Stratégie de conception des systèmes d'information (H5170).pdf

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Informatique H 5 170 − 1
H
5
170
6
-
1994
Stratégie de conception
des systèmes d’information
par Pascal SILVESTRE
Ingénieur en Chef société SOPRA
et Didier VERLHAC
Senior Consultant société KRYSTAL
es dernières années, les technologies informatiques sont en évolution
permanente :
— des ordinateurs encore plus puissants, des rapports coûts/performances en
constante amélioration, des instruments de dialogues avec l’homme de plus en
plus évolués sont des aspects contribuant au succès de l’informatique, devenue
aujourd’hui accessible à tous les publics ;
— plus de métiers couverts grâce à l’apparition de nouvelles techniques
(multimédia, multimodal, bases de données réparties, ...) ;
1. Construction d’un système d’information........................................ H 5 1 70 - 2
1.1 Définition...................................................................................................... — 2
1.2 Contexte de construction............................................................................ — 2
2. Stratégie de conception......................................................................... — 6
2.1 Enjeux........................................................................................................... — 6
2.2 Activité de conception................................................................................. — 6
2.3 Problématique.............................................................................................. — 6
2.4 Approches .................................................................................................... — 7
2.5 Difficultés de la conception......................................................................... — 7
2.6 Étapes contribuant à l’activité de conception ........................................... — 8
2.7 Méthodes dans la stratégie......................................................................... — 8
3. Méthodes.................................................................................................... — 9
3.1 Besoin d’un cadre méthodologique........................................................... — 9
3.2 Qu’est-ce qu’une méthode ?....................................................................... — 9
3.3 Principes....................................................................................................... — 9
3.4 Intégration dans l’entreprise....................................................................... — 10
4. Panorama des méthodes de conception ........................................... — 11
4.1 Émergence des méthodes .......................................................................... — 11
4.2 Panorama actuel.......................................................................................... — 12
5. Nouveaux besoins, nouvelles tendances .......................................... — 16
5.1 Émergence de nouveaux besoins .............................................................. — 16
5.2 Réponses...................................................................................................... — 16
5.3 Tendances..................................................................................................... — 21
5.4 Sujets de recherche et perspectives .......................................................... — 21
6. Annexe : modèles conceptuels ............................................................ — 22
6.1 Modèles sémantiques ................................................................................. — 22
6.2 Modèles comportementaux........................................................................ — 22
6.3 Modélisation ................................................................................................ — 23
Références bibliographiques ............................................................. — 23
C

STRATÉGIE DE CONCEPTION DES SYSTÈMES D’INFORMATION ________________________________________________________________________________
H 5 170 − 2 © Techniques de l’Ingénieur, traité Informatique
— des outils pour réaliser les logiciels toujours plus sophistiqués et adaptés,
contribuant ainsi à améliorer leur qualité en masquant de plus en plus les tech-
niques de base.
Cependant, des domaines qui devraient, en toute logique, être les précurseurs
de ces évolutions, ne font que s’y adapter. La conception des Systèmes d’Informa-
tion en est l’exemple le plus marquant.
Par ailleurs, s’il existe actuellement une multitude de moyens pour décrire les
systèmes conçus, il reste une rupture entre :
— l’expression du besoin et la conception de la solution ;
— la conception de la solution et sa fabrication.
Il n’existe encore aujourd’hui aucun moyen pour garantir que l’on fabrique
tout ce qui a été conçu, et rien que cela, et que les produits de la conception
répondent à 100 % des besoins exprimés.
Bien que le concepteur s’en défende, les outils qu’il utilise sont orientés vers
ceux de réalisation et d’exploitation. Son activité s’en trouve dès lors dégradée.
La seconde rupture citée devrait s’en trouver supprimée, mais des antagonismes
culturels et organisationnels viennent l’accentuer.
De nombreuses méthodes, dont certaines seulement se sont imposées en
France (Merise, SADT), doivent aujourd’hui intégrer les évolutions techno-
logiques.
Les tentatives pour intégrer la conception dans le cycle d’informatisation sont
nombreuses, mais il semble manquer une véritable théorie unifiée dont la
conception serait l’un des maillons.
Ces constatations nous ont amenés à faire un point objectif sur ce qu’est
l’activité de la conception au début des années 90, sur son rôle dans l’entre-
prise et son impact sur le Système d’Information, en insistant particulièrement
sur son support principal : les méthodes.
Cet article présente le panorama le plus large possible des méthodes utilisées
au niveau national, guidé par les tendances passées, actuelles et futures les
plus marquantes.
Les outils d’aide à la conception ne seront qu’abordés. S’ils constituent un
support pour le concepteur, ils ne sont pas une aide à l’activité de conception.
De même, nous ferons référence aux aspects organisationnels, qualité, gestion
de projet et pilotage, lorsque cela peut éclairer la compréhension générale du
sujet.
1. Construction d’un système
d’information
1.1 Définition
Avec l’émergence des moyens informatiques, les organes
décisionnels des entreprises souhaitent construire et faire vivre un
système maîtrisé dans le fonctionnement duquel l’information joue
un rôle prépondérant. Ce système dit Système d’Information (SI) est
à l’origine de l’automatisation des activités de l’entreprise.
Le SI est à la fois passif en tant que base d’informations de l’entre-
prise et actif par les règles de gestion qu’il leur applique.
La composante informatique du SI l’enrichit d’un ensemble de
procédures d’acquisition, transformations, stockage et recherche de
données pertinentes, représentatives de la réalité.
Il doit être perçu comme le reflet de l’entreprise et de son fonction-
nement sous réserve des simplifications nécessaires éventuelles à
des fins d’exploitation. Il n’intègre pas les composantes sociales,
culturelles et relationnelles de l’entreprise.
1.2 Contexte de construction
1.2.1 Projet de développement
Un projet se déroule dans le temps en une ébauche qui exprime
des concepts, une première étude donnant un cahier des charges
établi à partir de plusieurs scénarios et donnant son périmètre, une
contractualisation après acceptation, son développement et son
achèvement après recette pour conformité, généralement sous
forme d’une période de garantie.
Le projet est décomposé en une série d’étapes selon une démarche
qui part du besoin pour aboutir au produit fini qu’est le système
informatique. La notion de cycle représente l’itération des projets
dérivant des nouveaux besoins engendrés par le système développé.

________________________________________________________________________________ STRATÉGIE DE CONCEPTION DES SYSTÈMES D’INFORMATION
Un projet induit des aspects organisationnels, humains, tech-
niques, spatio-temporels et de qualité qui agissent et interagissent
tout au long de son déroulement. Si la qualité implique trois plans :
production, management, contrôle, seul le plan de production fait
l’objet de cet article.
La partie développement d’un projet suit un cycle similaire au
projet lui-même, avec la notion de sous-projets si sa dimension
l’impose. Ces derniers sont verticaux et correspondent à une brique
du projet, ou horizontaux et sont vus comme le ciment du projet.
Le projet est donc composé d’une hiérarchie de cycles récursifs
avec, au sommet, la détermination de son lancement via une étude
de faisabilité globale (figure 1).
Dans le cadre, par exemple, de la phase de développement d’un
projet de construction d’un SI conçu suivant le modèle client-serveur,
l’étape de réalisation consiste à fabriquer des composants centraux
et locaux, ainsi que les moyens de les faire communiquer. Le sous-
projet de construction des moyens de communication suit lui-même
une démarche passant par une expression des besoins dont le
demandeur est le concepteur du SI, des spécifications, une étape
de conception puis de réalisation.
Le déroulement de la phase de développement du projet s’inscrit
dans un cadre structurant représenté par des modèles dont le
premier a été proposé par Royce au début des années 70. Depuis,
de nombreux modèles ont été élaborés reprenant l’esprit décrit
précédemment.
Le cycle en V proposé par Golberg est le plus traditionnel et le
plus utilisé actuellement (figure 2). La première branche du V pro-
pose une démarche descendante de l’expression du besoin au
développement de la solution. La seconde branche est une démarche
ascendante partant d’une unité élémentaire de développement et
aboutissant au produit expression de la solution. Il intègre toutes
les unités de développement testées, vérifiées, validées et certifiées.
Le modèle de la cascade, proposé par Boehm en 1975, représente
une démarche descendante de la définition/spécification jusqu’à la
réalisation. Chaque phase est reliée à la suivante par un lien d’enchaî-
nement indiquant la démarche descendante et par un lien de retour-
arrière représentant les corrections. À chaque étape est associée une
phase de vérification/validation (figure 3).
Nous n’avons pas tenu compte jusqu’ici des coûts de fonction-
nement et de maintenance. Pour des grands SI, ces coûts excèdent
ceux de développement d’un facteur de 2 à 4 (Boehm), la plus grande
partie étant imputable aux changements dans les besoins exprimés.
Figure 1 – Cycles d’un projet
Figure 2 – Cycle en V

Cela a conduit, en 1982, Mac Cracken et Jackson à suggérer le
remplacement de ces modèles par un modèle plus évolutif basé
sur l’idée que l’utilisateur doit avoir dès que possible un prototype
permettant une première expérimentation. Le modèle de la spirale
de Boehm (figure 4) [14] traduit cette évolution par un cycle de
développement récursif à 4 phases :
— la détermination des objectifs, des choix et des contraintes ;
— l’analyse des risques et l’évaluation de la solution par création
d’un prototype ;
— le développement et la vérification du produit relatif au niveau
en cours ;
— la planification des phases suivantes.
Golberg a fait évoluer le cycle en V en y intégrant la notion de
maquette/prototype. Il précise, dès le début du cycle en W, la spéci-
fication des interfaces et permet de vérifier immédiatement la
cohérence avec les spécifications du besoin (figure 5).
D’autres éléments volontairement omis concernent, par exemple,
la conduite de projet et la planification qui, comme nous l’avons déjà
précisé, sont en dehors du périmètre des sujets traités dans cet
article.
Quel que soit le type de modèle utilisé, la phase de développement
d’un projet s’inscrit dans un milieu caractérisé par des facteurs qui
auront une incidence sur la stratégie de conception à mettre en place.
En fonction des valeurs de ces facteurs, le projet est considéré à
risque ou non, réalisable ou non, pertinent ou non. Nous l’illustrons
par des valeurs extrêmes de certains de ces facteurs : (0)
1.2.2 Facteurs contextuels
1.2.2.1 Environnement
L’environnement peut être mal structuré dans les domaines
n’ayant fait l’objet d’aucune informatisation ou d’une informatisation
partielle. Le projet de développement passe alors par des projets
préliminaires (schéma directeur, par exemple) ayant pour objectif de
définir les orientations générales du nouveau SI après avoir restruc-
turé l’ancien. Faire un schéma directeur impose une démarche struc-
turée s’appuyant sur une méthodologie (Racine, par exemple)
permettant d’extraire les données essentielles du futur SI et les
règles de gestion importantes en les organisant par domaines infor-
mationnels.
L’entreprise peut posséder plusieurs implantations géographiques
de développement, internationales ou non, pouvant imposer une
cohérence de l’ensemble des produits de conception dans des
contextes culturels différents.
Facteurs
Incertitude
faible élevée
Besoin bien exprimé mal exprimé
Système existant très structuré peu structuré
Taille système petite importante
Expérience des utilisateurs expertise limitée
Qualité concepteur excellente faible
Figure 3 – Modèle de cycle en cascade
Figure 4 – Modèle de cycle en spirale

