Ingénierie des systèmes d'information

Merise deuxième génération
Image non disponible


précédentsommairesuivant

IV. Partie 4 - Mise en œuvre de la méthode Merise

IV-A. Préambule

La deuxième partie traitait de la conception du Système d'Information Organisationnel. Cette troisième partie est consacrée à l'étude du Système d'Information Informatisé (SII), plus précisément à l'articulation des modélisations et formalismes associés. Cette partie précisera comment élaborer et exprimer les différents modèles, comment passer d'un niveau d'abstraction au suivant et transformer les différents modèles et, enfin, comment aborder toute optimisation.

Cette partie est consacrée à la mise en œuvre de la méthode Merise qui passe par le suivi d'une démarche et l'organisation de moyens. Le rôle et la nécessité de ces composantes ont déjà été exposés au chapitre 3Chapitre 3 Les trois composantes de Merise. Leur importance nécessiterait des développements détaillés et commentés.

Les précédentes éditions accordaient presque 200 pages à la présentation détaillée de ces thèmes. Les contraintes de pagination de cette nouvelle édition, ainsi que la volonté d'une mise en avant des raisonnements spécifiques à Merise, nous ont conduits :

  • à condenser cette partie en n'en présentant que les aspects principaux ;
  • à reporter, sous la forme de fichiers (format PDF d'Acrobat Reader) dans le CD joint, le contenu intégral des éditions initiales. Les lecteurs intéressés par des considérations opérationnelles de mise en œuvre retrouveront ainsi matière suffisante.

IV-B. Des démarches

Une démarche, dans le domaine de l'ingénierie des systèmes d'information, propose une séquence structurée de tâches guidant la mise en œuvre des différents raisonnements applicables pour l'informatisation d'un système d'information organisationnel.

Si une démarche est indispensable, il n'y a pas pour autant de démarche unique, car il n'y a pas de réponse unique à des contextes variés. Les méthodes n'ont certes pas inventé ou découvert ce qui constitue les activités de conception et de développement des projets informatiques ni la succession des étapes à franchir. Mais tous les « méthodologues » s'accordent sur l'importance de définir précisément, dans une méthode, ces activités et ces étapes, ainsi que sur l'importance de l'unicité de méthode pour un organisme.

Influencées par les environnements techniques, économiques et culturels, les démarches ont évolué et offrent aujourd'hui une diversité pouvant satisfaire une large palette de situations.

Cependant, pour être praticable, une démarche doit également pouvoir s'adapter d'une part à la taille et à la complexité du projet abordé, d'autre part au contexte et aux contraintes de l'entreprise. Cette personnalisation s'avère à chaque fois nécessaire.

IV-C. Évolution des démarches

IV-C-1. Première génération

Lors de la première génération de la méthode Merise, dans les années 80, la démarche proposée reposait sur les hypothèses explicites ou implicites suivantes :

  • des projets relativement ambitieux, correspondant au développement des grands systèmes d'information « intégrés » ;
  • une technologie dominée par les grands systèmes transactionnels avec des bases de données centralisées ;
  • une relative aisance budgétaire accordée à l'informatique ; un horizon perçu comme suffisamment stable pour permettre une planification de projets à moyen terme. La démarche préconisée s'inspire alors de celle mise en œuvre en génie civil, avec parfois un esprit « grandes manœuvres » : organisation, planification, points de décision, formalisation et structuration des tâches. Cette démarche est présentée au chapitre 15Chapitre 15 La démarche classique de Merise.

IV-C-2. Deuxième génération

Dans les années 90, l'environnement tant technique qu'économique évolue fortement avec les caractères majeurs suivants :

  • une technologie où le micro-ordinateur et son interface graphique sont le poste de travail privilégié de l'utilisateur, devenu également plus exigeant ;
  • un éclatement et une répartition des systèmes (émergence du client/serveur) ;
  • une crise économique restreignant les budgets et exigeant désormais une meilleure productivité des développements informatiques ;
  • une plus grande incertitude sur l'avenir favorisant les projets à court terme. Dans ce contexte, la démarche « classique » de la première génération a été perçue (parfois hâtivement) comme lourde, rigide et n'offrant pas de visibilité suffisante pour la conduite de projet (effet tunnel).

Une nouvelle démarche, dite rapide, a été proposée en alternative à la démarche classique. Cette démarche rapide remplace la « cascade » de tâches par une conception itérative faisant majoritairement appel au maquettage/prototypage et à une forte implication des utilisateurs. Cette démarche rapide relève plutôt d'un esprit « commando ». Cette démarche est présentée au chapitre 16Chapitre 16 La démarche rapide de Merise.

Dans cette deuxième génération de la méthode Merise, nous proposons une cohabitation des deux démarches qui, à l'expérience, correspondent à des situations de projets très différentes. Ainsi, suivant la nature et le contexte du projet envisagé, le concepteur optera-t-il pour l'une ou l'autre démarche. Dans les deux cas, il conservera les raisonnements du cycle d'abstraction.

Rappelons également que d'autres démarches peuvent aisément être associées aux raisonnements de Merise. Citons par exemple des « mariages » réussis avec SDM/S et Eurométhod.

Les démarches préconisées par la méthode Merise ne sont pas une obligation, mais une proposition, surtout en absence d'alternative.

IV-C-3. Personnalisation des démarches

La démarche est un guide général pour dérouler un projet ; elle ne doit pas être un carcan.

Par principe, une démarche type se doit de présenter l'exhaustivité des tâches nécessaires, tous projets confondus. Or, chaque projet présente des caractéristiques propres (nature, taille, contexte technique, enjeux, etc.) qui rendent nécessaire une adaptation de la démarche. Par exemple :

  • en étude préalable, la tâche d'évaluation des solutions techniques sera développée si le projet vise à déterminer l'architecture la plus adaptée, mais a contrario sera réduite si la configuration est figée d'avance ;
  • en étude préalable, l'analyse de l'existant peut être abrégée lorsqu'aucun problème particulier n'est prévisible, mais devra être approfondie lorsque la situation actuelle s'avère complexe ou confuse ;
  • en étude détaillée, l'étude des procédures de secours et des procédures de transition est fortement conditionnée par le contexte de chaque projet.

Avant d'engager une étape, il est donc indispensable que le responsable de projet réfléchisse à la personnalisation de sa démarche pour le projet. Il pourra par exemple s'inspirer de la technique suivante :

Personnalisation pour le projet Z

Étude préalable démarche type générale

Ignorer

Réduire

Normal

Développer

Lancement

   

X

 

Analyse de l'existant

 

X

   

Analyse des flux

   

X

 

Données actuelles

 

X

   

Informatisation actuelle

X

     

Organisation actuelle

 

X

   

Bilan

 

X

   

Besoins à satisfaire

   

X

 

Conception de solutions

   

X

 

Objectifs et contraintes

     

X

MCD futur

   

X

 

etc.

       

IV-D. Des moyens

La conception puis la réalisation d'un logiciel, support d'un système d'information, constituent une suite de processus complexes qui font intervenir un nombre important d'acteurs et de partenaires qui doivent s'organiser et disposer d'outils adaptés.

IV-D-1. Une organisation

Coordonner la diversité des savoir-faire pour respecter les engagements et améliorer la qualité, prévoir, organiser et suivre les ressources et les activités, voilà l'objectif de la maîtrise d'un projet.

Dans ce domaine, la méthode Merise se borne à proposer des principes généraux qui doivent être développés et adaptés au contexte de chaque organisme. Ces principes devront être en cohérence d'une part avec la méthode de conduite de projets adoptée, d'autre part avec les règles et recommandations d'assurance qualité en vigueur dans l'entreprise.

Ces principes généraux d'organisation se traduiront essentiellement par une structure type de projet articulée autour des groupes de projet, de pilotage et de validation. Ils seront présents, ainsi que les répartitions des tâches au chapitre 17Chapitre 17 L'organisation d'un projet Merise.

IV-D-2. Des outils

Si dans la première période de Merise, on a pu ou dû se satisfaire de modélisations manuelles, aujourd'hui, la mise en œuvre d'une méthode passe nécessairement par l'utilisation d'outils logiciels adaptés. On peut même affirmer que l'outil est le partenaire indispensable d'une méthode et interagit sur les évolutions et le devenir d'une méthode.

Dans le cas de la méthode Merise, le marché offre et a offert une diversité de produits qui, bien que différents, proposent un ensemble de fonctionnalités standards nécessaires à la mise en œuvre de la méthode Merise. Les principes de ces outils et l'illustration au travers de Win'Design font l'objet du chapitre 18Chapitre 18 Outils pour la mise en œuvre de Merise.

IV-E. Une adaptation au BPR

Les formalismes de modélisation proposés par la méthode Merise sont avant tout dédiés à la conception de systèmes d'information, qui s'inscrivent dans les disciplines de la gestion.

Dans les années 90, ce monde de la gestion a été traversé par le courant managérial du Business Process Reengineering qui proposait de nouvelles manières de se structurer et de s'organiser, accordant une place centrale aux technologies de l'information et aux systèmes d'information.

Il était donc tentant de voir si, avec des finalités différentes, les outils de modélisation utilisés dans la méthode Merise, trouvaient un usage pertinent dans le domaine du BPR. Cette adaptation, qui ouvre des perspectives très stimulantes, est présentée au chapitre 19Chapitre 19 Merise et le BPR.

IV-F. Chapitre 15 La démarche classique de Merise

IV-F-1. Principes généraux

IV-F-1-a. Découpage en étapes

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.

Dans la pratique, ce sont les étapes de conception d'un projet (de l'étude préalable à l'étude technique) qui sont les plus connues et utilisées, essentiellement à cause de l'efficacité des modélisations mises en œuvre.

Image non disponible
Figure 15.1 : Les étapes de la démarche classique Merise.

IV-F-1-b. Portée des étapes

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.

Image non disponible
Figure 15.2 Découpage et portée des différentes étapes de la démarche classique de Merise.

Dans ce chapitre, nous focaliserons la mise en œuvre de la démarche sur la période de développement du projet, et en particulier sur les étapes de conception. Les aspects de l'application de la méthode Merise au schéma directeur et à la maintenance, relativement marginalisés dans la pratique, sont exposés dans les annexes correspondantes enregistrées sur le CD.

IV-F-2. L'étude préalable

IV-F-2-a. Objectifs de l'étude préalable

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.

IV-F-2-b. Le sous-ensemble représentatif

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.

IV-F-2-c. Les phases de l'étude préalable

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.

Image non disponible
Figure 15.3 : Les quatre phases de l'étude préalable.

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.

IV-F-2-d. Phase de lancement

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.

Image non disponible
Figure 15.4 : Le lancement de l'étude préalable.

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.

IV-F-2-e. Phase d'analyse de l'existant

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.

Bien que nécessaire à la compréhension de l'activité du domaine, l'étude de l'existant ne doit pas être la tâche majeure de l'étude préalable. Il ne faut surtout pas rechercher l'exhaustivité du recensement des données et des traitements actuels, sous peine de dépassement de budget… L'étude de l'existant doit s'attacher à mettre en évidence les activités principales et informations associées, ainsi que les dysfonctionnements majeurs. Il ne faut pas transformer l'analyse en audit. Sur le terrain, bien des critiques de lourdeur attribuées à la méthode Merise le furent à cause d'analyses de l'existant complètes et systématiques, dont le bénéfice pour le futur système restait limité.

Image non disponible
Figure 15.5 : L'analyse de l'existant dans l'étude préalable.

IV-F-2-f. Analyse des flux d'informations

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).

