Publié le 16 septembre 2026 à 11:00 · Publication originale
La démonstration est excellente.
Il retrouve les clauses importantes, résume les obligations et signale plusieurs risques.
La direction valide le projet.
Six mois plus tard, personne ne l'utilise en production.
Cette trajectoire est fréquente car un prototype répond à une question limitée: la technologie peut-elle accomplir la tâche?
Le déploiement industriel en ajoute beaucoup d'autres.
Que se passe-t-il lorsqu'un contrat contient 400 pages? Lorsqu'un document est mal numérisé? Lorsqu'une filiale utilise une clause différente? Lorsque 2.000 salariés interrogent simultanément le système? Lorsqu'une erreur concerne une obligation de plusieurs millions d'euros?
Le prototype travaille généralement dans un environnement préparé.
La production rencontre les exceptions.
Il faut alors intégrer l'outil aux systèmes existants, gérer identités et permissions, mesurer la qualité, prévoir les pannes, contrôler les coûts, journaliser les opérations et déterminer les cas nécessitant une validation humaine.
Même la définition de "ça marche" change.
Une démonstration peut convaincre avec vingt exemples.
Un service utilisé 100.000 fois par mois avec 1% d'erreurs produit 1.000 situations problématiques.
La fréquence transforme une faiblesse marginale en problème opérationnel.
Voilà pourquoi certaines organisations accumulent les expérimentations sans accumuler les capacités.
Elles savent démontrer.
Elles n'ont pas encore l'infrastructure permettant d'exploiter durablement ce qu'elles démontrent.
Passer en production impose aussi d'accepter que certaines performances doivent être refusées.
Une réponse incertaine peut être transmise à un humain. Une opération trop coûteuse peut utiliser un modèle plus petit. Une tâche trop risquée peut rester manuelle.
L'industrialisation commence lorsque l'entreprise connaît assez bien les limites du système pour décider où elle accepte de l'utiliser.
ULTRA®
En production, un changement de modèle devrait être traité comme une modification d'infrastructure.
Avant bascule, le nouveau modèle peut fonctionner en "mode fantôme": il reçoit une copie du trafic réel sans que ses réponses atteignent l'utilisateur. Ses sorties sont comparées au système actif sur taux d'erreur, latence p99, coût, appels d'outils et cas d'abstention.
Vient ensuite le déploiement canari: 1%, puis 5%, puis 20% du trafic, avec retour automatique si un SLO franchit son budget d'erreur.
La difficulté propre aux LLM est la dérive multidimensionnelle. Modèle, instruction système, RAG, reclasseur et outils peuvent évoluer indépendamment. Chaque réponse doit donc conserver la version exacte de toute la chaîne.
Les équipes parlent de "lineage": reconstruire quel graphe d'inférence a produit quelle sortie.
Sans cette filiation, un rollback du modèle peut laisser intacte la véritable cause de la régression.