# Je code: les bonnes pratiques en éco-conception de service numérique à destination des développeurs de logiciels

Cyrille Bonamy, Cédric Boudinet, Laurent Bourgès, Karin Dassas, Laurent Lefèvre, Didier Mallarino, Benjamin Ninassi, Francis Vivat

► To cite this version:

Cyrille Bonamy, Cédric Boudinet, Laurent Bourgès, Karin Dassas, Laurent Lefèvre, et al.. Je code : les bonnes pratiques en éco-conception de service numérique à destination des développeurs de logiciels. 2026, pp.1-19. [hal-03009741v6](https://hal.science/hal-03009741v6)

HAL Id: hal-03009741

https://hal.science/hal-03009741v6

Submitted on 23 Feb 2026

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>
# Je code : les bonnes pratiques en écoconception de service numérique à destination des développeurs de logiciels

## Auteurs :

- Cyrille Bonamy : LEGI / CNRS

- Cédric Boudinet : G2Elab / Grenoble INP

- Laurent Bourgès : OSUG / CNRS

- Karin Dassas : CESBIO / CNRS

- Laurent Lefèvre : ENS Lyon / Inria

- Didier Mallarino : OSU Pythéas / CNRS

- Benjamin Ninassi : Inria

- Francis Vivat : LATMOS / CNRS

Les auteurs sont membres du Groupement de Recherche et de Service (GDRS) CNRS EcolInfo [1.1], qui travaille sur l'écoresponsabilité du numérique.

## Résumé :

Cette plaquette est un complément aux 3 plaquettes de bonnes pratiques liées au développement logiciel proposées par le réseau des acteurs du DEVelopment LOGiciel au sein de l'Enseignement Supérieur et de la Recherche : DevLOG.

Ce volet est dédié aux bonnes pratiques en termes d'écoconception de service numérique qui permettent d'appréhender, de comprendre et de réduire l'impact environnemental du numérique.

Après avoir explicité le contexte général dans une première fiche, une seconde fiche ("Mais pourquoi ?") met en évidence la nécessité d'intégrer une dimension environnementale dans nos conceptions de service numérique, et par conséquent dans nos développements de logiciels. La troisième fiche ("Quand ?") rappelle les étapes du cycle de vie d'un service numérique pour introduire les fiches de bonnes pratiques qui correspondent aux différentes étapes : "Avant", "Pendant" et "Après", en gardant à l'esprit que le développement est souvent itératif, et les frontières entre les différentes étapes sont perméables.

Vous trouverez à la fin de la plaquette une fiche spécifique sur les bonnes pratiques d'écoconception pour le calcul scientifique, ainsi que des fiches concernant le développement web, l'IA générative, ou les systèmes embarqués.

Les plaquettes DevLOG existantes :

- Je code : les bonnes pratiques développement logiciel [1.2]

- Je code : les bonnes pratiques de diffusion [1.3]

- Je code : quels sont mes droits et obligations ? [1.4]
## Un service numérique, c'est :

* de l'information : les données

* des traitements : algorithme, filtrage, simulation

* des échanges d'informations

* des interfaces utilisateurs

## Un service numérique repose sur :

* des infrastructures logicielles : applications, outils, bibliothèques, protocoles

* des infrastructures matérielles : serveurs, équipements réseau, terminaux, capteurs

* des données : la matière qui sera traitée par le matériel et le logiciel

* des personnes : développeurs, administrateurs systèmes et réseaux, chefs de projet, chercheurs

## Les impacts humains [2.1]

A travers leur quotidien, les humains collaborant à la production de services numériques vont générer des impacts : ils vont par exemple utiliser du matériel informatique et se déplacer pour venir à leur bureau ou pour se réunir. Mettre en place une politique environnementale d'organisation permettant de limiter ces impacts est crucial. Par exemple, favoriser la prolongation de la durée de vie des ordinateurs et l'utilisation de matériel reconditionné va réduire la part de l'impact de la fabrication des équipements.

## Exemple de service numérique : le workflow d'une simulation numérique.

### Il est constitué des briques suivantes :

* la préparation des données d'entrée

* le transfert des données d'entrée vers la plateforme de calcul considérée (machine locale, méso centre régional (Liste ESR [2.2]), national (GENCI [2.3]), cloud public, GPU/CPU)

* le calcul sur la plateforme de calcul

* le transfert des données vers la plateforme de post-traitement

* le post-traitement, stockage et dissémination des données de sortie du calcul

* l'analyse et l'exploitation des données

### De nombreux leviers pour réduire les impacts, mais une vision globale est nécessaire :

* s'interroger sur la pertinence du projet et de toutes ses fonctionnalités

* choisir des briques logicielles externes ou à redévelopper en interne

* limiter les transferts et les manipulations sur les données

* choisir la plateforme de calcul, de pré et post-traitement

* optimiser le temps de calcul (oui, mais...)

* post-traiter les données au plus proche du lieu de création

* limiter les données d'entrée et/ou de sortie

**Eco-concevoir** un service numérique, c'est intégrer les aspects environnementaux tout au long de son cycle de vie [2.4] (attention à bien définir l'unité fonctionnelle [2.5])

Développeurs, mais aussi chefs de projet, ingénieurs et chercheurs, tous et toutes sont concernés par cette plaquette !
Pourquoi se préoccuper de l'impact environnemental du numérique ? Tout simplement parce qu'il est loin d'être négligeable. L'augmentation de la contribution du numérique dans les émissions GES (Gaz à Effet de Serre) globales mondiales est exponentielle. Quelques références générales sur le sujet en page 18 (ARCEP 2025 [3.1], ADEME 2025 [3.2], EcolInfo [3.3], Green IT [3.4], INR [3.5], DINUM [3.6], Boavizta [3.7]), ainsi que des références orientées datacentre ADEME scenario DC [3.8], rapport Shift Project 2025 [3.9].

A noter que l'impact du numérique ne se limite pas à sa déclinaison la plus médiatisée, les émissions de gaz à effet de serre et le réchauffement climatique. L'impact principal provient de la fabrication des équipements numériques et de la gestion de leurs déchets : pollution des sols et des nappes phréatiques, raréfaction des ressources en eau, ainsi que des conséquences sur la santé et la biodiversité. Le numérique a également des répercussions sociales et humaines (par exemple, les minerais de conflit, ou les conditions de travail précaires dans l'annotation des IA) et des effets systémiques en amplifiant l'impact d'autres secteurs par effet rebond. Le traitement des D3E (Déchets d'Equipements Electriques et Electroniques) [3.10], Infographie D3E [3.11], n'entre cependant pas dans le cadre de cette plaquette.

<figure><img src="image_2.png" /></figure>

[1] Données Fiches Dell Matinfo [3.12] (usage sur 7 ans)

Facteur d'impact FR : 0,0599 kgCO₂/kWh [3.13]

[2] Méthode sphera pour laptops et écrans [3.14]

[3] Méthode Paia pour les serveurs calcul et stockage [3.15], 100% taux utilisation

[4] ADEME [3.16]

[5] SNCF [3.17]

[6] Izi by EDF [3.18]

* le logiciel est au cœur du service numérique et conditionne le matériel nécessaire ainsi que sa durée de vie

* les volumes de données et leur complexité conditionnent les besoins en puissance de calcul, en mémoire et en stockage, qui influencent directement la durée de vie potentielle des équipements

* la phase de fabrication du matériel est très impactante d'un point de vue environnemental

* faire durer ses équipements le plus longtemps possible permet de diminuer l'impact global de la fabrication des équipements en ayant un moindre renouvellement du matériel

Un projet de recherche qui nécessite 50 millions d'heures.cœur de calcul correspond approximativement à 60 ou 200 tonnes eqCO2 en fonction du facteur d'émission g/h.cœur CPU utilisé. Le facteur d'émission dépend du centre de calcul, des processeurs utilisés (CPU / GPU (x20 environ)) et de la méthodologie suivie (rapport MesoNET [3.19]). A titre de comparaison, 200 tCO2eq sont équivalentes à environ 100 Allers-Retours Paris - New York en avion selon l'ADEME [3.20].
L'écoconception d'un service numérique consiste à intégrer des contraintes environnementales dans tous les processus de développement, afin de **réduire les impacts environnementaux du service numérique pendant son cycle de vie**. Les impacts peuvent avoir lieu à chaque étape du cycle de vie du service : avant son développement (définition des besoins, analyse), pendant son développement (conception, développement logiciel, tests, mise en production) et après son développement (exploitation, maintenance, fin de vie). De façon générale, plus la prise en compte des aspects environnementaux intervient tôt dans le cycle de vie, plus l'effet est important. Cette plaquette propose d'explorer différentes bonnes pratiques d'écoconception de service numérique en s'intéressant tout particulièrement au logiciel, et aux éléments à prendre en compte avant, pendant et après la phase de développement logiciel.

