Pourquoi la maintenance logicielle est non négociable – y compris sur les systèmes legacy?

06 février 2026 | 6 lecture minimale | Décommissionnement des systèmes legacy, Enterprise Legacy System Application (ELSA), Gestion des données SAP

Dans le paysage réglementaire actuel, la maintenance logicielle est passée d’une préoccupation purement technique à une obligation de conformité critique. Les organisations ne peuvent plus traiter les mises à jour de sécurité comme des tâches facultatives à aborder quand cela leur convient. Les conséquences de la négligence de la maintenance deviennent de plus en plus graves. Les régulateurs européens adoptent une position plus ferme, et les récentes mesures d’application démontrent que les excuses, qu’elles soient liées aux contraintes de ressources ou à l’âge du système, ne soustrairont pas les organisations à leurs responsabilités. Ce changement exige une modification fondamentale de la manière dont les entreprises abordent l’ensemble de leur parc logiciel, y compris les systèmes legacy qui passent souvent inaperçus dans les pratiques de sécurité modernes.

Le 22 décembre 2025, l’autorité française de protection des données (CNIL) a infligé une amende significative de 1,7 million d’euros à une entreprise informatique pour ne pas avoir mis en œuvre des mesures de sécurité appropriées. L’application en question, un système PCRM utilisé par les services sociaux publics, traitait des données personnelles sensibles sans protection adéquate. Mais qu’est-ce qui a conduit à cette amende massive ?

Les causes profondes qui ont conduit la CNIL à infliger une amende à l’entreprise étaient des vulnérabilités de sécurité persistantes, des lacunes connues par rapport aux normes de sécurité de pointe et des retards importants dans la mise en œuvre des actions correctives. Plus important encore, des audits avaient identifié ces problèmes bien avant que toute exposition de données ne se produise. De plus, ce qui est choquant ici, c’est le fait que l’organisation était au courant des problèmes mais n’a pas agi de manière décisive.

Par conséquent, cela envoie un message clair à toutes les organisations : la prise de conscience sans action n’est pas une défense. Les régulateurs examineront non seulement si vous avez identifié des vulnérabilités, mais aussi la rapidité et l’efficacité avec lesquelles vous les avez traitées.

Attendre les incidents ou les plaintes avant d’agir n’est jamais une solution logique. Conformément à l’article 32 du RGPD, la loi européenne sur la protection des données, les organisations sont tenues de mettre en œuvre des mesures techniques et organisationnelles appropriées qui reflètent les menaces actuelles et les bases technologiques. Cette obligation est un processus continu et non négociable, et non un exercice ponctuel. À mesure que les menaces évoluent et que de nouvelles vulnérabilités apparaissent, vos mesures de sécurité doivent s’adapter en conséquence. Les approches réactives laissent des fenêtres d’exposition dangereuses qui peuvent être exploitées facilement.

L’un des aspects les plus importants est que la maintenance logicielle va bien au-delà de la stabilité du système. Il s’agit fondamentalement d’une activité de conformité, essentielle pour protéger les données personnelles et limiter les risques liés aux exploits connus. En fait, lorsque des correctifs sont disponibles pour des vulnérabilités connues, les retards de déploiement deviennent de plus en plus difficiles à justifier. Chaque jour où une vulnérabilité connue reste non traitée, votre paysage informatique devient plus risqué – une préoccupation que les régulateurs examineront si une violation se produit.

De nombreuses organisations investissent considérablement dans les audits de sécurité, estimant que cela démontre la diligence raisonnable. Bien qu’il soit important d’investir dans des mesures de sécurité, il est à noter que l’identification des vulnérabilités par de telles mesures de sécurité n’est que la première étape. L’examen réglementaire se concentre sur ce qui se passe après la remise des résultats d’audit, par exemple : à quelle vitesse les correctifs ont-ils été déployés, les ressources ont-elles été allouées de manière appropriée, etc. Ces questions détermineront si une organisation est jugée conforme ou négligente.

Les systèmes legacy manquent fréquemment de support fournisseur, de contrôles de sécurité modernes et de capacités d’intégration avec les outils de sécurité contemporains. Ils sont régulièrement mis en évidence dans les rapports de violation et les conclusions réglementaires comme des environnements à haut risque. Ces systèmes ont souvent été conçus à une époque où les menaces de cybersécurité étaient moins sophistiquées. Leur architecture peut ne pas prendre en charge les normes de chiffrement modernes, les contrôles d’accès ou les capacités de surveillance, ce qui en fait des cibles faciles pour les attaquants et des priorités préoccupantes pour les régulateurs.