Autre exemple, une évolution de l’activité de l’entreprise peut créer
un écart important entre les activités informatisées et le besoin d’un
nouveau SI.
1.2.2.2 Importance du SI
Celle-ci influe sur le contenu de la démarche mise en œuvre pour
la conception et se décline en fonction de deux facteurs :
— le volume des objets mis en jeu ;
— l’impact du projet concerné sur les résultats de l’entreprise.
Les moyens mis en œuvre, les produits résultants demandés,
l’approche qualité (diminuer le plan de management au profit du plan
de production) sont, par exemple, des éléments variables dans les
différents projets au sein d’une même entreprise.
Dans un petit projet, il est permis que certains éléments de l’activité
de conception soient supprimés ou que certains produits résultants
soient simplifiés.
Les fréquences d’utilisation, le nombre des utilisateurs concernés,
le nombre de sites impliqués, etc. sont aussi des éléments d’échelle
permettant d’économiser sur la conception sans en dégrader les
résultats.
1.2.2.3 Expérience des concepteurs
Experts dans un domaine, les concepteurs peuvent être peu
réceptifs aux évolutions (la technologie objet, par exemple). Multi-
compétents, ils peuvent n’être experts dans aucun domaine. Par
ailleurs, un concepteur chevronné peut sciemment (après accepta-
tion) omettre délibérément certains points dans une étape, ce qui
n’est certes pas recommandé pour un jeune concepteur.
Cette expérience est donc liée à la technicité mise en œuvre pour
la conception, mais également à la connaissance du concepteur de
l’entreprise et en particulier du SI existant. Celle-ci peut l’amener à
effectuer des choix implicites ou à éviter des voies culturellement
incompatibles avec l’entreprise.
Le métier du concepteur intègre également une composante
moins technique liée à la gestion de la démarche qu’il suit et des
ressources qu’il gère.
Dans ce domaine, l’expérience est un atout qui permet d’éviter
les pièges comme les écarts de charges ou de délais ou les dérives
par rapport aux objectifs fixés contractuellement par le projet. Des
mesures d’écart doivent être prises tout au long du projet pour réagir
au plus tôt et non pas en fin de phase ou en validation.
1.2.2.4 Coûts et délais
Les délais sont souvent un facteur prédominant, puisqu’ils sont
généralement liés à la réactivité de l’entreprise sur son marché. Leur
influence s’accroît avec le taux d’avancement du projet et donc avec
les coûts réellement engagés.
Ce type de facteur contribue à une simplification de la démarche
de conception qui peut s’avérer fatale pour le projet. L’ajout de
ressources humaines, par exemple, pour tenter d’accélérer le pro-
cessus est généralement un calcul qui s’avèrera trop coûteux par
rapport aux gains réels.
1.2.2.5 Type de projet
Les systèmes transactionnels, statistiques, d’aide à la décision, de
production, etc. mettent en jeu des techniques différentes qui
nécessitent des moyens et des ressources variés. La problématique
s’accentue lors de combinaisons des systèmes et d’ajout de critères
comme la localisation : systèmes centralisés ou distribués.
1.2.2.6 Outils
Les outils disponibles sur le marché, déjà très nombreux, sont de
niveaux de sophistication variables. Ils tentent de faciliter les repré-
sentations graphiques ou textuelles et automatisent certaines tâches
(génération, etc.). Cependant, aucun n’apporte une solution univer-
selle.
Les outils sont liés à un ou plusieurs cycles de développement,
à une ou plusieurs méthodes et, s’ils sont « ouverts », c’est au
concepteur de définir et d’y introduire des spécificités contextuelles
généralement liées aux normes et standards retenus pour l’entre-
prise.
Ils recueillent les informations des produits de la conception
dans un dictionnaire ou un référentiel. En termes de maîtrise du SI,
cet aspect est essentiel et les outils apportent là une aide véritable
quant à la connaissance de son contenu informationnel.
Cependant, ils donnent une vision statique du SI sans pouvoir en
montrer les évolutions passées et futures. Les justifications des choix
et des tendances restent encore des notions purement intellectuelles
et les outils n’apportent pas d’aide véritable dans la définition de
la stratégie informatique de l’entreprise.
1.2.2.7 Existant
Les outils aidant à la construction du SI deviennent une contrainte
dès lors qu’ils sont déjà utilisés. Les faire évoluer n’est pas toujours
possible et les remplacer implique souvent des coûts de migration
dépassant largement les enjeux. Les choix d’outils faits à un instant
donné deviendront naturellement une contrainte de l’existant dans
le futur.
La stratégie de la conception doit donc intégrer des contraintes
à long terme et il est souvent plus pertinent de retarder le choix d’un
outil, plutôt que d’en imposer un qui aura une durée de vie limitée.
Si, en revanche, le besoin de changer les outils est une nécessité
(technologie obsolète, fournisseur n’assurant plus l’évolution, etc.),
l’entreprise doit chercher des solutions où l’existant est reconduit
et intégré. Cela l’amènera souvent à développer ou faire développer
des outils spécifiques de migration. Si cela n’est pas possible, elle
devra gérer deux SI, l’un représentatif du passé et qu’il faudra faire
vivre, l’autre en partie redondant avec le premier.
L’existant se mesure également en terme de taux d’activités déjà
automatisées. En fonction de son importance, le processus de
conception le prend en compte ou non de manière à aboutir soit à
une évolution, soit à une refonte.
La qualité de cet existant (niveau de la documentation, nombre
d’experts dans les domaines concernés, ...) vient moduler sa prise
en compte lors de la conception de manière à éviter les écarts entre
ce que l’on croit que fait le SI et ce qu’il fait réellement. On évite
de s’attarder sur le comment il le fait en l’intégrant dans le processus
de conception.
Figure 5 – Modèle de cycle en W

2. Stratégie de conception
2.1 Enjeux
La stratégie de la conception dans l’entreprise définit l’ensemble
des ressources et leur organisation globale nécessaires à la mise
en œuvre de l’activité de conception. S’agissant du SI de l’entreprise,
élément majeur de son fonctionnement, voire son outil de produc-
tion, les choix stratégiques de conception sont faits par les organes
décisionnels : direction générale ou instance responsable de
l’ensemble des acteurs impliqués dans le processus de conception.
L’élargissement à d’autres acteurs de l’entreprise est indispen-
sable pour intégrer son contexte général, qu’il soit technologique
ou organisationnel. La conception est un sous-ensemble du cycle
de construction d’un SI et son activité reçoit des flux déclencheurs
en amont et des contraintes en amont ou en aval.
La stabilité des choix, au regard des enjeux fixés, est incontesta-
blement l’élément le plus critique vis-à-vis de la maîtrise à long terme
du SI et de ses évolutions. Le changement des repères induit auto-
matiquement une modification des perceptions de la réalité (igno-
rance du pourquoi, par exemple). De même, la modification des
moyens de production (outils de conception ou d’aide à la conception
au sens large du terme) désorganise l’existant et déstabilise ainsi
la base des évolutions du SI. La définition des moyens dédiés à la
conception engage l’entreprise dans un processus continu de crois-
sance interdisant les remises en cause intempestives. La culture de
l’entreprise se positionne comme le garant de la pertinence des choix
et de leur acceptation générale.
Dans l’activité de conception, tous les acteurs participent à la
même activité à des niveaux décisionnels, de responsabilité et
opérationnels différents. Leurs rôles dans l’entreprise sont différents
et chacun d’eux doit donc posséder des outils adaptés et commu-
niquant de manière naturelle en s’appuyant sur des normes et des
standards, produisant ainsi des résultats compréhensibles par tous.
2.2 Activité de conception
L’activité de la conception (figure 6) s’intègre dans le contexte
organisationnel général de l’entreprise et fait appel dans son proces-
sus complet à des acteurs différents :
— le demandeur ;
— le concepteur ;
— le réalisateur ;
— le bénéficiaire.
L’activité de conception est réalisée dans un processus contractuel,
modélisé par une succession d’étapes enrichissant de manière
formelle la nature et le contenu des informations issues de l’expres-
sion du besoin pour aboutir à une représentation proche de l’infor-
matique.
Chaque étape du processus s’appuie sur :
— l’abstraction qui fabrique des vues externes exprimant le quoi
faire ;
— la traduction qui aboutit à des vues internes exprimant le
comment cela sera fait ;
— le contrôle, la validation, la décision.
La maîtrise du sujet par le concepteur qui n’est pas le demandeur,
la dimension croissante des sujets à traiter, les moyens techniques,
organisationnels et budgétaires imposés par le contexte de
l’existant, la diversité des méthodes, des techniques et des moyens
à mettre en œuvre sont autant d’aspects qu’il faut maîtriser avant
de démarrer un processus de conception.
2.3 Problématique
Si le processus mental de la conception est propre à chaque indi-
vidu en fonction de son expérience, de sa fonction, de sa perception
des objectifs à atteindre et de ses affinités culturelles, le résultat pro-
duit doit être neutre vis-à-vis de ces différences, d’où la nécessité
de canaliser chaque acteur dans une démarche structurée, mais
surtout structurante.
La maîtrise des résultats de la démarche est obtenue par la défini-
tion de plans de production décrivant les moyens organisationnels
pour gérer, suivre et contrôler les étapes de l’activité de conception
et leurs produits résultants.
La tactique à suivre définit les moyens nécessaires à chaque acteur
pour réaliser chaque tâche : méthodes, outils de modélisation, créa-
tion d’un prototype, d’une maquette, etc.
Tout projet suit une tactique définie dans la stratégie et régie par
des contraintes contextuelles et ses propres objectifs.
Chaque projet de fabrication d’un composant du SI utilise tout ou
partie du cadre méthodologique sans altération de ses composants.
Seules la dimension ou la complexité d’un projet, la diminution ou
la multiplication des composants à automatiser de l’entreprise
peuvent amener soit à réduire le champ d’application des moyens
à utiliser, soit à l’élargir. Dans ce dernier cas, il s’agit d’une évolution
de la stratégie de conception. Elle reste alors locale au projet
concerné ou est intégrée au contexte général de l’entreprise pour
les projets futurs.
Les évolutions des composants tactiques de la conception sont
induites par des changements technologiques (modèle client-
serveur par exemple) ou des évolutions des standards ou normes
du marché (méthode Merise-CASC par exemple). Les choix straté-
giques de conception doivent donc intégrer cette quasi-certitude de
survenance de modifications des moyens tactiques à employer.
Pour élaborer sa stratégie de la conception, l’entreprise s’appuie
sur des facteurs qui reposent sur les réponses à des questions dont
les principales sont les suivantes :
— existe-t-il réellement des approches différentes par les visions
et la matière qu’ils manipulent pour concevoir son SI ? ;
— si la réponse est positive, ces approches sont-elles similaires ? ;
— doit-on suivre des approches différentes en fonction de son
type ? ;
— dans ce cas, quelles sont-elles ?
Toutes ces questions concourent à définir une stratégie qui aide
les concepteurs à se poser les bonnes questions au bon moment
afin qu’ils puissent réaliser le produit de leur conception dans les
meilleures conditions.
Figure 6 – Activité de conception

