Locale: fr
Note : cet article sépare les informations publiques vérifiables au 4 octobre 2026 des impressions issues d’un usage concret. Les informations publiques sur Astra, Codex et Claude Opus 5.5 ont été vérifiées auprès de sources officielles. Des phrases comme « Astra élargit facilement l’exploration » ou « Dot fonctionne bien comme superviseur » décrivent un workflow particulier, pas un benchmark universel. « Dot » désigne ici le rôle d’IA superviseur.
1. Conclusion : ne demandez pas à un seul modèle de jouer toute l’entreprise
Quand une IA est très puissante, on veut lui donner tout le travail :
recherche, conception, code, tests, récupération après échec, suivi et compte rendu.
En réalité, cela regroupe plusieurs métiers.
Une séparation pratique :
- Exploration : Astra — chercher causes, alternatives, hypothèses oubliées et risques d’architecture
- Supervision : Dot — limiter le périmètre, suivre l’état, détecter les blocages et choisir la suite
- Exécution : Codex — modifier code et fichiers, rechercher et lancer les tests
Si un seul modèle termine correctement le travail de bout en bout, nul besoin de fabriquer une équipe. Anthropic présente Claude Opus 5.5 pour le coding agentique, les tâches complexes multi-outils et le travail de longue durée.[5]
La règle :
un agent s’il clôt le travail ; plusieurs rôles si le travail part dans tous les sens.
2. Une forte capacité d’exploration peut aussi agrandir le périmètre
Quand la cause est inconnue, un explorateur est précieux.
Il remet les hypothèses en question. Cherche les dépendances cachées. Propose d’autres architectures. Suit la cause racine.
Mais « corrige ce bouton » peut devenir :
« revoyons l’architecture du composant », « inspectons les services liés », « améliorons l’extensibilité », « nettoyons les anciennes dépendances ».
Le bouton reste cassé.
OpenAI décrit l’orchestration comme la manière de décider quels agents s’exécutent, dans quel ordre et comment choisir l’étape suivante, avec notamment une approche pilotée par LLM et une approche pilotée par le code.[1]
Explorer n’est pas terminer.
3. Dot est plus utile comme contremaître que comme second génie
Le superviseur doit savoir :
- quelle tâche est active
- ce qui est fini
- ce qui a échoué
- qui agit ensuite
- quand escalader
Si Astra propose un redesign global, Dot peut répondre : « Très bien, nouvelle tâche. D’abord, rétablissons le service. »
Si Codex échoue à un test, Dot renvoie le log.
Après trois échecs identiques, le problème monte vers Astra.
Ce rôle est moins spectaculaire, mais il empêche la chaîne de s’arrêter.
4. Codex devient plus prévisible avec des limites claires
Il faut préciser :
- dépôt
- fichiers cibles
- symptôme
- périmètre autorisé
- critère de succès
- tests obligatoires
- format du résultat
Si le vrai but est de faire passer une PR, inutile de demander une stratégie d’entreprise.
Le projet Symphony d’OpenAI traite également issues et tâches comme des unités de travail durables, plutôt que de placer la session de code au centre.[2]
La conversation n’est pas le travail. La tâche est le travail.
5. thread_id aide, mais task_id doit être la clé principale
source_thread_id indique où renvoyer la réponse.
Mais un même fil peut contenir plusieurs questions.
Séparez donc :
- task_id
- source_thread_id
- source_message_id
- manager / executor / advisor
- status
- attempt
- next_action
États utiles : pending, working, blocked, review, done, delivered, failed.
« Probablement terminé » n’est pas un état.
6. Boucle normale Dot↔Codex ; Astra seulement en cas de vrai blocage
Normal :
Dot → Codex → Dot → Codex
Escalade :
Dot → Astra → Dot → Codex
Exemples de déclencheurs :
- même échec trois fois
- plusieurs causes possibles sans moyen de trancher
- changement d’architecture nécessaire
- plusieurs dépôts concernés
- conflit entre demande et spécification
Astra devient alors un spécialiste, pas un participant permanent à chaque réunion.
7. Un abonnement premium temporaire ne doit pas devenir l’infrastructure permanente
Une fonction disponible aujourd’hui peut sortir du budget demain.
Il faut donc conserver :
- état des tâches
- prompts
- critères d’acceptation
- tests
- limites de retry
- règles d’escalade
- logs d’échec
Le modèle premium peut être un turbo. Il ne doit pas être le seul endroit où vit le processus.
8. Si Opus 5.5 va de 0 à 10 seul, choisissez le système le plus simple
Les organigrammes multi-agents sont amusants.
Superviseur, chercheur, exécutant, relecteur.
Puis l’humain devient le service RH d’une entreprise de robots.
Ce n’est pas le but.
Anthropic présente Opus 5.5 pour le coding agentique, les tâches longues et les workflows complexes multi-outils.[5]
S’il réalise de manière fiable :
objectif → recherche → implémentation → tests → correction → rapport final
alors l’utiliser directement peut être plus simple.
Ne créez pas IA SA si une seule personne ferme le ticket.
9. Architecture minimale
- Chaque question ou incident entre dans une file avec task_id.
- Dot choisit priorité et prochaine action.
- Codex exécute.
- Dot vérifie.
- Astra intervient seulement si une règle se déclenche.
- La réponse revient vers source_thread_id.
- On ferme après confirmation de delivered.
- Les travaux réellement end-to-end peuvent aller directement à Opus 5.5.
L’infrastructure stocke des rôles :
manager executor advisor
Pas des noms de modèles.
10. Résumé : plus d’IA ne signifie pas plus d’automatisation
Le plus difficile n’est pas toujours de penser davantage.
C’est de savoir quand arrêter de penser et commencer à exécuter.
L’exploration agrandit la carte. La supervision ferme la boucle. L’exécution touche réellement aux fichiers.
Séparés :
Astra : « J’ai trouvé sept options. » Dot : « Teste la deuxième. » Codex : « Corrigé. Tests OK. » Dot : « Fermé. »
Soudain, cela ressemble à une entreprise.
Keep the loop tight.
Le nombre d’agents n’est pas le niveau d’automatisation.
L’automatisation, c’est un travail qui atteint une fin vérifiable sans qu’un humain doive constamment venir le sauver.
