Over the last few months, we’ve published 2 articles on eco-design and the RGESN (French Eco-design standard) to introduce them to you.
We’re convinced that the RGESN standard has a great future, and that it will enable our digital services to improve their environmental impact. However, like all standards, and even more so for recent ones, it has its limits. With this in mind, we at K-LAGAN are working to enhance it.
In this article, we present the main limitations we have identified and the actions we have taken to address them, through the work we have carried out to design the Envi’Score.
RGESN criteria are in “all-or-nothing” mode
The RGESN is a binary reference system: a criterion is either met or not. This feature is very practical in a certification or rating process, but does not make it possible to quantify the progress of certain actions. This can quickly lead to discouragement on the part of teams, as well as failing to give a precise indication of the eco-design maturity of a digital service.
To address this issue, we drew inspiration from TMMi. TMMi provides different levels of quality maturity, each composed of process areas that meet specific objectives. To validate a TMMi level it is necessary to validate all the Process Areas of the level, as well as all the levels below.
Process Areas and even objectives can be seen as criteria to be met. At the end of a TMMi assessment, we obviously have a level with the Process Areas and objectives achieved or not… but each of these elements not achieved has a % of achievement. This enables us to see how far we still have to go to meet this criterion.
We have included this vision of % progress for each RGESN criterion, and this progress is included in the score of our enriched RGESN.
It’s quite complicated to know if you’ve reached a criterion
The RGESN is a set of 78 criteria.
Digital services that can be evaluated on all 78 criteria are quite rare, as some criteria are specific to a technology (e.g. AI and blockchain), a type of digital service (a back-end service will be little or not at all affected by the front-end theme) or even the service proposition (not all digital services provide audio or video).
What’s more, each criterion, even if it has an explanatory sheet, is specialized on a subject, and it can be complex to know whether or not the criterion has been met.
In order to respond as precisely as possible to this problem, we have designed a set of questions for each criterion. This also enables us to better assess the % of progress stated in the previous paragraph.
As a reminder, here are the criteria for the most “instinctive” topic, the strategy:
| Criterion |
| Has the digital service been favorably evaluated in terms of utility, taking into account its environmental impact? |
| Has the digital service defined the business needs and real expectations of target users? |
| Does the digital service have at least one identified digital eco-design referent? |
| Does the digital department carry out regular reviews to ensure compliance with its eco-design approach? |
| Has the digital service set targets for reducing or limiting its own environmental impact? |
| Does the digital service collect data in a responsible and reasoned manner? |
| Does the digital service use a level of encryption adapted to its needs? |
| Has the digital service implemented open source efforts? |
| Has the digital service been designed using standard, interoperable technologies rather than specific, closed technologies? |
| Does the digital service rely on documented, open APIs to interact with the hardware? |
RGESN criteria are not “weighted”
The RGESN coverage indicator is quite simple: a % of validated criteria. Unfortunately, as you will have seen in this article, the number of criteria is not necessarily evenly distributed across the different topics, and the impacts of digital services are not equivalent.
In order to provide a more objective view, we have worked on 4 types of digital services and weighted the topics for each type of service.
Please note: the prioritization of the latest version allows for different coverage depending on the priority of the criteria.
The RGESN does not take sufficient account of quality and development.
The RGESN is an excellent tool for implementing best practices for limiting and reducing environmental impact.
Unfortunately, it fails to take into account topics that we feel are of prime importance: development and quality. However, this does not mean that quality or development are not addressed using the above criteria. They are, in fact, addressed through reviews, but only through the prism of other topics.
To fill this gap, we have added the Quality topic and the Development topic, whose criteria we have selected as follows:
| Thématique | Critère |
| Quality | Does your test strategy take eco-design aspects into account? |
| Quality | Do your test output criteria take environmental aspects into account? |
| Quality | Do you have an eco-design quality manager? |
| Quality | Do you conduct eco-design reviews during the various phases of your software cycle? |
| Quality | Do your retrospectives identify actions to improve the environmental impact of the digital service? |
| Quality | Are your tests structured in such a way as to limit their environmental impact? |
| Quality | Are your test environments sized according to test requirements? |
| Quality | Are your test environments activated only when you need them? |
| Quality | Is the volume of test data adapted to test requirements? |
| Quality | Is eco-design training in place? |
| Quality | Do you test the current resource consumption of your digital service? |
| Quality | Do you have a community of eco-design best practices? |
| Development | Do you have a dedicated eco-design developer? |
| Development | Do you take a mobile-first or adaptive design (responsive évolué) approach to development? |
| Development | Do you set up forks dedicated to environmental impacts (e.g. consumption, performance, etc.)? |
| Development | Does your selection of libraries/functionalities to call up take resource consumption into account? |
| Development | Are your CSS adapted to limit environmental impact? |
| Development | Are DOM modifications managed in an eco-responsible way? |
| Development | Does your code analysis tool take eco-design criteria into account? |
| Development | Have you implemented best practices to limit the number of requests? |
| Development | Do you limit redirections? |
| Development | Do you remove unused functions? |
We have obviously applied these criteria to our indicators. For example, we use this radar:
Conclusion
After a thorough analysis of the RGESN, we were able to make it our own and identify the areas for improvement that seemed most relevant to us. We then implemented them in an “enriched RGESN” that we use in our Envi’Score.
The improvements we have added are of a “comfort” nature, making it easier to understand the criteria with the notion of progress and the creation of questionnaires, of a “communication” nature with the addition of indicators, but also of a “substance” nature with the addition of 2 new topics.
We have also taken particular care to ensure that we can continue to provide the official RGESN score at all times, so that our enriched RGESN is an extension that does not suppress certain information, such as RGESN coverage, which will surely prove indispensable in the near future.