2.4 Approches
L’activité de conception est réalisée dans un contexte structurant,
communicant et normatif.
Les axes majeurs à définir en priorité pour fabriquer ce contexte
sont les suivants :
— la vision qu’a l’entreprise de son SI qui détermine l’approche
générale du processus de conception ;
— la démarche à suivre, cohérente avec l’organisation, qui déter-
mine la topologie des projets.
Le premier axe s’inscrit dans le cadre de la structuration du proces-
sus mental de conception, en imposant des directions de réflexion
et des moyens de présenter les résultats (modélisation). Il s’agit, par
exemple, des approches privilégiant :
— la vision par les données : la modélisation des données gérées
est primordiale, les règles de gestion viennent alors s’appliquer à
ces données : c’est la dynamisation d’une vision statique ;
— la vision par les traitements : la modélisation concerne d’abord
les procédures de gestion des activités de l’entreprise, leurs acteurs,
puis les informations gérées ;
— la vision par les événements : la modélisation s’appuie d’abord
sur la manière dont les procédures de gestion des données sont
déclenchées et leur séquencement dans le système ; elle est centrée
sur la dynamisation des données et leur évolution ;
— la vision par les flux : la modélisation décrit en priorité la
manière dont les procédures de l’entreprise s’échangent des
informations ;
— la vision par les modèles décisionnels : la modélisation prend
en compte en priorité les besoins en information des responsables
ou des acteurs de chaque activité de l’entreprise.
Il faut entendre ici par procédure toute action, automatisée ou non,
contribuant à l’activité de l’entreprise. Ce terme prend des significa-
tions spécifiques aux méthodes qui l’utilisent, que nous avons volon-
tairement ignorées.
Quel que soit le type d’approche, le résultat final exprimé dans
sa représentation spécifique décrit globalement quelles sont les
données gérées, par qui, quand, comment (comment les produire,
les modifier, les restituer, les détruire) et où. Entre toutes les
approches possibles, seuls les moyens d’obtenir le résultat et son
formalisme diffèrent.
L’objet du SI détermine le choix pertinent de l’approche à suivre.
Les éléments suivants sont des exemples de critères qui influent sur
ce choix ainsi que les moyens utilisés pour mener à bien l’activité
de conception :
— système centralisé ou réparti ;
— système temps réel ou non ;
— taux du transactionnel/batch ;
— taux des données volatiles/données permanentes ;
— taux des événements pouvant être gérés ou non ;
— règles de gestion complexes/moyennes/simples ;
— interface passive/active ;
— système historisant ou non les données ;
— nombre de données dans le système ;
— culture méthodologique de l’entreprise ;
— importance de la qualité de l’information par rapport aux règles
de gestion.
Ces questions sont rassemblées dans des tableaux à destination
des organes décisionnels et garantissent un choix objectif et non
pas intuitif.
Celles-ci sont alors complétées par des informations relatives
aux outils à mettre en œuvre dans le processus de conception et
aux acteurs disponibles de l’entreprise en précisant leur fonction et
leur rôle.
En fait, les réponses sont conditionnées par le métier de l’entre-
prise (tertiaire, industrie, ...) et par l’importance du rôle du SI dans
l’entreprise (outil de production ou de gestion). Cela peut l’amener
à faire le choix de plusieurs méthodes, chacune d’elles étant adaptée
à un SI ou la composante d’un SI.
L’enjeu du projet, quant à lui, vient moduler le taux d’utilisation
des instruments de la méthode en appliquant ou non l’ensemble des
étapes de la démarche associée. Les moyens alloués au projet ne
doivent pas être un critère de modulation. C’est, au contraire, en fonc-
tion de ses enjeux que les moyens doivent être définis (essentielle-
ment en termes de budget, de planning et de priorités) dans le plan
de production.
Ces moyens décrivent nécessairement le contexte défini pour la
stratégie générale de la conception. Si, par exemple, dans l’organisa-
tion prévue pour les projets, le rôle de l’administrateur des données
est clairement indiqué comme incontournable, celui-ci devient une
constante sur l’ensemble des projets, quelle que soit leur importance
(enjeu ou dimension).
Ils participent tous, à leur échelle, à la mise en place des éléments
constituant le SI et doivent donc respecter les mêmes règles.
N’oublions pas que le SI constitue une grande part de la mémoire
de l’entreprise et que de son homogénéité dépend sa compréhension
future par des acteurs nouveaux.
Le deuxième axe s’inscrit dans la démarche générale suivie pour
les projets. Par exemple, le choix d’un cycle en spirale impose la
présence d’un outil de prototypage et un circuit d’information et un
cycle de décisions particuliers.
L’étude de ces axes induit automatiquement un choix de
composants méthodologiques pertinents en termes de méthodes de
conception, d’outils, de méthodes de planification et d’organisation,
par exemple.
Les composants méthodologiques sont directement liés au rôle
du SI dans l’entreprise, de son importance en termes de dimension
et du nombre et du type des acteurs que l’on peut impliquer dans
sa construction. Cependant, un SI est en constante évolution et, dès
lors que l’on définit les éléments stratégiques de sa conception, il
faut prévoir ses procédures de révision de manière à éviter les
bouleversements (souvent traduits par un gel de l’activité de concep-
tion) lors d’un changement issu des résultats d’un schéma directeur,
par exemple.
2.5 Difficultés de la conception
Une bonne conception doit intégrer la réponse à la question
générale suivante.
Comment procéder pour aboutir, dans un temps et pour un coût
donnés, à un produit fini et utilisable, répondant à la requête du
demandeur et respectant des critères de qualité définis ?
Il est alors aisé de percevoir la difficulté d’obtenir la bonne réponse
et, par voie de conséquence, d’appréhender la complexité du travail
des concepteurs.
Cette complexité se décline suivant quatre aspects :
— la maîtrise du sujet : le concepteur est différent du demandeur ;
il faut ou connaître le domaine du client ou apprendre à le connaître ;
— la diversité des méthodes, techniques et moyens à mettre en
œuvre : il faut maîtriser les nombreux constituants de la conception
et de la réalisation ;
— l’accroissement de la dimension du sujet à traiter : celle-ci
nécessite non pas un individu mais une équipe induisant des
problèmes de gestion, de coordination, de communication, de
ressources humaines et de planification ;
— le contexte qui demande l’intégration ou non de l’existant et
impose les moyens mis à disposition (techniques, organisationnels,
budgétaires).

Il suffit que l’un des aspects soit déficient pour que le produit de
la conception soit inadéquat aux objectifs et contraintes fixés
(respects des critères de qualité). Les engagements pris dans le
contrat fournisseur/client ne seront alors pas respectés.
L’activité de conception est une activité humaine complexe et
faillible qui aboutit à une solution qui, bien qu’elle résulte souvent
de transformations, nécessite une part importante de créativité. Le
concepteur doit être capable d’apporter des idées adaptées à la
solution du problème/manque.
2.6 Étapes contribuant
à l’activité de conception
Nous situons l’activité de conception dans le contexte d’un projet
de développement informatique et étudions la stratégie à adopter
qui, comme nous le verrons, nous amènera à un cadre méthodo-
logique.
Dans la stratégie globale de la mise en œuvre de la conception,
il est nécessaire de prévoir également les moyens à mettre en place
pour évaluer la charge réelle des projets, les délais réalistes face à
cette charge, les moyens de contrôler leurs dérives et les procédures
correctives si nécessaire.
2.6.1 Expression du besoin utilisateur
L’expression du besoin consiste à décrire dans un formalisme
compréhensible par l’informaticien les objectifs réels et précis du
projet. Réalisée par les utilisateurs du SI, cette étape est menée en
collaboration avec les concepteurs.
Nous insistons sur la réalité des objectifs, qui doit faire l’objet
d’une étude particulière. Le rôle du concepteur doit être à la fois
critique, novateur et stratégique. Les réponses aux questions
suivantes, par exemple, seront la clé d’un projet réussi :
— le besoin n’est-il pas déjà couvert en totalité ou en partie ? ;
— ses enjeux justifient-ils le développement d’un projet ? ;
— le projet est-il justifié économiquement ? ;
— quel est le degré d’urgence de mise à disposition de la
solution ? ;
— quelle sera la pérennité de la solution ? ;
— n’y a-t-il pas des réponses sur le marché et si oui à quelles
conditions ? ;
— une solution est-elle réalisable dans les conditions actuelles et
si non quand le sera-t-elle, ou que faire pour qu’elle le devienne ?
Dans le cadre de la stratégie de la conception, il est donc essentiel
de définir clairement, voire de manière contractuelle, le rôle de
chaque acteur en insistant sur son niveau de décision.
Une informatique seulement exécutante risque de perdre son
efficacité en développant des systèmes marginaux face aux enjeux
de l’entreprise et en sacrifiant des moyens utiles aux éléments straté-
giques.
En revanche, une informatique trop décisionnaire provoquerait
un risque d’insatisfaction des utilisateurs, une perte de confiance
dans cette informatique et la possibilité de voir se développer des
systèmes parallèles non maîtrisés, incohérents et redondants.
Un arbitrage est nécessaire en fin d’étape pour convenir de la
continuation du projet, de la révision de ses objectifs ou sa poursuite
en l’état.
Les moyens généralement utilisés pour analyser le besoin
s’appuient sur une modélisation de type réseaux sémantiques qui
permettent d’éliminer les faux sens et contresens, les redondances
et les non-dits. Cependant, seuls l’expérience, le niveau d’expertise
et la personnalité des intervenants garantissent un résultat ne
laissant ni ambiguïté ni lacune face au manque à combler ou au pro-
blème à résoudre.
2.6.2 Spécification
La spécification du SI ou de ses composants est l’une des étapes
les plus importantes du cycle de vie. Elle décrit ce que le système
doit faire en faisant complète abstraction du comment le faire, en
couvrant 100 % du besoin. Elle peut cependant intégrer une étude
de faisabilité sur des parties du système à fabriquer, sachant qu’une
étude de faisabilité globale a déjà dû être effectuée.
Dans le cas des grands projets, le besoin peut n’être couvert qu’à
80 % en fonction des priorités et des enjeux. Les 20 % restants seront
intégrés de manière naturelle dans les étapes déclenchées si le coût
reste marginal ou si un gain réel est dégagé, ou reportés dans le
cadre de projets ultérieurs.
Très subjective, cette étape est aussi la plus créative en restant
exclusivement intellectuelle. Elle s’appuie cependant sur deux
réalités : l’existant et ses contraintes.
Les moyens mis à disposition de l’étape sont liés aux axes et aux
composants méthodologiques de conception choisis (modélisation
statique ou dynamique, type de cycle, ...).
L’étape consiste à décrire les premiers niveaux de modélisation
de manière macroscopique. Il faut noter qu’à ce niveau grand
nombre d’informations sont encore soit inconnues, soit imprécises.
Les représentations y sont généralement pour la plupart informelles
(textes, ...).
Les résultats de l’étape constituent le cahier des charges pour le
développement de la solution. C’est à ce niveau que sont définis les
critères, facteurs et moyens de mesure à mettre en place pour
contrôler la qualité des produits de la conception.
2.6.3 Conception informatique
La conception consiste à donner les éléments permettant aux
techniciens (les réalisateurs) de développer et de mettre en place
une architecture matérielle et des logiciels.
En entrée, le concepteur dispose du résultat des étapes décrites
précédemment. Son rôle est de :
— décrire le comment réaliser ce qui a été spécifié non pas en
termes de moyens ni de démarche mais en termes de résultats à
produire ;
— supprimer les imprécisions et rechercher les informations
manquantes ;
— définir les moyens de tester la solution développée.
Il passe progressivement à une représentation de plus en plus
formelle, à des niveaux de structuration plus proches de ceux des
objets informatiques qu’il faudra utiliser ou développer.
Le concepteur dispose de l’ensemble des moyens tactiques définis
dans la stratégie de conception : méthodes, outils, normes et
standards, documentation de l’existant et inscrit son activité dans
un cadre organisationnel défini et figé.
2.7 Méthodes dans la stratégie
Dans le cadre de cet article, seul l’aspect méthode sera abordé
en gardant à l’esprit qu’il ne s’agit là que d’une facette de la stratégie
de conception, facette importante puisqu’elle est structurante,
communicante et normative. Le choix des méthodes est directement
lié au rôle du SI dans l’entreprise, de son importance en termes de
dimension et du nombre et du type des acteurs impliqués dans sa
construction.

