En bref
Choisir un modèle de langage pour un usage professionnel demande quatre informations : la taille de la fenêtre de contexte, le prix, la date à laquelle s’arrête la connaissance du modèle, et la durée pendant laquelle il restera servi. Les trois premières décident de ce que le modèle peut faire et de ce qu’il coûte. La quatrième décide de la durée de vie de ce que vous construisez autour.
Le 6 septembre 2026, ces quatre informations ont été cherchées le même jour, sur les pages modèles officielles d’Anthropic, d’OpenAI et de Google. Aucun des trois ne les publie toutes. L’écart entre le plus complet et le moins disert n’est pas un détail de rédaction technique : il change la nature du travail de cadrage, et il détermine ce qu’un architecte peut affirmer par lui-même plutôt que sur parole.
En clair : imaginez trois concessionnaires. Le premier affiche, sur la même fiche, la cylindrée, le prix, l’année du modèle, et l’engagement écrit que les pièces resteront disponibles jusqu’à telle date. Le deuxième affiche la cylindrée et le prix, mais pas l’année. Le troisième donne les noms des voitures et vous renvoie au vendeur pour le reste. Les trois vendent de bonnes voitures. Mais un seul vous permet de calculer, seul, combien de temps la vôtre roulera.
La méthode, pour que le relevé soit refaisable
Il n’y a pas de mystère méthodologique ici, et c’est voulu : la valeur de ce relevé tient à ce que n’importe qui puisse le refaire et constater la même chose, ou constater qu’il a changé.
Trois pages, consultées le 6 septembre 2026 :
- la page « Models overview » de la documentation Anthropic ;
- la page « Models » de la documentation développeur d’OpenAI ;
- la page « Models » de la documentation de l’API Gemini.
Pour chaque fournisseur, une seule question : cette page, celle vers laquelle la documentation renvoie en premier, publie-t-elle le champ ? Pas « l’information existe-t-elle quelque part sur le site » — elle finit souvent par exister, dans une note de version, un billet de blog ou une fiche par modèle. La question est celle du lecteur pressé qui compare : trouve-t-il le champ à l’endroit prévu pour comparer ?
Le relevé
| Information publiée sur la page modèles | Anthropic | OpenAI | |
|---|---|---|---|
| Liste des modèles courants | oui | oui | oui |
| Fenêtre de contexte | oui | oui | non |
| Limite de tokens en sortie | oui | oui | non |
| Prix entrée / sortie | oui | oui | non |
| Prix de lecture de cache | oui | partiel | non |
| Date de fin de connaissance | oui | non | non |
| Date de retrait au plus tôt | oui | non | non |
| Identifiants sur les plateformes tierces | oui | non | oui |
| Modèles hérités encore servis | oui | oui | oui |
Relevé du 6 septembre 2026. Un champ « non » signifie qu’il est absent de la page de comparaison, pas qu’il est introuvable ailleurs.
Ce que chaque champ permet de décider
La fenêtre de contexte est le champ le plus regardé, et le moins piégeux — à un détail près sur lequel nous revenons. Elle dit combien de matière tient dans une requête.
Le prix est trompeusement simple. Le prix affiché à l’entrée et à la sortie ne dit rien du poste qui domine réellement une facture d’agent conversationnel : la lecture de cache, c’est-à-dire ce que coûte la relecture du même contexte à chaque tour. Chez Anthropic, elle vaut 10 % du prix d’entrée sur la gamme, et 2,5 % sur le modèle de tête. Sur une conversation relue cinquante fois, cet écart pèse davantage que le prix affiché — au point d’inverser parfois le classement entre deux modèles.
La date de fin de connaissance dit ce que le modèle ignore. C’est une limite de capacité déguisée en note de bas de page. Chez Anthropic, elle s’étale sur seize mois à l’intérieur de la même gamme : juin 2026 pour le modèle de tête, février 2025 pour le plus économique. Deux modèles de la même marque, servis le même jour, n’ont pas la même idée de ce qu’est le présent. Un système qui bascule automatiquement de l’un à l’autre pour économiser bascule aussi, sans le dire, d’une année de connaissance à l’autre.
La date de retrait au plus tôt est le champ le plus rare et le plus structurant. Elle ne dit rien de la performance : elle dit combien de temps l’intégration que vous écrivez aujourd’hui fonctionnera sans être reprise. C’est la seule des quatre informations qui parle de votre calendrier plutôt que de celui du modèle. Un seul des trois fournisseurs la publie.
En clair : les trois premiers champs répondent à « est-ce que ça marchera ? ». Le quatrième répond à « pendant combien de temps ? ». C’est la question qu’on oublie de poser au moment du choix, et la seule à laquelle on ne peut pas répondre après coup.
Trois pièges que la lecture d’une fiche ne signale pas
Le nom n’ordonne plus la capacité
La convention implicite du marché — un tier haut de gamme, un tier intermédiaire, un tier économique, ordonnés par le nom — a cessé d’être fiable en 2026, et chez deux fournisseurs simultanément.
Chez Anthropic, le modèle le plus capable n’est plus celui de la lignée Opus : un nom nouveau lui est passé devant, et la documentation recommande explicitement de commencer par Opus et de ne monter que si la mesure le justifie. Chez Google, le modèle présenté comme le plus avancé est un Flash, en version stable, tandis que le tier Pro en est à une version numériquement inférieure, en préversion. Un lecteur qui applique « Pro > Flash » choisit le mauvais modèle.
Chez OpenAI, le mouvement est inverse mais aussi déroutant : le modèle unique à routeur automatique de 2025, vendu sur l’argument qu’on n’aurait plus à choisir, a été remplacé par trois variantes nommées entre lesquelles il faut de nouveau choisir — séparées par un facteur seize sur le prix de sortie, à fenêtre de contexte identique.
Le phénomène déborde d’ailleurs les trois fournisseurs relevés ici. Chez Mistral, le modèle documenté comme le plus capable s’appelle Medium, pas Large — et il est le seul des trois principaux à être commercial, quand les modèles nommés Large et Small sont ouverts sous Apache 2.0. « Le plus ouvert » et « le plus capable » n’y désignent plus le même modèle, ce qu’aucun des deux noms ne laisse deviner.
Le même nombre de tokens ne contient plus le même texte
Un changement de tokeniseur ne se voit sur aucune fiche produit, parce qu’aucun champ ne le porte. Il change pourtant la valeur de tous les autres.
Chez Anthropic, le tokeniseur introduit courant 2026 fait tenir environ 555 000 mots dans un million de tokens, là où les modèles antérieurs en tenaient environ 750 000. La fenêtre annoncée n’a pas bougé ; sa contenance réelle a baissé de près d’un quart. Un budget de contexte calibré avant le changement, et jamais recalculé, déborde en silence.
L’absence d’un champ n’est pas l’absence de la donnée
Un fournisseur qui ne publie pas la fenêtre de contexte sur sa page de comparaison n’a pas de modèles sans fenêtre de contexte. L’information existe — dans une fiche par modèle, une note de version, un article de blog. Ce qui change, c’est le coût de vérification : là où un tableau permet une décision en cinq minutes, l’absence impose une collecte, page par page, qu’il faudra refaire à chaque révision de gamme, et dont personne ne garantit qu’elle soit à jour.
C’est en cela que la différence est réelle et pas rhétorique. Le fournisseur le plus disert n’est pas nécessairement le plus performant. Il est le plus vérifiable — et sur une décision d’architecture qu’on devra défendre dans six mois, la vérifiabilité est une propriété du fournisseur au même titre que la latence.
Ce que ça change concrètement pour une décision d’architecture
Épingler l’identifiant, jamais le tier. Écrire « le modèle haut de gamme du fournisseur » dans une spécification, c’est écrire une cible mobile. Les deux exemples de 2026 le montrent : un identifiant écrit en dur est une date de péremption déguisée, mais un tier écrit en clair est pire — il change de sens sans prévenir.
Dater son relevé, et le réintroduire dans la documentation. Une comparaison de modèles n’est vraie qu’à une date. Le présent article porte la sienne dans son titre de section et dans ses sources ; une note d’architecture interne devrait faire de même. Sans date, un tableau comparatif devient une source d’erreur au bout d’un trimestre.
Mesurer ce qui n’est pas publié plutôt que de l’estimer. Quand la fin de connaissance n’est pas donnée, une poignée de questions sur des faits datés la borne mieux qu’une supposition. Quand la contenance réelle de la fenêtre est incertaine, un texte de longueur connue la mesure en une requête. Ces vérifications prennent quelques minutes et remplacent une croyance par un chiffre.
Demander par écrit ce qui manque. La date de retrait est une information contractuelle avant d’être technique. Qu’un seul fournisseur la publie spontanément ne signifie pas que les autres refusent de s’engager — cela signifie qu’il faut le leur demander, et que la réponse a sa place dans le dossier de décision.
Que faire selon ce qui manque
| Contexte | Recommandation | Pourquoi |
|---|---|---|
| La date de retrait n’est pas publiée | La demander par écrit avant l’engagement, et consigner la réponse au dossier | C’est la seule information qui borne la durée de vie de votre intégration. Elle est contractuelle avant d’être technique : l’absence de publication n’est pas un refus de s’engager. |
| La fin de connaissance n’est pas publiée | La borner par la mesure : quelques questions sur des faits datés | Quelques minutes remplacent une supposition par un intervalle. À refaire à chaque changement de modèle, y compris un changement de tier au sein du même fournisseur. |
| La fenêtre de contexte n’est pas sur la page de comparaison | Aller la chercher par modèle, et dater le relevé | L’information existe ailleurs. Ce qui coûte, c’est de la recollecter à chaque révision de gamme — autant écrire la date à côté du chiffre. |
| Le tokeniseur a changé depuis votre calibrage | Remesurer la contenance réelle avec un texte de longueur connue | Une fenêtre annoncée identique peut avoir perdu près d’un quart de sa contenance. Aucun champ de fiche ne le signale. |
| Vous rédigez une spécification ou une note d’architecture | Épingler l’identifiant exact, jamais le nom du tier | Le tier a cessé d’ordonner la capacité en 2026 chez au moins trois fournisseurs. Un identifiant vieillit ; un tier change de sens sans prévenir, ce qui est pire. |
| Usage conversationnel avec contexte relu à chaque tour | Comparer sur le prix de lecture de cache, pas sur le prix affiché | Son tarif varie d’un facteur quatre à l’intérieur d’un même catalogue, et c’est lui qui domine la facture. |
Ce qu’il faut retenir
- Quatre informations décident d’une architecture : fenêtre de contexte, prix, fin de connaissance, durée de service. Aucun des trois grands fournisseurs ne publie les quatre sur sa page de comparaison, au 6 septembre 2026.
- La plus rare est aussi la plus structurante : la date de retrait au plus tôt est la seule qui parle de votre calendrier plutôt que de celui du modèle. Un seul fournisseur la donne.
- La fin de connaissance varie de seize mois à l’intérieur d’une même gamme. Basculer vers un modèle moins cher, c’est aussi basculer vers un modèle qui en sait moins — et rien dans le prix ne le signale.
- Le prix affiché n’est pas le prix payé : sur un usage conversationnel, c’est la lecture de cache qui domine, et son tarif varie d’un facteur quatre à l’intérieur d’un même catalogue.
- Le nom du tier a cessé d’ordonner la capacité en 2026, chez trois fournisseurs au moins — et chez l’un d’eux le modèle le plus capable est aussi le seul qui ne soit pas ouvert. Épingler un identifiant précis, et le dater.
- Un changement de tokeniseur peut réduire d’un quart la contenance réelle d’une fenêtre annoncée inchangée. Aucun champ de fiche produit ne le signale.