Souveraineté des données : opérer au plus près du terrain

La souveraineté des données est devenue une exigence incontournable. Les régulateurs demandent, de plus en plus, que les données sensibles restent dans le pays. L'intention est légitime. Le problème, c'est qu'elle se heurte à une réalité technique brutale : sur la plupart de nos marchés, l'infrastructure locale n'est pas au niveau de ce qu'offrent les grands fournisseurs de cloud.

On se retrouve donc face à deux injonctions qui tirent dans des sens opposés. D'un côté, garder la donnée localement. De l'autre, tenir un niveau de fiabilité et de sécurité que seul, aujourd'hui, le cloud permet d'atteindre. Prétendre que ces deux exigences se concilient sans effort serait malhonnête. La souveraineté des données est un arbitrage, pas un slogan, et le faire correctement demande de regarder le problème en face.

Deux injonctions contradictoires

D'un côté, la pression réglementaire est réelle et croissante. Localiser certaines données n'est plus une option mais une condition d'exercice. De l'autre, ce que l'on sait faire sur AWS, GCP ou Azure, à savoir une disponibilité élevée, une élasticité immédiate et une sécurité industrialisée, n'a pas d'équivalent local clé en main. La marche est haute, et faire comme si elle n'existait pas conduit droit à des promesses intenables.

Le piège serait de choisir un camp par confort : tout cloud en ignorant la contrainte légale, ou tout local en ignorant la réalité technique. Les deux postures se paient. La première en risque de conformité, la seconde en risque opérationnel. La bonne réponse commence par nommer honnêtement ce que chaque option coûte vraiment.

Local veut dire on-premise, et ça change tout

Dans nos contextes, exiger du local revient presque toujours à faire de l'on-premise : héberger soi-même, sur ses propres serveurs, dans un datacenter local. Ce n'est pas une variante du cloud, c'est un autre métier. Les contraintes changent de nature : compétences rares à recruter et à retenir, délais de déploiement qui se comptent en semaines plutôt qu'en minutes, coûts d'investissement et d'exploitation bien plus lourds.

Et ce n'est pas qu'une question de budget ou de temps. C'est surtout une question de sécurité et de conformité. Tout ce qu'un fournisseur de cloud industrialise et certifie, la sécurité physique, le chiffrement, la gestion des accès, la conformité de l'infrastructure, doit désormais être assuré, prouvé et maintenu en interne. Ce qui était délégué redevient une charge complète.

Le grand perdant : la responsabilité partagée

C'est le point le plus sous-estimé. Le cloud fonctionne sur un modèle de responsabilité partagée : le fournisseur répond de la sécurité de l'infrastructure sur des périmètres précis et certifiés, et l'on se concentre sur la sécurité de son application. En passant à l'on-premise, cette part de responsabilité déléguée disparaît. On hérite de toute la pile, du serveur physique jusqu'au correctif de sécurité du système.

Pire, les infrastructures et les serveurs disponibles localement ne sont souvent pas au niveau de ce que l'on trouve dans le cloud. Matériel plus ancien, redondance moindre, exploitation moins mature : on assume davantage de responsabilité sur un socle qui, par ailleurs, offre moins de garanties. C'est l'inverse du compromis qu'on aimerait faire.

La vraie valeur du local : la continuité

Faut-il pour autant rejeter le local ? Non, car il apporte une valeur que le cloud lointain ne donne pas : la continuité quand le lien vers l'extérieur se rompt. Une bonne partie de la connectivité du continent dépend de câbles sous-marins. Le jour où une fibre est coupée au large, l'accès aux services hébergés à l'autre bout de la planète se dégrade ou s'effondre. Avec la donnée et le traitement en local, le service, lui, continue de tourner.

C'est là, et peut-être là seulement, que réside le vrai gain de souveraineté : non pas dans une case cochée pour le régulateur, mais dans la capacité à continuer de servir les utilisateurs quand le reste du monde devient inaccessible. Pour une plateforme transactionnelle critique, cette continuité n'est pas un luxe.

À cette continuité s'ajoute un gain plus discret mais quotidien : la latence. Plus la donnée et le traitement sont proches de l'utilisateur, plus la réponse est rapide. Sur un paiement à la caisse ou une prise de jeu à quelques secondes du tirage, ces millisecondes gagnées se ressentent directement. Rapprocher l'infrastructure, ce n'est donc pas seulement une assurance contre la rupture du lien sous-marin, c'est aussi de la réactivité à chaque opération, tout le reste du temps.

Mais le local a ses propres pannes

Il faut toutefois résister à l'idéalisation du local. Garder la donnée près de soi ne met pas à l'abri des pannes, cela en change la nature. Les datacenters locaux subissent des coupures de courant qui provoquent des arrêts de service, et le phénomène touche jusqu'aux opérateurs télécoms. La continuité gagnée sur le câble sous-marin peut se reperdre sur le réseau électrique.

Autrement dit, le local résout un problème de dépendance externe et en crée un d'infrastructure interne. Choisir l'on-premise sans traiter sérieusement l'alimentation, la redondance et l'exploitation, c'est déplacer le point de fragilité, pas le supprimer. Une souveraineté mal conçue peut très bien être moins fiable que le cloud qu'elle prétend remplacer.

Concilier : l'hybride et la réplication

La voie réaliste n'est ni le tout-cloud ni le tout-local. C'est l'hybride, pensé donnée par donnée. On tire parti de la robustesse et de l'élasticité du cloud là où elles font la différence, tout en gardant localement une réplique des données sensibles et de quoi continuer à fonctionner quand l'extérieur tombe. La donnée vit à deux endroits, et le système est conçu pour basculer sans perdre la main.

Cette approche ne supprime aucune des difficultés évoquées, elle les répartit. Elle demande de décider, pour chaque donnée, où elle réside, comment elle est répliquée, quelle latence et quelle obligation locale elle porte. C'est plus exigeant qu'un choix unique et définitif, mais c'est la seule façon de tenir à la fois la conformité, la continuité et la fiabilité.

Décider donnée par donnée

La souveraineté des données ne se résout pas par un principe, elle se construit par une série d'arbitrages lucides. Il faut accepter que le local coûte cher et reporte sur soi une responsabilité que le cloud absorbait, tout en reconnaissant qu'il apporte une continuité irremplaçable le jour où le câble lâche. Entre les deux, l'hybride et la réplication locale offrent un compromis tenable.

C'est ce travail que nous menons, sans le vendre comme une évidence. Concevoir une plateforme souveraine, ce n'est pas planter un serveur dans un pays pour cocher une case. C'est arbitrer, donnée par donnée, entre l'obligation, la fiabilité et la continuité, puis opérer ce qu'on a conçu avec la même exigence des deux côtés de la frontière.