Le harnais est un actif, le modèle est un consommable

Ce que le mot harnais désigne exactement

Il faut commencer par lever une confusion qui coûte cher dans les appels d'offres. L'agent est l'application : le service métier qui répond à une demande, rédige une note, instruit un dossier. Le harnais en est le système d'exploitation : il ordonne les appels au modèle, gère le contexte qui lui est transmis, exécute les outils, isole les espaces de travail, reprend sur erreur, plafonne les budgets et journalise ce qui s'est passé.

Deux organisations qui utilisent exactement le même modèle et deux harnais différents n'obtiennent pas les mêmes résultats, ni les mêmes coûts, ni le même niveau de fiabilité. L'écart n'est pas marginal : il est du même ordre que celui qui séparait deux générations de modèles il y a trois ans.

Cette confusion explique une bonne partie des déceptions constatées après un pilote réussi. Le pilote validait un modèle, la mise à l'échelle bute sur un harnais que personne n'avait spécifié. Un test simple situe votre projet : demandez combien de temps il faudrait pour servir vos cas d'usage avec un autre modèle. Si la réponse se compte en jours, vous avez un harnais. Si elle se compte en trimestres, vous avez une intégration.

Trois années, trois déplacements de l'effort

En 2023, l'effort d'ingénierie portait sur le prompt : formuler la bonne demande, dans le bon ordre, avec les bons exemples. En 2024, il s'est déplacé vers la gestion du contexte : choisir ce qu'on met dans la fenêtre, ce qu'on résume, ce qu'on écarte, et selon quelle politique. En 2026, il porte sur la conception de la boucle.

La différence est de nature. Le prompt et le contexte concernent un appel ; la boucle concerne l'enchaînement des appels, ce qui se passe entre eux, et la manière dont le système se rattrape quand l'un d'eux échoue. La logique de ce déplacement est simple : à mesure que les modèles deviennent bons, le facteur limitant cesse d'être leur capacité et devient l'organisation de leur travail.

L'été 2026 a vu cinq architectures concurrentes de harnais être publiées en trois semaines. Quand cinq équipes indépendantes publient au même moment sur le même problème, ce n'est pas une coïncidence : c'est le signe qu'un sujet a quitté le laboratoire pour entrer dans l'ingénierie industrielle. Le principe le plus radical de cette série, poussé par DeepSeek, consiste à faire de tout un plugin, y compris de la boucle elle-même : le noyau n'impose aucune capacité, il se contente de résoudre les dépendances entre les composants qu'on lui déclare. C'est une position d'architecture, et elle est instructive pour un acheteur, car elle dit que même la boucle de décision doit pouvoir être remplacée.

Les leviers de la boucle

Cinq leviers font l'essentiel de l'écart. L'ordonnancement décide de la séquence : quand appeler le modèle, quand appeler un outil, quand s'arrêter. C'est le plus rentable et le plus négligé. Les sous-agents délèguent une tâche bornée à un contexte séparé, dont seul le résultat remonte, ce qui évite la pollution du contexte principal, première cause de dégradation des systèmes agentiques longs. L'isolation des espaces de travail donne à chaque tâche son bac à sable, ses fichiers, ses permissions et sa durée de vie. Le chargement des compétences à la demande évite de décrire au modèle l'intégralité de ce qu'il pourrait faire, ce qui réduit le coût et améliore la précision. La mémoire persistante, enfin, conserve ce qui a été appris entre deux exécutions : c'est le levier qui transforme un système qui recommence à zéro en un système qui s'améliore.

S'y ajoute un changement d'approche. La première génération de systèmes agentiques exposait au modèle une liste d'outils, à charge pour lui de sélectionner le bon. Cette méthode se heurte à une explosion combinatoire dès que le nombre d'outils dépasse quelques dizaines : le modèle passe l'essentiel de son effort à choisir, et non à raisonner. L'approche qui s'impose consiste à le laisser écrire du code qui appelle ces outils, dans un environnement d'exécution contrôlé. Le prix à payer est une exigence d'isolation sérieuse : faire écrire du code à un modèle sans bac à sable strict n'est pas une architecture, c'est un incident en préparation.

Pourquoi le harnais est un actif et le modèle un consommable

Un modèle a une durée de vie utile de l'ordre de dix-huit mois. Il sera remplacé, par un meilleur, par un moins cher, ou par les deux. Personne ne construit un patrimoine sur un composant dont on sait à l'avance qu'il sera périmé avant le prochain plan.

Le harnais, lui, accumule. Les descriptions d'outils écrites pour vos systèmes internes, les procédures qui encodent la façon dont votre organisation traite un dossier, les jeux d'évaluation constitués sur vos données réelles, les corrections apportées après chaque incident, la mémoire des cas déjà traités : tout cela est du travail spécifique, coûteux à produire, et qui ne se retrouve nulle part ailleurs.

La question d'achat qui en découle est simple. Si votre logique métier est dissoute dans des instructions envoyées à un modèle propriétaire, changer de fournisseur signifie tout réécrire, et le coût de sortie est prohibitif. Si elle est portée par un harnais dont vous maîtrisez le code, changer de modèle est une opération de configuration. La même dépense, engagée au même moment, produit dans un cas une dépendance et dans l'autre un actif.

Trois choix indépendants, et une bonne nouvelle pour l'Europe

Le harnais peut être d'origine chinoise, le modèle européen et le déploiement souverain. Ces trois choix sont indépendants les uns des autres, et c'est précisément ce qui rend l'interopérabilité stratégique plutôt que technique. La recommandation qui en découle n'est pas de choisir le bon runtime : elle est de refuser d'en dépendre d'un seul. Un harnais qui exige son propre fournisseur de modèles, son propre magasin d'outils et son propre format de mémoire n'est pas une couche d'abstraction, c'est une nouvelle dépendance présentée comme la solution au problème de dépendance.

Pour l'Europe, ce constat est une bonne nouvelle qu'on entend peu. La couche où se joue désormais la performance est de l'ingénierie logicielle classique, sans barrière capitalistique comparable à celle de l'entraînement. Elle s'écrit, se teste, s'audite et se déploie comme n'importe quel système critique. C'est un terrain sur lequel nous avons des équipes, des méthodes et une culture du logiciel ouvert, et c'est très concrètement la couche que nous produisons en commun ouvert.

C'est aussi la couche qui décide de la fiabilité des agents qui tournent sans supervision directe, donc celle qui conditionne leur acceptabilité dans les administrations et les entreprises exposées. Une boucle auditable, dont chaque décision est journalisée et rejouable, n'est pas seulement une bonne pratique d'ingénierie : c'est la condition pour documenter un système au sens de l'AI Act, et pour répondre à la question la plus simple et la plus redoutable qu'un contrôleur puisse poser, celle de savoir pourquoi ce système a fait cela.