La plupart des discussions sur la souveraineté se concentrent sur ce que les fournisseurs disent de leurs produits. Les discussions les plus utiles portent en revanche sur ce que les fournisseurs ont réellement mis en place. L'architecture est plus difficile à simuler que le marketing. Les choix de conception opérés par un fournisseur des années avant que la souveraineté ne devienne une exigence d'achat déterminent souvent si la souveraineté peut être garantie dans la pratique ou si elle reste une simple mention dans un contrat.

Certains choix de conception préservent le contrôle du client. D’autres le lui font perdre. Une fois qu’un système est construit autour d’un ensemble particulier de choix, la position en matière de souveraineté qui en résulte ne peut être modifiée a posteriori par des avenants contractuels ou des manœuvres juridictionnelles. C’est l’architecture qui fait la différence.

La question relative à la clé cryptographique est le test le plus fiable

Le critère architectural le plus évident en matière de souveraineté est de savoir qui détient les clés cryptographiques. Il ne s'agit pas de savoir qui s'est engagé contractuellement à ne pas les utiliser ou qui a accepté de ne pas les divulguer dans des circonstances normales, mais bien de savoir qui les possède.

Ces deux architectures donnent lieu à deux approches de la souveraineté fondamentalement différentes.

Clés détenues par le fournisseur. Le prestataire, en tant qu’opérateur du service, détient les clés qui protègent les données des clients. Il s’engage contractuellement à ne pas utiliser ces clés à d’autres fins que la prestation du service. La protection du client repose sur le contrat, les politiques du prestataire et l’intégrité opérationnelle de ce dernier.

Clés détenues par le client. Le client conserve les clés au sein d’une infrastructure de gestion des clés qu’il contrôle. Le fournisseur, en tant qu’opérateur du service, n’a techniquement aucun moyen d’accéder aux données protégées, même s’il y est contraint par une autorité judiciaire, même en cas de compromission interne, et même en cas de résiliation du contrat.

Dans le premier modèle, la confidentialité des données du client dépend de la coopération continue du fournisseur, de son intégrité et de sa résistance à toute contrainte. Dans le second, elle dépend de la gestion des clés par le client lui-même.

C’est dans des situations conflictuelles que cela revêt toute son importance : contrainte judiciaire, compromission d’un fournisseur, litige contractuel ou perturbation géopolitique. En conditions normales d’exploitation, les deux architectures semblent identiques. En situation de crise, elles divergent fortement. Un fournisseur détenant les clés peut être contraint de divulguer des données par une décision de justice rendue dans sa juridiction, par un régime de contrainte gouvernementale ou à la suite d’une violation suffisamment sophistiquée de son infrastructure de gestion des clés. Un fournisseur qui n’a jamais détenu les clés ne peut divulguer ce à quoi il n’a pas accès.

Pour les clients soucieux de la souveraineté, ce simple choix architectural contribue davantage à la souveraineté que la plupart des clauses contractuelles réunies. Et c'est un choix qui doit être fait dès les premières étapes de la conception du système. Intégrer des clés détenues par le client dans une architecture où les clés sont détenues par le fournisseur n'est pas une refonte, mais une réécriture.

La topologie de déploiement détermine la souveraineté opérationnelle

Le deuxième critère architectural consiste à vérifier si le système peut fonctionner indépendamment de l'infrastructure cloud du fournisseur.

Une architecture exclusivement SaaS, dans laquelle le client s'abonne à un service cloud exploité par le fournisseur, offre un confort d'utilisation au client tout en conférant au fournisseur une autorité opérationnelle permanente. Le client ne peut pas exploiter le système. Seul le fournisseur en a la capacité. La continuité des activités du client dépend de celle du fournisseur. La conformité du client dépend de la politique de conformité du fournisseur. L'emplacement géographique des données du client dépend des options de configuration proposées par le fournisseur au sein de son cloud. Le client est, de par la structure du système, un locataire et la souveraineté opérationnelle a été transférée au fournisseur.

