8 heures avec des agents IA :
le workflow quotidien
d'un Lead Dev .NET

Beaucoup d'articles sur l'IA dans le développement ressemblent à des brochures commerciales : des captures d'écran de code généré en 10 secondes, des titres sur la "fin du développeur", et des estimations de productivité qui ignorent tout ce qui se passe avant et après la génération. Je vais décrire un mardi ordinaire — pas exceptionnel, pas optimisé pour l'article. Un mardi où deux PRs attendent, où un nouveau ticket arrive à 08h45, et où le sprint planning mange l'après-midi. Ce que les agents gèrent, ce qu'ils ratent, et pourquoi tout ça ne change pas le métier : ça change la texture du métier.

08:00 — Sync du matin (15 min, sans agent)

Je commence sans ouvrir de terminal. Je lis les notifications overnight : Slack, Azure DevOps, monitoring. Ce premier quart d'heure est délibérément sans agent parce que c'est là que se fait le tri de ce qui a réellement de la valeur ce matin.

Ce matin : une question d'architecture de mon collègue sur le découpage d'un bounded context (ça me demande, ça ne délègue pas), un bloquant sur une PR (je dois trancher), et trois notifications de tests verts sur la branche de la veille. Le bloquant et la question architecturale restent avec moi. Les trois notifications sont de l'information, pas une action.

Le filtre que j'applique à chaque notification est toujours le même : est-ce que ce sujet requiert du jugement contextuel que j'ai accumulé sur des années sur cette base de code et ce domaine métier ? Si oui, je le garde. Si non — pattern connu, tâche mécanique, premier jet à valider — ça peut aller à un agent. La difficulté n'est pas d'appliquer cette règle. C'est d'être honnête sur ce qui est vraiment du jugement et ce qui n'est que de la familiarité.

08:15 — Code review (30 min, augmenté par IA)

Deux PRs overnight. Je lance le skill /review et le skill /security en parallèle sur la première PR — deux minutes d'attente pendant que les agents lisent le diff et les specs associées.

Le résultat sur cette PR : quatre problèmes identifiés. Un risque IDOR sur un endpoint qui ne vérifie pas l'appartenance de la ressource à l'appelant — légitime, critique, j'aurais pu le rater en review manuelle. Un N+1 dans une query EF Core — légitime, classique, le type de chose qu'on glisse sans le voir. Deux flaggings de style sur des patterns que je connais : ce sont des faux positifs sur notre base de code spécifique, pas sur le standard général. Je les connais parce qu'ils sont dans le learned-errors.md depuis deux mois.

Je vérifie les deux vrais problèmes manuellement — trente secondes chacun pour confirmer que le contexte est bien celui que l'agent a compris. Je commente sur la PR, je demande les corrections. Total : 12 minutes. Sans agent, cette revue m'aurait pris 40 à 45 minutes, avec un risque non négligeable de passer à côté de l'IDOR si j'avais reviewé vite.

La deuxième PR est plus simple — un refactoring interne sans modification de surface publique. Cinq minutes, l'agent ne trouve rien de critique, je valide après lecture rapide du diff.

08:45 — Design d'une nouvelle feature (25 min, surtout IA)

Un nouveau ticket arrive : "Ajouter l'export PDF de la facture mensuelle". Ticket court, contexte métier riche — exactement le type de sujet où l'agent peut produire une architecture cohérente mais incomplète.

Je lance l'agent PO. Cinq minutes, je récupère un Gherkin avec sept scénarios et les critères d'acceptance. Je lis. Six scénarios sont corrects. Le septième suppose que chaque utilisateur peut exporter n'importe quelle facture — l'agent n'a pas intégré la contrainte d'isolation multi-tenant. Ça ne figure nulle part dans le ticket, donc c'est normal que l'agent ne l'ait pas incluse. Je corrige manuellement le Gherkin.

