Cloud souverain : alternative crédible aux géants américains ?

Le cloud n’est plus un simple poste technique que l’on délègue à la DSI. Il touche désormais à la conformité, à la continuité d’activité, aux coûts et à la capacité d’une entreprise à garder la main sur ses actifs numériques. Pendant longtemps, AWS, Microsoft Azure et Google Cloud ont imposé leur rythme : catalogue immense, déploiement rapide, services d’IA, réseau mondial. Leur avance reste réelle. Pourtant, confier des données clients, des documents RH, des applications métier ou des modèles d’IA à des fournisseurs soumis au droit américain pose une question très concrète : qui contrôle réellement l’information lorsque survient un litige, une demande administrative ou une crise géopolitique ?

Le cloud souverain répond à cette question sans promettre de miracle. Il ne consiste pas seulement à placer des serveurs en France. Il repose sur un ensemble cohérent : gouvernance européenne, hébergement local, protections juridiques, certifications, réversibilité et exploitation maîtrisée. Pour une startup SaaS, une PME industrielle, une collectivité ou un cabinet médical, le sujet n’est donc pas idéologique. Il s’agit de réduire un risque opérationnel tout en conservant l’agilité nécessaire pour automatiser, déployer et faire évoluer ses services numériques.

En bref

• Les hyperscalers américains gardent une avance technologique et une part très majoritaire du marché européen du cloud.
• Le Cloud Act américain peut concerner des données hébergées en Europe lorsqu’un prestataire dépend d’une entreprise américaine.
• OVHcloud, Scaleway, Outscale, Clever Cloud et Leviia couvrent aujourd’hui des besoins allant du stockage objet au cloud certifié pour les environnements sensibles.
• La souveraineté ne remplace pas une stratégie de sécurité : sauvegardes, chiffrement, IAM, journalisation et tests de reprise restent indispensables.
• Une migration utile commence par les données critiques et les charges de travail les plus simples à rendre réversibles.

Cloud souverain : pourquoi AWS, Azure et Google Cloud ne sont plus des choix neutres

Le succès des fournisseurs américains s’explique facilement. Une équipe peut créer une machine virtuelle en quelques minutes, appeler une API d’IA, mettre en place une base de données managée et distribuer son application à l’international sans acheter le moindre serveur. Pour un produit qui cherche son marché, cette vitesse compte. Dans le business en ligne, retarder un lancement de six mois pour construire une infrastructure parfaite n’a souvent aucun sens.

Le problème apparaît lorsque la facilité devient une dépendance. Une entreprise comme « Atelier Nord », une PME fictive qui édite un logiciel de maintenance pour usines, peut démarrer sur AWS avec une logique saine : peu de frais initiaux, capacité à monter en charge, documentation abondante. Trois ans plus tard, son application contient des données de production, des contrats, des informations sur les techniciens et des historiques de pannes. Changer de prestataire devient alors plus difficile, car les bases de données, les services de messagerie, les scripts et les droits d’accès ont été construits autour d’un écosystème propriétaire.

Le Cloud Act et le RGPD : deux cadres qui ne répondent pas à la même logique

Le Cloud Act permet aux autorités américaines de demander l’accès à des données détenues ou contrôlées par des entreprises américaines, y compris lorsque les données sont stockées hors des États-Unis. Le sujet est complexe juridiquement, mais l’impact business est simple : une localisation physique en Europe ne suffit pas, à elle seule, à éliminer toute exposition extraterritoriale.

Le RGPD impose, lui, des règles sur le traitement des données personnelles : minimisation, finalité, sécurité, droits des personnes et encadrement des transferts internationaux. Il ne dit pas qu’un acteur américain est automatiquement interdit. En revanche, il oblige l’entreprise cliente à démontrer que les garanties appliquées sont adaptées. Pour des données sensibles, cette démonstration peut devenir lourde, coûteuse et fragile.

