VTB explique pourquoi les pilotes d'IA s'enlisent avant la production et comment l'architecture peut y remédier

Les 8–9 avril, lors de la conférence Data Fusion, VTB a reconnu publiquement un problème que connaît presque tout client corporate de l'IA : les pilotes convainquent, mais rares sont ceux qui arrivent jusqu'à une véritable mise en production. L'analyse ne porte pas sur la qualité d'un modèle isolé, mais sur l'architecture de déploiement elle-même.

Pourquoi les pilotes échouent

L'idée centrale est simple : un pilote teste généralement une seule étape dans des conditions contrôlées, alors qu'en production apparaît toute une chaîne d'actions où les erreurs s'accumulent. Si huit maillons affichent chacun une précision de 85 %, la fiabilité globale de la chaîne tombe à 27 %. En présentation, un tel système paraît encore « presque bon », mais dans un processus réel, trois résultats sur quatre sont faux — et, plus dangereux encore, impossible de savoir à l'avance lesquels. Le problème ne se manifeste donc pas comme un bug ponctuel, mais comme une dégradation systémique de la qualité lors du passage à l'échelle.

Une conclusion plus dérangeante en découle : le marché optimise souvent l'IA non pas pour la précision, mais pour l'autonomie. La métrique « quel pourcentage de tâches est accompli sans humain » est commode pour le marketing et les rapports, mais elle reflète mal la capacité du système à rester ancré dans la réalité sur la durée. L'article relie ce phénomène à l'automation bias et au deskilling : les utilisateurs se fient de plus en plus à des suggestions erronées tout en perdant la capacité de décider sans la machine. Au final, l'entreprise hérite non seulement d'un pipeline fragile, mais aussi d'une érosion progressive de sa propre expertise.

Une architecture avec l'humain

Plutôt qu'une autonomie totale, l'auteur propose un schéma à faible entropie où l'humain est intégré au système comme élément obligatoire, et non comme bouton d'arrêt d'urgence. Ce schéma répartit le travail sur quatre niveaux : de l'opérateur de terrain, au plus près de l'objet, jusqu'à l'expert métier qui vérifie les recommandations du modèle et réinjecte ses corrections dans l'entraînement. L'objectif : « purger » l'incertitude à chaque niveau, au lieu de la laisser remonter la chaîne sans contrôle.

• Niveau 0 — l'opérateur ou le spécialiste sur site, qui voit l'objet réel et valide les données d'entrée.
• Niveau 1 — des modèles spécialisés pour des signaux précis : température, humidité, défauts, images ou autres paramètres physiques.
• Niveau 2 — un coordinateur, qui agrège les résultats des modèles, raisonne et formule une recommandation à destination de l'humain.
• Niveau 3 — l'expert métier, qui confirme ou corrige la conclusion et fournit ainsi au système un signal d'apprentissage.

Dans cette construction, le rôle de l'IA n'est pas de remplacer le spécialiste, mais d'étendre son périmètre d'action et sa productivité. L'auteur cite l'exemple d'un jumeau numérique d'un écosystème forestier couvrant plus de 180 000 hectares : lorsque la couverture est passée de 2 000 à 50 000 hectares, les dépenses d'investissement ont été multipliées par 2,1, les dépenses opérationnelles par 2,2, tandis que l'équipe n'est passée que de quatre à huit personnes. Avec une approche traditionnelle, selon l'auteur, il aurait fallu plusieurs fois plus d'agents de terrain.

Pourquoi une API ne suffit pas

Un argument distinct concerne la stack. L'article affirme qu'un tel schéma est difficile à bâtir uniquement sur les API publiques des grands modèles, car l'expertise métier doit résider non pas dans les prompts, ni seulement dans le RAG, mais dans les poids d'un modèle contrôlé localement. L'auteur propose pour cela des adaptateurs LoRA ou QLoRA, affinés sur des paires vérifiées de réponses et de préférences d'experts. Après la journée de travail, les logs sont validés par un humain, le fine-tuning tourne la nuit, et le matin le système redémarre avec une connaissance du domaine mise à jour.

« Un prompt s'oublie à la fin de la fenêtre de contexte.

Un adaptateur, jamais. »

Cette logique mise sur une infrastructure en propre. Côté matériel, l'article avance un budget indicatif d'environ 900 000 à 1,2 million de roubles : un serveur équipé d'une RTX 4090 ou 5090 pour le coordinateur et l'entraînement nocturne, quelques Raspberry Pi pour les modèles spécialisés sur site et un stockage dédié aux logs. L'argument principal n'est pas que les modèles cloud seraient inutiles, mais qu'il vaut mieux les employer comme outil de recherche externe plutôt que comme couche de décision dans un circuit de production critique.

Ce que cela signifie

Pour le marché, c'est un tournant notable : la question n'est plus de savoir combien d'humains retirer du processus, mais comment préserver la qualité lors du passage à l'échelle de l'IA. Si cette logique s'impose, les déploiements en entreprise s'articuleront de plus en plus autour de modèles locaux, d'une vérification permanente et de boucles humain-machine, plutôt qu'autour de promesses d'autonomie totale.