Trois grands types de méthodes sont utilisés actuellement :
— méthodes du marché (générales et non spécialisées) respec-
tant des normes publiées (ISO, IEEE, ...) ;
— méthodes adaptées par l’entreprise à partir de celles du marché
pour intégrer ses contraintes culturelles (générales et spécialisées) ;
— méthodes construites par l’entreprise à partir de son expérience
et de ses plans d’informatisation (spécifiques et très spécialisées).
L’expérience montre que les plus couramment utilisées sont celles
du type 2. Adaptées au contexte de l’entreprise, elles sont moins
coûteuses en investissement et évolutions et donc en coûts induits,
puisqu’elles influent moins sur la réactivité de l’entreprise que celles
du type 3.
Bien souvent, le choix des outils viendra altérer les composants
de la méthode choisie, quel que soit son type, par ajout, modification
ou suppression de concepts. Notons que ce ne sont pas les outils
qui doivent définir le périmètre de la méthode.
3. Méthodes
3.1 Besoin d’un cadre méthodologique
Ce cadre méthodologique a pour objectif de :
— substituer à la construction empirique et individuelle des SI une
conception rigoureuse ordonnée et concertée sur une coopération
efficace entre concepteurs, utilisateurs et réalisateurs ;
— maîtriser la complexité du système informationnel ;
— évaluer les produits de la conception pas à pas en vérifiant
leur capacité à satisfaire le besoin exprimé ;
— réduire les coûts et les délais ;
— accroître la productivité et la qualité des développements.
Une méthodologie a pour but d’aider l’organisation à mieux
maîtriser les activités relatives à la conception et au développement
des solutions.
Par exemple, une méthodologie de conception exprime plus
particulièrement le cheminement par étapes successives de satisfac-
tion d’un besoin pour arriver au produit de conception. Pour ce faire,
elle peut utiliser un ensemble cohérent de méthodes. La méthodo-
logie de développement de systèmes SDM/S est un cas typique qui,
par exemple, applique la méthode Merise.
3.2 Qu’est-ce qu’une méthode ?
3.2.1 Définition
Une méthode définit les informations à produire pour déclencher
le processus de réalisation, le formalisme de présentation et les
informations nécessaires au démarrage d’une tâche de conception.
La démarche liée à la méthode décrit, quant à elle, l’organisation
du projet mettant en œuvre la méthode à travers un plan de produc-
tion propre au projet concerné.
Une méthode recouvre plusieurs notions correspondant à une
démarche, un guide dans l’approche des problèmes de construction
des SI.
La démarche est constituée d’un ensemble de règles, conseils,
critères et séquences de décision. Elle s’appuie sur des techniques
de représentation.
Cette démarche est à la fois rationnelle et empirique. Elle s’appuie
d’une part sur l’observation et l’analyse et, d’autre part, sur des
concepts issus généralement de la technologie.
Une méthode a au minimum trois composants :
— des modèles ; un modèle est une interprétation explicite de la
compréhension d’une situation ou de l’idée que s’en fait le concep-
teur sous forme de symboles et de mots ;
— des langages : un langage est un ensemble de constructions
logiques puisant dans le langage naturel ou dans un langage formel
qui permet de décrire le produit de conception ;
— une démarche : une démarche est le processus opératoire
grâce auquel s’effectue le travail de modélisation et de description
du SI.
Un quatrième composant peut se greffer : les outils supports de
la méthode. En général, des compléments y sont apportés dans le
formalisme d’expression de la méthode.
Une méthode ne décrit pas une solution, mais comment aboutir
au résultat. Elle se concrétise par un modèle de réflexion exprimant
comment procéder pour spécifier et concevoir.
Une méthode est dépendante de la nature de la solution à trouver
(temps réel, gestion, productique, ...) et par conséquent du résultat
à produire (normes et standards, programmes, ...).
3.2.2 Modèles
Pour aboutir à un produit de conception, il est indispensable de
communiquer ce qui est conçu à chaque étape de la conception au
demandeur, au réalisateur voire au bénéficiaire pour examen et
approbation. Le support de communication contractuel utilise une
technique de représentation structurée par modèles.
Un modèle sert à décrire visuellement un système qui deviendra
réalité après sa conception ou la conception de ses évolutions s’il
existe déjà.
Un modèle possède des qualités d’abstraction, décomposition,
lisibilité. Les modèles sont regroupés dans quatre grandes caté-
gories [15] :
— les modèles conceptuels, basés sur l’emploi de symboles pour
la représentation des aspects quantitatifs (cardinalités, ...) et qualita-
tifs (sous-types, ...) s’appliquant à des symboles d’identification ;
— les modèles analytiques, basés sur l’utilisation de relations
mathématiques et logiques pour représenter les lois physiques du
comportement ; ils sont utilisés comme moyen pour prévoir, évaluer
et valider le comportement de différents aspects d’un objet ; ces
modèles permettent de différencier les comportements prévisibles
dans le temps des comportements incertains ;
— les modèles iconiques, qui sont des reproductions en minia-
tures d’objets physiques comme des véhicules, bâtiments afin de
faire des études en soufflerie, des études sismiques ou autres ;
— les modèles analogiques, qui exploitent une apparence
physique différente de l’objet à caractériser à des fins de simulation,
par exemple, un réseau électrique simulant un moteur ou un réseau
hydraulique.
La modélisation fait appel d’abord aux modèles conceptuels puis
analytiques.
Les modèles analytiques peuvent s’appuyer sur les modèles
iconiques et analogiques afin de vérifier les comportements simulés.
Pour faciliter la compréhension des illustrations des modèles des
différentes méthodes décrites, nous présentons en annexe (§ 6) la
première catégorie qui est la plus utilisée.
3.3 Principes
Il y a deux approches méthodologiques :
— la première issue des années 60 regroupant les méthodes carté-
siennes ;
— la seconde étudiée au cours des années 70 regroupant les
méthodes systématiques.

