Le Harness IA a dix composants, pas sept

Tomasz Tunguz a publié Software After AI / Harnessing AI hier. C’est la décomposition architecturale en une seule page la plus propre de ce dont les systèmes IA de production ont vraiment besoin que j’aie lue cette année. Son argument central tient en une ligne :

Comme un mustang, l’IA est puissante mais sauvage. Que se passe-t-il quand chaque entreprise a accès au même modèle ? Les meilleurs cavaliers gagnent.

C’est juste, et Tunguz détaille sept composants dont un harness IA sérieux a besoin pour gagner le concours du cavalier. Lisez son article. Douze minutes, et ça devrait être lecture obligatoire pour tout CPTO et tout head of engineering qui planifie son architecture 2027.

Voici la partie que je veux ajouter. Les sept composants que Tunguz décrit sont le harness technique. C’est ce qu’un ingénieur doit construire. Ce n’est pas, en soi, ce qui fait gagner le harness sur le marché. Les mêmes sept composants, construits à la même qualité, produiront des résultats radicalement différents selon trois couches que Tunguz sous-pondère ou ne couvre pas du tout : la couche leadership humain, la couche engagement client et la couche business model.

Je construis cet argument depuis l’article sur l’empowerment, l’article sur le vibe coding, l’article sur l’Act 2 de GitLab et l’article sur les Forward Deployed AI Engineers. Cet article les relie au framework de Tunguz et propose la forme complète : le harness IA a dix composants, pas sept.

Les sept que Tunguz nomme

Brièvement, pour que vous puissiez suivre sans quitter cette page. Le framework de Tunguz, avec ma glose en une ligne sur chacun :

#	Composant	Ce que c’est	Pourquoi ça compte
1	Contexte et mémoire (Context & Memory)	Retrieval custom, mémoire court terme, bases SOP qui évoluent avec l’org	Détermine si l’agent sait ce que votre business veut dire par “contrat” ou “incident”
2	Outils et action (Tools & Action)	Outils exposés via registry, arguments validés, gates d’approbation, MCP comme tissu conjonctif	Détermine ce que l’agent peut vraiment faire, en sécurité
3	Orchestration et boucle (Orchestration & Loop)	Cycles penser-agir-observer, sous-agents, planification, retries, conditions d’arrêt	Détermine comment l’agent récupère de ses propres erreurs
4	État et persistance (State & Persistence)	Checkpoints, systèmes de fichiers, threads de session, stockage d’artefacts	Détermine si une tâche multi-étapes reprend ou redémarre
5	Sandbox et compute (Sandbox & Compute)	Espaces Unix isolés, egress contrôlé, gestion des credentials	Détermine si l’agent peut tourner en sécurité sur des données de production
6	Observabilité et gouvernance (Observability & Governance)	Tracing, logs, evals-comme-tests-de-régression, human-in-the-loop	Détermine si on peut débugger, faire confiance et améliorer le système
7	Coût et optimisation de workflow (Cost & Workflow Optimisation)	Routing déterministe vs non-déterministe, sélection du modèle	Détermine l’économie unitaire de chaque run d’agent

C’est une stack serrée, opiniâtre. Chacun de ces composants est non-négociable. Sautez-en un, et le harness a un trou qui produira une fracture de fatigue sous charge de production. Si vous construisez des agents IA et que vous n’avez pas de réponse architecturale claire pour chacun de ces sept, votre harness est incomplet.

Mais voilà : si chaque éditeur sérieux construit ces sept, le problème de différenciation n’est pas résolu. Il est déplacé. “Les meilleurs cavaliers gagnent” est le bon cadrage, mais le framework de Tunguz ne vous dit que ce à quoi ressemblent la selle et la bride. Il ne vous dit rien sur le cavalier, sur sa relation avec le cheval, ni sur la cagnotte.

Les trois couches que Tunguz manque

8. Leadership et empowerment

Le framework de Tunguz est centré ingénierie : il décrit ce dont le système a besoin. Il est silencieux sur qui opère le système, comment ces personnes sont organisées, et quelle culture elles apportent pour l’opérer. C’est une omission porteuse, parce que le même harness produit des résultats radicalement différents selon l’équipe qui le fait tourner.

J’ai déployé cet argument en entier dans Diriger l’IA est un problème d’empowerment, donc la version courte est celle-ci. La position on-the-loop de Kief Morris - construire et améliorer le harness plutôt qu’inspecter chaque artefact - est exactement ce que Marty Cagan appelle empowered product teams depuis vingt ans, et exactement ce que Reed Hastings appelle context not control chez Netflix. Le harness est l’artefact technique. La façon dont les humains s’y rapportent est l’artefact culturel. Vous avez besoin des deux.

