D5 · Scaling Across Teams and Systems

Ce domaine vaut 16 % de l’examen blanc — soit environ 8 items sur 50. C’est le cours « Scale Codex Across Governed Teams and Systems » rendu concret : coordonner des chantiers parallèles et intégrer leurs sorties en sécurité, standardiser la configuration sur de nombreux dépôts, câbler Codex dans les outils que vos équipes utilisent déjà, mesurer si le passage à l’échelle aide réellement, et reconnaître les modes de défaillance qui n’apparaissent qu’à l’échelle. L’examen récompense l’intégration sûre et la standardisation plutôt que le parallélisme brut.

Ce que vous devez savoir

Bien exécuter un agent (D2) diffère d’en exécuter beaucoup à travers une organisation. À l’échelle, vous coordonnez des chantiers parallèles et intégrez leurs sorties en sécurité — branches indépendantes, changements vérifiés, merges contrôlés — plutôt que de laisser les agents entrer en collision. Vous standardisez AGENTS.md sur les dépôts pour que le comportement soit prévisible partout. Vous intégrez Codex à la livraison via le Codex SDK, l’App Server, la GitHub Action et des intégrations avec GitHub, GitLab (bêta), Slack et Linear. Et vous mesurez à la fois l’adoption et la qualité, car plus d’activité d’agent ne signifie pas automatiquement plus de valeur. Les modes de défaillance caractéristiques — conflits de merge entre agents parallèles, dérive de config, changements non relus en volume, et confusion entre activité et résultats — sont tous testables.

Objectifs d’apprentissage

À l’issue de cette page, vous devriez être capable de :

1. Coordonner des chantiers parallèles et intégrer leurs sorties en sécurité.
2. Standardiser AGENTS.md et la configuration sur de nombreux dépôts.
3. Intégrer Codex à la livraison via le Codex SDK, l’App Server, la GitHub Action, et GitHub/GitLab/Slack/Linear.
4. Mesurer l’adoption et la qualité, pas seulement l’activité.
5. Reconnaître et atténuer les modes de défaillance du passage à l’échelle d’un agent sur de nombreux dépôts.

5.1 Chantiers parallèles et intégration sûre

L’échelle signifie plusieurs tâches Codex s’exécutant à la fois — à travers branches, dépôts ou équipes. La valeur est le débit ; le risque est l’intégration non sûre.

        ┌── workstream A (branch) ──┐
task ──►┤── workstream B (branch) ──┤──► VERIFY each ──► CONTROLLED MERGE ──► main
        └── workstream C (branch) ──┘     (tests, diff)   (review + CI gate)
              parallel, isolated

5.2 Standardiser AGENTS.md sur les dépôts

Un bon AGENTS.md (D2) rend un dépôt prévisible. À l’échelle, la cohérence entre dépôts est le levier : un ingénieur ou un agent passant d’un dépôt à l’autre devrait rencontrer les mêmes conventions, commandes de build/test et zones interdites.

La standardisation est ce qui transforme « Codex fonctionne sur mon dépôt » en « Codex fonctionne de la même façon sur tous nos dépôts », et c’est ce qui rend les chantiers parallèles sûrs à intégrer — parce que chacun a été produit sous les mêmes règles.

5.3 Intégration programmatique et à la livraison

Codex se branche sur la façon dont le logiciel est réellement livré.

5.4 Mesurer l’adoption et la qualité

À l’échelle, « plus d’activité Codex » n’est pas l’objectif — une livraison meilleure, plus rapide et sûre l’est. Mesurez les deux côtés.

ACTIVITY  ≠  VALUE
│              │
tasks run   review pass rate, defects avoided,
per week    security findings resolved, cycle time

Measure BOTH; a rise in activity with falling quality is a warning, not a win.

5.5 Modes de défaillance du passage à l’échelle d’un agent

Certains problèmes n’apparaissent qu’une fois de nombreux agents exécutés sur de nombreux dépôts. Connaissez le schéma et l’atténuation.

Cadre de décision

Utilisez SCALE SAFELY (SISM) : Standardiser, Isoler, Safe-merge, Mesurer.

