J'ai cru qu'on m'inventait un modèle. C'est moi qui n'avais pas suivi.

L'erreur

Je préparais une revue de l'actualité IA du mois. Les moteurs de recherche m'ont renvoyé une série de billets d'agrégateurs listant les sorties de modèles d'août et septembre 2026. Une phrase citait, dans la même énumération, une demi-douzaine de noms.

J'en ai reconnu certains. D'autres non. Et comme j'ai pour habitude de me méfier de ces pages — elles confondent régulièrement deux annonces proches, elles arrondissent les numéros de version, elles recopient les erreurs les unes des autres — j'ai écrit noir sur blanc que ces noms-là étaient probablement fabriqués.

Puis je suis allé vérifier, comme il se doit, dans les documentations des fournisseurs eux-mêmes.

Ils existaient tous. Pas approximativement : exactement. Les identifiants figuraient dans les pages de référence officielles, avec leurs dates de mise en disponibilité générale. L'agrégateur que je soupçonnais avait raison, et le soupçon venait de moi — plus précisément, de l'idée que je me faisais du catalogue, qui datait de quelques semaines et que je croyais à jour.

J'ai corrigé. Mais l'épisode m'a laissé une question plus intéressante que ma bévue : comment en suis-je arrivé à trouver plus vraisemblable qu'on invente un modèle plutôt qu'il en soit sorti un de plus ?

Les faits

Trente-trois jours, chez un seul fournisseur

Voici ce que donne le journal des modifications public de l'interface Gemini de Google, entre le 13 août et le 15 septembre 2026. Je le recopie sans commentaire, parce qu'il se suffit.

Et ce n'est qu'un fournisseur. Sur la même période, la page de référence d'OpenAI liste en modèles phares gpt-6-astra, gpt-5.6-sol — avec gpt-5.6 comme alias —, gpt-5.6-terra et gpt-5.6-luna, auxquels s'ajoutent des déclinaisons spécialisées : gpt-5.6-cyber, deux modèles d'image, des modèles temps réel, un modèle de transcription. Chez Anthropic, les annonces s'égrènent au même rythme : Claude Opus 5 le 24 juillet, un billet sur les garde-fous de Fable 5 le 7 août, puis Claude Fable 5.1 et Claude Mythos 5.1 le 1^er septembre.

Je mets ma main au feu que cette liste sera fausse avant la fin de l'automne. C'est d'ailleurs la seule prédiction de ce texte dont je sois certain.

Ce que ça casse

Le numéro de version ne veut plus rien dire

Regardez à nouveau le relevé. Un modèle 3.5 sort treize jours après un modèle 3.7. Un modèle nommé omni-1.1 cohabite avec des modèles nommés 3.8. Des capacités nouvelles sont ajoutées le 1^er septembre à trois générations différentes en même temps, dont deux que le 3.8 du lendemain est censé remplacer.

Ce n'est pas du désordre. C'est parfaitement rationnel du point de vue du fournisseur : ces noms ne décrivent pas une progression, ils décrivent une gamme. Le chiffre indique une famille d'architecture, le suffixe indique la spécialité et le format, et les deux évoluent sur des calendriers indépendants. C'est un catalogue, pas une échelle.

Sauf que nous, en face, nous continuons de les lire comme une échelle. Trente ans d'habitudes logicielles nous ont appris qu'un numéro plus grand signifie « plus récent, et généralement meilleur ». C'est ce raisonnement qui me faisait croire que je connaissais le catalogue : je pensais en avoir vu le haut, alors qu'il n'y a plus de haut, seulement une surface qui s'étend dans plusieurs directions à la fois.

La conséquence pratique est désagréable. La question « quel est le meilleur modèle ? » n'a plus de réponse par défaut, non pas parce que ce serait subtil, mais parce qu'elle est mal formée. Meilleur pour du raisonnement long, du code, de la transcription, du temps réel, de l'image, du coût par million de jetons ? Ce sont aujourd'hui des modèles différents, chez le même fournisseur, avec des cycles de vie différents.

Et les comparatifs suivent encore moins bien que moi

C'est ici que je dois nuancer ma méfiance initiale envers les agrégateurs — et lui rendre en partie raison, sur un autre terrain que celui où je l'avais placée.

Ils n'inventent pas les modèles, je m'étais trompé. Mais ils publient des classements dont la date de mesure n'est presque jamais visible, et qui portent sur un catalogue qui a changé entre la mesure et la lecture. Un tableau comparatif publié le 1^er septembre décrivait un monde où gemini-3.8-flash n'existait pas encore. Il n'est pas faux ; il est daté, et sa date ne se voit pas.

Le problème n'est donc pas la véracité de ces pages. C'est que la durée de validité d'une information est devenue plus courte que le temps qu'il faut pour la trouver, la lire et la transmettre. J'ai été piégé par cette mécanique alors même que je m'en méfiais. J'ai simplement été piégé dans l'autre sens.

