Dossier ZAF — lecture continue

01 · Finalité exécutive et promesse institutionnelle

1.1 Objet du dossier

Un dossier d’architecture permet de décider ce que l’organisation construit, quelles responsabilités elle conserve et quelles preuves justifient l’investissement. Un catalogue technologique ne répond pas à ces questions. ZAF relie finalité, capacités, contraintes et décisions dans un document révisable. Cette édition publique présente une méthode et une institution fictive : un siège, six antennes et une équipe technique supposée de deux personnes. Le premier périmètre couvre les demandes opérationnelles et le reporting. Paiements, identité nationale et déploiement national en sont exclus. Ce document ne reproduit pas un blueprint client et ne revendique aucun résultat déployé.

1.2 Promesse à protéger

Une demande acceptée doit avoir une origine identifiable, une décision autorisée, une version traçable et un résultat récupérable. « Acceptée » signifie reconnue par le service faisant autorité, pas seulement sauvegardée sur un appareil déconnecté. Une demande peut être retardée ou refusée avec un motif. Elle ne doit pas être dupliquée par une reprise, conserver une approbation après modification ou disparaître entre l’application et le rapport. Ces invariants sont à valider et à démontrer.

1.3 Évaluation exécutive

L’écart du scénario est la capacité à fournir un service cohérent dans toutes les antennes : responsabilités d’approbation, définitions des rapports et reprise restent à démontrer. La recommandation consiste à stabiliser un parcours et ses capacités communes avant de multiplier les applications.

1.4 La plateforme comme ville

Les domaines sont des bâtiments aux usages différents. Identité, intégration, livraison et observabilité représentent des services communs. La gouvernance fixe les règles ; l’équipe plateforme assure les capacités convenues. Cette analogie ne prescrit ni un microservice ni une équipe par capacité.

1.5 Pièces attendues

• Finalité, périmètre et exclusions approuvés.
• Promesse et scénarios d’acceptation.
• Responsables métier, données, système et risques nommés.
• Hypothèses et décisions ouvertes enregistrées.

1.6 Point de décision

La découverte commence lorsque le sponsor valide le parcours et attribue les responsabilités. L’achat d’un produit ne doit pas être approuvé sur la seule apparence du schéma cible.

02 · Contexte institutionnel et capacités métier

2.1 Partir de la décision métier

L’institution doit autoriser une opération, exécuter ce qui a été approuvé et expliquer les résultats. La capacité décrit ce qui doit rester possible malgré un changement de logiciel, d’organisation ou de fournisseur. Le parcours étudié couvre soumission, revue du service, approbation financière, exécution et rapprochement. Refus, retrait et amendement font partie du besoin. Le seul parcours réussi ne suffit pas.

2.2 Acteurs et autorité

Un intitulé de rôle ne prouve pas son autorité. Distinguer politique, délégation et droits réellement configurés. Le fournisseur ne décide pas des délégations pour simplifier le code.

2.3 Capacités et responsabilités

2.4 Contraintes du terrain

Examiner réseau, alimentation, langues, appareils partagés et accès de maintenance dans les antennes retenues. « Faible débit » ne suffit pas : documenter les conditions et l’interruption tolérable. Le scénario propose des brouillons hors connexion et des approbations finales en ligne. L’attente est un coût métier à comparer au risque de décisions contradictoires. La finalisation hors connexion exige une politique distincte de délégation et de résolution des conflits.

2.5 Livrables et validation

Produire registre des acteurs, parcours complet, carte des capacités et registre des contraintes. Les valider avec demandeurs, approbateurs, opérateurs et finance. Tout désaccord reçoit un responsable et un point de résolution.

03 · Évaluation de l’existant et registre des preuves

3.1 Distinguer constat, témoignage et hypothèse

Un utilisateur qui juge un rapport peu fiable fournit un témoignage. Un rapport échantillonné impossible à rapprocher constitue un constat. Supposer le même problème partout reste une hypothèse. Le registre conserve cette distinction. Le scénario repose sur des tableurs, approbations par email, application existante et exports manuels. Il ne décrit pas une investigation réelle. Le choix de l’échantillon et de la fenêtre de test dépend du risque et des accès autorisés.

