Modernisation du SI : la cybersécurité et la conformité by design

Le SI Legacy, le maillon faible de votre cybersécurité

---

Les systèmes d’information légacy (ou hérités) cumulent de potentielles failles jamais corrigées ; comme des correctifs impossibles à appliquer, des technologies qui ne sont plus supportées, des dépendances logicielles non maîtrisées, l’absence de journalisation exploitable et des architectures en silo incompatibles avec le Zero Trust. Naturellement, les cyber-criminiels les ciblent en priorité. À cela est venue se greffer l’IA, avec une telle vitesse fulgurante qu’il était en effet difficile d’anticiper. Et dans la grande majorité des organisations dans lesquels nous intervenons, les agents IA et autres LLM en production ont souvent été déployés par les métiers sans passer par la DSI ni le RSSI. Mais voilà, ces systèmes IA accèdent directement au SI, manipulent des données sensibles et génèrent du code en volume, sans gouvernance, sans audit, sans traçabilité.

Les outils de sécurité que vous utilisez aujourd’hui (Ndl SAST, DAST, SIEM et EDR) ont été conçus avant les agents IA et les LLM. Ils ne voient pas ce qu’ils font, ni où ils accèdent, ni ce qu’ils exfiltrent. Dans la quasi-totalité des environnements financiers et industriels où mes équipes interviennent, les systèmes IA en production ne sont ni résilients, ni auditables, ni sous supervision humaine.

Brice Leffe

Cybersecurity Practice Manager

Les 6 facteurs de risque prioritaires lors d’une modernisation SI

1. Agents IA déployés hors gouvernance

82 % des DSI déclarent que leurs collaborateurs créent des agents et des applications IA plus rapidement que leur capacité à en assurer la gouvernance. Le risque ? Des accès directs au SI, des identités machines sans principe de moindre privilège et aucun contrôle sur ce qu’ils exécutent. Source : IT Social Shadow IT agentique, mars 2026

2. Code généré par IA non audité

Aujourd’hui les développeur utilisent Copilot, Claude ou Cursor au quotidien. Du code est produit en volume mais avec des vulnérabilités que vos outils SAST et DAST classiques ne détectent pas car ils n’ont pas été conçus pour analyser les modèles spécifiques du code généré par LLM. L’ANSSI elle-même identifie l’injection de vulnérabilités dans le code source généré par IA comme un vecteur d’attaque documenté. Source : ANSSI Recommandations de sécurité pour un système d’IA générative, 2024

3. Flux RAG et LLM tiers non vérifiés

L’utilisation de services d’IA non approuvés par l’entrepise est désormais classé comme premier comportement à risque dans les organisations françaises (75 % des entreprises membres du CESIN). Les données indexées dans vos bases vectorielles (les données que vous fournissez à vos assistants IA) et transmises à des modèles tiers sont très rarement soumises à une évaluation de souveraineté ou de criticité et c’est un risque direct de conformité RGPD, DORA et AI Act. Source : CESIN 11e baromètre OpinionWay, janvier 2026

4. Systèmes legacy non patchés

L’ANSSI recense près de 50 000 CVE en 2025, soit une hausse de 18 % par an. Le délai entre la publication d’une vulnérabilité critique et son exploitation active est passé sous les 5 jours alors que la majorité des organisations appliquent des cycles de patch mensuels voire trimestriels. Sur un équipement legacy en fin de support, cette fenêtre de réaction n’existe tout simplement plus. Source : ANSSI Panorama de la cybermenace 2025, mars 2026

5. APIs non sécurisées issues du legacy

Lors des projets de migration vers le cloud, les APIs héritées sont exposées sans avoir été auditées au préalable. Ces points d’entrée non documentés sont absents de la cartographie de sécurité et, bien entendu, ce qui n’est pas cartographié ne peut pas être gouverné. L’ANSSI constate une augmentation significative des incidents liés aux interconnexions cloud mal sécurisées dans son Panorama 2025. Source : ANSSI Panorama de la cybermenace 2025, mars 2026

Absence de supervision centralisée

