Moderniser un système d’information ne signifie pas automatiquement réduire son exposition aux cybermenaces.
Au contraire, une transformation SI fait souvent coexister plusieurs environnements : applications legacy, nouvelles architectures, interfaces temporaires, API, cloud, automatisation ou encore agents IA.
Le risque cyber ne disparaît donc pas avec l’ancien système. Il évolue et se déplace tout au long de la transformation.
Pour les organisations, l’enjeu consiste désormais à sécuriser trois dimensions simultanément :
- le legacy et ses hypothèses de sécurité historiques ;
- la coexistence entre l’existant et la cible ;
- l’architecture cible et les nouvelles technologies qu’elle introduit.
Un récent rapport américain sur la cybersécurité aéronautique illustre particulièrement bien cette problématique.
Le legacy peut rester opérationnel tout en devenant vulnérable
Le 21 septembre 2026, le Gouvernement Accountability Office américain (GAO) a publié un rapport consacré aux risques cyber pesant sur les communications aéronautiques de la Federal Aviation Administration.
Le constat est significatif : plusieurs systèmes restent exposés à des menaces liées au spectre électromagnétique, notamment le brouillage et le spoofing.
Le GAO relève notamment des évaluations de risques et de mesures de protection incomplètes ainsi que l’absence d’une capacité définie de surveillance et de détection en temps réel couvrant l’ensemble de ces menaces. Ces attaques peuvent perturber les communications aéronautiques, dégrader la connaissance de la situation et provoquer des perturbations opérationnelles. Gouvernement des États-Unis
Le sujet dépasse largement l’aéronautique.
Il met en évidence une réalité fréquente dans les grands systèmes d’information : un système peut continuer à remplir parfaitement sa fonction métier alors que son modèle de sécurité n’est plus adapté à son environnement.
Les architectures historiques ont parfois été conçues à une époque où certains réseaux étaient fortement isolés, où les utilisateurs étaient considérés comme fiables ou encore où les volumes d’interconnexions étaient beaucoup plus faibles.
La transformation doit donc commencer par une question simple :
Les hypothèses de confiance sur lesquelles repose notre SI sont-elles encore valables aujourd’hui ?
Le risque cyber est souvent maximal dans les interactions
Remplacer progressivement un système legacy implique rarement de passer instantanément d’une architecture A à une architecture B.
Pendant plusieurs mois, voire plusieurs années, les deux environnements peuvent coexister.
C’est alors qu’apparaissent :
- des interfaces temporaires ;
- des synchronisations de données ;
- des API supplémentaires ;
- des doubles traitements ;
- des comptes techniques ;
- des flux entre anciennes et nouvelles applications ;
- des règles de sécurité différentes selon les environnements.
Individuellement, le legacy et la cible peuvent être correctement sécurisés. Le problème peut se situer dans ce qui les relie.
Cette zone intermédiaire mérite donc une attention particulière lors d’une migration SI.
Une bonne cartographie de transformation ne devrait pas uniquement représenter les applications et les flux fonctionnels. Elle devrait également identifier les identités, dépendances, accès, protocoles et mécanismes de confiance utilisés entre les différents composants.
L’architecture cible crée elle aussi de nouveaux risques
Une architecture moderne n’est pas automatiquement une architecture plus sûre.
Cloud, API, micro services, automatisation, SaaS et intelligence artificielle peuvent améliorer la performance et l’agilité d’un système d’information. Mais ils augmentent également le nombre d’interactions et de dépendances à maîtriser.
Le raisonnement doit donc évoluer.
Il ne s’agit pas simplement de passer :
legacy risqué → cible sécurisée
mais plutôt de comprendre quels risques sont supprimés, transférés ou créés par chaque choix d’architecture.
L’IA introduit de nouveaux acteurs dans le SI
Les agents IA rendent cette question particulièrement concrète.
Lorsqu’un agent peut consulter des données, appeler une API, déclencher un processus ou modifier une information, la question de la cybersécurité dépasse la simple protection du modèle.
Il faut notamment déterminer :
- quelles données l’agent peut consulter ;
- quelles actions il peut réaliser ;
- avec quels droits ;
- comment ses actions sont tracées ;
- quelles décisions nécessitent une validation humaine ;
- comment ses accès peuvent être révoqués immédiatement.
L’agent devient en pratique un nouvel acteur du système d’information qu’il faut gouverner comme tel.
DLT et tokenisation : l’interopérabilité devient un enjeu cyber
Le secteur financier offre un autre exemple.
Le 21 septembre 2026, l’Eurosystème a lancé Pontes, une solution permettant le règlement en monnaie de banque centrale de transactions de gros sur des actifs tokenisés. Elle constitue une première étape de la stratégie européenne autour de la finance tokenisée. European Central Bank
Ces nouvelles infrastructures ne remplacent cependant pas immédiatement l’ensemble du SI bancaire.
Elles doivent communiquer avec les systèmes de paiement, référentiels, applications métiers et infrastructures existantes.
La Banque des règlements internationaux souligne justement que l’interopérabilité entre réseaux DLT reste complexe et que certains mécanismes de connexion entre réseaux, notamment les bridges, peuvent introduire de nouveaux risques opérationnels et affecter la résilience. Bank for International Settlements
La question devient donc moins :
« La blockchain est-elle sécurisée ? »
que :
« Comment sécuriser l’ensemble de la chaîne entre cette nouvelle infrastructure et le SI existant ? »
C’est un changement important dans la manière d’aborder le risque.
Le quantique impose déjà de penser la transformation cryptographique
Une autre évolution doit également être anticipée : la cryptographie post-quantique.
Le risque ne dépend pas de la disponibilité immédiate d’un ordinateur quantique capable de casser les mécanismes actuels.
Le NIST considère désormais que les organisations doivent commencer leur migration vers les nouveaux standards de cryptographie post-quantique et indique que trois standards sont déjà disponibles pour être implémentés. NIST
Cela pose un enjeu plus large de crypto-agilité : la capacité d’une organisation à remplacer ou faire évoluer ses mécanismes cryptographiques dans ses applications, protocoles, infrastructures et équipements sans interrompre son activité. NIST Sécurité Informatique
Pour les grands SI, cette évolution implique notamment de savoir où la cryptographie est utilisée aujourd’hui, quelles applications en dépendent et comment la faire évoluer progressivement.
Encore une fois, la cybersécurité rejoint directement l’architecture et la transformation SI.
Comment sécuriser une transformation SI ?
La cybersécurité doit couvrir toute la trajectoire du programme, et non intervenir uniquement au moment de la mise en production de la cible.
Six principes permettent de structurer cette approche.
1. Réexaminer les hypothèses de confiance du legacy
Identifier les mécanismes devenus fragiles : réseaux supposés isolés, protocoles anciens, authentification insuffisante, comptes techniques ou composants difficiles à maintenir.
2. Cartographier les interactions entre legacy et cible
Les flux temporaires doivent recevoir le même niveau d’attention que l’architecture définitive.
Chaque interface doit avoir un propriétaire, une justification, des contrôles et, lorsqu’elle est temporaire, une date de retrait.
3. Intégrer la sécurité dès la conception
Les exigences cyber doivent influencer les choix d’architecture dès le cadrage : gestion des identités, segmentation, chiffrement, journalisation, résilience et dépendances externes.
4. Gouverner les nouveaux acteurs du SI
Agents IA, automatisations et services tiers doivent disposer du minimum de droits nécessaires, avec des actions traçables et révocables.
5. Anticiper les évolutions technologiques
DLT, tokenisation et cryptographie post-quantique ne doivent pas être considérées indépendamment du reste du système d’information.
Leur intégration au SI existant fait partie du risque.
6. Mesurer la résilience plutôt que la seule conformité
Une organisation doit pouvoir répondre à plusieurs questions concrètes :
Pouvons-nous détecter une attaque ? La contenir ? Maintenir les fonctions critiques ? Basculer sur une solution alternative ? Reprendre rapidement l’activité ?
C’est cette capacité opérationnelle qui permet réellement d’évaluer la robustesse du système.
Du risque legacy au risque de transformation
Opposer legacy vulnérable et architecture cible sécurisée est donc trop simple.
Pendant une transformation, les risques peuvent se situer aussi bien dans l’existant que dans les interfaces de migration ou les nouvelles technologies déployées.
La bonne question n’est plus uniquement :
« Comment sécuriser notre legacy ? »
Elle devient :
« Comment démontrer que chaque étape de notre transformation réduit réellement le risque ? »
Cette approche implique de rapprocher les équipes architecture, transformation, exploitation et cybersécurité dès le début du programme.
Chez GROUPE BBU, nous considérons ainsi la cybersécurité comme une composante de la transformation : elle doit participer aux choix d’architecture, à la stratégie de migration, à la gouvernance et au modèle opérationnel, plutôt que constituer un chantier parallèle.
Pourquoi une transformation SI augmente-t-elle temporairement le risque cyber ?
Parce qu’elle multiplie souvent les systèmes, interfaces, flux de données et mécanismes d’accès pendant la période de coexistence entre legacy et architecture cible.
Le legacy est-il nécessairement moins sécurisé qu’une architecture moderne ?
Non. Une architecture ancienne peut être maîtrisée tandis qu’une architecture moderne mal configurée peut créer de nouvelles vulnérabilités. L’important est d’évaluer concrètement les risques, les dépendances et les mécanismes de sécurité de chaque environnement.
Quel est le principal risque pendant une migration SI ?
Il n’existe pas un risque unique. Les interactions entre legacy et cible méritent toutefois une vigilance particulière, car elles peuvent introduire des interfaces temporaires, des flux supplémentaires et des mécanismes de confiance difficiles à superviser.
Pourquoi intégrer la cybersécurité dès la conception ?
Parce que certaines décisions structurantes — architecture, identité, segmentation, flux, hébergement ou dépendances technologiques — deviennent beaucoup plus coûteuses à modifier une fois la solution déployée.