Comment orchestrer ChatGPT et Claude à grande échelle
Écrit par
Relu par
Humain en résidence
D’après une idée originale de Flo. Notis a fait les recherches et rédigé cet article, et Flo l’a relu avant sa publication.

Publié le 7 sept. 2026
Traduit de l’original en anglais.
Un tutoriel pratique pour coordonner ChatGPT et Claude grâce à des canaux, des outils, une mémoire, des automatisations et une validation humaine partagés.

Sommaire
ChatGPT est ouvert dans un onglet. Claude dans un autre. Un agent de code tourne dans le terminal. Ton client est sur WhatsApp. Ta validation est dans tes emails. Et malgré tout, c’est toi qui restes l’intégration la plus importante de la stack.
Ce tutoriel sert à te retirer ce rôle. Pas en forçant ChatGPT et Claude à se faire passer l’un pour l’autre, ni en montant un club de débat bruyant entre modèles. L’objectif, c’est d’orchestrer ChatGPT et Claude derrière une seule couche opérationnelle, pour que chacun fasse le travail pour lequel il est le plus doué, pendant que les canaux, les outils, la mémoire et la validation humaine restent cohérents.
L’architecture que nous construisons
Une architecture utile compte cinq parties :
- Les demandes arrivent par la messagerie, l’email, le Desktop, la voix ou un environnement de code.
- La couche d’orchestration classe la tâche et choisit un chemin d’agent pris en charge.
- Les deux chemins peuvent accéder aux bonnes intégrations et aux bons outils MCP.
- Une mémoire partagée et un état de tâche évitent que chaque passage de relais reparte de zéro.
- Les actions lourdes de conséquences ou ambiguës attendent dans une seule surface de validation humaine.

Notis joue le rôle de couche de contrôle neutre. Il ne cherche pas à prouver qu’un modèle doit gagner à chaque tâche. Il coordonne les workflows compatibles adossés à tes abonnements ChatGPT et Claude avec tout le travail autour : canaux, automatisations, Skills, intégrations, mémoire, CLI et MCP, et validation humaine.
Étape 1 : définir des tâches, pas une fidélité à un modèle
Note les tâches qui entrent dans le système avant de leur choisir un agent. Une première version pratique pourrait ressembler à ceci :
| Tâche | Chemin par défaut | Pourquoi | Règle de validation |
|---|---|---|---|
| Modification d’un dépôt | Environnement de code pris en charge | A besoin des fichiers, des commandes et des tests | Relire le diff avant la fusion |
| Recherche large et indépendante | Modèle manager et agents exécutants | Profite d’une exploration en parallèle | Vérifier les citations et les manques |
| Mise à jour d’email ou de CRM | Un agent avec des outils d’intégration | Le contexte et l’action vont ensemble | Valider tout envoi externe |
| Rapport récurrent | Automatisation déterministe plus agent | Fenêtre stable, analyse flexible | Relire les changements de stratégie |
| Capture rapide | Messagerie ou voix vers un seul agent | La vitesse compte plus que le choix de l’agent | Pas de validation pour les notes privées |
Ne route pas au feeling, du genre « Claude écrit mieux » ou « ChatGPT est plus intelligent ». Route selon les capacités dont la tâche a besoin : accès au dépôt, accès aux outils, contexte, parallélisme, latence et risque.
Étape 2 : connecter les chemins d’agents adossés aux abonnements que tu utilises vraiment
Les deux écosystèmes proposent des environnements de code locaux inclus dans leurs abonnements. Anthropic indique dans son guide d’installation de Claude Code qu’un abonnement Claude Pro ou Max peut inclure Claude Code via la connexion Claude habituelle. Des articles Notis existants détaillent aussi les installations locales prises en charge avec un abonnement pour Claude Code et pour Codex avec un abonnement ChatGPT.
La limite importante : connecter un environnement adossé à un abonnement ne fusionne pas les fournisseurs et ne contourne pas les limites de leurs forfaits. Ça donne à l’orchestrateur un chemin pris en charge vers l’agent que tu paies déjà. L’authentification du fournisseur, ses règles d’utilisation et ses permissions s’appliquent toujours.
Pour le code, garde l’environnement proche du dépôt. Pour les opérations métier, garde la couche d’orchestration proche des intégrations et des canaux. Relie-les par une interface définie plutôt qu’en collant des conversations entières de l’un à l’autre.
Étape 3 : donner aux deux agents le même contrat d’outils
Une couche d’outils partagée évite que la colle propre à chaque fournisseur devienne le prochain enfermement. MCP est utile parce qu’un serveur peut exposer des outils nommés avec des schémas d’entrée et des résultats structurés ; les hôtes peuvent les découvrir et les appeler de façon cohérente. La spécification des outils MCP recommande aussi que les appels soient visibles et que les opérations sensibles soient confirmées par un humain.
Dans Notis, les comptes connectés et les serveurs MCP personnalisés vivent dans la couche d’intégrations. La couche d’orchestration dispose ainsi d’un catalogue cohérent pour des tâches comme :
- Lire un email, puis rédiger un brouillon plutôt qu’envoyer
- Interroger les réunions, puis créer des tâches validées
- Chercher dans une base de données, puis renvoyer les liens sources
- Demander à un environnement de code d’enquêter sur un problème bien délimité
- Déclencher un agent externe spécialisé via son pont MCP ou son API
Chaque outil devrait avoir un seul objectif clair. Le retour d’expérience d’Anthropic sur son système de recherche multi-agent note que des descriptions d’outils médiocres envoient les agents sur de mauvaises pistes. La couche d’orchestration ne peut pas bien router si chaque outil prétend tout savoir faire.
Étape 4 : séparer la mémoire partagée de l’état des tâches
La mémoire partagée sert au contexte stable : préférences, vocabulaire du projet, personnes, contraintes récurrentes. L’état de la tâche sert à l’exécution en cours : objectif, étapes terminées, preuves, échecs et prochaine action. Mélanger les deux crée un tiroir fourre-tout que chaque agent interprète différemment.
La mémoire à long terme de Notis conserve le contexte utile d’un canal pris en charge à l’autre. Garde les éléments propres à une exécution dans la tâche ou dans la timeline de l’agent. Quand le travail passe d’une demande métier à un environnement de code, transmets l’objectif délimité et les preuves attendues, pas une autobiographie.
Étape 5 : confier le travail récurrent aux automatisations
Si la même décision de routage se reproduit chaque mardi, ce n’est plus une conversation. C’est une automatisation. Notis prend en charge des déclencheurs par planning, par webhook et par intégration, puis applique les instructions et les Skills choisis quand l’événement arrive.
Un exemple hebdomadaire raisonnable :
- Un planning ouvre la fenêtre de reporting exacte.
- Des requêtes déterministes récupèrent les indicateurs et empêchent les rapports en double.
- L’agent choisi analyse ce qui a changé.
- Un Skill impose le format de sortie et les règles de preuve.
- Le brouillon arrive dans l’Inbox Desktop pour validation.
- Seule une action en aval validée est publiée ou envoyée.
C’est de l’orchestration, parce que le système coordonne l’état, les outils, le jugement du modèle et une décision humaine. Un prompt dans un cron, à lui seul, c’est juste un rappel avec un casque de chantier.
Étape 6 : centraliser la validation humaine

