Ce que dix ans d'IA en production m'ont appris

Je mets de l’IA en production depuis 2016, d’abord avec la vision par ordinateur et des modèles de langage, puis avec des LLM enrichis par RAG. À chaque génération, la difficulté se trouve moins dans le modèle que dans les données, l’intégration et l’organisation qui l’entourent.

Dès 2016, je dirigeais un lab d’innovation à la Société Générale, une vingtaine de personnes et une ribambelle de startups. Le mot « IA » était dans l’air, mais il désignait quelque chose de plus étroit qu’aujourd’hui : un peu de vision par ordinateur, dont la reconnaissance de caractères, des classifieurs de langage, et de la voix. On entraînait des modèles sur TensorFlow et PyTorch, puis sur AWS SageMaker, sur une machine qu’on avait montée nous-mêmes et gardée dans une pièce fermée à clé : un Threadripper, des cartes graphiques de gamer, plus de RAM que personne n’aurait validé deux fois. Les grands fournisseurs vendaient des services cognitifs à l’appel d’API, mais une banque ne pouvait pas leur envoyer ses données, alors on a construit les nôtres : OCR, reconnaissance et synthèse vocales, compréhension du langage, entièrement open source, sur une infrastructure qu’on maîtrisait, où les données restaient. Cet instinct, posséder l’outil et garder les données à la maison, est revenu des années plus tard.

L’une de ces expérimentations est devenue un chatbot qu’on avait appelé YODA, « Your Own Digital Assistant ». Il répondait aux questions que les collaborateurs envoyaient d’habitude à un humain avant d’attendre : IT, RH, conformité, les frictions quotidiennes d’une banque de plus de 150 000 personnes. On l’a industrialisé pour environ vingt mille utilisateurs, en français et en anglais, des années avant que ChatGPT n’apprenne le mot « prompt » à tout le monde. Ce n’était pas magique. C’était de la classification d’intention, une couche de récupération, et énormément de travail ingrat sur les données derrière, construit dans le lab avec Do You Dream Up comme partenaire sur le moteur conversationnel. Il a réellement soulagé les équipes de support, la seule métrique qui comptait.

Autour, on a construit ce qui semble anodin aujourd’hui et qui était difficile à l’époque : des pipelines de vision par ordinateur, dont de l’OCR sur Tesseract, des modèles de voix, et même quelques robots Pepper déployés juste pour comprendre ce qu’apportait une présence physique. La plupart ont marché. Certains non. Tous ont enseigné la même leçon.

Le modèle n’a jamais été le plus dur

Chaque vague d’IA arrive avec la même histoire : le modèle est la percée, et tout le reste est un détail. C’est l’inverse. Le modèle est la partie facile. C’est un téléchargement, un article, un appel d’API. Le plus dur, c’est tout ce qu’il y a autour.

Ce sont les données, sales, que personne ne possède proprement. C’est la production, où vivent les vrais modes de défaillance et où « ça marchait dans le notebook » ne veut rien dire. C’est la confiance, parce qu’une banque ne mettra pas une boîte noire devant un client, et elle a raison. C’est le coût d’exploitation, réel et récurrent, si facile à balayer d’un revers de main en démo.

J’ai passé ces années à apprendre à construire les parties qui ne sont pas le modèle. C’est ce qui a fait la différence à chaque fois que le modèle a changé.

La leçon n’a cessé de se vérifier

À Société Générale Equipment Finance, j’ai créé une digital factory à partir de rien à Berlin et mis en production une IA qui lisait les documents derrière une décision de financement. Le projet avait un nom qui disait l’objectif, Need for Speed, et un autre plus sobre pour les slides, KYC 4.0. Elle utilisait la vision par ordinateur, dont l’OCR, pour extraire les chiffres des bilans et du reste des documents KYB et KYC, puis du machine learning, entraîné sur Azure, pour faire les calculs et produire un score de risque. Elle ramenait à environ une journée une revue qui prenait deux semaines, en production, pas sur une slide.

La percée, ce n’était pas le modèle. C’était tout ce qu’on avait construit autour pour que les analystes risque lui fassent confiance. Ils relisaient chaque recommandation et pouvaient aller contre. En un clic, ils voyaient exactement d’où venait chaque chiffre : le document source, avec chaque donnée extraite encadrée et surlignée à sa place. Pas de boîte noire. La machine faisait l’extraction et l’arithmétique fastidieuses, l’analyste gardait le jugement. C’est pour ça que c’est parti en production, et que les gens s’en servaient vraiment. C’était né d’un hackathon, et c’est allé jusqu’en production. La même leçon, quatre ans plus tard.

Un modèle que nous pouvions exploiter nous-mêmes

Quelques années plus tard, chez Chantelle, l’IA générative était arrivée et la tentation était de traiter les modèles comme la réponse à toutes les questions. Nous ne l’avons pas fait.

Nous avons mis un système RAG en production pour les équipes e-commerce et service client : un bot dans Google Chat qu’elles pouvaient mentionner dans un canal, orchestré de bout en bout dans n8n, qui répondait à leurs questions sur nos systèmes et nos processus. Avec une confirmation explicite, il pouvait aussi déclencher des actions dans leurs outils au moyen de connecteurs MCP, officiels ou développés par nos soins. L’humain restait dans la boucle, comme avec le moteur de risque quelques années plus tôt. La première année, le système utilisait Gemini. En juin 2026, nous avons déployé notre propre Gemma affiné, auto-hébergé et servi avec vLLM, afin de mieux maîtriser la qualité, la latence et le coût. L’évaluation tournait en CI : un changement qui dégradait les réponses faisait échouer le build. Les retours réels alimentaient ensuite les données d’entraînement de l’itération suivante.

La meilleure mesure de son efficacité ne venait pas d’un tableau de bord. Au début, les utilisateurs adressaient encore leurs questions à mon équipe. Je leur demandais s’ils avaient essayé le bot. Ils répondaient qu’il n’avait pas trouvé la réponse, alors que la même question, reformulée ou reposée, fonctionnait. Cet écart entre les capacités de l’outil et la confiance qu’on lui accordait s’est réduit avec le temps. Les questions adressées à mon équipe ont diminué à mesure que l’usage progressait.

Le modèle a changé. La leçon, non. La qualité de la récupération l’emporte sur l’astuce du prompt. L’évaluation l’emporte sur l’intuition. C’est la plomberie ingrate qui décide si la chose est fiable ou seulement impressionnante en démo.

Ce que ça implique si vous évaluez l’IA aujourd’hui

Si vous dirigez une équipe à qui l’on demande de « faire quelque chose avec l’IA », voici ce qu’une décennie m’a appris.

Partez d’un problème qui vous coûte de l’argent ou du temps, pas de la technologie. Mesurez ce qui vous importe vraiment, avant et après. Partez du principe que le modèle est la partie la moins chère du système et répartissez votre effort en conséquence : les données, l’évaluation et la production sont là où se trouve le travail. Déployez à un petit groupe, apprenez, puis élargissez. Et soyez honnête sur le coût, car une fonctionnalité IA qui triple discrètement votre facture d’inférence n’est pas une victoire.

Rien de tout cela n’est nouveau. Je l’appliquais en 2016 avec des modèles qui feraient honte à un téléphone d’aujourd’hui. Les outils se sont améliorés. C’est la discipline qui se transmet.

C’est cette méthode que je souhaite appliquer dans mon prochain poste de direction : partir d’un problème réel, construire le système autour du modèle et mesurer son adoption.