VTB a expliqué pourquoi les projets pilotes AI se bloquent avant la mise en production et comment l’architecture peut y remédier

Les 8 et 9 avril, à la conférence Data Fusion de VTB, VTB a reconnu publiquement un problème familier à presque tout client d'IA en entreprise : les pilotes semblent convaincants, mais peu atteignent la production réelle. L'analyse porte non pas sur la qualité d'un modèle individuel, mais sur l'architecture de mise en œuvre elle-même.

Pourquoi les Pilotes Se Cassent

L'idée clé est simple : un pilote teste généralement une étape dans des conditions contrôlées, mais en production, toute une chaîne d'actions apparaît où les erreurs s'accumulent. Si huit maillons fonctionnent avec une précision de 85%, la fiabilité globale de la chaîne tombe à 27%. Dans une présentation, un tel système ressemble toujours à « presque bon », mais dans un processus réel, trois résultats sur quatre s'avèrent faux, et le plus dangereux est qu'il n'est pas clair d'avance lesquels.

C'est pourquoi le problème ne se manifeste pas comme un bug isolé, mais comme une dégradation systémique de la qualité lors de la mise à l'échelle. Cela mène aussi à une conclusion plus désagréable : le marché optimise souvent l'IA non pas pour la précision, mais pour l'autonomie. La métrique « quel pourcentage de tâches s'accomplissent sans intervention humaine » est pratique pour le marketing et les rapports, mais elle montre mal comment le système reste ancré à la réalité sur le long terme.

L'article relie cela au biais d'automatisation et au deskilling : les gens font de plus en plus confiance à des suggestions incorrectes et perdent simultanément la capacité à prendre des décisions sans la machine. En résultat, l'entreprise n'obtient pas seulement un pipeline fragile, mais aussi une érosion progressive de sa propre expertise.

Architecture Avec les Humains

Au lieu d'une autonomie totale, on propose un schéma à basse entropie, où les humains sont intégrés dans le système comme un élément obligatoire, pas comme un bouton de secours. Il divise le travail en quatre niveaux : d'un opérateur sur le terrain près de l'objet à un expert de domaine qui vérifie les recommandations du modèle et réinjecte les corrections dans l'entraînement.

La logique est de « décharger » l'incertitude à chaque niveau plutôt que de la laisser remonter incontrôlée dans la chaîne.

• Niveau 0 — un opérateur ou spécialiste sur place qui voit l'objet réel et valide les données d'entrée.
• Niveau 1 — modèles étroits pour des signaux spécifiques : température, humidité, défauts, images ou autres paramètres physiques.
• Niveau 2 — un coordonnateur qui collecte les résultats des modèles, raisonne et formule une recommandation pour les humains.
• Niveau 3 — un expert de domaine qui confirme ou corrige la conclusion et fournit ainsi un signal d'apprentissage au système.

Dans une telle conception, la tâche de l'IA n'est pas de remplacer le spécialiste, mais d'élargir son champ d'action et sa productivité. L'auteur donne l'exemple d'un jumeau numérique d'un écosystème forestier couvrant plus de 180 mille hectares : alors que la couverture passait de 2 à 50 mille hectares, les dépenses en capital ont augmenté de 2,1 fois, les dépenses opérationnelles de 2,2 fois, et l'équipe n'a augmenté que de quatre à huit personnes. Avec une approche traditionnelle, selon l'estimation de l'auteur, beaucoup plus de personnel de terrain aurait été nécessaire.

Pourquoi l'API Ne Suffit Pas

Un point séparé concerne la pile technologique. L'article affirme qu'un tel schéma est difficile à construire uniquement sur les APIs publiques de grands modèles seuls, car l'expertise de domaine doit vivre non pas seulement dans les prompts ou le RAG, mais dans les poids d'un modèle contrôlé localement. Pour cela, des adaptateurs LoRA ou QLoRA sont proposés, qui sont 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 les humains, l'affinement s'exécute la nuit, et le matin le système démarre avec une connaissance de domaine mise à jour.

« Un prompt est oublié à la fin de la fenêtre de contexte.

Un adaptateur — jamais. »

Cette logique mise sur une infrastructure propre. L'indice matériel mentionné dans le matériel est d'environ 900 mille à 1,2 million de roubles : un serveur avec RTX 4090 ou 5090 pour le coordonnateur et l'entraînement nocturne, plusieurs Raspberry Pi pour les modèles étroits sur site, et un stockage de logs séparé. L'argument principal n'est pas que les modèles en cloud sont inutiles, mais qu'ils sont mieux utilisés comme un outil de recherche externe plutôt que comme une couche de prise de décision dans des boucles de production critiques.

Ce Que Cela Signifie

Pour le marché, c'est un tournant important : la question n'est plus combien de personnes on peut supprimer du processus, mais comment maintenir la qualité lors de la mise à l'échelle de l'IA. Si cette logique prend pied, les mises en œuvre en entreprise seront de plus en plus construites autour de modèles locaux, de vérification continue et de boucles humain-machine, plutôt que autour de promesses d'autonomie totale.