3.3.1 Méthodes cartésiennes
Les méthodes cartésiennes ou analytiques mettent l’accent sur la
démarche de conception qui décrit la manière de conduire et de
dérouler le processus de conception.
Elles recensent un ensemble de tâches à accomplir de manière
ordonnée. Le processus de conception est décomposé en phases,
elles-mêmes découpées en étapes, puis en sous-étapes avec les
tâches à accomplir au niveau élémentaire. Le processus de concep-
tion est vu comme un développement linéaire. Le terme usuel est
Top Down.
Les méthodes cartésiennes correspondent à une approche fonc-
tionnelle du SI. Le SI est abordé par les fonctions qu’il doit assurer,
plutôt que par les données qu’il doit gérer.
Le rôle de cette catégorie de méthodes est d’aider le concepteur
à passer d’une vision fonctionnelle globale à la description détaillée
du processus de traitement qu’elle constitue.
3.3.2 Méthodes systémiques
J.L. Lemoigne donne la définition suivante : « Un système est
défini comme quelque chose d’identifiable qui a une activité ou une
fonction, qui est doté d’une structure, qui évolue dans le temps, qui
est inséré dans un environnement et qui a une finalité ».
Dans les méthodes systémiques, le SI est abordé à travers
l’organisation des systèmes constituants de l’entreprise dont il fait
lui-même partie. Le SI est un modèle de la réalité organisation-
nelle, couplé :
— d’une part au système opérant dont il est une représentation
cohérente, complète, actuelle, non redondante et structurée ;
— d’autre part, au système de pilotage dont il est le support.
Le système opérant agit, suivant les décisions qui lui sont trans-
mises et à partir des flux dont il dispose, pour fournir les produits
en sortie.
Le système de pilotage prend les décisions macroscopiques de
l’organisation, en fonction des informations externes et internes
qui lui sont transmises, pour les envoyer au système opérant.
Ces méthodes permettent de concevoir un SI donnant une repré-
sentation de tous les faits pertinents qui surviennent dans l’organi-
sation.
L’approche de conception retenue pour ces méthodes est une
approche conceptuelle. Concevoir un SI, c’est construire un modèle
de la réalité organisationnelle. Celle-ci est donc à la fois une image
de la réalité et une vue abstraite de collections de données et de
traitements. La plupart de ces méthodes sont focalisées sur la
modélisation du SI et tout particulièrement sur la modélisation des
données (figure 7).
3.4 Intégration dans l’entreprise
3.4.1 Choix
La problématique du choix d’un cadre méthodologique pour
l’entreprise a déjà été traitée (§ 2.3). Il est cependant nécessaire de
rappeler que ce choix dépend de la manière dont il va être perçu
dans l’entreprise et donc des différents impacts qu’il pourrait avoir
lors de son intégration puis de son utilisation.
Les critères essentiels sont liés à l’historique culturel de l’entre-
prise en terme de méthodes, d’organisation et à sa capacité à évoluer.
Par exemple, le rejet d’une méthode par ses utilisateurs est certaine-
ment le point qui aura le plus d’influence sur la maîtrise globale du
SI et sur sa réactivité face aux exigences d’un marché concurrentiel.
Notons qu’une méthode rejetée produira des résultats souvent
non conformes au contrat passé entre le demandeur et le concepteur.
Si donc le choix d’une méthode ressort de la stratégie globale de
l’entreprise et est fait par les organes décisionnels, il est nécessaire
d’obtenir un consensus de l’ensemble des acteurs impliqués dans
l’activité de conception.
3.4.2 Processus d’intégration
Le plan d’intégration des activités de construction du SI d’une
entreprise doit comprendre des éléments contextuels dont l’influ-
ence n’est visible dans bien des cas qu’après leur expérimentation.
Il est cependant nécessaire de se doter au préalable des moyens de
mesurer cette influence pour correction si nécessaire. Les points
suivants semblent être les plus importants en termes de risque de
dérive et de maîtrise de SI.
■ L’organisation et les nouveaux métiers
Tous deux doivent être définis, couverts et mis en place préalable-
ment au premier projet de conception. Les circuits d’information
doivent être clairement établis, ainsi que les points de validation et
de synchronisation.
Les nouveaux métiers liés directement ou indirectement à l’utili-
sation d’un cadre méthodologique sont, par exemple, l’administra-
tion des données, l’administration des outils, le contrôle de la qualité.
■ L’adaptation
Quels que soient les choix effectués, il est nécessaire de s’assurer
que l’ensemble des composants de la méthodologie en place sont
conformes aux contraintes et aux spécificités de l’entreprise. Si des
adaptations nécessaires peuvent être envisagées, il faut noter le
risque lié à l’utilisation des outils. Il n’est pas rare en effet que l’entre-
prise s’adapte aux moyens de production de la conception sans éva-
luer le risque à long terme de désorganisation de son SI existant.
■ Les normes et les standards
Leurs mises en place définissent les règles à respecter dans l’acti-
vité de conception. Celles-ci concernent les résultats attendus (par
exemple la codification des données).
Figure 7 – Approche systémique

■ La sensibilisation
C’est une action marketing interne nécessaire qui réduit d’autant
les risques de rejet et incite les acteurs de la conception à vérifier
par eux-mêmes que leur activité est d’autant plus productive qu’ils
respectent les choix méthodologiques en les replaçant dans le
contexte stratégique de l’entreprise.
■ La formation
Elle doit s’attacher à former chaque acteur sur les techniques qu’il
utilise, mais également sur celles des autres acteurs impliqués, dans
un souci d’efficacité maximale de la communication.
L’intégration des composants méthodologiques doit être progres-
sive dans l’entreprise et passe nécessairement par un ou plusieurs
projets pilotes qui valident ou invalident pour adaptation l’ensemble
des aspects techniques, fonctionnels, organisationnels et budgé-
taires mis en place.
3.4.3 Bilan
Une fois intégrés dans l’entreprise, les composants du cadre
méthodologique doivent faire l’objet d’un suivi régulier pour
contrôler leur impact sur la maîtrise du SI et pour mesurer les gains
qu’ils génèrent en termes de qualité et de productivité. Les facteurs
suivants indiquent quels types de mesures il faut effectuer pour
améliorer, si nécessaire, le processus d’intégration d’un ou de
plusieurs éléments du cadre méthodologique.
■ Les indices de satisfaction
Ils mesurent les gains apportés par chaque composant de la
méthodologie face à leurs objectifs annoncés.
La méthode Merise, par exemple, comporte deux faiblesses, la
première liée à la modélisation des traitements plus faible que celle
des données, la seconde liée à la communication concepteur/utilisa-
teur sur laquelle la méthode n’est pas explicite.
Ces indices dépendent en règle générale de la pertinence des choix
et des faiblesses intrinsèques des outils de conception eux-mêmes
(méthodes, outils, ...).
■ Les taux d’utilisation
Ils mesurent le nombre des acteurs qui utilisent les différents
composants méthodologiques, avec quelle couverture et avec quels
résultats, comme par exemple :
— combien de concepteurs utilisent Merise dans l’entreprise ? ;
— combien utilisent la modélisation des données ? ;
— combien respectent les règles, les normes et les standards
imposés ? ;
— combien suivent les circuits d’information et les cycles de
décision imposés ?
■ La personnalisation
Elle mesure les composants méthodologiques qu’il a fallu adapter
pour rendre la méthode et sa démarche associée exploitables dans
l’entreprise. Toujours avec Merise comme exemple, choisi par 65 %
des entreprises utilisant une méthode (Enquête ADELI de mars 1989),
on approche 80 % de personnalisation, en particulier sur la
démarche.
■ Les attentes
Elles recensent les points à améliorer essentiellement dans les
méthodes face aux résultats des trois points précédents. Les attentes
actuelles essentielles concernent la productivité, la réactivité, la satis-
faction des utilisateurs.
Ces attentes ne sont pas explicitement mesurables, mais elles ne
peuvent être exprimées qu’après avoir mesuré les différents facteurs
cités précédemment, ce qui impose que des organes de contrôle
soient mis en place et soient réellement opérationnels.
En fait, s’il faut améliorer les composants méthodologiques pro-
posés sur le marché, c’est moins sur leurs aspects structurants
comme la modélisation, que sur la manière dont ils s’inscrivent dans
le contexte global de l’entreprise. Trop opérationnels, ils ne donnent
pas une vision du SI en tant qu’instrument de ses activités ; trop
abstraits, ils créent souvent une rupture avec la réalisation sauf à
des coûts très élevés à travers une démarche complexe.
De manière générale, l’entreprise, ayant accepté les enjeux d’une
méthode et de l’ensemble des autres moyens mis à la disposition
des concepteurs, devra d’abord contrôler que les manques dans
ses attentes ne sont pas imputables aux modifications qu’elle y a
apportées.
4. Panorama des méthodes
de conception
4.1 Émergence des méthodes
Le choix d’une méthode nécessite de bien maîtriser ses domaines
d’application, sa couverture, ses possibilités, ses limites, ses diffi-
cultés d’apprentissage et de mise en œuvre, ... Pour ce faire, le choix
se fait en fonction de critères tels que :
— les finalités et la stratégie de l’entreprise ;
— les acteurs concernés ;
— les domaines d’application ;
— les étapes du cycle couvertes ;
— les outils supports de la méthode (s’ils existent).
Dans un premier temps, nous effectuerons un recensement des
méthodes les plus anciennes jusqu’à l’apparition de méthodes
supportées par des outils. Nous excluons les méthodes n’ayant
aucun trait à la conception et les méthodes n’ayant pas été à l’origine
des méthodes plus actuelles.
On peut citer tout d’abord les Réseaux de Pétri qui datent des
années 60, non pas en tant que méthode de conception mais parce
qu’ils sont à la base de nombreuses autres. Ils permettent, entre
autres, de modéliser à un niveau d’abstraction quelconque la dyna-
mique d’un système.
Un réseau de Pétri se présente comme un graphe orienté composé
de deux classes de nœuds reliés par des arcs orientés et valués :
— les places (ressources) ;
— les transitions (activités conditionnées).
Il introduit la notion de marquage (condition de synchronisation)
et de jetons (présence de ressource dans des places). La notion de
marquage des places permet d’exprimer le séquencement et la
concurrence. Une transition n’est franchissable que lorsque toutes
les places en amont possèdent au moins un nombre de jetons égal
au marquage (figure 8).
Une des plus anciennes méthodes de conception est IDEF créée
lors d’un projet de l’US Air Force en 1974. IDEF est composée de
trois étapes :
— analyse du système (IDEF-0) ;
— analyse de la structure des informations (IDEF-1) ;
— analyse du comportement dynamique du système (IDEF-2).
La même année a été élaborée la méthode SD (Structured Design)
proposée initialement par W. Stelens, G. Myers et L. Constantine.
Elle permet de modéliser la solution sous forme de diagrammes. Les
éléments modélisés sont les modules et les flux de données entre
les modules. Cette méthode est proche de la réalisation et concerne
la conception de l’architecture d’un traitement (figure 9).
Pour mémoire, à la même époque a été créée la méthode Warnier
LCS (Logique de Construction de Système). Elle est constituée des
étapes de diagnostic, conception et analyse générale. Elle produit

