Cloud souverain : par où commencer sans tout casser
Migrer vers un hébergement européen ne se décide pas sur un coup de tête, et ne se fait pas non plus en un week-end. Voici la méthode que nous appliquons chez nos clients.
Publié par L'équipe Noyau Digital
La question revient dans presque tous nos cadrages depuis deux ans : faut-il quitter les hyperscalers américains ? La réponse honnête est « ça dépend », mais la façon d'y répondre, elle, peut être méthodique.
Commencer par cartographier, pas par migrer
Avant toute décision, il faut savoir ce que l'on héberge et où. Dans la moitié des audits que nous menons, le client découvre des dépendances qu'il ignorait : un service de mail transactionnel, un bucket de sauvegarde oublié, une brique d'authentification tierce.
Nous produisons systématiquement trois listes :
- les données personnelles au sens du RGPD ;
- les données stratégiques dont la fuite serait un problème commercial ;
- tout le reste, qui n'a pas vocation à contraindre l'architecture.
Cette dernière catégorie est souvent la plus grosse, et c'est une bonne nouvelle : elle réduit d'autant le périmètre à traiter en priorité.
Distinguer souveraineté et localisation
Héberger en France ne suffit pas à échapper au CLOUD Act si le prestataire est une filiale d'un groupe américain. Inversement, un hébergeur européen mal configuré n'apporte aucune garantie supplémentaire.
La souveraineté est une propriété du contrat et de l'architecture, pas seulement de l'adresse du datacenter.
Les critères que nous regardons sont la nationalité de la maison mère, le droit applicable au contrat, la localisation des équipes d'exploitation, et la réversibilité effective — c'est-à-dire : peut-on partir, et à quel coût ?
Migrer par tranches, jamais d'un bloc
Une migration réussie ressemble rarement à un grand soir. Elle ressemble à ceci :
- Les nouveaux projets d'abord. Tout ce qui démarre part directement sur le socle cible. Aucune reprise, aucun risque.
- Le stateless ensuite. Les services sans état se déplacent presque sans douleur, et permettent de roder l'outillage.
- Les données en dernier. C'est la partie coûteuse et risquée ; on l'aborde une fois que l'équipe maîtrise le nouvel environnement.
Sur un système d'information de taille moyenne, ce parcours prend entre neuf et dix-huit mois. Toute promesse plus courte mérite d'être regardée de près.
Le coût réel n'est pas celui de la facture
Le prix affiché d'un hébergeur européen est fréquemment inférieur à celui d'un hyperscaler. Ce n'est pas là que se joue l'écart. Le coût réel se situe dans :
- la ré-écriture des briques propriétaires (fonctions managées, files, bases spécifiques) ;
- la montée en compétence de l'équipe ;
- l'outillage d'exploitation qu'il faut parfois reconstruire.
C'est précisément pour cette raison que nous décrivons toujours l'infrastructure sous forme de code dès le premier jour. Une infrastructure versionnée et reproductible est une infrastructure que l'on peut déplacer.
Ce que nous en retenons
La souveraineté n'est pas un dogme, c'est un arbitrage. Certaines charges ont un intérêt évident à rester où elles sont ; d'autres n'auraient jamais dû y aller. Le travail utile consiste à savoir lesquelles — et cela commence toujours par un inventaire honnête.