Navigation – Plan du site

AccueilLes numéros15DossierUne méthodologie unifiée pour la ...

Dossier

Une méthodologie unifiée pour la construction de systèmes de qualité dans le domaine des TIC

Pierre-Michel Riccio

Résumés

L’Association Française de Normalisation définit la qualité comme l’aptitude d’un produit ou d’un service à satisfaire les besoins des utilisateurs. Cette définition nous semble insuffisante pour construire des systèmes de qualité dans le domaine des Technologies d’Information et de Communication. En effet, de nombreux acteurs influent sur le système construit et il peut exister une différence assez importante entre usages et besoins exprimés.

Pour apporter un début de réponse à ce problème, nous proposons une méthodologie unifiée associant : une approche communicationnelle empirico-inductive « le modèle situationnel », et un langage de modélisation standard « UML », pour recueillir, analyser, et visualiser les besoins de l’ensemble des acteurs, tout en facilitant la transition vers l’étape de réalisation du système.

Haut de page

Plan

Haut de page

Texte intégral

Introduction

1L’explosion des réseaux numériques internationaux accompagnée d’un large éventail de services existants, ou à créer, laisse un grand nombre de responsables d’entreprises ou d’organisations assez perplexes. Faut-il prendre le train en marche ? Quel peut être l’impact d’un investissement dans le domaine des Technologies d’Information et de Communication (TIC), sur les plans économique, organisationnel, culturel, médiatique ?

2La décision est particulièrement difficile à prendre car il existe un nombre important d’éléments, souvent contradictoires, qui peuvent influencer de façon directe ou indirecte la maîtrise des coûts :

3• Pour mener à bien un projet dans le domaine des TIC l’entreprise peut s’appuyer sur les méthodes et outils de Génie Logiciel destinés à faciliter la maîtrise des aléas dans le processus de développement « ensemble d’activités ordonnées, avec un déroulement séquentiel ou parallèle, qui permettent d’analyser et de concevoir, de rétro-concevoir ou de refondre le système » [Castellani 92]. La construction du système est alors décomposée en plusieurs activités : spécification, conception, réalisation, test, et recette, organisées en cycles de vie linéaires ou itératifs, avec un souci constant : gérer la qualité « aptitude d’un produit ou d’un service à satisfaire les besoins des utilisateurs » [Afnor 91].

4• Plusieurs enquêtes montrent que plus de la moitié des défauts, qui apparaissent dans les systèmes de type informatisés opérationnels, prennent leurs sources dans la phase amont du projet et plus particulièrement dans l’activité de spécification pendant laquelle le besoin est mal identifié ou pas identifié du tout.

5• Jusqu’à une période assez récente, l’activité de spécification était complètement dédiée au recueil des besoins (utilisateurs et système) : le « quoi », alors que l’activité de conception était dédiée à la construction de l’architecture système : le « comment ». Un certain nombre d’acteurs, comme le département américain de la défense, proposent aujourd’hui une approche différente dans laquelle l’activité de spécification est centrée sur la collecte de l’ensemble des caractéristiques du système à construire (« quoi » et « comment ») et l’activité de conception est centrée sur le choix des caractéristiques pertinentes (« satisfaisant le besoin ») [Dod 95].

6• Une des principales difficultés dans le développement d’un projet de type informatique est aujourd’hui bien identifiée : « La définition du problème n’est pas une donnée, mais un résultat. L’espace du problème n’est pas un espace figé et neutre ; mais au contraire un espace élastique, orienté par les interrogations des différents interlocuteurs du projet » [Afnor 93].

7• Le domaine des TIC concerne directement ou indirectement une large palette de profils et de compétences dans et hors de l’entreprise. La multiplicité des acteurs rend naturellement toute opération de construction d’un système beaucoup plus complexe.

8• Dans son ouvrage Les sens de la technique Victor Scardigli nous montre que l’utilisateur final crée les usages en s’appropriant, quelquefois de façon inattendue, les technologies mises à sa disposition [Scardigli 92].

9Cette énumération n’est pas exhaustive. Toutefois elle permet déjà d’imaginer le sentiment de perplexité qui peut étreindre le responsable éclairé d’une entreprise au moment de prendre une décision souvent vitale pour la structure.

10Comment, dans ce contexte, créer un système de qualité ? À partir de ces différents éléments et de notre expérience du terrain, nous proposons une nouvelle définition pour la qualité d’un système informatisé applicable aux TIC : « La qualité d’un système informatisé prend sa source dans l’adéquation entre les usages d’un système et les besoins des acteurs impliqués de façon directe ou indirecte dans la construction du système ou son utilisation ».

11Pour aborder le problème sous cet angle, il est intéressant de choisir un point de vue communicationnel en prenant appui sur le paradigme compréhensif des sciences humaines et sociales. C’est-à-dire en étudiant, dans une entreprise ou une organisation, l’ensemble des communications des acteurs impliqués dans la construction d’un système dans le domaine des TIC pour comprendre le sens de leurs actions et chercher à anticiper les usages.

12Pour ce faire, nous avons choisi d’utiliser la théorie des processus de communication et le modèle situationnel issu de cette théorie [Mucchielli 98a]. Ils permettent, dans une approche systémique et constructiviste, de faire émerger le sens qui accompagne toute communication généralisée.

13Avec cette démarche, nous obtenons des résultats particulièrement intéressants pour analyser l’introduction [Mucchielli 98b] ou la création [Riccio 97] de services ou d’applications dans le domaine des TIC. Toutefois le formalisme utilisé est essentiellement textuel. Il contribue à produire des études assez denses qui sont difficiles à lire pour les acteurs externes.

14Pour faciliter la construction de systèmes de qualité dans le domaine des TIC nous proposons d’utiliser aujourd’hui en complément de la théorie des processus et du modèle situationnel un langage graphique unifié de modélisation : UML [Rational 97]. Ce dernier a été créé pour unifier les standards de notation graphiques dans la modélisation objet des informations.

15Nous allons rappeler les principes de base des processus de la communication. Nous présenterons ensuite une vue synthétique du langage de modélisation UML. Enfin, pour terminer nous proposerons une méthodologie unifiée pour la construction de systèmes de qualité dans le domaine des TIC.

Les processus de la communication

16L’objet de la « Théorie des processus de la communication » [Mucchielli 98a] est de faire émerger, dans une approche systémique et constructiviste, le sens qui accompagne toute communication généralisée. Le modèle situationnel pour l’analyse des communications, issu de cette théorie, constitue un véritable guide opératoire systémique.

