IA en entreprise : ce n'est pas l'outil qui manque, c'est le bon outil

80% des projets IA échouent à passer à l'échelle. Résistance au changement, données, compétences... et si la vraie cause était plus simple : le mauvais outil ?

80% des projets IA ne passent pas à l'échelle. Ce chiffre circule dans tous les articles, dans toutes les conférences, comme une fatalité. On l'attribue à la résistance au changement, à la qualité des données, au manque de compétences. Ces raisons existent. Mais elles masquent une cause plus simple, plus structurelle, dont on parle peu : on a massivement utilisé le mauvais outil.

Le malentendu LLM

Le même scénario revient sans cesse dans les entreprises du secteur assurantiel : un POC lancé avec un grand modèle de langage, ChatGPT, Mistral, Gemini…, des mois de travail, des équipes mobilisées, et au final un projet qui ne tient pas en production. Trop d'erreurs, des coûts qui dérapent, des données qui ne peuvent finalement pas quitter l'infrastructure de ces géants du Cloud pour des raisons de politique de sécurité.

Les LLM sont des outils remarquables. Pour produire du contenu, synthétiser des documents, faire du conseil ou du marketing, ils sont imbattables. Mais ils sont conçus pour être universels. Un grand modèle est entraîné sur des milliards de paramètres, pour des millions d'utilisateurs différents. Il ne peut pas, structurellement être entraîné sur les données d'une organisation spécifique.

Or, automatiser la gestion de sinistres, le traitement de factures ou la relation client en assurance, ce n'est pas un problème de généralité. C'est un problème de précision, de répétabilité, de conformité. Ce sont exactement les cas d'usage où les LLM échouent, et où les Small Language Models, des modèles spécialisés, entraînés sur les données et les processus de l'entreprise elle-même, peuvent atteindre jusqu'à 99% de précision.

Prenons un exemple concret : la déclaration de sinistre. Dans un processus manuel, l'assuré appelle, un conseiller lui explique qu'il va recevoir un mail, qu'il faudra renvoyer ses pièces, que le traitement prendra deux à trois semaines. Avec un SLM entraîné sur les données et les règles métier de l'assureur, le même sinistre peut être traité en temps réel : l'agent répond à l'assuré, envoie immédiatement le formulaire adapté et vérifie la conformité des pièces à la seconde où elles arrivent. Ce niveau de précision et d'automatisation, un LLM généraliste ne peut tout simplement pas l'atteindre, parce qu'il n'a pas été formé pour ça.

La souveraineté n'est pas une option

Dans les secteurs régulés, la première question d'un DSI n'est pas "est-ce que ça marche ?". C'est "est-ce que nos données restent chez nous ?".

Un LLM dans le cloud ne peut pas répondre oui. Un SLM déployé on-premise le peut, parce que sa frugalité le rend économiquement possible. Ces modèles spécialisés sont plusieurs centaines de fois moins gourmands en ressources qu'un grand modèle. Ils peuvent tourner sur les serveurs de l'entreprise, avec une infrastructure matérielle d'un coût raisonnable. Aucune donnée ne transite vers l'extérieur, le modèle vit dans l'infrastructure de l'assureur.

Pour une entreprise soumise au RGPD, ce n'est pas un argument commercial. C'est un prérequis. Les grands comptes du secteur l'ont d'ailleurs bien compris : avant même de parler de cas d'usage ou de retour sur investissement, les équipes sécurité exigent des certifications,  ISO 27001, HDS pour les données de santé, qui attestent qu'aucune donnée sensible ne peut fuiter vers l'extérieur. C'est le ticket d'entrée. Et c'est précisément ce qui manquait jusqu'ici : une technologie suffisamment légère pour être souveraine sans sacrifier la performance.

Budget maîtrisé : l'avantage silencieux des SLM 

Il y a un troisième avantage, remonté régulièrement par les directions financières des assureurs, et qui brille pourtant par son absence dans les débats sur l'adoption de l'IA : la prédictibilité des coûts.

Les LLM accédés via API facturent en tokens, une unité dont le volume dépend directement de la taille des textes traités, des réflexions et du texte généré. Cette facturation à l'usage est difficile à anticiper : le budget d'un projet peut exploser entre la phase de test et la mise en production, simplement parce que les volumes réels dépassent les estimations initiales.

Par contre un SLM déployé on-premise échappe entièrement à cette logique. Le coût du service dépend de l'infrastructure matérielle installée chez l'assureur, et permet une prédictibilité parfaite, amortissable, défendable en COMEX, à partir du moment où l'on connaît les volumes qui transitent et que la facturation se fait à la volumétrie réelle. Dans un secteur où la maîtrise budgétaire est une discipline aussi rigoureuse que la gestion des risques, cette prévisibilité est un argument décisif, et pourtant presque invisible dans les comparatifs.

Beaucoup de projets d’IA n’ont pas encore atteint la dimension critique, non pas car ils se sont trompés de direction mais d’outil. On a proposé des solutions universelles pour des problèmes qui exigent de la spécialisation, de la souveraineté et de la prévisibilité. Ce sont exactement les trois choses qu'un grand modèle de langage ne peut pas offrir, et que les secteurs régulés ne peuvent pas se passer d'avoir.

Les assureurs qui commencent aujourd'hui à passer à l'échelle ne sont pas ceux qui ont choisi les modèles les plus puissants. Ce sont ceux qui ont choisi les modèles les plus adaptés à leurs contraintes réelles. C'est une leçon simple,  mais il a fallu quelques années d'expérimentations infructueuses pour l'apprendre.