Qu'est-ce qu'un harness system

La plupart des plateformes construisent des agents. Nous construisons l'environnement dans lequel ils s'exécutent.

La distinction semble subtile ; elle ne l'est pas. C'est la différence entre livrer un moteur et livrer un véhicule doté de freins, d'instruments et d'un siège conducteur.

L'origine du mot

En ingénierie, un harness est un banc d'essai. C'est l'appareillage qui permet d'exécuter un composant dans des conditions contrôlées : il fournit les entrées, observe les sorties, impose les limites et coupe l'alimentation quand quelque chose sort du domaine admissible. Les développeurs connaissent le terme par les test harness — le code autour du code testé.

La propriété essentielle : le harness n'est pas le système testé. Il n'a pas besoin d'être plus intelligent que ce qu'il contient. Il doit être fiable là où ce qu'il contient ne l'est pas.

C'est exactement la bonne relation avec un modèle de langage. Le modèle est puissant, généraliste et statistiquement faillible d'une manière qu'on ne peut pas supprimer entièrement. La couche qui l'entoure, elle, peut être étroite, explicite et auditable. Rendre le modèle lui-même assez digne de confiance pour agir sans supervision est le chemin difficile. L'envelopper dans quelque chose qui décide de ce que sa sortie a le droit de devenir est le chemin praticable.

Les couches

Un harness compose six choses que la plupart des stacks laissent éparpillées.

Le modèle de langage comprend la langue, extrait de la structure d'entrées désordonnées, propose des actions et parle aux gens. C'est ce qu'il fait vraiment très bien.

Les outils agissent : interroger une base, appeler une API interne, écrire un enregistrement, envoyer un document. Ils constituent le seul chemin du raisonnement vers l'effet — d'où leur rôle naturel de point de contrôle.

Le modèle du domaine — ontologies, nomenclatures, référentiels — décrit ce qui existe dans cette activité et comment cela se relie. C'est ce que, comme l'argumentait l'article précédent, le RAG ne remplace pas.

Les politiques énoncent ce qui est permis : quel agent peut appeler quel outil, sur quelles données, pour le compte de qui, jusqu'à quel seuil, dans quelle juridiction.

La validation contrôle les résultats avant qu'ils ne deviennent des actions : la proposition respecte-t-elle les contraintes du domaine, les sources citées existent-elles et disent-elles ce qu'on leur prête, la sortie est-elle bien formée pour le système qui la consommera.

L'humain décide là où une décision doit avoir un propriétaire. Non pas en relisant tout — cela ruine l'économie du dispositif — mais aux points que la politique marque comme sensibles et que la validation marque comme incertains.

Un harness, c'est ce qui fait de tout cela un seul système d'exécution plutôt que six projets d'intégration.

Ce que le harness sait

Concrètement, il détient les réponses à des questions qui vivent aujourd'hui dans des prompts et dans la mémoire des équipes :

• quel agent peut accomplir quelle action, et sur quelle autorité ;
• quelles données une tâche a le droit de toucher, et lesquelles elle ne doit jamais voir ;
• quelles sorties doivent être vérifiées avant de sortir, et contre quoi ;
• quelles règles priment lorsque deux s'appliquent ;
• à quel moment un dossier doit s'arrêter et attendre une personne ;
• et comment une décision achevée s'explique ensuite — la chaîne de preuves, de vérifications et d'approbations qui l'a produite.

Aucune de ces propriétés n'est une capacité du modèle. Aucun fine-tuning ne produit « cet agent n'a pas accès aux données de paie ». C'est une propriété architecturale, et elle appartient à une couche qui existe que le modèle se comporte bien ou non.

Pourquoi le problème a la forme d'un système d'exploitation

Un système d'exploitation ne fait pas le travail utile. Il arbitre : il décide quel processus obtient le CPU, quelle mémoire il peut adresser, quels appels système lui sont ouverts, et il isole la défaillance d'un processus des autres. La valeur est dans les applications ; l'OS est la raison pour laquelle la machine tient debout quand une application a tort.

Les agents suivent la même trajectoire. Une organisation avec trois agents les gouverne à la main. Une organisation avec trois cents — écrits par des équipes différentes, appelant les outils les uns des autres, touchant des données qui se recoupent sous des obligations juridiques distinctes, certains fournis par un éditeur, d'autres assemblés par une direction métier le trimestre dernier — ne le peut plus. Il lui faut un endroit où l'identité, les permissions, la validation et l'audit existent une seule fois, pour tous.

Cet endroit, c'est le harness.

Où nous en sommes réellement

Une note d'honnêteté, car cette série parle d'architecture et pourrait se lire comme une fiche produit.

Cradle met aujourd'hui en œuvre la partie la plus proche de l'exécution : orchestration de modèles locaux, routage d'agents, ancrage dans vos propres documents, filtrage du risque à deux niveaux sur les réponses, et approbation humaine avant que quoi que ce soit ne quitte le périmètre — le tout sur votre matériel. C'est un harness opérationnel, au sens étroit.

Le tableau complet décrit ici — moteur de politiques de plein droit, environnement de validation, packs métier et ontologies comme composants livrés — constitue l'architecture cible, pas la version actuelle. Nous la publions parce que nous préférons être jugés sur une conception annoncée plutôt que vendre un système achevé qui n'existe pas. Le document d'architecture sépare explicitement les deux colonnes.

---

Ensuite : L'environnement d'exécution neuro-symbolique — comment les moitiés neuronale et symbolique s'entrelacent à l'exécution.