AI Act 2026 : la transparence énergétique des clouds

Le déploiement rapide de l’intelligence artificielle transforme les besoins d’hébergement : davantage de calcul GPU, des baies plus denses, des contraintes de refroidissement accrues et une consommation électrique qui varie fortement selon les modèles et les usages. Dans ce contexte, l’AI Act européen est souvent présenté comme un futur outil de transparence environnementale des clouds. La réalité est plus nuancée.

Le règlement européen sur l’intelligence artificielle, officiellement le règlement (UE) 2024/1689, impose des obligations importantes aux fournisseurs de systèmes d’IA et de modèles d’IA à usage général. Mais il ne crée pas, à lui seul, une fiche environnementale publique et standardisée pour chaque offre de cloud. Pour choisir une infrastructure réellement plus sobre, il faut donc combiner les exigences réglementaires, les informations techniques demandées à l’hébergeur et une lecture critique de ses engagements climatiques.

Voici une grille de lecture concrète pour évaluer un cloud destiné à l’IA, sans confondre conformité réglementaire et promesse de « cloud vert ».

AI Act 2026 : ce que le règlement impose réellement

L’AI Act est entré en vigueur le 1^er août 2024. Son application est progressive : certaines règles, notamment sur les pratiques interdites et la culture de l’IA, s’appliquent déjà depuis février 2025 ; les obligations applicables aux modèles d’IA à usage général ont commencé à s’appliquer en août 2025 ; l’essentiel des règles devient applicable à partir d’août 2026. Certains systèmes d’IA à haut risque intégrés à des produits réglementés suivent un calendrier distinct.

Son objet principal est la sécurité, le respect des droits fondamentaux, la gouvernance et la transparence des systèmes d’IA. Le règlement s’adresse notamment :

aux fournisseurs qui développent un système d’IA ou le font développer avant de le commercialiser sous leur nom ;
aux déployeurs, c’est-à-dire les organisations qui utilisent un système d’IA dans le cadre de leur activité ;
aux fournisseurs de modèles d’IA à usage général, souvent désignés par l’acronyme GPAI ;
aux importateurs, distributeurs et représentants autorisés concernés.

Un fournisseur d’infrastructure à la demande, comme un opérateur IaaS proposant des machines virtuelles ou des instances GPU, n’est donc pas automatiquement soumis aux mêmes obligations qu’un fournisseur de modèle d’IA. Tout dépend de son rôle réel. Un hébergeur qui fournit seulement des ressources de calcul ne devient pas nécessairement fournisseur du modèle entraîné par son client. En revanche, une plateforme cloud qui met elle-même sur le marché un assistant, une API de modèle ou un service d’IA peut cumuler plusieurs rôles.

Cette distinction est essentielle. Elle évite de demander à un hébergeur une « conformité AI Act » générale, formulation trop imprécise pour être utile. La bonne question est plutôt : quel acteur porte quelle obligation dans la chaîne technique, du modèle jusqu’au datacenter ?

Les modèles GPAI : une première ouverture sur les données de calcul

Les obligations relatives aux modèles d’IA à usage général sont les plus proches d’un enjeu de transparence sur les ressources. L’article 53 de l’AI Act demande aux fournisseurs de ces modèles de constituer et de tenir à jour une documentation technique. L’annexe XI prévoit notamment des informations sur les méthodes d’entraînement, les données employées et les ressources de calcul mobilisées. Elle mentionne aussi la consommation énergétique connue ou estimée du modèle.

Il s’agit d’une évolution importante : l’énergie nécessaire à l’entraînement d’un modèle entre dans le champ de documentation réglementaire. Toutefois, il faut en mesurer les limites :

la documentation n’est pas conçue comme un tableau de bord environnemental public destiné à tous les clients ;
elle concerne les fournisseurs de modèles GPAI, et non chaque prestataire de stockage, de réseau ou de GPU ;
une estimation de consommation du modèle ne décrit pas automatiquement son empreinte totale, qui dépend aussi de la fabrication des serveurs, de l’électricité locale, de l’inférence, du refroidissement et du transfert des données ;
l’AI Act n’impose pas un unique indicateur comparable, tel qu’un nombre obligatoire de grammes de CO₂e par requête ou par million de tokens.

Pour un projet qui utilise un modèle via API, la transparence pertinente doit donc venir à la fois du fournisseur de modèle et du fournisseur d’infrastructure. Les deux ne sont pas toujours la même entreprise. Un modèle peut être accessible par une API opérée par son éditeur, via une place de marché cloud, ou être déployé par une organisation sur ses propres instances GPU.

