Un fondateur m'a appelé en novembre 2024, deux semaines avant Noël, absolument furieux. Une agence web lui avait coté 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'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.Custom software quotes go wrong at scoping, not building; estimate from data model complexity, integrations, and review cycles, and price the discovery phase separately.
Je développe des logiciels depuis plus de douze ans. Seahawk seul a livré plus de 12 000 sites et applications. Et le point de défaillance le plus systématique que je vois -- chez les fondateurs, les freelancers, les agences qui cotent des projets -- 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 sensations. 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 -- donc ils recourent à des raccourcis qui ressemblent à de la rigueur mais ne le sont pas.how hard -- so they reach for shortcuts that feel like rigour but aren't.
Un développeur vous donne un chiffre d'instinct. Une agence multiplie son tarif journalier par un nombre estimé de sprints. Un freelancer regarde un gig similaire sur Upwork et travaille à rebours. Aucun de ces approches n'est exactement faux, mais aucun ne tient compte des vrais facteurs de coût : la complexité d'intégration, la latence décisionnelle du côté client, le scope creep sur les features qui semblaient mineures, la surcharge de tests, et le tueur silencieux -- la configuration d'environnement et le DevOps que personne ne tarifie.
En 2021, je gérais un projet pour un client du secteur immobilier-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 de 28 000 £. Nous avions déjà réalisé des builds similaires. Mais ce client utilisait un système de gestion immobilière existant avec une API propriétaire qu'on n'avait pas touchée depuis quatre ans. Rien que l'intégration a dépassé d'trois semaines. Coût final : 47 500 £. Le client l'a bien pris parce que nous lui en avions parlé dès que nous avions trouvé la documentation de l'API -- mais l'estimation initiale était quand même de la fiction, et c'est moi qui 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 : toute devis que vous recevez avant que des spécifications détaillées ne soient rédigées doit être traitée comme une fourchette, pas un chiffre. 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 chiffre 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 que tout estimateur ne puisse fonctionner, vous devez diviser le projet dans les bonnes catégories. Pas « frontend, backend, QA » -- ce sont des rôles, pas des facteurs 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 pratiquement chaque projet. C'est le travail d'intégration qui vous coûte. Chaque API externe, système existant, 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 scope qui touche des systèmes externes.
2. UI/UX Design (Ne sautez pas cette ligne)
Beaucoup de fondateurs considèrent le design comme optionnel ou essaient de le rouler dans l'estimation de développement. Erreur. Le design bien fait -- wireframes, prototypes interactifs dans Figma, une librairie de composants testée -- représente généralement 15-25 % du coût total du projet. Le sauter et vous paierez deux fois : une fois en rework de développeur quand les exigences s'avèrent ambiguës, et une autre en 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 cite cela correctement. Les environnements de staging, les pipelines CI/CD (nous utilisons 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 énumérés. Pour un SaaS de complexité moyenne, budgétisez un minimum de £3 000-£6 000 pour la configuration initiale de l'infrastructure, plus des coûts mensuels continus 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 d'assurance qualité manuelle, les tests de performance, l'examen de sécurité pour tout ce qui traite les paiements ou les données personnelles -- cela représente généralement 20 % du temps de développement total si c'est fait correctement. La plupart des devis d'agence incluent « testing » comme poste et signifient « un dev a cliqué un peu 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 : Énumérez chaque fonctionnalité comme une user story. Pas « gestion utilisateur » -- c'est trop vague. « Un utilisateur peut s'inscrire avec son e-mail et mot de passe, vérifier son e-mail, réinitialiser son mot de passe et mettre à jour sa photo de profil. » Quatre stories. Chacune 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 histoire par complexité. J'utilise trois niveaux :I use three tiers:
- 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.(S): Pure CRUD, no external dependencies, standard UI patterns. Think: a settings page, a profile update form, a data table with sorting.
- 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.(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. Par exemple : un système de chat en direct, un moteur de recommandation, un modèle de permissions multi-locataire.(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 :
- Story simple : 4-8 heures
- Story moyenne : 12-24 heures
- Story complexe : 30-80 heures (oui, cette amplitude est large -- complexe est réellement 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, on peut obtenir un excellent travail ici, mais les frais 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 en voulant un tableau de bord analytique B2B -- 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 h2 Medium stories = 48 hrs
- Intégration GA4 + pipeline de données : 1 récit Complex = 55 h1 Complex story = 55 hrs
- Schéma de base de données d'événements personnalisés + API : 2 récits Medium = 40 h2 Medium stories = 40 hrs
- Interface de tableau de bord (graphiques via Chart.js ou Recharts, responsive) : 3 récits Medium = 65 h3 Medium stories = 65 hrs
- Export de rapports en PDF/CSV : 1 récit Medium = 18 h1 Medium story = 18 hrs
- Gestion d'équipe (invitation, suppression, attribution de rôles) : 2 récits Simple + 1 récit Medium = 28 h2 Simple + 1 Medium stories = 28 hrs
- Facturation via Stripe (abonnements, montée/rétrogradation de gamme) : 1 récit Complex = 45 h1 Complex story = 45 hrs
Total de développement brut : ~299 heures
Appliquez un taux d'agence britannique mixte de £95/h : £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 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.PCI DSS compliance adds 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'intégration pour les futurs développeurs -- 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 revendre la chose.
---
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. 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 forts assistés par l'IA travaillent environ 20-30% plus vite sur du travail CRUD greenfield. Ce chunk du milieu de fonctionnalités standard -- formulaires, tableaux, flux d'authentification basique -- sort plus vite. Mais le travail d'intégration complexe, les décisions architecturales, le débogage des conditions de concurrence subtiles, et tout ce qui demande une réflexion produit profonde ? L'IA ne vous aide pas là, et dans certains cas elle génère du code qui semble plausible mais 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% à l'étape 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 des wireframes et une architecture technique : ±10-15%. Payez pour un vrai engagement 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 ?
Un prix fixe vous donne une 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. Le temps et matériaux est honnête mais vous oblige à gérer activement la portée. Ma préférence pour la plupart des fondateurs : prix fixe par sprint (généralement 2 semaines), avec une portée définie au début de chaque sprint. Vous obtenez de la prévisibilité sans le jeu du gonflage.
Le développement nearshore ou offshore est-il vraiment moins cher une fois les frais de gestion en compte ?
Souvent, mais pas toujours. Le surcoût est réel — plus de temps PM, plus de communication asynchrone, du retravail occasionnel dû à des attentes mal alignées. 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. J'ai mené des projets réussis à 40 £/h en blended avec des équipes polonaises et ukrainiennes. Pour quelque chose d'ambigu et en mouvement rapide, je le garderais plus près de la maison.
Quel est un signal d'alarme dans une proposition logicielle ?
Un devis sur une seule ligne sans détail. Un calendrier qui n'inclut pas l'AQ ou le déploiement. Aucune mention de la façon dont les demandes de changement sont traitées. Et honnêtement — toute agence qui ne vous pose pas de questions difficiles sur votre infrastructure existante avant de faire un devis. S'ils ne sont pas curieux de connaître vos contraintes, ils n'ont 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à.