Dire « débrouille-toi » à une IA, c'est l'accident assuré. Le vrai sujet, c'est le harnais.

« Ce dépôt, range-le un peu, fais au mieux. »

Le lendemain matin, l’IA avait « fait au mieux » : 40 fichiers modifiés. Du code qui tournait, bien sûr. Sauf que des fichiers de config qu’il ne fallait surtout pas toucher avaient été « rangés » eux aussi, proprement effacés.

Vous voyez le genre de frisson dans le dos.

Pourquoi une IA censée être brillante provoque-t-elle des accidents sans sourciller ? La réponse est simple : « être intelligent » et « pouvoir travailler sans danger » sont deux choses totalement différentes. Pensez à la nouvelle recrue qui a 20/20 à tous les tests et qui, le premier jour, casse la caisse enregistreuse. Ce n’est pas un problème de capacité. C’est un problème d’appui, d’échafaudage.

Cet échafaudage, on l’appelle de plus en plus le harnais (en anglais, harness). Aujourd’hui je vous l’explique en évitant au maximum le jargon.

Un harnais, c’est quoi au juste ?

Un harnais, c’est un petit programme qu’on place « autour » de l’IA.

L’image la plus parlante, c’est le baudrier de sécurité sur un chantier, ou les petites roues d’un vélo d’enfant. Un mécanisme qui laisse la personne avec toutes ses capacités, mais qui l’empêche de tomber. Pour une IA, il joue ces rôles :

• décider ce qu’elle a le droit de lire (on ne lui montre pas tout) ;
• décider ce qu’elle doit produire (on fixe l’objectif clairement) ;
• décider jusqu’où elle agit seule, et à quel moment elle demande à un humain ;
• vérifier mécaniquement que le résultat n’est pas cassé.

« Écrire un bon prompt » n’est qu’une toute petite partie de l’histoire. Si polir vos prompts ne réduit jamais les accidents, c’est parce que c’est comme s’entraîner au monocycle sans petites roues : ça ne tient pas.

Pourquoi ça monte en flèche, maintenant ?

Il n’y a pas si longtemps, on demandait à l’IA « écris-moi un texte », « écris-moi du code », et c’était à peu près tout. Un humain relisait, jugeait, point.

Aujourd’hui, on lui confie le travail lui-même. Lire des fichiers, choisir un sujet qui ne double pas un article existant, vérifier les changements, s’inscrire sur un service externe, signaler la cause en cas d’échec. Arrivé là, il n’y a plus un humain entre chaque étape. Voilà pourquoi le risque « elle agit toute seule et provoque un accident » a explosé d’un coup.

Si Claude Code a si bonne réputation, ce n’est pas tant parce que le modèle est brillant, c’est parce que cet échafaudage est bien fichu. L’outil pour lire les fichiers, l’outil pour chercher, le garde-fou qui bloque les opérations dangereuses, le mécanisme qui lui fait mémoriser les règles du projet. Toute cette « plomberie peu glamour » tient solidement. Ce qui cartonne, ce n’est pas le prompt magique, c’est justement cette plomberie de l’ombre.

D’abord, on le fait tourner : un harnais minimal en 30 lignes

Plutôt qu’un long discours, autant le voir fonctionner. On va construire l’échafaudage le plus minimal possible : l’IA n’a le droit que de lire et écrire, et elle ne peut jamais mettre les pieds en dehors d’un dossier qu’on a choisi. Il vous faut Node.js et une clé API Anthropic.

On prépare le terrain.

mkdir harness-demo && cd harness-demo
npm init -y
npm install @anthropic-ai/sdk
mkdir sandbox
echo "# Note" > sandbox/note.md

Ensuite, on écrit la « liste blanche ». C’est le cœur du harnais. C’est la déclaration : « on ne touche à rien en dehors de sandbox ».

{
  "workspace": "./sandbox",
  "maxSteps": 6
}

Puis le corps du programme (harness.mjs). Une seule chose à retenir. safePath est le portier qui arrête tout dès que l’IA tente de sortir du dossier. Avec lui en place, l’accident des « 40 fichiers » du début ne peut plus arriver.

import Anthropic from "@anthropic-ai/sdk";
import { readFile, writeFile } from "node:fs/promises";
import path from "node:path";

const client = new Anthropic();
const policy = JSON.parse(await readFile(new URL("./policy.json", import.meta.url), "utf8"));
const root = path.resolve(policy.workspace);