Je lance l'agent Archi. Huit minutes, je récupère la liste de fichiers, la structure commande/handler/query, les DTOs Infrastructure. L'architecture est cohérente avec nos conventions Clean Architecture. Je lis en diagonale — pas pour valider chaque ligne, mais pour détecter les dérives. Rien de problématique cette fois.

Je lance le Plan Writer. Cinq minutes, j'ai une checklist de tâches de 2 à 5 minutes chacune, ordonnée dans l'ordre TDD. Sans les agents, ce travail de design et de décomposition m'aurait pris deux heures, avec une session de whiteboard et probablement un aller-retour avec le product manager. Total avec agents : une demi-heure, dont dix minutes de relecture et de correction de la contrainte métier manquante.

09:15 — Phase Red (45 min, collaboration)

J'exécute la checklist du Plan Writer item par item. L'agent écrit les stubs de tests — la structure, les noms, les arrangements. Moi, je remplis les assertions métier : les valeurs exactes qui font sens dans le domaine, les invariants qui doivent tenir, les cas limites que le domaine impose.

C'est la phase la plus collaborative de la journée. L'agent ne connaît pas le domaine — il connaît les patterns de test. Moi, je connais le domaine mais je préfère ne pas écrire le boilerplate. On se divise naturellement : lui les structures, moi la sémantique. Le ratio sur cette session est à peu près 60/40 humain/agent, mesuré en décisions prises plutôt qu'en lignes tapées.

On fait des allers-retours. Je décris un invariant en prose — "une facture ne peut être exportée que si elle est à l'état Finalisé ou Archivé" — l'agent traduit en assertion xUnit. Je valide ou corrige. Ce cycle prend 2 à 3 minutes par invariant. Sur ce ticket : sept invariants, une heure de phase Red serait la norme. On termine en 45 minutes.

10:00 — Phase Green (45 min, surtout IA)

L'agent implémente les handlers, les queries, le câblage Infrastructure. Je surveille, je ne tape pas. Mon rôle dans cette phase est de la supervision architecturale : est-ce que l'agent reste dans les bonnes couches, est-ce qu'il introduit des couplages non voulus, est-ce qu'il respecte les conventions de naming ?

Une fois ce matin, l'agent a mis de la logique de domaine dans le controller — une condition de validation qui appartient à l'agrégat, pas à la couche API. Je l'ai vu immédiatement, j'ai corrigé la direction avec un commentaire précis. L'agent a refactoré vers le bon endroit sans résistance.

C'est ça, la phase Green avec un agent : pas regarder du code s'écrire passivement. Surveiller activement les frontières architecturales. Quand l'agent dérape — et il dérape régulièrement sur des subtilités de couche — la correction est rapide si on est attentif. Si on ne l'est pas, on découvre le problème deux semaines plus tard lors d'une review.

10:45 — Refactor et revue architecturale (20 min, moi seul)

Je fais cette phase moi-même. Pas parce que l'agent ne peut pas suggérer des refactorings — il peut, et ses suggestions sont souvent correctes sur le plan technique. Mais les décisions de refactoring exigent de comprendre la trajectoire de maintenance sur trois ans. L'agent ne sait pas que ce module va être découpé au troisième trimestre. Il ne sait pas que cette abstraction qu'on pourrait extraire sera de toute façon supprimée dans quatre mois lors d'une migration.

Refactorer c'est arbitrer entre la lisibilité aujourd'hui et la maintenabilité dans un futur que seul un humain avec le contexte du projet peut anticiper. C'est un jugement que je ne délègue pas.

11:05 — Kaizen snapshot (10 min)

Dix minutes avant de passer à la suite. Qu'est-ce qui a accroche ce matin ?

L'agent Archi a manqué la contrainte multi-tenant — normal, elle n'était pas dans le ticket, mais c'est un pattern récurrent sur ce projet. J'ajoute une ligne dans learned-errors.md : la contrainte d'isolation doit être vérifiée systématiquement sur tous les tickets touchant aux factures, même si elle ne figure pas explicitement dans le ticket. Je mets à jour le CLAUDE.md avec une règle qui s'appliquera à la prochaine session.

