Du PoC à la production. Comment industrialiser des agents IA.

Le pilote qui fonctionnait. L'agent qui n'est jamais sorti.

Lorsqu'un brief arrive sur l'un de nos bureaux et que nous nous asseyons avec l'équipe qui le porte, la conversation suit souvent la même trame. Une équipe cliente a passé la majeure partie d'une année sur une initiative IA. Le pilote a été présenté au comité de direction, la démonstration était propre, quelqu'un s'est engagé sur un lancement au trimestre suivant, et plusieurs trimestres plus tard rien n'est passé en production. Le proof of concept n'a pas vraiment été tué. Il est installé sur l'ordinateur d'un développeur, les opérateurs qu'il devait aider ne se sont jamais connectés, et le dirigeant qui le portait est passé à une autre priorité.

Dans nos échanges avec les clients et les partenaires technologiques, nous voyons ce schéma assez souvent pour qu'il ne surprenne plus personne dans la salle. Les raisons que nous rencontrons sont généralement une combinaison des cinq décrites ci-dessous, et la plupart des équipes avec qui nous travaillons s'y reconnaissent dans plus d'une.

Les compétences qui ont bâti le pilote ne sont pas celles qui le mettent en production.

Dans le laboratoire, le modèle est évalué sur la précision face à un jeu de données mis de côté. En production, ce qui compte est la latence sous charge, la fiabilité quand une API en amont change de comportement, et le coût par session quand l'usage double. Nous avons travaillé avec des équipes data science extrêmement compétentes à qui aucune de ces trois questions n'avait été posée pendant la phase pilote, et qui ne les auraient pas priorisées même si elles l'avaient été. La manière dont nous traitons cela avec un client est généralement d'associer le data scientist à un platform engineer dès la première semaine du travail de production, ce qui paraît lourd au début et se révèle nécessaire au deuxième sprint.

La confiance des opérateurs n'a jamais été conçue dans le système.

Un modèle qui produit des réponses utiles une partie du temps est acceptable en démonstration et impraticable au quotidien. Les opérateurs avec qui nous avons travaillé décrivent un seuil de confiance constant : s'ils ne peuvent pas voir pourquoi l'agent a recommandé quelque chose, ne peuvent pas surclasser facilement une mauvaise réponse, et ne peuvent pas tracer ce que l'agent a fait il y a trois jours quand quelque chose s'est mal passé, ils arrêtent de l'utiliser en quelques semaines. Le travail que nous menons avec les clients à ce stade ne porte pas sur la précision du modèle. Il porte sur la conception du système pour qu'il soit digne de confiance de l'intérieur, ce qui est une conversation différente.

L'agent n'avait plus de responsable une fois la phase pilote close.

La plupart des pilotes que nous voyons ont été financés sur un budget innovation et portés par un chief data officer, un head of digital, ou un dirigeant curieux côté métier. Quand la phase pilote se termine, ce responsable est happé par le sujet suivant. L'équipe des opérations qui pilote le processus que l'agent devait changer a rarement été consultée pendant la phase de construction, et elle n'intègre pas l'agent dans son portefeuille. Il n'y a pas de service level agreement, pas de rotation d'astreinte, pas de budget d'amélioration. En un trimestre, l'agent s'est dégradé silencieusement et personne n'a le poids politique pour le ranimer.

La gouvernance est arrivée trop tard pour façonner la conception.

Dans les environnements régulés, et de plus en plus dans tous ceux où interviennent des données personnelles, des décisions financières ou des considérations de sécurité, nous voyons la même séquence. Le juridique, la sécurité et la conformité ne sont pas dans la salle pendant la phase de conception. Ils arrivent plus tard avec un long document de revue qui fait remonter une contrainte qui aurait dû être un paramètre de conception dès le départ. L'équipe se retrouve face à des mois de retouches ou à un arrêt silencieux. Faire entrer ces fonctions dans la conversation avant que le premier prompt ne soit écrit est l'un des leviers les plus puissants que nous recommandons.

L'intégration est l'endroit où le modèle est jugé injustement.

Le modèle est impressionnant isolément. Une fois branché sur le système de gestion de la relation client, l'entrepôt de données, l'outil de ticketing et la couche d'authentification interne, les cas limites se multiplient et les latences s'empilent. L'agent paraît plus bête qu'il ne l'est parce que la plomberie autour de lui fuit. Nous avons vu beaucoup d'équipes blâmer le modèle pour des problèmes qui étaient en réalité des problèmes d'intégration, et perdre des mois à chercher au mauvais endroit.

