Comment réduire l'empreinte de l'IA : dix leviers par ordre d'impact_

Le classement qui suit est ordonné par gain mesuré, et il est l'inverse de celui que les équipes appliquent spontanément. Elles s'attaquent d'abord au prompt, qui arrive dixième et rapporte quelques pourcents. Le choix de modèle, qui pèse bien plus que tout le reste, vient en dernier quand il vient.

Un client qui travaille ses prompts sur le modèle le plus lourd, dans la région la plus carbonée, s'occupe du levier le plus faible pendant que deux leviers à facteur 10 restent intacts.

Le tableau, avec qui contrôle quoi

La dernière colonne décide de ce sur quoi on peut agir dans une mission donnée. Le chiffrage de chaque levier vient du chapitre sur la formule.

Levier 1 : ne pas utiliser de LLM

Le calcul le plus sobre est celui qui n'a pas lieu, et une bonne part des usages déployés ont un substitut déterministe moins cher, plus fiable et auditable.

Un repère chiffré pour situer les marches, mesuré par Luccioni, Jernite et Strubell (Power Hungry Processing, FAccT 2024) sur huit accélérateurs A100 sans regroupement de requêtes, en kWh pour mille inférences : classifier un texte 0,002, question-réponse extractive 0,003, générer du texte 0,047, générer une image 2,907. Générer plutôt que classifier coûte environ 25 fois plus.

La première marche est une question, pas une technique : le besoin est-il vraiment de créer une fonctionnalité avec de l'IA, ou autre chose, ou rien du tout. Le premier livrable d'un cadrage sobriété est la liste des usages qui n'avaient pas besoin d'un modèle frontière.

Levier 2 : ne pas surdimensionner le modèle

L'écart entre modèles commerciaux dépasse 65 entre le plus sobre et le plus gourmand, sur les 30 modèles de Jegham et al., How Hungry is AI? (v6, novembre 2025). Ces valeurs sont des estimations, pas des mesures : latence d'API plus attribution matérielle inférée. À citer avec cette limite.

Sur la base de sessions agentiques de claude-carbon (janvier à août 2026, 17 402 millions de tokens), deux modèles de la gamme haute concentrent 99 % du carbone, quand un modèle intermédiaire pèse 9 kg sur 1 052.

Les fournisseurs le font pour eux-mêmes. Chez Google, la stratégie consiste à rediriger systématiquement les requêtes grand public vers des modèles plus petits dès qu'une nouvelle génération égale la performance de la précédente. Pour les intégrations produit, ce ne sont jamais les modèles généralistes qui tournent mais des versions spécialisées.

Trois limites à énoncer, dont deux qui gênent. Le verrouillage économique : les investissements dans des data centers dimensionnés pour les gros modèles incitent à les rentabiliser. Le passif d'entraînement : beaucoup de petits modèles sont distillés depuis de gros modèles, ce qui réduit leur intérêt en amont. Et un risque de superposition : si les petits modèles s'ajoutent aux gros au lieu de les remplacer, le gain s'évapore. Exigez la preuve du remplacement.

Levier 3 : couper le raisonnement inutile

Le mode raisonnement coûte +92 % d'énergie en moyenne, et jusqu'à +849 % sur une tâche de génération de code, pour un gain de performance inégal selon les tâches. Sur les tâches où il n'apporte rien, c'est un surcoût pur.

Et même là où il apporte, la moitié est superflue : une méthode publiée ramène le volume de tokens de 2 408 à 1 331 sur un jeu de mathématiques, soit −44,8 %, pour une justesse de 92,8 % contre 93,0 %.

C'est un paramètre d'API, pas un chantier. Mesurez chez le client avant de recommander un niveau : le même jeu de tâches aux différents réglages, en lisant le compteur de tokens de sortie. Une après-midi, et vous avez le seul chiffre qui compte, celui de ses tâches.

Levier 4 : choisir la région

Énergie, modèle et code identiques. Seul le mix électrique change.

