Comment View AI mesure l'IA

Chapitre 01

L'essentiel en une page

View AI mesure l'empreinte environnementale de l'usage que vos équipes font des assistants d'IA générative dans leur navigateur. Une extension compte la taille de chaque question posée et de chaque réponse reçue sur ChatGPT, Claude, Gemini, Mistral Le Chat, DeepSeek et Copilot. Notre serveur convertit ces volumes en énergie, en émissions de CO₂ et en eau. La plateforme agrège ensuite ces chiffres par personne, par équipe et par outil.

Le contenu des conversations ne nous parvient jamais. L'extension lit le texte dans le navigateur le temps d'en compter les caractères, puis n'envoie que des nombres. Notre base de données n'a d'ailleurs aucune colonne capable de stocker une phrase.

Nos chiffres sont des estimations construites sur des volumes réellement mesurés. Le nombre de tokens est déduit du nombre de caractères. L'énergie par token vient de coefficients publiés par plateforme, pas d'un relevé sur les serveurs d'OpenAI ou d'Anthropic, auxquels personne n'a accès. Nous préférons le dire clairement plutôt que de présenter une précision que la situation ne permet pas.

L'extension propose aussi de réduire cette empreinte en demandant à l'IA des réponses plus courtes. Nous mesurons ce que cela change réellement et nous estimons le gain net, coût de notre propre instruction déduit. Quand la réponse est trop courte pour que la compression soit rentable, la plateforme l'affiche en rouge.

Ce document décrit la version 1.7.0 de l'extension et la formule de calcul v1. Chaque équation et chaque coefficient cités ici sont ceux du code. Les limites connues sont signalées là où elles s'appliquent, et le dernier chapitre liste ce qui a changé depuis la version précédente de ce whitepaper.

Chapitre 02

Mesurer l'usage plutôt que la dépense

La plupart des bilans carbone traitent les logiciels par leur coût. On multiplie le montant des factures par un facteur d'émission moyen du secteur numérique, et l'on obtient un chiffre. Pour l'IA générative, ce raccourci ne tient pas. Un abonnement ChatGPT au même prix peut servir à dix questions par mois ou à mille. La facture ne dit rien du calcul effectivement demandé aux serveurs.

Ce calcul dépend de deux choses que la facture ignore. La première est le nombre de requêtes, parce que chaque requête mobilise des machines et coûte une part fixe d'énergie, quelle que soit sa longueur. La seconde est le volume de texte, et surtout le volume généré. Un modèle lit la question d'un seul bloc mais produit la réponse mot après mot, chaque nouveau token demandant un passage complet dans le réseau de neurones. Générer coûte donc nettement plus que lire.

C'est pour cela que View AI compte les requêtes et sépare les tokens lus des tokens générés. On appelle cette approche une comptabilité par l'activité, par opposition à une comptabilité par la dépense.

Le contexte réglementaire, sans exagération

L'Agence internationale de l'énergie prévoit que la consommation électrique des centres de données fera plus que doubler d'ici 2030, portée en grande partie par l'IA. Les régulateurs européens commencent à demander des chiffres.

La directive CSRD impose aux entreprises concernées de publier leurs émissions, y compris celles de leur chaîne de valeur (le Scope 3) lorsqu'elles sont significatives. Son périmètre a été resserré par la directive Omnibus adoptée en février 2026, qui vise désormais les entreprises de plus de 1 000 salariés et de plus de 450 millions d'euros de chiffre d'affaires. Leurs fournisseurs reçoivent par ricochet des demandes de données.

Le règlement européen sur l'IA (règlement 2024/1689) oblige les fournisseurs de modèles d'IA à usage général à documenter la consommation d'énergie de leurs modèles, et son article 95 encourage des codes de conduite qui évaluent l'impact environnemental. En revanche, il n'impose pas aujourd'hui à une entreprise qui utilise ChatGPT de mesurer l'empreinte de cet usage. Nous le disons parce que certains discours commerciaux, y compris dans une version antérieure de ce document, ont laissé entendre le contraire.

Le vrai sujet est ailleurs. Les directions RSE doivent chiffrer un poste qui grossit vite et que personne ne sait mesurer. Les DSI veulent savoir quels outils sont utilisés et comment. Le référentiel AFNOR Spec 2314 sur l'IA frugale donne un cadre méthodologique à cette démarche. View AI fournit la donnée d'activité qui manque à ces trois besoins.

