Souveraineté numérique : guide pratique et stratégique pour les RSSI

La souveraineté numérique n’est plus un dossier juridique qui dort dans un tiroir. Pour un RSSI, c’est désormais une question de continuité d’activité, de cybersécurité et de capacité à garder la main quand un prestataire change les règles du jeu.

Allergique aux pavés ? Voilà ce qu’il faut retenir.

Souveraineté numérique : cartographier les dépendances avant de parler de cloud

Le premier piège consiste à réduire la souveraineté numérique à une simple question d’adresse de serveur. « Les données sont hébergées en France, donc tout va bien » : cette phrase rassure en comité, mais elle ne protège pas grand-chose. Un environnement peut être physiquement localisé à Paris, tout en restant administré depuis l’étranger, supporté par une société soumise à une loi extraterritoriale ou verrouillé dans une technologie impossible à déplacer.

Le RSSI doit donc regarder plus large : données, applications, infrastructures, identités, contrats, maintenance et accès à distance. C’est la base d’une gestion des risques sérieuse. La question utile n’est pas seulement « où sont nos données ? », mais aussi « qui peut les consulter, les déplacer, les déchiffrer ou couper le service ? ». La différence paraît minime sur un slide. Elle devient énorme à 3 heures du matin, lors d’un incident de sécurité ou d’une panne fournisseur.

Partir des processus métier qui font réellement tourner l’entreprise

Une bonne cartographie ne démarre pas par une liste de logiciels. Elle commence par les activités qui ne peuvent pas s’arrêter : encaissement, production, gestion des patients, paiements, logistique, communication avec les clients ou facturation. À ce sujet, la préparation à la facturation électronique en France rappelle une réalité concrète : un flux réglementé devient vite une dépendance stratégique dès qu’il conditionne la capacité à facturer et à encaisser.

Prenons le cas fictif de Mécaflux, une ETI industrielle de 900 salariés. Son RSSI découvre que l’ERP est hébergé dans un cloud européen, mais que son infogérant détient un accès administrateur permanent depuis un centre de support hors Union européenne. Le fournisseur de sauvegarde, lui, utilise une console SaaS opérée par un autre acteur. Sur le papier, l’entreprise a « déplacé ses données dans le cloud ». Dans les faits, elle a empilé trois dépendances critiques sans les relier dans sa gouvernance IT.

Le travail utile consiste à classer les actifs selon leur impact : arrêt de production, atteinte à la confidentialité, sanction réglementaire, préjudice client, perte financière ou atteinte à la réputation. Ce classement évite le grand théâtre des projets où tout devient soudainement « critique ». Non : tout n’a pas le même niveau de sensibilité. Une base de tests anonymisée, une messagerie interne et les secrets de fabrication ne se pilotent pas avec le même degré d’exigence.

• 🗂️ Recenser les applications qui manipulent des données sensibles ou indispensables à l’activité.
• 👤 Identifier les personnes et prestataires disposant de droits d’administration.
• 🌍 Documenter les pays depuis lesquels le support, la supervision et la maintenance sont réalisés.
• 📄 Relire les clauses de sortie, de portabilité et d’assistance en cas de crise.
• ⚠️ Associer chaque dépendance à un scénario de panne, de compromission ou de pression juridique.

Cette discipline n’a rien d’idéologique. Elle permet de distinguer un risque acceptable d’une faiblesse qui finira par coûter cher. Une infrastructure numérique moderne comporte nécessairement des dépendances. L’objectif n’est pas de vivre en autarcie derrière une porte blindée. L’objectif est de savoir quelles dépendances sont tolérées, lesquelles doivent être réduites et lesquelles méritent un plan de repli immédiat.

Une souveraineté numérique solide commence par une carte honnête : ce qui n’est pas identifié ne peut ni être protégé, ni être remplacé.

Conformité, NIS2 et DORA : transformer l’obligation réglementaire en sécurité des systèmes

La conformité n’est pas un supplément administratif ajouté à la fin d’un projet. En 2026, elle impose de prouver que l’organisation connaît ses fournisseurs, contrôle ses expositions et sait répondre à un incident. NIS2 élargit les exigences de cybersécurité pour de nombreux secteurs essentiels ou importants. DORA applique une logique particulièrement exigeante aux services financiers : gestion des prestataires numériques, résilience opérationnelle et tests deviennent des sujets de direction, pas seulement des tickets de sécurité.

