Le pilote d'IA qui n'est jamais passé en production : ce qui manquait côté données et exploitation

Le pilote a fonctionné. Sur un ensemble de documents triés sur le volet, le modèle a extrait les champs, trié les tickets et convaincu les personnes qui l'avaient demandé. Des mois plus tard, il tourne toujours dans un bac à sable sur des données d'échantillon, et personne ne sait dire ce qu'il faudrait pour l'activer sur la vraie file.

Ce manque ne se comble pas en changeant de modèle. Une démo répond à la question de savoir si un modèle sait lire un document. La production demande ce qu'il advient de chaque document, y compris le document scanné, le fil transféré et celui sur lequel le modèle se trompe, sur des données qui n'ont peut-être jamais eu le droit d'atteindre le service utilisé par le pilote.

Une démo prouve que le modèle sait lire ; la production s'interroge sur chaque document

En 2015, Sculley et ses collègues de Google ont écrit que seule une petite fraction des systèmes de machine learning réels est constituée du code de machine learning, et que l'infrastructure nécessaire qui l'entoure est vaste et complexe. Un pipeline à base de modèle de langage a la même forme, et un pilote construit à partir de cette seule petite partie n'a rien autour de lui pour tourner en production.

Mettez ce dont disposait le pilote à côté de ce dont la file de production a besoin, et le travail manquant devient une liste :

• Évaluation : quelques exemples qui ont plu à quelqu'un, face à un jeu annoté avec un seuil de réussite convenu par champ
• Données : des exports, des échantillons ou une API hébergée, face à des sources réelles qui ne peuvent pas quitter votre infrastructure
• Entrée : des PDF propres, face à des scans, des fils d'e-mails, des pièces jointes et des templates qui changent sans préavis
• Sortie : un texte qu'une personne a lu, face à des enregistrements qu'un autre système consomme et auxquels il doit pouvoir se fier
• Exploitation : un utilisateur à la fois, face au volume de pointe, à une panne du serveur de modèle et à un responsable après le lancement

Constituer le jeu de recette avant de toucher au modèle

Le premier artefact manquant est un jeu annoté de documents réels, avec la réponse que chacun doit produire. Sans lui, chaque changement de prompt ou de modèle est jugé par celui qui lit la sortie ce jour-là, et le pilote ne peut pas franchir un jalon qui n'a jamais été mis par écrit.

Les « Rules of Machine Learning » de Google placent la mesure avant le modèle : la règle n° 2 est : d'abord, concevoir et implémenter des métriques. Pour l'extraction et le routage de tickets, la métrique n'est pas un score unique pour tout le document :

• Tirez les documents du trafic réel, sur une période assez longue pour inclure les fins de mois, les jours fériés et les expéditeurs qui utilisent des formats inhabituels
• Faites-les annoter par les personnes qui font le travail aujourd'hui, deux d'entre elles indépendamment sur une partie du jeu, et traitez leurs désaccords comme des lacunes de la spécification plutôt que comme du bruit
• Notez chaque champ séparément, car une date fausse ne se compense pas, en moyenne, par un nom correct
• Fixez le seuil de réussite par champ et par type de document, et désignez quels champs peuvent être automatisés et lesquels vont toujours à une personne
• Mesurez le processus manuel actuel sur le même jeu, pour que le modèle soit comparé à la référence réelle et non à la perfection
• Tenez une partie du jeu à l'écart de quiconque ajuste les prompts, pour que le score final ne soit pas mesuré sur les exemples sur lesquels le prompt a été ajusté

Des données qui ne peuvent pas quitter le périmètre changent l'architecture, pas seulement le fournisseur

Quand le pilote a été construit sur un modèle hébergé avec des échantillons, des données synthétiques ou des documents que quelqu'un a validés à la main, et que les données réelles ne peuvent pas être transmises à un fournisseur externe, le résultat du pilote ne se transpose pas : le modèle à l'intérieur peut être un autre modèle, ou le même modèle à poids ouverts avec une quantification et des réglages de serving différents, et dans les deux cas sa qualité doit être mesurée à nouveau sur le jeu de recette.

Le modèle est le composant qu'il est évident de ramener à l'intérieur. Ce n'est pas le seul, car un pipeline à base de modèle de langage copie les données dans plus d'endroits que l'appel au modèle :

