Dans cette section
- 1.1 Finalité de l’architecture institutionnelle
- 1.2 Mandat d’architecture
- 1.3 Promesse et résultats institutionnels
- 1.4 Institution et écosystème
- 1.5 Acteurs, préoccupations et autorité
- 1.6 Capacités, services et chaînes de valeur
- 1.7 Responsabilité et modèle de fonctionnement
- 1.8 Preuves et hypothèses
- 1.9 Principes institutionnels
- 1.10 Exemple institutionnel
- 1.11 Risques et décisions ouvertes
- 1.12 Pièces d’architecture
- 1.13 Passage au Livre II
- 1.14 Liste de revue
- 1.15 Décision avant progression
1.1 Finalité de l’architecture institutionnelle
L’architecture institutionnelle explique comment une organisation accomplit son mandat à travers capacités, responsabilités, information, services et relations. Les logiciels sont des réalisations possibles ; leur présence ne prouve pas la cohérence de l’institution. Cette section fonde la bibliothèque ZAF et les décisions qui précèdent le Livre II. Elle est un brouillon de travail. Elle ne déclare ni l’achèvement des huit livres, ni une revue externe, ni une adoption institutionnelle. La question initiale est : que doit accomplir l’institution, sous quelle autorité, avec quelles informations et quelle responsabilité en cas d’échec ?
1.2 Mandat d’architecture
Le mandat définit sponsor, périmètre, autorité, accès et livrables. L’architecte recommande une délégation sans posséder nécessairement le pouvoir de l’accorder.
| Élément | Décision | Preuve conservée |
|---|---|---|
| Sponsor | Autorité qui engage le travail | Sponsorship et escalade |
| Périmètre | Institution, service ou parcours concerné | Frontières et exclusions |
| Droits de décision | Autorité des politiques, risques et investissements | Responsables et délégations |
| Accès | Données, personnes et environnements autorisés | Périmètre d’évaluation |
| Livrables | Décisions soutenues par le travail | Registre des pièces attendues |
| Acceptation | Validation des faits et des recommandations | Responsabilités de revue |
Le mandat n’autorise pas automatiquement des tests intrusifs, des exports complets ou la publication de données institutionnelles. Toute autorité incertaine reste une question ouverte.
1.3 Promesse et résultats institutionnels
La promesse décrit ce sur quoi les acteurs doivent pouvoir compter, sans nommer un produit. Pour un service d’approbation, une demande acceptée possède une origine, une décision autorisée, un état explicable et une voie de correction ou de reprise. Séparer résultat utilisateur, décision métier et mesure technique. Une interface rapide ne prouve pas une décision juste ou rendue dans le délai institutionnel.
| Question | Preuve candidate | Limite |
|---|---|---|
| État faisant autorité accessible ? | Parcours et historique | L’échantillon ne prouve pas tous les services |
| Décision explicable ? | Version, autorité et motif | Un statut seul est insuffisant |
| Correction permise ? | Circuit d’amendement | L’ingénierie ne crée pas la politique |
| Reprise possible ? | Exercice vérifié | Sauvegarde configurée différente de reprise démontrée |
Les objectifs chiffrés suivent analyse d’impact, coûts et capacité d’exploitation. Ils ne doivent pas être inventés avant mesure.
1.4 Institution et écosystème
L’institution comprend personnes, politiques, financement, délégations, propriétaires d’information, partenaires et tâches manuelles. Un registre papier ou un appel de confirmation appartient au fonctionnement réel. Une architecture de service, d’institution et d’écosystème national exige des autorités différentes. La capacité technique ne résout pas seule la coopération entre institutions.
Cette vue sépare mandat, responsabilités métier et réalisation technique. Elle ne prescrit ni microservices ni équipes distinctes.
1.5 Acteurs, préoccupations et autorité
Un registre relie acteur, préoccupation et décision. « Direction » ne suffit pas lorsque plusieurs autorités divergent.
| Acteur | Préoccupation | Contribution |
|---|---|---|
| Utilisateurs | Accès, clarté et correction | Valider le parcours complet |
| Responsable métier | Mandat et résultat | Approuver le sens et le périmètre |
| Propriétaire des données | Sens, usage et conservation | Approuver les définitions |
| Responsable système | Exploitation et reprise | Accepter la responsabilité opérationnelle |
| Autorité des risques | Exposition résiduelle | Accepter ou imposer un traitement |
| Équipe de réalisation | Faisabilité et vérification | Produire les preuves techniques |
Plusieurs rôles peuvent être réunis, mais conflits et contrôles critiques restent explicites. Une responsabilité vide ne se transfère pas implicitement au fournisseur.
1.6 Capacités, services et chaînes de valeur
Une capacité décrit ce que l’institution sait accomplir. Un service présente un résultat utilisable. Une chaîne de valeur relie les activités nécessaires. Un écran n’est donc pas automatiquement une capacité. Pour une approbation : recevoir, examiner, autoriser, exécuter et rapprocher. Identité et notification soutiennent le parcours sans posséder sa politique. Documenter aussi refus, retrait, amendement et interruption.
1.7 Responsabilité et modèle de fonctionnement
Si deux systèmes peuvent déclarer indépendamment la même demande approuvée, l’institution possède des autorités concurrentes. Nommer le propriétaire du fait et les relations entre copies, projections et corrections.
| Distinction | Décision institutionnelle | Conséquence technique |
|---|---|---|
| Référence et copie | Propriété du sens et de la correction | Identifiants, versions et traçabilité |
| Capacité commune et règle locale | Règles partagées | Contrats plateforme et frontières métier |
| Délégation et accès général | Qui agit, où et jusqu’à quand ? | Autorisation limitée et cycle des accès |
| Résultat et santé des composants | Promesse aux utilisateurs | Signaux de parcours et réponse opérationnelle |
Le partage doit réduire la duplication sans absorber toutes les décisions métier. L’autonomie doit préserver des règles cohérentes.
1.8 Preuves et hypothèses
Distinguer observation, témoignage, hypothèse et recommandation. Une plainte indique un problème vécu sans prouver sa cause technique. Une contradiction dans un échantillon ne représente pas un taux global. Conserver source, période, autorisation, interprétation et incertitude. Minimiser les copies. Chaque élément cible doit répondre à un objectif, un constat ou une responsabilité.
1.9 Principes institutionnels
| Principe | Sens | Conséquence |
|---|---|---|
| Finalité avant technologie | Le mandat gouverne l’investissement | Produits après exigences et responsabilités |
| Une autorité par fait | Correction attribuée | Copies avec source et fraîcheur |
| Responsabilité explicite | Confiance attribuable | Aucun service critique sans responsable |
| Réalité locale | Réseau et personnel comptent | Complexité adaptée à l’exploitation |
| Preuve avant maturité annoncée | Installation différente de résultat | Acceptation par comportement observé |
| Évolution avec justification | Préserver les raisons | Options, conséquences et déclencheurs conservés |
Ces principes sont proposés pour revue. Une institution adopte leur applicabilité et son mécanisme d’exception.
1.10 Exemple institutionnel
Une institution fictive possède un siège, six antennes et une petite équipe technique. Tableurs, emails et rapports manuels ne permettent pas de relier sûrement l’exécution à la version autorisée. La recommandation institutionnelle consiste à établir approbation faisant autorité, propriété des faits d’exécution et définitions du reporting. Kafka ou Kubernetes ne sont pas encore décidés.
| Référence | Constat ou décision | Prochaine preuve |
|---|---|---|
| OBS-01 | Conventions différentes dans le scénario construit | Échantillons autorisés |
| DEC-01 | Un propriétaire du cycle de demande | Responsable et transitions convenus |
| DEC-02 | Approbation finale en ligne au départ | Acceptation de l’attente pendant coupure |
| OPEN-01 | Objectif de reprise non engagé | Impact et faisabilité testée |
Cet exemple n’est pas une réalisation client et ne revendique aucun gain mesuré.
1.11 Risques et décisions ouvertes
Localisation, conservation, délégation, interruption tolérable, fournisseur et financement opérationnel peuvent modifier la solution. Les rendre visibles avant réalisation. Le registre relie cause, conséquence, preuve, traitement et autorité d’acceptation. Une inconnue critique peut justifier de la découverte avant investissement. L’architecte ne doit pas accepter le risque à la place de l’autorité institutionnelle.
1.12 Pièces d’architecture
| Identifiant | Pièce | Preuve d’acceptation |
|---|---|---|
| ZAF-I-01-A01 | Mandat | Périmètre et autorités enregistrés |
| ZAF-I-01-A02 | Registre des acteurs | Préoccupations et décisions attribuées |
| ZAF-I-01-A03 | Promesse et scénarios | Résultats utilisateur, métier et techniques distingués |
| ZAF-I-01-A04 | Capacités et responsabilités | Autorité critique non concurrente |
| ZAF-I-01-A05 | Preuves et incertitudes | Constats traçables et limites visibles |
| ZAF-I-01-A06 | Principes et décisions | Justifications et révisions conservées |
Une adaptation du dossier doit expliquer les omissions plutôt que masquer la responsabilité correspondante.
1.13 Passage au Livre II
Le Livre II transforme les décisions institutionnelles acceptées en architectures de référence, standards technologiques et responsabilités d’ingénierie. Il ne remplace pas le mandat.
| Entrée institutionnelle | Réponse du Livre II | Question |
|---|---|---|
| Capacité et propriétaire | Architecture de référence | Autorité préservée ? |
| Politique d’information | Architecture données et sécurité | Traçabilité et correction possibles ? |
| Continuité et exploitation | Infrastructure et opérations | Équipe capable de reprendre ? |
| Gouvernance | Décisions technologiques | Changements révisables ? |
Le chapitre Kubernetes du Livre II est conservé. Son applicabilité suit une décision d’adoption ; son existence ne l’impose pas à chaque projet.
1.14 Liste de revue
- Périmètre explicite.
- Mandat, recommandation et approbation distingués.
- Préoccupations reliées aux décisions.
- Propriétaires des capacités et informations nommés.
- Parcours refusés, modifiés et interrompus inclus.
- Preuves distinctes des hypothèses.
- Choix technologiques après décisions institutionnelles.
- Risques et prochaines preuves attribués.
- Pièces identifiées et révisables.
- Entrées du Livre II explicites.
Cette liste ne prouve pas une conformité institutionnelle. Enregistrer version, réviseur, périmètre, constats et décisions de traitement.
1.15 Décision avant progression
La prochaine section est Contexte institutionnel et préoccupations des acteurs. Elle développe modèle de contexte, registre des préoccupations et plan de découverte. La publication de ce brouillon ne constitue pas son acceptation. Le passage à un statut accepté suit le processus de revue documenté dans la bibliothèque.