ZAF / CHAPITRE 07 / 15

Architecture cible et fonctionnement de bout en bout

Édition publique de référence 1.0 · 5 novembre 2026 · Exemple institutionnel fictif. Aucun résultat client ou déploiement n’est revendiqué.

Dans ce chapitre
  1. 7.1 Recommandation
  2. 7.2 Vue logique
  3. 7.3 Parcours normal et refus
  4. 7.4 Concurrence
  5. 7.5 Livrables

7.1 Recommandation

La première cible proposée est une application modulaire, une base relationnelle faisant autorité et des traitements différés récupérables. Elle répond à l’équipe supposée et au besoin de cohérence transactionnelle ; ce n’est pas une règle universelle. Versions, autorisations et transitions restent proches des données de référence. Reporting et notification sont séparés logiquement car leurs délais et défaillances diffèrent.

7.2 Vue logique

Figure 7.1 · Cible logique et état faisant autorité
Cible logique et état faisant autoritéL’API valide l’état de référence. Le worker traite le travail validé pour notifications et rapports. Identité, pièces et reprise nécessitent d’autres frontières contrôlées.NavigateurBrouillons et commandesAPI applicativeDroits et versionsPostgreSQLÉtat, audit et outboxNotificationsLivraison différéeWorkerTravail récupérableReportingProjections versionnées
L’API valide l’état de référence. Le worker traite le travail validé pour notifications et rapports. Identité, pièces et reprise nécessitent d’autres frontières contrôlées.

Le navigateur transmet une commande authentifiée, une version attendue et un identifiant stable. L’API vérifie acteur, périmètre et transition. Une transaction conserve état, audit, résultat et intention de traitement différé. Le worker traite le travail validé. L’échec d’un email n’annule pas l’approbation. Le rapport indique source et période de traitement. Identité, pièces jointes et sauvegardes constituent aussi des frontières contrôlées.

7.3 Parcours normal et refus

ÉtapeRésultat normalRefus ou exception
SoumissionVersion reçue une seule foisDonnées invalides refusées
RevueActeur autorisé sur version actuelleMauvais périmètre refusé
ApprobationTransition atomiqueVersion périmée en conflit
ExécutionRéférence à l’autorisationAutorisation annulée ou changée refusée
RapportProjection rapprochéeCouverture manquante visible

Un refus métier peut être le bon fonctionnement du système. Il doit être distingué d’une panne technique ou d’un résultat encore inconnu.

7.4 Concurrence

Lire puis modifier sans condition ne protège pas la version approuvée. Choisir et tester mise à jour conditionnelle ou verrouillage. Définir périmètre, comparaison et conservation des clés de commande. L’acceptation couvre réponse perdue après validation, modification concurrente et arrêt du worker. Chaque scénario doit laisser l’état explicable.

7.5 Livrables

Fournir contexte, vue logique, transitions, frontières de confiance et scénarios d’échec. Chaque composant doit répondre à une exigence et posséder un responsable.