Une consommation d’énergie déclarée pour l’entraînement ne permet pas, à elle seule, de comparer l’impact d’une utilisation quotidienne en production. L’inférence, la localisation des données et le taux d’utilisation des GPU restent déterminants.

Pour les organisations qui construisent des systèmes à haut risque, la documentation technique et la gestion des risques prennent également une place centrale. Cela peut créer une demande accrue de traçabilité auprès des prestataires : version du matériel, capacité de calcul, environnement d’exécution, journalisation et éléments nécessaires à l’évaluation du système. Mais là encore, une obligation de documentation sur le système d’IA ne vaut pas obligation générale, pour le cloud, de publier tous ses indicateurs environnementaux.

Pourquoi les clouds ne deviennent pas transparents par magie avec l’AI Act

Le risque de greenwashing commence souvent par un raccourci : « conforme à l’AI Act » deviendrait synonyme de « IA responsable » ou de « cloud durable ». Ce raisonnement ne tient pas. La conformité est une exigence juridique liée à un périmètre précis ; la sobriété environnementale résulte d’arbitrages techniques, opérationnels et matériels beaucoup plus larges.

L’AI Act évoque bien l’efficacité énergétique, la gestion des ressources et la durabilité environnementale dans le cadre des normes harmonisées et des codes de conduite volontaires. Ces leviers peuvent faire progresser les pratiques et les méthodes de mesure. Ils ne remplacent pas une analyse de l’infrastructure sous-jacente.

Un fournisseur peut ainsi être en mesure de répondre à ses obligations liées à un modèle tout en restant peu transparent sur :

le datacenter exact dans lequel s’exécute une charge ;
le mix électrique associé à la région cloud ;
l’efficacité énergétique annuelle du site ;
la consommation d’eau du refroidissement ;
la durée d’usage, le réemploi ou la fin de vie des serveurs et accélérateurs ;
le taux réel d’occupation des GPU mutualisés.

Cette prudence rejoint les critères présentés dans notre guide pour choisir un hébergeur écologique. Une allégation environnementale crédible s’appuie sur un périmètre identifiable, une méthode explicite, des données vérifiables et, idéalement, des résultats publiés dans la durée.

La directive EED : le texte à surveiller pour les grands datacenters

Pour obtenir des données sur l’exploitation des datacenters, le cadre européen le plus direct n’est pas l’AI Act, mais la refonte de la directive sur l’efficacité énergétique (EED). Son article 12 organise une obligation de déclaration pour les opérateurs de datacenters dont la puissance informatique installée atteint au moins 500 kW.

Le dispositif prévoit la collecte d’informations relatives à la performance et à la durabilité des sites. Un règlement délégué européen précise le schéma commun de l’Union pour l’évaluation des datacenters. Il couvre notamment des éléments relatifs à l’énergie, à l’eau, aux énergies renouvelables et à la valorisation de chaleur fatale. Les indicateurs demandés s’inscrivent dans une logique de comparaison et de suivi à l’échelle européenne.

Pour un acheteur de cloud, cela apporte une base utile, mais non suffisante. D’une part, le seuil de 500 kW exclut certains sites plus petits. D’autre part, une donnée déclarée au niveau d’un datacenter ne renseigne pas automatiquement l’impact de votre machine virtuelle, de votre cluster Kubernetes ou de vos instances NVIDIA GPU.

Il est néanmoins légitime de demander au fournisseur si les sites utilisés par l’offre sont concernés par ce reporting, et si les indicateurs communiqués peuvent être reliés à une région cloud donnée. Notre analyse sur la directive EED et les données des hébergeurs explique pourquoi cette transparence d’infrastructure complète utilement la régulation de l’IA.

Énergie : les indicateurs à demander pour une charge d’IA

Pour évaluer l’énergie d’un projet IA, il faut d’abord séparer l’entraînement, l’inférence, le stockage et les transferts de données. Une plateforme peut communiquer une empreinte carbone annuelle globale sans pouvoir attribuer une mesure à votre usage. Ce n’est pas inutile, mais ce n’est pas assez précis pour piloter une architecture sobre.

Localisation et électricité

Demandez la région cloud et, lorsque c’est possible, le pays ou le datacenter d’exécution. Cette information permet de rapprocher la charge du contexte électrique local. Attention : l’achat de garanties d’origine ou d’un contrat d’achat d’électricité renouvelable ne signifie pas que le site est alimenté physiquement, à chaque instant, par une production renouvelable.