Le RGPD ajoute une couche déterminante sur la protection des données personnelles. Il encadre les transferts hors de l’Espace économique européen et demande des garanties effectives, pas une collection de cases cochées. Un contrat rempli de promesses ne vaut pas grand-chose si un prestataire peut accéder à une base de production sans traçabilité, sous-traiter la maintenance à l’autre bout du monde ou déplacer une sauvegarde dans une zone non prévue.

Contrôler la chaîne de sous-traitance plutôt que collectionner les certifications

Une certification est utile, mais elle ne remplace pas un contrôle opérationnel. Le RSSI doit obtenir des réponses précises : quels sous-traitants interviennent réellement ? Où sont les équipes de support ? Quels comptes privilégiés existent ? Quelle procédure est appliquée en cas de demande d’une autorité étrangère ? Combien de temps faut-il pour restaurer une donnée ou exporter un environnement complet ? Quand personne ne sait répondre clairement, le risque ne disparaît pas. Il vient juste de se déguiser sous un logo rassurant.

Les référentiels et labels de cybersécurité servent de repères pour objectiver les décisions. Une lecture des certifications et labels de cybersécurité aide à éviter l’amalgame habituel entre label commercial, attestation limitée et qualification adaptée aux services les plus sensibles. Pour les environnements critiques, la qualification SecNumCloud apporte un niveau d’assurance français particulièrement structurant. À l’échelle européenne, les travaux portés par l’ENISA contribuent aussi à faire monter le niveau d’exigence.

Chez Mécaflux, la revue contractuelle fait ressortir un détail que tout le monde avait laissé passer : le délai de notification d’un incident fournisseur est fixé à cinq jours ouvrés. Pour une fuite de données concernant des clients et partenaires, c’est trop long. Le RSSI négocie un mécanisme d’alerte initiale sous vingt-quatre heures, une mise à jour régulière, l’accès aux éléments de preuve et une assistance claire pour documenter l’incident. Voilà de la conformité qui protège réellement l’activité.

Le même raisonnement doit s’appliquer aux accès d’administration. Une connexion distante de support peut être nécessaire, mais elle ne doit pas être permanente, invisible ou impossible à auditer. Les comptes à privilèges doivent être nominatifs, protégés par une authentification forte, limités dans le temps et journalisés. Si un prestataire refuse ce cadre parce que « sa plateforme standard ne le permet pas », le problème est déjà posé : l’organisation adapte sa sécurité au fournisseur, au lieu d’exiger l’inverse.

La conformité devient alors un levier de stratégie informatique. Elle oblige à poser des exigences mesurables, à arbitrer les exceptions et à faire participer les achats, le juridique, la DSI et les métiers. Le RSSI ne doit pas porter seul le poids du risque. Une dépendance critique acceptée sans plan de repli est une décision de gouvernance, donc une décision qui doit être assumée au bon niveau.

Le contrat utile n’est pas celui qui promet la sécurité : c’est celui qui permet de vérifier, d’alerter, d’auditer et de sortir.

Cloud souverain et chiffrement : isoler les données critiques sans casser l’agilité

Le débat « cloud public contre on-premise » est souvent traité comme un match de supporters. C’est une perte de temps. Le cloud public apporte de la capacité, des services managés, de la vitesse de déploiement et une souplesse réelle. Le rapatriement total du système d’information coûterait cher à la plupart des entreprises, tout en recréant d’autres fragilités : dette technique, pénurie de compétences, matériel vieillissant et absence de redondance.

La bonne stratégie n’est pas de tout sortir du cloud. Elle consiste à segmenter. Les charges ordinaires peuvent rester dans des environnements publics, avec un cadre de sécurité robuste. Les données les plus sensibles, les secrets industriels, les identités à fort impact, les journaux de sécurité ou certains traitements réglementés doivent recevoir une protection renforcée. Selon le niveau de risque, un cloud souverain, un environnement qualifié ou une infrastructure interne peut alors s’imposer.

La clé de chiffrement vaut souvent plus que le serveur

Le point qui sépare une protection sérieuse d’un décor marketing, c’est la maîtrise des clés. Des données chiffrées par le fournisseur mais dont les clés restent accessibles au fournisseur ne sont pas totalement sous le contrôle du client. Pour les actifs les plus critiques, l’organisation doit viser une détention exclusive des clés, idéalement avec un HSM, un matériel dédié qui protège les opérations cryptographiques et limite les manipulations non autorisées.

Cette approche demande de la rigueur. Si les clés sont mal sauvegardées, mal gérées ou perdues, l’entreprise peut s’infliger elle-même une indisponibilité sévère. Il faut donc définir les rôles, les procédures de rotation, le stockage des secrets de secours et les règles d’accès en situation de crise. La souveraineté numérique ne consiste pas à acheter un boîtier puis à se féliciter autour d’un café. Elle exige une exploitation quotidienne propre.

