Data centers IA : pourquoi le taux d’utilisation compte

L’IA change l’échelle du problème énergétique

L’intelligence artificielle transforme rapidement les besoins d’infrastructure. Entraîner, ajuster ou servir des modèles de langage, de vision ou de recommandation nécessite souvent des accélérateurs spécialisés, notamment des GPU. Ces équipements sont puissants, coûteux à produire et énergivores lorsqu’ils fonctionnent à pleine charge. Mais leur consommation ne dépend pas uniquement de leur puissance théorique : elle dépend aussi, et surtout, de la façon dont ils sont réellement employés.

Selon le rapport Energy and AI de l’Agence internationale de l’énergie (AIE), les data centers ont consommé environ 415 TWh d’électricité en 2024. L’AIE anticipe une forte hausse de cette demande d’ici 2030, notamment sous l’effet du déploiement de l’IA. Ces chiffres concernent l’ensemble des data centers, mais l’IA constitue clairement un moteur de croissance : ses charges de calcul exigent des serveurs denses, des réseaux rapides et des systèmes de refroidissement adaptés.

Dans ce contexte, choisir un hébergement ou un cloud « vert » ne peut plus se limiter à regarder l’origine de l’électricité, un certificat d’énergie renouvelable ou le PUE d’un data center. Ces éléments restent importants, mais ils ne disent pas si les serveurs réservés à votre projet travaillent effectivement.

Le taux d’utilisation est donc un critère utile pour évaluer la sobriété réelle d’une infrastructure IA. Il permet de poser une question simple : quelle part de la capacité matérielle mobilisée produit effectivement un calcul utile pour les utilisateurs, les applications ou les équipes qui la financent ?

Pour compléter ce sujet, consultez aussi notre dossier sur les impacts de l’IA sur l’hébergement web vert.

Pourquoi un serveur IA sous-utilisé pèse sur le bilan carbone

Un GPU inactif n’est pas un GPU sans impact. Lorsqu’un serveur est allumé, il continue à alimenter de nombreux composants : processeurs, mémoire, stockage, cartes réseau, ventilateurs et alimentation électrique. Le GPU lui-même peut rester en état de veille tout en consommant de l’énergie. À cette consommation informatique s’ajoutent les besoins indirects du data center, en particulier le refroidissement et la conversion électrique.

La situation est encore plus défavorable lorsqu’une entreprise réserve une capacité importante « au cas où », puis l’emploie de manière intermittente. Un cluster peut être immobilisé par des expérimentations, des environnements de test, des files d’attente mal configurées, des dépendances logicielles ou des jeux de données insuffisamment préparés. Pendant ce temps, l’équipement reste potentiellement sous tension et ne peut pas nécessairement être utilisé par un autre client.

L’empreinte de fabrication doit aussi être répartie

L’impact environnemental d’un serveur ne se limite pas aux kilowattheures consommés pendant son exploitation. La fabrication des puces, des cartes électroniques, des serveurs, des baies et des équipements réseau mobilise des matières premières, de l’énergie et des procédés industriels complexes. Cet impact « incorporé » doit être réparti sur les usages rendus par le matériel au cours de sa durée de vie.

Un accélérateur utilisé régulièrement pour plusieurs projets permet de répartir son impact de fabrication sur davantage d’heures de calcul utiles. À l’inverse, un GPU acheté ou réservé pour de rares pics de demande peut concentrer une empreinte matérielle élevée sur un volume de travail limité. Cela ne signifie pas qu’il faut faire fonctionner un GPU en permanence : un calcul inutile n’est pas sobre. L’objectif est plutôt d’éviter de surdimensionner l’infrastructure et d’éteindre, libérer ou réaffecter les ressources lorsqu’elles ne sont plus nécessaires.

La puissance nominale ne mesure pas le travail accompli

Comparer deux offres à partir du seul nombre de GPU, du nombre de cœurs CPU ou de la mémoire disponible peut être trompeur. Une infrastructure de grande taille n’est pas intrinsèquement inefficace ; elle peut être indispensable pour un entraînement distribué ou un service à forte audience. En revanche, sa puissance nominale ne renseigne pas sur le nombre de requêtes traitées, de modèles entraînés, d’images analysées ou de tâches réellement terminées.

Une même carte graphique peut produire beaucoup de travail utile dans un environnement bien planifié, ou rester partiellement inactive faute de données, de mémoire, de capacité réseau ou d’organisation des tâches. C’est pourquoi l’évaluation environnementale doit relier les ressources mobilisées à un résultat concret.

La meilleure capacité n’est pas celle qui affiche le plus grand nombre de GPU, mais celle qui répond au besoin avec le moins de matériel, d’énergie et de temps d’immobilisation possible.

