Le « harness engineering », un vrai métier : la fiche de poste

Depuis deux ans, les conseils de carrière autour des agents IA portaient surtout sur l'art de bien les prompter. Ce n'est plus la compétence rare. La compétence rare, c'est de construire l'échafaudage dans lequel s'inscrit un agent — ce qu'on appelle de plus en plus un harness — et c'est suffisamment spécifique, et suffisamment difficile, que cela devient une fonction à part entière plutôt qu'une responsabilité annexe de « la personne IA » d'une équipe.

L'exposé public le plus clair de ce que cela implique concrètement vient de la newsletter de Lenny, qui décrit comment ChatPRD, l'outil de gestion produit, a construit un harness pour déboguer automatiquement les bugs remontés par Sentry. L'article mérite d'être lu en entier si vous hésitez à vous spécialiser dans ce domaine, car il souligne un point facile à manquer : le modèle n'a jamais été le goulot d'étranglement. L'équipe s'est appuyée sur le Claude Agent SDK comme base, puis a consacré l'essentiel de son effort d'ingénierie à une interface terminal sur mesure et à un ensemble d'adaptateurs reliant l'agent à Sentry, Linear, GitHub et Vercel. C'est le métier, en miniature. Quatre systèmes, quatre schémas d'authentification différents, quatre structures de données différentes, et une interface qui permet à un humain d'observer et d'intervenir sans devoir surveiller chaque étape.

Ce que recouvre concrètement le terme « harness »

Si vous cherchez à déterminer si cette compétence mérite d'être développée, il est utile de la décomposer en éléments qui font l'objet d'un recrutement distinct, ou du moins d'une évaluation distincte lors d'un entretien :