Chapitre 03

Le parcours d'une mesure

Voici ce qui se passe entre le moment où une personne envoie une question à un assistant et celui où le chiffre apparaît dans son tableau de bord.

La question elle-même part vers l'éditeur de l'IA exactement comme sans View AI. Nous ne sommes pas un intermédiaire réseau et nous ne voyons pas passer les échanges. L'extension observe ce que la page envoie et reçoit, localement, puis transmet à notre serveur un petit message qui ressemble à ceci.

Corps envoyé à POST /api/ingest/log (extension, backend-client.js)

{
  "platform": "Claude",
  "input_tokens": 125,
  "output_tokens": 400,
  "timezone": "Europe/Paris",
  "carbon_intensity": 0,
  "injector_used": false,
  "compression_level": 0
}

Rien d'autre ne quitte le poste. Ni le texte, ni l'adresse de la conversation, ni son identifiant, ni le nom exact du modèle. La requête est authentifiée par le jeton de session de l'utilisateur et chiffrée en HTTPS. Le fuseau horaire sert uniquement à choisir l'intensité carbone du calcul et n'est pas conservé. Le champ carbon_intensity est prévu pour recevoir un jour une intensité mesurée en temps réel. À zéro, le serveur applique sa table de référence.

Le serveur répond avec l'impact calculé, que l'extension affiche aussitôt. Si l'envoi échoue, parce que la connexion est coupée ou la session expirée, la mesure est mise en attente sur le poste et renvoyée au prochain envoi réussi. Elle n'est rejouée que pour le compte qui l'a produite.

Chapitre 04

L'extension de navigateur

L'extension est construite sur Manifest V3, le format actuel des extensions Chrome, et fonctionne à partir de Chrome 111. Edge et les autres navigateurs basés sur Chromium acceptent aussi les extensions du Chrome Web Store. Elle demande trois permissions. La permission storage garde localement les réglages, la file d'attente hors ligne et les quinze dernières activités. La permission tabs sert à transmettre le niveau de compression aux onglets ouverts et à ouvrir la page d'accueil. La permission webRequest sert à lire le corps des requêtes envoyées à quelques adresses précises.

Ces adresses sont listées une à une dans le manifeste. Il s'agit des points d'entrée des conversations de ChatGPT, Claude, Gemini, Mistral et DeepSeek, plus notre propre API. L'extension n'a aucun droit sur les autres sites. Ses scripts ne se chargent que sur sept domaines d'assistants d'IA.

Consentement avant toute mesure

À l'installation, une page explique ce qui est collecté et demande un accord explicite. Tant que cet accord n'est pas donné, aucune mesure n'est envoyée. Une personne qui refuse garde l'extension installée, inactive. Il faut ensuite se connecter avec un compte View AI, par e-mail et mot de passe, avec double authentification si elle est activée sur le compte.

Comment chaque plateforme est lue

Chaque assistant échange ses données avec un protocole différent. L'extension place donc un script dans la page elle-même, chargé avant le code du site, qui observe les appels réseau de la page sans les modifier, sauf quand la compression est activée (chapitre 6). Un second script, isolé de la page, fait le lien avec le reste de l'extension.

Pour Copilot Microsoft 365, l'extension ne compte un échange qu'après avoir vu la page envoyer une vraie question sur la connexion. Cela évite de compter comme nouveaux les anciens messages que Microsoft renvoie à la reconnexion.

Ce qui est gardé, ce qui est jeté

Le texte est lu en mémoire, le temps de mesurer sa longueur. Seule cette longueur est conservée, le temps que la réponse arrive, puis convertie en tokens en divisant par quatre et en arrondissant au supérieur. Le texte lui-même n'est ni écrit sur le disque, ni envoyé à notre serveur.

L'extension repère souvent le modèle utilisé, par exemple GPT-4o ou DeepSeek R1. Elle le garde localement mais ne le transmet pas encore. Le calcul se fait donc au niveau de la plateforme et non du modèle, ce que corrigera la prochaine version du moteur (chapitre 9).

Les limites de la mesure

Le ratio de quatre caractères par token est une convention calibrée sur l'anglais. En français, un token couvre en moyenne moins de caractères, si bien que nous sous-estimons légèrement le volume réel.