Concrètement, la couche leadership du harness doit couvrir :

Talent density. Le composant Observability & Governance de Tunguz n’est utile que s’il y a des humains à l’autre bout des alertes capables d’agir dessus. Les empowered teams à haute talent density vont resserrer le harness avec le temps. Les feature teams vont réagir aux alarmes et livrer des rustines. Même observabilité, évolutions différentes.
Ownership empowered. Chaque composant du harness a besoin d’un owner avec l’autonomie de l’améliorer. Context & Memory sans owner devient obsolète. Tools & Action sans owner accumule des outils morts et dupliqués. Orchestration & Loop sans owner cesse d’être challengé. Le flywheel agentique que le framework de Tunguz rend possible ne tourne que si quelqu’un en possède la rotation.
Discipline anti-rationalisation. Le framework agent-skills open source d’Anthropic est, dans cette optique, un harness pour les humains qui construisent des harness. Chaque skill a une section rationalisations explicite qui anticipe les excuses qu’un agent ou un ingénieur fatigué inventera pour sauter le bon process. Sans cette discipline encodée dans la façon de travailler de l’équipe, votre harness se dégrade silencieusement avec le temps et vous ne le remarquez pas avant que la prod casse.

Le test mécanique est celui-ci : si vous imaginez remplacer l’équipe d’ingénierie qui opère votre harness, en passant de votre org actuelle à une org en feature teams d’une bureaucratie du Fortune 500, le harness produit-il les mêmes résultats ? Bien sûr que non. Le harness est nécessaire ; l’équipe qui l’opère est la variable qui décide si vous gagnez. Le framework de Tunguz traite ça comme hors scope. Ça ne l’est pas.

9. Engagement client et promotion de patterns

Le framework de Tunguz suppose implicitement que le harness est déployé une fois dans un environnement unique. Cette hypothèse casse dès que vous vendez du logiciel IA à des entreprises. Le harness doit être opéré contre la réalité du client, pas la vôtre, et l’architecture doit faire en sorte que cet engagement se compose en valeur plateforme plutôt que de s’évanouir en chiffre d’affaires services sur mesure.

J’ai déroulé cet argument longuement dans Le SaaS n’est pas mort - il recrute des Forward Deployed AI Engineers. Le modèle Palantir est la preuve : des Forward Deployed Engineers embarqués dans l’environnement du client, qui construisent le harness contre les données, les process et les gens du client, avec un forum de promotion hebdomadaire explicite qui tire les patterns sur mesure de retour dans la plateforme. La raison pour laquelle Palantir a 139% de net dollar retention et pas le 110% plat habituel du SaaS, c’est que cette couche se compose d’une façon qu’un produit installable ne fait jamais.

Concrètement, la couche engagement client du harness couvre :

Forward Deployed AI Engineering comme fonction, pas comme consultance facturable. Ingénieurs seniors plus agents, embarqués chez les clients, payés à l’intérieur du contrat plateforme. L’économie fonctionne parce que les agents effondrent le coût des services ; sans ça, vous recréez un bras services à 30% de marge brute et la plateforme perd le focus.
Forums de promotion de patterns. Cadence hebdomadaire, pas d’exceptions, trois questions : qu’est-ce que les FDE ont construit cette semaine, quels patterns vont apparaître chez les cinq prochains clients, qui possède leur promotion dans la plateforme ? C’est le flywheel agentique que le framework de Tunguz rend possible, appliqué aux engagements éditeur-client plutôt qu’aux boucles internes.
Ontology côté client. Le composant Context & Memory de Tunguz parle de retrieval et de SOP dans l’abstrait. En réalité, le contexte le plus précieux est le modèle sémantique et exécutable du business spécifique du client - ce que Palantir appelle l’Ontology. La mission FDE est la façon dont ça se construit. Sans la couche engagement, votre composant Context & Memory est générique et celui de votre concurrent est sur mesure et composé.

Le test honnête de savoir si votre harness a cette couche : quand un client signe, le harness produit-il de la valeur en jours ou en mois ? Les produits sortis de la boîte produisent de la valeur en mois. Les harness équipés FDE produisent de la valeur en jours. Le marché récompensera la seconde forme, durement, pendant les cinq prochaines années.

10. Business model et capture composée

Le septième composant de Tunguz est Cost & Workflow Optimisation. C’est une vue économie unitaire : modèles cheap pour le travail facile, modèles chers pour le travail dur. C’est juste et nécessaire, et ce n’est pas non plus tout le tableau du business model. Le business model doit matcher l’architecture, et le framework de Tunguz est silencieux sur le pricing.