• Le serveur d'inférence et les poids du modèle, avec leurs versions figées
• Les embeddings et l'index vectoriel, qui sont dérivés des documents et doivent être protégés comme les documents
• Les prompts, les sorties et les traces dans les logs, puisqu'un prompt journalisé contient le document à partir duquel il a été construit
• Le jeu de recette, l'outil d'annotation et la file de revue
• Le monitoring et le suivi des erreurs, qui deviennent une copie externe des données quand ils tournent en service hébergé

Le masquage aide là où les logs doivent quitter une zone restreinte. Presidio, un framework open source lancé chez Microsoft, détecte et anonymise les données personnelles dans du texte, et sa documentation indique que, la détection étant automatisée, rien ne garantit qu'il trouvera toutes les informations sensibles. Le masquage réduit l'exposition ; il ne remplace pas le fait de garder les données à l'intérieur.

L'entrée, c'est la moitié ingrate : scans, fils de messages et pièces jointes

Un pilote reçoit des documents ; la production reçoit tout ce que les expéditeurs produisent. Avant tout appel au modèle, le pipeline doit transformer cela en un texte vers lequel il peut renvoyer :

• Les scans et les photos passent par l'OCR, dont les erreurs sur les chiffres et les colonnes de tableau parviennent au modèle comme un texte d'apparence fiable
• Les fils d'e-mails et de tickets contiennent des réponses citées, des signatures et des clauses de non-responsabilité : le dernier message doit donc être séparé de l'historique
• Le contenu se trouve souvent dans les pièces jointes, et chaque format a besoin de son propre chemin d'extraction
• Chaque chunk conserve sa source (fichier, page et offset), pour que chaque champ extrait puisse être rattaché au passage dont il provient
• Les doublons, comme un avis transféré ou un ticket rouvert par e-mail, sont détectés avant de devenir deux enregistrements

Les entrées longues demandent un soin particulier. Dans « Lost in the Middle », publié dans TACL en 2024, Liu et ses collègues ont montré que, pour les modèles qu'ils ont testés, la performance est souvent la plus élevée lorsque l'information pertinente se trouve au début ou à la fin du contexte d'entrée, et se dégrade significativement lorsqu'elle se trouve au milieu d'un long contexte. Découper un long document par section, en conservant la source sur chaque chunk, est un choix par défaut plus sûr que de supposer que le modèle lit tout le contexte de manière uniforme, et le jeu de recette montre ce qui vaut pour vos documents.

La sortie structurée a besoin d'un schéma, d'un validateur et d'une place pour la mauvaise réponse

Le décodage contraint limite le modèle à un JSON conforme à un schéma : vLLM le prend en charge sous le nom de structured outputs, et llama.cpp au moyen de grammaires. Il fixe la forme de l'enregistrement, dans la limite des fonctionnalités de schéma que le backend prend en charge et tant que la génération n'est pas coupée par la limite de tokens, mais pas sa véracité : un enregistrement bien formé peut tout de même contenir une date fausse.

La véracité se vérifie après le modèle, par du code auquel l'entreprise fait déjà confiance :

• Des contrôles de type et de format : dates, devises et identifiants à clé de contrôle, comme l'ISIN
• Des règles inter-champs, comme une date de fin de période qui ne peut pas précéder sa date de début
• Des vérifications par rapport aux données de référence que l'entreprise maintient déjà, comme un instrument ou un client connu
• Cohérence avec la source : chaque valeur extraite, avant normalisation, doit apparaître dans le passage qu'elle cite

La confiance que le modèle s'attribue lui-même est un garde-fou faible. Le GPT-4 Technical Report d'OpenAI, publié en 2023, montre que sur un benchmark à choix multiples le modèle pré-entraîné était très bien calibré et que le post-entraînement a réduit la calibration. Une certitude autodéclarée ou une probabilité de token est un signal à tester sur le jeu de recette, pas un seuil auquel se fier par défaut.

Un enregistrement qui échoue à un contrôle, quel qu'il soit, va dans une file de revue, et non dans le système aval. La file est un produit à part entière : il lui faut un responsable, un plan de capacité en heures de relecture, le passage source affiché à côté de chaque champ, et des corrections qui reviennent alimenter le jeu de recette.