3.2 Reconstituer une opération complète

Pour des demandes autorisées, suivre contenu soumis, autorité, version approuvée, exécution et inclusion dans le rapport. Signaler les ruptures de preuve. Minimiser les copies, masquer les données sensibles et convenir de leur conservation.

3.3 Examiner l’exploitation réelle

Cartographier identité, bases, intégrations, traitements, déploiements, sauvegardes et support. Inclure les contournements manuels : un tableur envoyé après l’échec d’un export fait partie du fonctionnement réel. Les tests de droits incluent accès permis et interdits dans le périmètre convenu. Examiner configuration, secrets et retrait des accès. Aucun test perturbateur ou extraction sensible ne se déduit d’une simple revue.

3.4 Mesurer avant de promettre

Un échantillon n’établit pas un résultat institutionnel global. Le dossier doit annoncer ses limites.

3.5 Dossier de preuves

Livrer inventaire expurgé, trace du parcours, registre des preuves et questions ouvertes. Chaque constat renvoie à une preuve ou une hypothèse. Le responsable système confirme les faits ; l’architecte assume l’interprétation.

04 · Analyse des écarts et priorisation des risques

4.1 Un écart se mesure à un résultat convenu

L’absence d’un outil n’est pas automatiquement un écart. Si l’exécution ne peut pas être reliée à l’autorisation, l’écart concerne l’intégrité de la décision. Un moteur de workflow peut contribuer au traitement, sans définir à lui seul le problème. Distinguer faiblesse et incident : une modification non autorisée possible n’est pas une modification démontrée.

4.2 Classer conséquences et inconnues

Ces priorités ordonnent un exemple ; elles ne représentent pas une notation institutionnelle validée.

4.3 Respecter les dépendances

Construire le rapport avant de définir l’état faisant autorité peut figer une mauvaise interprétation. Étendre un service non récupérable augmente l’exposition. Commencer par autorité et reprise, vérifier un parcours puis élargir. Une inconnue peut bloquer la conception : localisation des données, durée des coupures, règles de continuité. Associer chaque inconnue à la décision empêchée et à la preuve attendue.

4.4 Comparer les traitements

Pour G-01, comparer une extension contrôlée de l’application existante à un remplacement complet. L’extension limite parfois la migration, si les invariants peuvent être vérifiés. Le remplacement se justifie lorsque propriété, tests ou intégrations empêchent une extension sûre. Pour G-02, l’achat d’un produit de sauvegarde ne suffit pas. Prévoir accès protégés, état récupérable, procédure isolée et responsable capable de démontrer la reprise.

4.5 Acceptation et clôture

• Constat et référence de preuve.
• Options, coûts d’exploitation et recommandation.
• Test de clôture observable.
• Risque résiduel, autorité d’exception et déclencheur de revue.

L’architecte recommande ; le responsable institutionnel autorisé accepte le risque résiduel. Un ticket terminé ne constitue pas la preuve de clôture.

05 · Principes d’architecture et scénarios de qualité

5.1 Un principe doit orienter une décision réelle

« Sécurisé, scalable et moderne » ne permet pas d’arbitrer. Un principe indique règle, justification, conséquence et procédure d’exception. Il doit survivre au remplacement d’un produit. Dans l’exemple, autorité, traçabilité et reprise priment sur la multiplication des composants distribués. La distribution reste possible lorsqu’un besoin et une capacité d’exploitation la justifient.

5.2 Écrire des scénarios vérifiables

Préciser acteur, événement, contexte, réponse et mesure. Séparer délai logiciel et attente d’une décision humaine.

Ces objectifs sont des hypothèses. Ils deviennent des engagements après analyse d’impact, coûts et preuve de faisabilité.

5.3 Arbitrer les tensions

L’autorité en ligne préserve la cohérence mais interrompt une antenne pendant une coupure. L’approbation hors connexion maintient l’activité au prix de conflits possibles. Documenter l’arbitrage : le cache ne définit pas l’autorité. De même, une conservation illimitée peut faciliter l’enquête mais contredire les obligations de suppression. Choisir les preuves nécessaires, leurs accès et leur durée autorisée.

