> For the complete documentation index, see [llms.txt](https://www.bilancarbone-conformite.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://www.bilancarbone-conformite.com/referentiels-de-conformite/chapitre-d-transparence-de-la-methodologie-des-sources-et-formation/critere-d.4-mise-a-jour-methodologique-de-loutil.md).

# Critère D.4 - Mise à jour méthodologique de l'outil

La méthode Bilan Carbone® a évolué et continue à le faire afin de proposer des outils et méthodes toujours pertinentes pour accompagner les organisations dans le pilotage de leur réduction d’émission de GES. C’est pourquoi, les propriétaires de l’outil-candidat se doivent, premièrement, de « faire vivre » leur outil, c’est-à-dire d’envisager le développement et les mises à jour courantes comme la mise à jour des FE, mais aussi les mises à jour nécessaires à l’adéquation avec les futurs standards et méthodologies de référence.

Afin de faciliter l’utilisation d’une plateforme, il est donc important de proposer un bon niveau de transparence sur les évolutions des modules et fonctionnalités, afin de permettre aux utilisateurs de suivre et d’améliorer leur pratique en profitant des développements faits par le porteur d’outil. Les outils de comptabilité carbone participent largement à la démocratisation de la comptabilité carbone, et pour ce faire certains proposent des outils très accessibles. Les développements des outils participent donc à la montée en maturité des utilisateurs, en évitant de les bloquer à cause d’outils trop portés sur l’accessibilité.

De la même façon, il est important d’assurer le meilleur niveau de transparence sur la gestion des mises à jour des bases de FE utilisées et sur l’impact que ces mises à jour peuvent avoir sur les bilans des utilisateurs. Cela évitera notamment la modification inopinée du résultat d’un bilan, sans que son propriétaire ne soit prévenu.

#### Critère

<table data-header-hidden><thead><tr><th width="136"></th><th></th></tr></thead><tbody><tr><td><mark style="color:red;"><strong>Obligatoire</strong></mark></td><td><strong>Critère D.4 - Mise à jour méthodologique de l'outil</strong></td></tr><tr><td><strong>Question</strong></td><td>Est-il prévu le développement futur de l’outil-candidat et notamment le besoin de mise à jour périodique des FE voire de la méthodologie de l’outil-candidat ? Les process de mises à jour associés sont-ils clairs dans les ressources de l’outil-candidat ? Les utilisateurs sont-ils avertis des impacts de ces mises à jours sur leurs bilans ?</td></tr><tr><td><strong>Réponses</strong></td><td><ul><li><mark style="color:green;"><strong>Oui, l'outil-candidat intègre un historique des mises à jour et ses process de mise à jour des FE et de l'outil sont clairement explicités.</strong></mark></li><li><mark style="color:red;"><strong>Non</strong></mark></li></ul></td></tr><tr><td><strong>Aide à la mise en œuvre</strong></td><td><p>Rechercher dans le guide de l’utilisation, le guide méthodologique et/ou le manuel les paragraphes d’explication sur les évolutions passées (et/ou futures si cela existe). Y a-t-il un chargé de projet/développement de l’outil-candidat ?</p><p></p><p>Est-il possible d’identifier clairement un chef/chargé de développement de l’outil-candidat. Y a-t-il des moyens humains alloués au développement de l’outil ?</p><p></p><p>Vérifier la présence d’une présentation du process de mise à jour des facteurs d’émission utilisés, et de la façon dont les utilisateurs sont impactés</p></td></tr></tbody></table>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://www.bilancarbone-conformite.com/referentiels-de-conformite/chapitre-d-transparence-de-la-methodologie-des-sources-et-formation/critere-d.4-mise-a-jour-methodologique-de-loutil.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.