Questions d'entretien sur le harness engineering : 22 questions avec réponses pour un ingénieur IA

Comment se préparer

Les questions d'entretien sur le harness engineering vont en général du général au particulier : qu'est-ce qu'un harnais, de quoi se compose-t-il, comment diagnostiquez-vous un problème, comment mesurez-vous l'effet d'un changement ? L'examinateur cherche une pensée d'ingénieur : la capacité à distinguer un problème de modèle d'un problème d'environnement et à proposer une solution vérifiable. Vous trouverez ci-dessous 22 questions avec réponses, regroupées par thème.

Les fondamentaux

1. Qu'est-ce que le harnais d'un agent ?

Le harnais est l'ensemble de l'environnement dans lequel travaille un agent IA, à l'exception du modèle lui-même : instructions, outils, environnement d'exécution, stockage de l'état et boucles de retour. Le modèle prend les décisions ; le harnais détermine ce qu'il sait, ce qu'il peut faire et comment il apprend le résultat de son action. Le même modèle, placé dans des harnais différents, affiche une qualité très différente.

2. En quoi le harness engineering se distingue-t-il du prompt et du context engineering ?

Le prompt engineering travaille sur la formulation d'une requête, le context engineering sur ce qui entre dans la fenêtre du modèle à chaque étape. Le harness engineering englobe les deux et ajoute ce que le texte ne résout pas : l'accès aux outils, un environnement reproductible, un état conservé entre les sessions et une vérification automatique du résultat.

3. Citez les cinq sous-systèmes du harnais.

Les instructions (AGENTS.md, CLAUDE.md, skills, documentation), les outils (shell, tests, linter, navigateur, MCP), l'environnement (dépendances, runtime, Docker, worktree), l'état (PROGRESS.md, liste des fonctionnalités, décisions) et le retour d'information (make check, E2E, hooks, évaluateur). L'absence de l'un d'eux ne produit pas des résultats « un peu moins bons », mais une classe systématique d'échecs.

4. Pourquoi remplacer le modèle par un plus puissant ne résout-il souvent rien ?

Parce que de nombreux échecs n'ont rien à voir avec l'intelligence du modèle. Un modèle puissant n'obtiendra pas un accès à une commande qu'on ne lui a pas donnée, ne se souviendra pas de la session de la veille sans fichier d'état, et n'apprendra pas qu'une migration est cassée si personne ne l'a exécutée. Il ne devinera pas non plus les conventions propres à une équipe donnée.

Diagnostic

5. L'agent enfreint une règle écrite dans CLAUDE.md. Que faites-vous ?

D'abord, vérifier si l'agent trouve la règle : un long fichier de dizaines de points noie l'essentiel. Réduisez le fichier d'entrée à une table des matières et sortez les détails dans des documents chargés sous condition. Si la règle est critique, transformez-la en vérification exécutable — linter, test, garde-fou grep ou hook —, de sorte que la transgression devienne visible par la machine et ne dépende plus de l'attention du modèle.

6. À partir d'un symptôme, comment savoir quel sous-système est défaillant ?

Les conventions connues bafouées renvoient aux instructions. L'agent qui « veut mais ne peut pas » renvoie aux outils. Une session qui commence par la réparation de l'environnement renvoie à l'environnement. Une nouvelle session qui ne sait pas où les choses en étaient renvoie à l'état. Un « terminé » qui ne correspond pas à la réalité renvoie au retour d'information.

7. Par quel sous-système commencez-vous la construction du harnais, et pourquoi ?

Par le retour d'information. Tant qu'il n'existe pas de commande qui répond mécaniquement « ça marche ou non », l'effet d'un autre changement ne peut pas être mesuré. Viennent ensuite en général les instructions, l'état, l'environnement et les outils, mais l'ordre est empirique et dépend de ce qui est le plus gravement défaillant.

8. Comment mesurez-vous la contribution d'un élément du harnais ?

Par l'ablation : on fixe le modèle et l'ensemble des tâches, on désactive un sous-système à la fois et on observe la chute. Mais mieux vaut commencer par un journal des échecs annoté par couche : il désigne le goulot d'étranglement plus vite. Une chute nulle ne signifie pas que l'élément est inutile : il n'est peut-être pas sollicité par ces tâches, ou il est redondant.

Instructions et contexte

9. Comment structurer un bon AGENTS.md ?

Comme un routeur, et non comme un manuel : ce qu'est le projet, comment le lancer, comment le vérifier, la définition of done et une courte liste de contraintes obligatoires. Les détails figurent dans des documents séparés, reliés par des renvois du type « à lire si la tâche concerne les paiements ». Le fichier énonce des invariants (« les données sont validées à la frontière ») au lieu de dicter l'implémentation et les bibliothèques ligne à ligne.

10. À quoi servent les sous-agents ?

À isoler le contexte. Une sous-tâche — recherche dans la base de code, revue, vérification — s'exécute dans un contexte distinct et ne renvoie que son résultat. Le fil principal reste propre, et un sous-agent vérificateur n'hérite pas des raisonnements de l'exécutant, ce qui est important pour une évaluation honnête.

11. Qu'est-ce que la dette du harnais ?

L'écart accumulé entre le harnais et la réalité : règles obsolètes, commandes qui ne fonctionnent plus, documents décrivant des modules qui n'existent plus. Elle se comporte comme une dette technique : elle s'accumule sans bruit et se paie par les pannes de l'agent. Le harnais doit être révisé régulièrement, et non configuré une seule fois.

