Contrat Au Forfait Ou Régie ?

Le choix entre un contrat au forfait et la régie est presque toujours présenté comme un arbitrage de risque, ce qui est exact, puis immédiatement mal traité, parce que les deux parties supposent que le risque disparaît alors qu’il ne fait que changer de camp.

Il ne disparaît pas. Au forfait, le prestataire porte le risque d’une estimation fausse et intègre ce risque dans le chiffre annoncé. En régie, c’est le client qui le porte. La question n’est jamais de savoir quelle formule supprime l’incertitude. Elle est de savoir quelle partie est la mieux placée pour la gérer, et si le prix du transfert vaut la peine d’être payé.

Le test qui prédit ce qui va marcher : êtes-vous capable d’écrire ce que « terminé » signifie, avec assez de précision pour que deux personnes soient d’accord sur le fait que ce point est atteint ? Si oui, le forfait vous est accessible et il est sans doute pertinent. Sinon, un contrat au forfait ne supprime pas l’ambiguïté, il transforme simplement chaque désaccord futur en négociation commerciale au lieu d’une discussion technique.

Ce qu’un contrat au forfait achète réellement

La certitude sur la facture, et rien d’autre. Il n’achète en particulier aucune certitude sur le résultat, sur la date ou sur la qualité, alors que beaucoup d’acheteurs supposent que tout cela vient avec.

Il a aussi un prix. Un prestataire qui chiffre au forfait ajoute une provision pour risque, puisqu’il absorbe le dépassement, et le montant de cette provision augmente à mesure que la spécification est vague. Sur un périmètre bien défini, elle reste modeste. Sur un périmètre flou, elle peut approcher le coût du travail lui-même, et vous la payez que le risque se réalise ou non.

Le second coût est comportemental. Une fois le prix figé, chaque ambiguïté se tranche dans le sens du moindre travail, parce que c’est désormais là que se situe l’intérêt du prestataire. Ce n’est pas de la mauvaise foi, c’est l’incitation créée par le contrat lui-même. Un prestataire qui repère une meilleure approche en cours de route n’a aucune raison de la proposer, et un client qui comprend qu’une exigence était fausse se retrouve face à une demande de changement plutôt qu’à une conversation.

Le forfait fonctionne bien sur un travail réellement borné : une migration dont la source et la cible sont connues, une intégration avec une API documentée, un ensemble défini d’écrans à partir d’une maquette validée. Il fonctionne mal dès que le travail devient exploratoire.

Quand la régie coûte moins cher

Contre toute intuition, c’est souvent le cas, parce que vous ne payez ni la provision pour risque ni le traitement des demandes de changement.

Elle convient au travail dont le périmètre va légitimement bouger : une première version dont la direction dépend de ce que font les utilisateurs, une intégration avec un système que personne n’a documenté, la reprise d’une base de code dont l’état reste inconnu tant que personne n’a regardé. Dans tous ces cas, un forfait est en réalité un forfait sur une supposition.

Ce qu’elle exige du client, c’est de l’attention. La régie sans implication devient une facture ouverte, et le mode de défaillance classique est un projet qui tourne pendant des mois sans que personne demande ce qui a été livré la semaine précédente. Le contrôle n’est pas contractuel, il est opérationnel : un backlog visible, une démonstration à intervalle régulier, et une personne côté client habilitée à changer les priorités.

Si personne chez vous ne peut fournir cette attention, dites-le franchement, car la régie fonctionnera mal et aucune clause ne corrige cela.

L’option que la plupart des projets devraient retenir

Un dispositif plafonné ou découpé en phases, qui n’est ni l’un ni l’autre et convient à davantage de projets logiciels que les deux formules pures.

Régie plafonnée. Le travail est facturé au temps passé, avec un plafond. Le client garde la souplesse de changer de direction et le prestataire porte le risque résiduel au-delà du plafond. Les deux parties conservent un intérêt à l’efficacité, ce qu’aucun des deux modèles purs ne produit.

Forfait par phases. Un cadrage court et payant produit une spécification, et c’est seulement ensuite que la réalisation est chiffrée au forfait, sur une base réelle. C’est la version honnête du forfait, puisque l’estimation intervient après réduction des inconnues et non avant. Notre guide de l’appel d’offres logiciel détaille ce que cette spécification doit contenir.

