Modèle de maturité du pilotage : d'Excel à l'EPM intégré

Le modèle de maturité du pilotage situe une organisation selon sa capacité à produire des données fiables, à construire des prévisions cohérentes et à transformer l'analyse en décisions suivies. Il décrit une progression des pratiques, pas un classement des logiciels : une équipe équipée d'Excel peut être rigoureuse, tandis qu'une organisation disposant d'un EPM peut conserver des processus fragiles. L'enjeu est de choisir le prochain progrès utile, en fonction des risques et des décisions à éclairer.

• Évaluer plusieurs dimensions, pas seulement l'outil. La gouvernance est l'ensemble des règles qui attribuent les responsabilités et organisent les arbitrages. Elle compte autant que la qualité des données, la cohérence des calculs ou la participation des responsables opérationnels. Un fichier partagé ne garantit pas une définition commune des indicateurs ; une base centralisée ne garantit pas que quelqu'un explique les écarts. Le diagnostic doit donc chercher des preuves : une règle écrite, un contrôle exécuté, une validation conservée ou une décision suivie.
• Progresser par étapes utiles. Le référentiel est l'ensemble des codes et définitions communs utilisés pour décrire les données, comme les entités, les produits et les comptes. Stabiliser ce référentiel, identifier une version approuvée et attribuer un responsable à chaque donnée peut être plus urgent que déployer une nouvelle plateforme. L'ordre des travaux dépend du problème rencontré : erreurs de calcul, versions contradictoires, délais de collecte ou prévisions déconnectées de l'activité.
• Mesurer la valeur dans le travail de gestion. Un pilotage plus mature permet de comprendre comment un résultat a été obtenu, quelle hypothèse a changé et quelle action a été décidée. L'EPM peut soutenir cette progression en reliant les données, les calculs et les validations, mais il ne remplace ni le jugement financier ni la responsabilité des métiers. La cible n'est pas nécessairement le niveau le plus sophistiqué : c'est un fonctionnement maîtrisé, proportionné aux besoins et durablement utilisé.

Sans diagnostic de maturité, la direction financière risque de traiter chaque difficulté comme un incident isolé. Un retard devient une relance supplémentaire ; une incohérence, une correction manuelle ; une prévision contestée, une nouvelle réunion. Ces réponses peuvent résoudre l'urgence sans corriger la cause : définitions différentes, responsabilités floues ou absence de contrôle avant diffusion.

Le budget est une référence chiffrée approuvée qui traduit les objectifs et les ressources prévus pour une période. Le forecast, ou prévision actualisée, estime les résultats attendus à partir des informations disponibles. Le réel désigne les résultats effectivement constatés. Lorsque ces ensembles sont mélangés dans les mêmes fichiers, une correction peut effacer une hypothèse initiale ou rendre une comparaison impossible. Le contrôleur de gestion passe alors du temps à reconstituer les versions plutôt qu'à expliquer l'activité.

Les difficultés se cumulent souvent. Chaque service nomme ses produits différemment ; les totaux sont recopiés entre classeurs ; une formule dépend d'un fichier détenu par une seule personne. La direction reçoit un chiffre sans savoir s'il est complet, validé ou comparable à celui du mois précédent. Les opérationnels contestent ensuite les résultats, faute de reconnaître leurs hypothèses dans la synthèse.

Le modèle de maturité permet de distinguer la cause du symptôme. Si les définitions divergent, il faut d'abord harmoniser les règles. Si elles sont stables mais que les échanges deviennent difficiles à maîtriser, un outil partagé peut être pertinent. Si les données sont fiables mais ne débouchent sur aucune action, le problème relève surtout de l'organisation des décisions.

Le DAF, directeur administratif et financier, fixe les priorités et arbitre les moyens. Le contrôle de gestion rend les comparaisons cohérentes et analyse les résultats. Les responsables opérationnels expliquent l'activité et portent les actions. L'équipe informatique sécurise les accès et les échanges de données. Le diagnostic clarifie ces rôles pour éviter que la finance assume seule toutes les corrections et toutes les décisions.

Le modèle fonctionne comme une grille de lecture appuyée sur des faits. Il complète le cycle de gestion : planifier, mesurer, analyser, agir, en évaluant la solidité de chaque étape plutôt qu'en jugeant seulement le résultat final.

