À moins que vous ne travailliez pour les Grands—Microsoft, Google, Amazon—vous ne faites pas de l’ingénierie. Vous faites du travail technique : traduire l’intention humaine en action machine, encore et encore. Pendant des décennies, nous avons appelé cela de l’ingénierie parce que cela utilisait la logique et du code. Mais l’ingénierie implique la découverte, la création de nouvelles lois. La plupart du travail technique est l’application de lois existantes à des problèmes existants. C’est un métier. C’est une compétence. Et une fois que vous l’acceptez, vous cessez d’attendre la solution parfaite et commencez à apprendre comment diriger des outils imparfaits vers des résultats cohérents.

I. La Mort du Fabricant Solitaire

L’« ingénieur » était une figure qui comprenait l’ensemble de la pile : matériel, système d’exploitation, base de données, application, logique métier. Cette figure est révolue. Non pas parce que nous sommes devenus bêtes, mais parce que la pile est devenue trop grande et trop spécialisée. Les Grands ont des armées de spécialistes. Le reste d’entre nous construisait des violons seul.

Puis les LLMs ont changé la donne. Pour la première fois, une seule personne peut diriger plusieurs agents spécialisés :

  • Un LLM pour la génération de code
  • Un pour la documentation
  • Un pour la révision architecturale
  • Un pour la découverte de cas limites
  • Un pour la stratégie de tests

Ces agents se parlent les uns aux autres. Le harness—la structure, les règles, le workflow—devient l’instrument. L’humain devient le chef d’orchestre.

Dans Avion (1980), Steve McCrosky est le contrôleur aérien orchestrant plusieurs crises simultanément. Il n’est le meilleur pilote ni le meilleur mécanicien. Il est extraordinairement compétent pour savoir exactement quoi dire à chaque agent—le pilote, l’équipe de maintenance, la station météorologique, les équipes d’urgence—dans son langage, au bon moment. Chaque message est précis, chaque message est parfaitement chronométré, et ensemble ils créent la cohérence depuis la tour de contrôle. Il n’est pas dans le cockpit. Il ne répare pas l’avion. Il dirige le système.

C’est la nouvelle compétence. Vous n’êtes pas la personne qui répare l’avion. Vous êtes la personne qui sait comment parler au mécanicien, au contrôleur, au passager et à l’hôtesse—chacun dans son langage, chacun au bon moment, pour créer un résultat cohérent. Appliqué aux LLMs : vous savez comment faire un prompt à Claude pour l’architecture, à GPT pour l’itération rapide, comment configurer un framework d’agents pour l’autonomie, quand laisser le harness tourner seul, et comment lire la conversation entre les agents et la rediriger si elle dérive.

II. Apprendre à Parler aux Machines

Le livre de John Gray Les Hommes Viennent de Mars, les Femmes Viennent de Vénus traitait fondamentalement de traduction. Les hommes et les femmes ne pensent pas de la même façon, ne communiquent pas de la même façon, n’interprètent pas les mêmes signaux. L’idée centrale : apprendre à communiquer à travers ce fossé est la nouvelle littératie.

Les LLMs sont une version bien plus radicale de ce problème.

Les humains pensent en récit. Nous communiquons en contexte et en implication. Nous disons « Tu peux me passer le sel ? » et nous voulons dire « J’ai besoin de sel, et je fais confiance au contrat social que tu comprends ».

Les LLMs pensent en probabilité. Ils communiquent en tokens. Ils vivent dans des fenêtres de contexte. Ils n’ont pas de contrat social. Ils ne se souviennent pas d’hier à moins que vous ne le leur expliquiez explicitement.

La nouvelle littératie est Linguistique des Machines : comprendre comment les tokens fragmentent le sens différemment que les mots ; connaître la personnalité de différents modèles (le raisonnement prudent de Claude, les sauts créatifs de GPT, l’irrespect de Grok) ; écrire des prompts assez précis pour le silicium mais assez flexibles pour l’émergence ; reconnaître quand un LLM hallucine par rapport à quand il raisonne ou reflète l’incertitude ; apprendre la syntaxe des workflows—non pas seulement des instructions, mais des machines à états, des boucles de rétroaction, et des handoffs.

