Votre agent IA a une date de péremption

Le modèle sur lequel tourne votre agent sera retiré, probablement dans les douze à dix-huit mois, et vous serez prévenu deux mois avant. Ce n’est pas un incident à redouter, c’est une opération de maintenance à inscrire au calendrier, au même titre qu’une montée de version de base de données. Ce qui distingue les équipes qui la passent en une demi-journée de celles qui y perdent trois semaines tient à une seule chose, préparée bien avant l’annonce.

Les dates sont publiques et récentes. Claude Sonnet 4 et Claude Opus 4 ont été retirés le 15 juin 2026, avec 62 jours de préavis ; Claude Opus 4.1, sorti en août 2025, a été retiré le 5 août 2026 après 61 jours, soit exactement douze mois de vie. Du côté d’OpenAI, GPT-4, GPT-3.5 Turbo, o1 et o1-pro s’éteignent le 23 octobre 2026, et l’API Assistants a fermé le 26 août. Un système écrit en 2024 qui n’a pas été touché depuis pointe aujourd’hui vers des noms de modèles dont plusieurs ne répondront plus cet automne.

Quel préavis un fournisseur donne-t-il vraiment ?

Assez pour migrer, jamais assez pour découvrir le problème le jour de l’annonce. Anthropic s’engage sur au moins 60 jours pour un modèle publiquement disponible, et les deux retraits de 2026 se sont tenus à un ou deux jours de cet engagement. OpenAI annonce six mois pour un modèle généralement disponible, trois pour une variante spécialisée, et deux semaines seulement pour une préversion.

Cette dernière ligne mérite qu’on s’y arrête, parce qu’elle piège régulièrement. Une préversion est ce qu’on essaie quand un modèle vient de sortir et qu’on veut voir ce qu’il fait de mieux ; c’est aussi, très souvent, ce qui finit en production parce que l’essai a bien marché et que personne n’a repassé la ligne de configuration en revue. Deux semaines de préavis sur un composant central, c’est un vendredi soir.

Le corollaire pratique est court : figez une version nommée, jamais un alias qui suit la dernière. Un alias vous fait changer de modèle une nuit, sans déploiement, sans annonce et sans que personne dans l’équipe puisse dire ce qui a bougé. Le préavis de soixante jours ne protège que ceux qui ont écrit le nom complet.

Qu’est-ce qui casse exactement quand le modèle change ?

Pas l’appel au modèle, qui se corrige en changeant une chaîne de caractères. Ce qui casse, ce sont les consignes que vous avez écrites pour compenser les défauts du modèle précédent.

Tout agent en production porte une couche de rattrapage, accumulée pendant des mois : la phrase qui empêche le modèle de conclure trop vite, l’exemple ajouté parce qu’il confondait deux formats de date, l’instruction en majuscules qui l’oblige à vérifier avant d’affirmer. Chacune de ces phrases répondait à un comportement réel et daté. Sur un modèle qui n’a plus ce défaut, elles ne sont pas neutres : elles restent des instructions, elles consomment du contexte, et certaines produisent l’excès inverse. La consigne qui empêchait de conclure trop vite fait maintenant hésiter un modèle qui avait raison.

Le second poste, moins visible, est l’économie. Un agent facture surtout du contexte relu à chaque étape, et le coût d’un agent tient à la reprise du contexte plutôt qu’à la longueur de ses réponses. Un nouveau modèle change le prix au jeton, la taille de fenêtre, parfois le comportement du cache de prompt, et une migration réussie sur la qualité peut se traduire par une facture multipliée sans que personne n’ait changé d’usage. Cela se vérifie en une heure, à condition de savoir qu’il faut le vérifier.

Le troisième est le plus discret et le plus long à diagnostiquer. Un agent qui garde des notes d’une fois sur l’autre a écrit ces notes avec l’ancien modèle, dans un style et un niveau de détail que le nouveau n’aurait pas produits. Elles restent lisibles, elles ne sont pas fausses, et elles orientent quand même. C’est la version « migration » du problème que nous décrivons à propos de ce qu’une mémoire d’agent doit oublier.

Pourquoi le jeu de cas d’essai est le seul vrai plan de migration

Parce qu’il transforme une question d’opinion en une lecture de tableau. Nous défendons depuis longtemps qu’un essai se juge sur trente cas tirés de votre historique, rejoués trois fois, dont la bonne réponse est écrite avant le premier essai. L’argument était l’achat : ne pas se laisser convaincre par une démonstration.

