Le Cloud & AI Development Act — CADA en abrégé — transforme un débat stratégique en exigence auditable : quatre niveaux d'assurance de l'Union cumulatifs, de la localisation des données jusqu'au contrôle effectif de chaque composant logiciel. Nous amenons votre parc cloud, vos preuves et vos contrats à ces niveaux.
Chiffres issus de l'exposé des motifs du Cloud & AI Development Act, proposition COM(2026) 502 final du 3 juin 2026. Le texte suit la procédure législative — critères et délais peuvent encore évoluer.
Pendant des années, « souverain » relevait de la promesse commerciale. Le Cloud & AI Development Act (CADA) en fait une liste de critères qu'un organisme d'audit peut cocher — et une condition d'accès à la commande publique.
Le CADA déplace le critère d'appréciation : il ne s'agit plus seulement de savoir où résident les données, mais qui peut en disposer, ainsi que de l'exploitation et du logiciel, le moment venu. Les entités publiques doivent déterminer l'un des quatre niveaux CADA par cas d'usage et ne peuvent acheter que des services reconnus ; les entités critiques au sens de la directive NIS2 peuvent appliquer la même logique. La souveraineté devient donc documentable, auditable et contractualisable — c'est précisément notre terrain.
Parler d'emplacements de centres de données couvre un tiers du sujet. Les deux autres décident des niveaux CADA supérieurs.
Où résident les données clients — métadonnées et télémétrie comprises ? Qui y accède, avec quels droits, et cet accès est-il journalisé sans lacune ? Le chiffrement ne compte que si la gestion des clés est clarifiée.
Qui exploite réellement le service ? Dès le niveau 2 comptent la localisation du personnel et les canaux de support ; dès le niveau 3, la nationalité des équipes et, lorsque des informations classifiées sont en jeu, l'habilitation nationale.
Qui fournit le code et qui pourra encore le modifier demain ? Le niveau le plus élevé exige la preuve d'un contrôle effectif sur la conception, la maintenance, les correctifs de sécurité et l'évolution de chaque composant logiciel pertinent.
Chaque niveau du Cloud & AI Development Act contient le précédent et le durcit. Choisissez un niveau — la matrice indique le critère qui apparaît à ce stade.
À partir d'ici, un organisme d'audit indépendant contrôle. Nouveautés : personnel et support exclusivement dans l'Union, certificat européen de cybersécurité au moins « substantiel », interdiction d'entraîner une IA de pays tiers avec les données d'exploitation, SBOM complète et audits de code source pour les composants de pays tiers.
nouveau à ce niveauinchangé par rapport au niveau précédent
La résidence des données est un bon début — et couvre exactement le niveau CADA le plus bas. Cette comparaison évite bien des malentendus dans les appels d'offres.
Trois questions, une première orientation. L'attribution contraignante relève de l'évaluation des risques prévue à l'article 29 du Cloud & AI Development Act.
Cette estimation ne remplace ni un conseil juridique ni une évaluation des risques. Elle indique le corridor dans lequel vous vous situez probablement — la preuve solide, nous la construisons ensemble.
Six briques alignées sur le Cloud & AI Development Act — mobilisables séparément, conçues pour que chaque preuve serve plusieurs fois.
Nous cartographions votre parc cloud et l'évaluons selon les trois dimensions : données, exploitation, technologie. Y compris les questions rarement posées dans les questionnaires fournisseurs — flux de métadonnées, canaux de support, structure de propriété.
Résultat : Profil de souveraineté par charge de travail avec attribution provisoire d'un niveau
Nous confrontons la situation actuelle au niveau cible, quantifions l'écart et priorisons selon l'effort, la dépendance et la durée des contrats. Pas un programme maximal, mais un ordre de marche réalisable.
Résultat : Plan d'actions priorisé avec charge, séquence et responsabilités
Nous construisons la chaîne SBOM exigée au niveau 2, identifions les composants de pays tiers, cadrons les audits de code source et documentons les fonctions à distance à désactiver.
Résultat : Documentation auditable qui sert également le CRA
Un plan de migration documenté en cas de défaillance d'un fournisseur n'est pas qu'un critère de niveau 2 : c'est du pilotage d'externalisation. Nous ne l'écrivons pas seulement — nous le testons avec vous.
Résultat : Un plan de sortie testé plutôt qu'une déclaration d'intention
Nous formulons les exigences de souveraineté de façon liée à l'objet du marché, documentée et donc défendable — de la localisation des données, télémétrie comprise, aux droits d'audit et clauses de séparation.
Résultat : Clauses contractuelles solides et critères d'attribution tenables
Nous vous préparons à l'audit qui vient : BSI C5 comme attestation établie, BSI C3A pour la dimension souveraineté, et le travail préparatoire pour un futur schéma européen.
Résultat : Un dossier de preuves qui résiste à une revue tierce indépendante
Le cadre de souveraineté du Cloud & AI Development Act rejoint des textes que vous appliquez déjà — et réclame en grande partie les mêmes preuves.
L'attribution des niveaux suit la logique sectorielle de la directive NIS2. Si vous y êtes déjà classé, vous connaissez votre périmètre.
Voir la prestationDORARegistres, stratégies de sortie et risque de concentration couvrent une part substantielle des preuves de souveraineté.
Voir la prestationCRAL'obligation de SBOM est la même que celle apportée par le Cyber Resilience Act. Une mise en place, deux textes servis.
Voir la prestationBSI C5Une attestation C5 fournit une bonne part des preuves attendues par un auditeur pour les niveaux 2 à 4.
Voir la prestationBSI C3ALe catalogue C3A traite précisément les questions de contrôle que le cadre européen posera.
Voir la prestationEU AI ActLes systèmes d'IA hébergés et exploités à distance comptent expressément comme services cloud : la logique des niveaux vaut aussi pour l'IA managée.
Voir la prestationSix étapes rentables quelle que soit l'issue de la procédure législative du CADA — NIS2, DORA et le CRA exigent déjà les mêmes preuves.
Pas seulement « quel service, quelle région », mais : à qui appartient le fournisseur, où est l'équipe d'exploitation, quels sous-traitants sont dans la pile ?
Attribuez vos cas d'usage aux quatre niveaux à titre d'exercice. En quelques heures, vous voyez lesquels n'auraient aujourd'hui aucun fournisseur conforme.
Listes de sites, journaux d'accès, diagrammes de flux, SBOM : les preuves de l'annexe III sont très concrètes — et incomplètes dans la plupart des organisations.
Localisation des données y compris métadonnées, canaux de support, séparation des entités de pays tiers, droits d'audit. C'est le sujet de la prochaine négociation, pas de la suivante.
Un plan jamais répété ne vaut pas plus qu'une déclaration d'intention lors d'un audit. Un exercice par an suffit à faire la différence.
Regrouper les preuves, nommer les responsables, documenter la piste d'audit — pour que le premier appel d'offres ne tourne pas à la course aux justificatifs.
Ce que les décideurs nous demandent le plus souvent sur le CADA et la souveraineté du cloud.
Non. La Commission a présenté la proposition le 3 juin 2026 ; elle suit la procédure législative ordinaire. Selon le projet, le règlement entre en vigueur le vingtième jour suivant sa publication au Journal officiel et s'applique un an plus tard. Les critères et délais peuvent encore évoluer — pas la préparation.
Les entités publiques et de l'Union sont directement visées. Les entités relevant de NIS2 peuvent réaliser volontairement des évaluations comparables, et la Commission pourra le rendre obligatoire pour certains secteurs hautement critiques. Au-delà, le cadre fixe un standard de marché : ce qu'exigent les appels d'offres finit dans les questionnaires fournisseurs privés.
Elle aide beaucoup mais ne couvre pas tout. C5 traite la sécurité de l'information en exploitation cloud ; le cadre de souveraineté y ajoute propriété, contrôle, localisation du personnel et chaîne logicielle. Pour la dimension contrôle, le catalogue BSI C3A est plus proche.
Aucun schéma européen spécifique au cloud n'a été adopté à ce jour ; les négociations sont considérées comme bloquées. La proposition prévoit une règle transitoire : tant qu'aucun schéma de l'Union n'existe, les schémas nationaux s'appliquent, et à défaut le fournisseur doit démontrer les standards les plus élevés du droit de l'Union. En pratique : construire les attestations nationales maintenant, en visant la compatibilité européenne.
Pour un parc cloud de taille moyenne, comptez deux à quatre semaines jusqu'au profil de souveraineté, selon la solidité de votre documentation contractuelle et opérationnelle. L'analyse d'écart s'enchaîne directement.
En règle générale non, et sûrement pas dans la précipitation. Ce qui compte : trier vos charges de travail, améliorer la base de preuves et préparer votre position de négociation pour le prochain cycle contractuel. Le changement est une option parmi d'autres, pas le point de départ.
Les sources primaires du Cloud & AI Development Act — et nos pages de connaissances pour aller plus loin.
Trente minutes, votre portefeuille réel, une lecture honnête : nous confrontons votre parc cloud aux quatre niveaux d'assurance du Cloud & AI Development Act et nommons les écarts déjà comblables.