Que le logiciel soit nouveau, ancien, personnalisé ou prêt à l’emploi, l’obligation d’assurer une sécurité adéquate reste constante. Les directives de la CNIL sur la maintenance et le contrôle des interventions de tiers renforcent cette responsabilité tout au long du cycle de vie. En fait, l’âge d’un système ne diminue pas le devoir de diligence d’une organisation. Au contraire, les systèmes plus anciens nécessitent plus d’attention précisément parce qu’ils manquent des protections intégrées que les plateformes modernes offrent. Les régulateurs comprennent ces défis mais attendent des organisations qu’elles mettent en œuvre des contrôles compensatoires ou prennent des décisions difficiles concernant le retrait des systèmes.

Les plateformes legacy hébergent généralement des données historiques sensibles et sont intégrées dans des processus métier plus larges. Leur compromission peut se propager à des systèmes plus vastes, créant des effets d’entraînement dans toute l’organisation. Ce risque interconnecté signifie qu’une violation dans un système legacy apparemment isolé peut exposer les opérations actuelles, les données clients et la continuité des activités. Le décommissionnement des systèmes legacy doit donc être considéré non pas comme un projet de modernisation facultatif, mais comme un impératif critique de cybersécurité.

Il est extrêmement important de s’assurer que votre politique de maintenance ne laisse aucun système de côté. La politique doit définir des déclencheurs clairs pour les cycles de rafraîchissement, le déploiement de correctifs et les décisions stratégiques concernant le décommissionnement des systèmes legacy. Assurez-vous d’aligner ces politiques avec la CNIL (autorité RGPD en France), le RGPD avec toute autre autorité locale, ou les exigences relatives aux lois sur la confidentialité des données de la région pour les mesures documentées, en vous assurant de pouvoir démontrer la conformité lors des audits.

Priorisez les systèmes traitant des données sensibles pour des mises à jour et des examens de sécurité plus fréquents. En fait, les systèmes obsolètes doivent être inclus dans les programmes de gestion des vulnérabilités, et non exemptés en raison de leur âge ou de leur isolement perçu.

Les enregistrements des interventions, des correctifs et des décisions deviennent des éléments clés dans les audits et la gouvernance interne. Maintenez une documentation complète qui démontre l’engagement de votre organisation envers une maintenance de sécurité continue.

Pour les systèmes legacy qui ne peuvent pas être sécurisés de manière adéquate, le décommissionnement peut être la voie la plus sûre. Les plateformes de décommissionnement modernes permettent aux organisations de retirer les systèmes obsolètes tout en maintenant l’accès aux données historiques à des fins de conformité. Cette approche élimine les risques de sécurité liés à la maintenance de systèmes vulnérables sans sacrifier l’accessibilité des données.

L’amende de 1,7 million d’euros de la CNIL représente un moment significatif pour les obligations de maintenance logicielle. Les régulateurs sont devenus stricts quant à leurs points de contrôle de conformité et attendent des organisations qu’elles mettent en œuvre des pratiques de sécurité sur l’ensemble de leurs logiciels et de leurs paysages informatiques.

Les systèmes legacy, souvent négligés dans les efforts de modernisation, sont précisément là où l’attention réglementaire se concentrera. Le non-respect d’une maintenance robuste à grande échelle entraîne des sanctions significatives et des dommages réputationnels durables.

Pour les organisations aux prises avec des systèmes legacy qui posent des risques de sécurité continus, le décommissionnement offre une solution stratégique. L’Enterprise Legacy System Application (ELSA) de TJC Group offre une voie sûre et conforme. Cette solution certifiée SAP permet aux organisations de décommissionner 100 % de leurs systèmes legacy, d’un ERP unique à des centaines d’applications, tout en maintenant un accès facile aux données historiques chaque fois que nécessaire.

Grâce à la passerelle ELSA, les entreprises peuvent récupérer rapidement toutes les données, rapports et documents legacy requis pour la conformité réglementaire, sans les risques et les dépenses liés à la maintenance de systèmes obsolètes. ELSA maintient également des journaux de traçabilité pour assurer une conformité continue avec les exigences fiscales et les lois sur la confidentialité des données telles que le RGPD.

Contactez-nous dès aujourd’hui pour découvrir comment ELSA peut vous aider à réduire les risques de conformité et à renforcer votre posture de sécurité.