Lorsque vous confiez une mission complexe à Claude Code, vous voyez le résultat. Ce que vous ne voyez pas, c’est tout ce qui se passe entre les deux. Un agent qui se dédouble, gère sa propre mémoire, exécute des travaux qui survivent au-delà de la conversation et décide lui-même quand il a terminé. Ce mécanisme n’est pas de la magie. C’est du design.
Le battement de cœur d’un agent
Un agent ne travaille pas de manière linéaire. Il fonctionne en cycle : exécuter une action, examiner le résultat, décider de la suite, recommencer. Ce cycle ne s’arrête pas à un moment fixe, il s’arrête lorsque l’agent décide lui-même que la tâche est achevée. C’est la différence fondamentale avec un script qui s’exécute étape par étape.
Dans la pratique, cela signifie qu’une tâche complexe passe par des dizaines, voire des centaines de cycles avant d’être terminée. Chaque cycle est un moment de décision : qu’est-ce que je viens de voir, que fais-je maintenant ?
Ce qui m’a frappé très tôt : lors de la construction du site web, l’agent développeur travaillait d’abord à l’aveugle. Il écrivait du code, mais ne voyait pas le résultat. J’ai remarqué que la mise en page n’était pas correcte et je devais à chaque fois décrire moi-même ce qui n’allait pas. Après quelques recherches et un tutoriel, j’ai trouvé la solution : installer le plugin Playwright MCP et donner explicitement à l’agent les outils pour ouvrir un navigateur et prendre une capture d’écran. Une fois ces outils disponibles, sa façon de travailler a complètement changé. Après chaque étape visuelle, il prenait une capture d’écran, examinait le résultat et décidait s’il pouvait continuer. Comme un designer qui tire une épreuve avant de valider une version.
Cette seule prise de conscience m’a appris quelque chose de plus large : un agent est aussi autonome que les outils que vous lui donnez. Ni plus, ni moins.
Décomposer de grandes tâches sans perdre la vue d’ensemble
Confier une mission complexe d’un seul coup à un seul agent ne fonctionne pas. Non pas parce que le modèle n’en est pas capable, mais parce que l’agent principal perd toute son attention dans les détails. Chaque lecture de fichier, chaque appel API, chaque résultat intermédiaire s’accumule dans sa mémoire de travail.
La solution, ce sont les sous-agents. L’agent principal décompose la tâche en parties et délègue chaque partie à un sous-agent avec son propre contexte vierge. Ce sous-agent exécute sa part, parfois des dizaines d’étapes en profondeur, et ne renvoie que le résultat final. Tout le bruit intermédiaire disparaît. L’agent principal garde la vue d’ensemble sans avoir à voir chaque détail.
Lors de la construction du Campaign Hub, l’agent développeur fonctionnait ainsi. Des sous-agents distincts pour la migration de base de données, la couche API et l’intégration des webhooks. Chacun avec sa propre tâche délimitée. L’agent principal a reçu trois réponses, pas trois cents étapes intermédiaires.
C’est aussi la manière dont vous instruisez un bon collaborateur : donner le contexte, définir le résultat attendu, faire confiance au processus.
Une mémoire qui ne s’engorge pas
Un agent dispose d’une fenêtre de contexte : la quantité d’informations qu’il peut activement contenir. Lors d’une longue session de travail, celle-ci se remplit. Un fichier de code de mille lignes consomme déjà quatre mille tokens. Laissez un agent travailler assez longtemps et il commence à oublier ce qu’il a fait auparavant.
Un agent bien construit compresse automatiquement, en trois couches. La première couche s’exécute silencieusement après chaque étape : les anciens résultats d’outils sont remplacés par un bref résumé. La deuxième couche entre en action lorsque la fenêtre approche de sa limite : l’intégralité de la conversation est écrite sur disque et résumée, après quoi ce résumé remplace l’historique complet. La troisième couche peut être activée vous-même lorsque vous souhaitez libérer de l’espace.
Rien n’est véritablement perdu. Tout est déplacé, pas effacé. L’agent reste efficace parce qu’il ne traîne pas ce qui n’est plus pertinent.
Un travail qui survit au-delà de la conversation
Une conversation se termine. Un bon système de tâches, non. Les tâches sont enregistrées avec leur statut et leurs dépendances : la tâche B ne démarre que lorsque la tâche A est terminée, les tâches C et D s’exécutent en parallèle. Ce système survit à la compression du contexte et aux fermetures de session. Une nouvelle session reprend là où la précédente s’est arrêtée.
De plus, un agent peut exécuter des opérations lentes en arrière-plan tout en travaillant déjà sur l’étape suivante. Lors de la construction du site web, l’agent développeur effectuait des installations en arrière-plan tout en écrivant simultanément des fichiers de configuration. Deux choses à la fois, sans que l’une ne bloque l’autre.
Comment organiser tout cela en pratique
Les mécanismes décrits ci-dessus sont puissants. Mais ils ne fonctionnent que si la couche qui les entoure est bien organisée. Et c’est là que la plupart des implémentations échouent.
Après dix semaines, j’ai construit mon système en cinq couches. Chaque couche a sa propre place, son propre format et sa propre raison d’être.
CLAUDE.md : la constitution
C’est le premier fichier que l’agent lit à chaque session. Il ne contient ni données clients, ni connaissances sur ma méthodologie, ni tâches concrètes. Il contient des règles de comportement : comment je travaille, quels outils j’utilise et quand, comment je résous les conflits, quand je demande confirmation. CLAUDE.md est court et ciblé. Tout ce qui n’y a pas sa place se trouve ailleurs. Un agent qui reçoit un CLAUDE.md trop long perd la vue d’ensemble. Un agent qui reçoit un CLAUDE.md vague improvise.
knowledge/ : connaissances de domaine stables
Tout ce dont l’agent a besoin pour bien fonctionner sur le long terme se trouve dans le dossier knowledge. Profils clients, directives de marque, méthodologies, références API, critères de qualité. Ces connaissances ne changent pas d’une conversation à l’autre.
Les domaines de connaissances actifs sont chacun organisés en trois fichiers. knowledge.md contient les faits confirmés et les modèles, des choses qui ont été testées et qui tiennent la route. hypotheses.md contient des observations qui nécessitent davantage de données, des intuitions pas encore prouvées. rules.md contient des règles appliquées par défaut, dérivées d’hypothèses suffisamment confirmées. Lorsqu’une hypothèse se vérifie trois fois, elle passe dans les règles. Lorsqu’une règle est contredite par de nouvelles informations, elle retourne dans les hypothèses. Ainsi, la connaissance du système évolue avec la pratique.
Cette structure à trois couches est particulièrement précieuse dans les domaines en évolution constante. La stratégie IA en est l’exemple type. Ce qui est une approche éprouvée aujourd’hui peut être dépassé dans six mois par un nouveau modèle, un nouvel outil ou un changement de marché. En marquant d’abord les observations comme hypothèses et en ne les déplaçant vers les règles qu’après une confirmation suffisante, on construit un système de connaissances qui grandit avec la pratique. L’agent ne fait pas confiance trop tôt à ce qui n’est pas encore prouvé et ne s’accroche pas à des règles que la réalité a déjà dépassées.
Dans mon système, c’est le senior-strategist qui jongle activement avec ces trois couches. Chaque fois que le marché évolue, qu’une conversation client apporte de nouveaux éclairages ou qu’une approche est ajustée, c’est cet agent qui évalue ce qui reste valide, ce qui reste une hypothèse et ce qui est suffisamment prouvé pour être appliqué comme règle. Ainsi, la stratégie Rescope reste itérative, alignée sur un secteur qui se réinvente tous les quelques mois.
memory/ : ce qui est conservé d’une conversation à l’autre
Claude Code dispose de deux couches de mémoire. La première est intégrée et invisible : un dossier caché en dehors de votre répertoire de projet que Claude charge automatiquement à chaque session. Vous ne voyez pas ce dossier dans votre éditeur, mais il existe et fonctionne silencieusement en arrière-plan. C’est là que le système stocke notamment vos préférences personnelles et les paramètres de session.
La deuxième couche, vous l’avez construite vous-même. Dans le dossier du projet, nous avons créé un répertoire memory/ avec un MEMORY.md comme index, un seul fichier chargé automatiquement à chaque session et qui renvoie vers des fichiers séparés par catégorie. Pour chaque catégorie, son propre fichier : décisions prises avec le raisonnement derrière, signaux du marché, insights clients, questions ouvertes. Ces fichiers, nous les rédigeons nous-mêmes, après des conversations ou après des tâches achevées. Concis, trente lignes maximum, l’essentiel plus le raisonnement. Pas comme une archive, mais comme une mémoire de travail.
La différence avec la couche intégrée : celle-ci est visible, consultable et composée délibérément. Vous savez exactement ce qu’elle contient et pourquoi.
Credentials : en local, jamais dans le cloud
Tous les mots de passe, clés API et tokens sont stockés dans un seul fichier local : .env. L’agent sait où trouver ce fichier et en extrait les bonnes valeurs lorsqu’il doit appeler un service externe. Ce fichier n’est jamais dans GitHub. Le dépôt contient le code et la structure, mais jamais les clés. Une règle .gitignore garantit que .env est automatiquement exclu. Quiconque clone le code ne peut rien faire avec les systèmes externes sans remplir ses propres credentials. Ainsi, le système reste partageable sans risque de sécurité.
Trois mécanismes qui améliorent le système
La plupart des systèmes grandissent mais ne s’améliorent jamais. Mon système dispose de trois mécanismes d’amélioration intégrés.
knowledge/lessons.md est un journal des erreurs et des corrections. Lorsque l’agent fait quelque chose de travers ou lorsque j’ajuste une approche, cela est consigné avec la date et le contexte. Au début de chaque session, l’agent lit ce fichier. Pas comme une punition, mais comme une mémoire. Faire la même erreur deux fois est le signe qu’il n’y a pas de lessons.md.
knowledge/quality-gates.md contient une checklist concrète par type de livrable. Pour une newsletter, ce sont sept critères, du nombre de mots au HTML responsive. Pour une offre, d’autres critères. Pour un article de blog, trois lectures obligatoires. L’agent parcourt la liste avant de marquer une tâche comme terminée et me confirme quels points ont été vérifiés. Ainsi, je n’ai pas à contrôler moi-même ce que je peux confier au système.
knowledge/daily/ contient un journal quotidien par date. Ce qui a été fait, quelles décisions ont été prises, quels points restent ouverts. Quinze lignes maximum. Lorsqu’il y a plusieurs sessions le même jour, on ajoute au fichier existant, on ne le remplace pas. Il y a donc toujours un aperçu chronologique de ce qui s’est passé, utile pour la continuité et les bilans.
La leçon qui résume tout
La confusion entre ces couches est le problème le plus courant chez les organisations qui veulent prendre l’IA au sérieux. Tout mettre dans un seul prompt. Un seul document qui doit servir à la fois de constitution, de connaissance de domaine et de mémoire. Et ensuite s’étonner que l’agent sache parfois des choses et parfois pas, qu’il fasse deux fois la même erreur, qu’il doive être rebrieffé après chaque conversation.
La réponse n’est presque jamais le modèle. C’est la structure qui l’entoure.
La qualité d’un agent dépend de l’information qu’il reçoit, du moment où il la reçoit et de la structure dans laquelle elle est organisée. Ce n’est pas un défi technique. C’est une question organisationnelle. Et tout comme la gestion des connaissances chez les humains ne fonctionne que s’il y a une structure derrière, elle ne fonctionne en IA que si l’on réfléchit à ce qui va où et pourquoi.
Comment démarrer soi-même ?
C’est la question que pose presque chaque lecteur. Et la réponse honnête : pas en mettant immédiatement en place un environnement de production.
Commencez par une expérience contenue. Choisissez un projet concret, une équipe, un cas d’usage, et développez-le entièrement avant de le déployer plus largement. Non pas comme un proof of concept, mais comme un véritable environnement de travail, en utilisant des sandboxes, des environnements de test séparés de la production, afin de travailler de manière contrôlée sans impact sur le reste de l’organisation.
N’impliquez pas seulement l’IT. Les personnes qui connaissent la logique métier, qui savent à quoi ressemble une exception, qui veillent au ton client, sont tout aussi indispensables que le technicien qui construit le système. Un agent est aussi bon que les connaissances qu’on lui donne, et ces connaissances se trouvent chez vos collaborateurs, pas dans un manuel.
Un bon point de départ est Claude Desktop : installez l’application, donnez accès à un dossier local et commencez petit. Mais passez vite à Claude Code dans VS Code ou un autre éditeur. Là, vous voyez par fichier ce que l’agent modifie, comment il planifie, comment les tâches sont décomposées. Cette visibilité n’est pas un luxe, c’est le moyen le plus rapide de comprendre comment l’orchestration fonctionne en pratique.
Investissez enfin d’abord dans la compréhension. Huit à dix heures de bons tutoriels, avant de dépenser un seul euro en outillage ou en implémentation. Non pas parce que la technologie est compliquée, mais parce que vous l’utiliserez mal si vous ne comprenez pas comment elle fonctionne. Un bon point de départ est cette vidéo de Nick Saraev, qui explique le système calmement et en profondeur. Ce n’est pas un luxe, c’est la condition préalable.