Les tensions politiques et commerciales entre grandes puissances renforcent cette prudence. Le Transatlantic Data Privacy Framework a amélioré certains mécanismes de transfert, mais il ne transforme pas la dépendance numérique en détail anodin. Une stratégie digitale sérieuse doit prévoir ce qui se passe si les règles changent, si les prix augmentent ou si un fournisseur modifie ses conditions d’usage.

La souveraineté numérique devient un sujet de continuité d’activité

La souveraineté n’est pas une médaille à afficher sur une page d’accueil. C’est une capacité à décider. Décider où les données résident, qui administre les infrastructures, comment les récupérer et sous quel droit elles sont protégées. Cette logique rejoint les enjeux détaillés dans la souveraineté numérique des entreprises : la question touche autant le comité de direction que les équipes techniques.

En 2025, les cyberattaques et les indisponibilités ont rappelé une évidence : une donnée compromise ou inaccessible peut coûter bien plus cher que l’hébergement. L’attaque ayant affecté Marks & Spencer au printemps 2025, avec des pertes estimées à plusieurs centaines de millions d’euros, illustre l’ampleur potentielle d’un incident numérique. Le cloud ne crée pas ces risques, mais il peut les amplifier lorsqu’aucune architecture de secours, aucune sauvegarde isolée et aucun plan de reprise ne sont prévus.

Le cloud souverain n’est donc pas un rejet automatique du cloud public : c’est un choix de contrôle pour les actifs qui ne peuvent pas devenir une variable externe.

Alternatives françaises à AWS : quels fournisseurs répondent aux besoins réels ?

Un cloud souverain crédible ne se choisit pas sur un drapeau affiché dans une présentation commerciale. Il faut examiner le modèle de gouvernance, les lieux d’hébergement, les certifications, les contrats, l’interopérabilité et le niveau de support. Les offres françaises ne reproduisent pas toutes le catalogue de plusieurs centaines de services d’AWS. Ce n’est pas toujours un défaut. Une PME n’a pas nécessairement besoin de tout ; elle a besoin de services fiables, documentés et compatibles avec son stack.

Leviia, Scaleway et OVHcloud : trois réponses à des problèmes différents

Leviia vise un besoin très précis : stocker, partager et sauvegarder des fichiers sans transformer la facture en puzzle. Son offre de stockage objet compatible S3 permet à une application existante de conserver une partie de ses appels API. La triple géo-répartition en France apporte une protection utile contre la perte d’un site. L’absence de frais de sortie ou de facturation opaque sur certaines opérations répond aussi à un irritant bien connu du cloud : découvrir le prix réel après avoir déplacé plusieurs téraoctets.

Scaleway convient davantage aux équipes qui construisent et déploient des applications. Instances, Kubernetes managé, bases de données, stockage objet et API ouvertes permettent de travailler avec des pratiques modernes. Une startup qui utilise Docker, Terraform et GitLab CI peut industrialiser son infrastructure sans basculer dans un environnement totalement fermé. C’est une approche cohérente pour une stratégie d’automatisation : moins de clics dans une console, plus de configuration versionnée.

OVHcloud propose un spectre plus large, du serveur dédié au cloud privé en passant par les environnements managés. Son intérêt est fort lorsque l’entreprise a déjà des contraintes hybrides, des logiciels historiques ou des besoins de capacité importants. Certains parcours demandent davantage de compétences techniques. Ce n’est pas un détail : un outil puissant mais mal administré devient vite une source d’incidents et de coûts inutiles.

Outscale, Clever Cloud et les intégrateurs spécialisés

Outscale, marque de Dassault Systèmes, s’adresse aux contextes où la sécurité, l’audit et la qualification pèsent plus lourd que la recherche du service le plus exotique. Sa certification SecNumCloud en fait une option structurante pour les secteurs soumis à des contraintes élevées. Les entreprises qui suivent les évolutions de l’écosystème industriel peuvent aussi consulter les innovations de Dassault à Vélizy pour mieux comprendre les dynamiques autour de l’industrie, de la simulation et des plateformes numériques.