IV-F-2-g. Analyse du modèle organisationnel actuel

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.

L'utilisation du modèle organisationnel des traitements (MOT) en étude préalable peut être facultative si l'aspect organisationnel est simple dans le domaine. Le diagramme des flux suffit alors pour exprimer le fonctionnement global du domaine.

IV-F-2-h. Analyse du modèle logique des données actuelles

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.

IV-F-2-i. Bilan critique de la situation actuelle

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.

IV-F-2-j. Souhaits et attentes à satisfaire

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.

IV-F-2-k. Phase de conception de solutions

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.

Image non disponible
Figure 15.6 : La phase de conception de solutions de l'étude préalable

IV-F-2-l. 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.

IV-F-2-m. Construction du modèle conceptuel de données futur

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.

En étude préalable, un MCD constitue davantage une structure qu'un descriptif : la quasi-totalité des entités et relations modélisables dans le domaine est exprimée ; par contre, les propriétés les caractérisant peuvent être très limitées, elles servent surtout à stimuler la compréhension du modèle par les lecteurs.

IV-F-2-n. Construction du modèle conceptuel de traitements futur

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.

IV-F-2-o. Confrontation MCD / MCT

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.

IV-F-2-p. Construction de modèles organisationnels de 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.

IV-F-2-q. Construction du modèle organisationnel de données

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).

IV-F-2-r. Confrontation MOD/MOT

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

IV-F-2-s. Synthèse et validation des solutions proposées

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.

IV-F-2-t. Phase d'évaluation et d'appréciation des solutions

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

Image non disponible
Figure 15.7 : La phase d'évaluation et d'appréciation des solutions de l'étude préalable.

IV-F-2-u. Chiffrage du volume et de l'activité

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.

IV-F-2-v. Architectures informatiques

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]).

IV-F-2-w. Principes de transition du système actuel au système futur

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.

IV-F-2-x. Scénarios de développement

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.

IV-F-2-y. Estimation des délais et des coûts

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.

IV-F-2-z. Appréciation des différentes solutions proposées

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.

IV-F-2-aa. Rédaction du dossier de choix

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.

IV-F-2-ab. Décision sur l'étude préalable

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.

IV-F-3. L'étude détaillée

IV-F-3-a. Objectifs de l'étude détaillée

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.

IV-F-3-b. Les phases de l'étude détaillée

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.

Image non disponible
Figure 15.8 : Les phases de l'étude détaillée.

IV-F-3-c. Phase de spécifications générales

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).

Image non disponible
Figure 15.9 : Phase de spécifications générales de l'étude détaillée.

IV-F-3-d. Extension du modèle conceptuel de données

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.

IV-F-3-e. Extension du modèle conceptuel de traitements

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.

IV-F-3-f. Extension du modèle organisationnel des données

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.

IV-F-3-g. Extension du modèle organisationnel de traitements

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.

Le concepteur ne présente pas ici la description détaillée de chaque tâche. Celle-ci sera abordée dans la phase suivante. Le concepteur présente le modèle organisationnel par les documents suivants :

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.

IV-F-3-h. Cohérence MOD / MOT

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.

IV-F-3-i. Phase de spécifications détaillées

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.

Image non disponible
Figure 15.10 : La phase de spécifications détaillées de l'étude détaillée.

IV-F-3-j. Spécification détaillée des phases interactives

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.

IV-F-3-k. Spécification détaillée des phases automatiques

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.

IV-F-3-l. Confrontation détaillée

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.

IV-F-3-m. Finalisation du modèle organisationnel de données

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.

IV-F-3-n. Phase de spécification des procédures transitoires

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.
Image non disponible
Figure 15.11 : La phase de spécification des procédures transitoires de l'étude détaillée

IV-F-3-o. Récupération et transfert des données actuelles

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.

IV-F-3-p. Modèle organisationnel de traitements transitoire

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.

IV-F-3-q. Phase de spécification des procédures de secours

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.

Image non disponible
Figure 15.12 : La phase de spécification des procédures de secours de l'étude détaillée

IV-F-3-r. Modèle organisationnel des traitements en secours

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.

IV-F-3-s. Procédures de rattrapage de l'activité

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.

IV-F-3-t. Finalisation de l'étude détaillée

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).

Image non disponible
Figure 15.13 : Phase de finalisation de l'étude détaillée.

IV-F-3-u. Validation générale

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.

IV-F-3-v. Révision des estimations et de la planification

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.

IV-F-3-w. Rédaction du dossier d'étude détaillée

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.

IV-F-4. L'étude technique