Erreurs courantes

Défi de mise en situation

Scénario. Un groupe plateforme de 40 ingénieurs répartis sur 25 dépôts a adopté Codex. La direction est ravie : le nombre de tâches exécutées par semaine a triplé. Mais trois problèmes ont émergé : deux tâches Codex parallèles sur la même branche de fonctionnalité se sont écrasées mutuellement la semaine dernière ; les 25 dépôts ont dérivé, si bien que Codex utilise des commandes de build et des conventions différentes dans chacun ; et le taux de revert sur les PR mergées a discrètement grimpé pendant que personne ne surveillait la qualité. Un manager propose : « continuons à passer à l’échelle — les chiffres d’activité prouvent que ça marche — et nous corrigerons les problèmes au fil de l’eau ».

Trace de raisonnement d’expert.

1. La métrique phare est trompeuse. Un nombre de tâches par semaine triplé est de l’activité, pas de la valeur. Le taux de revert en hausse est le signal de qualité qui compte, et il bouge dans le mauvais sens — donc « les chiffres prouvent que ça marche » est exactement le piège activité-vs-résultats.
2. La collision est un échec d’isolation. Deux agents sur une branche se sont écrasés mutuellement parce que le travail n’était pas isolé. Le correctif est un chantier par branche/worktree, intégré via un merge contrôlé, en utilisant le cloud ou Ultra pour un vrai parallélisme.
3. La dérive est un échec de standardisation. 25 dépôts avec des commandes de build et des conventions différentes font que Codex se comporte de façon incohérente et rendent les sorties parallèles non sûres à intégrer. Standardiser un template AGENTS.md partagé et une configuration managée, avec des vérifications de dérive périodiques.
4. Le taux de revert est un échec de volume-non-relu / de qualité. Des reverts qui grimpent pendant que « personne ne surveillait » signifient que la porte de revue et la mesure de qualité ont toutes deux lâché sous le volume. Rétablir la porte de revue (auto-review comme preuve, pas remplacement) et mesurer la qualité aux côtés de l’adoption.
5. Rejeter « corriger les problèmes au fil de l’eau ». À l’échelle, les correctifs réactifs sont en retard sur les dégâts ; les atténuations sont structurelles (isoler, standardiser, safe-merge, mesurer).

Décision conforme à l’examen : traiter le taux de revert — pas le nombre de tâches par semaine — comme le signal de préparation ; isoler le travail parallèle par branche/worktree avec un merge contrôlé ; standardiser AGENTS.md et la configuration sur les 25 dépôts avec des vérifications de dérive ; rétablir la porte de revue et mesurer la qualité aux côtés de l’adoption. Pas « continuer à passer à l’échelle parce que l’activité est en hausse », pas de travail parallèle sur des branches partagées, pas laisser chaque dépôt diverger, pas de correctifs uniquement réactifs.

Pièges d’évaluation

Questions d’entraînement

Chaque item indique combien de réponses sélectionner. Essayez avant de révéler.

Points clés à retenir

• Le parallélisme est du débit ; la sûreté est l’isolation plus un merge contrôlé. Donnez à chaque chantier sa propre branche/worktree et vérifiez avant de merger.
• Standardisez AGENTS.md et la configuration sur les dépôts, avec des vérifications de dérive, pour que le comportement de l’agent soit prévisible partout.
• Faites correspondre l’intégration au travail : GitHub Action pour la CI GitHub, Codex SDK pour vos propres outils, App Server pour l’hébergement, et les intégrations GitHub/GitLab (bêta)/Slack/Linear pour leurs plateformes.
• Souvenez-vous que GitLab est en bêta lors de la planification d’un déploiement critique.
• Mesurez l’adoption et la qualité ; une activité en hausse avec une qualité en baisse est un avertissement, pas une victoire.
• Les modes de défaillance d’échelle — collisions, dérive de config, volume non relu, activité-comme-valeur, auth non gouvernée, dette de sécurité — nécessitent une atténuation structurelle, pas des correctifs réactifs.