des documents sur la description des données tels que FLB (Fichiers
Logiques de Base) et FLO (Fichiers Logiques Opérationnels) et des
documents sur les traitements tels que ULT (Unités Logiques de
Traitements) et UOT (Unités Opérationnelles de Traitements). Le
développement s’appuie sur la méthode LCP (Logique de Construc-
tion de Programme).
4.2 Panorama actuel
Ce paragraphe présente les méthodes les plus couramment
utilisées et celles qui ont une certaine notoriété, en précisant le type
d’approche et leurs caractéristiques en termes de couverture du cycle
de développement, d’implantation, de secteur d’activité, de normali-
sation et de support outils.
4.2.1 Merise
C’est la méthode systémique la plus connue et la plus employée
en France. Elle est aussi utilisée par des grands groupes en Amérique
du Nord, Belgique, Espagne, Italie, Suisse et pays du Maghreb. Elle
a été mise au point dans sa première version en 1978 par un groupe-
ment formé par sept SSII et des grands de l’administration française
[11]. La marque est déposée par l’administration. Suivant cette
méthode, tout projet informatique suit trois cycles : abstraction, déci-
sion et vie.
4.2.1.1 Cycle d’abstraction
Il permet de définir les principaux concepts manipulés par l’entre-
prise aux niveaux conceptuel, organisationnel et opérationnel.
■ Niveau conceptuel
Il permet de définir ce que l’on veut faire en identifiant des informa-
tions, des règles de gestion et l’enchaînement des traitements.
■ Niveau organisationnel
Le niveau organisationnel ou logique permet de définir « qui fait
quoi, quand et où ». À ce niveau sont traitées l’organisation des
données, la description des tâches, les répartitions géographique et
fonctionnelle.
■ Niveau opérationnel
Au niveau le plus bas, la méthode répond à la question « avec
quels moyens » en décrivant les traitements, les données, les états
et les écrans.
4.2.1.2 Cycle de décision
Le cycle de décision définit les instances et points de décisions
se rapportant au projet étape par étape :
— schéma directeur : il permet de faire un diagnostic, d’identifier
et de qualifier les domaines pour aboutir à un plan stratégique ; sur
ce point, Merise reprend des éléments de la méthode Racine, ciblée
sur cette étape ;
— étude préalable : étude des scénarios d’informatisation d’un
domaine étudié au niveau du schéma directeur ; cette étape se
décompose en une phase de recueil, puis de conception et enfin
d’appréciation des scénarios, qui aboutit à un choix avec un
découpage du projet de développement ;
— étude détaillée : cette étape reprend les éléments définis dans
l’étape précédente (modèles conceptuels) pour fournir des spécifi-
cations détaillées par sous-projet en obtenant des modèles logiques
optimisés ;
— réalisation : les développements informatiques sont effectués
et testés avec une recette en fin d’étape ;
— mise en œuvre : elle comprend toute la préparation de l’envi-
ronnement de production avec un site pilote qui sert à tester en gran-
deur réelle le produit livré pour recette par les utilisateurs. La mise
en œuvre comprend la livraison du produit.
L’utilisation des modèles de Merise est bien illustrée dans [7].
4.2.1.3 Cycle de vie
Le cycle de vie de Merise se rapporte au SI et prend en compte
la conception, la réalisation et la maintenance. Ce cycle est repris
dans les étapes du cycle de décision.
4.2.1.4 Remarques sur la méthode
Cette méthode met bien en évidence les invariants du SI. Elle
sépare l’étude du conceptuel vrai du logique (quelle que soit la
technologie) et de l’organisationnel dépendant d’une structure. De
même, la séparation des données des traitements facilite les évolu-
tions mineures de l’organisation, qui affectent les traitements sans
généralement avoir d’impact sur la structure des données.
Cette méthode est typiquement de culture française : intellectuel-
lement forte mais difficile à pratiquer, excepté la partie donnée,
reprise du modèle de P. Chen [4].
La démarche est lourde et monolithique, plutôt adaptée aux
moyens et grands systèmes avec terminaux passifs et comporte des
lacunes sur l’étude technique et la réalisation.
Figure 8 – Réseaux de Pétri
Figure 9 – Méthode SD

Cependant, le degré de diffusion de la méthode et le nombre
d’outils la supportant (plus de 20) en font une méthode qu’on ne
peut ignorer.
4.2.2 Rémora
Rémora est une méthode française développée par une équipe
de chercheurs [9] sous forme d’un projet dont le premier jet a été
présenté à la conférence internationale sur les « Very Large Data
Base » à Berlin en 1978.
C’est une méthode systémique qui vise à obtenir un modèle de
la réalité de l’organisation aussi complet que possible.
La méthode introduit une notion de SI actif qui intègre un
ensemble de mécanismes de synchronisation des actions le concer-
nant. Le SI actif joue le rôle de contrôle des événements qui modifient
le SI. Il réagit en fonction de messages et de règles, connus de lui,
décrits pendant le processus de conception.
Le SI est construit en deux étapes : conceptuelle et logique.
4.2.2.1 Étape conceptuelle
Elle permet de modéliser la réalité organisationnelle en proposant
une représentation abstraite des classes, associations de faits et des
règles de gestion. Le résultat est un schéma conceptuel unique qui
prend en compte l’aspect statique et dynamique du système
(figure 10).
4.2.2.2 Étape logique
Elle correspond à la définition de la solution technique. Elle décrit
la structure logique des données et l’ensemble des traitements
déclenchés en fonction d’événements. Cette étape aboutit à un
schéma logique qui prend en compte les contraintes techniques des
outils exploitant le SI.
4.2.2.3 Remarques sur la méthode
La méthode Rémora est relativement proche de Merise en ce sens
qu’elle propose des solutions pour la modélisation conceptuelle et
logique des SI en termes de données et traitements.
Par rapport à Merise, la notion de modélisation dynamique
complète la modélisation statique par enrichissement de la descrip-
tion des objets avec des concepts d’événement et d’opération. La
partie dynamique s’inspire en particulier des réseaux de Pétri.
Cependant, il existe une différence essentielle par l’intégration
de la notion de temps dans la méthode Rémora. Ce concept est
représenté au niveau logique en introduisant les notions de
« relation dépendant du temps » et de « relation permanente ».
Par exemple, une relation associant un prix à un article à vendre
est sujette à une évolution dans le temps. En revanche, une rela-
tion historique des prix de vente est une relation permanente car
chaque occurrence (nuplet) est immuable.
Cette prise en compte du temps est utile pour amener le concep-
teur à justifier ses choix de représentation des phénomènes évolutifs.
Rémora est une méthode bien introduite dans le monde univer-
sitaire servant de base à l’enseignement des méthodes (cf. article
Conception de bases de données : une méthode orientée objet et
événement [H 3 248] de ce traité).
4.2.3 SADT
La méthode SADT (Structured Analysis and Design Technique)
est une méthode créée en 1976 par D. T. Ross et est la propriété de
la société Softech. Généralement utilisée dans le monde industriel,
elle jouit d’une notoriété internationale.
Elle suit une approche cartésienne qui décrit le SI de manière
descendante, modulaire, hiérarchique et structurée, en couvrant
essentiellement les phases d’expression des besoins, de spécifica-
tion et de conception.
Elle s’appuie sur un modèle spécifique composé de Datagrammes
décrivant la transformation des données et d’Actigrammes décrivant
l’enchaînement des activités.
Le diagramme de données ou Datagramme est modélisé par des
« boîtes » créées à partir d’activités d’entrée. Le diagramme d’activité
ou Actigramme est modélisé aussi par des « boîtes » identifiées par
une activité, un événement ou un verbe. Ce modèle est représenté
par des boîtes avec 4 types de liens : entrées, sorties, contrôles,
mécanismes.
L’ensemble des diagrammes est ordonné hiérarchiquement avec,
au niveau le plus général, le diagramme de contexte (figure 11).
La méthode est basée sur un travail d’analyse orienté sur les flots
de données, qui permet de mettre en évidence les activités. Ce travail
conduit à un modèle fonctionnel par étapes successives :
— construction de Datagrammes et Actigrammes ;
— références croisées entre Actigrammes et Datagrammes ;
— séquencement des activités ;
— identification des mécanismes servant la réalisation des acti-
vités.
■ Remarques sur la méthode
Comparée à Merise, SADT propose des règles méthodologiques
plus souples et plus simples malgré quelques lacunes. Par exemple,
le choix et le nombre de niveaux d’abstraction sont maîtrisés par
le concepteur qui décide de la hiérarchie des « boîtes ». Un point
fort est son implantation internationale. Un point faible : la méthode
ne couvre que partiellement le cycle de décision. Elle est plutôt à
utiliser dans les premières phases d’un projet : expression des
besoins, spécification préliminaire et détaillée d’un SI car c’est une
méthode simple pour communiquer avec les utilisateurs. Elle est
considérée comme orientée système temps réel.
Elle est applicable à toute situation que ce soit pour un petit (un
individu) ou un grand projet.
4.2.4 Axial
Créée en 1984 par Pellaumail, c’est la méthode utilisée par IBM
pour ses développements internes et préconisée à ses clients,
généralement en gestion.
Figure 10 – Méthode Rémora : sous-schéma dynamique

Elle couvre tout le cycle de développement et met l’accent sur
l’aspect planification des SI. Elle propose des formalismes
graphiques aussi bien pour les données que pour les traitements.
La liste des phases et étapes d’Axial est la suivante :
— diagnostic d’adéquation du SI et d’équipement des postes de
travail, qui est composé d’étapes d’interviews avec les utilisateurs
afin de définir le dossier d’entreprise (Système d’Information et
Poste de Travail) ;
— schéma directeur de développement (étude des stratégies) :
étude par domaine structurel et par entité organisationnelle avec jus-
tification économique, constitution de diagrammes tels que
Diagramme Fonction Générale, Diagramme Objet Fonction ;
— conception fonctionnelle : description des activités d’un
domaine avec choix des moyens techniques et élaboration d’un
scénario optimal validé qualitativement et quantitativement, consti-
tution de diagrammes tels que Diagramme Détaillé Objets/Fonctions
d’Activité et Diagramme Tâches/Utilisateurs ;
— conception des systèmes techniques : définition des bases de
données, des équipements informatiques, distribution des res-
sources entre sites avec définition des moyens de communication ;
— plan de réalisation : découpage en séquences de réalisation,
plans de mise en œuvre avec évaluation économique détaillée ;
— réalisation : conception fonctionnelle détaillée, écriture des
programmes avec Improved Programming Technique et mise en
œuvre du produit de conception jusqu’à sa mise à disposition auprès
des utilisateurs finals ;
— maintenance et bilan.
Il existe des analogies entre Axial et Merise. Par comparaison,
Axial démarre plus en amont dans un projet de développement et
couvre mieux les modalités de passage entre l’ancien SI et le
nouveau SI, du fait de sa plus grande dépendance vis-à-vis du maté-
riel et des logiciels. Par ailleurs, la partie évaluation des charges est
intégrée dans la méthode dès le schéma directeur et utilise la Fonc-
tion Point pour évaluer la réalisation. Axial est plus faible sur la partie
conception (étude préalable ou spécifications générales) à cause
d’une documentation moins fournie et de définitions moins précises
des concepts et de leur articulation.
Par son origine, cette méthode est essentiellement utilisée par des
sociétés à forte tendance IBM. Elle a été portée sur l’outil Excelerator
sous l’influence de P. Pellaumail.
Elle est peu répandue. Moins de 50 sites en France l’utilisent
dont plus de la moitié partiellement.
4.2.5 IEM
Créée en 1984 par J. Martin, la méthode Information Engineering
Methodology est orientée vers le développement de systèmes inté-
grés et combine l’approche donnée et l’approche traitement. Les
vues du système en terme de « business model » se décomposent
en « business data », « business activities » et « interaction » entre
les données et les traitements (figure 12).
La méthode se déroule en sept étapes :
— ISP (Information Strategy Planning) : construction d’un plan
stratégique à partir des besoins exprimés ; c’est un modèle d’entre-
prise qui se décompose en domaines appelés « Business Area » ;
— BAA (Business Area Analysis) : correspond à la conception du
SI ;
— BSD (Business System Design) : examen des interactions de
l’utilisateur avec le futur système ;
— TD (Technical Design) : adaptation des modèles des étapes
précédentes en fonction de l’environnement technique (matériel et
logiciel) ;
— construction : étape de réalisation ;
— transition : mise en place progressive du nouveau système ;
— production : exploitation du futur système correspondant au
besoin exprimé durant l’étape ISP.
Dans l’étape BAA, le modèle de données introduit la notion d’entité
associative qui représente les associations porteuses de propriétés
du modèle de données de Merise. Il ne traite que les relations
binaires. Lors de cette étape, 11 modèles sont utilisés pour décrire
les données, les traitements, les flux et les références croisées.
La méthode est applicable dans tous les secteurs d’activités avec
une préférence pour la gestion ; elle est largement utilisée dans les
secteurs bancaires et assurances. Elle est supportée par deux
outils : IEF (J. Martin) et ADW (Knowledgeware).
Elle a une couverture internationale et le support des outils ADW
(anciennement IEW) et IEF a favorisé son utilisation.
4.2.6 IA-NIAM
Nijssen’s Information Analysis Method est une méthode de
Control Data développée par G.M. Nijssen en 1975. La méthode est
basée sur une analyse sémantique du réel perçu. L’approche orientée
traitement utilise les diagrammes de flux d’informations et
l’approche orientée données utilise les diagrammes de structuration
des informations basées sur un modèle binaire (figure 13).
Le modèle IA décrit :
— l’objet type, objet du monde réel ;
— l’objet non lexical (Non Lexical Object Type ou NOLOT) de type
concret ou abstrait possédant une existence propre et caractérisé
par les rôles qu’il joue via les idées et/ou ponts de dénomination ;
— l’objet lexical (Lexical Object Type ou LOT), classe de dénomi-
nation d’un ou plusieurs NOLOT auquel il est relié ; un LOT n’est
jamais isolé ;
— l’idée reliant par une phrase élémentaire type deux NOLOT,
chacun y jouant alors un rôle dans une relation binaire irréductible ;
— le pont de dénomination associant un NOLOT à un de ses
LOT.
Figure 11 – Méthode SADT : boîte de diagrammes

