Un système cœur de métier peut continuer à fonctionner alors même que les hypothèses de sécurité qui le sous-tendent ne sont plus adaptées. À mesure que les entreprises adoptent des services cloud, des accès distants, des API et des plateformes tierces, la modernisation dépasse la simple décision applicative. Elle pose aussi la question de savoir si le système reste défendable dans son environnement d’exploitation actuel.
Les hypothèses de sécurité évoluent avec le temps
De nombreux systèmes d’entreprise matures ont été conçus pour un environnement fermé, où les utilisateurs se trouvaient à l’intérieur du réseau de l’entreprise et où les connexions externes étaient relativement rares. Ces frontières se sont depuis élargies aux terminaux mobiles, aux charges de travail cloud, aux partenaires
et aux équipes distribuées. Les contrôles fondés sur la localisation réseau ou sur une confiance interne implicite peuvent donc être moins efficaces qu’auparavant.
44 % des serveurs, réseaux et systèmes approchent de leur fin de vie.
Source : 2024 Kyndryl Readiness Report, d’après les réponses de 3 200 dirigeants d’entreprise et responsables technologiques dans 18 pays.
La dette de sécurité peut rester invisible
La dette fonctionnelle produit généralement des symptômes visibles : anomalies récurrentes, performances dégradées ou effort de maintenance croissant. La dette de sécurité est plus difficile à détecter, car des contrôles obsolètes peuvent continuer à fonctionner sans perturber le service quotidien.
Sur les plateformes matures, cette dette se manifeste souvent par des méthodes d’authentification anciennes, des exceptions d’accès accumulées, des dépendances qui ne sont plus prises en charge, un chiffrement hétérogène et des journaux d’audit incomplets. L’écart ne devient parfois visible qu’à l’occasion d’un audit, d’une nouvelle intégration ou d’un incident de sécurité.
Une nouvelle plateforme ne supprime pas l’exposition existante
Investir dans une nouvelle plateforme n’élimine pas automatiquement les risques liés à l’ancienne. Des processus essentiels, des données historiques et des intégrations complexes peuvent empêcher la mise hors service d’un système hérité. Le même problème survient fréquemment après une acquisition, lorsque plusieurs plateformes doivent cohabiter plus longtemps que prévu.
Cette coexistence augmente le nombre d’identités, d’interfaces, de flux de données et de modèles d’accès que l’organisation doit sécuriser. Le risque ne diminue que lorsque les charges de travail et les contrôles sont migrés, intégrés ou décommissionnés. Si la capacité de mise en œuvre ne suit pas le rythme des investissements, une architecture de transition temporaire peut devenir une source d’exposition permanente.
La modernisation est une décision de sécurité
L’architecture applicative et l’architecture de sécurité doivent être évaluées dans le cadre d’une même décision de modernisation. Cet examen doit déterminer quels processus métier restent critiques, quelles dépendances doivent être conservées, comment les identités et les données circulent dans l’environnement et quelle exposition de sécurité subsiste dans chaque scénario.
Tous les systèmes matures n’ont pas vocation à être remplacés. Certains contrôles peuvent être renforcés sans changement architectural majeur. D’autres systèmes nécessiteront une modernisation, une migration ou une mise hors service, parce que leur modèle de sécurité sous-jacent ne correspond plus au fonctionnement de l’entreprise.
Rikkeisoft Smart Modernization aide les organisations à évaluer les contraintes applicatives, de dépendances et de sécurité au sein d’une feuille de route coordonnée, afin d’éclairer les décisions sur ce qu’il convient de conserver, de moderniser, de migrer ou de mettre hors service.
Source :
