Un fondateur m'a appelé en novembre 2024, deux semaines avant Noël, absolument furieux. Une agence web lui avait fait un devis de £14 000 pour un tableau de bord logistique sur mesure. Il avait signé. Six mois plus tard, la facture finale s'élevait à £61 000. Personne ne lui avait menti, techniquement. Mais personne ne lui avait dit la vérité non plus — parce que personne n'avait vraiment fait le travail d'estimation correctement avant de prendre son argent.
Je développe des logiciels depuis plus de douze ans. Seahawk à elle seule a livré plus de 5 000 sites et applications. Et l'unique point de défaillance le plus constant que j'observe — chez les fondateurs, chez les freelances, chez les agences qui font des devis — c'est que personne n'a de méthode rigoureuse pour estimer le coût avant qu'une seule ligne de code ne 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 vraiment 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 logicielle est véritablement difficile, et la plupart des gens sous-estiment à quel point — ils optent donc pour des raccourcis qui donnent l'impression de rigueur mais n'en ont pas.howhard — so they reach for shortcuts that feel like rigour but aren't.
Un développeur vous donne un chiffre au feeling. Une agence multiplie son tarif journalier par un nombre de sprints estimé. Un freelance regarde un projet similaire sur Upwork et travaille à rebours. Aucun de ces approches n'est exactement faux, mais aucun ne tient compte des vrais moteurs de coûts : la complexité d'intégration, la latence décisionnelle du côté client, le scope creep sur les fonctionnalités qui semblaient mineures, la surcharge de test, et le tueur silencieux — la configuration de l'environnement et DevOps que personne ne chiffre.
En 2021, je gérais un projet pour un client de la property-tech à Manchester. Assez simple sur le papier : un portail locataire avec téléchargement de documents, suivi des loyers et un workflow de demandes de maintenance. L'estimation initiale était de £28 000. Nous avions déjà réalisé des projets similaires. Mais ce client utilisait un système de gestion immobilière legacy avec une API propriétaire que personne n'avait touchée depuis quatre ans. Seule l'intégration a dépassé le délai de trois semaines. Coût final : £47 500. Le client l'a accepté parce que nous l'avions signalé dès que nous avions trouvé la documentation API — mais l'estimation initiale était quand même de la fiction, et j'en suis responsable.
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., popularised by Steve McConnell, describes how project estimates get more accurate as you get closer to delivery. At ideation, you might be off by 4x in either direction. After detailed design, maybe 1.25x. Most founders are getting quotes at the ideation stage and treating them like signed contracts.
L'implication pratique : tout devis que vous recevez avant que les spécifications détaillées ne soient rédigées devrait être traité comme une plage, pas comme un nombre. Si une agence vous donne un chiffre unique avant d'avoir vu votre modèle de données, vos flux utilisateur et vos dépendances tierces — ce nombre est purement décoratif.range, not a number. If an agency gives you a single figure before they've seen your data model, user flows, and third-party dependencies — that number is decorative.
---
Les Quatre Vrais Postes de Coûts
Avant qu'un estimateur puisse travailler, vous devez diviser le projet dans les bonnes catégories. Pas « frontend, backend, QA » — ce sont des rôles, pas des moteurs de coûts. Les vrais postes :
1. Travail Greenfield vs. Travail d'Intégration
Le greenfield — construire quelque chose à partir de zéro sur sa propre base de données et logique métier — est la moitié moins chère et plus prévisible de presque tous les projets. C'est le travail d'intégration qui vous pose problème. Chaque API externe, système hérité, processeur de paiement ou fournisseur d'authentification tiers ajoute une complexité non linéaire. J'ajoute généralement une contingence de 30–40 % sur toute ligne de périmètre 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 l'inclure dans l'estimation de développement. Erreur. Le design fait correctement — maquettes, prototypes interactifs dans Figma, une bibliothèque de composants testée — représente généralement 15–25 % du coût total du projet. Si vous le sautez, vous paierez deux fois : une fois dans la refonte des développeurs quand les exigences s'avèrent ambiguës, et à nouveau dans la recherche utilisateur plus tard quand le produit ne convertit pas.Figma, a tested component library — typically runs 15–25% of total project cost. Skip it and you'll pay twice: once in developer rework when requirements turn out to be ambiguous, and again in user research later when the product doesn't convert.
3. Infrastructure et DevOps
Personne ne devis cela correctement. Les environnements de staging, les pipelines CI/CD (on utilise GitHub Actions sur 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 listés. Pour un SaaS de complexité moyenne, budgétez un minimum de £3 000–£6 000 pour la configuration 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
Suites de tests automatisés, passes de QA manuelles, tests de performance, revue de sécurité pour tout ce qui traite des paiements ou des données personnelles — c'est généralement 20 % du temps de développement total si c'est bien fait. La plupart des devis d'agence incluent « testing » comme ligne item et signifient « un dev a cliqué partout pendant un après-midi avant l'appel de remise ».
---
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é comme un récit utilisateur. Pas « gestion des utilisateurs » — c'est trop vague. « Un utilisateur peut s'inscrire avec un e-mail et un mot de passe, vérifier son e-mail, réinitialiser son mot de passe et mettre à jour sa photo de profil. » Quatre récits. Chacun a un coût.Not "user management" — that's too vague. "A user can register with email and password, verify their email, reset their password, and update their profile photo." Four stories. Each one has a cost.
Étape 2 : Classez chaque récit par complexité. J'utilise trois niveaux :I use three tiers:
- Simple (S) : Pur CRUD, pas de dépendances externes, modèles d'interface standard. Pensez à : une page de paramètres, un formulaire de mise à jour de profil, un tableau de données avec tri.(S): Pure CRUD, no external dependencies, standard UI patterns. Think: a settings page, a profile update form, a data table with sorting.
- Moyen (M) : Une logique métier, une intégration externe, ou une interface non-standard. Pensez à : une recherche filtrée avec requêtes sauvegardées, un gestionnaire de webhook, un flux d'abonnement Stripe.(M): Some business logic, one external integration, or non-standard UI. Think: a filtered search with saved queries, a webhook handler, a Stripe subscription flow.
- Complexe (C) : Plusieurs intégrations, fonctionnalités en temps réel, logique algorithmique, ou infrastructure lourde. Pensez à : un système de chat en direct, un moteur de recommandation, un modèle de permissions multi-client.(C): Multiple integrations, real-time features, algorithmic logic, or heavy infrastructure. Think: a live chat system, a recommendation engine, a multi-tenant permission model.
É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 :
- Récit simple : 4–8 heures
- Récit moyen : 12–24 heures
- Récit complexe : 30–80 heures (oui, c'est large — le complexe est véritablement 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, gestion de projet) : £80–£120/h en moyenne pondérée
- 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 travail excellent ici, mais la charge de communication est réelle et doit être intégrée au devis
É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 (s'il n'est pas déjà défini) : 15–25 % du total
- Configuration DevOps/Infrastructure : forfait de 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 détailler quelque chose de concret. Un fondateur vient me voir en voulant un tableau de bord analytique B2B — un produit SaaS où ses clients se connectent, consultent 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 + Google SSO, accès basé sur les rôles) : 2 stories Moyen = 48 heures2 Medium stories = 48 hrs
- Intégration GA4 + pipeline de données : 1 story Complexe = 55 heures1 Complex story = 55 hrs
- Schéma de base de données d'événements personnalisée + API : 2 stories Moyen = 40 heures2 Medium stories = 40 hrs
- Interface du tableau de bord (graphiques via Chart.js ou Recharts, responsive) : 3 stories Medium = 65 heures3 Medium stories = 65 hrs
- Export de rapports en PDF/CSV : 1 story Medium = 18 heures1 Medium story = 18 hrs
- Gestion d'équipe (invitations, suppression, attribution de rôles) : 2 stories Simple + 1 story Medium = 28 heures2 Simple + 1 Medium stories = 28 hrs
- Facturation via Stripe (abonnements, mise à niveau/rétrogradage) : 1 story Complex = 45 heures1 Complex story = 45 hrs
Total de développement brut : ~299 heures
Application d'un tarif blended d'agence UK de £95/hr : £28,405£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 emails transactionnels. Algolia si vous avez besoin d'une vraie recherche. Ce sont des coûts permanents que les fondateurs omettent régulièrement de leur budget logiciel parce qu'ils les considèrent simplement comme des « API ». Un SaaS de taille moyenne avec 10 000 utilisateurs actifs pourrait payer £800–£2 000/mois en frais de services tiers avant même que la première 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 des frais. Si vous êtes dans la santé ou la finance, vous devez compter sur des coûts d'audit supplémentaires qui peuvent atteindre £5 000–£20 000 juste pour la certification initiale. J'ai vu des fondateurs être véritablement pris au dépourvu par cela. Un client fintech chez nous en 2023 avait budgété zéro livre pour la conformité et a finalement eu besoin de £14 000 avant de pouvoir lancer.PCI DSS complianceadds overhead. If you're in health or finance, you're looking at additional audit costs that can run £5,000–£20,000 just for initial certification work. I've seen founders get genuinely blindsided by this. One fintech client of ours in 2023 had budgeted zero pounds for compliance work and then needed £14,000 of it before they could launch.
Transmission et documentation
Une bonne documentation — docs API, runbooks de déploiement, guides d'onboarding pour les devs futurs — 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 offre un cadre vraiment utile pour cela : temps fixe, scope variable. Ça vaut le coup de la lire avant d'entrer dans n'importe quelle négociation d'agence.has a genuinely useful framing for this: fixed time, variable scope. It's worth reading before you enter any agency negotiation.
---
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 assistés par l'IA travaillent environ 20–30% plus vite sur du travail CRUD greenfield. Ce morceau du milieu de fonctionnalités standard — formulaires, tableaux, flux d'auth basiques — sort plus vite. Mais le travail d'intégration complexe, les décisions architecturales, le débogage de conditions de course subtiles, et n'importe quoi qui demande de la réflexion produit approfondie ? L'IA n'aide pas là, et dans certains cas elle génère du code qui ressemble plausible et introduit de nouveaux problèmes.
J'appliquerais une remise d'efficacité de 10–15% sur les stories simples et moyennes en 2026 si l'équipe est confirmée comme utilisant sérieusement les outils IA. Pas plus que ça. Quiconque vous cite 50% moins cher « parce qu'on utilise l'IA » exécute soit un type de projet très différent de ce que vous croyez, soit vous dit quelque chose de 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 très. Attendez-vous à une variance de ±40–60% au stade de l'idée. 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 pour un vrai travail de découverte avant de vous engager sur un budget de build complet — ça 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 sur l'agence — ce qui signifie qu'elle gonflera l'estimation et se protègera avec des clauses de changement de périmètre. Le temps et matériaux est honnête mais vous oblige à 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 avez la prévisibilité sans le jeu du gonflement.
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 PM, plus de communication asynchrone, du rework occasionnel dû à des attentes mal alignées. Pour un projet bien délimité avec des spécifications solides, le nearshore (Europe de l'Est en particulier) offre une vraie valeur. J'ai mené des projets réussis à 40 £/h blended avec des équipes polonaises et ukrainiennes. Pour quelque chose d'ambigu et qui évolue rapidement, je le garderais plus près de chez moi.
Quel est un signal d'alarme dans une proposition logicielle ?
Un devis d'une seule ligne sans détail. Une chronologie qui n'inclut pas les tests ou le déploiement. Aucune mention de la façon dont les demandes de changement sont traitées. Et franchement — toute agence qui ne vous pose pas de questions difficiles sur votre infrastructure existante avant de vous faire un devis. S'ils ne sont pas curieux de vos contraintes, ils n'ont pas vraiment pensé à 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 le travail mineur sur les fonctionnalités. 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 experts en 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à.