Le Cloud and AI Development Act, que la Commission a publié le 3 juin au sein du paquet sur la souveraineté technologique, se prête à une lecture commode. C’est la lecture géographique, celle des mégawatts et des délais de délivrance des autorisations, de l’endroit où finissent physiquement les octets et du fournisseur américain qui restera hors des marchés publics européens. Il faut reconnaître que c’est une lecture défendable, parce que les chiffres la soutiennent. La part de marché des fournisseurs cloud européens est tombée d’environ vingt-neuf pour cent en 2017 à environ quinze pour cent en 2022, le manque de capacité dans les data centers est documenté, l’ambition affichée est de tripler cette capacité en cinq à sept ans, et le premier des quatre niveaux d’assurance prévus par le règlement demande littéralement que le traitement et le stockage des données se fassent sur une infrastructure européenne. De là l’interprétation qui circule sur toutes les tables ces dernières semaines, et c’est la plus rassurante qu’on puisse imaginer : souveraineté veut dire que les données sont rentrées à la maison.
Au-delà du premier niveau
Cette interprétation a un défaut, et le défaut est qu’elle s’arrête au premier niveau. Si l’on lit au-delà, le centre de gravité du règlement se déplace vers un point bien moins photogénique. Le deuxième niveau ne demande pas où sont les données. Il demande une indépendance démontrable vis-à-vis des pays tiers et une transparence sur la chaîne d’approvisionnement du logiciel. Le quatrième niveau exige le contrôle plein sur cette même chaîne, sans interférences extérieures sur le code qui tourne. Il y a ensuite un mécanisme plus subtil, qui vit dans les règles de marchés publics : les administrations devront considérer la valeur ajoutée pour l’Union comme critère non économique dans l’attribution, c’est-à-dire dans quelle mesure un fournisseur contribue à la résilience de la filière numérique européenne. Le règlement précise que ce critère doit rester accessoire et non décisif, avec un poids maximal que les considérants situent autour de quinze points sur cent vingt, et pourtant il introduit malgré tout un avantage structurel pour qui a sa recherche et sa production à l’intérieur des frontières. Et puis il y a la partie qui touche mon travail de plus près, parce qu’elle sort du périmètre du secteur public : le règlement donne à la Commission le pouvoir d’étendre, par actes délégués, les mêmes obligations d’évaluation de la souveraineté aux entreprises privées des secteurs déjà encadrés par NIS2, c’est-à-dire les banques, l’énergie, les télécommunications, la santé. Quiconque construit du logiciel pour ces secteurs ferait bien de lire au-delà du premier niveau.
Le pari que l’Europe a posé au début de juin, sous le vernis infrastructurel, n’est pas géographique. C’est un pari sur la provenance vérifiable du code. Et il n’arrive pas maintenant par hasard. Ce sont les mêmes semaines où le continent a touché du doigt ce que signifie dépendre de décisions prises ailleurs, quand une mesure unilatérale de contrôle des exportations a rendu indisponibles du jour au lendemain des modèles de pointe déjà utilisés par des milliers de personnes. Le CADA est, pour une bonne part, le reflet structurel de cette dépendance ressentie. La question implicite qui le traverse n’est pas où tu gardes tes données, mais si tu es capable de savoir, et de démontrer, ce qu’il y a à l’intérieur du logiciel que tu fais tourner. Mieux vaut garder ce mot en tête, provenance, parce que dans ces mêmes quinze jours quelqu’un en a montré le fond.
Dix mille dépôts qui font semblant
Le 18 juin, un chercheur signant sous le pseudonyme Orchid a publié les résultats d’une enquête de plusieurs mois. L’histoire a commencé de la façon la plus banale : en cherchant son propre projet sur un moteur de recherche, Orchid a trouvé à sa place un clone au nom et à la description identiques, hébergé par un autre compte. De là est partie la chasse, menée avec un seul script Python qui a passé au crible seize millions d’événements de push enregistrés dans l’archive publique de GitHub à la recherche d’une signature récurrente. Le résultat est un chiffre qui, en avril, dans une analyse antérieure d’autres chercheurs, s’arrêtait à cent neuf dépôts, et qui en juin atteignait environ dix mille, la campagne étant active depuis au moins début 2025. Tous distribuaient la même famille de logiciels malveillants, un loader qui ouvrait la voie à un programme de vol d’identifiants. Le détail qui fait la différence, et que la plupart des récits ont traité comme un point technique, c’est la manière dont ces dépôts se rendaient crédibles. Ce n’étaient pas des forks. C’étaient des clones créés de toutes pièces, avec l’historique des commits copié tel quel depuis le projet original et l’attribution laissée intacte sur les auteurs réels, si bien qu’en cliquant sur les contributeurs apparaissaient des comptes vrais et anciens. La seule modification était un lien dans le fichier de description qui pointait vers une archive compressée. Ce qui les faisait paraître fiables, c’était précisément le signal de provenance sur lequel nous nous appuyons depuis dix ans : l’historique long et les auteurs reconnaissables, l’air d’un projet qui a vécu.
Certains de ces dépôts survivaient depuis plus d’un an, et y parvenaient grâce à une ruse qui en dit long sur le fonctionnement de la confiance automatisée. Ils effaçaient périodiquement le dernier commit et en republiaient un identique, toujours intitulé de la même façon, toutes les quelques heures. Cela suffisait à brouiller les algorithmes de sécurité de la plateforme, réglés pour signaler l’activité soudainement suspecte plus que l’anomalie discrète et prolongée. Mais la partie qui devrait inquiéter davantage que le chiffre, c’est la réponse de GitHub à ceux qui, avant Orchid, avaient signalé le mécanisme par les canaux officiels. La plateforme a rejeté les rapports en soutenant que les commits antidatés sont un cas d’usage légitime pour qui travaille hors ligne, et a qualifié le fait de rendre plus visible l’historique réel des push de demande de fonctionnalité, non de correction de sécurité. Traduit : la plateforme qui héberge la quasi-totalité de l’open source mondial a décidé que le problème de la provenance n’est pas son problème. Orchid, face au silence, a publié tant l’outil de détection que la liste complète des dépôts repérés, parce que les signaler un par un était matériellement impossible.
Une lignée, pas un incident
Cela vaut la peine de replacer cette affaire dans une lignée, parce que seule elle ressemble à un incident et alignée avec les autres elle révèle une direction. En 2020, SolarWinds avait montré qu’on pouvait frapper des milliers d’organisations en compromettant un seul fournisseur en amont. En 2024, le cas de XZ Utils avait relevé le seuil de patience, avec un attaquant qui avait passé des mois à gagner la confiance d’un projet open source pour y insérer une backdoor en qualité de mainteneur légitime. 2026 a déplacé la cible encore plus loin. En mai, la campagne rebaptisée Megalodon a injecté en quelques heures des workflows malveillants dans plus de cinq mille dépôts, conçus pour voler les secrets des pipelines d’intégration continue et tout identifiant cloud à portée. Dans les mêmes jours, GitHub lui-même a confirmé que l’appareil d’un de ses employés, infecté via une extension malveillante d’un éditeur très répandu, avait permis l’exfiltration d’environ trois mille huit cents dépôts internes. La campagne d’Orchid se déplace sur un axe différent mais complémentaire : elle ne compromet pas un projet réel, elle en fabrique de faux qui revêtent les habits des vrais. Mises en séquence, ces histoires racontent un seul mouvement. La surface d’attaque s’est déplacée du code vers les métadonnées de la confiance, et des mains humaines vers les pipelines automatiques. Pendant que nous déplacions le développement vers l’orchestration d’agents qui clonent et exécutent du code sans plus la friction du jugement humain, l’adversaire apprenait à falsifier justement les signaux que cette friction, autrefois, lisait. Et ce n’est pas une figure de style. Orchid a remarqué que beaucoup de ces dépôts étaient construits pour appâter les agents, pas seulement les personnes. Le mécanisme a été décrit par une recherche parallèle sur les vulnérabilités des assistants de codage : des fichiers de configuration empoisonnés, les instructions que des outils comme Copilot ou Cursor lisent au démarrage pour savoir comment se comporter, écrites de manière à détourner en silence tout le code généré à partir de là dans la session. L’instruction malveillante survit à la copie du dépôt et se propage aux projets en aval. Quand c’est un agent qui clone, puis écrit du code à ta place, le faux signal de provenance cesse de tromper un être humain distrait et commence à contaminer la source même de ce qui sera produit.
Ouvert ne veut pas dire inspecté
À ce stade, l’éditorialiste paresseux a déjà son article tout prêt, et même le titre. L’open source first rencontre l’open source que personne ne vérifie. La souveraineté européenne bâtie sur le code inspectable, démentie dans les mêmes quinze jours par dix mille projets inspectables et toxiques. C’est une ironie qui tient le temps d’un billet et pas un millimètre de plus, parce qu’elle repose sur un malentendu qu’il vaut mieux démonter calmement.
L’argument en faveur de l’open source comme fondement de la souveraineté est correct, et il faut le prendre au sérieux avant d’essayer de l’entamer. Un composant dont les sources sont publiques et les dépendances déclarées part d’une meilleure position qu’un stack propriétaire dans lequel on ne peut pas regarder. C’est la thèse que SUSE a formulée avec précision en commentant le règlement : l’infrastructure ouverte, où chaque composant est inspectable et chaque dépendance déclarée, satisfait cette exigence de transparence d’une manière que le logiciel fermé n’atteint pas. C’est vrai. La campagne d’Orchid ne démonte pas cette thèse, elle la déplace d’un pas, sur un terrain qu’elle ne couvrait pas. Ouvert veut dire inspectable en principe. Cela ne veut pas dire inspecté. Et à l’échelle de centaines de millions de dépôts, le principe est précisément le lieu où se nichent les attaques. La confiance, dans le développement logiciel, est une économie comme toutes les autres, et comme toutes les autres elle cherche à économiser. Lire vraiment le code de chaque dépendance que nous importons coûterait plus que le temps dont nous disposons, et donc nous ne le faisons presque jamais. Nous lisons les signaux qui l’entourent : le nombre d’étoiles, l’historique, les auteurs, la position dans les résultats de recherche. Ces signaux sont une procuration, une délégation que nous signons en trois secondes chaque fois que nous clonons quelque chose. Les attaquants d’Orchid n’ont pas violé notre capacité à lire le code. Ils ont appris à frapper la monnaie avec laquelle nous payons la confiance pour ne pas avoir à le lire. La falsification ne concerne pas la source, elle concerne l’appareil qui nous dispense de la regarder.
La SBOM devient loi
Ici le propos cesse d’être philosophique et devient une échéance sur le calendrier. L’outil qui transforme la transparence promise par le règlement en quelque chose d’opérationnel existe, porte un nom peu élégant et une base juridique désormais précise. C’est la nomenclature des matériaux du logiciel, la SBOM, et avec le Cyber Resilience Act elle devient pour la première fois une obligation légale et non plus une bonne pratique. Les dates sont rapprochées. À partir du 11 septembre 2026, quiconque met sur le marché européen un produit comportant des éléments numériques doit notifier les vulnérabilités activement exploitées sous vingt-quatre heures. À partir du 11 décembre 2027, il doit conserver dans la documentation technique une SBOM dans un format lisible par la machine, qui couvre au moins les dépendances de premier niveau et reste à jour pendant toute la période de support du produit. Les sanctions sont calibrées sur le modèle du RGPD, jusqu’à quinze millions d’euros ou deux et demi pour cent du chiffre d’affaires mondial. Et il y a un détail que beaucoup ne découvrent qu’à la première évaluation : on ne peut pas notifier ce qu’on ne sait pas avoir. L’échéance de septembre 2026 sur les vulnérabilités fait de la SBOM un prérequis pratique dès maintenant, bien avant qu’elle ne devienne formellement obligatoire, parce que sans un inventaire précis des dépendances la fenêtre de vingt-quatre heures est impossible à respecter.
Travaillant depuis longtemps sur des outils de ce type pour des clients dans des secteurs réglementés comme la santé et l’administration publique, le malentendu que je rencontre le plus souvent est que la SBOM serait le produit à livrer. Elle ne l’est pas. La SBOM est la question. Et ici il vaut mieux faire d’emblée une concession à ceux qui connaissent la matière, parce que l’objection est fondée et qu’il faut la désamorcer avant qu’elle ne soit soulevée. Une nomenclature des matériaux, prise pour ce que la plupart des organisations en font, l’attaque d’Orchid ne la voit même pas. Ces dépôts n’enfoncent pas une dépendance malveillante dans ton manifeste, ils te convainquent de cloner et d’exécuter un projet qui revêt les habits d’un autre. Un scanner qui compare ton arbre de dépendances à une base de vulnérabilités connues passe à travers sans rien remarquer, parce que la tromperie n’habite pas dans la liste, elle habite dans l’origine de ce que la liste énumère. Et c’est exactement là le point. La version inutile de la SBOM, celle qu’on produit en premier presque partout, est un arrêt sur image : une liste statique de composants, peut-être un PDF, générée la veille de l’audit et jamais retouchée, qui dit ce que tu as mis dedans et tait d’où ça vient et si c’est bien ce que ça prétend être. Les dix mille dépôts de la campagne passeraient un contrôle de ce genre sans sourciller. La question qui compte n’est pas quels composants sont là, c’est si chacun d’eux provient vraiment d’où il prétend provenir, et à cette question ne répond pas un document, répond une vérification exécutée à l’instant précis où le composant entre dans la build.
Qui signe la déclaration
Et c’est ici que la SBOM, seule, ne suffit pas, parce qu’une SBOM est une déclaration, et une déclaration se falsifie avec la même facilité qu’un historique de commits. La vraie question recule d’un pas : qui signe cette déclaration, et combien il est difficile pour un attaquant d’en signer une fausse. La réponse, pour qui travaille dans la sécurité de la filière, passe par une couche d’outils qui a beaucoup mûri ces dernières années. Le modèle de référence s’appelle SLSA et définit par niveaux la fiabilité de l’histoire de la fabrication d’un artefact. Cette histoire s’exprime dans un format d’attestation signée qui s’appelle in-toto, et signée pour de bon grâce à Sigstore, qui évite le fardeau de gérer des clés à long terme en liant chaque signature à une identité vérifiée sur le moment et en enregistrant sa trace dans un registre public et immuable. Le point crucial de ce dispositif n’est pas la cryptographie en soi, c’est qui tient la plume. L’autocertification ne vaut rien : si c’est le même script de build qui génère la preuve de sa propre honnêteté, un attaquant qui contrôle le script peut faire dire à la preuve ce qu’il veut. On l’a vu il y a quelques mois avec une attaque sur la chaîne des paquets qui portait des attestations de provenance cryptographiquement valides, produites toutefois par une plateforme de construction qui ne garantissait pas l’isolement exigé par les niveaux les plus élevés de SLSA. La provenance ne devient crédible que lorsqu’elle est générée par un environnement isolé, contrôlé par la plateforme et non par l’utilisateur, de sorte que même celui qui a accès à la configuration ne puisse mentir. Ce n’est pas un hasard si les builds reproductibles, c’est-à-dire la capacité de reconstruire bit pour bit le même artefact à partir des mêmes sources, ont été retirées des versions récentes de SLSA : elles étaient l’idéal théorique, et se sont révélées trop difficiles à obtenir en pratique. La vérification, elle aussi, a donc sa régression. Quelqu’un doit certifier le certificateur, et la seule réponse solide est de placer ce quelqu’un hors de portée de qui aurait intérêt à tricher.
Et ici l’ironie que l’éditorialiste paresseux avait entrevue revient, mais bien plus aiguisée qu’il ne l’avait laissée. La couche d’attestation que je viens de décrire est mature. GitHub lui-même offre nativement la génération de preuves de provenance signées pour les artefacts qui sortent de ses pipelines, et atteindre un niveau d’assurance correct est aujourd’hui l’affaire d’une après-midi de travail, non plus d’un projet de plusieurs semaines. La plateforme, autrement dit, fournit le cadenas cryptographique pour le paquet que tu produis et laisse en même temps falsifiable par choix la plaque avec le nom sur la porte du dépôt d’où ce paquet semble provenir. Elle met à disposition les outils pour démontrer qu’un artefact vient d’une certaine build, et refuse de rendre plus difficile de feindre qu’un projet entier vient d’un certain auteur. Les deux choses vivent à la même adresse et ne se parlent pas.
Où habite la souveraineté
Alors revenons à la question dont nous sommes partis, où habite la souveraineté. Pas dans le data center, qui est la partie facile à légiférer et facile à mesurer, et c’est exactement pour cela que tout le monde en parle. La géographie des octets est un problème résolu sur le papier au moment où tu l’écris dans un cahier des charges. La provenance des composants qui tournent dans ce data center est un problème qu’il faut démontrer à nouveau à chaque build, sur chaque dépendance, contre un adversaire qui a tout intérêt à paraître en règle. L’Europe a fait, peut-être sans le dire jusqu’au bout, de la provenance le mur porteur de tout l’édifice. Mais le langage du règlement nomme le résultat et tait le mécanisme. Il demande la transparence sur la chaîne d’approvisionnement et ne dit pas signée par qui, ni vérifiée selon quel critère au moment de la mise en production. La distance entre avoir une SBOM et pouvoir démontrer que la SBOM dit vrai est l’enjeu tout entier, et c’est précisément la distance que ces mêmes quinze jours de juin ont mise à ciel ouvert. D’un côté un règlement qui parie sur la filière vérifiable, de l’autre un chercheur seul qui, avec un script, démontre que la filière, aujourd’hui, ne sait pas s’attester elle-même.
Reste à dire la chose qui dérange. L’open source first est le bon principe et un principe vide tant qu’ouvert n’est pas couplé à attesté. La transparence des sources est une condition nécessaire de la souveraineté et n’est en aucune manière suffisante, parce qu’entre le pouvoir regarder et l’avoir regardé s’ouvre l’espace dans lequel un adversaire construit dix mille dépôts que personne ne regarde. La souveraineté n’est pas un lieu qu’on atteint, c’est une propriété qu’on ne cesse de démontrer, et elle cesse d’exister à l’instant exact où l’on cesse de la vérifier. La SBOM n’est pas un meuble de la conformité à garder dans un coin pour l’auditeur, c’est le point où le mot souveraineté touche terre, à condition qu’il y ait en dessous une chaîne d’attestation qui le soutient.
Que GitHub ait appelé fonctionnalité la correction qui aurait rendu plus difficile la falsification de la provenance est le détail le plus révélateur de toute l’histoire. La plateforme a décidé que le niveau de vérification, ce n’est pas elle qui le construit. Ce qui signifie que, pour quiconque prend au sérieux le langage du règlement européen, ce niveau devient un travail à faire ailleurs, dans les pipelines et les pratiques de ceux qui livrent du logiciel pour les secteurs que la loi est sur le point de resserrer. Le pari européen sur la souveraineté de la filière est, au fond, le pari que quelqu’un construise la couche d’attestation que la plateforme refuse de construire. Cette couche est le vrai travail. Tout le reste, ce sont des mégawatts.
Ce qu'il faut retenir
Le CADA n’est pas une loi géographique. Le premier niveau d’assurance demande une infrastructure européenne, mais à partir du deuxième niveau le règlement exige une indépendance démontrable et une transparence sur la chaîne d’approvisionnement du logiciel. Le pari européen porte sur la provenance vérifiable du code, pas sur les mégawatts.
La Commission peut étendre les obligations d’évaluation de la souveraineté, par actes délégués, aux entreprises privées des secteurs NIS2 : banques, énergie, télécommunications, santé. Qui construit du logiciel pour ces secteurs est déjà dans le périmètre, même hors du secteur public.
Ouvert veut dire inspectable, pas inspecté. Les dix mille dépôts de la campagne Orchid n’ont pas violé notre capacité à lire le code : ils ont falsifié les signaux de provenance (historique, auteurs, position dans les résultats) sur lesquels nous nous appuyons pour ne pas le lire.
La SBOM imposée par le CRA est une échéance, pas une bonne pratique : vulnérabilités activement exploitées à notifier sous 24 heures dès le 11 septembre 2026, nomenclature des matériaux lisible par la machine obligatoire à partir du 11 décembre 2027, sanctions jusqu’à 15 millions d’euros ou 2,5 % du chiffre d’affaires mondial. On ne peut pas notifier ce qu’on ne sait pas avoir.
Une SBOM est une déclaration, et une déclaration se falsifie. Il faut une chaîne d’attestation signée (SLSA, in-toto, Sigstore) générée par un environnement isolé que même celui qui contrôle la configuration ne peut altérer. Cette couche, GitHub refuse de la construire : c’est le vrai travail, et c’est un travail à faire dans les pipelines de ceux qui livrent du logiciel aux secteurs réglementés.
Questions & réponses
Qu'est-ce que le Cloud and AI Development Act (CADA) ?
C’est la proposition de règlement que la Commission européenne a publiée le 3 juin 2026 au sein du paquet sur la souveraineté technologique. Elle naît de chiffres précis : la part de marché des fournisseurs cloud européens est tombée d’environ 29 % en 2017 à environ 15 % en 2022, et l’ambition affichée est de tripler la capacité des data centers européens en cinq à sept ans. Mais au-delà du premier niveau d’assurance, qui demande une infrastructure européenne, le règlement exige une indépendance démontrable vis-à-vis des pays tiers et une transparence sur la chaîne d’approvisionnement du logiciel.
Le CADA ne concerne-t-il que l'administration publique ?
Non. Le règlement donne à la Commission le pouvoir d’étendre, par actes délégués, les mêmes obligations d’évaluation de la souveraineté aux entreprises privées des secteurs déjà encadrés par NIS2 : banques, énergie, télécommunications, santé. Quiconque construit du logiciel pour ces secteurs ferait bien de lire au-delà du premier niveau.
Qu'est-ce que la campagne découverte par Orchid ?
Le 18 juin 2026, un chercheur signant sous le pseudonyme Orchid a publié une enquête de plusieurs mois : environ dix mille dépôts GitHub qui distribuaient la même famille de logiciels malveillants en se faisant passer pour des projets honnêtes. Ce n’étaient pas des forks, mais des clones créés de toutes pièces avec l’historique des commits copié tel quel et l’attribution laissée intacte sur les auteurs réels. Certains survivaient depuis plus d’un an en republiant toutes les quelques heures un commit identique, pour brouiller les algorithmes de sécurité réglés sur l’activité soudainement suspecte plus que sur l’anomalie discrète et prolongée.
Qu'est-ce qu'une SBOM et quand devient-elle obligatoire ?
La SBOM (Software Bill of Materials) est la nomenclature des matériaux du logiciel, la liste des composants et des dépendances. Avec le Cyber Resilience Act, elle devient pour la première fois une obligation légale : à partir du 11 septembre 2026, quiconque met sur le marché européen un produit comportant des éléments numériques doit notifier les vulnérabilités activement exploitées sous 24 heures ; à partir du 11 décembre 2027, il doit conserver dans la documentation technique une SBOM dans un format lisible par la machine. Les sanctions atteignent 15 millions d’euros ou 2,5 % du chiffre d’affaires mondial.
Si j'ai une SBOM, suis-je à l'abri des attaques de provenance ?
Non. Une SBOM prise comme un arrêt sur image, une liste statique générée la veille de l’audit, ne voit pas la campagne d’Orchid : ces dépôts n’insèrent pas une dépendance malveillante dans votre manifeste, ils vous convainquent de cloner et d’exécuter un projet qui revêt les habits d’un autre. Et une SBOM reste une déclaration, qui se falsifie. Il faut une chaîne d’attestation signée (SLSA, in-toto, Sigstore) générée par un environnement isolé contrôlé par la plateforme et non par l’utilisateur, de sorte que même celui qui a accès à la configuration ne puisse mentir.
L'auteur
