La DSA, Direction de la Stratégie et de l'Architecture : ce qu'elle regarde dans un SI
Domaines, applications, flux, environnements, versions de frameworks : jusqu'où descend une direction de l'architecture ? Ce qu'elle décide, ce qu'elle encadre, ce qu'elle laisse aux équipes.
« Il faut passer en comité d’architecture. » Pour un développeur ou un DevOps, c’est souvent une boîte noire. Voici qui sont ces gens, jusqu’où ils regardent, et comment travailler avec eux.
La fonction est répandue dès qu’un SI compte quelques centaines d’applications : banques, assurances, télécoms, énergie, grands offices publics. Le sigle, lui, ne l’est pas. Selon les maisons, on dit Direction Architecture et Urbanisation, Architecture d’Entreprise, ou Design Authority pour sa partie comité. Elle est le plus souvent rattachée à la DSI.
« DSA » désigne aussi le Digital Services Act, le règlement européen sur les plateformes en ligne. Rien à voir.
Quatre missions, en boucle
Comment elle découpe un SI
Quatre couches, avec deux vocabulaires pour la même idée : l’urbanisation, très ancrée dans les entreprises francophones, et TOGAF dans le monde anglo-saxon.
L’urbanisation emprunte son image à la ville, et elle en tire une règle d’or :
Jusqu’où descend-elle ?
Elle décide en haut, encadre au milieu, et consolide en bas sans gérer le détail.
Cliquez sur un niveau pour voir ce qu’elle en fait :
Oui, c'est son cœur de métier.
- Elle découpe : paiements, crédit, client, conformité.
- Elle désigne l'application maîtresse de chaque donnée.
- Elle dit quel domaine a le droit d'appeler quel autre.
Avec le Domain-Driven Design, elle dessine les grandes frontières et les équipes affinent les bounded contexts à l'intérieur.
Oui, au niveau du portefeuille. Pour chaque application, le référentiel indique :
- le nom, le domaine et la fonction ;
- le propriétaire métier et le responsable technique ;
- la criticité ;
- le cycle de vie : en construction, en service, à remplacer, à retirer ;
- les grandes briques techniques.
Outils courants : MEGA HOPEX, LeanIX, Ardoq, Sparx EA, ou un tableur bien tenu. Méthode de tri : TIME pour Tolerate, Invest, Migrate, Eliminate.
Oui, et en détail. C'est là qu'elle descend le plus bas : retirer une application sans connaître ses flux, c'est découvrir le lendemain qu'un rapport réglementaire n'est plus alimenté.
Le schéma juste après montre une ligne de sa matrice des flux. Au Maroc, ces flux comptent aussi pour la loi 09-08 (CNDP) et, dans les banques, pour les exigences de Bank Al-Maghrib.
Non, elle fixe seulement les règles. La liste des environnements revient à la production, à la plateforme ou au projet. Elle impose par exemple :
- un minimum : développement, recette, préproduction, production ;
- l'isolement réseau de la production ;
- pas de données de production non anonymisées en recette ;
- un environnement de reprise pour les applications critiques.
Pas le détail, mais l'obsolescence, oui. Spring Boot 3.3.4 ou 3.4.1, ce n'est pas son sujet. Combien d'applications critiques tournent sur une version sans correctifs de sécurité, si.
Le détail vient de la CMDB, des SBOM et des outils de scan : elle lit le résultat, elle ne le produit pas.
Le passage en comité
Les six questions qui reviennent presque toujours :
| Question | Ce qu’on regarde | |
|---|---|---|
| 1 | Où ? | le domaine, et le chevauchement avec l’existant |
| 2 | Quels flux ? | ce qui entre et sort, et les données sensibles |
| 3 | Quelles technologies ? | leur présence au référentiel, sinon la dérogation et sa date de fin |
| 4 | Où ça tourne ? | sur site, cloud public ou souverain, hébergement des données |
| 5 | Quelle criticité ? | disponibilité, sauvegarde, reprise après sinistre |
| 6 | Qui s’en occupe après ? | exploitation et maintenance une fois le projet terminé |
DSA et DevOps : du document au contrôle automatique
La critique est connue : une architecture « tour d’ivoire », et un comité mensuel face à des équipes qui déploient en continu. Voici le partage qui marche le mieux :
Trois autres habitudes aident :
- Des chemins balisés : un modèle de projet déjà conforme (CI, observabilité, authentification).
- Des décisions dans le dépôt : les Architecture Decision Records, de courts fichiers Markdown versionnés avec le code.
- Des architectes embarqués : un architecte de domaine aux rituels de l’équipe en apprend plus qu’en relisant cinquante pages.
Pour aller plus loin sur ces contrôles : la signature d’images et l’admission avec Kyverno.
En résumé
| Sujet | La DSA… |
|---|---|
| Domaines | décide du découpage et des frontières |
| Applications | tient le portefeuille, la criticité, le cycle de vie |
| Flux | les cartographie en détail et les fait valider |
| Données | désigne les systèmes maîtres et les référentiels |
| Socle technique | publie la liste des technologies et leur statut |
| Environnements | fixe des principes, ne gère pas la liste |
| Versions de frameworks | suit l’obsolescence consolidée, pas le détail par application |
| Code, configuration | n’intervient pas, sauf via des règles automatisées |