Un des tests que l'agent a écrit en phase Red était trop permissif : il vérifiait qu'une valeur était non nulle au lieu de vérifier qu'elle était exactement la valeur attendue. Ce type d'assertion passe quand tout va bien et ne détecte pas les régressions. Je corrige le test, j'ajoute une ligne dans learned-errors.md.

Dix minutes. Deux entrées. C'est tout.

L'IA ne change pas le métier — elle change la texture du métier. Vous pensez plus, vous tapez moins. Vous décidez plus, vous attendez moins. La différence entre un développeur qui utilise des agents comme un outil rapide et un développeur qui construit un système qui s'améliore tient en grande partie à ces dix minutes quotidiennes.

L'après-midi (esquisse)

Le sprint planning à 14h00 se fait sans agents. C'est une conversation humaine — négociation de priorités, estimation collective, arbitrages sur la capacité. Un agent qui génère des story points ne comprendrait pas pourquoi on sous-estime volontairement le ticket qui dépend d'une migration legacy non documentée. Le contexte social et politique du planning est opaque pour un agent.

À 15h30, je démarre deux nouvelles stories indépendantes en parallèle via des worktrees Git séparés — deux agents qui travaillent en parallèle sur deux branches distinctes pendant que je supervise les deux. C'est le mode de travail le plus efficace pour des tâches indépendantes : le temps de développement est divisé par deux sur le scaffolding, et la supervision reste linéaire.

À 17h30, je ferme la journée : tests verts obligatoires avant le push, snapshot de rétrospective — deux phrases sur ce qui a avancé et ce qui a bloqué. Ce snapshot n'est pas pour moi seul : il alimente la mémoire du projet au sens large.

La comptabilité honnête

Sur une semaine de 40 heures, voici comment le temps se répartit réellement :

• Ce que les agents gèrent — environ 14 heures : scaffolding, premier jet de tests, première passe de revue, génération de specs Gherkin, câblage Infrastructure. Tout ce qui est mécanique, répétitif, ou dont la valeur est dans le résultat et non dans l'acte de production.
• Ce que je gère — environ 26 heures : décisions architecturales, assertions métier, refactoring stratégique, design de domaine, planning, communication avec le product, supervision active des agents en phase Green.

Le gain net est d'environ 8 à 10 heures par semaine qui étaient auparavant de la charge cognitive mécanique — pas de la réflexion, juste de la frappe et de la navigation dans des patterns connus. Ces heures sont maintenant disponibles pour ce qui demande réellement du jugement.

Ce n'est pas une division du travail entre "humain créatif" et "machine mécanique". Les agents font des erreurs métier. Les humains font des erreurs mécaniques. La vraie division est : qui est responsable de la décision ? La réponse est toujours l'humain — les agents proposent, l'humain valide et assume.

L'habitude qui fait tout composer

Si je devais isoler une seule pratique qui distingue un workflow avec des agents qui composent dans le temps d'un workflow qui stagne, c'est le kaizen snapshot de 10 minutes. Pas la qualité des agents, pas le nombre de skills configurés, pas la puissance du modèle.

Sans le snapshot, vous utilisez un outil rapide. Avec le snapshot, vous construisez un système apprenant. Chaque correction capturée dans learned-errors.md devient une règle dans CLAUDE.md qui s'applique à la session suivante. Chaque pattern de faux positif documenté évite 5 minutes de re-vérification le lendemain. Chaque invariant métier manqué une fois est une règle qui ne manquera plus.

Au bout de trois mois, le CLAUDE.md ressemble à la mémoire institutionnelle du projet — les règles que n'importe quel nouvel arrivant sur la mission devrait connaître, capturées non pas parce que quelqu'un a pris le temps de documenter, mais parce que le système apprend de ses erreurs en continu. C'est le seul mécanisme de composition que j'ai trouvé qui fonctionne vraiment dans la durée.