Nous comptons le nouveau message de l'utilisateur, pas tout l'historique de la conversation que le modèle relit à chaque tour. Sur une longue conversation, l'entrée réelle est donc plus grande que celle que nous comptons. La réflexion que certains modèles produisent sans l'afficher échappe aussi à l'extension, alors que celle qui est affichée, chez Claude par exemple, est comptée.

Les images, fichiers joints et générations d'images ne sont pas encore mesurés. Enfin, l'extension suppose un échange à la fois par plateforme. Deux questions envoyées avant la fin de la première réponse peuvent fausser l'attribution du niveau de compression.

Toutes ces limites vont dans le même sens. Elles conduisent à sous-estimer l'empreinte plutôt qu'à la gonfler.

Chapitre 05

Le moteur de calcul

Le calcul qui fait foi est effectué sur notre serveur. Toutes les surfaces de View AI utilisent donc la même formule, et nous pouvons la faire évoluer sans attendre que chaque utilisateur mette à jour son extension. La formule en production s'appelle v1.

L'équation

Une requête consomme une énergie fixe, à laquelle s'ajoute un coût par token lu et un coût plus élevé par token généré. Ce total est majoré de 25 % pour tenir compte de la fabrication du matériel. On ajoute une part de l'énergie qui a servi à entraîner le modèle, répartie sur sa durée de vie. Le résultat est l'électricité de la requête, en wattheures.

Le facteur 1,2 est le PUE, l'indicateur d'efficacité des centres de données. Il ajoute au calcul l'électricité consommée par le refroidissement et la distribution électrique. L'intensité carbone I dépend du lieu où la requête est traitée (voir plus bas). Le facteur eau de 1,8 litre par kWh correspond à l'eau évaporée pour refroidir les serveurs. Chaque résultat est arrondi à quatre décimales.

Extrait de backend/internal/services/formula.go

inferenceWh := (cfg.base + float64(inputTokens)*cfg.inputCost +
    float64(outputTokens)*cfg.outputCost) * embodiedFactorV1   // 1.25

totalElec := inferenceWh + trainingWh
return Impact{
    Elec:  round4(totalElec),
    CO2:   round4(totalElec * pueV1 * carbonIntensity / 1000),  // PUE 1.2
    Water: round4(totalElec * waterFactorV1 * pueV1 / 1000),    // 1.8 L/kWh
}

Les coefficients par plateforme

Les coefficients ont été calibrés sur trois publications de 2025. Il s'agit de la consommation moyenne par requête annoncée par OpenAI (Sam Altman, juin 2025), de celle publiée par Google pour Gemini, et du banc d'essai de Jegham et al. qui compare la consommation d'une trentaine de modèles. Une plateforme inconnue reçoit le profil « Autre ».

Copilot reprend le profil de ChatGPT parce qu'il repose sur la même famille de modèles, servie par Microsoft sur Azure. DeepSeek est un modèle à experts dont seule une fraction des paramètres travaille à chaque token, d'où un coût par token plus bas. L'amortissement de l'entraînement divise l'énergie totale d'entraînement estimée par le nombre de requêtes attendu sur la vie du modèle. Pour GPT-3.5, environ 1 300 MWh répartis sur environ cent milliards de requêtes donnent 0,00003 Wh par requête. Ce poste pèse très peu à l'échelle d'une requête, ce qui est cohérent avec la littérature récente.

Où la requête est-elle traitée ?

Un kWh consommé en France émet beaucoup moins qu'un kWh consommé aux États-Unis ou en Asie. La formule applique donc une intensité carbone qui dépend de l'endroit probable du centre de données. Faute de connaître ce lieu exactement, nous utilisons ce que l'on sait de chaque fournisseur, et le fuseau horaire de l'utilisateur quand le fournisseur route ses requêtes par région.

Ces valeurs sont des moyennes annuelles ajustées aux centres de données, tirées des données de l'AIE, d'Electricity Maps et des rapports de durabilité des fournisseurs. Gemini reçoit la moyenne mondiale parce que Google répartit ses calculs sur un réseau mondial et compense une grande partie de sa consommation par des achats d'électricité renouvelable.

Un exemple de bout en bout

