Comment calcule-t-on le taux d'adoption d'une fonctionnalité ?

On divise le nombre d'utilisateurs actifs de la fonction par le nombre d'utilisateurs qui pouvaient s'en servir, sur une période donnée (par exemple 30 jours). Il faut fixer à l'avance ce qu'est un utilisateur actif et un utilisateur éligible.

Quel est un bon taux d'adoption ?

Il n'existe pas de seuil valable pour tous : cela dépend de la fonction et du public. Comparez-vous d'abord à vous-même, d'un mois sur l'autre et d'un segment de clients à l'autre, plutôt qu'à un chiffre trouvé ailleurs.

La mesure d'usage d'une fonction demande-t-elle le consentement des utilisateurs ?

La CNIL exempte de consentement la mesure d'audience qui respecte des conditions strictes (finalité limitée à la mesure, durée de conservation limitée, information des personnes). Mesurer l'usage d'une fonction avec des données personnelles peut sortir de ce cadre : faites le point avec la personne qui s'occupe de la protection des données chez vous.

Taux d'adoption d'une fonctionnalité : le mesurer

Le taux d'adoption d'une fonctionnalité est la part des utilisateurs qui pouvaient s'en servir et qui s'en sont servis, sur une période donnée. Pour un assistant IA intégré à votre logiciel, la formule est simple. La difficulté est de bien choisir ce qu'on compte au numérateur et au dénominateur, et de ne pas confondre curiosité et usage utile.

La définition

Taux d'adoption = utilisateurs actifs de la fonction ÷ utilisateurs éligibles, sur une période donnée.

Trois choix à écrire avant de mesurer :

Utilisateur éligible. Qui voit la fonction ? Si l'assistant n'est activé que dans l'édition « Pro » ou chez les clients volontaires, les autres ne comptent pas. Sinon vous obtenez un taux faible qui ne dit rien.
Utilisateur actif de la fonction. Une seule question posée suffit-elle, ou faut-il au moins deux utilisations dans la période ? Une définition courante est « au moins une question posée avec réponse affichée », mais c'est vous qui décidez, et vous gardez la même.
Période. 7 jours pour suivre un lancement, 30 jours pour le suivi courant. Ne comparez que des périodes de même durée.

Exemple d'hypothèse : 1 200 utilisateurs éligibles, 180 ont posé au moins une question dans les 30 derniers jours : le taux d'adoption à 30 jours est 180 ÷ 1 200, soit 15 %. Ces chiffres sont posés pour le calcul, ils ne décrivent aucun logiciel réel.

On distingue souvent l'adoption (premier usage), la rétention (retour après le premier usage) et l'usage récurrent. Un bon lancement donne d'abord de l'adoption ; une fonction utile se voit à la rétention.

Les autres indicateurs à suivre

Le taux d'adoption seul ne dit pas si la fonction rend service. Complétez avec :

Indicateur	Ce qu'il dit	Comment le calculer
Rétention	Les utilisateurs reviennent-ils ?	Part des utilisateurs du mois précédent qui l'ont réutilisée ce mois-ci
Questions sans réponse	La documentation couvre-t-elle les besoins ?	Nombre (ou part) de questions où l'assistant dit ne pas trouver
Renvois au support	L'assistant passe-t-il la main ?	Part des conversations transférées ou suivies d'un ticket
Satisfaction	La réponse a-t-elle aidé ?	Bouton « Cette réponse m'a aidé » : part de oui parmi ceux qui répondent
Profondeur d'usage	Une question ou une vraie conversation ?	Nombre de messages par session

La part des utilisateurs qui répondent au bouton de satisfaction est souvent faible : indiquez toujours le nombre de réponses à côté du pourcentage, sinon un « 90 % de satisfaits » peut cacher dix réponses.

