Le RSSI seul ne suffit plus : repenser la gouvernance cyber à l'heure de la dépendance numérique

# Le RSSI seul ne suffit plus : repenser la gouvernance cyber à l'heure de la dépendance numérique

> En 2026, confier la souveraineté numérique de votre entreprise à un seul RSSI, c'est comme confier la politique étrangère d'un pays à un attaché de presse. Le rôle est utile. Mais il n'a pas été conçu pour ça.

Depuis plusieurs années, la figure du RSSI a été promue comme la réponse universelle à tous les risques numériques. Les fournisseurs américains ont d'ailleurs largement contribué à cette narrative : en vendant des plateformes de sécurité intégrées — XDR, SIEM, SOAR — ils ont fabriqué un interlocuteur idéal, le RSSI, dont le périmètre correspond exactement à celui de leurs produits. Pratique.

Mais voilà le problème : la souveraineté numérique n'est pas un périmètre technique. C'est un choix politique d'entreprise. Et ce choix ne peut pas être délégué à une seule fonction, aussi compétente soit-elle.

Ce guide s'adresse aux DSI et CTO de PME/ETI européennes qui sentent que quelque chose cloche dans leur gouvernance — mais qui n'ont pas encore formalisé pourquoi ni comment y remédier.

Pourquoi la question dérange — et pourquoi il faut quand même la poser

Avant d'entrer dans le guide, posons la question qui fâche : votre RSSI sait-il où sont hébergées vos données critiques, par qui elles sont traitées, et sous quelle juridiction elles tombent en cas de litige ?

Dans la majorité des ETI européennes, la réponse honnête est : partiellement. Parce que les décisions d'achat de SaaS ont été prises par les métiers. Parce que le cloud a été choisi pour sa simplicité opérationnelle, pas pour sa localisation juridique. Parce que le RSSI a été appelé *après*, pour sécuriser ce qui avait déjà été signé.

Ce n'est pas une faute du RSSI. C'est une faute de gouvernance.

Étape 1 — Cartographier vos dépendances réelles, pas vos contrats

La première tâche n'est pas technique. Elle est documentaire — et elle est souvent inconfortable.

Ce que ça implique concrètement pour les équipes IT :

Recensez l'ensemble des outils SaaS actifs dans votre organisation, y compris ceux que la DSI n'a pas achetés elle-même. Shadow IT inclus. Pour chaque outil, posez trois questions simples :

• Où sont les données ? Pas où le commercial vous a dit qu'elles seraient. Où sont-elles *contractuellement* garanties d'être hébergées ?
• Qui peut y accéder sans vous le dire ? Les fournisseurs américains sont soumis au CLOUD Act. Ce n'est pas une théorie du complot, c'est du droit positif américain.
• Qu'est-ce qui se passe si ce fournisseur change ses conditions demain matin ? La réponse « on trouvera » n'est pas une réponse de gouvernance.

Cette cartographie doit être mise à jour tous les semestres, pas tous les trois ans lors d'un audit. Elle doit être partagée avec la direction générale — pas rangée dans un rapport que personne ne lit.

La question qui dérange : est-ce que votre RSSI a les moyens RH et le mandat politique pour mener cette cartographie seul ? Probablement non. C'est précisément pourquoi il ne peut pas être le seul responsable.

Étape 2 — Créer un comité de souveraineté numérique — et lui donner un vrai pouvoir de veto

Nommons les choses clairement : un comité de plus ne sert à rien si c'est une réunion de plus dans un agenda déjà saturé.

Ce que nous proposons ici, c'est un organe de décision, pas de consultation. Il réunit a minima :

