Ma formule pour estimer un projet web sans me planter

Je facture ma calculatrice à 18h47 un vendredi. Le mandat qu'un client m'avait donné trois semaines plus tôt : « refonte simple du site vitrine, ajout d'un module de réservation ». J'avais estimé 40 heures. J'en étais à 122 heures, et il me restait encore le module de paiement à connecter.

Le calcul qui fait mal

Ce projet-là, je l'avais chiffré à 3 200 $ CAD, forfait fixe. Décomposition rapide sur un coin de table, deux ou trois blocs de tâches, un chiffre qui sonnait bien, un client content de la proposition. Classique.

Le problème est apparu à la deuxième semaine. Le « module de réservation » que j'avais budgété à 12 heures s'est transformé en système avec gestion de disponibilités, notifications par courriel, synchronisation avec un calendrier externe et gestion de fuseaux horaires parce que le client avait des clients en Ontario. Rien de tout ça n'était écrit dans le mandat initial, mais tout ça était implicite dans « module de réservation » pour lui.

J'ai fini par sortir mon fichier de suivi de temps (Toggl, que j'utilise depuis des années sans vraiment l'exploiter) et j'ai fait le calcul complet. 122 heures réelles contre 40 heures estimées. Un dépassement de 305 %. Payé 3 200 $ pour 122 heures de travail, ça donne un taux horaire de 26,20 $ CAD. Mon taux normal tourne autour de 75 $ CAD de l'heure.

J'ai perdu de l'argent sur ce projet. Mais le vrai dégât, c'est que j'ai perdu trois semaines où j'aurais pu prendre un autre client payant à mon vrai taux.

Ce que le dépassement révélait vraiment

Le lendemain, j'ai repris mon fichier d'estimation initial et je l'ai comparé ligne par ligne avec le temps réel passé. Ce n'était pas un exercice agréable, mais c'est probablement le meilleur diagnostic que j'ai fait sur ma propre façon de travailler.

Trois biais sont ressortis, nets et répétés :

• Je sous-estimais systématiquement les tâches d'intégration. Chaque fois qu'il fallait connecter deux systèmes (paiement, calendrier, API tierce), mon estimation initiale était toujours 2 à 3 fois trop basse. Je pensais en « temps de code » et j'oubliais le temps de débogage, de lecture de documentation mal écrite, de tests avec des cas limites.
• Je ne chiffrais jamais les allers-retours client. Chaque révision, chaque « est-ce qu'on pourrait juste ajouter... » pendant les points hebdomadaires me coûtait entre 1 et 4 heures que je n'avais budgétées nulle part.
• Mon estimation initiale était optimiste parce que je voulais le contrat. Ça, c'est le biais le plus difficile à admettre. Je savais, au fond, en proposant 40 heures, que c'était serré. Mais un chiffre plus bas fait gagner l'appel d'offres. Je m'étais menti à moi-même pour me convaincre de mentir un peu au client.

Le pire dans tout ça : ce n'était pas la première fois. En regardant mes trois projets précédents dans Toggl, j'avais un dépassement moyen de 60 % sur mes estimations. Ce projet à 305 % était juste le cas extrême qui m'a forcé à regarder le pattern au lieu de l'ignorer.

Ma formule actuelle

Depuis ce projet, j'estime différemment. Pas de formule magique universelle, mais une méthode reproductible que j'applique à chaque nouveau mandat.

Étape 1 : décomposition en tâches atomiques. Je découpe le projet en tâches de 2 à 6 heures maximum. Si une tâche dépasse 6 heures dans mon estimation, c'est qu'elle cache en fait deux ou trois sous-tâches que je n'ai pas identifiées. Une tâche floue de 15 heures cache toujours plus de travail qu'une liste de cinq tâches de 3 heures.

Étape 2 : chiffrage brut de chaque tâche selon mon historique. Pas selon ce que je « pense » que ça devrait prendre, mais selon les données réelles de projets similaires dans mon suivi de temps. Si j'estime « intégration API de paiement » à 4 heures, je vérifie d'abord dans mon historique combien ça a réellement pris les trois dernières fois. Presque toujours, la réalité est 2 à 3 fois plus haute que mon intuition.

Étape 3 : multiplicateur de marge selon le type de client. C'est la partie qui a changé le plus radicalement ma rentabilité. Je n'applique pas la même marge à tout le monde :

• Client existant avec qui j'ai déjà livré 2-3 projets : multiplicateur de 1,2
• Nouveau client, mandat clair, spécifications écrites détaillées : multiplicateur de 1,4
• Nouveau client, mandat vague ou « on verra en cours de route » : multiplicateur de 1,8
• Client qui a déjà montré des signes d'indécision en appel de vente (change d'avis plusieurs fois pendant la discussion) : multiplicateur de 2,0

Ce dernier point vient directement de mon expérience à jongler plusieurs clients en simultané, où j'ai appris à repérer les signaux d'un client qui va générer des allers-retours sans fin avant même de signer le contrat. Ces signaux existent, et je les ignorais avant.

Étape 4 : zones grises, marge additionnelle fixe. Certaines catégories de travail sont systématiquement sous-chiffrées, peu importe l'expérience. Chez moi, ce sont :

• Intégrations tierces (paiement, calendrier, API externes) : +50 % sur mon estimation brute
• Contenu et textes que le client doit fournir mais fournit toujours en retard ou incomplet : +8 heures fixes de « gestion et relances »
• Tests sur mobile et compatibilité navigateurs : +20 % sur le temps de développement front-end
• Déploiement et configuration serveur si le client n'a pas d'infrastructure existante : +6 heures fixes

