Contexte technique
J'adore ce genre de cas, non pas pour l'effet « wow », mais parce qu'on y voit une véritable architecture IA, et non un simple chat avec un prompt bricolé. Le schéma est simple et puissant : une base de connaissances commune dans Obsidian, un Claude Code dédié pour chaque projet, un orchestrateur au sommet, et des sous-agents en dessous pour des tâches spécifiques.
J'apprécie particulièrement que la base de connaissances soit externalisée en Markdown. C'est une approche très pragmatique pour l'intégration de l'IA : les connaissances, les instructions, le contexte du projet et le routage des tâches sont stockés dans un format lisible, et non codés en dur dans l'orchestrateur. On modifie le Markdown, on ne réingénierie pas tout le système.
C'est là que ça devient intéressant. Si un agent de projet se retrouve dans une impasse, il ne reste pas bloqué dans une boucle infinie ; il escalade le problème vers le haut. L'orchestrateur décide alors de la marche à suivre : traiter le cas lui-même, transmettre la tâche à un autre agent, ou diviser le travail en sous-tâches.
Cela ressemble déjà beaucoup à un pipeline de développement de type production. Je reconnais ici des schémas familiers : des sessions isolées, des rôles dédiés, des passages de relais entre agents, une couche de mémoire partagée et la gestion des tâches longues via un coordinateur. Essentiellement, c'est une fondation pour l'implémentation de l'intelligence artificielle dans les équipes d'ingénierie, où un processus stable est plus important qu'un seul agent intelligent.
J'ai aussi été intrigué par le fait que Claude Code et Codex peuvent tous deux servir d'orchestrateurs de haut niveau. Ici, je définirais soigneusement les limites de responsabilité pour éviter qu'ils ne se disputent le contrôle du pipeline. Mais l'idée elle-même est saine : un modèle est plus fort dans certains types de tâches, l'autre dans d'autres, et cela peut être utilisé comme une couche de routage plutôt que comme une bataille de modèles.
Ce que cela change pour l'entreprise et l'automatisation
Le premier effet est évident : le coût du changement de contexte diminue. Lorsque chaque projet a son propre agent et sa propre mémoire, je ne passe pas une demi-journée à réexpliquer l'architecture, les bogues et les accords. Pour les équipes, ce n'est plus un jouet, mais une véritable automatisation avec l'IA.
Le deuxième point que je soulignerais est l'escalade. Au lieu d'échouer en silence, l'agent lève la main, l'orchestrateur intervient, et la tâche ne meurt pas. C'est essentiel pour les plateformes internes, le support au développement et les refactorisations à grande échelle.
Mais ceux qui lancent cela sans discipline sont voués à l'échec. Sans isolation des espaces de travail, sans logs, sans limites de temps et sans un schéma de passage de relais clair, la multi-agence se transforme rapidement en un chaos coûteux alimenté par les jetons.
C'est exactement le genre de choses que j'aime décortiquer : où utiliser un seul agent, où construire une orchestration, et où ne pas toucher à ce qui fonctionne déjà. Si votre équipe est déjà embourbée dans la coordination manuelle, chez Nahornyi AI Lab, nous pouvons développer une solution IA sur mesure pour votre flux de travail réel, afin que les agents s'occupent des tâches de routine et que les gens puissent enfin se concentrer sur l'ingénierie, et non sur la répartition des tâches.