CMMI n'est pas une méthode informatique

L'origine de CMMI

C'est le département de la défense américain qui est à l'origine de ce modèle, dans les années 80. A la base ce n'était pas du tout une méthode informatique mais un simple référentiel destiné à comparer les performances des différents fournisseurs de logiciels de l'armée des Etats-Unis essentiellement sur le plan de la qualité.

CMMI est donc en quelque sorte une norme de qualité et non une méthode, ce avec quoi beaucoup de gens ont tendance à le confondre.

C'est le Software Engineering Institute (SEI) a qui on a confié cette mission d'élaborer cette norme qualitative. Il faut attendre 1991 pour que soit présenté CMM (Capability Maturity Model). L'évolution vers d'autres modèles se poursuivit dans les années 90 pour aboutir en 2001 à la version CMMI proprement dite : Capability Maturity Model Integration.

Une norme très lourde

Si dans les années 80 beaucoup d'informaticiens se plaignaient de la méthode d'analyse MERISE à cause de sa lourdeur, qu'ils se rassurent : CMMI est encore plus lourd.

Déjà, les premières méthodes des années 70 tel que la méthode LCP, étaient considérées comme une perte de temps pour beaucoup de développeurs et d'analystes programmeurs.

Les concepteurs de CMMI étaient bien conscient que leur méthode était la pire de toutes et dès 2006 ils proposent une version simplifiée baptisée CMMI 1.2. Nous en sommes maintenant à la version 1.3 qui vu le jour en 2011. Mais elle ne va plus dans le sens d'une simplification, bien au contraire.

Le principal défaut de CMMI est qu'elle ne s'intéresse pas seulement au développement de projets informatique mais en réalité à tout processus de fabrication et de réalisation concernant tout type de produit. C'est une norme très générale et pourtant déclinée jusqu'au moindre détail. Utiliser CMMI c'est avoir une garantie de la qualité mais c'est également s'attacher un boulet au pied, un frein à toute réactivité. Et on sait que de plus en plus dans le monde d'aujourd'hui il est nécessaire d'être réactif et pouvoir s'adapter à tout changement quel qu'il soit.

Paradoxalement, c'est dans le développement et la maintenance informatique que la version CMMI-DEV est la plus utilisée alors qu'elle pourrait l'être pour la conception et la fabrication de tout autre type de produit (industriel, bâtiment, ...).

Descriptif du modèle CMMI

Il se présente comme un modèle en couches. On compte pas moins de 22 couches de processus. Chaque couche se décline suivant 5 niveaux qualitatif. Et un étage ne peut pas atteindre un niveau de qualité tant que tous les étages inférieurs n'ont pas eux même atteint ce niveau ou un niveau supérieur.

Appliquée à l'informatique c'est une méthode qui est le contre-pied exact de la méthode AGIL très prisée par de nombreuses équipes de développement. AGIL prône l'efficacité alors que CMMI s'attache à la qualité.

Le gros défaut du modèle en couche est qu'il ne prend pas en compte la possibilité de régression, c'est-à-dire qu'un niveau peut être atteint à un certain moment mais qu'ultérieurement le processus peut se retrouvé à un niveau plus faible. Ce n'est pas du au fait que le processus a changé mais tout simplement que les processus auxquels il est directement lié ont évolué. Une nouvelle règlementation peut par exemple faire chuter le niveau de qualité d'un processus existant.

C'est pourquoi CMMI ajoute à tous les niveaux d'un projet des étapes de monitoring et de surveillance pour s'assurer du maintient du niveau de maturité précédemment atteint. Mais bien entendu ces étapes supplémentaires viennent alourdir le projet et n'ont jamais eu aucune nécessité fonctionnelle. C'est tout simplement du temps perdu et des risques pris inutilement. Elles ne correspondent à aucun besoin autre que les propres besoins de CMMI.

Description des niveaux de qualité de CMMI

1. Initial

Tout doit être fait. La documentation est disparate et dispersée. Aucune mesure de performance. Pas de tâches clairement identifiée confiée aux employés. Mauvaise gestion des incidents qui sont traités sur le tas. C'est le chaos le plus total.

2. Managed

Ce niveau est un peu plus ordonnée. On y trouve des plans, de nombreux plans : Plan de projet, Plan de développement, Plan de tests, Plan de livraison...
Tous ces plans sont confiés à un manager qui n'est autre qu'un chef de projet. Son rôle essentiel est de maintenir tous les plans à jour. C'est passionnant.

3. Defined

Dans ce niveau apparait un terme essentiel : la capitalisation.
La capitalisation est le fruit de l'accumulation des erreurs du passé dans le but de ne pas les réitérer dans le futur.
Et quand quelque chose s'est bien passé par le passé, on la capitalise également, c'est-à-dire qu'on le fige. Ce niveau de capitalisation est donc un frein à toute évolution pour se surpasser et faire encore mieux. Pour ne pas prendre le risque de faire des erreurs on va préférer ne rien toucher à ce qui se passe bien.

4. Quantitatively managed

Le niveau de qualité 4 est caractérisé par la présence de nombreux tableaux de bord, des plannings, des objectifs, des budgets à tenir. Il faut absolument montrer que tout se passe pour le mieux dans le meilleur des mondes et qu'on respecte correctement les plans. Pour y arriver on n'hésite pas à pointer du temps passé là où il n'a pas lieu d'être afin de ne pas avoir de dépassement par rapport aux prévisions.

5. Optimizing

Le niveau un peu utopiste où on cherche, malgré l'accumulation de toutes les étapes précédentes, à anticiper les évolutions et à être réactif en cas de nouveau besoin de la clientèle ou d'un changement technologique ou d'une règlementation.
En fait, c'est le niveau où tout est livré en production et où tout fonctionne à peu près correctement. Tout se passe donc merveilleusement bien tant que rien ne survient pour chambouler tout ça. Une nouvelle expression des besoins et il faut repartir à zéro avec un nouveau projet géré de la même façon.