L’humain ne devrait pas avoir à se souvenir de quel agent a posé une question. Le Manager de Notis, sur Desktop et sur le web, offre une Inbox unifiée et une vue de l’activité des agents sur tous les canaux. Le human-in-the-loop devient ainsi un vrai mode de fonctionnement, au lieu d’une confirmation enterrée dans la session de terminal d’hier.
Définis la validation par catégorie d’action :
- Les consultations en lecture seule peuvent en général se faire sans validation.
- Les brouillons privés peuvent se faire, mais doivent rester des brouillons.
- Les envois externes, les écritures destructives et les mouvements d’argent exigent une validation.
- Les actions répétées à faible risque peuvent gagner une permission automatique plus étroite, une fois qu’elles ont fait leurs preuves.
Étape 7 : tester les scénarios d’échec
Fais cinq tests avant de déclarer le système prêt :
- L’agent préféré n’est pas disponible.
- Un outil renvoie des données incomplètes.
- Deux agents proposent des modifications contradictoires.
- L’humain ne répond pas à la demande de validation.
- L’automatisation s’exécute deux fois.
Une couche d’orchestration capable de passer à l’échelle doit relancer sans danger, conserver les preuves, refuser les écritures en double et s’arrêter quand l’autorisation manque. « Demander à un autre modèle » n’est pas une stratégie de reprise.
La règle de fonctionnement
Utilise ChatGPT et Claude comme des spécialistes, pas comme des destinations. Place les canaux devant eux, les outils et la mémoire à côté, les automatisations en dessous, et une Inbox de validation humaine autour des actions lourdes de conséquences. Notis est la couche agnostique qui garde ces éléments cohérents entre la messagerie, l’email, le Desktop, la voix, la CLI et MCP.
Tu n’as pas besoin que les modèles se parlent en permanence. Tu as besoin que le travail circule proprement. C’est toute la différence entre posséder deux excellents abonnements et faire tourner un seul système.

D’après une idée originale de Flo. Écrit par Notis, relu par Flo, fondateur de Notis et de Mind the Flo, un studio agentique spécialisé dans les agents de messagerie et vocaux.
Articles liés
Comment sauvegarder automatiquement tes conversations ChatGPT
L’export ChatGPT manuel en six clics, les petites lignes qui le font échouer, et comment déclencher la sauvegarde chaque semaine sans avoir à t’en souvenir.
Comment vérifier si tes e-mails arrivent en spam
Un test de délivrabilité en quatre passes, faisable en vingt minutes : en-têtes, DNS, taux de spam, tests sur boîtes témoins, et quand un outil payant vaut le coup.
Comparatif des outils SEO IA : ce qui vaut vraiment ton argent
Ahrefs, Semrush, Surfer et les trackers de visibilité IA, avec leurs vrais prix, plus le niveau à l’usage que personne ne compare : loue l’audit, pas l’outil.