Un fondateur m'a appelé en novembre 2024, deux semaines avant Noël, complètement furieux. Une agence web lui avait devisé 14 000 £ pour un tableau de bord logistique sur mesure. Il avait signé. Six mois plus tard, la facture finale était arrivée à 61 000 £. Personne ne lui avait menti, techniquement. Mais personne ne lui avait dit la vérité non plus, parce que personne n'avait réellement fait le travail d'estimer correctement avant de prendre son argent.
Point clé : les devis de logiciels sur mesure échouent au stade de la définition du périmètre, non de la construction ; estimez à partir de la complexité du modèle de données, des intégrations et des cycles de révision, et facturez la phase de découverte séparément.
Je construis des logiciels depuis plus de douze ans. Seahawk à elle seule a lancé plus de 12 000 sites et applications. Et le point d'échec le plus constant que je vois, chez les fondateurs, chez les freelancers, chez les agences qui devisent des projets, c'est que personne n'a de méthode rigoureuse pour estimer le coût avant qu'une ligne de code soit écrite. Les gens devinent. Ils s'ancrent sur des intuitions. Ils utilisent le dernier projet comme point de référence sans vérifier s'il était remotement comparable.
Donc. Voici le cadre que j'utilise réellement. Pas un modèle de feuille de calcul avec des cellules vides. Un vrai modèle mental, avec des chiffres actuels de 2026, des outils spécifiques, et les réserves qui comptent.
---
Pourquoi la Plupart des Devis Logiciels Sont de la Fiction
Le problème n'est pas la malhonnêteté (généralement). C'est que l'estimation de logiciels est véritablement difficile, et la plupart des gens sous-estiment à quel point, donc ils se tournent vers des raccourcis qui donnent l'impression de rigueur mais ne l'en sont pas.
Un développeur vous sort un chiffre au pifomètre. Une agence multiplie son taux journalier par un nombre de sprints estimé. Un freelancer regarde un gig similaire sur Upwork et travaille à l'envers. Aucun de ces approches n'est exactement faux, mais aucun ne tient compte des vrais leviers de coût : la complexité de l'intégration, la latence décisionnelle côté client, le scope creep sur les features qui semblaient mineures, la surcharge de test, et le tueur silencieux, la configuration d'environnement et les DevOps que personne ne facture.
En 2021, je gérais un projet pour un client en property-tech à Manchester. Assez simple sur le papier : un portail locataire avec uploads de documents, suivi des loyers, et un workflow de demandes de maintenance. L'estimation initiale était 28 000 £. Nous avions fait des constructions similaires. Mais ce client utilisait un système de gestion immobilière hérité avec une API propriétaire que personne n'avait touchée depuis quatre ans. L'intégration seule s'est dépassée de trois semaines. Coût final : 47 500 £. Le client l'a bien pris parce que nous l'avions signalé dès que nous avions trouvé la doc de l'API, mais l'estimation initiale était quand même de la fiction, et c'était ma responsabilité.
Le Cône d'Incertitude Est Réel
Le cône d'incertitude, popularisé par Steve McConnell, décrit comment les estimations de projet deviennent plus précises à mesure qu'on s'approche de la livraison. À l'idéation, vous pourriez être à côté de 4x dans les deux sens. Après la conception détaillée, peut-être 1,25x. La plupart des fondateurs reçoivent des devis au stade de l'idéation et les traitent comme des contrats signés.
Conséquence pratique : tout devis que vous recevez avant que des spécifications détaillées soient écrites devrait être traité comme une plage, pas comme un chiffre. Si une agence vous donne un seul chiffre avant d'avoir vu votre modèle de données, vos flux utilisateur et vos dépendances tierces, ce chiffre est purement décoratif.
---
Les Quatre Vrais Postes de Coûts
Avant que tout estimateur ne fonctionne, vous devez diviser le projet dans les bonnes catégories. Pas « frontend, backend, QA », ce sont des rôles, pas des leviers de coût. Les vrais buckets :
1. Travail Greenfield vs. Travail d'Intégration
Greenfield, construire quelque chose de zéro contre votre propre base de données et logique métier, est la moitié plus bon marché et plus prévisible de presque tout projet. C'est le travail d'intégration qui vous coûte. Chaque API externe, système hérité, processeur de paiement ou fournisseur d'auth tiers ajoute de la complexité non-linéaire. J'ajoute généralement une contingence de 30-40 % sur toute ligne de scope qui touche des systèmes externes.
2. UI/UX Design (Ne sautez pas cette ligne)
Beaucoup de fondateurs traitent le design comme optionnel ou essaient de le rouler dans l'estimation de développement. Erreur. Le design fait correctement, wireframes, prototypes interactifs en Figma, une librairie de composants testée, représente généralement 15-25 % du coût total du projet. Sautez-le et vous paierez deux fois : une fois en rework de développeur quand les requirements s'avèrent ambigus, et de nouveau en recherche utilisateur plus tard quand le produit ne convertit pas.
3. Infrastructure et DevOps
Personne ne cite cela correctement. Les environnements de staging, les pipelines CI/CD (nous utilisons GitHub Actions pour presque tout maintenant), la conteneurisation avec Docker, l'hébergement cloud sur AWS ou GCP, ce sont des coûts réels qui ne disparaissent pas parce que personne ne les a détaillés. Pour un SaaS de complexité moyenne, budgétisez un minimum de £3 000-£6 000 pour la mise en place initiale de l'infrastructure, plus des coûts mensuels récurrents qui tournent généralement autour de £200-£800 selon l'utilisation.
4. Testing, QA, et frais de lancement
Les suites de tests automatisés, les passes QA manuelles, les tests de performance, l'examen de sécurité pour tout ce qui gère les paiements ou les données personnelles, cela représente généralement 20% du temps de développement total s'il est fait correctement. La plupart des devis d'agence incluent « testing » comme poste budgétaire et signifient « un dev a cliqué partout pendant un après-midi avant l'appel de livraison ».
---
Un estimateur qui fonctionne : la méthode par module
Voilà le cadre réel. Je l'appelle la méthode par module parce qu'elle vous force à décomposer un projet en chunks discrets, estimables indépendamment, plutôt que de le traiter comme un monolithe.
Étape 1 : Listez chaque fonctionnalité sous forme de user story. Pas « gestion des utilisateurs », c'est trop vague. « Un utilisateur peut s'inscrire avec un email et un mot de passe, vérifier son email, réinitialiser son mot de passe et mettre à jour sa photo de profil. » Quatre stories. Chacune a un coût.
Étape 2 : Classez chaque histoire par complexité. J'utilise trois niveaux :
- Simple (S) : Du pur CRUD, aucune dépendance externe, motifs UI standard. Par exemple : une page de paramètres, un formulaire de mise à jour de profil, un tableau de données avec tri.
- Moyen (M) : Un peu de logique métier, une intégration externe, ou une UI non standard. Par exemple : une recherche filtrée avec requêtes enregistrées, un gestionnaire webhook, un flux d'abonnement Stripe.
- Complexe (C) : Plusieurs intégrations, fonctionnalités en temps réel, logique algorithmique, ou infrastructure lourde. Par exemple : un système de chat en direct, un moteur de recommandation, un modèle de permissions multi-locataire.
Étape 3 : Attribuez des plages horaires, pas des estimations en points.
En 2026, en travaillant avec une agence britannique de gamme moyenne ou une équipe nearshore solide, voici ce que j'établis :
- Story simple : 4-8 heures
- Story moyenne : 12-24 heures
- Story complexe : 30-80 heures (oui, c'est vraiment une fourchette large, complexe est vraiment imprévisible)
Étape 4 : Appliquez votre tarif.
Les tarifs du marché actuels à connaître :
- Développeur senior basé à Londres (freelance) : £90-£140/h
- Agence britannique (équipe complète, gérée comme projet) : £80-£120/h blendé
- Nearshore solide (Europe de l'Est, Amérique latine) : £35-£65/h
- Offshore (Asie du Sud, Philippines) : £15-£35/h, et oui, vous pouvez obtenir un excellent travail ici, mais les frais généraux de communication sont réels et doivent être pris en compte dans le prix
Étape 5 : Ajoutez les frais généraux explicitement.
Ne les absorbez pas. Détaillez-les en tant que postes distincts :
- Gestion de projet : 10-15% des heures de développement
- Design (si non déjà défini) : 15-25% du total
- Configuration DevOps/Infrastructure : forfait £3,000-£8,000 selon la complexité
- QA : 20 % des heures de développement minimum
- Contingence : 20 % pour les projets greenfield, 35 % pour tout ce qui implique une intégration significative
---
Un exemple concret : tableau de bord SaaS, tarification 2026
Laissez-moi vous montrer quelque chose de concret. Un fondateur vient me voir voulant un tableau de bord B2B analytics, un produit SaaS où ses clients se connectent, voient leurs données de performance extraites de Google Analytics 4 et d'une base de données d'événements personnalisée, peuvent exporter des rapports et gérer l'accès de leur propre équipe.
Voici comment je le décomposerais :
- Système d'authentification (email + SSO Google, accès basé sur les rôles) : 2 récits Medium = 48 h
- Intégration GA4 + pipeline de données : 1 récit Complex = 55 h
- Schéma de base de données d'événements personnalisés + API : 2 récits Medium = 40 h
- Interface de tableau de bord (graphiques via Chart.js ou Recharts, responsive) : 3 récits Medium = 65 h
- Export de rapports en PDF/CSV : 1 récit Medium = 18 h
- Gestion d'équipe (invitation, suppression, attribution de rôles) : 2 récits Simple + 1 récit Medium = 28 h
- Facturation via Stripe (abonnements, montée/rétrogradation de gamme) : 1 récit Complex = 45 h
Total de développement brut : ~299 heures
Appliquez un taux d'agence britannique mixte de £95/h : £28 405
Ajouter :
- Design (20 %) : £5,681
- Configuration DevOps : £4,500
- Assurance qualité (20 % des heures de développement, même tarif) : £5,681
- Chef de projet (12%) : £3 409
- Contingence d'intégration (30% sur le travail GA4 et Stripe) : £3 000
Devis total : ~£50 676
C'est un vrai chiffre pour un vrai produit. Rien de choquant si vous comprenez ce qu'il contient. Absolument choquant si vous vous attendiez à £18 000 parce que c'est ce qu'on a dit à un fondateur de votre réseau l'année dernière pour « quelque chose de similaire ».
---
Les coûts cachés que personne ne mentionne
Licences et services tiers
Mapbox pour les fonctionnalités de cartographie. Twilio pour les SMS. SendGrid pour les e-mails transactionnels. Algolia si vous avez besoin d'une vraie recherche. Ce sont des coûts récurrents que les fondateurs omettent régulièrement de leur budget logiciel entièrement parce qu'ils les considèrent comme « juste des APIs ». Un SaaS de moyenne envergure avec 10 000 utilisateurs actifs pourrait payer £800-£2,000/mois en frais de services tiers avant qu'une seule facture de serveur n'arrive.
Sécurité et conformité
Si vous traitez des données personnelles au Royaume-Uni, le RGPD n'est pas optionnel. Si vous touchez aux paiements, la conformité PCI DSS ajoute de la complexité. Si vous êtes dans la santé ou la finance, vous regardez des coûts d'audit supplémentaires qui peuvent coûter £5,000-£20,000 rien que pour le travail de certification initial. J'ai vu des fondateurs être véritablement surpris par cela. Un client fintech que nous avons eu en 2023 avait budgété zéro livre pour le travail de conformité et a eu besoin de £14,000 avant de pouvoir lancer.
Transmission et documentation
Une bonne documentation, des docs API, des runbooks de déploiement, des guides d'onboarding pour les futurs devs, cela coûte du temps réel. Budgétisez 5-8% des heures totales du projet pour la documentation si vous voulez jamais pouvoir maintenir, étendre ou vendre le truc.
---
Comment tester une soumission sous pression
Vous avez une proposition devant vous. Voici comment l'auditer avant de signer :
- Demandez la ventilation des fonctionnalités derrière le chiffre. S'ils ne peuvent pas vous donner une ventilation au niveau des stories, la soumission est une devinette.
- Vérifiez si DevOps, QA et PM sont des postes budgétaires distincts ou cachés dans un taux mixte. Caché signifie généralement mal cuisiné.
- Demandez quelle est la politique de contingence. Plafonneront-ils les dépassements ? Régie ou prix fixe ? Chacun a des implications réelles.
- Découvrez quelles hypothèses ils ont faites sur les intégrations tierces. Demandez-leur directement : « Avez-vous lu la documentation API pour [service spécifique] avant de faire la soumission ? »
- Demandez ce qui se passe si les exigences changent après le sprint 2. La réponse vous dit presque tout sur la façon dont l'agence fonctionne.
La méthodologie Shape Up de Basecamp propose un cadre véritablement utile pour ceci : temps fixe, périmètre variable. Cela vaut la peine d'être lu avant d'entrer dans toute négociation avec une agence.
---
AI Tools en 2026 : Ce qu'ils changent (et ce qu'ils ne changent pas)
Tout le monde veut savoir si GitHub Copilot, Cursor, ou la nouvelle vague d'outils de codage basés sur des agents (Devin, Replit Agent) ont materialmente réduit les coûts logiciels. Honnêtement ? Oui, un peu. Mais moins que le battage médiatique le suggère.
Mon expérience approximative : les développeurs forts assistés par l'IA travaillent environ 20-30% plus vite sur le travail CRUD greenfield. Ce morceau du milieu des fonctionnalités standard, les formulaires, les tableaux, les flux auth basiques, sort plus vite. Mais les intégrations complexes, les décisions architecturales, le débogage des race conditions subtiles, et tout ce qui nécessite une réflexion produit approfondie ? L'IA n'aide pas là, et dans certains cas elle génère du code plausible qui introduit de nouveaux problèmes.
J'appliquerais une réduction d'efficacité de 10-15% aux stories simples et moyennes en 2026 si l'équipe est confirmée utiliser sérieusement les outils d'IA. Pas plus que ça. Quiconque vous propose un devis 50% moins cher « parce qu'on utilise l'IA » dirige soit un type de projet très différent de ce que vous pensez, soit vous dit quelque chose trop beau pour être vrai.
---
FAQ
À quel point une estimation logicielle peut-elle vraiment être précise avant que les spécifications ne soient écrites ?
Pas vraiment. Attendez-vous à une variance de ±40-60% au stade des idées. Une fois que vous avez des flux utilisateur détaillés, un modèle de données et une liste de toutes les dépendances tierces, vous pouvez atteindre ±20%. Après un sprint de découverte avec wireframes et architecture technique : ±10-15%. Payez un vrai projet de découverte avant de vous engager sur un budget de build complet, cela coûte généralement £2 000-£6 000 et c'est le meilleur argent que vous dépenserez sur le projet.
Dois-je opter pour un prix fixe ou le temps et matériaux ?
Le prix fixe vous donne la certitude budgétaire mais transfère le risque à l'agence, ce qui signifie qu'elle augmentera le devis et se protègera avec des clauses de changements. Le temps et matériaux est honnête mais vous demande de gérer activement le périmètre. Ma préférence pour la plupart des fondateurs : prix fixe par sprint (généralement 2 semaines), avec le périmètre défini au début de chaque sprint. Vous obtenez la prévisibilité sans le jeu de gonflage.
Le développement nearshore ou offshore est-il vraiment moins cher une fois les frais de gestion en compte ?
Souvent, mais pas toujours. Les frais généraux sont réels : plus de temps de gestion, plus de communication asynchrone, et parfois du travail à refaire en raison de désalignements dans les attentes. Pour un projet bien délimité avec des spécifications solides, le nearshore (l'Europe de l'Est en particulier) offre une véritable valeur ajoutée. J'ai mené des projets réussis à 40 £/h en blend avec des équipes polonaises et ukrainiennes. Pour quelque chose d'ambigu et qui évolue rapidement, je préfère rester plus proche.
Quel est un signal d'alarme dans une proposition logicielle ?
Une citation sur une seule ligne sans ventilation. Une chronologie qui n'inclut pas l'assurance qualité ni le déploiement. Aucune mention de la façon dont les demandes de modification sont traitées. Et honnêtement, une agence qui ne vous pose pas de questions difficiles sur votre infrastructure existante avant de vous faire un devis. Si elle n'est pas curieuse de connaître vos contraintes, elle n'a pas réfléchi sérieusement à votre projet.
Comment budgétiser la maintenance après le lancement ?
Règle standard : 15-20 % du coût initial de construction par an pour la maintenance continue, les corrections de bugs et les travaux de fonctionnalités mineures. Une construction de 50 000 £ nécessite un budget de maintenance annuel de 7 500 £-10 000 £. Si quelqu'un vous dit que le logiciel est « terminé » au lancement, trouvez d'autres gens du logiciel.
---
Le fondateur logistique de novembre ? Il est retourné chez son agence, ils ont refactorisé leur processus de travail, et le produit a été livré en mars. Ça fonctionne bien. Mais il m'a dit qu'il aurait aimé que quelqu'un lui remette un cadre comme celui-ci avant de signer quoi que ce soit. Voilà.
Lectures connexes : Building a Real-Time Auction Site with Next.js & Supabase, développement web sur mesure et logiciels personnalisés.