Un moteur ouvert qui connecte Claude, ChatGPT et Codex

#Pourquoi vouloir brancher plusieurs IA ensemble ?

Aujourd'hui, tu as le choix entre plusieurs assistants de code : Claude Code (Anthropic), ChatGPT (OpenAI) et Codex (l'agent de code d'OpenAI). Chacun a sa personnalité. Claude est réputé fort pour planifier et écrire du code robuste. Codex est très apprécié pour relire du code et traquer les défauts. ChatGPT sert souvent de généraliste pour raisonner ou rédiger.

La question qu'on se pose d'habitude, c'est « lequel choisir ? ». Mais il y a une autre voie : ne pas choisir. Les faire travailler ensemble, chacun sur ce qu'il fait de mieux. C'est l'idée derrière ce qu'on appelle un moteur d'orchestration ouvert : une couche logicielle qui sert d'intermédiaire entre plusieurs modèles d'IA pour qu'ils collaborent sur un même projet.

Cet article t'explique ce qu'est ce type de moteur, pourquoi le mot « ouvert » est important, comment il fonctionne sous le capot, et comment t'y mettre — même de façon très simple, sans rien installer de compliqué.

Un modèle (ou LLM, large language model), c'est le cerveau : Claude Opus, GPT-5, etc. Un agent, c'est un modèle équipé d'outils (lecture de fichiers, exécution de commandes) qui agit en autonomie. Claude Code et Codex sont des agents. Quand on « connecte des IA », on connecte en réalité des agents.

#Le problème : des agents qui s'ignorent

Par défaut, ces agents vivent dans des mondes séparés. Claude Code tourne dans ton terminal avec sa propre mémoire. Codex tourne ailleurs, dans son interface ou dans une pull request GitHub, avec sa propre mémoire lui aussi. Ils ne partagent rien. Si tu veux que Codex relise ce que Claude a écrit, c'est toi qui fais le facteur : tu copies, tu colles, tu passes d'une fenêtre à l'autre.

Ce travail manuel a trois défauts :

Il est lent : tu es le goulot d'étranglement entre deux IA qui pourraient échanger en quelques secondes.
Il perd du contexte : à chaque copier-coller, tu oublies des détails, et l'agent qui reçoit le texte ne sait pas ce qui s'est passé avant.
Il ne passe pas à l'échelle : avec deux agents, ça va. Avec cinq, tu deviens dispatcheur à plein temps.

Un moteur d'orchestration sert justement à automatiser ce rôle de facteur, de façon fiable et reproductible.

#« Ouvert », ça veut dire quoi exactement ?

Le mot ouvert porte deux promesses importantes.

Premièrement, neutre vis-à-vis du fournisseur. Le moteur ne t'enferme pas chez un seul éditeur. Il sait parler à Anthropic et à OpenAI et, demain, à un autre fournisseur. Tu n'es pas obligé de tout miser sur une seule entreprise. Si un nouveau modèle plus performant sort, tu le branches sans tout réécrire.

Deuxièmement, transparent et inspectable. « Ouvert » sous-entend souvent open source : tu peux lire le code du moteur, comprendre ce qu'il fait de tes données, et le modifier. À l'inverse d'une boîte noire commerciale, tu gardes le contrôle.

Retiens la nuance : un moteur ouvert orchestre des modèles qui, eux, peuvent rester fermés (Claude et GPT sont propriétaires). L'ouverture est dans la couche de coordination, pas forcément dans les cerveaux qu'elle pilote.

#Comment ça marche sous le capot

Un moteur d'orchestration repose sur trois briques. Comprends ces trois pièces et tu as compris l'essentiel.

#Brique 1 — Les adaptateurs (un par fournisseur)

Chaque fournisseur a sa propre façon de recevoir une requête : son format d'API, ses noms de modèles, son système d'authentification. Un adaptateur est un petit module de traduction : il prend une demande dans un format unique, interne au moteur, et la convertit dans le langage du fournisseur visé.

C'est exactement comme un adaptateur de prise électrique. Le moteur parle une seule langue ; chaque adaptateur traduit vers la prise locale (Anthropic, OpenAI...). Pour ajouter un nouveau modèle, tu écris un nouvel adaptateur, et le reste du système ne change pas.

#Brique 2 — Le bus de messages (le canal partagé)

Pour que des agents collaborent, il leur faut un endroit où se parler. C'est le bus de messages : un canal commun où chaque agent dépose ses messages et lit ceux des autres.

Imagine un salon de discussion partagé. Claude écrit « j'ai implémenté la fonction de login ». Codex lit ce message, relit le code, et répond « attention, tu ne valides pas l'email ligne 42 ». Claude lit la réponse et corrige. Tout passe par ce canal unique, et chaque message reste consultable — donc rien ne se perd.

#Brique 3 — L'espace de travail partagé (les fichiers et les tâches)

Discuter ne suffit pas : les agents doivent agir sur les mêmes fichiers sans se marcher dessus. Le moteur fournit donc un espace de travail commun, souvent organisé autour de deux éléments :

une liste de tâches partagée, où l'on voit qui fait quoi et ce qui reste à faire ;
un journal des changements (par exemple un fichier CHANGES.log), où chaque agent note ce qu'il vient de modifier, pour que les autres restent au courant.

