Le modèle est une dépendance qui finit par disparaître
Une organisation peut intégrer un modèle d’intelligence artificielle comme s’il s’agissait d’un service permanent. Pourtant, les fournisseurs le traitent plutôt comme une version logicielle appelée à évoluer, être remplacée puis retirée. Anthropic distingue notamment les modèles actifs, anciens, dépréciés et retirés. Une fois un modèle retiré, les requêtes qui le ciblent échouent. Microsoft Foundry décrit une progression comparable : aperçu, disponibilité générale, ancien, déprécié et retiré. Dans son service, un modèle arrivé à la dernière étape retourne une erreur au lieu d’une réponse. Cette réalité transforme le choix initial. Le meilleur modèle aujourd’hui n’est pas nécessairement celui qui minimise le risque sur deux ans. Une PME qui branche directement un processus critique sur un identifiant précis accepte aussi son calendrier de fin de vie, ses règles de remplacement et les limites de sa plateforme. La question d’achat devrait donc inclure la sortie : combien de temps faut-il pour changer de modèle, que faut-il retester et quel service continue de fonctionner pendant la transition?
Un préavis ne remplace pas un plan de migration
Les fournisseurs publient des échéanciers, mais leur durée varie. Microsoft indique que plusieurs modèles généralement disponibles vendus par sa plateforme suivent un cycle standard de 18 mois, alors que certains modèles partenaires suivent un cycle de 12 mois. Pour les modèles en aperçu, le préavis peut être beaucoup plus court et une mise à niveau forcée demeure possible. L’entreprise se réserve aussi la possibilité d’accélérer un retrait lorsqu’un problème de sécurité ou de conformité l’exige. Anthropic publie de son côté les dates de dépréciation, de retrait et les remplaçants recommandés. Sa documentation montre qu’un avis peut laisser quelques mois plutôt que plusieurs années. Cela suffit pour une application bien inventoriée, mais devient serré lorsque le modèle se cache derrière plusieurs outils, automatisations ou fournisseurs. Un courriel envoyé au propriétaire d’un compte ne garantit pas que la personne responsable du processus d’affaires sera prévenue. La première protection n’est donc pas le préavis du fournisseur : c’est un registre interne qui relie chaque modèle à un propriétaire, un usage et une procédure de remplacement.
Changer le nom dans le code ne suffit pas
Microsoft avertit qu’une migration peut modifier le ton, la structure JSON, la latence, le coût ou la manière dont un modèle appelle des outils. Ces écarts sont parfois discrets. Une réponse reste lisible pour une personne, mais un champ change de nom et brise l’étape suivante. Un nouveau modèle refuse davantage un type de demande, appelle un outil plus tôt ou produit une réponse deux fois plus longue. La facture et le comportement opérationnel changent alors même si le scénario principal semble fonctionner. Il faut aussi vérifier les fonctions entourant le modèle : fenêtre de contexte, traitement des images, sorties structurées, mise en cache, région d’hébergement, quotas et politiques de conservation. Le remplaçant recommandé n’offre pas automatiquement la même combinaison. Pour un assistant qui prépare des devis, par exemple, le test ne doit pas seulement demander si la réponse paraît meilleure. Il doit confirmer que les montants proviennent des bonnes données, que les champs exigés sont présents, que les exceptions sont signalées et qu’aucun devis n’est envoyé sans l’approbation prévue.
Un jeu d’essai et un retour arrière valent plus qu’une promesse
Une petite organisation n’a pas besoin d’un laboratoire complexe. Elle peut conserver de 20 à 50 cas représentatifs : demandes ordinaires, entrées incomplètes, documents difficiles, refus attendus et situations où l’agent doit transférer le dossier à une personne. Pour chaque cas, l’équipe définit ce qui constitue un résultat acceptable. Elle compare ensuite l’ancien et le nouveau modèle sur la qualité, le temps, le coût complet, les appels d’outils et les interventions humaines. La migration peut commencer avec une faible proportion du trafic ou dans un environnement parallèle qui ne déclenche aucune action réelle. Les résultats problématiques retournent à l’ancien parcours pendant que l’équipe ajuste les consignes et les validations. Le retour arrière doit être testé avant le changement final, pas imaginé pendant une panne. Il faut aussi conserver les paramètres, les schémas et les versions du jeu d’essai utilisés pour la décision. Sans cette trace, une équipe risque d’approuver un remplacement sur quelques exemples favorables et de découvrir les régressions seulement après le retrait de l’ancien modèle.
La facilité de sortie devrait faire partie du choix
Au moment d’adopter un outil, une PME peut demander si l’identifiant du modèle est visible, si les dates de retrait sont accessibles par programmation et si des alertes peuvent être envoyées à plusieurs personnes. Elle devrait savoir si le fournisseur permet d’essayer le remplaçant avant l’échéance, de conserver deux déploiements en parallèle et de choisir le moment du basculement. Les applications importantes gagnent aussi à isoler l’appel au modèle derrière une couche simple, plutôt qu’à disperser les particularités d’un fournisseur dans chaque processus. Cette portabilité n’efface pas les différences entre modèles. Elle réduit toutefois la quantité de code et de procédures à reprendre. Un contrat de sortie concret comprend le jeu d’essai, les formats attendus, les permissions, les limites de coût, le délai acceptable et la personne qui autorise la migration. La rapidité des lancements rend les nouveaux modèles attrayants; elle garantit aussi que les anciens ne resteront pas immobiles. Préparer leur remplacement dès l’adoption permet de profiter des améliorations sans transformer chaque retrait en projet d’urgence.
