Le devis n'est pas le coût : le dépassement de budget d'un développement d'application

Un dépassement de budget sur une application ne vient presque jamais du tarif horaire. Il vient de ce que personne n'avait écrit. Vu du client, la facture gonfle sans raison ; vu du prestataire, trente jours vendus en deviennent quarante-cinq. Les deux décrivent la même chose.

Le dépassement de budget d'un développement d'application se joue après la signature, pas dedans. Un développeur français résume le mécanisme sur Reddit (r/developpeurs, juillet 2026) : « Tu vends 30 jours, tu en passes 45, mais tu ne peux pas tout refacturer si tu veux garder le client. » Cinquante pour cent de dérive, absorbés en silence par l'un ou facturés en avenants à l'autre.

Vu du client : la facture gonfle sans que rien de visible ne change

Le porteur de projet voit un devis, une date, puis des avenants. Il n'a pas de moyen de savoir si la demande qu'il vient de formuler coûte une heure ou trois semaines, parce que rien n'a été écrit sur ce que le produit devait faire avant que le travail ne commence. Un dirigeant raconte sur Reddit (r/nocode, juin 2026) avoir consulté plusieurs agences pour reprendre son application : toutes ont proposé de la reconstruire de zéro, avec un montant à six chiffres et un délai en mois, l'application restant gelée pendant l'opération. Un devis était à 60 000. Il est resté bloqué trois mois après avoir reçu ces réponses.

Vu du prestataire : le forfait paie la mauvaise personne

Le développeur cité plus haut détaille ce qui se passe entre le devis et la livraison : les spécifications changent, le périmètre grossit, le client découvre des besoins que personne n'avait vus. Il vend un forfait, il porte le risque. Refacturer chaque écart abîme la relation ; ne rien refacturer abîme la marge. Un intégrateur d'agents décrit la même arithmétique sur Reddit (r/AI_Agents, août 2026) : un chantier simple à 10 000 ou 30 000 dollars, un système en production branché sur un CRM à 70 000 ou 150 000, et une règle empirique qui tient en une phrase, chaque mois de développement supplémentaire ajoute 20 000 à 40 000 dollars. Il ajoute que les budgets meurent là.

La cause commune : la dérive de périmètre est un défaut d'écriture

Les deux camps décrivent un même trou. Ce que le produit doit faire n'existe nulle part sous une forme que les deux parties ont lue, comprise et acceptée. Le devis liste des livrables ; il ne dit pas ce qui se passe quand un devis est refusé, qui voit quoi, ni comment s'arrondit un acompte. Ces décisions se prennent quand même, mais après la signature, une par une, dans des courriels et des appels. Chacune coûte un aller-retour et parfois du travail à refaire. Le cumul est la dérive.

Une deuxième cause s'ajoute chez les projets repris. Quand le produit existe déjà, ses règles vivent dans le logiciel et dans la tête de deux personnes, jamais sur le papier. Le prestataire chiffre ce qu'il voit à l'écran, découvre les cas particuliers en construisant, et facture la découverte. Le porteur, lui, croyait payer une reprise et paie une redécouverte de son propre métier.

Écrire ces décisions avant le début coûte quelques heures et se lit en un quart d'heure. C'est l'objet du cahier des charges, à condition qu'il descende au niveau des règles et pas des intentions. Notre méthode des questions qui fâchent tient en quatre blocs chronométrés, et lire un tel document sans être du métier s'apprend en dix minutes.

Ce qu'un budget encadré change à la conversation

Un plafond visible avant la dépense remet les deux parties du même côté. Chez nous, une estimation multipliée par trois borne le lancement d'un développement, un budget mensuel encadre l'ensemble des projets et une file d'attente empêche plusieurs chantiers de consommer en parallèle sans contrôle. Quand une étape échoue à sa vérification, deux réparations sont tentées, puis la décision remonte à l'humain plutôt que de tourner en boucle. Le principe se transpose à un contrat d'agence : demandez un plafond par lot et le nom de la personne qui décide quand il est atteint. Nous publions nos propres coûts, ligne par ligne pour que ce chiffre soit discutable.

Estimer votre dérive avant de signer

Reprenez le devis que vous avez sur la table et cherchez trois phrases : ce qui arrive quand vous changez d'avis, le nombre d'allers-retours inclus par écran, et la définition de « terminé » pour une fonctionnalité. Si les trois manquent, le devis chiffre un travail que personne n'a encore décrit, et l'écart se réglera à vos frais ou aux siens. Posez les trois questions par écrit avant de signer. Un prestataire qui répond en détail vous montre qu'il a déjà vécu la dérive et qu'il a appris à la borner ; un prestataire qui esquive vous annonce que vous la découvrirez ensemble, au troisième mois. La réponse vous en apprendra plus sur lui que son montant.