Qu’est-ce que la dépendance à un modèle IA ?

La dépendance à un modèle IA désigne la situation où une application ne peut plus changer de modèle sans réécriture. L’identifiant du modèle, le format attendu de ses réponses et ses particularités de prompt sont dispersés dans le code métier, si bien que passer à une nouvelle version devient un projet à financer, arbitré au budget suivant.

Le 30 juillet 2026, OpenAI a divisé par cinq le prix de Luna, le modèle le plus économique de sa gamme GPT-5.6 (annonce d’OpenAI rapportée le jour même par CNBC), et les applications qui appelaient déjà Luna en ont profité sans qu’une ligne de code bouge. Le 10 août, Anthropic a fait du tarif d’introduction de Claude Sonnet 5 son tarif standard, en renonçant à la hausse prévue au 1er septembre : les applications déjà passées à Sonnet 5 le conservent sans rien modifier. Claude Opus 5, sorti le 24 juillet sous un identifiant que personne n’appelait encore, n’atteint que les applications prêtes à changer d’identifiant, et c’est là que l’architecture entre en jeu.

Le couplage reste invisible tant que le fournisseur ne bouge pas. Il se manifeste le jour où une version est dépréciée, ou quand un modèle plus capable sort sous un autre identifiant. En 2026, ces deux situations se présentent plusieurs fois par an.

Le terme recouvre deux réalités distinctes. La dépendance à un fournisseur tient au contrat, à l’hébergement et à l’outillage. La dépendance à un modèle tient à la façon dont le code appelle une version précise, et c’est la plus discrète des deux, parce qu’elle se loge dans le code applicatif.

Que perd une application figée sur un identifiant de modèle ?

Une application figée sur un identifiant ne profite que des baisses appliquées à celui-ci, comme celle de Luna. Les nouvelles versions exigent de changer d’identifiant, avec leurs gains de capacité et parfois des tarifs plus bas, et une application figée n’en voit rien.

Les gains de capacité arrivent sous un nouvel identifiant

Claude Opus 5 est sorti le 24 juillet 2026 au tarif d’Opus 4.8, 5 dollars le million de tokens en entrée et 25 en sortie (annonce d’Anthropic du 24 juillet 2026), avec un niveau de capacité supérieur, et il est devenu le modèle par défaut de l’offre Claude Max. Une application qui appelle claude-opus-4-8 paie exactement ce qu’elle payait avant, et ne verra jamais rien de cette génération. L’écart touche aussi le prix : une application restée sur Claude Sonnet 4.5 paie 3 dollars le million de tokens en entrée et 15 en sortie, quand Claude Sonnet 5 est facturé 2 et 10 dollars (grille publique d’Anthropic consultée le 16 septembre 2026). Le gain réel se mesure sur vos volumes, car Sonnet 5 utilise le nouveau tokenizer présenté plus bas.

Des prix qui évoluent en sens contraires selon la gamme

La baisse de Luna ne dessine d’ailleurs aucune tendance générale. Dans sa mise à jour du 15 septembre 2026 (méthodologie v1.1, page consultée le 16 septembre 2026), l’indice de prix des tokens de BenchLM, qui suit 40 modèles, mesure sur un an une hausse de 72 % du segment frontier, de 7,4 % du segment budget, et une baisse de 7,7 % du segment intermédiaire, où il retient Claude Sonnet 5 à 2 et 10 dollars le million de tokens. Les prix divergent donc d’une gamme à l’autre, et le rattrapage automatique ne vaut que pour l’identifiant qui a bénéficié d’une baisse.

En haut de gamme, Claude Fable 5.1, sorti le 1er septembre 2026, reprend les tarifs de Fable 5, 10 dollars le million de tokens en entrée et 50 en sortie, soit le double du tarif mixte d’Opus 5. Sur la grille, seules les lectures en cache baissent, à 0,25 dollar le million contre 1 dollar sur Fable 5 (grille publique d’Anthropic consultée le 16 septembre 2026), une économie elle aussi réservée au nouvel identifiant.