17Les processus de la communication ont été mis en évidence par Alex Mucchielli à partir de 1995 [Mucchielli 95]. Ils forment sept contextes utilisés par les acteurs dans l’échange.

La contextualisation spatiale

18Le lieu de réunion, l’aménagement de la salle, la position des individus autour de la table, la distance entre les personnes, les moyens techniques, sont des composantes qui, évoquées ou manipulées par les acteurs d’une situation, influencent le sens des communications.

19Il est réducteur de considérer que ces différentes composantes forment un cadre figé, une « mise en scène » statique. Le contexte spatial évolue en permanence pendant une rencontre. Il forme un contexte subjectif dynamique qui s’impose aux différents acteurs.

La contextualisation physique ou sensorielle

20L’acteur communique par et à travers l’ensemble de ses organes sensoriels : parole, mais aussi vue, ouïe, odorat, ou toucher. Dans toute action de communication, il est immergé dans un univers physique et sensoriel qui contribue au sens de l’échange.

21Des impacts sensoriels multiples (visuels, sonores, olfactifs, tactiles) en combinaison avec un contexte spatial organisé et des acteurs prédisposés, peuvent transformer les modalités de perception et la signification des communications [Hotier 97].

La contextualisation temporelle

22Toute communication généralisée s’inscrit dans un contexte historique et dynamique. Pour faire émerger le sens d’une communication il est nécessaire de la positionner dans son contexte temporel. La modification de ce contexte peut en changer le sens, de façon partielle ou complète.

23Sur le plan historique, la communication vient toujours se positionner dans le cadre de ce qui a déjà été communiqué. Sur le plan dynamique, elle est caractérisée par exemple par un rythme, régulier ou en rupture, et par des appels au temps, explicites ou implicites.

Le positionnement et la structuration des relations

24Dans son langage (tutoiement) mais aussi dans son paralangage (habillement), chaque individu propose sa vision du positionnement des acteurs de la situation. Tout échange est une lutte permanente dans laquelle l’individu cherche à valoriser sa position dans le groupe.

25Le processus de positionnement et de structuration des relations est particulièrement important dans le domaine des TIC compte tenu de l’hétérogénéité des acteurs impliqués dans la construction des systèmes et de l’impact des systèmes sur la place des acteurs dans l’entreprise.

L’appel, la construction ou l’émergence des nonnes

26Toute communication s’effectue dans un contexte normatif. Les normes sont multiples : culturelles et sociales dans la vie quotidienne, ou conduites en entreprise. Elles définissent un sens « a priori » partagé par un groupe d’individus.

27Les normes et règles forment un « déjà là », par exemple sous la forme de sentences proverbes dictons ou maximes dans la vie quotidienne. Elles sont évoquées de façon explicite ou implicite, évoluent en permanence, et quelquefois émergent dans l’échange.

La construction de la qualité des relations

28Dans la communication, les acteurs construisent une relation affective. Chaque individu utilise le langage et le paralangage pour séduire et influencer ses interlocuteurs. Pour faire émerger le sens, il est nécessaire d’identifier les composantes valorisantes et dévalorisantes mises en œuvre dans l’échange.

29De nombreuses études ont montré que les relations dans l’entreprise sont structurées autour du phénomène de pouvoir. Aussi, il est essentiel de comprendre quelles sont les alliances, coopérations, compétitions, ou conflits en œuvre dans la situation.

L’expression identitaire

30Tout individu est doté d’un système de pertinence qui en fonction de ses préoccupations forme sa vision du monde, c’est-à-dire une perception sélective des phénomènes de la vie [Schutz 1987]. Il n’est pas possible de saisir le sens d’une communication sans comprendre la motivation des acteurs de la situation.

31Les spécialistes distinguent chez l’acteur trois niveaux d’intentionnalité : une intentionnalité générale (« faire carrière », « investir dans un loisir »…), une intentionnalité présente (« obtenir une augmentation », « être l’acteur incontournable sur un sujet »…), et une intentionnalité réactionnelle (« prendre la bonne décision »).

L’analyse avec le modèle situationnel

32La première étape consiste à fixer le cadre de travail, recueillir et préparer les informations :

33– Poser une problématique avec : un thème de travail, les considérants ou attendus, et une proposition de cadrage.

34– Collecter les informations sur la ou les situations en utilisant une ou plusieurs méthodes qualitatives [Mucchielli 96] : observation, observation participante, interviews non directives centrées, interviews de groupes…

35– Transcrire l’ensemble des informations, existantes et collectées, sous une forme pratique : réserver par exemple une colonne en partie droite des documents.

36– Parcourir l’ensemble des documents et noter dans cette zone les phénomènes intéressants d’un point de vue communicationnel en se référant aux processus de la communication.

37La deuxième étape est consacrée à l’analyse à l’aide du modèle situationnel :

38– Le chercheur choisit, parmi l’ensemble des processus de la communication qui sont interdépendants et dans une démarche d’analyse systémique, le processus « émergent ».

39– Il analyse la situation à l’aide de ce processus et ensuite complète l’étude à l’aide des autres processus de la communication mis en œuvre dans la situation.

40– Le sens, résultat d’un processus complexe, surgit alors progressivement de la mise en relation des acteurs en situation dans ces différents contextes.

Le langage de modélisation UML

41À la fin de l’année 1994, Grady Booch et Jim Rumbaugh, créateurs des méthodes de modélisation objet Booch 93’[Booch 94] et OMT-2 [Rumbaugh 91], largement utilisées en entreprise, ont décidé de faire converger leurs travaux pour créer une méthode unifiée.

42La première présentation de la méthode unifiée a eu lieu lors du congrès OOPSLA 95’. Elle a suscité des réactions enthousiastes concernant le projet de définition d’une notation standard permettant enfin à l’ensemble des utilisateurs de communiquer facilement au niveau international, et réservées pour le choix des concepteurs d’imposer une méthode emprisonnant de fait les utilisateurs dans démarche opératoire figée.

43Grady Booch et Jim Rumbaugh ont repris leurs travaux avec l’aide d’un spécialiste de renommée internationale, Ivar Jacobson, créateur de la méthode Objectory [Jacobson 92]. Ils ont finalisé la première version du langage unifié de modélisation UML [Rational 97] en janvier 1997. UML est diffusé depuis gratuitement sur les réseaux internationaux.

