Les produits sensibles à la conformité deviennent difficiles bien avant de devenir volumineux. Le problème n’est généralement pas le nombre de lignes, mais la dispersion silencieuse des règles de workflow entre contrôleurs, formulaires, templates et services ponctuels.
Symfony fonctionne très bien dans ce contexte lorsqu’on modélise le workflow délibérément au lieu de l’assembler au fil de l’eau.
Le problème
À mesure que les règles de workflow évoluent, les équipes ajoutent des contrôles d’éligibilité, des décisions de notification et des garde-fous de transition dans la couche la plus proche du changement du moment. L’application continue de marcher, mais plus personne ne peut expliquer le système avec confiance pendant un incident ou un audit.
Ce qui casse en pratique
- La même règle d’éligibilité existe dans le contrôleur, le template et un worker.
- L’interface admin laisse croire qu’une action est possible alors que le backend la rejettera.
- Les échecs de notification ou de document restent couplés à une action admin en temps réel.
- Modifier une règle métier devient risqué parce qu’elle a été recopiée dans plusieurs chemins.
Décisions de conception
- Centraliser les transitions de workflow dans des services domaine afin de nommer explicitement les actions et leurs gardes.
- Garder les contrôleurs fins et concentrés sur le transport pour que le comportement métier ne dérive pas dans la couche HTTP.
- Déplacer documents et notifications dans des jobs de fond afin que l’interface admin reste réactive et récupérable.
- Exposer clairement l’état du workflow côté admin afin que support et opérations puissent agir sans deviner la logique backend.
Arbitrages
- Des services domaine explicites apportent plus de structure qu’une implémentation centrée contrôleurs.
- Les effets de bord asynchrones renforcent la résilience mais exigent monitoring de queue et outils de replay.
- La visibilité de l’état admin prend du temps produit, mais réduit fortement l’ambiguïté opérationnelle.
Patterns de production
- Services de garde pour l’éligibilité et les contrôles sensibles à la conformité.
- Services domaine qui persistent l’état avant d’émettre du travail asynchrone.
- Vues opérateur pour documents échoués, notifications en attente et actions rejouables.
- Audit trail sur chaque transition importante du workflow.
Ce que je ferais différemment
- Ajouter plus tôt des tests automatisés sur les transitions négatives et cas limites d’éligibilité.
- Introduire plus vite une visualisation de workflow pour les opérateurs.
- Isoler plus explicitement les familles d’erreurs documentaires et notifications au lieu de les agréger dans un même seau async.