GPT-5 : ce qu'une génération majeure ne change pas

Une nouvelle génération de modèle remplace une couche d'un système qui en compte cinq, et les quatre autres restent exactement dans l'état où on les a laissées. C'est le rappel le plus utile à faire quand l'annonce tombe.

Un système en production repose sur un corpus, une chaîne de récupération, un prompt, un périmètre d'action et un modèle. L'annonce ne porte que sur le dernier élément.

Or, sur les systèmes que je reprends, la source des problèmes se trouve neuf fois sur dix dans les quatre autres couches. Un corpus contenant trois versions d'une procédure produira des réponses contradictoires quel que soit le modèle.

Attendre la génération suivante pour régler un problème de qualité revient à reporter indéfiniment un travail qui n'a rien à voir avec le modèle. J'ai vu cette attente durer deux ans.

Le raisonnement paraît sensé : les modèles progressent vite, donc autant attendre. Il échoue parce que les défauts qui gênent le plus en production, une réponse fondée sur un document périmé, une information introuvable, un refus mal calibré, ne relèvent pas de la capacité du modèle.

Le test qui tranche prend dix minutes. On prend cinq mauvaises réponses réelles et on vérifie, pour chacune, si l'information correcte figurait dans le contexte fourni. Si elle n'y était pas, aucune génération future ne corrigera quoi que ce soit.

Dans la quasi-totalité des cas que j'ai examinés, elle n'y était pas, ce qui renvoie au travail décrit dans le corpus est le projet.

Ajouter le modèle comme option, relancer le jeu de tests, comparer taux d'erreur et coût, décider : deux heures. C'est tout ce qu'une annonce doit déclencher.

Ce qui serait déraisonnable, c'est d'ouvrir un chantier. Une migration lancée sur la foi d'une annonce mobilise des semaines pour un gain qu'on aurait mesuré en une demi-journée.

La décision qui suit la mesure est en général l'une des trois suivantes. Basculer, si le taux d'erreur baisse à coût égal ou inférieur. Descendre de palier, si le nouveau modèle intermédiaire égale l'ancien supérieur. Ou ne rien faire, si le gain ne justifie pas la revérification des réglages.

Cette troisième option est parfaitement légitime et rarement retenue, alors qu'elle est souvent la bonne sur un système stable et bien réglé.

Une amélioration du modèle change le style des réponses, ce qui oblige à revérifier des réglages qui fonctionnaient. C'est le coût caché d'une bascule, et il est réel.

Un système en production a été ajusté : le prompt tient compte des tendances du modèle, les seuils sont calés sur son comportement, les cas limites ont été traités un par un. Un nouveau modèle défait une partie de ces ajustements, souvent en mieux, parfois en moins bien.

Le symptôme typique : les réponses deviennent plus longues, ou le modèle refuse moins souvent, ou il reformule au lieu de citer. Rien de tout cela n'est une régression au sens strict, et tout cela change l'expérience.

D'où l'intérêt du basculement par paliers avec surveillance du taux de correction humaine, décrit dans migrer un agent sans régression.

Le corpus, la récupération et le périmètre offrent un rendement bien supérieur à tout changement de modèle, et ils ne dépendent d'aucun fournisseur. C'est le message que je répète le plus souvent en mission.

Sur le corpus : désigner la version qui fait autorité, retirer les documents périmés, porter les dates dans les métadonnées. Quelques jours de travail, un effet immédiat sur la qualité perçue.

Sur la récupération : vérifier que les bons documents remontent, ajuster le découpage, filtrer les droits avant la recherche. Le test de dix questions réelles suffit à établir un diagnostic.

Sur le périmètre : écrire ce que le système ne fait pas, et ce qu'il répond quand il ne sait pas. Voir le refus de répondre est une fonctionnalité.

Ces trois chantiers ont une propriété que le changement de modèle n'a pas : leur bénéfice persiste à travers toutes les générations suivantes.