44UML 1.0 n’est plus une méthode mais un langage de notation. Pour construire un modèle, l’utilisateur emploie la méthode de son choix (Booch 93’, OMT-2, Objectory ou une autre, qui lui fourni un guide opératoire) en respectant la notation UML. Le modèle résultant peut alors facilement être communiqué à un autre utilisateur.

45Pour créer le langage de modélisation unifié UML, le groupe de travail (Booch, Jacobson, et Rumbaugh) a étudié de façon détaillée l’ensemble des systèmes de notation existants. Après un important travail de synthèse, il a défini neuf types de diagrammes qui constituent autant de points de vues sur le système en construction.

Les diagrammes de classes

46Le diagramme de classes représente la vue statique d’un système. Il est composé de classes et des relations entre ces classes.

La classe

47La classe décrit une famille d’objets possédant la même structure et le même comportement [Stefik 86]. En UML, elle est représentée par un rectangle doté de trois zones :

48– La première permet l’identification de la classe.

49– La seconde est consacrée aux données statiques ou attributs.

50– La troisième est dédiée aux données dynamiques, opérations ou méthodes.

51Nom de la classe

52Attribut : type = valeur initiale

53Méthode ()

Figure 1 : La classe.

Les relations

54Les relations sont au nombre de quatre :

55– L’association est une relation entre deux classes.

56– L’agrégation est une association non symétrique.

57– La composition est une agrégation matérialisant une relation d’inclusion.

58– L’héritage représente une relation de dérivation.

Figure 2 : Les relations.

59Pour les diagrammes de classe, UML propose d’autres éléments de notation : les stéréotypes, les propriétés, la visibilité, l’interface, la cardinalité, et les contraintes.

60Moteur

61Carrosserie

Figure 3 : Un diagramme de classes UML.

Les cas d’utilisation

62Les cas d’utilisations ou « use cases » ont pour objet de faciliter la description sous forme graphique et textuelle de l’utilisation d’un système. Ils sont organisés autour de trois composants essentiels : les acteurs, les cas d’utilisation eux-mêmes, et le système.

Figure 4 : Le système dans les cas d’utilisation

L’acteur

63L’acteur représente le rôle joué par une personne ou un élément en interaction avec le système. Un même acteur peut agir de différentes façons. Le mécanicien auto entretient l’automobile du client, la conduit pour l’essayer, ou la répare.

64Mécanicien

65

Figure 5 : L’acteur interagit avec le système.

66Une personne physique peut avoir plusieurs rôles. Par exemple, lorsque le mécanicien achète une automobile ou conduit son véhicule personnel il se transforme en client. Dans ce cas, la même personne est représentée par deux acteurs différents.

67Mécanicien Client

68

Figure 6 : Deux rôles pour une même personne conduisent à la création de deux acteurs.

69Lorsque plusieurs individus ont un rôle identique, UML préconise de ne représenter qu’un seul acteur. Ce « méta-acteur » améliore grandement la lisibilité du modèle. Il permet, par exemple, de ne représenter qu’un seul acteur le « mécanicien » pour modéliser l’ensemble des mécaniciens travaillant dans le même atelier d’une concession automobile. Naturellement le chef d’atelier ou l’apprenti ayant des rôles différents donneront naissance à de nouveaux acteurs.

70Dans les cas d’utilisation, la notion d’acteur est très fortement liée à la notion de rôle. Par extension du rôle, l’acteur peut aussi représenter une personne morale ou un système externe qui échange des informations avec le système modélisé. Une fois identifiés, les différents acteurs doivent être décrits en quelques lignes.

Les cas d’utilisation

71Les cas d’utilisation sont déterminés par analyse des séquences d’interaction entre les différents acteurs et le système.

72Mécanicien

73

Figure 7 : Un cas d’utilisation – réviser une automobile.

74En complément de la représentation graphique, les cas d’utilisation font l’objet d’une description textuelle qui précise : le début et la fin du cas d’utilisation, les interactions, les informations échangées, ainsi que la chronologie et l’origine des informations. La description dissocie le cas d’utilisation des différents scénarios qui le traversent.

Le système

75Dans les cas d’utilisation, le système est construit progressivement à partir de l’ensemble des informations recueillies. La juxtaposition de l’ensemble des cas constitue le modèle des besoins appelé aussi spécification du système.

Les diagrammes d’objets

76Les diagrammes d’objets sont utilisés essentiellement en complément des diagrammes de classes pour apporter un éclaircissement sur un sous-ensemble du modèle. Ils permettent de visualiser plus facilement les évolutions de contextes ou le détail d’une structure de données complexe.

77La notation est dérivée de celle des diagrammes de classes dont elle reprend la syntaxe. Les principales différences sont : la notation « objet : classe », et le lien qui remplace la relation.

Figure 8 : Un diagramme d’objets.

Les diagrammes de collaboration

78Les diagrammes de collaboration sont une extension des diagrammes d’objets. Ils permettent de faciliter la représentation des interactions entre « objets ».

79Le principe consiste à positionner des messages sur les liens entre les objets. Il est possible de numéroter les messages pour matérialiser le séquencement des opérations.

Figure 9 : Un diagramme de collaboration.

80La notation UML préconise l’utilisation d’objets mais aussi d’acteurs dans les diagrammes de collaboration. Cela permet par exemple de mettre en évidence les interactions entre un utilisateur et les différents objets du système.

Figure 10 : Ouverture du coffre d’une voiture (verrouillage centralisé).

81Les diagrammes de séquences

82Les diagrammes de séquences permettent de représenter les interactions entre objets selon un point de vue temporel.

83Une barre verticale appelée ligne de vie est construite à partir de l’objet matérialisé par un rectangle. Les communications entre objets, ou messages, sont représentées par des flèches horizontales entre les lignes de vie. De cette façon il est assez facile d’identifier l’ordre d’envoi des messages à partir de la position des flèches sur les différentes lignes de vie. Il existe plusieurs types de flèches pour représenter différents modes de transmission (asynchrone, synchrone…).

Figure 11 : L’ouverture d’une voiture (diagramme simplifié).

Les diagrammes d’états-transitions

84Les diagrammes états-transitions permettent de représenter un système selon un point de vue dynamique à partir de trois éléments essentiels : les états du système, les transitions, et les événements.

Figure 12 : Exemple simplifié de diagramme états-transitions.

