Solution · AI Operations
Le modèle que vous avez choisi va disparaître. La seule question, c'est de le savoir avant votre client.
Choisir un modèle n'est pas une décision qu'on prend une fois : les fournisseurs retirent des versions avec préavis, les mettent à jour par en dessous et bougent les prix — et votre système, lui, reste en production. On construit la fonction qui transforme un changement de modèle en opération ennuyeuse : banc d'essai à vous, comparaison réelle et retour arrière, au lieu d'un saut dans le vide.
Le problème
Votre fournisseur de modèle est un fournisseur. Vous le traitez comme une constante.
- Le modèle que vous utilisez a été choisi un après-midi, il y a dix-huit mois, parce que c'était le bon à ce moment-là. Personne n'a revu la décision et personne ne sait si elle tient encore.
- Un e-mail de retrait est arrivé avec une date. Personne ne sait combien de vos systèmes dépendent de cette version précise, donc personne ne sait quel travail se cache derrière cette date.
- Quelqu'un a testé un nouveau modèle sur cinq exemples écrits à la main, l'a trouvé meilleur, et l'a mis en prod. La comparaison était une impression, pas une mesure.
- Un matin la qualité a changé sans que personne ne touche à rien. On a débattu : le modèle, le prompt ou la donnée ? On a tranché au feeling et on est passé à autre chose.
- Le même modèle cher traite la tâche qui demande du discernement et celle qui range juste un e-mail dans trois cases, parce que décider qui va où n'a jamais été le travail de personne.
- Si le fournisseur tombe une demi-heure, vous tombez une demi-heure. Il n'y a pas de second chemin et personne n'a jamais testé s'il pourrait y en avoir un.
- Changer de modèle est perçu comme un projet de six semaines, donc ça ne se fait pas — et la décision d'il y a dix-huit mois reste gelée par peur, pas par discernement.
Le coût de ne rien changer
Vous avez un fournisseur critique dont le produit change sous vos pieds, et aucun moyen d'en mesurer l'effet. Ça se paie de trois façons. D'abord la surprise : une date de retrait tombe et la migration se fait en courant, sans banc d'essai, avec le risque réparti sur vos clients. Ensuite la dérive silencieuse, qui est pire : le système ne plante pas, il répond simplement un peu autrement — plus long, dans un autre format, en refusant ce qu'il acceptait avant — et comme personne ne mesure, on le découvre par une réclamation. Enfin le coût d'opportunité : comme changer fait peur, on ne change pas, donc on continue de payer un modèle cher pour des tâches bon marché et de supporter un modèle moins bon que celui déjà disponible.
La solution
On transforme le changement de modèle en une opération mesurée, réversible et ennuyeuse
- 1L'inventaire d'abord, que presque personne n'a : quels systèmes appellent quel modèle et dans quelle version exacte, quelle tâche fait chaque appel, et ce qui casserait si cette version disparaissait demain. Sans ça, tout préavis de retrait devient une urgence au lieu d'une tâche planifiée.
- 2On construit votre banc de cas de référence : un ensemble figé de cas réels de votre exploitation — les normaux, les bizarres et ceux qui ont mal tourné — avec le résultat que vous jugez correct. C'est l'actif qui fait passer la comparaison de modèles de l'impression à la mesure, et il est à vous même si vous nous virez demain.
- 3On définit le routage par tâche : quels appels ont vraiment besoin du bon modèle et lesquels se résolvent avec un modèle moins cher ou plus rapide sans dégrader le résultat. La décision se prend avec le banc sous les yeux, pas avec l'intuition de celui qui parle le plus fort.
- 4On monte la procédure de migration : candidat passé au banc, comparaison côte à côte sur votre travail réel, déploiement progressif sur une part du trafic, comparaison des sorties en direct, et seulement ensuite la bascule complète. Avec le retour arrière préparé et répété avant de commencer, pas improvisé le mauvais jour.
- 5On installe la détection de dérive. Les fournisseurs mettent aussi à jour sans changer le nom de version, et ça ne plante pas : le format bouge, la longueur bouge, l'adhérence au JSON se relâche, et la ligne où le modèle dit non se déplace. Le banc tourne périodiquement pour que cette dérive soit repérée par une alerte et non par un client.
- 6Et on le met au calendrier. Les dates de retrait de vos fournisseurs arrivent comme des alertes avec de la marge — pas comme un e-mail que quelqu'un a archivé — et la décision de modèle se revoit à une cadence convenue, avec le coût par tâche et la qualité mesurée sur la table.
Ce qui change
Ce que tu arrêtes de perdre
Anthropic s'engage sur un préavis minimum de 60 jours avant de retirer ses modèles publics, et OpenAI sur un minimum de six mois pour ses modèles en disponibilité générale. Ce préavis ne sert que si quelqu'un sait quels systèmes chez vous dépendent de la version concernée : l'inventaire transforme une date en plan.
Politiques publiques de dépréciation des fournisseurs (Anthropic, OpenAI), consultées en 2026-08
Changer de modèle cesse d'être un saut dans le vide : le candidat est mesuré sur vos propres cas, avec votre définition du correct, avant de toucher un seul client.
Mécanisme
La dérive silencieuse cesse de se découvrir par une réclamation. Quand le fournisseur met à jour par en dessous, les sorties changent sans erreur — format, longueur, adhérence au JSON, seuil de refus — et le banc périodique en fait une alerte.
Mécanisme
Le coût baisse par conception et non par coupe : quand chaque tâche va au modèle dont elle a besoin, l'économie vient de ne plus payer du discernement là où il suffisait de trier — pas d'utiliser une IA moins bonne.
Mécanisme
Ce qu'on mesure : systèmes avec version de modèle inventoriée, qualité du candidat face au banc de cas de référence, écarts détectés par les exécutions périodiques, coût par tâche avant et après routage, temps de retour arrière répété, et jours de marge sur chaque date de retrait annoncée.
Ce qu'on mesure
Fiche technique
- Travail supprimé
- que la décision de modèle de votre entreprise se gèle par peur, et que chaque retrait, mise à jour ou changement de prix du fournisseur se traite en courant, sans mesure et avec les clients au milieu
- Mise en place habituelle
- 4 à 8 semaines
- Entrée
- vos systèmes d'IA en production, les versions de modèle qu'ils appellent aujourd'hui et des cas réels de votre exploitation — y compris ceux qui ont mal tourné
- Sortie
- un inventaire vivant de ce qui dépend de quelle version, un banc de cas de référence à vous, un routage par tâche, une procédure de migration avec retour arrière répété, et des alertes de dérive et de dates de retrait
- Compatible avec
- OpenAIAnthropicGoogle Vertex AIAzure OpenAIAmazon BedrockMistralLangSmithLangfuseBraintrust
- Peut se connecter à
- Vos journaux de production, d'où viennent les cas du bancVotre couche d'évaluation et votre gestion de prompts, si elles existentVotre passerelle ou routeur de modèles, pour que changer soit de la configurationVotre tableau de coûts par modèle et par tâcheVotre processus de changement et votre calendrier d'astreinte
- Ce qu’on mesure
- % de systèmes avec version de modèle inventoriée et responsable nomméqualité du candidat face au banc de cas de référenceécarts de comportement détectés par les exécutions périodiquescoût par tâche avant et après routagetemps de retour arrière répété en exercicejours de marge sur chaque date de retrait annoncée
- Adapté pour
- les entreprises avec de l'IA déjà en production et une dépendance réelle à un ou plusieurs fournisseurs de modèle — DSI, CTO ou responsable IA — qui ont besoin que la décision de modèle soit révisable, mesurable et réversible plutôt qu'un engagement à l'aveugle
- Pas adapté pour
- ceux qui sont encore en pilote sans trafic réel — il n'y a pas de banc à construire, il faut d'abord arriver en production — ni ceux qui attendent qu'on leur nomme le meilleur modèle du marché : ça dépend de votre travail, et c'est justement pour ça que ça se mesure au lieu de se commenter
Questions fréquentes
Et on continue de le dire : changer de modèle parce que quelque chose sous-performe, c'est presque toujours déplacer le problème, parce que le goulot est en général un processus mal défini ou de la donnée sale. Ici c'est l'inverse. On ne change pas de modèle pour réparer quoi que ce soit : on change parce que le fournisseur retire la version que vous utilisez, parce qu'il l'a mise à jour par en dessous, parce qu'une option fait la même chose pour une fraction du coût, ou parce que la décision d'il y a dix-huit mois n'est plus celle que vous prendriez aujourd'hui. Ces changements arriveront, que vous le vouliez ou non. Ce qu'on monte, c'est la capacité de les absorber sans drame et avec des preuves — et, au passage, ce qui vous dit quand le modèle n'est pas le problème, c'est-à-dire exactement quand il ne faut pas y toucher.
C'est un ensemble figé de cas réels de votre exploitation avec le résultat que vous jugez correct : les cas normaux, les bizarres, les ambigus et surtout ceux qui ont mal tourné. Quelques dizaines à quelques centaines de cas bien choisis suffisent en général ; pas besoin de milliers. C'est le cœur du sujet parce que c'est la seule chose qui transforme « ce modèle a l'air meilleur » en un chiffre comparable : vous passez le candidat sur le même ensemble que le modèle actuel et vous voyez exactement où il s'améliore et où il se dégrade, sur votre travail et pas sur un examen générique. Et c'est ce que vous gardez de plus précieux du projet, parce que ça ne dépend d'aucun fournisseur : ça marchera aussi bien l'an prochain avec des modèles qui n'existent pas encore. C'est pour ça qu'on le construit avec vous et qu'il reste chez vous.
Parce qu'ils mesurent autre chose. Un benchmark public vous dit comment un modèle se comporte sur un examen standardisé qui ne ressemble pas à votre exploitation : ni vos documents, ni votre vocabulaire, ni vos cas limites, ni votre définition du correct. C'est une information utile pour écarter des candidats nettement plus faibles et pour lire où va le marché, et on s'en sert pour ça. Mais un classement ne peut pas prendre la décision : un modèle peut mieux scorer en public et moins bien rendre sur une tâche précise avec des documents précis, et l'inverse arrive aussi. Le fournisseur, en plus, a un intérêt évident dans la comparaison. Votre banc de cas, non.
En exécutant le banc périodiquement contre le même endpoint et en comparant à la ligne de base. C'est la seule méthode fiable, parce qu'une mise à jour silencieuse ne produit pas d'erreur : elle produit une dérive. Le format des appels d'outils bouge un peu, l'adhérence au JSON se relâche, les réponses s'allongent ou raccourcissent, et la frontière de ce que le modèle refuse se déplace. Rien de tout ça ne casse l'intégration, donc la supervision classique — disponibilité, latence, taux d'erreur — reste au vert pendant que la qualité glisse. Avec les exécutions périodiques du banc, cette dérive sort en alerte avec des cas concrets à l'appui, et la conversation devient « ça a changé mardi et voici les cas » au lieu de « j'ai l'impression qu'il répond bizarrement en ce moment ».
Moins que n'importe quelle alternative, et c'est facile à vérifier : les livrables sont à vous et ne dépendent pas de nous. L'inventaire des versions, le banc de cas de référence, les règles de routage, la procédure de migration et le calendrier des retraits sont documentés et vivent dans vos systèmes. On monte sur votre stack et sur les outils d'évaluation que vous avez déjà ; si vous n'en avez aucun, on choisit avec vous et on explique pourquoi, sans couche propriétaire dont il faudrait ensuite sortir. La fin normale, c'est que votre équipe l'opère — c'est former son équipe, un autre service — ou qu'on l'opère nous le temps que cette capacité mûrisse. Les deux sorties sont écrites dès le départ.
On le monte chez toi ?
Tu as ciblé le problème. On livre la solution et on la laisse mesurée.