Le terme « cloud souverain » s’est progressivement installé dans le vocabulaire des entreprises, des administrations et des responsables publics.
Il semble offrir une réponse simple à une inquiétude elle-même facile à formuler : certaines données ou certains traitements sont devenus trop importants pour dépendre entièrement d’infrastructures que l’on ne maîtrise pas.
Mais dès que l’on cherche à définir précisément ce qu’est un cloud souverain, la simplicité disparaît.
Un serveur installé en France est-il souverain ?
Une entreprise européenne utilisant des logiciels américains l’est-elle ?
Une infrastructure opérée par une société française mais reposant sur des technologies étrangères peut-elle être considérée comme souveraine ?
Et souverain par rapport à quoi ?
Au droit d’un autre État ?
À un fournisseur ?
À une technologie ?
À une chaîne industrielle ?
À une incapacité à déplacer ses données ou ses applications ?
Le débat devient beaucoup plus clair lorsqu’on abandonne l’idée que la souveraineté serait une propriété binaire — souverain ou non souverain — pour la considérer comme un ensemble de dépendances qu’il faut identifier et maîtriser.
Le cloud n’est pas un lieu
L’expression elle-même entretient parfois une confusion.
Le cloud n’est pas un espace abstrait dans lequel les données seraient déposées.
Il repose sur des infrastructures parfaitement matérielles : centres de données, serveurs, processeurs, équipements réseau, systèmes de stockage, logiciels et connexions télécoms.
À cette infrastructure physique s’ajoutent plusieurs couches logicielles.
Virtualisation.
Systèmes d’exploitation.
Bases de données.
Services d’identité.
Outils de supervision.
Solutions de sauvegarde.
Plateformes applicatives.
Services d’intelligence artificielle.
Un même service peut donc dépendre de nombreux acteurs différents.
Le lieu où se trouve physiquement la donnée n’est qu’un élément parmi d’autres.
Il est important.
Mais il ne suffit pas à déterminer qui contrôle réellement le système.
La première souveraineté est juridique
La question la plus souvent évoquée est celle du droit applicable.
Une entreprise européenne peut exploiter un centre de données situé en Europe tout en appartenant à un groupe soumis à une législation étrangère.
La localisation physique des données et la juridiction à laquelle l’opérateur est soumis deviennent alors deux questions différentes.
C’est notamment cette problématique qui a contribué à populariser le débat européen sur la souveraineté du cloud.
L’objectif n’est pas nécessairement d’affirmer qu’un fournisseur étranger peut librement accéder à toutes les données qu’il héberge.
Les situations juridiques sont beaucoup plus complexes.
Il faut tenir compte de la nature des données, des contrats, des mécanismes de chiffrement, de l’entité juridique exploitant le service, des procédures judiciaires et des règles applicables dans les différents pays concernés.
Mais cette complexité constitue précisément le problème.
Une organisation peut souhaiter que certaines informations particulièrement sensibles ne dépendent pas d’un conflit de juridictions ou d’une interprétation juridique extérieure à son environnement habituel.
La souveraineté juridique consiste alors à déterminer quelles autorités peuvent imposer une décision au fournisseur ou à l’opérateur qui contrôle les données.
Héberger les données en Europe ne répond donc pas à tout
Il est tentant de résumer le problème par une règle simple :
« Les données doivent rester en Europe. »
Cette exigence peut avoir du sens.
Elle facilite certaines obligations réglementaires.
Elle réduit certaines formes de transfert international.
Elle permet aussi de savoir plus précisément où se trouvent les infrastructures.
Mais elle ne répond pas nécessairement à toutes les dépendances.
Un service hébergé dans un centre de données européen peut dépendre d’un logiciel dont l’éditeur contrôle les licences à distance.
Il peut utiliser une technologie propriétaire impossible à maintenir sans le fournisseur.
Il peut dépendre d’une plateforme d’administration étrangère.
Il peut être exploité par une entreprise dont la maison mère se trouve dans une autre juridiction.
Il peut enfin utiliser des composants matériels dont la production dépend d’un nombre très limité de pays ou d’industriels.
La localisation apporte donc une réponse à la question :
« Où sont les données ? »
Elle ne répond pas nécessairement à :
« Qui contrôle le système ? »
La souveraineté technique pose une autre question
Imaginons maintenant que les aspects juridiques soient maîtrisés.
L’infrastructure appartient à une société européenne.
Les serveurs sont situés en Europe.
Les contrats sont soumis au droit européen.
La souveraineté est-elle acquise ?
Pas nécessairement.
Il faut encore savoir si l’opérateur est techniquement capable de faire fonctionner son infrastructure sans dépendre de décisions prises ailleurs.
Un service cloud repose sur des logiciels complexes.
Certains sont ouverts.
D’autres sont propriétaires.
Certaines briques peuvent être remplacées.
D’autres sont profondément intégrées à l’architecture.
La souveraineté technique peut donc être comprise comme la capacité à maintenir, administrer, modifier ou remplacer les composants nécessaires au fonctionnement d’un système.
Cette capacité ne signifie pas qu’il faille tout produire soi-même.
Aucune infrastructure moderne n’est totalement indépendante.
Mais toutes les dépendances ne se valent pas.
Une bibliothèque logicielle peut être remplacée relativement facilement.
Une plateforme sur laquelle des centaines d’applications ont été construites pendant dix ans peut être beaucoup plus difficile à abandonner.
La dépendance apparaît souvent au moment où l’on veut partir
Cette question conduit directement au problème du vendor lock-in, ou enfermement propriétaire.
Au début d’un projet, le fournisseur cloud apporte généralement des avantages importants.
Les serveurs sont disponibles immédiatement.
Les bases de données sont administrées.
Les sauvegardes peuvent être automatisées.
Les outils de supervision sont déjà présents.
Des dizaines de services spécialisés peuvent être activés en quelques clics.
Cette richesse accélère considérablement le développement.
Mais chaque service propriétaire utilisé peut également augmenter le coût d’une future migration.
Une application construite autour de machines virtuelles relativement standards est généralement plus facile à déplacer qu’une application dépendant de nombreuses fonctions spécifiques à une plateforme.
Plus l’architecture exploite des services propriétaires, plus la dépendance augmente.
Elle n’est pas nécessairement mauvaise.
Une entreprise peut parfaitement accepter cette dépendance parce que les avantages économiques et techniques sont supérieurs au risque.
Le problème apparaît lorsqu’elle n’a jamais été mesurée.
La souveraineté consiste alors moins à refuser toute dépendance qu’à savoir combien coûterait la sortie.
Peut-on réellement changer de fournisseur ?
Cette question peut servir de test très concret.
Si le fournisseur augmente fortement ses prix, combien de temps faut-il pour partir ?
S’il abandonne une technologie utilisée par l’entreprise, existe-t-il une alternative ?
Si un conflit juridique bloque un service, combien de temps faut-il pour reconstruire l’environnement ailleurs ?
Les données peuvent-elles être exportées dans un format exploitable ?
Les applications peuvent-elles fonctionner sur une autre infrastructure ?
L’entreprise possède-t-elle les compétences nécessaires pour effectuer cette migration ?
Dispose-t-elle d’une documentation suffisante ?
Une stratégie de souveraineté réaliste doit pouvoir répondre à ces questions.
Ce qui compte n’est donc pas seulement la nationalité du fournisseur.
C’est aussi la réversibilité.
Une entreprise très dépendante d’un fournisseur local peut avoir moins d’autonomie opérationnelle qu’une autre utilisant un fournisseur international tout en ayant conçu une architecture réellement portable.
La souveraineté est également opérationnelle
Un autre niveau concerne les personnes qui administrent effectivement le système.
Qui possède les comptes les plus privilégiés ?
Qui peut modifier les règles réseau ?
Qui peut accéder aux sauvegardes ?
Qui peut déployer une mise à jour ?
Qui peut restaurer l’infrastructure après une panne ?
Une organisation peut juridiquement être propriétaire de ses données tout en ne possédant presque aucune capacité technique interne pour exploiter son environnement.
Elle dépend alors de son prestataire pour les opérations les plus essentielles.
Cette situation peut être parfaitement acceptable.
Externaliser est une stratégie normale.
Mais elle représente une dépendance opérationnelle qu’il faut identifier.
La souveraineté ne signifie pas obligatoirement tout administrer soi-même.
Elle consiste plutôt à conserver une capacité suffisante pour décider, contrôler et éventuellement reprendre la main.
La compétence devient une infrastructure
Cette dimension est souvent sous-estimée.
Une organisation peut posséder les serveurs, le code source et les données sans être réellement autonome si personne ne sait exploiter l’ensemble.
La compétence humaine devient donc elle-même une composante de la souveraineté.
Une technologie extrêmement complexe maîtrisée par trois personnes externes peut créer une dépendance plus forte qu’un service industriel largement documenté et utilisé.
La documentation compte.
La formation compte.
La disponibilité des compétences sur le marché compte.
La possibilité de changer de prestataire compte.
Une stratégie de souveraineté uniquement fondée sur la localisation des infrastructures ignore cette dimension pourtant essentielle.
Il existe aussi une souveraineté économique
Une autre dépendance apparaît lorsque quelques acteurs concentrent une part très importante du marché.
Les grandes plateformes cloud disposent d’un avantage considérable.
Elles investissent massivement.
Elles bénéficient d’économies d’échelle.
Elles proposent des centaines de services.
Elles disposent de réseaux mondiaux.
Elles peuvent acheter d’immenses volumes de matériel et de capacité électrique.
Cette puissance économique leur permet d’innover rapidement et souvent de proposer des services difficiles à reproduire pour de petits concurrents.
Mais elle crée également une asymétrie.
Une entreprise cliente représente parfois une fraction infime du chiffre d’affaires du fournisseur.
Son pouvoir de négociation peut être limité.
Elle dépend des évolutions tarifaires.
Elle dépend du calendrier de suppression ou de modification des services.
Elle dépend des choix stratégiques du fournisseur.
La souveraineté économique consiste alors à se demander si l’organisation conserve des alternatives réalistes.
Souveraineté ne signifie pas autarcie
L’une des difficultés du débat vient du mot lui-même.
« Souveraineté » peut donner l’impression que l’objectif serait de produire localement chaque élément nécessaire au numérique.
Ce serait irréaliste.
Un centre de données européen utilise des processeurs dont la conception ou la fabrication implique des entreprises situées dans différentes parties du monde.
Les équipements réseau dépendent de chaînes industrielles internationales.
Les logiciels utilisent des milliers de bibliothèques développées dans plusieurs pays.
Les disques, les mémoires, les systèmes de refroidissement et les équipements électriques suivent eux aussi des chaînes d’approvisionnement mondialisées.
Une souveraineté numérique absolue n’existe donc pratiquement pas.
La question pertinente est celle du niveau de dépendance acceptable.
Certaines dépendances sont facilement substituables.
D’autres constituent des points de concentration critiques.
La stratégie consiste à distinguer les deux.
Le logiciel libre ne résout pas tout, mais change certaines dépendances
L’open source occupe naturellement une place importante dans cette réflexion.
Lorsque le code d’un logiciel est disponible, l’organisation ne dépend pas exclusivement de l’éditeur initial pour comprendre son fonctionnement ou poursuivre son développement.
Elle peut théoriquement changer de prestataire.
Elle peut héberger le logiciel elle-même.
Elle peut auditer certaines parties du code.
Elle peut conserver une version même si l’entreprise qui le développe modifie sa stratégie commerciale.
Cela améliore certaines formes d’autonomie.
Mais l’open source ne supprime pas toutes les dépendances.
Un logiciel extrêmement complexe peut être ouvert tout en restant très difficile à maintenir.
Une communauté peut disparaître.
Des composants peuvent contenir des vulnérabilités.
Une entreprise peut être techniquement libre de reprendre un projet sans disposer des ingénieurs capables de le faire.
L’ouverture du code augmente donc la possibilité de contrôle.
Elle ne garantit pas automatiquement la capacité réelle à l’exercer.
Le chiffrement peut réduire certains risques
La maîtrise des clés cryptographiques constitue également un élément important.
Une organisation qui chiffre ses données avec des clés qu’elle contrôle elle-même limite ce que l’opérateur de l’infrastructure peut en faire.
Ce principe peut permettre de réduire certaines dépendances sans nécessairement changer de fournisseur.
Mais là encore, les détails comptent.
Qui possède réellement la clé ?
Où est-elle stockée ?
Qui peut demander son utilisation ?
Le fournisseur peut-il accéder aux données pendant leur traitement ?
Le chiffrement couvre-t-il uniquement le stockage ou également les communications ?
Quelles sont les procédures de récupération ?
Un slogan comme « données chiffrées » ne suffit donc pas davantage que « données hébergées en Europe ».
Il faut comprendre le modèle de contrôle.
Le cloud souverain peut être différent selon les données
Toutes les informations d’une organisation n’ont pas la même sensibilité.
Le site institutionnel d’une entreprise ne présente pas nécessairement les mêmes enjeux qu’un dossier médical.
Un catalogue public n’a pas les mêmes exigences qu’un système militaire.
Une plateforme de développement n’a pas nécessairement les mêmes contraintes qu’une base contenant des informations stratégiques.
Appliquer la même architecture de souveraineté à tous les systèmes peut donc devenir extrêmement coûteux sans apporter de bénéfice proportionné.
Une stratégie plus rationnelle consiste à classer les usages.
Certaines données peuvent être placées dans un cloud public classique.
D’autres nécessitent des garanties contractuelles supplémentaires.
Certaines applications doivent pouvoir être rapidement déplacées.
D’autres peuvent nécessiter une infrastructure entièrement contrôlée.
La souveraineté devient ainsi une question d’architecture adaptée au risque.
Le multicloud n’est pas automatiquement souverain
Pour réduire la dépendance, certaines organisations choisissent plusieurs fournisseurs.
L’idée paraît logique.
Si un fournisseur devient indisponible, un autre peut prendre le relais.
Mais utiliser trois clouds différents ne garantit pas nécessairement l’indépendance.
Une application peut utiliser trois fournisseurs tout en restant profondément dépendante d’un seul pour une fonction critique.
La complexité supplémentaire peut également devenir une nouvelle faiblesse.
Trois plateformes signifient trois systèmes d’administration.
Trois modèles de sécurité.
Trois ensembles de compétences.
Trois systèmes de facturation.
Le multicloud peut améliorer la résilience lorsqu’il répond à une architecture pensée pour cela.
Il peut également simplement multiplier les dépendances.
La souveraineté doit être mesurable
Le terme deviendrait probablement plus utile s’il était traduit en critères concrets.
Pour une application donnée, une organisation pourrait par exemple examiner :
la juridiction applicable ;
la localisation des données ;
la maîtrise des clés de chiffrement ;
la dépendance à des technologies propriétaires ;
la portabilité des données ;
la portabilité des applications ;
le délai nécessaire pour changer de fournisseur ;
la disponibilité d’un fournisseur alternatif ;
la capacité interne à administrer le système ;
la dépendance aux mises à jour du fournisseur ;
la capacité à fonctionner temporairement sans lui.
La question ne serait alors plus :
« Ce cloud est-il souverain ? »
Mais :
« Quelles dépendances avons-nous acceptées et quelles capacités avons-nous conservées ? »
La réponse devient beaucoup plus utile.
Une organisation peut accepter consciemment une dépendance
La souveraineté ne doit pas devenir un objectif absolu qui écraserait tous les autres.
Une entreprise doit également être compétitive.
Elle doit développer rapidement.
Elle doit maîtriser ses coûts.
Elle doit accéder à des technologies performantes.
Elle doit recruter des compétences disponibles.
Un service cloud international peut parfaitement constituer le meilleur choix pour de nombreux usages.
L’enjeu est de ne pas confondre choix volontaire et dépendance subie.
Une dépendance connue peut être gérée.
Elle peut faire l’objet d’un plan de continuité.
Elle peut être compensée par des sauvegardes externes.
Elle peut être contractualisée.
Elle peut être limitée aux données non sensibles.
Une dépendance inconnue ne peut pas être pilotée.
L’intelligence artificielle rend la question encore plus complexe
L’arrivée massive de l’intelligence artificielle dans le cloud ajoute une nouvelle couche.
Une entreprise peut désormais dépendre non seulement d’une infrastructure, mais d’un modèle.
Le modèle peut évoluer.
Son prix peut changer.
Certaines fonctionnalités peuvent apparaître ou disparaître.
La politique d’utilisation peut être modifiée.
Les données peuvent être envoyées vers une API distante.
Une application entière peut être construite autour d’un modèle dont l’entreprise ne contrôle ni les paramètres ni l’évolution.
Les mêmes questions réapparaissent donc :
Peut-on remplacer ce modèle ?
Les données peuvent-elles rester locales ?
L’application fonctionnera-t-elle avec un autre fournisseur ?
Existe-t-il un modèle ouvert permettant de conserver un fonctionnement minimal ?
Le cloud souverain et l’IA souveraine commencent ainsi à se rejoindre.
La souveraineté est finalement une capacité de choix
Le débat sur le cloud souverain devient beaucoup plus simple lorsqu’on abandonne l’idée d’une indépendance totale.
Une organisation souveraine n’est pas nécessairement une organisation qui ne dépend de personne.
C’est une organisation qui connaît ses dépendances et conserve suffisamment d’alternatives pour pouvoir décider.
Elle sait où se trouvent ses données.
Elle sait à quels droits elles sont soumises.
Elle sait qui possède les privilèges administratifs.
Elle sait quelles technologies seraient difficiles à remplacer.
Elle sait combien coûterait une migration.
Elle sait quelles fonctions doivent absolument rester disponibles.
Elle sait ce qu’elle peut reprendre elle-même et ce qu’elle a choisi d’externaliser.
Dans cette perspective, le cloud souverain n’est plus un produit que l’on achète.
C’est une architecture de dépendances que l’on organise.
La localisation européenne peut en faire partie.
Le droit européen également.
L’open source peut en faire partie.
La maîtrise des clés cryptographiques.
La portabilité.
Les compétences internes.
Les contrats.
Les solutions de secours.
Aucun de ces éléments ne suffit seul.
La vraie souveraineté commence lorsque l’organisation peut répondre à une question beaucoup plus concrète que « où sont mes serveurs ? » :
« Si demain je ne peux plus, ou ne veux plus, dépendre de ce fournisseur, qu’est-ce que je suis encore capable de faire ? »
Commentaires 0
Aucun commentaire pour le moment.