Rien de tout cela n'est de la malchance. C'est la conséquence d'une structure qui optimise pour le moment de la démonstration plutôt que pour le moment de l'usage quotidien, et c'est la structure que nous passons l'essentiel de notre temps à aider les clients à changer.

Ce que veut vraiment dire « être en production » pour un agent IA.

Quand la question arrive dans un comité de pilotage ou dans nos discussions avec des partenaires technologiques, la définition de travail que nous utilisons a tenu au fil de nos missions. Un agent IA est en production quand un opérateur qui n'en a jamais entendu parler peut être pris en main en une demi-journée, accomplir une vraie tâche avec lui, obtenir un résultat auquel il fait confiance, et que l'équipe qui pilote l'agent peut détecter et corriger une régression dans les heures qui suivent.

Cette phrase porte cinq conditions, et d'après notre expérience, les cinq doivent être réunies pour qu'un agent survive à son premier trimestre d'usage réel.

Une suite d'évaluation qui s'exécute à chaque changement.

Par suite d'évaluation, nous entendons un jeu de tests issu du trafic réel en production, avec les sorties attendues, qui s'exécute chaque fois que l'équipe change un prompt, remplace un modèle ou met à jour un index de recherche. Nous avons travaillé avec des équipes qui ont mis en production sans suite d'évaluation et qui ont appris l'existence de régressions par des utilisateurs mécontents une semaine plus tard. Nous avons travaillé avec des équipes qui ont investi dans la suite d'évaluation dès le premier sprint et qui ont pu changer trois fois leur modèle sous-jacent au cours de la mission sans perdre la confiance des opérateurs. La différence est significative et sous-estimée.

Une observabilité câblée dès le premier sprint.

L'équipe doit voir ce que fait réellement l'agent. Les traces de chaque appel, les latences, le nombre de tokens, les invocations d'outils, les taux de repli, le coût par session. Quand quelque chose tourne mal, quelqu'un doit pouvoir rejouer la conversation de la veille. Dans les briefs que nous recevons après un pilote calé, traiter l'observabilité comme une fonctionnalité à ajouter plus tard est l'une des erreurs les plus fréquentes que nous trouvons. C'est de la plomberie, et la plomberie est bien plus difficile à rétro-installer qu'à poser dès le départ.

Une interface opérateur qui explique, permet de surclasser et journalise.

Les trois schémas qui construisent la confiance des opérateurs plus vite que n'importe quel chiffre de précision sont le raisonnement visible, les chemins de surclassement et les journaux d'audit. L'agent montre d'où vient sa réponse. L'opérateur peut être en désaccord, corriger la réponse et faire retomber cette correction dans le jeu d'évaluation. Chaque action de l'agent est journalisée de manière à ce que l'opérateur et l'équipe de conformité puissent tous deux l'inspecter. Les clients nous demandent parfois si ces schémas ralentissent le système. D'après notre expérience, ils ralentissent la démonstration et accélèrent fortement l'adoption.

La gouvernance comme contrainte d'exécution, pas comme case à cocher au lancement.

L'accès aux outils est au moindre privilège. Il y a des garde-fous sur ce que l'agent peut écrire, à qui il peut envoyer des emails, ce qu'il peut dépenser dans une session. Il y a un kill switch qui ne nécessite pas un déploiement de code pour être activé, parce que d'après notre expérience, le moment où vous avez besoin d'un kill switch est le moment où vous ne pouvez pas vous permettre de planifier une release. Il y a une piste d'audit que la conformité peut inspecter un lundi matin sans que personne ne soit d'astreinte pour les aider.

Des budgets de coût et de latence appliqués à l'exécution.

Chaque appel a un budget. Le système se dégrade gracieusement quand le budget est dépassé : fenêtre de contexte plus courte, modèle moins cher ou réponse plus simple, plutôt que de produire un coût non borné. Les clients avec qui nous travaillons qui ont ignoré cela ont découvert que l'agent consommait une part disproportionnée de la ligne IA dans un rapport financier en fin de trimestre, ce qui n'est jamais la manière dont on souhaite ouvrir cette conversation.

Quand les cinq conditions sont réunies, l'agent est passé d'un déploiement à un système en production. C'est le seuil à viser.

L'écart entre un notebook qui fonctionne et un agent qui fonctionne, c'est l'ingénierie sans gloire que personne ne met en avant. C'est aussi la partie qui décide si votre investissement dans l'IA rapporte quelque chose au business.

Trois habitudes que partagent les équipes qui réussissent.

