Rédiger des contrats compatibles avec l'agilité : une liste de vérification pour cette semaine
Si votre équipe travaille en Scrum mais que votre contrat exige une portée figée, un prix fixe et une date de livraison établie avant la première ligne de code, les deux sont en conflit silencieux. Le contrat suppose qu'on peut tout prévoir d'avance; le Sprint suppose qu'on apprend en avançant. Après deux années où les délais d'approvisionnement, les effectifs et même les lieux de travail changeaient chaque mois, le coût de prétendre tout fixer à l'avance n'a jamais été aussi évident.
Pas besoin d'un diplôme en droit pour rendre un contrat plus agile. Il suffit de changer ce qu'il protège : au lieu de garantir une liste figée de fonctionnalités, il garantit une façon de travailler, une cadence de décisions et une sortie claire. Voici une liste à apporter à votre prochaine discussion d'approvisionnement ou avec un fournisseur cette semaine.
Ce qu'il faut inscrire dans l'entente
Fixez la cadence, pas la portée. Convenez de la durée du Sprint, d'une Revue de Sprint à laquelle l'acheteur assiste et d'un Backlog produit ordonné par le Product Owner de l'acheteur. Le backlog peut changer; le rythme d'inspection et de réajustement, non.
Facturez en régie plafonnée, ou par Sprint. Achetez de la capacité pour une période fixe plutôt qu'un ensemble figé de fonctionnalités. Le plafond rassure les finances; le droit d'arrêter après tout Sprint rassure tout le monde.
Rendez le rôle de Product Owner contractuel. Nommez qui ordonne le backlog et qui peut accepter le travail à la Revue. C'est le délai de décision, et non la vitesse des développeurs, qui coule souvent les projets à distance ou hybrides.
Définissez « terminé » une seule fois, pour tout. Renvoyez à une Définition de Terminé écrite dans le contrat pour que « fini » ne soit pas débattu fonctionnalité par fonctionnalité au moment de facturer.
Prévoyez une sortie sans faute. Permettez à l'acheteur de mettre fin à l'engagement à la fin d'un Sprint avec préavis, en conservant tout le logiciel fonctionnel produit. C'est la clause qui rend la livraison incrémentale honnête.
Ce qu'il faut éviter
Des calendriers détaillés de fonctionnalités en annexe — ils deviennent une machine à avenants dès qu'on apprend quelque chose.
Des pénalités liées à une date de lancement figée alors qu'elle a été devinée avant la découverte.
Des points d'approbation exigeant une seule grande acceptation finale, ce qui annule l'intérêt de réviser chaque Sprint.
Une formulation vague de « meilleurs efforts du secteur » sans cadence derrière — elle ne protège personne.
Un test utile : lisez l'ébauche et demandez ce qui arrive si, au Sprint 3, l'équipe découvre que la fonctionnalité la plus précieuse n'était sur aucune liste à la signature. Un bon contrat agile en fait un simple réordonnancement du backlog. Un mauvais en fait un litige. Le contrat doit permettre à l'apprentissage de changer le produit sans changer la relation.
Cela ne veut pas dire que les contrats deviennent flous. Ils deviennent précis sur les bonnes choses — cadence, rôles, acceptation et sortie — et volontairement discrets sur ce que personne ne peut honnêtement fixer au premier jour.
Revoir un contrat pour qu'il finance la valeur au lieu de combattre votre modèle de livraison mérite d'être bien fait dès le départ — le conseil en exécution de programmes et de projets de XNM aide les équipes du secteur public et des grands projets à structurer des ententes solides.