Deux grandeurs différentes circulent sous le même levier, et les confondre décrédibilise l'argument.

Le rapport d'intensité entre réseaux vaut 14 chez Ember (production, ACV, 2025) et 21 chez Electricity Maps (consommation tracée, ACV, 2025) entre la France et la Pologne. C'est un facteur par kilowattheure, et il résiste au choix de base de données, ce qui est rare.

Le rapport d'inventaire annuel entre deux sites vaut 126 : Meta publie ses émissions scope 2 location-based par data center pour 2024, et l'écart entre Luleå en Suède (5 298 tCO2e) et Altoona dans l'Iowa (666 434 tCO2e) atteint ce facteur, à matériel et pratiques identiques. Ce chiffre-là agrège l'intensité du réseau et le volume d'électricité consommé sur chaque site. Il illustre le levier, il ne le mesure pas.

Trois limites, rarement dites.

Ce levier a un plafond d'échelle. Lin et al. (2023) relèvent que les data centers hyperscale dépassent 15 % de la charge de certains réseaux régionaux ; à cette taille, déplacer la charge vers l'électricité décarbonée perturbe le réseau qu'on cherche à ménager. Le levier marche pour un acteur isolé, pas pour tous en même temps.

Sur un réseau déjà propre, ce levier rapporte beaucoup moins. Le composite carbone passe d'un facteur 4,1 sur le total, pas 20, et à intensité nulle le matériel reste.

Et sur une API propriétaire, vous ne choisissez pas la région. Le levier est réel pour un auto-hébergement ou un cloud avec choix de région, indisponible pour la majorité des usages. Le dire évite de vendre un levier inactivable.

Levier 5 : réduire le contexte

Le coût du contexte est superlinéaire, et les fournisseurs le facturent avec un multiplicateur de 2 sur l'entrée au-delà de leur palier. Router chaque question vers une recherche ciblée plutôt que vers le contexte plein réduit le volume de tokens de 61,6 % sur Gemini 1.5 Pro, dans Li et al. (Google DeepMind, EMNLP 2024), sur neuf jeux de données.

Le gain est en tokens, pas en joules, et le pipeline de recherche n'est pas gratuit. Et sur l'agentique, le plafond est bas : la part réellement compressible pèse 28,8 % de l'empreinte, donc un compresseur parfait ne descend pas sous 71 % du total.

Levier 6 : cache de prompt