1. Délimiter l'objet du diagnostic. Choisir un processus concret, par exemple la préparation budgétaire ou la prévision des ventes. Préciser les entités concernées, les utilisateurs, la période et les décisions attendues. Sans cette limite, une bonne pratique locale peut être prise à tort pour une capacité de toute l'organisation.

2. Observer les pratiques sur plusieurs axes. Examiner les données, les méthodes de calcul, les responsabilités, les outils et l'usage des résultats. Demander des éléments observables : fichiers effectivement utilisés, règles de validation, comptes rendus et corrections réalisées. Les déclarations d'intention ne suffisent pas.

3. Décrire la situation actuelle. Pour chaque axe, distinguer une pratique dépendante des personnes, une pratique définie et répétable, puis une pratique intégrée et suivie. Une même organisation peut être avancée sur ses contrôles et débutante sur ses prévisions. Conserver ce profil détaillé plutôt que le masquer derrière une note globale.

4. Relier chaque faiblesse à une conséquence. Une absence de version approuvée expose à une comparaison erronée ; une donnée sans responsable retarde les corrections ; une hypothèse non documentée rend la prévision difficile à discuter. Cette relation donne un sens économique et opérationnel au diagnostic.

5. Choisir une cible réaliste. Le modèle cible est la description du fonctionnement souhaité, avec ses règles, ses rôles et ses outils. Il doit répondre aux risques prioritaires et aux décisions utiles, sans ajouter une complexité qui ne serait pas entretenue.

6. Vérifier la progression. Comparer les mêmes critères après mise en œuvre. Une capacité est acquise lorsqu'elle fonctionne dans un cycle normal, avec les utilisateurs habituels, et pas seulement lors d'une démonstration. Les résultats servent ensuite à ajuster la prochaine étape.

Ce cas est entièrement fictif : un groupe industriel composé de deux sites évalue la maturité de son suivi mensuel. Le chiffre d'affaires (CA) représente les ventes de la période ; les coûts variables évoluent avec le niveau d'activité ; la marge sur coûts variables est égale au CA moins les coûts variables. Tous les montants du tableau sont exprimés en milliers d'euros.

| Site | CA budget | CA réel | Coûts variables budget | Coûts variables réels | Marge budget | Marge réelle | |---|---:|---:|---:|---:|---:|---:| | A | 1 200 | 1 140 | 720 | 706 | 480 | 434 | | B | 800 | 880 | 480 | 554 | 320 | 326 | | Total | 2 000 | 2 020 | 1 200 | 1 260 | 800 | 760 |

Les marges se recalculent directement : pour A, 1 200 − 720 = 480 au budget et 1 140 − 706 = 434 au réel ; pour B, 800 − 480 = 320 et 880 − 554 = 326. Les totaux sont 1 200 + 800 = 2 000 et 1 140 + 880 = 2 020 pour le CA ; 720 + 480 = 1 200 et 706 + 554 = 1 260 pour les coûts variables. Les marges totales sont donc 2 000 − 1 200 = 800 et 2 020 − 1 260 = 760.

L'écart budgétaire est le réel moins le budget. Pour le CA, 2 020 − 2 000 = +20, soit 20 / 2 000 × 100 = +1 %, favorable dans ce cas. Pour les coûts variables, 1 260 − 1 200 = +60, défavorable. Pour la marge, 760 − 800 = −40, soit −40 / 800 × 100 = −5 %, défavorable. La hausse des ventes ne signifie donc pas que la marge progresse.

Le forecast de CA, figé avant la période, était de 2 121. L'écart de prévision est le réel moins le forecast : 2 020 − 2 121 = −101. La forecast accuracy, mesure de précision ici définie par 1 − |réel − prévision| / réel, vaut 1 − 101 / 2 020 = 0,95, soit 95 %.

Au départ, les sites utilisent des formules différentes et aucune validation commune. Le progrès de maturité consiste à imposer les mêmes définitions, conserver le forecast initial et faire expliquer la dégradation de marge par les responsables. Ces calculs ne prouvent pas sa cause : l'effet des prix, des volumes ou des consommations reste à analyser avant toute décision.

Le déploiement commence par un problème de gestion, non par un choix de logiciel. La gouvernance des données et des modèles de pilotage donne le cadre pour rendre les progrès durables.

