Agile au forfait : concilier un prix fixe et un périmètre qui évolue

L'agile au forfait consiste à figer trois choses (le prix, le délai et l'objectif métier) et à laisser ouvert le détail du périmètre. Les fonctionnalités forment une liste priorisée, estimée en tailles comparables et livrée par étapes ; le client peut remplacer une fonctionnalité pas encore commencée par une autre de même taille, sans avenant ni surcoût. Ainsi, le budget est tenu, et le logiciel livré correspond à ce que l'on a appris en route plutôt qu'à ce que l'on imaginait au départ.

Cet article explique pourquoi forfait et agilité semblent s'opposer, quels mécanismes les réconcilient, et quoi écrire dans le contrat pour que cela tienne.

Pourquoi forfait et agile semblent incompatibles

Le forfait classique fige tout : un cahier des charges détaillé, un prix, une date. Le prestataire s'engage sur le résultat et porte le risque de dépassement. C'est rassurant, mais rigide : toute idée nouvelle devient un avenant, et l'on finit parfois par livrer exactement ce qui était écrit, alors que le besoin a changé.

Les méthodes agiles partent du principe inverse. Le Manifeste agile de 2001 valorise « l'adaptation au changement plus que le suivi d'un plan » et « la collaboration avec les clients plus que la négociation contractuelle ». Le Guide Scrum décrit un backlog de produit, une liste ordonnée qui évolue en permanence. Rien de tout cela ne ressemble à un contrat à prix fixe.

En pratique, beaucoup d'entreprises tranchent en achetant de l'agilité en régie : des sprints facturés au temps passé. Elles gagnent en souplesse, mais reprennent tout le risque de dépassement, comme le détaille notre article sur le forfait et la régie. L'agile au forfait cherche à garder les deux avantages.

Ce qui est fixe, ce qui bouge

Un projet a trois variables liées : le périmètre, le coût et le délai. Le forfait classique fige les trois, ce qui ne laisse aucune marge quand la réalité s'écarte du plan. L'agile au forfait en fige deux et fait de la troisième une variable pilotée.

L'objectif reste fixe, et c'est essentiel. « Permettre aux techniciens de saisir leurs interventions sur le terrain et de déclencher la facturation » est un objectif. La liste des écrans pour y parvenir peut bouger ; l'objectif, non.

Les six mécanismes qui le rendent possible

1. Un cadrage visible avant de signer

On ne peut pas fixer un prix sur un besoin flou, agile ou pas. Avant de signer, le périmètre doit être rendu concret : les écrans principaux, les parcours, les règles métier essentielles. Un prototype visuel est l'outil le plus efficace pour cela, parce qu'il fait apparaître les malentendus avant qu'ils ne coûtent. Notre article sur le cadrage d'un projet logiciel détaille cette étape.

2. Un backlog estimé en tailles comparables

Le périmètre initial prend la forme d'une liste de fonctionnalités, chacune décrite du point de vue de l'utilisateur et estimée en taille relative (petite, moyenne, grande, ou en points). Ce qui compte n'est pas la précision de chaque estimation, mais leur cohérence entre elles : c'est ce qui rend les échanges possibles. Pour la méthode d'estimation, lisez comment estimer un projet logiciel.

3. Une priorisation explicite

