Comment estimer un projet digital en 2027 ? Ce n'est pas le code qui fait déraper le budget

Quatre postes que les devis oublient presque toujours, et comment les faire apparaître avant de signer

Quand un projet digital dérape, on accuse souvent la technique : « c'était plus compliqué que prévu ». Presque jamais. Ce qui coûte plus cher que prévu, ce sont des choses qui n'étaient pas dans le devis

Dans un devis, on trouve des écrans, des fonctionnalités, un nombre de jours de développement. On y trouve beaucoup plus rarement le temps passé à décider, à attendre une validation, à migrer des contenus ou à gérer ce qui se passe après la mise en ligne.

Voici comment je lis une estimation, et les quatre postes que je cherche en premier.

1. 1. Le temps de décision : le poste invisible

Un ingénieur estime ce qu'il sait construire. Il estime mal combien de temps vos équipes mettront à trancher. Chaque écran pose des questions : que se passe-t-il si le client n'a pas de compte ? Qui valide ce texte ? Quelle règle s'applique à ce cas particulier ? Tant que personne n'a répondu, le projet est à l'arrêt. Le prestataire facture quand même son équipe, ou la réaffecte ailleurs et revient plus tard.

Un projet livré vite est presque toujours un projet dont le périmètre était déjà tranché. Angela, à La Réunion, avait un prototype no-code à migrer vers une vraie base de code React Native. Les décisions étaient prises, car le prototype les contenait. Livraison en 19 jours, code source et historique Git complets remis.

Pour Tom, qui n'avait aucune équipe technique et partait d'une page blanche, une application complète iOS et Android a pris 4 mois. Ce n'est pas lent. Pour ce périmètre, le marché français se situe plutôt entre 40 000 et 100 000 €. Mais ces 4 mois contiennent des centaines de petites décisions qu'il a fallu prendre ensemble.

Donc demandez à votre prestataire de lister les décisions qu'il attend de vous, avec une date limite pour chacune. Si la liste est vide, c'est mauvais signe.

2. 2. Ce qui dépend d'un tiers

Votre projet touche presque toujours un système que ni vous ni votre prestataire ne contrôlez : une boutique d'applications, un moyen de paiement, un ERP, un service d'envoi d'e-mails.

Makan a eu une application mobile bloquée par une complication lors de la soumission à l'App Store d'Apple. Apple s'est obstiné à classer le projet en pari sportif alors qu'il s'agissait d'un simple jeu entre amis sans argent, allant jusqu'à réclamer une autorisation officielle de la FIFA. Sans autre issue face au store, l'équipe a dû faire preuve de persévérance en ajustant et en resoumettant le dossier jusqu'à son approbation. Cet événement nous a conduits à réviser nos contrats pour formaliser la responsabilité des retards liés aux tiers. Dans une estimation honnête, ce type de risque figure comme une ligne à part entière, et non comme un simple détail technique.

Dès aujourd’hui, pour chaque dépendance externe, demandez : « Si ce tiers refuse, retarde ou change ses règles, qu'est-ce qu'on fait, et qui paie ? »

3. 3. Les contenus, les données et la recette

Un site ou une application vide ne sert à rien. Il faut y mettre des textes, des images, des produits, des comptes clients venus de l'ancien système. Ce travail est presque toujours supposé « à la charge du client », puis il revient discrètement dans la facture ou dans le calendrier.

Il y a aussi la phase de recette : tester, corriger, retester puis valider la conformité juridique et technique (La rédaction des CGU pour encadrer l’exploitation des données utilisateur tenant compte du RGPD en particulier, qui reste la première question d'un acheteur européen). On la compte rarement à sa juste taille parce qu'elle ne produit rien de visible.

Alors, exigez que le devis sépare trois lignes : la construction, la reprise des contenus et données, la recette. Si elles sont fondues en une seule, vous ne pouvez pas arbitrer.

4. 4. L'après mise en ligne

C'est le poste le plus sous-estimé, et celui qui décide si le projet vit ou meurt.

Un produit en ligne demande de l'hébergement, des mises à jour de sécurité, des corrections et des ajustements après les premiers vrais utilisateurs. Antony, de Limescribe, a eu besoin de correctifs après le lancement (validation de fichiers, nettoyage d'une tâche planifiée). Ce n'est pas un échec : c'est la vie normale d'un produit. Mais si ce poste n'est pas budgété, il arrive au pire moment, sous la forme d'une urgence.

Les relations qui durent le montrent. Urbidesk travaille avec nous depuis plusieurs années, bien après la livraison initiale de sa plateforme. Un projet n'est pas un événement, c'est un début.

En pratique, demandez le coût de l'année 2 avant de signer l'année 1.

5. Comment construire une estimation qui tient ?

Plutôt qu'un chiffre unique, demandez trois scénarios : bas, probable, haut. L'écart entre eux est une information : plus il est large, plus le périmètre est flou, et c'est là que le risque se loge. Un prestataire qui vous donne un chiffre unique et très précis sur un périmètre vague ne vous protège pas, il vous cache l'incertitude.

Découpez ensuite en lots livrables courts avec une démonstration à chaque fin de lot. Vous voyez l'avancement sur du concret, et vous pouvez réorienter avant que l'erreur coûte cher.

Pour comparer deux devis, ramenez-les à un même périmètre. Côté main-d'œuvre, un développeur coûte généralement entre 350 et 800 € par jour en France. Notre grille publique va de 150 € (junior) à 300 € (senior), depuis chez nous, avec un décalage horaire d'environ une à deux heure avec la France selon la saison. L'écart de prix est réel, mais il ne remplace pas les quatre questions ci-dessus. Un devis moins cher qui oublie les quatre postes coûte plus cher à la fin.

Enfin, regardez ce qui protège votre délai. Chez nous, chaque jour ouvré de retard réduit automatiquement de 5 % du prix, et nous vous remboursons à 100% si l'interruption du projet provient de notre côté. De plus, les révisions sont illimitées jusqu'à la conformité au brief validé. Quelle que soit la façon dont vous choisissez votre prestataire, exigez un engagement écrit sur ces deux points.

6. Ce qui change en 2027

Les outils d'aide au développement continuent de progresser, et il est tentant d'en déduire que tout devrait coûter beaucoup moins. Prudence : ces outils aident surtout à écrire du code, et le code n'était déjà pas le poste qui faisait dériver les projets. Décider, dépendre d'un tiers, migrer, tester, maintenir : rien de tout cela ne disparaît avec un outil. Nous n'avons pas encore de pilote documenté qui permette de chiffrer un gain, donc nous ne promettons pas de baisse de prix à ce titre. Méfiez-vous de quiconque vous en promet une sans pouvoir montrer un projet réel.

En bref, avant de signer, vérifiez que votre estimation contient : les décisions attendues de votre côté, les dépendances externes, la reprise des contenus et la recette, et le coût de l'année 2. Si l'un des quatre manque, le devis n'est pas faux, il est incomplet, et vous paierez la différence plus tard.

Si vous avez un projet en cours d'estimation et un doute sur un de ces points, écrivez-moi en message privé. Je vous dirai franchement ce que je vois.