1. Formaliser le besoin. Décrire la décision à améliorer, les difficultés actuelles et les risques associés. Le DAF désigne un responsable du chantier et fixe les limites du périmètre. Livrable : une note de cadrage qui précise l'objectif, les utilisateurs concernés et les critères d'acceptation.

2. Établir le diagnostic factuel. Suivre un cycle existant, de la collecte jusqu'à la décision. Relever les reprises manuelles, les contrôles absents, les versions contradictoires et les tâches dépendantes d'une seule personne. Livrable : une grille de maturité accompagnée de preuves et d'une liste des risques prioritaires.

3. Définir les règles communes. Fixer les définitions, les sources autorisées, les unités, les responsables et les modalités de validation. Le dictionnaire de données est le document qui décrit le sens, le format et les règles d'usage de chaque donnée. Livrables : ce dictionnaire, les règles de calcul et le calendrier de contribution.

4. Concevoir une cible limitée. Séparer ce qui relève de l'organisation, des données et de l'outillage. Prévoir un premier périmètre utilisable sans reproduire tous les fichiers historiques. Livrables : le modèle cible, la répartition des responsabilités et une feuille de route ordonnée selon les dépendances.

5. Tester avec les utilisateurs. La recette utilisateur est la vérification que le fonctionnement livré répond aux besoins convenus. Rejouer des cas connus : total incomplet, correction tardive, changement d'hypothèse et accès non autorisé. Livrables : des résultats de tests, une liste d'anomalies et une décision formelle d'acceptation.

6. Installer le fonctionnement courant. Former les contributeurs, organiser l'assistance et définir qui entretient les règles. Observer un cycle complet, puis comparer les résultats au diagnostic initial. Livrables : un guide d'utilisation, un suivi des incidents et un bilan de progression validé par la finance et les métiers.

Commencer par les décisions à éclairer

Une donnée n'a pas besoin d'être collectée simplement parce qu'elle existe. Partir des décisions attendues aide à choisir le détail utile, la fréquence de mise à jour et les personnes qui doivent contribuer. Cette discipline évite de construire un modèle volumineux dont les résultats ne sont jamais discutés.

Stabiliser les définitions avant d'automatiser

L'automatisation reproduit les règles configurées, qu'elles soient justes ou non. Définir les unités, les signes, les périodes et les méthodes de calcul avant de relier les fichiers ou les applications. Un contrôle indépendant doit vérifier les totaux et les comparaisons. Les limites d'Excel en finance tiennent notamment à la maîtrise des usages, pas uniquement au tableur lui-même.

Garder la preuve des hypothèses

Une prévision approuvée doit rester identifiable après une actualisation. Conserver sa date, son auteur, ses hypothèses et son périmètre permet d'analyser les écarts sans reconstruire l'histoire. La traçabilité est la capacité à retrouver l'origine d'une donnée et les transformations qu'elle a subies. Elle rend les échanges plus précis et les corrections plus sûres.

Faire participer les responsables opérationnels

La finance garantit la cohérence du modèle ; les métiers apportent la connaissance de l'activité. Cette séparation évite que le contrôleur de gestion invente seul les hypothèses commerciales ou les contraintes de production. Chaque contribution doit avoir un propriétaire, un délai et une procédure de validation compréhensible.

Préférer une progression vérifiable

Un rapprochement consiste à comparer des données ou des totaux provenant de sources distinctes et à expliquer leurs différences. Associer chaque chantier à une preuve de fonctionnement : une version effectivement verrouillée, un rapprochement réalisé ou une action clôturée avec justification. Une fonctionnalité disponible mais inutilisée ne constitue pas un progrès acquis. Les pratiques doivent rester applicables pendant les absences et les périodes de forte activité.

Prévoir l'entretien du modèle

Les produits, les structures et les responsabilités évoluent. Désigner les personnes autorisées à modifier les règles, documenter ces changements et vérifier leurs conséquences évite une dégradation progressive.

Assimiler maturité et équipement

Déployer un EPM ne rend pas automatiquement les données fiables ni les responsabilités claires. Le piège consiste à remplacer des fichiers dispersés par une application qui conserve les mêmes ambiguïtés. Pour l'éviter, valider les définitions et les règles de gestion avant leur traduction dans l'outil.

Réduire le diagnostic à une note globale

