En bref
Depuis l'arrivée des LLM, l'attention s'est focalisée sur le modèle : GPT-5, Claude, Gemini, Qwen. Mais en production, le vrai levier de fiabilité n'est plus le modèle — c'est tout ce qu'il y a autour. Contexte, outils, workflow, validation, garde-fous, observabilité. C'est ce qu'on appelle le harness, et sa conception est une discipline à part entière : le Harness Engineering.
Chez VOID, on a construit un premier harness en 100% on-premise pour automatiser les mises à jour de sécurité, testé sur du code open source et nos propres projets internes. Stack : Autogit (open source), Ollama servant un Qwen3.5-27B, le tout sur une Nvidia RTX PRO 6000. Ce retour d'expérience nous a rappelé une vérité simple : sans boucle de feedback automatisée, un agent IA n'a rien à faire en production.
1. Le piège du "on a branché GPT, ça va marcher"
Tout le monde a vu ce scénario. Une entreprise connecte un LLM à son système d'information. Premiers tests enthousiasmants en démo. Mise en production. Et là, l'agent commence à halluciner des références, à ignorer des consignes critiques ("ne jamais toucher à la base de prod"), à faire exactement l'inverse de ce qu'on lui a demandé.
Diagnostic habituel : "le modèle n'est pas assez bon, attendons la prochaine génération." Faux. 90% du temps, ce n'était pas un problème de modèle. C'était un problème de harness.
L'erreur la plus fréquente
Croire qu'un LLM, livré seul, est capable de tenir des engagements en production. Un modèle brut n'a pas de mémoire persistante, pas de garde-fous, pas d'outils vérifiés, pas de boucle de rattrapage. Il improvise. En production, improviser n'est pas une option.
2. Qu'est-ce qu'un harness en IA ?
Le mot harness — littéralement "harnais" ou "attelage" — désigne en ingénierie IA tout ce qu'il y a autour du modèle pour le rendre utile et fiable. Le LLM est le moteur. Le harness, c'est le châssis, la direction, les freins, le tableau de bord.
Les composants d'un harness
Plusieurs produits grand public qu'on utilise tous les jours sont en fait des harnesses autour d'un ou plusieurs LLM :
- Cursor / Claude Code : un harness pour coder
- Devin (Cognition) : un harness pour développer en autonomie
- Perplexity : un harness pour rechercher sur le web
- Harvey : un harness pour le droit
- GitHub Copilot : un harness pour l'autocomplétion dans l'IDE
La question qu'on se pose dans le Harness Engineering n'est donc pas "quel modèle choisir ?", mais "quel environnement concevoir autour du modèle pour qu'il réalise la tâche de façon fiable, traçable et gouvernée ?"
3. Clarification du vocabulaire
Le domaine bouge vite et plusieurs termes circulent, souvent confondus. Pour cadrer les discussions, voici les distinctions utiles :
| Terme | Ce que ça désigne | Popularisé par |
|---|---|---|
| Harness / AI Harness | L'infrastructure logicielle autour du LLM (tools, mémoire, validation, workflow) | Anthropic, Cursor, Devin |
| Context Engineering | La discipline de concevoir ce qu'on donne à l'agent (contexte, docs, specs) | Andrej Karpathy (2024) |
| Agent / Agentic Engineering | Concevoir le workflow complet de l'agent (plan, exec, verify) | Communauté open-source |
| Prompt Engineering | (ancien) écrire les bons prompts — encore utile, mais insuffisant | 2023 |
| Steering | Guider / contraindre le modèle à suivre les directives, y compris quand il a tendance à les oublier | Recherche Anthropic / OpenAI |
| Scaffolding | Les "rails" qu'on met autour de l'agent pour canaliser son comportement | Papers académiques |
| Skills / Tool use | Les capacités qu'on donne à l'agent (fonctions exposées, MCP, outils) | OpenAI, Anthropic, MCP |
Glossaire du Harness Engineering
- Ce que ça désigne
- L'infrastructure logicielle autour du LLM (tools, mémoire, validation, workflow)
- Popularisé par
- Anthropic, Cursor, Devin
- Ce que ça désigne
- La discipline de concevoir ce qu'on donne à l'agent (contexte, docs, specs)
- Popularisé par
- Andrej Karpathy (2024)
- Ce que ça désigne
- Concevoir le workflow complet de l'agent (plan, exec, verify)
- Popularisé par
- Communauté open-source
- Ce que ça désigne
- (ancien) écrire les bons prompts — encore utile, mais insuffisant
- Popularisé par
- 2023
- Ce que ça désigne
- Guider / contraindre le modèle à suivre les directives, y compris quand il a tendance à les oublier
- Popularisé par
- Recherche Anthropic / OpenAI
- Ce que ça désigne
- Les "rails" qu'on met autour de l'agent pour canaliser son comportement
- Popularisé par
- Papers académiques
- Ce que ça désigne
- Les capacités qu'on donne à l'agent (fonctions exposées, MCP, outils)
- Popularisé par
- OpenAI, Anthropic, MCP
Dans ce qui suit, on emploie "Harness Engineering" comme terme parapluie. Tous les autres sont des sous-disciplines ou des techniques qui s'y rattachent.
4. Les 6 piliers d'un bon harness
Construire un harness, ce n'est pas empiler des outils. C'est traiter six préoccupations distinctes, et aucune n'est optionnelle en production.
Context Engineering — donner à l'agent ce dont il a besoin
Documentation métier, specs produit, historique des décisions, RAG bien indexé, référentiels internes. Un agent sans contexte pertinent produira du générique — au mieux inutile, au pire faux.
Principe : "garbage in, garbage out", puissance 10.
Skills & Tools — donner les bons outils
Fonctions exposées, API internes, commandes CLI, accès en lecture/écriture à un périmètre précis. Le Model Context Protocol (MCP) s'impose comme standard pour connecter agents et outils.
Principe : l'agent ne peut faire que ce qu'on lui autorise explicitement à faire.
Workflow — orchestrer les étapes
Planning → exécution → vérification → rattrapage. Les patterns qui marchent : ReAct, Chain-of-Thought, Tree-of-Thoughts, boucles agentiques. Pour les tâches complexes, on décompose en plusieurs agents (planner, executor, critic).
Principe : un agent sans workflow dérive.
Validation loops — vérifier avant de commit
Self-critique, evals automatisés, human-in-the-loop sur les actions critiques. C'est ici que les tests automatisés (unitaires, intégration, E2E Playwright) prennent tout leur sens.
Principe : un agent qui vérifie son travail vaut mieux qu'un agent plus grand.
Steering & Guardrails — tenir les directives
C'est la réponse à la question frustrante : "Pourquoi l'agent fait-il le contraire de ce que j'ai demandé ?" Techniques : system prompts renforcés, constitutional AI, output parsing strict, règles métier en dehors du LLM.
Anti-pattern : tout mettre dans le prompt et croire que ça va tenir. Les contraintes critiques doivent être dans du code déterministe.
Observabilité — savoir ce que fait l'agent
Traces (LangSmith, Langfuse, Arize), logs des outils appelés, métriques : taux de succès, hallucination rate, coût par tâche, temps d'exécution. Sans ça, on ne peut ni debugger, ni améliorer.
Principe : on ne gère pas ce qu'on ne mesure pas.
Context Engineering — donner à l'agent ce dont il a besoin
Documentation métier, specs produit, historique des décisions, RAG bien indexé, référentiels internes. Un agent sans contexte pertinent produira du générique — au mieux inutile, au pire faux.
Principe : "garbage in, garbage out", puissance 10.
Skills & Tools — donner les bons outils
Fonctions exposées, API internes, commandes CLI, accès en lecture/écriture à un périmètre précis. Le Model Context Protocol (MCP) s'impose comme standard pour connecter agents et outils.
Principe : l'agent ne peut faire que ce qu'on lui autorise explicitement à faire.
Workflow — orchestrer les étapes
Planning → exécution → vérification → rattrapage. Les patterns qui marchent : ReAct, Chain-of-Thought, Tree-of-Thoughts, boucles agentiques. Pour les tâches complexes, on décompose en plusieurs agents (planner, executor, critic).
Principe : un agent sans workflow dérive.
Validation loops — vérifier avant de commit
Self-critique, evals automatisés, human-in-the-loop sur les actions critiques. C'est ici que les tests automatisés (unitaires, intégration, E2E Playwright) prennent tout leur sens.
Principe : un agent qui vérifie son travail vaut mieux qu'un agent plus grand.
Steering & Guardrails — tenir les directives
C'est la réponse à la question frustrante : "Pourquoi l'agent fait-il le contraire de ce que j'ai demandé ?" Techniques : system prompts renforcés, constitutional AI, output parsing strict, règles métier en dehors du LLM.
Anti-pattern : tout mettre dans le prompt et croire que ça va tenir. Les contraintes critiques doivent être dans du code déterministe.
Observabilité — savoir ce que fait l'agent
Traces (LangSmith, Langfuse, Arize), logs des outils appelés, métriques : taux de succès, hallucination rate, coût par tâche, temps d'exécution. Sans ça, on ne peut ni debugger, ni améliorer.
Principe : on ne gère pas ce qu'on ne mesure pas.
Déterministe vs non-déterministe
La frontière entre ce qu'on délègue au LLM et ce qui doit rester dans du code classique.
Résultat toujours identique
Même entrée, même résultat. Reproductible, auditable, testable.
Code métier, règles SQL, API classiques, tests unitaires, guardrails.
Résultat variable
Même entrée, résultat qui peut varier. Créatif, utile pour le langage, mais imprévisible.
LLM (GPT, Claude, Qwen), génération d'images, résumés, raisonnement.
Résultat toujours identique
Même entrée, même résultat. Reproductible, auditable, testable.
Code métier, règles SQL, API classiques, tests unitaires, guardrails.
Résultat variable
Même entrée, résultat qui peut varier. Créatif, utile pour le langage, mais imprévisible.
LLM (GPT, Claude, Qwen), génération d'images, résumés, raisonnement.
Exemple : règle de remboursement bancaire
Règle : "Jamais de remboursement > 5 000 MAD sans escalade humaine."
Règle dans le prompt :
"Ne valide jamais > 5 000 MAD sans escalade."
→ Un jour, le LLM validera 8 000 MAD. Rare, mais ça arrivera. Et 1% de cas = catastrophe.
Règle dans le code :
if (montant > 5000) {
escaladerVersHumain();
}
→ Impossible à contourner. Le code ne dérive jamais.
Règle dans le prompt :
"Ne valide jamais > 5 000 MAD sans escalade."
→ Un jour, le LLM validera 8 000 MAD. Rare, mais ça arrivera. Et 1% de cas = catastrophe.
Règle dans le code :
if (montant > 5000) {
escaladerVersHumain();
}
→ Impossible à contourner. Le code ne dérive jamais.
La règle d'or du Harness
Critique → déterministe. Créatif → non-déterministe. Le harness fait la séparation.
5. Les 3 pièges qui font échouer les projets agent IA
"Le modèle est assez intelligent, pas besoin de workflow"
Faux. Même GPT-5 ou Claude Opus dérivent sans scaffolding. Plus la tâche est sensible, plus le workflow est critique.
"On met toutes les règles dans le prompt"
Le prompt est non-déterministe : il dérive. Les contraintes critiques (sécurité, montants, droits) doivent être en dehors du LLM, dans du code déterministe qui l'encadre. C'est la règle d'or.
"On évaluera en production"
Trop tard. Il faut une suite d'evals avant production, comme des tests unitaires — avec des cas nominaux, des cas limites et des cas adversariaux.
6. Retour d'expérience VOID : un agent de mise à jour de sécurité 100% souverain
La leçon qu'on voudrait que tout le monde retienne
Un agent IA qui corrige du code sans pouvoir tester son travail, c'est pire que pas d'agent. Avant de déployer un agent IA sur un projet, la priorité n'est pas le modèle, ni le framework d'orchestration, ni les prompts.
La priorité, c'est la boucle de feedback : tests unitaires, tests d'intégration, tests E2E Playwright. Chez VOID, on a inversé notre approche — on cadre et on met à niveau les tests automatisés avant de parler d'agent IA.
Le contexte
Sur nos missions de TMA et d'infogérance AWS, on observe une réalité récurrente : la dette de sécurité s'accumule plus vite qu'elle ne se résorbe. CVE sur dépendances NPM / Python / Java, patches OS, vulnérabilités containers. Chaque semaine, des dizaines d'alertes. Les équipes produit avancent sur les features, la dette grossit.
Beaucoup d'environnements régulés — typiquement banques, assurances, administrations — imposent une contrainte non-négociable : le code ne doit jamais sortir de l'infrastructure. Exit les solutions SaaS type Copilot, Cursor ou Dependabot Premium. Il faut un agent IA souverain, tournant entièrement en on-premise.
On a donc voulu valider le concept de bout en bout avant toute industrialisation. Pour cela, on a mené le pilote sur du code open source et sur nos propres projets internes VOID, jamais sur du code client. Objectif : prouver la faisabilité et mesurer les limites d'un agent IA souverain qui détecte les vulnérabilités, corrige le code, exécute les tests, crée une PR — le tout sans qu'aucun octet ne quitte l'infra.
Ce qui suit est le retour d'expérience brut de ce pilote : les choix techniques, les résultats, et surtout les enseignements qu'on applique désormais à tous nos projets.
Le stack 100% on-premise
Après plusieurs itérations, on a convergé sur une architecture intégralement self-hosted :
| Composant | Choix | Rôle |
|---|---|---|
| Orchestration | Autogit (open source, self-hosted) | Détection CVE, pilotage workflow, interaction Git |
| Serveur d'inférence | Ollama | Sert le modèle localement |
| Modèle | Qwen3.5-27B | Raisonnement code, génération de fix |
| Hardware | Nvidia RTX PRO 6000 (Blackwell) | Carte pro, 96 GB VRAM, idéale pour un 27B en local |
| Scan vulnérabilités | Trivy / Snyk CLI | Détection CVE |
| Tests E2E | Playwright + suite unit/intégration existante | Boucle de feedback — pas de PR sans tests verts |
| Plateforme Git | GitHub / GitLab API | Création PR |
Stack technique 100% on-premise
- Rôle
- Détection CVE, pilotage workflow, interaction Git
- Choix
- Ollama
- Rôle
- Sert le modèle localement
- Choix
- Qwen3.5-27B
- Rôle
- Raisonnement code, génération de fix
- Choix
- Nvidia RTX PRO 6000 (Blackwell)
- Rôle
- Carte pro, 96 GB VRAM, idéale pour un 27B en local
- Choix
- Trivy / Snyk CLI
- Rôle
- Détection CVE
- Choix
- Playwright + suite unit/intégration existante
- Rôle
- Boucle de feedback — pas de PR sans tests verts
- Choix
- GitHub / GitLab API
- Rôle
- Création PR
Le bénéfice clé : souveraineté totale
Aucun appel sortant. Aucune API LLM tierce. Aucune donnée exfiltrée. Le code ne sort jamais de son environnement d'origine. Stack auditable de bout en bout par un RSSI, prêt à être répliqué dans une infrastructure régulée.
L'architecture du harness
| Pilier | Mise en œuvre |
|---|---|
| Contexte | Repo complet + historique des PR + documentation interne |
| Tools | Git, Trivy/Snyk, test runner, API GitHub/GitLab |
| Workflow | Detect CVE → localize code → draft fix → run tests → create PR |
| Validation | Tests unitaires + intégration + E2E Playwright. Pas de PR si tests rouges |
| Guardrails | Branche dédiée. Jamais de merge auto. Revue humaine obligatoire |
| Observabilité | Logs de chaque run, taux de PR acceptées, temps moyen de correction |
Architecture du harness — mise en correspondance avec les 6 piliers
- Mise en œuvre
- Repo complet + historique des PR + documentation interne
- Mise en œuvre
- Git, Trivy/Snyk, test runner, API GitHub/GitLab
- Mise en œuvre
- Detect CVE → localize code → draft fix → run tests → create PR
- Mise en œuvre
- Tests unitaires + intégration + E2E Playwright. Pas de PR si tests rouges
- Mise en œuvre
- Branche dédiée. Jamais de merge auto. Revue humaine obligatoire
- Mise en œuvre
- Logs de chaque run, taux de PR acceptées, temps moyen de correction
Ce qui a marché
- ✓Fixes triviaux (bumps de patch version, mises à jour mineures, CVE bien documentées) : excellents résultats. Qwen3.5-27B en local gère parfaitement.
- ✓Tests de non-régression générés par l'agent sur les fonctions impactées par la mise à jour. Pas parfait, mais souvent meilleur que "rien".
- ✓Documentation de la PR claire (CVE concerné, portée du fix, tests ajoutés). Gain de temps considérable pour le reviewer.
- ✓Souveraineté : zéro donnée envoyée à un tiers. Stack intégralement auditable par un RSSI.
Ce qui a moins marché
- ⚠Breaking changes entre majors : en autonomie pure, l'agent fixe en aveugle un v2 → v3 et casse la compilation — il ne saisit pas l'impact métier. Notre réponse n'a pas été de bannir les majors, mais de spécialiser le harness : des actions Autogit dédiées avec prompts enrichis (guide de migration officiel scrapé, changelog, diff d'API, checklist d'impact) orientent l'agent sur ces cas. Workflow plus lent, review humaine obligatoire. Le mode "autonome léger" reste réservé aux minors et patches. C'est exactement le message de l'article : ce n'est pas le modèle qu'on change, c'est le harness qu'on adapte au niveau de risque.
- ⚠Dépendances transitives complexes (peer dependencies NPM imbriquées) : l'agent se perd, n'arrive pas à remonter la chaîne quand la mise à jour casse indirectement une autre dépendance.
- ⚠Génération autonome de tests E2E Playwright : non. L'agent sait exécuter la suite Playwright existante et s'en servir comme signal de validation, mais il ne sait pas écrire seul un scénario E2E pertinent (sélecteurs stables, data-testid, assertions métier). Les tests Playwright restent produits en mode co-pilote (développeur + agent, type Cursor / Copilot), pas en autonomie. C'est précisément pour ça qu'on audite et qu'on met à niveau le test harness avant de déployer l'agent autonome.
- ⚠Qwen3.5-27B vs un modèle frontier : en reasoning pur, on sent l'écart avec GPT-5 ou Claude Opus. Mais pour ce use case précis (patterns répétitifs, code localisé, tests comme signal), Qwen3.5-27B est largement suffisant. Et c'est le prix de la souveraineté.
Les 6 leçons qu'on retient
Sans feedback loop automatisée, pas de production
Après nos premiers tests, un constat brutal : un agent qui corrige du code mais ne peut pas vérifier que ça marche, c'est un agent qui fabrique des bombes à retardement. La seule variable qui fait la différence entre un pilote sympa et un déploiement réel, c'est la qualité de la boucle de feedback — tests unitaires, intégration, et surtout E2E automatisés (Playwright, Cypress). Notre règle désormais : avant même de parler d'agent IA, on audite et on remet à niveau le harness de tests.
Le scope est tout
On a voulu au départ que l'agent couvre "toutes les mises à jour". Échec. En se limitant aux minor / patch et aux CVE documentées, on obtient un taux d'acceptation élevé et une relation de confiance avec les reviewers.
Le test est la vraie valeur
Un agent qui propose un fix sans le tester, c'est Dependabot. Un agent qui exécute les tests avant de pousser la PR, c'est un vrai collègue. La boucle de validation, c'est ce qui sépare un outil d'un agent.
Never auto-merge
On a techniquement la capacité de faire merger automatiquement les PR dont les tests passent. On ne le fait pas. Un humain valide, toujours. C'est un choix de gouvernance, pas une limite technique.
Souveraineté = architecture, pas marketing
Quand un contexte réglementaire impose que "les données ne doivent pas sortir", ça ne se résout pas avec un NDA. Ça se résout avec une architecture. Ollama + Qwen + Autogit open source sur une GPU locale = une réponse concrète, auditable, défendable.
L'observabilité n'est pas optionnelle
On mesure chaque semaine : PR proposées, PR mergées, PR rejetées, raisons des rejets. Sans ça, impossible de savoir si l'agent progresse ou si le harness dérive.
7. Quel stack harness en 2026 ?
Le paysage outillage change vite. Voici ce qu'on recommande aujourd'hui selon le besoin :
| Besoin | Outils |
|---|---|
| Orchestration agent | LangGraph, CrewAI, AutoGen, OpenAI Agents SDK, Autogit |
| Tool protocol | MCP (Model Context Protocol) — standard en train de s'imposer |
| Serveur modèle local | Ollama, vLLM, TGI |
| Modèles open-source | Qwen3.5, Llama 3.3, Mistral, DeepSeek |
| Feedback loop (tests) | Playwright, Cypress, Vitest, Jest, Pytest, JUnit |
| Evals | Braintrust, Langfuse, Promptfoo |
| Observabilité | LangSmith, Arize, Helicone, Langfuse |
| Guardrails | Guardrails.ai, NeMo Guardrails |
| RAG | LlamaIndex, Haystack, Vectara |
Stack harness recommandé en 2026
- Outils
- LangGraph, CrewAI, AutoGen, OpenAI Agents SDK, Autogit
- Outils
- MCP (Model Context Protocol) — standard en train de s'imposer
- Outils
- Ollama, vLLM, TGI
- Outils
- Qwen3.5, Llama 3.3, Mistral, DeepSeek
- Outils
- Playwright, Cypress, Vitest, Jest, Pytest, JUnit
- Outils
- Braintrust, Langfuse, Promptfoo
- Outils
- LangSmith, Arize, Helicone, Langfuse
- Outils
- Guardrails.ai, NeMo Guardrails
- Outils
- LlamaIndex, Haystack, Vectara
8. Ce qu'on retient
- →Le modèle n'est plus le bottleneck. Le harness l'est.
- →Construire un agent IA en production = 20% prompt, 80% ingénierie autour.
- →Les projets IA qui échouent sont presque toujours des problèmes de harness, pas de modèle.
- →Sans boucle de feedback automatisée (tests unitaires + E2E Playwright), un agent IA n'a rien à faire en production.
- →La souveraineté n'est pas une option marketing. C'est une architecture — et elle est atteignable avec un stack open source.
- →Règle d'or : ce qui est critique doit être déterministe, ce qui est créatif peut être non-déterministe. Le harness fait la séparation.
Envie d'explorer un agent IA dans votre delivery ?
Chez VOID, on commence toujours par la boucle de feedback. Trois portes d'entrée, selon votre maturité :
Audit de testabilité
Évaluation de la couverture et de la qualité de vos tests automatisés.
Mise à niveau test harness
Installation de la suite Playwright / unit / intégration qui permettra l'agent IA.
Cadrage agent IA
Une fois les tests en place, on conçoit le scaffolding agentique, en souverain si besoin.
Cet article vous a été utile ?
Partagez-le à votre réseau — en particulier aux équipes qui s'apprêtent à déployer un agent IA en production.
Approfondir le sujet
Articles liés
NVIDIA DGX Spark : Révolution Desktop ou Gadget Hype ? Analyse Production 2025
Analyse technique complète du NVIDIA DGX Spark (Grace Blackwell GB10, 128GB, 1 PFLOP). Benchmarks réels LMSYS, goulot bande passante mémoire, limites clustering, et guide dimensionnement infrastructure IA souveraine pour production au Maroc.
Agent IA : guide complet 2025 (agents autonomes, LangChain, AutoGPT, multi-agents)
Découvrez les agents IA : définition, architecture, comparaison avec ChatGPT, frameworks (LangChain, AutoGPT, CrewAI), cas d'usage concrets et développement d'agents intelligents autonomes.
Drupal comme serveur MCP : piloter son CMS par IA (Claude, ChatGPT, Cursor)
Transformer Drupal en serveur MCP pour permettre à Claude, ChatGPT ou Cursor de créer des contenus, uploader des médias et gérer le workflow éditorial. Module custom, routes, sécurité.
Apps ChatGPT & Model Context Protocol : Développement avec Next.js (Guide Développeur 2026)
Guide complet création d'apps ChatGPT avec MCP et Next.js. Architecture backend, widgets interactifs, intégration OpenAI SDK. Tutoriel technique développeur.
Agile Delivery : Au-delà de la Vitesse, la Performance Stratégique
L'agilité ne se résume pas à livrer vite, mais à livrer juste. Découvrez comment transformer votre Delivery opérationnel en véritable levier de performance stratégique : alignement, gouvernance, feedback, transparence.
KYC & Onboarding Digital pour Banques au Maroc | Solution Sumsub
Sécurisez et accélérez l'onboarding digital de vos clients bancaires avec Sumsub : vérification d'identité, liveness detection, screening AML. Conforme aux réglementations marocaines.