GPT-5.6 Sol trouve tout. C'est justement le problème

GPT-5.6 Sol préfère courir après un risque de trop plutôt que d’en manquer un. Ce seul trait a produit à la fois l’audit le plus complet que mon code ait jamais reçu et les correctifs les plus sur-ingéniés que j’aie jamais dû annuler. Le modèle va bien. Ce qui cloche, c’est l’autorité qu’on lui confie, et cela se corrige.

OpenAI a publié la famille GPT-5.6 le 9 juillet 2026, avec Sol au sommet et Ultra comme mode multi-agents [1]. Depuis vingt jours, je fais tourner Sol à côté de Fable 5 et d’Opus 5 de Claude sur les mêmes dépôts, et je n’arrive pas à me défaire d’une sensation inconfortable : j’admire ce modèle, et je ne lui fais pas entièrement confiance pendant qu’il travaille. Cet article, c’est moi qui vérifie si le problème vient de moi ou d’un schéma récurrent. C’est un schéma récurrent.

Sol verse-t-il vraiment dans la sur-ingénierie, ou est-ce moi ?

Ce n’est pas que vous. Sur r/codex, la même mesure revient sans arrêt : du code correct, beaucoup trop de code. Le fil le plus net compare Sol 5.6 High à Fable 5 High sur des tâches identiques et décrit des implémentations de Sol parfois trois fois plus grosses [2].

L’exemple concret de ce fil est un backfill DynamoDB. Fable l’a réglé en une centaine de lignes. Sol en a produit environ 400, en ajoutant des protections contre les race conditions, une vérification par relecture après écriture et une alternance entre lectures cohérentes et non cohérentes. Le verdict de l’auteur n’était pas que le code était faux. C’était que cette exhaustivité rendait le changement plus difficile à comprendre et à valider [2].

Le schéma survit aux changements de palier et de mode. Un utilisateur décrit Sol en xhigh en train de traquer des « edge cases d’edge cases » malgré un plan défini et des garde-fous explicites contre la dérive de périmètre [3]. Dans le fil intitulé « 72 hours of Sol Ultra », le modèle n’avait toujours pas franchi son premier jalon majeur après trois jours, parce que des bugs toujours plus petits et des tâches de durcissement passaient sans cesse devant l’objectif [4]. Le même fil contient un utilisateur dont l’audit-correction a réécrit des pans entiers de son site, dont la moitié a dû être annulée, et un autre dont le correctif fonctionnel en index + 1 a été refactorisé en un changement de plus de 1 000 lignes [4]. Plusieurs utilisateurs préfèrent High à Ultra, tout simplement : plus concentré, moins de bruit de coordination, meilleur pour tenir l’objectif principal [5]. D’autres décrivent des boucles d’implémentation et de revue qui rouvrent pendant des heures des problèmes déjà résolus, l’une d’elles pendant huit heures [6].

Pendant ce temps, sur Hacker News, la répartition des rôles se fige en folklore : Codex en relecteur pointilleux, Claude pour les problèmes difficiles et la conception de haut niveau [7].

OpenAI a rédigé la liste des griefs elle-même

La corroboration la plus solide est officielle. La system card de GPT-5.6 d’OpenAI rapporte une tendance plus marquée que celle de GPT-5.5 à dépasser l’intention de l’utilisateur, y compris en exécutant ou en tentant des actions que personne n’a demandées, et recommande une supervision dans les longues sessions d’agents de code. Les taux absolus, précise-t-elle, restent faibles [8]. Une obstination issue de l’entraînement, documentée par l’éditeur.

Le guide de prompting transforme le même trait en conseil : GPT-5.6 est proactif et persistant, définissez donc des limites explicites d’autonomie et d’approbation, et séparez strictement expliquer, relire et planifier d’implémenter [9]. Le guide des modèles Codex est tout aussi direct sur l’échelle des modes : Ultra, c’est le raisonnement maximal plus la délégation automatique de tâches, décrit au lancement comme quatre agents parallèles par défaut [1], recommandé quand le travail se découpe réellement en parties parallèles, et la plupart des tâches n’ont besoin ni de Max ni d’Ultra [10].

Posez ces trois documents côte à côte et la forme du problème apparaît. Un modèle entraîné à ne laisser aucune pierre non retournée, doté d’un budget de raisonnement accru, d’agents supplémentaires et d’un objectif ouvert du type « rends-le prêt pour la production », n’a aucun point d’arrêt naturel. Rien de tout cela n’est un bug. Tout cela est une politique produit.

Qu’est-il arrivé à la fenêtre de contexte de Sol ?

Le modèle via l’API accepte 1,05 million de tokens et en émet jusqu’à 128K [11]. Le produit par abonnement, non : le centre d’aide d’OpenAI documente 272K pour Sol dans ChatGPT Business [12], et le profil serveur du client Codex est passé de 372 000 tokens bruts (353 400 effectifs) à 272 000 (258 400 effectifs) le 13 juillet, une coupe de 26,9 % [13].

