Des licences achetées ne font pas une adoption : mesurer l'usage réel d'un outil IA

Quand je demande où en est l'adoption d'un outil IA, la réponse la plus fréquente est un nombre de licences. C'est une réponse à une autre question, celle de la dépense engagée.

La métrique de vanité : le nombre de sièges

Un siège attribué mesure une décision d'achat, pas un usage. Il reste identique que le collaborateur ouvre l'outil tous les jours ou qu'il ne s'y soit jamais connecté depuis la session de lancement. Pire, il reste identique jusqu'à la date de renouvellement, donc pendant toute la période où une correction aurait encore été possible.

Le taux de connexion au moins une fois, souvent brandi en comité, ne vaut guère mieux. Ouvrir un outil une fois par curiosité produit exactement la même ligne dans le tableau de bord qu'un usage quotidien installé.

Quatre mesures qui veulent dire quelque chose

L'usage récurrent à trente jours

La question n'est pas combien de personnes ont essayé, mais combien utilisaient encore l'outil trente jours après leur première connexion. Cet indicateur écrase le pic de curiosité du lancement, qui fausse toutes les lectures faites les deux premières semaines.

Un écart important entre le nombre d'essais et le nombre d'usages persistants ne signale pas un défaut de formation. Il signale que l'outil n'a pas trouvé sa place dans une tâche réelle.

La profondeur d'usage

Un collaborateur qui pose trois questions courtes par semaine et un collaborateur qui a intégré l'outil dans une production régulière apparaissent identiques dans un décompte d'utilisateurs actifs. Ils ne le sont pas.

J'observe le nombre d'échanges par session et la nature des tâches confiées. Le passage du ponctuel au récurrent se voit nettement : les sessions s'allongent, et surtout elles portent sur des livrables qui comptent plutôt que sur des essais périphériques.

Le retour après abandon

Celui-ci est peu utilisé et je le trouve le plus révélateur. Parmi les personnes qui ont cessé d'utiliser l'outil pendant plusieurs semaines, combien y reviennent spontanément.

Un taux de retour significatif indique que l'outil a créé un manque, donc une valeur perçue réelle. Un taux de retour nul indique que l'abandon était définitif, quelles que soient les déclarations de satisfaction recueillies par ailleurs. Le meilleur remède se prend en amont : impliquer les utilisateurs avant le développement.

L'écart entre usage déclaré et usage constaté

Les enquêtes internes surestiment systématiquement l'usage, pour une raison simple : répondre qu'on n'utilise pas l'outil que l'entreprise vient de payer est inconfortable. Comparer les déclarations d'un sondage aux données d'usage réelles, quand l'outil les fournit, donne la mesure de cet écart.

Cet écart est en lui-même une information de pilotage. Un écart large signale une pression implicite à déclarer un usage, donc un climat où les retours négatifs ne remonteront pas non plus.

Ce que ces chiffres changent dans la discussion budgétaire

Une direction financière ne sait pas quoi faire d'un taux de satisfaction. Elle sait quoi faire d'un nombre d'utilisateurs récurrents rapporté au coût par siège.

Ces indicateurs permettent surtout de poser la bonne décision au renouvellement : réduire le nombre de licences et concentrer l'accompagnement sur les usages qui tiennent, plutôt que reconduire à l'identique en espérant que ça décolle. J'ai rarement vu une reconduction à l'identique produire un usage différent l'année suivante.

Pour chiffrer ce qu'un usage réellement installé fait gagner, plutôt que de le supposer, mon calculateur de ROI d'automatisation donne une base de discussion à partir des paramètres réels du poste concerné.

Ce que je mets en place au démarrage

Je définis ces quatre mesures avant l'ouverture des accès, pas après. La raison est mécanique : l'usage récurrent à trente jours et le retour après abandon exigent une date de référence par utilisateur, impossible à reconstituer plus tard.

Je fixe aussi le point de décision à l'avance, avec une date et un seuil, exactement comme pour un pilote d'agent IA qui doit pouvoir être arrêté. Sans ce point de décision, le déploiement se prolonge par inertie budgétaire jusqu'à la date de renouvellement. C'est le point de départ de mon approche de la conduite du changement sur les déploiements d'IA.

Enfin, je croise ces mesures avec le diagnostic ADKAR, parce qu'un chiffre bas dit qu'il y a un blocage sans dire lequel. Les métriques localisent le problème dans le temps, la grille de diagnostic le localise dans la séquence d'adoption. Cette complémentarité entre mesure et pilotage est au cœur de ce que change le métier de delivery manager augmenté par l'IA.