Au fil des missions que nous menons depuis nos bureaux de Paris, Dubaï, Singapour et Bali, et dans notre travail aux côtés de nos partenaires technologiques, les équipes qui parviennent à faire entrer un agent dans l'usage quotidien réel, et à l'y maintenir, partagent trois habitudes qui les distinguent des autres. Aucune n'est une innovation technique. Ce sont des habitudes de cadrage du travail.

Elles commencent la conversation avec l'opérateur, pas avec le data scientist.

La première réunion sur un projet d'agent réussi porte rarement sur les données disponibles. Elle porte sur la décision que l'opérateur prend chaque jour, sur l'endroit où se situe la friction dans cette décision, et sur ce qui rendrait vraiment les deux heures suivantes de son travail plus simples. Le modèle est un moyen. La décision est la finalité. Quand la première conversation démarre par la donnée plutôt que par les décisions, nous finissons souvent avec un agent qui résout un problème que personne sur le terrain ne demandait à résoudre. Nous avons reconstruit la liste courte des cas d'usage dans les trois premières semaines de plus d'une mission, simplement parce que la liste d'origine venait d'une slide de fournisseur plutôt que d'entretiens avec les opérateurs.

Elles construisent la suite d'évaluation avant de construire l'agent.

Le jeu d'évaluation joue le rôle de spécification. C'est la liste des cas que l'agent doit traiter, issue d'exemples réels d'opérateurs, avec les sorties attendues. L'écrire en premier oblige à un niveau de clarté sur ce qu'est un bon résultat que le seul prompt engineering ne produit pas. Cela donne aussi à l'équipe un signal de feedback qui survit à chaque réécriture de prompt, à chaque mise à jour de modèle et à chaque réglage de la recherche qui interviendront inévitablement pendant le travail.

Elles transmettent la responsabilité aux opérations avant le jour du lancement.

Dans les projets qui marchent, l'équipe qui pilotera l'agent en production est dans la salle avant que l'agent n'existe. Elle écrit le runbook avec l'équipe de construction. Elle co-conçoit l'alerting. Elle nomme la rotation d'astreinte. Elle définit le service level agreement. Quand le jour du lancement arrive, il n'y a pas de passation au sens formel. L'agent est déjà le sien. Les projets que nous avons vus échouer traitent presque toujours la passation comme l'étape finale plutôt que comme la première.

Les deux prérequis que nous vérifions toujours en premier : les personnes et la donnée.

Avant d'aborder l'une quelconque des disciplines d'ingénierie décrites plus haut, il y a deux fondations que nous examinons toujours en premier, parce que d'après notre expérience aucun travail sur l'agent lui-même ne peut compenser une faiblesse sur l'une ou l'autre. La première est la donnée sur laquelle l'agent va s'appuyer. La seconde, ce sont les personnes qui travailleront avec lui. Nous avons vu d'excellentes équipes d'ingénierie construire des agents sur des données auxquelles personne ne faisait confiance, et nous avons vu de bons modèles déployés dans des équipes qui n'avaient jamais été consultées. Les deux types de projets calent à peu près de la même manière.

Côté donnée, ce que nous cherchons, c'est la confiance, pas le volume.

Le schéma que nous voyons le plus souvent est que la donnée existe, le volume est suffisant, l'accès technique peut être arrangé, et le manque se situe au niveau de la gouvernance. Qui décide de la source canonique. Qui est autorisé à alimenter le modèle. Qui est responsable quand la donnée dérive. Nous sommes arrivés sur plus d'une mission où le premier travail utile n'était pas un modèle mais une revue de propriété de la donnée, qui faisait remonter un désaccord non résolu entre l'équipe qui possède le système client et l'équipe qui possède l'entrepôt. Tant que ce désaccord n'est pas nommé et tranché au bon niveau, l'agent construit sur des données contestées survit rarement à sa première revue de conformité.

Pour cette raison, nous recommandons toujours de résoudre les questions de confiance dans la donnée avant que la construction ne démarre, même si cela ajoute des semaines au début. Le temps récupéré ensuite, en moins de retouches, moins d'escalades de conformité et moins de débats sur ce que l'agent aurait dû savoir, est généralement significatif.

Côté personnes, ce que nous cherchons, c'est l'inclusion, pas la formation.

L'inclusion des opérateurs est souvent traitée comme un problème de formation alors qu'elle relève davantage de la conception. Les personnes qui utiliseront l'agent au quotidien doivent façonner ce qu'il fait, ce qu'il montre, quand il les interrompt et comment il reconnaît son incertitude. Dans nos discussions avec les équipes dirigeantes qui ont vécu un déploiement calé, la leçon est généralement la même : l'activité la plus utile au début est rarement un plan de formation. C'est un petit nombre d'entretiens avec les opérateurs qui font remonter les frictions du travail actuel, les moments où ils accueilleraient une aide, et ceux où ils ne le feraient pas. De ces conversations, la liste courte des cas d'usage se réécrit souvent, parfois significativement par rapport à la spécification d'origine.

