« Souverain » est devenu le mot le plus galvaudé du marketing cloud européen. Chaque fournisseur a désormais son offre souveraine, sa région souveraine ou son partenariat souverain. La plupart sont des progrès utiles. Peu survivent à une définition précise. Cet article en propose une.
Une définition opérationnelle
Une plateforme data est souveraine quand aucune entité extérieure à la juridiction que vous avez choisie ne peut accéder à vos données, les bloquer ou les saisir, et que vous pouvez quitter la plateforme sans les perdre. Cette phrase implique cinq propriétés testables.
1. La juridiction de l’opérateur, pas l’emplacement des machines
La question n’est jamais « où sont les serveurs ? » mais « qui peut être juridiquement contraint, et par qui ? ». Une plateforme opérée par une entité américaine est soumise au Cloud Act où que soient les serveurs. La souveraineté commence par la chaîne de détention de chaque opérateur de la stack : le fournisseur cloud, l’éditeur de la plateforme, les sous-traitants.
2. Des clés que vous détenez
Quiconque peut déchiffrer vos données peut y être contraint. Si l’éditeur détient vos clés de chiffrement, votre souveraineté est une promesse de politique interne. Si les clés restent dans votre propre compte et que les credentials sont chiffrées au repos, c’est un fait d’architecture.
3. Une résidence que vous pouvez prouver
« Résidence des données dans l’UE » ne devrait pas être une clause contractuelle à croire sur parole, mais une propriété vérifiable : ce bucket, cette région, ces fichiers. Quand un auditeur ou un client demande où vivent les données, la réponse doit être une requête, pas une réunion.
4. Des formats ouverts
Les formats de tables propriétaires transforment la souveraineté en dépendance déguisée : vos données sont peut-être en Europe, mais un seul moteur sait les lire. Les standards ouverts comme Apache Iceberg et Parquet garantissent que n’importe quel moteur, aujourd’hui ou dans dix ans, lira vos tables. Le verrouillage de format, c’est du verrouillage de juridiction avec un meilleur branding.
5. Une vraie sortie
Le test final est brutal et simple : résiliez le contrat dans votre tête et regardez ce qui se passe. Si vos données, vos pipelines et votre historique restent utilisables sur une infrastructure que vous contrôlez, la plateforme était souveraine. Sinon, vous louiez de la souveraineté, et le bail vient de s’arrêter.
Ce que la souveraineté n’est pas
Il faut être honnête sur l’inverse aussi, parce que la surenchère nuit à tout l’écosystème européen :
- La souveraineté n’est pas un nom de région. Une région UE chez un cloud non européen change la latence, pas la juridiction.
- La souveraineté n’est pas un communiqué de partenariat. Un revendeur local devant un opérateur étranger ne change pas qui peut être contraint.
- La souveraineté n’est pas l’isolement. Une plateforme souveraine peut très bien tirer des modèles ouverts du Hub Hugging Face ou alimenter des dashboards Power BI. Ce qui compte, c’est le sens de la dépendance : les choses peuvent entrer ; vos données ne sortent pas.
Le test en cinq questions
Avant de signer quoi que ce soit, demandez :
- Qui détient chaque entité opératrice de la chaîne ?
- Qui détient les clés ?
- Puis-je pointer le bucket et la région exacts où vivent mes données ?
- Un autre moteur peut-il lire mes tables sans cet éditeur ?
- Qu’est-ce qui survit si je pars demain ?
Une plateforme souveraine répond aux cinq d’un trait. Les réponses de Polnor : des entités européennes uniquement ; vos clés dans votre compte ; votre bucket OVHcloud ou Scaleway dans la région de votre choix ; de l’Apache Iceberg ouvert que tout le monde peut lire ; et tout survit, parce que tout a toujours été à vous.
Envie de passer votre stack actuelle au test ? Demandez une démo et venez avec les questions qui fâchent.