85L’état caractérise une période de stabilité du système (un système est toujours dans un état), il est représenté par un rectangle aux coins arrondis. La transition matérialise le passage d’un état dans un autre, elle est représentée par une flèche. L’événement, qui déclenche le changement d’état, est précisé sous une forme textuelle à proximité des transitions.

Les diagrammes d’activités

86Le diagramme d’activités est une variante du diagramme états-transitions dans laquelle l’activité est mise en valeur. Il permet de mieux visualiser le déroulement des opérations.

87Les activités sont représentées sous la forme d’un rectangle doté d’un demi-cercle à chaque extrémité. La transition est toujours représentée par une flèche, mais sans événement. Le diagramme d’activités peut aussi contenir des états, des stéréotypes, ou des objets.

Figure 13 : Exemple simplifié de diagramme d’activités

Les diagrammes de composants

88Les diagrammes de composants sont utilisés pour décrire les éléments physiques d’une application. De multiples éléments sont gérés comme : les fichiers d’en-têtes (spécification), les fichiers d’implémentation (corps), les fichiers de classes paramétrables (génériques), les processus et tâches, le programme principal, les sous-programmes, et les sous-systèmes. Naturellement les diagrammes de composants permettent aussi de représenter les relations entre ces différents éléments.

Les diagrammes de déploiement

89L’objet des diagrammes de déploiement est de représenter l’implantation physique des différents éléments de l’application. Quelle sont les machines utilisées (les postes serveurs, les postes clients) ? Est-ce qu’il y a des imprimantes ? Comment les différents sous-ensembles sont-ils connectés (niveau physique, protocoles de communication) ?

La méthodologie unifiée

90La méthodologie unifiée associe une approche compréhensive pour l’analyse des situations, le modèle situationnel, et un langage de modélisation, UML. L’ensemble est intégré dans un cadre destiné à faciliter la construction de systèmes de qualité dans le domaine des TIC.

91Par commodité d’écriture, nous allons présenter cette méthodologie sous la forme de points. Le lecteur prendra note que nous sommes dans une approche méthodologique systémique et constructiviste. Cela signifie que les différents points de la méthodologie peuvent être traités dans n’importe quel ordre. Cela ne signifie pas que les points sont exclusifs (distincts) et commutatifs (interchangeables). En fait l’analyste pourra commencer par le point qu’il trouve le plus adapté, par rapport à la situation étudiée et aux informations dont il dispose, pour continuer son travail avec les autres points et revenir si nécessaire aux précédents.

92Nous proposons de construire un système qui intègre l’ensemble des éléments concernant l’objectif de façon directe ou indirecte : les communications généralisées, les éléments des contextes (spatial, physique ou sensoriel, temporel, de positionnement, normatif, de la qualité des relations, de l’expression identitaire), les exigences exprimées par les acteurs, et les informations existantes. En procédant autrement, par exemple par recueil et analyse des seules exigences exprimées par les acteurs, nous aurions considéré de fait qu’il n’existe pas de possibilité de contradiction entre ces exigences et d’autres éléments d’information, et perdu de vue une partie de notre cible : construire des systèmes de qualité.

La problématique

93La méthodologie unifiée est ancrée dans une démarche qualitative de type empirico-inductif. Il s’agit d’une démarche de découverte dans laquelle le chercheur va s’attacher à faire émerger les éléments signifiants de la situation.

94Pour une meilleure efficacité, il est important que le chercheur formalise une problématique. La problématique peut être définie comme : « une mise en relation argumentée des considérants permettant de poser un problème de recherche (une grande question) » [Paillé 96]. La question doit être ouverte et s’appuyer sur les problèmes du terrain identifiés à travers les considérants. La problématique pourra naturellement être affinée et aménagée pendant le travail d’étude.

L’identification des acteurs

95Pour élaborer un système de qualité, il est essentiel d’avoir une bonne vision des acteurs qui vont participer de façon directe ou indirecte au processus de construction ou d’utilisation du système. Nous proposons d’organiser ce travail en deux activités : identifier les acteurs, et construire les classes d’acteurs.

Identifier les acteurs

96L’identification exhaustive des acteurs, qui peuvent influencer la construction ou l’utilisation d’un système dans le domaine des TIC, peut représenter un nombre de personnes assez important, dans et hors de l’entreprise : chef de projet, direction, chargé de communication, juriste, gestionnaire, représentant de l’assurance qualité, représentant du service informatique, représentant des utilisateurs, utilisateurs, intervenants externes.

97Pour mener à bien cette activité, il existe plusieurs techniques : réaliser une véritable enquête, se procurer l’organigramme complet et à jour de l’entreprise puis éliminer de la liste les personnes qui ne sont pas concernées par l’opération sans oublier d’ajouter les intervenants externes, identifier un premier groupe de personnes incontournables dans l’opération et étendre cette population en menant un enquête rapide auprès des personnes de ce premier groupe et de façon récurrente auprès des personnes des nouveaux groupes. Plus sûrement, combiner les différentes techniques pour atteindre un meilleur résultat.

98Pendant le travail d’identification, il est important de définir et de mémoriser un ensemble d’attributs (fonction, service, position hiérarchique, localisation géographique…). Ces attributs seront ensuite utilisés pour construire le modèle des acteurs.

Construire les classes d’acteurs

99En appliquant, sur la population identifiée et pour les différents attributs retenus, un mécanisme semblable à celui des rôles, présenté dans les « cas d’utilisation » (cf. § 2B), le chercheur va pouvoir construire des groupes d’acteurs homogènes.

100Par exemple, la direction commerciale d’une entreprise est composée de quatre groupes : un « directeur », une « assistante de direction », des « ingénieurs expérimentés », et des « jeunes commerciaux ».

101Pour visualiser plus facilement l’ensemble des groupes (ou classes d’acteurs), qui forme le modèle des acteurs, nous proposons d’utiliser le « diagramme de classes » (cf. § 2A). Le diagramme de classes va permettre de représenter les classes d’acteurs et les relations entre ces classes (association, agrégation, composition, héritage). Pour améliorer la lisibilité du modèle il est recommandé de créer des classes structurantes ne contenant pas directement d’acteur comme « entreprise », « direction commerciale », ou bien « atelier ».

Le recueil des informations

102Nous proposons de découper le recueil des informations en quatre activités : inventorier les informations existantes, définir une stratégie d’enquête, enquêter, et mettre au net les informations.

Inventorier les informations existantes

