> For the complete documentation index, see [llms.txt](https://urd.gitbook.io/compass/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://urd.gitbook.io/compass/home/home-fr/apprentissage-et-adaptation/apprendre-de-lexperience-et-partager-les-enseignements/processus-structures-dapprentissage-des-lecons.md).

# Processus structurés d’apprentissage des leçons

### <mark style="color:orange;">Quand une expérience mérite plus qu’un débriefing</mark>

Un **processus structuré d’apprentissage des enseignements** est ce vers quoi vous vous tournez lorsqu’une revue après action ne suffit pas. L’expérience s’étend sur plusieurs équipes ou phases, implique des parties prenantes au-delà de l’équipe projet, ou est jugée suffisamment importante pour qu’il vaille la peine d’y consacrer du temps afin d’en faire un véritable savoir transférable.

Contrairement au débriefing immédiat, il ne se fait pas spontanément. Il **doit être planifié**: quelqu’un décide de le faire, définit son objectif et va jusqu’à un document rédigé et partagé.

***

### <mark style="color:orange;">**Les quatre étapes**</mark>

<details>

<summary><strong>1. Cadrage</strong></summary>

De quelle expérience, exactement, tirez-vous des enseignements ? À quelle question est-elle censée répondre ? À qui est-elle destinée (c’est-à-dire à l’équipe elle-même, à l’organisation au sens large, aux partenaires, au secteur) ? Sauter cette étape est de loin la raison la plus fréquente pour laquelle ces processus dérivent et ne sont jamais menés à terme.

</details>

<details>

<summary><strong>2. Collecte</strong></summary>

Entretiens individuels ou collectifs, ateliers de restitution avec les équipes concernées et, lorsque cela est possible, les communautés concernées, ainsi qu’une revue de la documentation existante (c’est-à-dire les données de suivi, les notes d’AAR déjà produites, les rapports).

</details>

<details>

<summary><strong>3. Analyse</strong></summary>

Distinguez ce qui est propre à ce contexte de ce qui pourrait s’appliquer ailleurs. Identifiez ce qui a fonctionné et ce qui n’a pas fonctionné, sans lisser les échecs. Un processus qui se concentre uniquement sur les réussites risque fort de passer à côté d’éléments d’apprentissage importants.

</details>

<details>

<summary><strong>4. Formalisation et restitution</strong></summary>

Produisez un livrable court et utilisable (voir [Documenter et partager : formats, diffusion et mesures de protection](/compass/home/home-fr/apprentissage-et-adaptation/apprendre-de-lexperience-et-partager-les-enseignements/documenter-et-partager-formats-diffusion-et-mesures-de-protection.md)), puis partagez-le avec les personnes qui ont contribué avant de le diffuser plus largement.

</details>

> Sauter l’étape de cadrage pour passer directement à la collecte d’informations est la raison la plus fréquente pour laquelle ces processus s’enlisent. Sans question ni public clairement définis, l’exercice s’étend indéfiniment et n’atteint jamais l’étape 4.

***

### <mark style="color:orange;">**Animer un atelier d’apprentissage**</mark>

**Deux versions, selon le temps et les ressources disponibles.**

| Version allégée                                    | Version complète                                                                             |
| -------------------------------------------------- | -------------------------------------------------------------------------------------------- |
| Un atelier d’une demi-journée avec l’équipe projet | Plusieurs séances réparties sur quelques semaines                                            |
| Animé en interne                                   | Animation externe ou dédiée, en particulier pour les sujets sensibles                        |
| Le livrable pourrait être une fiche de deux pages  | Le livrable pourrait être une étude de cas, une note d’orientation, du matériel de formation |
| Partagé en interne                                 | Partagé en interne et en externe (partenaires, plateformes de coordination)                  |

Commencez par défaut avec la version allégée. Passez à la version complète seulement lorsque l’étape de cadrage a confirmé que l’expérience le justifie réellement, et non parce qu’un processus plus lourd paraît plus légitime.

{% file src="/files/4b8f134adf2d3933bc3fbf3d35114b1e5a521535" %}

***

### <mark style="color:orange;">**En quoi cela diffère d’une évaluation**</mark>

Un processus structuré d’apprentissage des enseignements n’a pas besoin d’être mené par une personne externe, et il **n’évalue pas la performance au regard de critères prédéfinis** (comme les critères du CAD de l’OCDE utilisés dans les évaluations). Il part de l’ **expérience vécue de l’équipe** et cherche à en tirer du sens, de manière descriptive et réflexive plutôt que normative. Il peut toutefois s’appuyer sur les données et les conclusions d’une évaluation existante comme l’une de ses entrées.

***

### <mark style="color:orange;">**Points clés**</mark>

* Réservez cette méthode aux expériences qu’un AAR ne permet pas d’explorer à leur juste mesure, et non comme exercice par défaut de fin de projet.
* Cadrez avant de collecter : sans question ni public clairement définis, le processus dérive.
* Privilégiez par défaut la version allégée ; passez à une version plus complète seulement lorsque le cadrage confirme que c’est justifié.
* Documentez les échecs avec autant d’honnêteté que les succès : c’est là que réside l’essentiel de la valeur transférable.
* Cela complète l’évaluation ; cela ne la remplace pas.