Mécaflux adopte une architecture à trois niveaux. Les outils collaboratifs et les sites publics restent dans un cloud généraliste. Les données de conception des pièces industrielles migrent vers un espace avec contrôle renforcé, chiffrement géré par l’entreprise et accès conditionnel. Enfin, les sauvegardes immuables et les secrets d’administration sont séparés dans un environnement distinct. Ce découpage n’est pas glamour, mais il limite le rayon d’explosion en cas de compromission.

L’open source peut aussi réduire certaines dépendances, à condition de ne pas le traiter comme un talisman. Utiliser un composant ouvert sans équipe capable de le maintenir, le corriger et le sécuriser revient simplement à déplacer la dépendance. En revanche, des standards ouverts, des formats exportables et des briques maîtrisées améliorent la réversibilité. Cette approche est détaillée dans ce contenu sur l’open source au service de la souveraineté numérique.

La vraie question n’est pas « quel cloud choisir ? », mais « quelles données doivent rester sous un contrôle technique exclusif ? »

Réversibilité et PRA : empêcher le vendor lock-in de devenir une prise d’otage

Une entreprise n’est pas libre parce qu’elle a signé trois contrats cloud. Elle est libre lorsqu’elle peut déplacer une charge critique, restaurer ses données et poursuivre son activité malgré la panne ou la défaillance d’un acteur majeur. Le vendor lock-in, cette dépendance qui rend un fournisseur quasi impossible à quitter, se construit lentement : formats propriétaires, frais de sortie imprévus, API spécifiques, compétences absentes et données éparpillées.

Le problème apparaît souvent trop tard. Les équipes construisent vite, utilisent les services les plus pratiques du moment, puis découvrent trois ans après que la migration coûterait plusieurs centaines de milliers d’euros et six mois d’efforts. À ce stade, le fournisseur peut augmenter ses tarifs, modifier ses conditions ou imposer une évolution technique. L’entreprise discute, mais elle ne négocie plus vraiment : elle est attachée au siège.

Tester la sortie au lieu de la promettre

Le plan de reprise d’activité, ou PRA, doit répondre à des questions brutales : quel service redémarre en premier ? En combien de temps ? Avec quelles données ? Sur quelle infrastructure ? Qui décide de basculer ? Une ligne dans un document n’est pas un PRA. Un test de restauration, une simulation de perte d’accès cloud et un exercice de crise impliquant les métiers, voilà un PRA qui commence à tenir debout.

Pour Mécaflux, l’exercice est simple : simuler l’indisponibilité pendant quarante-huit heures de son principal environnement cloud. La première surprise tombe vite. Les sauvegardes existent, mais leur restauration dépend d’un compte administrateur fédéré au même annuaire que la production. Si l’annuaire est compromis, la sauvegarde devient difficilement accessible. Deuxième surprise : une application métier utilise une base managée avec des fonctions propriétaires. Elle ne peut pas être restaurée telle quelle dans l’environnement secondaire.

Ce type de test ne sert pas à humilier les équipes. Il sert à sortir du fantasme. Ensuite, les corrections sont concrètes : créer des comptes de secours isolés, conserver des exports dans des formats standards, prévoir des procédures de restauration documentées, chiffrer les sauvegardes, et tester le temps réel nécessaire. Le RSSI doit mesurer le RTO, le délai acceptable de reprise, et le RPO, la quantité maximale de données que l’entreprise peut accepter de perdre. Sans ces objectifs validés par les métiers, personne ne sait vraiment ce qu’il faut protéger.

1. 🔍 Vérifier que les données peuvent être exportées dans un format exploitable.
2. 💶 Chiffrer les coûts de sortie, de transfert et de reconstruction hors du fournisseur.
3. 🧪 Organiser au moins un test annuel de bascule pour les services critiques.
4. 🛡️ Isoler les sauvegardes de la production pour résister aux ransomwares.
5. 📞 Prévoir une cellule de crise avec DSI, RSSI, métiers, juridique et communication.

La sécurité des systèmes dépend aussi de l’interopérabilité des outils. Une flotte de solutions qui ne partagent ni événements, ni identités, ni contexte d’alerte ralentit la réponse à incident. Dans une crise, un tableau de bord rempli de jolis indicateurs ne sert à rien si les analystes doivent ouvrir sept consoles pour comprendre qui a accédé à quoi. Centraliser les journaux, normaliser les identités et documenter les dépendances techniques accélèrent les décisions.

Un fournisseur devient un partenaire acceptable le jour où son remplacement a été testé, chiffré et préparé.