Un fournisseur sérieux doit distinguer, si les données sont disponibles :

la consommation électrique physique de ses opérations ;
la méthode de calcul de ses émissions de scope 2 ;
la part d’électricité renouvelable revendiquée et le mécanisme mobilisé ;
la granularité géographique et temporelle des données.

Le suivi horaire est particulièrement pertinent pour les charges flexibles, comme l’entraînement non urgent ou les traitements par lots. Il est traité plus en détail dans notre article sur le bilan carbone horaire comme critère de choix.

Efficacité de l’infrastructure

Le PUE (Power Usage Effectiveness) compare l’énergie totale du datacenter à celle consommée par l’équipement informatique. Plus il est proche de 1, moins les équipements auxiliaires, notamment le refroidissement et la distribution électrique, consomment d’énergie en proportion. C’est un indicateur utile, mais il ne dit ni quelle électricité est utilisée ni si les serveurs sont bien employés.

Demandez un PUE annuel, associé à un site ou à une région, avec la période et la méthode de calcul. Méfiez-vous d’un chiffre isolé sans date, d’un « meilleur PUE observé » présenté comme une moyenne, ou d’une valeur globale qui mélange des sites très différents. Le PUE ne mesure pas davantage l’impact de fabrication des GPU. C’est pourquoi le PUE ne suffit pas à lui seul pour qualifier un hébergement de durable.

Eau et refroidissement : sortir de l’angle mort des GPU

Les charges IA intensives augmentent la densité thermique des serveurs. Selon l’architecture du datacenter, cette chaleur peut être évacuée par air, par eau, avec des boucles fermées, par refroidissement adiabatique ou grâce à des systèmes de refroidissement liquide au plus près des composants. Il n’existe donc pas un impact hydrique uniforme du cloud.

Le premier indicateur à connaître est le WUE (Water Usage Effectiveness), qui met en relation l’eau utilisée par l’infrastructure et l’énergie des équipements informatiques. Comme le PUE, il doit être interprété avec prudence. Son périmètre peut varier, et une valeur faible ne renseigne pas à elle seule sur le stress hydrique local.

Pour un projet IA, demandez :

le WUE annuel du site ou de la région, si l’opérateur le publie ;
la distinction entre prélèvement, consommation et rejet d’eau lorsque cette information existe ;
le type de refroidissement employé ;
la provenance de l’eau utilisée, par exemple eau potable, eau recyclée ou eau non potable ;
le contexte local et les mesures prévues en cas de tension sur la ressource.

Une communication qui se limite à « refroidissement naturel » ou « datacenter sans climatisation » mérite des précisions. Le free cooling peut être très efficace dans certaines conditions, mais il ne permet pas de conclure à lui seul sur l’ensemble du bilan d’un site. Consultez notre dossier sur l’usage de l’eau dans les datacenters pour approfondir ce critère.

GPU, serveurs et durée de vie : les données matérielles à exiger

Les accélérateurs constituent le cœur des charges IA modernes. Or, une comparaison basée uniquement sur le prix à l’heure d’une instance GPU peut encourager le surdimensionnement. Une GPU laissée inactive, une instance réservée sans travail ou un modèle exécuté avec une précision inutilement élevée dégrade le bilan économique et environnemental du projet.

Le cloud ne publiera pas toujours le détail de son parc pour des raisons de sécurité, de concurrence ou de gestion opérationnelle. En revanche, il est raisonnable de demander des informations actionnables :

le modèle d’accélérateur proposé et sa mémoire ;
les métriques d’utilisation disponibles dans l’interface, par exemple l’occupation GPU, la mémoire utilisée et le temps d’exécution ;
les possibilités d’arrêt automatique, d’extinction des environnements inutilisés et de planification des jobs ;
l’existence d’instances mutualisées ou fractionnées lorsque l’usage ne nécessite pas un GPU entier ;
la politique générale de réemploi, de reconditionnement, de réparation ou de recyclage des équipements ;
les données d’émissions de scope 3 lorsque le fournisseur les publie, en distinguant les émissions opérationnelles de celles liées à la chaîne matérielle.

La mutualisation doit toutefois être vérifiée. Partager une ressource peut améliorer son taux d’utilisation, mais ce bénéfice dépend de la capacité réellement consommée, des performances obtenues et de la durée totale du calcul. Une instance plus lente qui allonge fortement un entraînement n’est pas nécessairement le meilleur choix.

