reformulation des pratiques 006 a 010

2024-02-02 16:13:15 +01:00
parent 9c8294b0ac
commit b3864b8413
14 changed files with 899 additions and 1 deletions
--- a/chapters/MBP_001_fr.md
+++ b/chapters/MBP_001_fr.md
@@ -0,0 +1,43 @@
+## Éliminer les fonctionnalités non essentielles
+
+### Identifiants
+
+Bonne pratique originale : [BP_001](https://github.com/cnumr/best-practices/blob/main/chapters/BP_001_fr.md) 
+
+### Catégories
+
+| Cycle de vie |  Tiers  |  Responsable  |
+|:---------:|:----:|:----:|
+| 1. Spécification | Utilisateur/Terminal | PO/AMOA |
+
+### Indications
+
+| Degré de priorité |      Mise en oeuvre       |  Impact écologique    |
+|:-------------------:|:-------------------------:|:---------------------:|
+| 5 | 4 | 5 |
+
+|Ressources Economisées                                      |
+|:----------------------------------------------------------:|
+|Processeur / Mémoire vive / Stockage / Réseau / Requêtes    |
+
+### Description
+Plusieurs études (Cast Software et Standish Group, notamment) démontrent que 70 % des fonctionnalités demandées par les utilisateurs ne sont pas essentielles et que 45 % ne sont jamais utilisées. En réduisant la couverture et la profondeur fonctionnelle de l’application, on abaisse son coût de développement initial, sa dette technique 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. Il faut donc réduire le plus possible la couverture fonctionnelle de l’application, en la centrant sur le besoin essentiel de l’utilisateur.
+
+Détecter une fonctionnalité non essentielle est possible au moment de l'analyse de l'expression du besoin. La méthode MoSCoW, des ateliers, des wireframes (maquettes fonctionnelles) ou des prototypes avec tests utilisateurs permettent de vérifier l'utilité d’une fonctionnalité en amont de son développement.
+
+
+### Exemple
+Les succès récents du Web – Google, Twitter, WhatsApp, Pinterest, Instagram, etc. – fournissent un seul service et misent sur une grande sobriété fonctionnelle.
+
+Se poser, au moment de l'analyse de l'expression du besoin, la question : « Que se passe-t-il si on ne l’a pas ? ».
+
+Respecter le principe YAGNI (You Ain't Gonna Need It) de l’extreme programming : développez quand vous avez effectivement besoin d’une fonctionnalité, pas lorsque vous imaginez en avoir besoin.
+
+### Principe de validation
+
+
+| Le nombre ... |     est inférieur ou égal à   |  
+|-------------------|:-------------------------:|
+| de fonctionnalités dont l'utilité n'a pas été vérifiée avec un panel d'utilisateurs avant développement |  0 % |
--- a/chapters/MBP_002_fr.md
+++ b/chapters/MBP_002_fr.md
@@ -0,0 +1,49 @@
+## Quantifier précisément le besoin
+
+### Identifiants
+
+Pratique originale : [BP_002](https://github.com/cnumr/best-practices/blob/main/chapters/BP_002_en.md)
+
+### Catégories
+
+| Cycle de vie |  Tiers  |  Responsable  |
+|:---------:|:----:|:----:|
+| 1. Spécification | Utilisateur/Terminal | PO/AMOA |
+
+### Indications
+
+| Degré de priorité |      Mise en oeuvre       |  Impact écologique    |
+|:-------------------:|:-------------------------:|:---------------------:|
+| 5 | 4 | 5 |
+
+|Ressources Economisées                                      |
+|:----------------------------------------------------------:|
+|Processeur / Mémoire vive / Stockage / Réseau / Requêtes    |
+
+### Description
+
+Les « dimensions » de chaque fonctionnalité doivent être définies précisément et dans leur ensemble. Il peut s’agir 
+d’un taux de compression pour les images de l’interface graphique, du temps de réponse maximum pour une requête HTTP, 
+du nombre d’items affichés dans une liste, etc.
+
+Plus les « dimensions » et exigences associées à chaque fonctionnalité collent au métier, plus on évite la surqualité.
+La logique doit donc être inversée par rapport aux habitudes actuelles. Si une information n’est pas précisée, 
+c’est le niveau de qualité ou la quantité minimale qui est proposé. Par exemple, en l’absence de précision, 
+le nombre d’items d’une liste est limité à 5 éléments ou au nombre maximal affichable sur le plus petit écran cible de l’application.
+
+Les valeurs par défaut, rarement modifiées par l'utilisateur, doivent être choisies pour répondre au besoin avec un impact minimal.
+
+### Exemple
+
+Gain potentiel : en jouant sur le nombre d’items affichés sur la page de résultats de son moteur de recherche Bing, 
+Microsoft Research a démontré qu’il était possible de réduire jusqu’à 80 % l’infrastructure physique (nombre de serveurs) sous-jacente.
+
+Autre exemple : en utilisant par défaut une résolution de vidéo acceptable (480p) plutôt que maximale, on réduit la bande passante 
+utilisée pour la plupart des utilisateurs (qui ne changeront pas la valeur par défaut), tout en laissant la possibilité aux autres 
+d'augmenter la résolution s'ils en en ont le besoin.
+
+### Principe de validation
+
+| Le nombre ...     | est égal à   |  
+|-------------------|:-------------------------:|
+| de fonctionnalités avec des dimensions supérieures au besoin	| 0 |
--- a/chapters/MBP_003_fr.md
+++ b/chapters/MBP_003_fr.md
@@ -0,0 +1,43 @@
+## Optimiser le parcours utilisateur
+
+### Identifiants
+
+Bonne pratique originale : [BP_003](https://github.com/cnumr/best-practices/blob/main/chapters/BP_003_fr.md)
+
+### Catégories
+
+| Cycle de vie |  Tiers  |  Responsable  |
+|:---------:|:----:|:----:|
+| 2. Conception | Utilisateur/Terminal | UX/UI Designer |
+
+### Indications
+
+| Degré de priorité |      Mise en oeuvre       |  Impact écologique    |
+|:-------------------:|:-------------------------:|:---------------------:|
+| 5 | 4 | 5 |
+
+|Ressources Economisées                                      |
+|:----------------------------------------------------------:|
+|Processeur / Mémoire vive / Stockage / Réseau / Requêtes    |
+
+### Description
+
+Optimiser le parcours utilisateur consiste à diminuer le temps passé par l'utilisateur sur ses usages les plus fréquents. Dans un premier temps, cibler les parcours les plus fréquents puis optimiser leur usage : diminuer le nombre d'étapes, diminuer le nombre d'actions, supprimer l'inutile, identifier les cas d'échecs, optimiser les temps de réponse... Un parcours est bien conçu lorsque le programme se comporte exactement comme l'utilisateur l'avait imaginé.
+
+A minima, sonder en observant son entourage utilisant le service est un bon moyen d’identifier les points de friction - situations ou interactions qui contribuent à dégrader l’expérience utilisateur et à ralentir le parcours - des utilisateurs. Les tests utilisateurs permettent d'aller plus en profondeur dans la recherche de ces points de friction.
+
+Le temps passé par l'utilisateur sur son terminal est le deuxième post en termes d'impacts environnementaux.
+
+### Exemple
+
+* Proposer, pour une application de grande distribution, une nouvelle commande sur la base du contenu de la précédente.
+* Acheter sans inscription sur une application de type e-commerce.
+* Copier/Coller son RIB directement plutôt que le télécharger puis le transférer.
+* Mettre en avant les champs ou les filtres les plus utilisés.
+
+
+### Principe de validation
+
+|  Le nombre de | est inférieur à ou égal à  |  
+|-------------------|:-------------------------:|
+| points de friction | 0 |
--- a/chapters/MBP_004_fr.md
+++ b/chapters/MBP_004_fr.md
@@ -0,0 +1,86 @@
+## Préférer la saisie assistée à l'autocomplétion
+
+### Identifiants
+
+// TODO
+
+### Catégories
+
+| Cycle de vie |  Tiers  |  Responsable  |
+|:---------:|:----:|:----:|
+| 1. Spécification | Utilisateur/Terminal | PO/AMOA |
+
+### Indications
+
+| Degré de priorité |      Mise en oeuvre       |  Impact écologique    |
+|:-------------------:|:-------------------------:|:---------------------:|
+| 3 | 3 | 3 |
+
+|Ressources Economisées                                      |
+|:----------------------------------------------------------:|
+| Requêtes    |
+
+### Description
+
+L'autocomplétion, ou complément automatique est une fonctionnalité très répandue consistant à suggérer à l'utilisateur ou utilisatrice
+des résultats correspondant à sa recherche pendant sa saisie. Par exemple, un site permettant de rechercher un itinéraire
+va proposer « Paris », « Lyon Part-Dieu » et « Paray le Monial » quand la personne tape « Par ».
+
+L'implémentation de l'autocomplétion consiste à envoyer une requête au serveur à chaque caractère saisi pour récupérer les
+résultats correspondants. On peut donc avoir beaucoup de requêtes effectuées et beaucoup de ressources dépensées.
+
+Dans la mesure du possible, cette fonctionnalité est à remplacer par la saisie assistée.
+Cela consiste à guider la personne utilisatrice par un ensemble d’informations et d’indices : 
+ - Présentation du format attendu en grisé dans le champ de saisie (`placeholder`)
+ - Texte expliquant le format attendu
+ - Réaction de l’interface avec un message d’erreur ou un changement de couleur et aide textuelle lorsque la saisie est incorrecte
+ - etc.
+
+Les interactions liées à la saisie assistée sont gérées localement, ce qui réduit les échanges avec le serveur.
+
+
+Pour l'exemple de la recherche d'itinéraire et de la complétion des villes, il est possible, en cas d'ambiguïté, de proposer
+les différents résultats après la soumission du formulaire. L'utilisateur entre une chaine de caractère, par exemple « Lens »,
+soumet le formulaire, et se voit à ce moment proposées différentes options : « Lens (France) », « Lens (Belgique) », 
+« Loison sous Lens ».
+
+Si le recours à l'autocomplétion ne peut pas être évité il est possible de minimiser le nombre de requêtes avec des optimisations simples : 
+ - Ajouter un délai de quelque dixièmes de secondes entre l'ajout d'un caractère et la requête : cela permet de ne pas déclencher de requête si l'utilisateur n'a pas terminé sa saisie.
+ - Limiter le nombre de résultats affichés par l'autocomplétion, priorisés par une note de pertinence
+ - Fixer un nombre de caractères minimal avant de chercher à compléter.
+ - Si la taille de la base de données le permet, effectuer l'autocomplétion côté client en utilisant un composant natif comme `AutoCompleteTextView`
+ - Mettre en cache les résultats des recherches avec pour clef la chaîne saisie pour moins solliciter la base de données.
+ - Contextualiser les résultats pour en limiter le nombre.
+
+### Exemple
+
+Gain potentiel : à chaque fois que l’on utilise la saisie assistée pour une fonctionnalité, plutôt que l’autocomplétion, on réduit le nombre de requêtes associées par un facteur 10.
+
+### Solution alternative
+
+Si la donnée qui est proposée à l'utilisateur est assez petite en quantité, vous pouvez l'inclure directement dans le code de l'application en utilisant le composant natif `AutoCompleteTextView`. 
+
+```xml
+<AutoCompleteTextView
+    android:id="@+id/auto_complete_country_text_view"
+    android:layout_width="match_parent"
+    android:layout_height="wrap_content"/>
+```
+
+```kotlin
+val COUNTRIES = arrayOf("Belgium", "France", "Italy", "Germany", "Spain")
+val countriesAdapter = ArrayAdapter<String>(
+    this,
+    R.layout.simple_dropdown_item_1line,
+    COUNTRIES,
+)
+binding.autoCompleteCountryTextView.setAdapter(countriesAdapter)
+```
+
+Ce composant proposera nativement, et sans aller/retour avec le serveur, un mécanisme d'autocompletion.
+
+### Principe de validation
+
+| Le nombre ...     | est inférieur ou égal à   |  
+|-------------------|:-------------------------:|
+| de champs en autocomplétion  | 20%  |
--- a/chapters/MBP_005_fr.md
+++ b/chapters/MBP_005_fr.md
@@ -0,0 +1,48 @@
+## Favoriser un design simple, épuré, adapté au mobile
+
+### Identifiants
+
+// TODO
+
+### Catégories
+
+| Cycle de vie |  Tiers  |  Responsable  |
+|:---------:|:----:|:----:|
+| 2. Conception | Utilisateur/Terminal | UX/UI Designer |
+
+### Indications
+
+| Degré de priorité |      Mise en oeuvre       |  Impact écologique    |
+|:-------------------:|:-------------------------:|:---------------------:|
+| 4 | 3 | 4 |
+
+|Ressources Economisées                                      |
+|:----------------------------------------------------------:|
+| Processeur / Mémoire vive / Réseau   |
+
+### Description
+
+Tout design d'interface doit être réfléchi en amont, en prenant en compte :
+- les besoins de l'utilisateur (voir la bonne pratique "Optimiser le parcours utilisateur")
+- les heuristiques d'ergonomie (Bastien et Scapin, Nielsen, etc.)
+- les contraintes techniques
+- les bonnes pratiques d'écoconception
+- et les bonnes pratiques d'accessibilité
+
+**Privilégiez un design simple et épuré réalisable sans ajout de dépendances spécifiques.**
+
+### Exemple
+
+// TODO je ne comprends pas bien l'exemple. Il manque une illustration ?. A reformuler
+
+
+
+**Description :** Certains sites contiennent des images encadrées, non contrastées et non lisibles (RGAA) et créent une surcharge mentale non nécessaire (2.2. Densité Informationnelle de Scapin et Bastien). Téléchargées, elles ne sont pourtant pas visibles sur mobile (écoconception). On peut parfois soulever l'incohérence entre signalétique et colorimétrie (1.2.2. Groupement/Distinction par le Format de Scapin et Bastien).
+
+**Recommandation :** Supprimer les images de fond et ajouter un glyphe (Préférer les glyphes aux images, bonne pratique d'écoconception) avec une colorimétrie cohérente si un groupement doit avoir lieu.
+
+### Principe de validation
+
+| Le nombre ...     | est inférieur ou égal à   |  
+|-------------------|:-------------------------:|
+|   de pages dont le design est plus chargé que nécessaire  |  0 |
--- a/chapters/MBP_006_fr.md
+++ b/chapters/MBP_006_fr.md
@@ -0,0 +1,100 @@
+## Optimiser la récupération des données en fonction du cycle de vie
+
+### Identifiants
+
+### Catégories
+
+| Cycle de vie |  Tiers  |       Responsable        |
+|:---------:|:----:|:------------------------:|
+| 2. Conception | Utilisateur/Terminal | Developpeur/Développeuse |
+
+### Indications
+
+| Degré de priorité |      Mise en oeuvre       |  Impact écologique    |
+|:-------------------:|:-------------------------:|:---------------------:|
+| 3 | 4 | 3 |
+
+| Ressources Economisées |
+|:----------------------:|
+|    Mémoire / Réseau    |
+
+### Description
+
+Lorsqu'une personne navigue d'une vue à une autre au sein d'une application, mais également entre plusieurs applications sur son mobile, ces vues transitionnent entre différents états. Selon ces changements d'état, pour optimiser l'usage de la mémoire du téléphone, le système va effectuer des opérations telles que : libérer partiellement la mémoire si l'application passe en arrière-plan, supprimer complétement les données de la mémoire si l'utilisateur quitte la vue en cours en appuyant par exemple sur le bouton retour. Ces changements d'état sont matérialisés par le cycle de vie.
+
+Il convient d'optimiser l'accès aux données utilisées faites par la vue, afin d'éviter d'effectuer des requêtes en base de données locale ou sur le réseau à chaque changement d'état.
+
+Il existe plusieurs bonnes pratiques à appliquer à différents niveaux : 
+- À l'échelle de la vue :
+  - En utilisant correctement les callbacks du cycle de vie fournies par les composants `Activity` ou `Fragment`.
+- À l'échelle du `ViewModel` : 
+  - En utilisant une classe de type `ViewModel` (par exemple via l'implémentation fournie par l'API **Jetpack ViewModel**) ayant un cycle de vie plus long.
+ 
+#### A l'échelle de la vue : 
+
+Au sein d'une classe de type `Activity` ou `Fragment`, il est courant de surcharger une ou plusieurs méthodes du cycle de vie afin d'initialiser et d'adapter l'état de la vue (via les méthodes `onCreate`, `onResume`, `onPause`,`onStop`, etc.). Il est important d'éviter de récupérer inutilement les données depuis la base de données locale ou le réseau à chaque fois que la vue redevient visible et utilisable (état `RESUMED`), c'est-à-dire au sein de la fonction `onResume`.
+Il convient plutôt d'initialiser l'état de la vue au sein de la fonction `onCreate` et de récupérer les données dont elle a besoin soit dans l'état `CREATED`, soit dans l'état `STARTED`.
+
+Note : Dans certaines situations, il est conseillé de développer ses propres composants "lifecycle aware" afin d'être notifié de la même façon de ces changements d'états, afin de rendre le code plus maintenable.
+
+#### A l'échelle du `ViewModel` 
+
+Une classe de type `ViewModel` a un cycle de vie d'une durée de vie plus longue qu'une `Activity` ou un `Fragment`.
+Gérer et maintenir les données de la vue au sein de ce type de classe permet de les garder en mémoire durant toute la durée de vie de la vue. Typiquement lors des changements de configuration (ex : l'utilisateur change l'orientation de l'écran) ou lorsque la vue passe en arrière-plan. Les données dont la vue a besoin pour se restaurer suite à ces changements restent ainsi accessibles sans avoir besoin d'effectuer une nouvelle requête en base de données ou sur le serveur. L'accès en lecture et en écriture aux données en mémoire est plus rapide et moins consommateur. De plus, une fois que la vue associée au ViewModel est détruit, par exemple si l'utilisateur quitte l'écran en appuyant sur le bouton retour, le ViewModel est aussi détruit, libérant ainsi les données de la mémoire précédemment stockées.
+
+### Exemple
+
+Soit une vue d'une application affichant le profil d'un utilisateur : 
+
+`MainActivity.kt` : 
+
+
+```
+class ProfileActivity : ComponentActivity() {
+
+    private val viewModel: ProfileViewModel by viewModels()
+
+    override fun onCreate(savedInstanceState: Bundle?) {
+        super.onCreate(savedInstanceState)
+
+        // Update the uiState
+        lifecycleScope.launch {
+            lifecycle.repeatOnLifecycle(Lifecycle.State.STARTED) {
+                viewModel.uiState.collectLatest {
+                    // TODO update view
+                }
+            }
+        }
+    }
+}
+```
+
+`ProfileViewModel.kt` : 
+
+```
+
+class ProfileViewModel(userRepository: UserRepository) : ViewModel() {
+
+    val uiState: StateFlow<ProfileUIState> = userRepository.userData.map {
+        ProfileUIState.Success(it)
+    }.stateIn(
+        scope = viewModelScope,
+        initialValue = ProfileUIState.Loading,
+        started = SharingStarted.WhileSubscribed(5_000),
+    )
+}
+
+sealed interface ProfileUIState {
+    data object Loading : ProfileUIState
+    data class Success(val user: User) : ProfileUIState
+}
+
+```
+
+### Principe de validation
+
+| Le nombre ...                                                                                    | est inférieur ou égal à |  
+|--------------------------------------------------------------------------------------------------|:-----------------------:|
+| d'écran effectuant des chargements de données à chaque fois que la vue passe dans l'état `RESUMED` |           0%            |
+| d'écran rechargeant l'ensemble des données lors d'un changement de configuration                 |           0%            |
+| d'écran n'utilisant pas de ViewModel ou équivalent pour maintenir l'état de la vue               |           0%            |
--- a/chapters/MBP_006bis_fr.md
+++ b/chapters/MBP_006bis_fr.md
@@ -0,0 +1,46 @@
+## Mettre en pause les traitements consommateurs lorsque l'application est en arrière-plan
+
+### Identifiants
+
+// TODO
+
+### Catégories
+
+| Cycle de vie |  Tiers  |       Responsable        |
+|:---------:|:----:|:------------------------:|
+| 2. Conception | Utilisateur/Terminal | Developpeur/Développeuse |
+
+### Indications
+
+| Degré de priorité |      Mise en oeuvre       |  Impact écologique    |
+|:-------------------:|:-------------------------:|:---------------------:|
+| 3 | 4 | 3 |
+
+| Ressources Economisées |
+|:----------------------:|
+|   Mémoire / Batterie   |
+
+### Description
+
+Lorsqu'une personne navigue entre plusieurs applications sur son mobile, ces applications basculent entre premier plan et arrière-plan. Lorsqu'une application qui effectue un traitement consommateur en mémoire passe en arrière-plan, il convient de s'appuyer sur son cycle de vie pour réduire l'impact de ce traitement sur la batterie du téléphone.
+* Dans la fonction `onPause`, l'activité est toujours visible à l'écran, mais l'utilisateur ne peut plus interagir avec.
+- Dans la fonction `onStop`, l'activité n'est plus visible.
+
+Au sein de ses deux callbacks, une bonne pratique est de libérer ou d'ajuster les ressources consommatrices initialisées précédemment.
+
+Quelques exemples de traitements consommateurs : 
+* L'affichage d'une animation
+* La lecture d'une vidéo ou d'un son.
+* L'usage des capteurs du téléphone : le GPS, le gyroscope.
+* L'usage de protocol de connectivité : Bluetooth, Wifi, NFC, etc.
+
+### Exemple 
+* Soit une application utilisant la position GPS du téléphone. Lorsque l'activité n'est plus visible, il faut désactiver la mise à jour de la position dans la fonction `onStop` ou si cela n'est pas possible, changer la granularité de mise à jour de la position de "fine" à "grossière".
+* Soit une activité `PhotoActivity` qui utilise l'appareil photo. Lorsqu'une autre activité prend le focus sur celle-ci par exemple sous forme de modale, mais que la première activité restent visible dessous (dans l'état `PAUSED`), il faut appeler la fonction `camera?.release()` dans la callback `onPause`. 
+
+### Principe de validation
+
+| Le nombre ...                                                                                                                                                  | est inférieur ou égal à   |  
+|----------------------------------------------------------------------------------------------------------------------------------------------------------------|:-------------------------:|
+| de traitement lourds pour lesquels la mémoire n'est pas libéré dans les fonctions `onPause` ou `onStop`                                                        |  0% |
+
--- a/chapters/MBP_007_fr.md
+++ b/chapters/MBP_007_fr.md
@@ -0,0 +1,41 @@
+## Stocker localement les données de l'utilisateur
+
+### Identifiants
+
+// TODO
+
+### Catégories
+
+| Cycle de vie |  Tiers  |  Responsable  |
+|:---------:|:----:|:----:|
+| 3. Réalisation (fabrication / développement) | Datacenter | Architecte Logiciel/Développeur |
+
+### Indications
+
+| Degré de priorité |      Mise en oeuvre       |  Impact écologique    |
+|:-------------------:|:-------------------------:|:---------------------:|
+| 4 | 3 | 4 |
+
+|Ressources Economisées                                      |
+|:----------------------------------------------------------:|
+| Réseau / Requêtes    |
+
+### Description
+
+Il est inutile de stocker sur le serveur des données qui n'ont de sens que pour un utilisateur donné.
+
+Il existe différents moyens permettant de stocker ce type de données en local sur un téléphone : 
+* Le stockage sous forme de clé valeur, grâce par exemples aux SharedPreferences.
+* Le stockage au sein de la base de données locale (via SQLite ou Room par exemple).
+
+L’intérêt du stockage local est double. D’une part, on évite les allers-retours inutiles avec le serveur, ce qui économise des ressources et du temps de réponse.
+D’autre part, comme les données sont locales, il est plus facile et plus rapide de les manipuler au sein de l’interface.
+
+Le gain potentiel est la réduction de la charge serveur, donc du nombre d’équipements nécessaires (de leur empreinte environnementale et économique),
+des serveurs HTTP jusqu’aux serveurs de base de données.
+
+### Principe de validation
+
+| Le nombre ...     | est inférieur ou égal à   |  
+|-------------------|:-------------------------:|
+| de données statiques non stockées localement  | 25%  |
--- a/chapters/MBP_008_fr.md
+++ b/chapters/MBP_008_fr.md
@@ -0,0 +1,31 @@
+## Déployer un Android App Bundle (AAB) plutôt qu'un APK
+
+### Identifiants
+
+// TODO
+
+### Catégories
+
+| Cycle de vie | Tiers |       Responsable        |
+|:---------:|:-----:|:------------------------:|
+| 2. Conception |  Utilisateur/Terminal   | Développeur/Développeuse |
+
+### Indications
+
+| Degré de priorité |      Mise en oeuvre       |  Impact écologique    |
+|:-------------------:|:-------------------------:|:---------------------:|
+| 3 | 3 | 3 |
+
+|Ressources Economisées                                      |
+|:----------------------------------------------------------:|
+|  Processeur / Mémoire vive / Stockage  |
+
+### Description
+
+Un Android App Bundle (AAB) contient tout le code compilé et les ressources d'une application, mais délègue au Google Play Store la responsabilité de générer et signer l'APK qui sera installé sur l'appareil de l'utilisateur. Celui-ci optimise ainsi l'APK en n'y incluant que les ressources nécessaires selon la configuration de l'appareil. Cela permet de réduire considérablement la taille de l'application.
+
+### Principe de validation
+
+| Le nombre ... | est inférieur ou égal à   |  
+|---------------|:-------------------------:|
+| d'APK déployé | 0  |
--- a/chapters/MBP_009_fr.md
+++ b/chapters/MBP_009_fr.md
@@ -0,0 +1,39 @@
+## Supprimer les ressources non utilisées
+
+### Identifiants
+
+// TODO
+
+### Catégories
+
+| Cycle de vie | Tiers |       Responsable        |
+|:---------:|:-----:|:------------------------:|
+| 4. Production |  Utilisateur/Terminal   | Développeur/Développeuse |
+
+### Indications
+
+| Degré de priorité |      Mise en oeuvre       |  Impact écologique    |
+|:-------------------:|:-------------------------:|:---------------------:|
+| 3 | 3 | 3 |
+
+|Ressources Economisées                                      |
+|:----------------------------------------------------------:|
+|  Processeur / Mémoire vive / Stockage  |
+
+### Description
+
+Supprimer les ressources et les classes non utilisées permet de réduire la taille de l'application. 
+
+Il existe plusieurs moyens d'appliquer cela : 
+- Utiliser le linter inclus dans Android Studio qui détecte les ressources (`res/`) non utilisées et les supprimer manuellement.
+
+```shell
+res/layout/item_row.xml: Warning: The resource R.layout.item_row appears
+    to be unused [UnusedResources]
+```
+
+### Principe de validation
+
+| Le nombre ...                                 | est inférieur ou égal à   |  
+|-----------------------------------------------|:-------------------------:|
+| de fichier non utilisé dans le package final  | 0  |
--- a/chapters/MBP_010_fr.md
+++ b/chapters/MBP_010_fr.md
@@ -0,0 +1,64 @@
+## Minifier et optimiser le code
+
+### Identifiants
+
+// TODO
+
+### Catégories
+
+| Cycle de vie  |  Tiers  |  Responsable  |
+|:-------------:|:----:|:----:|
+| 4. Production |  Utilisateur/Terminal   | Développeur/Développeuse |
+
+### Indications
+
+| Degré de priorité |      Mise en oeuvre       |  Impact écologique    |
+|:-------------------:|:-------------------------:|:---------------------:|
+| 4 | 3 | 4 |
+
+| Ressources Economisées |
+|:----------------------:|
+|  Processeur / Mémoire vive / Stockage  |
+
+### Description
+
+Utiliser un outil de minification et d'optimisation de code permet de réduire considérable la taille de l'application. 
+Sur android, cet outil se décompose en quatre processus : 
+-La minification, qui consiste à supprimer les espaces inutiles, les commentaires, les sauts de ligne, les délimiteurs de blocs et ainsi réduire la taille de l'application finale.
+- La suppression des ressources non utilisées dans notre code mais également dans les bibliothèques tierces incluses dans notre projet, par exemple si notre code n'utilise qu'une petite partie de celles-ci.
+- L'obfuscation. Ce processus réduit le nom des classes et de ses membres, augmentant la sécurité et réduisant par la même occasion la taille des fichiers. Par exemple la classe : `com.monpackage.MaClass` devient une fois compilée : `a.a.B`
+- L'optimisation. Ce processus inspecte et optimize le code pour supprimer le code qui n'est jamais exécutée. Par exemple il peut détecter que la branche `else` d'une condition n'est jamais empruntée, et donc la supprimer du code compilé.
+
+Pour activer et configurer ces processus, il faut activer les paramètres `isShrinkResources` et `isMinfyEnabled` dans le fichier Gradle de l'application, dans les paramètres du build qui sera déployé. Au-delà de ses paramètres, il faut ensuite spécifier les processus qui doivent s'appliquer et sur quelles classes dans le fichier `proguard-rules.pro` du projet.
+
+
+
+### Exemple
+
+
+```kotlin
+android {
+    buildTypes {
+        getByName("release") {
+            // Enables code shrinking, obfuscation, and optimization for the release build type
+            isMinifyEnabled = true
+
+            // Enables resource shrinking, which is performed by the Android Gradle plugin.
+            isShrinkResources = true
+
+            // Includes the default ProGuard rules files
+            proguardFiles(
+                getDefaultProguardFile("proguard-android-optimize.txt"),
+                "proguard-rules.pro"
+            )
+        }
+    }
+    ...
+}
+```
+
+### Principe de validation
+
+| Le nombre ...                      | est inférieur ou égal à |  
+|------------------------------------|:-----------------------:|
+| de fichiers non minifiés/optimisés |           25            |