Untitled

978-2-10-056580-1
Préface
Préface à la 1re édition (écrite à propos de la version 1.1 de CMMI)

Avant le XIXe siècle, alors que furent érigés des phares tout au long de la côte
atlantique des États-Unis, on a déploré la perte de centaines de navires et de milliers
de vies. Plusieurs de ces phares tiennent encore debout aujourd’hui. Si vous avez la
chance de les visiter, vous découvrirez le secret qu’ils partagent. Chacun renferme
en effet un magnifique instrument, construit avec une précision remarquable : une
lentille de Fresnel, fabriquée à Paris au XIXe et au début du XXe siècle. Inventé par
Augustin Fresnel en 1822, cet astucieux assemblage de prismes permet de focaliser un
rayon de lumière avec une intensité cinq fois plus grande que tout ce qui avait été
possible auparavant. Ainsi, des centaines de navires ont pu approcher les côtes tout
en évitant les bancs et les récifs dangereux.
Aujourd’hui, tout comme Richard Basque le décrit avec éloquence au début de
son livre, des milliers d’organisations se retrouvent perdues en mer, essayant de mener
à bon port leurs nombreux projets au milieu de la houle des changements d’exigences
et de technologies, espérant livrer leurs produits et services pour la grande satisfaction
de leurs clients et utilisateurs.
Pour améliorer leur probabilité de réussite, des organisations de tous les horizons
industriels se tournent en nombre sans cesse croissant vers l’amélioration de processus
en s’appuyant sur les meilleures pratiques qui puissent les guider dans la gestion
de leurs projets et l’ingénierie de leurs produits et services. Dans tous les domaines
industriels (par exemple l’aérospatial, les télécommunications, l’automobile, le logiciel,
le bancaire ou l’assurance), des organisations en tête de peloton sur le plan mondial
adoptent le CMMI comme référentiel de meilleures pratiques. Comme Richard
l’explique dans les chapitres 1 et 2, bien que le département de la Défense américain
ait soutenu le développement de ce modèle et de ses prédécesseurs (le CMMI a
une longue lignée d’ancêtres), le CMMI est aujourd’hui tout autant utilisé dans le
monde commercial que dans celui de la défense, surtout dans les moyennes et grandes
organisations. (Le site web du SEI donne toutes les informations souhaitées sur le
CMMI : www.sei.cmu.edu/cmmi.)
Le défi de tout modèle de pratiques repose dans son interprétation et dans son
adaptation. Même si le CMMI aide effectivement des milliers d’organisations à éviter
« bancs et récifs dangereux » et à développer avec succès de bons produits, dans le respect
des délais et des budgets, en vérité certaines d’entre elles font un usage plus judicieux
de ce modèle que d’autres. Il en résulte pour elles des avantages plus importants,
VIII Préface
comme celui de pouvoir consacrer une part grandissante de leur énergie à la poursuite
de nouvelles occasions d’affaire. Les organisations qui ne peuvent maîtriser leurs
affaires actuelles auront sans doute du mal à le faire avec de nouvelles affaires et
devront bientôt déclarer forfait. Les organisations doivent pouvoir se lancer dans de
nouvelles occasions d’affaire. Hélas, pour plusieurs d’entre elles, la Direction est trop
occupée à régler les problèmes qui perturbent les projets en cours. Ce qui devrait être
routinier n’est pas encore établi par le biais de processus normalisés. Les interfaces de
processus entre groupes interdépendants ne sont pas encore été définies avec soin. Ces
organisations constateront rapidement que leurs compétiteurs les devanceront dans la
poursuite de nouvelles occasions d’affaires et en récolteront les bénéfices à leur place.
Je disais que les phares ont sauvé des centaines de navires et des milliers de vie
au début du XIXe siècle et que les lentilles de Fresnel, conçues par un Français et
fabriquées par des manufacturiers parisiens, ont permis de décupler les sauvetages
de vies et de navires. De même, le CMMI et le livre de Richard aideront votre
organisation à déployer de meilleures pratiques avec intelligence, vous incitant à
enchâsser dans des processus normalisés ce qui est routinier et vous permettant ainsi
de dégager le temps dont votre organisation aura un précieux besoin pour analyser et
exploiter les occasions d’affaires apportées par les changements de technologies et les
fluctuations des marchés.
Les exigences de la réussite sont aujourd’hui plus grandes qu’elles ne l’ont jamais
été pour les organisations. La globalisation crée des compétiteurs dans tous les coins
du globe et, en même temps, de nouveaux marchés pour vos produits et services. Les
technologies qui changent rapidement exigent que les organisations soient rompues à
la discipline des processus et fassent preuve d’agilité et d’innovation pour exploiter,
mieux et plus tôt que leurs compétiteurs, les occasions d’affaires qui jalonnent leurs
parcours. Les meilleures pratiques du CMMI peuvent « éclairer » leur route ; le livre
de Richard, comme les lentilles de Fresnel, peut vous aider à « voir la route » avec plus
d’acuité.
Si votre projet ou votre organisation se débat pour construire les bons produits
et services et que vous souhaitez apprendre les pratiques mises au point par d’autres
organisations qui ont réussi dans des circonstances similaires aux vôtres, alors ce livre
vous est destiné. Si vous envisagez de tirer le meilleur profit du modèle CMMI et que
vous vous interrogez sur la meilleure façon de le déployer dans votre organisation,
encore une fois, ce livre vous est destiné.
J’aimerais conclure en parlant de l’auteur de ce livre. D’autres ont publié, souvent
avec une grande sagesse, des livres sur leurs expériences d’utilisation de modèles pour
l’amélioration de processus. Bien peu savent le faire avec le talent et la grâce d’un poète
comme Richard sait le faire. Je n’apprécie pas seulement la grande compréhension
dont Richard fait preuve. J’apprécie aussi le style qu’il adopte dans son livre. Richard
écrit avec la grâce et le style que bien peu sauraient imiter ce qui nous donne un livre
dont on ressent les vibrations cristallines comme celles de la lumière éblouissante qui
jaillit d’une lentille de Fresnel.
Mike K ONRAD
Co-auteur du CMMI en version originale anglaise
et responsable des projets CMMI au SEI (Software Engineering Institute)
Préface
Préface à la 2e édition (écrite à propos de la version 1.2 de CMMI-DEV)

Lorsque Richard a publié ce livre en première édition, mon ami le docteur
Mike Konrad, que j’estime beaucoup, a écrit une préface brillante. Il a souligné
l’importance de « bien éclairer la route » de l’amélioration de processus. Le livre de
Richard a constitué un bel exemple de « l’éclairage » auquel songeait Mike. Par cette
deuxième édition, Richard contribue encore une fois à cette vision de l’amélioration
continue que nous souhaitons partager avec la « CMMI Product Suite ». Nous sommes
redevables à Richard et à des collègues tels que lui : par leurs écrits, ils nous guident
vers la livraison de meilleurs produits et services ainsi que vers un futur plus lumineux.
Au moment d’écrire ces lignes, je prends pleinement conscience des efforts
exceptionnels qui ont été déployés pour faire du CMMI un outil utile à la com-
munauté mondiale des développeurs. Par exemple, en mai 2006, le SEI a souligné la
participation du cinquante millième étudiant (en France incidemment !) au cours
« Introduction to CMMI ». À la même date, 62 % des évaluations CMMI (sur un total
de 1 500) avaient été menées dans des organisations hors des États-Unis. La France
est bonne première en Europe alors que quatre pays du cercle du Pacifique (Inde,
Japon, Chine et Corée) ont mené, ensemble, plus d’évaluations que les États-Unis.
On dispose de traductions totales ou partielles du CMMI en japonais, en chinois, en
français, en néerlandais, en allemand et en portugais.
Que nous réserve le futur ? On peut prévoir l’expansion de la couverture des
besoins des organisations en matière de processus. En effet, nous allons développer des
adaptations du contenu actuel, à partir d’un socle commun et en ne modifiant que les
parties spécifiques aux nouveaux champs d’intérêt. Par exemple, ceux qui se définissent
avant tout comme des prestataires de services plutôt que des développeurs de produits
nous disent que la plus grande partie du modèle actuel fonctionne pour eux ; nous
ferons donc les quelques ajustements nécessaires pour bien traduire les meilleures
pratiques applicables dans leur environnement spécifique. Nous recherchons aussi
des moyens de bien capter les bonnes pratiques des organisations qui, plutôt que de
développer elles-mêmes des applicatifs logiciels complexes, préfèrent les acheter et les
intégrer dans leur environnement ; ceci implique évidemment un savoir faire pointu
en négociation, acquisition et suivi de contrats. Deux nouvelles « constellations » du
CMMI sont en cours de développement pour traiter ces deux cas particuliers et d’autres
X Préface
pourraient suivre. Nous savons que Richard nous soutiendra dans cette expansion pour
faire en sorte que le chemin de l’amélioration demeure toujours aussi libre d’obstacles
que possible.
Trois principes ont guidé la mise à jour du CMMI en version 1.2 :
• simplifier le document ;
• étendre sa portée pour englober des composants de type matériel (« hardware ») ;
• accroître la confiance dans les résultats des évaluations.
Vous constaterez les résultats de nos efforts dans la version 1.2 du modèle. Avec
différents clients, Richard nous a aidés à valider et à confirmer les éléments améliorés
dans le modèle. Ce fut un plaisir pour moi de faire équipe avec lui au cours de
ces travaux qui ont permis de mieux expliquer les différences essentielles que nous
voulions intégrer dans cette nouvelle version du CMMI. Maintenant, il vous relaie
ces bonnes idées par ce livre, dans son style bien à lui. Profitez de ses lumières et
laissez-vous guider sur la route de l’amélioration de processus !
Mike P HILLIPS
The Software Engineering Institute
Note de l’auteur
À tous ceux qui m’ont épaulé dans ce projet ambitieux qu’est Alcyonix,
famille, amis, collègues et clients,
alors que se profile tranquillement une retraite très progressive.
Lors de la parution de la 2e édition

Mon éditeur m’a rencontré en juin 2005 pour discuter du projet d’une seconde édition.
Sachant alors que le SEI annonçait pour le milieu de l’année 2006 une nouvelle
version (1.2) du CMMI, j’ai alors proposé d’aligner la seconde édition de mon livre
sur cette nouvelle version du CMMI. Ainsi les lecteurs profiteraient non seulement
des améliorations que je pouvais apporter au contenu en français mais pourraient
en même temps utiliser en français les énoncés des pratiques du CMMI dans sa
version la plus récente. Certes, les autres éléments d’information relatifs au CMMI
qui auraient également évolué (par exemple, l’existence de SCAMPI classe B et C)
seraient évidemment mis à jour dans ma nouvelle édition.
J’ai aussi voulu ajouter du contenu aux endroits que l’on m’a signalés comme étant
insuffisants pour bien interpréter le sens des pratiques du CMMI. Ma source principale
d’inspiration fut facile à trouver. Agissant comme modérateur du groupe Yahoo!
« cmmi-en-francais », j’ai profité de nos échanges nourris pour éclairer les endroits
laissés trop vagues. J’ai aussi puisé dans nos échanges plusieurs idées et exemples dont
j’ai souhaité faire profiter mes lecteurs. Aussi, et je m’en réjouis tout particulièrement,
on m’a demandé des exemples de choses à ne pas faire afin d’en tirer les leçons
voulues. Je me suis alors tourné vers un des membres les plus actifs de notre groupe
de discussion : Denise Cattan. Elle a très gentiment accepté de nous faire profiter de
sa longue expérience en ingénierie de système et de son talent pour illustrer par des
histoires vécues les dangers de la non-discipline en développement de systèmes.
Lors de la première édition de ce livre, la version 1.1 du CMMI qui était
alors disponible se présentait en différents regroupements de disciplines et en deux
représentations ce qui donnait plusieurs instances du modèle CMMI. L’instance que
XII CMMI 1.3
j’avais utilisée pour mon livre était la plus complète (en termes de regroupements
de disciplines) afin de couvrir tous les domaines de processus et toutes les pratiques
possibles. De plus, sachant que la majorité des utilisateurs du modèle avaient choisi
la représentation étagée (staged), c’est donc cette représentation du CMMI que
j’avais opté de privilégier. L’instance du CMMI que j’avais donc utilisée se nommait
dans son titre original anglais complet et très long : « Capability Maturity Model
Integration (CMMI), Version 1.1 – CMMI for Systems Engineering, Software Engineering,
Integrated Product and Process Development, and Supplier Sourcing ». Son titre abrégé
était « CMMI-SE/SW/IPPD/SS, V1.1 ».
En date du 25 août 2006, le SEI a publié la version 1.2 du CMMI sous le titre com-
plet « CMMI for Development, Version 1.2 » et sous le titre abrégé CMMI-DEV, V1.2
(le document lui-même est numéroté CMU/SEI-2006-TR-008). Il n’y a plus qu’une
seule instance du CMMI, du moins pour ce que le SEI appelle la « constellation » du
développement (development) et qui regroupe, de facto, toutes les disciplines associées
au développement. De plus, dans cette version 1.2, le SEI a choisi de présenter à la fois
la représentation étagée (staged) et continue (continuous) avec des notes de mise en
page qui permettent de séparer les différences qui sont relativement peu nombreuses.
Bref, voilà un CMMI considérablement simplifié dans sa publication originale anglaise.
Du coup, la question de l’instance que je privilégierais pour la deuxième édition de
mon livre se trouvait résolue par le fait qu’il n’y a plus qu’une seule référence originale !
Dans la deuxième édition de ce livre, les mots CMMI et CMMI-DEV réfèrent
donc à la plus récente version officielle du CMMI disponible, dont la référence est
donnée dans le paragraphe précédent.
Les notions de représentations (étagée ou continue) restent bien sûr disponibles
lorsqu’on déploie le CMMI dans une organisation. Si on choisit la représentation
étagée, ceci entraîne automatiquement un ordre de préséance des domaines de
processus à déployer. On les déploie selon le niveau de maturité auquel ils sont
associés. Ainsi pour passer du niveau de maturité 1 au niveau de maturité 2, il faut
institutionnaliser tous les domaines de processus associés au niveau 2. Puis pour passer
au niveau de maturité 3, il faut aussi institutionnaliser tous les domaines de processus
associés au niveau 3, et ainsi de suite.
Comme la majorité des organisations que je connais privilégient toujours cette
représentation étagée, j’ai décidé de maintenir dans mon livre cet ordre de présenta-
tion des domaines de processus par niveau de maturité, même si ce n’est pas l’ordre de
présentation utilisée (l’ordre alphabétique) dans l’unique nouvelle instance du modèle
CMMI en anglais.
Pour aider les lecteurs à se retrouver rapidement, les tables de correspondance
ci-dessous aideront à trouver le domaine de processus qu’ils cherchent.

La décision d’une 3e édition fut motivée par l’épuisement des inventaires des copies
imprimées de la 2e édition. De plus, la publication à la mi-2008 d’une traduction en
français complète et autorisée du SEI du livre CMMI original m’a amené à réviser très
légèrement quelques termes qui, après mûre réflexion, méritaient d’être modifiés. Il
Note de l’auteur XIII
en résulte que le libellé des objectifs et des pratiques est totalement conforme dans
cette 3e édition avec celui utilisé par Pearson Education France qui a fait la traduction
complète du CMMI, avec l’implication de mon ami et collègue Antoine Nardèze et
son équipe qui m’avaient justement demandé de valider la cohérence avec mon livre,
ce que j’ai fait.
Par ailleurs, j’ai décidé de proposer, comme valeur ajoutée, des représentations
schématiques des différents domaines de processus. Dunod les met à disposition sur
une page de leur site web complémentaire au livre (il suffit de cliquer sur l’icône
« Suppléments au livre » dans la page de leur site web — www.dunod.com — qui
correspond à cet ouvrage).

La décision d’une 4e édition coïncida avec la publication de la version 1.3 du CMMI.
La collaboration avec Pearson s’est poursuivie et le contenu du livre complet en
français, traduction autorisée par le SEI, s’alignera encore une fois avec la terminologie
fixée ici dans mon ouvrage. Par ailleurs, j’ai décidé de couvrir, comme valeur ajoutée à
cette 4e édition, les constellations SVC (Services) et ACQ (Acquisition) en plus de
DEV (Développement) pour ainsi proposer à tout le moins une traduction cohérente
et complète de toute la famille CMMI.
Par ailleurs, des représentations schématiques des différents domaines de processus
sont toujours mises à disposition sur une page du site web de Dunod complémentaire
au livre (il suffit de cliquer sur l’icône « Suppléments au livre » dans la page de leur
site web — www.dunod.com — qui correspond à cet ouvrage).
Note sur les copyrights

Software Engineering Institute (SEI) représente l’auteur collectif du texte original anglais
dont les droits sont détenus par Carnegie Mellon University à laquelle est affilié le
SEI. La traduction qui en a été faite par Richard Basque a été réalisée avec l’aimable
autorisation du Software Engineering Institute. Carnegie Mellon University et Software
Engineering Institute n’ayant cependant pas participé directement ou indirectement
à cette traduction, ils ne peuvent officiellement l’endosser. Richard Basque demeure
responsable de sa précision et de son interprétation.
Je tiens cependant à souligner que le groupe de discussion cmmi-en-francais sur
Yahoo! a été mis à contribution ; il compte plus de 350 participants francophones.
Ceux-ci m’ont éclairé sur certaines formulations à privilégier en français. Notre souhait
est simple : proposer à la francophonie une traduction qui serve de référence pour le
CMMI en français et éviter la multiplication des traductions françaises qui ne feraient
que nuire à la synergie que nous désirons développer entre les professionnels de
l’amélioration du processus.
Richard BASQUE
XIV CMMI 1.3
Table de référence par ordre alphabétique des sigles des domaines de processus du CMMI-DEV
CONTINU ÉTAGÉ
Sigle Catégorie Niveau Nom en français Nom en anglais Page
de processus maturité
Analyse causale Causal Analysis
CAR Support 5
et résolution and Resolution
173
CM Support 2 Gestion de configuration Configuration Management 105

Analyse et prise Decision Analysis
DAR Support 3
de décision and Resolution
156
Integrated Project
IPM Project Mgmt. 3 Gestion de projet intégrée
Management
147
MA Support 2 Mesure et analyse Measurement and Analysis 98

Définition du processus Organizational Process
OPD Process Mgmt. 3
organisationnel Definition
141
Focalisation
OPF Process Mgmt. 3 sur le processus Organizational Process Focus 136
organisationnel
Gestion de la
Organizational Performance
OPM Process Mgmt. 5 performamnce
Management
175
organisationnelle
Performance du processus Organizational Process
OPP Process Mgmt. 4
organisationnel Performance
163
Formation
OT Process Mgmt. 3
organisationnelle
Organizational Training 145
PI Product Eng. 3 Intégration de produit Product Integration 125

Surveillance et contrôle Project Monitoring
PMC Project Mgmt 2
de projet and Control
90
PP Project Mgmt 2 Planification de projet Project Planning 80

Assurance-qualité Process and Product Quality
PPQA Support 2
processus et produit Assurance
102
Gestion de projet Quantitative Project

QPM Project Mgmt. 4
quantitative Management
166
Développement des
RD Product Eng. 3
exigences
Requirements Development 116
REQM Project Mgmt. 2 Gestion des exigences Requirements Management 75

RSKM Project Mgmt. 3 Gestion des risques Risk Management 152
Gestion des accords Supplier Agreement
SAM Project Mgmt 2
avec les fournisseurs Management
94
TS Product Eng. 3 Solution technique Technical Solution 121

VAL Product Eng. 3 Validation Validation 134
VER Product Eng. 3 Vérification Verification 129
Note de l’auteur XV
Table des domaines de processus du CMMI-DEV dans la représentation étagée

(par niveau de maturité)
NOTE : ceci est l’ordre utilisé dans la mise en page des chapitres 7 à 10.
ÉTAGÉ CONTINUE
Niveau Catégorie Sigle Nom en français Nom en anglais Page
maturité de processus
Requirements
2 Project Mgmt REQM Gestion des exigences
Management
75
2 Project Mgmt PP Planification de projet Project Planning 80

2 Project Mgmt PMC
90

2 Project Mgmt SAM
avec les fournisseurs Management (SAM)
94
Measurement
2 Support MA Mesure et analyse
and Analysis
98
Assurance-qualité Process and Product

2 Support PPQA
processus et produit Quality Assurance
102
Configuration
2 Support CM Gestion de configuration
Management
105
Développement Requirements
3 Product Eng. RD
des exigences Development
116
3 Product Eng. TS Solution technique Technical Solution 121

3 Product Eng. PI Intégration de produit Product Integration 125
3 Product Eng. VER Vérification Verification 129
3 Product Eng. VAL Validation Validation 134
Focalisation
Organizational Process
3 Process Mgmt. OPF sur le processus
Focus
136
organisationnel
OPD Définition du processus Organizational Process
3 Process Mgmt.
+ IPPD organisationnel + IPPD Definition + IPPD
141
Formation
3 Process Mgmt. OT
organisationnelle
Gestion de projet Integrated Project

3 Project Mgmt. IPM
intégrée Management
147
3 Project Mgmt. RSKM Gestion des risques Risk Management 152

Analyse et prise Decision Analysis
3 Support DAR
de décision and Resolution
156
Performance
4 Process Mgmt. OPP du processus
Performance
163
organisationnel
4 Project Mgmt. QPM
166
Gestion de la Organizational
5 Process Mgmt. OPM performance Performance 175
organisationnelle Management
5 Support CAR
et résolution and Resolution (CAR)
173
XVI CMMI 1.3
Table de référence dans la représentation continue (par catégorie de processus)
CONTINU ÉTAGÉ
Catégorie Niveau Sigle Nom en français Nom en anglais Page
Focalisation
Process Mgmt. 3 OPF sur le processus
Focus
136
organisationnel
Définition du processus Organizational Process
Process Mgmt. 3 OPD
organisationnel Definition
141
Formation
Process Mgmt. 3 OT
organisationnelle
Performance du processus Organizational Process

Process Mgmt. 4 OPP
organisationnel Performance
163
Organizational
Gestion de la performance
Process Mgmt. 5 OPM
organisationnelle
Performance 175
Management
Développement Requirements
Product Eng. 3 RD
des exigences Development
116
Product Eng. 3 TS Solution technique Technical Solution 121

Product Eng. 3 PI Intégration de produit Product Integration 125
Product Eng. 3 VER Vérification Verification 129
Product Eng. 3 VAL Validation Validation 134
Requirements
Project Mgmt 2 REQM Gestion des exigences
Management
75
Project Mgmt 2 PP Planification de projet Project Planning 80

Project Mgmt 2 PMC
90

Project Mgmt 2 SAM
avec les fournisseurs Management
94
Integrated Project
Project Mgmt. 3 IPM Gestion de projet intégrée
Management
147
Project Mgmt. 3 RSKM Gestion des risques Risk Management 152

Project Mgmt. 4 QPM
166
Measurement and
Support 2 MA Mesure et analyse
Analysis
98
Assurance-qualité Process and Product

Support 2 PPQA
processus et produit Quality Assurance
102
Configuration
Support 2 CM Gestion de configuration
Management
105
Decision Analysis
Support 3 DAR Analyse et prise de décision
and Resolution
156

Support 5 CAR
et résolution and Resolution
173
Note de l’auteur XVII
Table de référence par ordre alphabétique du nom de domaine de processus en anglais
CONTINU ÉTAGÉ
Nom en anglais Sigle Nom en français Catégorie Niveau Page
Causal Analysis Analyse causale
and Resolution
CAR
et résolution
Support 5 173
Configuration Management CM Gestion de configuration Support 2 105

Decision Analysis Analyse et prise
and Resolution
DAR
de décision
Support 3 156
Integrated Project Gestion de projet

Management
IPM
intégrée
Project Mgmt. 3 147
Measurement and Analysis MA Mesure et analyse Support 2 98

Organizational Process Définition du processus
Definition
OPD
organisationnel
Process Mgmt. 3 141
Focalisation
Organizational Process Focus OPF sur le processus Process Mgmt. 3 136
organisationnel
Gestion de la
Organizational Performance
Management
OPM performance Process Mgmt. 5 175
organisationnelle
Performance
Performance
OPP du processus Process Mgmt. 4 163
organisationnel
Formation
Organizational Training OT
organisationnelle
Process Mgmt. 3 145
Process and Product Quality Assurance-qualité

Assurance
PPQA
processus et produit
Support 2 102
Product Integration PI Intégration de produit Product Eng. 3 125

Project Monitoring Surveillance et contrôle
and Control
PMC
de projet
Project Mgmt 2 90
Project Planning PP Planification de projet Project Mgmt 2 80

Quantitative Project Gestion de projet
Management
QPM
quantitative
Project Mgmt. 4 166
Développement
Requirements Development RD
des exigences
Product Eng. 3 116
Requirements Management REQM Gestion des exigences Project Mgmt. 2 75

Risk Management RSKM Gestion des risques Project Mgmt. 3 152
Supplier Agreement Gestion des accords
Management
SAM
avec les fournisseurs
Project Mgmt 2 94
Technical Solution TS Solution technique Product Eng. 3 121

Validation VAL Validation Product Eng. 3 134
Verification VER Vérification Product Eng. 3 129
Table des matières
Préface de Mike Konrad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VII
Préface de Mike Phillips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IX
Note de l’auteur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XI
Avant-propos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XXV
Chapitre 1 – La genèse d’un modèle de meilleures pratiques . . . . . . . . . . . . . . . . . . . . 1
Chapitre 2 – L’étoile CMMI dans la galaxie des modèles . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1 ISO9001:2000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2 ISO/IEC 15504 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3 ISO12207 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4 iCMM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.5 ITIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.6 SA-CMM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.7 PMBOK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.8 COBIT et Sarbanes-Oxley (SOX) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.9 Agile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.10 eSCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.11 SCAMPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
XX CMMI 1.3
Chapitre 3 – Une échelle de maturité organisationnelle . . . . . . . . . . . . . . . . . . . . . . . . 17

3.1 La parabole de la visite chez le médecin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2 La parabole du trajet en voiture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3 Le CMMI au regard de ces paraboles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.4 Tronc commun et parties spécifiques dans les trois constellations du CMMI . . . 24
Chapitre 4 – Terminologie particulière au CMMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.1 Organisation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.2 Projet et travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.3 Manager et gestionnaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.4 Chef de projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.5 Groupe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.6 Représentation, niveau, maturité et aptitude . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.7 Nomenclature des niveaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.8 Adéquat, approprié, au besoin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.9 Établir et maintenir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.10 Client et utilisateur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.11 Fournisseur et prestataire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.12 Parties prenantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.13 Produits d’activité, produits et services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.14 Évaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.15 Actifs processus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.16 CMMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Chapitre 5 – L’architecture du modèle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5.1 Les deux représentations du CMMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.1.1 La représentation étagée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.1.2 La représentation continue. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.1.3 Que choisir ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.2 Les différents composants du CMMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.2.1 Domaine de processus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Table des matières XXI
5.2.2 Intention, notes explicatives et références . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.2.3 Objectifs et pratiques génériques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.2.4 Objectifs spécifiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.2.5 Pratiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.2.6 Exemples de produits d’activité typiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.2.7 Sous-pratiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.2.8 Élaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.2.9 Divers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Chapitre 6 – Les niveaux 0 et 1 : des cas très particuliers . . . . . . . . . . . . . . . . . . . . . . 59
Chapitre 7 – Le niveau 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
7.1 Interprétation de l’objectif générique GG2 et des pratiques génériques GP2.1
à GP2.10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
7.1.1 GP2.1 – Établir une directive organisationnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
7.1.2 GP2.2 – Planifier le processus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
7.1.3 GP2.3 – Fournir les ressources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
7.1.4 GP2.4 – Assigner la responsabilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
7.1.5 GP2.5 – Former les personnes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
7.1.6 GP2.6 – Contrôler les produits d’activité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
7.1.7 GP2.7 – Identifier et impliquer les parties prenantes concernées . . . . . . . . . . . . . 72
7.1.8 GP2.8 – Surveiller et contrôler le processus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
7.1.9 GP2.9 – Évaluer la conformité de manière objective . . . . . . . . . . . . . . . . . . . . . . . 74
7.1.10 GP2.10 – Passer le statut en revue avec la hiérarchie . . . . . . . . . . . . . . . . . . . . . . 74
7.2 Interprétation des pratiques spécifiques dans les domaines de processus
de la constellation DEV au niveau de maturité 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
7.2.1 Gestion des exigences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
7.2.2 Planification de projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
7.2.3 Surveillance et contrôle de projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
7.2.4 Gestion des accords avec les fournisseurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
7.2.5 Mesure et analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
7.2.6 Assurance qualité processus et produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
7.2.7 Gestion de configuration (un domaine de processus de la catégorie Support dans
la représentation continue) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
XXII CMMI 1.3

8.1 Interprétation de l’objectif générique GG3 et des pratiques génériques GP3 . . . 113
8.1.1 GP3.1 – Établir un processus ajusté . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
8.1.2 GP3.2 – Recueillir des retours d’expériences relatifs au processus . . . . . . . . . . . . 114
8.2.1 Développement des exigences. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
8.2.2 Solution technique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
8.2.3 Intégration de produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
8.2.4 Vérification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
8.2.5 Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
8.2.6 Focalisation sur le processus organisationnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
8.2.7 Définition du processus organisationnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
8.2.8 Formation organisationnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
8.2.9 Gestion de projet intégrée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
8.2.10 Gestion des risques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
8.2.11 Analyse et prise de décision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

9.1.1 Performance du processus organisationnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
9.1.2 Gestion de projet quantitative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Chapitre 10 – Le niveau 5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

de la constellation dev au niveau de maturité 5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
10.1.1 Analyse causale et résolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
10.1.2 Gestion de la performance organisationnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Chapitre 11 – Un cas concret . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Chapitre 12 – Les bénéfices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Chapitre 13 – Utilisations possibles du CMMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

13.1 Guide de bonnes pratiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Table des matières XXIII
13.2 Sources de gabarits (modèles) pour des processus à améliorer ou à définir . . . . . 197
13.3 Source d’inspiration pour une approche d’amélioration continue et progressive 198
13.4 Référentiel pour s’auto-évaluer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
13.5 Référentiel pour évaluer des tiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
13.5.1 Fournisseurs potentiels (sélection) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
13.5.2 Fournisseurs actuels (audit en cours de projet en vue d’une décision de go/nogo) 199
13.5.3 « Due diligence » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
A NNEXES
Annexe A – Indicateurs des pratiques du CMMI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Annexe B – La pénétration du CMMI dans le monde . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Annexe C – Les « certifications » du SEI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
Annexe D – « Histoires vécues » et autres histoires . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
Annexe E – CMMI-ACQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
Annexe F – CMMI-SVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
Références bibliographiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
Avant-propos
Clarifions tout de suite un point important : ce livre n’est pas une traduction du
CMMI. Le SEI m’a accordé l’autorisation de puiser tout ce que je voulais dans les
fichiers du CMMI pour écrire cet ouvrage. J’aurais pu, si je l’avais voulu, faire une
traduction complète. Mais je ne l’ai pas fait. Pourquoi ?
J’ai déjà essayé et j’ai arrêté. Avant même la version 1.0 du CMMI, me sentant
l’âme missionnaire pour notre chère langue française, je me suis porté volontaire pour
amorcer ce grand œuvre. J’avais l’expérience de la francisation (officielle et avec la
bénédiction totale du SEI) du SW-CMM en 1998. Donc, n’écoutant que ma témérité,
je me suis dit : fonçons vers le CMMI. Nous n’en étions alors qu’à une version 0.9
suivie d’une lettre que j’ai oubliée. C’était avant même la première version officielle et
publique 1.0 sortie des presses du SEI en 2000. Premier problème : je savais que cette
version était temporaire, je savais que la prochaine serait volatile et que la version 1.1
aurait une durée de vie suffisante. Mais je me disais qu’il fallait tout de suite créer
l’habitude de causer CMMI en français et donc qu’il fallait le faire vite. On allait
mettre à niveau ensuite. Pourquoi pas ? On est motivé ou on ne l’est pas.
Certes... alors, deuxième problème : qui va payer tout ça ? Je veux bien payer de
ma personne mais je n’ai pas la naïveté ni la prétention de croire que j’y arriverai
seul. Et je doute qu’on puisse éviter les frais d’un traducteur spécialisé ; c’est ce qu’on
avait fait pour le SW-CMM. Je bombarde de courriels1 tous les francophiles que je
connais dans le monde SW-CMM et leur demande leur contribution en jours et aussi
en espèces sonnantes et trébuchantes pour ce nouveau projet de francisation : CMMI.
Les réponses ne tardent pas à me faire tomber des nues.
Tous veulent bien payer de leur personne mais aucun ne peut convaincre sa société
de mettre un seul écu. Je les comprends, ce sont des amis pour la plupart, pas seulement
des collègues, mais je me tape une déprime carabinée à la lecture de leurs courriels qui
tous disent sensiblement : des jours (bénévoles !) OK mais pas d’argent. La déprime
sera de courte durée. Je me dis : je vais me battre quand même et frapper aux portes
de mes gouvernements pour obtenir des subsides. Grâce à l’écoute exceptionnelle
1. Le mot « courriel » inventé au Québec est maintenant accepté en France et par plusieurs sociétés.
XXVI CMMI 1.3
et à la réactivité d’un ex-collègue (merci Denis Bistodeau) membre du ministère

québécois responsable de ce genre de dossier, je parviens à décrocher une contribution
du gouvernement du Québec. Je suis fier de mon pays et de ma langue. Au boulot !
Je ne dévoilerai pas de chiffres car je ne veux pas minimiser le geste généreux (je le
dis bien sincèrement) du ministère québécois mais le subside ne couvrait évidemment
pas mon propre temps. Il aurait couvert une partie des frais de traducteurs spécialisés.
J’espérais qu’une fois la machine partie, mes amis francophiles auraient quelque chose
à montrer à leurs sociétés pour enfin sauter dans le train en marche.
Je me suis lancé dans l’aventure et j’ai échoué. Au bout de quelques semaines, je
n’arrivais plus à faire tourner Alcyonix, ma propre société que j’avais fondée en 1998,
et à faire avancer la traduction. En plus, mes contacts qui m’avisaient de leurs précieux
conseils sur l’acceptation des termes français étaient plus câblés côté logiciel que côté
ingénierie système. Je me demandais si les choix de termes allaient éventuellement
remporter l’assentiment des ingénieurs système. Je me sentais responsable d’engager
des deniers publics dans une aventure qui dépassait maintenant ma petite personne.
Appliquant une pratique du modèle, suivre et agir en cas de dérive, j’ai agi : je me suis
résigné à arrêter car je ne pouvais plus tenir à bout de bras ce projet trop gros pour
moi, malgré l’appui sympathique de plusieurs de mes contacts.
Je me sentais un Don Quichotte de la langue française sur le cheval CMMI.
La plupart des grandes multinationales, même dans la très française mère patrie,
favorisaient le nouvel esperanto du business : l’anglais. Ne me sentant pas à l’aise dans
ce rôle désespéré et tragique, j’ai préféré me raviser et passer à d’autres projets.
Alors pourquoi y revenir ? Mais justement je n’y reviens pas. Je vous ai dit que
ce livre n’est pas une traduction du CMMI. Et ce n’est pas une imitation du fameux
tableau de Magritte Ceci n’est pas un livre... Non : ceci est bel et bien un livre et en
français. Mais un livre en français SUR le CMMI et non le CMMI lui-même, traduit
en français. Ainsi je ne m’astreins pas à la rigueur d’une traduction fidèle ; je me
permets la latitude évoquée par le célèbre aphorisme italien « Traduttore, traditore ».
Et surtout, je peux développer les points qui me semblent importants et donner mes
interprétations personnelles, en espérant ainsi « ajouter de la valeur » tout en n’ayant
pas, rassurez-moi, à payer de TVA !
À travers les grandeurs et les misères de leur métier, les développeurs de solutions
largement dépendantes du logiciel ont découvert l’importance de mettre en œuvre une
approche centrée sur les processus. Cette prise de conscience a mené à la naissance
des modèles qui ont précédé le CMMI puis du CMMI lui-même. C’est ce que nous
évoquerons dans le chapitre sur la genèse du CMMI.
On prendra le temps au chapitre 2 de situer le CMMI par rapport à un certain
nombre de normes ou modèles. On découvrira combien se dessine déjà une saine
convergence qui activera encore plus, si besoin est, la synergie créatrice des diverses
disciplines impliquées dans des projets de développement.
Puisque le CMMI utilise une échelle graduée pour caractériser la maturité d’une
organisation ou l’aptitude d’un processus, il faut bien expliquer notre définition et
compréhension de ce concept fondamental. Le chapitre 3 traite de cette question.
Avant-propos XXVII
Certains mots prennent un sens bien particulier dans le contexte spécifique du

CMMI. Ceci peut constituer autant de pièges car, dans le langage courant, ces mots
peuvent avoir plusieurs sens et on peut être tenté de les interpréter autrement si on
ne porte pas attention. Le chapitre 4 fera les mises en garde qui s’imposent à l’égard
de la terminologie propre au CMMI.
On sera alors prêt à entrer dans l’univers du modèle lui-même en commençant par
la vue d’ensemble ou son architecture. Ce sera l’objet du chapitre 5 qui prendra le
parti éditorial de s’attarder plus particulièrement sur la représentation étagée car c’est
celle (à 80 % selon les statistiques du SEI) qui est la plus utilisée.
Puis, on découvrira les secrets de chaque niveau en décrivant la nature du niveau
en question, en expliquant les domaines de processus associés au niveau dans la
représentation étagée ; puis, pour chaque domaine, on parcourra les objectifs et les
pratiques et je donnerai mes interprétations, fruit de mon expérience sur le terrain :
• au chapitre 6, ce sera les cas spéciaux des niveaux 0 et 1 ;
• au chapitre 7, ce sera le niveau 2 ou « Discipliné » ;
• au chapitre 8, le niveau 3 ou « Ajusté » ;
• au chapitre 9, le niveau 4 ou « Géré quantitativement » ;
• au chapitre 10, le niveau 5 ou « En optimisation ».
Sans révéler de noms, et en amalgamant plusieurs expériences du terrain chez

différents clients, je présenterai de façon très concrète au chapitre 11 comment se
déroule typiquement l’histoire CMMI dans une organisation.
Au chapitre 12, nous ferons le tour des bénéfices possibles de l’application dans
une organisation. Pour rappeler un personnage coloré de la télévision québécoise pour
enfants dans les années 1970, j’espère que « les sceptiques seront confondus », sans
pour autant avoir recours à l’arme principale de ce truculent bonhomme : l’exagération
outrancière.
Je parlerai ensuite au chapitre 13 des différents usages que l’on peut faire du CMMI :
usages informels, comme d’y puiser des idées spontanées d’amélioration, et usages
formels, comme de mener une évaluation de type SCAMPI (Standard CMMI Appraisal
Method for Process Improvement).
Je conclurai en soulevant une question quasi existentielle :
« Qu’est-ce qui arrive après le niveau 5 ? »
En annexe, je proposerai une bibliographie de soutien à ce livre. Puis j’expliquerai
comment utiliser une liste d’indicateurs types pour vérifier le degré de déploiement des
pratiques du CMMI dans une organisation. Je reprendrai ensuite quelques statistiques
récentes sur le déploiement du CMMI dans le monde. Enfin, j’ai ajouté les anecdotes
savoureuses de Denise Cattan, une amie experte en ingénierie de système, qui a associé
les leçons qu’on peut tirer de ses anecdotes à différentes parties du CMMI.
Le CMMI, on le verra, est un compendium de bonnes pratiques à appliquer dans le
cadre de développement de systèmes où le logiciel constitue un composant important.
Ce compendium est bien structuré, bien organisé et vise la qualité. J’ai tout de suite
XXVIII CMMI 1.3
pensé à ces itinéraires qu’on emprunte en voiture, à pied ou en skis avec d’autant plus
de plaisir qu’ils sont bien fléchés, bien balisés. Puis Mike Konrad du SEI m’a envoyé
sa préface et cette idée du phare et la lentille de Fresnel me parut, sans jeu de mots,
lumineuse. Ceci a influencé le choix du sous-titre et de l’illustration de la couverture
de cet ouvrage.
J’ose espérer que ce livre sur le CMMI que je publie dans la langue dont je suis
fier, sachant que je ne la parle pas toujours comme elle le mérite, saura intéresser les
francophiles de ce monde technologique qui s’intéressent en même temps au CMMI.
Ma Rossinante aura ainsi connu un destin plus faste.
L’auteur,
Richard B ASQUE
Remerciements
Merci Philippe
J’ai oublié la date mais pas l’endroit. Avenue du Parc, coin Milton à Montréal, un café
en compagnie de mon ami Philippe Michelin qui vit à cheval entre Montréal et Paris
à cause de ses affaires. C’est lui qui le premier a semé dans mon esprit l’idée de ce livre.
Merci Pierre-Yves et Jean-Luc

Dans un restaurant enchanteur sur le bord du Lac Léman près de Lausanne, mon
ami Pierre-Yves Cloux, lui-même trois fois auteur chez Dunod, m’a fait franchir une
autre étape importante en me parlant de son éditeur Jean-Luc Blanc et en me mettant
en contact avec celui-ci que je rencontre quelques semaines plus tard à Paris, entre
deux avions. Jean-Luc est devenu pour moi, un guide d’une grande patience pour ma
première aventure d’écriture de livre.
Merci à Michel et à ses collègues du SEI

De son vrai nom Michael Konrad, un des auteurs principaux du CMMI au SEI, celui
que je nomme Michel est un des Américains francophiles les plus sympathiques
qu’il m’ait été donné de connaître. Sans doute sa mère française lui a-t-elle inculqué
cet amour de la langue française qui le caractérise. D’une intelligence éblouissante,
doublée d’une extrême gentillesse, Michel a piloté ma requête auprès du SEI pour
obtenir l’autorisation d’utiliser le contenu du CMMI. Il m’a aussi fait l’honneur d’une
préface fort émouvante.
Merci à tous mes clients d’Alcyonix, aux participants à mes cours

et aux membres de mes équipes d’évaluation
Chaque fois que je me suis retrouvé dans la situation de travailler avec vous, j’ai
appris à mieux interpréter les pratiques du CMMI et à faire passer l’esprit du modèle
avant la lettre quand il s’agissait de les interpréter adéquatement dans des milieux fort
différents.
Avant-propos XXIX
Merci à mes collègues de SQLI et d’Alcyonix

Vous m’apprenez constamment par vos questions qui me forcent à m’interroger sur
les explications que je prodigue sur le CMMI et me maintiennent sur ma propre
voie d’amélioration continue. Vos propres interventions sur le terrain, dont vous
avez la gentillesse de partager avec moi les leçons apprises, viennent bonifier ma
compréhension du modèle.
Merci Danielle, Catou et Nico

À ceux que je désignais en dédicace de la première édition comme les trois plus beaux
cadeaux que la vie m’ait donnés, un merci tout spécial. À mon épouse Danielle qui fut
d’une infatigable patience lorsque j’étais plongé dans mes pensées d’auteur de ce livre
et qu’elle me parlait tout en réalisant que j’étais ailleurs. À mon fils musicien et auteur
aussi, mais dans un autre medium, puisqu’il compose et connaît le stress et la joie de la
création. Il se moquait gentiment de l’écriture de ce livre en me demandant souvent si
le héros meurt à la fin. À ma fille Catherine, vive comme le printemps lorsqu’il éclate
enfin au Québec, pour avoir meublé la solitude de sa maman lors d’un merveilleux
voyage au Portugal alors que j’écrivais encore et toujours, même au bord de la piscine.
Merci à tous les membres du forum cmmi-en-francais

Par votre active et conviviale participation, vous m’avez beaucoup appris sur les
subtilités du modèle avec vos questions et vos suggestions. Vous verrez ici le résultat
de vos efforts parce que les explications sous plusieurs pratiques ont été enrichies
et améliorées. Un merci spécial à ceux qui m’ont envoyé des commentaires pour la
version 1.3 du CMMI en français.
Merci à Mike Philipps

Un autre pilier du projet CMMI au SEI ! Il nous a accompagnés, moi et Daniel Henry
de l’équipe Alcyonix, dans un projet pilote d’évaluation de cette nouvelle version du
CMMI chez un client à Vancouver. Son parti pris pour une approche pragmatique
d’un point de vue entreprise et son empathie envers les utilisateurs du modèle m’ont
toujours impressionné. Je le remercie de sa préface en 2e édition.
Merci à Denis Cattan

Un mot spécial pour Denise qui a très gentiment proposé de savoureuses anecdotes
que l’on trouvera en annexe et qui illustre à merveille les dérives qui nous guettent
quand on oublie les bonnes pratiques du CMMI.
1
La genèse d’un modèle
de meilleures pratiques
Bien que le CMMI soit devenu, au fil du temps, une famille de modèles couvrant
plusieurs « constellations » de bonnes pratiques touchant, comme on le verra, à
plusieurs catégories de disciplines1 , son histoire a commencé dans l’univers de la
discipline informatique et, encore plus spécifiquement, dans l’univers du logiciel. Cette
origine logicielle me ramène immanquablement à mes premiers pas professionnels,
comme tous ceux de ma génération (les « baby boomers » nés dans les années
cinquante) qui sont tombés dans la marmite de l’informatique naissante. L’histoire du
CMMI est donc liée étroitement à celle de l’informatique qui elle-même fait partie de
mon histoire à moi.
En effet, j’ai suivi mon premier cours d’informatique quand le mot « informatique »
venait à peine de naître. C’était l’ère fascinante des cartes perforées aux couleurs de
l’arc-en-ciel ; des lecteurs qui les avalaient à une vitesse effarante, en se bloquant
hélas souvent ; des dérouleurs de bandes magnétiques qui de loin semblaient rouler
de gros yeux comme des robots menaçants. Lors de ce premier cours d’informatique,
le lecteur de cartes perforées se trouvait dans un local situé à une cinquantaine de
mètres du centre de traitement principal. Une copine de l’époque m’avait demandé
si on avait creusé un tunnel sous la terre pour que les cartes perforées se rendent du
local du lecteur au local de l’ordinateur. Quelque temps plus tard, à l’université, je me
rappelle des voyages incessants entre la salle des perforatrices de cartes et le pigeonnier
1. En anglais, avant la version 1.3, les auteurs avaient utilisé le terme « discipline » que j’avais repris
en français. Ils désignaient ainsi un type d’activité, un créneau d’affaire, une catégorie d’organisation.
Par exemple, la « discipline » de ceux qui font du logiciel, de ceux qui font des systèmes, ou de ceux
qui font des produits matériels, etc. Avec la version 1.3, les auteurs ont remplacé le mot « discipline »
en anglais par l’expression « area of interest » ; en ce qui me concerne, je n’ai pas modifié le terme
« discipline » en français dans cette 4e édition.
2 Chapitre 1. La genèse d’un modèle de meilleures pratiques
où on récupérait les « listings » avec nos noms imprimés en gros caractères ; chaque
lettre de notre nom était composée de centaines de fois la lettre en question. C’était
l’époque hippie. Les informaticiens étaient perçus comme des êtres à part. On passait,
avec un mélange de fascination et de défi dans les yeux, dans le corridor où on avait
percé des fenêtres donnant sur ce qu’on nommait la « salle des machines », comme s’il
s’agissait d’une usine. Telle une pouponnière dans un hôpital, il y avait une barrière
infranchissable entre les gigantesques ordinateurs et nous. Si on amenait des visiteurs
avec nous, on grandissait soudain à leurs yeux, dotés du pouvoir mystérieux de parler
à ces machines bizarres.
Arrivé dans l’industrie, j’avais hérité, comme mes autres collègues étudiants, d’une
espèce d’aura magique. On admirait tout autant qu’on les craignait les informaticiens,
un peu comme les sorciers d’un village indigène. Rois et maîtres, les informaticiens
menaient la danse de l’informatisation et étendaient sans cesse leur territoire dans
l’entreprise. On les laissait faire, de peur d’attiser la colère des dieux et de voir une
armée de machines, sous leur commandement, déferler dans les bureaux. J’exagère à
peine. C’était l’âge d’or de l’informatique. Terrible responsabilité pourtant puisqu’on
infiltrait tous les rouages de l’entreprise et bientôt ses dirigeants mêmes avaient
l’impression d’être à la merci du plus humble des programmeurs.
Je ne vais pas raconter toute l’histoire des ordinateurs, rassurez-vous. Il m’aurait
d’abord fallu remonter à Pascal et il me tarde de vous causer du CMMI. Rappelons sim-
plement que l’arrivée de l’ordinateur personnel a tout bouleversé en quelques années.
Les utilisateurs de l’informatique se sont révoltés contre l’hégémonie outrancière des
informaticiens et ont remis à sa place cette discipline arrogante. Les informaticiens
sont redevenus des personnes offrant un soutien aux fonctions de l’entreprise.
Ayant repris sa vraie place, l’informatique est devenue un outil merveilleux entre
les mains des dirigeants et des utilisateurs. Ils se sont attaqués à peu près à tous les
types de problèmes et ont forcé les informaticiens à imaginer des solutions sans cesse
innovatrices. Heureusement que la technologie a suivi, ou plutôt devancé le plus
souvent, car le carrosse roulait de plus en plus vite. Concurrence, mondialisation,
rationalisation, réingénierie des processus d’affaire : le progrès avançait et avance
toujours à une vitesse croissant exponentiellement semble-t-il.
Mais il y a un grave problème à la base même de ce développement fulgurant :
les informaticiens ont mis du temps, beaucoup de temps, à faire de l’informatique
une véritable profession, une robuste discipline d’ingénierie. Tout est relatif certes. La
construction de maisons, qui remonte bien à l’homme préhistorique (parlons alors
d’abris), a eu tout le temps de devenir ingénierie en bâtiments, ponts ou chaussées.
Faut-il donc s’étonner que l’informatique qui n’a pas de racines aussi lointaines n’ait
pas encore accédé complètement au statut de profession ? Et peut-on vraiment dire
que les informaticiens sont des ingénieurs ? Depuis quelques années, certains diront
oui, sans doute avec raison. En ce sens, l’histoire de l’informatique s’est certainement
déroulée à la cadence grand V, comme celle des ordinateurs.
Pourtant si on regarde la réalité des projets informatiques, l’image est encore bien
décevante. Retards innombrables, livraisons de piètre qualité, clients mécontents,
et j’en passe, sont toujours le lot de trop nombreux projets. Des études récentes
La genèse d’un modèle de meilleures pratiques 3
confirment encore que les dépassements de budget et d’échéance affectent la majorité

des projets. Les dieux d’hier sont devenus des incapables. Monsieur et Madame
Tout-le-monde ayant maintenant son PC à la maison, on se fait fort de souligner
à grands traits que ce n’est pas si difficile que ça de répondre rapidement à des
besoins d’informatisation. N’a-t-on pas développé une application de gestion de ses
dépenses personnelles durant le week-end, avec tout plein de graphiques couleurs
et une interface tout à fait conviviale ? Alors comment se fait-il qu’au travail, notre
département informatique n’arrive pas, en 15 mois, à livrer cette satanée application
de gestion du personnel ? Cherchez l’erreur !
Malgré la crise de confiance qui secoue les relations entre les clients et les experts
de l’informatique, on ne semble plus vouloir arrêter l’invasion du logiciel. Il est
bien sûr toujours très présent dans les systèmes de gestion des entreprises. Mais on
l’a fait entrer dans la vie de tous les jours avec les guichets bancaires, Internet et
son train d’applications à domicile, et tous les appareils électroniques qui sont à la
base du divertissement maison mais aussi des tâches ménagères. Et la voiture ? On
calcule qu’une voiture ordinaire au tournant du millénaire ne comptait pas moins de
30 processeurs et cela augmente bien sûr. Alors inutile de rappeler que les avions ne
volent plus sans une multitude de processeurs, que les trains ne peuvent plus rouler
sans logiciel, que l’économie mondiale est assise sur un Himalaya de logiciels.
Il fallait donc que le besoin d’informatiser soit urgent pour continuer de foncer
tête première alors que les projets informatiques n’avaient pas encore su démontrer la
maturité voulue. Ou alors que les clients soient tous masochistes et aiment flirter avec
l’échec qu’ils savent possible voire probable. On a mesuré au début des années 2000
que dans un cahier des charges types pour une solution à un besoin le moindrement
complexe, il y a maintenant plus de la moitié des exigences qui sont finalement
traitées par le logiciel ! Le train (pensons aux plus récents TGV) qui était auparavant
essentiellement mécanique, est devenu électronique et informatique avant tout.
Des besoins sans cesse grandissants, complexes et diversifiés, confiés à des déve-
loppeurs de plus en plus anxieux de savoir que leur approche de développement est
rarement robuste, le tout sur un fond de cacophonie de changements technologiques
qui rendraient fou quiconque chercherait à simplement suivre le courant ! Sans
compter la nécessité d’intégrer en un tout cohérent des composants développés dans
des chapelles parfois bien éloignées les unes des autres : informaticiens et ingénieurs
de systèmes (mécaniques ou électroniques par exemple) ne se parlant à peu près pas.
Je ne dis pas que les progrès de la discipline informatique ont été nuls, loin de là. On
a vu les bénéfices réels de la programmation structurée (qui se rappelle de cette vogue
des années 1970 ?), de l’analyse selon des techniques de plus en plus sophistiquées, des
notions d’architecture de systèmes, des bases de données en je ne sais plus combien de
formes normales, des générateurs de code, des approches orientées objet, des outils de
génie logiciel, de la modélisation des processus d’affaire, de l’application des principes
de la gestion de projet aux projets d’informatique et de système puis des approches de
type Agile. Malgré tout, les projets souffrent encore de sérieuses lacunes chroniques.
Certains font remonter l’histoire du CMMI aux pionniers de la qualité totale :
Deming, Juran, Crosby, etc. En tout cas, il faut dire qu’un certain Watts Humphrey
s’est inspiré de ces maîtres à penser pour redresser un projet majeur qui allait marquer
l’histoire d’IBM.
Le développement du système d’opération 360 pour les ordinateurs IBM des
années soixante courait à sa perte. Des milliers de développeurs tournaient en rond et
risquaient de tourner en dérision le « Big Blue » comme on désignait alors IBM (à cause
du bleu de son logo mais aussi sans doute du complet marine que tous ses employés
masculins arboraient). Les dirigeants ont alors demandé à Watts Humphrey de prendre
le gouvernail du projet 360. Mettant en pratique les enseignements de ses maîtres
spirituels, Watts s’inspira du principe de la qualité totale pour établir une approche de
réalisation de projets basée sur une maturation des processus de développement. Cette
histoire connut une fin heureuse. Le système a marqué du sceau du succès l’histoire
d’IBM. Le sauveur Humphrey avait réussi à retourner la machine et à l’amener au port
de la qualité et de la satisfaction des clients d’IBM. Sa réputation n’était plus à faire.
Quelques années plus tard (fin des années soixante-dix), le département de la
Défense américaine (DoD) commandait une étude sur les dépenses de sous-traitance
informatique, soucieux de voir les sommes faramineuses englouties dans les projets
informatiques alors que la plupart ne donnaient pas les bénéfices espérés. Cette
étude fit scandale. Elle révélait qu’une infime proportion (moins de 5 %) des projets
confiés à des sous-traitants informatiques se terminait à temps, dans les délais,
avec le produit attendu fonctionnant adéquatement. Une grande proportion allait
carrément à la poubelle. Entre les deux, toutes les nuances de gris (surtout de gris
sombre) : projets sauvés in extremis par réinjection massive de fonds, produits modifiés
substantiellement après livraison, à grands frais, pour arriver à les faire fonctionner,
etc. Quelle horrible perte de deniers publics ! Il fallait stopper l’hémorragie.
Le DoD a décidé de créer un institut : le SEI ou Software Engineering Institute.
Il a lancé un concours auprès des universités américaines et Carnegie Mellon,
située à Pittsburgh (en Pennsylvanie) et déjà bien connue pour l’excellence de son
département informatique, remporta la mise : héberger le SEI. En 1984, on y a mis sur
pied une équipe avec le mandat de s’attaquer à la crise du logiciel. Qui d’autre que
Watts Humphrey1 pouvait sauver le bateau en péril encore une fois ? Il accepta de
diriger l’équipe qui allait créer le CMM, modèle précurseur du CMMI.
D’abord, Watts publia un article puis un livre sur cette idée que le développement
de logiciel devait s’appuyer sur des processus matures. Son équipe mit au point un
questionnaire au milieu des années quatre-vingt qui sera utilisé pendant plusieurs
années pour auditer les sous-traitants informatiques du DoD afin de déterminer « Le
bon, la brute et le truand ». Ce questionnaire eut tant de succès qu’on le reprit dans
d’autres secteurs de l’industrie aux États-Unis et bientôt dans d’autres pays. Mais les
expériences nombreuses de l’utilisation du questionnaire révélèrent un problème de
taille pour assurer la répétitivité des résultats des audits. On avait beaucoup de mal à
interpréter correctement les questions (une ou deux lignes seulement par question)
et surtout à les interpréter de façon cohérente à travers l’industrie. On a vu des
1. Considéré comme un des pères du génie logiciel, Watts Humphrey est hélas décédé à l’au-
tomne 2010.
organisations cotées niveau 3 se faire ré-auditer au niveau 1 (plus faible) quelques

semaines plus tard ! Watts et son équipe se sont attaqué à ce problème et ont publié
en 1991 la première version du modèle « Capability Maturity Model for Software »
ou « CMM for software » que l’on a pris l’habitude de désigner par SW-CMM. Une
version fortement remaniée fut publiée en 1993 : la version 1.1 qui est celle qui fut
utilisée jusqu’à la fin 2005. Pas mal pour un modèle : il a vécu douze ans et fut très
largement utilisé mondialement !
Suite à l’approche « ad hoc » de l’application du questionnaire de départ, l’équipe
a créé une méthode d’évaluation nommée SPA (pour Software Process Assessment).
Dès 1994, celle-ci fut remplacée par la méthode CBA IPI (CMM-Based Assessment
for Internal Process Improvement), pour les évaluations internes assistées et par la
méthode SCE (Software Capability Evaluation) pour les audits externes. Avec ces
méthodes plus rigoureuses que SPA, les évaluations avaient gagné énormément en
rigueur et en répétitivité ce qui a bien assis la notoriété du CMM dont l’utilisation,
couplée aux méthodes SCE et surtout CBA IPI, s’est répandue comme une traînée de
poudre à travers le monde, dans tous les segments de l’industrie du logiciel : défense,
aéronautique, télécommunications, fabrication, finance, etc.
Le succès du SW-CMM fut tel que l’industrie a réclamé un petit frère au SW-CMM
pour traiter des aspects autres que le logiciel dans les produits complexes (avions,
systèmes de défense ou communication, etc.). Les ingénieurs de système se sont mis
à la tâche, SEI et autres organismes en tête, pour bientôt publier un SE-CMM (pour
System Engineering). En même temps, ceux qui faisaient surtout de l’acquisition de
progiciels et de la personnalisation ont développé de leur côté un modèle SA-CMM
(pour Software Acquisition). La famille s’agrandissait toujours. On a bientôt réalisé le
besoin de processus de gestion du personnel. Qu’à cela ne tienne : on a créé le modèle
P-CMM (pour People). Chacun de ces modèles avait des airs de famille puisqu’ils
avaient adopté comme modèle, le modèle des modèles, le SW-CMM. Mais chaque
développement de modèle se faisait néanmoins dans sa propre chapelle. Les personnes
intéressées à faire des évaluations sur la base de ces modèles devaient se faire agréer
en fonction de schémas d’agréments différents. Les utilisateurs devaient suivre des
cours différents pour chacun des modèles. Les sociétés qui adoptaient ces modèles
avaient tendance à les traiter comme des entités distinctes. Un fort désir d’intégration
est rapidement apparu, à la fois pour des raisons d’économie d’échelle mais aussi pour
résoudre un des plus gros défis des projets de développement où se côtoyaient des
ingénieurs de disciplines multiples (dont celle du logiciel) : leur faire parler le même
langage de base, leur faire utiliser, à haut niveau, des processus communs. Après tout,
était-il vraiment utile de décrire le processus de planification de projet à la fois dans le
modèle SE-CMM et dans le modèle SW-CMM ? Et que dire de l’assurance qualité ?
De la gestion de configuration ? De la gestion des modifications aux exigences des
clients ? La redondance gênait de plus en plus. La pression d’intégrer devenait trop
forte.
En 1998, un dénouement important survint alors que les utilisateurs du SW-CMM
attendaient une version 2, fruit de cinq années de travail suite aux modifications
demandées par une communauté d’utilisateurs sans cesse croissante et fort active. Au
lieu de leur annoncer la parution de la version 2 du SW-CMM, on a annoncé à la
conférence SEPG (Software Process Engineering Group Conference) tenue à Chicago

cette année-là que le SW-CMM allait être remplacé par le modèle CMMI (avec le
« I » pour Integration). La nouvelle aurait pu être bonne si on avait demandé son avis
à cette masse qui attendait ardemment la version 2 de leur modèle préféré. Hélas, la
réaction fut plutôt catastrophique et on faillit jeter le bébé avec l’eau du bain. La vague
de réaction négative, due à la frustration des utilisateurs mal préparés à ce changement,
fut telle qu’elle se rendit jusqu’au Congrès américain. L’idée d’intégration était certes
puissante et fort à propos. Mais la manière dont on s’y est pris alors relevait du grand
guignol hélas. On a peut-être perdu quelques mois ou années pour gérer la crise qui a
hanté le SEI de 1998 à 2000.
Le temps, grand guérisseur, fit son œuvre. En 2000, après quelques versions de
travail, on publia la première version officielle du modèle CMMI. On ne se priva
de la lapider en public, surtout ceux qui avaient tant planché sur la version 2 du
modèle SW-CMM. Mais patiemment, la nouvelle équipe CMMI du SEI analysa les
récriminations et peaufina le CMMI pour publier une version 1.1 en janvier 2002.
Il fallut encore presque un an pour que s’apaise enfin le feu de la colère des tenants
du modèle SW-CMM. Il faut dire que le changement en était un d’envergure ! Au
lieu de se limiter au développement de logiciel, voilà qu’on agrandissait le domaine
au développement de système. Le logiciel n’était plus qu’un maillon, important sans
doute, mais pas le seul sujet du modèle CMMI. On regroupait, dans un seul modèle,
des pratiques communes à plusieurs disciplines. Ceux qui avaient l’impression de ne
faire strictement que du logiciel ne comprenaient pas qu’il leur eût fallu utiliser un
modèle qui allait plus loin que le logiciel (figure 1.1).
EIA Interim
Standard 731
SECM
SW- Integrated
CMM Product
Version Development
2.0 CMM
Draft C Draft
v0.98
Figure 1.1 — Les modèles ayant servi de sources au CMMI.
Au cours de la première décade de ce millénaire, le CMMI a fini par s’imposer,

même auprès de ceux qui doutaient du mérite de l’intégration des pratiques de
développement logiciel et de développement système. J’ai dû donner des dizaines et
des dizaines de cours d’Introduction au CMMI à plusieurs centaines de personnes, dans
plusieurs pays, en anglais et en français, dans des milieux aussi variés que la défense,
l’avionique, les banques, les SSII et j’en passe ! Aucun, je dis bien aucun, commentaire
négatif à l’endroit du modèle CMMI ! Des demandes d’amélioration, certes, mais pas
de critiques franchement négatives. Voilà ce qui montre bien la puissance de modèles
unificateurs ou intégrateurs. C’est aussi pourquoi je souhaitais en partager le savoir
avec les adeptes de l’amélioration de processus du monde francophone.
À la fin de l’été 2006, le 25 août plus précisément, une version 1.2 fut publiée par
le SEI en y intégrant les modifications demandées par les dizaines de milliers d’usagers.
Sans être une révolution, la version 1.2 apporta quelques changements simplificateurs.
Le nom du modèle CMMI connut cependant une modification qui préparait la venue
d’autres modèles de type CMMI. En effet, les grands utilisateurs du SEI ont convaincu
le SEI de transposer l’architecture et une grande partie du contenu du CMMI version
1.2 dans d’autres modèles de bonnes pratiques. Le SEI répondit à cette demande et
c’est ainsi que furent publiés en 2008 deux « frères » du CMMI ; un CMMI avec de
bonnes pratiques pour les organisations qui font de gros achats de biens et services et
un autre CMMI pour les organisations qui opèrent ou font la prestation de services.
On décida de nommer ces différentes instanciations du CMMI des « constellations ».
Le CMMI que l’on connaissait depuis longtemps se vit baptiser CMMI-DEV (pour
développement) et ses deux frères CMMI-ACQ (pour acquisition) et CMMI-SVC
(pour services). Tout en partageant une architecture, une terminologie et de larges
parties du contenu avec leur grand frère d’origine (DEV), ces constellations ACQ et
SVC n’étaient pas complètement harmonisées à celui-ci.
S’inscrivant tout à fait dans la logique fondamentale des boucles d’amélioration
continue, l’activité du SEI sur le CMMI se poursuivit (et se poursuit toujours).
Ainsi, en novembre 2010, peu de temps avant le Beaujolais nouveau, la plus récente
cuvée CMMI est sortie des murs du SEI avec la collaboration de la très grande
collectivité mondiale des utilisateurs du CMMI. Avec la version 1.3, le SEI a décidé de
l’harmonisation complète des trois constellations (DEV, ACQ et SVC) et en a profité
pour clarifier les attentes du CMMI au regard des plus hauts niveaux de maturité et
d’aptitude (on verra que ce sont les niveaux 4 et 5) afin de corriger certaines mauvaises
interprétations découlant des textes un peu trop flous, selon plusieurs, des explications
entourant les bonnes pratiques de ces niveaux dans la version précédente. Le SEI a
aussi eu la sagesse d’intégrer de nombreuses explications sur les rapprochements avec
les approches dites « Agiles » pour dissiper les malentendus sur les fausses oppositions
entre CMMI et Agile.
La quatrième édition de ce livre porte donc sur la version 1.3 du CMMI et traite
maintenant des trois constellations du modèle CMMI. Son champ d’application
est donc beaucoup plus vaste que celui de la constellation DEV puisqu’il aborde
maintenant les constellations ACQ et SVC en plus de la constellation DEV.
Par ailleurs, au milieu de l’année 2008, la maison d’édition Pearson Education
France, affiliée à Addison Wesley qui a toujours publié les livres CMMI officiels
en anglais, publia la traduction en français du livre CMMI complet et en obtint
l’approbation officielle de la part du SEI. J’ai eu l’occasion de participer à la révision des
textes et je proposai les traductions de mon livre chez Dunod (avec leur autorisation)
comme base pour la traduction du livre CMMI complet. Je souhaitais ainsi maintenir
la cohérence de la traduction Pearson avec celle que j’avais faite pour mon ouvrage
chez Dunod.
J’ai eu l’occasion de discuter tout au long du 2e semestre 2010 avec la maison
Pearson Education en France afin de partager mes traductions partielles du CMMI et
les résultats des travaux du comité de soutien à la traduction mis sur pied par le SEI
et auquel j’ai participé. Leur intention est de publier le CMMI-DEV version 1.3 en
français dans le format livre au plus tard à l’automne 2010 mais si possible juste avant
l’été 2010.
Tableau 1.1 — Sommaire historique.
Fin des années 1970 Étude du DoD sur les dépenses en sous-traitance logicielle
1984 Création du SEI
1987-1988 Articles et rapports de Watts Humphrey
1987 Questionnaire de maturité avec algorithme de cotation
1988 Publication de la méthode SCE
1989 Livre Managing the Software Process de Watts Humphrey
1990 Publication de la méthode SPA par le SEI
1991 Publication du SW-CMM version 1.0 par le SEI
1993 Publication de la méthode CBA IPI par le SEI
1995 Début des travaux sur SW-CMM version 2.0
1998 Arrêt des travaux sur SW-CMM et démarrage du projet CMMI
2000 Publication du CMMI 1.0
2000 Publication de la méthode SCAMPI v1.0 par le SEI
2003 Publication du CMMI version 1.1
2003 Publication de la méthode SCAMPI v1.1 par le SEI
2005 Fin du soutien du SW-CMM, CBA IPI et SCE par le SEI
2006 Publication du CMMI version 1.2 le 25 août
Publication de la constellation CMMI-ACQ et publication de CMMI-DEV

2008
(le livre complet) en français
2009 Publication de la constellation CMMI-SVC
Publication de CMMI version 1.3 dans les trois constellations (DEV, ACQ
Novembre 2010
et SVC)
2
L’étoile CMMI
dans la galaxie
des modèles
Il existe un mot spécial en anglais qui m’a amené à écrire ce chapitre ; il s’agit du
mot « Quagmire » que le Software Productivity Consortium (SPC) a utilisé dans un
article devenu vite célèbre et qui est évoqué dans un de ses séminaires sur le Web
(http://www.systemsandsoftware.org/ssci-2008038-W-P). Le Collins English Dictionary
édition 2000 donne cette définition du mot : « an awkward, complex, or embarrassing
situation » c’est-à-dire une situation bizarre, complexe ou embarrassante. Le SPC a
en effet répertorié les normes officielles ou de facto qui tournait autour de la qualité,
de la productivité et de la robustesse du développement de systèmes comprenant
un composant de type logiciel. Il en résultait un « Quagmire » que je serais tenté de
traduire par embrouillamini, ce qui me fait penser à un enchevêtrement de câbles
comme on en trouve parfois derrière son bureau si, en plus d’un ordinateur, s’y trouvent
aussi quelques périphériques. Essayons de démêler au moins quelques-uns de ces fils
qui relient le CMMI au reste du monde. Nous pourrons alors situer l’étoile CMMI
dans la galaxie.
Il importe sans doute d’abord de clarifier quelque chose de tout à fait fondamental.
Le CMMI n’est pas à proprement parler une norme puisqu’il n’est pas le fruit d’un
projet dont le résultat serait approuvé par un organisme de normalisation. C’est un
abus de langage de parler de la norme CMMI. Ou alors, il faut dire la norme de facto
ou un modèle qui est utilisé comme référentiel de facto.
Aussi, il vaut la peine de souligner que le CMMI n’impose aucune méthode de
développement particulier, aucun outil particulier, aucune technique ou technologie
particulière. Le CMMI est comme un caméléon. Il s’adapte à tout environnement
10 Chapitre 2. L’étoile CMMI dans la galaxie des modèles
technologique ou méthodologique, dans des organisations de taille tout à fait variable :

de la très grande à la très petite, dans des types d’application aussi différents que la
gestion des comptes d’épargne, le contrôle de la trajectoire d’un satellite, ou un jeu
interactif sur le Web.
Le CMMI constitue un compendium de bonnes pratiques à appliquer dans tout
projet qui veut livrer un produit à temps, dans les budgets, à la satisfaction du client
et avec une rentabilité intéressante pour le développeur ou dans toute activité de
service que l’on veut rendre avec les mêmes objectifs (rentabilité et satisfaction client).
Comment se situe-t-il donc au regard d’autres modèles ou normes ?
2.1 ISO9001:2000
Quand on pense normes dans le domaine du logiciel ou des systèmes, on pense
inévitablement à ISO/IEC (International Organization for Standardization/International
Electrotechnical Commission) ou à IEEE/EIA (The Institute of Electrical and Electronics
Engineers/Electronics Industries Association) qui assez souvent adapte les normes de
ISO/IEC pour les États-Unis. Commençons par situer le CMMI par rapport à cet
ensemble de normes en utilisant le référentiel international, donc ISO/IEC.
Boris Mutafelija et Harvey Stromberg, ont analysé le CMMI au regard de la norme
« Quality management systems – Fundamentals and vocabulary » ISO9001:2000
(http://www.sei.cmu.edu/cmmi/casestudies/mappings/pdfs/upload/iso-mapping.pdf).
Il en ressort que plusieurs des thèmes abordés sont communs aux deux référentiels. Ce
n’est pas particulièrement étonnant. Déjà en 1994, Mark Paulk, un des auteurs du
SW-CMM (ancêtre du CMMI rappelons-le), avait fait une analyse comparative entre
le modèle SW-CMM et la norme ISO9001:1994 que l’on retrouve facilement sur le
site web du SEI (http://www.sei.cmu.edu/reports/94tr012.pdf). Il en était ressorti une
grande convergence des thèmes abordés. Un des éléments du SW-CMM qui
manquait à la norme ISO était le concept d’amélioration continue. Or la version
2000 de la norme ISO a justement introduit ce concept et a donc rapproché
ISO9001:2000 du SW-CMM. Comme le SW-CMM est complètement absorbé par le
CMMI, par transitivité on pouvait donc s’attendre à une parenté assez grande, du
moins dans la philosophie et dans les sujets abordés, entre le CMMI et ISO9001:2004.
À mes clients qui s’inquiètent des investissements déjà consentis dans ISO9001 et
qui se demandent si tout cela est perdu, je dis souvent qu’au contraire tout cet
investissement sera récupéré dans le déploiement du CMMI puisque ce dernier ne
trahit pas les principes d’ISO9001.
2.2 ISO/IEC 15504

Parlons maintenant de la norme ISO/IEC 15504. Son origine remonte en Angleterre
au milieu des années quatre-vingt-dix. Un membre de la communauté ISO/IEC
a convaincu les instances de démarrer un projet nommé SPICE. SPICE devait
livrer une norme internationale unique (une seule méthode et un seul modèle)
2.3 ISO12207 11
d’évaluation de processus logiciel. Le mandat fut redéfini pour construire une norme
qui établirait plutôt les critères des méthodes d’évaluation et des modèles de pratiques.
Plusieurs méthodes pourraient ainsi devenir conformes aux critères ; plusieurs modèles
également. Le projet SPICE fut aussi responsable de mener des essais sur le terrain
avant la publication de la norme. Ce projet est formellement terminé depuis 2003
et fut remplacé par le SPICE User Group (http://www.spiceusergroup.org). Bien que
l’appellation « SPICE » ne soit plus rigoureusement exacte pour parler du modèle
qui fut livré par le projet, l’habitude est restée de désigner ainsi ce qui se rapporte à
la norme ISO/IEC 15504. Le SEI a délégué des ressources très actives dans le projet
SPICE afin de s’assurer qu’à la livraison, le CMMI et la méthode SCAMPI satisferaient
aux exigences d’ISO/IEC 15504. Il y a donc une forte convergence documentée entre
le CMMI et la norme ISO15504.
2.3 ISO12207
La formulation des pratiques du CMMI se veut la plus universelle possible. C’est

pourquoi le CMMI n’utilise pas une toponymie de cycle de vie de projet qui soit propre
au CMMI seulement. En fait, les auteurs ont utilisé le vocabulaire de cycle de vie
proposé par la norme ISO12207. Il y a donc un alignement facile pour ceux qui sont
familiers avec cette norme. Et pour ceux qui ne le sont pas, ce n’est pas vraiment un
problème puisque les phases décrites dans 12207 sont assez universellement reconnues.
2.4 ICMM
Pour les lecteurs qui seraient dans le domaine de l’avionique, il sera sans doute
intéressant de comprendre le lien entre le CMMI et le iCMM de la FFA (Federal
Aviation Administration). J’ai eu l’occasion de discuter avec Linda Ibrahim qui
pilote le projet iCMM (The Federal Aviation Administration Integrated Capability
Maturity Model) à la FAA. La préoccupation de l’intégration des pratiques de
développement de logiciel avec celles de développement de système ainsi qu’avec
celles de l’acquisition de composants hantait la FAA bien avant que le projet
CMMI prenne son envol officiellement en 1998. Le projet CMMI tardant à livrer
quelque chose qui la satisfasse, la FFA a alors entrepris elle-même son projet
d’intégration des disciplines avec son propre modèle qu’elle a nommé iCMM
(http://www.faa.gov/about/office_org/headquarters_offices/aio/library/media/FAA-
iCMMv2.pdf) À la différence du CMMI, la FAA a décidé d’emblée d’englober les
pratiques d’acquisition alors que le SA-CMM ne constituait pas une priorité pour le
projet CMMI du SEI. Ceci explique que le modèle iCMM a continué d’exister
(jusqu’à sa version 2.0) mais qu’éventuellement il s’effaça au profit du CMMI, lorsque
celui-ci, selon Linda Ibrahim, a enfin intégré totalement les pratiques d’acquisition,
avec la constellation ACQ.
2.5 ITIL
Alcyonix s’est intéressé au cours des dernières années à un autre modèle de bonnes
pratiques destinées aux activités de type opération : centre de traitement, centre
d’appels, etc. Le paradigme de base dans ce cas n’est pas le projet, avec une date
de début et de fin, mais l’activité continue, au fil de l’eau comme on trouve par
exemple dans les centres de traitement ou d’opération (avec un centre d’appel pour
le dépannage des utilisateurs). Certains de nos clients qui se trouvaient à la tête
de Directions informatiques et qui assuraient la totalité du cycle de développement
mais aussi d’exploitation ou d’opération du logiciel, en particulier dans le monde de
l’informatique de gestion (banques, assurances, etc.), ont eu besoin d’améliorer leurs
pratiques de développement mais aussi leurs pratiques d’opération pour couvrir l’en-
semble de leur mission. Dans ce cas, nous avons constaté que nos clients se tournaient
d’une part vers le CMMI pour le développement et vers ITIL (Information Technology
Infrastructure Library, http://www.ogc.gov.uk/guidance_itil.asp) pour l’exploitation ou
les opérations. Jusqu’en 2003 environ, hélas selon moi, la communauté des utilisateurs
ITIL et celle du CMMI s’ignoraient mutuellement. Curieusement, des gens du SEI,
Brian Gallagher en tête, ont publié un rapport d’interprétation des pratiques du
CMMI pour les milieux d’opération (http://www.sei.cmu.edu/reports/02tn006.pdf)
sans aucunement à cette époque faire référence à ITIL. Progressivement et heureuse-
ment je dirais, à compter de 2003, j’ai observé un éveil au CMMI dans la communauté
ITIL et vice-versa. Les communautés CMMI et ITIL ont réalisé de plus en plus
clairement qu’il y avait pas mal d’intérêt pour un rapprochement ou pour des ponts
entre CMMI et ITIL. En 2009, une équipe du SEI a franchi un jalon important dans
un projet de nouvelle « constellation » du CMMI pour couvrir les bonnes pratiques
relatives non pas au développement de produits mais à la prestation de « services »
(http://www.sei.cmu.edu/cmmi/tools/svc/index.cfm) qui aborde sensiblement le même
sujet. Plus récemment, avec la version 1.3, le SEI a achevé l’harmonisation complète
des constellations DEV, ACQ et SVC. Alors qu’avant 2009, les centres de services
informatiques (la « production ») n’avaient qu’ITIL comme référentiel de bonnes
pratiques, voici que depuis la parution de CMMI-SVC, ils peuvent maintenant trouver
dans cette constellation des bonnes pratiques tout aussi pertinentes que dans ITIL.
2.6 SA-CMM
En février 2004, le SEI annonçait la publication d’un guide d’interprétation

pour les pratiques reliées à l’acquisition de produits ou de services
(http://www.sei.cmu.edu/reports/04tn001.pdf). Ceci annonçait la fin imminente du
modèle SA-CMM qui allait être sans doute implosé dans la prochaine version du
CMMI. L’approche suivie par le SEI pour faire évoluer son modèle CMMI est celle
qu’elle a adoptée pour le SA-CMM. Le SEI demande d’abord à la communauté
désirant un ajout de domaines de processus ou de pratiques de publier un guide
d’interprétation centré sur le CMMI actuel et de mener des projets pilotes. Ceci
permet de faire la preuve des concepts et de peaufiner la définition des pratiques et
2.7 PMBOK 13
des domaines de processus. Ensuite seulement, le SEI fait l’analyse des changements
requis pour intégrer ceux-ci dans le CMMI lui-même. En fait, en 2006, le SEI
a annoncé qu’une « constellation » du CMMI était en voie de développement
pour couvrir les bonnes pratiques d’acquisition. Elle a vu le jour en 2008 et se
trouve aisément en version récemment mise à jour (version 1.3) sur le site du SEI
(http://www.sei.cmu.edu/cmmi/tools/acq/index.cfm)
2.7 PMBOK
Il y a un lien que j’aimerais voir se développer et c’est celui du CMMI avec le PMBOK
(A Guide to the Project Management Body of Knowledge), documenté par le PMI (Project
Management Institute) depuis l’an 2000. Le CMMI pourrait, selon moi, avoir des
liens beaucoup plus étroits avec ce document (http://www.pmi.org/PMBOK-Guide-
and-Standards.aspx). En effet les domaines de processus qui ont trait à la gestion de
projet dans le CMMI trouvent des échos dans le PMBOK et vice-versa. Pourtant les
deux organisations, le SEI et le PMI, n’ont jamais vraiment cherché à se rapprocher.
Dommage sans doute ! Car la convergence est possible si je me fie aux personnes
certifiées par le PMI qui assistent à mes cours CMMI et qui ne sont pas du tout
déstabilisées par les pratiques de gestion de projet que l’on retrouve dans le CMMI et
qui ont de fortes affinités avec celle du PMBOK (et du travail sur OPM3).
2.8 COBIT ET SARBANES-OXLEY (SOX)
Les scandales financiers du début des années 2000 ont suscité des réactions fortes pour
remettre à l’avant-scène des organisations des principes transparents de gouvernance et
de responsabilisation des dirigeants. Aux États-Unis, ceci s’est traduit pas la législation
proposée par messieurs Sarbanes et Oxley (SOX, http://www.soxlaw.com/) et qui est
devenue une loi affectant toute société cotée à la bourse américaine. Ce mouvement a
entraîné des émules dans d’autres pays. On se retrouve aujourd’hui avec de plus en plus
de règles obligatoires en matière de gouvernance pour les sociétés cotées en bourse à
travers le monde. Celles-ci doivent être en mesure de démontrer objectivement leur
respect de pratiques de gestion saines qui rassureraient les investisseurs et le public. Ces
règles doivent se décliner de façon concrète par des énoncés que des modèles tels que
CobiT (Control Objectives for Information and related Technology publié par Information
Systems Audit and Control Association ou ISACA, http://www.isaca.org/Knowledge-
Center/COBIT/Pages/Overview.aspx, aligné sur la gestion des risques) ont proposés
pour le domaine des technologies de l’information. Par surprenant que pour interpréter
les règles générales énoncées dans SOX, plusieurs ont adopté CobiT dans le monde
des technologies de l’information. Or voilà qu’on se rend compte que si on déploie
le CMMI, du même coup on répond à plusieurs des exigences de CobiT et donc de
SOX ! Encore un bon point pour le CMMI !
2.9 AGILE
Il serait incorrect de classer les approches de type « Agile » dans la catégorie des
normes ou des standards. Mais il importe de dissiper quelques idées incorrectes qui
brouillent les pistes des novices qui s’intéressent au CMMI et qui se font opposer Agile
comme s’il s’agissait d’une alternative. Le terme « Agile » décrit en fait un ensemble
de méthodes et techniques de développement logiciel qui respectent les valeurs et
les principes d’un manifeste plutôt succinct. Sur la base de ce manifeste, un certain
nombre de spécialistes du logiciel ont proposé des méthodes de travail et des tech-
niques qui voulaient alléger les façons que d’aucuns jugeaient trop lourdes en matière
de logiciel. Ainsi naquirent des méthodes telles que Scrum et XP (probablement les
deux plus célèbres déclinaisons du manifeste Agile). Avec le mot « Agile » comme
bannière, certains ont cru que ces approches faisaient fi de tout processus documenté
pour réaliser des projets et que ces approches signifiaient « Libres de tout processus ».
De là le raccourci : CMMI s’oppose à Agile. Heureusement, les esprits plus éclairés
tant sur le CMMI que sur les approches Agile ont réussi à expliquer que le CMMI qui
s’attarde à ce qu’il faut faire (au QUOI) ne s’oppose aucunement à Agile qui propose
un COMMENT i.e. une façon allégée (« light » diraient les Américains et... même mes
cousins de France !) de faire les choses. Agile exige des processus robustes pour faire les
choses de façon allégée mais fiable. En ce sens, Agile et CMMI sont complémentaires.
Le SEI fut sensible à cette incompréhension malheureuse entre CMMI et Agile et
a décidé dans la version 1.3 d’ajouter de nombreuses notes explicatives pour décrire
comment les pratiques du CMMI peuvent être déployées dans le respect, par exemple,
des préconisations des approches Agile.
2.10 ESCM
eSCM-SP (eSourcing Capability Model for Service Providers) et eSCM-CL (eSourcing
Capability Model for Client Organizations) à l’origine mis au point par une autre division
(comme le SEI) de l’université Carnegie-Mellon : Information Technology Services
Qualification Center (ITSqc). Cette organisation a changé de statut en janvier 2010
pour devenir une société privée qui poursuit le développement et le déploiement des
modèles eSCM qui décrivent en fait les relations client-fournisseur dans un contexte
de sous-traitance (« outsourcing »). L’avènement des constellations SVC et ACQ va
peut-être marcher sur les plates-bandes des eSCM... L’avenir le dira mais le nombre
d’utilisateurs des eSCM reste plutôt limité à la fin de 2010.
2.11 SCAMPI
J’aimerais terminer ce chapitre sur le positionnement du CMMI dans la galaxie des
modèles et de normes en parlant de ses liens avec la famille de méthodes SCAMPI
(Standard CMMI Appraisal Method for Process Improvement) publiée en 2001 par le
SEI, peu après la version 1.0 du CMMI. Au départ, le SEI avait établi une seule
2.11 SCAMPI 15
méthode SCAMPI pour analyser la maturité des pratiques d’une organisation avec
l’aide du CMMI comme référentiel cible. Puis, deux variations de la méthode ont été
publiées si bien qu’on a renommé la première SCAMPI « de classe A » récemment
mise à jour avec la version 1.3 du CMMI ; les deux autres sont SCAMPI de classe
B et SCAMPI de classe C. Bien qu’on puisse utiliser le CMMI sans les méthodes
d’évaluation SCAMPI et qu’on puisse évaluer une organisation avec des méthodes
autres que SCAMPI, ces méthodes SCAMPI demeurent celles privilégiées par le SEI
comme approches officielles permettant de faire une analyse approfondie des forces
et faiblesses du processus de développement d’une organisation au regard du CMMI.
La SCAMPI de classe A en particulier est la seule qui permette une cotation (rating)
du niveau de maturité organisationnelle ; elle est exhaustive, très cadrée et permet
un diagnostic très fiable. La SCAMPI de classe B quant à elle permet généralement
à moindre coût et plus rapidement, de caractériser le risque de ne pas satisfaire aux
exigences du modèle CMMI sans donner formellement de cotation officielle. Elle
porte typiquement sur un échantillon de projets plus restreint. On l’utilise souvent en
amont d’un SCAMPI de classe A pour déterminer le chemin qu’il reste à parcourir
avant d’atteindre un objectif donné (par exemple un niveau de maturité). La SCAMPI
de classe C, également moins coûteuse et plus rapide que la classe A, est plutôt axée
sur l’analyse de fidélité d’un référentiel de processus « sur étagère » au regard des
exigences du CMMI, sans nécessairement examiner le déploiement de ce référentiel
de processus. Soulignons enfin qu’en mai 2009, j’ai publié chez Dunod un ouvrage
sur le déploiement du CMMI qui traite abondamment de l’utilisation de la méthode
SCAMPI (voir la bibliographie).
Avez-vous bien LU ?
(Les réponses se trouvent dans le texte.)
a) Comment se fait-il qu’une organisation qui est certifiée ISO 9001 se retrouve assez
facilement dans les exigences du CMMI ?
b) Décrivez la différence fondamentale que l’on constate entre le CMMI et ITIL.
c) Comment se nomme la famille des méthodes d’évaluation développées par le SEI

sur la base du CMMI ? Décrivez brièvement la différence entre ses trois variantes.
Avez-vous bien COMPRIS ?

(Pistes de réflexion, les réponses ne sont pas nécessairement dans le texte.)
a) Si vous rencontriez le Directeur du développement logiciel d’une banque ainsi

que la Directrice du centre de traitement, à qui proposeriez-vous de déployer le
CMMI-DEV ? CMMI-ACQ ? CMMI-SVC ? ITIL ? Pourquoi ?
b) Si vous rencontrez le conseil d’administration de la même banque et qu’il

s’interroge sur des moyens de démontrer la gouvernance de leur banque, expliquez
comment le CMMI pourrait y contribuer.
c) Rassurez un copain ou une copine, chef de projet, qui a récemment reçu son certificat
du PMI et qui vient d’apprendre que sa société a choisi de déployer le CMMI-DEV.
3
Une échelle de maturité
organisationnelle
Dans sa constellation DEV, le CMMI est un compendium de bonnes pratiques de

développement de système où le logiciel constitue généralement, mais pas néces-
sairement, un composant important. Une organisation qui applique le CMMI-DEV
avec détermination voit sa maturité augmenter sensiblement et de façon mesurable,
en qualité et en productivité par exemple. On retrouve la même logique dans les
deux autres constellations du CMMI : ACQ et SVC. Simplement, elle s’applique à
d’autres disciplines: celle de l’acquisition (ACQ) ou des services (SVC). Le concept de
maturité dont il est question ici rejoint la compréhension intuitive que le lecteur aura
sans doute développée face au mot « maturité » appliquée à une personne par exemple.
Comme il s’agit d’un concept tout à fait fondamental pour le CMMI, j’ai voulu lui
consacrer un chapitre à lui tout seul. À tout seigneur, tout honneur ! La parabole
ci-après portera sur la constellation DEV (donc sur la discipline de développement de
systèmes).
3.1 LA PARABOLE DE LA VISITE CHEZ LE MÉDECIN
Le lecteur qui a vécu quelques expériences de développement de projets au sein d’une

organisation immature reconnaîtra ici les symptômes que je vais évoquer. Supposons,
pour faire image, qu’une organisation se présente chez le médecin. Comme tout
médecin désireux d’aller droit au but, il pose la question typique lorsqu’il accueille la
patiente dans son bureau : « Alors, qu’est-ce qui ne va pas ? ».
18 Chapitre 3. Une échelle de maturité organisationnelle
Figure 3.1 — J’entends ce représentant

de la Direction dans le cabinet du médecin...
Voilà l’organisation qui répond avec un trémolo d’angoisse :

« Tout, docteur ! Nos projets ne sont jamais livrés dans les délais convenus initialement.
Les dépassements sont devenus la règle. Pire : on découvre cette catastrophe seulement à la
dernière minute car notre visibilité sur la progression réelle des projets est minimale. Comme
on est obsédé par la date de livraison, il arrive parfois que le hasard nous fasse réaliser
suffisamment tôt que le délai communiqué au client ne tient pas la route. Alors branle bas
de combat ! À fond la caisse, on redirige plusieurs ressources vers le bateau en péril et on
réussit parfois à reprendre le dessus sur le calendrier menacé. Mais à quel prix ! Plusieurs
projets, ailleurs, souffriront d’une brusque ponction de leurs ressources pour sauver le navire
en péril et bientôt ceux-ci réclameront le même remède de cheval, nous entraînant souvent
dans une réaction en chaîne infernale. À force de s’agiter ainsi, on réussit tant bien que mal
à rassurer un client puis un autre mais notre rentabilité souffre de plus en plus car on arrive
mal à leur faire digérer une augmentation de coûts. Ils ont souvent été astucieux et nous
ont imposé un carcan impitoyable : un budget fixe pour un cahier des charges donné. Mais
parlons-en docteur de ce cahier des charges. Dans la précipitation de gagner ce contrat, nous
ne l’avions pas très bien analysé. Au bout de quelques jours seulement, ne voila-t-il pas que
nos analystes, brillants, découvrent que notre technologie actuelle ne permet de répondre tout
à fait aux besoins. Qu’à cela ne tienne : on n’est quand même pas pour s’avouer vaincu dès
le début du projet ! Alors hop : on fait entrer cette technologie miraculeuse dont on a vu une
démo à une conférence récente et dont on dit des merveilles. Ce n’est pas une mince tâche,
je vous assure. Mais nos techniciens sont brillants aussi et bientôt la technologie en question
ronronne comme une nouvelle voiture de sport, prête à bondir pour nous. Pour nous mais...
pas pour le client ! Lors d’une rencontre de travail, convoquée précipitamment et à laquelle
nous étions mal préparés, le client nous annonce que nous avons mal compris son besoin !
En toute bonne foi, il nous faut bien admettre qu’il a raison. Certes, les phrases du cahier
des charges étaient floues mais à la relecture, on découvre, effarés, que cette technologie
coûteuse que l’on vient d’acquérir non seulement ne peut fonctionner dans l’environnement
du client mais, de plus, était inutile à la lumière de la nouvelle compréhension des exigences !
Alors imaginez notre déconvenue... Pitoyables, nous retournons dans notre chaumière pour
nous précipiter au téléphone pour rappeler de vacances les quelques effectifs qui nous avaient
presque suppliés de les laisser partir car déjà épuisés par le dernier marathon visant à faire
entrer la nouvelle technologie. Comme ce sont de bons soldats, ils rentrent au bercail, laissant
leurs familles, qui sur la plage, qui à la montagne, promettant, comme un ivrogne, que c’est
3.1 La parabole de la visite chez le médecin 19
la dernière fois, tout en sachant hélas, on peut tout se dire docteur n’est-ce pas, que ce n’est
qu’une fois de plus et qu’il y en aura encore. Pendant ce temps, les quelques projets que nous
avons livrés ne cessent de réclamer de la chair à canon ! Ça prend des hommes sur le front ;
et des femmes aussi, certes. La guerre aux bogues n’est pas sexiste. Et les bogues sont légion !
Il faut dire, je m’en confesse docteur, que nous avions ordonné de couper court aux essais
planifiés dans nos projets, toujours pour sacrifier au dieu des délais convenus. On se disait,
pauvres naïfs, que nos brillants ingénieurs et nos brillants techniciens avaient la main habile
et avaient su d’emblée générer un produit déjà exempt de bogues. Diantre : on les paie assez
chers pour ça. Et cette idée qu’ils ont eue de passer en revue les produits d’activité : c’est
bien beau mais Dieu que ça coûte cher en temps et... le temps c’est de l’argent vous savez.
Alors, on a aussi coupé dans ces revues qui devenaient, ma foi, un peu trop tatillonnes à
mon goût. Il faut bien savoir prendre des décisions quand on finit par découvrir que notre
budget s’enfonce désespérément. Alors docteur, est-ce normal que plusieurs de mes meilleurs
employés soient au bord de la crise de nerf, que plusieurs d’entre eux aient déjà divorcé deux
fois, après avoir laissé femmes et enfants en vacances mais sans eux. Des rumeurs de départ
massif commencent à circuler. Heureusement, le marché n’est pas très bon ; on les tient en
quelque sorte prisonniers. Car je vous le donne en mille : je partirais bien moi aussi ! Ce n’est
pas joli, docteur, je le sais. Est-ce ça que vous appelez l’immaturité organisationnelle ?
Et c’est grave, dites ? »
Et le médecin de répondre...
« Hélas je le crains. Et si vous voulez bien m’écouter, ce cancer n’est pas fatal lorsqu’on
le prend à temps. Tiens, pas plus tard que ce matin, un patient qui était dans la même
condition que vous il y a deux ou trois ans revenait me voir pour son examen périodique. Il
avait fière allure je vous assure. Sa cure au CMMI-DEV l’avait radicalement changé. Mais
comprenons-nous bien, ce ne fut pas mince tâche. Surtout qu’au moment où il est venu me
voir, il était dans un état dépressif profond, au bord de la ruine, et je n’étais pas certain qu’il
serait en mesure de prendre une décision sereine sur l’opportunité de la cure CMMI-DEV
ou non. Pensez : il avait été si occupé qu’il ne savait répondre à aucune de mes questions. Il
ne savait pas me dire depuis combien de temps il souffrait de dépassements budgétaires, de
quel ordre de grandeur, à partir de combien de bogues en surplus par rapport aux attentes les
clients devenaient-ils insatisfaits ; rien de tout ça. Aucune mesure fiable ! Alors comment
le convaincre objectivement, rationnellement en essayant de lui décrire les avantages qu’il
aurait à suivre la cure CMMI-DEV. Je ne pouvais pas lui donner des chiffres sur la base
des siens, inexistants ! Alors j’ai fait comme pour vous. Je lui ai parlé de mes autres patients
désespérés avec qui j’avais réussi, mais je devrais dire, qui avaient réussi avec mon soutien à
se sortir de l’auberge de la mort. »
Vous le regardez, encore un peu sceptique mais plein d’espoir : « Alors je ne suis pas
le seul ? Vous voulez bien me dire il est comment ce patient que vous avez vu ce matin ? »
Petit sourire aux lèvres du médecin qui se réjouit de votre intérêt...
« Je vous l’ai dit, il avait fière allure ! Quasiment aucun de ses projets n’excède les
délais et les budgets convenus. Il met un peu plus de temps au début des projets pour
bien comprendre les cahiers des charges et il s’en réjouit. Combien d’ambiguïtés ont pu
ainsi être résolues sereinement, en dehors de toute crise ! Chaque projet est suivi par un
comité de projet qui demande un rapport d’avancement périodique, se donnant ainsi une
bonne visibilité sur les travaux en cours. Les alarmes sont encore fréquentes mais au moins
elles se déclenchent tôt et on sait réagir avant que le feu n’ait envahi tout le quartier. Les
vacances sont redevenues ce qu’elles doivent être : une occasion de décrocher sans craindre
les représailles ou les lendemains qui déchantent. On peut sentir, dit-il, une joie de vivre chez
les gens qui travaillent chez nous. Alors que nous pensions que la cure CMMI-DEV allait
nous coûter les yeux de la tête sans rapporter les bénéfices pour satisfaire nos actionnaires,
on a pu démontrer, chiffres à l’appui, que la somme investie a rapporté cinq fois plus en deux
ans ! Inutile de dire que c’est maintenant au tour des actionnaires de réclamer la poursuite de
nos efforts CMMI-DEV. Si vous pensez qu’on va lâcher : ce serait de la folie ! Nos clients
se demandent ce qui nous arrive. Ils ont repris confiance et nous redonnent des commandes
alors qu’ils avaient commencé à jeter du lest dans les dernières années. Concrètement,
on recrute maintenant régulièrement et notre profitabilité a augmenté avec notre chiffre
d’affaires. Comment saurais-je jamais vous remercier, docteur, de nous avoir remis en état
de maturité organisationnelle ? »
3.2 LA PARABOLE DU TRAJET EN VOITURE

Imaginons que vous arrivez dans un pays qui vous est totalement inconnu. Vous devez
rencontrer un client important. Vous êtes arrivés à l’hôtel le dimanche soir et on vous
remet à la réception une enveloppe contenant un message de votre client.
Vous lisez : « Rendez-vous lundi à 9 h à nos bureaux. Nous sommes situés au centre-ville.
C’est un gratte-ciel d’une vingtaine d’étages en verre, et au sommet, notre nom en lettres
géantes. » Vous regardez dans l’enveloppe à nouveau : c’est tout ! Vous vous informez
mais on vous répond ne pas connaître cette société. Pas étonnant : elle vient tout juste
de s’implanter ici ! Votre hôtel est tout près de l’aéroport et le centre-ville est à une
vingtaine de kilomètres. Mais il y au moins vingt entrées possibles dans la ville et il y
a au moins une centaine d’immeubles en verre de 15 à 45 étages ! C’est ce que vous
découvrez, atterré, en feuilletant le magazine touristique dans votre chambre. Inutile
d’appeler : ils ouvrent à neuf heures, qui est précisément l’heure de votre rendez-vous
lundi matin. Mais votre engagement à répondre aux besoins du client ne peut souffrir
de manquer ce rendez-vous crucial. Alors vous allez réussir... presque ! Vous vous levez
à l’aurore, espérant pouvoir entrer en ville avant les bouchons. Mais vous ignorez tout
des habitudes locales et les bouchons sont déjà commencés. Vous avez pris 3 heures de
marge alors vous restez calme. Il est 8 heures quand vous entrez enfin en ville par la
porte que votre intuition vous a suggérée : on voit déjà les gratte-ciel et ils semblent
concentrés dans cette zone. Mais quelle zone ! Et comment visualiser le sommet des
édifices depuis votre voiture ! Vous garez votre voiture dans le parking de l’un d’eux
et vous prenez l’ascenseur jusqu’au sommet. Il est 8 h 45. On peut observer la ville du
haut des airs et avec des jumelles vous repérez en grosses lettres le nom de la société
que vous cherchez. Vous demandez au gardien de sécurité de vous identifier l’immeuble
en question. Vous sautez dans un taxi et vous arrivez... à 10 h 30 car le taxi a fait de
son mieux mais les bouchons intra-muros sont encore pires après 9 heures. Vous voyez
le regard courroucé de votre client : allez-vous lui dire qu’il aurait dû vous donner
de meilleures indications et vous faire dire : « Alors c’est le bouquet ! C’est de notre
3.3 Le CMMI au regard de ces paraboles 21
faute ! » ? Vous fonctionnez dans un environnement immature et sur une échelle de

maturité, vous en seriez au tout début : au niveau 1, le niveau Initial.
On rembobine le film et on reprend alors que vous ouvrez l’enveloppe. Elle contient
aussi des instructions pour vous rendre à leurs bureaux : prendre telle autoroute, telle
sortie, tourner ici puis là. Des directions claires quoi ! En les suivant à la lettre, vous
arrivez à bon port et à l’heure. Vous fonctionnez déjà dans un environnement plus
mature et sur une échelle de maturité, vous en seriez au niveau de maturité 2. Muni
des indications précieuses, de votre processus documenté, vous savez répéter l’exploit
de vous rendre à l’endroit convenu, à l’heure et avec la consommation d’essence
prévue. Et votre client est ravi de vous voir arriver. Vous êtes discipliné ! Vous le
saviez déjà ! Mais comme vous êtes sur place pour quelques mois, il peut vous arriver
quand même de tomber sur une situation inattendue : accidents, sortie d’autoroute
fermée, etc. Alors, sans autres informations, vous êtes de retour à votre bon vieux
comportement de niveau 1 hélas.
Bien sûr, vous avez déjà entrevu la solution de niveau 3. Avoir un plan et vous faire
un parcours ajusté. Et attention, pas n’importe quel plan. Vous avez interrogé, tous
les employés qui ont fait le trajet depuis l’aéroport où se trouve votre hôtel et vous
avez capitalisé. Puis vous avez ajusté votre trajet particulier tout en sachant que si un
pépin survenait, vous avez un trajet alternatif ! Les risques de non-respect des délais
sont beaucoup plus faibles qu’au niveau de maturité 2. La capitalisation associée à la
personnalisation ou l’ajustement (certains diraient customisation) vous a fait gagner
des points !
Nous avons oublié de mentionner que depuis le début vous avez noté dans un
petit calepin toutes sortes de mesures précieuses sur vos parcours, les durées, les
distances, votre consommation. Quand votre client vous donne à son tour des données
statistiques issues de la base de données maintenue par l’ensemble des employés, vous
êtes en mesure d’appliquer une gestion quantitative et utiliser les informations
précises pour améliorer encore plus votre performance et stabiliser celle-ci en prenant
les parcours les plus indiqués. Vous fonctionnez au niveau 4.
Au bout de quelque temps, vous attendez à un feu rouge mal synchronisé avec
le reste des feux rouges. Une pub à la radio vante les mérites d’une société qui est
en optimisation constante et une idée brillante surgit en votre esprit en ébullition.
Vous aussi vous allez être dans ce mode d’optimisation. Vous allez soumettre une
requête pour synchroniser ce feu. Et puis vous verrez ensuite si d’autres améliorations
ne permettraient pas de prévenir les dépassements d’horaire convenu. Vous voilà dans
cet état de nirvana : vous surfez sur les vagues enivrantes du niveau 5 !
3.3 LE CMMI AU REGARD DE CES PARABOLES
Dans ses trois constellations (DEV, ACQ et SVC) CMMI propose deux représenta-
tions du même ensemble de bonnes pratiques. On verra au chapitre 5 que ces pratiques,
avant d’être globalement examinées selon ces deux visions ou représentations, sont
d’abord groupées par « domaines de processus » (ex. : planification, assurance qua-

lité, etc.). Ces domaines à leur tour sont groupés différemment dans chacune des
deux représentations. L’une des représentations est centrée sur un ENSEMBLE de
domaines de processus qu’on améliore de façon groupée, collectivement, dans toute
l’organisation. Dans cette approche que l’on nomme ÉTAGÉE, le CMMI propose
une amélioration progressive de la maturité organisationnelle en cinq paliers, du
niveau de maturité 1 au niveau de maturité 5 et chacun compte un certain nombre de
domaines de processus à satisfaire (i.e. à institutionnaliser selon l’esprit des pratiques
décrites dans le CMMI).
Gestion de la performance organisationnelle

5 Analyse causale et résolution
(2)
22 domaines de processus répartis Performance du processus organisationnel

4 Gestion de projet quantitative (2)
sur les 5 niveaux de maturité
Développement des exigences
Solution technique
Intégration de produit
Vérification
Validation
3 (11)
Focalisation sur le processus organisationnel
Définition du processus organisationnel
Formation organisationnelle
Gestion de projet intégrée
Gestion des risques
CMMI Analyse et prise de décision
Gestion des exigences
Planification de projet
Surveillance et contrôle de projet
Gestion des accords avec les fournisseurs (7)
2 Mesures et analyse
Assurance qualité processus et produit
Gestion de configuration
Figure 3.2 — CMMI en représentation étagée dans la constellation DEV.
Dans la représentation CONTINUE, le CMMI nous propose aussi une progression

mais cette fois axée sur CHACUN des domaines de processus (ex. : Planification de
projet, Assurance qualité processus et produit, etc.) pris individuellement (par silo ou
par cheminée si on veut prendre une image concrète). On parlera alors d’améliorer
l’aptitude d’un processus et l’échelle d’aptitude sera similaire à l’échelle de maturité
à une différence près : il y a un niveau zéro ! Dans la représentation continue, quand
on améliore quelques domaines de processus en parallèle, chacun dans son silo, on
doit utiliser un graphique de profil à colonnes, chaque colonne correspondant à un
domaine de processus.
Les statistiques semestrielles publiées par le SEI sur la durée des passages d’un
niveau à un autre (http://www.sei.cmu.edu/cmmi/casestudies/profiles/cmmi.cfm)
montrent qu’il faut compter environ 18 à 30 mois pour qu’une organisation
« décolle » du niveau de maturité 1 et atteigne le niveau de maturité 2 ; puis environ
deux ans par niveau de maturité subséquent.
3.3 Le CMMI au regard de ces paraboles 23

(2)
22 domaines de processus répartis Performance du processus organisationnel

4 Gestion de projet quantitative (2)
sur les 5 niveaux de maturité
Gestion technique de l’acquitition
Vérification de l’acquisition
Validation de l’acquisition
3 (9)
Gestion de projet intégrée
Gestion des risques
Analyse et prise de décision
CMMI Gestion des exigences

Gestion de l’accord
Développement des exigences de l’acquisition (9)
Planification de projet
Surveillance et contrôle de projet
Sollicitation et développement de l’accord avec les fourmisseurs
2 Mesures et analyse
Figure 3.3 — CMMI en représentation étagée dans la constellation ACQ.

(2)
Performance du processus organisationnel
24 domaines de processus répartis 4 Gestion de travail quantitative (2)
sur les 5 niveaux de maturité Gestion de la capacité et de la disponibilité
Résolution et prévention des incidents
Continuité de service
Développement du système de service
Transition du système de service
3 Gestion stratégique du service (12)
Gestion de travail intégrée
Gestion des risques
CMMI Analyse et prise de décision
Gestion des exigences
Prestation de service
Planification de travail (8)
Surveillance et contrôle de travail
2 Gestion des accords avec les fournisseurs
Mesures et analyse
Figure 3.4 — CMMI en représentation étagée dans la constellation SVC.

Les domaines de processus en représentation continue : avant tout des profils !
PA
PA1 1 PA22
PA PA
PA3 3 PA
PA
44
L5
L5
L4
L4
L3
L3
L2
L2
L1
L1
L0
L0
Figure 3.5 — Une illustration du concept de la représentation continue.
Certes plusieurs facteurs peuvent influencer cette durée. Le tout premier d’entre
eux est l’engagement de la Direction. Une Direction convaincue, déterminée et
constante donnera une impulsion soutenue et fera avancer toute l’organisation plus
vite. Une portée bien focalisée, des ressources financières, humaines et matérielles
mises à disposition en quantité suffisante, une bonne communication, etc. sont autant
de facteurs qui agiront comme accélérants.
On discutera plus longuement des représentations étagée et continue au chapitre 5
alors que nous présenterons l’architecture du modèle. Retenons pour l’instant qu’il n’y
a pas de représentation préférable à l’autre dans l’absolu. Le choix sera déterminé par
les besoins de focalisation propres à chaque organisation.
3.4 TRONC COMMUN ET PARTIES SPÉCIFIQUES

DANS LES TROIS CONSTELLATIONS DU CMMI
Dans les trois illustrations des constellations (DEV, ACQ et SVC) du CMMI
(figures 3.2. 3,3 et 3.4), le lecteur attentif aura remarqué que la majorité des domaines
de processus se retrouvent dans chacune des trois constellations. Il y a en effet un
tronc commun assez volumineux au sein de chacune des trois constellations. Signalons
que toutes les fois où on retrouve le mot « Projet » dans les noms de domaine des
constellations DEV et ACQ, on y substitue le mot « Travail » dans les domaines de
processus de la constellation SVC. Examinons cela de plus près.
3.4 Tronc commun et parties spécifiques dans les trois constellations du CMMI 25
Figure 3.6 — Les domaines de processus du tronc commun

et les domaines de processus propres à chaque constellation
Dans les chapitres 7 à 11 de ce livre, nous allons présenter les différents niveaux
de maturité et les domaines de processus qui s’y rattachent. Nous n’allons pas détailler
les processus des constellations ACQ et SVC mais allons plutôt nous attarder sur la
constellation DEV. Toutefois, en annexe, nous allons donner la traduction en français
des domaines de processus (les parties intentions, objectifs spécifiques et pratiques
spécifiques) propres aux constellations SVC et ACQ.
26
Figure 3.7 — Les domaines de processus du tronc commun et les domaines de processus propres à chaque constellation (suite)
Chapitre 3. Une échelle de maturité organisationnelle
3.4 Tronc commun et parties spécifiques dans les trois constellations du CMMI 27
Avez-vous bien LU ?
a) Donnez au moins un exemple concret de ce qui change dans une organisation qui
passe du niveau de maturité 1 au niveau de maturité 2.
b) Donnez au moins un exemple concret de ce qui change dans une organisation qui
c) Donnez au moins un exemple concret de ce qui change dans une organisation qui
d) Donnez au moins un exemple concret de ce qui change dans une organisation qui
e) Nommez au moins un domaine de processus par niveau de maturité.

a) Racontez dans vos mots comment l’expérience de peindre les murs de votre
maison ou appartement pourrait évoluer du niveau de maturité 1 à 5 ?
b) Si nous étions le 1er décembre 2011, serait-il possible pour une organisation de se
faire confirmer au niveau de maturité 3 du CMMI le 1er juin 2012 ? Expliquez.
4
Terminologie particulière
au CMMI
En 1995, j’ai piloté la francisation du SW-CMM. Ce fut un défi passionnant qui

m’a fait découvrir tous les ressorts extraordinaires de la langue et des mots. Aussi
les pièges que cachent les mots. Je me rappelle de l’expression « Caractéristiques
communes » par laquelle nous avions traduit l’anglais « Common features ». Une fois
que l’expression est adoptée par les auteurs d’un ouvrage, elle en devient prisonnière.
On ne peut plus utiliser l’expression ou le mot à d’autres fins, tant que l’on se trouve à
l’intérieur du périmètre de l’ouvrage. Essayez d’écrire un livre de 700 pages (environ
le nombre de pages du SW-CMM à l’époque) sans utiliser les mots « Caractéristiques
communes » ailleurs que là où la version anglaise du SW-CMM utilisait « Common
features ». Et que dire de mots encore plus courants utilisés dans cette ancienne cuvée
SW-CMM : buts, pratiques, secteurs ? Entre les mains des créateurs d’un ouvrage tels
que le SW-CMM, ils devenaient des esclaves à qui on ne permettait aucune autre
permission que celle de désigner « goals », « practices », « areas » du SW-CMM en
langue de Shakespeare (mais je devrais dire de Tennessee Williams, par exemple,
puisque l’américain est parfois bien éloigné de l’anglais britannique ; je m’attarderais
d’ailleurs si je poursuivais sur cette lancée et décrivais par exemple les incessants
débats entre Québécois et Français sur les mots managers et gestionnaires).
Voilà que le CMMI va créer aussi ses mots prisonniers. Aux lecteurs du modèle, ils
vont se présenter avec un sens bien précis. On va demander au lecteur de ne plus les
utiliser à d’autres fins que de désigner précisément et uniquement l’objet ou le concept
auquel on les a assignés. Soyez prêts, lecteurs du CMMI, à ne plus utiliser à d’autres
fins que ceux prévus par les auteurs du CMMI les mots discipline1 , maturité, aptitude
et beaucoup d’autres. Ce chapitre vise à guider le lecteur dans ce labyrinthe des mots
particuliers du CMMI.
1. Voir la note de bas de page en première page du chapitre 1.

30 Chapitre 4. Terminologie particulière au CMMI
4.1 ORGANISATION
Le CMMI se présente comme un compendium de meilleures pratiques appliquées

par une organisation. En français, on utilise le mot « organisation » parfois pour
parler de toute une société ou de l’une de ses entités et parfois de la façon dont on
va agencer des composants d’un tout. Il faudra vous habituer dorénavant, dans le
contexte du CMMI, à réserver le mot « organisation » au périmètre à l’intérieur duquel
on déploie une action d’amélioration de processus. L’organisation peut correspondre
à toute une société, à une division de celle-ci, ou à un sous-ensemble d’une entité
administrative. C’est le territoire sur lequel on cherche à déployer des processus
fidèles à l’esprit du CMMI. Si on trouve l’expression « directive organisationnelle » ou
« processus organisationnel » ou « au niveau de l’organisation », on ne veut pas dire au
niveau de la société dans son ensemble, quoique cela puisse arriver puisque le périmètre
de l’organisation au sens du CMMI peut parfois correspondre à toute la société. Mais
pas nécessairement. Le plus souvent, on vise un territoire plus restreint : un site, une
division, une ligne de produits.
4.2 PROJET ET TRAVAIL
Dans la constellation DEV, le CMMI s’applique en grande partie dans le contexte

d’un projet. Dans les autres constellations, ACQ et SVC, il y a aussi des aspects
qui se déroulent sous forme de projets. Bien que certaines pratiques (par exemple, la
publication d’une directive organisationnelle ou l’organisation du plan de formation
organisationnel) soient du ressort d’une unité organisationnelle c’est-à-dire dont
le travail profite à toute l’organisation, la plupart des pratiques doivent s’exercer à
l’intérieur d’un projet. Il y a cependant une variante importante dans la constellation
SVC dédiée à l’élaboration et la prestation de services. Dans ce cas, plusieurs pratiques
s’exercent sur une activité continue qui n’a pas de date de fin prévisible ; dans ce cas
particulier, le modèle remplace le mot « Projet » par le mot « Travail ». Ainsi, le nom
de domaine « Planification de projet » dans DEV et ACQ devient « Planification du
travail » dans SVC.
Il peut sembler facile de se rallier à une compréhension commune du mot « projet ».
Pourtant, l’expérience des évaluations dans de nombreuses sociétés m’a appris que
la question « Que voulez dire par le mot projet ici ? » est l’une des toutes premières
qu’un évaluateur CMMI doit poser lorsqu’il arrive dans un site à examiner. Certains
font naître un projet après l’acceptation d’un cahier des charges, alors que beaucoup
d’activités ont déjà pris place en amont (par exemple, étude d’opportunité) et ont
consommé des charges d’intervenants de la société. D’autres initient un projet dès la
réception d’une demande, même peu formalisée, d’un client. La façon la plus simple
de comprendre la notion de projet se résume à dire qu’il s’agit d’une activité visant à
livrer un produit à un client et qui se déroule sur un calendrier donné en mettant en
scène une équipe avec son chef d’équipe (qu’on appellera chef de projet) qui dispose
d’un budget donné.
4.3 Manager et gestionnaire 31
Sachant que le CMMI couvre la discipline de l’ingénierie logicielle tout autant

que l’ingénierie système ou l’élaboration/prestation de services, le projet peut donc
couvrir un ensemble très varié d’activités et peut mettre en scène des intervenants de
profils également très variés. La couverture de la notion de projet s’arrête pourtant aux
limites d’un calendrier donné avec une date de début et une date de fin. Ainsi, on ne
peut mettre sous le chapeau de « projet » l’activité qui consiste à maintenir au cours
de sa vie active un produit qui connaît des ratés occasionnels, ce que l’on nomme
parfois « la petite maintenance » ou « la maintenance corrective » ou le « debugging ». Ni
les tâches, importantes pourtant, du soutien à l’exploitation ; par exemple, la gestion
d’un centre de traitement. Pourtant, ce sont là aussi des préoccupations majeures de
la Direction de sociétés qui développent et exploitent aussi, parfois, des produits ou
des services. Elles trouveront alors leurs repères dans la constellation SVC du modèle
CMMI car la constellation DEV s’interprète mal dans un contexte d’activité continue
qui n’a pas de date de début ou de date de fin ; par exemple, les activités d’un centre
d’appels. De même, le CMMI-DEV s’applique mieux dans des projets qui ont une
certaine durée. Un « bug » que l’on détecte en production au cours de la nuit et que
l’on corrige au petit matin connaît un cycle de vie si court que le CMMI-DEV n’a pas
vraiment le temps de l’intercepter !
Dans les évaluations que j’ai réalisées, j’ai eu pourtant à intégrer des activités de
maintenance en continu. Mais alors, j’ai proposé le cadre suivant : chaque application
maintenue fera l’objet d’un « projet » qui débute au début de l’année financière de
l’organisation et qui prend fin à la date de clôture de l’année financière. On a ainsi
des projets d’une durée d’un an sur lesquels on affecte une équipe et un chef de projet.
Les pratiques du CMMI-DEV se déclinent alors généralement bien. Mais de là à faire
entrer le chameau de l’exploitation par le chas du CMMI-DEV, il y a un pas que je ne
franchis pas. Je me tourne alors vers la constellation SVC qui cadre beaucoup mieux
avec ce type d’activités.
Plus globalement, fuyons l’intégrisme et disons bien que le CMMI n’est pas le seul
modèle de bonnes pratiques de l’univers. Un certain George Box disait : « Tous les
modèles sont faux ; certains sont utiles » en référence au fait qu’un modèle n’est qu’une
abstraction de la réalité, une abstraction que notre pauvre esprit humain se donne
pour mieux appréhender une réalité trop complexe à aborder dans sa nature même. Le
CMMI en ce sens est faux. Mais il est drôlement utile pour comprendre les défis du
développement ou de l’acquisition de produits et/ou de services !
4.3 MANAGER ET GESTIONNAIRE

J’ai déjà évoqué avec humour et nostalgie les batailles épiques du projet de francisation
du SW-CMM autour du mot « manager » que nous, québécois, remplaçons par
« gestionnaire », au grand dam de nos cousins « français de France » comme on aime
appeler les Gaulois. Comme un certain général, j’élèverais les bras comme le fait
mon tire-bouchon préféré et je dirai « Français : je vous ai compris ! ». Me voilà
crypto-français et je me surprends, même au Québec, à dire « manager », avec un
accent un peu pointu dont je finis par hériter quand je dépasse trois semaines de séjour
à Paris. Un gars se tanne, comme on dit au Québec, de se faire dire « Vous dites ? »
quand il utilise le mot « gestionnaire ». Dans le CMMI, le mot management désigne
parfois l’action de manager et parfois les gens qui managent. Oh que ces mots me
semblent bizarres tout à coup, conjugués, accordés en genre et en nombre. Mais jusqu’à
la lie : poursuivons ! Il arrive parfois que je ne résiste pas au besoin d’utiliser une autre
tournure. Ainsi la pratique générique GP2.10 dit, en anglais, « Review the activities,
status, and results of the process with higher level management and resolve issues ». J’ai
traduit : « Passer en revue avec la hiérarchie les activités, le statut et les résultats du
processus et résoudre les problèmes. » Je n’ai pu souffrir de dire « avec le management de
niveau supérieur ».
4.4 CHEF DE PROJET
Dans le contexte du CMMI, on parlera du chef de projet (project manager en anglais ;

amis français, admettez qu’ici vous adoptez facilement la désignation « chef de projet »
plutôt que « manager de projet ») comme celui qui dirige l’équipe de projet. Son rôle se
trouve au cœur de nombreuses pratiques du modèle : on le désigne notamment pour
préparer le plan de projet et pour faire la surveillance du projet. Pas nécessairement
seul. Certes, il peut être assisté d’un bureau de projets.
4.5 GROUPE
Tant qu’à personnaliser le débat et parler de responsables de niveau supérieur et des

chefs de projets, j’aimerais faire une précision qui semble anodine mais qui a une
importance très grande, surtout pour les petites organisations. À chaque fois que le
CMMI réfère à un groupe de personnes, rappelons qu’il peut s’agir d’un groupe d’une
seule personne, voire d’une seule personne à temps partiel ! Ainsi, une seule personne
peut porter plusieurs chapeaux, rendant ainsi possible le déploiement du CMMI dans
de toutes petites boîtes.
4.6 REPRÉSENTATION, NIVEAU, MATURITÉ

ET APTITUDE
Le chapitre suivant porte sur les « représentations » et ce terme sera amplement

expliqué. On en a d’ailleurs déjà parlé un peu au chapitre précédent. On y a expliqué
qu’on désigne ainsi l’une des deux façons (« étagée » ou « continue ») d’envisager
les centaines de pratiques du CMMI et de les regrouper en fonction de deux types
d’architecture. Les deux architectures, qui se nomment « représentations » dans le
CMMI, utilisent un concept de progression par « niveau » (en anglais level) qu’on
pourrait associer à la notion de stade de la vie humaine.
4.7 Nomenclature des niveaux 33
Dans le cas de la représentation étagée, les niveaux visent à décrire l’organisation

dans son ensemble et on dira alors que ce sont des niveaux de MATURITÉ orga-
nisationnelle (tout comme on dit, pour parler du niveau de maturité globale chez
l’homme : la petite enfance, l’enfance, l’adolescence, etc.). En pratique, on écourte
souvent et on dit simplement « niveau de maturité N » ou « maturité de niveau N »
sans nécessairement ajouter le mot « organisationnelle » qui est sous-entendu. L’échelle
utilisée pour les niveaux est alors qualifiée d’échelle de maturité.
Dans le cas de la représentation continue, les niveaux visent plutôt à décrire
un aspect particulier (un domaine de processus) de l’organisation ; on verra dans le
chapitre suivant que l’architecture du CMMI groupe les pratiques, que ce soit en
représentation continue ou étagée, sur un peu plus d’une vingtaine de « domaines
de processus ». La notion de niveau en représentation continue porte sur un seul
domaine de processus à la fois (c’est ce que je veux dire par aspect particulier de
l’organisation). En anglais, les auteurs ont choisi le mot « capability » au lieu de
« maturity » et parlent donc de « capability level » dans la représentation continue
au lieu de « maturity level » déjà utilisée avec la représentation étagée. Bien que dans
l’ancêtre du CMMI, le SW-CMM, on avait utilisé le mot français « capacité » pour
traduire « capability », j’ai opté pour le mot « aptitude » qui est traduit mieux, à la
réflexion, le concept de « capability » développé par les auteurs dans le CMMI. Si
bien que dans la représentation continue on parlera du « niveau d’APTITUDE du
domaine de processus » sur une échelle d’aptitude et non de maturité, terme réservé à
la représentation étagée.
4.7 NOMENCLATURE DES NIVEAUX
J’avouerai bien candidement que les auteurs du CMMI m’ont déçu quand ils ont
nommé les différents niveaux de maturité organisationnelle dans le CMMI de
représentation étagée ou des différents niveaux d’aptitude de processus dans le CMMI
de représentation continue. Et ils m’ont créé de sérieux soucis de traduction ! Sans
compter que les auteurs dans la version anglaise d’origine ont utilisé des termes
communs pour les niveaux 2 et 3 dans les deux représentations mais des termes
différents pour le niveau 1 ! Passons en revue les mots en question.
Niveau d’aptitude 0 : Incomplet

Dans la représentation étagée, une organisation débute au niveau 1 ; il n’y a donc pas
de niveau de maturité 0. Dans la représentation continue, comme elle ne focalise que
sur un seul domaine de processus à la fois, il fallait pouvoir évoquer le fait qu’il est
possible qu’un domaine de processus ne soit même pas fait de façon basique. Pensons
à une organisation qui ne ferait aucune assurance-qualité : eh oui, ça arrive ! Il y
a donc un niveau d’aptitude zéro dans la représentation continue et il se nomme
« Incomplet ».
Niveau de maturité 1 : Initial/Niveau d’aptitude 1 : Basique

Dans la représentation étagée, une organisation débute au niveau 1 ; il semble donc
normal de dire que ce niveau de maturité organisationnelle est le point de départ
donc il est nommé « Initial ». Mais dans la représentation continue, ce niveau n’est
pas le point de départ puisqu’il existe un niveau d’aptitude 0 ! Les auteurs n’ont pas
pu, logiquement, qualifier le niveau d’aptitude 1 d’initial. Ils voulaient exprimer le
fait que le processus a déjà progressé en aptitude mais se trouve à un faible degré de
sophistication ; ils ont utilisé en anglais le mot « Performed ». Je m’excuse à l’avance
de ma prétention auprès de ces très respectés et très respectables auteurs, mais il m’a
semblé plus juste de traduire par « Basique » ce niveau 1 d’aptitude.
Niveau de maturité ou d’aptitude 2 : Discipliné

Pour les niveaux 2 et 3, que l’on soit en représentation étagée (niveau de maturité)
ou en représentation continue (niveau d’aptitude) on utilisera les mêmes noms de
niveau.
« Managed » disent les auteurs pour caractériser le niveau de maturité 2 ou le
niveau d’aptitude 2. Aurais-je dû traduire par « géré » ou « managé » ? Quand j’ai
réfléchi à ce que les auteurs voulaient véhiculer, je me suis rendu compte que le mot
« managed » voulait en fait englober les dix exigences enfouies dans les dix pratiques
génériques de niveau 2. Et ces dix exigences ou critères font passer de l’indiscipline à
la discipline. J’ai donc opté pour le mot discipliné pour le niveau de maturité 2 ou le
niveau d’aptitude 2. Ma foi, j’aurais aimé que les auteurs aient aussi choisi un tel mot
en anglais (disciplined) plutôt que le mot « managed » que l’on a tendance à traduire et
à percevoir comme « géré » plutôt que « le fait d’appliquer les dix critères de niveau 2 ».
Certes, le mot discipline doit être pris ici de façon très positive ; il s’agit d’une bonne
« discipline » et non d’abus de pouvoir !
Niveau de maturité ou d’aptitude 3 : Ajusté

Dans l’original en anglais, c’est encore pire au niveau 3. Les auteurs ont opté pour
le terme « Defined ». Alors là, messieurs, dames, vous n’avez pas, sauf votre respect,
fait fort. Je vous mets au défi de demander à cent personnes, anglophones comme
francophones, ce que veut dire le mot « Defined » ou « Défini » et de trouver vraiment
le sens qu’ont voulu y donner les auteurs. En général, quand on dit « défini » on pense
à « énoncé » et « documenté », ce qui est déjà inclus dans le niveau 2. En fait, le
niveau 3 ajoute un concept crucial à la fondation établie au niveau 2 : il ajoute le
fait que l’on doit capitaliser les expériences des projets passés et, tant qu’on peut le
justifier, que l’on doit dériver, adapter, instancier (pour parler le langage orienté objets),
customiser, personnaliser bref AJUSTER le processus de chaque nouveau projet à
partir du capital disponible. J’ai donc choisi de désigner ce niveau de maturité 3 ou
niveau d’aptitude 3 par le terme ajusté.
4.8 Adéquat, approprié, au besoin 35
Niveau de maturité 4 : Géré quantitativement

Je me réconcilie avec les auteurs du CMMI au niveau 4. La désignation « Quantitatively
Managed » évoque tout à fait le comportement attendu à ce niveau : géré quantita-
tivement. C’est-à-dire la surveillance des indicateurs (quantitatifs) de performance
d’un certain nombre de processus clés et la prise systématique d’action corrective à
chaque fois que l’on dérive des objectifs fixés. On dit en langage statistique qu’on
élimine les causes spéciales de variation. Il en résulte une stabilisation, d’un point
de vue statistique, de la performance des processus visés. Ce qui permet la prochaine
étape : l’optimisation.
Depuis la version 1.3 du modèle, la représentation continue s’arrête au niveau
d’aptitude 3. Si on focalise que sur ou quelques processus, les auteurs proposent
d’appliquer les domaines de processus situés aux niveaux 4 et 5 de la représentation
étagée pour passer en gestion quantitative (niveau 4) ou en optimisation (niveau 5).
Niveau de maturité 5 : En optimisation

L’étape du niveau 5, disponible seulement dans la représentation étagée, est en fait
une boucle sans fin. Les auteurs l’ont appelé à juste titre « Optimizing » ce que j’ai
traduit facilement par « En optimisation ». Il me fallait éviter « optimisé » qui aurait
présenté un caractère de fait accompli statique alors qu’au niveau 5, l’idée est de
maintenir l’organisation en perpétuelles boucles d’amélioration continue. Ceci se
nomme l’élimination des causes communes de variation en langage statistique. Cette
élimination ne peut être possible que par la conduite fréquente d’analyses causales sur
un certain nombre de défauts dont on cherche à prévenir la récurrence.
4.8 ADÉQUAT, APPROPRIÉ, AU BESOIN

Portons maintenant notre attention sur les mots adéquat, approprié, au besoin.
Anodins ces petits mots ? Pas du tout ! J’applaudis au fait qu’on les retrouve assez
souvent dans la formulation des pratiques car ils confirment que les auteurs visent le
respect de l’intention des pratiques plutôt que la lettre. Il n’est pas toujours adéquat,
approprié ou on n’a pas toujours besoin de mettre en œuvre exactement tel que
décrite dans le CMMI telle ou telle pratique. Qu’on se le tienne pour dit : les auteurs
du CMMI ne sont pas des dictateurs et ils invitent les lecteurs à faire montre de
jugement. Si une pratique est inutile, inapplicable, voire contre-productive au regard
des contraintes d’un projet, d’une activité ou des objectifs corporatifs, soyons assez
intelligents pour y déroger et trouvons une pratique alternative qui respecte l’esprit
mais non la lettre du CMMI.
4.9 ÉTABLIR ET MAINTENIR

Que dire de l’expression « établir et maintenir » que l’on retrouve dans plusieurs
pratiques du CMMI ? Dans le langage courant, on pense à établir comme l’acte
de mettre en clair, de formuler quelque chose que l’on souhaite accomplir. Ainsi
établir un plan consiste à le clarifier en précisant inévitablement son contenu. Puis
la maintenance consistera à mettre cette information à jour à mesure que l’exigera
le déroulement du projet. Cependant, le CMMI sous-entend deux autres nuances
importantes dans « établir et maintenir ». Chaque fois qu’on lira cette expression, on
doit comprendre que l’objet sur lequel on l’applique devra être documenté et utilisé
en plus d’être établi (formulé) et maintenu.
4.10 CLIENT ET UTILISATEUR
Le mot client peut prêter à confusion, surtout lorsque la personne qu’il désigne se
trouve à l’intérieur de l’organisation. Pour un constructeur de trains, le client est facile
à identifier. Pour une unité responsable de développer et maintenir un système de
paie, le client peut très bien être le département des ressources humaines qui pilote
en même temps le projet lui-même ; il s’agit donc d’une autre unité administrative à
l’intérieur de la même société ! Soulignons aussi qu’un CLIENT peut être représenté
dans un projet par une (des) personne(s) autre(s) que les vrais UTILISATEURS de
la solution qui sera livrée par le projet. Cette distinction nous a fait préférer tantôt
UTILISATEUR et tantôt CLIENT, selon les pratiques que nous avons traduites.
4.11 FOURNISSEUR ET PRESTATAIRE
Le mot fournisseur peut aussi prêter à confusion. En fait on se rend compte que dans
la grande chaîne de production, le client de quelqu’un est toujours le fournisseur de
quelqu’un d’autre et vice-versa ! Un constructeur de trains, client d’une société de
transport ferroviaire, comptera sans doute de très nombreux fournisseurs de pièces.
Quand il s’agit de livrer non pas des composants physiques ou des produits – au
sens propre – mais biens des services (par exemple, développer, installer, etc.), on
désigne souvent le fournisseur par le terme prestataire ! Le CMMI ne voit pas
l’utilité de distinguer entre les deux et utilise toujours le mot fournisseur. On verra,
dans la section portant sur le domaine de processus de « Gestion des accords avec les
fournisseurs » (SAM) dans la constellation DEV, qu’on ne s’intéressera, pour ce qui est
des services, qu’aux fournisseurs qui gardent une responsabilité quant aux processus
utilisés ; sinon, si les processus utilisés pour rendre les services sont ceux du client (en
France, on appelle souvent ce type de prestations de la « régie ») et que les ressources
du fournisseur viennent tout simplement combler des postes sous le contrôle d’un
manager interne et de processus interne, on ne considérera pas ce type de prestation
comme devant satisfaire aux exigences du domaine SAM.
4.12 Parties prenantes 37
4.12 PARTIES PRENANTES
Nous avons francisé le mot « stakeholders » par « parties prenantes ». En fait c’est
un concept parapluie sous lequel on regroupe tous les groupes et individus qui ont
un mot à dire dans le projet : ils peuvent accomplir des choses, participer à leur
accomplissement, devoir être informés, devoir fournir des commentaires, etc. On
utilise parfois dans le CMMI la précision « parties prenantes concernées » quand on
veut spécifier quel sous-ensemble des parties prenantes de l’ensemble du projet sont
requises dans une activité donnée.
4.13 PRODUITS D’ACTIVITÉ, PRODUITS ET SERVICES
Plusieurs pratiques du CMMI s’appliquent à des objets qui sont les résultats d’une
activité de développement et qui peuvent à leur tour servir en entrée dans une
autre activité. Un produit d’activité peut parfois (souvent même) être livré au client
(deliverable en anglais) et devient alors un bien livrable. Mais il peut aussi rester dans
le giron d’un projet comme document intermédiaire par exemple, non visible aux
yeux du client. Il arrive aussi, au Québec par exemple, qu’on utilise le mot « biens
livrables » pour tout résultat d’une activité, que le produit soit livré ou non au client
(sous-entendu, il est quand même livré, en interne, au management ou à l’équipe projet
ou à toute partie prenante qui n’est pas un client). Dans cette logique, j’aurais pu
utiliser le vocable « biens livrables » au lieu de « produits d’activité » mais j’ai finalement
retenu « produits d’activité » dont un sous-ensemble sera des « biens livrables », ceux
qui seront effectivement livrés au client. Notons que le CMMI choisit plutôt le mot
produit pour désigner un produit d’activité qui est livré au client. Enfin, toujours
dans le CMMI, le mot produit englobe service ; pour le CMMI, le service est tout
simplement un produit intangible.
4.14 ÉVALUATION
Lorsque le SEI a créé le SW-CMM, il a développé deux méthodes associées mais

distinctes : l’une pour les évaluations externes (audits) : SCE ; l’autre pour les
évaluations internes assistées : CBA IPI. Les auteurs de ces méthodes les ont baptisées
respectivement « evaluation » et « assessment ». Notons ici que les francophones
avaient utilisé le même mot évaluation et l’accolaient au qualificatif d’externe ou
interne pour traduire respectivement « evaluation » et « assessment ». Tout allait bien
jusqu’au jour où, avec le CMMI, le SEI a livré une famille de méthodes unifiée,
internes et externes à la fois, nommée SCAMPI. On gardera donc en français le mot
évaluation tout court pour désigner une des méthodes de la famille SCAMPI. Mais
dans le CMMI, ce mot évaluation ne désigne pas uniquement SCAMPI ; il peut y
avoir des évaluations plus informelles également qui respectent l’esprit des règles et le
même mot évaluation est utilisé.
4.15 ACTIFS PROCESSUS
Le niveau 3 du CMMI exige le recours à un capital ou un référentiel d’actifs. Ce

capital se traduit par un ensemble d’objets que l’on nommera effectivement des
actifs (sous entendu « de processus »), par analogie avec le domaine des finances.
Dans les domaines de processus du CMMI, on trouvera des références à l’ensemble de
processus standards au niveau de l’organisation que l’on désigne plus simplement par «
processus organisationnels ». Ces processus organisationnels (en fait, on les retrouve
souvent sous forme de Méthode ou Méthodologie, comme on a pris l’habitude de dire)
ne peuvent que rarement s’appliquer tels quels à un projet donné. Il faut alors que
le chef de projet définisse les variations dont on aura besoin et constituer ainsi un
processus ajusté (sous-entendu « pour le projet »). Pour y arriver, le chef de projet
consultera le capital (des actifs) mis à sa disposition. En plus de la méthode, de la
description des cycles de vie autorisés, de lignes directrices pour la personnalisation,
il aura accès à ce que les auteurs du CMMI nomment la base de données de tous les
projets passés (estimations, données finales, statistiques sur les erreurs, etc.) et aussi à
la bibliothèque des exemples types, des modèles de documents, etc.
4.16 CMMI
Celui-là, je l’ai gardé pour le dessert ! Le sigle CMMI correspond en anglais à « Capa-
bility Maturity Model Integration ». Les Américains nous ont ainsi livré un beau casse-
tête : comment traduire justement cette juxtaposition de mots sans déterminant ? Je
serais bien curieux de passer un test aux Américains pour leur demander d’expliquer
ce que veut précisément dire « Capability Maturity Model Integration ». Je serais prêt
à parier que même parmi les experts du CMMI on trouverait des incohérences !
Pour la simple raison que les quatre mots juxtaposés contiennent au moins deux
paradoxes. Entendons-nous d’abord sur le mot principal : on n’obstinera pas qu’il
s’agit de « Model » ce qui se traduit bien facilement en français par « Modèle ». Mais
ensuite ? Ils nous ont juxtaposé « Capability » (qui est le mot réservé pour caractériser
les niveaux en représentation continue) ainsi que « Maturity » (qui est le mot réservé
pour caractériser les niveaux en représentation étagée). Faudrait-il alors comprendre
qu’ils ont élidé le « And » et traduire par « Modèle d’aptitude et de maturité » ? Ou
croire qu’ils ont voulu dire que l’aptitude est plus ou moins sophistiquée et qu’ils
ont alors utilisé le mot « Maturity » qui, placé après « Capability », correspondrait
à une forme elliptique de « Maturity of Capability ». On aurait alors « Modèle de
maturité – ou maturation – de l’aptitude » ? Et que fait-on avec « Integration » ? Je
sais, des auteurs-mêmes, que c’est bel et bien en référence au fait que ce modèle,
contrairement au SW-CMM, intègre plusieurs disciplines d’ingénierie. Le modèle sert
donc à l’intégration des disciplines. Ce qui fait que les pratiques dans le modèle sont
elles-mêmes intégrées, que ce soit pour une discipline x ou y. On serait alors tenté de
dire « Modèle intégré » ou « Modèle en vue de l’intégration » pour rendre cette notion
d’intégration justement. Conclusion : je ne sais vraiment plus comment rendre très
justement « Capability Maturity Model Integration » car aucune des traductions, que
4.16 CMMI 39
ce soit « Modèle intégré de maturité et d’aptitude », « Modèle de maturité et d’aptitude en

vue de l’intégration » ou « Modèle intégré de maturation de l’aptitude » ou... ouf ! Me
pardonnerez-vous de dire simplement CMMI ?
Lecteurs vous voilà donc maintenant bien outillés pour aborder le contenu du
modèle. Si on parlait d’abord de la vue d’ensemble avant d’aborder les détails ? Suivez-
moi et passons au chapitre qui porte sur l’architecture du CMMI.
Avez-vous bien LU ?
a) Comment s’appelle le sous-ensemble d’une entreprise auquel on décide

d’appliquer le CMMI ?
b) Dans quelle représentation parle-t-on de niveau de maturité ? De niveau d’aptitude ?
c) Dans une organisation déterminée à bien appliquer le CMMI à très long terme,
quel niveau de maturité est susceptible de durer le plus longtemps ?
d) En plus de formuler et de garder à jour, que signifie l’expression « établir et

maintenir » dans le contexte du CMMI ?
e) Qu’est-ce qui aide les projets d’une organisation de niveau de maturité 3 à se

ressembler pas mal plus que dans une organisation de niveau de maturité 2 ?
f) Qu’est-ce qui aide les projets d’une organisation de niveau de maturité 3 à pouvoir
quand même différer légèrement les uns des autres ?

a) Racontez dans vos mots comment une organisation changerait en passant du

niveau de maturité 1 à 2 puis à chacun des niveaux supérieurs.
b) Essayez de décrire une organisation dans laquelle la notion de projet serait bien
différente de celle appliquée dans une autre organisation (piste : pensez à une banque
qui veut refondre ses applications pour les comptes clients et à une boîte de conseillers
qui développe une application de consultation de son compte bancaire par Internet).
5
L’architecture du modèle
Dans ce chapitre, nous expliquerons la structure du modèle CMMI.

Globalement, chaque constellation du CMMI couvre un ensemble de disciplines1
(ou métiers) et non uniquement la discipline du logiciel comme le faisait son ancêtre
(le SW-CMM).
Avant d’examiner l’architecture interne du modèle, il importe donc de rappeler
que sa portée dépasse le monde du logiciel. Le « I » du sigle CMMI signifie Integration.
Le CMMI intègre en effet des disciplines multiples. Nous associons le concept de
discipline à celui d’un « corpus de connaissances » qui est souvent à la base de la
définition de toute discipline. Ainsi le développement de logiciel constitue l’une des
disciplines. On peut décrire un corpus de connaissances requises de la part de ceux
qui visent à exercer cette discipline. Par exemple, pour la discipline du logiciel, ce fut
l’objet du projet SWEBOK (Software Engineering Body of Knowledge). Pour la discipline
de la gestion de projet, on peut penser au PMBOK (Project Management Body of
Knowledge) du PMI (Project Management Institute). Mais revenons au CMMI : dans sa
constellation DEV, il va chercher son contenu dans les disciplines de développement
de logiciel (Software Engineering), mais aussi de développement de systèmes (System
Engineering) et de développement matériel (Hardware Engineering).
Par cette approche ouverte aux disciplines variées, la portée du CMMI pourrait
bien s’étendre et absorber d’autres disciplines dans ses versions futures. Véritable
« work-in-progress », l’avenir du CMMI se dirigera vers où sa communauté d’utilisateurs
voudra bien le diriger. Évidemment, bien que le CMMI soit à géométrie variable, on
peut s’intéresser seulement aux disciplines qui nous intéressent. Rien n’oblige un
utilisateur du modèle à utiliser toutes les disciplines couvertes par le modèle.
1. Voir la note en bas de page de la première page du chapitre 1.

42 Chapitre 5. L’architecture du modèle
Lors du passage de la version 1.1 à la version 1.2 du CMMI, les auteurs ont
constaté qu’il serait utile de grouper les disciplines par vocation ; ils ont désigné ces
regroupements par le mot « constellation ». Ainsi, le trio logiciel, système et matériel
dans un contexte de projet d’élaboration ou de construction d’un livrable se nomme
DEV (qui signifie « Développement »). Lors du passage à la version 1.2, à cette
constellation DEV se sont déjà ajoutées les constellations ACQ (pour acquisition)
et SVC (pour services). Lors de la publication de la version 1.3 du CMMI, on ne
trouve toujours que ces 3 constellations : DEV, ACQ et SVC, Mais on peut imaginer
que d’autres constellations du CMMI se rajouteront au fil des années en fonction des
besoins exprimés par la collectivité qui utilise le CMMI. Certains grands utilisateurs
du CMMI souhaiteraient par exemple mettre sur étagère les bonnes pratiques du
passage du développement du prototype à l’industrialisation à grande échelle (à la
ligne de production). D’autres aimeraient voir intégrer dans la famille CMMI les
bonnes pratiques de gestion du personnel que l’on trouve dans P-CMM. L’avenir nous
dira qui seront les futurs « enfants » du CMMI.
5.1 LES DEUX REPRÉSENTATIONS DU CMMI

Deux visions de l’expression de l’évolution de la capacité de développement se sont
affrontées lors de la genèse du modèle CMMI. Une école de pensée privilégiait
de considérer l’évolution des pratiques par stade ou par étape, en situant cette
évolution au niveau de toute une organisation de développement. Héritière de la
vision implémentée dans le modèle SW-CMM (ancien modèle du SEI qui ne traitait
que du développement logiciel), cette approche se nomme « Staged » qu’on a traduit
par « Étagée ». Une autre école de pensée, née lors de la conception du modèle
SE-CMM (un autre ancien modèle auquel a également fortement contribué le SEI et
qui était axé sur le développement de système où le logiciel joue un rôle prépondérant
mais n’est qu’un élément du projet de développement) privilégiait de focaliser sur
l’évolution de chaque domaine de processus (Process Area) spécifique et d’y associer
des stades de développement de l’aptitude du domaine de processus en question.
Cette approche se nomme « Continuous » qu’on a traduit par « Continue ». Elle fut
également adoptée par le projet SPICE qui a défini une norme ISO/IEC 15504 qui
s’appuie justement sur une représentation continue.
Confronté à ces deux visions du monde de l’évolution des processus et n’arrivant
à opter ni pour l’une ni pour l’autre, le SEI a tranché à la Salomon en proposant les
deux représentations. Le modèle CMMI se présente donc en représentation étagée
et aussi en représentation continue. Nous verrons un peu plus loin que cette double
personnalité du CMMI apporte plus d’avantages que d’inconvénients.
5.1.1 La représentation étagée

La représentation étagée exprime l’évolution des pratiques en fonction d’une vue
plus globale ou organisationnelle. Quand on songe à déployer le CMMI, on définit
d’abord un périmètre cible que le CMMI désigne par le vocable « l’organisation ». Ceci
5.1 Les deux représentations du CMMI 43
peut très bien correspondre à toute une société ou seulement à un sous-ensemble

de celle-ci : une division, une ligne d’affaire, un site géographique. Puis on observe
le comportement de cette entité au regard d’une échelle comportant cinq niveaux
de maturité organisationnelle. C’est un peu comme les stades de développement
de l’intelligence proposés par Piaget. L’organisation, selon la représentation étagée,
passe par cinq niveaux de maturité. Chaque niveau est associé à la maîtrise, par
toute l’organisation, d’un certain nombre de domaines de processus. Le modèle fait
débuter l’évolution d’une organisation au niveau de maturité 1 (Initial) et propose
une progression jusqu’au niveau de maturité 5 (En optimisation). Pour monter d’un
niveau, il faut que toute l’organisation maîtrise, et donc institutionnalise, l’ensemble
des domaines de processus associés au niveau supérieur.
Figure 5.1 — La représentation étagée.
La représentation étagée se présente comme une espèce d’escalier. En référence à

ma jeunesse et ma période rock, je le nomme souvent « Stairway to heaven » puisque
ce « Stairway » aboutit au « Heaven » des processus : le niveau de maturité 5, celui de
l’optimisation, le but ultime de la démarche d’amélioration de processus. Le niveau
plancher (le plus bas niveau) correspond au niveau de maturité 1. Toute organisation
qui veut développer des produits ou offrir des services commence d’abord, comme un
bébé, par « ramper » de façon plus ou moins organisée et disciplinée. Ses processus de
travail se structurent progressivement et s’organisent de plus en plus, tout comme le
bébé devient enfant. L’organisation se dirige vers une maîtrise accrue de la discipline
de développement. On peut alors constater que l’organisation a atteint un plateau
supérieur : le niveau de maturité 2 dit « Discipliné ». Progressivement, les intervenants
au sein de l’organisation se rendent compte à quel point il serait utile de capitaliser
sur les expériences passées pour devenir de plus en plus performants. On réutilise
alors des processus organisationnels standards. En même temps, on s’efforce de bien
ajuster ces processus communs ou standards aux spécificités des projets ou des services,
comme lorsqu’on achète du prêt-à-porter et qu’on fait ajuster son costume ou sa robe.
Pour y arriver, on doit maîtriser plusieurs domaines de processus additionnels. Une
fois ces processus de capitalisation (et quelques autres) maîtrisés, l’organisation est
au niveau de maturité 3 ou « Ajusté ». La prochaine étape, le niveau de maturité 4,
sera associée à une approche de gestion quantitative généralisée dans tous les projets
et services de l’organisation ; le niveau se nomme d’ailleurs « Géré quantitativement ».
Enfin, le nirvana est associé à l’optimisation continue, le niveau de maturité 5 (« En
optimisation »). À cette étape, l’organisation est une espèce de machine qui s’auto-
optimise sans arrêt.
5.1.2 La représentation continue

La représentation continue utilise une vision plus ciblée de l’évolution des pra-
tiques. En effet, plutôt que de chercher à exprimer les stades d’évolution de toute
l’organisation en cinq paliers, avec des bouquets de processus comme le fait la
représentation étagée, la représentation continue exprime la capacité ou l’aptitude de
chaque processus pris séparément au sein de l’organisation. Schématiquement, au lieu
d’un seul escalier pour illustrer la maturité de toute l’organisation, il faut un escalier
par domaine de processus pour exprimer sa capacité ou son aptitude. En fait, plutôt
que de recourir à des images d’escaliers, on utilise plutôt des diagrammes à colonnes
où chaque colonne (on dit parfois « silo » ou « cheminée ») traduit, par sa hauteur et
en fonction d’une échelle graduée de zéro à cinq, le niveau d’aptitude du processus.
L’ensemble des colonnes pour les processus choisis constitue ainsi un profil d’aptitude
pour l’organisation.
Le lecteur attentif aura remarqué que j’ai dit ci-dessus que l’échelle de la repré-
sentation continue commence à zéro plutôt qu’à 1 comme dans la représentation
étagée. En effet, comme elle est plus ciblée et ne porte que sur un processus à la
fois, la représentation continue doit pouvoir exprimer la situation où la réalisation
des activités de base d’un processus est tout simplement nulle ou très incomplète.
Ceci constitue alors le niveau zéro de ce processus. Si on y réfléchit bien, dans la
représentation étagée, il serait pour le moins surprenant que pour tout un bouquet
de processus, aucun d’eux ne soit réalisé ; un niveau de maturité zéro dans la
représentation étagée devient donc inutile et l’échelle de référence commence donc,
tout simplement, à 1. C’est moins déprimant diront avec humour certains partisans de
la représentation étagée de commencer à 1 que de partir à zéro ! À partir du niveau 2,
les deux représentations expriment sensiblement la même idée de progression mais
appliquée à l’aptitude d’un processus donné dans le cas de la représentation continue
et à la maturité de toute l’organisation dans le cas de la représentation étagée.
Figure 5.2 — La représentation continue.

5.1 Les deux représentations du CMMI 45
5.1.3 Que choisir ?

Alors, comment choisir : étagée ou continue ? Examinons les avantages et les incon-
vénients de l’une et de l’autre.
La représentation étagée permet en une seule image forte (la maturité de l’organi-
sation caractérisée par un seul chiffre) d’exprimer de façon très synthétique un état
des lieux ou un objectif à atteindre. Ainsi, suite à une évaluation de la maturité d’une
organisation, avec la méthode SCAMPI par exemple, on dira : « L’évaluation a révélé
que cette organisation fonctionne à un niveau de maturité 1 (ou 2, ou 3, etc.). » Pour
la Direction d’une telle organisation, l’objectif est simple à fixer : « D’ici x mois – ou
années –, nous nous fixons comme organisation l’objectif d’atteindre le niveau de maturité 2
(ou 3, ou 4, etc.). » Cette même Direction peut comparer son organisation à une autre,
grâce à cette caractérisation par un seul chiffre de la maturité organisationnelle ; faire
ce que l’on appelle communément du « benchmarking ». En utilisant les statistiques
publiées par le SEI, il est facile de se comparer, de déterminer à quelle catégorie
(plus ou moins mature) d’organisations on appartient. L’ensemble des personnes d’une
même organisation peut facilement se rallier autour de cet objectif simple : être au
niveau actuel + 1 d’ici « n » mois ou années.
Tout ça est vrai diront les tenants de la représentation continue. Mais la simplicité
n’est pas toujours bonne conseillère ! L’image d’un seul niveau de maturité pour
toute l’organisation est peut-être séduisante et forte dans son dépouillement zen
mais simplifie exagérément la réalité qu’elle cherche à modéliser. La représentation
continue permet d’exprimer toute la subtilité de la progression de l’aptitude des
différents processus que l’on cherche à mettre en œuvre. N’est-il pas exagérément
simpliste de vouloir progresser sur un ensemble de processus (par exemple la Gestion de
configuration et la Planification de projet) au même rythme ? La représentation continue,
à cet égard, offre cette subtile distinction dans la progression, pas nécessairement
synchrone, de l’aptitude de plusieurs processus. Pour l’équipe de soutien au processus,
la planification de l’amélioration peut se décliner en objectifs beaucoup plus clairs :
atteindre le niveau d’aptitude « n » de tel ou tel processus. L’éléphant, c’est connu,
se mange mieux par petites bouchées. Faut-il donc laisser nos lecteurs sur ce débat
d’experts ? Je me souviendrai toujours de cette boutade de deux collègues de la
communauté des évaluateurs CMMI : pourquoi pas les deux ? En 2002, lors de la
conférence SEPG (Software Engineering Process Group) qui se tenait cette année-là à
Phœnix en Arizona, Agapi Svolou et Tim Kasse proposaient un nouveau concept :
l’approche « con-stagious ». Ceci a frappé l’imaginaire des participants. La peur des
pandémies et la contagion par les virus de toutes sortes hantait déjà les esprits. Ils ont
retourné le concept de contagion et en ont fait quelque chose de positif. Une approche
positivement « contaminante » serait idéale. Un amalgame de la représentation étagée
et de la représentation continue correspond sans doute, de toute façon, aux besoins
complémentaires de deux types de personnes dans la même organisation. D’une part,
le management qui doit fixer des objectifs et qui doit suivre la progression de toute
l’organisation vers l’atteinte de ces objectifs se sentira à l’aise avec la représentation
étagée. Les gens du terrain, ceux qui, telles de vaillantes fourmis ouvrières dans la
fourmilière, doivent déployer une à une les améliorations de processus apprécieront
les repères plus fréquents et ciblés de la représentation continue. Une publicité

bien connue en Amérique présente le côté « sage » et le côté « givré » d’un certain
petit-déjeuner fait de petits carrés à base de céréale et conclut que les deux « côtés »
sont importants. Exit la controverse : il faut assumer les deux côtés de sa personnalité.
Pour les besoins de ce livre et pour éviter d’entraîner le lecteur dans un parcours
systématiquement parallèle (un petit bout d’étagé puis un petit bout de continu, en
boucle), j’ai fait un choix éditorial basé sur mon vécu sur le terrain. Mes clients
utilisent à plus de 80 % la représentation étagée. Je choisis donc de développer
prioritairement, dans la suite de ce livre, l’approche étagée. Ceci ne constitue pas un
déni des avantages bien réels de la représentation continue. En fait, lorsqu’on regarde
sereinement le contenu du livre CMMI dans les deux représentations, on s’aperçoit
rapidement que le contenu important (la description des pratiques) est identique !
Moins de 10 % (et encore !) des pages sont différentes. De plus, les cours officiels
sur le CMMI combinent à la fois la représentation continue et la représentation
étagée. D’ailleurs, les auteurs du CMMI, lorsqu’ils ont publié le modèle en anglais en
format livre à couverture rigide (plutôt qu’en version classeur à anneaux) ont choisi
cette approche de présenter le modèle dans ses deux représentations. La version 1.3
quant à elle, même dans le « Technical Report » original du SEI, combine les deux
représentations dans un seul manuel.
Soyez donc rassurés. Je parlerai surtout « étagé » dans ce livre mais je n’abandonne-
rai pas à leur sort les partisans « continus ». Je leur ai déjà consacré toute une page !
5.2 LES DIFFÉRENTS COMPOSANTS DU CMMI1

Le CMMI est une construction qui utilise divers composants. Ça me rappelle mes jeux
de briques de plastique qui occupaient mes journées de vacances lorsque j’étais enfant.
Il y avait de petites briques, des plus grandes, des pièces de fondation sur lesquelles on
devait commencer par disposer ses briques. Elles étaient toutes de couleur rouge et en
plastique souple : c’était avant les Legos (hélas ça me rappelle mon vieil âge !). Aussi,
bien sûr, il y avait des portes, des fenêtres... Je m’arrête : on aura compris l’image des
composants ! Le composant fondamental du CMMI est le « domaine de processus ». En
représentation étagée, chaque niveau de maturité est associé à un ensemble précis de
domaines de processus ; la notion de niveau est appliquée à cet ensemble de domaines
de processus et on parle de niveau de maturité de l’organisation. En représentation
continue, chaque domaine de processus est pris séparément ; la notion de niveau est
appliquée à chaque domaine de processus pris individuellement et grâce aux pratiques
génériques appliquées à chacun, on parle alors de niveau d’aptitude du domaine de
processus.
Voyons donc comment chaque domaine de processus est décrit dans le CMMI.
1. Je suggère fortement au lecteur de suivre dans le CMMI (version française complète approuvée
par le SEI ou version originale anglaise) les sections qui correspondent à celles que l’on aborde ici.
Les exemples tirés du CMMI dans les pages qui suivent permettront au lecteur de facilement se
repérer dans le modèle CMMI.
5.2 Les différents composants du CMMI 47
Représentation étagée Représentation continue
Niveau de maturité
Domaines Domaines
de processus de processus
Objectifs Objectifs Objectifs Objectifs
Niveau d’aptitude
génériques spécifiques génériques spécifiques
Pratiques Pratiques Pratiques Pratiques

génériques spécifiques génériques spécifiques
Figure 5.3 — Architecture fondamentale du CMMI

dans ses deux représentations (étagée et continue).
5.2.1 Domaine de processus

Le composant fondamental du CMMI est le domaine de processus (Process Area).
L’ensemble des activités accomplies peut se décrire en fonction d’une espèce de
toponymie des processus. Le CMMI, dans sa version 1.3 et dans la constellation
DEV, propose un total de 22 domaines de processus ; la constellation ACQ en compte
également 22 et la constellation SVC quant à elle en compte 24. Si on se rappelle que
le CMMI est un livre, alors les domaines de processus en sont les chapitres. Le CMMI
utilise rigoureusement le même schéma de décomposition et d’écriture pour chacun
de ses chapitres, c’est-à-dire pour chacun de ses domaines de processus. Ceci est bien
pratique : quand on a lu le contenu d’un domaine de processus, on retrouve facilement
la même structure dans tous autres domaines de processus. Ceci facilite grandement
l’apprentissage du modèle et la navigation à l’intérieur du CMMI puisqu’on trouve
toujours les mêmes choses aux mêmes endroits, comme dans l’atelier de tout bon
bricoleur ou dans les armoires de toute bonne cuisinière. Mais j’aurais pu tout aussi bien
dire de toute bonne bricoleuse ou de tout bon cuisinier : la langue française permet
ces subtilités ! Citons, à titre d’exemple, quelques domaines de processus : Gestion des
exigences (REQM), Planification de projet (PP), Validation (VAL), Analyse causale et
résolution (CAR). Les sigles entre parenthèses sont ceux que l’on utilise couramment
pour désigner les noms de domaines ; on aura compris que ce sont simplement les
premières lettres de chaque mot composant les noms de domaine en anglais.
5.2.2 Intention, notes explicatives et références

Les toutes premières lignes d’un « chapitre » de domaine de processus décrivent
l’intention (Purpose) du domaine en question. Lors de mes cours sur le CMMI, je
dis souvent qu’il n’y a aucune excuse valable pour ignorer de quoi est fait le CMMI.
Dans un seul trajet de la maison au travail, même en voiture (avec les feux rouges)
on aura le temps de lire au moins ces petits paragraphes que l’on trouve au tout début
des domaines de processus. Qui n’a pas 15 minutes dans sa vie pour lire le CMMI ?
L’intention nous situe tout de suite dans le contexte de base du domaine de processus.
Ainsi, dans le chapitre consacré au domaine de Planification de projet, les auteurs
débutent par « L’intention du domaine de processus Planification de projet est d’établir et
maintenir des plans qui décrivent les activités du projet ». Voilà en quelques mots simples
bien campés le caractère fondamental du « personnage » Planification. Ce paragraphe
est ensuite suivi de notes explicatives (en général une page environ) qui brossent
de façon un peu plus étoffée et de manière plus littéraire la nature du domaine de
processus.
Tableau 5.1 — Exemple tiré du CMMI de la description de l’intention (« Purpose »)

d’un domaine de processus et des notes explicatives (« Introductory Notes »).
Project planning Planification de projet

A Project Management Process Area Un domaine de processus de la catégorie
at Maturity Level 2 Gestion de projet du niveau de maturité 2
Purpose Intention
The purpose of Project Planning (PP) is to L’intention de « Planification de projet » (PP) est
establish and maintain plans that define project d’établir et maintenir les plans qui définissent les
activities. activités de projet.
Introductory Notes Notes explicatives
(...) The Project Planning process area involves (...) Voici ce que comprend le domaine de
the following : processus Planification de projet :
• Developing the project plan • développement de projet ;
• Interacting with stakeholders appropriately • interaction adéquate avec les parties
• Getting commitment to the plan prenantes ;
• Maintaining the plan • obtention d’un engagement envers le plan ;
(...) • maintien du plan.
(...)
Le lecteur attentif aura remarqué dans la version originale anglaise du CMMI que le
nom du domaine de processus est toujours suivi, en plus petits caractères une ligne en
dessous, de deux informations juxtaposées dans une expression sibylline. On y donne
d’abord l’appartenance du domaine de processus dans la représentation continue c’est-
à-dire sa « catégorie » ; puis on précise aussi son appartenance dans la représentation
étagée, c’est-à-dire son « niveau de maturité ». Ainsi, en ce concerne notre exemple,

PP appartient à la catégorie « Gestion de projet » dans la représentation continue et
est situé au niveau de maturité 2 dans la représentation étagée.
Suite aux quelques paragraphes de notes explicatives, les auteurs listent les
références entre domaines de processus. À titre d’exemple, la Planification de projet
(PP) est liée au Développement des exigences (RD) parce qu’il faut évidemment
connaître le contenu (obtenu de RD) de ce que doit couvrir le plan de projet
(développé en PP). Dans chacun des domaines, les auteurs ont ainsi commodément
regroupé tous les liens entre domaines de processus.
Tableau 5.2 — Exemple tiré du CMMI de liens entre PP

et les autres domaines de processus (Related Process Area).
Related Process Areas Références entre domaines

de processus
Refer to the Requirements Development process Pour plus d’informations sur l’obtention et
area for more information about eliciting, l’explicitation, l’analyse et la documentation des
analyzing, and establishing customer, product, exigences client, produit et composants de
and product component requirements. produit, reportez-vous au domaine de processus
Développement des exigences. Pour plus
Refer to the Technical Solution process area for d’informations sur la sélection, la conception et
more information about selecting, designing, and l’implémentation de solutions aux exigences,
implementing solutions to requirements. reportez-vous au domaine de processus Solution
Refer to the Measurement and Analysis process technique.
area for more information about specifying Pour plus d’informations sur la spécification des
measures. mesures, reportez-vous au domaine de processus
Mesure et analyse.
Refer to the Requirements Management process Pour plus d’informations sur la gestion des
area for more information about managing exigences, reportez-vous au domaine de
requirements. processus Gestion des exigences.
Refer to the Risk Management process area for Pour plus d’informations sur l’identification et
more information about identifying and analyzing l’analyse des risques et sur la réduction des
risks and mitigating risks. risques, reportez-vous au domaine de processus
Gestion des risques.
Poursuivons la lecture du domaine de processus. À la suite du paragraphe d’inten-

tion, de la page de notes explicatives et des références croisées entre domaines, on
trouve un tableau des objectifs et des pratiques associées à chacun d’eux. Explorons
ce que ces concepts veulent dire dans le contexte du CMMI.
5.2.3 Objectifs et pratiques génériques

Le lecteur trouve dans une section qui précède la description détaillée de chaque
domaine de processus une section consacrée à une série d’objectifs et de pratiques
dites Génériques. On remarquera le caractère différent de ces objectifs et de leurs
pratiques associées quand on les compare aux objectifs et pratiques Spécifiques des
pages subséquentes (les pages consacrées à chaque domaine de processus). Si les

objectifs et pratiques Spécifiques sont intimement associés à la nature même du
domaine de processus, les objectifs et pratiques Génériques s’appliquent à chacun des
domaines de processus contenus dans le CMMI. Les objectifs et pratiques spécifiques
sont, comme on peut s’y attendre, très différents dans leur formulation même d’un
domaine de processus à l’autre. Si on parle d’estimation (une activité qui, en toute
logique, est bel et bien spécifique à la planification) dans le domaine de processus
Planification de projet, on parlera d’actions correctives en Surveillance et contrôle de
projet, de préparation d’un environnement d’essais en Vérification, pour ne donner
que quelques exemples illustrant le caractère spécifique (forcément) des objectifs et
pratiques Spécifiques. Par contraste, les objectifs et pratiques décrits dans le chapitre
qui précède ceux consacrés aux différents processus présentent un caractère Générique.
On peut les copier-coller d’un domaine de processus à l’autre, en ne changeant que
le nom du domaine de processus auquel on l’applique. Les objectifs et pratiques
génériques d’un domaine de processus sont, de plus, intimement liés au niveau de
maturité de l’organisation (en représentation étagée) ou d’aptitude du processus (en
représentation continue). On peut dire que l’objectif générique, avec son train de
pratiques associées, situe le degré d’institutionnalisation d’un domaine de processus
alors que les objectifs spécifiques en décrivent les activités de base.
Comme ils sont communs à tous les domaines de processus, le CMMI ne les décrit
complètement qu’une seule fois, au tout début de la partie II. Mais il ne faut jamais
oublier qu’ils s’appliquent à chacun des 22 (ou 24, pour la constellation SVC) domaine
de processus même s’ils ne sont pas recopiés.
Attention : le numéro d’un objectif générique correspond au niveau de maturité

auquel il correspond. Ainsi GG2 signifie que cet objectif est requis de chaque domaine
de processus (en plus de ses pratiques spécifiques) pour atteindre le niveau 2. Par
contre le numéro d’un objectif spécifique est NON signifiant et en vise qu’à donner
une identification unique à chaque objectif. De plus, pour les objectifs (et pratiques
d’ailleurs) spécifiques, ce numéro n’impose aucune séquence chronologique : le CMMI
n’impose absolument pas qu’un objectif SG2 soit réalisé après un objectif SG1 dans
un même domaine de processus. De la même façon, le CMMI n’impose pas qu’une
pratique SP1.1 soit accomplie avant une activité SP1.2 ou même une activité SP2.3.
Bien se rappeler que le numéro d’un objectif et d’une pratique n’a de sens que dans
le cas des Génériques.
Ayant choisi de structurer mon livre par niveau de maturité selon la représentation
étagée, on trouvera les objectifs génériques et les pratiques génériques associées en
début de chapitre correspondant à chaque niveau de maturité.
5.2.4 Objectifs spécifiques

Dans le CMMI, chaque domaine de processus comporte un certain nombre d’objectifs
(goals) à atteindre. Il y a deux types d’objectifs : les spécifiques, propres à chaque
domaine de processus, et les génériques, identiques ou communs d’un domaine de
processus à l’autre. Comme je le soulignais précédemment, je reviendrai sur les

objectifs génériques un peu plus loin.
Lorsqu’on évalue une organisation vis-à-vis le CMMI, les objectifs représentent
autant de critères pour juger de la satisfaction, par l’organisation, des exigences du
modèle au regard du domaine de processus. Petites phrases très courtes, les objectifs
d’un domaine de processus sont à ce point fondamentaux que la maîtrise de tous les
objectifs est obligatoire pour décréter la satisfaction du domaine de processus. Quand
on fait une évaluation des processus sur la base du CMMI, il suffit qu’un seul objectif
ne soit pas satisfait pour considérer que le domaine de processus ne soit pas satisfait !
Ceci peut sembler excessif au profane. Mais il lui suffira d’un exemple pour comprendre
que cela va quasiment de soi.
Tableau 5.3 — Exemple tiré du CMMI de la table des objectifs spécifiques

et des pratiques spécifiques associées pour PP.
Specific Goal and Practice Summary Objectifs et pratiques spécifiques
SG 1 Establish Estimates SG 1 Établir les estimations

SP 1.1 Estimate the Scope of the Project SP 1.1 Faire l’estimation de la portée
SP 1.2 Establish Estimates of Work du projet
Product and Task Attributes SP 1.2 Établir les estimations des attributs des
SP 1.3 Define Project Lifecycle produits d’activité et des tâches
SP 1.4 EstimateEffort SP 1.3 Définir le cycle de vie du projet
and Cost SP 1.4 Estimer la charge et le coût
SG 2 Develop a Project Plan SG 2 Développer un plan de projet

SP 2.1 Establish the Budget and Schedule SP 2.1 Établir le budget et le calendrier
SP 2.2 Identify Project Risks SP 2.2 Identifier les risques du projet
SP 2.3 Plan Data Management SP 2.3 Prévoir la gestion des données
SP 2.4 Plan Project Resources SP 2.4 Prévoir les ressources du projet
SP 2.5 Plan Needed Knowledge SP 2.5 Prévoir les connaissances
and Skills et aptitudes nécessaires
SP 2.6 Plan Stakeholder Involvement SP 2.6 Prévoir l’implication des parties
SP 2.7 Establish the Project Plan prenantes
SP 2.7 Établir le plan de projet
SG 3 Obtain Commitment to the Plan SG 3 Obtenir l’engagement sur le plan

SP 3.1 Review Plans that Affect the Project SP 3.1 Plan en revue les plans qui ont
SP 3.2 Reconcile Work and Resource Levels des répercussions sur le projet
SP 3.3 Obtain Plan Commitment SP 3.2 Concilier les niveaux de charge
et de ressources
SP 3.3 Obtenir l’engagement au plan
Ainsi, dans le domaine de processus Planification de projet comprend trois objectifs

spécifiques (identifiés par SG pour Specific Goal puis un chiffre séquentiel) :
• SG1 – Établir les estimations.
• SG2 – Développer un plan de projet.
• SG3 – Obtenir l’engagement sur le plan.
Peut-on imaginer avoir des lacunes sérieuses vis-à-vis l’un ou l’autre de ces objectifs
et néanmoins espérer satisfaire l’intention du domaine de processus qui est : « Établir
et maintenir les plans qui décrivent les activités du projet » ? On voit bien que la nature
tout à fait basique des objectifs les rend indissociables de la satisfaction de l’intention
du domaine de processus. Si on me permet cette image : le « syndicat » des objectifs
est complètement solidaire de son domaine de processus.
Précisons aussi que le texte des objectifs (il en est de même pour les pratiques) est
disponible en deux versions : la version courte et la version complète ou allongée. La
version courte sert essentiellement aux discussions entre personnes impliquées dans
des évaluations par exemple et qui réfèrent souvent aux pratiques ou aux objectifs. Ils
se parlent donc entre experts et coupent court. Notons que ce texte abrégé est parfois
trompeur car il oublie des éléments importants de la pratique ou de l’objectif. Il faut
donc référer à la version plus longue de l’objectif ou de la pratique comme référentiel
officiel. C’est un peu comme dans un texte de loi : il y a les titres courts et le texte
officiel qui est la référence.
Tableau 5.4 — Exemple tiré du CMMI
du texte court et du texte long d’un objectif dans PP.
SG 1 Establish Estimates SG 1 Établir les estimations
Estimates of project planning parameters Les estimations des paramètres

are established and maintained. de planification de projet
sont établies et maintenues.
5.2.5 Pratiques
Dans le CMMI, les pratiques représentent les composants de base de chaque domaine
de processus. Une pratique décrit un comportement attendu, de la part d’une organi-
sation ou d’un projet, qu’on peut rattacher à un objectif spécifique, dans le cas d’une
pratique spécifique, ou à un objectif générique, dans le cas d’une pratique générique.
À l’aide d’un texte assez court de 3 ou 4 lignes tout au plus, une pratique exprime une
action normalement accomplie dans le cadre d’un processus de développement qui
respecterait les enseignements du CMMI.
Attention : le CMMI n’impose pas les pratiques de façon incontournable. Il autorise en

effet le déploiement de façons de faire qui respectent l’intention sans nécessairement
respecter la lettre de la pratique. On parlera, dans de telles situations, d’approches
alternatives acceptables. Par exemple, le texte d’une pratique peut demander « Évaluer
si les composants de produit devraient être développés, achetés ou réutilisés en s’appuyant

sur des critères établis » (pratique SP2.4 du domaine Solution Technique). Dans un
projet donné ou dans une organisation donnée, il pourrait arriver qu’une directive
exclut d’emblée l’achat ou la réutilisation de composants ; dans un tel cas, évidemment,
l’esprit de la pratique reste respecté même si une évaluation de ces options n’est pas
effectuée puisque exclue par directive.
Dans chaque domaine du CMMI, chaque objectif est associé à quelques pratiques,
généralement de deux à quatre pratiques ; exceptionnellement, un objectif peut se
décliner en plus de cinq pratiques. C’est le cas notamment, de l’objectif générique
GG2 qui comporte dix pratiques génériques ; il s’agit du maximum ! Un tel objectif
devient, de ce fait, assez difficile à satisfaire puisqu’aucune faiblesse significative, parmi
les dix pratiques, ne doit venir entraver l’atteinte de cet objectif pour pouvoir le
déclarer satisfait.
A-t-on remarqué que le sigle de chaque pratique est composé de celui du domaine
suivi d’un tiret, puis du sigle GP pour Generic Practice ou SP pour Specific Practice.
Après le sigle « SP » ou « GP » on trouve le numéro de l’objectif auquel est associée
la pratique, un point, puis un numéro unique pour chaque pratique à l’intérieur de
l’objectif. Cette convention est assez simple et permet de repérer immédiatement
l’objectif auquel est associée une pratique.
Poussons un peu plus loin notre découverte des composants du CMMI. Nous avons
maintenant compris, la notion de niveau de maturité ou d’aptitude, de domaine,
d’objectif et de pratique. Nous sommes maintenant prêts pour découvrir plus à fond
les détails du concept de pratique. Poussons donc la porte de la pratique et découvrons
ce qui s’y cache.
5.2.6 Exemples de produits d’activité typiques

Immédiatement sous le libellé officiel de la pratique, les auteurs expliquent en texte
libre la signification de la pratique. Il s’agit de précieuses informations pour interpréter
correctement une pratique. Mais la perle du CMMI se situe juste après ce texte
explicatif : les exemples de produits d’activité !
Les auteurs du CMMI ont fait preuve d’un grand sens pratique en listant sous
chaque pratique quelques exemples de produits (ou livrables) que l’on s’attend de
trouver dans un projet, une activité ou une organisation qui applique la pratique.
Ceci va aider grandement un projet, une activité ou une organisation à comprendre
concrètement ce que l’on attend de lui ou d’elle.
Si on prétend par exemple avoir maîtrisé et utilisé la pratique qui vise à « Établir
et maintenir les procédures et critères pour l’intégration des composants du produit » (PI-
SP1.3), on devrait normalement pouvoir montrer les produits d’activité suivants :
1. Des procédures pour l’intégration du produit.
2. Des critères pour l’intégration du produit.
Ce sont là les deux exemples de produits d’activité de la pratique PI-SP1.3.
Chacun d’eux peut servir de révélateur du degré de déploiement de la pratique en
question. Plus la pratique est institutionnalisée, plus ces deux produits d’activité seront
systématiquement disponibles dans les projets. Ils constituent en quelque sorte des
preuves de l’accomplissement de la pratique.
Important : il faut toujours se rappeler, comme leur nom le précise, que ce ne sont
que des EXEMPLES de produits d’activité et ne pas se limiter à ceux-ci. Chaque
organisation, projet ou activité pourrait démontrer l’accomplissement de la pratique
par d’autres produits d’activités tout aussi pertinents. Sur la base de mes expériences
terrain, je dirais qu’en général ceux qui sont précisés dans le CMMI représentent de
bons exemples types.
Les organisations qui veulent déployer le CMMI trouveront bien commode de

connaître ainsi de façon concrète les documents que l’on s’attend de trouver. Les
évaluateurs de la maturité des processus peuvent ainsi demander à l’avance aux
organisations à évaluer de collecter ces produits d’activité typiques comme preuves du
bon déploiement des pratiques. À l’arrivée sur site, les évaluateurs peuvent alors
vérifier si les éléments collectés répondent bien aux produits d’activité typiques
attendus. Ceci rend le processus d’évaluation très discipliné et beaucoup plus efficace.
Tableau 5.5 — Exemple tiré du CMMI du texte donnant la signification

d’une pratique suivie des produits d’activité typiques dans PI
(Typical Work Products).
SP 1.3 Establish Product Integration SP 1.3 Établir les procédures

Procedures and Criteria et critères d’intégration de produit
Establish and maintain procedures Établir et maintenir les procédures

and criteria for integration et critères pour l’intégration
of the product components. des composants de produit.
(...) (...)
Example Work Products Exemples de produits d’activité
1. Product integration procedures. 1. Procédure d’intégration de produit.

2. Product integration criteria. 2. Critères d’intégration de produit.
Notons que dans la constellation ACQ, on trouvera non seulement des exemples
de produits d’activité pour l’organisation mais aussi des exemples de livrables du
fournisseur (« example supplier deliverable » en anglais). Le CMMI-ACQ veut ainsi faire
ressortir que dans l’interaction entre organisation et fournisseur, des produits doivent
normalement être demandés au fournisseur si on applique les bonnes pratiques.
5.2.7 Sous-pratiques
La plupart des pratiques du CMMI se décomposent à leur tour en sous-pratiques.
Celles-ci permettent d’élaborer sur les différents aspects d’une pratique et servent à
interpréter la pratique plus finement et de façon cohérente. Dans le cadre de certaines
évaluations que j’ai pilotées, certains de mes membres d’équipe avaient tendance à
prendre les sous-pratiques comme une espèce de liste de contrôle (check-list) servant à
vérifier point par point si une pratique était satisfaite ou non. Il m’a fallu maintes fois
expliquer que ce n’est pas ce que visaient les auteurs du CMMI avec les sous-pratiques :
un quasi-automatisme pour juger du déploiement d’une pratique. Il est vrai que ce
serait parfois bien pratique d’avoir une telle liste qui éviterait de porter des jugements.
Mais ce serait faire bien peu de cas de la nécessité d’appliquer avec intelligence le
CMMI en tenant compte des variables de chaque environnement : objectifs straté-
giques, nombre d’employés, nature des produits ou services, culture organisationnelle,
etc. Les sous-pratiques doivent être lues comme des moyens de mieux comprendre
une pratique, surtout lorsque celle-ci est très « englobante » ou vague. Par exemple, la
pratique SP2.1 de Gestion des accords avec les fournisseurs (SAM) demande de Réaliser
avec le fournisseur les activités telles qu’elles sont spécifiées dans l’accord avec le fournisseur.
Ma foi, cela tombe sous le sens tellement c’est trivial. Lorsqu’on prend la peine de lire
les sous-pratiques, on découvre qu’on suggère une surveillance de la performance du
fournisseur, des rencontres techniques périodiques, des rencontres de management,
etc. Ces sous-pratiques apportent un éclairage plus net sur le texte plutôt vague de la
pratique. Deux équipes d’évaluation différentes risquent peu d’interpréter la pratique
très différemment. En l’absence de sous-pratiques, dans l’exemple choisi, le risque de
grandes variations dans l’interprétation serait considérable.

de sous-pratiques (Subpractices) dans SAM.
SP 2.1 Execute the Supplier Agreement SP 2.1 Exécuter l’accord avec le fournisseur
Perform activities with the supplier as Réaliser les activités avec le fournisseur
specified in the supplier agreement. telles qu’elles sont spécifiées dans l’accord
avec le fournisseur.
(...) (...)
Subpractices : Sous-pratiques :
1. Monitor supplier progress and performance 1. Surveiller l’avancement et la performance
(e.g. schedule, effort, cost, technical performance) du fournisseur (par exemple : calendrier, charge,
as defined in the supplier agreement. coût, performance technique) tels qu’ils sont
(...) définis dans l’accord fournisseur.
4. Conduct reviews with the supplier as specified (...)
in the supplier agreement. 4. Conduire des revues avec le fournisseur selon
les spécifications de l’accord.
5.2.8 Élaboration
Le composant élaboration est utilisé dans la section portant sur les objectifs et
pratiques spécifiques.. On le retrouve comme explication des pratiques génériques
appliquées à un domaine en particulier. L’élaboration décrit la particularité de la
pratique générique appliquée au domaine en question. Le lecteur familier avec les
approches orientées objet retrouvera dans l’élaboration le concept d’instanciation.
Par exemple, la pratique GP2.3 exige de Fournir les ressources adéquates pour mettre en
œuvre le processus, développer les produits d’activité et fournir les services couverts par le
processus. Lorsque cette pratique est associée au domaine de Planification de projet, le
texte d’élaboration suggère qu’on aura besoin d’outils d’estimation. Lorsque la même
pratique est associée au domaine de Validation, le texte d’élaboration suggère qu’on
pourrait avoir besoin d’outils de génération de jeux d’essais. Par le biais de l’élaboration,
on donne une couleur locale en quelque sorte à la pratique générique.

d’une élaboration (Elaboration) en PP (Planification de Projet.)
GP 2.3 Provide Resources GP 2.3 Fournir les ressources
Provide adequate resources Fournir les ressources adéquates

for performing the project planning pour mettre en œuvre le processus
process, developing the work products, de planification de projet, déveloper
and providing the services les produits d’activité et fournir
of the process. les services couverts par le processus.
PP Elaboration : Élaboration pour PP :

Special expertise, equipment, and facilities in Pour planifier le projet, une expertise,
project planning may be required. des installations ou des équipements spéciaux
Special expertise in project planning may peuvent être nécessaires.
include the following : Voici des exemples de compétences spéciales :
• Experienced estimators • estimateurs expérimentés ;
• Schedulers • ordonnanceurs ;
• Technical experts in applicable areas • experts techniques dans les domaines
(e.g., product domain and technology) applicables (comme le domaine du produit et la
technologie).
Examples of resources provided include the Exemples de ressources fournies :

following : • tableurs ;
• Spreadsheet programs. • modèles d’estimation ;
• Estimating models. • outils de planification de projet
• Project planning and scheduling packages. et d’ordonnancement.
5.2.9 Divers
Le CMMI enrichit le texte de plusieurs exemples, notes explicatives et références.
Il importe ici de souligner qu’avec l’avénement de la version 1.3 plusieurs notes
explicatives ont été ajoutées dans la constellation DEV sur les approches dites
Agiles. Le SEI a ainsi réagi à une vague d’incompréhension qui a déferlé vers les
années 2007 et suivantes. Certains intégristes des approches dites Agiles ont pensé
limiter l’application du CMMI dans leurs organisations en qualifiant le CMMI
d’incompatible avec les approches Agiles. Il a fallu du temps et plusieurs publications
d’experts reconnus pour dénouer ce nœud d’incompréhension malheureux et faire la
démonstration que les approches Agiles constituent UNE des façons (le comment)
d’implémenter quelques pratiques du CMMI (qui ne décrit que le quoi et non le
comment). Pour bien fixer cette idée de compatibilité entre CMMI et Agile, les auteurs
ont profité de la version 1.3 pour ajouter aux endroits appropriés des explications
pertinentes.

d’une explication sur Agile dans PP-SP1.5.
In Agile environments, the sustained Dans les environnements Agiles, l’implication

involvement of customer and potential end soutenue du client et des utilisateurs finaux
users in the project’s product development probables dans les activités de développement
activities can be crucial to project success ; thus, peut être cruciale au succès du projet ; par
customer and end-user involvement in project conséquent, l’implication du client et des
activities should be monitored. utilisateurs finaux dans les activités du projet doit
être surveillée.
Avez-vous bien LU ?
a) Nommez et expliquez les disciplines couvertes par le CMMI-DEV.
b) Comparez la nomenclature des niveaux de maturité et des niveaux d’aptitude ;

indiquez quelles sont les similitudes et quelles sont les différences.
c) Combien le CMMI compte-t-il de domaines de processus pour ses différentes

constellations?
d) Pourquoi ne trouve-t-on pas dans le CMMI-DEV de domaine de

processus qui traiterait du soutien à l’utilisateur final lorsqu’un applicatif est production ?
e) Que veulent dire les sigles suivants ?

1) PPQA-SP2.1 ;
2) PP-GP2.6 ;
3) SAM-GG3 ;
4) MA-GP2.3.
f) Si vous cherchiez des exemples de preuves de déploiement d’une pratique

spécifique donnée, quelle partie précise dans le livre du CMMI pourrait vous aider ?
g) Qu’est-ce qui permet de trouver des particularités propres à un domaine de

processus donné pour chaque pratique générique?

a) Décrivez deux situations qui vous feraient recommander le recours à la

représentation continue dans un cas et à la représentation étagée dans l’autre.
b) Représentez sous forme schématique, en commençant par le composant

« domaine de processus » en haut, l’ensemble des composants que l’on trouve décrits
dans ce chapitre.
c) Prenez la pratique générique GP2.3 : Fournir les ressources adéquates pour mettre en
œuvre le processus, développer les produits d’activité et fournir les services couverts par
le processus. Sachant que le mot ressources ici veut dire outils, personnes, guides, etc.,
appliquez-la aux domaines de processus suivants et donnez une description la plus
concrète possible de ce qu’elle voudrait dire dans un projet type de votre organisation :
1) PP-GP2.3 (Planification de projet) ;
2) RD-GP2.3 (Développement des exigences) ;
3) RSKM-GP2.3 (Gestion des risques).
6
Les niveaux 0 et 1 :
des cas très particuliers
« Être ou ne pas être »
Les échelles qui caractérisent la MATURITÉ organisationnelle d’un ensemble de

domaines de processus (dans la représentation étagée) ou l’APTITUDE d’un domaine
de processus particulier (dans la représentation continue) débutent toutes les deux par
des cas spéciaux. En effet, dans les deux représentations, les échelles débutent d’abord
par un niveau qui exprime la NON-institutionnalisation c’est-à-dire le fait que l’on
ne détecte pas encore de preuves d’institutionnalisation, même basique.
Commençons d’abord par le zéro : on se rappelle qu’il n’y a pas de niveau de
maturité zéro en représentation étagée mais qu’il existe un niveau d’aptitude zéro en
représentation continue. Sachant que le concept d’aptitude ne s’applique que sur un
seul domaine de processus, un zéro veut dire qu’on n’a pas encore institutionnalisé
l’ensemble des pratiques spécifiques du domaine en question. Il y a alors des lacunes
importantes dans le déploiement de l’une ou l’autre des pratiques spécifiques ce qui
fait qu’on ne peut pas déclarer satisfait l’objectif générique GG1 qui n’existe que dans
la représentation continue.
Par cette explication, je viens de décrire en même temps ce que signifie le niveau
d’aptitude 1 en représentation continue : satisfaire toutes les pratiques spécifiques du
domaine de processus. Ce n’est qu’à cette condition qu’un domaine de processus peut
passer du niveau d’aptitude 0 au niveau d’aptitude 1 en représentation continue et se
qualifier de « basique » (nom donné au niveau d’aptitude 1).
60 Chapitre 6. Les niveaux 0 et 1 : des cas très particuliers
Par la suite, c’est-à-dire une fois maîtrisées les pratiques spécifiques qui forment
collectivement le niveau d’aptitude 1, le passage vers des niveaux d’aptitude supérieurs,
va exiger la satisfaction des pratiques génériques (que l’on décrira en détail dans
les chapitres à venir, qui portent sur les niveaux 2 et 3). On peut donc dire qu’en
représentation continue, on a une sorte de collection de poupées russes en bois, celles
qu’on emboîte les unes dans les autres (avec un ensemble de poupées par domaine de
processus). Au cœur, la poupée la plus intérieure correspond au niveau 1 et correspond
à l’ensemble des pratiques spécifiques. Puis chaque poupée qui emboîte la poupée
plus petite vient superposer une couche de pratiques génériques qui enrichissent
progressivement (niveaux 2 et 3) l’aptitude du processus formée initialement de la
« poupée de base », celle du niveau d’aptitude 1.
Tableau 6.1 L’objectif générique du niveau d’aptitude 1 et son unique pratique générique (texte
court et texte long).
GG1 Achieve specific goals GG1 Atteindre les objectifs spécifiques
The specific goals of the process area are Les objectifs spécifiques (les«SGs») du domaine
supported by the process by transforming de processus sont soutenus par le processus en
identifiable input work products into identifiable transformant les produits d’activité entrants
output work products. identifiables en produits d’activité sortants
identifiables.
GP1.1 Perform Specific Practices GP1.1 Réaliser les pratiques spécifiques
Perform the specific practices of the process area Exécuter les pratiques spécifiques (les « SPs ») du
to develop work products and provide services to domaine de processus pour développer des
achieve the specific goals of the process area. produits d’activité et produire des services, afin
d’atteindre les objectifs spécifiques du domaine
de processus.
On verra dans les chapitres suivants, en abordant chaque domaine de processus, le

libellé et la signification des pratiques spécifiques de chacun d’eux. On comprendra
alors ce que veut dire exactement « être au niveau d’aptitude 1 », pour PP (Planification
de projet) ou pour VAL (Validation) ou n’importe lequel des domaines de processus.
Dans la représentation étagée, le CMMI situe le plancher au niveau de maturité 1.
Cela est bien nord-américain. Au Québec, on parle du rez-de-chaussée comme du
« premier étage », tournure que l’on a piquée de « First Floor » chez les Anglais ou les
Américains. Lors de mon premier voyage en France, quelle ne fut pas ma surprise de
découvrir que le « premier étage » se situait à trois mètres au-dessus du sol et que les
ascenseurs avaient un bouton d’appel pour le niveau zéro ! Le CMMI ayant ses racines
en Amérique, il a désigné son niveau plancher en représentation étagée à l’américaine :
le niveau de maturité 1 et non zéro (qui n’existe pas dans cette représentation).
Rappelons que la représentation étagée groupe les domaines de processus pour
chacun des niveaux de maturité à atteindre ; par exemple, on sait (et on les passera
en revue au chapitre suivant) que le niveau de maturité 2 exige que 7 domaines
de processus soient TOUS satisfaits (i.e. que les pratiques exigées par le modèle
soient toutes bien institutionnalisées). Le fait de ne pas satisfaire l’un ou l’autre
Les niveaux 0 et 1 : des cas très particuliers 61
des sept domaines de processus associés au niveau de maturité 2 en représentation

étagée entraîne que l’on déclare alors l’organisation au niveau de maturité 1 c’est-à-
dire, en quelque sorte, « pas encore au niveau de maturité 2 ». Il n’y a donc aucun
objectif à satisfaire pour être déclarée une organisation de niveau de maturité 1. De
ce point de vue, en représentation étagée, toute organisation « naît » au niveau de
maturité 1 avant d’évoluer vers les niveaux de maturité supérieurs. Ceci a d’ailleurs
amené quelques critiques dans les modèles étagés (comme l’était aussi le SW-CMM,
ancêtre du CMMI). On voit des organisations fondées depuis de plusieurs années
évaluées au niveau de maturité 1 (pas encore 2) aux côtés d’organisations toutes
nouvelles également décrétées, de facto, au niveau de maturité 1 ! Le niveau de
granularité de l’échelle de maturité, qui embrasse plusieurs domaines de processus à la
fois, est tellement « grosses mailles » qu’une division d’une multinationale du logiciel
existant depuis des lunes (sans nommer de nom) peut fort bien être du même niveau de
maturité que l’entreprise de logiciel que vient de fonder votre adolescent(e) dans votre
garage : toutes deux au niveau de maturité 1 ! Certes, c’est en fouillant dans le degré de
déploiement et d’institutionnalisation des processus groupés au niveau de maturité 2
que l’on constatera sans doute des différences entre nos deux exemples. J’imagine
que la grosse boîte connue pourrait bien maîtriser 4 ou 5, voire 6 des domaines de
processus sur les 7 requis pour être décrétée de niveau de maturité 2 alors que la boîte
de votre ado peinerait à satisfaire même un seul des domaines de processus. L’orgueil
de la multinationale est sauf !
Avez-vous bien LU ?
a) Que veut dire le niveau d’aptitude zéro appliqué à un domaine de processus dans
la représentation continue du CMMI ?
b) Pourquoi n’y a-t-il pas de niveau de maturité zéro en représentation étagée du

CMMI ?
c) Que veut dire le niveau d’aptitude 1 appliqué à un domaine de processus dans la

représentation continue du CMMI ?
d) Que veut dire le niveau de maturité 1 d’une organisation dans la représentation

étagée du CMMI ?
62 Chapitre 6. Les niveaux 0 et 1 : des cas très particuliers

a) Expliquez comment une organisation de niveau de maturité 1 du CMMI peut

quand même réussir à livrer des solutions acceptables à ses clients.
b) Si vous étiez un client cherchant un fournisseur qui vous livrerait une solution sur
commande pour un besoin stratégique, qu’est-ce qui pourrait vous inciter vers un
fournisseur de niveau de maturité 1 ? Qu’est-ce qui vous ferait reculer ?
c) Si on vous offrait un emploi a priori intéressant sur papier et qui correspondait à

vos aptitudes et vos ambitions mais dans une organisation de niveau de maturité 1,
que feriez-vous ? Pourquoi ?
d) Si un appel d’offres privilégie le choix du plus bas soumissionnaire, pensez-vous

qu’une organisation de niveau 1 a plus de chance d’être choisie pour le contrat ?
Pourquoi ?
7
Le niveau 2
D’une approche immature à une discipline de développement :

l’échelon le plus difficile à grimper dans l’échelle de maturité ou d’aptitude
Rappelons d’abord qu’en représentation étagée ou continue, la signification du
niveau 2 est essentiellement la même. Cependant, ce concept de niveau s’applique
à un seul domaine de processus, en fait à son APTITUDE, dans la représentation
continue alors qu’il s’applique à une grappe de domaines de processus pour toute
une organisation, en fait pour sa MATURITÉ, dans la représentation étagée. Ce
chapitre porte donc tout autant sur l’atteinte du niveau d’aptitude 2 que du niveau
de maturité 2. Toutefois, la liste des domaines de processus que l’on décrit dans ce
chapitre regroupe ceux du niveau de MATURITÉ 2 et ne s’applique que dans la
représentation étagée. Pour appliquer, en représentation continue, le concept de
niveau d’APTITUDE 2 aux autres domaines de processus, il suffit de regarder leur
contenu dans les autres chapitres de ce livre (les tables de référence au tout début
du livre aideront à les localiser facilement) pour trouver leurs objectifs et pratiques
spécifiques et d’ajouter l’objectif générique GG2 et les pratiques génériques GP2.1
à GP2.10 qui se trouvent dans le présent chapitre. Dit d’une autre façon, l’ordre de
présentation que nous suivons dans ce livre est celui de la représentation étagée ; mais
si on utilise la représentation continue, il suffit de trouver le domaine de processus dans
le chapitre approprié de ce livre et de lui appliquer toutes les pratiques des niveaux
d’aptitude que l’on vise.
Dans la version originale anglaise du CMMI, on dit en représentation étagée qu’une
organisation de niveau de maturité 2 se caractérise par des processus « managed » ;
de même, en représentation continue, on dit qu’un processus de niveau d’aptitude 2
se caractérise par le fait qu’il est institutionnalisé en tant que processus « managed ».
Un seul mot qui regroupe pourtant 10 caractéristiques bien précises, qui traduisent
64 Chapitre 7. Le niveau 2
chacune à leur tour une particularité des processus qui ne sont plus « ad hoc » (niveau
de maturité ou d’aptitude 1) mais qui ont au contraire acquis une certaine rigueur.
Chacune des caractéristiques correspond en fait à l’une ou l’autre des dix pratiques
génériques de niveau de maturité 2 ou niveau d’aptitude 2 décrites ci-après : disposer
d’une directive organisationnelle, planifier la mise en œuvre du processus dans chaque
projet, fournir les ressources requises pour chaque projet, etc.
Tableau 7.1 — Les dix pratiques génériques

(texte court et texte long) du niveau de maturité ou niveau d’aptitude 2.
GP 2.1 Establish an Organizational Policy GP2.1 Établir une directive organisationnelle

Establish and maintain an organizational policy Établir et maintenir une directive organisationnelle
for planning and performing the process. traitant de la planification et de la mise en œuvre
du processus.
GP 2.2 Plan the Process GP2.2 Planifier le processus

Establish and maintain the plan for performing the Établir et maintenir le plan pour la mise en œuvre du
process. processus.
GP 2.3 Provide Resources GP2.3 Fournir les ressources

Provide adequate resources for performing the process, Fournir les ressources adéquates pour mettre en œuvre
developing the work products, and providing the le processus, développer les produits d’activité et fournir
services of the process. les services couverts par le processus.
GP 2.4 Assign Responsibility GP2.4 Assigner la responsabilité

Assign responsibility and authority for performing the Assigner la responsabilité et l’autorité pour mettre en
process, developing the work products, and providing œuvre le processus, développer les produits d’activité
the services of the process. et fournir les services couverts par le processus.
GP 2.5 Train People GP2.5 Former les personnes

Train the people performing or supporting the process Former selon les besoins les personnes qui mettent
as needed. en œuvre ou soutiennent le processus.
GP 2.6 Control work products GP2.6 Contrôler les produits d’activité

Place selected work products of the process under Mettre les produits d’activité sélectionnés du processus
appropriate levels of control. sous le niveau de contrôle approprié.
GP 2.7 Identify and Involve GP2.7 Identifier et impliquer

Relevant Stakeholders les parties prenantes concernées
Identify and involve the relevant stakeholders of the Identifier et impliquer les parties prenantes concernées
process as planned. par le processus comme prévu dans le plan.
GP 2.8 Monitor and Control the Process GP2.8 Surveiller et contrôler le processus
Monitor and control the process against the plan for Surveiller et contrôler le processus vis-à-vis de son plan
performing the process and take appropriate corrective de mise en œuvre et prendre les actions correctives
action. appropriées.
GP 2.9 Objectively Evaluate Adherence GP2.9 Évaluer la conformité de manière objective

Objectively evaluate adherence of the process and Évaluer de manière objective le respect par le processus
selected work products against the process description, tel qu’appliqué et par les produits d’activité sélectionnés
standards, and procedures, and address noncompliance. de la description du processus, des normes et des
procédures qui devaient être respectées et traiter les
non-conformités détectées.
GP 2.10 Review Status GP2.10 Passer le statut

with Higher Level Management en revue avec la hiérarchie
Review the activities, status, and results of the process Passer en revue avec la hiérarchie les activités, le statut
with higher level management and resolve issues et les résultats du processus et résoudre les problèmes.
Le niveau 2 65
Au niveau de maturité 2 (étagé) ou au niveau d’aptitude 2 (continu), bien

qu’il arrive que les processus disciplinés soient établis et documentés au niveau
organisationnel et soient communs pour tous les projets (via une méthode généralisée
à travers l’organisation par exemple), ceci n’est pas exigé. L’exigence de discipline
s’applique projet par projet mais l’exigence d’utiliser un processus commun dans tous
les projets ne viendra qu’au niveau de maturité 3 (étagé) ou d’aptitude 3 (continu).
Le premier défi d’une organisation qui emprunte la voie royale de l’amélioration
continue à l’aide du CMMI consiste donc à passer du niveau de maturité 1 (étagé)
ou d’aptitude 1 (continu) au niveau de maturité 2 (étagé) ou d’aptitude 2 (continu).
Les consultants qui accompagnent des sociétés dans cette grande aventure savent que
ce passage vers le niveau 2 est le plus difficile de tous. Il s’agit en effet de casser le
moule de l’indiscipline pour amorcer un renouveau qui s’appuie sur la discipline et le
déploiement systématique de processus documentés.
Les statistiques du SEI confirment qu’en représentation étagée c’est le passage
qui prend le plus de temps à se faire complètement. En général, une organisation
prend quelques mois de plus pour passer du niveau de maturité 1 vers le niveau de
maturité 2, que du 2 vers 3, du 3 vers 4 ou de 4 vers 5. Un cycle de passage prend en
général environ 18 à 24 mois. Le cassage du moule niveau 1 mettra facilement 24 à 30
mois. Notons qu’on n’a pas de statistiques sur les durées de passage en représentation
continue ; ces statistiques devraient alors être présentées pour chacun des domaines
de processus ce qui rendrait relativement plus complexe la collecte et la présentation
des résultats !
Mais le plus exigeant de ce passage déjà difficile au niveau 2 reste de commencer !
Convaincre la Direction d’amorcer le grand voyage demeure un des grands défis de
ceux qui voient les avantages de l’amélioration continue mais qui n’arrivent pas à les
démontrer irréfutablement. Car il y a un os de taille ! Une organisation de niveau de
maturité 1 possède rarement les chiffres valables pour faire une analyse sérieuse des
bénéfices. Toute estimation des bénéfices s’appuie sur la comparaison entre l’image
actuelle (niveau de maturité 1) et l’image désirée (niveau de maturité 2). On connaît
facilement les coûts. Quand on veut mesurer les bénéfices, on découvre souvent qu’il
n’existe pas de données fiables sur la qualité ou la productivité actuelle. C’est le propre
d’une organisation de niveau 1 d’être immature et de ne pas mesurer. Que faire alors ?
Comment produire cette étude des coûts et bénéfices si on ne trouve pas les données
qu’il faut ? Même si je crois fermement aux vertus des mesures, je dis souvent à ceux qui
assistent à mes cours d’organiser une partie de golf entre leur Directeur et le Directeur
d’une autre société (non-compétitrice évidemment) qui a déjà adopté avec succès
l’amélioration continue et le CMMI. Entre pairs, ils se comprendront. Que faites-vous
quand vous souhaitez partir vers une destination de vacances que vous n’avez jamais
visitée ? Acheter une nouvelle voiture que vous ne connaissez pas encore mais qui
vous attire ? Changer d’emploi et accepter un poste dans une société que vous ne
connaissez que de nom ? N’avez-vous pas le réflexe, à défaut de données mesurables, de
faire appel à vos amis, votre famille, vos collègues de travail pour demander conseil ?
À défaut de données statistiques ou de mesures fiables, c’est parfois la seule façon de
se convaincre. Il en va de même pour le CMMI. On fait un choix basé sur un acte de
foi, appuyé par les commentaires de ses connaissances. Les Américains nomment cela
« educated guess ».
Si on a connu une organisation de niveau de maturité 1 et qu’on y retourne
seulement lorsque celle-ci est devenue confirmée au niveau de maturité 2, on
remarquera immédiatement des différences marquées. Les évaluateurs ne mettent
pas de temps à pouvoir sentir l’air plus sain du niveau de maturité 2. En boutade, je
dirais que ça sent moins la sueur des efforts héroïques, moins les pleurs des déceptions,
moins les colères des espoirs déçus, moins les angoisses des délais obsédants, moins
le rouge des bilans financiers des projets. Ce qu’on remarque d’emblée, c’est que la
Direction se détend un peu quant aux échéanciers à respecter à tout prix (de toute
façon, les projets sont beaucoup moins en retard qu’avant) et valorise de plus en plus
la qualité et la prévisibilité. Les managers de haut niveau détestent les surprises. Ils
aiment voir venir. Le niveau de maturité 2, avec son cortège d’indices révélateurs, aide
à annoncer les couleurs avec justesse et à prendre les actions correctives pour redresser
les situations avant qu’il ne soit trop tard. Finie l’époque héroïque de ceux qui tirent
plus vite que leur ombre mais qui annoncent la veille de la livraison qu’on vient de
découvrir un pépin de taille qui fait tout planter. Ce sont les mêmes qui répondaient
inlassablement « Terminé à 95 % » quand on leur demandait où ils en étaient dans
un projet ; ce 95 % avait l’incroyable capacité de ne pas bouger malgré les injections
incessantes d’heures et de jours additionnels.
Une organisation de niveau de maturité 2 se remarque d’abord par le soin parti-
culier qu’elle porte à bien enregistrer et suivre toutes les demandes de modification
d’un client au regard du cahier des charges initial. Ses chefs de projet ont appris à faire
des estimations avec un argumentaire solide, à établir des plans clairs et à négocier
les engagements des intervenants. Ils ont aussi appris à rapporter régulièrement et
justement la progression de leurs projets. Ainsi, lorsqu’ils constatent une déviation
significative quant aux délais, aux budgets, aux charges par exemple, ils savent rapide-
ment proposer les actions qui s’imposent et les suivre jusqu’à fermeture. La Direction
peut compter sur des statistiques fiables, qui lui donnent l’heure juste au regard des
objectifs commerciaux que la société a établis : est-ce qu’on diminue les coûts de
production ? Veut-on mettre des produits sur le marché plus vite ? Augmente-t-on la
qualité des produits ? Autant de questions qui trouvent réponses dans une organisation
de niveau de maturité 2 puisqu’elle s’est dotée d’une infrastructure de mesures alignée
sur ses objectifs commerciaux. Mais ce n’est pas tout ! Des renseignements objectifs
sont fournis quant au respect des normes et les non-conformités sont suivies jusqu’à
leur correction. Ses rapports avec ses fournisseurs, choisis en fonction de leur capacité
réelle de livrer et non au hasard des préférences personnelles, se tiennent sous le signe
du respect des engagements clairement établis. Enfin, une organisation de niveau
de maturité 2 déploiera un environnement qui permet de garder le contrôle sur les
innombrables produits d’activité de tous ses projets. Tout un programme comme on le
voit. Pas étonnant que le passage de l’indiscipline à la discipline ressemble au passage
plein de défis de l’adolescence !
7.1 Interprétation de l’objectif générique GG2 et des pratiques génériques GP2.1 à GP2.10 67
7.1 INTERPRÉTATION DE L’OBJECTIF GÉNÉRIQUE GG2

ET DES PRATIQUES GÉNÉRIQUES GP2.1 À GP2.10
Avant de décrire les sept domaines de processus qu’on retrouve dans la représentation
étagée au niveau de maturité 2, réglons d’abord le cas de cet objectif générique qui se
trouve dans tous les domaines, le GG2, et les GP2.n, les pratiques génériques qui y
sont associées. Parlons d’abord de l’objectif.
Plan
Directive du processus
Supervision
Direction
Ressources
AQ
GP2.1 GP2.2
GP2.10
GP2.3
GP2.9
GG2 –
Processus Responsabilités
DISCIPLINÉ
GP2.8 GP2.4
GP2.7 GP2.5
Suivi 7 GP2.6
Parties Gestion Formation

prenantes de configuration
Figure 7.1 — Les dix pratiques génériques

qui soutiennent l’objectif générique du niveau de maturité 2 ou GG2.
GG2 Institutionalize a Managed Process GG2 Institutionnaliser le processus

en tant que processus discipliné
The process is institutionalized as a defined Le processus est institutionnalisé

process. en tant que processus discipliné.
Deux mots lourds de sens se remarquent dans ce texte : institutionnalisé et

discipliné. Le concept même d’objectif générique est lié à celui d’institutionnalisation.
D’ailleurs, on dit souvent que les pratiques génériques sont des pratiques d’institution-
nalisation. On veut dire par là que sans celles-ci, il sera très difficile de pérenniser
les processus. Dès que les personnes ayant défini un nouveau processus quitteront
l’organisation, les projets ne respecteront plus le processus en question en l’absence de
directive claire ou de moyens appropriés par exemple. Ces pratiques de directive ou de

moyens suffisants assurent une bonne généralisation des autres pratiques du domaine
de processus. C’est ce qu’on appelle l’institutionnalisation. On retrouvera ces termes
« Le processus est institutionnalisé » dans le libellé de l’objectif GG3 également.
Mais restons-en pour l’instant au GG2. L’autre mot-clé est « discipliné ». En anglais,
les auteurs utilisent le mot « managed » que je trouvais vague. Mais dans tous les cas,
ils auraient pu dire que le processus, au lieu d’être discipliné (ou « managed »), doit
respecter les 10 critères contenus dans les pratiques génériques GP2.1 à GP2.10 du
CMMI. En effet, c’est la façon la plus rigoureuse d’expliquer ce que le mot « discipliné »
veut dire dans le contexte particulier du CMMI. Regardons donc ce que sont ces
fameux 10 critères qui se cachent dans les dix pratiques génériques associées à l’objectif
générique GG2.
Rappelons encore que pour la représentation continue, ce sont exactement les
mêmes pratiques génériques que l’on retrouvera sous l’objectif générique GG2.
7.1.1 GP2.1 – Établir une directive organisationnelle

Établir et maintenir une directive organisationnelle traitant de la planification et de la mise
en œuvre du processus.
Cette pratique générique dit qu’une organisation doit s’engager, par le biais d’une
directive (policy en anglais), envers un domaine de processus sinon elle a bien peu de
chance de pérenniser son processus. J’ai tendance à décrire cette pratique comme celle
qui fait entendre la voix de la Direction clamant qu’on ne doit pas faire un projet sans
ceci ou cela (les incontournables). Le tout est documenté dans un document que l’on
nomme directive dans le CMMI (terme qui pourrait être repris tel quel ou qui pourrait
faire place à un terme équivalent dans une organisation) pour bien faire ressortir qu’il
s’agit d’une orientation de haut niveau mais néanmoins précise et qui doit être suivie
par tous. Ce n’est pas détaillé comme une procédure peut l’être. Une directive tient
en général sur une seule page voire moins. Elle est signée par la Direction pour lui
conférer son caractère solennel et officiel. Elle change peu sauf lors de modifications
importantes d’orientation. Dans une organisation certifiée avec ISO9001, on retrouve
souvent les directives dans le « Manuel Qualité » de l’organisation. Même si la pratique
GP2.1 est répétée dans chaque domaine de processus, cela ne veut pas nécessairement
dire que l’on doit avoir une directive distincte pour chacun des domaines. Une même
directive peut embrasser plusieurs domaines.
S’il est facile de comprendre le concept de directive, il arrive souvent lors
d’évaluations que les gens du site que l’on rencontre ne savent pas les identifier ou les
reconnaître. Il est vrai qu’on ne passe pas son temps à les consulter quand on a la tête
dans le guidon, dans des projets. Mais on devrait quand même sensibiliser les personnes
de l’organisation à l’existence des directives pour s’y référer en cas de questionnement
fondamental quant à l’opportunité de respecter tel ou tel aspect d’une approche de
développement. Les directives sont au processus ce que la constitution est à un pays.
Le principal problème pratico-pratique lors des évaluations de type SCAMPI ou
autre est de faire comprendre ce que l’on cherche avec GP2.1, tellement c’est trivial !
Pour des sociétés ayant des processus matures institutionnalisés depuis longtemps, on
en finit par oublier (et peut-on le reprocher ?) où est la fameuse directive ! Si on
pose la question directement : « Décrivez-nous brièvement la directive qui encadre vos
activités de... (gestion des exigences – REQM – et développement des exigences – RD – par
exemple) », la réponse est presque toujours une description plus ou moins longue de la
PROCÉDURE ou du PROCESSUS sous-jacent aux activités. Si on interrompt cette
description (parfois longue) : « Attendez ! Vous êtes en train de me définir votre façon
de faire détaillée (en passant, c’est quand même utile... mais pour GP2.2 !). Je cherche
plutôt à savoir à quel endroit je pourrais trouver un document signé par votre Direction et
qui clarifie l’obligation qui est faite à tous les projets d’appliquer cette façon de faire », on
obtient parfois une moue qui dit « Mais c’est évident ! Tout le monde fait ça ! On n’a pas
besoin de nous forcer à le faire ! ». Vous imaginez ce que donnerait une évaluation où
tout est parfait à l’exception du fait qu’on n’aurait pas de DIRECTIVES explicites ! La
pratique GP2.1 serait non satisfaite et donc l’organisation serait de niveau de maturité
1, même si absolument tout est nickel par ailleurs. L’effet un peu pervers de cette
pratique est d’amener des organisations à formuler des directives par simple souci
de conformité sans n’y trouver aucune valeur ajoutée. L’indice le plus évident d’une
telle approche « by the book » : la directive est quasiment calquée mot pour mot sur
le contenu du CMMI. On ne peut rien dire : la pratique GP2.1 est faite ! Mais c’est
quand même un peu dommage de ne pas profiter de la formulation de la directive pour
ajouter de la valeur via la démarche. Comment ? Mais en expliquant par exemple en
exergue de la directive POURQUOI il importe de faire ce qui suivra dans le texte de
la directive et ce, dans le contexte PRÉCIS de l’organisation. La directive jouera alors
un rôle pédagogique de haut niveau. De plus, il serait utile de revoir à chaque année
(ou aux deux ans) les formulations de directives et de les faire ré-autoriser, question
de monter à tous que la Direction assume pleinement son rôle de figure de proue et
de commandant du navire organisationnel. Mais revenons à REQM et RD. Dans la
plupart des sociétés que j’ai visitées, une seule directive couvre les deux domaines,
ce qui est assez logique compte tenu de leur forte affinité. En quelques lignes, on
expliquera pourquoi il importe de démarrer tout projet sur une base de compréhension
commune client/équipe projet, de clarifier le périmètre, de formuler le plus clairement
possible les exigences contre lesquelles on jugera si un projet a bien livré ce qu’il
devait livrer et d’en faire quelque chose de contractuel. On établira la distinction
entre formulation client (exigences client) et formulation équipe projet (exigences
système ou produit). On expliquera aussi que le maintien du cap sur le périmètre établi
n’ira pas sans quelques corrections inévitables. On dira alors pourquoi il importe de
baliser ces modifications (les documenter, les enregistrer dans le journal de bord, en
analyser les impacts et ré-approuver le « contrat » modifié). On établira clairement
que la traçabilité servira d’accélérant et de garantie d’exhaustivité à l’analyse d’impact
lors de demandes de modification. On précisera enfin pourquoi une validation hâtive
des exigences formulées est importante. Tout ça en une page ou moins si possible.
Enfin, il devra clairement être dit qu’aucun projet ne peut échapper à cette directive.
7.1.2 GP2.2 – Planifier le processus

Établir et maintenir le plan pour la mise en œuvre du processus.
Cette pratique porte sur la planification non pas du projet mais bel et bien de
chaque processus du CMMI en vue de réaliser le projet. La planification du projet sera
plutôt couverte par le domaine de processus Planification de projet (PP). Mais il y a une
planification plus fine qui porte sur chacun des aspects de chacun des domaines de
processus et c’est de celle-ci qu’il s’agit dans GP2.2.
Ainsi, pour institutionnaliser de façon disciplinée (niveau de maturité ou d’ap-
titude 2) la Gestion des exigences (REQM), il faudra que le chef de projet précise
comment se fera, dans son projet, la gestion des exigences. Assez souvent, le chef
de projet n’invente pas l’approche à suivre ; il référera plutôt à la méthodologie en
usage dans l’organisation et précisera les adaptations particulières à son projet. On
peut donc s’attendre à trouver dans un document (typiquement le plan de projet ou la
note de lancement ou le mandat de projet) généralement élaboré au début du projet la
description des façons de faire (des processus) pour chacun des domaines de processus.
Il y a un cas particulier de l’application de cette pratique auquel il vaut la peine
de s’attarder. Lorsqu’on applique GP2.2 au domaine de processus de Planification de
projet (PP), la pratique devient Établir et maintenir le plan pour la mise en œuvre du
processus Planification de projet. Autrement dit, il faut planifier le planning ! Certains
trouveront qu’on pousse le bouchon un peu trop loin. Encore une fois, il faut user de
sens commun. Un projet de trois mois ne doit pas prendre plus de quelques heures à
planifier. Planifier ces quelques heures ne peut prendre que quelques minutes. Mais il
faut les prendre, ne serait-ce que pour s’assurer qu’on a tous les éléments voulus pour
préparer le plan et que tous comprennent comment on prépare les estimations, par
exemple. Par ailleurs, dans le cas de méga-projets, il n’est pas rare que la planification
elle-même prenne quelques semaines, voire quelques mois. La pratique GP2.2 prend
alors tout son sens et ne ressemble plus du tout à un canon pour tuer une mouche !
7.1.3 GP2.3 – Fournir les ressources

Fournir les ressources adéquates pour mettre en œuvre le processus, développer les produits
d’activité et fournir les services couverts par le processus.
On ne peut sérieusement prétendre institutionnaliser un processus discipliné si on
ne se donne pas les moyens de ses ambitions. Ces moyens se traduisent en personnes,
en matériel, en locaux, etc. ; le CMMI les désigne sous le terme de « ressources ».
Attention de ne pas restreindre ceci qu’aux personnes (ressources humaines).
Il n’est pas facile, lors d’une évaluation, de vérifier la satisfaction de cette pratique à
cause du qualificatif « adéquates » qui est quand même assez subjectif ; en général, pour
y arriver, on peut demander l’opinion du plus grand nombre de personnes concernées
par le domaine de processus dans lequel on applique la pratique GP2.3. Je pose
souvent la question de la façon suivante : « Sur une échelle de 0 à 10 correspondant à
une satisfaction croissante, comment jugez-vous le soutien qu’apportent à votre projet les
ressources matérielles (ex. : espaces de travail) ? Les outils mis à votre disposition ? Les
lignes directrices et guides d’utilisation ? ». Pour ce qui est des ressources humaines, je
pose souvent cette question : « De façon générale, que pensez-vous du temps calendrier et
de la charge que l’on vous attribue pour faire le travail qui vous est assigné ? ». Certes, on
peut s’attendre à ce que les réponses ne frisent pas la perfection ; il est assez rare qu’on
ne trouve rien à redire. Mais entre un 7 ou 8 sur dix (très bon) et un 2 ou 3 sur dix
(piètre), il y a une marge !
7.1.4 GP2.4 – Assigner la responsabilité

Assigner la responsabilité et l’autorité pour mettre en œuvre le processus, développer les
produits d’activité et fournir les services couverts par le processus.
On résume souvent la préoccupation que couvre cette pratique par la question
« Qui fait quoi ? ». Pour chaque projet, il faut que les rôles et responsabilités soient
clairement établis et assignés nominativement pour les activités de chaque processus. Il
arrive assez souvent que l’on assigne des rôles à un groupe sans nommer spécifiquement
les intervenants, se gardant la souplesse en cours de projet d’affecter au moment
opportun la (ou les) personne(s) disponible(s) et appropriée(s). Ceci est tout à fait
acceptable, à moins que par ailleurs, on découvre que cette souplesse entraîne des
problèmes sérieux de respect des échéances car au moment où l’on a besoin des
ressources, elles ne sont jamais disponibles dans des délais raisonnables !
Il existe plusieurs façons de satisfaire cette pratique. On peut le faire dans une
section « organisation de projet » du plan de projet ; ça peut aussi se trouver dans des
descriptions de postes détaillant les activités de personnes affectées à des rôles donnés
dans les projets.
7.1.5 GP2.5 – Former les personnes

Former selon les besoins les personnes qui mettent en œuvre ou soutiennent le processus.
Pour chacun des domaines de processus, on doit simplement s’assurer que pour
réaliser le projet les personnes affectées aux activités de ce domaine de processus ont
été bien formées avant leur affectation (parfois dans une autre société ou un autre
poste). En général, dans un document distinct ou dans une section du plan de projet, le
chef de projet indique les stages particuliers ou les approches de mentorat qui devront
être suivis par les ressources du projet. Il peut aussi laisser une note à l’effet que toutes
les ressources maîtrisent déjà les connaissances requises par le projet.
Dans le CMMI, « former » ne veut pas nécessairement dire faire suivre des cours
magistraux. Il faut interpréter que la pratique exige de s’assurer que les personnes
impliquées ont les connaissances requises au moment voulu. Elles peuvent avoir
reçu ces connaissances dans une situation antérieure (à l’intérieur de l’organisation
actuelle ou dans une autre société) et on s’en est assuré au moment de débuter le
projet. Ceci arrive assez souvent avec les personnes de grande expérience. Mais on
doit quand même bien vérifier que ces personnes qui maîtrisent les techniques par
leurs antécédents connaissent aussi les règles INTERNES à l’organisation. D’autres
façons de « former » qui sont conformes au CMMI : le mentorat, l’auto-apprentissage,
la « formation sur le tas ». Mais dans tous les cas, on doit néanmoins s’assurer (et laisser
une trace qu’on l’a fait) que ces connaissances requises ont bel et bien été acquises.
Soulignons qu’il y a en Planification de projet (PP), une pratique spécifique (PP-
SP2.5) qui ressemble étrangement à GP2.5 ; la différence c’est qu’elle s’applique au
projet dans son ensemble alors que GP2.5 s’applique au domaine de processus.
7.1.6 GP2.6 – Contrôler les produits d’activité

Mettre les produits d’activité sélectionnés du processus sous le niveau de contrôle approprié.
Chacun des domaines de processus entraîne la production d’un certain nombre de
produits d’activité. Ceux-ci seront développés par les gens du projet et pourront passer
d’un statut de « brouillon », à « proposé », à « vérifié », à « remis pour approbation »,
à « approuvé » – toutes ces appellations de statut n’étant ici que des exemples ; à
travers ces étapes, un document pourra faire l’objet de plusieurs versions. Parfois, il
faudra pouvoir retourner à une version antérieure. Aussi, il faut que les personnes du
projet sachent à quel(s) endroit(s) retrouver les produits d’activité ainsi que les clés
d’accès (si les documents sont à accès limité). Tous ces aspects doivent être clarifiés
dans un document distinct ou dans une rubrique du plan de projet, pour chacun des
domaines de processus. C’est ce qu’on appelle la gestion de configuration.
En fonction des directives appropriées au sein de l’organisation ou du projet, la
formulation de cette pratique ouvre la porte à un mode qui peut être moins rigoureux
de gestion des composants puisqu’elle utilise les mots « niveau de contrôle approprié ».
Il peut arriver que certains composants (par exemple des documents intermédiaires)
ne requièrent pas vraiment tout l’attirail d’une gestion de configuration poussée avec
référentiel contrôlé ; par exemple, une simple liste des modifications en début de
document (tel qu’imposé par ISO 9001 d’ailleurs) pourrait suffire.
Contrairement au domaine de processus Gestion de configuration (CM), qui parle
des pratiques mêmes de la gestion de configuration en général, GP2.6 appelle, pour
un domaine de processus donné, les pratiques de CM et vérifie qu’elles sont déployées
pour les produits d’activité du domaine de processus en question.
7.1.7 GP2.7 – Identifier et impliquer les parties prenantes concernées

Identifier et impliquer les parties prenantes concernées par le processus comme prévu dans le
plan.
Cette pratique vise à s’assurer de la participation au moment opportun des
personnes qui doivent être impliquées dans les activités d’un domaine de processus.
On voudra éviter d’impliquer trop de monde pour rien tout en s’assurant que tous ceux
qui doivent être impliqués le sont. Il faut aussi préciser les attentes vis-à-vis chacun.
Dans certains cas, on peut s’attendre à une participation active et obligatoire ; dans
d’autres, on peut s’attendre à recevoir des commentaires au besoin.
Il arrive assez souvent que dans un projet on traite la GP2.4 (responsabilité) en
même temps que la GP2.7 (partie prenante) par le biais d’une grille de rôle vs. les
types d’interventions attendues (autorise, réalise, commente, participe).
Soulignons qu’il y a en « Planification de projet » (PP), une pratique spécifique

(PP-SP2.6) qui ressemble étrangement à GP2.7 ; la différence c’est qu’elle s’applique
au projet dans son ensemble alors que GP2.7 s’applique au domaine de processus.
7.1.8 GP2.8 – Surveiller et contrôler le processus

Surveiller et contrôler le processus vis-à-vis son plan de mise en œuvre et prendre les actions
correctives appropriées.
Pour assurer le bon niveau de discipline dans chaque domaine de processus, on ne
peut faire autrement que de surveiller le déroulement du processus en question. Ceci
se fait généralement à l’aide d’indicateurs qualitatifs ou, encore mieux, quantitatifs.
A-t-on fait suffisamment d’essais ? Combien ? A-t-on réalisé assez de revues par les
pairs ? Combien ? Combien a-t-on découvert de défauts ? Autant de questions qui,
si on connaît les réponses, démontrent que l’on suit bien ce qui se passe dans le
déroulement des processus.
Contrairement au domaine de processus Surveillance et contrôle de projet (PMC), qui
parle des pratiques mêmes de surveillance en général, GP2.8 appelle, pour un domaine
de processus donné, les pratiques de surveillance et vérifie qu’elles sont déployées pour
les activités du domaine de processus en question.
La principale difficulté avec cette pratique est donc de comprendre ce qui la
distingue des pratiques spécifiques (les « SP ») que l’on trouve dans PMC. Autrement
dit, un chef de projet qui fait bien les pratiques décrites en PMC ne fait-il pas,
inévitablement, les GP2.8 de tous les domaines de processus ? L’expérience montre
que non. Il arrive que les rapports (et revues et réunions afférentes) d’avancement de
projet rendent bien compte de la progression générale du projet (consommation des
charges, reste-à-faire, état du budget, statut sur les délais, étapes à venir, révision des
risques, etc.) sans spécifiquement faire le point sur des aspects pourtant importants
de chacun des domaines de processus. Ainsi, si un chef de projet applique mal la
GP2.8 à REQM (Gestion des exigences) et RD (Développement des exigences), on ne
trouverait pas dans son rapport d’avancement de projet d’information sur le nombre
de demandes de modification aux exigences reçues, traitées, en suspens ; ou sur la
charge de travail spécifiquement consommée à analyser l’impact des demandes de
modification ou à établir les exigences au départ ou à les valider ; ou sur le nombre
d’exigences... bref des informations spécifiquement reliées au progrès du travail de type
RD et REQM. Lors d’une évaluation, on cherche des traces de telles informations
périodiquement rapportées et aussi de situations documentées (par exemple dans les
comptes-rendus de réunions d’avancement de projet) où un problème détecté grâce à
ces informations a été discuté et a donné lieu à une action corrective. Un cas classique
serait la trop grande volatilité des exigences. Lorsqu’on rapporte périodiquement le
nombre de demandes de modification aux exigences reçues et qu’on se dote d’un
indice de volatilité, on peut déclencher une action spéciale (par exemple rencontre au
sommet avec le client pour revoir le périmètre d’un projet) si les données réelles nous
rapprochent d’un seuil critique de volatilité. Ou encore, si on constate une croissance
indue de la charge de travail requise pour l’analyse d’impact lors de demandes de
modification, on peut plus facilement déclencher une action corrective (par exemple,
est-ce que mon équipe a bien établi la traçabilité et l’utilise-t-elle ?).
7.1.9 GP2.9 – Évaluer la conformité de manière objective

Évaluer de manière objective le respect par le processus tel qu’appliqué et par les produits
d’activité sélectionnés de la description du processus, des normes et des procédures qui
devaient être respectées et traiter les non-conformités détectées.
Cette pratique générique nous rappelle que pour chacun des domaines de processus,
les activités et les produits d’activité doivent être déclarés conformes aux normes en
vigueur et que cette déclaration doit être faite par quelqu’un qui demeure objectif.
L’application de la GP2.9 à des processus comme RD (Développement des exigences)
et REQM (Gestion des exigences) par exemple, garantit qu’en déployant les pratiques
spécifiques (les « SP ») de PPQA, on va effectivement s’attarder aussi aux activités
(processus) et produits d’activité de RD et REQM spécifiquement. La GP2.9 dit, en
quelque sorte, « N’oubliez surtout pas d’appliquer PPQA ici, en RD et REQM ! ». Alors
que va-t-on effectivement vérifier ? Par exemple que les demandes de modification aux
exigences sont renseignées conformément aux procédures en place ; que les exigences
passent effectivement par le processus de validation prévu ; que les exigences font
l’objet d’un accord entre le client et le projet ; etc. En évaluation, on demandera qu’on
nous montre des rapports d’audits internes (ou l’équivalent) montrant clairement (par
exemple via une « checklist ») que ces aspects ont été vérifiés ; on pourra demander
qu’on nous montre un cas de non-conformité rapportée et en suivre le parcours jusqu’à
sa résolution.
Contrairement au domaine de processus Assurance qualité processus et produit
(PPQA), qui parle des pratiques mêmes de l’assurance qualité en général, GP2.9
appelle, pour un domaine de processus donné, les pratiques de PPQA et vérifie qu’elles
sont déployées pour les produits d’activité et les activités du domaine de processus en
question.
7.1.10 GP2.10 – Passer le statut en revue avec la hiérarchie

Passer en revue avec la hiérarchie les activités, le statut et les résultats du processus et
résoudre les problèmes.
Pour obtenir un processus discipliné, le CMMI demande par le biais de cette
pratique de tenir la Direction et le management intermédiaire au courant du statut de
ce processus dans chaque projet. Par exemple, où en est-on avec la solution technique ?
Avec les essais d’acceptation ? Etc. Autant de questions qui doivent être répondues, au
bon niveau de granularité. Remarquons que la formulation de la pratique laisse toute
la place voulue pour utiliser son bon jugement : son patron immédiat, un chef d’équipe
par exemple, demandera plus de détails que la Direction. Il faut savoir s’ajuster au bon
niveau.
Interprétation des pratiques spécifiques dans les domaines de processus... 75
Dans plusieurs des organisations que j’ai visitées, cette pratique est institutionna-
lisée par le biais de rapports à la Direction, souvent doublés de présentations, soit
via des réunions de comité de gestion ou de comité de projet. Dans ces rapports et
présentations, on doit s’assurer de couvrir suffisamment les sujets visés par les différents
domaines de processus qui sont pertinents pour l’organisation et les projets. Quand on
fait bien la pratique GP2.8 (voir précédemment) et aussi PMC (Surveillance et contrôle
de projet), en général on fait bien GP2.10 qui est alors simplement la suite logique du
« reporting ». Le même processus de rapport d’avancement de projet couvre souvent le
« reporting » à tous les niveaux de l’organisation.
7.2 INTERPRÉTATION DES PRATIQUES SPÉCIFIQUES

DANS LES DOMAINES DE PROCESSUS DE LA
CONSTELLATION DEV AU NIVEAU DE MATURITÉ 2
Je rappelle que je n’ai pas la prétention de proposer une traduction officielle de tout
le modèle CMMI. Cette tâche ambitieuse n’aurait pu être complétée dans des délais
raisonnables et aurait exigé des charges et des budgets considérables. Je propose donc
une traduction ciblée des pratiques et des objectifs de tous les domaines de processus,
fidèle à ma propre compréhension des pratiques du CMMI, le tout validé par des
experts indépendants. De plus, je donne sous chaque pratique quelques explications
additionnelles pour mettre en lumière les aspects qui me semblent, lors d’une première
lecture, moins évidents. Ceci sera, je l’espère, particulièrement utile puisque ces
commentaires ont été écrits suite aux expériences que j’ai vécues sur le terrain. Dans la
colonne de gauche, j’ai repris textuellement le contenu du CMMI avec l’autorisation
du SEI. Le lecteur pourra ainsi comparer les textes anglais et français et se faire sa
propre opinion sur l’interprétation à donner au texte de la pratique en anglais. Enfin,
en consultant les suppléments en ligne sur le site web de Dunod, le lecteur trouvera
une représentation schématique de chacun des domaines de processus.
Pour les domaines de processus qui seraient exclusifs aux constellations SVC et
ACQ, il faut se référer aux annexes pour la traduction des intentions et des objectifs
spécifiques de ces domaines ainsi que la traduction des pratiques spécifiques associées.
7.2.1 Gestion des exigences
Gestion des exigences – un domaine de processus de la catégorie Gestion de

Projet dans la représentation continue.
Ce domaine de processus se retrouve dans les trois constellations (DEV, SVC et ACQ)
du CMMI ; il fait partie du tronc commun du CMMI.
REQM Requirements Management Gestion des exigences
The purpose of Requirements Management L’intention de Gestion des exigences (REQM) est
(REQM) is to manage requirements of the project’s de gérer les exigences des produits et composants
products and product components and ensure de produits du projet et d’assurer la cohérence
alignment between those requirements and the entre ces exigences et les plans et produits
project’s plans and work products. d’activité du projet.
Il ne faut pas confondre la Gestion des exigences avec la Définition des exigences. Au
niveau de maturité 2, dans la représentation étagée, la Gestion des exigences suppose
que des exigences sont déjà formulées et donc disponibles. Ce domaine de processus
focalise sur la compréhension initiale des exigences (en vue de préparer un devis) et
sur le traitement que l’on accordera aux demandes de modifications. Au niveau de
maturité 3, toujours en représentation étagée, on verra au prochain chapitre que la
Définition des exigences portera plutôt sur l’activité de formulation même des exigences.
Il est évident que la charge principale du domaine de processus (RD) se situe surtout
en amont du projet, quoique chaque exigence additionnelle, en cours de projet, exige
aussi une activité de formulation. La charge de Gestion des exigences (REQM) se
répartit quant à elle tout au long du projet puisque les demandes de modification
peuvent survenir à tout moment.
Gérer les exigences
SG1 Manage Requirements SG1 Gérer les exigences
Requirements are managed and inconsistencies Les exigences sont gérées, et les incohérences
with project plans and work products are avec les plans et les produits d’activité sont
identified. identifiées.
Il n’y a qu’un seul objectif spécifique dans le domaine de processus Gestion des
exigences. Il couvre donc à lui seul tout le contenu spécifique au domaine de processus.
Celui-ci englobe essentiellement l’activité de gestion des demandes de modification
au fil de l’eau. Aussi, on y exige la recherche et la correction des incohérences entre
les composants déjà développés, sur la base des exigences acceptées par le projet, et
les exigences qui seraient modifiées suite à une demande de modification.
SP1.1 UnderstandRequirements SP1.1 Comprendre les exigences
Develop an understanding with the requirements Développer une compréhension commune des
providers on the meaning of the requirements. exigences et de leur signification avec ceux qui
les ont fournies.
Sur réception du cahier des charges par exemple, on demande aux intervenants
dans le projet de s’assurer qu’ils comprennent bien ce que veulent dire les exigences.
On tiendra par exemple des rencontres pour passer les exigences en revue ou encore
7.2 Interprétation des pratiques spécifiques dans les domaines de processus... 77
on collectera les commentaires de façon à permettre à ceux qui les utiliseront comme
point de départ de leurs activités de démarrer du bon pied.
Si on veut atteindre le niveau 2 de maturité organisationnelle (qui exige de
satisfaire REQM), mais qu’on n’a pas encore institutionnalisé une approche disciplinée
de clarification d’exigences (par exemple, des séances « JAD » ou des interactions
actives et organisées avec son client pour formuler des « use cases ») ni d’approche
disciplinée pour bien documenter un référentiel d’exigences – ce qui est plutôt couvert
dans RD Développement des exigences, il faudra néanmoins démontrer que l’on a
une approche disciplinée pour que l’équipe projet acquière quand même une bonne
compréhension des exigences du client qui se matérialise par un accord explicite sur
celles-ci, ce qui ne peut évidemment se faire sans documenter ces fameuses exigences !
SP1.2 Obtain Commitment to Requirements SP1.2 Obtenir l’engagement

sur les exigences
Obtain commitment to requirements Obtenir des participants au projet

from project participants. leur engagement sur les exigences.
Pour donner suite à la pratique précédente, on demande aux participants de

démontrer explicitement, au moyen de signatures par exemple, qu’ils sont prêts à
entreprendre leurs activités sur la base des exigences qu’ils ont passées en revue.
La pratique nous demande d’obtenir un engagement quant aux exigences. Le libellé
court de la pratique laisser planer le doute sur l’acteur principal qui doit s’engager.
Mais le libellé long, l’officiel, ne laisse planer aucun doute : c’est bien de l’équipe
projet (les « participants ») qu’il s’agit et non du seul client (la compréhension avec
le client étant couverte par SP1.1). Les participants qui utiliseront en entrée les
exigences se commettent et déclarent qu’ils ont bien compris ces exigences et sont
donc prêts à préparer un devis puis à se mettre à l’œuvre pour le développement des
composants qui vont satisfaire les exigences. Comme REQM doit se redéployer chaque
fois qu’une demande de modification survient, il est normal de revérifier avec les
participants au projet qu’ils sont toujours d’accord pour poursuivre le travail, souvent
avec un réajustement du devis, une fois qu’une demande de modification a été reçue
et analysée. Dans la plupart des organisations, des réunions de démarrage permettent
de bien noter et de documenter ces engagements au début du projet. Puis, chaque
demande de modification doit être ré-acceptée par les intervenants. En général, elle
est « endossée » par les parties prenantes.
La façon la plus fréquente que je retrouve sur le terrain pour satisfaire la pratique
REQM-SP1.2 est ce que l’on appelle souvent « réunion de lancement » (« kick off
meeting »). Ceci suppose évidemment que la pratique REQM-GP2.7 est faite : cette
pratique générique, rappelons-le, vise à identifier clairement qui on fera intervenir
dans la réunion de lancement pour confirmer leurs engagements par rapport aux exi-
gences. La réunion de lancement est la plupart du temps constituée de plusieurs séances
ou de suivis pour résoudre les points soulevés par les intervenants. Éventuellement,
tous se sentent capables de donner leur accord et la pratique SP1.2 est ainsi bouclée.
La faiblesse la plus courante est d’oublier d’inviter des groupes « périphériques » (par
exemple, le groupe qui doit faire les tests d’acceptation ou d’intégration, l’unité qui
devra déployer la solution en production, etc.) qui ne sont pas perçus comme ayant
un rôle majeur en cours de projet dans les étapes de construction mais qui pourtant
seront impactés à un moment quelconque du déroulement du projet.
Tous ceux qui ont participé à des projets savent que les exigences évoluent en
cours de projet. Il importe qu’un mécanisme de gestion soit déclenché à chaque
fois qu’une demande de modification est formulée par le client. Par exemple, les
groupes de développement tiennent un registre, souvent automatisé, des demandes
de modification. Ils peuvent ainsi retracer l’origine et les étapes accomplies depuis la
réception de la demande, l’analyse des impacts et la décision prise.
SP1.3 Manage Requirements Changes SP1.3 Gérer les modifications aux exigences
Manage changes to requirements Gérer les modifications aux exigences au fur

as they evolve during the project. et à mesure de leur évolution en cours de projet.
Bien qu’elle joue un rôle critique pour éviter les dérives incontrôlées du périmètre
d’un projet (« scope creep »), la pratique REQM-SP1.3 est assez simple à comprendre et
pose rarement des problèmes d’interprétation. Lorsqu’on l’applique, on peut facilement
en montrer les traces : formulaire papier ou électronique complété pour chaque
demande de modification aux exigences, informations sur les impacts de cette demande
sur ce qui a déjà été développé et décision d’acceptation ou de rejet. La plupart
des grandes organisations s’outillent d’une sorte de banque de données couplée à
la messagerie électronique pour accuser réception, annoter la demande, lister les
modifications requises, en faire l’estimation et proposer une solution au client. Un
journal de bord manuel et un échange de courriels peuvent aussi satisfaire aux besoins
d’un petit projet.
SP1.4 Maintain Bidirectional Traceability SP1.4 Maintenir la traçabilité

of Requirements bidirectionnelle des exigences
Maintain bidirectional traceability among Maintenir une traçabilité bidirectionnelle

requirements and work products. entre les exigences et les produits d’activité.
Tel le Petit Poucet, les développeurs avisés laissent des cailloux derrière eux pour
retrouver leur chemin dans le labyrinthe des exigences qui se découpent et dans les
produits dérivés qui y sont associés. Il importe de retrouver son chemin du haut vers
le bas, du bas vers le haut et de façon latérale, entre composants. Si une erreur est
détectée lors d’un essai, on doit pouvoir remonter vers la source, jusqu’à la formulation
des exigences. Si une exigence change, on doit pouvoir descendre vers toutes les
décompositions qu’on a faites et les documents ou composants que l’on a tirés de ces
exigences. Enfin, on doit aussi pouvoir retracer les liens entre composants associés
(par exemple, un cahier d’essais associés à un sous-ensemble donné d’exigences). Il
existe aujourd’hui sur le marché des produits sophistiqués qui permettent de maîtriser
les milliers de liens entre composants que cette approche requiert. Mais il m’est arrivé
assez souvent de trouver des sites qui géraient la traçabilité par des tables EXCEL ou
même en WORD. Ces sites signalaient généralement (en GP2.3) que cet « outil »
devenait rapidement inadéquat chez eux tant les liens devenaient, avec le temps,
nombreux et les mises à jour fréquentes. Ils se tournaient alors vers des outils plus
sophistiqués.
Le plus difficile à trancher dans l’interprétation de cette pratique est le degré
d’exhaustivité attendue. Doit-on maintenir TOUS les liens des exigences de départ
jusqu’à tous les documents et objets livrés, en passant par tous les produits d’activité
intermédiaires ? Est-ce acceptable de ne pas tracer le code (par exemple) aux spéci-
fications techniques et de ne garder que les liens des exigences vers les jeux d’essais
d’une part et des jeux d’essais vers les modules de code d’autre part ? De façon pratique,
il m’arrive assez rarement de rencontrer des organisations qui maintiennent tous les
liens entre absolument tous les produits d’activité qui découlent les uns des autres. Je
m’assure alors que ce qui est fait est en accord avec la directive (fruit de la GP2.1) et
que les limites appliquées à la traçabilité ne soient pas rapportées comme causant des
problèmes à l’un ou l’autre des intervenants du projet.
SP1.5 Ensure alignment between Project SP1.5 Assurer l’alignement des produits
Work and Requirements du projet sur les exigences
Ensure that project plans and work products S’assurer que les plans de projet et les produits
remain aligned with the requirements. d’activité demeurent alignés sur les exigences.
Lorsqu’une modification est appliquée aux composants associés à une exigence

pour laquelle on a accepté une demande de modification, il faut pouvoir, le plus
rapidement possible, détecter tous les endroits à modifier dans le réseau souvent fort
complexe des composants. Par ailleurs, un des problèmes ayant le plus d’impact sur
les dépassements de coûts et de délais trouve sa source dans les incohérences que l’on
n’arrive pas à détecter dans ce réseau de composants. Une démarche permettant de
retracer les liens et de s’assurer de la cohérence des contenus doit être appliquée.
En plus de se déclencher lors des demandes de modifications reçues du client,
la pratique REQM-SP1.5 s’exerce en fait tout au long du projet et en de multiples
occasions, souvent associée à une activité de revue, de test, de rapport d’avancement...
Elle couvre l’action que l’on déclenche quand on se rend compte qu’un composant
(produit d’activité quelconque) n’est pas en ligne avec les exigences. Ceci devient
un cas particulier de déclenchement d’action corrective (comme on va en trouver
en PMC – Surveillance et contrôle de projet). Je dirais que la principale difficulté
d’interprétation pour cette pratique réside dans le fait qu’on arrive difficilement à isoler
cette pratique d’une activité plus globale qui l’intègre (par exemple, une relecture de
document, un test, etc.).
7.2.2 Planification de projet
Planification de projet – un domaine de processus de la catégorie Gestion de Projet

dans la représentation continue.
du CMMI ; il fait partie du tronc commun du CMMI. Cependant, dans la constellation
SVC, il porte le nom de Planification de travail (« Work Planning » - WP) puisqu’au lieu
de projet à date de fin établie, on traite des activités de services en continu. Partout le
mot « projet » est remplacé par « work » dans SVC.
De plus, dans cette même constellation SVC, le premier objectif spécifique compte
une pratique spécifique de plus que dans DEV. Celle-ci porte le sigle SP1.1 (voir son
contenu en annexe) dans SVC et, du coup, les sigles les autres SP1.n sont décalées
de +1 par rapport à DEV.
Par ailleurs, dans la constellation ACQ, le premier objectif spécifique compte aussi
contenu en annexe) dans ACQ (comme dans SVC) et, du coup, les sigles les autres
SP1.n sont décalées de +1 par rapport à DEV.
Enfin, dans cette même constellation ACQ, le second objectif spécifique compte une
pratique spécifique de plus que dans DEV. Celle-ci porte le sigle SP2.7 (voir son
contenu en annexe) dans ACQ ; comme c’est la dernière listée sous l’objectif SG2,
les sigles des autres pratiques ne sont pas différents vs. DEV.
PP Project Planning Planification de projet
The purpose of Project Planning (PP) is to L’intention de Planification de projet (PP)

establish and maintain plans that define project est d’établir et maintenir les plans
activities. qui définissent les activités de projet.
Ça semble si évident et pourtant ! « Le diable se cache dans les détails » diraient

les Américains. En effet, il faut voir tout ce qui se cache derrière une phrase toute
simple en apparence. Cela commence par des estimations qui dépassent le stade
de l’intuition, se poursuit par l’assemblage des composants requis pour dresser un
plan complet et signifiant, et se termine par une approbation de ce plan par tous les
intervenants concernés. Attention au mot plan ! Bien qu’il faille se garder, en mode
évaluation de processus, de juger si le contenu du document que nous appelons le
plan est « bon » ou « mauvais », il faut quand même utiliser son sens commun pour
distinguer entre le simple calendrier de travail et ce que le CMMI désigne par le mot
plan. Je préfère parfois parler de mandat de projet pour mieux expliquer que le concept
englobe plusieurs autres composants que le calendrier ou le graphique PERT. Lorsque
je vais évaluer le processus PP d’une organisation qui aspire au niveau de maturité 2
du CMMI, je m’attends à trouver, pour chaque projet, un ou plusieurs documents qui,
pris dans leur ensemble, m’informent sur la portée du projet, son ampleur, ses objectifs,
le client, le cahier des charges, les estimations et leurs hypothèses, le calendrier de
travail, l’organisation du projet, les outils de soutien, les rôles et responsabilités, etc.
Établir les estimations

Les paramètres de planification (ex. : la taille, la complexité, le nombre d’occur-
rences, etc.) regroupent les éléments d’information qui permettront de chiffrer les
charges et les coûts du projet.
SG1 Establish Estimates SG1 Établir les estimations
Estimates of project planning parameters Les estimations des paramètres de planification

are established and maintained. de projet sont établies et maintenues.
SP1.1 Estimate the Scope of the Project SP1.1 Faire l’estimation

de la portée du projet
Establish a top-level work breakdown structure Établir un découpage de haut niveau (WBS)
(WBS) to estimate the scope of the project. pour faire l’estimation de la portée du projet.
Le bon vieux principe de diviser pour régner est appliqué ici. Plus le découpage est
fin, plus les estimations portent sur de petits éléments, plus on augmente la précision
et plus on diminue les risques d’erreur grossière. De plus, dans plusieurs organisations,
on propose aux responsables de projet des décompositions types qui permettent de
facilement comparer un projet à un autre en utilisant les « lignes » identiques du WBS
(Work Breakdown Structure – Découpage ou décomposition) standard.
Le seul problème d’interprétation que j’ai rencontré avec cette pratique, et ce n’est
pas fréquent, vient du sigle WBS que l’on croit universellement compris mais qui ne
l’est pas toujours. En ce cas, il suffit généralement de demander aux chefs de projet
comment ils découpent le domaine ciblé par un projet pour éventuellement procéder à
l’estimation du projet et de leur demander dans quel document le résultat de ce premier
découpage est décrit. Je n’ai jamais rencontré de vrai problème d’interprétation en
procédant de cette façon pour vérifier si PP-SP1.1 est déployée ou pas ; dans la majorité
des cas, elle l’est. J’ai rarement vu, tellement ça semble naturel de procéder ainsi, un
processus d’estimation qui ne commence pas par découper le projet global en parties
plus fines, plus faciles à estimer.
SP1.2 Establish Estimates of Work Product SP1.2 Établir les estimations des attributs
and Task Attributes des produits d’activités et des tâches
Establish and maintain estimates of work product Établir et maintenir les estimations des attributs
and task attributes. des produits d’activité et des tâches.
Chaque ligne du WBS et chaque produit d’activité font l’objet d’une caracté-
risation au moyen d’hypothèses sur lesquels s’appuieront les estimations. Certaines
organisations les appellent « facteurs dimensionnants ». Il n’est pas toujours facile de
proposer des attributs quantitatifs. Parfois, on peut seulement catégoriser de façon
qualitative. En rationalisant le processus d’estimation, on prépare la capitalisation.
En effet, une base historique ne pourra être utile que dans la mesure où ceux qui la
consulteront sauront interpréter correctement, hypothèses à l’appui, les chiffres qu’elle
contiendra sur les projets passés.
Le principal défi que je rencontre en situation d’évaluation de processus est
d’expliquer la différence entre cette pratique et la PP-SP1.4 (aspect « charge » en
particulier) ci-dessous. Il faut réaliser que l’essence de SP1.2 est de pouvoir appuyer
ses estimations (entre autres, de charge) sur des bases objectives dont on pourra tirer
des enseignements plus tard. On se doit de documenter ses hypothèses si on veut
reconstruire ses estimations ou préparer de nouvelles estimations pour des projets
similaires mais où certaines variables devront être modifiées. En fait, la pratique SP1.2
nous demande de bien préciser les variables qui vont influencer les calculs de nos
estimations. La plupart du temps, la taille (ou le volume) de l’objet à construire ou à
modifier tiendra un rôle important en plus de la complexité de l’activité. En situation
d’évaluation de processus, on demande de voir quelque chose comme le document
où sont inscrits les paramètres et les formules qui ont servi à faire les calculs des
estimations.
SP1.3 Define Project Lifecycle Phases SP1.3 Définir les phases

du cycle de vie du projet
Define project lifecycle phases upon which Définir les phases du cycle de vie du projet
to scope the planning effort. sur lesquelles la planification est faite.
Avant de pouvoir projeter la décomposition d’activités du WBS (voir SP1.2 ci-

dessus) sur un calendrier de travail, il faut connaître quel cycle de vie sera adopté
pour le projet : quelle liste d’activités, quels produits d’activité types et surtout quel
agencement d’activités (règles de précédence) seront imposés : ceci constitue l’objet de
la pratique PP-SP1.3. La trame de notre calendrier doit être faite d’une série de phases
préétablies, lesquelles s’enchaînent ou se chevauchent. Les organisations encapsulent
souvent les cycles de vie autorisés dans ce que l’on appelle méthode développement ou
méthodologie de développement. On a fini par accepter le terme méthodologie tant il
est utilisé à la place du mot méthode, du moins en développement de projet. Il arrive
assez souvent que la méthodologie (vous voyez !) suggère plusieurs cycles de vie qui
conviennent à différents profils de projet. Il arrive aussi qu’une organisation impose un
et un seul cycle de vie. Cela varie en fonction de la diversité des projets susceptibles
de prendre place dans l’organisation. Enfin, on retrouve parfois les descriptions de
cycle de vie en tirés à part, en sus des guides méthodologiques. Le CMMI n’impose
évidemment pas la façon de faire mais seulement le fait que les cycles de vie doivent
être précisés. Il est rare qu’un projet crée dans le plan de projet même son propre
cycle de vie ; en général, le projet réfère à un cycle de vie déjà défini en dehors des
documents de projet.
SP1.4 Estimate Effort SP1.4 Estimer la charge et le coût

and Cost
Estimate the project’s effort and cost for work Estimer la charge et le coût du projet pour les
products and tasks based on estimation rationale. produits d’activité et les tâches en se basant sur
une approche raisonnée.
Le mot-clé dans cette pratique est « raisonnée ». Avant le niveau de maturité

2, les estimations sont souvent faites avec ce qu’on nomme souvent avec ironie le
« pifomètre ». Lorsque j’évalue une organisation de niveau de maturité 2, les chefs de

projet peuvent me montrer des feuilles (le plus souvent électroniques) d’estimation
qui décrivent l’argumentaire de l’estimation (hypothèses, calculs, résultats).
J’ai rencontré deux principaux défis au regard de cette pratique. Le premier est
que le libellé court de la pratique ne fait pas ressortir l’importance de l’approche
RAISONNÉE. Il faut rappeler aux sites que c’est le libellé long qui est la formulation
officielle de la pratique et en fonction de laquelle on doit interpréter le degré de
déploiement. Bien sûr, et heureusement, le libellé long demande de pouvoir suivre
rationnellement la façon dont on est arrivé au résultat du calcul de charge (attention :
on dit souvent « effort » au lieu de « charge » au Québec) et de coût à partir des
attributs établis dans la pratique SP1.1. Au niveau 2, on n’exigera pas que l’on
consulte des données historiques (données d’estimations de projets passés pertinents)
puisqu’elles n’existent pas toujours. Le second défi est que l’aspect financier (coût) est
assez souvent traité par un groupe ou une personne différente de l’aspect charge. En
situation d’évaluation, il faut donc dans ces cas rencontrer parfois non seulement ceux
que l’on nomme chefs de projets mais aussi d’autres personnes qui assistent les chefs
sur l’aspect « monétaire ».
Développer un plan de projet
SG2 Develop a Project Plan SG2 Développer un plan de projet
A project plan is established and maintained Un plan de projet est établi et maintenu
as the basis for managing the project. pour servir de base à la gestion du projet.
Je me souviens de l’époque où les traceurs de courbe sont devenus disponibles

comme périphériques d’ordinateur (c’étaient des mégamachines en ces temps révolus).
On s’amusait comme des fous à tracer des réseaux d’activités tous plus complexes les
uns que les autres (quand ce n’étaient pas des banderoles de meilleurs vœux !). C’était
bien pratique pour tracer les graphiques PERT des projets complexes et gigantesques !
Hélas, ils devenaient souvent des œuvres d’art qui ornaient les murs et qui, comme
de véritables papiers peints ou tapisseries, étaient rarement modifiées. Ce n’était plus
exactement les éléments de plan qui servaient de base à la gestion réelle du projet
mais plutôt des trucs pour épater la galerie.
SP2.1 Establish the Budget and Schedule SP2.1 Établir le budget et le calendrier
Establish and maintain the project’s budget Établir et maintenir le budget et le calendrier
and schedule. du projet.
Je soulignais dans la pratique PP-SP1.4 qu’il arrive assez souvent que des inter-
venants autres que les chefs de projet interviennent dans le chiffrage financier. Le
CMMI, souple comme toujours, n’impose pas le « comment » mais le « quoi » et
accepte donc que le processus d’estimation budgétaire implique un bureau de projets
par exemple ou la trésorerie. Comme nous le disions plus haut, il faut pouvoir doter le
projet d’éléments de gestion autres que le simple calendrier de projet dont parle aussi
cette pratique.
Le seul souci que j’ai sur le terrain avec cette pratique est d’ordre quasiment
sémantique et linguistique. On y parle de budget et de calendrier (en anglais
« schedule »). Réglons d’abord le cas du « calendrier ». Au Québec, comme on est collé
sur les États-Unis, on tombe souvent dans le piège des faux amis en matière de langue ;
on dit souvent et par erreur « cédule ». Quant aux cousins français, souvent prompts à
utiliser des termes anglais prononcés à la française, ils parlent plutôt du « planning ».
J’ai choisi le mot « calendrier » dans le sens de « calendrier de travail » espérant rallier
les lecteurs francophones de tous pays. Certains auraient préféré « échéancier » qui
est correct, je crois, mais peu usuel en France.
Passons au mot « budget ». Il m’a créé des soucis parce que je me demandais bien
ce qu’il fallait de plus qu’en PP-SP1.4 qui me demandait de calculer les coûts. Puis
j’ai réalisé qu’il ne suffit pas d’avoir le coût et la liste des articles (tâches ou biens)
correspondants à ces coûts. Il faut aussi établir à quels moments l’argent sera dépensé.
Il est donc tout à fait logique de parler de budget lorsqu’on ajoute la notion temporelle
(calendrier) à celle des coûts.
SP2.2 Identify Project Risks SP2.2 Identifier les risques du projet
Identify and analyze project risks. Identifier et analyser les risques du projet.
La plupart des organisations sérieuses accorde à cette pratique d’identification

et d’analyse des risques susceptibles d’affecter le projet l’attention qu’il convient, du
moins au démarrage du projet. Il faut croire que les catastrophes de si nombreux projets
de développement ont fini par porter fruit : « Chat échaudé craint l’eau froide », dit le
proverbe.
Réglons la question de la différence entre ces pratiques et tout le domaine de
processus Gestion des risques (RSKM) que l’on verra au niveau de maturité 3. Il faut
bien qu’il y ait un degré de sophistication accru dans le domaine RSKM pour que
les auteurs aient situé ce domaine à un niveau supérieur de maturité (3) en laissant
quand même une certaine activité traitant des risques au niveau de maturité inférieur
(2). Il est assez facile à la lecture de RSKM (sur lequel on reviendra dans le chapitre
qui suit) de comprendre en effet qu’on pousse pas mal plus loin dans ce domaine de
processus focalisant sur les risques en catégorisant ces risques, en préparant des plans
de réduction et de contingence, etc. Mais il fallait garder au niveau de maturité 2 un
degré suffisant de discipline (le niveau 2 étant, faut-il le rappeler, celui de la discipline)
qui se concrétise, au plan des risques, par leur identification et leur surveillance. Une
fois réglée cette question, je n’ai en général plus tellement de problèmes à vérifier
l’état de ces pratiques dans une organisation. La plupart du temps, dans une section du
document de planification de projet, on retrouve une liste des risques ; dans les gros
projets ou les projets critiques, on peut trouver un document tiré à part (par exemple,
un plan de gestion des risques) qui porte sur les risques et qui, dans certains cas, satisfait
à la fois les exigences de PP-SP2.2 et celles que l’on étudiera plus tard dans RSKM.
SP2.3 Plan Data Management SP2.3 Prévoir la gestion des données
Plan for the management of project data. Prévoir la gestion des données du projet.
Voilà une pratique qui m’a fait un peu suer (en réflexion) lors de mes premières
évaluations CMMI. J’avais du mal à voir la différence entre elle et la pratique CM-
SP1.1 (que l’on verra un peu plus loin en Gestion de configuration). J’avais l’impression
que « les données de projet » faisaient partie des entrées ou des sorties des activités
du projet et donc tombaient sous le couvert de la gestion de configuration appliquée
aux documents. Comment alors distinguer PP-SP2.3 et CM-SP1.1 ? Eh bien je n’avais
pas, je crois, tout à fait tort. Il y a une certaine redondance. Mais ce que le concept
de « données de projet » ajoute, ce sont tous les documents contextuels que l’on peut
devoir consulter pour construire son produit. Ainsi, les normes, les notes manuscrites,
les dessins, les extraits de presse, des références bibliographiques, en plus bien sûr
des documents d’entrée (ex. : exigences) ou de sortie (spécifications détaillées) plus
typiques. La façon simple de vérifier comment cette pratique est déployée est de
demander « Comment organisez-vous votre DOSSIER DE PROJET ? Qu’y retrouve-t-on
en cours de projet ? Qu’est-ce qu’on n’y retrouve jamais ? »
Les données du projet sont donc toutes les parcelles d’information qui seront
nécessaires à la gestion et à la réalisation du projet. On les regroupe dans ce que l’on
nomme souvent le « dossier de projet » dont la structure est souvent normalisée pour
en faciliter la consultation d’un projet à un autre.
SP2.4 Plan Project Resources SP2.4 Prévoir les ressources du projet
Plan for resources to perform the project. Prévoir les ressources pour réaliser le projet.
Le mot « ressources » englobe tous les types de ressources : humaines, matérielles,

documentaires, méthodologiques, logicielles, etc. Cette pratique ne cause générale-
ment pas de souci à partir du moment où on a bien compris qu’il ne s’agit pas que
des ressources humaines. Il peut certes arriver que plusieurs unités soient impliquées
dans cette pratique en ce sens qu’une unité spécialisée peut très bien avoir comme
mission de planifier l’infrastructure de soutien par exemple et que ceci peut même se
dérouler en dehors de tout projet (je pense à la notion de « capacity planning » des
« data centers » par exemple). En général, pour ce qui est des personnes, on les identifie
par profil jusqu’à ce qu’on obtienne, au moment voulu, leurs noms du responsable
de l’unité d’origine. Ceci peut même se passer peu de temps avant le tout début de
l’activité. Ceci n’est pas une « faute » du point de vue du CMMI en autant que le
besoin d’un tel type de ressource a été identifié, négocié et consenti et que l’affectation
spécifique arrive quand même à temps pour le démarrage de l’activité.
SP2.5 Plan Needed Knowledge and Skills SP2.5 Prévoir les connaissances
et aptitudes nécessaires
Plan for knowledge and skills needed to perform Prévoir les connaissances et compétences
the project. nécessaires à la réalisation du projet.
Il ne faut pas confondre la pratique générique GP2.5 sur la formation avec cette
pratique spécifique qui, incidemment et par le plus pur des hasards, porte le même
numéro mais en pratique spécifique : SP2.5 ! La GP2.5 couvre toujours un aspect
bien particulier de la formation. Cette pratique générique GP2.5, peu importe le
domaine d’ailleurs – pas seulement PP, se limite en effet aux connaissances requises
pour accomplir les activités bien précises du domaine de processus. La seconde, la
pratique PP-SP2.5, interpelle le chef de projet afin qu’il n’oublie pas de réfléchir à
la formation requise pour l’ensemble des intervenants sur l’ensemble du projet. Cela
se traduit généralement par une section du plan de projet qui porte sur le plan de
formation propre au projet ; dans de gros projets, cela peut même aller jusqu’à un
document distinct ne traitant que cet aspect.
SP2.6 Plan Stakeholder Involvement SP2.6 Prévoir l’implication

des parties prenantes
Plan the involvement of identified stakeholders. Prévoir l’implication des parties prenantes
identifiées.
En plus de planifier les ressources (PP-SP2.4), obtenir leurs engagements (PP-SP3.3

que l’on verra juste un peu plus tard), pourquoi cet ajout sur les parties prenantes ? Le
terme « parties prenantes » englobe bien toutes les ressources : celles qui « participent
en périphérie » autant que celles qui développent ! On planifie certes leur implication
en identifiant quelles ressources sont requises pour quelles activités ; on le précise
en établissant les rôles et les responsabilités des personnes dans le projet ; on peut
même utiliser une table de responsabilités que j’ai souvent vue dans des organisations
pour préciser le code d’intervention associée à chaque intervenant dans un projet (en
anglais RACI : R = Responsible, A = Accountable, C = Consulted, I = Informed). Ce peut
être aussi un organigramme de projets avec clarification des rôles et responsabilités
de chacun. Mais si « parties prenantes » regroupe les « ressources humaines » de la
pratique PP-SP2.4, pourquoi alors une PP-SP2.6 en plus de la SP2.4 ? En fait je crois
comprendre que la SP2.4 insiste sur l’identification de la charge requise par profil alors
que la SP2.6 porte sur les RESPONSABILITÉS (et, en ce sens, elle est intimement liée
aux pratiques GP2.7, permettant en quelque sorte d’invoquer ces pratiques GP2.7).
Quand faut-il réunir les gens ? Et qui convoquer ? À qui faire parvenir des copies de
compte rendu ? De qui attendre les commentaires avant de passer à une autre étape ?
Autant de questions qui trouveront ainsi leurs réponses quand on applique bien cette
pratique.
Cette pratique n’est en fait que l’aboutissement de toutes les PP-SP1.n et PP-SP2.n
qui précèdent. J’ai aussi déjà expliqué que le plan peut se matérialiser en un seul
SP2.7 Establish the Project Plan SP2.7 Établir le plan de projet
Établir et maintenir un plan couvrant l’ensemble

Establish and maintain the overall project plan.
du projet.
document. Il peut toutefois (et le plus souvent) être décomposé en plusieurs documents
complétés par divers intervenants. Songeons par exemple au plan AQ (assurance
qualité), au plan de gestion de configuration, au plan d’ingénierie système versus celui
d’ingénierie logicielle, etc. Si on a pris une telle approche très segmentée, il faut bien
que le chef d’orchestre assemble la partition...
En fait je n’ai jamais vu un seul cas de document unique nommé PLAN. Il y a au
moins un document texte et un calendrier géré par un outil tel que MS-Project. Mais
il peut aussi y avoir N documents papier ou électroniques derrière cette pratique. La
question à poser : « Si vous quittiez un projet tout de suite après avoir terminé la planification
d’origine, quel ensemble documentaire (document au sens large) légueriez-vous à votre
successeur pour qu’il prenne la relève ? ». Attention à une petite chose anodine mais oh
combien difficile à détecter parfois. Savez-vous à quel point le mot « plan » peut être
ambigu ? Le danger est que ce mot vous semble tellement trivial que vous interprétez
les réponses des personnes que vous pouvez rencontrer dans une organisation en
fonction de VOTRE compréhension mais qu’elles veuillent en fait exprimer tout
autre chose. Si au lieu de la question décrite à la fin du paragraphe précédent vous
demandez « quel plan légueriez-vous à votre successeur pour qu’il prenne la relève ? », on
pourra penser que vous cherchez à savoir si le chef qui part va transmettre son tableau
MS-Project (calendrier étant ici pris comme synonyme de plan !), ce qui vous ferait
passer à côté de la pratique SP2.7.
Obtenir l’engagement sur le plan
SG3 Obtain Commitment to the Plan SG3 Obtenir l’engagement sur le plan
Commitments to the project plan are established Les engagements sur le plan de projet
and maintained. sont établis et maintenus.
Ce principe de faire s’engager les divers intervenants est fondamental dans le

CMMI. On responsabilise les gens mais en contrepartie il faut bien leur donner
l’occasion de comprendre ce à quoi ils s’engagent et obtenir une preuve, quelque chose
qui laisse une trace de leur engagement. Ne poussons pas cette idée jusqu’à imaginer
qu’il faille nécessairement des signatures individuelles. Il arrive assez souvent que cette
recherche d’engagement passe par les représentants officiels, dans l’organisation, des
groupes impliqués. J’ai aussi rencontré des organisations qui, par choix culturel en
quelque sorte, exigent des engagements au niveau de chaque personne. Le CMMI sera
heureux avec l’une ou l’autre des approches, en autant que l’on respecte l’esprit de la
pratique.
SP3.1 Review Plans that Affect SP3.1 Passer en revue les plans
the Project qui ont des répercussions sur le projet
Review all plans that affect the project Passer en revue tous les plans qui ont des
to understand project commitments. répercussions sur le projet afin de comprendre les
engagements sur le projet.
Le lecteur relira le commentaire en PP-SP2.7 et comprendra ce que « TOUS les

plans » dans cette pratique SP3.1 veut dire. Elle peut même faire déborder le regard
du chef de projet vers les plans d’autres projets qui auraient une influence sur le sien.
Cette pratique pose un petit problème pratique en évaluation. Comment trouver
la preuve de ce type d’activité ? Même si on peut facilement croire qu’un chef de
projet aura bel et bien regardé tous les plans en entrée (comment pourrait-il faire
autrement ?) pour assembler son « puzzle » final, il n’est pas évident qu’il laisse une
trace qu’il a bien examiné tous les plans collectés. Je trouve ici que le CMMI peut
imposer une petite bureaucratie pas nécessairement utile ; de générer par exemple un
bref compte rendu de l’examen des documents identifiés en entrée comme plans ayant
servi dans la consolidation du plan de projet. Le pardonnera-t-on au CMMI ?
SP3.2 Concilier les niveaux de charge

SP3.2 Reconcile Work and Resource Levels
et de ressources
Adjust the project plan to reconcile available Mettre le plan de projet en cohérence avec les
and estimated resources. ressources disponibles par rapport aux ressources
estimées.
Si une même personne est sollicitée dans la même période, dans divers « sous-
plans », plus de 24 heures par jour au total, la surprise ne sera parfois découverte qu’au
moment de l’assemblage du plan d’ensemble. Cette pratique volera alors à sa rescousse
en invitant le chef de projet à l’indulgence à son égard... Remarquons que ceci est
vrai de ressources matérielles : un laboratoire de test qu’on ne peut utiliser de façon
concurrente par exemple.
Cette pratique pose le même problème pratique en évaluation que PP-SP3.1.
Comment en trouver la preuve ? Même si on peut facilement espérer qu’un chef
de projet aura négocié (souvent avec leurs unités d’origine) les participations des
personnes en fonction de leur disponibilité réelle et modifier son calendrier pour
s’appuyer sur la réalité résultante, pour assembler son plan « puzzle » final, il n’est pas
évident qu’il laisse une TRACE (preuve) qu’il a bien négocié et généré une nouvelle
version plus réaliste de son calendrier. Quoique, s’il utilise un outil tel que MS-Project,
on a de bonnes chances qu’il puisse nous montrer la version avant et celle après lissage
des ressources.
Dans les organisations que j’ai visitées, on obtient généralement des engagements
écrits de la part des unités qui vont intervenir dans le projet par des signatures ou des
déclarations d’acceptation du plan dans un compte rendu de rencontre de démarrage
SP3.3 Obtain Plan Commitment SP3.3 Obtenir l’engagement au plan
Obtain commitment from relevant stakeholders Obtenir l’engagement des parties prenantes
responsible for performing and supporting plan concernées qui sont responsables de réaliser
execution. le plan ou d’en soutenir la réalisation.
de projet. On ne recherche pas nécessairement les engagements de tous les individus

lorsque des personnes en autorité peuvent s’engager au nom de leur unité. Il faut
s’assurer que toutes les parties prenantes qui jouent un rôle soit de développement, de
management, de surveillance, de soutien, bref que tout le monde ait voix au chapitre
pour confirmer que les échéances sont compatibles avec les leurs, que les charges
allouées les satisfont, que les biens livrables identifiés et les critères d’entrée et de
sortie (ou d’acceptation) de ceux qui leur sont assignés leur conviennent au niveau
de leur description, etc. Par la suite, il faut surveiller (on verra cela en Surveillance et
contrôle de projet ou PMC) et s’assurer que la marchandise promise est bien livrée.
Une fois que les gens d’un site se sentent suffisamment en confiance avec un
interlocuteur qui amorce la discussion sur ce que signifie ENGAGEMENT sur le
plan, qu’est-ce qu’on entend assez souvent ? Des choses du genre : « Oui, le CMMI
demande un tel engagement mais que vaut cet engagement quand on a le fusil sur la tempe
pour accepter les diktats du marketing ou de la Direction ou du client qui nous tient par...
la barbichette disons ? Ou qu’une fois qu’on a énoncé un engagement sur X (charge), on
retranche de X environ 50 % ? En compétition pour une proposition, on veut gagner des
affaires donc on coupe. Et puis, en début de projet, qu’est-ce que l’on sait VRAIMENT ? Ou
plutôt qu’est-ce que l’on ne sait pas ? Comment être réaliste quand on ne sait pas le type de
solutions et sa complexité au regard d’un cahier des charges ? De toute façon, ne croyez-vous
pas utopique d’exiger le libre consentement des participants sur des projets d’envergure ? »
J’ai déjà entendu tout ça et bien plus.
En fait l’un de ces arguments me touche particulièrement : comment s’engager en
face d’un grand nombre d’inconnues. Il faut être compréhensif et réaliste. On accepte
généralement (a-t-on le choix ?) le fait que les engagements puissent être réalistes pour
la phase qui suit immédiatement et conditionnels pour les phases subséquentes. C’est
d’ailleurs dans les notes explicatives détaillées du CMMI en anglais. À l’impossible,
nul n’est tenu.
Les autres arguments me touchent moins quand je réalise que c’est parfois par
laxisme ou par paresse que l’on subit le sort de la grande coupe. En face d’estimations
sans argumentaires, intuitives, n’importe qui en autorité a beau jeu de sabrer à fond.
Mais si on applique bien ses pratiques PP-SP1.n et SP2.n, il faudra bien que l’on
discute sur la base des faits documentés dans notre argumentaire pour identifier ce que
l’on peut couper et ne peut pas couper. La discussion se situe alors sur le plan rationnel
plutôt qu’émotif. Et si on coupe d’autorité, il restera à réclamer de bien documenter et
surveiller le risque afférent à cette décision commerciale. Je suis assez mal placé quand
je visite une organisation pour juger du bien fondé d’une décision commerciale. Tout
ce que je peux vérifier c’est qu’elle soit bien cernée et suivie en risque après qu’on ait
laissé les parties prenantes expliquer leurs argumentaires...
7.2.3 Surveillance et contrôle de projet
Surveillance et contrôle de projet – un domaine de processus de la catégorie

Gestion de Projet dans la représentation continue.
SVC, il porte le nom de Surveillance et contrôle de travail (« Work Monitoring and
Control » - WMC) puisqu’au lieu de projet à date de fin établie, on traite des activités
de services en continu. Partout le mot « projet » est remplacé par « work » dans SVC.
Par ailleurs, dans la constellation ACQ, le premier objectif spécifique compte aussi
contenu en annexe) dans ACQ ; comme c’est la dernière listée sous l’objectif SG1,
les sigles des autres pratiques ne sont pas différents vs. DEV.
PMC Project Monitoring and Control Surveillance et contrôle de projet
The purpose of Project Monitoring and Control L’intention de Surveillance et contrôle de projet
(PMC) is to provide an understanding of the (PMC) est de fournir une appréciation de
project’s progress so that appropriate corrective l’avancement du projet de telle sorte que des
actions can be taken when the project’s actions correctives puissent être prises quand
performance deviates significantly from the plan. la performance du projet s’écarte de façon
significative du plan.
Imaginons le contrôleur aérien dans la tour. Il scrute les écrans et suit le mouvement
des avions. Si un signal capte son attention, il demande une action corrective. Il garde
le contrôle de la situation. Il peut très souvent arriver que les corrections demandées
soient faites par quelqu’un d’autre : le pilote d’un avion par exemple. Le domaine de
processus PMC demande au chef de projet d’endosser ce rôle de contrôleur de projet
dans sa tour de contrôle (en espérant que celle-ci ne soit pas faite d’ivoire sinon gare
au projet...).
Surveiller le projet par rapport au plan
SG1 Monitor the Project Against the Plan SG1 Surveiller le projet par rapport au plan
Actual project progress and performance are La performance et l’avancement réels du projet
monitored against the project plan. sont surveillés par rapport au plan de projet.
Cet objectif couvre l’aspect de veille active. Le chef de projet doit rester à l’affût
des signes vitaux du projet. Ses points de repère demeurent inscrits dans le plan, outil
précieux s’il en est !
Si le projet n’a pas sauvegardé les données de planification, en particulier celles
relatives à l’estimation, il aura bien du mal à confronter les informations courantes
avec ce qui devait normalement se passer ! Comment savoir si on a dépassé les
prévisions par exemple à mi-parcours ? Le projet avisé aura toujours le plan de projet
SP1.1 Monitor Project Planning Parameters SP1.1 Surveiller les paramètres

de planification de projet
Monitor actual values of the project planning Surveiller les valeurs réelles des paramètres de
parameters against project plan. planification de projet par rapport au plan de
projet.
sur sa table de capitaine, juste à côté des « écrans » (virtuels ou réels) qui donnent en
continu les données sur la situation actuelle, pour chacun des paramètres utilisés lors
de la planification.
Voilà une pratique qui, en quelques mots, décrit pourtant une bonne partie de la
vie d’un chef de projet : rester vigilant devant son tableau de bord pour surveiller
la progression du projet et être prêt à réagir si quelque chose vient à clocher !
Certains aspects de son tableau de bord seront couverts de façon plus spécifique dans
les autres pratiques SP1.n. On pourrait presque dire que la SP1.1 dit de garder un
œil sur l’ensemble de son tableau de bord alors que les autres PMC-SP1.n insistent
sur quelques « cadrans » de son tableau de bord. Sur le terrain, en évaluation, mes
membres d’équipe me demandent souvent quelle différence je fais entre PMC-SP1.1 et
la pratique générique GP2.8 que l’on doit décliner dans chaque domaine de processus.
Ma réponse est que la PMC-SP1.1 porte sur les paramètres d’ensemble du projet au
moment « t » (la charge consommée vs. estimée, les coûts réels vs. budgétés, l’atteinte
ou non des jalons dans le calendrier, etc.) alors que les GP2.8 porte sur les activités
qui sont décrites dans un domaine de processus. Certes, un chef de projet fait les deux
en même temps. Par exemple, il a un œil sur le cadran de la charge pour l’ensemble
de son projet (avec une petite marque en rouge dans le cadran pour indiquer le seuil
à ne pas dépasser et une petite aiguille pour indiquer la charge consommée) : il fait
alors de la PMC-SP1.1. Il a en même temps un œil sur une série de N cadrans associés
à chacun des domaines de processus. Ainsi, parmi le groupe de cadrans REQM, un
cadran indiquera combien de demandes de modification aux exigences ont été reçues ;
en y jetant un regard, le chef de projet fait alors de la REQM-GP2.8 pour s’assurer que
la volatilité des exigences demeure dans des zones acceptables.
SP1.2 Monitor Commitments SP1.2 Surveiller les engagements
Monitor commitments against those identified in Surveiller les engagements par rapport à ceux
the project plan. identifiés dans le plan de projet.
Cette pratique est intimement liée au calendrier puisqu’elle demande que le chef
de projet (ou la personne à qui on a affecté cette responsabilité) regarde le « cadran »
(pour poursuivre l’analogie développée dans la pratique précédente) des dates de
livraison promises pour voir si les intervenants de chaque livraison promise se sont
bien conformés à leurs promesses. En fait, cette pratique déborde de la notion de
dates promises vs. réelles pour aussi couvrir le contenu réel vs. promis de la livraison.
Bref, tous les types d’engagements (date, contenu, conformité à telle ou telle norme,
qualité, etc.). Je n’ai en général pas de grands problèmes à vérifier si cette pratique est
bien déployée. Dans tous les cas que j’ai vus, les projets tiennent des rencontres qui
permettent en général de bien couvrir cette pratique en passant en revue justement
les engagements avec les intervenants.
SP1.3 Monitor Project Risks SP1.3 Surveiller les risques de projet
Monitor risks against those identified in the Surveiller les risques par rapport à ceux identifiés
project plan. dans le plan de projet.
En Planification de projet, on a établi une liste des risques. Celle-ci doit être revisitée
périodiquement. Je constate dans les organisations que cette réévaluation des risques
survient généralement lors des revues de projet, la périodicité étant fixée en fonction
de l’ampleur et de la criticité du projet. Malheureusement, dans certains, je constate
que les risques que l’on a pris grand soin d’identifier au début du projet ne sont tout
simplement pas réévalués. Il est facile de le découvrir. On demande de voir la liste des
risques à une date X et on y trouve des risques associés à des événements déjà passés ;
par exemple, le risque de ne pas recevoir un composant à temps d’un fournisseur alors
qu’il a déjà été livré à l’équipe de projet depuis belle lurette.
SP1.4 Monitor Data Management SP1.4 Surveiller la gestion des données
Monitor the management of project data against Surveiller la gestion des données de projet par
the project plan. rapport au plan de projet.
Cet aspect de gestion des données a été planifié en PP. On fera périodiquement le
point sur le respect des règles par l’équipe de projet. Par exemple : conserve-t-on bien
dans le dossier de projet (ou ailleurs) les éléments dont on aura besoin plus tard soit
dans le projet même ou dans une perspective de capitalisation ?
SP1.5 Monitor Stakeholder Involvement SP1.5 Surveiller l’implication

Monitor stakeholder involvement against the Surveiller l’implication des parties prenantes par
project plan. rapport au plan de projet.
Ceux qui s’étaient engagés à transmettre des commentaires, l’ont-ils fait ? Ont-ils
participé aux rencontres prévues pour eux ? Cette pratique interpelle le projet sur
ces questions. Cette surveillance se fait souvent en même temps que celle décrite en
SP1.2 ci-dessus.
SP1.6 Conduct Progress Reviews SP1.6 Mener des revues d’avancement
Periodically review the project’s progress, Passer périodiquement en revue l’avancement,

performance, and issues. la performance et les problèmes du projet.
Il est très rare qu’un projet ne tienne aucune réunion d’équipe. Heureusement !
Même si le CMMI n’exige pas, à proprement parler, de telles réunions (des « revues »
pourraient être faites sans réunion, via des séries de courriels périodiques), c’est souvent
le seul moyen de passer en revue les signes vitaux du projet avec les divers intervenants.
Si un chef de projet déclenche périodiquement une tournée de sa paroisse pour
confesser ses ouailles une à une, cela respecte aussi l’esprit de la pratique. L’important
demeure de renseigner le capitaine du navire.
SP1.7 Conduct Milestone Reviews SP1.7 Mener des revues sur jalons
Review the project’s accomplishments and results Passer en revue les réalisations et les résultats
at selected project milestones. du projet à des jalons de projet sélectionnés.
En plus de la prise périodique des signes vitaux, on trouve dans tout plan de projet
qui se respecte des jalons, souvent en fin de phase. La pratique SP1.7 demande que
des revues, souvent plus formelles et décisionnelles quant à l’enchaînement vers la
phase subséquente du cycle de vie, soient menées. Je constate souvent la présence de
l’utilisateur ou du client à certaines de ces revues que l’on désigne fréquemment par
« revues de fin de phase ».
Seule difficulté dans les évaluations : obtenir une preuve tangible si un chef de
projet ne génère pas de compte rendu (même s’il ne s’agirait que de noter les décisions
prises). Autre situation vécue mais non problématique : dans certains cas, les réunions
de type PMC-SP1.6 sont si régulières et fréquentes que l’on juxtapose celles décrites
en SP1.7 à l’occasion d’une SP1.6. Le CMMI acceptera cette variante. L’exigence
porte essentiellement sur la liste des points de décision. S’il n’y a pas de preuves de
prise de décisions, alors il y a sans doute un problème qui se profile...
Gérer l’action corrective jusqu’à clôture
SG2 Manage Corrective Action to Closure SG2 Gérer l’action corrective jusqu’à clôture
Corrective actions are managed to closure Les actions correctives sont gérées jusqu’à clôture
when the project’s performance or results deviate lorsque la performance ou les résultats s’écartent
significantly from the plan. de façon significative du plan.
Il ne suffit pas de réagir aux alertes. Encore faut-il s’assurer que les actions
correctives sont effectivement prises et que l’alerte cesse, non pas par épuisement
des piles du système d’alarme, mais par le fait que le problème déclencheur a été
résolu.
Ce qui m’embête dans les pratiques sous-jacentes à cet objectif, c’est leur segmenta-
tion en trois pratiques séparées qui implique, lors d’une évaluation, de vérifier chacune
d’elle avec une preuve directe tangible.
Avant d’appuyer sur le bouton de panique, les intervenants feront bien de réagir
calmement à l’alerte en amassant toutes les données requises pour une prise de décision
sur l’action corrective la plus pertinente.
SP2.1 Analyze Issues SP2.1 Analyser les problèmes
Collect and analyze issues and determine Recueillir et analyser les problèmes
corrective actions to address them. et déterminer les actions correctives pour les
traiter.
Tel que je soulignais juste ci-dessus, comment montrer les preuves de déploiement
de cette pratique si on n’a pas conservé un argumentaire écrit des éléments d’infor-
mation collectés suite à la découverte d’un problème ? Je ne pense pas que ce sera
de la bureaucratie inutile si on produit des comptes-rendus succincts qui permettront
de toujours savoir où on en est dans la solution aux problèmes détectés et auront
l’avantage, en même temps, de servir de preuve lors d’évaluations.
SP2.2 Take Corrective Action SP2.2 Appliquer une action corrective
Take corrective action on identified issues. Prendre des actions correctives pour les
problèmes identifiés.
En toute sérénité, il faut alors appliquer l’action corrective qui peut faire intervenir
(c’est même le cas le plus fréquent) les pratiques d’autres domaines de processus. Ainsi,
on peut devoir réestimer la charge (PP), refaire une partie de la conception (TS), ou
encore ajouter une série d’essais dans le plan d’essais d’acceptation (VAL). Et quoi
encore ?
SP2.3 Manage Corrective Actions SP2.3 Gérer une action corrective
Manage corrective actions to closure. Gérer les actions correctives jusqu’à clôture.
Évidemment, on s’assurera que l’action corrective est bien menée à terme. Ceci se
détectera aisément si on a toujours pris la peine de lister les points d’action avec une
date cible et qu’on en fait un suivi périodique.
7.2.4 Gestion des accords avec les fournisseurs
Gestion des accords avec les fournisseurs – un domaine de processus de la

catégorie Gestion de Projet dans la représentation continue.
Ce domaine de processus se retrouve dans deux des trois constellations (DEV et SVC)
du CMMI. Il est absent de la constellation ACQ, ce qui est logique, puisque dans cette
constellation ACQ les pratiques d’établissement de contrat et de suivi du travail est
traité par des domaines de processus particuliers plus pointus.
SAM Supplier Agreement Management Gestion des accords avec les fournisseurs
The purpose of Supplier Agreement Management L’intention de Gestion des accords avec les
(SAM) is to manage the acquisition of products fournisseurs(SAM) est de gérer l’acquisition
and services from suppliers. des produits et services des fournisseurs.
Le domaine de processus SAM nous dit essentiellement qu’à chaque fois que l’on
fait intervenir un tiers par le biais d’un contrat, d’un cahier des charges, d’une licence,
d’une lettre traduisant la compréhension des engagements mutuels, on doit enclencher
un processus de gestion de la livraison du produit ou du service sous-traité. Remarquons
que le sous-traitant peut se situer en dehors de la même société que le projet ou en
dedans. Le cas est simple et courant dans le cas d’un sous-traitant ou fournisseur ou
prestataire externe : on fait la plupart du temps intervenir le département des contrats
ou des achats et on donne un caractère assez formel, voire légal et notarié, à l’accord
entre client (cette fois, c’est nous le client !) et l’entité qui va nous livrer le service ou
produit. Le CMMI n’empêche pas, loin de là, d’appliquer la même logique en interne,
dans la même société, envers un autre département. J’ai remarqué que le laxisme dont
a fait preuve dans le passé dans les cas de sous-traitance intrasociété devient parfois
une bonne raison pour tenter une approche plus disciplinée et que cela porte fruit en
amenant, si on sait éviter la sclérose d’un légalisme à tous crins, une approche plus
adulte des relations interdépartementales.
La version 1.2 du CMMI a apporté un changement un peu plus important dans ce
domaine de processus que dans la plupart des autres. En effet, dans la version 1.1 on
avait DEUX domaines de processus qui traitaient des relations avec les fournisseurs :
en plus de SAM, il y avait ISM ou Gestion des fournisseurs qui ne s’appliquait que dans
les cas précis où la discipline SS (Supplier Sourcing) était jugée applicable. Ce domaine
de processus venait se superposer au domaine SAM couvert. Pour la version 1.2, les
auteurs ont suivi la suggestion faite par plusieurs utilisateurs du CMMI d’imploser
ISM dans SAM et de mettre plus d’explications sous les pratiques pour aider à décider
jusqu’où il faut aller dans les différents cas de figure (fonctionnement plus ou moins
intégré avec ses fournisseurs). Du coup, ils ont fait sauter la discipline SS (Supplier
Sourcing) qui n’existe plus avec la version 1.2 du CMMI.
Si je négocie avec une SSII (consultants) la participation de n personnes qui vont
complètement s’intégrer à mon équipe du projet, vont rapporter au chef de projet et
vont suivre entièrement les processus de mon organisation, je peux alors considérer
qu’elles font partie du « personnel du projet » et ne pas appliquer SAM sur ce projet si
AUCUN autre produit ou service n’est acquis d’une tierce partie. On est alors dans une
situation de ce que mes amis français désignent par de la régie. On peut alors exclure
SAM du périmètre d’une évaluation de maturité au niveau 2. Il y aurait cependant
un inconvénient pour une organisation qui se ferait confirmer son niveau de maturité
sans SAM i.e. à ne soumettre AUCUN projet utilisant SAM. On se retrouverait
alors dans la situation qu’aucun projet examiné lors de l’évaluation ne permettrait de
vérifier le déploiement de SAM. En ce cas, le périmètre CMMI associé au niveau de
maturité décrété devra bien préciser que SAM n’a jamais été examiné. Un client qui
traite avec cette société pourrait être gêné par cette limite car sur un projet futur, on
pourrait avoir à sous-traiter ou à acquérir des produits sur étagère mais on n’aurait pas
su le rassurer sur sa capacité de le faire ! Mais si aujourd’hui encore plusieurs projets
ne font pas du tout appel à la sous-traitance (ce qui est une décision commerciale
tout à fait légitime et neutre d’un point de vue évaluation), quels projets peuvent
prétendre TOUT faire à neuf et n’intégrer aucun produit du marché ? Il devient donc
de plus en plus difficile de se soustraire totalement à SAM qui englobe l’intégration
de composants commerciaux autant que la sous-traitance.
Établir les accords avec les fournisseurs
SG1 Establish Supplier Agreements SG1 Établir les accords avec les fournisseurs
Agreements with the suppliers are established Les accords avec les fournisseurs sont établis
and maintained. et maintenus.
Quelle phrase simple ! Il faut vraiment lire les pratiques pour voir de quoi il en
retourne... Allons-y donc !
SP1.1 Determine Acquisition Type SP1.1 Déterminer un type d’acquisition
Determine the type of acquisition for each Déterminer le type d’acquisition pour chaque
product or product component to be acquired. produit ou composant de produit à acquérir.
Peu importe le moment où l’on fait ce choix, il faut déterminer si on fait ou si

on fait faire ou si on réutilise quelque chose d’existant. Et plusieurs options sont
souvent disponibles à l’acheteur : un produit commercial existant ou sur commande
(du « sur-mesure ») ?
SP1.2 Select Suppliers SP1.2 Choisir des fournisseurs
Select suppliers based on an evaluation of their Choisir des fournisseurs en s’appuyant

ability to meet the specified requirements sur une évaluation de leur aptitude à satisfaire
and established criteria. les exigences spécifiées et les critères établis.
La pratique (qui englobe la demande, la réception et l’analyse des devis fournis-

seurs) nous donne la clé du choix des fournisseurs : leur aptitude ! Et on établira
celle-ci par un examen rationnel qui implique très souvent le département des achats.
A-t-on songé à appliquer le CMMI dans le cas où on voudrait externaliser une partie
significative de son développement ? Certes je suis biaisé : vous me donneriez du
travail ! Mais c’est une suggestion tout ce qu’il y a de plus sérieux. L’acheteur peut
aussi appliquer bien d’autres approches pour rationaliser son choix de fournisseurs.
On me fait souvent remarquer que les choix sont parfois imposés, soit par des règles
d’alliances stratégiques, soit par le client, soit par la nature de l’activité sous-traitée
qui pourrait demander une expertise rarissime. Réglons les deux derniers cas : on
n’a tout simplement pas le choix et on traitera en gestion des risques les aspects
potentiellement critiques ou menaçants de ce choix imposé par la force des choses (ou
des gens...). Pour ce qui est de la liste courte des fournisseurs privilégiés, je chercherais
alors à appliquer en amont, lors de la constitution de la liste même, l’évaluation des
aptitudes des heureux élus. Évidemment, s’il s’agit d’affaires de cœur ou de portefeuille
entre le président et un fournisseur, alors je retombe en gestion des risques... ou je
peux préparer mon CV !
SP1.3 Establish Supplier Agreements SP1.3 Établir des accords avec le fournisseur
Establish and maintain supplier agreements. Établir et maintenir des accords

avec le fournisseur.
Notons simplement que cet accord peut prendre plusieurs formes, plus ou moins
légales : de la simple lettre d’accord au contrat notarié. Il faut sans doute passer un
peu de temps pour vérifier que les exigences qui ont été tracées vers les prestations
sous-traitées se retrouvent bien dans l’accord négocié.
Se conformer aux accords avec les fournisseurs
SG2 Satisfy Supplier Agreements SG2 Se conformer aux accords

avec les fournisseurs
Agreements with suppliers are satisfied Les accords avec les fournisseurs sont respectés
by both the project and the supplier. et par le projet et par les fournisseurs.
Encore un objectif si vague (mais qui reste tout à fait pertinent) que l’on doit
absolument lire les pratiques pour en comprendre l’essence et le sens...
SP2.1 Execute the Supplier Agreement SP2.1 Appliquer l’accord

avec le fournisseur
Perform activities with the supplier as specified Réaliser les activités avec le fournisseur telles
in the supplier agreement. qu’elles sont spécifiées dans l’accord.
Alors là, je me permets de dire aux auteurs du CMMI qu’ils n’ont pas fait fort.
Alors que pour la très grande majorité des pratiques, il me suffit de lire le texte de
la pratique pour en découvrir le sens de façon assez concrète, je ne peux m’arrêter
à cette lecture dans le cas de SAM-SP2.1 n’est-ce pas ? Comment savoir, si on ne
va pas dans le manuel pour y lire les sous-pratiques, que le CMMI espère que vous
ferez des rencontres techniques et managériales avec vos fournisseurs ? Que vous
examinerez quelques processus critiques déployés chez eux (par exemple, l’assurance
qualité) ? Voilà donc, hélas je dirais, une pratique qui force à descendre au sous-sol
(des sous-pratiques) pour trouver la lumière ! Je proposerais donc une reformulation
plus explicite : « Mettre en œuvre les moyens et activités requis pour assurer que les travaux
SP2.2 Accept the Acquired Product SP2.2 Accepter le produit acquis
Ensure that the supplier agreement is satisfied S’assurer que l’accord avec le fournisseur est
before accepting the acquired product. satisfait avant d’accepter le produit acquis.
du fournisseur se déroulent selon l’accord convenu et que le projet et l’organisation respectent

ses engagements vis-à-vis le fournisseur. »
Une forme particulière d’essai d’acceptation ou de revue formelle d’acceptation se
cache dans cette pratique.
Plus que d’accepter, il faut pousser plus loin et faire sien le service ou le produit
acheté ! Une fois passé le CAS de l’acceptation, il faut encore faire la place au
composant sous-traité, former son équipe aux techniques particulières qu’il peut exiger,
lui faire de la place (en espace plancher ou en espace disque par exemple), vérifier
comment appliquer la garantie prolongée du fournisseur et la protection contre les
vices cachés.
SP2.3 Ensure Transition of Products SP2.3 S’assurer du transfert des produits
Ensure the transition of the products acquired S’assurer du transfert des produits acquis
from the supplier. du fournisseur.
7.2.5 Mesure et analyse
Mesure et analyse – un domaine de processus de la catégorie Support dans la

représentation continue.
Ce domaine de processus se retrouve dans les 3 constellations (DEV, SVC et ACQ)
MA Measurement and Analysis Mesure et analyse
The purpose of Measurement and Analysis (MA) is L’intention de Mesure et analyse (MA) est de
to develop and sustain a measurement capability développer et maintenir une capacité à mesurer
used to support management information needs. utilisée pour soutenir les besoins d’information de
gestion.
On pourrait écrire plusieurs livres sur ce seul domaine de processus. Dire qu’il
n’existait même pas dans le SW-CMM, l’ancêtre du CMMI ! Les auteurs du CMMI
ont été bien avisés de l’inclure dans leur compendium de bonnes pratiques car il vient
corriger un effet pervers de ce que j’appellerais la « mesurite galopante ».
Le domaine de processus PMC – Surveillance et contrôle de projet que nous avons
couvert ci-dessus ne peut se faire sans mesures. De même GP2.8, la pratique générique
que l’on retrouve dans chaque domaine de processus, passe par la collecte et l’analyse
de mesures. Sans le domaine de processus MA, un terrible fléau guette le projet : qu’il
tombe entre les mains des ayatollahs de la mesure qui sont infectés du grave virus de la
« mesurite galopante ». Ils ne trouvent de repos qu’après avoir tout mesuré ce qui leur
tombe sous la main, Dans leur folie de mesures, ils ne savent plus pour quoi ou pour
qui ils mesurent. Obligeant hommes, femmes, enfants, vieillards, personnes saines ou
grabataires à mesurer, ils finissent par susciter la méfiance puis bientôt la révolte face à
toute mesure. Imaginons le jour de la grande capitalisation (niveau de maturité 3). On
réunira le bon peuple et on lui dira : « Vous qui avez passé des jours et des nuits à mesurer,
nous devons vous informer que dans toutes les mesures prises depuis x années, il y a 20 %
de données utiles. Par ailleurs, nous constatons maintenant que pour répondre aux attentes
de nos dirigeants, il faudrait remonter en arrière et retracer telles ou telles mesures qui nous
ont échappé à ce jour ! » N’espérez pas une salve d’applaudissements enthousiastes et
munissez-vous du parapluie spécial anti-tomates.
Sérieusement, le domaine de processus MA invite un projet et toute l’organisation
à réfléchir d’emblée à cette question existentielle : que faut-il donc mesurer pour
répondre aux vrais besoins de notre Direction, de nos actionnaires, de notre manage-
ment, ou de nous-mêmes ? Mettons en place un système qui répond bien à ces besoins
mais seulement à ces besoins justifiés. Ainsi sera-t-on vacciné contre la « mesurite
galopante ».
Le domaine de processus MA est une espèce de service d’utilité publique pour tous
les autres domaines de processus, un peu comme le service de téléphone ou d’électricité
pour nos demeures. Pris séparément, il ne sert pas à grand-chose ; il faut le coupler à
un autre domaine de processus pour lui donner une vocation, pour faire « parler » les
mesures.
Aligner les activités de mesure et analyse
SG1 Align Measurement and Analysis SG1 Aligner les activités

Activities de mesure et analyse
Measurement objectives and activities are aligned Les objectifs et activités de mesure sont alignés
with identified information needs and objectives. avec les besoins et objectifs d’information
identifiés.
Voici le point essentiel : ne mesurer que ce qui a besoin d’être mesuré ! D’abord,
avec les pratiques spécifiques sous-jacentes à ce premier objectif, déterminer les
mesures utiles puis mettre en place une infrastructure de mesure (souvent outillée par
des systèmes d’information) qui sera ensuite utilisée au fil de l’eau par le projet.
SP1.1 Establish Measurement Objectives SP1.1 Établir des objectifs de mesure
Establish and maintain measurement objectives Établir et maintenir des objectifs de mesure
derived from identified information dérivés des besoins et des objectifs d’information
needs and objectives. identifiés.
D’abord retrouver la mère de toutes les mesures : les objectifs de l’organisation.

Qu’est-ce qui importe aux yeux des dirigeants, des actionnaires ? L’augmentation du
chiffre de ventes ? La diminution des retours à cause des défauts ? La rapidité avec
laquelle on peut mettre un nouveau service sur le marché ? Quand on saura ce qui
importe, on pourra, par une approche de type « Goal-Question-Metric » par exemple,
en faire découler les mesures qui doivent être disponibles et éviter les mesures inutiles.
Pour vérifier le bon déploiement de cette pratique, un chef évaluateur demandera, par
exemple, à voir de quelle façon ont été exprimés les liens entre les mesures imposées
à tous les projets et des énoncés d’objectifs qui traduiraient des préoccupations
importantes de l’organisation ou du projet. De bonnes questions à poser : « Pourquoi
prenez-vous ces mesures ? Où ce besoin est-il expliqué ? À quelle fréquence est-il actualisé ?
La Direction est-elle impliquée ? ».
SP1.2 Specify Measures SP1.2 Spécifier des mesures
Specify measures to address measurement Spécifier des mesures qui répondent aux objectifs
objectives. de mesure.
Pour chaque mesure, il importe de fournir une définition opérationnelle c’est-à-dire

limpide aux yeux de tous et qui puisse facilement être mise en opération (utilisée,
calculée, collectée, etc.). Le défi de cette pratique est de la pousser assez loin pour
éviter la confusion ou l’ambiguïté dans les définitions d’indicateurs ou de mesures. Si
on est à l’écoute des personnes qui doivent collecter des données et les analyser, on
peut rapidement constater si les définitions établies sont claires ou pas. Dans le cadre
d’une évaluation, ceci sera révélé, le cas échéant, par des questions comme « Quelles
sont les principales difficultés que vous rencontrez pour bien interpréter les données et vous
assurer de la cohérence de leur interprétation à travers votre projet et votre organisation ?
Quelle information est disponible pour vous guider à cet égard ». Car la plupart des
organisations que j’ai vues ont rencontré ce type de difficulté : les définitions ne sont
pas suffisamment claires lorsqu’on tente de les utiliser sur le terrain.
SP1.3 Specify Data Collection and Storage SP1.3 Spécifier des procédures de collecte
Procedures et de stockage de données
Specify how measurement data are obtained and Spécifier comment les données de mesure sont
stored. obtenues et stockées.
Mesurer va impliquer de mettre en place un système de collecte et de stockage.

Cette machine doit être définie et mise en marche. En général, si on prend des mesures,
on sait comment on va s’y prendre pour la collecte, le stockage et l’analyse. Le défi de
la pratique est d’avoir documenté cette façon de faire et que cette documentation (des
procédures) soit connue et utilisée par les intervenants appropriés.
Autre composant de la « machine » à mettre en place : les techniques d’analyse et
de production d’états doivent être documentées et expliquées.
SP1.4 Specify Analysis Procedures SP1.4 Spécifier des procédures d’analyse
Specify how measurement data are analyzed and Spécifier comment les données de mesure sont
communicated. analysées et communiquées.
Fournir des résultats de mesure
SG2 Provide Measurement Results SG2 Fournir des résultats de mesure
Measurement results, which address identified Des résultats de mesures qui répondent aux
information needs and objectives, are provided. besoins et aux objectifs d’information identifiés
sont fournis.
Il ne reste qu’à faire tourner la machine à mesures dans chaque projet...
SP2.1 Obtain Measurement Data SP2.1 Obtenir les données de mesure
Obtain specified measurement data. Obtenir les données de mesure spécifiées.
Collecte (par exemple, via un système de feuilles de temps, ou par le biais de

rencontres avec l’équipe projet, ou par des extractions automatiques du journal des
défauts rapportés, etc.) puis...
SP2.2 Analyze Measurement Data SP2.2 Analyser les données de mesure
Analyze and interpret measurement data. Analyser et interpréter les données de mesure.
Analyse des données collectées. On souhaite, avec cette pratique, faire plus que de
la consolidation de données collectées en SP2.1. Des états consolidés sont faciles à
produire et on les trouve dans toutes les organisations qui ont déployé des mesures. Ce
qui manque parfois, et là repose le défi, c’est des traces de l’analyse de ces données :
tendances, explications, commentaires... Une bonne question à poser aux managers
(gestionnaires) pour détecter le déploiement de SP2.2 : « Quelles explications vos chefs
de projet vous fournissent-ils pour accompagner les états consolidés sur les indicateurs de
projet. »
SP2.3 Store Data and Results SP2.3 Stocker données et résultats
Manage and store measurement data, Gérer et stocker les données de mesure,
measurement specifications, and analysis results. les spécifications de mesure et les analyses
de résultats.
Sauvegarder les données et les résultats d’analyse, avec une bonne gestion des
versions, est essentiel dans une perspective de capitalisation et de réutilisation par les
projets futurs.
SP2.4 Communicate Results SP2.4 Communiquer les résultats
Communicate results of measurement and Communiquer les résultats des activités

analysis activities to all relevant stakeholders. de mesure et d’analyse à toutes les parties
prenantes concernées.
Transmettre l’information à qui de droit ! Simple, non ? Le seul défi avec cette
pratique est de s’assurer que toutes les parties concernées reçoivent bien l’information
qui leur est destinée avec le soutien approprié à leur interprétation.
7.2.6 Assurance qualité processus et produit
Assurance qualité processus et produit – un domaine de processus de la catégorie

Support dans la représentation continue.
Serez-vous étonnés que dans de très nombreuses organisations on désigne par

AQ (assurance qualité) le fait de tester ? Mais dans le CMMI, les tests sont couverts
dans deux domaines de processus bien précis : VER et VAL (pour Validation et
Vérification). Il faut donc que PPQA ait un sens différent de tester !
PPQA Process and Product Quality Assurance qualité processus et produit

Assurance
The purpose of Process and Product Quality L’intention d’ Assurance qualité processus et produit
Assurance (PPQA) is to provide staff and (PPQA) est de fournir au personnel et au
management with objective insight into processes management une image objective des processus
and associated work products. et des produits d’activité associés.
En fait, et en mettant l’accent sur le mot ASSURANCE, PPQA tente de répondre

aux questions suivantes : Fait-on bien ce que l’on a dit que l’on ferait ? Respecte-t-on
les règles que l’on a promis de suivre ? Qui le dira ? Qui nous donnera l’heure juste
en évitant l’auto censure ou la censure tout court ? Sans imposer le modus operandi,
le domaine de processus PPQA rappelle que la fébrilité des projets exige une vue
impartiale qui voit l’ensemble de la forêt et rappelle à l’ordre lorsqu’on viole ses
propres règles. Autant les règles sur les produits que celles sur les façons de faire
(processus) sont soumises à la sagacité de la fonction AQ. J’ai vu hélas combien les
pauvres AQ ont connu les affres d’une perception très négative de leur rôle dans de
trop nombreuses organisations. Faut-il s’étonner que les candidats aux postes AQ
vacants ne se précipitent pas au portillon quand on leur faisait porter un costume de
la Gestapo et leur faisait jouer les rouages malsains de la dénonciation ?
Jugez plutôt la fraîcheur de ce discours (certains cyniques diront la naïveté). De
préférence, tenez vos bras bien droits en angle aigu au-dessus de vos épaules, comme un
certain général dont a utilisé le nom pour en affubler un certain type de tire-bouchon.
Chefs de projet de tous les pays : nous vous avons compris ! Vous êtes esclaves de la
cadence impitoyable de vos projets ? Vous ne rentrez dans vos chaumières que lorsque
tout le monde dort depuis longtemps ? Vous ne prenez plus de vacances de peur que
le feu détruise le bâtiment ? Vous êtes sous calmants car vous ne pourriez supporter
la pression que vous pensez apaiser en buvant, oh paradoxe, des jerricans de café ?
Alors, chefs de projet, voici votre ami le plus cher, voici AQ. Il saura, de ses yeux de
lynx et du haut de son mirador, détecter la moindre mare et vous la signaler avant que
vous y mettiez les pieds. Et s’il est trop tard, il vous demandera de réparer l’erreur en
vous laissant le temps qui convient. Si dans votre frénésie vous ne savez pas trouver
le temps de le faire, il avisera vos chefs, non pas pour vous dénoncer mais pour qu’ils
réalisent que vous avez besoin d’aide et volent à votre secours.
Angélique ? Utopique ? Voyons voir ce que ces objectifs et ces pratiques PPQA
nous racontent.
Évaluer de manière objective des processus et des produits d’activités
SG1 Objectively Evaluate Processes and SG1 Évaluer de manière objective des
Work Products processus et des produits d’activités
Adherence of the performed process and Pour les processus exécutés ainsi que pour les
associated work products to applicable process produits d’activité associés, le respect des
descriptions, standards, and procedures is descriptions de processus, des normes et des
objectively evaluated. procédures qui doivent être appliquées est évalué
de manière objective.
Plusieurs modalités permettent d’assurer l’objectivité qu’il faut. Certes, on trouve

assez souvent une unité AQ qui rapporte à un grand chef, dans un parcours hiérar-
chique distinct de celui du chef de projet. C’est sans doute le moyen le plus simple,
celui auquel recourent la plupart des boîtes qui commencent à prendre au sérieux
l’AQ. Mais j’ai vu aussi des AQ dans les projets qui faisaient partie d’autres équipes
de projet et dont l’implication en mode croisé, interprojets, assurait tout autant une
bonne objectivité. Faut-il le rappeler : le CMMI s’attarde au quoi et non au comment !
SP1.1 Objectively Evaluate Processes SP1.1 Évaluer de manière objective

des processus
Objectively evaluate selected performed Évaluer objectivement les processus exécutés et

processes against applicable process descriptions, sélectionnés comme devant être examinés à des
standards, and procedures. fins d’assurance-qualité vis-à-vis les descriptions,
les normes et les procédures qui doivent
être respectées.
Regard côté cour : les façons de faire. Pas question que l’AQ jette son dévolu sur
vos pratiques sans une feuille de route qui formalise la démarche, qui en assure encore
une fois l’objectivité (par exemple, des listes de vérification). On dépasse ainsi la
vérification intuitive et tout à fait informelle. L’AQ est une chose sérieuse qui s’appuie
sur une approche rationnelle.
SP1.2 Objectively Evaluate Work Products SP1.2 Évaluer de manière objective

des produits d’activités
Objectively evaluate selected work products Évaluer de manière objective les produits
against applicable process descriptions, standards, d’activité sélectionnés comme devant être
and procedures. examinés à des fins d’assurance-qualité vis-à-vis
les descriptions, les normes et les procédures qui
doivent être respectées.
Regard côté jardin : les produits d’activité. Même démarche mais sur des objets
différents de la pratique SP1.1 qui s’attardait aux processus alors que celle-ci reluque
leurs résultats.
Fournir une image objective
SG2 Provide Objective Insight SG2 Fournir une image objective
Noncompliance issues are objectively tracked and Les non-conformités sont suivies
communicated, et communiquées de manière objective
and resolution is ensured. et leur résolution est assurée.
Dans un film de série B, on entendrait : « Taxi : suivez cette non-conformité et ne la

lâchez pas d’une semelle. » Le détective dans la voiture rend compte de la progression
de la poursuite et n’a de cesse que d’avoir enfin constaté que la non-conformité a été
réparée.
SP2.1 Communicate and Resolve SP2.1 Communiquer et résoudre les

Noncompliance Issues non-conformités
Communicate quality issues and ensure the Communiquer les problèmes relatifs à la qualité
resolution of noncompliance issues with the staff et assurer la résolution des non-conformités avec
and managers. le personnel et les managers.
Encore une fois, il ne s’agit pas de dénoncer pour dénoncer. Il faut renseigner le
management pour qu’il vole à la rescousse de ceux qui ont glissé sur une peau de
banane, qui ont commis une non-conformité et dont on attend la résolution. Il faut
aussi renseigner le bon peuple afin de contribuer à l’édification des esprits et éviter la
récurrence de mêmes erreurs.
Pratique généralement facilement déployée et constatée (en autant évidemment
que l’on prenne l’AQ au sérieux). J’ai vu par exemple des bases de données rapportant
les non-conformités et qui en rendent le suivi jusqu’à clôture assez facile ; des outils
spécialisés pour recueillir l’information sur les défauts (avec une catégorie réservée aux
non-conformités) et les suivre à la trace ; des « workflow » qui envoient des courriels
aux délinquants avec des rappels de plus en plus sévères ; ou plus simplement, des
comptes-rendus périodiquement revus pour ce qui est des non-conformités rapportées
à la fin du compte-rendu. Une question qui permet de vérifier si les personnes à
l’origine des non-conformités sont bien informées : « Si jamais, par erreur, oubli ou
volontairement, vous ne respectiez pas les règles ou normes que votre projet est censé
appliquer, comment cette non-conformité serait-elle détectée et révélée ? »
SP2.2 Establish Records SP2.2 Établir des enregistrements
Establish and maintain records of quality Établir et maintenir des enregistrements sur les
assurance activities. activités d’assurance-qualité.
Un jour ou l’autre, vous entendrez retentir le carillon de la porte d’entrée dans

votre organisation : l’auditeur (ISO ou autre) s’annonce ! Êtes-vous prêts à ouvrir vos
livres ? Mais aussi, en interne, ne faut-il pas outiller l’AQ pour qu’elle puisse elle-même
suivre ses dossiers ? Tout ceci milite pour une conservation des enregistrements de
l’AQ.
7.2.7 Gestion de configuration (un domaine de processus de la catégorie

Support dans la représentation continue)
Ce domaine de processus se retrouve dans les trois constellations (DEV, SVC et
ACQ) du CMMI ; il fait partie du tronc commun du CMMI.
J’ai toujours visualisé un numéro de trapézistes de cirque quand je pense au domaine
de processus CM. Les cirques les plus responsables n’ont-ils pas un système très complet
pour éviter les chutes tragiques des trapézistes et les pertes de contrôle ? Un chef de
projet dirige un incroyable numéro de haute voltige où une myriade d’objets sont
lancés au-dessus de sa tête. Des composants de toutes sortes sont générés, en versions
multiples, en statuts évolutifs, se mêlent les uns aux autres pour former des modules
de toutes formes. N’est-ce pas la plus élémentaire des prudences que de disposer d’un
filet de sécurité pour empêcher les chutes tragiques ? CM constitue ce filet. Il consiste
en un impressionnant arsenal de moyens plus ou moins (en général plus, compte tenu
des volumes en cause) automatisés pour garder le contrôle des versions, des retours
arrière possibles, des liens entre les objets, etc.
CM Configuration Management Gestion de configuration
The purpose of Configuration Management (CM) L’intention de Gestion de configuration (CM) est
is to establish and maintain the integrity of work d’établir et maintenir l’intégrité des produits
products using configuration identification, d’activité en utilisant une identification
configuration control, configuration status de configuration, un contrôle de configuration, un
accounting, and configuration audits. registre des statuts de configuration et des audits
de configuration.
Établir des référentiels
SG1 Establish Baselines SG1 Établir des référentiels
Baselines of identified work products Des référentiels des produits d’activité identifiés
are established. sont établis.
Le mot référentiel peut être associé à une photo que l’on prend à un moment
déterminé. On fige sur la pellicule le ballet des objets qui ont été générés par son
projet et on s’y réfère comme à la version x.
SP1.1 Identify Configuration Items SP1.1 Identifier les éléments

de configuration
Identify configuration items, components, and Identifier les éléments de configuration,

related work products to be placed under les composants et les produits d’activité associés
configuration management. à gérer en configuration.
Cette déclaration d’intention doit se matérialiser suffisamment tôt pour s’assurer

de mettre en œuvre ce qui convient aux différents types d’objets. En général, on la
trouve dans le plan de projet ou dans un plan de gestion de configuration distinct.
Elle est faite de règles de nomenclature par catégorie d’objets, de règles d’accès, de
traitements particuliers aux différents types d’objets, etc.
SP1.2 Establish a Configuration SP1.2 Établir un système de gestion

Management System de configuration
Establish and maintain a configuration Établir et maintenir un système de gestion de

management and change management system configuration et de gestion des modifications
for controlling work products. pour contrôler les produits d’activité.
Il faut mettre en place la mécanique. C’est souvent un outil informatisé qui

ressemble à une gestion d’inventaire sophistiquée. Prouver le déploiement de cette
pratique se limite souvent à assister à une présentation et démonstration de ces outils
et à en constater l’utilisation concrète dans les projets.
SP1.3 Create or Release Baselines SP1.3 Créer ou figer des référentiels
Create or release baselines for internal use and Créer ou figer des référentiels pour utilisation
for delivery to the customer. interne et pour livraison au client.
De temps en temps, il faut figer des ensembles d’objets pour que tous les gens du
projet s’y réfèrent sans risque d’erreurs qui seraient dues à la confusion. Certes, ceci
est particulièrement crucial au moment de livrer au client. On ne voudrait pas qu’il
ouvre son paquet cadeau et qu’il découvre que l’on s’est trompé de destinataire ou,
telle une boîte IKEA mal vérifiée (ceci arrive hélas), que l’on a oublié une pièce ou
que l’on a mis dans la boîte une pièce qui était destinée à un autre client !
La difficulté rencontrée sur le terrain au regard de cette pratique est d’ordre
sémantique. Parfois, le mot « référentiel » (« baseline » en anglais) est tout à fait
limpide pour toutes les personnes d’une organisation. Mais quand les gens ne savent
pas de quoi on cause, évidemment ça pose problème de comprendre pourquoi le CMMI
demande de créer ou mettre à jour des référentiels ! Qu’il suffise ici de rappeler que tout
projet qui doit livrer une solution passe par différentes phases où chaque composant de
la solution peut avoir existé en plusieurs versions suite à des modifications multiples et
connaître de nombreux stades (en développement, en essai unitaire, en essai intégré...).
Une « solution » est donc un ensemble de composants de versions et de statuts divers
que l’on a figé pour livraison. Tout au long du projet, on doit pouvoir assembler un
paquet de composants dans un état cohérent pour passer d’une étape à une autre en
cours de développement et ultimement pour envoyer chez son client. Ce résultat figé
est ce qu’on appelle « référentiel » ou « baseline ». Il devient dès lors évident que l’on
doive effectivement créer ou mettre à jour ces « portraits » au moment de faire migrer
la solution vers différents stades.
Suivre et contrôler les modifications
SG2 Track and Control Changes SG2 Suivre et contrôler les modifications
Changes to the work products under Les modifications aux produits d’activité gérés
configuration management are tracked and en configuration sont suivies et contrôlées.
controlled.
Au fil de l’eau, chaque demande de modification au contenu des référentiels doit

être traitée avec le plus grand soin. Les bons outils de CM sont alors d’un grand secours,
compte tenu des volumes en cause la plupart du temps.
SP2.1 Track Change Requests SP2.1 Suivre les demandes de modification
Track change requests for configuration items. Suivre les demandes de modification
aux éléments de configuration.
Chaque référentiel (voir commentaire sur SP1.3) subit donc des transformations
dans le temps qui sont dues soit à des corrections d’erreurs découvertes en revue de
pair ou en essai, soit à des demandes de modification aux exigences par les parties
prenantes. La plupart des organisations mettent rapidement en place un journal des
« demandes » pouvant impacter les référentiels. Dans ce journal, on retrouve la date
de la réception de la demande, l’origine, une description sommaire et ceci sert à
déclencher l’analyse de l’impact dont on documente les résultats avec les estimations et
la décision GO/NOGO. La plupart des organisations visitées soutiennent ce processus
par une base de donnée spécialisée ou un outil établi ou acheté à cette fin.
SP2.2 Control Configuration Items SP2.2 Contrôler les éléments

de configuration
Control changes to configuration items. Contrôler les modifications aux éléments

de configuration.
Ne pas transformer son projet en Club Med où toutes les chambres sont accessibles
sans clé. Ce n’est pas par malice des intervenants dans le projet mais bientôt, avec
toutes les modifications (par milliers) qui agitent la boîte des référentiels, une chatte
n’y reconnaîtra plus ses petits. Alors, il faut contrôler soigneusement toutes les
demandes de modification et en formaliser le processus d’acceptation. J’ai souvent
vu ceci pris en charge par un « bureau des modifs » qui s’ajoute à la quincaillerie
automatisée des outils CM.
Établir l’intégrité
SG3 Establish Integrity SG3 Établir l’intégrité
Integrity of baselines is established L’intégrité des référentiels est établie

and maintained. et maintenue.
Objectif noble : garder la maison nette !
SP3.1 Establish Configuration Management SP3.1 Établir des enregistrements

Records de gestion de configuration
Establish and maintain records describing Établir et maintenir les enregistrements décrivant
configuration items. les éléments de configuration.
Chaque chose à sa place, bien étiquetée avec la liste de tous les changements
apportés. C’est la meilleure façon de ne pas se tromper quand on est pressé. Ne l’est-on
pas toujours quand on développe un produit ? En général, les outils de gestion de
configuration font très bien ce travail. Sinon, il est alors nécessaire que la personne
qui en est responsable édite périodiquement, ou sur événement, un état qui serve de
référence à toutes les personnes travaillant sur le projet. Tous doivent savoir quelle est
la référence en cours, et il peut même arriver qu’une version surlignée (red-lined) soit
agréée pour le travail, en attendant un circuit de signatures, mais tout ceci doit être
bien décrit et tout le monde doit être au courant des évolutions prises en compte.
SP3.2 Perform Configuration Audits SP3.2 Mener des audits de configuration
Perform configuration audits to maintain the Mener des audits de configuration pour maintenir
integrity of configuration baselines. l’intégrité des référentiels de configuration.
Cette activité est celle qui pose le plus d’interprétation de tout le domaine de
processus CM. Plusieurs personnes se demandent d’abord en quoi elle diffère de
CM-GP2.9. Réglons ça d’abord. GP2.9 appliquée à CM demande que quelqu’un
exerçant un rôle d’assurance qualité vérifie de quelle façon se font les activités de CM
et fasse ressortir les incohérences entre ce qui est fait et ce qui devrait se faire si on
suit les règles. La pratique CM-SP3.2 porte, quant à elle, sur une activité à faire par les
gens de CM (généralement... quoique quelqu’un d’autre pourrait aussi le faire). Il s’agit
de s’assurer que le CONTENU des référentiels est bien cohérent avec ce qu’il devrait
être, compte tenu de l’état précédent et de toutes les transactions qui sont passées. Un
peu comme l’activité de conciliation que l’on fait périodiquement avec son compte
(ou relevé) de banque et que l’on s’assure que le total affiché correspond bien à ce
qu’on s’attend une fois appliquées toutes les transactions. De même, de temps en
temps, faut-il demander à son responsable CM d’ouvrir le couvercle de la machine à
CM et y faire une inspection pour s’assurer que tous les rouages fonctionnent toujours
à merveille et que le contenu des référentiels ne s’est pas dégradé depuis le dernier
audit de contenu.
Je cite ici Denise Cattan qui nous faisait judicieusement remarquer dans le forum
de discussion cmmi-en-francais : « Il est fréquent que lorsque l’on questionne sur le
sujet, on nous réponde FCA/PCA (Fonctional Configuration Audit/Physical Configuration
Audit), et ce n’est malheureusement pas la réponse qui convient, malgré que ces audits
soient importants. En effet, avec CM-SP3.2 on s’intéresse à ce qui se passe PENDANT
le développement. Sur des projets qui durent plusieurs années, attendre le FCA/PCA de
fin de développement n’apportera pas beaucoup d’information sur ce qui a pu se passer
PENDANT, et on n’a plus que les yeux pour pleurer (et le budget à consommer pendant le
temps nécessaire) pour corriger les écarts éventuels. Il s’agit bien de vérification de cohérence
des bases AU COURS du développement (on ne l’écrit jamais assez gros !). »
Avez-vous bien LU ?
a) Pourquoi le mot « discipliné » caractérise-t-il bien le niveau 2 dans le CMMI ?
b) Quelle pratique générique du niveau 2 demande, pour chaque domaine de

processus... :
1) De fournir des ressources adéquates ?
2) De s’assurer que les membres de l’équipe possèdent les connaissances requises ?
3) De promulguer les aspects incontournables exigés de tous les projets ?
4) De revoir l’avancement des activités du processus avec les managers ?
5) De gérer adéquatement les objets générés lors de l’accomplissement des activités ?
c) Quelle(s) pratique(s) spécifique(s) traitent des bonnes pratiques suivantes... :

1) Il faut pouvoir expliquer rationnellement comment on en arrive à telle charge de
travail pour telle activité.
2) Quelqu’un doit détecter les situations où les règles à suivre ne sont pas respectées.
3) Il est important de surveiller comment les risques évoluent avec le temps.
4) On ne peut pas migrer des composants vers la production sans contrôle.
5) Il faut pouvoir découvrir rapidement les liens entre les exigences et les jeux d’essais
(ou les cas d’essais).
6) Toute statistique compilée et publiée doit découler d’un besoin justifié.
7) On ne peut pas se décharger de l’obligation de surveiller ses sous-traitants.

a) Pourquoi dit-on souvent que le niveau 2 est le plus difficile à atteindre alors que les
niveaux supérieurs présentent pourtant des degrés de complexité plus élevés ?
b) Imaginez que vous êtes un chef de projet très réfractaire au CMMI. Faites un
plaidoyer (avec argumentaire) en faveur du statu quo et du non-déploiement du CMMI.
c) Pour chacun des domaines des processus du niveau 2, développez et expliquez au

moins un bénéfice très pertinent de l’institutionnalisation de ce domaine de processus
pour un développeur ; pour un chef de projet ; pour un membre de la Direction ?
d) Pour chacune des pratiques génériques du niveau 2, imaginez que la pratique

n’est vraiment pas satisfaite et expliquez ce qui arriverait dans un projet quelconque.
e) Pour chaque pratique spécifique suivante, donnez au moins un exemple de

DOCUMENT qui prouverait tangiblement que la pratique a bel et bien été déployée
dans un projet donné :
1) REQM-SP1.3 ;
2) PP-SP2.2 ;
3) PMC-SP1.6 ;
4) MA-SP2.3 ;
5) SAM-SP1.1 ;
6) PPQA-SP2.2 ;
7) CM-SP3.2.
8
Le niveau 3
D’une discipline de développement à la capitalisation

des connaissances : mettre en place une organisation apprenante
tout en évitant le piège de la bureaucratie.
L’expérience des organisations de niveau de maturité 2 montre que les projets
réussissent sensiblement mieux à respecter leurs délais et leurs budgets en ayant
institutionnalisé une bonne discipline basée sur des processus documentés et pratiqués.
Le succès appelle le succès et les projets qui réussissent captent l’attention. On
s’intéresse de plus en plus à ce qui fait leur réussite.
Les chefs de ces projets qui réussissent ont tendance, c’est normal, à réappliquer
leurs bonnes pratiques dans tous leurs projets. Pourquoi réinventer une roue qui
marche bien ? Je ne sais pas pour vous mais en ce qui me concerne, je suis un bien
piètre cuisinier mais un excellent mangeur ! Ma femme, excellente cuisinière, ne
se risque pourtant jamais à recevoir des amis ou de la famille sans d’abord tester de
nouveaux plats sur son cobaye préféré (rassurez-vous, elle passe à tout coup les essais
d’acceptation). Ayant maîtrisé le processus, elle l’applique ensuite avec des invités et,
le succès appelant le succès, le répète tant qu’elle ne se lasse pas du plat en question.
Mais revenons aux chefs de projet de développement de systèmes. En discutant
avec leurs collègues, ils constatent que d’autres ont aussi des pratiques intéressantes. Si
bien qu’un jour, inévitablement, une étincelle surgit : et si on mettait nos bonnes idées
en commun ? Voilà : le germe du niveau 3 est en marche. Il s’agit de capitaliser. De se
doter d’une fonction qui fera le point avec les projets pour en extraire la substantifique
moelle et la rendre disponible à tous sous forme de processus standard ou méthode. De
plus, on va demander aux projets de mettre à disposition leurs données statistiques en
commençant par les données d’estimation et les données réelles de fin de projet. Cette
mine de renseignements, consolidés au niveau organisationnel, devient vite une base

de données historiques précieuse pour tous les projets futurs.
Le niveau 3 sera donc fait avant tout de capitalisation et, en corollaire, d’ajus-
tement ou personnalisation. En effet, on n’imposera pas l’approche totalitaire du
processus identique pour tous. On aura la finesse de permettre, d’imposer même,
l’ajustement ou la personnalisation pour s’assurer que le processus appliqué à chaque
projet, bien qu’issu de la même base, convient bien aux caractéristiques de chaque
projet. C’est du prêt-à-porter avec un tailleur pour les retouches.
Pour monter un référentiel solide et bien renseigné de leçons apprises et de données
historiques, on devra imposer autre chose aux projets : qu’ils partagent leurs jouets
avec les amis ! Une grande collecte est organisée pour que chaque projet verse ses
dons à la grande bibliothèque.
Tableau 8.1 — Les deux pratiques génériques

(texte court et texte long) du niveau de maturité ou niveau d’aptitude 3.
GP 3.1 Establish a Defined Process GP3.1 – Établir un processus ajusté

Establish and maintain the description Établir et maintenir la description d’un processus
of a defined process. ajusté.
GP 3.2 Collect Process Related Experiences GP3.2 – Recueillir des retours

Collect process related expriences derived from d’expériences relatifs aux processus
planning and performing the process to support Recueillir les retours d’expériences provenant de
the future use and improvement of the la planification et de la mise en œuvre du
organization’s processes and process assets. processus en vue de soutenir l’utilisation future
et l’amélioration des processus organisationnels et
des actifs associés.
Rappelons qu’en représentation étagée ou continue, la signification du niveau 3

est essentiellement la même. Cependant, ce concept de niveau s’applique à un seul
domaine de processus, en fait à son APTITUDE, dans la représentation continue alors
qu’il s’applique à une grappe de domaines de processus pour toute une organisation, en
fait pour sa MATURITÉ, dans la représentation étagée. Ce chapitre porte donc tout
autant sur l’atteinte du niveau d’aptitude 3 que du niveau de maturité 3. Toutefois,
la liste des domaines de processus que l’on décrit dans ce chapitre regroupe ceux du
niveau de MATURITÉ 3 et ne s’applique que dans la représentation étagée. Pour
appliquer, en représentation continue, le concept de niveau d’APTITUDE 3 aux
autres domaines de processus, il suffit de regarder leur contenu dans les chapitres
appropriés de ce livre (les tables de référence au tout début du livre aideront à les
localiser facilement) pour trouver leurs objectifs et pratiques spécifiques et d’ajouter
l’objectif générique GG2 et les pratiques génériques GP2.1 à GP2.10 qui se trouvent
dans le chapitre précédent ainsi que l’objectif GG3 et les pratiques génériques GP3.1
et GP3.2 qui se trouvent dans le présent chapitre. Dit d’une autre façon, l’ordre de
présentation que nous suivons dans ce livre est celui de la représentation étagée ; mais
si on utilise la représentation continue, il suffit de trouver le domaine de processus dans
le chapitre approprié de ce livre et de lui appliquer toutes les pratiques des niveaux
d’aptitude que l’on vise.
8.1 Interprétation de l’objectif générique GG3 et des pratiques génériques GP3 113
En représentation étagée, le niveau de maturité 3 est aussi fait d’une poussée de

maturité du côté des pratiques d’ingénierie. Un total de 11 domaines de processus
compose le bouquet étagé du niveau de maturité 3. C’est beaucoup. Êtes-vous prêt à
faire le parcours avec nous ?
8.1 INTERPRÉTATION DE L’OBJECTIF GÉNÉRIQUE GG3

ET DES PRATIQUES GÉNÉRIQUES GP3
Avant de décrire les onze domaines de processus qu’on retrouve dans la représentation
étagée au niveau de maturité 3, parlons de l’objectif générique qui se trouve dans
tous les domaines qu’on souhaite « monter » au niveau 3 et plus ; l’objectif GG3
et les pratiques GP3.1 et GP3.2, les deux pratiques génériques qui y sont associées.
Décrivons d’abord l’objectif.
GG3 Institutionalize a Defined Process GG3 Institutionnaliser le processus

en tant que processus ajusté
The process is institutionalized as a managed Le processus est institutionnalisé en tant que

process. processus ajusté.
Quand on vise le niveau 3, les projets ont la responsabilité de s’assurer que, pour
chacun des domaines de processus, sera mise en œuvre une version ajustée du processus
organisationnel standard. L’ajustement (ou la personnalisation) vise à s’assurer que
le processus colle vraiment à la « personnalité » du projet, qu’il tienne compte de
ses caractéristiques propres. Le processus organisationnel peut par exemple établir
que l’activité de design se traduira par des diagrammes de flux de données entre les
fonctions d’un système. Si un projet utilise une technique de design particulière, le
projet doit alors exprimer que pour le design il utilisera cette technique au lieu de
diagrammes de flux de données. La liste de dérogations au processus organisationnel
standard doit être clairement exprimée et entérinée afin d’éviter une multitude
incontrôlée de versions de processus utilisées dans les projets qui rendrait toute
capitalisation du savoir impossible.
En anglais, les auteurs utilisent le mot « defined » que j’ai traduit à ma façon
par « Ajusté », pour les raisons évidentes que je décris ci-dessus. Mais dans tous les
cas, ils auraient pu dire que le processus, au lieu d’être ajusté, doit respecter les 10
critères contenus dans les pratiques génériques GP2.1 à GP2.10 du CMMI, donc être
discipliné mais en plus, il doit respecter les deux critères contenus dans les pratiques
génériques GP3.1 et GP3.2 ce qui fait un total de douze pratiques génériques ou
critères d’institutionnalisation. Comme on a déjà expliqué au chapitre précédent
les dix critères qui se cachent dans les dix pratiques génériques associées à l’objectif
générique GG2, il nous reste à expliquer les exigences additionnelles inscrites dans
les pratiques GP3.1 et GP3.2.
Figure 8.1 — Les deux pratiques génériques de l’objectif générique GG3,

qui englobe, de plus, les dix pratiques génériques de GG2.
8.1.1 GP3.1 – Établir un processus ajusté

Établir et maintenir la description d’un processus ajusté.
La première pratique qui contribue à l’atteinte de l’objectif GG3 demande
simplement que le processus ajusté qui sera établi par le chef de projet soit documenté
et justifié par un argumentaire expliquant pourquoi il faut déroger à tel ou tel aspect
du processus organisationnel standard. Elle oblige aussi à utiliser le capital processus
(entre autres, justement, le processus organisationnel standard).
Lors d’une évaluation de processus, on peut demander au chef de projet à quel
moment et de quelle façon il a clairement formulé ses demandes de dérogation au
processus organisationnel en vigueur et que, par défaut, il doit respecter. Dans une
organisation de niveau de maturité 3 (ou pour un domaine de processus d’aptitude 3),
les chefs de projet le font généralement dans une section particulière du document
décrivant le mandat du projet. On retrouvera les outils particuliers qu’ils demandent
d’utiliser, les produits d’activité qu’ils demandent à faire différemment (par exemple,
regrouper certains produits d’activité), les activités du cycle de vie standard qu’ils
veulent éliminer ou ajouter, etc. Je dis souvent que les chefs de projet doivent faire leur
« déclaration solennelle à la nation » en jurant fidélité au processus organisationnel
standard tout en réclamant parfois des ajustements qu’ils doivent justifier et faire
entériner.
8.1.2 GP3.2 – Recueillir des retours d’expériences relatifs au processus

Recueillir les retours d’expérience provenant de la planification et de la mise en œuvre
du processus en vue de soutenir l’utilisation future et l’amélioration des processus de
l’organisation et des actifs associés.
Interprétation des pratiques spécifiques dans les domaines de processus... 115
Pour paraphraser le célèbre « Trop de notes, mon cher Mozart » de l’empereur Joseph
II, je dirais « Trop de mots, mon cher CMMI ». Le texte de cette pratique est si long
que je m’amuse souvent à en exprimer plutôt l’idée par cette boutade : « Partage
tes jouets avec tes copains ». Il est en effet ici question de capitalisation. Au niveau
3, le CMMI exige que les projets contribuent à la bonification du savoir collectif.
Ainsi en cours de projet ou lors d’un bilan de projet, le projet fera en sorte que les
produits d’activité réutilisables par d’autres projets et les connaissances enfouies dans
ses mesures soient conservés. En général, la fonction de conservateur (comme dans un
musée) est exercée par une fonction de soutien au processus. L’unité ou la personne
responsable de cette fonction s’assurera que l’information à conserver est valide et
utile pour les projets à venir. Elle la mettra à disposition de tous les intéressés grâce
à un environnement approprié à l’organisation. Dans les sociétés où nous sommes
intervenus, nous constatons que celles-ci utilisent de plus en plus Intranet comme un
pilier d’un tel environnement. En consultant Intranet, les chefs de projet accèdent
à cette espèce de bibliothèque d’Alexandrie, au savoir collectif. Ils ont l’impression
de recevoir les conseils de tous leurs prédécesseurs, d’accéder au savoir de tous leurs
collègues.
Lors d’une évaluation de processus, nous demandons souvent aux personnes qui
travaillent dans les projets si leurs façons de faire sont uniques ou communes à tous les
projets. Tout en encourageant l’ajustement (pratique GP3.1), le CMMI exige tout de
même que celui-ci soit fait à partir d’un processus standard au niveau de l’organisation.
Sans capitalisation, une organisation ne peut prétendre fonctionner au niveau 3.

Tout comme je le faisais pour les pratiques de niveau de maturité 2, je rappelle que je
n’ai pas la prétention de proposer une traduction officielle de tout le modèle CMMI.
Je répète que je propose plutôt une traduction ciblée des pratiques et des objectifs de
tous les domaines de processus, fidèle à ma propre compréhension des pratiques du
CMMI, le tout validé par des experts indépendants. De plus, je donne sous chaque
pratique quelques explications additionnelles pour mettre en lumière les aspects
qui me semblent, lors d’une première lecture, moins évidents. Ceci sera, je l’espère,
particulièrement utile puisque ces commentaires ont été écrits suite aux expériences
que j’ai vécues sur le terrain. Dans la colonne de gauche, j’ai repris textuellement le
contenu du CMMI avec l’autorisation du SEI. Le lecteur pourra ainsi comparer les
textes anglais et français et se faire sa propre opinion sur l’interprétation à donner au
texte de la pratique en anglais. Enfin, en consultant les suppléments en ligne sur le
site web de Dunod, le lecteur trouvera une représentation schématique de chacun des
domaines de processus.
Quand on compare les constellations DEV, ACQ et SVC, on constate que c’est au
niveau de maturité 3 que se retrouvent la majorité des domaines de processus uniques
à chacune de ces constellations.
8.2.1 Développement des exigences
Développement des exigences – un domaine de processus de la catégorie

Ingénierie dans la représentation continue.
Ce domaine de processus ne se retrouve que dans la constellation DEV du CMMI ; il
ne fait pas partie du tronc commun du CMMI et est donc absent des constellations
ACQ et SVC.
RD Requirements Development Développement des exigences
The purpose of Requirements Development L’intention de Développement des exigences (RD)

(RD) is to elicit, analyze, and establish customer, est d’obtenir et expliciter, d’analyser et d’établir les
product, exigences client, produit et composants de produits.
and product component requirements.
J’ai déjà fait remarquer au chapitre précédent que si le domaine de processus

Gestion des exigences focalisait essentiellement sur les modifications aux exigences déjà
établies, le domaine RD porte quant à lui sur l’activité de collecte des besoins, de leur
transformation en exigences et de l’explicitation de ces exigences.
Développer les exigences client
SG1 Develop Customer Requirements SG1 Développer les exigences client
Stakeholder needs, expectations, constraints, Les besoins, attentes, contraintes et interfaces

and interfaces are collected and translated into des parties prenantes sont recueillis et traduits
customer requirements. en exigences client.
Première étape décrite par cet objectif : capter ce que nous dit notre client, à sa
façon plus ou moins formelle, et le documenter pour en faire un cahier d’exigences
client.
Un point qui est très souvent soulevé lors des formations CMMI : qu’est-ce qui
arrive lorsqu’on reçoit un cahier des charges déjà bien ficelé par le client lui-même ?
A-t-on encore besoin d’appliquer RD, et en particulier l’objectif SG1, puisque les exi-
gences sont déjà documentées ? Et la réponse est, à moins d’exception exceptionnelle
(Oh le beau pléonasme !), oui RD reste requis. Pour deux raisons : primo, il y aura
des modifications aux exigences en cours de projet et il faudra revenir en RD pour les
expliciter ; secundo, il faut ajouter aux exigences du client (externe) celles du ou des
clients internes, y compris de sa propre organisation (celle qui développe) ! Voir la
pratique SP1.1 qui parle bien de TOUTES les parties prenantes.
Mais il est vrai que la formulation de cet objectif qui commence par « Développer »
est trompeuse. Ici, l’équipe projet doit non pas formuler ou développer par elle les
exigences, mais s’assurer du développement des exigences et y contribuer. Je compare
ceci au rôle de sage-femme dans un accouchement. Le client accouche de ses exigences
et le projet l’assiste dans cette entreprise.
SP1.1 Elicit Needs SP1.1 Expliciter les besoins
Elicit stakeholder needs, expectations, constraints, Obtenir et expliciter les besoins, attentes,
and interfaces for all phases of the product contraintes et interfaces des parties prenantes
lifecycle. pour toutes les phases du cycle de vie du produit.
Comme « bonne pratique », le CMMI nous enseigne qu’on ne peut plus se

contenter de recueillir passivement les attentes du client. Le verbe expliciter implique
une certaine recherche active de la part du responsable du cahier d’exigences pour
clarifier celles-ci et éliminer les ambiguïtés. Ça nous ramène au rôle de sage-femme
évoqué ci-dessus.
Attention aussi de ne pas oublier ce qu’on désigne généralement par l’expression
« exigences non techniques » (cadre légal à respecter, délais bloqués, normes, etc.) !
Ceci fait aussi partie du travail d’explicitation.
SP1.2 Transform Stakeholder Needs into SP1.2 Transformer les besoins des parties
Customer Requirements prenantes en exigences client
Transform stakeholder needs, expectations, Transformer les besoins, attentes, contraintes

constraints, and interfaces into prioritized et interfaces des parties prenantes en exigences
customer requirements. client priorisées.
Ce qui a été entendu et élicité doit être noté dans un document (papier ou
électronique) de référence. RD-SP1.2 branche logiquement sur la REQM-SP1.4 pour
établir la base de la traçabilité, par exemple en découpant clairement les exigences,
en les identifiant de façon unique et en les enregistrant dans l’outil qui nous servira à
la traçabilité.
Je rappelle la remarque faite ci-dessus sur le mot « Développer » utilisé ici dans le
libellé court de la pratique : on accompagne plus qu’on développe comme tel.
Développer les exigences produit
SG2 Develop Product Requirements SG2 Développer les exigences produit
Customer requirements are refined Les exigences client sont clarifiées et détaillées
and elaborated to develop product and product pour développer les exigences produit
component requirements. et composants de produit.
Deuxième étape exprimée par cet objectif : faire subir au cahier des exigences
client une réécriture en ajoutant les aspects système aux aspects clients. Il en résulte
un document (papier ou électronique) plus technique et plus détaillé qui traduit les
exigences système ou produit.
SP2.1 Establish Product and Product SP2.1 Établir les exigences produit
component Requirements et composants de produit
Establish and maintain product and product Établir et maintenir les exigences produits
component requirements, which are based on et composants de produit, qui sont basées
the customer requirements. sur les exigences clients.
Évidemment, on n’inventera pas les exigences produit à partir de rien. Le point de

départ et la traçabilité doivent être clairs : on doit partir des exigences client !
SP2.2 Allocate Product component SP2.2 Allouer les exigences composants

Requirements de produit
Allocate the requirements for each product Allouer les exigences pour chaque composant
component. de produit.
Puisque l’on décompose la solution recherchée en composant de solution (le tout

en parties), il faut bien que l’on distribue vers les différentes parties les exigences que
l’on destine à chacune. Par exemple, un système de contrôle peut faire intervenir des
pièces mécaniques et des modules électroniques. Une exigence client qui dirait de
fermer l’écoutille lorsque se produit une certaine situation peut se répercuter sur le
mécanisme (la mécanique) de fermeture et aussi sur le module électronique qui traitent
les signaux d’alerte et envoient un signal de fermeture. À la même exigence client
initiale correspondrait alors une exigence système qui serait mécanique (allouée au
composant mécanique) et une autre exigence système qui serait électronique (allouée
au composant électronique).
J’utilise parfois une autre analogie pour expliquer la pratique d’allocation des
exigences. Un centre d’appel d’une compagnie de taxis doit assigner tel appel à tel
taxi ; de même le projet (le chef de projet ou l’architecte) doit décider que telle
exigence sera assignée à tel composant qui sera développé par telle sous-équipe. On
commence en quelque sorte une architecture de haut niveau qui va entraîner une
première décomposition de la solution envisagée en grands blocs de composants : des
composants logiciels, des composants mécaniques, des composants électroniques, etc.
derrière lesquels s’affaireront ensuite des équipes logicielles, mécaniques, électroniques,
etc. pour la phase de développement (qui sera couverte en TS – Solution technique).
SP2.3 Identify Interface Requirements SP2.3 Identifier les exigences d’interface
Identify interface requirements. Identifier les exigences d’interface.
Puisqu’on divise son cahier d’exigences système en parties plus petites liées les unes
aux autres, il faut établir justement la nature de ces liens : les exigences d’interface.
Analyser et valider les exigences
SG3 Analyze and Validate Requirements SG3 Analyser et valider les exigences
The requirements are analyzed and validated. Les exigences sont analysées et validées.
Troisième et dernière étape couverte par cet objectif spécifique : s’assurer que
l’on débute le projet du bon pied en ayant résolu le maximum de problèmes à la
source c’est-à-dire dès que le cahier des exigences est disponible. Ceux qui ont travaillé
au développement de système savent combien des pertes énormes de temps et d’argent
sont souvent liées à des exigences floues que l’on n’a pas détectées et réglées au bon
moment.
SP3.1 Establish Operational Concepts SP3.1 Établir des concepts d’emploi

and Scenarios et des scénarios
Establish and maintain operational concepts and Établir et maintenir des concepts d’emploi et des
associated scenarios. scénarios associés.
Il faut faire « vivre » les exigences, raconter des histoires, comme aux enfants, pour
s’assurer qu’on a tout bien compris et qu’on arrive à imaginer le produit tel qu’il sera
un jour ! Plusieurs modes d’expression sont possibles. La plupart des personnes (en
logiciel au moins) connaissent maintenant le vocable « use cases » et dès qu’on leur
dit qu’une des façons de déployer SP3.1 est de faire, par exemple, des « use cases », tout
est compris rapidement ! Mais on peut aussi décrire les concepts d’emploi avec des
illustrations, des prototypes, des enchaînements d’écrans, des histoires avec maquettes
pour s’assurer que l’on a bien compris.
SP3.2 Establish a Definition of Required SP3.2 Établir une définition

Functionality and Quality Attributes des fonctionnalités requises
et des attributs de qualité
Establish and maintain a definition of required Établir et maintenir une définition

functionality and quality attributes. des fonctionnalités requises et des attributs
de qualité.
Ce que l’on donnera aux développeurs doit être suffisamment précis et complet
pour qu’ils puissent établir une conception et amorcer la construction. Notons que
cette pratique peut souvent se faire en simultané ou en parallèle avec la pratique
précédente.
SP3.3 Analyze Requirements SP3.3 Analyser les exigences
Analyze requirements to ensure that they are Analyser les exigences pour s’assurer qu’elles
necessary and sufficient. sont nécessaires et suffisantes.
Un aspect crucial de la validation des exigences consiste à s’assurer que tout

ce que le client a demandé est couvert par le cahier des exigences système, sinon
on ne développera pas et on ne livrera pas tout ce qui a été demandé. Ça semble
évident mais dans un système complexe, aux enchevêtrements quasi inextricables, on
peut facilement s’y perdre. D’où l’importance d’une bonne approche de traçabilité
(voir REQM-SP1.4). À l’inverse, si on trouve dans le cahier d’exigences système des
exigences orphelines, qu’on ne peut tracer jusqu’à leur mère (une exigence client),
on est train de se faire plaisir en prévoyant un truc non demandé par le client. Cela
peut être acceptable si c’est la règle de la maison d’ainsi profiter de développements
particuliers pour bonifier à mesure le produit global. Ainsi, si on vise le développement
d’une ligne de produit paramétrable, il est fort possible que l’on profite de chaque
« customisation » client pour peaufiner le produit générique, si telle est la politique de
l’organisation.
SP3.4 Analyze Requirements SP3.4 Analyser les exigences

to Achieve Balance pour assurer l’équilibre
Analyze requirements to balance stakeholder Analyser les exigences pour équilibrer les besoins
needs and constraints. et contraintes des parties prenantes.
Le projet fait intervenir différents acteurs qui peuvent exprimer des besoins
contradictoires qu’il faut savoir arbitrer. De plus, un projet ne se développe pas sur
sa petite planète à lui. Il coexiste souvent avec d’autres projets qui peuvent aussi
influencer son déroulement. On ne peut tirer toutes les ressources de l’organisation à
soi sans créer des problèmes ailleurs. Encore une fois, il faut savoir arbitrer.
Les deux pratiques RD-SP3.3 et SP3.4 incitent à examiner plusieurs aspects
importants des exigences : la nécessité, la suffisance et l’équilibre entre contraintes et
besoins. Ce faisant, on aura certainement besoin, comme conséquence des analyses
faites, de modifier des exigences déjà exprimées. La plupart des organisations n’exigent
pas alors le formalisme des demandes de modifications (tel que discuté en REQM –
Gestion des exigences) puisque l’on considère qu’on est toujours en mode d’explicitation
et qu’on n’a pas encore formalisé le contrat ou le référentiel d’exigences contractuelles.
Autrement dit, on ne déclenchera REQM qu’après qu’un référentiel validé aura été
approuvé et que le développement (TS – Solution technique) sera amorcé !
Avant même de passer à l’étape de construction, on doit chercher par tous les
moyens possibles et raisonnables à clarifier si ce que l’on est en train d’imaginer va
vraiment tenir la route dans le véritable environnement de l’utilisateur. On doit
chercher à valider cet aspect le plus tôt possible en tenant des « focus groups » par
exemple, des sondages, en présentant des prototypes à l’œil critique de son client, etc.
SP3.5 Validate Requirements SP3.5 Valider les exigences
Validate requirements to ensure the resulting Valider les exigences pour s’assurer que le
product will perform as intended in the end produit résultant aura le comportement prévu
user’s environment. dans l’environnement de l’utilisateur final.
8.2.2 Solution technique
Solution technique – un domaine de processus de la catégorie Ingénierie dans la

ACQ et SVC.
C’est ici que l’on sent l’effort « manuel » en quelque sorte, que l’on verra le produit
se matérialiser sous nos yeux ébahis. Le domaine de processus TS couvre en effet
toutes les activités de conception et de construction qui contribuent directement à la
gestation du produit ; il reléguera à des domaines de processus spécialisés les activités
périphériques comme les revues par les pairs (VER), les essais (VER et VAL) ou
l’intégration du produit (PI).
TS Technical Solution Solution technique
The purpose of Technical Solution (TS) is to select, L’intention de Solution technique (TS) est de
design, and implement solutions to requirements. sélectionner, faire la conception
Solutions, designs, and implementations et l’implémentation des solutions aux exigences.
encompass products, product components, and Les solutions, conceptions et implémentations
product related life-cycle processes either singly or recouvrent les produits, composants de produits
in combinations as appropriate. ainsi que les processus du cycle de vie reliés aux
produits en question, en tout ou en partie, selon ce
qui convient.
Sélectionner les solutions de composants de produit
SG1 Sélectionner les solutions

SG1 Select Product component Solutions
de composants de produit
Les solutions de produit ou de composants de

Product or product component solutions are
produit sont sélectionnées à partir d’un éventail
selected from alternative solutions.
de solutions possibles.
Pas de précipitation ! Cet objectif nous prévient : avant de nous lancer, assurons-
nous de bien choisir la meilleure approche en comparant divers chemins possibles.
SP1.1 Develop Alternative Solutions and SP1.1 Développer un éventail de solutions

Selection Criteria possibles ainsi que des critères de sélection
Develop alternative solutions and selection Développer un éventail de solutions possibles et

criteria. des critères de sélection.
Pour comparer, il faut d’abord nous assurer de disposer de suffisamment d’infor-

mation sur différents chemins possibles et aussi préciser sur quels critères reposera
son choix. Quand je fais des évaluations d’organisation, on me dit parfois que dans
certains projets la situation imposait une seule possibilité, qu’aucune alternative n’était
possible lors du design. Je m’étonne alors car la pratique ne précise pas à quel niveau
de décomposition du design elle s’applique. Il me semble qu’il arrive toujours au moins
une situation où on doive choisir entre au moins deux voies possibles. J’explique
alors que je cherche à vérifier s’il existe un réflexe de ne pas immédiatement choisir
la première solution possible car elle n’est pas nécessairement la meilleure ; on en
convient alors assez facilement. Alors je demande : « Comment faites-vous, au moment
du design, pour éviter de sauter sur la première idée venue ? ». Mais dans un nombre
assez limité de situations (par exemple lors d’évolutions mineures à des applications
existantes), il pourrait arriver que l’on demande une dérogation à cette pratique tant
le chemin à suivre pour le design est tout tracé d’avance.
SP1.2 Select Product component Solutions SP1.2 Sélectionner les solutions

pour les composants de produit
Select the product component solutions based on Sélectionner les solutions pour les composants de
selection criteria. produit sur la base des critères de sélection.
À mesure que se présentent des points de décision sur la construction d’un

composant, il faut pouvoir démontrer que nos choix reposent sur un argumentaire
rationnel.
Faire la conception
SG2 Develop the Design SG2 Faire la conception
Product or product component designs Le produit ou les composants de produit sont

are developed. conçus.
Cet objectif spécifique parle de l’étape de conception, essentielle à tout projet

de construction qui se veut mature et qui évite la précipitation et l’improvisation,
facteurs qui affectent grandement la pérennité du produit en bout de ligne.
SP2.1 Design the Product SP2.1 Concevoir le produit

or Product Component ou le composant de produit
Develop a design for the product or product Concevoir le produit ou le composant de produit.
component.
Il s’agit de l’étape classique de la conception dans un projet de développement.

Cette pratique pose le principe fondamental qu’on ne construit pas un produit avant
de le concevoir, d’en faire le design. Mais rares sont ceux qui en doutent encore !
Une fois cette question réglée, qu’est-ce que, diable, cette pratique nous dit-elle de si
important pour qu’on la qualifie de « bonne pratique » ? Dans sa formulation même :
très peu d’indices ! C’est un cas classique de pratique qui formulée très simplement
repose néanmoins sur un savoir-faire immense qui est du domaine du « comment »
et non du « quoi ». Or le CMMI ne s’attarde qu’au « quoi » et laisse champ libre
au « comment ». J’ai l’habitude de dire que certains passent toute une vie sur cette
seule pratique tellement elle est complexe à décortiquer, à en saisir le fonctionnement
interne.
Cette pratique spécifique demande que l’on rassemble les éléments d’information
que l’on transmettra ultérieurement aux développeurs. Il peut s’agir de dessins
techniques, de documents de spécification, ou tous les autres types d’éléments utiles à
la construction du produit.
SP2.2 Establish a Technical Data Package SP2.2 Établir un ensemble de données

techniques
Establish and maintain a technical data package. Établir et maintenir un ensemble de données
techniques.
Le problème que je rencontre le plus souvent avec cette pratique surgit dans les
environnements d’informatique de gestion. En ingénierie système, on est plus familier
avec ce concept. On a différents niveaux de plans (au sens « blue prints » : détails
plomberie, détails électricité, détails charpente... par exemple) et il faut bien les
rassembler pour les passer à ceux qui vont construire concrètement. J’ai aussi vu des
situations où une masse importante d’information technique devait être transmise aux
constructeurs (par exemple : ceux qui construisent des simulateurs d’avion reçoivent
un impressionnant volume de données techniques sur les appareils à simuler). Alors,
ma façon de retraduire cette pratique pour la rendre plus facilement compréhensible
dans tous les milieux est de demander « Dites-moi de quelle façon ceux qui vont construire
les composants et le produit reçoivent-ils tout ce qui leur sera nécessaire pour faire le travail ?
Et que contient la « trousse » qu’on leur remet ? »
SP2.3 Design Interfaces Using Criteria SP2.3 Concevoir les interfaces

en s’appuyant sur des critères
Design product component interfaces using Concevoir les interfaces des composants de
established criteria. produit en s’appuyant sur des critères établis.
On peut considérer que cette pratique est une variante de la pratique SP2.1 qu’on
applique aux modules d’interface. On reverra en PI ou Intégration de produit qu’il
n’est pas superflu d’accorder une attention toute spéciale aux interfaces puisqu’ils sont
souvent à la source de problèmes nombreux.
SP2.4 Réaliser les analyses permettant

SP2.4 Perform Make, Buy, or Reuse
de déterminer si on va faire, acheter
Analyses
ou réutiliser
Evaluate whether the product components Évaluer si les composants de produit doivent être
should be developed, purchased, or reused développés, achetés ou réutilisés en s’appuyant
based on established criteria. sur des critères établis.
Quand j’interroge des équipes de projets sur cette pratique, on me dit parfois qu’on
n’avait pas le choix, qu’on ne pouvait tout simplement pas faire d’évaluation du type
décrit dans la pratique : il fallait acheter d’un fournisseur donné. Bien ! Mais alors je
demande de me montrer, ailleurs, dans un autre composant traité par le projet, que
l’équipe a exploré différentes voies possibles : réutiliser, construire à neuf, acheter...
Il est rarissime que dans la totalité d’un projet on ne puisse démontrer un seul de
ces cas sur l’un ou l’autre des composants. Autre remarque souvent entendue : mais
on a déjà pris cette décision (par exemple : acheter) « avant » ! Alors je demande
« avant quoi ? ». On me répond « Mais avant ! Au moment de l’étude de faisabilité par
exemple. Or, on est ici à l’étape de conception avec cette pratique ! ». Alors je dois faire
remarquer : « Rappelez-vous que même si elles sont forcément présentées dans un ordre
linéaire puisqu’il s’agit d’un livre, les pratiques (et les domaines de processus) ne se déroulent
pas nécessairement dans cet ordre linéaire précis ». Les pratiques constituent plutôt une
sorte de « check-list » qui permet de vérifier qu’on les déploie à un moment donné,
sans ordre de préséance suggéré ou imposé par le CMMI.
Mettre en œuvre la conception du produit
SG3 Implement the Product Design SG3 Mettre en œuvre la conception

du produit
Product components, and associated support Les composants de produit et la documentation

documentation, are implemented from their de soutien associée sont mis en œuvre à partir de
designs. leurs conceptions.
Cet objectif spécifique couvre l’étape classique de codage dans un projet de déve-
loppement informatique par exemple ou de construction des composants électroniques
ou mécaniques dans des projets d’ingénierie. On traite dans cet objectif autant les
composants eux-mêmes que la documentation connexe.
SP3.1 Implement the Design SP3.1 Mettre en œuvre

à partir de la conception
Implement the designs of the product Mettre en œuvre les conceptions des composants
components. de produit.
Tout comme sa voisine SP2.1, voilà une pratique très lourde de sens par le savoir-
savoir qu’elle implique. Si simple à formuler mais si complexe à faire ! Ici, j’avoue
que la formulation de la pratique est simplement factuelle et il est peu aisé d’y voir
un aspect de « bonne pratique ». Il y a bien cette référence à la conception comme
point d’appui pour la réalisation. Mais en fait, les aspects de « bonnes pratiques »
se trouvent plutôt expliqués dans les sous-pratiques (par exemple, faire des essais de
chaque composant, demander à faire des revues par les pairs, etc.).
SP3.2 Develop Product SP3.2 Développer la documentation

Support Documentation de soutien au produit
Develop and maintain the end-use Développer et maintenir la documentation pour

documentation. l’utilisation finale.
En plus des guides destinés à l’utilisateur final, qui peuvent être fournis sous forme
d’aide en ligne, cette pratique couvre aussi les manuels d’opération, de maintenance,
de formation, etc.
8.2.3 Intégration de produit
Intégration de produit – un domaine de processus de la catégorie Ingénierie dans

la représentation continue.
ACQ et SVC.
PI Product Integration Intégration de produit
The purpose of Product Integration (PI)is to

L’intention d’ Intégration de produit (PI) est d’assembler
assemble the product from the product
le produit à partir des composants de produit, de
components, ensure that the product, as
s’assurer que le produit assemblé se comporte
integrated, behaves properly (i.e., possesses
correctement (i.e., possède les fonctionnalités et les
the required functionality and quality
attributs de qualité requis) et de le livrer.
attributes, and deliver the product.
Tout comme au retour du magasin où on aurait acheté un meuble en kit et qu’il

faudrait assembler avant de le disposer dans sa chaumière, le domaine de processus
PI décrit les activités d’assemblage et de vérification de bon fonctionnement avant
livraison. Notons ici que le SW-CMM négligeait ces activités ou ne les abordait que
de façon très sommaire. Il faut dire que la portée du SW-CMM se limitait à l’aspect
logiciel. Le lecteur aura certes compris que le CMMI couvre un ensemble plus vaste
intégrant les disciplines d’ingénierie système et d’ingénierie logicielle. Ce domaine de
processus PI constitue donc un apport significatif propre au modèle CMMI.
Se préparer à l’intégration de produit
SG1 Prepare for Product Integration SG1 Se préparer à l’intégration de produit
Preparation for product integration is conducted. La préparation en vue de l’intégration de produit

est réalisée.
L’enchaînement des objectifs spécifiques dans ce domaine de processus se retrouve

dans plusieurs autres domaines de processus du CMMI. Un premier objectif SG1
couvre la préparation de l’activité principale (ici l’intégration) puis un second objectif
SG2 couvrira la réalisation de l’activité elle-même.
SP1.1 Establish an Integration Strategy SP1.1 Établir une stratégie d’intégration
Establish and maintain a product component Établir et maintenir une stratégie d’intégration
integration strategy. des composants de produit.
Il existe plusieurs stratégies d’intégration et, bien sûr, le CMMI n’en impose aucune
en particulier. Un chef de projet pourra choisir une approche « big bang » alors qu’un
autre chef de projet préférera une approche étapiste. On comprend généralement
qu’il vaut mieux traiter de la stratégie d’intégration tôt dans le projet ; ceci signifie
d’impliquer les intervenants de l’intégration dès le démarrage pour bien planifier les
aspects de l’intégration. Cette pratique, qui arrive donc généralement tôt dans le
déroulement d’un projet, constitue une autre illustration que le CMMI énumère un
ensemble de bonnes pratiques logiquement regroupées en domaine de processus mais
que ce regroupement, par exemple ici PI, ne signifie aucunement qu’il faut réaliser ces
activités en bloc, après les domaines présentés ailleurs dans le livre (par exemple, le
domaine de processus TS – Solution technique).
SP1.2 Establish the Product Integration SP1.2 Établir l’environnement d’intégration

Environment de produit
Establish and maintain the environment needed

Établir et maintenir l’environnement nécessaire
to support the integration of the product
à l’intégration des composants de produit.
components.
S’il s’agit d’assembler un avion, on peut imaginer que cette pratique aille jusqu’à
la construction d’un hangar pour l’assemblage. Dans un projet plus modeste, elle
pourrait se traduire par la nécessité de doter un laboratoire des équipements requis à
l’intégration. S’il s’agit d’un projet purement logiciel, on peut devoir mettre en place
un ensemble de librairies particulières aux activités d’intégration.
Il arrive assez souvent que l’environnement qui servira à phase d’intégration de
plusieurs projets, soit mis à disposition par une entité externe au projet. La pratique est
alors appliquée de facto avant même que le projet démarre mais le chef de projet doit
néanmoins s’assurer avec soin que ses besoins spécifiques pour l’intégration s’insèrent
bien dans l’environnement préétabli.
SP1.3 Establish Product Integration SP1.3 Établir les procédures et critères

Procedures and Criteria d’intégration de produit
Establish and maintain procedures and criteria for Établir et maintenir les procédures et critères
integration of the product components. pour l’intégration des composants de produit.
Cette pratique demande tout simplement de préparer le protocole de l’intégration

et les critères de déclenchement de chacune des étapes. Tout comme SP1.1, cette
pratique peut également démarrer très tôt dans le projet et elle doit faire intervenir
toutes les parties prenantes au moment de la planification.
Assurer la compatibilité des interfaces
SG2 Ensure Interface Compatibility SG2 Assurer la compatibilité des interfaces
The product component interfaces, both internal Les interfaces des composants de produit, tant
and external, are compatible. internes qu’externes, sont compatibles.
Cet objectif spécifique porte sur un sous-ensemble précis des composants, celui
des interfaces. La compatibilité de ceux-ci est critique comme le savent très bien les
développeurs qui ont l’expérience des projets impliquant plusieurs composants.
Je traduis souvent cette pratique par cette interrogation toute simple et concrète
(bien que dans plusieurs cas, les interfaces ne soient pas aussi matérielles) : « Avant
de fermer la boîte, vous êtes-vous assurés qu’il ne manque aucun câble ? ». Toutes les
parties prenantes doivent passer en revue les descriptions des interfaces pour éviter les
interprétations erronées, diminuer les délais et prévenir le développement d’interfaces
qui fonctionnent mal.
La réalisation de la pratique SP2.1 a pu nous faire réaliser que les interfaces doivent
encore être modifiées. De plus, des modifications à des composants ont souvent des
répercussions sur les interfaces qui les lient à d’autres composants.
SP2.1 Review Interface Descriptions SP2.1 Passer en revue les descriptions

for Completeness d’interfaces pour s’assurer
de leur exhaustivité
Review interface descriptions for coverage and Passer en revue les descriptions d’interfaces pour
completeness. s’assurer de leur couverture et de leur
exhaustivité.
SP2.2 Manage Interfaces SP2.2 Gérer les interfaces
Manage internal and external interface Gérer les définitions des interfaces internes et
definitions, designs, and changes for products externes entre les produits et les composants de
and product components. produit, leurs conceptions et leurs modifications.
Assembler les composants de produit et livrer le produit
SG3 Assemble Product Components SG3 Assembler les composants de produit

and Deliver the Product et livrer le produit
Verified product components are assembled and

Les composants de produit vérifiés sont assemblés
the integrated, verified, and validated product is
et le produit intégré, vérifié et validé est livré.
delivered.
Cet objectif spécifique constitue finalement l’aboutissement de tout le projet de

développement : livrer au client.
SP3.1 Confirm Readiness of Product SP3.1 Confirmer que les composants

Components for Integration de produit sont prêts à être intégrés
Confirmer avant l’assemblage que chaque

Confirm, prior to assembly, that each product
composant de produit requis pour assembler le
component required to assemble the product has
produit a été correctement identifié, se comporte
been properly identified, behaves according to its
conformément à sa description, et que les
description, and that the product component
interfaces des composants de produit sont
interfaces comply with the interface descriptions.
conformes à leurs descriptions.
Cette pratique vise à s’assurer une dernière fois que toutes les pièces, les bonnes
pièces, et seulement les bonnes pièces sont installées sur la table de travail, prêtes pour
l’assemblage.
SP3.2 Assemble Product Components SP3.2 Assembler les composants de produit
Assemble product components according to the Assembler les composants de produit en accord
product integration strategy and procedures. avec la stratégie d’intégration et les procédures.
Que dire de plus, sinon qu’on assemble le puzzle ? Comme on est rarement seul
pour intégrer un produit dans un vrai projet (contrairement au puzzle), il faut suivre
la stratégie mise au point pour que toute l’opération se déroule de concert avec toutes
les parties prenantes. Sinon, ce sera la cacophonie... et l’échec, alors qu’on est si près
du but, de la livraison !
SP3.3 Evaluate Assembled Product SP3.3 Évaluer les composants de produit

Components assemblés
Evaluate assembled product components for Évaluer les composants de produit assemblés
interface compatibility. pour s’assurer de la compatibilité des interfaces.
Une fois le montage terminé, les liens entre composants fonctionnent-ils toujours ?
Encore une autre vérification ; on n’est jamais trop prudent car c’est le dernier droit
avant la livraison au client.
SP3.4 Package and Deliver the Product SP3.4 Conditionner et livrer le produit
or Product Component ou le composant de produit
Package the assembled product or product Conditionner le produit ou le composant de

component and deliver it to the customer. produit assemblé et le livrer au client.
J’ai appris de mes cousins français que l’on dit « conditionner » pour « packager ».
Cette pratique couvre la préparation du paquet cadeau, de l’emballage, de l’étiquette
et de la livraison au bon client. Le « paquet » doit inclure tout ce qui est nécessaire
au bon fonctionnement du produit livré : documentation d’installation, d’utilisation,
etc. Dans certains cas, la livraison peut impliquer tout un projet de transfert de
technologie vers le client. La pratique nous rappelle enfin qu’il ne faut pas se tromper
de destinataire.
8.2.4 Vérification
Vérification – un domaine de processus de la catégorie Ingénierie dans la

ne fait pas partie du tronc commun du CMMI et est docn absent des constellations
ACQ et SVC.
À chaque fois que je donne un cours sur le CMMI, je demande aux étudiants
de m’expliquer la différence entre vérification et validation. J’obtiens toujours des
réponses divergentes. Pourtant, des normes internationales s’efforcent de bien définir
l’une et l’autre. Mais, je ne sais pour quelle raison mystérieuse, la confusion perdure.
Je parie même que tous les lecteurs ne s’accorderont pas avec les définitions que je
vous propose ici et qui, évidemment, seront celles du CMMI.
VER Verification Vérification
The purpose of Verification (VER) is to ensure L’intention de Vérification (VER) est de s’assurer
that selected work products meet their specified que les produits d’activité sélectionnés respectent
requirements. les exigences spécifiées qui les concernent.
Le domaine de processus VER couvre les activités qui permettent de s’assurer

que le produit développé est conforme aux exigences. Ceci inclut différents modes de
vérification : des essais unitaires, des revues par les pairs, etc. Par ailleurs, le domaine de
processus VAL s’attardera, quant à lui, à s’assurer que le produit développé fonctionne
correctement dans l’environnement du client cible ou dans un environnement
similaire.
Pour expliquer ce que les auteurs du CMMI entendent par VER et VAL, je prends
souvent l’exemple d’une voiture que l’on achète. Quand on consulte les spécifications
et qu’on compare la voiture convoitée avec celles-ci, on fait de la VER. Par exemple,
je peux m’assurer que l’accélération annoncée (0-100 km par exemple) se fait bien
dans les délais annoncés (5 secondes par exemple : quelle puissance quand même que
ce bolide !). Par contre, quand avant de l’acheter, je prends la route avec la voiture
convoitée et que je m’assure que j’aime la conduite, alors je suis en train de faire
de la VAL. Le siège est-il confortable ? La visibilité des lunettes avant et arrière me
plaît-elle ? Le coffre, bien que dimensionné selon les spécifications, est-il configuré
pour me permettre de loger ce que je veux transporter dans cette voiture ? Le tableau
de bord me donne-t-il un accès facile aux commandes importantes ? Les amortisseurs
me donnent-ils la sensation que je recherche ?
Ce qui complique les choses, c’est que le même essai routier me permet souvent de
faire de la VAL et de la VER en même temps. On désigne parfois la combinaison de
VER et VAR par le sigle V & V ! Ainsi, je peux programmer un essai avec un copilote.
Je me dirige sur une piste d’accélération, je m’immobilise, et avertis le copilote de
partir son chronomètre quand je lance la voiture à fond ; le copilote surveille le cadran
de l’accélérateur et arrête le chronomètre quand l’aiguille touche le 100 km. Il fait
de la VER. Pendant ce temps, lui et moi avons écouté le bruit que faisait le bolide et
avons aimé : on fait de la VAL ! Et si on avait eu un mesureur de décibels, on aurait
pu faire une autre VER...
Mais, est-ce si important de distinguer VER et VAL en autant qu’on couvre bien
les deux buts visés ? Je ne sais pas vraiment. Une fois que j’ai expliqué aux sociétés
que je visite que les deux sont effectivement nécessaires pour satisfaire le client, il me
semble bien secondaire de savoir au moment où je fais un essai si je fais de la VER ou
de la VAL à ce moment précis... Vous noterez d’ailleurs que les pratiques (exception
des pratiques de revues de pairs sous l’objectif SG2 de VER) de VAL et de VER sont
formulées de façon quasi identique !
Ce n’est que dans leur intention que les deux domaines se distinguent.
Se préparer à la vérification
SG1 Prepare for Verification SG1 Se préparer à la vérification
Preparation for verification is conducted. La préparation en vue de la vérification est

réalisée.
Je vous avais dit que l’on retrouverait ce schéma de formulation avec un premier
objectif visant la préparation (SG1) et un autre (ici ce sera SG3) pour la conduite
des activités. Entre les deux, on trouvera inséré dans le domaine de processus VER un
objectif associé aux revues par les pairs.
SP1.1 Select Work Products for Verification SP1.1 Sélectionner les produits d’activité
à vérifier
Select work products to be verified and Sélectionner les produits d’activité à vérifier et les
verification methods to be used. méthodes de vérification
à utiliser.
Dépendant de la criticité du produit, la stratégie de vérification pourra varier d’un

échantillonnage léger à une vérification complète de tous les modules, d’où le mot
« sélectionner » en début de pratique. Certes, on comprendra qu’un jeu vidéo n’a
pas besoin du même niveau de vérification qu’un système de contrôle de centrales
nucléaires.
Quand les gens réalisent que le CMMI ne les force pas à TOUT tester, ils
demandent, « Comment vous faites en évaluation pour nous dire si on satisfait ou pas
cette pratique ? Combien de tests sont suffisants ? ». Ma réponse ne vous étonnera pas :
« Autant que nécessaire ! ». Et ils poursuivent : « Mais qui va vous en convaincre ? Quelles
preuves recherchez-vous ? ». Alors je dis que les chefs de projets et leurs collègues
doivent pouvoir me montrer dans un document (généralement le plan des essais)
un argumentaire qui justifie le nombre plus ou moins élevé, la couverture plus ou
moins exhaustive que devra avoir l’ensemble des tests prévus. Et je demande aussi aux
gens dans les projets : « Avez-vous faits autant de tests que vous le jugiez nécessaire ? »
ou « Vous êtes-vous restreints, faute de temps, pour découvrir plus tard que certains tests
avaient été oubliés ce qui a entraîné ultérieurement des corrections ou reprises (« rework »)
importantes » ?
Le chef de projet pourrait devoir acquérir des équipements particuliers, réserver
des locaux spéciaux, monopoliser des ressources spécialisées. Tout ceci est relié à la
préparation de la vérification.
SP1.2 Établir l’environnement

SP1.2 Establish the Verification Environment
de vérification
Establish and maintain the environment needed Établir et maintenir l’environnement nécessaire à
to support verification. la vérification.
On avait vu une pratique similaire en PI – Intégration de produit, plus précisément

en PI-SP1.2. Je précisais alors, et ça reste vrai en VER, que souvent un groupe externe
au projet a déjà mis en place l’environnement ou l’infrastructure qu’il faut. Mais même
dans ces cas, il faut au moins que le projet s’assure de la disponibilité de l’ensemble
des objets, outils, espaces, référentiels, etc. requis pour faire les tests. Et parfois, il faut
tout bâtir de zéro et ceci devient un projet dans un projet !
SP1.3 Establish Verification Procedures SP1.3 Établir les procédures et les critères
and Criteria de vérification
Establish and maintain verification procedures Établir et maintenir les procédures et les critères
and criteria for the selected work products. de vérification pour les produits d’activité
sélectionnés.
Sans minimiser l’importance de cette activité, il n’en demeure pas moins qu’elle
est assez triviale pour quiconque a travaillé le moindrement dans un projet de
développement de produit (logiciel ou autre). On ne teste pas sans feuille de route,
sans plan de tests ; sans annoncer ce qu’on va tester et sans décrire à l’avance les
résultats attendus pour y comparer ceux obtenus ; sans s’assurer que sa feuille de route
contient suffisamment de tests pour couvrir tous les cas à tester (voir la SP1.1). Dit
plus simplement, il s’agit de préparer les cahiers d’essais.
Réaliser les revues par les pairs
SG2 Perform Peer Reviews SG2 Réaliser des revues par les pairs
Peer reviews are performed on selected work Des revues par les pairs sont réalisées pour les
products. produits d’activité sélectionnés.
Les auteurs du CMMI ont longuement hésité avant d’intégrer les revues par les pairs
dans le domaine de processus VER. Quand on y réfléchit bien, on pourrait considérer
facilement que celles-ci sont une instanciation d’un mode de vérification qui s’appuie
sur l’intervention de collègues pour dépister des problèmes le plus tôt possible. En ce
sens, les auteurs auraient pu simplement citer l’approche de revues par les pairs comme
une des techniques de vérification possible. Mais pour bien insister sur l’obligation
(comme bonne pratique) de prévoir des revues par les pairs, ils ont prévu un objectif
spécifique traitant de revues par les pairs qui constitue alors un critère fondamental
pour considérer que le domaine de processus Vérification est satisfait. Ainsi, sans revues
par les pairs institutionnalisés dans les projets, on ne peut considérer le domaine VER
comme satisfait d’un point de vue CMMI.
SP2.1 Prepare for Peer Reviews SP2.1 Se préparer pour les revues
par les pairs
Prepare for peer reviews of selected work Se préparer pour les revues par les pairs des
products. produits d’activité sélectionnés.
Ceux qui ont participé à des revues par les pairs savent l’importance de recevoir
les composants à revoir suffisamment à l’avance pour les commenter. De plus, le choix
des réviseurs et de l’animateur demande une bonne connaissance des intervenants
possibles. Enfin, la mise à disposition d’une liste de vérification appropriée à l’objet
vérifié demeure un aspect important de la préparation.
Le problème d’interprétation que je rencontre le plus souvent porte sur la couver-
ture et le nombre. Peut-on ne faire des revues par les pairs que sur les spécifications ?
Que sur le code ? Et combien de revues sont nécessaires ? Évidemment, n’attendez
pas du CMMI qu’il vous donne le chiffre précis de revues de pairs acceptable ! Quant
à la couverture, la réponse est souvent : le plus possible, autant que nécessaire, sans
sombrer dans la bureaucratie absurde. On n’élimine pas le besoin du bon jugement en
appliquant le CMMI... heureusement !
SP2.2 Conduct Peer Reviews SP2.2 Mener des revues par les pairs
Conduct peer reviews of selected work products Mener des revues par les pairs des produits
and identify issues resulting from these reviews. d’activité sélectionnés et identifier les problèmes
détectés lors de ces revues.
Ici encore, le CMMI n’impose pas de techniques précises. Ceux qui ont fait des
inspections de codes connaissent sans doute la technique préconisée par Fagan. Les
spécialistes du métier sauront sans doute trouver la technique de revue par les pairs
qui soit la mieux adaptée aux différents objets à vérifier. Dans tous les cas, il importe
de tenir un journal de bord afin de ne perdre aucune des remarques signalées par les
réviseurs.
SP2.3 Analyze Peer Review Data SP2.3 Analyser les données des revues
par les pairs
Analyze data about the preparation, conduct, and Analyser les données portant sur la préparation,
results of the peer reviews. la conduite et les résultats des revues par les pairs.
Le chef de projet, la plupart du temps, ou un délégué, devra se pencher de temps

en temps sur les informations recueillies lors des revues par les pairs. On y puise une
masse considérable de savoir dont on peut faire profiter l’ensemble des intervenants
du projet.
Vérifier les produits d’activité sélectionnés
SG3 Verify Selected Work Products SG3 Vérifier les produits d’activité
sélectionnés
Selected work products are verified against their Les produits d’activité sélectionnés sont vérifiés
specified requirements. au regard des exigences spécifiées.
Cet objectif nous dit tout simplement de faire fonctionner la moulinette de

vérification.
SP3.1 Perform Verification SP3.1 Réaliser la vérification
Perform verification on selected work products. Réaliser la vérification des produits d’activité
sélectionnés.
Les protocoles établis sous les pratiques de l’objectif SG1 doivent maintenant être
exécutés pour le sous-ensemble des produits d’activité que l’on a choisi. Le vin étant
tiré, il faut le boire n’est-ce pas ? On n’aura pas préparé tous ces cas de test pour les
laisser sur étagère ! Il faut que l’on puisse démontrer en évaluation que chaque cas
à tester l’a bien été et qu’on conserve la trace des résultats et de la décision prise
(poursuivre ou corriger).
SP3.2 Analyze Verification Results SP3.2 Analyser les résultats de vérification
Analyze results of all verification activities. Analyser les résultats de toutes les activités
de vérification.
Tout comme on l’a fait pour les données de revues par les pairs, on analysera
également les données de vérification. Certes, toutes les erreurs détectées devront
faire l’objet d’une décision quant à leur correction ou au report de leur correction dans
une étape ultérieure. Les données en elles-mêmes peuvent aussi renseigner le chef de
projet sur les zones de faiblesse de son équipe.
8.2.5 Validation
Validation – un domaine de processus de la catégorie Ingénierie dans la représenta-

tion continue.
ACQ et SVC.
Je ne répéterai pas ici la distinction entre VER et VAL que je donnais au début
du domaine de processus VER. Rappelons simplement que les essais réalisés dans le
domaine de processus VAL serviront à démontrer que le produit développé devrait
bien fonctionner dans l’environnement du client. Prenons l’exemple d’une voiture. Les
essais de vérification nous auront permis de nous assurer que toutes les spécifications
techniques de la voiture ont été respectées. Toutefois, seuls des essais bien différents
dans leur nature permettraient de valider si la voiture rencontrera un franc succès
avec tel ou tel groupe de consommateurs cibles.
VAL Validation Validation
The purpose of Validation (VAL) is to demonstrate L’intention de Validation (VAL) est de démontrer
that a product or product component fulfills its qu’un produit ou un composant de produit satisfait
intended use when placed in its intended à l’utilisation prévue lorsqu’il est placé dans
environment. l’environnement cible.
Se préparer pour la validation
SG1 Prepare for Validation SG1 Se préparer pour la validation
Preparation for validation is conducted. La préparation en vue de la validation est réalisée.
Cet objectif spécifique couvre une activité similaire à celle que l’on a déjà décrite
dans les domaines de processus PI et VER. Dans le domaine de processus VAL, on
pourrait devoir construire un environnement calqué sur celui de l’utilisateur final et
qui permet de simuler le fonctionnement du produit avant sa livraison.
SP1.1 Select Products for Validation SP1.1 Sélectionner les produits à valider
Select products and product components to be Sélectionner les produits et les composants de
validated and the validation methods to be used. produit à valider ainsi que les méthodes de
validation à utiliser.
Voir à ce sujet l’explication que je donnais dans le domaine de processus VER. La

même explication s’applique à VAL.
SP1.2 Establish the Validation Environment SP1.2 Établir l’environnement de validation
Establish and maintain the environment needed Établir et maintenir l’environnement nécessaire à
to support validation. la validation.

SP1.3 Establish Validation Procedures SP1.3 Établir les procédures et les critères
and Criteria de validation
Establish and maintain procedures and criteria for Établir et maintenir les procédures et les critères
validation. de validation.

Valider le produit ou les composants de produit
SG2 Validate Product or Product SG2 Valider le produit ou les composants

Components de produit
The product or product components are Le produit ou les composants de produit sont
validated to ensure they are suitable for use in validés pour s’assurer qu’ils conviennent à
their intended operating environment. l’utilisation prévue dans l’environnement
opérationnel cible.
Maintenant il s’agit d’appliquer les techniques de validation prévues aux cas d’essais
qui ont été préparés dans l’environnement qui ressemble le mieux à l’environnement
cible.
SP2.1 Perform Validation SP2.1 Réaliser la validation
Perform validation on selected products and Valider les produits et composants de produit
product components. sélectionnés.

SP2.2 Analyze Validation Results SP2.2 Analyser les résultats de validation
Analyze results of validation activities. Analyser les résultats des activités de validation.

8.2.6 Focalisation sur le processus organisationnel
Focalisation sur le processus organisationnel – un domaine de processus de la

catégorie Gestion de processus dans la représentation continue.
OPF Organizational Process Focus Focalisation sur le processus organisationnel
The purpose of Organizational Process Focus (OPF) L’intention de Focalisation sur le processus
is to plan, implement, and deploy organizational organisationnel (OPF) est de planifier, mettre en
process improvements based on a thorough œuvre et déployer des améliorations aux
understanding of current strengths and weaknesses processus organisationnels en s’appuyant sur une
of the organization’s processes and process assets. compréhension approfondie des forces et faiblesses
actuelles des processus et des actifs de processus
organisationnels.
Ce domaine de processus constitue la pierre d’assise du niveau de maturité ou

d’aptitude 3 qui se traduit essentiellement par le concept de capitalisation. Dans
la représentation continue, il faudra au moins appliquer l’équivalent des pratiques
décrites en OPF (et aussi OPD) pour les domaines de processus que l’on vise. Dans la
représentation étagée, le bloc de pratiques OPF (et OPD) est intimement rattaché au
niveau de maturité 3 par le fait que ce domaine de processus est situé précisément au
niveau 3.
Quand on évoque la capitalisation, on veut dire que les retours des projets passés
doivent être collectés, filtrés au besoin, et mis à disposition, dans un environnement
aisément accessible à l’ensemble des projets à venir ; ainsi chaque projet accédera au
savoir collectif qui s’accumule avec le temps. Dans les organisations que j’ai visitées,
un groupe spécialisé (nommé typiquement « groupe de soutien aux processus » –
Engineering Process Group ou EPG) est le plus souvent affecté à la coordination de ces
activités essentiellement organisationnelles.
Le prochain domaine de processus OPD sera étroitement relié au présent domaine
OPF. Celui-ci porte sur la mise en place de l’infrastructure de soutien de base alors
qu’OPD portera sur le déploiement de chacun des actifs de processus au niveau
organisationnel. Rappelons que ces actifs organisationnels constitueront le point
d’appui (la partie « prêt-à-porter » avant les retouches) primordial pour l’établissement
d’un processus ajusté, propre à chaque projet.
Déterminer les occasions d’amélioration de processus
SG1 Determine Process-Improvement SG1 Déterminer les occasions

Opportunities d’amélioration de processus
Strengths, weaknesses, and improvement Les forces, les faiblesses et les occasions
opportunities for the organization’s processes are d’amélioration des processus de l’organisation
identified periodically and as needed. sont identifiées périodiquement et au besoin.
Ce premier objectif spécifique couvre ce qui constitue une grande partie de mon
activité professionnelle, à savoir la réalisation d’évaluations de processus. Certes, le
CMMI suggère de mener non seulement des évaluations officielles, mais aussi des
évaluations plus pointues présentant un caractère officieux. Dans tous les cas, les
résultats de ces évaluations permettront au groupe de processus de déterminer les
priorités d’actions d’amélioration.
SP1.1 Establish Organizational Process SP1.1 Établir les besoins des processus
Needs organisationnels
Establish and maintain the description of process Établir et maintenir la description des besoins et
needs and objectives for the organization. des objectifs des processus pour l’organisation.
Trop souvent, j’ai malheureusement rencontré des dirigeants qui se contentaient

d’exprimer un objectif du type : « Soyons au niveau X avant la fin de l’année ! ».
Bien que l’on puisse s’en contenter tactiquement, ce n’est pas à proprement parler
un objectif de nature organisationnelle. Je recommande fortement à mes clients de
décliner leur objectif processus à partir des objectifs d’entreprise. Ainsi on assure la
pérennité de l’activité d’amélioration de processus en l’exprimant dans un langage qui
parle à la Direction (avec un très grand « D »).
SP1.2 Appraise the Organization’s Processes SP1.2 Évaluer les processus de l’organisation
Appraise the organization’s processes periodically Évaluer les processus de l’organisation

and as needed to maintain an understanding of périodiquement et au besoin en vue de maintenir
their strengths and weaknesses. une compréhension de leurs forces et faiblesses.
Une évaluation de processus bien faite se termine par une liste précise de points
forts et de points faibles. Dans une stratégie d’amélioration continue de ses processus,
il faut prévoir des états des lieux exhaustifs et officiels (des SCAMPI de classe A) –
par exemple aux deux ans – mais il est bon également de planifier des examens plus
limités, plus légers, plus focalisés et plus fréquents (des SCAMPI de classe B ou C ou
des analyses d’écart officieuses).
SP1.3 Identify the Organization’s Process SP1.3 Identifier les améliorations

Improvements au processus de l’organisation
Identify improvements to the organization’s Identifier les améliorations aux processus et aux
processes and process assets. actifs de processus de l’organisation.
À partir des résultats de l’évaluation, il est facile généralement de dresser une liste
des points à améliorer qui sont tout naturellement associés aux faiblesses identifiées.
On ne pourra pas avaler cet éléphant d’une seule bouchée. Donc il faut prioriser afin
de faire un plan de projet réaliste. Ceci commence par une sélection judicieuse des
prochaines réalisations à mettre en chantier en priorité. Le fait d’avoir précisé (en
SP1.1) des objectifs reliés aux objectifs d’entreprise aidera à fixer les priorités.
Planifier et mettre en œuvre les activités d’amélioration de processus
SG2 Plan and Implement Process Actions SG2 Planifier et mettre en œuvre
les actions relatives aux processus
Process actions that address improvements to the Les actions relatives aux processus et traitant les
organization’s processes and process assets are améliorations aux processus et aux actifs de
planned and implemented. processus de l’organisation sont planifiées et
mises en œuvre.
L’organisation doit constamment planifier, mener et surveiller un projet de mise à

niveau de ses actifs processus organisationnels.
Tout cycle d’amélioration au capital processus devient pour ainsi dire un projet en
soi renouvelé, espérons-le, d’année en année. On peut dire que le cahier des charges
de ce projet découle de la dernière évaluation menée. Il faut assigner un chef à ce
projet et ce chef, probablement issu du groupe de soutien aux processus, devra bien
sûr établir le plan de projet. Bref, cela revient à appliquer PP – Planification de projet à
ce projet spécial d’amélioration de processus.
SP2.1 Establish Process Action Plans SP2.1 Établir des plans d’action processus
Establish and maintain process action plans to Établir et maintenir des plans d’action processus
address improvements to the organization’s pour traiter les améliorations aux processus et
processes and process assets. aux actifs de processus de l’organisation.
SP2.2 Implement Process Action Plans SP2.2 Mettre en œuvre

les plans d’action processus
Implement process action plans. Mettre en œuvre les plans d’action processus.
Cette pratique au texte succinct contient pourtant tant d’énergie et de travail !

C’est le branle-bas de combat pour mettre à niveau et bonifier ce que l’on veut garder
mais améliorer, mettre au rancart ce qui n’est plus utile ou ajouter de nouveaux actifs
à notre capital processus. On peut devoir écrire de nouveaux processus, réécrire des
processus existants, choisir de nouveaux outils, etc. Ceci correspond à l’activité de
construction dans un projet de développement. Ça me fait étrangement penser aux
domaines de processus TS, PI, VAL et VER appliqués aux processus eux-mêmes.
En évaluation, qu’on me montre des versions de processus, des comptes rendus de
rencontres où on aurait validé des processus modifiés, qu’on me montre des comptes
rendus d’avancement du projet d’amélioration de processus, etc. et je serai content !
Déployer les actifs de processus organisationnels et incorporer les retours d’expérience
SG3 Deploy Organizational Process Assets SG3 Déployer les actifs de processus
and Incorporate Experiences organisationnels et incorporer les retours
d’expérience
Organizational process assets are deployed Les actifs de processus organisationnels sont
across the organization and process-related déployés à travers l’organisation et les retours
experiences are incorporated into organizational d’expérience relatifs aux processus sont
process assets. incorporés dans les actifs de processus
organisationnels.
Voilà décrite dans cet objectif spécifique l’essence même de la capitalisation.

L’organisation met à disposition le savoir collectif et ne perd aucune occasion
d’apprendre par les retours d’expériences.
SP3.1 Deploy Organizational Process Assets SP3.1 Déployer les actifs de processus
organisationnels
Deploy organizational process assets across the Déployer les actifs de processus organisationnels
organization. à travers l’organisation.
Une fois une mise à niveau complétée, il importe de communiquer à l’ensemble

des parties prenantes les informations utiles pour en tirer profit. Je trouve de plus en
plus d’organisations qui s’appuient sur Intranet pour s’acquitter de cette importante
activité de communication.
SP3.2 Deploy Standard Processes SP3.2 Déployer les processus standards
Deploy the organization’s set of standard Déployer dans les projets, dès leur début,
processes to projects at their startup and deploy l’ensemble des processus organisationnels
changes to them as appropriate throughout the standards et déployer les modifications à ceux-ci
life of each project. selon les besoins tout au long de la vie des projets.
Attention ici : le mot « ensemble » est la traduction du mot anglais « set » et n’est
pas utilisé, comme on le fait parfois en français, comme synonyme de « tous les ».
Dès qu’un actif processus organisationnel a été mis à jour, il faut s’assurer que les
projets qui démarrent utilisent bien la nouvelle version de l’actif en question. De
même, pour les projets déjà en cours, il faut voir s’il est souhaitable de substituer à
l’actif déjà utilisé à date, la nouvelle version de l’actif.
Il faut veiller à ce que toute l’organisation et par conséquent tous les projets suivent
le rythme des mises à niveau et utilisent effectivement les nouveaux actifs. Pour ce
faire, une surveillance doit s’exercer de la part du groupe responsable de l’amélioration
du processus.
SP3.3 Monitor the Implementation SP3.3 Surveiller la mise en œuvre
Monitor the implementation of the organization’s Surveiller la mise en œuvre de l’ensemble des
set of standard processes and use of process processus organisationnels standards et
assets on all projects. l’utilisation des actifs de processus dans tous les
projets.
SP3.4 Incorporate Experiences into SP3.4 Incorporer les retours d’expériences

Organizational Process Assets dans les actifs de processus organisationnels
Incorporate process related experiences derived Incorporer dans les actifs de processus
from planning and performing the process into organisationnels les retours d’expériences dérivés
organizational process assets. de la planification et de l’exécution du processus.
En beaucoup de mots, il s’agit simplement de maintenir à niveau le capital

processus en utilisant la boucle de rétroaction activée par chacun des projets, soit
à des jalons importants ou, à tout le moins, à la fin du projet, lors d’un bilan ou
« post-mortem ». Cette pratique ferme donc la boucle de la capitalisation. Le capital
ne s’enrichit que par les apports des projets (et des personnes qui y travaillent). On
bonifie le savoir collectif, qui devient comme une bibliothèque d’Alexandrie.
8.2.7 Définition du processus organisationnel
Définition du processus organisationnel – un domaine de processus de la catégorie

Gestion de processus dans la représentation continue.
OPD Organizational Process Definition Définition du processus organisationnel
The purpose of Organizational Process Definition L’intention de Définition du processus

(OPD) is to establish and maintain a usable set of organisationnel (OPD) est d’établir et maintenir un
organizational process assets, work environment ensemble utilisable d’actifs de processus au niveau
standards, and rules and guidelines for teams. organisationnel, des normes d’environnement
de travail ainsi que des règles et lignes directrices
pour les équipes.
Comme je le disais au début du domaine de processus OPF, le domaine OPD y est

intimement lié. Rappelons simplement qu’OPD va couvrir avec son unique objectif
spécifique (SG1), à raison d’une pratique par type d’actifs processus, les différents
composants du capital processus.
Établir les actifs du processus organisationnel
SG1 Establish Organizational Process Assets SG1 Établir les actifs du processus
organisationnel
A set of organizational process assets Un ensemble d’actifs de processus

is established and maintained. organisationnels est établi et maintenu.
Dans cet objectif spécifique, on retrouve la totalité des actifs de processus qui
doivent être mis en place. Chaque pratique réfère à l’un d’eux.
La plupart des organisations ayant un vécu de projets de développement mettent
peu de temps à se doter d’une méthode standard pour les projets en question. Ceci
constitue concrètement ce que l’on désigne dans la pratique SP1.1 par l’ensemble de
processus standards de l’organisation. Tous les projets devront s’y conformer sans pour
autant interdire les variations telles qu’on le verra dans le domaine de processus IPM –
Gestion de projet intégrée et qu’on a déjà vu dans la pratique générique GP3.1.
SP1.1 Establish Standard Processes SP1.1 Établir les processus standards
Establish and maintain the organization’s set of Établir et maintenir l’ensemble de processus
standard processes. standards de l’organisation.
SP1.2 Establish Lifecycle Model Descriptions SP1.2 Établir les descriptions des modèles
de cycles de vie
Establish and maintain descriptions of lifecycle Établir et maintenir les descriptions des modèles
models approved for use in the organization. de cycle de vie dont l’utilisation est approuvée
dans l’organisation.
Il arrive très souvent, lorsqu’une organisation dispose d’une méthode standard, que
les cycles de vie sont enchâssés dans la méthode elle-même. Si ce n’est pas le cas, la
pratique demande que les cycles de vie autorisés soient publiés de façon distincte. Les
projets, par la suite, référeront à ces descriptions de cycles de vie plutôt que de les
redéfinir à l’intérieur de leurs plans de projet. La notion de « cycle de vie » correspond
à la liste des étapes et l’agencement de celles-ci qu’un projet doit respecter depuis le
début jusqu’à la fin.
SP1.3 Establish Tailoring Criteria and SP1.3 Établir les critères et les lignes
Guidelines directrices d’ajustement
Establish and maintain tailoring criteria and Établir et maintenir les critères et les lignes
guidelines for the organization’s set of standard directrices d’ajustement pour l’ensemble des
processes. processus standards de l’organisation.
J’ai bien rappelé que les projets doivent utiliser les processus standards. Cependant,
j’ai aussi précisé qu’ils peuvent appliquer un certain nombre de variantes. La pratique
SP1.3 demande que des adaptations typiques soient proposées aux projets qui satisfont
un certain nombre de caractéristiques communes. Au côté de la méthode standard,
les chefs de projet trouveront, par exemple, un guide d’adaptation pour petits projets,
un autre pour très grands projets, etc. Cette possibilité d’ajustement est à ce point
importante qu’une organisation qui ne la prévoirait pas ne pourrait être déclarée de
niveau de maturité 3.
Les données historiques de tous les projets sont collectées, filtrées et stockées dans
un répertoire centralisé aisément accessible à l’ensemble des projets. Ces données
portent non seulement sur les facteurs d’estimation, les données actuelles en fin de
projet, mais aussi sur les activités d’essais, de revues par les pairs, etc. Ainsi, tout projet
qui démarre aura à sa disposition une masse d’informations très utiles pour préparer
des estimations plus réalistes et des plans plus appropriés.
SP1.4 Establish the Organization’s SP1.4 Établir la base de mesures

Measurement Repository de l’organisation
Establish and maintain the organization’s Établir et maintenir la base de mesures de

measurement repository. l’organisation.
Je conseille la patience aux organisations sur cette pratique. Plus elles sont grosses,
éclatées, dispersées, et plus ce sera difficile de trouver les dénominateurs communs qui
seront utiles à tous ! Le concept est simple mais sa réalisation est parfois fort longue !
Quels paramètres peuvent vraiment aider les futurs projets à faire de meilleures
estimations ? Comment un projet pourra-t-il retrouver les projets similaires dans une
base historique ? Le temps ne joue-t-il pas aussi un rôle majeur ? Les données d’il y a
10 ans sont-elles toujours pertinentes ? Ne faut-il pas épurer ?
SP1.5 Establish the Organization’s Process SP1.5 Établir une bibliothèque des actifs
Asset Library processus de l’organisation
Establish and maintain the organization’s process Établir et maintenir une bibliothèque des actifs
asset library. processus de l’organisation.
Si l’information quantitative est stockée dans le répertoire décrit dans la pratique

SP1.4, l’information qualitative, elle, sera conservée dans une bibliothèque qui sera
elle aussi accessible à tous. Intranet vient encore soutenir très efficacement la plupart
des organisations que j’ai visitées. Formulaires types, exemples de documents bien
renseignés, bilans de projets, documents de formation : voilà autant d’exemples
concrets du contenu de cette véritable bibliothèque d’Alexandrie.
SP1.6 Establish Work Environment SP1.6 Établir des normes

Standards pour l’environnement de travail
Establish and maintain work environment Établir et maintenir des normes

standards. pour l’environnement de travail.
Les projets vont utiliser des outils de travail, vont devoir se plier à des normes,
vont utiliser des composants matériels, logiciels ou autres qui constitueront leur
environnement de travail. Cette pratique vise à établir un mode de fonctionnement
standard en ce qui concerne l’environnement de travail.
SP1.7 Establish Rules and Guidelines for SP1.7 Établir des règles et lignes directrices
teams pour les équipes
Establish and maintain organizational rules and Établir et maintenir des règles et des lignes
guidelines for the structure, formation, and opera- directrices pour la structure, la constitution et le
tion of teams. fonctionnement des équipes.
Les projets vont utiliser des outils de travail, vont devoir se plier à des normes,
vont utiliser des composants matériels, logiciels ou autres qui constitueront leur
environnement de travail. Cette pratique vise à établir un mode de fonctionnement
standard en ce qui concerne l’environnement de travail.
Un projet exige généralement de mettre en place une espèce de mini-organisation à
l’intérieur de l’organisation. Cette mini-organisation, telle une équipe de cosmonautes
dans une navette spatiale, va partir en mission pour un certain temps. Pour assurer la
cohésion du groupe qui va habiter la navette, on propose de communiquer à l’équipe
une vision rassembleuse qui la situe par rapport au reste de l’organisation. Ce sera le
cri de ralliement, la ligne de parti, la chanson du groupe pour démarrer le matin, le
costume... Bon j’exagère, certes, mais il s’agit de réunir les gens autour d’une bannière
qui reste tout de même connectée sur la réalité du projet au sein de la société. Le
système de récompense (par exemple : augmentation de salaire, promotion) doit être
harmonisé avec l’objectif fondamental : travailler de façon collaborative. En plus de
bien connaître son métier, il faut savoir travailler en groupe, respecter les métiers
des autres, se rallier aux décisions du groupe : ce sont là des aptitudes souhaitées.
Par ailleurs, certains projets ou activités peuvent demander une ressource spéciale
de soutien : par exemple un technicien en vidéoconférence et soutien aux outils de
travail de groupe.
Dans certaines organisations, les projets impliquent une organisation matricielle.
Chaque personne vient d’une unité d’origine qu’elle délaisse plus ou moins le temps
que dure leur projet. L’unité d’origine peut réclamer une certaine participation
maintenue aux activités de l’unité d’origine en dépit du projet en cours pour, par
exemple, participer à des réunions périodiques du département d’origine. On veut
ainsi, par cette bonne pratique, éviter de déconnecter complètement les ressources de
leurs unités d’origine et ainsi faciliter pour elles le retour « à la normale » à la fin du
projet.
8.2.8 Formation organisationnelle
Formation organisationnelle – un domaine de processus de la catégorie Gestion

de processus dans la représentation continue.
OT Organizational Training Formation organisationnelle
The purpose of Organizational Training (OT) is to L’intention de Formation organisationnelle (OT) est
develop skills and knowledge of people so they de développer les aptitudes et connaissances des
can perform their roles effectively and efficiently. personnes de telle sorte qu’elles puissent remplir
leurs rôles de façon efficace et efficiente.
Les lecteurs auront bien noté que dans chacun des domaines de processus, on
parle déjà de formation. En effet, la pratique générique GP2.5 requiert la définition
des moyens de formation propres à chacun des domaines de processus. Il doit donc y
avoir des aspects nouveaux pour constituer tout un domaine de processus en sus des
22 occurrences de GP2.5. Le mot-clé dans le nom de ce domaine de processus est
« organisationnel ». En plus, donc, d’appliquer la pratique GP2.5 dans chaque domaine
de processus, généralement au niveau de chaque projet, une organisation de niveau 3
doit mettre en œuvre une démarche de consolidation des besoins de formation pour
toute l’organisation. Le résultat sera un programme de formation organisationnelle
qui est assez souvent géré par un délégué des Ressources humaines.
Établir une capacité de formation organisationnelle
SG1 Establish an Organizational Training SG1 Établir une capacité de formation

Capability organisationnelle
A training capability, which supports the roles in Une capacité de formation qui soutient les rôles
the organization, is established and maintained. dans l’organisation est établie et maintenue.
Rappelons-nous les domaines de processus PI, VER et VAL. On préparait dans un

premier objectif et on réalisait dans un autre objectif. La même logique (préparation
dans un objectif et réalisation dans un second objectif) se retrouve dans OT.
SP1.1 Establish Strategic Training Needs SP1.1 Établir les besoins stratégiques
de formation
Establish and maintain strategic training needs of Établir et maintenir les besoins stratégiques de
the organization. formation de l’organisation.
En plus des besoins propres à chacun des projets, il importe de collecter les besoins
qui se rapportent à des activités hors des projets ou, en tout cas, hors des projets en
cours. Imaginons une organisation qui voudrait développer son marché en Chine.
On peut normalement s’attendre à ce qu’elle exprime le besoin de former un certain
nombre de représentants commerciaux ou d’analystes d’affaires à la langue chinoise
(au mandarin). Sur le plan technique, il peut s’agir de vouloir explorer une nouvelle
technologie à laquelle il faudra former quelques pionniers.
Qui va payer en définitive ? Le plan de formation (pratique suivante) précise
généralement cette information. Cela peut aussi être régi par des normes organisation-
nelles.
SP1.2 Determine Which Training Needs Are SP1.2 Déterminer quels besoins
the Responsibility of the Organization de formation seront du ressort
de l’organisation
Determine which training needs are the Déterminer quels besoins de formation sont du
responsibility of the organization and which are ressort de l’organisation et lesquels sont laissés à
left to the individual project or support group. la responsabilité de projets individuels ou des
groupes de soutien.
SP1.3 Establish an Organizational Training SP1.3 Établir un plan organisationnel

Tactical Plan tactique de formation
Establish and maintain an organizational training Établir et maintenir un plan tactique de formation
tactical plan. organisationnelle.
En consolidant les besoins de l’organisation, des projets, des groupes de soutien et

des individus (plans de carrière), un plan pour répondre à l’ensemble des besoins doit
être préparé.
SP1.4 Establish a Training Capability SP1.4 Établir une capacité de formation
Establish and maintain a training capability to Établir et maintenir une capacité de formation
address organizational training needs. pour combler les besoins de formation de
l’organisation.
Cette pratique spécifique vise à doter l’organisation des moyens concrets (pro-
grammes de cours, liste d’instructeurs, locaux, etc.) pour pouvoir diffuser la formation.
Dispenser la formation nécessaire
SG2 Provide Training SG2 Dispenser la formation
Training for individuals to perform their roles La formation aux individus pour remplir
effectively is provided. efficacement leurs rôles est dispensée.
SP2.1 Deliver Training SP2.1 Dispenser la formation
Deliver training following the organizational Dispenser la formation selon le plan tactique de
training tactical plan. formation organisationnelle.
Il ne suffit pas de planifier des formations, encore faut-il les dispenser et se

conformer au plan.
Les cours prévus sont donnés en respectant le mieux possible la planification. Il
vaut sans doute la peine de noter ici que la formation visée par le CMMI n’est pas
uniquement la formation magistrale. Dans sa souplesse habituelle, le CMMI accepte
des formations dites « sur le tas » en autant que celles-ci soient préparées et suivies en
accord avec les règles de l’organisation et les plans de formation. De toute façon, il y a
des situations (par exemple, technologie toute nouvelle) où il n’existe pas encore de
cours magistraux sur le marché.
SP2.2 Establish Training Records SP2.2 Établir des enregistrements
de formation
Establish and maintain records of organizational Établir et maintenir des enregistrements de la

training. formation organisationnelle.
Toujours dans un esprit de capitalisation, les expertises disponibles doivent pouvoir

facilement être trouvées. Quoi de mieux, à cet égard, que des dossiers de formation
bien tenus ?
SP2.3 Assess Training Effectiveness SP2.3 Évaluer l’efficacité de la formation
Assess the effectiveness of the organization’s Évaluer l’efficacité du programme de formation

training program. de l’organisation.
Par le biais des sondages réalisés à la fin des formations ou après une période
suffisante pour mesurer l’intégration des nouvelles connaissances ou par tout autre
moyen jugé utile, le CMMI recommande de mesurer l’efficacité des formations
dispensées.
8.2.9 Gestion de projet intégrée
Gestion de projet intégrée – un domaine de processus de la catégorie Gestion de

projet dans la représentation continue.
SVC, il porte le nom de Gestion de travail intégrée (« Integrated Work Management »
- IWC) puisqu’au lieu de projet à date de fin établie, on traite des activités de services
en continu. Partout le mot « projet » est remplacé par « work » dans SVC.
IPM Integrated Project Management Gestion de projet intégrée
The purpose of Integrated Project Management L’intention de Gestion de projet intégrée (IPM) est
(IPM) is to establish and manage the project and d’établir et gérer le projet et l’implication des parties
the involvement of relevant stakeholders according prenantes concernées en accord avec un processus
to an integrated and defined process that is tailored intégré et ajusté qui est dérivé d’un ensemble de
from the organization’s set of standard processes. processus standards au niveau de l’organisation.
Ce domaine de processus est assez particulier. En effet, il reprend en grande partie

les pratiques des domaines PP et PMC du niveau de maturité 2 en les élevant à un
niveau de sophistication plus élevé.
J’ai l’habitude d’imager ce concept en disant que IPM c’est un peu PP + PMC
avec stéroïdes. Un chef de projet de niveau 3 continue bien sûr à faire ses activités
PP et PMC. Cependant, il les accomplira avec plus de force en tirant profit de la
capitalisation rendue possible par OPF et OPD. Voyons cela dans les objectifs et
pratiques qui suivent.
Utiliser le processus ajusté pour le projet
SG1 Use the Project’s Defined Process SG1 Utiliser le processus ajusté
pour le projet
The project is conducted using a defined process Le projet est mené en utilisant un processus
tailored from the organization’s set of standard ajusté dérivé de l’ensemble de processus
processes. standards de l’organisation.
Le chef de projet, au lieu de construire son processus à partir de zéro, va devoir

utiliser le processus standard de l’organisation et l’adapter aux contraintes de son
projet en justifiant les adaptations qu’il fera.
SP1.1 Establish the Project’s Defined Process SP1.1 Établir le processus ajusté
pour le projet
Establish and maintain the project’s defined Établir et maintenir le processus ajusté du projet
process from project startup through the life of depuis le début du projet et tout au long de la vie
the project. du projet.
Cette pratique est sans doute la plus fondamentale d’IPM puisqu’elle traduit tout
l’esprit du niveau 3 : dériver son processus ajusté au projet à partir du processus
organisationnel standard. Elle fait aussi le pendant de toutes les GP3.1. En ce sens, c’est
la principale difficulté pour les novices du CMMI : cette pratique est-elle vraiment
différente de la somme des GP3.1 ? Pas vraiment. C’est un peu comme CM qui est
le pendant des GP2.6 ou de PPQA qui répond aux GP2.9. Autre difficulté pour les
novices : ne pas oublier qu’une organisation de niveau de maturité 3 (avec le CMMI
étagé) doit « rehausser » ses exigences de normalisation, y compris pour les processus
localisés au niveau de maturité 2 ! Ainsi, REQM, PP, PMC, etc. doivent se faire selon
une approche standard commune à toute l’organisation (avec l’obligation d’ajuster
aux besoins de chaque projet).
Le processus ajusté est généralement identifié et décrit dans le plan du projet. Il
est important que soient bien notées les adaptations afin que lors du bilan de projet,
on puisse évaluer l’impact de celles-ci sur la performance du projet. Par analogie avec
les annonces officielles de début de mandat de nouveaux élus, je dis parfois que cette
pratique consiste pour le chef de projet à faire sa déclaration à la nation : « Je promets
que mon projet respectera tous les processus organisationnels standards mais, à cause des
particularités de mon projet, je réclame le droit d’appliquer les variations suivantes que je
justifie ci-dessous... ». Les ajustements doivent donc être bien décrits et justifiés. Du
coup, la personne qui fera l’assurance qualité saura précisément quand l’examen de
conformité s’appuiera sur les actifs processus standards et quand il s’appuiera plutôt
sur certaines variantes spécifiques au projet.
SP1.2 Use Organizational Process Assets SP1.2 Utiliser les actifs processus
for Planning Project Activities organisationnels pour les activités
de planification du projet
Use organizational process assets and the Utiliser les actifs de processus organisationnels et
measurement repository for estimating and la base de mesures pour les activités d’estimation
planning project activities. et de planification du projet.
La contrepartie de la collecte associée à la capitalisation est l’obligation d’utiliser

le capital dans les projets subséquents, sinon la performance d’un projet ne pourra
jamais être comparée à l’historique des projets.
SP1.3 Establish the Project’s SP1.3 Établir l’environnement

Work Environment de travail du projet
Establish and maintain the project’s work Établir et maintenir l’environnement de travail du
environment based on the organization’s work projet sur la base des normes d’environnement
environment standards. de travail de l’organisation.
Dans certaines organisations, l’environnement de travail qui est mis en place

pour chaque projet est très normalisé et déjà disponible, prêt à l’usage si on peut
dire ; dans d’autres organisations, chaque projet doit préparer la mise en place d’un
environnement particulier. Si on pense aux projets en mode IPPD par exemple, on ne
doit pas ménager les moyens physiques et virtuels pour favoriser le partage de données
et d’idées. Songeons aux méthodes dites « agiles » qui, elles aussi, recommandent
un aménagement de l’espace bien particulier qui vise des échanges fructueux et
efficaces entre les intervenants. Disposition des lieux, mobilier spécial, postes de
travail avec logiciels de soutien au travail de groupe, vidéoconférence ne sont que

quelques exemples de l’arsenal auquel on peut recourir.
SP1.4 Integrate Plans SP1.4 Intégrer les plans
Integrate the project plan and other plans that Intégrer le plan projet et les autres plans qui ont
affect the project to describe the project’s defined une incidence sur le projet pour décrire le
process. processus ajusté du projet.
Les autres plans comprennent, par exemple, les plans d’assurance qualité, de gestion
de configuration, de gestion du risque, de formation, etc.
SP1.5 Manage the Project Using SP1.5 Gérer le projet en utilisant

Integrated Plans les plans intégrés
Manage the project using the project plan, other Gérer le projet en utilisant le plan de projet,
plans that affect the project, and the project’s les autres plans qui ont une incidence sur le projet
defined process. et le processus ajusté documenté du projet.
Cette pratique spécifique à elle seule recoupe la plupart des pratiques spécifiques
de PP et PMC, mais à un degré plus poussé de sophistication. Tout ceci se trouve
exprimé dans le seul mot « gérer » qui est ici utilisé au lieu de « planifier » dans PP
ainsi que « surveiller » dans PMC. Concrètement, la différence se retrouve dans la
sous-pratique 2 et plus précisément dans le troisième point de cette sous-pratique. Il
faut porter attention au mot « seuil » (thresholds).
Au niveau de maturité 2, le chef de projet ne dispose pas de tels seuils. Lorsqu’il
détecte un écart par rapport au plan, il réagit en fonction de son intuition quant à
l’importance de cet écart. Au niveau 3, le chef de projet profite en quelque sorte de la
présence virtuelle de tous les chefs des projets passés qui le conseillent par le biais des
valeurs exprimées dans les seuils.
Lors d’évaluations, lorsqu’on doit couvrir le niveau de maturité ou d’aptitude
3, il m’arrive assez souvent de poser la question suivante aux chefs de projets qui
travaillent dans la même organisation depuis plusieurs années : « Depuis les derniers
mois, quelle différence avez-vous remarqué dans votre façon de surveiller vos projets ? De
quelle information additionnelle bénéficiez-vous pour vous aider à déterminer si oui ou non
un dépassement est critique ou pas ? Quel impact les données des autres projets ont-elles sur
votre façon de piloter votre projet ? »
SP1.6 Establish Teams SP1.6 Établir les équipes
Establish and maintain teams. Établir et maintenir les équipes.
Quand un projet démarre, on crée en quelque sorte une petite société propre au
projet. On doit déterminer quelle organisation de projet sera mise en place, comment
on affecte les bonnes personnes aux bons rôles dans l’organisation d’équipe et des sous-
équipes. On affectera les personnes dans une structure qui sera optimale pour les fins du
projet sans forcément tenir compte de leurs unités d’origine. Ceci se fera normalement
dans le plan de projet, dans la section établissant justement l’organisation du projet.
SP1.7 Contribute to Organizational Process SP1.7 Contribuer aux actifs processus

Assets organisationnels
Contribute process related experiences to Contribuer par le biais de retours d’expériences

organizational process assets. aux actifs processus organisationnels.
Encore une fois, la capitalisation a ses exigences. Elle se nourrit des retours de
chaque projet. C’est ce que j’appelle avec humour « partager ses jouets avec ses
copains ». Chaque fois que je dois expliquer cette pratique, je revois les jeux de
société ou une case demande de payer son dû (comme au Monopoly par exemple
quand on arrive sur une case d’un terrain détenu par un autre joueur). Sur une note
moins ludique, je pense aux impôts : puisqu’on profite de services communs, résultats
de la capitalisation, il faut payer. La façon de le faire, c’est par ses propres retours
d’expérience (qu’on nomme savamment « post-mortem » ou plus simplement bilans
de projets) et aussi par le fait de ne plus conserver ses données de projets (estimation,
suivi, statistiques de toutes sortes) dans son dossier projet seulement mais de les faire
remonter dans le répertoire organisationnel de mesures.
Coordonner et collaborer avec les parties prenantes concernées

Cet objectif spécifique recoupe une bonne partie des activités que l’on retrouvait
anciennement dans le modèle SW-CMM en coordination inter-groupes.
SG2 Coordinate and Collaborate SG2 Coordonner et collaborer

with Relevant Stakeholders avec les parties prenantes concernées
Coordination and collaboration between the La coordination et la collaboration entre le projet

project and relevant stakeholders ares conducted. et les parties prenantes concernées sont menées.
SP2.1 Manage Stakeholder Involvement SP2.1 Gérer l’implication

Manage the involvement of relevant stakeholders Gérer l’implication dans le projet des parties
in the project. prenantes concernées.
Cette pratique fait appel au sens de coordination et d’arbitrage du chef de projet.

Quand on me demande en quoi cette pratique diffère de PP-SP2.6 et PMC-SP1.5,
combinées aux GP2.7, je suis un peu embêté ! En fait, il n’y a que la notion propre
au niveau 3 de processus standard duquel on dérive son processus projet ajusté qui
vient ajouter une nuance ; c’est-à-dire que je devrais pouvoir faire mon suivi des
parties prenantes en m’appuyant par exemple sur des modèles types, des listes (ou
« checklists ») standards.
SP2.2 Manage Dependencies SP2.2 Gérer les dépendances
Participate with relevant stakeholders to identify, Participer avec les parties prenantes concernées à
negotiate, and track critical dependencies. l’identification, à la négociation et au suivi
des dépendances critiques.
Au niveau 3, les plans de projet indiquent clairement les dépendances critiques

et les chemins critiques. Ceux-ci sont ensuite régulièrement examinés par le chef
de projet afin de focaliser sur les points susceptibles de créer des problèmes de
coordination.
Cette pratique va donc plus loin que SP2.1 en demandant d’utiliser une approche
de gestion de projet qui tient compte des dépendances critiques. En réalité, dans
plusieurs organisations, dès qu’on utilise un outil de gestion de projets, les chefs de
projets, même au niveau 2, appliquent ces idées : faire ressortir quelles activités se
trouvent sur le chemin critique ? Quelles attentes a-t-on de recevoir au moment
critique les livrables de toutes les parties prenantes dont dépend le démarrage d’une
activité subséquente ? Souvent, on retrouve cette information sous forme de risques
exprimés dans le plan (par exemple : on sera en retard dans le projet si les unités X,
Y et Z ne livrent pas à temps leurs composants au groupe d’intégration ; or ces unités
sont actuellement en manque de ressources pour cause d’absences nombreuses ces
derniers mois).
SP2.3 Resolve Coordination Issues SP2.3 Régler les problèmes de coordination
Resolve issues with relevant stakeholders. Régler les problèmes avec les parties prenantes
concernées.
Il s’agit ici essentiellement d’arbitrage. La plupart du temps, si on fait bien IPM-

SP1.1 et SP1.2 et qu’on tient ses réunions de surveillance de projet (PMC-SP1.6),
alors la pratique IPM-SP2.3 se fait tout naturellement. On ne laissera jamais ouvert
un point d’action qui demande un arbitrage entre plusieurs groupes par exemple.
8.2.10 Gestion des risques
Gestion des risques – un domaine de processus de la catégorie Gestion de Projet

RSKM Risk Management Gestion du risque

The purpose of Risk Management (RSKM) is to L’intention de Gestion des risques (RSKM) est
identify potential problems before they occur so d’identifier des problèmes potentiels avant qu’ils
that risk handling activities may be planned and surviennent de telle sorte que les activités pour
invoked as needed across the life of the product traiter les risques puissent être planifiées et
or project to mitigate adverse impacts on déclenchées au besoin tout au long de la vie du
achieving objectives. produit ou du projet afin que les impacts nuisibles
à l’atteinte des objectifs soient atténués.
Dans le modèle SW-CMM, les activités relatives à la gestion des risques se

retrouvaient au niveau des pratiques de planification, de suivi et de gestion intégrée.
Les auteurs du CMMI ont reçu de nombreux commentaires sur l’importance très
grande d’une bonne gestion des risques dans les projets. Un long débat s’est achevé
sur la décision de consacrer à la gestion des risques tout un domaine de processus.
Se préparer pour la gestion des risques
SG1 Prepare for Risk Management SG1 Se préparer pour la gestion des risques
Preparation for risk management is conducted. La préparation pour la gestion des risques est
menée.
On retrouve encore une fois la logique de décrire les activités de préparation

dans un premier objectif spécifique, puis celles de réalisation dans un second objectif
spécifique. Cette logique avait été utilisée dans PI, VER et VAL.
SP1.1 Determine Risk Sources SP1.1 Déterminer les sources

and Categories et les catégories de risques
Determine risk sources and categories. Déterminer les sources et les catégories de
risques.
Cette pratique spécifique est rarement accomplie dans le projet lui-même. Les chefs
de projet reçoivent généralement cette information dans la méthodologie imposée au
niveau organisationnel ou dans un guide spécifique à la gestion des risques.
Dans ma pratique, je suis agréablement surpris de constater que plusieurs sociétés
ont recours à une taxonomie des risques (une sorte de catalogue des risques qui permet
d’utiliser le même langage et de ne pas oublier d’identifier les risques possibles d’un
projet) standard au niveau organisationnel et donc partagée par tous les projets. À
cet égard, le SEI a publié un excellent document de référence « Taxonomy-Based Risk
Identification » qu’on trouve sur son site : http://www.sei.cmu.edu/reports/93tr006.pdf.
On se rappelle que dans PP – Planification de projet on retrouve l’identification des
risques (PP-SP2.2) mais sans l’exigence de catégoriser les risques ; c’est une pratique,
plus « légère » alors que RSKM constitue une ensemble de pratiques plus « poussées ».
SP1.2 Define Risk Parameters SP1.2 Définir les paramètres de risques
Define parameters used to analyze and categorize Définir les paramètres utilisés pour analyser et
risksto control the risk management effort. catégoriser les risques ainsi que pour contrôler
la charge de gestion des risques.
À titre d’exemple, les paramètres de risques incluent la probabilité, l’impact, la

criticité, etc. Les organisations qui accordent (à juste titre !) de l’importance à la
gestion des risques comprennent facilement que chaque risque, pour être traité de
la manière qui convient, doit être caractérisé selon certaines échelles associées, au
minimum, à la probabilité d’occurrence, l’étendue de l’impact et la sévérité ou criticité
des dommages possibles ; assez souvent, on précise aussi à partir de quel seuil il est
recommandé d’agir pour contrer le risque. Tout comme pour SP1.1, je rencontre peu
de difficulté d’interprétation sur cette pratique tant elle semble logique et limpide.
Attention : quand je dis ça, je ne veux pas dire que c’est toujours fait dans les
organisations et les projets que j’ai eu la chance de voir mais seulement que les gens
comprennent très vite de quoi il s’agit et peuvent rapidement nous dire s’ils le font ou
pas et nous montrer des preuves le cas échéant.
SP1.3 Establish a Risk Management SP1.3 Établir la stratégie

Strategy de gestion des risques
Establish and maintain the strategy to be used Établir et maintenir la stratégie qui sera utilisée
for risk management. pour la gestion des risques.
Cette pratique demande d’expliciter l’approche qui sera prise pour gérer les risques.
Par exemple, on précisera la fréquence des revues de risques, les méthodes d’analyse
et de communication et les approches de réduction des risques.
Identifier et analyser les risques
SG2 Identify and Analyze Risks SG2 Identifier et analyser les risques
Risks are identified and analyzed to determine Les risques sont identifiés et analysés pour
their relative importance. déterminer leur importance relative.
Si l’objectif SG1 se trouvait généralement satisfait par des activités accomplies

au niveau de l’organisation et dont les résultats étaient rendus disponibles pour les
chefs de projet, les pratiques sous l’objectif spécifique SG2 doivent être accomplies au
niveau du projet.
Cette pratique spécifique ressemble à la pratique de PP-2.2. En fait en RSKM (par
rapport à PP), on demande de produire le même résultat (liste des risques) mais en
donnant plus de détails qui sont exigés par la stratégie décrite en RSKM-SP1.3.
SP2.1 Identify Risks SP2.1 Identifier les risques
Identify and document risks. Identifier et documenter les risques.
SP2.2 Evaluate, Categorize, SP2.2 Évaluer les risques, les catégoriser

and Prioritize Risks et les ordonner par priorités
Evaluate and categorize each identified risk using Évaluer et catégoriser chaque risque identifié en
defined risk categories and parameters, and utilisant les catégories et les paramètres de
determine its relative priority. risques établis et déterminer leur priorité relative.
Dans les organisations que j’ai visitées, le résultat de cette analyse se présentait
souvent sous forme de matrices avec des zones exprimant la criticité des risques (vert,
jaune, rouge).
Atténuer les risques
SG3 Mitigate Risks SG3 Atténuer les risques
Risks are handled and mitigated as appropriate to Les risques sont gérés et atténués lorsque
reduce adverse impacts on achieving objectives. nécessaire afin de diminuer les impacts qui
peuvent nuire à l’atteinte des objectifs.
On remarquera que les pratiques de cet objectif spécifique ne se retrouvent pas en

PP, ni en PMC.
SP3.1 Develop Risk Mitigation Plans SP3.1 Développer les plans d’atténuation
des risques
Develop a risk mitigation plan in accordance with Développer un plan d’atténuation du risque en
the risk management strategy. accord avec la stratégie de gestion des risques.
Le piège de cette pratique c’est que dans sa formulation elle ne parle que
d’atténuation de risque. Dans la réalité (et dans la formulation des sous-pratiques)
elle couvre en fait deux types d’interventions : celles qui consistent à diminuer la
probabilité d’occurrence d’un risque (l’atténuation du risque) et celles qui consistent
à réparer les dégâts (la contingence) lorsque, malgré l’atténuation, le risque s’est
effectivement matérialisé. Le CMMI n’exige pas de faire de tels plans (atténuation et
contingence) pour tous les risques ; la directive (GP2.1), le processus (GP2.2) ou la
stratégie (SP1.3) sont autant d’endroits pour préciser les exigences (ou les seuils) de
faire ou de ne pas faire de tels plans au regard des risques identifiés.
SP3.2 Implement Risk Mitigation Plans SP3.2 Mettre en œuvre les plans
d’atténuation des risques
Monitor the status of each risk periodically and Surveiller périodiquement le statut de chaque
implement the risk mitigation plan as appropriate. risque et mettre en œuvre, selon les besoins, le
plan d’atténuation du risque.
Comme on le disait ci-dessus, ce n’est pas parce qu’on a préparé des plans d’atté-
nuation de risque qu’on devra nécessairement les utiliser. Seul un suivi périodique et
méticuleux permettra de détecter le moment où il faudra se résoudre à faire appel à ces
plans. Les rencontres périodiques d’avancement de projet constituent des moments
privilégiés pour revoir et réévaluer les risques.
8.2.11 Analyse et prise de décision
Analyse et prise de décision – un domaine de processus de la catégorie Support

Ce domaine de processus se retrouve dans les 3 constellations (DEV, SVC et ACQ)
DAR Decision Analysis and Resolution Analyse et prise de décision
The purpose of Decision Analysis and Resolution L’intention d’ Analyse et prise de décision (DAR)
(DAR) is to analyze possible decisions using a est d’analyser des décisions éventuelles en utilisant
formal evaluation process that evaluates identified un processus d’évaluation formel qui évalue, au
alternatives against established criteria. regard de critères établis, des solutions possibles
déterminées.
Les auteurs du CMMI ont dû débattre assez longtemps pour décider s’ils devaient ou
non inclure ce domaine de processus dans le modèle. En effet d’aucuns ont reproché
et reprochent encore aux auteurs d’avoir ainsi ouvert la porte à des domaines de
processus qui font intrinsèquement partie des habiletés de tout professionnel : savoir
écrire, faire des présentations, animer des réunions, bref savoir travailler. Dans tout
travail professionnel, il arrive que l’on ait à prendre des décisions difficiles qui auront
un impact important. Devoir le faire rationnellement tombe sous le sens pour ceux qui
s’opposaient à faire entrer DAR dans le CMMI. Néanmoins, compte tenu de l’absence
d’une telle démarche rationnelle dans plusieurs projets lors de décisions importantes,
les auteurs ont finalement résolu (peut-être en appliquant DAR ?) de l’inclure dans
le modèle. Au niveau de maturité 3 en représentation étagée, on s’attend donc
que les projets prennent des décisions importantes en s’appuyant sur une démarche
disciplinée.
Évaluer les solutions possibles

Il n’y a qu’un seul objectif spécifique dans le domaine de processus Analyse et prise de
décision. Il contient donc toute la portée de domaine dans les seuls mots « évaluation »
et « critères établis ». Le message est fondamentalement simple : ne pas prendre de
décisions à la légère lorsqu’il s’agit de décisions importantes.
SG1 Evaluate Alternatives SG1 Évaluer les solutions possibles
Decisions are based on an evaluation Les décisions sont basées sur une évaluation des
of alternatives using established criteria. solutions possibles en utilisant des critères établis.
Serait-il normal que dans le cadre d’une évaluation on ne rencontre, dans un projet
donné, aucun cas de décision s’appuyant sur les mécanismes décrits dans DAR ? Là
encore, la réponse est simple : non ! Tout projet comporte au moins (sauf exception
très rare) une occasion de décision qui tombe dans la catégorie des décisions devant
être justifiées par une approche DAR : acheter un produit sur étagère ou réutiliser ou
développer ; adopter une architecture fortement centralisée ou décentralisée ; choisir
la technologie X ou Y, le fournisseur A ou B ; voilà quelques exemples types.
SP1.1 Establish Guidelines SP1.1 Établir les lignes directrices

for Decision Analysis pour l’analyse de décision
Establish and maintain guidelines to determine Établir et maintenir les lignes directrices pour
which issues are subject to a formal evaluation déterminer quels problèmes doivent être soumis
process. à un processus d’évaluation formel.
Il faut d’abord distinguer entre ce qui est important et ce qui ne l’est pas. Des
lignes directrices doivent aider les projets à faire la part des choses. Le domaine de
processus DAR ne sera pas exigé sur des décisions qui ne seront pas jugées suffisamment
importantes pour déployer l’artillerie lourde.
SP1.2 Establish Evaluation Criteria SP1.2 Établir et maintenir

les critères d’évaluation
Establish and maintain criteria for evaluating Établir et maintenir les critères d’évaluation des
alternatives, and the relative ranking of these solutions possibles et le classement relatif de ces
criteria. critères.
Une fois qu’on a choisi d’appliquer DAR pour une décision à prendre, on
recommande de préparer une grille de critères pondérés par leur importance relative
pour le projet.
SP1.3 Identify Alternative Solutions SP1.3 Identifier les solutions possibles
Identify alternative solutions to address issues. Identifier les solutions possibles pour résoudre les
problèmes.
Dans la grille de décision, on vient inscrire les solutions possibles que l’on a choisi
de comparer.
SP1.4 Select Evaluation Methods SP1.4 Sélectionner les méthodes

d’évaluation
Select evaluation methods. Sélectionner les méthodes d’évaluation.
Pour obtenir les informations recherchées, plusieurs approches peuvent être

envisagées. Cette pratique demande de les identifier. Va-t-on consulter des revues
spécialisées ? Interroger des spécialistes reconnus ? Faire des sondages ? Des visites
industrielles ?
SP1.5 Evaluate Alternative Solutions SP1.5 Évaluer les solutions possibles
Evaluate alternative solutions using established Évaluer les solutions possibles en utilisant les
criteria and methods. critères et les méthodes établis.
On procède à l’évaluation proprement dite. Autrement dit, on inscrit dans notre

grille de décision les renseignements obtenus en appliquant les méthodes d’évaluation.
SP1.6 Select Solutions SP1.6 Sélectionner les solutions
Select solutions from alternatives based on Sélectionner les solutions à partir des solutions
evaluation criteria. possibles en s’appuyant sur les critères
d’évaluation.
« Il n’y a plus qu’à... » comme m’ont appris à dire mes copains de France. On suit
la logique de la démarche dont le résultat, la décision, découle des résultats de calculs
la plupart du temps bien peu savants. Que du bon sens quoi !
Avez-vous bien LU ?
a) Pourquoi le mot « ajusté » caractérise-t-il bien le niveau 3 dans le CMMI ?
b) Quelle pratique générique du niveau 3 demande, pour chaque domaine de

processus... :
1) D’utiliser toujours les procédures standards comme point de départ de ses façons
de faire ?
2) De contribuer, depuis chaque projet, au capital des actifs processus de l’organisation.
c) Quelle(s) pratique(s) spécifique(s) traitent des bonnes pratiques suivantes... :

1) Il faut établir des critères pour déclencher l’obligation de recourir à une approche
rigoureuse de choix entre plusieurs options.
2) Un chef de projet doit appliquer une approche appropriée de gestion des
dépendances critiques.
3) Si une situation critique se présentait, il faut avoir, sous le coude, une série d’actions
documentées et prêtes à être déclenchées.
4) Le prototypage, des visites industrielles, des maquettes d’écran : voilà autant de
moyens de s’assurer que l’on comprend bien ce que notre client envisage comme
solution.
5) De temps en temps, il faut faire un état des lieux des procédures, des gabarits
(modèles), des guides, des outils, etc., qui sont proposés à l’ensemble des projets.
6) Avant de soumettre un document à l’AQ (ou à son client), il est prudent de
demander à des collègues de le relire.
7) Plusieurs points doivent être examinés de façon systématique avant de transmettre
son produit assemblé à son client.
8) En vue de permettre aux projets de stocker leurs statistiques de performance, il faut
mettre en place un réservoir de données structuré.
9) Entre les exigences du client et la construction de la solution, il y a une étape
intermédiaire importante à réaliser.
10) Il faut s’assurer d’avoir tout ce qu’il faut pour pouvoir faire des essais.
11) Il faut préparer soigneusement différents scénarios avec résultats attendus pour
permettre à notre client d’accepter notre solution.
11) Il faut s’assurer qu’on a l’infrastructure requise pour pouvoir former tout son
personnel.

a) Pourquoi est-il faux de dire qu’au niveau de maturité 3 tous les projets fonctionnent
exactement de la même façon ?
b) Imaginez que vous êtes un chef de projet. Faites un plaidoyer (avec argumentaire)
en faveur du niveau de maturité 3 du CMMI.

pour un développeur ; pour un chef de projet ; pour un membre de la Direction ?
d) Pour chacune des pratiques génériques du niveau 3, imaginez que la pratique

n’est vraiment pas satisfaite et expliquez ce qui arriverait dans un projet quelconque.
e) Pour chaque pratique spécifique suivante, donnez au moins un exemple de

dans un projet donné ou au niveau de l’organisation:
1) IPM-SP2.2 ;
2) OPF-SP2.1 ;
3) VER-SP1.3 ;
4) PI-SP1.2 ;
5) DAR-SP1.5 ;
6) TS-SP2.2 ;
7) OT-SP1.3 ;
8) VAL-SP2.2 ;
9) RSKM-SP3.2 ;
10) RD-SP3.3 ;
11) OPD-SP1.3.
9
Le niveau 4
De la capitalisation et de l’ajustement à une approche quantitative des projets et des

processus : appliquer des approches statistiques pour mettre quelques processus de
développement sous contrôle statistique
Une organisation qui fonctionne au niveau de maturité 3 depuis un certain
temps prend conscience de la force collective que donne un savoir partagé. La
base de données historique contient alors des statistiques collectées dans des projets
dont le processus commun permet une véritable comparaison et une projection des
performances. Par exemple, si depuis plusieurs mois on cumule les données sur les
charges consommées en relation avec des produits dont on a aussi mesuré les facteurs
« dimensionnants » (par exemple : taille, complexité), on peut en arriver à dégager
des tendances de productivité et prévoir que si la tendance se maintient, les projets à
venir devraient utiliser une productivité X calculée à partir de l’historique. Un groupe
aura comme mission de surveiller les performances des projets dont les données sont
conservées dans la base de mesures de l’organisation. Périodiquement (une ou deux fois
par année par exemple), ce groupe (ou cette personne) fixera des objectifs directement
dérivés de l’interprétation des statistiques disponibles. Ces objectifs porteront d’une
part sur un certain nombre de processus au niveau de leur performance (par exemple
en TS – Solution technique : constater que les projets d’une organisation devraient être
capables, selon la base historique, d’écrire N pages de spécifications techniques entre
Y et Z heures) et au niveau de la qualité des produits d’activité (par exemple toujours
en TS – Solution technique : constater que les projets d’une organisation devraient être
capables d’écrire du code sans injecter plus de N erreurs dans le code avant la phase
de test d’intégration).
À partir du moment où de tels objectifs quantitatifs sont disponibles, le niveau 4
du CMMI demande que les projets en tiennent compte dans la surveillance de
leurs activités. Les chefs de projet vont choisir les processus et sous-processus sur
lesquels ils estiment utile de focaliser leur attention. Les objectifs quantitatifs leur
sont communiqués et représentent la capacité organisationnelle, dérivée à partir des

données historiques. Chaque fois que la performance constatée sur les projets dérive
de ces objectifs, les chefs de projets devront prendre une action destinée à ramener
la performance à l’intérieur des objectifs fixés. C’est ce qu’on appelle la gestion
quantitative.
À force d’appliquer des correctifs lors de dérives au regard des objectifs, le processus
ciblé finit par se stabiliser à l’intérieur des bornes fixées. En langage statistique, on dira
qu’on a éliminé les causes spéciales de variation et que notre processus est stabilisé.
L’atteinte du niveau 4 va supposer une activité de détermination des objectifs
quantitatifs au niveau de l’organisation et en fonction de l’historique des projets. Son
pendant sera l’activité au niveau des projets : l’utilisation des objectifs quantitatifs
comme moyen pour stabiliser un certain nombre de processus déterminés.
Il n’y a pas d’objectif générique GG4 ni de pratiques génériques GP4.n

dans le CMMI
Dans sa représentation étagée, le CMMI ne propose pas de nouvelles pratiques
d’institutionnalisation au-delà du niveau 3. Donc, en plus des pratiques spécifiques de
niveau 4, les domaines de processus n’auront qu’à appliquer les objectifs et pratiques
génériques des niveaux 2 et 3.
Rappelons que l’on vise le contrôle statistique d’un certain nombre de processus au
niveau 4 mais pas de tous. Il a semblé aux auteurs du CMMI que ce serait tout
à fait utopique de forcer le contrôle statistique sur tous les domaines de processus.
Conséquemment, on ne peut pas institutionnaliser un comportement de niveau 4 sur
l’ensemble des domaines de processus et donc de discipliner, capitaliser et personnaliser,
hérités des niveaux 2 et 3 mais de les stabiliser en plus. Par ailleurs, si on lit le contenu
des domaines de processus situé au niveau de maturité 4, OPP – « Performance du
processus organisationnel » et QPM – « Gestion de projet quantitative », on constate
qu’ils induisent bel et bien au sein de l’organisation un comportement de gestion
quantitative sélectif (sur des processus ou sous-processus ciblé), ce qui est bien le
propre de la vision « niveau 4 ».
En ce qui concerne la représentation continue, les auteurs du CMMI préconisent
le recours à OPP et QPM pour ajouter une vision de « gestion quantitative » aux
processus que l’on aura sélectionnés.

Tout comme je le faisais pour les pratiques des niveaux 2 et 3, je rappelle que je n’ai
pas la prétention de proposer une traduction officielle de tout le modèle CMMI. Je
répète que je propose plutôt une traduction ciblée des pratiques et des objectifs de

Au niveau de maturité 4, il n’y a pas de domaines de processus qui seraient exclusifs
aux constellations SVC et ACQ ; ceux décrits ici pour DEV sont donc applicables
également aux deux autres constellations. Rappelons toutefois la nuance que dans
SVC, le mot « projet » est remplacé par « travail », y compris dans le nom et le sigle
du domaine QPM qui devient QWM.
9.1.1 Performance du processus organisationnel
Performance du processus organisationnel – un domaine de processus de la

OPP Organizational Process Performance Performance du processus organisationnel
The purpose of Organizational Process L’intention de Performance du processus

Performance (OPP) is to establish and maintain a organisationnel (OPP) est d’établir et maintenir
quantitative understanding of the performance of une appréciation quantitative de la performance
selected processes in the organization’s set de processus sélectionnés dans l’ensemble des
of standard processes in support of achieving processus standards de l’organisation quant à leur
quality and process-performance objectives, and to soutien des objectifs de qualité et de performance
provide the process performance data, baselines, des processus. Ce domaine de processus vise aussi
and models to quantitatively manage the à fournir des données sur la performance
organization’s projects. des processus, des référentiels et des modèles pour
permettre aux projets de l’organisation d’appliquer
une approche de gestion quantitative.
Au niveau 4, on exploitera au maximum le potentiel des informations historiques

capitalisées pour exprimer de façon quantitative des objectifs réalistes puisqu’ils
s’appuient sur la réalité de la performance organisationnelle.
Établir des référentiels et des modèles de performance
SG1 Establish Performance Baselines SG1 Établir des référentiels et des modèles
and Models de performance
Baselines and models that characterize the Des référentiels et des modèles qui caractérisent
expected process performance of the la performance attendue des processus standards
organization’s set of standard processes are de l’organisation sont établis et maintenus.
established and maintained.
Il n’y a qu’un seul objectif spécifique dans le domaine de processus OPP. Cet objectif
recouvre donc évidemment toute la portée du domaine. Celle-ci vise essentiellement à
rendre accessibles au projet les données sophistiquées qui leur permettront d’appliquer
une approche de gestion quantitative.
SP1.1 Establish Quality SP1.1 Établir les objectifs de qualité

and Process Performance Objectives et de performance de processus
Establish and maintain the organization’s Établir et maintenir des objectifs quantitatifs qui
quantitative objectives for quality and process sont reliés aux objectifs d’entreprisea et qui
performance, which are traceable to business portent sur la qualité et la performance des
objectives. processus.
a. Le terme entreprise ici appliqué à « objectifs » correspond à l’expression « business goals » en anglais. Nous avons
été tenté de traduire par « objectifs d’affaires » ou « objectifs commerciaux » mais ceci collait mal lorsqu’on parlait
d’organisations de type gouvernemental ou sans buts lucratifs. Ou encore par « objectifs statégiques » mais plus loin,
dasan les domaines de niveau 5, les auteurs du CMMI évoque des « business strategies » ce qui nous aurait mené vers
une expresssion absurbe de « stratégies stratégiques ». Finalement, l’expression « d’entreprise » évite la connotation
trop commerciale et signifie bien quelque chose qui se situe à haut niveau dans la vision de l’organisation.
Cette démarche de fixation des objectifs se déroule périodiquement et fait appel à

une connaissance fine des données historiques capitalisées. Les objectifs qui sont fixés
seront très certainement réalistes puisqu’ils sont dérivés des statistiques accumulées sur
des projets réels dans sa propre organisation avec son propre ensemble de processus.
Notons ici que les objectifs s’appliquent tout autant à la qualité des produits (par
exemple, densité des erreurs) qu’à la performance des processus (par exemple, durée
cible pour un volume donné).
SP1.2 Select Processes SP1.2 Sélectionner les processus
Select processes or subprocesses in the Sélectionner les processus ou les sous-processus

organization’s set of standard processes to be dans l’ensemble des processus standards de
included in the organization’s process l’organisation à inclure dans les analyses de
performance analyses and maintain traceability to performance des processus de l’organisation et
business objectives. maintenir la traçabilité aux objectifs d’entreprise.
Il n’est pas possible, utile ou justifiable sur le plan économique d’appliquer une
approche de gestion quantitative sur le moindre petit processus. Il faut donc choisir
les armes de la guerre. Le groupe qui suit le contenu des données historiques est
généralement le mieux placé pour recommander les choix les plus intéressants, ceux
qui apporteront le plus de bénéfices pour l’organisation.
La difficulté d’interprétation vient du nombre minimal requis pour considérer
cette pratique pleinement déployée. On peut penser qu’il suffit d’avoir choisi un
seul processus, voire une seule portion de processus (par exemple les revues par les
pairs sur les spécifications techniques détaillées dans VER). Mais ce serait oublier
un point important qui est donné en explication dans le livre en anglais, dans les
sous-pratiques de cette pratique : il faut que les processus ou parties de processus
répondent aux besoins d’entreprise de l’organisation. Il serait assez surprenant que l’on
puisse répondre à ces besoins par un seul objectif quantitatif et les résultats associés !
De plus, la GP2.2 (définir le processus) appliquée à OPP doit établir le processus
de sélection appliqué dans SP1.1 ; encore là, il serait surprenant que ce processus
limite la démarche à un seul objectif. En fait, dans le concret, je cherche toujours à
vérifier pour OPP-SP1.1 le degré d’activité organisationnelle en continue c’est-à-dire,
si quelqu’un a pour mission de chercher (et le fait !) périodiquement et d’allonger la
liste des domaines de processus (ou parties de ceux-ci) qui pourraient rejoindre ceux
qui seront sur le tableau de bord quantitatif.
SP1.3 Establish Process Performance SP1.3 Établir les mesures de performance

Measures du processus
Establish and maintain definitions of measures to Établir et maintenir les définitions des mesures à
be included in the organization’s process inclure dans les analyses de performance des
performance analyses. processus de l’organisation.
Une fois que l’on a choisi les processus sur lesquels porteront nos analyses, il
importe de clarifier les facteurs ou les mesures qui exprimeront le mieux, et de façon
chiffrée, la performance de ces processus. Si on a bien appliqué le domaine de processus
MA – Mesure et Analyse, on aura déjà fait une bonne partie du travail préalable à la
pratique OPP-SP1.2 puisqu’on aura déjà un catalogue de mesures dans lequel puiser.
SP1.4 Analyze Process Performance and SP1.4 Analyser la performance des

Establish Process Performance Baselines processus et établir les référentiels
de performance de processus
Analyze the performance of the selected Analyser la performance des processus

processes, and establish and maintain the process sélectionnés et établir et maintenir les référentiels
performance baselines. de performance des processus.
Dans les organisations que j’ai visitées, un groupe (assurance qualité, bureau de
projets, etc.) assume la responsabilité de divulguer périodiquement les indices de
performance et de qualité.
Cette pratique se déroule en général assez étroitement avec les précédentes. Il s’agit
en fait de préparer l’information destinée aux chefs de projets et présentant les cibles à
atteindre. Comme ces cibles peuvent varier selon certains paramètres (par exemple la
taille des projets – les petits projets devront se référer à un tableau d’objectifs, les gros
à un autre tableau ; la ligne d’affaire – les projets du domaine militaire se référeront
aux objectifs de classe A alors que les projets du domaine commercial se référeront
aux objectifs de classe B ; etc.) la pratique invitent à établir DES référentiels selon les
besoins commerciaux.
SP1.5 Establish Process Performance SP1.5 Établir les modèles de performance

Models des processus
Establish and maintain process performance Établir et maintenir les modèles de performance
models for the organization’s set of standard des processus pour l’ensemble des processus
processes. standards de l’organisation.
En plus de fournir au chef de projet les données dont on a fait mention précédem-
ment dans le domaine de processus OPP, ce domaine demande à la fonction affectée
à l’analyse des performances organisationnelles de guider les estimations à venir des
projets par des modèles d’estimation.
9.1.2 Gestion de projet quantitative
Gestion de projet quantitative – un domaine de processus de la catégorie Gestion

de projet dans la représentation continue.
Ce domaine de processus se retrouve dans les 3 constellations (DEV, SVC et ACQ) du
CMMI ; il fait partie du tronc commun du CMMI. Cependant, dans la constellation SVC,
il porte le nom de Gestion de travail quantitative (« Quantitative Work Management »
- QWM) puisqu’au lieu de projet à date de fin établie, on traite des activités de services
en continu. Partout le mot « projet » est remplacé par « work » dans SVC.
QPM Quantitative Project Management Gestion de projet quantitative
The purpose of the Quantitative L’intention de Gestion de projet quantitative

Project Management (QPM) process area is to (QPM) est de gérer quantitativement le projet en
quantitatively manage the project to achieve the vue de satisfaire les objectifs de qualité et de
project’s established quality and process performance du processus établis pour le projet.
performance objectives.
QPM applique au niveau du projet les données et les modèles qui résultent du
domaine du processus OPP. Si OPP interpelle un groupe organisationnel, QPM
interpelle naturellement le chef de chaque projet.
Gérer le projet quantitativement
SG1 Prepare for Quantitative Management SG1 Se préparer à la gestion quantitative
Preparation for quantitative management is La préparation pour la gestion quantitative est

conducted. menée.
Le chef de projet ou d’activité a la responsabilité au niveau 4 de se préparer à gérer

quantitativement, par exemple en fixant ses propres objectifs en tenant compte bien
sûr des informations fournies par le groupe organisationnel.
SP1.1 Establish the Project’s Objectives SP1.1 Établir les objectifs du projet
Establish and maintain the project’s quality and Établir et maintenir les objectifs de qualité et de
process-performance objectives. performance du processus du projet.
Cette pratique se résume souvent, à moins que le projet soit très différent de ceux
dont les données sont contenues dans la base de données historiques, à répliquer les
objectifs fixés au niveau organisationnel (OPP-SP1.3). Dans tous les cas, ces objectifs
organisationnels servent au moins de point de départ ; dans bien des cas, ils sont aussi
ceux sur lesquels le projet s’aligne.
SP1.2 Compose the Defined Process SP1.2 Composer le processus ajusté
Using statistical and other quantitative techniques, En utilisant des techniques statistiques et d’autres
compose a project’s defined process that enables techniques quantitatives, composer le processus
the project to achieve its quality and capability ajusté du projet en vue de satisfaire les objectifs de
dataprocess performance objectives. qualité et de performance du processus du projet.
Le chef de projet dérive son processus ajusté à partir de l’ensemble des processus
standards de l’organisation. Ceci est un comportement de niveau 3. Au niveau 4, il
ajoutera à la préparation de son processus ajusté la dimension de gestion quantitative,
ce qui mettra l’accent sur un certain nombre de sous-processus.
Un des principes du domaine de processus QPM est de bien choisir les cibles sur
lesquelles il est pertinent de l’appliquer. Par ailleurs, un des principes important du
niveau 3 est de réfléchir au besoin d’ajustement du processus standardisé et de justifier
les variations désirables par les aspects particuliers du projet. Lorsqu’on combine ces
deux principes, on se trouve en plein dans la pratique QPM-SP1.2 ; on sait qu’on
ne pourra établir une gestion quantitative sur tout donc on doit choisir sa (ses)
cibles ; mais si notre processus projet est fortement ajusté, il faut analyser l’impact
sur la possibilité de déployer peu ou prou la gestion quantitative. À ce jour, ayant
surtout visité des organisations qui appliquaient OPP et QPM sur des activités assez
normalisées (par exemple, relecture de spécifications ou inspection de code) n’ayant
pas eu à être fortement ajustées, la pratique ici n’entraînait que peu de difficultés
d’interprétation dans de telles organisations.
SP1.3 Select Subprocesses SP1.3 Sélectionner les sous-processus

and Attributes et les attributs
Select subprocesses and attributes critical to Sélectionner les sous-processus et les attributs
evaluating performance and that help to achieve essentiels à l’évaluation de la performance et à la
the project’s quality and process performance satisfaction des objectifs de qualité et de
objectives. performance du processus du projet.
Il n’est pas réaliste de vouloir mettre sous gestion statistique (ce qui sera traité sous
l’objectif spécifique SG2) l’ensemble des sous-processus. Certains ont un comporte-
ment que l’on peut difficilement stabiliser ou prévoir.
SP1.4 Select Measures and Analytic SP1.4 Sélectionner les mesures

Techniques et les techniques d’analyse
Select measures and analytic techniques to be Sélectionner les mesures et les techniques
used in quantitative management. d’analyse à utiliser pour la gestion quantitative.
La gestion quantitative passe absolument par une identification précise des mesures
et des techniques d’analyse. Comme on l’a souligné en OPP – Performance du processus
organisationnel, si on a fait un bon travail en MA – Mesure et analyse, on aura déjà un
catalogue de mesures bien documentées dans lequel puiser.
Gérer quantitativement la performance de sous-processus

Les pratiques sous SG1 préparent une approche de gestion quantitative. Celles que
nous verrons sous SG2, poussent le défi plus loin en activant cette approche de gestion
quantitative qui repose sur une stabilisation progressive de certains processus.
SG2 Quantitatively Manage the Project SG2 Gérer le projet quantitativement
The project is quantitatively managed. Le projet est géré quantitativement.
SP2.1 Monitor the Performance SP2.1 Surveiller la performance

of Selected Subprocesses des sous-processus sélectionnés
Monitor the performance of selected Surveiller la performance des sous-processus

subprocesses to using statistical and other sélectionnés en utilisant des techniques
quantitative techniques. statistiques et d’autres techniques quantitatives.
Le chef de projet surveillera les aiguilles des cadrans sur son tableau de contrôle et
déclenchera des actions correctives dès qu’une cause spéciale de variation entraînera
la performance du projet dans une zone extérieure aux balises établies Cette pratique
décrit donc la réaction attendue d’un chef de projet qui constate que la performance
des sous-processus qu’il a choisi de mettre sous contrôle statistique s’éloigne des bornes
permises. Il doit analyser ce qui a pu causer ces écarts de conduite afin de ramener son
processus dans l’étroit chemin entre la borne inférieure et la borne supérieure de la
fourchette de performance établie. Cette pratique cause en général peu de problème
d’interprétation. Cependant, elle est parfois difficile à être examinée in situ lorsque la
fourchette de performance est trop large (i.e. l’organisation a été peu analytique et a
fixé des paramètres trop permissifs) ; ça prend alors beaucoup de temps avant qu’une
situation d’activation d’une réaction quelconque de la pratique se manifeste.
SP2.2 Manage Project Performance SP2.2 Gérer la performance du projet
Manage the project using statistical and other Gérer le projet en utilisant des techniques
quantitative techniques to determine whether or statistiques et d’autres techniques quantitatives
not the project’s objectives for quality and process pour déterminer si les objectifs de qualité du
performance will be satisfied. projet et de performance du processus seront
satisfaits ou non.
Constatons ici la progression depuis le niveau de maturité 2. À ce niveau, on se

contentait de surveiller le projet et de réagir uniquement lorsque les performances
réelles déviaient des performances attendues. Au niveau 3, on a raffiné sa technique
de réaction en tenant compte de seuils dérivés de la connaissance des projets passés.
Au niveau 4 maintenant, non seulement surveille-t-on l’écart du projet par rapport à
des seuils, mais aussi l’écart du projet par rapport aux objectifs quantitatifs de qualité
et de performance de processus que l’on s’est fixés.
SP2.3 Perform Root Cause Analysis SP2.3 Réaliser une analyse causale
Perform root cause analysis of selected issues to Réaliser une analyse causale de résultats
address deficiencies in achieving the project’s sélectionnés pour traiter les lacunes qui nuisent à
quality and process performance objectives. la satisfaction des objectifs de qualité et de
performance.
Une organisation apprenante qui veut continuer d’apprendre doit absolument

mener des analyses des causes à l’origine des problèmes ou situations particulières
rencontres afin d’éviter leur récurrence future.
Avez-vous bien LU ?
a) Pourquoi les mots « géré quantitativement » caractérisent-ils bien le niveau 4 dans

le CMMI ?
b) Quelle(s) pratique(s) spécifique(s) traitent des bonnes pratiques suivantes... :

1) Il faut choisir dans un projet quels processus ou parties de processus on souhaite
stabiliser ou mettre sous contrôle statistique.
2) Des objectifs de performance doivent être établis pour l’organisation à partir de
l’examen des statistiques des projets passés.

a) Imaginez que vous êtes un chef de projet. Faites un plaidoyer (avec argumentaire)
b) Pour chacun des domaines des processus du niveau 4, développez et expliquez au

pour un développeur ; pour un chef de projet ; pour un membre de la Direction.
c) Pour chaque pratique spécifique suivante, donnez au moins un exemple de

1) QPM-SP1.2 ;
2) OPP-SP1.2.
10
Le niveau 5
D’une approche quantitative des projets et de processus

à l’optimisation continue : toujours s’améliorer et prévenir
Dans une organisation de niveau 4, les projets réussissent à stabiliser par gestion
quantitative un certain nombre de processus déterminés. Les chefs de projet sont
heureux d’atteindre les objectifs fixés et on pourrait être tenté de s’asseoir sur ses
lauriers : mission accomplie !
Mais l’organisation ne vit pas en vase clos. Elle est soumise à la compétition. Un
jour ou l’autre les objectifs audacieux qu’elle s’est fixée au niveau 4 et qui comblent
d’aise ses clients actuels vont présenter un tout autre visage. Tels les vêtements qui
nous éblouissent et qui nous semblent si bizarres ou laids quand on les revoit sur
de vieilles photos, les objectifs d’aujourd’hui seront trop timides puis dérisoires dans
quelques mois ou quelques années. C’est souvent la compétition qui nous pousse à
vouloir constamment aller de l’avant. A-t-on jamais vu un athlète olympique vouloir
poursuivre sa carrière mais ne pas vouloir se dépasser ?
Une organisation de niveau 5 sait qu’elle peut faire toujours mieux ! En effet, une
fois les processus stabilisés, elle peut enfin voir très clair dans les facteurs qui agissent
sur la performance de ses processus et observer les causes communes de variations.
Comment se fait-il que tout en restant entre les balises des objectifs fixés, on réussisse
mieux dans certaines conditions que dans d’autres ? Des analyses causales sont menées
et on isole les problèmes qui tirent les performances vers le bas et on les élimine un
à un, jusqu’à re-stabiliser le processus à l’intérieur de balises encore plus ambitieuses
qu’avant.
Cette roue ne s’arrête jamais. Si on atteint un point de performance incompressible,
on se tournera vers d’autres processus. On aura plusieurs années, décennies, centenaires
avant d’avoir épuisé les occasions d’amélioration... On se trouve prisonnier dans des
cercles non pas vicieux mais vertueux, des boucles d’amélioration continue telles que
décrites par Deming.
Il n’y a pas d’objectif générique GG5 ni de pratiques génériques GP5.n

dans le CMMI
On a déjà dit que dans sa représentation étagée, le CMMI ne propose pas de
nouvelles pratiques institutionnalisées au-delà du niveau 3. Donc, en plus des pratiques
spécifiques de niveau 5, les domaines de processus n’auront qu’à appliquer les objectifs
et pratiques génériques des niveaux 2 et 3.
Rappelons que l’on vise un comportement d’optimisation continue sur un certain
nombre de processus au niveau 5 mais pas de tous. Il a semblé aux auteurs du CMMI
que ce serait tout à fait utopique de forcer l’optimisation sur tous les domaines de
processus. Conséquemment, on ne peut institutionnaliser un comportement de niveau
5 sur l’ensemble des domaines de processus et donc on ne retrouve pas d’autres buts
génériques que de discipliner, capitaliser et personnaliser, hérités des niveaux 2 et 3.
Par ailleurs, si on lit bien le contenu des domaines de processus OID – Innovation
et déploiement organisationnels et CAR – Analyse causale et résolution qui sont les
deux domaines de processus du niveau 5 en représentation étagée, on constate qu’ils
induisent un comportement organisationnel qui traduit très bien la vision d’optimisation
continue propre au niveau 5.
En ce qui concerne la représentation continue, les auteurs du CMMI préconisent
le recours à OPM et CAR pour ajouter une vision d’« optimisation continue » aux
processus que l’on aura sélectionnés.

Tout comme je le faisais pour les pratiques des niveaux précédents, je rappelle que je
n’ai pas la prétention de proposer une traduction officielle de tout le modèle CMMI.
Je répète que je propose plutôt une traduction ciblée des pratiques et des objectifs de
10.1.1 Analyse causale et résolution
Analyse causale et résolution – un domaine de processus de la catégorie Support

CAR Causal Analysis andResolution Analyse causale et résolution
The purpose of Causal Analysis and Resolution L’intention d’Analyse causale et résolution (CAR)
(CAR) is to identify causes of selected outcomes est d’identifier les causes de résultats sélectionnés
and take action to improve process performance. et de faire en sorte d’améliorer la performance
du processus.
Ce domaine de processus au niveau 5 peut s’appliquer à toutes sortes d’activités

et de produits couverts par l’un ou l’autre des autres domaines de processus à tous
les niveaux. C’est en quelque sorte un utilitaire comme l’étaient DAR, CM, PPQA,
etc. CAR fait écho au domaine de Prévention des défauts que l’on retrouvait dans le
SW-CMM il y a longtemps. Cependant, avec la version 1.3 du CMMI, les auteurs ont
élargi le spectre d’application de CAR en parlant non pas seulement de défauts ou
de problèmes comme occasion de mener une analyse causale mais de toute situation
(« outcomes ») qui mérite qu’on mène une telle analyse. Par exemple, si une certaine
façon de faire donne des résultats extraordinaires, il vaut la peine de trouver la source
de cet exploit non pas pour l’éviter bien sûr mais au contraire pour la répéter.
Déterminer les causes de résultats qui nous intéressent
SG1 Determine Causes of Selected SG1 Déterminer les causes des résultats
Outcomes sélectionnés
Root causes of selected outcomes are Les causes à l’origine des résultats sélectionnés
systematically determined. sont systématiquement déterminées.
On cherche non plus seulement à corriger les défauts ou situations problématiques

mais à remonter à la source, à la cause des défauts dont la suppression entraînera
une diminution ou une disparition des défauts en question. Comme mentionné en
introduction de ce domaine, on utilise la même approche pour répéter les exploits.
Il faut une certaine compréhension des statistiques pour sélectionner les défauts
ou problèmes ou situations particulières dont le comportement se prête bien à une
séance d’analyse causale.
SP1.1 Select Outcomes for Analysis SP1.1 Choisir les résultats

pour analyse
Select outcomes for analysis. Choisir les résultats pour analyse.
SP1.2 Analyze Causes SP1.2 Analyser les causes
Perform causal analysis of selected outcomes and Réaliser une analyse causale des résultats
propose actions to address them. sélectionnés et proposer des actions pour les
traiter.
Les habitués des analyses causales connaissent l’utilisation que l’on fait des
diagrammes en arêtes de poisson (Ishikawa) qui permettent de remonter aux causes
des défauts. L’analyse causale consiste à utiliser les connaissances de spécialistes d’un
domaine pour déterminer, ensemble, comment il se fait qu’une erreur survient de
façon récurrente ou, qu’au contraire, un exploit survient de façon récurrente ; une
fois qu’on a compris la cause originelle (le facteur qui engendre l’erreur ou l’exploit),
on leur demande de nous proposer une action PRÉVENTIVE qui, en éliminant la
cause, va éliminer la conséquence (et donc l’erreur) ou une action PROACTIVE qui
va favoriser la répétition de l’exploit.
Traiter les causes des défauts
SG2 Address Causes of Selected Outcomes SG2 Traiter les causes des résultats
sélectionnés
Root causes of selected outcomes are Les causes à l’origine des résultats sélectionnés
systematically addressed. sont systématiquement traitées.
On reconnaîtra un comportement de niveau 5 dans un projet par la quasi-obsession

de toujours analyser les défauts ou autres situations intéressantes problématiques et de
suivre la solution à ceux-ci en mode préventif ou préventif. L’organisation de niveau
5 a complètement basculé du mode réactionnel au mode proactif.
SP2.1 Implement Action Proposals SP2.1 Mettre en œuvre

les propositions d’actions
Implement selected action proposals developed Mettre en œuvre les propositions d’actions
in causal analysis. sélectionnées qui ont été développées lors des
analyses causales.
Notons au passage que l’autre domaine de processus du niveau de maturité 5, OID

– Innovation et déploiement organisationnels, va récupérer le résultat de cette activité
SP2.1 pour en faire un projet d’amélioration.
SP2.2 Evaluate the Effect of Implemented SP2.2 Évaluer les retombées des actions
Actions mises en œuvre
Evaluate the effect of implemented actions Évaluer les retombées des actions mises en œuvre
on process performance. sur la performance des processus.
Rappelons-nous qu’au niveau 4, le domaine de processus QPM permettait de

proposer au projet une vision quantitative précise des performances attendues. Les
bouleversements apportés par les projets d’amélioration résultant des analyses causales
auront du moins, on l’espère, un impact mesurable sur les performances attendues.
SP2.3 Record Data SP2.3 Enregistrer les données
Record causal analysis and resolution data for use Enregistrer les données d’analyse causale et
across projects and the organization. résolution pour les utiliser dans les projets et à
travers l’organisation.
L’information sur les retombées positives des projets d’amélioration doit circuler
librement pour permettre à tous d’en tirer de meilleurs profits possibles.
10.1.2 Gestion de la performance organisationnelle
Gestion de la performance organisationnelle – un domaine de processus de la

OPM Organizational Performance Gestion de la performance organisationnelle

Management
The purpose of Organizational Performance L’intention de Innovation et déploiement

Management (OPM) is to proactively manage organisationnels (OPM) est de gérer de manière
the organization’s performance to meet its proactive la performance de l’organisation afin
business objectives. d’atteindre ses objectifs stratégiques.
Une organisation de niveau 5 doit être en mesure de profiter des changements par
petits pas (approche incrémentielle ou « Kaizen ») tout autant que des changements
plus radicaux (« breakthrough »). Ces changements pourront affecter tout autant ses
processus que les technologies utilisées. Mais contrairement à une organisation de
niveau 1, dépouvue d’une bonne compréhension de ses modes de fonctionnement et
de ses vrais problèmes et qui succombe aisément aux charmes de sirènes habiles leur
vantant les mérites de tel ou tel outil ou succombant aux effets de mode (nouvelles
techniques, nouvelles méthodes), une organisation de niveau 5 est particulièrement
bien préparée pour choisir les améliorations à déployer. Une organisation très mature
s’appuie sur une compréhension fine, basée sur des analyses statitistiques, de son
fonctionnement et de ses disfonctionnements. Elle se donne des objectifs d’entreprise
qui gouverne les choix d’amélioration qu’elle fera. Elle s’assure que ses choix donnent
les résultats attendus, toujours en s’appuyant sur des faits, sur des données quantitatives
incontestables. Des vendeurs de camelote qui frappe à la porte de telles organisations
n’en franchissent jamais le seuil. L’organisation navigue sur la mer des nouveautés
avec intérêt mais toujours mené par la raison et non par la passion ; elle cherche des
solutions à des problèmes bien cernés et n’y accoste que lorsqu’elle est certaine que ces
solutions ont la capacité de les résoudre. Elle n’en repart qu’une fois convaincue,
chiffres à l’appui, que la solution a eu l’effet escompté. Elle reprend la route de
l’optimisation continue avec l’assurance que lui donnent ses statitiques fiables.
Certes, dès le niveau 3, on retrouve dans OPF la nécessité de déployer des
améliorations au niveau des processus et des outils qui les soutiennent. Mais au niveau
3, on ne s’attend pas à ce que ces changements soient le résultat d’analyse statitsique
ni qu’ils soient assujettis à des objectifs quantitatifs ; ceci se trouve cependant bien
clairement au niveau 5.
Choisir les améliorations
SG1 Manage Business Performance SG1 Gérer la performance d’entreprise
The organization’s business performance is La performance d’entreprisea de l’organisation est

managed using statistical and other quantitative gérée en utilisant des techniques statistiques et
techniques to understand process-performance d’autres techniques quantitatives afin de
shortfalls and identify areas for process comprendre les insuffisances de performance des
improvement. processus et d’identifier des zones d’amélioration
de processus.
a. Le terme entreprise ici appliqué à « objectifs » correspond à l’expression « business goals » en anglais. Nous avons
été tenté de traduire par « objectifs d’affaires » ou « objectifs commerciaux » mais ceci collait mal lorsqu’on parlait
d’organisations de type gouvernemental ou sans buts lucratifs. Ou encore par « objectifs statégiques » mais plus
loin les auteurs du CMMI évoque des « business strategies » ce qui nous aurait mené vers une expresssion absurbe
de « stratégies stratégiques ». Finalement, l’expression « d’entreprise » évite la connotation trop exclusivement
commerciale qu’aurait eu l’expression « objectifs d’affaires » et signifie bien quelque chose qui se situe à haut niveau
dans la vision de l’organisation.
Comme on le soulignait en entrée de chapitre, une organisation qui applique bien

OPM va inévitablement aligner sa stratégie d’amélioration sur une cible claire (des
objectifs d’entreprise) et une compréhension fine, basée sur des données statitisques
irréfutables, de son fonctionnement et des zones d’amélioration possibles.
SP1.1 Maintain Business Objectives SP1.1 Maintenir des objectifs d’entreprise
Maintain business objectives based on an Maintenir des objectifs d’entreprise basés sur une
understanding of business strategies and actual compréhension des stratégies d’entreprise et des
performance results. résultats actuels de performance.
Au niveau 5, on ne s’engage dans aucune initiative d’améliorations sans avoir

une idée très claire des objectifs d’entreprise que l’on vise. Ceux-ci peuvent être fixés
périodiquement (par exemple, dans le cadre de plan annuel stratégique) ou de façon

opportune à l’occasion de situations particulières. Ils portent tout autant sur la qualité
des livrables que sur la performance des processus utilisés pour produire ces livrables.
SP1.2 Analyze Process Performance Data SP1.2 Analyser les données de performance
des processus
Analyze process performance data to determine Analyser les données de performance des
the organization’s ability to meet identified processus pour déterminer la capacité de
business objectives. l’organisation de satisfaire les objectifs
d’entreprise identifiés.
Si on se rappelle bien OPP (Performance du processus organisationnel) au niveau 4,

on a sous la main des données fiables sur les processus utilisés au sein de l’organisation.
On a cumulé suffisamment de points de données pour isoler les phénomènes qui
méritent notre attention, par exemple des sous-performances chroniques ou au
contraire des agencements de processus qui ont donné des performances ou une qualité
exceptionnelles.
SP1.3 Identify Potential Areas for SP1.3 Identifier des zones possibles
Improvement d’amélioration
Identify potential areas for improvement that Identifier des zones possibles d’amélioration qui
could contribute tomeeting business objectives. pourraient contribuer à la satisfaction des objectifs
d’entreprise.
L’analyse décrite en SP1.2 permet de bien cibler les endroits pertinents pour
appliquer des améliorations. Et rappelons encore que ceci n’est aucunement intuitif
puisque ces décisions s’appuient sur des techniques statistiques et d’autres techniques
quantitatives.
Choisir les améliorations
SG2 Select Improvements SG2 Sélectionner les améliorations
Improvements are proactively identified, Les améliorations sont identifiées de façon

evaluated using statistical and other quantitative proactive, évaluées en utilisant des techniques
techniques, and selected for deployment based statistiques et d’autres techniques quantitatives et
on their contribution to meeting quality sélectionnées pour déploiement sur la base de
and processperformance objectives. leur contribution à l’atteinte des objectifs de
qualité et de performance de processus.
Avant de déployer tous azimuts, une organisation de niveau 5 s’avance prudem-

ment en validant les résultats des améliorations sur une échelle réduite.
On raffine sa bonne compréhension des améliorations suggérées en distinguant par
exemple celles qui représentent des changements drastiques (« beraktrough ») de celles
qui constituent plutôt des petits pas d’amélioration continue (« kaizen »).
SP2.1 Elicit SP2.1 Obtenir et expliciter

Suggested Improvements les améliorations suggérées
Elicit and categorize suggested improvements. Obtenir, expliciter et identifier les améliorations
suggérées.
SP2.2 Analyze Suggested Improvements SP2.2 Analyser les améliorations suggérées
Analyze suggested improvements for their Analyser les améliorations suggérées quant à leur
possible impact on achieving the organization’s impact possible sur la satisfaction des objectifs
quality and process performance objectives. organisationnels de qualité et de performance
des processus.
Toutes les suggestions d’amélioration ne doivent pas nécessairement être retenues.

Cette pratique demande de choisir les plus intéressantes pour l’organisation.
Le défi de cette pratique est de la « lire au bon niveau ». Dans son libellé, elle
semble relativement simple et « innocente ». Quand on tentera de faire de l’OPM dans
une organisation qui débute l’amélioration continue, on fera (même en étant niveau 2
ou 3) la pratique SP1.2 de façon passablement intuitive et sa formulation « innocente »
sera bienvenue. Mais quand on tentera d’atteindre un niveau de maturité 5, il y aura
des exigences d’anticipation mathématique qui se trouvent bien exprimées dans les
sous-pratiques. On ne profitera pleinement des avantages de la pratique SP1.2 que
lorsqu’on disposera des munitions (statistiques) pour faire une analyse sérieuse et
quantitative des potentiels d’amélioration.
SP2.3 Validate Improvements SP2.3 Valider les améliorations
Validate selected improvements. Valider les améliorations sélectionnées.
La prudence inspire la pratique SP1.3 puisque même si les suggestions d’améliora-

tions ont été intéressantes sur papier, rien ne vaut un projet pilote, des prototypes, ou
toute autre technique de validation pour donner des informations réalistes du terrain.
SP2.4 Select and Implement Improvements SP2.4 Sélectionner et mettre en œuvre

for Deployment les améliorations pour déploiement
Select and implement improvements for Sélectionner et mettre en œuvre les améliorations
deployment throughout the organization based pour déploiement au travers l’organisation en se
on an evaluation of costs, benefits, and other basant sur une évaluation des coûts, des
factors. bénéfices et d’autres facteurs.
Évidemment, les résultats des validations constitueront la source première pour

prendre ces décisions. Certes, quand on sera au niveau 5, on disposera d’une base
statistique solide suite aux validations pour décider ou non de déployer une innovation
urbi et orbi. Entre-temps, on prendra ses décisions de façon plus intuitive quand on
appliquera OPM dans une organisation de niveau de maturité 3 ou moins par exemple.
Déployer les améliorations
SG3 Deploy Improvements SG3 Déployer les améliorations
Measurable improvements to the organization’s Des améliorations mesurables aux processus et

processes and technologies are deployed and technologies de l’organisation sont déployées et
evaluated using statistical and other quantitative évaluées en utilisant des techniques statistiques et
techniques. d’autres techniques quantitatives.
Cet objectif spécifique résume presque à lui seul tout l’esprit du CMMI : l’amélio-
ration continue.
SP3.1 Plan the Deployment SP3.1 Planifier le déploiement
Establish and maintain plans for deploying Établir et maintenir les plans pour déployer les
selected improvements. améliorations sélectionnées.
Faut-il s’étonner que le CMMI recommande de préparer un plan de projet ? Que le

projet soit destiné à livrer un produit au client ou à améliorer l’environnement interne
de développement, on ne peut se permettre d’appliquer deux poids et deux mesures.
Tout projet mérite d’être géré à l’aide du CMMI.
SP3.2 Manage the Deployment SP3.2 Gérer le déploiement
Manage the deployment of selected Gérer le déploiement des améliorations

improvements. sélectionnées.
Pour faire suite à notre commentaire précédent, il s’agit ici d’appliquer en quelque
sorte PMC aux projets particuliers d’amélioration de processus et de technologies.
SP3.3 Evaluate Improvement Effects SP3.3 Évaluer les effets de l’amélioration
Evaluate the effects of the deployed Évaluer les effets des améliorations déployées sur
improvements on quality and process la qualité et sur la qualité et sur la performance
performance using statistical and other des processus en utilisant des techniques
quantitative techniques. statistiques et d’autres techniques quantitatives.
Toujours la même prudence ! Malgré que les validations aient été concluantes, le
CMMI recommande de maintenir une veille sur les retombées des améliorations afin
de s’assurer que l’évolution globale du contexte de l’organisation fasse en sorte que le
terrain ne soit plus favorable aux améliorations en question.
Avez-vous bien LU ?
a) Pourquoi les mots « en optimisation » caractérisent-ils bien le niveau 5 dans le

CMMI ?
b) Quelle(s) pratique(s) spécifique(s) traitent des bonnes pratiques suivantes... :

1) Il faut faire des projets pilotes ou l’équivalent pour valider des améliorations avant
de les déployer dans toute l’organisation.
2) On ne peut pas faire de l’analyse causale sur tous les problèmes : il faut choisir.

a) Pourquoi n’y a-t-il pas de pratiques génériques de niveau 5?
b) Imaginez que vous êtes un chef de projet. Faites un plaidoyer (avec argumentaire)

pour un développeur ; pour un chef de projet ; pour un membre de la Direction.
d) Pour chaque pratique spécifique suivante, donnez au moins un exemple de

1) CAR-SP1.2.
2) OPM-SP2.3.
11
Un cas concret
Certains des stagiaires qui assistent à mes cours en France s’amusent à composer
une espèce de florilège de mes expressions québécoises qui leur semblent amusantes,
bizarres ou simplement différentes. Il en est une que j’utilise assez souvent et qui les
fait sourire mais je crois qu’elle est plutôt de mon cru et qu’elle n’a pas nécessairement
cours chez beaucoup de Québécois. Je dis souvent « Dans la vraie vie » pour signifier
« En réalité » mais en insistant sur le contraste qu’il y a parfois entre la théorie et la
pratique, celle-ci étant bien sûr, désignée par « la vraie vie ».
Je vais donc vous parler ici de la vraie vie d’une organisation qui réalise qu’elle a
besoin d’utiliser le CMMI et de mener une évaluation de type SCAMPI. Je rappelle
que le SCAMPI n’est pas, dans ce contexte, un crustacé mais bien la méthode
d’évaluation officielle publiée par le SEI qui s’appuie sur le CMMI pour identifier
les forces et faiblesses des processus en usage dans une organisation.
Mon histoire sera le fruit de l’amalgame de plusieurs histoires vécues et ne
permettra pas, je l’espère, d’identifier les sources. Certes, il aurait peut-être fallu mille
exemples pour refléter toutes les variantes que l’on trouve « dans la vraie vie ». Mais
ceci aurait été à la fois trop complexe et trop long à réaliser. Je me contenterai donc
de décrire un cas assez typique en espérant que vous comprendrez que ce cas n’est pas
nécessairement représentatif de tous les cas possibles.
Imaginons la société COMPLEX qui fabrique des appareils coûteux et complexes
qu’ils vendent à des industriels ; ceux-ci intègrent ensuite ces appareils dans leurs
propres produits qu’ils vendent, une fois assemblés en systèmes de contrôle commande,
sur le marché international. Les appareils de la société COMPLEX sont principalement
composés de circuits électroniques contrôlés par logiciel ; le logiciel constitue donc un
élément critique de leur produit. La fiabilité des appareils COMPLEX repose en grande
partie sur le logiciel. La réputation de COMPLEX dépend de la qualité du logiciel et
de la capacité de COMPLEX de le faire évoluer rapidement. Comme les clients de
COMPLEX intègrent les appareils dans des systèmes parfois critiques (des vies peuvent
182 Chapitre 11. Un cas concret
en dépendre), ces clients sont de plus en plus préoccupés d’appliquer des standards
rigoureux pour toute la chaîne des composants dans les solutions qu’ils destinent à
leur propre clientèle. La Direction de COMPLEX se fait dire de plus en plus souvent
par leurs clients qu’elle devra bientôt pouvoir démontrer objectivement la robustesse
de son processus de développement du logiciel qui entre dans les appareils.
Un beau jour (c’est toujours « un beau jour » dans les livres...), COMPLEX délègue
une personne qui assiste à un cours CMMI. Depuis quelque temps, cette société
examine en effet différentes voies pour gagner de nouveaux marchés. Dernièrement,
lors d’une discussion informelle avec un collègue d’une autre société, un représentant
du marketing apprend que des demandes de propositions destinées à des sociétés
telles que COMPLEX mentionnent de plus en plus souvent une nouvelle exigence :
se conformer au modèle CMMI pour démontrer une capacité de développement au
niveau de maturité 3. Comme ce type de demandes de propositions leur est passé sous
le nez, la pression pour comprendre ce qu’il en est du CMMI se fait de plus en plus
pressante. Le département de marketing a fait pression sur celui de l’ingénierie et
voilà notre représentant qualité de COMPLEX qui se pointe sur un cours CMMI avec
curiosité et un peu de méfiance. Il a depuis belle lurette maîtrisé la norme ISO9001 et
se demande bien ce que le CMMI peut apporter de plus.
Heureux lecteurs : vous le savez, vous, ce que découvre l’ingénieur qualité de
COMPLEX. Plus le cours avance et plus il découvre que les meilleures pratiques
décrites dans le CMMI collent tout à fait à la réalité de COMPLEX. Il comprend
rapidement tout le profit que sa société peut en tirer. Il comprend aussi pourquoi
les clients de COMPLEX exigeront bientôt que COMPLEX démontre la robustesse
et la maturité de ses processus au regard du CMMI. Il revient donc à son bureau
avec enthousiasme, se préparant à rencontrer son patron pour lui proposer un plan
d’attaque.
Je reçois bientôt un appel téléphonique du patron en question qui me rappelle que
son ingénieur qualité a participé au cours CMMI et que son organisation désire se
faire certifier CMMI. Il demande combien de temps il faut pour obtenir le certificat.
Je lui explique d’abord que le concept de certification n’est pas très important avec le
CMMI. Après que je lui aie décrit les raisons du SEI pour ne pas émettre, du moins
dans les premières années du CMMI, de certifications aux organisations évaluées avec
le CMMI, il comprend qu’il aura beaucoup plus qu’un certificat. Il recevra un rapport
d’évaluation bien étoffé qu’il pourra présenter à ses clients le cas échéant et qui dira
précisément le niveau de maturité de son organisation au regard des pratiques cibles
décrites dans le CMMI. Le voilà satisfait et il est prêt à me rencontrer pour amorcer le
travail.
La première rencontre est l’occasion pour moi de bien expliquer ce qu’est le CMMI
et surtout comment on peut l’utiliser dans une organisation. Comme il est très clair que
les clients de COMPLEX exigent une confirmation CMMI objective de la maturité
de ses processus de développement de ses appareils, il devient pressant de réaliser une
évaluation officielle, qu’on appelle SCAMPI de classe A. De plus, étant donné que
COMPLEX applique depuis plusieurs années des démarches relatives à l’amélioration
de la qualité, il s’avère qu’ils ont sans doute, tel Monsieur Jourdain, fait du CMMI
Un cas concret 183
sans le savoir ! Autrement, on aurait pu procéder par petites touches successives et

aborder la démarche par le biais d’évaluations plus informelles qui permettent une
appropriation plus progressive des concepts du CMMI. Avant de passer au « grand
SCAMPI » de classe A, on aurait sans doute fait un « SCAMPI moyen » de classe
B, voire un « petit SCAMPI » de classe C pour faire un premier état des lieux et une
première boucle d’amélioration avant de déployer l’artillerie plus lourde du SCAMPI
de classe A qui seule permet une cotation officielle. En fait il devient de plus en plus
fréquent (je le recommande fortement à mes clients) de faire un SCAMPI de classe B
avant de faire un SCAMPI de classe A.
Mais le temps presse et le passage au SCAMPI de classe A semble constituer
la bonne approche pour COMPLEX. J’explique alors à mon interlocuteur que la
démarche de diagnostic n’est qu’une étape dans une série de boucles d’amélioration
continue. Il comprend tout à fait ; il a lu les livres de Deming et ces concepts non
seulement lui sont familiers mais lui plaisent beaucoup. Il ne croît pas aux changements
radicaux en une seule nuit et sait qu’il faudra s’engager sur le long terme à procéder
à des cycles d’amélioration de 18 à 30 mois. Mais ça ne l’inquiète pas outre mesure
car il sait aussi que COMPLEX y trouvera son compte dès le premier cycle. Une fois
l’inertie vaincue, les bénéfices convaincront rapidement les décideurs de poursuivre la
démarche et de ne pas arrêter la roue qui tourne. Je respire d’aise car j’ai souvent été
moins chanceux ; hélas, plusieurs pensent parfois trouver dans le CMMI une recette
miracle qui les rendra efficaces et gagnants en quelques jours ou semaines. Ils pensent
que s’ils mettent le gros prix, ils pourront s’acheter une certification qui impressionnera
ses clients. Comme ils déchantent quand ils comprennent combien ils se trompent !
Mais ne nous attardons pas dans cette impasse : COMPLEX ne mange pas de ce
pain. Nous avons donc un « bon » client pour le CMMI et pour SCAMPI. L’ingénieur
qualité qui a assisté à mon cours vient rejoindre son patron et nous poursuivons la
discussion à trois. Je me réjouis de la présence de cet ingénieur enthousiaste face à l’idée
de participer à « l’aventure CMMI » comme il l’appelle, lui qui, adepte de trekking
extrême, a grimpé plusieurs montagnes et donc sait l’effort et la détermination que cela
demande. Dans une démarche CMMI, on a toujours besoin d’un tel coordonnateur
dévoué et gagné à la cause de l’amélioration de processus.
J’ai un peu chaud quand il me faut expliquer à son patron qu’il n’est pas la meilleure
personne pour jouer le rôle de « sponsor » comme on désigne dans la méthode
SCAMPI le membre de la Direction qui préside au déroulement du SCAMPI au
nom de son organisation. Le patron avec qui je discute est le Directeur Qualité. Son
rôle est certes important mais il ne dirige pas les groupes d’ingénierie qui sont au
nombre de trois chez COMPLEX. Il y a un groupe d’ingénierie Matériel et un autre
d’ingénierie Logiciel ; un troisième se nomme Intégration. Je constate tout de suite
que le CMMI leur ira comme un gant car il aborde bien les disciplines qui sont
courantes chez COMPLEX. Mais j’explique que la Direction qui chapeaute tout le
périmètre visé par la démarche d’amélioration de processus est mieux placée pour agir
comme « sponsor ». Je ménage la susceptibilité du directeur Qualité qui heureusement
comprend vite que sans l’appui de la Haute Direction, tout le navire risque de chavirer
et que le soutien du plus haut niveau hiérarchique possible sera garant de la pérennité
de l’opération. Il accepte donc de bonne grâce de me fixer un rendez-vous avec le
Directeur général. Lorsque je lui explique qu’il peut, compte tenu de son implication
stratégique en matière de qualité, endosser le rôle de « co-sponsor » et ainsi participer
à toute la démarche de préparation du SCAMPI, il retrouve non seulement son sourire
mais aussi un élan qui le fait paraître dix ans de moins que son âge.
Une semaine plus tard, nous sommes quatre dans le bureau du Directeur général
pour cette rencontre critique pour le succès de toute « l’aventure CMMI » comme
l’appelle l’ingénieur qualité, dorénavant mon complice sur le terrain chez COMPLEX.
On s’entend sur le périmètre de l’évaluation. Ce ne sera pas toute la boîte qui sera
évaluée mais un sous-ensemble, néanmoins important, de COMPLEX. Une phrase
devra bien capter les limites de ce qui sera couvert et de ce qui ne le sera pas. Comme
il s’agit d’une première évaluation, les attentes du Directeur général sont réalistes ;
une fois informé des exigences du CMMI en version étagée, il déclare : « Je crois
que nous sommes sans doute au niveau de maturité 2 et même... Ce n’est pas tout à
fait certain. » Encore une fois, j’applaudis au réalisme de COMPLEX ; il m’est arrivé
parfois de rencontrer des chefs aux fols espoirs de voir leur boîte « certifiée » niveau 3
au début de l’année, niveau 4 avant les vacances d’été et au niveau 5 comme cadeau
de Noël corporatif ! COMPLEX a bien compris que les démarches d’amélioration
continue des processus de développement passent par des cycles de 18 à 30 mois dans
des organisations typiques. Comme ils ne croient pas aux miracles, ils se préparent à
des calendriers de travail réalistes.
À la fin de cette rencontre qui s’est, somme toute, très bien déroulée, je dispose
d’une commande claire : un périmètre précis et un niveau CMMI cible. Je leur ai
suggéré de regarder un peu plus que le niveau de maturité 2 car s’ils étaient confirmés
comme opérant au niveau de maturité 2 et qu’on s’était limité aux domaines de
processus du niveau de maturité 2, ils ne pourraient pas établir un plan pour le prochain
cycle d’amélioration en ne connaissant pas clairement leur manque au-delà du niveau
2. Il vaut toujours mieux jeter un regard, au moins partiel (un sous-ensemble des
domaines de processus du niveau de maturité cible + 1) vers la prochaine étape. J’ai
aussi clarifié ce dont j’aurais besoin pour mener l’évaluation SCAMPI et le « sponsor »
a donné son accord.
Au cours des deux semaines qui suivent, je communique assez souvent avec celui
que nous désignons maintenant comme le coordonnateur logistique (cet ingénieur
qualité qui a assisté au cours CMMI). Nous identifions qui seront les membres d’équipe
d’évaluation. Je recommande une équipe de sept personnes : le chef d’équipe (qui doit
être un chef certifié par le SEI) et 6 membres d’équipe. Parmi ceux-ci, j’aime bien
avoir une majorité de personnes (par exemple ici 5 sur les 6 autres personnes et la 6e
serait un collègue qui assistera le chef évaluateur certifié) du site à évaluer afin de faire
un transfert massif de technologies vers le site. Le SCAMPI de classe A ne vise pas
seulement à déterminer la cote de maturité d’une organisation ; on en profite pour
susciter ou raviver la flamme de l’amélioration continue au sein de l’organisation. Ceci
demande une participation active de personnes du site. Il importe donc d’en retrouver
un nombre significatif dans l’équipe d’évaluation même. En général, le chiffre magique
est donc de cinq personnes sur une équipe de sept. Le fait d’avoir une équipe de
sept personnes permettra de dégager un point de vue non biaisé sur les processus en
usage dans le site. Le fait d’avoir deux personnes externes apporte la dose d’objectivité
Un cas concret 185
requise et le fait d’avoir cinq personnes du site contribue à la pérennité de la démarche

d’amélioration après le SCAMPI par le biais de l’internalisation du savoir.
Nous programmons un cours destiné à l’équipe d’évaluation. Certes, les membres
de l’équipe doivent déjà avoir été formés au CMMI. On ne peut quand même pas
mener une évaluation avec le CMMI si on ne maîtrise pas le contenu du modèle
CMMI ! Le cours CMMI est fréquemment donné par des organisations autorisées (des
« partenaires ») par le SEI. On demande donc que les membres de l’équipe aient déjà
assisté à ce cours (comme l’a fait notre ingénieur qualité). Mais on organise ensuite
un cours destiné à l’équipe et portant sur la conduite du SCAMPI, c’est-à-dire sur la
méthode elle-même. Ce cours dure environ 2 jours et donne l’occasion à l’équipe de se
faire la main par le biais d’exercices pratiques et de jeux de rôles. À la fin du cours on
aborde la préparation de la collecte de données et le planning de la suite des activités.
En général, il s’écoule 4 à 8 semaines entre le cours d’équipe et l’évaluation sur site. Il
faut en effet quelques semaines pour terminer la collecte de données et les préparatifs.
Pour la collecte des données, on transmet au site une liste de PIIs (« Practice
Implementation Indicators » – voir en annexe) que l’on demande de renseigner. Il s’agit
d’une liste de preuves demandées. Concrètement, c’est une liste de documents que
l’on s’attend de trouver dans une organisation qui prétend déployer le CMMI de façon
rigoureuse dans ses projets et à travers son organisation. L’organisation sera invitée à
formuler avec sa propre terminologie la liste des documents recherchés. Alors, une
fois dressée cette liste de preuves recherchées, on demande au site de rassembler les
documents ou les pointeurs vers les documents qui permettront de vérifier hors de tout
doute que les processus visés sont bel et bien déployés en conformité avec l’esprit du
CMMI. Le site aura besoin de quelques semaines pour passer en revue cette liste et
rassembler les quelques centaines de preuves demandées.
Au regard du périmètre défini pour le site, on aura constitué un échantillon de
projets représentatifs et un échantillon de personnes représentatives. Ceci découle du
fait que nous ne pouvons quand même pas interroger tout le personnel et qu’il nous
faut choisir des représentants dans les différents métiers pour obtenir une bonne vue
en coupe des processus déployés dans les différents projets en cours dans l’organisation.
Par ailleurs, on choisira de 3 à 5 projets parmi les projets en cours ou récemment
terminés pour avoir une vue en profondeur du processus déployé dans quelques projets
types. En croisant les informations obtenues des chefs de projets sélectionnés et celles
obtenues des différentes personnes sélectionnées travaillant dans ces projets mais aussi
dans d’autres projets, on obtiendra une excellente vue du degré d’institutionnalisation
des processus examinés.
Quelques semaines s’écoulent alors que COMPLEX se prépare fébrilement à l’éva-
luation. Les preuves sont collectées et on renseigne le tableau de PIIs. Les entrevues
avec les chefs de projets et avec les personnes sélectionnées sont programmées. Il n’y
a plus qu’à se rendre en douceur au début de la période sur site en s’assurant de bien
coordonner la logistique restante (locaux à réserver, matériels requis par l’équipe, etc.).
L’évaluation sur site est en général échelonnée sur une à deux semaines, donc
5 à 10 jours ouvrables. Ce sera alors du travail à temps plein pour les membres de
l’équipe puisque toutes les activités de la période sur site se déroulent en équipe. Voici
venu le grand jour du début de la période sur site. Il y a de l’excitation dans l’air
chez COMPLEX. Un début de SCAMPI a quelque chose de solennel, comme une
grande première. Le sponsor (je dis « le » mais c’est parfois « la » : on a dépassé cette
époque où les femmes étaient exclues des postes de Direction, Dieu merci !) souhaite
la bienvenue, présente l’équipe et situe le SCAMPI dans le contexte de l’organisation.
Après un rappel de l’engagement fort de la Direction envers le cycle d’amélioration
de processus qui s’amorce et une explication de l’utilité de ce cycle pour contribuer
aux objectifs commerciaux de COMPLEX, le chef d’équipe SCAMPI explique à tous
le déroulement des festivités (ou des hostilités, c’est selon...). Sérieusement, il est
alors important pour le chef d’équipe d’expliquer à tous que l’équipe ne vient pas
auditer, en inquisiteur, le statut des processus mais vient plutôt, en facilitateur, aider
l’organisation à voir clair et à se donner les moyens de ses ambitions : devenir plus
rentable, productive, crédible. Le chef d’une équipe SCAMPI doit veiller à instaurer
un climat serein et de confiance entre les interviewés et les membres de l’équipe. Il
faut de la diplomatie et de la franchise.
Comme les interviewés vont parler de ce qui va et de ce qui ne va pas, il faut
les rassurer quant aux retombées qu’auront leurs « révélations ». On aura pris soin
de signer un accord qui ne laisse place à aucun doute. Tout le contenu spécifique
à un projet ou à une personne ne sera jamais révélé à qui que ce soit. Comme un
journaliste à l’éthique irréprochable, l’équipe ne révélera jamais ses sources, même si
on la soumet à la question. Comme on veut éviter d’en arriver là, cette « question »
aura été traitée bien avant, dans les discussions avec le sponsor. Voilà les gens rassurés :
on peut commencer les entrevues.
Mais juste avant de débuter les entrevues, on doit d’abord vérifier les documents
collectés par COMPLEX en tant que preuves à aligner avec les PIIs. L’équipe de
SCAMPI regarde chacun des documents proposés pour déterminer si effectivement il
répond à l’esprit des pratiques du CMMI. Dans la majorité des cas, l’équipe constate
que les documents sont conformes ; dans le cas contraire, des questions de suivi sont
notées. Même lorsque les documents collectés satisfont aux pratiques du CMMI,
des questions visant à corroborer les éléments d’information sont préparées pour les
entrevues à venir.
Les entrevues s’échelonnent sur quelques jours, à raison de 2 à 4 par jour. Chaque
séance dure de 1 à 2 heures. Toute l’équipe de SCAMPI se disperse autour d’une
grande table et accueille les interviewés, par petits groupes focalisant sur une activité
principale du développement (ex. : l’architecture, le design. la construction technique,
les essais, la gestion de projet, etc.). De même, les chefs des projets sélectionnés sont
rencontrés mais individuellement. L’équipe passe ainsi une douzaine d’entrevues avec
les gens de COMPLEX. Le chef d’équipe anime les rencontres et pose des questions
préparées par l’équipe au sujet des différentes pratiques du CMMI à examiner. Les
membres de l’équipe prennent des notes. Celles-ci seront détruites à la fin du SCAMPI
car on veut respecter l’engagement de confidentialité.
Après chaque rencontre, l’équipe retourne dans sa salle de travail et révise ses
notes pour en tirer des observations au regard de chacune des pratiques du modèle. À
la fin de chaque journée, ces observations sont soumises à la sagacité de l’ensemble
Un cas concret 187
de l’équipe qui se met d’accord sur toutes les formulations des forces et faiblesses
détectées et formulées par de petites phrases brèves mais bien alignées avec chacune
des pratiques du CMMI. Au fil des jours, un portrait se construit ainsi par petites
touches jusqu’à couvrir entièrement le sous-ensemble du CMMI qui est visé par le
SCAMPI. On est alors plus qu’à mi-parcours de la période sur site du SCAMPI.
Deux séances de validation générale sont ensuite organisées. On rassemble tous les
managers et les chefs de projet (qui sont déjà habitués à discuter avec le management)
qui ont été interviewés chez COMPLEX pour une séance de validation puis tous les
autres interviewés pour une seconde séance de validation. Le partage en deux grands
sous-groupes vise à assurer la libre circulation des idées et à éviter l’autocensure de
la part d’interviewés qui seraient gênés par la présence de leurs propres managers
(de ceux à qui ils rapportent). L’équipe SCAMPI profite alors de cette validation
générale pour s’assurer qu’elle a bien reflété les propos entendus en entrevues et les
documents examinés. Suite aux deux séances de validation, les ajustements pertinents
sont apportés aux constats et on appose les sceaux sur ceux-ci. Le diagnostic est
complété.
Il reste à faire la cotation. Chaque faiblesse détectée et formulée par un constat
est soumise au jugement de l’équipe : cette faiblesse affecte-t-elle significativement
l’objectif générique ou spécifique correspondant à cette pratique dans le CMMI ? Si
la réponse est « oui », alors l’objectif en question est déclaré non satisfait ; autrement
on poursuit jusqu’à ce qu’on ait jugé des impacts de toutes les faiblesses. À la fin, on
dégage aisément le degré de satisfaction des objectifs, des domaines de processus et des
niveaux de maturité organisationnelle. On rassemble l’ensemble de ces informations
sous forme de transparents que l’on présente en fin de période sur site au sponsor, en
présence de tous les interviewés de COMPLEX.
Le site, en l’occurrence l’ensemble des gens de COMPLEX, est généralement
peu surpris du résultat. Un site peu mature s’attend rarement à atteindre des cotes
de maturité élevées ; à l’inverse, un site mature « sent » assez bien le genre de
résultats qu’il est en droit d’attendre. Ce qui surprend c’est le portrait d’ensemble, bien
agencé, documenté, appuyé par une logique irréprochable et largement justifié par un
argumentaire étoffé. Ce qui surprend c’est le fait que pour une fois tous les gens de
COMPLEX réalisent collectivement leurs points forts et leurs points faibles en matière
de processus de développement et partagent un diagnostic qui fait généralement
l’unanimité. C’est un moment magique dont il faut savoir profiter dans les meilleurs
délais. Le « momentum » doit trouver son débouché dans la mise en œuvre rapide
d’un plan d’amélioration qui va entraîner COMPLEX dans des cercles vertueux (le
contraire des cercles vicieux) d’amélioration continue, jusqu’au prochain SCAMPI,
dans 18 à 30 mois.
Mais beaucoup de travail sera accompli entre-temps. COMPLEX fera un plan de
projet d’amélioration pour combler les lacunes détectées. Une équipe de choc mettra
en place les correctifs et s’assurera de former les gens aux nouveaux processus de travail.
Elle communiquera encore et encore jusqu’à ce que soient bien institutionnalisées
les nouvelles façons de faire. Au fil de l’eau, elle mesurera les bénéfices qui en
découlent afin de confondre les derniers sceptiques : l’amélioration de processus finit
par avoir tellement de retombées positives que seule la mauvaise foi empêche quelques
récalcitrants de se joindre au concert d’éloges unanimes : le CMMI change la vie

de l’organisation COMPLEX par petits pas et apporte des retours sur investissement
de l’ordre de 4 ou 5 euros par euro investi. Mais nous anticipons ici sur le prochain
chapitre.
12
Les bénéfices
Plusieurs entreprises et organismes ont documenté et présenté publiquement les

bénéfices qu’ils ont obtenus en investissant dans l’amélioration de leur processus.
À ce jour, peu de données fiables sont disponibles sur les retombées d’utilisation
des constellations ACQ (Acquisition) et SVC (Services), encore trop récentes.
Cependant, de nombreuses publications ou présentations publiques décrivent les
ROI (Return On Investment) d’utilisation de la constellation DEV. La plus célèbre
est une étude du Software Engineering Institute publiée en août 2006 qui donne
des statistiques fort convaincantes sur les retombées positives de l’amélioration de
processus. Mais à l’occasion de la quatrième édition de ce livre j’ai pu retrouver
quelques informations publiques plus récentes sur les retombées positives d’utilisation
du CMMI.
En mai 2010, le SEI a présenté les résultats (voir figures 12.1 à 12.5) issus
de plusieurs organisations du milieu de la Défense américaine (quelques unités
au sein de deux agences gouvernementales et d’autres unités au sein de
quatre fournisseurs majeurs) suite au déploiement du CMMI-DEV. On peut
retrouver la présentation complète sur la page suivante du site WEB du SEI :
http://www.sei.cmu.edu/library/abstracts/presentations/CMMI-Benefits-to-Defense-
Industry.cfm.
190 Chapitre 12. Les bénéfices
Figure 12.1 — L’organisation 2a a réussi à augmenter une performance déjà enviable dans ses
projets ; la quasi-totalité de ses projets respectent maintenant l’échéance annoncée. L’organisation
1 a réduit de 6,35 fois le temps consacré à la détection et la réparation des défauts après le début
des tests. L’organisation 7 a amélioré ses estimations et le repect de ses échéances de plus de 19 %.
Figure 12.2 — L’organisation 1 a diminué de 58 % les heures consacrées à la réparation des

défauts. L’organisation 5 a réduit de 22 % les coûts de détection et réparation des défauts.
L’organisation 4 a réduit de 24 % en moyenne les heures consacrées à chaque défaut. De plus, un
index des coûts évaluant le degré de temps consacré à ajouter de la valeur s’est amélioré de 10 %.
L’organisation 6 a réduit ses frais généraux de 7,3 % et le coût global des projets a diminué de
28 % en passant du niveau de maturité 3 à 5.
Les bénéfices 191
Figure 12.3 — L’organisation 1 a diminué de 62,5 % le nombre de défauts qualifiés sévères en

passant du niveau de maturité 3 à 5. L’organisation 2a a réduit de 65 % les défauts de conception
de ses cartes de cicrcuits imprimés. L’organisation 3 a augmenté de 240 % le nombre de défauts
corrigés au cours de la phase même où ils furent injectés (on sait que tout défaut qui est détecté
dans une phase postérieure à celle où il fut injecté coûte beaucoup plus cher à corriger).
L’organisation 2b a amélioré de 13 % le taux de correction des défauts au cours de la même phase
où ils furent injectés. L’organisation .7 a ramené son taux de défauts à 0,15 par millier de lignes de
code et a amené à plus de 85 % le pourcentage de défauts découverts avant les tests de système.
Figure 12.4 — L’organisation 1 a augmenté de 42 % sa productivité sur une période de 9 ans

de pratiques de haut niveau de maturité ; de plus en utilisant un référentiel reconnu, elle a réduit
les heures requises pour sa production de 33 % au niveau de maturité 3 et de plus de 37 % au
niveau de maturité 5. L’organisation 6 a connu une hausse de productivité de plus de 25 % en
passant du niveau de maturité 3 à 5.
Figure 12.5 — Les contrats de défense sont souvent attribués avec des clauses de bonus / malus
en fonction de critères tels que respect des échéances, budget, niveau de qualité, etc.
L’organisation 6 a augmenté de 50 % son taux d’obtention des bonus. L’organisation 1 a fait
économiser à son client 25 % des coûts prévus.
À la conférence annuelle du SEI en Europe en 2008, le Crédit Suisse a présenté

des résultats éloquents (figure 12.6) comparant ses performances en 2005 à celles de
2007 (année de confirmation de son niveau de maturité 2 avec CMMI-DEV).
Figure 12.6 — Résultats du Crédit Suisse

En haut à gauche : la variation des coûts est passée de 38 % à 11 % (diminution de 71 %) ; celle
des délais de 30 % à 3 % (diminution de 91 %).En haut à droite : les corrections appliquées en
urgence en production sont passées de 12 % à 4 % (diminution de 63 %). En bas à gauche : la
densité des signalements de problèmes de toute sorte est passée de 10,5 % à 6 % (une
diminution de 49 %). En bas à droite : le coût unitaire d’un point de « Use Case » est passé d’un
peu plus de 6 % à un peu moins de 5 % (diminution de 22 %).
Les bénéfices 193
J’ai eu aussi l’occasion de suivre de près pendant une dizaine d’années une DSI
de l’entité responsable des prêts hypothécaires d’un grand groupe bancaire français.
Avec l’appui irréductible et continu de sa Direction, convaincue des avantages du
CMMI-DEV, cette DSI a démontré qu’avec l’atteinte d’un niveau de maturité 3, elle
avait réussi une diminution de son coût unitaire de développement de plus de 50 %
sur une période de 4 ans. La source principale de cette économie était la diminution
drastique du taux de défaut en cours de développement entraînant évidemment une
diminution majeure des coûts de correction (« rework »).
Dans une brochure publicitaire obtenue depuis son site WEB et intitulée « Achie-
ving delivery excellence using the Capability Maturity Model Integration By Keith M.
Heston », la société Accenture déclare avoir obtenu un retour sur investissement
de 5:1 en déployant le CMMI-DEV : « We used CMMI-DEV (...) and realized 5:1
return on investment (ROI). »
Accessible depuis le site web de la société GrafP de mon ami Louis Poulin
(http://www.grafp.com/Pdf/BMO_case-study_2006.pdf), une étude de cas de la DSI de
la Banque de Montréal fait état des bénéfices suivants suite à l’atteinte d’un niveau de
maturité 3 (traduction libre) :
• Une productivité. en maintenance corrective 3,8 fois meilleure que celle de
l’industrie du logiciel.
• Une productivité en maintenance évolutive 2 fois meilleure que celle de
l’industrie du logiciel.
• Un nombre de défauts livrés de 2 / livraison en moyenne, comparativement à 6
à 12 / livraison dans l’industrie.
• Une amélioration sensible de la productivité mesurée par les points de fonction,
excédant de beaucoup la productivité de l’industrie.
Et maintenant, revenons à l’étude du SEI de 2006 : voici quelques extraits

(Tableaux 12.1 à 12.5, traduction libre d’extraits de la section 3 du rapport « Per-
formance Results of CMMI-Based Process Improvement, Diane L. Gibson, Dennis R.
Goldenson, Keith Kost, CMU/SEI-2006-TR-004 ») disponible sur le site du SEI
(http://www.sei.cmu.edu/reports/06tr004.pdf). Un accès interactif aux données est
aussi disponible sur http://www.sei.cmu.edu/cmmi/research/results/index.cfm.
Tableau 12.1 — Impacts sur les coûts.
$2.1 millions d’économie en matériel dans une organisation satisfaisant le

Anonyme
niveau de maturité 3 du CMMI.
Diminution de 52 % des coûts lorsque l’organisation est passée du niveau

DB Systems GmbH
2 SW-CMM au niveau de maturité 3 du CMMI.
Un site du niveau de maturité 3 CMMI a réduit ses coûts de « rework » Raytheon Corp,
de 42 % sur une période de quelques années. site anonyme
Tableau 12.2 — Impacts sur les délais.
70 à 80 % de réduction de dépassement des délais en atteignant le

JP Morgan Chase
niveau 2 de maturité du CMMI.
Écart vs. plan initial qui était en moyenne de 130 jours est passé à moins
NCR
de 20 jours une année après l’atteinte du niveau de maturité 2 du CMMI.
Northrop Grumman IT,

A respecté TOUS les jalons (25 consécutifs) avec un degré élevé de
Defense Enterprise
qualité et à la grande satisfaction du client.
Solutions
Tableau 12.3 — Impacts sur la qualité.
44 % de réduction des défauts suite à un cycle d’analyse causale dans

Anonyme
une organisation qui se dirige vers le niveau de maturité 3 du CMMI.
40 % de réduction dans tous les problèmes de production et plus de

IBM Australia Application
80 % de réduction des problèmes de sévérité 1 en passant du niveau
Management Services
3 du SW-CMM au niveau de maturité 5 du CMMI.
Plus de 110 % d’amélioration dans le fait de trouver et résoudre les

erreurs dans la même phase du cycle de vie où elles furent injectées Reuters
quand l’organisation est passée du CMM niveau 3 au CMMI niveau 5.
Tableau 12.4 — Impacts sur la satisfaction des clients.
Lockheed Martin
Augmentation des bons de livraison de 55 % comparativement à
Management and Data
quand l’organisation était SW-CMM niveau 2.
Systems
Augmentation constante de la satisfaction du client en passant du SAIC System and Network

niveau 3 SW-CMM vers le niveau de maturité 5 du CMMI. Solutions Group
Index de satisfaction du client a augmenté de 42 % dans 3 unités

techniques entre 1996 et 2004. Une moyenne de 48 % de cette Siemens Information
amélioration est survenue quand l’organisation est passée du Systems Ltd.
SW-CMM niveau 5 vers le niveau de maturité 5 du CMMI.
Tableau 12.5 — Retour sur investissement (« ROI »).
ROI de 5,33 :1 obtenu par l’utilisation de guide d’estimation et d’un

modèle pour les « use cases » dans une organisation de niveau de Tata Consultancy Services
maturité 5 CMMI.
Un ROI de 6 :1 dans une organisation de niveau de maturité 3 du Raytheon Corporation, site

CMMI anonyme
Un ROI de plus de 3 :1 suite à réduction des défauts découverts

après livraison dans une organisation qui est passée du SW-CMM Reuters
niveau 3 au CMMI niveau de maturité 5.
Les bénéfices 195
Voici par ailleurs des citations de documents présentant justement des données
sur les bénéfices suite à une période d’amélioration de processus. Celles-ci ont été
collectées en utilisant le SW-CMM. Les données sur le CMMI sont encore récentes et
les présentations encore peu largement disponibles. Mais le fait que le CMMI couvre
un domaine plus large que le SW-CMM nous incite à croire que les bénéfices ne
peuvent qu’être encore plus importants ! Voici donc les citations, en traduction libre :
« Nous avons découvert une corrélation entre le niveau de maturité SW-CMM et la
performance, en termes de budget et de calendrier, à partir d’un échantillon généralement
représentatif de contrats de développement logiciel. (...) les organismes plus matures avaient
tendance à mieux respecter les budgets et les délais initialement établis. » (Patricia K. Lawlis,
Robert M. Flowe et James B. Thordahl, « A Correlational Study of the CMM and
Software Development Performance », Crosstalk : The Journal of Defense Software
Engineering, vol. 8, no 9, septembre 1995 – traduction libre).
« Il existe une énorme demande d’information à propos des impacts de l’amélioration
de processus logiciel. En réponse à celle-ci, nous avons collecté des données en provenance
de 13 organismes de niveaux de maturité variés. En analysant comment la performance
évoluait dans chaque organisme à mesure que des efforts d’amélioration étaient déployés, nous
avons identifié des gains substantiels au niveau de la productivité, de la détection hâtive des
défauts, des délais de livraison et de la qualité. Ces bénéfices s’ajoutaient aux impressionnants
retours sur investissements. » (James Herbsleb, Anita Carleton, et al., Benefits of CMM-
Based Software Process Improvement : Initial Results, Software Engineering Institute,
CMU/SEI-94-TR-13, août 1994 – traduction libre).
« Il ressort clairement des données disponibles (...) que l’amélioration de processus logiciel
peut avoir un impact significatif sur les économies d’un organisme de développement (jusqu’à
67 % de réduction des coûts de développement et de correction « rework »). » (Thomas
McGibbon, A business Case for Software Process Improvement, A Data & Analysis
Center for Software (DACS) State-of-the-Art Report, septembre 1996 – traduction
libre).
« Les premières applications du concept de CoSQ (« Cost of Software Quality »)
illustrent que le coût de la qualité du logiciel constitue une part importante des coûts de
développement logiciel : 60 % et plus, pour les organismes qui n’ont pas encore entrepris
de programme d’amélioration de leur processus. L’utilisation du CoSQ peut cependant
démontrer d’importantes économies – comme la réduction de 4 pour 1 des efforts de reprise
(« rework ») mesurée chez Raytheon – pour les organismes de développement logiciel qui
entreprennent des améliorations de leur processus logiciel. » (Dan Houston et J. Bert Keats,
Cost of Software Quality : A Means of Promoting Software Process Improvement, Quality
Engineering, vol. 10, no 3, mars 1998 – traduction libre).
« Soyez réalistes : chaque amélioration prise individuellement n’apportera pas de retours
sur investissement extraordinaires. En déployant 2 ou 3 améliorations par année, nous
avons obtenu un retour moyen relativement modeste de 5 à 10 %. Cependant, après
2 à 3 années d’amélioration continue, le retour sur investissement est devenu assez
impressionnant. L’équipe de développement est devenue, après quatre années d’efforts, 30 %
plus productive. » (Peter Lloyd, Return on Investment from Continuous Software Process
Improvements in an International Company, 5th International Conference on Software

Quality, 23-26 octobre 1995, Austin TX – traduction libre).
« Nous avons constaté (...) une amélioration dans la densité des erreurs avec chaque
initiative centrée sur la qualité du logiciel, mais à un taux décroissant (...) Nous avons
mesuré de plus grands retours sur les investissements en amélioration de la qualité lorsque
ceux-ci étaient appliqués au début des projets. » (Sandra A. Slaughter, Donald E. Harter
et Mayuram S. Krishnan, Evaluating the Cost of Software Quality, Communications of
the ACM, août 1998, vol. 41, no 8 – traduction libre).
On voit donc qu’en général, les entreprises et organismes recouvrent assez rapi-
dement (moins de 18 mois) leur investissement initial. Les bénéfices se mesurent
en charge de reprise (« rework ») diminuée, en erreurs détectées et corrigées en
amont du cycle (diminuant largement les coûts de correction), en productivité
accrue, en meilleur respect et gestion des exigences, en capacité de livrer des produits
nouveaux ou des produits existants dans de meilleurs délais, en crédibilité améliorée
auprès des clients, etc. Aucune entreprise ou organisme n’a jamais déclaré avoir
perdu en investissant dans l’amélioration de son processus avec le CMMI-DEV. Par
extension, on peut raisonnablement présumer, en attendant des données empiriques
plus complètes, qu’il en sera de même avec les constellations ACQ et SVC.
13
Utilisations possibles
du CMMI
Je souhaite ici brièvement décrire les utilisations principales que l’on peut imaginer
pour le CMMI. Je ne prétends pas que ce sont les seules. Ce sont celles que j’ai
rencontrées dans le cadre de mes activités professionnelles dans les nombreuses
organisations qu’il m’a été donné de visiter dans plusieurs pays.
13.1 GUIDE DE BONNES PRATIQUES

Tout chef de projet, manager, développeur, responsable qualité, etc. peut trouver dans
les pratiques du CMMI des idées intéressantes pour améliorer ses façons de travailler.
Lire le CMMI c’est comme accéder au savoir collectif des meilleurs responsables de
projets ou d’activité. On ne peut pas faire autrement que de se laisser influencer par
tous ces bons conseils ! Certes, il arrive un moment où une organisation souhaitera
faire un état des lieux global et se donner un plan d’amélioration. Mais jusqu’à ce que
cette occasion se présente, rien n’empêche les personnes de s’approprier les conseils
des sages et de se faire la main sur de petits pas qui iront tranquillement dans la bonne
direction.
13.2 SOURCES DE GABARITS (MODÈLES) POUR

DES PROCESSUS À AMÉLIORER OU À DÉFINIR
Il n’est pas rare de trouver au sein d’une organisation un groupe de soutien métho-
dologique. Ce groupe, si on le forme au CMMI, saura rapidement trouver dans le
198 Chapitre 13. Utilisations possibles du CMMI
CMMI une source d’inspiration quasi inépuisable pour patiemment développer des
aides méthodologiques destinées aux projets. Ces aides peuvent se présenter sous la
forme de lignes directrices, de directives, de formulaires, de matériel de formation,
pour ne nommer que quelques-unes des façons de déployer les bonnes idées du CMMI
sous la gouverne d’un groupe d’un soutien.
13.3 SOURCE D’INSPIRATION POUR UNE APPROCHE

D’AMÉLIORATION CONTINUE ET PROGRESSIVE
L’agencement des pratiques dans le CMMI, leur regroupement par domaine de

processus constitue en soi une approche d’amélioration par bouquets de pratiques
bien agencées. Le CMMI s’appuie sur une architecture d’affinités entre pratiques
pour composer une palette de domaines de processus qui couvre tout le cycle de
développement de produits ou services. La table des matières du CMMI, en ce sens,
ressemble à la carte d’un restaurant : on y compose son repas en choisissant au gré
de ses priorités commerciales. La progression par paliers du CMMI en représentation
étagée a beau nous proposer des arrangements de domaines préétablis (pour rester
dans la parabole des bouquets floraux), il faut néanmoins fixer un ordre de priorité
à l’intérieur de chaque palier ! Mais on saura, en représentation étagée, qu’il vaut
mieux bien établir sa fondation avec les domaines de processus du niveau de maturité
2 avant de s’attaquer aux domaines du niveau 3. On trouve donc une proposition de
déploiement progressif.
13.4 RÉFÉRENTIEL POUR S’AUTO-ÉVALUER
Je dis souvent à mes étudiants qui assistent au cours CMMI qu’ils doivent profiter
du cours pour s’auto-évaluer (en fait je veux dire évaluer les processus mis en œuvre
dans leurs projets) dans leur for intérieur tout au long du cours CMMI. La méthode
SCAMPI dont je parle abondamment dans un chapitre précédent n’est donc pas
obligatoire pour faire une évaluation avec le CMMI. Il y a en fait tout un spectre
de méthodes d’évaluation qui va de la plus sommaire et rapide à la plus détaillée et
longue. Le SCAMPI (surtout le SCAMPI de classe A) se situe au bout du spectre :
méthode exhaustive, robuste, qui va au fond des choses. Mais une organisation peut
souhaiter se faire la main, amorcer son premier cycle d’amélioration CMMI avec une
approche d’analyse d’écarts plus légère. Plusieurs fournisseurs de services proposent de
nombreuses variantes aux évaluations dites informelles. On a vraiment l’embarras du
choix pour trouver la chaussure qui convient à son pied.
13.5 Référentiel pour évaluer des tiers 199
13.5 RÉFÉRENTIEL POUR ÉVALUER DES TIERS

Je souhaite dire enfin quelques mots sur une utilisation du CMMI qui prend de plus en
plus d’ampleur dans le monde. Je constate que de plus en plus de décideurs trouvent
dans le CMMI un allié précieux pour minimiser les risques. Je donne ci-dessous
quelques exemples parmi les plus courants.
13.5.1 Fournisseurs potentiels (sélection)

La plupart des donneurs d’ordre se trouvent fort rassurés d’apprendre que le CMMI leur
permettra de distinguer « le bon, la brute et le truand » pour rappeler le western spaghetti
de Sergio Leone. En effet, quoi de mieux que le CMMI pour passer au crible les
fournisseurs potentiels ? Sont-ils niveau 1, c’est-à-dire immatures dans leur processus ?
Ou sont-ils niveau de maturité 2 ou 3 ? Peut-être sont-ils très matures (4 ou 5) ?
Quelle est la criticité de notre projet ou de notre activité? Veut-on confier sa destinée
à un amateur ou à un professionnel de haut calibre ? Certes le concept s’applique
tout autant à un prestataire pour un projet donné qu’à un prestataire qui assurera
par exemple le développement et la maintenance de tout un portfolio d’applicatifs
(externalisation ou « outsourcing »).
Je constate d’ailleurs que ce mouvement de recourir au CMMI pour fixer des
niveaux de services aux prestataires de services d’externalisation prend de l’ampleur.
Les contrats d’externalisation (impartition ou « outsourcing ») exigent des prestataires
qu’ils suivent des boucles d’amélioration basées sur le CMMI et qu’ils affichent des
résultats sans cesse meilleurs. Quelle belle façon de s’assurer que l’on en a pour son
argent !
13.5.2 Fournisseurs actuels (audit en cours de projet en vue d’une décision

de go/nogo)
Dans un grand projet qui est en train de faire l’objet de la Chronique d’une mort
annoncée (titre d’un magnifique roman de Gabriel Garcia Marquez), quoi de mieux
que de faire halte et de passer au macro/microscope du CMMI les processus de son
équipe de projet ? On saura mieux juger de l’état des pratiques et mieux décider s’il
faut faire marche arrière, stopper les machines, ou avancer mais avec de nouveaux
processus.
13.5.3 « Due diligence »

Avant d’investir du capital de risque dans une société qui fait du développement de
système, ne serait-il pas bien avisé de regarder l’état de l’usine ? Cette usine virtuelle
est faite des processus de développement. Quelle chance de disposer d’un modèle
objectif comme le CMMI pour faire l’état des lieux. On saura si notre argent se dirige
vers un gouffre ou vers un tremplin.
Conclusion
Y a-t-il une vie après le niveau 5 ?

Je m’en veux d’avoir songé à ce titre de chapitre qui évoque la fameuse question
existentielle « Y a-t-il une vie après la mort ? ». Non pas de vous plonger ainsi dans une
réflexion philosophique mais d’associer niveau 5 à mort plutôt qu’à vie. Certains y
verront un lapsus freudien. Les extrémistes des approches libres et anarchiques diront
même : « Voilà bien où le CMMI nous mène ! Le chat sort du sac : c’est la mort ! » Je
demande grâce. Il y a tellement de personnes qui me posent cette question dans mes
cours : qu’y a-t-il donc après le niveau 5 ? Je ne peux m’empêcher d’aborder cette
question.
Dans le chapitre sur le niveau 5, je disais : « La marche vers l’amélioration est
irrépressible et sans fin. » Le niveau 5 est donc sans fin ? Si on regarde le comportement
d’une organisation de niveau 5, on est loin d’une organisation statique. Elle bouge
sans cesse. Tel un ogre insatiable, elle doit se nourrir et elle bouffe et absorbe des
changements. Une fois digérée, elle réclame d’autres changements. On ne pourrait pas
capter avec une caméra ouverte à une vitesse d’obturation lente une telle organisation.
Sitôt la caméra fixée sur un objectif, l’organisation a bougé et laisse un flou sur la
photo.
Si cette organisation était un cycliste sur une piste, cette piste serait un plan incliné
ascendant et non un plateau. Le cycliste qui est en tête sait que s’il cesse de pédaler, il
va être rejoint par le peloton puis bientôt dépassé.
Dans son essence même, l’optimisation continue, le niveau 5 ressemble à une
boucle sans fin. Un niveau 6 nous semblerait difficilement insérable dans une telle
logique. Peut-être verrons-nous des raffinements à l’intérieur du niveau 5. Mais il nous
semble bien peu probable de voir des niveaux 6 ou plus dans un avenir rapproché ou
dans notre système logique actuel.
Après tout, peut-on être plus heureux qu’heureux ? Plus vivant que vivant ? Alors
pourrait-on vraiment être plus en optimisation qu’en optimisation ? Cette porte ne
peut qu’être ouverte ou fermée.
ANNEXES
A
Indicateurs des pratiques
du CMMI
Une liste proposée d’indicateurs de déploiement des pratiques du CMMI

On connaît tous la légende : Robinson a trouvé Vendredi sur son île en suivant
des traces de pas dans le sable. Les traces de pas constituaient la preuve irréfutable
qu’un humain était passé sur la plage. De même, lorsque l’on réalise une activité de
développement à l’aide d’un processus, on laisse des traces. Il suffit de regarder les
traces pour remonter au processus qui les a laissées. À la façon d’un archéologue qui
examine des artefacts comme preuves de l’activité d’une civilisation on peut utiliser
les indicateurs de déploiement de pratiques comme des preuves de leur déploiement.
Dans le CMMI, sous chaque pratique (à quelques exceptions près), les auteurs
ont pris la peine de donner des clés aux futurs archéologues des processus ou aux
« civilisations » qui voudront mettre en œuvre les processus. Ce sont les exemples
de produits d’activité. On arrive assez facilement à reconnaître en eux les preuves
typiques que l’on est en droit d’attendre d’une organisation qui déploie les pratiques
du CMMI.
Le SEI n’a pas établi une liste normalisée des PII (Practice Implementation Indicators)
car les exemples varient en fonction des techniques, des méthodes, des outils, etc.
Par contre, justement, les exemples de produits d’activité listés sous chaque pratique
nous en donnent déjà un très bon aperçu. Chaque chef évaluateur doit constituer
la liste qu’il proposera comme sa « liste d’épicerie » à l’organisation qu’il ira évaluer.
C’est un peu comme s’il disait à l’organisation : « Trouvez-moi ces documents dans vos
projets ; ce seront autant de pièces à conviction, d’artefacts, de preuves à verser au dossier
de votre évaluation. » L’organisation peut alors disposer d’un certain laps de temps pour
rassembler ces preuves. Mais avant il sera important de personnaliser la liste des PII.
Celle-ci, quand on la donne à l’organisation comme liste à renseigner, doit être adaptée
206 Annexe A. Indicateurs des pratiques du CMMI
à la terminologie du site. Ce que le CMMI nomme « éléments de configuration » sera

peut-être appelé « composants à gérer en configuration » ; quand le CMMI demande de
démontrer une « rencontre de suivi de projet par la Direction », le site peut par exemple
apporter le « procès-verbal du comité de projet », et ainsi de suite.
Une fois la liste de PII personnalisée, le site pourra alors partir à la chasse non pas
aux papillons mais aux artefacts, tantôt dans les projets (ex. : plan de projet, rapports
d’avancement), tantôt au niveau de l’organisation (ex. : plan de formation annuel,
procédure standard d’estimation de la charge). La liste, une fois renseignée, devient
un outil formidablement bien structuré pour faciliter grandement le travail de l’équipe
d’évaluation. Mais aussi, elle peut devenir une façon très pratique d’instituer des revues
d’assurance qualité au fil de l’eau en demandant aux projets de constituer à mesure
leur base de preuves, qui démontrent, finalement, que les projets suivent ou non les
processus de l’organisation.
Au fil des expériences sur le terrain, Alcyonix (ma société) a préparé « sa » liste
de PII. Je vous la livre dans L’aide-mémoire publié chez Dunod (voir bibliographie).
C’est un « work-in-progress » qui peut et doit évoluer à mesure que la collectivité des
utilisateurs du CMMI saura partager ses expériences.
B
La pénétration du CMMI
dans le monde
Les chefs SCAMPI certifiés par le SEI ont l’obligation de retourner des données sur les
résultats à la fin de chaque évaluation. Le SEI utilise ces données, les banalise (retire
toute information permettant d’identifier les sources) et publie deux fois par année des
tableaux statistiques fort utiles pour évaluer la pénétration du CMMI dans le monde.
En date de septembre 2010 (la publication la plus récente au moment de préparer
cette 4e édition), les données portent sur 6 126 évaluations SCAMPI dans 4 909
organisations (soit toute la société ou un sous-ensemble de celles-ci) de 3 857 sociétés
différentes (certaines sociétés ont fait évaluer plusieurs de leurs entités ou organisa-
tions). Plus de 75 % d’entre elles se sont déroulées hors des États-Unis.
On rapporte des évaluations sur tous les continents avec une prédominance de
l’Europe, de l’Asie, et des Amériques, mais l’Océanie et l’Afrique sont aussi touchées
par la vague ! Seuls les ours polaires de l’extrême nord ou de l’extrême sud n’ont pas
vu d’évaluations CMMI !
Notons que ceci ne porte que sur les évaluations officielles ce qui n’est que la pointe
de l’iceberg (puisqu’on parle d’ours polaires). Beaucoup d’autres sociétés ont pu utiliser
le CMMI sans pour autant avoir encore mené une évaluation officielle (SCAMPI).
Ces chiffres changent constamment. La pénétration est sans doute encore plus
grande au moment où vous lisez ces lignes.
Au moment de mettre la dernière touche à la quatrième édition de ce livre, en
décembre 2010, le répertoire officiel du SEI fait état de :
• 328 sociétés qui détiennent une licence de partenaire du SEI pour offrir des
cours CMMI à travers le monde
• 287 sociétés qui détiennent une licence de partenaire du SEI pour offrir des
évaluations SCAMPI à travers le monde
208 Annexe B. La pénétration du CMMI dans le monde
Extrait des profils de maturité publiés par le SEI

http://www.sei.cmu.edu/cmmi/casestudies/profiles/cmmi.cfm), Carnegie Mellon University,
septembre 2010. Note : en gras, les pays ajoutés depuis la dernière publication du SEI.
Par ailleurs, le SEI a célébré en 2009 la participation de la cent millième personne

au cours officiel d’Introduction au CMMI !
C
Les « certifications »
du SEI
Un parcours du combattant !
Le CMMI est disponible gratuitement sur le site du SEI. Quiconque s’intéresse au

CMMI peut ainsi récupérer une copie du fichier en format WORD et PDF. Mais si on
veut ensuite obtenir des « reconnaissances » officielles, il faut y mettre l’effort et le
prix.
D’abord une organisation qui décide de dépasser le stade de l’auto-évaluation
officieuse, devra négocier un contrat avec un chef évaluateur certifié par le SEI pour
conduire une évaluation officielle, nommée SCAMPI (nom donné par le SEI à la
famille de méthodes officielles). Elle devra aussi former au moins quelques personnes
au cours officiel du SEI qui, en trois jours, présente l’Introduction au CMMI. Certes,
ce mot « Introduction » accolé à un cours de trois jours paraît minimiser la profondeur
du cours. Quand on suit ce cours, cette idée se confirme car on va bien au-delà de la
simple « Introduction » pour faire des participants des personnes aptes à bien utiliser
le modèle dans un contexte de projet d’amélioration de processus ou d’évaluation de
processus. Un cours officiel ne se donne que par un instructeur certifié par le SEI ; ce
cours évidemment ne sera pas gratuit !
Il arrive que des organisations se plaignent du coût assez élevé des services officiels
(évaluation ou cours) associés au CMMI. Je sympathise car en effet ils sont élevés. J’ai
pensé que d’expliquer le parcours du combattant pour obtenir les certifications en tant
qu’instructeur ou évaluateur CMMI certifié par le SEI permettrait de comprendre un
peu ce qui amène des prix aussi élevés (en espérant qu’un jour ils puissent diminuer).
210 Annexe C. Les « certifications » du SEI
Aussi, j’ai cru que ceci intéresserait les personnes espérant obtenir ces certifications du
SEI en leur expliquant le parcours et en les préparant au choc de l’effort et des coûts.
Distinguons d’abord entre les deux types de certifications données par le SEI :
celle d’instructeur CMMI certifié et celle d’évaluateur SCAMPI certifié. Les deux
commencent néanmoins par la même exigence : avoir suivi le cours d’Introduction
au CMMI (trois jours, au prix d’environ 2 000 $CAN ou 1 700 euros au cours du
marché de septembre 2006). Ce cours est donné soit par le SEI ou soit par une société
partenaire du SEI qui recrute un instructeur certifié par le SEI. La société en question
doit évidemment payer son instructeur, des frais de « licence » en tant que partenaire
du SEI et des « royalties » pour chaque participant. Ces fonds permettent au SEI de
former les futurs instructeurs, de faire évoluer le matériel de cours et de contrôler la
qualité des prestations.
La personne qui a suivi le cours CMMI et l’a utilisé pendant quelque temps peut
alors vouloir l’enseigner ou diriger des équipes d’évaluation SCAMPI. Dans les deux
cas, la seconde étape sera de suivre le cours avancé sur le CMMI. On exigera d’avoir
utilisé le CMMI sur le terrain pendant au moins trois mois, question de s’assurer
que l’on a dépassé le stade de la connaissance théorique. En fait, ce cours qualifié
d’Intermediate est plutôt un atelier pratique dirigé par des instructeurs chevronnés
du SEI où les candidats doivent démontrer leurs connaissances du CMMI lors de
présentations et d’un test de compréhension portant sur le CMMI. Ce cours est donné
uniquement par le SEI qui désire s’assurer de l’homogénéité du contenu auquel on
expose les futurs instructeurs ou évaluateurs certifiés. Il ne se donne pas très souvent ni
dans beaucoup d’endroits (au SEI même à Pittsburgh aux États-Unis ou dans quelques
villes importantes hors États-Unis). Son prix frise les 4 000 $US (somme payable au
SEI donc en dollars américains). Il y a un test à la fin pour s’assurer que le contenu est
maîtrisé. C’est suite à ce cours et au passage du test que le parcours va différer entre le
futur instructeur et le futur évaluateur.
Le futur instructeur CMMI devra se trouver une société partenaire du SEI pour le
cours CMMI qui acceptera de le parrainer pour la suite de son parcours. Cette société
partenaire soumettra le dossier de son candidat instructeur au SEI. En plus de ses
antécédents académiques et de ses expériences, le SEI s’assurera que dans sa base de
données, le nom de ce candidat est bel et bien enregistré comme ayant assisté aux
cours CMMI (Introduction et Intermediate). Alors, il inscrira ce candidat au prochain
cours dédié aux instructeurs CMMI qui ne se donne qu’au SEI par le SEI. Le prix est
dégressif en fonction du nombre de stagiaires inscrits par la même société parraine ;
il peut s’élever jusqu’à près de 10 000 $US pour cinq jours de cours intensifs et de
coaching par des instructeurs seniors du SEI. Une évaluation formelle (test) permet
à ceux-ci de rendre leur verdict : ça passe ou ça casse ! Bien malheureux celui qui a
payé une somme assez conséquente et qui n’est pas accepté. Mais même s’il réussit, le
stagiaire ne peut pas encore recevoir son certificat d’instructeur. Prudent, le SEI exige
que cet instructeur en devenir donne son cours sous l’observation (pas gratuite quand
même) d’un délégué du SEI qui fera rapport au responsable du programme CMMI. Si
le rapport est positif, le candidat reçoit alors son certificat tant convoité et mérité ! On
lui demandera 2 000 $US pour ce certificat et son renouvellement chaque deux ans.
Les « certifications » du SEI 211
Le futur chef évaluateur SCAMPI n’aura pas la vie plus facile ! Il devra aussi
se trouver une société partenaire du SEI, cette fois pour les évaluations SCAMPI,
qui acceptera de le parrainer pour la suite de son parcours. Cette société partenaire
soumettra le dossier de son candidat chef évaluateur SCAMPI au SEI. En plus de ses
antécédents académiques et de ses expériences, le SEI s’assurera que dans sa base de
données, le nom de ce candidat est bel et bien enregistré comme ayant assisté aux
cours CMMI (Introduction et Intermediate). Mais il y aura une importante exigence
additionnelle. Dans les deux années qui auront précédé, il devra avoir participé en tant
que membre d’équipe à un minimum de deux évaluations enregistrées auprès du SEI
(donc officielles). Ces deux évaluations à elles seules représentent un investissement
total en temps qui peut varier d’une trentaine à une cinquantaine de jours ! Alors
seulement le SEI l’inscrira-t-il au prochain cours dédié aux chefs évaluateurs SCAMPI
qui, lui aussi, ne se donne qu’au SEI par le SEI : les places disponibles sont rares et
se paient à prix d’or : autour de 8 000 $US pour cinq jours de cours intensifs et de
coaching par des chefs évaluateurs seniors du SEI. Une évaluation formelle (test)
permet à ceux-ci de rendre leur verdict : ça passe ou ça casse ! S’il échoue, le candidat
a droit à des reprises sous certaines conditions. Mais même s’il réussit, vous l’aurez
deviné, le stagiaire ne peut pas encore recevoir son certificat de chef évaluateur.
Prudent toujours, le SEI exige (eh oui !) que ce chef évaluateur en devenir mène
(comme chef donc et non comme membre d’équipe) une évaluation SCAMPI sous
l’œil vigilant d’un délégué du SEI qui fera rapport au responsable du programme
SCAMPI. Si le rapport est positif, le candidat reçoit alors son certificat qu’il veut à
tout prix encadrer tant il a payé de ses deniers et de sa personne. Il y a aussi les frais
de certificat renouvelable aux deux ans.
212 Annexe C. Les « certifications » du SEI
Schéma des étapes pour devenir « certifié ».
Lorsque vous discuterez avec un chef évaluateur ou un instructeur certifié par le

SEI, comprenez que cette personne a véritablement connu un parcours du combattant
qui devrait vous rassurer sur sa compétence. Serez-vous étonné de découvrir qu’il n’y
ait que quelques centaines de certificats actifs en vigueur dans le monde ? Pouvez-vous
espérer un prix d’aubaine pour une telle expertise ? Je conviens par ailleurs qu’il peut
y avoir des personnes qui ont acquis leurs titres de noblesse autrement, sans passer
par les certifications du SEI puisque le modèle CMMI est public et que n’importe qui
peut développer SON cours et SA méthode d’évaluation. Il faut alors utiliser son bon
jugement pour distinguer entre Le bon, la brute et le truand... et accepter que l’on ne
Les « certifications » du SEI 213
puisse totalement se comparer à d’autres puisque le référentiel utilisé pour former ou

évaluer n’est pas commun avec les cours et évaluations officielles du SEI auxquels
sont imposées des normes uniformes, dictées par le SEI. Une approche hybride est
souvent utilisée d’ailleurs : utiliser des approches officieuses pour se familiariser et
déployer des actions d’amélioration et les approches officielles pour faire confirmer.
Il y a donc toute une palette de solutions pour les différents besoins et étapes de son
projet d’amélioration de processus.
Note importante
Depuis 2008, le SEI impose une nouvelle étape dans le cursus des évaluateurs SCAMPI.
Avant de décerner le certificat, un test objectif sera soumis aux candidats.
De plus, les candidats devront décider s’ils veulent être certifiés pour faire des
évaluations SCAMPI jusqu’au niveau de maturité 3 seulement ou jusqu’au niveau 5.
S’ils aspirent de faire des évaluations aux niveaux de maturité 4 et 5, ils vont passer
un test additionnel sur ces aspects de même qu’une entrevue pour leur décerner un
certificat de « High Maturity ».
D
« Histoires vécues »
et autres histoires
« Rassurez-vous, je n’ai pas vécu tous ces problèmes sinon je vivrais aujourd’hui en ermite
loin du monde, essayant de comprendre pourquoi le mauvais sort s’est tant acharné sur moi.
J’aurai souvent l’occasion de citer des exemples relatifs aux systèmes sur lesquels j’ai travaillé,
mais pas seulement. Je prends à mon compte des expériences qui ont pu concerner d’autres
personnes, collègues ou amis. Que le lecteur ne soit pas effrayé, je m’efforcerai d’en expliquer
le contexte pour une bonne compréhension. »
Denise C ATTAN
Du bon énoncé des exigences

(Illustration du non-déploiement des pratiques de type REQM-SP1.1.)
Au milieu du XVIIe siècle, de nombreuses familles parties du Perche français ont pris
possession de terres dans la Belle Province.
Mais beaucoup d’hommes sont partis seuls dans cette aventure et Pierre Boucher,
surnommé le « patriarche de la Nouvelle-France » implore le roi Louis XIV de faire
envoyer des filles à marier et de prendre en charge « le soin de pourvoir la colonie en
épouses et en mères ». Talon, l’intendant de la Nouvelle-France exprime ainsi le besoin :
« des âges convenables à la génération et surtout qu’elles soient bien saines ». Le roi s’engage
à doter pendant dix ans les « filles, femmes ou veuves » passées au Canada (appelées
Filles du roi).
Elles sont peu nombreuses et ne donnent, semble-t-il, pas toute satisfaction aux
demandeurs. Trois ans plus tard, le Sieur Talon revoit ses exigences dans la demande
qu’il fait à Colbert : « qu’elles ne soient aucunement disgraciées par la nature, qu’elles
n’aient rien de rebutant à l’extérieur, qu’elles soient saines et fortes pour le travail de
campagne ou du moins qu’elles aient quelque industrie pour les ouvrages de main ».
216 Annexe D. « Histoires vécues » et autres histoires
Il y a encore beaucoup de subjectivité dans la façon dont ces exigences peuvent

être vérifiées mais on sent bien que le demandeur a voulu mieux préciser son besoin
en donnant des critères de satisfaction.
C’est le plus ancien exemple d’exigences que j’aie dans ma bibliothèque. Ce
n’est pas pour autant qu’il est satisfaisant car il laisse encore beaucoup de place à
la subjectivité de la personne qui fait le choix. Il est bien entendu qu’à toute exigence
doit être associée une quantité qui permettra de s’assurer qu’elle est satisfaite. Bien
d’autres critères sont aussi utilisés, il y a de bons documents sur le sujet.
Demain, il fera jour !

(Illustration du non-déploiement des pratiques de type PP-GP2.2.)
J’ai interviewé un jour une personne qui avait en charge un projet se déroulant en
plusieurs phases. Le client ne notifiait les phases que l’une après l’autre. Ce chef de
projet conduisait donc la première phase de réalisation dudit projet. En principe, il
s’attendait à la notification de la seconde phase dès la fin de la première.
La notification de la seconde phase était imminente et je lui demandais de
m’expliquer comment il avait planifié les activités correspondant à la négociation
éventuelle de la seconde phase et la préparation du plan projet correspondant à cette
seconde phase.
Il n’avait rien préparé. On ne voyait nulle part comment il pourrait dégager le
temps qui lui serait forcément nécessaire pour confirmer les éléments de déroulement
du projet, les compléments à son plan en cours et la préparation des échéances les plus
rapprochées de la seconde phase
Comme un chef de projet a bien du mal à réaliser déjà ce qu’il a prévu, on peut
être sûr a fortiori qu’il ne disposera d’aucune capacité à faire ce qu’il n’a pas prévu.
Demain, il ne fera pas jour !
Comme un surfeur sur la vague

(Illustration du non-déploiement des pratiques de type PMC-SP2.3 et PPQA-SP2.1.)
On a quelquefois l’impression que les chefs de projet aiment surfer sur une pile
d’actions qui roulent sans jamais se clore.
Dans une équipe où j’étais, le suivi des actions était une préoccupation. Nous y
consacrions une part non négligeable de notre réunion d’avancement périodique. Un
tableau avait été mis au point qui affichait automatiquement en rouge les actions
dont la date prévue de réalisation avait été dépassée. Il arrivait que certaines d’entre
elles réapparaissent ainsi à chaque réunion. Bien sûr, on actualisait la date prévue, la
personne qui en était chargée (si elle était présente) donnait une nouvelle prévision et
l’action passait en orange, comme étaient en orange les actions dont la date d’échéance
était avant la prochaine réunion d’avancement.
Mais, immanquablement, le problème se reposait à la réunion suivante.
« Histoires vécues » et autres histoires 217
Je pense que nous n’avons pas eu les bonnes réactions. Comme j’ai eu le plaisir de
le constater dans une autre équipe, donner des indicateurs qui matérialisent ce fait et
l’énergie perdue associée conduit à se poser des questions sur l’action elle-même :
• En a-t-on besoin ? Car, si le projet a pu continuer malgré le glissement, c’est que
l’action ne présentait pas un si grand impératif !
• La personne en charge est-elle la bonne ?
• Les personnes concernées sont-elles sensibilisées ?
• Faut-il diviser l’action en plusieurs plus élémentaires et mieux maîtrisables ?
Des actions non closes, ce sont des efforts dépensés inutilement.
Date, vous avez dit date ?

(Peut-être considéré comme un problème de data management ou d’audit de configuration.)
Il m’est arrivé de participer à une évaluation interne conduite par une équipe de SEPG.
Ils m’avaient tout simplement invitée à les suivre, ce qui me permettait de m’assurer
que leur démarche était cohérente avec ce qu’ils m’annonçaient par ailleurs. Nous
avons ainsi rendu visite aux personnes tenant les rôles principaux du projet, nous nous
attachions à vérifier la traçabilité des exigences. Après avoir recueilli de chacun les
informations sur ce qu’il considérait être « sa référence », nous avons ensuite rendu
visite à la personne en charge du référentiel de configuration car nous avions un petit
problème de date de validation.
Nous avions en effet une spécification d’allocation d’exigences (SSDD) qui
semblait être validée avant que ne soit validée la spécification de besoins système
(SSS). Nous avons donc demandé une édition de la base concernant les éléments en
question. C’était cohérent avec ce que nous avaient dit nos interlocuteurs. Alors, d’où
venait le problème ?
Nous avons fait sortir les documents et les avons étalés sur la table. Et la réponse
nous est apparue ! Certains avaient énoncé leur date en JJ/MM/AA, d’autres en
MM/JJ/AA. Il n’y avait tout simplement pas eu de définition de la façon dont une
date devait être formulée. Faites l’essai dans un tableur et vous verrez les dégâts que
cela peut faire.
Cela a permis également de mieux spécifier ce qu’on entend par date de validité
d’un document. Car il y a bien souvent trois dates au minimum qui peuvent être
considérées comme telles : la date d’impression du document qui a été soumis au
circuit de signature, la date de la dernière signature d’approbation, la date à laquelle
le document est mis au référentiel du projet.
Je sais tout mais je ne dis rien

(Illustration du non-déploiement des pratiques de type PPQA-SP2.1.)
Cela aurait pu être la devise d’un responsable qualité qu’il m’a été donné de rencontrer.
Nous étions en pleine évaluation du type « état des lieux » et mettions en évidence
un certain nombre de faiblesses que les membres de l’équipe relevaient bien conscien-
cieusement. Puis le moment est venu d’interviewer des responsables qualité. Quelle
n’a pas été notre surprise de constater que rien n’était ignoré de l’un d’entre eux, qu’il
avait même établi des notes et un rapport synthétisant ses constats mais qu’il n’en
avait jamais fait part à qui que ce soit !
Que gâchis ! Imaginez le temps gagné si ces problèmes avaient été remontés et
que des actions aient pu être mises en place ! Je ne crois pas que cela ait été dû à
une volonté de garder l’information. Simplement, il n’avait pas su que faire de cette
information. Les voies de communication n’avaient pas été bien définies.
Quelle pétaudière !
(Illustration du non-déploiement des pratiques de type GP2.3, IPM-SP1.3 ou OPD-SP1.6.)
Madame Cattan, chez vous, c’est une pétaudière ! C’est par ces mots que m’a saluée
l’Ingénieur en Chef qui représentait notre client. Il venait participer à une réunion
d’avancement alors que la phase d’intégration du système allait bientôt commencer.
Je me suis bien sûr gardée de répliquer, en attendant de comprendre un peu plus ce qui
m’était reproché. C’est le soir que j’ai pu consulter un dictionnaire pour comprendre le
sens de cette expression. Il y est dit : « un lieu de désordre et de confusion où chacun veut
être le maître ». Cela me parut exagéré par rapport au problème constaté. Venons-y.
Le projet était démarré depuis quatre ans et il avait été prévu à l’origine qu’il
utiliserait une certaine plateforme d’intégration. Il en existait plusieurs, en nombre
limité, que les projets utilisaient successivement. Malheureusement, le projet avait
pris du retard et l’enchaînement des systèmes sur les plateformes d’intégration n’avait
plus été possible comme prévu à l’origine.
Il fut donc décidé d’en construire une nouvelle. Cela consistait à couler du béton et
à y sceller une « sous-sellette » destinée à recevoir une tourelle, le tout respectant des
exigences draconiennes d’interfaces mécaniques (ex. horizontalité, planéité). Il fallait
aussi passer toutes les interconnexions qui permettraient de relier le système au local
des machines tournantes qui se trouvait au-dessous. Enfin, il fallait que l’ensemble soit
entouré d’une enceinte permettant de respecter les engagements de sécurité liés à ce
type de système.
La phase d’intégration avait commencé avec un shelter, sorte de grand conteneur
qui allait recevoir les équipements. Il y avait bien une grille autour. Mais le lecteur de
badge n’était pas encore actif car il manquait une liaison permettant d’accéder aux
informations adéquates. Pour la mettre en place, il fallait faire une tranchée, mais cela
ne fut fait qu’après la réunion en question. L’Ingénieur en chef était arrivé sur le site
avec un peu d’avance, s’était rendu sur la plateforme d’intégration, et avait constaté
que n’importe qui pouvait y entrer. C’était la raison de mon interpellation.
Il arrive bien souvent que des phases importantes d’un projet ne puissent être
engagées, faute de la disponibilité des moyens nécessaires. Il faut donc veiller au
développement et à la réalisation de ceux-ci avec la même rigueur que l’on peut
apporter au développement du système ou produit principal objet du contrat.
Si c’est faisable, ce sera fait

(Illustration du non-déploiement des pratiques de type RD-SP3.1.)
Lorsque j’ai commencé à travailler, j’étais « ingénieur d’étude », c’est ainsi que l’on
appelait les ingénieurs frais émoulus, sans expérience. Les entreprises profitaient
de leurs connaissances encore très théoriques pour leur faire étudier des concepts
nouveaux, et eux s’imprégnaient de l’entreprise et de ses multiples métiers. J’ai
travaillé avec un collègue à la détermination de correcteurs numériques, ce qui était
méritoire lorsque l’on cherchait cinq chiffres significatifs, sans moyens numériques
pour les calculer. C’était son sujet de thèse. Notre seul outil était une machine
électromécanique qui nous permettait quand même de faire les multiplications et
divisions (à condition de placer correctement la virgule sinon, elle s’emballait). Les
essais se faisaient sur un ensemble de simulation hybride : un calculateur numérique
(celui du système qui utiliserait le correcteur), des organes d’entrée/sortie réels (conver-
tisseurs, séquenceur d’échanges...) mais le reste des équipements était simulé sur des
calculateurs analogiques. Imaginez de grandes armoires avec des petits tiroirs, un
pour chaque fonction élémentaire comme par exemple « intégration », « dérivation »,
addition. Les connexions entre ces petits tiroirs étaient faites sur un « patchboard »
avec une multitude de câbles reliant les points entre eux. Il n’existait aucune
protection par-dessus ce tableau de câblage. Notre seule crainte était qu’une femme
de ménage n’arrache un câble par inadvertance avec son balai et ne le rebranche
n’importe où. Cela s’est produit, bien sûr, mais heureusement pour nous le câble était
resté déconnecté.
Compte tenu de l’effort que représentait un contrôle complet des connexions,
l’adjonction d’une porte de protection aurait sans doute était une façon adéquate de
gérer le risque présenté par cet événement potentiellement probable.
Cela ne devrait plus se produire de nos jours si l’on étudie de façon exhaustive
toutes les situations d’emploi. Cela me rappelle deux autres exemples récents, qui ont
été correctement gérés.
Un équipement est destiné à être placé sur un véhicule militaire, en extérieur.
Même si aucune exigence ne le stipulait, sa conception est telle qu’une personne peut
marcher dessus, car il servira forcément un jour de marchepieds. Il doit donc de plus
être recouvert d’un revêtement antidérapant.
Nous avions une installation sur un bâtiment de la marine (rappelez-vous, le
« shelter »). Dans ce « shelter » se trouvait le meuble radar. Il était relié à la tourelle où
se trouvait l’antenne au moyen de guides d’ondes entre autres. Il suffit d’être allé un
peu sur un bateau, en mer, pour se rendre compte que tout ce qui peut être considéré
comme une poignée sera forcément agrippé un jour par la personne qui se trouve à
proximité. Nous avons donc disposé devant les guides d’ondes un cadre rigide et solide
qui pouvait faire office d’organe de préhension pour tout marin en mal de s’accrocher
quelque part.
L’avare paie deux fois (proverbe russe)

(Illustration du non-déploiement des pratiques de type SAM–SP1.2 et GP2.7.)
Lorsque nous devions livrer un système de guides d’ondes à bord d’un bâtiment de
la Marine pour installation, cela ne se faisait pas sans un minimum d’opérations
préalables.
Nous fournissions bien sûr des données d’installation pour que le chantier où se
construisait le bâtiment puisse préparer ce dernier à recevoir notre système.
Nous devions également fournir ce que nous appelions les « fournitures anticipées »
qui allaient permettre l’installation du système à son arrivée. Ces fournitures compre-
naient des éléments de fixation et de raccordement. Ces éléments de raccordement
comprenaient des câbles (lorsqu’ils étaient spécifiques) et les fameux guides d’ondes.
Ces guides d’ondes avaient des spécifications particulières en fonction de leur
bande passante, et de différents paramètres comme les pertes que nous pouvions
tolérer dans la puissance radar transmise. Ils étaient composés par exemple d’éléments
droits, de coudes, de « twists » chacun avec des caractéristiques précises.
Nous avions l’habitude de travailler avec un certain fournisseur et avons donc
établi notre commande vers le service achats (c’est la règle, aucune commande ne
sort sans passer par lui) en indiquant les éléments dont nous avions besoin pour notre
installation à bord. Puis nous avons attendu la livraison.
Catastrophe ! Les éléments qui nous sont parvenus n’étaient pas ceux que nous
avions commandés. Comment cela a-t-il pu être possible ?
Le service achats avait une démarche d’amélioration en cours et un objectif de
réduire de façon drastique le coût des éléments provenant de l’extérieur. Se basant
sur notre commande, ils avaient cherché des fournisseurs proposant des éléments à
moindre coût, sans nous en informer.
Le coût était moins élevé mais le traitement des éléments était différent (traitement
des surfaces internes des guides). Dans notre commande, nous n’avions pas spécifié
certaines caractéristiques indispensables que les éléments reçus ne respectaient pas.
Or, nous devions impérativement livrer les éléments en question !
Nous avons fait le tour des usines, toutes les plateformes d’intégration, toutes les
plateformes d’essais et avons pu réunir un patchwork (à cause des diverses couleurs et
autres marquages) qui pourrait satisfaire les exigences techniques mais certainement
pas celles du client.
Nous avons dû nous présenter au chantier tout penaud avec notre attirail de
« plomberie » (comme les équipes du logiciel aimaient à dire) dépareillé, et quelques
explications.
Nous avons dû montrer le plan que nous avions pour remettre la situation
d’aplomb.
Nous avons dû recommander un autre jeu de guides, et faire au total deux fois
l’installation de ceux-ci.
Nous avons eu de la chance que des pénalités ne nous aient pas été appliquées !
Un monument... aux avions

(Illustration du non-déploiement des pratiques de type TS-SP1.1.)
Alors que je travaillais sur des études de projet (je veux dire en amont, avant de
pouvoir faire les offres correspondantes), il m’est arrivé de me rendre sur une base
navale allemande. J’ai été tout à fait interloquée par le monument sur lequel nous
sommes tombés à notre entrée dans la base. C’était un avion F104 planté dans le sol !
La raison de ce spectacle nous a été fournie par les personnes que nous rencontrions.
Le F104 avait acquis une triste réputation. Et pourtant, c’était à l’origine un bon avion.
Mais, en service dans ce pays, des modifications lui avaient été apportées qui avaient
modifié ses conditions de vol jusqu’à augmenter la probabilité de le voir se planter.
En fait, on rencontre souvent ce dilemme : une organisation a mis au point ce
qui lui paraît être une ligne de produit et ensuite, tout projet s’y colle, avec plus ou
moins de verrue. Mais la question qu’il faut se poser alors est la suivante : Faut-il rester
conforme à l’architecture d’origine ou faut-il mettre en cause cette architecture ? La
réponse doit alors se faire en suivant une démarche formelle (application de DAR).
Si on exclut la mise en cause de l’architecture, on peut se poser la question du
« REUSE » qu’il est judicieux de justifier aussi formellement. Mais cela fait l’objet du
commentaire suivant.
Reuse, Ô mon cher Reuse !

(Illustration du mauvais déploiement des pratiques de type TS-SP 2.4.)
Lors du lancement d’un système destiné à être utilisé dans un environnement donné, il
fut décidé de réutiliser un équipement qui avait été conçu pour un emploi dans un autre
environnement. Formidable, pas de développement, ça va coûter moins cher ! Oui
mais, voilà, le produit que nous allions recevoir était donc prélevé sur une fabrication
en série et nous en prélevions un après vérification finale. Voilà l’équipement arrivé
pour l’intégration et qui nous pose bien des problèmes. Il est peint dans une couleur qui
n’est pas du tout celle de notre client. Il faut donc le décaper, et ce n’est pas évident.
Il faut protéger les connecteurs et tous éléments de fixation et faire un décapage
suffisant pour atteindre les sous-couches. Car, bien sûr, les sous-couches compatibles
de la couche finale ne sont pas les mêmes. Je donne là un exemple qui paraît facile,
mais pensez à la main d’œuvre supplémentaire qu’il a fallu pour faire ce travail alors
que l’équipement avait été fabriqué en série et avait demandé moins de main d’œuvre
pour tout le reste de sa réalisation !
Tous les industriels qui ont investi dans le développement d’un produit souhaitent
pouvoir le réutiliser pour un autre contrat. Le problème est bien souvent lié au fait
que la conception initiale n’a pas été faite avec le concept de réutilisation et que le
produit est très lié au premier client.
Pour qu’un produit soit réutilisable, il faut que l’ensemble des exigences qui
s’appliquent à ce produit soient réutilisables, qu’elles n’aient donc rien qui soit liée à
une spécificité de ce client par rapport au panel des clients potentiels.
Pataugeons un peu dans la peinture

(Illustration du mauvais déploiement des pratiques de type RD-SG3.)
Nous nous sommes retrouvés à un moment dans une situation confortable vis-à-vis
de ces problèmes de peinture. C’était le début des équipements fonctionnant en
infrarouge. Pour que les détecteurs fonctionnent correctement, il fallait les maintenir
à une température d’environ – 200 ◦ C. Cela se faisait au moyen de systèmes de
refroidissements externes, avant qu’ils ne deviennent intégrés aux équipements. Mais
pour faciliter le travail, nous avons pu faire valoir à notre client que cet équipement
serait peint en blanc, que nous avons appelé le « blanc optique ». Cela permettait
de gagner de précieux degrés par rapport à ce qu’aurait donné un vert olive ou un
gris-bleu moyen. Pendant quelque temps, nous avons vraiment eu un produit.
Les personnes chargées de prononcer l’acceptation des équipements faisaient
systématiquement un test sur la tenue de la peinture. Cela consiste à faire un griffage de
la peinture, puis à coller sur cette zone griffée un ruban adhésif que l’on arrache ensuite.
La peinture doit tenir. Si des morceaux cèdent, l’épaisseur des couches est mesurée et
peut conduire à des reprises. C’est là que pouvaient jouer les bonnes relations que l’on
pouvait avoir avec ce personnel. Lorsque l’on jouait la transparence, le test était fait
en un endroit masqué, sur lequel on pouvait faire une retouche anodine (sous réserve
que les résultats aient été satisfaisants). Lorsque les relations étaient tendues, le test
pouvait se retrouver sur une face parlante, avec des conséquences plus problématiques
comme vous pouvez l’imaginer.
S’il y a bien un domaine où le fournisseur voudrait imposer ses règles, c’est
dans l’aspect final de l’équipement qu’il propose. Toute reprise finale peut se révéler
catastrophique. Il en est de même d’autres exigences, souvent non vraiment justifiées
pour le client, mais qu’il considère agréables à avoir. C’est donc un domaine qu’il faut
négocier au maximum avec le client, avant signature du contrat.
Problème de peinture et d’étiquette

(Illustration du non-déploiement des pratiques de type GP2.7.)
S’il y a bien une chose qui horripile, exaspère les techniciens qui présentent un
équipement en acceptation, c’est de constater que les problèmes techniques se révèlent
mineurs par rapport aux problèmes posés par la peinture et les étiquettes. Ils se
sont acharnés à compenser les retards souvent pris par les phases antérieures en
travaillant comme des forcenés et tout ça pour voir que l’acceptation est reportée par
manque de marquage ou non respect d’une épaisseur de peinture ! Tant qu’ils n’ont
pas fait l’expérience de se rendre chez le client, sur son site d’exploitation, ils peuvent
difficilement comprendre. Regardons maintenant de près où les problèmes peuvent
résider.
Pour des équipements amenés à passer toute leur vie à l’extérieur, quelquefois dans
des ambiances corrosives, la protection est effectivement de première importance.
Avez-vous jamais vu à quoi se trouve réduit un bateau abandonné sans traitement
régulier ? La rouille et toutes sortes d’oxydations ont tôt fait de rendre le bâtiment
inapte à l’usage, et il peut même y devenir impossible de démonter un équipement.
Pour les étiquettes, je me souviens avoir vécu une expérience pénible lors de
l’installation chez le client. Nous avions correctement réalisé et vérifié tous les
marquages. Nous avions également fourni un dossier d’installation complet, avec
les contraintes liées aux opérations de maintenance (dégagements à prévoir pour
l’installation, les ouvertures, les échanges de matériels défectueux, les organes en
mouvement...). Nous avions eu l’occasion de voir les plans d’installation prévus par le
chantier. Lorsque nous sommes arrivés avec le matériel pour l’installer, une cloison
avait « poussé » à un endroit qui empêchait de lire les étiquettes présentes sur le bâti
d’un équipement.
On peut en conclure que nous n’avions pas entretenu de relations suffisamment
régulières avec le chantier pour éviter qu’un tel incident ne se produise.
Lenteur des circuits de signature pour les demandes d’évolution

(Illustration du risque de mauvais déploiement des pratiques de type CM-SG2 & GP2.4.)
J’ai pendant quelque temps été le garant de la « politique produit » (qui n’en était pas
vraiment une) de notre système. Cela signifiait que je voyais passer toutes les demandes
d’évolution portant sur tout constituant de notre système. Cela correspondait en plus
avec le début de l’abandon des composants dits « militaires ». Inutile de vous dire que
j’avais parfois des piles importantes de dossiers de modification qui attendaient.
Les personnes en charge de la gestion de configuration ont émis l’avis que je
devrais leur déléguer une partie des dossiers jugés mineurs pour lesquels je n’avais pas
beaucoup de valeur ajoutée. J’en convenais mais encore fallait-il définir cette limite.
Sur ces entrefaites m’arrive un dossier jugé mineur. La demande d’évolution portait
sur la fixation d’un connecteur sur une carte imprimée. Quelques explications :
Dans les racks avec des cartes, les connexions entre cartes se font normalement
par le fond de panier (avec ce que l’on appelle une « carte-mère »). Il peut arriver que
ce ne soit pas suffisant, ou que l’on veuille éloigner des signaux, on peut alors utiliser
des câbles plats (limandes) qui viennent s’enficher sur des connecteurs en haut des
cartes. La fixation d’un connecteur sur une carte posait problème car les trous dans
la carte n’étaient pas de largeur suffisante. La demande d’évolution portait donc sur
l’élargissement de ces trous.
J’examinai le dossier portant la solution et bloquai le tout. Pourquoi ?
Les cartes étaient conçues avec des moyens informatiques. Sur un coin du schéma,
il y avait une synthèse de tous les perçages de la carte. Chaque perçage était repéré
par un code, et le nombre de ces perçages était indiqué, avec leur position sur la carte
(en X/Y). Je vis que le code que l’on voulait remplacer par un autre ne figurait pas en
quantité 2 comme je m’y attendais mais en quantité bien supérieure. Le même type de
perçage était utilisé pour fixer certains composants sur la carte. Je vous laisse imaginer
la suite si je n’avais pas vu l’erreur, des soudures sèches certainement !
Inutile de vous dire que, pendant quelque temps, il n’a plus été question de
délégation de signature !
Zéro, ce n’est pas rien

(Illustration du mauvais déploiement des pratiques de type MA-SP.)
Il m’est arrivé de voir les choses les plus surprenantes en termes de mesures. Des
tableurs sur fichier de type « Excel » étaient utilisés, et réutilisés. Il y avait des formules,
plus ou moins compliquées, qui donnaient un résultat nul dans certains cas d’absence
d’entrée. Si bien que l’on pouvait voir, par exemple, des prévisions de charges très
importantes tomber brutalement à zéro. Après explication, on voyait ce qui se passait,
mais les personnes qui avaient donné ce rapport n’étaient pas conscientes de ce que
cette « fausse mesure » pouvait donner, si l’on s’avisait de la consolider avec d’autres
informations.
Pratiquer des mesures est un art.
Les personnes que l’on charge de cette pratique doivent être avisées de ce qui sera
fait avec leurs mesures. La même attention doit être portée à la véracité des valeurs
portées.
En France, nous sommes très friands de ce que l’on appelle la courbe temps – temps
ou la courbe à 45◦ . De quoi s’agit-il ? C’est la prévision de tenue de jalons en fonction
du temps. Dans un projet idéal, ces prévisions sont horizontales, car les délais sont
inchangés, et se terminent plus ou moins sur la courbe à 45◦ correspondant à la date
du jour de la mesure qui suit juste le jalon prévu. Dans un projet en difficulté, les
prévisions ont tendance à s’écarter de temps en temps des valeurs initiales et on voit
des marches d’escalier. Dans un projet en grande difficulté, ces prévisions finissent
par prendre la parallèle à cette diagonale 45 et on peut douter d’en voir un jour la
terminaison. Il m’est arrivé de voir des prévisions dont la distance à la diagonale 45
avait augmenté ! Que s’était-il passé ? Simplement, lors d’une date prévue de mise à
jour, la mesure n’avait pas été faite et, pour éviter une remarque, la personne en charge
avait extrapolé à partir des mesures précédentes. Lors de la mise à jour suivante, la
vérité s’est révélée très brutalement.
Mieux vaut ne pas donner de mesure que d’en donner de fausses.
Voilà un autre commandement à respecter dans ce domaine.
Hubble
(Illustration du non-déploiement des pratiques de type CM-SP2.2.)
Il y a eu également beaucoup de littérature sur le sujet, je voudrais juste rappeler un
petit détail. La première mission envoyée avec la navette pour récupérer le satellite a
été un échec parce que le bras articulé qui devait s’arrimer dessus pour l’agripper et le
faire rentrer dans la soute n’a pas pu remplir sa mission. Pourquoi ?
Parce qu’une modification à « trois francs six sous » (ou, plutôt, à dix dollars)
n’avait pas été correctement gérée. Il existait une différence entre la pièce telle qu’elle
était sur le satellite et la pièce telle qu’elle était dans le dossier. Le bras avait été fait à
partir du dossier bien sûr.
Cette anecdote est toujours bonne à rappeler.
On m’a appris à faire ça, je le fais encore 50 ans après !

(Illustration du non-déploiement des pratiques de type MA-SG1 et SP3.2.)
Quelle fierté dans cette affirmation !
Un collègue m’a raconté l’histoire suivante qui lui est arrivée alors qu’il était frais
émoulu de l’école.
Il avait été envoyé dans une entreprise pour participer à un audit. Parmi les
différentes personnes qu’il avait été amené à rencontrer, un Monsieur l’avait par-
ticulièrement frappé et qui, lui, se trouvait plutôt près de l’âge de la retraite. Alors
qu’ils abordaient le sujet des mesures, ce Monsieur, très fier, lui montra la série de
registres ainsi que celui sur lequel il travaillait avec les relevés qu’il y avait portés.
• Tous les jours je mesure la hauteur de la rivière.
• Mais pourquoi faites-vous cette mesure ?
• Mon p’tit gars, j’ai commencé à 14 ans, on m’a appris à faire ça et je n’ai pas
manqué un jour.
• Mais enfin, à quoi servent ces mesures ?
• J’ai eu un maître formidable. Il m’a appris comment faire ces mesures.
La réponse à sa question, il l’obtint auprès d’autres personnes. Alors que les

transports lourds et encombrants se faisaient de préférence par bateau, connaître
la profondeur de la rivière était une information indispensable pour un bon ordon-
nancement afin d’organiser la réception des marchandises et l’expédition des produits
finis. Cela faisait plus de quinze ans que le mode de transport avait changé mais il
semble que personne ne s’était avisé d’abandonner cette mesure désormais inutile.
Fallait-il que ce jeune auditeur fasse remonter le problème, au risque de voir cette
personne tomber dans une profonde dépression car cela représentait son sujet de
fierté ? Il s’en garda mais cet exemple l’a marqué à jamais sur la nécessité de s’assurer
périodiquement de l’utilité des mesures que l’on fait.
Le froid n’est pas le même pour tout le monde

Au cours des échanges que nous avons eus sur le forum « CMMI en français » animé
par Richard Basque, l’auteur de ce livre, j’ai été sollicitée pour donner mon avis à
quelqu’un qui suivait une formation sur le traitement des exigences. Il avait à traiter
une portion d’exigences s’appliquant à un distributeur automatique de billets (exemple
bien connu de l’ATM). Il voulait savoir s’il l’avait traité correctement. Mon but n’était
pas de résoudre le problème à sa place, mais j’ai quand même profité de l’occasion pour
faire quelques remarques.
Dans les exigences qu’il avait à traiter il y avait celle-ci : le dispositif doit fonc-
tionner jusqu’à une température (basse) de – 20 ◦ C. Il en avait déduit les implications
suivantes :
Une sonde de température doit être mise en place et, lorsque la température
passe au-dessous de – 20 ◦ C, un message est affiché sur le dispositif pour informer les
éventuels utilisateurs que le dispositif n’est pas disponible.
C’est drôle mais, dans mon esprit, ce n’est pas la première conséquence à laquelle
j’ai pensé. Je me suis dit que, par – 20 ◦ C, les clients se promenaient avec des gants,
qu’il pouvait être déconseillé de les enlever (risque de rester avec les doigts collés
lorsque l’on touche quelque chose), et qu’il fallait donc que le dispositif puisse être
activé par une personne portant des gants (ce qui interdit par exemple l’emploi d’un
écran tactile).
Derrière cela, je vois immédiatement une vérification dans une chambre froide à
– 20 ◦ C pour m’assurer que le système remplit toutes ses fonctions.
Comprendre une exigence, c’est s’assurer que tous les aspects que l’on a pu
interpréter l’ont été dans l’esprit que le client en avait, et en vérifiant avec lui cette
compréhension.
Un caparaçon bien gênant

Lors de la conception d’une baie avec un calculateur, nous avons consulté notre
spécialiste en compatibilité électromagnétique.
Après examen de la baie, il a décidé que nous devions mettre en place un capot
de protection, avec le joint adéquat, le tout fixé par 40 vis sur le pourtour. La
conception a avancé, en oubliant que nous avions aussi des exigences de disponibilité
qui s’appuyaient sur un MTBF et un MTTR, le tout spécifié.
C’était une de ces approches où on ne va consulter les « maintenanciers » que
lorsque la conception est presque complètement bouclée.
Lorsque notre spécialiste en soutien logistique a vu arriver le coffre-fort, il nous a
tout simplement dit qu’il ne pourrait pas respecter le temps nécessaire à la réparation
d’un élément quelconque contenu sous le capot.
Voilà bien l’illustration qu’il faut impliquer toutes les personnes concernées,
recueillir leurs besoins, dès le début du projet, avant que des choix irréversibles n’aient
été faits.
Des passe-temps instructifs

(Illustration du mauvais déploiement des pratiques de type GP2.5.)
Au début de ma carrière, j’ai changé de chef de service. Le nouveau m’a demandé
si j’aimais faire des travaux « féminins » du type tricot ou dentelle au crochet. Je lui
répondais que oui (et oui ! on peut être ingénieur et avoir le goût pour cela) mais
lui demandais pourquoi cette question. Il m’a alors fourni les caractéristiques qu’il
associait à ce passe-temps, à la suite de quoi je n’ai plus jamais eu à rougir de ces
activités dites « féminines ».
• savoir suivre une procédure,
• avoir une bonne notion de l’avancement du travail,
• avoir de la concentration,
• avoir de la ténacité,
• avoir une vision de détail en même temps qu’une vision d’ensemble,
• être organisé pour faire cet ouvrage en même temps que de multiples autres
choses.
Je ne crois pas que les DRH fassent jamais la corrélation entre les passe-temps des
individus et leur capacité à bien tenir leur rôle. Je crois même que certains passe-temps
sont cachés, par crainte des interprétations qui pourraient y être liées. Ne cache-t-on
pas ainsi des trésors ?
Quand les « 0 » deviennent des « 1 »

(Illustration du mauvais déploiement des pratiques de type TS-SP2.3 et PI-SG 2.)
« Ah ! Si vous saviez les problèmes que nous pouvons avoir avec LES masses ! »
Je parle ici de masse électrique et masse mécanique, et des circuits correspondants
que l’on trouve dans tout produit où circule de l’électricité.
Nous avions sur notre système un dispositif pyrotechnique que nous mettions à feu
au moyen d’une étoupille. J’adore ce mot. Il vient d’étoupe, ces fibres qui servaient à
calfater les navires. Mais cette étoupille devait nous réserver des surprises car, après
son amorçage, son état n’était pas connu a priori.
Il y avait deux possibilités :
• Elle pouvait se retrouver comme circuit ouvert, et ce cas ne pose pas de problème
et peut être correctement géré.
• Elle pouvait se retrouver en court-circuit, ce qui nous a conduits à quelques
mésaventures.
Cela produisait une circulation de courant dans le circuit de masse, faisant

apparaître une référence qui devait être à zéro comme un potentiel négatif, ce qui
conduisait de facto à prendre pour un « 1 » un signal qui était à zéro.
S’il y a bien un domaine où il faut faire appel aux équipes intégration/essais, c’est
dans la conception de ce type de réseau car ils savent trouver les défauts de conception
dans ce domaine.
Ne pas se conduire en Jésuite

(Illustration du mauvais déploiement des pratiques de type RD-SP 3.5 et VAL-SP 1.3.)
Je me rappelle la consternation de notre client le jour où il a vu que, dans le cahier
des charges, il était écrit « on vérifiera si ... » au lieu de « on vérifiera que ... ».
Heureusement, nous avons pu « vérifier que ... » mais je n’ose pas imaginer dans
quel imbroglio nous nous serions retrouvés si les vérifications (du type validation selon
CMMI) n’avaient pas donné satisfaction. C’est une raison supplémentaire pour ne pas
faire confiance au verbiage dans lequel se délectent certains rédacteurs.
Les énoncés d’exigences doivent être simples, les performances limitées, les
conditions d’acceptation claires et non ambiguës.
Un vent à ne pas mettre une cible dehors

(Illustration du mauvais déploiement des pratiques de type VAL-SP 1.3.)
Toujours dans les conditions de validation, nous avons dû faire face à des difficultés
presque impossibles à résoudre.
Après avoir apporté au système une évolution destinée à augmenter des capacités,
nous avions à faire une validation avec des conditions de vent spécifiées. Savez-vous
maîtriser le vent ? Nous ne le savions pas non plus (et pourtant nous avions accepté
de telles conditions de validation !). La sortie en mer se faisait donc en fonction des
prévisions météorologiques. Combien de sorties avons-nous faites sans succès ? Je ne
sais plus. Nous devions mettre une cible en l’air pour l’essai. Cet engin qui servait de
cible amerrissait à la fin de l’essai et un canot se dépêchait d’aller le récupérer avant
qu’il n’ait coulé.
Mais, lorsque le vent souffle depuis « un certain temps », la mer se forme et il n’est
plus possible d’envoyer un canot récupérer la cible. Et, si on ne peut pas la récupérer,
on ne la lance pas.
Quel dilemme !
Je ne sais plus comment cela s’est résolu, mais je crois bien que le constructeur (nous
en l’occurrence) s’est engagé à payer l’engin en cas d’impossibilité de récupération, ce
qui a tout débloqué.
Il ne fait pas bon avoir les cheveux blancs

(Illustration du mauvais déploiement des pratiques de type CAR-SP 1.2.)
Supposez une société qui s’avise de réduire son taux de mortalité en même temps
qu’elle se préoccupe d’améliorer la qualité de vie de sa population.
L’analyse des données des causes de décès montre qu’il y a une corrélation entre
les morts de mort naturelle et la couleur des cheveux :
« Les personnes aux cheveux blancs meurent plus fréquemment de mort naturelle. »
On peut imaginer qu’un analyste recommande alors que toutes les personnes aux
cheveux blancs devraient se les faire teindre.
Ridicule ! Direz-vous car vous savez que la cause n’est pas là mais bien liée à l’âge
de ces personnes. Je vous l’accorde, l’exemple est trop caricatural, bien que souvent
utilisé.
C’est pour attirer l’attention sur la difficulté que l’on rencontre face à des monceaux
de données. On commence à les triturer, à faire des corrélations, et on risque de partir
sur la première corrélation trouvée, sans les chercher toutes et sans avoir la vision
globale.
On risque de ne plus voir que des données là où il y a des processus et des hommes.
E
CMMI-ACQ
Je profite de la 4e édition pour couvrir plus largement la famille CMMI dans ses
3 constellations : DEV, ACQ et SVC. N’ayant pas encore accumulé suffisamment
d’expérience sur le terrain avec les deux constellations SVC et ACQ, beaucoup plus
récentes que DEV, je ne peux apporter de commentaires éclairés qui seraient le fruit
de situations vécues sur chacune des pratiques, comme je l’ai fait pour DEV dans les
chapitres 6 à 10 de ce livre. Je me commenterai donc de traduire les intentions des
domaines de processus et, pour chacun d’eux, les objectifs spécifiques et les pratiques
spécifiques sous-jacentes.
Si la constellation DEV comprend les bonnes pratiques permettant d’améliorer la
maturité d’une organisation dans la façon de mener des projets de développement
(d’où son nom DEV), la constellation ACQ comprend quant à elle les bonnes
pratiques permettant d’améliorer la maturité d’une organisation dans la façon d’ac-
quérir des biens ou des services en vue de les intégrer dans son fonctionnement
organisationnel ou dans des produits ou services qu’elle développe. Soulignons que
selon l’analyse de son propre état de maturité et les décisions stratégiques qu’elle
en dérivera, une même organisation peut très bien recourir à une ou plusieurs
constellations simultanément. L’usage d’une constellation n’exclut pas le recours à
une 2e ou 3e constellation.
Comme les objectifs génériques et les pratiques génériques sous-jacentes sont
communes aux 3 constellations, il est inutile de reproduire ici leur traduction ; le
lecteur intéressé n’a qu’à lire les traductions proposées au début du chapitre 6 (pour
GG1 et GP1.1) , au début du chapitre 7 (pour GG2 et les GP2.1 à GP2,10) et au
début du chapitre 8 (pour GG3 et les GP3.1 et GP3.2).
230 Annexe E. CMMI-ACQ
Par ailleurs, la plupart des domaines de processus de DEV se retrouvent dans le

tronc commun aux 3 constellations et sont donc réutilisés dans ACQ et SVC. Il est
donc inutile de reproduire ici leur traduction ; le lecteur intéressé n’a qu’à lire les
traductions proposées dans la liste ci-dessous pour appliquer ces domaines de processus
à la constellation ACQ :
• Chapitre 7 (domaines de processus communs avec DEV et associés au niveau
de maturité 2)
– Gestion des exigences
– Planification de projet
NOTE : il y a une petite différence entre les pratiques spécifiques du premier objectif
spécifique (PP-SG1) de ACQ et DEV.
Il y a une pratique spécifique additionnelle dans ACQ et elle est décrite en premier
(PP-SP1.1) ; du coup les autres pratiques spécifiques sous l’objectif PP-SG1 dans ACQ,
toutes identiques aux correspondantes dans DEV, ont un identifiant dont le dernier
chiffre est incrémenté de 1 vs. celles de DEV.
SP1.1 Establish the Acquisition SP1.1 Établir la stratégie

Strategy d’acquisition
Establish and maintain the service Établir et maintenir la stratégie

strategy. d’acquisition.
Il y a aussi une petite différence entre les pratiques spécifiques du second objectif
spécifique (PP-SG2) de ACQ et DEV.
Il y a une pratique spécifique additionnelle dans ACQ et elle est décrite en 7e position
(PP-SP2.7) ; du coup la dernière pratique spécifique sous l’objectif PP-SG2 dans ACQ,
identique à la correspondante dans DEV, a un identifiant dont le dernier chiffre est
incrémenté de 1 vs. celle de DEV.
SP2.7 Plan Transition to SP2.7 Planifier la transition vers les

Operations and Support opérations et le support
Plan transition to operations and Planifier la transition vers les opérations

support. et le support.
CMMI-ACQ 231
– Surveillance et contrôle de projet
NOTE : il y a aussi une petite différence entre les pratiques spécifiques du premier
objectif spécifique (PMC-SG1) de ACQ et DEV. Il y a une pratique spécifique
additionnelle dans ACQ et elle est décrite en dernière position (PP-SP2.8).
SP1.8 Monitor Transition to SP2.7 Surveiller la transition vers

Operations and Support les opérations et le support
Monitor transition to operations and Surveiller la transition vers les

support. opérations et le support.
– Surveillance et contrôle de projet

– Mesures et analyse
– Assurance qualité processus et produit
– Gestion de configuration
de maturité 3)
– Focalisation sur le processus organisationnel
– Définition du processus organisationnel
– Formation organisationnelle
– Gestion de projet intégrée
– Gestion des risques
– Analyse et prise de décision
de maturité 4)
– Performance du processus organisationnel
– Gestion de projet quantitative
de maturité 5)
– Gestion de la performance organisationnelle
– Analyse causale et résolution
Il en résulte donc que dans cette annexe dédiée à la constellation ACQ, on ne

retrouve que les traductions propres à la constellation ACQ c’est-à-dire celle des
domaines de processus suivants.
• Au niveau de maturité 2
– Gestion des accords (AM)
– Développement des exigences d’acquisition (ARD)
– Sollicitation et développement de l’accord avec le fournisseur (SSAD)
CMMI-ACQ 233
– Gestion technique de l’acquisition (ATM)
– Validation de l’acquisition (AVAL)
– Vérification de l’acquisition (AVER)
CMMI-ACQ 235
CMMI-ACQ 237
CMMI-ACQ 239
F
CMMI-SVC
Je profite de la 4e édition pour couvrir plus largement la famille CMMI dans ses
trois constellations : DEV, ACQ et SVC. N’ayant pas encore accumulé suffisamment
d’expérience sur le terrain avec les deux constellations SVC et ACQ, beaucoup plus
récentes que DEV, je ne peux apporter de commentaires éclairés qui seraient le fruit
de situations vécues sur chacune des pratiques, comme je l’ai fait pour DEV dans les
chapitres 6 à 10 de ce livre. Je me commenterai donc de traduire les intentions des
domaines de processus et, pour chacun d’eux, les objectifs spécifiques et les pratiques
spécifiques sous-jacentes.
Si la constellation DEV comprend les bonnes pratiques permettant d’améliorer la
maturité d’une organisation dans la façon de mener des projets de développement
(d’où son nom DEV), la constellation SVC comprend quant à elle les bonnes pratiques
permettant d’améliorer la maturité d’une organisation dans la façon de mettre en
œuvre ou de faire la prestation de services. Soulignons que selon l’analyse de son
propre état de maturité et les décisions stratégiques qu’elle en dérivera, une même
organisation peut très bien recourir à une ou plusieurs constellations simultanément.
L’usage d’une constellation n’exclut pas le recours à une 2e ou 3e constellation.
Comme les objectifs génériques et les pratiques génériques sous-jacentes sont
communes aux 3 constellations, il est inutile de reproduire ici leur traduction ; le
lecteur intéressé n’a qu’à lire les traductions proposées au début du chapitre 6 (pour
GG1 et GP1.1), au début du chapitre 7 (pour GG2 et les GP2.1 à GP2,10) et au début
du chapitre 8 (pour GG3 et les GP3.1 et GP3.2).
242 Annexe F. CMMI-SVC
Par ailleurs, la plupart des domaines de processus de DEV se retrouvent dans le

tronc commun aux trois constellations et sont donc réutilisés dans ACQ et SVC. Il
est donc inutile de reproduire ici leur traduction ; le lecteur intéressé n’a qu’à lire les
traductions proposées aux chapitres indiqués dans la liste ci-dessous pour appliquer
ces domaines de processus à la constellation SVC. Une remarque cependant. Comme
la notion de « projet » s’applique mal à la notion d’« activité en continu » qui est
le propre de la prestation de service, le mot « projet » utilisé dans la constellation
DEV est remplacé par le mot « work » en anglais ou « travail » en français dans la
constellation SVC. Cette particularité s’applique à tous les composants du CMMI-
SVC (domaine de processus, objectifs, pratiques, etc.), y compris au nom (et au
sigle) des domaines de processus. Par exemple « Work Planning (WP) » en anglais ou
« Planification du travail » en français qu’on retrouve dans CMMI-SVC est bien le
même domaine de processus que « Planification de projet » en français qu’on retrouve
dans les constellations CMMI-DEV et CMMI-ACQ.
de maturité 2)
– Gestion des exigences
– Planification de projet (qui devient « Planification de travail » dans SVC)
– Surveillance et contrôle de projet (qui devient « Surveillance et contrôle de
travail » dans SVC)
– Gestion des accords avec les fournisseurs
– Mesures et analyse
– Assurance qualité processus et produit
– Gestion de configuration
NOTE : il y a une petite différence entre les pratiques spécifiques du premier objectif
spécifique (PP-SG1) de SVC et DEV. Il y a une pratique spécifique additionnelle dans
SVC et elle est décrite en premier (PP-SP1.1) ; du coup les autres pratiques spécifiques
sous l’objectif PP-SG1 dans SVC, toutes identiques aux correspondantes dans DEV,
ont un identifiant dont le dernier chiffre est incrémenté de 1 vs. celles de DEV.
SP1.1 Establish the Service Strategy SP1.1 Établir la stratégie de service
Establish and maintain the service strategy. Établir et maintenir la stratégie de service.
CMMI-SVC 243

de maturité 3)
– Focalisation sur le processus organisationnel
– Définition du processus organisationnel
– Formation organisationnelle
– Gestion de projet intégrée (qui devient « Gestion de travail intégré » dans
SVC)
– Gestion des risques
– Analyse et prise de décision
de maturité 4)
– Performance du processus organisationnel
– Gestion de projet quantitative (qui devient « Gestion de travail quantita-
tive » dans SVC)
de maturité 5)
– Gestion de la performance organisationnelle
– Analyse causale et résolution
Il en résulte donc que dans cette annexe dédiée à la constellation SVC, on ne

retrouve que les traductions propres à la constellation SVC c’est-à-dire celle des
domaines de processus suivants :
– Prestation de service (SD)
– Gestion de la capacité et de la disponibilité (CAM)
– Résolution et prévention d’incidents (IRP)
– Continuité de service (SCON)
– Développement du système de service (SSD)
– Transition du système de service (SST)
– Gestion stratégique du service (SSM)
CMMI-SVC 245
CMMI-SVC 247
CMMI-SVC 249
CMMI-SVC 251
Références bibliographiques
Bibliographie
R. Basque, CMMI 1.2 – Le déploiement, Réussir son parcours avec le modèle IDEAL et la
méthode SCAMPI, Dunod, 2009.
R. Basque, CMMI 1.2 – L’aide-mémoire, Les domaines de processus du CMMI-DEV,
Dunod, 2008.
M.B. Chrissis, M. Konrad, S. Shrum, CMMI : Guide des bonnes pratiques pour
l’amélioration des processus, Pearson Education, juin 2011.
K.M. Dodson, Dr. Hubert F. Hofmann, G.S. Ramani, D.K. Yedlin, Adapting CMMI
for Acquisition Organizations : A Preliminary Report, SEI, CMU/SEI-2006-SR-005,
juin 2006.
D.R. Goldenson, D.L. Gibson, K. Kost, Performance Results of CMMI-Based Process
Improvement, CMU/SEI-2006-TR-004, SEI, août 2006.
B.P. Gallagher, Interpreting Capability Maturity Model Integration (CMMI) for Operatio-
nal Organizations, CMU/SEI-2002-TN-00, SEI, avril 2002.
W.S. Humphrey, Managing the Software Process, Addison-Wesley, janvier 1989.
W.S. Humphrey, W.L. Sweet, A Method for Assessing the Software Engineering Capability
of Contractors, SEI, CMU/SEI-87-TR-23, septembre 1987.
W.S. Humphrey, Characterizing the Software Process : A Maturity Framework, SEI,
CMU/SEI-87-TR-11, juin 1987.
L. Ibrahim & all, The Federal Aviation Administration Integrated Capability Maturity
Model (FAA-iCMM), V2.0, Federal Aviation Administration, septembre 2001.
M.C. Paulk, C.V. Weber, B. Curtis, The Capability Maturity Model : Guidelines for
Improving the Software Process, Addison-Wesley, juin 1995.
Guide to the Project Management Body of Knowledge, A (PMBOK Guide), « Project
Management Institute » (PMI), ISBN 1880410230, 2000.
254 CMMI 1.3
Webographie
Dunod – Le site web sur lequel vous trouverez des compléments d’information ajoutés
par l’auteur à l’intention de ceux qui auront acheté le livre :
http://www.dunod.com
Groupe de discussion Yahoo! – L’auteur a créé un groupe pour lequel il agit comme
modérateur et qui permet de discuter du CMMI dans la langue de Molière :
http://groups.yahoo.com/group/cmmi-en-francais/
SEI – Software Engineering Institute. les pages spécifiques au CMMI sont faciles à
trouver dans
http://www.sei.cmu.edu/cmmi/index.cfm
SEIR – Software Engineering Information Repository. Contient des informations regrou-
pées commodément par thème et par domaine de processus ; il faut s’inscrire mais
c’est gratuit :
https://seir.sei.cmu.edu/seir/
Index
A assembler 128
accord avec les fournisseurs 94, 97 les composants de produit 128
actif 38 assurance qualité 150
de processus 141, 142 processus et produit 102
de processus organisationnels 137, atténuer les risques 155
140, 149, 151 au besoin 35
action corrective 73, 93, 94 audit 37, 199
adéquat 35 de configuration 108
ajusté 34, 43, 112, 113
allouer les exigences 118
alternative solutions 121, 158 B
amélioration
aux processus 138 base de données 38
continue 179, 184 basique 34
continue et progressive 198 benchmarking 45
mesurable 179 bénéfice 65, 189
analyse besoin
causale 171, 173, 174 de formation 146
causale et résolution 173 stratégique de formation 145
de performance 165 bibliothèque 38
analyser
des actifs processus 143
les données 133
biens livrables 37
les résultats 134
boucle
approche incrémentielle 175
approprié 35 d’amélioration 172
aptitude 33, 145 d’amélioration continue 183
arbitrage 151, 152 de rétroaction 141
artefact 205 breakthrough 175
assemblage 126 budget 83
256 CMMI 1.3
C couverture 128
calendrier 83 critère
capacité de formation 146 de sélection 122
organisationnelle 145 et les lignes directrices 142
capital processus 114, 139, 141 criticité des risques 155
capitalisation 21, 81, 111, 112, 115, 137, cycle
140, 147, 148, 151 d’amélioration 183
CAR 173 de vie 38, 82, 142
catégorie de risque 153
cause
à l’origine des défauts 174 D
commune de variation 171 DAR 156
des défauts 173
découpage de haut niveau 81
première 173
défaut 174
spéciale de variation 162
définition
CBA IPI 5, 37
de mesure 165
changement drastique 175
chef de projet 30, 32, 70 des exigences 76
chemin critique 152 des fonctionnalités 119
client 36 des interfaces 128
CM 105 du processus organisationnel 141
CMMI 6, 38 demande 66
domaines de processus 47 de modification 76, 78, 107
modèle 41 description d’interface 128
CMMI-ACQ 7 design 121
CMMI-DEV XII, 7 DEV 42
CMMI-SVC 7 développement des exigences 116
CobiT 13 direction 66, 74
compatibilité des interfaces 129 directive 68
compétences 86 discipline 41
composant de produit 123
discipliné 21, 34, 43, 65
concept d’emploi 119
dispenser la formation 146, 147
conditionner le produit 129
documentation de soutien au produit 125
confirmer avant l’assemblage 128
domaines de processus 33, 47
connaissance 86, 145
constellation 42 représentation continue XVI
continue 22, 42 représentation étagée XV
contrôle statistique 161, 162 sigles XIV
contrôler 73 table de référence XVII
coordination 151, 152 donnée historique 112, 143
coordonnateur logistique 184 capitalisée 164
courriel XXV due diligence 199
Index 257
E focalisation sur le processus

organisationnel 137
échelle de maturité 33
formation 71, 150
efficacité de la formation 147
organisationnelle 145
élaboration 55
formulation des exigences 76
élément de configuration 106
fournisseur 36
en optimisation 35, 43
fournisseur de potentiels (sélection) 199
engagement 87, 89, 91
enregistrement de gestion de
configuration 108 G
enregistrer les données 175 gabarit 197
ensemble de données techniques 123 gérer 150
entente avec les fournisseurs 96, 97 le déploiement 179
environnement le projet 150
cible 135 le projet quantitativement 167
d’intégration de produit 126 statistiquement 168
de validation 135 gestion
de vérification 132 de configuration 72, 105, 150
EPG 137 de projet intégrée 147
estimation 81, 149, 166 de projet quantitative 166
établir des accords avec les fournisseurs 94
et maintenir 35 des données 85, 92
un plan de formation tactique des exigences 75, 76
organisationnel 146 des risques 152
étagée 22, 23, 42 du risque 150, 153
évaluation 37 quantitative 21, 35, 43, 162–164,
de processus 137 167
externe 37 statistique 168
interne 37 gestionnaire 31
évaluer GG2 67
les processus de l’organisation 138 GP2.n 67
les risques 155 groupe 32
exigence 76 de soutien aux processus 137
client 116, 117 guide d’adaptation 143
d’interface 118
des produits 76 H
produit 117, 118 Humphrey Watts 3
expliciter les besoins 117
externalisation 199
I
iCMM 11
F identifier les risques 155
faire, acheter ou réutiliser 124 IEEE/EIA 10
258 CMMI 1.3
immature 65 M
immaturité organisationnelle 19 MA 98
impact manager 31
mesurable 175 maturité organisationnelle 17, 20
sur la qualité 194 membre d’équipe d’évaluation 184
sur la satisfaction des clients 194 mesure 168
sur les coûts 193 mesurer 65
sur les délais 194 les effets de l’amélioration 179
impartition 199 méthode 38
implémentation 121 de validation 135
implémenter de vérification 131
la conception 125 développement 82
les activités d’amélioration de standard 142
processus 139 méthodologie de développement 82
implication des parties prenantes 92, 151 métiers 41
incohérence 76, 79 mettre en œuvre 124
incomplet 33 mode préventif 174
indicateur de déploiement de pratiques modèle 164
205 de performance de processus 166
innovation et déploiement modification
organisationnels 175 aux exigences 78
institutionnalisation 50, 67 aux produits de sortie 107
intégration de produit 125, 126
intégrer les plans 149, 150
intégrité 108 N
IPM 148 nécessaires et suffisantes 120
ISO/IEC 10 niveau
ISO/IEC 15504 10, 42 ajusté 34
ISO12207 11 basique 34
ITIL 12 d’aptitude du domaine de processus
33
de maturité 33, 43
K discipliné 34
Kaizen 175 en optimisation 35
géré quantitativement 35
incomplet 33
L niveau 0 33, 59
leçon apprise 112 niveau 1 21, 34, 59, 60
ligne directrice pour la personnalisation niveau 2 21, 34, 63, 64
38 niveau 3 21, 34, 111
livrer 128 niveau 4 21, 35, 161
le produit 129 niveau 5 21, 35, 171
Index 259
niveau de services 199 périmètre de l’évaluation 184

niveau Initial 21 personnalisation 21
non-conformité 104 personnalisé 21
note explicative 48 PI 125
PII 185, 205
O plan 80, 147
d’action processus 139
objectif 49, 50
d’amélioration 197
d’affaire 138
d’atténuation du risque 156
de mesure 99
de gestion de configuration 106
de qualité et de performance de
processus 177 de projet 76, 83
du processus 138 de réduction du risque 155
du projet 167 du processus 70
générique 50 intégré 150
quantitatif 161, 164 planification de projet 79, 149
spécifique 50 planifier
objectivité 103 le déploiement 179
occasion d’amélioration de processus 137 les activités d’amélioration de
OPD 141 processus 139
OPF 137 PMBOK 13
OPM 175 PMC 90
OPP 163 point à traiter 133
optimisation 21 PP 80
continue 171 PPQA 102
organisation 30, 42 pratique 49, 52
organisationnel 142 générique 52, 55, 64
OT 145 spécifique 52
outsourcing 199 préparer
la vérification 131
P les revues par les pairs 133
P-CMM 5 pour la validation 135
paramètre prestataire 36
de planification de projet 81, 91 prévention des défauts 173
de risque 154 priorité d’action d’amélioration 137
parties prenantes procédure
concernées 37, 64, 72, 89, 148, 151, d’analyse 101
152 de collecte et de stockage 100
performance et les critères d’intégration de
du processus 164, 175 produit 127
du processus organisationnel 163 et les critères de validation 136
du projet 169 et les critères de vérification 132
260 CMMI 1.3
processus 150 résultat de validation 136

ajusté 38, 67, 113, 114, 166, 167 retour
intégré et personnalisé 148 d’expérience 151
normalisé de l’organisation 166 sur investissement 194
organisationnel 38 revue
organisationnel standard 114 d’avancement 92
personnalisé 38 de pairs 132, 133
personnalisé pour le projet 148 sur jalons 93
stabilisé 171 risque 84, 92, 154
standard au niveau de l’organisation rôle 71
148 RSKM 153
produit 37
d’activité 37, 76 S
d’activité typique 53
SA-CMM 5, 12
de sortie 72
SAM 95
projet 30
Sarbanes-Oxley ou SOX 13
proposition
SCAMPI 14, 37, 181, 198, 207
d’action 174
SCE 5, 37
d’amélioration 178
SE-CMM 5
SEI XII, XIII, 4
Q sélectionner les sous-processus 168
QPM 166 séquence d’intégration 126
quagmire 9 service 37
qualité des produits 164 seuil 150
Software Engineering Institute XIII
solution
R de composants de produit 121
RD 116 de produit 121
réduction des risques 154 technique 121
référence entre domaines de processus 49 source de risque 153
référentiel 106, 198, 199 sous-pratiques 54
de performance de processus 164, SPA 5
165 SPICE 10, 42
régler les problèmes de coordination 152 sponsor 183
représentation 32 stabilisation 168
continue 44, 45 stakeholders 37
étagée 42, 45 stratégie
REQM 76 de gestion du risque 154, 155
responsabilité 71 de vérification 131
ressource suivre 73
adéquate 70 surveillance et contrôle de projet 90
du projet 85 SW-CMM 5, 29
Index 261
SWEBOK 41 V
système de gestion de configuration 106 VAL 135
validation 134, 136
valider
T le produit 136
les exigences 121
technique d’analyse 168
VER 130
traçabilité 120 vérification 130, 134
TS 121 de bon fonctionnement 126
type d’acquisition 96 et validation 129
vérifier les produits de sortie 134
U W
utilisateur 36 WBS 81

Untitled

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Untitled

Transféré par

Droits d'auteur :

Formats disponibles

978-2-10-056580-1

Préface à la 1re édition (écrite à propos de la version 1.1 de CMMI)

Préface à la 2e édition (écrite à propos de la version 1.2 de CMMI-DEV)

Lors de la parution de la 2e édition

Lors de la parution de la 3e édition

Lors de la parution de la 4e édition

Note sur les copyrights

CM Support 2 Gestion de configuration Configuration Management 105

MA Support 2 Mesure et analyse Measurement and Analysis 98

PI Product Eng. 3 Intégration de produit Product Integration 125

PP Project Mgmt 2 Planification de projet Project Planning 80

Gestion de projet Quantitative Project

REQM Project Mgmt. 2 Gestion des exigences Requirements Management 75

TS Product Eng. 3 Solution technique Technical Solution 121

Table des domaines de processus du CMMI-DEV dans la représentation étagée

2 Project Mgmt PP Planification de projet Project Planning 80

Gestion des accords Supplier Agreement

Assurance-qualité Process and Product

3 Product Eng. TS Solution technique Technical Solution 121

Gestion de projet Integrated Project

3 Project Mgmt. RSKM Gestion des risques Risk Management 152

Table de référence dans la représentation continue (par catégorie de processus)

Performance du processus Organizational Process

Product Eng. 3 TS Solution technique Technical Solution 121

Project Mgmt 2 PP Planification de projet Project Planning 80

Gestion des accords Supplier Agreement

Project Mgmt. 3 RSKM Gestion des risques Risk Management 152

Assurance-qualité Process and Product

Analyse causale Causal Analysis

Table de référence par ordre alphabétique du nom de domaine de processus en anglais

Configuration Management CM Gestion de configuration Support 2 105

Integrated Project Gestion de projet

Measurement and Analysis MA Mesure et analyse Support 2 98

Process and Product Quality Assurance-qualité

Product Integration PI Intégration de produit Product Eng. 3 125

Project Planning PP Planification de projet Project Mgmt 2 80

Requirements Management REQM Gestion des exigences Project Mgmt. 2 75

Technical Solution TS Solution technique Product Eng. 3 121

Préface de Mike Konrad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VII

Préface de Mike Phillips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IX

Chapitre 1 – La genèse d’un modèle de meilleures pratiques . . . . . . . . . . . . . . . . . . . . 1

Chapitre 2 – L’étoile CMMI dans la galaxie des modèles . . . . . . . . . . . . . . . . . . . . . . . . 9

Chapitre 3 – Une échelle de maturité organisationnelle . . . . . . . . . . . . . . . . . . . . . . . . 17

Chapitre 4 – Terminologie particulière au CMMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Chapitre 5 – L’architecture du modèle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5.2.2 Intention, notes explicatives et références . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Chapitre 6 – Les niveaux 0 et 1 : des cas très particuliers . . . . . . . . . . . . . . . . . . . . . . 59

Chapitre 8 – Le niveau 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Chapitre 9 – Le niveau 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

Chapitre 10 – Le niveau 5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

Chapitre 11 – Un cas concret . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

Chapitre 12 – Les bénéfices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

Chapitre 13 – Utilisations possibles du CMMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

Annexe A – Indicateurs des pratiques du CMMI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205

Annexe B – La pénétration du CMMI dans le monde . . . . . . . . . . . . . . . . . . . . . . . . . . . 207

Annexe C – Les « certifications » du SEI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209

Annexe D – « Histoires vécues » et autres histoires . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215

Annexe E – CMMI-ACQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229

Annexe F – CMMI-SVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241

Références bibliographiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253

et à la réactivité d’un ex-collègue (merci Denis Bistodeau) membre du ministère

Certains mots prennent un sens bien particulier dans le contexte spécifique du

Sans révéler de noms, et en amalgamant plusieurs expériences du terrain chez

Merci Pierre-Yves et Jean-Luc