IV-F-4-a. Objectifs de l'étude technique

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.

IV-F-4-b. Les phases de l'étude technique

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.

Image non disponible
Figure 15.14 : Les phases de l'étude technique.

IV-F-4-c. Architectures logicielles

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.

Image non disponible
Figure 15.15 : La phase d'architectures logicielles de l'étude technique.

IV-F-4-d. Architecture technique des données

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.

IV-F-4-e. Architecture technique des programmes

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.

IV-F-4-f. Préparation de la réalisation

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.

Image non disponible
Figure 15.16 : La phase de préparation de la réalisation de l'étude technique.

IV-F-4-g. Outils de réalisation

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.

IV-F-4-h. Règles de développement

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.

IV-F-4-i. Principes de qualification

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.

IV-F-4-j. Organisation du développement

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é.

IV-F-5. La production du logiciel

IV-F-5-a. Objectifs de la' production du logiciel

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.

IV-F-5-b. Les phases de la production du logiciel

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.

Image non disponible
Figure 15.17 : Les phases de la production du logiciel.

La recette avant lancement portera sur le logiciel et sa documentation ; elle sera menée par les utilisateurs et le service d'exploitation au cours de l'étape suivante de mise en service.

IV-F-6. La mise en service

IV-F-6-a. Objectifs de la mise en service

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.

IV-F-6-b. Les phases de la mise en service

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.

Image non disponible
Figure 15.18 : Les phases de la mise en service.

IV-F-6-c. Planification de la mise en service

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 service commence souvent dès la fin de l'étude détaillée ; elle se déroule donc d'abord en parallèle avec l'étude technique et la réalisation ; puis à la suite de la réalisation dont elle met en exploitation le résultat.

Il est donc important de synchroniser très exactement les plannings correspondants.

IV-F-6-d. Mise en place des ressources

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.

IV-F-6-e. Préparation du lancement

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é.

IV-F-6-f. Déploiement

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.

IV-G. Chapitre 16 La démarche rapide de Merise

IV-G-1. Principes généraux

IV-G-1-a. Contexte d'émergence d'une démarche rapide

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.

IV-G-1-b. Critiques de la démarche « classique »

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.

IV-G-1-c. Des évolutions technologiques

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.

IV-G-1-d. De nouvelles exigences

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é.

IV-G-1-e. La démarche RAD

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.

Image non disponible
Figure 16.1 : Phases de la démarche RAD

IV-G-1-f. Positionnement de la démarche rapide

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.

IV-G-1-g. Découpage en étapes

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.

Image non disponible
Figure 16.2 : Les étapes de la démarche rapide de Merise

IV-G-2. La définition générale du système

IV-G-2-a. Objectifs de la définition générale du système

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.

IV-G-2-b. Les phases de la définition générale du système

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.

Image non disponible
Figure 16.3 : Les phases de la définition générale du système

IV-G-2-c. Phase d'appréciation du projet

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.

IV-G-2-d. Positionnement du projet

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 ?

IV-G-2-e. Délimitation des fonctions à informatiser

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.

IV-G-2-f. Évaluation des enjeux

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é.

IV-G-2-g. Phase de spécifications générales

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.

Image non disponible
Figure 16.4 : La phase de spécifications générale de la définition générale du système.

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.

IV-G-2-h. Modélisation conceptuelle des données

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).

La mise en œuvre d'une démarche rapide ne saurait être associée à l'utilisation d'un formalisme modélisation des données « allégé ». La pratique a suffisamment démontré la puissance du formalisme entité - relation dont l'utilisation peut être modulée en fonction des besoins d'expression.

IV-G-2-i. Macro-modélisation organisationnelle des traitements

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.

IV-G-2-j. Rédaction du dossier de spécifications générales

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.

IV-G-3. La conception détaillée de l'application

IV-G-3-a. Objectifs de la conception détaillée de l'application

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.

IV-G-3-b. Les phases de la conception détaillée de l'application

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 :

Image non disponible
Figure 16.5 : Les phases de la conception détaillées.

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

IV-G-3-c. Phase de développement de la maquette

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.

Image non disponible
Figure 16.6 : La phase de développement de la maquette de la conception détaillée.

IV-G-3-d. Rôle du maquettage

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).

IV-G-3-e. Intérêt du maquettage

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 :

Image non disponible

IV-G-3-f. Diversité de maquettages

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.

IV-G-3-g. Maquette jetable ou construction progressive du système ?

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 :

Image non disponible

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.

IV-G-3-h. Modélisation des données

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 :

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.

IV-G-3-i. Conception des dialogues

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).

IV-G-3-j. Expression des règles

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.

IV-G-3-k. Enrichissement des spécifications fonctionnelles détaillées

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.

IV-G-3-l. Phase d'évaluation de la maquette

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.

IV-G-3-m. Présentation de la maquette

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 réussite d'une approche par maquettage dépend très fortement de la qualité de cette présentation aussi le concepteur doit apporter un soin particulier à l'animation de la séance de validation. Elle ne doit pas se réduire à une démonstration de la maquette ; bien d'autres éléments constituent les spécifications détaillées de l'application : diagrammes de procédures, règles de gestion, éventuellement modèles de données, qui doivent également être présentés.

IV-G-3-n. Formalisation des amendements

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.

IV-G-4. La réalisation du logiciel

Cette étape, qui reste toujours essentielle dans le développement d'une application, met en œuvre des techniques et des savoir-faire qui sont peu concernés par les apports méthodologiques de la méthode Merise ; aussi cette étape ne sera pas détaillée en phases.

La réalisation de l'application définitive se fait en reprenant des composants déjà élaborés pour la maquette, en y rajoutant les éléments non simulables dans la maquette, en particulier des règles de traitement.

Dans la démarche proposée, on suggère d'aborder cette étape de réalisation dans la continuité de la maquette dynamique et en adoptant une démarche dite « en spirale ». Cette dernière préconise un découpage en « modules fonctionnels » de taille limitée permettant un cycle conception-réalisation très rapide, l'application complète se construisant par une succession de cycles sur les modules.

Dans cette étape, le réalisateur tient compte également des aspects sécurité, confidentialité et gestion de l'exploitation nécessaires à l'application.

Par rapport aux aspects abordés dans la démarche proposée, on rappellera deux tâches spécifiques à cette étape : l'optimisation de la base de données et la prise en compte des spécificités de l'environnement de développement retenu.

IV-G-4-a. L'optimisation de la base de données

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).

IV-G-4-b. Prise en compte des spécificités de l'environnement de développement

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.

IV-G-5. Le déploiement

À ce niveau, suivant la nature et l'ampleur de l'application développée, la mise en service peut prendre les différentes formes évoquées dans la démarche classique.

Cette étape consiste à installer l'application sur un ou plusieurs sites pilotes afin de vérifier son acceptation par les utilisateurs. Elle permet également d'apporter d'une part les différentes corrections qui fiabiliseront l'application, d'autre part les modifications mineures demandées par les utilisateurs.

Dans tous les cas, on retrouvera au moins les tâches suivantes :

  • Mise en place des moyens techniques, de l'organisation et des ressources nécessaires.
  • Finalisation de la documentation utilisateur.
  • Période probatoire.
  • Recette définitive et généralisation.

IV-H. Chapitre 17 L'organisation d'un projet Merise

Les deux composantes fondamentales de la méthode Merise présentées dans les chapitres précédents, les raisonnements (deuxième et troisième parties) et la démarche (quatrième partie) ne sont pas suffisantes. En effet, elles présentent, lors de la mise en application pratique, une lacune qui peut s'avérer fatale pour l'accomplissement du projet : la maîtrise du déroulement du projet et la responsabilité des choix et des décisions.

À l'issue de chaque étape de la démarche, voire de chaque phase, l'application des raisonnements de la méthode Merise a permis de proposer des solutions, à tous les niveaux, pour l'informatisation du futur système d'information. La maîtrise du déroulement du projet s'intéresse aux questions suivantes :

  • Quelles sont les décisions attendues ?
  • De quelle nature sont-elles ?
  • Quelles sont les responsabilités à engager ?
  • Quelles sont les ressources à mettre en œuvre ?

