La scène se rejoue toutes les semaines, dans toutes les boîtes. Quelqu'un présente une fonctionnalité en réunion, le chef de projet se tourne vers toi : "tu peux me dire en combien de temps tu fais ça ?". Tout le monde attend. Tu n'as jamais fait ce genre de tâche. Mais tu sens que dire "je ne sais pas" passe pour de l'incompétence.
Toi, tu lances un chiffre. "Deux jours". Trois semaines plus tard, tu en es à ton huitième jour, tu enchaînes les heures sup pour ne pas avoir l'air d'avoir menti, et le client commence à demander pourquoi rien n'avance.
Le problème n'est pas que tu es mauvais en estimation. Le problème, c'est que personne ne t'a appris à estimer une tâche inconnue. On t'a appris à coder, à tester, à utiliser Git. Pas à dire "voici ce que je crois, voici ce que je ne sais pas, voici comment on peut sécuriser ça". Cette compétence-là ne figure dans aucun cursus officiel.
Cet article te donne une méthode reproductible : comment décomposer une tâche que tu ne maîtrises pas, comment formuler une réponse honnête qui ne te pénalise pas, et comment éviter les pièges qui transforment un projet de deux semaines en chantier de trois mois.
Le problème : tu confonds estimer et deviner
Quand tu lances "deux jours" sous la pression d'une réunion, tu ne fais pas une estimation. Tu fais un pari sur ton intuition, en supposant que rien ne se passera mal. Et comme tu n'as jamais fait cette tâche, ton intuition est calibrée sur du vide.
Une estimation honnête est une déclaration sur ton niveau d'information, pas une promesse sur le futur. Elle a deux composantes : une fourchette de temps, et un niveau de confiance dans cette fourchette. Dire "deux jours" sans rien de plus, c'est cacher tout ce qui compte vraiment.
Le mécanisme psychologique qui te pousse à donner un chiffre précis a un nom : le biais d'optimisme. Tu imagines la tâche dans son scénario idéal, tu oublies les frictions, et tu donnes une réponse qui correspond à un meilleur cas qui n'arrivera jamais. Toutes les études sur les estimations montrent le même résultat : les développeurs sous-estiment systématiquement de 30 à 50%, et les juniors plus que les seniors.
Plus grave : une fois que tu as lancé un chiffre, ce chiffre devient un engagement dans la tête des autres. Personne ne se souvient qu'il s'agissait d'une estimation à la volée. Le chef de projet a déjà ajouté la deadline dans son planning, le client a déjà calé sa communication, et toi tu te retrouves à courir derrière un mot lâché en quinze secondes.
Le principe : sépare ce que tu sais de ce que tu ne sais pas
Toute tâche que tu reçois se décompose en deux paquets : les parties que tu as déjà faites cent fois, et les parties qui sont nouvelles pour toi. Le premier paquet est estimable avec une précision raisonnable. Le second ne l'est pas, par définition.
La méthode tient en cinq étapes que tu peux appliquer en quinze minutes pour la plupart des tâches, et en deux heures pour les chantiers vraiment lourds.
1. Décompose en sous-tâches concrètes
Tu prends un papier, tu listes chaque étape technique. Pas "j'intègre Stripe", mais "je crée un compte Stripe test", "je lis la doc de l'endpoint Payment Intent", "je configure les webhooks", "j'écris l'endpoint qui reçoit le webhook", "je teste avec une carte de test", et ainsi de suite.
Cette décomposition révèle automatiquement ce que tu ne maîtrises pas. Si tu n'arrives pas à lister les étapes, c'est que tu ne comprends pas encore la tâche. Et si tu ne la comprends pas, tu ne peux pas l'estimer.
2. Classe chaque sous-tâche en trois catégories
Pour chaque ligne de ta liste, tu te poses une question simple : est-ce que je l'ai déjà fait ? Tu obtiens trois piles.
- Connu : tu l'as fait plusieurs fois, tu peux estimer à la demi-journée près.
- Familier : tu connais le domaine sans avoir fait exactement ça. Tu peux estimer à la journée près, avec une marge.
- Inconnu : tu n'as aucune référence. C'est ici que se trouvent tous les risques.
Sois honnête avec toi-même. Une intégration tierce que tu n'as jamais faite est inconnue, même si tu as déjà fait d'autres intégrations. Une migration de base que tu n'as jamais faite est inconnue, même si tu connais bien SQL.
3. Réduis l'inconnu par un spike
Un spike, c'est une investigation timeboxée. Tu te donnes une demi-journée ou une journée pour explorer la partie inconnue, sans chercher à produire du code utilisable. L'objectif : passer de "je ne sais pas" à "je sais à peu près combien de temps ça va prendre".
Tu lis la doc, tu fais un prototype crado, tu poses des questions sur Stack Overflow ou à un collègue. Au bout du temps imparti, tu en sais assez pour estimer correctement, ou tu sais que la tâche est beaucoup plus lourde que prévu.
4. Donne une fourchette, jamais un chiffre unique
Une fourchette communique ton niveau de certitude. "Entre trois et cinq jours" est honnête. "Quatre jours" est un mensonge qui se prend pour de la précision.
Règle simple : si tu donnes une fourchette dont la borne haute est moins du double de la borne basse, tu te bases sur du connu. Si l'écart est plus grand, tu reconnais que la tâche contient encore de l'inconnu, et tu proposes un spike pour resserrer.
5. Ajoute un buffer explicite, pas caché
Tu ajoutes systématiquement 20 à 30% de temps pour ce qu'on appelle les "unknown unknowns" : ce que tu ne sais pas que tu ne sais pas. Bugs imprévus, modifications de scope, attente d'une réponse, problème de prod qui te détourne.
Tu le dis explicitement à l'équipe. "Trois à cinq jours, plus une marge pour les imprévus, soit quatre à six jours au total." Tu ne caches pas le buffer. Quand tu le caches, il disparaît à la première discussion sur la deadline.
Exemple : tu dois intégrer un système de paiement Stripe
Imaginons une situation type. On te demande "ajouter Stripe sur notre application Symfony, en combien de temps tu fais ça ?". Tu n'as jamais intégré Stripe. Voici comment appliquer la méthode.
Décomposition :
- Créer un compte Stripe test et récupérer les clés API
- Installer le SDK PHP Stripe dans le projet
- Créer l'endpoint qui génère un Payment Intent
- Intégrer Stripe Elements dans le formulaire front
- Configurer et tester les webhooks (avec ngrok ou Stripe CLI)
- Gérer les statuts de paiement (réussi, échoué, en attente, remboursé)
- Sécuriser le webhook (vérification de signature)
- Écrire les tests d'intégration
- Passer de la clé test à la clé live, déployer
Classification :
- Connu : installation SDK, endpoint Symfony, déploiement (tu fais ça toutes les semaines)
- Familier : tests d'intégration, gestion des statuts (tu sais le principe, pas les spécificités Stripe)
- Inconnu : webhooks Stripe, Payment Intent, sécurisation par signature, Stripe Elements front
Estimation : avec une journée de spike pour comprendre les webhooks et le flow Payment Intent, tu peux ensuite estimer entre 4 et 6 jours de développement effectif, plus le buffer. Soit une réponse honnête : "je propose une journée d'exploration pour comprendre les webhooks Stripe, puis je te reviens avec une estimation précise. À vue de nez, on est entre 5 et 8 jours au total, mais je veux confirmer après le spike."
Personne ne te reprochera cette réponse. Elle est précise sur ce qui peut l'être, prudente sur le reste, et propose un mécanisme concret pour réduire l'incertitude. C'est ce que fait un développeur sérieux.
Comment formuler ta réponse à l'oral
La méthode ci-dessus suppose que tu as quelques heures devant toi. En réunion, on te demande souvent une réponse immédiate. Voici trois formulations à connaître par cœur, à adapter selon le contexte.
Quand tu peux gagner du temps : "Je ne veux pas te donner un chiffre au hasard. Laisse-moi prendre une heure pour décomposer la tâche, je te reviens cet après-midi avec une estimation chiffrée." Cette phrase change tout. Elle te positionne comme professionnel, pas comme indécis.
Quand on insiste pour avoir un ordre de grandeur : "Très grossièrement, ça me paraît être quelques jours plutôt que quelques heures, et plutôt que quelques semaines. Mais je ne peux pas être plus précis sans avoir regardé. Je te confirme aujourd'hui ou demain." Tu donnes une catégorie temporelle, pas un chiffre faux.
Quand tu as identifié l'inconnu : "Il y a une partie que je n'ai jamais faite, c'est la gestion des webhooks. Je te propose qu'on prévoie une journée de spike sur ça avant de figer la deadline. Sans ce spike, n'importe quel chiffre que je te donnerais serait du bluff." Cette phrase fait passer la responsabilité de l'estimation de tes épaules à la décision d'équipe.
Pièges classiques à éviter
Estimer pour faire plaisir
Tu sens que le chef de projet veut entendre "trois jours", alors tu dis trois jours. C'est la pire raison de donner un chiffre. Tu te mets en porte-à-faux avec la réalité, et le projet en paie le prix une semaine plus tard.
Une estimation honnête qui contrarie est toujours préférable à une estimation flatteuse qui explose. Les chefs de projet sérieux le savent et préfèrent les développeurs qui disent vrai.
Confondre temps de codage et temps de tâche
Tu estimes "deux jours de code". Mais entre les deux journées de code, il y a une revue de PR qui prend une journée, un blocage technique qui prend une demi-journée à résoudre, et une réunion qui ampute encore deux heures. Au total, ce sont quatre jours calendaires, pas deux.
Tu estimes toujours en jours calendaires effectifs, en intégrant le contexte réel de ton équipe. Si tu sais que tu as une réunion de planning de deux heures chaque mardi matin, tu en tiens compte.
Sous-estimer le temps de test et de revue
Erreur classique : tu comptes le temps pour écrire le code, pas pour le tester ni pour le faire revoir. Or tester et faire revoir représentent souvent 30 à 50% du temps total d'une tâche. Si tu n'as pas une stratégie de tests claire, tu vas perdre des heures à débugger plus tard. L'article sur le principe Fail Fast détaille pourquoi détecter tôt coûte toujours moins cher que corriger en aval.
Dans ton estimation, tu intègres explicitement le temps de tests, de relecture, de corrections post-revue, et de mise en production.
Ne pas mettre à jour ton estimation
Tu as dit "trois jours" lundi. Mercredi, tu as compris que c'était plus compliqué que prévu, et tu sens que ça va prendre cinq jours au minimum. Tu ne dis rien, en espérant rattraper. Vendredi, le pot aux roses se découvre, mais avec deux jours de retard sur la communication.
Dès que tu sens que ton estimation initiale est dépassée, tu communiques immédiatement. "Hé, la tâche que j'avais estimée à trois jours s'avère plus complexe, je suis plutôt parti sur cinq. Je voulais te prévenir tout de suite." C'est désagréable une fois, c'est une catastrophe si tu le caches.
Refuser d'estimer par peur de se tromper
L'autre extrême. Tu refuses systématiquement de donner un chiffre, ce qui rend impossible toute planification dans l'équipe. À force, on cesse de te demander, et on cesse aussi de te confier les tâches intéressantes.
Estimer fait partie du métier. Tu ne dois pas estimer juste, tu dois estimer avec honnêteté et explicitement sur la base de ce que tu sais. Personne ne te reprochera une fourchette large justifiée. On te reprochera un refus de te mouiller.
Ignorer ton historique
Tu fais des estimations à chaque sprint sans jamais regarder ce qui s'est passé. Pourtant, ton historique est ta meilleure source d'apprentissage. Si tu sous-estimes systématiquement de 50% les tâches de migration, tu peux ajuster.
Garde une trace simple : ton estimation initiale, le temps réel passé, et la cause principale du décalage. Trois lignes par tâche, dans un fichier ou un Notion. En trois mois, tu vois apparaître ton pattern personnel.
Pour aller plus loin
L'estimation est l'une de ces compétences qui ne s'apprennent ni à l'école ni dans les bootcamps. C'est exactement le type de sujet que développe l'article sur les soft skills du développeur moderne, qui couvre aussi l'art de dire "je ne sais pas" et de contredire un tech lead en réunion.
Si tu es freelance ou en train d'y passer, l'estimation prend une dimension financière directe : sous-estimer un projet au forfait peut te coûter des semaines de travail non rémunérées. Le guide pour se lancer en freelance développeur web en 2026 aborde la question du chiffrage côté indépendant.
Côté formation, les modules Symfony 7 et React incluent un travail explicite sur la décomposition de fonctionnalités en sous-tâches, qui est la base d'une bonne estimation. La formation CI/CD avec GitHub Actions couvre la partie livraison, souvent oubliée dans les estimations.
