Mardi matin, dans le compte rendu hebdomadaire qu’elle s’apprête à envoyer à sa direction, une cheffe de produit hésite devant une ligne : « Sur cette tâche, j’ai utilisé l’IA. » L’outil ne lui a rien apporté cette semaine-là. Mais son entreprise suit un indicateur d’adoption, et cette phrase sera comptée, qu’elle l’écrive ou non. Alors elle l’écrit.

Cette scène, des milliers d’équipes produit la rejouent chaque semaine. Une capture d’écran d’un assistant conversationnel glissée dans une documentation, un outil cité dans un compte rendu, non pas parce que le travail en a été meilleur, mais parce qu’il faut prouver qu’on suit le mouvement. Ce réflexe a un nom : l’usage performatif de l’intelligence artificielle. Il prospère parce que presque personne, dans l’entreprise, ne sait vraiment comment évaluer un outil IA sur un travail réel.

Mesurer l’adoption avant d’avoir mesuré la valeur

Ce diagnostic, c’est celui que pose Caleb Sponheim, chercheur au Nielsen Norman Group (NN/g), cabinet de référence en ergonomie numérique fondé par les pionniers de l’utilisabilité Jakob Nielsen et Don Norman. Dans un article publié le 7 août 2026, il décrit une dérive devenue banale : des équipes évaluées sur leur usage de l’IA, sans définition claire de ce à quoi ressemble un usage réussi. Le résultat, écrit-il, c’est qu’on « mesure l’adoption avant d’avoir mesuré la valeur ».

La formule résume le piège où beaucoup d’organisations sont tombées depuis deux ans. Sommées d’afficher un taux d’usage de l’IA générative (ces systèmes capables de produire du texte, du code ou des images à partir d’une instruction en langage courant, un prompt), des équipes essaient des outils sans grille pour juger s’ils apportent réellement quelque chose. Sponheim identifie deux échecs symétriques : tester un outil une fois, sur un cas flatteur choisi pour la démonstration, et le déclarer productif ; ou le tester sur la mauvaise tâche et l’abandonner en bloc. Ni l’une ni l’autre ne répond à la seule question qui compte : comparé au travail d’aujourd’hui, l’outil produit-il un résultat qui justifie qu’on l’adopte ?

Le phénomène a un second visage, plus discret. Selon une étude du cabinet UpGuard, relayée par NN/g, environ 80 % des salariés admettent utiliser des outils d’IA que leur employeur n’a pas validés. Cette IA de l’ombre, ou shadow IA (l’équivalent, pour l’intelligence artificielle, du shadow IT que les directions informatiques observent depuis vingt ans : des outils utilisés en dehors des circuits officiels), prospère parce que personne n’a fourni de méthode pour juger un outil avant de s’en servir.

Cinq critères pour évaluer un outil IA sur une seule tâche

Face à ce vide, Sponheim propose PROVE, l’acronyme anglais des cinq critères qu’il a formalisés (Problem, Risk, Output, Velocity, Experience). Le cadre ne prétend pas trancher, à l’échelle d’une organisation, quel outil généraliser : il vise une décision défendable sur un outil précis, appliqué à une tâche précise. Résumés en français, ses cinq critères se lisent ainsi :

  • Le problème : partir de la tâche récurrente qui coûte du temps, avant de choisir un outil. L’IA ne s’évalue pas dans l’absolu ; elle est en concurrence avec le processus actuel, sa qualité, sa vitesse, la friction qu’on tolère déjà.
  • Le risque : vérifier, avant tout test, que l’usage est autorisé et que les données transmises ne posent pas de problème de confidentialité. Que 80 % des collègues utilisent un outil ne dit rien de sa sécurité.
  • Le résultat : comparer la production de l’outil à son propre travail réel, pas à un exemple idéalisé. La barre de qualité varie selon l’enjeu de la tâche.
  • La vitesse réelle : chronométrer le temps total, du lancement à la publication, corrections comprises. Une génération de trois secondes peut ouvrir une demi-heure de retouches.
  • L’expérience : distinguer la friction ponctuelle de l’apprentissage de celle qui revient à chaque usage. Un bon outil s’intègre au travail assez naturellement pour qu’on continue à s’en servir une fois la nouveauté passée.

Le cas d’une synthèse hebdomadaire, mesurée poste par poste

