# Optimiser l'efficience énergétique des systèmes d'information : Étude comparative d'architectures de mise à disposition des données issues d'Agrosyst

Bérenger Vuittenez<fnref n="1" />
Thibault Peyrard<fnref n="1" />

## CORRESPONDANCE

berenger.vuittenez@inrae.fr
thibault.peyrard@inrae.fr

## RÉSUMÉ

L'augmentation de la consommation énergétique des data centers, susceptible de doubler entre 2024 et 2026, et plus généralement de l'impact grandissant du numérique sur le climat, justifient de réfléchir aux meilleures solutions technologiques à l'aune de leur consommation énergétique. Dans le cadre de l'évolution des modalités de mise à disposition des données agri-coles des plus de 2000 fermes et expérimentations du réseau DEPHY contenues dans le système d'information Agrosyst à des chercheurs et data scientists, la question de l'optimisation de l'efficience énergétique s'est posée. Deux types d'architecture de livraison de données sont comparés : une architecture historique caractérisée par un stockage systématique des tables finales, et une architecture caractérisée par la création de nombreuses tables intermédiaires et un processus de génération à la volée. L'étude montre que le choix de l'une ou l'autre des architectures va dépendre du volume et du degré de particularité des requêtes. Compte tenu des habitudes actuelles d'utilisation du SI Agrosyst, il semble justifié de changer d'architecture, et donc de diminuer le stockage sur serveur et préférer l'exécution de certaines procédures à chaque génération de jeux de données. Ce changement de paradigme pourrait diviser au moins par deux la consommation énergétique du système de mise à disposition des données. Nous pensons que la méthodologie déployée pour réaliser cette analyse revêt un caractère géné-rique potentiellement intéressant pour d'autres situations plus ou moins similaires. Ce travail pose les bases de la prise en compte systématique de la sobriété énergétique pour les évolu-tions du SI Agrosyst, et pourrait appuyer l'élaboration d'un cadre méthodologique plus robuste et généralisable

## MOTS-CLÉS

Système d'information ; efficacité énergétique ; livraison de données ; stockage de données ; stockage sur serveur

<footnote n="1">¹ Agroécologie, INRAE, DPA3P, 21065 Dijon</footnote>
# Optimizing the energy efficiency of information systems: a comparative study of data delivery architectures from Agrosyst

Bérenger Vuittenez<fnref n="1" />
Thibault Peyrard<fnref n="1" />

## CORRESPONDENCE

berenger.vuittenez@inrae.fr
thibault.peyrard@inrae.fr

## ABSTRACT

The increase in energy consumption by data centers, which is projected to double between 2024 and 2026, and more generally the growing impact of digital technology on the climate, justify the need to consider the best technological solutions regarding their energy consumption. As part of the evolution of the methods for providing agricultural data from more than 2,000 farms and experiments in the DEPHY network, stored in the Agrosyst Information System, to researchers and data scientists, the issue of optimizing energy efficiency has emerged. Two types of data delivery architecture are being compared: a traditional architecture characterized by the systematic storage of final tables, and an architecture characterized by the creation of numerous intermediate tables and an "on-demand" generation process. The study shows that the choice between these architectures depends on the volume and specificity of the queries. Given the current usage patterns of the Agrosyst system, it seems justified to change the architecture, thereby reducing server storage and favoring the execution of certain procedures at each instance of data generation. This paradigm shift could reduce the energy consumption of the data provisioning system by at least half. We believe that the methodology used for this analysis has a broad applicability and may show potential interest for other similar situations. This work lays the foundation for systematically considering energy efficiency in future developments of the Agrosyst Information System and could support the development of a more robust and generalizable methodological framework.

## KEYWORDS

Information system; energy efficiency; data delivery; data storage; server storage

<footnote n="1">¹ Agroécologie, INRAE, DPA3P, 21065 Dijon</footnote>
## Introduction

Avec l'essor d'internet, des objets connectés et des systèmes d'information, le volume de données générées et stockées dans le monde croît rapidement. Son augmentation est estimée à plus de 80% entre 2023 et 2025 (Hassani et MacFeely, 2023).

