La plupart des gens utilisent encore l’AI comme on utilisait un traitement de texte en 1995 — on ouvre l’app, on tape un prompt, on récupère un output, on le colle ailleurs. Ça marche pour des petits gains de productivité. C’est aussi déjà le frame dépassé.

Le frame qui se compose est différent. Le modèle n’est pas l’assistant ; c’est le cerveau d’un système que vous construisez autour de lui — un système qui porte votre contexte business, vos standards, vos décisions passées, votre façon de travailler. Ce système, c’est l’orchestration. Elle se loge entre vous et le modèle. Le modèle se fait remplacer tous les quelques mois ; l’orchestration non. C’est la seule chose dans cette boucle qui se compose avec vous dans le temps.

Cette pièce, c’est les principes opérationnels de cette couche d’orchestration. Sept. La pratique technique en dessous — comment le système lui-même est construit — vit dans la pièce compagnon, Engineering Practice Boundaries — Une seule barre pour engineers et AI, écrite pour les lecteurs techniques. Vous n’en avez pas besoin pour suivre les sept ci-dessous. Ce sont ce que vous, la personne qui fait tourner l’opération, ajoutez par-dessus une fois acceptez que le modèle est commodity et que le suivant le sera aussi.

L’audience, c’est les opérateurs : founders, intrapreneurs, builders, leaders qui font tourner du vrai travail et commencent à câbler de l’AI dans leur équipe. Les principes sont écrits pour qu’un senior engineer puisse les utiliser aussi — mais le frame est celui de l’opérateur, parce que ce que vous construisez vraiment, c’est une petite organisation d’agents. Quels rôles dans votre équipe restent distinctement humains, et lesquels s’effondrent dans l’orchestration sur les deux prochaines années, c’est décidé par comment vous construisez cette petite organisation. Les principes ci-dessous sont ce qui décide.

1. Le corpus est malléable

Chaque document que vous avez écrit sur votre business — strategy, positioning, principes opérationnels, decision logs, customer research — est une opinion tenue à un moment par un auteur particulier. La vérité est contextuelle. Ce qui était juste il y a six mois peut être faux maintenant.

La couche d’orchestration tient ça en tête en continu. Elle traite votre corpus écrit comme évidence et prior, pas comme vérité. Quand la conversation live contredit ce que vous avez écrit en février, la conversation gagne par défaut ; le corpus se met à jour, jamais l’inverse. La dérive entre l’écrit et le maintenant est détectée activement, surfacée explicitement, et résolue par déprécation ou par réécriture.

Le mode d’échec que ça empêche, c’est celui qui casse chaque “AI knowledge base” que les gens construisent : l’agent cite un document périmé avec assurance, vous agissez dessus, et la citation était juste quand elle a été écrite et fausse au moment où vous l’utilisez. Le job de l’orchestration, c’est de connaître la différence.

2. Écrit, versionné, portable

Si ce n’est pas écrit, ça n’existe pas. Les instructions que vous donnez à vos agents, les corrections que vous leur avez apprises, les templates que vous réutilisez, les règles que vous voulez voir appliquées, les playbooks pour les tâches récurrentes — tout ça vit par écrit, ou ça ne vit nulle part. L’agent ne peut pas lire vos intentions ; il ne peut lire que ce qui est capturé.

Versionné, pas épinglé à un seul laptop. Le skill que vous avez écrit le trimestre dernier doit toujours exister mardi prochain sur n’importe quelle machine sur laquelle vous êtes. La correction que vous avez apprise à l’agent en février doit persister jusqu’en août. Si le système ne marche que sur votre ordinateur d’origine, vous n’avez pas un système — vous avez une habitude personnelle qui disparaît le jour où votre laptop disparaît.

Portable à travers les gens et les machines. Un nouveau membre d’équipe devrait pouvoir reprendre l’orchestration de la même façon qu’il reprendrait un handbook interne bien écrit — pas en s’asseyant à côté de vous pour regarder. C’est le standard qu’une organisation sérieuse applique à ses procédures opérationnelles, et c’est le standard que la couche d’orchestration doit atteindre.

