Une démarche transparente,
pas une vérité scientifique.

1. Notre démarche

Chez Appliance Labs, notre métier est de concevoir et de déployer des solutions d’intelligence artificielle privées et locales. Nous ne sommes pas des spécialistes du climat ou de l’analyse du cycle de vie.

Mais nous pensons qu’il est important de chercher à comprendre l’impact environnemental des technologies que nous déployons. Alors nous avons commencé à creuser le sujet.

Nous avons étudié les travaux publiés par Artificial Analysis, Hugging Face, ML.ENERGY, l’ADEME et d’autres acteurs reconnus. Nous avons cherché à rapprocher les capacités des modèles d’IA de leurs consommations énergétiques, lorsque des mesures existent.

À partir de ces données, nous avons construit notre propre méthode d’estimation, avec ses hypothèses, ses extrapolations et, forcément, ses limites. Nous ne prétendons pas avoir toutes les réponses.

Les chiffres présentés ne constituent ni une analyse du cycle de vie certifiée, ni une mesure réelle des services cloud que vous utilisez. Ils permettent d’explorer différents scénarios et de mieux comprendre ce qui influence l’empreinte de l’IA.

2. Ce que nous comparons

Deux façons de fournir la même quantité de travail d’IA à une équipe de 50 personnes au plus, pendant trois ans : des services d’IA dans le cloud, ou une seule Appliance installée dans vos locaux.

Une demande est un travail complet confié à l’IA. Elle peut contenir plusieurs appels au modèle, du raisonnement et des reprises : tout est déjà compté dans sa taille.

La répartition porte sur les demandes, pas sur les personnes. L’association entre un usage et un modèle est illustrative : GPQA n’est pas un vrai parcours d’agent, et lm-arena-chat n’est pas votre travail quotidien. Aucune équivalence avec un modèle propriétaire n’est validée. Les tailles de demande sont des hypothèses, pas des usages observés.

Ce qui est compté, et ce qui ne l’est pas

Un poste inconnu ne vaut pas zéro. Le résultat compare donc des sous-totaux : ce n’est pas une réduction d’émissions certifiée.

3. Comment nous calculons

1. 1. Le volume de demandes

   Nombre de personnes × demandes par jour × 220 jours travaillés par an. La croissance annuelle s’applique à partir de la deuxième année. Les demandes sont ensuite réparties entre les trois usages.

2. 2. L’énergie côté cloud

   Nous multiplions le texte généré par l’énergie que ML.ENERGY a mesurée pour le modèle ouvert de référence. Cette énergie couvre déjà tous les GPU et le regroupement des requêtes : nous ne la multiplions pas une seconde fois. Nous ajoutons 15 % pour les autres composants du serveur, puis un facteur 1,20 pour le centre de données. Appliquer un benchmark à nos usages est une extrapolation, pas une mesure.

3. 3. Les émissions côté cloud

   L’électricité obtenue est multipliée par l’intensité carbone choisie pour le réseau électrique du cloud. C’est une hypothèse : nous ne connaissons pas celle de votre fournisseur.

4. 4. L’Appliance

   255 kg CO₂e comptés dès le départ, sans les étaler sur trois ans. Puis l’électricité : 38 W au repos et 140 W pendant 8 heures par jour, soit 630,72 kWh par an, multipliés par 0,029 kg CO₂e/kWh. Ce budget est fixe : il ne dépend pas du nombre de demandes.

5. 5. La comparaison

   Nous cumulons les deux côtés année après année. Le point de bascule est le moment où le cumul du cloud rejoint celui de l’Appliance. Il peut ne pas exister : avec une électricité cloud bas carbone, le cloud reste en dessous.

Les sources utilisées dans le calcul

Sources consultées le 11 octobre 2026. Les mesures de ML.ENERGY sont citées et liées à leur source. Nous ne republions pas leurs tableaux de données.

Le scénario de référence

