Forfait vs régie : quel contrat fonctionne vraiment pour le logiciel sur mesure

Le framework du fondateur non technique pour choisir la bonne structure de contrat avec un partenaire logiciel, et les clauses qui rendent la facturation en régie réellement responsable.

La première fois qu’un fondateur nous transmet deux projets de contrat et demande lequel signer, on sait déjà comment la conversation va se terminer. Un projet est au forfait : un montant unique, une liste de fonctionnalités, une date de livraison. L’autre est en régie : un taux horaire ou hebdomadaire, une estimation souple, une demande de confiance. On a dit au fondateur que le forfait est plus sûr parce qu’il plafonne la facture, et il veut qu’on le lui confirme.

La plupart du temps, on lui dit le contraire. Pour le logiciel sur mesure en phase initiale, la régie avec une structure à milestones est la bonne option par défaut. Le forfait gagne dans un ensemble restreint de cas qui ne s’appliquent généralement pas, et quand il gagne, il faut payer plus pour qu’il soit honnête. Le contrat que vous signez pour du logiciel sur mesure n’est pas un instrument financier. C’est le système d’exploitation de la relation que vous êtes sur le point de construire.

Voici le framework qu’on déroule avec chaque fondateur avant toute signature.

Ce qu’est chaque contrat, en une phrase

Le forfait signifie que vous et le prestataire convenez d’un montant total fermé pour un périmètre défini, payé contre milestones. Le prestataire prend le risque de livraison. S’il a sous-estimé, c’est son problème.

La régie, parfois appelée T&M (time and materials), signifie que vous payez le temps que l’équipe passe réellement, en général facturé à la semaine ou au sprint, à des taux convenus. Le prestataire envoie une facture pour les heures effectuées. Vous prenez le risque budgétaire. Si le travail dure plus longtemps que prévu, le compteur continue de tourner.

C’est la description manuelle. C’est aussi là où la plupart des articles sur le sujet s’arrêtent, et c’est pour cela que les fondateurs signent le mauvais contrat. Les deux structures paraissent symétriques sur le papier. En pratique elles créent des incitations complètement différentes, et ces incitations façonnent le produit que vous finissez par recevoir.

Les quatre conditions qui rendent le forfait honnête

Le forfait n’est pas une mauvaise structure. C’est une structure qui exige des conditions que la plupart des projets logiciels en phase initiale ne peuvent pas remplir. Quand ces quatre points sont vrais, le forfait peut être le bon choix.

Le périmètre est réellement connu. Pas “on sait qu’on veut une marketplace”. Connu signifie : les écrans sont dessinés, les intégrations sont listées, les cas limites sont documentés, le modèle de données est figé, le rythme auquel le client change d’avis est proche de zéro. Si vous ne pouvez pas tendre un dossier à un inconnu et obtenir de lui une estimation proche de celle de votre prestataire, le périmètre n’est pas figé.

Le travail est une commodité. Un site WordPress vitrine, un ajustement de thème Shopify, une appli mobile de forme connue pour un business de forme connue. Des choses qui ont déjà été construites des milliers de fois, où le prestataire dispose d’un vrai cadre de référence. Plus vous êtes loin d’une commodité, plus le prestataire doit injecter de marge de risque dans le montant fixe pour absorber les inconnues. Cette marge est le prix que vous payez pour le transfert de risque.

Vous ne changerez pas d’avis. Si la seule personne qui peut modifier le périmètre est vous, et que vous pouvez promettre de manière crédible de ne pas le modifier, le forfait reste propre. Au moment où vous changez de périmètre, le forfait devient une succession d’avenants, chacun négocié sous asymétrie d’information. Au troisième avenant, le contrat a cessé de fonctionner.

Le prestataire a construit exactement cela récemment. Pas “quelque chose de proche”. Cela. Une équipe qui a livré la même forme de produit pour deux clients précédents peut chiffrer un forfait honnêtement parce que son estimation s’appuie sur deux devis passés qui se sont confirmés. Une équipe nouvelle dans le domaine devine, et la devinette arrive chargée de marge de risque.

Si vous ne pouvez pas défendre les quatre points devant un pair, le forfait est la mauvaise structure pour votre projet. Le chiffre dans le contrat est de la fiction.

Les quatre façons dont le forfait casse en pratique

Les fondateurs qui signent des forfaits sur du vrai logiciel sur mesure terminent presque toujours dans un de ces modes d’échec.

Le prestataire a gonflé le chiffre, et vous avez payé cher un risque qui ne s’est jamais matérialisé. Un bon prestataire sait que “construire un SaaS de gestion de propriétés” porte des inconnues inconnues. Il chiffre le montant qui lui permet de dormir tranquille. Si tout se passe bien, vous venez de payer une prime de 30 à 60% pour le privilège de la certitude. Cet argent serait allé plus loin sur un projet en régie qui aurait fini au même endroit.

