Le document présente la méthode Merise pour la conception et le développement de systèmes d'information, en soulignant l'importance de l'analyse des besoins et de la rédaction d'un cahier des charges. Il décrit les différentes phases de création d'un système, comprenant l'analyse des besoins, la modélisation des données et des traitements, ainsi que les types de spécifications. Enfin, il aborde le modèle acteur-flux pour illustrer les échanges d'informations entre les différents acteurs d'un système.

1. Conception des Systèmes
Informatiques
LA METHODE MERISE
SUPPORT DE COURS -1
ELALLAOUI YOUSSEF
1

2. Système d'Information (S.I)
Le SI est composé des moyens (humains et techniques) nécessaires au
stockage et au traitement de l'information d'une organisation.
système opérant
2
système de pilotage
Un sous-système qui se préoccupe de recevoir des informations de l'intérieur ou de
l'extérieur de l'organisation de les traiter puis de les retransmettre vers l'intérieur ou
l'extérieur.
un système d'information automatisé (Système informatique) est un système
d'information qui fait intervenir des moyens automatiques de traitement notamment
des ordinateurs.

3. Les fonctions du système d’information
1. Recueillir l’information (saisie)
2. Mémoriser l’information (stockage dans des fichiers ou bases de données)
3. Exploiter l’information (traitement)
1. Consulter
2. Organiser
3. Mettre à jour
4. Produire de nouvelles informations par des calculs
4. Diffuser l’information (édition)
3

4. Analyse de besoins et cahier
de charges
 L'analyse des besoins: processus visant à établir
quelles fonctionnalités le systèmedoit fournir, et les
contraintesauxquelles il sera soumis.
 Uncahierdescharges: viseàdéfinir exhaustivement les
« spécifications de base » d'un produit ou d'un service à
réaliser. C'est le document sorti de l'analyse des besoins.
4

5. Analyse de besoins et cahier de
charges- Objectifs
 Comprendre la nature exacte du problème, par
l'analyste et par le client
 Fournir un document compréhensible par le client et les
concepteurs du système, ce qui fournira une sorte de
fondementdu contrat.
 Définir la base pour la validation des étapes ultérieures
(A-t'onconçu cequi a étédemandé ?)
 Préciser lescontraintesde réalisation
 Réduire les coûts de développement du système. Eviter l'oubli,
les allers-retours dans le cycle de développement.
5

6. Typologies des besoins
 Besoins fonctionnels (exigences fonctionnelles) : ce
que l'utilisateurattend en termes de fonctionnalités.
 Exemple : dans un DAB (distributeur automatique de
billets), on aura besoin d'implémenter la vérification de la
validité de la carte bleue.
 Besoins non fonctionnels (spécifications
techniques): conformité aux standards, contraintes sous
les quelles le systèmedoit resteropérationnel.
 Exemple : dans un DAB, le distributeur doit répondre
au plus 2 secondes après insertion de la carte, ou
encore, contrainte du système d'exploitation (on
demande un travail sous UNIX].
6

7. L'analyse des besoins en pratique
 Les différents acteurs lors de cetteétape sont l'analyste, le
client, et l'utilisateurfinal.
 Procédé
 Séries de questions posées auxclients et aux utilisateurs
 Eventuellement, les documents fournis par leclient
 Analyse de la tâche
 Problèmes rencontrés
 comment organiseret structurer les informationsobtenues ?
 Comment résoudre les contradictions pouvant existerentre les
différents interlocuteurs ?

8. Spécifications: types
 II existedifférents typesde spécifications,
 Spécification informelle : Généralement rédigée en langage naturel,
ces caractéristiques :
 pas de structuresprécisesdedocument
 Pas d'outils
 Lisibles par l'utilisateurfinal
 Spécification semi-fonctionnelle : Ce type est lié aux
méthodologies employées, à base de graphiques et utilisant des
modèles.
 Spécification formelle : Elle est fondée sur des langages
de spécification.

