Cinq erreurs des contrats agiles (et comment les corriger)
Un contrat est une prévision de la façon dont deux organisations comptent se comporter sous pression. Quand la méthode de livraison est agile mais que le contrat suppose un livrable figé et entièrement spécifié, les deux tirent dans des directions opposées. On demande à l'équipe d'inspecter et de s'adapter à chaque Sprint; le contrat est rédigé comme si la réponse était déjà connue le premier jour. Au printemps 2021, avec des équipes hybrides, des priorités changeantes et des perturbations d'approvisionnement encore vives, ce décalage est devenu coûteux pour bien des acheteurs qui avaient verrouillé la portée un an plus tôt et ne pouvaient plus la modifier sans heurts.
La bonne nouvelle, c'est que ces échecs sont prévisibles. La plupart des ennuis de contrat agile remontent à la même poignée d'erreurs, et chacune a un correctif connu qui protège l'acheteur sans étouffer l'équipe.
Les erreurs qui reviennent sans cesse
Fixer une portée figée à un prix fixe. Si la portée et le prix sont gelés, la seule variable qui reste est la qualité — et c'est elle qui s'érode discrètement à l'approche de l'échéance. L'agilité suppose que la portée fluctue autour d'une cadence stable; geler la portée mine la méthode avant le premier Sprint.
Lier l'acceptation à un document d'exigences. Quand l'acceptation est rattachée à un cahier des charges de 200 pages écrit avant que quiconque ne touche au produit, chaque apprentissage de l'équipe devient une demande de changement à débattre. C'est le document, et non le produit fonctionnel, qui devient le livrable.
Traiter le rôle de Product Owner comme optionnel. Les acheteurs signent souvent le contrat puis nomment un intervenant à temps partiel incapable de décider. Le Guide Scrum est clair : le Product Owner est responsable de l'ordonnancement du Product Backlog; sans propriétaire habilité côté acheteur, l'équipe devine, et les devinettes coûtent cher.
Interdire le changement au lieu de le tarifer. Un processus de contrôle des changements qui exige un comité et trois semaines de paperasse pour tout ajustement signale à l'équipe que l'adaptation est mal venue. Or tout l'intérêt d'une méthode empirique est une correction de cap fréquente et peu coûteuse.
Mesurer l'effort plutôt que la valeur. Les contrats qui paient pour des heures consignées ou des points 'réalisés' récompensent l'activité. L'acheteur finance le mouvement plutôt que les incréments fonctionnels et utiles qui réduisent réellement son risque.
Des clauses qui laissent Scrum respirer
Rien de tout cela n'exige de montages juridiques exotiques. Quelques modèles bien compris réalignent les incitatifs pour que le contrat et la méthode veuillent la même chose.
Fixer le budget et la cadence, faire varier la portée. On convient d'une capacité (une équipe stable sur un nombre défini de Sprints) et on laisse le backlog priorisé décider de ce qui est construit. L'acheteur contrôle la valeur livrée, pas une liste de fonctions figée.
Définir l'acceptation comme un Incrément fonctionnel et livrable qui respecte la Définition de Terminé — et non la conformité à un cahier des charges initial.
Nommer le Product Owner habilité dans le contrat, avec une attente de niveau de service pour sa disponibilité et son délai de décision.
Inclure une clause de résiliation anticipée ou « argent pour rien, changement gratuit » afin que l'acheteur puisse arrêter, ou échanger des fonctions de taille égale sans frais, une fois assez de valeur livrée.
Prévoir un point de contrôle à la Revue de Sprint où chaque partie peut ajuster l'engagement selon ce que révèle le produit fonctionnel.
Le glissement de fond consiste à passer de l'achat d'une chose à l'achat d'une capacité qui produit des choses, inspectée et pilotée toutes les quelques semaines. C'est plus difficile à écrire qu'un livrable figé, mais bien plus proche du comportement réel du travail — et cela protège mieux l'acheteur, car il paie pour des progrès démontrés et visibles, non pour des promesses en annexe.
Si vous négociez un tel contrat en ce moment, résistez à l'envie de greffer un vocabulaire agile sur un gabarit en cascade. Partez de la cadence et des rôles habilités, et laissez les conditions commerciales suivre la façon dont l'équipe travaillera réellement.
Quand le vocabulaire d'approvisionnement et la méthode de livraison se contredisent, le conseil de XNM en livraison de programmes et de projets peut vous aider à structurer des ententes qui protègent l'acheteur tout en laissant l'équipe livrer.