Sponheim illustre sa méthode par un cas concret : la rédaction d’une synthèse de veille publiée chaque semaine sur Slack, qui lui prenait jusque-là vingt-cinq minutes. Sur le problème et le risque, l’outil testé, Gemini Notebooks, obtient un score plein : tâche répétitive, exigences modestes, sources publiques sans donnée confidentielle, outil déjà accessible dans son environnement de travail. Sur le résultat, en revanche, la note plafonne à quatre sur cinq : le texte produit est exact, ses sources bien citées, mais il « sonne comme un rapport » plutôt que comme une voix personnelle, et réclame une réécriture avant publication. Le temps total tombe de vingt-cinq à environ dix minutes, un gain net comparable à ceux que nous décrivions à propos des leviers réels de l’IA pour les chefs de produit, mais le flux de travail passe de trois étapes à six : lire, importer, formuler l’instruction, copier, remettre en forme, publier. Deux allers-retours de plus à chaque exécution.

La décision finale n’est ni un rejet ni une adoption définitive : un essai d’un mois, avec une réserve notée noir sur blanc. Le cadre PROVE ne produit pas un verdict binaire mais une note de synthèse en quatre temps, que Sponheim recommande de conserver comme trace : ce qui a été évalué, ce qui a été observé, ce qu’on décide de faire, et la principale réserve qui subsiste.

Ce que ce cadre déplace, au-delà de l’outil

L’intérêt de PROVE ne tient pas à son acronyme, ni à sa nouveauté : publié depuis quelques jours seulement, il n’a pas encore été éprouvé à grande échelle. Ce qu’il déplace, c’est la question que se posent les organisations sur l’IA. Depuis deux ans, la plupart mesurent des taux d’adoption, des licences activées, des mentions dans les comptes rendus : des indicateurs de conformité, pas de valeur. Quand un indicateur de conformité devient un critère d’évaluation individuelle, les équipes apprennent vite à le satisfaire sans changer leur travail. C’est l’usage performatif décrit plus haut, une illustration de la loi de Goodhart, bien connue des économistes : un indicateur cesse d’être fiable dès qu’il devient, en soi, un objectif à atteindre.

C’est donc la charge de la preuve qui se déplace. Il ne s’agit plus de justifier, après coup, un usage déjà décidé par la direction, mais de documenter, avant de généraliser un outil, ce qu’il change réellement à une tâche réelle. C’est aussi ce que défendait dans nos colonnes le consultant John Cutler à propos de la confiance dans les projets d’IA : sans contrat social clair entre direction et équipes, l’adoption échoue quel que soit le raffinement de l’outil. PROVE fournit une brique à ce contrat : un langage commun pour dire, preuves à l’appui, pourquoi on garde un outil, pourquoi on l’essaie encore un mois, ou pourquoi on y renonce.

Les limites d’un cadre tout juste né

Sponheim balise lui-même les limites de sa méthode. PROVE n’est pas conçu pour arbitrer une décision à l’échelle d’une organisation entière, ni pour chiffrer le coût d’un abonnement dans la durée : il compare un outil à une tâche, rien de plus. Les scores qu’il produit, insiste-t-il, « révèlent une tendance, ils ne remplacent pas le jugement ». Un seul passage sur un seul jeu de données reste « un filtre, pas un verdict ».

On peut ajouter une réserve que l’article n’énonce pas frontalement : un cadre construit pour résister à la pression d’adopter peut, par effet de balancier, nourrir une méfiance réflexe, celle d’équipes qui multiplient les critères pour ne jamais rien changer. Sponheim l’anticipe en rappelant que la méthode doit être révisée dès qu’une tâche évolue, mais la discipline ne suffit pas toujours à contenir une culture déjà arc-boutée contre le changement. Et parce qu’elle a moins d’une semaine d’existence publique, aucun retour de terrain à grande échelle ne permet encore de vérifier si elle tient ses promesses au-delà du cas que son auteur a choisi de documenter.

Ce qui reste à faire, dès lundi

Rien n’empêche, en attendant, de s’en emparer à l’échelle d’une équipe. La prochaine fois qu’un outil d’IA générative s’invite dans un flux de travail, la question n’est pas « faut-il l’adopter ? » mais « sur quelle tâche précise, comparé à quoi, avec quel temps total et quelle friction ? ». Écrire la réponse en quatre lignes suffit déjà à transformer une pression d’adoption en décision qu’on peut défendre devant son équipe, et se relire dans six mois.

La cheffe de produit du mardi matin n’a peut-être pas besoin d’effacer sa ligne. Il lui faut une autre phrase derrière : non pas « j’ai utilisé l’IA », mais ce qu’elle a réellement mesuré en le faisant.

Sources

ARTICLES CONNEXESPLUS DE L'AUTEUR