La souveraineté numérique relève d'un choix d'architecture

Une entreprise suisse peut stocker ses données en Suisse tout en restant fortement dépendante d'infrastructures, de logiciels, de services de chiffrement et d'outils de gestion contrôlés depuis l'étranger.

Cela ne rend pas pour autant automatiquement cette architecture inadaptée. Les fournisseurs de technologies internationaux offrent des capacités que de nombreuses organisations ne pourraient ni reproduire de manière rentable, ni exploiter à une échelle comparable. Le problème survient lorsque les entreprises considèrent la localisation des données comme le seul critère de la souveraineté numérique.

Les piles technologiques modernes comportent plusieurs niveaux de dépendances. L'infrastructure cloud en est un. Les systèmes d'identité, les clés de chiffrement, les consoles de gestion, les mises à jour logicielles, les modèles d'IA, les API et les connaissances opérationnelles spécialisées peuvent eux aussi créer leurs propres dépendances.

Les organisations suisses ont donc besoin d'une définition plus concrète de la souveraineté : quel degré de contrôle l'entreprise conserve-t-elle sur les systèmes dont elle dépend, et que se passe-t-il si l'une de ces dépendances devient indisponible, peu intéressante sur le plan commercial ou difficile à utiliser d'un point de vue juridique ?

La localisation des données ne répond qu’à une seule question

La « résidence des données » indique à une entreprise où ses informations sont physiquement stockées ou traitées. Pour les secteurs soumis à une réglementation, les organismes publics et les entreprises traitant des informations sensibles, cela peut constituer une exigence essentielle.

Cela ne décrit pas l'ensemble de la pile technologique.

Une charge de travail peut être exécutée dans un centre de données suisse tandis que son plan de contrôle repose sur une technologie exploitée depuis une autre juridiction. Une entreprise peut chiffrer des informations localement tout en faisant appel à un prestataire externe pour certaines étapes du processus de gestion des clés. Une application peut stocker sa base de données principale en Suisse tout en transmettant certaines informations à des API étrangères chaque fois que des collaborateurs utilisent une fonction d'IA intégrée.

L'architecture établit ces relations, un service à la fois.

C'est pourquoi les questionnaires d'approvisionnement axés principalement sur l'emplacement des serveurs peuvent donner à la direction une vision incomplète de la situation. Une meilleure évaluation consiste à prendre en compte les données, le contrôle opérationnel et les dépendances techniques à l'échelle de l'ensemble du système.

Qui peut gérer l'environnement ? Qui contrôle les clés de chiffrement ? Quel fournisseur propose les services d'identité ? Où sont transférés les journaux ? Quelles API externes reçoivent les informations ? Les administrateurs peuvent-ils continuer à exploiter le système si le service central d'un fournisseur devient indisponible ? Quel serait le degré de difficulté d'une migration ?

Ces réponses en disent bien plus long sur la souveraineté concrète que le code postal d'un centre de données.

L'IA ajoute une nouvelle couche de dépendance

L'IA générative complique l'analyse, car les entreprises déploient rarement un modèle de manière isolée.

Un service d'IA d'entreprise peut inclure un modèle de base, une infrastructure cloud, un logiciel de recherche, des bases de données vectorielles, des outils d'orchestration, des systèmes de surveillance et des connexions aux applications internes. Les équipes peuvent également faire appel à plusieurs fournisseurs de modèles, car l'un d'entre eux peut être plus performant pour l'analyse de documents tandis qu'un autre est plus adapté au codage, à la traduction ou aux tâches multimodales.

Chaque connexion engendre une dépendance tant technique que commerciale.

Les entreprises suisses n'ont pas besoin d'éviter ces dépendances. Elles doivent savoir lesquelles elles peuvent accepter.

Un service marketing qui mène des expériences dans le domaine de l'information publique présente un profil de risque différent de celui d'une banque qui analyse les données de ses clients ou d'un fabricant qui intègre un agent d'IA à ses systèmes de production. L'architecture doit refléter ces différences plutôt que d'appliquer une norme unique en matière de souveraineté à toutes les charges de travail.

