Forfait ou régie : pourquoi nous ne facturons jamais à l’heure

Forfait ou régie : la définition en deux phrases

Un contrat en régie facture le temps passé par les développeurs, au jour ou à l’heure. Un contrat au forfait facture un résultat défini (un périmètre, un délai) pour un prix fixé à l’avance. Dans le premier cas, le client porte le risque de dérive. Dans le second, c’est le prestataire.

Cette distinction paraît simple. Elle détermine pourtant qui a intérêt à aller vite, qui a intérêt à rallonger, et qui paie quand un imprévu survient. C’est pour cette raison que nous ne facturons jamais à l’heure, et que nous expliquons ici dans quels cas ce choix est le bon, et dans quels cas il ne l’est pas.

Comparatif : régie et forfait sur six critères

Les comparatifs publiés sur le sujet convergent sur les quatre premières lignes. La dernière est celle qu’ils traitent le moins, et c’est celle qui compte le plus aujourd’hui.

Pourquoi l’IA rend la facturation à l’heure plus difficile à défendre

Un assistant de code change le rapport entre le temps passé et la valeur livrée. Une fonctionnalité qui demandait trois jours peut en demander un. Le lien entre heures facturées et valeur livrée se relâche, et ce relâchement joue contre le client en régie : le prestataire qui travaille plus vite gagne moins, celui qui travaille plus lentement gagne plus.

Ce n’est pas une accusation de mauvaise foi. C’est un effet de structure. Quand le revenu dépend des heures, l’amélioration de la productivité devient un manque à gagner pour celui qui la réalise. Au forfait, elle devient une marge, et une partie peut être redistribuée au client sous forme de prix ou de périmètre.

Pour mesurer ce que l’IA change réellement dans un projet, lisez notre article sur la livraison d’un produit en 90 jours. Le point à retenir ici : plus l’exécution est rapide, plus la précision du périmètre devient le vrai sujet.

Comment nous cadrons un forfait

Un forfait ne vaut que ce que vaut son cadrage. Voici la séquence que nous suivons, dans l’ordre.

1. Définir le résultat observable. Une phrase du type « un utilisateur peut faire X et voir Y », pas une liste de fonctionnalités techniques.
2. Lister ce qui est exclu. Chaque exclusion écrite évite une discussion plus tard.
3. Fixer le délai. Nos projets visent environ 90 jours entre le cadrage et la mise en production.
4. Nommer les hypothèses. Accès aux données, disponibilité d’un interlocuteur, services tiers : chaque hypothèse non tenue déclenche une discussion explicite.
5. Prévoir un mécanisme de changement. Un ajout de périmètre est chiffré avant d’être réalisé, avec ce qu’il remplace ou ce qu’il décale.
6. Définir la recette. Les critères d’acceptation sont écrits avant le développement, pas après.

Cette méthode ne supprime pas l’incertitude. Elle la rend visible et lui donne un propriétaire. Vous pouvez comparer cette logique avec nos formules et nos prix, qui reposent sur ce principe.

Quand le forfait N’EST PAS le bon choix

Le forfait est un mauvais outil dans quatre situations. Nous les refusons ou nous les redirigeons.

• Le besoin n’est pas encore compris. Si vous ne pouvez pas décrire le résultat attendu en une phrase, un prix fixe ne fait que cacher l’incertitude. Une phase courte d’exploration, facturée séparément, est plus honnête.
• Le périmètre évolue chaque semaine. Un produit dont la direction dépend des retours utilisateurs quotidiens s’accommode mal d’un cahier des charges figé. Une régie encadrée par un plafond mensuel convient mieux.
• Vous cherchez du renfort dans votre équipe. Si l’objectif est d’ajouter une compétence à une équipe existante, qui dirige le travail, c’est de la mise à disposition. La régie est le modèle naturel.
• La maintenance est le sujet. Une application déjà en production demande des interventions de nature variable. Un forfait de maintenance mensuel avec un volume défini fonctionne, un forfait « tout compris » non.