Clever Cloud prend le problème par l’autre bout : l’équipe livre son code, la plateforme gère une grande partie du déploiement et de l’exécution. Pour un éditeur SaaS, cela peut réduire la charge d’exploitation. Un PaaS ne dispense pas de penser sécurité, mais il évite de consacrer chaque semaine des heures à administrer des serveurs qui n’apportent aucune valeur directe au produit.

La bonne alternative n’est pas celle qui imite AWS service par service : c’est celle qui couvre le besoin métier sans enfermer l’entreprise dans une dette technique supplémentaire.

Infrastructure souveraine et DevOps : automatiser sans perdre le contrôle

Une migration vers un fournisseur européen échoue souvent pour une mauvaise raison : l’entreprise essaie de déplacer tout son système d’un seul coup. C’est le réflexe du grand chantier, celui qui immobilise les équipes, multiplie les exceptions et finit par repousser la bascule. Une approche plus pragmatique consiste à commencer par une charge de travail isolée : sauvegardes, stockage de médias, environnement de préproduction ou outil interne non critique.

Reprenons Atelier Nord. L’entreprise peut d’abord transférer les archives et les pièces jointes vers un stockage objet français. Ensuite, elle déploie son environnement de test sur une infrastructure européenne. Enfin, elle migre progressivement les services applicatifs qui reposent sur des standards ouverts. Cette séquence permet de mesurer les performances, les coûts et la qualité du support avant de toucher au cœur de production.

Infrastructure as Code : la meilleure assurance contre l’improvisation

Terraform et Ansible sont devenus des outils centraux pour décrire une infrastructure sous forme de fichiers versionnés. Au lieu de créer manuellement des réseaux, des instances et des règles de pare-feu, l’équipe écrit une configuration, la relit, la teste et la déploie. Le gain ne se limite pas à la vitesse. Il apporte une traçabilité indispensable pour les audits, la conformité et la reprise après incident.

Une infrastructure souveraine bien conçue utilise des composants portables : Docker pour empaqueter les applications, Kubernetes pour orchestrer les conteneurs, Terraform pour provisionner les ressources et Git pour conserver l’historique. Scaleway avec Kapsule ou OVHcloud avec Managed Kubernetes peuvent s’intégrer dans cette logique. L’objectif n’est pas d’empiler les outils parce qu’ils sont à la mode. L’objectif est de réduire la dépendance aux actions manuelles et aux services propriétaires impossibles à remplacer.

Le même principe vaut pour la CI/CD. GitLab CI, Jenkins ou une autre solution peuvent lancer les tests, analyser le code, construire les images Docker et déployer un environnement de test. Chaque modification laisse une trace. Lorsqu’un incident survient, l’équipe sait quelle version a été déployée, à quel moment et avec quelle configuration. Automatiser sans comprendre, c’est accélérer ses erreurs ; automatiser avec des règles claires, c’est rendre le système reproductible.

Kubernetes, open source et réversibilité opérationnelle

Kubernetes est souvent présenté comme une réponse universelle. Ce n’est pas le cas. Une application simple peut très bien fonctionner sur une machine virtuelle correctement configurée. En revanche, pour une plateforme composée de plusieurs services, avec des déploiements fréquents et des besoins de montée en charge, il offre une couche d’abstraction utile. Il faut simplement prévoir les compétences nécessaires : supervision, gestion des secrets, sauvegarde des volumes et mises à jour.

L’open source joue ici un rôle stratégique. Prometheus, Grafana, Loki, ELK, Vault ou Trivy permettent de construire une chaîne de supervision et de sécurité portable. Si le fournisseur change, l’entreprise ne doit pas réinventer l’ensemble de son exploitation. Elle déplace ses workloads, adapte ses connecteurs et conserve ses pratiques. Cette logique rejoint les évolutions décrites dans les tendances du cloud computing, où l’hybride et le multicloud deviennent des choix de résilience plutôt que des effets de mode.