Sans journalisation exploitable ni SOC adapté, les cyber criminels pénètrent tranquillement dans votre SI pendant des semaines, voire des mois, avant d’être détectés. Le cas France Travail en est un parfait exemple dramatique. Selon le parquet de Paris, les hackers ont eu accès aux systèmes du 6 février au 5 mars 2024, soit près d’un mois d’activité non détectée. Ce n’est qu’au moment d’un transfert massif de 25 gigaoctets de données que les alarmes se sont enfin déclenchées. Les données personnelles de 43 millions de personnes ont été potentiellement exposées dont les numéros de sécurité sociale, les adresses et les identifiants. Ce qui n’est pas supervisé ne peut pas être détecté et ce qui n’est pas détecté ne peut pas être enraillé.

Sources : ZATAZ Cyberattaque France Travail, analyse détaillée, 2024 et LeMagIT Cyberattaque France Travail, état des lieux, mars 2024

DSI, ce que NIS2, DORA et l’AI Act vous impose

---

2026 impose un cadre réglementaire d’une ampleur inédite pour les DSI et RSSI qui vous demande de repenser complètement la gouvernance et la sécurité du SI dans sa globalité. S’engager dans un chantier de modernisation de votre SI sans intégrer NIS2, DORA, RGPD et AI Act dès la conception, est une gageure. Nous sommes face à des obligations concrètes avec des délais non négociables, des sanctions financières dissuasives et, pour la première fois, une responsabilité personnelle des dirigeants engagée.

Moderniser sans se conformer, c’est choisir son risque. Les DSI qui traitent encore la conformité comme un chantier à part s’exposent doublement, à la menace cyber d’un côté, au régulateur de l’autre. Et depuis NIS2, ce n’est plus seulement le SI qui est en jeu, c’est leur responsabilité personnelle.

— France Titin-Snaider, Directrice Conseil Conformité & Directrice Harington Impact

France Titin-Snaider

Directrice Conseil Conformité & Directrice Harington Impact

NIS2, la fin de la déclaration, le temps de la preuve

NIS2 couvre désormais 18 secteurs critiques et s’applique à toutes les organisations. L’ANSSI a publié le 17 mars 2026 le Référentiel Cyber France (ReCyF), le cadre qui liste les mesures NIS2 à mettre en place dès maintenant sans attendre la promulgation de la loi Résilience prévue pour l’été 2026. Certes encore non obligatoire à date, il constitue une bonne base de travail et les entités qui l’appliquent pourront s’en prévaloir en cas de contrôle ANSSI. Le changement de fond est est que sous NIS1, il suffisait de déclarer des mesures alors que sous NIS2, vous devez les démontrer, les documenter et les tenir à jour. Et ceci rend les SI legacy structurellement non conformes.

Ce que NIS2 impose concrètement :

• Responsabilité personnelle des dirigeants (article 20) : le comité de direction approuve désormais les mesures de gestion des risques cyber. Le COMEX engage désormais sa responsabilité.
• Sanctions dissuasives : jusqu’à 10 M€ ou 2 % du CA mondial pour les entités essentielles, 7 M€ ou 1,4 % pour les entités importantes.
• Notification d’incident sous contrainte horaire : pré-signalement à l’ANSSI sous 24 h, rapport intermédiaire sous 72 h, rapport final sous 1 mois. Un calendrier impossible à tenir sans journalisation centralisée et procédures éprouvées.
• Registre des prestataires IA : DORA impose de recenser et d’auditer tous vos fournisseurs IT y compris les LLM tiers et les outils SaaS traitant des données financières.

AI Act, vos modèles IA sont peut-être classés haut risque

Pour les secteurs financiers et régulés, l’AI Act classe systèmes IA à haut risque les modèles de scoring crédit, de tarification assurance et d’analyse de solvabilité. Auditabilité, traçabilité des décisions, contrôle des données d’entraînement, supervision humaine sont obligatoires. Et dans la grande majorité des environnements où nous intervenons, aucune de ces conditions n’est remplie.

Modernisation SI, la matrice des risques cyber

---

Moderniser le SI, c’est aussi l’exposer. Chaque projet de transformation ouvre une fenêtre de risque que les cybercriminels savent exploiter. La coexistence legacy/cloud non sécurisée, les APIs de bridge non auditées et les agents IA interconnectés au SI sans gouvernance sont autant de brèches spécifiques à la phase de transition. Aussi critiques que les vulnérabilités legacy, elles sont pourtant souvent absentes des cartographies de sécurité. La matrice ci-dessous recense les expositions prioritaires à traiter avant, pendant et après votre migration SI.

