Souveraineté cloud vs sécurité opérationnelle : le vrai sujet

Depuis deux ans, la souveraineté numérique s'est imposée comme critère de choix dans presque tous les appels d'offres et comités de direction. C'est une bonne chose : la question de savoir qui peut légalement accéder à vos données mérite d'être posée. Mais dans une majorité de dossiers que je vois passer, la souveraineté devient un totem qui dispense de poser la vraie question, celle de la sécurité opérationnelle réelle de l'infrastructure retenue.

Une entreprise peut choisir un hébergeur français, cocher la case souveraineté, et laisser en production une infrastructure mal configurée, sans sauvegarde testée et sans supervision. Elle aura résolu un problème juridique et laissé intact un problème technique bien plus probable de se réaliser.

Ce que la souveraineté résout vraiment

La souveraineté numérique répond à une question précise : quelle juridiction peut, légalement, exiger l'accès à vos données ? Le Cloud Act américain, par exemple, permet aux autorités des États-Unis de réclamer des données hébergées par une entreprise américaine, même si les serveurs sont physiquement situés en Europe. C'est un risque réel pour certains secteurs — santé, défense, données publiques sensibles — et un risque marginal pour la majorité des PME et scale-ups qui ne traitent pas de données stratégiques d'État.

Pour ces dernières, le sujet mérite d'être traité, mais proportionnellement. Choisir OVHcloud ou Scaleway plutôt qu'AWS règle la question juridictionnelle. Cela ne règle ni la qualité de la configuration réseau, ni la robustesse des sauvegardes, ni la gestion des accès, ni la capacité à détecter un incident.

Ce que la souveraineté ne résout jamais

La sécurité opérationnelle regroupe les pratiques concrètes qui déterminent si une infrastructure résiste à une attaque ou à une erreur humaine, indépendamment de sa nationalité :

• La gestion des accès : qui a des droits administrateur, depuis combien de temps, avec ou sans authentification à deux facteurs.
• Les sauvegardes testées : une sauvegarde qu'on n'a jamais restaurée n'est pas une sauvegarde, c'est une hypothèse.
• Le chiffrement au repos et en transit, appliqué uniformément et pas seulement sur les bases de données visibles.
• La supervision et l'alerting : la capacité à détecter une activité anormale en heures, pas en semaines.
• Le plan de reprise d'activité, documenté et exercé au moins une fois par an.

J'ai vu des infrastructures hébergées à 100 % en France, parfaitement souveraines sur le papier, tomber en quelques heures faute de segmentation réseau ou de rotation des accès après le départ d'un prestataire. Le critère souveraineté n'aurait rien changé à ce scénario.

Une grille d'arbitrage en trois questions

Face à un choix d'hébergement, trois questions permettent de sortir du débat idéologique et de revenir aux faits :

1. Quelle est la sensibilité réelle des données traitées ? Données de santé, données régaliennes, secrets industriels stratégiques justifient un arbitrage souveraineté fort. Un SaaS B2B classique avec des données de facturation et des comptes utilisateurs justifie un arbitrage plus pragmatique.
2. Quel est le niveau de maturité opérationnelle de l'hébergeur et de l'équipe qui le configure ? Un cloud souverain mal opéré est plus risqué qu'un cloud américain bien opéré. L'inverse est vrai aussi.
3. Quel est le coût de la réversibilité ? Un fournisseur qui verrouille son format de données ou ses API rend toute décision future — souveraine ou non — beaucoup plus coûteuse à corriger.

Construire un cahier des charges qui ne se limite pas au drapeau

Un cahier des charges d'hébergement solide combine les deux dimensions plutôt que de choisir l'une contre l'autre. Concrètement, cela signifie exiger :

• La localisation contractuelle des données et la juridiction applicable, avec preuve écrite.
• Un audit de configuration récent, ou à défaut, la réalisation d'un audit avant la migration.
• Des tests de restauration de sauvegarde documentés et datés.
• Une politique d'accès nominative, avec authentification forte pour tout accès administrateur.
• Un plan de réponse à incident, même sommaire, avec un responsable identifié.

Ce sont ces éléments, et non le seul choix du fournisseur, qui déterminent la probabilité qu'un incident survienne et la vitesse à laquelle l'entreprise s'en remet. Beaucoup de directions techniques n'ont ni le temps ni le mandat pour piloter cet arbitrage en parallèle de leurs sujets produit, ce qui justifie de faire appel ponctuellement à un CTO externalisé pour arbitrer ces choix, le temps de sécuriser la décision et sa mise en œuvre.

Ne pas opposer les deux dimensions dans la communication interne

Un dernier point pratique : dans les comités de direction, la souveraineté se vend plus facilement en une phrase que la sécurité opérationnelle. Le risque est que l'entreprise communique — en interne comme auprès de ses clients — sur un critère rassurant sans avoir vérifié le second, plus déterminant. Une direction technique sérieuse documente les deux volets séparément, avec des indicateurs propres à chacun, plutôt que de les fondre dans un même argumentaire commercial.

FAQ

Faut-il systématiquement privilégier un cloud français pour des raisons de souveraineté ?

Non, cela dépend de la sensibilité réelle des données traitées. Pour des données stratégiques, de santé ou régaliennes, l'arbitrage souverain est justifié. Pour une majorité de PME et de SaaS B2B, le critère de maturité opérationnelle de l'hébergeur pèse souvent plus lourd que sa nationalité.

Comment évaluer la sécurité opérationnelle d'un hébergeur avant de signer ?

En demandant des preuves concrètes plutôt que des déclarations : rapport d'audit récent, résultats de tests de restauration, politique d'accès documentée, certifications à jour comme ISO 27001 ou SecNumCloud, et références clients vérifiables sur la gestion d'un incident passé.