Jusqu'à présent, dans le déroulement de la méthode Merise, nous avons évoqué différents intervenants, notamment le concepteur, le réalisateur, le décideur. Il est nécessaire de se demander :

  • Quels sont les différents types d'intervenants pour une mise en œuvre opérationnelle de la méthode Merise ?
  • Quelles sont les structures à mettre en place pour assurer une maîtrise effective d'un projet ?

Initialement, les promoteurs de la méthode Merise, préoccupés en priorité par une contribution en termes de démarche et de raisonnement, avaient laissé aux utilisateurs le soin d'apporter des réponses à ces questions. Les années d'expérience accumulées ont permis de conclure que ces problèmes devaient être abordés dans une méthode, d'autant qu'un certain nombre de traits généraux se dessinent aujourd'hui.

Enfin, la mise en œuvre opérationnelle d'une méthode passe maintenant obligatoirement par des outils logiciels d'aide à la conception et à la documentation (chapitre 18Chapitre 18 Outils pour la mise en œuvre de Merise).

Nous abordons dans ce chapitre, consacré aux moyens de mise en œuvre de la méthode Merise, d'une part les structures et l'organisation des différents intervenants dans un projet utilisant Merise et d'autre part le rôle de ces différentes structures au cours de la démarche.

IV-H-1. Structures et intervenants dans un projet merise

Nous distinguons trois types de structures : tout d'abord les structures permanentes, ensuite les structures spécifiques au projet et enfin les structures de conseil.

IV-H-1-a. Les structures permanentes

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.

IV-H-1-b. Les structures de projet

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.

IV-H-1-c. Groupe de validation

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.

Image non disponible
Figure 17.1 : Structures dans un projet Merise.

IV-H-2. Les structures de conseil

La conception et la réalisation d'un système d'information font appel à des connaissances très variées qui parfois ne sont pas toutes réunies au sein du groupe de projet. Afin de pallier d'éventuelles lacunes, les structures de projet peuvent solliciter ponctuellement l'intervention de spécialistes dans différentes disciplines mises en œuvre dans la conception et la réalisation du système d'information. Nous pouvons distinguer différentes spécialités, dans le contexte des raisonnements de la méthode Merise :

  • Spécialiste du domaine d'activité : La conception d'un nouveau système d'information est souvent l'occasion de rénover les techniques utilisées dans l'activité : nouvelle méthode de gestion de production, changement d'organisation… L'intervention du spécialiste porte alors sur le contenu même de l'activité et la manière de l'exercer.
  • Spécialiste de la méthode Merise : Bien que facile à mettre en œuvre, la maîtrise complète de cette méthode requiert une pratique certaine, surtout pour l'élaboration des différents modèles et le respect de la démarche. L'intervention du spécialiste est alors d'ordre méthodologique afin d'éviter l'enlisement du projet sur des problèmes de formalisation et de démarche.
  • Spécialiste de l'organisation : La méthode Merise a mis en évidence le rôle important joué par l'organisation dans la conception et le fonctionnement d'un système d'information. L'intervention du spécialiste porte alors sur l'appréciation des postes, des procédures, sur l'ergonomie générale de l'organisation humaine et matérielle.
  • Spécialiste des techniques informatiques : Un projet de conception et de réalisation d'un système d'information comporte indéniablement une part importante de technique informatique, connaissance des matériels, problèmes de télécommunications, outils de productions, langages… L'intervention du spécialiste porte alors sur l'aide au choix du matériel, l'estimation des coûts et délais suivant les conditions de réalisation, la résolution de problèmes ponctuels lors de la réalisation.

Ces différentes compétences peuvent soit être disponibles au sein de l'entreprise, soit être ponctuellement recherchées à l'extérieur.

IV-H-3. Rôle des structures dans la démarche

Les différentes structures précédemment décrites, et en particulier celles propres au projet, jouent des rôles divers au cours du déroulement du projet. L'organisation générale proposée pour Merise doit être adaptée dans le contexte particulier de chaque entreprise. Suivant la taille de l'entreprise et l'ampleur du projet, on ne mobilisera pas les mêmes ressources. De plus, les personnalités des différents intervenants et les contingences matérielles ne permettent pas toujours de mettre en place une organisation idéale.

Nous voulons présenter, dans le contexte de ce document, des principes généraux sur les rôles respectifs des différents intervenants. Nous incitons vivement chaque entreprise utilisatrice de la méthode Merise à réfléchir à une personnalisation de cette organisation.

IV-H-4. Classification des activités

Les récentes réflexions dans le domaine du génie logiciel et plus particulièrement dans le domaine de l'assurance qualité proposent une typologie des différentes activités émergeant dans un projet d'étude et de réalisation d'un système d'information. On distingue schématiquement les activités suivantes :

  • Produire, c'est-à-dire exercer une activité intellectuelle ou physique contribuant à l'élaboration du projet, par exemple participer à la construction d'un modèle, écrire un programme, faire un test…
  • Documenter, on distingue cette activité de production qui est destinée à faciliter la lecture des spécifications du projet ; par exemple rédiger un rapport d'étude, décrire un modèle, documenter un programme, écrire un manuel utilisateur…
  • Décider, c'est-à-dire agir sur le déroulement du projet en termes de choix sur les coûts, délais ou qualité.
  • Valider, c'est-à-dire se prononcer sur la conformité de la production par rapport aux souhaits et spécifications initiales.
  • Conseiller, c'est-à-dire apporter un avis, une contribution ponctuelle lors de la production.
  • Piloter, c'est-à-dire donner les orientations et les choix au groupe de projet, diriger l'équipe.
  • Approuver les décisions prises par un autre intervenant, généralement en termes de respect de coût, de délai et de qualité.

IV-H-4-a. Activités des structures de projet au cours de la démarche

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.

Image non disponible
Figure 17.2 : Les rôles des structures

IV-H-4-b. La validation, facteur de qualité

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.

Image non disponible
Figure 17.3 : Les maillons de la qualité globale.

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.

IV-H-4-c. Modalités de validation

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

La méthode Merise accorde une part importante à la modélisation pour l'expression des spécifications. L'expérience nous a confirmé l'efficacité de ce mode de spécification. Toutefois, le caractère formel des modélisations (en particulier dans les données) nécessite une certaine maîtrise des formalismes que l'on ne peut pas toujours attendre de tous les utilisateurs.

Aussi, l'utilisation directe des modélisations comme seul support de validation des spécifications ne peut pratiquement se réaliser qu'au sein du groupe de projet. Même dans ce cas, le chef de projet (informaticien) doit s'assurer de la maîtrise de la formalisation et ne pas hésiter à expliciter la signification des modélisations auprès des participants - utilisateurs. Par contre, la présentation directe et non commentée(8) des modélisations auprès du groupe de validation est, à l'expérience, à déconseiller, surtout pour les modélisations conceptuelles de données.

Dans tous les cas, la présentation de modèles auprès du groupe de validation ne peut se faire que dans le cadre de la présentation de solutions, accompagnée d'explications, avec un important effort de pédagogie (sans pour cela se transformer en « cours » de modélisation…).

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

Il s'agit en fait de l'animation de réunions de validation. Sur la base des éléments de solutions élaborés par le groupe de projet, comprenant bien sûr les modélisations, le groupe de projet construit une présentation de ces solutions. Les animateurs feront appel aux divers modes et techniques de présentation.

Les modèles élaborés par l'équipe de projet, sur lesquels les spécifications s'appuient, doivent être cependant présentés aux gestionnaires et utilisateurs du domaine pour qu'ils puissent confirmer si les options prises, les modélisations retenues, expriment correctement les choix et les significations fondamentales du système d'information du domaine.

Ces personnes sont expertes dans leur domaine d'application, mais rarement dans les formalismes de Merise. Il est ainsi nécessaire de reformuler chaque modélisation en français. Dans cette reformulation :

  • les concepts de base du domaine d'application feront l'objet d'une définition simple et rigoureuse ;
  • ces concepts seront illustrés par des exemples réalistes ;
  • le modèle sera expliqué et commenté, de préférence par parties (vues) ; de même, il faudra réduire le plus possible l'utilisation des termes techniques des formalismes (cardinalité, synchronisation…).