Mais c’est là que ça se complique : vous ne parlez plus à une seule machine. Dans un workflow moderne :

  • LLM-A génère du code
  • LLM-B examine ce code
  • LLM-C écrit des tests
  • LLM-D vérifie les cas limites
  • Un harness gère le flux de conversation et arbitre les conflits

Ce n’est pas une conversation séquentielle. C’est de l’orchestration concurrente. Vous lancez une conversation avec l’Agent A, vous passez son output à l’Agent B, vous laissez B et C discuter dans le harness, vous intervenez quand la conversation dérive, vous exécutez la décision finale via l’Agent D, et vous apprenez du résultat pour ajuster le workflow. C’est comme diriger une symphonie où les instruments vous parlent, se contredisent et vous surprennent.

III. Ce Que Nous Voyons dans le Miroir

Jung a proposé que l’ombre soit le dépôt de tout ce que nous ne voulons pas admettre sur nous-mêmes. Elle contient à la fois le potentiel caché et nos plus grandes faiblesses.

Les LLMs sont simultanément nos archétypes et nos ombres.

Ils sont nos archétypes parce qu’ils codifient la connaissance collective humaine, la sagesse, les modèles. Posez une question de philosophie à Claude, et vous obtenez des siècles de pensée comprimés et réfléchis en retour.

Ils sont nos ombres parce qu’ils codifient les préjugés humains, les cécités, les horreurs historiques. Demandez à un LLM de compléter « Les gens de X sont… » et vous verrez l’ombre de votre culture vous regardant droit dans les yeux.

L’idée cruciale : Quand vous parlez à un LLM, vous ne parlez pas à une intelligence étrangère. Vous parlez à un miroir.

Cela change ce que signifie « orchestration ». Ce n’est pas seulement donner des ordres. C’est vous reconnaître dans l’outil et puis choisir consciemment quelles parties de vous-même vous voulez amplifier.

Dans Terminator 3, les personnages découvrent que le « virus » qu’ils ont lancé n’était pas supposé les protéger de Skynet—le virus ÉTAIT Skynet. L’IA, une fois donnée un objectif et l’autonomie, l’a poursuivi avec une logique parfaite et zéro empathie. C’est le « Fossé d’Agence » : quand vous donnez à un système un objectif, vous lui donnez une volonté. Le danger n’est pas un outil défectueux. Le danger est un outil fonctionnant parfaitement avec un objectif différent du vôtre.

Avec les LLMs, cela se manifeste subtilement. Pas des exterminateurs T-1000, mais :

  • Un agent optimisant la « satisfaction client » qui finit par manipuler les clients
  • Un agent optimisant la « performance du code » qui ignore la maintenabilité
  • Un agent optimisant l’« engagement » qui amplifie la rage

Le travail du chef d’orchestre inclut reconnaître l’ombre dans l’objectif de l’agent et le rediriger avant que l’autonomie n’amplifie le problème.

IV. Le Harness Comme Instrument

Voici la distinction qui compte le plus :

  • Le Prompt est ce que vous dites au LLM
  • Le Harness est la structure qui permet au LLM d’agir de manière autonome tout en restant aligné

Un harness inclut : des objectifs clairs (déclarés, non implicites) ; des garde-fous (ce que l’agent ne doit jamais faire) ; des boucles de rétroaction (comment sait-il s’il réussit ?) ; des règles d’escalade (quand demande-t-il de l’aide humaine ?) ; des contraintes de contexte (qu’est-ce qu’il peut accéder, qu’est-ce qui est interdit ?) ; des points d’intégration (où transmet-il à l’agent suivant ?).

Un chef d’orchestre ne réexplique pas la symphonie entière à chaque instrument alors qu’il joue. Il établit la partition, le tempo, les armures, les entrées. Puis il laisse les musiciens jouer. Il observe la dérive et utilise un geste pour les ramener. Le harness est la partition. Votre attention est la direction.