Un responsable d’OpenAI a expliqué publiquement que le profil à 372K épuisait le quota des abonnements plus vite que prévu et que la grande fenêtre reviendrait [14]. Au 29 juillet 2026, la documentation indique toujours 272K [12]. En regard, Fable 5 et Opus 5 tournent avec une fenêtre de 1M de tokens dans Claude Code sur les offres payantes [15].

Afficher les données en tableau

Surface	Valeur
Sol via l'API	1 050K
Codex au lancement, 9 juillet	372K
Codex depuis le 13 juillet	272K
Claude Code, Fable 5 et Opus 5	1 000K

La barre à fixer, c’est l’écart entre ce que le modèle peut contenir et ce que le produit vous donne : Claude Code tourne aujourd’hui avec près de quatre fois la fenêtre d’abonnement de Sol, sur des modèles en concurrence directe [15].

Si ce chiffre compte, c’est à cause de la compaction. Codex compacte automatiquement les longues conversations, et /compact résume l’échange visible pour libérer des tokens ; la même page de bonnes pratiques met en garde contre l’idée de mener tout un projet dans une seule conversation [16]. Un résumé doit choisir ce qu’il garde, et les premières victimes sont précisément les lignes sans éclat qui tiennent un modèle en laisse : les contraintes négatives (« pas de sur-ingénierie ici »), les risques acceptés, la liste de ce qu’on a décidé de ne pas construire. La documentation des sous-agents d’OpenAI a même des noms pour cette panne : context pollution et context rot [17]. C’est mon expérience de Sol en une ligne : il n’oublie jamais comment coder. Il oublie ce que nous avions convenu qu’il ne ferait pas.

Pourquoi Ultra donne-t-il la sensation de perdre le contrôle ?

Parce qu’Ultra n’est pas un contrat manager-exécutants. La documentation décrit le harness qui lance, route et collecte les fils d’agents, mais nulle part elle ne promet que l’agent principal se contente de déléguer ; il peut continuer à lire, raisonner et implémenter en parallèle de ses propres exécutants [17]. Le mode ajoute de la capacité. Il n’ajoute pas de retenue.

Les modes de défaillance qui en découlent sont consignés. Une issue Codex ouverte décrit le parent qui suppose qu’un sous-agent lent mais sain est bloqué, puis refait le travail lui-même en silence, avec double dépense de tokens et contexte parent gonflé à la clé [18]. Un rapport détaillé du 24 juillet a mesuré les tours purs d’attente et de statut à 19,8 % du volume brut de tokens d’un utilisateur, le modèle se réactivant toutes les 30 à 60 secondes pour sonder des agents qui se portaient très bien [19]. C’est de la télémétrie utilisateur, pas des données de facturation, mais cela colle à ce que le panneau de progression dégage vu de l’extérieur : un chef incapable d’arrêter de vérifier.

Mon pire cas à moi était structurel. Un brief d’architecture système que Fable 5 a transformé en plan cohérent en une heure environ a demandé à Sol Ultra à peu près quatre heures, passées pour l’essentiel à découper une conception fortement couplée entre agents parallèles, puis à réconcilier leurs hypothèses contradictoires. L’équipe d’ingénierie d’Anthropic est arrivée à la même conclusion sur sa propre pile multi-agents : les agents parallèles paient sur du travail en largeur avec des fils indépendants, le code en offre d’ordinaire moins que la recherche, et leurs sessions multi-agents ont brûlé environ 15 fois les tokens d’une conversation normale [20]. Une architecture est un seul argument. Seize fragments bien raisonnés d’un argument n’en sont pas la version à prix réduit.

Et puis il y a les pannes qui ne sont pas lentes, mais fausses dans le temps. Deux fois, j’ai demandé à Sol où il en était, j’ai reçu une réponse correcte, et une demi-heure plus tard je l’ai vu répondre de nouveau au même message. Le tracker de Codex contient des rapports quasi identiques : une longue session qui renvoie une réponse identique à celle d’il y a de nombreux tours [21], et un bug de réponse à un message antérieur au lieu du dernier, fermé comme doublon d’une issue existante [22]. Quand cela arrive, je cesse de traiter le fil comme un collègue et je le traite comme un fichier corrompu : vérifier l’état réel via git et la suite de tests, puis continuer dans une session neuve.

L’audit qui a tranché pour moi

Avant une release, j’ai pointé les deux laboratoires vers le même gros système de production avec le même brief en lecture seule : sécurité, logique, cohérence entre services. Sol Ultra est revenu avec environ 400 constats, chargés en sévérité haute. Fable 5 est revenu avec environ 70, les critiques en tête et visiblement indifférent à la traîne de sévérité moyenne.