Le calcul final ressemble à ça : (somme des tâches décomposées) × (multiplicateur client) + (marges fixes des zones grises) = estimation soumise au client.

Pour le projet du fiasco à 305 %, si j'avais appliqué cette formule à l'époque, j'aurais soumis environ 78 heures au lieu de 40. Toujours en dessous des 122 heures réelles, mais dans une zone où le dépassement aurait été gérable au lieu de catastrophique.

Confronter l'estimation aux données réelles

La dernière étape, celle que je saute encore parfois par paresse et que je regrette à chaque fois, c'est la confrontation finale avant d'envoyer le chiffre au client.

Avant de proposer un montant, j'ouvre mon historique Toggl et je cherche le projet le plus similaire des 12 derniers mois. Pas similaire en théorie, similaire en pratique : même type de stack, même complexité de features, même profil de client. Je compare mon estimation actuelle avec le temps réel de ce projet passé.

Si l'écart est de plus de 20 %, je ne me pose pas la question de savoir si mon estimation actuelle est correcte. Je la corrige, point final. Mon intuition m'a déjà trahi une fois avec un écart de 305 %, je ne lui fais plus confiance sans vérification.

Cette discipline demande un système de suivi de temps propre et honnête. Je documente d'ailleurs cette pratique plus en détail dans mon carnet de bord technique, où je note chaque jour le temps réel passé sur chaque bloc de travail, pas juste en fin de semaine de mémoire (qui ment, toujours).

Il y a aussi la question du format de facturation qui influence directement le niveau de risque que je prends avec mes estimations. J'ai écrit un article séparé sur le choix entre forfait et taux horaire, parce que la formule d'estimation change complètement selon le modèle choisi. Un forfait fixe sur un mandat flou, c'est signer un chèque en blanc au client. Depuis mon dégât à 305 %, je refuse systématiquement le forfait fixe sur les mandats sans spécifications écrites détaillées.

Ce que je facture différemment maintenant

Un changement concret que cette méthode a apporté : je facture désormais une phase de découverte séparée sur tout mandat qui dépasse 20 heures estimées. Cette phase, entre 2 et 5 heures selon la complexité, sert uniquement à décomposer le projet en détail avec le client avant de soumettre un chiffre final ferme.

Ça semble contre-intuitif de facturer pour « juste faire un devis », mais ça change la dynamique complètement. Le client paie pour ma rigueur d'estimation, ce qui élimine les clients qui cherchaient un chiffre gratuit à faire compétitionner sur cinq plateformes différentes. Et ça me force, moi, à vraiment décomposer le projet au lieu de lancer un chiffre approximatif pour gagner le contrat rapidement.

Pour les développeurs solo qui gèrent aussi la partie contenu ou marketing de leurs propres projets pendant qu'ils codent pour des clients, je note en passant qu'estimer le temps pour produire du contenu SEO cohérent souffre exactement des mêmes biais que l'estimation de code. C'est un des trucs qui m'a poussé à regarder Gridar, un outil SEO bilingue FR-CA qui automatise la génération d'articles pour les PME québécoises, histoire de ne pas avoir à estimer (et sous-estimer) le temps de rédaction en plus du reste.

L'outil que j'utilise pour vérifier mes chiffres

Concrètement, mon processus d'estimation tient maintenant dans une feuille de calcul simple avec quatre colonnes : tâche, heures estimées selon l'historique, multiplicateur appliqué, marge de zone grise. Rien de sophistiqué. La sophistication n'est pas dans l'outil, elle est dans la discipline de vérifier chaque chiffre contre des données réelles au lieu de faire confiance à mon intuition du vendredi soir pressé de fermer une vente.

J'ai aussi commencé à noter, projet par projet, l'écart final entre estimation et réalité, en pourcentage. Objectif personnel : ramener mon écart moyen sous les 20 %. Il tournait autour de 60 % avant ce projet catastrophique. Il est descendu à environ 25 % depuis que j'applique cette formule, sur les huit derniers mandats.

Ce n'est pas parfait. Je continue de me tromper, surtout sur les projets avec des intégrations que je n'ai jamais faites avant. Mais l'écart est gérable maintenant, au lieu d'être un dégât financier qui me force à travailler à 26 $ de l'heure pendant trois semaines.

Sur TokamDarius, je documente ce genre de processus terrain parce que je pense que la majorité des ressources sur l'estimation de projet sont écrites par des gens qui n'ont jamais vécu le moment où ils réalisent, un vendredi à 18h47, qu'ils ont travaillé trois fois plus longtemps que prévu pour le même chèque.

Ce que je referais autrement

Si je pouvais revenir au moment où j'ai signé ce contrat à 3 200 $, je referais deux choses différemment. D'abord, j'exigerais des spécifications écrites sur ce que « module de réservation » signifie exactement, avec une liste de fonctionnalités précises validée par écrit avant de chiffrer quoi que ce soit. Ensuite, je facturerais une phase de découverte payante au lieu de faire un devis gratuit basé sur une conversation de 30 minutes.

L'action concrète que je propose si tu es dans une situation similaire : ouvre ton historique de temps sur tes trois derniers projets, calcule l'écart réel entre ton estimation et le temps passé, et si cet écart dépasse 30 %, arrête d'estimer selon ton instinct. Construis ta propre formule avec un multiplicateur selon le type de client et une marge fixe pour tes zones grises récurrentes. Ça prend une heure à mettre en place. Ça t'évite de facturer ta calculatrice à 26 $ l'heure un vendredi soir.

---

À lire aussi

• React et TypeScript : quand dire non malgré la hype
• Comment survivre à son DEC en informatique sans se faire détruire par les maths
• Facturer au forfait ou à l'heure : ce que j'ai appris en freelance