● Silicon.fr Télécom 📅 05/05/2026 à 16:01

Cybersécurité 👤 Clément Bohic

🏷️ Tags : cert réseau rte stoc

D’un côté, les services dits « souverains » de par les garanties juridiques qu’ils apportent. De l’autre, ceux qualifiés de « résilients » au titre des garanties techniques. Cette distinction structure un référentiel made in CISPE*. Difficile de ne pas y voir une réaction au Cloud Sovereignty Framework, même si l’association représentative des CSP européens ne le présente pas comme telle. Elle a en effet vivement critiqué ce cadre de référence dont l’UE s’est dotée à l’automne 2025 pour évaluer la « souveraineté » des offres cloud dans le cadre de la commande publique. Le référentiel Gaia-X niveau 3, mais avec deux options Le Cloud Sovereignty Framework établit 8 « objectifs » (souveraineté stratégique, opérationnelle, technologique, etc.) déclinés en critères. Pour chacun, on peut déterminer un niveau d’assurance, sur 5 échelons. Bruxelles propose aussi de calculer un « score de souveraineté », éventuellement avec une pondération par objectif. CISPE a dénoncé ce dernier élément. Un système créant une « moyenne de moyennes » ne favorise pas la transparence, estime l’association, qui considère plus globalement qu’on ne « peut pas être souverain à 75 % ». Elle a par ailleurs déploré la présence d’objectifs « inatteignables » (contrôle européen complet sur tous les composants matériel, par exemple) et d’idées « vagues » (en particulier quant aux garanties sur le changement de contrôle). Lire aussi : Copie privée : les cloud providers européens s'insurgent L’initiative s’inspire nettement du niveau 3 du référentiel Gaia-X. Elle s’en différencie toutefois par la double approche « souverain »/« résilient ». Tout en ouvrant la porte à une certification au-delà de l’Europe : un service hébergé au Japon par un fournisseur japonais pourrait être à la fois « souverain » sur place et « résilient » en Europe, explique CISPE. Est pour cela introduite la notion de « zone géographique de souveraineté ». Souveraineté légale et juridictionnelle Une offre peut prétendre au label « résilient » dans une zone géographique donnée dès lors que son fournisseur y est légalement établi. Le label « souverain » implique beaucoup plus d’exigences sur ce volet. D’abord sur l’immunité juridictionnelle. Le siège social, l’administration centrale et l’établissement principal du fournisseur doivent être situés dans un pays de la zone. En parallèle, aucune entité située en dehors de la zone ne doit exercer de contrôle direct ou indirect, individuel ou collectif. Quant aux membres de l’équipe dirigeante et du conseil d’administration, ils ne doivent pas, en raison de leur nationalité ou de leur résidence, être sujets à des obligations extraterritoriales en conflit avec les principes énoncés dans le référentiel. Autre spécificité du label « souverain » : aucune entité localisée hors de la zone, ni aucune personne physique citoyenne ou résidente d’un pays hors zone, ne doit avoir un droit de veto sur le fournisseur. Et pas plus le droit de nommer la majorité des membres des organes d’administration, de gestion ou de supervision. Une option de mise en miroir des workloads critiques Les fournisseurs de services « souverains » doivent aussi s'abstenir de transférer des données clients et des données utilisateurs vers des pays ou régions hors de la zone. Ni, plus globalement, vers tout sous-traitant ou destinataires que le client n'a pas expressément autorisé. Si la législation applicable l'impose, le fournisseur doit limiter la divulgation au strict minimum et informer le client sans délai - sauf la loi l'interdit. La fourniture d'un service « souverain » suppose aussi de notifier le client en cas de prise de contrôle par un tiers qui ne respecte pas les exigences du référentiel. Et de soumettre le contrat de service exclusivement à la loi et à la juridiction d'un pays de la zone. Toutes ces exigences s'appliquent aussi aux sous-traitants. Sauf s'ils n'ont pas techniquement la capacité de traiter les données critiques de manière autonome. Lorsqu'il leur est possible d'affecter la disponibilité de services (cas des prestataires de colocation, notamment), le fournisseur doit mettre en miroir les workloads et données critiques sur une infrastructure « sous contrôle souverain » dans la zone, ou bien déployer sur une infra « fédérée, distribuée, multifournisseur ». Lire aussi : Trois ans après, que devient le catalogue Gaia-X du CISPE ? Souveraineté opérationnelle Peut être souverain un service dont tous les actifs critiques, y compris ceux qu gèrent des sous-traitants, se trouvent dans la zone géographique concernée. Le label « résilient » tolère que des actifs se trouvent en dehors de la zone. Mais à condition d'avoir obtenu le consentement écrit préalable du client. Et de disposer, dans la zone, d'au moins un actif redondant équivalent sur les plans fonctionnel, technique, de sécurité et de niveau de service. Le référentiel opère une distinction similaire pour ce qui est du support. Sur un service « souverain », il est techniquement impossible d'accéder aux données et à l'exploitation des actifs critiques depuis l'extérieur de la zone. Sur un service « résilient », les éventuels accès externes sont documentés, avec maintien à jour de la liste des opérations concernées. Le fournisseur obtient l'accord du client et implémente un contrôle des accès. Qu'il soit « souverain » ou « résilient », un service doit être conforme au Data Act (ou à une législation locale similaire). Sinon, soit être portable (notamment par l'usage de solutions open source ou largement utilisées au sein de la zone concernée), soit reposer sur une infrastructure fédérée ou distribuée. Les services « résilients » doivent, en complément, permettre au client de faire ses sauvegardes de manière autonome, avec des outils tiers et dans des formats qu'il peut restaurer hors de l'environnement du fournisseur. Souveraineté technologique En matière de gestion du matériel, le label « souverain » impose des mesues pour sécuriser les composants critiques (isolation, validation des mises à jour de fournisseurs non souverains...). Le label « résilient » les reprend et y ajoute deux éléments. D'une part, définir un stock approprié pour les équipements et composants-clés. De l'autre, notifier le client de toute perturbation de la chaîne d'approvisionnement entraînant l'indisponibilité de ces équipements et composants. Sur la question du stock, on aura noté que le référentiel impose, pour les équipements et composants conçus et fabriqués en dehors de la zone, d'assurer la disponibilité d'une alternative venant de l'intérieur de la zone... Sur la gestion du logiciel, pas de différence entre « souverain » et « résilient ». Le fournisseur doit notamment s'efforcer d'obtenir des engagements - ou, au minimum, des informations - de la part de l'éditeur de tout actif critique quant aux conditions de sa maintenance. À défaut, il doit pouvoir assurer indépendamment la continuité du service. Y compris en substituant un autre logiciel afin d'assurer un minimum de viabilité fonctionnelle. Dans le même esprit, pour tout logiciel tiers propriétaire utilisé ou mis à disposition, le fournisseur doit identifier au moins un logiciel alternatif, open source si possible. À défaut (par exemple pour l'edge et des services cyber comme WAF, anti-DDoS et CDN), il doit identifier une solution permettant un minimum de viabilité foncitonnelle. Tout en validant, pour les SaaS, la conformité avec le Data Act ou toute législation similaire. Pas non plus de différence entre « souverain » et « résilient » sur le sujet de l'autonomie opérationnelle. Le fournisseur doit pouvoir maintenir l'entièreté de son service par lui-même ou en s'appuyant sur au moins deux sociétés tierces. Et s'assurer que les actifs critiques issus d'entités non souveraines n'incluent pas de kill switches... Souveraineté des données Qu'un fournisseur postule au label « souverain » ou « résilient », il ne doit traiter les données personnelles des clients qu'en accord avec leurs instructions et avec la législation applicable dans la zone. Il lui faut aussi tenir à leur disposition une liste des pays où sont stockées et traitées ces données, ainsi que les données techniques, les données utilisateur et les données administratives. Excepté pour ces dernières, il n'y a pas de transfert hors zone sans consentement du client. Lire aussi : Au point mort avec Broadcom, le CISPE maintient la pression Mêmes exigences également entre « souverain » et « résilient » concernant le chiffrement. Excepté les données client, il faut chiffrer en transit et au repos, en conservant les clés dans la zone... et en évitant les accès non autorisés, y compris par les tiers impliqués dans l'infrastructure de failover réseau. Les services « résilients » ont un régime spécifique sur le transfert des données vers des pays tiers. C'est possible, à condition que la législation applicable l'autorise et reconnaisse que le pays en question assure un niveau équivalent de protection des données. Dans tous les cas, le fournisseur doit donner au client l'option de stocker et traiter ses données critiques dans la zone géographique concernée. * Le comité qui pilote le développement du framework se compose d’Anexia (Autriche), Aruba (Italie), Clever Cloud (France), Deda Cloud (Italie), Infomaniak (Suisse), Jotelulu (Espagne), Leaseweb (Pays-Bas), NumSpot (France), OUTSCALE (France), OpenNebula (Espagne), Opiquad (Italie), OUTSCALE (France), oXya (France), ReeVo (Italie) et WaveCom (Estonie). BYCYB, filiale du LNE (Laboratoire national de métrologie et d'essais), est dans la boucle pour les audits. CISPE prévoit d'instaurer plusieurs niveaux de résilience. Illustration générée par IA

🔗 Lire l'article original 👁️ 0 lecture