Pour relier l'usage à l'effet sur votre équipe, voir la réduction des tickets du support. Certaines plateformes d'assistants fournissent déjà des métriques de base : la page des fonctionnalités d'ALMA mentionne par exemple, relevée le 15/11/2026, un tableau de bord avec messages, sessions, satisfaction, coûts et jetons consommés, ainsi qu'une gestion des questions sans réponse (fonctionnalités d'ALMA). Quel que soit l'outil, vérifiez que vous pouvez extraire les chiffres pour les rapprocher des vôtres.

Un tableau de bord minimal

Six lignes suffisent pour un premier lancement, avec la période affichée :

utilisateurs éligibles ;
utilisateurs actifs de la fonction et taux d'adoption ;
nombre de questions et questions par utilisateur actif ;
part des questions sans réponse ;
part des conversations renvoyées au support ;
satisfaction, avec le nombre de réponses.

Ajoutez une vue par segment : taille du client, édition du logiciel, ancienneté. L'adoption diffère beaucoup d'un segment à l'autre, et c'est dans ces écarts que se trouvent les décisions : où mieux annoncer la fonction (annoncer la fonction), où la documentation manque.

Le coût suit le même rythme : rapprochez l'usage du coût de revient pour vérifier vos hypothèses de tarification.

Les pièges

Compter les clics. Ouvrir la fenêtre de l'assistant n'est pas l'utiliser. Comptez une question envoyée et une réponse affichée.
Compter l'usage sans l'utilité. Un utilisateur qui pose trois fois la même question parce que la réponse est mauvaise n'est pas un utilisateur conquis. Regardez les reformulations rapprochées.
Confondre éligible et inscrit. Un dénominateur trop large dilue le taux ; trop étroit, il le gonfle.
Un taux de lancement qui retombe. La curiosité des premiers jours gonfle l'adoption ; regardez la rétention à quatre semaines.
Les moyennes. Un client qui pose beaucoup de questions peut masquer que la plupart n'y touchent pas. Regardez la médiane et le nombre de comptes qui s'en servent, pas seulement le total.
Comparer à un chiffre trouvé ailleurs. Sans savoir comment l'autre l'a défini, la comparaison ne vaut rien. Comparez-vous à vos propres périodes.
Oublier l'effet de la documentation. Si l'adoption est bonne et la satisfaction mauvaise, le problème est souvent dans les pages que l'assistant trouve : voir la documentation pour l'IA.

Mesurer sans enfreindre le RGPD

Mesurer l'usage d'une fonction revient à collecter des données sur des personnes. Quelques repères, à faire valider par la personne qui s'occupe de la protection des données chez vous.

La CNIL indique, sur sa page consacrée à la mesure de la fréquentation, que des traceurs de mesure d'audience peuvent être exemptés de consentement à certaines conditions, relevées le 15/11/2026 : finalité strictement limitée à la mesure d'audience, pour le compte exclusif de l'éditeur ; durée de vie du traceur limitée (la CNIL cite treize mois comme exemple) et non prolongée automatiquement ; informations conservées vingt-cinq mois au plus ; information des personnes, par exemple dans la politique de confidentialité. La page précise que l'exemption ne joue pas si le fournisseur réutilise les données pour son propre compte.

Ce cadre vise la mesure d'audience. Un suivi qui relie l'usage de la fonction à une personne identifiée, ou qui sert à autre chose qu'à des statistiques, n'y entre peut-être pas : renseignez-vous avant de le mettre en place.

Des habitudes qui limitent les risques :

Compter plutôt que lire. Pour le taux d'adoption, un identifiant d'utilisateur et un horodatage suffisent ; il n'est pas nécessaire de lire le contenu des questions.
Séparer l'analyse du contenu. Relire des questions pour améliorer la documentation est un autre usage : dites-le dans l'information donnée aux utilisateurs et limitez l'accès à quelques personnes.
Limiter la durée de conservation des journaux et des conversations, et l'écrire.
Informer : une phrase dans l'aide de l'assistant, un lien vers la politique de confidentialité.
Prévoir la suppression d'une conversation à la demande d'un utilisateur.