Quand les dysfonctionnements organisationnels finissent dans le budget du projet
Deux équipes doivent réaliser deux applications de taille et de complexité comparables.
La première travaille avec des exigences maîtrisées, des estimations documentées, une planification réaliste, des responsabilités définies et un suivi régulier des écarts.
Dans la seconde, les exigences évoluent sans véritable gestion des changements, les estimations reposent essentiellement sur l’expérience des chefs de projet, les décisions arrivent tardivement et les difficultés sont souvent découvertes lorsqu’elles deviennent urgentes.
La seconde organisation ne produit pourtant pas davantage de logiciel.
Mais elle peut consommer sensiblement plus d’effort.
C’est précisément ce que cherche à représenter le facteur Maturité des processus de COCOMO II.
Pour une DSI, ce facteur pose une question très concrète : quelle part de l’effort de nos projets provient du logiciel à réaliser et quelle part provient de notre manière de conduire les projets ?
Que mesure la maturité des processus ?
La maturité des processus évalue la capacité d’une organisation à mettre en œuvre de manière maîtrisée et reproductible les processus nécessaires à la réalisation de ses projets logiciels.
Ce facteur est issu du modèle international COCOMO II, utilisé depuis de nombreuses années pour l’estimation des projets logiciels.
Dans COCOMO II.2000, ce paramètre est directement relié au Capability Maturity Model (CMM) du Software Engineering Institute.
Il ne faut cependant pas réduire cette notion à la présence de procédures.
Une organisation peut disposer de dizaines de documents méthodologiques et rester relativement peu mature si ces pratiques ne sont pas réellement appliquées.
La question est donc moins :
« Avons-nous défini un processus ? »
que :
« Sommes-nous capables de l’appliquer de manière régulière et mesurable sur nos projets ? »
Les différents niveaux
COCOMO II distingue six niveaux d’évaluation.
| Niveau COCOMO II | Correspondance historique CMM | Valeur PMAT |
| Très faible | Niveau 1 – partie basse | 7,80 |
| Faible | Niveau 1 – partie haute | 6,24 |
| Nominal | Niveau 2 | 4,68 |
| Élevé | Niveau 3 | 3,12 |
| Très élevé | Niveau 4 | 1,56 |
| Extra élevé | Niveau 5 | 0,00 |
Ces valeurs ne sont pas des pourcentages ni des multiplicateurs directs.
PMAT est un facteur d’échelle.
Il intervient dans l’exposant de la formule COCOMO II. Son impact augmente donc avec la taille du logiciel : la maturité devient particulièrement importante lorsque les projets deviennent importants.
Un impact qui augmente avec la taille du projet
Pour rendre cet effet compréhensible, prenons un projet logiciel significatif et fixons le niveau nominal comme référence à 1 000 jours-homme.
Comme PMAT intervient dans l’exposant de COCOMO II, il faut fixer une taille technique pour effectuer la comparaison. Pour l’illustration, nous retenons un projet de 100 KSLOC et maintenons tous les autres paramètres constants.
On obtient approximativement :
| Maturité | Effort relatif | Effort illustratif |
| Très faible | 115 % | 1 155 JH |
| Faible | 107 % | 1 074 JH |
| Nominale | 100 % | 1 000 JH |
| Élevée | 93 % | 931 JH |
| Très élevée | 87 % | 866 JH |
| Extra élevée | 81 % | 806 JH |
L’écart entre les deux extrêmes atteint donc environ 349 jours-homme, soit environ 43 % d’effort supplémentaire lorsqu’on compare le niveau très faible au niveau le plus élevé.
Ce chiffre doit être interprété avec prudence : il dépend de la taille du logiciel et des autres hypothèses du modèle.
Le message important est ailleurs : la maturité des processus n’a pas un impact fixe. Son influence augmente avec la taille du projet.
Cas concret : le déploiement d’un nouveau CRM
Imaginons une grande entreprise lançant un CRM destiné à plusieurs milliers de collaborateurs.
Les besoins fonctionnels sont identifiés et l’architecture générale est connue.
Mais l’organisation projet présente plusieurs faiblesses :
- exigences insuffisamment stabilisées ;
- responsabilités entre métier, MOA et réalisation mal définies ;
- estimations initiales peu documentées ;
- changements traités au fil de l’eau ;
- suivi essentiellement centré sur les échéances ;
- détection tardive des dérives.
Chaque faiblesse prise individuellement semble gérable.
Le problème vient de leur accumulation.
Une exigence imprécise génère une interprétation. Cette interprétation conduit à un développement. Le métier constate l’écart lors de la recette. Une demande de modification est créée. Elle entraîne une nouvelle analyse, un nouveau développement, de nouveaux tests et éventuellement une modification de la planification.
Le projet n’a pas créé davantage de valeur fonctionnelle.
Il a simplement consommé davantage d’effort pour atteindre le même résultat.
Pourquoi un tel impact ?
Une faible maturité produit principalement de la variabilité et du travail évitable.
Elle augmente notamment :
Les reprises
Les problèmes sont détectés tardivement et nécessitent de revenir sur des travaux considérés comme terminés.
Les changements non maîtrisés
Les modifications sont réalisées sans toujours mesurer leur impact sur le périmètre, le budget ou le calendrier.
Les erreurs de planification
Lorsque les estimations initiales sont insuffisamment structurées, les plans reposent sur des hypothèses fragiles.
Les problèmes de coordination
Les responsabilités, livrables et décisions peuvent être insuffisamment formalisés.
La détection tardive des dérives
Une organisation mature ne supprime pas les problèmes. Elle cherche à les identifier suffisamment tôt pour que leur correction reste peu coûteuse.
Les symptômes observables
Plusieurs signes doivent attirer l’attention d’une DSI :
- écarts importants entre estimations initiales et résultats ;
- modifications fréquentes du périmètre sans réestimation ;
- difficultés récurrentes lors des recettes ;
- nombreux arbitrages tardifs ;
- indicateurs différents selon les projets ;
- dépendance excessive à quelques personnes expérimentées ;
- causes des dépassements rarement analysées ;
- mêmes problèmes reproduits d’un projet à l’autre.
Un autre symptôme est particulièrement révélateur : l’organisation explique systématiquement les dérives par les caractéristiques particulières du projet.
Lorsque tous les projets sont considérés comme des exceptions, il devient difficile d’améliorer le système qui les produit.
Conséquences sur le chiffrage
La maturité des processus doit faire partie des hypothèses d’un chiffrage.
Le responsable de l’estimation peut notamment demander :
- Comment les exigences sont-elles validées et mises sous contrôle ?
- Les estimations précédentes sont-elles conservées et comparées aux résultats ?
- Comment les changements de périmètre sont-ils gérés ?
- Les risques sont-ils identifiés et suivis ?
- Existe-t-il des indicateurs communs aux projets ?
- Les causes des écarts sont-elles analysées ?
- Les pratiques définies sont-elles réellement appliquées ?
L’erreur serait de considérer implicitement que tous les projets bénéficient d’un environnement organisationnel nominal.
Un chiffrage techniquement précis peut être faux si ses hypothèses organisationnelles ne correspondent pas aux conditions réelles de réalisation.
La qualité du chiffrage dépend donc à la fois de la mesure de ce qu’il faut produire et de l’évaluation des conditions dans lesquelles cette production sera réalisée.
Comment améliorer ce facteur ?
L’objectif n’est pas de créer davantage de procédures.
Il est de réduire les causes récurrentes de variabilité.
1. Maîtriser les exigences
Définir une baseline, tracer les évolutions et mesurer leur impact avant décision.
2. Capitaliser les estimations
Conserver les hypothèses initiales, les comparer aux résultats et construire progressivement un historique exploitable.
3. Standardiser quelques indicateurs
Taille fonctionnelle, effort, coût, délai, évolution du périmètre et défauts permettent déjà d’objectiver une grande partie des écarts.
4. Organiser les retours d’expérience
L’objectif n’est pas seulement d’expliquer pourquoi un projet a dérivé, mais d’éviter que le suivant dérive pour la même raison.
5. Vérifier l’application réelle des pratiques
Une méthode non appliquée n’améliore pas la maturité.
La maturité repose davantage sur la répétabilité des bonnes pratiques que sur leur niveau de formalisation.
Que changent les IA génératives ?
Les IA génératives peuvent contribuer à améliorer certains processus.
Elles peuvent par exemple :
- analyser la qualité des exigences ;
- détecter des ambiguïtés ou incohérences ;
- faciliter la production de documentation ;
- comparer des exigences ou des versions ;
- assister l’identification des risques ;
- automatiser certaines activités d’estimation ;
- analyser les retours d’expérience.
Mais elles ne rendent pas la maturité des processus obsolète.
Elles pourraient même renforcer son importance.
Une IA utilisée dans un processus mal défini permet parfois simplement d’exécuter plus rapidement un processus mal maîtrisé.
Pour bénéficier réellement des IAG, une DSI doit notamment définir les informations fournies aux agents, les résultats attendus, les contrôles nécessaires, les responsabilités de validation et les données permettant d’évaluer les résultats.
L’IAG peut donc automatiser une partie du processus ; elle ne supprime pas le besoin de maîtriser le processus.
Les erreurs fréquentes
Confondre maturité et bureaucratie
Une organisation mature n’est pas nécessairement une organisation qui produit beaucoup de documents.
Considérer une certification comme une garantie
L’existence d’un référentiel ou d’une certification ne garantit pas que les pratiques soient réellement appliquées sur chaque projet.
Multiplier les procédures pour améliorer la maturité
L’accumulation de contrôles peut au contraire augmenter les délais sans améliorer les résultats.
Ne pas mesurer les résultats
Sans comparaison entre prévisions et réalisations, l’organisation dispose de peu de moyens pour apprendre de ses projets.
Croire que l’Agile supprime le sujet
Agile modifie les processus, mais ne supprime ni la nécessité de maîtriser les exigences, ni celle d’estimer, de suivre les risques ou d’analyser les résultats.
À retenir
Maturité des processus : cinq idées essentielles
- La maturité mesure la capacité à conduire les projets de manière maîtrisée et reproductible.
- Dans COCOMO II, elle constitue un facteur d’échelle : son importance augmente avec la taille du logiciel.
- Une faible maturité génère notamment reprises, variabilité, changements mal maîtrisés et détection tardive des dérives.
- L’objectif n’est pas de multiplier les procédures, mais de rendre les pratiques essentielles réellement maîtrisées.
- Les IA génératives peuvent automatiser certains processus, mais elles ne remplacent pas leur maîtrise.
Quelles décisions un DSI peut-il prendre ?
La première consiste à ne plus considérer la maturité des processus comme un sujet exclusivement méthodologique.
Elle influence potentiellement l’économie des projets.
La deuxième consiste à identifier quelques processus dont les insuffisances génèrent réellement des coûts : exigences, estimation, changements, risques, qualité et capitalisation.
La troisième consiste à intégrer les conditions organisationnelles de réalisation dans les estimations.
Enfin, une DSI peut utiliser les données de ses propres projets pour mesurer progressivement l’effet réel de ses pratiques.
La question n’est donc pas de savoir si l’organisation possède une méthode projet.
La question est de savoir si cette méthode permet effectivement de réduire la variabilité, d’anticiper les dérives et d’améliorer la prévisibilité des projets.
« La maturité ne produit pas plus de logiciel. Elle évite de dépenser inutilement de l’effort pour produire le même logiciel. »
Le conseil Estimancy
Ne cherchez pas à évaluer la maturité de votre organisation uniquement à partir de son référentiel méthodologique.
Observez les projets.
Mesurez systématiquement la taille du logiciel, l’effort estimé, l’effort réellement consommé et les principales causes d’écart.
En comparant ces données sur plusieurs projets, une DSI peut identifier les processus qui ont réellement un impact économique et concentrer ses efforts d’amélioration là où ils produisent le plus de valeur.
Les niveaux CMM utilisés dans l’article correspondent directement à la table PMAT du manuel : niveau 1 inférieur = très faible, niveau 1 supérieur = faible, niveau 2 = nominal, niveau 3 = élevé, niveau 4 = très élevé et niveau 5 = extra élevé. Le manuel prévoit également une évaluation plus détaillée fondée sur 18 domaines de processus clés et leur degré d’application.
