L'architecture d'entreprise pour les RSSI et la sécurité

Conception de l'état cible technologique

La technology architecture doit traduire les scénarios de croissance en contrôles concrets de résilience, sécurité et coût.

Un état cible utile n'est pas un schéma figé. C'est un ensemble évolutif de garde-fous applicables dans les pipelines delivery.

• Définir des patterns de référence par criticité de charge
• Associer des contrôles de fiabilité et de sécurité à chaque pattern
• Revoir la dérive de l'état cible chaque trimestre avec architecture et plateforme

Le RSSI ne sécurise pas ce que l'organisation ne voit pas

Pour un responsable sécurité, l'architecture d'entreprise n'est pas un exercice de modélisation — c'est la carte indispensable avant toute décision de risque sérieuse. Quels systèmes supportent un service critique ? De quoi dépendent-ils ? Qu'arrive-t-il à ce service si un fournisseur ou un composant tombe ? Sans réponse à jour, segmentation, résilience et risque tiers relèvent de la devinette.

Cette page regarde l'EA sous l'angle de la sécurité : visibilité du parc et des dépendances, documentation DORA/NIS2, gouvernance et audit, résidence des données en UE. Elle est volontairement honnête — les affirmations sur Archilu se limitent à des fonctionnalités vérifiables, et l'EA est présentée comme une aide à la documentation et à la visibilité, pas une garantie de conformité.

Visibilité : le parc applicatif et ses dépendances ICT

Le risque vit dans les connexions. Un registre applicatif dit ce qui existe ; une cartographie des dépendances ICT dit comment ces systèmes se soutiennent et quels services métier ils sous-tendent. Ensemble, ils permettent de raisonner sur le rayon d'impact, les points de défaillance uniques et les systèmes qui méritent le plus d'attention.

Quand cette image vit dans un modèle connecté plutôt que dans des schémas épars, une analyse d'impact — « si ce système est compromis ou retiré, qu'est-ce qui est affecté ? » — devient une requête au lieu d'une enquête.

• Tenir un inventaire à jour des applications et des actifs
• Cartographier les dépendances ICT et les services qu'elles supportent
• Raisonner sur le rayon d'impact et les points de défaillance uniques

DORA et NIS2 : de la documentation, pas une promesse de conformité

Des régimes comme DORA et NIS2 attendent que les organisations connaissent leurs systèmes critiques, leurs dépendances et leur exposition aux tiers, et puissent le démontrer. C'est d'abord un problème de documentation d'architecture avant d'être un problème d'outil.

Archilu aide à garder cette documentation à jour — registre applicatif, cartographie des dépendances et historique des décisions de gouvernance — pour que la preuve soit défendable et actuelle. Il ne certifie pas la conformité et ne remplace ni votre évaluation, ni vos contrôles, ni votre conseil juridique. La checklist liée ci-dessous cadre ce qu'il faut documenter ; la responsabilité de la conformité reste la vôtre.

Gouvernance et piste d'audit au même endroit

Auditeurs et régulateurs ne demandent pas seulement « quelle est votre architecture » mais « qui a décidé cela, quand, et au regard de quelle politique ». Quand les décisions d'architecture, les principes et les approbations sont consignés avec le modèle, vous répondez avec une piste plutôt qu'en la reconstituant à partir de fils d'e-mails.

Pour un RSSI, cela compte doublement : cela raccourcit les audits, et cela signifie que les dérogations de sécurité et les acceptations de risque sont consignées là où vivent les systèmes concernés — pas perdues dans un outil de tickets que personne ne rouvre.

L'endroit où vit le référentiel est une décision de sécurité

Votre référentiel d'architecture est une cible de grande valeur : il décrit vos systèmes les plus sensibles et leurs points faibles. La question de l'hébergement n'est donc pas accessoire. Archilu propose un hébergement UE ou on-premise sous votre contrôle, qui répond directement aux enjeux de résidence des données et de souveraineté et garde cette carte sensible sous votre gouvernance.

Soyez clair sur le périmètre, cependant : l'EA apporte visibilité, dépendances, documentation et gouvernance. Elle ne remplace ni votre stack de détection, ni vos outils de vulnérabilités, ni votre réponse à incident — elle les rend mieux informés.

Partez de votre maturité, pas d'un argumentaire éditeur

Avant d'investir, voyez où en est réellement votre pratique. L'évaluation gratuite de maturité EA d'Archilu note dix dimensions et renvoie un plan d'action priorisé en environ dix minutes — un moyen concret pour un responsable sécurité de repérer les écarts de visibilité, de dépendances et de gouvernance qui comptent le plus, et de décider par quoi commencer.

KPIs de technology architecture

Suivez la santé d'architecture via des indicateurs de risque, fiabilité et efficience de coût.

• Atteinte des SLO sur services critiques
• Couverture des contrôles de sécurité par charge
• Impact des indisponibilités non planifiées sur les capacités métier
• Tendance des unit economics des plateformes cœur

Common mistakes

La dérive technologique vient souvent d'optimisations locales sans garde-fous enterprise.

• Dupliquer les capacités plateforme entre domaines
• Ne pas avoir de baseline identité, observabilité et sécurité
• Ne pas relier la capacité aux scénarios de croissance
• Traiter la fiabilité comme un sujet uniquement SRE

Practical checklist

Appliquez ces contrôles avant de généraliser les changements cloud et plateforme.

• Documenter une reference architecture par classe de charge
• Imposer par défaut les contrôles identité et logging
• Définir SLO et ownership incident sur services critiques
• Revoir coût, risque et résilience chaque trimestre