Décider ce que doit faire un produit qui se trompe
La gestion d’un produit d’intelligence artificielle ressemble à la gestion de produit ordinaire jusqu’à la première fois où le système se trompe avec assurance. À cet instant, une différence de nature apparaît : le produit ne comporte pas un défaut à corriger, il possède un taux d’erreur qui fait partie de ce qu’il est. La question n’est donc pas de l’éliminer mais de décider quelles erreurs sont acceptables, lesquelles ne le sont pas, et ce que le produit fait quand il ne sait pas. Ces trois décisions n’ont pas d’équivalent dans la gestion de produit classique, elles appartiennent au responsable produit et non à l’équipe technique, et elles ne figurent presque jamais dans une feuille de route. Un produit conduit sans elles fonctionne correctement pendant des mois, puis rencontre la situation que personne n’avait tranchée, et l’organisation découvre qu’aucune position n’avait été prise au moment où elle était facile à prendre.
Responsable produit IA, en bref
Métier émergent| En une phrase | Décide de ce que doit faire un produit d’IA, avec la complication inhabituelle que son comportement est probabiliste. |
|---|---|
| Jugé sur | Le fait que le produit soit utilisé, et que ses défaillances soient celles que l’équipe a choisi d’accepter. |
| Échoue quand | Il est mené comme une gestion de produit ordinaire, avec une feuille de route de fonctionnalités et aucune position sur l’erreur acceptable. |
| Confondu avec | La gestion de produit ordinaire, à laquelle il ressemble jusqu’à la première fois où le système se trompe avec assurance. |
Un travail réel, dont le périmètre varie assez d’un employeur à l’autre pour que l’intitulé seul n’apprenne pas grand-chose. Aucun chiffre de rémunération : voir notre méthode.
Les trois décisions qui appartiennent au produit
Quelles erreurs sont acceptables. Un système qui se trompe sur la mise en forme d’une réponse et un système qui se trompe sur un montant ne posent pas le même problème. Classer les erreurs par conséquence, et écrire ce classement, est un travail de produit qu’aucune équipe technique ne fera à sa place.
Ce que le produit fait quand il ne sait pas. Répondre quand même, signaler son incertitude, ou remonter vers une personne. Ces trois comportements produisent trois produits différents, et le premier est celui qui détruit le plus vite la confiance des utilisateurs.
Ce que l’utilisateur sait du fonctionnement. Ce qui lui est dit sur ce que le système fait, ce sur quoi il s’appuie et ce qu’il ne garantit pas. Cette décision est à la fois produit et, dans certains contextes, réglementaire.
Prioriser par catégorie plutôt que par fonctionnalité
Une feuille de route de fonctionnalités convient mal à ces produits, parce que ce qui limite leur valeur n’est presque jamais une fonction manquante. C’est une classe de cas sur laquelle le système échoue.
La lecture utile vient donc du jeu d’évaluation, à condition qu’il soit découpé par catégorie. Elle dit sur quelles demandes le produit se tient et sur lesquelles il cède, et elle transforme une discussion d’opinions en discussion de faits.
Cela fait du jeu d’évaluation un instrument de décision autant que de mesure, et c’est une raison pour le responsable produit de participer à sa construction plutôt que de la déléguer entièrement. Les catégories qu’il contient déterminent ce que l’équipe pourra voir.
Ce qu’il faut mesurer, et ce qui trompe
Une justesse moyenne est utile pour communiquer et dangereuse pour décider. Elle peut rester stable pendant qu’une catégorie précise s’effondre, et les catégories n’ont pas le même poids : celle qui concerne le client le plus important compte davantage que le reste.
Deux mesures complètent utilement la justesse. Le taux de remontée vers une personne, qui doit exister : un produit qui ne remonte jamais rien traite avec assurance des cas qu’il ne maîtrise pas. Et le taux de reprise, c’est-à-dire la proportion de sorties que l’utilisateur corrige, qui est le meilleur signal de confiance réelle.
Cette dernière mesure a un avantage sur les enquêtes de satisfaction : elle ne se déclare pas, elle s’observe. Un utilisateur qui dit être satisfait et qui reprend systématiquement les sorties donne deux informations, et c’est la seconde qui compte.
L’erreur de conduite la plus fréquente
Le produit est mené comme un produit ordinaire pendant six mois, avec des fonctionnalités et des jalons, et personne n’écrit de position sur l’erreur acceptable parce que la question ne se pose pas tant que rien n’a mal tourné.
Puis un utilisateur important reçoit une réponse fausse énoncée avec assurance. La réaction est immédiate et mal calibrée : on ajoute une validation humaine partout, ce qui rend le produit plus lent que le travail manuel, et il est abandonné trois semaines plus tard.
La décision qui manquait n’était pas technique. Elle consistait à dire, avant la mise en service, quelles erreurs l’organisation acceptait et ce qui se passait pour les autres. Prise à froid, elle prend une heure ; prise après un incident, elle est prise par quelqu’un d’autre et dans la précipitation.
