Des éclats de
pensée.

Ce qu'on appelle "dev augmenté" n'est pas ce qu'on croit.

La première image — un développeur qui code plus vite grâce à l'autocomplétion — est la plus pauvre. C'est l'usage le plus répandu, et probablement le moins transformateur.

Ce qui est réellement nouveau : la capacité à tenir plusieurs niveaux de complexité en parallèle sans perte de cohérence. Un architecte qui spécifie, valide, documente et implémente en même temps. Pas séquentiellement — en parallèle, dans le même mouvement de pensée.

Rupture de fond, pas accélération de surface.

---

Le spectre des usages, du plus superficiel au plus structurant :

Niveau 1 — Autocomplétion. Copilot, Cursor, Tabnine. Gain de vitesse réel, impact intellectuel faible.

Niveau 2 — Génération à la demande. "Écris-moi une fonction qui fait X." Délègue l'implémentation mais pas la conception. Risque : produire du code qu'on ne comprend pas, donc qu'on ne maintient pas.

Niveau 3 — Spec-first avec l'IA comme miroir. On écrit des specs, des ADRs. L'IA les valide, les questionne, les enrichit. Le code vient ensuite. Simon Willison documente cette pratique — "Here's how I use LLMs to help me write code" — l'IA comme interlocuteur de conception, pas comme générateur.

Niveau 4 — Multi-agent / rôles distribués. Plusieurs personas avec des responsabilités distinctes. Chaque agent contraint son scope, ce qui force la séparation des préoccupations dans la pensée du praticien.

Niveau 5 — Architecture-dev augmentée. L'intégration complète : l'IA participe au modèle formel, aux décisions d'architecture, aux specs UX, à l'implémentation et aux tests — avec un praticien qui reste le décideur à chaque étape. Le moins documenté, le plus rare, probablement le plus puissant.

---

La valeur des personas IA n'est pas dans la simulation de collègues fictifs. Elle est dans la discipline intellectuelle qu'ils imposent.

Quand Nora ne peut pas trancher sur l'architecture et que Mira ne spécifie pas l'UX, ce n'est pas un jeu de rôle. C'est une contrainte cognitive volontaire qui force à ne pas mélanger les niveaux de raisonnement. Un architecte seul saute de la contrainte technique à la décision UX sans transition. Les personas forcent cette transition à être visible.

Pensée structurée, pas délégation.

---

Le vrai risque : la vitesse sans profondeur.

L'IA doit ralentir certaines décisions, pas seulement accélérer leur production. Un ADR écrit avec l'IA mais validé consciemment prend plus de temps qu'un ADR généré et accepté sans friction. C'est voulu. La valeur est dans la validation, pas dans la génération.

---

Le profil le mieux positionné n'est pas le développeur junior qui cherche de l'aide pour coder. C'est l'architecte-praticien qui comprend déjà la complexité du problème, qui sait quelles questions poser, et qui utilise l'IA pour tenir cette complexité à un niveau de détail qu'il ne pourrait pas tenir seul.

Pas "l'IA fait le travail à ma place". C'est "l'IA me permet de travailler à un niveau que je n'atteignais pas seul."

Différence qualitative, pas quantitative.

Deux philosophies. Deux rapports au contrôle.

D'un côté, on configure une fois : agents, hooks, pipelines. Puis ça tourne. L'humain supervise de loin. 28 agents, 125 skills, persistance SQLite — l'infrastructure fait le travail. C'est séduisant. C'est rapide. C'est everything-claude-code.

De l'autre, on assigne des rôles. Les agents ne s'automatisent pas — ils contestent, spécifient, bloquent. La friction n'est pas un obstacle. C'est le mécanisme de valeur.

---

Le terrain a tranché avant la théorie.

Un repositionnement CVM lancé sans spec, deux refactos enchevêtrées, périmètre non borné. Résultat : ko. Ce n'est pas un agent qui a failli — c'est un pilotage qui a manqué.

Plus l'agent est capable, plus la dette potentielle est grande. Il prend des raccourcis cohérents localement mais incohérents globalement. Loin sans direction précise, c'est de la dette accumulée silencieusement.

---

Ce que la friction structurelle produit : Lea audite les docs et détecte que "peer-reviewed" et "formellement vérifié" sont utilisés partout pour un preprint arXiv avec 5 bloquants et 9 majeurs. Sans persona dédiée à la rigueur, cette surévaluation reste dans les ADR et la landing page. C'est Lea qui pose le bloquant — pas un hook, pas une CI.

Personne dans la littérature ne fait la configuration complète : personas isolées avec périmètres d'écriture, friction structurelle inter-personas, un seul humain qui orchestre.

---

	Config-once	Role-based
Valeur cible	Vélocité	Qualité de décision
Rôle humain	Superviseur qui se retire	Acteur central augmenté
Friction	Obstacle à éliminer	Mécanisme de valeur
Risque	Dette silencieuse	Blocage si pas de PO

---

L'humain n'est pas retiré de la boucle — il est le seul à pouvoir résoudre ce que les personas ne peuvent pas résoudre entre elles. Lui donner une équipe de haut niveau avec friction intégrée, pas un pipeline qui tourne sans lui.

L'architecture complexe se pilote. Elle ne se délègue pas.

L'industrie converge vers une seule direction : l'IA qui fait tout, l'humain qui supervise. Devin, Cursor Agent, Claude Code autonome, SE 3.0 — la trajectoire dominante est la réduction de l'humain dans la boucle.

