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 (notre outil d'orchestration interne VOID, en cours d'open sourcing), 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.
« Early progress was slower than we expected, not because Codex was incapable, but because the environment was underspecified. The agent lacked the tools, abstractions, and internal structure required to make progress toward high-level goals. The primary job of our engineering team became enabling the agents to do useful work. »
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) | Lütke · Karpathy · Willison (juin 2025) — formalisé par Anthropic (sept. 2025) |
| 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
- Lütke · Karpathy · Willison (juin 2025) — formalisé par Anthropic (sept. 2025)
- 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 — gérer le contexte, pas juste l'écrire
Terme popularisé en juin 2025 par Tobi Lütke (CEO Shopify), amplifié par Andrej Karpathy puis cristallisé par Simon Willison, et formalisé par Anthropic en septembre 2025 comme « la progression naturelle du prompt engineering ». On ne se contente plus d'écrire un bon prompt, on gère activement le contexte tout au long d'une session longue. En pratique : mémoire (ce qu'on garde entre deux tours), compactage et résumé (qu'est-ce qui est essentiel à garder ?), prévention du context rot — ce pourrissement progressif quand on accumule trop de tokens inutiles — via du micro-compacting, et nettoyage régulier des outils exposés à l'agent. Sans ça, même avec la meilleure doc métier et un RAG bien indexé, l'agent finit par se noyer dans son propre contexte.
Principe : un contexte propre bat un contexte volumineux. Garbage in, garbage out — puissance 10.
Skills & Tools — donner les bons outils, dans un périmètre contenu
Fonctions exposées, API internes, commandes CLI, accès en lecture/écriture à un périmètre précis — idéalement dans une sandbox Docker dédiée pour contenir toute action destructrice. Le Model Context Protocol (MCP) s'impose comme standard pour connecter agents et outils — à utiliser avec discernement : chaque serveur MCP branché est aussi un token burner (descriptions d'outils, schémas, métadonnées consomment du contexte en continu).
Principe : l'agent ne peut faire que ce qu'on lui autorise explicitement à faire, et dans un environnement qu'on peut détruire.
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, et surtout une pipeline CI stricte non contournable par l'agent : quality gates (Sonar Way), sécurité (Snyk, Trivy, SAST), et feedback live côté agent — lint, type-check et quick checks exécutés en continu, pour corriger à chaud plutôt qu'en fin de run.
Anti-pattern : tout mettre dans le prompt et croire que ça va tenir. Les contraintes critiques doivent être dans du code déterministe et dans la CI, pas dans un system prompt.
Observabilité — savoir ce que fait l'agent et l'améliorer
Traces (LangSmith, Langfuse, Arize), logs des outils appelés, métriques de base : taux de succès, hallucination rate, coût par tâche. Mais surtout : penser amélioration dès le jour 1. C'est lent ? Quel tool call est le moins performant ? Est-ce de la latence réseau, du prompt processing, du token generation ? Pourquoi l'agent se trompe ici — manque de skill ? de contexte ? de l'outil ? Il faut collecter le maximum de signaux pour nourrir un cycle de self-improvement — idéalement en laissant un autre modèle (plus gros, ou juge) analyser les traces et proposer des correctifs de harness.
Principe : on ne gère pas ce qu'on ne mesure pas, et on ne s'améliore pas sans collecter dès le départ.
Context Engineering — gérer le contexte, pas juste l'écrire
Terme popularisé en juin 2025 par Tobi Lütke (CEO Shopify), amplifié par Andrej Karpathy puis cristallisé par Simon Willison, et formalisé par Anthropic en septembre 2025 comme « la progression naturelle du prompt engineering ». On ne se contente plus d'écrire un bon prompt, on gère activement le contexte tout au long d'une session longue. En pratique : mémoire (ce qu'on garde entre deux tours), compactage et résumé (qu'est-ce qui est essentiel à garder ?), prévention du context rot — ce pourrissement progressif quand on accumule trop de tokens inutiles — via du micro-compacting, et nettoyage régulier des outils exposés à l'agent. Sans ça, même avec la meilleure doc métier et un RAG bien indexé, l'agent finit par se noyer dans son propre contexte.
Principe : un contexte propre bat un contexte volumineux. Garbage in, garbage out — puissance 10.
Skills & Tools — donner les bons outils, dans un périmètre contenu
Fonctions exposées, API internes, commandes CLI, accès en lecture/écriture à un périmètre précis — idéalement dans une sandbox Docker dédiée pour contenir toute action destructrice. Le Model Context Protocol (MCP) s'impose comme standard pour connecter agents et outils — à utiliser avec discernement : chaque serveur MCP branché est aussi un token burner (descriptions d'outils, schémas, métadonnées consomment du contexte en continu).
Principe : l'agent ne peut faire que ce qu'on lui autorise explicitement à faire, et dans un environnement qu'on peut détruire.
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, et surtout une pipeline CI stricte non contournable par l'agent : quality gates (Sonar Way), sécurité (Snyk, Trivy, SAST), et feedback live côté agent — lint, type-check et quick checks exécutés en continu, pour corriger à chaud plutôt qu'en fin de run.
Anti-pattern : tout mettre dans le prompt et croire que ça va tenir. Les contraintes critiques doivent être dans du code déterministe et dans la CI, pas dans un system prompt.
Observabilité — savoir ce que fait l'agent et l'améliorer
Traces (LangSmith, Langfuse, Arize), logs des outils appelés, métriques de base : taux de succès, hallucination rate, coût par tâche. Mais surtout : penser amélioration dès le jour 1. C'est lent ? Quel tool call est le moins performant ? Est-ce de la latence réseau, du prompt processing, du token generation ? Pourquoi l'agent se trompe ici — manque de skill ? de contexte ? de l'outil ? Il faut collecter le maximum de signaux pour nourrir un cycle de self-improvement — idéalement en laissant un autre modèle (plus gros, ou juge) analyser les traces et proposer des correctifs de harness.
Principe : on ne gère pas ce qu'on ne mesure pas, et on ne s'améliore pas sans collecter dès le départ.
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 — cas nominaux, cas limites, cas adversariaux — couplée à un human-in-the-loop sur les actions sensibles et à un LLM-as-a-judge (avec un bias / rubric explicite) pour itérer vite sur les régressions qualité.
6. Retour d'expérience VOID : un agent de remédiation à l'échelle, 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. Et ce problème ne se limite pas aux CVE : c'est la même mécanique pour code propagation (propager un changement d'API dans tout un repo), dependency management at scale, ou fleet-wide remediation quand un même fix doit atterrir sur dizaines — voire centaines — de projets.
22h47 : une CVE critique tombe sur une dépendance utilisée par 100 projets internes. Sans agent, c'est trois jours de guerre pour coordonner les équipes.
07h30 le lendemain : l'agent a ouvert 100 PR, chacune avec le fix, les tests qui passent, un lien d'environnement de test éphémère, et une notification Slack au owner du repo. Il reste aux humains ce qui compte : la revue et la décision de merge.
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 (outil interne VOID, self-hosted, en cours d'open sourcing) | Détection CVE, pilotage workflow, interaction Git |
| Serveur d'inférence | vLLM (prod) / Ollama (dev) | Sert le modèle localement — vLLM pour le throughput en prod, Ollama pour itérer |
| 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 + SAST |
| Tests E2E | Playwright + suite unit/intégration existante | Boucle de feedback — pas de PR sans tests verts |
| Sandbox | Docker sandboxes / sandboxagent.dev | Environnement isolé jetable — l'agent y exécute ses commandes sans risque pour le host |
| Plateforme Git | GitHub / GitLab API | Création PR + commentaires de revue |
Stack technique 100% on-premise
- Rôle
- Détection CVE, pilotage workflow, interaction Git
- Choix
- vLLM (prod) / Ollama (dev)
- Rôle
- Sert le modèle localement — vLLM pour le throughput en prod, Ollama pour itérer
- 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 + SAST
- Choix
- Playwright + suite unit/intégration existante
- Rôle
- Boucle de feedback — pas de PR sans tests verts
- Choix
- Docker sandboxes / sandboxagent.dev
- Rôle
- Environnement isolé jetable — l'agent y exécute ses commandes sans risque pour le host
- Choix
- GitHub / GitLab API
- Rôle
- Création PR + commentaires de revue
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é. Qwen3.6-27B — sorti le 22 avril 2026 sur Hugging Face — réduit cet écart sur les benchmarks agentiques publics (SWE-bench Verified 77.2 %). On le fait tourner sur le même harness, sans refonte, avec des premiers retours très encourageants.
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. vLLM + 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 | vLLM (prod, throughput sérieux), Ollama (dev / POC), TGI |
| Sandbox / exécution isolée | Docker sandboxes, sandboxagent.dev, E2B |
| Modèles open-source | Qwen3.5 / Qwen 3.6 (meilleure promesse agents), 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
- vLLM (prod, throughput sérieux), Ollama (dev / POC), TGI
- Outils
- Qwen3.5 / Qwen 3.6 (meilleure promesse agents), 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.
Le savais-tu ? Fun facts harness
Trois détails qu'on oublie souvent, mais qui en disent long sur la maturité d'un harness.
Le « switch to planning mode » est une KPI
Quand Cursor ou Claude Code te proposent de passer en mode planning, ils mesurent le temps entre la proposition et ton clic. C'est une métrique de friction cognitive : plus tu mets de temps, plus l'agent t'a embarqué sur une mauvaise piste. À tracker dans n'importe quel harness interne.
« Continue » révèle quand l'agent fatigue
Chaque fois que tu tapes "continue" à un agent, c'est un signal. Comptés sur une session, ces prompts permettent d'identifier quand l'agent commence à staler, perdre le fil, ou tourner en rond — typiquement au bout de N tool calls ou d'un certain volume de contexte. Excellent indicateur de context rot et de limite de skill.
Les benchmarks agents sont une direction, pas une vérité
Un bon nombre des benchmarks d'agents IA les plus populaires du secteur sont fondamentalement dépassés ou biaisés — c'est l'application directe de la loi de Goodhart : "quand une mesure devient un objectif, elle cesse d'être une bonne mesure". À lire : Berkeley RDI — Trustworthy Benchmarks. Use them as a compass, not a scoreboard.
Le « switch to planning mode » est une KPI
Quand Cursor ou Claude Code te proposent de passer en mode planning, ils mesurent le temps entre la proposition et ton clic. C'est une métrique de friction cognitive : plus tu mets de temps, plus l'agent t'a embarqué sur une mauvaise piste. À tracker dans n'importe quel harness interne.
« Continue » révèle quand l'agent fatigue
Chaque fois que tu tapes "continue" à un agent, c'est un signal. Comptés sur une session, ces prompts permettent d'identifier quand l'agent commence à staler, perdre le fil, ou tourner en rond — typiquement au bout de N tool calls ou d'un certain volume de contexte. Excellent indicateur de context rot et de limite de skill.
Les benchmarks agents sont une direction, pas une vérité
Un bon nombre des benchmarks d'agents IA les plus populaires du secteur sont fondamentalement dépassés ou biaisés — c'est l'application directe de la loi de Goodhart : "quand une mesure devient un objectif, elle cesse d'être une bonne mesure". À lire : Berkeley RDI — Trustworthy Benchmarks. Use them as a compass, not a scoreboard.
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.