Évaluer les impacts à partir des caractéristiques techniques : En fournissant un descriptif des caractéristiques de l’équipement utilisé ainsi que ses conditions d’utilisation, l’API est en capacité de générer des facteurs d’empreinte environnementale. Cela s’apparente à une base de données de facteurs dynamiques.

Architecture en couche : L’API suit une approche bottom-up. Quand cela est possible, les impacts des équipements sont évalués sur la base des impacts de chacun de leurs composants, qui sont agrégés pour estimer leur impact. Dans le futur, nous souhaitons évaluer les impacts des systèmes et services numériques sur la base de celui des équipements mis en œuvre.

Multicritère : Pour prendre en compte la diversité des impacts environnementaux induits par le numérique, l’API ne se limite pas à l’évaluation des émissions de gaz à effets de serre (participation au réchauffement climatique, global). 19 critères d’impacts sont disponibles, couvrant des impacts relatifs à la pollution, à l’utilisation des ressources et de l’énergie, ou encore l’utilisation des sols. Face au manque de facteurs d’empreintes multicritères disponibles publiquement, l’ensemble des équipements et des composants évalués n’implémentent pas l’ensemble de ces critères. Par exemple, seuls 3 critères d’impacts sont disponibles pour les serveurs.

Sur l’ensemble du cycle de vie : Les impacts environnementaux du numérique ne se limitent pas à la phase d’usage et à la consommation d’énergie des équipements. Une majorité des étapes du cycle de vie sont évaluées par l’API (extraction des matières premières, fabrication, usage). Les phases de distribution et de fin de vie sont évaluées quand cela est possible.

Interface simple ou détaillée au choix : De nombreuses données d’inventaire sont utilisées par l’API . La plupart des utilisatrices et utilisateurs ne disposant pas de l’ensemble des données à l’évaluation des impacts, l’API complète automatiquement les données manquantes selon différentes stratégies :

• Complétion dynamique sur la base d’autres données. (ex. nom du CPU)
• Des données provenant d’un l’archétype, un équipement ou un composant préenregistré qui est défini dans la requête permettant de récupérer les données manquantes.
• Des données par défaut.

Pour prendre en compte l’incertitude générée par la complétion des données manquantes, nous fixons des bornes minimales et maximales sur l’ensemble des données d’inventaire et d’impacts.

Transparent : La transparence est pour Boavizta un élément clef dans le cadre de la création de communs, surtout dans le contexte naissant des évaluations environnementales du numérique. Afin de garantir un haut niveau de transparence, nous documentons au maximum les méthodes mises en œuvre et renvoyons aux utilisatrices et utilisateurs les données utilisées - notamment les données complétées.

Nouvelles fonctionnalités

Les premières versions de l’API ont permis de créer un MVP permettant de tester l’intérêt de proposer un tel outil. Avec la sortie de la v1, nous espérons proposer un projet plus complet et plus robuste qui pourra être utilisé dans une plus grande diversité de cas d’usages et susciter des envies de collaboration. Parmi les nouvelles fonctionnalités majeures, on peut citer :

• Évaluation des impacts des terminaux et périphériques utilisateur sur la base des données NégaOctets disponible sur la Base Empreinte.
• Évaluation des impacts des équipements IoT sur la base d’une approche screening développé par Thibault Pirson et David Bol de l’UC Louvain, adapté en multicritère par TIDE.
• Évaluation des impacts de l’ensemble des équipements disponible pour 3 à 19 critères d’impact PEF
• Ajout des marges d’erreur sous la forme de données min et max. Pour le moment, les marges d’erreur sont basées sur la complétude des données utilisateur et non sur la fiabilité des facteurs d’empreinte
• Ajout des warnings pour témoigner des incertitudes de manière qualitative quand cela est nécessaire.
• Ajout des données de plus de 2 000 CPU pour la complétion par nom. Pour ajouter des nouveaux CPU voir la documentation dédiée.
• Ajout des routes utilitaires pour obtenir la liste des valeurs disponibles pour une partie des variables.
• Les utilisateurs peuvent désormais choisir les facteurs d’impact qu’elles/ils souhaitent calculer
• L’ajout de nouveaux clouds providers par la communauté est grandement facilité

Afin de proposer une version 1 plus robuste, de nombreuses modifications majeures (breaking changes) ont été introduites. Ainsi, si vous étiez utilisatrices ou utilisateurs des dernières versions, vous serez amené à modifier certaines de vos requêtes à l’API. N’hésitez pas à regarder en détail la note de release, ouvrir des issues sur le GitHub pour en discuter ou encore contribuer à l’amélioration de la documentation.

L’approche outil de Boavizta

Open-Source

Pourquoi ?

Les membres de Boavizta sont, avant d’être des actrices et acteurs du numérique, des citoyens conscients des risques et conséquences du dépassement des limites planétaires et du rôle grandissant du numérique à ce sujet. Plusieurs raisons nous motivent à ne produire et encourager des solutions et méthodes ouvertes :

