Le document traite de la relation entre la maîtrise d'ouvrage (MOA) et la maîtrise d'œuvre (MOE) dans la réussite des projets, en soulignant l'importance d'un cahier des charges bien défini. Il met en avant le modèle CMMI-ACQ comme un guide pour améliorer le processus d'acquisition, bien que son adoption soit limitée par sa complexité. Enfin, il recommande aux MOA de mettre en place des processus d'ingénierie des exigences pour mieux définir et partager leurs besoins avec les fournisseurs.

1. La MOA, l’IE et la MOE
Gildas Prémel-Cabic

2. 2
Sommaire
Présentation & objectifs
La relation MOA / MOE dans la réussite des projets
Le cahier des charges
Le modèle CMMI-ACQ : un rendez-vous manqué
Synthèse

3. 3
Présentation & Objectifs
Gildas Prémel-Cabic
 Plus de 20 ans d’expérience en SSII (côté MOE uniquement !)
 Certifié IREB en Ingénierie des Exigences (IE)
Objectifs :
 Retour d’expérience sur l’impact de la relation MOA/MOE dans la réussite des
projets
 Apport de l’Ingénierie des Exigences dans ce contexte

4. 4
Sommaire
Présentation&Objectifs
La relation MOA / MOE dans la réussite des projets
Le cahier des charges
Le modèle CMMI-ACQ : un rendez-vous manqué
Synthèse

5. 5
La relation MOA / MOE
Les acteurs MOA /MOE
 Maîtrise d’Ouvrage [MOA] – le « demandeur » du système , le « client » de la MOE
• Entité porteuse du besoin d’une organisation définissant les objectifs du système à réaliser et les
condition de réalisation (calendrier, budget).
• Produit le contrat constitué :
– du cahier des charges (spécification technique de besoin) du système à réaliser,
– de la spécification de management du projet de réalisation.
 Maîtrise d’Œuvre [MOE] – le « réalisateur » du système, le « fournisseur » de la MOA
• Entité retenue par la MOA pour réaliser le système,
• Est responsable des choix techniques inhérents à la réalisation du système,
• S’engage à fournir un système conforme dans le délai et le budget négociés.
 Ces acteurs peuvent ne pas appartenir à la même organisation.

6. 6
La relation MOA / MOE
Le cahier des charges est à la
charnière entre les parties.
Il doit assurer la bonne
compréhension par la MOE du
système à réaliser.
Au mieux, les référentiels
normatifs fournissent des
recommandations sur son
contenu, d’où un grande
diversité de la qualité des
cahiers des charges.
Cahier
des
charges

7. 7
La relation MOA / MOE
Conditions nécessaires (mais non suffisantes) à la réussite d’un projet IT :
 une « bonne » relation MOA/MOE :
• Egal investissement des parties
• Équilibrée
• Organisation miroir MOA /MOE
Les cahiers des charges non matures mettent en difficulté la MOE et
en retour la MOA (applicatifs en deçà des attentes, dépassement du
délai et du budget).
Les cahiers des charges non matures mettent en difficulté la MOE et
en retour la MOA (applicatifs en deçà des attentes, dépassement du
délai et du budget).
t
Etat de grâce
Etat de tension
Retour au réalisme
Début
projet
Début
projet
1ère
livraison
MOE
1ère
livraison
MOE
Début
recette MOA
Début
recette MOA
Fin
recette
Fin
recette
 un « bon » cahier des charges.

8. 8
Sommaire
Présentation&Objectifs
La relation MOA / MOE dans la réussite des projets
Le cahier des charges
Le modèle CMMI-ACQ : un rendez-vous manqué
Synthèse

9. 9
Le cahier des charges (CdC)
Un « bon » CdC doit :
 Etre orienté « problème » et non « solution »,
 Donner pour cela :
• la raison d’être du système (pourquoi on l’entreprend),
• son périmètre (ce que les différents parties prenantes du produit doivent être capables de faire ou
attendent de l’exploitation du système).
• les cas d’utilisation du système qui doivent se situer au « bon » niveau c’est-à-dire décrire les
interactions entre les utilisateurs et le système dans l’exercice de leur métier.
• les règles de gestion « métier », réglementaires ou légales que le système doit appliquer,
• son environnement opérationnel (exigences d’interface applicables au système),
 La description de la solution doit se limiter aux contraintes techniques et aux objectifs de
performances (exigences non fonctionnelles applicables au système).
L’analyse des CdC devrait « sortir » la voix des utilisateurs du futur
système.

10. 10
Le cahier des charges (CdC)
Rôle de l’analyste métier (Business Analyst)
 Mission : aider la MOA à produire le CdC
 Fonctions :
• Identifier des parties prenantes/intéressées du système i.e l’ensemble des personnes ayant un
intérêt dans le système,
• Elucider les objectifs/buts des parties prenantes,
• Analyser, documenter et valider les objectifs/buts,
• Rédiger les cas d’utilisation du système,
• Identifier les règles métiers que le système doit appliquer.
L’analyste métier peut être externe à la MOA et agir pour le compte de
cette dernière dans le cadre d’une mission AMOA.
 C’est un métier d’avenir. “As a … (role or actor) (Who)
