Dans ce chapitre
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.
| Question | Position recommandée | Autorité |
|---|---|---|
| Premier investissement | Parcours d’approbation et reporting explicable | Sponsor métier |
| Responsabilités conservées | Règles, définitions, accès et preuves d’acceptation | Responsables institutionnels |
| Travail du fournisseur | Composants et exploitation sous contrats explicites | Achats et responsable système |
| Exclusions initiales | Approbations définitives hors connexion et services réglementés supplémentaires | Sponsor et responsable des risques |
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.