GPT-5.5 « Spud » : ce qui est vérifié sur la fiabilité en contexte long

Les rumeurs autour de GPT-5.5 « Spud » mélangent deux sujets : l’existence supposée d’un modèle public OpenAI portant ce nom, et l’idée qu’il aurait déjà prouvé une meilleure fiabilité en contexte long. Les éléments examinés ici soutiennent une conclusion plus prudente : les documents officiels OpenAI de ce corpus parlent de GPT-5.4, tandis que « Spud » apparaît surtout dans des publications sociales, vidéos et pages non officielles .

Pour les équipes produit, les développeurs et les responsables IA, la nuance est importante. Un surnom de modèle n’est pas un benchmark. Et une grande fenêtre de contexte — c’est-à-dire la quantité de texte qu’un modèle peut recevoir en entrée — ne prouve pas, à elle seule, que le modèle saura conserver les consignes dans un long flux de travail avec outils, fichiers et plusieurs sessions.

Le verdict

Affirmation	Statut	Ce que les sources permettent de dire
GPT-5.5 Spud est un modèle OpenAI officiellement documenté	Non vérifié	Le guide API, le changelog et les notes de version GPT examinés renvoient à « Latest: GPT-5.4 », pas à un modèle public GPT-5.5 Spud .
OpenAI a publié une date de sortie, une model card, une page API ou des tarifs pour GPT-5.5 Spud	Non trouvé dans les sources officielles examinées	Des pages non officielles évoquent un calendrier et des capacités possibles, mais les documents OpenAI de ce corpus documentent GPT-5.4 .

Pourquoi la piste « Spud » ne suffit pas

Le nom « Spud » circule bien en ligne. On le retrouve dans des publications Facebook, des fils Reddit, des posts sur X, des vidéos YouTube et des articles non officiels évoquant des fenêtres de lancement, du préentraînement, de la multimodalité ou de nouvelles capacités . Ces références montrent qu’une rumeur existe. Elles ne démontrent pas qu’OpenAI a lancé un modèle.

Pour établir la disponibilité d’un modèle, les preuves les plus solides seraient normalement une page API OpenAI, une entrée de changelog, une note de version, une annonce officielle, une system card ou un artefact de benchmark — précisément le type de sources primaires qui, dans ce corpus, identifient ou décrivent GPT-5.4 .

L’absence de documentation publique ne prouve pas qu’aucun nom de code interne n’existe. Elle signifie simplement que les affirmations publiques sur la date de sortie, l’accès API, le prix, la mémoire ou la fiabilité en contexte long de Spud restent non vérifiées dans les sources examinées.

Ce que les sources officielles disent vraiment

Les éléments OpenAI les plus solides portent sur GPT-5.4. Le guide API s’intitule « Using GPT-5.4 », et le changelog comme les notes de version GPT renvoient à « Latest: GPT-5.4 » .

Dans son annonce de GPT-5.4, OpenAI indique que le modèle intègre les capacités de codage de GPT-5.3-Codex et améliore le travail avec les outils, les environnements logiciels, les feuilles de calcul, les présentations et les documents . La même annonce affirme que GPT-5.4 atteint 83,0 % sur les comparaisons GDPval, contre 70,9 % pour GPT-5.2, sur un benchmark présenté comme testant la capacité d’agents à produire du travail de connaissance bien spécifié dans 44 métiers .

La preuve officielle la plus proche de la question de la fiabilité sur de longs workflows concerne GPT-5.4 Thinking, pas Spud. La system card de GPT-5.4 Thinking affirme que le modèle réussit nettement mieux que les modèles précédents sur des traces longues difficiles, notamment pour suivre et annuler des opérations tout en préservant le travail de l’utilisateur ; la page décrit CoT-Control comme une suite d’évaluation de plus de 13 000 tâches . C’est une affirmation sur GPT-5.4 Thinking, pas une preuve que GPT-5.5 Spud a été publié ou testé de façon comparable.

Le contexte long ne se résume pas à une grande mémoire

