diff --git a/docs/.vuepress/config.js b/docs/.vuepress/config.js
index 5ca3259a..1e177a30 100644
--- a/docs/.vuepress/config.js
+++ b/docs/.vuepress/config.js
@@ -52,31 +52,42 @@ module.exports = {
     sidebarDepth: 2,
     lastUpdated: true,
     footerCopyright: 'Apache 2.0 Licensed | Copyright © 2020 - 2024 Mojaloop Foundation',
-    // PR Preview configuration
     isPrPreview: isPrPreview,
     prNumber: process.env.VUEPRESS_PR_NUMBER || '',
-    nav: [
-      {
-        text: 'Adoption',
-        link: '/adoption/',
-      },
-      {
-        text: 'Community',
-        link: '/community/'
-      },
-      {
-        text: 'Technical',
-        link: '/technical/'
+    locales: {
+      '/': {
+        selectText: 'Languages',
+        label: 'English',
+        editLinkText: 'Edit this page on GitHub',
+        lastUpdated: 'Last Updated',
+        nav: [
+          { text: 'Adoption', link: '/adoption/' },
+          { text: 'Community', link: '/community/' },
+          { text: 'Technical', link: '/technical/' },
+          { text: 'Product', link: '/product/' },
+          { text: 'Training Program', link: 'https://mojaloop.io/mojaloop-training-program/' }
+        ],
       },
-      {
-        text: 'Product',
-        link: '/product/'
-      },
-
-      {
-        text: 'Training Program',
-        link: 'https://mojaloop.io/mojaloop-training-program/'
+      '/fr/': {
+        selectText: 'Langues',
+        label: 'Français',
+        editLinkText: 'Modifier cette page sur GitHub',
+        lastUpdated: 'Dernière mise à jour',
+        nav: [
+          { text: 'Adoption', link: '/fr/adoption/' },
+          { text: 'Communauté', link: '/fr/community/' },
+          { text: 'Technique', link: '/fr/technical/' },
+          { text: 'Produit', link: '/fr/product/' },
+          { text: 'Programme de formation', link: 'https://mojaloop.io/mojaloop-training-program/' }
+        ],
       }
+    },
+    nav: [
+      { text: 'Adoption', link: '/adoption/' },
+      { text: 'Community', link: '/community/' },
+      { text: 'Technical', link: '/technical/' },
+      { text: 'Product', link: '/product/' },
+      { text: 'Training Program', link: 'https://mojaloop.io/mojaloop-training-program/' }
     ],
     // Ref: https://vuepress.vuejs.org/theme/default-theme-config.html#sidebar
     sidebar: {
@@ -1162,6 +1173,89 @@ module.exports = {
             ['features/invariants', 'Invariants'],
             ['features/development', 'Continuous Development']]
         }
+      ],
+      '/fr/adoption/': [
+        {
+          title: 'Guide du Schéma',
+          collapsable: false,
+          sidebarDepth: 2,
+          children: [
+            ['Scheme/platform-operating-guideline', 'Modèle de Directive Opérationnelle de la Plateforme'],
+            ['Scheme/scheme-business-rules', 'Modèle de Règles Commerciales du Schéma'],
+            ['Scheme/scheme-key-choices', 'Choix Clés du Schéma'],
+            ['Scheme/scheme-participation-agreement', 'Modèle d\'Accord de Participation au Schéma'],
+            ['Scheme/scheme-uniform-glossary', 'Modèle de Glossaire Uniforme'],
+          ]
+        },
+        {
+          title: 'Guide des Opérations du Hub',
+          collapsable: false,
+          sidebarDepth: 1,
+          children: [
+            {
+              title: 'Guide des Opérations Techniques',
+              collapsable: true,
+              sidebarDepth: 2,
+              children: [
+                'HubOperations/TechOps/tech-ops-introduction',
+                'HubOperations/TechOps/incident-management',
+                'HubOperations/TechOps/problem-management',
+                'HubOperations/TechOps/change-management',
+                'HubOperations/TechOps/release-management',
+                'HubOperations/TechOps/defect-triage',
+                'HubOperations/TechOps/key-terms-kpis',
+                'HubOperations/TechOps/incident-management-escalation-matrix',
+                'HubOperations/TechOps/service-level-agreements'
+              ]
+            },
+            {
+              title: 'Guide de Gestion des Règlements',
+              collapsable: true,
+              sidebarDepth: 2,
+              children: [
+                'HubOperations/Settlement/settlement-management-introduction',
+                'HubOperations/Settlement/settlement-basic-concepts',
+                'HubOperations/Settlement/ledgers-in-the-hub',
+              ]
+            },
+            {
+              title: 'Guide du Portail Finance v2',
+              collapsable: true,
+              sidebarDepth: 2,
+              children: [
+                'HubOperations/Portalv2/busops-portal-introduction',
+                'HubOperations/Portalv2/settlement-business-process',
+                'HubOperations/Portalv2/accessing-the-portal',
+                'HubOperations/Portalv2/managing-windows',
+                'HubOperations/Portalv2/settling',
+                'HubOperations/Portalv2/checking-settlement-details',
+                'HubOperations/Portalv2/monitoring-dfsp-financial-details',
+                'HubOperations/Portalv2/enabling-disabling-transactions',
+                'HubOperations/Portalv2/recording-funds-in-out',
+                'HubOperations/Portalv2/updating-ndc',
+                'HubOperations/Portalv2/searching-for-transfer-data'
+              ]
+            },
+            {
+              title: 'Contrôle d\'Accès Basé sur les Rôles',
+              collapsable: true,
+              sidebarDepth: 2,
+              children: [
+                'HubOperations/RBAC/Role-based-access-control'
+              ]
+            },
+            {
+              title: 'Guide d\'Intégration pour l\'Opérateur du Hub',
+              collapsable: true,
+              sidebarDepth: 2,
+              children: [
+                'HubOperations/Onboarding/onboarding-introduction',
+                'HubOperations/Onboarding/business-onboarding',
+                'HubOperations/Onboarding/technical-onboarding',
+              ]
+            }
+          ]
+        }
       ]
     }
   },
@@ -1183,8 +1277,8 @@ module.exports = {
     },
     '/fr/': {
       lang: 'fr-FR',
-      title: 'Mojaloop Documentation',
-      description: '',
+      title: 'Documentation Mojaloop',
+      description: 'Documentation officielle du projet Mojaloop',
     },
   },
 };
diff --git a/docs/.vuepress/enhanceApp.js b/docs/.vuepress/enhanceApp.js
index 8452a868..be9e13df 100644
--- a/docs/.vuepress/enhanceApp.js
+++ b/docs/.vuepress/enhanceApp.js
@@ -4,11 +4,34 @@
  * https://v1.vuepress.vuejs.org/guide/basic-config.html#app-level-enhancements
  */
 
+const LOCALE_STORAGE_KEY = 'mojaloop-docs-locale-redirected'
+
+function getBrowserLang () {
+  if (typeof navigator === 'undefined') return 'en'
+  const lang = navigator.language || navigator.userLanguage || ''
+  return lang.toLowerCase().split('-')[0]
+}
+
 export default ({
-  Vue, // the version of Vue being used in the VuePress app
-  options, // the options for the root Vue instance
-  router, // the router instance for the app
-  siteData // site metadata
+  Vue,
+  options,
+  router,
+  siteData,
+  isServer
 }) => {
-  // ...apply enhancements for the site.
+  if (isServer) return
+
+  router.afterEach((to) => {
+    const alreadyRedirected = sessionStorage.getItem(LOCALE_STORAGE_KEY)
+    if (alreadyRedirected) return
+
+    sessionStorage.setItem(LOCALE_STORAGE_KEY, '1')
+
+    const browserLang = getBrowserLang()
+    const isOnFrenchPage = to.path.startsWith('/fr/')
+
+    if (browserLang === 'fr' && !isOnFrenchPage) {
+      return router.replace('/fr' + to.path)
+    }
+  })
 }
diff --git a/docs/.vuepress/theme/layouts/404.vue b/docs/.vuepress/theme/layouts/404.vue
index 4eef36d3..35c65f87 100644
--- a/docs/.vuepress/theme/layouts/404.vue
+++ b/docs/.vuepress/theme/layouts/404.vue
@@ -3,23 +3,44 @@
     <div class="content">
       <h1>404</h1>
       <blockquote>{{ getMsg() }}</blockquote>
-      <router-link to="/">Take me home.</router-link>
+      <router-link :to="homeLink">{{ homeLinkText }}</router-link>
     </div>
   </div>
 </template>
 
 <script>
-const msgs = [
-  `There's nothing here.`,
-  `How did we get here?`,
-  `That's a Four-Oh-Four.`,
-  `Looks like we've got some broken links.`
-]
+const msgs = {
+  en: [
+    `There's nothing here.`,
+    `How did we get here?`,
+    `That's a Four-Oh-Four.`,
+    `Looks like we've got some broken links.`
+  ],
+  fr: [
+    `Il n'y a rien ici.`,
+    `Comment sommes-nous arrivés ici ?`,
+    `C'est une erreur 404.`,
+    `On dirait que nous avons des liens cassés.`
+  ]
+}
 
 export default {
+  computed: {
+    isFrench () {
+      return this.$route.path.startsWith('/fr/')
+    },
+    homeLink () {
+      return this.isFrench ? '/fr/' : '/'
+    },
+    homeLinkText () {
+      return this.isFrench ? 'Retourner à l\'accueil.' : 'Take me home.'
+    }
+  },
   methods: {
     getMsg () {
-      return msgs[Math.floor(Math.random() * msgs.length)]
+      const lang = this.isFrench ? 'fr' : 'en'
+      const pool = msgs[lang]
+      return pool[Math.floor(Math.random() * pool.length)]
     }
   }
 }
diff --git a/docs/fr/adoption/HubOperations/Onboarding/business-onboarding.md b/docs/fr/adoption/HubOperations/Onboarding/business-onboarding.md
new file mode 100644
index 00000000..87aefd61
--- /dev/null
+++ b/docs/fr/adoption/HubOperations/Onboarding/business-onboarding.md
@@ -0,0 +1,20 @@
+# Intégration métier des DFSP
+
+Le parcours d'intégration des DFSP comprend des étapes qui se déroulent en dehors du Hub Mojaloop. Elles sont liées au volet métier de l'intégration, et il est utile pour l'opérateur du Hub d'en être informé.
+
+::: tip NOTE
+Les étapes du processus de candidature du DFSP et du parcours d'intégration métier sont définies par le schéma, en conformité avec les exigences réglementaires financières locales.
+:::
+
+Les étapes clés du parcours d'intégration métier sont :
+
+1. Le DFSP découvre le service offert par le schéma et indique son intention et sa raison commerciale de rejoindre le schéma.
+1. Le DFSP signe un accord de candidature.
+1. La documentation est partagée avec le DFSP, ce qui permet au DFSP d'évaluer l'effort technique d'intégration, ainsi que sa compatibilité commerciale avec les règles du schéma.
+1. L'opérateur du schéma effectue une vérification préalable de l'éligibilité du candidat.
+1. Le DFSP comprend et signe un accord de participation (contrat).
+1. Le DFSP effectue une procédure KYC auprès de la banque de règlement. Cela fait partie du processus d'ouverture d'un compte bancaire de règlement (également appelé compte de liquidité).
+1. Le DFSP développe de nouvelles fonctionnalités d'interface utilisateur / met à jour les fonctionnalités d'interface utilisateur existantes pour exposer le ou les cas d'utilisation pris en charge par le schéma aux utilisateurs finaux.
+1. Le DFSP ouvre et pré-alimente son compte de liquidité à la banque de règlement.
+
+En parallèle des étapes métier, après la signature de l'accord de participation, le DFSP peut commencer son [parcours d'intégration technique](technical-onboarding.md).
diff --git a/docs/fr/adoption/HubOperations/Onboarding/onboarding-introduction.md b/docs/fr/adoption/HubOperations/Onboarding/onboarding-introduction.md
new file mode 100644
index 00000000..44ed7cae
--- /dev/null
+++ b/docs/fr/adoption/HubOperations/Onboarding/onboarding-introduction.md
@@ -0,0 +1,5 @@
+# Introduction – Guide d'intégration pour l'opérateur du Hub
+
+Ce guide est destiné à l'opérateur d'un Hub Mojaloop et fournit des informations sur le processus d'intégration des DFSP. Il offre une vue d'ensemble de haut niveau du parcours d'intégration que suivent les DFSP, servant de liste de contrôle des activités d'intégration. L'objectif est d'aider les employés du Hub à comprendre les étapes à accomplir lors de la connexion des DFSP aux différents environnements du Hub.
+
+
diff --git a/docs/fr/adoption/HubOperations/Onboarding/technical-onboarding.md b/docs/fr/adoption/HubOperations/Onboarding/technical-onboarding.md
new file mode 100644
index 00000000..666f4894
--- /dev/null
+++ b/docs/fr/adoption/HubOperations/Onboarding/technical-onboarding.md
@@ -0,0 +1,247 @@
+# Intégration technique des DFSP
+
+À un niveau élevé, l'intégration à un Hub Mojaloop nécessite qu'un DFSP concentre ses efforts sur les jalons majeurs suivants :
+
+* [Intégration](#integration-api) de son backend principal avec le Hub Mojaloop au niveau de l'API (cela implique à la fois le codage et les tests).
+* [Connexion](#connexion-aux-environnements-mojaloop) aux environnements de pré-production et de production en suivant les exigences rigoureuses de sécurité de Mojaloop.
+
+En plus des étapes nécessitant l'implication du DFSP, l'opérateur du Hub doit également effectuer certaines activités d'intégration dans son [backend](#integration-dans-le-backend-du-hub) indépendamment des DFSP.
+
+Cette section fournit une vue d'ensemble de haut niveau de tous ces jalons.
+
+## Intégration API
+
+Dans le contexte de l'API Mojaloop Financial Service Provider Interoperability (FSPIOP), un transfert se déroule en trois étapes principales :
+
+1. Identification du bénéficiaire (phase de recherche de partie ou de découverte)
+1. Accord sur le transfert (phase de devis ou d'accord)
+1. Exécution du transfert (phase de transfert)
+
+Pour plus de détails sur chacune de ces phases, voir le **Module 2 - Démonstration statique : Un exemple de bout en bout** du [cours de formation Mojaloop](https://learn.mojaloop.io/) **MOJA-102**.
+
+Ces trois phases correspondent aux ressources clés de l'API Mojaloop FSPIOP :
+
+* **Service de recherche de partie** : Identification du DFSP desservant le bénéficiaire et du bénéficiaire lui-même (= le destinataire des fonds dans une transaction) sur la base d'un identifiant du bénéficiaire (généralement un MSISDN, c'est-à-dire un numéro de mobile).
+* **Service de devis** : Demande d'un devis et échange de preuves cryptographiques pour préparer et sécuriser le transfert. Un devis est un contrat entre un DFSP payeur et un DFSP bénéficiaire pour une transaction financière particulière avant que la transaction ne soit effectuée. Il garantit l'accord établi par les DFSP payeur et bénéficiaire concernant le payeur, le bénéficiaire et le montant du transfert, et est valide pendant la durée de vie d'un devis et d'un transfert d'une transaction financière spécifiée.
+* **Service de transferts** : Exécution de la transaction selon les détails convenus et la preuve cryptographique.
+
+Les DFSP peuvent choisir de :
+
+* se connecter directement au Hub Mojaloop et implémenter la version asynchrone Mojaloop de ces services API, ou
+* tirer parti d'un composant d'intégration open source (le [Mojaloop-SDK](#mojaloop-sdk) ou [Payment Manager OSS](#payment-manager-oss)) et implémenter une version simplifiée et synchrone des services de l'API Mojaloop FSPIOP
+
+Les DFSP disposant d'une équipe de développement interne et d'une expérience avec les API RESTful seront probablement en mesure de gérer le processus en interne et de développer une connexion directe à Mojaloop. Cependant, il est recommandé que les DFSP utilisent l'un des composants d'intégration open source, car une connexion directe nécessite un développement et une maintenance de code supplémentaires. L'utilisation du Mojaloop-SDK ou de Payment Manager OSS réduit le temps nécessaire à l'intégration avec le Hub Mojaloop et facilite le dépannage pour l'opérateur du Hub, réduisant ainsi le coût global du système.
+
+Pendant que le DFSP effectue des travaux de développement hors ligne, le rôle de l'opérateur du Hub consiste à répondre aux questions ponctuelles sur les spécificités de l'API, ou - selon l'outil open source choisi et le modèle de déploiement convenu - peut même s'étendre à une partie du développement.
+
+### Outils open source pour faciliter l'intégration API
+
+#### Mojaloop-SDK
+
+Le [Mojaloop-SDK](https://github.com/mojaloop/sdk-scheme-adapter) présente une version simplifiée et synchrone de l'API Mojaloop FSPIOP au système backend d'un DFSP, permettant aux DFSP d'implémenter une API simple en interne pour s'interfacer avec le Hub Mojaloop, tout en restant conforme à la spécification de l'API Mojaloop FSPIOP pour les communications externes interopérables.
+
+Le modèle asynchrone de l'API Mojaloop FSPIOP (bien qu'il présente de nombreux avantages) peut ne pas convenir aux applications clientes qui fonctionnent en mode requête-réponse synchrone. Le Mojaloop-SDK aide à combler cet écart en offrant une API simplifiée de type requête-réponse, faisant abstraction des complexités de la composition de requêtes multiples et des détails de l'API asynchrone pour les clients finaux.
+
+![Mojaloop-SDK](../../../../.vuepress/public/mojaloop-sdk.png)
+
+Le Mojaloop-SDK doit être téléchargé depuis [GitHub](https://github.com/mojaloop/sdk-scheme-adapter) vers l'environnement du DFSP et intégré au backend du DFSP. Il est fourni sous forme d'image de conteneur Docker, et peut être hébergé sur la même infrastructure que l'application bancaire principale ou sur une machine virtuelle provisionnée spécifiquement pour cela. La maintenance continue peut nécessiter un support spécialisé d'un intégrateur de systèmes formé au logiciel.
+
+En plus d'une API simplifiée, le Mojaloop-SDK fournit également les protocoles de sécurité requis par Mojaloop « prêts à l'emploi », en offrant une interface de configuration simplifiée à ses utilisateurs. Cette fonctionnalité du Mojaloop-SDK aide à l'[étape de connexion](#connexion-aux-environnements-mojaloop) de l'intégration.
+
+#### Payment Manager OSS
+
+[Payment Manager OSS](https://pm4ml.github.io/documents/payment_manager_oss/latest/core_connector_rest/introduction.html) présente une version orientée cas d'utilisation, simplifiée et synchrone de l'API Mojaloop FSPIOP au système backend d'un DFSP. Le composant clé d'intégration de Payment Manager s'appelle Core Connector, il agit comme un traducteur entre le backend principal d'un DFSP (CBS) et un composant de Payment Manager (appelé Mojaloop Connector, qui exploite le Mojaloop-SDK) qui communique directement avec le Hub Mojaloop.
+
+![Payment Manager OSS](../../../../.vuepress/public/PM4ML_system_architecture.png)
+
+Core Connector est construit en Apache Camel, un langage déclaratif basé sur Java pour les ingénieurs d'intégration qui ne nécessite pas d'écrire du code à partir de zéro. Un modèle de Core Connector prêt à l'emploi est disponible pour simplifier l'effort de développement. Le modèle fournit une base de code de remplacement pour les points d'accès API qui doivent être développés, et il doit être personnalisé pour être aligné avec la technologie CBS appropriée. La flexibilité offerte par le modèle permet d'adapter Core Connector au backend d'un DFSP, plutôt que l'inverse.
+
+L'effort de personnalisation d'un modèle Core Connector variera selon l'option de déploiement choisie. Lors du déploiement de Payment Manager, deux options sont disponibles :
+
+* **Géré et hébergé par un intégrateur de systèmes** : Un intégrateur de systèmes déploie Payment Manager dans le cloud, et synchronise le modèle Core Connector avec l'implémentation du backend principal du DFSP.
+* **Auto-hébergé par le DFSP** : Le DFSP déploie Payment Manager sur site ou dans le cloud, et la personnalisation du modèle Core Connector peut être effectuée par un certain nombre d'acteurs (selon le résultat d'une évaluation initiale des capacités du DFSP) :
+    * l'intégrateur de systèmes
+    * l'intégrateur de systèmes et le fournisseur de la solution backend principale du DFSP
+    * le DFSP et le fournisseur de la solution backend principale du DFSP
+
+Payment Manager est fourni sous forme d'un ensemble d'images de conteneurs Linux (Docker) et peut être hébergé sur site à l'aide d'une infrastructure serveur standard ou dans une infrastructure cloud appropriée lorsqu'elle est disponible.
+
+Si l'opérateur du Hub le souhaite, il peut assumer le rôle d'intégrateur de systèmes.
+
+Étant donné que Payment Manager intègre les fonctionnalités du Mojaloop-SDK, il implémente également la couche de sécurité requise par Mojaloop. Cette fonctionnalité de Payment Manager aide à l'[étape de connexion](#connexion-aux-environnements-mojaloop) de l'intégration.
+
+## Connexion aux environnements Mojaloop
+
+Une fois que le DFSP a terminé le codage, il teste son intégration contre une instance de laboratoire dans un environnement de test fourni par le Hub. C'est là que la phase de connexion du parcours d'intégration technique commence, avec un nouvel ensemble de responsabilités pour l'opérateur du Hub.
+
+Les exigences relatives à la connexion sont dictées par les multiples protocoles de sécurité que tout Hub Mojaloop et les DFSP participants doivent implémenter :
+
+* TLS bidirectionnel avec authentification mutuelle X.509
+* Authentification OAuth 2.0 pour les sessions via la passerelle API du Hub
+* Liste blanche basée sur les adresses IP dans les règles de pare-feu et les passerelles API
+* Signature des messages par JSON Web Signature (JWS)
+* Signature et validation des paquets Interledger Protocol (ILP)
+
+Si vous souhaitez plus de détails, consultez [Sécurité dans Mojaloop](#securite-dans-mojaloop).
+
+La mise en pratique des mesures de sécurité ci-dessus nécessite un partage d'informations étendu et une configuration technique de la part de différentes équipes tant du côté du DFSP que du Hub Mojaloop. Des outils open source sont disponibles pour la communauté afin de faciliter ce processus, tant pour les DFSP que pour l'opérateur du Hub.
+
+### Outils open source pour faciliter la connexion aux environnements Mojaloop
+
+#### Mojaloop-SDK
+
+Le Mojaloop-SDK implémente des composants standard qui établissent une manière uniforme de connecter les systèmes DFSP à un Hub Mojaloop. Il implémente les fonctionnalités de sécurité conformes à Mojaloop suivantes :
+
+* TLS bidirectionnel avec authentification mutuelle X.509
+* Signature des messages par JSON Web Signature (JWS)
+* Génération du paquet Interledger Protocol (ILP) avec signature et validation
+
+Le Mojaloop-SDK peut être téléchargé depuis [GitHub](https://github.com/mojaloop/sdk-standard-components) et hébergé sur la même infrastructure que l'application bancaire principale du DFSP ou sur une machine virtuelle provisionnée spécifiquement pour cela. Après la génération, la signature et l'échange des certificats TLS et JWS, les DFSP sont tenus de configurer les variables d'environnement liées à TLS et JWS dans le Mojaloop-SDK. Enfin, l'installation des certificats dans les pare-feu et la passerelle API du DFSP complète la partie configuration des certificats du processus.
+
+L'obtention des identifiants de la passerelle API du Hub requis pour collecter les jetons OAuth 2.0 et leur configuration dans le Mojaloop-SDK via des variables d'environnement doit être effectuée manuellement.
+
+L'échange des détails des points d'accès avec le Hub et leur configuration dans le Mojaloop-SDK via des variables d'environnement, ainsi que dans les listes blanches des pare-feu/passerelles sont également des étapes manuelles.
+
+#### Payment Manager OSS
+
+Payment Manager OSS fournit toutes les fonctionnalités de sécurité que le Mojaloop-SDK offre, et plus encore. Payment Manager est livré avec un client Mojaloop Connection Manager (MCM), qui simplifie et automatise la création, la signature et l'échange de certificats, ainsi que la configuration des connexions requises aux différents environnements. Le degré d'automatisation de ces processus variera selon l'option de déploiement choisie. Deux options sont disponibles :
+
+* **Géré et hébergé par un intégrateur de systèmes** : Un intégrateur de systèmes déploie Payment Manager dans le cloud.
+* **Auto-hébergé par le DFSP** : Le DFSP déploie Payment Manager sur site ou dans le cloud.
+
+Lorsqu'un DFSP opte pour l'**option gérée et hébergée**, l'intégrateur de systèmes (ce rôle peut être rempli par l'opérateur du Hub) peut employer l'Infrastructure-as-Code et des scripts d'intégration pour gérer les éléments suivants du processus de manière automatisée :
+
+* génération, signature, configuration et installation des certificats TLS
+* mise en liste blanche des adresses IP dans les pare-feu et les passerelles API
+* génération et configuration du secret/clé client requis pour obtenir des jetons OAuth 2.0
+
+Les étapes liées aux certificats JWS sont effectuées via le [portail Connection Wizard](https://pm4ml.github.io/documents/payment_manager_oss/latest/connection_wizard/index.html), un portail facile à utiliser que Payment Manager fournit pour gérer les processus liés aux certificats et aux points d'accès de manière guidée. Les DFSP et l'opérateur du Hub sont tenus de générer des certificats JWS en utilisant l'outil de leur choix, puis de partager leurs clés publiques via le portail Connection Wizard. La configuration des certificats JWS dans Payment Manager se fait via le portail Connection Wizard, tandis que leur installation dans les passerelles est une étape manuelle.
+
+Lorsqu'un DFSP opte pour l'**option auto-hébergée**, il utilise le [portail Connection Wizard](https://pm4ml.github.io/documents/payment_manager_oss/latest/connection_wizard/index.html) pour gérer les étapes liées aux certificats et aux points d'accès de manière semi-automatisée :
+
+* Les DFSP saisissent les détails de leurs points d'accès et obtiennent les points d'accès du Hub depuis le portail. Ils configurent ensuite ces informations dans Payment Manager via des variables d'environnement ainsi que dans les listes blanches des pare-feu/passerelles manuellement.
+* Les DFSP génèrent, signent et configurent les certificats TLS en un clic via le portail Connection Wizard.
+* Les DFSP génèrent des certificats JWS en utilisant un outil de leur choix et les partagent et les configurent dans Payment Manager en un clic dans le portail Connection Wizard.
+
+L'obtention des identifiants de la passerelle API du Hub requis pour collecter les jetons OAuth 2.0 et leur configuration dans Payment Manager via des variables d'environnement doit être effectuée manuellement.
+
+#### MCM
+
+Le produit Mojaloop Connection Manager (MCM) est essentiel pour simplifier et automatiser une grande partie du partage d'informations et de la configuration autour des points d'accès et des certificats. MCM a un composant Client MCM et un composant Serveur MCM, qui communiquent entre eux lors de l'échange des détails des points d'accès et des certificats, et lors de la signature des demandes de signature de certificat.
+
+Le client MCM est intégré dans Payment Manager, tandis que le serveur MCM se trouve dans les limites du Hub. MCM fournit un portail pour que l'opérateur du Hub soumette les informations des points d'accès du Hub et les certificats du Hub, et récupère les détails des points d'accès et des certificats du DFSP soumis par le DFSP via Payment Manager.
+
+### Sécurité dans Mojaloop
+
+Pour comprendre ce qu'implique en détail la connexion d'un DFSP à un environnement Mojaloop, il est important d'examiner de plus près les exigences de sécurité de Mojaloop.
+
+Mojaloop exige que les mesures de sécurité suivantes soient implémentées afin de protéger les données échangées entre les DFSP :
+
+* **La sécurité de la couche de transport (TLS)** est un mécanisme sécurisé pour échanger une clé symétrique partagée sur un réseau entre deux pairs anonymes, avec vérification d'identité (c'est-à-dire des certificats de confiance). Elle assure la confidentialité (personne n'a lu le contenu) et l'intégrité (personne n'a modifié le contenu). Mojaloop exige une authentification mutuelle TLS bidirectionnelle utilisant des certificats X.509 pour sécuriser les connexions bidirectionnelles. Les DFSP et le Hub Mojaloop s'authentifient mutuellement pour s'assurer que les deux parties impliquées dans la communication sont de confiance. Les deux parties partagent leurs certificats publics et la vérification/validation est ensuite effectuée sur cette base.
+* Une autre mesure de sécurité offerte pour l'authentification est constituée par les **jetons OAuth** que les DFSP sont tenus d'utiliser lors d'une requête d'appel API. OAuth 2 est utilisé pour fournir un accès basé sur les rôles aux points d'accès du Hub Mojaloop (autorisation API).
+* **La mise en liste blanche des adresses IP** réduit la surface d'attaque du Hub Mojaloop.
+* Pour protéger le niveau applicatif, Mojaloop implémente la **signature JSON Web Signature (JWS)** telle que définie dans la [RFC 7515 (JSON Web Signature (JWS))](https://tools.ietf.org/html/rfc7515), la norme pour l'intégrité et la non-répudiation. La signature des messages garantit que le DFSP payeur et le DFSP bénéficiaire peuvent avoir confiance que les messages partagés entre eux n'ont pas été modifiés par un tiers.
+* L'API Mojaloop FSPIOP implémente la prise en charge du **protocole Interledger (ILP)**. ILP est construit sur le concept de transferts conditionnels, dans lesquels les registres impliqués dans une transaction financière du payeur au bénéficiaire peuvent d'abord réserver des fonds sur un compte payeur, puis les valider sur le compte bénéficiaire. Le transfert du compte payeur au compte bénéficiaire est conditionné à la présentation d'un accomplissement qui satisfait la condition attachée à la demande de transfert originale.
+
+![Vue d'ensemble de la sécurité](../../../../.vuepress/public/security_overview.png)
+
+Les sections suivantes fournissent des informations de fond sur les étapes impliquées dans la connexion à un environnement Mojaloop. Les informations fournies sont rédigées de manière à ce que les DFSP et le Hub puissent s'appuyer sur les meilleures pratiques PKI et sur les outils et technologies propriétaires qu'ils préfèrent ou auxquels ils ont accès.
+
+::: tip
+Comme mentionné ci-dessus, en utilisant Payment Manager OSS, Mojaloop Connection Manager (MCM) et l'Infrastructure-as-Code (IaC) qui déploie les composants constituant l'écosystème Mojaloop, bon nombre des étapes des processus décrits ci-dessous peuvent être effectuées de manière automatisée.
+:::
+
+#### Création et partage de certificats
+
+##### Certificats TLS
+
+L'authentification TLS bidirectionnelle ou mutuelle (mTLS) repose sur le fait que les deux parties (client et serveur) partagent leurs certificats publics et effectuent la vérification/validation sur cette base.
+
+Les étapes de haut niveau suivantes décrivent comment la connexion est établie et les données sont transférées entre un client et un serveur dans le cas du mTLS :
+
+1. Le client demande une ressource protégée via le protocole HTTPS et le processus de handshake SSL/TLS commence.
+1. Le serveur retourne son certificat public au client avec un message server hello.
+1. Le client valide/vérifie le certificat reçu. Le client vérifie le certificat auprès de l'autorité de certification (CA) pour les certificats signés par une CA.
+1. Si le certificat du serveur a été validé avec succès, le serveur demande le certificat du client.
+1. Le client fournit son certificat public au serveur.
+1. Le serveur valide/vérifie le certificat reçu. Le serveur vérifie le certificat auprès de l'autorité de certification pour les certificats signés par une CA.
+
+Après l'achèvement du processus de handshake, le client et le serveur communiquent et transfèrent des données entre eux, chiffrées avec les clés secrètes partagées entre les deux pendant le handshake.
+
+<img src="../../../../.vuepress/public/TLS_connection.svg" width="65%" height="65%" />
+
+Le processus ci-dessus exige qu'avant de se connecter à un environnement (pré-production ou production), le DFSP et le Hub Mojaloop complètent chacun les étapes suivantes.
+
+1. Créer un certificat serveur signé par votre CA.
+1. Partager votre certificat serveur et la chaîne CA avec l'autre partie.
+1. Installer la chaîne CA de l'autre partie dans votre pare-feu sortant (la validation/vérification se fera par rapport à ces certificats installés).
+1. Générer une demande de signature de certificat (CSR) pour votre certificat client TLS et la partager avec l'autre partie.
+1. Signer la CSR de l'autre partie en utilisant votre CA.
+1. Partager le certificat client signé ainsi que le certificat racine de votre CA avec l'autre partie.
+1. Installer votre propre certificat client signé par la CA de l'autre partie dans votre passerelle API sortante.
+1. Installer le certificat racine de la CA de l'autre partie dans votre passerelle API sortante.
+
+##### Certificats JWS
+
+Chaque fois qu'un client API envoie un message API à une contrepartie, le client API doit signer le message à l'aide de sa clé privée JWS. Après que la contrepartie reçoit le message API, elle doit valider la signature avec la clé publique JWS de la partie émettrice. JWS est utilisé par la partie réceptrice pour valider que le message provient de l'expéditeur attendu et qu'il n'a pas été modifié en transit.
+
+Le processus ci-dessus exige que tous les DFSP et le Hub Mojaloop lui-même disposent d'un certificat JWS et qu'avant de se connecter à un environnement (pré-production ou production), le DFSP et le Hub Mojaloop complètent chacun les étapes suivantes.
+
+1. Créer un magasin de clés (pour stocker votre certificat et votre clé privée), une paire de clés asymétriques (une clé publique et une clé privée), et un certificat associé qui vous identifie.
+1. Partager votre clé publique JWS.
+1. Installer les clés publiques JWS des autres parties (le Hub et tous les autres DFSP) dans votre passerelle entrante.
+1. Installer votre clé privée JWS dans votre passerelle sortante.
+
+#### Partage des informations des points d'accès
+
+Le Hub Mojaloop et les DFSP partagent les informations des points d'accès pour :
+
+* mettre en liste blanche les adresses IP publiques de l'autre partie dans les règles de pare-feu afin de permettre le trafic
+* configurer les URL de rappel de l'autre partie dans les passerelles API
+
+En règle générale, l'accès à tout trafic entrant et sortant pour un DFSP sera contrôlé par l'équipe de sécurité concernée. Le pare-feu du DFSP doit être correctement configuré :
+
+* pour accéder au Hub Mojaloop dans tout environnement où le DFSP et le Hub interagissent, et
+* pour que le Hub Mojaloop effectue des rappels vers le DFSP
+
+En dehors de l'accès vers et depuis le Hub déployé dans un environnement, tout autre accès public doit être bloqué pour empêcher tout accès non autorisé/non justifié.
+
+En conséquence, l'accès au Hub Mojaloop est également réglementé. Les DFSP doivent partager leur IP/plage d'IP à partir desquelles les appels seront effectués vers le Hub afin que le pare-feu du Hub puisse être configuré de manière appropriée. L'équipe de sécurité au sein du DFSP devrait être en mesure de fournir cette information.
+
+#### Obtention d'un jeton OAuth
+
+Le Hub Mojaloop utilise les technologies WSO2 pour l'intégration entre le Hub et les DFSP, et pour fournir une passerelle aux DFSP. Pour se connecter aux différents environnements du Hub, les DFSP doivent obtenir l'accès à WSO2. WSO2 offre un portail API Store où les DFSP peuvent créer des comptes de passerelle API pour l'accès au niveau applicatif, s'abonner aux API et obtenir des jetons OAuth pour une utilisation lors de l'interaction avec le Hub Mojaloop.
+
+## Intégration dans le backend du Hub
+
+L'intégration comprend certaines étapes qui ne nécessitent aucune action de la part des DFSP et sont de la seule responsabilité de l'opérateur du Hub. Ces étapes sont les suivantes :
+
+1. Configurer les passerelles API du Hub qui gèrent les flux de données entrants et sortants depuis/vers les DFSP. Mojaloop utilise les technologies WSO2 pour l'accès aux passerelles, ainsi que l'autorisation et l'authentification des DFSP pour le passage des messages via les passerelles. La pile de produits WSO2 peut être déployée à partir du code en utilisant une solution d'intégration et de déploiement continus (CI/CD), le provisionnement peut être effectué par des scripts d'automatisation.
+1. Créer des utilisateurs et des comptes, configurer le contrôle d'accès basé sur les rôles.
+1. Configurer le Hub pour gérer les cas d'utilisation pris en charge par le schéma :
+    - Configurer les registres du Hub.
+    - Configurer les e-mails de notification du Hub.
+    - Configurer le modèle de règlement.
+    - Intégrer les oracles. \
+    Mojaloop fournit un [script de provisionnement](https://github.com/mojaloop/testing-toolkit-test-cases/tree/master/collections/hub/provisioning/MojaloopHub_Setup) pour effectuer toutes les étapes ci-dessus de manière automatisée en utilisant le [Mojaloop Testing Toolkit (TTK)](https://github.com/mojaloop/ml-testing-toolkit).
+1. Configurer des DFSP simulateurs pour les activités de validation initiales. \
+   Mojaloop fournit des [scripts de provisionnement](https://github.com/mojaloop/testing-toolkit-test-cases/tree/master/collections/hub/provisioning/MojaloopSims_Onboarding) pour effectuer cette étape de manière automatisée en utilisant le Mojaloop Testing Toolkit (TTK).
+1. Configurer les DFSP dans le backend du Hub. Pour chaque DFSP :
+    - Ajouter le DFSP et créer une devise pour celui-ci.
+    - Ajouter les URL de rappel pour tous les services API.
+    - Ajouter un plafond de débit net et définir la position initiale à 0.
+    - Configurer les e-mails de notification du DFSP. \
+    Comme pour les étapes précédentes, la configuration des détails du DFSP peut également être effectuée via un script de provisionnement.
+
+## Tests et validation
+
+Au fur et à mesure que les DFSP avancent dans leur parcours d'intégration, ils sont tenus d'effectuer des tests dans chaque environnement. Les exigences de validation métier et technique doivent être satisfaites lors des tests. Les détails de la validation métier sont définis dans les règles du schéma.
+
+Voici quelques exemples d'activités de test que les DFSP sont censés effectuer dans les différents environnements de pré-production :
+
+* validation de l'intégration de bout en bout et de la couche applicative contre des simulateurs
+* validation de l'intégration de bout en bout et de la couche applicative contre des DFSP réels et amicaux
+* validation du processus de règlement
+* validation de la configuration de sécurité
+* validation des accords de niveau de service (SLA) en matière de temps de réponse
+* tests de performance
diff --git a/docs/fr/adoption/HubOperations/Portalv2/accessing-the-portal.md b/docs/fr/adoption/HubOperations/Portalv2/accessing-the-portal.md
new file mode 100644
index 00000000..ad34e5d2
--- /dev/null
+++ b/docs/fr/adoption/HubOperations/Portalv2/accessing-the-portal.md
@@ -0,0 +1,92 @@
+# Accéder au portail
+
+Lorsque vous accédez au portail, vous êtes invité à vous connecter. Saisissez vos identifiants sur la page de connexion.
+
+<img src="../../../../.vuepress/public/portal_login.png" width="40%" height="40%" />
+
+Le portail met en œuvre un contrôle d'accès basé sur les rôles, ce qui signifie que le rôle qui vous est attribué détermine l'éventail des fonctionnalités du portail auxquelles vous avez accès. Actuellement, les rôles suivants existent :
+
+* `portaladmin` : a un accès complet à toutes les fonctionnalités du portail
+* `portaluser` : a un accès limité aux fonctionnalités du portail
+
+Le tableau suivant répertorie toutes les fonctionnalités disponibles, les chemins de navigation pour y accéder et les autorisations de rôles correspondantes.
+
+<table>
+<caption><strong>Fonctionnalités du portail et chemins de navigation</strong></caption>
+<colgroup>
+<col style="width: 30%" />
+<col style="width: 30%" />
+<col style="width: 20%" />
+<col style="width: 20%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Fonctionnalité</th>
+<th>Chemin de navigation</th>
+<th>portaladmin</th>
+<th>portaluser</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p><a href="managing-windows.html">Afficher les détails de la fenêtre de règlement</a></p></td>
+<td><p><strong>Settlement</strong> &gt; <strong>Settlement Windows</strong></p></td>
+<td><p>✓</p></td>
+<td><p>✓</p></td>
+</tr>
+<tr class="even">
+<td><p><a href="settling.html#closing-a-settlement-window">Fermer des fenêtres de règlement</a></p></td>
+<td><p><strong>Settlement</strong> &gt; <strong>Settlement Windows</strong></p></td>
+<td><p>✓</p></td>
+<td><p>✓</p></td>
+</tr>
+<tr class="even">
+<td><p><a href="settling.html#settling-a-closed-settlement-window">Régler des fenêtres de règlement</a></p></td>
+<td><p><strong>Settlement</strong> &gt; <strong>Settlement Windows</strong></p></td>
+<td><p>✓</p></td>
+<td><p>✓</p></td>
+</tr>
+<tr class="even">
+<td><p><a href="settling.html#finalizing-a-settlement">Finaliser un règlement</a></p></td>
+<td><p><strong>Settlement</strong> &gt; <strong>Settlement Windows</strong></p></td>
+<td><p>✓</p></td>
+<td><p>✓</p></td>
+</tr>
+<tr class="odd">
+<td><p><a href="checking-settlement-details.html">Afficher les détails du règlement</a></p></td>
+<td><p><strong>Settlement</strong> &gt; <strong>Settlements</strong></p></td>
+<td><p>✓</p></td>
+<td><p>✓</p></td>
+</tr>
+<tr class="odd">
+<td><p><a href="monitoring-dfsp-financial-details.html">Afficher les détails financiers des DFSP</a></p></td>
+<td><p><strong>Participants</strong> &gt; <strong>DFSP Financial Positions</strong></p></td>
+<td><p>✓</p></td>
+<td><p>✓</p></td>
+</tr>
+<tr class="even">
+<td><p><a href="enabling-disabling-transactions.html">Désactiver et réactiver les transactions pour un DFSP</a></p></td>
+<td><p><strong>Participants</strong> &gt; <strong>DFSP Financial Positions</strong></p></td>
+<td><p>✓</p></td>
+<td><p>✓</p></td>
+</tr>
+<tr class="odd">
+<td><p><a href="recording-funds-in-out.html">Enregistrer les dépôts ou retraits sur les comptes de liquidité des DFSP</a></p></td>
+<td><p><strong>Participants</strong> &gt; <strong>DFSP Financial Positions</strong></p></td>
+<td><p>✓</p></td>
+<td><p>✓</p></td>
+</tr>
+<tr class="even">
+<td><p><a href="updating-ndc.html">Mettre à jour le Net Debit Cap d'un DFSP</a></p></td>
+<td><p><strong>Participants</strong> &gt; <strong>DFSP Financial Positions</strong></p></td>
+<td><p>✓</p></td>
+<td><p>x</p></td>
+</tr>
+<tr class="odd">
+<td><p><a href="searching-for-transfer-data.html">Rechercher des données de transfert</a></p></td>
+<td><p><strong>Transfers</strong> &gt; <strong>Find Transfers</strong></p></td>
+<td><p>✓</p></td>
+<td><p>✓</p></td>
+</tr>
+</tbody>
+</table>
diff --git a/docs/fr/adoption/HubOperations/Portalv2/busops-portal-introduction.md b/docs/fr/adoption/HubOperations/Portalv2/busops-portal-introduction.md
new file mode 100644
index 00000000..1ebe7956
--- /dev/null
+++ b/docs/fr/adoption/HubOperations/Portalv2/busops-portal-introduction.md
@@ -0,0 +1,23 @@
+# Introduction – Guide du Finance Portal v2
+
+Ce guide est destiné à l'Opérateur d'un Hub Mojaloop et fournit des informations sur le Finance Portal, qui facilite la gestion quotidienne des processus liés au règlement.
+
+::: tip REMARQUE
+Le Finance Portal est désigné sous le nom de « Business Operations Portal » sur l'interface utilisateur du portail.
+:::
+
+Le portail offre les fonctionnalités suivantes :
+
+* [rechercher des fenêtres de règlement et vérifier les détails des fenêtres de règlement](managing-windows.md)
+* [fermer et régler des fenêtres de règlement](settling.md)
+* [régler des règlements](settling.md)
+* [rechercher des règlements et vérifier les détails des règlements](checking-settlement-details.md)
+* [surveiller les détails financiers des DFSP tels que le solde, la Position actuelle, le Net Debit Cap, le pourcentage de NDC utilisé](monitoring-dfsp-financial-details.md)
+* [désactiver et réactiver les transactions pour un DFSP](enabling-disabling-transactions.md)
+* [mettre à jour le Net Debit Cap d'un DFSP](updating-ndc.md)
+* [enregistrer les dépôts ou retraits sur le compte de liquidité d'un DFSP](recording-funds-in-out.md)
+* [rechercher des données de transfert](searching-for-transfer-data.md)
+
+::: tip REMARQUE
+Le Finance Portal ne prend actuellement en charge que les processus de règlement basés sur le modèle de règlement net différé (Deferred Net Settlement).
+:::
diff --git a/docs/fr/adoption/HubOperations/Portalv2/checking-settlement-details.md b/docs/fr/adoption/HubOperations/Portalv2/checking-settlement-details.md
new file mode 100644
index 00000000..dce2f804
--- /dev/null
+++ b/docs/fr/adoption/HubOperations/Portalv2/checking-settlement-details.md
@@ -0,0 +1,52 @@
+# Vérification des détails du règlement
+
+La page **Settlement > Settlements** vous permet de consulter certains détails des règlements, tels que :
+
+* l'identifiant du règlement
+* l'état du règlement
+* la valeur totale des transactions
+* les identifiants des DFSP impliqués dans les transactions, ainsi que la Position de règlement net multilatérale associée pour la période choisie
+
+![Vérification des détails du règlement](../../../../.vuepress/public/check_settlement_details.png)
+
+La page **Settlements** fournit une liste de règlements que vous pouvez filtrer à l'aide de divers critères de recherche :
+
+* **Date** : Fournit une liste déroulante de plages horaires. La valeur par défaut est **Today**. \
+\
+L'option **Clear** vous permet de supprimer tous les filtres de date déjà appliqués.
+* **From** et **To** : Affiche l'heure de début et l'heure de fin de la plage horaire sélectionnée dans le champ **Date**. Lorsque **Date** est défini sur **Custom Range**, vous devez définir la date et l'heure vous-même dans les champs **From** et **To**.
+* **State** : Fournit une liste déroulante des états de règlement.
+    * **Pending Settlement** : Un nouveau règlement composé d'une ou plusieurs fenêtres de règlement a été créé. La Position de règlement net multilatérale due à/par chaque participant a été calculée.
+    * **Ps Transfers Recorded** : Le Hub a marqué les transferts concernés comme `RECEIVED_PREPARE` dans ses enregistrements internes.
+    * **Ps Transfers Reserved** : Le Hub a marqué les transferts concernés comme `RESERVED` dans ses enregistrements internes.
+    * **Ps Transfers Committed** : Le Hub a marqué les transferts concernés comme `COMMITTED` dans ses enregistrements internes.
+    * **Settling** : Le règlement est en cours.
+    * **Settled** : Le règlement est terminé.
+    * **Aborted** : Le règlement n'a pas pu être complété et doit être annulé.
+* Bouton **Clear Filters** : Vous permet de supprimer tous les filtres que vous avez appliqués.
+
+À mesure que vous appliquez des critères de recherche, la liste des résultats (règlements) est mise à jour en continu.
+
+Les détails suivants sont affichés :
+
+* **Settlement ID** : L'identifiant unique du règlement.
+* **State** : Le statut du règlement.
+* **Total Value** : La valeur totale des transactions au sein du lot de règlement.
+* **Open Date** : La date et l'heure de création du règlement dans le Hub.
+* **Last Action Date** : La date et l'heure de la dernière action effectuée sur le règlement dans le Hub (par exemple, des fonds ont été réservés, des fonds ont été validés).
+* **Action** : Bouton **Finalize**. Vous permet de finaliser un règlement. Ce bouton n'est affiché que pour les règlements en attente (Pending Settlements). Pour plus de détails sur la finalisation d'un règlement, voir [Règlement](settling.md#finalizing-a-settlement).
+
+Pour afficher les détails d'un règlement particulier, cliquez sur le règlement dans la liste des résultats. La fenêtre contextuelle **Settlement Details** s'affiche.
+
+![Fenêtre contextuelle des détails du règlement](../../../../.vuepress/public/settlement_details_popup.png)
+
+Les détails supplémentaires suivants sont affichés :
+
+* **DFSP** : L'identifiant unique du DFSP.
+* **Window ID** : L'identifiant unique de la fenêtre de règlement en cours de règlement.
+* **Debit** : Montant de débit agrégé résultant des transferts auxquels le DFSP a participé.
+* **Credit** : Montant de crédit agrégé résultant des transferts auxquels le DFSP a participé.
+
+::: tip REMARQUE
+Au moment de la rédaction, les informations que devrait afficher le clic sur le bouton **View Net Positions** ne sont pas disponibles. Elles seront ajoutées dans une future version du portail.
+:::
diff --git a/docs/fr/adoption/HubOperations/Portalv2/enabling-disabling-transactions.md b/docs/fr/adoption/HubOperations/Portalv2/enabling-disabling-transactions.md
new file mode 100644
index 00000000..210d9945
--- /dev/null
+++ b/docs/fr/adoption/HubOperations/Portalv2/enabling-disabling-transactions.md
@@ -0,0 +1,27 @@
+# Désactivation et réactivation des transactions pour un DFSP
+
+Dans certains cas, il peut être nécessaire de rendre un DFSP inactif temporairement ou définitivement. Un exemple de scénario est lorsque vous observez un comportement hautement suspect et que la cause réelle nécessite une investigation, le risque de perte d'argent étant trop élevé.
+
+La page **Participants** > **DFSP Financial Positions** fournit une option pour arrêter l'envoi et la réception de transferts pour un DFSP particulier en désactivant son registre de Position en un clic de bouton.
+
+(Le Hub maintient un registre de Position pour chaque DFSP. Le registre de Position suit combien un DFSP doit ou combien lui est dû. Chaque fois qu'un transfert est traité, la Position dans le Hub est ajustée en temps réel.)
+
+Pour désactiver les transactions pour un DFSP particulier, effectuez les étapes suivantes :
+
+::: warning
+La désactivation d'un DFSP arrêtera toutes les transactions entrantes et sortantes pour ce DFSP, assurez-vous donc d'appliquer cette option avec précaution. Une fois le risque écarté, n'oubliez pas de reprendre les services pour le DFSP.
+:::
+
+1. Allez sur la page **Participants** > **DFSP Financial Positions**.
+1. Trouvez l'entrée du DFSP que vous souhaitez désactiver.
+1. Cliquez sur le bouton **Disable**.
+
+<img src="../../../../.vuepress/public/disable_dfsp_position_ledger.png" />
+
+Pour reprendre les services pour le DFSP que vous avez précédemment désactivé, effectuez les étapes suivantes :
+
+1. Allez sur la page **Participants** > **DFSP Financial Positions**.
+1. Trouvez l'entrée du DFSP que vous souhaitez activer.
+1. Cliquez sur le bouton **Enable**.
+
+<img src="../../../../.vuepress/public/enable_dfsp_position_ledger.png" />
diff --git a/docs/fr/adoption/HubOperations/Portalv2/managing-windows.md b/docs/fr/adoption/HubOperations/Portalv2/managing-windows.md
new file mode 100644
index 00000000..2380e6b8
--- /dev/null
+++ b/docs/fr/adoption/HubOperations/Portalv2/managing-windows.md
@@ -0,0 +1,50 @@
+# Vérification des détails des fenêtres de règlement
+
+La page **Settlement Windows** vous permet de :
+
+* rechercher des fenêtres de règlement en fonction de plusieurs critères de recherche
+* fermer une fenêtre de règlement ouverte
+* régler une seule fenêtre ou régler plusieurs fenêtres à la fois
+
+::: tip REMARQUE
+N'oubliez pas que le règlement doit suivre cette procédure :
+
+* Fermez la fenêtre de règlement que vous souhaitez régler.
+* Réglez la ou les fenêtres fermées de votre choix. Cela crée un nouveau règlement.
+* Envoyez les rapports de règlement aux DFSP et à la banque de règlement, puis obtenez une confirmation de la banque attestant qu'elle a transféré les fonds conformément au rapport.
+* Finalisez le nouveau règlement créé à l'étape 2.
+
+Étant donné que la fermeture d'une fenêtre et l'initiation du règlement en réglant les fenêtres sélectionnées font partie intégrante du processus de règlement, elles sont décrites dans une section dédiée au [règlement](settling.md).
+:::
+
+Une fenêtre de règlement est une période de temps entre deux règlements successifs. Elle a une heure de début et une heure de fin, et tous les transferts qui aboutissent (et atteignent l'état `"COMMITTED"`) pendant que la fenêtre de règlement est ouverte seront réglés en lot après la fermeture de la fenêtre de règlement.
+
+Les transferts effectués dans la même fenêtre de règlement sont réglés en lot après la fin de la fenêtre de règlement.
+
+Pour accéder à la page **Settlement Windows**, allez dans **Settlement** > **Settlement Windows**.
+
+![Gestion des fenêtres de règlement](../../../../.vuepress/public/settlement_window_mgmt.png)
+
+La page **Settlement Windows** fournit une liste de fenêtres de règlement que vous pouvez filtrer à l'aide de divers critères de recherche :
+
+* **Date** : Fournit une liste déroulante de plages horaires. La valeur par défaut est **Today**. \
+\
+L'option **Clear** vous permet de supprimer tous les filtres de date déjà appliqués.
+* **From** et **To** : Affiche l'heure de début et l'heure de fin de la plage horaire sélectionnée dans le champ **Date**. Lorsque **Date** est défini sur **Custom Range**, vous devez définir la date et l'heure vous-même dans les champs **From** et **To**.
+* **State** : Fournit une liste déroulante des états des fenêtres de règlement :
+    * **Open** : La fenêtre de règlement est ouverte, les transferts sont acceptés dans la fenêtre ouverte actuelle.
+    * **Closed** : La fenêtre de règlement est fermée. Elle n'accepte plus de transferts supplémentaires et tous les nouveaux transferts sont affectés à une nouvelle fenêtre de règlement ouverte.
+    * **Pending** : La fenêtre de règlement est fermée, mais elle doit encore être réglée. Une fenêtre ne peut être réglée qu'une fois que la banque de règlement a confirmé que tous les DFSP participants ayant effectué des transferts dans la fenêtre de règlement ont réglé leurs paiements.
+    * **Settled** : La banque de règlement a confirmé que tous les DFSP concernés ont réglé leurs obligations mutuelles. Suite à la confirmation, l'Opérateur du Hub a réglé la fenêtre de règlement.
+    * **Aborted** : La fenêtre de règlement faisait partie d'un règlement qui a été annulé. Il est possible d'ajouter la fenêtre annulée à un nouveau règlement.
+    * **Clear** : Vous permet de supprimer tous les filtres d'état de fenêtre déjà appliqués.
+* Bouton **Clear Filters** : Vous permet de supprimer tous les filtres que vous avez appliqués.
+
+À mesure que vous appliquez des critères de recherche, la liste des résultats (fenêtres de règlement) est mise à jour en continu. La liste des résultats de recherche affiche les détails suivants :
+
+* Sélecteur de fenêtre : Affiché uniquement pour les fenêtres de règlement **Pending**. Cliquer sur le sélecteur de fenêtre active le bouton **Settle Selected Windows**. Pour plus de détails sur le règlement d'une fenêtre de règlement, voir [Règlement](settling.md#settling-a-closed-settlement-window).
+* **Window ID** : L'identifiant unique de la fenêtre de règlement.
+* **State** : L'état de la fenêtre de règlement.
+* **Opened Date** : La date et l'heure d'ouverture de la fenêtre de règlement.
+* **Closed Date** : La date et l'heure de fermeture de la fenêtre de règlement.
+* **Action** : Bouton **Close Window**. Vous permet de fermer une fenêtre de règlement. Ce bouton n'est affiché que pour les fenêtres de règlement **Open**, car seules les fenêtres ouvertes peuvent être fermées. Pour plus de détails sur la fermeture d'une fenêtre de règlement, voir [Règlement](settling.md#closing-a-settlement-window).
diff --git a/docs/fr/adoption/HubOperations/Portalv2/monitoring-dfsp-financial-details.md b/docs/fr/adoption/HubOperations/Portalv2/monitoring-dfsp-financial-details.md
new file mode 100644
index 00000000..b6422a2a
--- /dev/null
+++ b/docs/fr/adoption/HubOperations/Portalv2/monitoring-dfsp-financial-details.md
@@ -0,0 +1,24 @@
+# Surveillance des détails financiers des DFSP
+
+La page **DFSP Financial Positions** vous permet de surveiller les détails financiers des DFSP tels que le solde, la [Position](settlement-basic-concepts#position) actuelle, le [Net Debit Cap](settlement-basic-concepts#liquidity-management-net-debit-cap), le pourcentage de NDC utilisé.
+
+Pour accéder à la page **DFSP Financial Positions**, allez dans **Participants** > **DFSP Financial Positions**.
+
+![Surveillance des détails financiers des DFSP](../../../../.vuepress/public/dfsp_financial_positions_2.png)
+
+Les détails suivants sont affichés pour chaque DFSP :
+
+* **Balance** : Reflète le solde du compte de liquidité du DFSP auprès de la banque de règlement.
+* **Current Position** : La Position actuelle du DFSP. \
+\
+La Position d'un DFSP reflète — à un moment donné — le total des montants de transfert envoyés et reçus par le DFSP. La Position est la somme de toutes les transactions sortantes moins les transactions entrantes depuis le début de la fenêtre de règlement, ainsi que tous les transferts provisoires qui n'ont pas encore été réglés. \
+\
+Chaque tentative de transfert sortant entraîne le recalcul de la Position par le Hub Mojaloop en temps réel, qui est ensuite comparée au Net Debit Cap. \
+\
+Une fois la fenêtre de règlement fermée, les Positions sont ajustées en fonction du règlement — la Position change pour correspondre au montant net des transferts qui n'étaient pas initiés ou pas encore exécutés lorsque la fenêtre de règlement a été fermée.
+* **NDC** : Le Net Debit Cap défini pour le DFSP. \
+\
+Lors du pré-financement de leur compte de liquidité, les DFSP définissent le montant maximum qu'ils peuvent « devoir » aux autres DFSP, c'est ce qu'on appelle le Net Debit Cap (NDC). Le NDC agit comme une limite ou un plafond sur les fonds disponibles pour les transactions d'un DFSP, et il ne peut jamais dépasser le solde du compte de liquidité. Cela est nécessaire pour garantir que les obligations d'un DFSP peuvent être honorées avec les fonds immédiatement disponibles auprès de la banque de règlement. \
+\
+La Position est continuellement vérifiée par rapport au Net Debit Cap ((MontantTransfert + Position) < = NDC) et si un transfert devait faire dépasser le montant de la Position par rapport au montant du NDC, le transfert est bloqué.
+* **% NDC Used** : Un indicateur Position/NDC pour montrer le pourcentage de NDC utilisé.
diff --git a/docs/fr/adoption/HubOperations/Portalv2/recording-funds-in-out.md b/docs/fr/adoption/HubOperations/Portalv2/recording-funds-in-out.md
new file mode 100644
index 00000000..51661d0b
--- /dev/null
+++ b/docs/fr/adoption/HubOperations/Portalv2/recording-funds-in-out.md
@@ -0,0 +1,31 @@
+# Enregistrement des entrées et sorties de fonds pour un DFSP
+
+La page **DFSP Financial Positions** vous permet d'enregistrer les entrées ou sorties de fonds dans les registres du Hub en cas de mouvement de fonds initié par le DFSP : un DFSP dépose des fonds sur son compte de liquidité ou retire des fonds de son compte de liquidité.
+
+Pour accéder à la page **DFSP Financial Positions**, allez dans **Participants** > **DFSP Financial Positions**.
+
+<img src="../../../../.vuepress/public/dfsp_financial_positions_2.png" width="90%" height="90%" />
+
+Pour enregistrer des entrées ou sorties de fonds pour un DFSP, effectuez les étapes suivantes :
+
+1. Cliquez sur le bouton **Update** à côté du DFSP pour lequel vous souhaitez enregistrer des entrées/sorties de fonds. \
+![](../../../../.vuepress/public/add_withdraw_funds.png) \
+La fenêtre **Update Participant** apparaît.
+1. Sélectionnez **Add / Withdraw Funds** dans le menu déroulant **Action**. \
+<img src="../../../../.vuepress/public/update_participant.png" width="40%" height="40%" />
+1. Sélectionnez l'option **Add Funds** ou **Withdraw Funds** selon l'action que vous souhaitez effectuer. \
+Pour enregistrer un dépôt, utilisez **Add Funds**. \
+Pour enregistrer un retrait, utilisez **Withdraw Funds**. \
+<img src="../../../../.vuepress/public/action_add_withdraw.png" width="40%" height="40%" />
+1. Saisissez le montant ajouté ou retiré par le DFSP dans le champ **Amount**. \
+Ne spécifiez pas de signe plus ou moins lors de la saisie du montant. Assurez-vous plutôt d'avoir sélectionné la bonne action à l'étape précédente.
+1. Cliquez sur **Submit**.
+1. En cliquant sur **Submit**, une fenêtre de confirmation apparaît vous demandant de confirmer l'action, ou de confirmer et également mettre à jour le Net Debit Cap du DFSP. \
+<img src="../../../../.vuepress/public/confirm_action_add_withdraw_funds.png" width="50%" height="50%" />
+
+1. Cliquez sur **Confirm Only** ou **Confirm and Update NDC**. \
+\
+En cliquant sur **Confirm Only**, la valeur **Balance** sur la page **DFSP Financial Positions** est mise à jour et le Hub ajuste les registres. \
+\
+En cliquant sur **Confirm and Update NDC**, la fenêtre **Update Participant** change et vous permet de mettre à jour le Net Debit Cap (NDC). \
+<img src="../../../../.vuepress/public/action_update_ndc.png" width="40%" height="40%" />
diff --git a/docs/fr/adoption/HubOperations/Portalv2/searching-for-transfer-data.md b/docs/fr/adoption/HubOperations/Portalv2/searching-for-transfer-data.md
new file mode 100644
index 00000000..8b985e73
--- /dev/null
+++ b/docs/fr/adoption/HubOperations/Portalv2/searching-for-transfer-data.md
@@ -0,0 +1,189 @@
+# Recherche de données de transfert
+
+Le Finance Portal fournit une page de recherche de transferts, qui vous permet de trouver des données de transfert en fonction des identifiants DFSP, des identifiants d'utilisateur final ou des identifiants de transfert. Cela est utile lors de la résolution de problèmes.
+
+::: tip REMARQUE
+Les valeurs affichées sur la page **Find Transfers** proviennent de la base de données central-ledger du Hub.
+:::
+
+## Recherche de transferts
+
+Pour rechercher des transferts, effectuez les étapes suivantes :
+
+1. Allez dans **Transfers** > **Find Transfers**. La page **Find Transfers** s'affiche. \
+<img src="../../../../.vuepress/public/find_transfers.png" width="90%" height="90%" />
+1. Utilisez les filtres de recherche pour spécifier ce que vous recherchez. Vous pouvez remplir n'importe quel nombre de champs de recherche, dans n'importe quelle combinaison.
+    * **Transfer ID** : Saisissez un `transferId` complet ou un fragment d'un `transferId`.
+    * **Payer FSP ID** : Saisissez le `fspId` complet ou un fragment du `fspId` du DFSP Payeur.
+    * **Payer ID Type** : À l'aide de la liste déroulante, sélectionnez le type d'identifiant utilisé pour identifier le Payeur (par exemple, **MSISDN** ou **ACCOUNT_ID**).
+    * **Payer ID Value** : Saisissez l'identifiant complet ou un fragment de l'identifiant utilisé pour identifier le Payeur (par exemple, un numéro de téléphone ou un numéro de compte bancaire).
+    * **Payee FSPID** : Saisissez le `fspId` complet ou un fragment du `fspId` du DFSP Bénéficiaire.
+    * **Payee ID Type** : À l'aide de la liste déroulante, sélectionnez le type d'identifiant utilisé pour identifier le Bénéficiaire.
+    * **Payee ID Value** : Saisissez l'identifiant complet ou un fragment de l'identifiant utilisé pour identifier le Bénéficiaire.
+    * **From** et **To** : Saisissez l'heure de début et l'heure de fin de la plage horaire pendant laquelle le ou les transferts que vous recherchez ont eu lieu.
+1. Une fois vos filtres de recherche définis, cliquez sur **Find Transfers**. La liste des résultats de recherche correspondant aux critères s'affiche.
+
+Utilisez les boutons de navigation de page en bas de l'écran pour naviguer entre les pages de résultats de recherche.
+
+Vous pouvez supprimer tous les filtres que vous avez appliqués et recommencer votre recherche à zéro en cliquant sur **Clear Filters**.
+
+Les résultats de recherche sont affichés en colonnes. Toutes les colonnes sont triables :
+
+* Cliquez sur un en-tête de colonne pour modifier l'ordre de tri des valeurs affichées dans la colonne.
+* Cliquez sur l'icône de loupe dans l'en-tête de colonne et saisissez une valeur que vous recherchez.
+
+::: tip
+Le nombre total de transferts retournés est limité à mille (1000) (ceci pour limiter la charge sur le backend). Si vous ne parvenez pas à trouver le transfert que vous recherchez parmi les mille premiers résultats, commencez à affiner votre recherche en utilisant les filtres de recherche. \
+ \
+Si votre recherche retourne plus de cinq cents (500) résultats, la page affichera un message d'information pour que vous sachiez que vous ne voyez pas nécessairement tous les résultats correspondant à vos critères de recherche initiaux et que vous devriez affiner davantage.
+:::
+
+Les détails suivants sont affichés pour un transfert :
+
+::: tip REMARQUE
+Les transferts sans devis (c'est-à-dire les transferts « ajout/retrait de fonds » et les transferts de règlement) n'afficheront des détails que pour les champs suivants : **Transfer ID**, **Timestamp**, **Amount**, **Currency**, **Status**.
+:::
+
+* **Transfer ID** : L'identifiant unique du transfert (correspond à `transferId`).
+* **Type** : Le type de transfert (correspond à `transactionType` dans Payment Manager et `transactionScenario` dans l'API Mojaloop FSPIOP).
+* **Timestamp** : La date et l'heure de création de la demande de transfert, sous forme d'horodatage au format [ISO-8601](https://www.iso.org/iso-8601-date-and-time-format.html).
+* **Payer FSPID** : Le `fspId` du DFSP Payeur.
+* **Payee FSPID** : Le `fspId` du DFSP Bénéficiaire.
+* **Amount** : Le montant du transfert.
+* **Currency** : La devise du transfert.
+* **Status** : L'état du transfert (correspond à `transferState` dans Payment Manager et l'API Mojaloop FSPIOP).
+* **Payer Acct ID** : Le type d'identifiant et la valeur d'identifiant du compte du Payeur.
+* **Payee Acct ID** : Le type d'identifiant et la valeur d'identifiant du compte du Bénéficiaire.
+
+## Détails du transfert
+
+Pour obtenir plus de détails sur un résultat de recherche particulier, cliquez sur son entrée dans la liste des résultats de recherche. Une fenêtre contextuelle **Transfer Details** apparaît. Cette section fournit des informations sur les détails affichés pour un transfert.
+
+### Demandes de devis
+
+L'onglet **Quote Requests** affiche le `quoteId` et des informations supplémentaires dans des sous-onglets.
+
+#### Sous-onglet Quote Request
+
+<img src="../../../../.vuepress/public/transfer_details_quote_request.png" width="70%" height="70%" />
+
+Le sous-onglet **Quote Request** affiche les détails suivants concernant la demande de devis :
+
+* **quoteId** : L'identifiant unique du devis, décidé par le DFSP Payeur.
+* **transactionReferenceId** : Correspond au `transactionId` spécifié dans la demande de devis.
+* **transactionRequestId** : Facultatif. Identifiant commun entre les DFSP pour l'objet de demande de transaction, décidé par le DFSP Bénéficiaire.
+* **note** : Un mémo facultatif attaché au transfert.
+* **expirationDate** : Une date d'expiration facultative de la demande de devis, sous forme d'horodatage au format [ISO-8601](https://www.iso.org/iso-8601-date-and-time-format.html).
+* **amount** : Le montant pour lequel le devis est demandé.
+* **createdDate** : La date et l'heure de création de la demande de devis, sous forme d'horodatage au format [ISO-8601](https://www.iso.org/iso-8601-date-and-time-format.html).
+* **transactionInitiator** : Indique si l'initiateur du transfert est le **PAYER** (Payeur) ou le **PAYEE** (Bénéficiaire).
+* **transactionInitiatorType** : Indique le type de l'initiateur :
+    * **CONSUMER** : Le consommateur est l'initiateur de la transaction. Par exemple : transfert de personne à personne ou remboursement de prêt depuis un portefeuille.
+    * **AGENT** : L'agent est l'initiateur de la transaction. Par exemple : remboursement de prêt via un agent.
+    * **BUSINESS** : L'entreprise est l'initiateur de la transaction. Par exemple : décaissement de prêt.
+    * **DEVICE** : L'appareil est l'initiateur de la transaction. Par exemple : paiement marchand initié par le commerçant et autorisé sur un TPE.
+* **transactionScenario** : Indique le scénario de transaction (correspond à `transactionType` dans Payment Manager).
+* **transactionSubScenario** : Indique le sous-scénario de transaction défini par le schéma.
+* **balanceOfPaymentsType** : Le code BdP tel que défini dans [le Système de codification de la balance des paiements du FMI](https://www.imf.org/external/np/sta/bopcode/).
+* **amountType** : **SEND** pour le montant envoyé, **RECEIVE** pour le montant reçu.
+* **currency** : La devise du montant pour lequel le devis est demandé. Un code alphabétique de trois lettres conforme à [ISO 4217](https://www.iso.org/iso-4217-currency-codes.html).
+
+#### Sous-onglet Quote Parties
+
+<img src="../../../../.vuepress/public/transfer_details_quote_parties.png" width="70%" height="70%" />
+
+Le sous-onglet **Quote Parties** affiche les détails suivants concernant le DFSP Payeur et le DFSP Bénéficiaire :
+
+* **quoteId** : L'identifiant unique du devis, décidé par le DFSP Payeur.
+* **partyIdentifierType** : Le type d'identifiant utilisé pour identifier la partie (par exemple, **MSISDN** ou **ACCOUNT_ID**).
+* **partyIdentifierValue** : La valeur de l'identifiant utilisé pour identifier la partie (par exemple, un numéro de téléphone ou un numéro de compte bancaire).
+* **fspId** : L'identifiant unique du DFSP enregistré dans le Hub (correspond à `fspId`) - tel que fourni dans le devis.
+* **merchantClassificationCode** : Utilisé lorsque le Bénéficiaire est un commerçant acceptant les paiements marchands.
+* **partyName** : Le nom d'affichage de la partie.
+* **transferParticipantRoleType** : Le rôle que le DFSP joue dans le transfert.
+* **ledgerEntryType** : Le type d'écriture financière que cette partie présente — valeur principale (c'est-à-dire le montant d'argent que le Payeur souhaite que le Bénéficiaire reçoive) ou commission d'interchange.
+* **amount** : Le montant pour lequel le devis est demandé.
+* **currency** : La devise du montant pour lequel le devis est demandé. Un code alphabétique de trois lettres conforme à [ISO 4217](https://www.iso.org/iso-4217-currency-codes.html).
+* **createdDate** : La date et l'heure de création de la demande de devis, sous forme d'horodatage au format [ISO-8601](https://www.iso.org/iso-8601-date-and-time-format.html).
+* **partySubIdOrTypeId** : Un sous-identifiant ou sous-type pour la partie.
+* **participant** : Référence au `fspId` résolu (si fourni/connu).
+
+#### Sous-onglet Quote Errors
+
+Le sous-onglet **Quote Errors** n'affiche des informations que s'il y a eu une erreur lors de l'étape des devis.
+
+### Réponses aux devis
+
+<img src="../../../../.vuepress/public/transfer_details_quote_responses.png" width="70%" height="70%" />
+
+L'onglet **Quote Responses** affiche les détails concernant la réponse au devis :
+
+* **quoteId** : L'identifiant unique du devis, décidé par le DFSP Payeur.
+* **transactionReferenceId** : Correspond au `transactionId` spécifié dans la demande de devis.
+* **quoteResponseId** : L'identifiant unique de la réponse au devis.
+* **transferAmountCurrencyId** : La devise du montant du transfert. Un code alphabétique de trois lettres conforme à [ISO 4217](https://www.iso.org/iso-4217-currency-codes.html).
+* **transferAmount** : Le montant que le DFSP Payeur doit transférer au DFSP Bénéficiaire.
+* **payeeReceiveAmountCurrencyId** : La devise du montant que le Bénéficiaire doit recevoir dans la transaction de bout en bout.
+* **payeeReceiveAmount** : Le montant que le Bénéficiaire doit recevoir dans la transaction de bout en bout.
+* **payeeFspFeeCurrencyId** : La devise de la part des frais de transaction du DFSP Bénéficiaire (le cas échéant). Un code alphabétique de trois lettres conforme à [ISO 4217](https://www.iso.org/iso-4217-currency-codes.html).
+* **payeeFspFeeAmount** : La part des frais de transaction du DFSP Bénéficiaire (le cas échéant).
+* **payeeFspCommissionCurrencyId** : La devise de la commission de transaction du DFSP Bénéficiaire (le cas échéant). Un code alphabétique de trois lettres conforme à [ISO 4217](https://www.iso.org/iso-4217-currency-codes.html).
+* **payeeFspCommissionAmount** : La commission de transaction du DFSP Bénéficiaire (le cas échéant).
+* **ilpCondition** : La condition ILP qui doit être jointe au transfert par le côté Payeur.
+* **responseExpirationDate** : La date d'expiration du devis sous forme d'horodatage au format [ISO-8601](https://www.iso.org/iso-8601-date-and-time-format.html).
+* **isValid** : Un indicateur indiquant si la réponse au devis a passé la validation de la demande et les vérifications de doublons.
+* **createdDate** : La date et l'heure de création de la demande de devis, sous forme d'horodatage au format [ISO-8601](https://www.iso.org/iso-8601-date-and-time-format.html).
+* **ilpPacket** : Le paquet ILP retourné par le côté Bénéficiaire en réponse à la demande de devis.
+
+### Préparations de transfert
+
+<img src="../../../../.vuepress/public/transfer_details_transfer_prepares.png" width="70%" height="70%" />
+
+L'onglet **Transfer Prepares** affiche les détails concernant la demande de transfert :
+
+* **transferId** : L'identifiant unique du transfert.
+* **amount** : Le montant que le DFSP Payeur doit transférer au DFSP Bénéficiaire.
+* **currencyId** : La devise du montant du transfert. Un code alphabétique de trois lettres conforme à [ISO 4217](https://www.iso.org/iso-4217-currency-codes.html).
+* **ilpCondition** : La condition ILP qui doit être remplie pour valider le transfert.
+* **expirationDate** : La date d'expiration du transfert sous forme d'horodatage au format [ISO-8601](https://www.iso.org/iso-8601-date-and-time-format.html).
+* **createdDate** : La date et l'heure de création de la demande de transfert, sous forme d'horodatage au format [ISO-8601](https://www.iso.org/iso-8601-date-and-time-format.html).
+
+### Participants au transfert
+
+<img src="../../../../.vuepress/public/transfer_details_transfer_participants.png" width="70%" height="70%" />
+
+L'onglet **Transfer Participants** affiche les détails suivants concernant les participants au transfert :
+
+* **transferParticipantId** : L'identifiant interne du participant au schéma (DFSP) pour lequel le rapport est demandé, correspond à `participantId` tel qu'enregistré dans le Hub.
+* **transferId** : L'identifiant unique du transfert.
+* **participantCurrencyId** : La devise dans laquelle le participant (DFSP) effectue ses transactions. Un code alphabétique de trois lettres conforme à [ISO 4217](https://www.iso.org/iso-4217-currency-codes.html).
+* **transferParticipantRoleType** : Le rôle que le DFSP joue dans le transfert.
+* **ledgerEntryType** : Le type d'écriture financière que cette partie présente — valeur principale (c'est-à-dire le montant d'argent que le Payeur souhaite que le Bénéficiaire reçoive) ou commission d'interchange.
+* **amount** : Le montant du transfert.
+* **createdDate** : La date et l'heure de création de la demande de transfert, sous forme d'horodatage au format [ISO-8601](https://www.iso.org/iso-8601-date-and-time-format.html).
+
+### Exécutions de transfert
+
+<img src="../../../../.vuepress/public/transfer_details_transfer_fulfilments.png" width="70%" height="70%" />
+
+L'onglet **Transfer Fulfilments** affiche les détails suivants concernant la réponse au transfert :
+
+* **transferId** : L'identifiant unique du transfert.
+* **ilpFulfilment** : L'exécution de la condition ILP spécifiée dans la demande de transfert.
+* **completedDate** : La date et l'heure d'achèvement du transfert, sous forme d'horodatage au format [ISO-8601](https://www.iso.org/iso-8601-date-and-time-format.html).
+* **isValid** : Un indicateur indiquant si l'exécution du transfert est valide.
+* **settlementWindowId** : L'identifiant de la fenêtre de règlement à laquelle ce transfert a été assigné.
+* **createdDate** : La date et l'heure de création de la réponse au transfert, sous forme d'horodatage au format [ISO-8601](https://www.iso.org/iso-8601-date-and-time-format.html).
+
+### Changements d'état du transfert
+
+<img src="../../../../.vuepress/public/transfer_details_transfer_state_changes.png" width="70%" height="70%" />
+
+L'onglet **Transfer State Changes** affiche les détails suivants concernant les états par lesquels passe un transfert :
+
+* **transferStateChangeId** : L'identifiant unique de l'état du transfert.
+* **transferId** : L'identifiant unique du transfert.
+* **enumeration** : L'état du transfert (correspond à `transferState` dans Payment Manager et l'API Mojaloop FSPIOP).
+* **description** : La description de la signification de l'état.
+* **reason** : La raison pour laquelle le transfert est passé dans un état particulier.
+* **createdDate** : La date et l'heure auxquelles le transfert a atteint un état particulier, sous forme d'horodatage au format [ISO-8601](https://www.iso.org/iso-8601-date-and-time-format.html).
diff --git a/docs/fr/adoption/HubOperations/Portalv2/settlement-business-process.md b/docs/fr/adoption/HubOperations/Portalv2/settlement-business-process.md
new file mode 100644
index 00000000..65335d92
--- /dev/null
+++ b/docs/fr/adoption/HubOperations/Portalv2/settlement-business-process.md
@@ -0,0 +1,68 @@
+# Processus de règlement
+
+Il est important de définir un processus métier autour de la gestion des règlements. Le processus de haut niveau suivant sert d'exemple que vous pouvez personnaliser en fonction des besoins spécifiques de votre organisation.
+
+<table>
+<caption><strong>Processus métier de règlement</strong></caption>
+<colgroup>
+<col style="width: 14%" />
+<col style="width: 85%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Étape</th>
+<th>Détails</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>1</p></td>
+<td><p>L'Opérateur du Hub <a href="settling.html">ferme la fenêtre de règlement et initie le règlement pour les fenêtres sélectionnées à l'aide du Finance Portal</a>.</p></td>
+</tr>
+<tr class="even">
+<td><p>2</p></td>
+<td><p>L'Opérateur du Hub récupère un rapport de règlement DFSP pour chaque DFSP actif dans la fenêtre de règlement.</p></td>
+</tr>
+<tr class="odd">
+<td><p>3</p></td>
+<td><p>L'Opérateur du Hub envoie par courriel le rapport de règlement DFSP aux points de contact désignés de chaque DFSP.</p></td>
+</tr>
+<tr class="even">
+<td><p>4</p></td>
+<td><p>Les DFSP examinent leur rapport et rapprochent les transactions avec leurs propres enregistrements dans les meilleurs délais.</p>
+<p>Le rapport fournit des informations sur la position de règlement bilatérale du DFSP avec chaque DFSP avec lequel il a effectué des transactions (soit en tant que DFSP Payeur, soit en tant que DFSP Bénéficiaire) dans la ou les fenêtres de règlement en cours de règlement. Il fournit également le total des montants de transfert envoyés et reçus par le DFSP dans la ou les fenêtres de règlement.</p></td>
+</tr>
+<tr class="odd">
+<td><p>5</p></td>
+<td><p>L'Opérateur du Hub récupère le rapport bancaire de règlement.</p></td>
+</tr>
+<tr class="even">
+<td><p>6</p></td>
+<td><p>L'Opérateur du Hub informe les points de contact de la banque de règlement que le règlement peut être effectué, en partageant le rapport bancaire de règlement.</p><p>Le rapport sert d'instructions de paiement à la banque et fournit la position de règlement bilatérale de chaque DFSP par rapport à chaque autre DFSP ayant effectué des transactions dans la ou les fenêtres de règlement en cours de règlement. Il fournit également le total des montants de transfert envoyés et reçus par chaque DFSP.</p></td>
+</tr>
+<tr class="odd">
+<td><p>7</p></td>
+<td><p>La banque de règlement transfère les fonds entre le compte de règlement et les comptes de liquidité des DFSP, conformément aux Positions nettes agrégées indiquées dans le rapport bancaire de règlement.</p></td>
+</tr>
+<tr class="even">
+<td><p>8</p></td>
+<td><p>La banque de règlement confirme que les fonds ont été transférés et (puisque l'Opérateur du Hub n'a pas de visibilité sur le solde des comptes détenus à la banque de règlement) partage le solde du compte de liquidité de chaque DFSP.</p></td>
+</tr>
+<tr class="odd">
+<td><p>9</p></td>
+<td><p>L'Opérateur du Hub <a href="settling.html">finalise le règlement à l'aide du Finance Portal</a>.</p></td>
+</tr>
+<tr class="even">
+<td><p>10</p></td>
+<td><p>L'Opérateur du Hub <a href="monitoring-dfsp-financial-details.html">vérifie les soldes des comptes de liquidité des DFSP par rapport aux soldes affichés dans le portail</a>, et les met à jour si nécessaire, en utilisant la <a href="recording-funds-in-out.html">fonctionnalité « ajouter/retirer des fonds » du portail</a>. Notez que cela peut entraîner un recalcul du NDC du DFSP, ce qui pourrait provoquer le rejet des transactions sortantes du DFSP par le Hub.</p></td>
+</tr>
+<tr class="odd">
+<td><p>11</p></td>
+<td><p>L'Opérateur du Hub récupère un rapport de résultat de règlement DFSP pour chaque DFSP.</p></td>
+</tr>
+<tr class="even">
+<td><p>12</p></td>
+<td><p>L'Opérateur du Hub informe chaque DFSP du résultat du règlement et du solde de son compte de liquidité en envoyant le rapport de résultat de règlement DFSP à chaque DFSP.</p></td>
+</tr>
+</tbody>
+</table>
diff --git a/docs/fr/adoption/HubOperations/Portalv2/settling.md b/docs/fr/adoption/HubOperations/Portalv2/settling.md
new file mode 100644
index 00000000..acd8b779
--- /dev/null
+++ b/docs/fr/adoption/HubOperations/Portalv2/settling.md
@@ -0,0 +1,67 @@
+# Règlement
+
+1. [Fermez la fenêtre de règlement](#closing-a-settlement-window) que vous souhaitez régler.
+1. [Réglez la ou les fenêtres fermées de votre choix](#settling-a-closed-settlement-window). Cela crée un nouveau règlement.
+1. Envoyez les rapports de règlement aux DFSP et à la banque de règlement, puis obtenez une confirmation de la banque attestant qu'elle a transféré les fonds conformément au rapport.
+1. [Finalisez le nouveau règlement](#finalizing-a-settlement) créé à l'étape 2.
+
+Cette section décrit les étapes du processus (étapes 1, 2 et 4) que vous effectuez via le portail.
+
+## Fermeture d'une fenêtre de règlement
+
+Pour fermer une fenêtre de règlement ouverte, effectuez les étapes suivantes :
+
+1. Allez dans **Settlement** > **Settlement Windows**. La page **Settlement Windows** s'affiche.
+1. Trouvez la fenêtre de règlement que vous recherchez, [en utilisant les filtres de recherche](managing-windows.md).
+1. La fenêtre ouverte aura un bouton **Close Window** affiché à côté d'elle dans la colonne **Action**. Cliquez sur le bouton **Close Window**.
+
+![Fermeture d'une fenêtre de règlement](../../../../.vuepress/public/settlement_window_mgmt_close.png)
+
+La fermeture d'une fenêtre ouvrira automatiquement une nouvelle fenêtre avec l'état **Open**.
+
+## Règlement d'une fenêtre de règlement fermée
+
+Pour régler une ou plusieurs fenêtres de règlement, effectuez les étapes suivantes :
+
+1. Allez dans **Settlement** > **Settlement Windows**. La page **Settlement Windows** s'affiche.
+1. Trouvez la fenêtre de règlement que vous recherchez, [en utilisant les filtres de recherche](managing-windows.md). La fenêtre de règlement doit être à l'état **Closed**.
+1. Cliquez sur le sélecteur de fenêtre à côté de la ou des fenêtres de règlement que vous souhaitez régler. \
+\
+<img src="../../../../.vuepress/public/settlement_window_mgmt_selector.png" /> \
+\
+Cela active le bouton **Settle Selected Windows**. Cliquez sur le bouton **Settle Selected Windows**. \
+\
+<img src="../../../../.vuepress/public/settlement_window_mgmt_settle_button.png" /> 
+1. Une fenêtre **Settlement Submitted** apparaît, où vous avez les options suivantes :
+
+* Afficher les règlements soumis
+* Continuer à afficher les fenêtres \
+\
+<img src="../../../../.vuepress/public/settlement_window_settlement_submitted.png" width="50%" height="50%" /> \
+\
+Si vous souhaitez afficher le nouveau règlement que vous venez de créer, cliquez sur le bouton **View Submitted Settlements**. Cela vous amène à la page **Settlements**, où vous pouvez rechercher le nouveau règlement, [en utilisant les filtres de recherche](checking-settlement-details.md). Le règlement sera à l'état **Pending Settlement**.
+
+## Finalisation d'un règlement
+
+Pour finaliser le règlement, effectuez les étapes suivantes :
+
+**Prérequis :**
+
+* La banque de règlement a confirmé que toutes les Positions MLNS des DFSP ont été réglées.
+
+**Étapes :**
+
+1. Allez dans **Settlement** > **Settlements**. La page **Settlements** s'affiche.
+1. Trouvez le règlement que vous recherchez, en utilisant les [filtres de recherche](checking-settlement-details.md). Le règlement doit être à l'état **Pending Settlement**. \
+\
+<img src="../../../../.vuepress/public/finalise_settlement.png" /> 
+1. Cliquez sur le bouton **Finalize** à côté du règlement. Une fenêtre de statut apparaît et affiche les états du règlement avec des coches ajoutées au fur et à mesure que le processus de règlement progresse. \
+\
+Lorsque le règlement est finalisé, vous verrez tous les états affichés avec des coches à côté. Le dernier état indiquera **State: SETTLED.** De plus, le bouton **Close** sera activé, vous permettant de revenir à la page **Settlements**. \
+\
+<img src="../../../../.vuepress/public/finalising_settlement_popup.png" /> 
+1. De retour sur la page **Settlements**, en recherchant le règlement, vous devriez voir l'état du règlement affiché comme **Settled**.
+
+::: tip
+Si l'état du règlement est autre que **Settled**, cela signifie que le règlement ne s'est pas terminé pour une raison quelconque. Cliquez à nouveau sur **Finalize** pour terminer le processus de règlement inachevé.
+:::
diff --git a/docs/fr/adoption/HubOperations/Portalv2/updating-ndc.md b/docs/fr/adoption/HubOperations/Portalv2/updating-ndc.md
new file mode 100644
index 00000000..a03d72b2
--- /dev/null
+++ b/docs/fr/adoption/HubOperations/Portalv2/updating-ndc.md
@@ -0,0 +1,22 @@
+# Mise à jour du Net Debit Cap d'un DFSP
+
+La page **DFSP Financial Positions** vous permet de mettre à jour le Net Debit Cap (NDC) d'un DFSP.
+
+Pour accéder à la page **DFSP Financial Positions**, allez dans **Participants** > **DFSP Financial Positions**.
+
+![Mise à jour du NDC d'un DFSP]("../../../../.vuepress/public/dfsp_financial_positions_2.png")
+
+Pour mettre à jour le Net Debit Cap d'un DFSP, effectuez les étapes suivantes :
+
+1. Cliquez sur le bouton **Update** à côté du DFSP pour lequel vous souhaitez mettre à jour le NDC. \
+<img src="../../../../.vuepress/public/add_withdraw_funds.png" width="90%" height="90%" />
+La fenêtre **Update Participant** apparaît.
+1. Sélectionnez **Change Net Debit Cap** dans le menu déroulant **Action**. \
+<img src="../../../../.vuepress/public/update_participant.png" width="40%" height="40%" />
+1. Saisissez le nouveau montant du NDC dans le champ **Amount**. \
+<img src="../../../../.vuepress/public/action_change_net_debit_cap.png" width="40%" height="40%" />
+1. Cliquez sur **Submit**.
+1. En cliquant sur **Submit**, une fenêtre de confirmation apparaît vous demandant de confirmer l'action. \
+<img src="../../../../.vuepress/public/confirm_action_update_ndc.png" width="50%" height="50%" />
+1. Cliquez sur **Confirm**. \
+En cliquant sur **Confirm**, la valeur **NDC** sur la page **DFSP Financial Positions** est mise à jour et affiche le nouveau montant du NDC.
diff --git a/docs/fr/adoption/HubOperations/RBAC/Role-based-access-control.md b/docs/fr/adoption/HubOperations/RBAC/Role-based-access-control.md
new file mode 100644
index 00000000..2c4e8258
--- /dev/null
+++ b/docs/fr/adoption/HubOperations/RBAC/Role-based-access-control.md
@@ -0,0 +1,311 @@
+# Contexte du RBAC
+Le Hub Mojaloop utilise une méthode de contrôle d'accès basé sur les rôles (RBAC) pour atténuer les risques.
+
+## Qu'est-ce que le RBAC et comment le concevoir ?
+
+Le contrôle d'accès basé sur les rôles (RBAC) est une méthode de restriction de l'accès au réseau en fonction des rôles des utilisateurs individuels au sein d'une entreprise. Le RBAC permet aux employés d'avoir des droits d'accès uniquement aux informations dont ils ont besoin pour effectuer leur travail et les empêche d'accéder aux informations qui ne les concernent pas.
+
+La conception RBAC pour un opérateur de hub décrit les points de contrôle de sécurité qui doivent être pris en compte ou étendus afin d'atténuer les risques au sein d'une organisation typique d'exploitation de hub Mojaloop. Certains points de contrôle sont liés aux processus métier et à la structure organisationnelle, certains points de contrôle sont techniques et concernent les couches d'identification, d'authentification et d'autorisation, et certains points de contrôle nécessitent une surveillance. Les trois doivent être pris en compte pour créer la responsabilité et atténuer les risques.
+
+Ce document couvre :
+1. Vue d'ensemble du RBAC.<br>
+Où nous discutons des principes RBAC et des structures organisationnelles.
+2. Implémentation technique des contrôles RBAC.<br>
+Spécifiquement ce qui est important pour une implémentation Mojaloop et comment l'appliquer techniquement.
+3. Recommandations de rôles
+4. Exigences et approche de surveillance.
+
+## Vue d'ensemble du RBAC
+
+### Principe du moindre privilège
+
+Le RBAC utilise le principe de sécurité du moindre privilège. Le moindre privilège signifie qu'un utilisateur dispose précisément du niveau de privilège nécessaire pour effectuer son travail. L'objectif est de minimiser la probabilité d'attribuer à un utilisateur des permissions excessives pour effectuer des actions dans l'écosystème Mojaloop.
+
+### Implémentation Zero Trust de Mojaloop
+
+Un réseau zero trust est un réseau dans lequel aucune personne, appareil ou réseau ne bénéficie d'une confiance inhérente. Toute confiance, qui permet l'accès aux informations, doit être méritée, et la première étape consiste à démontrer une identité valide. Un système doit savoir qui vous êtes, avec certitude, avant de pouvoir déterminer ce à quoi vous devriez avoir accès.
+
+La conception inhérente de Mojaloop implémentera une approche Zero Trust dans son architecture et son déploiement, exigeant que toutes les entités qui interagissent s'authentifient d'abord, puis demandent l'autorisation d'accéder et de traiter les données en fonction du rôle auquel elles appartiennent.
+
+### Séparation des fonctions
+
+La séparation des fonctions vise à atténuer le risque de fraude interne en fixant des limites entre les rôles attribués à un employé, et entre les conflits d'intérêts pouvant résulter des responsabilités d'un employé, en veillant à ce qu'aucun utilisateur unique ne puisse avoir le contrôle fonctionnel de bout en bout d'un processus métier et de ses données. Cela nécessite que plus d'un individu crée, traite et complète une action.
+
+### Audit
+
+L'audit devrait travailler en collaboration avec les équipes métier et informatiques pour séparer ces fonctions dans la mesure du possible et attribuer un contrôle d'atténuation approprié dans les cas où cela n'est pas faisable. De plus, ces contrôles devraient être surveillés sur une base trimestrielle et les résultats doivent être signalés à la direction.
+
+Quelques définitions contextuelles incluent :
+1. **Action** : un événement distinct déclenché par un utilisateur qui entraîne :
+   - La création d'un actif de données
+   - La lecture ou l'accès à un actif de données
+   - La mise à jour ou la modification de l'état d'un actif de données
+   - La suppression ou le retrait d'un actif de données d'une application ou d'une base de données.
+2. **Permission** : autorité pour effectuer une action spécifique dans le contexte d'une application ou d'un service
+3. **Rôle** : applications, actions et accès aux données nécessaires pour effectuer les tâches liées à un rôle unique
+4. **Relation utilisateur - rôle** : Le ou les rôles attribués à chaque utilisateur qui définissent les permissions dont ils disposent
+
+## Implémentation technique du RBAC
+
+Un individu qui a besoin d'accéder aux différents portails de gestion du Hub Mojaloop peut être enregistré et un « compte » généré, qui peut être utilisé pour accéder à divers aspects d'une instance opérationnelle d'un Hub Mojaloop et pour fournir une base d'audit de cet accès en liant les activités à l'enregistrement original. Aux fins de ce document, un « compte » est une identité numérique, un moyen d'authentifier (lier) la personne revendiquant cette identité à l'enregistrement original, et un ensemble d'attributs, qui incluront - entre autres - un ensemble de droits d'accès, ou des droits qui sont activés par la possession de ces attributs.
+
+Le processus d'enregistrement implique la vérification d'identité, la vérification des antécédents, etc. L'individu reçoit ensuite des identifiants - un identifiant de compte de connexion/identité numérique et au moins une méthode d'authentification, qui peut inclure un mot de passe et une authentification à deux facteurs (2FA).
+
+::: tip NOTE
+La portée de ce document ne se limite pas aux opérateurs du Hub Mojaloop. Il aborde également les aspects de l'accès des opérateurs DFSP aux portails Payment Manager.
+:::
+
+### Considérations relatives à la 2FA
+
+Il convient de noter que la 2FA via un téléphone mobile peut être inappropriée pour certains rôles, car les rôles très sensibles peuvent exiger que les téléphones mobiles soient rangés sous clé pendant que l'individu est « en service ». Cela nécessitera d'autres méthodes de 2FA, telles que des jetons physiques.
+
+### Utilisateurs, actions et rôles dans un contexte Mojaloop
+
+Mojaloop aura 2 grandes catégories d'utilisateurs :
+
+1. **Humains** <br>
+Ce sont les utilisateurs du hub et des DFSP qui, à travers diverses interfaces, interagiront avec Mojaloop. Les utilisateurs DFSP interagiront avec Mojaloop à travers le Payment Manager et les portails qui seront mis à disposition pendant le processus d'intégration.
+2. **Non-humains** <br> 
+Ceux-ci automatiseront les processus métier et les tâches qui seraient autrement effectuées par un humain. Ils communiqueront via des appels API qui effectueront des actions pour répondre aux exigences métier.
+
+Le contexte de ce document se concentrera uniquement sur les utilisateurs humains.
+
+### Gestion du cycle de vie des utilisateurs
+
+Le « cycle de vie du compte utilisateur » définit les processus de gestion collectifs pour chaque compte utilisateur. Ces processus peuvent être décomposés en Création, Révision/Mise à jour et Désactivation — ou « CRUD ». Si une organisation utilise des ressources informatiques de quelque nature que ce soit, elle s'appuie sur des comptes utilisateurs pour y accéder.
+
+### Intégration
+
+Le processus d'intégration comprendra certaines activités impliquant la création d'utilisateurs tant du côté DFSP que du Hub. Celles-ci seront les suivantes :
+
+1. Hub : Les utilisateurs suivants seront créés
+   - Opérateurs du Hub
+   - Administrateurs du Hub
+2. DFSP
+   - Opérateurs DFSP
+   - Administrateurs DFSP (applicable uniquement au Payment Manager).
+
+
+### Processus de détermination de la séparation des fonctions
+
+1. Définir les flux de travail et processus de gestion des utilisateurs. Ce sont tous les processus métier qui composent les actions métier Mojaloop dans Mojaloop. Les exemples incluent l'intégration.
+1. Rationaliser toutes les exigences d'accès de sécurité des utilisateurs pour les applications de Mojaloop comme indiqué dans le tableau ci-dessous :
+   - Définir les fonctions métier et applicatives pour les utilisateurs et les API
+   - Définir les profils de rôles
+   - Définir les profils de fonctions et de compétences
+   - Rassembler une liste des conflits de séparation des fonctions applicables en définissant les rôles de séparation des fonctions
+   - Tableau matriciel des profils de rôles (avec des données d'exemple) :
+
+| **Rôles et Permissions**  **Matrice** | Utilisateurs Hub | Administrateur | Utilisateur Maker Standard | Utilisateur Checker Standard | Lecture Seule Standard | Utilisateurs DFSP | Administrateur | Utilisateur Maker Standard | Utilisateur Checker Standard | Lecture Seule Standard |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
+| Rôles d'intégration | X | | | | | | | | | |
+| Créer un compte utilisateur | X | | | | | | | | | |
+| Créer un profil DFSP | X | | | | | | | | | |
+| Créer un utilisateur DFSP | X | | | | | | | | | |
+|
+| **Portail Financier** |
+| Voir les rapports | | | X | X | X | | | X | X | X |
+| Configuration de la plateforme | | | | | | | | | | |
+|
+
+3. Reconfigurer les rôles en conflit
+   - Approbations métier
+   - Création d'utilisateurs Maker/Checker
+4. Rapports périodiques sur l'accès au système et l'autorisation des utilisateurs
+5. Séparation de la sécurité informatique et de la sécurité informatique opérationnelle qui soutiendra les activités de gestion des utilisateurs
+
+### Meilleures pratiques pour le RBAC et la gestion des identités Mojaloop
+
+1. Tous les identifiants d'utilisateurs doivent être uniques et avoir un format unique qui peut être corrélé dans le hub mais pas significatif pour les personnes extérieures.
+2. Les utilisateurs DFSP n'auront accès à aucun rôle administratif du Hub
+3. Tous les utilisateurs non-humains doivent être empêchés de se connecter aux interfaces applicatives.
+4. Les utilisateurs DFSP seront formés sur les rôles et les meilleures pratiques
+5. Appliquer le provisionnement automatisé des utilisateurs et la gestion du cycle de vie.
+6. Classer les actions effectuées dans Mojaloop pour identifier les actions métier à risque nécessitant des contrôles supplémentaires.
+7. Les contrôles supplémentaires pour atténuer les risques RBAC peuvent inclure :
+   - Authentification multifacteur (MFA)
+   - Journalisation d'audit avec alertes
+   - Désactivation / blocage automatique du profil utilisateur
+8. Mojaloop surveillera l'inactivité des utilisateurs et désactivera les utilisateurs inactifs sur une période spécifiée
+9. Appliquer une politique centralisée d'application à travers les identités, par ex. politique de mots de passe, politiques de connexion, MFA, authentification basée sur le risque, etc.
+10. Identifier et surveiller de près les identités privilégiées qui ont des permissions pour effectuer des actions sensibles. 
+Les éléments suivants s'appliquent aux utilisateurs privilégiés :
+    - Les privilèges avancés doivent être demandés et approuvés au cas par cas ;
+    - Les administrateurs doivent avoir leurs permissions privilégiées pour le minimum de temps possible ;
+    - Les administrateurs ne doivent avoir que les permissions nécessaires pour accomplir une tâche spécifique ;
+    - L'appartenance aux groupes administratifs doit être révisée régulièrement ;
+    - Appliquer l'authentification multifacteur pour les utilisateurs administratifs ;
+    - Conserver les journaux d'accès, les audits et configurer des notifications en temps réel lorsque l'accès est activé.
+11. Mojaloop configurera des journaux d'audit et des alertes pour toutes les actions des utilisateurs dans Mojaloop. Dans la mesure du possible, explorer l'analytique des identités via des outils open source applicables.
+
+### Gestion automatisée des identités et contrôle RBAC
+
+Les outils préférés pour la gestion des utilisateurs et des identités dans un déploiement Mojaloop sont :
+
+1. **Moteur de gestion des identités KeyCloak** – Stocker et traiter les contrôles d'authentification API ainsi qu'agir comme passerelle API.
+2. **Moteur de gestion des identités WSO2** – Stocker et traiter les profils de rôles des utilisateurs et gérer l'auto-intégration des utilisateurs DFSP.
+
+## Conception des rôles au sein de votre organisation
+
+Un utilisateur avec un compte qui permet l'accès au Hub aura des rôles associés à ce compte, qui définissent ce qu'il peut faire une fois authentifié et connecté.
+
+De nombreux rôles s'appliquent à plusieurs portails, cependant, certains rôles peuvent être spécifiques à des portails individuels.
+
+Une attention particulière doit être portée lors de l'attribution de plusieurs rôles à un compte, ou de plusieurs comptes à une même personne physique. Cela est dû au potentiel qui se présente pour le contournement des contrôles. Une partie de l'objectif du RBAC est de s'assurer que plus d'une personne doit être dans la chaîne d'autorisation pour les actions importantes, réduisant ainsi les vulnérabilités liées aux acteurs malveillants.
+
+### Portails de l'écosystème Mojaloop
+
+L'écosystème Mojaloop offre un certain nombre de portails, qui prennent en charge divers degrés de contrôle d'accès et de RBAC. Ceux-ci sont divisés en deux groupes :
+
+- Portails du Hub, qui sont liés au fonctionnement du Hub lui-même
+- Portails Payment Manager, qui sont liés à la gestion de la connexion d'un DFSP spécifique au Hub
+
+### RBAC dans le Hub Mojaloop
+
+Dans l'environnement du Hub Mojaloop, le RBAC est implémenté à travers une combinaison d'outils - Ory Oathkeeper pour la gestion des identités, et Keycloak pour le contrôle d'accès (y compris les rôles et le maker/checker).
+
+Le Hub lui-même possède les portails suivants :
+
+- **Intégration de l'opérateur du Hub :**<br>
+Actuellement, il n'existe pas de solution intégrée de gestion des identités et des accès (IAM) pour les opérateurs du Hub, bien que la fonction soit partiellement remplie par l'utilisation de WSO2. Des travaux de développement sont en cours pour développer une solution IAM complète basée sur Ory et Keycloak. Cela verra un opérateur administrateur créé parallèlement au déploiement du Hub, ce qui constitue une première étape fondamentale dans ce domaine.
+- **Portail Financier :** <br>
+Il a deux fonctions principales : la gestion des opérations de règlement, et la gestion de la position de liquidité des DFSP individuels (et en relation avec cela, leur valeur de plafond de débit net (NDC)).
+L'accès au portail financier est actuellement limité à une simple fonction de contrôle d'accès par nom d'utilisateur/mot de passe.
+- **Cycle de vie des participants :** <br>
+Contrôle et configuration de l'accès au Hub par les DFSP.
+D'un point de vue technique, cela est actuellement réalisé par l'utilisation du Mojaloop Connection Manager (MCM). Cependant, il est prévu que le MCM lui-même sera développé pour présenter une API, qui pourra être utilisée pour développer une interface utilisateur disponible pour les opérateurs du Hub et pour les DFSP.
+- **Opérations du Hub :** <br>
+Celles-ci comprennent les recherches de transactions, la surveillance de l'état et des performances, les tableaux de bord et l'ensemble des opérations techniques.
+Actuellement, celles-ci sont réalisées grâce à l'utilisation de Prometheus/Grafana et d'une gamme d'autres outils, avec un contrôle d'accès standard intégré dans ces outils eux-mêmes. Il est prévu que cela sera migré vers la solution Ory/Keycloak, au fur et à mesure de son développement.
+
+D'autres opérations du Hub, telles que la gestion de la fraude et la gestion des cas/litiges, sont des modules complémentaires qui implémentent leur propre contrôle d'accès pour gérer l'accès à leurs fonctions sensibles. Ceux-ci ne sont pas abordés dans ce document.
+
+En plus des mesures de contrôle d'accès ci-dessus, il convient de noter que l'accès à toutes ces fonctions n'est possible que via un VPN, avec des identifiants individuels contrôlant l'accès.
+
+En plus de ces portails, il existe deux autres moyens principaux d'accéder au Hub, dont aucun n'est soumis au RBAC :
+
+- Le premier concerne les transactions, qui sont strictement contrôlées selon leurs propres mesures de cybersécurité multicouches.
+- Et deuxièmement, les paiements en masse (gouvernement vers personne - G2P), qui sont pris en charge au moyen d'une API soumise aux mêmes contrôles que les autres transactions individuelles. Il est prévu que les paiements en masse seront un service fourni aux DFSP (et à leurs clients) au moyen d'une API sécurisée, le DFSP exploitant un portail de paiements en masse pour l'utilisation par ses clients. Il est possible que l'opérateur d'une instance du Hub Mojaloop puisse mettre à disposition un portail de paiements en masse en marque blanche, qui s'interface avec l'API de paiements en masse du Hub, pour personnalisation par tout DFSP souhaitant offrir le service à ses clients. (Notez que cette approche n'est pas unique : une approche similaire a été proposée, par exemple, pour les paiements marchands, avec une application en marque blanche pour les transactions par code QR mise à disposition des DFSP pour intégration dans leurs portefeuilles mobiles.)
+
+Les contrôles d'accès autour des paiements individuels ou en masse ne sont donc pas abordés davantage dans ce document.
+
+### Payment Manager pour l'intégration
+
+Payment Manager est actuellement l'un des principaux mécanismes d'intégration des DFSP à un Hub Mojaloop. Alors que le Hub est unique dans un schéma, il existe une instance distincte de Payment Manager pour chaque DFSP. Les portails offerts par Payment Manager doivent donc être sécurisés au moyen du RBAC pour limiter l'accès aux représentants autorisés du DFSP.
+
+Dans l'environnement Payment Manager, le RBAC est implémenté uniquement via Keycloak.
+
+Les portails suivants sont disponibles :
+
+- **Intégration utilisateur/opérateur :**
+Payment Manager inclut Keycloak pour l'IAM. Lors du déploiement, un utilisateur administrateur unique est créé, qui peut être utilisé pour créer d'autres comptes utilisateurs.
+- **Gestion de la connexion au Hub :**
+Cela inclut la possibilité de configurer la connexion au Hub du côté Payment Manager, et par implication de la désactiver. C'est donc une fonction contrôlée, avec des contrôles différents pour la visualisation par rapport à la modification.
+- **Investigation des transactions :**
+Il est possible d'investiguer les requêtes de transactions en utilisant le portail Payment Manager. Cela est potentiellement problématique si des informations personnellement identifiables (PII) sont disponibles via le portail.
+
+### Comptes fondamentaux
+
+Au moment où un Hub est mis en place pour la première fois, Ory/Keycloak sera utilisé pour créer un compte utilisateur fondamental avec des privilèges d'administrateur. Un administrateur système se verra attribuer ce compte. Notez que l'administrateur système ne se verra attribuer aucun rôle opérationnel au-delà de ceux d'un administrateur système.
+
+Toutes les fonctions exécutées à l'aide d'Ory/Keycloak sont soumises à une journalisation au niveau du système à des fins d'audit.
+
+L'administrateur système utilisera ensuite Ory/Keycloak pour créer d'autres comptes utilisateurs, sous réserve de vérifications d'identité et de contrôles d'antécédents standard pour chaque individu (définis dans les règles du schéma associées à un déploiement Mojaloop particulier) avant que leurs comptes ne soient créés.
+
+Ces nouveaux comptes utilisateurs se verront attribuer l'un de ces rôles :
+
+- OPERATOR
+- MANAGER
+
+Un compte utilisateur ne peut pas avoir à la fois les rôles OPERATOR et MANAGER.
+
+### Comptes supplémentaires
+
+En plus de l'administrateur système, les comptes fondamentaux auront la possibilité d'utiliser Ory/Keycloak pour ajouter d'autres comptes. Cependant, pour ces utilisateurs, cette activité sera soumise à des contrôles maker/checker. Un utilisateur avec le rôle OPERATOR pourra créer un compte utilisateur (avec des processus en place pour garantir que la diligence raisonnable en matière de vérification d'identité et de contrôle des antécédents a été effectuée). Cependant, ce compte ne sera pas activé tant qu'une personne avec le rôle MANAGER ne l'aura pas approuvé.
+
+Un rôle sera attribué à chacun de ces comptes lors de leur création. En plus des rôles associés aux comptes fondamentaux, les rôles suivants peuvent être attribués aux nouveaux comptes utilisateurs :
+
+- ADMINISTRATOR
+- FINANCE_MANAGER
+
+Un compte utilisateur ne peut pas avoir plus d'un des rôles OPERATOR, MANAGER, ADMINISTRATOR ou FINANCE_MANAGER, afin d'assurer la séparation de :
+
+- La gestion financière des autres tâches d'exploitation du Hub
+- Les rôles d'opérateur et de gestionnaire dans les fonctions maker/checker
+
+::: tip NOTE
+L'attribution des rôles ADMINISTRATOR ou FINANCE_MANAGER est soumise à un degré plus élevé de vérification d'identité et de contrôle des antécédents que tout autre rôle, en raison de la nature sensible des fonctions associées. Ces vérifications supplémentaires sont définies dans les règles du schéma.
+:::
+
+### Portail Financier / Cadre opérationnel métier
+
+De nombreuses fonctions (telles que la visualisation des positions des DFSP, l'état des fenêtres de règlement, etc.) du portail financier sont disponibles pour tous les utilisateurs connectés, quel que soit leur rôle. Cependant, les fonctions suivantes ne peuvent être exécutées que par des utilisateurs ayant des rôles spécifiques :
+
+- Traitement des règlements
+  - Fermer la fenêtre de règlement
+  - Initier le règlement
+- Gestion de la liquidité DFSP
+  - Ajouter/retirer des fonds
+  - Modifier le NDC
+
+Toutes ces fonctions sont soumises à des contrôles maker/checker, de sorte qu'un utilisateur avec le rôle ADMINISTRATOR peut initier l'action, mais elle doit être approuvée par un utilisateur avec le rôle FINANCE_MANAGER.
+
+### Cycle de vie des participants
+
+Ce portail fournit une interface unique pour qu'un opérateur du Hub ajoute et maintienne les DFSP sur les écosystèmes du Hub.
+
+Il existe certaines fonctions standardisées qui sont soumises au RBAC :
+
+- Créer un DFSP
+- Créer des comptes DFSP
+- Suspendre un DFSP
+
+Chacune de ces fonctions est soumise à des contrôles maker/checker, de sorte qu'un utilisateur avec le rôle OPERATOR peut mettre en place les modifications, et elles doivent être approuvées par un utilisateur avec le rôle MANAGER.
+
+De plus, il y a une charge de travail importante dans l'intégration technique d'un DFSP, en particulier autour de l'établissement de l'environnement technique d'exploitation (certificats, etc.). Cela n'est pas soumis au RBAC. Cela n'est pas considéré comme un risque significatif, car il n'y a pas de valeur sans pouvoir créer un DFSP et les comptes associés sur le Hub lui-même - activités qui sont soumises au RBAC.
+
+### Opérations du Hub
+
+L'accès aux fonctions de reporting de Prometheus/Grafana n'est pas soumis aux contrôles RBAC - tout utilisateur connecté/authentifié, avec n'importe quel rôle RBAC attribué, peut consulter les rapports et les tableaux de bord.
+
+La création d'un nouveau rapport/tableau de bord est une fonction restreinte, et n'est disponible que pour les utilisateurs ayant le rôle MANAGER.
+
+Comme indiqué précédemment, les portails d'opérations et de reporting seront migrés vers l'environnement Ory/Keycloak afin de faciliter ces contrôles.
+
+### Payment Manager
+
+La fonctionnalité opérateur de Payment Manager est soumise aux contrôles RBAC, mais le maker/checker n'est pas requis.
+
+#### Intégration utilisateur/opérateur
+
+Lors du déploiement de Payment Manager, un seul compte utilisateur administrateur est créé à l'aide de Keycloak. Notez que l'utilisateur administrateur ne se verra attribuer aucun rôle opérationnel au-delà de ceux d'un administrateur système.
+
+Toutes les fonctions exécutées à l'aide de Keycloak sont soumises à une journalisation au niveau du système à des fins d'audit.
+
+L'utilisateur administrateur utilisera Keycloak pour créer d'autres comptes utilisateurs, sous réserve de vérifications d'identité et de contrôles d'antécédents standard pour chaque individu (définis dans les règles du schéma associées à un déploiement Mojaloop particulier) avant que leurs comptes ne soient créés.
+
+Ces nouveaux comptes utilisateurs se verront attribuer l'un des rôles suivants :
+
+- OPERATOR
+- MANAGER
+
+Un compte utilisateur ne peut pas avoir à la fois les rôles OPERATOR et MANAGER.
+
+### Tableaux de bord
+
+Les tableaux de bord de Payment Manager sont disponibles pour tout utilisateur connecté/authentifié ayant le rôle OPERATOR ou MANAGER.
+
+### Gestion de la connexion au Hub
+
+La visualisation des paramètres de la connexion Payment Manager/Hub est disponible pour tout utilisateur connecté/authentifié ayant le rôle OPERATOR ou MANAGER. Cependant, la modification des paramètres est une fonction contrôlée. Seul un utilisateur ayant le rôle MANAGER peut modifier les paramètres.
+
+### Investigation des transactions
+
+La réalisation d'investigations de transactions à l'aide des fonctionnalités du portail Payment Manager est une activité contrôlée, en raison du potentiel de révélation de données PII. Elle n'est donc disponible que pour les utilisateurs connectés/authentifiés ayant le rôle MANAGER.
+
+## Surveillance
+La surveillance est le quatrième pilier de l'atténuation du risque RBAC. Sa conception et sa configuration dépendent fortement de la maturité du schéma, des règles du schéma, des cas d'utilisation employés et des classes de participants.
+Comme point de départ pour concevoir votre surveillance, considérez ces catégories :
+1. Surveillance des menaces de sécurité externes
+1. Surveillance des menaces de sécurité internes, par ex. l'audit
+1. Surveillance de l'application des règles du schéma
diff --git a/docs/fr/adoption/HubOperations/Settlement/ledgers-in-the-hub.md b/docs/fr/adoption/HubOperations/Settlement/ledgers-in-the-hub.md
new file mode 100644
index 00000000..4995a592
--- /dev/null
+++ b/docs/fr/adoption/HubOperations/Settlement/ledgers-in-the-hub.md
@@ -0,0 +1,367 @@
+# Grands livres dans le Hub
+
+## Gestion du risque
+
+Certains éléments du processus de règlement échappent au contrôle du Hub ; il importe donc qu’un ensemble de contrôles soit en place pour éviter la disparition de fonds et garantir qu’il y ait toujours suffisamment de liquidité pour l’exploitation du Hub. Outre le [Net Debit Cap](settlement-basic-concepts.md#liquidity-management-net-debit-cap), le Hub utilise plusieurs grands livres internes pour gérer le risque et assurer la liquidité. Ces grands livres sont les suivants :
+
+<table>
+<colgroup>
+<col style="width: 33%" />
+<col style="width: 33%" />
+<col style="width: 33%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Grand livre</th>
+<th>Définition</th>
+<th>Type de transfert enregistré dans le grand livre</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>DFSP Position Ledger</p></td>
+<td><p>Suit combien un DFSP doit ou a droit de recevoir. Chaque fois qu’un transfert est traité, la Position dans le Hub est ajustée en temps réel.</p></td>
+<td><p>Transfert P2P : transaction de personne à personne entre utilisateurs finaux de DFSP.<br />
+<br />
+Transfert de règlement : flux de fonds entre DFSP visant à rapprocher les grands livres et à mettre à jour les Positions pour une fenêtre de règlement donnée.</p></td>
+</tr>
+<tr class="even">
+<td><p>DFSP Settlement Ledger</p></td>
+<td><p>Compte de liquidité du DFSP tenu à la banque de règlement, reflété dans le Hub. Sert de compte de rapprochement et reflète les mouvements de fonds réels.</p></td>
+<td><p>Transfert de fonds (entrant et sortant) : mouvement de fonds initié par le DFSP ou confirmation par la banque de règlement que le règlement est terminé.</p></td>
+</tr>
+<tr class="odd">
+<td><p>Hub Multilateral Net Settlement (HMLNS) Ledger</p></td>
+<td><p>Sert à enregistrer l’écriture d’équilibre pour le règlement net entre les DFSP. Après qu’une fenêtre de règlement a été fermée et réglée entre tous les DFSP, son solde revient à zéro.</p></td>
+<td><p>Transfert de règlement : flux de fonds entre DFSP visant à rapprocher les grands livres et à mettre à jour les Positions pour une fenêtre de règlement donnée.</p></td>
+</tr>
+<tr class="even">
+<td><p>Hub Reconciliation Ledger</p></td>
+<td><p>Garantit que les mouvements entrants et sortants des comptes de liquidité enregistrés dans les grands livres de règlement (Settlement Ledgers) s’équilibrent. Le solde correspond au montant que l’opérateur du Hub administre dans l’ensemble des grands livres de règlement des DFSP participants.<br />
+<br />
+Fait office de compte de contrôle et suit les mouvements de fonds sur l’ensemble des DFSP Settlement Ledgers (qui reflètent les mouvements de fonds réels).</p></td>
+<td><p>Transfert de fonds (entrant et sortant) : mouvement de fonds initié par le DFSP ou confirmation par la banque de règlement que le règlement est terminé.</p></td>
+</tr>
+</tbody>
+</table>
+
+## Principes comptables
+
+En comptabilité, une position nette positive (davantage de débits) est traitée comme un actif, tandis qu’une position nette négative (davantage de crédits) est traitée comme un passif. Le Hub Mojaloop applique ces mêmes principes, mais du point de vue du Hub. Qu’est-ce que cela signifie ?
+
+Un transfert est enregistré par le Hub comme un débit (DR) du côté du DFSP payeur, car le transfert réduit le montant qui doit être reversé à ce DFSP (passif réduit du point de vue du Hub). Ainsi, alors que le DFSP payeur lui-même traitera le transfert comme une augmentation de son passif dans son propre système, le Hub le traite comme une augmentation de son actif.
+
+Le même transfert est enregistré par le Hub comme un crédit (CR) du côté du DFSP bénéficiaire, car le transfert augmente le montant dû à ce DFSP (passif accru du point de vue du Hub).
+
+Enregistrer une transaction sur deux comptes sous forme d’écritures de débit et de crédit opposées (de montants égaux) correspond à ce qu’on appelle en comptabilité la « partie double ».
+
+En appliquant ces principes comptables à un dépôt effectué par un DFSP sur son compte de liquidité, le montant crée un passif du point de vue du Hub (l’argent doit être remboursé). Le montant saisi dans le Hub est donc négatif. Ainsi, à tout moment, le montant que le Hub doit à un DFSP peut être calculé rapidement en additionnant la Position du DFSP au solde de son compte de liquidité. L’écriture en partie double pour le DFSP Settlement Ledger est ajoutée au Hub Reconciliation Ledger.
+
+## Règlement : un exemple
+
+Cette section montre comment une transaction est enregistrée dans les différents grands livres, à l’aide d’un exemple simple.
+
+Prenons l’exemple suivant : DFSP1 envoie 50 USD à DFSP2. Voici comment cette transaction d’exemple est enregistrée dans les grands livres du Hub.
+
+### Étape 1a : Réserver le montant du transfert pour l’émetteur dans le grand livre de Position
+
+Le DFSP Position Ledger sert à suivre les variations de la Position d’un DFSP. Une fois qu’une fenêtre de règlement est fermée et que le processus de règlement est lancé, le montant du transfert est réservé dans les grands livres de Position du Hub tenus pour les DFSP ainsi que dans le Hub Multilateral Net Settlement Ledger. Réserver le montant du transfert pour le DFSP payeur (DFSP1) garantit que les fonds ne peuvent pas être utilisés pour un autre transfert.
+
+<table>
+<colgroup>
+<col style="width: 25%" />
+<col style="width: 25%" />
+<col style="width: 25%" />
+<col style="width: 25%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th colspan="2"><strong>DFSP1 Position Ledger</strong></th>
+<th colspan="2"><strong>Hub Multilateral Net Settlement Ledger</strong></th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p><strong>DR</strong></p></td>
+<td><p><strong>CR</strong></p></td>
+<td><p><strong>DR</strong></p></td>
+<td><p><strong>CR</strong></p></td>
+</tr>
+<tr class="even">
+<td><p>50 USD</p></td>
+<td></td>
+<td></td>
+<td><p>50 USD</p></td>
+</tr>
+</tbody>
+</table>
+
+### Étape 1b : Réserver le montant du transfert pour le bénéficiaire dans le grand livre de Position
+
+De même, la Position du DFSP bénéficiaire est suivie via le DFSP Position Ledger du DFSP.
+
+<table>
+<colgroup>
+<col style="width: 25%" />
+<col style="width: 25%" />
+<col style="width: 25%" />
+<col style="width: 25%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th colspan="2"><strong>DFSP2 Position Ledger</strong></th>
+<th colspan="2"><strong>Hub Multilateral Net Settlement Ledger</strong></th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p><strong>DR</strong></p></td>
+<td><p><strong>CR</strong></p></td>
+<td><p><strong>DR</strong></p></td>
+<td><p><strong>CR</strong></p></td>
+</tr>
+<tr class="even">
+<td></td>
+<td><p>50 USD</p></td>
+<td><p>50 USD</p></td>
+<td></td>
+</tr>
+</tbody>
+</table>
+
+### Étape 2a : Comptabiliser le montant du transfert pour l’émetteur dans le grand livre de Position
+
+Après la réservation du montant du transfert, l’étape suivante consiste à comptabiliser le montant dans les mêmes grands livres qu’auparavant.
+
+<table>
+<colgroup>
+<col style="width: 25%" />
+<col style="width: 25%" />
+<col style="width: 25%" />
+<col style="width: 25%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th colspan="2"><strong>DFSP1 Position Ledger</strong></th>
+<th colspan="2"><strong>Hub Multilateral Net Settlement Ledger</strong></th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p><strong>DR</strong></p></td>
+<td><p><strong>CR</strong></p></td>
+<td><p><strong>DR</strong></p></td>
+<td><p><strong>CR</strong></p></td>
+</tr>
+<tr class="even">
+<td><p>50 USD</p></td>
+<td></td>
+<td></td>
+<td><p>50 USD</p></td>
+</tr>
+</tbody>
+</table>
+
+### Étape 2b : Comptabiliser le montant du transfert pour le bénéficiaire dans le grand livre de Position
+
+La comptabilisation du montant du transfert pour le DFSP bénéficiaire (DFSP2) permet au DFSP d’envoyer des fonds vers d’autres DFSP s’il le souhaite.
+
+<table>
+<colgroup>
+<col style="width: 25%" />
+<col style="width: 25%" />
+<col style="width: 25%" />
+<col style="width: 25%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th colspan="2"><strong>DFSP2 Position Ledger</strong></th>
+<th colspan="2"><strong>Hub Multilateral Net Settlement Ledger</strong></th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p><strong>DR</strong></p></td>
+<td><p><strong>CR</strong></p></td>
+<td><p><strong>DR</strong></p></td>
+<td><p><strong>CR</strong></p></td>
+</tr>
+<tr class="even">
+<td></td>
+<td><p>50 USD</p></td>
+<td><p>50 USD</p></td>
+<td></td>
+</tr>
+</tbody>
+</table>
+
+### Étape 3 : Réserver le montant du transfert pour l’émetteur dans le grand livre de règlement
+
+Une fois que les Positions sont dans un état contrôlé et que les écritures de débit et de crédit correspondantes ont été enregistrées dans le Hub Multilateral Net Settlement Ledger, la transaction doit aussi être enregistrée et réservée dans les DFSP Settlement Ledgers et le Hub Reconciliation Ledger afin de garantir que des fonds ne sont pas libérés par inadvertance pour une autre opération de sortie de fonds (Funds-Out).
+
+<table>
+<colgroup>
+<col style="width: 25%" />
+<col style="width: 25%" />
+<col style="width: 25%" />
+<col style="width: 25%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th colspan="2"><strong>DFSP1 Settlement Ledger</strong></th>
+<th colspan="2"><strong>Hub Reconciliation Ledger</strong></th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p><strong>DR</strong></p></td>
+<td><p><strong>CR</strong></p></td>
+<td><p><strong>DR</strong></p></td>
+<td><p><strong>CR</strong></p></td>
+</tr>
+<tr class="even">
+<td><p>50 USD</p></td>
+<td></td>
+<td></td>
+<td><p>50 USD</p></td>
+</tr>
+</tbody>
+</table>
+
+### Étape 4a : Comptabiliser le montant du transfert pour le bénéficiaire dans le grand livre de règlement
+
+Une fois que l’argent réel a bougé sur les comptes de liquidité des DFSP, les montants de transfert peuvent être comptabilisés dans les DFSP Settlement Ledgers et le Hub Reconciliation Ledger. Le mouvement de fonds est d’abord enregistré pour le DFSP bénéficiaire.
+
+<table>
+<colgroup>
+<col style="width: 25%" />
+<col style="width: 25%" />
+<col style="width: 25%" />
+<col style="width: 25%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th colspan="2"><strong>DFSP2 Settlement Ledger</strong></th>
+<th colspan="2"><strong>Hub Reconciliation Ledger</strong></th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p><strong>DR</strong></p></td>
+<td><p><strong>CR</strong></p></td>
+<td><p><strong>DR</strong></p></td>
+<td><p><strong>CR</strong></p></td>
+</tr>
+<tr class="even">
+<td></td>
+<td><p>50 USD</p></td>
+<td><p>50 USD</p></td>
+<td></td>
+</tr>
+</tbody>
+</table>
+
+### Étape 4b : Comptabiliser le montant du transfert pour l’émetteur dans le grand livre de règlement
+
+Enfin, le montant du transfert est aussi comptabilisé côté émetteur.
+
+<table>
+<colgroup>
+<col style="width: 25%" />
+<col style="width: 25%" />
+<col style="width: 25%" />
+<col style="width: 25%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th colspan="2"><strong>DFSP1 Settlement Ledger</strong></th>
+<th colspan="2"><strong>Hub Reconciliation Ledger</strong></th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p><strong>DR</strong></p></td>
+<td><p><strong>CR</strong></p></td>
+<td><p><strong>DR</strong></p></td>
+<td><p><strong>CR</strong></p></td>
+</tr>
+<tr class="even">
+<td><p>50 USD</p></td>
+<td></td>
+<td></td>
+<td><p>50 USD</p></td>
+</tr>
+</tbody>
+</table>
+
+## Ajouter ou retirer des fonds : un exemple
+
+### Ajout de fonds
+
+Les soldes des comptes de liquidité fluctuant, les DFSP ajoutent des fonds pour financer leurs envois nets ou procèdent à des retraits. Les dépôts peuvent intervenir à tout moment, mais le Hub Reconciliation Ledger doit être mis à jour régulièrement pour éviter des problèmes de rapprochement. Chaque fois qu’une modification est apportée au compte externe (c’est-à-dire au compte de liquidité du DFSP), le Net Debit Cap doit aussi être réévalué.
+
+Dans l’exemple suivant, DFSP1 ajoute 100 000 USD à son compte de liquidité. Voici comment le montant du dépôt est enregistré dans les grands livres du Hub.
+
+<table>
+<colgroup>
+<col style="width: 25%" />
+<col style="width: 25%" />
+<col style="width: 25%" />
+<col style="width: 25%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th colspan="2"><strong>DFSP1 Settlement Ledger</strong></th>
+<th colspan="2"><strong>Hub Reconciliation Ledger</strong></th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p><strong>DR</strong></p></td>
+<td><p><strong>CR</strong></p></td>
+<td><p><strong>DR</strong></p></td>
+<td><p><strong>CR</strong></p></td>
+</tr>
+<tr class="even">
+<td></td>
+<td><p>100,000 USD</p></td>
+<td><p>100,000 USD</p></td>
+<td></td>
+</tr>
+</tbody>
+</table>
+
+### Retrait de fonds
+
+Un retrait pouvant avoir une incidence sur le Net Debit Cap et sur la capacité à opérer, le NDC doit être recalculé au regard du nouveau solde du DFSP (le solde ne doit jamais être inférieur au NDC).
+
+Dans l’exemple suivant, DFSP2 retire 100 000 USD de son compte de liquidité. Voici comment le montant du retrait est enregistré dans les grands livres du Hub.
+
+<table>
+<colgroup>
+<col style="width: 25%" />
+<col style="width: 25%" />
+<col style="width: 25%" />
+<col style="width: 25%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th colspan="2"><strong>DFSP2 Settlement Ledger</strong></th>
+<th colspan="2"><strong>Hub Reconciliation Ledger</strong></th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p><strong>DR</strong></p></td>
+<td><p><strong>CR</strong></p></td>
+<td><p><strong>DR</strong></p></td>
+<td><p><strong>CR</strong></p></td>
+</tr>
+<tr class="even">
+<td><p>100,000 USD</p></td>
+<td></td>
+<td></td>
+<td><p>100,000 USD</p></td>
+</tr>
+</tbody>
+</table>
diff --git a/docs/fr/adoption/HubOperations/Settlement/settlement-basic-concepts.md b/docs/fr/adoption/HubOperations/Settlement/settlement-basic-concepts.md
new file mode 100644
index 00000000..61ef157b
--- /dev/null
+++ b/docs/fr/adoption/HubOperations/Settlement/settlement-basic-concepts.md
@@ -0,0 +1,129 @@
+# Concepts de base
+
+Cette section regroupe les concepts et éléments clés du processus de gestion des règlements.
+
+## Couverture de liquidité
+
+Comme décrit dans l’[Introduction](settlement-management-introduction.md), l’une des caractéristiques d’un système de paiements en temps réel est que les DFSP créanciers doivent débourser des fonds à leurs clients avant d’être remboursés par le DFSP débiteur. Pour atténuer le risque qu’un DFSP créancier ne reçoive pas les fonds qui lui sont dus, Mojaloop exige que les DFSP débiteurs fournissent une preuve crédible qu’ils disposent de fonds réels suffisants pour honorer les obligations qu’ils contractent du fait des opérations dans le système.
+
+Cette preuve crédible est appelée *couverture de liquidité*. Le système Mojaloop ne prescrit pas la forme qu’elle doit prendre ; pour un DFSP donné, elle peut prendre plusieurs formes. Il peut s’agir par exemple :
+
+- de fonds déposés sur un compte sur lequel le Hub Mojaloop exerce un certain contrôle
+- d’une ligne de crédit accordée par un autre établissement financier
+- d’une autre forme de garantie
+
+Toute couverture de liquidité utilisée dans un schéma Mojaloop doit toutefois présenter les caractéristiques suivantes :
+
+- Elle doit pouvoir être convertie en paiements de règlement *immédiatement* sur demande du schéma Mojaloop.
+- Elle doit être attestée par des preuves fiables dont dispose le schéma Mojaloop.
+- Elle ne doit pas pouvoir être convertie par le DFSP sous d’autres formes (par exemple en retirant des fonds d’un compte bancaire ou en tirant sur une ligne de crédit) sans que le schéma Mojaloop en ait été informé au préalable et l’ait approuvé.
+
+La couverture de liquidité attribuée à un DFSP donné est une couverture de liquidité pour un modèle de règlement et une devise donnés, et elle est attribuée au schéma dans son ensemble. Autrement dit, Mojaloop n’autorise pas les participants à détenir une couverture de liquidité qui ne s’appliquerait qu’à leurs transferts avec un ou certains DFSP spécifiques.
+
+Lorsqu’un DFSP demande au Hub Mojaloop d’effectuer un transfert, le Hub Mojaloop vérifie que le DFSP débiteur dispose d’une couverture de liquidité suffisante pour garantir que le transfert pourra être réglé s’il se termine avec succès. Il le fait en comparant le total des fonds réels du DFSP à la somme des éléments suivants :
+
+1. La somme des transferts qui ont été complétés mais pas encore réglés, et pour lesquels le DFSP est *soit* le créancier *soit* le débiteur.
+1. La somme des transferts qui ont été initiés mais ne sont pas encore terminés, et pour lesquels le DFSP est le débiteur.
+1. Le montant du transfert proposé.
+
+Si le total de ces trois éléments est supérieur au montant des fonds réels disponibles pour le DFSP débiteur, le transfert sera rejeté par le Hub Mojaloop. Notez que, dans cette configuration, la liquidité d’un DFSP est créditée de l’effet des transferts dont il est le bénéficiaire dès que le transfert est complété, sans attendre le règlement des fonds. Mojaloop agit ainsi pour réduire au minimum le montant de liquidité que les participants doivent détenir.
+
+## Modèle de règlement
+
+Les schémas souhaitent régler les fonds entre leurs participants de différentes manières. Cela dépend de qui exploite le schéma, du volume de trafic dans le schéma et de nombreux autres paramètres.
+
+Mojaloop est conçu pour prendre en charge les modes de règlement entre participants conformes aux usages du secteur. Ils sont les suivants :
+
+- Règlement net différé multilatéral
+- Règlement net différé bilatéral
+- Règlement brut immédiat
+
+La signification des termes composant ces types de règlement est la suivante.
+
+Les règlements sont *nets différés* si plusieurs transferts sont réglés ensemble. Les règlements nets (dans lesquels plusieurs transferts sont réglés ensemble) sont par définition différés (puisqu’il faut du temps pour constituer un lot).
+
+Les règlements sont *bruts* si chaque transfert est réglé séparément. Les règlements bruts peuvent être immédiats ou différés. Ils sont *différés* si une approbation extérieure au Hub est requise pour le règlement, et *immédiats* si le Hub peut procéder au règlement d’un transfert sans approbation externe. À ce jour, Mojaloop ne prend en charge que les règlements bruts immédiats.
+
+Les règlements sont *bilatéraux* si chaque paire de participants se règle entre elle pour le net de tous les transferts entre eux. Les règlements sont *multilatéraux* si chaque participant se règle avec le Hub pour le net de tous les transferts auxquels il a participé, quelle que soit l’autre partie.
+
+Un modèle de règlement définit la manière dont un Hub Mojaloop règlera un ensemble de transferts. Dans le cas simple, il n’y a qu’un seul modèle de règlement et il règle tous les transferts traités par le Hub. Mojaloop prend toutefois en charge plus d’un modèle de règlement pour un même schéma. Cela permet, par exemple, à un schéma de définir des modèles de règlement différents selon les devises ou les types de comptes du grand livre.
+
+Si un schéma définit plus d’un modèle de règlement, il incombe au schéma de veiller à ce qu’un transfert donné ne puisse relever que d’un seul modèle de règlement. Par exemple, supposons qu’un schéma définisse un modèle de règlement pour tous les transferts nécessitant une conversion de devise (définis comme : tous les transferts dont la devise source et la devise cible diffèrent), et un autre modèle pour tous les transferts dont la devise source est le shilling kényan (KES). Dans ce cas, un transfert convertissant des shillings kényans en rand sud-africain pourrait relever des deux modèles.
+
+## Fenêtre de règlement
+
+Chaque transfert complété dans le Hub est affecté à la fenêtre de règlement actuellement ouverte. La fenêtre de règlement sert à regrouper des transferts. L’affectation des transferts à une fenêtre de règlement est indépendante des modèles de règlement utilisés pour régler ces transferts. Ainsi, si un schéma a défini plus d’un modèle de règlement, les transferts relevant de modèles différents partageront une même fenêtre de règlement.
+
+Il n’existe pas de méthode déterministe pour affecter les transferts à une fenêtre de règlement donnée. Lorsqu’un administrateur du schéma crée une nouvelle fenêtre de règlement, on ne peut pas savoir à l’avance quels transferts seront affectés à la nouvelle fenêtre et lesquels resteront dans l’ancienne.
+
+Une fenêtre de règlement peut présenter les états suivants :
+
+* `OPEN` : la fenêtre de règlement est ouverte ; les transferts sont acceptés dans la fenêtre ouverte en cours.
+* `CLOSED` : la fenêtre de règlement est fermée ; elle n’accepte plus de transferts supplémentaires et tous les nouveaux transferts sont affectés à une nouvelle fenêtre de règlement ouverte.
+* `PENDING_SETTLEMENT` : la fenêtre de règlement est fermée, les [positions nettes de règlement multilatéral](#multilateral-net-settlement-position) ont été calculées pour chaque DFSP mais le règlement avec la banque de règlement partenaire n’a pas encore eu lieu.
+* `SETTLED` : la banque de règlement a confirmé que tous les DFSP participants ayant effectué des transferts dans la fenêtre de règlement ont réglé leurs paiements, et l’opérateur du Hub a soldé la fenêtre.
+
+La fermeture d’une fenêtre de règlement ouvre automatiquement la suivante.
+
+### Règlements et fenêtres de règlement
+
+Un administrateur du Hub peut demander des règlements pour un modèle de règlement donné et pour une ou plusieurs fenêtres de règlement.
+
+Si un schéma n’a qu’un seul modèle de règlement, le règlement des transferts pour ce modèle dans une fenêtre de règlement donnée règle tous les transferts de cette fenêtre. En revanche, si un schéma a défini plus d’un modèle de règlement, le règlement des transferts relevant d’un modèle de règlement particulier pour une fenêtre donnée signifie que certains transferts de cette fenêtre ont été réglés et d’autres pas.
+
+Il est particulièrement important de comprendre les implications lorsqu’un modèle de règlement brut immédiat a été défini. Dans ce cas, les transferts individuels sont réglés dès qu’ils sont complétés. Si le schéma n’a qu’un modèle de règlement brut immédiat, tous les transferts sont réglés à leur complétion et la fenêtre de règlement devient sans objet. En revanche, si le schéma combine des modèles brut et net, ou s’il a défini plus d’un modèle net, une fenêtre de règlement donnée peut contenir à la fois des transferts réglés et des transferts non réglés ; et, pour les transferts réglés par un modèle brut, des transferts déjà réglés peuvent apparaître même dans une fenêtre de règlement encore ouverte. Cela complique la définition du statut global d’une fenêtre de règlement.
+
+Mojaloop gère cette situation en attribuant toujours à la fenêtre de règlement un état qui est l’*état minimal* des transferts qu’elle contient. L’*état minimal* est défini par la séquence des états de fenêtre de règlement indiquée ci-dessus. Ainsi, par exemple, si une fenêtre de règlement contient des transferts déjà réglés (parce qu’ils sont réglés en brut) et d’autres transferts dont le processus de règlement n’a pas encore commencé, l’état de la fenêtre de règlement sera `OPEN`. Si une fenêtre de règlement a été fermée et qu’elle contient des transferts relevant de deux modèles de règlement différents, dont l’un est en cours de règlement (état `PENDING_SETTLEMENT`) et l’autre pas (état `CLOSED`), l’état global de la fenêtre de règlement sera `CLOSED`.
+
+## Gestion de la liquidité (Net Debit Cap)
+
+Comme indiqué ci-dessus, Mojaloop exige que les participants préfinancent les transferts lorsqu’ils sont la partie débitrice en fournissant au Hub Mojaloop une preuve crédible qu’ils peuvent honorer l’ensemble de leurs besoins de règlement actuels. Il peut toutefois exister des situations où un participant ne souhaite pas que l’intégralité de sa couverture de liquidité serve de garantie aux transferts. Par exemple, un participant peut être bénéficiaire dans un canal de rémittances et donc créancier net au global ; ou un participant peut déposer des fonds supplémentaires pour couvrir les périodes où ses comptes ne sont pas ouverts pour recevoir des fonds.
+
+Pour couvrir ces cas, Mojaloop permet aux participants ou aux administrateurs du Hub de réserver une partie de leur couverture de liquidité disponible, de sorte que seule une partie puisse servir de couverture de liquidité pour les transferts. Cela s’appelle le Net Debit Cap (NDC). Le NDC agit comme une limite ou un plafond posé sur les fonds d’un DFSP disponibles pour les opérations ; il ne peut jamais dépasser le solde du compte de liquidité. Cela est nécessaire pour garantir que les passifs d’un DFSP peuvent être couverts avec des fonds immédiatement disponibles auprès de la banque de règlement.
+
+Lorsqu’il calcule si un transfert est couvert par la liquidité disponible, le Hub tient compte de toute restriction du montant de fonds disponibles fixée par le Net Debit Cap.
+
+## Position
+
+La Position d’un DFSP reflète l’ensemble des obligations non réglées de ce DFSP pour un modèle de règlement donné à un instant donné : autrement dit, le montant des fonds qu’un DFSP devra éventuellement régler avec le schéma. La Position d’un DFSP pour un modèle de règlement donné est le net des éléments suivants :
+
+1. Tous les transferts complétés mais non réglés qui relèvent du modèle de règlement et pour lesquels le DFSP est le débiteur.
+2. Tous les transferts complétés mais non réglés qui relèvent du modèle de règlement et pour lesquels le DFSP est le créancier.
+3. Tous les transferts demandés mais pas encore complétés qui relèvent du modèle de règlement et pour lesquels le DFSP est le débiteur.
+
+Pour le DFSP payeur, ce total inclut les montants de transfert en attente et pas encore complétés. Notez qu’en cas d’abandon ou de délai d’attente dépassé, les transferts concernés ne se complètent pas et la réservation pour ce transfert est levée.
+
+La Position est la position totale sur l’ensemble des fenêtres de règlement qui n’ont pas encore été réglées. Le montant de la position d’un participant ne change que lorsque certains des transferts qui la composent sont réglés.
+
+## Positions nettes de règlement
+
+Comme indiqué ci-dessus, un règlement net différé peut être multilatéral ou bilatéral. Lorsqu’un administrateur du Hub demande un règlement, le Hub calcule combien chaque participant doit ou est dû du fait des transactions à régler. Les transactions à régler sont définies comme toutes les transactions qui :
+
+- Relèvent de la ou des fenêtre(s) de règlement à régler.
+- Relèvent du modèle de règlement en cours de règlement.
+
+Si le règlement est *multilatéral*, un DFSP ne reçoit qu’un seul montant pour ce qu’il doit ou ce qui lui est dû du fait du règlement. Ce montant est le net de toutes les transactions à régler.
+
+Si le règlement est *bilatéral*, un DFSP peut recevoir plusieurs montants pour ce qu’il doit ou ce qui lui est dû du fait du règlement. Chaque montant représente le net des transactions du DFSP avec un DFSP particulier. Le net de toutes ces valeurs sera égal au montant global qu’il devrait ou qu’on lui devrait dans un règlement net multilatéral.
+
+## Rapports de règlement
+
+Pour faciliter le rapprochement des DFSP et le règlement à la banque de règlement, le Hub fournit divers rapports de règlement. Un schéma peut choisir d’avoir plusieurs rapports différents selon les usages. Voici quelques exemples :
+
+* Rapport de règlement DFSP : rapport remis à un DFSP lorsque le règlement a été initié. Il indique la position de règlement bilatérale du DFSP avec chaque DFSP avec lequel il a opéré (en tant que DFSP payeur ou DFSP bénéficiaire) dans la ou les fenêtre(s) de règlement concernée(s). Il indique aussi la position nette de règlement multilatéral du DFSP (somme des montants de transferts envoyés et reçus par le DFSP dans la ou les fenêtre(s) de règlement).
+* Rapport de la banque de règlement : rapport remis à la banque de règlement lorsque le règlement a été initié. Il indique la position de règlement bilatérale de chaque DFSP par rapport à tout autre DFSP ayant opéré dans la ou les fenêtre(s) de règlement concernée(s). Il indique aussi la position nette de règlement multilatéral de chaque DFSP (somme des montants de transferts envoyés et reçus par le DFSP).
+* Rapport de résultat de règlement DFSP : rapport remis à un DFSP lorsque le règlement est finalisé. Il détaille le solde du compte de liquidité du DFSP et les mouvements de fonds résultant de la clôture de la fenêtre de règlement.
+
+## Portail Finance
+
+Le [Portail Finance](busops-portal-introduction.md) (souvent désigné « Finance Portal v2 ») est un portail web utilisé par l’opérateur du Hub pour gérer au quotidien les processus liés au règlement. Le portail offre notamment les fonctionnalités suivantes :
+
+* consulter des informations telles que le solde, la [Position](#position), le [Net Debit Cap](#liquidity-management-net-debit-cap) des DFSP
+* mettre à jour le [Net Debit Cap](#liquidity-management-net-debit-cap) d’un DFSP
+* gérer les fenêtres de règlement
+<!--* download reports-->
+* enregistrer les dépôts ou retraits sur les comptes de liquidité des DFSP
+
+::: tip NOTE
+Le Portail Finance ne prend actuellement en charge que les processus de règlement fondés sur le modèle de règlement net différé.
+:::
diff --git a/docs/fr/adoption/HubOperations/Settlement/settlement-management-introduction.md b/docs/fr/adoption/HubOperations/Settlement/settlement-management-introduction.md
new file mode 100644
index 00000000..9ea7d9e0
--- /dev/null
+++ b/docs/fr/adoption/HubOperations/Settlement/settlement-management-introduction.md
@@ -0,0 +1,7 @@
+# Introduction – Guide de gestion des règlements
+
+Lorsqu’un paiement est effectué dans un système de paiements en temps réel comme Mojaloop, le DFSP qui est le dépositaire du compte du bénéficiaire (le DFSP créancier) accepte de créditer le bénéficiaire des fonds immédiatement. Mais le DFSP créancier n’a pas encore reçu les fonds du DFSP qui est le dépositaire du compte du débiteur : tout ce qui s’est produit jusqu’à présent, c’est que le DFSP débiteur a contracté une obligation de rembourser le DFSP créancier, et cette obligation a été enregistrée dans le Hub Mojaloop.
+
+Le processus de règlement est le processus par lequel un DFSP débiteur rembourse un DFSP créancier pour les obligations que le DFSP débiteur a contractées du fait des transferts.
+
+Ce guide décrit comment les règlements sont gérés par le Hub Mojaloop et la ou les banques de règlement partenaires, et présente les principaux éléments constitutifs du traitement des règlements.
diff --git a/docs/fr/adoption/HubOperations/TechOps/change-management.md b/docs/fr/adoption/HubOperations/TechOps/change-management.md
new file mode 100644
index 00000000..bfc37a94
--- /dev/null
+++ b/docs/fr/adoption/HubOperations/TechOps/change-management.md
@@ -0,0 +1,388 @@
+# Gestion des changements
+
+L'objectif du processus de gestion des changements est de contrôler le cycle de vie de tous les changements, permettant d'effectuer des modifications avec un minimum de perturbation des services informatiques.
+
+::: tip NOTE
+Les processus décrits dans cette section représentent les bonnes pratiques et servent de recommandations pour les organisations remplissant un rôle d'opérateur du Hub.
+:::
+
+## Objectifs
+
+Les objectifs de la gestion des changements sont de :
+
+* Répondre aux exigences métier changeantes tout en maximisant la valeur et en réduisant les incidents et les reprises de travail
+* Répondre aux demandes de changement (RFC) qui aligneront les services sur les besoins métier
+* S'assurer que les changements sont enregistrés et évalués, et que les changements autorisés sont gérés de manière contrôlée
+* Optimiser le risque métier global
+
+## Périmètre
+
+Le périmètre de la gestion des changements doit inclure les changements apportés à toutes les architectures, processus, outils, métriques et documentation, ainsi que les changements apportés à tous les éléments de configuration (CI) tout au long du cycle de vie du service.
+
+Tous les changements doivent être enregistrés et gérés dans un environnement contrôlé pour tous les CI. Il peut s'agir d'actifs physiques tels que des serveurs ou des réseaux, d'actifs virtuels tels que des serveurs virtuels ou du stockage, ou d'autres types d'actifs tels que des accords ou des contrats.
+
+La gestion des changements n'est pas responsable de la coordination de tous les processus de gestion des services pour assurer la mise en œuvre fluide des projets.
+
+## Rôles et responsabilités
+
+Les rôles énumérés ci-dessous indiquent certaines des parties prenantes essentielles nécessaires pour rendre le processus de gestion des changements efficace.
+
+### Responsable des changements
+
+Le responsable des changements agit en tant que chef de file, responsable du processus global de gestion des changements.
+
+Les principales responsabilités du responsable des changements sont :
+
+* Piloter l'efficience et l'efficacité du processus de gestion des changements
+* Produire des informations de gestion
+* Surveiller l'efficacité de la gestion des changements et formuler des recommandations d'amélioration
+* Adhésion au processus de gestion des changements
+* Planifier et gérer le support des outils et processus de gestion des changements
+* Vérifier que les RFC sont correctement complétées et attribuées aux autorités de changement (le cas échéant)
+* Communiquer les décisions des autorités de changement aux parties concernées
+* Activités de surveillance et de révision
+* Publier le calendrier des changements et les interruptions de service prévues
+* Mener des revues post-implémentation pour valider les résultats des demandes de changement
+* Déterminer la satisfaction métier concernant les demandes de changement
+
+### Coordinateur des changements
+
+Les coordinateurs des changements sont des membres du personnel de support qui gèrent les détails d'une demande de changement.
+
+Les responsabilités d'un coordinateur des changements comprennent :
+
+* Rassembler les informations appropriées en fonction du type de changement faisant l'objet d'une investigation
+* Associer les éléments de configuration, incidents et services connexes à la demande de changement
+* Fournir des mises à jour de statut aux demandeurs
+* Examiner les plans et calendriers de changement. Les activités de planification comprennent la programmation de la demande de changement, l'évaluation des risques et de l'impact, la création de plans, la définition et le séquencement des tâches nécessaires à l'accomplissement de la demande de changement, et la planification des personnes et des ressources pour chaque tâche.
+* Examiner toutes les tâches terminées. À l'étape de [mise en œuvre](#step-4-implement), au moins une tâche liée à la demande de changement est en cours.
+* Mener des revues post-implémentation pour valider les résultats de la demande de changement
+* Déterminer la satisfaction du demandeur concernant la demande de changement
+
+### Initiateur du changement
+
+Un initiateur du changement est une personne qui initie ou demande un changement, depuis un rôle métier ou technique. Différentes personnes peuvent initier un changement, ce rôle n'est pas exclusif à une seule personne. L'initiateur/demandeur du changement est tenu de fournir toutes les informations et justifications nécessaires pour le changement.
+
+Les autres responsabilités d'un initiateur du changement comprennent :
+
+* Compléter et soumettre une proposition de changement (si nécessaire)
+* Compléter et soumettre une demande de changement (RFC)
+* Assister aux réunions du comité consultatif des changements (CAB) pour fournir des informations complémentaires
+* Examiner les changements lorsque cela est demandé par la gestion des changements
+
+### Exécutant du changement
+
+Il s'agit de la personne désignée comme propriétaire de la demande de changement tout au long du cycle de vie de la demande. La mise en œuvre d'un changement nécessite une approbation de type réalisateur/vérificateur, c'est-à-dire que tous les changements nécessitent une personne pour effectuer le changement et une autre pour le valider.
+
+Les responsabilités d'un exécutant du changement comprennent :
+
+* Assurer la liaison avec le demandeur du changement pour les questions et problèmes métier et techniques, le cas échéant
+* Créer une RFC et mettre à jour son statut chaque fois que nécessaire
+* Vérifier et décider d'une date de mise en œuvre, en s'assurant qu'elle n'entre pas en conflit avec d'autres activités, par exemple, les délais, les fenêtres de changement, etc.
+* Évaluer et gérer les risques impliqués pendant le cycle de vie de la demande de changement
+* Tester et mettre en œuvre le changement
+* Coordonner et communiquer avec toute autre équipe impactée avant de soumettre le changement (en l'absence du coordinateur des changements)
+* Une fois le changement approuvé, créer un cas de remédiation pour le changement programmé
+* Exécuter le changement à la date et à l'heure programmées
+* Fournir le statut de clôture après l'achèvement réussi
+* Documenter la procédure de changement après sa mise en œuvre
+
+### Approbateur du changement
+
+Il s'agit d'une personne qui fournit l'approbation de premier niveau à une demande de changement avant qu'elle ne passe en revue au comité consultatif des changements. Les approbateurs des changements sont définis pour différents changements du Hub, ce qui signifie que ce rôle peut être occupé par différentes personnes à divers niveaux hiérarchiques du cadre de gestion des changements, chacune avec son propre domaine où elle agit en tant qu'approbateur.
+
+Les responsabilités d'un approbateur du changement comprennent :
+
+* Examiner toutes les RFC soumises par les initiateurs/demandeurs de changement
+* S'assurer que la demande de changement a atteint le niveau de préparation nécessaire pour justifier une décision du responsable des changements et du CAB
+* Examiner et commenter le contenu de l'enregistrement de changement, à savoir : plan de changement, mise en œuvre, plan de test et de remédiation, et calendrier
+* Accorder l'approbation une fois satisfait que tous les critères pertinents ont été remplis et les préoccupations traitées OU rejeter l'approbation en donnant des préoccupations et réserves claires concernant le contenu de l'enregistrement de changement
+* Le résultat des changements échoués lorsque le résultat négatif est le résultat d'une approbation non déterminée
+
+### Expert technique (SME)
+
+L'expert technique en la matière (SME) est une personne qui fait autorité dans un domaine ou sujet technique particulier. En relation avec la gestion des changements, le SME est responsable de :
+
+* Fournir les plans détaillés de mise en œuvre, de test et de remédiation
+* Assister à la réunion du CAB pour répondre aux questions et préoccupations concernant le changement auprès des approbateurs et de la gestion des changements (si invité)
+* La mise en œuvre des tâches de changement et la mise à jour des enregistrements pertinents dans l'outil de gestion des changements en ce qui concerne le statut de mise en œuvre
+* Examiner et retravailler un changement comme demandé, et contribuer à la revue d'un changement post-implémentation
+
+### Membre du CAB
+
+Le comité consultatif des changements (CAB) implique des membres de différents domaines, y compris la sécurité de l'information, les opérations, le développement, les réseaux, le Service Desk et les relations commerciales, entre autres. Un membre du CAB a les responsabilités suivantes :
+
+* Diffuser les RFC dans son domaine de responsabilité et coordonner les retours
+* Examiner les RFC et recommander si elles doivent être autorisées
+* Examiner les changements réussis, échoués et non autorisés
+* Examiner le calendrier des changements et les interruptions de service prévues
+
+### Président du CAB
+
+Le président du CAB est responsable de :
+
+* Convoquer et présider les réunions du CAB
+* Superviser le processus global de gestion des changements
+* S'assurer que le CAB remplit la charte sur les politiques et procédures relatives aux changements
+
+## Types de changements
+
+Le processus de gestion des changements traite les types de changements suivants.
+
+### Changements standard
+
+Un changement standard est un changement apporté à un service ou à un autre élément de configuration qui a été pré-autorisé et n'a donc pas besoin de passer par le processus d'approbation. Pour être considéré comme candidat à devenir un changement standard, au moins trois changements mineurs réussis doivent avoir été mis en œuvre. Une demande de changement standard doit ensuite être soumise au comité consultatif des changements pour approbation.
+
+Le risque d'un changement standard doit être faible et bien compris, les tâches doivent être bien connues, documentées et éprouvées, et il doit y avoir un déclencheur défini pour l'initier, tel qu'un événement ou une demande de service.
+
+Exemples de changements standard : mise à niveau du système d'exploitation (OS), déploiement de correctifs, etc.
+
+### Changements mineurs
+
+Un changement mineur est un changement non trivial qui a un impact faible et un risque faible. Ce sont des changements non triviaux qui ne se produisent pas fréquemment mais qui passent néanmoins par chaque étape du cycle de vie du changement, y compris l'approbation du CAB. Il est important de documenter les informations pertinentes pour référence future. Au fil du temps, un changement mineur peut être converti en changement standard.
+
+Exemples de changements mineurs : modifications de site web, améliorations de performance.
+
+Pour qu'un changement soit classé comme changement mineur, il doit avoir un délai de préparation inférieur à 3 jours.
+
+### Changements majeurs
+
+Un changement majeur est un changement à haut risque et à fort impact qui pourrait interrompre les environnements de production en direct s'il n'est pas correctement planifié. L'évaluation du changement est cruciale pour déterminer le calendrier et le flux d'approbation. Un changement majeur nécessite l'approbation de la direction en plus de l'approbation du CAB. La demande de changement (RFC) d'un changement majeur doit contenir une proposition détaillée sur l'analyse coût-bénéfice, l'analyse risque-impact et les implications financières, le cas échéant.
+
+En pratique, tous les changements qui impliquent un temps d'arrêt, en particulier un temps d'arrêt qui affecte l'intégration des DFSP et les activités de test sur les environnements inférieurs, doivent être classés comme changements majeurs et doivent être examinés par le CAB. Ces changements doivent être mis en œuvre en coordination avec le chef de projet technique.
+
+Pour qu'un changement soit classé comme changement majeur, il doit avoir un délai de préparation de 5 jours ou plus.
+
+### Changements d'urgence
+
+Un changement d'urgence est un changement qui doit être effectué dès que possible. Un changement d'urgence ne sera accepté que s'il est lié à un incident de sévérité 1, qui a un ticket S1 correspondant dans l'outil Service Desk. Le responsable de service initiera l'ouverture d'un changement d'urgence et demandera à l'expert technique de le créer.
+
+### Résumé des délais de préparation et matrice d'approbation
+
+<table>
+<colgroup>
+<col style="width: 33%" />
+<col style="width: 33%" />
+<col style="width: 33%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Type de changement</th>
+<th>Délai de mise en œuvre</th>
+<th>Revue et approbation</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Changement standard</p></td>
+<td><p>3 jours ouvrés</p></td>
+<td><p>Pré-approuvé</p></td>
+</tr>
+<tr class="even">
+<td><p>Changement mineur</p></td>
+<td><p>3 jours ouvrés</p></td>
+<td><ol type="1">
+<li><p>CAB</p></li>
+<li><p>Approbateurs métier (le cas échéant)</p></li>
+</ol></td>
+</tr>
+<tr class="odd">
+<td><p>Changement majeur</p></td>
+<td><p>5 jours ouvrés</p></td>
+<td><ol type="1">
+<li><p>CAB</p></li>
+<li><p>Approbateurs métier (le cas échéant)</p></li>
+</ol></td>
+</tr>
+<tr class="even">
+<td><p>Changement d'urgence</p></td>
+<td><p>Dès que possible</p></td>
+<td><p>CAB d'urgence ou propriétaire métier</p></td>
+</tr>
+</tbody>
+</table>
+
+## Comité consultatif des changements
+
+Le comité consultatif des changements (CAB) soutient la gestion des changements dans l'évaluation, la priorisation et la programmation des changements. Le CAB doit avoir une visibilité complète sur tous les changements qui pourraient présenter un risque modéré ou plus élevé pour les services et les éléments de configuration. Il est important qu'au sein du CAB, il y ait des membres qui peuvent fournir une expertise adéquate pour évaluer tous les changements tant du point de vue métier que technique.
+
+Il y a des membres permanents du CAB qui sont invités à toutes les réunions, mais pour s'assurer qu'il y a une compréhension claire de tous les besoins des parties prenantes, d'autres personnes seront invitées à participer en raison de leur expertise pour un changement qui doit être discuté. Le cas échéant, le fournisseur externe peut également être invité.
+
+### Réunion du CAB
+
+La réunion du CAB peut se tenir en personne ou par voie électronique. Il peut être plus pratique de tenir des réunions électroniques, cependant il peut être plus difficile de traiter les questions de cette façon. Ce sera la responsabilité du président du CAB de décider en fonction de la situation. Il est prévu que les réunions du CAB soient électroniques en raison des contraintes de délais.
+
+Une réunion du CAB est une réunion formelle avec une structure désignée. Avant toute réunion du CAB, les changements à discuter doivent être distribués à tous les membres. Le président du CAB est responsable de s'assurer que cela est effectué, mais peut déléguer la tâche au vice-président du CAB ou à tout membre du CAB.
+
+Tous les représentants des changements doivent assister ou envoyer un délégué. En cas d'absence, le changement ne sera pas discuté et donc pas approuvé. Tous les participants au CAB doivent venir à la réunion préparés à discuter des changements qu'ils représentent et à exprimer des opinions et avis basés sur le domaine particulier qu'ils représentent.
+
+La réunion du CAB est le forum pour discuter des changements précédents, réussis et échoués, et examiner les leçons apprises.
+
+Un ordre du jour pour la réunion du CAB doit être distribué avant la réunion. Le président du CAB est responsable de s'assurer que la structure est respectée, que les procès-verbaux sont pris et que les points d'action sont rassemblés pour être distribués après la réunion.
+
+## Processus de gestion des changements
+
+Cette section fournit un résumé des activités clés du processus de gestion des changements. Des instructions spécifiques sur la façon d'effectuer les activités du processus dans le contexte d'un service ou d'une fonction peuvent être fournies par des procédures opérationnelles locales dans un manuel de procédures.
+
+Tous les changements doivent être créés dans l'outil Service Desk.
+
+La figure suivante fournit un résumé de haut niveau du processus de gestion des changements avec les activités clés :
+
+![Résumé de haut niveau des activités du processus de gestion des changements](../../../../.vuepress/public/change_mgmt_flow.png)
+
+### Étape 1 : Créer une demande de changement (RFC)
+
+#### Objectif
+
+L'objectif de cette activité est de s'assurer que les types de demandes de changement sont respectés afin que le processus puisse répondre et gérer l'environnement tout en protégeant l'activité.
+
+La figure suivante fournit un résumé de la première étape du processus de gestion des changements.
+
+![Processus de gestion des changements – Initier un changement en créant une RFC](../../../../.vuepress/public/raise_rfc.png)
+
+#### Prérequis
+
+Les prérequis pour les changements doivent être alignés sur les exigences des mises en production telles que décrites dans le [processus de gestion des mises en production](release-management.md). Les éléments suivants doivent être clairement capturés dans l'outil Service Desk lors de la préparation de l'enregistrement de changement :
+
+* Transfert de l'équipe concernée à l'équipe des opérations, y compris une revue complète des éléments suivants :
+    * Ticket de changement ou enregistrement de changement : Raison du changement incluant l'impact, les risques, les limitations. La matrice de catégorisation du changement peut être la même que celle des incidents. Pour les détails sur la matrice de catégorisation des incidents, voir [Matrice de catégorisation des incidents](incident-management.md#incident-categorization-matrix).
+    * Runbook de changement : Étapes requises pour effectuer le changement et annuler le changement si nécessaire
+    * Résultats de tests de l'environnement inférieur : Preuve que le changement a été testé avec succès et ne cause pas de régression
+    * Plan de test pour l'environnement supérieur : Quels tests spécifiques doivent être exécutés pour valider le changement
+    * Toute la documentation connexe, y compris l'architecture, les diagrammes de flux, les informations de configuration/paramétrage, etc., a été mise à jour
+* Tests pré-changement : Vérifier la stabilité de l'environnement en examinant les derniers résultats de test du parcours de référence (GP)
+* Tests post-changement : Exécution des tests convenus pour valider le changement, et exécution des tests GP complets pour confirmer l'absence de régression sur l'environnement
+
+#### Entrées
+
+Les entrées de la RFC sont :
+
+* Demandes de service
+* Demandes de la [gestion des incidents](incident-management.md) pour appliquer des solutions de contournement/correctifs
+* Demandes de la [gestion des incidents](incident-management.md) pour effectuer des changements d'urgence afin de résoudre les incidents de sévérité 1
+* Demandes de nouvelles fonctionnalités du bureau de gestion de projet
+* Demandes de maintenance pour changement
+
+#### Sorties
+
+Enregistrements de changement contenant les détails des RFC pour examen.
+
+### Étape 2 : Examiner et autoriser
+
+#### Objectif
+
+Les changements sont examinés, et une étape d'approbation technique détermine si les informations minimales obligatoires requises sont capturées pour permettre une phase de planification et de programmation efficace.
+
+La figure suivante fournit un résumé de l'étape « examiner et autoriser » du processus de gestion des changements.
+
+![Processus de gestion des changements – Examiner et autoriser](../../../../.vuepress/public/review_authorize.png)
+
+#### Entrées
+
+Enregistrement de changement pour examen.
+
+#### Sorties
+
+Enregistrement de changement avec approbation technique.
+
+### Étape 3 : Planifier et approuver
+
+#### Objectif
+
+Les enregistrements de changement qualifiés qui ont passé une évaluation initiale dans les étapes précédentes du processus sont planifiés et approuvés. Le niveau de risque du changement orientera le chemin d'approbation.
+
+La figure suivante fournit un résumé de l'étape « planifier et approuver » du processus de gestion des changements.
+
+![Processus de gestion des changements – Planifier et approuver](../../../../.vuepress/public/plan_approve.png)
+
+#### Entrées
+
+Enregistrement de changement initialement autorisé.
+
+#### Sorties
+
+Enregistrement de changement entièrement planifié et approuvé.
+
+### Étape 4 : Mettre en œuvre
+
+#### Objectif
+
+Les experts techniques concernés exécutent les activités planifiées, enregistrent tout écart et entreprennent des activités de remédiation le cas échéant, conformément aux plans de changement, pour mettre en œuvre les changements demandés.
+
+La figure suivante fournit un résumé de l'étape « mettre en œuvre » du processus de gestion des changements.
+
+![Processus de gestion des changements – Mettre en œuvre](../../../../.vuepress/public/implement.png)
+
+#### Entrées
+
+Enregistrement de changement approuvé.
+
+#### Sorties
+
+Changement mis en œuvre, changement échoué, changement annulé, changement échoué remédié.
+
+### Étape 5 : Clôturer
+
+L'activité finale du processus garantit que les changements soumis à une revue post-implémentation reçoivent l'attention nécessaire et que les activités de remédiation sont comprises et exécutées.
+
+La figure suivante fournit un résumé de l'étape « clôturer » du processus de gestion des changements.
+
+![Processus de gestion des changements – Clôturer](../../../../.vuepress/public/close.png)
+
+#### Entrées
+
+Changements réussis, changements échoués, changements échoués avec remédiation.
+
+#### Sorties
+
+Changements clôturés.
+
+## Gouvernance
+
+**Nom de la réunion :** Réunion du comité consultatif des changements
+
+**Fréquence de la réunion :** Hebdomadaire
+
+**Objectif de la réunion :**
+
+* Examiner et approuver/rejeter les changements proposés dans un contexte métier et technique
+* Prioriser les changements proposés selon les besoins métier
+* Effectuer une revue post-implémentation des changements terminés et déterminer/documenter les leçons apprises
+* Examiner les changements précédemment approuvés mais non mis en œuvre dans la fenêtre de changement précédente et recommander des actions de suivi
+
+**Président de la réunion (rôle dans le processus) :** Président du CAB
+
+**Participants recommandés (rôles dans le processus) :**
+
+* Membres permanents du CAB
+* Représentants métier
+* Initiateur/exécutant du changement
+
+**Entrées :**
+
+* Calendrier des changements
+* Enregistrement de changement
+
+**Sorties :**
+
+* Approbation/rejet
+* Enregistrements de changement mis à jour
+* Points d'action
+
+### Gouvernance pour la communication des changements
+
+Les directives suivantes s'appliquent à la communication des changements :
+
+* Les changements standard seront communiqués aux parties prenantes internes.
+* Les changements majeurs, mineurs et d'urgence seront communiqués à toutes les parties prenantes métier et techniques concernées.
+* Les changements seront communiqués après les approbations du CAB.
+* Au début de la fenêtre de changement approuvée, une mise à jour par courriel et une notification Slack (ou similaire) doivent être envoyées aux parties prenantes concernées.
+* À la fin de la fenêtre de changement approuvée, une mise à jour par courriel et une notification Slack (ou similaire) doivent être envoyées aux parties prenantes concernées.
+* La communication externe aux clients (DFSP) et aux partenaires du Hub sera effectuée par le responsable de service.
+
+La notification doit inclure les détails suivants :
+
+* Titre et description du changement
+* Impact sur l'activité
+* Fenêtre de changement
+* Contacts/Coordinateur des changements
diff --git a/docs/fr/adoption/HubOperations/TechOps/defect-triage.md b/docs/fr/adoption/HubOperations/TechOps/defect-triage.md
new file mode 100644
index 00000000..d1dbd211
--- /dev/null
+++ b/docs/fr/adoption/HubOperations/TechOps/defect-triage.md
@@ -0,0 +1,93 @@
+# Triage des défauts
+
+L'objectif du processus de triage des défauts est de garantir que tous les bogues identifiés dans l'environnement de production de l'opérateur du Hub sont capturés, évalués et soumis à une équipe de support Mojaloop, une équipe dédiée à l'exécution des services de support pour les opérations techniques d'un Hub Mojaloop. Cette équipe peut être internalisée ou externalisée (ou même partiellement internalisée et partiellement externalisée), selon le niveau d'expertise ou de capacité au sein de l'organisation d'hébergement du schéma. S'il est décidé d'externaliser cette fonction, il existe des organisations au sein de la communauté Mojaloop qui fournissent différents niveaux de support en tant que service. (Pour plus d'informations et des recommandations, contactez la Fondation Mojaloop.)
+
+::: tip NOTE 
+Les processus décrits dans cette section représentent les bonnes pratiques et servent de recommandations pour les organisations remplissant un rôle d'opérateur du Hub. 
+:::
+
+::: tip NOTE
+Le processus proposé ici s'applique aux bogues identifiés dans l'environnement de production de l'opérateur du Hub, et les nouvelles fonctionnalités ou améliorations sont hors de son périmètre. Cependant, pour faciliter les conversations commerciales, les opérateurs du Hub peuvent soumettre des demandes de nouvelles fonctionnalités ou d'améliorations, et celles-ci seront transmises aux équipes produit de la communauté.
+:::
+
+Il doit y avoir une équipe spécifique responsable de l'évaluation et de la planification de la résolution de chaque bogue signalé dans les différents environnements (Production, Pré-production, QA, Développement, etc.). Il peut s'agir d'une équipe de support ou d'une équipe QA/Développement. Dans le reste de cette section, cette équipe est appelée « équipe de triage du support Mojaloop ».
+
+L'équipe de triage est composée des membres suivants :
+
+* Chef de produit Mojaloop (Mojaloop principal)
+* Chef de produit des extensions ou autres composants implémentés dans le Hub - Payment Manager, PortX, etc.
+* Expert technique du Hub (livraison produit, c'est-à-dire développement et QA)
+* Représentant des opérations (opérations techniques et infrastructure)
+
+## Bogues identifiés dans un environnement de production de l'opérateur du Hub
+
+*Étapes de l'opérateur du Hub :*
+
+1. Un ticket d'incident est créé dans l'outil [Service Desk](key-terms-kpis.md#key-terms) de l'opérateur du Hub par un ingénieur de support L1 du Hub, conformément au [processus de gestion des incidents](incident-management.md).
+1. Le ticket est escaladé vers l'équipe L2/L3 du Hub pour une investigation et une analyse approfondies, selon les besoins.
+1. L'équipe L2/L3 du Hub évalue si le comportement est un nouveau bogue ou un problème connu, et si un ticket/enregistrement de bogue existe déjà. S'il s'agit d'un bogue connu et qu'un ticket de support Mojaloop existe déjà, alors l'ingénieur L1 doit mettre à jour le ticket existant avec les nouveaux détails et informations, et la priorité et l'impact/sévérité (niveau d'impact sur le Hub ou ses utilisateurs) peuvent être ajustés en conséquence. L'ingénieur L1 doit communiquer cela au rapporteur/client DFSP (comme mentionné au point 6). Les nouveaux bogues suivront le reste du processus ci-dessous.
+1. L'équipe L2/L3 du Hub confirme que le problème de production peut être reproduit dans les environnements inférieurs exécutant la même version que l'environnement de production (PRD). C'est-à-dire que le bogue n'est pas une erreur utilisateur ou un problème environnemental.
+1. L'équipe L3 du Hub peut escalader vers le responsable des opérations techniques du Hub et signaler le bogue via l'outil Service Desk du support Mojaloop, en ajoutant tous les détails de leur analyse (y compris les étapes claires pour reproduire le bogue, le comportement attendu, le comportement réel et tous les fichiers journaux et détails des investigations L2/L3), en plus de l'identifiant du ticket d'incident créé à l'étape 1 pour un suivi facile.
+1. La réponse/accusé de réception/communication est renvoyée au client DFSP dans les délais convenus.
+
+*Étapes de l'équipe de support Mojaloop :*
+
+1. L'équipe de support Mojaloop examine, attribue un membre de l'équipe comme propriétaire et accuse réception du bogue.
+1. Suite à un examen initial du problème soulevé, le membre de l'équipe de support Mojaloop transmet le problème à l'équipe de triage pour une évaluation plus approfondie. \
+L'examen du ticket est effectué pour a) établir une bonne compréhension du problème soulevé, y compris le niveau de sévérité et la priorité définis par l'opérateur du Hub ; b) confirmer l'exhaustivité des informations fournies, y compris les fichiers journaux, la description claire, les étapes de reproduction, les captures d'écran, etc.
+1. L'équipe de triage évalue le bogue : les améliorations/demandes de nouvelles fonctionnalités sont transmises aux équipes produit de la communauté. L'impact opérationnel, la sévérité et la priorité sont examinés et la résolution du bogue est attribuée au chef de produit concerné. Pour les détails sur la priorisation, voir [Priorisation des bogues](#prioritization-of-bugs).
+1. Le chef de produit clone le bogue dans le backlog produit de son équipe de livraison produit, ce qui lie les deux problèmes pour référence et suivi de la progression. Le chef de produit examine et définit également la priorité par rapport aux autres éléments de son backlog produit.
+1. L'ingénieur de support Mojaloop assigné au ticket de bogue du support Mojaloop surveille le ticket cloné et gère toute la communication entre le chef de produit et l'opérateur du Hub sur la progression des bogues, y compris le partage de toute mesure corrective (par exemple, solutions de contournement ou façons alternatives d'utiliser la fonctionnalité affectée). Chaque mise à jour ultérieure de l'équipe de livraison produit doit également être partagée dans le ticket de bogue du chef de produit pour la visibilité de l'opérateur du Hub. Le chef de produit assigné doit rester le propriétaire du ticket de bogue du chef de produit jusqu'à ce que le bogue soit résolu.
+1. Le chef de produit communique le plan de résolution et les délais à l'équipe de support via le ticket de bogue original du chef de produit. Le plan de résolution est ensuite communiqué à l'opérateur du Hub. \
+\
+Pour les détails sur ce qui se passe si l'opérateur du Hub n'est pas d'accord avec la priorisation et le plan de résolution proposés, voir [Processus d'escalade](#escalation-process). 
+1. Le bogue est résolu suivant le processus de développement standard de l'équipe de livraison produit assignée et est inclus dans une version, qui sera mise à disposition de l'opérateur du Hub ou peut être proposée comme une version ad hoc (correctif), si nécessaire.
+1. Le ticket de support Mojaloop est clôturé une fois que la version de correction du bogue est déployée et validée dans l'environnement de l'opérateur du Hub.
+
+## Bogues identifiés pendant la fenêtre de déploiement/changement dans l'environnement du Hub
+
+Les déploiements dans les environnements du Hub sont de la responsabilité de l'équipe de l'opérateur du Hub, et les bogues identifiés pendant le déploiement doivent être signalés via le processus standard (c'est-à-dire qu'un ticket est créé conformément au processus de gestion des incidents du Hub, puis escaladé vers l'équipe de support Mojaloop si nécessaire). De plus :
+
+* L'équipe du Hub évaluera si le comportement est un problème connu ou un nouveau défaut. Pour les problèmes connus, la mise en production doit se poursuivre et être complétée comme prévu, le bogue connu étant signalé dans le rapport post-déploiement.
+* Pour les nouveaux défauts identifiés, la mise en production/le changement peut être annulé en fonction de la sévérité. Cette décision peut être prise par l'équipe de déploiement. En cas d'annulation, les tests de régression doivent être exécutés pour confirmer que la version précédente fonctionnelle est stable dans l'environnement, et le bogue est signalé dans le rapport post-déploiement.
+* Le bogue est capturé via l'outil Service Desk du support Mojaloop et sera traité via le processus décrit ci-dessus.
+
+## Processus d'escalade
+
+S'il y a un écart entre la priorité attribuée ou les attentes du client (opérateur du Hub) et le plan de résolution fourni par l'équipe de support Mojaloop, la [matrice d'escalade de la gestion des incidents](incident-management-escalation-matrix.md) régit la suite des événements. En conséquence, l'incident sera défini comme priorité P1 ou tout autre type de priorité inférieure et les parties prenantes seront informées.
+
+Le chef d'équipe du support Mojaloop et le responsable de programme de l'opérateur du Hub doivent être informés immédiatement. Le responsable de programme de l'opérateur du Hub est un responsable au sein de l'organisation du Hub qui est chargé de traduire les besoins commerciaux du schéma en directives d'opérations techniques.
+
+## Propriété et responsabilité
+
+Le créateur du ticket Service Desk (l'ingénieur de support de l'opérateur du Hub) reste le propriétaire jusqu'à ce que le ticket soit résolu.
+
+La priorité et la sévérité doivent être alignées, discutées et négociées entre l'équipe de triage du support Mojaloop et l'équipe des opérations de l'opérateur du Hub.
+
+Les informations issues des discussions de triage et de l'équipe de livraison produit doivent être partagées dans le ticket Service Desk par l'ingénieur de support Mojaloop.
+
+Le chef de produit à qui le bogue est assigné doit s'assurer que le référencement croisé et le suivi sont en place pour garantir le flux d'informations requises ou produites par l'évaluation de l'équipe de livraison produit.
+
+Le chef de produit à qui le bogue est assigné doit déterminer et communiquer le plan de résolution à l'équipe/ingénieur de support Mojaloop, via le ticket uniquement.
+
+### Priorisation des bogues
+
+La priorisation des bogues est de la responsabilité des experts en la matière (SME) de l'équipe de triage du support Mojaloop.
+
+Tous les bogues sont évalués en fonction du comportement attendu du système et du comportement réel observé (et reproduit). L'impact opérationnel et l'urgence du bogue doivent être capturés par l'équipe des opérations de l'opérateur du Hub afin que cela soit pris en compte par l'équipe de triage dans la priorisation.
+
+Chaque bogue est évalué par rapport à la feuille de route et au backlog du produit.
+
+Les demandes de nouvelles fonctionnalités ou d'améliorations sont acheminées vers l'équipe produit et ne sont pas traitées par ce processus. Cela est communiqué au demandeur via l'équipe des opérations.
+
+::: tip
+La priorité est l'ordre dans lequel le bogue sera corrigé. Plus la priorité est élevée, plus le bogue sera résolu rapidement. \
+\
+La sévérité est le niveau d'impact sur le Hub ou sur ses utilisateurs. \
+\
+Ces deux facteurs fonctionnent de concert. Par exemple, un bogue cosmétique comme une faute de frappe sur une page web sera probablement classé comme de faible sévérité mais pourrait être une correction rapide et facile et classé comme de haute priorité. Il est donc important de définir ces valeurs avec le soin nécessaire.
+:::
+
+## Diagramme de flux du processus
+
+<img src="../../../../.vuepress/public/defect_triage.png" width="70%" height="70%" />
diff --git a/docs/fr/adoption/HubOperations/TechOps/incident-management-escalation-matrix.md b/docs/fr/adoption/HubOperations/TechOps/incident-management-escalation-matrix.md
new file mode 100644
index 00000000..e7d12a74
--- /dev/null
+++ b/docs/fr/adoption/HubOperations/TechOps/incident-management-escalation-matrix.md
@@ -0,0 +1,51 @@
+# Annexe A : Matrice d'escalade de la gestion des incidents
+
+Cette section fournit des informations sur les rôles clés à contacter lorsqu'un incident survient.
+
+::: tip NOTE
+La matrice d'escalade de la gestion des incidents fournie ci-dessous sert uniquement d'exemple. Les noms réels des rôles peuvent être différents dans votre organisation.
+:::
+
+<table>
+<caption><strong>Chaîne de support pour les incidents</strong></caption>
+<colgroup>
+<col style="width: 25%" />
+<col style="width: 25%" />
+<col style="width: 25%" />
+<col style="width: 25%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Nom de l'équipe</th>
+<th>Responsable N</th>
+<th>Escalade N+1</th>
+<th>Escalade N+2</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Support client niveau 1</p></td>
+<td><p>Chef d'équipe support opérationnel L1/L2</p></td>
+<td><p>Responsable de service</p></td>
+<td><p>Responsable des opérations techniques</p></td>
+</tr>
+<tr class="even">
+<td><p>Support client niveau 2</p></td>
+<td><p>Responsable de service</p></td>
+<td><p>Responsable des opérations techniques</p></td>
+<td><p>Propriétaire produit du Hub / Responsable de programme</p></td>
+</tr>
+<tr class="odd">
+<td><p>Support client niveau 3</p></td>
+<td><p>Responsable de service</p></td>
+<td><p>Responsable des opérations techniques</p></td>
+<td><p>Propriétaire produit du Hub / Responsable de programme</p></td>
+</tr>
+<tr class="even">
+<td><p>Support client niveau 4</p></td>
+<td><p>Responsable de service</p></td>
+<td><p>Responsable des opérations techniques</p></td>
+<td><p>Propriétaire produit du Hub / Responsable de programme</p></td>
+</tr>
+</tbody>
+</table>
diff --git a/docs/fr/adoption/HubOperations/TechOps/incident-management.md b/docs/fr/adoption/HubOperations/TechOps/incident-management.md
new file mode 100644
index 00000000..f04a403b
--- /dev/null
+++ b/docs/fr/adoption/HubOperations/TechOps/incident-management.md
@@ -0,0 +1,695 @@
+# Gestion des incidents
+
+L'objectif principal de la gestion des incidents est de restaurer le fonctionnement normal du service aussi rapidement que possible et de minimiser l'impact sur les opérations métier, garantissant ainsi que les meilleurs niveaux possibles de qualité et de disponibilité de service sont maintenus. Le « fonctionnement normal du service » est défini ici comme le fonctionnement du service dans le cadre des [accords de niveau de service (SLA)](service-level-agreements.md).
+
+Cela est réalisé grâce à un processus de gestion des incidents robuste et bien aligné, guidé par un système de Service Desk qui aide à capturer tous les problèmes et à suivre le délai de traitement (TAT) depuis le moment où un problème est signalé jusqu'au moment de la résolution et de la clôture.
+
+Le processus de gestion des incidents implique la détection d'un incident, son enregistrement avec toutes les informations appropriées, l'analyse du problème, la correction des défauts et la restauration du service conformément au TAT stipulé.
+
+Cette section rassemble les principaux processus, concepts et principes relatifs à la gestion des incidents.
+
+::: tip NOTE
+Les processus décrits dans cette section représentent les bonnes pratiques et servent de recommandations pour les organisations remplissant un rôle d'opérateur du Hub.
+:::
+
+::: tip NOTE
+Tout au long de cette section, les termes « client », « consommateur », « utilisateur final » et « utilisateur » désignent tous un employé de DFSP. Lorsque ces mots sont utilisés dans un autre sens, la signification du mot est précisée et expliquée en détail.
+:::
+
+## La gestion des incidents en une seule image
+
+La figure suivante définit le flux de processus et les concepts clés de la gestion des incidents en une seule image.
+
+<img src="../../../../.vuepress/public/incident_mgmt_single_image.png" width="75%" height="75%" />
+
+<!--![Gestion des incidents en une seule image](/incident_mgmt_single_image.png)-->
+
+## Limites du processus
+
+Le processus de gestion des incidents commence lorsque :
+
+* un incident est déclenché par un appel téléphonique/courriel/interaction avec le Service Desk de la part des utilisateurs ou des clients
+* un incident est découvert par le biais d'un processus ou d'un outil interne, par exemple, il y a une alerte d'événement provenant de l'un des outils d'alerte ou des systèmes de surveillance
+* le personnel de support à tous les niveaux (ingénieurs de support L1, L2, L3) ou le responsable de service signale directement un incident
+
+Le processus de gestion des incidents se termine :
+
+* pour le client : lorsque le statut du ticket dans l'outil Service Desk est changé en « Clôturé »
+* pour l'équipe du Service Desk : lorsque l'incident est résolu et que la validation de clôture est envoyée au client
+
+Les limites de la gestion des incidents stipulent que le processus prend en compte les prérequis suivants :
+
+* Un accord de niveau de service (SLA) entre la communauté (par exemple, Mojaloop), les sociétés holding (par exemple, le Hub) et les prestataires de services financiers numériques (DFSP) est en place.
+* Un SLA entre le partenaire d'implémentation (le Hub) et les fournisseurs de logiciels tiers (par exemple, Microsoft, Oracle, etc.) est en place.
+* Il existe un accord de niveau opérationnel (OLA) existant. Cet accord décrit les responsabilités de chaque groupe de support interne envers les autres groupes de support, y compris le processus et le délai de livraison de leurs services.
+
+## Gestion des incidents étape par étape
+
+Cette section fournit une description détaillée du processus de gestion des incidents. Tous les incidents signalés passent par les étapes principales suivantes.
+
+### Étape 1 : Signaler et enregistrer l'incident, la demande de changement ou la question
+
+Les problèmes, demandes de changement ou questions peuvent être signalés et enregistrés via l'outil Service Desk dès qu'ils surviennent. L'outil Service Desk est le canal principal pour recevoir les requêtes liées aux incidents. Les courriels, appels téléphoniques et messagerie instantanée peuvent être utilisés comme canaux secondaires.
+
+Le statut des tickets tels que capturés dans le système Service Desk peut prendre les valeurs suivantes :
+
+* **En cours** : Un incident qui a été reçu via le Service Desk et assigné à un ingénieur de support. Les efforts de résolution ont commencé.
+* **Escaladé** : Un incident qui a été escaladé vers toute partie extérieure à l'équipe des opérations, y compris l'équipe de livraison produit ou les fournisseurs de services externes L4.
+* **En attente** : Un incident qui a été temporairement mis en attente ou en attente de retour de l'utilisateur ou d'un autre ticket qui doit être résolu avant que ce ticket puisse être résolu. \
+\
+Gardant à l'esprit que l'utilisation du statut « En attente » arrête le chronomètre SLA, la seule raison qui justifie l'utilisation de « En attente » est lorsqu'une action du client est requise. Il doit s'agir d'une action qui est de la responsabilité du client/consommateur ou de son fournisseur et qui est un prérequis à la continuation du processus ; par exemple, demander des informations essentielles ou l'approbation pour résoudre la demande. Les tickets de sévérité 1 et 2 ne doivent pas être mis au statut « En attente ». La restauration d'un service ou d'une fonction d'un service dépend rarement de l'action du client. La seule exception est lorsque le client arrête l'investigation ou la mise en œuvre d'une solution ou refuse une approbation nécessaire. Dans tous les cas, la décision du client doit être documentée.
+* **Annulé** : Un incident qui a été annulé. Un incident ne peut être annulé que lorsque le client en fait la demande.
+* **Résolu** : Un incident qui a été traité par un ingénieur de support et a été corrigé, et une alerte a été déclenchée à l'utilisateur pour réouvrir si non satisfait.
+* **Clôturé** : Un incident qui a été clôturé une fois que la résolution a été reconnue par l'utilisateur final.
+
+Toutes les informations pertinentes relatives aux incidents doivent être enregistrées afin qu'un historique complet soit maintenu. En maintenant des enregistrements d'incidents précis et complets, le personnel des groupes de support assignés est mieux en mesure de résoudre les incidents enregistrés.
+
+### Étape 2 : Catégoriser et prioriser
+
+L'utilisateur final/demandeur se voit attribuer un numéro de ticket pour référence et facilité d'accès lorsque le problème est reconnu et pris en charge par l'équipe de support. Le ticket doit être visible par le demandeur (l'employé DFSP qui a soulevé le problème) à tous les niveaux de support.
+
+Le demandeur sera automatiquement notifié par courriel de tout changement, mise à jour de statut, demande d'informations supplémentaires, disponibilité pour test ou résolution finale concernant le ticket.
+
+Nous classifions généralement les demandes de support en :
+
+* Incident
+* Demande de service
+* Demande de changement ou Request for Change (RFC, tels que fonctionnalités, améliorations)
+
+Les incidents sont catégorisés et sous-catégorisés en fonction du service informatique ou du domaine métier pour lequel l'incident cause une perturbation.
+
+Voici quelques exemples de catégories de service :
+
+* Infrastructure
+* Mojaloop
+* Sécurité
+* Règlements
+* Intégration
+
+La sévérité d'un incident peut être déterminée à l'aide d'une [matrice de catégorisation](#incident-categorization-matrix). En fonction de leur sévérité, les incidents peuvent être catégorisés comme :
+
+* Critique = S1
+* Grave = S2
+* Moyen = S3
+* Mineur = S4
+
+Une fois l'incident catégorisé, il est automatiquement acheminé vers un ingénieur de support L1 possédant l'expertise pertinente.
+
+### Étape 3 : Investiguer et résoudre
+
+La ressource de support assignée sera chargée d'investiguer le problème, ainsi que de préparer l'enregistrement de l'incident et de communiquer avec le client sur la façon de résoudre le problème.
+
+L'investigation d'un incident peut inclure l'une des actions suivantes :
+
+* Collecte et analyse d'informations
+* Recherche, y compris la reproduction du problème
+* Acquisition d'informations supplémentaires auprès d'autres sources
+
+La résolution d'un incident peut inclure l'une des actions suivantes :
+
+* Fournir une résolution ou des étapes vers une résolution
+* Modifications de configuration
+
+En fonction de la complexité de l'incident, il peut être nécessaire de le décomposer en sous-tâches ou tâches. Les tâches sont généralement créées lorsque la résolution d'un incident nécessite la contribution de plusieurs techniciens de différents départements.
+
+Pendant le traitement de l'incident, l'ingénieur de support doit s'assurer que l'accord de niveau de service n'est pas violé. Un SLA est le délai acceptable dans lequel un incident nécessite une réponse (SLA de réponse) ou une résolution (SLA de résolution). Les SLA peuvent être attribués aux incidents en fonction de leurs paramètres comme la catégorie de service, le demandeur, l'impact, l'urgence, etc. Dans les cas où un SLA est sur le point d'être violé ou a déjà été violé, l'incident peut être escaladé fonctionnellement ou hiérarchiquement pour garantir qu'il soit résolu au plus tôt.
+
+Un incident est considéré comme résolu lorsque l'équipe de support L1/L2/L3 a trouvé une solution de contournement temporaire ou une solution permanente au problème. Les solutions de contournement peuvent être :
+
+* des instructions fournies au client sur la façon d'accomplir son travail en utilisant une méthode alternative
+* des correctifs temporaires qui aident un système à fonctionner comme prévu mais qui ne résolvent pas le problème de manière permanente
+
+Les solutions de contournement doivent être documentées et communiquées au Service Desk afin qu'elles puissent être ajoutées à la base de connaissances. (Il est recommandé de maintenir un référentiel d'articles de base de connaissances, décrivant la solution de contournement ou les étapes de résolution des incidents survenus par le passé.) Cela garantira que les solutions de contournement sont accessibles au Service Desk pour faciliter la résolution lors de récurrences futures de l'incident.
+
+### Étape 4 : Escalader
+
+L'escalade d'un incident est la reconnaissance qu'il existe la possibilité qu'un incident dépasse les délais de résolution convenus à chaque niveau de support. Une gestion claire de l'escalade permet à l'équipe de support d'identifier, de suivre, de surveiller et de gérer les situations nécessitant une sensibilisation accrue et une action rapide.
+
+Il existe deux types d'escalade :
+
+* **Escalade fonctionnelle** : Ce type d'escalade intervient lorsqu'une équipe de niveau de support (par exemple, L1) est incapable de résoudre le problème ou de respecter le délai convenu (ce qui signifie que le temps ciblé pour la résolution est dépassé). Par conséquent, le cas est proactivement assigné au niveau de service suivant (par exemple, L2).
+* **Escalade hiérarchique** : Ce type d'escalade sert de moyen pour informer toutes les parties impliquées, de manière proactive, d'une violation potentielle du SLA. Cela aide à apporter de l'ordre, de la structure, de la responsabilité, de l'appropriation, une gestion ciblée et une mobilisation des ressources dans le but de fournir des services efficaces et efficients.
+
+### Étape 5 : Clôturer l'incident
+
+Un incident peut être clôturé une fois que le problème est résolu et que l'utilisateur reconnaît la résolution et en est satisfait.
+
+## Matrice de catégorisation des incidents
+
+L'une des étapes les plus importantes de la gestion des incidents est la catégorisation des incidents. Cela aide non seulement à trier les tickets entrants, mais garantit également que les tickets sont acheminés vers les ingénieurs de support les plus qualifiés pour traiter le problème. La catégorisation des incidents aide également le système de Service Desk à appliquer les SLA les plus appropriés aux incidents et à communiquer ces priorités aux utilisateurs finaux. Une fois qu'un incident est catégorisé, les ingénieurs de support peuvent diagnostiquer l'incident et fournir à l'utilisateur final une résolution.
+
+Le tableau suivant fournit des orientations sur la façon de classifier la sévérité d'un incident.
+
+<table>
+<caption><strong>Matrice de catégorisation des incidents</strong></caption>
+<colgroup>
+<col style="width: 16%" />
+<col style="width: 83%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Code de sévérité</th>
+<th>Critères</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Sévérité 1</p></td>
+<td><ul>
+<li><p>Impact étendu sur l'activité, panne du système de production, le fonctionnement normal n'est pas possible.</p></li>
+<li><p>Tout incident ayant entraîné une panne majeure du Hub, y compris la connectivité de plusieurs partenaires/DFSP.</p></li>
+<li><p>Tout incident présentant des risques financiers majeurs et ayant des implications contractuelles.</p></li>
+<li><p>Un incident de sécurité ayant un impact majeur sur la confidentialité ou la disponibilité du Hub, des partenaires/DFSP ou des données clients.</p></li>
+</ul></td>
+</tr>
+<tr class="even">
+<td><p>Sévérité 2</p></td>
+<td><ul>
+<li><p>Panne partielle du Hub.</p></li>
+<li><p>Une fonctionnalité clé est altérée sans solution de contournement disponible.</p></li>
+</ul></td>
+</tr>
+<tr class="odd">
+<td><p>Sévérité 3</p></td>
+<td><ul>
+<li><p>Impact fonctionnel mineur/modéré sur un seul utilisateur ou un petit groupe d'utilisateurs. Une solution de contournement existe.</p></li>
+</ul></td>
+</tr>
+<tr class="even">
+<td><p>Sévérité 4</p></td>
+<td><ul>
+<li><p>Un incident mineur avec (presque) aucun impact ou préjudice sur la fonctionnalité du système mais néanmoins un bogue valide.</p></li>
+</ul></td>
+</tr>
+</tbody>
+</table>
+
+Légende :
+
+* Sévérité 1 = Critique
+* Sévérité 2 = Grave
+* Sévérité 3 = Moyen
+* Sévérité 4 = Mineur
+
+Le code de sévérité attribué à un incident déterminera le temps de résolution et sera utilisé par le Service Desk pour attribuer des ressources à la demande.
+
+En plus de la sévérité, dans certains cas, la priorité d'un incident peut également devoir être prise en compte. La priorité est attribuée par l'opérateur du Hub (plutôt que par le client) et représente l'ordre dans lequel l'incident sera corrigé. Plus la priorité est élevée, plus l'incident sera résolu rapidement. Considérez l'exemple suivant : un bogue cosmétique comme une faute de frappe sur une page web sera probablement classé comme de faible sévérité mais pourrait être une correction rapide et facile et classé comme de haute priorité. Il est donc important d'accorder à la sévérité et à la priorité la considération nécessaire.
+
+Le tableau suivant fournit des orientations sur la façon d'attribuer une priorité à un incident.
+
+<table>
+<caption><strong>Matrice de priorité</strong></caption>
+<colgroup>
+<col style="width: 16%" />
+<col style="width: 83%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Code de priorité</th>
+<th>Critères</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Priorité 1</p></td>
+<td>Un problème grave est survenu affectant plusieurs utilisateurs au sein d'un bénéficiaire de service (&gt;50% des utilisateurs du bénéficiaire de service) dans la mesure où ils sont incapables d'exécuter leurs fonctions de travail assignées, OU le bénéficiaire de service ou des domaines extérieurs au bénéficiaire de service sont affectés.</td>
+</tr>
+<tr class="even">
+<td><p>Priorité 2</p></td>
+<td>Un problème est survenu affectant soit plusieurs utilisateurs (affecte &gt;10 mais pas plus de 50% de tous les utilisateurs du bénéficiaire de service) SOIT un utilisateur clé nommé du service dans la mesure où ils sont incapables d'exécuter leurs fonctions de travail assignées et une unité métier est affectée.</td>
+</tr>
+<tr class="odd">
+<td><p>Priorité 3</p></td>
+<td>Un problème est survenu affectant un seul utilisateur OU (affecte &lt;10 utilisateurs OU pas plus de 25% de tous les utilisateurs) dans la mesure où ils sont incapables d'exécuter leurs fonctions de travail assignées.</td>
+</tr>
+<tr class="even">
+<td><p>Priorité 4</p></td>
+<td>Un problème est survenu affectant un seul utilisateur, causant une fonctionnalité réduite d'une seule application. Il existe une solution de contournement pour que l'utilisateur puisse exécuter ses fonctions de travail assignées, mais la panne entraîne une diminution de sa productivité.</td>
+</tr>
+</tbody>
+</table>
+
+## Incidents de sécurité
+
+Cette section décrit la procédure qu'il est recommandé à un opérateur du Hub de mettre en œuvre pour le traitement des événements/incidents de sécurité. Les incidents de sécurité peuvent être classés comme incidents de sévérité 1, sévérité 2, sévérité 3 ou sévérité 4. Quelle que soit sa catégorisation, suivez les étapes décrites dans le tableau ci-dessous si un incident est lié à la sécurité.
+
+<table>
+<caption><strong>Gestion des incidents de sécurité</strong></caption>
+<colgroup>
+<col style="width: 25%" />
+<col style="width: 25%" />
+<col style="width: 25%" />
+<col style="width: 25%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th colspan="2">Étape</th>
+<th>Action ou information supplémentaire</th>
+<th>Rôle</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p><strong>Étape 1</strong> : Un événement/incident de sécurité suspecté est reçu via le Service Desk par le biais d'un ticket assigné à l'équipe de sécurité (L1) pour examen initial et triage.</p></td>
+<td></td>
+<td></td>
+<td></td>
+</tr>
+<tr class="even">
+<td><p><strong>Étape 2</strong> : Invoquer le processus de triage.</p></td>
+<td><p><strong>Étape 2a</strong> :</p>
+<ul>
+<li><p>Identifier les artefacts de l'incident.</p></li>
+<li><p>Identifier les appareils, systèmes ou utilisateurs affectés.</p></li>
+</ul></td>
+<td><ul>
+<li><p>Rassembler les indicateurs clés d'une menace.</p></li>
+<li><p>Récupérer les journaux.</p></li>
+<li><p>Rechercher les artefacts (adresses IP, noms d'utilisateurs, URL, noms d'hôtes, etc.).</p></li>
+<li><p>Examiner les journaux pour déterminer s'il y a une loi/réglementation violée par l'incident (s'il s'agit d'un incident grave, il pourrait nuire à la réputation de l'organisation).</p></li>
+</ul></td>
+<td><p>L1 Responsable de la sécurité de l'information (ISO)</p></td>
+</tr>
+<tr class="odd">
+<td><p></p></td>
+<td><p><strong>Étape 2b</strong> :</p>
+<ul>
+<li><p>Évaluer la situation : évaluation de l'impact.</p></li>
+<li><p>Estimer l'effet potentiel de l'événement ou de l'incident.</p></li>
+</ul></td>
+<td><ul>
+<li><p>Examiner les indicateurs de compromission disponibles.</p></li>
+<li><p>Évaluer l'impact en fonction de la criticité du système affecté.</p></li>
+<li><p>Examiner les journaux d'audit.</p></li>
+<li><p>Établir une chronologie des événements.</p></li>
+</ul></td>
+<td><p>L1 ISO</p></td>
+</tr>
+<tr class="even">
+<td><p></p></td>
+<td><p><strong>Étape 2c</strong> :</p>
+<p>Collecter les preuves.</p></td>
+<td><ul>
+<li><p>Collecter et rassembler toutes les informations disponibles pour permettre la catégorisation.</p></li>
+</ul></td>
+<td><p>L1 ISO</p></td>
+</tr>
+<tr class="odd">
+<td><p></p></td>
+<td><p><strong>Étape 2d</strong> :</p>
+<p>Déterminer la catégorisation.</p></td>
+<td><ul>
+<li><p>Sur la base des informations collectées, attribuer une catégorie au ticket.</p></li>
+<li><p>La sécurité L1 mettra à jour les catégorisations selon les besoins.</p></li>
+</ul>
+<p>Les exemples de catégories sont :</p>
+<ul>
+<li><p>Déni de service (DOS)</p></li>
+<li><p>Code malveillant</p></li>
+<li><p>Accès non autorisé</p></li>
+<li><p>Fuite/perte de données</p></li>
+<li><p>Violation de données (violation de la réglementation relative à la protection des données)</p></li>
+<li><p>Utilisation inappropriée</p></li>
+</ul></td>
+<td><p>L1 ISO</p></td>
+</tr>
+<tr class="even">
+<td><p></p></td>
+<td><p><strong>Étape 2e</strong> :</p>
+<p>Prendre les mesures de base pour atténuer l'effet sur l'environnement.</p></td>
+<td>Les mesures de base peuvent inclure des tâches telles que :
+<ul>
+<li><p>Verrouiller un point de terminaison.</p></li>
+<li><p>Déployer un anti-malware si nécessaire.</p></li>
+<li><p>Examiner les procédures opérationnelles standard de sécurité (SOP) (le cas échéant) pour toute étape supplémentaire qui pourrait être nécessaire.</p></li>
+</ul>
+<p>Si les mesures d'atténuation prises réussissent à résoudre le problème signalé, la sécurité L1 mettra à jour le ticket et passera à l'étape 8 (Clôturer le problème).</p></td>
+<td><p>L1/L2 ISO</p></td>
+</tr>
+<tr class="odd">
+<td><p><strong>Étape 3</strong> : Évaluer si le problème signalé est un événement ou un incident.</p></td>
+<td><p></p></td>
+<td><p>La décision d'évaluation est prise par l'équipe de sécurité L1 en collaboration avec la sécurité L2.</p></td>
+<td><p>L1/L2 ISO</p></td>
+</tr>
+<tr class="even">
+<td><p><strong>Étape 4.1</strong> : Si le problème signalé est catégorisé comme un « événement », suivre ces étapes :</p></td>
+<td><p><strong>Étape 4.1a</strong> :</p>
+<p>Effectuer le suivi de l'événement.</p></td>
+<td>Les exemples de suivi d'événement incluent :
+<ul>
+<li><p>Vérifier et installer un anti-malware sur tous les hôtes.</p></li>
+<li><p>Déclencher des tickets demandant la correction des systèmes et/ou la révision de l'événement par l'équipe des opérations.</p></li>
+</ul></td>
+<td><p>L1/L2 ISO</p></td>
+</tr>
+<tr class="odd">
+<td><p></p></td>
+<td><p><strong>Étape 4.1b</strong> :</p>
+<p>Passer à l'étape 8.</p></td>
+<td></td>
+<td><p>L1 ISO</p></td>
+</tr>
+<tr class="even">
+<td><p><strong>Étape 4.2</strong> : Si le problème signalé est catégorisé comme un « incident », suivre ces étapes :</p></td>
+<td><p><strong>Étape 4.2a</strong> :</p>
+<p>L'ISO L1 escalade vers l'ISO L2 pour une investigation plus approfondie en réattribuant le ticket au groupe de sécurité L2 pour suivi.</p></td>
+<td></td>
+<td><p>L1 ISO</p></td>
+</tr>
+<tr class="odd">
+<td><p></p></td>
+<td><p><strong>Étape 4.2b</strong> :</p>
+<p>L'ISO L2 accuse réception du ticket de L1 et procède à l'ouverture du rapport d'incident de sécurité.</p></td>
+<td></td>
+<td><p>L2 ISO</p></td>
+</tr>
+<tr class="even">
+<td><p></p></td>
+<td><p><strong>Étape 4.2c</strong> :</p>
+<p>L'ISO L2 examine et vérifie la sévérité et la catégorisation de l'incident.</p></td>
+<td><ul>
+<li><p>Pour les définitions de sévérité des incidents, voir la <a href="incident-management.html#incident-categorization-matrix">matrice de catégorisation</a>.</p></li>
+<li><p>Passer à l'étape 5.</p></li>
+</ul></td>
+<td><p>L2 ISO</p></td>
+</tr>
+<tr class="odd">
+<td><p><strong>Étape 5.1</strong> : Si l'incident signalé est catégorisé comme un incident « S1 », suivre ces étapes :</p></td>
+<td><p><strong>Étape 5.1a</strong> :</p>
+<p>Mettre à jour le rapport d'incident de sécurité.</p></td>
+<td></td>
+<td><p>L2 ISO</p></td>
+</tr>
+<tr class="even">
+<td></td>
+<td><p><strong>Étape 5.1b</strong> :</p>
+<p>Informer les parties prenantes par courriel sécurisé.</p></td>
+<td><p>Les parties prenantes sont documentées dans l'<a href="incident-management-escalation-matrix.html">Annexe A : Matrice d'escalade de la gestion des incidents</a>.</p></td>
+<td><p>L2 ISO</p></td>
+</tr>
+<tr class="odd">
+<td></td>
+<td><p><strong>Étape 5.1c</strong> :</p>
+<p>Passer à l'étape 6.</p></td>
+<td></td>
+<td><p>L2 ISO</p></td>
+</tr>
+<tr class="even">
+<td><p><strong>Étape 5.2</strong> : Si l'incident signalé est catégorisé comme un incident « S4 », suivre ces étapes :</p></td>
+<td><p><strong>Étape 5.2a</strong> :</p>
+<p>Passer à l'étape 6.</p></td>
+<td></td>
+<td><p>L2 ISO</p></td>
+</tr>
+<tr class="odd">
+<td><p><strong>Étape 6</strong> : Contenir et éradiquer.</p></td>
+<td><p><strong>Étape 6a</strong> :</p>
+<p>Examiner et mettre à jour les actions d'atténuation pour réduire l'impact.</p></td>
+<td><p>Les exemples d'actions d'atténuation incluent :</p>
+<ul>
+<li><p>Changer les mots de passe.</p></li>
+<li><p>Verrouiller l'accès.</p></li>
+</ul></td>
+<td><p>L2 ISO</p></td>
+</tr>
+<tr class="even">
+<td></td>
+<td><p><strong>Étape 6b</strong> :</p>
+<p>Collecter les preuves.</p></td>
+<td></td>
+<td><p>L2 ISO</p></td>
+</tr>
+<tr class="odd">
+<td></td>
+<td><p><strong>Étape 6c</strong> :</p>
+<p>Effectuer l'analyse des causes premières et identifier/mettre en œuvre un correctif.</p></td>
+<td></td>
+<td><p>L2 ISO</p></td>
+</tr>
+<tr class="even">
+<td></td>
+<td><p><strong>Étape 6d</strong> :</p>
+<p>Mettre à jour les procédures opérationnelles standard (SOP) de l'incident selon les besoins.</p></td>
+<td><p>Les mises à jour des SOP sont examinées par L3 avant adoption.</p></td>
+<td><p>L2 ISO</p></td>
+</tr>
+<tr class="odd">
+<td><p><strong>Étape 6.1</strong> : Si l'étape 6 est réussie, suivre ces étapes :</p></td>
+<td><p><strong>Étape 6.1a</strong> :</p>
+<p>Mettre à jour le rapport d'incident de sécurité et le ticket.</p></td>
+<td><p>S'assurer que le ticket ne contient pas d'informations de sécurité sensibles.</p></td>
+<td><p>L2 ISO</p></td>
+</tr>
+<tr class="even">
+<td></td>
+<td><p><strong>Étape 6.1b</strong> :</p>
+<p>Communiquer avec les parties prenantes par courriel sécurisé.</p></td>
+<td><p>Les parties prenantes sont documentées dans l'<a href="incident-management-escalation-matrix.html">Annexe A : Matrice d'escalade de la gestion des incidents</a>.</p></td>
+<td><p>L2 ISO</p></td>
+</tr>
+<tr class="odd">
+<td></td>
+<td><p><strong>Étape 6.1c</strong> :</p>
+<p>Mettre fin au verrouillage du système ou du service.</p></td>
+<td></td>
+<td><p>L2 ISO</p></td>
+</tr>
+<tr class="even">
+<td></td>
+<td><p><strong>Étape 6.1d</strong> :</p>
+<p>Passer à l'étape 8.</p></td>
+<td></td>
+<td><p>L2 ISO</p></td>
+</tr>
+<tr class="odd">
+<td><p><strong>Étape 6.2</strong> : Si l'étape 6 échoue, suivre ces étapes :</p></td>
+<td><p><strong>Étape 6.2a</strong> :</p>
+<p>Escalader vers l'équipe de sécurité L3.</p></td>
+<td></td>
+<td><p>L2 ISO</p></td>
+</tr>
+<tr class="even">
+<td></td>
+<td><p>Étape <strong>6.2b</strong> :</p>
+<p>Informer l'équipe métier.</p></td>
+<td></td>
+<td><p>L2 ISO</p></td>
+</tr>
+<tr class="odd">
+<td></td>
+<td><p><strong>Étape 6.2c</strong> :</p>
+<p>L3 procède à l'étape 7.</p></td>
+<td></td>
+<td><p>L3 ISO</p></td>
+</tr>
+<tr class="even">
+<td><p><strong>Étape 7</strong> : L3 examine et résout le problème.</p></td>
+<td><p><strong>Étape 7a</strong> :</p>
+<p>Examiner les activités et l'historique de l'incident documentés par L1 et L2.</p></td>
+<td></td>
+<td><p>L3 ISO</p></td>
+</tr>
+<tr class="odd">
+<td></td>
+<td><p><strong>Étape 7b</strong> :</p>
+<p>Fournir des orientations pour des actions de confinement supplémentaires.</p></td>
+<td></td>
+<td><p>L3 ISO</p></td>
+</tr>
+<tr class="even">
+<td></td>
+<td><p><strong>Étape 7c</strong> :</p>
+<p>Si L3 résout le problème, passer à l'étape 8.</p></td>
+<td></td>
+<td><p>L3 ISO</p></td>
+</tr>
+<tr class="odd">
+<td></td>
+<td><p><strong>Étape 7d</strong> :</p>
+<p>Si L3 ne peut pas résoudre le problème, il peut escalader vers l'OEM du système/logiciel ou obtenir des services spécialisés (sous réserve d'approbation) pour le support.</p></td>
+<td><p>Si L3 ne peut pas résoudre le problème, il peut escalader vers l'OEM du système/logiciel ou obtenir des services spécialisés (sous réserve d'approbation) pour le support. Une décision peut être nécessaire sur le déclenchement du plan de reprise après sinistre, y compris la formation d'une « cellule de crise ».</p><p>Un plan de reprise après sinistre (DRP) est un arrangement sur mesure, basé sur les capacités techniques de l'opérateur du Hub, ainsi que sur l'appétit pour le risque. Il fait partie des politiques de sécurité informatique d'un opérateur du Hub. Il est nécessaire d'évaluer les détails de la politique et des attentes du DRP de l'opérateur du Hub, et d'affiner le déploiement pour répondre à ses besoins. Les détails doivent être élaborés pendant la mise en œuvre (de préférence pendant la phase de conception) car les différentes options disponibles peuvent avoir des implications financières.</p></td>
+<td><p>L3 ISO</p></td>
+</tr>
+<tr class="even">
+<td><p><strong>Étape 8</strong> : Clôturer le problème.</p></td>
+<td><p><strong>Étape 8a</strong> :</p>
+<p>Restaurer les systèmes affectés.</p></td>
+<td></td>
+<td><p>L1 / L2 / L3 ISO</p></td>
+</tr>
+<tr class="odd">
+<td></td>
+<td><p><strong>Étape 8b</strong> :</p>
+<p>Mettre à jour le rapport d'incident de sécurité.</p></td>
+<td></td>
+<td><p>L2 / L3 ISO</p></td>
+</tr>
+<tr class="even">
+<td></td>
+<td><p><strong>Étape 8c</strong> :</p>
+<p>Identifier et communiquer les leçons apprises.</p></td>
+<td></td>
+<td><p>L2 / L3 ISO</p></td>
+</tr>
+<tr class="odd">
+<td></td>
+<td><p><strong>Étape 8d</strong> :</p>
+<p>L'équipe de réponse aux incidents examine les recommandations pertinentes pour une adoption éventuelle.</p></td>
+<td><p>Cette session de revue peut inclure les équipes des opérations techniques et de gestion des services, selon la sévérité.</p></td>
+<td><p>L1 / L2 / L3 ISO</p></td>
+</tr>
+<tr class="even">
+<td></td>
+<td><p><strong>Étape 8e</strong> :</p>
+<p>Informer les parties prenantes.</p></td>
+<td></td>
+<td><p>L2 / L3 ISO</p></td>
+</tr>
+<tr class="odd">
+<td></td>
+<td><p><strong>Étape 8f</strong> :</p>
+<p>Clôturer le problème.</p></td>
+<td></td>
+<td><p>L1 / L2 / L3 ISO</p></td>
+</tr>
+<tr class="even">
+<td><p><strong>Étape 9</strong> : L'ISO L3 modifie et révise les politiques et procédures relatives aux violations.</p></td>
+<td></td>
+<td></td>
+<td><p>L3 ISO</p></td>
+</tr>
+</tbody>
+</table>
+
+La figure suivante présente un résumé du processus décrit ci-dessus.
+
+![Gestion des incidents de sécurité](../../../../.vuepress/public/security_incident_process.png)
+
+### Modèle de rapport d'incident de sécurité
+
+Lors de la rédaction d'un rapport d'incident de sécurité, il est recommandé d'utiliser un modèle créé à cet effet.
+
+## Rôles et responsabilités
+
+Cette section fournit des directives génériques sur les rôles et responsabilités proposés au sein du processus de gestion des incidents.
+
+::: tip NOTE
+Il est pratique de décrire le support continu pour les opérations techniques du Hub Mojaloop en niveaux. Ce document décrit quatre niveaux. Les niveaux sont pratiques car chaque niveau de support nécessite un degré différent de connaissance et d'accès au système. En d'autres termes, les niveaux font référence à différents rôles/équipes de support au sein de votre organisation.
+
+Certaines de ces équipes peuvent éventuellement être externalisées, selon le niveau d'expertise ou de capacité au sein de votre organisation. Si vous décidez d'externaliser des fonctions de support, il existe des organisations au sein de la communauté Mojaloop qui fournissent différents niveaux de support en tant que service. (Pour plus d'informations et des recommandations, contactez la Fondation Mojaloop.)
+:::
+
+### Utilisateur final/utilisateur/demandeur/L0
+
+*Rôle*
+
+Il s'agit de la partie prenante qui subit une perturbation de service et crée un ticket d'incident pour initier le processus de gestion des incidents.
+
+*Responsabilités*
+
+* Contacter le Service Desk pour créer une nouvelle demande d'incident.
+* Suivre une demande existante.
+* Surveiller le canal de communication pour tout retour des ingénieurs de support.
+* Communiquer clairement toutes les informations requises ou demandées aux ingénieurs de support.
+* Reconnaître la restauration du service et l'achèvement du ticket.
+* Répondre aux enquêtes de suivi après la résolution du ticket en complétant la boucle de rétroaction.
+
+### Équipe niveau 1/Service Desk
+
+*Rôle*
+
+Il s'agit du premier point de contact (support niveau 1) pour les demandeurs ou les utilisateurs finaux lorsqu'ils souhaitent créer une demande ou un incident. Ce rôle est responsable de la résolution de base au Service Desk, des diagnostics initiaux et de l'investigation des tickets du Service Desk.
+
+*Responsabilités*
+
+* Enregistrer toutes les demandes d'incident entrantes avec les paramètres appropriés, tels que la sévérité et la priorité (si cette dernière est applicable).
+* Attribuer les tickets aux ingénieurs de support en fonction des paramètres ci-dessus (sévérité et priorité).
+* Analyser et résoudre l'incident pour restaurer le service.
+* Escalader les incidents non résolus vers l'équipe niveau 2.
+* Rassembler toutes les informations requises auprès des demandeurs et leur envoyer des mises à jour régulières sur le statut de leur demande.
+* Agir comme point de contact pour les demandeurs et, si nécessaire, coordonner entre l'équipe niveau 2 et les utilisateurs finaux.
+* Vérifier la résolution avec l'utilisateur final et recueillir les retours tout en mettant à jour les tickets.
+* Surveiller les retours et enquêtes liés aux actions que L1 a prises pour résoudre le problème dans le but d'analyser la qualité du service offert.
+
+### Équipe niveau 2 (Support application, infrastructure, sécurité et opérations métier L2) (Équipe de support client)
+
+*Rôles*
+
+Cette fonction de support est composée d'ingénieurs ou d'experts métier en la matière (SME) ayant une connaissance approfondie du Hub. L'équipe L2 est censée fournir un dépannage approfondi, une analyse technique, une analyse des transactions et un support pour résoudre les incidents signalés. Ils reçoivent généralement des demandes plus complexes des utilisateurs finaux ; ils reçoivent également des demandes sous forme d'escalades de l'équipe L1.
+
+*Responsabilités*
+
+* Effectuer le diagnostic de l'incident.
+* Documenter les étapes suivies pour résoudre l'incident et soumettre des articles de base de connaissances. (Pour chaque incident, l'équipe de support met à jour la base de connaissances. L'objectif des articles de base de connaissances est de permettre aux utilisateurs finaux et au personnel de support de résoudre les problèmes par eux-mêmes.)
+* Traiter les incidents intermédiaires, par exemple les incidents liés aux applications, à l'infrastructure, à l'analyse des journaux, à l'analyse des transactions, etc.
+* Si l'incident est résolu, confirmer la résolution avec l'utilisateur final.
+* Soutenir l'intégration des DFSP.
+
+### Équipe niveau 3 (Support application, infrastructure et sécurité L3) (Équipe de support technique)
+
+*Rôles*
+
+Ce niveau est généralement composé d'ingénieurs spécialisés ayant une connaissance approfondie de domaines particuliers du Hub – par exemple, connaissance des composants d'infrastructure ou des applications système, ou expertise en ingénierie de sécurité.
+
+*Responsabilités*
+
+* Effectuer une analyse approfondie et/ou reproduire le problème dans un environnement de test afin de diagnostiquer correctement le problème et de tester la solution.
+* Interpréter et analyser le code et les données en utilisant les informations triées depuis L1 et L2.
+* Si non résolu, escalader l'incident vers les partenaires de support « L4 » pour identifier le problème sous-jacent ou vers les fournisseurs externes, DFSP ou banque de règlement (requêtes de transactions ou rapports de transferts) selon le cas.
+* Fournir une expertise en la matière.
+* Documenter l'incident et mettre à jour la base de connaissances. (Pour chaque incident, l'équipe de support met à jour la base de connaissances. L'objectif des articles de base de connaissances est de permettre aux utilisateurs finaux et au personnel de support de résoudre les problèmes par eux-mêmes.)
+
+### Responsable des incidents/Responsable de service
+
+*Rôle*
+
+Le responsable de service surveille l'efficacité du processus. Le responsable de service gère le processus pour restaurer le fonctionnement normal du service aussi rapidement que possible et pour minimiser l'impact sur les opérations métier.
+
+*Responsabilités*
+
+* Servir de point de contact pour tous les incidents S1 signalés.
+* Planifier et faciliter toutes les activités impliquées dans le processus de gestion des incidents.
+* S'assurer que le processus correct est suivi pour tous les tickets et corriger tout écart.
+* Coordonner et communiquer avec le propriétaire du processus.
+* Aligner les attentes des clients avec les SLA en étant l'interface entre les clients et l'équipe des opérations.
+* Identifier les incidents qui doivent être examinés et effectuer l'examen.
+
+### Propriétaire du processus : Responsable des opérations techniques
+
+*Rôle*
+
+Il s'agit du propriétaire du processus suivi pour la gestion des incidents. Ce rôle agit également comme coordinateur entre les équipes et les organisations. Le responsable des opérations techniques analyse, modifie et améliore le processus pour s'assurer qu'il sert au mieux les intérêts de l'organisation.
+
+*Responsabilités*
+
+* Responsable de la qualité globale du processus. Supervise la gestion et la conformité aux procédures, modèles de données, politiques et technologies associés au processus.
+* Propriétaire du processus et de la documentation de soutien pour le processus d'un point de vue stratégique et tactique.
+* S'assure que le processus de gestion des incidents s'aligne sur les autres politiques de l'organisation, par exemple la politique RH, la politique de sécurité, les principes directeurs de niveau un, etc.
+* Définit les [indicateurs clés de performance (KPI)](key-terms-kpis.md) et les aligne sur les facteurs critiques de succès (CSF), et s'assure que ces objectifs sont atteints.
+* Conçoit, documente, examine et améliore les processus.
+* Établit l'amélioration continue du service (CSI) et s'assure que les procédures, politiques, rôles, technologies et autres aspects du processus de gestion des incidents sont examinés et améliorés.
+* Se tient informé des bonnes pratiques de l'industrie et les intègre dans le processus de gestion des incidents.
+
+## Résultats du processus de gestion des incidents
+
+Le processus de gestion des incidents produit les résultats suivants. Notez que le seul résultat obligatoire pour les incidents de sécurité ou S1 est l'analyse des causes premières (RCA), et tous les autres résultats énumérés ci-dessous peuvent alimenter la RCA.
+
+* Incidents résolus ou clôturés. Il s'agit du résultat le plus souhaité du processus de gestion des incidents. L'enregistrement d'incident clôturé contient des détails précis sur les attributs de l'incident et les étapes prises pour la résolution ou la solution de contournement.
+* Demandes de changement (RFC).
+* Métriques de résolution (temps moyen entre les pannes, temps moyen de réparation, temps moyen d'accusé de réception et temps moyen jusqu'à la défaillance). Pour les détails sur les KPI, voir le [Glossaire](key-terms-kpis.md).
+* Changement mis en œuvre avec succès à travers le processus de gestion des changements.
+* Document RCA conforme au modèle RCA.
+* Service restauré.
+* Base de données de la base de connaissances mise à jour.
+* Notification par divers canaux (Service Desk, courriel, appel, etc.) sur l'initiation, la résolution et la clôture d'un incident S1 aux différentes parties prenantes.
+* Rapport d'opérations quotidiennes et rapport de gestion mis à jour pour vérifier les décisions prises concernant les améliorations de service, l'allocation/réaffectation des ressources.
+* Détails d'interruption de service et/ou de composant enregistrés avec précision (par exemple, début, fin, durée, classification de l'interruption, etc.).
+
+## Impact sur les autres processus
+
+Le processus de gestion des incidents interagit avec un certain nombre d'autres processus, alimentant et impactant chacun d'entre eux :
+
+* **Processus de gestion des changements** : L'objectif du processus de gestion des changements est de s'assurer que des méthodes et procédures standardisées sont utilisées pour le traitement efficace et rapide de tous les changements, afin de minimiser l'impact des incidents liés aux changements sur la disponibilité ou la qualité du service, et par conséquent d'améliorer les opérations quotidiennes de l'organisation.
+* **Processus de gestion des mises en production** : La gestion des mises en production et du déploiement est définie comme le processus de gestion, de planification et de programmation du déploiement des services informatiques, des mises à jour et des versions dans l'environnement de production. L'objectif principal de ce processus est de s'assurer que l'intégrité de l'environnement de production est protégée et que les composants corrects et les fonctionnalités validées sont mis à disposition pour l'utilisation par les clients.
+* **Processus de communication des incidents** : La communication des incidents est le processus d'alerte des utilisateurs qu'un service connaît un type d'interruption ou une performance dégradée. Cela est particulièrement important pour les services où une disponibilité 24h/24 et 7j/7 est attendue. La communication des incidents est importante pour tous les partenaires, clients et leurs clients.
diff --git a/docs/fr/adoption/HubOperations/TechOps/key-terms-kpis.md b/docs/fr/adoption/HubOperations/TechOps/key-terms-kpis.md
new file mode 100644
index 00000000..703ca8ea
--- /dev/null
+++ b/docs/fr/adoption/HubOperations/TechOps/key-terms-kpis.md
@@ -0,0 +1,80 @@
+# Glossaire
+
+Cette section sert de glossaire des termes des opérations techniques et fournit des définitions :
+
+* des termes clés guidés par les bonnes pratiques de la bibliothèque d'infrastructure des technologies de l'information (ITIL)
+* des indicateurs clés de performance (KPI), c'est-à-dire des métriques qui aident à déterminer si les objectifs spécifiques de gestion des incidents sont atteints
+
+## Termes clés
+
+**Gestion des changements :** La gestion des changements est le processus d'enregistrement, d'approbation, d'exécution, de clôture et de révision de tous les changements. Le changement peut être soit contractuel (comme la signature initiale d'un contrat, une mise à niveau de SLA, de nouvelles ressources nécessaires, etc.), soit opérationnel résultant d'une demande de changement.
+
+**Escalade :** La reconnaissance du fait qu'un incident nécessite des ressources supplémentaires pour respecter les objectifs de niveau de service ou les attentes des utilisateurs, en tenant compte de la criticité, de l'impact et de l'urgence de l'incident.
+
+**Centre d'assistance/Service Desk :** Le point de contact unique entre le fournisseur de services et les utilisateurs. Un Service Desk typique gère les incidents et les demandes de service, et assure également la communication avec les utilisateurs.
+
+**Incident :** Une interruption non planifiée d'un service informatique, ou une réduction de la qualité d'un service informatique. La défaillance d'un élément de configuration qui n'a pas encore impacté le service est également un incident ; par exemple, la défaillance d'un disque dans un ensemble en miroir.
+
+**Processus de gestion des incidents (IMP) :** Le processus de gestion du cycle de vie de tous les incidents. L'objectif principal de la gestion des incidents est de restaurer le fonctionnement normal du service informatique aussi rapidement que possible avec le soutien de l'ensemble de l'organisation en place.
+
+**Enregistrement/ticket d'incident :** Un enregistrement contenant les détails d'un incident. Chaque enregistrement d'incident (également appelé ticket) documente le cycle de vie d'un seul incident.
+
+**Priorité :** Une catégorie utilisée pour identifier l'importance relative d'un incident ou d'un changement. La priorité est utilisée pour identifier les délais requis pour les actions à entreprendre.
+
+**Gestion des mises en production :** La gestion des mises en production est le processus de gestion, de planification, de programmation, de mise en œuvre et de contrôle d'une version logicielle à travers différentes étapes et environnements, dans le but de fournir des fonctionnalités aux clients ou aux utilisateurs finaux.
+
+**Demande de changement (RFC) :** La demande de changement (ou simplement demande de modification) est une demande formelle pour la mise en œuvre d'un changement. La RFC est un précurseur de l'« enregistrement de changement » et contient toutes les informations nécessaires pour approuver et exécuter un changement.
+
+**Rôle :** Un ensemble de responsabilités, d'activités et d'autorisations accordées à une personne ou une équipe. Les rôles sont utilisés pour attribuer des propriétaires aux différents processus de gestion des incidents et pour définir les responsabilités des activités dans les définitions détaillées des processus.
+
+**Analyse des causes premières (RCA) :** La RCA est un terme collectif qui décrit un large éventail d'approches, d'outils et de techniques utilisés pour découvrir les causes des incidents. Elle est invoquée lors de chaque incident urgent et chaque fois qu'un incident se produit plus d'une fois.
+
+**Accord de niveau de service (SLA) :** Un accord entre un fournisseur de services informatiques et un client. Le SLA décrit le service informatique, documente les objectifs de niveau de service et précise les responsabilités du fournisseur de services informatiques et du client.
+
+**Sévérité :** Une mesure de l'effet d'un incident sur les processus métier.
+
+**TAT (Délai de traitement) :** Il s'agit du temps écoulé entre le moment où l'incident est signalé et le moment où il est résolu et clôturé. Il comprend le temps d'intervention garanti (GIT) et le temps de résolution garanti (GRT).
+
+## Indicateurs clés de performance (KPI)
+
+**Taux de disponibilité (Taux de disponibilité du service) :** La disponibilité de l'ensemble de la solution technique pour fournir le service par DFSP.
+
+**Durée moyenne de clôture des incidents :** Durée moyenne entre l'enregistrement des incidents et leur clôture.
+
+**Temps moyen de réponse aux incidents :** La durée moyenne (par exemple, en minutes) entre la détection d'un incident et la première action entreprise pour réparer l'incident.
+
+**Nombre moyen d'incidents résolus par le Service Desk :** Nombre moyen d'incidents résolus par le Service Desk par rapport à tous les incidents ouverts.
+
+**Temps d'intervention garanti (GIT) :** Le temps écoulé entre le moment où un incident est signalé (par exemple, un courriel est envoyé à l'outil Service Desk) et le moment où une réponse d'accusé de réception est renvoyée au signaleur du problème.
+
+**Temps de résolution garanti (GRT) :** Somme du temps total consacré à la résolution d'un problème par toutes les parties. (Le statut du problème doit être « En cours » ou « Escaladé » pour être comptabilisé dans la somme totale. Les statuts « En attente » ou « Clôturé » ne sont pas pris en compte dans le calcul de la somme totale.)
+
+**Incidents résolus sans escalade :** Le pourcentage (%) d'incidents résolus dans le cadre du SLA sans aucune escalade.
+
+**Taux de file d'attente des incidents :** Le nombre d'incidents clôturés par rapport au nombre d'incidents ouverts sur une période donnée.
+
+**Temps moyen entre les pannes (MTBF) :** Le temps moyen entre les pannes réparables d'un produit technologique. Cette métrique est utilisée pour suivre à la fois la disponibilité et la fiabilité d'un service informatique ou de tout autre élément de configuration, afin d'évaluer s'ils peuvent remplir leur fonction convenue sans interruption. Plus le temps entre les pannes est élevé, plus le système est fiable.
+
+**Temps moyen d'accusé de réception (MTTA) :** Le temps moyen entre le déclenchement d'une alerte et le début du travail sur le problème. Cela mesure le temps qu'il faut à une organisation pour répondre aux plaintes, pannes ou incidents dans tous les départements en moyenne. Cette métrique est utile pour suivre la réactivité d'une équipe et l'efficacité d'un système d'alerte.
+
+**Temps moyen de détection (MTTD) – « Actions proactives » :** La différence entre le début de tout événement considéré comme ayant un impact sur les revenus et sa détection effective par le technicien qui initie ensuite une action spécifique pour rétablir l'événement à son état d'origine. Ce n'est pas la même chose que de démarrer le chronomètre du temps moyen de réparation (MTTR) (c'est-à-dire une fois que le technicien reçoit un ticket). Le début de tout événement ayant un impact sur les revenus est presque toujours enregistré à un moment précis par un équipement spécifique. L'élément clé est d'intégrer l'outil de détection dans l'environnement du technicien, puis de mesurer la différence entre l'horodatage de l'événement et la première action du technicien indiquant la reconnaissance de l'événement (MTTD).
+
+**Temps moyen jusqu'à la défaillance (MTTF) :** Le temps moyen entre les pannes non réparables d'un produit technologique (principalement le matériel).
+
+**Temps moyen de réparation (MTTR) :** Fait référence au temps moyen nécessaire pour réparer un système et le restaurer à sa pleine fonctionnalité. \
+\
+Le chronomètre MTTR commence à tourner lorsque les réparations commencent et continue jusqu'à ce que les opérations soient restaurées. Cela inclut le temps de réparation, la période de test et le retour à la condition de fonctionnement normal.
+
+**Temps moyen de récupération :** Le temps moyen de récupération est une mesure du temps entre le moment où la panne est découverte pour la première fois et le moment où le service reprend son fonctionnement. Ainsi, en plus du temps de réparation, de la période de test et du retour à la condition de fonctionnement normal, il capture le temps de notification de la panne et le diagnostic.
+
+**Arriéré d'anciens incidents :** Nombre d'incidents ouverts de plus de 28 jours (ou tout autre délai donné) par rapport à tous les incidents ouverts.
+
+**Pourcentage d'incidents résolus dans les délais/objectifs :** Nombre d'incidents clôturés dans le délai autorisé, par rapport au nombre total d'incidents clôturés sur une période donnée. Un délai est appliqué à chaque incident lors de sa réception et fixe une limite au temps disponible pour résoudre l'incident. Le délai appliqué est dérivé des accords conclus avec le client concernant la résolution des incidents.
+
+**Pourcentage d'incidents résolus dans le délai SLA :** Nombre total d'incidents résolus dans le délai SLA, divisé par le nombre total d'incidents.
+
+**Pourcentage d'indisponibilité due aux incidents :** Pourcentage d'indisponibilité due aux incidents, par rapport aux heures de service.
+
+**Pourcentage d'incidents en retard :** Nombre d'incidents en retard (non clôturés et non résolus dans le délai établi) par rapport au nombre d'incidents ouverts (non clôturés).
+
+**Pourcentage d'incidents répétés :** Pourcentage d'incidents pouvant être classés comme incidents répétés, par rapport à tous les incidents signalés au cours de la période de mesure. Un incident répété est un incident qui s'est déjà produit (plusieurs fois) au cours de la période de mesure.
diff --git a/docs/fr/adoption/HubOperations/TechOps/problem-management.md b/docs/fr/adoption/HubOperations/TechOps/problem-management.md
new file mode 100644
index 00000000..d6a9103b
--- /dev/null
+++ b/docs/fr/adoption/HubOperations/TechOps/problem-management.md
@@ -0,0 +1,131 @@
+# Gestion des problèmes
+
+L'objectif global de la gestion des problèmes est d'identifier la cause première des incidents (incidents de sévérité 1 ou incidents survenus plus d'une fois) ou les causes potentielles des incidents, puis de mettre en œuvre immédiatement des actions pour améliorer ou corriger la situation.
+
+La procédure de gestion des problèmes garantit que :
+
+* les problèmes sont correctement enregistrés
+* les problèmes sont correctement acheminés
+* le statut des problèmes est rapporté avec précision
+* la file d'attente des problèmes non résolus est visible et rapportée
+* les problèmes sont correctement priorisés et traités dans l'ordre approprié
+* la résolution fournie répond aux exigences de l'accord de niveau de service (SLA) convenu
+* la résolution des causes premières ou des problèmes est effectuée
+
+
+## Identification des problèmes
+
+Un problème est déclaré par la partie prenante concernée de la gestion des services dans les situations suivantes :
+
+* lorsqu'il y a un incident dont le propriétaire de l'incident ne peut pas établir la cause dans le cadre de l'accord de niveau de service défini
+* lorsqu'il y a des occurrences répétées d'un incident avec un impact considérable sur l'activité
+* lorsqu'il y a une dégradation du service ou un écart par rapport au comportement attendu susceptible d'affecter l'activité à l'avenir s'il n'est pas atténué, et dont l'atténuation n'est pas bien établie
+
+Dans l'un des scénarios ci-dessus, ou tout autre scénario que le responsable des problèmes peut juger applicable, un enregistrement de problème sera ouvert et le processus de gestion des problèmes sera lancé.
+
+Si un problème s'avère être causé par un défaut du produit, un bogue est signalé conformément au [processus de triage des défauts](defect-triage.md).
+
+## Catégorisation et priorisation des problèmes
+
+Afin de déterminer si les SLA sont respectés, il est nécessaire de catégoriser et prioriser les problèmes rapidement et correctement.
+
+L'objectif d'une catégorisation appropriée est de :
+
+* identifier le service impacté
+* associer les problèmes aux incidents connexes
+* indiquer quels groupes de support doivent être impliqués
+* fournir des métriques significatives sur la fiabilité du système
+
+Pour chaque problème, le service spécifique sera identifié.
+
+La priorité attribuée à un problème déterminera la rapidité avec laquelle il sera programmé pour résolution. La priorité est définie en fonction d'une combinaison de la sévérité et de l'impact des incidents associés.
+
+Le tableau ci-dessous fournit des orientations sur la façon de classifier un problème. Pour savoir comment lire ce tableau, voir les exemples suivants :
+
+* Un problème de sévérité élevée et d'impact faible sera classé comme un problème de priorité moyenne (vérifier la cellule à l'intersection de sévérité élevée et impact faible).
+* Un problème de sévérité moyenne et d'impact élevé sera classé comme un problème de priorité élevée (vérifier la cellule à l'intersection de sévérité moyenne et impact élevé).
+
+<table>
+<caption><strong>Matrice de priorité des problèmes</strong></caption>
+<colgroup>
+<col style="width: 20%" />
+<col style="width: 20%" />
+<col style="width: 20%" />
+<col style="width: 20%" />
+<col style="width: 20%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th></th>
+<th colspan="4"><strong>SÉVÉRITÉ</strong></th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td></td>
+<td></td>
+<td><p><strong>Faible</strong><br />
+<br />
+Le problème empêche l'utilisateur d'accomplir une partie de ses tâches.</p></td>
+<td><p><strong>Moyenne</strong><br />
+<br />
+Le problème empêche l'utilisateur d'exécuter des fonctions critiques sensibles au temps.</p></td>
+<td><p><strong>Élevée</strong><br />
+<br />
+Un service ou une partie majeure d'un service est indisponible.</p></td>
+</tr>
+<tr class="even">
+<td rowspan="3"><p><strong>IMPACT</strong></p></td>
+<td><p><strong>Faible</strong><br />
+<br />
+Le problème affecte un ou deux membres du personnel.</p>
+<p>Niveaux de service dégradés mais toujours dans les limites des SLA.</p></td>
+<td><p>Faible</p></td>
+<td><p>Faible</p></td>
+<td><p>Moyenne</p></td>
+</tr>
+<tr class="odd">
+<td><p><strong>Moyen</strong><br />
+<br />
+Niveaux de service dégradés mais ne respectant pas les contraintes SLA ou ne pouvant fournir qu'un niveau minimum de service.</p>
+<p>La cause du problème semble affecter plusieurs domaines fonctionnels.</p></td>
+<td><p>Moyenne</p></td>
+<td><p>Moyenne</p></td>
+<td><p>Élevée</p></td>
+</tr>
+<tr class="even">
+<td><p><strong>Élevé</strong><br />
+<br />
+Tous les utilisateurs d'un service spécifique sont affectés.</p>
+<p>Un service destiné aux clients est indisponible.</p></td>
+<td><p>Élevée</p></td>
+<td><p>Élevée</p></td>
+<td><p>Élevée</p></td>
+</tr>
+</tbody>
+</table>
+
+## Documentation des solutions de contournement
+
+Une solution de contournement définit un moyen temporaire de surmonter les effets négatifs d'un problème. Les solutions de contournement peuvent être :
+
+* des instructions fournies au client sur la façon d'accomplir son travail en utilisant une méthode alternative
+* des correctifs temporaires qui aident un système à fonctionner comme prévu mais qui ne résolvent pas le problème de manière permanente
+
+Les solutions de contournement doivent être documentées et communiquées au Service Desk afin qu'elles puissent être ajoutées à la base de connaissances. Cela garantira que les solutions de contournement sont accessibles au Service Desk pour faciliter la résolution lors de récurrences futures de l'incident.
+
+Dans les cas où une solution de contournement est trouvée, il est important de documenter tous les détails de la solution de contournement dans l'enregistrement du problème et que l'enregistrement du problème reste ouvert.
+
+## Documentation des erreurs connues
+
+Lorsqu'un diagnostic est établi pour identifier un problème et ses symptômes, un enregistrement d'erreur connue doit être créé et placé dans la documentation des erreurs connues. Si des incidents ou des problèmes récurrents surviennent, ils peuvent être identifiés et le service restauré plus rapidement. Toute solution de contournement ou résolution doit également être documentée dans l'enregistrement d'erreur connue du problème concerné.
+
+Dans certains cas, il peut être avantageux de créer un enregistrement d'erreur connue encore plus tôt dans le processus global – à titre informatif par exemple – même si le diagnostic n'est pas terminé ou qu'une solution de contournement n'a pas encore été trouvée.
+
+L'enregistrement d'erreur connue doit contenir tous les symptômes connus afin que, lorsqu'un nouvel incident survient, une recherche dans les erreurs connues puisse être effectuée et la correspondance appropriée trouvée.
+
+## Processus
+
+La figure suivante présente un résumé du processus décrit ci-dessus.
+
+![Gestion des problèmes](../../../../.vuepress/public/problem_mgmt.png)
diff --git a/docs/fr/adoption/HubOperations/TechOps/release-management.md b/docs/fr/adoption/HubOperations/TechOps/release-management.md
new file mode 100644
index 00000000..47bf62db
--- /dev/null
+++ b/docs/fr/adoption/HubOperations/TechOps/release-management.md
@@ -0,0 +1,108 @@
+# Gestion des mises en production
+
+La gestion des mises en production gère les processus de gestion, de planification, de programmation et de contrôle d'une modification logicielle à travers le déploiement et les tests dans divers environnements.
+
+::: tip NOTE
+Les processus décrits dans cette section représentent les bonnes pratiques et servent de recommandations pour les organisations remplissant un rôle d'opérateur du Hub.
+:::
+
+::: tip NOTE
+Cette section fait référence à une « équipe de support Mojaloop » : une équipe dédiée à l'exécution des services de support pour les opérations techniques d'un Hub Mojaloop. Notez que cette équipe peut être une unité internalisée ou externalisée, selon le niveau d'expertise ou de capacité au sein de votre organisation. Si vous décidez d'externaliser les fonctions de support, il existe des organisations au sein de la communauté Mojaloop qui fournissent différents niveaux de support en tant que service. (Pour plus d'informations et des recommandations, contactez la Fondation Mojaloop.)
+:::
+
+## Composants de mise en production et environnements
+
+Lors de l'acceptation de nouvelles versions de Mojaloop Open Source pour les services Switch et autres composants nécessaires, les versions passent par une série d'activités de test dans des environnements progressivement plus élevés, en commençant par les environnements de développement/QA et en terminant par les tests de niveau production.
+
+La configuration d'environnement recommandée comprend plusieurs environnements servant tous des objectifs différents, comme illustré dans le diagramme ci-dessous.
+
+<img src="../../../../.vuepress/public/release_mgmt.png" width="80%" height="80%" />
+
+Une implémentation spécifique au Hub de Mojaloop est construite sur un certain nombre de composants de service (Mojaloop OSS, extensions ou autres composants, personnalisations potentielles), et les versions incluront de nouvelles fonctionnalités, des améliorations ou des corrections de bogues de tous ces composants.
+
+<img src="../../../../.vuepress/public/release_service_components.png" width="70%" height="70%" />
+
+## Développement et tests (Définition de terminé)
+
+Les pratiques standard de développement et de QA – suivies par l'équipe de développement/livraison produit Mojaloop – incluent les éléments suivants dans le cadre de la définition de terminé. La recommandation est que l'opérateur du Hub adopte une stratégie similaire.
+
+* Tests unitaires développés pour chaque morceau de code écrit.
+* Le code, les tests unitaires et la documentation ont été revus par les pairs.
+* Les tests d'intégration ont été développés et exécutés.
+* Les tests de régression complets ont été exécutés avec succès lors du commit (fusion dans la branche master).
+* Les notes de version ont été créées avec les détails suivants :
+    * Description des changements
+    * Liste des composants/services modifiés
+    * Liste des user stories et bogues dans la version
+    * Mise en évidence de tout changement fondamental (rupture) impactant toute fonctionnalité, solution API ou architecture système
+* Runbook de déploiement créé, avec les instructions de déploiement et de retour en arrière, y compris les variables d'environnement, les scripts de mise à jour de base de données et les prérequis de déploiement.
+* Maintenance des définitions de tests de régression, des résultats de tests de référence de Mojaloop OSS et des critères de validation spécifiques au schéma (tests) ajoutés en complément.
+* Maintenance d'une base de connaissances sur tout changement nouveau ou significatif concernant les fonctionnalités, produits, architecture, etc., relatifs à Mojaloop OSS et autres composants, ainsi que les personnalisations effectuées pour le schéma. La base de connaissances sert de base pour le transfert de connaissances à l'équipe des opérations. Ce transfert comprend un examen complet du runbook de déploiement et d'autres artefacts de version, tels que les packages de version et les scripts de base de données, qui aideront grandement l'équipe des opérations dans les opérations quotidiennes, la validation, le débogage des problèmes et la maintenance.
+
+## Versions de Mojaloop
+
+La pratique standard pour les versions de Mojaloop est la suivante :
+
+* Toutes les nouvelles versions des applications individuelles, composants et microservices qui composent Mojaloop sont disponibles via les charts Helm dans les dépôts publics ici : <https://github.com/mojaloop/helm/releases>
+* Les tests unitaires et certains tests d'intégration fonctionnels sont produits avec chaque version de composant.
+* La version de Mojaloop inclut également des tests de régression automatisés de bout en bout. Les suites de tests sont versionnées, le numéro de version correspondant au numéro de version de la version de Mojaloop.
+* Un package de version est produit, une fois par incrément de programme (PI), pour les nouvelles versions de Mojaloop. Cela inclut les mises à niveau des applications individuelles, composants et microservices au sein de Mojaloop. \
+\
+Un incrément de programme est un intervalle limité dans le temps pendant lequel une équipe Agile livre une valeur incrémentale.
+* Toutes les mises à jour de maintenance de Mojaloop, les nouvelles fonctionnalités et les corrections de bogues sont mises à disposition des utilisateurs de Mojaloop dans le cadre des cycles de publication, une fois par période PI.
+
+## Versions de produits d'extensions/composants supplémentaires
+
+Il est recommandé que la pratique standard pour les versions de produits d'extensions/composants supplémentaires soit alignée sur le processus de publication de Mojaloop [ci-dessus](release-management.md#mojaloop-releases) :
+
+* Toutes les nouvelles versions de produits sont mises à disposition via des packages de version et décrites dans les notes de version.
+* Un package de version inclut des tests automatisés de bout en bout pour chaque version de produit. Les suites de tests sont versionnées, le numéro de version correspondant au numéro de version de la version du produit.
+* Les versions de produits sont alignées sur la cadence de publication de Mojaloop, une fois par période PI.
+* Toutes les mises à jour de maintenance des produits, les nouvelles fonctionnalités et les corrections de bogues sont mises à disposition des DFSP clients des extensions/produits supplémentaires dans le cadre du cycle de publication, une fois par période PI.
+
+## Bogues et correctifs urgents
+
+Les bogues et correctifs urgents sont traités de la manière suivante :
+
+* Toutes les corrections de bogues (à la fois Mojaloop et autres produits) sont incluses dans les packages de version.
+* De même, les correctifs urgents sont également fournis via une version. Il n'est pas recommandé de déployer des correctifs urgents directement à partir des versions de packages d'applications spécifiques, car le déploiement d'un seul composant d'une version (par opposition au déploiement de la version qui inclut le composant mis à jour) peut entraîner une désynchronisation du Hub avec la version du package d'application.
+* Les bogues sont suivis, gérés et priorisés comme défini dans le [processus de triage des défauts](defect-triage.md) :
+    * L'outil Service Desk est utilisé pour la gestion de tous les bogues.
+    * Une équipe de triage du support Mojaloop avec des représentants des équipes de livraison produit et de gestion de produit de Mojaloop et d'autres produits est impliquée dans l'analyse de l'urgence et de l'impact pour déterminer la priorisation des bogues, y compris la planification/programmation de la résolution et la communication à l'opérateur du Hub.
+
+## Environnements et stratégie QA
+
+Afin de valider un déploiement d'une version nouvellement publiée de Mojaloop par rapport aux derniers autres produits (extensions/composants supplémentaires), un environnement doit être mis en place par le schéma avec tous les composants nécessaires ainsi que la configuration spécifique que le schéma utilise. Cela permet aux équipes de QA/validation et/ou de support Mojaloop (une équipe dédiée à l'exécution des services de support pour les opérations techniques d'un Hub Mojaloop) d'effectuer le déploiement et les tests des versions de Mojaloop par rapport aux dernières versions des autres produits.
+
+::: tip NOTE
+L'environnement mis en place par l'équipe de support Mojaloop pour la validation doit suivre une infrastructure standard, reproduisant ou simulant une configuration de production correspondante autant que possible, afin que tout problème ou bogue puisse être identifié tôt dans le processus. Une configuration de production comprend généralement des passerelles API, des DMZ, une configuration de cluster basée sur des zones de sécurité, ainsi que tous les composants et personnalisations nécessaires (y compris les règles du schéma) effectuées par le schéma. L'opérateur du Hub doit s'assurer que son infrastructure de production est entièrement synchronisée avec les normes d'infrastructure de l'équipe de support Mojaloop.
+::: 
+
+Suite au déploiement et à la validation réussis d'une version sur l'infrastructure et l'architecture standard, et après avoir exécuté avec succès la dernière version de Mojaloop et des autres produits, la version est approuvée et peut être partagée/mise à disposition (via le serveur/dépôt client de l'équipe de support). L'équipe du Hub peut alors programmer le déploiement dans l'environnement (potentiellement personnalisé) de l'opérateur du Hub.
+
+La stratégie QA employée par les équipes de livraison produit de Mojaloop et des produits d'extension garantit que le nouveau code de chaque composant de service a subi des tests complets avant sa publication. La stratégie QA de l'équipe de support Mojaloop, en revanche, doit se concentrer sur la validation de la déployabilité des composants de service intégrés et l'interopérabilité des produits, garantissant qu'il existe un Switch Mojaloop fonctionnel, qui peut ensuite être déployé dans l'environnement d'un opérateur du Hub.
+
+## Processus de mise en production
+
+La recommandation pour les implémentations de Hub est de rester alignée sur la cadence de publication de Mojaloop d'une version par période PI et d'éviter de déployer des changements individuels directement depuis la branche master d'applications, composants ou services spécifiques au sein de Mojaloop. Cette recommandation garantit que l'intégrité des applications reste plus propre et alignée sur les dépôts sources.
+
+Pour chaque version, il est recommandé que l'équipe de support Mojaloop suive les étapes suivantes :
+
+::: tip NOTE
+Les opérateurs du Hub doivent être informés de la date de publication cible bien à l'avance.
+:::
+
+1. L'équipe de support Mojaloop examine tous les artefacts de version, y compris les notes de version et la documentation associée, et crée ou améliore le runbook de déploiement dès que la version est disponible.
+1. L'équipe de support Mojaloop effectue le déploiement et la validation des versions planifiées de Mojaloop et d'autres produits dans un environnement de support Mojaloop temporaire (utilisant l'infrastructure de support Mojaloop standard mais correspondant aux versions d'applications du client – c'est-à-dire de l'opérateur du Hub).
+1. Suite au déploiement et à la validation réussis d'une version sur l'infrastructure et l'architecture de support Mojaloop standard, et après avoir testé avec succès la dernière version de Mojaloop et des autres produits, la version est approuvée et mise à disposition de l'opérateur du Hub.
+1. L'équipe de l'opérateur du Hub confirme la disponibilité (et éventuellement, la fenêtre de déploiement cible) pour le déploiement dans l'environnement de développement de l'opérateur du Hub. \
+\
+Il est de la responsabilité de l'opérateur du Hub d'effectuer le déploiement dans l'environnement de développement et la validation ultérieure. Alternativement, il peut demander au support Mojaloop d'effectuer ces activités en son nom.
+
+### Déploiements par l'équipe de support Mojaloop
+
+Si l'opérateur du Hub demande à l'équipe de support Mojaloop d'effectuer le déploiement dans l'environnement de développement de l'opérateur du Hub, alors l'équipe de support Mojaloop envoie un courriel (ou toute autre forme de communication selon les préférences de l'opérateur du Hub) avec des informations sur la date de publication cible, l'éventail des fonctionnalités incluses dans la version et la fenêtre de déploiement. Suite au déploiement, une communication supplémentaire est envoyée pour confirmer que le déploiement a été effectué, validé et que la fenêtre de déploiement est fermée.
+
+## Diagramme de flux du processus
+
+<img src="../../../../.vuepress/public/release_process.png" width="65%" height="65%" />
diff --git a/docs/fr/adoption/HubOperations/TechOps/service-level-agreements.md b/docs/fr/adoption/HubOperations/TechOps/service-level-agreements.md
new file mode 100644
index 00000000..f7157914
--- /dev/null
+++ b/docs/fr/adoption/HubOperations/TechOps/service-level-agreements.md
@@ -0,0 +1,35 @@
+# Annexe B : Accords de niveau de service
+
+Les délais indiqués dans le tableau suivant sont des exemples de temps de réponse cibles pour le traitement des incidents. Ils peuvent servir de point de départ pour que l'opérateur du Hub définisse ses propres délais.
+
+::: tip NOTE
+La réponse ne peut pas être une réponse automatisée.
+:::
+
+<table>
+<caption><strong>Exemples de délais de réponse aux incidents et SLA</strong></caption>
+<colgroup>
+<col style="width: 50%" />
+<col style="width: 50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Sévérité de l'incident</th>
+<th>Temps de réponse cible</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Sévérité 1</p></td>
+<td><p>Dans les 2 heures</p></td>
+</tr>
+<tr class="even">
+<td><p>Sévérité 2</p></td>
+<td><p>Dans les 4 heures ouvrées</p></td>
+</tr>
+<tr class="odd">
+<td><p>Sévérité 3-4</p></td>
+<td><p>Dans les 8 heures ouvrées</p></td>
+</tr>
+</tbody>
+</table>
diff --git a/docs/fr/adoption/HubOperations/TechOps/tech-ops-introduction.md b/docs/fr/adoption/HubOperations/TechOps/tech-ops-introduction.md
new file mode 100644
index 00000000..c07db4eb
--- /dev/null
+++ b/docs/fr/adoption/HubOperations/TechOps/tech-ops-introduction.md
@@ -0,0 +1,31 @@
+# Introduction – Guide des opérations techniques
+
+Le Hub Mojaloop exploite un certain nombre d'environnements qui nécessitent une gestion et une maintenance quotidiennes. Les procédures standard décrites dans ce document présentent les processus opérationnels qui permettent à l'opérateur du Hub de gérer tous les aspects d'un service en production.
+
+Les procédures suivantes doivent être mises en place :
+
+- [**Gestion des incidents**](./incident-management.md) : Gestion des incidents qui ont été signalés à l'équipe des opérations techniques ou qui sont parvenus à l'équipe via des alertes ou des activités de surveillance.
+
+- [**Gestion des problèmes**](./problem-management.md) : Identification de la cause première des incidents ou des causes potentielles des incidents, et mise en œuvre immédiate d'actions pour améliorer ou corriger la situation.
+
+- [**Gestion des changements**](./change-management.md) : Contrôle du cycle de vie de tous les changements, permettant d'effectuer des modifications avec un minimum de perturbation des services informatiques.
+
+- [**Gestion des mises en production**](./release-management.md) : Gestion, planification, programmation et contrôle d'une modification logicielle à travers le déploiement et les tests dans divers environnements.
+
+- [**Triage des défauts**](./defect-triage.md) : Garantir que tous les bogues identifiés dans l'environnement de production du client sont capturés, évalués, priorisés et soumis au Service Desk.
+
+Un aperçu rapide des environnements gérés par l'opérateur du Hub est fourni ci-dessous :
+
+- **Développement** : Environnement de développement logiciel hors production où le code OSS de Mojaloop est fusionné avec les personnalisations. Fournit aux développeurs un retour rapide sur les nouvelles soumissions de code. Les prestataires de services financiers numériques (DFSP) n'interagissent pas avec cet environnement. Accès réservé aux développeurs et au QA uniquement.
+
+- **Tests d'acceptation utilisateur (UAT)** : Environnement de test pour l'acceptation utilisateur et les tests de régression afin de valider les nouvelles versions.
+
+- **Bac à sable (SBX)** : Environnement de test pour valider la connectivité des DFSP en termes d'exigences API et de sécurité.
+
+- **Pré-production (STG)** : Environnement de pré-production qui reflète la production aussi fidèlement que possible. Validation des nouvelles versions et de l'intégration des DFSP.
+
+- **Production (PRD)** : Environnement de production compatible avec la version en production.
+
+::: tip
+Un [Glossaire](./key-terms-kpis.md) est fourni pour aider à clarifier les termes courants des opérations techniques utilisés dans ce document. Si vous rencontrez un terme nécessitant une explication, il est utile de consulter le glossaire pour vérifier si une définition a été fournie.
+:::
diff --git a/docs/fr/adoption/Scheme/platform-operating-guideline.md b/docs/fr/adoption/Scheme/platform-operating-guideline.md
new file mode 100644
index 00000000..855ee50e
--- /dev/null
+++ b/docs/fr/adoption/Scheme/platform-operating-guideline.md
@@ -0,0 +1,553 @@
+# Modèle de directive opérationnelle de la plateforme
+
+- Version : 2.0 
+    - Auteur : Carol Coye Benson (Glenbrook), Michael Richards (ModusBox)  
+    - Date : Octobre 2019
+    - Description : 
+
+---
+
+## **À propos du projet de documents commerciaux de la communauté Mojaloop**
+
+Ce document fait partie du projet de documents commerciaux de la communauté Mojaloop. Le projet est destiné à soutenir les entités (pays, régions, associations de fournisseurs ou entreprises commerciales) mettant en œuvre de nouveaux systèmes de paiement utilisant le code Mojaloop. Ces entités devront également rédiger des règles commerciales que les participants au système suivront.
+
+Le projet de documents commerciaux de la communauté Mojaloop fournit des modèles pour les règles commerciales et les documents associés. De nombreux choix sont impliqués dans la mise en œuvre d'un nouveau système de paiement : les modèles présentent certains de ces choix et, le cas échéant, des commentaires sont fournis sur la manière dont le choix particulier est lié aux objectifs d'un système aligné sur Level One.
+
+Les documents suivants font partie du projet :
+
+- Choix clés du schéma
+
+- Modèle d'accord de participation au schéma
+
+- Modèle de règles commerciales du schéma
+
+- Modèle de directive opérationnelle de la plateforme
+
+- Modèle de directive opérationnelle de gestion des exceptions
+
+- Glossaire uniforme
+
+## **Introduction**
+
+Un schéma mettant en œuvre un système aligné sur Level One, y compris ceux utilisant le code de référence Mojaloop dans la plateforme, devra rédiger des règles commerciales pour le schéma. Un modèle pour ces règles commerciales est inclus dans ce projet. Les règles commerciales introduisent le concept de documents associés, qui font partie des règles commerciales et ont la même force — les DFSP signant les règles commerciales sont également tenus de suivre les dispositions des documents associés.
+
+La directive opérationnelle de la plateforme est un document associé important qui décrit comment la plateforme du schéma fonctionnera et précise les obligations et responsabilités du schéma, de l'opérateur de la plateforme et des DFSP.
+
+Ce document est un modèle pour une telle directive opérationnelle de la plateforme. Cependant, de nombreuses dispositions varieront en fonction des choix effectués par le schéma : certains de ces choix sont décrits dans le document « Choix clés du schéma » qui fait partie de ce projet.
+
+Le modèle de règles commerciales qui fait partie de ce projet peut être utilisé indépendamment du choix de plateforme d'un schéma. Cette directive opérationnelle de la plateforme est plus spécifique à l'utilisation de Mojaloop comme plateforme.
+
+## **Table des matières — Modèle de directive opérationnelle de la plateforme**
+
+[1 - À propos de ce document](#_1-a-propos-de-ce-document)
+
+[1.1 - Services du schéma](#_1-1-services-du-schema)
+
+[1.2 - Spécification Open API](#_1-2-specification-open-api)
+
+[1.3 - Cas d'utilisation du schéma](#_1-3-cas-d-utilisation-du-schema)
+
+[1.4 - Identifiants pris en charge par le schéma](#_1-4-identifiants-pris-en-charge-par-le-schema)
+
+[2 - Le service de recherche de compte](#_2-le-service-de-recherche-de-compte)
+
+[2.1 - Description du service de recherche de compte](#_2-1-description-du-service-de-recherche-de-compte)
+
+[2.2 - Requête de partie](#_2-2-requete-de-partie)
+
+[2.3 - Requête Parties](#_2-3-requete-parties)
+
+[2.4 - Réponse à la requête Parties](#_2-4-reponse-a-la-requete-parties)
+
+[3 - Le service de devis](#_3-le-service-de-devis)
+
+[3.1 - Description du service de devis](#_3-1-description-du-service-de-devis)
+
+[3.2 - Demande de devis](#_3-2-demande-de-devis)
+
+[3.3 - Réponse au devis](#_3-3-reponse-au-devis)
+
+[4 - Le service de transfert](#_4-le-service-de-transfert)
+
+[4.1 - Description du service de transfert](#_4-1-description-du-service-de-transfert)
+
+[4.2 - Demande de transfert](#_4-2-demande-de-transfert)
+
+[4.3 - Demande de paiement](#_4-3-demande-de-paiement)
+
+[5 - Le service de règlement](#_5-le-service-de-reglement)
+
+[5.1 - Règlement des transferts](#_5-1-reglement-des-transferts)
+
+[5.2 - Règlement des frais : frais de traitement](#_5-2-reglement-des-frais-frais-de-traitement)
+
+[5.3 - Règlement des frais : frais d'interchange](#_5-3-reglement-des-frais-frais-d-interchange)
+
+[6 - Le service de gestion du schéma](#_6-le-service-de-gestion-du-schema)
+
+[6.1 - Description du service de gestion du schéma](#_6-1-description-du-service-de-gestion-du-schema)
+
+[6.2 - Le processus d'inscription](#_6-2-le-processus-d-inscription)
+
+[6.3 - Service client DFSP](#_6-3-service-client-dfsp)
+
+[6.4 - Gestion du système du schéma](#_6-4-gestion-du-systeme-du-schema)
+
+[7 - Le service de gestion de la fraude](#_7-le-service-de-gestion-de-la-fraude)
+
+[8 - Annexe : Cas d'utilisation pris en charge par le schéma et paramètres système](#_8-annexe-cas-d-utilisation-pris-en-charge-par-le-schema-et-parametres-systeme)
+
+[9 - Annexe : Codes de catégorie de commerçants](#_9-annexe-codes-de-categorie-de-commercants)
+
+## 1. À propos de ce document
+
+Ces directives opérationnelles de la plateforme spécifient les exigences opérationnelles et techniques pour les DFSP et pour le schéma. De temps à autre, le schéma publiera des bulletins opérationnels supplémentaires, qui décriront des fonctionnalités opérationnelles supplémentaires du schéma et spécifieront des exigences supplémentaires pour les DFSP.
+
+### 1.1 Services du schéma
+
+- Les services du schéma sont utilisés par les DFSP pour échanger des transactions interopérables et pour gérer leur participation au schéma.
+
+- Le service de recherche de compte du schéma permet aux DFSP du système d'identifier le DFSP qui gère le compte de transaction d'un bénéficiaire prévu ou d'une autre contrepartie à un transfert.
+
+- Le service de transfert du schéma permet à un DFSP payeur d'envoyer un transfert à un DFSP bénéficiaire, effectuant ainsi un transfert de fonds d'un payeur à un bénéficiaire.
+
+- Le service de règlement du schéma permet aux DFSP de régler leurs obligations financières envers le schéma en ce qui concerne les transferts.
+
+- Le service de gestion du schéma permet au schéma d'accorder et de révoquer l'accès au schéma par les DFSP, gère les interactions continues des DFSP avec le schéma, surveille le fonctionnement efficace du schéma et fournit des outils aux DFSP pour gérer leur participation au schéma.
+
+- Le service de gestion de la fraude du schéma permet aux DFSP de collaborer sur certains éléments de la gestion de la fraude afin de réduire les coûts et d'améliorer les résultats.
+
+- Les DFSP sont tenus de suivre les procédures détaillées ci-dessous pour l'utilisation du schéma.
+
+### 1.2 Spécification Open API
+
+Les protocoles du schéma sont basés sur les modèles opérationnels et de données définis dans le document de spécifications « Open API for FSP Interoperability Specification » version 1.0 daté du \[xx\]. Lorsque le schéma s'écarte de cette spécification, ces écarts sont documentés ici et remplaceront les sections pertinentes de ce document. Le schéma peut mettre à jour la version utilisée en publiant un bulletin opérationnel.
+
+### 1.3 Cas d'utilisation du schéma
+
+Certaines règles et spécifications opérationnelles varient selon les cas d'utilisation et les cas d'utilisation secondaires pris en charge par le schéma. Le schéma reconnaît les cas d'utilisation et les cas d'utilisation secondaires par une combinaison de composants de données requis et d'inférence système. Cela est détaillé dans une annexe à ce document.
+
+### 1.4 Identifiants pris en charge par le schéma
+
+Le schéma prend en charge certains identifiants, ou adresses de paiement, à utiliser pour effectuer des transferts. L'identifiant identifie le bénéficiaire dont le compte de transaction est crédité pour le transfert. Les identifiants pris en charge par le schéma sont répertoriés dans une annexe aux règles commerciales.
+
+Pour chaque identifiant pris en charge par le schéma, ce document doit spécifier ce qu'est l'identifiant et comment il est résolu (comment il est déterminé quel DFSP bénéficiaire est responsable du compte de transaction associé à cet identifiant).
+
+#### 1.4.1 Exemple : L'identifiant MSISDN 
+
+Chaque schéma aura ses propres directives pour chaque identifiant ; les dispositions ci-dessous pourraient varier considérablement en fonction des choix effectués.
+
+- Les MSISDN sont des numéros mobiles qui sont globalement uniques. Les MSISDN sont l'identifiant de compte de transaction pour les DFSP qui sont des opérateurs de réseau mobile et qui fournissent des comptes de transaction à leurs clients.
+
+- L'utilisation du MSISDN comme identifiant de bénéficiaire est limitée aux comptes de transaction fournis par les DFSP qui sont l'opérateur de réseau mobile responsable de ce MSISDN.
+
+::: tip NOTE
+Si les MSISDN sont utilisés pour d'autres comptes de transaction, ce sont des alias, et un protocole distinct pour les résoudre doit être spécifié.
+:::
+
+- Une requête de partie pour un MSISDN est résolue par un service de répertoire MSISDN déterminé par le schéma. Le schéma peut spécifier des obligations de maintenance du service de répertoire pour les DFSP opérateurs de réseau mobile de temps à autre.
+
+#### 1.4.2 Exemple : L'identifiant du numéro de compte bancaire 
+
+Chaque schéma aura ses propres directives pour chaque identifiant ; les dispositions ci-dessous pourraient varier considérablement en fonction des choix effectués.
+
+- Les numéros de compte bancaire sont attribués aux clients par les DFSP bancaires qui fournissent des comptes de transaction à leurs clients.
+
+- Le numéro de compte bancaire, associé à un code bancaire, forme l'identifiant de numéro de compte bancaire du schéma. Les DFSP payeurs sont responsables du formatage correct de l'identifiant de numéro de compte bancaire selon les formats qui seront spécifiés par le schéma.
+
+- L'utilisation de l'identifiant de numéro de compte bancaire est limitée aux comptes de transaction fournis par les DFSP qui sont des banques.
+
+- Une requête de partie pour un identifiant de compte bancaire est envoyée par le DFSP payeur au schéma. Le schéma vérifie que le code bancaire dans l'identifiant de compte bancaire est associé à une banque active dans le schéma.
+
+#### 1.4.3 Exemple : L'identifiant commerçant du schéma 
+
+Chaque schéma aura ses propres directives pour chaque identifiant ; les dispositions ci-dessous pourraient varier considérablement en fonction des choix effectués.
+
+- L'identifiant commerçant est un identifiant défini par le schéma utilisé pour les paiements de personne à entreprise.
+
+- L'utilisation de l'identifiant commerçant est limitée aux DFSP qui fournissent des comptes de transaction aux commerçants, émetteurs de factures, agences gouvernementales ou autres entités commerciales qui reçoivent des paiements de leurs clients via le schéma. Il peut être utilisé pour les paiements en personne et à distance. Le terme « commerçant » utilisé dans cette section inclut tous ces types de receveurs de paiements.
+
+- L'utilisation de l'identifiant commerçant est limitée aux transferts des cas d'utilisation P2B ou P2G.
+
+- Un commerçant peut demander plusieurs identifiants commerçant à son DFSP ; ceux-ci peuvent être utilisés par le commerçant pour différents points de vente, caisses ou magasins. Il n'y a pas de limite au nombre d'identifiants commerçant pouvant être liés à un seul compte de transaction. Cependant, un identifiant commerçant donné ne peut être lié qu'à un seul compte de transaction.
+
+- L'identifiant commerçant est émis par le schéma au DFSP qui fournit au commerçant le compte de transaction dans lequel les paiements seront effectués.
+
+- L'identifiant commerçant est émis sous forme de numéro, qui peut être affiché par un commerçant physiquement ou numériquement.
+
+- Les identifiants commerçant peuvent être rendus sous forme de codes QR par les DFSP ou leurs clients commerçants. Les codes QR doivent être rendus selon les directives de format et de marque qui seront publiées par le schéma. Il est interdit aux DFSP d'utiliser d'autres formats de données de code QR ou marques pour recevoir des paiements via le schéma.
+
+- Les DFSP sont tenus d'afficher la marque du schéma. Les exigences de marque du schéma seront spécifiées par le schéma. La marque du schéma doit être visible pour le client dans le magasin du commerçant, ou sur l'appareil que le client payeur utilise pour acheter à distance.
+
+- Exigences d'inscription. Les DFSP demanderont un identifiant commerçant pour un client en utilisant une API du schéma spécifique à cet effet. Les DFSP devront fournir :
+
+    - Identifiant DFSP
+
+    - Le numéro de compte de transaction qui recevra les fonds payés au commerçant. Il peut s'agir soit d'un MSISDN, soit d'un numéro de compte bancaire.
+
+    - Le \[numéro d'enregistrement commercial ou d'identification fiscale\] du commerçant. N'importe quel nombre d'identifiants commerçant peut être associé au même numéro d'enregistrement commercial ou d'identification fiscale.
+
+    - Le nom du commerçant
+
+- Les DFSP demandant un identifiant commerçant au schéma garantissent qu'ils ont complété les informations KYC requises pour le compte du commerçant au moment de la demande.
+
+- Les DFSP sont tenus de fournir des informations de formation adéquates à leurs clients.
+
+- Désactivation des identifiants commerçant. Les DFSP peuvent demander la désactivation d'un identifiant commerçant. Le schéma désactivera immédiatement cet identifiant commerçant, mais le conservera dans le système du schéma à des fins de reporting. Les demandes de devis ou les demandes de transfert effectuées vers cet identifiant commerçant seront refusées par le schéma et renvoyées au DFSP payeur.
+
+Le schéma peut souhaiter fournir un mécanisme permettant le portage d'un identifiant commerçant d'un DFSP à un autre.
+
+#### 1.4.4 L'identifiant Scheme ID 
+
+Cet identifiant serait similaire à l'identifiant commerçant ci-dessus mais serait destiné aux consommateurs ainsi qu'aux entreprises, et pourrait être exprimé en phrases plutôt qu'en numéro. Notez que chaque schéma aura ses propres directives pour chaque identifiant ; les dispositions ci-dessous pourraient varier considérablement en fonction des choix effectués.
+
+- Le Scheme ID est un identifiant défini par le schéma.
+
+- Les DFSP sont tenus d'offrir à leurs clients l'option de demander un Scheme ID.
+
+- Les Scheme ID peuvent prendre n'importe quelle forme, sous réserve uniquement de restrictions de longueur que le schéma spécifiera de temps à autre. Le schéma se réserve le droit de refuser l'utilisation de tout Scheme ID spécifique demandé.
+
+Les schémas peuvent souhaiter activer les Scheme ID.
+
+- Les clients peuvent demander un nombre quelconque de Scheme ID, sous réserve des limites imposées par leur DFSP. Plusieurs Scheme ID peuvent être associés à un seul compte de transaction. Cependant, chaque Scheme ID ne peut être associé qu'à un seul compte de transaction.
+
+- Exigences d'inscription. Les DFSP demanderont un Scheme ID pour un client en utilisant une API du schéma spécifique à cet effet. Les DFSP devront fournir dans cette API :
+
+    - Identifiant DFSP
+
+    - Le Scheme ID demandé
+
+    - Le numéro de compte de transaction qui recevra les fonds payés au client. Il peut s'agir soit d'un MSISDN, soit d'un numéro de compte bancaire.
+
+    - Si le titulaire du compte de transaction est un commerçant ou une entreprise, le \[numéro d'enregistrement commercial ou d'identification fiscale\] du titulaire du compte. N'importe quel nombre de Scheme ID peut être associé au même numéro d'enregistrement commercial ou d'identification fiscale.
+
+- Les DFSP demandant un Scheme ID au schéma garantissent qu'ils ont complété les informations KYC requises pour le compte du client au moment de la demande.
+
+- Désactivation des identifiants du schéma. Les DFSP peuvent demander la désactivation d'un Scheme ID. Le schéma désactivera immédiatement ce Scheme ID, mais le conservera dans le système du schéma à des fins de reporting. Les demandes de devis ou les demandes de transfert effectuées vers ce Scheme ID seront refusées par le schéma et renvoyées au DFSP payeur.
+
+Le schéma peut souhaiter fournir un mécanisme permettant le portage d'un Scheme ID d'un DFSP à un autre.
+
+Les sections suivantes décrivent chaque service ainsi que les obligations et responsabilités des parties prenantes. Chaque service est composé de processus : la plupart des processus sont liés à des appels API spécifiques spécifiés dans la section [Spécification Open API](#_1-2-specification-open-api) de ce document.
+
+## 2. Le service de recherche de compte
+
+### 2.1 Description du service de recherche de compte 
+
+- Le service de recherche de compte permet aux DFSP de faire correspondre des identifiants spécifiques pour des clients individuels au DFSP qui fournit un compte de transaction pour ce client. Les identifiants sont utilisés pour identifier des individus, commerçants, émetteurs de factures, agences gouvernementales ou autres entreprises. Tout type d'identifiant pris en charge par le schéma dispose d'un service d'identifiant défini, dont les paramètres sont indiqués dans la section « Identifiants pris en charge par le schéma » de ce document.
+
+- Tous les services d'identifiant garantissent que les identifiants utilisés pour les transactions du schéma sont uniques au sein du schéma et sont associés à un seul DFSP qui fournit le compte de transaction pertinent pour ce client. Tout identifiant doit être associé à un seul compte de transaction.
+
+- Les DFSP doivent compléter le processus de recherche de compte immédiatement avant d'initier un processus de devis, sauf autorisation contraire dans ces directives.
+
+### 2.2 Requête de partie
+
+- Une requête de partie est envoyée par un DFSP payeur à la plateforme. La requête de partie doit contenir les éléments de données clés suivants :
+
+    - L'identifiant du bénéficiaire prévu
+
+    - L'identifiant du DFSP payeur
+
+Le schéma peut définir des éléments de données clés supplémentaires qui seront requis dans la requête de partie.
+
+- La requête est transmise de la plateforme au service de recherche de compte pour ce type d'identifiant.
+
+- Le service d'identifiant renvoie au service de recherche de compte l'identification du DFSP associé à cet identifiant, si une référence est trouvée. Si ce n'est pas le cas, une réponse négative est renvoyée et cela est communiqué par la plateforme au DFSP payeur. Si une référence est trouvée, le service de recherche de compte associe alors le DFSP identifié à l'identifiant DFSP correct du schéma.
+
+### 2.3 Requête Parties
+
+- Si la requête de partie réussit à identifier un DFSP bénéficiaire, la plateforme exécute alors une requête Parties au DFSP identifié pour déterminer si le DFSP est disposé à accepter une demande de devis dirigée vers cet identifiant.
+
+### 2.4 Réponse à la requête Parties
+
+- Le DFSP identifié répond soit avec une réponse positive à la requête Parties, soit avec une réponse d'erreur. Si positive, la réponse à la requête Parties doit contenir les éléments de données clés suivants :
+
+    - Le nom complet du bénéficiaire
+
+    - L'identifiant du DFSP payeur
+
+    - Le type de compte de transaction, qui précise si le compte est un compte bancaire ou un portefeuille
+
+    - Le type de titulaire du compte de transaction, qui précise si le titulaire du compte de transaction est un consommateur, un commerçant (y compris d'autres types d'entreprises) ou une agence gouvernementale.
+
+    - Si le bénéficiaire est un commerçant, le code de catégorie de commerçant. Ces codes se trouvent dans une annexe à ce document.
+
+Le schéma peut définir des éléments de données supplémentaires requis dans la réponse à la requête Parties.
+
+-   La plateforme répond au DFSP payeur avec le résultat de la réponse à la requête Parties
+
+## 3. Le service de devis
+
+#### 3.1 Description du service de devis
+
+- Le processus de devis précède le processus de transfert et permet au DFSP payeur et au DFSP bénéficiaire d'échanger certaines informations avant le transfert.
+
+- Le processus de devis doit être complété avant qu'un DFSP payeur n'initie le processus de transfert. Cela est vrai pour tous les cas d'utilisation et cas d'utilisation secondaires.
+
+- Les étapes du processus de devis sont présentées ci-dessous.
+
+#### 3.2 Demande de devis 
+
+- Une demande de devis est envoyée par un DFSP payeur au DFSP bénéficiaire ; la demande de devis est enregistrée par la plateforme. La demande de devis doit contenir les éléments de données clés suivants :
+
+    - Le montant du transfert
+
+    - Le type de montant défini comme montant d'envoi.
+
+    - L'ensemble complet des informations de partie renvoyées par la réponse à la requête Parties.
+
+    - Le nom complet du payeur (le titulaire du compte de transaction au DFSP payeur)
+
+    - Les données de type de transaction requises pour le cas d'utilisation et le cas d'utilisation secondaire de la transaction, comme spécifié dans l'annexe des cas d'utilisation de ce document.
+
+    - Un délai d'expiration, dont les paramètres autorisés seront spécifiés par le schéma de temps à autre.
+
+Le schéma peut définir des éléments de données clés supplémentaires qui seront requis dans la réponse à la requête Parties.
+
+- Une demande de devis pour un montant supérieur à la limite de valeur de transaction du schéma sera rejetée par la plateforme et renvoyée au DFSP payeur.
+
+### 3.3 Réponse au devis
+
+- Une réponse au devis est envoyée par le DFSP bénéficiaire au DFSP payeur ; la réponse au devis est enregistrée par la plateforme. Le DFSP bénéficiaire est tenu de répondre à une demande de devis.
+
+- La réponse au devis doit contenir les éléments de données clés suivants :
+
+    - Le montant du transfert
+
+    - Un délai d'expiration, dont les paramètres autorisés seront spécifiés par le schéma de temps à autre.
+
+    - L'objet de transaction signé qui contient les paramètres du transfert. L'objet de transaction est la description faisant autorité de la transaction aux fins du reporting du schéma, de la gestion de la fraude et de la résolution des litiges.
+
+Le schéma peut définir des éléments de données clés supplémentaires qui seront requis dans la réponse à la requête Parties.
+
+- La réponse au devis est signée par le DFSP bénéficiaire et définit les paramètres de la transaction ; le DFSP payeur ne peut pas modifier ces paramètres dans le processus de transfert.
+
+## 4. Le service de transfert
+
+### 4.1 Description du service de transfert
+
+- Le service de transfert est le moyen par lequel le transfert effectif de fonds est accompli entre le DFSP payeur et le DFSP bénéficiaire. La demande de transfert est le processus clé au sein du service. Une demande de transfert doit être précédée d'un processus de devis.
+
+### 4.2 Demande de transfert
+
+- Une demande de transfert est envoyée par un DFSP payeur au DFSP bénéficiaire via le service de transfert du schéma. La plateforme enregistre la demande de transfert. La demande de transfert doit contenir les éléments de données clés suivants :
+
+    - Les identifiants du DFSP payeur et du DFSP bénéficiaire
+
+    - Le montant de la transaction
+
+    - Un paquet ILP représentant l'objet de transaction
+
+    - Un délai d'expiration, dont les paramètres autorisés seront spécifiés par le schéma de temps à autre.
+
+Le schéma peut définir des éléments de données clés supplémentaires qui seront requis dans la demande de transfert.
+
+- La demande de transfert est signée par le DFSP payeur
+
+- La plateforme effectue un processus d'approbation de transfert pour déterminer si le transfert proposé peut être réglé. Le processus d'approbation de transfert est défini plus en détail dans la section du service de règlement de ce document.
+
+- Si la demande de transfert échoue au processus d'approbation de transfert, la demande de transfert est renvoyée au DFSP payeur.
+
+- Si la demande de transfert réussit le processus d'approbation de transfert, la plateforme réserve les fonds spécifiés dans la demande de transfert dans le grand livre de position du DFSP payeur. Cela est défini plus en détail dans la section du service de règlement de ce document.
+
+- Le DFSP bénéficiaire détermine s'il acceptera le transfert.
+
+- S'il n'est pas accepté, une réponse d'erreur est renvoyée à la plateforme. La plateforme libère la réservation de fonds dans le grand livre de position du DFSP payeur et renvoie une condition d'erreur au DFSP payeur.
+
+- S'il est accepté, le DFSP bénéficiaire renvoie une réponse de transfert signée indiquant que le transfert a été exécuté. La plateforme remplace le débit provisoire par un débit dans le grand livre de position du DFSP payeur et crédite le grand livre de position du DFSP bénéficiaire d'un crédit du montant du transfert.
+
+- La plateforme envoie ensuite une confirmation du transfert exécuté au DFSP payeur et au DFSP bénéficiaire.
+
+- Si la plateforme ne reçoit pas de réponse de transfert signée dans le délai d'expiration de la demande de transfert, le transfert sera annulé et le schéma en informera les DFSP bénéficiaire et payeur.
+
+- Les DFSP payeurs et bénéficiaires sont tenus :
+
+    - De notifier leurs clients de l'état d'un transfert en temps opportun
+
+    - De débiter et créditer immédiatement les comptes de transaction de leurs clients lors de l'exécution du transfert
+
+    - De libérer immédiatement tout fonds réservé si un transfert a été refusé ou annulé
+
+### 4.3 Demande de paiement 
+
+_Cette section n'a pas encore été rédigée._
+
+## 5. Le service de règlement
+
+Ce document présente un modèle pour les processus de règlement tant pour les transferts que pour les frais du schéma. Il existe de multiples approches possibles pour le règlement, qui sont discutées dans le document « Choix clés » qui fait partie de ce projet. Le modèle ci-dessous couvre deux modèles : le règlement net et le règlement brut continu. Le code de référence Mojaloop prend en charge un certain nombre de modèles de règlement différents, y compris ceux-ci.
+
+### 5.1 Règlement des transferts 
+
+#### 5.1.1 Description du service de règlement des transferts
+
+- Le règlement des transferts est le moyen par lequel les DFSP règlent leurs obligations financières les uns envers les autres. Il y a cinq processus dans le règlement des transferts : le processus de grand livre, le processus de plafond de débit net, le processus d'approbation de transfert, le processus de comptabilisation du règlement et le processus de gestion du compte de règlement.
+
+- \[_Option de règlement net_\] Les DFSP sont tenus d'ouvrir un compte bancaire de règlement auprès de la banque de règlement du schéma. \[_Option de règlement brut continu_\] Les DFSP sont tenus de devenir copropriétaires du compte bancaire de règlement mutualisé du schéma auprès de la banque de règlement du schéma, et d'utiliser ou d'ouvrir tout autre compte bancaire individuel auprès de la banque de règlement du schéma si nécessaire pour transférer des fonds vers et depuis le compte bancaire de règlement mutualisé du schéma.
+
+#### 5.1.2 Le grand livre de la plateforme 
+
+- La plateforme est responsable du maintien d'un grand livre de position DFSP pour chaque DFSP. Cette opération fonctionne en continu. \[_Option de règlement brut continu_\] Le grand livre de position DFSP de chaque DFSP, moins les écritures provisoires, représente la part de propriété de ce DFSP dans le compte bancaire de règlement mutualisé du schéma.
+
+- Le grand livre de position enregistre :
+
+    - Tous les transferts exécutés comme débits dans le grand livre du DFSP payeur et crédits dans le grand livre du DFSP bénéficiaire
+
+    - Toutes les demandes de transfert comme débits provisoires dans le grand livre du DFSP payeur. Ces débits provisoires sont supprimés lorsque le transfert est exécuté, refusé par le DFSP bénéficiaire ou expire.
+
+    - \[_Option de règlement net uniquement_\] Les écritures de règlement livrées et acceptées par la banque de règlement du schéma pour ce DFSP.
+
+    - \[_Option de règlement brut continu uniquement_\] Les transferts vers et depuis le compte bancaire de règlement mutualisé du schéma effectués par les DFSP.
+
+- La position du grand livre DFSP est la somme de tous les éléments énumérés ci-dessus. Cela est utilisé dans le processus d'approbation de transfert.
+
+#### 5.1.3 Processus de plafond de débit net
+
+- Le plafond de débit net d'un DFSP est une valeur que la plateforme utilise pendant le processus d'approbation de transfert. Le débit net d'un DFSP est la somme de :
+
+    - \[_Option de règlement net uniquement_\] Une valeur fixée par le schéma qui est destinée à représenter les fonds que le DFSP a disponibles sur son compte bancaire de règlement
+
+Notez que le schéma peut être en mesure d'automatiser le calcul de la valeur décrite ci-dessus, ou il peut choisir de la saisir manuellement dans la section Opérateur de la plateforme du portail du schéma.
+
+- La marge du schéma pour ce DFSP. Il s'agit d'une valeur, déterminée par le schéma, qui est spécifique à un DFSP donné. Cette valeur peut être un pourcentage de la position du grand livre DFSP ou peut être une valeur absolue. Le schéma peut modifier la marge du schéma pour tout DFSP à sa discrétion. Elle peut avoir pour effet d'augmenter ou de diminuer la capacité d'un DFSP à exécuter des transactions.
+
+- La marge discrétionnaire du DFSP. Il s'agit d'une valeur, déterminée par un DFSP individuel, qui diminue la valeur absolue du plafond de débit net. La marge discrétionnaire du DFSP est fixée dans les paramètres autorisés définis par le schéma. Cela a pour effet de diminuer la capacité du DFSP à exécuter des transactions.
+
+#### 5.1.4 Processus d'approbation de transfert 
+
+- Approbation de transfert. Lorsque la plateforme reçoit une demande de transfert d'un DFSP payeur, la plateforme approuvera ou rejettera la demande sur la base d'une comparaison du montant du transfert demandé avec la position actuelle du grand livre du DFSP payeur moins le plafond de débit net du DFSP payeur.
+
+- Si le transfert demandé est inférieur à cette somme, la plateforme transmettra la demande au DFSP bénéficiaire. S'il est supérieur à la valeur du plafond de débit net, la plateforme rejettera la demande et la renverra au DFSP payeur.
+
+#### 5.1.5 Processus de comptabilisation du règlement
+
+- \[_Option de règlement net uniquement_\] Le schéma définira les paramètres des fenêtres de règlement utilisées pour le schéma ; cela inclura la fréquence des fenêtres ou d'autres paramètres (limites de valeur, etc.) choisis pour définir les fenêtres de règlement.
+
+- \[_Option de règlement net uniquement_\] À la fin de chaque fenêtre de règlement définie, la plateforme calculera la position nette de règlement de chaque DFSP : cette position est le solde du grand livre de position DFSP. Ces soldes deviennent les écritures de règlement pour cette fenêtre.
+
+- \[_Option de règlement net uniquement_\] La plateforme enverra les écritures de règlement pour chaque DFSP à la banque de règlement choisie par le schéma.
+
+- \[_Option de règlement net uniquement_\] La banque de règlement comptabilisera les écritures de règlement sur le compte bancaire de règlement de chaque DFSP, et enverra une confirmation à la plateforme de l'achèvement de ce processus.
+
+Les règles du schéma devront tenir compte des dispositions et procédures en cas d'échec du processus décrit ci-dessus.
+
+#### 5.1.6 Processus de gestion du compte de règlement
+
+- \[_Option de règlement net_\] Les DFSP peuvent ajouter des fonds à leur compte bancaire de règlement du schéma à leur discrétion. Le schéma fournira des instructions sur la manière de procéder. \[_Option de règlement brut continu_\] Les DFSP peuvent transférer des fonds vers le compte bancaire de règlement mutualisé du schéma à leur discrétion. Le schéma fournira des instructions sur la manière de procéder.
+
+- \[_Option de règlement brut continu uniquement_\] Le schéma fournira un rapport de fin de journée aux DFSP montrant leur part de propriété dans le compte bancaire de règlement mutualisé du schéma.
+
+- Les DFSP peuvent demander le retrait de fonds de leur \[_Option de règlement net_\] compte bancaire de règlement via le portail du schéma. \[_Option de règlement brut continu_\] Les DFSP peuvent demander le retrait de fonds du compte bancaire de règlement mutualisé du schéma via le portail du schéma. Le schéma examinera le retrait demandé et, s'il est approuvé, exécutera le transfert pour le compte du DFSP. L'objectif de cet examen est de s'assurer que la part du DFSP dans le compte bancaire de règlement est suffisante pour prendre en charge les transferts en cours : cette approbation ne sera pas refusée de manière déraisonnable.
+
+#### 5.1.7 Rapports de règlement du schéma 
+
+- Le schéma fournira, via le portail DFSP du schéma, des informations aux DFSP qui incluent pour chaque DFSP :
+
+    - Le plafond de débit net actuel et ses composantes
+
+    - La position actuelle du grand livre et ses composantes, y compris les transferts exécutés pour tous les DFSP et les transferts provisoires pour les DFSP payeurs
+
+    - Des alertes à certains niveaux de la position actuelle du grand livre : ces niveaux seront déterminés par les DFSP et/ou le schéma de temps à autre
+
+- Des outils pour permettre aux DFSP de prévoir leur volume de transfert anticipé sur la base de données historiques
+
+### 5.2 Règlement des frais : frais de traitement
+
+Cette section n'a pas encore été rédigée.
+
+### 5.3 Règlement des frais : frais d'interchange
+
+Cette section n'a pas encore été rédigée.
+
+## 6. Le service de gestion du schéma
+
+::: tip NOTE
+Il existe un service parallèle d'opérateur de plateforme nécessaire au fonctionnement de la plateforme qui n'est pas décrit dans ce document.
+:::
+
+### 6.1 Description du service de gestion du schéma
+
+- Le service de gestion du schéma est fourni par le schéma pour aider les DFSP dans leur utilisation des services du schéma. Bon nombre de ces fonctions sont fournies via le portail du schéma, qui est mis à la disposition des DFSP du schéma.
+
+- Les processus suivants font partie du service de gestion du schéma :
+
+### 6.2 Le processus d'inscription
+
+- Le processus d'inscription permet la demande de participation d'un DFSP et l'intégration opérationnelle et technique. Il couvre les domaines suivants :
+
+    - Formulaires et processus de demande de participation d'un DFSP au schéma.
+
+    - Formulaires et processus d'obtention de certificats numériques et de signatures numériques pour une utilisation avec la plateforme.
+
+    - Processus de téléchargement des artefacts logiciels fournis par le schéma, y compris les SDK et les API.
+
+    - Processus de test de la préparation technique pour accéder à la plateforme et aux services.
+
+    - Processus de réception de l'approbation et de la certification du schéma pour l'accès à la plateforme et aux services.
+
+### 6.3 Service client DFSP
+
+- Le schéma fournira un service d'assistance en ligne et téléphonique pour les DFSP.
+
+- Le portail du schéma fournira des moyens par lesquels les DFSP peuvent désigner des administrateurs et des utilisateurs du portail, et mettre à jour les informations du profil DFSP.
+
+### 6.4 Gestion du système du schéma
+
+- Le schéma fournira, via le portail du schéma, des moyens par lesquels les DFSP peuvent consulter leur grand livre de position actuel, leur plafond de débit net et leur activité récente et historique avec le schéma.
+
+- Le schéma fournira, via le portail du schéma, des moyens par lesquels les DFSP peuvent utiliser les données historiques, y compris leurs positions et historiques de plafond de débit net, pour prévoir les volumes à venir et les niveaux de financement de règlement requis.
+
+- Le schéma fournira des moyens par lesquels les DFSP peuvent obtenir des mises à jour des artefacts logiciels qu'ils ont précédemment téléchargés.
+
+- Le schéma fournira, via le portail du schéma, des moyens par lesquels les DFSP peuvent demander un retrait de leur part du compte bancaire de règlement du schéma.
+
+- Le schéma fournira, via le portail du schéma, des moyens par lesquels les DFSP peuvent consulter leur part du solde du compte bancaire de règlement du schéma.
+
+## 7. Le service de gestion de la fraude
+
+_Cette section n'a pas encore été rédigée, mais devrait inclure les sections suivantes :_
+    
+1. _Description de l'utilitaire de gestion de la fraude — Objet et portée_
+
+2. _La base de données de transactions partagée_
+
+3. _Schéma de catégorisation de la fraude_
+
+4. _Signalement des acteurs ou transactions connus comme malveillants_
+
+5. _Algorithmes et processus de détection des anomalies et de la fraude_
+
+6. _Rapports DFSP_
+
+7. _Options d'interception de transactions en temps réel_
+
+## 8. Annexe : Cas d'utilisation pris en charge par le schéma et paramètres système
+
+_Il s'agit du même tableau que celui qui apparaît dans le document des règles commerciales, mais il a ajouté les codes systémiques nécessaires pour que la plateforme reconnaisse une transaction comme appartenant à un cas d'utilisation ou un cas d'utilisation secondaire donné. Un schéma ne définirait des cas d'utilisation secondaires que s'il souhaitait rédiger des règles et/ou spécifier des frais propres à ce cas d'utilisation secondaire._
+
+_Ce tableau est un exemple de tableau de cas d'utilisation et de cas d'utilisation secondaires qu'un schéma pourrait prendre en charge._
+
+| Code du cas d'utilisation | Cas d'utilisation | Cas d'utilisation secondaire | Éléments de données requis | Autres méthodes de détermination du cas d'utilisation |
+| :--- | :----- | :--------- | :-------------------------- | :------------------------------------------- |
+| 1.0  | P2P  | Personne à personne | Paramètre API <br>Scenario=Transfer</br> <br>Initiator = Payer</br> <br>Initiator Type = Consumer</br> <br>Recipient Type = Consumer</br> | |
+| 1.1 | P2P | Portefeuille à portefeuille | Le type de compte de transaction pour le DFSP payeur est Portefeuille et pour le DFSP bénéficiaire est Portefeuille |
+| 1.2 | P2P | Banque à banque | Le type de compte de transaction pour le DFSP payeur est Banque et pour le DFSP bénéficiaire est Portefeuille |
+| 1.3 | P2P | Portefeuille à banque | Le type de compte de transaction pour le DFSP payeur est Portefeuille et pour le DFSP bénéficiaire est Banque |
+| 1.4 | P2P | Banque à portefeuille | Le type de compte de transaction pour le DFSP payeur est Banque et pour le DFSP bénéficiaire est Portefeuille. |
+| 2.0 | Paiement en masse | | Paramètres API <br>Scenario=Transfer</br> <br>Initiator = Payer</br> <br>Recipient Type = Consumer</br> |
+| 2.1 | B2P | Banque à banque | Initiator Type = Business |
+| 2.2 | G2P | Gouvernement à personne | Initiator Type = Government |
+| 3.0 | P2B | Personne à entreprise | Paramètres API <br>Scenario=Transfer</br> <br>Initiator = Payer</br> <br>Initiator Type = Consumer</br> <br>Recipient Type = Business</br> |
+| 3.1 | P2B | Achat par numéro de caisse | Initiator Type = Device | |
+| 3.2 | P2B | Achat par code QR | à déterminer | |
+| 3.3 | P2B | Achat en ligne | Merchant ID Code = à déterminer | |
+| 3.4 | P2B | Paiement de facture | | à déterminer : un élément de données dans la demande de devis inclura le numéro de compte du payeur chez l'émetteur de factures |
+| 3.5 | P2B | Personne à entreprise - Autre | | | 
+| 4.0 | P2G | | Paramètres API <br>Scenario=Transfer</br> <br>Initiator = Payer</br> <br>Recipient Type = Government</br> | 
+| 4.1 | P2G | Personne à gouvernement | | |
+| 4.1 | P2G | Achat par numéro de caisse | Initiator Type = Device | |
+| 4.2 | P2G | Achat par code QR | à déterminer | |
+| 4.3 | P2G | Achat en ligne | Merchant ID Code = à déterminer | |
+| 4.4 | P2G | Paiement de facture | | à déterminer : un élément de données dans la demande de devis inclura le numéro de compte du payeur chez l'émetteur de factures |
+
+## 9. Annexe : Codes de catégorie de commerçants
+
+_Le schéma voudra spécifier des codes pour reconnaître le type de commerçant payé. Le terme « commerçant » est ici utilisé au sens large pour inclure tous les types d'accepteurs de paiements non-consommateurs. Un système de codes de catégorie de commerçants pourrait vouloir reconnaître les industries, les domaines (magasins en personne vs à distance ou en ligne) et/ou la taille des commerçants._
diff --git a/docs/fr/adoption/Scheme/scheme-business-rules.md b/docs/fr/adoption/Scheme/scheme-business-rules.md
new file mode 100644
index 00000000..48ae1621
--- /dev/null
+++ b/docs/fr/adoption/Scheme/scheme-business-rules.md
@@ -0,0 +1,525 @@
+# Modèle de règles commerciales du schéma
+
+- Version : 4.0 
+    - Auteur : Carol Coye Benson (Glenbrook)
+    - Date : Octobre 2019
+    - Description :     
+
+---
+
+## **À propos du projet de documents commerciaux de la communauté Mojaloop**
+
+Ce document fait partie du projet de documents commerciaux de la communauté Mojaloop. Le projet est destiné à soutenir les entités (pays, régions, associations de fournisseurs ou entreprises commerciales) mettant en œuvre de nouveaux systèmes de paiement utilisant le code Mojaloop. Ces entités devront également rédiger des règles commerciales que les participants au système suivront.
+
+Le projet de documents commerciaux de la communauté Mojaloop fournit des modèles pour les règles commerciales et les documents associés. De nombreux choix sont impliqués dans la mise en œuvre d'un nouveau système de paiement : les modèles présentent certains de ces choix et, le cas échéant, des commentaires sont fournis sur la manière dont le choix particulier est lié aux objectifs d'un système aligné sur Level One.
+
+Les documents suivants font partie du projet :
+
+- Choix clés du schéma
+
+- Modèle d'accord de participation au schéma
+
+- Modèle de règles commerciales du schéma
+
+- Modèle de directive opérationnelle de la plateforme
+
+- Modèle de directive opérationnelle de gestion des exceptions
+
+- Glossaire uniforme
+
+## **Introduction**
+
+Des schémas de paiement à travers le monde sont en cours de mise en œuvre, ou envisagent la mise en œuvre, de systèmes de paiement basés sur Mojaloop. Mojaloop est un logiciel open source pour les sociétés de services financiers, les régulateurs gouvernementaux et d'autres acteurs relevant les défis de l'interopérabilité et de l'inclusion financière. La Fondation Bill & Melinda Gates a fourni un financement et un soutien pour Mojaloop à travers le Level One Project, une vision pour les marchés financiers numériques basée sur les principes d'interopérabilité, de collaboration et d'inclusion.
+
+Les schémas mettant en œuvre Mojaloop devront rédiger des règles commerciales qui régissent les droits et responsabilités des participants au système. Ce document fournit un modèle pour ces règles commerciales. Le modèle est structuré sous forme de plan détaillé : la formulation réelle des règles sera déterminée par les schémas qui les mettent en œuvre et les juridictions dans lesquelles ils opèrent. Dans de nombreuses parties du document, nous suggérons simplement un sujet sur lequel un schéma pourrait vouloir envisager de rédiger une règle : encore une fois, les spécificités de la règle varieront selon le schéma.
+
+Avant la rédaction des règles commerciales, les schémas doivent prendre des décisions commerciales majeures sur le fonctionnement du système et de ses partenaires de l'écosystème. Ces décisions sont décrites dans un document séparé au sein du projet de documents commerciaux de la communauté Mojaloop, « Choix clés du schéma ». Les lecteurs sont encouragés à lire ce document en premier.
+
+Modèle de règles commerciales du schéma
+
+## **Table des matières**
+
+[1 - À propos de ces règles commerciales du schéma](#_1-a-propos-de-ces-regles-commerciales-du-schema)
+
+[2 - Objectifs du schéma](#_2-objectifs-du-schema)
+
+[3 - Participation au schéma](#_3-participation-au-schema)
+
+[4 - Règles commerciales du schéma](#_4-regles-commerciales-du-schema)
+
+[5 - Responsabilités et obligations du schéma](#_5-responsabilites-et-obligations-du-schema)
+
+[6 - Responsabilités et obligations des participants](#_6-responsabilites-et-obligations-des-participants)
+
+[7 - Responsabilité - Répartition des responsabilités](#_7-responsabilite-repartition-des-responsabilites)
+
+[8 - Sécurité, gestion des risques et confidentialité des données](#_8-securite-gestion-des-risques-et-confidentialite-des-donnees)
+
+[9 - Plateforme et services du schéma](#_9-plateforme-et-services-du-schema)
+
+[10 - Gestion des exceptions](#_10-gestion-des-exceptions)
+
+[11 - Annexe : Documents associés](#_11-annexe-documents-associes)
+
+[12 - Annexe : Processus d'intégration et de sortie](#_12-annexe-processus-d-integration-et-de-sortie)
+
+[13 - Annexe : Services du schéma](#_13-annexe-services-du-schema)
+
+[14 - Annexe : Cas d'utilisation pris en charge par le schéma](#_14-annexe-cas-d-utilisation-pris-en-charge-par-le-schema)
+
+[15 - Annexe : Grille tarifaire du schéma](#_15-annexe-grille-tarifaire-du-schema)
+
+[16 - Annexe : Gestion des risques, sécurité, confidentialité et normes de service](#_16-annexe-gestion-des-risques-securite-confidentialite-et-normes-de-service)
+
+## **Guide de ce document**
+
+Les titres de section et les entrées à puces sous les titres de section sont des formulations réellement proposées, ou des sections suggérées pour un document de règles. Le texte en italique constitue des commentaires qui peuvent être utilisés lorsqu'un schéma rédige la formulation réelle d'un document de règles.
+
+## 1. À propos de ces règles commerciales du schéma
+
+### 1.1 Ceci constitue les règles commerciales du schéma
+
+::: tip NOTE
+Le logiciel Mojaloop peut être utilisé pour des échanges bilatéraux entre DFSP, ainsi que dans une structure de schéma qui utilise un commutateur. Ce document suppose cette dernière option ; que le schéma fournit, engage ou organise autrement l'échange de transactions interopérables via un commutateur. Certains concepts de ces règles ne s'appliquent qu'à cette configuration ; d'autres seraient utiles dans des accords bilatéraux également.
+:::
+
+### 1.2 Propriété du schéma 
+
+<ul><i>Qui est propriétaire du schéma, quelles sont les possibilités de participation à la propriété. Référence à d'autres documents (charte, statuts, etc.)</i></ul>
+
+### 1.3 Documents associés définis
+
+- Ces règles incluent les documents associés répertoriés dans une annexe à ces règles. Les documents associés font partie des règles opérationnelles et ont la force de celles-ci.
+
+<ul><i>Les documents associés devraient inclure la directive opérationnelle de la plateforme et le glossaire uniforme. Cela n'inclut pas les divers documents techniques qui peuvent être référencés dans les règles commerciales ou la directive opérationnelle de la plateforme.</i></ul>
+
+### 1.4 Les règles commerciales du schéma sont contraignantes pour les participants
+
+<ul><i>Cela répète la disposition de l'accord de participation au schéma. Notez que les règles commerciales du schéma ne sont contraignantes que pour les DFSP qui participent au schéma. Le schéma peut rédiger des règles exigeant que certaines dispositions de ces règles soient transmises aux clients des participants (par exemple, les commerçants) ou aux partenaires (par exemple, les processeurs) - mais il s'agit d'une obligation du participant envers le schéma, et non des autres parties.</i></ul>
+
+### 1.5 Les règles peuvent être modifiées
+
+<ul><i>Les détails du processus de modification sont spécifiés ailleurs.</i></ul>
+
+### 1.6 Les termes sont définis dans le glossaire uniforme
+
+<ul><i>Le glossaire est un document séparé, plutôt qu'interne au document des règles commerciales. Cela permet d'assurer la cohérence de la terminologie à mesure que le service évolue et que la directive opérationnelle de la plateforme change.</i></ul>
+
+## 2. Objectifs du schéma
+
+<ul><i>Il s'agit d'une section qui permet à un schéma d'énoncer les objectifs du schéma. Nous suggérons le soutien aux transactions financières interopérables, l'inclusion financière et l'égalité des genres. C'est également l'occasion de référencer le soutien aux principes de conception du Level One Project, une stratégie nationale ou régionale de paiement (ou stratégie d'économie numérique), ou un ensemble de principes de conception spécifiques au schéma.</i></ul>
+
+## 3. Participation au schéma
+
+### 3.1 Éligibilité à la participation
+
+- Critères d'éligibilité
+
+<ul><i>Une déclaration indiquant quels types d'institutions sont éligibles pour postuler comme participant au schéma. Le principe de conception Level One est que tout fournisseur autorisé de comptes de transaction dans une juridiction couverte par le schéma devrait être éligible pour postuler.</i></ul>
+
+- Critères d'approbation
+
+<ul><i>Dispositions du schéma pour l'acceptation des candidatures, y compris des déclarations de haut niveau sur les informations requises du candidat, telles que la démonstration d'une capacité durable à respecter les obligations financières et les obligations de conformité. Le processus de candidature réel figure dans une annexe à ces règles. Les exigences de certification technique peuvent être répertoriées dans la directive opérationnelle de la plateforme.</i></ul>
+
+### 3.2 Licence
+
+<ul><i>Ce concept peut ou non s'appliquer lorsque l'opérateur du schéma est une entité gouvernementale. Si le concept de licence n'est pas inclus dans les règles, il doit y avoir une disposition dans la section « Éligibilité à la participation » concernant la résiliation d'un participant.</i></ul>
+
+- Un participant se voit accorder une licence pour participer au schéma et utiliser la propriété du schéma conformément aux règles commerciales du schéma.
+
+- Un participant ne peut utiliser la propriété du schéma que conformément aux règles commerciales du schéma. Les licences limiteront l'utilisation de la propriété du schéma à la fourniture de services par le participant en lien avec le schéma et conformément aux règles.
+
+- Les licences ne seront pas exclusives.
+
+### 3.3 Accès par paliers
+
+<ul><i>Les schémas peuvent choisir de permettre à certains candidats de rejoindre le schéma en tant que participants indirects. Cette section précise les conditions pour cela. Certains schémas permettent séparément la participation technique indirecte et la participation indirecte au règlement.</i></ul>
+
+<ul><i>Si cela est autorisé, des termes définis (tels que banque sponsor et participant indirect) sont requis. Cette section doit clairement montrer quelles sont les obligations de chaque partie ; cela peut faire référence aux sections d'obligations apparaissant ultérieurement.</i></ul>
+
+### 3.4 Départ de la participation
+
+<ul><i>Dispositions pour la suspension ou la résiliation par le schéma de la participation d'un participant au schéma. Le schéma peut suspendre, limiter ou exclure un participant de la participation au schéma s'il détermine que l'incapacité du participant à respecter une règle constitue une charge excessive pour le schéma ou les autres participants ou pose des risques excessifs pour l'intégrité du schéma ou la réputation du schéma.</i></ul>
+
+<ul><i>Dispositions permettant aux participants de mettre fin à leur participation au schéma.</i></ul>
+
+## 4. Règles commerciales du schéma
+
+### 4.1 Portée des règles commerciales du schéma
+
+- Ces règles s'appliquent à chaque participant et régissent les droits et responsabilités des participants et du schéma.
+
+- Ces règles peuvent être remplacées dans la mesure où elles entrent en conflit avec toute loi applicable. Rien dans ces règles ne sera appliqué de manière à exiger que le schéma ou tout participant viole la loi applicable.
+
+- Toutes les questions relatives à l'interprétation des règles et tous les litiges découlant de la participation au schéma seront soumis aux lois de \[xxxx\]
+
+<ul><i>Des dispositions devraient être prises pour la résolution des litiges entre participants ou entre les participants et le schéma.</i></ul>
+
+### 4.2 Modifications des règles commerciales du schéma
+
+- Les participants peuvent de temps à autre fournir des suggestions ou des demandes de modification des règles.
+
+- Les suggestions des participants pour des modifications des règles peuvent être utilisées par le schéma ou par d'autres participants en lien avec le schéma sans compensation ni attribution au participant qui fait la suggestion ou la demande.
+
+- Les modifications des règles seront effectuées selon une procédure consultative :
+
+- Un ou plusieurs participants ou le schéma peuvent proposer une modification des règles commerciales du schéma.
+
+- Le schéma publiera les propositions à tous les participants et demandera des commentaires et suggestions à ce sujet ; tous les commentaires reçus seront publiés à tous les participants.
+
+- Le schéma peut inclure, avec la publication d'un changement proposé, sa suggestion déterminée de manière indépendante pour la formulation d'un changement dans les règles.
+
+<ul><i>Le schéma devrait avoir un processus défini pour l'adoption des changements, qui peut inclure le vote des participants ou une décision du schéma. S'il y a un vote, les règles ici devraient spécifier les paramètres.</i></ul>
+
+- Le schéma peut accorder des dérogations aux règles sur demande des participants.
+
+- Des dispositions pour des changements urgents peuvent être prises par le schéma pour répondre à des risques ou des exigences réglementaires.
+
+## 5. Responsabilités et obligations du schéma
+
+### 5.1 Définition et fourniture des services du schéma
+
+- Le schéma définit l'ensemble des services du schéma qui sont fournis aux participants. La liste définie des services du schéma est présentée dans une annexe à ces règles.
+
+<ul><i>Services du schéma</i></ul>
+
+- Le schéma précise comment les services du schéma sont fournis aux participants - ils peuvent être exploités par l'entité du schéma, par une autre entité sous contrat avec le schéma, ou il peut y avoir un autre arrangement. Cette section donne au schéma le droit de définir de nouveaux services, de modifier les services existants, etc.
+
+- Le schéma peut définir des normes de niveau de service pour lui-même et pour les participants dans l'utilisation de ces services.
+
+- Pour les services de plateforme externalisés, le schéma spécifie les services à fournir. Le schéma peut spécifier les accords de niveau de service pour les fournisseurs de ces services.
+
+- Pour le service de règlement du schéma, le schéma sélectionne et contracte avec une ou plusieurs banques de règlement pour le règlement inter-participants.
+
+- Le schéma établit une limite de valeur de transaction qui fixe la valeur maximale de tout transfert effectué via la plateforme du schéma. Les DFSP peuvent fixer des valeurs inférieures pour leurs clients.
+
+- Le schéma devrait examiner s'il garantira au DFSP bénéficiaire tout transfert exécuté conformément à ces règles.
+
+<ul><i>Le schéma devrait examiner s'il garantira au DFSP bénéficiaire tout transfert exécuté conformément à ces règles.</i></ul>
+
+### 5.2 Rédaction, mise à jour et maintenance des règles
+
+- Le schéma rédige, met à jour et maintient les règles commerciales.
+
+- Le schéma est responsable d'informer les participants de toute modification des règles, de tous les frais, des politiques susceptibles d'affecter l'utilisation du schéma par les participants, ou de toute autre information importante et pertinente.
+
+- Le schéma est responsable de l'établissement d'une politique, et de sa communication aux participants, pour l'application des règles.
+
+- Le schéma est responsable de l'établissement de politiques concernant l'octroi de dérogations aux règles aux participants.
+
+### 5.3 Autres responsabilités du schéma
+
+- Le schéma administre les processus d'intégration et de sortie des participants. Ces processus sont répertoriés dans une annexe à ces règles.
+
+- Le schéma surveille l'éligibilité continue des participants selon les exigences établies pour la participation.
+
+- Le schéma définit un ensemble de cas d'utilisation et de cas d'utilisation secondaires. Ceux-ci sont répertoriés dans une annexe à ces règles.
+
+- Le schéma établit la grille tarifaire et définit les processus par lesquels les frais sont collectés. La grille tarifaire figure dans une annexe à ces règles.
+
+- Le schéma définit la marque du schéma et établit des directives pour son utilisation. Ces directives figurent dans un document associé.
+
+- Le schéma mesure la progression du schéma et de ses participants.
+
+- Le schéma définit des politiques et procédures en matière de sécurité, de gestion des risques et de confidentialité des données pour le schéma et ses participants.
+
+- Le schéma définit des politiques et procédures pour la gestion des exceptions de transaction.
+
+- Le schéma entreprend des activités pour promouvoir et encourager l'adoption et l'utilisation du schéma.
+
+- Le schéma planifie l'amélioration et l'expansion à long terme de la plateforme pour répondre aux besoins et opportunités du marché en évolution dans l'avancement des objectifs du schéma.
+
+## 6. Responsabilités et obligations des participants
+
+- Les participants sont tenus de se conformer à ces règles commerciales et aux documents associés à ces règles.
+
+- Les participants doivent se conformer à toute loi applicable en ce qui concerne leur participation au schéma dans les territoires dans lesquels ils opèrent et dans lesquels ils utilisent les services du schéma. Le schéma n'assume aucune responsabilité quant à la conformité des participants à la loi applicable.
+
+- Les participants sont tenus de permettre l'utilisation et la divulgation d'informations personnelles comme l'exigent ces règles commerciales et de fournir des informations à leurs clients et d'obtenir les consentements nécessaires concernant cette utilisation et divulgation d'informations personnelles comme l'exige la loi applicable.
+
+- Les participants acceptent de payer des frais au schéma et aux autres participants comme spécifié dans ces règles.
+
+- Les participants adhéreront aux spécifications de marque du schéma comme spécifié dans ces règles.
+
+- Les participants utiliseront les services du schéma comme spécifié dans ces règles.
+
+    <ul><i>Les schémas devront examiner s'ils souhaitent : 1) exiger l'utilisation du schéma pour les transactions éligibles au schéma (en supposant l'autorité des règles pour ce faire) ; 2) exiger l'utilisation de la plateforme du schéma pour les transactions « on-us » (nécessiterait des frais de traitement séparés, probablement nuls pour ces transactions) ; si les transactions « on-us » ne passent pas par la plateforme, si le schéma souhaite exiger le reporting des transactions « on-us » au schéma, pour utilisation avec un utilitaire de fraude.</i></ul>
+
+- Tous les transferts effectués en utilisant la marque du schéma ou décrits comme étant effectués avec le schéma seront effectués en utilisant les services du schéma.
+
+    <ul><i>Les schémas devront examiner s'ils souhaitent énoncer la règle ci-dessus. Certains schémas peuvent vouloir que les participants utilisent la marque du schéma pour les transactions on-us qui n'utilisent pas les services du schéma. Cela pourrait être formulé comme « tous les transferts interopérables ».</i></ul>
+
+- _\[Option de règlement net\]_ Les participants ouvriront un compte bancaire de règlement auprès de la banque de règlement spécifiée par le schéma, ou mettront à disposition un compte existant à ces fins, comme autorisé par le schéma. _\[Option de règlement brut continu\]_ Les participants deviendront copropriétaires du compte de règlement mutualisé du schéma et signeront l'accord de compte bancaire de règlement du schéma à cet effet. Les participants transféreront des fonds vers et depuis ce compte à partir de leurs comptes de réserve, de compensation ou de fiducie existants auprès de la banque de règlement du schéma, comme spécifié dans les directives opérationnelles du schéma.
+
+- Les participants partageront des informations avec le schéma dans la mesure strictement nécessaire au fonctionnement du schéma, y compris pour la diligence raisonnable, l'intégration technique, la configuration, la gestion des transactions et d'autres fins spécifiées dans les règles.
+
+- Les participants seront tenus par le schéma de respecter les normes de sécurité, de gestion des risques et de confidentialité des données spécifiées par le schéma.
+
+- Les participants fourniront un service client adéquat à leurs clients en lien avec le schéma.
+
+- Les participants doivent exclure les clients de l'utilisation du schéma à la demande du schéma lorsque le schéma détermine raisonnablement qu'un client présente un risque pour le schéma, qui peut inclure un risque financier, juridique, de sécurité, de réputation ou tout autre risque.
+
+- Les participants ne permettront pas, et ne permettront pas à leurs clients, d'utiliser le schéma à des fins illégales, y compris les biens ou services illégaux ; les paiements illégaux, tels que la corruption, le blanchiment d'argent ou le financement du terrorisme ; le braconnage ou le trafic d'espèces animales protégées ou de produits dérivés.
+
+    <ul><i>Les schémas peuvent examiner s'ils souhaitent spécifier que les participants interdisent contractuellement aux clients d'utiliser les services du schéma à des fins illégales et interrompront les services du schéma pour les clients dont ils savent, ou soupçonnent, qu'ils utilisent les services du schéma pour initier ou recevoir des transferts à des fins illégales.</i></ul>
+
+### 6.1 Responsabilités et obligations des participants en tant que DFSP payeurs
+
+- Un participant qui initie une demande de devis ou une demande de transfert agit en tant que participant payeur en vertu de ces règles.
+
+- Un participant peut initier une transaction pour le compte de son payeur pour tout cas d'utilisation ou cas d'utilisation secondaire pris en charge par le schéma.
+
+- Un participant payeur est tenu de régler un transfert lors de la soumission d'une demande de transfert, à moins que cette demande de transfert ne soit refusée par le DFSP bénéficiaire ou n'expire sans exécution.
+
+- Le participant payeur garantit, lors de la soumission de chaque demande de transfert, que le transfert provient d'un compte conforme aux exigences KYC et AML et est exécuté conformément à la loi applicable, et que le payeur a reçu toutes les informations et a donné tous les consentements nécessaires pour effectuer le transfert conformément à ces règles commerciales et à la loi applicable.
+
+- Le participant payeur garantit, lors de la soumission d'une demande de transfert, que la demande de transfert a été autorisée par son payeur, et que ses communications avec son payeur ont été correctement authentifiées conformément à ces règles commerciales et à la loi applicable.
+
+- Le participant payeur reconnaît que la plateforme rejettera une demande de transfert si le transfert proposé violerait ces règles commerciales, comme le dépassement du plafond de débit net du participant payeur.
+
+### 6.2 Responsabilités et obligations des participants en tant que DFSP bénéficiaires
+
+- Un participant qui reçoit et répond à une demande de devis ou une demande de transfert agit en tant que participant bénéficiaire en vertu de ces règles.
+
+- Un participant bénéficiaire qui reçoit une demande de devis est tenu de répondre, en l'absence de problèmes techniques, avec une réponse au devis si :
+
+  - Le compte de transaction du bénéficiaire auprès du participant bénéficiaire est en règle et capable de recevoir, à ce moment-là, le montant du transfert et
+
+  - L'acceptation du transfert ne mettra pas le compte du bénéficiaire dans un état non autorisé par la loi applicable ou les politiques et accords de compte du participant.
+
+  - Le participant bénéficiaire affirme, lors de l'initiation d'une réponse au devis autre qu'une réponse d'erreur, que le compte du bénéficiaire a été validé — il est ouvert, en règle et capable d'accepter le montant du transfert proposé à ce moment-là.
+
+- Le participant bénéficiaire affirme, lors de l'initiation d'une réponse au devis autre qu'une réponse d'erreur, qu'un transfert vers le compte désigné est conforme à ce moment-là aux exigences applicables en matière d'AML/CFT et de KYC.
+
+- Un participant bénéficiaire qui reçoit une demande de transfert est tenu, en l'absence de problèmes techniques, de répondre avec une réponse de transfert avec l'état de transaction « Committed » si :
+
+  - Il a reçu une demande de devis et a répondu avec une réponse au devis pour la transaction et
+
+  - La réponse au devis n'a pas encore expiré
+
+  - Le compte de transaction du bénéficiaire auprès du participant bénéficiaire est en règle et capable de recevoir, à ce moment-là, le montant du transfert et
+
+  - L'acceptation du transfert ne mettra pas le compte du bénéficiaire dans un état non autorisé par la loi applicable ou les politiques et accords de compte du participant et
+
+  - La demande de transfert sur la transaction n'a pas expiré.
+
+- Un participant bénéficiaire qui envoie une réponse de transfert avec un état de transaction « Committed » doit comptabiliser ce transfert sur le compte du bénéficiaire dans un délai de \[X temps\].
+
+- Un participant bénéficiaire qui reçoit une demande de transfert ne répondant pas aux critères ci-dessus est tenu de répondre avec une réponse de transfert avec l'état de transaction « Aborted ».
+
+- Le participant bénéficiaire doit affirmer, lors de la soumission de chaque réponse de transfert avec un état de transaction « Committed », que le transfert est crédité sur un compte conforme aux exigences AML et est exécuté conformément à toute limitation de volume de compte, ou toute autre réglementation s'appliquant dans les territoires dans lesquels il opère, et que le bénéficiaire a reçu toutes les informations et a donné tous les consentements nécessaires pour effectuer le transfert conformément aux règles et à la loi applicable.
+
+## 7. Responsabilité - Répartition des responsabilités
+
+- Chaque participant est responsable des erreurs commises par lui, et de la fraude commise par ses employés ou sous-traitants, conformément à la loi applicable.
+
+- Le schéma ne sera pas tenu responsable et chaque participant indemnisera et défendra le schéma contre les réclamations découlant des actions ou omissions des participants, de leurs clients ou sous-traitants.
+
+- Le schéma peut choisir de défendre toute réclamation dans les circonstances où le schéma détermine que la résolution d'une réclamation pourrait avoir un impact défavorable sur les finances, les opérations ou la réputation du schéma.
+
+- Le schéma sera tenu responsable de ses propres erreurs dans le traitement des transferts dans les limites prescrites par les règles.
+
+- Le schéma compensera les participants pour les coûts de fonds dans la mesure où un participant est injustement privé de fonds pendant une période de temps résultant d'erreurs commises par le schéma.
+
+- Chaque participant est responsable des actions et omissions de tout sous-traitant engagé par lui pour fournir des services en lien avec le schéma dans la même mesure que s'ils avaient été commis par le participant.
+
+- Le schéma peut répartir la responsabilité entre les participants pour les conséquences de l'utilisation non autorisée ou de l'accès aux données par un participant ou pour un incident de sécurité subi par un participant qui impacte d'autres participants ou le schéma conformément aux principes énoncés dans les règles.
+
+## 8. Sécurité, gestion des risques et confidentialité des données 
+
+### 8.1 Confidentialité et protection des informations personnelles
+
+- Les informations confidentielles du schéma divulguées aux participants seront tenues confidentielles par les participants et ne seront utilisées qu'aux fins autorisées par les règles. Les informations confidentielles du schéma peuvent inclure la technologie propriétaire et d'autres éléments désignés par le schéma.
+
+- Les données de transaction n'appartiendront pas au schéma et appartiendront à un participant en ce qui concerne les transactions de ses clients.
+
+- La confidentialité des données de transaction et de toute information personnelle traitée dans la plateforme sera protégée par le schéma et les participants conformément à la loi applicable.
+
+- Les statistiques ou données qui identifient un participant ou à partir desquelles le participant peut être identifié ne seront pas divulguées à d'autres participants. Le schéma peut préparer pour un usage interne et divulguer à des tiers à des fins promotionnelles des statistiques basées sur des données agrégées et anonymisées, comme autorisé par la loi applicable.
+
+- Le schéma effectuera des divulgations d'informations confidentielles pour se conformer à la loi applicable ou à la directive d'une autorité de régulation.
+
+- Le schéma protégera les informations personnelles en sa possession ou sous son contrôle contre toute utilisation abusive et traitera ces informations conformément à la loi applicable protégeant la vie privée des individus.
+
+- Le schéma maintiendra des mesures de sécurité de premier plan dans l'industrie pour protéger les informations contre tout accès et utilisation non autorisés.
+
+- Les participants informeront le schéma et reconnaissent que le schéma peut informer d'autres participants, de tout incident de sécurité dans les systèmes ou locaux du participant, de ses entités affiliées ou de tout fournisseur tiers engagé par le participant pour fournir des services en soutien de la participation du participant au schéma.
+
+- Le schéma peut mener des enquêtes sur les incidents de sécurité. Les participants coopéreront pleinement et rapidement avec l'enquête. Ces enquêtes seront aux frais du participant concerné.
+
+- Le schéma peut exiger qu'un participant mène des enquêtes sur les incidents de sécurité et peut exiger que ces enquêtes soient menées par des auditeurs de sécurité indépendants qualifiés acceptables pour le schéma.
+
+- Le schéma peut imposer des conditions de participation continue au participant concerné concernant la remédiation des causes de l'incident de sécurité et les mesures de sécurité en cours.
+
+- L'enquête et le rapport, ainsi que les remèdes qui peuvent être requis, seront tenus confidentiels dans la mesure autorisée par la loi applicable.
+
+### 8.2 Politiques de gestion des risques
+
+<ul><i>Cette section suppose que l'élaboration de politiques de gestion des risques par le schéma et ses participants sera évolutive. Cette section envisage que certaines de ces politiques seront (éventuellement) dans les règles ; d'autres ne le seront pas.</i></ul>
+
+- Les politiques et procédures de gestion des risques peuvent être énoncées dans les règles, dans les documents associés ou dans d'autres documents de politique écrits créés par le schéma et distribués aux participants.
+
+- Les politiques et procédures de gestion des risques incluront la solidité fiscale, l'intégrité du système, la conformité à la loi applicable, en particulier en ce qui concerne les mesures de lutte contre le blanchiment d'argent/le financement du terrorisme, la protection de la vie privée des informations personnelles et la sécurité des données.
+
+- Les fonctions de gestion des risques incluent les procédures applicables aux participants pour la surveillance des risques, y compris les exigences de reporting et les audits.
+
+### 8.3 Continuité des activités
+
+- Dispositions pour assurer la continuité des activités de la part du schéma, de ses fournisseurs et des participants.
+
+## 9. Plateforme et services du schéma
+
+- Le schéma définit l'ensemble des services du schéma auxquels les participants accèdent pour utiliser le système. Ceux-ci sont répertoriés dans une annexe à ce document. Les services essentiels du schéma nécessaires à l'interopérabilité sont considérés comme la plateforme du schéma.
+
+- Les détails techniques et opérationnels sur l'utilisation des services du schéma, y compris la plateforme du schéma, sont fournis dans les documents associés. Cette liste de documents associés est une annexe à ce document.
+
+## 10. Gestion des exceptions
+
+- Des problèmes peuvent survenir lors de l'exécution d'une transaction, entraînant des cas d'exception, qui peuvent nécessiter ou être facilités par une communication inter-participants. Les cas d'exception peuvent inclure des erreurs de la part de toute partie, des fraudes ou d'autres anomalies de service.
+
+- Le schéma créera et maintiendra des protocoles par lesquels les participants peuvent déterminer le type d'exception et les actions suggérées ou requises de la part des participants pour résoudre l'exception. Ces protocoles sont contenus dans un document associé.
+
+- Les principes suivants régissent la gestion des exceptions :
+
+  - Les participants impliqués coopéreront de bonne foi.
+
+  - Chaque participant accepte de ne pas contacter directement le client de l'autre participant pendant le processus de résolution des litiges.
+
+  - Les participants acceptent de coopérer entre eux et avec le schéma pour partager des informations sur les fraudes suspectées ou confirmées.
+
+### 10.1 Irrévocabilité des transactions
+
+- Les participants conviennent que les transferts exécutés via la plateforme sont irrévocables. Un transfert qui a été crédité sur le compte d'un bénéficiaire à la suite d'un transfert du schéma ne peut pas être révoqué sans le consentement du bénéficiaire.
+
+- Le schéma peut ordonner à un participant d'initier une transaction corrective entre participants pour un montant déterminé par le schéma comme nécessaire pour corriger les erreurs causées par le DFSP payeur, le DFSP bénéficiaire ou le schéma. Les conditions dans lesquelles de telles transactions correctives peuvent être effectuées sont spécifiées par les règles. 
+
+- Les erreurs de la part du DFSP bénéficiaire, du DFSP payeur ou du schéma qui entraînent une comptabilisation erronée ou en double d'un transfert sur le compte d'un bénéficiaire peuvent être corrigées par le participant bénéficiaire, tant que les instructions du transfert exécuté ne sont pas révoquées ou modifiées de quelque manière que ce soit.
+
+## 11. Annexe : Documents associés
+
+- Glossaire uniforme
+
+- Directive opérationnelle de la plateforme
+
+- Directive de marque
+
+- Protocoles de gestion des exceptions
+
+## 12. Annexe : Processus d'intégration et de sortie
+
+## 13. Annexe : Services du schéma
+
+Les services du schéma incluent :
+
+- Plateforme du schéma, qui comprend
+
+  - Le service de transfert
+
+  - Le service de répertoire
+
+  - Le service de règlement
+
+  - Service de gestion du schéma
+
+- Autres services partagés
+
+  - Utilitaire de gestion de la fraude
+
+## 14. Annexe : Cas d'utilisation pris en charge par le schéma
+
+<ul><i>Les cas d'utilisation sont définis par le type de client qui paie quel autre type de client, et par l'objectif du paiement. Les cas d'utilisation secondaires sont des sous-ensembles des cas d'utilisation et sont utilisés pour démontrer des différences plus précises dans les transferts. Tous les transferts effectués via les services du schéma peuvent être catégorisés par un, et un seul, cas d'utilisation et cas d'utilisation secondaire.</i></ul>
+
+<ul><i>Le cas d'utilisation et le cas d'utilisation secondaire d'une transaction peuvent nécessiter l'application de différents détails opérationnels et techniques, comme spécifié dans la directive opérationnelle de la plateforme ; différents frais d'interchange, comme spécifié dans une annexe à ces règles ; différentes exigences pour les procédures de gestion des exceptions, comme spécifié dans un document associé à ces règles.</i></ul>
+
+<ul><i>Tous les cas d'utilisation et cas d'utilisation secondaires pris en charge par le schéma sont définis par les attributs des transactions, qui sont spécifiés dans la directive opérationnelle de la plateforme.</i></ul>
+
+<ul><i>Ce qui suit est un exemple de tableau de cas d'utilisation et de cas d'utilisation secondaires qu'un schéma pourrait prendre en charge.</i></ul>
+
+<ul><i>Un schéma ne définirait des cas d'utilisation secondaires que s'il souhaitait rédiger des règles et/ou spécifier des frais propres à ce cas d'utilisation secondaire.</i></ul>
+
+|       | Cas d'utilisation   | Cas d'utilisation secondaire          |
+| :---: | :--------: | :-------------------------- |
+| 1.0 | P2P | Personne à personne |
+| 1.1 | P2P | Portefeuille à portefeuille |
+| 1.2 | P2P | Banque à banque |
+| 1.3 | P2P | Portefeuille à banque |
+| 1.4 | P2P | Banque à portefeuille |
+| 2.0 | Paiement en masse |  |
+| 2.1 | B2P | Entreprise à personne |
+| 2.2 | G2P | Gouvernement à personne |
+| 3.0 | P2B | Personne à entreprise |
+| 3.1 | P2B | Achat par numéro de caisse |
+| 3.2 | P2B | Achat par code QR |
+| 3.3 | P2B | Achat en ligne |
+| 3.4 | P2B | Paiement de facture |
+| 3.5 | P2B | Personne à entreprise - Autre |
+| 4.0 | P2G | |
+| 4.1 | P2G | Personne à gouvernement |
+| 4.1 | P2G | Achat par numéro de caisse |
+| 4.2 | P2G | Achat par code QR |
+| 4.3 | P2G | Achat en ligne |
+| 4.4 | P2G | Paiement de facture |
+
+## 15. Annexe : Grille tarifaire du schéma
+
+1. Frais de traitement
+
+   - Les frais de traitement sont calculés par \[définir\]
+
+   - Les frais de traitement s'appliquent aux transferts exécutés
+
+   - Les frais de traitement sont facturés à \[quelle partie ou parties\]
+
+   - Les frais de traitement pour les transferts « on-us » (où le DFSP payeur et le DFSP bénéficiaire sont les mêmes) \[sont ou ne sont pas facturés\]
+
+   - Les frais de traitement seront calculés et facturés aux participants \[définir\]
+
+   - Disposition sur la manière dont les participants paieront les factures de traitement \[définir\]
+
+2. Frais d'adhésion ou de participation
+
+   - Les frais d'adhésion ou de participation sont facturés à \[définir\]
+
+   - Spécifier la base, le mode de collecte, etc.
+
+3. Frais d'interchange
+
+   - Les frais d'interchange sont fixés par le schéma
+
+   - Le montant du frais et la direction (quel participant paie quel autre) varient selon le cas d'utilisation et le cas d'utilisation secondaire. Certains cas d'utilisation et cas d'utilisation secondaires n'auront pas d'interchange.
+
+   - \[Définir comment la plateforme collectera et distribuera l'interchange : sur une base transactionnelle ou périodique.\]
+
+## 16. Annexe : Gestion des risques, sécurité, confidentialité et normes de service
+
+<ul><i>Les schémas peuvent ou non vouloir spécifier des normes ou exiger que les participants se conforment à d'autres normes établies. Les schémas peuvent en outre spécifier des normes différentes pour différentes catégories de participants. La liste ci-dessous est donnée purement à titre d'exemple.</i></ul>
+
+Les participants doivent adhérer aux pratiques suivantes en matière de qualité de service, de sécurité, de confidentialité des données et de service client en ce qui concerne leur participation au schéma.
+
+- Les participants établiront un cadre de gestion des risques pour identifier, évaluer et contrôler les risques relatifs à leur utilisation du schéma.
+
+- Les participants s'assureront que les systèmes, applications et réseaux prenant en charge l'utilisation du schéma sont conçus et développés de manière sécurisée.
+
+- Les participants mettront en œuvre des processus pour gérer de manière sécurisée tous les systèmes et opérations prenant en charge l'utilisation du schéma.
+
+- Les participants mettront en œuvre des processus pour s'assurer que les systèmes utilisés pour le schéma sont protégés contre les intrusions ou utilisations non autorisées.
+
+- Les participants mettront en œuvre des processus pour assurer l'authentification de leurs clients lors de la création et de l'approbation des transactions utilisant le schéma.
+
+-   Les participants élaboreront des plans efficaces de continuité des activités et de contingence.
+
+-   Les participants géreront les opérations techniques et commerciales pour permettre des réponses rapides aux appels API reçus de la plateforme du schéma ou d'autres participants via la plateforme du schéma.
+
+-   Les participants établiront des accords écrits régissant leurs relations avec les agents, processeurs et autres entités fournissant des services externalisés liés au schéma.
+
+-   Les participants élaboreront des politiques et processus pour la gestion et la supervision continues du personnel, des agents, des processeurs et des autres entités fournissant des services externalisés liés au schéma.
+
+-   Les participants s'assureront que les clients reçoivent des informations claires, visibles et opportunes concernant les frais et les conditions générales liés aux services utilisant le schéma.
+
+-   Les participants élaboreront et publieront des politiques et procédures de service client liées aux services utilisant le schéma.
+
+-   Les participants fourniront un mécanisme approprié pour que les clients puissent poser des questions et résoudre des problèmes. Les participants préciseront comment les litiges peuvent être résolus si la résolution interne échoue.
+
+-   Les participants se conformeront aux bonnes pratiques et aux lois applicables régissant la confidentialité des données des clients.
+
+-   Les participants s'assureront que les clients reçoivent des informations claires, visibles et opportunes concernant leurs pratiques de confidentialité des données.
diff --git a/docs/fr/adoption/Scheme/scheme-key-choices.md b/docs/fr/adoption/Scheme/scheme-key-choices.md
new file mode 100644
index 00000000..9dcda3bd
--- /dev/null
+++ b/docs/fr/adoption/Scheme/scheme-key-choices.md
@@ -0,0 +1,407 @@
+# Choix clés du schéma
+
+- Version : 5.0 
+    - Auteur : Carol Coye Benson (Glenbrook)
+    - Date : Octobre 2019
+    - Description : 
+
+---
+
+## **À propos du projet de documents commerciaux de la communauté Mojaloop**
+
+Ce document fait partie du projet de documents commerciaux de la communauté Mojaloop. Le projet est destiné à soutenir les entités (pays, régions, associations de fournisseurs ou entreprises commerciales) mettant en œuvre de nouveaux systèmes de paiement utilisant le code Mojaloop. Ces entités devront également rédiger des règles commerciales que les participants au système suivront.
+
+Le projet de documents commerciaux de la communauté Mojaloop fournit des modèles pour les règles commerciales et les documents associés. De nombreux choix sont impliqués dans la mise en œuvre d'un nouveau système de paiement : les modèles présentent certains de ces choix et, le cas échéant, des commentaires sont fournis sur la manière dont le choix particulier est lié aux objectifs d'un système aligné sur Level One.
+
+Les documents suivants font partie du projet :
+
+- Choix clés du schéma
+
+- Modèle d'accord de participation au schéma
+
+- Modèle de règles commerciales du schéma
+
+- Modèle de directive opérationnelle de la plateforme
+
+- Modèle de directive opérationnelle de gestion des exceptions
+
+- Glossaire uniforme
+
+## **Introduction**
+
+Des schémas de paiement à travers le monde sont en cours de mise en œuvre, ou envisagent la mise en œuvre, de systèmes de paiement basés sur Mojaloop. Mojaloop est un logiciel open source pour les sociétés de services financiers, les régulateurs gouvernementaux et d'autres acteurs relevant les défis de l'interopérabilité et de l'inclusion financière. Mojaloop est basé sur la spécification « Open API for FSP Interoperability Specification », qui a été développée pour fournir une spécification d'API ouverte pour l'interopérabilité de la monnaie mobile.
+
+La Fondation Bill & Melinda Gates a fourni un financement et un soutien pour Mojaloop. Mojaloop est un code de référence open source qui démontre les principes du Level One Project, une vision pour les marchés financiers numériques basée sur les principes d'interopérabilité, de collaboration et d'inclusion.
+
+Les schémas mettant en œuvre Mojaloop devront faire un certain nombre de choix commerciaux concernant la conception du système. Ces choix, une fois effectués, affecteront à la fois la mise en œuvre technique de Mojaloop et les règles commerciales que le schéma rédigera, et auxquelles les DFSP participants accepteront de se conformer. Ce document décrit et examine certains des choix les plus significatifs. Le cas échéant, des recommandations de meilleures pratiques sont formulées pour s'aligner sur les principes de conception du Level One Project (L1P).
+
+Bien que ce document soit rédigé en tant que contribution à la communauté Mojaloop, les questions décrites ici sont pertinentes pour tout système de paiement aligné sur Level One, quel que soit la mise en œuvre technique choisie.
+
+## **Choix décrits dans ce document**
+
+[1 - Choix : Propriété du schéma](#_1-choix-propriete-du-schema)
+
+[2 - Choix : Participation au schéma](#_2-choix-participation-au-schema)
+
+[3 - Choix : Relation entre le schéma et la plateforme](#_3-choix-relation-entre-le-schema-et-la-plateforme)
+
+[4 - Choix : Portée des règles du schéma et autorité des règles du schéma](#_4-choix-portee-des-regles-du-schema-et-autorite-des-regles-du-schema)
+
+[5 - Choix : Cas d'utilisation](#_5-choix-cas-d-utilisation)
+
+[6 - Choix : Codes QR](#_6-choix-codes-qr)
+
+[7 - Choix : Adressage des paiements](#_7-choix-adressage-des-paiements)
+
+[8 - Choix : Règlement inter-participants](#_8-choix-reglement-inter-participants)
+
+[9 - Choix : Accès par paliers](#_9-choix-acces-par-paliers)
+
+[10 - Choix : Frais du schéma et tarification pour l'utilisateur final](#_10-choix-frais-du-schema-et-tarification-pour-l-utilisateur-final)
+
+[11 - Choix : Gestion de la marque](#_11-choix-gestion-de-la-marque)
+
+[12 - Choix : Connexions du schéma avec d'autres schémas](#_12-choix-connexions-du-schema-avec-d-autres-schemas)
+
+[13 - Choix : Utilisation du schéma par d'autres FSP](#_13-choix-utilisation-du-schema-par-d-autres-fsp)
+
+[14 - Choix : Normes de gestion des risques du schéma](#_14-choix-normes-de-gestion-des-risques-du-schema)
+
+[15 - Choix : Gestion des exceptions](#_15-choix-gestion-des-exceptions)
+
+## 1. Choix : Propriété du schéma
+
+Le schéma est l'entité qui rédige les règles du système de paiement. En tant que tel, le schéma contrôle de multiples aspects de la fourniture des services du schéma, y compris la manière dont la plateforme technique et opérationnelle sera fournie aux DFSP participants. Les modèles courants de propriété de schéma dans l'industrie des paiements incluent :
+
+- Une association de DFSP participants, avec ou sans propriété partielle par la banque centrale
+
+- Une banque centrale ou une autre entité gouvernementale
+
+- Une entité commerciale
+
+Le modèle associatif maximise le contrôle des DFSP sur le schéma et peut encourager les DFSP à rejoindre et utiliser le schéma. Un schéma contrôlé par le gouvernement ou la banque centrale peut rendre la supervision réglementaire des DFSP plus efficace et simplifier la prise de décision : un organisme gouvernemental peut être disposé à prendre des décisions d'infrastructure qui sont bénéfiques pour l'ensemble de l'écosystème, plutôt que d'optimiser les avantages individuels des DFSP. Une entité commerciale peut être plus rapide à mettre en œuvre un nouveau système et peut être plus efficace dans certaines situations pour créer un modèle opérationnel durable.
+
+### 1.1 Alignement Level One — Propriété du schéma
+
+N'importe laquelle de ces structures de propriété peut atteindre les objectifs du L1P et de l'inclusion financière. Les principes de conception Level One suggèrent « l'auto-gouvernance par les DFSP » (le premier modèle) comme conception préférée, sur la base de la conviction que la participation à la gouvernance peut augmenter l'engagement des DFSP envers le schéma. D'autres conceptions peuvent fonctionner, cependant, tant que le schéma et ses membres disposent d'une certaine forme de gouvernance participative et fonctionnent avec transparence et communications ouvertes.
+
+Le principe Level One le plus important est que le schéma lui-même devrait fonctionner sur un modèle « sans perte » (recouvrement durable des coûts). Ce dernier point est particulièrement important pour atteindre l'objectif du L1P de créer un système de paiement à très faible coût. Ce principe repose sur l'idée que les DFSP peuvent, bien entendu, fonctionner sur une base lucrative en fournissant des services de paiement. La source de leurs revenus, cependant, peut provenir principalement des « [adjacences](https://docs.gatesfoundation.org/documents/fighting%20poverty%20profitably%20full%20report.pdf) » plutôt que des frais liés à la transaction de paiement elle-même. Notez que la plateforme opérationnelle peut être fournie par une entité commerciale, même si le schéma lui-même est exploité sur une base « sans perte ». Ceci est discuté plus loin dans « Choix : Relation entre le schéma et la plateforme ».
+
+De nombreux systèmes de paiement bancaires hérités dans le monde fonctionnent sur le modèle associatif. Les systèmes ACH et les systèmes de carte de débit nationaux (tels que le système ACH américain et le système Interac du Canada) utilisent ce modèle et offrent des coûts de traitement ultra-faibles aux DFSP participants. Certains nouveaux systèmes de paiement mobile, tels que le système UPI de l'Inde et le système BIM du Pérou, utilisent également ce modèle.
+
+Plusieurs pays fournissent des services par l'intermédiaire de la banque centrale : le modèle SPEI du Mexique est notable ici. Le système JoMoPay de la Jordanie a commencé comme un système de banque centrale et est passé au modèle associatif.
+
+Les réseaux de cartes mondiaux, notamment Visa et MasterCard, ont commencé comme des modèles associatifs et sont passés à un modèle commercial. De nombreuses FinTechs, telles que PayPal ou WeChat Payments, exploitent des systèmes en boucle fermée sur un modèle commercial.
+
+## 2. Choix : Participation au schéma
+
+Mojaloop et le L1P utilisent le terme « DFSP » (Fournisseur de services financiers numériques) pour désigner toute entité dans la juridiction dans laquelle le système de paiement opère, qui est autorisée d'une certaine manière à fournir des comptes de transaction aux utilisateurs finaux qui détiennent des fonds et qui peuvent être utilisés pour effectuer et recevoir des paiements. Cette définition inclut les banques, les autres institutions financières de dépôt et les émetteurs de monnaie électronique (parfois appelés opérateurs de monnaie mobile).
+
+Il existe une myriade d'autres participants de l'écosystème qui ne détiennent pas de comptes de transaction des utilisateurs finaux : ceux-ci incluent les processeurs, les agrégateurs et certains types de fournisseurs de services de paiement. La relation de ces entités avec le schéma et les DFSP est discutée dans [Choix : Utilisation du schéma par d'autres FSP](#_13-choix-utilisation-du-schema-par-d-autres-fsp).
+
+La question de la participation est double : premièrement, quelles catégories de DFSP sont prises en charge par le schéma, et deuxièmement, quel est le processus par lequel les DFSP sont autorisés à participer. Le terme « boucle ouverte » est utilisé pour désigner une structure dans laquelle plusieurs DFSP adhèrent et utilisent le schéma pour échanger des transactions (interopérer). Mais un schéma en « boucle ouverte » peut être soit un schéma dans lequel tout DFSP d'une catégorie prise en charge est éligible pour rejoindre le schéma, soit un schéma dans lequel la participation est limitée et gérée par invitation. Un DFSP candidat peut faire face à certains critères d'éligibilité (taille, santé financière, etc.) avant d'être admis au schéma.
+
+Le terme « boucle fermée » est le plus souvent utilisé pour désigner un schéma qui n'est pas interopérable ; dans lequel l'entité du schéma a des relations directes avec tous les clients finaux.
+
+Le L1P est fortement en faveur des systèmes en boucle ouverte. De plus, le L1P préconise que tous les fournisseurs autorisés de comptes de transaction soient éligibles : en d'autres termes, les catégories de banques et d'émetteurs de monnaie électronique devraient être incluses et autorisées à interopérer via la plateforme du schéma.
+
+Il y a un certain nombre d'arguments qui soutiennent cette recommandation. Le concept même d'« inclusion financière » implique l'intégration de populations précédemment exclues dans l'écosystème financier du pays. Dans de nombreux pays, l'émission de monnaie électronique ou d'autres structures ont été approuvées par les régulateurs pour fournir des comptes de transaction à des populations qui n'ont pas pu être servies économiquement par les banques traditionnelles. Ces émetteurs de monnaie électronique ont fréquemment créé des portefeuilles mobiles en boucle fermée, et l'un des objectifs du L1P et de Mojaloop est de permettre l'interopérabilité de ces portefeuilles. Cependant, les détenteurs de portefeuilles doivent payer non seulement d'autres détenteurs de portefeuilles, mais aussi des commerçants et d'autres institutions bancaires, ainsi que des individus bancarisés. Les individus et institutions bancarisés effectuent également des paiements aux détenteurs de portefeuilles. Il est logique que le même système de paiement interopérable prenne en charge les deux pour des raisons d'efficacité (pourquoi avoir plusieurs systèmes quand un seul peut connecter tous les acteurs ?) et pour des raisons économiques.
+
+L'argument économique tourne autour de la nature des systèmes de traitement transactionnel : plus le volume est important, plus le coût unitaire est faible. Ce principe est également soutenu dans le [Rapport PAFI de la Banque mondiale/CPMI](http://www.worldbank.org/en/topic/financialinclusion/brief/pafi-task-force-and-report) : « le cadre promeut l'innovation et la concurrence en ne faisant pas obstacle à l'entrée de nouveaux types de PSP... L'interopérabilité accrue des infrastructures soutenant la commutation, le traitement, la compensation et le règlement des instruments de paiement du même type est encouragée... les infrastructures de paiement, y compris celles exploitées par les banques centrales, ont des exigences de participation objectives, fondées sur les risques, qui permettent un accès juste et ouvert à leurs services. » Un point connexe et important est que les règles du schéma devraient spécifier qu'un participant individuel ne peut pas discriminer un autre participant individuel : sauf contrainte par d'autres facteurs (limites réglementaires de compte, etc.), les participants doivent recevoir les transactions envoyées par d'autres participants du schéma. Cela garantit une interopérabilité totale.
+
+La deuxième question est de savoir quels critères d'éligibilité un DFSP potentiel doit remplir pour effectivement rejoindre le schéma. De nombreux schémas de paiement ont des procédures assez élaborées pour s'assurer que les DFSP candidats disposent des ressources financières pour se conformer aux règles et des moyens techniques pour répondre aux exigences opérationnelles des règles.
+
+Une certaine forme de ces exigences est nécessaire pour tout schéma. Mais la technologie moderne et, en particulier, les modèles de règlement pré-financés réduisent considérablement les risques pour le schéma dans ses relations avec les DFSP plus petits. La question d'alignement Level One ici est de s'assurer que le schéma ne discrimine pas involontairement les petits DFSP en faveur des grands. L'objectif devrait être de garantir les qualifications minimales nécessaires pour soutenir les obligations qu'un DFSP candidat entreprend.
+
+## 3. Choix : Relation entre le schéma et la plateforme
+
+Nos définitions séparent le concept de schéma (l'entité qui rédige les règles d'un système de paiement) et de plateforme (l'ensemble des services qui permettent physiquement l'interopérabilité). Le plus souvent, mais pas nécessairement, la plateforme fonctionne comme un commutateur qui achemine les transactions d'un DFSP à un autre : l'alternative est des connexions physiques bilatérales entre les DFSP.
+
+Quelle est la relation entre le schéma et la plateforme ? Il existe de multiples modèles démontrés dans les systèmes de paiement à l'échelle mondiale :
+
+1. Même entité : le schéma exploite la plateforme. Cela se voit fréquemment dans les systèmes commerciaux (par ex. Visa) et également dans les systèmes fournis par la banque centrale (par ex. Bank of Mexico SPEI).
+
+2. Le schéma engage la plateforme : le commutateur et les services associés sont exploités par une entité distincte, sous contrat avec l'entité du schéma. Le schéma paie l'entité de la plateforme ; ce coût est recouvré par les frais du schéma à ses DFSP participants. Le système Faster Payments du Royaume-Uni fonctionne sur ce modèle (Faster Payments Scheme Ltd. engage Vocalink pour exploiter la plateforme).
+
+3. Le schéma définit les paramètres selon lesquels le(s) opérateur(s) gèrent les transactions régies par les règles : s'il y a plusieurs opérateurs, ces entités doivent interopérer, encore une fois comme spécifié dans les règles du schéma. Les DFSP individuels choisissent l'opérateur qu'ils souhaitent utiliser pour accéder au système. Le système ACH américain fonctionne de cette manière, tout comme plusieurs des systèmes de paiement SEPA en Europe.
+
+4. Pas de commutateur : c'est en réalité une variation du modèle 3 ci-dessus. Chaque DFSP se connecte indépendamment et physiquement à chaque autre DFSP, toujours dans les contraintes fixées par les règles du schéma. Les cartes de débit en Australie fonctionnent de cette manière.
+
+### 3.1 Alignement L1P : Relation entre le schéma et la plateforme
+
+Il n'y a pas de principe Level One unique qui plaiderait en faveur de l'un de ces modèles par rapport à l'autre. Les facteurs à considérer incluent :
+
+- L'objectif est que tous les acteurs de l'écosystème (schéma, plateforme, DFSP, etc.) encouragent un comportement conforme au L1P. Un modèle plus contrôlé (modèles 1 ou 2) rend cela sans doute plus facile.
+
+- Avoir un système à faible coût est un principe fondamental. Cependant, il est discutable de savoir si cela est mieux réalisé par le modèle 1 ou le modèle 2. Les modèles 3 et 4 portent le risque d'exclure ou de désavantager les petits DFSP ou les nouveaux entrants du système.
+
+- Dans les modèles 2 et 3, les fournisseurs de plateforme auront leurs propres directives opérationnelles. Il peut y avoir des situations dans lesquelles les dispositions des règles du schéma ne sont pas adéquatement reflétées ou mises en œuvre par la plateforme. Il s'agit d'une question de pouvoir et de contrôle. Le modèle 1 évite ce problème mais pourrait créer un problème de type « verrouillage fournisseur », où les DFSP n'ont d'autre choix que de payer les coûts de la plateforme contrôlée par le schéma.
+
+## 4. Choix : Portée des règles du schéma et autorité des règles du schéma
+
+### 4.1 Portée
+
+Les règles de schéma varient considérablement en portée d'un schéma à l'autre. Toutes couvrent les éléments essentiels de la participation au schéma, les obligations des parties et les mécanismes d'interopérabilité. Mais de nombreux schémas vont beaucoup plus loin en termes de définition de la manière dont les DFSP mettent les services de paiement à la disposition de leurs clients, et selon quelles conditions. Deux domaines méritent d'être notés : 
+
+- Certains schémas spécifient des éléments de l'expérience de l'utilisateur final. Des exemples incluent les réseaux de cartes spécifiant les paramètres physiques et les exigences de conception des cartes. Certains systèmes (par exemple, le BIM du Pérou) spécifient comment l'interface du téléphone mobile apparaît au consommateur. D'autres systèmes (par exemple, le UPI de l'Inde) vont jusqu'à fournir les SDK et API qui définissent ce que l'application de l'utilisateur final peut fonctionnellement faire. Certains systèmes peuvent exiger qu'un DFSP recevant une transaction de crédit par poussée doive la comptabiliser sur le compte d'un client dans un délai spécifié.
+- Certains schémas spécifient également des dispositions élaborées en matière de responsabilité sur les transactions interopérables. Ces dispositions peuvent varier selon le cas d'utilisation et les attributs particuliers d'une transaction. Par exemple, dans les réseaux de cartes, la responsabilité peut passer de l'émetteur de la carte à l'acquéreur du commerçant si le terminal du commerçant ne répond pas à certaines spécifications.
+
+### 4.2 Autorité des règles
+
+Comme décrit ci-dessus, le schéma est l'entité qui rédige les règles du système de paiement. Mais qui approuve ces règles ? Il existe deux modèles principaux sur le marché :
+
+- Autorité des DFSP. Dans ce modèle, tous (ou certains) changements de règles sont votés par les DFSP participants. Le vote peut être déterminé sur une base par siège, ou sur une base pondérée par le volume. De nombreux schémas ont expérimenté des variations à ce sujet.
+
+- Autorité du schéma avec participation des DFSP. Dans ce modèle, l'autorité des règles repose sur l'entité du schéma, mais un certain degré de participation formelle ou informelle des DFSP est inclus : cela peut être formel (comités permanents qui se réunissent pour examiner les changements de règles, périodes de commentaires sur les modifications des règles spécifiées dans les règles, etc.) ou informel (les représentants du schéma se réunissent et/ou demandent des retours écrits sur les changements de règles proposés).
+
+### 4.3 Alignement L1P — Portée et autorité des règles
+
+Il y a deux principes Level One pertinents : l'un est la gouvernance participative, et l'autre est le mandat de fournir un système à faible coût. Level One reconnaît également l'importance d'un système pratique et facile à utiliser pour les clients utilisateurs finaux, en particulier les consommateurs et commerçants pauvres. Les considérations incluent donc :
+
+- Les règles peuvent créer des coûts : plus les règles sont élaborées pour spécifier comment les DFSP doivent fournir des services au client, plus les coûts de conformité à ces règles seront élevés.
+
+- En contrepartie, il y a la valeur d'avoir une expérience consommateur commune — il existe des preuves considérables qu'avoir une expérience commune peut aider les consommateurs à s'auto-éduquer dans l'utilisation des services. On peut argumenter que c'est un facteur important dans la mise à l'échelle du système. Mais plus un schéma va loin dans la rédaction de règles qui affectent l'expérience de l'utilisateur final, plus il est important que les DFSP participants aient une voix dans ces règles.
+
+- L'expérience des schémas a montré que les règles de vote explicites, bien qu'elles semblent bonnes pour les DFSP, aboutissent souvent à des pratiques de décision très longues : c'est l'une des raisons pour lesquelles certains schémas utilisent le second modèle ci-dessus, et utilisent les DFSP participants comme sondages, mais ne leur accordent pas l'autorité sur les règles.
+
+## 5. Choix : Cas d'utilisation
+
+L'un des choix les plus importants qu'un schéma doit faire est de déterminer quels cas d'utilisation prendre en charge. Fréquemment, un schéma de crédit par poussée en temps réel pour le commerce de détail commence par les paiements de personne à personne (P2P) comme premier cas d'utilisation : souvent, un schéma indiquera au marché qu'il a l'intention de prendre en charge d'autres cas d'utilisation à l'avenir. À mesure que les schémas évoluent, il y a des « sous-cas d'utilisation » significatifs à considérer : dans certaines mises en œuvre de Mojaloop, le terme « cas d'utilisation secondaire » est utilisé pour cela : par exemple, si le P2P est le cas d'utilisation, le P2P transfrontalier pourrait être un cas d'utilisation secondaire ; portefeuille-à-portefeuille et portefeuille-à-compte bancaire pourraient être des cas d'utilisation secondaires.
+
+Les règles commerciales peuvent varier selon le cas d'utilisation et/ou le cas d'utilisation secondaire. Cela peut inclure des détails opérationnels (champs de données utilisés, etc.), la tarification du schéma (en particulier, l'interchange) et même des dispositions de responsabilité.
+
+Le document Open API utilisé par le code Mojaloop inclut la liste suivante de cas d'utilisation :
+
+- Transfert P2P
+- Encaissement initié par un agent
+- Décaissement initié par un agent
+- Décaissement initié par un agent autorisé sur TPV
+- Décaissement initié par le client
+- Paiement commerçant initié par le commerçant
+- Paiement commerçant initié par le commerçant autorisé sur TPV
+- Décaissement initié par GAB
+- Remboursement
+
+Un schéma en cours de mise en œuvre choisira ses propres cas d'utilisation primaires et secondaires, et les définitions de ceux-ci figureront dans les règles commerciales. Les schémas devraient considérer les éléments suivants :
+
+- L'interopérabilité éventuelle entre schémas sera plus facile (surtout d'un schéma implémenté par Mojaloop à un autre) si les mêmes cas d'utilisation primaires et définitions sont utilisés.
+
+- Les schémas peuvent avoir besoin de différencier entre la capacité d'un DFSP à initier des transactions dans un cas d'utilisation ou cas d'utilisation secondaire spécifique, et les exigences qu'un DFSP doit être en mesure de prendre en charge pour recevoir des transactions dans un cas d'utilisation ou cas d'utilisation secondaire spécifique.
+
+- Toute règle rédigée spécifiquement pour un cas d'utilisation ou un cas d'utilisation secondaire doit être détectable systémiquement (par étiquetage ou inférence) si la règle doit être appliquée automatiquement : cela est particulièrement important pour les frais d'interchange spécifiques aux cas commerciaux. La manière dont cela est fait devrait faire partie de la documentation commerciale, dans les directives opérationnelles.
+
+### 5.1 Alignement L1P — Cas d'utilisation
+
+Il y a deux considérations ici. Une question significative est la relation entre les volumes élevés dans un système de paiement et la capacité à offrir des frais de traitement ultra-faibles aux DFSP participants. Presque tous les systèmes de paiement de détail prennent en charge plusieurs cas d'utilisation, y compris ceux qui ont commencé avec un seul cas d'utilisation. Les réseaux de cartes sont un excellent exemple de cela : ayant commencé pour prendre en charge les achats en point de vente, ils prennent maintenant en charge les achats en ligne, le paiement de factures, les paiements de salaires et les paiements B2B. Le traitement des paiements est une activité d'échelle : plus le volume est important, plus les coûts unitaires peuvent être faibles. Level One soutient fortement l'utilisation d'un système de paiement pour plusieurs cas d'utilisation : idéalement, tous les cas d'utilisation de détail (c'est-à-dire excluant les grands montants B2B) dans un pays.
+
+L'autre considération est de rendre le système de paiement facile d'accès et de compréhension pour les utilisateurs finaux. Le même système, avec des interfaces utilisateur similaires, etc., pour les cas d'utilisation sera plus facile à utiliser pour les utilisateurs finaux (en particulier les utilisateurs pauvres ou peu instruits).
+
+## 6. Choix : Codes QR
+
+Les codes QR émergent comme un facilitateur majeur des paiements commerçants dans les pays en développement. Les schémas de paiement et les autorités nationales de paiement décident des formats, protocoles et de la portée des codes QR. Certaines des décisions incluent :
+
+- Le code QR est-il présenté par le commerçant et scanné par le consommateur, ou présenté par le consommateur et scanné par le commerçant ? Level One a une préférence pour les codes QR présentés par le commerçant, mis en œuvre en conjonction avec des paiements par poussée, et non par tirage. Un code QR présenté par le commerçant peut être combiné avec un numéro de caisse pour permettre aux consommateurs disposant de téléphones basiques de payer facilement le même commerçant.
+
+- Le code QR est-il statique (le même pour tous les achats) ou dynamique ? Plutôt qu'un choix, cela est perçu comme une évolution : la plupart des marchés commencent avec des codes QR statiques, mais ont des plans pour passer à des codes dynamiques. Les codes dynamiques fonctionnent comme un message de « demande de paiement » dans un système de paiement par poussée, et peuvent contenir des données spécifiques à l'achat.
+
+- L'approche nationale des codes QR utilise-t-elle une approche de « code QR partagé », dans laquelle un seul code QR peut représenter les identifiants de paiement d'un commerçant à travers plusieurs schémas ? La manière la plus courante dont cette approche est mise en œuvre est par l'utilisation des normes de code QR EMVCo. Une alternative est une approche de code QR unique, dans laquelle un code QR est utilisé uniquement pour accéder soit à un schéma de paiement interopérable (par exemple, le système CoDi du Mexique) soit à un système en boucle fermée (par exemple, WeChat Payments en Chine). Une approche de code QR unique peut créer des avantages de coût faible en dirigeant le volume à travers une seule plateforme nationale, tandis qu'une approche inter-schémas peut permettre la concurrence entre plusieurs schémas.
+
+- Si une approche de code QR partagé est utilisée, y a-t-il une entité nationale unique qui contrôle quels schémas un commerçant donné accepte ? Si oui, qui gère cette fonction de « répertoire » et quelles sont ses fonctions ? Émet-elle réellement la chaîne de données du code QR ? Si oui, signe-t-elle la chaîne et la valide-t-elle ? Il y a des spéculations selon lesquelles un répertoire de codes QR pourrait servir de point de surveillance inter-systèmes de paiement et de gestion de la fraude. Il pourrait également être lié à un registre national des entreprises d'une certaine manière. Il est intéressant de considérer qu'un répertoire de codes QR inter-schémas pourrait nécessiter ses propres règles commerciales, qui deviendraient des « méta-règles » existant au-dessus des règles commerciales des schémas individuels.
+
+- La chaîne de données du code QR (la « charge utile ») contient-elle l'« adresse de paiement » du commerçant, ou pointe-t-elle d'une certaine manière vers un endroit où celle-ci est stockée ? Cette dernière approche offre plus de flexibilité et prend en charge la capacité d'un commerçant à changer de fournisseur.
+
+- Comment le consommateur (et le commerçant) est-il protégé contre la fraude par code QR ?
+
+- Quels sont les aspects économiques de la transaction pour le commerçant ? Level One a une forte préférence pour une tarification nulle ou quasi nulle pour le petit commerçant ou le commerçant pauvre.
+
+## 7. Choix : Adressage des paiements
+
+Tout schéma mettant en œuvre des paiements par crédit-poussée doit spécifier comment le payeur et son DFSP payeur adressent le paiement. L'adresse doit d'une certaine manière être résolue en numéro de compte du bénéficiaire auprès du DFSP qui fournit son compte de transaction. Le schéma doit décider :
+
+- Quels types d'adresses de paiement (parfois appelées « identifiants ») sont utilisés. Certaines adresses de paiement sont des identifiants institutionnels et des numéros de compte : un numéro de routage bancaire et un numéro de compte bancaire en sont un exemple. D'autres adresses de paiement peuvent être des numéros de compte sans l'identifiant institutionnel : un numéro de téléphone mobile utilisé pour diriger des fonds vers un portefeuille de monnaie électronique fourni par un opérateur de réseau mobile en est un exemple. Tous les autres types d'adresses de paiement sont des alias de quelque sorte. Un alias peut être une adresse e-mail, un identifiant commerçant attribué par le schéma, un numéro d'identité national ou un numéro de téléphone mobile utilisé pour diriger des fonds vers un compte autre que celui fourni par un émetteur de monnaie électronique opérateur de réseau mobile. Un alias pris en charge par le schéma peut également être une phrase : « payadamnu123 ».
+
+- Pour chaque type d'adresse de paiement pris en charge par le schéma, le schéma doit déterminer comment cette adresse de paiement est résolue. Au minimum, le schéma doit prendre en charge un mécanisme par lequel l'adresse est mappée à un identifiant DFSP participant au schéma responsable du compte de transaction associé à cette adresse de paiement. La résolution peut être effectuée de plusieurs manières différentes :
+
+    - Le schéma peut maintenir un répertoire mappant les adresses aux identifiants DFSP responsables : cela nécessite un certain type de processus d'enregistrement DFSP pour les adresses.
+
+    - Le schéma peut maintenir un répertoire qui mappe l'adresse au DFSP responsable et spécifie également le numéro de compte : cela nécessite un processus d'enregistrement légèrement différent.
+
+    - L'un ou l'autre de ces types de répertoires peut être maintenu par un tiers : les règles du schéma établiraient comment ces répertoires sont alimentés, maintenus et utilisés, et quelles sont les responsabilités des différentes parties.
+
+    - Un schéma peut également utiliser une méthode de diffusion pour déterminer le DFSP responsable d'une adresse de paiement donnée (« revendiquez-vous cette adresse »), mais doit développer un protocole pour gérer les conflits si plus d'un DFSP « revendique » l'adresse.
+
+- Il est important de noter que la méthode de résolution peut être différente pour chaque type d'adresse de paiement pris en charge. Certains types d'adresses de paiement pris en charge peuvent également être accompagnés d'ensembles de données particuliers : par exemple, lorsqu'un paiement est effectué en règlement d'une facture, l'adresse de paiement peut être un certain type d'alias, et l'utilisation de cet alias peut être liée à des données de facture accompagnantes. Les codes QR dynamiques, par exemple, créeront une « demande de paiement » qui peut contenir l'identifiant commerçant pris en charge par le schéma (un alias) et le détail des données de transaction accompagnantes.
+
+La spécification Open API et le code de référence Mojaloop prennent en charge un large éventail de différents types d'adresses : numéro de mobile, compte bancaire, identité nationale, alias (« Quickshop\@abc »), etc.
+
+### 7.1 Alignement L1P — Adressage des paiements 
+
+Un adressage de paiement sécurisé et facile se rapporte à deux concepts importants dans Level One : la commodité pour l'utilisateur final et l'« ouverture ». Ce dernier point est particulièrement important pour permettre la concurrence et la mise à l'échelle rapide d'un système de paiement. Alors que les schémas (Level One et autres) à travers le monde luttent pour déterminer comment résoudre au mieux la question de l'adressage des paiements, quelques meilleures pratiques semblent émerger :
+
+- Bien que l'utilisation du numéro de mobile, en particulier, comme adresse ait un attrait évident, il semble y avoir une tendance à utiliser des alias — des identifiants sans signification supplémentaire. Cela est démontré en Inde avec le système UPI et dans le nouveau système en temps réel de l'Australie, où l'identifiant est appelé PAYID.
+
+- La portabilité des identifiants est souhaitable, tant du point de vue de la commodité de l'utilisateur que comme mécanisme pour éviter le « verrouillage DFSP ».
+
+- Comme mentionné ci-dessus, le répertoire doit assurer l'unicité de l'adresse de paiement au sein du système de paiement : toute adresse donnée ne peut mapper qu'à un seul DFSP. Cependant, un seul compte de transaction DFSP peut avoir plusieurs adresses de paiement qui y dirigent. Les DFSP ont la possibilité de créer des services à valeur ajoutée pour leurs clients, dans lesquels ils différencient le traitement des transactions acheminées vers eux via différentes adresses de paiement (sous réserve, bien sûr, des règles commerciales globales du schéma).
+
+## 8. Choix : Règlement inter-participants
+
+Les schémas de paiement doivent déterminer comment les DFSP participants régleront leurs obligations financières les uns envers les autres découlant des transactions interopérables. Il y a de multiples décisions à prendre concernant le modèle de règlement. Les modèles de règlement existants utilisés dans les systèmes de paiement de détail hérités comportent des contrôles importants sur les risques. En règle générale, les schémas d'aujourd'hui ont la possibilité de faire des choix en tirant parti de la technologie moderne et de la connectivité pour gérer ces risques de différentes manières. Certains des choix sont :
+
+- Règlement net, brut ou brut continu. Traditionnellement, le règlement net a été utilisé pour les systèmes de paiement de détail (pratiquement parlant, tous les systèmes sauf le RTGS). Certains systèmes de paiement de détail en temps réel utilisent maintenant le règlement brut (le SPEI du Mexique) ou prévoient de le faire (le Brésil). Certains systèmes utilisent un compte de règlement brut continu (le réseau RTP américain) : dans cette approche, les DFSP possèdent conjointement un compte unique à la banque de règlement, et les parts de propriété dans le compte mutualisé sont déterminées, à tout moment, par la position du grand livre du DFSP à la plateforme. Cette approche n'utilise pas d'écritures de règlement, de compensation ou de comptabilisation d'écritures de règlement.
+
+- Choix de la banque de règlement. La plupart des systèmes de paiement de détail interopérables utilisent la banque centrale du pays comme banque de règlement, mais il existe des exemples (règlement par réseau de cartes aux États-Unis) où une banque commerciale est utilisée comme banque de règlement.
+
+- Comptes de règlement dédiés ou polyvalents. Les comptes de règlement des DFSP, détenus à la banque de règlement, sont-ils dédiés au but du règlement du schéma, ou sont-ils utilisés à d'autres fins (autres règlements de schéma, soldes de réserve, etc.) également ? Dans un modèle de règlement brut continu, le compte mutualisé est toujours un compte dédié.
+
+- Règlement le jour même ou différé. Dans un modèle de règlement net, les écritures de règlement sont-elles comptabilisées sur les comptes de la banque de règlement le jour de la transaction, ou plus tard ?
+
+- Fenêtres de règlement multiples ou uniques. Dans un modèle de règlement net, y a-t-il une seule fenêtre de règlement par jour ouvrable, ou y en a-t-il plusieurs ? Si multiples, les fenêtres sont-elles définies par des périodes de temps, le volume de transactions ou un autre facteur ?
+
+- Pré-financé ou non. Les écritures de règlement (dans un système net) ou les transactions individuelles (dans un système brut) sont-elles autorisées si le financement du compte de la banque de règlement n'est pas suffisant ? Si oui, quels mécanismes (lignes de crédit, comptes de garantie, etc.) sont utilisés pour couvrir ce risque ? Le terme « pré-financé » est utilisé lorsque les règles du schéma spécifient que le DFSP doit avoir suffisamment d'argent sur son compte de règlement pour couvrir une transaction sortante : sinon, la plateforme refusera la transaction.
+
+- Gestion dynamique de la position ou non. Dans un système de règlement net qui utilise un commutateur, le commutateur « connaît-il » la position réelle du DFSP émetteur avant d'envoyer la transaction au DFSP récepteur ?
+
+- Calcul automatisé ou manuel du plafond de débit net. Le plafond de débit net est un montant que le système utilise, en conjonction avec la gestion dynamique de la position, pour déterminer si une transaction individuelle est envoyée ou non au DFSP récepteur. Cela peut être soit fixé manuellement par le schéma (individuellement pour chaque DFSP) soit automatisé : ce dernier nécessite une connexion en temps réel entre le compte de la banque de règlement (dédié) et le commutateur.
+
+- Des composantes discrétionnaires du plafond de débit net peuvent être définies par le schéma. Il en existe deux types. Une composante discrétionnaire du schéma peut s'ajouter ou se soustraire au plafond de débit net d'un DFSP individuel. Un ajout peut être utilisé pour créer une marge de sécurité ; une soustraction peut être utilisée pour étendre les capacités de découvert au DFSP. Dans ce dernier cas, la responsabilité du découvert doit être clairement convenue entre le schéma et la banque de règlement.
+
+### 8.1 Alignement L1P — Règlement inter-participants
+
+Level One a un principe clair appelant au règlement le jour même. En dehors de cela, les considérations les plus importantes sont la manière dont un schéma donné gérera le risque et les coûts pour les DFSP — les coûts de liquidité en particulier. Il s'agit d'un domaine en évolution rapide dans les systèmes de paiement, et il est prévu que différents schémas feront des choix différents. En général, on peut observer que l'automatisation soutient la mise à l'échelle, et que le pré-financement et les fenêtres multiples soutiennent un risque et un coût faibles.
+
+Le code de référence Mojaloop prend en charge une variété de mécanismes de règlement différents.
+
+## 9. Choix : Accès par paliers
+
+Les systèmes de paiement de détail hérités (et les systèmes de gros) prennent généralement en charge l'accès par paliers — la capacité pour les institutions plus petites d'accéder au système via des relations de correspondance avec des institutions plus grandes. Cela a été considéré nécessaire car les institutions plus petites avaient fréquemment des difficultés à remplir les obligations de règlement de la participation directe ou les obligations techniques (en particulier la sécurité) de la participation directe.
+
+Dans les pays disposant de licences d'émission de monnaie électronique (ou d'autres DFSP non traditionnels, ou de fournisseurs de comptes de transaction), la question devient de savoir si ces fournisseurs non traditionnels accèdent au système directement ou par le biais d'une relation avec une banque traditionnelle : dans ces cas, c'est généralement la question du règlement, et non la question technique, qui est en jeu.
+
+### 9.1 Alignement L1P — Accès par paliers
+
+Il n'y a pas de principe Level One unique qui orienterait un schéma sur la manière de traiter cette question. Il y a, cependant, des questions de coût et de risque à considérer :
+
+- Il convient de noter que les grandes institutions ont créé des activités très rentables en servant ces institutions plus petites. Ces coûts, supportés par les participants indirects, seront d'une certaine manière répercutés sur les utilisateurs finaux. Pour cette raison, les schémas Level One pourraient vouloir éviter ce modèle lorsque c'est possible.
+
+- Le principe Level One de « boucle ouverte » suggère qu'un schéma devrait soutenir la capacité de tous les DFSP à participer directement partout où c'est possible : la technologie moderne, telle que celle utilisée par Mojaloop, et les modèles de règlement pré-financés devraient rendre cela plus simple.
+
+- Les systèmes hérités tendent également à « cacher » l'activité de l'institution plus petite au schéma ou au Hub. Cela peut être indésirable du point de vue réglementaire ou de la gestion des risques. Certains nouveaux systèmes de paiement de détail en temps réel (notamment le réseau RTP américain) permettent à la fois l'accès indirect technique et de règlement avec une transparence totale de l'institution plus petite vis-à-vis du schéma et de la plateforme.
+
+- Un autre facteur à considérer est particulier aux pays disposant d'émetteurs de monnaie électronique ou d'autres fournisseurs DFSP non traditionnels. Selon le principe L1P d'implication des DFSP dans les décisions de gouvernance, il se peut que demander aux émetteurs de monnaie électronique d'accéder à un système « sous » un participant bancaire puisse laisser ces DFSP dans une position de « second rang » en ce qui concerne la gouvernance : cela est sans doute indésirable, et en particulier dans les cas, qui semblent pertinents dans certains pays, où les émetteurs de monnaie électronique ont un volume de transactions plus élevé que leurs banques sponsors.
+
+Notez que cette section ne traite pas de l'accès au système par d'autres FSP : cela est abordé dans [Choix : Utilisation du schéma par d'autres FSP](#_13-choix-utilisation-du-schema-par-d-autres-fsp).
+
+## 10. Choix : Frais du schéma et tarification pour l'utilisateur final
+
+Les frais associés à un schéma de paiement interopérable peuvent être catégorisés comme :
+
+-   Frais pour l'utilisateur final : les frais (ou exigences de solde minimum, etc.) évalués par un DFSP à son client utilisateur final. Cela inclut les frais facturés aux consommateurs, commerçants, émetteurs de factures, gouvernements ou autres entreprises. Certains de ces frais sont spécifiquement liés au transfert interopérable lui-même (par ex. un frais d'« envoi de transfert » ou un « frais d'escompte commerçant ») ; d'autres sont connexes (un frais de « décaissement », un frais de retrait au GAB). Ces frais sont généralement fixés par le DFSP. Dans certains pays et situations, la réglementation ou les accords de règles du schéma peuvent s'appliquer ou influencer les frais. Les frais peuvent être des montants fixes ; des pourcentages de valeur, ou une combinaison de montants fixes et de pourcentage de valeur. Dans tous les cas, les grilles tarifaires peuvent différer en fonction des tranches de valeur (par exemple, les transactions inférieures à la valeur « X » ont ce frais) ou du volume de transactions de l'utilisateur final.
+
+- Frais de traitement : les frais que le schéma et l'opérateur de la plateforme (si différent) facturent aux DFSP pour l'utilisation du schéma et de la plateforme. Comme pour les frais pour l'utilisateur final, les frais de traitement peuvent être fixes ou variables et peuvent également varier selon la tranche de valeur ou le volume de transactions.
+
+- Frais d'interchange : frais qu'un DFSP paie à un autre DFSP liés à une transaction interopérable. Les frais d'interchange sont normalement fixés par le schéma (dans les règles du schéma) et sont physiquement tabulés et collectés par le schéma. Le schéma et l'opérateur de la plateforme ne paient ni ne reçoivent ces frais : ils constituent un débit pour un DFSP et un crédit pour l'autre. Tant le taux des frais d'interchange que la direction (le DFSP payeur paie-t-il ou reçoit-il ?) peuvent varier selon le cas d'utilisation et le cas d'utilisation secondaire. Les frais d'interchange peuvent être fixes, un pourcentage de la valeur, ou une combinaison des deux.
+
+En plus de fixer les politiques de frais, les schémas devront décider de la manière dont les frais sont collectés et (dans le cas des frais d'interchange) distribués. Il y a une considération importante avec l'interchange : les frais doivent-ils être collectés et distribués dans le cadre du règlement de chaque transaction, ou sous forme de facturation en fin de période (comme mensuellement) ?
+
+### 10.1 Alignement L1P : Frais
+
+L'un des concepts Level One les plus importants est d'avoir une plateforme à coût ultra-faible, avec des frais pour les consommateurs et les petits commerçants aussi bas que possible. Un élément important pour y parvenir dans un système de paiement est d'atteindre l'échelle. Les schémas voudront considérer ces deux facteurs lorsqu'ils fixeront les politiques de frais. Les considérations incluent :
+
+- **Tarification pour l'utilisateur final.** Le schéma est-il en position de mettre des contrôles ou des limitations à ce sujet ? La réponse variera selon la juridiction. Certains schémas ont mis des limitations sur la structure des frais (par ex. doit être fixe vs pourcentage de la valeur), sur les parties pouvant être facturées (par ex. les payeurs peuvent être facturés mais pas les bénéficiaires, etc.) ou sur ce que les frais globaux peuvent être. Certains schémas n'ont pas écrit cela dans les règles mais ont encouragé des accords informels sur les politiques de frais (sous réserve des approbations réglementaires) pour inciter l'utilisation par les consommateurs. D'autres schémas ont interdit certains types d'actions tarifaires, comme facturer des surcharges pour les transactions interopérables.
+
+- **Frais de traitement.** L'objectif ici est que les frais du schéma aux DFSP soient aussi bas que possible (spécifiquement et idéalement, une fraction d'un cent américain). Les meilleures pratiques du marché sont que ces frais soient fixes, plutôt qu'un pourcentage de la valeur : cela a du sens étant donné que le schéma et la plateforme ne prennent pas de risque de valeur dans le traitement des transactions. Cependant, il y a un défi avec des frais purement fixes : comment éviter d'avoir des frais trop élevés pour les transactions de très faible valeur. Certains schémas abordent cela par des tranches de valeur, avec des frais fixes inférieurs pour les transactions en dessous d'une certaine valeur. Certains schémas établissent des paliers de volume pour inciter les DFSP. Les schémas peuvent souhaiter encourager (ou même imposer) que les DFSP acheminent les transactions « on-us » (où le DFSP payeur et le DFSP bénéficiaire sont la même institution) via la plateforme : si tel est le cas, le schéma peut souhaiter fixer un frais nul pour ces transactions. Certains schémas peuvent également facturer des frais d'adhésion et/ou d'intégration aux DFSP. Enfin, certains schémas peuvent prévoir une période après le lancement du schéma pendant laquelle tous les frais sont supprimés.
+
+- **Frais d'interchange**. Il s'agit d'un sujet complexe et souvent débattu dans l'industrie du paiement mondial, et qui attire fréquemment l'attention des régulateurs. Les schémas peuvent vouloir considérer :
+
+    - S'il faut ou non avoir de l'interchange. Certains systèmes de paiement en ont ; beaucoup n'en ont pas. Les systèmes de paiement de détail en temps réel dans le monde sont partagés sur la question de savoir s'ils prennent en charge l'utilisation de l'interchange, et là où ils le font, dans quelle direction l'interchange circule pour des cas d'utilisation tels que le P2P.
+
+    - L'interchange est un mécanisme utile pour une forme de facturation : lorsque le receveur d'un service de valeur (comme un commerçant qui veut accéder au compte de paiement d'un consommateur) n'a pas de relation avec le fournisseur de ce service (le DFSP du consommateur). Un autre exemple est celui où le GAB d'une banque est utilisé pour distribuer des fonds au client d'une autre banque.
+
+    - L'interchange est plus discutable lorsqu'il est utilisé pour soutenir des modèles commerciaux hérités : par exemple, si une transaction interopérable fait « perdre » à un DFSP payeur un frais de décaissement qu'il aurait autrement gagné, le schéma peut spécifier un taux d'interchange dans lequel le DFSP bénéficiaire paie le DFSP payeur pour compenser cette perte. Il peut être pratique d'utiliser l'interchange dans ces situations à court terme, mais à long terme on peut argumenter que le modèle commercial sous-jacent doit évoluer.
+
+    - Les schémas doivent garder à l'esprit que partout où l'interchange est utilisé, un « coût dur » est créé qui est absorbé par, et probablement répercuté dans les frais pour l'utilisateur final, par le DFSP payant l'interchange.
+
+## 11. Choix : Gestion de la marque
+
+Faut-il utiliser une marque de schéma ? La même marque doit-elle être utilisée pour tous les cas d'utilisation ? Ou la seule marque utilisée doit-elle être la marque du DFSP qui offre un service à ses clients ? Sans surprise, c'est une question qui a été débattue dans les systèmes de paiement au fil des ans.
+
+### 11.1 Alignement L1P — Marque
+
+Level One a un principe de conception clair soutenant une marque commune : cela repose sur le fait de rendre le service compréhensible et facile à utiliser pour les consommateurs et les commerçants. Une marque commune de schéma peut être utilisée en conjonction avec les marques des DFSP : « Utilisez DFSP SuperPay (marque DFSP) avec XPay (marque du schéma) pour payer vos factures. »
+
+Les règles commerciales devront spécifier comment et où la marque commune est utilisée.
+
+## 12. Choix : Connexions du schéma avec d'autres schémas
+
+L'avènement de systèmes de paiement de détail en temps réel à peu près similaires dans le monde a conduit à de nombreuses discussions sur l'opportunité de connecter ces schémas entre eux. Cela peut faciliter les transactions au sein d'un pays, mais a notamment une importance pour les paiements transfrontaliers de toutes sortes, y compris les transferts de fonds des travailleurs.
+
+Dans les systèmes de paiement hérités, ce type de connexion est rare sur une base de schéma à schéma. Des exceptions notables incluent la connexion domestique des réseaux de GAB, et la connexion de schémas de cartes domestiques qui sont détenus ou contrôlés par des réseaux de cartes mondiaux. Ce qui se passe, au lieu de cela, c'est que les DFSP ou d'autres fournisseurs qui participent à plusieurs réseaux (soit directement, soit par le biais de partenariats) créent l'effet d'une connexion inter-schémas par des accords individuels : c'est, essentiellement, le fonctionnement de la banque correspondante transfrontalière.
+
+Mojaloop en tant que technologie est conçu pour permettre la connectivité système à système. Les schémas mettant en œuvre des systèmes Mojaloop devront considérer l'équilibre entre conclure des accords commerciaux de schéma à schéma (avec des connexions techniques concomitantes) et/ou permettre aux DFSP de leur schéma de se connecter bilatéralement à d'autres schémas ou DFSP.
+
+### 12.1 Alignement L1P — Connexions avec d'autres schémas
+
+Les principes L1P pertinents ici sont le faible coût et l'« ouverture ». Le code Mojaloop en particulier a le potentiel de transformer les transactions transfrontalières, qui sont régies par des relations complexes (comme dans le cas de la banque correspondante traditionnelle), en transactions qui font l'objet de concurrence dans un marché ouvert et interconnecté. Les schémas devront évaluer les mérites de cela (promouvant sans doute des coûts plus bas) avec les risques de dominance par les grandes institutions. Les arrangements commerciaux de schéma à schéma peuvent avoir des caractéristiques bénéfiques d'« égalisation des chances ». Des relations hybrides sont également possibles. Il s'agit d'un domaine en évolution de l'industrie du paiement, et un domaine où une variété considérable d'arrangements sont à la fois possibles et probables.
+
+## 13. Choix : Utilisation du schéma par d'autres FSP
+
+Un schéma aligné L1P réussi sera utilisé par de nombreuses entreprises — commerçants, émetteurs de factures, agences gouvernementales, etc. — ainsi que par des individus. Il y aura également un large éventail d'autres FSP (fournisseurs de services financiers) qui ne sont pas des DFSP : en d'autres termes, qui ne détiennent pas de comptes de transaction des clients. Cela inclut les fournisseurs de services de paiement : agrégateurs, fournisseurs de services aux commerçants, divers processeurs de DFSP, etc., qui peuvent tous vouloir se connecter et utiliser le schéma.
+
+Comme décrit dans le choix « participation » ci-dessus, un schéma aligné Level One inclut comme participants directs et réglants uniquement les entités qui détiennent les comptes de transaction des utilisateurs finaux : les comptes qui sont débités et crédités à la suite de la transaction interopérable.
+
+D'autres entités peuvent se connecter physiquement à la plateforme dans le cadre de divers arrangements commerciaux. Le schéma devra décider à quel point les règles commerciales du schéma sont impliquées dans la dictée des termes ou normes de ces arrangements. En règle générale, tout autre FSP se connectant à la plateforme devra agir pour le compte d'un DFSP dont le compte de transaction du client est débité (le DFSP payeur) ou crédité (le DFSP bénéficiaire). Dans les modèles de paiement hérités, le DFSP conserve toutes les obligations financières et responsabilités de la transaction : le tiers agit purement pour le compte du DFSP. Les règles commerciales du schéma peuvent spécifier des exigences pour les arrangements commerciaux entre le DFSP et le tiers. Dans certaines juridictions (notamment l'Inde et l'UE), la réglementation pousse à des changements de ce modèle pour permettre aux autres FSP d'avoir une implication plus directe dans les schémas. Les règles du schéma devront décrire et prescrire soigneusement les paramètres de ces arrangements.
+
+Note de définition : nous n'utilisons intentionnellement pas le terme « PSP » (Prestataire de services de paiement) ici, car dans diverses juridictions, ce terme est utilisé pour inclure les fournisseurs de comptes de transaction, dans certains cas, et les fournisseurs de comptes non-transactionnels dans d'autres cas. En commentaire supplémentaire, dans de nombreux pays aujourd'hui, des entités telles que les agrégateurs détiennent des comptes financiers dans des banques ou chez des émetteurs de monnaie électronique et utilisent ces comptes pour recevoir de l'argent des clients et distribuer de l'argent à d'autres clients. Dans ce rôle, l'agrégateur est un client d'un DFSP (la banque ou l'émetteur de monnaie électronique) et agit également en tant que fournisseur de services financiers. Il se peut que ces agrégateurs, à l'avenir, n'aient pas besoin d'intermédier la transaction financière, mais fournissent plutôt des instructions conduisant au transfert direct de fonds, via le schéma, du compte de transaction d'un client à celui d'un autre.
+
+### 13.1 Alignement L1P — Utilisation par d'autres FSP
+
+Les principes ici sont, encore une fois, le faible coût et l'ouverture. Level One encouragerait les nouveaux acteurs à pouvoir utiliser et accéder au schéma, tant que leurs actions sont contrôlées par le schéma afin d'assurer la sécurité et la stabilité financière.
+
+## 14. Choix : Normes de gestion des risques du schéma
+
+Les schémas de paiement, leurs plateformes et les DFSP participants ainsi que les tiers doivent tous, évidemment, fonctionner selon des normes de gestion des risques solides afin d'assurer un écosystème de systèmes de paiement sain.
+
+La question pour un schéma est l'équilibre entre définir ces normes lui-même et s'appuyer sur d'autres normes. Du point de vue des règles commerciales, c'est un choix significatif. Les schémas peuvent soit :
+
+- Développer des normes détaillées de gestion des risques pour les DFSP (et pour la plateforme) et mener des processus rigoureux de certification et/ou d'audit pour assurer la conformité
+
+- Exiger que les DFSP, la plateforme et les tiers suivent les normes nationales ou mondiales référencées en matière de gestion des risques et de sécurité
+
+### 14.1 Alignement L1P — Normes de gestion des risques
+
+Level One ne traite pas de quel choix ci-dessus est le meilleur. Mais les concepts d'un système sûr pour les consommateurs et d'un système à faible coût s'appliquent clairement ici. Quelques considérations :
+
+- Un utilitaire partagé de gestion de la fraude (que les principes Level One soutiennent) peut gérer de manière rentable certaines des tâches de gestion de la fraude. Cela ne réduit pas la charge de conformité individuelle d'un DFSP, mais déplace simplement la manière dont il remplit cette charge.
+
+- Les réseaux de cartes mondiaux ont effectivement démontré la capacité d'automatiser des éléments du traitement des exceptions, en se concentrant sur les transactions qui se produisent le plus fréquemment.
+
+- La communauté Mojaloop a exprimé son intérêt pour la codification des exceptions et la fourniture d'un support par le code pour certains processus.
+
+- La communauté Mojaloop peut également développer des documents de meilleures pratiques pour traiter les domaines de la gestion des risques, y compris la cybersécurité.
+
+## 15. Choix : Gestion des exceptions
+
+Le traitement des exceptions comprend une grande variété de transactions et d'interactions non standard parmi les utilisateurs et les fournisseurs d'un schéma de paiement. Celles-ci incluent :
+
+- Les erreurs de la part des utilisateurs finaux
+
+- Les erreurs de la part des DFSP, de la plateforme ou d'autres FSP
+
+- La fraude commise par les clients utilisateurs finaux, y compris les individus, les commerçants, les émetteurs de factures ou d'autres entités
+
+- La fraude commise par des tiers, y compris les pirates informatiques
+
+- Les attaques malveillantes sur le système ou sur des DFSP individuels, y compris les cyberattaques.
+
+Les schémas ont des choix importants à faire sur le degré d'implication du schéma et de ses règles commerciales dans la définition de la manière dont les participants au schéma gèrent ces exceptions. Les systèmes de paiement hérités nous montrent une grande variété de modèles utilisés, allant de systèmes où le schéma et les règles commerciales ont une implication minimale dans le traitement des exceptions (chèques, la plupart des systèmes ACH) à des systèmes où le schéma et ses règles commerciales sont largement impliqués (la plupart des réseaux de cartes). Les systèmes de paiement de détail en temps réel dans le monde n'en sont généralement qu'aux premiers stades de la décision sur la manière de traiter ces questions.
+
+### 15.1 Alignement L1P — Traitement des exceptions
+
+Il y a deux principes de conception Level One très importants qui s'y rapportent.
+
+- L'un est le principe d'irrévocabilité des transactions. Cela signifie qu'une transaction de paiement qui est complétée avec succès (dans une implémentation Mojaloop, une qui a été exécutée) ne peut pas être annulée sans le consentement du bénéficiaire.
+
+- L'autre est l'engagement envers une ressource partagée de gestion de la fraude au niveau de la plateforme. L'idée est que le schéma et sa plateforme auront une vue plus large de toutes les données de transaction et seront en mesure d'effectuer des tâches de détection et de gestion de la fraude plus efficacement et à moindre coût que les DFSP individuels. Ce concept en est à ses tout premiers stades d'évolution à mesure que les systèmes Level One sont déployés, tant avec que sans la technologie Mojaloop.
+
+Les schémas feront face à des défis significatifs dans ce domaine alors que le déploiement tant attendu des paiements commerçants se produit, en particulier dans les marchés moins développés qui ne disposent pas d'industries de paiement par carte très pénétrées. Le défi sera d'équilibrer le désir de protéger les consommateurs contre la fraude des commerçants avec le désir d'avoir une tarification à faible coût pour l'utilisateur final. Sur les marchés développés de paiement par carte, cela est souvent assuré par des règles commerciales qui spécifient que la banque du commerçant est financièrement responsable de la fraude commise par le commerçant. Cela fonctionne mais entraîne des frais de transaction relativement élevés pour le commerçant, car sa banque doit couvrir son exposition au risque en vertu de ces règles. Ce modèle financier peut ou non être viable dans les économies moins développées. C'est un autre domaine où nous anticipons une évolution considérable dans les années à venir.
diff --git a/docs/fr/adoption/Scheme/scheme-participation-agreement.md b/docs/fr/adoption/Scheme/scheme-participation-agreement.md
new file mode 100644
index 00000000..d987354c
--- /dev/null
+++ b/docs/fr/adoption/Scheme/scheme-participation-agreement.md
@@ -0,0 +1,76 @@
+# Modèle d'accord de participation au schéma
+
+- Version : 3.0 
+    - Auteur : Carol Coye Benson (Glenbrook) 
+    - Date : Octobre 2019
+    - Description : 
+
+---
+
+## **À propos du projet de documents commerciaux de la communauté Mojaloop**
+
+Ce document fait partie du projet de documents commerciaux de la communauté Mojaloop. Le projet est destiné à soutenir les entités (pays, régions, associations de fournisseurs ou entreprises commerciales) mettant en œuvre de nouveaux systèmes de paiement utilisant le code Mojaloop. Ces entités devront également rédiger des règles commerciales que les participants au système suivront.
+
+Le projet de documents commerciaux de la communauté Mojaloop fournit des modèles pour les règles commerciales et les documents associés. De nombreux choix sont impliqués dans la mise en œuvre d'un nouveau système de paiement : les modèles présentent certains de ces choix et, le cas échéant, des commentaires sont fournis sur la manière dont le choix particulier est lié aux objectifs d'un système aligné sur Level One.
+
+Les documents suivants font partie du projet :
+
+- Choix clés du schéma
+
+- Modèle d'accord de participation au schéma
+
+- Modèle de règles commerciales du schéma
+
+- Modèle de directive opérationnelle de la plateforme
+
+- Modèle de directive opérationnelle de gestion des exceptions
+
+- Glossaire uniforme
+
+# Table des matières
+
+[1 - Demande de participation et accord](#_1-demande-de-participation-et-accord)
+    
+[1.1 - Droit applicable](#_1-1-droit-applicable)
+
+[1.2 - Bloc de signature : Candidat et schéma](#_1-2-bloc-de-signature-candidat-et-schema)
+
+# 1. Demande de participation et accord
+
+::: tip NOTE
+L'objectif de ce document est qu'il contienne les dispositions minimales nécessaires pour attester de la demande d'un DFSP de rejoindre le schéma et de respecter ses règles commerciales. En particulier, les modifications futures des règles commerciales ne devraient pas entraîner la nécessité de re-signer ou de modifier cet accord.
+:::
+
+L'organisation soussignée (« _Candidat_ ») demande par la présente sa participation au \[Schéma\], une \[forme juridique de société\] organisée et existante en vertu des lois de \[définir\] et, si elle est acceptée par le \[Schéma\], le Candidat accepte que sa participation au schéma sera soumise aux termes et conditions suivants. Cette demande et cet accord sont datés du \_\_\_\_\_\_\_\_\_\_\_\_\_\_ et entreront en vigueur et seront contraignants pour le Candidat à compter de la date indiquée ci-dessous lorsqu'ils seront signés au nom du \[Schéma\] (la « *Date d'entrée en vigueur* »). À compter de la date d'entrée en vigueur, le Candidat sera appelé un « *Participant* ». Le Candidat reconnaît que cette demande de participation et cet accord sont soutenus par une contrepartie mutuelle adéquate. Les termes non définis dans cette demande et cet accord auront les significations telles que définies dans les règles commerciales, comme défini ci-dessous.
+
+- Le Candidat sera lié par et respectera toutes les dispositions des règles commerciales.
+
+- Les règles commerciales comprennent les règles commerciales et les documents associés et autres documents qui peuvent être désignés comme documents associés de temps à autre par le schéma. Les règles commerciales et les documents associés incluent tous les autres documents tels que désignés dans ces documents.
+
+- Le schéma peut modifier les règles commerciales de temps à autre comme il le juge approprié, en fournissant aux participants un préavis raisonnable des changements ou ajouts que le schéma peut juger approprié dans les circonstances.
+
+- Les participants paieront les frais tels que spécifiés dans les règles commerciales.
+
+- Résiliation :
+
+    - Un participant peut résilier sa participation à tout moment sans motif moyennant un préavis écrit de X jours. Cette résiliation sera soumise aux dispositions des règles commerciales concernant les coûts et les procédures de cessation des opérations du participant par rapport au schéma. Le participant restera responsable de tous les frais et autres charges et responsabilités encourus en vertu des règles commerciales jusqu'à la date effective de la résiliation.
+
+    - Le schéma peut résilier un participant pour les motifs prévus dans les règles commerciales.
+
+    - La résiliation d'un participant pour motif sera soumise aux obligations de résiliation et aux procédures spécifiées dans les règles commerciales.
+
+    - Licence. Le participant se voit accorder une licence pour participer, y compris l'utilisation de la propriété du schéma, selon les termes spécifiés dans les règles commerciales. Le participant est autorisé à fournir des services en utilisant les composants de traitement du schéma et la marque du schéma et à utiliser la propriété du schéma dans les pays suivants :
+
+    - Soumissions d'informations. Le candidat garantit et déclare que toutes les informations soumises au schéma à l'appui de cette demande de participation et de cet accord sont correctes et complètes à la date de cette demande.
+
+## 1.1 Droit applicable
+
+- Choix du droit. Cette demande et cet accord et les règles commerciales seront interprétés et appliqués conformément aux lois de \[spécifier\] et non par les dispositions de ces lois qui détermineraient les lois de quelle juridiction s'appliqueraient en l'absence de cette clause de choix du droit.
+
+- Le schéma et le participant exécuteront toutes les prestations en rapport avec le schéma conformément au droit applicable.
+
+- Les règles commerciales ne seront pas comprises comme exigeant toute action qui amènerait le schéma ou le participant à violer le droit applicable. Tout conflit entre le droit applicable et une disposition des règles commerciales sera résolu conformément aux procédures spécifiées dans les règles commerciales. Aucune résolution de ce type n'exigera du participant ou du schéma qu'il prenne une mesure ou s'abstienne de toute mesure qui l'amènerait à violer le droit applicable.
+
+Le candidat a fait signer cette demande et cet accord de participation au nom du candidat par la personne indiquée ci-dessous sous réserve des garanties et déclarations du candidat selon lesquelles cette personne a été autorisée par toutes les actions nécessaires et appropriées de la société à conclure cette demande et cet accord de participation à la date indiquée ci-dessus et que, lorsqu'ils seront signés au nom du candidat et acceptés par le schéma, ils constitueront une obligation contraignante et exécutoire du candidat à compter de la date indiquée ci-dessous.
+
+## 1.2 Bloc de signature : Candidat et schéma
diff --git a/docs/fr/adoption/Scheme/scheme-uniform-glossary.md b/docs/fr/adoption/Scheme/scheme-uniform-glossary.md
new file mode 100644
index 00000000..aa82d7e7
--- /dev/null
+++ b/docs/fr/adoption/Scheme/scheme-uniform-glossary.md
@@ -0,0 +1,299 @@
+# Modèle de glossaire uniforme
+
+- Version : 1.0 
+    - Auteur : Carol Coye Benson (Glenbrook)
+    - Date : Octobre 2019
+    - Description : 
+
+---
+
+## **À propos du projet de documents commerciaux de la communauté Mojaloop**
+
+Ce document fait partie du projet de documents commerciaux de la communauté Mojaloop. Le projet est destiné à soutenir les entités (pays, régions, associations de fournisseurs ou entreprises commerciales) mettant en œuvre de nouveaux systèmes de paiement utilisant le code Mojaloop. Ces entités devront également rédiger des règles commerciales que les participants au système suivront.
+
+Le projet de documents commerciaux de la communauté Mojaloop fournit des modèles pour les règles commerciales et les documents associés. De nombreux choix sont impliqués dans la mise en œuvre d'un nouveau système de paiement : les modèles présentent certains de ces choix et, le cas échéant, des commentaires sont fournis sur la manière dont le choix particulier est lié aux objectifs d'un système aligné sur Level One.
+
+Les documents suivants font partie du projet :
+
+- Choix clés du schéma
+
+- Modèle d'accord de participation au schéma
+
+- Modèle de règles commerciales du schéma
+
+- Modèle de directive opérationnelle de la plateforme
+
+- Modèle de directive opérationnelle de gestion des exceptions
+
+- Glossaire uniforme
+
+## **Introduction**
+
+Ceci est un glossaire des termes utilisés dans le projet de documents commerciaux de la communauté Mojaloop, et contient d'autres termes liés aux sujets commerciaux. Un glossaire technique plus détaillé est disponible dans le cadre de la spécification Open API for FSP Interoperability.
+
+# Modèle de glossaire uniforme
+
+| Terme   | Définition                                                                                      |
+| :----- | :---------------------------------------------------------------------------------------------- | 
+| Canal d'accès | Lieux ou capacités utilisés pour initier ou recevoir un paiement. Les canaux d'accès peuvent inclure les succursales bancaires, les GAB, les terminaux au point de vente, les points d'agents, les téléphones mobiles et les ordinateurs. |
+| Recherche de compte | Un processus qui détermine le DFSP responsable d'un compte de transaction. |
+| Système de recherche de compte | Le système de recherche de compte est une entité abstraite utilisée pour récupérer des informations concernant le FSP dans lequel un compte, un portefeuille ou une identité est hébergé. Le système de recherche de compte lui-même peut être hébergé sur son propre serveur, dans le cadre d'un commutateur financier, ou dans les différents FSP. |
+| Validation de compte | Un statut fourni par un appel API de réponse au devis : un DFSP bénéficiaire indique qu'un compte est disponible pour être crédité du montant de transfert proposé. |
+| Utilisateur actif | Un terme utilisé par de nombreux fournisseurs pour décrire combien de leurs titulaires de compte sont des utilisateurs fréquents de leur service. |
+| Adressage | L'utilisation d'un identifiant pour diriger un paiement d'un payeur vers un bénéficiaire, généralement un numéro de téléphone mobile ou une adresse e-mail. |
+| Adjacences | Moyens par lesquels les entités et/ou les DFSP réalisent des revenus à partir de services qui ne sont pas directement associés à un paiement — par exemple, les prêts accordés aux titulaires de comptes de transaction. |
+| Agent | Une entité autorisée par le fournisseur à gérer diverses fonctions telles que l'inscription des clients, l'encaissement et le décaissement à l'aide d'une caisse d'agent. |
+| Point d'agent | Un emplacement physique qui possède une ou plusieurs caisses d'agent, lui permettant d'effectuer des transactions d'inscription, d'encaissement et de décaissement pour les clients au nom d'un ou plusieurs fournisseurs. La législation nationale définit si un point d'agent peut rester exclusif à un seul fournisseur. Les points d'agent peuvent avoir d'autres activités commerciales et fonctions de support. |
+| Caisse d'agent | Une caisse d'agent est une « ligne » enregistrée émise par le fournisseur, soit une carte SIM spéciale, soit une machine TPV, utilisée pour effectuer des transactions d'inscription, d'encaissement et de décaissement pour les clients. La législation nationale dicte quels fournisseurs de services financiers peuvent émettre des caisses d'agent. |
+| Encaissement initié par l'agent | Un cas d'utilisation défini dans le document des spécifications API. |
+| Décaissement initié par l'agent | Un cas d'utilisation défini dans le document des spécifications API. |
+| Agrégateur | Une forme spécialisée de fournisseur de services aux commerçants, qui gère généralement les transactions de paiement pour un grand nombre de petits commerçants. Les règles du schéma précisent souvent ce que les agrégateurs sont autorisés à faire. |
+| Alias | Un identifiant de bénéficiaire qui est mappé à un DFSP bénéficiaire et à un numéro de compte de transaction. |
+| Lutte contre le blanchiment d'argent (AML) | La lutte contre le blanchiment d'argent fait référence au droit applicable et, dans la mesure expressément adoptée par le schéma, aux guides de bonnes pratiques, concernant l'atténuation des risques de blanchiment d'argent. |
+| API | Interface de programmation d'applications : une interface technique mise en œuvre par un protocole logiciel qui permet aux systèmes d'interagir les uns avec les autres via des structures standard, sans qu'un système utilisateur ait besoin de connaître les détails de mise en œuvre interne du système avec lequel il interagit. |
+| Droit applicable | Tous les traités, conventions, lois, règlements, directives, orientations officielles ou directives d'une autorité de régulation dans la mesure où ils sont contraignants, respectivement, pour le schéma ou un participant en ce qui concerne les services du schéma. |
+| Candidat | Une organisation qui a soumis ou souhaite soumettre une demande pour devenir participant, mais dont la demande n'a pas été traitée par le schéma. |
+| Interface de programmation d'applications (API) | Une méthode de communication permettant l'interaction et le partage de données entre différents logiciels ou protocoles techniques. |
+| Arbitrage | L'utilisation d'un arbitre, plutôt que des tribunaux, pour résoudre les litiges. |
+| Documents associés | L'ensemble des documents répertoriés dans l'annexe A de ces règles. |
+| Décaissement initié par GAB via OTP | Un cas d'utilisation défini dans le document des spécifications API. |
+| Attribut | Une caractéristique d'une transaction, étant entendu que des règles spécifiques peuvent s'appliquer aux transactions avec des attributs spécifiques. |
+| Authentification | Le processus consistant à s'assurer qu'une personne ou une transaction est valide pour le processus (ouverture de compte, initiation de transaction, etc.) en cours. |
+| Autorisation | La permission donnée par le payeur ou l'entité d'effectuer un paiement. |
+| Institution/entité autorisée | Institutions non financières qui ont suivi l'autorisation appropriée de la banque d'État et/ou des autorités réglementaires compétentes pour participer à la fourniture de services financiers mobiles. |
+| B2P | Entreprise à personne ; un cas d'utilisation secondaire de paiement en masse. |
+| Banque | Un système financier agréé dans un pays qui a la capacité d'accepter des dépôts et d'effectuer et de recevoir des paiements sur les comptes des clients. |
+| Compte bancaire | Un compte de transaction offert par une banque. |
+| Identifiant de compte bancaire | Un type d'identifiant de bénéficiaire. |
+| Services de comptes et de transactions bancaires | Un compte de transaction détenu dans une banque. Ce compte peut être accessible par un téléphone mobile, auquel cas il est parfois appelé « banque mobile ». |
+| Banque à banque | Un cas d'utilisation secondaire P2P. |
+| Banque à portefeuille | Un cas d'utilisation secondaire P2P. |
+| Modèle piloté par les banques | Une référence à un système dans lequel les banques sont les principaux fournisseurs de services financiers numériques aux utilisateurs finaux. La législation nationale peut l'exiger. |
+| Téléphone basique | Appareil minimum requis pour utiliser les services financiers numériques. |
+| Paiement de facture | Un cas d'utilisation secondaire P2B. |
+| Authentification biométrique | L'utilisation d'une caractéristique physique d'une personne (empreinte digitale, iris, etc.) pour authentifier cette personne. |
+| Liste noire | Une liste ou un registre d'entités (utilisateurs enregistrés) auxquelles un privilège, un service, une mobilité, un accès ou une reconnaissance particulière est refusé/bloqué. |
+| Blockchain | Une technologie qui crée des architectures distribuées. Dans les systèmes de paiement, souvent une référence à un registre partagé qui enregistre et valide les transactions. |
+| Blockchain | La technologie sous-jacente au bitcoin et à d'autres cryptomonnaies - un registre numérique partagé, ou une liste continuellement mise à jour de toutes les transactions. |
+| Marque | Un mot et/ou une marque approuvée par le schéma pour utilisation par les participants. |
+| Décaissement en masse | Un cas d'utilisation défini dans le document des spécifications API. |
+| Paiement en masse | Un paiement d'un seul payeur à plusieurs bénéficiaires, par exemple des programmes de transfert d'argent d'un gouvernement ou d'une ONG à un ensemble de bénéficiaires. |
+| Service de téléchargement en masse | Un service permettant l'importation de plusieurs transactions par session, le plus souvent via un fichier de transfert de données en masse utilisé pour initier des paiements. Exemple : fichier de paiement des salaires. |
+| Entreprise | Entité telle qu'une société publique à responsabilité limitée ou une société qui utilise la monnaie mobile comme service ; par exemple, effectuer et accepter des paiements de factures et verser des salaires. |
+| Gestion de la trésorerie | Gestion des soldes de trésorerie chez un agent. |
+| Encaissement | Recevoir un crédit en monnaie électronique en échange d'espèces physiques - généralement effectué chez un agent. |
+| Décaissement | Recevoir des espèces physiques en échange d'un débit sur un compte de monnaie électronique - généralement effectué chez un agent. |
+| Carte à puce | Une carte à puce contient une puce informatique : elle peut être soit sans contact, soit à contact (nécessite l'insertion dans un terminal). Les normes mondiales pour les cartes à puce sont définies par EMV. |
+| Compensation | Le processus au sein d'un système de paiement par lequel un DFSP payeur et un DFSP bénéficiaire débitent et créditent les comptes de leurs utilisateurs finaux. |
+| Boucle fermée | Un système de paiement utilisé par un seul fournisseur, ou un groupe très restreint de fournisseurs. |
+| Lutte contre le financement du terrorisme (CFT) | Initiatives visant à empêcher les individus ou les entités d'utiliser les systèmes de paiement pour envoyer des fonds à des individus ou des entités associés au terrorisme. |
+| Commission | Un paiement incitatif effectué, généralement à un agent ou à un autre intermédiaire qui agit au nom d'un fournisseur de services financiers numériques. Fournit une incitation pour l'agent. |
+| Engagement | Partie d'une opération de transfert en deux phases dans laquelle les fonds qui étaient réservés pour être transférés sont libérés au bénéficiaire ; le transfert est complété entre les comptes d'origine/payeur et de destination/bénéficiaire. |
+| Condition | Dans le protocole Interledger, un verrou cryptographique utilisé lorsqu'un transfert est réservé. Généralement sous la forme d'un hachage SHA-256 d'une pré-image secrète. Lorsqu'elle est fournie dans le cadre d'une demande de transfert, le transfert doit être réservé de telle sorte qu'il ne soit engagé que si l'accomplissement de la condition (la pré-image secrète) est fourni. |
+| Corridor | Désigne deux pays quelconques dans une transaction transfrontalière et la direction du transfert. |
+| Contrepartie | L'autre partie dans une transaction de paiement ou de crédit. Un bénéficiaire est la contrepartie d'un payeur, et vice versa. |
+| Coupon | Un jeton qui donne droit au porteur à une réduction ou qui peut être échangé contre des biens ou des services. |
+| Virement | Un paiement ou un transfert de fonds initié par le DFSP payeur au DFSP bénéficiaire. Un virement est souvent appelé « transfert de crédit par poussée » car les fonds sont « poussés » depuis le compte de transaction du payeur. Le virement contraste avec le prélèvement automatique. |
+| Transfrontalier | Un transfert d'un DFSP payeur domicilié dans un pays, vers un DFSP bénéficiaire domicilié dans un autre pays. |
+| Transfert multi-devises | Transfert impliquant plusieurs devises, y compris un calcul de change. |
+| Position actuelle | La position nette actuelle d'un participant dans le grand livre de position pour une devise donnée. |
+| Client | Le client du système. Le terme est utilisé tant pour le payeur que pour le bénéficiaire. Les individus, les commerçants, les émetteurs de factures, les gouvernements et les autres entreprises sont tous des clients. Parfois désignés comme utilisateurs finaux. |
+| Décaissement initié par le client | Un cas d'utilisation défini dans le document des spécifications API. |
+| Achat initié par le client | Un cas d'utilisation défini dans le document des spécifications API. |
+| Achat initié par le client via QR | Un cas d'utilisation défini dans le document des spécifications API. |
+| DFSP (Fournisseur de services financiers numériques) | Un fournisseur de services financiers autorisé par une autorité de régulation à fournir des comptes de transaction qui détiennent les fonds des clients et sont utilisés pour effectuer et recevoir des paiements. Les DFSP ont des relations avec les consommateurs, les commerçants et d'autres entreprises, et fournissent des services financiers numériques aux utilisateurs finaux. Utilisé de manière interchangeable avec FSP (Fournisseur de services financiers). |
+| Numérique | Communications électroniques entre deux individus ou entités pouvant se produire sur divers appareils électroniques (par ex. mobile, tablette, ordinateur). |
+| Liquidité numérique | Une pratique consistant à conserver la valeur sous forme numérique, plutôt que d'échanger la valeur numérique contre des espèces (forme physique). |
+| Paiement numérique | Un terme large incluant tout paiement exécuté électroniquement. Comprend les paiements initiés par téléphone mobile ou ordinateur. Les paiements par carte dans certaines circonstances sont considérés comme des paiements numériques. Le terme « paiement mobile » est tout aussi large et comprend une grande variété de types de transactions qui utilisent d'une manière ou d'une autre un téléphone mobile. |
+| Prélèvement automatique | Un paiement ou un transfert de fonds initié par le DFSP bénéficiaire au DFSP payeur. Un prélèvement automatique est souvent appelé « transfert de débit par tirage » car les fonds sont « tirés » du compte de transaction du payeur. Le prélèvement automatique contraste avec le virement. |
+| Répertoire | Un registre centralisé ou décentralisé d'identifiants de paiement à utiliser pour l'adressage, accessible par le système de paiement ou les DFSP. |
+| Résolution des litiges | Un processus spécifié par un fournisseur ou par les règles d'un schéma de paiement pour résoudre les problèmes entre les utilisateurs finaux et les fournisseurs, ou entre un utilisateur final et sa contrepartie. |
+| Domestique | Décrit une transaction entre deux DFSP domiciliés dans le même pays. |
+| Monnaie électronique | Fonds ou valeur numériques détenus par un titulaire de compte de transaction sur un dispositif de paiement tel qu'une puce, une carte prépayée, un téléphone mobile ou un système informatique. La réglementation nationale précise quels types de DFSP peuvent émettre de la monnaie électronique. |
+| Émetteur de monnaie électronique | Un DFSP autorisé dans le pays à agir en tant qu'émetteur de monnaie électronique. |
+| Utilisateur final | Le client d'un DFSP. Le client peut être un consommateur, un commerçant, un gouvernement ou une autre forme d'entreprise. |
+| Frais pour l'utilisateur final | Frais évalués par un DFSP à son client utilisateur final. |
+| Entreprise | Toute personne non individuelle qui est cliente d'un DFSP : comprend les commerçants, les émetteurs de factures, les agences gouvernementales et d'autres entreprises. |
+| Compte séquestre ou de fiducie | Un compte détenu par un DFSP non bancaire dans une banque ; normalement une exigence réglementaire pour protéger les dépôts des consommateurs auprès du DFSP. |
+| Exceptions | Transactions erronées ou frauduleuses. |
+| FATF | Le Groupe d'action financière est une organisation intergouvernementale pour lutter contre le blanchiment d'argent et agir contre le financement du terrorisme. |
+| Téléphone basique | Un téléphone mobile sans capacités de calcul significatives. |
+| Frais | Les paiements évalués par un fournisseur à son utilisateur final. Il peut s'agir d'un frais fixe, d'un frais en pourcentage de la valeur, ou d'un mélange. |
+| Monnaies fiduciaires | Monnaie officielle émise par la banque centrale d'un pays ou d'une région comme monnaie légale. |
+| Inclusion financière | La fourniture durable de services financiers numériques abordables qui intègrent les utilisateurs finaux à faible revenu dans l'économie formelle. |
+| Inclusion financière | La fourniture durable de services financiers numériques abordables qui intègrent les personnes pauvres dans l'économie formelle. |
+| Littératie financière | Consommateurs et entreprises possédant des compétences financières essentielles, telles que la préparation d'un budget familial ou la compréhension de concepts tels que la valeur temporelle de l'argent, l'utilisation d'un produit ou service de services financiers numériques, ou la capacité de postuler pour un tel service. |
+| Fintech | Un terme utilisé pour décrire l'intersection de la finance et de la technologie. Les « fintechs » sont des entités fournissant des solutions innovantes dans le domaine financier, en tirant parti de la technologie. |
+| Flottant | Ce terme peut signifier une variété de choses différentes. En banque, le flottant est créé lorsque le compte d'une partie est débité ou crédité à un moment différent de celui de la contrepartie à la transaction. La monnaie électronique, en tant qu'obligation d'un fournisseur non bancaire, est parfois désignée comme flottant. |
+| Fraude | Utilisation criminelle des services financiers numériques pour prendre des fonds à un autre individu ou entreprise, ou pour nuire à cette partie d'une autre manière. |
+| Gestion du risque de fraude | Outils pour gérer les risques des fournisseurs, et parfois les risques des utilisateurs (par exemple, pour les commerçants ou les gouvernements) dans la fourniture et/ou l'utilisation des services de services financiers numériques. |
+| FSP | L'entité qui fournit un service financier numérique à un utilisateur final (soit un consommateur, une entreprise ou un gouvernement). Utilisé de manière interchangeable avec DFSP (Fournisseur de services financiers numériques). |
+| Transfert exécuté | Un transfert qui a été accepté par le DFSP bénéficiaire et enregistré comme terminé par le schéma. Une fois qu'un transfert a été enregistré comme terminé par le schéma, le payeur est tenu d'honorer la transaction lorsqu'elle apparaît dans un règlement. |
+| Accomplissement | Dans le protocole Interledger, un secret qui est la pré-image d'un hachage SHA-256, utilisé comme condition sur un transfert. La pré-image est requise dans le message d'engagement pour déclencher l'engagement du transfert. |
+| FX | Change (Foreign Exchange). |
+| G2P | Un cas d'utilisation secondaire de paiement en masse. |
+| Gouvernance | L'ensemble des approches de gestion, des décisions et des fonctions de surveillance au sein du schéma. La gouvernance du schéma peut donner le ton de tout ce qui se passe dans le schéma. |
+| Agence gouvernementale | Tout titulaire de compte de transaction qui est une sorte d'agence ou de département gouvernemental. |
+| Services d'acceptation des paiements gouvernementaux | Services qui permettent aux gouvernements de collecter des impôts et des frais auprès des individus et des entreprises. |
+| Règlement brut | Une méthode de règlement des obligations financières entre les DFSP et un schéma. Le règlement brut traite chaque transaction individuellement. Les détails du modèle de règlement brut sont spécifiés dans les règles du schéma. Le règlement brut contraste avec le règlement net. |
+| Hub | Un terme qui peut être utilisé pour l'entité qui exploite la plateforme au nom du schéma. |
+| Service d'identifiant | La manière dont le processus de recherche de compte fonctionne pour un type d'identifiant donné. |
+| Identité | Un justificatif d'identité de quelque sorte qui identifie un utilisateur final. Les identités nationales sont délivrées par les gouvernements nationaux. Dans certains pays, une identité financière est délivrée par les fournisseurs de services financiers. |
+| Transfert de fonds immédiat | Un paiement numérique qui est reçu par le bénéficiaire presque immédiatement après que le payeur a initié la transaction. |
+| Interchange | Une structure au sein de certains schémas de paiement qui oblige un fournisseur à payer à l'autre fournisseur des frais sur certaines transactions. Généralement utilisé dans les schémas de cartes pour effectuer le paiement d'un frais d'un commerçant à la banque émettrice de la carte du consommateur. |
+| Interledger | Le protocole Interledger est un protocole pour transférer de la valeur monétaire à travers plusieurs réseaux de paiement déconnectés en utilisant une chorégraphie de transferts conditionnels sur chaque réseau. |
+| Transfert de fonds international | Effectuer et recevoir des paiements vers une autre personne dans un autre pays. |
+| Interopérabilité | La capacité d'un client disposant d'un compte de transaction chez un participant à échanger une transaction avec un client qui a un compte de transaction chez un participant différent. |
+| Service d'interopérabilité pour les transferts (IST) | Un commutateur. |
+| Irrévocable | Une transaction qui ne peut pas être « rappelée » par le payeur ; un paiement irrévocable, une fois reçu par un bénéficiaire, ne peut pas être repris par le payeur. |
+| Connaissance du client (KYC) | Exigences réglementaires pour qu'un DFSP établisse l'identité et les activités d'un utilisateur final ou d'une entité, tant avant l'ouverture d'un compte de transaction que dans le temps. |
+| Grand livre | Un registre tenu des transactions. |
+| Level One Project | Une initiative de la Fondation Bill & Melinda Gates pour promouvoir l'inclusion financière. |
+| Responsabilité | Une obligation légale d'une partie envers une autre ; requise soit par la législation nationale, les règles du schéma de paiement, ou des accords spécifiques entre fournisseurs. Certaines règles de schéma transfèrent les responsabilités d'une transaction d'un fournisseur à un autre dans certaines conditions. |
+| Licence | La licence accordée à un candidat par le schéma lors de l'acceptation de l'accord de participation au schéma, qui autorise le participant à participer au schéma et à utiliser la propriété du schéma conformément aux règles. |
+| Liquidité | La disponibilité d'actifs liquides pour soutenir une obligation. Les banques et les fournisseurs non bancaires ont besoin de liquidité pour honorer leurs obligations. Les agents ont besoin de liquidité pour faire face aux transactions de décaissement des consommateurs et des petits commerçants. |
+| Prêts | Moyens par lesquels les utilisateurs finaux peuvent emprunter de l'argent. |
+| Commerçant | Une entreprise qui vend des biens ou des services et reçoit des paiements pour ces biens ou services. |
+| Acquisition de commerçants | Le processus d'activation d'un commerçant pour la réception de paiements électroniques. |
+| Codes de catégorie de commerçants | Un ensemble de catégorisation défini par un schéma pour différencier les clients entreprises. |
+| Identifiant commerçant | Un type d'identifiant de bénéficiaire. |
+| Fournisseur de services aux commerçants | Un fournisseur (banque ou non-banque) qui soutient les exigences des commerçants ou d'autres accepteurs de paiements pour recevoir des paiements de clients. Le terme « acquéreur » est utilisé spécifiquement en lien avec l'acceptation des transactions de paiement par carte. |
+| Achat initié par le commerçant | Un cas d'utilisation défini dans le document des spécifications API. |
+| Achat initié par le commerçant via TPV/OTP | Un cas d'utilisation défini dans le document des spécifications API. |
+| Achat initié par le commerçant via QR | Un cas d'utilisation défini dans le document des spécifications API. |
+| Institution de microfinance (IMF) | Une entité qui offre des services financiers aux populations à faible revenu. Presque toutes les IMF accordent des prêts à leurs membres, et beaucoup offrent des services d'assurance, de dépôt et autres. Les IMF sont considérées comme des DFSP dans un système Level One si elles fournissent des comptes de transaction à leurs clients. Les IMF qui ne sont pas des DFSP peuvent se connecter directement à une plateforme Level One, par le biais d'une relation avec un DFSP. Les règles du schéma préciseront comment ces IMF peuvent interagir avec la plateforme. |
+| Opérateur de réseau mobile (ORM) | Une entreprise qui vend des services de téléphonie mobile, y compris les communications vocales et de données. |
+| Opérateur de transfert d'argent | Un fournisseur spécialisé de services financiers numériques qui gère les transferts de fonds nationaux et/ou internationaux. |
+| MSISDN | Numéro identifiant de manière unique un abonnement dans un réseau de téléphonie mobile. Ces numéros utilisent la norme E.164 qui définit le plan de numérotation pour un réseau téléphonique public commuté (RTPC) mondial. |
+| Règlement net multilatéral | Un type de règlement qui gère les positions d'un groupe de participants dans un schéma. |
+| Document d'identité national | Un justificatif qui identifie un utilisateur final. Les documents d'identité nationaux sont délivrés par les gouvernements nationaux. |
+| Communication en champ proche | Une technologie de communication utilisée dans les paiements pour transmettre des données de paiement d'un téléphone mobile équipé NFC à un terminal compatible. |
+| Plafond de débit net | Une valeur que la plateforme utilise pour déterminer si un DFSP payeur peut envoyer une demande de transfert, comme défini dans les règles opérationnelles du schéma. |
+| Marge du plafond de débit net | Une valeur fixée par un schéma qui augmente ou diminue le plafond de débit net d'un participant. |
+| Position nette | Une valeur dans le grand livre d'un participant au schéma, reflétant le solde net des obligations dues. |
+| Règlement net | Un type de règlement qui compense la position d'un participant dans un schéma, reflétant à la fois les obligations dues à et par d'autres participants ou le schéma. |
+| Non-banque | Une entité qui n'est pas une banque agréée, mais qui fournit des services financiers aux utilisateurs finaux. Les exigences pour que les non-banques fassent cela, et les limitations de ce qu'elles peuvent faire, sont spécifiées par la législation nationale. |
+| Modèle piloté par les non-banques | Une référence à un système dans lequel les non-banques sont les fournisseurs de services financiers numériques aux utilisateurs finaux. Les non-banques doivent généralement répondre à des critères établis par la législation nationale et appliqués par les régulateurs. |
+| Non-répudiation | Capacité de prouver l'authenticité d'une transaction, par exemple en validant une signature numérique. |
+| Sans perte | Un modèle de recouvrement des coûts avec un ensemble supplémentaire de fonds disponibles pour couvrir les besoins d'investissement pour exploiter la plateforme. |
+| Notification | Avis à un payeur ou un bénéficiaire concernant l'état du transfert. |
+| Paiements off-us | Paiements effectués dans un système ou schéma à participants multiples, où le fournisseur du payeur est une entité différente de celle du fournisseur du bénéficiaire. |
+| Paiements on-us | Paiements effectués dans un système ou schéma à participants multiples, où le fournisseur du payeur est la même entité que le fournisseur du bénéficiaire. |
+| Achat en ligne | Un cas d'utilisation secondaire P2B. |
+| Spécification Open API | La spécification Open API for FSP Interoperability. |
+| Boucle ouverte | Un système ou schéma de paiement conçu pour que plusieurs fournisseurs y participent. Les règles du système de paiement ou la législation nationale peuvent restreindre la participation à certaines catégories de fournisseurs. |
+| Règles opérationnelles | Règles rédigées par un schéma qui lient les participants au schéma. Parfois appelées « règles commerciales ». |
+| Gestion des risques opérationnels | Outils pour gérer les risques des fournisseurs dans l'exploitation d'un système de services financiers numériques. |
+| Opérateur | Une entité qui fournit et/ou gère la plateforme d'un système de paiement. |
+| Organisation | Une entité telle qu'une entreprise, une œuvre de bienfaisance ou un département gouvernemental qui utilise la monnaie mobile comme service ; par exemple, recevoir des paiements de factures, effectuer des paiements de factures et verser des salaires. |
+| OTP | Code à usage unique. L'OTP est un identifiant qui, par définition, ne peut être utilisé qu'une seule fois. Il est généré puis validé par le même FSP pour une approbation automatique. L'OTP est généralement lié à un payeur spécifique dans un paiement. L'OTP généré est généralement un nombre entre 4 et 6 chiffres. |
+| Services au guichet | Services fournis par des agents lorsqu'une partie finale n'a pas de compte de monnaie électronique : le payeur (distant) peut payer la monnaie électronique sur le compte de l'agent, qui paie ensuite en espèces au bénéficiaire ne disposant pas de compte. |
+| P2P | Un cas d'utilisation défini dans le document des spécifications API. |
+| Participant | Un fournisseur qui est membre d'un schéma de paiement et soumis aux règles de ce schéma. |
+| Marge discrétionnaire du participant sur le plafond de débit net | Une valeur fixée par un participant qui diminue son plafond de débit net. |
+| Accord de participation | Un accord conclu entre chaque participant et un schéma. |
+| Frais de participation | Frais pour la participation à un schéma de paiement (parfois appelés frais d'adhésion). |
+| Requête Parties | Un appel API au service de répertoire du schéma par lequel un DFSP payeur demande l'identifiant du DFSP auprès duquel un identifiant de bénéficiaire est enregistré. |
+| Réponse à la requête Parties | La réponse du service de répertoire du schéma à une requête Parties. |
+| Banque partenaire | Institution financière soutenant le FSP et lui donnant accès à l'écosystème bancaire local. |
+| Partie | Une entité qui utilise les services du schéma directement ou indirectement. |
+| Identifiant de partie | Un élément d'information qui identifie de manière unique un client dans une mise en œuvre d'interopérabilité. |
+| Type d'identifiant de partie | Une énumération qui distingue les différents types d'identifiants de partie. La gamme complète des types d'identifiants de partie est donnée dans la spécification Open API ; le sous-ensemble des types d'identifiants de partie pris en charge par un schéma donné est indiqué dans ses règles opérationnelles. |
+| Bénéficiaire | Le destinataire de fonds électroniques dans une transaction de paiement. |
+| DFSP bénéficiaire | Le rôle d'un participant qui reçoit un transfert au nom de son client bénéficiaire. |
+| Payeur | Le payeur de fonds électroniques dans une transaction de paiement. |
+| DFSP payeur | Le participant qui envoie un transfert. |
+| Paiement | Un échange de fonds, d'identifiants et d'autres informations nécessaires pour compléter une obligation entre les utilisateurs finaux. Un transfert est un paiement. |
+| Dispositif de paiement | Le dispositif de paiement est la notion abstraite d'un appareil électronique, autre que le propre appareil du payeur, capable de permettre à un payeur d'accepter une transaction via l'utilisation d'un identifiant (une sorte d'OTP). Des exemples de dispositifs (de paiement) sont les GAB et les TPV. |
+| Système de paiement | Un terme large pour décrire le système global, y compris le schéma, les services du schéma et les participants au schéma. |
+| Opérateur de système de paiement | L'entité qui exploite un système ou schéma de paiement. |
+| Prestataire de services de paiement (PSP) | Un terme utilisé de deux manières : généralement, pour toute entreprise impliquée dans la fourniture de services de paiement (y compris les DFSP) ; ou pour un fournisseur qui offre des produits ou services de marque aux utilisateurs finaux, y compris les commerçants. Les PSP peuvent se connecter directement à une plateforme Level One, par le biais d'une relation avec un DFSP. Les règles du schéma préciseront comment les PSP peuvent interagir avec la plateforme. |
+| Informations personnelles | Informations relatives à toute personne individuelle, y compris les clients ou les employés du schéma ou d'un participant, à partir desquelles l'individu peut être identifié ou reconnu, quelle que soit la forme de ces informations. |
+| Plateforme | L'ensemble des capacités opérationnelles, incluant souvent un commutateur, qui mettent en œuvre l'échange de paiements dans un système de paiement interopérable aligné sur Level One. |
+| Plateforme | Un terme utilisé pour décrire le logiciel ou le service utilisé par un fournisseur, un schéma ou un commutateur pour gérer les comptes des utilisateurs finaux et envoyer et recevoir des transactions de paiement. |
+| Compte de règlement mutualisé | Un compte bancaire à la banque, détenu conjointement par les participants au schéma. |
+| Grand livre de position | Un grand livre tenu par la plateforme qui enregistre les écritures de règlement provisoires et définitives pour un participant dans une devise donnée. |
+| Comptabilisation | L'acte du fournisseur d'enregistrer une écriture de débit ou de crédit dans le relevé de compte de l'utilisateur final. |
+| Frais de traitement | Frais facturés par le schéma aux participants pour le traitement effectué par la plateforme du schéma. |
+| Processeur | Une entreprise qui gère, sur une base externalisée, diverses fonctions pour un DFSP. Ces fonctions peuvent inclure la gestion des transactions, la gestion de la base de données clients et la gestion des risques. Les processeurs peuvent également effectuer des fonctions pour le compte de systèmes de paiement, de schémas ou de commutateurs. Les processeurs peuvent se connecter directement à une plateforme Level One, agissant au nom d'un DFSP. Les règles du schéma préciseront comment les processeurs peuvent interagir avec la plateforme. |
+| Débit provisoire | Un enregistrement dans le grand livre de position du schéma d'une demande de transfert qui n'a pas été exécutée ; enregistré uniquement dans le grand livre de position du DFSP payeur. |
+| PSP | Prestataire de services de paiement. |
+| Paiement par tirage | Un type de transaction initiée par le DFSP du bénéficiaire. Les prélèvements automatiques, les chèques et les paiements par carte sont tous des paiements par tirage. Les paiements par tirage peuvent être rejetés ou échouer pour insuffisance de fonds sauf si une autorisation séparée est effectuée (par ex. cartes). |
+| Paiement par poussée | Un type de transaction initié par le DFSP payeur. Ceci est parfois appelé un virement. |
+| Achat par code QR | Un cas d'utilisation secondaire P2B. |
+| Code QR (Quick-Response) | Une méthode d'encodage et de visualisation de données sous forme lisible par machine. Il existe de multiples modèles de QR. |
+| Devis | Un processus par lequel un DFSP bénéficiaire reconnaît la validité du compte du bénéficiaire pour accepter un transfert, et définit les termes (et éventuellement les frais) liés à ce transfert. |
+| Demande de devis | Une demande par un DFSP payeur de données relatives à un transfert proposé. |
+| Réponse au devis | La réponse d'un DFSP bénéficiaire à une demande de devis. |
+| Règlement brut en temps réel (RTGS) | Un modèle de règlement qui règle les transferts sur une base individuelle, plutôt que nette. |
+| Paiements de détail en temps réel (RTRP) | Paiements de détail qui sont traités en temps réel (au moment de l'initiation). |
+| Montant reçu | Le montant qui est crédité sur le compte de transaction du bénéficiaire. |
+| Rapprochement | Le rapprochement inter-FSP est le processus consistant à s'assurer que deux ensembles d'enregistrements, généralement les soldes de deux comptes, sont en accord entre les FSP. Le rapprochement est utilisé pour s'assurer que l'argent quittant un compte correspond à l'argent réellement transféré. Cela se fait en s'assurant que les soldes correspondent à la fin d'une période comptable particulière. |
+| Recours | Droits accordés à un utilisateur final par la loi, les règles opérationnelles privées ou des accords spécifiques entre fournisseurs, permettant aux utilisateurs finaux de faire certaines choses (parfois révoquer une transaction) dans certaines circonstances. |
+| Remboursement | Un transfert qui annule une transaction précédente. |
+| Régulateur | Une organisation gouvernementale investie du pouvoir par la législation nationale de fixer et d'appliquer des normes et des pratiques. Les banques centrales, les départements des finances et du trésor, les régulateurs des télécommunications et les autorités de protection des consommateurs sont tous des régulateurs impliqués dans les services financiers numériques. |
+| Demande de devis | Un appel API qui initie une transaction par laquelle le DFSP payeur demande au DFSP bénéficiaire des informations concernant un transfert proposé. |
+| Demande de transfert | Un message qui est transmis d'un DFSP payeur via la plateforme à un DFSP bénéficiaire, qui demande qu'un transfert soit effectué du payeur au bénéficiaire. |
+| Demande de paiement | Un message par lequel un bénéficiaire « demande » un paiement à un payeur. Une demande de paiement dans un système Level One est souvent utilisée pour décrire un commerçant qui demande un paiement par poussée à un utilisateur final. |
+| Réservation | Partie d'une opération de transfert en deux phases dans laquelle les fonds à transférer sont bloqués (les fonds ne peuvent être utilisés à aucune fin jusqu'à ce qu'ils soient annulés ou engagés). Cela est généralement fait pour une durée prédéterminée, dont l'expiration entraîne l'annulation de la réservation. |
+| Paiement de détail | Un paiement ou un transfert entre utilisateurs finaux, généralement de faible valeur. Le terme est souvent utilisé pour décrire les paiements P2P, B2P ou P2B. |
+| Annulation | Le processus d'annulation d'un transfert terminé. |
+| Gestion des risques | Les pratiques que les entreprises mettent en œuvre pour comprendre, détecter, prévenir et gérer divers types de risques. La gestion des risques se fait chez les fournisseurs, dans les systèmes et schémas de paiement, chez les processeurs et chez de nombreux commerçants ou accepteurs de paiements. |
+| Approche fondée sur les risques | Une approche réglementaire et/ou de gestion commerciale qui crée différents niveaux d'obligation en fonction du risque de la transaction ou du client sous-jacent. |
+| Annulation | L'annulation signifie que les fonds électroniques qui étaient précédemment réservés sont remis dans leur état d'origine. La transaction financière est annulée. Les fonds électroniques ne sont plus bloqués pour utilisation. |
+| Règles | Les pratiques et normes nécessaires au fonctionnement des services de paiement définies par le schéma. Les règles sont parfois appelées règles du schéma, règles commerciales ou règles opérationnelles. |
+| Modification des règles | Tous les changements, ajouts, suppressions ou autres modifications des règles opérationnelles du schéma ou de tout document associé. |
+| Épargne et investissement | Conserver des fonds pour les besoins futurs et le rendement financier. |
+| Produits d'épargne | Un compte chez un fournisseur bancaire ou non bancaire, qui stocke des fonds dans le but d'aider les utilisateurs finaux à économiser de l'argent. |
+| Schéma | Un ensemble de règles, pratiques et normes nécessaires au fonctionnement des services de paiement. |
+| Cas d'utilisation secondaire | Un sous-ensemble d'un cas d'utilisation. Des règles commerciales ou des directives opérationnelles spécifiques peuvent s'appliquer aux cas d'utilisation secondaires. |
+| Élément sécurisé | Une puce sécurisée sur un téléphone qui peut être utilisée pour stocker des données de paiement. |
+| Code d'accès de sécurité | Un numéro d'identification personnel (PIN), un mot de passe/mot de passe à usage unique (OTP), une reconnaissance biométrique, un code ou tout autre dispositif fournissant un moyen d'accès certifié au compte d'un client aux fins, entre autres, d'initier un transfert électronique de fonds. |
+| Incident de sécurité | (i) Accès non autorisé ou divulgation d'informations personnelles ou de données de transaction relatives aux clients éligibles pour initier ou recevoir des transferts via le schéma qui s'est produit ou dont on soupçonne raisonnablement qu'il s'est produit ; ou (ii) une violation confirmée des réseaux ou systèmes d'un participant ou des réseaux ou systèmes de son fournisseur qui expose des informations personnelles ou des données de transaction relatives au schéma qui s'est produite ou dont on s'attend raisonnablement à ce qu'elle se soit produite. |
+| Montant envoyé | Le montant qu'un payeur autorise à être débité de son compte de transaction. |
+| Données sensibles du consommateur | Les données sensibles du consommateur désignent toute ou toutes les informations utilisées par un consommateur pour authentifier son identité et obtenir l'autorisation d'effectuer des services bancaires mobiles, y compris mais sans s'y limiter, l'identifiant utilisateur, le mot de passe, le PIN mobile, le PIN de transaction. Comprend également les données relatives aux croyances religieuses ou autres, à l'orientation sexuelle, à la santé, à la race, à l'origine ethnique, aux opinions politiques, à l'appartenance syndicale, au casier judiciaire. |
+| Services | Éléments de la plateforme du schéma qui fournissent des capacités d'interopérabilité aux participants du schéma. |
+| Règlement | Un processus par lequel les participants règlent leurs obligations les uns envers les autres et envers le schéma liées à l'échange de transactions tel qu'énoncé dans les directives opérationnelles de règlement. |
+| Banque de règlement | Une banque désignée par le schéma pour être partenaire dans la gestion du règlement et dans laquelle chaque participant doit avoir un compte bancaire aux fins du règlement. |
+| Compte bancaire de règlement | Le compte bancaire détenu par un participant auprès de la banque de règlement ou auprès d'une banque convenue avec la banque de règlement, qui est utilisé pour le règlement entre le schéma et le participant. |
+| Instruction de règlement | Désigne une instruction donnée à un système de règlement par un participant au système de règlement ou par un opérateur de système de compensation de paiement au nom d'un participant au système de règlement de la banque centrale pour effectuer le règlement d'une ou plusieurs obligations de paiement, ou pour acquitter toute autre obligation d'un participant au système envers un autre participant au système. |
+| Obligation de règlement | Désigne une dette due par un participant au système de règlement à un autre à la suite d'une ou plusieurs instructions de règlement. |
+| Fenêtre de règlement | Une période de temps entre deux règlements nets successifs tels que planifiés conformément aux directives opérationnelles de règlement. |
+| Service partagé | Un ensemble commun de services que les DFSP participants collaborent pour développer et/ou utiliser. |
+| Smartphone | Un appareil qui combine un téléphone mobile avec un ordinateur. |
+| Banques à charte spéciale | Banques dans un pays qui sont autorisées à effectuer un ensemble limité de fonctions, tel que déterminé par la réglementation. Les banques à charte spéciale qui ne peuvent qu'accepter des dépôts et gérer des paiements sont considérées comme des DFSP dans un système Level One. |
+| Sponsor | Un arrangement entre un émetteur de monnaie électronique et une banque, utilisé pour le paiement et la collecte des frais d'interchange par les émetteurs de monnaie électronique. |
+| Organisme de normalisation | Une organisation qui crée des normes utilisées par les fournisseurs, les schémas de paiement et les systèmes de paiement. |
+| Compte de valeur stockée | Compte dans lequel les fonds sont conservés dans un format électronique sécurisé. Peut être un compte bancaire ou un compte de monnaie électronique. |
+| Rapport de transaction suspecte | Si une institution financière remarque quelque chose de suspect dans une transaction ou une activité, elle peut déposer un rapport auprès de la cellule de renseignement financier qui l'analysera et le recoupera avec d'autres informations. Les informations dans un RTS varient selon la juridiction. |
+| Commutateur | Une entité de traitement dans un système de paiement qui achemine une transaction d'un DFSP à un autre DFSP. Un système peut exploiter son propre commutateur, ou cette fonction peut être effectuée par un ou plusieurs tiers. |
+| Système | Un terme utilisé pour décrire le schéma, les services, la plateforme et les participants alignés sur un Level One Project. |
+| Risque systémique | Dans les systèmes de paiement, le risque d'effondrement d'un système financier entier ou d'un marché entier, par opposition au risque associé à un fournisseur individuel ou un utilisateur final individuel. |
+| Le Level One Project | Une initiative de la Fondation Bill & Melinda Gates, au sein du programme Services financiers pour les pauvres, qui travaille à soutenir les pays ou régions construisant des systèmes de services financiers numériques interopérables et à faible coût pour intégrer les personnes et les commerçants à faible revenu dans l'économie formelle. |
+| Accès par paliers | Une disposition établie dans les règles du schéma qui permet à un DFSP de participer au système sous le parrainage d'un autre DFSP. |
+| Achat par numéro de caisse | Un cas d'utilisation secondaire P2B. |
+| Transaction | Un ensemble d'appels API connexes qui sont échangés entre les participants via le schéma, y compris un transfert. |
+| Compte de transaction | Un compte bancaire ou un portefeuille offert à un client par un DFSP. |
+| Titulaire du compte de transaction | Le client d'un DFSP qui détient le compte de transaction fourni par ce DFSP. |
+| Type de titulaire du compte de transaction | Une désignation utilisée pour définir si le titulaire du compte de transaction est un consommateur, une entreprise, une agence gouvernementale ou une agence à but non lucratif. |
+| Type de compte de transaction | Une désignation utilisée pour définir un compte de transaction comme étant soit un compte bancaire, soit un portefeuille de monnaie électronique. |
+| Coût de transaction | Le coût pour un fournisseur de services financiers numériques de fournir un service financier numérique. Cela pourrait être pour un ensemble de services (par exemple, un « portefeuille ») ou pour des transactions individuelles. |
+| Frais de transaction | Frais pour le traitement des transactions interopérables fixés par un schéma. |
+| Transfert | Terme générique pour décrire toute transaction financière où de la valeur est transférée d'un compte à un autre. |
+| Montant du transfert | Le montant que le DFSP payeur transfère à un DFSP bénéficiaire en utilisant le schéma. |
+| Demande de transfert | Une demande par un DFSP payeur d'effectuer un transfert. |
+| Réponse au transfert | La réponse d'un DFSP bénéficiaire à une demande de transfert. |
+| Compte de fiducie | Un moyen de détenir des fonds au profit d'une autre partie. Les émetteurs de monnaie électronique sont généralement tenus par la loi de détenir la valeur des comptes de monnaie électronique des utilisateurs finaux dans une banque, généralement dans un compte de fiducie. Cela accomplit les objectifs d'isolation et de protection des fonds. |
+| Ubiquité | Un terme utilisé pour décrire la capacité de payer n'importe qui et d'être payé par n'importe qui. |
+| Non bancarisé | Les personnes non bancarisées n'ont pas de compte de transaction. Les personnes sous-bancarisées peuvent avoir un compte de transaction mais ne l'utilisent pas activement. Sous-desservi est un terme large désignant les personnes qui sont les cibles des initiatives d'inclusion financière. Il est également parfois utilisé pour désigner une personne qui a un compte de transaction mais ne dispose pas de services supplémentaires de services financiers numériques. |
+| Pertes non couvertes | Obligations de règlement qui ne sont pas satisfaites par le DFSP responsable et ne sont pas acquittées par le biais de garanties ou d'autres mécanismes. |
+| Cas d'utilisation | Un terme utilisé pour décrire l'objet du paiement. Des règles commerciales ou des directives opérationnelles spécifiques peuvent s'appliquer aux cas d'utilisation. |
+| Identifiant utilisateur | Un identifiant unique d'un utilisateur. Il peut s'agir d'un MSISDN, d'un compte bancaire, d'une forme d'identifiant fourni par le DFSP, d'une identité nationale, etc. Dans une transaction, l'argent est généralement adressé à un identifiant utilisateur et non directement à un identifiant de compte. |
+| USSD | Une technologie de communication utilisée pour envoyer du texte entre un téléphone mobile et un programme d'application dans le réseau. |
+| Services à valeur ajoutée | Services ou produits fournis aux utilisateurs finaux que les utilisateurs finaux paieront pour utiliser ou accéder, souvent utilisés en coordination avec les adjacences. |
+| Bon | Un instrument de valeur monétaire couramment utilisé pour transférer des fonds à des clients (bénéficiaires) qui n'ont pas de compte auprès du FSP du payeur. Cela pourrait être des bénéficiaires sans compte ou ayant un compte auprès d'un autre FSP. |
+| Portefeuille | Un compte de transaction offert aux clients par les émetteurs de monnaie électronique. |
+| Portefeuille à banque | Un cas d'utilisation secondaire P2P. |
+| Portefeuille à portefeuille | Un cas d'utilisation secondaire P2P. |
+| Liste blanche | Une liste ou un registre d'entités (utilisateurs enregistrés) auxquelles un privilège, un service, une mobilité, un accès ou une reconnaissance particulière est accordé, en particulier celles qui étaient initialement sur liste noire. |
+| Autonomisation économique des femmes (WEE) : | Augmenter l'accès et les droits des femmes aux ressources économiques par des opportunités de travail décent, la propriété et les actifs, l'inclusion financière et les plateformes. |
diff --git a/docs/fr/adoption/guides/Role-based-access-control.md b/docs/fr/adoption/guides/Role-based-access-control.md
new file mode 100644
index 00000000..436dd08e
--- /dev/null
+++ b/docs/fr/adoption/guides/Role-based-access-control.md
@@ -0,0 +1,297 @@
+# Contexte du RBAC
+
+Un individu qui a besoin d'accéder aux différents portails de gestion du Hub Mojaloop peut être enregistré et un &quot;compte&quot; généré, qui peut être utilisé pour accéder à divers aspects d'une instance opérationnelle d'un Hub Mojaloop et pour fournir une base d'audit de cet accès en liant les activités à l'enregistrement original. Aux fins de ce document, un &quot;compte&quot; est une identité numérique, un moyen d'authentifier (lier) la personne revendiquant cette identité à l'enregistrement original, et un ensemble d'attributs, qui incluront - entre autres - un ensemble de droits d'accès, ou des droits qui sont activés par la possession de ces attributs.
+
+### Conception du RBAC
+
+La conception RBAC pour un opérateur de hub décrit les points de contrôle de sécurité qui doivent être pris en compte ou étendus afin d'atténuer les risques au sein d'une organisation typique d'exploitation de hub Mojaloop. Certains points de contrôle sont liés aux processus métier et à la structure organisationnelle, certains points de contrôle sont techniques et concernent les couches d'identification, d'authentification et d'autorisation, et certains points de contrôle nécessitent une surveillance. Les trois doivent être pris en compte pour créer la responsabilité et atténuer les risques.
+
+### Audit
+
+L'audit devrait travailler en collaboration avec les équipes métier et informatiques pour séparer ces fonctions dans la mesure du possible et attribuer un contrôle d'atténuation approprié dans les cas où cela n'est pas faisable. De plus, ces contrôles devraient être surveillés sur une base trimestrielle et les résultats doivent être signalés à la direction.
+
+Quelques définitions contextuelles incluent
+
+1. **Action** : un événement distinct déclenché par un utilisateur qui entraîne :
+
+- La création d'un actif de données
+- La lecture ou l'accès à un actif de données
+- La mise à jour ou la modification de l'état d'un actif de données
+- La suppression ou le retrait d'un actif de données d'une application ou d'une base de données.
+
+1. **Permission** : autorité pour effectuer une action spécifique dans le contexte d'une application ou d'un service
+2. **Rôle** : applications, actions et accès aux données nécessaires pour effectuer les tâches liées à un rôle unique
+3. **Relation utilisateur - rôle** : Le ou les rôles attribués à chaque utilisateur qui définissent les permissions dont ils disposent
+
+## Utilisateurs, actions et rôles dans un contexte Mojaloop
+
+Mojaloop aura 2 grandes catégories d'utilisateurs :
+
+1. Humains – Ce sont les utilisateurs du hub et des DFSP qui, à travers diverses interfaces, interagiront avec Mojaloop. Les utilisateurs DFSP interagiront avec Mojaloop à travers le Payment Manager et les portails qui seront mis à disposition pendant le processus d'intégration.
+2. Non-humains – Ceux-ci automatiseront les processus métier et les tâches qui seraient autrement effectuées par un humain. Ils communiqueront via des appels API qui effectueront des actions pour répondre aux exigences métier.
+
+Le contexte de ce document se concentrera uniquement sur les utilisateurs humains.
+
+## Gestion du cycle de vie des utilisateurs
+
+Le &quot;cycle de vie du compte utilisateur&quot; définit les processus de gestion collectifs pour chaque compte utilisateur. Ces processus peuvent être décomposés en Création, Révision/Mise à jour et Désactivation — ou &quot;CRUD&quot;. Si une organisation utilise des ressources informatiques de quelque nature que ce soit, elle s'appuie sur des comptes utilisateurs pour y accéder.
+
+## Intégration
+
+Le processus d'intégration comprendra certaines activités impliquant la création d'utilisateurs tant du côté DFSP que du Hub. Celles-ci seront les suivantes :
+
+1. Hub : Les utilisateurs suivants seront créés
+  1.1 Opérateurs du Hub
+  1.2. Administrateurs du Hub
+2. DFSP
+  2.1 Opérateurs DFSP
+  2.2 Administrateurs DFSP (applicable uniquement au Payment Manager).
+
+## Séparation des fonctions
+
+La séparation des fonctions vise à atténuer le risque de fraude interne en fixant des limites entre les rôles attribués à un employé, et entre les conflits d'intérêts pouvant résulter des responsabilités d'un employé, en veillant à ce qu'aucun utilisateur unique ne puisse avoir le contrôle fonctionnel de bout en bout d'un processus métier et de ses données. Cela nécessite que plus d'un individu crée, traite et complète une action.
+
+### Principe du moindre privilège
+
+Le RBAC utilise le principe de sécurité du moindre privilège. Le moindre privilège signifie qu'un utilisateur dispose précisément du niveau de privilège nécessaire pour effectuer son travail. L'objectif est de minimiser la probabilité d'attribuer à un utilisateur des permissions excessives pour effectuer des actions dans l'écosystème Mojaloop.
+
+### Implémentation Zero Trust de Mojaloop
+
+Un réseau zero trust est un réseau dans lequel aucune personne, appareil ou réseau ne bénéficie d'une confiance inhérente. Toute confiance, qui permet l'accès aux informations, doit être méritée, et la première étape consiste à démontrer une identité valide. Un système doit savoir qui vous êtes, avec certitude, avant de pouvoir déterminer ce à quoi vous devriez avoir accès.
+
+La conception inhérente de Mojaloop implémentera une approche Zero Trust dans son architecture et son déploiement, exigeant que toutes les entités qui interagissent s'authentifient d'abord, puis demandent l'autorisation d'accéder et de traiter les données en fonction du rôle auquel elles appartiennent.
+
+### Processus de détermination de la séparation des fonctions
+
+1. Définir les flux de travail et processus de gestion des utilisateurs. Ce sont tous les processus métier qui composent les actions métier Mojaloop dans Mojaloop. Les exemples incluent l'intégration.
+2. Rationaliser toutes les exigences d'accès de sécurité des utilisateurs pour les applications de Mojaloop comme indiqué dans le tableau ci-dessous :
+  2.1 Définir les fonctions métier et applicatives pour les utilisateurs et les API
+  2.2 Définir les profils de rôles
+  2.3 Définir les profils de fonctions et de compétences
+  2.4 Rassembler une liste des conflits de séparation des fonctions applicables en définissant les rôles de séparation des fonctions
+  2.5 Tableau matriciel des profils de rôles (avec des données d'exemple) :
+
+| **Rôles et Permissions**  **Matrice** | Utilisateurs Hub | Administrateur | Utilisateur Maker Standard | Utilisateur Checker Standard | Lecture Seule Standard | Utilisateurs DFSP | Administrateur | Utilisateur Maker Standard | Utilisateur Checker Standard | Lecture Seule Standard |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
+| Rôles d'intégration | X | | | | | | | | | |
+| Créer un compte utilisateur | X | | | | | | | | | |
+| Créer un profil DFSP | X | | | | | | | | | |
+| Créer un utilisateur DFSP | X | | | | | | | | | |
+|
+| **Portail Financier** |
+| Voir les rapports | | | X | X | X | | | X | X | X |
+| Configuration de la plateforme | | | | | | | | | | |
+|
+
+3. Reconfigurer les rôles en conflit
+  3.1 Approbations métier
+  3.2 Création d'utilisateurs Maker/Checker
+4. Rapports périodiques sur l'accès au système et l'autorisation des utilisateurs
+5. Séparation de la sécurité informatique et de la sécurité informatique opérationnelle qui soutiendra les activités de gestion des utilisateurs
+
+## Meilleures pratiques pour le RBAC et la gestion des identités Mojaloop
+
+1. Tous les identifiants d'utilisateurs doivent être uniques et avoir un format unique qui peut être corrélé dans le hub mais pas significatif pour les personnes extérieures.
+2. Les utilisateurs DFSP n'auront accès à aucun rôle administratif du Hub
+3. Tous les utilisateurs non-humains doivent être empêchés de se connecter aux interfaces applicatives.
+4. Les utilisateurs DFSP seront formés sur les rôles et les meilleures pratiques
+5. Appliquer le provisionnement automatisé des utilisateurs et la gestion du cycle de vie.
+6. Classer les actions effectuées dans Mojaloop pour identifier les actions métier à risque nécessitant des contrôles supplémentaires.
+7. Les contrôles supplémentaires pour atténuer les risques RBAC peuvent inclure :
+  7.1 Authentification multifacteur (MFA)
+  7.2 Journalisation d'audit avec alertes
+  7.3 Désactivation / blocage automatique du profil utilisateur
+8. Mojaloop surveillera l'inactivité des utilisateurs et désactivera les utilisateurs inactifs sur une période spécifiée
+9. Appliquer une politique centralisée d'application à travers les identités, par ex. politique de mots de passe, politiques de connexion, MFA, authentification basée sur le risque, etc.
+10. Identifier et surveiller de près les identités privilégiées qui ont des permissions pour effectuer des actions sensibles. Les éléments suivants s'appliquent aux utilisateurs privilégiés :
+  10.1 Les privilèges avancés doivent être demandés et approuvés au cas par cas ;
+  10.2 Les administrateurs doivent avoir leurs permissions privilégiées pour le minimum de temps possible ;
+  10.3 Les administrateurs ne doivent avoir que les permissions nécessaires pour accomplir une tâche spécifique ;
+  10.4 L'appartenance aux groupes administratifs doit être révisée régulièrement ;
+  10.5 Appliquer l'authentification multifacteur pour les utilisateurs administratifs ;
+  10.6 Conserver les journaux d'accès, les audits et configurer des notifications en temps réel lorsque l'accès est activé.
+11. Mojaloop configurera des journaux d'audit et des alertes pour toutes les actions des utilisateurs dans Mojaloop. Dans la mesure du possible, explorer l'analytique des identités via des outils open source applicables.
+
+## Gestion automatisée des identités et contrôle RBAC
+
+Les outils préférés pour la gestion des utilisateurs et des identités dans un déploiement Mojaloop sont :
+
+1. **Moteur de gestion des identités KeyCloak** – Stocker et traiter les contrôles d'authentification API ainsi qu'agir comme passerelle API.
+2. **Moteur de gestion des identités WSO2** – Stocker et traiter les profils de rôles des utilisateurs et gérer l'auto-intégration des utilisateurs DFSP.
+
+-------
+
+## Contexte
+
+Un individu qui a besoin d'accéder aux différents portails de gestion du Hub Mojaloop peut être enregistré et un « compte » généré, qui peut être utilisé pour accéder à divers aspects d'une instance opérationnelle d'un Hub Mojaloop et pour fournir une base d'audit de cet accès en liant les activités à l'enregistrement original. Aux fins de ce document, un « compte » est une identité numérique, un moyen d'authentifier (lier) la personne revendiquant cette identité à l'enregistrement original, et un ensemble d'attributs, qui incluront - entre autres - un ensemble de droits d'accès, ou des droits qui sont activés par la possession de ces attributs.
+
+Le processus d'enregistrement implique la vérification d'identité, la vérification des antécédents, etc. L'individu reçoit ensuite des identifiants - un identifiant de compte de connexion/identité numérique et au moins une méthode d'authentification, qui peut inclure un mot de passe et une authentification à deux facteurs (2FA).
+
+::: tip NOTE
+La portée de ce document ne se limite pas aux opérateurs du Hub Mojaloop. Il aborde également les aspects de l'accès des opérateurs DFSP aux portails Payment Manager.
+:::
+
+### Considérations relatives à la 2FA
+
+Il convient de noter que la 2FA via un téléphone mobile peut être inappropriée pour certains rôles, car les rôles très sensibles peuvent exiger que les téléphones mobiles soient rangés sous clé pendant que l'individu est « en service ». Cela nécessitera d'autres méthodes de 2FA, telles que des jetons physiques.
+
+### Contrôle d'accès basé sur les rôles
+
+Le Hub Mojaloop utilise une méthode de contrôle d'accès basé sur les rôles (RBAC). Un utilisateur avec un compte qui permet l'accès au Hub aura des rôles associés à ce compte, qui définissent ce qu'il peut faire une fois authentifié et connecté.
+
+De nombreux rôles s'appliquent à plusieurs portails, cependant, certains rôles peuvent être spécifiques à des portails individuels.
+
+Une attention particulière doit être portée lors de l'attribution de plusieurs rôles à un compte, ou de plusieurs comptes à une même personne physique. Cela est dû au potentiel qui se présente pour le contournement des contrôles. Une partie de l'objectif du RBAC est de s'assurer que plus d'une personne doit être dans la chaîne d'autorisation pour les actions importantes, réduisant ainsi les vulnérabilités liées aux acteurs malveillants.
+
+## Portails de l'écosystème Mojaloop
+
+L'écosystème Mojaloop offre un certain nombre de portails, qui prennent en charge divers degrés de contrôle d'accès et de RBAC. Ceux-ci sont divisés en deux groupes :
+
+- Portails du Hub, qui sont liés au fonctionnement du Hub lui-même
+- Portails Payment Manager, qui sont liés à la gestion de la connexion d'un DFSP spécifique au Hub
+
+## RBAC dans le Hub Mojaloop
+
+Dans l'environnement du Hub Mojaloop, le RBAC est implémenté à travers une combinaison d'outils - Ory Oathkeeper pour la gestion des identités, et Keycloak pour le contrôle d'accès (y compris les rôles et le maker/checker).
+
+Le Hub lui-même possède les portails suivants :
+
+- **Intégration de l'opérateur du Hub :**
+Actuellement, il n'existe pas de solution intégrée de gestion des identités et des accès (IAM) pour les opérateurs du Hub, bien que la fonction soit partiellement remplie par l'utilisation de WSO2. Des travaux de développement sont en cours pour développer une solution IAM complète basée sur Ory et Keycloak. Cela verra un opérateur administrateur créé parallèlement au déploiement du Hub, ce qui constitue une première étape fondamentale dans ce domaine.
+- **Portail Financier :** Il a deux fonctions principales : la gestion des opérations de règlement, et la gestion de la position de liquidité des DFSP individuels (et en relation avec cela, leur valeur de plafond de débit net (NDC)).
+L'accès au portail financier est actuellement limité à une simple fonction de contrôle d'accès par nom d'utilisateur/mot de passe.
+- **Cycle de vie des participants :** Contrôle et configuration de l'accès au Hub par les DFSP.
+D'un point de vue technique, cela est actuellement réalisé par l'utilisation du Mojaloop Connection Manager (MCM). Cependant, il est prévu que le MCM lui-même sera développé pour présenter une API, qui pourra être utilisée pour développer une interface utilisateur disponible pour les opérateurs du Hub et pour les DFSP.
+- **Opérations du Hub :** Celles-ci comprennent les recherches de transactions, la surveillance de l'état et des performances, les tableaux de bord et l'ensemble des opérations techniques.
+Actuellement, celles-ci sont réalisées grâce à l'utilisation de Prometheus/Grafana et d'une gamme d'autres outils, avec un contrôle d'accès standard intégré dans ces outils eux-mêmes. Il est prévu que cela sera migré vers la solution Ory/Keycloak, au fur et à mesure de son développement.
+
+D'autres opérations du Hub, telles que la gestion de la fraude et la gestion des cas/litiges, sont des modules complémentaires qui implémentent leur propre contrôle d'accès pour gérer l'accès à leurs fonctions sensibles. Ceux-ci ne sont pas abordés dans ce document.
+
+En plus des mesures de contrôle d'accès ci-dessus, il convient de noter que l'accès à toutes ces fonctions n'est possible que via un VPN, avec des identifiants individuels contrôlant l'accès.
+
+En plus de ces portails, il existe deux autres moyens principaux d'accéder au Hub, dont aucun n'est soumis au RBAC :
+
+- Le premier concerne les transactions, qui sont strictement contrôlées selon leurs propres mesures de cybersécurité multicouches.
+- Et deuxièmement, les paiements en masse (gouvernement vers personne - G2P), qui sont pris en charge au moyen d'une API soumise aux mêmes contrôles que les autres transactions individuelles. Il est prévu que les paiements en masse seront un service fourni aux DFSP (et à leurs clients) au moyen d'une API sécurisée, le DFSP exploitant un portail de paiements en masse pour l'utilisation par ses clients. Il est possible que l'opérateur d'une instance du Hub Mojaloop puisse mettre à disposition un portail de paiements en masse en marque blanche, qui s'interface avec l'API de paiements en masse du Hub, pour personnalisation par tout DFSP souhaitant offrir le service à ses clients. (Notez que cette approche n'est pas unique : une approche similaire a été proposée, par exemple, pour les paiements marchands, avec une application en marque blanche pour les transactions par code QR mise à disposition des DFSP pour intégration dans leurs portefeuilles mobiles.)
+
+Les contrôles d'accès autour des paiements individuels ou en masse ne sont donc pas abordés davantage dans ce document.
+
+## Payment Manager pour l'intégration
+
+Payment Manager est actuellement l'un des principaux mécanismes d'intégration des DFSP à un Hub Mojaloop. Alors que le Hub est unique dans un schéma, il existe une instance distincte de Payment Manager pour chaque DFSP. Les portails offerts par Payment Manager doivent donc être sécurisés au moyen du RBAC pour limiter l'accès aux représentants autorisés du DFSP.
+
+Dans l'environnement Payment Manager, le RBAC est implémenté uniquement via Keycloak.
+
+Les portails suivants sont disponibles :
+
+- **Intégration utilisateur/opérateur :**
+Payment Manager inclut Keycloak pour l'IAM. Lors du déploiement, un utilisateur administrateur unique est créé, qui peut être utilisé pour créer d'autres comptes utilisateurs.
+- **Gestion de la connexion au Hub :**
+Cela inclut la possibilité de configurer la connexion au Hub du côté Payment Manager, et par implication de la désactiver. C'est donc une fonction contrôlée, avec des contrôles différents pour la visualisation par rapport à la modification.
+- **Investigation des transactions :**
+Il est possible d'investiguer les requêtes de transactions en utilisant le portail Payment Manager. Cela est potentiellement problématique si des informations personnellement identifiables (PII) sont disponibles via le portail.
+
+## Exigences RBAC
+
+### Hub Mojaloop
+
+#### Intégration de l'opérateur du Hub
+
+##### Comptes fondamentaux
+
+Au moment où un Hub est mis en place pour la première fois, Ory/Keycloak sera utilisé pour créer un compte utilisateur fondamental avec des privilèges d'administrateur. Un administrateur système se verra attribuer ce compte. Notez que l'administrateur système ne se verra attribuer aucun rôle opérationnel au-delà de ceux d'un administrateur système.
+
+Toutes les fonctions exécutées à l'aide d'Ory/Keycloak sont soumises à une journalisation au niveau du système à des fins d'audit.
+
+L'administrateur système utilisera ensuite Ory/Keycloak pour créer d'autres comptes utilisateurs, sous réserve de vérifications d'identité et de contrôles d'antécédents standard pour chaque individu (définis dans les règles du schéma associées à un déploiement Mojaloop particulier) avant que leurs comptes ne soient créés.
+
+Ces nouveaux comptes utilisateurs se verront attribuer l'un de ces rôles :
+
+- OPERATOR
+- MANAGER
+
+Un compte utilisateur ne peut pas avoir à la fois les rôles OPERATOR et MANAGER.
+
+##### Comptes supplémentaires
+
+En plus de l'administrateur système, les comptes fondamentaux auront la possibilité d'utiliser Ory/Keycloak pour ajouter d'autres comptes. Cependant, pour ces utilisateurs, cette activité sera soumise à des contrôles maker/checker. Un utilisateur avec le rôle OPERATOR pourra créer un compte utilisateur (avec des processus en place pour garantir que la diligence raisonnable en matière de vérification d'identité et de contrôle des antécédents a été effectuée). Cependant, ce compte ne sera pas activé tant qu'une personne avec le rôle MANAGER ne l'aura pas approuvé.
+
+Un rôle sera attribué à chacun de ces comptes lors de leur création. En plus des rôles associés aux comptes fondamentaux, les rôles suivants peuvent être attribués aux nouveaux comptes utilisateurs :
+
+- ADMINISTRATOR
+- FINANCE_MANAGER
+
+Un compte utilisateur ne peut pas avoir plus d'un des rôles OPERATOR, MANAGER, ADMINISTRATOR ou FINANCE_MANAGER, afin d'assurer la séparation de :
+
+- La gestion financière des autres tâches d'exploitation du Hub
+- Les rôles d'opérateur et de gestionnaire dans les fonctions maker/checker
+
+::: tip NOTE
+L'attribution des rôles ADMINISTRATOR ou FINANCE_MANAGER est soumise à un degré plus élevé de vérification d'identité et de contrôle des antécédents que tout autre rôle, en raison de la nature sensible des fonctions associées. Ces vérifications supplémentaires sont définies dans les règles du schéma.
+:::
+
+#### Portail Financier
+
+De nombreuses fonctions (telles que la visualisation des positions des DFSP, l'état des fenêtres de règlement, etc.) du portail financier sont disponibles pour tous les utilisateurs connectés, quel que soit leur rôle. Cependant, les fonctions suivantes ne peuvent être exécutées que par des utilisateurs ayant des rôles spécifiques :
+
+- Traitement des règlements
+  - Fermer la fenêtre de règlement
+  - Initier le règlement
+- Gestion de la liquidité DFSP
+  - Ajouter/retirer des fonds
+  - Modifier le NDC
+
+Toutes ces fonctions sont soumises à des contrôles maker/checker, de sorte qu'un utilisateur avec le rôle ADMINISTRATOR peut initier l'action, mais elle doit être approuvée par un utilisateur avec le rôle FINANCE_MANAGER.
+
+#### Cycle de vie des participants
+
+Ce portail fournit une interface unique pour qu'un opérateur du Hub ajoute et maintienne les DFSP sur les écosystèmes du Hub.
+
+Il existe certaines fonctions standardisées qui sont soumises au RBAC :
+
+- Créer un DFSP
+- Créer des comptes DFSP
+- Suspendre un DFSP
+
+Chacune de ces fonctions est soumise à des contrôles maker/checker, de sorte qu'un utilisateur avec le rôle OPERATOR peut mettre en place les modifications, et elles doivent être approuvées par un utilisateur avec le rôle MANAGER.
+
+De plus, il y a une charge de travail importante dans l'intégration technique d'un DFSP, en particulier autour de l'établissement de l'environnement technique d'exploitation (certificats, etc.). Cela n'est pas soumis au RBAC. Cela n'est pas considéré comme un risque significatif, car il n'y a pas de valeur sans pouvoir créer un DFSP et les comptes associés sur le Hub lui-même - activités qui sont soumises au RBAC.
+
+#### Opérations du Hub
+
+L'accès aux fonctions de reporting de Prometheus/Grafana n'est pas soumis aux contrôles RBAC - tout utilisateur connecté/authentifié, avec n'importe quel rôle RBAC attribué, peut consulter les rapports et les tableaux de bord.
+
+La création d'un nouveau rapport/tableau de bord est une fonction restreinte, et n'est disponible que pour les utilisateurs ayant le rôle MANAGER.
+
+Comme indiqué précédemment, les portails d'opérations et de reporting seront migrés vers l'environnement Ory/Keycloak afin de faciliter ces contrôles.
+
+### Payment Manager
+
+La fonctionnalité opérateur de Payment Manager est soumise aux contrôles RBAC, mais le maker/checker n'est pas requis.
+
+#### Intégration utilisateur/opérateur
+
+Lors du déploiement de Payment Manager, un seul compte utilisateur administrateur est créé à l'aide de Keycloak. Notez que l'utilisateur administrateur ne se verra attribuer aucun rôle opérationnel au-delà de ceux d'un administrateur système.
+
+Toutes les fonctions exécutées à l'aide de Keycloak sont soumises à une journalisation au niveau du système à des fins d'audit.
+
+L'utilisateur administrateur utilisera Keycloak pour créer d'autres comptes utilisateurs, sous réserve de vérifications d'identité et de contrôles d'antécédents standard pour chaque individu (définis dans les règles du schéma associées à un déploiement Mojaloop particulier) avant que leurs comptes ne soient créés.
+
+Ces nouveaux comptes utilisateurs se verront attribuer l'un des rôles suivants :
+
+- OPERATOR
+- MANAGER
+
+Un compte utilisateur ne peut pas avoir à la fois les rôles OPERATOR et MANAGER.
+
+#### Tableaux de bord
+
+Les tableaux de bord de Payment Manager sont disponibles pour tout utilisateur connecté/authentifié ayant le rôle OPERATOR ou MANAGER.
+
+#### Gestion de la connexion au Hub
+
+La visualisation des paramètres de la connexion Payment Manager/Hub est disponible pour tout utilisateur connecté/authentifié ayant le rôle OPERATOR ou MANAGER. Cependant, la modification des paramètres est une fonction contrôlée. Seul un utilisateur ayant le rôle MANAGER peut modifier les paramètres.
+
+#### Investigation des transactions
+
+La réalisation d'investigations de transactions à l'aide des fonctionnalités du portail Payment Manager est une activité contrôlée, en raison du potentiel de révélation de données PII. Elle n'est donc disponible que pour les utilisateurs connectés/authentifiés ayant le rôle MANAGER.
diff --git a/docs/fr/adoption/index.md b/docs/fr/adoption/index.md
new file mode 100644
index 00000000..1b32bc8d
--- /dev/null
+++ b/docs/fr/adoption/index.md
@@ -0,0 +1,42 @@
+# À propos des documents sur l’adoption de Mojaloop
+
+Pour un opérateur de Hub ou une banque centrale souhaitant utiliser Mojaloop pour son système de paiement instantané inclusif (IIPS), le processus d’adoption et les étapes de la prise de décision diffèrent souvent fortement de celles consistant à faire appel à une entreprise pour fournir un logiciel propriétaire. Utiliser Mojaloop pour construire et posséder une plateforme offre davantage de contrôle mais aussi davantage de responsabilités. Ne pas dépendre d’un seul fournisseur signifie exactement cela.
+
+La documentation et les outils de cette section visent à aider à justifier le choix de Mojaloop et à proposer une démarche de mise en œuvre recommandée.
+
+Construire un système de paiement dépasse largement la plateforme technologique. Le schéma et les opérations sont en réalité les facteurs de succès. Nous avons développé Mojaloop pour réduire la charge opérationnelle et le coût de mise en œuvre de règles de schéma inclusives telles que l’irrévocabilité et la certitude.
+
+Le processus de construction d’un système de paiement peut être aussi important que certaines décisions de schéma qui en découlent. Chaque propriétaire et opérateur de schéma peut définir son propre processus, mais nous recommandons une démarche inclusive, transparente et itérative afin de maximiser l’appropriation, la confiance et la durabilité à long terme.
+
+
+
+Outils à la disposition des adoptants :
+
+* [**Choix relatifs au schéma**](#scheme-choices) : documents d’aide pour définir les règles du schéma, les lignes directrices d’exploitation, ainsi que les choix commerciaux et de conception majeurs
+* [**Exploitation du Hub**](#hub-operations) : guides fournissant des informations pratiques sur les différents aspects de l’exploitation d’un Hub Mojaloop
+
+## Choix relatifs au schéma
+
+Le [modèle de lignes directrices d’exploitation de la plateforme](./Scheme/platform-operating-guideline.md) fournit un modèle pour décrire le fonctionnement de la plateforme du Schéma et pour préciser les obligations et responsabilités du Schéma, de l’opérateur de la plateforme et des DFSP.
+
+Le [modèle de règles commerciales du schéma](./Scheme/scheme-business-rules.md) fournit un modèle pour définir les règles commerciales qui encadrent les droits et obligations des participants à un schéma Mojaloop.
+
+Le document [Choix clés du schéma](./Scheme/scheme-key-choices.md) décrit et examine certains des choix commerciaux et de conception les plus importants qui influencent à la fois la mise en œuvre technique de Mojaloop et les règles commerciales que le Schéma rédigera et auxquelles les DFSP participants accepteront de se conformer.
+
+Le [modèle de convention de participation au schéma](./Scheme/scheme-participation-agreement.md) fournit un modèle de convention de participation au schéma contenant les dispositions minimales nécessaires pour attester de la demande d’un DFSP de rejoindre le Schéma et de respecter ses règles commerciales.
+
+Le [modèle de glossaire uniforme](./Scheme/scheme-uniform-glossary.md) sert de glossaire des termes métier.
+
+## Exploitation du Hub
+
+Ces documents peuvent servir de référence aux adoptants pour s’appuyer dessus et adapter les portails d’exploitation du Hub, puis développer les leurs ultérieurement selon les besoins.
+
+Le [guide des opérations techniques](./huboperations/techops/tech-ops-introduction.md) décrit les processus opérationnels qui permettent à l’opérateur du Hub de couvrir tous les aspects de la gestion d’un service en production, tels que la gestion des incidents, la gestion des problèmes, la gestion du changement, la gestion des versions et le triage des défauts.
+
+Le [guide de la gestion des règlements](./huboperations/settlement/settlement-management-introduction.md) explique comment les règlements sont gérés par le Hub Mojaloop et la ou les banques partenaires de règlement, et présente les principaux éléments du traitement des règlements.
+
+Le [guide du portail financier v2](./huboperations/portalv2/busops-portal-introduction.md) s’adresse à l’opérateur d’un Hub Mojaloop et fournit des informations sur le portail financier, qui facilite la gestion au quotidien des processus liés aux règlements.
+
+Le document [contrôle d’accès basé sur les rôles](./huboperations/rbac/Role-based-access-control.md) traite du mécanisme de sécurité utilisé pour contrôler l’accès aux différents aspects d’une instance opérationnelle d’un Hub Mojaloop.
+
+Le [guide d’intégration pour l’opérateur du Hub](./huboperations/onboarding/onboarding-introduction.md) s’adresse à l’opérateur d’un Hub Mojaloop et fournit des informations sur le processus d’intégration des DFSP. Il offre une vue d’ensemble du parcours d’intégration suivi par les DFSP, en servant de liste de contrôle des activités d’intégration.
diff --git a/docs/fr/product/features/Iso20022/v1.0/MarketPracticeDocument.md b/docs/fr/product/features/Iso20022/v1.0/MarketPracticeDocument.md
index 9949d5d2..630e844d 100644
--- a/docs/fr/product/features/Iso20022/v1.0/MarketPracticeDocument.md
+++ b/docs/fr/product/features/Iso20022/v1.0/MarketPracticeDocument.md
@@ -6,38 +6,37 @@ sidebarTitle: MPD ISO 20022 v1.0
  
 <!-- TOC depthfrom:1 depthto:3 orderedlist:true -->
 
-- [1. Mojaloop ISO 20022 Market Practice Document](#_1-mojaloop-iso-20022-market-practice-document)
 - [2. Introduction](#_2-introduction)
-    - [2.1. How to Use This Document?](#_2-1-how-to-use-this-document)
-        - [2.1.1. Relationship with Scheme-Specific Rules Documents](#_2-1-1-relationship-with-scheme-specific-rules-documents)
-        - [2.1.2. Distinction Between Generic Practices and Scheme-Specific Requirements](#_2-1-2-distinction-between-generic-practices-and-scheme-specific-requirements)
-- [3. Message Expectations, Obligations, and Rules](#_3-message-expectations-obligations-and-rules)
-    - [3.1. Currency Conversion](#_3-1-currency-conversion)
-    - [3.2. JSON Messages](#_3-2-json-messages)
-    - [3.3. APIs](#_3-3-apis)
-        - [3.3.1. Header Details](#_3-3-1-header-details)
-        - [3.3.2. Supported HTTP Responses](#_3-3-2-supported-http-responses)
-        - [3.3.3. Common Error Payload](#_3-3-3-common-error-payload)
-    - [3.4. ULIDs as Unique Identifiers](#_3-4-ulids-as-unique-identifiers)
-    - [3.5. Inter-ledger Protocol v4 to represent the Cryptographic Terms](#_3-5-inter-ledger-protocol-v4-to-represent-the-cryptographic-terms)
-    - [3.6. ISO 20022 Supplementary Data Fields](#_3-6-iso-20022-supplementary-data-fields)
-- [4. Discovery Phase](#_4-discovery-phase)
-    - [4.1. Message flow](#_4-1-message-flow)
-    - [4.2. Parties Resource](#_4-2-parties-resource)
-- [5. Agreement Phase](#_5-agreement-phase)
-    - [5.1. Currency Conversion Agreement Sub-Phase](#_5-1-currency-conversion-agreement-sub-phase)
-        - [5.1.1. Message flow](#_5-1-1-message-flow)
-        - [5.1.2. fxQuotes Resource](#_5-1-2-fxquotes-resource)
-    - [5.2. Transfer Terms Agreement Sub-Phase](#_5-2-transfer-terms-agreement-sub-phase)
-        - [5.2.1. Message flow](#_5-2-1-message-flow)
-        - [5.2.2. Quotes Resource](#_5-2-2-quotes-resource)
-- [6. Transfer Phase](#_6-transfer-phase)
-    - [6.1. Accepting Currency Conversion terms](#_6-1-accepting-currency-conversion-terms)
-        - [6.1.1. Message flow](#_6-1-1-message-flow)
-        - [6.1.2. fxTransfers Resource](#_6-1-2-fxtransfers-resource)
-    - [6.2. Transfer Execution and Clearing](#_6-2-transfer-execution-and-clearing)
-        - [6.2.1. Message flow](#_6-2-1-message-flow)
-        - [6.2.2. Transfers Resource](#_6-2-2-transfers-resource)
+    - [2.1. How to Use This Document?](#_2-1-comment-utiliser-ce-document)
+        - [2.1.1. Relationship with Scheme-Specific Rules Documents](#_2-1-1-lien-avec-les-documents-de-regles-propres-au-schema)
+        - [2.1.2. Distinction Between Generic Practices and Scheme-Specific Requirements](#_2-1-2-distinction-entre-pratiques-generiques-et-exigences-propres-au-schema)
+- [3. Message Expectations, Obligations, and Rules](#_3-attentes-obligations-et-regles-applicables-aux-messages)
+    - [3.1. Currency Conversion](#_3-1-conversion-de-devises)
+    - [3.2. JSON Messages](#_3-2-messages-json)
+    - [3.3. APIs](#_3-3-api)
+        - [3.3.1. Header Details](#_3-3-1-details-des-en-tetes)
+        - [3.3.2. Supported HTTP Responses](#_3-3-2-reponses-http-prises-en-charge)
+        - [3.3.3. Common Error Payload](#_3-3-3-charge-utile-d-erreur-commune)
+    - [3.4. ULIDs as Unique Identifiers](#_3-4-ulid-comme-identifiants-uniques)
+    - [3.5. Inter-ledger Protocol v4 to represent the Cryptographic Terms](#_3-5-protocole-interledger-v4-pour-les-termes-cryptographiques)
+    - [3.6. ISO 20022 Supplementary Data Fields](#_3-6-champs-de-donnees-supplementaires-iso-20022)
+- [4. Discovery Phase](#_4-phase-de-decouverte)
+    - [4.1. Message flow](#_4-1-flux-de-messages)
+    - [4.2. Parties Resource](#_4-2-ressource-parties)
+- [5. Agreement Phase](#_5-phase-d-accord)
+    - [5.1. Currency Conversion Agreement Sub-Phase](#_5-1-sous-phase-d-accord-sur-la-conversion-de-devises)
+        - [5.1.1. Message flow](#_5-1-1-flux-de-messages)
+        - [5.1.2. fxQuotes Resource](#_5-1-2-ressource-fxquotes)
+    - [5.2. Transfer Terms Agreement Sub-Phase](#_5-2-sous-phase-d-accord-sur-les-conditions-de-transfert)
+        - [5.2.1. Message flow](#_5-2-1-flux-de-messages)
+        - [5.2.2. Quotes Resource](#_5-2-2-ressource-quotes)
+- [6. Transfer Phase](#_6-phase-de-transfert)
+    - [6.1. Accepting Currency Conversion terms](#_6-1-acceptation-des-conditions-de-conversion-de-devises)
+        - [6.1.1. Message flow](#_6-1-1-flux-de-messages)
+        - [6.1.2. fxTransfers Resource](#_6-1-2-ressource-fxtransfers)
+    - [6.2. Transfer Execution and Clearing](#_6-2-execution-et-compensation-du-transfert)
+        - [6.2.1. Message flow](#_6-2-1-flux-de-messages)
+        - [6.2.2. Transfers Resource](#_6-2-2-ressource-transfers)
 
 <!-- /TOC -->
 # 2. Introduction
@@ -59,9 +58,9 @@ Cette distinction permet aux DFSP d’implémenter un noyau de messagerie cohér
 
 # 3 Attentes, obligations et règles applicables aux messages
 Le processus de transfert Mojaloop comporte trois phases clés pour des transactions sûres et efficaces. Chaque phase s’appuie sur des ressources spécifiques pour les interactions entre participants, assurant communication, accord et exécution. Certaines phases et ressources sont facultatives ; l’objectif reste que chaque transfert soit exact, sécurisé et conforme aux conditions convenues.
-1. [Découverte](#_4-discovery-phase)
-2. [Accord](#_5-agreement-phase)
-3. [Transfert](#_6-transfer-phase)
+1. [Découverte](#_4-phase-de-decouverte)
+2. [Accord](#_5-phase-d-accord)
+3. [Transfert](#_6-phase-de-transfert)
 
 ## 3.1 Conversion de devises
 La conversion de devises prend en charge les transactions multi-devises. Comme elle n’est pas toujours nécessaire, les messages et flux associés ne sont utilisés qu’en cas de besoin, pour la flexibilité mono- ou multi-devises.