Travailler avec des agents sur plusieurs dépôts séparés

Un dépôt backend et un dépôt client vont ensemble, mais vivent séparément — un agent a besoin d'une stratégie différente de celle utilisée dans un seul monorepo.

Distinction avec le monorepo

Le chapitre « Utiliser des agents IA dans de grands monorepos » traite d'UN seul dépôt regroupant de nombreux sous-projets sous un même toit. Il s'agit ici de l'inverse : plusieurs dépôts autonomes, versionnés séparément — par exemple un backend d'API et un dépôt frontend distinct — qui forment ensemble un système, mais possèdent chacun leur propre historique Git, leur propre CLAUDE.md et leur propre pipeline de déploiement.

Le contexte par dépôt

Chaque dépôt conserve son propre CLAUDE.md avec ses propres conventions. Un agent qui démarre dans le dépôt backend connaît automatiquement ses règles — il ne charge pas de lui-même les règles du dépôt frontend, car les deux dépôts ne savent techniquement rien l'un de l'autre.

Établir l'accès à un second dépôt

Claude Code peut intégrer une copie supplémentaire d'un dépôt extrait séparément via un accès à un répertoire additionnel — la même technique qui rend aussi accessibles des paquets voisins dans un monorepo fonctionne tout aussi bien pour un second dépôt entièrement séparé présent sur le disque.

Modifications coordonnées et ordre des opérations

Si un contrat d'API change, la modification backend doit généralement être d'abord fusionnée et déployable avant que le client ne soit adapté — ou alors les deux côtés restent rétrocompatibles pendant une phase de transition. Sans ordre délibéré et sans versionnage, tu risques des hypothèses incompatibles entre le client et le serveur.

EXEMPLE

Tâche : ajouter un nouveau champ 'currency' à l'information de prix, le dépôt backend 'tm2-api' et le dépôt frontend 'tm2-web' sont séparés. Étape 1 (dans le dépôt tm2-api) : ajouter le champ de façon additive au schéma de réponse, l'ancien client reste compatible puisque le champ est optionnel. Déployer. Étape 2 (accès à tm2-web via --add-dir ou une session séparée) : adapter le client pour qu'il utilise le nouveau champ s'il est présent, sinon qu'il utilise la valeur par défaut précédente. Étape 3 : marquer le champ comme obligatoire dans le backend seulement après confirmation du déploiement des deux côtés.

🛠️ EXERCICE — À TOI DE JOUER

Simule une modification coordonnée sur deux dépôts locaux séparés.

Crée localement deux petits dépôts Git séparés, l'un comme 'API', l'autre comme 'Client', qui partagent un « contrat » via un simple fichier texte (par ex. un schéma JSON).
Modifie le contrat de façon additive dans le dépôt API (nouveau champ optionnel) et effectue un commit.
Donne à un agent l'accès aux deux répertoires et laisse-le adapter le client pour qu'il utilise le nouveau champ s'il est présent.
Vérifie si le client fonctionne encore même sans le nouveau champ (ancien contrat).

✅ AUTO-VÉRIFICATION

☐ Le client est-il resté fonctionnel avec l'ancienne version du contrat, alors que la nouvelle version existait déjà ?
☐ L'agent a-t-il dû accéder explicitement au second répertoire de dépôt, ou l'a-t-il fait automatiquement ?

QUIZ RAPIDE

Qu'est-ce qui distingue fondamentalement le travail sur plusieurs dépôts séparés d'un monorepo avec de nombreux sous-projets ?