[Fiche pratique] La contractualisation agile : pourquoi, comment ?

Aujourd'hui, après des années d'expérimentation des techniques agiles, 90% des sociétés disent avoir lancé des projets informatiques utilisant les techniques agiles. Les projets agiles sont bâtis sur un paradigme : gérer un périmètre non spécifié dans le détail au début du projet et permettre le changement en cours de projet. Si cette ouverture ravit le métier qui ne sait pas tout ce dont il aura finalement besoin, cela semble contraire à l'esprit d'une contractualisation maîtrisée où tout aura été prévu : périmètre précis, délai et charges financières.

Les acheteurs sont en droit d'attendre de leurs fournisseurs un engagement sur les résultats. Cet engagement est matérialisé par des livrables précis et des SLA. Or, la contractualisation avec "obligation de moyens" est aujourd'hui dépassée, ou en tout cas incompatible avec une gestion de projet agile dont la méthode, la plus utilisée étant Scrum, permet au produit d'évoluer pendant tout le cycle de construction. Les livrables ne sont définis qu'à chaque début de "Sprint".

Posons le problème simplement. Dans une méthode de gestion traditionnelle, en début de projet, tout est fixé : périmètre, coût et délai. Si tout se passe comme prévu, la résultante est une qualité maintenue. Une spécification technique ou fonctionnelle qui se révèlerait plus difficile à développer que prévue aurait une incidence sur le délai et donc le coût. Comme le client est en droit de refuser ce "dérapage" (obligation de résultat), la seule variable d'ajustement consiste à rattraper et "aller plus vite" sur le reste à faire. Et donc prendre un risque fort sur la qualité. C'est ainsi que selon le "Chaos Report 2015" du Standish Group, 84% des projets dépassent leurs délais et/ou leur budget. Plus précisément, 53% des projets coûtent finalement 2 fois plus (189% en moyenne) que l'estimation initiale.

Le même document rapporte que 30% de projets intègrent des changements d'exigences clients au cours du développement. La méthode de projet agile permet le changement d'exigences clients pendant le projet parce que le périmètre est réactualisé à chaque itération. Les nouvelles exigences sont intégrées dans le "Backlog Produit" qui est repriorisé à chaque itération. Et ces nouvelles "Features" remplacent celles qui ont une valeur métier moindre. La valeur d'ajustement devient donc le périmètre ; les données coût, délai et qualité restant fixes. Le budget du projet reste complètement sous le contrôle du "Product Owner" pour les changements mais aussi sous celui du "Scrum Master" pour la réalisation.