Neuf habitudes d’ingénierie pour déployer votre premier agent IA

Une histoire circule dans les cercles de l’ingénierie des agents au sujet d’une facture de 47 000 dollars. Elle est racontée sans beaucoup de détails, il faut donc la considérer comme une illustration et non comme un cas vérifié. Un agent s’est comporté parfaitement lors de chaque démonstration. Puis on l’a mis en œuvre dans un flux de travail réel de client, ce qui l’a conduit dans une boucle de remboursement, le forçant à exécuter la même action encore et encore pendant six heures, sans que personne ne le surveille. Le modèle n’était pas particulièrement stupide. Les personnes qui ont conçu le système ont ignoré tous les mécanismes permettant au modèle de savoir quand s’arrêter.

C’est la vérité dérangeante concernant le travail d’ingénierie sur les systèmes d’intelligence artificielle : même si vous maîtrisez Python, RAG, les agents, les bases de données vectorielles, la technique de prompting ainsi que toutes les versions des modèles, vous pouvez encore ne pas être prêt pour la mise en production. Les compétences qui permettent de surmonter les problèmes après une démo ne figurent que rarement dans les tutoriels. Elles sont ennuyeuses et faciles à ignorer, mais elles font la différence entre un système qui a l’air impressionnant et un système fiable. Voici neuf habitudes de travail utiles à adopter avant de lancer un système autonome.

Pourquoi connaître plus ne fait pas de vous un expert

Quelques chiffres montrent à quel point les projets stagnent entre la démo et le déploiement. Ces données sont indirectes et les méthodes varient, donc considérez-les comme une estimation approximative :

• Une prévision de Gartner pour le milieu de 2025 indique que plus de 40 % des projets d’intelligence artificielle basés sur des agents seraient annulés avant la fin de 2027, en raison de coûts croissants, d’une valeur incertaine et de contrôles des risques insuffisants.

Selon une enquête menée en 2025 par S&P Global Market Intelligence, les entreprises abandonneraient environ 46 % de leurs prototypes d’IA avant leur mise en production.

L’initiative NANDA du MIT, après avoir étudié plus de 300 déploiements, aurait constaté que seuls environ 5 % d’entre eux produisaient un impact financier mesurable.

Aucun modèle ne se retrouve soudainement 40 % moins performant en termes de raisonnement. Quelque chose se passe entre la démonstration et le lancement. La théorie dominante est que les échecs en production sont souvent causés ou aggravés par le système entourant le modèle, et non uniquement par ses résultats : absence de mécanismes de contrôle, données de mauvaise qualité, validation insuffisante, faible capacité d’observation et dépenses non contrôlées.

Un benchmark indique la même direction sans prouver la cause. Sur tau-bench, qui teste des agents capables d’utiliser des outils pour des tâches telles que réserver des vols ou résoudre des tickets de support, un résumé indiquait que même les meilleurs modèles réussissaient moins de la moitié de ces tâches, et que la répétition d’une tâche faisait chuter la cohérence à environ un quart. Cela mesure les capacités mais ne diagnostique rien. Il affirme que les agents sont peu fiables, sans expliquer pourquoi.

Retenez bien une distinction, car elle sous-tend tous les comportements mentionnés ci-dessous : le cycle décrit précédemment n’était pas une réponse erronée. Rien ne l’a empêché de fonctionner. C’est l’écart entre la sortie d’un modèle et ce que le système permet de faire avec cette sortie qui est à l’origine de la plupart de ces problèmes.

1. Écrire l’évaluation avant la fonctionnalité

Les débutants écrivent une instruction, la testent quelques fois, vérifient le résultat et le mettent en production. Les ingénieurs plus expérimentés commencent par définir ce qu’est une solution « correcte » sous forme d’un ensemble de cas de test, avant même de travailler sur la fonctionnalité.

Une évaluation peut rester simple : collectez de 20 à 30 exemples réels tirés d’une utilisation concrète, chacun accompagné du résultat attendu, puis testez votre instruction sur tous ces exemples chaque fois qu’un changement est apporté. Si vous ne pouvez pas déterminer si un changement a été bénéfique sans examiner les résultats et deviner, il s’agit alors d’une intuition et non d’une véritable évaluation. Cette seule habitude est le moyen le plus rapide d’éviter de déployer des régressions invisibles.

2. Gérez le contexte comme de l’argent

L’habitude des débutants est de tout y mettre : le document entier, toute la conversation, cinq exemples « au cas où ». Plus il y a de contexte, on pense que c’est plus sûr, mais ce n’est généralement pas le cas. Chaque élément supplémentaire concurrence pour attirer l’attention du modèle et lui fournit un détail erroné de plus sur lequel se concentrer. Considérez la fenêtre d’affichage comme un budget :

• Réduisez les documents récupérés aux parties pertinentes.
• Summarisez les anciennes échanges et n’affichez pas leur contenu intégral.
• Supprimez les exemples qui ne sont pas utiles.

