Orchestrer une armée d'IA : retour d'expérience sur quatre modèles pour un double piano

Développer deux POC musicaux en temps réel en une seule journée — Rainbow Journey en React/TypeScript/Three.js et Chromatic River en JavaScript vanilla — a constitué un laboratoire grandeur nature pour tester plusieurs familles de modèles d'IA, d'agents autonomes et d'environnements d'orchestration.

L'historique Git des deux dépôts garde la trace exacte de chaque intervention : qui a fait quoi, dans quel ordre, sur quel périmètre, et avec quels résultats. Cet article dresse le bilan chronologique de cette collaboration hybride, regroupe les modèles selon leurs forces intrinsèques et propose une méthodologie concrète pour orchestrer efficacement plusieurs agents sans conflit.

1. La chronologie des interventions (12 septembre 2026)

L'aventure s'est déroulée en cinq temps forts sur les deux dépôts :

timeline
    title Déroulement chronologique des contributions
    16h52 : GPT / Astra : Cadrage initial & livraison du socle RainbowJourney (v0-astra-tango)
    18h06 - 18h23 : Copilot / VS Code : Lot 1 RainbowJourney (optimisations chemin chaud, IDB, 24 demi-tons, CI)
    18h37 : Kimi Agent : Livraison du POC visuel Chromatic River sur base 3D Venice Boat (v0-kimi)
    18h40 - 19h10 : Claude Opus 5 : Contrats d'interface (CONTRATS.md) & Vague A Chromatic River (A1-A4, A6)
    19h32 : Kimi Agent : Paquet A5 (bouées fantômes 3D & 13 glyphes vectoriels)
    19h45 : Claude Opus 5 : Vague B Chromatic River (session, piano romain, menu MIDI, HUD)
    20h41 - 21h01 : Copilot / VS Code : Sessions collaboratives DP1 (clavier AZERTY, recherche émotions, canon de jeu)
    22h14 - 22h31 : Claude Opus 5 : Vague C Chromatic River, audit croisé & rapport comparatif (PR #1)
    22h14 - 23h03 : Copilot / VS Code : FloatingPanel HUD, accessibilité, tests E2E Playwright & Devblogs

Les jalons clefs

1. 16h52 (GPT / Astra) : À partir d'un prompt initial exprimant le besoin de synesthésie visuelle pour piano MIDI, GPT mène quatre séries de questions/réponses approfondies et livre le socle complet de Rainbow Journey (React 19, TypeScript strict, Three.js, Tonal, Zod, IndexedDB).
2. 18h06 (GitHub Copilot dans VS Code) : Prise en main du code pour le « Lot 1 » : élimination des instanciations d'objets dans la boucle d'animation Three.js, mise en place d'un singleton de base de données IndexedDB, prise en charge des intervalles jusqu'à 24 demi-tons et tests d'accessibilité ARIA.
3. 18h37 (Kimi Agent - Moonshot AI) : Exploration visuelle alternative avec l'import direct d'un jeu de course de gondoles (Venice Speed) transformé en promenade vénitienne synesthésique sans compilation.
4. 18h40 – 22h31 (Claude Opus 5) : Formalisation d'un contrat d'interface strict (CONTRATS.md), découpage en 12 paquets étanches sans chevauchement de fichiers, implémentation des vagues A, B, C, et audit croisé exhaustif avec rapport HTML comparatif.
5. 20h41 – 23h03 (GitHub Copilot / Gemini dans VS Code) : Tests physiques sur le piano Bird DP1, ajout du clavier AZERTY, formalisation du canon de gameplay sans échec, système de panneaux HUD modulaires FloatingPanel et rédaction des articles de synthèse.

2. Regroupement par usage, volume et besoins

L'expérience montre que chaque modèle brille sur un profil de tâche précis. Tenter de confier l'ensemble du cycle à un seul agent conduit inévitablement à des angles morts.

3. Guide pratique : Comment orchestrer au mieux plusieurs agents

Pour faire collaborer plusieurs agents sur un projet complexe sans régression ni conflit de code, quatre règles fondamentales se dégagent :

Règle n°1 : Le Contrat d'Interface d'Abord (Zéro Chevauchement)

Avant de lancer des sous-agents en parallèle, l'orchestrateur doit rédiger un document d'interface unique et immuable (ex : CONTRATS.md ou types TypeScript d'exports). Chaque sous-agent reçoit un ensemble de fichiers strictement exclusif. Si deux agents écrivent dans le même fichier au même moment, le travail est compromis.

Règle n°2 : L'Audit Croisé Asymétrique

Un agent ne doit jamais être le seul validateur de son propre travail. La méthode la plus efficace consiste à confier l'implémentation exploratoire à un modèle rapide et créatif (ex: Kimi pour la 3D), puis à faire auditer et corriger son code par un modèle réputé pour sa rigueur formelle (ex: Claude Opus pour la gestion de mémoire et les contrats).

Règle n°3 : La Boucle de Feedback Outillée (Linter / Tests / E2E)

L'intégration finale doit impérativement se faire dans un environnement outillé où l'agent dispose de retours déterministes :

• Le compilateur TypeScript pour la conformité des types (tsc --noEmit).
• Les tests unitaires pour la logique métier (vitest).
• Les tests Playwright pour le rendu visuel et les interactions navigateur. Un agent guidé par des messages d'erreurs réels converge cinq fois plus vite qu'un agent travaillant en aveugle.

Règle n°4 : Garder une Source Unique de Vérité pour la Publication

Le dépôt Git conserve l'historique et la traçabilité technique ; l'Admin API gère le contenu vivant. Comme documenté lors des audits de publication, vérifier l'identité de l'agent publiant (whoami) et centraliser les métadonnées dans des frontmatters complets évite les désynchronisations entre local et production.

Conclusion

L'ingénierie logicielle assistée par IA n'est plus une question de « quel est le meilleur modèle dans l'absolu », mais de composition d'orchestre :

• GPT pour poser les fondations et questionner les hypothèses.
• Kimi pour prototyper et donner une âme visuelle.
• Claude pour figer les contrats, paralléliser et auditer avec rigueur.
• Copilot / VS Code pour assembler, tester, optimiser et livrer.

Combinés selon cette méthode, ils permettent de transformer une idée complexe en deux applications jouables et testées en quelques heures seulement.