Les entreprises peuvent conserver certaines applications sur une infrastructure de cloud public classique, tout en plaçant les charges de travail plus sensibles dans des environnements soumis à des contrôles juridictionnels, opérationnels ou cryptographiques plus stricts. D'autres peuvent exécuter certains modèles ouverts sur une infrastructure qu'elles contrôlent, tout en continuant à utiliser des modèles commerciaux pour les tâches moins sensibles.

Cette approche hybride offre souvent davantage de souplesse que de chercher à rendre chaque composant tout aussi autonome.

La question du contrôle du chiffrement mérite qu'on s'y intéresse davantage

Le chiffrement est souvent évoqué dans les débats sur la sécurité en tant que mesure de protection technique. Du point de vue de la souveraineté, la question la plus intéressante est de savoir qui contrôle les clés.

Un fournisseur de services cloud peut héberger des données chiffrées tout en laissant au client le contrôle des clés de chiffrement nécessaires à leur déchiffrement. Les différents modèles de mise en œuvre offrent des niveaux de séparation variables entre le fournisseur et le client.

Pour les charges de travail sensibles, les entreprises doivent déterminer si un fournisseur peut accéder à des informations en clair dans le cadre de ses opérations normales, quels sont les privilèges dont disposent les administrateurs et comment les systèmes de gestion des clés se comportent en cas de panne ou de litige juridique.

La même analyse s'applique aux sauvegardes.

Une entreprise dispose d'une autonomie opérationnelle limitée si son environnement principal et son environnement de reprise dépendent du même fournisseur, de la même couche de gestion et du même service d'authentification. La redondance géographique peut offrir une protection contre une défaillance de l'infrastructure locale, tout en laissant intacte une autre catégorie de dépendance.

La planification de la résilience doit donc tenir compte aussi bien de la concentration technologique que de la localisation géographique.

La possibilité de sortie transforme la souveraineté en une notion mesurable

De nombreuses organisations évoquent la question de l'indépendance vis-à-vis des fournisseurs lors du processus d'approvisionnement, mais ne prennent conscience du coût réel de cette dépendance que lorsqu'elles tentent de changer de fournisseur.

Les plateformes cloud incitent les entreprises à recourir à des bases de données gérées, à des produits d'analyse propriétaires, à des fonctions « serverless » et à des services d'IA spécialisés, car ces outils allègent la charge de travail opérationnelle. Les avantages peuvent être considérables. Chaque composant propriétaire peut toutefois alourdir l'effort de migration.

Une analyse d'architecture pertinente pose une question opérationnelle simple : si l'entreprise devait déplacer cette charge de travail, quels changements faudrait-il apporter ?

Certains systèmes peuvent être transférés assez facilement, car ils utilisent des technologies portables et des interfaces bien documentées. D'autres peuvent nécessiter la réécriture d'applications, la conversion de données, la mise en place de nouveaux contrôles de sécurité et des mois de travail d'ingénierie.

Aucune de ces deux situations ne détermine automatiquement l'architecture la plus appropriée. Une entreprise peut raisonnablement accepter une forte dépendance vis-à-vis d'un seul fournisseur lorsque les avantages économiques et techniques l'emportent sur le risque lié à un éventuel changement de fournisseur.

La direction devrait opérer ce compromis en toute connaissance de cause.

Une fois que les équipes ont évalué la difficulté de la migration, la portabilité des données, les options de remplacement et le délai de transition, la souveraineté cesse d'être un concept politique abstrait. Elle s'inscrit alors dans le cadre de la continuité des activités et de la gestion des risques technologiques.

Les entreprises suisses peuvent donner la priorité aux systèmes qui nécessitent un contrôle

Une indépendance technologique totale serait coûteuse pour la plupart des organisations et irréaliste pour bon nombre d'entre elles.