Gain sans aucune perte de qualité, ce qui le rend particulier : le résultat est identique, c'est le calcul qui disparaît. Les annonces vont jusqu'à −90 % de coût sur les tokens concernés, et la mesure de Lumer et al. (Don't Break the Cache, arXiv:2601.06007, janvier 2026) sur plus de 500 sessions d'agent du banc DeepResearch Bench donne −79,6 % sur la facture complète de GPT-5.2.

Le piège de périmètre est ici. Le cache supprime le préremplissage, c'est-à-dire la partie la moins chère par token, environ 35 fois moins qu'un token de sortie à lot unitaire. Une remise de 90 % sur le prix des tokens d'entrée n'est pas 90 % d'énergie économisée.

Personne n'a mesuré l'énergie d'un succès de cache contre un échec. Position tenable : le cache réduit le calcul réellement effectué sans dégrader la sortie, son ampleur énergétique est inconnue et inférieure à la remise commerciale.

Le cache est un préfixe : tout ce qui modifie le début du contexte en cours de session l'invalide pour la suite, donc ne rien ajouter en route. Le compteur de durée démarre au début de la requête, pas à la fin de la réponse. Et les modèles économiques diffèrent, l'un facturant l'écriture, l'autre le stockage horaire.

Le décodage spéculatif, même famille, même piège

Un petit modèle « brouillon » propose plusieurs tokens d'avance, le gros modèle les vérifie en une seule passe et garde le plus long début compatible avec ce qu'il aurait produit lui-même.

Même propriété que le cache : à température nulle, la sortie est strictement identique. Ce n'est pas une approximation, c'est une réorganisation du calcul. Les accélérations publiées vont de 2 à 3,6 fois, toutes mesurées en latence : 2 à 3 fois chez Leviathan, Kalman et Matias (arXiv:2211.17192, ICML 2023) sur T5-XXL à lot unitaire, jusqu'à 3,6 fois pour Medusa (arXiv:2401.10774).

Le piège est plus vicieux que celui du cache, parce qu'il peut inverser le gain. Les deux seules mesures énergétiques publiées donnent −12 % à −27 % avec un brouillon bien apparié (Nik, Riegler et Halvorsen, SimulaMet, arXiv:2502.11723, version revue Scientific Reports 2026 ; Qwen2.5-7B sur A100, brouillon n-gram, décodage glouton), et +30 % de consommation malgré une accélération de 1,19 fois quand le brouillon est mal apparié (Dutta et al., arXiv:2602.09113, Findings of EACL 2026 ; Vicuna-7B sur A5000, mesure CodeCarbon). Les deux tournent à lot unitaire, le régime le plus favorable.

Vitesse et énergie ne vont donc pas forcément dans le même sens. Comme le regroupement, ce levier appartient au fournisseur.

Levier 7 : réduire les tokens de sortie

Un token de sortie coûte environ 35 fois un token d'entrée, mesuré à lot unitaire. Sur une session agentique, la sortie représente 0,73 % du volume et 48,5 % du carbone.

Trois façons d'agir : contraindre la longueur de réponse et couper le raisonnement, mais aussi choisir un modèle qui répond court. Ce dernier point est mal connu : à tâche identique, les modèles produisent des réponses de longueurs différentes, et cette verbosité n'apparaît dans aucune grille de comparaison.

Un piège à connaître. Optimiser les joules par token incite à générer plus, puisque les coûts fixes s'amortissent : Vellaisamy et al. (Carnegie Mellon) mesurent sur Qwen3-8B et MATH-500, sur un H200, 7,46 J par token à 10 tokens de sortie contre 0,72 J à 512, alors que l'énergie de la requête est multipliée par 5. Optimisez les joules par tâche résolue.

Levier 8 : regroupement et mutualisation

Le décodage est limité par la mémoire, donc traiter plusieurs requêtes dans la même passe amortit la lecture des poids. Deux grandeurs distinctes, qu'il faut donner séparément.

Le gain va de 17 à 25 entre un lot de 1 et un lot de 32, selon l'architecture d'attention (Ma et al., The Illusion of Power Capping in LLM Decode, mai 2026 ; un H200, modèles d'environ 4 milliards de paramètres, phase de décodage isolée).

L'écart total observable entre une mesure sans regroupement et une mesure de production atteint environ 35 sur des modèles de même classe. Celui-là compare deux protocoles complets, pas deux tailles de lot : 1,72 Wh par requête sur Llama-3-70B chez AI Energy Score contre 0,0486 Wh sur Llama 3.3 70B chez ML.Energy v3.0. Les poids ne sont pas exactement les mêmes, l'ordre de grandeur tient.

D'où la conclusion contre-intuitive qu'il faut oser dire : auto-héberger un modèle à faible volume est énergétiquement pire qu'appeler une API mutualisée. Les chiffres : en génération à lot unitaire le GPU tire 137 à 300 W sur 700, l'énergie par token est 17 à 25 fois celle du lot de 32, et sur BLOOM, mesuré 18 jours sur 16 A100 sans regroupement, environ 75 % de l'énergie sert simplement à maintenir le modèle en mémoire (Luccioni, Viguier et Ligozat, JMLR 2023).

Deux nuances, sinon vous vendez du cloud. D'abord, distinguez cet argument physique de l'argument marketing des hyperscalers, qui comparent leur flotte à une installation délibérément inefficace. Et à volume élevé et charge régulière, l'auto-hébergement redevient défendable, avec des leviers que l'API interdit. Le seuil se calcule.

Levier 9 : quantification et distillation

Réduire la précision numérique fait gagner 39 % en moyenne selon la mesure du PEReN pour l'Arcep (mai 2026, 22 modèles ouverts sur le supercalculateur Jean Zay, GPU seul). Et la distillation de 83 à 90 % d'énergie d'inférence pour 13 à 15 points de ROUGE-L en moins, sur CodeT5+ et une RTX 4090 (arXiv:2608.17515).

Le résultat qui empêche de le recommander à l'aveugle : à petit lot, entre 8 et 16 requêtes, la précision réduite consomme plus que la précision standard dans 7 cas mesurés sur 7, avec une médiane à +30 % (ML.Energy v3.0, observation 7, H100 et B200). Le gain n'apparaît qu'à gros lot. La basse précision ne rapporte que dans les régimes limités par le calcul ; en régime limité par la mémoire, elle ne rapporte rien.

Sur la qualité, ne reprenez pas les « dégradation négligeable » des papiers de méthode. La source la plus honnête est celle de Meta, qui écrit que les benchmarks standards ne reflètent pas correctement les effets de la quantification, et que sans garde-fous le modèle produit occasionnellement des réponses corrompues alors que les scores restent bons.

Levier 10 : réduire les reprises

Une réponse ratée est de l'énergie dépensée pour rien, plus une seconde requête. Sur une conversation, la reprise coûte davantage que la requête initiale, puisque tout l'historique est renvoyé.

L'ingénierie de prompt, c'est aussi de l'énergie économisée, au sens propre : un prompt qui obtient le bon résultat du premier coup supprime des requêtes entières. Le rapport Arcep de mai 2026 reprend un travail de green prompting qui mesure 32 à 48 % d'énergie d'inférence en moins à qualité égale ou meilleure. Le rapport ne nomme pas ce travail, donc le chiffre voyage avec un seul relais.

Les gestes qui marchent. Cadrez une fois plutôt que dix allers-retours : un prompt plus long mais précis coûte moins cher qu'un prompt court qui force l'itération, puisque l'entrée est 35 fois moins chère que la sortie à lot unitaire. Écrivez chaque prompt comme si vous n'aviez qu'une chance, et envoyez du texte plutôt qu'un document scanné. Dernier point, ne remplissez pas la fenêtre à ras bord : la qualité se dégrade bien avant la limite technique, donc les reprises augmentent. DONNÉE MANQUANTE sur le seuil : aucune mesure publiée ne relie taux de remplissage et taux d'erreur. Il faudrait faire tourner une même évaluation à plusieurs taux de remplissage, à modèle et tâche constants.

La limite qu'il faut poser, sinon ce levier devient une manipulation : sa valeur réelle est pédagogique, il rend le sujet tangible pour un utilisateur qui ne choisit ni son modèle ni sa région. Son risque est de déplacer la responsabilité sur l'utilisateur final pendant que les décisions à facteur 10 se prennent ailleurs. Le mettre en dixième position n'est pas un hasard, et il faut le dire à voix haute en le présentant.

Le faux levier qu'on vous proposera

Baisser la température pour consommer moins. On vous le proposera, c'est faux, et le savoir évite de perdre une réunion.

La température est une division appliquée après tout le calcul, sur un vecteur de la taille du vocabulaire. Elle n'ajoute ni couche, ni passe, ni lecture de poids. Structurellement, elle ne peut pas peser.

La mesure confirme : Nik, Riegler et Halvorsen (SimulaMet, arXiv:2502.11723, version revue Scientific Reports 2026) balaient la température de 0,1 à 1,2 sur Qwen2.5-7B, deux A100-PCIE-40GB, lot unitaire, et trouvent un écart de −0,2 % à +2,6 % avec le décodage glouton selon la tâche. Du bruit. Sur les mêmes lignes, passer à la stratégie de décodage DoLa coûte 51,5 % de plus.

Deux canaux indirects existent quand même, et méritent d'être nommés pour ne pas se faire reprendre. Une température haute peut faire écrire plus longtemps, et le coût est alors dans le nombre de tokens, pas dans le réglage. Elle dégrade aussi le taux d'acceptation du décodage spéculatif : EAGLE-2 (arXiv:2406.16858) mesure une perte d'accélération de 5,4 à 21,6 % en passant de la température nulle à 1, sur les paires mal appariées seulement. Le chaînage vers l'énergie n'a été mesuré par personne.

Personne n'a mesuré la longueur moyenne de sortie en fonction de la température à modèle et prompt fixés. DONNÉE MANQUANTE. L'expérience tient en deux jours pour qui a un GPU : longueur de sortie et déclenchement de la fin de séquence à plusieurs températures, sur un jeu de prompts fixe.

Ce que cette liste ne règle pas

L'efficacité par processus n'indique pas la consommation du système. Google a divisé par 33 son énergie par requête pendant que sa consommation électrique montait de 38 % et ses émissions de 18 %, sur la même année. Les dix leviers ci-dessus sont réels et chiffrés, et ils ont tous été activés à grande échelle par les acteurs qui les maîtrisent le mieux.

Si elle reste au volontariat, la sobriété de l'un libère de la capacité pour un autre. Seule une contrainte sur le total, un plafond ou un budget opposable, bat un effet rebond.

La ligne à tenir : les leviers individuels existent et sont chiffrés, mais ils ne suffisent pas. Vendre les premiers sans dire le second est une faute professionnelle.

Pour appliquer ce classement à un usage réel, le calculateur chiffre un mix de modèles et la méthodologie publie les paramètres utilisés.

FAQ

Quel est le levier le plus efficace pour réduire l'empreinte de l'IA ?

Ne pas utiliser de modèle de langage quand un substitut déterministe suffit, puisque le calcul n'a alors pas lieu. Le choix de modèle vient juste après, avec un écart de plus de 65 entre le modèle commercial le plus sobre et le plus gourmand, estimé par Jegham et al. sur 30 modèles commerciaux. L'optimisation des prompts arrive en dixième position et rapporte quelques pourcents.

Optimiser ses prompts réduit-il vraiment l'empreinte carbone ?

Marginalement, et beaucoup moins que la plupart des autres leviers. Le rapport Arcep de mai 2026 reprend un travail de green prompting mesurant 32 à 48 % d'énergie en moins à qualité égale sur la partie concernée, sans le nommer, mais l'entrée ne pèse qu'un quart de l'énergie sur du chat et moins encore sur de l'agentique. Sa valeur réelle est pédagogique : il rend le sujet tangible pour un utilisateur qui ne contrôle rien d'autre.

Faut-il auto-héberger un modèle pour réduire son empreinte ?

Pas à faible volume, où c'est énergétiquement pire qu'une API mutualisée. En génération à requête unique, un accélérateur ne tire que 137 à 300 W sur un budget de 700 et plus de 88 % de ses unités de calcul restent inactives, tandis qu'environ 75 % de l'énergie sert à maintenir le modèle chargé. À volume élevé et charge régulière, l'arbitrage s'inverse.

Couper le mode raisonnement dégrade-t-il la qualité ?

Sur les tâches qui ne le justifient pas, non : le régulateur français mesure un surcoût moyen de 92 % d'énergie pour un gain de performance inégal selon les tâches. Et même là où il apporte, une méthode publiée supprime 44,8 % des tokens de raisonnement pour une perte de justesse de 0,2 point. Le réglage doit s'appuyer sur une évaluation, pas sur une intuition.

Les gains d'efficacité suffisent-ils à faire baisser l'empreinte totale de l'IA ?

Non, et le meilleur contre-exemple vient d'un fournisseur. Google a divisé par 33 l'énergie de sa requête médiane entre mai 2024 et mai 2025, pendant que la consommation électrique de ses data centers augmentait de 38 % et ses émissions totales de 18 %. Seule une contrainte sur le volume total, sous forme de plafond ou de budget, compense un effet rebond.