Sur une architecture applicative, un appel à une API d'IA générative ressemble à n'importe quel autre appel réseau : on l'ajoute, on le teste, on l'oublie. Sauf que derrière cette ligne de code se cache une consommation d'électricité et d'eau bien réelle, à une échelle qui commence à peser sur des infrastructures nationales entières. Pour des équipes qui multiplient les intégrations IA dans leurs produits, c'est un paramètre qui mérite d'entrer dans les choix d'architecture au même titre que la latence ou le coût cloud.
Une consommation qui change d'échelle
Selon la
Statistical Review of World Energy 2026 de l'Energy Institute, la demande électrique mondiale des data centers a atteint 787,8 TWh en 2025, en hausse de près de 20 % sur un an, un rythme directement porté par l'essor de l'IA générative. Les États-Unis concentrent près de 40 % de cette demande, au point que les data centers y pèsent déjà plus de 6 % de l'électricité nationale. En Irlande, ils absorbaient 17 % de l'électricité nationale en 2022, contre moins de 5 % en 2015.
En France, l'
ADEME recensait en 2024 environ 350 data centers actifs, pour une consommation annuelle proche de 10 térawattheures, soit l'équivalent de la consommation d'une métropole comme Lyon. Ses projections publiées début 2026 évoquent une consommation numérique française potentiellement multipliée par près de 4 d'ici 2035 si les tendances actuelles se poursuivent.
L'eau, souvent absente des choix d'architecture
Les serveurs de calcul intensif génèrent une chaleur considérable, refroidie dans de nombreux cas par de l'eau. Un rapport de l'
Agence internationale de l'énergie évalue la consommation mondiale d'eau des data centers à environ 600 milliards de litres en 2023. Un rapport de l'
institut des Nations unies pour l'eau, l'environnement et la santé estime que cette consommation, eau et électricité confondues, devrait doubler d'ici 2030, portée par la demande liée à l'IA. Une partie non négligeable de ces infrastructures se trouve dans des zones déjà sous tension hydrique, ce qui explique la controverse autour de plusieurs projets d'implantation actuellement débattus en France.
Des bonnes pratiques qui commencent à se généraliser
Sur le terrain, on voit émerger des réflexes qui n'existaient pas il y a deux ans : mesurer le nombre d'appels IA par fonctionnalité avant de la déployer à grande échelle, comparer le coût réel d'un modèle propriétaire massif face à un modèle open source plus léger auto-hébergé, ou encore fixer des budgets de tokens par usage pour éviter qu'une fonctionnalité mal maîtrisée ne fasse exploser la facture sans qu'on s'en aperçoive avant la fin du mois. Ce ne sont pas des optimisations marginales : sur certains projets, ce type d'arbitrage a permis de diviser par plusieurs le volume d'appels IA sans dégrader l'expérience utilisateur, simplement en évitant les appels redondants ou superflus.
Ce que ça implique dans nos choix techniques
Chaque appel API vers un modèle d'IA générative, chaque batch d'entraînement ou de fine-tuning, chaque requête envoyée « juste pour tester » a un coût énergétique qui se traduit directement dans la facture cloud et dans l'empreinte carbone du produit livré. Sur les missions où l'on conseille nos clients, plusieurs leviers reviennent systématiquement : choisir un modèle plus léger quand la tâche ne justifie pas un modèle massif, mettre en cache les résultats plutôt que de relancer un appel identique, et limiter les appels IA à ce qui apporte une vraie valeur au produit plutôt que de les généraliser par facilité. Ce sont des décisions d'architecture, pas de la communication RSE.
Ce qu'il faut en retenir
L'intelligence artificielle n'est pas un service immatériel qui existerait sans coût physique. Pour une équipe de développement qui multiplie les intégrations IA, la sobriété numérique devient un critère d'architecture à part entière, au même titre que la performance ou le coût d'infrastructure, pas un sujet réservé aux équipes RSE.