Une moyenne peut cacher une faiblesse critique : un processus bien documenté mais alimenté par des données non contrôlées reste fragile. Présenter les résultats par axe et signaler les points bloquants.

Prendre la vitesse pour la qualité

Un résultat diffusé plus tôt n'est utile que s'il est suffisamment fiable et expliqué. Mesurer le délai sans suivre les corrections encourage une publication prématurée. Associer l'observation du temps de production à celle des anomalies, des validations et de l'utilisation des résultats.

Reproduire tous les fichiers existants

Les classeurs historiques peuvent contenir des exceptions devenues inutiles ou des calculs dont personne ne connaît l'origine. Les recopier à l'identique fige ces défauts. Distinguer les exigences de gestion réellement nécessaires des habitudes de présentation, puis simplifier avec les utilisateurs.

Confondre objectif et prévision

Modifier le forecast pour qu'il corresponde au budget empêche d'anticiper une difficulté. Le budget exprime une référence approuvée ; le forecast estime ce qui devrait se produire. Conserver ces rôles distincts et discuter séparément les actions nécessaires pour réduire l'écart.

Automatiser sans contrôle de reprise

Un échange de données peut fonctionner techniquement tout en oubliant une entité ou en doublonnant une période. Vérifier avant diffusion la complétude, c’est-à-dire la présence de toutes les données attendues, rapprocher les totaux et examiner les rejets, c’est-à-dire les données non intégrées parce qu’elles ne respectent pas les règles d’import. Prévoir aussi une procédure de correction, avec une personne responsable et une preuve de validation.

Oublier le suivi des décisions

Une analyse pertinente peut rester sans effet si aucune action n'est attribuée. Terminer la revue par une décision, un responsable et une échéance. Au cycle suivant, vérifier ce qui a été réalisé et ce qui doit être révisé, sans confondre action exécutée et résultat obtenu.

Un KPI, ou indicateur clé de performance, est une mesure sélectionnée pour suivre un objectif et guider une décision. Pour évaluer la maturité, il faut combiner des mesures de fiabilité, de fonctionnement et d'usage. Aucun indicateur isolé ne résume toute la qualité du pilotage.

• Taux de contrôles conformes = contrôles réussis / contrôles exécutés × 100. Définir les contrôles attendus et suivre aussi ceux qui n'ont pas été exécutés, faute de quoi le taux peut sembler bon malgré une couverture insuffisante.
• Taux de livrables à l'heure = livrables transmis avant l'échéance / livrables attendus × 100. Fixer à l'avance ce qui constitue un livrable recevable : un fichier incomplet ne doit pas être considéré comme livré.
• Taux de corrections après validation = livrables corrigés après validation / livrables validés × 100. Distinguer une erreur de production d'un changement d'information légitime et conserver une règle de classement stable.
• Délai de production = date et heure de diffusion validée − date et heure de disponibilité des sources attendues. Préciser si la mesure utilise du temps calendaire ou du temps ouvré, et conserver la même convention.
• Forecast accuracy = 1 − |réel − prévision| / réel. Utiliser cette convention pour un réel strictement positif, avec une prévision figée et un périmètre comparable. Si le réel est nul, la formule est indéfinie ; s'il est négatif, choisir et documenter une mesure adaptée. Le résultat peut être négatif lorsque l'erreur dépasse le réel : ne pas le plafonner silencieusement. Voir la mesure de la fiabilité des prévisions.
• Taux d'actions réalisées à l'échéance = actions réalisées dans le délai / actions arrivées à échéance × 100. Vérifier séparément leurs effets : respecter une échéance ne prouve pas une amélioration du résultat.

Les livrables associés sont la grille de diagnostic, le dictionnaire de données, le calendrier, les règles de calcul, le registre des validations et le suivi des actions. Chaque indicateur doit avoir une source, un responsable et une fréquence. En cas de dénominateur nul, afficher « non applicable » et expliquer la situation plutôt que produire un pourcentage trompeur.

Un EPM peut fournir un cadre commun pour saisir les hypothèses, calculer les résultats, comparer les versions et organiser les validations. Son apport dépend du périmètre configuré et de l'usage réel, pas de la seule présence du logiciel.

La centralisation des données limite les copies concurrentes lorsque les utilisateurs travaillent sur les mêmes références. La gestion des versions distingue budget, forecast et simulations. Un workflow, ou circuit de traitement et de validation, organise la contribution, la revue et l'approbation. Les droits d'accès limitent les données consultables ou modifiables selon les responsabilités.