Le prestataire a sous-estimé, et il perd maintenant de l’argent sur vous. Le forfait n’aligne les incitations de personne dès qu’un projet bascule dans le rouge. Le seul chemin du prestataire vers la marge est de couper : sauter des tests, recycler du code d’un client précédent, livrer quelque chose dont il ne serait pas fier, mettre un développeur junior sur un problème senior. Vous n’avez aucune visibilité là-dessus tant que le produit ne casse pas en production six mois plus tard.

Le périmètre dérive et la relation s’écroule. Le vrai logiciel se découvre lui-même au fur et à mesure qu’il est construit. Un fondateur voit le deuxième prototype et réalise que le PRD qu’il a écrit au départ était faux. En forfait, chaque nouvelle prise de conscience devient une négociation contractuelle. Le prestataire devient un clipboard. Vous commencez à vous détester avant que le MVP soit livré.

Le prestataire disparaît à 80% du projet. C’est le pire mode d’échec et le plus courant. Le forfait fait que la majeure partie du flux de trésorerie est concentrée sur les milestones tardifs. Quand le prestataire a déjà encaissé le gros du travail facile et que ce qui reste est la partie difficile et ambiguë, partir est rationnel pour lui. On a vu cela arriver dans trois software houses différentes avec trois fondateurs différents. Le motif est identique : un kickoff brillant, des démos hebdomadaires qui ont fière allure, et un déclin silencieux de l’attention à partir du quatrième mois.

On a écrit sur la manière d’évaluer la software house qui va signer ce contrat avant qu’aucune structure contractuelle ne compte. Un mauvais partenaire vous fera défaut sur l’un comme sur l’autre des deux contrats. La structure du contrat fait que l’échec arrive plus vite ou plus lentement. Elle ne change pas le plafond.

Pourquoi la régie est l’option par défaut pour le logiciel sur mesure

La régie a injustement mauvaise réputation parce qu’elle ressemble à un chèque en blanc. Dans une structure saine, c’est l’inverse.

La régie aligne les incitations là où elles doivent l’être. Le prestataire est payé pour livrer du logiciel qui marche à chaque sprint. Vous êtes payé sous forme de logiciel qui marche à chaque sprint. Personne n’est en position de perdre de l’argent sur vous, donc personne n’est en position de couper sur vous. Quand le périmètre change, la conversation est “ça ajoute deux semaines” et non “ça déclenche un avenant qui prendra trois semaines à négocier”. Les décisions tombent plus vite. Le produit sort meilleur.

La régie expose aussi la vérité du travail. Vous voyez les heures, la vélocité, les arbitrages. Dans un projet au forfait, le prestataire a intérêt à vous tenir hors de la réalité d’ingénierie, parce que chaque conversation sur la réalité devient une renégociation. Dans un projet en régie, le prestataire a intérêt à vous faire entrer dans la réalité d’ingénierie, parce que c’est comme ça que vous restez confiant que la facture est juste.

Il y a un coût réel. La régie veut dire que vous portez le risque budgétaire, et que le budget peut déraper. La façon de neutraliser ce risque n’est pas le forfait. C’est une structure de régie qui intègre la responsabilité.

La structure de contrat en régie qui ne vous saigne pas

La plupart des contrats de régie sont trop souples. Le prestataire envoie une facture chaque semaine, le fondateur la paye, et trois mois plus tard personne n’a une vision claire de ce qui a été livré. On utilise une structure plus disciplinée avec chaque fondateur qu’on accompagne. Cinq clauses, toutes négociables, aucune exotique.

Plafond par sprint. Définissez un nombre maximum d’heures par semaine ou par sprint. Le prestataire ne peut pas facturer au-dessus du plafond sans accord écrit, et les dépassements ne se reportent pas. C’est un plafond souple qui maintient l’équipe focalisée sur la livraison de ce qui a le plus de valeur à chaque cycle, plutôt que de moudre des heures sur le ticket qui se trouve ouvert.

Démo ou pas de facture. Chaque sprint se termine par une démo de ce qui a été construit, qui fonctionne. Si la démo n’a pas lieu, le sprint n’est pas facturable. La clause sonne agressive en négociation. En pratique, c’est ce que tout prestataire honnête fait déjà, et la formalité vous protège dans le un sur cinq engagements où l’équipe commence à sauter les démos vers le troisième mois.

Droit de pause à tout milestone. Vous pouvez arrêter le projet à la fin de n’importe quel sprint sans pénalité, sans kill fee, sans clawback. Vous devez les heures déjà effectuées. Point. C’est la clause la plus importante du contrat. Elle transforme la relation en une suite de petits paris, chacun revalidé par ce que le sprint précédent a effectivement livré.

Code dans votre dépôt dès le premier jour. Le code vit dans votre organisation GitHub ou GitLab, pas dans celle du prestataire. Chaque commit poussé par l’équipe est à vous immédiatement, pas en fin de projet. On est entrés dans trop de situations où un fondateur a découvert, lors d’une rupture avec son prestataire, qu’il n’était pas propriétaire du code qui faisait tourner son entreprise. Cette clause rend cette rupture mécaniquement possible.