// Le portier : dès qu'on tente de sortir du dossier de travail, on bloque sur place
function safePath(p) {
  const resolved = path.resolve(root, p);
  if (resolved !== root && !resolved.startsWith(root + path.sep)) {
    throw new Error(`${p} est en dehors du dossier de travail. On ne touche qu'à l'intérieur de sandbox.`);
  }
  return resolved;
}

const tools = [
  { name: "read_file", description: "Lire un texte dans sandbox",
    input_schema: { type: "object", properties: { path: { type: "string" } }, required: ["path"] } },
  { name: "write_file", description: "Écrire un texte dans sandbox",
    input_schema: { type: "object", properties: { path: { type: "string" }, content: { type: "string" } }, required: ["path", "content"] } },
];

async function useTool(name, input) {
  if (name === "read_file") return await readFile(safePath(input.path), "utf8");
  if (name === "write_file") { await writeFile(safePath(input.path), input.content, "utf8"); return "Écriture OK"; }
  throw new Error(`Outil inconnu : ${name}`);
}

const messages = [{ role: "user", content: process.argv.slice(2).join(" ") || "Lis note.md et écris un résumé dans summary.md." }];

for (let step = 0; step < policy.maxSteps; step++) {
  const res = await client.messages.create({
    model: process.env.ANTHROPIC_MODEL || "claude-sonnet-4-6",
    max_tokens: 1024,
    tools,
    system: "Tu es un préposé aux fichiers prudent. Tu n'utilises un outil qu'en cas de besoin et tu restes dans sandbox.",
    messages,
  });
  messages.push({ role: "assistant", content: res.content });

  const calls = res.content.filter((b) => b.type === "tool_use");
  if (calls.length === 0) { console.log(res.content.find((b) => b.type === "text")?.text ?? ""); break; }

  const results = [];
  for (const c of calls) {
    try { results.push({ type: "tool_result", tool_use_id: c.id, content: String(await useTool(c.name, c.input)).slice(0, 4000) }); }
    catch (e) { results.push({ type: "tool_result", tool_use_id: c.id, is_error: true, content: e.message }); }
  }
  messages.push({ role: "user", content: results });
}

Pour lancer, rien de plus que ça.

node harness.mjs

Quelques dizaines de lignes à peine, et pourtant on y trouve déjà « l’IA elle-même », « les outils disponibles », « le périmètre autorisé », « la limite de relances » et « le mécanisme qui bloque quand ça casse », chacun bien séparé. Voilà le squelette d’un harnais. Ensuite, on lui greffe la recherche, l’exécution de tests, l’attente de validation, les notifications, et il grandit petit à petit jusqu’à ressembler à Claude Code.

Là où ça change tout (trois cas)

1. Le contrôle de la « production en série » d’articles ou de docs Si vous vous contentez de « écris un article », l’IA vous pond sans broncher des textes creux ou des sujets « quasi identiques ». Alors on donne au harnais une marche à suivre : lire les titres existants → choisir un angle qui ne double rien → écrire le corps → vérifier mécaniquement le nombre de signes et les liens. Du coup, avant même que l’humain ne se demande si c’est bon ou non, le portier recale les articles trop minces. Chez moi, ça fait maintenant plusieurs brouillons par mois qui se bloquent avant publication. Et c’est tant mieux qu’ils se bloquent.

2. Le tri des demandes entrantes « Lis les demandes qui arrivent et signale-moi seulement celles qui sentent l’affaire. » La lecture, oui, qu’elle soit automatique. Mais l’ajout au fichier client reste en suspens tant qu’un humain n’a pas cliqué. Ça, on le force via le harnais. Lecture automatique, écriture en brouillon (dry-run), inscription finale par l’humain seul. L’accident où un client mal classé est balancé tout seul dans la base de production disparaît.

3. Le temps de respiration avant un déploiement Avant d’appuyer sur le bouton « publier », on fait toujours vérifier : le build passe-t-il, les variables d’environnement sont-elles toutes là, le diff est-il conforme à ce qu’on attend, existe-t-il une procédure de retour en arrière. L’IA a tendance à ne regarder que la « dernière ligne » du log d’échec et à corriger à côté de la plaque. L’astuce, c’est donc de décider à l’avance « où regarder ». On ne lui passe pas tout le log, juste les quelques dizaines de lignes concernées. Rien que ça, et les corrections hors-sujet chutent.

Trois choses à « voler » à Claude Code

Quand vous construisez votre propre harnais, inutile de tout réinventer. Claude Code est une mine d’exemples. Pas besoin de tout copier, mais ces trois-là, adoptez-les tôt et l’ensemble se stabilise d’un coup.