Brique	Rôle	Analogie
Adaptateurs	Traduire vers chaque fournisseur	Adaptateur de prise électrique
Bus de messages	Faire dialoguer les agents	Salon de discussion partagé
Espace partagé	Coordonner fichiers et tâches	Tableau de bord d'équipe

#Le déroulé d'une mission, étape par étape

Mettons ces briques en mouvement. Voici ce qui se passe quand tu confies une fonctionnalité au moteur :

Tu donnes l'objectif au moteur : « ajoute une page de connexion avec validation de l'email ».
Le moteur répartit le travail. Il confie la conception et l'écriture à Claude (fort en planification), et réserve la relecture à Codex (fort en revue).
Claude travaille, écrit le code, puis poste sur le bus : « première version prête, voir CHANGES.log ».
Codex lit le message, relit le code via son adaptateur, et renvoie ses remarques sur le bus.
Claude corrige en tenant compte des remarques, et met à jour la liste de tâches.
Le moteur boucle jusqu'à ce que la tâche soit marquée terminée, puis te rend la main.

Tu n'as plus à faire le facteur entre les fenêtres : le moteur s'en charge, et tu gardes une trace écrite de tout l'échange.

#Te lancer sans usine à gaz

Bonne nouvelle : tu n'as pas besoin d'un système complexe pour goûter au principe. Tu peux orchestrer deux agents à la main, avec une convention toute simple, puis automatiser plus tard.

#Niveau 0 — La convention partagée

Crée à la racine de ton projet deux fichiers que les deux agents liront :

projet/
├── AGENTS.md       # les règles du jeu, communes à tous les agents
└── CHANGES.log     # le journal : qui a changé quoi, et quand

Dans AGENTS.md, tu écris les consignes que chaque agent doit suivre :

# Règles pour les agents

- Avant de coder, lis CHANGES.log pour voir le travail récent.
- Après chaque modification, ajoute une ligne dans CHANGES.log :
  [AGENT] [DATE] résumé court du changement.
- Ne touche pas à un fichier déjà en cours de modification par un autre.
- Claude : planification et écriture. Codex : relecture et correctifs.

Ce fichier joue le rôle du bus de messages simplifié : un endroit commun où chacun annonce ce qu'il fait. C'est rudimentaire, mais ça marche, et ça t'apprend la mécanique.

#Niveau 1 — Le relais via une pull request

L'enchaînement le plus répandu aujourd'hui utilise GitHub comme canal de passage :

Tu demandes à Claude Code de planifier et d'implémenter la fonctionnalité.
Claude ouvre une pull request (une demande de fusion de son code).
Codex est branché sur le dépôt pour relire automatiquement chaque pull request.
Codex poste ses remarques en commentaires ; tu demandes à Claude de les corriger et de redemander une relecture.
Tu répètes jusqu'à ce que Codex approuve.

Ici, la pull request est le bus de messages, et GitHub est l'espace partagé. Tu obtiens une vraie collaboration entre deux modèles concurrents, sans écrire une ligne de moteur.

Garde deux réflexes de sécurité. Un : donne à chaque agent un périmètre de fichiers distinct, sinon ils s'écrasent mutuellement. Deux : tu factures deux abonnements et deux fois des tokens (les unités de texte que les modèles consomment). Réserve cette orchestration aux tâches qui valent vraiment l'aller-retour.

#Niveau 2 — Le moteur complet

Quand le manuel devient répétitif, tu passes à un vrai moteur d'orchestration : un programme qui gère les adaptateurs, le bus et l'espace partagé pour toi, et qui boucle tout seul jusqu'à la fin de la tâche. Plusieurs projets open source existent dans cet esprit — souvent décrits comme des « méta-harnais » ou des « orchestrateurs multi-agents ». Le principe reste celui que tu viens de voir, simplement automatisé et outillé.

#Faut-il vraiment connecter plusieurs IA ?

Pas toujours. Pour une tâche simple, un seul bon agent suffit largement, et ajouter un second ne fait qu'augmenter la facture et la complexité. L'orchestration multi-modèles devient intéressante quand :

la tâche profite de regards complémentaires (un qui écrit, un qui relit) ;
tu veux éviter l'enfermement chez un seul fournisseur ;
tu fais souvent le même aller-retour à la main et veux l'automatiser.

Si rien de tout ça ne s'applique, reste simple. Le but n'est pas d'empiler les IA pour le plaisir, mais de mettre chaque modèle là où il est meilleur.

#Récapitulatif

Un moteur d'orchestration ouvert fait collaborer plusieurs agents (Claude, ChatGPT, Codex) sur un même projet, en jouant le rôle d'intermédiaire à ta place.
Ouvert signifie deux choses : neutre vis-à-vis du fournisseur (pas d'enfermement) et transparent (souvent open source, donc inspectable).
Il repose sur trois briques : des adaptateurs (traduction par fournisseur), un bus de messages (canal de dialogue) et un espace de travail partagé (fichiers et tâches).
Tu peux commencer sans rien installer : une convention partagée (AGENTS.md + CHANGES.log), puis un relais via pull request, avant de passer à un moteur complet.
Connecter plusieurs IA n'a de sens que si la tâche profite de regards complémentaires. Sinon, garde un seul agent.

Le réflexe utile n'est pas « quelle IA est la meilleure ? » mais « comment faire jouer chacune sur sa force ? ». Commence par la convention la plus bête qui soit — deux fichiers partagés — et regarde deux modèles concurrents se relire l'un l'autre. C'est le moyen le plus simple de transformer un choix en équipe.