Mesurer l’adoption réelle : au-delà du nombre de licences

Cent licences payées, quinze utilisateurs réguliers : ce ratio, nous le retrouvons dans la majorité des entreprises que nous auditons. Le nombre de licences ne mesure pas l’adoption de l’IA — il mesure une ligne budgétaire. Pour savoir si l’investissement produit quelque chose, la mesure d’adoption IA doit porter sur trois dimensions : la fréquence d’usage, la profondeur des tâches confiées, et le nombre de process réellement couverts.

Ces trois métriques racontent trois histoires différentes. La fréquence dit si l’outil est entré dans les habitudes. La profondeur dit s’il sert à autre chose qu’à reformuler des mails. La couverture dit si l’entreprise — pas seulement des individus — a changé sa façon de travailler. Une seule des trois qui stagne, et le ROI promis reste théorique.

Pourquoi le taux d’équipement est une métrique de vanité

« 100 % des équipes sont équipées » est la phrase préférée des bilans de fin d’année — et elle ne dit rien. Une licence attribuée peut recouvrir un usage quotidien structuré comme une connexion unique le jour de la formation. Compter les licences, c’est mesurer l’intention de la direction, pas le comportement des équipes.

Le même piège existe côté volume brut : nombre de conversations, de requêtes ou de tokens consommés. Un gros volume peut venir de trois passionnés pendant que quarante collègues n’ouvrent jamais l’outil. Ces chiffres ont un usage — le suivi des coûts — mais aucun ne répond à la question qui compte : est-ce que la façon de travailler a changé ? Le danger des métriques de vanité n’est pas seulement de flatter : c’est qu’elles retardent le diagnostic. Tant que le tableau affiche « 100 % équipés », personne ne cherche pourquoi l’usage réel plafonne.

Les trois métriques qui mesurent l’adoption réelle

Trois indicateurs, chacun avec un seuil d’alerte lisible, suffisent à piloter un déploiement :

• Fréquence : le nombre de jours d’usage actif par personne et par semaine. Un usage réel se situe à trois jours et plus ; en dessous d’un jour par semaine, la licence est décorative.
• Profondeur : la nature des tâches confiées — reformulation ponctuelle, production d’un livrable complet, ou exécution d’un process de bout en bout avec contextes et skills. C’est l’échelle qui sépare le gadget de l’outil de travail.
• Couverture : le nombre de process d’équipe identifiés qui passent effectivement par l’IA — revue de code, qualification de leads, réponse aux appels d’offres, reporting mensuel. C’est la seule des trois métriques qui appartient à l’organisation et non aux individus.

Comment instrumenter la mesure sans usine à gaz ?

La fréquence s’obtient depuis les consoles d’administration des outils : utilisateurs actifs par jour et par semaine, par équipe. La profondeur et la couverture, elles, ne tombent pas d’un dashboard : elles se relèvent en listant les process cibles de chaque équipe au démarrage, puis en cochant chaque mois ceux qui sont passés à l’IA, avec le temps gagné estimé par les intéressés. Ce relevé manuel a une vertu cachée : il oblige chaque responsable d’équipe à regarder ses process en face une fois par mois, ce qu’aucun outil de tracking ne provoque.

L’ensemble tient sur une page, mis à jour mensuellement, présenté au même comité qui a validé le budget. C’est le pilier pilotage d’un Harness d’entreprise — la couche d’orchestration entre Claude et vos process : sans ce tableau de bord, personne ne peut dire si le système produit, ni où investir ensuite.

Que faire quand les chiffres sont mauvais ?

Une fréquence basse signale presque toujours un problème de confiance ou de formation : les équipes n’ont pas vu l’outil traiter leurs cas réels et concrets. La réponse est un entraînement pratique sur leurs propres tâches, pas un mail de relance de plus.

Une profondeur faible signale un problème d’équipement : sans contextes métier ni skills, chaque usage repart de zéro et plafonne aux tâches triviales. Une couverture faible, enfin, signale un problème de priorisation : personne n’a désigné les process à transformer ni qui en est responsable. Trois diagnostics différents — que le seul comptage des licences aurait tous masqués. C’est pour installer ces trois mesures dès la première semaine que notre programme commence par un audit des process, pas par une distribution de comptes.