Si vous ne savez pas ce qui remplit la fenêtre, imprimez l’intégralité de votre demande avant de l’envoyer et lisez-la. Beaucoup de gens sont surpris de voir à quel point une grande partie du contenu est inutile.

3. Mettez des limites à l’autonomie du modèle avant de le lancer

C’est cette habitude qui aurait pu mettre fin au cercle vicieux des remboursements. Une étude des échecs coûteux des agents, réalisée par un groupe nommé Operator Collective, a classé ces cas en cinq catégories : absence de limites aux actions autonomes, données obsolètes ou erronées, confiance accordée aux résultats sans vérification, sécurité traitée en dernier recours, et échecs passés inaperçus faute de surveillance. Aucune de ces cinq catégories ne correspond à l’idée que « le modèle a raisonné de manière erronée ». Il s’agit d’une seule étude et non d’une loi naturelle, mais elle révèle une réalité : un résultat erroné cause rarement de dommages à lui seul. Les dommages apparaissent lorsque rien en aval ne le détecte, ne le limite ou ne l’empêche de se reproduire.

Les calculs montrent que c’est une exigence incontournable. Si chaque étape d’un flux de travail d’agent réussit 95 % du temps et que la tâche comporte 20 étapes, l’ensemble ne s’achève pas correctement que 95 % du temps, car les probabilités s’accumulent. Avec 90 % de réussite par étape, une chaîne de 20 étapes ne fonctionne correctement que dans environ 12 % des cas. Une démonstration où trois étapes se déroulent sans problème ne dit presque rien sur un flux de production comportant vingt étapes.

Au préalable de mettre en service tout système autonome, fixez-lui une limite d’étapes, un plafond de coûts, un délai d’expiration et un moyen de s’arrêter lui-même. La raison n’est pas que le modèle ne soit pas fiable, mais plutôt parce que la probabilité finit toujours par l’emporter.

4. Enregistrez les données comme si vous deviez diagnostiquer le problème à 2 heures du matin.

L’échec le plus dangereux ne se manifeste pas par une panne bruyante. L’agent entreprend l’action incorrecte, indique un succès, le tableau de bord reste vert, et un client perd de l’argent ou reçoit de mauvais conseils avant que quiconque ne s’en aperçoive.

Les débutants ajoutent des journaux d’activité après qu’un problème se soit produit. Les ingénieurs expérimentés mettent en place un suivi structuré dès le premier jour : chaque entrée, appel d’outil et étape de raisonnement intermédiaire est daté et recherchable. Trois semaines plus tard, vous voulez reconstituer exactement ce que l’agent a vu et décidé, plutôt que de le reconstituer à partir de sa mémoire. Si votre configuration actuelle vous oblige à deviner en pleine nuit, comblez d’abord cette lacune.

5. Montez les échelons : prompt, récupération des données, puis affinage

Lorsque la précision est décevante, les débutants ont souvent recours directement au réglage fin, car cela semble être une véritable pratique d’ingénierie. Il s’agit généralement du mauvais premier pas, et un cas bien connu illustre pourquoi. Des chercheurs de Microsoft ont pris GPT-4, y ont ajouté un ensemble de techniques de suggestion appelé Medprompt, et l’ont comparé à Med-PaLM 2, le spécialiste médical de Google, ajusté à partir de données cliniques et associé à des suggestions rédigées par des experts. Mesuré sur MedQA, le Med-PaLM 2 réglé finement a obtenu 86,5 %, tandis que le GPT-4 utilisant uniquement des suggestions Medprompt a obtenu 90,2 %. Cela représente une réduction de 27 % du taux d’erreur, ainsi que beaucoup moins d’appels au modèle que la méthode de réglage fin ne l’exige.

L’ordre logique consiste à passer de la méthode peu coûteuse et réversible à celle coûteuse et lente :

Prompting        Retrieval (RAG)      Fine-tuning
(cheap, fast,  →  (add missing    →   (expensive, slow,
reversible)        knowledge)          last resort)

Réparez d’abord le prompt et mesurez-le. Si le modèle manque de faits, ajoutez une fonction de récupération d’informations. N’effectuez le fine-tuning que lorsque vous disposez d’un ensemble de données important et propre, ainsi que d’un comportement spécifique que le prompt ne peut vraiment pas produire. La plupart des équipes n’ont jamais besoin de le faire, car les étapes précédentes résolvent déjà le problème.

6. Séparez la réflexion de l’exécution

Un agent débutant est souvent constitué d’un seul prompt géant qui planifie, décide et exécute en une seule opération. Lorsqu’il échoue, rien ne distingue « le modèle a pensé de manière erronée » de « le code a fait quelque chose de faux », car tout est mélangé ensemble.