La dépréciation des versions et leurs dates de retrait

Anthropic a retiré six versions de son API entre février et août 2026, de Claude Sonnet 3.7 à Claude Opus 4.1, et une requête adressée à un modèle retiré échoue. L’éditeur s’engage à un préavis d’au moins soixante jours pour retirer un modèle public : une version active peut donc disparaître dès deux mois après l’annonce de son retrait. Au 16 septembre 2026, la documentation donnait à chaque version active une date plancher, avant laquelle la version ne sera pas retirée : le 29 septembre 2026 pour Claude Sonnet 4.5.

Une application livrée au printemps tourne déjà sur une génération précédente, et personne ne sait chiffrer la bascule : la direction technique ne la propose pas, et l’arbitrage glisse au budget suivant. Prenons, à titre d’exemple, un agent de tri des sinistres livré en mars sur Claude Sonnet 4.5 : il peut très bien fonctionner aujourd’hui, mais le jour où le retrait de cette version sera annoncé, l’équipe pourra ne disposer que de deux mois pour réécrire ses prompts, revalider ses sorties et le redéployer.

Où se loge le couplage dans une application IA ?

Le couplage se loge dans des détails d’implémentation rarement documentés : l’écriture de l’identifiant, la mise au point des prompts et la lecture des réponses.

L’identifiant écrit en dur, et ses copies

Un nom de modèle écrit dans le code d’un service est rarement seul : on retrouve la même chaîne dans un script de traitement par lots, un notebook d’analyse, une tâche planifiée ou le paramétrage d’un outil d’automatisation. Chaque copie est un endroit de plus à modifier le jour de la bascule, et celle qu’on oublie continue d’appeler l’ancienne version jusqu’à son retrait.

Les prompts calibrés pour une version

Un prompt mis au point sur une version porte la trace de ses faiblesses : consignes répétées pour stabiliser un format, exemples choisis pour contourner une erreur récurrente, contraintes de longueur. Sur une version récente, ces rustines deviennent inutiles, parfois gênantes, et un prompt hérité peut brider un modèle plus capable. Relire les guides de migration qu’Anthropic publie vers ses derniers modèles évite de reconduire des consignes superflues.

La lecture des réponses et les paramètres d’appel

Le code qui lit la réponse attend souvent une structure précise, par exemple un champ à tel endroit. Un modèle plus récent qui formule autrement casse ce parseur sans bruit, et l’erreur n’apparaît qu’en aval, dans un tableau de bord faux. Les paramètres d’appel posent la même difficulté : sur Claude Opus 4.7 et les modèles suivants, l’API d’Anthropic renvoie une erreur quand temperature, top_p ou top_k reçoivent une valeur autre que celle par défaut (documentation Claude, consultée le 16 septembre 2026).

Comment savoir si votre architecture est couplée à un modèle ?

Quelques questions situent le couplage. La situation saine tient en un seul fichier de configuration, une bascule sans redéploiement, un jeu d’évaluation, une mesure par cas d’usage et un décideur nommé, et chaque écart à cette situation rend le changement de modèle plus coûteux.

  1. Combien de fichiers contiennent un identifiant de modèle ? Au-delà d’un fichier de configuration, le couplage est établi.
  2. Pouvez-vous basculer un cas d’usage vers une autre version sans redéployer l’application ?
  3. Disposez-vous d’un jeu d’évaluation qui rejoue vos cas réels sur un modèle candidat ?
  4. Connaissez-vous la consommation par cas d’usage, ou seulement la facture globale du mois ?
  5. Qui décide d’un changement de modèle, et sur quels critères écrits ?

Qui décide d’un changement de modèle