• Conception des permissions. Décider ce qu'un agent est autorisé à faire sans supervision (lire un ticket, rédiger une PR) par opposition à ce qui nécessite un humain dans la boucle (fusionner, déployer, supprimer, dépenser de l'argent) — et coder cela comme une véritable politique dans le code, pas comme une instruction de prompt que le modèle pourrait ignorer sous pression. Cela relève davantage de l'ingénierie du contrôle d'accès que de la rédaction de prompts.
• Adaptateurs d'outils. Des enveloppes minces et bien testées autour de chaque système externe (Sentry, Linear, GitHub, Vercel, ou quel que soit l'ensemble d'outils de votre entreprise) qui traduisent l'intention de l'agent en un appel API sûr et validé, puis traduisent la réponse en quelque chose sur quoi le modèle peut raisonner. C'est de l'ingénierie logicielle ordinaire — gestion des erreurs, nouvelles tentatives, validation de schéma — appliquée à un nouveau type de consommateur.
• Interface terminal ou console. Un moyen pour un humain de voir ce que fait l'agent, d'approuver ou de rejeter ses actions, et d'intervenir lorsqu'il se bloque. ChatPRD en a construit une sur mesure ; de nombreuses équipes utiliseront plutôt des consoles d'agent prêtes à l'emploi, mais quelqu'un doit tout de même décider ce qui est affiché, ce qui est masqué, et ce qui nécessite un clic avant de se produire.
• Sélection d'outils à grande échelle. Un article de Machine Learning Mastery signale un point à connaître si vous construisez autre chose qu'une simple démo : la précision d'un agent dans ses appels d'outils tend à se dégrader dès que le catalogue d'outils dépasse la douzaine d'options environ — le modèle se met à appeler les mauvais outils, à halluciner des paramètres, ou à s'enliser sur de mauvais appels. Les mesures d'atténuation qu'il énumère (restreindre les outils visibles selon le contexte, la recherche d'outils par récupération, l'orientation vers des sous-agents spécialisés, des étapes de planification explicites, une logique de repli, et des harnais de test pour détecter les régressions) constituent elles-mêmes une liste de choses qu'un ingénieur harness doit savoir mettre en œuvre, et pas seulement connaître.
• Ingénierie du contexte et de la mémoire. La même source établit une distinction qui mérite d'être intégrée : l'ingénierie du contexte (ce qui entre dans un seul appel d'inférence, et où) et l'ingénierie de la mémoire (ce qui persiste d'une session à l'autre, comment c'est stocké, comment c'est récupéré) sont des disciplines distinctes avec des modes de défaillance différents. Sa thèse est que la plupart des dysfonctionnements observés chez les agents de longue durée, multi-sessions, proviennent de la confusion entre les deux — traiter la mémoire de session comme si ce n'était que du contexte supplémentaire, ou l'inverse — en particulier au moment où le système décide quoi récupérer.

Les preuves qu'il s'agit d'un poste réel et finançable — pas seulement d'une niche pour amateurs

Les sceptiques se demanderont, à juste titre, si « harness engineer » est un véritable métier ou simplement une tâche noyée dans le poste de quelqu'un d'autre. Deux éléments tirés de la synthèse suggèrent qu'on se dirige vers la première option. D'abord, l'équipe Aspire de Microsoft — un groupe de dix personnes — a utilisé les Agentic Workflows de GitHub pour automatiser les PR de documentation inter-dépôts, et sur deux versions a fusionné 82 PR avec un délai médian de 44,8 heures après la sortie de la PR produit correspondante, sans embauche supplémentaire ni reformation des processus. C'est une petite équipe qui obtient un effet de levier disproportionné précisément parce que quelqu'un a investi dans l'échafaudage (les définitions de workflow, l'acheminement des revues, la logique de déclenchement) plutôt que de faire rédiger les PR de documentation à la main par des ingénieurs. Ensuite, le projet SkillOpt de Microsoft Research traite les fichiers de « compétences » (« skill ») de l'agent — les instructions et contraintes qui façonnent son comportement au sein de son harness — comme quelque chose à optimiser systématiquement plutôt qu'à modifier à la main, et rapporte avoir obtenu le meilleur résultat, ou un résultat ex æquo avec le meilleur, sur les 52 cellules d'une grille de benchmark (six benchmarks, sept modèles, trois modes d'exécution), les compétences optimisées se transférant d'un modèle à l'autre et d'un harness à l'autre. Que cet outil précis devienne ou non un standard, cela indique que le secteur commence à traiter la configuration des harness comme un artefact d'ingénierie à part entière, avec ses propres outils et ses propres benchmarks — la même trajectoire qui a transformé le « DevOps », d'un ensemble de scripts improvisés, en une discipline à part entière.

Une infrastructure est également en train d'être construite explicitement pour cette couche. Les nouvelles fonctionnalités « Managed Agents » de Google dans l'API Gemini — exécution en arrière-plan et asynchrone, intégration de serveurs MCP distants, appels de fonctions personnalisés, rafraîchissement des identifiants entre les interactions — constituent en réalité une plomberie préconstruite pour exactement les problèmes que l'équipe ChatPRD a résolus à la main. C'est un schéma habituel : ce qu'une équipe construit sur mesure cette année, un éditeur de plateforme le transforme en produit l'année suivante. Cela n'élimine pas le rôle d'ingénieur harness ; cela relève le plancher et déplace le métier vers l'intégration et la configuration de briques gérées plutôt que vers l'écriture de chaque adaptateur à partir de zéro, de la même manière que l'infrastructure cloud n'a pas éliminé les ingénieurs ops, mais a changé ce à quoi ils consacraient leur temps.

Ce que cela signifie si vous visez ce poste

Quelques éléments concrets et vérifiables à mettre dans un portfolio ou un CV si vous voulez être crédible sur ce terrain : construisez un adaptateur de bout en bout face à une véritable API que vous ne contrôlez pas (authentification, gestion des erreurs, limites de débit incluses — pas une démo qui ne montre que le chemin nominal) ; concevez et documentez un modèle de permissions pour un agent qui distingue les actions de lecture, de proposition et d'exécution, et qui explique pourquoi chaque frontière se situe là où elle se situe ; et construisez ou configurez une interface de revue où un humain approuve les actions de l'agent avant qu'elles ne s'exécutent, car c'est l'élément sur lequel la plupart des entreprises insisteront avant de laisser un agent toucher à la production. Si vous évaluez une offre d'emploi d'ingénieur harness ou que vous délimitez vos propres responsabilités, demandez précisément qui possède le modèle de permissions, qui possède les adaptateurs, et qui possède l'interface de revue humaine — dans beaucoup d'équipes, à l'heure actuelle, ces trois éléments n'ont pas de propriétaire clairement identifié, ce qui est exactement le vide que ce poste est en train de se former pour combler.

Une réserve mérite d'être formulée clairement : aucune des sources ci-dessus n'établit de chiffre de marché de l'emploi pour cet intitulé précis, et « harness engineer » n'est pas encore un intitulé de poste que vous verrez dans les annonces — il apparaît plutôt à l'intérieur d'intitulés comme « ingénieur infrastructure IA », « ingénieur plateforme agent », ou simplement « ingénieur backend senior, systèmes IA ». Considérez cela comme une compétence à construire et à décrire avec précision, pas comme un intitulé à rechercher sur LinkedIn.