Le modèle IA intègre la notion de sur-types et de sous-types. Il
inclut une grande variété de contraintes telles que l’unicité, l’inclu-
sion, l’exclusion, etc.
La méthode utilise un langage formel textuel pour spécifier les
activités.
L’approche donnée a été retenue par l’ISO. Sur ce point, c’est la
méthode la plus riche avec une expression détaillée des contraintes
d’intégrité.
C’est une approche grands comptes plus utilisée dans les secteurs
bancaires et assurances.
La méthode est supportée par les outils ISW de ISW et Graphtalk
de Parallax.
4.2.7 SSADM
Développée par CCTA en 1983 et parrainée par le gouvernement
britannique, la méthode Structured Systems Analysis and Design
Method couvre l’analyse et la conception des SI et intègre des
aspects de planification. Elle est composée des étapes suivantes :
— étude de faisabilité ;
— analyse de l’existant ;
— spécification des besoins ;
— choix des options techniques ;
— modélisation logique des données ;
— modélisation logique des traitements ;
— modélisation physique.
SSADM utilise trois visions graphiques :
— les diagrammes de flux (Data Flow Diagram) décrivant les flux
de données (Entity Flow Diagram) et les traitements associés
(figure 14) ;
— les diagrammes entité-relation (Logical Data Structure Dia-
gram) décrivant les données et leurs relations ;
— les diagrammes d’historisation des entités définissant la planifi-
cation des événements sur les entités.
Les contradictions entre DFD et LDSD sont détectées par des
références croisées.
La méthode est dirigée par une liste de problème/besoins. Cette
liste intégrée au déroulement des étapes permet, à chaque problème
sélectionné, d’y adjoindre progressivement la solution à prendre en
compte dans le système futur.
Sa couverture est principalement anglo-saxonne et elle est sup-
portée par des outils comme VSF de la société britannique Syste-
matica.
Figure 12 – Méthode JEM : « business model »
Figure 13 – Méthode NIAM : modèle de données

5. Nouveaux besoins,
nouvelles tendances
5.1 Émergence de nouveaux besoins
5.1.1 Adéquation partielle
Dans de nombreuses entreprises, on constate les réticences à
suivre pas à pas les méthodes, souvent dues aux contraintes de
fonctionnement des équipes de développement. Ainsi, une entre-
prise utilise rarement une méthode dans sa globalité.
Une première démarche pratiquée dans certaines entreprises
consiste à utiliser le formalisme entité-association lors des phases
de conception statique du système pour identifier les objets du
monde réel et établir leur relation. Pour la partie activité d’un système
avec prise en compte des aspects dynamiques, la méthode SADT
est la plus utilisée.
Une deuxième démarche, appliquée généralement dans le cas
de Merise, est de contraindre la méthode au contexte de l’entre-
prise soit en éliminant certaines étapes de la méthode, soit en y
apportant des adaptations.
La première génération de méthodes est essentiellement inspirée
de moyens informatiques peu adaptés pour représenter le monde
réel, d’où des modèles de données très liés à la construction de bases
de données, des représentations des activités inspirées de la structu-
ration des programmes et des difficultés à représenter la dynamique
des SI. Par conséquent, les modèles des données et des activités
sont distincts et nécessitent obligatoirement une consolidation pour
validation.
5.1.2 Évolution technologique
Le premier point est l’essor des stations de travail dû à une
augmentation de leur puissance et à la diminution de leur coût
d’acquisition. Cela a deux impacts :
— l’utilisation d’outils puissants permettant à la fois de supporter
le formalisme des méthodes, les démarches, les règles associées et
de garantir la cohérence de ce qui est conçu en facilitant les transi-
tions entre les différentes étapes du cycle de développement ;
— la possibilité de répartir le produit réalisé en dissociant ce qui
est proche de l’utilisateur, en général l’interface homme/machine
et les informations locales, de ce qui est partagé par l’ensemble
des utilisateurs ou qui nécessite la puissance des gros ordinateurs.
D’où la nécessité, dès la conception, de prévoir comment répartir
les données et les activités.
Le second point concerne les langages de programmation. Après
une première évolution utilisée principalement dans les milieux
universitaires, une deuxième génération de langages apparue au
cours des années 80 s’impose sur une partie du marché, par exemple
ADA développé en 1983 pour le ministère de la défense américaine,
SMALLTALK 80 (Goldberg 1985) et C++ (Stroustrup 1989), langages
dits « orientés objets », et PROLOG, langage pour système expert.
Cette nouvelle génération de langages a créé un fossé entre la
conception et la réalisation, nécessitant une réflexion soit sur l’évolu-
tion des méthodes existantes, soit sur la création de nouvelles
méthodes.
5.1.3 Couverture du cycle de vie
L’évolution du SI devient un problème crucial. La maintenance
fonctionnelle et l’évolution des applications constituent un proces-
sus complexe mal maîtrisé. Il est en effet acquis que l’effort de déve-
loppement se portera de plus en plus sur la maintenance évolutive,
y compris l’extension et le redéveloppement d’applications opéra-
tionnelles et de moins en moins sur la construction de nouveaux SI.
5.1.4 Formation des informaticiens
Bien que les méthodes apportent la rigueur nécessaire dans les
développements informatiques et par conséquent une amélioration
de la productivité et de la qualité des produits résultants, elles sont
loin d’être intuitives et demandent un effort certain avant de les
maîtriser. Implicitement, elles créent des barrières entre les initiés
et les non-initiés. Par exemple, il n’est pas rare d’appeler les adeptes
de Merise les « Merisiens ». Une méthode nécessite souvent au
moins un an de pratique avant de pouvoir en tirer les bénéfices
attendus.
Ce constant va dans le même sens que les évolutions technolo-
giques, c’est-à-dire un plus grand confort d’utilisation des méthodes
via le support d’outils et une seconde génération de méthodes plus
proches de nos schémas de pensée.
5.2 Réponses
5.2.1 Outils
Nous ne parlerons ici que des outils utilisés dans l’activité de
conception.
La conception est avant tout, nous l’avons déjà signalé, un proces-
sus mental de création. Dans l’état actuel de la technologie, il ne
semble donc pas opportun de parler d’outils de conception, mais
plutôt d’outils d’aide à la conception.
Ils se déclinent suivant quatre grands axes :
— les outils de modélisation généralement graphiques, obligeant
le concepteur à respecter les contraintes de représentation imposées
par la méthode utilisée (MCD et MOT par exemple) ;
— les outils de contrôle, permettant de s’assurer que les résultats
de la conception respectent des règles et des contraintes imposées
par la méthode (non-polysémie, non-redondance par exemple) ou
par la démarche (point de synchronisation, visa d’un administrateur,
validation ou réalisation d’une étape obligatoire) ;
Figure 14 – Méthode SSADM : diagramme de flux