Il y a une deuxième école, minoritaire, qui fait l'inverse : l'IA comme amplificateur de la pensée humaine. L'humain reste au centre, mais il pense mieux, décide mieux, voit plus loin.

Ce ne sont pas deux points sur un spectre. Ce sont deux philosophies incompatibles.

---

Full automatique. L'objectif : minimiser la friction, maximiser l'autonomie de l'agent. Le KPI : temps économisé, tâches complétées sans intervention. L'humain : superviseur, validateur, parfois spectateur.

Cas emblématique : everything-claude-code. Même outil que nous, philosophie inverse. 28 sous-agents, 120+ skills automatisés, boucles autonomes. L'objectif : optimiser le harness. Le produit est l'infrastructure d'automatisation elle-même, pas ce qu'on construit avec.

Humain augmenté. L'objectif : générer de la friction utile, amplifier le jugement humain. Le KPI : qualité des décisions, profondeur de la réflexion. L'humain : orchestrateur, arbitre, penseur au centre. Plus lent, plus exigeant, moins vendable.

---

La première école est en train de gagner par défaut. Pas par supériorité — par visibilité. Les outils, le marketing, les benchmarks, les investissements vont tous dans cette direction.

La deuxième école n'a presque pas de voix. Quelques papiers — constructive controversy, devil's advocacy IA, co-creative friction — mais pas de produit, pas de méthodo documentée, pas de communauté.

Notre approche est dans la deuxième école. Le HITL comme transition Petri formelle, pas comme callback. Le rejet humain dans le graphe. Les personas IA avec friction structurelle. L'humain n'est pas hors de la boucle — il est la boucle.

---

Qui pense ?

L'école full auto dit : l'IA pense, l'humain valide. À l'échelle, la capacité de jugement se concentre chez ceux qui configurent les agents — une élite technique. Les autres deviennent opérateurs de systèmes qu'ils ne comprennent pas. On a déjà vu ce film avec l'industrialisation.

L'école humain augmenté dit : l'humain pense mieux grâce à l'IA. La capacité de jugement se distribue. Mais ça demande un effort — apprendre à orchestrer la friction, accepter la lenteur, refuser le confort du "l'agent gère".

Le problème politique : l'école 1 scale, l'école 2 non. L'automatisation se vend, se mesure, se déploie. L'augmentation demande une posture individuelle, une discipline, presque une éthique. Plus dur à industrialiser.

---

Le danger silencieux : si l'école 1 gagne par défaut, les produits sortiront, les KPI seront verts. Mais la compréhension de pourquoi les décisions ont été prises s'érodera. Le jour où il faudra pivoter, corriger une erreur systémique — plus personne ne comprendra le système assez profondément pour le faire.

C'est le même argument que P0 appliqué à la cognition : une dépendance cognitive est un pari sur la roadmap de quelqu'un d'autre.

---

Ne pas en faire une opposition morale. Les gens qui font du full auto répondent à une pression réelle — livrer, scaler, survivre. Le débat sera plus productif formulé comme un choix de design avec des conséquences mesurables, pas comme un camp du bien contre un camp du mal.

Le miroir déforme aussi quand la chaîne est longue.

Chaque erreur non détectée se propage à l'étape suivante comme une prémisse valide. L'étape 3 ne sait pas que l'étape 2 a produit quelque chose de faux. Elle construit dessus. Un calcul simple : un workflow de 10 étapes avec des agents fiables à 94% — la fiabilité globale tombe à 54% (0.94¹⁰). Près d'un échec sur deux. Ce n'est pas une hypothèse — c'est de l'arithmétique composée.

Le pire : la cascade est silencieuse. L'erreur initiale, petite, est amplifiée à chaque relais. Le résultat final a l'air correct. Il ne l'est pas.

---

L'aveu enterprise.

Salesforce, Agentforce, 1,5 million de conversations, décembre 2025 : les LLMs omettent des instructions dès qu'on dépasse huit directives. Vivint, 2 millions de clients, découvre que les enquêtes de satisfaction ne partent plus — aléatoirement. Solution : des déclencheurs déterministes pour ce qui ne doit pas être oublié.

Côté recherche : Cemri et al., 2025 ont analysé 1642 traces d'exécution sur 7 frameworks multi-agents (dont ChatDev). 14 modes de défaillance identifiés — problèmes de conception (41.8%), désalignement inter-agents (36.9%), vérification des tâches (21.3%).

Le multi-agent sans gouvernance structurelle aggrave la fiabilité plutôt qu'il ne l'améliore.

---

L'intervention juste, pas l'intervention constante.

Résultat contre-intuitif (Huang et al., ICML 2025) : dans les systèmes multi-agents avec des agents défaillants, la structure hiérarchique — un orchestrateur central coordonnant des agents spécialisés — chute de 5,5%. Les topologies plates : 10,5% et 23,7%. L'orchestrateur central est l'architecture la plus robuste.

Intervention ciblée aux points critiques : la fiabilité passe de 85-92% à 95-99%. Supervision constante : dégrade la scalabilité sans apport proportionnel.

Un PO qui intervient chirurgicalement sur le cadre produit plus qu'un PO qui relit chaque sortie.

---

La limite à gouverner n'est pas l'IA — c'est la longueur de la chaîne entre deux regards humains.

Ce qui doit être déterministe : la structure, le cadre, les points de contrôle. Ce qui peut rester stochastique : le travail de chaque agent à l'intérieur de ce cadre.

On ne gouverne pas l'IA en contrôlant chaque sortie. On la gouverne en structurant ce qui ne doit pas dériver.