Workflow d'estimation de développement avec Claude Code pour projets réels

Estimer un développement ne consiste pas à deviner un nombre exact de jours. Dans un vrai projet, une bonne estimation explique le périmètre, les hypothèses, les inconnues, les risques, le temps de revue et la vérification afin que produit, ingénierie et client décident avec les mêmes preuves.

L’erreur classique des débutants est de ne compter que le temps de code. “Ajouter un champ téléphone au profil” semble petit, mais peut toucher une migration de base de données, les types d’API, la validation de formulaire, les exports CSV, les logs d’audit, les tests, les notes de release et la disponibilité des reviewers. Une migration modifie le schéma ou les données. Elle mérite une estimation séparée, car les données ne se restaurent pas toujours aussi facilement que le code.

Claude Code ne rend pas les estimations magiquement exactes. Sa valeur est de lire le dépôt, révéler le rayon d’impact, mettre les hypothèses et inconnues en tableau et rendre les risques visibles. Ne lui demandez pas d’inventer une date certaine. Demandez-lui de réduire les oublis.

Cette approche rejoint l’empirisme du Scrum Guide: transparence, inspection et adaptation. Pour suivre un ensemble d’issues et de PRs, la documentation GitHub sur les milestones est utile. Pour l’estimation relative, le guide Atlassian estimation peut aider. Pour Claude Code, gardez l’overview et la CLI reference à portée de main.

Pour approfondir côté ClaudeCodeLab, lisez aussi naviguer dans un codebase, le template de bug report et la checklist de code review.

Séparer Les Entrées De L’estimation

Avant de parler de dates, séparez cinq entrées.

Entrée	Sens simple	Aide possible de Claude Code
scope	Ce qui est inclus et exclu	Fichiers, fonctions liées, tests
assumptions	Ce qui doit être vrai	Règles produit, permissions, release
unknowns	Ce qui manque	Fichiers, questions, responsables
risk buffer	Marge pour échec et attente	Migration, auth, paiement, review
evidence	Pourquoi le chiffre tient	PRs passées, git history, tests

Évitez “2 jours” seul. Préférez “bas: 1,5 jour; probable: 3 jours; haut: 5 jours si le CRM entre dans le scope”. Une fourchette n’est pas un aveu de faiblesse. Elle montre ce qui est connu et ce qui peut encore bouger.

flowchart LR
  A["Demande"] --> B["repo scan"]
  B --> C["décomposition"]
  C --> D["table des hypothèses"]
  D --> E["registre des risques"]
  E --> F["fourchette"]
  F --> G["prompt de revue"]
  G --> H["résumé client"]

Quatre Cas D’usage Réalistes

Premier cas: un champ de profil dans un SaaS. Ajouter phone_number peut toucher le schéma de base, la validation API, l’UI, la recherche, les exports CSV, les audit logs, la confidentialité et les tests. Si c’est une donnée personnelle, le masquage dans les logs et les règles de suppression ou d’export font partie de l’estimation.

Deuxième cas: un bug sur un écran legacy. “Le filtre ne marche pas” peut impliquer des helpers de requête anciens, du cache, des paramètres d’URL, des fixtures et de l’E2E. Avant de demander la correction, demandez à Claude Code de cartographier l’impact et la vérification.

Troisième cas: une proposition de conseil ou une demande DX interne. Le client dit “il nous faut un admin”, mais le vrai scope peut inclure login, rôles, audit, CSV, notifications, transfert de droits et manuel d’exploitation. Claude Code peut lire issues et code existants pour révéler le travail absent de la demande initiale.

Quatrième cas: un site de contenu monétisé. Un petit changement MDX peut inclure performance, liens internes, OGP, données structurées, localisation, captures et revue de layout compatible AdSense. La qualité de publication dépasse l’édition de texte.

Échecs Fréquents

Premier échec: partager la première intuition comme engagement. “Probablement un jour” est un souhait avant lecture du dépôt. Dès qu’il atteint un stakeholder, une estimation plus réaliste ressemble à un retard.

Deuxième échec: considérer revue et vérification comme gratuites. Six heures d’implémentation peuvent encore demander tests, corrections de review, staging, notes de release et coordination de déploiement.

Troisième échec: cacher les inconnues dans un buffer vague. “Ajouter 30%” ne suffit pas sans nommer la cause: API externe incertaine, rollback non conçu, file d’attente des reviewers, fixtures manquantes, règles produit floues.

Quatrième échec: croire un chiffre IA sans preuves. Si Claude Code dit “3 jours” sans fichiers, PRs passées, tests et risques, c’est seulement une prose bien présentée.

Step 1: Repo Scan En Lecture Seule

Commencez par la forme du dépôt. Ne modifiez rien.

git status --short
git branch --show-current
git rev-parse --show-toplevel

rg --files \
  -g '!*node_modules*' \
  -g '!dist' \
  -g '!build' \
  -g '!coverage' \
  -g '!*.lock' \
  | sort \
  | head -200

find . -maxdepth 3 \( \
  -name package.json -o \
  -name pyproject.toml -o \
  -name go.mod -o \
  -name Cargo.toml -o \
  -name AGENTS.md -o \
  -name CLAUDE.md -o \
  -name README.md \
\) -print

Puis demandez une carte en lecture seule.

claude -p "
Run a read-only repo scan.
Do not edit, create files, or add dependencies.

Return:
1. apps, packages, and services
2. runtime, test, and build entrypoints
3. generated folders to ignore
4. 10 files that must be read for this estimate
5. reasons this task cannot yet be estimated
"

Step 2: Décomposer La Tâche

Découpez en unités révisables et vérifiables.

claude -p "
Task: Let users add, view, and edit a phone number on their profile.

