Un matin de drop de sneakers, devant un magasin d'une marque mondiale de sport, la file commence sur le trottoir avant l'ouverture et déborde dans le magasin dès que les portes s'ouvrent. Entre 2021 et 2023, nous avions devant cette file un outil SMS monté à la hâte pendant le COVID pour capter les visites, et une liste de fonctionnalités IA à prioriser, dont un chatbot qui réserverait la paire avant la venue en magasin. La question qui décidait de tout tenait en une ligne : mettons-nous un chatbot devant cette file, et quel chiffre nous dira qu'il marche ?
Prioriser une fonctionnalité IA, c'est choisir laquelle construire en premier en répondant à cinq questions, la valeur, la disponibilité des données, le coût de l'échec, le coût d'évaluation et la réversibilité, puis en refusant tout score final avant une évaluation sur des données réelles.
Mesurer une fonctionnalité IA, c'est lire quatre chiffres après le lancement, l'adoption, le taux de succès de la tâche, le taux de correction et le coût par tâche, contre une baseline écrite avant la première ligne de code, avec une règle d'arrêt dans le ticket.
Vous avez sans doute votre propre liste. Cinq idées IA remontées par la direction, un backlog qui n'a pas de colonne pour l'incertitude, et personne pour trancher autrement qu'à la voix.
Les cinq questions qui décident
Une grille de priorisation produit classique demande l'effet attendu et l'effort. Pour une fonctionnalité IA nous posons cinq questions, et les deux dernières sont celles qui manquent presque partout.
La valeur, d'abord, et pour qui. La personne qui s'en sert gagne-t-elle quelque chose qu'elle remarque, du temps, ou une paire mise de côté ? Sur le drop, le client gagnait de savoir avant de venir, et le magasin gagnait une file qui rentre.
La disponibilité des données ensuite. Un chatbot qui promet une paire doit savoir ce qu'il reste en réserve, et si cette donnée n'existe pas proprement, la fonctionnalité n'existe pas non plus, quel que soit le modèle. Cette question se vérifie en deux jours, et c'est souvent elle qui vide la liste.
Le coût de l'échec. Quand la réponse est fausse, qui paie, et combien ? Une paire promise qui n'est pas là, c'est un client qui a fait la queue pour rien et qui le dira dehors. Une description produit résumée un peu à côté ne coûte presque rien. Les deux fonctionnalités méritent des seuils très différents.
Le coût d'évaluation. Savoir si la chose marche, avant de la construire, a un prix en jours. Certaines fonctionnalités s'évaluent sur cent conversations passées, d'autres demandent un jeu d'évaluation qu'il faut d'abord fabriquer à la main, et ce coût-là entre dans le score.
La réversibilité, enfin. Si on l'éteint un mardi, que se passe-t-il ? Un chatbot devant une file se retire en une heure. Et la file reprend sa forme d'avant. Un modèle qui a réécrit vos règles de remise pendant six mois ne se retire pas, ses effets restent dans les paniers.
La grille de score, avec « inconnu » là où c'est inconnu
Chaque question reçoit une note de 0 à 3. La colonne d'avant évaluation accepte la mention « inconnu ». La colonne d'après ne l'accepte plus. Une ligne qui porte encore un inconnu ne passe pas, et la somme ne se calcule pas tant qu'une ligne ne passe pas, ce qui oblige à faire l'évaluation au lieu de la remplacer par une opinion bien présentée.
| Question | Ce qu'on note de 0 à 3 | Avant l'évaluation | Après l'évaluation |
|---|---|---|---|
| Valeur pour le client | Ce que la personne gagne, en temps ou en résultat, et si elle le remarque | Une estimation, souvent bonne | Mesurée sur le jeu de test |
| Disponibilité des données | La donnée existe, elle est propre, on a le droit de s'en servir | Vérifiable en deux jours | Confirmée, ou la ligne tombe |
| Coût de l'échec | Ce qu'une mauvaise réponse coûte au client et au magasin | Estimable | Lu sur les erreurs réelles du jeu d'évaluation |
| Coût d'évaluation | Ce qu'il en coûte de savoir avant de construire | Connu tout de suite | Dépensé |
| Réversibilité | Ce qui se passe le jour où on l'éteint | Connu tout de suite | Inchangé |
| Score de confiance | La probabilité que la fonctionnalité fasse ce qu'elle promet | Inconnu, toujours | Le taux de réussite du jeu d'évaluation contre le seuil écrit |
La dernière ligne est celle qui fâche, parce que tout le monde a envie de la remplir. Un « inconnu » écrit noir sur blanc vaut mieux qu'un chiffre rond (le comité aime les chiffres ronds, même faux).
Ce que RICE a apporté, et les deux colonnes que nous ajoutons
RICE vient d'Intercom, qui l'a écrite pour ses propres équipes produit : R pour la portée, I pour l'effet attendu, C pour la confiance, E pour l'effort, une multiplication, une division, et le backlog se range. ICE, sa cousine plus ancienne, fait le même travail avec trois colonnes, et la matrice impact et faisabilité que les écoles enseignent en est la version dessinée. Ces grilles ont donné aux équipes produit françaises une arithmétique commune, et elles ont tué la priorité de la voix la plus forte en réunion.
Nous les gardons.
Le point où nous nous séparons de la grille est la colonne confiance. Pour une fonctionnalité déterministe, un product manager qui a vu le problème trois fois la remplit en conscience. Pour une fonctionnalité probabiliste, cette colonne est vide par nature avant l'évaluation, puisque personne ne sait ce qu'un modèle fera sur vos données avant de l'avoir fait tourner dessus.
Un score qui cache ce vide fait passer en tête la fonctionnalité la plus séduisante, celle qui se présente bien en comité, à la place de la plus réversible. Puis on la tue trop tard, parce qu'elle a un chiffre. D'où les deux colonnes ajoutées, le coût d'évaluation et la réversibilité, et la règle qu'aucun score n'est final avant une évaluation sur des données réelles. Décider avec ce vide sous les yeux, c'est le métier du product manager à l'ère des agents.
Évaluer avant de construire, deux semaines au plus
Une évaluation avant construction tient en deux semaines et quatre pièces : un jeu d'évaluation tiré de données réelles, un seuil de réussite écrit avant le premier essai, une baseline (ce que la règle ou l'humain en place obtient déjà, chronomètre en main) et une limite de latence, puisqu'une réponse juste qui arrive trop tard devant une file ne sert à rien. Le seuil s'écrit avant, jamais après, sinon il descend jusqu'au résultat obtenu.
| Jours | Ce qu'on fait | Ce qu'on tient à la fin |
|---|---|---|
| 1 et 2 | Sortir entre cent et trois cents cas réels des logs, des SMS ou des tickets, et les annoter à la main avec la bonne réponse, écrite par quelqu'un qui connaît le rayon | Un jeu d'évaluation et un jeu de test, séparés dès le premier jour |
| 3 | Écrire le seuil de réussite (la part de tâches réussies au-dessous de laquelle on ne construit pas) et la baseline, ce que la règle en place obtient déjà | Le seuil, signé avant le premier essai |
| 4 à 8 | Faire tourner le modèle sur le jeu d'évaluation, lire le taux de succès de la tâche, le taux d'hallucination, la latence et le coût par tâche, régler, recommencer | Des chiffres, et les erreurs classées par type |
| 9 et 10 | Comparer au seuil sur le jeu de test, celui qui n'a servi à aucun réglage | Passe ou ne passe pas, et la grille se remplit |
Le jeu de test reste sous clé pendant les réglages. Un modèle ajusté sur les cas qui servent ensuite à le juger obtient un beau chiffre et un lancement raté, et c'est l'erreur que nous voyons le plus chez les équipes qui font l'évaluation pour la première fois. Deux semaines est un maximum : au-delà, l'évaluation devient le projet, et le projet ne sort jamais du laboratoire, ce que nous décrivons sur l'IA en production.
Les quatre chiffres après le lancement
Un KPI est un chiffre relié à une décision. Chacun des quatre ci-dessous a une décision au bout, garder ou éteindre, et une chose contre laquelle il se lit.
| Métrique | Ce qu'elle mesure | Lue contre quoi |
|---|---|---|
| Adoption | La part des clients ou des vendeurs qui se servent de la fonctionnalité quand elle leur est proposée, semaine après semaine | Le chemin d'avant (l'appel, le SMS, la file) et la courbe à 4, 8 et 12 semaines |
| Taux de succès de la tâche | La part des demandes qui aboutissent à ce que la personne voulait, une paire réservée, une réponse juste, sans passer par un humain | Le seuil de l'évaluation, puis la baseline humaine |
| Taux de correction (override rate) | La part des réponses ou des actions du modèle qu'un humain a reprises, corrigées ou annulées | Le taux d'erreur du jeu de test ; s'il monte au-dessus, le modèle voit des données que le jeu ne contenait pas |
| Coût par tâche | Ce que coûte une tâche réussie, appels de modèle compris, divisé par les tâches réussies et jamais par les requêtes | Le coût de la même tâche faite à la main, et la ligne promise en comité |
La latence et le taux d'hallucination se lisent chaque jour comme des garde-fous : ils déclenchent une alerte, et la décision de garder ou d'éteindre revient aux quatre chiffres du tableau. C'est cette lecture hebdomadaire, tenue par l'équipe elle-même, que nous installons avec The Product Engine.
Quand tuer la fonctionnalité
La question de quand tuer une fonctionnalité se règle avant de la construire. La règle d'arrêt s'écrit dans le ticket, sous la description, avec la métrique, le seuil et la date, et le ticket ne passe pas en développement sans elle. Une règle qui tient ressemble à ceci : si à la semaine 8 le taux de succès de la tâche est sous le seuil de l'évaluation, ou si le taux de correction dépasse le double du taux d'erreur du jeu de test, la fonctionnalité s'éteint le lundi suivant et le chemin d'avant reprend.
Un test A/B, quand le trafic le permet, donne la même réponse plus vite et plus proprement. Devant une file de drop, couper la file en deux n'aurait rien mesuré, et c'est l'avant et l'après du même magasin, sur le même chiffre, qui a servi de comparaison. Éteindre à la date écrite une fonctionnalité qui est sous son seuil est une décision produit ordinaire, prise en dix minutes par l'équipe qui a écrit la règle, et c'est la règle écrite qui rend les dix minutes possibles.
Le chatbot devant la file, noté puis mesuré (2021 à 2023)
Retour au drop. L'outil SMS tenait la file pendant le COVID, il avait été construit pour ça et pour rien d'autre, et l'idée d'un chatbot IA relié à un moteur de réservation, puis à WhatsApp, est arrivée sur la liste avec les autres. Nous l'avons passée sur les cinq questions.
La valeur d'abord, haute des deux côtés du comptoir. Les données : l'outil SMS avait déjà produit des conversations réelles, de quoi bâtir un jeu d'évaluation sans rien inventer. Le coût de l'échec pesait lourd, une paire promise et absente coûtait un client furieux dans une file, ce qui a fixé le seuil de réussite haut. Pour le coût d'évaluation, quelques jours sur les conversations passées. La réversibilité, enfin : le chatbot se coupait en une heure et le SMS reprenait, et honnêtement c'est cette ligne qui a fait pencher la décision.
Le chiffre a été écrit avant la construction, l'encombrement du magasin aux drops, et lu après. Sur les magasins de la marque (2021 à 2023), la conversion de la réservation vers l'achat a atteint 80 %, l'encombrement en magasin aux drops de pointe a baissé de 50 %, les ventes de sneakers ont monté de 20 % et le coût opérationnel a baissé de 25 %. La baisse de moitié de l'encombrement est celle qui comptait, parce qu'elle voulait dire que des gens sont entrés dans le magasin au lieu de rester dehors. Le commerce conversationnel de la marque a commencé là, sur une file.
Juste avant, dans les années IKEA de notre équipe (2018 à 2021), une fonctionnalité de reconnaissance d'objets par la caméra du téléphone est sortie sur deux continents ; l'engagement y a monté de 30 % et, effet que le deck de lancement n'avait pas prévu, le travail du service des réclamations s'en est trouvé simplifié. C'est le genre de résultat qu'un tableau d'après-lancement attrape, à condition d'y laisser une colonne vide au départ, celle des effets qu'on n'attendait pas.
Ce que nous n'avons pas résolu
Le taux de correction est la métrique que les équipes rechignent à publier. Chaque correction est une réponse du modèle qu'un humain a dû reprendre, et vu de loin le chiffre ressemble à un aveu, alors il glisse hors du compte rendu, ou il arrive arrondi. Le montrer à côté du taux de succès aide un peu. Pas assez. Nous n'avons pas trouvé la façon indolore de le faire dire, et une équipe qui le cache se prive du seul signal qui annonce une dérive avant que les clients la voient.
Les questions qu'on nous pose
Quels KPI pour une fonctionnalité IA ?
The 34 Group en lit quatre, contre une baseline : l'adoption, le taux de succès de la tâche, le taux de correction et le coût par tâche. La latence et le taux d'hallucination servent de garde-fous quotidiens. Un KPI sans décision au bout est un chiffre de plus dans un tableau de bord, et les tableaux de bord des équipes IA en ont déjà trop.
Comment prioriser une fonctionnalité IA sans données ?
The 34 Group commence par la deuxième question, la disponibilité des données, et la traite en deux jours : où est la donnée, qui la possède, a-t-on le droit de s'en servir, depuis quand elle est propre. Si la réponse est vide, la fonctionnalité sort de la liste ou devient un projet de données, ce qui est une autre priorisation. Si la donnée existe mais qu'elle est sale, l'évaluation de deux semaines dit combien de nettoyage il faut avant de savoir quoi que ce soit, et ce nettoyage entre dans la colonne coût d'évaluation.
Quand arrêter une fonctionnalité IA ?
À la date écrite dans le ticket, répond The 34 Group, si la métrique est sous le seuil. La règle d'arrêt se rédige avant la première ligne de code, et le retour au chemin d'avant se prépare dès le lancement. Une fonctionnalité sans règle d'arrêt s'éteint quand même un jour, mais tard, après avoir consommé une équipe, alors que le chiffre qui l'aurait arrêtée existait depuis des mois.
Faut-il un test A/B pour une fonctionnalité IA ?
Quand le trafic le permet, oui, chez The 34 Group avec la même métrique que le ticket. Sur un magasin, une file ou une équipe de dix personnes, le trafic manque, et l'avant et l'après du même périmètre, sur le même chiffre, fait le travail à condition que le chiffre ait été écrit avant. Le test A/B mesure mieux, et l'absence de chiffre écrit ne mesure rien.
Peut-on garder RICE ?
Oui, The 34 Group garde RICE à une condition sur la colonne confiance : elle reste à « inconnu » pour une fonctionnalité IA tant que l'évaluation sur données réelles n'a pas eu lieu, et le score ne se calcule pas avant. Ajoutez le coût d'évaluation et la réversibilité, et vous avez la grille de ce guide sans changer d'outil. Vos collègues gardent l'arithmétique qu'ils connaissent, et le score devient vrai.
Combien de temps dure une évaluation avant construction ?
Dix jours ouvrés au plus chez The 34 Group. Deux jours pour sortir et annoter les cas réels, un jour pour écrire le seuil de réussite et la baseline, une semaine pour faire tourner le modèle et classer les erreurs, deux jours pour le verdict sur le jeu de test. Une évaluation qui dépasse les deux semaines est en train de devenir le projet, et c'est le moment de la couper.
La suite, en cohorte
Ce guide est le deuxième des trois modules que la cohorte d'Atelier 34, « Product manager à l'ère des agents », travaille sur le produit de chaque participant, en direct et en français. Vous arrivez avec votre liste de cinq idées IA et personne pour trancher, et vous en ressortez avec une seule fonctionnalité notée sur les cinq questions, évaluée sur vos propres données et lue sur les quatre chiffres, règle d'arrêt écrite dans le ticket ; le certificat Atelier 34 atteste ce livrable-là. Le premier module pose la roadmap produit avec des fonctionnalités IA en pari mesurable, le troisième tient le backlog quand l'agent code ; les deux sont dans nos guides. Rejoindre la liste de priorité.