L’usage qui rentabilise vraiment ce travail arrive plus tard, et personne ne le mentionne au moment de le faire. Ces trente cas sont ce que vous rejouez le jour de l’annonce de retrait. Vous obtenez, en une demi-journée, la liste exacte des endroits où le nouveau modèle se comporte différemment, avec la nature de l’écart. Sans ce jeu, la migration consiste à remplacer un modèle qu’on connaissait mal par un modèle qu’on ne connaît pas, puis à attendre qu’un utilisateur signale quelque chose. Ce n’est pas une migration, c’est un pari avec un délai de révélation de trois semaines.

La variance compte autant que le résultat. Un cas qui passe trois fois sur trois avec l’ancien modèle et deux fois sur trois avec le nouveau n’est pas un cas qui a régressé de 33 %, c’est un cas devenu instable, et l’instabilité coûte plus cher qu’une erreur franche parce qu’elle échappe aux tests suivants.

Ce que nous avons appris en migrant, et la règle que nous en avons tirée

Nous avons changé de modèle plusieurs fois depuis le début de Balt, et la première fois s’est mal passée pour une raison que je trouve rétrospectivement évidente.

Nous avions dispersé les corrections. Une partie vivait dans le prompt, une partie dans le code qui prépare les appels, une partie dans des vérifications ajoutées après coup autour des réponses. Chacune avait été écrite pour un défaut précis d’un modèle précis, et aucune ne disait lequel. Au moment de migrer, nous ne pouvions ni les garder toutes, faute de savoir ce qu’elles coûtaient, ni les retirer toutes, faute de savoir ce qu’elles protégeaient.

La règle que nous appliquons depuis tient en une phrase, et elle est écrite dans notre documentation interne plutôt que dans un mémo : une correction écrite pour un modèle donné vit dans une section du prompt réservée à ce modèle, jamais dans le code qui l’entoure. La question qui tranche est simple à poser à chaque ajout : est-ce que ceci sera encore utile pour un modèle deux générations meilleur ? Si la réponse est non, la chose a une date de péremption connue et doit être rangée à un endroit qu’on vide. Si la réponse est oui, elle peut vivre dans le produit.

Le bénéfice ne s’est pas vu à la migration suivante, il s’est vu à celle d’après. Vider une section identifiée prend une heure ; désassembler une couche de rattrapage dispersée dans trois fichiers prend une semaine et laisse toujours un doute.

Que demander à un éditeur avant de signer ?

Pas quel modèle il utilise, qui est la question que tout le monde pose et dont la réponse ne vous apprend rien. Le nom du modèle est un instantané ; ce qui vous concerne est la capacité de l’éditeur à en changer sans vous.

Trois questions font mieux, et elles se posent dans cet ordre. Depuis combien de temps tournez-vous sur ce modèle, combien de fois en avez-vous changé, et à quelles dates ? Qu’a coûté la dernière migration, en jours de travail et en régressions constatées ? Un éditeur qui répond précisément a un jeu de cas et s’en sert. Un éditeur qui n’a jamais migré n’est pas fautif, il est jeune, et vous savez désormais que la première migration se fera sur votre déploiement.

Ces questions ont un mérite secondaire, qui est de résister à la démonstration. Elles portent sur ce qui s’est passé plutôt que sur ce que le produit sait faire, et c’est exactement le terrain où un agent réel se distingue d’un habillage.

Ce que ce calendrier change pour votre propre déploiement

Il déplace une catégorie de dépense. Un agent n’est pas un logiciel qu’on installe et qu’on laisse tourner cinq ans ; c’est un composant dont la fondation est renouvelée par un tiers tous les douze à dix-huit mois, avec deux mois de préavis. Le budget d’exploitation doit contenir cette ligne, et le contrat doit dire qui la porte.

Datadog relève par ailleurs que près de sept entreprises sur dix font tourner au moins trois modèles différents, et que la part de celles qui en dépassent six a presque doublé en un an. Le calendrier de retrait ne s’applique donc pas une fois tous les dix-huit mois, mais trois fois, à des dates différentes, décidées par des fournisseurs qui ne se coordonnent pas.

C’est une raison de plus de ne pas multiplier les endroits où ce choix se prend, et cela rejoint une question qui se pose bien avant celle du modèle : combien d’agents détiennent du contexte sur votre entreprise, et lequel d’entre eux sera migré par quelqu’un dont ce n’est pas le métier.