— les outils de génération de descriptions plus fines (comme le
passage d’une forme normale à une autre ou la fabrication du
Langage de Définition des Données), ou l’ébauche d’objets utilisés
dans la phase de réalisation (structure de données, point
d’entrée, ...) ;
— les outils de construction de maquettes ou de prototypes.
Ces outils s’appuient généralement sur un référentiel garantissant
la mémorisation des informations créées par les concepteurs et per-
mettant d’obtenir toutes les visions de la conception d’un SI adaptées
à chaque type d’acteur.
Le référentiel et les outils qui l’exploitent sont les éléments essen-
tiels de la communication. Ceux-ci sont nécessairement assortis de
générateurs de documents ou de dossiers et c’est certainement cet
aspect qui leur fait prendre toute leur importance.
Il ne s’agit pas dans cet article de faire le catalogue des outils du
marché, mais d’en citer quelques-uns comme exemples.
Les quatre axes sont couverts par trois catégories d’outils :
— les outils spécialisés : ils couvrent une seule méthode à
travers tout ou partie de la démarche associée (DELF, Excelerator
Merise, ...) ;
— les outils adaptables : spécialisés dans une ou plusieurs
méthodes, ils acceptent un niveau de paramètres leur permettant
un certain degré d’adaptation aux exigences spécifiques de l’entre-
prise (MEGA, ADW, ...) ;
— les générateurs d’outils : à travers une description dans un
langage formel, ils permettent de fabriquer des outils spécialisés
entièrement adaptés aux contraintes de l’entreprise (par exemple :
Graphtalk, VSF, OMS de MAESTRO II).
Ces outils, une fois intégrés dans le contexte de l’entreprise,
constituent ce qui est communément appelé Atelier de Génie Logi-
ciel (AGL).
La notion d’AGL recouvre deux aspects :
— l’intégration des outils par échange d’informations (interfaces) ;
— l’intégration des outils par les données.
Le premier aspect est encore le plus répandu, mais il ne permet
plus la réactivité nécessaire à l’entreprise.
Le second aspect est le plus récent et a tendance à devenir la solu-
tion la plus pérenne. La première tentative a été proposée par IBM
dans le cadre de son offre AD/Cycle. Bien que celle-ci ait subi des
retournements technologiques récents, les concepts d’intégration
par les données sont conservés. PCTE (Portable Common Tool
Environment ) spécifié par l’ECMA et l’AFNOR, et IRDS, spécification
internationale pour les référentiels, vont à terme imposer ces
concepts.
Cependant, si près de 70 % des entreprises ont choisi d’utiliser
une méthode, seulement 50 % d’entre elles utilisent des outils. En
fait, si les outils améliorent la qualité et la maîtrise des produits de
la conception, ils ne semblent actuellement en réduire ni les coûts
ni les délais. Sur un marché encore nouveau, ils n’ont pas encore
atteint leur maturité.
5.2.2 Évolutions des méthodes
5.2.2.1 Merise/2
L’évolution de la méthode Merise est la propriété de SEMA Group.
Cette évolution offre la compatibilité ascendante ainsi qu’un support
à travers des outils. Les principales caractéristiques Merise sont
conservées : approche systémique, les trois cycles, les modèles. Elle
est supportée par l’outil Principia de SEMA Group.
L’évolution générale de Merise/2 est relative à la répartition des
données et traitements et à l’approche objet. Elle précise les modèles
de données et de traitements des niveaux conceptuels et organisa-
tionnels par l’utilisation systématique de techniques de décomposi-
tion/composition reprises des méthodes anglo-saxonnes (SADT,
IEM, SSADM), le rapprochement données/traitement et complète le
cycle d’abstraction au niveau logique par des modèles et des tech-
niques originaux s’appuyant sur des architectures d’applications
client-serveur. Cela a entraîné l’ajout de modèles et de gammes
opératoires.
Bien que ce soit une évolution d’une méthode largement
répandue, cette nouvelle mouture provoque un léger bouleverse-
ment culturel et nécessite une documentation volumineuse de
l’ordre de 1 000 pages. Nous la présentons succinctement en
déclinant les évolutions par niveau de modélisation.
Il y a un rapprochement dès la conception des données et des
traitements. Les interactions entre les données et les traitements
sont encapsulés dans des objets. Pour cela, deux techniques sont
utilisées :
— le Modèle Conceptuel des Traitements Analytiques (MCTA) : on
associe à une action donnée tous les objets auxquels elle accède.
Le concept de base de MCTA est l’opération analytique déclenchée
par un ou plusieurs événements qui fournit un ou plusieurs résultats.
Elle est constituée d’un ensemble d’actions élémentaires (création,
consultation, modification, suppression) dont le déclenchement ou
l’itération sont conditionnés (figure 15) ;
— le modèle du Cycle de Vie des Objets (CVO) : il décrit toutes
les transformations que peut subir un objet pendant son cycle de
vie ; ce modèle comporte un ou plusieurs états initiaux, intermé-
diaires et finals. Ces états se définissent par un ensemble de
contraintes d’intégrité qui sont vérifiées au cours d’une étape donnée
du cycle de vie d’un objet (figure 16).
■ Niveau organisationnel
L’étude du niveau organisationnel a pour but de décrire le fonc-
tionnement du SI (défini au niveau conceptuel) dans le cadre d’une
organisation cible.
Le modèle organisationnel des données se décompose en trois
vues :
— générale : distinction entre les données informatisées et les
données manuelles avec apparition de nouveaux objets ;
— par type de site : représentation du partage des données
accédées avec notion de propriété et de protection ;
— par type d’acteur : expression par type d’acteur des autorisa-
tions d’accès par groupes de données (figure 17).
Figure 15 – Merise/2 : modèle conceptuel
des traitements analytiques

Le modèle organisationnel des traitements poursuit la décomposi-
tion du niveau conceptuel avec un niveau de détail permettant
d’identifier les unités de préoccupations organisationnelles avec le
Modèle Organisationnel des Traitements Analytiques (MOTA).
■ Niveau logique
Il prend en compte les nouvelles architectures d’application
client/serveur avec interface graphique multifenêtres.
L’application peut être divisée en quatre domaines :
— la présentation ;
— les dialogues ;
— les interfaces avec les traitements ;
— les traitements.
C’est à ce niveau que la répartition logique des données et des
traitements est effectuée. Une notion de fonction logique apparaît
à des fins de réutilisation. Elle est composée (figure 18) :
— de l’interface utilisateur : objets graphiques et dialogue gérant
l’enchaînement des fenêtres ;
— du guidage fonctionnel : enchaînement des tâches en fonc-
tion des actions utilisateur, interface pour les messages et appels
aux autres fonctions ;
— du noyau non interactif : ensemble de procédures non interup-
tibles comme les accès aux données et les calculs.
Plusieurs principes sont à respecter :
— recherche de l’indépendance entre les trois composants afin
de pouvoir développer des interfaces différentes avec le même
noyau ;
— gestion du verrouillage des données en mise à jour en tenant
compte de l’interruptibilité et du parallélisme des traitements ;
— conception de l’application par niveau d’interaction avec l’utili-
sateur (lexical, syntaxique et sémantique).
5.2.2.2 Merise-CASC
Merise-CASC (Conception des Applications Serveurs-Clients)
développée au sein de la Sligos par J. M. Berlioux a pour objectif
d’intégrer les approches client/serveur dans Merise. Cette évolution
introduit des modèles complémentaires et les notions de modèles :
— externes définissant les modes de communication entre les
traitements ;
— internes définissant le mode de fonctionnement des traite-
ments.
L’intérêt de ce type d’évolution est d’intégrer à moindre coût
culturel les évolutions fonctionnelles dues aux avancées techno-
logiques. Merise-CASC est opérationnelle, mais n’est pas largement
diffusée actuellement.
Nous présentons comme précédemment les évolutions par niveau
de modélisation.
La répartition des données est représentée par un modèle MRGD
(Modèle Réparti Global des Données) qui remplit deux fonctions :
— représenter la répartition des données ;
— décrire les redondances.
Ce modèle est construit à partir du modèle conceptuel de données
MCD en indiquant pour chaque propriété s’il s’agit d’une donnée de
référence, d’une duplication ou d’une donnée mouvement. Les infor-
mations de propriété et protection sont prises en compte de manière
textuelle.
Relatif au traitement, le modèle opérationnel de traitement MOT
de Merise est repris en y adjoignant la notion de processeur
(machine) supportant l’opération et le périmètre des traitements
pour le modèle interne.
■ Niveau logique
Le niveau logique accentue la répartition. Le modèle représente
les données par processeur logique avec des liens entre processeurs
pour la gestion de la cohérence. Le modèle logique des traitements
spécifie la structure des traitements assurant les opérations réparties
et les opérations de gestion de la cohérence. Le modèle interne des
traitements représente, outre la structure logique interne des traite-
ments, la structure interne des traitements serveurs (contexte,
conversation, sécurité, protection, ...) (figure 19).
5.2.3 Nouvelles méthodes
Comme nous l’avons précisé (§ 5.1), les lacunes constatées sur
les méthodes de première génération et l’apparition de langages
dits « orientés objets » nécessitent une autre manière de concevoir
les SI.
Figure 16 – Merise/2 : cycle de vie des objets
Figure 17 – Merise/2 : groupe de données par type d’acteur
Figure 18 – Merise/2 : fonction logique

Les méthodes dites « conception par objet » sont, la plupart du
temps, des méthodes d’aide à la définition des programmes utilisant
un langage objet et non des méthodes de conception de système
d’objets (tableau 1). (0)
Volontairement, nous ne présentons pas de méthodes orientées
vers la connaissance utilisées dans le domaine des systèmes experts,
non pas à cause de leur manque d’intérêt, mais principalement par
le coté non généralisable à tout type d’application. Cependant des
méthodes comme KOD (Knowledge Oriented Design de C. Vogel)
et KADS (issue du projet ESPRIT) sont très intéressantes pour modé-
liser l’activité cognitive dans l’expression des besoins, aspect actuel-
lement non traité ou partiellement dans les autres méthodes. Cet
aspect intègre une analyse de texte de l’expression des besoins des
experts avec contrôle sémantique.
5.2.3.1 Quelques définitions
■ Objet
C’est une abstraction d’un réel perçu qui a une valeur, une identité
et un ensemble d’opérations pour le manipuler. Il a un caractère
dynamique possédant un état interne. Un objet correspond donc à
une entité logique à forte cohésion fonctionnelle.
■ Classes
Il s’agit de l’entité conceptuelle qui décrit l’objet. Des objets
différents ayant des comportements identiques et de même structure
sont regroupés en classes. Ainsi, l’objet est une instance d’une
classe. La description de la classe se fait à l’aide de variables. Elle
correspond à la vision statique de la réalité.
■ Méthodes
Ce sont les opérations que l’on peut appliquer sur un objet. Elles
représentent la réalité d’un point de vue dynamique.
■ Encapsulation
C’est le regroupement dans une même unité des structures de
données décrivant les propriétés de l’objet et des méthodes
permettant de faire interagir cet objet avec d’autres.
■ Messages
Les objets communiquent au moyen de messages qui ne spécifient
jamais comment une action doit être réalisée.
■ Héritage
Les propriétés des classes peuvent être transmises à leurs
descendants par le mécanisme de l’héritage. L’héritage simple ne
permet cette transmission à une classe qu’à partir d’une seule classe
parente alors que l’héritage le permet à partir de plusieurs.
■ Agrégation
Elle permet la composition d’une classe à partir de l’inclusion des
propriétés et des méthodes d’autres classes.
■ Polymorphisme
C’est la possibilité d’envoyer le même message à des objets,
instances de différentes classes. Chacune de ces instances interprète
le message à sa manière, c’est-à-dire en évaluant la méthode corres-
pondante qu’elle connaît.
Figure 19 – Merise-CASC : modèle logique
des données réparties
Tableau 1 – Méthodes orientées objets représentatives
des tendances actuelles
Méthodes françaises Méthodes étrangères
Méthodes utilisant un modèle entité - association
MORE de M. Paraire OOA de P. Coad et E. Yourdon
Méthode classe-relation
de P. Defray
OOA/OOD de S. Shlaer
et S.J. Mellor
OOM de A. Rochfeld PTECH de J. Edwards
OMT de J. Rumbaugh et al.
Méthodes n’utilisant pas de modèle entité - association
COOPE de B. Ergin,
J. Kouloundjan et al.
OOD de G. Booch
O* de C. Rolland, C. Cauvet
et J. Brunet Objectory de I. Jacobson
MCO de X. Castellani BON de B. Meyer et al.
HOOD (CRI, CISI et Matra)
SYS-P-O de P. Jaulent

Stratégie de conception des systèmes d'information (H5170).pdf

Stratégie de conception des systèmes d'information (H5170).pdf

Recommandé

Recommandé

Contenu connexe

Similaire à Stratégie de conception des systèmes d'information (H5170).pdf

Similaire à Stratégie de conception des systèmes d'information (H5170).pdf (20)

Stratégie de conception des systèmes d'information (H5170).pdf