Merise est une méthode d'analyse pour les projets informatiques
Merise est une méthode de conception de systèmes d'information de gestion.
Merise ne se limite pas à l'aspect informatique. Cette méthode a eu comme objectif premier de jeter un pont entre les besoins des utilisateurs et les solutions des informaticiens. Certes sa finalité est quand même de faciliter la conception des projets informatiques en permettant d'analyser et de formaliser très tôt les « besoins » des utilisateurs.
Qu'est qu'un système d'information La définition du système d'information est issue de la théorie des systèmes ou systémique. Bien que fortement « théorisante », elle fournit un éclairage assez solide sur le terrain (lorsqu'on ne voit plus de quoi on parle…)
Une « organisation » (entreprise, administration, collectivité, tout groupe social organisé exerçant une activité) peut être modélisé comme comportant trois sous systèmes :

• le système de pilotage (celui qui réfléchit, décide, oriente)
• le système opérant (celui qui produit, transforme, agit)
• le système d'information

Le système d'information est la représentation de l'activité du système opérant ,construite par et pour le système de pilotage pour en faciliter le fonctionnement. Le système d'information a deux grandes fonctions :

• recueillir, mémoriser et diffuser les informations
• assurer le traitement de ces informations

On reconnaît ici la fameuse dichotomie Données / Traitements.
Le système d'information, dans son principe, n'est pas né avec l'informatique ! Les pharaons disposaient de systèmes d'informations ; seuls les moyens différaient. C'est la capacité de l'outil informatique à amplifier la gestion des données et des traitements qui a conduit à distinguer deux niveaux de système d'information :
Une « organisation » (entreprise, administration, collectivité, tout groupe social organisé exerçant une activité) peut être modélisé comme comportant trois sous systèmes :

• le système d'information organisationnel (SIO), la partie visible, basée essentiellement sur des ressources humaines, de l'activité organisée
• le système d'information informatisé (SII) correspondant au contenu informatisé du SI (logiciel, base de données)

Ainsi, un projet informatique a pour objectif de construire une application informatique (logiciel et base de données), support d'un système d'information informatisé, inclus dans un système d'information organisationnel. Merise ne fait que rappeler que l'on ne peut pas construire un SII sans comprendre au préalable le SIO dans lequel on l'implante ! J'utilise parfois la métaphore de la « prothèse » que l'on greffe au sein de l'organisation pour amplifier ses fonctions, qui doit être adaptée à son contexte, ne pas « blesser » le récepteur sous peine de rejet…
Qu'est ce qu'une méthode Une méthode comporte trois axes indispensables pour obtenir ce label « méthode » :

• une démarche, ensemble coordonné d'étapes, de phases et de tâches indiquant le chemin à suivre [Hodos, le chemin en grec, serait une des étymologies de méthode] pour conduire un projet, ici, la conception d'un SI,
• des raisonnements et des techniques nécessaires à la construction de l'objet projeté, traduits ici par des modélisations,
• des moyens de mise en œuvre, en l'occurrence une organisation de projet et des outils.

Seule la réunion de ces trois dimensions permet une utilisation opérationnelle. Dès le début, Merise s'est voulu une méthode. Avec un effet induit : dès que l'un des axes est remis en cause, l'ensemble en pâti…C'est en effet la lourdeur de la démarche, dénoncée dans les années 90, qui a « plombé » Merise.

Nota : On remarquera qu'UML, en se positionnant sur le deuxième axe, ne peut être une méthode tant que l'on ne lui adjoint pas une démarche et des moyens.
Pour conclure, Merise est donc volontairement une méthode pour la conception de systèmes d'information, en vue de leur informatisation.

Début des années 70
Les bases de données commencent se développer. Aux Etats-Unis, Codd (70-72) propose le formalisme relationnel. En France,

• la recherche, essentiellement universitaire, est très active sur ce domaine,
• les chercheurs et les professionnels « éclairés » se rencontrent dans le cadre du Groupe Bases de données de l'AFCET (société savante qui jouera un rôle important pour la diffusion des connaissances, dont Merise)
• Hubert Tardieu, dans le cadre du Centre d'Etude Technique de l'Equipement d'Aix en Provence, développe un prototype de SGBD relationnel et réfléchit à une approche alternative. Il publie « Modèle individuel pour un base de données » H. Tardieu, C. Deheneffe, JL Hainaut (Namur – mai 74), qui préfigure le modèle entité-relation.

La recherche sous contrat (74 – 81)
Courant 74, le CETE d'Aix en Provence et l'Université d'Aix-Marseille s'associent pour présenter un projet de recherche auprès de l'I(N)RIA intitulé : « Méthode, modèles et outils pour la conception de la base de données d'un système d'information ».
L'équipe, placée sous la direction scientifique du Prof J.L. Le Moigne (qui vient d'inventer en 73 la notion de système d'information), est pilotée par Hubert Tardieu. Elle est composée au départ d'Henri Heckenroth et de Dominique Nanci. Au cours du projet, d'autres personnes rejoindront l'équipe, plus ou moins longtemps, dont : Daniel Pascot, Bernard Espinasse, Mokrane Bouzeghoub.
Dans ce contexte, s'élaborent progressivement :

• la modélisation conceptuelle des données (formalisme individu – relation qui deviendra ensuite entité – relation )
• la confrontation par les vues externes
• la transformation en modélisation logique puis la transformation en bases de données (Codasyl et relationnel)
• des prototypes d'outils d'aide à la conception
• plus tard, la modélisation des traitements selon ses différents niveaux(par adaptation des réseaux de Petri au contexte de la gestion)

Régulièrement, des rapports de recherche sont remis à l'I(N)RIA, où le référent est Arnold Rochfeld, jalonnant ainsi les principales étapes de construction.

Parallèlement, l'équipe participe à de nombreux groupes de travaux (dont l'AFCET) et à des congrès scientifiques pour diffuser la modélisation conceptuelle entité-relation. Des sociétés de service s'intéressent au travaux (Sema avec R. Coletti, Gamma avec Ph Duché, CGI avec G. Vahee).

