Modèle d'orchestration pour résorber les dépendances transverses entre modules (inspiré de repository.sync)

[shikanime]

Contexte

En relisant l'implémentation de repository.sync (module repository de apps/server-nestjs, issu de #2434), on constate que le couplage GitLab ↔ Vault n'est pas résolu par un appel direct d'un plugin à l'autre, mais par une orchestration au niveau du service. Cette approche pourrait servir de modèle pour résorber les dépendances transverses profondes entre modules (GitLab dépend de Vault, SonarQube / Harbor / ArgoCD dépendent de GitLab, etc.).

Le pattern observé

• Le service écrit l'état partagé (Vault : GIT_INPUT_PASSWORD) avant d'émettre l'événement repository.sync / project.upsert.
• Les plugins ne s'appellent jamais entre eux : le réconciliateur GitLab lit les credentials depuis Vault, il ne les reçoit jamais d'un autre plugin.
• Bus d'événements unique (AppEventsService) → hooks réactifs, réconciliation rejouable.
• Injection @Optional() de Vault : dégradation propre (log warning) au lieu d'un couplage dur.
• L'échec remonte en 422 côté appelant ; l'état en base reste commité (rejouable).

Questions ouvertes

• La règle d'ordonnancement (écrire l'infra partagée avant l'émission) doit-elle devenir un contrat documenté, ou rester implicite par service ?
• @Optional() suffit-il à l'échelle, ou faut-il une carte de capacités (quels plugins requièrent quelle infra) ?
• Ce pattern est dans server-nestjs : s'applique-t-il aussi au système de plugins Fastify d'apps/server, ou est-il propre à la réécriture NestJS ?

PR liée

#2434

[StephaneTrebel]

Pas sûr que ce soit encore d'actualité, si ?