9. Spécifications: cahier des charges
II esten règlegénéralecomposédes éléments suivants :
• introduction
• Descriptiongénérale
• Environnement / contexte du système
• Modèleconceptuel: regrouper l'ensemble des fonctionnalités ...
• Caractéristiques des utilisateurs
• Besoins fonctionnels
• Spécification des structuresde données: Spécifie les entités les plus
importantesdu système, ainsi que les associationsqui les relient.
• Besoinsen performance (non fonctionnels)
• Contraintes de développement
• Références (bibliographie, source d'obtention...)
• Index
• Annexes (description, toutcequi peut êtrevulgarisé par le lecteur...)

10. 1. Historique
2. Merise : une méthodedeconceptionetdedéveloppement

11. Méthodes d'analyse et de conception
 Une méthode d'analyse et de conception permet la
formalisationdes étapes préliminairesdu développement
d'un systèmeafin de rendre ce développement plus fidèle
aux besoins du client.
 La phased'analyse permetde lister les résultatsattendus,
en termes de fonctionnalités, de performance, de
robustesse, de maintenance, de sécurité, d'extensibilité,
etc.
 La phase de conception permet de décrire de manière
non ambiguë, le plus souvent en utilisant un langage de
modélisation, le fonctionnement futur du système,
afin d'en faciliter la réalisation.

12. Historique
 Années 70 : Méthodesorientéesvers les fonctionnalitésdes systèmes.
 Années 80 : Méthodes systémiques, modélisation des données et
modélisationdes traitementsde manièreséparée. (MERISE comme
exemple)
 1990-1995 : Emergence des méthodes objet
 Analyseret modéliserun systèmeen considérantde manière unifiée les
données et les traitements : Booch, Classe-Relation, Fusion, HOOD,
OMT, OOA, OOD, OOM, OOSE ... Aucune de ces méthodes ne s'est
réellement imposée.
 1995-1997 : Unificationet normalisationdes méthodesvers une sortede
standard appelé UML

13. Merise : une méthode de conception et de
développement
La méthode MERISE date de 1978-1979, et fait suite à une
consultation nationale lancée en 1977 par le ministère de
l'Industrie français dans le but de choisir des sociétés de
conseil en informatique afin de définir une méthode de
conception de systèmes d'information. Les deux principales
sociétés ayant mis au point cette méthode sont le CTI
(Centre Technique d'Informatique) chargé de gérer le projet,
et le CETE (Centre d'Etudes Techniques de l'Equipement).
MERISE: Méthode d'Étude et de Réalisation Informatique
par les Sous-Ensembles ou pour les Systèmes d'Entreprises

14. MERISE est une méthode d'analyse, de conception et de réalisation de systèmes
d'informations. La méthode MERISE est basée sur la séparation des données et
des traitements à effectuer en plusieurs modèles conceptuels et physiques.
Merise : une méthode de conception et de
développement
⚫ A partirde l'existantde l'organisation (entreprise, société, association,
…) on va procéder à l'étude de son système d'information qui va être
successivement modélisé (utilisation des méthodes) puis formalisé
(miseen formeen fonctionde normesou de standards) de telle façon à
obtenir un système informatique représentatif de la réalité du système
d'information de l'organisation étudiée.

15. Merise : une méthode de conception et de
développement - Caractéristiques
 Meriseest une méthodeou démarche de construction de
systèmed'information. Les points fortsde merise :
 Elle permetde recenser la totalitédes informationsdans
l'organisation.
 Elle permet une description instantanéeet aussi
perspective.
 Ellese base sur unedescription objectivedes informations
permettantde confrontes les pointsdevuedes acteurs.
 Elle utilise un formalisme spécifique à base de modèle.
 Ellese base sur la séparationdes traitementsetdes
données.

16. Les deux approches de MERISE
Approches par niveaux
Vise à concevoir le système d'information de chaque domaine de l'organisation
suivant une logique de modélisation des trois niveaux : conceptuelle,
logique ou organisationnelleet le niveau physique ou opérationnel.
Niveaux Préoccupation Données Traitement
Conceptuel Quoi faire ? MCD MCT
Logique Qui fait quoi ? Quand et ou ? MLD MOT
Physique Comment et avec quelle moyenne ? MPD MPT
•MCD = Modèle Conceptuel de Données
•MLD = Modèle Logique de Données
•MPD = Modèle Physique de Données

17. Les deux approches de MERISE
Approches par étapes
 schémadirecteur: étapede planification de développement de système d'information
(SI),
 le S.I est étudié d'une manière globaleet décomposeren domaine.
 Il s'agit en suite d'affecter les finalités aux besoinscorrespondants,
 aux niveaux informatiques enétablie un plan prévoyant l'évolutionde l’étudeainsi que le besoin
matériel et logiciel.
 étude préalable: reprendre domaine pardomaineou ledomaine de choix, et les étudier
de manière plus approfondie. On distincte 3 étapes :
 Etude de l'existant.
 Procédure ou scénario future.
 Evaluation (le coût).
 étude détaille: réalisée pour chaque domaine à partir des solutions choisies lors de
l'étude préalable. Le domaine peut être découpé en projet et chaque projet peut être
découpé en applications, un cahierde charge utilisateursera rédigéparapplications.
 étude technique: Dans cette étape on étudie le MPD et le MPT.
 Réalisation: la programmation, les tests et la mise en ouvre (former la personne qui
dirige le programme).
 Maintenance: modification des programmes pour faire vivre les applications et les
mettreà niveau jusqu'à leur mort

18. Modèle acteur-flux
Graphe de flux de données

19. Modèle acteur-flux
Le modèle acteur-flux nommé aussi le Modèle
Conceptuel de Communication (MCC), représente les
systèmes fonctionnels externes et internes à l'entreprise.
A chaque fonctioncorrespond un objectif de l'entreprise.

20. Composants d'un MCC- Flux
Un flux est un lot d'informations transmis entre deux
acteurs. C'est un échange d'informations entre un
acteurémetteuret un acteurrécepteur.
Code Flux Flux
F1 Contact fournisseur pour devis
F2 Établissement de fiche de Commande
F3 Emprunt des documents
F4 Retour des documents
F5 Validation des livraisons

21. Composants d'un MCC- Acteur
 un acteur est toutcequi peutémettreou recevoirdes flux.
 uneentité, humaineou matérielle, intervenantdans le système
d'information.
 Exemple : un domaine, un service, une personne, un rôle jouépar une
personne. (Dépend du degréde finesse de l'analyse).
 deux catégories, internes et externes, selon leurappartenance ou non
à l'entreprise.
 Acteur externe : entité externe à l'organisation ou au domaine étudié.
 Exemple : un client, la banquede l'entreprise...
 Acteur interne : appartient à l'organisation ou au domaine étudié.
 Exemple : leservice production, commercial...
 Lechoix interne/externeest fondamental : il décrit la frontièredu
domained'études. C'està faire toutau débutd'uneanalyse.

22. Composants d'un MCC- Acteur
Les acteurs du système « bibliothèque »
Code acteur Acteur Type (interne ou externe)
A1 Responsable de la bibliothèque
A2 Le service de catalogage
A3 Le fournisseur
A4 Le service de la comptabilité
A5 Les utilisateurs

23. Etapes de construction d'un MCC
 La première étape: isoler le système. Il s'agit donc de
définir le système et les acteurs externes avec lesquels
il échange des flux d'information.
 La secondeétape: consisteàdécouper l'organisation en
acteurs internes (ou domaines).
 La dernière étapeest l'analysedes flux d'information.

24. Matrice et graphe de flux
 Matricede flux : c'est un tableau qui décrit les flux
d'informationentre acteurs :
 les acteurs figurent en tête des lignes et des colonnes;
 un flux apparaît à l'intersectiond'une ligneetd'unecolonne.
Graphedes flux : c'est une représentationgraphiquede la
matrice des f lux.
Émetteur Récepteur Acteur 1 Acteur 2 Acteur 3
Acteur 1 Flux1
Acteur 2 Flux 2 Flux 4
Acteur 3 Flux 3

25. Code Flux Flux
F1 Contact fournisseur pour devis
F2 Établissement de fiche de
Commande
F3 Emprunt des documents
F4 Retour des documents
F5 Validation des livraisons
Code
acteur
Acteur
A1 Responsable de la
bibliothèque
A2 Le service de catalogage
A3 Le fournisseur
A4 Le service de la comptabilité
A5 Les utilisateurs
Exemple 1 : Gestion d’une bibliothèque
A1
A4
A2
A3
A5
F1
F2
F3
F4
F5
bibliothèque

26. Exemple 2 : Gestion des sinistres dans une société d'assurance
A l'arrivéed'unedéclarationde sinistre, on l'examine. Si ladéclaration est
recevable, on demande l'avis d'un expert, sinonon notifie le refusà l'assuré.
Au retour de l'expertise et après réception de la facture du garage, on calcule
le montant du remboursement et on envoie le chèqueau client.
•Déduire la matrice des flux

27. Exercice : Gestion des commandes des clients
Les commandesdes clientssont saisiesau niveau descomptoirs
d'accueils régionaux et sont transmises chaque soir au siège central de la
société.
 Tous les matins, le service magasin du siège traite les commandes
reçues: il édite pour chaque commande des bons deréquisition.
 Ces bons sont transmis aux magasiniers qui sortent les articles des
stocks, pointent manuellement les bons, puisapportent les articles
au service emballage, afin qu'ils soient conditionnés le jour même.
Dès le lendemain, le service emballage expédie les colisauxclients.
 En fin de semaine, le centre de traitement informatique du siège
édite les factures qui correspondentauxcommandesde la semaine.
 Dégager les acteurset leurs types
 Tracer le graphe de f lux