Les data centers, qui assurent le stockage de ces données, représentent environ 14 % de l'empreinte carbone du numérique en France (Lees Perasso et al., 2023). Celle-ci est imputable à leur consommation d'électricité – environ 2 % de l'électricité mondiale (Baude et al., 2021) – et plus encore à la construction des infrastructures et la fabrication des batteries nécessaires à leur fonctionnement. Minimiser le niveau de charge de ces services permettrait à la fois de diminuer leur consommation d'électricité et d'agir contre la dynamique de croissance du nombre de ces équipements.

La livraison de données est un rouage essentiel du fonctionnement d'internet, influencé par les pratiques de stockage et de référencement des ressources populaires (Llorca et al., 2013). Cependant, il reste difficile de trouver des ressources pour arbitrer entre différentes architectures de livraison de données du point de vue des systèmes d'information dans la littérature technique. L'optimisation de ces fonctionnalités pourrait pourtant entrer dans le cadre des bonnes pratiques en éco-conception de services numériques (Bonamy et al., 2022).

Notre étude vise à combler ce manque en éclairant la prise de décision au sein d'une équipe responsable d'un système d'information. Le cas d'étude s'appuie sur le système Agrosyst, développé par INRAE dans le cadre du plan Écophyto (Ancelet et al., 2014). Agrosyst collecte des données issues du réseau DEPHY, regroupant plus de 2000 exploitations agricoles sur plus de dix ans, ainsi que des expérimentations visant à réduire l'usage de produits phytosanitaires. Enrichi chaque année par plus de 300 ingénieurs, il centralise des données variées (quantitatives, qualitatives, textuelles) réparties sur une centaine de tables et représentant un volume total de 30 Go.

En 2023, la mise en place d'un entrepôt de données pour Agrosyst a soulevé la question de l'architecture de livraison à adopter. Deux scénarios ont été envisagés : un stockage systématique des données générées ou une génération à la volée suivie d'une suppression après usage. Cet article présente la méthodologie développée pour arbitrer entre ces deux approches, en mettant l'accent sur la comparaison des performances énergétiques. Après une présentation de la démarche de conception de l'entrepôt, nous décrivons les critères et outils permettant de guider ce choix architectural.

## La démarche de conception de l'entrepôt et des magasins de données

### Génération d'un entrepôt de données

Historiquement, la fourniture des données issues d'Agrosyst à des valorisateurs impliquait l'envoi d'un jeu de données volumineux et non spécifique à leurs usages. Si ce système permettait à n'importe quel utilisateur de trouver les informations nécessaires à son travail, la valorisation était rendue complexe par l'architecture de la base. Dans cette configuration, on avait donc un format unique couvrant toute l'information, mais nécessitant ensuite un important travail individuel des utilisateurs pour extraire ce dont ils avaient besoin. De plus, des données inutiles à l'utilisateur étaient susceptibles d'être stockées sur le poste, aggravant l'impact énergétique de la procédure.

La première étape de mise en place d'un nouveau système de fourniture de données a consisté à créer un entrepôt de données. Celui-ci est une copie de la base de données opérationnelle (à un moment donné). Il est stocké en PostgreSQL et contient toute la logique métier<fnref n="1" /> issue de la base de données opérationnelle du système d'information. Pour ce faire, les informaticiens et les agronomes de l'équipe ont conjointement choisi la nomenclature la plus pertinente pour chacune des entités métiers<fnref n="2" /> manipulées. La base de données obtenue constitue la brique élémentaire de tout le travail subséquent. Cet entrepôt est généré grâce à un ensemble de scripts SQL. Ce nouvel entrepôt a été mis à disposition en 2024 sur un site internet : https://agrosyst.fr/datagrosyst/ (Vuittenez et al., 2025).

### Définition des magasins de données

Une fois l'entrepôt mis en place, nous avons conçu des jeux de données appelés « magasins de données » pour répondre aux besoins spécifiques des utilisateurs. Ces magasins, adaptés à des objectifs métiers déterminés, simplifient l'accès aux données en intégrant des prétraitements et une structure adaptée aux profils types identifiés.

