Modèle de retour d’expérience (REX)

Exemple — Contenu fictif à titre d'illustration

Migration réseau du bureau de Bruxelles — Revue de la Phase 2


Projet / Événement
Migration réseau du bureau de Bruxelles — Phase 2
Date de revue
07/02/2026
Animateur
TLThomas Laurent
Type de revue
Post-projet

🎯 Objectifs

Migrer le bureau de Bruxelles (140 postes de travail, 3 commutateurs d'étage, 1 routeur principal) de l'ancien réseau 100 Mbps vers la nouvelle infrastructure 1 Gbps pendant une seule fenêtre de maintenance le week-end (1–2 février 2026). Critères de succès : zéro interruption non planifiée le lundi matin, tous les appareils connectés au nouveau VLAN et connectivité VPN confirmée pour les 12 collaborateurs en télétravail.

📊 Résultats

Migration terminée dimanche à 18 h, 6 heures avant la date limite. 137 postes sur 140 connectés avec succès lundi matin. Trois appareils (2e étage, salles de réunion B et C) ont nécessité une réaffectation manuelle de VLAN — résolue avant 09 h 45. Connectivité VPN confirmée pour tout le personnel distant à 10 h. Débit mesuré : 940 Mbps en moyenne (objectif : 900+).

🔍 Analyse

Ce qui a bien fonctionné

  • Les tests pré-migration sur le bureau de Gand (réalisés en janvier) ont identifié le problème de taggage VLAN qui aurait affecté Bruxelles — économisant environ 3 heures de dépannage.
  • La procédure de retour arrière était documentée et répétée ; l'équipe aurait pu revenir en arrière en 45 minutes si nécessaire.

Ce qui pourrait être amélioré

  • Les appareils des salles de réunion n'étaient pas inclus dans l'inventaire pré-migration. Le système de gestion des actifs les classait sous « Équipement AV » plutôt que « Terminaux réseau », ils ont donc été omis lors de la planification.
  • L'e-mail de communication aux collaborateurs de Bruxelles a été envoyé à 17 h 30 vendredi — trop tard pour certains employés à temps partiel déjà partis.

✅ Actions à mener

ActionResponsableÉchéanceStatut
Mettre à jour le système de gestion des actifs pour classer les appareils de salle de réunion comme terminaux réseauMC14/02/2026En cours
Envoyer les communications de maintenance 48 h avant le début, pas le jour mêmeTLPermanentFait
Ajouter une étape de vérification d'inventaire pré-migration à la SOP de migration réseauSV21/02/2026En cours
Ceci est un exemple — créez le vôtre dans Elium

Structurez la manière dont votre équipe analyse ses projets et événements. Ce modèle capture ce qui était prévu, ce qui s’est réellement passé, pourquoi l’écart existe et ce qu’il faut changer la prochaine fois — pour que les leçons alimentent les projets futurs au lieu de s’effacer des mémoires.

Essayer dans Elium

Qu’est-ce qu’un retour d’expérience ?

Un retour d’expérience (REX) est une analyse structurée menée après un projet, un événement ou un jalon pour documenter ce qui était prévu, ce qui s’est réellement passé et pourquoi les deux divergent. Il produit des enseignements formalisés et des actions correctives précises qui alimentent les travaux futurs.

Issu des pratiques militaires et adopté par la gestion de projet, le retour d’expérience se situe entre le compte rendu immédiat d’incident et la rétrospective globale. Il est plus ciblé qu’une rétrospective complète — centré sur un livrable ou une phase spécifique — mais plus rigoureux qu’un débriefage informel. Le résultat est un document concis que tout membre de l’équipe peut consulter avant d’entamer un travail similaire.

Sans retours d’expérience documentés, les équipes reproduisent les mêmes erreurs. Les enseignements restent dans la tête de ceux qui étaient présents, invisibles pour l’équipe suivante confrontée au même défi.

Qui devrait utiliser ce modèle ?

Ce modèle de retour d’expérience s’adresse aux équipes responsables de la livraison de projets et de la qualité opérationnelle :

  • Responsables des opérations — normalisent les débriefages post-projet entre départements pour que les leçons circulent entre sites et équipes
  • Chefs de projet — conduisent des analyses structurées après chaque jalon ou clôture de projet, avec des actions correctives et des responsables désignés
  • Responsables des connaissances — capitalisent les enseignements projet dans un format consultable qui alimente la planification future et la recherche par IA
  • Responsables d’équipe — offrent à leurs collaborateurs un cadre reproductible pour une réflexion honnête, sans recherche de coupable

Que contient ce modèle ?

Le modèle se compose de deux parties : des champs de métadonnées structurés et des sections narratives.

Les champs de métadonnées posent le contexte :

  • Nom du projet ou de l’événement
  • Responsable du projet
  • Date du retour d’expérience
  • Participants — membres de l’équipe ayant contribué
  • Phase du projet (par ex. post-projet, jalon, post-incident)

Les sections narratives guident l’analyse :

  • Objectifs et résultats attendus — ce qui était prévu, incluant les critères de réussite et les jalons clés
  • Résultats obtenus — ce qui s’est réellement passé, étayé par des données quand c’est possible
  • Ce qui a bien fonctionné — pratiques et décisions à reproduire
  • Ce qui n’a pas fonctionné — écarts constatés et leurs causes racines
  • Actions correctives — changements précis pour la prochaine fois, avec responsables et échéances

Comment créer et personnaliser ce modèle dans Elium

  1. Ouvrir le constructeur de modèles — Rendez-vous dans votre menu profil et sélectionnez l’onglet Constructeur de modèles, ou cliquez sur « + Créer » puis choisissez « Créer un nouveau modèle ».
  2. Définir le périmètre — Choisissez une icône, activez le modèle et décidez s’il s’applique à l’ensemble de la plateforme ou à des espaces spécifiques (par ex. votre espace Projets).
  3. Ajouter les champs structurés — Cliquez sur « Champ » pour ajouter les métadonnées : un champ texte pour le nom du projet, un champ utilisateur pour le responsable, un champ date pour la date du retour d’expérience, un champ utilisateur pour les participants et un champ étiquette pour la phase (préremplissez avec « Post-projet », « Jalon », « Post-incident »). Rendez obligatoires le nom du projet et la phase.
  4. Construire la structure de l’analyse — Utilisez le bouton « + » pour ajouter des blocs de contenu pour chaque section narrative : objectifs et résultats obtenus en blocs texte, ce qui a bien fonctionné et ce qui n’a pas fonctionné en blocs texte, et les actions correctives sous forme de tableau avec les colonnes action, responsable, échéance et statut.
  5. Prévisualiser et enregistrer — Vérifiez la mise en page du modèle, puis enregistrez. Les membres de l’équipe peuvent désormais le sélectionner lors de la création d’articles, et vous pouvez l’appliquer au contenu existant en masse.

Comment l’IA vous aide à créer et utiliser ce modèle

Rédigez plus vite. Après la séance de débriefage, transmettez les notes de réunion ou la transcription à l’IA d’Elium. Elle génère un premier brouillon structuré — objectifs, résultats, analyse et actions correctives — que l’animateur relit et affine au lieu de tout rédiger de zéro.

Recherchez plus intelligemment. Avant de lancer un projet similaire, interrogez l’IA d’Elium : « Quels enseignements avons-nous tirés de la migration du bureau de Bruxelles ? » L’IA renvoie les constats et les actions correctives de votre précédent retour d’expérience — pas un guide générique de gestion de projet.

Pourquoi les équipes utilisent Elium pour les retours d’expérience

Un retour d’expérience n’a de valeur que si l’équipe suivante peut le retrouver. Un débriefage enregistré dans un dossier local aide une équipe une seule fois. Un retour d’expérience structuré et publié dans Elium aide toutes les équipes confrontées à un défi similaire — car la recherche alimentée par l’IA fait remonter les enseignements à partir d’une question en langage naturel, pas d’un nom de fichier.

Bouygues Construction — 53 500 collaborateurs répartis dans 80 pays — a centralisé ses connaissances opérationnelles dans Elium pour résoudre précisément ce problème. Les enseignements projet étaient cloisonnés dans des dossiers locaux et des courriels. En structurant les connaissances dans Elium, ils ont offert à leurs équipes distribuées une source de référence unique — réduisant les erreurs répétées et rendant l’apprentissage inter-sites concret.

FAQ — Questions fréquentes

Un retour d’expérience est une analyse structurée qui documente ce qui était prévu, ce qui s’est passé et pourquoi l’écart existe. Sans retours d’expérience formalisés, les équipes reproduisent les mêmes erreurs car les enseignements restent informels — tributaires de la mémoire plutôt que de documents partagés. Des retours réguliers construisent une bibliothèque consultable de leçons projet qui améliore la planification.
Un modèle complet comprend des métadonnées (nom du projet, date, responsable, phase) et des sections narratives couvrant les objectifs, les résultats obtenus, l’analyse des écarts, les actions correctives avec responsables et échéances, et un plan de suivi. Les meilleurs modèles capturent aussi ce qui a bien fonctionné — pas seulement les dysfonctionnements — pour reproduire les réussites.
Les retours d’expérience structurés réduisent les erreurs répétées en transformant l’expérience projet en connaissances partagées. Ils raccourcissent la planification car les équipes s’appuient sur des enseignements documentés au lieu de repartir de zéro. Au fil du temps, une bibliothèque de retours d’expérience révèle des schémas opérationnels — goulets d’étranglement récurrents, risques sous-estimés et pratiques qui fonctionnent systématiquement.
Commencez par reformuler les objectifs initiaux — ce à quoi ressemblait la réussite avant le lancement du projet. Documentez ce qui s’est réellement passé, données à l’appui quand c’est possible. Analysez l’écart sans chercher de coupable : concentrez-vous sur les processus, pas sur les personnes. Terminez par des actions correctives concrètes, attribuées et assorties d’une date de suivi.
Un retour d’expérience porte sur un projet ou un événement précis — il compare les résultats prévus aux résultats réels. Une rétrospective couvre une période plus large, généralement un sprint ou un trimestre, et examine les méthodes de travail de l’équipe. Les deux produisent des enseignements, mais le retour d’expérience est ciblé sur un livrable défini tandis que la rétrospective analyse le fonctionnement global de l’équipe.

Related reading: Read more on our blog