cnumr · rlemaire · Oct 7, 2025
diff --git a/README.md b/README.md
@@ -23,5 +23,5 @@ N'hésitez pas à lire [le guide des contributeurs](CONTRIBUTING.md).
 * [Répartir les builds dans le temps](practices/11_repartir-les-builds-dans-le-temps.md)
 * [Limiter le nombre de conteneurs utilisés pendant le développement](practices/12_limiter-le-nombre-de-conteneurs-utilises-pendant-le-developpement.md)
 * [Vérifier régulièrement la consommation des conteneurs déployés](practices/13_verifier-regulierement-la-consommation-des-conteneurs-deployes.md)
-* [Monitorer les ressources](practices/14_monitorer-des-ressources.md)
+* [Monitorer les ressources](practices/14_monitorer-les-ressources)
 * [Proposer le module durabilité aux clients](practices/15_proposer-le-module-durabilite-aux-clients.md)
diff --git a/practices/08_supprimer-les-conteneurs-qui-ne-sont-plus-utiles.md b/practices/08_supprimer-les-conteneurs-qui-ne-sont-plus-utiles.md
@@ -41,8 +41,8 @@ donc plus utile.
 
 | Le nombre...                             | est égal à |
 |------------------------------------------|------------|
-| de conteneurs par développeur est        | 0          |
-| de conteneurs par consultant fonctionnel | 0          |
+| de conteneurs par développeur est        | 5          |
+| de conteneurs par consultant fonctionnel | 2          |
 
 
 ## Liens avec le RGESN

diff --git a/practices/14_monitorer-des-ressources.md → practices/14_monitorer-les-ressources.md b/practices/14_monitorer-des-ressources.md → practices/14_monitorer-les-ressources.md
@@ -51,10 +51,10 @@ Solutions que l’on peut mettre en place :
 
 ### Principe de validation
 
-| Le nombre...                                                                                              | est supérieur ou égal à |
-|-----------------------------------------------------------------------------------------------------------|-------------------------|
-| De projet avec suivi des consommations systèmes des clients                                               | 90%                     |
-| De nos clients ayant des alertes sur la sur-sous consommations systèmes et/ou projections de consommation | 90%                     |
+| Le nombre...                                                                                           | est supérieur ou égal à |
+|--------------------------------------------------------------------------------------------------------|-------------------------|
+| De projets avec suivi des consommations systèmes des clients                                           | 90%                     |
+| De clients ayant des alertes sur la sur ou sous consommation système et/ou projections de consommation | 90%                     |
 
 
 ## Liens avec le RGESN