Par exemple, un utilisateur analysant les performances agronomiques d'une variété de blé aura des besoins différents de celui étudiant les performances environnementales d'une exploitation. La diversité des besoins s'explique par le large spectre couvert par la base Agrosyst, où certains pans, comme les rotations culturales, peuvent être inutiles pour des filières comme la vigne.

Certains magasins servent à des plateformes partenaires, comme DEPHYGraph<fnref n="3" /> et MoCoRiBa<fnref n="4" />, ou à l'animation interne du réseau DEPHY. Ce processus de génération, dynamique et automatisé, répond aux besoins de mise à jour fréquente des utilisateurs.

<footnote n="1">1. La logique métier de l'application, c'est la raison pour laquelle elle existe. Dans le cadre d'Agrosyst, il s'agit de toutes les informations pouvant avoir un intérêt agronomique.</footnote>

<footnote n="2">2. Par extension de la logique métier, toute entité concernant le cœur de l'application est appelée entité métier.</footnote>

<footnote n="3">3. https://dephygraph.fr/#/</footnote>

<footnote n="4">4. https://mocoriba.fr/general/</footnote>
## Choix d'architecture

Il existe donc un large éventail de données à livrer périodiquement, pour une pluralité importante de profils. Le volume de données et le besoin d'automatisation appellent une vraie réflexion sur les outils informatiques à mobiliser pour faire face à ces défis. En d'autres termes : si on dispose déjà, à ce stade, d'un entrepôt et de la spécification des magasins, il reste à réfléchir à la façon de coordonner au mieux l'ensemble de ces entités. Le choix de l'architecture sera réalisé à la lumière de son coût énergétique et de sa complexité.

## Construction de la proposition d'architecture

Choisir une architecture de livraison de données, c'est arbitrer entre une consommation d'énergie au stockage et une consommation d'énergie au moment de l'exécution d'un processus de génération. Certaines architectures font le choix de stocker directement les données à livrer à l'utilisateur final tandis que d'autres font appel à des processus de génération intermédiaires. Pour ces dernières, le coût en stockage sera moins grand mais le coût en génération sera d'autant plus grand que le nombre de requêtes sera élevé.

### Présentation de l'architecture

La fourniture d'un jeu de données apparaît triviale de prime abord : il s'agit de déplacer une donnée d'un point A (souvent un serveur) à un point B (souvent le poste d'un utilisateur), comme le montre la figure 1.

Cependant, pour des jeux de données au volume important, il peut être énergivore de stocker en base de données l'intégralité du jeu de données tel que l'obtiendra l'utilisateur. On sera donc amené à complexifier le processus de livraison en intercalant, entre le serveur et l'utilisateur, une étape de génération de l'état final : c'est la méthode de génération à la volée (Figure 2). Une fois les résultats finaux obtenus et délivrés, ceux-ci sont détruits et l'espace disque libéré.

<figure><img src="image_1.png" /><figcaption>Figure 1. Architecture de livraison sans intermédiaire</figcaption></figure>

<figure><img src="image_2.png" /><figcaption>Figure 2. Architecture de livraison avec calculs à la volée</figcaption></figure>

Le problème de cette solution, notamment pour les données issues d'Agrosyst où le nombre de traitements à effectuer est important, est que le coût de la génération peut s'avérer plus élevé que la solution de stockage (en fonction du nombre de requêtes, de leur fréquence...). Face à ce constat, nous considérons qu'il est judicieux d'introduire une approche intermédiaire, détaillée dans la figure 3 :

* stocker en base de données les données complexes à générer ;

* générer à la volée les jeux de données finaux à forte redondance.

<figure><img src="image_3.png" /><figcaption>Figure 3. Architecture de livraison retenue</figcaption></figure>

Les composants de cette solution intermédiaire sont les entités suivantes :

* A1 : base de données, appelée entrepôt de données et contenant toutes les données brutes utilisées dans la suite du processus ;

* A2 : base de données, appelée outils, contenant l'ensemble des tables complexes à générer ; elle est générée grâce au processus P1 et permet au processus P2 de disposer de toutes les informations sans être trop coûteux ;