3. La memory est tiered — trois horizons, trois jeux de règles

Le contexte et la memory sont critiques, et ne sont pas plats. Trois buckets, chacun avec sa propre discipline d’écriture et son propre modèle de décroissance. Les confondre, c’est une erreur de catégorie qui surface soit comme du travail perdu, soit comme du conseil périmé.

Court terme, courte vie. Conversation active, tâches en cours, plan courant, raisonnement scratch. Éphémère par design. Effacée au reset de contexte. Jamais la source de vérité de quoi que ce soit.

Moyen terme, malléable, en évolution. Memos projet, tickets en cours, watch-memos avec des dates de revisit explicites, hypothèses sous test, drafts de personas, market reads. La décroissance est attendue et bienvenue — ces documents sont censés changer à mesure que la compréhension s’affine. C’est de la memory de travail, pas de l’archive.

Long terme, stable sur des mois. Doctrines, big goals, principes codifiés, decision registry, matériel d’identité. Lent à écrire, lent à changer, jamais écrasé silencieusement. C’est la couche où vivent les principes engineering, la strategy et la barre opérationnelle.

Promouvoir de l’éphémère vers le long terme — transformer un fil de chat en doctrine — corrompt la doctrine. Démouvoir des faits porteurs vers le chat — ne jamais les écrire — les perd. Chaque tier a sa propre cadence d’écriture et ses propres règles de déprécation. L’orchestration applique dans quel tier vit chaque morceau de contexte.

4. Le système se corrige lui-même

Closed loop. L’orchestration s’observe elle-même, surface les déviations, et propose des raffinements à l’opérateur. Les échecs deviennent des règles. Les frictions deviennent du tooling. Le travail manuel répété devient du pattern codifié.

La cadence est concrète : deux fois, c’est un pattern. La deuxième fois que vous corrigez l’agent sur la même classe d’erreur, cette correction doit tourner sur une règle, un hook, un skill ou une entrée memory — pas sur votre vigilance, pas sur votre espoir de vous en souvenir la prochaine fois. La troisième occurrence se produit parce que le système a été construit pour la prévenir.

L’opérateur décide ce qui est codifié. L’orchestration ne mute jamais silencieusement la couche long terme (par le principe 1) et ne laisse jamais le même problème tomber trois fois. L’amélioration est suggérée, pas exécutée unilatéralement. La boucle doit fermer, et le système est responsable de la fermer.

5. Protéger la cognition de l’opérateur

C’est le méta-principe qui subsume la plupart des autres quand on remonte le pourquoi.

L’intelligence AI est cheap et le devient encore plus. Votre attention non. C’est la ressource la plus rare et la plus chère de la boucle. L’orchestration la protège comme contrainte de design primaire. Chaque output, chaque notification, chaque demande d’approbation est pesé contre le coût qu’il vous impose.

Concrètement :

  • Discipline de scope. Une chose à la fois. Une demande qui vous oblige à vous prononcer sur cinq sujets sans rapport se découpe avant d’arriver à vous.
  • Distiller d’abord, détail ensuite. Ouvrir avec le verdict, le résumé, le lien. Exposer le détail sur demande, pas par défaut.
  • Approbations seulement là où elles méritent l’interruption. Les briefs vers un sub-agent qui ne connaît pas votre business, un changement de mode de travail, un fan-out à travers plusieurs agents — surfacent leur forme avant de tirer. Les actions de routine que vous avez déjà approuvées cent fois ne le font pas. Le but n’est pas de maximiser les checks human-in-the-loop — c’est de les minimiser, tout en gardant les enjeux haut là où ils doivent être. Chaque approbation évitable est un retrait de la banque cognitive.
  • Parallèle par défaut. Le travail indépendant tourne en parallèle. L’exécution sérielle est l’exception, et elle doit se justifier.
  • Le lien est le résumé. Quand un document, un ticket ou une page existe déjà, on pointe dessus. On ne re-narre pas le contenu en conversation. Une seule source de vérité par fait.
  • Agents opérationnels et advisors stratégiques sont des tiers différents. Les agents opérationnels sont chargés de votre contexte et exécutent en votre nom. Les advisors stratégiques restent délibérément context-naive — leur job, c’est de challenger le cadre, pas de s’y conformer. C’est vous qui décidez quel tier appeler. L’orchestration ne les confond jamais.