Une topologie de déploiement comprenant des configurations sur site gérées par le client, dans lesquelles ce dernier peut exploiter le système au sein de sa propre infrastructure, avec sa propre équipe d’exploitation, sur son propre territoire et sur son propre matériel, se traduit par une approche de la souveraineté structurellement différente. Le client peut isoler entièrement le système de l’Internet public. Le client peut faire fonctionner le système même en cas de coupures de connexion. Le client peut soumettre le système à son propre audit, à son propre contrôle des changements et à sa propre gouvernance. Le fournisseur fournit le logiciel. Le client l'exploite.

Les déploiements qui préservent le plus la souveraineté vont encore plus loin. Les configurations « air-gapped », dans lesquelles le système fonctionne dans l’environnement du client sans aucune connexion à l’infrastructure du fournisseur à des fins opérationnelles, représentent le contrôle opérationnel maximal qu’un fournisseur peut offrir. Le client est indépendant sur le plan opérationnel. Les mises à jour transitent par des canaux contrôlés que le client gère lui-même. La télémétrie, le cas échéant, transite par des voies contrôlées par le client. La pérennité du fournisseur n’est pas une condition préalable à la poursuite des opérations du client.

Cette gamme de topologies de déploiement, allant du SaaS pur à une extrémité à une solution entièrement isolée physiquement à l'autre, constitue l'axe de la souveraineté opérationnelle. La plupart des discussions concrètes sur la souveraineté portent sur la position qu'un client donné doit occuper sur cet axe et sur la capacité de l'architecture du fournisseur à prendre en charge cette position.

Un fournisseur dont l’architecture ne prend en charge que le SaaS, sans aucune option de déploiement sur site, limite fondamentalement la souveraineté opérationnelle du client, quelle que soit la rigueur de son infrastructure cloud. Un fournisseur dont l’architecture couvre toute la gamme — le SaaS pour les clients en quête de simplicité, le déploiement sur site pour ceux qui ont besoin d’un contrôle opérationnel, et les solutions « air-gapped » pour ceux évoluant dans des environnements classifiés ou critiques — offre au client le choix de son niveau de souveraineté. Cette différence architecturale résulte de décennies d’investissement, et non d’un simple changement de configuration.

La question de l'entité opérationnelle oppose le marketing au fond

Au-delà de l'architecture technique, il existe un choix d'architecture organisationnelle qui s'avère souvent plus déterminant : qui est l'entité chargée de l'exploitation effective pour les clients dont la souveraineté est en jeu, et quelle est l'importance réelle de cette entité sur le plan opérationnel ?

Avant que cette question ne se pose, il faut répondre à une autre : la juridiction de la société mère du fournisseur respecte-t-elle le seuil juridique minimal du client ? L’évaluation de la souveraineté est menée par une autorité, un service des marchés publics, un organisme de régulation ou un conseil d’administration, dont la juridiction définit ce qui constitue un risque juridique étranger. Le critère de l’entité opérationnelle est particulièrement utile pour les fournisseurs dont la juridiction de la société mère est acceptable au regard du cadre du client. Lorsque la juridiction de la société mère engendre un risque juridique considéré comme étranger par le client (les fournisseurs dont le siège social est situé aux États-Unis et qui vendent dans le cadre de marchés publics relevant de la souveraineté de l’UE constituent l’exemple le plus souvent cité, mais la même logique s’applique de manière symétrique dans l’autre sens pour tout marché public transfrontalier), la question de l’entité opérationnelle intervient en aval d’un seuil qui n’a déjà pas été franchi. La substance opérationnelle ne modifie pas le risque juridique lié à la juridiction étrangère que la société mère conserve en vertu de sa constitution en société.

C'est souvent l'entité opérationnelle qui révèle si la souveraineté existe dans la pratique ou seulement sur le papier. Un schéma courant consiste pour un fournisseur dont le siège social est situé dans une juridiction donnée à créer une filiale dans une juridiction où la souveraineté revêt une importance particulière (généralement l'UE, mais de plus en plus d'autres régions). La filiale est présentée comme le point d'ancrage souverain local. Les clients concluent leurs contrats avec la filiale. C'est la filiale qui détient les certifications locales. C'est le nom de la filiale qui figure dans les supports marketing.