Modernisation SI, le security-by-design

---

Appréhender la sécurité en fin de projet est une erreur qui peut vous coûter cher ! Une vulnérabilité découverte en production coûte en moyenne 6 fois plus cher à corriger qu’en phase de conception. Dans un programme de modernisation SI, chaque sprint non sécurisé est une dette qui s’accumule … et que les attaquants ne manqueront pas d’exploiter. Le Security-by-Design permet de livrer vite et sans faille.

DevSecOps et Shift Left : embarquer la sécurité dans chaque livraison

Le DevSecOps intègre les contrôles de sécurité dès l’écriture du code, la gestion des dépendances et la construction des artefacts. Ainsi, aucune nouvelle brique (API, microservice, agent IA, composant cloud-native) ne peut être mis en production sans passer par un pipeline sécurisé et audité. Voici les contrôles :

1. SAST adapté IA : Les outils classiques ne détectent pas les vulnérabilités du code généré par Copilot, Cursor ou Claude. Des outils SAST et DAST spécifiques aux patterns LLM sont indispensables.
2. SCA (Software Composition Analysis) : Audit des dépendances open-source et de la chaîne applicative des agents IA. Pour sécuriser, cartographier est indispensable.
3. Secrets scanning : Détection des identifiants, clés API et tokens codés en dur y compris dans les configurations d’agents IA et les manifests d’infrastructure.
4. IaC Security : Contrôle des templates Terraform, Helm et manifests Kubernetes avant tout déploiement.

Zero Trust, l’architecture pour SI hybride

Le Zero Trust repose sur le principe qu’aucun utilisateur, aucun équipement, aucun agent IA n’est digne de confiance par défaut. Pour les DSI en transformation cloud, cela va au delà du choix d’architecture, c’est LE cadre de référence à adopter. Il s’implémente progressivement, en commençant par les identités et les accès privilégiés.