Les tickets et les documents sont des entrées non fiables pour le modèle

Un ticket de support est un texte écrit par quelqu'un d'extérieur à l'entreprise, et un document peut porter des instructions que son expéditeur y a placées délibérément. L'OWASP Top 10 for LLM Applications 2025 place l'injection de prompt (prompt injection) en premier, y compris l'injection indirecte, où les instructions arrivent à l'intérieur d'un contenu externe que le modèle traite, comme un site web ou un fichier.

Trois entrées de cette même liste se traduisent en règles de conception pour un pipeline de documents :

• Injection de prompt (Prompt injection) : marquez chaque document et chaque ticket comme contenu non fiable, tenu à l'écart des instructions dans un template que l'expéditeur ne peut pas modifier
• Gestion inappropriée des sorties (Improper output handling) : validez la sortie du modèle avant qu'un système n'agisse dessus, comme vous valideriez une entrée venant d'un utilisateur
• Autonomie excessive (Excessive agency) : donnez au pipeline le moindre privilège dont sa tâche a besoin, pour qu'un modèle qui lit des tickets ne puisse ni clôturer des comptes ni envoyer des paiements

L'OWASP note aussi qu'on ne sait pas s'il existe une prévention infaillible de l'injection de prompt. Ce sont les contrôles de sortie et la limite de privilèges qui font l'essentiel du travail, pas la formulation du prompt.

Figer le modèle, le prompt et le parseur en une seule version

Le comportement d'un pipeline est le produit de plusieurs artefacts qui changent indépendamment les uns des autres. Traitez-les comme une seule release, et stockez son identifiant sur chaque enregistrement qu'elle produit :

• Les poids du modèle identifiés par checksum, avec la quantification et la version du serveur d'inférence
• Le template de prompt, le schéma de sortie et les paramètres de décodage
• Le moteur d'OCR, les règles de chunking et les validateurs
• La version du jeu de recette sur laquelle la release a été notée

Figer les versions ne rend pas les sorties identiques. Thinking Machines Lab a montré en septembre 2025 qu'un serveur d'inférence peut renvoyer des complétions différentes pour le même prompt à température zéro, parce que le résultat d'une requête dépend du nombre d'autres requêtes qui partagent son batch ; le même billet montre que des kernels invariants au batch éliminent ce phénomène au prix d'une perte de vitesse. À moins que le serveur n'utilise de tels kernels, la reproductibilité consiste à relancer le jeu de recette à chaque release et à comparer les scores, pas à attendre un texte identique.

Exploitation : capacité, files d'attente et l'heure où le serveur de modèle est en panne

La capacité se planifie en tokens, pas en documents. Mesurez la distribution de la longueur des entrées et des sorties sur le trafic réel, car une longue pièce jointe peut coûter autant que de nombreux tickets courts, et le temps de génération croît avec la longueur de la sortie.

Les systèmes de serving regroupent les requêtes en batches pour garder l'accélérateur occupé. Dans l'article sur vLLM, présenté à SOSP 2023, Kwon et ses collègues ont rapporté que la pagination du cache clé-valeur de l'attention améliorait le débit d'un facteur 2 à 4 à niveau de latence égal, par rapport aux systèmes qu'ils ont évalués. Des batches plus gros augmentent le débit et augmentent aussi la latence de chaque requête, ce qu'une file de back-office peut absorber et une étape interactive non, d'où la séparation des deux :

• Le travail interactif, comme le tri de tickets qu'attend un agent du support, avec sa propre capacité et un objectif de latence
• Le travail en batch, comme l'extraction nocturne, sur une file qui absorbe les pics et peut être mise en pause
• De la backpressure entre l'ingestion et le serveur de modèle : une file bornée et une limite de concurrence, pour qu'un afflux de documents attende ou soit refusé avec un signal de retry au lieu de surcharger le serveur
• Un traitement idempotent, avec le document pour clé, pour qu'un retry après un crash ne crée pas de second enregistrement
• Un repli sur le processus manuel quand le serveur de modèle est indisponible, pour que le travail attende une personne au lieu de disparaître

Le repli est ce qui rend l'activation du pipeline réversible. Le processus manuel qui existe aujourd'hui reste le socle, et le pipeline lui retire du travail champ par champ plutôt que de le remplacer à une date unique.