D’abord, répartir les règles en niveaux. Les engagements qui ne changent jamais vont dans un fichier de config ; les consignes propres à la session du jour, dans une note jetable ; les préférences durables, encore ailleurs. Tout réécrire dans le prompt à chaque fois, ça l’allonge et fait baisser la précision.

Ensuite, confier le déterministe à des commandes. Le formatage, les vérifications, les tests : plutôt que de les demander à l’IA, faites-les tourner avec une commande comme npm test, c’est plus rapide et plus sûr. On ne laisse à l’IA que le travail de « réfléchir ».

Enfin, expédier les grosses recherches à un autre responsable. Déverser de longs logs ou la lecture d’une montagne de fichiers dans la conversation principale, ça brouille le jugement décisif. Faites faire le défrichage par un processus séparé et ne récupérez que la conclusion. Rien que ça, et la netteté des décisions revient.

Mes trois plantages personnels

Je joue franc jeu. Mes premiers harnais étaient un festival d’accidents.

Le premier : je lui ai filé trop d’outils. Persuadé que ça l’aiderait, j’en avais préparé une trentaine. Résultat, l’IA hésitait — « lequel je prends ? » — et enchaînait les choix bizarres. Aujourd’hui, je me limite à 5 ou 10 au départ.

Le deuxième : mes messages d’erreur n’aidaient personne. Quand je renvoyais juste Error: failed, l’IA ne pouvait rien réparer. Le jour où j’ai écrit des choses comme README.md introuvable. Dans sandbox il n'y a que note.md, en indiquant la cause et le prochain geste, elle s’est soudain mise à se débrouiller seule.

Le troisième : je m’en remettais aux seuls yeux humains pour les vérifications. « Je relirai à la fin », ça lâche immanquablement les jours chargés. Depuis que j’ai posté des portiers mécaniques — nombre de signes, liens morts, erreurs de typage —, mes vérifications de minuit ont fondu.

Par où commencer

Ne construisez surtout pas tout de suite « l’agent intelligent entièrement automatique ». Choisissez une petite tâche, une seule, où l’échec se rattrape. Le contrôle d’un brouillon d’article, la première relecture d’une PR, le tri des demandes, la vérification avant mise en staging. C’est exactement le bon calibre.

L’ordre est toujours le même. ① Restreindre étroitement ce qu’on lui donne à lire → ② Clarifier l’objectif (le livrable) → ③ Confier les vérifications à des commandes autant que possible → ④ Mettre toutes les opérations dangereuses (suppression, base de prod, facturation, force push) sur « demander à un humain » au départ. On ne promeut une opération en automatique qu’après l’avoir vue se révéler sûre. Rien qu’en respectant cet ordre, les accidents s’effondrent.

Pour le détail des droits, j’ai tout regroupé dans le guide des permissions Claude Code, et pour poser les bases d’un usage en équipe, dans les bonnes pratiques CLAUDE.md. Si vous voulez découper de longs travaux, jetez un œil aux patterns de subagents. Pour la vision officielle, la documentation du Claude Agent SDK reste la source de référence.

Ce que j’ai testé, concrètement

Depuis l’accident des « 40 fichiers », j’ai arrêté de me torturer avec la question « est-ce que je fais confiance à l’IA ? ». Ce que je regarde désormais, c’est quel portier l’a arrêtée. En ajoutant un seul safePath à mon harnais minimal, les accidents hors dossier sont tombés à zéro. En ajoutant la vérification automatique du nombre de signes et des liens, les articles minces se bloquent désormais avant publication. Plutôt que de chercher l’IA la plus intelligente, je commence par construire un échafaudage où, même en tombant, on ne se blesse pas. Ça paraît être un détour, mais c’est en réalité le chemin le plus rapide. C’est ma conviction du moment.

En résumé

Le harness engineering, ce n’est pas l’art de décorer ses prompts. C’est l’art de concevoir ce que l’IA voit, ce qu’on lui fait faire, où on l’arrête et comment on vérifie. Commencez par faire tourner les 30 lignes ci-dessus, et ajoutez un seul « portier » à votre propre travail. La qualité du travail d’une IA se joue moins sur l’intelligence du modèle que sur l’échafaudage qui l’entoure.

Si vous voulez intégrer l’IA à votre activité de façon plus structurée et plus sûre, allez voir la liste des supports et modèles. Et si votre équipe veut cadrer permissions, revue et vérification d’un bout à l’autre, passez par la page formation et accompagnement.