Coder à 3× la vitesse avec des agents IA — sans devenir un dev qui copie-colle

La phrase que j'entends 5 fois par semaine

"Vous codez avec l'IA ? Vous êtes courageux. J'ai testé ChatGPT, ça m'a sorti du code qui marchait pas. C'est pas mûr."

C'est presque toujours dit par un dev senior de 38-50 ans. Et c'est presque toujours faux — pas leur expérience, leur cadrage est faux.

Ils ont testé l'IA comme un traducteur ("réécris-moi ce code en Python"), pas comme un collaborateur ("voilà mon repo, vois où je peux ajouter X, écris la PR, teste").

La différence entre ces deux approches est la même qu'entre un junior et un senior. Et c'est la seule raison pour laquelle l'IA en dev a une réputation mitigée.

Voici comment je l'utilise concrètement.

Mon workflow réel — un projet quelconque, lundi matin

Lundi. Mon client veut ajouter un module "abonnements récurrents Stripe" à SaleCast. Sans IA, je commence comme ça :

1. Je lis la doc Stripe Subscriptions (1 h)
2. Je regarde l'archi existante de SaleCast pour voir où ça s'insère (30 min)
3. Je code le modèle EF Core (1 h)
4. Je code le webhook handler (2 h)
5. Je teste manuellement (1 h)
6. 6 heures pour la première itération.

Avec Claude Code, voici ce que je fais à la place :

Étape 1 — Briefing de l'agent (5 min)

J'ouvre Claude Code dans le projet. Pas dans un chat web — dans le projet ouvert, avec accès direct au filesystem.

Je tape :

"Lis CLAUDE.md et ARCHITECTURE.md. Audit l'archi des modules existants. Trouve où ajouter un module Subscriptions Stripe. Donne-moi un plan en 8 étapes max, sans coder. Cite les fichiers spécifiques que tu vas créer/modifier."

L'agent lit. Il sort un plan :

1. Créer Application/Domains/Subscription/SubscriptionPlan.cs
2. Créer Application/Domains/Subscription/SubscriptionStatus.cs (enum)
3. Migration EF Core : 20260803_AddSubscriptions
4. Endpoint webhook : Controllers/StripeWebhookController.cs
5. Service Fusion : Application/Services/Fusion/SubscriptionFusionService.cs
6. Composant Blazor : Components/Pages/Subscriptions.razor
7. Helper Stripe SDK : Application/Services/Stripe/StripeClient.cs
8. Tests unitaires : SaleCast.Tests/Subscription/SubscriptionTests.cs

C'est mon archi. Mes noms de dossiers. Ma convention de migrations. Il a lu mes fichiers, il propose une structure cohérente.

Étape 2 — Validation humaine (5 min)

Je lis le plan. Je le challenge.

Le plan a peut-être 7 points qui sont parfaits et 1 qui est faux. Mon job est de trouver le mauvais.

Dans l'exemple : "Composant Blazor Subscriptions.razor". Faux — mes admins clients sont dans /Pages/Admin/, pas à la racine. Je corrige :

"Le composant Blazor va dans /Components/Pages/Admin/Subscriptions.razor. Les autres points sont OK. Vas-y."

Étape 3 — L'agent code (1 h pendant que je fais autre chose)

L'agent commence à exécuter. Il crée les fichiers, écrit le code, lance les tests, corrige ses erreurs de compilation.

Pendant ce temps, je n'attends pas. Je vais répondre à des emails. Je réfléchis à la roadmap. Je prépare un déploiement. L'agent travaille en parallèle, comme un dév junior à qui on a donné une tâche claire.

Étape 4 — Audit du diff (30 min)

Quand l'agent finit, il me dit "j'ai créé X fichiers, voici le diff".

Je lis le diff. Ligne par ligne. Pas en diagonale. Ligne par ligne.

C'est l'étape la plus importante du workflow. C'est ce qui sépare un dev qui code avec l'IA d'un dev qui ship du code qu'il ne comprend pas.

Sur cette PR de SaleCast, j'ai trouvé :

• Une typo dans le nom d'un enum (correctement nommé partout sauf 1 endroit)
• Un test qui n'avait pas de cas négatif
• Une dépendance circulaire entre SubscriptionPlan et Customer
• Un appel API Stripe sans idempotency_key (bug grave en concurrence)

Je corrige les 4. Total : 20 minutes.

Étape 5 — Tests + déploiement (15 min)

Je lance les tests. Tout passe. Je push. Je déploie sur staging.