Dans une équipe data, des outils comme Prometheus et Grafana peuvent aider à suivre l’activité des serveurs et des pods Kubernetes. Côté GPU, les métriques exposées par NVIDIA DCGM, souvent collectées via un exporteur compatible Prometheus, permettent notamment de visualiser l’utilisation des accélérateurs. L’objectif n’est pas de produire un rapport marketing, mais d’identifier les ressources sous-employées et de dimensionner les jobs au plus juste.

Une checklist pour sélectionner un hébergeur IA plus responsable

Avant de signer un contrat cloud ou de choisir une plateforme d’inférence, transformez les promesses environnementales en questions écrites. Comparez les réponses fournisseur par fournisseur, en notant le périmètre, la date et la méthode de chaque donnée.

Rôle réglementaire : le fournisseur est-il seulement hébergeur, fournisseur de modèle GPAI, ou les deux ? Qui fournit la documentation liée au modèle ?
Localisation : dans quelle région les données, les GPU, les sauvegardes et les services managés sont-ils hébergés ?
Énergie : le fournisseur communique-t-il un PUE annuel localisé, un bilan d’émissions documenté et la méthode employée pour ses allégations d’électricité renouvelable ?
Eau : existe-t-il un WUE ou des informations sur le refroidissement et les ressources hydriques utilisées ?
Matériel : quelle est la politique de gestion de fin de vie des serveurs, et des informations de scope 3 sont-elles disponibles ?
Mesure de l’usage : pouvez-vous exporter les métriques GPU, CPU, mémoire, stockage et réseau de votre propre projet ?
Sobriété opérationnelle : la plateforme permet-elle l’extinction automatique, les limites de ressources, les quotas et la planification des tâches non urgentes ?
Preuves : les chiffres sont-ils datés, rattachés à un périmètre clair et, lorsque cela est possible, vérifiés par un tiers ?
Réversibilité : pouvez-vous récupérer vos données, modèles, images et journaux dans des formats exploitables si vous changez de fournisseur ?

La réversibilité n’est pas un détail administratif. Éviter un verrouillage technique permet de déplacer une charge vers une région, un matériel ou un fournisseur plus adapté. Le Data Act et la réversibilité du cloud constituent à ce titre un sujet complémentaire à suivre.

Réduire l’impact avant même de choisir un cloud

Le choix de l’hébergeur compte, mais une infrastructure plus efficace ne compense pas une architecture inutilement gourmande. La première source de sobriété reste l’évitement du calcul superflu. Avant de réserver plusieurs GPU, posez quelques questions simples : faut-il entraîner un modèle de zéro ? Un modèle plus petit, un fine-tuning ciblé ou une approche non générative répondraient-ils au besoin ? Les résultats doivent-ils être produits en temps réel ?

Des mesures opérationnelles donnent souvent des gains immédiats :

mettre fin automatiquement aux notebooks, machines de développement et endpoints d’inférence inactifs ;
choisir une taille d’instance adaptée aux besoins réels de mémoire et de calcul ;
traiter en lot les tâches qui n’exigent pas une réponse instantanée ;
suivre le taux d’utilisation des GPU avant d’augmenter la capacité ;
limiter les copies de jeux de données et définir des règles de rétention pour les sorties, checkpoints et journaux ;
mesurer séparément entraînement, tests, inférence et expérimentation afin de repérer les postes dominants.

Cette démarche complète les informations fournies par le cloud. Elle donne surtout à l’organisation les moyens de discuter avec son hébergeur à partir de données d’usage concrètes, plutôt que de se contenter d’un label ou d’une page institutionnelle.

Conclusion : faire de la transparence une exigence contractuelle

L’AI Act fait entrer les ressources de calcul et la consommation énergétique estimée dans la documentation de certains modèles d’IA à usage général. C’est un signal réglementaire important, mais il ne transforme pas automatiquement chaque cloud en infrastructure transparente sur l’énergie, l’eau et le matériel. La directive EED, les rapports environnementaux des opérateurs et les données techniques de votre propre usage restent indispensables.

Pour héberger une IA de façon plus responsable, recherchez des réponses localisées, datées et méthodologiquement explicites. Demandez les indicateurs avant l’achat, inscrivez les engagements clés dans vos échanges contractuels et mesurez vos workloads après leur mise en production. Cette approche vous aidera à comparer les offres au-delà des promesses, tout en construisant une infrastructure IA plus sobre et plus pilotable.