103Dans une entreprise ou une organisation il existe très souvent des données potentiellement intéressantes. Pendant l’étude, le chercheur s’attachera à identifier ces données et à organiser les informations collectées.

Définir une stratégie d’enquête

104Il existe de nombreuses techniques qualitatives de recueil des données. Parmi celles-ci nous privilégions l’observation participante, l’interview non directive active, et l’interview de groupe non directive centrée.

105L’observation participante a pour objet essentiel de comprendre les phénomènes à l’intérieur de l’entreprise. Le chercheur doit être immergé dans le groupe. Son travail consiste à observer et comprendre les faits humains.

106L’interview non directive active est une variante de l’interview non directive. Le chercheur pose une question ouverte. Il soutient son interlocuteur dans sa réflexion et en présente régulièrement des synthèses progressives pour organiser le contenu des informations.

107Dans l’interview de groupe non directive centrée le chercheur joue le rôle de l’animateur. Il prépare la réunion en définissant un thème précis, en choisissant le lieu et la durée, en arrêtant la composition de groupes homogènes d’une dizaine de personnes, et en communiquant aux participants une information préalable. Pour composer les groupes, il est essentiel de s’appuyer sur le modèle des acteurs (cf. § 3B).

108Définir une stratégie d’enquête va consister à projeter l’usage des techniques qualitatives dans le temps. Le chercheur intégrera ses différentes contraintes (durée de l’étude, dates limites, disponibilité, regroupement des interviews…) et celles de ses interlocuteurs (nécessaire information, respect des canaux hiérarchiques, disponibilités…). Il prendra soin de caler l’enquête suffisamment en amont dans l’étude pour avoir le temps de valider ses travaux et de les compléter si nécessaire.

Enquêter

109Il y a peu de commentaires à faire sur l’activité d’enquête si ce n’est qu’il peut être utile pour un entretien particulièrement important d’être assisté par une personne expérimentée (par exemple pour mener un série d’interviews de groupe non directives centrées). Nous conseillons aussi de prévoir un rythme d’enquête raisonnable (un rythme trop élevé affectant de façon sensible les capacités d’abstraction du chercheur).

110Nous rappelons qu’il est important de tenir avec rigueur un journal d’enquête dans lequel le chercheur consignera de façon chronologique les informations collectées.

Mettre au net les informations

111Dans l’inventaire des informations, l’observation participante, l’interview des acteurs et des groupes, le chercheur construit une abstraction qui est déjà une forme d’analyse.

112La mise au net consiste à organiser ces « informations », par exemple en réservant une zone dans les différents documents, pour faciliter l’identification des phénomènes intéressants.

L’analyse

113Pour mener une analyse de qualité, nous proposons d’associer étroitement modèle situationnel et langage de modélisation UML autour de quatre activités : identifier les phénomènes, analyser la situation, construire les cas d’utilisation, et finaliser le modèle des besoins.

Identifier les phénomènes

114Identifier les phénomènes intéressants consiste, pour le chercheur, à parcourir l’ensemble des documents « mis au net » avec deux questions rémanentes à l’esprit : « Comment les différents contextes sont-ils évoqués ou manipulés par les acteurs dans l’échange ? » et « Quels sont les objets cognitifs (éléments de modèle de types fonctionnel, dynamique, ou informationnel, matériels et immatériels) auxquels l’acteur fait référence de façon explicite ou implicite ? ».

115Ce travail va faire émerger un ensemble de phénomènes que le chercheur notera, par exemple dans les zones préalablement réservées à cet effet dans les documents.

Analyser la situation

116Pour analyser la situation, nous proposons d’utiliser le modèle situationnel issu de la théorie des processus de la communication (cf. § 1H).

117Le chercheur parcours l’ensemble des informations recueillies. Il choisit, dans une démarche d’analyse systémique, parmi les processus de la communication qui sont interdépendants, le processus « émergent » (en fonction de sa sensibilité théorique). Il analyse la situation à l’aide de ce processus (en s’appuyant naturellement sur les phénomènes intéressants identifiés) et complète l’étude à l’aide des autres processus de la communication mis en œuvre dans la situation. Le sens, résultat d’un processus complexe, surgit alors progressivement de la mise en relation des acteurs en situation dans les différents contextes.

Construire les cas d’utilisation

118À partir de la problématique, des documents annotés, et de l’analyse, le chercheur identifie les différents cas d’utilisation (cf. § 2B).

119Pour chaque cas d’utilisation, il rédige un descriptif en précisant : le début du cas d’utilisation (événement déclencheur), la fin du cas d’utilisation (cause d’arrêt), l’interaction entre le cas d’utilisation et les acteurs (limites du système), les informations échangées, la chronologie et l’origine des informations.

120En complément du descriptif, il construit une représentation graphique matérialisant : les acteurs, le système, les cas d’utilisation, et les interactions entre cas d’utilisation et acteurs.

Finaliser le modèle des besoins

121La dernière activité de l’analyse consiste à finaliser le modèle des besoins. Nous disposons : d’une problématique, d’une liste d’acteurs, d’un modèle des acteurs (diagramme de classe), d’un journal d’enquête, de comptes-rendus d’observations et d’interviews annotés, d’un ensemble de documents de l’entreprise concernant de façon directe ou indirecte le projet, de l’analyse communicationnelle, de la liste des cas d’utilisations, et des descriptifs des cas d’utilisation accompagnés de leurs représentations graphiques.

122À partir de ces informations, le chercheur élabore un document de synthèse intégrant : la problématique, une présentation de l’opération, l’analyse communicationnelle, et les cas d’utilisations documentés.

123Il vérifie la qualité du système en construction en effectuant un travail de recoupement entre l’analyse communicationnelle, les cas d’utilisation, et les objets cognitifs identifiés.

124Rappelons que les objets cognitifs peuvent être de différents types :

125– fonctionnels (activités) : téléphoner au garage pour prendre rendez-vous, transférer la communication téléphonique au chef d’atelier, vidanger la voiture…

126– dynamiques (états d’un système) : voiture à l’arrêt, voiture en accélération, voiture en vitesse de croisière…

127– informationnels (statiques) : voiture, téléphone, bidon d’huile, client, chef d’atelier, règle d’usage, manuels d’entretien…

128Le travail sera naturellement beaucoup plus rapide si le chercheur a pris soin d’annoter correctement les documents dans l’activité d’identification des phénomènes.