Temps total : 5 + 5 + 60 (en parallèle d'autres tâches) + 30 + 15 = ~1h45 de mon temps actif.

Vs 6h de travail séquentiel sans agent.

Les 5 règles que j'ai apprises douloureusement

Règle 1 — Ne jamais demander à l'IA de coder sans contexte

❌ "Écris-moi un système d'abonnement Stripe."

✅ "Lis CLAUDE.md. Audit Application/Domains/. Propose 8 étapes pour ajouter un module Subscription cohérent avec l'archi existante. Ne code pas encore."

La première version est un appel d'aide générique. La seconde est un briefing. La qualité du résultat est proportionnelle à la qualité du briefing.

Règle 2 — Toujours faire planifier avant coder

L'agent qui code directement sans plan est l'équivalent du dev qui ouvre VSCode et commence à taper sans avoir réfléchi. Tu dois lui faire produire un plan explicite que tu valides avant qu'il tape une ligne.

90 % de mes erreurs proviennent d'avoir sauté cette étape.

Règle 3 — Audit obligatoire du diff complet

L'agent ment. Pas par malice — par construction probabiliste. Il dit "j'ai géré le cas X" et n'a pas codé le cas X. Il dit "les tests passent" et n'a pas lancé les tests. Il dit "j'ai utilisé ton convention de naming" et a inventé deux conventions différentes.

Tu lis le diff. Tout le diff. Toujours.

Le jour où tu commences à merger sans lire, tu introduis des bugs que tu ne comprends pas. Et 6 mois plus tard, tu maintiens un code que tu ne reconnais pas.

Règle 4 — Faire valider par un agent différent

Sur les PR critiques, j'utilise une astuce simple :

Premier agent (Claude Sonnet) : "Code la feature."

Deuxième agent (Claude Opus, indépendant) : "Voici un diff produit par un autre agent. Trouve les 3 problèmes les plus graves. Ne corrige pas, signale."

Le deuxième agent n'a pas l'attachement émotionnel au code qu'il a écrit. Il trouve des trucs que le premier n'a pas vus.

Sur 4 PR sur 5, le 2e agent trouve au moins un bug réel que j'aurais raté en audit humain.

Règle 5 — Garder la main sur l'archi

L'agent code bien des features. Il code mal une architecture entière.

Quand un client me demande "fais-moi une plateforme SaaS avec 200 endpoints", je ne demande pas à l'agent de tout coder. Je code moi-même l'archi de base : routing, auth, DI, premier domain complet (User par exemple). Ça lui montre les patterns. Ensuite je le laisse répliquer pour les 199 autres endpoints.

Si je sautais cette étape, l'agent inventerait sa propre archi. Chaque domain aurait des conventions différentes. Le projet serait inmaintenable au mois 3.

Les outils que j'utilise concrètement

Je n'utilise pas :

• ChatGPT pour coder (chat web → copy-paste = ~10× plus lent qu'un agent IDE)
• Cursor (l'autocompletion est plus dangereuse que productive — elle te suggère des choses fausses subtilement, contrairement à un agent qui te montre un plan explicite)
• Copilot (idem — l'IA en autocompletion bypass l'étape "plan validé")

L'effet métier sur 12 mois

Avant Claude Code (Q1 2025) :

• ~6 issues GitHub fermées par semaine
• ~150 lignes de C# par jour de travail effectif
• Time-to-feature moyen : 4 jours

Avec Claude Code (Q2-Q4 2025) :

• ~18 issues fermées par semaine
• ~500 lignes par jour
• Time-to-feature : 1,5 jour

3× la vélocité. Pas 10×, pas 100×. Trois. C'est mesurable. C'est constant depuis 9 mois. C'est ce qui m'a permis de livrer 9 produits en 11 mois.

Le mythe du "l'IA va remplacer les développeurs" rate complètement la cible. Ce qui se passe en vrai : l'IA multiplie les développeurs senior par 3 et laisse les développeurs débutants à leur vitesse normale. L'écart s'ouvre.

La leçon

L'IA en dev n'est pas une question d'outil — c'est une question de méthode.

Le développeur qui demande "écris-moi un truc" obtient du code médiocre.

Le développeur qui briefe, fait planifier, audite, valide, et garde la main sur l'archi obtient un collaborateur qui code 3× plus vite que lui sans sacrifier la qualité.

La différence entre les deux n'est pas l'IA. C'est la maîtrise du processus de délégation. La même compétence qu'un manager qui sait déléguer à son équipe vs un manager qui veut tout faire lui-même.

C'est, ironiquement, une compétence de senior.

Ce que ça veut dire pour ton parcours

Si tu es dev senior et que tu n'as pas encore intégré un agent IA dans ton workflow quotidien, tu prends 2026 avec un handicap de 3×.

Ce n'est pas une question d'éthique. Ce n'est pas une question de "remplacement". C'est purement opérationnel : tes pairs qui l'utilisent shippent 3× plus que toi, à qualité égale ou supérieure, pour le même salaire.

Sur 3 ans, l'écart est colossal.

Tente l'expérience. Prends Claude Code, ouvre-le dans un de tes vrais projets, et passe une journée à essayer le workflow décrit ci-dessus. Pas une "demo". Une vraie tâche productive de la journée.

Tu m'en diras des nouvelles.

Stack & outils

• Claude Code (Anthropic) — CLI + intégration IDE (VS Code, JetBrains)
• Modèles utilisés : Claude Opus pour planification et audit, Claude Sonnet pour le code de masse
• MCP servers : MCP filesystem (pour lire le repo), MCP git (pour le diff review)
• Workflow : Plan mode → Code mode → diff review → second agent cross-check
• Coût : ~$80/mois en API + Plan Opus → ROI ~50× sur le coût d'un dev sénior

L'IA en dev n'est pas un sujet de "futur du travail". C'est un sujet de workflow d'aujourd'hui. Et ceux qui le maîtrisent en 2026 auront une avance structurelle sur ceux qui s'y mettent en 2028.