La fiabilité en contexte long ne consiste pas seulement à faire entrer beaucoup de texte dans une requête. Dans un usage réel, un modèle peut devoir conserver des contraintes placées très loin les unes des autres, maintenir un état au fil des tours ou des sessions, choisir le bon outil, corriger un travail antérieur sans casser le reste, et garder un livrable cohérent sur plusieurs fichiers ou documents.

La recherche récente traite encore ce sujet comme un problème d’évaluation ouvert. Des synthèses couvrent les techniques d’extension de contexte, la modélisation long contexte, les changements d’architecture, les approches de workflow et le context engineering, plutôt que de présenter le suivi d’instructions en contexte long comme un problème résolu . Une étude d’évaluation systématique compare aussi des techniques d’optimisation pour les modèles de langage en contexte long, y compris dans des cas où les modèles doivent traiter et retenir de grands volumes d’information .

La rétention des consignes est de plus en plus mesurée directement. LongAlign introduit LongBench-Chat pour évaluer le suivi d’instructions en contexte long . LifBench propose un Long-context Instruction Following Benchmark centré sur la performance et la stabilité du suivi d’instructions en contexte long . LocoBench vise les workflows complexes de génie logiciel et inclut la rétention de mémoire multi-session ainsi que des workflows de développement sur plusieurs sessions .

Comment tester la fiabilité sur de longs workflows

Les recommandations d’évaluation d’OpenAI invitent à construire des évaluations orientées production et mentionnent explicitement le choix d’outils ; OpenAI avertit qu’à mesure que l’on ajoute des outils et des tâches à une architecture d’agent unique, le modèle peut avoir plus de mal à suivre les consignes ou à sélectionner le bon outil . OpenAI publie aussi des conseils pour des tâches Codex à long horizon, ce qui montre que le travail étendu en plusieurs étapes est bien un cas d’usage produit, mais ce n’est pas un benchmark de Spud .

Une suite d’évaluation pratique devrait au minimum couvrir six comportements :

1. Survie des consignes à distance. Placer des exigences critiques au début, au milieu et à la fin d’un long contexte, puis vérifier si la sortie finale les respecte toutes. LongAlign et LifBench sont pertinents parce qu’ils se concentrent sur le suivi d’instructions en contexte long .
2. Rétention d’état multi-session. Simuler plusieurs sessions de travail avec décisions, contraintes et retours arrière, puis vérifier si le modèle reprend au bon état. Le cadrage de LocoBench sur la mémoire multi-session est directement utile .
3. Choix d’outils sous charge. Proposer plusieurs outils plausibles et vérifier que le modèle choisit le bon, avec les bons paramètres. OpenAI identifie le choix d’outils comme une cible d’évaluation et note que la complexité peut rendre le suivi des consignes et la sélection d’outils plus difficiles .
4. Annulation et réparation. Demander au modèle d’annuler une partie d’une longue tâche sans endommager le reste du travail utilisateur. Cela correspond de près au comportement sur longues traces qu’OpenAI rapporte pour GPT-5.4 Thinking .
5. Cohérence des livrables sur plusieurs fichiers ou documents. Pour du code, des feuilles de calcul, des présentations et des documents, vérifier si le modèle maintient les contraintes sur l’ensemble du livrable plutôt que d’optimiser seulement le dernier tour. Le positionnement officiel de GPT-5.4 inclut les outils, les environnements logiciels, les tableurs, les présentations et les documents, tandis que LocoBench se concentre sur des workflows complexes de génie logiciel .

Ce qui ferait changer le verdict

Le verdict devrait changer seulement avec des preuves primaires plus solides : une page API ou une page modèle OpenAI nommant GPT-5.5 ou Spud, une entrée de changelog ou de notes de version, une annonce OpenAI, une model card ou system card, ou des résultats d’évaluation reproductibles couvrant le suivi d’instructions, la mémoire multi-session, le choix d’outils, l’annulation d’opérations et la cohérence des livrables .

En attendant, la formulation la plus sûre reste limitée : GPT-5.5 Spud n’est pas publiquement vérifié dans les documents officiels OpenAI examinés ici, et sa fiabilité en contexte long n’est pas établie par les preuves disponibles. Le bon réflexe consiste à benchmarker les modèles réellement accessibles, et à traiter les surnoms non officiels comme des rumeurs tant qu’OpenAI n’a pas publié de documentation.