Le harness : pourquoi vos prompts ne suffisent plus

Tout le monde a maintenant un bon prompt quelque part. Un message soigné, avec le rôle, le contexte et le format demandé, qui a donné un excellent résultat un mardi soir. Le problème arrive le jeudi, quand on le relance sur un autre dossier et que le résultat est médiocre. Ce n’est pas le modèle qui a changé. C’est que le prompt n’était qu’une partie du travail.

Ce que j’appelle harness, faute d’un bon mot français, c’est tout ce qui entoure le modèle pour rendre un résultat répétable. Le terme vient du monde des développeurs, où un harness de test est le cadre qui exécute un programme dans des conditions contrôlées. L’idée est la même : on ne demande pas au modèle d’être brillant, on lui construit un cadre dans lequel il est fiable.

Les cinq pièces du harness

Un harness complet tient en cinq pièces. Aucune n’est technique, toutes demandent de la méthode.

Le contexte. Ce que le modèle doit savoir avant de commencer : les documents de référence, le vocabulaire de l’organisation, les exemples de ce qui est bien et de ce qui ne l’est pas. La plupart des échecs viennent d’un contexte absent. On demande au modèle de rédiger « comme nous » sans jamais lui avoir montré comment on écrit.

Les instructions. Le prompt proprement dit, mais versionné, relu, et séparé de la demande du jour. Les instructions décrivent la procédure : les étapes, les critères de réussite, ce qu’il faut refuser de faire. La demande du jour ne fait que fournir les données d’entrée.

Les outils. Ce que le modèle peut faire au-delà de produire du texte : lire un fichier, chercher sur le web, interroger une base, écrire dans un tableur. Un modèle sans outils invente ce qu’il ne sait pas. Un modèle avec les bons outils va chercher.

Les garde-fous. Ce qui est interdit ou qui exige une validation humaine : envoyer un mail, supprimer une ligne, engager un montant. Le garde-fou est écrit noir sur blanc dans les instructions et, quand c’est possible, imposé par l’outil lui-même.

La vérification. Comment on sait que le résultat est bon avant de l’utiliser. Une grille de relecture, un test automatique, une comparaison avec un exemple de référence. Sans vérification, on fait confiance par défaut, et c’est là que les erreurs passent.

Un exemple concret : la réponse à un appel d’offres

Prenons une tâche que je rencontre en mission : rédiger la première version d’une réponse à un appel d’offres.

Sans harness, on colle le cahier des charges dans un chatbot et on demande une réponse. Le résultat est fluide, générique, et faux sur les détails de l’entreprise.

Avec un harness, la même tâche devient une procédure. Le contexte contient les trois dernières réponses gagnées, la présentation de l’entreprise et la grille tarifaire. Les instructions décrivent la structure attendue, section par section, et interdisent d’inventer une référence client. Un outil permet de lire le cahier des charges et de le découper par exigence. Le garde-fou impose de signaler chaque exigence à laquelle l’entreprise ne peut pas répondre plutôt que de la contourner. La vérification est une grille de dix questions que relit la personne responsable avant tout envoi.

La différence n’est pas dans le modèle. Elle est dans le cadre.

Des skills pour ne pas tout réécrire

Une fois le harness construit, la question suivante est de le rendre réutilisable. C’est ce que j’appelle une skill : une procédure formalisée, avec ses instructions et ses fichiers de contexte, que le modèle sait exécuter à la demande.

La skill « réponse à appel d’offres » contient tout ce qui précède, rangé dans un dossier, avec un fichier d’instructions lisible par un humain comme par le modèle. Quand un nouvel appel d’offres arrive, on n’écrit plus un prompt. On invoque la skill et on fournit le document.

Ce fonctionnement existe aujourd’hui dans plusieurs outils, sous des noms différents : projets, instructions personnalisées, fichiers d’instructions à la racine d’un dépôt de code, skills à proprement parler dans les assistants de code. Le principe est le même partout, et c’est le principe qu’il faut enseigner, pas l’interface du moment.

Et les agents ?

Un agent est un harness qui boucle tout seul : il lit, décide, agit avec un outil, vérifie, recommence, jusqu’à ce que la tâche soit terminée. Ce site a été conçu et codé de cette façon, avec un assistant de code qui lisait le brief, écrivait les pages, lançait les vérifications d’accessibilité et corrigeait.

Un agent sans harness est dangereux : il agit vite et sans cadre. Un agent avec un harness solide est un collègue junior fiable, qui sait quand demander avant d’agir. La question à se poser avant de passer à un agent n’est pas « le modèle est-il assez bon ? » mais « mon harness est-il assez clair pour qu’il boucle sans surveillance ? ».

Par où commencer

Choisissez une tâche qui revient chaque semaine et qui prend plus d’une heure. Écrivez les instructions comme si vous les donniez à un nouveau collègue. Rassemblez les trois documents qu’il devrait lire avant. Définissez ce qu’il n’a pas le droit de faire seul. Écrivez la grille de relecture.

Vous venez de construire un harness. Le modèle, lui, était déjà prêt.

C’est ce que je fais faire dans le module Comprendre et utiliser l’IA, sur les cas réels des participants.