IA responsable : héberger localement suffit-il vraiment à réduire son empreinte environnementale ?

« Héberger localement » peut désigner des réalités très différentes

Avant de comparer une IA « locale » à une IA « dans le nuage », il faut préciser ce que l’on compare.

Une première organisation peut installer ses propres serveurs dans son bâtiment. Elle maîtrise directement les équipements, leur accès physique, leur renouvellement et une partie des conditions d'exploitation.

Une deuxième peut utiliser un centre de données exploité par un prestataire situé dans le même pays. Les données et les traitements restent géographiquement proches, mais l’infrastructure est mutualisée avec d’autres clients.

Une troisième peut choisir un service en nuage souverain ou régional afin de répondre à certaines exigences de localisation, de juridiction ou de maîtrise des données.

Une quatrième peut recourir à l’infrastructure fortement mutualisée d’un grand fournisseur international.

Ces quatre situations ne présentent ni les mêmes risques, ni les mêmes performances, ni nécessairement le même impact environnemental. La proximité géographique ne suffit donc pas à établir un classement.

L’impact commence par l’électricité, mais ne s’arrête pas au compteur

Le premier facteur à examiner est le mix électrique, c’est-à-dire l’ensemble des sources utilisées pour produire l’électricité consommée dans une région donnée.

Un même calcul exécuté dans deux centres de données peut ainsi être associé à des impacts climatiques différents selon l’électricité mobilisée. La localisation a donc une importance réelle, mais pour une raison plus précise que la simple distance : les caractéristiques du système énergétique comptent.

Il faut ensuite regarder l’efficacité du centre de données.

Un indicateur fréquemment utilisé est le PUE, pour Power Usage Effectiveness, ou efficacité de l’utilisation de l’énergie. Il met en rapport l’énergie totale consommée par le centre de données et celle effectivement utilisée par ses équipements informatiques. Il permet notamment de prendre en compte l'énergie nécessaire aux infrastructures auxiliaires, comme le refroidissement et la distribution électrique.

Mais le PUE ne raconte pas toute l’histoire.

Un centre de données très performant énergétiquement peut utiliser un système de refroidissement consommant de l’eau. Il faut donc éviter de réduire la responsabilité environnementale aux seules émissions de gaz à effet de serre. L’eau, les matières premières, les déchets électroniques, la pollution, le transport et l’utilisation des ressources font également partie du bilan.

La recommandation ITU-T L.1801 publiée en 2026 sur l’évaluation environnementale des systèmes d’IA adopte précisément cette logique de cycle de vie. Elle couvre notamment l’énergie, le matériel, le stockage et les transferts de données, le refroidissement, l’utilisation de l’eau et la fin de vie des équipements.

Un serveur local inutilisé n’est pas nécessairement une solution sobre

Un autre facteur est moins visible : le taux d’occupation des équipements.

Une organisation peut acheter plusieurs serveurs puissants afin de disposer de capacités d’IA en interne. Si ces équipements restent largement sous-utilisés pendant la majorité de leur durée de vie, leur fabrication et leur exploitation doivent néanmoins être prises en compte.

Une infrastructure mutualisée fonctionne selon une logique différente : les mêmes ressources physiques peuvent servir successivement ou simultanément à plusieurs charges de travail. Cette mutualisation peut améliorer l’utilisation des équipements.

Cela ne signifie pas qu’un grand centre de données est automatiquement préférable. Cela signifie simplement qu’« interne » et « écologique » ne sont pas synonymes.

Il faut également considérer le cycle de renouvellement. Les processeurs spécialisés, serveurs, systèmes de stockage et équipements réseau nécessitent des matières et de l’énergie pour leur fabrication. Leur remplacement fréquent déplace une partie de l’impact environnemental hors du centre de données lui-même.

L’Union internationale des télécommunications souligne d’ailleurs une difficulté importante : les mesures actuelles de l’impact de l’IA reposent encore souvent sur des estimations et documentent imparfaitement certaines phases du cycle de vie, notamment l’inférence, les comportements d’usage, la chaîne d’approvisionnement et l’eau.

Il faut donc distinguer les mesures disponibles des estimations et reconnaître les incertitudes lorsqu’elles existent.

Le choix du modèle peut compter autant que le choix du centre de données

Deux organisations hébergées dans le même bâtiment peuvent avoir des empreintes très différentes.

Pourquoi ? Parce que l’infrastructure n’est qu’une partie de l’équation.

Il faut distinguer plusieurs étapes : l’entraînement, pendant lequel un modèle apprend à partir de données ; l’adaptation, lorsqu’un modèle existant est ajusté pour un usage particulier ; et l’inférence, qui correspond à son utilisation pour produire une réponse, une classification ou une analyse.

L’impact dépend alors de la taille et de l’architecture du modèle, du matériel utilisé, mais aussi du nombre de requêtes et de leur complexité.