• La démocratisation du sujet complexe des impacts environnementaux liés au numérique.
• Le passage à l’échelle, en termes de compréhension de ces impacts dans les organisations et de leur capacité à les réduire.
• Une meilleure collaboration, et donc une meilleure qualité des outils et méthodes proposées.
• Le respect pour l’ensemble des personnes (dont nous faisons partie) qui pourraient être assujetties à de nouvelles réglementations dans le futur, motivées par des évaluations d’impacts environnementaux. Une évaluation, qu’elle soit sous forme d’étude, de tableau de pilotage, de chiffre partagé dans des campagnes de communication, est un objet politique. Elle a le potentiel d’influencer des politiques privées ou publiques. Selon nous, les personnes et les sociétés touchées par ces politiques doivent avoir un droit de regard sur la manière dont ces évaluations sont construites, pouvoir les critiquer et les remettre en cause.
• Le partage et la collaboration à l’international, qui nous semble indispensable pour que des accords adviennent sur des standards d’évaluation qui soient les plus fiables et transparents possibles.

La licence AGPL

La licence AGPL ou GNU Affero General Public License est une licence ayant pour but d’obliger les services accessibles par le réseau de publier leur code source. Cette licence est apparue dans un contexte où de nombreux services commerciaux en ligne se sont construits sur des logiciels libres, sans rétribution quelque soit leur forme, pour les contributrices et contributeurs à ces projets. Cette licence est dite libre et copyleft.

_Libre _signifie que l’auteur concède tous les droits ou une partie des droits que lui confère le droit d’auteur, en laissant au minimum quatre droits considérés fondamentaux aux utilisateurs :

• usage de l’œuvre ;
• étude de l’œuvre pour en comprendre le fonctionnement ou l’adapter à ses besoins ;
• modification ou incorporation de l’œuvre en une œuvre dérivée ;
• redistribution de l’œuvre, c’est-à-dire sa diffusion à d’autres usagers, y compris commercialement.

Copyleft signifie que ces droits sont concédés, dans la mesure où cette même autorisation reste préservée. Le but étant d’éviter que l’œuvre originelle soit modifiée, puis que cette nouvelle œuvre ne permette pas les mêmes droits à ses utilisateurs.

BoaviztAPI est sous licence AGPL-3.0. Ce qui signifie, que toute personne ou organisation, donnant accès à d’autres personnes que ses collaborateurs à une version auto-hébergée de l’API, qu’elle soit modifiée ou non, intégrée dans un autre outil ou non, est dans l’obligation de communiquer à ses utilisateurs un lien vers le code source de la version active de l’API. À travers cette licence, il s’agit pour nous à la fois de valoriser le travail des contributrices et contributeurs, de pousser les utilisatrices et utilisateurs à la contribution mais avant tout d’éviter une utilisation modifiée de l’API non auditable.

À l’état de l’art

Le processus / la discussion méthodologique

Nous tentons de rapprocher le plus possible les méthodes et calculs implémentés dans l’API de l’état de l’art de la recherche sur le sujet. Pour ce faire, les discussions méthodologiques naissent souvent de la publication d’un article scientifique, qui semble apporter une amélioration significative pour l’évaluation d’un élément numérique donné (impacts environnementaux d’un semi-conducteur, d’un écran, ou d’un composant spécifique, par exemple). Les discussions commencent généralement au sein de l’association, sur notre outil de chat. Une fois qu’un périmètre d’évaluation semble adressable grâce à ces nouvelles découvertes, nous ouvrons généralement une issue sur le projet Github de la BoaviztAPI, en ajoutant un tag “Enhancement”.

À partir de là, les discussions sont ouvertes publiquement et toute personne, membre ou non de l’association peut prendre part à la réflexion et suggérer une manière d’implémenter cette méthodologie.

Une personne non membre de l’association peut également suggérer d’implémenter une nouvelle méthode de calcul, en ouvrant directement une issue sur le projet Github.

Micro-services

L’API joue un rôle central dans la boîte à outils Boavizta. Elle constitue le référentiel méthodologique et le moteur de calcul, qui peut être utilisé dans de nombreux contextes. C’est elle qui fournit les évaluations d’impact disponibles via Datavizta. C’est également le module chargé de l’évaluation d’impact dans le projet cloud-scanner qui permet d’évaluer les impacts des ressources consommées dans un compte AWS. Boagent est un autre exemple d’usage de l’API, destiné aux serveurs physiques. Cet outil scanne les caractéristiques et fournit une évaluation d’impacts basée sur la BoaviztAPI. Cloud-scanner et Boagent sont des projets qui embarquent l’API comme composant du logiciel. Il est donc nécessaire de mettre à jour la version de l’API utilisée et déployée avec le projet, pour bénéficier de ses avancées (charge aux contributeurs de ces projets d’adapter l’outil pour faire bénéficier des évolutions de l’API aux utilisateurs).

BoaviztAPI est capable d’évaluer l’impact de la fabrication d’un équipement, mais aussi de son utilisation (à condition que l’utilisateur fournisse des hypothèses d’usage). La méthode utilisée est en constante évolution, mais nous sommes arrivés à la conclusion qu’un projet plus structuré, faisant appel à de la collecte de données primaires était nécessaire pour l’améliorer. Le projet en cours Energizta a pour objectif d’alimenter l’API avec de meilleurs modèles d’estimation de la consommation d’énergie d’une machine