La première publication internationale s'inscrit dans le cadre de l'IFIP. (janv. 76)
 « Conceptual model as a data base design tool » P. Moulin, J. Randon, S. Savoyski, S Spaccapietra, H. Tardieu, M. Teboul. Ces personnes constituaient le groupe Base de données de l'AFCET. L'AFCET étant le représentant français de l'IFIP, Tardieu avait usé de ce moyen pour obtenir un droit d'entrée dans un congrès international (où l'accès à de nouveaux venus est toujours très verrouillé). Les personnes sont citées par ordre alphabétique mais l'article avait été entièrement rédigé par H. Tardieu et son équipe…. Voilà comment Moulin et Teboul se retrouvent propulsés à l'origine de Merise (par l'auteur du mémo à l'origine de ma réaction)

En octobre 76, Chen publie dans la revue de l'ACM« The Entity-Relationship model, toward a unified view of data » où il présente son formalisme, très proche du formalisme de Tardieu ; Cette publication américaine lui donne un statut (évidemment) international. Le formalisme de Tardieu devient Entité – Relation.

L'équipe de recherche « aixoise » continue à jalonner ses travaux de publications et communications pour promouvoir les principes de sa méthode. Un premier ouvrage « Conception d'un système d'information – Construction de la base de données » paraît en 79 aux Editions d'Organisation, écrit par H. Tardieu, D. Nanci , D. Pascot . Il expose pour la première fois au « grand public » la conception d'une base de données avec la notion de MCD Entité-Relation, puis MLD et génération de base de données, ainsi que la nécessité d'outils.

Le projet Merise (77-81)
Dès 77, la Mission informatique du Ministère de l'Industrie (on est encore dans une volonté importante de l'Etat pour une politique informatique française) souhaite établir une méthode nationale (unifiée ?) dans le domaine de la conception des systèmes d'information. On constitue un groupe de travail qui réunit l'équipe de recherche« aixoise » et des représentants des principales sociétés de services avec comme objectif de : >

• intégrer les travaux de recherche proposés par l'équipe de H. Tardieu,
• mettre au point une démarche et des moyens de mise en œuvre, issus de l'expérience pratique des SSII
• être le vecteur de la diffusion de la synthèse méthodologique ainsi construite.