diff --git a/practices/REIPRO_001_bien-quantifier-le-besoin.mdx b/practices/REIPRO_001_bien-quantifier-le-besoin.mdx
@@ -0,0 +1,45 @@
+---
+refID: '001'
+title: Bien quantifier le besoin
+createdAt: 2025-10-01T10:00:00.000Z
+updatedAt: 2025-10-01T10:00:00.000Z
+language: fr
+published: true
+refType: REIPRO
+versions:
+  - version: 1.0.0
+    idRef: '001'
+people: NA
+responsible:
+  - responsible: src/content/personas/fr/architecte-logicieldeveloppeur.mdx
+  - responsible: src/content/personas/fr/poamoa.mdx
+lifecycle: 1-specification
+rgesn: 3.2
+environmental_impact: 1
+priority_implementation: 1
+moe: 3
+tiers: user-device
+saved_resources:
+  - cpu
+  - ram
+  - storage
+  - network
+  - requests
+validations:
+  - rule: de fonctionnalités avec des dimensions supérieures au besoin
+    maxValue: '0'
+---
+
+## Description
+
+Les « dimensions » de chaque fonctionnalité doivent être définies
+précisément et dans leur ensemble. Exemples : le nombre d'éléments
+affichés dans un écran, la quantité de ressources réservée pour un
+composant.
+
+Si une information n'est pas précisée, c'est le niveau de qualité ou la
+quantité minimale qui est proposé. Par exemple 10 éléments affichés par
+défaut.
+
+Les valeurs par défaut, rarement modifiées par l\'utilisateur, doivent
+être choisies pour répondre au besoin avec un impact minimal.
diff --git a/practices/REIPRO_002_ne-retenir-que-les-fonctionnalites-essentielles.mdx b/practices/REIPRO_002_ne-retenir-que-les-fonctionnalites-essentielles.mdx
@@ -0,0 +1,43 @@
+---
+refID: '001'
+title: Retenir uniquement les fonctionnalités essentielles
+createdAt: 2025-10-01T10:00:00.000Z
+updatedAt: 2025-10-01T10:00:00.000Z
+language: fr
+published: true
+refType: REIPRO
+versions:
+  - version: 2.0.0
+    idRef: '002'
+people: NA
+responsible:
+  - responsible: src/content/personas/fr/architecte-logicieldeveloppeur.mdx
+  - responsible: src/content/personas/fr/poamoa.mdx
+lifecycle: 1-specification
+rgesn: 1.1
+environmental_impact: 2
+priority_implementation: 2
+moe: 3
+tiers: user-device
+saved_resources:
+  - cpu
+  - ram
+  - storage
+  - network
+  - requests
+validations:
+  - rule: de fonctionnalités dont l'utilité n'a pas été vérifiée avec un panel d'utilisateurs avant développement
+    maxValue: '0'
+---
+
+## Description
+
+Tout ajout de fonctionnalité implique plus de ressources dépensées, plus de code, plus d’assets, etc. Dans beaucoup de
+produits, des fonctionnalités ne sont peu ou pas utilisées. En réduisant la couverture et la profondeur fonctionnelle
+de l’application, on abaisse son coût de développement initial et les impacts environnementaux associés.
+
+On diminue ainsi mécaniquement l’infrastructure nécessaire à son exécution. Par ailleurs, à niveau ergonomique constant,
+plus l’application est pauvre fonctionnellement, plus elle sera simple à utiliser.
+
+Détecter une fonctionnalité non essentielle est possible au moment de l'analyse de l'expression du besoin et des étapes
+suivantes de conception et de priorisation fonctionnelles.
diff --git a/practices/REIPRO_003_minimiser-le-nombre-de-developpements-specifiques.mdx b/practices/REIPRO_003_minimiser-le-nombre-de-developpements-specifiques.mdx
@@ -0,0 +1,41 @@
+---
+refID: '003'
+title: Minimiser le nombre de développements spécifiques
+createdAt: 2025-10-01T10:00:00.000Z
+updatedAt: 2025-10-01T10:00:00.000Z
+language: fr
+published: true
+refType: REIPRO
+versions:
+  - version: 3.0.0
+    idRef: '003'
+people: NA
+responsible:
+  - responsible: src/content/personas/fr/architecte-logicieldeveloppeur.mdx
+  - responsible: src/content/personas/fr/poamoa.mdx
+lifecycle: 1-specification
+rgesn: 1.1
+environmental_impact: 1
+priority_implementation: 2
+moe: 2
+tiers: user-device
+saved_resources:
+  - cpu
+  - ram
+  - storage
+  - network
+  - requests
+validations:
+  - rule: de développements spécifiques mis en œuvre alors que le standard pourrait suffire
+    maxValue: '0'
+---
+
+## Description
+
+Lors des ateliers d'analyse et diagnostic, il est primordial de proposer en priorité les fonctionnalités standards et
+de challenger fortement les besoins qui nécessitent du développement spécifique, afin de les éviter.
+
+En réalisant des interviews utilisateurs, on peut détecter les besoins, non impératif ou pouvant être réalisé en
+adaptant ses usages aux fonctionnalités "out-of-the-box" plutôt que d'adapter les logiciels à ses usages.
+
+Les fonctionnalités spécifiquement adaptées seront un coût en RUN.
diff --git a/...supprimer-les-developpements-specifiques-inclus-dans-les-nouveaux-standards.mdx b/...supprimer-les-developpements-specifiques-inclus-dans-les-nouveaux-standards.mdx
@@ -0,0 +1,39 @@
+---
+refID: '004'
+title: Supprimer les développements spécifiques couverts par les nouveaux standards
+createdAt: 2025-10-01T10:00:00.000Z
+updatedAt: 2025-10-01T10:00:00.000Z
+language: fr
+published: true
+refType: REIPRO
+versions:
+  - version: 4.0.0
+    idRef: '004'
+people: NA
+responsible:
+  - responsible: src/content/personas/fr/architecte-logicieldeveloppeur.mdx
+  - responsible: src/content/personas/fr/poamoa.mdx
+lifecycle: 6-support
+rgesn: 2.7
+environmental_impact: 2
+priority_implementation: 3
+moe: 3
+tiers: user-device
+saved_resources:
+  - cpu
+  - ram
+  - storage
+  - network
+  - requests
+validations:
+  - rule: Développements spécifiques qui peuvent être remplacés par une fonctionnalité standard…
+    maxValue: '0'
+---
+
+## Description
+
+Dans l’objectif de conserver la solution déployée la plus sobre et la plus optimisée possible, il est intéressant de
+décommissionner les développements spécifiques qui deviennent inclus dans les standards.
+
+Cela permet de réduire la taille du livrable (code, assets, …) et de profiter des éventuelles optimisations mises en
+place par Microsoft pour ce besoin ainsi que des mises à jour automatiques issues du feedback du monde entier.
diff --git a/practices/REIPRO_005_supprimer-les-developpements-specifiques-non-utilises.mdx b/practices/REIPRO_005_supprimer-les-developpements-specifiques-non-utilises.mdx
@@ -0,0 +1,49 @@
+---
+refID: '005'
+title: Supprimer les développements spécifiques non utilisés
+createdAt: 2025-10-01T10:00:00.000Z
+updatedAt: 2025-10-01T10:00:00.000Z
+language: fr
+published: true
+refType: REIPRO
+versions:
+  - version: 5.0.0
+    idRef: '005'
+people: NA
+responsible:
+  - responsible: src/content/personas/fr/architecte-logicieldeveloppeur.mdx
+  - responsible: src/content/personas/fr/poamoa.mdx
+lifecycle: 6-support
+rgesn: 2.7
+environmental_impact: 2
+priority_implementation: 3
+moe: 3
+tiers: user-device
+saved_resources:
+  - cpu
+  - ram
+  - storage
+  - network
+  - requests
+validations:
+  - rule: fonctionnalités réclamant un développement spécifique qui ne sont plus utilisées…
+    maxValue: '0'
+---
+
+
+## Description
+
+Il arrive que des fonctionnalités ne soient plus utilisées parce que le besoin des utilisateurs a changé. Dans le but
+de simplifier l’application et de l’alléger, ces développements spécifiques doivent être supprimés. Cela permet de
+réduire l’empreinte technique (RAM, CPU, etc.) côté client comme côté serveur. On contribue ainsi à réduire les
+impacts environnementaux inutiles.
+
+L'identification de ces développements peut se faire par télémétrie, mais aussi et surtout par la connaissance de
+l’équipe sur le produit déployé et le client.
+
+## Exemples avec Business Central
+
+* Identifier dans quelle mesure les traitements de report avec mise à jour des coûts sont lancés
+* Identifier la fréquence d’utilisation des pages statistiques (avec les prix de ventes marges etc.)
+* Vérifier l'utilisation des Factbox sur les pages
+* Idem pour Pack & ship qui donne des statistiques de performance
diff --git a/practices/REIPRO_006_lisser-la-charge.mdx b/practices/REIPRO_006_lisser-la-charge.mdx
@@ -0,0 +1,37 @@
+---
+refID: '006'
+title: Reporter les tâches qui peuvent l'être pour lisser la charge
+createdAt: 2025-10-01T10:00:00.000Z
+updatedAt: 2025-10-01T10:00:00.000Z
+language: fr
+published: true
+refType: REIPRO
+versions:
+  - version: 6.0.0
+    idRef: '006'
+people: NA
+responsible:
+  - responsible: src/content/personas/fr/architecte-logicieldeveloppeur.mdx
+  - responsible: src/content/personas/fr/codeuseur-developpeuser.mdx
+lifecycle: 3-developement
+rgesn: 3.2
+environmental_impact: 3
+priority_implementation: 3
+moe: 3
+tiers: datacenter
+saved_resources:
+  - cpu
+  - ram
+validations:
+  - rule: de conteneurs dont les dimensions sont calibrées pour une charge importante limitée à moins de 10% de sa vie
+    maxValue: '0'
+---
+
+## Description
+
+Dans certains cas, il est possible de décaler des traitements applicatifs dans le temps de telle sorte que la charge
+serveur soit lissée. C’est particulièrement intéressant si des pics de charge ponctuels nécessitent de dimensionner
+le composant (conteneur) à une taille plus grande que ce qui est requis la majeure partie du temps.
+
+Utiliser une stratégie asynchrone et une mise en attente (par exemple avec une file d’attente) des traitements permet
+de limiter la consommation de ressources.
diff --git a/practices/REIPRO_007_minimiser-les-ressources-necessaires-au-projet.mdx b/practices/REIPRO_007_minimiser-les-ressources-necessaires-au-projet.mdx
@@ -0,0 +1,38 @@
+---
+refID: '007'
+title: Minimiser les ressources nécessaires au projet
+createdAt: 2025-10-01T10:00:00.000Z
+updatedAt: 2025-10-01T10:00:00.000Z
+language: fr
+published: true
+refType: REIPRO
+versions:
+  - version: 7.0.0
+    idRef: '007'
+people: NA
+responsible:
+  - responsible: src/content/personas/fr/poamoa.mdx
+  - responsible: src/content/personas/fr/architecte-logicieldeveloppeur.mdx
+  - responsible: src/content/personas/fr/codeuseur-developpeuser.mdx
+lifecycle: 2-concept
+rgesn: 4.8, 5.1, 5.7
+environmental_impact: 2
+priority_implementation: 3
+moe: 4
+tiers: user-device
+saved_resources:
+  - storage
+  - network
+validations:
+  - rule: de polices téléchargées
+    maxValue: '2'
+  - rule: d’images téléchargées par écran
+    maxValue: '10'
+---
+
+## Description
+
+Les ressources embarquées par le projet (polices de caractères, images, fichiers multimédias, …) alourdissent le
+livrable et nécessitent de la bande passante.
+
+Il faut les minimiser.
diff --git a/practices/REIPRO_008_supprimer-les-conteneurs-qui-ne-sont-plus-utiles.mdx b/practices/REIPRO_008_supprimer-les-conteneurs-qui-ne-sont-plus-utiles.mdx
@@ -0,0 +1,41 @@
+---
+refID: '008'
+title: Supprimer les containers qui ne sont plus utiles
+createdAt: 2025-10-01T10:00:00.000Z
+updatedAt: 2025-10-01T10:00:00.000Z
+language: fr
+published: true
+refType: REIPRO
+versions:
+  - version: 8.0.0
+    idRef: '008'
+people: NA
+responsible:
+  - responsible: src/content/personas/fr/codeuseur-developpeuser.mdx
+lifecycle: 3-developement
+rgesn: 2.7
+environmental_impact: 3
+priority_implementation: 3
+moe: 4
+tiers: datacenter
+saved_resources:
+  - storage
+validations:
+  - rule: de conteneurs par développeur est
+    maxValue: '5'
+  - rule: de conteneurs par développeur est
+    maxValue: '2'
+---
+
+## Description
+
+Le dimensionnement de la BDD de Docker est directement corrélé au nombre de conteneurs activables. Pour chaque
+conteneur (actif ou non), Docker garde une copie de la BDD et du paramétrage serveur Business Central.
+
+Il n’est pas nécessaire de garder des données qui ne seront jamais réutilisées par la suite. De plus, il est
+préférable de recréer un conteneur lors d’une nouvelle session de DEV pour être sûr d’avoir le dernier contexte client.
+
+## Exemple
+J’ai fait un dev il y a un mois. Je dois refaire un dev aujourd’hui. Mon client étant en SaaS, la version de Business
+Central a sûrement changé. Il faut donc que je travaille sur un nouveau conteneur. Mon ancien conteneur n'est
+donc plus utile.