Agent = Model + Harness : pourquoi un harness production-ready fait la vraie différence
Quand un agent IA échoue en conditions réelles, la première réaction est presque toujours « il nous faut un meilleur modèle ». C'est un mauvais diagnostic. Dans la grande majorité des cas, le problème ne vient pas du modèle — il raisonne brillamment. Le problème vient du harness : l'infrastructure logicielle autour du modèle, qui le transforme de quelque chose qui répond en quelque chose qui agit de manière fiable.
C'est aussi la formule sur laquelle nous nous appuyons :
Agent = Model + Harness
Un même modèle, mais un meilleur harness — de meilleurs résultats. C'est là qu'OpenKBS est fort : nous construisons un harness production-ready, scalable et secure. Cette publication explique ce que cela signifie, pourquoi cela compte pour l'entreprise et comment les deux couches — le modèle et le harness — se recouvrent dans la plateforme.
Qu'est-ce qu'un harness, au fond
Si le modèle est le cerveau, le harness est le corps. Le cerveau peut penser, mais sans corps il ne peut rien saisir, ouvrir une porte ni vérifier le résultat de son action. Le harness est tout ce qui se trouve entre « le modèle a décidé quoi faire » et « l'action s'est produite de manière sûre, traçable et reproductible » :
- les outils (tools) que le modèle peut invoquer ;
- l'environnement isolé (sandbox) dans lequel le code s'exécute ;
- la mémoire et le stockage, qui survivent entre les sessions ;
- les boucles de rétroaction (feedback loops), qui permettent à l'agent de voir le résultat et de se corriger ;
- les guardrails — les limites qui empêchent l'agent de nuire ;
- l'observabilité (observability), qui fournit une piste d'audit pour chaque action.
Le modèle en lui-même est stateless — il reçoit du texte et renvoie du texte. Tout le reste, ce qui rend un agent utile en production, c'est le harness.
Pourquoi la plupart des échecs viennent du harness, pas du modèle
C'est l'intuition clé : la plupart des échecs opérationnels des agents IA viennent du harness, pas du modèle lui-même. Les symptômes typiques n'ont rien à voir avec l'intelligence du modèle :
- Context rot — le contexte déborde ou se pollue et le modèle perd le fil ;
- Tool overload — trop d'outils, mal décrits, entre lesquels le modèle se perd ;
- Câblage fragile — des intégrations assemblées à la main qui cassent au premier changement ;
- Latence — chaque étape passe par des sauts réseau superflus ;
- Récupération non pertinente — la mémoire renvoie le mauvais contexte ;
- Vérification faible — l'agent ne vérifie pas le résultat de son action ;
- Guardrails manquants — rien n'arrête l'agent lorsqu'il se trompe.
Aucun de ces problèmes ne se résout en changeant de modèle. Tous se résolvent avec un meilleur harness. C'est pourquoi un harness solide rend les modèles moyens utiles, tandis qu'un harness faible gaspille même les meilleurs.
Couche 1 — Le modèle : la confiance grâce au zero data retention
Nous ne fabriquons pas de modèles. Et c'est un choix délibéré : les meilleurs modèles changent tous les quelques mois, et être verrouillé chez un seul fournisseur est un risque stratégique. À la place, nous donnons accès à tous les grands fournisseurs — OpenAI, Anthropic, Google — via un proxy IA unique, déployé sur notre infrastructure européenne.
La différence réside dans les conditions dans lesquelles cela se produit :
- Zero data retention. Les requêtes passent par les fournisseurs sous des accords de non-conservation des données — rien n'est journalisé, rien n'est conservé et rien n'est utilisé pour entraîner des modèles. Les données du client ne restent pas chez le fournisseur.
- Sans clés API à gérer. Le client ne jongle pas avec des clés OpenAI, Anthropic et Google — l'accès passe par un identifiant unique et une seule facturation en crédits.
- Consolidation de la chaîne d'approvisionnement. Au lieu d'un contrat distinct, d'une évaluation des risques distincte et d'un audit distinct pour chaque fournisseur d'IA, le client travaille avec un seul fournisseur. Pour les secteurs régulés, c'est un avantage direct au regard de NIS2 et de l'AI Act — drastiquement moins de fournisseurs à évaluer.
Autrement dit : les modèles, tout le monde en propose. Nous résolvons la partie qui pèse vraiment en environnement enterprise — la confiance.
Couche 2 — Le harness : c'est là notre force
Un harness de production se compose de blocs de construction reconnaissables. La force d'OpenKBS, c'est que chacun d'eux est réalisé sur une infrastructure managée, isolée et certifiée — non pas comme un prototype assemblé à la main, mais comme une plateforme.
| Bloc de construction du harness | Réalisation dans OpenKBS |
|---|---|
| System prompts / contexte | Fonctions Lambda — le contexte et la logique sont du code, versionné à chaque déploiement |
| Tools (outils) | Project API : workers, S3, e-mail, MQTT, base de données — des outils prêts à l'emploi que l'agent invoque |
| Sandboxes (isolation) | Isolation Lambda microVM + compte AWS dédié par client + workers EC2 à la demande pour les tâches lourdes |
| Filesystem | Stockage objet S3 avec presigned URLs — limitées dans le temps et la portée |
| Memory (mémoire) | PostgreSQL managé (Aurora/Neon), point-in-time restore jusqu'à 35 jours, 6 copies réparties sur 3 zones |
| Feedback loops | Agent loop dans Lambda : tool_use → exécution → observation → répétition et correction |
| Guardrails | Isolation multi-tenant, secrets injectés, limites de crédits, OWASP security audit, AES-256 / TLS 1.2+ |
| Observability | Logs CloudWatch, logs des workers, usage collector, journal d'audit administratif |
| Accès aux modèles | Proxy IA — tous les fournisseurs, zero retention, facturation unifiée, sans gestion de clés |
Ce n'est pas une liste d'ambitions — c'est l'infrastructure qui sous-tend déjà chaque projet de la plateforme. Le développeur part d'un harness prêt à l'emploi, au lieu de l'assembler de zéro pour chaque agent.
Scalable par défaut
Les fonctions Lambda passent automatiquement de zéro à des milliers d'exécutions simultanées. Les tâches lourdes (traitement vidéo, ML, batch) sont confiées à des workers à la demande facturés à la seconde. La base de données choisit le bon moteur selon la charge. Aucune planification de capacité et aucun serveur à maintenir.
Secure par conception
Chaque client est physiquement isolé au niveau du compte AWS — une frontière dure, imposée par AWS IAM, et non une séparation logique. Les secrets sont injectés au déploiement, jamais dans le code. L'accès passe par JWT et des clés par projet à rotation automatique. Chaque nouvelle version passe par un audit de sécurité structuré.
Production-ready signifie compliant
Dans un environnement européen régulé, « harness production-ready » a une autre signification : harness compliant. Ici, la force du harness et la conformité réglementaire se confondent.
- EU data residency — toutes les ressources sont par défaut dans la région AWS eu-central-1 (Francfort). Les données ne quittent pas l'UE.
- Certifications héritées — l'infrastructure s'appuie sur AWS avec plus de 150 certifications auditées de manière indépendante (ISO/IEC 27001, SOC 2 Type II, C5 du BSI), y compris l'appartenance à l'infrastructure critique allemande (KRITIS).
- Security audit à chaque version — analyse statique pour l'OWASP Top 10, vérification des injections SQL, XSS, CSRF, SSRF, command injection et vulnérabilités CVE avant la mise en production ; les rapports sont accessibles au régulateur.
- Compte dédié et transférable — à la résiliation du contrat, l'intégralité du compte AWS est transférée au client. Rien à migrer, aucun format propriétaire, aucun vendor lock-in.
Le même harness qui rend les agents fiables les rend aussi auditables. Les détails sur NIS2 et l'AI Act sont décrits dans nos publications dédiées — NIS2 et la transformation IA du secteur manufacturier et L'AI Act et la conformité pour les entreprises.
Ce que cela signifie pour l'entreprise
La plupart des entreprises aujourd'hui ne construisent pas un seul agent IA. Elles en construisent des dizaines. Et sans infrastructure commune, cela se transforme rapidement en agent sprawl — des agents dispersés et déconnectés qu'aucune équipe ne peut gérer, auditer ou maintenir de manière fiable.
Le harness partagé et production-ready résout exactement ce problème :
- De la démo à la production. Le prototype qui tourne sur un ordinateur portable et le système qui encaisse un trafic réel en environnement régulé sont deux choses différentes. La différence, c'est le harness.
- Governance. Un seul endroit pour l'observabilité, les secrets, les limites et l'audit — au lieu que chaque agent réinvente la roue.
- Vitesse sans prise de risque. Les équipes se concentrent sur la logique de l'agent, et non sur l'isolation, la mise à l'échelle et la conformité — qui arrivent clés en main.
La conclusion est simple : le succès en production exige de traiter l'ingénierie du harness comme une discipline à part entière, aussi importante que le choix du modèle. C'est la discipline dans laquelle OpenKBS est fort.
Prochaine étape
Si votre organisation passe des prototypes IA à de véritables agents en production — en particulier dans un secteur régulé — contactez-nous. Nous examinerons votre cas concret et vous montrerons à quoi ressemble un harness production-ready pour votre entreprise : isolé, scalable, secure et compliant par défaut.
Les services enterprise décrits — compte AWS dédié, audit de sécurité et revue de code généré par IA — font partie du plan Enterprise d'OpenKBS.
La présente publication a un caractère informatif et ne constitue pas un conseil juridique.