Taux d’utilisation : de quoi parle-t-on exactement ?

Le terme « taux d’utilisation » recouvre plusieurs mesures. Il ne faut pas les confondre, car elles répondent à des questions différentes. Un hébergeur peut par exemple communiquer un taux d’occupation de ses serveurs, tandis qu’une équipe data suit l’activité de ses GPU. Ces deux indicateurs sont intéressants, mais ne décrivent pas le même niveau de réalité.

Utilisation GPU : part du temps durant lequel le processeur graphique exécute des opérations. Elle peut être observée avec des outils tels que NVIDIA DCGM. Elle doit être interprétée avec prudence : une forte activité ne garantit pas que le modèle est bien optimisé ou que le calcul apporte une valeur métier.
Utilisation mémoire GPU : quantité de mémoire graphique occupée. Une mémoire remplie ne signifie pas forcément que le GPU calcule efficacement ; elle peut simplement contenir un modèle ou des données en attente.
Utilisation CPU, RAM et stockage : elle révèle d’éventuels goulots d’étranglement. Un GPU peut attendre un processeur, un chargement de données ou un accès disque trop lent.
Taux d’occupation ou de réservation : part de la capacité attribuée à des clients ou à des projets. Une ressource réservée n’est pas nécessairement active.
Taux d’achèvement des tâches : nombre de travaux effectivement réalisés par rapport aux ressources et au temps mobilisés. C’est un indicateur plus proche de l’utilité, mais il dépend du cas d’usage.

Le taux d’utilisation doit donc être lu sur une période pertinente : heure, jour, semaine ou mois. Une moyenne mensuelle peut masquer une activité concentrée sur quelques heures et de longues périodes d’inactivité. À l’inverse, une faible moyenne peut être normale pour un service d’inférence qui doit rester disponible afin de répondre à des demandes imprévisibles.

L’enjeu n’est pas d’imposer un objectif universel de 100 %. Un système exploité au maximum de sa capacité peut perdre en stabilité, augmenter les temps d’attente ou ne plus absorber les pics. Il s’agit plutôt de comprendre la marge réellement nécessaire et d’éviter les ressources durablement immobilisées sans justification technique ou opérationnelle.

Capacité réservée, capacité active et capacité mutualisée

Pour comparer les fournisseurs, il faut distinguer trois notions souvent mélangées dans les présentations commerciales : la capacité réservée, la capacité active et la capacité mutualisée.

La capacité réservée offre une garantie, mais peut créer du gaspillage

Une instance réservée, un serveur dédié ou une allocation de GPU garantit généralement à un client qu’une ressource pourra être utilisée. Cette garantie est précieuse pour les charges critiques, les traitements planifiés, les contraintes de confidentialité ou les projets qui ne peuvent pas tolérer une file d’attente.

Elle comporte cependant un risque : payer et immobiliser une capacité rarement utilisée. Dans une architecture dédiée, le fournisseur ne peut pas toujours affecter le GPU inoccupé à un autre client. La pertinence environnementale d’une réservation dépend donc de son niveau d’emploi, de la possibilité de la réduire à la demande et de la politique d’extinction ou de réaffectation appliquée par le fournisseur.

La mutualisation améliore potentiellement l’usage du matériel

Dans une infrastructure mutualisée, plusieurs clients utilisent un parc commun de serveurs. Le fournisseur peut alors répartir les charges et réduire la quantité de matériel nécessaire pour répondre à la demande globale. Cette logique est l’un des bénéfices possibles du cloud : une capacité partagée peut atteindre un meilleur niveau d’utilisation qu’une multitude de serveurs privés dimensionnés pour les pics individuels.

Mais la mutualisation n’est pas automatiquement synonyme de sobriété. Elle doit préserver l’isolation entre clients, la sécurité des données, la qualité de service et la transparence. Elle peut aussi encourager une consommation excessive si les ressources sont trop faciles à lancer et à oublier. Un environnement partagé bien gouverné, avec des quotas, une facturation lisible et des mécanismes d’arrêt automatique, est plus pertinent qu’une mutualisation opaque.

Le right-sizing consiste à dimensionner au plus juste

Le right-sizing consiste à choisir une configuration adaptée à la charge réelle : bon nombre de GPU, quantité de mémoire suffisante, type de stockage approprié et capacité réseau cohérente. C’est une démarche continue, pas une décision prise une fois pour toutes lors du lancement d’un projet.

Par exemple, une équipe qui exécute un modèle d’inférence de taille modérée peut constater, via ses métriques, qu’un GPU haut de gamme reste largement sous-employé. Elle peut alors tester une instance plus petite, un modèle quantifié, un traitement par lots ou une architecture CPU selon ses contraintes de latence. À l’inverse, une instance insuffisante peut allonger énormément la durée d’exécution : réduire le matériel sans mesurer peut donc aussi accroître la consommation totale.