La question qui permet de distinguer le fond de la forme est la suivante : quelle est l'activité réelle de cette filiale ?

Les filiales « fantômes » existent principalement à des fins contractuelles et de mise en conformité. Elles emploient un effectif réduit, occupant principalement des fonctions commerciales et de gestion de compte. Les activités d’ingénierie sont menées au sein de la société mère. La mise en place de l’infrastructure s’effectue dans la juridiction de la société mère. Les mises à jour logicielles proviennent de canaux gérés par la société mère. La filiale signe le contrat. La société mère assure l’exploitation du service. Si la société mère venait à disparaître, la filiale ne pourrait pas poursuivre ses activités. La filiale est une entité juridique de façade, et non une entité opérationnelle.

Les filiales dotées de ressources importantes ont un poids opérationnel significatif. Elles emploient des ingénieurs qui contribuent au code source fourni aux clients locaux. Elles gèrent l’infrastructure de compilation sur le territoire local, sous contrôle local. Elles contrôlent les canaux de déploiement et de mise à jour pour les versions locales. Elles disposent de la capacité technique et contractuelle nécessaire pour continuer à assurer le service aux clients locaux si la société mère venait à être indisponible. La filiale ne se contente pas de sous-traiter ; elle assure elle-même l’exploitation.

Cette distinction est rarement perceptible dans le domaine du marketing. Les deux types de filiales se présentent en effet de la même manière. C'est au niveau des questions opérationnelles que la distinction apparaît : où travaillent les ingénieurs, où se déroule le processus de développement, quelle est la source de référence pour les mises à jour fournies aux clients gouvernementaux, et que se passerait-il si la société mère venait à disparaître ?

Pour les clients qui prennent la souveraineté au sérieux, ce sont ces questions qui permettent de distinguer un fournisseur disposant d’une véritable entité opérationnelle souveraine d’un fournisseur dont la structure d’entreprise n’est qu’une façade. Et cela ne se construit pas du jour au lendemain. La mise en place d’une filiale dotée d’une réelle substance nécessite des années d’investissement dans les capacités d’ingénierie, la mise en place d’infrastructures, les démarches de certification et l’autonomie opérationnelle. Un fournisseur qui n’aura pas réalisé cet investissement au moment où la souveraineté deviendra un critère d’achat ne pourra pas s’en doter dans le cadre d’un contrat.

L'étendue de la certification comme preuve de l'intégrité opérationnelle

Dans le domaine du marketing, on parle souvent des certifications comme d'une liste de logos qui sont synonymes de légitimité. La question importante n'est pas de savoir combien de certifications possède un fournisseur, mais ce que ces certifications attestent réellement.

Les certifications de validation des opérations constituent la catégorie la plus intéressante pour l'évaluation de la souveraineté. Elles comprennent les éléments suivants.

Certifications attestant de l'intégrité opérationnelle dans le cadre d'un déploiement classifié. Lorsqu’une autorité de sécurité nationale accrédite un système pour une utilisation classifiée, cette accréditation s’étend au fond opérationnel, et pas seulement à la conception architecturale. Elle couvre le système tel qu’il est déployé, avec ses procédures d’exploitation, son modèle de mise à jour, ses contrôles d’accès et sa chaîne d’approvisionnement opérationnelle. L’accréditation « NATO Restricted », les directives « NSA Commercial Solutions for Classified », les certifications fédérales du BSI et les accréditations alliées équivalentes revêtent cette importance.

Certifications attestant de la continuité des opérations. Les cadres de surveillance continue tels que FedRAMP Classe D (Haut) exigent des preuves continues de la sécurité opérationnelle, et non une évaluation ponctuelle. La norme SOC 2 Type 2 atteste que les contrôles fonctionnent efficacement sur une période d’évaluation, et pas seulement qu’ils existent sur le papier. La norme ISO 22301 certifie spécifiquement les opérations de continuité d’activité.

