CMMI (Capability Maturity Model Integration)
7 août 2006
J'ai dit ici ce que j'ai compris de CMMI[1] afin de faire ressortir ses apports comme ses limites. Je serai reconnaissant à ceux qui, comme l'ont fait MM. Didier Dulac et Jacques Printz, voudront bien m'indiquer les corrections et compléments qui leur semblent nécessaires pour améliorer cette analyse, qui s'appuie sur une lecture critique de la documentation sur CMMI. Le mot critique doit être pris ici non au sens de dénigrement qu'on lui attribue dans le langage courant, mais au sens technique et précis de délimitation : il s'agit de délimiter ce que CMMI apporte, ce qui implique d'indiquer ce qu'il n'apporte pas.
Jacques Printz m'a fait observer que la toile de fond d'une telle lecture ne serait pas la même pour un Américain ou pour un Français car les normes IEEE, la méthode de conduite de projet PMBOK, le modèle d'estimation de coût COCOMO etc. font partie du bagage de tout professionnel américain alors qu'ils sont moins bien connus en France. Ainsi, dit-il, ce qui m'est apparu comme des lacunes de CMMI n'en serait pas pour un Américain car il s'agit de choses qui, pour lui, sont évidentes et vont de soi.
Jacques Printz m'a conseillé de bien séparer la description du commentaire. J'ai donc mis les commentaires sur un fond jaune, comme celui qui se trouve sous le présent paragraphe.
* *
CMMI considère la réalisation des projets, mais ce n’est pas une méthode de conduite de projet : CMMI est une démarche qui vise à porter l’entreprise au niveau de compétence (ou maturité) qui lui permettra de réaliser correctement ses projets, ce qu’indique d’ailleurs exactement l’expression « capability maturity model ».
La réalisation des projets est, parmi les thèmes relatifs aux systèmes d’information, celui qui fait couler le plus d’encre et occupe le plus de place dans certains cours et formations. Certes ce thème est important puisque beaucoup de projets échouent (cf. les statistiques que publie le Standish Group (De l’Informatique, p. 454), mais peut-être n'est-il pas le plus important. On peut en effet estimer que :
- pour un système d'information le plus important ne réside pas dans les projets, qui visent à le faire évoluer, mais dans la bonne utilisation des ressources qu’il offre ;
- parmi les décisions qui conditionnent le succès d’un projet, les plus cruciales se trouvent en amont (délimitation du projet, qualité des spécifications) et aussi en aval (formation des utilisateurs, animation du bon usage du produit).
La réalisation des projets est cependant le thème qui se prête le mieux à des recettes, à des méthodes, à la rigueur formelle, alors qu’il est sans doute plus difficile d'énoncer les règles qui permettent d’atteindre l’alignement stratégique, la qualité sémantique, la solidité de l’architecture.
Nota Bene : Je vais devoir ici énumérer des acronymes, car c'est ainsi que l'on désigne les normes, guides et recommandations. Que l'on veuille bien pardonner la lourdeur qui en résulte dans cet historique !
CMMI[2] a été conçu par le DoD (Department of Defense) américain pour répondre aux fréquents problèmes de qualité survenus dans l’ingénierie des logiciels et pour mieux maîtriser les coûts et les délais.
Le SEI (Software Engineering Institute) a été créé à cette fin en 1984 et l’université Carnegie Mellon a été choisie pour l’héberger. L’équipe a été dirigée par Watts Humphrey, qui avait été chez IBM responsable du système d'exploitation MVS de l'IBM 360 et qui publiera notamment Managing the Software Process (Addison-Wesley 1989).
Le SEI a publié en 1988 la méthode SCE (Software Capability Evaluation), en 1990 la méthode SPA (Software Process Assessment), en 1991 la version 1.0 du SW-CMM (Capability Maturity Model for Software), enfin en 2000 les méthodes CMMI et SCAMPI (Standard CMMI Appraisal Method for Process Improvement) qui sont l’aboutissement des travaux antérieurs.
CMMI est l’héritier de SW-CMM. D’après Richard Basque (CMMI, Dunod 2004), CMMI est parent d’ISO 9001 et il est équivalent à ISO/IEC 15504 (SPICE). Il comporte le cycle de vie défini par la norme ISO 12207.
PMBOK (Guide to the Project Management Body of Knowledge), mis au point par le PMI (Project Management Institute), est contrairement à CMMI une méthode de conduite de projet. Les deux guides pourraient converger utilement.
SA-CMM, mis au point par le SEI, concerne la gestion des achats. Il sera vraisemblablement intégré dans la version 2.0 de CMMI.
iCMM (Integrated Capability Maturity Model) de la FAA (Federal Aviation Administration) équivaut à l’ensemble formé par CMMI et SA-CMM.
SCAMPI, conçu lui aussi par le SEI[3], sert à évaluer la maturité d’une entreprise en regard de CMMI.
La compétence que considère CMMI est celle de l'entreprise tout entière, de l'organisation, et non celle des individus. L'efficacité résultera de la conjonction de la compétence de l'organisation et de la compétence des individus.
CMMI classe les tâches que l’on doit accomplir pour réaliser un projet selon une liste de 25 « domaines de processus » (process area, que nous appellerons ici « processus » tout court). Je proposerai une traduction en français de l’intitulé de chaque processus.
A chaque processus CMMI associe une intention (purpose) et des notes explicatives (introductory notes) ainsi qu’une liste des autres processus qui sont en relation avec lui (related process area). Puis il détaille le contenu du processus selon la structure que nous décrirons ci-dessous.
Observons qu’ici le mot « processus » n’a pas le même sens que celui qu’il a lorsque, dans la démarche d’urbanisation du système d’information, on dit que l’on identifie puis modélise le processus de production de chacun des produits (final ou intermédiaire) de l’entreprise. Dans CMMI, la liste des processus est une classification des tâches que comporte un projet.
L’ensemble des processus est lui-même classé selon deux présentations correspondant chacune à une démarche particulière :
- dans la présentation continue (continuous representation), les processus sont regroupés en quatre grandes catégories : gestion de processus, gestion de projet, ingénierie, support. Si l’on suit la démarche à laquelle cette représentation correspond, on attribuera à une entreprise une note dans chaque grande catégorie de processus et on y suivra ses progrès séparément ;
- dans la présentation par étapes (staged representation), on évaluera de façon globale la maturité de l’entreprise, depuis le niveau 1 qui est le plus bas jusqu’au niveau 5 qui est le plus élevé. Être qualifiée au niveau 2 ou au niveau 3, c’est pour une entreprise comme acquérir un diplôme : une SSII ainsi qualifiée sera considérée comme un fournisseur fiable. CMMI invite l’entreprise à parcourir les cinq niveaux dans l’ordre pour améliorer la façon dont elle réalise ses projets : il faut se rappeler que, comme le disait C. A. R. Hoare, l'optimisation prématurée est la racine de tous les maux [4].
Dans notre description de CMMI nous suivrons l’ordre de la présentation par étapes car c'est celle semble la plus utilisée en pratique. Nous nous interrogerons sur la pertinence de la progression chronologique ainsi proposée.
Pour décrire chacun des 25 processus, CMMI les détaille en objectifs (goals), puis en pratiques (practices), enfin en produits (typical work products). Chacun des éléments de ces listes comporte une définition, des commentaires et éventuellement des informations complémentaires (sous-pratiques etc.).
Selon un vocabulaire
malencontreux mais courant, CMMI distingue dans ce que fournit le projet des
produits et des services (products and services) alors qu’il aurait mieux
valu parler de biens et services (goods and services), puisque ce sont tous
également des produits (voir
Parmi les objectifs, CMMI distingue des « objectifs généraux » (generic goals), que l’on retrouve dans tous les processus, et des « objectifs particuliers » (specific goals) propres à un seul processus. La description d'un processus obéit donc à la structure arborescente ci-dessous :
Cette structure a l’avantage de la simplicité mais elle ne facilite pas la mise en évidence de l’importance relative des divers processus, pratique et produits.
Toute classification comporte une part de convention et l’on ne peut pas être certain que deux équipes différentes, usant des mêmes critères, seraient parvenues à la même nomenclature : mais si c’est là un inconvénient, il est mineur en regard de l’ordre que la classification procure dans les idées et dans la documentation.
Par contre il est nécessaire, lorsqu’on rencontre une classification, de connaître les critères qui ont conduit à classer sous une même rubrique tel sous-ensemble d’éléments. Or CMMI n’indique pas les critères qu’il a utilisés, comme si la nomenclature qu’il fournit était « naturelle » et évidente.
Par ailleurs, il ne donne pas d’indication sur la qualité des documents à élaborer ni sur la façon dont cette qualité peut être contrôlée. Or dans la documentation d’un projet ou d’un logiciel on rencontre souvent des textes incompréhensibles : le projet a produit les documents que la méthode exige, mais n’a pas obéi à son esprit puisqu’ils sont inutilisables.
D’un processus à l’autre, les objectifs généraux sont à peu de chose près les mêmes : organiser la planification du processus, puis le planifier effectivement ; lui fournir les ressources nécessaires ; définir et affecter les responsabilités ; former ses acteurs ; construire puis gérer sa documentation ; identifier et impliquer les parties prenantes ; le conduire et le maîtriser (monitor and control) ; évaluer son exécution ; enfin, rendre compte aux dirigeants.
Cette liste a le mérite de rappeler des évidences : il arrive, dans la pratique, que l’on évoque à la cantonade une tâche sans désigner celui qui en sera chargé, qu’on le désigne mais néglige de lui attribuer les moyens nécessaires, que certaines parties prenantes ne soient pas impliquées, que l’exécution ne soit pas évaluée etc.
Chacun des objectifs généraux est décliné dans chaque processus par copier-coller, la seule modification portant sur l’intitulé du processus.
Parfois la description manque de précision : ainsi dans le processus « ingénierie des exigences » les objectifs « désigner les responsables » et « identifier et impliquer les parties prenantes » sont mentionnés, mais sans que CMMI ne précise le partage des rôles entre le fournisseur et le client (maîtrise d’œuvre et maîtrise d’ouvrage) dans la validation des exigences auxquelles le projet doit répondre. Or ce point-là est crucial…
Un objectif comme « définir les responsabilités » s’explicite, dans certains processus, par la rédaction d’un contrat qui précise les engagements mutuels des parties prenantes et identifie les responsables.
CMMI ne fournit pas de contrat-type et n’indique pas l’identité des signataires, autre point crucial.
Pour « conduire et maîtriser » le processus, il est utile de disposer d’un tableau de bord. L’expérience montre que les tableaux de bord sont souvent fallacieux. CMMI n’indique pas comment construire un tableau de bord correct. Pour « rendre compte aux dirigeants » la pratique enseigne – mais CMMI ne le dit pas – qu’il vaut mieux présenter le compte rendu sous forme de séries chronologiques que sous forme d’alertes symbolisées par des feux de signalisation ou autres procédés. CMMI précise cependant – et c’est là une excellente chose – qu’il faut suivre l’exécution des décisions.
Les cinq niveaux de la présentation par étapes servent à qualifier la gestion des projets dans une organisation (dans CMMI, ce mot désigne indifféremment une entreprise ou une entité – direction, service – au sein d’une entreprise, bref une « personne morale ». Pour simplifier, nous utiliserons ci-dessous le mot « entreprise »).
Le niveau 1, ou niveau initial, c’est celui des entreprises qui ne gèrent pas leurs projets. Les processus sont chaotiques, le succès ne peut être obtenu que par un effort héroïque, budgets et calendriers sont souvent dépassés. Ce niveau a le numéro 1 qui, aux Etats-Unis, désigne le rez-de-chaussée d’un immeuble : c’est le ras du sol.
L’entreprise qui est au niveau 2 (managed) sait gérer les exigences, planifier et gérer un projet, répartir le travail entre les parties prenantes.
L’entreprise qui est au niveau 3 (defined) sait capitaliser l’expérience acquise d’un projet à l’autre et dispose d’une méthode standard pour gérer ses projets. Ce niveau comporte en outre des processus relatifs à l’amont et l’aval de la réalisation.
L’entreprise qui est au niveau 4 (quantitively managed) sait associer des indicateurs quantitatifs aux processus clé de chaque projet et prendre des mesures correctrices si ces indicateurs font apparaître une dérive.
L’entreprise qui est au niveau 5 (optimized) s’engage dans un cycle continu d’amélioration de ses méthodes.
CMMI part ainsi de ce qui se passe lors de la réalisation d’un projet (niveau 2), puis s’élargit vers l’amont et l’aval (niveau 3) pour approfondir enfin la maîtrise quantitative puis qualitative de sa méthode (niveaux 4 et 5).
Le passage d’un niveau à l’autre n’est pas aisé : d’après les statistiques que publie le SEI, il faut à de 18 à 30 mois pour « décoller » du niveau 1 et atteindre le niveau 2, puis encore de l’ordre de deux ans pour passer au niveau 3.
La description du niveau 1 ne serait qu’une énumération de mauvaises pratiques : nous commencerons donc par l’examen du niveau 2.
Pour être au niveau 2, l’entreprise doit maîtriser sept des 25 processus :
Gestion des exigences (Requirements
Management)
Planification du projet (Project Planning)
Conduite et maîtrise du projet (Project Monitoring and Control)
Gestion des achats (Supplier Agreement Management)
Production et analyse des indicateurs (Measurement and Analysis)
Assurance qualité des processus et des produits (Process and Product Quality
Assurance)
Gestion de configuration (Configuration Management)
Une entreprise qui se trouve au niveau 2 saura : (1) enregistrer et suivre les modifications du cahier des charges demandées par le client durant la réalisation du projet ; (2) produire des estimation argumentées de coût et de délai, planifier l’exécution et négocier les engagements des intervenants ; (3) produire à cadence régulière des rapports d’avancement fidèles à la réalité ; (4) proposer et suivre des actions correctrices en cas de dérapage des délais, du budget ou de l’utilisation des ressources.
Le niveau 2 contient ce qu’il faut pour réaliser un projet une fois que l’on a défini ce que l’on voulait faire.
Il n’y est pas question d’urbanisme, d’alignement stratégique, de qualité de la formulation des exigences : CMMI suppose ces questions-là déjà traitées, il ne s’interroge pas sur la pertinence de l’expression de besoin, sa sobriété ou sa cohérence mais se limite à organiser la réalisation.
Il ne mentionne pas non plus le rôle que l’expression de besoins, texte court en langage naturel, doit tenir durant la réalisation du projet : or il faut donner à celle-ci une place bien en vue dans la documentation. Un grand projet abonde en complications qui risquent de faire perdre de vue son but : le sens des priorités et des proportions ferait alors défaut quand il faudra prendre des décisions en cours de route. Il est utile alors de pouvoir se référer à l’expression de besoins initiale.
Par « gestion des exigences », CMMI entend la gestion de la cohérence entre les exigences et les produits de sortie du projet, le fait que les exigences soient bien comprises par les parties prenantes et que celles-ci s’engagent à les satisfaire, enfin la gestion des modifications apportées aux exigences en cours de projet.
Cependant comme à ce stade les critères de qualité des exigences n’ont pas été mentionnés le niveau 2 de CMMI reste muet sur la façon dont on arbitrera en cours de projet – lorsqu’il faudra par exemple, pour satisfaire des exigences nouvelles sous la contrainte de délai ou de budget, sacrifier certaines exigences initiales.
Il est étonnant que l’on évoque la gestion des exigences au niveau 2 alors que l’ingénierie des exigences (ainsi que celle de la solution technique qui doit les satisfaire) est reportée au niveau 3. Ainsi une entreprise certifiée au niveau 2 saurait gérer les exigences une fois celles-ci formulées, mais ne saurait pas comment les formuler !
Il s’agit de définir les variables qui permettent de mesurer l’avancement du projet, après avoir éventuellement découpé celui-ci en phases, et d’estimer chemin faisant les coûts et délais restants prévisibles. L’accent est mis sur le caractère rationnel des évaluations (elles doivent être quantitatives, on doit pouvoir les justifier et les expliquer). Un plan de projet permettra de suivre la consommation du budget et le calendrier de réalisation. Les risques, les ressources et les connaissances nécessaires doivent être gérés. Les parties prenantes doivent être impliquées et informées, notamment les responsables de ceux des autres projets avec lesquels le projet considéré est en relation.
On ne trouve pas dans CMMI la recommandation de découper la livraison en lots exploitables pour éviter l’« effet tunnel » et tirer parti, en cours de réalisation, des indications fournies par de premiers utilisateurs. CMMI ne met pas en garde non plus contre les difficultés logistiques que comporte l’organisation des réunions avec des parties prenantes qui ont d’autres priorités.
Il s’agit de suivre l’évolution du projet selon le schéma construit lors de sa planification. Les décisions prises en cours de route (corrective actions) sont définies et gérées.
C’est là un point important : il arrive trop souvent, dans l'entreprise, que des décisions soient ignorées ou indéfiniment remises en cause.
Les fournisseurs sont choisis à partir d’une évaluation de leurs aptitudes (sans doute en s’appuyant sur SCAMPI). Un contrat est passé avec chaque fournisseur, précisant les engagements mutuels entre le client et lui. Enfin, le produit du fournisseur doit être intégré dans l’architecture du système d’information et les équipes de l’entreprise doivent être formées aux techniques particulières le concernant.
La présence de ce dernier point, certes justifié, surprend dans le niveau 2 puisque la prise en considération des contraintes propres à l’architecture technique de l’entreprise relève du niveau 3.
Les indicateurs dont il s’agit sont ceux relatifs à l’avancement du projet et non au fonctionnement du produit une fois qu’il aura été mis entre les mains des utilisateurs (ce fonctionnement n’est pas pris en compte par CMMI).
Il est indiqué qu’il faut « spécifier la façon dont les données seront analysées et diffusées ». Mais CMMI ne donne ici aucune indication sur la façon de s’y prendre. Il faut arriver au niveau 4 pour découvrir les techniques statistiques qu’il suggère, et qui posent d’ailleurs quelques problèmes (voir ci-dessous).
Il s’agit de vérifier que les processus et les produits sont conformes aux normes et aux exigences.
La vérification des produits fait apparaître des anomalies (noncompliance issues). Celles-ci doivent être identifiées, qualifiées, et leur correction doit faire l’objet d’un suivi.
Parmi les divers indicateurs, celui qui rend compte de la convergence de la correction des anomalies est l’un des plus précieux : si l’on voit que le nombre d’anomalies à corriger ne décroît pas ou même augmente, il convient de s’interroger sur la qualité de la réalisation, sur la solidité de l’architecture sous-jacente. CMMI n’insiste pas assez, me semble-t-il, sur l’importance de cet indicateur.
Ce processus consiste à identifier et décrire les produits que le projet doit fournir : il faut donc en construire le référentiel (définition des identifiants et des attributs), puis alimenter et tenir à jour la description des produits – et le référentiel lui-même, en cas de changement.
Le « référentiel » dont il s’agit ici n’est donc pas celui de l’application que le projet vise à mettre entre les mains des utilisateurs (avec la définition des données, objets etc. que cette application traitera) mais seulement celui des produits du projet.
La construction du référentiel de l’application (modèle conceptuel de données si l’on est merisien, modèle UML en modélisation par objets) n’est évoquée nulle part dans CMMI.
Pour être au niveau 3, l’entreprise doit maîtriser les sept processus du niveau 2 et, en outre, quatorze autres processus (soit en tout 21 des 25 processus) :
Expression des besoins (Requirements
Development)
Solution technique (Technical Solution)
Intégration du produit (Product Integration)
Recette technique (Verification)
Recette fonctionnelle (Validation)
Gérer l’organisation des processus (Organizational Process Focus)
Définition de l’organisation (Organizational Process Definition)
Formation à l’organisation (Organizational Training)
Gestion multidisciplinaire de projet (Integrated Project Management for IPPD)
Gestion des risques (Risk Management)
Gestion d’une équipe intégrée (Integrated Teaming)
Intégration de la gestion des achats (Integrated Supplier Management)
Méthode de prise de décision (Decision Analysis and Resolution)
Organisation de l’intégration (Organizational Environment for Integration)
On trouve ainsi dans ce niveau
une accumulation de choses que l’on peut regrouper sous les thèmes suivants :
- l’ingénierie des exigences, de l’expression des besoins aux spécifications et
à la recette ;
-
le perfectionnement de la gestion de
projet ;
- la « personnalisation » de la gestion de chaque projet et la capitalisation de
l’expérience d’un projet à l’autre ;
- les méthodes de prise de décision.
Notre commentaire portera sur ces regroupements de processus.
Ce thème recouvre les processus Requirements Development, Technical Solution, Product Integration, Verification et Validation.
CMMI ne parle pas de ce que l’on appelle « gestion du portefeuille de projets ». Or cette gestion est susceptible de comporter des erreurs : on n’aura pas par exemple regroupé des projets qui se conditionnent mutuellement ou qui s’enchaînent dans le temps (certaines entreprises délimitent un projet pour le développement d’un produit, puis un autre pour sa vérification d’aptitude, un autre pour son déploiement, un autre encore pour la formation de ses utilisateurs…). CMMI suppose donc les projets convenablement délimités a priori.
Ce thème recouvre les processus Integrated Project Management for IPPD, Risk Management, Integrated Teaming, Integrated Supplier Management et Organizational Environment for Integration.
On rencontre ici des choses qui font classiquement partie de toutes les méthodes de conduite de projet, et l’on retrouve des choses qui nous sont familières : explication des exigences (to elicit needs), spécifications générales (customer requirements et product requirements), validation des spécifications, spécifications détaillées (technical solution) et spécifications techniques (technical data package), qui aboutissent à ce que nous appelons un cahier des charges. Ensuite viennent la réalisation, le codage proprement dit (implementation) et la rédaction de la documentation destinée à l’utilisateur, puis enfin l’intégration, l’assemblage, la livraison, la vérification.
CMMI dit que les spécifications doivent être validées, mais il n’indique pas qui doit faire cette validation. S'il s’agit de s’assurer que les spécifications répondent bien aux besoins des utilisateurs la responsabilité de leur validation appartiendra à la maîtrise d’ouvrage (à l’exception de la solution technique, qui relève de la maîtrise d’œuvre). L’expérience montre combien il est difficile de présenter les spécifications de telle sorte que l’on puisse obtenir, de la part de la maîtrise d’ouvrage, une validation authentique (c’est-à-dire une validation qui engage véritablement son expertise professionnelle et sa responsabilité).
On ne voit pas apparaître dans CMMI les étapes de modélisation (MCD ou UML) pourtant nécessaire pour assurer la qualité sémantique des données et des référentiels ; les revues de pairs (peer reviews) sont, étrangement, mentionnées après la livraison du produit alors qu’elles sont surtout utiles lors de la conception de la solution.
CMMI consacre plusieurs processus à la gestion d’une équipe intégrée, à la relation avec les fournisseurs etc. Les responsabilités doivent être clairement définies, la communication doit être assurée entre les diverses composantes de l’équipe etc.
Il serait utile d’insister ici sur le commerce de la considération, si utile à la bonne réalisation des grands projets, et qui peut se décliner en règles très simples (anticiper les problèmes et les régler à froid par production et publication d’indicateurs ; interdire le dénigrement des personnes absentes, etc.). Il ne suffit pas d’évoquer des incentives.
Ce thème recouvre les processus Organizational Process Focus, Organizational Process Definition et Organizational Training. Les leçons acquises lors de la réalisation des projets, les documents types, les statistiques, sont stockés dans une documentation afin de faciliter la capitalisation des méthodes et compétences d’un projet à l’autre. Cela facilite la personnalisation de la gestion de chaque projet : pouvant accéder à la mémoire de l’entreprise, le chef de projet sera en mesure de définir sa propre méthode.
Ces recommandations sont salubres. Cependant, dans les faits, leur application rencontrera des résistances – sauf, peut-être, dans les SSII qui étant impliquées dans de très nombreux projets ont tout intérêt à capitaliser sur leurs outils et documents. Dans la plupart des entreprises, même très grandes, on préfère à la fin d’un projet oublier ce qui s’est passé lors de son déroulement et « laisser les cadavres dans les placards ».
Rien n’est dit dans CMMI sur la nature de la relation entre expert et décideur, ni sur le suivi des décisions ; aucun exemple n’est donné, ni de critère permettant d’évaluer les décisions. On peut donc, tout en suivant CMMI à la lettre sur ce point, s’égarer longtemps dans l’erreur…
Il est pourtant crucial de définir, quand on parle de décision, qui est légitime pour décider, la démarche que le décideur doit suivre, la nature des informations qui doivent lui être communiquées par les experts pour qu’il puisse préparer sa décision.
Au niveau 4, il faut maîtriser les processus du niveau trois et en outre deux autres processus (soit en tout 23 des 25 processus) :
Performance des processus (Organizational
Process Performance)
Gestion quantitative du projet (Quantitative Project Management)
On se focalise ici sur la productivité, sur la performance lors de la réalisation des projets, et non sur la performance de l’entreprise elle-même, à laquelle les projets doivent contribuer : cela résulte de la focalisation de CMMI sur les projets et non sur leurs résultats.
Il s’agit de recueillir et de comparer les statistiques relatives à chaque projet. Mais si les techniques changent (par exemple, par introduction d’un nouvel AGL, d’un nouvel outil de gestion de la documentation) les données sur la productivité risquent de devenir obsolètes plus vite qu’elles ne s’accumulent.
Les techniques statistiques suggérées par CMMI sont inspirées du contrôle de la qualité dans la production industrielle, qui distingue les « causes normales » et les « causes spéciales » de variation et agit pour repérer et corriger les causes spéciales[5].
Mais cette technique n’est applicable que si l’on peut considérer un nombre de projets suffisant pour estimer des moyennes et des écarts-types que l’on utilisera ensuite comme référence pour le suivi de chaque projet particulier. Si l’entreprise n’est pas au niveau 4, ou si elle ne réalise pas assez de projets pour pouvoir estimer des moyennes et écarts-types significatifs, il faudra se contenter d’une description claire de l’avancement du projet et s’en remettre au bon sens pour savoir si l’on dérape ou non.
Au niveau 5 l’entreprise maîtrise les 25 processus décrits par CMMI ; pour passer du niveau 4 au niveau 5, elle doit donc acquérir la maîtrise des deux processus suivants :
Innovation organisationnelle
(Organizational Innovation and Deployment)
Analyse causale et solution des problèmes (Causal Analysis and Resolution)
Alors que le niveau 4 était consacré à la statistique, le niveau 5 est celui de la modélisation : on s’efforce de remonter du constat à la causalité, et d’agir sur les causes pour accroître encore la performance. Cette démarche est confortée par une veille technologique et une politique d’innovation.
CMMI encourage l’entreprise à capitaliser, d’un projet à l’autre, les enseignements de l’expérience : « règles de pouce », documents types, évaluations quantitatives. C’est là sans doute son apport le plus précieux : le responsable d’un projet nouveau pourra trouver dans une base documentaire un ensemble d’outils et de références qui lui éviteront d’avoir à réinventer la roue.
Associé à SCAMPI, CMMI fournit une référence qui permet à chaque entreprise d’évaluer sa maturité en conduite de projet et de la faire progresser.
CMMI définit, sous le nom de « processus », les diverses responsabilités qui interviennent dans la réalisation d’un projet ainsi que leur articulation ; il détaille selon une nomenclature arborescente le contenu de ces responsabilités en « pratiques » et « produits ». Cette énumération permet à ceux qui la consultent de ne rien oublier d’important. Les auteurs précisent qu’elle n’est qu’indicative : on peut, si l’on a de bonnes raisons pour cela, décider de ne pas mettre en œuvre tout ou partie de certains processus.
Toutefois CMMI n’évoque pas les « règles de pouce » de bon sens qui permettraient de faire ce choix.
Rappelons que CMMI n’est pas une méthode de conduite de projet : c’est une méthode de qualification de l’entreprise en conduite de projet.
Les définitions qu’il fournit comportent parfois des incohérences. Ainsi, le cycle de vie d’un produit est défini d’abord, de façon correcte (p. 30), comme « une période de temps qui commence quand le produit est conçu et s’achève quand il n’est plus utilisable ». Mais le paragraphe suivant précise les phases du cycle de vie : « (1) conception, (2) étude de faisabilité, (3) développement, (4) production, (5) phase finale » : cela correspond au cycle de vie d’un bien industriel vu par l’entreprise qui le produit, mais non à celui d’un service ni d’un logiciel car il manque dans cette liste la phase d’utilisation – souvent la plus longue, et qui demande elle aussi du travail.
C’est que CMMI est destiné aux directions des études et aux SSII, et non aux maîtrises d'oeuvre et maîtrises d'ouvrage même si celles-ci ont intérêt à le connaître pour évaluer leurs fournisseurs. CMMI ne considère pas la mise en place des référentiels, l’arbitrage entre les divers projets, la façon dont les métiers définissent leurs processus de production et les outils d'aide aux utilisateurs, l’alignement des dépenses avec les priorités des métiers, ni la traduction d'un problème technique en impacts pour la production ou les clients.
CMMI ne regarde ni vers l’amont, ni vers l’aval du projet. Il ne parle ni d’urbanisme du système d’information, ni de modélisation des processus de production de l'entreprise (il donne au mot « processus » un tout autre sens), ni d'animation du bon usage : il suppose donc tout cela fait par ailleurs, et bien fait.
CMMI décrit les processus qu'il est opportun de maîtriser pour conduire un projet, mais ne dit rien des pièges que ces processus permettent d’éviter. Or comme certains pièges sont plus dangereux que d’autres, les divers processus n’ont pas une importance égale : la présentation de CMMI manque de relief à cet égard.
CMMI ne fournit pas d’exemples de document bien rédigé, de processus bien mis en œuvre : il dit seulement « il faut écrire tel document », « il faut mettre en œuvre tel processus». Or il existe par exemple une grande différence entre un document bien rédigé (clair, lisible) et un document incompréhensible. Il ne suffit donc pas d’avoir défini le thème d’un document, il faut encore lui associer des critères de qualité et savoir les appliquer : CMMI ne fournit pas de tels critères.
Il ne convient pas de prendre CMMI au pied de la lettre, c’est d’ailleurs ce que disent ses auteurs eux-mêmes.
Il serait en effet peu raisonnable pour une entreprise d’attendre des mois ou années avant d’introduire des indicateurs quantitatifs dans la gestion de projet, et certains des processus qui relèvent des niveaux 3 ou 4 sont donc de ceux que l’entreprise doit maîtriser en tout premier, notamment la qualité de l’expression de besoins et le suivi quantitatif de la réalisation. Il faudra en fait les mettre en œuvre dès le début, donc sans respecter exactement l’ordre prescrit par CMMI.
Les niveaux les plus substantiels de CMMI sont les niveaux 2 et 3, qui font le plus souvent l’objet d’une certification et contiennent le plus grand nombre de processus.
Les niveaux 4 et 5 relèvent, pour l’essentiel, d’un perfectionnement que l’on peut juger superflu et qui est peut-être impossible : les projets que réalise une entreprise ne sont pas nombreux au point que l’on puisse fonder sur eux une statistique représentative, encore moins une analyse causale en bonne et due forme.
Enfin, l’entreprise qui adhère à CMMI risque peut-être de négliger ce que CMMI ignore, ou suppose déjà fait et bien fait : la gestion du portefeuille de projets, la sobriété des exigences, l’observation et l’animation de l’usage des produits. Si elle se focalise sur sa maîtrise de la « gestion de projet », seule chose que CMMI considère, et non sur la qualité de son SI, elle risque de lancer de nombreux projets sans percevoir que la pluie de nouveautés qui en résulte peut déstabiliser ses agents opérationnels et son organisation.
[1] Cette étude s’appuie sur une lecture méthodique de CMMI version 1.1, staged representation, mars 2002.
[2] Pour alléger le texte, nous ne parlerons ni « du » ni « de la » CMMI : nous utiliserons cet acronyme comme s’il s’agissait d’un nom propre.
[3] http://www.sei.cmu.edu/publications/documents/01.reports/01hb001.pdf
[4] « We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. »
[5] Les « causes normales » font fluctuer la qualité dans des bornes admises ; les causes spéciales sont celles qui provoquent un écart à la moyenne supérieur à trois écarts-types, écart que l’on ne constate pas plus de deux fois sur mille si la distribution de probabilité de la qualité obéit à une loi de Laplace-Gauss.
Pour lire un peu plus :
-
-
-
Essai sur les nomenclatures
- A
propos de la compétence
-
De l’Informatique
-
CMMI : le document pdf
www.volle.com/travaux/cmmi.htm
© Michel VOLLE, 2003
GNU
Free Documentation License