Le Cloud and AI Development Act : ce que l'Europe cherche vraiment à corriger

Le Cloud and AI Development Act est l'expression la plus nette, à ce jour, de ce qu'est devenue la politique technologique européenne. Ce n'est ni une loi de protection des consommateurs ni une loi de sécurité. C'est de la politique industrielle, et elle vise un problème unique : l'Europe fait tourner l'essentiel de son économie numérique sur une infrastructure qu'elle ne maîtrise pas.

On est donc dans un autre registre que le RGPD ou le règlement sur l'IA, et le texte vous atteindra par un tout autre canal. Comprendre lequel compte davantage que de lire les considérants.

Le problème auquel il répond

Personne ne conteste les chiffres. La très grande majorité des dépenses cloud européennes va à des fournisseurs non européens. Les plus grands modèles d'IA qu'utilisent les entreprises européennes sont entraînés et hébergés hors d'Europe. La puissance de calcul européenne ne représente qu'une petite fraction du total mondial.

Pendant dix ans, on y a vu un simple résultat de marché. Depuis 2022, on y voit une vulnérabilité stratégique, pour des raisons qui n'ont rien de technique : tensions commerciales, contrôles à l'exportation, et la découverte que la dépendance en matière d'infrastructure constitue un moyen de pression.

Le Cloud and AI Development Act est le bras législatif de cette réévaluation. Il s'inscrit aux côtés du plan d'action pour un continent de l'IA, de l'initiative InvestAI, du programme de gigafactories d'IA et de l'agenda de compétitivité issu du rapport Draghi.

Ce qu'il est censé faire

La proposition était attendue pour le début de l'année 2026, comme texte phare du programme de travail de la Commission. Les objectifs affichés ne varient pas d'une annonce à l'autre :

Renforcer la capacité européenne à développer, déployer et faire passer à l'échelle le cloud et l'IA. En pratique, il s'agit de puissance de calcul, de centres de données et de la capacité à entraîner et à servir de grands modèles au sein de l'UE.

Combler les lacunes réglementaires. Le cadre actuel traite le cloud surtout par les dispositions du règlement sur les données relatives au changement de fournisseur, et par les obligations de sécurité de NIS2. Ni l'un ni l'autre n'aborde la capacité ou la dépendance stratégique.

Promouvoir l'interopérabilité. Réduire le coût technique d'un changement de fournisseur : c'est exactement l'objectif que le règlement sur les données poursuit, lui, par le versant contractuel.

Établir une politique cloud à l'échelle de l'UE pour les administrations et la commande publique. C'est celui qui a du mordant. Une approche commune de la façon dont les organismes publics des États membres achètent du cloud, assortie d'une dimension de préférence européenne.

Soutenir un écosystème cloud et IA européen sûr et compétitif. La rubrique fourre-tout.

Le mécanisme qui vous atteindra vraiment

Voici ce qu'il faut avoir compris de ce dossier. La plupart des réglementations technologiques touchent directement les entreprises privées : vous traitez des données personnelles, donc le RGPD s'applique. Le Cloud and AI Development Act, lui, touchera la plupart des entreprises de façon indirecte, par la commande publique.

Les dépenses technologiques du secteur public dans l'UE sont considérables. Si les organismes publics des États membres se voient obligés, ou fortement incités, à acheter du cloud européen, c'est le marché adressable de tout fournisseur du secteur public qui change, et l'effet se propage des titulaires de marchés jusqu'à leurs sous-traitants.

On a déjà vu ce scénario avec l'accessibilité. La directive européenne sur l'accessibilité comporte des obligations directes, mais une grande partie du travail d'accessibilité a en réalité été déclenchée par des règles de commande publique qui écartaient les fournisseurs non conformes bien avant l'entrée en application de la directive.

Attendez-vous à la même chose ici. Si vous vendez du logiciel à des acheteurs publics européens, savoir où tourne votre infrastructure, qui la contrôle et si elle peut être migrée passera du questionnaire de sécurité aux critères de qualification.

Ce que cela implique pour l'architecture

Devant une politique de souveraineté, le réflexe est soit de l'ignorer, soit de migrer dans la panique. Ni l'un ni l'autre n'est la bonne réponse. Ce qui est raisonnable, c'est de pouvoir répondre à la question le jour où elle sera posée.

Sachez où se trouvent réellement vos données et votre puissance de calcul

Cela paraît trivial. Ça ne l'est pas. Dans un système arrivé à maturité, la réponse honnête à « où est-ce que ça tourne » fait souvent intervenir une région principale, une région de secours, un CDN dont on ne sait pas trop où sont les points de présence, une base de données managée, trois dépendances SaaS avec leurs propres sous-traitants, un fournisseur d'observabilité et une API d'IA dont le lieu d'inférence n'est documenté nulle part.

Dresser une carte exacte est le premier vrai chantier, et c'est exactement la carte qu'il vous faut pour l'analyse des transferts au titre du RGPD et pour les questions de chaîne d'approvisionnement posées par NIS2. Autant ne la faire qu'une fois.

Séparez ce qui est portable de ce qui ne l'est pas

Presque tout système a un noyau portable et un jeu de dépendances propres au fournisseur. Le noyau portable, c'est en général l'application. Les parties non portables, ce sont en général les services managés : bases de données propriétaires, environnements d'exécution serverless, files de messages, identité et, de plus en plus, API de modèles.

Rien ne vous oblige à les éliminer. Vous devez en revanche savoir exactement lesquelles, parce que cette liste constitue la réponse honnête à la question du coût d'une migration, et que c'est bien ce que cherche à savoir un questionnaire d'appel d'offres.

Traitez les fournisseurs de modèles comme une frontière d'abstraction

