Mesurer l'adoption, pas la satisfaction

Mesurer l’adoption d’un outil d’IA consiste à relever ce que les utilisateurs font réellement du système, à quelle fréquence et avec quelle profondeur, plutôt que ce qu’ils déclarent en penser.

La satisfaction est une opinion recueillie à un instant donné. L’adoption est un comportement observé dans la durée : une personne revient-elle vers l’outil quand elle a une tâche à accomplir ?

Cette mesure repose sur trois matériaux : les journaux d’usage du système (qui l’utilise, combien de requêtes, sur quelles fonctions), une population cible définie à l’avance qui sert de dénominateur, et quelques observations directes du travail. Un questionnaire peut les compléter, jamais les remplacer. Et la mesure sert à décider : un indicateur qui ne conduit ni à étendre, ni à corriger, ni à arrêter n’est qu’un graphique de plus.

La satisfaction déclarée sur un outil d’IA est presque toujours élevée, parce qu’elle mesure la nouveauté et la bienveillance envers le projet, pas l’usage qui suivra. Personne n’a envie de critiquer un projet dans lequel la direction s’est engagée.

Sur les missions que j’ai observées, j’ai vu des enquêtes à quatre-vingt-dix pour cent de satisfaction sur des outils dont le taux d’usage réel, six semaines plus tard, était inférieur à cinq pour cent. Ce sont des cas, pas une loi ; mais ils montrent que les deux chiffres ne mesurent pas la même chose, et qu’un seul décide de la suite.

Le biais est structurel : ceux qui ont abandonné ne répondent pas, et la question « l’outil vous semble-t-il utile ? » appelle un oui de principe. On peut juger un outil utile et ne jamais l’ouvrir.

Les quatre indicateurs d’adoption se calculent à partir des journaux d’usage et d’une population cible fixée avant le lancement, sans enquête ni outil d’analyse spécialisé.

Le dénominateur est le point le plus souvent négligé : rapporter les utilisateurs actifs aux licences ouvertes plutôt qu’à la population qui devrait s’en servir flatte le résultat. Le taux de reprise manuelle, lui, est le seul qui ne se lit pas dans les journaux ; il demande un échantillon revu avec les utilisateurs.

Six semaines est un repère empirique tiré de mes missions, pas une norme : c’est le délai au bout duquel, sur les déploiements observés, la curiosité initiale était retombée. Avant ce délai, la courbe d’usage reflète surtout la curiosité ; après, surtout l’utilité.

Sur les systèmes que j’ai suivis, un usage qui tenait à six semaines tenait en général à six mois, et un usage effondré dès la quatrième semaine n’est pas remonté tout seul. La cause était presque toujours la même : l’outil était à côté du travail plutôt que dedans.

Pour une tâche mensuelle, comme une clôture ou un reporting, il faut raisonner en cycles et attendre deux ou trois occurrences de la tâche. Le principe ne change pas : on juge l’usage quand il ne doit plus rien à l’effet de lancement.

Le nombre de questions posées par utilisateur actif, suivi semaine par semaine, décroche plusieurs semaines avant que l’usage global ne baisse. C’est, d’expérience, l’indicateur avancé le plus utile.

Sur les cas que j’ai suivis, ce décrochage se voyait trois à quatre semaines avant la chute du nombre d’utilisateurs actifs, ce qui laissait le temps d’intervenir. L’intervention la plus utile : interroger quelques utilisateurs dont la fréquence baisse, plutôt que relancer une communication générale. Le tableau de bord correspondant est décrit dans l’observabilité des systèmes IA.

Un système lent est abandonné même quand ses réponses sont bonnes, et cette cause n’apparaît dans aucun tableau de bord de qualité. C’est la cause d’abandon la plus sous-estimée.

Un utilisateur qui attend trop longtemps développe une stratégie de contournement : il fait autrement, il demande à un collègue, il retourne à sa recherche manuelle. Ce contournement ne produit aucun signal : ni erreur, ni plainte, seulement une baisse d’usage.

J’ai repris des systèmes dont les réponses étaient excellentes et l’usage quasi nul, avec, dans un cas, une latence moyenne de huit secondes. Sur ce cas, la diviser par trois a fait plus pour l’adoption que six mois d’amélioration de la qualité : une observation de mission, pas une règle, mais qui rejoint ce qui est détaillé dans la latence devient un critère de conception.

