← Tous les articles

Cloud souverain : ce que ça change vraiment pour une PME

Cloud souverain : pourquoi un serveur en France ne suffit pas, ce que dit vraiment le Cloud Act, et quand la question se pose concrètement pour une PME.

Frontière juridique entre un hébergement souverain et un accès international
Cloud souverain

« Vos données sont hébergées en Europe. » La phrase rassure, elle figure sur à peu près tous les sites de logiciels, et elle ne veut pas dire grand-chose. Le cloud souverain est devenu un argument commercial avant d’être un sujet compris, ce qui rend difficile de savoir si votre entreprise est concernée ou si on vous vend une inquiétude.

Essayons de trier. Voici ce que recouvre le terme, ce qui change réellement selon votre activité, et à quel moment la question mérite d’être posée.

Le malentendu de départ : le serveur et le juge

La confusion la plus répandue consiste à croire que l’emplacement physique des serveurs détermine le droit qui s’applique. Ce n’est pas le cas.

Un hébergeur américain qui exploite un datacenter à Paris reste une société de droit américain. À ce titre, il est soumis au Cloud Act, une loi de 2018 qui autorise les autorités américaines à réclamer des données détenues par une entreprise américaine, quel que soit le pays où ces données sont physiquement stockées. Vos fichiers sont à Roubaix ou à Marseille, et la demande est malgré tout recevable.

Un cloud réellement souverain suppose donc deux conditions cumulatives : des serveurs situés sur le territoire, et un opérateur qui ne relève que du droit européen. C’est ce qui distingue un hébergeur français d’un hébergeur américain doté d’une région française.

Cette nuance est le point sur lequel il faut lire les contrats. Les formulations « données stockées en Europe », « conforme RGPD » ou « région UE » décrivent une localisation, pas une juridiction. Elles peuvent être parfaitement exactes et ne vous protéger de rien sur ce plan précis.

Est-ce que ça vous concerne vraiment ?

Répondre honnêtement suppose de distinguer trois situations, parce que la réponse n’est pas la même.

Vous traitez des données sensibles. Données de santé, données RH détaillées, données financières de vos clients, informations sur des mineurs. Ici la souveraineté n’est plus une préférence. Certaines catégories imposent un hébergement agréé, et le transfert hors Union européenne se justifie difficilement depuis l’invalidation du Privacy Shield. Si vous êtes dans ce cas, le sujet est déjà réglé pour vous.

Vous répondez à des marchés publics. Les collectivités et les administrations font apparaître l’hébergement souverain dans leurs critères avec une régularité croissante, parfois en condition d’éligibilité, parfois en points d’attribution. Ce n’est plus un supplément d’âme, c’est une ligne de la grille de notation. Un prestataire qui ne peut pas cocher la case perd des dossiers sans même arriver à l’entretien.

Vous êtes une PME classique, sans données particulièrement sensibles. Soyons directs : le risque juridique immédiat est faible, et personne ne viendra vous chercher demain matin. La question devient alors moins juridique qu’économique, et elle se pose en termes de dépendance. Que se passe-t-il si votre fournisseur triple ses tarifs, ferme un service que vous utilisez, ou devient inaccessible pour une raison qui vous échappe entièrement ? La souveraineté est ici une forme de réduction du risque, pas une obligation.

Nous préférons le dire ainsi plutôt que d’agiter la menace réglementaire. Si votre situation ne l’exige pas, personne ne devrait vous vendre du souverain avec un discours de peur.

Ce que ça change concrètement au quotidien

Une inquiétude fréquente porte sur la qualité de service. Passer sur un hébergeur français, est-ce accepter moins bien pour un principe ?

Sur les usages courants d’une PME, non. Un serveur applicatif, une base de données, du stockage, des sauvegardes, un nom de domaine : les acteurs français couvrent tout cela avec des performances équivalentes, et souvent à un tarif inférieur pour la bande passante sortante, poste où les grands fournisseurs américains sont particulièrement chers.

L’écart existe ailleurs. Il porte sur les services managés très spécialisés, sur certains outils d’intelligence artificielle clés en main et sur la profondeur du catalogue. Si votre produit repose sur une brique propriétaire d’un grand fournisseur, la migration n’est pas une simple bascule et il faut le regarder en face.

Deux effets secondaires méritent aussi d’être signalés. Le premier est la latence, meilleure quand vos utilisateurs et vos serveurs sont dans le même pays. Le second est plus prosaïque : le support en français, sur le même fuseau horaire, avec quelqu’un qui répond. Ce n’est pas un argument de souveraineté, mais c’est souvent ce qui se remarque le plus après une migration.

À quoi ressemble une migration

La crainte principale porte sur l’interruption de service. Elle est légitime et elle se traite par la méthode.

On commence par un inventaire : ce qui tourne, où, avec quelles dépendances. Cette étape révèle presque toujours des choses oubliées, un vieux script sur un serveur que personne n’administre plus, un service tiers dont on ignorait qu’il stockait des données. Ce sont exactement les zones d’ombre qu’un bon suivi de maintenance applicative est censé empêcher de s’accumuler.

On monte ensuite l’environnement cible en parallèle, sans toucher à la production. Les données sont copiées, l’application est déployée, tout est testé pendant que l’ancien système continue de fonctionner normalement.

La bascule ne se décide qu’une fois les tests validés. Elle prend en général quelques minutes, à une heure choisie, avec un retour arrière préparé. L’ancien environnement reste disponible plusieurs jours par précaution.

Pour une application de PME, comptez de quelques jours à quelques semaines selon le volume de données et le nombre d’intégrations. Ce qui prend du temps, ce n’est presque jamais le transfert : ce sont les connexions avec les outils tiers, qu’il faut reconfigurer une par une.

Le RGPD, cousin mais pas jumeau

On confond souvent les deux sujets. Ils se recoupent sans se superposer.

Le RGPD encadre la façon dont vous traitez les données personnelles : sur quelle base légale, combien de temps, avec quels droits pour les personnes concernées. On peut être parfaitement conforme au RGPD en hébergeant hors d’Europe, à condition d’avoir un cadre de transfert valide et documenté.

À l’inverse, héberger en France ne vous rend pas conforme. Si votre registre des traitements n’existe pas, si vous conservez des CV depuis six ans ou si personne ne sait répondre à une demande d’effacement, le lieu de vos serveurs n’y changera rien.

Les deux vont bien ensemble, simplement parce que la souveraineté supprime la partie la plus fragile du dossier : celle des transferts internationaux, qui repose sur des accords régulièrement remis en cause par la justice européenne.

Ce qu’on en fait chez nous

Tous les projets que nous livrons sont hébergés en France sur une infrastructure OVHcloud, et la conformité RGPD est intégrée à la conception plutôt qu’ajoutée en fin de parcours. Non pas parce que chaque client y est légalement contraint, mais parce que faire l’inverse impose de justifier un choix par défaut moins protecteur.

Si vous vous demandez où en est votre situation, on peut auditer votre hébergement et votre conformité et vous dire ce qui mérite d’être changé, y compris quand la réponse est « rien pour l’instant ».