C'est le point le plus récent et celui qu'on saute le plus souvent. Les applications qui appellent directement l'API d'un seul fournisseur, avec des formats de prompt et un traitement des réponses propres à ce fournisseur, éparpillés dans tout le code, ont pris une décision de dépendance sans même s'en apercevoir.

Une fine couche d'abstraction sur les appels de modèle ne coûte presque rien à écrire et vous donne la possibilité de router vers un fournisseur européen, vers un modèle à poids ouverts sur infrastructure européenne, ou vers un tout autre prestataire. Vu la vitesse à laquelle le paysage des modèles se recompose, cela se justifie déjà sur des bases purement commerciales.

Testez la sortie, ne vous contentez pas de la documenter

Le règlement sur les données vous ouvre déjà un droit de changer de fournisseur cloud, les frais de changement disparaissant totalement au 12 janvier 2027. Très peu d'acheteurs exercent ce droit, et moins encore vérifient si l'export auquel ils ont droit permettrait réellement de reconstituer leur service.

Lancez l'export. Essayez de l'exploiter. L'écart entre ce qu'un fournisseur déclare exportable et ce qui est effectivement utilisable, c'est là que se loge l'enfermement propriétaire, et c'est aussi la réponse honnête à une question de souveraineté.

Ce qu'il n'est pas

Un peu de scepticisme est de mise, et mieux vaut être lucide maintenant que surpris plus tard.

Ce n'est pas une interdiction du cloud américain. Rien de ce qui a été annoncé ne laisse penser que les entreprises privées se verraient interdire les fournisseurs non européens. Le levier, c'est la préférence dans la commande publique et le développement de capacités, pas l'interdiction.

Une loi ne fait pas apparaître de la capacité. Si la capacité cloud européenne est limitée, c'est parce que construire des centres de données et entraîner des modèles de pointe exige des capitaux considérables et que l'Europe n'a engagé de tels montants que très récemment. Les programmes de financement décrits dans notre guide du financement technologique européen sont le véritable instrument. Le texte, lui, n'est que le cadre qui les entoure.

Un label souverain ne fait pas la souveraineté. Plusieurs offres se présentent comme du cloud souverain tout en tournant sur une technologie non européenne sous licence, avec des degrés très variables d'indépendance opérationnelle. Reste à savoir si cela suffira au regard d'une future règle de commande publique : c'est précisément la question à laquelle le texte devra répondre, et il ne l'a pas encore fait.

Ce n'est encore qu'une proposition. Tant qu'il n'existe pas de texte entouré des positions du Conseil et du Parlement, on ne peut rien savoir du détail. Ce qu'on sait, en revanche, c'est le cap, resté constant sur trois ans de communication de la Commission.

Comment cela se rattache au reste

Le Cloud and AI Development Act n'est qu'une pièce d'un dispositif coordonné, et le lire isolément le fait paraître plus faible qu'il ne l'est.

Le règlement sur l'IA encadre le comportement des systèmes d'IA. Le règlement sur les données s'attaque au verrouillage cloud par le contrat. NIS2 propage l'examen de la chaîne d'approvisionnement jusqu'aux fournisseurs. Le règlement sur la cyberrésilience impose des obligations de sécurité aux produits. InvestAI et le programme de gigafactories mettent de l'argent dans la puissance de calcul. Le Cloud and AI Development Act, lui, ajoute la couche commande publique et interopérabilité.

Pris séparément, chacun ressemble à une contrainte de plus. Ensemble, ils dessinent un pari plutôt cohérent : l'Europe peut se doter d'une base technologique qui lui appartienne à force de régulation, en combinant règles d'accès au marché et argent public.

Savoir si ce pari est gagnant est une question légitime. Constater qu'il a été engagé n'en est pas une.

Quoi faire dans les douze prochains mois

Dressez la carte de votre infrastructure. Ce qui tourne où, qui l'exploite, quelle est la porte de sortie contractuelle. Cette carte vous servira à quatre autres choses.

Repérez vos dépendances réellement non portables et chiffrez honnêtement la migration, même si vous ne la faites jamais. C'est la réponse à la question de l'acheteur public, et c'est aussi de la simple hygiène architecturale.

Posez une abstraction sur les fournisseurs de modèles si ce n'est pas déjà fait. Peu coûteux aujourd'hui, très coûteux plus tard, et utile pour des raisons totalement étrangères à la politique.

Si vous vendez à des acheteurs publics européens, suivez le volet achats de plus près que le texte lui-même. C'est là que l'exigence apparaîtra d'abord, sous forme de critère de qualification.

Ne migrez pas sur une simple spéculation. Déplacer une infrastructure à cause d'une proposition non publiée, c'est le meilleur moyen d'y passer un an et un gros budget pour une exigence qui, au bout du compte, ne s'imposait pas.

Obtenir de l'aide

Nous concevons et construisons des infrastructures cloud, des plateformes de données et des intégrations d'IA pour des entreprises actives en Europe, y compris le travail ingrat qui consiste à rendre un système réellement portable et pas seulement portable sur le papier.

Si vous avez besoin d'une carte de votre infrastructure et de vos dépendances, d'un test de sortie grandeur nature chez votre fournisseur actuel, ou d'une couche d'abstraction sur les fournisseurs de modèles, écrivez à office@c9group.dev. Vous trouverez plus de détails sur notre travail d'infrastructure sur la page optimisation des coûts AWS et sur notre travail européen sur la page entrée sur le marché européen.

Le tableau législatif d'ensemble figure dans notre panorama législatif numérique de l'UE, et l'argent qui finance cet agenda est cartographié dans notre guide du financement technologique européen.

Nous sommes ingénieurs, pas conseils en politiques publiques. Ce texte est une lecture de planification portant sur une proposition, pas un conseil juridique.