Le Harness en IA — Transformer un modèle brut en agent autonome et fiable
Un modèle d’IA brut, même très capable, reste une boîte noire. Ce qui le transforme en agent utile en production, ce n’est pas seulement un meilleur prompt : c’est tout ce qu’on construit autour — scripts, outils, planifications, APIs, garde-fous. C’est ça qu’on appelle le harness.
Sur mes projets, ce concept structure BB-DEV (développement autonome) et BB-LOG (monitoring autonome). Voici comment je le vois, et pourquoi l’équilibre entre IA générative et déterminisme change tout.
Partie 1 — Qu’est-ce qu’un harness ?
Plus qu’un wrapper autour d’un LLM
Le harness, c’est l’écosystème déterministe qui entoure le modèle : tout ce qui définit quand l’agent tourne, quoi il a le droit de faire, comment il récupère le contexte, et où il pose le résultat.
Sur le schéma ci-dessus, le « cerveau » au centre est le modèle. Autour, les modules du harness :
| Module | Rôle |
|---|---|
tools | Actions exposées au modèle (lire un fichier, chercher dans le code…) |
mcp | Connexions vers des plateformes externes (GitHub, Sentry…) |
api | Interfaces machine-to-machine contrôlées |
cron | Déclenchement planifié, sans intervention humaine |
scripts | Étapes déterministes (branche Git, PR, rapport docx…) |
webapp | Interface humaine pour piloter, valider, consulter |
Sans ces briques, on a un chat intelligent. Avec, on a un agent qui s’insère dans un workflow métier.
Pourquoi c’est indispensable
Un modèle générique est polyvalent — et c’est aussi son risque. Il peut dériver, inventer, sortir du cadre. Le harness force la spécialisation : chaque agent a une mission bornée, des permissions limitées, et des étapes critiques qui ne passent pas par la génération libre.
La tendance que je constate : on passe d’agents « fourre-tout » branchés sur plein de MCP à des agents spécialisés, chacun avec un harness taillé pour une tâche précise.
Partie 2 — Cas pratique : le harness de BB-DEV
La mission
BB-DEV traite des tickets GitHub tagués BB-DEV de bout en bout — correctifs bornés, features simples, mises à jour de contenu — sans décision architecturale ni négociation client.
Ce qui est déterministe, ce qui ne l’est pas
| Étape | Qui décide |
|---|---|
Sélection des tickets tagués BB-DEV | Script Python (déterministe) |
| Génération du code | Claude Code en CLI autonome (IA) |
| Création de branche, push, ouverture de PR | Scripts / processus Git (déterministe) |
L’IA produit le code. Le harness garantit que ce code s’insère dans un workflow de développement classique : même conventions de branche, même revue via PR, même périmètre que j’ai volontairement ouvert avec le tag.
Pourquoi c’était important d’avoir une partie déterministe ? Il y a 3 semaines, j’ai eu un sérieux coup de chaud. Alors que je travaillais avec Cursor pour construire un nouveau Workflow GitHub, je m’aperçois qu’il a décidé tout seul de pousser mon code sur GitHub. Il s’excuse, il me dit qu’il a estimé que comme le travail concernait un Workflow, mes instructions laissaient penser que je l’avais autorisé. Rien de grave, le workflow était opérationnel. Mais cela m’a fait prendre conscience du besoin de limiter l’espace donné à l’agent.
Le résultat
En un mois, 48 tickets traités sans intervention humaine. Le coût de « réentrée » sur les petites tâches disparaît : le développement continue en arrière-plan pendant que je me concentre sur l’architecture et le client.
Et tout ça avec la garantie que le processus de travail de l’équipe sera respecté.
Partie 3 — Cas pratique : le harness de BB-LOG
La mission
BB-LOG audite les erreurs Sentry et crée des tickets GitHub actionnables. Objectif : passer d’un monitoring passif (mail hebdo) à un traitement proactif.
La structure du harness
- Cron hebdomadaire — déclenchement déterministe, pas d’oubli.
- API Sentry / Posthog — récupération des erreurs avec contexte (fréquence, impact, gravité, évolution, récidive).
- Tickets GitHub — vérification des doublons, création de tickets prioritaires selon des règles fixes.
- Rédaction IA — la seule partie générative : titre, description, pré-analyse et suggestion de correction, à partir des données déjà structurées par le harness.
- Rapport structuré — production d’un docx formaté (processus déterministe), mais c’est une option, car je ne les regarde plus.
L’impact
Des rapports plus riches que le résumé Sentry, et un gain estimé à 2–3 heures par semaine de triage manuel. L’IA rédige ; le harness décide quoi traiter et comment le livrer dans GitHub. Maintenant qu’une partie importante du code de l’agent est déterministe, je sais que je peux l’appeler aussi souvent que nécessaire sans exploser mon budget token.
Ce que ça a changé concrêtement ? BB-LOG vérifie désormais les nouvelles erreurs chaque heure. Et il envoie ces erreurs à BB-DEV qui les corrige dans la foulée. C’est comme si votre application avait une sorte de fonctionnalité auto-repair.
S’il n’est pas certain de la correction, la consigne passée à l’agent est d’ajouter des logs, afin de mieux interpréter la prochaine fois qu’il aura cette erreur. Votre agent améliore au fur et à mesure la maintenabilité de votre application.
Partie 4 — L’équilibre génératif / déterministe
La règle que j’applique
L’IA intervient là où l’intelligence est nécessaire, pas là où la logique suffit.
Récupérer des tickets tagués, ouvrir une PR, planifier un cron, filtrer les erreurs déjà ticketées : ce n’est pas de la créativité. C’est du déterminisme — et c’est précisément ce qui rend l’agent fiable.
La génération (code, texte de ticket, synthèse) reste dans le périmètre où le modèle apporte de la valeur. Le harness borne ce périmètre.
Ce que ça apporte concrètement
- Fiabilité — moins de dérives, actions alignées sur le process.
- Prédictibilité — on sait ce que l’agent peut faire, et ce qu’il ne fera jamais.
- Gestion des risques — permissions minimales, points de contrôle (tag
BB-DEV, revue de PR, règles de priorité). - Montée en charge contrôlée — on élargit le harness (nouveaux tools, nouveaux cron) sans lâcher le modèle en liberté totale.
En résumé
Le harness n’est pas un détail d’implémentation : c’est la condition pour qu’un LLM devienne un agent de production. BB-DEV et BB-LOG n’ont pas le même moteur ni le même rythme, mais la même logique : entourer l’IA de processus déterministes, et ne lui confier que ce qui demande vraiment de l’intelligence.
Si vous voulez mettre en place ce type d’agents sur votre stack — ou simplement en discuter — contactez-moi.
Vous cherchez un CTO à la demande pour votre startup ou votre PME ?
Discutons de votre projet