Ingénierie des systèmes d'information

La démarche classique de Merise couvre trois grandes périodes : la planification des systèmes d'information, le développement d'un projet et la maintenance de l'application. Chacune de ces périodes se décompose en étapes successives comme l'illustre la figure 15.1 :

Cette démarche n'est pas spécifique à la méthode Merise. Il faut cependant remarquer la part importante faite à la conception (étude préalable, étude détaillée, étude technique) ; en particulier les passages successifs de l'étude qui permettent de dégrossir progressivement les différents choix que l'on a déjà mis en évidence dans la courbe dite du soleil (voir chapitre 3Chapitre 3 Les trois composantes de Merise).

À chacune des étapes de la démarche, les concepteurs appliqueront les différents raisonnements nécessaires à la construction du système d'information, parcourant les niveaux d'abstraction de la méthode. C'est le couplage démarche - niveaux d'abstraction qui fait la spécificité et la richesse de la méthode Merise. Ce couplage ne sera pas aussi étroit tout au long de la démarche. La méthode Merise s'est positionnée avant tout comme une méthode d'ingénierie de systèmes d'information et naturellement nous développerons les aspects liés à ces étapes, tout en rappelant que Merise est également une structure d'accueil pour d'autres raisonnements développés en dehors de la méthode, en particulier dans le cadre de la réalisation, avec les apports du génie logiciel.

La portée des différentes étapes pour un système d'information est la suivante :

• le schéma directeur concerne l'entreprise (ou un secteur majeur) dans son ensemble ;
• l'étude préalable porte sur un domaine, sous-système d'information de l'entreprise défini lors du schéma directeur ;
• l'étude détaillée, l'étude technique, la production du logiciel, la mise en service et la maintenance portent sur des projets relatifs à un domaine spécifique et peuvent être découpées en applications.

L'étude des systèmes d'information s'effectue à partir d'un découpage initié dans le schéma directeur identifiant les différents domaines d'activité. C'est à partir de ce découpage que sont déterminés et planifiés les différents projets associés à l'informatisation des systèmes d'information.

L'étude préalable, consacrée à l'élaboration et la proposition de solutions, s'effectue pour un projet. L'étude préalable peut à son tour conclure à un découpage en plusieurs sous-projets, pour des raisons de taille ou de complexité.

L'étude détaillée, l'étude technique, la production du logiciel et la mise en service s'effectuent par projet ou sous-projet. Éventuellement, à l'intérieur de chacune de ces étapes, le projet ou sous-projet peut être découpé en plusieurs lots, si cela s'avère nécessaire pour des raisons soit de complexité du champ de l'étude, soit pour des impératifs de suivi ou d'organisation.

S'inspirant des démarches de l'ingénierie, la conception d'un système d'information nécessite, avant la spécification exhaustive d'un projet, une étape plus sommaire et globale, proposant des choix et les évaluant : l'étude préalable.

L'étude préalable a pour objectifs :

• L'analyse et l'évaluation critique du fonctionnement du système d'information actuel.

• L'élaboration de solutions en précisant :

  • les processus de fonctionnement du domaine,
  • la perception des informations,
  • les modes d'organisation,
  • le degré et le type d'automatisation.

• L'évaluation des solutions proposées en termes de :

  • équipements informatiques,
  • coûts et délais de mise en œuvre,
  • conséquences sur l'organisation générale de l'entreprise,
  • scénario de mise en œuvre.

L'étude préalable privilégie la diversité des solutions par rapport au détail des spécifications.

La conduite d'une étude préalable se trouve confrontée à deux exigences contradictoires. D'une part, elle doit être de courte durée conditionnée par un budget souvent limité, d'autre part, elle doit conduire à une analyse suffisamment complète pour éclairer les décisions du maître d'ouvrage engageant toute la suite du projet.

Disposant d'un temps total de travail limité, l'équipe de projet se pose la question : « Quel est le sous-ensemble qui représente le mieux le domaine étudié ? ».

Pour choisir ce sous-ensemble représentatif et mettre en évidence les processus majeurs du domaine, le concepteur prend en compte le fonctionnement normal, en négligeant les situations exceptionnelles, les processus de faible fréquence et les opérations marginales. Ce sous-ensemble doit représenter l'ossature du système d'information où les activités principales et les données fondamentales sont exprimées.

La conception du futur système d'information repose sur les différentes solutions élaborées autour des éléments constituant le sous-ensemble représentatif. Le choix des éléments constituant le sous-ensemble représentatif conditionne donc fortement l'orientation future du fonctionnement du système d'information.

L'étude préalable se décompose en quatre phases présentées en figure 15.3.

Les objectifs de la phase d'analyse de l'existant sont de comprendre et formaliser le fonctionnement du système actuel, et diagnostiquer ses dysfonctionnements sur les plans de la gestion, de l'organisation et des solutions techniques.

Les objectifs de la phase de conception sont d'élaborer et formaliser des solutions de fonctionnement du futur système d'information.

Les objectifs de la phase d'évaluation sont d'évaluer chacune des solutions élaborées dans la phase précédente sur les aspects fonctionnels, organisationnels, techniques, financiers, charges de développement et planning. Lors de cette phase seront aussi proposés des scénarios de mise en service.

Chaque phase comporte un ensemble de tâches qui s'enchaînent telle une procédure. Les phases et tâches du déroulement présenté de l'étude préalable constituent la trame générale de la démarche classique de la méthode Merise. Toutefois, l'importance accordée aux tâches et à leur ordonnancement au sein de chaque phase dépend en grande partie du contexte, de la taille et du type de problème rencontré, de la connaissance que le concepteur peut avoir du domaine.

La phase de lancement initialise l'étude préalable. Elle se décompose en quatre tâches présentées sur la figure 15.4.

Cette phase assure d'abord un premier cadrage du projet en précisant son contour. Elle rappelle les orientations du schéma directeur, éventuellement réactualisées ; à défaut, le demandeur de l'étude devra rédiger ou approuver une courte note d'orientation.

Cette phase définit ensuite les modalités pratiques de déroulement et d'organisation de l'étude préalable en précisant :

• l'organisation des structures du projet (groupe de pilotage, groupe de projet, groupe de validation) et la répartition des tâches ;
• un calendrier ;
• le cadre budgétaire ;
• les contraintes d'environnement pesant sur le projet.

Tous ces éléments seront réunis pour constituer une note de lancement.

Cette phase donne enfin lieu à une information auprès des différentes parties prenantes sur les enjeux de cette étude préalable pour l'entreprise.

Avant de concevoir un nouveau système d'information, il est indispensable de bien connaître le domaine concerné. Bien que cette connaissance puisse déjà être compilée dans des documentations, il est indispensable de recueillir ou réactualiser ces informations en interrogeant les gestionnaires et les utilisateurs et de procéder à une analyse critique. L'analyse de l'existant se décompose en quatre tâches présentées sur la figure 15.5.

Objectifs et résultats attendus

Il s'agit de mettre en évidence rapidement :

• Les principales informations qui circulent dans le système d'information de l'entreprise ; ces flux d'informations peuvent correspondre à des supports très différents (imprimés, communications verbales, téléphoniques…).
• Les principales unités actives qui participent à ces échanges ; ces acteurs peuvent appartenir au domaine d'application (poste de travail, services…) ou à son environnement (autres unités, client, fournisseur…).

Avec un formalisme rudimentaire (voir chapitre 5 « Découpage en domaines et analyse des fluxChapitre 5 Découpage en domaines et analyse des flux »), l'analyse des flux permet de mettre en évidence :

• La délimitation du domaine.
• Les activités principales du domaine.
• La nature et la signification des informations échangées.

Raisonnements utilisés

Différentes sources peuvent servir de base à une analyse des flux d'informations :