Les développeurs expérimentés séparent ces deux éléments. Une partie, le modèle, agit comme le cerveau et choisit la prochaine action. Une autre partie, un code déterministe classique qui fonctionne comme le mécanisme d’exécution, la met en œuvre : il appelle l’API, vérifie la réponse, tente à nouveau dans des limites prédéfinies et applique les règles établies par la troisième habitude. C’est cette séparation qui permet de déboguer un système. On peut immédiatement savoir si c’est le modèle qui a choisi la mauvaise action ou si le code d’exécution a mal géré une action correcte, ce qui correspond à des bugs différents nécessitant des solutions distinctes.

7. Traitez les prompts comme du code et mettez-les à jour

Un prompt qui a nécessité quatre réécritures concerne la logique de production. Traitez-le comme du papier à gratter, car vous perdrez la version fonctionnelle dès que quelqu’un le « améliore ». Gardez les prompts sous contrôle de version comme n’importe quel autre fichier, exécutez votre ensemble d’évaluation dès la première étape sur chaque modification avant qu’elle ne soit fusionnée, et notez un bref journal des modifications indiquant ce qui a changé et pourquoi. Cela semble trop basique pour être mentionné, d’où le fait que la plupart des équipes l’omettent, jusqu’à ce qu’une dégradation d’un prompt atteigne la production et que personne ne puisse dire ce qui a changé.

8. Fixez d’abord le prix de la fonctionnalité

Voici un exemple concret. Un agent non contraint qui exécute une seule tâche logicielle dépense entre 5 et 8 dollars en frais API, tandis que des sessions de production complètes, y compris les tentatives répétées et les appels aux outils, coûtent entre 10 et 100 dollars. Les chiffres varient en fonction du modèle, de la tâche et des méthodes d’optimisation, mais le schéma reste identique. Un coût qui semble négligeable par tâche cesse de l’être à grande échelle, et un projet pilote qui semblait peu coûteux lors des tests peut finir par être la raison pour laquelle un projet est abandonné.

Les débutants commencent par coder puis consultent la facture plus tard. Les ingénieurs expérimentés estiment le coût par tâche avant d’écrire le moindre code : nombre approximatif de tokens entrants et sortants, appels attendus par tâche ainsi que volume quotidien prévu. Si le chiffre semble élevé pour dix utilisateurs, il ne sera pas meilleur pour dix mille. Le coût n’est pas une question financière à gérer après le lancement ; c’est une décision d’architecture que vous avez déjà prise, que vous vous en rendiez compte ou non.

9. Diagnostiquez avant de deviner

Lorsqu’un problème survient, le réflexe des débutants est de pointer vers le modèle, d’en utiliser un plus puissant ou d’écrire une instruction plus longue. Ne faites pas cela. Les échecs mentionnés dans l’analyse relative à la troisième habitude étaient dus à l’absence de mécanismes de protection, à des données de mauvaise qualité, à une confiance non vérifiée, à une sécurité insuffisante ou à des défaillances que personne n’avait anticipées, et non au fait que le modèle commette des erreurs de sa propre initiative. Il s’agit d’une observation basée sur un certain nombre de cas et cela ne garantit rien pour les vôtres, mais c’est une vérification peu coûteuse à effectuer avant une solution plus onéreuse. Avant de modifier l’instruction, demandez-vous si les données obtenues sont obsolètes ou incorrectes, si une appel à outil a échoué en silence et s’il existe des limites aux tentatives de réessai. La solution se trouve souvent dans le système environnant, et une vérification ne coûte que cinq minutes par rapport à la réécriture complète.

Quand sauter la moitié de cela

Aucun des neuf habitudes n’est gratuit. L’élaboration d’évaluations prend du temps, les mécanismes de contrôle ajoutent du code et la modélisation des coûts vous fait perdre un après-midi que vous préféreriez consacrer à la création. Si vous travaillez sur un prototype pendant un week-end et que vous êtes le seul utilisateur, sautez la plupart de ces étapes. Intégrez l’ensemble d’évaluations, les mécanismes de contrôle et des prompts versionnés uniquement lorsque d’autres personnes commencent à compter sur ce que vous avez créé, et non avant. Mener une expérience en solo avec des procédures de production rigoureuses revient à gaspiller du temps qui pourrait être utilisé pour découvrir ce qui fonctionne réellement. La discipline porte ses fruits dans les domaines où des retours sont essentiels : des systèmes qui touchent des utilisateurs réels, de l’argent réel ou des décisions importantes.

Le changement en une phrase

D’après ce récit, aucun modèle plus intelligent n’a permis de résoudre le problème. Ce qui l’a résolu, c’est un ensemble de règles écrites : des limites à l’autonomie, des vérifications avant chaque action et une personne chargée de lire les journaux. C’est la gouvernance, pas l’intelligence, qui a joué un rôle. Les débutants tentent de surmonter l’échec en utilisant un meilleur modèle. Les ingénieurs expérimentés conçoivent un système qui échoue de manière sûre lorsque le modèle est erroné, car tôt ou tard cela arrivera.