Le détail technique qui coince

L'alias qui bouge sous vos pieds

Un détail du catalogue d'OpenAI mérite qu'on s'y arrête, parce qu'il illustre le problème mieux que n'importe quel raisonnement général : gpt-5.6 n'est pas un modèle. C'est un alias, et il pointe aujourd'hui vers gpt-5.6-sol.

C'est une commodité évidente, et tout le monde l'utilise : on écrit le nom court dans son code, on reçoit automatiquement la version que le fournisseur considère comme la bonne, on ne s'occupe de rien. Sauf que « la version que le fournisseur considère comme la bonne » est une valeur qui change sans que votre code change.

Ce n'est pas propre à l'IA. C'est exactement le débat qu'on connaît depuis toujours sur les dépendances logicielles : épingler une version exacte et vieillir en sécurité, ou suivre une étiquette mouvante et recevoir les améliorations — avec les surprises. La différence, c'est le rythme et la nature du changement.

Il y a là un arbitrage, et je ne connais pas de bonne réponse universelle. Épingler un identifiant complet donne de la stabilité et fait rater les améliorations, parfois substantielles. Suivre l'alias donne les améliorations et fait porter à vos utilisateurs le coût des ajustements. Le seul choix clairement mauvais est de ne pas savoir lequel des deux on a fait — et c'est le cas le plus fréquent, parce que l'alias est ce qu'on copie-colle depuis la documentation le premier jour.

Ce qu'un numéro de version garantissait, et ne garantit plus

Le logiciel s'était doté d'une convention utile : un numéro en trois parties où le premier chiffre annonce une rupture, le deuxième un ajout compatible, le troisième une correction. Ce n'est pas une loi, beaucoup de projets la respectent mal, mais l'intention était partagée : le numéro devait dire quelque chose du risque de mise à jour.

Les numéros de modèles ne portent pas cette promesse, et n'ont jamais prétendu le faire. Passer de 3.7 Flash à 3.8 Flash ne vous dit ni si c'est compatible, ni si c'est mieux pour votre tâche, ni si le prix change. Ce sont des noms de gamme — Flash, Live, Omni, Lite — ordonnés par un chiffre qui indique surtout à quelle vague de développement le modèle appartient.

Je ne le reproche pas aux fournisseurs. Je constate qu'un réflexe vieux de trente ans continue de s'appliquer à des objets qui ne le portent pas, et que cela produit des erreurs de lecture — la mienne en ouverture de ce texte en est une.

L'objection

« Et alors ? Prenez le dernier et n'y pensez plus »

C'est la réponse qu'on m'oppose, et elle n'est pas absurde. Si le catalogue bouge trop vite pour être suivi, autant ne pas le suivre : on prend le modèle le plus récent du fournisseur avec lequel on a déjà un contrat, et on passe à autre chose.

Pour beaucoup d'usages, c'est effectivement la bonne réponse, et je la donne souvent. Mais elle a deux angles morts qu'il faut nommer.

Le premier est le coût. « Le dernier » est presque toujours le plus cher, et l'écart n'est pas marginal. Sur un usage à gros volume — de la classification, de l'extraction, du résumé en série — la différence entre le modèle phare et un modèle spécialisé de la même maison peut changer l'ordre de grandeur de la facture, pour une qualité que personne ne distingue sur la tâche concernée. C'est le même raisonnement que celui qui fait qu'un petit modèle bien alimenté bat souvent un gros modèle mal informé.

Le second est la stabilité. « Prendre le dernier » implique de changer de modèle tous les deux mois. Si le modèle est un composant remplaçable de votre système, très bien. S'il est devenu la fondation — si vos invites ont été ajustées à ses manies, si vos tests de recette encodent ses sorties, si vos utilisateurs ont appris à lui parler — alors changer n'est plus une mise à jour, c'est un chantier. Et vous le referez en novembre.

Et si ça se calmait ?

L'objection sérieuse à tout ce qui précède est une objection de calendrier : cette agitation est peut-être un phénomène de jeunesse. Les secteurs techniques connaissent en général une phase de prolifération suivie d'une consolidation — beaucoup d'acteurs, beaucoup de références, puis quelques standards qui s'imposent et un catalogue qui se stabilise. Si c'est ce qui nous attend, il serait absurde de refondre son architecture pour un désordre transitoire.

C'est possible. Je n'en sais rien, et personne n'en sait rien — les gens qui prédisent le rythme des sorties de modèles se trompent avec une régularité qui devrait les rendre plus prudents. Ce que j'observe est plus modeste : depuis deux ans, chaque trimestre où l'on a annoncé la stabilisation a été suivi d'un trimestre plus dense que le précédent.

