Travailler sur des projets multi-repos

Gérer la complexité des architectures distribuées

Les projets modernes sont souvent répartis sur plusieurs repositories : un frontend, un backend, une bibliothèque partagée, un service de paiement. Codex peut travailler sur plusieurs repos simultanément pour maintenir la cohérence.

Le défi du multi-repos

Quand vous modifiez une API dans le repository backend, il faut souvent mettre à jour :

• Le client API dans le repository frontend
• Les types partagés dans le repository common
• La documentation dans le repository docs
• Les tests d’intégration dans le repository e2e

Manuellement, c’est une source d’erreurs et d’oublis. Avec Codex, vous pouvez coordonner ces modifications.

Configurer plusieurs repos

Sur l’app web codex.openai.com, vous pouvez connecter plusieurs repositories de votre organisation. Chaque tâche spécifie sur quel(s) repo(s) elle travaille.

"Dans le repo backend (api-service) :
- Ajoute un endpoint GET /api/v2/products avec pagination

Dans le repo frontend (web-app) :
- Mets à jour le client API pour utiliser le nouvel endpoint
- Ajoute la pagination dans le composant ProductList"

Codex crée les modifications dans chaque repo et produit des PRs coordonnées.

Synchroniser les types partagés

Un cas fréquent : les types TypeScript partagés entre frontend et backend.

"Le type Product dans shared-types/src/product.ts a été 
modifié (ajout du champ tags: string[]). 
Mets à jour tous les usages dans :
- api-service : les routes et services qui utilisent Product
- web-app : les composants qui affichent un Product
- mobile-app : les écrans qui affichent un Product
Assure-toi que chaque repo compile sans erreur."

AGENTS.md pour les monorepos

Si votre projet est un monorepo (Turborepo, Nx, Lerna), configurez AGENTS.md à la racine et dans chaque package :

# AGENTS.md (racine du monorepo)

## Structure
Monorepo Turborepo avec les packages suivants :
- packages/api — Backend Fastify
- packages/web — Frontend Next.js
- packages/shared — Types et utilitaires partagés
- packages/e2e — Tests end-to-end Playwright

## Règles
- Les modifications de packages/shared DOIVENT être 
  suivies d'un build de tous les packages dépendants
- Commande de build global : `turbo run build`
- Commande de test global : `turbo run test`

Et dans chaque sous-package :

# packages/api/AGENTS.md

## API Backend
- Framework : Fastify
- Validation : Zod (schémas dans src/schemas/)
- Les types de packages/shared sont importés via @myorg/shared
- Chaque nouvelle route nécessite un test dans __tests__/

Workflows multi-repos concrets

Ajout d’une feature transverse

"Nouvelle feature : système de favoris.
1. shared-types : Ajoute le type Favorite
2. api-service : CRUD /api/favorites avec auth
3. web-app : Bouton coeur sur les cartes produit
4. Crée une PR dans chaque repo avec le lien 
   vers les PRs des autres repos dans la description"

Migration d’API versionnée

"L'API v1 /users est dépréciée. Crée la v2 :
1. api-service : Ajoute les routes v2 avec le nouveau format
2. api-service : Marque les routes v1 comme deprecated (header)
3. web-app : Migre tous les appels de v1 vers v2
4. mobile-app : Migre tous les appels de v1 vers v2
5. docs : Mets à jour la documentation API"

Limites actuelles

Codex travaille repo par repo dans des sandboxes séparés. Il ne peut pas exécuter les deux repos ensemble (par exemple, lancer le backend et le frontend pour un test d’intégration). Pour les tests cross-repos, vous devez :

1. Merger les PRs individuelles
2. Lancer les tests d’intégration depuis votre CI/CD
3. Utiliser Codex pour corriger les éventuels problèmes détectés

Points clés à retenir

• Codex peut créer des PRs coordonnées sur plusieurs repositories
• Les types partagés sont un cas d’usage idéal pour le multi-repos
• Configurez AGENTS.md dans chaque package d’un monorepo
• Les tests d’intégration cross-repos restent à vérifier dans la CI/CD
• Documentez les dépendances entre repos dans AGENTS.md