Deuxième Partie :
Etude conceptuelle et organisationnelle
I. Présentation de la méthode
d'analyse
A- La méthode MERISE
1. Historique :
Issue de l'analyse systémique, la méthode
MERISE est issue des travaux menés par Hubert Tardieu dans les
années 1970 et qui s'inséraient dans le cadre d'une
réflexion internationale, autour notamment du modèle relationnel
d'Edgar Frank Codd. Elle est devenue un projet, opérationnelle au
début des années 1980 à la demande du ministre de
l'industrie et surtout été utilisée en France et
principalement pour les projets d'envergure, notamment des grandes
administrations publiques ou privées.
Merise, méthode spécifiquement
française, a d'emblée connu la concurrence internationale des
méthodes anglo-saxonnes. Elle a ensuite cherché à
s'adapter aux évolutions rapides et des technologiques de l'informatique
avec MERISE/objet, puis MERISE/2 destinée à s'adapter au
client-serveur. Merise était un courant majeur des réflexions sur
une « Euro méthode » qui n'a pas réussi
à percer.
De l'aveu même d'un de ses fondateurs, le nom MERISE
vient de l'analogie faite entre le merisier `'qui ne peux porter de beaux
fruits que si on lui greffe une branche de cerisier : ainsi en va-t-il des
méthodes informatiques bien conçues, qui ne produisent de bons
résultats que si on greffe sur l'organisation réussit'' ;
même si beaucoup de gens ont voulu y avoir une acronyme comme par exemple
Méthode d'Etude et de Réalisation Informatique par les
Sous-ensembles ou pour les Systèmes d'Entreprises.
On pourra aussi consulter un historique de merise sur le site
web developpez.com.
Positionnement de la méthode.
La méthode Merise est une méthode d'analyse, de
conception et de réalisation de systèmes d'informations
informatisées.
En amont, elle se situait dans le prolongement naturel d'un
schéma directeur souvent conduit suivant la méthode RACINES,
très présente notamment dans le secteur public.
Les projets Merise étaient généralement
des projets de grande ampleur de refonte d'un existant complexe, dans un
environnement grand système. La méthode a aussi connu des
tentatives d'adaptation avec les Systèmes de Gestion des Bases de
Données relationnels, les différentes Interfaces Homme-Machine
(IHM), l'Orienté objet, le développement micro, les outils CASE,
la retro-ingénierie... mais qui n'ont pas connu le même
succès. La méthode est essentiellement française. Elle a
des équivalents à l'étranger en ce qui concerne les
modèles de données (avec des différences, par exemple les
cardinalités ne sont pas aussi détaillées dans les
méthodes anglo-saxonnes). En revanche la modélisation des
traitements est beaucoup plus complexe que dans les méthodes
anglo-saxonnes.
Sa mise en oeuvre peut paraître lourde. On consacre
beaucoup de temps à concevoir et à se pré- documenter
avant de commencer à coder, ce qui pouvait sembler nécessaire
à une époque où les moyens informatiques n'étaient
pas aussi diffusés qu'aujourd'hui. Ceci dit elle évite
l'écueil inverse du développement micro, qui souffre par le
manque de documentation, et où les erreurs sont finalement très
couteuses à réparer a postériori.
Même si les échanges et la consultation entre
concepteurs et utilisateurs sont formellement organisés, on a aussi
reproché à Merise d'utiliser un formalisme jugé complexe,
(surtout pour les modèles de données) qu'il faut d'abord
apprendre à manier, mais qui constitue ensuite un véritable
langage commun, puissant et rigoureux pour qui la maîtrise.
L'articulation très codifiée et bien balisée des
différentes étapes, avec un descriptif très précis
des résultats attendus est ce qui reste aujourd'hui de mieux connu et de
plus utilisé.
La méthode Merise est bien adaptée à
l'automatisation de tâches séquentielles de gestion pure. En
revanche, elle est mal adaptée aux environnements distribués
où de multiples applications externes à un domaine viennent
interagir avec l'application à modéliser ; de plus elle
n'est pas en mesure de modéliser les informations à
caractère sémantique (documents,...).
Méthode d'analyse et de conception
La méthode MERISE préconise d'analyser
séparément données et traitements, à chaque niveau.
On aura pris soin de vérifier la cohérence entre ces deux
analyses avant la validation et le passage au niveau suivant. La méthode
Merise propose une démarche articulée simultanément selon
trois axes pour hiérarchiser les préoccupations et les questions
auxquelles répondre lors de la conduite d'un projet :
Cycle de vie ; phase de conception, de
réalisation, de maintenance puis nouveau cycle de projet.
Cycle de décision : des grands
choix (Etude préalable), la définition de projet (étude
détaillée) jusqu'aux petites décisions des détails
de la réalisation et de la mise en oeuvre du système
d'information. Chaque étape est documentée et marquée par
une prise de décision.
Cycle d'abstraction : niveaux
conceptuels, logique / organisationnel et
physique /opérationnel (du plus abstrait au plus concret).
L'objectif du cycle d'abstraction est de prendre d'abord les grandes
décisions, métier pour les principales activités
(Conceptuel) sans rentrer dans le détail de questions d'ordre
organisationnel ou technique.
La méthode Merise, très analytique (attention
méthode systémique), distingue nettement les données et
les traitements, même si les interactions entre les deux sont profondes
et s'enrichissent mutuellement (validation des données par les
traitements et réciproquement).
Certains auteurs (Merise/Méga, puis Merise/2) ont
également apporté la notion complémentaire de
communication, vue au sens des messages échangés. Aujourd'hui,
avec les Systèmes de Gestion des Bases de Données Relationnelles,
l'objet, les notions de données et de traitements sont de plus en plus
imbriquées. « Courbe du soleil »
La littérature parle de « Courbe
soleil », établissant une analogie entre la démarche
Merise et le lever puis le coucher du soleil : de même, le projet
doit élaborer une analyse critique de l'existant (en partant du niveau
physique et en s'élevant jusqu'au conceptuel : démarche
bottom-up phase ascendante de la courbe), Puis décliner la solution
retenue (en partant du niveau conceptuel et revenant au niveau physique :
démarche top-down, phase descendante de la courbe).
Le recensement de l'existant est très
décrié en 2008, car il augmente la durée du projet. Sur ce
point, la démarche Merise est à l'opposé des
méthodes itératives du type RAD (Rapide Application Development),
ou de l'adoption systématique des best practices observées dans
d'autres entreprises du secteur, qui constituent une démarche typique
dans l'implémentation de progiciels.
Avec la pratique, vient un moment où le concepteur
peut se passer du modèle entités-associations et produire
directement des schémas relationnels corrects. Pourtant, continuer de
travailler à un niveau conceptuel plutôt qu'à un niveau
logique reste une tactique payante pour lui. Dans la mesure où les
données pourtant stockées sous une forme relationnelle, doivent
de nos jours être accédées par des applications
orientées objets. Le modèle conceptuel permet de faire le lien
entre d'une part la représentation objet des données et d'autres
de stockage relationnel des mêmes données.
Par exemple, on peut très bien imaginer
qu'un schéma entités-associations soit d'un côté
traduit en un schéma relationnel puis implémenté dans une
base de données oracle ; tandis qu'en parallèle elle est
traduite en diagramme de classe (Modèle Logique Objet), lui-même
implémenté dans un ensemble de classe java. Ces classes java
permettent en suite aux développeurs de construire des applications
clientes orientées objets et qui attaquent de manière
transparente les données de la base oracle. Il s'agit d'une solution de
passage entre la modélisation orientée objet (pertinente pour
développer des interfaces graphiques) et la modélisation
relationnelle (pertinente pour gérer les données).
Par ailleurs, la méthode MERISE est
certes typiquement française, mais en grande Bretagne la méthode
standard s'appelle SSADM (Structured Systems Analysis as Design Method) et
repose sur les mêmes principes. Les nord-américains quant à
eux utilisent ce qu'on appelle des diagrammes de flux, dont les principes sont
repris par la version 2 de Merise.
Aujourd'hui, ce sont les
modélisations objet et leurs unifications UML (unified modeling langage
autrement dit langage unifié de modélisation) qui se place
à la pointe de l'état de l'art. Malheureusement, UML n'est qu'un
ensemble de notations (d'ailleurs moins intuitives que celle des schémas
entités-associations). La connaissance de langage ne permet donc pas au
concepteur de faire l'économie d'une méthodologie de conception.
Voila pourquoi il n'est pas anachronique de rééditer en 2005 un
document sur des méthodes qui auront bientôt 30 ans ;-).
| 