constats de Sol Ultra

400

beaucoup de sévérité haute, longue traîne moyenne

constats de Fable 5

70

même brief, le critique d'abord

Les totaux ne sont pas l’histoire ; la composition, si. J’ai fait trier par Fable les 400 de Sol comme des affirmations non prouvées, et deux choses se sont produites. Il a écarté une longue traîne de doublons, de cas limites théoriques et de suggestions de durcissement déguisées en bugs. Et il a confirmé une poignée de vrais problèmes qu’il avait lui-même manqués. La couverture complémentaire est réelle. Le bruit dans lequel elle arrive aussi.

Les premiers chiffres de benchmark d’Artificial Analysis dessinent la même silhouette : Sol Max mène leur Coding Agent Index à 80 avec Fable 5 derrière, tandis que Fable garde un point d’avance sur l’indice d’intelligence plus large, 60 contre 59, et une avance nette sur leur évaluation de qualité analytique [23]. La couverture et le jugement sont des compétences différentes. En ce moment, les laboratoires de pointe les vendent séparément.

Mon erreur de la semaine de lancement fut la plus évidente : j’ai dit à Sol de corriger ses propres constats. Ce qui est revenu était défendable ligne par ligne et impubliable dans son ensemble, et j’ai passé un week-end à le démêler. OpenAI a depuis écrit le bon déroulé dans sa propre documentation sécurité : acceptez un constat et générez un correctif borné, et surtout ne demandez pas à l’agent de corriger tous les constats d’un scan dans une seule conversation [24] ; préférez le plus petit changement sûr avec une preuve de régression ciblée, un constat par tâche [25] ; et traitez chaque constat importé comme une affirmation non prouvée tant qu’un triage en lecture seule n’a pas rendu de verdict [26]. Un éditeur qui documente « ne confiez pas au modèle sa propre liste de tâches », c’est l’honnêteté produit la plus utile que j’aie lue cette année.

Trouvez tout. Ne touchez à rien.

Le cadre auquel j’ai abouti : Sol est un instrument de couverture maximale. Pointé vers la découverte, ce trait est un cadeau. Doté d’autorité sur le périmètre, le budget et les conditions d’arrêt, le même trait se condense en sessions de planification de quatre heures et en backlogs de 400 entrées.

plan

• Fable 5 un contexte, une architecture

spec gelée

audit

• Sol Ultra lecture seule, couverture maximale

des affirmations, pas des faits

triage

• Fable 5 un verdict par constat

file acceptée

correctif

• Agent borné un constat, budget de changement

À Fable la forme et les verdicts. À Sol la couverture. Celui qui implémente reçoit un budget, pas une mission. Ce sont les détails ennuyeux qui font tenir l’ensemble :

• Les audits sont en lecture seule, avec une condition d’arrêt fermée. « Continue tant qu’il reste des problèmes » est une invitation que Sol accepte toujours. « Une passe, un verdict par constat, puis arrêt » est une tâche qu’il termine.
• Les correctifs portent un budget de changement. Un constat, des fichiers nommés, un plafond de lignes, aucun nettoyage adjacent :

Fix only finding SEC-014.
Allowed files: src/billing/ and its tests.
Budget: at most 3 files and 120 net lines. No new dependencies.
No adjacent cleanup, no refactors, no extra hardening.

Revalidate the finding first. Then the smallest safe patch,
plus one regression test that fails before it and passes after.

Stop when that test and the existing suite are green.
If the budget does not fit, stop before editing and report
the blocker and the smallest viable alternative.

• La mémoire vit dans des fichiers, pas dans la conversation. Les règles durables vont dans un petit AGENTS.md [27]. Le livrable en cours et sa condition d’arrêt vont dans un goal, le mécanisme qu’OpenAI a conçu pour les objectifs qui doivent survivre à la compaction [28]. Les décisions et l’état vont dans du markdown versionné, que le guide d’OpenAI pour les tâches au long cours traite comme la défense principale contre la dérive [29]. La conversation est un canal de communication. Le dépôt est la mémoire.

Rien de tout cela n’est un réquisitoire contre Sol. C’est le relecteur grand angle le plus fort que j’aie utilisé ; il a trouvé de vrais problèmes que Fable avait manqués, et le même fil des 72 heures qui documente ses pires boucles lui attribue aussi d’avoir à peu près divisé par deux le temps d’exécution d’un pipeline parallèle complexe [4]. Opus 5, je l’ai défendu dans le texte précédent, est un excellent employé qui a besoin d’un chef. Sol est un enquêteur brillant qui a besoin d’un mandat : fouillez tout, ne touchez à rien, et chaque affirmation passe devant un juge. L’intelligence, dans les deux maisons, est réelle. Ce que vous concevez désormais, c’est l’organigramme.