Le coût récurrent de l'IA en production n'est pas l'inférence. C'est la requalification : les réévaluations, le réajustement des prompts et les tests de régression que vous devez à chaque fois qu'un modèle change sous vous. L'e-mail est arrivé un mardi.

Un modèle que nous faisions tourner en production depuis la majeure partie d'une année, épinglé à une version spécifique à dessein, était en cours de dépréciation. Nous avions une fenêtre pour migrer. Après cela, le point de terminaison commencerait à renvoyer des erreurs.

Nous avions fait tout ce que le manuel d'ingénierie prudente vous dit de faire. Nous ne flottions pas sur un alias de dernière version qui pourrait changer sous nous du jour au lendemain. Nous avons épinglé la version exacte du modèle, l'avons écrite dans la configuration et l'avons traitée comme toute autre dépendance que nous ne voulions pas voir bouger sans revue.

L'épinglage était censé être le choix sûr. L'avis de dépréciation a rendu clair quelque chose que l'épinglage avait discrètement caché : épingler une version de modèle ne vous achète pas l'immunité contre le changement. Cela vous achète un délai.

Le sol bouge toujours. Vous choisissez simplement le mardi. Cette distinction est le coût le plus sous-budgétisé de l'IA en production.

Les équipes modélisent leurs dépenses d'IA comme de l'inférence : tokens en entrée, tokens en sortie, fois le prix. Elles optimisent le choix du modèle, elles optimisent la longueur du prompt, elles débattent pour savoir si le modèle moins cher est suffisamment bon. Presque personne n'a de ligne dans le budget pour le jour où le modèle change et où tout le système doit être prouvé correct à nouveau.

Je vais appeler cette ligne la taxe de requalification, et à la fin de cet article, je veux que vous ayez à la fois un nom pour elle et un moyen de planifier autour d'elle. Ce que l'épinglage vous protège réellement, et ce qu'il ne protège pas Épingler une version de modèle est véritablement une bonne pratique. Cela arrête la dérive silencieuse du comportement, où un fournisseur met à jour les poids derrière un alias et vos sorties changent sans qu'une seule ligne de votre code ne change.

Si vous avez déjà vu un score d'évaluation bouger sans raison que vous puissiez trouver dans vos propres commits, vous savez déjà pourquoi les équipes épinglent. Mais un épinglage est un verrou de votre côté d'une porte que le fournisseur contrôle aussi. Les fournisseurs déprécient.

En 2026, la cadence, si tant est qu'elle ait changé, s'est accélérée : de nouveaux modèles de pointe sortent tous les quelques mois, les plus anciens sont mis au rancart, et plusieurs fournisseurs ont retiré des modèles avec un préavis court. La plupart des équipes ne font de toute façon pas tourner un seul modèle. La réalité actuelle, corroborée par les enquêtes d'ingénierie tout au long de l'année, est que les stacks de production gardent plusieurs modèles en vol à la fois : un modèle de pointe pour le raisonnement difficile, un modèle moins cher pour les appels routiniers, parfois un modèle auto-hébergé pour les données qui ne peuvent pas quitter le bâtiment.

Chacun de ceux-là est sur sa propre horloge de dépréciation. Donc l'épinglage ne supprime pas le changement. Il convertit un changement imprévisible en un changement planifié.

C'est une véritable amélioration, car un changement planifié est quelque chose que vous pouvez doter en personnel et budgétiser. Ce n'est un désastre que lorsque vous avez traité l'épinglage comme une permanence et n'avez rien mis dans le plan pour le jour où il expire. Ce que tout le monde oublie de chiffrer : le modèle n'est pas la seule chose qui change Voici la partie qui rend la requalification coûteuse plutôt que triviale.

Lorsque vous passez d'une version de modèle à la suivante, le modèle n'est pas une pièce interchangeable. Presque tout ce que vous avez construit au-dessus de l'ancien modèle était, que vous l'ayez voulu ou non, ajusté au comportement spécifique de ce modèle. Vos prompts étaient ajustés pour lui.

La formulation qui produisait de manière fiable une sortie structurée sur l'ancien modèle peut produire quelque chose de subtilement différent sur le nouveau. Vos exemples few-shot étaient calibrés sur ses particularités. Vos garde-fous étaient réglés contre ses modes de défaillance.

Vos parseurs de sortie étaient durcis contre les formes spécifiques qu'il avait tendance à renvoyer. Votre température et y...