Le vrai indicateur de maturité n’est pas le nombre d’outils utilisés : c’est la capacité à recréer l’environnement ailleurs, vite et proprement.

Cloud souverain et sécurité : SecNumCloud, sauvegardes et protection des données sensibles

Un fournisseur local n’est pas automatiquement un fournisseur sûr. La sécurité se construit par couches. Une infrastructure peut être hébergée en France et rester vulnérable si les comptes administrateurs ne sont pas protégés, si les sauvegardes sont accessibles depuis la production ou si les mises à jour sont oubliées. La localisation est une brique de confiance. Elle ne remplace ni le chiffrement ni les procédures.

La qualification SecNumCloud, portée par l’ANSSI, constitue un repère fort pour les environnements les plus sensibles. Elle évalue la sécurité technique, l’organisation, la gestion des accès, la chaîne de sous-traitance et les garanties de protection contre certaines lois extraterritoriales. Elle ne concerne pas toutes les offres d’un fournisseur de manière globale : il faut vérifier précisément le service, le périmètre et la version contractuelle visée.

Construire un socle de sécurité qui résiste aux erreurs humaines

Dans la pratique, le risque le plus courant ne vient pas toujours d’une attaque spectaculaire. Il peut s’agir d’un bucket de stockage rendu public, d’une clé API envoyée par erreur dans un dépôt Git, d’un compte administrateur partagé ou d’une sauvegarde jamais testée. Ces erreurs arrivent même aux équipes solides. La réponse n’est pas de culpabiliser. Elle consiste à mettre en place des garde-fous.

1. Activer l’authentification multifacteur sur tous les comptes à privilèges et supprimer les accès partagés.
2. Chiffrer les données en transit et au repos, avec une gestion des clés documentée.
3. Séparer production, test et sauvegardes afin qu’un incident ne touche pas tout le système.
4. Journaliser les actions critiques et centraliser les logs pour détecter rapidement un comportement anormal.
5. Tester la restauration régulièrement : une sauvegarde non restaurée reste une hypothèse, pas une protection.

Pour Atelier Nord, cela signifie que les données de production ne doivent pas être copiées intégralement dans l’environnement de test. Des jeux de données anonymisés suffisent dans la majorité des cas. Les accès aux clients doivent suivre le principe du moindre privilège. Et le plan de reprise doit être testé au moins une fois par an avec un scénario crédible : panne de zone, ransomware ou erreur de suppression.

Les données d’IA exigent une vigilance supplémentaire

Les usages de l’IA générative font entrer de nouvelles données dans le cloud : prompts, documents internes, conversations clients, corpus de formation et résultats d’analyse. Envoyer un contrat, un fichier médical ou un code source vers une API sans vérifier les conditions de traitement peut créer un risque de confidentialité. L’IA ne remplace pas le cadre de gouvernance. Elle accélère simplement les flux d’information.

Les entreprises peuvent privilégier des modèles open source déployés sur une infrastructure européenne, limiter les données envoyées aux fournisseurs externes et définir des règles simples : quels documents peuvent être traités, quels identifiants doivent être masqués, qui valide les nouveaux outils. Cette approche est particulièrement utile pour les organisations qui utilisent déjà des objets connectés ou des données de terrain. Les enjeux liés à l’IoT industriel et la performance montrent bien que la donnée opérationnelle peut vite devenir critique.

La souveraineté utile commence par une question basique : si cette donnée fuit ou devient indisponible demain matin, quel impact concret cela aura-t-il sur l’activité ?

Coûts, performance et migration : rendre le cloud souverain rentable dans la durée

Le prix affiché d’une instance ne dit presque rien du coût réel d’une infrastructure. Les hyperscalers proposent des services extrêmement riches, mais leur facturation peut devenir difficile à lire : trafic sortant, appels API, snapshots, logs, adresses IP, transfert inter-zone, licences et support. Une startup peut démarrer avec une facture modeste puis voir ses dépenses grimper à mesure que le trafic, les sauvegardes et les automatisations se développent.