L’architecture d’un harness agentique a deux régimes économiques distincts :

La plateforme elle-même est du logiciel à coût fixe élevé, coût marginal faible. L’économie est du pur SaaS. L’abonnement est la primitive de pricing juste pour cette couche.
Le travail d’agent que le harness exécute est du compute à coût variable, lié à la valeur. Les clients veulent payer en proportion du travail fait, surtout à mesure que les agents prennent en charge des tâches qui demandaient des têtes. La consommation est la primitive de pricing juste pour cette couche.

Un business model pur abonnement sous-monétise les gros clients agents et surfacture les petits. Un modèle pur consommation pénalise les clients qui s’appuient sur la plateforme et crée une prédictibilité de chiffre désastreuse. La lettre Act 2 de GitLab pointe explicitement cet hybride exact comme Conviction 9 de leur stratégie en avant : abonnements pour ce que les clients ont aujourd’hui, pricing à la consommation pour le travail que font les agents, avec plus de flexibilité pour mixer à mesure que la façon de travailler évolue. Palantir fait la même chose opérationnellement. Ce n’est pas une décision marketing ; c’est une décision architecturale, et elle a sa place dans le framework du harness.

Concrètement, la couche business model couvre :

Pricing hybride. Abonnement pour la valeur plateforme stable, consommation pour le travail au rythme agent, avec un chemin clair de l’un à l’autre pour que les clients grandissent sans renégocier.
Engagement bundlé dans les contrats plateforme. L’engagement FDE de la couche engagement client ne peut pas être vendu comme SOW séparé sinon la boucle de feedback plateforme meurt. Inscrivez-le dans le pricing plateforme.
OKRs qui connectent les métriques agent aux outcomes business. Le composant Observability de Tunguz vous donne la donnée. La couche business model transforme cette donnée en operating system de l’entreprise. Le taux de succès agent par workflow doit se trouver à côté des métriques north-star produit et du chiffre, sinon le harness est invisible aux personnes qui décident où investir.

Le test pour cette couche : pouvez-vous faire grandir le harness et faire grandir la dépense du client en proportion sans friction de renégociation ? Si oui, votre business model est harness-aware. Si les renouvellements demandent d’arracher des dents et les expansions des cycles de procurement neufs, le modèle et l’architecture sont désalignés.

Le harness à dix composants

Tout assembler :

Couche	#	Composant
Technique (Tunguz)	1	Contexte et mémoire (Context & Memory)
	2	Outils et action (Tools & Action)
	3	Orchestration et boucle (Orchestration & Loop)
	4	État et persistance (State & Persistence)
	5	Sandbox et compute (Sandbox & Compute)
	6	Observabilité et gouvernance (Observability & Governance)
	7	Coût et optimisation de workflow (Cost & Workflow Optimisation)
Humain / Leadership	8	Leadership et empowerment
Go-to-market / Implémentation	9	Engagement client et promotion de patterns
Stratégie / Capture	10	Business model et capture composée

C’est la forme complète. Tunguz a écrit la moitié architecture technique. Les trois autres composants sont ce qui transforme un harness technique en business qui gagne.

Chacun mappe à l’un de mes articles récents, délibérément :

Composants 1-7 ⇄ Architecture IA à trois niveaux et Le Skills Framework au niveau implémentation.
Composant 8 ⇄ Diriger l’IA est un problème d’empowerment et Le Vibe Coding en Prod est un Problème de Management.
Composant 9 ⇄ Forward Deployed AI Engineers.
Composant 10 ⇄ L’Act 2 de GitLab - La restructuration agentique passe au grand jour.

Si vous voulez opérationnaliser le harness à dix composants en 2026-27, ces cinq articles sont le playbook opérationnel, et l’article de Tunguz est le plan architectural en dessous.

Là où Tunguz a clairement raison

Je veux être clair que cet article est une extension, pas une réfutation. Le framework de Tunguz est l’artefact unique le plus utile que j’aie vu cette année pour les ingénieurs qui planifient des systèmes IA. Spécifiquement :

Le cadrage de l’ère du harness est exactement juste. La transition de “logiciel avec workflows fixes” à “IA à l’intérieur d’un harness” est l’histoire dominante de l’enterprise software en ce moment, et nommer ça l’ère du harness est le bon vocabulaire.
Les sept composants sont les bons sept. Je n’en retirerais aucun. Essayez de faire sans State & Persistence et vos tâches multi-étapes se cassent à l’échelle. Essayez de faire sans Sandbox & Compute et vous bouffez un incident de sécurité dans vos six premiers mois en prod.
L’argument de l’avantage compétitif est juste. Quand les modèles se commoditisent, les cavaliers gagnent. Il cloue ça. Tous ceux qui lisent son article devraient l’intérioriser.