Prenons une personne à Paris qui pose à Claude une question de 500 caractères et reçoit une réponse de 1 600 caractères. L'extension compte 125 tokens en entrée et 400 en sortie.

Le même échange donne des résultats très différents selon l'outil. Voici une question de 125 tokens et une réponse de 500 tokens, posées depuis la France.

Deux enseignements ressortent. La part fixe par requête pèse lourd, 0,25 Wh sur 0,64 pour ChatGPT. Pour des échanges courts, le nombre de questions compte donc davantage que leur longueur. Et le lieu de calcul fait varier le CO₂ d'un facteur dix entre Mistral, servi depuis l'Europe, et les autres.

Versionnage

Chaque formule est une stratégie nommée dans le code, et le serveur sait laquelle est active. Une table de versions enregistre qui a créé quelle version et quand. Changer de formule ne réécrit pas l'historique. Un outil d'administration permet de recalculer les données d'une organisation avec une autre version, mais ce recalcul reste approximatif pour les lignes anciennes, qui ne gardent ni la répartition entre tokens lus et générés d'avant septembre 2026, ni le fuseau horaire. À ce jour, une seule formule a été utilisée en production, la v1.

Le chiffre affiché dans l'extension pendant qu'une mesure attend d'être envoyée est calculé localement avec une copie des mêmes coefficients. Cette copie ajoute une petite estimation de l'énergie du réseau (Aslan et al., 2018) que le serveur ne compte pas. Dès que le serveur répond, c'est son chiffre qui remplace l'estimation locale.

Ce que la formule v1 ne fait pas

Elle raisonne par plateforme et non par modèle, alors qu'un modèle léger et un modèle de raisonnement n'ont pas la même consommation. Elle utilise des intensités carbone moyennes et non la valeur du réseau électrique à l'heure de la requête. Elle applique un seul PUE et un seul facteur eau à tous les fournisseurs, et ne compte que l'eau de refroidissement, pas celle consommée pour produire l'électricité. Le facteur de fabrication de 25 % est forfaitaire. Ces choix ont été faits pour disposer d'un calcul simple, traçable et identique pour tous. La formule v2 en corrige l'essentiel (chapitre 9).

Chapitre 06

Optimisez votre impact

Puisque la génération de texte est la part la plus coûteuse d'une requête, la manière la plus directe de réduire l'empreinte est d'obtenir des réponses plus courtes quand une réponse courte suffit. C'est ce que fait le curseur « Optimisez votre impact » de l'extension.

Le fonctionnement

Le curseur propose cinq positions, 0, 20, 40, 60 et 80 %. Le niveau choisi est mémorisé et transmis aux onglets ouverts. Quand il est supérieur à zéro, l'extension ajoute à la fin du message de l'utilisateur, juste avant l'envoi, un bloc d'instructions qui demande une réponse plus concise. Le bloc demande aussi au modèle de terminer par une ligne de signature qui rappelle le niveau appliqué. Voici celui du niveau 40 %.

Extrait de content.js, COMPRESSION_PAYLOADS[40]

{
  "output": "condensed",
  "style": "short_paragraphs_plus_bullets",
  "constraints": ["no_filler", "no_preamble", "no_meta_talk",
    "skip_politeness", "zero_redundancy", "write_complete_sentences",
    "start_with_brief_orienting_sentence",
    "bullets_must_be_full_sentences", "no_telegraphic_style"],
  "append_signature": "View AI - Réponse compressée de 40% : total token output : [N]"
}

Les niveaux 60 et 80 % ajoutent une indication max_tokens de 400 puis 220. Il faut être précis sur ce point. Cette indication fait partie du texte envoyé au modèle, elle n'est pas un paramètre technique qui couperait la réponse. Le modèle la suit généralement, sans y être contraint. Au niveau 0, l'extension ne modifie rien. Nous avons vérifié octet par octet que la requête envoyée est alors identique à l'originale.

Avec la compression activée, l'extension n'est donc plus un simple observateur. Elle ajoute du texte à la question, à la demande explicite de l'utilisateur, et ce texte part vers l'éditeur de l'IA avec le reste du message.

Ce que nous mesurons

Chaque mesure indique si l'instruction a réellement été ajoutée et à quel niveau. Si le format de la page n'a pas été reconnu et que l'ajout a échoué, la mesure est enregistrée comme non compressée, même si le curseur était réglé plus haut. La base de données refuse d'ailleurs toute ligne qui déclarerait un niveau de compression sans que l'instruction ait été ajoutée.