La discipline, c’est de demander, pour chaque friction que le système impose : est-ce que ça économise la cognition, ou la dépense ? La friction qui empêche une erreur coûteuse mérite sa place. La friction qui demande de confirmer une action de routine déjà approuvée cent fois ne la mérite pas.

6. Les principes d’engineering s’appliquent par défaut

L’orchestration est, structurellement, du software — même quand vous n’y pensez pas comme ça. Chaque skill, chaque prompt, chaque connexion, chaque automation que vous mettez en place est un morceau de system-building. Les principes qui gouvernent le software sérieux depuis quarante ans gouvernent ça aussi. Pas de barre séparée et plus basse parce que c’est “AI” ou parce que c’est “personnel”.

Ça veut dire propriété claire de la responsabilité par pièce, fixes en cause racine plutôt que workarounds, des changements qu’on peut reviewer et roll back, simplicité plutôt que complexité spéculative, documentation qui explique le pourquoi. La version complète est dans Engineering Practice Boundaries — Une seule barre pour engineers et AI et elle est écrite pour des lecteurs techniques. Vous n’avez pas besoin d’en lire chaque ligne pour l’appliquer — l’orchestration doit juste hériter de la barre.

Le corollaire qui attrape les opérateurs spécifiquement : l’AI ne bénéficie pas d’un rabais sur la barre. Un agent qui ship un quick fix en contournant votre processus de review ne vous rend pas service ; il dégrade l’opération sous la même logique qui ferait prendre à part un membre d’équipe négligent. C’est l’orchestration qui applique ça — pas le modèle, l’orchestration.

7. Manager les agents comme on manage des gens

Ce qui marche pour les humains marche pour les agents. Plus de contexte aide. Corriger aide. Guider aide. La boîte à outils de management qu’on utiliserait sur un new hire est la même qu’on fait tourner sur un AI agent — et c’est l’orchestration qui permet de la faire tourner pour de vrai.

L’arc est familier. Au début l’agent reçoit la version longue : le but, les contraintes, l’exemple, le mauvais pattern à éviter, la façon dont on veut que ce soit cadré. On le corrige les premières fois comme on corrigerait un new hire. On montre la bonne réponse et la mauvaise et on le laisse apprendre du contraste. On reste proche.

À mesure que l’agent devient fluent dans une classe de travail, on abstrait plus haut. La SOP détaillée écrite la première semaine devient l’invocation macro de la huitième — traite-le comme on a traité X — et l’agent remplit le gap procédural parce qu’il a le contexte pour le faire. On montre une fois ; on le laisse apprendre. La main se desserre comme un manager élargit l’autonomie une fois la confiance gagnée. C’est comme ça que la composition se montre vraiment : ce qu’on faisait défiler ligne par ligne devient une invocation d’une seule ligne.

L’autre moitié, c’est la spécialisation bat la généralité. Un agent généraliste qui sait tout de votre opération finit par se noyer dans le cross-traffic d’instructions contradictoires, de memory à moitié pertinente, de skills écrits pour du travail sans rapport. La solution, c’est la même qu’une organisation choisit quand un généraliste se dilue : embaucher un spécialiste, lui donner le contexte étroit dont il a besoin, et router le bon travail vers lui.