Les fournisseurs français et européens ont souvent un avantage : des grilles tarifaires plus directes et un support plus proche. Cela ne veut pas dire qu’ils sont toujours moins chers. Un workload très spécifique, nécessitant une région mondiale, un GPU particulier ou un service managé avancé peut rester plus compétitif chez un hyperscaler. Il faut comparer le coût total, pas seulement le prix mensuel de la machine.

FinOps : mesurer avant d’optimiser

Le FinOps consiste à rapprocher finance, technique et métier pour piloter les dépenses cloud. Dans une petite équipe, cela peut être très simple : un tableau de bord hebdomadaire, des tags de ressources, des alertes budgétaires et une revue mensuelle. Dans une grande organisation, il faut aller plus loin avec une allocation par produit, client ou environnement.

Atelier Nord peut identifier que son stockage de logs coûte plus que ses serveurs applicatifs. La solution n’est pas forcément de supprimer les logs. Elle peut définir une rétention de 30 jours en accès chaud, archiver les données plus anciennes et éviter les doublons. Elle peut aussi arrêter automatiquement les environnements de démonstration le soir. Ce sont des optimisations peu glamour, mais elles améliorent directement le ROI.

Les frais de sortie constituent un autre point de vigilance. Une entreprise doit pouvoir récupérer ses données sans payer une somme disproportionnée. La réversibilité se prépare dès le départ : formats standards, documentation des flux, exports testés et absence de dépendance inutile à une fonction propriétaire. Le meilleur moment pour penser à quitter un fournisseur est avant de signer, pas pendant une crise.

Un plan de migration progressif qui évite le grand saut

Une migration propre suit généralement une logique en plusieurs étapes. D’abord, l’entreprise cartographie ses applications, ses dépendances et ses données. Ensuite, elle classe les workloads selon leur criticité et leur difficulté de déplacement. Les services simples et peu risqués servent de terrain de test. Les applications centrales sont traitées après validation des performances, de la sécurité et du support.

Il est utile de prévoir des métriques avant le premier déplacement : temps de réponse, taux d’erreur, temps de restauration, coût mensuel, consommation CPU et satisfaction des équipes. Sans ces indicateurs, le débat reste théorique. Avec eux, la décision devient factuelle. Une stratégie hybride est souvent la plus réaliste : conserver certains services mondiaux chez un hyperscaler tout en plaçant les données sensibles, les sauvegardes et les applications réglementées chez un acteur souverain.

AWS n’est pas une fatalité, mais le remplacer sans méthode ne produit pas plus d’indépendance : cela déplace seulement le problème.

Un cloud hébergé en France est-il automatiquement souverain ?

Non. La localisation des serveurs est importante, mais la gouvernance du fournisseur, les contrats, la chaîne de sous-traitance et l’exposition à des lois extraterritoriales doivent aussi être vérifiées.

Quelle différence entre SecNumCloud, ISO 27001 et HDS ?

ISO 27001 porte sur le système de management de la sécurité de l’information. HDS concerne l’hébergement de données de santé. SecNumCloud est une qualification de l’ANSSI avec des exigences fortes de sécurité et de souveraineté pour des services cloud précis.

Peut-on migrer une application AWS vers Scaleway ou OVHcloud sans tout réécrire ?

Oui, surtout si l’application repose sur des standards comme Docker, PostgreSQL, Kubernetes, S3, Terraform et des API ouvertes. Les services propriétaires AWS peuvent toutefois demander une adaptation ou un remplacement.

Le cloud souverain coûte-t-il plus cher ?

Pas systématiquement. Le coût dépend des ressources, du stockage, du trafic, du support, des frais de sortie et du temps d’exploitation. Une analyse FinOps permet de comparer le coût total plutôt qu’un simple tarif d’instance.