La plateforme compare ensuite, pour chaque outil, la longueur moyenne des réponses avec et sans compression, ainsi que l'énergie et le CO₂ moyens par question. La comparaison se fait outil par outil, parce que comparer ChatGPT compressé à Claude non compressé comparerait des modèles et non des habitudes. Il s'agit d'une observation de vos usages réels et non d'un test contrôlé. Les questions posées avec et sans compression ne sont pas les mêmes.

Ce que nous estimons, et comment

Pour chiffrer le gain, nous supposons que le modèle a raccourci sa réponse exactement du pourcentage demandé. Une réponse compressée de o tokens au niveau L aurait donc compté o ÷ (1 − L) tokens sans compression. Il faut ensuite retirer les deux coûts que la compression ajoute elle-même. Le premier est l'instruction, lue par le modèle à chaque question, soit 103, 152, 162 et 156 tokens aux niveaux 20, 40, 60 et 80 %. Le second est la ligne de signature, environ 16 tokens générés.

Nous valorisons chaque token au coût marginal de la formule et non au coût moyen. Le coût moyen répartirait la part fixe de 0,25 Wh sur les tokens et doublerait à peu près le gain affiché. Ce serait flatteur, mais faux, puisque la part fixe est payée que la réponse soit courte ou longue.

Il en découle un seuil de rentabilité. En dessous d'une certaine longueur de réponse, l'instruction coûte plus qu'elle ne fait économiser, et la plateforme affiche alors un surcoût net en rouge.

Exemple concret. Une réponse de 300 tokens obtenue avec Claude au niveau 40 % correspond à environ 173 tokens générés en moins. Une fois l'instruction déduite, le gain net estimé est de 0,089 Wh et de 0,041 gCO₂e pour cette question.

Premier résultat réel

Le 22 septembre 2026, un premier échange compressé à 40 % a été mesuré sur Copilot Microsoft 365. La réponse faisait 267 tokens, contre 409 en moyenne pour des questions de même longueur posées juste avant sans compression, soit 35 % de moins. Selon la formule v1, l'énergie de l'échange passe de 0,570 à 0,500 Wh, soit 12 % de moins, parce que la part fixe ne bouge pas et que l'instruction ajoute des tokens en entrée.

Ce résultat va dans le sens attendu, mais un seul échantillon ne prouve rien. Nous préparons un protocole à trois bras qui compare, sur les mêmes questions, une réponse libre, une simple consigne de concision et notre instruction complète, avec une mesure de la qualité des réponses. Tant que ce protocole n'a pas été publié, nous présentons le gain comme une estimation.

Et sur la facture ?

Quand l'usage de l'IA est facturé au token, via une API, moins de tokens générés signifie une facture plus basse. Avec un abonnement par utilisateur comme ChatGPT Enterprise ou Copilot, le prix ne change pas. Le gain est alors environnemental, pas financier.

Chapitre 07

La plateforme

La plateforme web, accessible sur app.viewai.fr, rassemble les mesures de toute une organisation. L'extension offre la même lecture à l'échelle d'une personne.

Dans l'extension

La fenêtre de l'extension affiche un graphique de l'énergie, du CO₂, de l'eau ou du nombre de questions, par jour, semaine ou mois. Elle traduit les totaux en équivalents concrets, sur la base d'une charge de smartphone de 15,4 Wh, d'une voiture essence à 120 gCO₂ par kilomètre et d'un verre d'eau de 20 cl. Elle contient aussi le curseur de compression, avec le résultat des trente derniers jours, et les quinze dernières mesures.

Le tableau de bord

Le tableau de bord montre deux séries d'indicateurs. La première compare le mois en cours au mois précédent. La seconde suit la période et le périmètre choisis, une personne ou toute l'équipe. Viennent ensuite une courbe dans le temps, la répartition par outil d'IA et la carte de compression décrite au chapitre précédent. Les unités s'adaptent à l'ordre de grandeur, du milliwattheure au kilowattheure.

Les équipes

Une organisation a des administrateurs et des membres, invités par e-mail. Un administrateur voit les chiffres de chaque membre et leur historique de mesures. Ces historiques ne contiennent que les nombres décrits au chapitre 3, jamais le contenu des échanges. Nous recommandons d'en informer les équipes lors du déploiement.

