En juin 2026, j'ai publié deux posts LinkedIn le même mois.
Le premier racontait l'histoire d'un dev qui avait craqué. 112 508 impressions, 376 réactions, 38 commentaires, 25 sauvegardes. Record de mon compte.
Le second parlait de Compound Engineering. Une méthode pour inverser le ratio code/réflexion dans une équipe. 563 impressions, 1 réaction, 0 commentaires, 0 sauvegardes. Rien.
Ces deux posts parlaient du même sujet : la mutation du lead dev à l'ère de l'IA. Le premier a cartonné parce qu'il racontait une histoire. Le second est passé inaperçu parce qu'il expliquait comment faire.
C'est le problème que cette newsletter résout.
Pourquoi le lead dev doit devenir orchestrateur
Le constat qui ne passe pas sur LinkedIn
Depuis 18 mois, en mission chez Boiron, dans les échanges avec d'autres leads tech, dans ma propre façon de travailler, je vois la même chose.
Le métier change. Pas dans 5 ans. Maintenant.
Avant : 80% du temps à écrire du code. Le dev est un producteur.
Maintenant : 80% du temps à orchestrer des agents, concevoir l'architecture, reviewer les outputs, décider quoi coder (et quoi ne pas coder). Le dev devient un orchestrateur.
Ce n'est pas une dégradation. C'est une élévation. Les tâches mécaniques sont déléguées. Ce qui reste, c'est ce qui compte : la compréhension métier, les décisions d'architecture, la revue critique, les arbitrages.
Mais personne n'explique comment on fait cette transition. Comment on passe de "je code" à "j'orchestre". C'est le vide que cette newsletter remplit.
Ce qui change (et ce qui ne change pas)
Ce qui change :
Le prompt engineering et la supervision d'agents deviennent des compétences core
L'architecture et la conception prennent plus de place que l'implémentation
La review critique du code généré par IA devient une compétence à part entière
La compréhension métier devient le différenciateur principal
Ce qui ne change pas :
La rigueur sur la qualité du code. Elle est amplifiée : si tu ne sais pas reconnaître une mauvaise suggestion IA, tu produis de la dette plus vite
La capacité à détecter les erreurs, les angles morts, les dettes cachées
La responsabilité des décisions d'architecture
Le framework : Compound Engineering
La méthode la plus concrète que j'ai trouvée pour formaliser cette mutation s'appelle le Compound Engineering (Every, Dan Shipper). Elle décompose le travail du lead dev en 4 étapes :
Étape | % du temps | Description |
|---|---|---|
Plan | 40% | Comprendre le problème, le décomposer, décider quoi faire. L'IA aide à explorer les options, challenger les hypothèses. Toi tu décides. |
Review | 40% | L'IA exécute, toi tu reviews. Pas une relecture superficielle : tu vérifies que le code résout le vrai problème, qu'il est maintenable, qu'il ne crée pas de dette invisible. |
Work | 10% | Le code que toi seul peut écrire. L'architecture critique, le refactoring sensible. L'IA est ton copilote, pas ton remplaçant. |
Compound | 10% | L'étape que tout le monde saute. Tu documentes ce que tu as appris : patterns découverts, erreurs évitées, décisions architecturales. Ce savoir est réinjecté dans les futures itérations de Plan. Le système apprend de lui-même. |
Résultat : 5 produits en production, chacun maintenu par une seule personne. C'est la réalité d'Every aujourd'hui. Pas une promesse.
La nuance : l'Oversight Tax
Si je m'arrêtais là, cette newsletter serait un post LinkedIn de plus sur "comment l'IA va changer le dev". Tu passerais à autre chose en te disant "ouais, c'est plus compliqué que ça."
Parce que c'est plus compliqué.
Déléguer une tâche à un agent IA ne supprime pas la charge cognitive : elle la déplace. Le HBR (Harvard Business Review) appelle ça l'"AI brain fry". Tu restes assez alerte pour détecter des erreurs que tu ne fais plus toi-même. C'est épuisant.
Un agent qui échoue à 15% par étape sur un workflow de 8 étapes n'a que 27% de chances de terminer correctement. (0,85^8 ≈ 0,27). Tu passes ton temps à superviser.
La règle que j'ai apprise dans la formation Prism One : environ 50 exécutions réussies avant autonomie. Après 50 résultats fiables consécutifs, la vérification systématique devient superflue et la charge cognitive chute.
C'est ça, le vrai travail de l'orchestrateur. Pas déléguer et se reposer. Construire un système de confiance progressif, agent après agent, jusqu'à ce que le compounding opère.
LinkedIn est un excellent canal. Mais il récompense l'émotion et la narration, pas la profondeur technique. Mes posts les plus populaires (le burnout à 112k, le dev parti avec l'archi à 58k) racontent des histoires. Mes posts les plus utiles (Compound Engineering, Oversight Tax) plafonnent à 500-2000 impressions.
Cette newsletter est l'espace où je peux développer ces sujets sans la contrainte de l'algorithme. Un deep dive par mardi. Un sujet, des étapes concrètes, des exemples de code, la nuance qui manque sur LinkedIn.
Chaque numéro contiendra :
Un deep dive principal
3-5 liens sélectionnés
Un outil ou une méthode testée
Liens sélectionnés de la semaine
Compound Engineering, How Every Codes With Agents (Dan Shipper). L'article original qui a formalisé le framework. Si tu ne lis qu'un truc cette semaine, c'est celui-ci.
When Using AI Leads to "Brain Fry" (HBR). L'étude sur la charge cognitive de la supervision des agents.
Bootcamp Prisme One. La formation que je suis en ce moment. Ça nourrit directement le contenu de cette newsletter.
Outil de la semaine
Claude Code (mode agent). L'outil que j'utilise pour orchestrer mes agents de code. Le mode agent + un fichier CONTEXT.md bien écrit changent la donne sur les tâches de refactoring répétitives.
Une question pour toi
Cette newsletter n'existe que si elle apporte de la valeur. Alors réponds-moi :
Tu ressens cette mutation dans ton quotidien de lead dev ? Tu es où sur le spectre entre "je code encore 80%" et "j'orchestre déjà 80%" ?
Une ligne suffit. Ça m'aide à choisir les prochains sujets.