La sobriété ne revient pas à choisir systématiquement l’offre la moins puissante. Elle consiste à rechercher le meilleur compromis entre performance, durée de traitement, disponibilité et ressources mobilisées.

Les indicateurs concrets à demander à un hébergeur ou fournisseur cloud

Les particuliers et les petites entreprises n’obtiendront pas toujours les données d’exploitation internes d’un grand fournisseur cloud. En revanche, une demande précise permet de distinguer un discours général sur l’IA durable d’une démarche mesurable. Un prestataire sérieux doit au minimum expliquer ce qu’il mesure, à quel périmètre et avec quelle fréquence.

Les métriques accessibles au client : le tableau de bord permet-il de suivre l’activité CPU, mémoire, GPU, stockage et réseau par instance, projet ou équipe ?
La granularité des données : les métriques sont-elles disponibles à une échelle suffisamment fine pour identifier une machine oubliée ou un GPU peu actif ?
Les heures de fonctionnement : le fournisseur distingue-t-il les heures réservées, les heures allouées, les heures actives et les heures facturées ?
Les mécanismes d’arrêt : existe-t-il une mise en veille, une extinction programmée ou une suppression automatique des ressources inutilisées ?
Les options de partage : le fournisseur propose-t-il des instances mutualisées, des ressources à la demande ou des mécanismes de planification pour éviter l’immobilisation de GPU dédiés ?
Les données énergétiques : communique-t-il des informations sur le PUE, l’électricité consommée ou les émissions associées à ses opérations, avec un périmètre clairement expliqué ?
La durée de vie du matériel : publie-t-il une stratégie sur la réparation, le réemploi, le reconditionnement ou le recyclage des équipements ?

Le PUE, ou Power Usage Effectiveness, mesure le rapport entre l’énergie totale du data center et l’énergie consommée par les équipements informatiques. C’est un indicateur utile pour apprécier les pertes liées au refroidissement et aux infrastructures de site. Il ne permet toutefois pas de savoir si les GPU d’un client réalisent un travail utile. Un très bon PUE ne compense pas des serveurs surdimensionnés ou inactifs.

De la même manière, l’annonce d’une alimentation renouvelable doit être contextualisée : provenance de l’électricité, méthode de comptabilisation, période concernée et localisation des data centers comptent. Notre article sur les PPA verts chez les hébergeurs explique pourquoi la contractualisation de l’électricité mérite une lecture attentive.

Mesurer l’utilisation dans son propre projet IA

Le fournisseur ne porte pas seul la responsabilité de l’efficacité. Le client, l’équipe de développement ou l’agence qui déploie une application IA peut agir directement sur l’utilisation de ses ressources. La première étape est de disposer d’un inventaire fiable des instances, des environnements et des propriétaires de chaque ressource.

Pour les environnements utilisant des GPU NVIDIA, NVIDIA DCGM fournit des données de supervision pouvant être intégrées à des outils de monitoring. Dans un environnement conteneurisé, des équipes utilisent aussi Prometheus pour collecter des métriques et Grafana pour les visualiser. Ces outils ne réduisent pas l’impact à eux seuls, mais ils aident à repérer les périodes d’inactivité, les saturations ou les déséquilibres entre CPU et GPU.

Pour les workloads exécutés sur Kubernetes, un ordonnanceur correctement configuré peut éviter que des ressources restent attribuées à des pods inactifs. Des limites et demandes de ressources cohérentes, des quotas par équipe et la suppression des environnements temporaires sont des pratiques simples. Les environnements de développement, de démonstration et de test méritent une attention particulière : ils sont souvent lancés rapidement, puis oubliés.

Suivre les bonnes unités de résultat

Le taux d’utilisation brut est indispensable, mais il faut le compléter par une unité fonctionnelle. Selon le projet, il peut s’agir du nombre de requêtes traitées, de documents analysés, d’images générées, de jetons produits, d’heures d’entraînement ou de modèles évalués. Cette approche permet de suivre l’évolution de la consommation par service rendu, plutôt que la seule hausse ou baisse de la puissance appelée.

Le Software Carbon Intensity (SCI), porté par la Green Software Foundation, propose un cadre pour raisonner sur l’intensité carbone d’un logiciel. Son intérêt est de relier les émissions à une unité fonctionnelle, tout en tenant compte de l’énergie, du matériel et de l’intensité carbone de l’électricité. Son application demande des données fiables et des choix méthodologiques explicites, mais cette logique est particulièrement pertinente pour les services IA.

Pour une équipe qui débute, un suivi mensuel peut déjà produire des résultats utiles :