Surveiller les réponses, pas seulement les serveurs

Les tableaux de bord des serveurs disent si le pipeline a répondu. Ils ne disent pas si les réponses étaient justes, et un modèle qui se dégrade sur un nouveau template garde sa latence. Le monitoring d'un pipeline d'extraction ou de tickets couvre les deux :

• Le taux de passage en file de revue et les corrections des relecteurs, par champ, par type de document et par release
• Un échantillon régulier d'enregistrements automatisés, revérifiés par des personnes au regard des critères de recette
• Dérive des entrées : nouveaux expéditeurs, nouveaux templates, mélange des langues et longueur des documents
• Les échecs des validateurs par règle, qui peuvent révéler un nouveau format avant que les métriques d'exactitude ne bougent
• Les tokens, les heures d'accélérateur et l'âge de la file par type de document, à côté de la latence de chaque étape

Le Generative AI Profile du NIST, NIST AI 600-1, publié en juillet 2024, organise ce travail selon les quatre fonctions de son AI Risk Management Framework : gouverner, cartographier, mesurer et gérer. Les noms comptent moins que la conséquence : la mesure après le lancement est une activité identifiée et dotée de personnel, pas quelque chose que l'équipe du pilote fait quand elle en a le temps.

Déployer par champ et par type de document : shadow, assisté, puis automatisé

Activer le pipeline pour tout à une seule date réunit tous les risques en un seul événement. Un déploiement progressif les tient séparés :

• Shadow : le pipeline traite le trafic réel, n'écrit nulle part, et ses enregistrements sont comparés à ce que les personnes ont produit
• Assisté : le pipeline pré-remplit, une personne confirme chaque enregistrement, et les corrections sont comptées par champ
• Automatisé par champ et par type de document, uniquement là où le seuil de réussite tient sur le trafic réel, tout le reste restant revu
• Une bascule de retour au mode assisté, par type de document, que le responsable d'exploitation actionne sans approbation distincte quand un taux surveillé dépasse sa limite

Un pilote qui lit bien les documents et ne passe pourtant jamais en production n'a pas échoué à la lecture. On ne lui a jamais donné de jeu de recette à passer, de chemin de données qu'il avait le droit d'utiliser, de place pour ses mauvaises réponses ni de responsable pour le lendemain du lancement.

Le prestataire qui met cela en production demande vos documents avant votre choix de modèle

La question derrière cet article, qui peut installer un pipeline LLM dans votre propre infrastructure et le mettre réellement en production, se tranche par un test qui ne demande aucune liste de fournisseurs. Un prestataire qui fait ce travail pose des questions sur la recette et l'exploitation avant de recommander un modèle :

• Demande à examiner un échantillon de vrais documents et tickets, y compris les mauvais, dans votre environnement ou dans le cadre de votre accord sur les données, et demande comment le processus manuel les traite aujourd'hui
• Propose de construire d'abord le jeu de recette avec vos équipes, avec des seuils de réussite par champ, avant tout ajustement
• Liste chaque endroit où les données seront copiées, des poids et des index jusqu'aux logs, aux traces, aux données d'évaluation, à l'outil de revue et au monitoring, et montre que chacun reste à l'intérieur
• Place les validateurs, la file de revue et le repli sur le traitement manuel dans le même document de conception que le modèle
• Apporte une release qui fige ensemble modèle, prompt, schéma et parseur, et un déploiement par champ, du mode shadow au mode automatisé
• Nomme qui exploite le pipeline après le lancement, qui relit l'échantillon, et qui est appelé quand le serveur de modèle s'arrête

Chaque élément est un point que vous pouvez aborder dès la première conversation, et une réponse vague signifie que le travail manquant du pilote n'a pas encore été cadré.

La première question n'est donc pas de savoir quel modèle faire tourner dans votre périmètre. C'est de savoir quels champs, sur quels documents, vous accepteriez de voir automatisés, mesurés par rapport à quoi, et qui reprend les enregistrements qui échouent à la validation.

Ce qu'amBrain peut étayer publiquement au-delà de l'intégration en production décrite dans le résumé ci-dessus : amBrain construit des logiciels depuis 2019. Nous travaillons en trois formats : livraison complète, équipe dédiée ou ingénieurs intégrés à votre équipe.