Du débat géopolitique à la question opérationnelle
Pendant longtemps, la souveraineté numérique a été posée en termes de blocs. Europe contre États-Unis, cloud national contre hyperscalers. Le débat se déplace. Pour un DSI ou un RSSI, la vraie question est devenue plus terre à terre : l'organisation est-elle libre de changer de fournisseur si elle le décide ?
Cette liberté de choix n'a rien d'abstrait. Elle se mesure.
Trois capacités concrètes
La première, c'est la réversibilité. Pouvoir récupérer ses données, ses configurations et ses traitements dans un format exploitable, et dans un délai compatible avec l'activité.
La deuxième, l'interopérabilité. Des architectures qui ne reposent pas sur des API propriétaires impossibles à remplacer sans tout réécrire.
La troisième, la maîtrise des clés cryptographiques. Tant que le fournisseur détient les clés, il détient de fait le contrôle des données. Peu importe où elles sont hébergées.
L'IA accentue les dépendances
Les briques d'IA propriétaires s'intègrent profondément dans les processus métiers. Formats spécifiques, orchestrations, connecteurs maison. Plus l'intégration est profonde, plus la sortie coûte cher.
Et la réglementation pousse dans le même sens. L'AI Act impose une conformité croissante, qui suppose de garder la main sur ce que font réellement ces systèmes.
Le retour de l'hybride
Ce contexte explique un mouvement que beaucoup n'attendaient plus : le retour des approches hybrides. Réintroduire de l'on-premise ou du self-hosted pour certaines données sensibles, ou pour la gestion des clés, ce n'est plus un réflexe conservateur. C'est une façon de garder une option de sortie.
Diversifier les fournisseurs relève de la même logique. Ne pas concentrer tous les risques sur un seul acteur.
La réversibilité comme sujet de continuité
Un fournisseur dont on ne peut pas sortir devient un risque de concentration, au sens strict de la continuité d'activité. La clause de réversibilité existe dans la plupart des contrats cloud. Elle a rarement été testée.
Le jour où la DSI veut partir, elle découvre que les exports ne couvrent pas les configurations, que les formats sont propriétaires, que le délai contractuel est irréaliste. D'où l'intérêt de traiter la réversibilité comme un PRA : un test réel sur une application non critique, un chiffrage du coût et du délai de sortie complète, et une mise à jour régulière de cette estimation.