Un système interrogé quelques fois par jour ne présente pas le même profil qu’un service sollicité automatiquement des milliers de fois. Le stockage des données et leurs transferts entre sites ou services doivent également être considérés.

Cela conduit à un principe utile : la proportionnalité informatique.

Si une organisation veut, par exemple, classer des documents selon quelques catégories définies, elle devrait se demander si elle a réellement besoin d’un très grand modèle généraliste. Un modèle plus petit ou spécialisé peut parfois atteindre la qualité nécessaire avec moins de ressources.

Des travaux publiés en 2025 par l’UNESCO et University College London montrent précisément que la conception des modèles, leur dimensionnement et les pratiques d’utilisation peuvent modifier fortement leur consommation énergétique. Ces résultats ne signifient pas qu’un petit modèle sera toujours préférable, mais ils confirment l’intérêt de dimensionner la solution en fonction du besoin réel.

Local contre mutualisé : il n’existe pas de vainqueur automatique

Imaginons une infrastructure installée dans les locaux d’une organisation.

Elle peut présenter des avantages importants : maîtrise physique des équipements, contrôle accru des flux de données, fonctionnement possible sans dépendance permanente à un service externe et architecture adaptée à certaines exigences de confidentialité, de disponibilité ou de continuité.

Ces bénéfices peuvent parfaitement justifier une infrastructure locale.

Mais son bilan environnemental dépendra de son utilisation effective, de l’électricité consommée, du refroidissement, de la durée de vie du matériel et de son dimensionnement.

À l’inverse, une infrastructure mutualisée peut bénéficier d’une meilleure occupation des serveurs, d’équipements optimisés et d'une exploitation spécialisée. Elle peut cependant créer d’autres dépendances : fournisseur, réseau, localisation des traitements, conditions contractuelles ou possibilités de réversibilité.

Une infrastructure locale sous-occupée, alimentée par une électricité à fort impact climatique et dont les équipements sont fréquemment renouvelés peut donc présenter un bilan moins favorable qu’une infrastructure mutualisée correctement dimensionnée et efficacement exploitée.

L’inverse peut également être vrai selon le contexte.

La conclusion n’est pas de choisir systématiquement le nuage. Elle est de comparer les architectures plutôt que leurs étiquettes.

L’effet rebond : quand l’efficacité augmente… et l’usage aussi

Un dernier phénomène mérite l’attention : l’effet rebond.

Une amélioration technique peut réduire les ressources nécessaires pour une opération individuelle. Mais si cette amélioration rend l’usage moins coûteux ou plus facile, l’organisation peut multiplier les opérations au point d’annuler une partie du bénéfice obtenu.

Une IA plus efficace utilisée dix fois plus souvent n’entraîne donc pas nécessairement une baisse de l’impact total.

Cette question dépasse la technique. Faut-il générer automatiquement un résumé de chaque document ? Interroger un modèle à chaque étape d’un processus ? Conserver toutes les données produites ? Réexécuter une analyse lorsque son résultat n’a aucune conséquence opérationnelle ?

La sobriété commence aussi par une question simple : ce calcul est-il utile ?

Le lieu d’hébergement est une décision de gouvernance

Choisir une architecture d’IA ne devrait donc pas relever uniquement du service informatique.

La décision met simultanément en balance plusieurs dimensions : impact environnemental, confidentialité, sécurité, souveraineté des données, conformité, continuité d’activité, performances, coûts et dépendance envers les fournisseurs.

Ces objectifs peuvent entrer en tension.

Une architecture très mutualisée peut être énergétiquement intéressante mais incompatible avec certaines exigences de maîtrise des informations. Une infrastructure interne peut améliorer le contrôle des données mais nécessiter des équipements surdimensionnés pour quelques périodes de pointe.

La gouvernance consiste précisément à rendre ces arbitrages explicites.

L’organisation doit pouvoir expliquer pourquoi elle a choisi cette architecture, sur quelles informations elle s’est fondée, quelles alternatives elle a examinées et quels risques résiduels elle accepte.

Pour les données sensibles, notamment les informations de sécurité, plans, incidents, images ou vulnérabilités techniques, l’impact environnemental ne doit donc jamais être évalué isolément. La confidentialité, les accès, la finalité du traitement, la conservation et la maîtrise de l’environnement informatique restent déterminants.

Ce que les références ISO apportent à la réflexion

Trois publications ISO/IEC permettent de structurer cette démarche, avec des portées différentes.

ISO/IEC 42001:2023 — Technologies de l’information — Intelligence artificielle — Système de management est une norme internationale consacrée au système de management de l’intelligence artificielle. Elle spécifie des exigences relatives à l’établissement, à la mise en œuvre, au maintien et à l’amélioration continue d’un tel système. Elle fournit ainsi un cadre pour inscrire les objectifs, risques et opportunités liés à l’IA dans une démarche de gouvernance structurée.

