Dans ce chapitre
13.1 Choisir après la capacité
Comparer adéquation, compétences, sécurité, localisation, cycle de vie, reprise, intégration et coût de sortie. La familiarité aide sans prouver l’adéquation. Le scénario retient un backend modulaire, PostgreSQL et un worker récupérable. Langage et hébergement restent à valider. Kafka, Kubernetes et entrepôt séparé ne découlent pas automatiquement de l’ambition.
13.2 Correspondance
| Capacité | Option | Obligation |
|---|---|---|
| État transactionnel | PostgreSQL | Concurrence, mises à jour et reprise |
| Workflow | Backend modulaire | Tests métier et migrations |
| Travail différé | Outbox et worker | Reprises, doublons et blocages |
| Packaging | Conteneurs versionnés | Provenance et configuration |
| Reporting | Projections versionnées | Rapprochement et couverture |
13.3 Décisions documentées
| Décision | Recommandation | Coût accepté | Révision |
|---|---|---|---|
| ADR-001 | Application modulaire | Livraison commune | Équipes distinctes ou isolation mesurée |
| ADR-002 | Notifications différées | Délai et worker | Besoin de livraison plus strict |
| ADR-003 | Approbation en ligne | Attente pendant coupure | Politique de conflits approuvée |
| ADR-004 | Rapport quotidien | Retard d’un cycle | Décision demandant plus de fraîcheur |
Ce sont des recommandations illustratives. Une décision réelle nomme approbateur, date et preuves.
13.4 Coût total
Inclure découverte, réalisation, migration, licences éventuelles, hébergement, réseau, équipe, support, reprise et sortie. Une licence gratuite ne rend pas l’exploitation gratuite. Construire des fourchettes sous hypothèses explicites. Séparer changement initial et coût récurrent. Aucune économie ni tarification précise n’est inventée.
13.5 Réversibilité
Identifier formats d’export, propriété des contrats, éléments de reprise et connaissances nécessaires au changement de fournisseur. La remplaçabilité est une transition explicable et testable, pas une substitution instantanée.