* P1 : processus permettant d'obtenir les tables complexes à générer (en Python) ;

* P2 : processus permettant à l'utilisateur d'obtenir les jeux de données finaux (en SQL) ;

* B : poste de l'utilisateur final.

La version complète de l'article apporte plus d'informations sur ce qu'il est sous-entendu par « tables complexes à générer », sur les raisons du choix des différents langages et sur les limites de cette architecture, notamment vis-à-vis de la dynamique d'accès aux données (Vuittenez et Peyrard, 2025).

## Quantification des différences de performances entre les deux scénarios d'architecture

Afin de justifier notre choix, nous avons comparé deux architectures :

* l'une correspondant à une extension de l'ancienne version d'architecture et caractérisée par un stockage systématique des tables finales ;

* l'autre correspondant à une nouvelle version d'architecture et caractérisée par la création de nombreuses tables intermédiaires et un processus de génération à la volée.
Pour quantifier les différences espérées grâce à la nouvelle méthodologie, on cherchera à quantifier l'énergie utilisée pendant la durée de vie de la donnée. Afin de quantifier le gain énergétique associé à la nouvelle architecture, nous définissons G, exprimé comme suit :

$$G = 1 - \frac{e_B}{e_A} = 1 - \frac{1}{Q} \quad (1)$$

avec :

* $e_A$: énergie mobilisée par l'ancienne architecture, c'est-à-dire la somme des énergies nécessaires au stockage de l'ensemble des tables ;

* $e_B$: énergie mobilisée par la nouvelle architecture, c'est-à-dire la somme des énergies nécessaires au stockage des tables nécessaires à la table générée, à laquelle s'ajoute l'énergie de génération de la table finale, multipliée par le nombre de fois où la table est générée par des utilisateurs (nombre d'exécutions du processus P2) ;

* $Q$: quotient d'efficacité, rapport de $e_A$ sur $e_B$.

On espère calculer un gain supérieur à 0, prouvant que l'énergie mobilisée par la nouvelle architecture est inférieure à celle mobilisée par l'ancienne architecture.

Or, on peut montrer que ces énergies peuvent s'écrire, dans le cadre de l'insertion d'une nouvelle table accessible à l'export gn et grâce à la majoration sur le terme de génération expliquée dans l'annexe de la version complète de l'article (Vuittenez et Peyrard, 2025), comme :

$$e_A = e_{sgn} \approx \sum_{s_i \in P_{gn}} e_{s_{s_i}} \qquad (2) \\ e_B = \sum_{s_i \in P_{gn}} e_{s_{s_i}} + m \cdot e_{g_{gn}} < \sum_{s_i \in P_{gn}} e_{s_{s_i}} + m \cdot \alpha \cdot \sum_{s_i \in P_{gn}} e_{l_{s_i}} \quad (3)$$

$e_A$ est l'énergie de stockage de la table gn et celle-ci peut être approchée par la somme de l'énergie nécessaire au stockage de toutes les tables requises pour sa génération dans la nouvelle architecture,

avec :

* $S_i$: ie table stockée ;

* $g_i$: ie table générée ;

* $e_{s_t}$: énergie utilisée pour le stockage de la table t ;

* $e_{g_t}$: énergie utilisée pour la génération de la table t ;

* $e_{l_t}$: énergie utilisée pour fusionner la table t au résultat (jointure) ;

* $P_{gi}$: ensemble tel que $S_i \in P_{gi}$ si la table $S_i$ est utilisée lors de la génération de $g_i$ ;

* $P'_{gi}$: sous-ensemble de $P_{gi}$, correspondant à l'ensemble des tables stockées uniquement pour la table générée (spécifique à la nouvelle architecture) ;

