Les rétrospectives standard n'ont pas été conçues pour les produits dont le comportement de base est non déterministe, le coût évolue avec l'utilisation de manière imprévisible et les invites soigneusement réglées du mois dernier peuvent se dégrader si le fournisseur de modèles a envoyé une mise à jour.
Si vous construisez avec LLMs, vous avez besoin de rétrospectives qui tiennent compte des manières spécifiques dont les produits d'IA réussissent et échouent. Voici comment procéder sans transformer chaque rétro en un examen de métriques de trois heures.
Pourquoi votre format rétro normal n’est pas à la hauteur
Les rétrospectives traditionnelles sont construites autour d'un modèle prévisible : vous écrivez du code, vous l'expédiez, il fait ce que vous avez écrit. Les problèmes intéressants concernent le processus, la communication et les priorités.
Les produits d’IA brisent ce modèle de plusieurs manières :
Les sorties varient entre des entrées identiques. La même invite avec le même message utilisateur peut produire des résultats de qualité différents d'un appel à l'autre. Cela signifie que « cela fonctionne sur ma machine » s'étend à « cela a fonctionné lorsque je l'ai testé il y a cinq minutes ».
Les modes de défaillance sont nouveaux. Les hallucinations, l'injection rapide, l'amplification des biais et le débordement de la fenêtre contextuelle ne correspondent pas aux catégories de bogues traditionnelles. Votre équipe a besoin d'un vocabulaire et de cadres spécifiques pour en discuter.
Les coûts sont proportionnels à l'utilisation et difficiles à prévoir. Une fonctionnalité traditionnelle coûte ce qu'elle coûte à construire et s'exécute ensuite sur votre infrastructure existante. Le coût d'une fonctionnalité LLM évolue avec chaque interaction de l'utilisateur, et un moment viral peut faire exploser votre budget du jour au lendemain.
La qualité se dégrade de manière invisible. Une mise à jour du modèle provenant de votre fournisseur peut modifier subtilement la qualité de sortie sans aucune notification. Vos invites ont été optimisées pour une version de modèle spécifique ; cette optimisation peut ne pas être transférée.
Rien de tout cela ne signifie que les rétrospectives sont moins importantes. Cela signifie qu’ils doivent considérer différentes choses.
Les quatre objectifs pour les rétros de produits IA
Au lieu de la structure classique « ce qui a bien fonctionné/ce qui n’a pas fonctionné/éléments d’action », organisez votre rétrospective de produits d’IA autour de quatre objectifs distincts. Chacun fait apparaître une catégorie différente de problèmes.
Objectif 1 : Performances du modèle
Il s’agit de savoir si l’IA fait son travail au niveau technique.
Questions à discuter :
- Quelle est l’évolution de nos scores d’évaluation ? Est-ce que nous mesurons les bonnes choses ?
- Avons-nous remarqué des changements de qualité en corrélation avec les mises à jour du modèle ou les modifications apportées ?
- Quels sont nos pires cas d’échec de cette période ? Qu’ont-ils en commun ?
- Existe-t-il des cas d'utilisation où le modèle rencontre constamment des difficultés et que nous devrions aborder différemment ?
Ce dont vous avez besoin dans la salle : résultats d'évaluation, journaux d'erreurs, exemples de mauvais résultats signalés par les utilisateurs ou signalés par le contrôle qualité.
Objectif 2 : Efficacité de l’ingénierie rapide
Les invites constituent la surface de contrôle de votre produit. Ils méritent une attention particulière.
Questions à discuter :
- Quels changements rapides ont réellement amélioré les résultats, et lesquels ont été des changements latéraux ?
- Suivons-nous systématiquement les versions d'invite, ou est-ce ponctuel ?
- Avons-nous des invites fragiles : elles fonctionnent mais s'interrompent avec de légères variations d'entrée ?
- Combien de temps consacrons-nous à une itération rapide par rapport à d'autres travaux d'ingénierie ? Ce rapport est-il correct ?
Ce dont vous avez besoin dans la salle : un journal des changements rapides et leur impact mesuré. Si vous ne l'avez pas, l'établissement de ce système de suivi est votre première action.
Objectif 3 : Expérience utilisateur
Le modèle peut fonctionner correctement techniquement alors que les utilisateurs sont toujours frustrés.
Questions à discuter :
- Comment les utilisateurs réagissent-ils aux résultats générés par l’IA ? Que disent les retours ?
- Où les utilisateurs remplacent-ils, modifient-ils ou ignorent-ils les suggestions de l'IA ? Ce sont des moments riches en signaux.
- L’IA ajoute-t-elle de la valeur aux utilisateurs expérimentés mais crée-t-elle de la confusion chez les nouveaux utilisateurs, ou vice versa ?
- Y a-t-il des problèmes de confiance ? Les utilisateurs revérifient-ils tout ce que produit l’IA, ou lui font-ils trop confiance ?
Ce dont vous avez besoin dans la salle : commentaires des utilisateurs, analyses d'utilisation (en particulier les taux d'abandon et de modification) et tickets d'assistance liés aux fonctionnalités d'IA.
Objectif 4 : Coût et durabilité
Si vos fonctionnalités d'IA ne sont pas économiquement durables, la qualité et le UX n'ont pas d'importance.
Questions à discuter :
- Quel est notre coût réel par interaction utilisateur pour chaque fonctionnalité d'IA ?
- Comment les coûts évoluent-ils avec nos projections de croissance ? Est-ce linéaire ou avons-nous des amplificateurs de coûts ?
- Existe-t-il des possibilités de réduire les coûts sans impact significatif sur la qualité ? (Mise en cache, invites plus courtes, modèles plus petits pour des tâches plus simples.)
- Tirons-nous de la valeur des jetons que nous dépensons, ou envoyons-nous des invites gonflées et traitons-nous des résultats que nous n'utilisons pas ?
Ce dont vous avez besoin dans la salle : données de facturation ventilées par fonctionnalité, calculs du coût par interaction et tendances de croissance de l'utilisation.
Animer la réunion
Durée : 60 minutes. Vous pouvez le faire en 45 si votre équipe est disciplinée, mais n'essayez pas de l'entasser en 30.
Fréquence : Toutes les deux semaines si vous itérez activement sur les fonctionnalités d'IA. Mensuellement une fois que les choses se stabilisent. N'en exécutez pas un simplement parce qu'il figure sur le calendrier si rien de significatif n'a changé.
Qui devrait être là : Le chef de produit, les ingénieurs qui travaillent sur les fonctionnalités d'IA et toute personne qui examine les résultats du modèle ou les commentaires des utilisateurs. Vous n'avez pas besoin de toute l'entreprise.
Format qui fonctionne :
Examen des données (10 min) : Quelqu'un présente les indicateurs clés depuis la dernière rétro. Pas d'avis pour l'instant, juste des chiffres. Cela empêche la personne la plus bruyante de la pièce d’ancrer la conversation sur son anecdote.
Discussion à quatre objectifs (35 min) : Parcourez chaque objectif. Vous n'avez pas besoin de consacrer le même temps à chacun d'entre eux : certaines périodes, le coût sera le principal sujet ; d’autres fois, une régression qualitative dominera. Laissez les données vous guider là où vous vous concentrez.
Éléments d'action (15 min) : Soyez précis. « Améliorer la qualité des invites » n'est pas une action. "Exécutez le test A/B en comparant l'invite de résumé actuelle avec le candidat v7, mesurez les scores ROUGE et les taux de modification des utilisateurs, faites un rapport lors de la prochaine rétro" est un élément d'action.
Mesures qui valent la peine d'être suivies (et d'autres qui ne le sont pas)
Il est tentant de créer un tableau de bord élaboré qui suit des dizaines de mesures d’IA. Résistez-y. Commencez par un petit ensemble de mesures véritablement informatives et ajoutez-en d’autres uniquement lorsque vous devez répondre à une question spécifique.
Métriques de grande valeur :
- Taux de réussite des tâches — L'IA a-t-elle accompli ce que l'utilisateur a demandé ? Il s’agit de la mesure la plus importante, et c’est souvent la plus difficile à mesurer. Même un proxy approximatif (comme "l'utilisateur a accepté la sortie sans modification") vaut mieux que rien.
- Coût par interaction réussie — Pas seulement le coût par appel, mais le coût par résultat qui a réellement aidé l'utilisateur. Cela vous permet de rester concentré sur la valeur, pas seulement sur le volume.
- Taux de modification des utilisateurs — À quelle fréquence les utilisateurs modifient-ils le contenu généré par l'IA ? Un taux de modification élevé n'est pas nécessairement mauvais (cela peut signifier que les utilisateurs s'engagent activement), mais un taux de modification en hausse suggère que la qualité diminue.
- Latence chez p95 — Pas de latence moyenne, ce qui cache les expériences misérables. Le 95e centile vous indique ce à quoi font face vos utilisateurs les plus malchanceux, mais pas extrêmes.
Metriques qui semblent utiles mais ne le sont souvent pas :
- Nombre de jetons bruts — Vous indique le volume, pas la valeur. Intéressant pour la facturation mais pas pour les décisions produits.
- Longueur de l'invite — Plus long n'est pas automatiquement pire et plus court n'est pas automatiquement meilleur. Jugez les invites en fonction de la qualité du résultat et non de la longueur.
- Comparaisons des versions de modèles de manière isolée — La comparaison de GPT-4o et Claude 3.5 dans des benchmarks abstraits vous en dit très peu sur votre cas d'utilisation spécifique. Comparez uniquement vos tâches réelles avec vos critères d'évaluation réels.
Gérer les conversations difficiles
Les rétros de produits IA font apparaître des sujets inconfortables que les équipes évitent souvent :
"Nous ne savons pas vraiment si l'IA est bonne." Si votre équipe ne dispose pas d'un moyen systématique d'évaluer la qualité du résultat, admettez-le. L'action consiste à créer même un cadre d'évaluation minimal - un ensemble de cas de test avec les résultats attendus que vous exécutez après chaque modification.
"Nous dépensons beaucoup et nous ne sommes pas sûrs que cela en vaille la peine." Il s'agit d'une question de produit, pas technique. La fonctionnalité d’IA favorise-t-elle la fidélisation, la conversion ou d’autres résultats commerciaux ? Si vous ne parvenez pas à tracer cette ligne, vous créerez peut-être des fonctionnalités d’IA parce qu’elles sont impressionnantes plutôt que parce qu’elles sont précieuses.
"Le modèle fait parfois quelque chose de problématique et nous ne savons pas comment l'éviter." Ne cachez pas les problèmes de sécurité. Si le modèle produit occasionnellement du contenu biaisé, nuisible ou trompeur, il s'agit d'une action prioritaire et non d'un « problème connu » que vous classez.
"Notre ingénierie rapide ressemble à une conjecture." C'est souvent le cas, surtout au début. La version rétro est un bon endroit pour établir plus de rigueur : contrôle de version pour les invites, protocoles de test A/B et critères d'évaluation explicites.
Connecter les informations rétro aux décisions relatives aux produits
Le but de ces rétrospectives n’est pas de générer une liste de réglages. Il s'agit d'éclairer des décisions plus importantes en matière de produits :
- Devons-nous investir davantage dans cette fonctionnalité d’IA, ou est-ce une impasse ?
- Utilisons-nous le bon modèle pour ce cas d’utilisation, ou devrions-nous expérimenter des alternatives ?
- Notre approche actuelle est-elle évolutive, ou les coûts vont-ils réduire nos marges à 10 x les utilisateurs ?
- Y a-t-il des capacités d’IA que nous devrions ajouter, ou devrions-nous redoubler d’efforts pour fiabiliser celles existantes ?
Si votre rétro n'influence pas ce genre de décisions, c'est juste une réunion de statut en portant les vêtements d'une rétrospective.
Essayez NextRetro gratuitement — Utilisez le format à quatre objectifs avec des colonnes dédiées pour le modèle, les invites, UX et le coût dans votre prochaine rétrospective de produits d'IA.
Dernière mise à jour : février 2026
Temps de lecture : 7 minutes