Certifications attestant de la sécurité cryptographique et de la sécurité de la plateforme. L'évaluation selon les Critères communs à des niveaux d'assurance d'évaluation supérieurs valide les déclarations relatives à la sécurité cryptographique et à la sécurité de la plateforme d'un produit grâce à des tests effectués par des laboratoires tiers indépendants.

Le nombre de certifications détenues par un prestataire est moins important que la nature de ces certifications et ce que chacune d'entre elles atteste. Un prestataire disposant d'une longue liste de certifications portant uniquement sur l'architecture est fondamentalement différent d'un prestataire dont la liste, bien que plus courte, comprend des certifications attestant de ses capacités opérationnelles dans plusieurs juridictions.

Le modèle le plus pertinent en matière de souveraineté est la certification opérationnelle multijuridictionnelle : des certifications délivrées par plusieurs gouvernements alliés, validant des opérations dans le cadre de déploiements classifiés ou sensibles, détenues simultanément sur une plateforme intégrée. Ce modèle est rare et difficile à mettre en œuvre. Il nécessite un engagement opérationnel continu auprès de multiples autorités de sécurité nationale, chacune disposant de ses propres processus d’évaluation, modèles de menaces et normes opérationnelles. Un fournisseur qui détient une accréditation opérationnelle au niveau de l’OTAN, une certification américaine de niveau «classifié» et des certifications fédérales délivrées par des gouvernements alliés pour une même plateforme de produits a démontré son intégrité opérationnelle d’une manière qu’aucune certification isolée ne saurait égaler.

Un tel portefeuille de certifications ne se constitue que rarement par hasard. Il est le fruit d'années de collaboration avec des clients du secteur de la sécurité nationale, de cycles d'évaluation répétés et d'une architecture suffisamment stable pour satisfaire simultanément plusieurs autorités.

La transparence de la chaîne d'approvisionnement en tant que propriété structurelle

Dans les cadres modernes, l’objectif de souveraineté qui revêt le plus d’importance est celui de la chaîne d’approvisionnement. En effet, celle-ci constitue le critère le plus durable de la souveraineté. Le statut juridique peut évoluer en fonction d’un traité. L’empreinte opérationnelle peut être délocalisée. Les arguments marketing peuvent être mis à jour. En revanche, il est plus difficile de modifier le lieu où les logiciels sont conçus, développés et distribués.

Le modèle architectural qui garantit la souveraineté de la chaîne d'approvisionnement repose sur une transparence structurée. Plus précisément :

Mettre en place l'infrastructure dans la juridiction pertinente pour le client. Pour les déploiements chez un client soumis à des contraintes de souveraineté, le pipeline de compilation qui produit le logiciel s’exécutant dans l’environnement de ce client doit fonctionner sur une infrastructure adaptée à la juridiction concernée. Il s’agit d’une question distincte de celle de la juridiction du siège social, qui constitue un critère juridique de base abordé séparément dans toute évaluation rigoureuse. La question du pipeline de compilation porte sur le lieu où les artefacts de compilation sont produits et signés, sur les personnes ayant accès à ce pipeline, ainsi que sur la protection juridictionnelle qui s’applique aux artefacts eux-mêmes. Ces deux questions sont indispensables. Un fournisseur qui répond à l’une sans répondre à l’autre n’apporte qu’une réponse partielle.

Souveraineté matérielle pour les ancrages cryptographiques. Les HSM (modules de sécurité matériels) qui constituent le fondement de l’infrastructure cryptographique des déploiements sensibles en matière de souveraineté doivent provenir de fournisseurs dont la juridiction respecte les exigences de souveraineté du client. Les HSM relevant de la juridiction de l’UE (Thales en France, Utimaco en Allemagne, etc.) sont structurellement différents des HSM ne relevant pas de la juridiction de l’UE, même lorsque leurs spécifications techniques sont équivalentes.

