Comment mesurer l'adoption d'un outil : pourquoi le nombre d'utilisateurs actifs ment
Un rapport de déploiement commence presque toujours par le nombre d'utilisateurs actifs. Il progresse agréablement le premier mois, se stabilise le second et devient le principal argument pour affirmer que le projet a réussi. Or il ne répond jamais à la question que le déploiement était censé trancher.
Se connecter n'est pas travailler dans le système. Une personne peut ouvrir l'interface chaque jour, regarder la liste des tâches et continuer à faire le travail réel par e-mail. Dans le rapport, elle est un utilisateur actif ; dans le processus, elle est absente.
L'adoption se mesure à la part des scénarios qui vont jusqu'au bout dans l'outil, pas au nombre de personnes qui s'y connectent. La différence est fondamentale : la première métrique baisse en cas de contournement et ne progresse qu'avec un transfert réel, la seconde grossit par curiosité et ne baisse presque jamais. L'usage déclaré par les utilisateurs mesure une autre grandeur et ne corrèle que faiblement avec l'usage réel.
Pourquoi les métriques habituelles gonflent l'adoption
Chaque métrique d'adoption populaire possède son propre mécanisme de gonflement, et tous jouent dans le même sens.
Nombre d'utilisateurs actifs. Il progresse par curiosité et par obligation administrative. Il ne distingue pas la personne qui a passé une journée de travail entière dans le système de celle qui s'est simplement connectée pour vérifier si quelque chose de nouveau était apparu.
Nombre d'enregistrements créés. Il progresse par duplication : un collaborateur crée un enregistrement pour le reporting et continue de travailler à l'ancienne. Cet enregistrement existe, mais ne reflète aucune décision.
Enquête de satisfaction. Elle mesure une attitude, pas un comportement. Les gens répondent poliment, surtout quand l'enquête n'est pas anonyme, et ils parlent d'intention plutôt que de fait.
Volume de tickets de support. Il baisse aussi bien en cas de déploiement réussi qu'en cas d'abandon de l'outil. Sans une seconde métrique, impossible de distinguer l'un de l'autre.
| Métrique | Comment elle gonfle | Par quoi la remplacer |
|---|---|---|
| Utilisateurs actifs | Compte la connexion comme du travail | Taux de scénarios aboutis |
| Enregistrements créés | Compte la duplication comme de l'usage | Part des enregistrements avec les champs obligatoires remplis |
| Satisfaction | Mesure une attitude plutôt qu'un comportement | Taux de contournement |
| Tickets de support | Baisse en cas de succès comme en cas d'abandon | Le même taux de contournement |
La troisième colonne constitue à elle seule l'ensemble dont vous avez besoin. Trois métriques au lieu de quatre, et toutes trois baissent en cas de contournement — ce qu'aucune des métriques habituelles ne fait.
Pourquoi on ne peut pas simplement demander aux gens s'ils utilisent le système
La tentation de remplacer la mesure par une enquête est forte : une enquête coûte moins cher que des journaux système et ne nécessite aucune intégration. Sur le plan méthodologique, la question est réglée depuis longtemps.
L'usage déclaré d'un système et l'usage objectivement enregistré dans les journaux système sont deux construits distincts, faiblement corrélés entre eux. S'appuyer sur des déclarations subjectives pour évaluer l'adoption d'un système est méthodologiquement peu fiable.
Un mot d'honnêteté s'impose ici : le texte intégral de l'article est verrouillé par un abonnement payant, et j'ai lu la page de métadonnées avec le résumé, pas l'article lui-même. Je ne cite donc pas de coefficients de corrélation précis. La conclusion que je retiens est qualitative et confirmée par la pratique : le chiffre qu'une personne donne dans une enquête et le chiffre que montre le système sont deux grandeurs différentes, et il ne faut pas les confondre.
Ce qui constitue un scénario abouti
La notion de scénario abouti est empruntée à la pratique des tests d'utilisabilité, où elle est formalisée comme métrique centrale.
Le taux de réussite — la part des tâches cibles menées à bien — est posé comme la métrique clé et synthétique de l'interaction avec le produit : si un utilisateur n'a pas pu mener une tâche à son terme, tous les autres indicateurs deviennent secondaires.
Il s'agit d'un guide méthodologique pour des tests en laboratoire sur des échantillons de quatre à cinq personnes, pas d'une mesure d'adoption à grande échelle en exploitation industrielle ; je transpose cette notion aux données de production par analogie, et je le précise explicitement. La valeur réside dans la définition : un scénario est soit abouti, soit non abouti, sans état intermédiaire. C'est précisément ce caractère binaire qui rend la métrique résistante aux interprétations.
Combien coûte ce qui n'est pas utilisé
Le volet économique de la question se mesure séparément, et les chiffres progressent.
La part des dépenses improductives sur les abonnements cloud a augmenté de 10 points de pourcentage d'une année sur l'autre, et 59 % des spécialistes interrogés ont constaté une hausse de ces dépenses précisément sur les outils d'IA.
Le rapport est financé par un éditeur d'outils de gestion des actifs informatiques — un intérêt commercial à présenter le problème comme aigu existe donc —, et la méthode de calcul complète est verrouillée derrière un formulaire ; la part exacte des licences inutilisées n'est pas dévoilée sur les pages ouvertes, seule l'évolution des dépenses l'est. Je l'utilise comme indicateur de tendance : la couverture formelle en licences progresse plus vite que l'usage réel, et l'écart se creuse. Pour une décision budgétaire, cela suffit : un écart qui se creuse est un signal d'alerte suffisant pour renégocier un contrat, même sans le chiffre exact du gaspillage.
Comment construire la mesure de l'adoption
Avant d'aborder la troisième métrique, il vaut la peine de revenir sur la première : sa définition relève d'une décision de gestion, pas d'un paramétrage technique. Le scénario « traiter la demande » peut être considéré comme abouti au moment où la demande est clôturée dans le système, ou seulement lorsque le client a reçu une réponse et que cela a été consigné. La première définition donne une belle image, la seconde une image utile. Ce choix se fait une seule fois, et il détermine ce dont vous discuterez à chaque réunion de pilotage l'année suivante.
La deuxième métrique — la part des enregistrements avec les champs obligatoires remplis — sert de garde-fou contre la substitution. Sans elle, il est facile d'obtenir un taux élevé de scénarios aboutis simplement parce que les enregistrements sont créés pour la forme : le statut change, mais le contenu reste vide. Ensemble, les deux métriques résistent à ce type de substitution, car clôturer un scénario pour la forme est facile, alors que remplir les champs obligatoires avec des valeurs pertinentes est nettement plus difficile.
La troisième métrique est la plus incommode et la plus précieuse des trois. Elle ne se calcule pas dans l'outil lui-même, mais à partir des traces du contournement : combien de documents ont été créés hors du système, combien de décisions ont été prises par e-mail, combien de tâches sont apparues ailleurs. Obtenir une valeur exacte est difficile, mais la tendance est accessible, et elle suffit.
La première métrique doit être définie avant le lancement, en même temps que la définition de ce qui constitue un scénario abouti. Après coup, cette définition s'ajuste toujours aux données obtenues — j'ai écrit séparément sur l'observabilité du processus et la mesure de l'état initial.
Quatre étapes vers un rapport de déploiement honnête
Définissez le scénario abouti avant le lancement
Une phrase, un critère binaire. Après le lancement, la définition s'ajustera aux données.
Retirez les utilisateurs actifs du rapport
Ne complétez pas, remplacez. Tant que la métrique figure dans le rapport, c'est elle qu'on discutera.
Recherchez les traces du contournement
Documents, e-mails, tâches hors du système. La tendance suffit, la valeur exacte n'est pas nécessaire.
Ne demandez pas aux gens à quelle fréquence ils l'utilisent
L'usage déclaré et les journaux système mesurent des choses différentes. Demandez plutôt ce qui freine l'usage — c'est une question à laquelle une enquête répond honnêtement.
Une métrique d'adoption qui ne peut jamais baisser ne mesure rien. Vérifiez la vôtre : quel comportement des collaborateurs la ferait chuter ?
Questions fréquentes sur la mesure de l'adoption
Comment mesurer l'adoption d'un système d'entreprise ?
Par la part des scénarios qui vont jusqu'au bout dans le système, pas par le nombre d'utilisateurs actifs. Un scénario est considéré comme abouti lorsque chacune de ses étapes a laissé une trace dans le système : création, changement de statut, décision, résultat. Deux autres métriques complètent le tableau — la part des enregistrements avec les champs obligatoires remplis, et le taux de contournement, la part du travail qui passe à côté de l'outil.
Pourquoi le nombre d'utilisateurs actifs est-il une mauvaise métrique ?
Parce qu'il ne distingue pas la connexion au système du travail effectif dans celui-ci, et qu'il ne baisse presque jamais : il progresse par curiosité, par obligation administrative, et simplement parce que l'interface reste ouverte dans un onglet en arrière-plan. Une métrique qui ne peut pas diminuer quand les collaborateurs cessent d'utiliser un outil ne mesure pas l'adoption — elle mesure l'accès disponible.
Peut-on évaluer l'adoption par une enquête ?
Pas la fréquence d'usage — il est établi de longue date que l'usage déclaré et les journaux système objectifs mesurent des grandeurs différentes et ne corrèlent que faiblement. Une enquête fonctionne bien pour une autre question : ce qui freine l'usage. Là, les réponses sont concrètes et vérifiables, et le résultat se transforme directement en liste de correctifs, alors que l'auto-évaluation de la fréquence ne donne ni l'un ni l'autre.
Comment calculer le taux de contournement ?
À partir des traces laissées dans d'autres canaux : documents créés hors du système, décisions prises par e-mail, tâches ouvertes ailleurs. Obtenir une valeur exacte est difficile, et ce n'est pas nécessaire — la tendance sur quelques mois suffit. Si ce taux progresse alors que les indicateurs d'usage paraissent formellement élevés, cela signifie que l'outil a été adopté comme un exercice de reporting, pas comme un outil de travail.
L'ensemble des trois métriques d'adoption et la méthode de recherche des traces de contournement sont une généralisation personnelle tirée de déploiements de CRM dans trois entreprises (une agence digitale, un fabricant saisonnier de cadeaux d'entreprise, une plateforme de prise de rendez-vous en ligne) et de la pratique de collecte de statistiques d'usage par gestionnaire dans les propres produits d'Alego.Digital. Aucune mesure quantitative de la part de contournement n'a été effectuée au moment de ces déploiements ; c'est pourquoi cet article ne présente aucune métrique chiffrée interne. Tous les chiffres proviennent de sources externes dont la méthode est indiquée.
- Straub D., Limayem M., Karahanna-Evaristo E. Measuring System Usage: Implications for IS Theory Testing. Management Science, 41(8), 1995. ideas.repec.org
- Nielsen J., Budiu R. Success Rate: The Simplest Usability Metric. Nielsen Norman Group, 2001, rév. 2021. nngroup.com
- Flexera. 2026 State of ITAM Report, juin 2026 (enquête auprès de 512 spécialistes). flexera.com