A noter que les bonnes pratiques proposées ne sont pas dépendantes du cycle de développement choisi : cycle en V, en W, en spirale, en cascade, modèle agile. Un modèle itératif peut permettre de diminuer les impacts d'une étape lors d'une nouvelle itération.

<figure><img src="image_3.png" /></figure>

Marie Chevallier, 2023

Agir pour réduire l'impact environnemental est possible à chaque étape

Suivre le code couleur !

Avant

Pendant

Après
S'appuyer sur les grands principes d'écoconception de service numérique :

* simplicité : simplifier le logiciel pour éviter les usines à gaz

* en termes de fonctionnalités : 70 % des fonctionnalités demandées par les utilisateurs ne sont jamais ou rarement utilisées (Standish Group, 2006)

* en termes d'interfaces utilisateurs

* frugalité et sobriété : limiter le nombre et la taille des éléments (images par exemple). Par exemple, dans un développement web, éviter les pages "obèses" en terme de fonctionnalités et de graphisme.

* pertinence = utilité (le résultat doit répondre à l'attente de l'utilisateur) x rapidité (temps de réponse pour l'utilisateur) x accessibilité (par exemple pour certains handicaps)

* durabilité : réutiliser tout ou partie d'un logiciel permet d'éviter de dupliquer les développements; contribuer pour le bénéfice de la communauté.

## Je maîtrise le nombre de fonctionnalités logicielles : éviter l'obésiel

**Trop de fonctionnalités disparates :** où est passée la fonction que j'utilisais le plus souvent ? Mon logiciel est devenu un obésiel ! Mon service numérique devient une véritable "usine à gaz" !

<figure><img src="image_4.png" /></figure>

**Plus de fonctionnalités que nécessaire :** mon ancienne infrastructure ne suffit plus, je dois en changer !

<figure><img src="image_5.png" /></figure>

**Fonctionnalités justifiées et utiles :** mon service numérique est léger et efficace !

## Je favorise le libre : réutiliser des briques logicielles et contribuer aux communs

<figure><img src="image_6.png" /></figure>

La compatibilité entre développement durable et logiciels libres est illustrée dans le diagramme suivant avec quelques exemples.

L'utilisation et la production de logiciels libres et ouverts permettent d'éviter les développements redondants (avec une consommation d'énergie inutile) KDE eco [5.1], Collège Code Source et Science ouverte [5.2]

Consultez les 4 libertés essentielles qui définissent le logiciel libre selon Richard Stallman : [5.3] !

## Je planifie la gestion du logiciel : accroître la durée de vie

Un plan de gestion logiciel (SMP Software Management Plan) est un outil pour la pérennisation du logiciel. Les informations sur le logiciel, sur son contexte, sur ses caractéristiques, ou sur l'organisation de sa diffusion sont ainsi regroupées, mises à jour au cours du cycle de vie, et permettent d'en faire un produit modifiable et réutilisable facilement. Opidor [5.5], Presoft [5.6] (voir aussi le Data Management Plan [5.7] page 8). Je pense aussi aux principes FAIR pour le logiciel (groupe RDA) : FAIR4RS [5.8]
Prendre le temps de réfléchir à la plateforme de déploiement visée tout en considérant les contraintes du service numérique complet. Lors du futur déploiement de mon service numérique, l'adaptation aux choix techniques (infrastructure, virtualisation, protocoles...) aura une influence sur ses impacts environnementaux. Ne pas oublier de considérer également les aspects sécurité.

## Je réfléchis au déploiement du service : s'adapter au mieux au contexte

### En fonction des caractéristiques (lieu, capacités...) des plateformes disponibles :

* ordinateur, serveur local, plateforme embarquée (microcontrôleur, Raspberry-Pi...)

* plateforme spécialisée : cluster virtualisation ou spécialisé HPC, GPU, FPGA, ARM64

* une Offre De Service (ODS) de site ou de tutelles (CNRS, Universités) / clouds publics

### En fonction des contraintes du service :

* langages supportés, communications spécialisées (Infiniband, OmniPath, SpaceWire, Série...)

* goulots d'étranglement : accès disque, réseau, transferts mémoire

* pérennité, portabilité, sécurité, coûts à long terme, maintenance, temps de retour

* lieu géographique des usages, tutelles commanditaires du service

<figure><img src="image_7.png" /><figcaption>Electricity map / Intensité carbone [6,1]</figcaption></figure>

<figure><img src="image_8.png" /></figure>

Laurent Bourgès - 2022.05

<figure><img src="image_9.png" /></figure>

<figure><img src="image_10.png" /></figure>

### Quelques recommandations :

* je m'appuie sur les services mutualisés (authentification, stockage, base de données...)

* j'isole les données sur des espaces de stockages distribués et sauvegardés pour éviter la duplication

* je privilégie la virtualisation et je réduis la taille des images (VM, container) : cf schéma à droite ci-dessus

* j'estime au plus près les ressources nécessaires (vcpu, mémoire, stockage) pour éviter le surdimensionnement

* j'essaie d'estimer l'impact environnemental de mes calculs à l'avance (Green Algorithms [6.2] avec GA4HPC)

## Je n'oublie pas les aspects sécurité de mon service

De l'indisponibilité de mon service jusqu'au vol de données personnelles de mes utilisateurs (Règlement général sur la protection des données [6.3]) en passant par l'installation de logiciels malveillants sur mon infrastructure, les conséquences d'une faille de sécurité peuvent être nombreuses. L'application ou/et les données associées peuvent devenir obsolètes.

La sécurité doit être une préoccupation présente à toutes les étapes du cycle de vie d'un service numérique, et en lister les bonnes pratiques nécessiterait une plaquette à part entière. Je peux commencer par m'inspirer des recommandations de l'Agence Nationale de la Sécurité des Systèmes d'Information : l'ANSSI (C [6.4], Rust [6.5], IOT [6.6]).

Néanmoins je reste vigilant sur l'impact des mécanismes de sécurité considérés, notamment sur l'augmentation de la consommation de ressources ou du nombre d'équipements : bien prendre en compte la criticité des services pour ne pas sur-sécuriser inutilement [6.7]
Prendre le temps de choisir un langage en considérant l'efficacité énergétique, la pérennité, la simplicité et plus généralement les contraintes globales du service numérique complet.

## Je choisis mon langage et/ou ma pile logicielle : tout est affaire de compromis

Illustrations de l'efficacité énergétique en fonction du langage :

* à gauche : Simon P. Zwart, Nature Astronomy [7.1] avec une simulation N-Body, figure actualisée par P. Augier [7.2] et [7.3] mettant en évidence l'importance des compilateurs Python et des facteurs humains (optimisation du code, expertise et temps passé pour optimiser, tester et mesurer les codes),

* à droite, Rui Pereira et al, Science of Computer Programming [7.4] [7.5] basé sur le Computer Language Benchmark Game.

<figure><img src="image_11.png" /></figure>

<table><thead><tr><th>Time & Memory</th><th>Energy & Time</th></tr></thead><tbody><tr><td>C • Pascal • Go</td><td>C</td></tr><tr><td>Rust • C++ • Fortran</td><td>Rust</td></tr><tr><td>Ada</td><td>C++</td></tr><tr><td>Java • Chapel • Lisp • Ocaml</td><td>Ada</td></tr><tr><td>Haskell • C#</td><td>Java</td></tr><tr><td>Swift • PHP</td><td>Pascal • Chapel</td></tr><tr><td>F# • Racket • Hack • Python</td><td>Lisp • Ocaml • Go</td></tr><tr><td>JavaScript • Ruby</td><td>Fortran • Haskell • C#</td></tr><tr><td>Dart • TypeScript • Erlang</td><td>Swift</td></tr><tr><td>JRuby • Perl</td><td>Dart • F#</td></tr><tr><td>Lua</td><td>JavaScript</td></tr><tr><td></td><td>Racket</td></tr><tr><td></td><td>TypeScript • Hack</td></tr><tr><td></td><td>PHP</td></tr><tr><td></td><td>Erlang</td></tr><tr><td></td><td>Lua • JRuby</td></tr><tr><td></td><td>Ruby</td></tr></tbody></table>

<table><thead><tr><th>Energy & Memory</th><th>Energy & Time & Memory</th></tr></thead><tbody><tr><td>C • Pascal</td><td>C • Pascal • Go</td></tr><tr><td>Rust • C++ • Fortran • Go</td><td>Rust • C++ • Fortran</td></tr><tr><td>Ada</td><td>Ada</td></tr><tr><td>Java • Chapel • Lisp</td><td>Java • Chapel • Lisp • Ocaml</td></tr><tr><td>OCaml • Swift • Haskell</td><td>Swift • Haskell • C#</td></tr><tr><td>C# • PHP</td><td>Dart • F# • Racket • Hack • PHP</td></tr><tr><td>Dart • F# • Racket • Hack • Python</td><td>JavaScript • Ruby • Python</td></tr><tr><td>JavaScript • Ruby</td><td>TypeScript • Erlang</td></tr><tr><td>TypeScript</td><td>Lua • JRuby • Perl</td></tr><tr><td>Erlang • Lua • Perl</td><td></td></tr><tr><td>JRuby</td><td></td></tr></tbody></table>

L'usage de Python illustre le plus grand écart (~100x) en efficacité selon l'environnement d'exécution (cpython, numba, pythran, pypy) et l'optimisation du code dans ce cas d'utilisation (performance-driven development).

<figure><img src="image_12.png" /></figure>

Dans l'étude ci-dessus (C. Bonamy, L. Bourgès, L. Lefèvre [7.6], les machines à base d'ARM sont réellement efficaces quel que soit le langage considéré, et sans "portage" comme le demanderait l'utilisation de GPU. On voit aussi que deux groupes de langages se distinguent en termes d'efficacité : en tête, C, Fortran, Java et Julia, et légèrement derrière Python, Go et Rust

* langages compilés (natifs ou habituellement interprétés mais optimisés, p. ex. grâce à Numba ou PyThran pour Python) à privilégier pour les traitements lourds, haute performance ou temps réel

* langages faciles d'accès (interprétés) à privilégier pour les traitements moins contraints, afin de faciliter la maintenance, le ré-usage et ainsi la durabilité

* toutes les briques ne doivent pas forcément être écrites dans le même langage
Les études sur le stockage [8.1] ou le transport des données [8.2] permettent de se rendre compte, malgré les limites liées aux Analyse de Cycle de Vie, que ces processus ne sont pas neutres en terme d'impacts environnementaux. Garantir la reproductibilité scientifique et la réutilisation des données impose l'usage de formats interopérables et ouverts mais doit se faire dans une démarche de soutenabilité. Une politique globale de sobriété (visant la réduction en valeur absolue des impacts environnementaux) sur les données doit être systématiquement appliquée. Enfin, compte tenu du coût environnemental significatif et des ressources colossales mobilisées pour l'acquisition des données (satellites, campagne en mer par exemple), une gestion parcimonieuse, sobre et durable des jeux acquis n'est pas une option mais une nécessité.

## Je fais attention à la volumétrie : gestion parcimonieuse des données

### Stockage des données : ASCII ou formats binaires ?

Le format texte (ASCII brut, XML, YAML...) nécessite généralement plus de place pour stocker la même information. Par contre lorsqu'on versionne les fichiers, le phénomène peut s'inverser (stockages successifs vs. stockage différentiel). Il y a un fort risque d'obsolescence lié à l'utilisation des formats binaires propriétaires (non ouverts). Des formats binaires ouverts tels que NetCDF [8.3] ou HDF5 [8.4] couplés à des conventions d'utilisation comme Climate forecast convention [8.5] permettent d'emporter à la fois les données et méta données rendant les jeux de données « autonomes » et réutilisables.

### Volumétrie importante : limiter les transferts

* je privilégie le traitement au plus près des données (serveur)

* je tiens compte de la volumétrie et de la localisation des données manipulées pour concevoir les traitements

* je minimise la volumétrie des jeux de données et j'élimine les dépendances superflues

## Je planifie la gestion des données : durabilité, reproductibilité et contribution aux communs

Suivre le principe FAIR peut aider à réduire l'empreinte environnementale pour plusieurs raisons :

<figure><img src="image_13.png" /></figure>

source : SangyaPundir CC BY-SA 4.0

* **Interopérabilité** : les données doivent être faciles à combiner avec d'autres jeux de données, à la fois par les humains et par les systèmes informatiques. Rendre les données interopérables permet d'éviter de multiplier les logiciels pour les manipuler et de multiplier les données avec des formats différents : diminution du nombre de données et du coût de conversion, retro compatibilité facilitée, optimisation des logiciels dédiés.

* **Open Data / Reproductibilité** : rendre les données et les codes sources facilement accessibles (référence DOI pérenne) et reproductibles permet de réduire l'empreinte environnementale en évitant des doublons. Moins de stockage (utilisation de web-services), moins de développement redondant. C'est également respecter le coût environnemental souvent important de l'acquisition des données.

De nombreuses ressources existent : Force11 principes FAIR [8.6] / directive européenne [8.7] / European Open Science Cloud [8.8] / Research Data Alliance [8.9] ou encore cette infographie FAIR interactive [8.10] proposée par l'URFIST Méditerranée.

Les objectifs souvent cités d'un plan de gestion de données (DMP) [8.11] de la recherche sont les suivants :
améliorer l'impact des projets de recherche et leur contribution scientifique, et même satisfaire les exigences de financeurs. Un plan correctement fait, intégrant la réflexion sur les impacts des données à chaque étape de leur cycle de vie permettra d'aboutir à des données FAIR et apportera quelques avantages environnementaux.
Quelques exemples de DMP sur le site OPIDoR [8.12].

Le Règlement Général sur la Protection des Données [8.13] définit un cadre strict sur la collecte des données personnelles à minima, ainsi que leur durée de rétention et de conservation la plus courte. On pourra également se référer au règlement Européen sur les données : le Data Act [8.14]. Voir aussi l'Atelier des données [8.15], leur guide de gestion de données [8.16], la plateforme de formation DORANum [8.17] et CADOR (Univ. Lyon) [8.18]
Analyser et superviser mon service numérique afin d'identifier les briques logicielles et les fonctions les plus consommatrices.

## J'analyse mon code : **identifier a priori**

* les analyses statiques permettent, entre autres, de déterminer la difficulté de maintenance d'un logiciel (exemples d'outils : Sonarqube, codacy)

* les analyses dynamiques permettent de quantifier l'usage des ressources (exemples outils : gcov, gprof, perf, valgrind)

Ces analyses de logiciel - qui font partie des bonnes pratiques classiques - sont indispensables afin de réduire l'impact d'un service numérique.

## Je mesure : **identifier les performances et les impacts environnementaux en fonctionnement**

* mesures de performance ; temps de chargement / temps d'exécution, taille des données, nombre de requêtes

* estimations des émissions carbone web (Ecoindex, CarbonAnalyser, GreenSpector, voir fiche page 17)

* mesures de la consommation électrique : en fonction des langages, des équipements utilisés, des protocoles réseau (par exemple dans l'IOT)

* estimations des impacts environnementaux à l'usage

Exemples d'outils pour vos calculs scientifiques sur la fiche Calcul Scientifique page 16.

## Un focus : je profile la consommation énergétique des logiciels

Chaque usage de ressource (processeur, mémoire, espace de stockage, réseau) dans mon logiciel provoque une consommation électrique.

Pour mesurer l'impact énergétique des logiciels en phase d'usage :
besoin d'équipements matériels (PDU, wattmètres) ou de sondes logicielles (powerAPI [9.1], Scaphandre [9.2], Energy Scope [9.3], allumet [9.4]).

<figure><img src="image_14.png" /></figure>

<figure><img src="image_15.png" /><figcaption>Wattmètre Watts'up Pro - PDU Eaton</figcaption></figure>

Je profile la consommation électrique dans le temps, pour découvrir les différentes phases intensives de mon logiciel.

<figure><img src="image_16.png" /><figcaption>Comparatif wattmètres logiciel et matériels entre CPU et GPU sur benchmarks</figcaption></figure>

source : Mathilde Jay, Vladimir Ostapenco, Laurent Lefèvre, Denis Trystram, Anne-Cécile Orgerie, et al. An experimental comparison of software-based power meters: focus on CPU and GPU. Conférence CCGrid, Mai 2023 [9.5]
Optimiser son logiciel, comme implémenter des algorithmes efficaces et les structures de données adéquates, permet de réduire le temps d'exécution, ce qui conduit en général à une réduction de la consommation électrique, et donc à une réduction des émissions eqCO2. Mais attention à l'effet rebond, et aux effets sur les autres éléments du service numérique. De même il faut être vigilant lorsque l'on applique les bonnes pratiques usuelles en ingénierie logicielle (gestion de version, intégration continue). Il faut les appliquer, mais avec des précautions (oui, mais....).

## J'optimise et j'améliore mon code (oui mais...)

L'amélioration est un problème multifactoriel : architecture, utilisation des ressources processeur, mémoire, stockage et trafic réseau. L'utilisation d'un levier d'amélioration peut nuire à l'usage d'une autre ressource. Par exemple :

* un système de cache permet d'accélérer les traitements, mais aura des impacts sur la mémoire, le stockage et la complexité accrue du logiciel

* utiliser la compression pour réduire le trafic réseau augmente légèrement l'utilisation du CPU

### Attention à l'effet rebond [10.1] :

<figure><img src="image_17.png" /></figure>

* optimiser un logiciel peut induire à lancer davantage d'opérations ou traiter davantage de données, donc l'empreinte écologique du service ne sera pas réduite (Paradoxe de Jevons).

* l'optimisation devrait servir simplement à réduire la consommation énergétique et des ressources, et si possible d'arriver plus vite au résultat. Chaque exécution a un impact !

* il est primordial de n'optimiser que ce qui a le plus d'impact (Loi de Pareto).

* il ne faut pour autant pas négliger la qualité des tests dans le processus d'optimisation (régressions).

* l'exemple de l'usage de l'IA est pertinent pour illustrer le mécanisme de l'effet rebond Luccioni [10.2]. Des bonnes pratiques pour tenter d'éviter cet effet sont présentées dans le rapport frugal AFNOR [10.3].

## Je pense à mes données

La gestion des données pendant la phase d'usage influe directement sur les performances que l'on va obtenir du service numérique déployé : format des fichiers (binaire ou textuel), support de stockage (SSD vs HDD, mais aussi le choix du type de file system), localisation géographique par rapport aux traitements, lectures et écritures multiples peuvent fortement influer sur les résultats.

## Gestion de version (oui mais...)

J'utilise un outil de gestion de version, mais :

* j'évite ou limite d'y stocker les paquets binaires et les jeux de données non indispensables ; et si il y a un réel besoin de fichiers binaires et/ou de fichiers volumineux, j'utilise git-lfs [10.4]

* je ne place pas en gestion de version les produits de compilation ni les fichiers de sortie

## Intégration continue (oui mais...)

* je réfléchis à mon Intégration Continue (CI). Je choisis un docker de taille minimum, et j'active ma CI uniquement sur certaines branches et j'envisage une exécution programmée. Ainsi je n'exécute pas tous les tests et ne produis pas tous les fichiers à chaque modification

* je surveille la durée des jobs, leur nombre, la taille des artefacts, le trafic réseau

* je privilégie les forges mutualisées (choix avec catopidor [10.5])
L'écoconception d'un service numérique doit prendre en compte les impacts liés au déploiement et à la production.
L'amélioration continue permet de réduire les impacts environnementaux.

## Déploiement : **sobriété numérique**

* je privilégie un hébergement mutualisé, labellisé COC (Code Of Conduct), au plus près des données et des utilisateurs

* je privilégie la virtualisation (moins de serveurs physiques), en minimisant l'empreinte mémoire et disque (taille des machines virtuelles, des containers), sauf cas particuliers (calcul haute performance)

* je fais attention à certains effets rebond : j'évite la multiplication des machines virtuelles, des instances du service

## Production : **amélioration continue en fonction des usages**

* j'exploite la supervision (et les alertes) pour observer les pics CPU, ressources utilisées (disque, réseau), consommation électrique

* je modifie le service numérique pour l'adapter en fonction de l'usage observé (amélioration continue)

* je réduis les fréquences et volumes des sauvegardes, j'adopte la déduplication

Exemples d'outils de supervision : top, vmstat, zabbix, scalasca, nagios, prometheus, grafana

<figure><img src="image_18.png" /><figcaption>Exemples d'outils utilisés pour l'amélioration continue du service numérique</figcaption></figure>

(source : PNGEgg, adaptée par C. Bonamy)
L'écoconception d'un service numérique doit prendre en compte les impacts liés à la distribution, l'utilisation et l'administration du logiciel, sans oublier les besoins des utilisateurs. Il faut s'assurer que l'efficacité énergétique et la réduction des impacts environnementaux sont conservées avec les évolutions du logiciel.

## Je traque les ressources inutiles : éviter le gaspillage énergétique

### La consommation statique des machines est importante : j'éteins les machines si possible

Le logiciel influence la consommation dynamique des machines, mais il y a peu de proportionnalité énergétique (un serveur inoccupé peut consommer 50 % de son budget électrique).

La consommation statique d'un serveur ou d'un équipement réseau est importante

<figure><img src="image_19.png" /><figcaption>Luiz André Barroso and Urs Hölzle, "The case for Energy-Proportional Computing", IEEE Computer, 2007 [12.1]</figcaption></figure>

<figure><img src="image_20.png" /></figure>

### Mise en place de systèmes de mise en veille

* j'éteins les machines virtuelles qui ont une empreinte mémoire et CPU

* je limite le nombre de services déployés

* je favorise les extinctions d'hôtes et de ressources (cœurs de calcul, systèmes de stockage) inutilisés

## Je distribue et maintiens mon code :
favoriser la durabilité et la simplicité

### Diffusion

* je dépose le logiciel en un endroit unique et facilement accessible, une forge ou un dépôt dédié (diffusion et pérennité logiciel COSO [12.2])

* je privilégie les publications open source. Licences et les démarches : plaquette licence [12.3] et etalab [12.4]

### Gestion des mises à jour

* je réduis la taille des produits logiciels

* je rationalise leur nombre et leur fréquence

* j'assure une rétrocompatibilité autant que possible

* je veille à éviter l'ajout constant de fonctionnalités

* je définis clairement le workflow des mises à jour

* je prévois une politique de mises à jour correctives de type Long Term Support (LTS) [12.5]

## Je sensibilise : améliorer les usages

* en m'appuyant sur les ressources existantes :

* Ecoinfo [12.6]

* ADEME [12.7]

* posters sobriété numérique irit [12.8]

* Mooc Impacts environnementaux du numérique [12.9]

* la fresque du numérique [12.10]

* cafeia et environnement [12.11]

* en affichant des informations de suivi de consommation

* en proposant des TP ecoconception [12.12], [12.13] aux développeurs de mon service numérique
Un service numérique qui n'est plus utilisé va continuer à générer des impacts résiduels sur l'environnement à cause, par exemple, du stockage de ses données, de son hébergement, des accès réseaux réguliers à d'autres services numériques nécessaires à son fonctionnement, etc. Il est donc plus qu'important de traiter sa fin de vie, comme n'importe quel produit.

## J'archive : favoriser la durabilité

* je déclare le code source auprès de Software Heritage [13.1] / HAL Software [13.2]

* j'archive mes données auprès des services relevant de ma thématique scientifique, les pôles de données de Data Terra [13.3] ou Recherche Data Gouv [13.4] par exemple.

* je m'interroge sur la licence à utiliser pour archiver ses données et mon code. De nombreuses recommandations sont disponibles sur le site d'Etalab [13.5] à ce sujet.

* je sauvegarde sur un stockage froid les données essentielles (= ayant de la valeur ou une obligation juridique) : traces d'exécutions réglementaires, données spécifiques, documentation, etc.

## Je mets hors service : éviter les logiciels et les données « Zombies »

### Les utilisateurs

* je préviens l'ensemble des utilisateurs et je m'assure que la fin de vie ne va pas avoir d'effet de bord indésirables : repli sur des solutions plus énergivores, mise en place de processus alternatifs ayant d'autres impacts environnementaux plus importants, etc.

### La documentation

* je supprime l'ensemble des données concernant le logiciel ... et je signale la fin de vie du logiciel dans l'espace documentaire qui lui était dédié.

### Les outils de support

* je mets à jour les configurations des outils permettant le support et les évolutions (files helpdesks, outil de suivi de version, etc.) afin de supprimer toute file active inutile et de nettoyer les données concernant le service numérique arrêté.

### Les données

* je supprime les données stockées après archivage : bases de données et fichiers plats.

### Le logiciel

* je supprime l'installation du logiciel sur toutes les instances (environnements de développement/qualification/production et le cas échéant, des postes de travail).

### Les sauvegardes

* je supprime l'ensemble des sauvegardes journalières/hebdomadaires/mensuelles nécessaires au plan de reprise d'activité.

### Les services nécessaires

* j'arrête et je désinstalle les services applicatifs qui n'étaient utiles que pour l'exécution du logiciel (Apache, Nginx, mysql, etc.).

### Les machines virtuelles et containers

* j'arrête les containers et machines virtuelles qui n'étaient pas mutualisées avec d'autres services, et je supprime leurs images. Les arrêter peut permettre d'éteindre une partie de l'infrastructure physique.

### La supervision

* je supprime les références au logiciel dans les configurations des outils de supervision ainsi que l'ensemble de ses traces d'exécution.

### Les dépendances mutualisées

* je vérifie que les éventuelles dépendances mutualisées (bibliothèques logicielles, assets JS ou CSS, etc.) sont encore utiles à au moins un autre service numérique, sans quoi je les supprime également.

### La cartographie applicative

* je supprime la partie concernant le logiciel en fin de vie dans la cartographie applicative de l'équipe ou de l'établissement afin de conserver une urbanisation du système d'information représentative de la réalité.
Je maîtrise le nombre de fonctionnalités logicielles : **éviter l'obésiciel**

Je favorise le libre : **réutiliser des briques logicielles et contribuer aux communs**

Je planifie la gestion du logiciel : **accroître la durée de vie**

Je réfléchis au déploiement du service : **s'adapter au mieux au contexte**

Je n'oublie pas les aspects sécurité de mon service

Je choisis mon langage et/ou ma pile logicielle : **tout est affaire de compromis**

Je fais attention à la volumétrie et aux formats utilisés : **gestion parcimonieuse des données**

Je planifie la gestion des données : **durabilité, diminution des développements redondants**

J'analyse mon code : **identifier a priori**

Je mesure : **identifier en fonctionnement (perf et empreinte carbone)**

Un focus : je profile la consommation énergétique des logiciels

J'optimise mon code (**oui mais...**)

Gestion de version (**oui mais...**)

Intégration continue (**oui mais...**)

Déploiement : **sobriété numérique**

Production : **lkeuonfocuon et noitcenn**

Je distribue et maintiens mon code : **favoriser la durabilité et la simplicité**

Je sensibilise : **lkeuonfocuon les usages**

Je distribue et maintiens mon code : **favoriser la durabilité et la simplicité**

J'archive : **favoriser la durabilité et la réutilisation**

Je mets hors service : **éviter les logiciels et les données « Zombies »**

Avant

Pendant

Après
Je réfléchis à l'intérêt de mon calcul. Je m'assure qu'aucun code existant et réutilisable ne réponde à mes besoins. Je conçois l'ensemble du workflow (données d'entrée, traitement, post-traitement, stockage) en pensant aux impacts environnementaux (coût des transferts réseaux, du stockage...), en ne cédant pas à l'IA sans réflexion préalable.

## Avant de développer :

> Je ne pense pas : "c'est un petit code, ça ne servira qu'à moi, ces bonnes pratiques ne me sont pas destinées".

* j'alerte les commanditaires et les développeurs des impacts des calculs sur l'environnement, en m'appuyant sur les études existantes (ADEME [15.1], étude Ecoinfo Conso IA [15.2])

* j'évalue l'impact dès le départ (méthodologie impact calcul et stockage MesoNET [15.3], évaluation environnementale de projets IA [15.4])

* je clarifie le besoin fonctionnel pour éviter d'intégrer des solutions inutilement impactantes (fonctions superflues, pertinence de l'intégration de l'IA...)

* je ne redéveloppe pas ce qui existe déjà : recherche sur les dépôts, questions à poser sur les listes Calcul, DevLOG...

* dans le cas d'usage d'un modèle d'IA, je me renseigne sur les pratiques d'IA frugale AFNOR [15.5], et sur les modèles les plus parcimonieux (complexité algorithmique plus faible) et les plus adaptés à mes données

* je choisis l'infrastructure adaptée pour chaque phase (laboratoire pour développement, méso-centre pour mise au point et validation Liste ESR [2.2], centre de calcul national pour production GENCI [2.3])

* je réfléchis à l'optimisation de mon workflow (localisation post-traitements, localisation des données...)

* j'établis un plan de gestion des données (DMP) ; je considère des formats ouverts et efficaces pour les données de sortie du logiciel

## Quelques outils :

Estimation en ligne de la consommation d'énergie et de l'empreinte carbone associées à une expérience numérique :

* Green Algorithms [15.6] (Lannelongue et al.), version HPC avec Green Algorithms for HPC [15.7]

* ML CO2 Impact [15.8] (Lacoste et al.) un outil en ligne qui permet de calculer la consommation d'énergie et l'empreinte carbone associée à partie des informations suivantes : type de matériel, durée d'exécution, fournisseur des équipements et localisation.

## Au tout début du développement :

* je choisis la licence (si possible ouverte afin de faciliter le ré-usage et la reproductibilité)

* je crée un dépôt structuré (src, tests, bin, doc, model si IA...) en ajoutant dès la création les fichiers "AUTHORS", "LICENSE", "README »

* j'utilise des bibliothèques éprouvées de haut niveau (pour le machine learning : scikit-learn, Tensorflow, Pytorch Lightning...)

* je choisis les normes et API adaptées (MPI, OpenMP, OpenACC, OpenCL)

* je mets en place l'intégration continue (Gitlab pipeline, Github Actions...), sans excès inutiles

* je mets en place des mécanismes de reprise automatique des calculs (checkpoint/restart)

* je m'assure de la qualité et de la pertinence des données utilisées pour l'entraînement de modèles (Inria science des données [15.9], article data et IA [15.10]) ou j'essaie d'utiliser des algorithmes robustes et compatibles avec des données incomplètes ou hétérogènes (dirty data project [15.11])
Pendant le développement, je mesure et optimise l'empreinte carbone de mon code (outils dédiés, optimisation CPU/GPU, limitation des transferts mémoire, suppression des données inutiles) tout en assurant portabilité, performance et partage transparent des sources. En fin de vie, je conserve uniquement les données et codes nécessaires à la reproductibilité, en respectant les principes FAIR et en les déposant dans des archives pérennes.

## Pendant le développement :

> Je ne pense pas : "c'est un petit code, ça ne servira qu'à moi, ces bonnes pratiques ne me sont pas destinées".

* je mesure l'empreinte carbone avec des outils dédiés

* je recherche le meilleur compromis entre temps de retour, finesse du calcul et coût eqCO2

* j'effectue une recherche des parties les plus coûteuses en performance avec des outils (gprof, valgrind, ...)

* je me fais aider pour optimiser (exemple : Performance Optimisation and Productivity [16.5]) tout en faisant attention à l'effet rebond (toujours plus !)

### Attention à l'effet rebond

<figure><img src="image_21.png" /></figure>

* si je code sur GPU : la clé des accélérateurs est de réfléchir à uniformiser (pas de conditions (if/else), pas d'hétérogénéité entre les cœurs) et maximiser les traitements sur l'accélérateur (GPU) afin d'éviter les transferts mémoire CPU vers GPU (attention au temps de transferts mémoire CPU/GPU vs kernel time)

* je fais du code portable et performant (attention à trop de spécificités avec un type d'accélérateur, comme par exemple CUDA)

* si j'utilise l'IA générative pour développer et optimiser mon code, voir la fiche page 17

* je pense à supprimer les données dès que celles-ci ne sont plus utiles

* je diffuse les sources, partage le dépôt, mets à jour la documentation dès que possible

## Quelques outils

* Experiment impact tracker [16.1] (Henderson et al.) : une bibliothèque Python qui calcule la consommation d'énergie à partir des informations GPU, CPU et DRAM

* Carbon tracker [16.2] (Anthony et al.) : également une bibliothèque Python qui calcule la consommation d'énergie à partir des informations GPU, CPU et DRAM. Dans le cas de calculs d'IA, il permet d'arrêter l'entraînement d'une expérience quand un coût environnemental fixé est dépassé

* Code Carbon [16.3] : une troisième bibliothèque Python fondée sur le même principe que les précédentes

* ImpactHPC [16.4] : une bibliothèque Python pour mesurer et comprendre l'empreinte environnementale du calcul scientifique, avec les indicateurs suivants : déplétion métaux (g Sb eq), énergie primaire (MJ) et impact climatique (gCO2eq)

## Après, pendant les phases de production :

* j'analyse la scalabilité de mon code, idéalement sur l'infrastructure d'utilisation finale (Loi d'Amdahl [16.6])

* j'adapte mon code en fonction de l'infrastructure matérielle (éviter l'obsolescence du code)

* je sensibilise les utilisateurs aux impacts environnementaux de leurs calculs GES Labos1.5 heures calcul [16.7]

## Après, fin de vie :

* je supprime les données non essentielles ; je ne conserve que le minimum pour la reproductibilité, dans un format FAIR, dans le respect de la règlementation des données

* je diffuse mon code en suivant également le principe FAIR (FAIR4RS [5.7]) dans des dépôts dédiés software heritage [13.1] / HAL Software [13.2]) en précisant le statut (non maintenu...)
L'Intelligence Artificielle générative (IAg) désigne une classe d'algorithmes capables de produire du texte, du code, des images, des vidéos ou d'autres médias en réponse à des requêtes utilisateur [17.1]. Son adoption croissante, notamment via des agents polyvalents (comme Vibe [17.2]), s'étend désormais à toutes les étapes du cycle de vie du logiciel : développement, compilation, intégration continue (CI), génération de documentation, ou encore optimisation de workflows. Ces usages (journée DevLOG IA4Dev [17.3], thèse sur l'IAg pour le code [17.4]) soulèvent cependant des enjeux majeurs. Au-delà des gains de productivité, nous insistons sur la nécessité d'intégrer ces pratiques dans une démarche d'éco-conception logicielle, en étant conscient des impacts socio-environnementaux résultants. Par ailleurs, des points de vigilance transverses doivent être considérés : éthique des usages, préservation des compétences humaines, sécurité des systèmes, ou encore gestion de la propriété intellectuelle — des aspects d'autant plus critiques dans un contexte académique et de recherche.

## Je suis conscient du coût environnemental de l'IAg

À l'échelle mondiale, la consommation d'électricité des centres de données en phase d'usage continue de décoller

Pour atteindre en 2030, entre 1250 et 1500 TWh : une multiplication par 3 par rapport à 2023.

<figure><img src="image_22.png" /></figure>

Trois dynamiques :

Phénomène IA générale

Usages traditionnels : hébergement site web, réseaux sociaux, plateformes vidéo, cloud

Deux scénarios :

Scénario de déploiement indifférence de foffre de calcul et de son adoption générale

Scénario tendanciel : taux de croissance maintenu à 13 % (valeur 2019-2024)

Proche d'une projection à horizon 2027 - 2028 :

Investissements déjà engagés, permis et raccordements accordés, infrastructures en cours de construction

De nombreuses références documentent cet impact (ACV service IAg [17.5], outil comparia [17.6], ecologit calculator [17.7], cafeia.org [17.8], coût d'un prompt [17.9]), avec un consensus sur l'importance de cet impact sur les émissions GES, la consommation d'eau, l'extraction des ressources minérales ou l'artificialisation des sols, et le risque de conflit d'usage avec la transition énergétique.

(source : The Shift Project 2025 [3.10])

## Je suis conscient de l'impact sociétal de l'IAg :

L'IAg pose d'importants défis sociétaux. Parmi ceux-ci figurent notamment l'exploitation de travailleurs précaires [17.10], souvent chargés de l'annotation des données et de l'entraînement des modèles, ainsi que la diffusion de fausses informations, qu'elle soit involontaire ou délibérée, par la reproduction et l'amplification des biais présents dans les données. Le Mooc IA et société [17.11] et le GDR Internet IA et Société [17.12] fournissent des ressources et des pistes de réflexions sur le sujet.

## Je suis conscient de l'impact cognitif de l'IAg :

Il paraît incontournable de proposer des enseignements de développement logiciel sans IAg pour continuer à se confronter à la complexité [17.13], éviter une perte d'expertise [17.14], et un déclin cognitif [17.15], [17.16]

## J'agis en préservant mes compétences en développement logiciel :

* je conserve un esprit critique sur les réponses de l'IAg, afin d'éviter des développements erronés à corriger ultérieurement (coût redondant), en particulier avec le vibe coding [17.17]

* j'essaie de rédiger des prompts plus efficaces [17.18] lors de l'utilisation de l'IAg pour coder (afin notamment de réduire le coût global de la requête), voir aussi les formations IA4Dev [17.19]

* j'utilise l'IAg avec le maximum de parcimonie

## Je privilégie les IAg institutionnelles :

Le Retrieval Augmented Generation (RAG) permet d'améliorer la traçabilité de l'information et de réduire le risque d'hallucinations par rapport à la simple utilisation d'un modèle d'IA générative Architecture de type RAG [17.20], RAGaRenn [17.21], Emmy CNRS [17.22], article sur les IAg académiques existantes [17.23]

## Je reste vigilant et sobre, même avec les IAg institutionnelles :

Outre le risque de potentielle fuite de données, l'IAg peut injecter des codes malveillants si le modèle a été détourné (ANSSI AI coding [17.24], cyber gouv [17.25]).

## Je fais attention aux données que j'injecte dans les outils d'IAg, et notamment :

* aux données sensibles, aux données personnelles CNIL IA RGPD [17.26], aux données industrielles, aux données sous licences non ouvertes
## Avant de développer :

Je m'imprègne du Référentiel Général d'Ecoconception de Services numériques [18.1] et je les diffuse aux autres participants du projet, notamment aux représentants de la maitrise d'ouvrage (MOA, Product Owner) et du design des interfaces (UX/UI). J' invite notamment les designers à s'imprégner du Guide [18.2] réalisé par les designers éthiques. L'écoconception de développement web n'est pas une démarche individuelle ni purement technique, elle nécessite de mobiliser toute l'équipe impliquée dans le projet.

En effet, les gains les plus importants sur le développement Web se font :

* en économisant les fonctionnalités, donc en impliquant les donneurs d'ordre et les utilisateurs pour aller vers l'essentiel

* en simplifiant au maximum les interfaces utilisateurs, dans un esprit de sobriété

* en limitant les éléments générant du trafic et de l'utilisation CPU sur les terminaux comme les animations CSS et javascript, les vidéos, les traceurs, les jeux de données, les graphiques, etc.

D'une manière générale, j'élimine des spécifications tout contenu ou fonctionnalité non-essentiels. Le service doit être utilisable sur un petit écran, et si possible réactif (responsive). Je proscris l'utilisation de tout type de Dark Pattern [18.3].

Lorsque je commence le développement, je vais faire un tour sur le site du référentiel de bonnes pratiques d'écoconception web [18.4].

Je me préoccupe de la sécurité à toutes les étapes du cycle de vie, et je me familiarise avec les recommandations de l' ANSSI sur la sécurisation d'un site Web [18.5].

## Pendant le développement :

Je pilote la qualité du développement à partir d'indicateurs d'impacts environnementaux sur les terminaux. Pour ce faire, j'utilise si possible un outil de mesure (type Greenspector [18.6] *), ou à défaut d'évaluation de l'impact environnemental de mon site (type eco index [18.7], ecoindex_revisited [18.8], extension Firefox CarbonAnalyser [18.9], Fruggr [18.10]* ou Greenframe [18.11]*). J'ajoute, si possible, l'appel à ce type d'outils dans ma chaîne d'intégration continue, en complément des outils de développement intégrés à mon navigateur que j'utilise au quotidien.

* Outils (partiellement) payants

Je planifie la gestion des données au plus proche du besoin, et j'applique le principe F.A.I.R [18.12].

J'anticipe la compatibilité et la maintenabilité sur le long terme. Je privilégie des technologies pérennes maintenues par des communautés actives et établies, pour éviter l'obsolescence du code produit. Je fais attention aux dépendances inutiles de l'application ou des frameworks utilisés.

Je limite les accès réseaux et les transferts de données au strict minimum : je rends ainsi mon service accessible pour des connexions à faible débit, et dans l'idéal résilient aux déconnexions.

J'écris un code simple à comprendre et à mettre en œuvre, il sera aussi plus durable et plus facile à faire évoluer. C'est la base du principe KISS [18.13] : Keep It Simple and Stupid.

## Après, pendant les phases de production :

Je choisis un hébergeur labellisé Code of Conduct [18.14], présentant l'indicateur d'efficacité énergétique le plus fort possible et au plus proche géographiquement de mes utilisateurs cible.

Je mets en place une politique de sauvegarde des données sobres.

Je supervise le service (CPU, IO) et les journaux (un an maximum).

J'anticipe les usages : je suis vigilant à la transformation des comportements potentiellement induits par mon application, et je l'adapte afin de réduire leurs impacts négatifs.
## Comment éco-concevoir des plateformes embarquées et objets connectés ?

* un livre blanc ACV d'un système embarqué a été proposé par l'association Embedded France [19.1] avec une liste de bonnes pratiques (simplification du système, gestion du mode de veille, optimisation de l'alimentation, optimisation thermique, utilisation des énergies renouvelables...) et leurs limites.

* le codage des nombres a un impact direct sur les performances et donc sur la consommation. Choisir la bonne représentation (virgule flottante vs fixe) et la bonne taille permet de diminuer la fréquence processeur, voire d'utiliser un processeur moins puissant.

* les objets connectés échangent beaucoup de données par internet, à volume de données finales échangées identique certains protocoles ajoutent plus ou moins de données superflues (ex. MQTT, HTTP, XMPP) protocoles IOT [19.2]

* l'architecture logicielle (interruptions vs. attente active, buffers circulaires, optimisation) a un impact direct sur la charge processeur.

## Comment assurer la pérennité d'une application pour mobile ?

Les recommandations des fiches précédentes s'appliquent également au développement d'applications pour mobiles, en gardant en tête qu'il vaut toujours mieux éviter l'installation d'une surcouche logicielle sur le terminal de l'utilisateur, qui pourrait être responsable d'une obsolescence induite sur son matériel.

Je privilégie donc la piste de l'application web plutôt que mobile.

La compatibilité d'un service numérique se construit dans la durée en demeurant utilisable sur les équipements anciens ou exotiques.

## À l'extrême

Il existe des technologies particulièrement peu consommatrices en énergie, des « low-techs » poussées à l'extrême :

* CollapseOS [19.3] : un système fonctionnant sur des microcontrôleurs

* Lowtech Magazine [19.4] : hébergement d'un site web uniquement visible si la production d'énergie solaire est suffisante

* Lowtech Lab [19.5] : serveur modulable autoalimenté en réemploi

## Aller plus loin : compatibilité science ouverte et réduction de l'impact environnemental

L'ouverture des données par les principes FAIR permet-elle vraiment de diminuer leur impact environnemental ?

La question mérite d'être posée, car établir un bilan strictement environnemental demeure complexe.

On répondra positivement pour la manipulation et l'échange des données quand on utilise des formats ouverts et adaptés aux types de données. L'ouverture contribue également à valoriser le coût environnemental, souvent élevé, de l'acquisition initiale des données (satellites ou campagnes océanographiques par exemple) en permettant leur réutilisation et en évitant des collectes redondantes. Elle présente en outre des bénéfices pour la reproductibilité scientifique, la diffusion et l'accessibilité à la connaissance pour tou-te-s.

Cependant, la disponibilité accrue des données favorise l'émergence de nouveaux usages (IA ou projets de croisements des données par exemple). On retrouve cette question à l'identique avec les logiciels libres. De manière générale, toutes les méthodes qui contribuent à une forme d'efficacité sont potentiellement soumises à un usage en croissance susceptible de contrebalancer cette efficacité (notamment les gains environnementaux).

Or, l'ouverture et la normalisation sont clairement une forme d'efficacité soumise à l'effet rebond.

Même si les enjeux sur le savoir et la démocratie méritent certainement ici de pencher en faveur de l'ouverture des données et du logiciel, il semble important de ne pas éluder la question des usages et de leurs impacts environnementaux.
[1.1] https://ecoinfo.cnrs.fr/

[1.2] https://cnrs.hal.science/hal-02083801/

[1.3] https://hal.science/hal-02400300/

[1.4] https://hal.science/hal-02399517/

[2.1] https://learninglab.gitlabpages.inria.fr/mooc-impacts-num/mooc-impacts-num-ressources/Partie3/FichesConcept/FC3.4.2-bonnespratiques-MoocImpactNum.html#les-impacts-humains

[2.2] https://groupe-calcul.cnrs.fr/pages/mesocentres_en_france.html

[2.3] https://www.genci.fr/

[2.4] https://www.eco-conception.fr/static/analyse-du-cycle-de-vie-acv.html

[2.5] https://www.eco-conception.fr/static/fonction-unite-fonctionnelle-acv.html

[3.1] https://www.arcep.fr/uploads/tx_gspublication/pour-un-numerique-soutenable_edition2025_infographies.pdf

[3.2] https://ecoresponsable.numerique.gouv.fr/actualites/actualisation-ademe-impact/

[3.3] https://ecoinfo.cnrs.fr/

[3.4] https://www.greenit.fr/empreinte-environnementale-du-numerique-mondial/

[3.5] https://institutnr.org/inr-numerique-responsable

[3.6] https://ecoresponsable.numerique.gouv.fr/a-propos/

[3.7] https://boavizta.org/

[3.8] https://infos.ademe.fr/industrie-production-durable/2026/consommation-electrique-des-data-centers-5-scenarios-pour-demain

[3.9] https://theshiftproject.org/publications/intelligence-artificielle-centres-de-donnees-rapport-final/

[3.10] https://ecoinfo.cnrs.fr/wp-content/uploads/2019/09/Informatique-et-développement-soutenable-LIMSI.pdf

[3.11] https://ecoinfo.cnrs.fr/wp-content/uploads/2026/02/Flyer-DEEE-EcoInfo_2026.pdf

[3.12] https://www.dell.com/fr-fr/lp/dt/product-carbon-footprints

[3.13] https://base-empreinte.ademe.fr/donnees/jeu-donnees

[3.14] https://www.delltechnologies.com/asset/en-us/solutions/business-solutions/briefs-summaries/dell-pcf-calculator-whitepaper.pdf

[3.15] https://alliancegreenit.org/media/ressource-projet-greenit/resilio-aguaro-whitepaper-rdb-vs-pcf-fr-20241025-web.pdf

[3.16] https://agirpourlatr transition.ademe.fr/particuliers/bureau/deplacements/calculer-emissions-carbone-trajets

[3.17] https://www.groupe-sncf.com/fr/engagements/developpement-durable/preserver-planete/calcul-empreinte-carbone

[3.18] https://www.izi-by-edf-renov.fr/blog/classes-consommation-energetique

[3.19] https://pastel.hal.science/ICI-LAB/hal-04728710

[3.20] https://ecolab.ademe.fr/apps/transport

[5.1] https://eco.kde.org/fr/be-green/

[5.2] https://www.ouvrirlascience.fr/college-codes-sources-et-logiciels/?menu=3

[5.3] https://fr.wikipedia.org/wiki/Logiciel_libre

[5.4] https://ll-dd.ch/logiciels-durables/#convergence

[5.5] https://dmp.opidor.fr/

[5.6] https://www.france-grilles.fr/wp-content/uploads/2018/04/ModeleSMP_PRESOFTV3.2.pdf

[5.7] https://hal.science/hal-01241196

[5.8] https://scienceouverte.unistra.fr/websites/science-ouverte/science_ouverte/fichiers_22/RDA_Unistra_reco_FAIR4RS_v2.pdf

[5.9] https://ll-dd.ch/

[6.1] https://app.electricitymap.org/map

[6.2] https://www.green-algorithms.org/

[6.3] https://www.cnil.fr/fr/reglement-europeen-protection-donnees

[6.4] https://messervices.cyber.gouv.fr/guides/regles-de-programmation-pour-le-developpement-securise-de-logiciels-en-langage-c

[6.5] https://messervices.cyber.gouv.fr/guides/regles-de-programmation-pour-le-developpement-dapplications-securisees-en-rust

[6.6] https://messervices.cyber.gouv.fr/guides/approche-ssi-pour-linternet-des-objets-industriels

[6.7] https://www.sti.uniurb.it/events/sfm10qapl/slides/katinka_slides.pdf

[7.1] https://arxiv.org/pdf/2009.11295.pdf

[7.2] https://greenlab.di.uminho.pt/wp-content/uploads/2017/10/sleFinal.pdf

[7.3] https://rdcu.be/ciO0J

[7.4] https://doi.org/10.1016/j.scico.2021.102609

[7.5] https://github.com/greensoftwarelab/Energy-Languages

[7.6] https://hal.science/hal-03607468

[7.7] https://github.com/paugier/nbabel
[8.2] https://hal.science/hal-04197870

[8.3] https://fr.wikipedia.org/wiki/NetCDF

[8.4] https://www.hdfgroup.org/solutions/hdf5/

[8.5] https://cfconventions.org/

[8.6] https://www.force11.org/group/fairgroup/fairprinciples

[8.7] https://op.europa.eu/en/publication-detail/-/publication/7769a148-f1f6-11e8-9982-01aa75ed71a1/language-en

[8.8] https://www.ouvirlascience.fr/portail-web-de-leosc/

[8.9] https://www.rd-alliance.org/fair

[8.10] https://view.genial.ly/5d64fbbd8352350fa3d22603

[8.11] https://hal.science/hal-01241196

[8.12] https://dmp.opidor.fr/

[8.13] https://www.cnil.fr/fr/comprendre-le-rgpd

[8.14] https://eur-lex.europa.eu/eli/reg/2023/2854/oj/eng

[8.15] https://mi-gt-donnees.pages.math.unistra.fr/site/

[8.16] https://mi-gt-donnees.pages.math.unistra.fr/site/guide.html

[8.17] https://doranum.fr/

[8.18] https://www.univ-lyon3.fr/gestion-des-donnees

[9.1] https://powerapi.org/

[9.2] https://ecoresponsable.numerique.gouv.fr/publications/boite-outils/fiches/scaphandre/

[9.3] https://www.denergium.fr/

[9.4] https://alumet.dev/#logo-after-splash

[9.5] https://inria.hal.science/hal-04030223/

[10.1] https://fr.wikipedia.org/wiki/Effet_rebond_(économie)

[10.2] https://arxiv.org/abs/2501.16548v1

[10.3] https://www.boutique.afnor.org/fr-fr/norme/afnor-spec-2314/referentiel-general-pour-lia-frugale-mesurer-et-reduire-limpact-environneme/fa208976/421140

[10.4] https://git-lfs.com/

[10.5] https://cat.opidor.fr/index.php/Forge_logicielle

[12.1] https://www.barroso.org/publications/ieee_computer07.pdf

[12.2] https://hal-lara.archives-ouvertes.fr/hal-05284336

[12.3] https://hal.science/hal-02399517/

[12.4] https://www.etalab.gouv.fr/accompagnement-logiciels-libres

[12.5] https://fr.wikipedia.org/wiki/Long-term_support

[12.6] https://ecoinfo.cnrs.fr/

[12.7] https://ecoresponsable.numerique.gouv.fr/publications/ressources-ademe/

[12.8] https://www.irit.fr/exposition-sobriete-numerique/les-posters/

[12.9] https://www.fun-mooc.fr/fr/cours/impacts-environnementaux-du-numerique/

[12.10] https://www.fresquedunumerique.org/

[12.11] https://cafeia.org/ia-et-environnement/

[12.12] https://perso.ens-lyon.fr/laurent.lefevre/OMP/TP_Mesurer_comprendre_et_éco_concevoir_26_mars.pdf

[12.13] https://ecoinfo.cnrs.fr/2025/06/04/formation-eco-conception-logicielle-a-amu/

[13.1] https://www.softwareheritage.org/save-and-reference-research-software/?lang=fr

[13.2] https://doc.hal.science/deposer/deposer-le-code-source/

[13.3] https://www.data-terra.org/

[13.4] https://recherche.data.gouv.fr/

[13.5] https://www.data.gouv.fr/pages/onboarding/producteurs

[15.1] https://ecoresponsable.numerique.gouv.fr/actualites/actualisation-ademe-impact/

[15.2] https://ecoinfo.cnrs.fr/2021/06/12/consommation-energetique-de-lutilisation-de-lia/

[15.3] https://pastel.hal.science/ICI-LAB/hal-04728710

[15.4] https://hal.science/hal-03853135/

[15.5] https://www.boutique.afnor.org/fr-fr/norme/afnor-spec-2314/referentiel-general-pour-lia-frugale-mesurer-et-reduire-limpact-environneme/fa208976/421140

[15.6] https://www.green-algorithms.org/

[15.7] https://github.com/GreenAlgorithms/GreenAlgorithms4HPC

[15.8] https://fr.wikipedia.org/wiki/OpenMP

[15.9] https://www.inria.fr/fr/sciences-des-donnees

[15.10] https://arxiv.org/html/2405.02703v1

[15.11] https://project.inria.fr/dirtydata/
[16.1] https://github.com/Breakend/experiment-impact-tracker

[16.2] https://github.com/lfwa/carbontracker

[16.3] https://codecarbon.io/

[16.4] https://numpex.org/fr/impacts-hpc-une-bibliotheque-python-pour-mesurer-et-comprendre-lempreinte-environnementale-du-calcul-scientifique/

[16.5] https://pop-coe.eu/

[16.6] https://fr.wikipedia.org/wiki/Loi_d'Amdahl

[16.7] https://apps.labos1point5.org/ges-1point5

[17.1] https://fr.wikipedia.org/wiki/Intelligence_artificielle_générative

[17.2] https://www.datacamp.com/fr/blog/mistral-vibe-2-0

[17.3] https://ia4dev-2025.sciencesconf.org/resource/page/id/1

[17.4] https://theses.hal.science/tel-05369950

[17.5] https://inria.hal.science/hal-04346102

[17.6] https://www.comparia beta.gouv.fr/

[17.7] https://huggingface.co/spaces/genai-impact/ecologits-calculator

[17.8] https://cafeia.org/

[17.9] https://theconversation.com/lia-generative-est-elle-soutenable-le-vrai-cout-ecologique-dun-prompt-269432

[17.10] https://theconversation.com/enquete-derriere-lia-les-travailleurs-precaires-des-pays-du-sud-201503

[17.11] https://www.fun-mooc.fr/fr/cours/intelligence-artificielle-et-societe/

[17.12] https://cis.cnrs.fr/presentation-gdr/

[17.13] https://www.sorbonne-universite.fr/dossiers/intelligence-artificielle/lia-dans-leducation-entre-opportunites-et-defis

[17.14] https://nmn.gl/blog/ai-and-learning

[17.15] https://legrandcontinent.eu/fr/2025/06/19/chatgpt-cerveau-etude-mit/

[17.16] https://www.iana-data.org/ethique-et-societe/843-lutilisation-exageree-doutils-dia-altere-les-capacites-cognitives-humaines.html

[17.17] https://fr.wikipedia.org/wiki/Vibe_coding

[17.18] https://arxiv.org/pdf/2506.10989

[17.19] https://www.canal-u.tv/chaines/devlog/formation-envol-l-intelligence-artificielle-en-aide-au-developpement

[17.20] https://www.entreprises.gouv.fr/files/files/Publications/2024/Guides/20241127-bro-guide-ragv4-interactif.pdf

[17.21] https://ragarenn.eskemm-numerique.fr/index.html

[17.22] https://emmy.cnrs.fr/

[17.23] https://themeta.news/mistral-gagnant-pour-la-recherche/

[17.24] https://cyber.gouv.fr/actualites/lanssi-et-le-bsi-publient-leurs-recommandations-de-securite-concernant-les-assistants-de-programmation-bases-sur-lia/

[17.25] https://cyber.gouv.fr/publications/recommandations-de-securite-pour-un-systeme-dia-generative

[17.26] https://www.cnil.fr/fr/ia-rgpd-la-cnil-publie-ses-nouvelles-recommandations-pour-accompagner-une-innovation-responsable

[18.1] https://www.arcep.fr/mes-demarches-et-services/entreprises/fiches-pratiques/referentiel-general-ecoconception-services-numeriques.html

[18.2] https://designersethiques.org/fr/thematiques/ecoconception/guide-d-ecoconception

[18.3] https://fr.wikipedia.org/wiki/Dark_pattern

[18.4] https://rweb.greenit.fr/

[18.5] https://messervices.cyber.gouv.fr/guides/securiser-un-site-web

[18.6] https://greenspector.com/fr/accueil/

[18.7] https://www.ecoindex.fr/

[18.8] https://github.com/christophe-cerin/Ecoindex-Revisited

[18.9] https://amoeba.mozilla.org/fr/firefox/addon/carbonalyser/

[18.10] https://www.fruggr.io/fr/

[18.11] https://greenframe.io/

[18.12] https://fr.wikipedia.org/wiki/Fair_data

[18.13] https://fr.wikipedia.org/wiki/Principe_KISS

[18.14] https://ecoinfo.cnrs.fr/2020/05/19/guide-des-bonnes-pratiques-du-code-de-conduite-europeen-sur-les-datacentres/

[19.1] https://www embedded-france.org/wp-content/uploads/2025/01/Le-cycle-de-vie-dun-systeme-embarque-LIVRE-BLANC-GT-Eco-conception-Embedded-France.pdf

[19.2] https://www.researchgate.net/publication/398592979_Transport_and Application_Layer Protocols for IoT Comprehensive Review

[19.3] https://collapseos.org/

[19.4] https://solar.lowtechmagazine.com/fr/about.html

[19.5] https://wiki.lowtechlab.org/wiki/Dominik_-_serveur_modulable_autoalimenté_en_réemploi