129Le chercheur s’attachera à compléter chaque cas d’utilisation, en utilisant par exemple une approche fonctionnelle avec des diagrammes d’activités UML (Figure 15). Il peut aussi construire une vue informationnelle générale du projet à l’aide d’un diagramme de classes.

130• Le client téléphone au garage pour prendre un rendez-vous pour la révision de sa voiture

131• L’hôtesse d’accueil lui passe le chef d’atelier

132• Le chef d’atelier lui propose une date de rendez-vous

133• Le client accepte

134• Le jour venu le client se présente à l’accueil du garage

135• L’hôtesse lui demande les clefs de sa voiture et lui fait signer la fiche de révision

136• Le client se dirige vers la salle d’attente

137• L’hôtesse d’accueil transmet les clefs et la fiche de révision au chef d’atelier

138• Le chef d’atelier appelle un apprenti et demande de rentrer le véhicule et de faire la vidange

139• L’apprenti ayant terminé rapporte les clefs au chef d’atelier

140• Le chef d’atelier vérifie quelques points sur la voiture

141• Le chef d’atelier sort le véhicule et rapporte les clefs et la fiche à l’hôtesse d’accueil

142• L’hôtesse d’accueil fait la facture et appelle le client

143• Le client paye la facture

144• L’hôtesse d’accueil remet au client les clefs de la voiture

Figure 14 : Exemple simplifié de description d’un cas d’utilisation

Figure 14 : Exemple simplifié de description d’un cas d’utilisation

Figure 15 : Exemple de diagramme d’activités pour un cas d’utilisation.

145Pour terminer, afin d’optimiser la qualité du travail réalisé, le chercheur s’appuiera sur le guide qualité interne de l’entreprise ou à défaut sur celui d’un organisme comme l’IEEE [Ieee830 98] (ce document propose une trame exhaustive qui permet de limiter les oublis).

146À partir du modèle des besoins, la conception pourra être réalisé dans la continuité, même si les équipes de conception utilisent des paradigmes de développement différents :

147• Le paradigme procédural : Il est guidé par les traitements qui s’appuient sur des données. Dans ce cas, le travail à venir consistera à construire un diagramme de classes (en privilégiant les relations d’associations) pour la partie données, et des diagrammes d’activités ou d’états-transitions pour la partie traitements.

148• Le paradigme objet : Il est centré sur l’existence d’une architecture de classes, chaque classe contenant ses données et traitements sous la forme d’attributs et de méthodes. Dans ce cas, le travail consistera à construire un diagramme de classes complet et modulaire.

Les apports de l’articulation SIC/UML

149La méthodologie unifiée est dédiée à la construction de systèmes de qualité dans le domaine des TIC. Elle est ancrée d’une part sur la théorie des processus de la communication [Mucchielli 98a] et les Sciences de l’Information et de la Communication (SIC), et d’autre part sur le langage de représentation graphique UML [Rational 97] issu de travaux menés dans la modélisation objet des connaissances.

150Centrée sur l’émergence des projets, la méthodologie unifiée est organisée en onze activités, de la problématique au modèle des besoins (Figure 16). Ces activités peuvent être, dans une approche systémique et constructiviste, abordés dans un ordre différent.

151Dans la méthodologie unifiée les composantes SIC et UML ne sont pas juxtaposées, mais utilisées conjointement en « interaction ». Pour mieux comprendre les apports de cette articulation nous allons parcourir les onze activités.

Poser la problématique [SIC]

152Nous sommes dans une démarche de type empirico-inductif. Poser une problématique qui s’appuie sur les problèmes concrets permet de limiter les risques liés à la « redécouverte » de phénomènes du terrain bien connus des spécialistes. La

Figure 16 : Les activités de la méthodologie unifiée.

153Validation de cette problématique auprès des principaux acteurs du projet facilite la clarification du contexte. Il est assez courant que la problématique soit aménagée progressivement pendant l’étude.

Identifier l’ensemble des acteurs [SIC]

154Il existe différentes techniques pour identifier les acteurs directs et indirects d’un projet, mais la plus satisfaisante est l’enquête qualitative. Même si l’identification des acteurs peut prendre beaucoup de temps, elle est à notre avis indispensable. Si la liste des acteurs est incomplète les interviews seront partielles et cela peut affecter de façon importante la qualité du modèle des besoins.

155Notre expérience nous a permis de constater qu’il est assez difficile d’identifier de façon exhaustive l’ensemble des acteurs lorsque cette activité est abordée en début de projet. En effet, les interviews réalisées dans l’activité d’enquête peuvent faire émerger de nombreux acteurs indirects. Il est toutefois souhaitable de mener cette activité assez tôt pour disposer du modèle des acteurs avant d’élaborer la stratégie d’enquête. Si de nouveaux acteurs sont ensuite découverts, il suffit de mettre à jour la liste, de procéder à l’aménagement du modèle des acteurs, et de compléter éventuellement les interviews.

Élaborer le modèle des acteurs [SIC et UML]

156L’activité d’élaboration du modèle des acteurs est SIC pour le travail d’identification des critères pertinents concernant les différents acteurs du projet (fonction, position hiérarchique, zone d’affectation…). Elle est UML pour le travail de construction du modèle des acteurs en s’appuyant sur un diagramme de classes (cf. § 2A).

157L’utilisation des classes et relations UML permet de représenter la structure d’un service ou d’une entreprise et les relations entretenues avec les acteurs extérieurs. Elle facilite la visualisation en permettant d’identifier par exemple, d’un seul coup d’œil, que la personne en contact avec l’agence de publicité est la secrétaire du directeur de la communication et non ce dernier. Ce type de représentation, que les personnes non spécialisées peuvent lire aisément, permet de valider le modèle des acteurs de façon interne et externe.

Inventorier les informations existantes [SIC et UML]

158L’inventaire des informations existantes est une tâche difficile. Elle nécessite généralement un travail d’enquête approfondi pour collecter et organiser les données disponibles dans l’entreprise sur le sujet. En effet, même pour un nouveau projet, les éléments d’information peuvent être assez abondants et de nature très diverses (notes, rapports, applications, versions antérieures, essais infructueux…).

159Le travail SIC d’enquête sur le terrain va permettre de collecter et de qualifier les éléments d’information. Il sera complété de façon efficace par la construction d’un modèle UML de type informationnel élaboré à l’aide d’un diagramme de classes (cf. § 2A).

160Le diagramme de classes UML des informations existantes va faciliter la représentation des informations collectées et des relations entre ces informations. Il pourra être utilisé pour valider, de façon interne et externe, le modèle des informations.