Bien préparée, une telle présentation contribuera ainsi à une meilleure compréhension du projet et facilitera la mise en service du futur système. Ce mode de validation est à conseiller en étude préalable et en phase de conception générale de l'étude détaillée.

IV-H-4-c-iii. Maquettage

En étude détaillée de la démarche « classique » ou dans le cadre de démarche « rapide », l'élaboration de l'interface utilisateur sous forme de maquettes ou de prototypes facilite grandement la validation par les utilisateurs (voir sur ce point le chapitre 16Chapitre 16 La démarche rapide de Merise).

IV-H-5. Compléments pour l'estimation des projets

Outre les ordres de grandeur pour l'estimation et la répartition des charges pour les différentes étapes du cycle de vie, il peut être également intéressant de préciser, à l'intérieur de chaque étape, la répartition de la charge de travail par catégorie d'intervenants.

En partant de l'observation et de l'expérience de Cecima, largement confirmée par de nombreux professionnels, nous allons présenter des répartitions des charges de travail moyennes entre informaticiens et utilisateurs(groupe de validation compris). On s'intéressera à deux types de répartitions : une répartition par étape et une répartition par rôle.

Première répartition moyenne par étape et par rôle

Notre expérience nous conduit aux ordres de grandeur (exprimés en %) de la figure 17.4.

Image non disponible
Figure 17.4 : Première répartition moyenne par étape et par rôle des charges de travail.

Il est à noter que la répartition de la charge de travail privilégie en étude préalable la part utilisateur (70 %). Cette part se trouve inversée au niveau de l'étude détaillée (30 %) par rapport aux informaticiens. La moyenne pondérée entre la charge de travail par rôle et la part de chaque étape dans le cycle de vie nous donne le total de la contribution des informaticiens (environ 70 %) et des utilisateurs (30 %) pour l'ensemble des étapes.

Seconde répartition moyenne par rôle et par étape

En fonction de la première répartition, la seconde répartition (voir figure 17.5) se déduit par calcul et indique, pour chaque rôle, la composition de sa charge totale de travail par étape.

Image non disponible
Figure 17.5 : Seconde répartition moyenne par étape des charges de travail.

On notera qu'à l'issue de la réalisation, l'informaticien a réalisé 95 % de sa charge totale (pour l'informaticien, le projet est quasiment terminé !), alors que l'utilisateur conserve une charge non encore réalisée de 30 % du total de sa charge (pour l'utilisateur, le projet est loin d'être terminé !).

IV-H-6. Guide de projet, manuel qualité

Un projet avec Merise implique avant tout des intervenants qui mènent ensemble le projet (qualité, coût, délai) en utilisant à bon escient différents modèles du système d'information. Présenter au lecteur ces différentes notions, expliquer leurs tenants et aboutissants, tel est le but principal de cet ouvrage. Cet ouvrage peut aussi être utilisé par les équipes de projet, les reports étant accélérés par utilisation de l'index de fin de volume.

Il existe aussi un autre type de support, directement conçu pour faciliter la conduite de projet avec Merise : le guide de projet. Dans un tel guide, il s'agit moins de justifier les notions que de les appliquer rapidement et sûrement, d'où la structure habituelle d'un guide de projet :

  • un ensemble de fiches d'action (une par tâche), rédigées dans un style le plus clair et le plus opérationnel possible ;
  • un ensemble de fiches techniques complémentaires, rappelant comment utiliser telle ou telle technique de base en conception des systèmes d'information.

Il existe également un répertoire de références croisées entre fiches d'action et fiches techniques.

Remarques

Les fiches techniques constituent un lieu d'accueil privilégié pour les normes techniques et les standards de l'entreprise. Lorsque l'entreprise décide de s'engager explicitement sur la voie de la qualité, le guide de projet devient ainsi, tout naturellement, un manuel qualité.

Selon l'AFNOR, le manuel qualité décrit les dispositions prises par l'entreprise pour obtenir la qualité de ses produits ; en fonction de l'organisation de la société et de la nature générale des projets à traiter, il définit la technologie en vigueur pour assurer la qualité d'un développement, ici informatique.

IV-I. Chapitre 18 Outils pour la mise en œuvre de Merise

Si des projets modestes peuvent se satisfaire aisément d'un ensemble de formulaires pour leur documentation, d'un tableau et de feutres pour la conception, le recours à des outils logiciels procure aux concepteurs et aux réalisateurs une assistance certaine.

La diffusion et l'intégration d'une méthode passent nécessairement par l'existence d'outils logiciels associés. Ces outils sont généralement conçus et diffusés par les promoteurs de la méthode. Dans le cas de la méthode Merise, son origine collective, source de richesse, a donné naissance à de nombreuses versions d'outils. Aujourd'hui, seuls quelques-uns se sont imposés, ils assurent pour la plupart une bonne couverture fonctionnelle et méthodologique (nous présentons plus loin l'un d'entre eux : Win'Design).

IV-I-1. Les ateliers de génie logiciel

Les outils logiciels, support de la mise en œuvre de la méthode Merise ou d'autres méthodes, participent au courant plus large des ateliers de génie logiciel (CASE en anglais : Computer Aided Software Engeniering) couvrant tout ou partie des cycles de conception, développement et maintenance des applications informatiques.

Cette approche industrielle de la production de logiciels, initiée par l'informatique à vocation technique de type temps réel, s'est développée autour de deux axes :

  • La conception du système d'information : Upper Case ou atelier de conception.
  • La spécification du logiciel et la production du code : Lower Case ou atelier de réalisation.

Si pour le deuxième axe, la préoccupation essentielle de productivité a été et demeure dépendante de l'environnement technique de développement (SGBD, système d'exploitation, langage, interface utilisateur…), les outils relevant du premier axe, au travers de méthodes de conception largement diffusées, ont une vocation plus large, et se prêtent plus facilement à une certaine normalisation et à une formalisation (niveau de modélisation, notions manipulées, représentation graphique, règles de comportement et de passage…).

Dans les années 80, ces deux catégories d'outils ont eu des difficultés à communiquer, tant sur le plan des concepts utilisés, qu'au niveau technique. Ces difficultés étaient souvent dues à une hétérogénéité des plates-formes matérielles supportant ces outils et à un problème de transformation des objets de conception en objets de réalisation, les méthodes étant sur ce point, notamment pour les traitements, relativement défaillantes.

Plus récemment, la cohabitation et la convergence de plusieurs courants marquent une étape importante de transition dans l'utilisation des ateliers et outils de génie logiciels :

  • la convergence des environnements de développement (client-serveur, Internet, base de données relationnelles, langages…) ;
  • l'utilisation de démarche de type « développement rapide » ;
  • le développement en langage-objet et la perspective de réutilisation "de composants logiciel” et d'objet « métier » ;

rendent encore plus nécessaire la communication entre environnement de conception et de réalisation.

Ces dernières années, la diffusion de méthodes « orientées objet », comme UML, a pu faire penser que ce problème était quasiment résolu en uniformisant, par des concepts et des formalismes communs, la modélisation du système d'information organisationnel (S.I.O) et celle du système d'information informatisé (S.I.I).

Dans la réalité, cette transition entre les « objets métiers » (S.I.O) et les « objets logiciel » (S.I.I) reste dans la même problématique que pour les méthodes « classiques ».

La nécessité de communication est une des priorités majeures et l'évolution de ces outils se traduira, sous diverses formes, par une meilleure cohabitation pour assurer une continuité entre les spécifications externes d'un système d'information et la production des logiciels s'y appliquant. Actuellement, la plupart des outils de conception, notamment ceux associés à Merise, permettent au moins la génération automatique des scripts de création et de modification SQL de bases de données directement exécutables par la plupart des SGBD, ainsi que la description des principaux triggers assurant l'intégrité de ces bases.