lister les instances GPU actives et leur propriétaire ;
identifier les ressources sans activité significative depuis plusieurs jours ;
supprimer les environnements éphémères après les tests ;
vérifier si la configuration choisie correspond aux besoins observés ;
comparer le temps d’exécution et les ressources mobilisées avant et après une optimisation.

Réduire l’inactivité sans dégrader le service

Une stratégie de sobriété efficace n’est pas une simple chasse aux serveurs allumés. Elle doit respecter les contraintes de production : temps de réponse, confidentialité, disponibilité, réversibilité et budget. Plusieurs leviers permettent cependant de diminuer l’inactivité structurelle.

Planifier les entraînements : regrouper les tâches non urgentes et libérer les GPU une fois les expériences terminées limite les réservations permanentes.
Choisir le bon mode d’exécution : les lots de traitements différés ne nécessitent pas forcément une capacité dédiée disponible en continu.
Mettre en place l’auto-extinction : un environnement de notebook, de test ou de démonstration peut être arrêté après une période d’inactivité définie par l’équipe.
Réutiliser les modèles et les résultats : éviter de relancer un entraînement ou une génération lorsque des artefacts valides existent déjà réduit les calculs inutiles.
Optimiser le pipeline de données : un GPU qui attend les données ou le réseau ne valorise pas l’énergie et le matériel mobilisés.
Tester à petite échelle : avant de déployer un grand nombre de GPU, mesurer les performances sur une configuration représentative permet de limiter le surdimensionnement.

La quantification, la distillation ou le choix d’un modèle plus compact peuvent également réduire les besoins de calcul dans certains cas. Ces techniques doivent toutefois être validées selon les exigences de qualité, de sécurité et de précision propres à chaque application. Un modèle plus léger n’est pertinent que s’il remplit réellement la fonction attendue.

Enfin, il est essentiel de surveiller l’effet rebond. Rendre une tâche moins coûteuse peut conduire à en lancer davantage. Les gains d’efficacité doivent donc s’accompagner de règles de gouvernance : objectifs de service, budgets de calcul, validation des nouveaux usages et suivi dans le temps.

Comment choisir une infrastructure IA plus sobre en 2026

Pour choisir une infrastructure IA plus responsable, commencez par votre besoin réel. Avez-vous besoin d’un GPU dédié en permanence ? Votre charge est-elle prévisible ? Le traitement peut-il attendre ? Les données imposent-elles une localisation précise ou un environnement isolé ? Ces réponses déterminent le niveau de mutualisation acceptable et la configuration technique pertinente.

Ensuite, privilégiez un fournisseur qui ne se contente pas d’afficher une promesse environnementale générale. Recherchez des données vérifiables sur ses infrastructures, son efficacité énergétique, sa politique matérielle et les outils qu’il met à disposition pour piloter les ressources. Pour un projet IA, la capacité à visualiser et à arrêter les instances inutilisées est souvent plus utile qu’un argument marketing sur la puissance disponible.

Une grille de décision pratique peut inclure les points suivants :

des métriques d’usage accessibles pour les GPU, CPU, la mémoire et le stockage ;
des options de dimensionnement flexibles plutôt qu’un engagement systématique sur une grande capacité fixe ;
des mécanismes de mutualisation compatibles avec vos exigences de sécurité ;
la possibilité de programmer l’arrêt et le redémarrage des environnements ;
une documentation claire sur les données environnementales publiées ;
une localisation des données et des serveurs cohérente avec vos contraintes ;
un accompagnement technique permettant d’optimiser les workloads plutôt que de simplement augmenter les ressources.

Le sujet ne concerne pas uniquement les grandes plateformes de cloud. Une PME qui utilise une API d’IA, une agence qui héberge un outil de génération, ou un éditeur SaaS qui déploie un modèle open source peut aussi surveiller ses appels, ses environnements et ses ressources. Chaque décision de dimensionnement, d’extinction ou de mutualisation contribue à réduire l’écart entre capacité achetée et capacité utile.

Conclusion : faire du taux d’utilisation un critère de choix

L’augmentation des usages de l’IA rend la sobriété informatique plus concrète que jamais. Les GPU, les serveurs et les data centers ne doivent pas être évalués seulement selon leur puissance ou leur disponibilité, mais aussi selon leur emploi effectif. Un taux d’utilisation pertinent, associé à la mutualisation et au right-sizing, aide à réduire l’énergie consommée et à mieux répartir l’impact de fabrication du matériel.

Avant de réserver une nouvelle capacité IA, examinez les métriques de vos ressources actuelles et interrogez votre fournisseur sur ce qu’il mesure réellement. Pour aller plus loin dans votre comparaison, découvrez notre guide pour choisir un hébergeur écologique et privilégiez les acteurs capables de documenter leurs pratiques au-delà des seules promesses.