Dépôt du code source et accès à des fins d'audit. Les clients impliqués dans des déploiements classifiés exigent souvent de pouvoir inspecter ou déposer le code source à titre de garantie de confiance. Un fournisseur dont l’architecture prend en charge le dépôt du code source dans le cadre de programmes gouvernementaux destinés à des clients certifiés offre au client la possibilité d’une vérification indépendante. Un fournisseur dont l’architecture ne prend pas en charge cette fonctionnalité, généralement parce que la base de code est trop étroitement intégrée à une infrastructure cloud propriétaire pour pouvoir être déposée de manière significative, limite les options offertes au client.

Conformité OpenChain ou équivalente en matière de chaîne d'approvisionnement. La conformité OpenChain (ISO/IEC 5230) est un cadre structuré visant à garantir la transparence de la chaîne d’approvisionnement logicielle. Les fournisseurs conformes à OpenChain ont démontré, par le biais d’un audit externe, que leurs pratiques en matière de chaîne d’approvisionnement répondent à une norme définie. Il s’agit là d’une preuve structurelle de la rigueur de leur chaîne d’approvisionnement.

Ces modèles relèvent de l'architecture et non du contrat. Soit un fournisseur a conçu sa chaîne d'approvisionnement de manière à ce qu'elle puisse être contrôlée, soit il ne l'a pas fait. Si c'est le cas, les clients soucieux de leur souveraineté peuvent s'engager avec lui. Dans le cas contraire, aucun contrat ne peut garantir une transparence de la chaîne d'approvisionnement qui n'existe pas au niveau de l'architecture.

La question de la sortie des fournisseurs que peu de gens abordent

Les débats sur la souveraineté portent généralement sur la phase initiale d'une relation avec un fournisseur : comment celui-ci est sélectionné, comment sa position en matière de souveraineté est évaluée et quelles mesures de protection sont mises en place au moment de la signature. La phase de sortie est rarement abordée avec la même rigueur, mais elle revêt structurellement la même importance pour la souveraineté à long terme du client.

Les questions d'architecture qui déterminent le coût de sortie sont les suivantes.

Les protocoles sont-ils ouverts ou propriétaires ? Un fournisseur utilisant des protocoles ouverts et basés sur des normes a structurellement permis au client de migrer vers un autre fournisseur prenant en charge les mêmes normes. Un fournisseur utilisant des protocoles propriétaires a structurellement lié le client à lui, dans la mesure où ces protocoles propriétaires sont intégrés aux opérations du client.

Les formats de données sont-ils portables ? Les données clients stockées dans des formats propriétaires, sans procédure d'exportation documentée ni équivalent standard, sont en pratique inaccessibles . Les données clients stockées dans des formats ouverts, ou pour lesquelles une procédure d'exportation est documentée, sont portables.

Les intégrations sont-elles remplaçables ? Un fournisseur dont la valeur pour le client dépend d'intégrations étroitement liées à ses autres produits a structurellement créé un coût de changement qui augmente avec le temps, à mesure que de nouvelles intégrations sont ajoutées. Ce n'est pas le cas d'un fournisseur dont le produit est interopérable avec des solutions tierces.

L'architecture est-elle extractible ? Dans les déploiements où la souveraineté est une priorité absolue, les clients peuvent avoir besoin de pouvoir extraire l’intégralité du système, des logiciels, des données, des configurations et des procédures opérationnelles afin de continuer à l’exploiter de manière indépendante. Les fournisseurs dont l’architecture prend en charge cette fonctionnalité (grâce à des accords de licence, à la mise à disposition du code source ou à des architectures ouvertes) offrent au client une véritable souveraineté de sortie. Les fournisseurs dont l’architecture ne permet pas cela conservent structurellement un contrôle sur la poursuite de l’exploitation par le client.