Et l'argument se retourne assez bien. Si la consolidation arrive, une architecture où le modèle est remplaçable ne vous aura presque rien coûté — quelques jours de travail ennuyeux, un jeu de tests que vous auriez dû écrire de toute façon. Si elle n'arrive pas, elle vous aura évité de refaire le même chantier quatre fois par an. L'asymétrie penche nettement d'un côté.

À qui profite le rythme

Suivre a un coût, et il n'est pas réparti également

Voici la partie la plus discutable de ce texte, et c'est pour elle que j'ai mis un avertissement en tête.

Réévaluer un catalogue tous les deux mois suppose quelqu'un dont c'est le travail. Une grande entreprise a cette personne, ou cette équipe : elle lit les journaux de modifications, elle maintient un banc d'essai interne, elle rejoue ses cas d'usage sur les nouvelles références et elle produit une recommandation. Le coût est réel mais il est absorbé, et il se dilue sur un volume d'usage considérable.

Une structure de dix, trente ou cent personnes n'a pas cette personne. Elle a quelqu'un qui fait déjà trois métiers et à qui l'on demande, en plus, de savoir si le modèle sorti mardi change quelque chose. Dans les faits, il se passe l'une de ces deux choses : soit on ne regarde plus du tout et on reste sur un choix vieux d'un an sans savoir ce qu'on a manqué, soit on suit l'actualité et on refait le débat à chaque annonce, ce qui consomme exactement l'attention qu'on aurait dû mettre sur le problème métier.

Aucune des deux ne me satisfait, et je ne prétends pas qu'il existe une troisième voie confortable. Je voudrais surtout qu'on cesse de présenter ce rythme comme une bonne nouvelle univoque. « Les modèles s'améliorent tous les mois » est vrai, et c'est effectivement une bonne nouvelle pour qui peut en profiter. Pour les autres, c'est une dette d'attention qui s'accumule, et le fait qu'elle ne figure sur aucune facture ne la rend pas moins réelle.

Je formule cela comme un souhait, pas comme un reproche documenté : je n'ai pas fait le tour des conditions de service de chaque fournisseur, et il est possible que certaines de ces garanties existent déjà, écrites quelque part où je ne suis pas allé lire. Si c'est le cas, je serai heureux qu'on me le signale — ce serait la deuxième fois dans ce texte que je me serai trompé par excès de certitude, et ce serait cohérent.

Ce que j'en retire

Traiter le modèle comme une pièce d'usure

Je n'ai pas de conclusion confortable. J'ai une conviction, formée par cette erreur autant que par les projets que je vois passer.

La conviction est celle-ci : tant que le catalogue bouge à ce rythme, la décision qui compte n'est pas le choix du modèle — c'est l'architecture qui permet d'en changer sans rien casser. Une couche d'abstraction ennuyeuse, un jeu d'exemples attendus qu'on rejoue à chaque changement, la capacité de faire tourner deux modèles en parallèle une semaine pour comparer sur ses propres cas. Rien de spectaculaire, rien qui se présente bien en réunion.

C'est exactement ce qu'on a fini par apprendre pour les bases de données, les fournisseurs de cloud et les bibliothèques tierces, à chaque fois de la même façon : en se faisant coincer une première fois. La différence, ici, c'est la vitesse. On ne se fait pas coincer tous les cinq ans, mais à chaque trimestre.

Et il y a une seconde leçon, plus personnelle, que je note pour moi autant que pour qui me lit. Ma méfiance envers les sources secondaires est un bon réflexe — elle m'a évité des erreurs réelles, encore récemment. Mais un réflexe qui n'est pas vérifié devient lui-même une source d'erreur. J'ai pris ma propre connaissance périmée pour un étalon, et j'ai déclaré faux ce qui ne correspondait pas. C'est précisément le mécanisme que je reproche aux pages que je critiquais.

La seule protection que je connaisse contre ça n'a pas changé, et elle est d'un ennui parfait : aller voir la documentation du fournisseur, avec sa date, avant d'affirmer quoi que ce soit. Y compris — surtout — quand on est certain de savoir.

Sources, relevées le 15 septembre 2026 : journal des modifications de l'interface Gemini pour l'intégralité des dates et identifiants du relevé d'août-septembre 2026 ; page de référence des modèles OpenAI pour les identifiants cités ; page d'actualités d'Anthropic pour les annonces du 24 juillet, du 7 août et du 1^er septembre 2026. Ces trois relevés sont datés du jour de publication et seront périmés — c'est le propos du texte, pas un défaut de l'article. Les noms de modèles sont donnés tels qu'ils figurent dans ces documentations, sans correction ni harmonisation de ma part. L'erreur racontée en ouverture est la mienne, elle a été commise le jour même et corrigée avant publication.