5.4 Réviser les exceptions

Chaque exception indique motif, responsable, durée et condition de revue. Un principe est utile lorsqu’il permet d’expliquer un choix et d’écarter une option inadaptée.

06 · Domaines métier et capacités de plateforme partagées

6.1 Séparer les responsabilités

Le domaine métier possède le sens et les règles de son activité. La plateforme partagée fournit une capacité réutilisable. La technologie réalise cette responsabilité ; l’infrastructure l’héberge. Ces catégories ne doivent pas être confondues. Dans l’exemple, demandes possède les versions, opérations les faits d’exécution et finance les définitions de rapprochement. L’identité authentifie ; elle ne décide pas seule si un acteur peut approuver une demande donnée.

6.2 Frontières

6.3 Partager sans bloquer

Chaque capacité commune a un contrat : service rendu, exploitant, accès et changements à coordonner. La notification reçoit une intention d’envoi ; elle ne devient pas l’autorité de l’approbation. Une petite équipe peut réaliser ces frontières par des modules dans un seul déploiement. Le dessin n’impose pas des microservices. Une séparation d’exécution exige un besoin et une capacité de support.

6.4 Gouvernance fédérée

Les règles communes couvrent identité, audit, compatibilité et transfert opérationnel. Les domaines conservent leurs politiques. Les exceptions sont attribuées et révisables. Une projection de reporting doit indiquer sa source et sa fraîcheur. La modifier directement pour corriger un total contournerait le propriétaire du fait.

6.5 Validation

Livrer carte des domaines, catalogue partagé, dépendances et procédure d’arbitrage. Rejouer un amendement entre demandes, opérations et finance. Chaque responsable doit expliquer son autorité et ses limites.

07 · Architecture cible et fonctionnement de bout en bout

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

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

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.

08 · Architecture des données, propriété et reporting fiable

8.1 Attribuer l’autorité

Le schéma traduit une définition mais ne lui donne pas son autorité institutionnelle. Nommer propriétaire du sens, responsable des exceptions et exploitant technique. La version appartient au domaine demandes, l’exécution aux opérations et le contrat de rapport à la finance.

8.2 Modèle d’information

Définir champs sensibles, pièces jointes, copies et données autorisées en test. La conservation des sources n’autorise pas une rétention illimitée.

8.3 Traçabilité source-rapport

Distinguer date métier, arrivée et publication. Une opération de lundi transmise mercredi ne doit pas changer de sens parce que sa date d’import est utilisée. Les corrections suivent une politique approuvée.

8.4 Contrat et qualité

Définir granularité, états inclus, période, devises, sources attendues et retards. Sur une période connue, rapprocher les enregistrements éligibles des données acceptées et exceptions identifiées, avec des ensembles exclusifs.

• Références absentes visibles et attribuées.
• Reprises sans duplication des faits.
• Corrections versionnées et testées.
• Couverture des sources publiée.
• Succès du traitement distinct de la justesse du résultat.

8.5 Évolution analytique et IA

Une projection quotidienne répond au scénario initial. Un entrepôt séparé ou du streaming exige un besoin d’historisation, d’isolation ou de fraîcheur démontré. L’IA demande un problème défini, des usages permis, un jeu d’évaluation, une analyse des erreurs et une supervision humaine. Une pipeline propre ne prouve pas qu’un modèle convient.

8.6 Acceptation

Propriétaire des données : définitions et conservation. Finance : rapprochement. Ingénierie : reprises et corrections. Le dossier expose les limites de qualité avant utilisation.

09 · Intégration, API et contrats événementiels

9.1 Commande et fait

Une commande demande à une autorité de décider. Un événement décrit un fait validé sous une autorité nommée. Un broker ne rend pas un fait valide. ApproveRequest vise le domaine demandes. RequestApproved n’est émis qu’après une transition valide. Le service de notification ne peut pas modifier la décision.

9.2 Contrat explicite

9.3 Validation et livraison