L'offre sur le marché, toutes catégories confondues, est actuellement importante et très diverse. Dans le domaine de la gestion, près d'une centaine d'outils sont recensés, et presque autant dans le domaine du temps réel. Il existe par ailleurs de nombreux catalogues et enquêtes sur le sujet (CXP, YPHISE, AFCET, ADELI…) fournissant des synthèses et points comparatifs très utiles dans un domaine aussi ambitieux, mouvant et très prolixe en solutions, concepts et sigles divers.

IV-I-2. La notion de dictionnaire

Avant de présenter, tout du moins pour celles relevant de Merise, les caractéristiques générales des outils, il est utile de préciser la notion de dictionnaire. En effet, le dictionnaire, pivot des ateliers de génie logiciel, est déterminant pour qualifier le champ d'application et l'aptitude à communiquer et à évoluer de ces outils.

Le dictionnaire est destiné à mémoriser, gérer et contrôler les différents objets de conception et/ou de réalisation des systèmes d'information étudiés. Ainsi, il contiendra pour la méthode Merise, des notions telles que :

  • entité, relation, propriété… pour le modèle conceptuel de données et le modèle organisationnel de données ;
  • opération, événement, acteur… pour le modèle conceptuel de traitements ;
  • tâche, procédure, règle, poste… pour le modèle organisationnel de traitements ;
  • record, item, table, attribut… pour le modèle logique de données ;
  • ULT (Unité Logique de Traitement), blocs… pour le modèle logique de traitements ;
  • programme, module, écran… pour les modèles physiques de traitements.

L'alimentation de ce dictionnaire peut s'effectuer progressivement au cours de la conception, enrichissant ainsi la base de description du système d'information étudié. Un tel dictionnaire permet, à tout instant de l'étude, la restitution d'une documentation à jour, normalisée et cohérente. L'intégration de tous les modèles permet également le recours à des références croisées, indispensables lors de modifications successives au cours de la conception, pour vérifier les règles du formalisme et garantir une cohérence des modèles.

IV-I-2-a. Métamodèle

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.

IV-I-2-b. Types de dictionnaires et outils associés

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.

IV-I-2-c. Les dictionnaires autonomes et communicants

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.

IV-I-2-d. Les dictionnaires intégrés

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.

IV-I-2-e. Référentiels et plates-formes d'intégration

À 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.

IV-I-3. Les grandes fonctions des ateliers de génie logiciel

On retrouve en général, articulées autour du dictionnaire, un ensemble de fonctions d'accès, de modélisation, de contrôle, de restitution, adaptées au formalisme des méthodes. Nous donnons ci-après quelques grandes orientations de ces fonctionnalités. On présentera plus loin et de façon plus détaillée un tel atelier de conception, l'atelier Win'Design développé par la société Cecima.

IV-I-3-a. Aides à la conception

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é.

IV-I-3-b. Production de rapport

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.

IV-I-3-c. Simulation et maquettage

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.

IV-I-3-d. Production de logiciel

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 …

IV-I-3-e. Conduite de projet

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.

IV-I-4. Un exemple d'atelier de conception : Win'Design

IV-I-4-a. Introduction

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 2e 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.

IV-I-4-b. Environnement de travail

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.

Image non disponible
Figure 18.1 : fenêtre principale de Win'Design avec l'espace de travail

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).

Image non disponible
Figure 18.2 : utilisation du dictionnaire d'objets

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).

Image non disponible
Figure 18.3 : système de requêtes sur le dictionnaire

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).

Image non disponible
Figure 18.4 : Gestion et paramétrage du dossier

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.

IV-I-4-c. Fonctions spécifiques à chaque type de modèle

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).

    Image non disponible
    Figure 18.5 : Exemple de M.C.D
  • 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).
Image non disponible
Figure 18.6 : Modélisation des règles
  • 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.
Image non disponible
Figure 18.7 : Description des états d'une entité
  • 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).
Image non disponible
Figure 18. 8 : Exemple d'une propriété composée et multivaluée
  • 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.

Image non disponible
Figure 18.9 : Exemple de M.L.D.

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).
Image non disponible
Figure 18.10 : Exemple de script de création de base de données

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).

Image non disponible
Figure 18.11 : Exemple de génération de triggers

IV-I-4-d. Reverse bases de données

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).

IV-I-4-e. Les Modèles de Traitements

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.
Image non disponible
Figure 18.12 : Exemple de M.O.T.

IV-I-4-f. Conception par décomposition

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).

IV-I-4-g. Association des modèles de données et de traitements

À 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 ».
Image non disponible
Figure 18.13 : Accès aux données, association de règles et maquettes
  • 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.

IV-I-4-h. Maquettage de l'interface homme-machine

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é.

Image non disponible
Figure 18.14 : exemple d'une maquette d'écran

IV-J. Chapitre 19 Merise et le BPR

IV-J-1. Merise et la Renaissance ou la renaissance de Merise

Il y a des époques où tout change, où en l'espace de quelques années le monde se transforme de façon fondamentale et où les anciens paradigmes sont assez rapidement remplacés par de nouveaux modes de pensée et de vie. La Renaissance a été une telle époque de transition rapide vers un monde nouveau. De nombreux indices suggèrent que nous vivons actuellement une transition similaire, où les hypothèses de travail, qui étaient vraies il y a quelques années encore, sont profondément bouleversées et font place à des idées nouvelles.

Le but de ce chapitre est de montrer que Merise est l'enfant d'une telle transition, et si par certains aspects il est marqué par le paradigme ancien, il y a par contre d'autres facettes qui sont déjà annonciatrices du paradigme nouveau. Il faudra donc faire la part des choses et mettre en évidence les fondements sains qui pourraient constituer la base pour une nouvelle approche, tout en abandonnant d'autres principes qui n'ont plus aucun sens dans un monde en changement.

Certains y vont un peu vite et sont prêts à jeter l'enfant avec le bain : à leurs yeux Merise n'a plus aucune raison d'être à une époque où tout se décline en termes d'objets. Il n'est pourtant pas prouvé que la notion d'objet est vraiment aussi fondamentale que certains ne le croient. Ce qui gêne le plus dans le concept d'objet, et même dans son nom, c'est qu'il est peu approprié pour tenir compte des êtres humains ; à force de décrire des objets, on a tendance à oublier que le potentiel humain constitue la ressource la plus précieuse de l'entreprise et que toutes les technologies de communication et de traitement de l'information n'ont de sens que dans la mesure où elles permettent de mettre en valeur les compétences proprement humaines.

Or, le courant managérial du Business Process Reengineering (BPR) a mis en évidence le rôle des êtres humains et l'un de ses objectifs consiste justement à changer radicalement l'entreprise en vue de transformer les êtres humains-« objets » des organisations traditionnelles en êtres humains émancipés, pleinement responsables de leurs actions et jouissant d'une autonomie suffisante pour mener avec succès leur propre projet d'entreprise.

C'est cette redécouverte du rôle fondamental assumé par l'être humain dans le tissu socio-économique qui n'est pas sans nous rappeler l'époque de la Renaissance. Le BPR, par de nombreux aspects, s'insère parfaitement dans cette vision nouvelle des choses, qui revalorise les compétences humaines, tout en mettant à sa disposition des outils bien plus puissants que tout ce qu'il a jamais eu entre les mains.

Le BPR constitue une première vague de changements, qui sont en train de transformer radicalement les entreprises. Une deuxième vague est constituée par l'expansion spectaculaire d'Internet et par l'émergence du commerce électronique, aussi bien entre entreprises qu'avec les consommateurs. D'autres vagues suivront, mais la méthode Merise a le potentiel de survivre à tous ces changements, car elle constitue un cadre de modélisation souple et adaptable au contexte technologique.

IV-J-2. Le BPR, une première vague de changements

Il n'y a aucun doute que le BPR a fait son apparition avec les allures d'une mode ou d'une opération de marketing. Les théories propagées par Michael Hammer et James Champy dans de nombreux articles parus dans des revues réputées et surtout leur livre de référence Reengineering the corporation : a manifesto for business revolution [Hammer 93] avec ses thèses provocatrices ont soulevé suffisamment de poussière pour identifier le BPR à ces deux auteurs.