Un journal de décisions, pas un rapport de statut. Le prestataire tient un journal court et écrit des décisions prises chaque sprint et des arbitrages derrière, dans votre dépôt. Pas une mise à jour des tickets fermés. Une trace de “on a choisi Postgres plutôt que MongoDB pour X”, “on a différé le travail multi-tenant à cause de Y”. Le journal est ce qui permet à un ingénieur futur, y compris celui qui remplacera cette équipe, de comprendre pourquoi le système a la forme qu’il a. C’est aussi ce qui rend le futur transfert survivable.

Un contrat de régie avec ces cinq clauses vous donne presque toute la sécurité du forfait, presque aucun de ses dégâts d’incitation, et un niveau de visibilité sur le travail que le forfait vous cache activement. On appelle cela la régie à milestones, et on demande à chaque fondateur de la négocier avant que le moindre travail démarre.

Quand choisir vraiment le forfait (et ce qu’il faut payer en plus pour le rendre réel)

Il existe un cas étroit pour le forfait, même sur du vrai logiciel sur mesure. Il s’applique quand vous avez une échéance externe dure que le prestataire ne peut pas rater, le périmètre est exceptionnellement bien défini, et le prestataire a déjà construit exactement cette forme de chose. Une date de mise en ligne imposée par un régulateur, une intégration avec un client phare dont la date de démarrage est verrouillée par contrat, une démo prévue pour un conseil d’administration déjà calé.

Dans ces cas, le forfait n’est pas vraiment une affaire d’économies. C’est l’achat d’une assurance livraison. Pour que cette assurance soit honnête, trois choses doivent être vraies.

Le prestataire intègre une vraie prime de risque, et vous l’acceptez. Si le devis paraît suspicieusement bas pour un forfait, partez. Le prestataire ne comprend pas le travail ou prévoit de couper.

Vous pré-négociez le protocole de changement de périmètre avant de signer. Pas “on verra les avenants quand ils se présenteront”. Un processus écrit qui dit : un avenant en dessous de X euros est validé par mail ; au-dessus de X il déclenche une fenêtre de 48 heures pour rechiffrage et un re-baseline du planning. Cela rend les inévitables changements de périmètre gérables au lieu d’être relationnellement fatals.

Vous gardez au moins 25% de la valeur du contrat sur le dernier milestone, payable uniquement contre livraison complète et un test d’acceptation convenu. C’est le levier qui empêche la sortie à 80%. Le montant que vous gardez à la fin est ce que le prestataire ne peut pas se permettre de laisser sur la table.

Si vous n’obtenez pas les trois, le contrat au forfait est du théâtre. Passez en régie à milestones et arrêtez de négocier contre vous-même.

FAQ rapide

Quelle est la différence entre forfait et régie en langage simple ?
Le forfait est un montant unique pour un périmètre convenu. La régie est le compteur qui tourne sur le temps que l’équipe passe réellement. Le prestataire prend le risque de livraison sur le forfait. Vous prenez le risque de budget en régie, et l’essentiel se neutralise avec les bonnes clauses.

Quelle est la différence entre forfait et un retainer à honoraire fixe ?
Un retainer est un honoraire fixe récurrent pour un périmètre récurrent, en général continu plutôt qu’attaché à un livrable précis. C’est plus proche d’une régie plafonnée que d’un forfait projet. Les retainers fonctionnent bien après que la première version du produit est en ligne, quand l’équipe itère plutôt que de construire à partir de zéro.

Existe-t-il un modèle hybride ?
Oui, et c’est parfois la bonne réponse. Le motif le plus utile qu’on voit est une phase de discovery courte au forfait (deux à quatre semaines, avec un périmètre limité à produire une architecture écrite et une spécification produit signée) suivie d’une régie à milestones pour la construction. La discovery est peu coûteuse, le périmètre est réellement connu à la fin, et vous démarrez le vrai travail avec un prestataire qui a déjà prouvé qu’il sait écouter.

Qui décide lequel on signe ?
Vous, pas le prestataire. Les prestataires préfèrent le forfait quand ils essaient de verrouiller du chiffre d’affaires, et la régie quand ils pensent que le périmètre va grossir. La bonne structure est celle qui correspond au projet, pas celle qui correspond au trimestre du prestataire.

Le type de contrat doit-il évoluer à mesure que l’entreprise grandit ?
Probablement. Le logiciel sur mesure en phase initiale, avec un produit encore en cours de découverte, veut presque toujours de la régie à milestones. Une fois qu’un système est en production et que l’équipe itère sur une forme connue, des retainers au forfait peuvent bien fonctionner. C’est la même logique qui s’applique à recruter un CTO trop tôt : le contrat est un outil, pas une identité.

Le contrat est la relation. Choisissez la structure qui vous laisse construire la chose que vous voulez vraiment, avec les gens en qui vous avez vraiment confiance. Puis négociez les clauses qui rendent l’une ou l’autre structure honnête. Le chiffre de la page un compte moins que les cinq lignes de la page sept.