Courbe du coût du changement

La raison tient à la quantité de travail qui repose sur une décision. Tant qu'une exigence ne figure que dans le concept, la modifier ne touche qu'un document. Si elle figure dans la conception, elle touche la conception et tout ce qui en découle. Si elle est réalisée et réceptionnée, s'y ajoutent la reprise, une nouvelle vérification, la documentation et la communication. La courbe ne monte donc pas de façon linéaire, mais à peu près exponentielle.

Les chiffres remontent à Barry Boehm, qui les a tirés de données de projets dans « Software Engineering Economics » en 1981. Pour les projets classiques à exécution coûteuse, par exemple dans le bâtiment, l'ingénierie industrielle ou l'événementiel, la relation reste valable. Ce qui est modifié sur le chantier coûte plusieurs fois ce que la modification aurait coûté en phase d'études.

Dans le développement logiciel, la courbe s'est nettement aplatie. Les tests automatisés, l'intégration continue et les petites livraisons réduisent fortement le coût d'un changement tardif. Kent Beck en a tiré la thèse inverse : si la courbe est plate, se fixer tôt ne paie plus, car on peut alors décider au moment où l'on en sait le plus.

La forme que prend la courbe dépend donc du projet, pas de la méthode. Elle monte fortement là où l'exécution est coûteuse et où les résultats s'appuient les uns sur les autres, comme dans le bâtiment ou lors de migrations. Elle reste plate là où les corrections sont bon marché et vérifiables automatiquement. La pente détermine à quelle phase du cycle de vie du projet une décision garde sa valeur.