Définir une stratégie d’enquête [SIC]

161L’objectif de cette activité est de définir la bonne stratégie pour mener l’enquête qualitative. À cet instant, le chercheur doit choisir les techniques à utiliser et les acteurs à interviewer et/ou situations à observer.

162L’existence des modèles UML, modèle des acteurs et modèle des informations, peut faciliter grandement la tâche du chercheur. Ce dernier va pouvoir s’appuyer sur ces représentations pour élaborer la stratégie d’enquête.

Enquêter [SIC]

163Nous tenons à rappeler que nous sommes dans une approche méthodologique systémique et constructiviste. En effet il est assez courant pendant l’enquête que le chercheur souhaite par exemple aménager sa problématique. Il peut aussi découvrir de nouveaux acteurs, ce qui risque de modifier sa stratégie d’enquête, ou se rendre compte qu’une technique d’enquête choisie n’est pas satisfaisante. Dans ces différents cas il abandonnera provisoirement l’activité en cours pour y revenir par la suite.

164Notre pratique sur le terrain nous a permis de constater que la méthodologie unifiée est utilisable pour la construction de modèles des besoins mais aussi pour leur reconstruction. C’est le cas en particulier lorsque l’on souhaite faire évoluer un système informatisé. Il est alors intéressant de construire les cas d’utilisation (cf. § 2B) (à partir des informations existantes) pour mener ensuite une enquête destinée à consolider les informations existantes et collecter les éléments d’information complémentaires. L’utilisation de diagrammes UML va faciliter la présentation des informations existantes aux différents acteurs.

Mettre au net les informations [SIC]

165La mise au net des informations est une activité importante, mais pas très complexe. Elle consiste essentiellement à mettre en forme les informations collectées de façon à pouvoir les annoter ensuite facilement. La principale difficulté de cette activité réside dans l’écriture des interviews et/ou cas.

166Le travail à réaliser est assez différent selon l’expérience du chercheur. S’il est expérimenté, il note et organise les informations essentielles sur le papier en « temps réel » pendant le travail d’enquête. Le travail de mise au net consiste alors à relire les notes, les saisir, et les mettre en forme. S’il est moins expérimenté, il doit par exemple enregistrer ses entretiens et prendre un maximum de notes. Le travail de mise au net dans ce cas est assez important puisque le chercheur doit retranscrire ses entretiens, les organiser, et procéder à la mise en forme.

Identifier les phénomènes [SIC et UML]

167L’identification des phénomènes consiste à annoter les documents préparés. Le chercheur va parcourir l’ensemble des documents en précisant, en regard de chaque interaction, les processus de communication évoqués ou manipulés dans l’échange. Il note aussi l’ensemble des objets cognitifs émergents (fonctionnels, dynamiques, ou informationnels).

168Pour faciliter le travail d’analyse à venir, il est intéressant de compléter les annotations textuelles à l’aide de schémas. Il est possible d’utiliser différents types de diagrammes UML : les diagrammes d’objets (cf. § 2C), de collaboration (cf. § 2D), de séquences (cf. § 2E), d’états-transitions (cf. § 2F), ou d’activités (cf. § 2G). Ces différentes représentations vont permettre de détailler les « micro-situations »

Analyser la situation [SIC et UML]

169Après la mise au net et l’identification des phénomènes, cette activité constitue la troisième étape de l’analyse. L’objectif est double, comprendre la situation et construire le cœur des cas d’utilisation.

170Après avoir identifié le processus « émergent » (en fonction de sa sensibilité théorique), le chercheur analyse la situation à l’aide de ce processus et complète l’étude à l’aide des autres processus de la communication mis en oeuvre dans la situation. Le sens surgit alors progressivement de la mise en relation des acteurs en situation dans les différents contextes.

171Pour mener à bien l’analyse le chercheur peut naturellement s’appuyer sur les schémas UML réalisés dans l’activité précédente. À ce niveau nous recommandons la construction de schémas UML plus complets à partir de l’ensemble des phénomènes identifiés.

Construire les cas d’utilisation [UML]

172Dans cette activité, le chercheur va commencer par identifier les différents cas d’utilisation (cf. 2B). Il est préférable de ne pas dépasser une dizaine de cas. Pour chaque cas d’utilisation, le chercheur s’attache ensuite à préciser l’événement déclencheur, la cause d’arrêt, les limites du système, et les objets fonctionnels dynamiques et informationnels.

173Nous avons pu constater que des diagrammes UML, en particulier les diagrammes d’activités (Figure 15) peuvent remplacer de façon avantageuse une partie de la description textuelle.

Finaliser le modèle des besoins [UML]

174L’activité de finalisation du modèle des besoins est la dernière étape dans la construction initiale du système. À partir de l’ensemble des documents, le chercheur va élaborer un document de synthèse qui sera par exemple un cahier des charges.

175Concernant le document, il nous semble important de rappeler en introduction la problématique dans sa version la plus évoluée. L’analyse communicationnelle permet ensuite de poser le cadre de l’opération en attirant l’attention ou en effectuant un certain nombre de recommandations sur l’impact que peut avoir l’introduction du nouveau système dans l’organisation. Le descriptif des besoins est quant à lui articulé autour des cas d’utilisations documentés et des diagrammes UML.

Conclusion

176L’objectif de notre travail de recherche est de mettre en évidence les possibilités d’amélioration de la qualité des systèmes dans le domaine des TIC en utilisant de façon conjointe, dans le processus de construction des systèmes, une démarche compréhensive pour le recueil et l’analyse des informations et un langage de modélisation standard.

177L’analyse communicationnelle va nous permettre de mieux comprendre la motivation des acteurs et le fonctionnement de l’entreprise. Avec ces informations, nous serons capables de mieux qualifier les exigences exprimées par les acteurs dans la construction d’un système et de procéder avec une meilleure pertinence aux arbitrages nécessaires.

178L’usage d’un langage de modélisation standard va faciliter la validation interne et/ou externe des besoins recueillis. Il va rendre aussi la transition vers les étapes de conception et de réalisation du système beaucoup plus naturelle.

179À partir de la méthodologie unifiée que nous venons de présenter, nous avons initié plusieurs projets dans le domaine de l’ingénierie des besoins avec des entreprises de tailles différentes. Il est encore trop tôt pour dresser un bilan, mais nous pouvons évoquer quelques points émergents.

