Driss Amiroune

Posted on May 20

La méthode hybride : quand Claude.ai supervise Claude Code

#ai #claude #agents #productivity

La méthode hybride est une organisation du travail dans laquelle l'utilisateur reste dans Claude.ai, l'interface chat conversationnelle, pendant que les tâches d'ingénierie longues sont déléguées en arrière-plan à Claude Code, l'agent en ligne de commande autonome. La délégation est invisible : c'est le chat lui-même qui rédige le prompt d'ingénierie professionnel adapté à la situation, lance l'exécuteur, supervise son travail à travers le filesystem local et l'historique git, et rapporte le résultat à l'utilisateur dans la même conversation. L'utilisateur n'ouvre jamais de terminal, ne tape jamais de prompt pour Claude Code, ne quitte jamais le chat.

Le nom suit l'analogie automobile. Une voiture hybride coordonne deux moteurs aux forces complémentaires — un moteur thermique pour la charge soutenue, un moteur électrique pour la réponse instantanée — à travers une transmission qui sélectionne lequel est engagé à chaque instant. Claude.ai et Claude Code correspondent à ces deux moteurs structurellement. Le conducteur appuie sur une pédale ; le système gère l'allocation en dessous.

J'utilise cette méthode quotidiennement sur des projets en production depuis le 21 avril 2026. Après un mois d'usage mesuré, c'est l'organisation d'ingénierie assistée par IA la plus utile que j'ai rencontrée : gain en débit d'environ un ordre de grandeur sur l'usage mono-agent, qualité d'output supérieure, et coût de context-switching proche de zéro parce que l'utilisateur ne quitte jamais l'interface conversationnelle. Au 20 mai 2026, une revue de la littérature publique sur l'écosystème Claude indique que cet assemblage précis n'est documenté nulle part — les pièces individuelles sont publiques, la combinaison semble nouvelle. C'est ce qui motive cet article.

1. Le contexte qui rend cette méthode nécessaire

Claude.ai et Claude Code couvrent des régimes de travail différents. Claude.ai est une interface conversationnelle — web ou desktop — adaptée aux décisions, à l'exploration, au travail documentaire, et aux appels d'outils courts via les serveurs Model Context Protocol (MCP). Claude Code est un agent en ligne de commande adapté au travail d'ingénierie autonome sur plusieurs heures : lecture de codebases, exécution de tests, refactos, commits.

La plupart des développeurs utilisent les deux outils séparément. Ils sollicitent le chat pour réfléchir et décider, et Claude Code pour construire. Cette séparation a un coût caché. Quand le travail à effectuer dépasse ce que le chat peut faire confortablement — une refonte multi-fichiers, un audit suivi de corrections structurées, un sprint de plusieurs heures avec tests et releases taguées — le développeur devient l'orchestrateur entre les deux interfaces. Il tient le plan dans sa tête, bascule entre les contextes, re-prompte toutes les quinze minutes, supervise chaque étape. Trois heures de travail de Claude Code coûtent trois heures d'attention du développeur.

Pour les utilisateurs sans une pratique solide d'ingénierie de prompts, la situation est pire. Les prompts qu'ils peuvent écrire pour Claude Code n'extraient qu'une fraction de ce que l'outil peut produire en mode autonome. Le mode agentique de Claude Code attend un brief structuré que la plupart des utilisateurs ne savent pas rédiger : phases explicites, critères d'acceptation, règles opérationnelles, protocole d'escalade. Sans ce brief, l'outil sous-performe ou dérive.

La méthode hybride résout ces deux problèmes par le même mécanisme : elle délègue au système à la fois la rédaction du prompt d'ingénierie ET l'exécution, tout en maintenant l'utilisateur dans son unique environnement conversationnel. Le chat traduit l'intention exprimée en langage naturel par l'utilisateur en un brief d'ingénierie structuré, le passe à l'exécuteur, supervise le travail, et retourne un résumé en langage naturel. La contribution de l'utilisateur est restreinte à exprimer l'intention, relire le plan, et valider le résultat — ce qui est précisément le travail que seul l'utilisateur peut faire.

2. Principe et description de la méthode

La méthode hybride fait tourner deux agents Claude distincts sur le même projet — un conversationnel, un exécuteur — et les traite comme deux moteurs fonctionnellement distincts coordonnés par une petite couche de transmission.

Le moteur conversationnel est Claude.ai. C'est l'interface que l'utilisateur utilise déjà pour réfléchir, demander, décider, rédiger. Il excelle dans la conversation, dans la désambiguïsation d'intention, dans le maintien d'un contexte long partagé avec l'utilisateur, dans les appels d'outils MCP unitaires. Il ne soutient pas des heures de travail autonome sur le filesystem. Ce n'est pas ce pour quoi le chat est conçu.