Les rapports

Des rapports périodiques sont envoyés par e-mail, à une personne ou à l'administrateur d'une organisation, selon une fréquence quotidienne, hebdomadaire, mensuelle ou à intervalle fixe. Le rapport donne les totaux de la période, détaillés par outil pour un rapport individuel, des équivalences issues des données de l'ADEME, de l'AIE et du Water Footprint Network, et une projection sur le mois, l'année et trois ans. Chaque exécution est journalisée, qu'elle réussisse ou échoue, avec sa durée et l'erreur éventuelle. Il est ainsi possible de prouver qu'aucune période n'a été oubliée.

Intégrations

Les organisations des offres Basic et Premium disposent d'une clé d'API qui permet d'envoyer des mesures depuis un autre outil que l'extension. La clé n'est affichée qu'une fois, lors de sa création. Nous n'en conservons qu'une empreinte cryptographique.

Ce qui n'existe pas encore

Les réglages de gouvernance permettent déjà de fixer un seuil d'émissions et de choisir qui reçoit les alertes. Ces réglages sont enregistrés, mais le déclenchement des alertes et le blocage au-delà du seuil ne sont pas encore actifs. Le rapport PDF destiné au reporting CSRD n'est pas encore disponible non plus. Les rapports actuels sont envoyés par e-mail.

Chapitre 08

Données, sécurité et conformité

La table des mesures

Toutes les mesures sont écrites dans une seule table, par une procédure stockée que le serveur appelle après le calcul. Voici sa structure actuelle.

Table public.mew_logs (migrations 001 et 003)

CREATE TABLE public.mew_logs (
  id                uuid DEFAULT gen_random_uuid() NOT NULL,
  user_id           uuid NOT NULL,
  org_id            uuid,
  platform          text NOT NULL,
  token_count       integer DEFAULT 0 NOT NULL,   -- entrée + sortie
  output_tokens     integer,                      -- NULL si inconnu
  electricity       double precision DEFAULT 0,   -- Wh
  co2               double precision DEFAULT 0,   -- gCO2e
  water             double precision DEFAULT 0,   -- litres
  injector_used     boolean DEFAULT false NOT NULL,
  compression_level smallint DEFAULT 0 NOT NULL,  -- 0, 20, 40, 60 ou 80
  created_at        timestamptz DEFAULT now()
);

Le seul champ texte, platform, reçoit le nom de l'outil, comme « Claude » ou « Mistral ». Tout le reste est numérique, booléen ou horodaté. Trois contraintes vérifiées par la base elle-même garantissent la cohérence des données. Le niveau de compression doit appartenir à la liste autorisée, un niveau supérieur à zéro exige que l'instruction ait été ajoutée, et les tokens de sortie ne peuvent dépasser le total.

Le serveur vérifie aussi chaque mesure avant de l'enregistrer. Une mesure sans plateforme, sans tokens d'entrée ou avec un niveau de compression incohérent est rejetée.

Hébergement

Toute l'infrastructure applicative est hébergée chez Scaleway, entreprise française, dans sa région de Paris. L'API tourne sur une instance Scaleway, derrière un proxy qui gère le HTTPS. La base PostgreSQL est un service managé, joignable uniquement par un réseau privé et avec une connexion chiffrée. Les deux applications web tournent en conteneurs dans la même région, et les e-mails partent par le service d'envoi de Scaleway.

Comptes et accès

L'authentification repose sur GoTrue, un serveur d'authentification open source que nous hébergeons nous-mêmes sur la même infrastructure. Les mots de passe sont stockés hachés. Les utilisateurs peuvent activer une double authentification par application TOTP, exigée pour les accès du personnel de View AI. Les sessions de l'application web sont portées par des cookies inaccessibles au JavaScript, et les jetons de rafraîchissement sont renouvelés à chaque utilisation.

Le nombre de requêtes par client est limité pour contrer les tentatives de force brute. Les actions sensibles du personnel de View AI sont inscrites dans un journal d'audit, qu'il s'agisse d'un accès à une organisation pour l'assistance, d'un recalcul, d'une suppression ou d'un envoi groupé.

Vos droits