Enregistrer état et intention d’envoi dans une transaction. Le worker traite le travail validé et conserve sa progression. Une livraison peut réussir alors que son accusé de réception se perd : des répétitions restent possibles. Prévoir dédoublonnage ou effets idempotents. Définir l’ordre nécessaire par objet métier et le traitement d’un prédécesseur manquant. Une exigence d’ordre global peut créer une coordination inutile.

9.4 Compatibilité

Changer le sens d’un montant approuvé peut casser un consommateur même sans changer la structure du message. Documenter propriétaire, version, exemples, erreurs et retrait des anciennes versions. L’intégration vérifie identité, données permises, limites, délais, reprises et support. Une clé API ne remplace pas un accord de responsabilité.

9.5 Vérification

• Répéter une commande après délai dépassé.
• Refuser une même clé avec contenu différent.
• Tolérer la livraison répétée d’un événement.
• Définir le traitement des versions incompatibles.
• Récupérer le travail après arrêt du worker.

Le livrable est un catalogue de contrats vérifiables, avant le choix éventuel d’un gateway ou broker.

10 · Sécurité, frontières de confiance et souveraineté des données

10.1 La sécurité est un modèle de responsabilités

L’authentification établit une identité présentée ; l’autorisation décide de son action sur un objet et dans un périmètre. Le chiffrement protège certaines frontières. Aucun mécanisme ne suffit seul à établir la confiance institutionnelle. Un hébergement local peut divulguer des données par les journaux, exports de support, télémétrie ou sauvegardes. La souveraineté concerne aussi les flux, usages et responsabilités.

10.2 Frontières

10.3 Concevoir selon les menaces

Examiner usurpation, action interservice non autorisée, répétition, contenu modifié et altération des preuves. Décrire actif, acteur, entrée et conséquence. Inclure récupération des comptes, secrets techniques, administration, consultation d’audit et réponse aux incidents. Les journaux ne doivent pas contenir de mots de passe ou données sensibles sans nécessité autorisée.

10.4 Souveraineté et fournisseurs

Le propriétaire approuve classification, destinations et usages. L’autorité juridique ou politique définit les obligations applicables. L’architecte traduit ces exigences en choix vérifiables. Vérifier sauvegardes, identité, email, supervision et support avant de dire « entièrement local ». L’hébergement local n’est pas une garantie de sécurité sans capacité de mise à jour et de reprise.

10.5 Acceptation

Fournir vue de confiance, matrice d’accès, cycle des secrets, conservation et escalade. Tester parcours permis et interdits, retrait des accès et récupération protégée. Attribuer tout risque restant.

11 · Infrastructure, livraison et continuité du service

11.1 Définir les contraintes d’exploitation

Choisir l’infrastructure après localisation autorisée, charge, disponibilité, reprise et support. Le contrôle local est ici une exigence candidate à valider. Deux conteneurs sur un même hôte ne protègent pas d’une panne de cet hôte. Une réplication n’est pas une sauvegarde. Chaque promesse demande un modèle de défaillance et un exercice.

11.2 Vue de déploiement candidate

La vue distingue accès, traitement, données de référence et copies de reprise protégées. Elle n’impose pas un cluster haute disponibilité sans équipe capable de l’exploiter. Hôtes, alimentation, réseau et stockage seront dimensionnés selon les objectifs approuvés.

11.3 Reprise et coût

Un objectif devient un engagement lorsque périmètre, dépendances, personnel et coûts sont approuvés.

11.4 Livraison

Relier révision, artefact, configuration, migration et vérifications. Tester compatibilité et droits selon le risque. Distinguer retour applicatif, correction en avant et restauration des données.

11.5 Exercice et acceptation

Simuler une panne dans un environnement isolé autorisé. Mesurer détection, décision, restauration, rapprochement et reprise. Une vérification sans pièces jointes ou clés nécessaires ne prouve pas la récupération complète. Livrer déploiement, inventaire des défaillances, procédure de version, politique de sauvegarde et runbook. Nommer les responsables et accepter le risque résiduel.

12 · Gouvernance, responsabilité plateforme et exploitation

12.1 Organiser les décisions