1. Identités vérifiées en continu : MFA obligatoire, RBAC contextualisé, principe du moindre privilège appliqué aux comptes humains et aux identités machines des agents IA.
2. Accès granulaires et temporaires : Pas d’accès persistant, chaque session est autorisée, journalisée et auditée y compris pour les agents IA autonomes connectés au SI.
3. Segmentation des flux : Le trafic est contrôlé entre chaque composant legacy, cloud, API, données. L’interconnexion non documentée devient impossible sur le plan architectural.
4. Observabilité continue : Chaque accès est journalisé, corrélé et analysé en temps réel, y compris les comportements des modèles IA en production (Un vecteur de dérive que les SIEM classiques ne savent pas surveiller.

IA et cybersécurité, les 4 angles morts que vos outils actuels ne couvrent pas

---

Pilier 1 AI Code Security : qui audite le code généré par IA ?

Vos développeurs utilisent Copilot, Claude ou Cursor au quotidien. Du code est produit en volume avec des vulnérabilités que les scanners SAST et DAST traditionnels ne détectent pas car ils n’ont pas été conçus pour les spécificités du code généré par LLM. La chaîne de dépendances des agents IA (AI Supply Chain Security) est une autre surface d’attaque rarement auditée et rarement cartographiée.

Pilier 2 MCP Security : les agents IA sans gouvernance

Les agents IA déployés sans contrôle ont des accès directs à votre SI, des identités machines sans gouvernance et aucune supervision de ce qu’ils exécutent. Les communications entre agents via le protocole MCP sont rarement contrôlées ni auditées. C’est l’une des deux surfaces d’attaque les plus fréquentes dans les environnements financiers et industriels où nos équipes interviennent.

Pilier 3 AI Quality & Governance : supervision humaine et traçabilité

DORA exige que les systèmes IA en production soient résilients, auditables et sous supervision humaine. Dans la quasi-totalité des environnements que nous rencontrons, ces trois critères ne sont pas respectés : pas de monitoring comportemental continu, pas de traçabilité exploitable des décisions, pas de dispositif human-in-the-loop structuré sur les modèles critiques. Et c’est une non-conformité.

Pilier 4 AI Data Access : souveraineté des données et RAG

Connaissez-vous tous les LLM tiers qui traitent des données financières ou des données clients de votre organisation ? Dans la plupart des cas auxquels nous sommes confrontés, les flux RAG et de fine-tuning alimentent des modèles tiers sans que les conditions de traitement ni la souveraineté des données aient été vérifiées. Et c’est un angle mort que le régulateur commencera à sanctionner.

Les organisations qui réussissent leur migration cloud-native sont celles qui ont embarqué la sécurité à chaque étape, pas celles qui l’ont traitée comme un chantier à part en fin de projet.

Brice Leffe

Cybersecurity Practice Manager, Harington

6. Sécuriser la nouvelle couche d’infrastructure avec le Cloud Native Security

La modernisation SI avec des architectures cloud-native (conteneurs, Kubernetes, micro-services, serverless / à Lire Microservices vs Serverless, quelle est la meilleure approche pour vous ?) permet de gagner en agilité mais elle ouvre une surface d’attaque que les équipes sécurité ne maîtrisent pas toujours. Voici les 5 points à contrôler.

1. Hardening des clusters : Namespaces, network policies, admission controllers (OPA/Gatekeeper), séparation des workloads critiques.
2. Gestion des secrets : HashiCorp Vault ou équivalent. Aucun secret en clair dans les manifests Kubernetes, les variables d’environnement ou les logs.
3. Container security : Analyse des images (Trivy, Snyk Container) avant déploiement. Une image publique non auditée est un vecteur d’attaque direct.
4. Runtime security : Détection comportementale en production (Falco, Sysdig) pour identifier les escalades de privilèges et les exfiltrations.
5. CSPM (Posture cloud) : Wiz ou Prisma Cloud pour détecter les misconfigurations en continu sur AWS, Azure ou GCP.

Intégrer la conformité dans programme de modernisation SI

---

La conformité réglementaire, ne relève pas de l’audit de fin de projet. Elle s’intègre dès le cadrage, sous forme de contraintes architecturales et de livrables auditables produits à chaque étape. C’est ce que nous appelons l’approche Security-by-Design × Compliance-by-Design qui consiste à produire des preuves NIS2 sans enrayer la MEP. Voici les chantiers à embarquer dans votre roadmap.

• Cartographie des actifs critiques et flux IA : Données sensibles (PII, données financières), flux RAG, LLM tiers, identités machines des agents.
• Gap analysis NIS2, DORA, RGPD et AI Act : Mesurer l’écart réel entre votre posture actuelle et les exigences réglementaires applicables. Prioriser le backlog selon le ratio risque, impact, effort.
• Gouvernance cyber formalisée : Un RSSI avec un mandat clair, une PSSI à jour et un comité de pilotage cyber impliquant la direction générale.
• KPI et preuves auditables : Taux de correction des vulnérabilités critiques, MTTD, MTTR, couverture des logs, exposition API et cloud. Des indicateurs pilotables au COMEX et présentables à l’ANSSI en cas de contrôle.
• Plan (testé) de réponse aux incidents : Procédures de notification ANSSI (24h, 72h, 1 mois), playbooks par scénario, exercices de simulation annuels.

Think, Build, Run : structurer votre programme de sécurité SI

---

Modernisation SI, Cybersécurité et conformité, l’essentiel à retenir

---

Le SI legacy est le principal angle mort cyber mais l’IA non gouvernée devient de plus en plus risquée -> Traitez les deux dès le cadrage de votre programme.

Les obligations NIS2 et DORA doivent être intégrées comme des contraintes architecturales -> et pas auditées en fin de projet

Vos outils SAST et DAST classiques ne couvrent pas le code généré par IA ni les agents IA autonomes -> Des outils spécifiques sont indispensables.

Zero Trust s’implémente progressivement -> Commencez par les identités et les accès privilégiés, humains et machines.

Cartographiez vos LLM tiers -> DORA exige que tous vos fournisseurs IA traitant des données financières figurent dans votre registre TIC.

Security-by-Design et DevSecOps -> Moins de dette sécurité, moins de coûts de remédiation et plus de vélocité en production.