Le moteur exécuteur est Claude Code, l'agent en ligne de commande fourni par Anthropic. Une fois doté d'un prompt structuré et d'un profil de permissions, il opère en autonomie : il explore le repository, planifie, écrit, teste, commit, corrige, itère, jusqu'à ce que les critères d'acceptation du prompt soient atteints ou que le travail soit bloqué. Il ne demande pas de tour-par-tour humain pendant l'exécution. Il est mal adapté aux échanges conversationnels courts.

Aucun des deux agents pris seul ne couvre toute la plage de travail d'un projet logiciel sérieux. La méthode hybride fait tourner les deux, avec le moteur conversationnel agissant comme superviseur de l'exécuteur. Quand l'utilisateur décrit un objectif qui dépasse la capacité de la voie conversationnelle, le chat traduit cet objectif en un prompt d'ingénierie structuré pour l'exécuteur, lance l'exécuteur comme processus en arrière-plan, sonde sa progression périodiquement, intervient si nécessaire, et rapporte le résultat à l'utilisateur en langage naturel. L'utilisateur n'ouvre jamais de terminal. L'utilisateur n'écrit jamais de prompt pour Claude Code. L'utilisateur reste dans le chat.

L'analogie automobile donne son nom à la méthode et clarifie sa logique sous-jacente. Une voiture hybride fait tourner deux moteurs simultanément : un moteur à combustion interne qui soutient le travail longue distance sous forte charge mais a un coût de démarrage mesurable, et un moteur électrique qui démarre instantanément et gère le travail à faible charge et courte distance de façon efficace. Un moteur thermique démarré pour un trajet court gaspille plus d'énergie en démarrage que le trajet n'en demande. Un moteur électrique sollicité pour un long-courrier devient le facteur limitant. Une voiture hybride ne choisit pas. Elle fait tourner les deux, et un système de transmission sélectionne le moteur engagé à un moment donné en fonction des conditions du trajet. Le conducteur appuie sur une pédale ; le système gère l'allocation en dessous.