Selon leur définition, mille fois reproduite dans la presse, le « reengineering » serait « une remise en cause fondamentale et une redéfinition radicale des processus opérationnels pour obtenir des gains spectaculaires dans les performances critiques que constituent aujourd'hui les coûts, la qualité, le service et la rapidité ». En faisant miroiter des « gains spectaculaires », ils ont immédiatement attiré l'attention et la bienveillance des chefs d'entreprise, toujours fort sensibles à des perspectives de profit.

Les mesures radicales proposées par les deux auteurs se sont pourtant révélées être inapplicables dans la plupart des situations réelles, et après une phase d'euphorie, on a rapidement dû déchanter et se fixer des objectifs plus modestes. Y. Tabourier attire d'ailleurs avec raison l'attention sur le fait que c'est uniquement dans la préface de l'édition française que Hammer et Champy mentionnent d'éventuels problèmes humains et sociaux liés à la cure radicale proposée par leur modèle de BPR virulent [Tabourier 94]. Ce qui fait que le BPR fut rapidement associé à un modèle d'organisation américain, n'ayant que peu de chance de succès dans le contexte socio-économique de « l'Ancien Continent ».

Ce serait pourtant une grosse erreur que d'aborder le sujet de cette façon. Les idées fondamentales qui sont à la base du BPR sont bien plus anciennes et plus solides que la présentation qui en est faite par Hammer et Champy. De nombreux auteurs américains et européens, tout en confirmant largement l'analyse de la situation par ces deux auteurs, proposent néanmoins des remèdes moins forts, qui ne risquent pas de provoquer le décès du patient par un choc thérapeutique. Des programmes de recherche ambitieux ont eu lieu au cours des années 80 dans les institutions les plus prestigieuses [Scott Morton 95] et ces études convergent largement vers une vision commune, celle d'une entreprise fragmentée, en réseau, dynamique, en changement permanent, par opposition à l'entreprise statique, hyperorganisée et complètement modélisée des années 70.

Cette dernière a nécessité la mise en place d'une base de données globale, intégrant pratiquement tous les aspects de l'entreprise et nécessitant des investissements importants en matériel et en logiciel. Le succès du modèle a fait croire en sa pérennité, mais paradoxalement c'est la performance même de ce modèle qui a été à l'origine de sa remise en question.

En effet, la puissance des solutions informatiques mises en place après 1970 a rapidement mené à leur généralisation, engendrant de ce fait des marchés de masse, un accroissement spectaculaire des performances, associé à une chute tout aussi spectaculaire des prix. L'introduction de l'outil informatique s'est généralisée au niveau du poste de travail, envahissant progressivement la production, la conception de produits et la commercialisation de ces mêmes produits. Mais non seulement les vendeurs de produits et de services ont pu profiter de ce mouvement, mais aussi les clients (toute entreprise étant à la fois fournisseur et client). Les nouveaux moyens d'information ont progressivement transformé les clients passifs en sélectionneurs judicieux de fournisseurs, donnant la préférence à ceux qui le mieux pouvaient satisfaire leurs besoins spécifiques.

C'est ainsi que le client est devenu un acteur puissant et bien informé, engendrant un comportement nouveau de la part des entreprises, qui ont tout mis en œuvre pour assouplir leur production et pour varier leurs produits en s'adaptant dynamiquement aux besoins changeants du client. Les technologies de l'information ont favorisé ce mouvement, mais les structures organisationnelles en place l'ont freiné.

Cette évolution a fait naître des réflexions fondamentales sur les structures organisationnelles adaptées à l'entreprise en mouvement. Il est vite devenu clair que les modèles mis en place par une informatique monolithique étaient bien trop lourds pour réagir assez rapidement aux changements de l'environnement socio-économique. L'implémentation de modèles gigantesques, à peine compréhensibles, avec spécialisation fonctionnelle des intervenants, a engendré des circuits de travail complexes et longs. Les travaux circulent d'un expert à l'autre et chacun doit constater si oui ou non il y a une intervention à faire. Les temps de circulation et d'attente sont devenus démesurés par rapport aux durées des interventions réellement productrices de valeur. De plus, aucun de ces experts ne se sent responsable envers le client, mais uniquement envers son chef.

Il n'est pas étonnant que dans ces conditions certains aient pu proposer d'oublier complètement l'ancien système, de recommencer à zéro et de réinventer un nouveau modèle d'entreprise. Le BPR à la Hammer et Champy en fut le résultat.

Mais en réalité, le problème fondamental à résoudre est celui de trouver une structure d'entreprise adaptée au changement permanent. Toutes les théories récentes, toutes les solutions informatiques nouvelles ont pour but d'apporter un élément de solution à ce problème.

Et c'est en cela que consiste le renouvellement de paradigme actuellement en cours : nous passons d'une conception statique du monde, évoluant par sauts quantiques périodiques, à une conception dynamique, évoluant par des changements continuels. Le « Tout est Mouvement » de l'ancien philosophe grec Héraclite devient la trame sur laquelle se tisse la nouvelle entreprise. L'aptitude au changement devient un prérequis de base de l'entreprise dynamique et tout ce qui risque de freiner cette aptitude devra être examiné avec soin.

Parmi les facteurs d'inertie figurent les organisations fonctionnelles lourdes, la lenteur des mécanismes de restructuration interne, mais aussi les solutions informatiques dinosauresques, celles-là mêmes qui ont peu à peu déclenché cette avalanche de changements.

Le BPR consiste à mettre en place de nouveaux modes de restructuration dynamique et continuelle, permettant à l'entreprise de se métamorphoser rapidement en fonction des changements de son environnement.

En réinterprétant le BPR dans cette optique élargie, on doit se rendre compte qu'il ne disparaîtra pas de sitôt. Il changera peut-être d'étiquette, mais il ne disparaîtra plus, à moins que les changements ne cessent ; mais ne serait-ce pas un peu comme la mort ?

IV-J-3. Merise, un dépoussiérage nécessaire

Merise est un enfant de son temps, c'est-à-dire des années quatre-vingts. Il a puissamment contribué à concevoir les réalisations informatiques actuellement en place et avec la remise en cause de ces réalisations, l'outil qui a servi à les concevoir est lui aussi devenu suspect. On est tenté de le jeter avec les manuels de référence des matériels informatiques utilisés à l'époque.

Le problème, c'est qu'il n'y a rien pour le remplacer, et toutes les méthodes orientées objet proposées au fil des jours ne sont bien souvent que des méthodes de génie logiciel se préoccupant principalement des niveaux logique et physique, à tel point qu'on en arrive à oublier la richesse originelle de Merise.

En effet, Merise prenait en compte l'entreprise globale, bien au-delà de considérations informatiques ou technologiques. En explorant les méthodes proposées en BPR on est toujours frappé par une constatation : « que ça ressemble fortement aux idées de base de Merise ! » Et on en arrive à la conclusion que Merise, ce n'est peut-être pas aussi dépassé que certains voudraient bien nous le faire croire.

Le marteau du sculpteur et son burin peuvent servir à modeler des œuvres classiques, mais rien n'empêche l'artiste moderne de les utiliser pour réaliser des sculptures avant-gardistes. Ce n'est pas l'outil qui a changé, mais le regard du créateur sur la matière première. Pour Merise il en va de même. Ce qui doit changer, c'est le regard du concepteur sur l'entreprise. Ce qui doit changer, c'est la façon d'utiliser l'outil, c'est la pondération entre les différentes facettes de la méthode.

Tout le monde sait que, suivant une tendance très forte à l'époque, les concepteurs de Merise ont nettement mieux développé le point de vue des données que le point de vue des traitements. Ils ont privilégié la statique par rapport à la dynamique à tel point que certains réduisent Merise à la modélisation des données. Les temps ont changé ; le pendule est en train d'osciller dans la direction opposée et l'attention se porte désormais sur la partie dynamique du système. La question qu'on doit se poser maintenant est la suivante : « Comment les concepteurs de Merise auraient-ils développé la partie dynamique s'ils avaient été confrontés à la situation actuelle ? ».