Trois causes expliquent l’essentiel des baisses d’usage d’un outil d’IA : la lenteur, le vieillissement du corpus et la dérive des usages, qui se distinguent en une demi-journée. Les confondre conduit à corriger la mauvaise.

La première est la lenteur : les utilisateurs contournent un système qui fait attendre, sans jamais le dire. Elle se mesure au temps jusqu’à la première réponse, au quantile élevé et non en moyenne.

La deuxième est le vieillissement du corpus : le système répond sur des documents périmés, quelques utilisateurs s’en aperçoivent, et la confiance se perd bien plus vite qu’elle ne s’était installée.

La troisième est la dérive des usages : les questions posées ne sont plus celles pour lesquelles le système a été conçu, et le taux d’échec monte sans que rien n’ait changé côté technique. Ces trois causes et leur traitement sont détaillés dans ce qui occupe l’équipe la deuxième année.

La mesure de l’adoption d’un outil d’IA se met en place en cinq étapes, dont trois doivent être faites avant la mise en service, faute de quoi aucune comparaison ne sera possible.

1. Définir la population cible : les personnes dont le travail devrait changer, par nom ou par fonction. C’est le dénominateur de tous les indicateurs.
2. Relever la situation de départ : temps passé à chercher une information, délai de traitement d’une demande, volume traité par semaine.
3. Instrumenter le système : journaliser chaque requête avec l’utilisateur, la fonction appelée, la durée de réponse et, quand c’est possible, l’usage fait du résultat.
4. Suivre chaque semaine les quatre indicateurs et le nombre de questions par utilisateur actif, sur un tableau partagé avec le métier dès le premier jour.
5. Fixer à l’avance la date de décision, à six semaines ou après deux ou trois cycles de la tâche, ainsi que les seuils qui feront étendre, corriger ou arrêter.

La cinquième étape est celle qu’on oublie : sans date ni seuil fixés à l’avance, on décide sur l’impression du moment, toujours favorable. C’est la logique de l’évaluation continue.

Les indicateurs d’adoption servent à deux décisions, étendre ou arrêter un outil d’IA, et chacune doit s’appuyer sur des chiffres partagés avec le métier depuis le début.

Étendre un système peu utilisé est l’erreur la plus fréquente, parce que l’enthousiasme de la direction ne s’appuie sur rien de mesuré. Trois situations se distinguent. L’usage tient et la reprise manuelle reste faible : on étend, vers une population proche de la première. L’usage tient mais se concentre sur une fonction, ou la reprise reste haute : on corrige avant d’étendre. L’usage s’effondre et l’outil est à côté du travail : on arrête, ou on revient au cadrage.

Arrêter proprement est une décision saine, rarement un échec du modèle : c’est souvent un des verrous décrits dans sortir du prototype : les cinq verrous, et parfois le symptôme d’un projet qui n’aurait pas dû dépasser le stade décrit dans l’anatomie d’un PoC qui ne passe jamais.

Un service d’IA dont personne ne sait ce qu’il apporte est arbitré à la baisse au premier exercice budgétaire contraint, quelle que soit la qualité réelle de ses réponses.

Un système documentaire produit une valeur diffuse : du temps non perdu, des erreurs évitées, des questions non posées à un collègue.

Relever avant la mise en service le temps passé à chercher une information, et le comparer six mois plus tard, transforme un bénéfice invisible en résultat démontrable. Ce relevé prend une demi-journée et il ne peut pas être fait après coup, comme le rappelle où part réellement un budget d’IA.

Les erreurs qui faussent la mesure de l’adoption d’un outil d’IA tiennent presque toutes au choix du dénominateur, au moment de la mesure ou à la confusion entre activité et usage utile.

• Rapporter l’usage aux licences plutôt qu’à la population cible, ce qui transforme un déploiement large en réussite apparente.
• Mesurer pendant le lancement. Une formation produit un pic d’usage qui ne dit rien de la suite, comme le montrent les programmes de formation à grande échelle.
• Se fier à la moyenne. Quelques utilisateurs très actifs peuvent masquer l’abandon de tous les autres.
• Ne rien relever avant la mise en service, ce qui rend toute démonstration de valeur impossible ensuite.

Il suffit de décider de la mesure avant le lancement, comme on prévoit une formation à l’IA ou un audit IA.