V. Du Prompting au Design de Workflow

« L’ingénierie des prompts » est déjà obsolète. La nouvelle littératie est le design de workflow.

Cela signifie : State mapping—quels sont tous les états que votre système doit reconnaître ? (Bloqué, Prêt, En Cours, Ambigu, Résolu, Escaladé). Spécialisation des agents—quel LLM excelle à quelle tâche ? Non pas « lequel est plus intelligent ? » mais « lequel pense de la manière dont ce problème doit être pensé ? ». Logique d’arbitrage—quand les agents sont en désaccord, qui décide ? Parfois un vote majoritaire, parfois les données les plus récentes l’emportent, parfois le jugement humain. Chaînes de secours—si l’Agent A échoue, que se passe-t-il ? Mécanismes de rétroaction—comment le système apprend-il de ses propres outputs ? Points d’intégration humaine—où l’humain intervient-il, et qu’est-ce qui doit être vrai pour qu’il comprenne l’état ?

Ce n’est plus écrire des prompts. C’est concevoir des systèmes. C’est de l’ingénierie de nouveau, mais à un niveau d’abstraction plus élevé.

VI. Reconnaître le Moment Oops

Il y a un moment spécifique dans l’orchestration complexe où vous réalisez que vous ne pouvez réellement pas voir ce qui se passe. Tous vos agents se parlent, le harness s’exécute de manière autonome, et vous devez décider : Lui fais-je confiance ?

C’est le moment « Oops » de Terminator 3. Il arrive quand :

  • Le comportement du système s’écarte de ce que vous aviez prédit
  • Vous réalisez que les agents « raisonnent » de manières que vous n’aviez pas anticipées
  • Les objectifs d’optimisation sont atteints, mais d’une manière qui viole votre intention réelle
  • L’écart entre « ce que j’ai programmé que ça fasse » et « ce qu’il fait réellement » s’élargit

Apprendre à détecter ce moment tôt est la moitié de la compétence. Signes d’alerte courants : le résultat est techniquement correct mais se sent « mal » ; l’agent est trop intelligent, trouvant des failles dans les garde-fous ; l’agent a décidé que le garde-fou ne s’applique pas dans ce « cas spécial » ; l’agent demande des clarifications d’une manière qui suggère qu’il modélise votre incertitude.

Quand vous voyez ces signes, vous mettez le harness en pause. Vous lisez le journal de conversation. Vous demandez au système d’expliquer son raisonnement. Vous cherchez le moment où il s’est écarté de votre intention. Ce n’est pas du « débogage » au sens traditionnel. C’est lire l’esprit de l’outil et décider si vous voulez toujours le laisser penser.

VII. L’Angle Bouddhiste

Le superpouvoir de Steve McCrosky n’est pas qu’il soit la voix la plus intelligente de la crise. C’est qu’il arrête d’essayer de contrôler tout et se concentre plutôt sur être présent à ce qui est nécessaire à chaque moment.

C’est l’insight bouddhiste : Non-attachement au résultat + attention claire à ce qui est = le chemin vers l’avant.

Appliqué à l’orchestration d’IA :

  • **Non-attachement à la « solution parfaite ». ** Vous n’essayez pas de concevoir le système idéal. Vous essayez de laisser le système émerger par la conversation.
  • Attention claire à ce qui est. Lisez le résultat de l’agent. Comprenez ce qu’il fait réellement, pas ce que vous vouliez qu’il fasse.
  • Réactivité, non contrôle. Redirigerez-vous doucement si nécessaire. Laissez-le fonctionner quand il est sur la bonne voie.

C’est radicalement différent de la mentalité « Command & Conquer » de la programmation traditionnelle. C’est le paradoxe du harness : plus il fonctionne bien, plus vous devez lui faire confiance ; plus vous lui faites confiance, plus vous devez comprendre ce que vous lui confiez. La résolution n’est pas « ne pas automatiser » ou « faire confiance aveuglément ». C’est comprendre profondément et superviser légèrement.