Le modèle hybride, souvent cité par les prestataires, répond à une partie de ces cas : le périmètre clair au forfait, la zone floue en régie plafonnée. Il demande davantage de discipline des deux côtés, car la frontière entre les deux zones doit être écrite.

Les cinq questions à poser avant de signer, quel que soit le modèle

Ces questions valent pour un contrat en régie comme pour un forfait. Un prestataire qui y répond précisément est un prestataire qui a déjà cadré des projets. Pour estimer la partie technique d’un budget, consultez aussi les choix de stack et leurs coûts pour un MVP suisse.

Le forfait déplace le risque, il ne le supprime pas

Un prix fixe ne protège pas d’un mauvais cadrage. Il le fait simplement payer par l’autre partie. Si le prestataire sous-estime, il rogne sur la qualité ou sur les tests. Si le client sur-spécifie, il paie une marge de risque pour des fonctionnalités dont il n’aura peut-être pas besoin.

C’est pourquoi le forfait fonctionne le mieux quand le prestataire a livré des produits comparables et connaît ses propres écarts d’estimation. Posez la question : combien de projets similaires, et avec quel écart entre l’estimation et le réel ? Une réponse vague est une information.

Le coût d’une fonctionnalité IA mérite une attention particulière, car il comprend des postes qui n’existent pas dans un logiciel classique, comme l’évaluation et l’inférence. Notre analyse du coût réel d’une fonctionnalité IA en production détaille ces postes. Un forfait sérieux les inclut ou les exclut par écrit.

Cinq signaux d’alerte dans une proposition commerciale

Quel que soit le modèle annoncé, certaines formulations révèlent un cadrage insuffisant. Voici ce que nous repérons en premier quand nous relisons une proposition reçue par un client.

• Un périmètre décrit par des verbes vagues. « Mise en place », « intégration » ou « optimisation » sans résultat observable ne peuvent pas être recettés.
• Aucune exclusion mentionnée. Une proposition sans exclusion écrite laisse chaque désaccord futur se résoudre au rapport de force.
• Un forfait dont le prix ne varie jamais avec le périmètre. Si retirer une fonctionnalité ne change pas le prix, le prix n’a pas été construit à partir du périmètre.
• Une régie sans plafond ni point de revue. Sans plafond mensuel et sans revue régulière, le budget devient une estimation que personne n’est tenu de respecter.
• Un calendrier sans jalon intermédiaire. Un projet de plusieurs semaines sans démonstration intermédiaire repousse la découverte des problèmes à la fin, quand ils coûtent le plus cher.

Aucun de ces signaux ne prouve à lui seul qu’un prestataire est mauvais. Plusieurs ensemble indiquent que le risque n’a pas été réparti, mais simplement déplacé vers vous.

Les erreurs que nous voyons côté client

Le choix du modèle de facturation n’est qu’une partie du sujet. Trois erreurs reviennent souvent, indépendamment du contrat signé.

Choisir le modèle sur le prix de départ. Une régie paraît moins chère parce que son prix initial est une estimation basse, que la réalité corrige rarement à la baisse. Comparez les budgets finaux probables, pas les chiffres de la première page.

Confondre flexibilité et absence de décision. La régie permet de changer d’avis, mais chaque changement consomme du temps et donc du budget. Un client qui n’arbitre pas rapidement paie son indécision au tarif journalier.

Oublier la période après livraison. Un produit mis en production demande des corrections, de la surveillance et des ajustements. Si le contrat n’en parle pas, ces coûts arrivent comme une surprise, quel que soit le modèle.

Ce que nous recommandons selon votre situation

• Vous lancez un produit et le résultat est clair : forfait, avec exclusions écrites et recette définie.
• Vous explorez un besoin flou : une courte phase d’exploration, puis forfait sur ce qui en ressort.
• Vous renforcez votre équipe : régie, avec un plafond et une revue mensuelle.
• Vous avez une application en production : forfait de maintenance au volume défini, plus devis pour les évolutions.

Notre règle est simple : si nous ne pouvons pas décrire le livrable, nous ne chiffrons pas, nous cadrons d’abord. Retrouvez nos réalisations pour voir ce que ce cadre donne en pratique.