Ce que je soutiens, c’est que les sept composants sont nécessaires et non suffisants. Une fois que chaque éditeur sérieux construit les mêmes sept, la différenciation qui décide qui gagne vraiment le concours du cavalier vient des trois composants que Tunguz sous-pondère. Construisez les sept. Puis construisez les trois suivants.

Un audit à quatre-vingt-dix jours en utilisant les dix composants

La chose la plus utile qu’un CPTO, un VP Eng ou un fondateur qui pilote un produit agentique puisse faire ce trimestre, c’est de mener l’audit à dix composants sur sa propre org. La forme qui a bien marché dans les conversations avec des dirigeants qui font cet exercice :

Jours 0-30 : noter chaque composant honnêtement. Passez les dix en revue, notez chacun sur une échelle de 1 à 5, et adossez le score à de la preuve concrète (un déploiement, un outcome client, un postmortem). Visez une calibration brutale. Si trois de vos scores atterrissent à 4 ou 5, vous vous notez probablement trop gentiment. La plupart des orgs ingénierie bien tenues qui n’ont pas fait cet exercice noteront 2 ou en dessous sur au moins trois des dix.
Jours 30-60 : investir dans les deux plus bas. Pour la plupart des organisations, les deux plus bas sont prévisibles. Observability & Governance (composant 6) atterrit bas parce que personne ne veut faire le travail ingrat de tracing et d’eval. Engagement client et promotion de patterns (composant 9) atterrit bas parce que le mouvement style FDE est culturellement dur pour des boards qui ont grandi sur l’économie pur-SaaS. Les deux sont exactement là où le levier se cache. Choisissez les deux plus bas de votre scorecard et investissez là avant de toucher à quoi que ce soit d’autre.
Jours 60-90 : connecter le harness aux outcomes business. Reliez la donnée qui sort des composants 6 et 7 directement aux OKRs de votre entreprise (composant 10), et montez le premier forum hebdomadaire de promotion de patterns (composant 9) pour que l’apprentissage engagement client revienne dans la plateforme. Établir la cadence tôt, c’est ce qui fait la différence entre un flywheel et un produit statique six mois plus tard.

Un test simple pour savoir si l’audit a fonctionné : à la fin des quatre-vingt-dix jours, vous devriez pouvoir pointer chacun des dix composants et nommer (a) la personne qui le possède, (b) le score auquel il était, et (c) le score auquel il est maintenant. Si ces trois colonnes sont remplies pour chaque ligne, vous opérez le harness à dix composants plutôt que d’en lire la théorie. Les sept de Tunguz, vous les suivez peut-être déjà. Les trois autres sont là où le levier se cache.

À retenir

Tunguz a publié le bon framework au bon moment. “Les meilleurs cavaliers gagnent” sera la phrase que tout le monde citera pendant l’année qui vient, et les sept composants sont la bonne architecture de départ pour toute équipe produit IA sérieuse en 2026-27.

Le morceau qui manque, je pense - et le morceau que je travaille depuis six mois sur ce site - c’est que le harness technique est nécessaire et non suffisant. Les équipes qui gagneront l’ère du harness seront celles qui traitent la couche leadership humain, la couche engagement client et la couche business model comme des composants first-class du même système. Construisez les sept, puis construisez les trois suivants. Le levier se compose à travers les dix.

Si vous lisez l’article de Tunguz cette semaine, associez-le aux cinq articles que j’ai liés plus haut. Ensemble ils sont le playbook opérationnel pour les vingt-quatre prochains mois d’enterprise IA. Les cavaliers qui intériorisent les dix composants, pas seulement les sept, sont ceux qui finiront la course.

Références

Software After AI / Harnessing AI - Tomasz Tunguz - Le framework à sept composants que cet article étend
Diriger l’IA est un problème d’empowerment - La couche leadership humain (composant 8)
Le Vibe Coding en Prod est un Problème de Management - Le pendant contributeur individuel du composant 8
Forward Deployed AI Engineers - La couche engagement client (composant 9)
L’Act 2 de GitLab - La restructuration agentique passe au grand jour - La couche business model (composant 10)
Le Skills Framework - Discipline procédurale à l’intérieur du harness technique
Architecture IA à trois niveaux - Patterns architecturaux au niveau implémentation
Le dernier goulot d’étranglement - Pourquoi ça compte maintenant