Le lancement d’une fonctionnalité IA est différent du lancement d’une fonctionnalité traditionnelle, et la différence est plus marquée au cours de la première semaine après l’expédition.
Avec une fonctionnalité régulière, le code fait ce que le code fait. Avec une fonctionnalité d'IA, vous publiez quelque chose qui se comporte différemment sous charge, coûte plus cher par utilisateur que ce que vous avez modélisé et peut produire des résultats embarrassants dans des cas extrêmes que personne n'a pensé à tester. La rétrospective post-lancement n'est pas facultative : c'est là que vous déterminez si vous disposez d'une fonctionnalité viable ou d'une responsabilité coûteuse.
Ce qui rend les lancements d'IA différents
Si vous avez déjà livré un logiciel, vous avez déjà une idée de ce qui peut mal se passer. Les lancements d’IA partagent certains de ces modes de défaillance et en ajoutent plusieurs nouveaux :
Les coûts n'évoluent pas de manière linéaire en fonction des utilisateurs. Une fonctionnalité traditionnelle peut ajouter un coût marginal de serveur par utilisateur. Une fonctionnalité LLM ajoute un coût de jeton par interaction, et les utilisateurs qui aiment cette fonctionnalité l'utilisent davantage, ce qui coûte plus cher, ce qui peut être formidable ou financièrement non viable. Souvent, vous ne pouvez pas savoir lequel jusqu'à ce que de vrais utilisateurs l'atteignent.
Changements de qualité dans des conditions réelles. Votre suite d'évaluation exécute des cas de test propres. Les vrais utilisateurs envoient des entrées mal formées, collent des documents volumineux, demandent des choses auxquelles ils ne s'attendaient pas et essaient de casser des choses (parfois volontairement). La qualité à grande échelle est toujours pire que la qualité des tests.
Les limites de débit deviennent une architecture. Lorsque vous appelez une API externe, la capacité de votre fonctionnalité est limitée par les limites de débit de quelqu'un d'autre. Si votre lancement génère plus de trafic que votre limite de débit ne le permet, les utilisateurs rencontrent des erreurs qui n'ont rien à voir avec votre code.
La boucle de rétroaction est plus lente que vous ne le souhaiteriez. Avec une fonctionnalité traditionnelle, vous pouvez voir immédiatement si les boutons sont cliqués et si les formulaires sont soumis. Avec une fonctionnalité d'IA, vous avez besoin de temps pour évaluer si les résultats sont réellement bons – et « bon » peut signifier différentes choses pour différents utilisateurs.
Avant le lancement : ce qu'il faut mettre en place
Il ne s'agit pas d'une liste de contrôle de lancement complète : votre équipe sait comment expédier les logiciels. Voici les préparations spécifiques à l’IA qu’il est facile de négliger :
Contrôle des coûts. Fixez un plafond de dépenses strict avec votre fournisseur d'API ou sur votre infrastructure. Sachez quel est votre budget quotidien et définissez des alertes sur 50 %, 75 % et 90 %. Si vous n'avez pas mis en place un contrôle des coûts, un lancement réussi (beaucoup d'utilisateurs !) peut se transformer en un incident budgétaire.
Surveillance de la qualité des sorties IA. Vous avez besoin de quelque chose (n'importe quoi) qui vous indique si les sorties sont bonnes en production, pas seulement dans votre suite de tests. Il peut s'agir de signaux de retour d'utilisateur (pouce vers le haut/vers le bas), d'une évaluation automatisée d'un échantillon de résultats de production ou d'un examen manuel d'un sous-ensemble aléatoire. Définissez « assez bien » avant de vous lancer.
Un kill switch. Vous devriez pouvoir désactiver la fonction IA sans redéployer. Un indicateur de fonctionnalité, un changement de configuration, quelque chose. Si les résultats se détériorent ou si les coûts augmentent, vous devez arrêter l’hémorragie rapidement.
Dégradation gracieuse. Que se passe-t-il lorsque l'IA est indisponible ? Tarif limité ? Lent? Si votre réponse est « la fonctionnalité tombe en panne », corrigez-le avant le lancement.
Métriques de base. Capturez votre état actuel avant la mise en ligne de la fonctionnalité IA : les métriques que vous espérez améliorer, les coûts que vous espérez justifier, l'expérience utilisateur que vous espérez améliorer. Sans ligne de base, votre rétro sera "on dirait que tout s'est bien passé" au lieu de "voici ce qui a changé".
L’argument du déploiement progressif
Déployer une fonctionnalité d'IA pour tout le monde dès le premier jour est tentant : vous travaillez dessus depuis des mois et vous voulez voir l'impact. Mais les déploiements progressifs sont particulièrement utiles pour les fonctionnalités d’IA, car ils vous permettent de détecter les problèmes lorsque le rayon d’explosion est petit.
Une progression judicieuse :
- Nourriture interne pour chien (1 semaine) : Votre équipe l'utilise sur du travail réel. Pas une démo, pas un environnement de test – une utilisation quotidienne réelle.
- Petite cohorte (1-2 semaines) : 5-10% des utilisateurs. Assez pour voir des modèles d'utilisation réels, suffisamment petits pour que les problèmes affectent peu de personnes.
- Déploiement plus large (1-2 semaines) : 25-50% des utilisateurs. Vous testez maintenant à grande échelle et validez la véracité des prévisions de coûts.
- Disponibilité générale : Tout le monde comprend.
À chaque étape, examinez la qualité, le coût et les commentaires des utilisateurs avant de développer votre projet. Il n'est pas nécessaire qu'il s'agisse d'une réunion formelle à chaque étape : parfois, un enregistrement rapide du Slack avec les métriques ouvertes suffit. Mais ne sautez pas le chèque.
La rétrospective post-lancement : une approche en trois étapes
Au lieu d'exécuter une grande rétro, effectuez trois passes à des échelles de temps différentes. Chacun attrape des choses différentes.
Pass 1 : examen du premier jour (30 minutes, jour ouvrable suivant)
Il s'agit d'une synchronisation rapide axée sur les surprises immédiates. Ne suranalysez pas – vous n’avez pas encore suffisamment de données.
De quoi discuter :
- Quelque chose s'est-il cassé ou s'est-il comporté de manière inattendue ?
- Les coûts correspondent-ils à nos projections ou y a-t-il des surprises ?
- Des rapports d'utilisateurs nécessitant une attention immédiate ?
- La surveillance nous donne-t-elle des signaux utiles ou avons-nous des angles morts ?
Sortie : Une courte liste de correctifs urgents, le cas échéant. La plupart des conclusions du premier jour devraient être « nous allons surveiller cela » plutôt que « nous devons changer quelque chose ».
Pass 2 : Semaine 1 Deep Dive (60 minutes, fin de la première semaine)
Vous disposez désormais de données réelles. C’est ici que se déroule la discussion de fond.
Données à préparer :
- Utilisation active quotidienne et modèles d'utilisation (quand, combien, quels types de demandes)
- Coût réel par rapport au coût projeté, ventilé par modèle d'utilisation
- Signaux de qualité : évaluations des utilisateurs, taux de modification, taux d'erreur, éventuels résultats de révision manuelle
- Données de performances : répartition de la latence, taux d'expiration, atteinte des limites de débit
- Tickets d'assistance et commentaires des utilisateurs liés à la fonctionnalité IA
Structure de discussion :
Qu'est-ce qui nous a surpris ? Commencez ici. C’est dans l’écart entre les attentes et la réalité que se trouvent les informations les plus utiles. Peut-être que l'utilisation était 3 fois supérieure à ce que vous aviez prévu. Peut-être que les utilisateurs utilisent cette fonctionnalité pour quelque chose pour lequel vous ne l'avez pas conçue. Peut-être que la qualité est meilleure que prévu dans certains domaines et pire dans d’autres.
Que devrions-nous changer la semaine prochaine ? Il s'agit d'ajustements tactiques. Ajustements rapides, stratégies de mise en cache, modifications du UX pour guider les utilisateurs vers de meilleures entrées, optimisation des coûts pour les gaspillages évidents.
Qu'est-ce qui nécessite plus de données avant que nous puissions décider ? Certaines choses ne seront pas claires après une semaine. Nommez-les explicitement et décidez de quelles données vous avez besoin et quand vous en aurez suffisamment.
Pass 3 : examen stratégique du premier mois (60 à 90 minutes, après un mois)
C'est la rétro où vous évaluez si la fonctionnalité est viable à long terme.
Grandes questions :
- Cette fonctionnalité rapporte-t-elle son coût ? (Pas en valeur abstraite, mais en impact commercial mesurable.)
- La qualité est-elle suffisante ou accumulons-nous des dettes techniques et de confiance ?
- Pouvons-nous maintenir cela avec une utilisation actuelle de 5x ou 10x ?
- Qu'avons-nous appris sur la création de fonctionnalités d'IA qui s'appliquent à notre prochain ?
Cette passe doit donner lieu à des décisions stratégiques : investir davantage, optimiser et maintenir, ou repenser l'approche. Il devrait également produire une liste de leçons apprises suffisamment spécifiques pour être réellement utiles la prochaine fois.
Surprises en matière de coûts et que faire à leur sujet
Les dépassements de coûts constituent le problème le plus courant lors des lancements de fonctionnalités d’IA. Voici les modèles et les réponses pratiques :
Le problème des utilisateurs bavards. Un petit pourcentage d'utilisateurs génère une quantité disproportionnée d'utilisation de jetons. Si 5 % des utilisateurs représentent 40 % des coûts, vous devez décider s'il faut limiter le débit des gros utilisateurs, optimiser leur cas d'utilisation ou accepter le coût.
Le problème du contexte gonflé. Vous envoyez plus de contexte au modèle que nécessaire. Examinez vos invites et vos messages système : existe-t-il des instructions dont le modèle n'a pas besoin pour la plupart des requêtes ? Pouvez-vous inclure dynamiquement le contexte uniquement lorsque cela est pertinent ?
Le problème "nous avons oublié les tentatives". Les échecs déclenchent des tentatives, les tentatives coûtent des jetons et, sous charge, les tempêtes de nouvelles tentatives peuvent multiplier vos coûts. Implémentez un intervalle exponentiel et déterminez si une demande ayant échoué doit réessayer ou simplement renvoyer une erreur gracieuse.
Le problème de surpuissance du modèle. Vous utilisez votre modèle le plus performant (et le plus cher) pour des tâches qu'un modèle plus petit et moins cher gère parfaitement bien. Acheminez les demandes simples vers des modèles moins chers. Classez d'abord la tâche, puis choisissez le modèle.
Des leçons transférables à chaque lancement d’IA
Après plusieurs lancements de fonctionnalités d’IA, certains modèles émergent systématiquement :
Votre suite de tests était trop propre. Les entrées du monde réel sont plus compliquées, plus longues, plus étranges et plus conflictuelles que tout ce que vous avez testé. Créez une collection de « entrées réelles étranges » après chaque lancement et ajoutez-les à votre suite de tests.
Les utilisateurs vous diront ce que la fonctionnalité doit réellement faire. La façon dont les gens utilisent votre fonctionnalité d'IA s'écarte souvent de votre intention de conception. Faites attention à cette divergence : il s'agit d'une recherche de produits gratuite.
La vitesse compte plus que vous ne le pensez. Les utilisateurs ont une tolérance de latence pour les fonctionnalités d'IA inférieure à ce à quoi vous vous attendriez. Si cela prend plus de quelques secondes, ils commencent à se désengager. Les améliorations perçues des performances (réponses en streaming, indicateurs de progrès) aident beaucoup.
Vous avez surestimé la V1 et sous-estimé la V3. La première version d'une fonctionnalité d'IA est rarement impressionnante pour les utilisateurs. Mais la troisième version, après deux phases d’amélioration basées sur des données d’utilisation réelles, dépasse souvent les attentes. Expédiez la V1 en sachant qu'il s'agit d'un véhicule d'apprentissage et non du produit final.
Essayez NextRetro gratuitement — Structurez votre rétro de lancement d'IA avec des colonnes par étapes et votez sur les problèmes post-lancement à résoudre en premier.
Dernière mise à jour : février 2026
Temps de lecture : 8 minutes