Les échanges automatisés avec les systèmes sources peuvent éviter certaines ressaisies. Ils doivent rester accompagnés de contrôles de complétude et de rapprochement des totaux. Les règles de calcul partagées rendent les résultats plus cohérents ; leur documentation reste nécessaire pour comprendre les exceptions. Les journaux de modification peuvent soutenir la traçabilité, selon les fonctions disponibles et leur configuration.

L'intégration consiste aussi à relier les hypothèses opérationnelles aux résultats financiers : les ventes influencent les volumes, les besoins de production et certaines dépenses. Elle ne signifie pas que toutes les données doivent être regroupées dans un seul outil. Des applications distinctes peuvent participer à un pilotage cohérent si leurs échanges, leurs définitions et leurs responsabilités sont maîtrisés.

Des solutions telles que OneStream, CCH Tagetik, Oracle EPM, SAP Analytics Cloud, Anaplan, Pigment, Board ou Workday Adaptive Planning peuvent être examinées selon le besoin. Leurs périmètres, modules et modalités de déploiement diffèrent : cette liste n'est ni un classement ni une affirmation d'équivalence.

Le panorama des éditeurs EPM aide à préparer une sélection. L'évaluation doit porter sur des cas de gestion représentatifs : correction d'une donnée, conservation d'une prévision, validation et changement de structure. Il faut aussi examiner l'administration, les compétences nécessaires, les coûts et la possibilité de récupérer les données. L'outil soutient la maturité ; il ne décide pas à la place de l'organisation.

Les niveaux suivants constituent une grille pédagogique, pas une norme universelle. Ils décrivent des pratiques observables. La progression débutant → intermédiaire → avancé peut varier selon les processus : la préparation budgétaire et le suivi des actions ne sont pas nécessairement au même stade.

Débutant : un fonctionnement dépendant des personnes

Les données sont collectées dans des fichiers dont les formats et les définitions varient. Les contrôles reposent sur l'expérience de quelques collaborateurs. La version approuvée est parfois difficile à identifier et les hypothèses sont peu documentées. Les réunions portent surtout sur la recherche du bon chiffre.

Le signe distinctif n'est pas l'utilisation d'Excel, mais la difficulté à reproduire le résultat sans son auteur habituel. Le progrès prioritaire consiste à formaliser les règles essentielles, attribuer les responsabilités et sécuriser les fichiers faisant référence. Il n'est pas nécessaire d'attendre un nouvel outil pour commencer.

Intermédiaire : des pratiques définies et répétables

Les définitions communes, le calendrier et les contrôles sont établis. Les versions de budget et de forecast sont distinctes. Les contributeurs connaissent leurs responsabilités et les résultats sont validés avant diffusion. Les écarts sont expliqués, mais certains échanges ou rapprochements restent manuels.

Le signe distinctif est la capacité à exécuter le cycle de façon cohérente, y compris en cas d'absence. La priorité devient la réduction des fragilités restantes : interfaces non contrôlées — les dispositifs permettant les échanges de données entre applications —, corrections tardives ou analyses encore déconnectées des décisions. Un EPM peut soutenir cette étape, sans constituer une condition suffisante.

Avancé : un pilotage intégré et entretenu

Les hypothèses des métiers et les résultats financiers sont reliés par des règles explicites. Les modifications sont traçables, les validations suivies et les prévisions conservées pour mesurer leur fiabilité. Les responsables discutent les causes des écarts, choisissent des actions et vérifient leurs effets.

Le signe distinctif est la capacité à adapter le pilotage sans perdre sa cohérence. Les changements de structure, de règles ou de sources sont encadrés et testés. Ce niveau n'exige pas une automatisation totale : une intervention manuelle peut rester pertinente si elle est justifiée, contrôlée et documentée.

Utilisez cette liste sur un processus précis et demandez une preuve pour chaque réponse positive. Une case cochée sur la base d'une intention ne démontre pas une capacité. Les réponses négatives servent à construire les priorités, pas à désigner des responsables à blâmer.