Chaque fonctionnalité est classée : indispensable, importante, souhaitable, hors du périmètre actuel. La méthode MoSCoW (must, should, could, won't) est la plus répandue. Le développement suit cet ordre. Conséquence directe : si le budget vient à manquer, ce qui reste hors du budget est, par construction, le moins important.

4. La règle d'échange à budget constant

C'est le cœur du dispositif. Le contrat prévoit qu'une fonctionnalité pas encore commencée peut être retirée et remplacée par une autre de taille estimée équivalente, sans changer ni le prix ni la date. Quelques règles rendent l'échange loyal :

• l'échange ne porte que sur ce qui n'a pas démarré ; ce qui est fait reste fait ;
• la taille de la nouvelle fonctionnalité est estimée par la même méthode que les autres, et validée par les deux parties ;
• un ajout net, sans retrait, n'est pas un échange : il passe par un avenant ou un lot supplémentaire chiffré à part ;
• chaque échange est écrit, avec sa date, dans un registre partagé.

5. Des livraisons par lots, avec démonstration et recette

Le logiciel est livré par incréments, toutes les deux à quatre semaines par exemple, chacun démontré puis recetté. C'est à ces moments que le client apprend ce qu'il veut vraiment, et que les échanges se décident. Une recette par lot évite aussi la recette unique de fin de projet, qui concentre tous les risques ; notre check-list de recette s'applique à chaque lot.

6. Une réserve et une sortie anticipée

Une part du budget peut être réservée dès le départ aux découvertes : cas métier oubliés, ajustements après démonstration. Elle se consomme par décision commune, pas par défaut. Enfin, une clause de sortie anticipée permet au client d'arrêter le projet à la fin d'un lot, en conservant ce qui a été livré, si le logiciel répond déjà à son besoin ou si celui-ci a changé. Ce principe a été popularisé dans les milieux agiles sous le nom de « money for nothing, change for free » : les changements sont gratuits à taille égale, et l'arrêt anticipé est prévu d'avance.

Un exemple d'échange

Exemple fictif. Une entreprise de services fait développer une application de gestion des interventions au forfait agile. Le backlog initial compte une trentaine de fonctionnalités estimées. Lors de la démonstration du deuxième lot, les techniciens expliquent qu'ils n'utiliseront jamais le planning hebdomadaire prévu sur mobile : ils reçoivent leur tournée la veille, et ont surtout besoin de photographier le chantier pour le rapport.

La fonctionnalité « planning hebdomadaire mobile » (taille moyenne, pas commencée) est retirée. « Photos jointes au rapport d'intervention » (estimée de taille moyenne) prend sa place, au même rang de priorité. Le prix et la date de fin ne bougent pas. L'échange est noté dans le registre, signé par le responsable du projet côté client.

Six mois plus tard, le logiciel livré ressemble davantage au travail réel des techniciens qu'au cahier des charges initial. C'est exactement l'effet recherché.

Ce qu'il faut écrire dans le contrat

Un forfait agile ne tient que si ses règles sont écrites. Au minimum :

• l'objectif métier, en une ou deux phrases mesurables ;
• le backlog initial, annexé, avec la taille et la priorité de chaque fonctionnalité ;
• la règle d'échange : ce qui peut être échangé, comment la taille est estimée, qui valide, comment c'est tracé ;
• le rythme des lots, la démonstration et la recette de chacun ;
• la définition de « terminé » : testé, documenté, déployé sur l'environnement de recette ;
• le rôle du client : qui arbitre, sous quel délai, avec quel mandat ;
• la sortie anticipée : à quelles étapes, avec quels livrables et quels droits, définis au cas par cas dans le contrat ;
• le traitement des ajouts nets : avenant ou lot supplémentaire, chiffré avant d'être lancé.

Ces clauses s'ajoutent à celles de tout contrat de développement, que nous détaillons dans les clauses d'un contrat de développement logiciel.

Les conditions côté client

L'agile au forfait demande plus d'implication au client qu'un forfait classique. Il faut :

• un responsable du produit, avec le mandat de trancher sans réunir un comité à chaque question ;
• du temps à chaque lot, pour la démonstration, la recette et les arbitrages ;
• des utilisateurs réels aux démonstrations, pas seulement la direction ;
• la discipline de prioriser : dire qu'une fonctionnalité est moins importante qu'une autre est plus difficile qu'il n'y paraît.

Sans ces conditions, l'agilité devient un flou permanent, et le forfait une source de tensions.

Les dérives à éviter

L'agilité comme excuse pour ne rien cadrer. « On verra en sprint » n'est pas une méthode. Sans cadrage visible, le prestataire ne peut pas s'engager sur un prix, ou il le fait avec une marge énorme.

Le forfait qui cache une régie. Un contrat qui fixe un nombre de sprints mais pas d'objectif ni de backlog n'est pas un forfait : c'est de la régie plafonnée. Le client paie les sprints, quel que soit le résultat.

Les échanges qui grossissent. Une fonctionnalité « de même taille » qui en contient trois en réalité fait déraper le projet. L'estimation partagée et le registre des échanges sont là pour l'éviter.

Le backlog qui ne se vide jamais. Chaque démonstration génère des idées. Elles vont dans une liste à part, pour la version suivante, sauf si elles remplacent quelque chose par échange.

Quand ce n'est pas le bon modèle

L'agile au forfait convient bien à un logiciel métier dont l'objectif est clair mais dont les détails se découvriront à l'usage. Il convient moins à un produit qui cherche encore son marché, quand l'objectif lui-même peut changer après quelques semaines : mieux vaut alors des lots courts, chacun chiffré à part, en commençant par une première version minimale. Notre article sur ce qu'il faut développer en premier aide à la délimiter.

Notre façon de faire

LPR Studio ne vend pas de régie : nos développements au forfait reposent sur un périmètre rendu visible avant tout engagement. Nous construisons d'abord un prototype visuel gratuit, présenté en visio sous 5 jours ouvrés. Une fois validé, il sert de base au chiffrage à prix fixe, puis au découpage en lots démontrés au fil du projet. Si vous préférez ne pas payer le développement, la formule abonnement couvre hébergement, maintenance et évolutions pour un montant mensuel : les priorités s'y arbitrent de la même façon, au fil de l'usage.