Présentation du mail type et du contexte de classification
Le point de départ de cette étude est un mail type qui représente une demande classique adressée à un service client d’assurance incluant une pièce jointe :
Ce type de message doit être automatiquement classifié dans une ou plusieurs catégories opérationnelles, comme par exemple :
- Confirmation de RDV/Présence
- Convocation
- Ordre de mission
- Report de RDV
- Transmission de pièce sinistre
On se rend compte en tant qu’humain ici, que cet e-mail type est une “Confirmation de RDV/Présence” et que l’information est portée par la pièce-jointe.
Deux approches sont envisagées pour réaliser cette tâche de manière automatisée :
- Un modèle basé sur un grand modèle de langage (LLM), tel que GPT, Llama, Mistral ou leurs variantes locales, avec ou sans fine-tuning.
- Un système d’intelligence artificielle symbolique, fondé sur des règles explicites, des expressions régulières, ou un moteur de règles avec ontologie comme est constitué le coeur technologique de Golem.ai
L’objectif ici est de comparer leur efficacité énergétique et leur impact carbone pour une tâche simple mais fréquente dans les environnements professionnels.
Dans notre étude nous allons nous baser sur le texte uniquement et considérer que la PJ soit dans un format texte ne nécessitant pas d’OCR afin de nous focaliser uniquement sur le moteur symbolique.
Analyse LLM
Précision sur le protocole de test LLM
Dans le cadre de la comparaison, le système basé sur LLM ne sera pas entraîné spécifiquement, mais exploité via prompting : on envoie une requête formulée en langage naturel au modèle pour lui demander de classer le mail.
Construction du prompt
Afin de réduire au maximum la génération de texte inutile, qui alourdirait artificiellement la charge computationnelle et donc la consommation énergétique, nous construisons un prompt strictement guidé, du type :
« Classifie le mail suivant dans une des catégories suivantes : [Confirmation de RDV/Présence, Convocation, Ordre de mission, Report de RDV, Transmission de pièce sinistre]
Ne répond que par le nom exact de la catégorie choisie, sans justification.
Corps du mail à classifier : ‘Bonjour, Par la présente, je vous prie de bien vouloir prendre connaissance de notre courrier en pièce jointe….’
Pièce jointe du mail à classifier : ‘Vos références 8JD93JF63T Nos références 92745DY/TOD/TAY Expert Jean Dupont…”
Cette approche vise à limiter la génération superflue, en contraignant la sortie du modèle à un mot ou une expression unique, plutôt qu’un paragraphe explicatif ou un résumé.
Utilisation de compar:IA
Pour la mise en œuvre concrète, ce prompt sera testé à travers la plateforme compar:IA, un comparateur public d’IA développé par beta.gouv.fr Cette plateforme permet :
- De comparer différents modèles ouverts et fermés (GPT, Mistral, Claude, etc.)
- D’obtenir des temps de réponse
- D’évaluer la pertinence de la réponse
- Et, ce qui nous intéresse particulièrement ici c’est d’estimer une empreinte énergétique et son équivalent carbone
Ce cadre garantit une évaluation transparente et reproductible, sans nécessiter d’implémentation locale ou fine-tuning, ce qui reflète un cas d’usage typique pour des entreprises qui s’appuient sur des APIs externes pour automatiser certaines tâches.
Résultats
Le prompt incluant consigne (558 caractères) et texte (1099 caractères) de l’e-mail et de sa pièce jointe représente 1657 caractères.
Après avoir sollicité le service gouvernemental de comparaison des LLM compar:IA nous observons les résultats suivants sur 2 LLM connus :
- Llama 3 70B
- Mistral Large
On peut constater que les deux modèles ont bien suivi la consigne afin de ne pas être trop verbeux et ainsi limiter leur capacité d’hallucination. Nous pouvons également observer que Llama n’a pas été en mesure de trouver la bonne réponse.
D’autres LLM dits “frugaux” sont utilisés pour faire une moyenne des consommation sur quelques tentatives.
- Gemini 2.0 flash :
- Consommation: 3 wH
- Nb tokens : 599
- Réponse pertinente? : KO
- Nb params: 40 M
- Qwen2.5-Coder-32B :
- Consommation: 3 wH
- Nb tokens : 597
- Réponse pertinente? : KO
- Nb params: 32 M
- Ministral :
- Consommation: 1,39 wH
- Nb tokens : 598
- Réponse pertinente? : OK
- Nb params: 8 M
- Llama 3.1 8b :
- Consommation: 1,36 wH
- Nb tokens : 585
- Réponse pertinente? : KO
- Nb params: 8 M
Si on met de côté la notion de pertinence, on trouve que la consommation approximative d’un LLM pour effectuer une telle tâche pourrait être approximée à environ 2Wh. Ce qui revient, en moyenne basse pour les modèles LLM dits “frugaux” à :
- 2 Wh
- 2 g CO2 avec mix énergétique = 1000 g C02 / kWh (tout charbon)
- Soit 0,12 g C02 avec un mix énergétique à 60 g C02 /kWh (mix énergétique en France)
Il est à noter que Compar:IA part du principe que les serveurs sont hébergés dans un pays où le mix énergétique est de l’ordre de 1 kg CO2 / kWh ce qui correspond à une production proche du tout charbon.
En France le mix énergétique est de l’ordre de 0,06 kg CO2 / kWh
Plus d’information sur les mix énergétiques ici.
Approche symbolique
Précision sur le protocole de test de l’approche symbolique via la plateforme nlu produite par Golem.ai
L’approche symbolique repose sur un moteur de règles conçu pour identifier des motifs textuels simples dans l’e-mail, via des expressions régulières ou des conditions logiques.
Temps de développement
Ce moteur a été mis en place en moins d’une demi-journée, avec une rédaction manuelle de règles basées sur un jeu de mails types, ce qui constitue une charge réaliste pour une tâche métier simple et bien délimitée.
Protocole de mesure énergétique
La mesure de consommation énergétique repose sur les métriques système exposées via kepler-exporter, un collecteur open source qui expose des informations de consommation énergétique au niveau processus ou conteneur.
Ces données sont agrégées et visualisées via un dashboard Grafana, permettant de suivre en temps réel :
- La consommation énergétique au niveau processus
- Le CPU time et mémoire allouée
- Le delta de consommation induit par l’exécution de la tâche
Calcul Unitaire
Lors d’une mesure de manière totalement unitaire est isolée, l’exécution de la classification s’effectue localement sur une machine de développement standard (CPU seul, sans GPU), dans un environnement Linux. Il est possible d’obtenir les résultats suivants à l’issue de l’analyse du message et de sa pièce jointe via Golem.ai
Résultats mesurés :
- Classification trouvée : Confirmation de RDV/Présence
- Temps de traitement total ( API call, storage, NLU ) : 623 ms
- Puissance consommée par le pod (au moment de la requête) : 0,0207 W
Cela correspond à une énergie consommée de l’ordre de quelques microWattHeures
Mais les mesures unitaires ne reflètent pas la réalité opérationnelle complète.
En environnement de production, plusieurs facteurs structurels viennent s’ajouter :
- Haute disponibilité et résilience (ex. : redondance active/passive ou active/active des services)
- Systèmes de queuing et de gestion de flux (broker, bus de messages, orchestrateurs)
- Maintenance sous tension continue des services, même en période creuse
- Monitoring, logs, sauvegardes, etc.
Autrement dit : bien que des système de scaling automatique pour s’adapter à la charge aient été mis en place, le système NLU ne s’éteint pas totalement entre deux requêtes. Une plateforme reste sous tension 24h/24, et sa consommation énergétique réelle est bien supérieure à la simple somme des traitements unitaires.
Une approche globale plateforme sur une période de 2h (disons de 10h à 12h le matin)
Pour obtenir une vision réaliste de l’impact environnemental d’un système de classification symbolique, il est nécessaire de dépasser les mesures ponctuelles et de calculer la consommation énergétique totale sur une période étendue, en l’occurrence ici : 2 heures continues.
Méthode de calcul
L’énergie totale consommée par la plateforme sur la journée est calculée selon la formule classique :
Où :
- E est l’énergie totale consommée (en joules ou en kilowattheures, selon les unités),
- Pi est la puissance moyenne (en watts ou kilowatts) pendant l’intervalle de temps i,
- Δti est la durée de l’intervalle i (en secondes pour les watts, ou en heures pour les kilowatts),
- n est le nombre total d’intervalles dans la journée.
Les puissances mesurées sont agrégées par le système de monitoring (ex : kepler-exporter) sur des intervalles réguliers, ce qui permet de reconstituer précisément la consommation sur 2h.
L’énergie obtenue est ensuite multipliée :
- par le PUE du datacenter (ici 1.3 pour Scaleway),
- puis par le facteur d’émission du mix énergétique français, soit 0,06 kgCO₂/kWh.
Cela permet d’estimer la quantité totale de CO₂ émise par la plateforme qui supporte les IA sur 2 heures de fonctionnement. Et surtout de d’attribuer la part d’émission à un élément de valeur “utile” qui est l’analyse d’un caractère
Le tout divisé par le nombre total de caractère traité dans ces même 2 heures.
Résultat obtenu :
- Jour analysé : 23 avril 2025 entre 10h00 et 12h00
Émission ramené au caractère analysé :
1,212 x 10-6 gC02 / caractères analysés
Application au cas d’usage : un e-mail concret
En appliquant ce ratio au message étudié dans la partie 1, composé de 1099 caractères, on obtient : 0,0013gCO₂
Soit 1,3 milligramme de CO₂ émis pour le traitement symbolique complet de cet e-mail, en incluant :
- les temps creux
- la redondance
- l’infrastructure de support
- l’hébergement dans un datacenter réel
Ce type d’analyse permet de passer d’une vision idéalisée à une évaluation cycle de vie plus rigoureuse, et fournit un indicateur pertinent pour la suite de la comparaison avec un traitement basé sur LLM qui est normalement lui aussi soumis à ces contraintes pour un usage de production.
Conclusion de l’étude : deux technologies, deux ordres de grandeur
L’analyse comparative que nous avons menée met en lumière un écart massif d’empreinte carbone entre deux approches de traitement d’un même problème : la classification d’un e-mail.
À conditions égales (même mix énergétique et même type de message), les résultats sont les suivants :
- LLM (grande IA générative dite “frugale”) :
→ 120 mg de CO₂ émis par e-mail classifié - Approche symbolique (eg: Golem.ai basé sur les données réelles de production ) :
→ 1,3 mg de CO₂ émis par e-mail classifié
Cela signifie que pour un même résultat fonctionnel, l’approche LLM émet environ ~100 fois plus de CO₂ que son équivalent symbolique au Run .
Et cela, sans même tenir compte de l’un des coûts les plus significatifs que représente la phase d’entraînement du modèle LLM, qui mobilise pendant des semaines des fermes de GPU, consommant de l’énergie de l’ordre du GigaWh dans des pays où le mix énergétique est bien plus carboné que celui du sol français. Et cela bien avant que le premier e-mail ne soit classifié.
Pour se donner une idée 1 GigaWh aux États-Unis (si on se réfère aux données avancées par ce site gouvernemental – “823.1 lbs CO2 per megawatt-hour” ) émet dans l’atmosphère 373 tonnes de CO2.
LLM : brillants, mais pas toujours pertinents
D’abord, il est important de souligner que les LLM sont des outils remarquables. Ils peuvent expliquer des concepts, générer des textes, résumer des rapports, ou même produire du code compilable.
Toutefois, leur versatilité a un prix : celui d’une complexité et d’une consommation difficilement compressible, même lorsqu’ils sont utilisés pour des tâches triviales.
Or classifier un e-mail métier parmi quelques catégories bien définies ne nécessite ni compréhension fine du monde, ni génération linguistique sophistiquée.
Et si on changeait de question ?
Ce n’est pas : « Est-ce que ça marche avec un LLM ? »
Mais plutôt : « Est-ce que ça a du sens d’utiliser cette puissance pour cette tâche ? »
Car dans un monde fini, où il est vital de maîtriser sa consommation, le choix technologique devient aussi un choix éthique.