La dernière question est la seule de la liste qui ne se règle pas dans le code. Quand personne n’est nommé, le modèle en production reste celui qu’a retenu l’équipe qui a livré le premier prototype, et ce choix n’a jamais été rouvert. Nous conseillons de confier cette décision à la direction technique, sur une grille écrite et révisée à date fixe.

Que fait une couche d’abstraction de modèle ?

La couche d’abstraction est un point de passage unique entre vos applications et les modèles. Elle sert à découpler, à router, à mesurer et à gouverner.

Découpler le code métier du nom du modèle

Le code métier appelle une capacité, par exemple « résumer un dossier de sinistre », et la correspondance entre cette capacité et un modèle vit dans une configuration versionnée. Changer de modèle revient alors à modifier une ligne relue, avec historique et retour arrière, comme n’importe quel paramètre d’infrastructure.

Router chaque cas d’usage vers le modèle adapté

Chaque cas d’usage part vers le modèle qui lui convient. Un classement de tickets entrants et une revue contractuelle n’ont pas les mêmes exigences de raisonnement, et la gamme d’un seul fournisseur suffit souvent à couvrir l’écart : la documentation d’Anthropic oriente les tâches simples vers Haiku, la plupart des charges de production vers Sonnet et le raisonnement le plus complexe vers Opus.

Mesurer au niveau du cas d’usage

Latence, taux d’échec, consommation et qualité sont mesurés cas d’usage par cas d’usage. Cette mesure montre quel cas d’usage coûte trop cher pour ce qu’il rapporte et fournit la base de comparaison dont toute migration aura besoin.

Gouverner depuis un point unique

Journaux, garde-fous et traces d’approbation sont centralisés au même endroit, ce qui rend l’inventaire des systèmes IA tenable. C’est aussi là que s’applique une méthode de supervision comme LOOP™, qui classe chaque action possible d’un agent dans une zone de confiance, de l’exécution autonome au blocage immédiat. Un changement de modèle modifie le comportement de l’agent, et les zones attribuées à ses actions méritent d’être revues avant la remise en production.

L’inventaire des systèmes IA et l’article 50 de l’AI Act

Cette dernière fonction porte une échéance réglementaire. L’article 50 de l’AI Act s’applique depuis le 2 août 2026 : un système conçu pour dialoguer avec des personnes doit leur indiquer qu’elles s’adressent à une IA, et les fournisseurs de systèmes génératifs doivent marquer les contenus produits dans un format lisible par machine. Pour cet article, le Digital Omnibus sur l’IA, entré en vigueur le 27 juillet 2026, n’a prévu qu’un sursis, limité au marquage (article 50, paragraphe 2), selon la fiche de synthèse de la Commission européenne sur les règles de transparence (29 juillet 2026) : les fournisseurs dont le système a été mis sur le marché avant le 2 août 2026 ont jusqu’au 2 décembre 2026 pour s’y conformer (FAQ de la Commission du 24 juillet 2026).

Pour repérer les systèmes concernés, un inventaire qui indique quel système tourne avec quel modèle est un moyen pratique, et la couche d’abstraction le tient à jour sans effort supplémentaire. Selon Deloitte (State of AI in the Enterprise, édition 2026), 21 % seulement des entreprises disposent d’une gouvernance mature de leurs agents.

Faut-il devenir multi-fournisseur pour autant ?

Non. Le multi-fournisseur est un moyen, parfois utile, souvent coûteux en compétences et en outillage : chaque fournisseur ajouté réclame sa grille d’évaluation, ses prompts, sa supervision et sa revue de sécurité. Assumer un modèle de référence reste une décision d’architecture défendable, avec une seule grille d’évaluation à maintenir et une seule courbe d’apprentissage à financer.

Koneetiv travaille exclusivement sur Claude, et les bascules décrites plus haut, d’Opus 4.8 vers Opus 5 ou de Sonnet 4.5 vers Sonnet 5, se jouent toutes dans une même gamme. Chez nous, choisir Claude comme socle va de pair avec une configuration versionnée, où l’identifiant du modèle n’apparaît qu’à un seul endroit. La configuration versionnée vous laisse rouvrir la décision au moment que vous choisissez.

