Un agent IA peut rédiger une réponse impeccable et échouer dès qu’il doit consulter un dossier, utiliser un outil ou vérifier le résultat. C’est le problème que les ingénieurs tentent désormais de résoudre. Le prompt engineering formule la tâche, le context engineering choisit les informations nécessaires et le harness engineering organise l’environnement qui permet d’agir.
Cette progression ne signifie pas que les anciennes méthodes ont disparu. Elle reflète surtout un changement d’échelle : les entreprises ne demandent plus seulement aux modèles de répondre, mais d’exécuter des opérations contrôlables. Et entre deux actions apparaît une autre question, souvent appelée loop engineering : comment poursuivre, corriger ou arrêter le travail ?
Trois points clés
- Le prompt engineering définit l’objectif, les contraintes et le format. Il reste indispensable, mais une consigne ne constitue pas un contrôle technique.
- Le context engineering sélectionne les documents, la mémoire, l’état de la tâche et les résultats d’outils utiles à chaque appel du modèle.
- Le harness engineering fournit les outils, l’exécution, les permissions et les vérifications. Les boucles d’action font partie de cette réflexion, sans relever d’une taxonomie universelle.
Le prompt engineering améliore la consigne, pas toute l’application
« Résume cette procédure en cinq points » : pour une demande limitée, une instruction claire fait souvent l’affaire. Le prompt engineering précise le rôle, l’objectif, les contraintes, les exemples et le format attendu. Il ne se réduit pas à des formules magiques : les prompts modernes peuvent intégrer des modèles de sortie structurés et des règles propres à une tâche. Notre guide du prompt engineering détaille cette première couche.
Mais demander à un assistant de « rembourser seulement les clients éligibles » ne lui donne ni les données du client ni le droit de payer. Cette limite traverse les comparaisons actuelles : un bon texte de consigne peut améliorer une réponse, sans garantir la réussite d’une opération de bout en bout. Dans leur guide Building Effective Agents, Schluntz et Zhang pour Anthropic distinguaient déjà les workflows codés des agents, qui choisissent eux-mêmes certaines étapes. La distinction reste essentielle : une succession fixe d’actions n’a pas les mêmes risques qu’un agent autorisé à improviser son parcours.
Le context engineering fournit le bon dossier au bon moment
Popularisé par Simon Willison, l’ingénierie du contexte est un travail sur l’ensemble des informations exposées au modèle. Pas seulement le message de l’utilisateur : aussi les instructions système, les extraits récupérés, l’historique utile, les définitions d’outils et leurs réponses. L’objectif n’est pas d’ajouter le plus de contenu possible. Il est de sélectionner les éléments qui rendent la prochaine décision pertinente, tout en maîtrisant le volume de tokens.
Un assistant peut se tromper parce qu’il n’a pas reçu une procédure, mais aussi parce qu’on lui a transmis trois versions incompatibles. La fenêtre de contexte n’est pas une mémoire fiable par nature. Elle peut se remplir d’éléments périmés, de résultats d’outils inutiles ou de conversations hors sujet. Louis Bouchard évoque notamment le context rot, cette dégradation de l’exploitation de l’information à mesure que le contexte s’encombre. Notre dossier sur la fenêtre de contexte des LLM explique pourquoi sa taille ne suffit pas à juger la qualité d’un système.
Le RAG ne remplace pas la gestion du contexte
Le RAG retrouve des passages dans une base documentaire. Le context engineering décide aussi lesquels conserver, dans quel ordre, avec quelle provenance et à quel moment relancer la recherche. Il peut résumer une étape ancienne, conserver l’état d’une tâche hors du prompt ou ne révéler que les outils pertinents. L’article sur les trois disciplines souligne ce glissement vers l’information utile. Mais aucune compression n’est neutre : un résumé peut effacer une exception importante. Une source récupérée doit pouvoir être contrôlée, pas simplement paraître crédible.
Le harness engineering construit le cadre qui permet d’agir
Le harness désigne l’ensemble des logiciels, configurations et mécanismes autour du modèle. Anthropic l’illustre avec Claude Code et OpenAI avec son environnement Deep Research, tandis que des écosystèmes comme LangChain proposent leurs propres définitions : le modèle fournit des capacités, l’environnement rend celles-ci utilisables. Outils, système de fichiers, état persistant, exécution de code, orchestration, tests et contrôles peuvent en faire partie. Ce n’est ni un standard technique unique ni forcément un framework à acheter.
Imaginons un agent qui consulte un ERP. Le harness vérifie son identité, restreint les outils exposés, contrôle les paramètres transmis à l’API et consigne les opérations. Il peut imposer une validation humaine avant un paiement. Si l’API ne répond pas, il évite de déclarer l’opération réussie ; il doit aussi empêcher qu’une nouvelle tentative crée un second remboursement. Une instruction du type « fais attention » n’offre pas ces garanties : elles doivent être appliquées par le code et les droits d’accès.
Le harness peut également décider quand récupérer de nouveaux documents, réduire le contexte ou solliciter un autre agent. Il recouvre donc une partie du travail sur le contexte sans le rendre inutile. Notre article sur l’AI Harness approfondit son architecture. Le protocole MCP facilite certaines connexions aux outils ; il ne remplace pas, à lui seul, l’autorisation des actions.
Le loop engineering révèle une quatrième question
Plusieurs des sources de l’industrie, notamment les cursus d’explainx.ai, distinguent une quatrième discipline : le loop engineering. Il décrit le cycle par lequel un agent observe une situation, choisit une action, vérifie son résultat puis décide de continuer ou de s’arrêter. Un bon mécanisme définit le but mesurable, le nombre maximal d’itérations, le budget, les conditions d’échec et l’intervention humaine. Sans cela, l’agent peut répéter une erreur coûteuse ou conclure trop tôt.
Il faut toutefois éviter de présenter cette quatrième couche comme une nomenclature officielle. Dans ses écrits, Addy Osmani décrit les boucles comme une pratique située au-dessus du harness d’un agent. D’autres auteurs les placent à l’intérieur de cet environnement. L’AI Developer Magazine les analyse comme une couche de vérification et de reprise. Les frontières changent selon l’architecture. Le diagnostic, lui, reste clair : un agent qui ne sait pas quand arrêter ne souffre pas nécessairement d’un mauvais prompt.
Un remboursement client montre où chaque couche intervient
Un client réclame un remboursement. Le prompt demande une réponse courte et justifiée, avec interdiction d’inventer une décision. Le contexte fournit la commande concernée, sa date, son statut, les règles applicables et les éventuels échanges antérieurs. Si le dossier est incomplet, l’agent doit rechercher la pièce manquante ou signaler son absence, pas extrapoler à partir d’une conversation voisine.
Le harness fait respecter les autorisations avec la lecture de la commande, le calcul vérifié du montant, la validation du paiement au-delà d’un seuil et le journal d’exécution. La boucle vérifie l’état renvoyé par l’API avant de clore le dossier. En cas d’échec ou de doute, elle arrête ou escalade l’opération plutôt que de relancer indéfiniment le versement. C’est une architecture illustrative, pas une procédure réglementaire universelle.
Chaque incident renvoie alors à un levier différent. Une réponse au mauvais format appelle une correction du prompt. Une politique de retour ancienne demande une correction du contexte. Un paiement non autorisé impose un contrôle du harness. Des tentatives sans fin nécessitent une révision de la boucle. Cette grille de lecture, également proposée par harness-engineering.net, évite de retoucher la formulation pour masquer un défaut logiciel.
Les résultats d’OpenAI et LangChain sont éclairants, mais situés
Dans ses retours d’expérience sur ses modèles de raisonnement o1 et o3, OpenAI indique développer ses logiciels internes de manière hautement automatisée. Les équipes évaluent l’impact concret de l’autonomie applicative sur les volumes de pull requests et les temps de développement. Ce sont les chiffres et l’évaluation d’OpenAI pour son propre projet, pas un benchmark indépendant applicable à toutes les entreprises.
De son côté, LangChain présente régulièrement des évaluations d’impact : en modifiant uniquement le harness et en maintenant le modèle constant, leurs agents de code enregistrent de fortes progressions de performance sur les benchmarks d’exécution de terminaux. L’écart met en lumière l’efficacité d’un protocole précis, et non une productivité générale. Ces travaux appuient une idée solide : l’environnement influence fortement les performances. Ils ne prouvent ni qu’un harness garantit la réussite, ni qu’une configuration gagnante sur un benchmark fonctionnera telle quelle dans une banque ou un hôpital.
Les risques apparaissent dès que l’agent possède des outils
Un chatbot peut rédiger une mauvaise recommandation. Un agent connecté peut supprimer un fichier, envoyer un message ou changer une donnée de production. Il rencontre aussi les injections de prompt indirectes, instructions hostiles insérées dans un site ou un document qu’il consulte. L’OWASP recommande de ne pas traiter ces contenus comme des instructions privilégiées. La séparation entre données externes et commandes autorisées doit être réelle.
La protection passe par des permissions minimales, des outils à portée limitée, la validation des paramètres, des environnements isolés et des confirmations avant les actions sensibles. Les journaux et évaluations détectent les dérives, mais peuvent eux-mêmes exposer des données s’ils sont mal conçus. Le harness ne sécurise donc rien par sa seule présence : un contrôle trop permissif ou un test insuffisant laisse passer l’erreur. Les vérifications de bout en bout restent indispensables.
Faut-il ajouter un harness à toutes les applications IA ?
Non. Une synthèse de documents relue par un humain n’exige pas la même infrastructure qu’un agent chargé de modifier des commandes. Pour une réponse ponctuelle, commencez par la consigne et l’évaluation du résultat. Pour une recherche dans des procédures qui évoluent, travaillez la récupération et la fraîcheur du contexte. Dès qu’un système agit sur des données ou des logiciels, les permissions, la gestion des échecs et la traçabilité deviennent prioritaires. La sophistication doit suivre le risque de l’action, pas une mode technique.
Même avec un harness, un workflow déterministe peut rester préférable à un agent autonome. Il est souvent plus facile à expliquer, à tester et à auditer. Avant le déploiement, mesurez la réussite des tâches complètes, les erreurs critiques, le coût par exécution, la durée et le recours à l’humain. Prévoyez des jeux de tests avec sources périmées, accès refusés, API indisponibles et tentatives d’injection. Sans critères de sortie, les agents transforment vite une simple panne en série de mauvaises décisions.
- Partager l'article :
