Théorie VS Réalité

Il y a la théorie de la cybersécurité, et il y a la réalité de votre parc applicatif. D’un côté, la directive NIS 2 impose désormais une « hygiène numérique » stricte et une authentification forte pour les accès critiques. De l’autre, votre ERP maison, votre interface SCADA ou votre outil de gestion de stock ont été codés il y a 15 ans, à une époque où le mot « MFA » n’existait même pas dans le cahier des charges.

Pour de nombreux DSI et RSSI, c’est l’équation impossible de 2026 : comment appliquer des standards de sécurité modernes sur des fondations archaïques ?

Le problème : Vos applications « Legacy » sont invisibles pour le MFA moderne

Ces applications sont souvent les piliers de votre activité. Elles tournent parfaitement, elles sont stables, mais sur le plan sécuritaire, elles sont restées figées dans les années 2010.

Leur architecture pose trois problèmes majeurs face aux menaces actuelles (Ransomware, vol d’identifiants) :

1. Absence de hooks d’authentification : Elles gèrent souvent leurs propres bases utilisateurs en local et ne supportent pas les protocoles modernes comme SAML.
2. L’illusion du périmètre : Elles ont été conçues pour être utilisées dans un « réseau de confiance » (LAN). Aujourd’hui, avec le travail hybride et l’ouverture des SI, cette notion n’existe plus.
3. Incompatibilité native : Intégrer une clé YubiKey ou du FaceID directement dans une vieille application Web ou Linux est techniquement complexe, voire impossible sans tout casser.

L’impasse de la refonte

Face à l’exigence de conformité (notamment l’article 21 de la directive NIS 2 concernant la sécurité de l’approvisionnement et le contrôle d’accès), le premier réflexe est souvent de penser « refonte ».

C’est pourtant un piège budgétaire et opérationnel. Recoder une application critique juste pour y ajouter une brique de sécurité, c’est s’exposer à :

• Un budget explosif : Le développement sur mesure coûte cher.
• Un délai inacceptable : Comptez 12 à 24 mois pour une refonte complète. NIS 2 n’attend pas.
• Un risque opérationnel majeur : Toucher au « vieux code » (Legacy code), c’est risquer des régressions, des bugs en production et des arrêts de service.

Comme le dit l’adage informatique : « If it works, don’t touch it. » (Si ça marche, n’y touche pas). Alors, comment sécuriser sans toucher ?

Le changement de paradigme : Le « Sas » de sécurité

L’approche moderne ne consiste plus à modifier l’application, mais à modifier la manière d’y accéder. C’est le principe de l’isolation.

Au lieu de forcer le vieux moteur à accepter du carburant moderne, on place un sas de sécurité étanche devant lui. C’est exactement l’approche que nous avons développée chez Reemo.

Comment ça marche ?

L’architecture se divise en deux zones distinctes, créant une rupture protocolaire :

1. La Zone Frontale (Le sas moderne) : L’utilisateur ne se connecte jamais directement à l’application Legacy. Il se connecte au portail Reemo. Ici, toutes les technologies de 2026 sont natives : HTTPS strict, MFA, et surtout biométrie (FaceID, TouchID…).
2. La Zone Arrière (Le Conteneur Sécurisé) : Une fois l’utilisateur fortement authentifié et validé, Reemo ouvre un tunnel sécurisé vers l’application Legacy. L’application reste dans son état d’origine, isolée dans un conteneur ou un réseau protégé, invisible depuis l’internet public.

Les résultats immédiats pour la DSI

Cette approche de « Security Overlay » / d’isolation protocolaire (couche de sécurité superposée) permet d’apporter une première brique de conformité.

• Brique de conformité : Votre application de 2008 bénéficie soudainement d’une authentification biométrique de niveau bancaire.
• Zéro impact sur le code : Pas de développement, pas de recette complexe, pas de risque de régression.
• Traçabilité complète : Là où les logs des vieilles applications sont souvent obscurs, le passage par le sas Reemo permet de savoir exactement qui s’est connecté, quand, et avec quel facteur d’authentification.

Ne remboursez pas la dette, sécurisez-la.

La course à la conformité NIS 2 ne doit pas paralyser votre roadmap IT. En dissociant et en isolant la sécurité de l’accès de la logique applicative, vous gagnez sur les deux tableaux : vos utilisateurs profitent de la fluidité du FaceID, et votre SI est protégé contre les accès illégitimes.

Vous avez des applications critiques qui ne supportent pas le MFA ? Discutons de la mise en place d’un sas.