Le risque d’une abstraction qui nivelle par le bas

Une abstraction mal conçue comporte son propre risque : elle nivelle par le bas. Si votre couche n’expose que les fonctions communes à tous les fournisseurs, vous perdez ce qui vous a fait choisir ce modèle, comme le traitement de contextes longs ou les appels d’outils structurés. Une couche utile expose les capacités avancées et documente celles qui ne sont pas portables.

Quelles erreurs rendent une migration de modèle coûteuse ?

Évaluer sur des démonstrations, comparer des tarifs au lieu des consommations et basculer tout le trafic d’un coup renchérissent une migration.

Évaluer sur des cas de démonstration

Un modèle candidat testé sur les exemples qui ont servi à vendre le projet passera l’épreuve. Le jeu d’évaluation doit rejouer des cas réels de production, anonymisés, avec leurs cas limites et les erreurs déjà corrigées, et fixer avant l’essai le seuil de qualité qui autorise la bascule. Sans ce seuil écrit, la décision se prend à l’impression.

Comparer des tarifs au lieu de comparer des consommations

Le tarif au million de tokens ne donne pas le coût d’un cas d’usage. Deux modèles au même tarif peuvent consommer des volumes très différents pour la même tâche, selon la longueur des réponses, le recours au raisonnement étendu et le découpage du texte, puisque les modèles Claude 4.7 et suivants utilisent un nouveau tokenizer qui produit davantage de tokens pour un même texte, d’après la documentation d’Anthropic. Seule une mesure sur vos propres cas dit si la bascule coûte plus ou moins cher.

Basculer tout le trafic d’un coup

Une bascule sûre procède par étapes : le modèle candidat tourne d’abord en mode shadow, sur le trafic réel, sans que ses réponses soient utilisées, puis reçoit une fraction du trafic, puis la totalité si les indicateurs tiennent. Le retour arrière doit rester possible à chaque étape, ce qui suppose que l’ancienne version soit encore disponible, et une migration lancée après l’annonce d’un retrait se fait sous contrainte de calendrier.

Par où commencer ?

Par un relevé, un exercice court quand on sait où chercher. Listez les applications IA en production, le modèle utilisé par chacune et la date de la dernière révision de ce choix. Côté API Claude, l’export d’usage de la console, ventilé par clé et par modèle, fournit une première liste des identifiants encore appelés (documentation Claude, consultée le 16 septembre 2026). Le relevé peut faire apparaître des cas d’usage oubliés, ou des applications qui tournent sur une version que l’équipe ne choisirait plus aujourd’hui.

Sortir l’identifiant du modèle de l’application la plus critique

Ensuite, sortez l’identifiant du modèle du code sur l’application la plus critique, une seule, et construisez le jeu d’évaluation qui vous dira si un candidat fait aussi bien sur vos données. S&P Global relevait en 2025 que 46 % des preuves de concept d’IA étaient abandonnées avant la production. Passer ce cap suppose, à notre sens, de traiter l’IA comme un composant d’architecture, soumis aux mêmes exigences de réversibilité que le reste du système d’information, et d’arbitrer l’architecture de vos agents IA sur des critères écrits.

Pour situer votre organisation, le diagnostic de maturité IA mesure en trois minutes six axes, dont le socle technique et la gouvernance, selon le référentiel Koneetiv (édition 2026).

La page consacrée aux agents IA en entreprise détaille les briques techniques d’un agent et sa gouvernance en production.

Pour industrialiser vos agents, notre programme de déploiement et d’exploitation d’agents Claude va de l’audit technique à l’agent en exploitation.

Les autres analyses de la rubrique agents IA en production prolongent ces questions d’architecture.