* $m$: entier naturel correspondant au nombre de fois où le processus P2 est lancé pour la nouvelle table (c'est-à-dire le nombre de fois où la table considérée a été générée) ;

* $\alpha$ = (Card($P_{gn}$) - 1) correspondant au nombre de tables jointes au résultat auquel on retranche 1.

En définissant $F_p$ comme le ratio d'énergie entre le stockage de la table t et son utilisation dans une jointure, supposé constant :

$$F_p = \frac{e_{s_t}}{e_{l_t}} = \frac{p_s \cdot v_t \cdot T_{s_t}}{p_{e_t} \cdot v_t \cdot T_{g_t}} = \frac{p_s \cdot T_{s_t}}{p_{e_t} \cdot T_{g_t}} \quad (4)$$

avec :

* $P_s$: la puissance nécessaire par Go stocké (en W/Go) ;

* $P_{e_t}$: la puissance nécessaire pour mener à bien la fusion (en W/Go) ;

* $V_t$: le volume de la table t (en Go) ;

* $T_s$: le temps de stockage (en h) ;

* $T_g$: le temps de génération (en h) ;

Et en définissant un terme r correspondant au rapport énergétique entre la génération des nouvelles tables et l'information totale utile à la génération :

$$r = \frac{\sum_{s_i \in P_{gn}'} e_{s_{s_i}}}{\sum_{s_i \in P_{gn}} e_{s_{s_i}}} \quad (5)$$

En mobilisant l'inégalité obtenue dans l'équation (3), en l'appliquant au quotient d'efficacité et en mobilisant l'ensemble des termes définis ci-dessus, on obtient :

$$Q = \frac{e_A}{e_B} > \frac{\sum_{s_i \in P_{gn}} e_{s_{s_i}}}{\sum_{s_i \in P_{gn}} e_{s_{s_i}} + m \cdot \alpha \left( \sum_{s_i \in P_{gn}} e_{l_{s_i}} \right)} = \frac{1}{\sum_{s_i \in P_{gn}} e_{s_{s_i}} + \frac{m \cdot \alpha}{F_p}} = \frac{1}{r + \frac{m \cdot \alpha}{F_p}} \quad (6)$$

Plus de détails de calculs sont disponibles dans les équations (3.1) et (4.1) de la version complète de l'article (Vuittenez et Peyrard, 2025).

Après réarrangement des termes, on obtient :

$$\text{si } m < \frac{(1-r) \cdot F_p}{\alpha} \Rightarrow Q > 1 \quad (7)$$

## Estimation des paramètres

Comme on peut le voir dans la dernière équation du quotient d'efficacité, notre fonction dépend de plusieurs paramètres ($r, m, \alpha$ et $F_p$).

Dans ce qui suit, on prend en exemple la génération de la table intervention_realise telle qu'elle est souhaitée par la cellule d'animation nationale du réseau DEPHY :

* $T_{s_t}$ = 4320 h (en moyenne, les données sont stockées 6 mois sur les serveurs) ;

* $T_{g_t}$ = 0.02 h (en moyenne la génération de la table dure moins d'une minute) ;

* $p_s$ = 0.03 W/Go (en moyenne sur des serveurs de base de données en Europe correspondant à 0.3 kWh/Go sur un an (Farfan et Lohrmann, 2023)) ;
* $Pe_j = 12.9 \text{ W/Go}$ (en moyenne pendant l'exécution de la génération, estimée sur des machines locales à partir de données constructeurs);

* $r = 1/5$ (environ un cinquième de l'information utilisée n'est stockée que pour cette nouvelle table);

* $\alpha = 12$ (on a 12 jointures successives pour constituer la table).

D'autres hypothèses importantes sur ces estimations sont disponibles dans la version complète de l'article (Vuittenez et Peyrard, 2025).

## Application de la méthode

En utilisant l'inégalité (6), on aura alors :

$$ \text{et donc :} \qquad \begin{aligned} Q &> \frac{1}{0.20 + \frac{12m}{502}} \\ m < 34 &\Rightarrow Q > 1 \\ \Rightarrow G &> 0 \end{aligned} $$

En d'autres termes, on est sûr d'avoir de meilleures performances énergétiques avec la nouvelle architecture si le nombre d'exécutions du processus P2 ne dépasse pas 34 occurrences. Dans le cadre de l'utilisation des données issues d'Agrosyst, même pour les magasins de données les plus utilisés, l'ordre de grandeur du nombre de téléchargements est plutôt d'une dizaine tous les 6 mois.

## Conclusion et perspectives

Comme la consommation importante d'électricité par le secteur numérique impose de penser les processus de livraison de données dans une perspective d'économie d'énergie, nous avons mis en place une méthodologie permettant d'optimiser la performance énergétique du système d'information Agrosyst dans le cadre d'une évolution récente et majeure, à savoir la mise à disposition de données à des valorisateurs externes. La modalité d'arbitrage présentée dans cet article a permis de comparer deux architectures :

* l'une proposant un stockage complet des tables désirées par l'utilisateur ;

* l'autre proposant un stockage des données complexe et une génération à la volée des tables complètes.

La méthodologie proposée permet de rendre compte d'une dynamique intuitive : plus le nombre de requêtes pour un jeu de données est important, plus il sera intéressant de stocker le jeu de données plutôt que de le générer.

En appliquant la méthodologie au contexte d'Agrosyst, il nous est apparu que le stockage systématique des jeux de données complets n'est pas la bonne solution, ce qui nous a conduit à nous orienter vers la solution à deux temps. En reprenant l'exemple de

intervention_realise avec un nombre usuel de téléchargements (c'est-à-dire dix), on trouve un quotient d'efficacité d'environ 2,3, soit un gain de 60 %. En extrapolant à un magasin de données du type de celui attendu dans le cadre de l'animation du réseau DEPHY, on peut conclure que l'économie permise par l'architecture est d'environ 890 Wh soit l'équivalent de 20 h de réfrigérateur tous les 6 mois par magasin de données équivalent (en prenant une consommation de 40 W pour un réfrigérateur).

Dans le cadre de notre problématique, nous avons donc prouvé sur l'exemple étudié que le nombre usuel de requêtes justifiait un changement d'architecture et avons donc construit notre outil de mise à disposition en fonction de ce résultat.

Cette méthodologie comporte néanmoins plusieurs limites qu'il convient de souligner :

* La difficulté à estimer les puissances : par exemple, celles annoncées par les constructeurs sont toujours des puissances nécessaires à l'alimentation de la machine. Il est difficile de connaître la part de cette puissance réellement allouée à la tâche en cours d'exécution.

* La définition $e_A = esgn$ est imparfaite. En effet, on ne tient pas compte de la redondance d'informations entre clé primaire et clé étrangère (nécessaire lorsqu'on stocke l'information dans plusieurs tables). Cependant, nous considérons que le stockage de ces clés et des index liés est négligeable par rapport à d'autres champs omniprésents (textuels par exemple).

* La majoration dont la démonstration est proposée dans l'anexe de la version complète (Vuittenez et Peyrard, 2025) est forte mais il est complexe d'en proposer une meilleure. Il est donc important de comprendre que l'on garantit une économie en dessous du nombre de 34 requêtes mais avoir un nombre d'occurrences supérieur n'implique pas forcément un gain inférieur à 0.

* L'absence de prise en compte du stockage temporaire du fishier généré à la volée (le temps que l'utilisateur télécharge son jeu de données).

Pour s'affranchir de ces limites et avoir une idée plus précise du nombre d'occurrences limite entre les deux architectures, il serait intéressant d'affiner la majoration.

On pourrait envisager des choix différents en fonction de la popularité du magasin de données considéré (si le magasin de données est téléchargé fréquemment, opter pour la solution de stockage sinon, opter pour celle retenue ici).

Cet article peut servir de base à une systématisation de ces questionnements sur l'optimisation énergétique des évolutions du système d'information Agrosyst, mais également à une réflexion plus générale et à plus grande échelle afin d'établir un cadre méthodologique robuste pour l'ensemble des systèmes d'information d'INRAE.
Références

Alsharif, M. H., Kelechi, A. H., Jahid, A., Kannadasan, R., Singla, M. K., Gupta, J., et al. A comprehensive survey of energy-efficient computing to enable sustainable massive IoT networks. *Alexandria Engineering Journal*, 91, 12-29. https://doi.org/10.1016/j.aej.2024.01.067

Ancelet E., Schellenberger A., Jolys, O., Munier-Jolain, N., Cadoux, S. (2014). Système d'information Agrosyst, HAL (cité 3 sept 2024). https://hal.science/hal-02800677

Baude, M., Colin, A., Duvernoy, J., Foussard, A. (2021). Chiffres clés du climat: France, Europe et monde. Édition 2021. Ministère de la Transition écologique (cité 3 sept 2024). https://www.statistiques.developpement-durable.gouv.fr/chiffres-cles-du-climat-france-europe-et-monde-edition-2021-0

Bonamy, C., Boudinet, C., Bourgès, L., Dassas, K., Lefèvre, L., Ninassi, B. et al. (2022). Je code : les bonnes pratiques en éco-conception de service numérique à destination des développeurs de logiciels. https://hal.science/hal-03009741/

Commission de l'aménagement du territoire et du développement durable. Rapport d'information de la mission d'information sur l'em-
preinte environnementale du numérique. 2020 (cité 3 sept 2024). https://www.senat.fr/rap/r19-555/r19-555-syn.pdf

Dayarathna, M., Wen, Y., Fan, R. (2015). Data Center Energy Consumption Modeling: A Survey. *IEEE Communications Surveys Tutorials*, 18(1), 732-794. DOI:10.1109/COMST.2015.2481183

DELL Technologies. Precision 7560 Configuration et caractéristiques. 2023 (cité 3 sept 2024). https://dl.dell.com/content/marual38050698-precision-7560-configuration-et-caractéristiques.pdf?language=fr-fr

Farfan, J., Lohrmann, A. (2023). Gone with the clouds: Estimating the electricity and water footprint of digital data services in Europe. *Energy Conversion and Management*, 290. https://doi.org/10.1016/j.enconman.2023.117225

Hassani, H., MacFeely, S. (2023). Driving Excellence in Official Statistics: Unleashing the Potential of Comprehensive Digital Data Governance. *Big Data and Cognitive Computing*, 7(3):134. https://doi.org/10.3390/bdcc7030134

International Energy Agency (2024). Electricity 2024. Analysis and forecast to 2026 (cité 3 sept 2024). https://iea.blob.core.windows.net/assets/6b2fd954-2017-408e-bf08-952fdd62118a/Electricity2024-Analysisandforecastto2026.pdf

Lees Perasso, É., Corbet, L., Drapeau P., Ollion L., Vigneron V., Prunel D., et al. (2023). Évaluation de l'impact environnemental du numérique en France et analyse prospective. État des lieux et pistes d'action. ADEME (cité 3 sept 2024). https://librairie.ademe.fr/consommer-autre-ment/5226-evaluation-de-l-impact-environnemental-du-numerique-en-france-et-analyse-prospective.html#

Llorca, J., Tulino, A. M., Guan, K., Esteban, J., Varvello, M., Choi, N., et al. (2013). Dynamic in-network caching for energy efficient content delivery. 2013 *Proceedings IEEE INFOCOM*. Turin, Italie (cité 9 sept 2024), 245-249. http://ieeexplore.ieee.org/document/6566772

Osman, N.I. (2014). Energy Efficiency in Content Delivery Networks. The University of Leeds School of Electronic and Electrical Engineering. https://etheses.whiterose.ac.uk/id/eprint/7866/1/EEinCDNs.pdf

Vuittenez, B., Baude, L., Badie, T., Peyrard, T., Reboud, X., Rousselet S., et al. (2025). Datagrosyst : plateforme d'accès aux données issues d'Agrosyst. Recherche Data Gouv (cité 29 avr 2025). https://entrepot.recherche.data.gouv.fr/citation?persistentId=doi:10.57745/CCG800

Vuittenez B., Peyrard T. (2025). Optimiser l'efficience énergétique des systèmes d'information : Étude comparative d'architectures de mise à disposition des données issues d'Agrosyst (version complète). https://haLinrae.fr/hal-05092654

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

Cet article est publié sous la licence Creative Commons (CC BY-SA). https://creativecommons.org/licenses/by-sa/4.0/

Pour la citation et la reproduction de cet article, mentionner obligatoirement le titre de l'article, le nom de tous les auteurs, la mention de sa publication dans la revue « NOV'AE», la date de sa publication et son URL.