Les serveurs dépendent des chaînes d'approvisionnement mondiales en matériel informatique. Les applications d'entreprise utilisent des bibliothèques logicielles internationales. Les produits de cybersécurité s'appuient sur des renseignements sur les menaces provenant de plusieurs juridictions. Les modèles d'IA dépendent de puces spécialisées, d'infrastructures de centres de données et d'écosystèmes logiciels qu'aucune entreprise ne contrôle entièrement à elle seule.

Une stratégie de souveraineté viable commence donc par identifier les domaines dans lesquels la dépendance pourrait entraîner des conséquences inacceptables.

Un hôpital peut accorder la priorité à la maîtrise des informations relatives aux patients et des systèmes cliniques. Une banque peut se concentrer sur les données clients, l’infrastructure des transactions et l’identité. Un fabricant peut quant à lui accorder une plus grande importance aux technologies de production, à la propriété intellectuelle et aux systèmes de chaîne d’approvisionnement. Les institutions publiques peuvent avoir des exigences supplémentaires liées à la continuité des services publics et à leur compétence juridictionnelle.

Les entreprises peuvent alors évaluer leur infrastructure technologique à l'aune de ces priorités.

Cet exercice montre souvent que la souveraineté n'est pas un état technique unique partagé par l'ensemble de l'organisation. Des systèmes différents nécessitent des niveaux de contrôle différents.

Les services d'achats doivent se poser des questions d'ordre architectural

Les équipes chargées des achats technologiques ont toujours comparé les fonctionnalités, les certifications de sécurité, les prix et les niveaux de service. La souveraineté soulève désormais des questions qui recoupent plusieurs domaines.

Les équipes juridiques doivent comprendre les questions de compétence juridictionnelle et les risques contractuels. Les équipes de sécurité examinent les accès privilégiés et le chiffrement. Les architectes d'entreprise évaluent la portabilité et les dépendances techniques. Les équipes chargées des achats évaluent la concentration et les coûts de changement de fournisseur. Les responsables métier décident du niveau de perturbation opérationnelle que l'organisation est en mesure de tolérer.

Aucune de ces fonctions ne peut à elle seule répondre à la question de la souveraineté.

Les entreprises devront également disposer d'un meilleur inventaire de leurs dépendances. L'IA rend cette nécessité particulièrement urgente, car les collaborateurs peuvent rapidement intégrer de nouveaux services aux processus métier. Un simple logiciel peut, à l'insu de tous, introduire un autre fournisseur de modèles ou un service de traitement externe par le biais d'une fonctionnalité intégrée.

La gouvernance architecturale doit disposer d'une visibilité suffisante pour détecter ces changements sans que chaque nouvel outil ne donne lieu à une procédure d'approbation de six mois.

La souveraineté, c'est avant tout une question de marge de manœuvre

La Suisse a bâti une grande partie de sa réputation économique sur la fiabilité, la discrétion et la stabilité institutionnelle. Ces caractéristiques influencent naturellement la manière dont les entreprises suisses envisagent leur infrastructure technologique.

La souveraineté numérique ne doit pas se traduire par un repli technologique.

Une entreprise acquiert une souveraineté effective lorsqu'elle identifie ses dépendances, protège les systèmes pour lesquels un contrôle est réellement nécessaire et se dote d'alternatives réalistes là où la concentration des fournisseurs pourrait entraîner un risque inacceptable.

Cela peut impliquer le recours à une infrastructure suisse pour une charge de travail donnée, à un hyperscaler mondial pour une autre, et à une architecture hybride reliant plusieurs environnements. Le choix de la conception appropriée dépend des informations traitées, de la fonction remplie par le système et des conséquences si un fournisseur ne pouvait plus assurer ce service dans des conditions acceptables. Le nom donné au cloud importe moins que le contrôle intégré dans le architecture. Pour les entreprises suisses, cela fait passer la souveraineté numérique du statut de simple slogan en matière d'achats à celui de véritable discipline de conception.