Mesurer pour scaler : le problème qui bloque l'IA en entreprise
Il y a deux ans, la plupart des dirigeants que je connais débattaient du choix de modèle de langage à adopter. Aujourd'hui, ceux qui ont déjà tranché cette question — et qui peinent malgré tout à justifier un second cycle d'investissement — commencent à comprendre que le problème n'a jamais été le modèle. C'était la mesure.
Le secteur des entreprises adopte l'intelligence artificielle à un rythme soutenu depuis plusieurs années. Selon McKinsey, 88 % des organisations ont intégré l'IA dans au moins une fonction métier. Mais seulement un tiers d'entre elles a commencé à la déployer à grande échelle avec cohérence. Cet écart — entre expérimenter et scaler — n'est pas d'ordre technologique. Il est organisationnel, et trouve son origine dans une conversation que la majorité des équipes dirigeantes a évité d'avoir avec précision : ce que signifie, en termes opérationnels et financiers, que tout cela fonctionne.
Chez Sustainabl, nous observons depuis un moment la manière dont les entreprises construisent leurs dossiers d'investissement en IA. Ce que nous constatons le plus souvent n'est pas une incompétence technique. C'est une confusion de couches : on mesure ce que le fournisseur livre — scores sur des tests standardisés, précision en laboratoire, classements comparatifs — et on oublie de mesurer la seule chose que le conseil d'administration a besoin de voir : ce qui a changé dans l'entreprise.
Le piège du benchmark et ce qu'il révèle sur le leadership
Lorsqu'une équipe dirigeante évalue des modèles d'IA en comparant des scores de référence, elle répète une erreur que le monde technologique a déjà commise avec les serveurs dans les années quatre-vingt-dix : acheter des spécifications plutôt que des résultats. Le problème n'est pas que les benchmarks soient inutiles. C'est qu'ils répondent à une question différente.
Les benchmarks mesurent à quel point un modèle résout des tâches standardisées, dans des conditions contrôlées, avec des données qui n'ont rien à voir avec les flux réels de votre entreprise, votre base de connaissances propriétaire ni vos cas limites spécifiques. Ce qui se produit en production — avec les données dont vous disposez, les processus déjà en place et les utilisateurs qui interagissent quotidiennement — peut différer de ces métriques de 15 à 25 points de pourcentage. Cet écart n'est pas un détail technique. C'est la distance entre une promesse de fournisseur et un résultat métier.
Ce qui m'intéresse ici n'est pas l'ingénierie du modèle. Ce qui m'intéresse, c'est ce que cette confusion révèle sur le fonctionnement des organisations lorsqu'elles font face à une nouvelle technologie. Il existe un schéma récurrent : face à l'incertitude, le leadership tend à déléguer le critère de succès au domaine technique. On adopte le langage des ingénieurs — précision, rappel, score F1 — sans le traduire dans le langage de l'entreprise. Et cela n'arrive pas parce que le leadership est incompétent. Cela arrive parce que personne n'a voulu avoir la conversation inconfortable qui consiste à définir ce que signifierait échouer avec cet investissement.
Cette conversation a un coût. Lorsqu'un projet d'IA arrive à 90 jours sans pouvoir montrer de mouvement dans aucun indicateur opérationnel, le débat devient politique avant de devenir analytique. Chaque département défend son interprétation, personne ne veut endosser la responsabilité du résultat et le projet se maintient par inertie ou est annulé par frustration. Ces deux dénouements sont évitables si l'équipe dirigeante établit dès le départ — avant de choisir un modèle, avant de sélectionner un fournisseur — quels indicateurs métier vont évoluer et de combien.
Ce qu'un directeur financier a besoin d'entendre
Il existe un test que j'applique mentalement lorsque j'examine des propositions d'investissement en IA : imaginer le directeur financier lisant le dossier métier douze mois après le déploiement. Si le document ne peut montrer que le modèle a obtenu 93 % sur un benchmark de raisonnement, le projet est en danger. Non pas parce que ce chiffre est sans intérêt, mais parce qu'il ne répond à aucune des questions qu'un directeur financier pose lorsqu'il autorise une seconde année de budget.
Les vraies questions sont les suivantes : de combien a diminué le temps de résolution par dossier, dans quelle mesure le taux de résolution au premier contact s'est-il amélioré, quel est le coût de chaque interaction assistée par IA par rapport à une interaction entièrement manuelle, combien de temps les nouveaux agents ont-ils mis pour atteindre un niveau opérationnel acceptable. Ces métriques ne sont pas fournies par le modèle. Elles sont fournies par l'architecture complète du système : la qualité des données, la conception de la récupération d'information, la latence d'intégration, les mécanismes de contrôle. Le modèle est une variable au sein de ce système. Fréquemment, ce n'est pas la variable la plus déterminante.
Ce qui est mesuré en production, sur les données propres de l'entreprise et avec les cas limites réels du métier, est ce qui détermine si la solution délivre de la valeur. Un modèle plus modeste, mieux calibré sur la base de connaissances spécifique et sur les patterns linguistiques du client, peut surpasser de manière constante un modèle plus sophistiqué qui n'a jamais été ajusté à ce contexte. J'ai vu cela se produire dans des centres de contact du secteur des services publics : le modèle « vainqueur » du benchmark a finalement été remplacé par un modèle plus simple qui obtenait de meilleures performances sur les vraies requêtes des clients.
L'implication est directe : le modèle doit être traité comme un composant interchangeable, et non comme l'identité du projet. Les organisations qui conçoivent leurs architectures avec cette logique — en séparant la couche du modèle de la couche applicative — peuvent substituer un modèle sans démonter toute la solution. Celles qui ne le font pas se retrouvent prises dans une dépendance technique qui renchérit toute amélioration future.
Un cadre en trois couches qui survit aux cycles budgétaires
Après avoir observé de multiples déploiements dans des secteurs industriels et de services, la structure de mesure qui démontre la plus grande durabilité n'est pas la plus sophistiquée. C'est la plus lisible pour l'ensemble de la chaîne de commandement, de l'équipe technique jusqu'au conseil d'administration.
La première couche mesure la précision en production : quel pourcentage des résultats générés par le système sont corrects sans correction humaine, mesurés par rapport aux données réelles de l'entreprise et à ses cas extrêmes. Pas le taux de précision que rapporte le fournisseur. Celui qui émerge des interactions réelles avec les utilisateurs et les experts internes.
La deuxième couche mesure l'efficacité opérationnelle : si le temps de traitement a diminué, si les taux de résolution se sont améliorés, si les escalades ont diminué. Ce sont les métriques qui justifient de poursuivre. Un déploiement qui ne peut pas montrer de mouvement dans au moins l'un de ces indicateurs dans les quatre-vingt-dix premiers jours présente un problème quelque part dans la pile technique, et attendre plus longtemps pour le savoir ne fait qu'augmenter le coût de correction.
La troisième couche mesure l'impact financier : le coût par interaction assistée par rapport à l'interaction entièrement manuelle, la période de récupération de l'investissement, les économies attribuables. C'est la couche qui transforme le projet en actif dans le bilan des décisions dirigeantes. Sans elle, la conversation sur l'IA reste dans le domaine des enthousiastes de la technologie, et non dans celui des personnes qui allouent le capital.
Ce qui fait fonctionner ce cadre n'est pas sa complexité. C'est qu'il oblige l'organisation à avoir la conversation de définition avant de déployer. Définir trois à cinq indicateurs métier spécifiques pour chaque cas d'usage, avant de sélectionner un modèle ou un fournisseur, n'est pas un exercice méthodologique. C'est le signal que le leadership comprend à quoi il s'engage et avec quel critère il évaluera si l'objectif a été atteint.
Celui qui mesure bien, scale. Celui qui ne le fait pas, itère sans direction
Le contexte réglementaire ajoute de l'urgence à cette conversation. La réglementation européenne sur l'intelligence artificielle, en vigueur depuis août 2024 avec une applicabilité élargie à partir d'août 2026, exige que les organisations non seulement déploient des systèmes d'IA, mais soient en mesure de démontrer que ces systèmes fonctionnent dans des paramètres définis, auditables et non discriminatoires. Cela n'est pas possible sans une infrastructure de mesure active. Les entreprises qui disposent déjà de tableaux de bord de suivi des indicateurs opérationnels se trouvent, sans l'avoir nécessairement prévu, mieux positionnées pour répondre aux exigences de gouvernance qui arriveront.
Mais la réglementation est l'argument minimal. L'argument de fond est celui de la maturité organisationnelle.
Les entreprises qui parviennent à scaler l'IA ne sont pas nécessairement celles qui ont choisi le meilleur modèle. Ce sont celles qui ont construit la discipline de mesurer, d'ajuster et de communiquer des résultats avec une précision suffisante pour maintenir le soutien interne dans la durée. Cette discipline exige que quelqu'un au sein de l'équipe dirigeante assume l'inconfort de dire : « Nous ne savons pas encore si cela fonctionne parce que nous n'avons pas défini à temps ce que cela signifierait que ça fonctionne. »
Il existe des organisations où cette conversation n'a jamais eu lieu parce qu'aucun dirigeant n'a voulu être celui qui remettrait en question l'enthousiasme de l'équipe, ou parce que le pilote est arrivé avec trop de bruit politique pour que quelqu'un ose proposer des critères d'échec clairs. Le résultat est ce que nous observons fréquemment : des projets qui se maintiennent dans des itérations sans direction, avec des équipes techniques qui optimisent des métriques que personne au comité de direction ne peut interpréter, et des dirigeants qui approuvent des budgets supplémentaires par crainte de reconnaître que le premier investissement n'a pas livré ce qu'il promettait.
L'IA ne résout pas ce problème. Elle l'amplifie. Un système qui génère des centaines de milliers d'interactions par semaine amplifie à la fois la valeur et l'erreur. Si vous ne savez pas ce que vous mesurez, vous ne saurez pas non plus ce que vous multipliez.
Le modèle va toujours s'améliorer. Les fournisseurs lanceront des versions plus capables dans des cycles de plus en plus courts. Ce qui ne change pas par lui-même, c'est la capacité d'une organisation à établir des critères clairs avant d'agir, à mesurer honnêtement ce qui se passe et à ajuster sans avoir besoin de reconstruire le projet depuis zéro. Aucun modèle ne livre cela. C'est le leadership qui le construit — ou personne ne le fait.