Un fournisseur qui privilégie la souveraineté du client conçoit la possibilité de se désengager comme un scénario à part entière. Ce n'est pas le cas d'un fournisseur dont le modèle économique repose sur la dépendance vis-à-vis de ses clients. La souveraineté à long terme du client dépend du type de fournisseur avec lequel il a établi une relation.

Le modèle structurel, en résumé

Les clients qui achètent depuis le plus longtemps des systèmes de niveau « souverain » — agences de sécurité nationale, ministères de la Défense et opérateurs de communications classifiées — ont, au fil du temps, défini un modèle structurel qui détermine à quoi ressemble la véritable souveraineté au sein de l’architecture. Ce modèle part d’un seuil juridictionnel et se développe à partir de là. La question du « seuil juridique » consiste à déterminer si la juridiction d’origine du fournisseur expose ce dernier à des contraintes juridiques étrangères à la juridiction du client. Si tel est le cas, les atouts architecturaux mentionnés ci-dessous se situent en aval d’un seuil qui n’a pas été respecté selon l’évaluation spécifique de ce client. Au sein de ce seuil, le modèle comprend :

• Clés cryptographiques détenues par les clients : une question d'architecture, et non de promesse

• Topologie de déploiement multimodale comprenant des options sur site et en mode « air-gapped »

• Entités opérationnelles implantées dans des juridictions pertinentes pour la clientèle et présentant une réelle substance technique et opérationnelle

• Certifications opérationnelles multi-juridictionnelles validant le système en cours de déploiement

• Des chaînes d'approvisionnement vérifiables, avec une transparence du pipeline de compilation, la souveraineté matérielle pour les ancrages cryptographiques, des dispositions relatives au code source et des cadres de conformité des chaînes d'approvisionnement

• Des protocoles ouverts et des formats de données portables qui préservent la liberté de changement de fournisseur des clients

Les fournisseurs qui respectent le seuil légal requis par le client et ont conçu leurs produits selon ce modèle peuvent faire de la souveraineté une réalité opérationnelle. Les fournisseurs qui ne respectent pas ces exigences légales minimales ne peuvent pas garantir la souveraineté à ce client, quelle que soit la solidité de leur architecture sur les autres plans, car ces exigences se situent au-dessus de la couche architecturale. Les fournisseurs qui respectent ces exigences légales minimales mais ont conçu leurs produits autour de modèles alternatifs (clés détenues par le fournisseur, déploiement exclusivement en mode SaaS, filiales locales sans substance réelle, certifications limitées à une seule juridiction, chaînes d’approvisionnement opaques et verrouillage propriétaire) ne peuvent pas non plus garantir la souveraineté en tant que réalité opérationnelle, quel que soit l’intensité de leur campagne marketing axée sur la souveraineté.

Les choix architecturaux ont été faits il y a des années. Le débat sur la souveraineté qui fait désormais son apparition dans le domaine des marchés publics met en effet en lumière à la fois les positions juridictionnelles des fournisseurs et les décisions architecturales qu’ils ont prises bien avant que la notion de souveraineté n’entre dans le vocabulaire des marchés publics. Les clients qui prennent la souveraineté au sérieux vont de plus en plus au-delà du discours marketing et posent les questions structurelles les unes après les autres : quelle est la juridiction mère par rapport à la nôtre, qui détient les clés, où le système peut-il fonctionner, qui exploite réellement l’entité locale, que valide chaque certification, où se trouve le pipeline de développement, et pouvons-nous nous désengager ?

Les clients qui prennent la souveraineté au sérieux posent de plus en plus souvent une série de questions différentes : qui détient les clés, où le système peut-il fonctionner, qui l’exploite réellement, que valident les certifications, où se trouve le pipeline de développement, et pouvons-nous nous en désengager ? Les réponses révèlent bien plus que n’importe quelle déclaration de souveraineté figurant sur un site web.

À lire également :
La souveraineté se mesure : qu’est-ce que le SEAL et pourquoi est-ce important au-delà du cloud ?
La souveraineté n'est plus une option : comment les gouvernements et les entreprises doivent-ils envisager la question du contrôle ?