Le forfait convient aux projets dont le besoin est précisément décrit et stable : le prix et le périmètre sont fixés à l’avance, et le prestataire porte le risque de dépassement. La régie convient aux projets dont le besoin va évoluer : vous payez le temps passé et vous pilotez les priorités, mais vous portez le risque budgétaire. Pour la plupart des applications métier, la meilleure option est le forfait par lots : un cadrage, puis des lots successifs chiffrés au forfait une fois leur contenu précisé.
Le choix du contrat ne se résume pas à une question de prix. Il détermine qui porte le risque, comment se traitent les changements et quelle relation vous aurez avec votre prestataire pendant des mois.
Que recouvrent le forfait, la régie et le forfait par lots ?
Un contrat au forfait est un engagement à livrer un périmètre défini, pour un prix et dans un délai convenus à l’avance. Le prestataire est payé pour un résultat : si le travail prend plus de temps que prévu, c’est à sa charge.
Un contrat en régie (ou « au temps passé ») est un engagement à mettre à disposition des compétences, facturées au temps réellement consacré au projet. Le client définit les priorités ; le prestataire s’engage sur la qualité de son travail, pas sur un périmètre fini.
Un forfait par lots découpe le projet en étapes, chacune chiffrée au forfait lorsque son contenu est suffisamment connu. Le premier lot est généralement le cadrage ; les suivants correspondent à des ensembles de fonctionnalités livrables et utilisables. Entre deux lots, le client peut réorienter le projet, voire l’arrêter.
Qui porte le risque, et à quel prix ?
| Critère | Forfait | Régie | Forfait par lots |
|---|---|---|---|
| Prix | Fixé à l’avance | Variable, selon le temps passé | Fixé lot par lot |
| Périmètre | Figé au contrat | Ajustable en continu | Figé par lot, ajustable entre les lots |
| Risque de dépassement | Prestataire | Client | Partagé, limité à un lot |
| Prérequis | Besoin détaillé et stable | Client disponible pour piloter | Cadrage initial |
| Gestion des changements | Avenants | Repriorisation | Entre les lots, ou échange de fonctionnalités |
| Risque principal | Marge de risque élevée, rigidité | Dérive budgétaire | Discipline de découpage nécessaire |
Le forfait a un coût caché : la marge de risque. Steve McConnell montre dans son livre blanc sur le cône d’incertitude qu’un engagement pris au stade du concept initial ou de la définition du produit comporte une erreur d’estimation d’un facteur 2 à 4. Un prestataire qui s’engage sur un prix ferme à ce stade doit couvrir cette incertitude : soit en gonflant son prix, soit en interprétant le périmètre de façon restrictive. Dans les deux cas, c’est le client qui paie.
Pourquoi le forfait classique s’accorde mal avec un projet qui apprend ?
Une application métier se découvre en partie en la construisant. Les premiers écrans montrés aux utilisateurs font apparaître des cas oubliés, des règles mal comprises, des fonctionnalités finalement inutiles. C’est une bonne nouvelle : c’est ainsi qu’on obtient un outil réellement adopté.
Le Manifeste agile en a fait l’une de ses valeurs : privilégier « la collaboration avec les clients plus que la négociation contractuelle » et « l’adaptation au changement plus que le suivi d’un plan ». Un forfait à périmètre figé fait l’inverse : chaque apprentissage devient un avenant à négocier.
Martin Fowler propose une sortie dans son article Fixed Price : on peut fixer le prix et la date, mais pas le périmètre. Le contrat fixe un budget et une échéance ; les fonctionnalités sont choisies ensemble au fil du projet, en commençant par les plus utiles. Il note aussi que ce fonctionnement permet au client d’arrêter plus tôt un projet qui ne tient pas ses promesses, parce que les écarts deviennent visibles rapidement.
Comment fonctionne un forfait par lots en pratique ?
Voici un déroulé type pour une application métier :
- Lot 0, le cadrage, au forfait. Ateliers, parcours utilisateurs, maquettes, architecture, découpage en lots et estimation argumentée. Livrable : un périmètre priorisé, que vous pouvez confier à n’importe quel prestataire. Voir notre article sur la phase de cadrage.
- Lot 1, le noyau utile, au forfait. Le parcours principal, mis en production auprès d’un groupe d’utilisateurs. Son contenu est décrit en user stories avec des critères d’acceptation, ce qui rend le forfait vérifiable.
- Lots suivants, au forfait. Chacun est précisé et chiffré à la fin du précédent, à partir des retours des utilisateurs.
- Au sein de chaque lot, des itérations courtes avec démonstration. Le Guide Scrum recommande des sprints d’un mois au plus ; deux semaines est un rythme courant. Notre article sur la livraison à chaque sprint explique pourquoi ce rythme protège le client.
Une variante utile est l’échange de fonctionnalités : à l’intérieur d’un lot, le client peut remplacer une fonctionnalité non commencée par une autre de taille équivalente, sans avenant. Elle donne de la souplesse sans rouvrir le prix.
La régie présente-t-elle des risques juridiques ?
Oui, si elle est mal organisée. Le Code du travail interdit le prêt de main-d’œuvre à but lucratif lorsqu’il constitue l’objet exclusif de l’opération, en dehors des cas prévus (travail temporaire notamment). Il réprime aussi le marchandage, défini comme une fourniture de main-d’œuvre à but lucratif qui cause un préjudice au salarié ou permet d’éluder la loi ou une convention collective.
Une prestation en régie reste légale quand elle porte sur une véritable prestation de services. En pratique, quelques précautions limitent le risque :
- le prestataire encadre lui-même son équipe : le client exprime des besoins et des priorités, il ne donne pas d’ordres directs aux développeurs ;
- la prestation porte sur un objet défini (un projet, un ensemble de fonctionnalités), avec une expertise propre au prestataire ;
- l’équipe n’est pas intégrée à l’organisation du client comme le seraient des salariés (horaires imposés, entretiens annuels, etc.).
Ces points relèvent du droit du travail : pour un dispositif de régie important ou de longue durée, faites relire le contrat par votre conseil juridique.
Quel contrat choisir selon votre situation ?
| Votre situation | Contrat recommandé |
|---|---|
| Besoin simple, bien décrit, peu susceptible d’évoluer | Forfait |
| Projet neuf, besoin à découvrir avec les utilisateurs | Cadrage au forfait, puis forfait par lots |
| Produit SaaS ou application en évolution permanente | Régie plafonnée avec démonstrations régulières |
| Refonte d’une application existante bien documentée | Forfait par lots, module par module |
| Maintenance et petites évolutions | Abonnement de maintenance et volume de jours |
| Besoin urgent et ponctuel d’expertise | Régie, avec un objet de mission précis |
Quelles clauses vérifier, quel que soit le contrat ?
Le mode de facturation compte moins que la qualité des clauses. Vérifiez au minimum :
- la définition des livrables : fonctionnalités, documentation, code source, environnements ;
- la procédure de recette : durée, critères d’acceptation, traitement des anomalies selon leur gravité, procès-verbal ; voir notre guide pour réussir la recette ;
- la gestion des changements : comment une demande est formulée, chiffrée, validée ;
- les plafonds et le reporting en régie : nombre de jours maximum par période, relevé détaillé du temps passé ;
- la propriété du code et la cession des droits, la remise des accès et de la documentation ;
- la réversibilité : conditions de transfert à un autre prestataire en fin de contrat ;
- la garantie et la maintenance après la mise en production.
Ces critères complètent ceux de notre article sur le choix d’une agence de développement.
Ce qu’il faut retenir
Le forfait protège votre budget quand le besoin est connu ; la régie protège votre capacité d’adaptation quand il ne l’est pas ; le forfait par lots vous donne les deux, à condition de commencer par un cadrage. Dans tous les cas, ce sont les démonstrations régulières et des clauses claires qui vous protègent vraiment.
Vous hésitez sur le bon cadre pour votre projet ? Décrivez-le dans notre diagnostic de projet : nous vous indiquerons le découpage et le mode de contrat qui nous paraissent les plus adaptés.