• [ ] Avons-nous défini les décisions que le processus doit éclairer et les utilisateurs de ses résultats ?
• [ ] Le périmètre, les périodes, les unités et les conventions de signe sont-ils explicites et partagés ?
• [ ] Chaque donnée importante possède-t-elle une source autorisée et un responsable de sa qualité ?
• [ ] Les mêmes entités, produits et comptes sont-ils décrits avec des codes communs dans les outils concernés ?
• [ ] Les règles de calcul sont-elles documentées et vérifiées indépendamment de leur auteur ?
• [ ] Peut-on distinguer sans ambiguïté le budget, le forecast approuvé et le réel ?
• [ ] Les hypothèses d'une prévision sont-elles conservées avec sa date, son auteur et son périmètre ?
• [ ] Les contrôles couvrent-ils la complétude des données, les doublons, les totaux et les anomalies de format ?
• [ ] Une personne identifiée décide-t-elle si les résultats peuvent être diffusés ?
• [ ] Les droits d'accès correspondent-ils aux responsabilités, notamment pour les données sensibles ?
• [ ] Peut-on retrouver l'origine d'une correction et la validation qui l'accompagne ?
• [ ] Les responsables opérationnels contribuent-ils aux hypothèses et à l'explication des écarts ?
• [ ] Chaque revue débouche-t-elle sur des décisions, des responsables et des échéances suivies ?
• [ ] Le processus reste-t-il utilisable lorsque son principal animateur est absent ?
• [ ] Mesurons-nous conjointement les délais, les erreurs, la fiabilité des prévisions et le suivi des actions ?
• [ ] Les changements de structure ou de règles sont-ils testés avant leur application courante ?
• [ ] Le choix d'un EPM éventuel repose-t-il sur des cas représentatifs plutôt que sur une démonstration générale ?
• [ ] Avons-nous prévu l'assistance aux utilisateurs et l'entretien du modèle après le déploiement ?

Pour conclure, regroupez les réponses par axe : données, méthodes, responsabilités, outils et décisions. Traitez d'abord les faiblesses qui rendent les résultats non fiables ou non utilisables. Vérifiez ensuite les progrès sur un cycle réel, avec les mêmes questions et des preuves comparables.

À retenir : la maturité du pilotage se juge à la fiabilité des données, à la cohérence des méthodes, à la clarté des responsabilités et au suivi des décisions. Excel et l'EPM sont des moyens. La bonne trajectoire corrige d'abord les risques prioritaires, puis intègre et automatise ce qui est suffisamment défini pour être maîtrisé.

Peut-on avoir un pilotage mature avec Excel ?

Oui, sur un périmètre adapté, si les définitions, les contrôles, les accès et les versions sont maîtrisés. La question décisive est la capacité à reproduire les résultats et à suivre les décisions sans dépendre d'une seule personne. Lorsque les contributions et les échanges deviennent difficiles à contrôler, un outil partagé peut être nécessaire. Ce besoin se démontre par les difficultés observées, pas par un seuil universel.

Quand faut-il envisager un EPM ?

Lorsque les besoins de collaboration, de validation, de traçabilité ou de liaison entre prévisions dépassent le fonctionnement actuel. Le diagnostic doit montrer ce que l'outil doit résoudre et ce qui exige d'abord une évolution des pratiques. Une sélection sérieuse teste les cas réels et tient compte de l'administration future, pas uniquement de la présentation des résultats.

Faut-il atteindre le niveau avancé sur tous les axes ?

Non. La cible doit être proportionnée aux risques, à la complexité et aux décisions attendues. Un processus stable et limité peut rester efficacement organisé avec peu d'automatisation. En revanche, une faiblesse critique de contrôle ou de responsabilité ne doit pas être compensée artificiellement par de bonnes performances sur d'autres axes.

Qui porte la progression de maturité ?

Le DAF fixe les priorités et les moyens. Le contrôle de gestion organise les méthodes et la lecture économique. Les métiers sont responsables de leurs hypothèses et de leurs actions ; l'informatique contribue à la sécurité et aux échanges de données. La progression exige cette responsabilité partagée : ni la finance seule ni l'outil seul ne peuvent l'assurer.

Comment prouver que la maturité a progressé ?

En comparant des pratiques observables avant et après : règles appliquées, versions conservées, contrôles exécutés, corrections expliquées et actions suivies. Une réduction du délai est utile, mais insuffisante si les erreurs augmentent. Le progrès doit être reproductible dans le fonctionnement courant et rester visible lorsque les personnes ou les structures changent.