Merise voit officiellement le jour en 79, sous la forme d'un premier fascicule publié par Ministère de l'Industrie: «  Méthode de définition d'un système d'information ».
Le nom de Merise a été trouvé comme la métaphore du merisier qui doit être greffé pour porter des fruits. En effet, dans l'introduction du premier fascicule, il est écrit : « Merise n'est pas une pas une méthode, mais un tronc commun méthodologique sur lequel …. ». En effet, les différentes SSII veulent pouvoir ultérieurement apporter leur valeur ajoutée en personnalisant cette méthode. Le vers est dans le fruit. Quinze ans après, on observera des méthodes Merise, parfois avec des écarts notables (donnant naissance à des querelles dont seuls les « gaulois » ont le secret…). Par ailleurs, quasiment aucune structure (tel l'OMG avec UML) ne veillera au respect d'une certaine « normalisation » de Merise ; le merisier est redevenu un « sauvageon » ; plus aucun groupe pour promouvoir cette méthode au niveau international face au lobbying d'autres approches.
Le projet Merise se poursuit donc jusqu'en début 81 avec la publication de plusieurs documents de référence sur la méthode Merise. Le projet est alors interrompu suite au changement politique. Une tentative de bilan aura lieu en 84, mais il se heurtera à des conflits d'intérêt entre les grandes SSII.
Entre-temps, l'Administration consacre Merise comme la méthode de référence pour tous ses projets de conception de SI, assurant ainsi sa pérennité et son enracinement.

L'essor de Merise (81- 85)
A partir de 81, certaines grandes SSII qui avaient accompagné Merise, dont SEMA, CGI, GAMMA [devenu depuis MEGA= MEriseGAmma], entament la diffusion de la méthode auprès des grandes entreprises et de l'Administration.
En 83, est publié le premier ouvrage sur Merise, ouvrage qui restera la référence.
« La méthode Merise – Tome I :Principes et outils »
H. Tardieu, A. Rochfeld, R. Coletti,

qui sera suivi en 85 par :
« La méthode Merise – Tome II : Démarches et pratiques »
H. Tardieu, A. Rochfeld, R. Coletti, G. Panet, G. Vahee

L'expansion de Merise (85-95)
Dès lors, Merise connaît un engouement. Toutes les SSII font désormais du Merise (avec des résultats plus ou moins probants…). De nombreux ouvrages paraissent. Merise est désormais enseigné dans les formations universitaires. Des outils apparaissent, certains issus des prototypes conçus lors de la recherche. La fin des années 80 dénombrera plus de 15 outils français sur Merise. Quasiment toute grande SSII propose le sien. Certains sont encore sur le marché.
  L'AFCET constitue un groupe de travail sur Merise dans lequel se retrouvent les promoteurs-défenseurs de cette méthode. Ils mettent en commun leurs expériences et améliorent progressivement Merise tant sur les modélisations que sur la démarche. De nombreuses publications et communications, associées avec le monde universitaire, jalonnent cette période et appuient les idées de la méthode Merise.
Cette promotion se traduit également par la participation, en 89-90, de représentants français (la plupart issus du groupe AFCET) au projet EuroMethod (l'équivalent du projet initial Merise au niveau européen). Comme on aurait pu s'en douter, les antagonismes nationaux attisés par des enjeux politiques, stérilisèrent complètement ce projet. Adieu donc à une méthode européenne et à ses conséquences au niveau de l'industrie du logiciel, du moins da sa partie intellectuelle (au grand bonheur des américains… ?).
A partir de 90 Merise est devenu une figure imposée dans le cursus de formation de tout informaticien, du moins sur la partie de modélisation, plus particulièrement des données.
En 91, l'AFCET organise un congrès « Autour et alentour de Merise » qui réunira plus de 1000 personnes pendant 3 jours avec un grand nombre de communications. Ce congrès marque, à mon avis, l'apogée de Merise. C'est à cette occasion que sont présentées un certains nombre d'évolutions qui vont conduire à Merise / 2 (ou deuxième génération)
L'émergence de cette deuxième génération se concrétise par deux ouvrages :
«  Merise / 2 : Modèles et techniques Merise avancées » G. Panet ; R. Letouche (94)
« Ingénierie des systèmes d'information : Merise deuxième génération » D. Nanci, B. Espinasse (94)

La concurrence et la remise en cause (95 – 2000)
Deux courants viennent contester Merise : le RAD et l'approche objet.
Il est indéniable que la démarche de Merise initialement proposée, enrichie(ou alourdie…) par les SSII (dont certaines y ont vu un moyen de s'incruster chez le client…), appliquée dogmatiquement (par ceux qui la maîtrisait le moins…) a conduit à une lourdeur certaine.
L'émergence des démarches rapides puis agiles, en opposition aux démarches traditionnelles, remet vivement en cause Merise (hélas sans préciser qu'il ne s'agissait que de la démarche…, on jetait le bébé avec l'eau du bain !). Le succès de ces démarche s'explique par un changement radical des conditions économiques et la nature des projets (fin des grands projets).
Le développement des langages objets et des méthodes associées bouleverse la conception du logiciel. Il faut admettre que Merise, méthode de conception de SI, contribuait plus à la partie SIO que SII et laissait les informaticiens sans réponse au niveau de la conception du logiciel (MLT, MPT). Ces méthodes et ces langages comblaient ce vide ; en particulier pour les développeurs.
Dans le camp merisien (déserté par ceux qui l'encensait, en particulier au niveau des médias…), deux réactions se distinguent :

• une proposition d'intégration – fusion de l'approche objet dans les modélisations. Merise-Objet ou Merise 3,
• une proposition de cohabitation en complémentarité (remplacer toute la partie Traitement du SII par l'approche objet)

Pour de nombreuses personnes, Merise est mort (titre de première page d'un grand hebdomadaire professionnel en 97).
Toutefois, les modélisations de Merise continuent à avoir leur place dans les programmes de formation scolaires et universitaires.
Les outils (du moins ceux qui restent) sont de plus en plus performants, conviviaux et professionnels.

Un repositionnement possible ? (2000 ?)
UML a unifié les modélisations objet concurrentes et s'est imposé comme modélisation pour la conception de logiciel orienté objet. Les bases de données restent fortement relationnelles. La modélisation des processus métiers (BPM) s'affirme comme indispensable dans la conception des systèmes d'information. Par ailleurs, la conception des bases de données devient de plus en plus « indépendante » de la conception du logiciel.
Aujourd'hui trois pôles semblent se distinguer dans la conception de systèmes d'information (qui ne se réduit évidemment pas à la conception du logiciel !…)

• la conception des bases de données, où la séquence MCD ? MLD ? base reste toujours en bonne place,
• la conception du logiciel dans des environnements objets où UML et les méthodes associés remplissent incontestablement et efficacement leur tâche,
• la modélisation des processus métiers, indispensable pour la compréhension du fonctionnement de l'entreprise et pour l'interconnexion des applications.

Si l'on se réfère à schéma bien connu, on retrouvera l'articulation suivante :

D'ailleurs, dans ma pratique, je déduis très facilement les cas d'utilisation d'une « vrai » modélisation MCT ou MOT métier (et non pas de MCT/MOT représentant un fonctionnement informatique…). Les opérations ou les tâches à informatiser déterminent « naturellement » les cas d'utilisation du futur système projeté ; sinon, on se demande d'où viennent ces cas d'utilisation (hormis d'un interview des utilisateurs sur leurs besoins et l'on retrouve intact le questionnement initial de Merise : comment mieux appréhender et exprimer les besoins des utilisateurs…).
Maintenant, le Merise monolithique est certainement défunt (et c'est par certains aspects excessifs, une bonne chose..). Mais son héritage reste très important et bénéfique, en particulier au niveau des modélisations et de l'approche générale SIO/SII ; il serait stupide de le rejeter (il est vrai que notre époque est propice aux intégrismes…).
Et si le merisier avait laissé des noyaux qui ne demandent à leur tour qu'à germer et être supports de nouvelles greffes ? [on greffe bien des merisiers pour porter des mirabelles…]. Faisons confiance à la nouvelle génération de « jardiniers ».

La méthode Merise est issue d'une initiative de la Mission informatique du Ministère de l'Industrie qui, de 1977à 1980, réunit dans un groupe de projet des chercheurs et des praticiens des SSII pour élaborer une méthode unifiée pour la conception de systèmes d'information, avec pour premier objectif de mettre cette méthode en œuvre dans les projets de l'Administration et d'inciter les grandes entreprises à y adhérer.
Ce groupe :

• reprend les travaux de recherche de l'équipe d'Hubert Tardieu développés depuis 1974 et qui proposaient un ensemble de modélisations pour la conception d'un système d'information (MCD/MOD/MLD/MPT, DF/MCT/MOT/MLT/MPT), ainsi que des prototypes d'outils,
• élabore une démarche de mise en œuvre issue de la pratique des SSI (Etude préalable, Etude détaillée, Etude Technique, Réalisation, …)
• propose une cadre d'organisation et de conduite de projet (maîtrise d'ouvrage / maîtrise d'œuvre, principaux rôles)
• définit les fonctions des outils associés (interface graphique, référentiel, règles et transformations, …)

Les travaux se concrétisent de 1979 à 1981 par des publications de fascicules du Ministère.
La parution en 1983 de l'ouvrage
« La méthode Merise – Tome I :Principes et outils »
H. Tardieu, A. Rochfeld, R. Coletti,
marque la diffusion publique de la méthode Merise ainsi que le début de son expansion.

Données et traitements sont indissociablement liées dans un SI. Les données ne vivent que par les traitements, les traitements ne fonctionnent qu'avec des données. C'est le pile et le face de la même pièce.
Par contre, de natures différentes (les données expriment la statique, les traitements expriment la dynamique), ces deux facettes d'un même système d'information sont analysées séparément, chacune avec des raisonnements spécifiques. (c'est l'analyse qui est séparée, et non Données et Traitements). On retrouve d'ailleurs cette dichotomie dans l'approche objet.
En conséquence, il est hâtif de dire « si les traitements doivent changer ,les données ne sont pas impactées et inversement ». Tout au plus, on peut dire que la manière de construire les données n'est pas dictées par les traitements qui les utilisent, et inversement. Cette analyse séparée, avec des vues différentes, vise à apporter le plus d'autonomie donc d'évolutivité.
Les niveaux d'abstraction
Ces niveaux d'abstraction sont un artifice pour faciliter l'analyse, une bonne pratique. Cette dernière suggère d'aborder d'abord le « Quoi » et le « Pourquoi », avant de prendre en compte « Qui », « Où », « Comment » et « Quand », « Quels moyens » . [Cette recommandation fort ancienne est préconisée par les rhétoriciens latins, : Quis quid, ubi, quibus auxiliis, cur, quomodo, quando,… et a récemment été reprise par un centurion dans Astérix].
Ces niveaux (préconisés à l'époque par l'ANSI devenu depuis l'ISO ) sont au nombre de quatre et se conjuguent avec les deux niveaux de SI.
Pour le Système d'Information Organisationnel (SIO)

• niveau Conceptuel ? Quoi, Pourquoi
• niveau Organisationnel ? Qui, Où, Comment, Quand

Pour le Système d'Information Informatisé (SII)

• niveau Logique ? avec Quel moyens logiciel (général)
• niveau Physique ? avec quelle technique concrète de réalisation.

Si l'on croise ces quatre niveaux avec le deux facettes (données / traitements), on obtient le tableau de positionnement des différentes modélisations :

Bien évidemment, ces différentes modélisations n'ont pas toutes la même importance, et n'ont pas eu le même succès.

Un processus est un ensemble structuré d'événements, d'activités et de résultats qui concourrent à un même but. Il représente généralement un ensemble d'activités de l'entreprise dont les événements initiaux et les résultats finaux déterminent une situation stable du domaine.
Le processus s'utilise au niveau d'un MCT macroscopique (ou macro-MCT).

Une opération est un ensemble d'activités déclenché par la survenance d'un événément et produisant en retour des résultats. On regroupe dans une même opération l'ensemble des activités que le domaine peut effectuer sans autre information extérieure.
La segmentation en plusieurs opérations ne se justifie que si l'on attend des informations complémentaires en provenance d'événements nécessaires à la poursuite des activités. Les activités élémentaires constituant l'opération peuvent être conditionnelles.
On ne tient pas compte de leur organisation.
L'opération s'utilise au niveau d'un MCT standard.

L'opération élémentaire représente un ensemble d'activités "homogène" en terme de finalités; cette homogénéité peut être évaluée de différentes façons (nature de l'activité, rupture conditionnelle, données utilisées, ..) .
L'opération s'utilise au niveau d'un MCT détaillé ou analytique (MCTA).

Phase (MOT) :
Une phase est un ensemble d'activités
- consécutives
- réalisées dans la même période de temps
- dans le même poste (ou unité organisationnelle)
L'opération s'utilise au niveau d'un MOT macroscopique (ou macro-MOT).

Tâche (MOT):
Une tâche est un ensemble d'activités
- homogènes en terme de finalité
- réalisées dans un même poste
- d'un même degré d'automatisation (manuel, conversationnel, automatique)
- d'un même délai de réponse (immédiat, différé)
L'opération s'utilise au niveau d'un MOT standard.

Les modèles de données et de traitements sont déclinés selon des niveaux d'abstraction :

• Le niveau conceptuel (MCD, MCT) formalise les activités (que fait-on, pourquoi le fait-on) sans préoccupation de l'organisation (qui le fait, où, quand, avec quelles ressources humaines, informatique, données).
• Le niveau organisationnel (MOD, MOT)formalise les activités en prenant en compte l'organisation
• Le niveau logique (MLD, MLT) formalise fonctionnement du logiciel.
• Le niveau physique (MPD, MPT) est le niveau le plus proche de l'implémentation.

Les niveaux d'abstraction se conjuguent avec le degré de détail.
Le degré de détail (de global à détaillé) exprime la "granularité" de l'activité modélisée (généralement par un rectangle) qui peut être composée d'activités élémentaires.
Le mécanisme de décomposition (ou "refinement") permet de passer d'une activité "macroscopique" à un ensemble d'activités plus détaillées et formalisées, un peu comme un effet de zoom bien connu dans les méthodes d'analyse structurées anglo-américaines.
La décomposition peut se faire à niveau d'abstraction constant, par exemple entre MCT et MCTA. Elle peut se faire également en changeant de niveau, par exemple du MCT au MOT. On peut avoir également un mécanisme de recomposition.