Quand les opérateurs sont traités comme co-concepteurs, le déploiement avance plus vite une fois lancé. Quand ils sont traités comme une audience future pour une démonstration, l'adoption cale dans les premières semaines d'usage réel. L'investissement en formation qui suit un sérieux effort de conception a du sens. L'investissement en formation qui remplace un effort de conception tend à être gaspillé.

Quand la conversation avec un client ou un partenaire bascule sur « que conseilleriez-vous avant que nous investissions sérieusement dans un agent IA », nous donnons généralement la même réponse. Consacrez les premières semaines à la propriété de la donnée et à l'inclusion des opérateurs avant de passer du temps à choisir un modèle ou un fournisseur. Les déploiements que nous avons vus réussir avaient ces deux fondations en place au moment où la construction démarrait. Les déploiements qui ont calé manquaient généralement de l'une, parfois des deux, et nous n'avons pas encore vu d'exception.

Une courte checklist que nous passons avant la production.

Quand une équipe cliente, ou l'un de nos partenaires technologiques sur une mission conjointe, approche du moment de mettre un agent entre les mains de vrais opérateurs, nous passons généralement les dix questions suivantes ensemble. Un « non » à l'une d'elles n'est pas nécessairement une raison de retarder. C'est un risque à nommer et à accepter en conscience, plutôt qu'à découvrir après coup.

1. Existe-t-il un jeu d'évaluation qui couvre les principaux cas que l'agent est censé traiter dans le premier mois ?
2. Ce jeu d'évaluation est-il alimenté par du trafic réel en production, ou est-il figé depuis le premier sprint ?
3. Les budgets de coût et de latence sont-ils définis, instrumentés et appliqués à l'exécution, pas seulement sur un tableau de bord ?
4. Quelqu'un dans l'équipe peut-il rejouer n'importe quelle conversation de la veille et comprendre ce que l'agent a fait ?
5. Les opérateurs ont-ils un moyen d'être en désaccord avec l'agent, et le désaccord retombe-t-il dans le jeu d'évaluation ?
6. Existe-t-il un kill switch qui ne nécessite pas un déploiement de code, accessible aux opérations plutôt qu'à la seule ingénierie ?
7. Les outils que l'agent peut utiliser sont-ils au moindre privilège, et leur accès est-il audité ?
8. Existe-t-il un responsable nommé pour l'agent au-delà du jour du lancement, avec un service level agreement, une rotation d'astreinte et un budget d'amélioration ?
9. Le juridique, la sécurité et la conformité ont-ils été associés à la phase de conception, ou seulement à la phase d'audit en fin de parcours ?
10. Si le modèle sous-jacent est déprécié ou re-tarifé significativement au prochain trimestre, quel est le plan de repli ?

Dans ces conversations, ce que nous écoutons n'est pas les questions auxquelles l'équipe répond « non ». Ce sont les questions où elle hésite. L'hésitation pointe généralement un point faible du modèle opératoire qu'il vaut la peine de renforcer avant que le déploiement ne s'élargisse.

Par où nous commençons généralement la conversation.

Si votre équipe porte un pilote qui devrait être en production et n'a pas fait le saut, les questions que nous ouvrons habituellement lors de notre premier échange ne portent pas sur le modèle. Nous demandons quel est le processus que l'agent devait changer, qui pilote ce processus aujourd'hui, et si cette personne était dans la salle au moment de la conception. Nous demandons quelle est la donnée sur laquelle l'agent s'appuie, qui décide de la version qui fait foi, et ce qui se passe quand ces personnes ne sont pas d'accord. Nous demandons qui sera responsable de l'agent six mois après le lancement, et si cette personne dispose d'un service level agreement, d'une rotation d'astreinte et d'un budget pour les améliorations qu'elle devra apporter.

Les clients avec qui nous travaillons qui ont une réponse claire à ces trois questions sont généralement à quelques mois de la production. Ceux qui n'ont pas de réponse claire sont dans une conversation plus longue qu'ils ne l'imaginaient, et c'est généralement utile de le découvrir tôt plutôt que tard.

Si vous souhaitez confronter vos notes sur un pilote qui cale, les équipes Tech Factory et Consulting de nos bureaux de Paris, Dubaï, Singapour et Bali sont joignables depuis le formulaire ci-dessous. Nous répondons sous un jour ouvré, avec le partner qui suivra le dossier plutôt qu'avec un chargé de relation.