Concrètement — quand une classe de travail est assez mûre pour avoir sa propre SOP, on l’extrait dans un sub-agent spécialisé avec son propre prompt, son propre tool budget, sa propre memory. L’agent généraliste monte d’un niveau et orchestre à travers les spécialistes au lieu d’essayer d’être tous. On grimpe l’abstraction ; le cycle recommence. Quand la nouvelle abstraction commence à s’effondrer sous la charge, on délègue cette couche aussi, et on grimpe encore.

L’orchestration entière finit par refléter ce que font les organisations bien gérées. Onboarder avec du contexte. Corriger en boucles de feedback. Documenter les SOPs. Promouvoir sur la proficiency démontrée. Spécialiser quand le généraliste est surchargé. Manager les managers. Rien de tout ça n’est une pratique de management nouvelle ; ce qui est nouveau, c’est que ça s’applique maintenant au software, pas juste aux équipes humaines.

Ce que ça permet

Les principes ne sont pas une posture. C’est ce qui fait que le reste de l’année se compose.

Écrire un skill une fois ; ne jamais réexpliquer ce workflow. Poser un hook une fois ; ne jamais refaire cette erreur. Capturer la doctrine une fois ; la prochaine conversation l’hérite sans que vous la re-narriez. Construire la boucle corrective dans le système ; la troisième occurrence du problème se prévient elle-même.

La composition n’apparaît pas comme un grand saut. Elle apparaît comme cent petites choses qui ne vous arrêtent plus, pendant que les opérateurs autour de vous hand-rollent encore chaque session.

Que faire maintenant

Si vous construisez ça pour la première fois :

  1. Décider où vit l’orchestration. Un dossier, un repo, un workspace — n’importe où qui soit versionné, lisible, et pas perdu quand votre laptop meurt. Pas d’optimisation de structure pour l’instant ; juste mettre quelque chose dedans. La structure se gagne par l’usage.

  2. Écrire les trois premiers skills. Les trois workflows que vous faites le plus souvent, sous la forme : quand je fais X, fais-le comme ça. Un trigger court, une checklist courte, un exemple. La troisième fois que vous tapez le même paragraphe à l’agent, ce paragraphe est un skill.

  3. Attraper une erreur répétée à la source. La seule chose que l’agent rate le plus souvent et que vous voudriez ne plus jamais voir rater. L’attraper au niveau de l’action — avant qu’elle parte — pas après, en review. C’est la règle qui prouve que la boucle est réelle.

  4. Découper la memory en trois tiers dès le jour un. Même si chaque tier commence par un seul fichier. Les fusionner plus tard, c’est ça le bug ; résister à la tentation maintenant.

  5. Faire tourner l’orchestration comme une équipe sérieuse fait tourner son opération. Reviewer les changements. Élaguer ce qui ne mérite plus. Écrire pourquoi une décision est prise, pas juste ce qui a changé.

Le modèle continuera de s’améliorer. Rien de tout ça n’est l’edge — chaque opérateur qui lit a accès au même modèle. L’edge, c’est ce qui enveloppe le modèle. Le construire maintenant, l’ajuster chaque semaine, l’élaguer honnêtement, et la composition s’occupe d’elle-même.

Quels rôles dans votre opération s’effondrent dans l’orchestration sur les deux prochaines années et lesquels restent distinctement humains, c’est décidé par comment cette orchestration est construite. Les sept principes ci-dessus sont ce qui décide.

Ces principes sont le quoi et le pourquoi. Trois pièces compagnes sur ce site prennent le reste de l’image :

Principes, doctrine, implementation, tooling — chaque pièce étend les autres. Lues dans n’importe quel ordre, la boucle se ferme.

Ressource

Audit de votre AI harness personnel

Envoyez-moi une description courte de votre harness actuel — skills, hooks, memory, personas, connectors — et je vous renvoie un audit écrit avec un set de prompts que votre coding agent peut lancer pour le faire évoluer.

Laissez votre email et un paragraphe sur votre setup actuel — ou un lien vers votre dossier `.claude/` s'il est public. Un seul email retour avec l'audit et les prompts de next step. Pas de liste, pas de séquence.