Chaque utilisateur peut télécharger l'ensemble de ses données, profil et historique de mesures, en JSON ou en CSV, depuis ses paramètres. Il peut aussi supprimer son compte, après confirmation par un code envoyé par e-mail. Ces deux fonctions répondent aux droits d'accès, de portabilité et d'effacement prévus par le RGPD.

Chapitre 09

Ce qui arrive ensuite

La formule v2 passera d'un calcul par plateforme à un calcul par modèle. Elle s'appuiera sur EcoLogits, la méthode ouverte développée par l'association GenAI Impact, qui estime l'énergie d'un modèle à partir de son nombre de paramètres actifs et du matériel qui le fait tourner. Son registre couvre plus de 340 modèles d'OpenAI, Anthropic, Google, Mistral, Cohere et des modèles ouverts de Hugging Face. Nous y ajouterons DeepSeek, Qwen et Grok, en citant nos sources pour chaque entrée et en respectant la licence CC BY-SA du registre.

Pour que ce calcul par modèle fonctionne, l'extension transmettra le modèle qu'elle détecte déjà. Chaque mesure indiquera aussi la version de formule qui l'a produite, ce qui rendra tout recalcul traçable ligne par ligne.

Le PUE et la consommation d'eau seront propres à chaque fournisseur, et l'eau consommée pour produire l'électricité sera comptée en plus de celle du refroidissement. L'intensité carbone pourra être lue en temps réel, côté serveur, pour les régions où la donnée existe.

Côté compression, le protocole à trois bras décrit au chapitre 6 sera publié avec ses résultats, qu'ils soient favorables ou non. Côté plateforme, arrivent le rapport PDF pour le reporting CSRD et l'activation des alertes de seuil.

Chaque évolution de méthode donnera lieu à une nouvelle version de ce document, avec la liste de ce qui a changé.

Chapitre 10

Sources, versions et corrections

Ce qui a changé depuis la version 1.6

La version précédente de ce whitepaper décrivait un calcul effectué dans l'extension. Il est désormais effectué sur notre serveur, et les coefficients cités ici sont ceux du serveur. L'énergie du réseau n'entre plus dans le chiffre officiel. Les intensités carbone de référence pour les États-Unis et le monde sont de 380 et 430 gCO₂e par kWh, et non plus 450 et 475.

En préparant ce document, nous avons constaté que le serveur calculait les mesures de Copilot et de DeepSeek avec le profil générique « Autre » et non avec leur propre profil. C'est corrigé depuis le 27 septembre 2026. Les mesures antérieures de ces deux outils restent calculées avec le profil générique.

L'hébergement est passé de Supabase à Scaleway, et la table des mesures a gagné les colonnes de compression décrites au chapitre 8. Nous avons retiré trois éléments de l'ancienne version. Le premier est la simulation Monte Carlo, qui ne reposait pas sur des mesures réelles. Le deuxième est la mention d'un plafond de tokens imposé, qui n'est en réalité qu'une consigne. Le troisième est la présentation des amendes du règlement sur l'IA comme une menace directe pour les entreprises utilisatrices, qui était juridiquement inexacte. L'intégration avec un partenaire de reforestation, évoquée comme perspective, n'est pas développée à ce jour.

Les installations de l'extension encore en version 1.6 calculent l'impact localement avec l'ancienne méthode. La mise à jour 1.7.0 bascule tous les utilisateurs sur la méthode décrite dans ce document.

Sources

Agence internationale de l'énergie, Energy and AI, 2025. Sam Altman, The Gentle Singularity, juin 2025. Google, How much energy does Google's AI use? We did the math, août 2025. Jegham et al., How Hungry is AI? Benchmarking Energy, Water, and Carbon Footprint of LLM Inference, arXiv, 2025. Aslan et al., Electricity Intensity of Internet Data Transmission, Journal of Industrial Ecology, 2018. GenAI Impact, méthodologie EcoLogits. Electricity Maps. ADEME, Base Empreinte. Règlement (UE) 2024/1689 sur l'intelligence artificielle. Conseil de l'Union européenne, directive Omnibus I modifiant la CSRD, février 2026. AFNOR, Spec 2314, Référentiel général pour l'IA frugale, 2024.

Versions décrites

Extension View AI 1.7.0, formule de calcul v1 (clé v1), schéma de base après la migration 003. Document version 2.0, septembre 2026.