Forfait par incrément. Chaque phase est chiffrée séparément et validée séparément. Vous obtenez une prévisibilité budgétaire par tranches et la possibilité d’arrêter, qui est le droit le plus précieux d’un client et précisément celui que les longs contrats au forfait suppriment.

Le fil conducteur est le même : la précision des estimations progresse énormément une fois qu’une partie du travail a été faite. Construire le montage commercial de façon à en profiter vaut davantage que n’importe quelle clause.

Où les projets au forfait échouent vraiment

Pas sur le prix. Sur la frontière entre périmètre et changement.

Tout projet au forfait génère des demandes de changement, parce que les spécifications sont écrites avant que quiconque ait utilisé le produit. La santé du dispositif dépend entièrement de la façon dont elles sont traitées, et cela se joue sur la précision avec laquelle le périmètre a été défini au départ, pas sur la bonne volonté des uns et des autres.

Deux choses réduisent les frictions. Convenez par écrit de ce qui arrive à un changement : qui l’évalue, sur quelle base il est chiffré, et dans quel délai. Et gardez aussi une provision côté client, car un forfait sans budget de changement chez le client transforme chaque découverte en dispute.

L’autre échec courant porte sur la recette. Si le contrat ne définit pas comment l’achèvement se démontre, le paiement final devient une négociation d’opinions. Écrivez les critères de recette à côté du périmètre, et préférez des critères que quelqu’un peut tester à des critères que quelqu’un doit apprécier.

Choisir en pratique

Demandez ce qui est réellement inconnu. Si la réponse est « très peu de choses », le forfait est raisonnable et vous devez vous attendre à payer une provision pour cette certitude. Si beaucoup reste inconnu, un forfait ne fait que convertir l’incertitude technique en friction commerciale.

Demandez ensuite ce que vous pouvez suivre. La régie récompense l’attention et sanctionne son absence. Le forfait vous demande moins semaine après semaine et davantage en amont, dans la spécification, là où les erreurs coûtent moins cher mais se repèrent plus difficilement.

Demandez enfin ce que vaut la certitude. Il arrive qu’un conseil d’administration ait besoin d’un chiffre, et la provision est alors un prix équitable. C’est une raison légitime de choisir le forfait, et une bien meilleure raison que de croire qu’il supprime le risque.

Mecanik travaille selon les trois formules dans le cadre de son service de développement logiciel, et recommande le plus souvent la version par phases. L’estimation produite après deux semaines de cadrage vaut davantage que celle produite avant, pour les deux parties.

Questions fréquentes

Un contrat au forfait est-il plus sûr que la régie ? Il est plus prévisible, ce qui n’est pas la même chose. Le forfait transfère le risque d’estimation au prestataire, qui l’intègre au prix sous forme de provision, si bien que vous le payez qu’il se réalise ou non. Il achète la certitude sur la facture, pas sur le résultat, la date ou la qualité.

Quand la régie revient-elle moins cher ? Quand le périmètre va légitimement bouger : une première version dont la direction dépend du comportement des utilisateurs, une intégration avec un système non documenté, ou un travail sur une base de code dont l’état reste inconnu tant que personne n’a regardé. Vous évitez alors la provision pour risque et le coût des demandes de changement, car un forfait serait ici un forfait sur une supposition.

Qu’est-ce que la régie plafonnée ? Un travail facturé au temps passé avec un plafond convenu. Le client garde la souplesse de changer de direction pendant que le prestataire porte le risque au-delà du plafond. Les deux parties gardent un intérêt à l’efficacité, ce que ni le forfait pur ni la régie pure ne parviennent à produire.

Pourquoi les projets logiciels au forfait tournent-ils mal ? Presque toujours à la frontière entre périmètre et changement, pas sur le prix. Les spécifications sont écrites avant que quiconque ait utilisé le logiciel, donc les demandes de changement sont inévitables. La santé du projet dépend d’un accord préalable sur qui évalue un changement et sur la façon dont il est chiffré, et sur le fait que le client garde sa propre provision.

Faut-il définir les critères de recette dans le contrat ? Oui, à côté du périmètre. Sans moyen défini de démontrer l’achèvement, le paiement final devient une négociation d’opinions. Préférez des critères que quelqu’un peut tester à des critères que quelqu’un doit apprécier, car les critères testables tranchent les désaccords alors que les critères d’appréciation les prolongent.