Le besoin : rendre une décision approuvée traçable
Une institution fictive dispose d’un siège et de six antennes. Les demandes de dépenses circulent entre tableurs, emails et application existante. La finance rapproche des exports pour produire un rapport. Le besoin est de savoir quelle demande a été approuvée, par qui, sur quelle version et avec quelles données. Le premier choix porte sur l’autorité de la décision et non sur un fournisseur cloud.
| Contrainte | Hypothèse de travail | Preuve à obtenir |
|---|---|---|
| Échelle et équipe | 120 utilisateurs, 20 simultanés, deux ingénieurs | Liste des accès, charge représentative et capacité de support |
| Connectivité | Coupures de plusieurs heures possibles | Historique des incidents, équipements et alimentation |
| Données | Contrôle institutionnel des données sensibles | Classification, hébergement autorisé et conservation |
| Reprise | RPO envisagé : 24 h ; RTO : 4 h | Analyse d’impact et restauration chronométrée |
| Reporting | Rapport quotidien à 09 h, heure d’Afrique centrale | Définitions et rapprochement validés par le responsable |
01 / État actuel
Le parcours choisi est demande → revue du service → approbation financière → exécution → rapprochement. Dans ce scénario construit, les antennes attribuent des références différentes, les emails servent de preuve et les exports n’ont pas le même instant de référence. Un tableur corrigé peut remplacer la version effectivement approuvée. Ces constats ne décrivent aucune institution réelle.
02 / Évaluation
Une mission examinerait des demandes acceptées et refusées, testerait les droits et rapprocherait un rapport de ses transactions sources. Un entretien explique la pratique prévue ; les enregistrements et les tests permettent d’examiner la pratique réelle. La restauration doit être démontrée. Les inconnues restent explicites.
- Responsable métier : confirmer le circuit et l’autorité des exceptions.
- Finance : approuver les définitions, la période et les règles de rapprochement.
- Responsable système : démontrer les accès, les versions et la reprise.
- Responsable des données : valider classification, destinations et conservation.
03 / Écarts prioritaires
| Priorité | Écart du scénario | Risque | Vérification |
|---|---|---|---|
| P1 | Version approuvée non identifiée | Exécution différente de l’autorisation | Modifier une demande puis rejouer son circuit |
| P1 | Restauration non démontrée | Reprise trop lente ou incomplète | Restaurer une copie isolée et rapprocher les données |
| P2 | Définitions et périodes incompatibles | Rapports non comparables | Vérifier une période connue |
| P2 | Reprises sans dédoublonnage | Création de demandes en double | Répéter une commande après délai dépassé |
04 / Principes
- Un responsable et une source faisant autorité pour chaque fait métier.
- Les autorisations et transitions sont vérifiées côté serveur.
- L’approbation porte sur une version identifiée de la demande.
- Une nouvelle tentative ne crée pas une deuxième opération métier.
- La conservation et l’hébergement suivent une politique approuvée.
- La complexité doit correspondre à la capacité réelle d’exploitation.
05 / Architecture recommandée
Démarrer avec une application modulaire et une base relationnelle. Séparer les responsabilités de workflow, d’autorisation et de reporting tout en conservant une frontière transactionnelle cohérente. Ce choix répond à l’équipe et à la charge supposées ; il ne constitue pas une règle générale contre les microservices.
L’API authentifie la commande et vérifie droits et version attendue. Une transaction enregistre la transition, la trace d’audit et l’événement de boîte d’envoi. Un worker traite les notifications et les projections de reporting. L’échec d’un email n’annule pas une approbation déjà validée. Les consommateurs tolèrent les doublons ; la boîte d’envoi ne garantit pas à elle seule un traitement unique de bout en bout.
Un historique auditable n’est pas automatiquement inviolable. Les privilèges administratifs, la conservation et la protection des sauvegardes doivent être conçus. Le stockage des pièces jointes, l’identité et les sauvegardes sont des frontières supplémentaires omises de ce schéma simplifié.
La connectivité impose une règle de cohérence
La première phase conserve un brouillon local clairement marqué comme non transmis. Aucune approbation ou exécution hors connexion n’est définitive. Au retour du réseau, le client utilise un identifiant stable de commande et une version attendue. Une version périmée impose une nouvelle revue. Une réponse perdue est rapprochée par l’identifiant de commande. Une approbation finale hors connexion exigerait une politique de conflit et de délégation explicite.
06 / Choix technologiques
| Capacité | Option envisagée | Obligation associée |
|---|---|---|
| Workflow et API | Backend modulaire ; langage choisi avec les mainteneurs | Frontières métier, tests des droits et migrations |
| État transactionnel | PostgreSQL | Contraintes, concurrence et restauration vérifiées |
| Traitements différés | Boîte d’envoi et worker | Reprises, dédoublonnage et échecs visibles |
| Pièces jointes | Stockage protégé sous contrôle institutionnel | Accès, limites, conservation et sauvegarde |
| Déploiement | Conteneurs versionnés sur infrastructure autorisée | Correctifs, secrets, retour arrière et responsabilités |
| Reporting | Projections et rapprochements versionnés | Période, couverture des sources et anomalies visibles |
07 / Décisions et compromis
| Décision | Option écartée | Coût accepté | Condition de révision |
|---|---|---|---|
| ADR-001 : application modulaire | Microservices indépendants | Cycle de livraison commun | Équipes distinctes ou besoin d’isolation mesuré |
| ADR-002 : notifications différées | Envoi pendant la transaction | Délai et exploitation d’un worker | Exigence de livraison plus stricte démontrée |
| ADR-003 : brouillons hors connexion | Approbation finale hors connexion | Validation impossible pendant la coupure | Politique de conflits et délégation approuvée |
| ADR-004 : reporting quotidien | Analyse en streaming | Retard d’un cycle | Décision nécessitant des données plus fraîches |
Kafka, Kubernetes et un entrepôt séparé ne sont pas des exigences initiales dans cet exemple. Leur coût d’exploitation doit répondre à un besoin mesuré de débit, d’isolation, de livraison indépendante ou d’historisation.
08 / Vérification et progression
| Phase | Livrable | Preuve de sortie |
|---|---|---|
| Découverte | Cartographie, échantillon et exigences | Définitions et responsables validés |
| Conception | Schémas, modèle et décisions | Parcours normal, refusé et interrompu examinés |
| Pilote | Une antenne et un type de demande | Droits, concurrence, reprises et rapprochements vérifiés |
| Reprise | Exercice de restauration | Durée et complétude conformes aux objectifs approuvés |
| Extension | Déploiement progressif et transfert | Support, exceptions et fraîcheur démontrés |
Trois scénarios vérifient les promesses : répéter une commande après un délai dépassé sans créer de doublon ; refuser une approbation sur une ancienne version ; arrêter le worker puis vérifier la reprise des notifications après une approbation valide. Ces scénarios vérifient le comportement plutôt que la seule présence des composants.
09 / Synthèse de décision
L’investissement proposé vise un circuit d’approbation faisant autorité et un reporting explicable. L’hébergement, la conservation, la continuité des antennes et les objectifs de reprise restent à arbitrer par l’institution. Aucune économie, réduction de fraude ou disponibilité n’est annoncée sans mesure initiale et pilote.