Un autre aspect fondamental, et une grande originalité de la méthode, c'est sa référence à la théorie des systèmes. Bien que rapidement oubliée par la plupart des utilisateurs, qui préfèrent la sécurité des dessins et des modèles à la réflexion systémique, cette dernière semble jouer un rôle de plus en plus important dans les modèles d'entreprises modernes. L'entreprise-organisme tend à éclipser l'entreprise-machine [Gouillart 95]. Les incertitudes de l'entreprise fractale [Warnecke 93 et 95] prennent le dessus sur la clarté de l'entreprise complètement modélisée et transparente.

Par ailleurs, la théorie des systèmes elle-même a fortement progressé au cours des vingt dernières années, poussée en cela par les avancées spectaculaires des sciences de la vie [Maturana 87], mais aussi par l'ouverture progressive des sciences économiques et des sciences de gestion à cette théorie des systèmes [Bartoli 96]. Et de nouveau peut-on se demander comment ces nouvelles connaissances auraient été intégrées dans la méthode, si elle avait été développée aujourd'hui.

Ce qu'il faut donc, c'est un dépoussiérage, un polissage et une remise en valeur des fondements sains de Merise. Et tout d'abord, il faudra faire l'examen de tout ce qui est utilisable dans une optique de BPR.

IV-J-4. Les modèles Merise au service du BPR

L'approche systémique a amené Merise à étudier globalement des systèmes, en s'intéressant aux interactions du système avec son environnement. L'identification des sollicitations de l'entreprise par l'environnement est le point de départ de la description des processus, considérés comme la réaction de l'entreprise à un événement déclencheur externe. C'est ainsi que dès le départ Merise a préconisé une approche orientée processus, plutôt qu'une approche orientée fonctions ; pour cette raison, les modèles de description des processus (MCT) et des procédures (MOT) sont tout à fait adaptés à l'analyse préalable qui est à la base de tout projet BPR. L'objectif est le même dans l'analyse Merise que dans l'analyse BPR : comprendre les processus essentiels de l'entreprise.

Les méthodes BPR proposent généralement un mélange entre MCT et MOT (voir par exemple la « Business Activity Map » (BAM) et le « Relational Diagram » (RD) [Morris 93]).

IV-J-4-a. Les apports du MOT

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.

Image non disponible
Figure 19.1 : Répartition des durées productives

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.

Image non disponible
Figure 19.2 : Une procédure en cascade

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 ».

Image non disponible
Figure 19.3 : Un responsable gère la procédure

IV-J-4-b. Les apports du MCT

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.

Image non disponible
Figure 19.4 : Le BPR 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.

IV-J-5. Les mécanismes du BPR

Les préoccupations du BPR se situent à un niveau stratégique du système étudié. Bien que les modèles conceptuels Merise constituent un bon point d'entrée au BPR, ils ne suffisent pas pour soutenir les raisonnements qui se font à ce niveau.

La démarche du BPR est souvent présentée en trois phases successives :

  • la phase de positionnement ;
  • la phase de repositionnement ;
  • la phase de reconfiguration.

IV-J-5-a. La phase de positionnement

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.

IV-J-5-b. La phase de repositionnement

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.

IV-J-5-c. La phase de reconfiguration

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.

Image non disponible
Figure 19.5 : L'interaction entre le client et l'entreprise

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] :

Image non disponible
Figure 19.6 : Les phases du modèle d'interaction

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.

    Image non disponible
    Figure 19.7 : Une boucle d'interaction secondaire
  • 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.

IV-J-5-d. Les mécanismes d'adaptation

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].

IV-J-5-e. La démarche de l'alignement stratégique

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 :

Image non disponible
Figure 19.8 : Les quatre axes de l'alignement stratégique

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.

Image non disponible
Figure 19.9 : Les quatre groupes de travail de re-engineering

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.

IV-J-6. Les technologies de l'information au service du BPR

L'alignement stratégique est conditionné en grande partie par les opportunités technologiques du moment et par leur évolution future. Les technologies actuelles rendent possibles l'entreprise en réseau et sa restructuration rapide [Tapscott & Caston 94].

Il est indispensable de pouvoir interconnecter des systèmes d'information existants et autonomes, ce qui engendre un certain nombre de conséquences :

  • Les systèmes d'information doivent être ouverts, c'est-à-dire doivent être capables de communiquer avec d'autres systèmes indépendamment de l'infrastructure matérielle utilisée de part et d'autre.
  • Les solutions utilisées doivent se conformer à des standards, aussi bien au niveau de la technologie qu'au niveau des messages échangés (interfaces).
  • Les solutions doivent être conviviales et s'adapter au maximum aux besoins et aux modes de travail de l'utilisateur humain.

En appliquant ces principes à tous les niveaux (interentreprise, à l'intérieur de l'entreprise, au niveau du poste de travail), on est en mesure d'agréger, de séparer et de recombiner des systèmes existants, afin de répondre aux besoins de reconfiguration permanents résultant du BPR.

Ces dernières années ont vu apparaître plusieurs approches particulièrement importantes :

  • Internet et le commerce électronique ;
  • XML et l'échange standardisé de données ;
  • l'informatique coopérative ;
  • la gestion des flux de travaux.

IV-J-6-a. Internet et le commerce électronique

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.

IV-J-6-b. XML et l'échange standardisé de données

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.

Image non disponible
Figure 19.10 : Une communication universelle par XML

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.

IV-J-6-c. L'informatique coopérative (« groupware »)

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.

Image non disponible
Figure 19.11 : Modélisation d'une tâche coopérative

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).

IV-J-6-d. La gestion des flux de travaux (« workflow »)

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.

IV-J-7. Merise et le BPR : quelques conclusions

Nous avons vu que le BPR est une démarche qui est elle-même en train d'évoluer en fonction du développement des technologies et de l'environnement socio-économique. Après un BPR de première génération, visant à repositionner et à reconfigurer une entreprise déterminée, nous passons à une deuxième génération de BPR, visant à restructurer des agrégats d'entreprises, voire des secteurs économiques entiers.

Merise et le BPR se ressemblent beaucoup par leurs préoccupations et par leurs démarches. Loin d'être une approche dépassée par le progrès technique, Merise est tout à fait capable d'aborder les problèmes de modélisation de l'entreprise en réseau.

Tout comme le BPR doit évoluer, il en est de même de Merise. Au lieu d'éviter les niveaux d'abstraction les plus élevés, comme le font trop souvent les informaticiens et les méthodes qu'ils appliquent, Merise devrait au contraire s'enrichir pour tenir compte des besoins du niveau stratégique, tout en conservant l'originalité de ses racines systémiques.

Cela entraîne le développement de méthodes permettant de modéliser des hiérarchies de finalités. Il faudra aussi envisager d'étendre la modélisation des données par une modélisation plus générale de langages de métiers. Il faudrait trouver des moyens pour modéliser le comportement d'acteurs économiques, que ce soit l'utilisateur, le client, une organisation partenaire ou simplement un agent logiciel parcourant Internet. La coopération entre acteurs devrait pouvoir être exprimée, tout comme les mécanismes d'évolution des systèmes d'information.

Voilà un vaste programme de travail pour la grande communauté des « Merisiens ». Tous ceux qui se sentent concernés par ces développements devraient coopérer pour développer la vision d'un Merise pour le 21e siècle, Merise 21 !


précédentsommairesuivant
Le comble étant d'adresser par courrier les modélisations aux membres du groupe de validation en demandant en retour leur accord pour validation !

Vous avez aimé ce tutoriel ? Alors partagez-le en cliquant sur les boutons suivants : Viadeo Twitter Facebook Share on Google+   

  

Les sources présentées sur cette page sont libres de droits et vous pouvez les utiliser à votre convenance. Par contre, la page de présentation constitue une œuvre intellectuelle protégée par les droits d'auteur. Copyright © 2016 Dominique Nanci. Aucune reproduction, même partielle, ne peut être faite de ce site ni de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.