I want … (what capability or feature do they need) (What)
so that … (why is it of business value or benefit) (Why)”
[“User story for requirement elucidation” Nick Naumovich]
“As a … (role or actor) (Who)
I want … (what capability or feature do they need) (What)
so that … (why is it of business value or benefit) (Why)”
[“User story for requirement elucidation” Nick Naumovich]

11. 11
Le cahier des charges
 Le CdC ne devrait pas contenir d’exigences fonctionnelles applicables au
système (« le système doit … ») :
C’est le rôle de l’analyste fonctionnel (MOE) que d’identifier les exigences
fonctionnelles applicables au système.
 Elles décrivent la solution vue comme une boîte noire.
 Elles ont pour principales sources les cas d’utilisation du système.
“[If Trigger-Event(s) occur] [during Precondition(s)], the system shall [not] perform Response-Action(s)
[resulting in Postcondition(s)] [within Quality-Threshold(s)]”.
[“Generating Complete, Unambiguous, and Verifiable Requirements from Stories, Scenarios, and Use
Cases”,
Don Firesmith, JOT, Vol. 3, No. 10, November-December 2004]
“[If Trigger-Event(s) occur] [during Precondition(s)], the system shall [not] perform Response-Action(s)
[resulting in Postcondition(s)] [within Quality-Threshold(s)]”.
[“Generating Complete, Unambiguous, and Verifiable Requirements from Stories, Scenarios, and Use
Cases”,
Don Firesmith, JOT, Vol. 3, No. 10, November-December 2004]
“Requirements are really a specification that faces the designers and developers. We need them; the users don't”
[Forum Requirement Engineering, B. Ferguson ]
“Requirements are really a specification that faces the designers and developers. We need them; the users don't”
[Forum Requirement Engineering, B. Ferguson ]
“Users may not need requirements, and generally don't want them for their own sake”
[Forum Requirement Engineering, K. Collyer ]
“Users may not need requirements, and generally don't want them for their own sake”
[Forum Requirement Engineering, K. Collyer ]

12. 12
Le cahier des charges : la réalité
 Exemples tirés du CdC d’un
SI :
 « ET11 : le SI doit permettre le
stockage, le traitement et
l’affichage de documents
bureautique dont les formats de
fichiers et d’encodage sont
normalisés ».
 « ET14 : la solution mise en place
devra être compatible avec
Internet Explorer (version 8 et
supérieures), Mozilla Firefox
(version 5 et supérieures) ».
Exigence fonctionnelle trop
générale et donc irréaliste.
Exigence fonctionnelle trop
générale et donc irréaliste.
Exigence technique
exprimant une contrainte
sur la solution.
Exigence technique
exprimant une contrainte
sur la solution.
Cas d’utilisation sans
valeur métier. (S’identifier
n’est pas un objectif en soi)
Cas d’utilisation sans
valeur métier. (S’identifier
n’est pas un objectif en soi)

13. 13
Sommaire
Présentation&Objectifs
La relation MOA / MOE dans la réussite des projets
Le cahier des charges
Le modèle CMMI-ACQ : un rendez-vous manqué
Synthèse

14. 14
Les modèles CMMI
Il existe 3 « constellations»:
 CMMI-DEV : amélioration du
processus de développement
de produits/service
=> s’applique à la MOE
 CMMI-ACQ : amélioration du
processus acquisition de
produits/services
=> s’applique à la MOA
 CMMI-SRV : amélioration du
processus de production d’un
service
=> s’applique à la MOA/MOE selon
le type de service

15. 15
Les modèles CMMI
Ces modèles ont une
structuration commune :
 Composants du modèle :
• Domaine de processus (PA),
• Objectifs génériques et spécifiques
• Pratiques génériques et spécifiques
 Déploiement du modèle :
• Mode « étagé » sur une échelle à 5
niveaux et donnant une
« roadmap »
• Mode « continue » :

16. 16
Le modèle CMMI pour l’acquisition
OPD OPF
OT
OPP
QPM
DAR
AM ARD
SSAPREQM
ATM
AVER
AVAL
PP
PMC
IPM
RSKM
CM MA
PPQA
OID
CAR
Processus
d’acquisition
Gestion de
projet
Processus
support
Gestion de
processus
N5
N4
N3
N2
PA spécifiques du modèle CCMI ACQ PA communs avec CMMI-DEV
Liste des PA :
1. AM : Agreement Management
2. ARD : Acquisition
Requirements development
3. ATM : Acquisition Technical
Management
4. AVAL : Acquisition Validation
5. AVER : Acquisition Verification
6. CAR : Causal Analysis &
Resolution
7. CM : Configuration management
8. DAR : Decision Analysis &
resolution
9. IPM : Integrated Project
Management
10. MA : Measurement & Analysis
11. OID : organization Innovation
Development
12. OPD : Organizational Process
Definition
13. OPF : organizational Process
Focus
14. OPP : Organizational Process
performance
15. OT : Organizational Training
16. PMC : Project Monitoring &
Control
17. PP : Project planning
18. PPQA : Process & Product
Quality Assurance
19. QPM : Quantitative Project
Management
20. REQM : Requirements
Management
21. RSKM : Risk Management
22. SSAP : Solicitation & Supplier
Agreement Development
Ventilation des PA par type et niveau de maturité