La gouvernance nomme qui décide, fournit les preuves, exploite et accepte une exception. Elle doit correspondre aux personnes disponibles. Dans l’équipe fictive de deux ingénieurs, plusieurs rôles peuvent être réunis. Les responsabilités restent distinctes et les décisions critiques nécessitent un contrôle adapté. Une capacité plateforme n’impose pas un département séparé.

12.2 Responsabilités

Une cellule vide ne transfère pas la responsabilité au fournisseur. Le contrat précise délégations et responsabilités conservées.

12.3 Cycle de décision

Un enregistrement conserve contexte, preuves, options, recommandation, conséquences et déclencheur de revue. Distinguer proposé, accepté, remplacé et retiré. Une modification locale peut recevoir une revue légère ; un contrat interdomaines ou une destination sensible demande une autorité plus large. Adapter la revue aux conséquences.

12.4 Exploiter après transfert

Définir horaires, support, escalade, accès, correctifs et exercices de reprise. La réponse à l’incident comprend communication et rapprochement des résultats incertains. Le runbook précise prérequis, droits, actions, vérifications et escalade. Le tester avec une autre personne si possible.

12.5 Validation

Livrer droits de décision, contrats de service, exceptions temporaires et responsabilités opérationnelles. Un incident simulé doit trouver un décideur et une réponse, pas seulement un organigramme.

13 · Choix technologiques, économie et décisions

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

13.3 Décisions documentées

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.

14 · Trajectoire de transition, vérification et acceptation

14.1 Avancer par preuves

La feuille de route ordonne dépendances et risques. Les durées et budgets seront convenus après définition des accès et du périmètre. Découvrir, concevoir un parcours, piloter dans une antenne, démontrer la reprise puis étendre. Un import réussi ne prouve pas la conservation du sens métier.

14.2 Phases

14.3 Migration

Nommer la source faisant autorité à chaque étape. Ne pas permettre deux approbations indépendantes sans règle de rapprochement. Prévoir correspondance des références, anomalies, bascule et arrêt contrôlé. Une archive incomplète garde sa provenance et ses limites. Ne pas fabriquer des approbations absentes pour compléter l’historique.

14.4 Acceptation

Conserver état initial, version, environnement et résultat. Une démonstration locale ne prouve ni capacité de production ni conformité institutionnelle.

14.5 Transfert

Documenter responsabilités, accès, procédures, support, limites et prochaine revue. L’acceptation dépend des preuves convenues. Une phase peut être arrêtée lorsque ses hypothèses échouent.

15 · Évolution future et dossier de décision exécutive

15.1 Préserver les principes, réviser les réalisations

Une architecture durable ne fige pas une technologie pour plusieurs décennies. Elle conserve finalité, autorité, sens des données et historique des choix. Le déclencheur d’évolution indique pourquoi l’option actuelle devient insuffisante. La cible modulaire peut durer ou être décomposée. Les deux trajectoires sont valables si elles reposent sur des preuves.

15.2 Déclencheurs

Aucun déclencheur n’impose automatiquement un produit.

15.3 Dossier exécutif

Présenter promesse, écarts, cible recommandée, options, coûts à établir, questions ouvertes et preuve du prochain passage. Dans l’exemple, la direction décide localisation et conservation, délégation, interruption tolérable, reprise et moyens d’exploitation. Ces responsabilités ne se délèguent pas à un dessin.

15.4 Ensemble documentaire

15.5 Utilisation en mission

Une revue ciblée ne promet pas de documenter toute une institution en une courte séance. Elle définit frontière, profondeur et preuves disponibles, puis les livrables pertinents. Un parcours peut produire un dossier compact ; une plateforme institutionnelle peut exiger plusieurs volumes. Cette édition illustre un niveau de raisonnement. Ses recommandations fictives demandent adaptation, autorité et validation avant usage réel.

15.6 Revue finale

Relier recommandations aux objectifs ; nommer les propriétaires ; expliciter options et inconnues ; vérifier exploitation et reprise ; rendre visibles les décisions de direction. Le dossier est prêt lorsque ces questions ont des réponses utilisables, pas seulement lorsque toutes les pages sont remplies.