Chaque équipe créant des produits basés sur l'IA se retrouve finalement au même carrefour : continuons-nous à payer par appel d'API, investissons-nous dans l'exécution de nos propres modèles ou affinons-nous quelque chose entre les deux ? La vérité inconfortable est que la bonne réponse change à mesure que votre produit évolue – et les équipes qui reviennent sur cette décision surpassent régulièrement celles qui la traitent comme un choix architectural ponctuel.
C'est là qu'interviennent les rétrospectives de stratégie d'IA. Non pas comme un exercice de mots à la mode, mais comme un moyen structuré d'examiner les données d'utilisation réelles, les coûts réels et les évaluations honnêtes de la qualité pour décider si votre approche actuelle a toujours du sens.
Les trois voies (et pourquoi aucune d’entre elles n’est permanente)
Soyons clairs sur ce que nous comparons :
Acheter (basé sur l'API) : Vous appelez OpenAI, Anthropic, Google ou l'API d'un autre fournisseur. Vous payez par jeton. Vous obtenez les derniers modèles sans gérer l’infrastructure. Vous acceptez également leurs modifications de prix, leurs limites de taux et leurs délais de dépréciation.
Build (auto-hébergé) : Vous exécutez des modèles ouverts comme Llama, Mistral ou Qwen sur votre propre infrastructure. Vous contrôlez tout. Vous êtes également responsable de la charge des opérations, des coûts du GPU et du chemin de mise à niveau.
Affinement (personnalisé) : Vous prenez un modèle de base — soit via l'API de réglage fin d'un fournisseur, soit sur votre propre infrastructure — et vous l'entraînez sur les données spécifiques à votre domaine. Vous obtenez une meilleure qualité pour votre cas d’utilisation spécifique. Vous assumez également la complexité du pipeline de données et le recyclage continu.
La plupart des équipes commencent par Acheter. C'est la bonne décision dès le début : vous êtes encore en train de déterminer ce que vos fonctionnalités d'IA doivent faire. L’erreur est de rester en pilote automatique une fois que vos habitudes d’utilisation sont devenues claires.
Quand organiser une rétrospective de stratégie d’IA
Ne les planifiez pas sur un calendrier fixe simplement parce que quelqu'un vous l'a demandé. Exécutez-en un lorsque quelque chose change réellement :
- Votre facture API mensuelle franchit un seuil qui fait grimacer quelqu'un. Le nombre spécifique dépend de votre entreprise, mais vous le saurez lorsque les finances vous poseront des questions.
- Un modèle dont vous dépendez devient obsolète ou dont le prix est modifié. Cela arrive plus souvent que quiconque ne le souhaiterait. OpenAI a retiré des modèles à plusieurs reprises ; Anthropic révise ses prix ; Google met fin aux choses.
- Vos exigences de qualité changent. Peut-être que vous avez lancé un chatbot et que "assez bien" était bien, mais maintenant vous générez du contenu qui est envoyé aux clients.
- Votre volume de données change de manière significative. Le traitement de 100 000 jetons par jour est un problème différent du traitement de 10 M.
- Une nouvelle version du modèle change le calcul. Lorsqu'un modèle moitié moins cher offre une qualité comparable pour votre cas d'utilisation, cela vaut la peine d'en discuter.
Si aucune de ces choses ne s’est produite au cours du dernier trimestre, vous n’avez probablement pas besoin d’une rétrospective. Ne faites pas perdre de temps aux gens.
Organiser la rétrospective : un format pratique
Bloquez 90 minutes. Invitez les personnes qui touchent réellement à la pile d'IA : les ingénieurs qui construisent avec elle, le chef de produit qui voit les modèles d'utilisation et quiconque surveille la facture. Ignorez les dirigeants à moins qu'ils n'aient un contexte pertinent.
Partie 1 : Examen des données (30 minutes)
Commencez par des chiffres, pas des opinions. Tirez-les avant la réunion :
Données d'utilisation — Combien de jetons/requêtes par jour et par fonctionnalité ? Quelle est la ligne de tendance ? Quelles fonctionnalités connaissent la croissance la plus rapide ?
Données de coûts — Que dépensez-vous réellement, ventilé par fonctionnalité ou cas d'utilisation ? Quel est le coût par interaction utilisateur ? Comment cela a-t-il changé ?
Données qualité — Que dit votre suite d'évaluation ? Si vous ne disposez pas d'une suite d'évaluation, c'est votre première action. Suivez tous les signaux de qualité dont vous disposez : scores de satisfaction des utilisateurs, taux d’erreurs, taux d’hallucinations issus de contrôles ponctuels ou plaintes des clients.
Données de latence — Quels sont vos temps de réponse p50 et p95 ? Sont-ils acceptables pour votre UX ?
Mettez ces numéros sur un écran partagé. Laissez les gens les absorber. La conversation qui suivra sera nettement meilleure avec les données devant tout le monde.
Partie 2 : Analyse des options (30 minutes)
Pour chaque cas d'utilisation significatif, parcourez les trois options en utilisant vos chiffres réels :
Si on reste sur les API :
- Coût projeté au taux de croissance actuel dans 6 mois
- Dépendance à la feuille de route et aux tarifs du fournisseur
- Plafond de qualité avec modèle actuel
Si nous sommes auto-hébergés :
- Coût d'infrastructure estimé (instances GPU, temps d'exploitation, surveillance)
- Temps d’ingénierie pour mettre en place et maintenir
- Comparaison de la qualité pour vos tâches spécifiques (vous devez réellement comparer cela, pas deviner)
- Implications en matière de latence et de débit
Si nous affinons :
- Disponibilité et qualité des données de formation
- Coûts estimés de formation et d’inférence
- Amélioration de la qualité attendue pour votre domaine
- Fréquence de recyclage et complexité du pipeline
Soyez honnête sur ce que vous ne savez pas. "Nous aurions besoin de comparer Llama 3 sur notre ensemble d'évaluation avant de pouvoir comparer la qualité" est un très bon résultat de cette section.
Partie 3 : Décisions et actions (30 minutes)
Visez l’un des trois résultats par cas d’utilisation :
- Maintenir le cap — l'approche actuelle reste la meilleure solution. Documentez pourquoi afin de ne pas recommencer la prochaine fois.
- Exécutez une expérience — quelque chose semble prometteur mais vous avez besoin de données. Définissez l'expérience : qui la fait, ce qu'ils mesurent, quand ils rendent compte.
- S'engager dans une migration — les données soutiennent clairement un changement. Définir le plan de migration avec des jalons.
Attribuez un propriétaire à chaque élément d’action. Fixez une date d’arrivée. Écrivez-le quelque part où l’équipe regarde réellement.
Les compromis dont personne ne parle
La plupart des analyses construction/achat se concentrent sur le coût et la qualité. Ces éléments sont importants, mais il existe des facteurs plus subtils qui déterminent souvent si une décision fonctionne réellement :
Le fardeau des opérations est réel. Auto-héberger un modèle ne consiste pas simplement à « faire tourner une instance GPU ». Il s'agit de surveiller, de mettre à l'échelle, de mettre à jour, de gérer les pannes à 2 heures du matin et de se tenir au courant des correctifs de sécurité. Si votre équipe est déjà surchargée, l'ajout d'opérations de modèle peut vous coûter plus cher en changement de contexte que ce que vous économisez en frais d'API.
Le réglage fin est un engagement, pas une tâche ponctuelle. Votre modèle affiné commence à se dégrader au moment où le monde s'écarte de ses données d'entraînement. Vous avez besoin d'un pipeline pour collecter de nouveaux exemples, évaluer les performances, recycler et déployer. Si vous n'êtes pas prêt à maintenir cette boucle, vous vous retrouverez avec un modèle obsolète qui sous-performe la dernière offre d'API.
Le verrouillage du fournisseur ne concerne pas seulement le modèle. Il s'agit de l'outillage, de la bibliothèque d'invites que vous avez créée, du cadre d'évaluation et des connaissances institutionnelles sur la façon d'obtenir de bons résultats. Changer de fournisseur n’est jamais aussi simple que de changer de point de terminaison d’API.
Les exigences de latence peuvent vous forcer la main. Si vous avez besoin de réponses en moins de 200 ms, l'auto-hébergement peut être votre seule option pour certaines tailles de modèles. A l’inverse, si la latence n’a pas beaucoup d’importance, la simplicité opérationnelle des API est difficile à battre.
Le contexte réglementaire compte plus que ce que les gens admettent. Les cas d'utilisation dans les domaines de la santé, de la finance et du gouvernement ne peuvent souvent pas envoyer de données à des API tierces, quel que soit le coût. L'auto-hébergement n'est pas un choix dans ces contextes, c'est une exigence.
Anti-modèles rétrospectifs courants
Le piège du "l'herbe est plus verte". Chaque rétrospective se transforme en débat sur le passage à ce qui est le plus récent. Remédiez à ce problème en exigeant des références sur vos données réelles avant qu'une option ne fasse l'objet d'une discussion sérieuse.
La défense contre les coûts irrécupérables. "Nous avons déjà investi dans l'auto-hébergement, nous devons donc continuer." L’investissement passé ne rend pas une mauvaise approche bonne. Si les API sont devenues considérablement moins chères ou améliorées depuis que vous avez passé cet appel, reconnaissez-le.
Paralysie de l'analyse. L'équipe génère une énorme feuille de calcul de comparaison mais ne décide jamais réellement de quoi que ce soit. Fixez-vous un délai ferme : d’ici la fin de cette réunion, nous nous engageons à au moins une action concrète par cas d’usage.
Ignorer la capacité de l'équipe. Une solution techniquement optimale que votre équipe ne peut pas construire ou maintenir de manière réaliste n'est pas réellement optimale. Tenez compte de ce que vos collaborateurs peuvent réellement entreprendre compte tenu de tout le reste dans leur assiette.
Un modèle de suivi léger
Vous n'avez pas besoin d'un tableau de bord sophistiqué. Un tableau simple mis à jour trimestriellement fonctionne :
| Cas d'utilisation | Approche actuelle | Coût mensuel | Niveau de qualité | Déclencheur de l'examen suivant |
|---|---|---|---|---|
| Chat d'assistance client | API GPT-4o | $ X, XXX | 4,2/5 utilisateur assis | Le coût dépasse Y $ ou la dépréciation du modèle |
| Résumé du document | Lama 3 affiné | $X,XXX (infra) | Précision d'évaluation de 91 % | La précision tombe en dessous de 88 % |
| Génération de code | API Copilot + Claude | $ X, XXX | Satisfaction des développeurs 3,8/5 | Date de sortie ou de renouvellement du nouveau modèle |
Le problème n'est pas le format. C'est que vous avez une trace écrite de ce que vous avez décidé, pourquoi et ce qui déclencherait une nouvelle visite.
Le vrai objectif
Les rétrospectives sur la stratégie de l’IA ne visent pas à trouver la « bonne » réponse unique. Il s’agit de prendre l’habitude de tester régulièrement vos hypothèses par rapport à la réalité. Les équipes qui réussissent bien avec l’IA ne sont pas celles qui font le choix initial parfait : ce sont celles qui remarquent quand le paysage change et s’adaptent avant qu’il ne devienne une crise.
Commencez par les données. Soyez honnête quant aux compromis. Prenez une décision. Revisitez-le lorsque les circonstances changent. C'est tout le cadre.
Essayez NextRetro gratuitement — Organisez votre prochaine rétrospective de stratégie d'IA avec des colonnes structurées, des contributions anonymes et un vote pour faire ressortir ce que pense réellement votre équipe.
Dernière mise à jour : février 2026
Temps de lecture : 7 minutes