État et sessions

12. Comment lutter contre l'amnésie de l'agent entre les sessions ?

En conservant l'état dans le dépôt : PROGRESS.md (situation, travail accompli, blocages, prochaines étapes), DECISIONS.md (décision, raison, options écartées), une liste de fonctionnalités avec leur statut, des commits fréquents. Dans les instructions, on fixe l'ordre de démarrage : lire la progression, lancer le script de vérification de l'environnement, reprendre la fonctionnalité active.

13. Pourquoi la règle WIP=1 ?

Quand un agent entame plusieurs fonctionnalités à la fois, l'état se disperse : aucune n'est terminée, les modifications sont mêlées, le retour arrière devient difficile. Une seule fonctionnalité active donne un point de contrôle clair, des commits propres et une reprise simple après une panne.

14. Qu'est-ce qu'un test de démarrage à froid ?

Une vérification consistant à savoir si une nouvelle session, sans aucune indication humaine, peut répondre aux questions de base : de quel projet il s'agit, où l'on en est, quelle fonctionnalité est active, comment vérifier que tout va bien. Si l'agent répond à partir des fichiers sans rien deviner, le sous-système d'état fonctionne.

Vérification

15. Pourquoi des tests unitaires verts ne prouvent-ils pas que la fonctionnalité marche ?

Un test unitaire isole un module et simule ses dépendances : il ne voit donc pas les jointures — interfaces incompatibles, propagation de l'état (le schéma a changé, le cache est périmé), fuites de ressources, problèmes de configuration et d'environnement. Les défauts détectés par les tests unitaires forment un sous-ensemble de ceux que détectent les tests d'intégration, eux-mêmes sous-ensemble de ce que révèle le E2E.

16. Qu'est-ce que l'écart de vérification et comment le calculer ?

C'est la proportion de tâches que l'agent a déclarées terminées sans qu'une vérification indépendante ne les confirme. On prend 10 tâches à la suite et on note pour chacune les deux faits. La métrique fournit une base de référence : après des modifications du harnais, on la recalcule sur un ensemble comparable de tâches.

17. Comment rédiger une définition of done pour un agent ?

Dans AGENTS.md, sous forme de liste de points vérifiables : les commandes de vérification se sont terminées avec le code 0, un test E2E couvre le scénario, les migrations s'appliquent, la progression est mise à jour. Il est utile de préciser ce qui n'est pas considéré comme terminé : « ça a l'air correct », « les tests unitaires passent », « chez moi ça marche ».

18. Pourquoi l'agent ne doit-il pas attribuer lui-même le statut « terminé » ?

Les modèles ont tendance à surestimer leur propre travail, et l'auto-évaluation a lieu dans le même contexte que celui où la décision a été prise. Le statut passing doit être attribué par un script de vérification à partir des résultats des exécutions, en consignant le hash du commit comme preuve.

19. Comment mettre en place un évaluateur indépendant ?

Un agent ou une session distincte qui ne voit que l'exigence, le diff et les résultats des exécutions, mais pas les raisonnements de l'exécutant. Il évalue selon une grille (exactitude, architecture, tests, gestion des erreurs), et chaque appréciation renvoie à un fichier, une ligne ou un journal. Il est préférable d'utiliser un autre modèle pour que les angles morts ne se recouvrent pas.

20. Comment rendre une règle d'architecture exécutable ?

Sur trois niveaux : garde-fou grep (rapide, fondé sur des motifs), règle de linter qui comprend le graphe des imports (import-linter, dependency-cruiser) et test d'architecture en CI. Tous s'intègrent à make check, échouent avec un code de sortie non nul et affichent POURQUOI et CORRECTION, afin que l'agent corrige lui-même la transgression. Le déclencheur d'une nouvelle vérification est le deuxième commentaire identique lors d'une revue.

Travail autonome

21. Que faut-il pour laisser un agent travailler pendant des heures ?

Un objectif non ambigu, une métrique de progression monotone (par exemple le nombre de fonctionnalités en passing), un budget par fonctionnalité en temps et en tentatives, un retour arrière automatique en cas de régression, et une liste d'actions qui exigent un humain : migrations, infrastructure, argent. Ajoutez l'isolation : un bac à sable ou un git worktree dédié, pour qu'une erreur ne touche pas l'environnement de travail.

22. Quand un seul cycle d'agent ne suffit-il plus, et comment construire un graphe de rôles ?

Lorsque l'exécutant commence à se vérifier lui-même et s'enlise. On découpe alors la tâche en rôles : implémentation, revue, tests, fusion. La revue reçoit un contexte propre et une grille, la fusion est exécutée par le code lorsque review == pass. Si la revue échoue, la fonctionnalité repart en implémentation ; après plusieurs échecs, elle est relancée avec un contexte propre — ce qui signifie que le problème tient à la compréhension de la tâche, et non au code.

Synthèse

En entretien sur le harness engineering, ce sont les réponses sur ce qui est vérifiable — quels fichiers, quelles commandes, quelle métrique — qui convainquent le plus. Gardez en tête les cinq sous-systèmes, l'écart de vérification et la règle « le statut est attribué par un script ». Tous ces thèmes se rejoignent dans un harnais unique sur un projet de bout en bout, dans le cours sur le harness engineering.