Shadow IA et gouvernance IT : protéger les données sans bloquer les équipes

L’intelligence artificielle générative a ouvert une nouvelle fuite potentielle dans les organisations : la Shadow IA. Un commercial colle une liste de prospects dans un assistant public pour rédiger un message. Un développeur transmet un extrait de code pour déboguer une fonction. Un financier demande une synthèse d’un prévisionnel. Ces gestes semblent anodins, mais ils peuvent exposer des données clients, du code, des informations financières ou des éléments stratégiques à un service externe non validé.

Interdire tous les outils d’IA ne fonctionne pas. Les équipes contourneront la règle, parce qu’elles y voient un gain de temps. L’approche efficace repose sur un cadre simple, des alternatives opérationnelles et une communication directe. Le RSSI doit expliquer ce qui est interdit, ce qui est autorisé, quelles données ne doivent jamais sortir et quelle solution interne utiliser à la place. Une charte de quinze pages que personne ne lit ne vaut pas une consigne claire intégrée aux outils quotidiens.

Donner une solution maîtrisée pour couper l’herbe sous le pied du contournement

La gouvernance IT doit proposer un catalogue : assistant conversationnel validé, environnement isolé pour le code, règles de pseudonymisation, journalisation des usages et validation pour les cas sensibles. Si l’entreprise demande aux équipes d’être plus productives, elle doit leur fournir une voie sûre. Sinon, la Shadow IA gagne à tous les coups, avec la régularité d’une fuite d’eau derrière un faux plafond.

Chez Mécaflux, un audit des navigateurs et des flux réseau identifie plusieurs outils d’IA utilisés sans validation. Au lieu de sanctionner à l’aveugle, le RSSI organise des ateliers avec les métiers. Les utilisateurs expliquent leurs besoins : synthèse de documents, aide à la rédaction, traduction, analyse de code. L’entreprise déploie ensuite une solution encadrée, avec interdiction d’y envoyer des données identifiantes ou des secrets industriels, et avec une procédure de demande pour les usages à haut risque.

La confidentialité passe aussi par le paramétrage. Il faut vérifier les conditions d’utilisation, les durées de conservation, la réutilisation éventuelle des contenus pour entraîner les modèles, les mécanismes d’authentification et le niveau de journalisation. Une IA hébergée localement n’est pas automatiquement sûre ; une IA externe n’est pas automatiquement inutilisable. Tout dépend des données traitées, du contrat, des contrôles techniques et de la capacité de l’organisation à prouver ce qu’elle fait.

Le sujet rejoint la stratégie informatique globale. Les directions générales demandent de l’innovation, les métiers veulent aller vite, et les RSSI doivent éviter que cette vitesse transforme le patrimoine informationnel en buffet à volonté. Le bon arbitrage ne se fait pas avec un slogan anti-technologie. Il se fait par classification des données, analyse des risques, contrôle des accès et formation ciblée.

Un dernier point mérite d’être dit franchement : la souveraineté numérique ne relève pas seulement de la DSI. Les achats choisissent des prestataires, le juridique valide des clauses, les métiers adoptent des services, la direction accepte des risques. Le RSSI apporte la méthode et alerte sur les angles morts, mais la résilience ne se délègue pas à une seule personne. Une entreprise qui traite ce sujet comme un dossier technique se prépare à découvrir le problème au pire moment.

La souveraineté numérique n’empêche pas d’innover : elle évite simplement que l’innovation parte avec les données par la porte de service.

La souveraineté numérique impose-t-elle d’abandonner le cloud public ?

Non. Une approche réaliste consiste à conserver le cloud public pour les usages compatibles avec le niveau de risque, puis à isoler les données, secrets et services les plus critiques dans des environnements renforcés, qualifiés ou internes.

Pourquoi le Cloud Act est-il un sujet pour un RSSI français ?

Le Cloud Act peut permettre aux autorités américaines de demander des données à des entreprises américaines, y compris lorsque les données sont hébergées hors des États-Unis. Le RSSI doit donc évaluer la juridiction applicable, les accès d’administration et les garanties contractuelles et techniques.

Quel est le premier livrable à produire ?

Une cartographie des dépendances critiques : applications, données, fournisseurs, sous-traitants, accès privilégiés, localisations de support, clauses de réversibilité et scénarios de panne. Sans cette vue, les priorités restent théoriques.

Comment limiter la Shadow IA sans bloquer les métiers ?

Il faut proposer des outils validés, établir des règles simples sur les données interdites, former les utilisateurs et contrôler les usages sensibles. Une interdiction sans alternative encourage le contournement.