ISO/IEC 42005:2025 — Évaluation de l’impact des systèmes d’IA fournit des orientations pour conduire des évaluations d’impact. Sa portée n’est pas exclusivement environnementale. L’ISO indique qu’elle vise plus largement à comprendre comment un système d’IA et ses usages prévisibles peuvent affecter les individus, les groupes et la société, et à identifier, évaluer et documenter ces impacts au cours du cycle de vie. Les préoccupations environnementales peuvent donc être intégrées dans cette analyse sans réduire l’évaluation à cette seule dimension.

Enfin, ISO/IEC TR 20226:2025 — Technologies de l’information — Intelligence artificielle — Aspects de durabilité environnementale des systèmes d’IA, publié en juillet 2025, traite directement du sujet environnemental. Il examine notamment la charge de travail, l’utilisation des ressources et des équipements, l’impact carbone, la pollution, les déchets, le transport et la localisation au cours du cycle de vie des systèmes d’IA.

Un point est important : ISO/IEC TR 20226 est un rapport technique. Il ne faut donc pas le présenter comme une norme de certification ou comme une liste d’exigences obligatoires. Il constitue plutôt une ressource technique pour mieux comprendre et examiner les dimensions environnementales d’un système d’IA.

Les questions à examiner avant de décider où héberger une IA

Avant de retenir une architecture, une organisation peut documenter au minimum les points suivants :

• Quel besoin précis le système d’IA doit-il satisfaire, et quelle qualité minimale est réellement nécessaire ?
• Un modèle plus petit ou spécialisé pourrait-il fournir un résultat suffisant ?
• Devons-nous entraîner un modèle, l’adapter ou simplement utiliser un modèle existant ?
• Quelle sera la fréquence réelle des requêtes et comment pourrait-elle évoluer ?
• Quel est le mix électrique associé aux différentes solutions envisagées ?
• Quelle est l’efficacité énergétique du centre de données et quel PUE est mesuré ?
• Quel système de refroidissement est utilisé et quelles informations sont disponibles sur sa consommation d’eau ?
• Quel sera le taux d’utilisation réel des équipements dédiés ?
• Les ressources peuvent-elles être mutualisées sans compromettre les exigences de sécurité ou de confidentialité ?
• Quelle est la durée de vie prévue du matériel et comment sa fin de vie est-elle gérée ?
• Quels volumes de données devront être stockés, conservés et transférés ?
• Quelles données peuvent quitter l’organisation et lesquelles doivent rester dans un environnement maîtrisé ?
• Quelles exigences de disponibilité et de continuité d’activité doivent être respectées ?
• Quelle dépendance envers le fournisseur l’architecture crée-t-elle, et quelles possibilités de réversibilité existent ?
• Comment l’impact environnemental sera-t-il mesuré dans le temps, plutôt que supposé au moment du projet ?
• Existe-t-il un risque d’effet rebond si l’IA devient plus rapide, moins coûteuse ou plus facile à utiliser ?

Ces questions permettent de passer d’une affirmation — « notre IA est locale, donc responsable » — à une décision documentée.

Conclusion : choisir une architecture, pas une étiquette

Héberger une IA localement peut constituer un choix parfaitement rationnel pour des raisons de confidentialité, de souveraineté, de sécurité, de disponibilité ou de continuité. Mais la proximité géographique ne constitue pas, à elle seule, une preuve de sobriété environnementale.

Une décision responsable examine le système dans son ensemble : infrastructure, énergie, eau, matériel, modèle, données, usages et cycle de vie.

Elle applique également un principe simple de proportionnalité : ne pas mobiliser davantage de puissance, de données ou d’infrastructure que ce qui est nécessaire pour atteindre le résultat attendu.

La bonne question n’est donc pas simplement « Où notre IA est-elle hébergée ? », mais « Quelle architecture répond à notre besoin avec le niveau d’impact, de risque et de dépendance que nous acceptons ? »

Pour une organisation qui envisage une infrastructure d’IA locale, souveraine ou externalisée, une démarche utile consiste à documenter ces critères avant le choix technique, puis à les réexaminer lorsque les usages évoluent. C’est cette traçabilité des arbitrages — davantage que l’étiquette « local » ou « nuage » — qui permet de construire une gouvernance de l’IA réellement responsable.

Sources

• ISO — ISO/IEC 42001:2023, Technologies de l’information — Intelligence artificielle — Système de management.
• ISO — ISO/IEC 42005:2025, Information technology — Artificial intelligence (AI) — AI system impact assessment.
• ISO — ISO/IEC TR 20226:2025, Information technology — Artificial intelligence — Environmental sustainability aspects of AI systems.
• UIT — Recommendation ITU-T L.1801 (2026), Guidelines for assessing the environmental impact of artificial intelligence systems.
• UNESCO / University College London — travaux 2025 sur l’efficacité énergétique des grands modèles de langage.
• The Green Grid — définition du Power Usage Effectiveness (PUE).