17. 17
Le modèle CMMI pour l’acquisition
 Les domaines de processus en lien avec l’ingénierie des exigences sont
adressés dès le niveau N2.
 ARD :
 REQM :
Specific Goal and Practice Summary
SG 1 Develop Customer Requirements
SP 1.1 Elicit Stakeholder Needs
SP 1.2 Develop and Prioritize Customer Requirements
SG 2 Develop Contractual Requirements
SP 2.1 Establish Contractual Requirements
SP 2.2 Allocate Contractual Requirements
SG 3 Analyze and Validate Requirements
SP 3.1 Establish Operational Concepts and Scenarios
SP 3.2 Analyze Requirements
SP 3.3 Analyze Requirements to Achieve Balance
SP 3.4 Validate Requirements
Specific Goal and Practice Summary
SG 1 Manage Requirements
SP 1.1 Understand Requirements
SP 1.2 Obtain Commitment to Requirements
SP 1.3 Manage Requirements Changes
SP 1.4 Maintain Bidirectional Traceability of Requirements
SP 1.5 Ensure Alignment Between Project Work and Requirements
« Exigences »
du cahier des
charges
« Exigences »
du cahier des
charges
Le quotidien
de l’IE
Le quotidien
de l’IE

18. 18
CMMI ACQ : impact sur le relation client/fournisseur
« + » :
 Dès le niveau 2, les organisations devraient soumettre de meilleurs cahiers des charges.
« - » :
 Le modèle ne développe pas de relation réellement collaborative entre acquéreur (MOA)
et fournisseur (MOE) mais promeut la surveillance du fournisseur.
 Son application à la lettre contraint le fournisseur à produire un grand nombre de
preuves, la plupart « naturellement » produites par les fournisseurs ayant adopté le
modèle CMMI-DEV.
 A partir du niveau 4, le modèle devient intrusif, des livrables fournisseur relevant de sa
stratégique (objectifs de performance des processus, niveaux atteints et axes
d’amélioration).

19. 19
CMMI ACQ : déploiement au 10/12/12
Présenter le déploiement du modèle CMMI Acq

20. 20
CMMI-ACQ : déploiement au 10/12/12
Le modèle « CMMI Acq » a peu de succès.
Les MOA n’ont pas perçu l’intérêt du CMMI-ACQ car (hypothèse) :
 Trop complexe (61 pratiques), il cible :
• les organismes dont les services achats dispose d’un budget important (ex : Direction Générale
de l’Armement),
• les intégrateurs de système ayant de multiples fournisseurs.
Il n’en demeure par moins que les MOA ont intérêt à s’inspirer du
modèle CMMI-ACQ et notamment de sous-pratiques qui contituent un
véritable guide à l’identification de ses besoins, à la contractualisation
des achats et à la vérification des produits achetés.
Il n’en demeure par moins que les MOA ont intérêt à s’inspirer du
modèle CMMI-ACQ et notamment de sous-pratiques qui contituent un
véritable guide à l’identification de ses besoins, à la contractualisation
des achats et à la vérification des produits achetés.

21. 21
CMMI-ACQ : pour aller plus loin
Clés de lecture du modèle
 Le modèle considère 3 acteurs :
• Customer
• Acquirer (en interface avec les 2 autres acteurs)
• Supplier
 Les PA sont des processus couplés entre eux et ne sont pas ordonnés
chronologiquement.

22. 22
Sommaire
Présentation&Objectifs
La relation MOA / MOE dans la réussite des projets
Le cahier des charges
Le modèle CMMI-ACQ : un rendez-vous manqué
Synthèse

23. 23
Synthèse
A l’origine de tout projet, la MOA joue un rôle crucial, notamment dans
l’établissement du cahier des charges.
La réussite de tout projet d’IT passe par la continuité entre MOA et MOE.
Pour se faire, les MOA auraient intérêt :
 à déployer en leur sein un processus d’IE au sens de l’ISO9001 piloté et doté d’un
référentiel général des exigences (« business requirements », « business rules », « user
requirements » , « legacy requirements »).
 À initialiser, à partir de ce référentiel d’entreprise, le référentiel des exigences propres au
projet et à l’enrichir (exigences spécifiques au projet),
 À partager le référentiel projet avec ses fournisseurs en s’appuyant sur les pratiques du
modèle CMMI-ACQ.

24. 24
Synthèse
Analyste métier Analyste fonctionnel
Processus IE