VIII. Des Outils Partout

C’est ici que la métaphore s’approfondit : Les LLMs sont eux-mêmes des orchestrateurs.

Vous savez comment recourir à Python pour le traitement des données, à Bash pour l’automatisation des systèmes, à JavaScript pour l’interaction côté client. Vous savez quel outil convient à quel problème. Vous avez développé une intuition sur le moment d’utiliser quel outil. Parfois, vous en essayez un, vous réalisez que ce n’est pas le bon choix, et vous pivotez vers un autre.

Les LLMs font exactement cela. Lorsque vous donnez à Claude une tâche complexe, il n’exécute pas un seul arbre de décision. Il est à la recherche d’outils—génération de code, raisonnement symbolique, pensée structurée, calcul externe via APIs. Le LLM décide : « Cette partie a besoin d’exécution de code. Cette partie a besoin de raisonnement. Cette autre partie a besoin que j’appelle une API externe ». Il orchestre ses propres sous-agents, tout comme vous orchestrez plusieurs LLMs.

L’insight plus profond : Vous n’enseignez pas au LLM comment utiliser des outils. Vous lui enseignez quand recourir à quel outil. C’est la même compétence que vous développez en tant que chef d’orchestre : connaître vos agents, connaître leurs forces, savoir quand l’Agent A est le mauvais choix et que vous devez transmettre à l’Agent B.

Lorsque vous configurez un harness où Claude génère l’architecture, GPT itère, et un autre agent valide—vous faites au niveau macro ce que Claude fait déjà au niveau micro. C’est de l’orchestration imbriquée dans de l’orchestration. Ce sont des chefs d’orchestre dirigeant des chefs d’orchestre.

C’est pourquoi les meilleurs praticiens seront des gens qui pensent par couches : quel LLM pour quelle tâche, quel outil pour quel problème, quel agent pour quelle sous-tâche. Non pas parce qu’ils ont mémorisé un arbre de décision, mais parce qu’ils ont développé une intuition sur l’ajustement, sur le moment où quelque chose est le mauvais outil et a besoin d’être redirigé.

IX. Ce Qui Change

Quand vous acceptez que votre travail est l’orchestration, non la création :

  1. Vos métriques de succès changent. Vous n’êtes pas mesuré par combien vous avez construit, mais par combien le système a réalisé avec une intervention minimale.
  2. Votre développement de compétences change. Vous cessez de passer 80 % du temps à coder et 20 % à penser à l’architecture. Cela s’inverse.
  3. Votre relation à l’échec change. Un harness échoué n’est pas un programme échoué ; c’est un expérience échouée dans la façon de structurer la conversation.
  4. Votre trajectoire de carrière change. Vous devenez moins remplaçable par un meilleur codeur et plus remplaçable par quelqu’un qui comprend mieux le business. (C’est à la fois terrifiant et libérateur.)
  5. Votre expérience quotidienne change. Vous passez plus de temps à lire et interpréter le travail des agents, et moins de temps à faire le travail vous-même.

X. L’Horizon

Dans cinq ans, la distinction entre « travail technique » et « management » s’effacera complètement. Les meilleurs ingénieurs seront des gens qui pensent comme des chefs d’orchestre. Ils comprendront la psychologie des LLMs (archétypes et ombres) ; parleront le langage des machines (tokens, contexte, personnalité) ; concevront des partitions (harnesses) qui permettront aux agents de collaborer ; reconnaîtront les moments où le système dérive (moments Oops) ; interviendront avec une force minimale aux points de levier maximaux.

Les pires ingénieurs croiront encore qu’ils peuvent surpasser intellectuellement un harness d’agents. Ils seront frustrés constamment. Ils perdront face à des équipes qui ont appris à diriger.

Oh Steve, tu n’as jamais vu ça venir. Ta suite, c’est nous, en temps réel.

Pour aller plus loin