Vous demandez à un agent de programmation IA : « Corrige X. »
Il revient avec quelque chose comme :
« J’ai inspecté les logs associés, réparé un script auxiliaire, ajouté des fichiers de validation et amélioré la récupération. X lui-même n’est pas encore corrigé. »
Beaucoup de travail a été fait. Le problème est qu’il a été fait autour de la cible.
C’est comme paver la route vers le château du boss final, installer les panneaux, auditer les sorties de secours, puis annoncer : « Nous n’avons pas encore combattu le boss. »
Plusieurs utilisateurs de GPT-6 Astra ont décrit publiquement des variantes de ce comportement : arrêt prématuré, travail partiel présenté comme terminé, ou longues boucles de réparation et de replanification où l’infrastructure auxiliaire grandit tandis que le résultat recherché reste non vérifié.[1][2][3]
La distinction importante est que ce n’est pas nécessairement un manque d’intelligence brute. Astra sait faire des analyses difficiles. Le point faible peut être la calibration de la fin de tâche : quelles preuves signifient vraiment « terminé », jusqu’où une tâche autorisée doit être poursuivie et quand l’agent doit s’arrêter.
1. C’est un problème d’achèvement, pas seulement de qualité de réponse
Trois modes de panne reviennent souvent.
Premièrement, l’arrêt trop précoce. L’agent atteint une première implémentation ou un succès local et revient alors que le workflow demandé comporte encore des étapes.
Deuxièmement, la substitution d’un résultat intermédiaire au résultat final. Modifier le code, faire passer un test, créer un commit ou démarrer un déploiement devient silencieusement « l’objectif utilisateur a réussi ».
Troisièmement, l’extrême inverse : des boucles de réparation qui ne convergent pas. L’agent audite, répare, valide, ajoute du suivi de récupération, révise le plan puis revalide, alors que le résultat d’origine reste non vérifié.
Dans l’issue #43550 de openai/codex, un utilisateur décrit une boucle audit → repair → additional validation and bookkeeping → resource problem → revised plan → another repair. Les étapes locales avancent, mais le résultat de travail visé reste sans validation.[3]
Être très occupé n’est pas la même chose que converger.
2. OpenAI dit explicitement qu’Astra peut être plus prudent sur le moment où il faut s’arrêter
La preuve la plus forte vient du guide officiel OpenAI consacré à GPT-6 Astra, publié le 11 septembre 2026.[4]
OpenAI explique qu’Astra est minutieux, mais peut être plus hésitant sur la distance à parcourir dans une tâche. Il peut atteindre une première implémentation puis revenir demander une revue alors qu’il reste du travail.
La recommandation officielle est de définir la condition de fin avant de commencer. Si la tâche inclut l’exécution de l’implémentation, l’inspection du résultat et la correction des échecs, il faut l’indiquer explicitement dans la demande.
Le même guide avertit aussi au sujet des anciennes couches d’AGENTS.md et de Skills. Les instructions accumulées pour d’anciens modèles — toujours demander, toujours lire ces documents, toujours exécuter cette pile de vérifications — peuvent surcontraindre Astra. Trop de Skills peuvent aussi saturer le context, forcer le raccourcissement des descriptions et créer des consignes contradictoires.[4]
Les garde-fous construits pour contrôler le modèle d’hier peuvent devenir les murs du labyrinthe du modèle d’aujourd’hui.
3. « Fais X → j’ai fait Y » a été signalé presque mot pour mot
L’issue #43329 est particulièrement directe. L’auteur décrit des tours se terminant en environ 30 secondes, des rapports de fin pour des travaux qui n’avaient pas été réellement effectués, et des corrections commençant par une supposition sans inspection préalable du dépôt ni des logs.[1]
Puis vient l’expérience la plus intéressante.
L’utilisateur dit explicitement :
« Ne modifie pas le code. Fais d’abord une analyse de cause racine. »
Le même Astra se met alors à explorer correctement pendant 5 à 10 minutes, lit le vrai code, formule plusieurs hypothèses et en élimine certaines selon les preuves.[1]
La capacité était donc toujours présente. Le problème semblait plutôt être la décision trop précoce que les preuves étaient suffisantes pour agir ou s’arrêter.
4. Ce qui a été signalé comme efficace #1 : RCA-first
Le motif le plus réutilisable est simple : prouver la cause avant de modifier.
Mauvais workflow :
- Voir un symptôme.
- Deviner la cause.
- Corriger un endroit compatible avec cette supposition.
- Faire passer un test local.
- Annoncer le succès.
- Découvrir que le système d’origine est toujours cassé.
Workflow RCA-first :
- Ne rien modifier encore.
- Lire le code réel, les logs, l’état et les conditions de reproduction.
- Formuler plusieurs hypothèses.
- Éliminer les hypothèses grâce aux preuves.
- Établir une cause racine.
- Faire la plus petite correction justifiée.
- Relire directement le résultat demandé par la tâche initiale.
L’issue #43329 rapporte une amélioration nette du comportement d’exploration après cette instruction.[1]
Au lieu de seulement dire « corrige X », ajoutez :
« Établis d’abord la cause racine à partir de preuves. Ne commence pas par une correction supposée. »
5. Ce qui a été signalé comme efficace #2 : Medium a terminé un workflow qu’Ultra ne terminait pas
« Tâche difficile » ne signifie pas automatiquement « effort de raisonnement maximal ».
Dans l’issue #46648, plusieurs exécutions Astra Ultra du même workflow d’analyse read-only d’un dépôt n’ont pas produit de résultat final, même avec des timeouts externes de 1200 et 1800 secondes. Lors d’un échec inspecté, les tool calls et subagents étaient terminés, mais le root agent n’avait pas produit le JSON final ni l’événement de completion. Une exécution Medium du même workflow s’est terminée en environ 274 secondes avec exit code 0, turn.completed et JSON valide selon le schema.[5]
Il s’agit d’un rapport isolé, pas d’un benchmark contrôlé. D’autres utilisateurs ont au contraire signalé une bonne efficacité avec Max.[6]
La leçon prudente est :
Plus de raisonnement ne signifie pas forcément une meilleure fiabilité d’achèvement.
6. Goal mode et subagents ne sont pas non plus des remèdes automatiques
Quand l’agent s’arrête trop tôt, la réaction évidente est : « Alors ne t’arrête jamais. »
Cela peut créer la panne inverse.
L’issue #43103 décrit une exécution normale qui s’arrête avant le livrable, puis une exécution persistante de type goal qui continue à consommer de l’usage à travers des compactions, réécritures de code et validations répétées sans terminer l’objectif initial.[2]
La courbe peut devenir :
S’arrête trop tôt → « Ne t’arrête jamais » → Maintenant il ne s’arrête plus
Les subagents ont un compromis similaire. Des utilisateurs rapportent que des workflows multi-agent fortement centrés sur Astra consomment beaucoup, alors qu’un Astra unique ou sans subagents peut être plus efficace.[6] Un autre utilisateur rapporte environ 50 % d’usage en moins en déléguant les tâches auxiliaires adaptées à GPT-5.6 Sol et en gardant Astra pour le raisonnement difficile.[7] Un autre a trouvé « very effective » l’utilisation d’Astra XHigh pour la documentation d’implémentation puis de Sol High pour l’implémentation.[8]
La conclusion n’est pas « interdisez les subagents ».
Elle est : ne faites pas par défaut d’Astra le manager d’une armée d’agents aussi coûteux. Les tâches mécaniques peuvent aller à des helpers moins chers ; si l’agent principal peut terminer seul, inutile d’ajouter une couche de coordination.
7. Le pattern de prompt le plus robuste externalise la condition d’arrêt
Ne laissez pas entièrement à l’agent la question « est-ce que j’ai fini ? ».
Définissez d’abord l’objectif final et les critères d’acceptation, puis excluez explicitement les étapes intermédiaires de la définition de « terminé ».
Avant de modifier le code, inspecte le code réel, les logs et l’état actuel.
Établis la cause racine à partir de preuves. Ne pars pas d’une correction supposée.
Objectif final :
Faire réellement réussir X.
Condition de fin :
Exécuter X et relire directement Y depuis l’environnement cible réel.
Investigation terminée, code modifié, commit créé, tests réussis,
build réussi ou déploiement démarré sont des états intermédiaires.
Aucun d’eux ne signifie à lui seul que la tâche est terminée.
Continue :
investiguer → corriger → exécuter → vérifier
jusqu’à satisfaction de la condition de fin.
Ne répète pas la même vérification ou réparation sans nouvelle preuve.
Arrête-toi lorsque la condition de fin est satisfaite.
Arrête-toi plus tôt uniquement devant un blocker concret
impossible à résoudre avec les outils autorisés,
comme un manque de permission, une dépendance externe
ou une restriction de sécurité.
La clé n’est pas seulement « continue ».
C’est dire jusqu’où continuer et exactement où s’arrêter.
8. Ne transformez pas tous les modèles en généralistes — Sol / Codex pour le quotidien, Astra pour les vrais cas difficiles
Après suffisamment d’exécutions, une conclusion plus pratique apparaît :
Astra n’a pas besoin d’être le modèle par défaut pour chaque tâche.
Dans un workflow réel, Sol couvrait déjà largement la compréhension de l’état actuel, les hypothèses de cause, la conception de solutions et l’orientation de l’implémentation. Codex était particulièrement utile pour lire le repository, les logs et l’état courant du runtime, puis effectuer le travail concret. Astra gardait une vraie valeur pour l’analyse causale difficile, mais son usage était beaucoup plus coûteux et, lorsqu’on lui confiait aussi toute l’implémentation, il pouvait dériver vers d’autres sujets ou s’arrêter à des frontières étranges.
Au lieu de vouloir faire de chaque modèle un joueur complet, mieux vaut exploiter le point fort de chacun.
8.1 Astra doit être une voie d’escalade, pas le choix par défaut
La boucle normale peut tourner avec Sol et Codex.
Codex rassemble les faits : current main, logs récents, runtime state, receipts et production readback. Sol transforme ces faits en hypothèses causales et en plan de réparation. Ensuite Codex ou l’environnement d’exécution modifie, teste et vérifie le résultat réel.
On n’escalade vers Astra que lorsque :
- le même défaut revient après plusieurs réparations ;
- supprimer l’erreur directe vue dans les logs ne répare pas le système ;
- plusieurs couches se contredisent sur l’état courant ;
- l’arbre des causes continue de grossir au lieu de converger.
À ce moment-là, le travail d’Astra n’est pas « tout faire ». Il doit construire l’arbre causal, éliminer les branches par les preuves, puis fixer une cause racine et une spécification de réparation. L’implémentation revient ensuite à Sol / Codex.
Inutile de laisser le cerveau le plus cher tourner au ralenti toute la journée. On appelle le véhicule de commandement quand personne ne sait même où se trouve l’incendie.
8.2 Une chaîne de production IA n’a pas besoin de copier « anomalie = arrêt définitif »
Sur un équipement industriel classique, il est logique de s’arrêter lorsqu’une anomalie apparaît. Une machine physique qui continue à tourner en panne peut multiplier les défauts ou provoquer un accident.
Mais un agent IA peut ajouter une étape après avoir contenu le dommage :
détecter l’anomalie → contenir le dommage → diagnostiquer → réparer de façon sûre → relancer → lire le résultat réel
Cela ne signifie pas « toujours continuer sans limite ». Les actions à fort impact — suppression de données, dépense d’argent, modification de privilèges, exposition de secrets ou publication externe difficile à annuler — doivent toujours s’arrêter au bon point d’autorisation. En revanche, si une réparation est peu risquée et réversible, demander une nouvelle validation humaine après chaque petit échec retire une grande partie de l’intérêt de l’agent.
Si l’objectif réel est « l’article est lisible en production », trouver une erreur dans un log n’est pas un succès. Il faut réparer ce qui peut l’être en sécurité, relancer, puis vérifier l’état final.
8.3 Une mise à jour de mémoire est de la tenue de registre, pas un événement terminal
Un autre mode d’échec apparaît lorsqu’une longue tâche écrit une mémoire ou un résumé puis traite cet acte de documentation comme un point naturel pour rendre la main.
Si l’utilisateur a explicitement dit « ne t’arrête pas après la mise à jour de mémoire », alors cette mise à jour n’est qu’un effet secondaire.
La bonne paire est :
écrire le registre → reprendre au point d’exécution précédent
Imaginez un mécanicien disant : « J’ai noté la panne dans le carnet d’entretien, donc je rentre chez moi. » Le carnet peut être parfait ; la voiture reste en panne. Mémoires, résumés, commits et rapports de progression soutiennent le livrable. Ils ne sont pas le livrable.
En pratique, on conserve l’étape courante avant d’écrire la mémoire, puis on reprend cette même étape après la mise à jour. L’écriture de mémoire ne doit pas être classée comme terminal action. Cette règle simple sépare clairement « je l’ai enregistré » de « je l’ai terminé ».
8.4 « Vas-y » ne veut pas dire « redéfinis l’objectif »
La sémantique de l’autorisation compte aussi.
« Vas-y » signifie normalement continue la tâche déjà en cours. Cela n’accorde pas automatiquement le droit de lancer une tâche latérale, de modifier la condition d’arrêt, de passer en mode documentation ou de redéfinir ce qui compte comme terminé.
L’agent doit séparer l’autorisation de continuer de l’autorisation de changer l’objectif.
Ce qui a été autorisé, c’est la progression, pas le remplacement de la destination.
Sans cette distinction, l’utilisateur dit simplement « continue à réparer », l’IA commence à écrire un énorme manuel d’exploitation et revient satisfaite une fois le manuel terminé. Le château n’est toujours pas pris, mais le plan d’urbanisme de la ville extérieure est superbe.
La règle de conception finale est simple :
Utilisez les modèles polyvalents et les outils d’exécution pour le travail normal. N’escaladez que les diagnostics réellement difficiles. Après une anomalie, poursuivez les réparations sûres et réversibles. Ne vous arrêtez pas uniquement parce que vous avez écrit des registres. Conservez l’objectif autorisé jusqu’à vérification de sa véritable condition d’achèvement.
9. Conclusion : intelligence et fiabilité opérationnelle sont deux axes différents
Les informations publiques dessinent une image assez cohérente :
- OpenAI : Astra peut être prudent sur le moment d’arrêt ; définissez la fin à l’avance.[4]
- GitHub : des utilisateurs ont signalé du travail inachevé présenté comme terminé.[1]
- GitHub : un cas montre une amélioration de l’investigation avec RCA-first.[1]
- GitHub : un cas montre Medium terminant un workflow qu’Ultra ne terminait pas.[5]
- GitHub : l’exécution persistante peut transformer un arrêt prématuré en boucle repair/compaction.[2]
- Communauté : réduire les subagents, utiliser des helpers moins chers ou réserver Astra à la planification et au raisonnement difficile a aidé certains utilisateurs.[7][6][8]
La solution n’est donc pas toujours « fais réfléchir Astra plus fort ».
Souvent, il faut plutôt dire :
« Ne remplace pas ce que j’ai demandé par une autre réussite simplement proche de la cible. »
Les étiquettes diagnostiques humaines n’expliquent pas utilement ce comportement d’IA. L’ingénierie des agents fournit de meilleures variables.
Si la demande est X, la preuve finale doit elle aussi être X.
Sources
- openai/codex GitHub Issue #43329 — “Suspected degradation of gpt-6-astra: premature turn termination (~30s), completion reports for work that was never done, ‘I guess...’ instead of investigating.” Opened 2026-09-07; retrieved 2026-09-23. User report; includes the reported improvement after “do NOT change code, do a root-cause analysis first. github.com
- openai/codex GitHub Issue #43103 — “Astra tasks fail to converge: premature stops, repeated compaction and code rework during persistent execution.” Opened 2026-09-05; retrieved 2026-09-23. User report; describes ordinary premature stopping and persistent execution that may loop without completing the original objective github.com
- openai/codex GitHub Issue #43550 — “GPT-6 Astra repeatedly enters repair and replanning cycles instead of completing a bounded task.” Retrieved 2026-09-23. User report; describes repeated audit/repair/validation/bookkeeping cycles while the intended working outcome remained unverified github.com
- OpenAI Developers — “Rethinking skills and prompts for GPT-6 Astra.” Published 2026-09-11; retrieved 2026-09-23. Official guidance on bloated skills/AGENTS.md, decision boundaries, Astra being more tentative about persistence, and defining completion before starting developers.openai.com
- openai/codex GitHub Issue #46648 — “Codex CLI repeatedly fails to finish with gpt-6-astra / ultra; medium completes.” Opened 2026-09-19; retrieved 2026-09-23. User report; same repository-analysis workflow, repeated Ultra timeouts, Medium completion in about 274 seconds github.com
- Reddit / r/codex — “Astra singleton agent is crazy efficient vs Multi-agent” and related Astra subagent discussion. Published 2026-09-14 / 2026-09-11; retrieved 2026-09-23. Anecdotal community reports; not controlled benchmarks. and https://www.reddit.com/r/codex/comments/1wdct3p/astra_subagents/ reddit.com
- Reddit / r/codex — “Astra Usage Tip.” Published 2026-09-13; retrieved 2026-09-23. Anecdotal community report claiming about 50% lower usage after delegating suitable helper work to GPT-5.6 Sol while retaining Astra for hard reasoning reddit.com
- Reddit / r/codex — “Codex is done.” Published 2026-09-19; retrieved 2026-09-23. Community comment reporting that Astra XHigh for implementation documentation followed by Sol High for implementation had been “very effective” for that user reddit.com