• l'organigramme des services (acteurs) ;
• des documents réels recueillis (flux d'informations) ;
• des procédures prédéfinies (acteurs et flux) ;
• l'interview des gestionnaires et des utilisateurs.

Dans tous les cas, on cherchera à mettre en évidence, puis à nommer, les acteurs concernés et les flux d'informations. On représentera ensuite graphiquement le diagramme des flux correspondant. On pourra commencer par un diagramme brut qui évoluera vers un diagramme de contexte (cf. Chap. 5Chapitre 5 Découpage en domaines et analyse des flux).

Objectifs et résultats attendus

L'objectif est de décrire globalement le fonctionnement du système actuel en termes d'organisation. Le résultat attendu est une description succincte du modèle organisationnel des traitements actuels (MOT actuel), cela en termes de :

• Postes de travail avec environnement humain et technique.
• Procédures organisationnelles majeures.

La construction d'un modèle organisationnel actuel poursuit plusieurs objectifs. Tout d'abord servir de point de départ au processus d'abstraction permettant la construction du modèle conceptuel de traitements actuel puis futur. Ensuite, établir un état des lieux du fonctionnement actuel permettant d'évaluer l'écart avec la situation future proposée, et d'élaborer un scénario pour la transition entre les deux situations. Enfin apprécier le fonctionnement général du domaine afin d'extraire les éléments marquants à retenir pour le sous-ensemble représentatif.

Raisonnements utilisés

Le concepteur met œuvre le formalisme présenté au chapitre 8Chapitre 8 Modélisation organisationnelle des traitements. L'élaboration de ce modèle ne s'effectue pas par la décomposition des opérations d'un modèle conceptuel, mais par la formalisation directe de l'enchaînement des tâches effectuées dans les différents postes. On illustrera en particulier les procédures que le gestionnaire ou l'utilisateur considèrent comme représentatives.

Objectifs et résultats attendus

L'objectif est de connaître et de décrire les fichiers informatisés actuellement existants. Les résultats attendus sont :

• Le modèle logique de données reconstitué à partir des structures de bases de données ou fichiers existants.
• Le volume des données actuellement mémorisées et l'évolution prévisible de ces volumes.

Comme précédemment, si les données actuelles étaient à reconsidérer totalement, cette tâche pourrait devenir inutile.

Raisonnements utilisés

Quelle que soit l'expression physique des données actuelles, on s'efforcera de les modéliser sous la forme d'un MLD « relationnel ». Des outils de « reverse engineering » (cf. Chap. 18Chapitre 18 Outils pour la mise en œuvre de Merise) sont particulièrement utiles pour cette tâche.

Objectifs et résultats attendus

Il ne suffit pas de décrire le système d'information actuel du domaine étudié ; il faut porter un jugement lucide sur ce système :

• Quels sont les points à préserver ?

• Quels sont ses dysfonctionnements ?

  • Sur le plan technique : obsolescence ou inadéquation du matériel ; difficultés pour exploiter ou maintenir les systèmes informatiques…
  • Sur le plan organisationnel : lourdeur du fonctionnement, insatisfaction grandissante des utilisateurs ou développement de circuits parallèles.
  • En matière de gestion : décalage important entre les choix de gestion actuellement mis en œuvre et ceux correspondant au système d'information actuellement opérationnel.

L'analyse points forts-points faibles tiendra compte des différents interlocuteurs dont les jugements peuvent être différents ; l'équipe de conception peut, elle-même, apporter des éléments critiques intéressants.

Objectifs et résultats attendus

Les interviews ont été l'occasion non seulement de recueillir les avis sur la situation actuelle, mais aussi d'entendre les besoins exprimés par les gestionnaires et les utilisateurs. Ces souhaits et attentes serviront de matière première à l'élaboration des solutions futures.

Raisonnements utilisés

Les besoins exprimés doivent être qualifiés, classés par nature et par thème, hiérarchisés et priorisés. Leur présentation peut être assortie de commentaires du groupe de projet, en particulier sur la compatibilité de ces souhaits et attentes avec les orientations générales du projet rappelées dans la phase de lancement.

Cette phase se concrétisera par l'élaboration de plusieurs modèles du futur système d'information du domaine :

• Modèle conceptuel des données (MCD).
• Modèle conceptuel des traitements (MCT).
• Modèle organisationnel des données (MOD).
• Modèle(s) organisationnel(s) des traitements (MOT).

Mais auparavant, il est nécessaire de clarifier les orientations du futur système d'information.

Lors du lancement, l'équipe de projet aura recueilli les orientations générales du projet, provenant du schéma directeur ou du groupe de pilotage. L'analyse de l'existant a permis de rencontrer des gestionnaires et des utilisateurs en prise avec leur système d'information actuel au quotidien. Ils ont formulé des souhaits et des attentes concernant le futur système d'information.

Ces orientations, objectifs, contraintes, souhaits, attentes constituent souvent un ensemble volumineux, hétéroclite, parfois contradictoire qu'il est nécessaire de trier et de structurer.

Pour guider efficacement toutes les étapes suivantes, les objectifs et les contraintes doivent être peu nombreux, immédiatement compréhensibles et cohérents entre eux. L'équipe de projet doit donc faire un travail de synthèse pour dégager les objectifs significatifs.

Sur cette base affermie, l'équipe de projet élaborera les différents modèles du futur système d'information, selon le schéma de la figure 15.6.

Objectifs et résultats attendus

Le modèle conceptuel de données formalise la signification des principaux concepts et informations qui seront utilisés pour le système d'information futur.

Raisonnements utilisés

Pour construire le futur MCD, l'équipe de projet applique l'ensemble des règles de construction d'un modèle conceptuel de données.

Le modèle spécifié comporte :

• les entités avec leur identifiant et quelques propriétés ;
• les relations avec leurs éventuelles propriétés et cardinalités.

On procède souvent à la construction directe du futur MCD, en précisant éventuellement les concepts déjà utilisés dans le passé et ceux nouveaux dans le domaine. On constate souvent une grande similitude entre MCD actuel et MCD futur pour le choix des principales entités et relations ; c'est un élément de grande stabilité dans l'entreprise.

En pratique, on aura recours à une approche plutôt inductive s'appuyant d'une part sur des structures issues des données actuelles, d'autre part sur les concepts métier évoqués par les gestionnaires et les utilisateurs dans leurs discours, leurs écrits ou sur des documents circulant dans l'entreprise, et recueillis lors des interviews.

Objectifs et résultats attendus

L'objectif est de spécifier le fonctionnement général du domaine conformément aux nouvelles orientations de gestion et sans référence explicite à l'organisation des ressources qui seront utilisées.

Le résultat attendu est un modèle conceptuel de traitements comprenant :

• La liste des acteurs ainsi que les événements émis et les résultats reçus.
• La liste des processus et les événements déclencheurs.
• Le diagramme d'enchaînement des opérations dans le nouveau système.
• La description succincte du contenu de chaque opération.

En étude préalable, le MCT futur permet surtout de confirmer les limites du domaine en exprimant formellement les fonctions remplies par celui-ci, puis de servir de point de départ à l'élaboration de solutions organisationnelles.

Raisonnements utilisés

Le modèle conceptuel de traitements se spécifie conformément aux règles du formalisme.

Un modèle conceptuel de traitements conçu dans une étude préalable met en évidence les processus majeurs (ceux qui sont retenus comme représentatifs), décrivant les opérations et leurs enchaînements. Le concepteur porte alors plus d'attention à l'ordonnancement des opérations qu'à la description détaillée du contenu des messages et des opérations.

Objectifs et résultats attendus

L'équipe de projet doit régulièrement s'assurer que les modélisations des données et des traitements effectuées respectent une cohérence mutuelle. En particulier, on vérifie la convergence des deux modèles sur les concepts retenus comme représentatifs dans le sous-ensemble d'étude.

Raisonnements utilisés

On met en œuvre la technique de relecture croisée présentée au chapitre 11Chapitre 11 Confrontation données / traitements.

Objectifs et résultats attendus

En étude préalable, le modèle organisationnel des traitements joue un rôle fondamental. Nous avons vu précédemment que le niveau conceptuel exprime un caractère général et de stabilité. Le niveau organisationnel permet d'exprimer la variété des solutions proposées, conformément aux orientations d'organisation. Pour chaque solution d'organisation envisagée, le concepteur produit :

• Une définition des postes avec leurs ressources humaines et techniques.
• La description des procédures organisationnelles présentant l'enchaînement des principales tâches représentatives de l'activité du domaine, en indiquant leur fréquence d'utilisation.
• L'illustration éventuelle de quelques tâches automatisées considérées comme critiques à l'aide d'une maquette.

L'élaboration des modèles organisationnels de traitements est une des principales difficultés de l'étude préalable : la description des différentes tâches doit être suffisamment explicite pour que l'utilisateur puisse étayer son choix, sans pour cela exiger un travail trop détaillé et trop complexe.

Raisonnements utilisés

Chaque proposition de modèle organisationnel de traitements est exprimée conformément aux règles du formalisme. Le concepteur s'efforcera d'élaborer différentes variantes en jouant sur :

• la diversité des postes et leur environnement informatique,
• le degré d'automatisation,
• les enchaînements entre tâches.

Objectifs et résultats attendus

Répercuter sur le MCD les choix d'organisation spécifiés dans les MOT et préciser ainsi la future organisation des données à mémoriser.

Raisonnements utilisés

S'exprimant dans le même formalisme que le MCD, le MOD en apparaît plus comme le prolongement que comme un nouveau modèle.

La production d'un MOD n'est pratiquement nécessaire qu'en cas de répartition organisationnelle (cf. Chap. 10Chapitre 10 Modélisation organisationnelle des données).

Objectifs et résultats attendus

Il est important de s'assurer que les modèles précédemment élaborés, MOD et MOT, peuvent fonctionner ensemble, constituant un système d'information cohérent. On vérifie globalement que les traitements disposent bien des données nécessaires (entités, relations) et que les données modélisées ont toutes une utilité dans les traitements. En étude préalable, le MOD se différenciant très peu du MCD, on effectue fréquemment cette confrontation entre le MCD et le MOT.

Cette confrontation permet d'obtenir une liste de diagnostics d'anomalies concernant le MCD-MOD et le MOT. En pratique, cette cohérence est réalisée en continu, à l'issue de la modélisation de chaque procédure organisationnelle.

Raisonnements utilisés

En étude préalable, on ne connaît pas en général la totalité des propriétés. La technique à utiliser est donc celle de la grille de cohérence globale présentée au chapitre 11Chapitre 11 Confrontation données / traitements.

Cette technique permet à l'équipe de projet de repérer elle-même et de corriger de nombreux problèmes. Il est donc conseillé de procéder à ces contrôles avant de soumettre les différents modèles à la validation des gestionnaires et des utilisateurs

Objectifs et résultats attendus

Pour valider la phase de conception des solutions, il est nécessaire de pouvoir présenter le futur système d'information aux différentes parties prenantes du projet. Cette validation devra mettre l'accent sur les choix retenus dans les différents modèles, les caractères distinctifs entre les différentes variantes et les choix appelant décision de la part des gestionnaires et des utilisateurs.

L'ensemble des modèles traduisant les solutions proposées pour le futur système d'information est exprimé dans un formalisme certes rigoureux et concis, mais pouvant parfois apparaître comme trop abstrait. L'équipe de projet devra donc s'efforcer d'en faire une présentation compréhensible et commentée, en particulier pour le MCD.

Cette phase se décompose en sept tâches présentées à la figure 15.7.

Objectifs et résultats attendus

Cette tâche consiste à :

• Estimer le volume global des futures données à mémoriser.
• Évaluer la future charge du système informatique directement liée à l'accès aux données à partir des traitements.

Ce chiffrage, évidemment sommaire, servira à dimensionner les ressources informatiques proposées dans la tâche suivante.

Raisonnements utilisés

Pour l'estimation du volume des données, le concepteur travaille sur le MOD et applique la démarche de quantification (cf. Chap. 10Chapitre 10 Modélisation organisationnelle des données). Il peut éventuellement effectuer ce chiffrage sur le MLD brut, après transformation. L'ensemble des propriétés n'étant pas défini, le concepteur pourra procéder à une estimation globale de la taille des entités et des relations.

Pour l'estimation des accès, le concepteur pourra s'appuyer sur les actions issues des grilles de cohérence de la confrontation MOD / MOT de la phase précédente. Il prêtera une attention particulière aux tâches du MOT à fréquence élevée ou à temps de réponse exigeant ainsi qu'aux tâches à volume de données important.

Objectifs et résultats attendus

Dans cette tâche, le concepteur définit l'architecture du système informatique qui supportera le futur système d'information.

Chaque solution s'exprime, entre autres, par :

• le type d'architecture envisagée (centralisée, client-serveur, intranet…) ;
• les nombre, type et répartition des postes utilisateurs (clients) ;
• les nombre, type et répartition des serveurs ;
• les capacités de mémorisation des données ;
• le dimensionnement des réseaux de télécommunication ;
• les logiciels de base utilisés (système d'exploitation, SGBD, langages…).

L'importance et les résultats attendus de cette tâche varieront selon qu'il s'agit d'un système existant (éventuellement à étendre) ou d'un nouveau système.

Raisonnements utilisés

Le problème abordé n'implique pas directement des raisonnements propres à la méthode Merise. Il fait appel à des connaissances plus informatiques sur les possibilités des différents matériels. On pourra se référer à des éléments méthodologiques spécifiques (méthode TACT [Alakl & Lalanne 89]).

Objectifs et résultats attendus

Cette tâche consiste à définir le processus de transition de systèmes lors de la mise en service. Le concepteur doit clairement définir la manière dont s'effectuera le passage entre le fonctionnement actuel et le fonctionnement futur, surtout si l'organisation doit profondément évoluer. Il peut opter pour différents modes.

• le basculement instantané ;
• le rodage sur un site pilote ;
• l'installation progressive des fonctions ;
• le fonctionnement en double.

Ces différents modes de mise en service peuvent, dans certaines situations, être mixés.

Raisonnements utilisés

Quelle que soit la solution choisie, le concepteur l'exprime en utilisant les règles et principes d'un modèle organisationnel de traitements. Le choix d'un mode de mise en service s'avère parfois assez délicat, et peut avoir des conséquences sur la viabilité de la solution organisationnelle normale retenue pour le futur système en termes de risques, de délais et de coûts. C'est pourquoi ces principes doivent être définis dès l'étude préalable.

Objectifs et résultats attendus

Il s'agit de préciser comment seront conduites les étapes ultérieures, en particulier les études détaillée et technique, la réalisation et la mise en service.

L'équipe de projet s'attachera à préciser les points suivants :

• découpage en sous-projets ou lots (cf. Principes généraux de la démarche) ;
• préconisation ou contraintes d'enchaînement du développement ;
• modalités de développement (interne, accompagné, sous-traité).

Raisonnements utilisés

Le concepteur pourra s'appuyer sur les MCT et MOT pour définir l'éventuel découpage en lots ou sous-projets qui seront eux-mêmes exprimés sous la forme de MOT et MOD.

Objectifs et résultats attendus

À partir de l'ensemble de toutes les spécifications élaborées dans les tâches précédentes, il s'agit de fournir des évaluations sur les délais concernant les étapes suivantes (étude détaillée et étude technique, réalisation, mise en service…) et sur les différents coûts associés (matériel, logiciel, personnel).

Le concepteur présente les postes de coût associés aux différentes composantes des étapes ultérieures.

Ces coûts peuvent être exprimés en unités monétaires ou en unités de ressources humaines. De la même façon, on établira un planning prévisionnel, éventuellement en dates relatives, pour les étapes ultérieures.

Raisonnements utilisés

L'évaluation des charges fait appel à des raisonnements et des modèles d'estimations que nous ne développerons pas ici et qui pourraient faire l'objet d'un ouvrage spécifique. Plusieurs méthodes de conduite de projet proposent de tels modèles dont beaucoup restent encore « protégés » comme savoir-faire des sociétés utilisatrices. L'évaluation du volume de l'étude détaillée peut s'appuyer sur le nombre de tâches à automatiser, pondéré par un coefficient grossier de complexité de la tâche.

Le planning sera représenté par un diagramme de Gantt ou un réseau Pert.

Objectifs et résultats attendus

Il s'agit ici d'exposer comment les différentes solutions répondent aux objectifs et aux contraintes retenus précédemment pour le système d'information, en particulier dans les phases de lancement et de conception des solutions.

Raisonnements utilisés

La nature même de la tâche d'appréciation ne relève pas directement des raisonnements formels de la méthode Merise. Le concepteur a cependant intérêt à s'appuyer sur l'ensemble des modèles élaborés dans les tâches précédentes.

Objectifs et résultats attendus

Il s'agit d'élaborer les documents permettant la prise de décision par les responsables de l'organisme, en particulier ceux qui sont présents dans le comité de pilotage. Le rapport final d'étude préalable se compose habituellement de deux documents.

• Le dossier de choix, un document de synthèse d'environ 30 pages, destiné au groupe de pilotage afin d'étayer sa prise de décision.
• Le dossier d'étude préalable qui réunit l'ensemble des documents élaborés au fur et à mesure de l'étape.

Raisonnements utilisés

Des plans types ont été élaborés soit par des sociétés de service, soit par les services méthode de certaines entreprises ou administrations.

Cette étape n'appartient plus formellement à l'étape, mais vient la conclure. Le groupe de projet a remis au groupe de pilotage les dossiers de fin d'étude préalable après avis du groupe de validation. Il appartient donc au groupe de pilotage de se prononcer sur la suite à donner au projet.

Selon le cas, cela pourra se traduire par :

• Le choix de développement d'une des solutions proposées.
• La demande d'un complément d'étude pour mieux départager certaines solutions.
• Le report ou l'abandon du projet.

L'étude préalable, en proposant des solutions, a permis au groupe de pilotage de choisir le profil général du futur système d'information. Cependant, les spécifications élaborées sont insuffisantes pour permettre une réalisation immédiate.

L'étude détaillée viendra donc étendre l'étude préalable, avec pour objectifs :

• La description de tous les processus composant le fonctionnement du futur système.
• La définition exhaustive des informations utilisées et mémorisées.
• La spécification complète des tâches à effectuer, en particulier pour celles à informatiser.
• La description des procédures exceptionnelles, les phases transitoires et le fonctionnement dégradé.

L'étude détaillée permet de spécifier l'intégralité du fonctionnement du futur système d'information organisationnel.

L'étude détaillée produit ainsi un véritable cahier des charges utilisateur et constitue la base de l'engagement que prend le concepteur vis-à-vis de l'utilisateur.

L'étude détaillée peut être découpée en plusieurs sous-projets sur la base des propositions de scénarios approuvés dans l'étude préalable. Chaque sous-projet sera conduit selon la démarche de la phase.

L'étude détaillée est menée en deux phases majeures : une phase de spécifications générales et une phase de spécifications détaillées. La phase de spécifications générales permet d'étendre les modélisations de l'étude préalable à l'ensemble de l'activité étudiée. La phase de spécifications détaillées fournit une description détaillée du fonctionnement du futur système d'information tel qu'il sera perçu par les futurs utilisateurs.

Outre cette analyse détaillée du fonctionnement « normal » du futur système d'information, le concepteur devra également spécifier :

• Les procédures organisationnelles de la mise en service permettant de passer du fonctionnement du système actuel au système futur, ou procédures transitoires.
• Les procédures organisationnelles à appliquer lors d'une indisponibilité des ressources informatiques, ou procédures de secours.

L'étude détaillée se conclut enfin par la réactualisation des estimations et la rédaction du rapport final. La figure 15.8 présente l'enchaînement des phases de l'étude détaillée.

Cette phase vise à étendre, généraliser les spécifications de l'étude préalable à l'ensemble du domaine retenu pour l'étude détaillée. Cette phase se décompose en quatre tâches (voir figure 15.9).

Objectifs et résultats attendus

L'objectif de cette tâche est de compléter le modèle conceptuel de données par les concepts secondaires dont la modélisation n'a pas été prise en compte lors de l'étude préalable et d'enrichir la liste des propriétés des entités et des relations du modèle.

Raisonnements utilisés

Le concepteur pourra faire appel à des modélisations avancées : sous-types, contraintes de valeurs et interrelations, règles.

Objectifs et résultats attendus

Il s'agit de reprendre le modèle conceptuel de traitement issu de l'étude préalable et le compléter par les concepts écartés du sous-ensemble représentatif. Les présentations des résultats sont semblables à celles de l'étude préalable ; seul le champ de l'analyse est étendu.

Raisonnements utilisés

Il s'agit de la reprise des éléments du modèle conceptuel de traitements et de la mise en œuvre de tous les formalismes associés à ce modèle.

Objectifs et résultats attendus

Il s'agit d'étendre le modèle organisationnel de données (MOD) de l'étude préalable, dans le cadre de la solution retenue pour le futur système.

Raisonnements utilisés

Le concepteur applique l'ensemble des raisonnements présentés au chapitre 10Chapitre 10 Modélisation organisationnelle des données, en particulier au niveau du type et de la taille des propriétés. En cas de répartition organisationnelle, il est indispensable de présenter les MOD locaux.

Objectifs et résultats attendus

Il s'agit de fournir une description complète de l'ensemble des procédures. Le modèle organisationnel de l'étude détaillée propose une description complète du fonctionnement du futur système, vu de l'utilisateur. Il devra donc être établi en étroite collaboration avec lui.

Raisonnements utilisés

L'intégralité des règles du formalisme organisationnel des traitements est appliquée. Le concepteur veillera à analyser tous les fonctionnements du futur système, y compris ceux correspondant à des situations particulières. Signalons que ce document servira de base pour la rédaction du manuel des procédures d'utilisation du futur système.

Objectifs et résultats attendus

Comme en étude préalable, cette tâche de confrontation permet d'une part de s'assurer de la cohérence dans l'utilité et l'utilisation des données dans les traitements, d'autre part d'enrichir les modélisations respectives.

Raisonnements utilisés

À ce stade, le concepteur utilise la grille de cohérence globale telle que présentée au chapitre 11Chapitre 11 Confrontation données / traitements.

Cette phase constitue le cœur de l'étude détaillée. C'est au cours de cette phase que se construit la description complète et détaillée du fonctionnement du futur système d'information dans sa partie externe, vu du système d'information organisationnelle. La figure 15.10 présente la décomposition en tâches.

Objectifs et résultats attendus

Cette tâche consiste à spécifier intégralement les traitements à effectuer pour informatiser les phases ou tâches interactives ou conversationnelles.

Cette description détaillée de l'informatisation d'une phase interactive correspond en fait à une première modélisation logique de traitement sous la forme de procédure logique. Si la tâche est relativement simple, spécifier la tâche sera équivalent à spécifier l'ULT associée à cette tâche. Si la phase est plus complexe, elle sera décomposée en tâches élémentaires, correspondant à des ULT, donnant naissance à une procédure logique.

Quel que soit le cas, pour chaque ULT, on précisera :

• La présentation détaillée de l'interface avec les informations correspondantes (écran, état, badge, ticket…).
• Les règles de traitement à appliquer (contrôles à la saisie, calculs arithmétiques et logiques, règles de présentation pour la restitution des informations).
• Les règles et les actions effectuées sur les données mémorisées à partir des informations utilisées dans l'ULT.
• Les messages et diagnostics d'erreurs propres à l'ULT.

Raisonnements utilisés

Le concepteur met en œuvre le premier niveau de modélisation logique des traitements. La spécification détaillée de chaque tâche, de chaque ULT est exprimée directement par le concepteur et s'enrichira lors du processus de confrontation détaillé. En fait, la tâche sera intégralement et correctement décrite à l'issue de la confrontation détaillée.

Pour cette tâche de spécification détaillée, l'utilisation d'outils de maquettage constitue aujourd'hui le moyen le plus efficace pour réaliser rapidement les spécifications externes de l'interface, assurer automatiquement la confrontation détaillée et faciliter la validation par les utilisateurs.

Objectifs et résultats attendus

Il s'agit de spécifier intégralement les traitements à effectuer pour des phases ou tâches à automatiser ne demandant que la ressource machine ; ces tâches sont souvent appelées batch. La différence majeure avec la spécification des tâches conversationnelles provient de l'absence de spécificité liée aux postes informatiques et à l'interactivité de l'interface.

Ces tâches automatiques concernent :

• La restitution d'états (statistiques, par exemple).
• La mise à jour en masse.
• L'archivage et l'épuration de la mémoire court terme.
• Le transfert entre systèmes.

Ces tâches concernant fréquemment la restitution de résultats, la principale spécification comporte :

• La présentation des résultats en fonction des souhaits des gestionnaires.
• Les calculs et algorithmes.
• Les actions sur les données.

Raisonnements utilisés

À la différence des tâches conversationnelles, l'absence d'interactivité rend moins nécessaire de détailler la procédure logique associée. Par contre, ce travail d'analyse logique des traitements devra s'effectuer lors de l'étude technique.

Objectifs et résultats attendus

Cette tâche consiste à confirmer définitivement la compatibilité entre les traitements à effectuer (les tâches ou les ULT primaires) et les données mémorisées (le modèle conceptuel/organisationnel de données).

À l'issue de cette opération de confrontation détaillée, et sous réserve qu'aucune modification ne soit intervenue sur les données ou les traitements suite à un enrichissement, le modèle conceptuel / organisationnel de données est déclaré cohérent par rapport aux tâches du modèle organisationnel de traitements représentées essentiellement par leur modèle externe.

En fait, le concepteur pratique un processus itératif :

• Confrontation.
• Enrichissement du modèle conceptuel / organisationnel de données.
• Enrichissement du modèle organisationnel de traitements.

Raisonnements utilisés

À partir de la description de la tâche ou des ULT la composant, le concepteur constitue le modèle externe et peut appliquer l'algorithme de confrontation détaillée présenté au chapitre 11 « Confrontation algorithmique détailléeConfrontation algorithmique détaillée ». Comme déjà rappelé, le recours à des outils de maquettage peut réaliser l'essentiel de ce travail.

Objectifs et résultats attendus

Il s'agit tout d'abord de prendre en compte les enrichissements issus de la confrontation et de compléter ce MOD pour en constituer la version définitive.

Raisonnements utilisés

L'équipe de projet confirme les choix concernant le MOD précédent :

• Prise en compte exhaustive des informations métier à mémoriser.
• Chiffrage des entités, des relations et des propriétés.
• Répartition sur les différents sites organisationnels.

L'équipe applique ces choix aux nouvelles informations du MCD validé. Elle complète enfin le MOD sous les trois aspects suivants :

• Propriétés exprimant des « états ».
• Prise en compte des durées de vie.
• Modèles organisationnels de données d'archives.

Ces procédures concernent la période de mise en service du nouveau système d'information et précisent les conditions dans lesquelles s'effectuera le transfert. Bien que provisoire, la spécification de ces procédures est indispensable à la réussite du futur système. La période de mise en service est une étape critique et il importe que son organisation en soit clairement exprimée. L'essentiel des spécifications propres à cette transition est du niveau organisationnel de traitements. Comme l'illustre la figure 15.11, on abordera les problèmes suivants :

• La récupération et le transfert des données.
• Les principes du basculement entre le système actuel et le système futur.
• Le ou les modèles organisationnels de traitements (MOT) durant la période transitoire.

Objectifs et résultats attendus

Il s'agit d'abord de définir la nature des informations à récupérer du système actuel, puis de spécifier les traitements prenant en charge le transfert, ainsi que celles qui permettent un chargement initial.

Dans de très nombreux cas, les utilisateurs désirent récupérer tout ou partie des informations existantes, mémorisées sous une forme informatique (transfert) ou manuelle (chargement initial).

Le concepteur spécifie, avec le même degré de détail que pour les tâches normales, l'ensemble des tâches permettant d'effectuer ce transfert ou ce chargement initial. Ces tâches sont généralement en batch.

En ce qui concerne les tâches de transfert, le concepteur doit exprimer :

• La structure des informations actuelles à récupérer (schéma de fichier, portion de schéma de base de données).
• Les éventuelles règles de traitement (contrôle de vraisemblance, filtrage préalable, concentration ou éclatement de valeurs…).
• Les éléments du modèle conceptuel futur concerné par cette mise à jour.
• Le volume à transférer.

En ce qui concerne les tâches de chargement initial, le concepteur doit exprimer :

• La nature des tâches (saisie transactionnelle directe, encodage en masse et mise à jour en différé).
• La présentation des informations à saisir (dessin d'écran ou de bordereau).
• Les règles de traitement.
• Le volume à saisir.

Raisonnements utilisés

Hormis le caractère provisoire de ces tâches, les raisonnements nécessaires à leur spécification sont ceux utilisés pour la spécification détaillée des tâches normales.

L'expression de ces tâches de transfert et chargement initial est indispensable pour évaluer correctement les charges liées à la mise en service.

Objectifs et résultats attendus

L'étude préalable avait permis de définir les principes de passage du système d'information actuel au système d'information futur.

L'étude détaillée doit spécifier en détail les différentes procédures de l'organisation provisoire, sous forme d'un ou plusieurs MOT transitoires.

Raisonnements utilisés

Le concepteur utilise intégralement les règles et formalismes d'élaboration d'un modèle organisationnel de traitements. Il doit cependant être attentif :

• Aux disponibilités partielles des ressources techniques de certains postes.
• À la faisabilité de certaines procédures (disponibilité des informations, ordonnancement des tâches).
• À l'appréciation de la charge de travail requise pour un poste.

Le modèle organisationnel du système en fonctionnement normal est fondé sur une disponibilité des ressources informatiques. En cas d'incident privant l'entreprise de ces ressources pour une durée plus ou moins longue, il est indispensable de prévoir les procédures de fonctionnement à appliquer. Ces dispositions concernent les utilisateurs ; elles ne préjugent pas des dispositifs techniques retenus pour prévenir de tels incidents ou pour en minimiser l'impact. La figure 15.12 présente les tâches de la démarche.

Objectifs et résultats attendus

Il s'agit de proposer et de décrire l'organisation à appliquer lors d'une indisponibilité des ressources informatiques. L'indisponibilité des ressources informatiques n'a que peu d'impact sur la structuration des informations mémorisées, mais elle remet totalement en cause l'équilibre manuel/informatisé.

Le concepteur doit définir le fonctionnement à adopter, donc proposer un modèle organisationnel spécifique. Il est indispensable de prévoir ces différentes procédures, car une improvisation lors de l'incident a toujours des conséquences néfastes, surtout si le taux d'automatisation est important avec des tâches en réponse immédiate. Différents types de stratégies peuvent être adoptés :

• L'attente.
• Le retour au manuel ; il faut alors spécifier complètement les nouvelles tâches à assurer (contenu, documents, répartition).

Raisonnements utilisés

L'expression de ce modèle organisationnel de traitements se fait avec les modélisations habituelles.

Objectifs et résultats attendus

Cette tâche consiste à spécifier dans quelles conditions s'effectuera la reprise des informations accumulées lors d'un incident. Suivant la stratégie retenue face à l'incident, le rattrapage se fera d'une façon « naturelle » ou devra être organisé.

Même si la solution retenue ne nécessite pas de formalisation particulière, le concepteur devra clairement préciser la conduite à tenir pour cette tâche de récupération.

Raisonnements utilisés

S'agissant essentiellement de spécification de tâches, le concepteur met en œuvre les raisonnements du modèle organisationnel des traitements, et plus particulièrement permettant la description détaillée d'une tâche.

Cette phase conclut l'étude détaillée par une validation générale des spécifications proposées, une réactualisation des estimations et de la planification des étapes suivantes et par la rédaction finale du dossier d'étude détaillée (figure 15.13).

Objectifs et résultats attendus

Cette tâche consiste à présenter au groupe de validation, représentant les gestionnaires et les utilisateurs, l'ensemble des spécifications générales et détaillées élaborées dans cette étape. Bien que de telles présentations partielles aient pu avoir lieu au cours de l'étape, seule cette dernière validation permet une véritable récapitulation de l'ensemble finalisé.

Cette présentation permet d'obtenir la validation du métier, indispensable à la poursuite du projet.

Raisonnements utilisés

Comme pour les validations précédentes, le groupe de projet doit être très attentif aux modalités de présentation en évitant le simple « déballage » des modélisations. La réussite du projet tient autant à la qualité de la validation qu'à la qualité des spécifications.

Objectifs et résultats attendus

Les spécifications détaillées des tâches à informatiser ainsi que la définition complète des données à mémoriser permettent d'affiner les précédentes estimations

Ces nouvelles estimations se traduisent par :

• Un chiffrage détaillé des charges de développement par tâche.
• Le choix, le dimensionnement et l'affectation des moyens de développement.
• La réactualisation du planning (découpage, répartition des tâches…).
• Le réajustement de l'architecture informatique envisagée.

Raisonnements utilisés

Le concepteur fait appel aux mêmes techniques déjà utilisées dans la tâche d'estimation en étude préalable.

Objectifs et résultats attendus

Le dossier d'étude détaillée matérialise l'ensemble des travaux réalisés dans les différentes phases de l'étude. Ce dossier peut comporter plusieurs documents :

• Une note de synthèse, destinée au groupe de pilotage, qui reprend les points essentiels du futur système ainsi que les éléments de chiffrage.
• Le rapport d'étude détaillé, destiné aux intervenants qui prendront en charge la suite du développement, qui comprend l'intégrale des spécifications générales et détaillées élaborées dans l'étape.
• Le contenu des spécifications réalisées avec un outil (modélisations, maquettes)

Ce dossier fournit :

• aux utilisateurs une description détaillée de leur futur système d'information ;
• aux informaticiens, la base pour l'élaboration des spécifications informatiques correspondantes ;
• aux organisateurs, les éléments pour la mise en place des nouvelles procédures.

Raisonnements utilisés

La rédaction de ce dossier est évidemment progressive au cours de l'étude détaillée.

Comme pour le dossier d'étude préalable, il existe des plans types qui facilitent l'élaboration des différents documents.

L'étude détaillée a permis d'obtenir l'ensemble des spécifications du futur système, du point de vue de l'utilisateur. L'étude technique constitue le complément de spécifications informatiques nécessaires pour assurer la réalisation du futur système.

L'étude technique permet de définir complètement :

• La structure physique des données (fichiers ou bases de données).
• Les programmes, modules ou composants à réaliser ou intégrer.
• Les procédures techniques de sécurité.
• La planification de la réalisation.

Les raisonnements utilisés sont :

• La modélisation logique puis physique de données (MLD, MPD).
• La modélisation logique puis physique de traitements (MLT, MPT).

L'étude technique permet d'établir le cahier des charges de réalisation qui, en association avec le cahier des charges utilisateurs, constitue le document contractuel pour la production de logiciels.

L'étude technique est menée en deux phases : tout d'abord la définition des architectures de données et de programmes, et ensuite la préparation de la réalisation (voir figure 15.14).

Bien que l'étude technique soit une étape importante et indispensable dans la démarche de conception et de réalisation pour l'informatisation d'un système d'information, nous ne lui accorderons pas, dans le cadre de cet ouvrage centré sur Merise, de développements aussi importants que pour les étapes précédentes. En effet, nombre des raisonnements utilisés relèvent plus du génie logiciel que de l'ingénierie de système d'information et sont développés dans d'autres ouvrages.

Cette phase, conduisant à la définition des architectures tant au niveau des données que des programmes, se décompose en deux tâches majeures présentées à la figure 15.15.

Objectifs et résultats attendus

Il s'agit de définir une description informatique opérationnelle de l'organisation des données mémorisées. Cette organisation doit être d'une part conforme à la sémantique exprimée par le modèle organisationnel de données spécifié, d'autre part de permettre l'implantation sur le système informatique cible.

Selon les systèmes de gestion de bases de données (SGBD) utilisés pour gérer les données, le concepteur définit :

• le schéma de la base ;
• l'allocation des espaces physiques ;
• les dispositifs de protection d'accès et de confidentialité ;
• les procédures de sécurité.

Raisonnements utilisés

Le MOD spécifié en étude détaillée, est d'abord traduit en MLD relationnel « brut » selon les règles présentées au chapitre 13Chapitre 13 Modélisation Logique des Données.

Puis, en respectant des objectifs généraux de performances d'accès et de stockage, le concepteur réalise une optimisation en tenant compte des possibilités techniques du matériel et du logiciel de gestion des données retenu, en appliquant les principes présentés au chapitre l4Chapitre 14 Optimisation des Modèles de Données.

Ce modèle est enfin transcrit dans le langage du SGBD.

La plupart des outils évoqués au chapitre 18Chapitre 18 Outils pour la mise en œuvre de Merise automatisent en partie ces travaux.

Objectifs et résultats attendus

Il s'agit de définir une description complète de la structuration technique du logiciel en fonction des outils de production de logiciels, ainsi que des logiciels de développement utilisés.

Suivant la technologie et les outils qui seront utilisés pour la production, le concepteur spécifie :

• Les composants logiciels à construire ou à utiliser.
• Les dialogues, modules ou transactions à programmer.
• L'enchaînement ou les échanges entre les différents modules ou composants.
• La répartition des traitements entre client et serveur.
• La description technique de chaque module ou composant (l'expression informatique des algorithmes, l'accès aux données, les sécurités techniques).

Raisonnements utilisés

Pour élaborer cette architecture et le découpage en modules ou composants, le concepteur peut certes s'appuyer sur la modélisation logique des traitements. Il peut également faire appel à des approches plus de génie logiciel proposées par les méthodes objet. Dans cette tâche, le concepteur tient compte essentiellement des capacités des logiciels systèmes et du matériel.

Dans la mesure où l'enchaînement des dialogues exprimés dans l'étude détaillée prend en compte des éléments d'ergonomie attachés à différents postes de travail, le concepteur s'efforcera de respecter cet enchaînement. Les spécifications des transactions devront également respecter les standards de qualité définis dans l'entreprise (structure standard, appellation des programmes et des données, commentaires…).

Pour la production d'états, la disponibilité d'outil de production rapide de rapports ou de langage d'interrogation doit être prise en compte par le concepteur.

Cette phase regroupe un ensemble de préconisations nécessaires pour aborder l'étape de réalisation. La figure 15.16 décline ces différentes tâches qui ne seront que succinctement décrites.

Il s'agit de recenser le ou les outils de réalisation retenus et d'en mentionner les possibilités et les contraintes. Rappelons que le concepteur avait déjà partiellement tenu compte de ces aspects dans les spécifications détaillées.

Quelle que soit la méthode de génie logiciel appliquée, il est nécessaire d'énoncer l'ensemble des règles de construction et d'écriture du logiciel qui devront être respectées.

Ces règles peuvent entre autres porter sur :

• La structuration de la programmation.
• Le nommage et les commentaires.
• La documentation du code.

Dans cette tâche, on définit les modalités des tests qui seront appliqués dans l'étape de production du logiciel :

• Test unitaire.
• Test d'intégration.
• Jeu d'essais.
• Gestion des versions et des configurations logicielles.

Il s'agit, sur les principes déjà esquissés en étude préalable (scénarios), de fixer l'organisation générale de l'étape de production du logiciel en précisant :

• La répartition des travaux entre les équipes.
• Le planning général de production du logiciel.
• Les modalités d'assurance qualité.

L'ensemble des spécifications précédentes, étude détaillée et étude technique, proposait un système d'information « papier ». Cette étape consiste à réaliser concrètement dans des langages, sur du matériel, l'ensemble de ces spécifications. À l'issue de cette étape, matérialisée par une recette technique, l'ensemble du système devra être conforme aux spécifications fonctionnelles et techniques.

Nous ne développerons pas les différentes tâches de la production du logiciel. Tous les savoir-faire de génie logiciel et les méthodes de conduite de projet décrivent abondamment cette étape. De plus, les raisonnements de conception spécifiques à Merise ne concernent plus cette étape.

Rappelons toutefois que, malgré la rapide évolution des outils d'aide à la réalisation et les efforts de réutilisation de composants logiciels, cette étape reste encore l'une des plus lourdes dans la démarche d'informatisation d'un système d'information organisationnel.

La figure 15.17 présente les principales phases usuelles de cette étape.

L'ensemble des programmes développés et testés associés à une structure d'accueil de données mémorisées constitue une application informatique. Sa greffe sur l'entreprise, en lui ajoutant sa dimension organisationnelle, permet à cette application de devenir le support d'un système d'information.

Aussi, un soin tout particulier doit-il être apporté pour la véritable naissance du futur système d'information. C'est au cours de cette étape que la responsabilité du système d'information est transférée du groupe de conception et de réalisation (maîtrise d'œuvre), aux gestionnaires et aux utilisateurs (maîtrise d'ouvrage).

L'objectif principal de cette étape est de rendre opérationnel le système d'information. À l'issue de cette étape, les parties prenantes dans le projet peuvent se prononcer sur la recette définitive, et dissoudre la plupart des structures spécifiques ayant permis la concrétisation du projet. Le fonctionnement de l'application informatique relève alors de l'exploitation.

Si l'on constate, dans la pratique de la démarche de Merise, une certaine convergence sur les découpages adoptés pour les étapes de conception, il faut admettre que cette étape de mise en service, lorsqu'elle est mentionnée, peut recouvrir une très grande variété de contenus et découpages.

La figure 15.18 propose un déroulement en quatre phases. Toutefois, compte tenu de la remarque précédente, nous ne développerons que très succinctement les tâches qui les composent.

Il s'agit de déterminer un scénario détaillé et réactualisé de l'ensemble des travaux nécessaires pour la mise en exploitation du nouveau système. Lors de l'étude préalable, le concepteur avait proposé une esquisse des moyens à prévoir pour l'installation. Depuis cette étape, les spécifications se sont affinées ; tous ces éléments permettent de produire un planning où toutes les tâches de mise en service sont explicitées. Ce scénario actualisé contient quatre calendriers particuliers :

• Mise en place des moyens techniques.
• Mise en place de l'organisation.
• Mise en place des ressources humaines.
• Mise en place de l'information externe.

La mise en place des ressources touche aussi bien les ressources techniques que les ressources humaines.

On retrouve dans cette phase les tâches suivantes :

• La mise en place des moyens techniques.
• La préparation des jeux d'essai.
• La rédaction de la documentation utilisateur.
• La mise en place de la nouvelle organisation.
• La mise en place des ressources humaines.

Cette phase regroupe un ensemble de tâches de formation et d'information qui doivent intervenir avant le lancement effectif du système d'information.

Ces tâches concernent entre autres :

• La formation du personnel utilisateur et informaticien.
• L'information interne.
• L'information externe.
• La mise au point du plan de lancement détaillé.

Cette phase correspond à l'installation de l'application qui va progressivement devenir opérationnelle.

On distingue globalement les tâches suivantes :

• La recette avant lancement qui s'applique sur les jeux d'essais précédemment constitués.
• Le lancement effectif conformément au scénario établi.
• Une période probatoire durant laquelle les équipes de développement interviennent pour corriger les inévitables « pannes de jeunesse » et apporter les conseils nécessaires à une bonne utilisation du nouveau système.
• La recette définitive prononcée par la maîtrise d'ouvrage qui conclut à l'acceptation totale du nouveau système d'information et met un terme à la mission de la maîtrise d'œuvre.

Les démarches rapides sont apparues dans la décennie 90 à la fois en réponse aux critiques de lourdeur à l'encontre des démarches classiques et sous l'influence de l'évolution des technologies et des nouvelles contraintes, en particulier économiques.

Aujourd'hui, ces deux approches doivent être considérées comme complémentaires, chacune adaptée à des catégories de projets différentes.

Les principales critiques faites à l'approche classique trouvent essentiellement leurs justifications dans les excès et les erreurs de conduite de projets, surtout constatés dans les années 80 pour des projets de taille importante. On peut notamment citer :

• le dérapage des délais et des coûts ainsi que les dérives de contenu ;
• la nécessité d'un engagement technologique à long terme ;
• un cycle de conception / réalisation / mise en œuvre trop long, conduisant à un manque de visibilité et nécessitant des choix souvent présentés comme irréversibles.

En réalité, il est plus vraisemblable, sans nier les échecs passés, que ces défauts soient plus imputables à la nature des projets, à leur dimension et à leur complexité (dans certains cas non maîtrisable) qu'à la démarche proprement dite ou aux méthodes utilisées. Dans le domaine informatique, cette décennie 80 fut marquée par une volonté de généralisation et de mise en cohérence des systèmes d'information des entreprises et des administrations, engageant fortement leur stratégie, impliquant des remises en cause souvent lourdes des principes de gestion et d'organisation, nécessitant de nombreux préalables à l'engagement des projets informatiques. Or le plus souvent, ce sont ces projets informatiques qui ont supporté le coût et la responsabilité de l'ensemble de l'opération, renforçant encore plus l'impression de lourdeur et la difficulté de maîtriser objectifs et résultats.

La décennie 90 a principalement vu le micro-ordinateur s'imposer comme le poste informatique normal dans les environnements organisationnels. Ses capacités et sa puissance, alliées à une grande richesse et diversité de logiciels disponibles en ont fait un composant majeur tant dans les architectures client-serveur que intra/Internet. Du point de vue de l'utilisateur, cette généralisation du micro-ordinateur s'est traduite par :

• une standardisation de l'ergonomie visuelle et mentale liée aux environnements graphiques et en particulier à l'hégémonie de Windows ® ;
• une intégration des fonctionnalités (applications métier, bureautique, messagerie, communications, intra/Internet…) ;
• une popularisation de l'environnement informatique.

Bien que toutes les nombreuses évolutions technologiques aient pu influencer l'environnement de conception de systèmes d'information, nous retiendrons plus particulièrement :

• L'affirmation et la généralisation des SGBD relationnels.
• La richesse, la diversité et la puissance des outils de développement.
• L'essor de la programmation orientée objet et l'utilisation de composants réutilisables.
• La disponibilité d'outils de conception et de prototypage performants.
• L'ouverture des systèmes d'informations vers le Net.

Toujours dans cette décennie 90, sûrement sous l'effet de conditions économiques difficiles, les entreprises privilégient des projets dont la taille, l'ampleur et l'ambition sont notablement plus réduites qu'auparavant. La plupart des projets sont alors engagés selon une démarche et un management de projet très différents, en préconisant notamment :

• une participation active des utilisateurs ;
• un cycle itératif de conception/réalisation/amélioration ;
• l'exigence d'une maîtrise des coûts et des délais ;
• des équipes plus compactes, expérimentées et polyvalentes ;
• un contenu fonctionnel restreint et connu du projet ;
• un contexte de choix de gestion et d'organisation stable et explicité.

Cette démarche dite « Rapid Application Development » est apparue au début des années 90, en s'opposant aux démarches en cascade, jugées trop lourdes et trop contraignantes pour le développement d'applications petites et moyennes. Elle suppose qu'au début du processus de développement, l'utilisateur n'a qu'une idée très sommaire de ses besoins. Elle se propose donc de rendre l'expression et la spécification des besoins progressives et pratiquement simultanées avec la conception et la réalisation.

Cette démarche s'appuie sur :

• Des préconisations d'organisation du travail, où notamment les utilisateurs sont associés de manière continue à l'ensemble du cycle de développement.
• La définition préalable d'une enveloppe de budget temps et coût (« Faire ce que l'on peut avec ce que l'on donne » au lieu de « Donner ce qu'il faut pour faire ce que l'on veut »).
• L'utilisation systématique de techniques de maquettage - prototypage.
• Un découpage relativement fin de l'application dès le début du projet ; chaque fonction ou lot découpé suit les différentes phases de la démarche, jusqu'à la finalisation complète du projet.
• Des itérations successives, essentiellement localisées dans la phase de réalisation.

La figure 16.1 présente le découpage de la démarche RAD.

La démarche rapide de Merise proposée s'appuie sur :

• La démarche classique initialement préconisée dans la méthode Merise, en s'inspirant des principes de certaines de ses étapes, en raison de leurs caractères éprouvés pour la conduite de projets de taille moyenne ou importante.
• Les techniques de maquettage - prototypage, qui s'avèrent déterminantes dans les phases de spécifications détaillées pour permettre l'expression et la validation des besoins utilisateurs.
• La démarche RAD dont certains principes peuvent être utilisés, notamment pour l'approche itérative de la conception, pour le passage du maquettage - prototypage à la réalisation, pour le découpage de l'application en modules ainsi que pour l'organisation et la répartition des rôles dans le projet.

La démarche rapide de Merise se démarque toutefois d'une démarche exploratoire. Cette dernière se caractérise par l'absence de projet spécifié, par des itérations rapides entre le développement d'une proposition, l'utilisation d'un module, la recherche de son adéquation et sa correction. Cette démarche exploratoire, qui peut paraître séduisante pour certains informaticiens en raison de sa simplicité de mise en œuvre et des raccourcis méthodologiques, est peu compatible avec un système stabilisé et ne donne aucune garantie de pérennité de l'investissement effectué.

La démarche rapide de Merise proposée concerne essentiellement l'aménagement de la démarche et non les raisonnements exprimés par les différentes modélisations. Ces modèles et les formalismes qui permettent de les représenter constituent indéniablement le « génotype » de la méthode Merise. Ils sont spécifiques et adaptés à la nature du problème à traiter (la conception d'un système d'information) et indépendants du type de projet (taille et complexité, système informatique cible). Le respect de ces principes de modélisations joue un rôle fondamental dans la communication entre l'ensemble des partenaires impliqués dans la conception et le développement des systèmes d'information, et elles contribuent à l'amélioration de la qualité.

Aussi, dans la démarche rapide, ces modèles sont-ils conservés sans aucune modification des concepts types, des symbolisations graphiques et des règles de modélisation. Seuls leur usage, l'ampleur de la modélisation et le degré de détail sont adaptés au contexte de la conception rapide.

La démarche rapide se positionne uniquement sur la période de développement d'un projet. À l'instar de la démarche classique, elle se décompose en étapes, puis en phases au cours desquelles le concepteur met en œuvre les différents raisonnements de conception et de réalisation.

La figure 16.2 présente les quatre étapes de la démarche rapide.

Cette étape doit réunir les objectifs fondamentaux de l'étude préalable et des spécifications générales de la démarche « classique », et ce dans un délai relativement restreint.

La définition générale du système doit tout d'abord permettre au concepteur-réalisateur de comprendre très tôt l'étendue et la complexité du projet, afin d'en évaluer la charge et le délai ou si le projet envisagé tient dans les budgets fixés a priori. Elle doit ensuite s'efforcer de formaliser un avant-projet ou une proposition destinée à la maîtrise d'ouvrage permettant de s'assurer de la compréhension réciproque du projet. Elle permet enfin d'esquisser des spécifications générales de l'application.

L'étape de définition générale du système se décompose en deux phases présentées sur la figure 16.3.

Elle est concrétisée par la production de deux documents.

Cette phase très courte doit permettre au concepteur-réalisateur d'effectuer une appréciation rapide du contour et des enjeux, indiquant une faisabilité globale du projet. L'évaluation sommaire résultante est communiquée au maître d'ouvrage.

Il s'agit globalement de qualifier la nature et le contenu du projet, à savoir :

• Quelles sont l'étendue et la complexité estimées du projet ?
• Le projet a-t-il des objectifs bien définis ?
• Les incertitudes organisationnelles et informatiques sont-elles limitées ?
• Ce projet relève-t-il vraiment d'un développement rapide ?
• Connaît-on assez bien le domaine d'activité ?
• A-t-on fait quelque chose d'équivalent ?
• Les utilisateurs compétents sont-ils suffisamment disponibles ?

L'objectif est de recenser rapidement les principales fonctions à informatiser et délimiter ainsi le périmètre fonctionnel du projet. Cette tâche est également l'occasion de mieux connaître les motifs de l'informatisation, les souhaits et attentes des utilisateurs, ainsi que les contraintes d'environnement organisationnelles et informatiques.

On utilisera essentiellement une modélisation à base de diagramme des flux (chapitre 5Chapitre 5 Découpage en domaines et analyse des flux).

Nous suggérons de construire deux diagrammes des flux :

• Un premier diagramme de type contextuel représentant les échanges du système avec les acteurs de son environnement.
• Un second explicitant le fonctionnement général du système étudié, de type macro-MCT.

Ainsi apprécié en termes de complexité et fonctionnalités, le concepteur peut mieux appréhender les enjeux de ce projet et justifier l'adoption d'une démarche rapide. Le concepteur évalue également la compatibilité globale de l'enveloppe budgétaire envisagée (en temps et en ressources) avec le contour général du projet.

Les conclusions de cette phase sont synthétisées dans une note de quelques pages résumant les lignes directrices du projet. Son contenu doit, d'une part permettre au maître d'ouvrage de s'assurer que sa demande a été globalement cernée, d'autre part lui donner en retour des éléments d'évaluation sur la taille du projet. À ce niveau, il ne peut y avoir aucun élément de solution proposé.

Au cours de cette phase, le concepteur va compléter sa connaissance des activités du champ de l'étude pour élaborer les spécifications générales de la future application, notamment définir :

• les données à mémoriser ;
• les fonctions à informatiser ;
• les éventuelles interrelations avec d'autres systèmes.

La figure 16.4 présente les tâches qui sont menées en cohérence mutuelle.

Sur la base de cette définition des fonctionnalités générales, le concepteur pourra procéder à un découpage en « modules » pour préparer l'étape suivante.

Cette modélisation reste incontestablement la plus efficace pour capter et formaliser efficacement la signification générale des informations utilisées. Au niveau de cette phase, un MCD doit être quasiment complet et vérifié en termes d'entités et de relations ; on peut toutefois se satisfaire d'une définition partielle des propriétés. Cet aspect structurel est assez important, car d'une part il fournit le support du dialogue sur la compréhension des informations utilisées (même s'il n'est pas explicitement communiqué aux utilisateurs), d'autre part il sert de point de départ pour la construction future des tables (même si un travail d'optimisation est nécessaire ultérieurement).

Dans des spécifications générales, il est indispensable d'établir la liste des fonctions à informatiser et d'en présenter des schémas d'enchaînement fonctionnel d'utilisation. Bien que l'on puisse se contenter d'une simple énumération, une représentation sous la forme d'un diagramme général de phases ou macro MOT fournit un complément explicatif efficace.

Dans la démarche rapide, par rapport au MOT classique, ce type de modèle sera appliqué en :

• négligeant éventuellement la répartition en postes ;
• s'intéressant d'abord aux phases interactives directement liées à une procédure ;
• gardant un niveau de détail compatible avec les spécifications générales.

L'utilisation d'une telle technique n'est pas obligatoire. Elle reste à l'appréciation du concepteur selon la complexité du système et les nécessités de formalisation de la solution pour en faciliter la compréhension mutuelle.

Cette tâche conclut l'étape de définition générale du système qui doit fournir un descriptif général de la future application, présenté sous la forme d'un dossier de spécifications générales.

Il est évident que la taille de ce dossier est proportionnelle à celle du projet. Il est hors de propos de demander la production de documents aussi épais que ceux d'une étude destinée à un grand ou moyen projet ; l'excès inverse (c'est-à-dire pas de documentation de spécifications générales) est tout aussi critiquable.

Le contenu type d'un tel document pourrait être :

• un rappel de la nature de la demande et du contexte du projet ;
• la présentation des processus à informatiser (diagrammes de flux) ;
• les principales fonctionnalités proposées (macro-MOT) ;
• les informations gérées informatiquement (MCD) ;
• les implications matérielles (configuration) ;
• une réévaluation de la durée.

Cette étape doit fournir les spécifications complètes du contenu de l'application à réaliser, des points de vue de l'utilisateur et de l'informaticien. Dans la démarche proposée, cette étape est principalement basée sur l'utilisation de maquettage dynamique (pour tout ou partie du projet).

Sur la base des spécifications générales élaborées lors de l'étape précédente, le concepteur va imaginer, pour les fonctionnalités déterminées, des enchaînements de dialogues possibles. Il va également devoir définir les données associées à la maquette.

À l'issue de cette étape, le concepteur doit obtenir l'accord des futurs utilisateurs sur le contenu et la forme de l'application à livrer.

Si le passage de la conception détaillée à la réalisation s'effectue par module, l'accord sur les spécifications détaillées s'effectuera au niveau de chaque module.

L'étape de conception détaillée de l'application se décompose en deux phases itératives comme l'illustre la figure 16.5 :

Elle se concrétise par la maquette associée à un dossier de spécifications détaillées.

L'une des originalités de la démarche proposée est le recours quasiment systématique aux techniques de maquettage dynamique rendues facilement utilisables soit avec les environnements de développement disponibles en micro-informatique, soit avec des outils de conceptions disposant de cette fonctionnalité (cf. chapitre 18Chapitre 18 Outils pour la mise en œuvre de Merise). Cette technique permet d'exprimer en détail les spécifications externes de la future application et d'améliorer ainsi la compréhension des besoins des utilisateurs, donc de minimiser les risques ultérieurs de développement.

Cette phase de développement de la maquette, fortement itérative, se décompose en tâches présentées à la figure 16.6.

La place importante prise par le maquettage - prototypage nous conduit à préciser le vocabulaire et l'usage de cette technique. Nous distinguons la maquette du prototype. Un prototype est destiné à tester, dans des conditions normales d'utilisation, certaines fonctionnalités de l'application. Une maquette est essentiellement mise en œuvre pour valider l'interface homme/machine avec des degrés de réalisme variables (maquette statique, maquette dynamique).

L'interactivité étant le caractère prédominant des applications actuelles, il n'est pas toujours aisé d'en traduire tous les aspects dans une spécification formelle. En conséquence, il est indispensable de recourir aux techniques de maquettage qui jouent aujourd'hui un rôle essentiel dans le processus de conception et réalisation des applications :

On distingue généralement deux grandes catégories de maquettes :

• les maquettes statiques proposant des dessins d'écrans ou d'éditions sans possibilité d'interactivité ;
• les maquettes dynamiques proposant une interaction élémentaire (la logique de dialogue) et un enchaînement des écrans ou éditions.

En complément, et chaque fois que cela pourra faciliter la compréhension du métier de l'utilisateur, la maquette pourra accueillir les différentes règles de traitement mises en œuvre.

L'approche par maquettage dynamique, qui a notre préférence, permet d'obtenir rapidement une validation de la solution proposée à l'utilisateur, par une présentation visuellement et dynamiquement la plus proche possible de l'application définitive.

L'utilisation des techniques de maquettage comme support d'aide aux spécifications externes du futur système pose le problème de la réutilisabilité de la maquette dans la réalisation proprement dite. Deux approches s'opposent :

• la construction d'une maquette jetable, élaborée de préférence avec des outils simples et rapides ;
• la construction progressive de la future application par l'utilisation restreinte des outils de développement (dessins d'écran, programmation ponctuelle, enchaînements).

Chaque solution présente des avantages et des inconvénients que l'on peut synthétiser dans le tableau suivant :

Dans notre contexte, la construction d'une maquette doit se concentrer sur l'interface homme/machine sans se préoccuper des problèmes d'architecture logicielle. De plus, la validation par les utilisateurs des règles de traitement (en particulier tous les algorithmes de calcul et de mises à jour) ne peut pas être réalisée dynamiquement par le biais du maquettage, mais nécessite une présentation descriptive qui peut difficilement être exprimée dans un langage de programmation.

Pour ces motifs, nous suggérons, dans la démarche rapide de Merise, l'approche par une maquette « jetable ». Toutefois, le concepteur devra, dans le choix de ses outils de maquettage, veiller aux possibilités de récupération vers l'environnement de réalisation des composants essentiels de la maquette, en particulier les dessins d'écran.

Dans une conception à base de maquettage, il est indispensable d'associer les données utilisées dans la maquette (dans les dialogues et les règles) à des données modélisées. Cette mise en correspondance des données contribue fortement à la mise en cohérence telle que préconisée dans le chapitre 11Chapitre 11 Confrontation données / traitements.

Le niveau de modèle peut être conceptuel ou logique. Comme la plupart des outils de maquettage dynamique, quel que soit le type de maquettage retenu, s'appuient sur une modélisation logique de données, nous proposons la démarche suivante :

• Enrichir progressivement le MCD élaboré dans la phase de conception générale.
• Transformer ce MCD en MLD relationnel en appliquant les règles présentées au chapitre 12Chapitre 12 Modélisation Logique des Traitements,
• Utiliser les données logiques dans la construction de la maquette.

Il est cependant souhaitable que le MCD reste la référence de la modélisation des données dans des spécifications fonctionnelles détaillées. Ainsi, au cours de la construction itérative de la maquette, les deux niveaux de modèles de données s'élaboreront progressivement.

L'aspect visuel des dialogues est l'atout principal du processus de conception par maquettage, surtout par son aspect communication - validation. La construction des dialogues constitue donc la tâche centrale de la phase de développement de la maquette.

On distingue trois aspects dans la construction d'un dialogue :

Le design de la présentation qui consiste à agencer les objets graphiques d'interface (champs de saisie, combo et list box , radio boutons, cases à cocher, boutons, cadres, onglets, etc.) sur la fenêtre de dialogue conformément aux finalités fonctionnelles de la tâche correspondante. Ce travail fait appel aux principes d'ergonomie visuelle et mentale qui constituent éventuellement des normes ou des standards.

L'expression de la logique du dialogue qui consiste d'une part à associer le contenu d'objets d'interface aux données modélisées (directement ou via une règle) ainsi que les valeurs prédéterminées ou contrôlées, d'autre part à spécifier les comportements d'interaction avec ou entre ces objets d'interface, comportements qui pourront éventuellement être simulés dans un maquettage dynamique.

La définition des enchaînements entre dialogues, souvent concrétisés par des boutons ou des menus, qui exprime la procédure de travail proposée à l'utilisateur. Le choix des enchaînements à offrir reste toutefois assez délicat à déterminer, car il doit rester compatible avec les procédures organisationnelles liées à la fonction à informatiser. En complément, le concepteur peut également utiliser comme support de sa réflexion, la modélisation logique des traitements proposée par Merise (cf. chap. 11Chapitre 11 Confrontation données / traitements).

La spécification détaillée des règles dans une approche par maquettage pose plusieurs problèmes :

• L'expression des règles de traitement (calcul et mise à jour des données) est indispensable dans un processus de conception.
• Quelle que soit la technique utilisée, on ne peut, en conception, valider des règles par démonstration ou par test ; il est nécessaire de les formaliser.
• Pour que cette formalisation soit compréhensible par l'utilisateur, il faut que le langage utilisé reste relativement naturel (ce qui exclut un langage de programmation).

En conséquence, nous préconisons, dans la démarche rapide de Merise, l'expression des règles dans un formalisme de type langage naturel structuré, intégrant les données modélisées. Éventuellement, ces règles peuvent être associées à des objets graphiques d'interface qui situent leur application, mais leur validation ne peut se faire que par la relecture de l'expression formalisée.

Comme dans les tâches précédentes, la construction progressive des règles vient enrichir les données modélisées et assurer leur cohérence avec les traitements.

La maquette est principalement orientée vers l'utilisateur afin de favoriser la validation. Les éléments ayant servi à sa construction qui constituent les spécifications fonctionnelles détaillées doivent être formalisés et complétés par d'autres éléments qui ne peuvent trouver place dans la maquette.

Parmi documents de spécifications fonctionnelles, on trouvera :

• Les modèles de données (MCD, MLD).
• Le descriptif des fonctions réalisées dans la maquette (présentation du dialogue, données concernées, règles de traitement utilisées).
• L'association des fonctions de la maquette aux phases du macro-MOT élaboré au niveau des spécifications générales.
• La liste des fonctions qui n'ont pas fait l'objet de maquettage (dialogues simples, traitements batch, certaines éditions).

Ces documents sont le « reflet » de la maquette. Ils ne sont pas a priori destinés à une présentation à l'utilisateur, mais constituent plutôt des documents internes au développement. Cependant, la validation de la maquette induira la « validation » de ces documents qui serviront ainsi de références pour la réalisation définitive de l'application.

L'objectif essentiel de cette phase est la présentation de la maquette à l'utilisateur en vue de la validation des propositions du concepteur. Afin de maîtriser la conception itérative par maquettage, il est nécessaire de bien distinguer deux tâches : la présentation de la maquette et la formalisation des amendements.

Pour que cette présentation se déroule efficacement, il faut veiller aux conditions de validation.

Le contexte et le rôle de validation doivent être expliqués à l'utilisateur. La validation par maquettage dynamique n'est pas un test du produit. Il sert à présenter d'une façon la plus réaliste possible la future application. Ce réalisme concerne exclusivement les interfaces homme/machine. Or, d'autres éléments entrent en jeu dans les spécifications détaillées de l'application : positionnement de l'application dans le processus organisationnel de l'activité, interrelations avec d'autres systèmes, conditions d'utilisation, potentiels et ouverture de l'application (surtout en termes de données), règles de gestion.

À l'exception des toutes petites applications, il est préférable d'effectuer la validation par « module ». L'utilisateur peut facilement se concentrer sur un sujet ; l'utilisateur hésite moins à demander des modifications ; les modifications ont une propagation limitée au niveau de la phase de validation.

La présentation - validation a normalement généré des remarques et suggestions de la part des utilisateurs qui ont été recueillies par le concepteur.

Les résultats cette présentation de la maquette sont rassemblés dans un compte rendu d'évaluation qui reprend les maquettes et autres documents présentés avec mention des commentaires et demandes de modifications exprimées.

Sur la base de cette évaluation, le concepteur procède aux amendements nécessaires sur la maquette et les spécifications détaillées associées, puis réitère le cycle développement - évaluation.

Dans l'étape de maquettage, nous avions préconisé de travailler sur un modèle logique brut ou très sommairement « optimisé ». À l'issue de la conception détaillée de l'application, le concepteur dispose d'une description complète et validée des données (sous une forme conceptuelle et logique), accompagnée de l'ensemble des traitements à mettre en œuvre. Il peut donc procéder, en toute connaissance, aux optimisations nécessaires.

Les techniques d'optimisation sont celles utilisées classiquement dans la méthode Merise pour les bases relationnelles (cf. chapitre 14Chapitre 14 Optimisation des Modèles de Données).

Les spécifications issues du maquettage, ainsi que les éléments éventuellement récupérés, peuvent nécessiter une adaptation aux contraintes du logiciel de développement. Dans des cas extrêmes, cela peut conduire à une réinterprétation complète de la maquette.

Cette étape de réalisation du logiciel se concrétise bien évidemment par la recette technique de l'application complète en état de fonctionnement. Outre ce résultat fondamental, certains documents doivent accompagner le produit, à savoir :

• une documentation technique du produit, nécessaire aux opérations de maintenance ;
• une documentation utilisateur, pour la partie intégrée dans le logiciel, l'autre partie pouvant être rédigée dans l'étape suivante.

Nous regroupons, sous cette appellation, les différentes structures dont l'existence est indépendante d'un projet de conception et de réalisation de système d'information. Nous analysons cependant ces structures par rapport aux fonctions qu'elles exercent vis-à-vis d'un projet de système d'information.

Professionnels de la gestion d'un domaine d'activité

Nous regroupons, sous cette appellation, toutes les personnes exerçant une fonction, un métier, quel que soit leur niveau de responsabilité, dans un domaine d'activité. Le domaine peut recouvrir soit une activité de gestion classique (vente, ressources humaines, comptabilité), soit une activité à caractère plus technique (recherche, production…).

Cette structure est fréquemment désignée par les utilisateurs. Elle est la destinataire de l'application informatique qui supportera son système d'information informatisé. En règle générale, cette structure permanente joue le rôle de maîtrise d'ouvrage dans un projet.

Rappelons que la compétence des personnes travaillant dans cette structure concerne avant tout leur domaine d'activité. Bien que ces utilisateurs/gestionnaires doivent s'impliquer dans la conception de leur système d'information, on ne peut exiger de ces personnes une maîtrise confirmée des démarches et des raisonnements utilisés lors de la conception et de la réalisation d'un système d'information informatisé.

Professionnels de la conception et de la réalisation de système d'information

Nous regroupons sous cette appellation les différents métiers dont la fonction concourt à la conception et la réalisation d'un système d'information informatisé. Cette structure est fréquemment, et parfois abusivement, désignée par « les informaticiens ». En règle générale, cette structure permanente joue le rôle de maîtrise d'œuvre.

Les personnes exerçant dans cette structure présentent des compétences très diverses : organisateurs, concepteurs, réalisateurs, spécialistes matériels… Elles ont généralement acquis une expérience au cours de la conception et la réalisation de plusieurs projets dans des domaines d'activités divers.

Ces structures, sous forme de groupe, sont constituées à l'occasion d'un projet (voir figure 17.1). Ces groupes sont établis autour des rôles suivants : production du projet, validation du projet et maîtrise du projet. Leur composition et leur rôle varient au cours du cycle de vie du projet.

Groupe de pilotage

Ce groupe a la responsabilité de la maîtrise de projet en termes de décisions, de coûts et de délais. Ses participants se prononcent sur les choix proposés par le groupe projet. De par son rôle, ce groupe de pilotage est composé de responsables hiérarchiques :

• de la maîtrise d'ouvrage ;
• de la maîtrise d'œuvre ;
• de la direction générale de l'entreprise.

Groupe de projet

Ce groupe a la responsabilité de la production du projet suivant les différentes phases de l'étude. La diversité des raisonnements à appliquer au cours de la démarche requiert des compétences variables. Ce groupe sera donc composé, dans des proportions variant avec le déroulement du projet :

• de professionnels de la gestion ;
• de professionnels de la conception ;
• de professionnels de la réalisation.

Quelles que soient les phases, il apparaît souhaitable qu'une mixité utilisateurs-informaticiens soit respectée. Ainsi, dans les étapes de conception du système d'information organisationnel (étude préalable, étude détaillée), il est indispensable que la majorité des participants au groupe de projet soient des professionnels de la gestion du domaine. Par contre, lors des étapes plus techniques (étude technique, réalisation), il est incontestable que le groupe de projet est constitué en quasi-totalité d'informaticiens.

D'une façon générale, on peut distinguer au sein du groupe de projet les fonctions et compétences suivantes :

• un responsable système d'information, représentant permanent des intérêts de la maîtrise d'ouvrage, leader des utilisateurs, maîtrisant totalement l'activité du domaine étudié ;
• des utilisateurs-concepteurs, participants actifs à la conception de leur système d'information, maîtrisant certains points particuliers du domaine ou présentant des aptitudes à la modélisation ;
• un chef de projet, professionnel de l'informatisation, leader des informaticiens, maîtrisant totalement les méthodes et techniques de la conception et de la réalisation des systèmes d'information ;
• des informaticiens-réalisateurs, participants actifs à la conception et à la réalisation du système d'information.

Étant donné le rôle actif de ce groupe de projet, les participants sont généralement mobilisés à plein temps, et selon leurs interventions sur les différentes phases du projet.

Ce groupe est la représentation consultative des futurs utilisateurs du système. Bien qu'il ne participe pas activement à la production de l'étude et de la réalisation du projet, son avis est indispensable pour valider les propositions émises par le groupe de projet. Ce groupe est constitué essentiellement d'utilisateurs. Lors de sa constitution, on veillera à respecter une représentativité reconnue par l'ensemble des usagers.

Nous proposons, sous la forme d'un tableau succinct (voir figure 17.2) une répartition des différents rôles des intervenants dans la mise en œuvre de la méthode Merise. Nous invitons le lecteur à personnaliser cette grille en fonction des particularités de son entreprise.

La démarche qualité est devenue un élément important du cadre méthodologique de conception de systèmes d'information et de réalisation d'applications informatiques. Il est donc naturel de retrouver cette préoccupation dans la mise en œuvre de la méthode Merise.

L'un des principes de base de la qualité est la conformité du produit fourni aux exigences du client. Cette conformité passe entre autres par la validation des spécifications du produit.

La figure 17.3 rappelle les étapes successives permettant d'obtenir une qualité globale.

En informatisation de système d'information, les développeurs se préoccupent prioritairement de la qualité de la production, car elle reste interne à la maîtrise d'œuvre. Les deux autres aspects de la qualité impliquent une relation entre la maîtrise d'œuvre (utilisateurs) et la maîtrise d'ouvrages (informaticiens).

Dans la méthode Merise, ces deux « maillons » de la relation Utilisateurs Informaticiens sont une préoccupation régulière tout au long du processus de conception. Elle se concrétise par l'implication de représentants de la maîtrise d'ouvrage dans le groupe de projet, ainsi que la présence d'un groupe de validation.

Bien que fortement souhaitable, la participation de représentants d'utilisateurs aux travaux du groupe de projet, du moins dans les étapes d'étude préalable et d'étude détaillée, reste tributaire de leur disponibilité et de leur aptitude à la conception. Il faut cependant tenir compte de leur représentativité limitée.

Quant au groupe de validation, son rôle est indispensable dans le processus de validation. Par expérience, nous avons constaté que les projets où un tel groupe (quel que soit par ailleurs son intitulé, mais distinct du groupe de pilotage) était absent, on rencontrait de plus grandes difficultés dans l'acceptation de l'application par les utilisateurs.

La qualité de l'expression des besoins dépend essentiellement de la représentativité des utilisateurs tant dans le groupe de projet que dans le groupe de validation. Leur validation passe par des échanges réguliers entre les participants à ces groupes et le reste des utilisateurs concernés par le projet.

La qualité des spécifications est le maillon essentiel de la relation utilisateurs informaticiens. La validation passe d'abord par une compréhension des spécifications et peut prendre plusieurs formes dont les conditions de mise en œuvre sont différentes (panels, interviews, groupe de travail…).

IV-H-4-c-i. Présentation des modélisations▲

IV-H-4-c-ii. Présentation des solutions▲

IV-H-4-c-iii. Maquettage▲

La modélisation des objets gérés par un dictionnaire est souvent représentée sous forme d'un modèle de type entité-relation, appelé aussi métamodèle ou modèle des modèles. Il décrit, dans ce formalisme, les objets utilisés dans une méthode, ainsi que leur articulation et certaines de leurs règles d'existence et de contrôle. On trouvera également, dans les formes évoluées de ces métamodèles, l'association du formalisme et de la symbolique graphique représentant les différents objets.

La pluralité des méthodes incite souvent les fournisseurs d'ateliers de conception à proposer un accès au métamodèle de leur dictionnaire, permettant de personnaliser ou d'adapter le contexte descriptif de la méthode proposée, ainsi que certains comportements induits, notamment pour les contrôles propres à chaque modèle et à l'articulation inter modèles.

Cette ouverture du métamodèle devient également une nécessité pour accueillir des notions appartenant à d'autres outils, afin de procéder à des communications entre outils hétérogènes, comme le passage d'un outil de conception à un outil de réalisation. L'interface ou la passerelle entre ces outils pourra également faire l'objet d'un méta modèle, traduisant l'articulation entre les notions partagées.

Si cette vision du dictionnaire et l'aptitude à en modifier le contenu peut paraître séduisante, il ne faut cependant pas sous-estimer la difficulté et les dangers d'une personnalisation méthodologique mal maîtrisée. De plus, le comportement des outils ne s'adapte pas forcément fonctionnellement à toute évolution.

La notion de dictionnaire se retrouve sous diverses appellations, recouvrant parfois des ambitions différentes. Ainsi les dénominations encyclopédie, base d'informations, gestionnaire banalisé d'informations, gestionnaire d'objets, référentiel, « repository » recouvrent à minima l'objectif de mémorisation des objets de conception et/ou de réalisation. Le caractère distinctif se révélera beaucoup plus dans l'organisation et les modalités d'accès à ces types de dictionnaires.

On peut ainsi distinguer trois grandes familles de dictionnaires qui induisent différentes architectures et différents usages des outils.

Développés ces dernières années par nombre de promoteurs de la méthode Merise, ces outils ont assez tôt tiré parti de l'environnement de la micro-informatique et de la richesse de son interface utilisateur, pour proposer des fonctionnalités de modélisation, de contrôle et de documentation autour d'un dictionnaire couvrant l'ensemble de la méthode.

La plupart proposent également des points d'appui pour la réalisation, notamment par le maquettage d'écran et d'état, la transformation des modèles conceptuels de données en modèles logiques relationnels. On retrouve dans les offres relatives à ces produits une architecture de postes de travail type micro autonome, ou des architectures réseau, pour partager les dictionnaires entre plusieurs utilisateurs.

Ces outils de conception disposent également fréquemment de procédures d'échanges sous forme d'import/export, pour établir des passerelles avec des outils de réalisation sur moyens ou grands systèmes. Les communications hétérogènes (ou interfaces) s'effectuent en général entre deux dictionnaires à travers une procédure de transformation permettant d'effectuer le passage d'objets de conception en objets de réalisation.

Solution souvent proposée par des fournisseurs d'atelier de réalisation souhaitant remonter vers la conception, il s'agit d'outils organisés autour d'une structure de dictionnaire unique comprenant les objets de conception et de réalisation.

Ces outils ont donc dû arbitrer entre le niveau de modélisation associé à une méthode de conception et le niveau de spécification du logiciel ; ce dernier conditionnant assez fortement par ses contraintes l'assemblage des deux niveaux, impose souvent une transition par des langages formels de spécifications.

La pratique peut mettre en évidence la difficulté pour ces outils d'avoir à la fois une large couverture du cycle de vie et une bonne performance sur chaque fonctionnalité. Ceci n'est pas surprenant, compte tenu :

• de la spécificité de chaque niveau abordé ;
• des utilisateurs de métiers complémentaires, mais ayant des organisations et rythmes de travail différents ;
• de l'impératif d'une cohérence permanente du dictionnaire.

À la fin des années 80, une nouvelle perspective des ateliers de génie logiciel a été proposée, à travers des plates-formes d'intégration assurant :

• la gestion, le contrôle, la mémorisation de l'ensemble des composantes du système d'information ;
• la normalisation de la perception du contenu des dictionnaires en rendant collectifs les métamodèles ;
• l'utilisation d'outils différents et complémentaires, spécialisés dans une méthode ou une partie du cycle de vie, communiquant grâce à la normalisation des objets manipulés et reconnus par la plate-forme d'intégration.

Le dictionnaire, noyau de ces plates-formes, est dénommé Référentiel ou Repository.

L'intégration d'un outil et ses capacités à s'insérer dans une quelconque des phases de conception ou de développement sont donc assurées par une plateforme commune, structure d'accueil d'outils différents, accédant aux données applicatives partagées. Ces données applicatives ont une structure et un format prédéfinis, par un modèle commun de données (ou métamodèle), et sont gérées par un dictionnaire centralisé : le Référentiel.

Par le passé, le monde de l'informatique et les luttes d'influence imposées par les conquêtes de marchés n'ont pas permis d'avoir des niveaux de normalisation suffisants pour assurer la portabilité des logiciels et la généralisation des méthodes.

L'approche par plates-formes d'intégration a fait immanquablement resurgir ces divergences (cf. l'échec d'AD CYCLE d'IBM). Cependant, si une normalisation du contenu des métamodèles paraît une nécessité pour une bonne communication entre outils hétérogènes, elle peut induire des effets réducteurs en matière d'innovation et d'évolution.

On regroupe sous cette appellation diverses fonctions qui aident le concepteur dans la mise en application des raisonnements, et plus particulièrement ceux de conception. On trouvera ainsi des outils assistant le concepteur dans :

• la manipulation des représentations graphiques des modèles ;
• la vérification des règles de construction des différents modèles ;
• la transformation d'un modèle en un autre (modèle conceptuel de données en modèle logique de données par exemple) ;
• le chiffrage et l'évaluation des volumes et activités ; 
• l'optimisation d'un modèle physique de données.

En règle générale, lorsqu'un raisonnement présente un caractère algorithmique ou semi-algorithmique, un outil logiciel d'aide à la conception pourra être utilisé.

La vie du projet est jalonnée de multiples rapports destinés aux différents intervenants. Malgré le développement des outils logiciels et des supports informatisés des spécifications, le rapport écrit restera encore pour longtemps la forme conventionnelle de présentation des conclusions d'étude. L'essor de la bureautique a désormais banalisé le traitement de texte comme outil de production de documents.

La rédaction d'un rapport d'étude ne peut suffire à la restitution formelle des spécifications ; il est indispensable d'y associer des éléments rédigés, permettant une compréhension plus large des idées exprimées. L'outil logiciel de production de rapports doit permettre :

• les fonctions classiques de mise en forme d'un traitement de texte ;
• l'incrustation de fiches, tableaux ou listes en provenance de la documentation formelle gérée par le dictionnaire du système d'information ;
• la manipulation de dessins (les schémas des modèles) ;
• l'indexation des éléments du rapport avec le dictionnaire afin de faciliter les mises à jour.

Ces types d'outils logiciels permettent d'illustrer et d'évaluer lors du processus de conception, le comportement du futur système d'information. Actuellement, les outils de simulation proposent une analyse du comportement dans le temps des modèles conceptuels ou organisationnels de traitements. Ces outils permettent de mettre en évidence les blocages éventuels, les points d'attente, et d'évaluer le découpage en tâches ou opérations dans le futur système d'information et d'en dimensionner les ressources.

Le maquettage permet d'illustrer le fonctionnement complet des données et traitements du futur système d'information. Il présente généralement les écrans associés aux tâches, les règles de traitements appliquées, l'utilisateur final peut ainsi faire part de ses réactions sur la maquette, ce qui permet de confirmer, ou si nécessaire d'adapter, les spécifications.

Les outils logiciels correspondant à ce créneau se sont très tôt développés et bien souvent indépendamment des méthodes de conception de système d'information. Le développement d'applications dispose aujourd'hui d'un ensemble d'outils regroupables sous le terme d'atelier de génie logiciel.

D'une façon générale, ces outils cherchent à accroître la productivité des réalisateurs, à apporter une meilleure portabilité du logiciel fourni et une facilité de maintenance. On retrouve généralement réunis dans cet atelier de production :

• des éditeurs de programmes sources multifenêtres ;
• des gestionnaires de bibliothèques de modules de programmes et de classes d'objet ;
• des langages de programmation évolués ;
• des générateurs de programmes ;
• des générateurs de jeux d'essai ;
• des aides à la documentation ;
• des descripteurs d'écrans …

Le passage d'une attitude artisanale à une démarche d'ingénierie pour la conception et la réalisation des systèmes d'information s'est accompagné de moyens pour la maîtrise des coûts et des délais. Là encore, des outils logiciels existent dans les domaines de l'ingénierie non informatique.

Il faut cependant adapter ces outils logiciels à la relative simplicité des projets à gérer (par comparaison à l'ingénierie pétrolière ou à des ouvrages d'art) ainsi qu'à la démarche spécifique.

On retrouve généralement dans ces outils de suivi de projet :

• l'ordonnancement et le suivi des délais des tâches et phases ;
• la planification et le suivi des consommations de ressources ;
• le suivi budgétaire de chacune des tâches ou phases ;
• le contrôle et le classement de la documentation produite et utilisée.

Win'Design, conçu et développé par la société CECIMA, est le successeur du produit MESSAGE, dont la première version a été commercialisée en 1986.

Win'Design est ainsi la synthèse de nombreuses années d'expérience de mise en œuvre d'outil de conception dans le cadre de projets très divers. Win'Design a su tirer parti à la fois des évolutions méthodologiques (extensions du formalisme de Merise, apport des méthodes orientées objet) et technologiques, aussi bien pour l'interface graphique (Windows®) que pour les environnements modernes de développement.

Outil indispensable de la mise en œuvre de la méthode Merise pour l'approche système d'information, Win'Design est également un outil performant pour la construction des bases de données et le passage à la réalisation pour certains environnements de développement.

Utilisé dans tous les secteurs d'activité (administration, industrie, services, SSII…), Win'Design est un atelier de conception complet, permettant d'aborder tous les modèles de données et de traitements. Ses nombreuses fonctionnalités constituent une véritable aide à la conception, aux contrôles, à la documentation dans le cadre de la mise en œuvre de la méthode Merise 2^e génération, du schéma directeur à l'étude détaillée. Enfin, notons que Win'Design a été utilisé pour les illustrations et les modèles présentés tout au long de cet ouvrage.

Win'Design dispose d'un environnement de travail dont l'ergonomie est particulièrement adaptée aux tâches de modélisation.

L'espace de travail

« L'espace de travail » regroupe des modèles et des fichiers (par exemple des documents texte, des tableaux…), autorise tous types d'organisation du travail (par modèle, projet, regroupement de projets, groupe de travail, sous-ensemble d'activité…).

Il permet ainsi d'adapter la visibilité des spécifications des systèmes d'information au contexte de travail des utilisateurs.

Le dictionnaire

Il fournit la liste des tous les objets existants dans les modèles de l'espace de travail, avec leurs localisations (représentations multiples d'un même objet). L'outil associé au dictionnaire permet également la recherche et l'affichage graphique de l'objet, la réutilisation d'objets existants (par glisser-déplacer sur le graphique).

Une liste complémentaire permet de visualiser toutes les références croisées de l'objet sélectionné (cf. figure 18.2).

Contrôles et requêtes

Win'Design outre les contrôles immédiats lors de la construction du modèle, dispose d'une fonction de contrôles à la demande.

Ces contrôles concernent essentiellement les contrôles de complétude des objets dans le cadre d'un modèle.

Les contrôles peuvent être paramétrés et catalogués. Ainsi, on pourra indiquer par type d'objet quel est le type de contrôles à opérer et indiquer le degré de gravité. L'exécution des contrôles permet de disposer d'une fenêtre contenant les résultats, différenciant par couleur les degrés de gravité (erreur, alerte, information) avec interaction entre la fenêtre de diagnostic et les fonctions de gestion des objets.

Ce dispositif de contrôle est complété par un système de requête multi modèles (exprimé en SQL simplifié) qui permet d'accéder sélectivement aux objets en fonction de ses caractéristiques ou liens (cf. figure 18.3).

Documenteur

Les schémas peuvent être imprimés directement et être mis en page par une fonction spécifique, tenant notamment compte des spécificités de l'imprimante, portrait, paysage, échelle, sélection, pages à éditer…

Une autre fonction permet d'effectuer des extractions du dictionnaire et de présenter le dossier d'étude. Ce dossier est paramétrable dans sa forme (entête, pied de page, page de garde, table des matières…) et dans son contenu (choix de l'édition, niveau de détail, sélection des objets… cf. figure 18.4).

Par ailleurs, la présentation des éditions peut faire l'objet d'une maquette réalisée à partir du traitement de texte Winword de Microsoft®, décrivant la forme et la structure de chaque édition. Ces maquettes peuvent être modifiées et personnalisées.

Modèle conceptuel de données

Win'Design prend en compte l'ensemble des notions du modèle entité relation étendu présenté dans cet ouvrage. Il permet ainsi de prendre en compte :

• La généralisation et spécialisation : Win'Design gère pour cela la relation d'héritage, l'héritage multiple, la contrainte sur sous-type, les critères de spécialisation… (cf. figure 18.5).

• Les contraintes : Win'Design permet notamment la prise en compte des contraintes de stabilité (les relations définitives, les pattes verrouillées, les propriétés non modifiables), les contraintes d'unicité (dépendance fonctionnelle), les contraintes interrelations (exclusion, inclusion, totalité, partition, simultanéité), les contraintes de valeur pour les propriétés (valeur minimale, maximale, par défaut, liste de valeurs, règles de détermination de valeur).

  

• Les règles : Win'Design permet l'expression de n'importe quel type de règle (calcul, contrôle, sélection…). Ces règles peuvent être dessinées dans le modèle et faire figurer les liens avec les propriétés utilisées dans la règle (cf. figure 18.6).

• L'historisation : Win'Design permet pour les entités ou les relations de préciser le rythme et la nature de la conservation des dernières modifications, soit pour l'entité ou la relation dans sa totalité, soit pour l'une de ses propriétés. Cette modélisation est précisée par une caractéristique d'unité de temps et de nombre de valeurs à conserver. (dans l'exemple l'entité « ARTICLE »).
• Les états associés aux entités ou aux relations : ces états permettent de traduire les différents stades de gestion perçus dans l'évolution du cycle de vie de l'entité ou de la relation. Ils sont organisés par typologie (cf. figure 18.7). Ces états peuvent être par ailleurs spécifiés dans les modèles de traitements, soit à titre de pré ou de post condition d'un traitement, soit à l'occasion de la description du cycle de vie de l'objet lui-même, en entrée ou en sortie d'un traitement dit de transition.

• Les propriétés composées : ces propriétés (par exemple : adresse composée de rue, code postal, ville) peuvent être décrites jusqu'à trois niveaux de profondeur (cf. figure 18.8).

• Les propriétés multivaluées : Ces propriétés permettent d'indiquer le nombre de répétitions de valeurs de la propriété, intéressant pour ne pas nommer avec un indice les mêmes propriétés répétées plusieurs fois (exemple : pour décrire 2 adresses, au lieu de définir les propriétés Adresse1, Adresse2, il suffira d'indiquer sur la propriété le nombre de valeurs : adresse (2) (cf. figure 18.8)).

Modèle Logique de données

Le modèle logique de données (MLD) est généré automatiquement à partir du modèle entité-relation (MCD/MOD). Cette génération prend en compte l'ensemble des caractéristiques de la modélisation du modèle conceptuel (cf. chapitre 13 « Modélisation logique des donnéesModèle logique de données relationnel »). Elles sont traduites au niveau relationnel, aussi bien au niveau de la description des tables et attributs que des clés primaires ou étrangères, des index, ainsi que les règles de contrôles d'intégrité référentielle (cf. figure 18.9).

Win'Design dispose également d'une fonction d'optimisation du placement graphique du modèle logique de données, fonction très utile notamment lors de la récupération par reverse d'une base de données existante.

Au-delà de la transformation automatique, le modèle logique de données peut être modifié, éventuellement dénormalisé et géré comme tous les modèles de Win'Design. Win'Design permet également, à partir d'un modèle logique, de générer un modèle de type entité-relation correspondant.

Modèle Physique de données

Win'Design permet la génération automatique du modèle physique de données à partir du modèle logique, avec :

• Paramétrage des pilotes (drivers) de génération des scripts : Win'Design dispose d'une fonction permettant de paramétrer intégralement les principales règles syntaxiques ou les contraintes spécifiques à chaque SGBD, pour la création d'un script. Win'Design dispose en standard de la plupart des drivers pour les SGBD relationnels actuels.
• Génération des scripts : en fonction des caractéristiques du modèle logique et du pilote de génération, Win'Design génère les scripts de création ou de modification des bases de données, ainsi que les descriptions de règles modélisées dans le MLR (cf. figure 18.10).

Win'Design génère également les triggers d'intégrité référentielle pour les SGBD qui en tiennent compte (cf. figure 18.11).

Win'Design permet de récupérer le descriptif du contenu des bases de données à partir soit d'ODBC, directement de la structure physique de la base de données, soit du script lui-même, pour tous les SGBD suivant la norme SQL2.

Le modèle logique de données est alors déduit par Win'Design du modèle physique de données. Dans le cas où les clés étrangères n'existent pas dans le SGBD, Win'Design tente de les reconstituer. Le schéma peut être automatiquement optimisé dans son placement.

Win'Design propose aussi un découpage en « sous-modèle » de l'ensemble du modèle, en fonction des tables les plus référencées par les autres ou des tables se référant à de nombreuses autres tables (correspondant en général aux notions majeures du modèle).

Win'Design prend en compte tous les modèles de traitements de la méthode Merise : diagramme des flux, MCT, MOT, MLT, diagramme d'état (cycle de vie) emprunté à l'approche « objet ».

• Ces modèles, intégrés dans un même environnement, sont interreliés et peuvent partager des concepts communs. Win'Design permet une unicité de définition et une réutilisation immédiate des objets communs aux différents niveaux d'abstraction (acteur, message, règle, poste ou unité organisationnelle, état). La figure 18.12 présente un MOT.

La conception par décomposition est conforme aux approches anglo-saxonnes (SADT, SSADM…). Win'Design permet ainsi :

• la décomposition d'un traitement dans un sous modèle présentant les traitements détaillés ;
• la décomposition dans le même niveau d'abstraction ou avec changement de niveau ;
• une aide à la décomposition d'un traitement à partir du détail de sa description et de son environnement (acteurs, messages, conditions…) ;
• la décomposition a posteriori (mise à jour de l'environnement, rattachement) ;
• le passage automatique (aval et amont) entre un traitement et sa décomposition ;
• la visualisation de la décomposition hiérarchique (gestionnaire de vues).

À chaque traitement (opération, tâche, unité logique…) peut être associé :

• Le sous-ensemble de données sur lequel il agit : ce sous-ensemble est décrit dans le module de données de Win'Design et est représenté sous forme d'icône dans les modèles de traitements. L'appel du modèle correspondant se fait par double clic sur l'icône représentant le sous-modèle de données, comme l'illustre la figure 18.13. Les actions (création, modification, lecture, suppression) peuvent alors être précisées pour chaque traitement sur chaque élément du sous-ensemble de données, appelé aussi « vue » ou « sous schéma ».

• Les règles associées : les règles peuvent être définies dans les modèles de données indépendamment de leur contexte, et être réutilisées dans les modèles de traitements où elles sont associées aux traitements (contexte d'utilisation). Elles peuvent être aussi définies directement à partir des modèles de traitements.
• Les maquettes d'états ou d'écrans : l'association des maquettes aux traitements permet de resituer le contexte d'appel et d'exécution d'un écran ou d'une édition, la sélection de l'icône représentant une maquette provoquera l'affichage de celle-ci.

Les maquettes d'écran et d'état peuvent être spécifiées aussi bien dans leur forme que dans leurs contenu et comportement (cf. figure 18.14). Plusieurs assistants permettent de s'appuyer sur les spécifications des autres modèles pour créer les maquettes (à partir des tables, vues logiques, vues externes, règles…).

Les objets dessinés (champ texte, liste déroulante, case à cocher, bouton, radio bouton, tableau, boite à onglet, objet externe de type « activeX »…), sont associés à leur source de données (par référence au modèle logique de données).

Les comportements peuvent être spécifiés soit à partir des règles de gestion (cf. modèle de données), pour des calculs, contrôles…, soit à partir d'un éditeur Visual Basic, permettant de programmer le comportement évènementiel de l'objet et sa dépendance avec les autres objets. Dans ce dernier cas, lors de la simulation de fonctionnement, ces comportements sont réellement exécutés.

Par ailleurs, il est possible simplement de simuler le fonctionnement de la future application. En mode exécution, chaque objet est activable avec son comportement standard et programmé, ceci permet d'évaluer et valider le fonctionnement d'un écran, des enchaînements d'écrans…

Enfin, la documentation des spécifications de ces maquettes constitue un véritable cahier des charges détaillé.

Le MOT permet de documenter clairement l'organisation de l'entreprise en vue de réagir à un événement déclencheur. Dans une optique BPR, il permet d'atteindre deux buts :

• Impliquer directement les intervenants internes dans la réflexion sur l'organisation, qui est rarement documentée et généralement peu connue des personnes concernées. Chacun connaît à fond les tâches qui lui sont confiées personnellement, sans nécessairement comprendre l'utilité de ces tâches dans l'ensemble du processus. Or, l'utilité d'un travail intéresse fortement celui qui le réalise et il est généralement motivé pour prendre connaissance du modèle complet qui s'étend devant lui et qu'il a contribué à construire.
• Montrer clairement les faiblesses de l'organisation actuelle. Le MOT laisse souvent une impression forte auprès des personnes concernées, parce qu'il dévoile impitoyablement la complexité et la lourdeur de l'organisation actuelle. Les acteurs concernés, et plus encore, les responsables, s'étonnent : « Est-ce vraiment comme ça que nous travaillons ? ». Cette révélation est indispensable pour déclencher le processus de changement et pour solliciter l'adhésion des personnes concernées à ce processus.

L'étude du MOT permet de détecter rapidement certains dysfonctionnements de l'entreprise :

• tâches qui sont réalisées plusieurs fois par des postes de travail distincts ;
• tâches « vides » où l'affaire est simplement transmise à l'intervenant suivant, après avoir attendu patiemment dans la file d'attente des entrées d'un responsable donné ;
• tâches qui ont pour seul but de rendre les données compatibles aux solutions informatiques, alors que les solutions informatiques devraient s'agencer autour des flux naturels des travaux à réaliser par les intervenants.

Des MOT quantifiés en durée déterminent les temps d'attente, les temps de transmission et les temps productifs et permettent de calculer certains paramètres importants :

• la durée totale de traitement, comme étant la somme de toutes les durées d'une occurrence de procédure ;
• la durée de travail productif, comme étant la somme de toutes les durées productives.

On peut ainsi calculer des ratios critiques des procédures : taux de traitement productif = durée du travail productif / durée totale de traitement.

Un taux inférieur à 80 % indique qu'il y a des améliorations à réaliser, un taux inférieur à 50 % (et c'est souvent le cas) montre qu'il y a des problèmes d'organisation à traiter d'urgence.

Aujourd'hui, le client ne veut plus attendre, s'il sait que la concurrence réalise un travail de même qualité dans des délais plus satisfaisants. La réduction des délais devient un avantage concurrentiel. L'entreprise dynamique aura tendance à se restructurer jusqu'à réaliser des délais minimaux, en d'autres termes, elle essaiera d'améliorer son taux de traitement productif.

Certaines entreprises essaient d'améliorer le taux de traitement productif en automatisant les procédures actuelles par des systèmes de gestion de flux de travaux informatisés (« workflow systems »). Cette façon naïve de résoudre le problème peut se révéler dangereuse. C'est une solution qui essaie d'agir sur les symptômes, plutôt que de curer la maladie elle-même, et une automatisation des flux de travaux actuels, sans remise en cause des processus, n'est pas à considérer comme du BPR. Au contraire, l'automatisation de processus mal conçus peut constituer un désavantage concurrentiel, car elle améliore essentiellement les durées de transmission, sans influencer les durées d'attente et les durées productives. Par contre, ces systèmes augmentent le pouvoir des organes de contrôle et de supervision, en fournissant des statistiques détaillées sur le comportement des intervenants, qui se sentiront surveillés et qui auront tendance à s'opposer et à bloquer le système, ou bien à le contourner en réduisant la qualité de la production au profit de la quantité.

En BPR par contre, on essaie de réduire les contrôles et d'accroître la qualité de la production en créant un climat de confiance mutuelle, de motivation pour l'amélioration continue des procédures et de responsabilisation des intervenants. Pour atteindre ce but, il faut comprendre les processus de façon plus approfondie et à cette fin le MOT s'avère insuffisant.

La quantification des durées productives peut rendre apparents d'autres problèmes : souvent il est difficile de quantifier la durée productive, car elle varie fortement en fonction de la complexité du cas à traiter. On a intérêt à réaliser un histogramme faisant apparaître la répartition des durées productives. L'histogramme ci-dessous montre que 80 % des cas de cet exemple sont des cas simples, 15 % des cas complexes et 5 % seulement des cas très complexes. Ceci met en évidence qu'on soumet au même intervenant des cas simples et des cas complexes, ce qui est un symptôme typique d'organisation par spécialisation fonctionnelle. Elle a le désavantage d'engendrer des chaînes de traitement longues et de multiplier des transmissions entre postes de travail d'experts fonctionnels.

En BPR, on propose de réagir aux cas simples et aux cas complexes par des procédures séparées, ce qui permet de réduire nettement le nombre de postes de travail qui interviennent dans le traitement d'un cas simple, l'idéal étant de confier l'ensemble du cas à un seul intervenant polyvalent. Par contre, pour les cas complexes, il faudra faire intervenir des techniques de coopération assistée si possible par ordinateur.

Le MOT permet d'un seul coup d'œil de caractériser la structure organisationnelle et ses faiblesses. Souvent la procédure a une structure en cascade. Les intervenants travaillent en chaînes de traitements, réalisent chacun une tâche déterminée et ne se sentent pas responsables de la tâche du prédécesseur ou du successeur. Le désavantage de ce type d'organisation, c'est que personne ne se sent concerné par l'ensemble de la procédure, que des contrôles de qualité sont nécessaires, que des délais de transmission et d'attente apparaissent en fonction de la disponibilité des intervenants et que personne ne connaît l'état d'avancement de l'affaire. De plus, le système est incapable de réagir rapidement à des imprévus et risque d'être écarté à terme des marchés intéressants.

Les systèmes de gestion de flux de travaux permettent de remédier à cet inconvénient en localisant en temps réel l'état de chaque affaire. Par contre, ils ne permettent guère d'accélérer ou de modifier le cours des traitements.

Une organisation améliorée consiste à prévoir un responsable de procédure qui s'occupe complètement des relations avec le client et surveille l'avancement de l'affaire dans la procédure.

Tout se passe comme si le responsable de procédure devenait à son tour client des spécialistes fonctionnels et qu'une relation client/fournisseur s'établissait entre eux. L'entreprise se structure en « front office » et en « back office ».

Faire du BPR en se basant uniquement sur des MOT ne peut amener que des améliorations ponctuelles de type organisationnel. Pour aller plus loin, il faut être prêt à se détacher complètement de l'organisation actuelle et se poser des questions plus fondamentales sur les processus managériaux. Le MCT Merise est tout à fait approprié pour documenter les réflexions sur ce qu'on fait réellement lors d'une prestation pour le client, indépendamment de la façon dont les choses sont organisées actuellement.

L'entreprise est considérée comme un interlocuteur unique qui essaie d'offrir un service optimal au client. Réaliser un MCT est plus difficile qu'on ne le croit généralement, car l'organisation actuelle a tendance à imposer sa présence au modélisateur, qui souvent ne s'en rend même pas compte. Pour faire un bon MCT, on doit considérer l'entreprise comme système et se libérer de toute l'organisation du stockage de l'information. La tentative même de s'engager dans cette voie présuppose un état d'esprit qui conduit directement à des questions plus fondamentales encore. À la recherche du « quoi ? » se substitue rapidement la quête du « pourquoi ? » et poser la question revient souvent à remettre en cause l'état actuel.

Merise à l'origine se contentait d'explorer le « quoi ? » et faisait de la reconfiguration de processus en tenant compte uniquement de contraintes ou d'opportunités nouvelles.

Le passage du modèle conceptuel du système existant vers le modèle conceptuel du système futur se fait au zénith de la « courbe du soleil » souvent citée dans la démarche Merise. Pourtant, peu d'ouvrages Merise expliquent ce qui se passe à ce niveau et, généralement, on suppose que les choix de gestion à réaliser soient déjà connus (souvent on les considère comme étant les déclencheurs de l'étude Merise).

Ce point de vue peut se justifier dans un contexte d'entreprise statique, qui évolue par mutations périodiques et où les changements de règles sont rares. Dans une entreprise en changement permanent, les règles doivent être adaptées dynamiquement en fonction de l'évolution de l'environnement. Lorsque l'entreprise coévolue avec son environnement, le processus de changement doit se réaliser de façon plus systématique et trouver sa place normale dans le cycle de vie. Le BPR est le mécanisme qui assume le changement et doit trouver sa place normale au sommet de la courbe du soleil.

Le BPR devient ainsi le moteur de l'évolution de l'entreprise. Il se base sur les modèles conceptuels existants et les adapte dynamiquement pour fournir régulièrement des directions de changement. La mise en œuvre rapide de ces directives est essentielle pour le succès du BPR, car le temps qui s'écoule entre l'émission de la directive et son activation au niveau physique constitue le délai de réaction de l'entreprise face aux changements structurels de l'environnement. Ce délai dépend largement d'outils qui accélèrent le passage du niveau conceptuel vers le niveau physique. Les directives produites par le BPR ne déterminent pas seulement les choix de gestion, mais peuvent aussi se répercuter sur des choix organisationnels, voire sur des choix technologiques.

Le but de cette phase est de comprendre le système actuel et de mettre en évidence ses dysfonctionnements. Les modèles organisationnels et conceptuels Merise sont des outils d'analyse fort appropriés qui permettent de répondre à la question : « Que faisons-nous et pourquoi le faisons-nous ? » Les réponses à ces questions permettent de comprendre le fonctionnement du système actuel. Il s'agit ensuite de procéder à une sorte d'autoévaluation : « Quels sont nos points forts et nos points faibles ? Quels sont les procédés que nous maîtrisons le mieux ? » La réponse à ces questions ne peut pas se faire par modélisation des processus de l'entreprise, mais nécessite une confrontation aux activités de la concurrence. Il s'agit en réalité de se positionner par rapport à cette concurrence et d'évaluer les chances de survie sur les marchés en changement rapide. Les techniques de positionnement sont hors du domaine d'applicabilité de Merise et font appel à des études de marché et à des raisonnements stratégiques. Le résultat de la phase de positionnement consiste en une vue réaliste de la situation de l'entreprise dans l'environnement socio-économique.

Lorsque la position de l'entreprise est devenue plus claire, il s'agit alors de produire une vision du futur. « Où voulons-nous être positionnés à l'avenir en tenant compte de nos compétences de base ? » Les réflexions qui sont menées dans cette phase mènent à une redéfinition des objectifs de l'entreprise. Souvent elles sont accompagnées d'un recentrage sur les compétences essentielles et de l'abandon d'activités accessoires dans lesquelles on s'était engagé sur la base d'une tendance générale à la diversification économique. On en arrive à la conclusion qu'on ne peut pas tout faire et qu'on a uniquement des chances de survie dans les domaines où l'on brille par son excellence et par l'avance sur la concurrence. Progressivement une vision nouvelle de l'entreprise se dégage et il s'agit dès lors de transformer la vision en réalité.

La phase de repositionnement est une activité hautement stratégique et Merise n'y intervient guère jusqu'à présent. Pourtant rien n'empêcherait de le faire. En effet l'approche systémique de Merise se prête de façon naturelle à l'étude des finalités d'un système, lui-même décomposé en sous-systèmes, auxquels correspondent des sous-finalités. La modélisation Merise devrait donc décrire la hiérarchie des finalités, partant de la vision d'entreprise, en passant par des missions, jusqu'à aboutir à des objectifs opérationnels quantifiables. Chaque finalité devrait se décrire comme un couple de valeurs : l'objectif à atteindre et le résultat effectivement atteint par le système. Des initiatives pour compléter la modélisation des traitements et des données par une modélisation des finalités ont déjà été proposées [Marshall 2000].

Dans la phase de repositionnement (« reframing »), on est parfois amené à redéfinir les frontières du système. L'abandon de certaines activités non essentielles, des accords d'association avec d'autres entreprises, des solutions de délocalisation et de sous-traitance font que l'ancien système ne peut plus rendre compte de l'entreprise nouvelle. Les frontières entre entreprises tendent à s'estomper et on se dirige vers l'entreprise étendue ou l'entreprise en réseau. Il en résulte que l'ancien schéma directeur basé sur des frontières rigides n'est plus applicable.

Là encore, Merise montre sa force. L'approche systémique se prête aussi bien à décrire une entreprise monolithique qu'un ensemble dynamique de sous-systèmes couplés et associés dans une évolution commune. Pour cela, il faudra élargir la vue et décrire globalement le système étendu ainsi défini. Les processus sont maintenant décrits au niveau du réseau et non plus au niveau de l'entreprise isolée. Le BPR exige donc un nouveau schéma directeur sur base de frontières de système nettement étendues et en faisant intervenir des décideurs et des concepteurs répartis géographiquement. La réalisation d'un tel schéma directeur multisites, multisociétés exige la mise en œuvre de techniques coopératives nettement plus performantes que celles utilisées aujourd'hui. Les AGL futurs devront intégrer des fonctions coopératives et permettre aussi de modéliser cette coopération.

Elle consiste à mettre en place une organisation pour l'entreprise repositionnée. Les lignes directrices qui déterminent la nouvelle organisation sont le service rendu au client et la production de valeurs. Le client n'est plus considéré comme un facteur externe qui de temps en temps lance une commande, mais plutôt comme un partenaire de l'entreprise en réseau. Il s'agit de le comprendre et de tenir compte de ses besoins particuliers. Dans cette optique, chaque commande est différente de l'autre et doit faire l'objet d'une négociation entre client et fournisseur. Il ne suffit plus de modéliser une procédure en représentant l'enchaînement des tâches à l'intérieur de l'entreprise, mais il faudra modéliser correctement l'interaction avec le client.

En réalité, cette interaction est complexe et la boucle demande-fourniture peut faire l'objet de nombreuses itérations et de longues tractations. De fait, il s'agit d'un processus de négociation où il faudra se mettre d'accord sur les termes de l'échange et sur les conditions à satisfaire avant que la demande du client ne soit acceptée. Similairement, il s'agira de négocier la réception de la prestation et de prouver, après fourniture, que les termes de la transaction ont bien été respectés.

Les modèles de procédure et de processus actuels ne sont guère appropriés pour représenter des situations de transactions négociées. Medina-Mora, Flores et Winograd proposent un modèle d'interaction client/fournisseur en quatre phases : la préparation, la négociation, la prestation et l'acceptation, comme l'illustre la Figure 19.6 [Medina-Mora 92] :

Dans la phase de préparation, le client définit sa demande ; durant la phase de négociation, il se met d'accord avec le fournisseur sur les termes de la transaction. Cette phase peut être complexe et passer par plusieurs états intermédiaires avec propositions et contre-propositions, jusqu'à ce que la phase de négociation aboutisse ou cesse. La phase de prestation correspond à toutes les tâches nécessaires à la satisfaction du marché conclu ; elle correspond à ce qui est normalement représenté dans une procédure. La phase d'acceptation a pour but de clôturer la transaction : ceci ne sera le cas que lorsque le client a obtenu satisfaction et que les termes négociés ont été respectés.

Le modèle est intéressant à plus d'un égard :

• Tout d'abord, en mettant l'interaction avec le client au centre des considérations, il oblige le modélisateur à définir des procédures orientées client et à définir clairement les responsabilités de chacun, ainsi que l'objectif et les conditions de l'interaction.

• Ensuite, le fournisseur, comme le client, pourra recourir aux services de tiers pour accomplir l'une ou l'autre phase de la transaction. En particulier, le fournisseur lui-même aura souvent besoin de sous-traiter certains éléments de la négociation ou de la prestation à d'autres entités organisationnelles de l'entreprise fournisseur ou du réseau d'entreprises. Cette sous-traitance fera l'objet d'une boucle d'interaction entre le fournisseur et son sous-traitant.

  

• De cette façon, toutes les interactions entre éléments de l'entreprise réseau sont décrites par des modèles de transaction entre acteurs jouant le rôle de clients et d'autres jouant le rôle de fournisseurs, chaque fournisseur produisant une certaine valeur ajoutée acquise par le client en fonction des termes d'un contrat (réel ou virtuel). Une telle boucle d'interaction constitue un processus élémentaire et tout processus d'entreprise pourra se décrire comme réseau de boucles d'interaction [Marshall 2000]. Cette façon de modéliser les interactions permet de décrire des situations très variées, où il suffit de remplacer une transaction par une autre pour que le comportement du système change fondamentalement.

• Certaines transactions, surtout celles avec les clients nouveaux, feront l'objet de négociations serrées, d'autres se dérouleront en fonction de contrats-cadres négociés entre deux partenaires et chaque occurrence de transaction se déroulera suivant un schéma prédéterminé, faisant largement appel à des tâches automatisées. Il est intéressant de noter qu'une transaction peut à la limite représenter une interaction entre un être humain et un ordinateur, ou bien une interaction entre deux ordinateurs, permettant ainsi de faire appel à la même métaphore de représentation pour les transactions commerciales que pour les transactions informatiques du type client-serveur.

• Le modèle des diagrammes d'interaction permet de tenir compte de l'évolution des relations au cours du temps. Une boucle client/fournisseur se transformera progressivement en boucle fournisseur/sous-traitant, dans la mesure où les relations commerciales se stabilisent et qu'un climat de confiance mutuelle, basé sur la qualité des interactions passées, s'établit entre partenaires.

• Enfin, au fur et à mesure que le comportement entre un client et un fournisseur déterminés se standardise, il en sera de même des messages échangés entre eux et on pourra alors effectivement appliquer la métaphore « objets de métier » : tout se passe comme si l'échange entre client et fournisseur était devenu un échange entre l'objet-client et l'objet-fournisseur communiquant par des messages standards définis d'un commun accord. Mais il faut bien comprendre que c'est l'aboutissement d'un long processus d'évolution et non pas la situation habituelle. Le modèle objet ne devient applicable que lorsque les interactions humaines sont devenues superflues ou se déroulent suivant un code de comportement strictement réglementé ; c'est probablement le cas dans les couches basses du modèle de communication.

Dans un monde en changement, rien n'est définitif et toute relation pourra se transformer rapidement, voire cesser complètement. Voilà pourquoi le modèle d'interaction sera en mouvement permanent. La technologie évoluera, les produits changeront, la concurrence s'améliorera et il faudra donc que l'entreprise-réseau soit capable de se remettre en cause régulièrement et ait mis en place un mécanisme d'évolution.

L'évolution d'un système d'information se fait par mutations espacées dans le temps au point qu'on a pu utiliser le terme de « cycle de vie » pour désigner ce mécanisme d'adaptation. À la fin d'un tel cycle, le système d'information est remodelé afin de tenir compte de changements importants de l'environnement.

Mais dans la mesure où l'environnement change plus rapidement, la durée de vie des produits logiciels devient de plus en plus courte et la vitesse de production doit s'accroître pour rester en accord avec les besoins des utilisateurs. La notion de cycle de vie tend à perdre sa signification et l'évolution du système d'information devient une activité continue.

Ceci ne signifie pas pour autant qu'une telle évolution soit chaotique. Au contraire, l'entreprise en changement ne survivra que lorsqu'elle maîtrisera son évolution et deviendra capable d'assimiler rapidement les opportunités technologiques dans sa structure organisationnelle. Nous présentons brièvement la démarche de l'alignement stratégique développée à la Sloan School of Management du MIT [MacDonald 95].

Le BPR a permis à l'entreprise de se repositionner et de reconfigurer ses processus. Le nouvel état ne sera pas en équilibre statique, mais devra plutôt être considéré comme un état d'équilibre dynamique, un peu comme le randonneur qui, dès qu'il a posé un pied sur terre, y prend appui pour lever l'autre pied en vue d'atteindre un nouvel état d'équilibre. Le BPR doit devenir un état d'esprit, une acceptation du mouvement. Il faudra donc se repositionner régulièrement et par la suite reconfigurer l'organisation et adapter le système d'information.

La démarche de l'alignement stratégique se fait suivant quatre axes différents :

Ces quatre axes s'influencent mutuellement et il faut les examiner un à un :

• L'axe stratégique procède à un repositionnement permanent en tenant compte des opportunités technologiques et des contraintes organisationnelles.
• L'axe organisationnel procède à une reconfiguration régulière des processus en tenant compte des objectifs stratégiques et des restrictions du système d'information.
• L'axe du système d'information développe une structure de communication, de coopération et de partage de l'information répondant aux besoins des structures organisationnelles et en accord avec les possibilités de la technologie.
• L'axe technologique surveille en permanence l'évolution des solutions technologiques en explorant plus particulièrement les solutions adaptées aux besoins du système d'information de l'entreprise, tout en identifiant des voies nouvelles qui pourraient avoir un impact stratégique pour l'entreprise.

En pratique l'équipe de reengineering s'organise en quatre groupes de travail qui se réunissent cycliquement.

L'équipe « Stratégie » est composée d'experts de la stratégie de l'entreprise, mais comprend aussi au moins un expert de l'axe technologique et un expert de l'axe organisationnel. D'une façon générale, chaque groupe de travail comprend essentiellement des responsables de l'axe correspondant, mais comprend aussi au moins un représentant de l'axe précédent et un représentant de l'axe suivant. De cette façon, on garantit une continuité dans les raisonnements et une meilleure communication entre les groupes de travail. Chaque groupe essaie de progresser le long de son axe en tenant compte des besoins formulés par le groupe de travail précédent et en exprimant des besoins au groupe de travail suivant.

La démarche n'a pas de début ni de fin, mais constitue un processus cyclique d'adaptation progressive de l'entreprise aux changements de l'environnement. Le cycle de l'alignement stratégique regroupe à la fois le cycle de décision et le cycle de vie de Merise. La périodicité du cycle peut être adaptée aux besoins de l'entreprise et aux changements qui s'opèrent dans l'environnement, mais d'une façon générale, le cycle se déroule assez rapidement : plusieurs passages peuvent raisonnablement avoir lieu chaque année. Il ne faut pas qu'il y ait rupture du processus. Ceci implique que les changements du système d'information doivent s'opérer au même rythme que la fréquence du cycle d'alignement stratégique et il faut recourir à des outils puissants et souples pour réussir ce tour de force.

L'accès des entreprises à Internet constitue un changement technologique qui remet en cause leur façon même de fonctionner. En permettant des échanges de données structurées et non structurées, ainsi que de composants logiciels portables, Internet constitue la colle qui permet de combiner des systèmes d'information indépendants. Ceci mène irrémédiablement à des relations différentes avec les consommateurs, se répercutant techniquement par le commerce électronique BtoC (business to consumer), que par la mise en place de structures coopératives interentreprises, se répercutant techniquement par le commerce électronique BtoB (business to business). Les marchés se globalisent et des agrégats de plus en plus grands d'entreprises font leur apparition. Les percées dans le domaine de la sécurité juridique, notamment par une reconnaissance quasi universelle de la signature électronique, vont mener à un développement encore plus rapide de ces restructurations.

Le commerce électronique constitue une nouvelle vague de changements qui déferle sur les entreprises et va engendrer les besoins d'un BPR de deuxième génération. Désormais, ce n'est plus une seule entreprise qu'il faudra repositionner et restructurer, mais des groupes sectoriels entiers et des agrégats d'entreprises partenaires opérant en symbiose.

Pour l'instant, il n'existe guère de méthodes de modélisation adaptées à cette évolution, mais la méthode Merise repose sur des bases générales ayant le potentiel d'engendrer des outils valables. En considérant chaque entreprise comme un système poursuivant des finalités, on pourra décrire tout agrégat d'entreprises comme un nouveau système, poursuivant lui aussi des finalités. L'évolution de l'environnement socio-économique, ainsi qu'un processus continu de négociation entre les partenaires, conditionnent les finalités de chaque système individuel.

Il sera donc essentiel d'enrichir Merise par des modélisations de finalités et par des modèles d'évolution issus de l'approche systémique, en mettant davantage en évidence ce qui représente l'originalité de cette méthode par rapport à des approches purement orientées composants logiciels. Pour jouer un rôle dans la modélisation de systèmes d'information implémentant le commerce électronique, Merise devra évoluer vers un outil BPR de deuxième génération.

L'évolution d'Internet a progressivement affiné les langages d'échanges de messages structurés en engendrant des standards à tous les niveaux. Si la première génération de langages de marquage de documents se contentait de moyens d'expression assez limités et rudimentaires, ce n'est plus le cas avec la deuxième génération de ces langages. XML (Extensible Mark-up Language) constitue l'outil capable de définir une variété illimitée de langages spécialisés pouvant être combinés les uns aux autres.

Désormais, tous les formats d'échange pourront être exprimés sous forme de documents XML. L'intérêt, c'est que le document transporte la description de sa propre structure, ou du moins fait référence à une structure commune connue par les partenaires de l'échange. Ainsi, par exemple, le résultat d'une requête à une base de données pourra être exprimé selon un format XML et migrer entre systèmes d'information sous forme d'un document XML, indépendant de la technologie, mais pouvant être interprété par le système destinataire.

Ceci permet une compartimentation plus claire des fonctionnalités logicielles et le développement de composants standards, qui pourront être combinés de multiples façons en fonction des besoins. On pourra par exemple imaginer une application de calcul de salaires qui combinera un composant de retenue d'impôt à la source, fourni par le fisc, un composant de calcul des cotisations sociales, fourni par la sécurité sociale, un composant tarifaire, fourni par une organisation syndicale sur base d'une convention collective sectorielle. Lorsque les règles changeront, les modules pourront être remplacés, sans toucher à l'interface. L'application sera autoadaptative, sans que l'entreprise ait besoin de développer des composants externes à ses finalités propres.

XML permet de définir des langages spécialisés dans un domaine déterminé et de combiner les vocabulaires de plusieurs langages spécialisés dans un même document d'échange. Ainsi, il y a des langages de description de livres, de formules mathématiques, de pièces de rechange, de signatures électroniques et tous les jours on voit apparaître de nouveaux langages sectoriels. Les anciennes normes EDIFACT sont transformées progressivement en structures XML.

Ceci aura des conséquences importantes pour la modélisation des données. À l'avenir, le modélisateur ne pourra plus inventer librement ses propres structures de données, mais devra de plus en plus tenir compte de structures prédéfinies, issues d'efforts de standardisation sectoriels. Un modèle des données sera construit à partir de composants, implémentant des vocabulaires spécialisés (XML name space).

Cette évolution est fort intéressante et tout à fait dans l'esprit de Merise : en effet, on s'éloigne davantage de structures de données plus ou moins limitées par des considérations techniques, pour passer à un niveau d'abstraction plus général, celui du langage. Or, le langage est une caractéristique fondamentale des systèmes intelligents, tels que les êtres humains ou les organisations. Merise devrait mettre dsavantage le poids sur la modélisation du langage plutôt que sur la représentation de données, un MCD n'étant rien d'autre qu'un énoncé faisant intervenir des concepts de langages de communication importants pour le système étudié. Ceci irait un peu dans la voie tracée il y a longtemps par l'informaticien-anthropologue C. Vogel dans ses travaux sur le génie cognitif [Vogel 88] et il faudra se poser la question si la méthode Merise à l'avenir ne devrait pas s'inspirer de l'ethno-science, tout comme à ses débuts elle s'est inspirée de la science des systèmes.

Du point de vue Merise, l'échange informatisé de données peut être modélisé au niveau organisationnel, à condition d'intégrer les procédures des deux partenaires, ce qui est recommandé par le BPR [Bergman 91]. Ceci pose néanmoins le problème de la coopération sur d'autres plans : négociation de conventions d'échange, élaboration en commun des nouvelles procédures, coévolution des stratégies commerciales. Il s'agit cette fois d'échanger des messages peu structurés et d'entretenir une relation continue, et non pas d'exécuter une transaction commerciale plus ou moins standardisée. On voit apparaître la nécessité de technologies améliorant ce genre de coopération.

Les technologies disponibles sont basées sur l'échange libre de messages non structurés (courrier électronique, vidéoconférences, multimédia, téléprésence) et sur le partage de l'espace de travail (corédaction de documents, partage de bases de documents, visualisation commune de fenêtres et intervention commune dans ces fenêtres).

Les outils comprennent des canaux de communication à large bande passante adaptés au multimédia (RNIS, ATM) et des environnements de partage de documents (p.ex. Lotus Notes). Au niveau logique, ces techniques font intervenir des échanges entre serveurs (réplication de bases de données).

Au niveau organisationnel, il s'agit de modéliser des tâches coopératives faisant intervenir simultanément plusieurs postes de travail. Le MOT devrait permettre d'exprimer que certaines tâches exécutées par des acteurs différents ne constituent qu'une seule tâche coopérative, où chacun des acteurs joue le cas échéant un rôle particulier.

Pour cela, il faudrait introduire la notion de relation de coopération entre tâches, notion qui n'est pas prévue actuellement dans le métamodèle de Merise. De cette façon, deux tâches peuvent être reliées, soit par des liens dirigés de séquencement de tâches (messages entre tâches consécutives), soit par des liens non dirigés de coopération (tâches synchrones avec partage de données).

Il existe une forme plus structurée de coopération qui se situe entre l'échange de données informatisé et l'informatique coopérative. Il s'agit d'une implémentation des procédures internes basée sur un échange automatique de messages électroniques.

La généralisation des réseaux informatiques à l'intérieur de l'entreprise a rapidement engendré l'apparition de serveurs spécialisés dans le routage des flux de travaux à travers une procédure. Nous avons vu que l'automatisation pure et simple des procédures existantes pouvait se révéler en opposition avec les finalités du BPR, lorsque cette automatisation ne s'accompagne pas d'une remise en cause et d'une restructuration fondamentale de la procédure, avec une redéfinition du rôle joué par les différents intervenants de la procédure. Par contre, lorsque l'automatisation des flux de travaux s'insère dans le cadre d'un BPR bien mené, elle peut apporter des gains de productivité remarquables.

L'intérêt des outils de gestion de flux de travaux, c'est qu'ils obligent à modéliser les procédures, et la plupart de ces outils permettent à présent de faire des modélisations graphiques d'une façon très aisée ; ils permettent en outre de quantifier les procédures et de les simuler. Ceci favorise la prise de conscience des défauts de la procédure actuelle par les personnes concernées et amène progressivement une amélioration de la procédure. Par ailleurs il n'est plus nécessaire de programmer le routage, le modèle pouvant être transformé automatiquement en script de routage. L'idéal serait que l'AGL utilisé pour modéliser les procédures puisse être interfacé directement avec l'outil de routage. Ceci présuppose une normalisation de la description des procédures, à l'instar de ce qui est proposé par la « Management-Workflow Coalition ».

Les modèles de Merise sont tout à fait suffisants pour modéliser les flux de travaux. En général, un diagramme de flux entre acteurs est suffisant ; ce diagramme se limite à représenter les différentes phases, sans préciser les tâches qui composent la phase. Pour des flux plus complexes, un MOT complet peut apporter des compléments utiles. Au cas où la transposition de la procédure ne peut pas être générée automatiquement, il s'avère très utile d'utiliser un diagramme représentant le cycle de vie de l'objet qui parcourt la procédure. Par exemple, dans une application de rédaction d'un document, celui-ci parcourt un certain nombre d'états, qui déterminent le routage du document : il peut être « en cours de rédaction », « en cours de vérification », « en cours d'approbation », « approuvé », « en cours de diffusion », « annulé ».

La combinaison des possibilités du routage de flux de travaux et des possibilités plus ouvertes de l'informatique coopérative rend possibles des solutions très intéressantes, car elle permet d'insérer dans une procédure des tâches coopératives réalisées en commun par plusieurs intervenants (comme une prise de décision par un comité). Ces possibilités sont particulièrement utiles dans le contexte de l'alignement stratégique, où une coopération structurée de beaucoup d'intervenants est indispensable pour adapter en permanence les stratégies, les structures organisationnelles, les moyens technologiques de l'entreprise.