Forfait ou régie : comment choisir pour un logiciel métier

La question revient dans presque tous les projets de logiciel métier : faut-il acheter une prestation au forfait, ou faire venir des développeurs en régie ? Elle est souvent tranchée par habitude, par la politique achats, ou par le format du dernier appel d'offres. Elle mérite mieux, parce que les deux contrats n'achètent pas la même chose et ne placent pas le risque au même endroit.

Deux façons d'acheter, deux objets achetés

La régie achète du temps

En régie, vous achetez une capacité de production : un ou plusieurs profils, facturés à la journée ou au mois, qui travaillent sous votre pilotage. Le prestataire s'engage sur la compétence et la disponibilité, pas sur le résultat. C'est vous qui définissez les priorités, arbitrez les fonctionnalités, organisez la recette et décidez quand le produit est fini.

Ce modèle a une vraie cohérence dans un cas précis : quand vous avez déjà une direction technique, une vision produit installée, et que vous voulez simplement augmenter une équipe existante sur une durée longue. La régie est alors un renfort, pas une externalisation.

Le forfait achète un résultat

Au forfait, vous achetez un produit défini pour un prix fixe. Le prestataire s'engage sur le périmètre, le délai et le montant ; il assume l'organisation interne, les choix techniques et les aléas. Si le développement prend deux fois plus de temps que prévu, c'est son problème, pas votre facture.

Le forfait suppose donc une chose non négociable : que le périmètre soit réellement fermé avant de chiffrer. Sans cela, le prestataire se protège par une marge que vous payez, ou par des avenants que vous découvrirez en cours de route.

Où va le risque

C'est la seule question qui compte vraiment, et elle se résume en une ligne : en régie, le risque de dérapage reste chez le client ; au forfait, il passe chez le prestataire.

Ce transfert a un prix, et il est légitime. Une entreprise qui s'engage sur un montant ferme doit couvrir l'incertitude qui reste après le cadrage. Plus le cadrage est solide, plus cette marge diminue, jusqu'à devenir marginale quand le périmètre a été fermé sur un objet visible. C'est exactement le rôle du prototype visuel gratuit : il transforme une incertitude coûteuse en un accord explicite.

En régie, l'absence de marge apparente se paie ailleurs. Le pilotage revient à votre encadrement, souvent à des personnes dont ce n'est pas le métier principal. Les arbitrages fonctionnels se font en réunion plutôt que dans un contrat. Et surtout, le compteur ne s'arrête que le jour où quelqu'un décide de l'arrêter.

Les trois questions qui tranchent

Qui décide de ce qui est fini ? Si personne dans votre organisation n'a le temps ni le mandat de trancher chaque semaine, la régie produira un projet qui s'étire. Le forfait impose la décision en amont, une fois, au moment où elle est la moins coûteuse.

Combien de temps le besoin va-t-il rester stable ? Un besoin qui change toutes les deux semaines par nature, par exemple une plateforme en recherche de son marché, s'accommode mal d'un engagement ferme. Un besoin métier identifié, avec des règles connues et des utilisateurs déjà en poste, se chiffre très bien.

Que se passe-t-il à la fin ? En régie, quand la mission s'arrête, il reste du code et personne pour l'exploiter. Au forfait, la question de l'hébergement, de la supervision et des évolutions se pose dans le contrat, au même moment que le reste. C'est souvent ce point, plus que le prix, qui départage les deux modèles à l'usage.

Le piège du forfait mal cadré

Le forfait a mauvaise réputation dans certaines organisations, et pour une bonne raison : mal cadré, il produit exactement ce qu'on lui reproche. Un prestataire qui chiffre sur des spécifications ouvertes livrera la lecture la moins coûteuse de chaque phrase ambiguë, puis facturera le reste en avenants. Le client a l'impression d'avoir acheté un prix fixe ; il a acheté une base de négociation.

Les signes d'un forfait fragile sont reconnaissables. Le chiffrage arrive très vite, sans atelier de cadrage. Le périmètre est décrit par une liste de fonctionnalités sans écrans. Le contrat parle de jours-hommes plutôt que de livrables. Et personne n'a encore vu à quoi ressemblera l'application.

Un forfait solide se reconnaît à l'inverse : le périmètre a été rendu visible avant la signature, les livrables sont décrits comme des résultats utilisables, et les évolutions hors périmètre ont une procédure connue à l'avance.

Notre position : zéro régie

LPR Studio ne vend ni heures ni personnel. Ce n'est pas une posture commerciale, c'est une conséquence du reste de notre fonctionnement : nous livrons un produit fini, déployé et maintenu, et cet engagement n'a de sens que si nous portons le risque de sa fabrication.

Concrètement, nos trois formules reposent toutes sur un résultat. Le développement au forfait part du prototype validé ensemble et va jusqu'au produit déployé, à prix fixe. La formule abonnement va plus loin : vous ne payez pas le développement, seulement un abonnement mensuel qui couvre l'hébergement, la maintenance et les évolutions, ce qui suppose que nous restions éditeur et exploitant de l'application. L'édition de produits SaaS, enfin, concerne les applications que nous exploitons pour plusieurs clients.

Dans les trois cas, la même règle : vous jugez sur un produit, pas sur un relevé d'heures. Ce que coûte ce produit, et ce qui fait varier son prix, est détaillé dans cet article.