OpenAI Symphony : une spécification open source pour orchestrer les agents Codex
OpenAI publie Symphony, une spec open source Apache 2.0 orchestrant des agents Codex sur des tableaux de tâches comme Linear. Les premières équipes rapportent 5× plus de PR merged en trois semaines.
Le passage de l'agent de coding ponctuel à un système d'automatisation continue est l'un des chantiers les plus actifs de 2026. Les modèles comme Codex peuvent résoudre des tâches complexes en autonomie, mais les coupler à un flux de travail d'équipe — créer une branche, soumettre une PR, relancer si l'agent plante — requiert une couche d'orchestration qui n'était pas standardisée. OpenAI répond à ce manque avec Symphony, une spécification open source publiée le 27 avril 2026.
Ce que fait Symphony
Symphony est une spécification formelle (un fichier SPEC.md) accompagnée d'une implémentation de référence. Son rôle : transformer un tableau de gestion de projet — Linear dans le cas de référence — en panneau de contrôle pour des agents de coding.
Le fonctionnement est simple en principe, ambitieux à l'exécution :
- Surveillance continue du board : Symphony interroge le tableau et s'assure que chaque tâche active possède un agent en cours d'exécution.
- Isolation par tâche : chaque item ouvre un workspace dédié dans lequel un agent Codex travaille de façon autonome, de la lecture de la spécification jusqu'à la soumission d'une pull request.
- Supervision et résilience : si un agent plante ou stalle, Symphony le redémarre. Si une nouvelle tâche apparaît, elle est automatiquement prise en charge.
- Spécification ouverte : la licence Apache 2.0 permet à n'importe quelle équipe d'adapter la spec à d'autres trackers (GitHub Issues, Jira, Linear, Notion, etc.).
L'implémentation de référence en Elixir
Le choix d'Elixir pour l'implémentation de référence est délibéré : le runtime BEAM et le modèle d'acteurs d'OTP offrent des primitives natives pour superviser des processus concurrents et les relancer en cas d'échec, sans complexité supplémentaire. OpenAI a fourni le SPEC.md à Codex, qui a généré l'implémentation Elixir en un seul passage — une validation interne de la capacité des agents à produire du code de production dans un langage hors de leur domaine de confort habituel.
# Extrait de SPEC.md (simplifié)
A Symphony orchestrator MUST:
- poll the task source at a configurable interval
- maintain one agent run per active task
- restart any agent run that terminates unexpectedly
- mark a task done when its agent produces a pull request
Résultats mesurés
OpenAI rapporte que certaines équipes internes ont vu une augmentation de 500 % des pull requests mergées lors des trois premières semaines d'utilisation. Le dépôt GitHub a rapidement dépassé les 15 000 étoiles. Ces chiffres restent internes à OpenAI et n'ont pas été reproduits par des équipes tierces à ce stade.
Limites et pièges
Qualité du board d'abord : Symphony suppose des tâches bien spécifiées. Un ticket vague produit une PR hors-sujet. Le travail de spécification des issues se déplace en amont, pas en aval.
Dépendance à Linear dans l'implémentation de référence : les équipes utilisant d'autres trackers doivent adapter le connecteur, ce qui n'est pas documenté en détail dans la version initiale.
Contexte d'entreprise : Symphony repose sur Codex (produit payant d'OpenAI). Les équipes souhaitant utiliser un autre modèle doivent réécrire la couche d'exécution, la spec ne prescrivant pas de modèle spécifique mais l'implémentation de référence étant liée à l'API OpenAI.
Pas de feedback multi-agent : deux agents travaillant sur des tâches liées n'ont pas de mécanisme natif de coordination ; chaque workspace reste isolé.
Symphony pose les bases d'un pattern qui va probablement se généraliser : détacher la supervision du travail d'agent de l'interaction humaine directe. La question ouverte est celle du trust boundary — jusqu'où peut-on déléguer en autonomie complète sans revue humaine intermédiaire ?
Analyse InfoWorld — Symphony pousse les agents du prompt vers l'orchestration