Claude.ai et Claude Code correspondent à ces deux moteurs structurellement, et non figurativement. Claude.ai a les propriétés du moteur électrique : démarrage instantané parce que l'utilisateur est déjà dans la session de chat, excellente maniabilité à faible charge, transitions fluides, et l'interface utilisateur dans laquelle vivent les décisions. Claude Code a les propriétés du moteur thermique : un coût de démarrage à froid mesurable (typiquement 5 à 15 secondes pendant qu'il charge le fichier de mémoire du projet et explore le repository), une performance autonome soutenue une fois lancé, un accès natif aux systèmes de fichiers et au contrôle de version. L'asymétrie des forces et des coûts entre les deux moteurs est ce qui rend leur coordination utile.

Propriété	Claude.ai (moteur conversationnel)	Claude Code (moteur exécuteur)
Coût de démarrage	Négligeable (session de chat existante)	5 à 15 secondes (contexte froid, exploration du repo)
Travail autonome soutenu	Borné par tour conversationnel	Multi-heures
Rétention de contexte utilisateur	Excellente (mémoire chat longue)	Par session, reset entre les runs
Opérations à l'échelle du repository	Lent via MCP, borné par les appels d'outils	Natif, non borné
Qualité conversationnelle	Optimisé pour	Pas son objet
Coût par unité de travail utile	Plus bas pour les tâches courtes	Plus bas pour les tâches longues

Utilisé seul, chaque moteur a un régime où il domine et un régime où il est le mauvais choix. Utilisés ensemble, avec une politique d'allocation explicite et une petite couche de transmission, ils couvrent l'enveloppe opérationnelle complète d'un projet logiciel réel.

3. Architecture technique

La couche de transmission entre les deux moteurs ne repose sur aucun protocole de communication custom. Elle est construite à partir de trois composants qui existent déjà sur n'importe quelle machine de développement standard : le filesystem local, le système de contrôle de version, et un petit serveur MCP qui expose un outil Bash au moteur conversationnel.

Le serveur MCP est la seule pièce qui doit être installée et configurée. Environ deux cents lignes de Python utilisant le SDK MCP Python officiel d'Anthropic suffisent. Plusieurs implémentations communautaires sont également disponibles. Le serveur expose un outil — appelons-le bash_local — qui permet au moteur conversationnel d'exécuter des commandes shell sur la machine hôte. Cet outil est le pont entre les deux moteurs : le moteur conversationnel l'utilise pour lancer l'exécuteur comme subprocess en arrière-plan, puis plus tard pour sonder les fichiers de status et lire le git log.

La commande de lancement elle-même est une invocation nohup standard qui spawn Claude Code avec un prompt d'ingénierie de plusieurs pages en entrée standard :

nohup bash -c 'echo "$PROMPT" | claude -p \
  --model opus-4-7 --effort xhigh \
  --dangerously-skip-permissions \
  > /tmp/sprint_run.log 2>&1' &

Une fois l'exécuteur lancé, les deux moteurs communiquent exclusivement via des artefacts écrits dans le filesystem. L'exécuteur maintient un fichier de progression (typiquement à /tmp/sprint_progress.md) qui reflète son état courant sous forme lisible. S'il est bloqué, il écrit un fichier de blocage (/tmp/sprint_blocked.md) et passe à la sous-tâche suivante. Les commits sont poussés vers le repository git au fur et à mesure que le travail est complété. Le moteur conversationnel, à des intervalles de cinq à dix minutes, sonde ces trois sources — le fichier de progression, l'existence d'un fichier de blocage, les dernières entrées de git log — via son outil bash_local. Pas de callbacks, pas de streaming, pas de connexion WebSocket. Le filesystem est le canal ; git est l'horloge distribuée.

Un composant subtil mais important de l'architecture est le fichier de mémoire projet conventionnellement nommé CLAUDE.md. Anthropic a câblé dans Claude Code la convention selon laquelle tout fichier portant ce nom à la racine du dossier courant est automatiquement chargé dans le contexte au démarrage de chaque session. Il sert de mémoire projet persistante de l'exécuteur.

Dans la méthode hybride, le moteur conversationnel lit aussi ce même fichier — explicitement, via son outil bash_local, au début de toute conversation liée au projet. Les deux moteurs commencent donc avec la même compréhension partagée du projet : son identité, son état actuel, ses conventions architecturales, les règles strictes gouvernant ce que chaque moteur a le droit et l'interdiction de faire, la liste des lectures obligatoires, le protocole d'escalade. Cette mémoire partagée est ce qui rend la transmission fiable. Quand le moteur conversationnel écrit un prompt de sprint pour l'exécuteur, il n'a pas besoin de répéter aucun contexte projet — l'exécuteur l'a déjà depuis CLAUDE.md. Le prompt peut se concentrer entièrement sur les spécificités du sprint courant : quelles sous-tâches, avec quels critères d'acceptation, dans quel ordre, avec quelles règles opérationnelles. Un CLAUDE.md bien maintenu est l'artefact le plus sous-évalué de cette configuration.

Schématiquement, le flux de données est le suivant :

Utilisateur (langage naturel)
   │
   ▼
Claude.ai (moteur conversationnel)
   │   utilise l'outil MCP : bash_local
   │   lance : nohup claude -p ... &
   ▼
Claude Code (moteur exécuteur, subprocess background)
   │   lit CLAUDE.md automatiquement
   │   lit le prompt d'ingénierie depuis stdin
   │   travaille en autonomie 1 à 3 heures
   │   commit et push de façon incrémentale
   ▼
Repository git (seule source de vérité)
   │   Claude.ai sonde toutes les 5 à 10 minutes :
   │     - dernières entrées de git log
   │     - /tmp/sprint_progress.md
   │     - /tmp/sprint_blocked.md (si présent)
   ▼
Claude.ai rapporte à l'utilisateur en langage naturel

Rien dans cette architecture ne nécessite de service cloud, de protocole de transport custom, ou de kit de développement logiciel au-delà de ce que les deux produits Claude fournissent déjà.

4. La matrice d'allocation des tâches

La couche de transmission décrite à la section précédente n'est économiquement rationnelle que s'il existe une politique claire sur quel moteur est engagé pour quel type de travail. La mauvaise politique gaspille soit la réactivité du moteur conversationnel, soit l'autonomie de l'exécuteur.

La matrice ci-dessous est la politique sur laquelle je me suis arrêté après un mois de mesure en usage de production quotidien. Elle est empirique plutôt que théorique : chaque ligne reflète un régime dans lequel un moteur est mesurablement plus efficace que l'autre.

Profil de tâche	Moteur engagé	Justification
Moins de 5 minutes, ciblée (fix une ligne, UPDATE SQL ciblé, redémarrage de service)	Conversationnel	Le coût de démarrage à froid de l'exécuteur dépasse le travail lui-même. Engager le chat via ses outils MCP existants est plus rapide en bout en bout.
5 à 15 minutes, multi-fichiers, contexte conversationnel déjà chargé	Conversationnel	Le contexte est chaud. Le re-charger dans une session exécuteur fraîche coûterait plus cher que d'exécuter directement via les appels d'outils MCP.
5 à 15 minutes, multi-fichiers, contexte froid	Exécuteur (foreground)	Contexte froid signifie que l'exécuteur est plus rapide que de réexpliquer tout au chat via MCP.
Plus de 15 minutes, ou exploration ouverte	Exécuteur (background)	Lancé en `nohup claude -p ... &`. Le chat sonde les fichiers de progression et le git log. L'utilisateur est libre pour d'autres travaux.
Refacto multi-modules, changements transverses	Exécuteur	Grep, read et write natifs sur le repository sans aller-retour MCP.
Document, article, ou synthèse stratégique	Conversationnel	La structure narrative est conversationnelle. L'exécuteur traite la narration comme une tâche annexe ; le chat la traite comme son mode principal.
Audit, planification, décision	Conversationnel, parfois assisté par une passe exécuteur en lecture seule pour la collecte de faits	Le chat tient le contexte stratégique. Si des faits spécifiques sur la codebase sont nécessaires, il lance d'abord une passe exécuteur en lecture seule, puis raisonne sur le résultat.

L'asymétrie de coût qui guide cette matrice est empirique. Une session Claude Code à froid a un temps de démarrage mesurable d'environ 5 à 15 secondes avant qu'un travail utile ne se produise, plus le temps nécessaire au chargement de CLAUDE.md et à l'exploration des répertoires pertinents. Pour une tâche dont le travail utile total est de 30 secondes, ce démarrage domine le temps écoulé total. Pour une tâche dont le travail utile est de 30 minutes, il est négligeable. La matrice ne fait que tracer le point de bascule.

Cette politique d'allocation est le contenu intellectuel substantiel de la méthode hybride. L'infrastructure de transmission — un outil Bash exposé via MCP, des fichiers de status dans un emplacement connu, git comme source de vérité — est mécanique et évidente une fois décrite. La discipline de savoir quand engager quel moteur est ce qui rend la configuration économiquement rationnelle plutôt que gaspilleuse, et c'est ce qui ne peut pas être improvisé. Elle se construit par la mesure.

5. Déploiement : local ou serveur

La méthode hybride est neutre à l'emplacement de l'exécuteur. Le même pattern fonctionne sans modification dans deux configurations.

Dans la configuration locale, l'exécuteur tourne comme subprocess sur la propre machine du développeur. Un serveur MCP local (un petit programme Python installé sur le laptop du développeur) expose l'outil Bash que le moteur conversationnel utilise pour lancer et superviser. C'est la configuration la plus appropriée pour le développement personnel sur du matériel personnel. Aucun sandboxing n'est nécessaire car le développeur travaille sur ses propres fichiers. C'est la configuration dans laquelle l'illustration discutée à la section 7 a eu lieu.

Dans la configuration serveur, l'exécuteur tourne sur un serveur Linux sous un utilisateur Unix dédié de faible privilège, isolé du reste du système. Le serveur MCP fournit un accès à distance — typiquement via SSH — permettant au moteur conversationnel qui tourne sur le device de l'utilisateur de lancer et superviser l'exécuteur à distance. C'est la configuration la plus appropriée pour du travail de production continu sur des systèmes dont l'état doit persister entre les sessions utilisateur. C'est la configuration que j'utilise depuis le 21 avril 2026 sur plusieurs projets.

La couche de transmission — filesystem, git, pont MCP — ne se soucie pas d'où l'exécuteur vit. Cette neutralité de déploiement est l'une des propriétés qui distinguent la méthode hybride des alternatives discutées à la section 9 : Cowork est lié à une machine virtuelle managée, AWS AgentCore est lié à l'infrastructure AWS, la délégation Slack est liée au cloud d'Anthropic. La méthode hybride n'est liée à rien au-delà de MCP standard. Elle tourne là où l'utilisateur choisit de la faire tourner.

Pour un agent opérant sur la machine d'un utilisateur non-développeur — par exemple, dans le contexte d'un produit grand public qui expose les capacités de Claude Code à des utilisateurs sans formation en ingénierie — l'outil Bash doit être soigneusement sandboxé. C'est une autre conversation et ce n'est pas le sujet de cet article.

6. Application en pratique

L'expérience côté utilisateur de la méthode hybride est directe. L'utilisateur ouvre Claude.ai, formule une intention en langage naturel, et le moteur conversationnel gère le reste.

Une session typique commence par la description d'un objectif. « L'audit récent a identifié treize findings sur le projet. Huit sont critical ou high. Peut-on les fermer ce soir en deux ou trois releases taguées ? » Le moteur conversationnel lit le rapport d'audit via son outil MCP bash_local, lit l'historique récent des releases du projet et le CLAUDE.md, et propose un plan dans la même langue conversationnelle : quels findings vont dans quelle release, avec quels critères d'acceptation, lesquels reporter avec justification documentée. L'utilisateur relit le plan dans le chat et approuve.

Le moteur conversationnel rédige ensuite un prompt d'ingénierie de plusieurs pages pour l'exécuteur. Ce prompt est structuré en quatre phases — lire, planifier, implémenter, vérifier — avec des critères d'acceptation explicites par sous-tâche, avec des règles opérationnelles strictes attachées (pas de force-push, tests requis avant chaque commit, mises à jour des fichiers de status obligatoires), et avec un protocole d'escalade spécifiant ce que l'exécuteur doit faire s'il est bloqué plus de trente minutes sur une sous-tâche unique. L'utilisateur ne lit pas ce prompt. L'utilisateur fait confiance au rédacteur.

Le lancement est invisible : le moteur conversationnel appelle son outil Bash, exécute l'invocation nohup ... claude -p ... &, et retourne vers l'utilisateur avec la confirmation que le sprint tourne. L'utilisateur ferme le laptop ou passe à d'autres travaux. L'exécuteur est maintenant seul avec son prompt, son CLAUDE.md, et la codebase.

Pendant les heures suivantes, l'utilisateur est hors de la boucle. Le moteur conversationnel sonde la progression toutes les cinq à dix minutes. Si tout apparaît normal, aucune action n'est prise. Si une régression apparaît dans le flux de commits, le moteur conversationnel investigue : il lit les diffs pertinents, évalue si la régression est réelle ou apparente, et soit patche sur place, soit rollback. Quand le travail est complet, le moteur conversationnel produit un résumé dans la langue préférée de l'utilisateur, avec la liste des commits, les findings fermés, les éléments reportés avec leur justification, tout incident survenu et comment il a été géré, et un pointeur vers où les artefacts peuvent être relus.

À aucun moment de cette session l'utilisateur n'ouvre un terminal, ne tape un prompt pour Claude Code, ou ne quitte l'interface Claude.ai. L'utilisateur exprime son intention en langage naturel au début, relit le plan proposé, valide le résultat final. L'exécution est déléguée de bout en bout.

Cette division du travail est l'expression opérationnelle d'un principe plus large : que le rôle de l'utilisateur dans l'ingénierie logicielle avec assistance IA devrait être de décider et de valider, et le rôle de l'IA devrait être d'exécuter. La méthode hybride rend ce principe implémentable en pratique, sur des projets réels, à l'échelle à laquelle du software sérieux est construit.

7. Illustration : un sprint multi-releases

Pour rendre les sections précédentes concrètes, cette section décrit une application spécifique de la méthode. Le cas est représentatif plutôt qu'exceptionnel. L'usage continu de la méthode sur plusieurs projets produit des résultats similaires ; ce sprint particulier est simplement assez compact pour être résumé en une seule section.

Le contexte : un produit desktop macOS actuellement en pré-release, que je ne nommerai pas ici puisque le produit est sous embargo jusqu'à son lancement public. L'état au début du sprint était la version 1.0.7.1, livrée quelques jours plus tôt. Un audit externe du code, lui-même effectué comme une session Claude Code en mode xhigh-effort contre un checkout propre, avait produit un rapport de treize findings : un trou de sécurité critique, quatre éléments de priorité haute, le reste medium et low. L'objectif du sprint était de fermer autant de findings que possible et de livrer le travail résultant comme des releases taguées documentées par changelogs.

Le moteur conversationnel a planifié trois releases. La version 1.0.8 fermerait le finding sécurité critique et trois des quatre éléments high-priority, plus une amélioration de dashboard planifiée. La version 1.0.9 ajouterait un ensemble d'endpoints HTTP manquants. La version 1.0.10 archiverait du code mort identifié par l'audit et finirait les cleanups low-priority.

Le résultat, mesuré à la fin du sprint :

onze commits poussés sur main, tous signés
huit des treize findings fermés, cinq reportés avec justification documentée
suite de tests étendue de 106 à 125 tests, tous passants
trois releases taguées : 1.0.8, 1.0.9, 1.0.10
un installeur .pkg buildé et vérifié sur la machine du développeur
aucun coût API supplémentaire — dans cette configuration, Claude Code est authentifié via OAuth contre mon abonnement Claude payant (plans Pro/Max, qui couvrent à la fois l'usage interactif de Claude.ai et celui de Claude Code dans un forfait mensuel unique) ; la consommation du sprint a tiré sur le quota de cet abonnement, pas sur un compte API facturé au token
environ trente minutes de temps de saisie humaine, distribuées entre planification au début et review à la fin

Un incident opérationnel s'est produit pendant le sprint et mérite d'être documenté parce que la réponse illustre le pattern de supervision. Une opération de cleanup a déplacé un répertoire src/wrappers/ vers src/legacy/wrappers/. À l'intérieur du scope de travail de l'exécuteur, c'était correct : les imports étaient mis à jour, la suite de tests passait, le commit était propre. En dehors du scope de l'exécuteur, sur la machine personnelle du développeur, trois entrées d'une configuration de tests hybrides locale pointaient dans src/wrappers/ et se sont silencieusement cassées quand les fichiers ont bougé sur le disque. Le produit lui-même n'a pas été affecté (l'application installée est auto-suffisante), mais l'environnement local du développeur l'était. Le moteur conversationnel, en sondant le flux de commits, a reconnu l'implication pour la configuration locale qui avait été chargée comme contexte plus tôt, a patché la configuration avec un sed d'une ligne, a sauvegardé la version précédente, et a noté l'incident dans le fichier de progression.

De l'incident, une nouvelle règle opérationnelle a été dérivée et ajoutée au CLAUDE.md du projet : l'exécuteur produit des artefacts installables (fichiers .pkg) et ne modifie jamais la working copy ou la configuration personnelle du développeur. Les sprints futurs travaillent sur des branches dédiées ou dans des clones temporaires. Cette règle s'applique maintenant à chaque session ultérieure.

L'illustration n'est pas un résultat remarquable ; c'est un résultat représentatif. Ce qu'elle démontre, c'est que la méthode produit des outputs mesurés qui sont compétitifs en qualité avec ce qu'une petite équipe d'ingénieurs produirait sur une durée similaire, avec un humain superviseur engagé pour des dizaines de minutes plutôt que plusieurs heures.

8. Ce que la méthode change pour les ingénieurs seniors et pour les utilisateurs sans formation en ingénierie

La méthode hybride adresse deux contraintes distinctes qui ont historiquement limité ce qu'un individu peut produire avec assistance IA, selon le niveau de formation en ingénierie de l'individu.

Pour les ingénieurs seniors, la contrainte persistante avec les outils IA mono-agent est l'attention plutôt que la capacité. L'outil peut écrire du code plus vite que l'ingénieur ne peut taper, mais l'ingénieur doit toujours tenir le plan, superviser chaque étape, reviewer chaque commit, décider quoi faire quand l'outil se trompe. Le travail total produit par unité de temps de l'ingénieur est borné par sa capacité à rester présent dans la boucle d'exécution. La méthode hybride déplace l'attention de l'ingénieur vers une autre voie. Le travail stratégique — architecture, scope, arbitrages, validation — reste avec l'ingénieur, mais il est tenu en conversation avec le moteur conversationnel, qui peut lire la codebase et faire surfacer des faits spécifiques à la demande. Le travail d'exécution bouge vers l'exécuteur sous la supervision du moteur conversationnel. Le travail de review ligne par ligne bouge aussi vers le moteur conversationnel, qui lit le flux de commits au fur et à mesure qu'il arrive et signale les anomalies. L'attention résiduelle de l'ingénieur se concentre sur le jugement et la validation, qui sont le travail que seul l'ingénieur peut faire. Un ingénieur senior utilisant cette méthode peut crédiblement maintenir plusieurs sprints actifs en parallèle, parce qu'aucun ne demande d'attention continue pendant l'exécution.

Pour les utilisateurs sans formation en ingénierie logicielle — professionnels d'autres domaines, hobbyistes techniques, quiconque dont l'expertise principale est ailleurs — la contrainte persistante avec les outils IA mono-agent a été l'expertise en ingénierie de prompts. Écrire le prompt structuré de plusieurs pages dont Claude Code a besoin pour produire un output autonome de haute qualité est en soi un craft qui demande des semaines ou des mois de jugement d'ingénierie accumulé. La plupart des utilisateurs sans cette formation ne l'ont pas et ne l'auront jamais. La méthode hybride supprime cette exigence. Le moteur conversationnel écrit le prompt d'ingénierie, en s'appuyant sur son long contexte conversationnel avec l'utilisateur et sur le CLAUDE.md du projet. L'utilisateur exprime son intention en langage naturel, dans sa propre langue ; le prompt rigoureux est produit pour lui. L'utilisateur apporte la connaissance du domaine, le jugement sur ce que le système devrait faire, la validation des outputs dans le contexte du monde réel que l'utilisateur seul comprend. Les agents IA apportent la rigueur d'ingénierie. L'asymétrie qui excluait précédemment les non-ingénieurs de la construction de software sérieux est réduite.

Les deux effets sont complémentaires. La même méthode qui libère l'attention de l'ingénieur senior pour du travail à plus haute valeur ajoutée ouvre aussi la pratique du développement logiciel à des utilisateurs dont la barrière à l'entrée précédente était une expertise en ingénierie de prompts qu'ils ne possédaient pas. Aucun des deux effets n'était l'objectif de design explicite ; les deux sont des propriétés qui émergent du choix architectural de séparer la voie conversationnelle de la voie d'exécution.

9. Pourquoi cet assemblage n'apparaît pas documenté ailleurs

Une revue de la littérature publique sur l'écosystème Claude au 20 mai 2026 a identifié plusieurs patterns adjacents. Aucun d'eux n'est le même que la méthode hybride décrite ici.

Pattern	Description brève	En quoi il diffère
Operator / orchestrator pattern (MindStudio, documentation Anthropic)	Une session Claude Code orchestre d'autres subagents Claude Code via le Task tool natif	Interne à Claude Code. Pas de superviseur conversationnel devant.
Claude Agent SDK (Anthropic, officiel)	Un wrapper Python qui spawn Claude Code comme subprocess et le pilote programmatiquement	Orchestration programmatique. Pas d'interface langage naturel pour l'utilisateur humain.
Cowork (Anthropic, produit enterprise)	Claude Desktop spawn Claude dans une machine virtuelle Linux managée sandboxée pour du travail asynchrone	Runtime managé cloud. Visible à l'utilisateur comme une surface produit distincte. Pas un chat qui délègue en dessous.
Délégation Slack (Anthropic)	`@Claude` dans un thread Slack lance une session Claude Code sur l'infrastructure Anthropic	Managée cloud. Visible via la mention explicite. Pas portable entre organisations.
Onglet Code + git worktrees (Claude Desktop, guides tiers)	L'app desktop expose une interface utilisateur pour spawn des Claude Code parallèles en worktrees	Lancée explicitement par l'utilisateur humain via une UI. Pas d'agent superviseur devant l'exécuteur.
AWS AgentCore avec protocole A2A (tiers)	Un main agent et un code agent communiquent via le protocole A2A sur AWS AgentCore	Basée cloud. Asynchrone via le protocole A2A. Pas locale ; pas basée MCP.

La méthode hybride se différencie de ces patterns adjacents sur quatre propriétés simultanément. Premièrement, le superviseur est un chat conversationnel — pas un script, pas un morceau de code, pas une interface utilisateur séparée — et l'utilisateur n'interagit qu'avec ce chat. Deuxièmement, le transport entre le superviseur et l'exécuteur est MCP standard, pas un wrapper Python ou un protocole custom ; n'importe quel client LLM supportant les outils MCP pourrait jouer le rôle de superviseur. Troisièmement, l'exécuteur est invisible à l'utilisateur ; Claude Code est un sous-traitant du chat, jamais surfacé explicitement. Quatrièmement, la communication entre les deux moteurs est asynchrone et passe par le filesystem local et un repository git, qui sont les mêmes artefacts que les équipes humaines utilisent déjà pour le développement logiciel distribué.

Les pièces individuelles de cet assemblage existent toutes publiquement et ont été documentées séparément. Aucun des patterns documentés ne combine les quatre propriétés. Cette combinaison est ce que je n'ai pas trouvé écrit, et ce qui motive l'écriture de cet article.

10. Comment implémenter la méthode

La méthode hybride nécessite quatre pièces d'infrastructure et trois disciplines opérationnelles. L'infrastructure peut être assemblée en un après-midi. Les disciplines se développent sur plusieurs semaines de pratique.

L'infrastructure consiste en :

Un abonnement Claude.ai avec support MCP (Pro ou Max). C'est le moteur conversationnel.
Un serveur MCP local qui expose un outil Bash et quelques utilitaires fichier au moteur conversationnel. Environ deux cents lignes de Python écrites contre le SDK MCP Python officiel d'Anthropic, ou l'une des implémentations communautaires. Aucun sandboxing n'est requis pour le développement personnel sur du matériel personnel. Pour un agent opérant sur la machine d'un utilisateur non-développeur, un sandboxing soigneux est non négociable.
Claude Code installé localement (npm install -g @anthropic-ai/claude-code ou via Homebrew sur macOS) avec un login unique. C'est le moteur exécuteur.
Un fichier CLAUDE.md bien maintenu à la racine du repository projet. C'est la mémoire partagée. La première version prend environ une heure à écrire. Le fichier est raffiné sur plusieurs semaines d'usage.

Les disciplines consistent en :

Une matrice d'allocation des tâches documentée. La version en section 4 de cet article est la mienne ; la version d'un implémenteur peut différer dans les détails. Ce qui importe est que la matrice soit écrite, appliquée de façon consistante, et mise à jour sur la base de mesures.
Une pratique d'ingénierie de prompts pour les prompts de sprint ingénierés que le moteur conversationnel écrit pour l'exécuteur. Quatre phases, critères d'acceptation par sous-tâche, une dizaine de règles opérationnelles strictes, un protocole d'escalade, des conventions de fichiers de status. C'est le moat opérationnel dans la méthode. Elle est développée sur plusieurs semaines d'itération sur de vrais sprints.
La discipline des deux voies. L'utilisateur reste dans le chat. Le moteur conversationnel reste dans la voie de supervision. L'exécuteur reste dans la voie d'exécution. Ces rôles ne se brouillent pas. Une fois que la délégation commence, l'utilisateur n'ouvre pas le terminal.

Pour un déploiement serveur, le serveur MCP local est remplacé par un MCP capable SSH, et l'exécuteur tourne sur le serveur distant sous un utilisateur Unix dédié de faible privilège. Tout le reste est identique.

Le premier sprint exécuté avec la méthode sera plus désordonné que prévu. Le troisième sprint sera plus fluide. Au dixième sprint, la pratique d'ingénierie de prompts se sera stabilisée, la matrice d'allocation reflétera des patterns mesurés plutôt que des suppositions, et le CLAUDE.md aura encodé les leçons opérationnelles que les sprints précédents ont fait surfacer. L'infrastructure paye en retour dès la première session. Les disciplines composent sur des semaines.

Conclusion

La méthode hybride est, dans sa formulation la plus simple, une façon d'utiliser ensemble deux produits Claude existants pour qu'ils couvrent des régimes de travail complémentaires : un moteur conversationnel pour les décisions, le contexte et la supervision ; un moteur exécuteur pour le travail d'ingénierie autonome soutenu. L'utilisateur n'interagit qu'avec le moteur conversationnel. L'exécuteur est un sous-traitant dont le travail est supervisé via des artefacts que l'utilisateur n'a pas besoin de lire.

L'infrastructure est petite. Trois composants — un abonnement chat, un serveur MCP local, Claude Code installé — et un fichier de mémoire partagée à la racine du projet. L'infrastructure ne requiert pas de service cloud, de protocole custom, ou de travail d'ingénierie spécialisé.

Ce qui demande du craft est la discipline opérationnelle qui transforme l'infrastructure en système productif : une politique d'allocation qui engage le bon moteur pour le bon type de travail, une pratique d'ingénierie de prompts qui traduit l'intention conversationnelle en instructions exécuteur structurées, et la séparation simple mais consistante des voies qui maintient chaque moteur dans ce qu'il fait bien.

Ce que la méthode offre, en retour, est un déplacement significatif de ce qu'une seule personne peut produire avec assistance IA. Pour un ingénieur senior, l'attention est libérée pour le travail que seul l'ingénieur peut faire — jugement, validation, scope, correction face au monde réel — pendant que l'exécution bouge vers un exécuteur supervisé. Pour un utilisateur sans formation en ingénierie, la barrière à la participation est abaissée : l'expertise en ingénierie de prompts qui gardait précédemment l'accès au mode autonome de Claude Code est fournie par le moteur conversationnel à la place de l'utilisateur, permettant à l'utilisateur d'apporter sa connaissance du domaine et son jugement sans devoir d'abord acquérir la rigueur d'ingénierie comme prérequis.

J'utilise cette méthode quotidiennement depuis le 21 avril 2026 sur des projets en production. Après un mois d'usage mesuré, je la considère comme l'organisation d'ingénierie assistée par IA la plus utile que j'ai rencontrée. Le gain en débit par rapport à l'usage mono-agent est d'environ un ordre de grandeur ; la qualité de l'output est plus élevée ; le coût cognitif du context-switching entre stratégie et exécution tombe à près de zéro parce que l'utilisateur ne quitte jamais l'interface conversationnelle. Ces affirmations sont faites avec soin et avec des mesures à l'appui, pas comme du marketing.

L'observation plus profonde, au-delà des gains immédiats de productivité, est que la méthode hybride rend implémentable en pratique une division du travail qui est défendue théoriquement depuis quelque temps : l'humain décide et valide, l'IA exécute. Les outils IA de codage mono-agent se sont approchés de cette division mais ne l'ont pas tout à fait livrée, parce que l'humain a dû rester présent dans la boucle d'exécution pour superviser. En dédiant un Claude à la supervision et un autre à l'exécution, avec l'humain attaché uniquement au superviseur, la méthode hybride livre la division sous une forme qui tient sur la durée et la complexité de vrais projets logiciels.

Les pièces de cet assemblage sont toutes publiques. La combinaison, autant que ma recherche dans la littérature publique du 20 mai 2026 l'indique, n'est pas encore documentée ailleurs. Le choix d'écrire cet article a été motivé par cette absence et par le sentiment que la fenêtre pendant laquelle l'écrire est la contribution la plus utile disponible est étroite : les principaux vendeurs IA bougent visiblement vers des versions natives de capacités apparentées, et une feature intégrée dans Claude.ai qui délègue à Claude Code depuis le chat est, selon moi, plausible dans les douze mois. D'ici là, la configuration côté utilisateur décrite ici est disponible pour quiconque veut l'assembler.

Si la description ci-dessus est utile, l'étape la plus précieuse pour un lecteur n'est pas davantage de lecture mais la pratique. Installer les quatre ingrédients, écrire une première version du CLAUDE.md, tenter un petit sprint sous le pattern de supervision, mesurer le résultat, raffiner la matrice d'allocation et le format de prompt sur la base de ce qui a été appris. Le premier sprint sera inégal. Le cinquième ne le sera pas. Le cadre décrit ici est l'échafaudage ; l'usage productif de celui-ci se construit par itération sur du vrai travail.

Les retours, les références à un travail antérieur qui contredirait la revendication d'originalité, les raffinements à la matrice d'allocation, et les comptes-rendus d'autres implémentations sont tous les bienvenus. La méthode est nommée, mais elle n'est pas finie. Des améliorations dans chacune de ces dimensions sont des améliorations à la pratique partagée plutôt qu'à toute implémentation individuelle, et elles sont la façon dont la méthode devient utile au-delà du petit ensemble de praticiens qui ont jusqu'ici convergé vers quelque chose qui lui ressemble.

— Driss Amiroune

DEV Community