Référence Architecture (Architecte d'Entreprise / Autorité de Conception)
Pour contextes régulés UE/France (banque, santé, défense). Les détails réglementaires évoluent : tout élément marqué « à vérifier » doit être contrôlé par rapport au texte officiel en vigueur avant utilisation dans un livrable.
Index des références
references/togaf-archimate.md— à lire lors de la structuration d'un effort d'architecture (phases ADM, livrables, gouvernance, revues de conformité) ou de la modélisation avec ArchiMate (couches, éléments, relations, points de vue). Chemin complet :${CLAUDE_PLUGIN_ROOT}/skills/architecture-reference/references/togaf-archimate.mdreferences/urbanisation.md— à lire lors de la production ou de l'utilisation de cartographies SI françaises (zones/quartiers/îlots, cartographies), d'un schéma directeur, d'une évaluation de portefeuille applicatif (TIME) ou d'un plan de rationalisation/décommissionnement. Chemin complet :${CLAUDE_PLUGIN_ROOT}/skills/architecture-reference/references/urbanisation.mdreferences/adr.md— à lire lors de la rédaction ou de la revue d'un enregistrement de décision d'architecture (ADR) ou d'une matrice de décision (Nygard, MADR, Y-statements, critères pondérés, exemples fictifs). Chemin complet :${CLAUDE_PLUGIN_ROOT}/skills/architecture-reference/references/adr.md
Modèles de livrables associés : ${CLAUDE_PLUGIN_ROOT}/skills/deliverables/templates/dat.md, interface-contract.md, flow-matrix.md.
Les détails réglementaires (RGPD, DORA, NIS2, HDS, II 901, IGI 1300…) se trouvent dans le skill sector-compliance et ses références sectorielles (${CLAUDE_PLUGIN_ROOT}/skills/sector-compliance/references/) ; ce skill ne couvre que les implications architecturales.
1. Rôle : Autorité de conception
Possède : les principes et standards d'architecture ; l'architecture cible et la feuille de route ; les décisions structurelles (ADR) ; la cohérence entre domaines et experts ; les dérogations avec date d'expiration ; les revues de conformité architecturale ; le registre de la dette technique au niveau architecture. Ne possède pas : l'acceptation du risque de sécurité (propriétaire du risque métier / autorité d'homologation, conseillée par RSSI) ; les décisions relatives aux données personnelles (responsable de traitement, conseillé par DPO) ; l'arbitrage budgétaire/calendaire (COPIL) ; les changements en production (CAB).
Points de contrôle de revue
| Point | Quand | Vérifications |
|---|---|---|
| G0 Cadrage | Note de cadrage | Adéquation avec l'architecture cible/feuille de route, options identifiées, périmètre réglementaire, classe de souveraineté des données |
| G1 Conception | DAT / brouillons de contrats d'interface | Conformité aux principes, NFRs quantifiés, motif d'intégration, propriété des données, architecture de sécurité, réversibilité |
| G2 Pré-construction | Conception figée | ADR acceptées, dérogations signées, matrice de flux complète, conception ops/DR |
| G3 Pré-mise en production | Avant le go/no-go | As-built vs DAT, dette contractée enregistrée, DR testé, registre DORA / carte de dépendances mise à jour |
Résultat d'une revue : conforme / conforme avec réserves (actions + dates) / dérogation (propriétaire du risque + expiration) / non conforme (bloquant).
2. Principes d'architecture
Format (style TOGAF) : Nom — Énoncé — Justification — Implications. Garder 10-15, chacun vérifiable lors d'une revue. Ensemble par défaut pour les contextes d'intégration régulée :
| # | Principe | Implication vérifiable |
|---|---|---|
| P1 | Continuité d'activité par conception | Chaque fonction critique a un RTO/RPO défini, atteint par conception et testé |
| P2 | Sécurité et vie privée dès la conception et par défaut (RGPD Art. 25) | Données classifiées (DICT) avant conception ; moindre privilège ; chiffrement en transit et au repos |
| P3 | Source unique de vérité par domaine de données | Chaque entité de données a un système maître et un propriétaire nommé ; les autres détiennent des copies gouvernées |
| P4 | Couplage faible via des interfaces gérées | Pas d'accès direct à la base de données d'une autre application ; tous les échanges via des APIs, messages ou fichiers contractés |
| P5 | Réutiliser avant d'acheter avant de construire | Les plateformes partagées existantes (MFT, API gateway, IAM, ordonnancement) utilisées sauf si un ADR dit autrement |
| P6 | Standards et formats ouverts | Protocoles/formats ouverts privilégiés ; propriétaires uniquement avec plan de réversibilité |
| P7 | Réversibilité et sortie | Chaque service externe a un plan de sortie ; données exportables dans des formats documentés |
| P8 | L'opérabilité est une exigence | Monitoring, logs, ordonnancement, redémarrage et DEX conçus avec la solution |
| P9 | Traçabilité et auditabilité | IDs de corrélation de bout en bout ; pistes d'audit conservées conformément aux exigences légales |
| P10 | Résidence et souveraineté des données par classification | Choix d'hébergement dérivé de la classe de données (voir §6) |
| P11 | Simplicité et rationalisation | Nouveau composant uniquement si aucun existant ne convient ; décommissionnement planifié avec chaque remplacement |
| P12 | Automatiser la chaîne de delivery | Infrastructure et déploiements comme du code, environnements reproductibles |
3. Architectures cible vs transition
- Baseline (état actuel), Cible (état futur à l'horizon, généralement 3-5 ans), Architectures de transition (plateaux : états intermédiaires stables, opérables, apportant de la valeur), Analyse d'écart (ce qui est ajouté, supprimé, modifié), Feuille de route (lots de travail, dépendances, dates de décommissionnement).
- Chaque transition doit être opérable de manière autonome (supportée, surveillée, couverte par le DR, documentée) — le projet peut s'arrêter là.
- Les ponts de coexistence (synchronisation temporaire, évitement de double écriture, couches anti-corruption) sont des composants de première classe : propriétaire, coût, date de suppression, entrée de dette.
- « Temporaire » sans date de suppression devient permanent : le refuser en G1.
- Privilégier la migration incrémentale (strangler fig : acheminer les fonctionnalités progressivement vers le nouveau système derrière une façade) plutôt qu'un remplacement big-bang lorsque le legacy est volumineux et mal documenté.
4. Architecture d'intégration (niveau macro)
La conception détaillée appartient à l'expert en intégration ; l'architecte définit le motif et les règles.
| Motif | Adapté à | Éviter quand | Points d'attention |
|---|---|---|---|
| Point à point | ≤ quelques flux stables, tactique | De nombreux consommateurs, changement fréquent | Spaghetti (liens n²), pas de monitoring central |
| Hub & spoke / EAI / ESB | Systèmes hétérogènes nombreux, transformations, gouvernance centralisée | Hub devient goulot d'étranglement/monolithe de logique métier | Garder la logique métier hors du bus |
| Transfert de fichiers via MFT | Batch, volume élevé, échanges partenaires, legacy (très courant en banque/IBM i) | Besoins temps réel | Contrôles d'intégrité, nommage, heures de coupure, renvoi, chiffrement, non-répudiation |
| API-led (couches système / processus / expérience) | Services réutilisables, canaux digitaux, APIs partenaires | Mouvement de données volumineux | Gestion des API, versioning, quotas, OAuth2/mTLS |
| Événementiel (pub/sub, event streaming, CDC) | Réactions découplées, propagation en temps réel, nombreux consommateurs | Cohérence transactionnelle forte requise entre systèmes | Ordonnancement, idempotence, évolution de schéma, rejeu, propriété des événements |
| Plateforme de données (DWH, lac, lakehouse, data mesh) | Analyse, reporting réglementaire, ML | Intégration transactionnelle opérationnelle | Lignage, qualité, rétention, ségrégation des données sensibles |
| MDM / Référentiels | Données de référence partagées (client, produit, organisation, identité patient) | Données avec un seul propriétaire naturel | L'effort de gouvernance est le vrai coût |
Règles empiriques : appels synchrones uniquement lorsque l'appelant a vraiment besoin de la réponse maintenant ; asynchrone par défaut entre domaines ; concevoir chaque flux pour l'échec (réessai avec backoff, dead-letter, rejeu, consommateurs idempotents) ; utiliser le motif outbox plutôt que les doubles écritures ; modèles de données canoniques uniquement dans un périmètre borné (les modèles canoniques à l'échelle de l'entreprise survivent rarement) ; versionner chaque contrat ; un ID de corrélation de bout en bout.
5. Exigences non fonctionnelles
Quantifier chaque NFR ; « haute disponibilité » n'est pas une exigence.
| Catégorie | Métriques/questions | Pièges |
|---|---|---|
| Disponibilité | % sur une période, heures de service, indisponibilité planifiée autorisée | Ignorer la chaîne de dépendances ; mesurer l'infra, pas le service |
| Continuité | RTO / RPO (DMIA / PDMA) par fonction métier, MTPD | RPO 0 promis avec réplication asynchrone ; redémarrage batch oublié |
| Performance | Débit, latence p95/p99, fenêtre batch, facteur de pic, croissance | Tester la moyenne, pas le pic ; pics de fin de mois oubliés |
| Scalabilité | Volumes à l'horizon, élasticité | Modèles de licence dont le coût croît de manière non linéaire |
| Sécurité | Classification DICT, IAM, chiffrement, journalisation, ségrégation | Sécurité ajoutée après conception |
| Opérabilité | Monitoring, alerting, logs, redémarrage, ordonnancement, automatisation | DEX rédigé après la mise en production |
| Observabilité | Traces, métriques, logs, corrélation, KPIs métier | Aucune vue de bout en bout à travers le middleware |
| Réversibilité | Plan de sortie, formats d'export, délai et coût de sortie | Uniquement contractuel, jamais testé |
| Interopérabilité | Standards (ex. ISO 20022 dans les paiements, HL7 FHIR dans la santé — vérifier les mandats sectoriels) | Dialectes locaux de standards |
| Conformité / résidence | Localisation des données, rétention, blocages légaux, audit | Sauvegardes et logs stockés en dehors de la zone convenue |
| Maintenabilité | Cadence de mise à niveau, dates de support fournisseur | Fin de support en cours de projet |
| Durabilité | Efficacité des ressources (directives RGESN d'écoconception en France — vérifier le statut) | Environnements non production surdimensionnés |
Aide-mémoire disponibilité (par an) : 99 % ≈ 3,65 jours ; 99,5 % ≈ 1,83 jours ; 99,9 % ≈ 8,76 h ; 99,95 % ≈ 4,38 h ; 99,99 % ≈ 52,6 min ; 99,999 % ≈ 5,3 min. Chaîne série : A = A1 × A2 × … ; paire redondante : A = 1 − (1 − A1)(1 − A2) (suppose des défaillances indépendantes — rarement totalement vrai). Cohérence RPO/RTO : RPO est borné par le mode de réplication et la fréquence des sauvegardes ; RTO inclut la détection, la décision, le basculement, la réparation des données, le rattrapage batch et la resynchronisation des partenaires — pas seulement le temps de basculement technique.
6. Stratégie cloud & souveraineté
Classifier d'abord, ensuite héberger : la classe des données détermine l'option d'hébergement.
| Classe de données / système | Options d'hébergement typiques (à vérifier par rapport aux règles en vigueur) |
|---|---|
| Publique / interne, non sensible | Cloud public acceptable avec contrôles standards |
| Données personnelles (RGPD) | Hébergement UE privilégié ; les transferts hors EEE nécessitent une base Chapitre V et une analyse d'impact du transfert |
| Données personnelles de santé (France) | Hébergeur certifié HDS requis (Code de la santé publique, Art. L.1111-8) ; le référentiel HDS récent ajoute des exigences de localisation des données dans l'EEE — vérifier la version actuelle et les dates de transition |
| Données d'une sensibilité particulière des services de l'État, opérateurs de l'État et GIP listés | Offre qualifiée SecNumCloud, ou certification UE/EEE qu'ANSSI reconnaît comme équivalente : loi SREN Art. 31 (2024), décret n° 2026-272 (14 avril 2026), arrêté du 12 août 2026 ; la doctrine « cloud au centre » (2021, mise à jour 2023) étend l'attente à d'autres SI de l'État — régime d'exemption dans ces textes |
| Diffusion Restreinte (DR) | Systèmes accrédités selon II 901 ; contraintes d'hébergement spécifiques — vérifier |
| Classifié (Secret / Très Secret, IGI 1300) | Infrastructure dédiée accréditée ; cloud public généralement exclu |
| Fonctions bancaires critiques ou importantes | Autorisées avec exigences DORA sur les tiers, règles d'externalisation (lignes directrices EBA) et notification au superviseur si nécessaire — vérifier |
SecNumCloud : qualification ANSSI des fournisseurs de services cloud selon le référentiel d'exigences v3.2 (8 mars 2022 ; la version approuvée par l'arrêté du 12 août 2026). Au-delà des exigences techniques de sécurité, son §19.6 protège contre les lois extraterritoriales non-UE : fournisseur établi dans l'UE, actionnariat non-UE plafonné à 24 % individuellement et 39 % collectivement, données stockées et service administré et supervisé depuis l'UE. Les labels marketing « souverain » ne sont pas une qualification : demander le certificat de qualification et son périmètre de service exact. Exposition extraterritoriale : évaluer le risque d'accès légal non-UE (ex. US CLOUD Act, FISA s.702) par rapport à la classe de données ; le chiffrement avec des clés détenues par le client (HSM/BYOK/HYOK) le réduit mais ne le supprime pas toujours. Clauses de réversibilité (contrat + architecture) : plan de sortie et période d'assistance ; export des données et métadonnées dans des formats ouverts documentés à un coût non prohibitif ; certificat de suppression ; documentation et export de configuration ; continuité de service pendant la sortie ; délais de préavis ; liste de sous-traitants ; droits d'audit. Le Data Act UE (Règlement (UE) 2023/2854, Chapitre VI) s'applique depuis le 12 septembre 2025 : les fournisseurs doivent faciliter le changement et ne peuvent facturer que leurs coûts réels de changement/sortie jusqu'au 12 janvier 2027, aucun après cette date. Facilitateurs d'architecture : charges de travail portables (conteneurs, IaC), bases de données standards ou chemins de migration documentés, éviter le couplage profond avec des PaaS propriétaires pour les fonctions principales sauf si un ADR l'accepte, test périodique de sortie (au moins export + restauration ailleurs). Options de migration cloud (6R/7R) : retirer, conserver, réhéberger, relocaliser, replateformer, refactoriser, racheter — décider par application à partir de l'évaluation du portefeuille (voir référence urbanisation).
7. Gestion de la dette technique
- Types : architecture (mauvais motif, couplage), obsolescence (versions en fin de support), code, données (qualité, doublons), opérationnel (étapes manuelles), documentation, sécurité (correctifs différés).
- Registre : élément, type, emplacement, cause (délibérée via ADR / accidentelle), intérêt (coût ou risque par période), principal (coût de correction), propriétaire, échéance, lien vers ADR/dérogation.
- Calendrier d'obsolescence : dates de fin de support fournisseur pour OS, DB, middleware, runtimes, versions ERP, releases IBM i ; signaler tout ce qui se termine dans les 24 mois.
- Financement : réserver une capacité explicite (communément cité 15-20 % de la capacité de delivery — spécifique à l'organisation) ; la dette issue d'une dérogation d'un projet est imputée à ce projet.
- La dette affectant les fonctions critiques est un risque ICT : la déclarer dans le cadre des risques, pas seulement dans les backlogs IT.
8. Risque ICT DORA d'un point de vue architecture
Règlement (UE) 2022/2554, applicable depuis le 17 janvier 2025, complété par des RTS/ITS. Les numéros d'articles ci-dessous sont indicatifs : les confirmer sur EUR-Lex avant de les citer dans un livrable.
| Sujet DORA | Contribution de l'architecture |
|---|---|
| Cadre de gestion des risques ICT (Art. 6) | Principes d'architecture, standards et architecture cible comme contrôles documentés |
| Identification (Art. 8) | Inventaire des actifs ICT et des actifs informationnels ; cartographie du bus… |
…[tronqué pour traduction]