Break this into reviewable work items.
For each item include:
- name
- likely files
- implementation work
- test work
- definition of done
- size: small, medium, or large

Also list out-of-scope items.
Separate guessed product rules as assumptions.
"

On obtient souvent DB, API, UI, tests et release. Si une unité est trop grosse pour une PR, découpez avant d’estimer.

Step 3: Table D’hypothèses

Les hypothèses sont les points de rupture futurs. Écrivez-les.

| ID | Assumption | Why it matters | Owner | Confirm by |
| --- | --- | --- | --- | --- |
| A1 | Phone number is optional | Required fields change validation and migration | PM | 2026-06-05 |
| A2 | Web only, no mobile app change | Mobile release adds review and store delay | PM | 2026-06-05 |
| A3 | Existing user rows stay null | Backfill work is not included | Tech lead | 2026-06-06 |

claude -p "
Review this assumptions table.
Find assumptions that could break the estimate.
Add missing owners, deadlines, and questions.
Move anything risky into a risk register.
"

Step 4: Registre Des Risques

Un registre des risques liste ce qui peut casser le plan.

| Risk | Trigger | Impact | Mitigation | Buffer |
| --- | --- | --- | --- | --- |
| DB rollback is unclear | migration changes existing rows | High | dry-run and rollback plan | 0.5-1 day |
| External CRM stores phone | CRM field mapping appears | Medium | check integration owner | 0.5 day |
| Review queue is full | no reviewer within 24h | Medium | book review slot early | 1 day |
| Test data is missing | no edge-case users | Medium | create fixtures first | 0.5 day |

Le buffer n’est pas du confort. C’est de la place pour l’incertitude, l’échec et l’attente. Authentification, paiement, données privées, suppression et migrations méritent plus de risque explicite qu’un changement purement UI.

Step 5: Calculer Une Fourchette

Ce script est directement exécutable.

// estimate-range.mjs
const tasks = [
  { name: "Repo scan and design check", hours: 2, risk: 1.1 },
  { name: "DB migration and schema", hours: 4, risk: 1.4 },
  { name: "API contract and validation", hours: 5, risk: 1.2 },
  { name: "Profile UI update", hours: 6, risk: 1.2 },
  { name: "Tests and fixtures", hours: 5, risk: 1.3 },
  { name: "Review fixes and release note", hours: 3, risk: 1.2 },
];

const base = tasks.reduce((sum, task) => sum + task.hours, 0);
const likely = tasks.reduce((sum, task) => sum + task.hours * task.risk, 0);
const low = Math.max(base * 0.8, base - 4);
const high = likely * 1.35;

const day = 6;
const format = (hours) => `${hours.toFixed(1)}h / ${(hours / day).toFixed(1)}d`;

console.log(`Low:    ${format(low)}`);
console.log(`Likely: ${format(likely)}`);
console.log(`High:   ${format(high)}`);

node estimate-range.mjs

Ne traitez pas le multiplicateur comme une vérité. risk: 1.4 signifie “cette zone est incertaine”. Si vous le changez, notez pourquoi dans l’issue ou la PR.

Step 6: Revue Critique

Avant de l’envoyer au client, faites attaquer l’estimation par Claude Code.

You are a critical project estimation reviewer.

Review this estimate before I share it with a client.
Find:
1. hidden scope
2. weak assumptions
3. missing tests
4. missing rollout or rollback work
5. fake precision
6. tasks that should be split

Return findings first.
Then provide a revised low / likely / high range.
Do not make the estimate look more certain than the evidence supports.

La consigne compte. “Rends cela plus joli” produit une prose plus jolie. “Revue critique” produit des objections utiles.

Step 7: Résumé Client

Transformez les notes internes en court document de décision.

# Development Estimate Summary

## Scope
- Add optional phone number to user profile.
- Update DB schema, API validation, profile UI, and tests.
- Include release note and manual verification.

## Not included
- SMS notification.
- Mobile app release.
- Historical data backfill.
- CRM integration changes unless confirmed.

## Estimate
- Low: 3 business days
- Likely: 4-5 business days
- High: 7 business days if CRM or migration rollback work expands

## Assumptions
- Phone number is optional.
- Web only.
- Existing users can keep the value empty.

## Risks
- DB rollback plan must be reviewed before implementation.
- Reviewer availability may add one calendar day.

## Next decision
- Confirm whether CRM and mobile app are in scope by 2026-06-05.

Remettez ensuite l’estimation dans GitHub Issues ou un milestone pour comparer au réel.

## Estimate
- Low:
- Likely:
- High:
- Confidence: Low / Medium / High

## Scope
- [ ]

## Out of scope
- [ ]

## Assumptions
- [ ]

## Risks
- [ ]

## Verification
- [ ] Unit tests:
- [ ] Integration tests:
- [ ] Manual check:

## Actual result
- Started:
- Merged:
- Extra work found:
- What to adjust next time:

La section Actual result transforme la prochaine estimation en apprentissage concret.

CTA Conseil

L’estimation mène naturellement au conseil, car chaque lecteur doit adapter le workflow à son dépôt, ses clients et ses règles d’équipe. ClaudeCodeLab peut aider à concevoir templates d’estimation, prompts de revue Claude Code, checklists PR et règles de déploiement d’équipe. Pour relier cela à vos issues ou propositions, envoyez le contexte via formation et conseil Claude Code.

Résultat Vérifié

Masa a testé ce workflow sur un petit changement de champ de profil. L’intuition initiale était “une demi-journée d’UI”. Après repo scan, le plan incluait schéma DB, validation API, export CSV, audit logs, tests et file de review. La fourchette client est devenue 4-5 jours ouvrés probables, avec un haut à 7 jours si le CRM apparaissait. Claude Code a été utile non pour prédire la date, mais pour révéler tôt les fichiers cachés et les inconnues.