• Le DSI ou CTO (maîtrise d'ouvrage technique)
• Le DAF ou un représentant de la direction générale (engagement budgétaire et stratégique)
• Le RSSI (apport d'expertise risque)
• Le DPO si votre organisation en dispose

Son rôle opérationnel : aucun contrat SaaS ou infrastructure cloud ne peut être signé sans son aval explicite sur la dimension souveraineté. Pas un avis. Un veto.

Ce que ça change au quotidien pour les équipes IT :

Cela force à documenter chaque décision d'achat avec une fiche de souveraineté synthétique : juridiction d'hébergement, réversibilité des données, existence d'une alternative européenne évaluée. Ce n'est pas de la bureaucratie — c'est la traçabilité des choix stratégiques.

Et oui, ça ralentit certaines décisions. C'est le prix de la maîtrise. La rapidité avec laquelle on signe un contrat SaaS américain est rarement une vertu sur le long terme.

Étape 3 — Intégrer la réversibilité comme critère d'achat, pas comme option

Voici le marketing pitch que les équipes IT entendent en permanence : *« Nos APIs sont ouvertes, la migration est simple. »*

Posez la question autrement : avez-vous déjà réellement migré hors d'une plateforme dominante américaine ? Combien de temps ? Combien de personnes ? Combien de données perdues ou reformatées à la main ?

La réversibilité n'est pas une promesse commerciale. C'est une capacité technique qui se vérifie *avant* la signature, pas après.

Concrètement, les équipes IT doivent désormais exiger :

• Un export complet des données dans un format ouvert et documenté, testable à tout moment (pas uniquement à la résiliation)
• Une documentation d'API publique et stable, sans que le fournisseur puisse la fermer unilatéralement
• Un délai de préavis contractuel suffisant pour organiser une migration réelle — pas symbolique

Deux acteurs européens ont fait de la réversibilité un argument commercial central ces dernières années : **Scaleway** sur l'infrastructure cloud, et **Nextcloud** sur la collaboration. Ce n'est pas un hasard — c'est une réponse directe à la pression de leurs clients continentaux. Prenez-en note : quand un acteur européen met la réversibilité en avant, c'est parce que ses clients le demandent. Commencez par le demander vous aussi.

Étape 4 — Former les équipes IT à lire un contrat, pas seulement un benchmark technique

C'est peut-être la recommandation la plus dérangeante de ce guide.

Les équipes IT sont formées pour évaluer des performances, des latences, des architectures. Elles ne sont généralement pas formées pour lire une clause de juridiction applicable, une clause de sous-traitance en cascade, ou une clause de modification unilatérale des conditions de service.

Or c'est dans ces clauses que se joue la souveraineté — pas dans les benchmarks.

Ce que ça implique concrètement :

• Intégrez dans vos processus de sélection d'outils une checklist juridique minimale, co-construite avec votre service juridique ou un conseil externe spécialisé en droit du numérique européen
• Formez au moins un membre technique de votre équipe à la lecture critique des CGU et contrats SaaS — il existe des formations courtes sur ce sujet, délivrées par des acteurs européens spécialisés
• Systématisez la question : *« Que se passe-t-il si ce fournisseur est racheté par un acteur américain dans 18 mois ? »* — parce que c'est une probabilité, pas une hypothèse d'école

Étape 5 — Mettre en place des indicateurs de souveraineté dans le reporting DSI

Ce qui ne se mesure pas ne se pilote pas. Et ce qui ne se pilote pas ne s'améliore pas.

Le tableau de bord du DSI en 2026 ne peut plus se limiter aux indicateurs de disponibilité, de tickets résolus et de coût par utilisateur. Il doit intégrer une colonne souveraineté.

Exemples d'indicateurs actionnables — sans inventer de chiffres :

• Part des données critiques hébergées sous juridiction européenne (en pourcentage de volume, défini par vous)
• Nombre d'outils SaaS pour lesquels une alternative européenne a été identifiée et évaluée
• Nombre de contrats avec clause de réversibilité testée (et non seulement contractualisée)
• Délai moyen estimé de migration hors de chaque outil critique — mis à jour annuellement

Ces indicateurs ne sont pas parfaits. Ils sont perfectibles. Mais ils forcent une conversation que la plupart des COMEX n'ont jamais eue — parce que personne ne la leur a mise sur la table.

Ce que tout ça dit du rôle du RSSI

Rien dans ce guide ne diminue le rôle du RSSI. Il reste indispensable sur son périmètre d'expertise : gestion des risques techniques, réponse aux incidents, conformité réglementaire.

Mais confondre sécurité et souveraineté est une erreur stratégique. Un système peut être parfaitement sécurisé et totalement sous dépendance américaine. Les deux problèmes sont distincts. Ils nécessitent des réponses distinctes. Et donc des responsabilités distinctes.

La gouvernance cyber souveraine, ce n'est pas un poste. C'est une posture collective — qui engage la direction générale, les achats, le juridique, et les équipes IT ensemble.

Tant que cette posture ne sera pas formalisée, le RSSI restera le fusible qu'on fait sauter quand quelque chose cloche. Ce n'est rendre service ni à lui, ni à votre organisation.

*Ce guide sera mis à jour au fil des évolutions réglementaires européennes et des retours terrain de nos lecteurs DSI/CTO. Vous avez une expérience de gouvernance à partager ? Écrivez-nous.*