50 personnes, 20 demandes par jour, répartition 70 / 20 / 10, usage stable, une Appliance, sur trois ans. Le calculateur s’ouvre sur l’électricité carbonée ; les trois hypothèses sont ci-dessous.

Ces chiffres ne démontrent pas une réduction d’émissions et ne décrivent aucun service commercial. Les variantes ne classent pas les fournisseurs, et leur étendue n’est pas un intervalle de confiance.

4. Nos hypothèses et limites

Chaque valeur porte son statut. Deux d’entre elles, l’électricité du cloud et l’empreinte de fabrication, se modifient dans les paramètres avancés du calculateur.

• HypothèseEmpreinte initiale de l’Appliance : 255 kg CO₂e

  Fabrication, livraison et installation. Provision non vérifiée : ce n’est pas un chiffre NVIDIA. Modifiable dans les paramètres avancés.

• HypothèsePuissance en activité : 140 W

  8 heures par jour, 365 jours par an. Hypothèse, pas une mesure sous cette charge.

• Déclaré par NVIDIAPuissance au repos : 38 W

  Valeur déclarée par NVIDIA pour la DGX Spark.

• Publié par RTEÉlectricité de l’Appliance : 0,029 kg CO₂e/kWh

  Production française 2025 en cycle de vie, publiée par RTE. Valeur d’approximation, pas le facteur exact de l’électricité livrée.

• HypothèseÉlectricité du cloud : 0,029, 0,200 ou 0,400 kg CO₂e/kWh

  Trois hypothèses au choix dans les paramètres avancés ; le calculateur s’ouvre sur la plus carbonée. Aucune n’est la valeur d’un fournisseur.

• HypothèseSurconsommation du centre de données (PUE) : 1,20

  Hypothèse de calcul, pas la valeur d’un fournisseur.

• HypothèseAutres composants des serveurs : 15 % de l’énergie des GPU

  Hypothèse de calcul.

• HypothèseVolumes : 220 jours

  Jours travaillés par an, sur 3 ans. La taille d’une demande dans chaque usage est une hypothèse, pas un usage observé.

Ce que la méthode ne sait pas faire

• La capacité de l’Appliance n’est pas vérifiée. Le scénario de référence lui demande de générer environ 163 tokens par seconde en moyenne sur huit heures de travail, sans marge pour les pics. Plusieurs appareils pourraient être nécessaires, ce qui augmenterait d’autant l’empreinte locale.
• L’association entre nos trois usages et les trois modèles de référence est illustrative. L’effet des demandes longues en entrée n’est pas modélisé.
• Les 140 W en activité et les 255 kg CO₂e d’empreinte initiale ne sont pas vérifiés. Le budget électrique fixe de l’Appliance n’est pas une loi de charge.
• Les facteurs d’émission du cloud et de l’Appliance ne reposent pas encore sur des périmètres harmonisés.
• Les variantes sont des scénarios, pas des probabilités. Certaines placent le cloud sous l’Appliance, d’autres au-dessus.
• Un contrat d’électricité renouvelable ne ramène pas automatiquement la consommation physique à zéro émission.
• La méthode n’a pas encore fait l’objet d’une revue indépendante.

5. Une méthode qui progresse

À mesure que nous déploierons nos appliances, nous chercherons à confronter nos estimations à des données de terrain, notamment avec CodeCarbon. Nous étudions également EcoLogits pour enrichir notre méthode.

À ce jour, ces outils n’ont produit aucune mesure de terrain : aucun chiffre de cette page ne vient d’une mesure réalisée par Appliance Labs.

Nous partagerons progressivement nos résultats, y compris lorsqu’ils ne seront pas favorables à Appliance Labs.

Et si vous travaillez sur ces sujets, nous serions ravis d’échanger. Une meilleure source, une erreur identifiée ou une critique constructive nous aideront à améliorer cette démarche.

Les travaux que nous étudions pour les prochaines versions

Méthode d’estimation v0.1.0 · sources consultées le 11 octobre 2026