180La démarche est très bien accueillie dans les entreprises qui considèrent la méthodologie unifiée comme une base de travail à partir de laquelle il est possible d’aménager le processus interne de construction des systèmes de qualité dans le domaine des TIC.

181Les entreprises voient dans la méthodologie unifiée une opportunité pour : construire des modèles de besoins plus complets, recueillir des besoins mieux qualifiés (ce qui va faciliter les arbitrages), améliorer la lisibilité des cahiers des charges, échanger plus simplement des informations (à l’aide d’un langage standard de modélisation), faciliter la validation des besoins, effectuer une transition plus naturelle vers la conception et la réalisation.

182Les premiers résultats sont très encourageants, mais il reste un travail important à réaliser pour faciliter l’appropriation de la démarche dans l’entreprise.

Haut de page

Bibliographie

Association française de normalisation, Management de projet –Recommandations pour l’analyse et la modélisation graphique d’actions et son utilisation pour une meilleure communication entre les acteurs d’un projet, Amor NF X 50-109, Paris, décembre 1991. Association française de normalisation, Traitement de l’information – Modèle de cycle de vie adapté au maquettage/prototypage, Afnor NF Z 67-111, Paris, mai 1993.

BoocH G., Analyse & Conception orientées objets, Addison-Wesley, Paris, 1994.

American department of defense, Military Standard Defense

System Software Development, MIL-STD 498,1995.

Hotier H., L’induction ou l’emprise des sens, Communication

et organisation, Textes préparatoires au colloque Induction et

communication du GREC/O, juin 1997.

Jacobson I. and al., Object-Oriented Software Engineering, A

Use Case Driven Approach, Addison-Wesley, Wokingham,

England, 1992.

MUCCHIELU A., Les Sciences de l’Information et de la Communication, Hachette, Paris, 1995.

MUCCHIELLI A. sous la dir., Dictionnaire des méthodes qualitatives en sciences humaines et sociales, Armand-Colin, Paris, 1996. Mucchielli A. et al, Théorie des processus de la communication, Armand-Colin, Paris, 1998.

MUCCHIELLI A., Douze cas et exercices sur la communication, Armand-Colin, Paris, 1998.

PAILLE P., Problématique d’une recherche qualitative, in Dictionnaire des méthodes qualitatives en sciences humaines et sociales, Armand-Colin, Paris, 1996,165-167.

Rational Co, UML Notation Guide 1.1, Rational Corporation, Santa Clara Ca, 1997.

RICCIO P.M., Vers une amélioration de la qualité des projets : relations interhumaines et cahiers des charges, Mémoire de DEA, Université Paul Valéry, Montpellier, 1997. Rumbaugh J. and al., Object-Oriented Modeling and Design, Prentice-Hall Nj, 1991.

SCARDIGLI V., Les sens de la technique, Presses Universitaires de France, Paris, 1992.

SCHUTZ A., Le Chercheur et le Quotidien, Méricuerts-Klincksieck, Paris, 1987.

STEFIK M.J. et Bobrow D.G., Object-Oriented Programming : Themes and Variations, The AI Magazine, vol. 6, n° 4,1986.

Haut de page

Table des illustrations

URL http://journals.openedition.org/communicationorganisation/docannexe/image/2188/img-1.png
Fichier image/png, 52k
URL http://journals.openedition.org/communicationorganisation/docannexe/image/2188/img-2.png
Fichier image/png, 83k
URL http://journals.openedition.org/communicationorganisation/docannexe/image/2188/img-3.png
Fichier image/png, 104k
URL http://journals.openedition.org/communicationorganisation/docannexe/image/2188/img-4.png
Fichier image/png, 23k
URL http://journals.openedition.org/communicationorganisation/docannexe/image/2188/img-5.png
Fichier image/png, 22k
URL http://journals.openedition.org/communicationorganisation/docannexe/image/2188/img-6.png
Fichier image/png, 17k
URL http://journals.openedition.org/communicationorganisation/docannexe/image/2188/img-7.png
Fichier image/png, 30k
URL http://journals.openedition.org/communicationorganisation/docannexe/image/2188/img-8.png
Fichier image/png, 63k
URL http://journals.openedition.org/communicationorganisation/docannexe/image/2188/img-9.png
Fichier image/png, 30k
URL http://journals.openedition.org/communicationorganisation/docannexe/image/2188/img-10.png
Fichier image/png, 17k
URL http://journals.openedition.org/communicationorganisation/docannexe/image/2188/img-11.png
Fichier image/png, 28k
URL http://journals.openedition.org/communicationorganisation/docannexe/image/2188/img-12.png
Fichier image/png, 27k
URL http://journals.openedition.org/communicationorganisation/docannexe/image/2188/img-13.png
Fichier image/png, 132k
Titre Figure 14 : Exemple simplifié de description d’un cas d’utilisation
URL http://journals.openedition.org/communicationorganisation/docannexe/image/2188/img-14.png
Fichier image/png, 163k
URL http://journals.openedition.org/communicationorganisation/docannexe/image/2188/img-15.png
Fichier image/png, 269k
Haut de page

Pour citer cet article

Référence électronique

Pierre-Michel Riccio, « Une méthodologie unifiée pour la construction de systèmes de qualité dans le domaine des TIC »Communication et organisation [En ligne], 15 | 1999, mis en ligne le 05 février 2013, consulté le 28 mars 2024. URL : http://journals.openedition.org/communicationorganisation/2188 ; DOI : https://doi.org/10.4000/communicationorganisation.2188

Haut de page

Auteur

Pierre-Michel Riccio

Pierre-Michel Riccio est ingénieur du Conservatoire National des Arts et Métiers, diplômé en gestion des entreprises et en génie logiciel de l’Université Montpellier II, et diplômé en sciences de l’information et de la communication de l’Université Paul Valéry-Montpellier III. Après dix années en entreprise où il a piloté de nombreux projets dans le domaine des TIC, il est depuis 1991 enseignant-chercheur, maître-assistant au LGI2P de l’École des Mines d’Alès, et chercheur au CERIC de l’Université Paul Valéry.

Articles du même auteur

Haut de page

Droits d’auteur

CC-BY-NC-ND-4.0

Le texte seul est utilisable sous licence CC BY-NC-ND 4.0. Les autres éléments (illustrations, fichiers annexes importés) sont « Tous droits réservés », sauf mention contraire.

Haut de page
Rechercher dans OpenEdition Search

Vous allez être redirigé vers OpenEdition Search