Comment mesurer l’adoption de l’IA en entreprise ?
Le 1er octobre 2026, Anthropic a publié le récit de l’élargissement de sa collaboration avec Barclays. La banque exprime son objectif en part de développeurs qui utilisent Claude Code et ne cite aucun nombre de licences.
Mesurer l’adoption de l’IA consiste à suivre la part des personnes concernées qui utilisent réellement un outil dans leur travail, sur une période donnée. Le taux d’usage actif rapporté à une population cible en est l’indicateur de base. La valeur produite se mesure ensuite à part, avec ses propres indicateurs.
Ce que Barclays a annoncé, et ce qui reste un objectif
Selon le communiqué, Barclays vise 50 % de ses développeurs sous Claude Code d’ici la fin 2026, puis une majorité de ses ingénieurs logiciels en 2027. Ce sont des objectifs. Les chiffres constatés sont ailleurs : plus de 16 000 collaborateurs utilisent l’Assistant de connaissances de Barclays UK, plus d’un million de recherches y ont été traitées, et la division Global Markets fait classer et orienter environ 120 000 e-mails de clients par jour.
Ces données viennent d’un communiqué publié par Anthropic, qui reprend des déclarations de Barclays, et aucune vérification indépendante n’a été publiée. Elles servent ici d’exemple de méthode. Le texte ne dit rien de la valeur dégagée, et il ne détaille pas les contrôles appliqués : il indique seulement qu’une gouvernance et une supervision humaine encadrent les cas d’usage.
Pour une direction informatique française, l’enseignement est un choix de vocabulaire. Une cible exprimée en part de la population se contrôle, se discute en comité de direction et se compare d’un trimestre à l’autre. Une cible de la forme « N licences déployées » ne se contrôle que sur une facture.
Pourquoi un parc de licences ne dit-il rien de l’adoption ?
Une licence est un droit d’accès. Elle se commande à l’échelle d’un contrat, parfois avant que le premier utilisateur ait été formé, et elle reste facturée que la personne s’en serve chaque jour ou jamais. Un nombre de licences répond donc à la question de l’achat, sans rien dire de l’usage.
Ce qu’un nombre de licences cache
Deux entreprises affichent le même nombre de licences. Dans la première, la moitié des détenteurs ouvre l’outil chaque semaine. Dans la seconde, une poignée de passionnés l’utilise et le reste n’a jamais dépassé la page d’accueil. Le registre d’achat place ces deux entreprises au même niveau, alors que leur situation n’a rien de commun. La plus avancée n’a aucun moyen de le démontrer, la seconde peut se croire en avance.
Le problème grossit avec la taille. Plus un groupe est grand, plus l’écart entre le périmètre acheté et le périmètre réellement utilisé se creuse, et moins les chiffres remontés au comité exécutif permettent de le voir.
Les pilotes qui réussissent sans changer le travail
Le même angle mort se retrouve dans les études sur les projets d’IA. S&P Global a mesuré en 2025 que 46 % des preuves de concept d’IA sont abandonnées avant la production, et une étude du MIT de la même année conclut que 95 % des pilotes d’IA générative n’ont pas d’effet mesurable sur le compte de résultat. Ces deux chiffres portent sur des projets. Ils désignent pourtant la même difficulté : on sait compter ce qu’on a lancé, beaucoup moins ce qui est entré dans le travail quotidien.
Un pilote réussi sur le plan technique peut rester sans lendemain si personne ne regarde, quelques semaines plus tard, combien de personnes s’en servent encore. Notre analyse du passage du pilote à la production, dans l’article sur les projets IA bloqués entre pilote et production, part du même constat.
Quels indicateurs suivre à la place du nombre de licences ?
Un tableau de bord d’adoption tient sur quelques indicateurs, chacun avec un dénominateur explicite. Sans dénominateur, un pourcentage ne veut rien dire : 50 % de quoi, sur quelle période, avec quel seuil d’activité ?
Le taux d’usage actif par population cible
Le taux d’usage actif divise les utilisateurs de la période par la population qu’on voulait équiper. Est actif quiconque a utilisé l’outil au moins une fois sur la période. La période dépend du rythme du métier : la semaine pour une équipe de développement qui travaille en continu, le mois pour une fonction dont les tâches sont plus espacées. Le dénominateur est la population cible : prendre l’effectif de l’entreprise dilue la mesure dans des métiers pour lesquels l’outil n’a pas été pensé.
La profondeur d’usage
Le taux d’usage actif distingue ceux qui utilisent de ceux qui n’utilisent pas, il ne dit rien de la manière. Une personne qui pose une question par mois et une autre qui confie chaque jour des tâches entières comptent pour une unité chacune. La profondeur se lit dans la fréquence, la variété des tâches et les livrables aboutis : une demande de modification relue et fusionnée, un dossier traité, une synthèse envoyée.
Cette deuxième lecture est celle qui rapproche la mesure de la valeur. Elle reste un indicateur d’usage, et elle ne remplace pas les indicateurs métier, comme le temps de traitement ou le taux de reprise, qu’il faut fixer avant le déploiement.
La part du flux traitée sous supervision
Pour un agent qui traite un flux, l’indicateur naturel est un volume. Les 120 000 e-mails quotidiens de la division Global Markets de Barclays en sont un exemple : le nombre d’éléments classés et orientés vers le bon circuit. Un volume seul ne dit rien de la confiance qu’on peut lui accorder. Il faut lui associer la part des éléments relus par une personne et le taux de corrections apportées, car un taux de correction qui tombe à zéro signale souvent une relecture qui s’est arrêtée, et rarement une perfection du modèle.
Un même indicateur convient-il à un assistant, à un agent de code et à un agent de flux ?
Non. Le communiqué de Barclays décrit des usages de nature différente, et chacun appelle ses indicateurs et son niveau de contrôle. Les ranger sous un seul pourcentage d’« adoption de l’IA » mélange des risques qui n’ont rien en commun.
L’assistant de connaissances
Le Colleague Knowledge Assistant de Barclays UK, décrit comme reposant sur une architecture de génération augmentée par récupération avec Claude, sert les collaborateurs de la banque. L’indicateur principal est le taux d’usage actif de cette population de collaborateurs, complété par une mesure de la qualité perçue : la part des réponses jugées utiles par ceux qui les reçoivent. Le risque dominant est la réponse erronée donnée avec aplomb, et le contrôle passe par la qualité des sources indexées.
L’agent de code
Pour le développement logiciel, l’indicateur est la part des développeurs actifs, c’est celui que Barclays a retenu pour son objectif. Il se complète par la part du code généré qui passe la relecture et les tests. Le risque dominant est la dette silencieuse : du code accepté sans être compris. Notre page sur Claude Code en entreprise détaille le cadre de déploiement que nous recommandons autour de cet usage.
L’agent de flux
Un agent qui trie, enrichit ou oriente des messages agit à une échelle que personne ne relit en entier. L’indicateur est le volume traité, accompagné du taux d’escalade vers un humain et du taux de correction. Le risque dominant est l’erreur répétée mille fois avant d’être vue. C’est le terrain de la gouvernance : quelles décisions l’agent prend seul, lesquelles remontent, qui répond de lui. Les zones de confiance de la gouvernance LOOP™ servent à fixer ces limites avant de mesurer le volume, et notre page gouvernance de l’IA en donne le cadre général.
Comment fixer une cible d’adoption sans qu’elle devienne un chiffre de vitrine ?
Une cible d’adoption a deux défauts possibles. Elle peut être trop vague pour être contrôlée, ou trop précise pour résister à l’usage qu’on en fait : quand un chiffre devient un objectif de management, les comportements s’ajustent au chiffre, ce que les précautions suivantes permettent de limiter.
Choisir le dénominateur avant l’objectif
« 50 % des développeurs » n’a de sens que parce que la population de développeurs est définie : qui compte, dans quelles équipes, avec quels prestataires. Écrire cette définition avant de fixer le pourcentage évite de découvrir, en fin d’année, que le dénominateur a bougé. Pour un autre métier, comme la conformité ou la relation client, la définition prend plus de temps et mérite d’être faite avec les responsables.
Fixer le seuil d’« actif »
Un seuil trop bas fait de chaque connexion une adoption. Un seuil trop haut décourage les équipes qui avancent par paliers. Le seuil d’activité se décide métier par métier, en partant de l’usage observé chez les premiers utilisateurs sérieux plutôt que d’une valeur théorique. Il se révise lorsque l’outil change de nature, par exemple lorsqu’un assistant devient un agent qui exécute des tâches.
Associer chaque cible à un périmètre de gouvernance
Élargir l’usage sans élargir la responsabilité produit des incidents évitables. Avant de passer une population de 10 % à 50 % d’utilisateurs actifs, la question est de savoir qui valide les accès, qui relit, qui arrête l’agent. Le diagnostic de maturité IA de Koneetiv aide à situer l’organisation sur ces axes, et notre article sur les niveaux de maturité IA en entreprise explique pourquoi un niveau d’adoption élevé suppose un niveau de gouvernance comparable.
Par où commencer la mesure dans une direction informatique ?
La mesure démarre avec les données que l’entreprise possède déjà : les journaux d’usage de la plateforme de l’éditeur, les journaux d’authentification et la liste des équipes. Aucun outil nouveau n’est nécessaire pour un premier relevé.
- Choisir un usage précis et une population cible, par exemple les équipes de développement qui utilisent déjà un assistant de code.
- Écrire la définition d’« utilisateur actif » avec les responsables métier, période et seuil compris.
- Extraire des journaux existants le nombre d’utilisateurs actifs et diviser par la population cible.
- Ajouter un indicateur de profondeur, celui qui correspond à l’usage : livrables aboutis, volume traité ou taux de correction.
- Désigner une personne qui répond de l’indicateur, et réviser le périmètre à chaque revue trimestrielle.
Cette démarche tient dans un tableau partagé. Elle fait apparaître en général deux choses : des équipes qui avancent sans qu’on le sache, et des licences qu’on peut redistribuer. Pour aller plus loin sur la préparation des équipes, notre article Mon entreprise est-elle prête pour l’IA ? propose une grille de questions, et le hub Adopter l’IA en entreprise rassemble les autres analyses de ce cluster.
Notre lecture : la question utile à poser à un comité de direction est « quelle part de la population cible utilise l’outil, et sous quelle supervision ? ». Le nombre de licences n’en est que le plafond. Si vous voulez situer votre organisation avant de fixer une cible, le diagnostic de maturité IA est le point d’entrée.