
La facturation horaire est cassée : elle récompense la lenteur. Comment cadrer un projet logiciel au forfait, quand cela échoue et pourquoi cela marche.
Je n'ai pas facturé à l'heure depuis trois ans. Chaque projet que nous livrons est au forfait, validé avant le début du travail, payé par étapes. Certains clients résistent. Ils veulent de l'horaire parce que cela leur paraît plus sûr : ils pensent acheter de la souplesse. Ce n'est pas le cas. Ils achètent un ensemble d'incitations qui jouent contre eux.
L'argument n'est pas nouveau. Les consultants plaident contre la facturation horaire depuis des décennies. Ce qui est nouveau, c'est que pour le logiciel, l'argument est devenu écrasant. Et pourtant, la plupart des studios chiffrent encore en heures. Voici donc la version que je donne quand un client me demande pourquoi nous travaillons ainsi.
Ce que récompense vraiment la facturation horaire
La facturation horaire récompense le studio qui prend plus de temps. Ce n'est pas une faute morale, c'est de l'arithmétique. Si un ingénieur senior livre une fonctionnalité en huit heures et un junior en quarante, le studio qui facture à l'heure gagne cinq fois plus en confiant le travail au junior. Le senior est pénalisé pour sa rapidité.
Les studios qui facturent à l'heure prennent l'habitude de staffer leurs projets avec ceux qui ne peuvent pas finir vite. Pas toujours consciemment. Mais le calcul tourne en arrière-plan de chaque décision d'affectation, et avec le temps, il façonne le studio.
Le forfait inverse la logique. Si le prix est fixé, le studio est récompensé quand il livre plus vite. L'ingénieur senior qui termine en huit heures devient cinq fois plus rentable que le junior. D'un coup, le studio veut le senior sur chaque projet. Le client obtient un meilleur travail, plus vite, pour le même prix.
Ce que la facturation horaire prétend être
L'argument de l'horaire, c'est que le client ne paie que ce qui est livré. Ce n'est pas ce que fait l'horaire. Il facture le temps passé, ce qui n'est pas la même chose que le travail livré. Le studio facture les heures déclarées par son équipe. Que ces heures aient produit quelque chose est une autre question.
J'ai lu des centaines de factures horaires. Appel de découverte : 1,5 h. Revue interne : 2 h. Discussion Slack : 0,75 h. Ce sont de vraies lignes, vues sur de vraies factures. Aucune n'a produit quoi que ce soit d'utilisable par le client. Toutes ont été facturées.
La facturation horaire est une taxe que le client paie chaque fois que le studio pense à son projet.
Le client ne peut pas contester ces lignes, faute de moyen de les vérifier. La revue interne était-elle nécessaire ? La discussion Slack était-elle utile ? Le studio le sait. Le client, non. L'asymétrie d'information est le modèle économique.
Ce que le forfait exige du studio
Pour chiffrer au forfait, le studio doit vraiment comprendre le travail. Cela paraît évident. Ça ne l'est pas. L'horaire permet de rester flou sur le périmètre et de le découvrir en avançant. Le forfait oblige le studio à faire ses devoirs avant de chiffrer.
Nous passons deux à quatre heures par prospect avant de chiffrer. Pas du conseil gratuit : du chiffrage. Lire le code s'il existe. Comprendre le modèle de données. Cartographier les parcours utilisateurs. Quand nous envoyons un montant, nous savons à vingt pour cent près ce que le travail nous coûtera. Nous absorbons cette marge de vingt pour cent. Le client n'en absorbe rien.
C'est plus de travail pour nous que d'envoyer une grille tarifaire horaire. C'est aussi la seule façon honnête de faire. Un studio qui chiffre au forfait sans ce travail soit surfacture par prudence, soit sous-chiffre et en veut au client dès le deuxième mois. Ni l'un ni l'autre n'est tenable.
Ce que le forfait exige du client
Le forfait exige aussi que le client décide de ce qu'il veut avant le début du travail. C'est là qu'échouent la plupart des projets au forfait : le client valide un périmètre, puis change d'avis la troisième semaine.
La réponse honnête, c'est un processus écrit de modification. Un nouveau périmètre, c'est un nouveau devis. Pas négociable, pas absorbé discrètement dans le projet existant. Nous avons un modèle d'avenant. Le client le signe. Le travail est fait. Cela paraît bureaucratique. C'est l'inverse : c'est ce qui empêche la rancœur lente qui s'installe quand un studio absorbe en silence les dérives de périmètre.
Certains clients protestent. Vous ne pouvez pas simplement le faire ? La réponse honnête est non. Le faire simplement, c'est ainsi que se sont mal passés tous les projets que j'ai vus mal tourner. L'avenant est la friction qui garde les deux parties honnêtes.
Quand le forfait échoue
Le forfait échoue sur deux types de projets.
- La vraie R&D. Si ni le studio ni le client ne savent ce qui sera construit, le forfait ne peut pas être chiffré. Le bon modèle est alors une phase d'exploration limitée dans le temps, facturée à prix fixe, qui se termine par un périmètre écrit, lui, chiffrable au forfait. Sautez l'exploration en faisant comme si le périmètre était connu, et le projet se passe mal pour tout le monde.
- L'ingénierie intégrée sur le long terme. Si nous sommes intégrés à une équipe produit pendant six mois, un forfait par fonctionnalité crée des incitations perverses dans l'autre sens. Pour un partenariat continu, nous proposons un forfait mensuel avec un livrable défini. C'est plus proche d'un salaire que d'un prix par projet. Cela fonctionne parce que la relation est longue.
Pour tout le reste (sites web, identités de marque, logiciels cadrés, sprints de découverte), le forfait est la réponse. Il aligne les incitations, il force la clarté, et il fait porter la discussion sur la valeur plutôt que sur les heures.
Ce que nous facturons
Nous facturons des résultats, pas des efforts. Un client qui nous engage nous engage pour obtenir une chose précise. Le prix reflète ce que vaut cette chose. Parfois, le travail nous prend moins de temps que prévu. Le prix reste le même. Parfois, il en prend plus. Le prix reste le même. Le client ne paie pas notre temps. Il paie ce qui est livré.
C'est le contrat. Il ne fonctionne que si les deux parties le prennent au sérieux. Nous le faisons. La plupart des clients, après un projet au forfait avec nous, n'y reviennent jamais. La clarté vaut trop cher. Voici comment nous chiffrons un logiciel sur mesure, toujours par version et jamais à l'heure.
Questions fréquentes
Vaut-il mieux développer un logiciel au forfait ou à l'heure ?
Pour les projets cadrés, comme les sites web, les identités de marque et les versions logicielles définies, le forfait est préférable : il récompense la rapidité et met le coût total sur la table dès le départ. La facturation horaire ou la régie conviennent à la R&D ouverte et aux équipes intégrées sur la durée.
Comment gérer un changement de périmètre sur un projet au forfait ?
Avec un avenant écrit : le nouveau travail a son propre prix et sa propre date de livraison, et il ne commence qu'une fois signé par le client. Le reste du projet garde son prix et sa date, ce qui évite les factures qui gonflent sans qu'on sache pourquoi.
Un prix fixe coûte-t-il plus cher qu'un projet à l'heure ?
Pas forcément. Le prestataire intègre le risque d'estimation dans un prix fixe, mais vous évitez les dépassements, qui sont la norme des projets à l'heure mal cadrés. Comparez le coût final probable, pas le taux horaire, et exigez un périmètre écrit dans les deux cas.
Comment un logiciel peut-il être chiffré au forfait si tout n'est pas connu ?
En le découpant en versions. La première version est le plus petit système qui résout le plus gros problème, cadrée et chiffrée précisément ; les suivantes sont chiffrées une à une, quand on en sait plus. Chez Unlockd, une première version commence à partir de 6 900 € et prend 3 à 4 semaines.


