Le Forum PHP 2025 avait cette année une saveur tout particulière. L’écosystème PHP célébrait plusieurs anniversaires marquants :

• 30 ans de PHP
• 25 ans de l’AFUP (Association Française des Utilisateurs de PHP)
• 20 ans de Symfony
• 10 ans d’API Platform.

Autant de jalons qui rappellent à quel point la communauté PHP reste vivante, innovante et tournée vers l’avenir. Présente pour l’occasion, l’équipe de Conserto a plongé au cœur de ces célébrations et exploré les tendances qui façonneront le futur du développement web.

Les grandes tendances de cette édition

Cette édition anniversaire a mis en lumière un écosystème mature et moderne :

• D’un côté, la sortie de PHP 8.5 (récemment sortie le 20 novembre 2025) confirme la volonté du langage de poursuivre sa montée en puissance en facilitant toujours plus le travail des développeurs.
• De l’autre, les conférences ont présenté les grandes évolutions de Symfony, API Platform, et FrankenPHP, retraçant leurs parcours respectifs et leurs ambitions futures.
• Enfin, l’intelligence artificielle a traversé l’événement comme un fil rouge, illustrant de nouvelles perspectives pour nos métiers et nos outils.

❤️ Nos conférences coups de coeur

20 ans de Symfony et maintenant ?

Speaker : Nicolas Grekas

Le framework d’APIs qui capitalise sur 30 ans de maturité du langage PHP

Speaker : Antoine Bluchet

Atteindre la qualité d’une SPA avec HTMX et Twig

Speaker : Damien Alexandre

What’s new in PHP 8.5

SQL vs Les Préjugés

Speaker : Laetitia Avrot

Perf et injection de dépendances – êtes-vous suffisamment paresseux-ses

Speaker : Nicolas Grekas

L’évaluation des IAs : la recette secrète des agents pas trop bêtes

Speaker : François Zaninotto

Conclusion

Cette édition du Forum PHP 2025 confirme que l’écosystème PHP n’a jamais été aussi dynamique.
Entre les évolutions de fond (Symfony 8, PHP 8.5, API Platform 4.2), la montée en puissance des outils d’analyse et de qualité, et l’ouverture vers l’IA intégrée aux applications, nous ressortons inspirés et motivés.

Pour nous, ces deux jours ont été l’occasion de :

• consolider notre veille technologique,
• identifier des pistes d’amélioration concrètes pour nos projets clients,
• et surtout, partager notre enthousiasme pour un PHP moderne, robuste et résolument tourné vers l’avenir.

The post Forum PHP 2025 : entre immersion technique et exploration des tendances à venir appeared first on Conserto.

Découvrez la troisième édition du Calendrier de l’après Conserto ! Nous vous proposons, tout au long du mois de janvier, des idées d’ateliers, des inspirations, des bonnes pratiques, des outils, en lien avec l’agilité, pour bien démarrer l’année.

2 janvier

Check list 360° Produit pour un PO

Imaginez un Product Owner qui se demande : “Est-ce que mon produit est vraiment sur les rails ? Est-ce que mon équipe a tout ce qu’il faut pour performer ?” 
Souvent, on avance vite, on livre, mais on oublie de prendre du recul. 

C’est là que la Check-list 360° Produit entre en jeu. 

La Check-list 360° Produit est un outil conçu pour les Product Owners et Product Managers afin de réaliser un audit complet de leur produit et de leur organisation. Elle couvre tous les leviers de performance : vision stratégique, expérience utilisateur, backlog, qualité, technique, business, conformité…  

L’objectif ? S’assurer que chaque aspect du produit est maîtrisé, identifier les zones d’amélioration et prioriser les actions pour gagner en pertinence et en performance.  

Concrètement, cette check-list vous aide à passer en revue 12 dimensions clés, avec des pratiques et outils associés, pour transformer votre produit en véritable moteur de valeur. 

Télécharger la check-list

5 janvier

Connaissez-vous le “Product Ops” ? 

Faire fonctionner une organisation produit, ce n’est pas facile.

Un rôle a émergé ces dernières années pour faciliter le fonctionnement : le Product Ops.

Un rôle support qui fournit des outils et des éléments pour réduire la charge cognitive des équipes produits, sur les aspects de Product Management.

Dans cette interview, Sarah Dufour nous explique en quoi cela consiste :

View video

6 janvier

Késako le Product Operating Model (POM) ?

Le Product Operating Model  (POM) c’est une manière d’organiser une entreprise autour de ses produits. C’est un cadre multidimensionnel qui définit comment une entreprise conçoit, développe et livre ses produits ou services pour répondre aux besoins des clients et atteindre ses objectifs commerciaux. 

Cette approche englobe l’agilité mais la dépasse : elle définit comment les décisions produit sont prises, comment la stratégie se traduit en exécution, comment l’organisation apprend et s’adapte.

Pour aller plus loin, découvrez ces deux articles de Rachel Dubois  :

Lire l’article

Lire l’article

7 janvier

De la raison d’être de l’équipe à la vision Produit

Avant le produit, il y a l’équipe qui le construit et le fait évoluer. 
 

Avant d’établir la vision Produit, il peut être nécessaire, en prérequis, d’établir la raison d’être de l’équipe (ou de la réaffirmer pour une équipe déjà existante). 

En effet, si la mission et les objectifs de l’équipe ne sont pas clairs et pas partagés cela va être un vrai frein pour le bon déroulement d’un atelier de type Vision Produit. 

Voici un canevas et un atelier pour vous aider : 

Atelier : Raison d’être de l’équipe

Dans cet article vous allez trouver : 

• Un canevas pour aider à aligner les acteurs la mission et les objectifs de l’équipe 
• Le déroulé de l’atelier et un guide de facilitation 
• Un modèle de manifeste d’équipe afin communiquer plus facilement avec le reste de l’organisation 
• Un exemple concret réalisé dans une équipe 

8 janvier

Roadmap Agile : comment réussir l’exercice ?

En tant que Product Owner ou Product Manager vos interlocuteurs vous demandent souvent une “Roadmap”. 

Le piège est de confondre roadmap produit et plan de release. 

Dans cette vidéo qui suit, découvrez des conseils pour des roadmaps réellement au service du produit : 

👍  des principes à respecter 

❌  des pièges à éviter 

✅  des exemples de formats 

View video

9 janvier

Le Value Proposition Canvas : un outil pour aligner votre offre avec les besoins de vos clients 

Le Value Proposition Canvas est un outil simple et puissant pour s’assurer que votre offre crée de la valeur réelle. Il vous aide à comprendre ce que vos utilisateurs veulent accomplir… et à aligner votre produit ou service pour y répondre parfaitement. 

Il se compose de deux parties : 

• Le profil utilisateur (jobs, pains, gains) qui décrit ce que vos utilisateurs et clients essaient d’accomplir, leurs frustrations et leurs attentes. 

• La carte de valeur (produits/services, pain relievers, gain creators) qui montre comment votre offre répond à ces besoins. 

Ses avantages : 

• Clarifie la compréhension des utilisateurs et clients et de leurs priorités. 

• Permet d’identifier les points de différenciation et d’améliorer l’adéquation produit-marché. 

• Favorise la collaboration entre équipes en offrant un langage commun. 

• Réduit le risque d’échec en centrant l’innovation sur la valeur réelle. 

En résumé, le Value Proposition Canvas, c’est un GPS pour créer des offres qui comptent vraiment ! 

Cet outil a été inventé et est proposé gratuitement par Strategyzer.

Sur leur site, vous pouvez télécharger le canvas ainsi que plusieurs fiches de questions tremplins pour vous guider dans votre réflexion : 

Télécharger les assets

Pour aller plus loin, Strategyzer a écrit un livre très complet pour vous aider dans la création de vos produits ou services : 

Plus d’infos

12 janvier

Le Double Diamant : comprendre avant d’agir

Le Double Diamant est un cadre qui structure l’approche produit en quatre étapes simples : explorer, définir, imaginer, construire. 

Le principe : d’abord comprendre le problème, ensuite explorer et tester les solutions, en alternant divergence (ouvrir le champ des possibles) et convergence (faire des choix éclairés). 

• Explorer le problème : comprendre la situation et les usages. Exemple : interviews, observation, analyse de données. 

• Définir le problème : clarifier ce qu’on veut résoudre. Exemple : synthèse des insights, formulation du problème. 

• Imaginer des solutions : générer plusieurs pistes. Exemple : brainstorming, croquis. 

• Construire la solution : tester et choisir la solution la plus pertinente. Exemple : prototypage, tests utilisateurs. 

Quand l’utiliser ? 

Il est utile dès qu’on veut s’assurer de bien comprendre le problème avant de se lancer sur une solution : 

• le problème est flou ou manque d’informations, 

• il arrive déjà formulé comme une solution, 

• le sujet est complexe et nécessite de poser les choses étape par étape. 

Pour aller plus loin 

Le Design Council propose des explications détaillées et des exemples d’activités pour chaque étape : 

Je découvre

13 janvier

RIC(E) : prioriser le discovery simplement

On connaît bien les méthodes pour prioriser le delivery (MoSCoW, story mapping, story points…).
Mais quand il s’agit de prioriser le discovery, c’est plus flou : quels problèmes explorer en premier ? Par où commencer ?

Parfois, il n’y a que peu de sujets éligibles au discovery : inutile de sur-outiller.
Mais si plusieurs sujets se présentent et que le choix devient difficile, RIC(E) est un moyen simple d’estimer la valeur potentielle des problèmes avant même de chercher des solutions.

Et vous allez voir que ce sont des questions qu’il est de toute façon intéressant, voire indispensable, de se poser.

Les critères du RIC(E)

RICE repose sur quatre critères :

Reach (portée)

• Quel pourcentage d’utilisateurs ? 

• À quelle fréquence ? 

• Combien d’occurrences ? 

 
On mesure ici l’ampleur du problème. 

Impact

• À quel point le problème affecte-t-il les utilisateurs ? 

• Que se passe-t-il si on ne fait rien ? Et si on le résout ? 

• Quel impact pour le business et les objectifs Produit ?

On évalue ici l’importance du problème. 

Confiance

• Qu’est-ce qui repose sur des données concrètes ?
• Qu’est-ce qui relève d’hypothèses ou d’intuition ?

Il s’agit d’estimer la solidité de nos informations.

Effort

• Quel effort pour construire la solution ?

En pré-discovery, estimer l’effort est souvent peu pertinent.

On utilise donc surtout RIC : Reach – Impact – Confiance.

Et vous pouvez ne pas avoir toutes les réponses. Rien ne vous empêche aussi de noter ces questionnements que vous pourrez adresser au travers de votre discovery.

Comment l’utiliser ?

Seul ou avec les parties prenantes, on passe chaque problème en revue rapidement en répondant aux questions associées aux critères.
Le PO ou PM attribue ensuite un score (de 1 à 5) pour chaque critère. Comme il n’existe pas de règle stricte sur la manière de noter, le score reste subjectif et la comparaison est donc relative. Pour garder de la cohérence, il est préférable que la même personne attribue les scores d’un sujet à l’autre.

Score = Reach × Impact × Confiance
(et / Effort si vous choisissez de le conserver)

Ce score permet de classer les sujets selon leur potentiel et de visualiser rapidement ceux qui méritent d’être explorés en priorité.

RIC(E) reste un guide, pas une vérité absolue.
Si un sujet classé 4ᵉ semble en réalité plus simple, plus stratégique ou plus opportun, explorez-le.
En revanche, si vous envisagez de commencer par le dernier de la liste, challengez votre choix : cela peut révéler un biais ou un critère oublié.

Quand l’utiliser ?

RIC(E) est utile lorsque vous avez plusieurs sujets à explorer et que vous voulez :

• Savoir par où commencer : identifier rapidement les problèmes qui méritent le plus d’attention,
• Poser les bonnes bases du discovery : se poser les questions essentielles avant de se lancer dans la recherche ou les prototypes,
• Aligner les parties prenantes : partager une vision commune sur ce qui est prioritaire et pourquoi.

Vous pouvez l’utiliser ponctuellement ou en continu.
L’essentiel : qu’il vous aide à y voir plus clair, sans alourdir votre quotidien.

14 janvier

Focused Discovery Discipline : une approche structurante du discovery en 7 étapes 

Le Double Diamant est souvent présenté comme une référence en matière de discovery : un diamant pour explorer le problème, un autre pour explorer la solution.

C’est clair, simple, mais parfois trop générique pour aider les équipes à structurer réellement leur démarche dans le temps. 

L’approche F.O.C.U.S.E.D. (présentée dans le livre Discovery Discipline) propose une alternative : 7 diamants, chacun dédié à une étape précise du discovery. 

L’objectif n’est pas d’ajouter de la complexité, mais d’apporter du focus : savoir exactement sur quoi se concentrer à chaque phase, dans quel ordre, et avec quel livrable attendu. 

Chaque étape peut durer 5 minutes comme plusieurs semaines. Ce n’est pas une approche qui va alourdir votre discovery. 

Cela dépend du contexte, du niveau d’ambition et de l’effort qu’on souhaite investir. L’essentiel est de timeboxer la démarche dès le départ, ce qui fait partie intégrante de la première étape. 
 
Voici les 7 étapes, leurs objectifs, leur utilité et ce que l’on attend des livrables associés. 

1. Frame 

• Objectif : cadrer l’ambition du projet. 

• Livrable « Project Ambition » : définir les critères de succès, les contraintes clés et la timebox du discovery. 

• Pourquoi ? : aligner tout le monde sur l’impact attendu et l’effort à investir, et éviter un discovery interminable. 

2. Observe 

• Objectif : identifier le premier cas d’usage. 

• Livrable « First Use Case » : décrire l’utilisateur principal, son contexte et le problème à résoudre à travers un cas d’usage précis. 

• Pourquoi ? : choisir le problème précis à traiter pour atteindre l’ambition et éviter de se disperser. 

3. Claim 

• Objectif : formuler la promesse faite à l’utilisateur. 

• Livrable « Launch Tweet » : formuler un tweet qui résume clairement la valeur apportée par la future solution. 

• Pourquoi ? : guider les étapes suivantes et donc le choix de la solution avec une promesse cohérente par rapport à l’ambition et au cas d’usage choisi. 

4. Unfold 
 

• Objectif : définir les étapes essentielles de l’expérience. 

• Livrable « 5 Touchpoints » : identifier les points de contact essentiels dans l’expérience utilisateur pour tenir la promesse. 

• Pourquoi ? : Visualiser le parcours critique et choisir les moments clés pour interagir avec l’utilisateur et résoudre son problème. 

5. Steal 
 

• Objectif : capitaliser sur ce qui fonctionne ailleurs. 

• Livrable « Gold nuggets » : lister et analyser des solutions existantes et leurs patterns à réutiliser ou adapter (pour les points de contact ou plus largement). 

• Pourquoi ? : Gagner du temps, s’inspirer de solutions efficaces et éviter de réinventer la roue. 

6. Execute 
 

• Objectif : matérialiser l’expérience pour la tester. 

• Livrable « Happy path » : construire un prototype fonctionnel et documenter les hypothèses principales à tester. 

• Pourquoi ? : Préparer les moyens nécessaires pour évaluer la solution. 

7. Decide 
 

• Objectif : décider de poursuivre ou non. 

• Livrable « Go/NoGo » : décider de partir en delivery ou non avec la solution. 

• Pourquoi ? : confronter la solution et les hypothèses à des utilisateurs pour décider si le discovery est terminé. 

Pour aller plus loin 
Si cette approche a éveillé votre curiosité, n’hésitez pas à vous procurer le livre Discovery Discipline. Vous y retrouverez notamment les activités possibles à chaque étape ainsi que des exemples concrets. 

Plus d’infos

15 janvier

Comprendre ses utilisateurs : les entretiens 

Dans le cadre d’un discovery produit, l’objectif est de creuser un problème avant de se lancer dans la solution. 

Cela implique de comprendre ses utilisateurs : qui ils sont, ce qu’ils cherchent à accomplir et quels obstacles ils rencontrent. 

Parmi toutes les méthodes possibles (observation, analyse des usages, feedbacks clients, enquêtes…), si on devait n’en choisir qu’une, ce seraient les entretiens utilisateurs. Ils permettent d’explorer en profondeur comportements, besoins et motivations, et servent de base solide au discovery. 

Préparer un entretien efficace 

Avant de rencontrer un utilisateur 

• Définir l’objectif : ce que vous voulez apprendre, pas ce que vous voulez valider. 

• Clarifier la cible : qui souhaitez-vous vraiment comprendre, selon quels critères ? 

• Recruter un panel représentatif : 5 à 7 personnes suffisent pour générer des insights significatifs. 

• Préparer un guide d’entretien : un fil conducteur flexible, ni trop rigide, ni trop vague. 

• Être accompagné si possible : difficile de prendre des notes et d’adopter la bonne posture en même temps. 

Bonnes pratiques pendant l’entretien 

Pendant l’entretien 

• Écouter plus que parler : laisser l’utilisateur s’exprimer (viser un ratio 80/20). 

• Poser des questions ouvertes et relancer sur des exemples concrets : “comment ?”, “racontez-moi…”, “pourquoi ?” 

• Reformuler pour valider : “Si je comprends bien… ?” 

• Utiliser le silence à bon escient pour que la personne complète ses propos. 

• Noter les verbatims sans interpréter pendant l’entretien. 

Erreurs à éviter 

• Chercher à vendre ou défendre le produit. 

• Tenter de valider ses idées plutôt que de comprendre la réalité. 

• Poser des questions fermées, orientées ou multiples : “Est-ce que vous préférez… ?” 

• Parler plus que l’utilisateur ou remplir les silences. 

• Réagir émotionnellement aux réponses. 

Formaliser et exploiter les insights 

Une fois l’entretien terminé, l’objectif n’est pas de tout retranscrire, mais de capturer l’essentiel : qui est l’utilisateur, ce qu’il cherche à accomplir, ce qui le bloque, ce qu’il ressent et les verbatims clés. 
L’enjeu n’est pas d’empiler des données, mais d’en extraire des informations actionnables. 

Quand plusieurs entretiens ont été menés, les tendances commencent à émerger. Plutôt que de résumer chaque cas individuellement, on croise les informations pour identifier des patterns, faire émerger et prioriser les problèmes, repérer des opportunités. 

Pour aller plus loin 
Plusieurs outils peuvent être utiles pour organiser besoins, comportements, irritants et motivations et donc structurer les enseignements issus des entretiens. 

Voici 2 exemples d’outils qui pourraient vous aider. Explorez ces ressources si vous souhaitez creuser davantage : 
 

En savoir plus

En savoir plus

16 janvier

Construire une roadmap produit alignée avec la stratégie 

Une roadmap produit n’est pas une liste de fonctionnalités. Elle doit relier stratégie et opérationnel pour que chaque initiative contribue à l’ambition globale. On peut la construire en 4 étapes clés : 

1. Formaliser la vision produit 

Commencez par les axes stratégiques de l’entreprise : lisez-les ensemble, identifiez leur impact sur votre produit et formalisez une vision claire (par exemple avec un Product Vision Board) pour aligner l’équipe sur le “pourquoi” et la trajectoire à suivre. 

2. Définir les objectifs 

En comparant la vision produit à votre produit actuel, vous identifiez les écarts et les enjeux à adresser. Définissez ensuite des objectifs clairs, idéalement SMART, pour rendre ces enjeux actionnables et mesurables. 

C’est proche des OKR dans l’esprit, mais plus simple à mettre en place. 

3. Générer des idées de fonctionnalités 

Pour chaque objectif, explorez les moyens d’y répondre : pour qui ? Avec quel impact ? Par quelle fonctionnalité ? 

Vous pouvez utiliser, par exemple, l’impact mapping pour relier objectifs, acteurs, impacts et idées, et générer des initiatives cohérentes avec vos objectifs. 

4. Prioriser et construire la roadmap 

La roadmap peut mêler des sujets encore en discovery et d’autres prêts pour le delivery. 
Comparez leur potentiel : impact sur les objectifs et effort demandé. Une estimation rapide en taille de t-shirt et une matrice impact/effort suffisent pour faire ressortir les priorités. 
Ensuite, organisez les éléments dans la roadmap : quelles fonctionnalités, quand, et pour quel impact. 
Et n’oubliez pas, ce n’est qu’une projection, pas un engagement strict. 

Pour aller plus loin 
Quelques outils ou templates :

En savoir plus

En savoir plus

En savoir plus

En savoir plus

En savoir plus

19 janvier

Avoir le mode d’emploi pour travailler (mieux) avec vos collègues, ça vous dit ?​

Pour Noël j’ai eu un super cadeau hightech !

Aussitôt déballé, j’ai appuyé sur tous les boutons sans produire les effets escomptés. Déception !

Heureusement, en lisant la notice d’utilisation j’ai pu enfin profiter de mon cadeau.

Et si on reproduisait la même chose avec nos collègues ?

Nous avons la chance de travailler avec des gens exceptionnels MAIS sans toujours connaitre leur mode d’emploi.

Et si, pour mieux collaborer, on prenait le temps de réfléchir en équipe sur nos modes d’emploi?

Avec cette trame, concevoir (et partager) sa notice d’utilisation devient un jeu d’enfant !

Télécharger la trame

Cette article a été inspiré par : https://www.fearlessculture.design/blog-posts/team-washing-instructions-canvas

Merci à Irène Doan.

20 janvier

La carte culturelle pour mieux collaborer

Vous souhaitez faciliter et renforcer la collaboration au sein de votre équipe, je vous propose de vous inspirer de la carte culturelle crée par Erin Meyer (The Culture Map, Erin Meyer). 

L’idée est simple, chacun se positionne sur un gradient pour 8 critères. 

L’avantage : il n’y a pas de « bonnes » ou de « mauvaises » réponses, juste la perspective de mieux comprendre les réactions de ses co-équipiers et de pouvoir en discuter.

Télécharger la carte

Cette article a été inspiré par : https://erinmeyer.com/books/the-culture-map/  

Merci à Laetitia  Thernier & Romain Blanco pour la découverte de ce livre !

21 janvier

La Voix du Client (VoC)

Le premier pilier du Lean Kaizen représente la valeur que nous livrons à nos clients. 

La Voix du Client (Voice of Client en anglais, ou VoC) est un outil efficace pour recueillir la satisfaction d’un client et obtenir de sa part des pistes d’amélioration actionnables. 

Quand utiliser la Voix du Client ? 

Dans la foulée de la livraison d’une version, d’une fonctionnalité. L’objectif n’est pas d’obtenir un indicateur de satisfaction global de l’ensemble des utilisateurs mais bien d’évaluer la satisfaction d’un client par rapport à une “pièce” spécifique livrée dernièrement. 

D’accord. Et comment on fait ça ? 

L’atelier consiste en une interview d’une vingtaine de minutes au cours de laquelle nous posons une série de question au client : 

• On questionne sur le quoi : Qu’attendiez-vous de la part de l’équipe sur ce sujet ? A-t-on complètement répondu à votre demande ? 

• On questionne le client sur le quand : Quand attendiez-vous la réponse de l’équipe ? A-t-on répondu dans les délais ? 

• On questionne le client sur le où : Quels sont les canaux de communications que vous souhaitez pour suivre votre demande ? Avez-vous eu toute la documentation souhaitée et au bon endroit ? 

• On questionne le client sur le comment : Vous a-t-on fait perdre du temps ? 

• On questionne le client sur la fiabilité : avons-nous été fiable dans le traitement de votre demande (répondu bon du premier coup) ? 

• On demande une note au client (sur 10) pour obtenir un Net Promoter Score (NPS) : à quel point le client recommanderait-il notre service ? 

• Qu’aurait-il fallu pour avoir 10 ? On va chercher des éléments spécifiques : ce sont des sources d’amélioration actionnables. 

L’astuce est d’ancrer cette pratique dans le flux et les rituels d’équipe : 

• on peut planifier une ou deux VoC à chaque livraison 

• les résultats de ces VoC peuvent nourrir la prochaine rétrospective d’équipe 

Et surtout, on remercie le client pour le temps qu’il nous a accordé ainsi que pour ses idées ! 

22 janvier

Impact Mapping : un outil stratégique pour concevoir moins et mieux 

Dans un monde numérique qui accélère plus vite que notre capacité à en mesurer les conséquences, le rôle d’un Product Manager ou Product Owner change profondément. Nous ne sommes plus seulement responsables de l’expérience ou de la valeur business : nous devenons garants de l’impact global du produit : social, économique, mais aussi environnemental. 

Parmi les outils capables d’accompagner ce changement, l’Impact Mapping occupe une place stratégique. D’apparence simple, il est en réalité l’un des plus puissants leviers de priorisation frugale dont dispose une équipe produit. 

1. Clarifier le “Pourquoi” avant le “Quoi” 

La première force de l’impact mapping est de recentrer la discussion sur l’intention : 

• Quel est l’objectif réel du produit ? 

• Quel comportement cherche‑t‑on à encourager ou éviter ? 

Or, dans une démarche d’écoconception, cette étape est essentielle : on identifie ainsi rapidement les fonctionnalités superflues, coûteuses en ressources, mais à faible valeur. 

2. Mettre en lumière les “acteurs” et leurs impacts réels 

En reliant l’objectif à ses “acteurs” (utilisateurs, partenaires, équipes internes), on observe mieux les comportements qui génèrent des charges techniques, du trafic réseau, des données à stocker ou des parcours énergivores. 

Ce n’est pas seulement un outil produit : c’est un outil de sobriété. 

3. Choisir les bons livrables plutôt que le maximum de livrables 

La dernière étape consiste à définir ce qui doit être construit, mais surtout ce qu’il ne faut pas construire. 

En écoconception, renoncer est un acte fort : 

➡️ moins de fonctionnalités → moins de code à maintenir → moins de serveurs → moins d’énergie → plus de clarté pour l’utilisateur. 

4. L’impact mapping comme outil de gouvernance responsable 

Il facilite aussi la transparence et l’alignement : chaque livraison peut être reliée à un objectif mesurable, et non à une intuition ou un “ça pourrait être sympa”. 

Moins mais mieux, voilà l’essence de l’éco‑conception produit. 

Réalisez vos impacts mapping en ligne sur l’excellent outil Atelier collaboratif :

En savoir plus

23 janvier

Au-delà des a priori : Exemple d’une discovery Produit pour le Secours Populaire Français

Le constat de départ est vertigineux : aujourd’hui, les responsables de structure du Secours Populaire 44 consacrent jusqu’à 80 % de leur temps à des tâches administratives.

80 %. C’est autant de temps perdu qui pourrait être investi là où l’impact est réel : auprès des personnes en difficulté.

Face à cette urgence, comment aider sans passer à côté du plus important ? En s’assurant de ne pas être à côté de la plaque ?

Plutôt que de foncer tête baissée dans le code, Céline Bouché, coach Agile et Product Owner chez Conserto a choisi une autre voie : la discovery Produit.

Dans cet instant tech’, découvrez comment l’écoute des utilisateurs et la compréhension de leurs frustrations ont permis de concevoir des solutions qui changent vraiment le quotidien des bénévoles.

View video

Au travers de cet exemple concret, vous retrouverez comment :

• Mener une exploration efficace pour identifier les vrais besoins (et pas ceux qu’on imagine).
• Maîtriser les bons outils pour analyser vos découvertes terrain.
• Aligner toute votre équipe pour prendre les bonnes décisions et bâtir une solution utile, adoptée et durable.

26 janvier

La Matrice d’Impact : prioriser avec conscience 

La Matrice d’Impact est l’un des outils les plus essentiels pour tout PO/PM soucieux d’allier performance et sobriété. 

Elle croise traditionnellement impact métier et effort, mais sa formation introduit un troisième axe fondamental : l’empreinte environnementale. 

1. Un outil visuel, simple et redoutablement efficace 

La matrice invite l’équipe à classer les fonctionnalités selon deux paramètres : 

• l’impact métier, c’est‑à‑dire la valeur produite, 

• l’effort, en temps, en complexité technique, en risques. 

L’ajout de la dimension environnementale rend l’outil encore plus puissant : certaines fonctionnalités deviennent soudainement absurdes au regard du coût écologique qu’elles supposent. 

2. Le cœur du service vs la zone de renoncement 

La matrice identifie clairement : 

• le cœur du service : ce qui doit absolument exister, 

• ce qui peut être challengé ou simplifié, 

• la zone de renoncement : ce qui mérite d’être abandonné. 

Cette dernière zone est un espace souvent tabou dans les organisations. Pourtant, l’écoconception nous rappelle que le produit le plus responsable est parfois celui qui ne sera pas construit. 

3. La matrice d’impact, outil éthique du PM moderne 

Travailler en PM/PO en 2026, c’est accepter d’être arbitre entre valeur métier et durabilité. 

La matrice d’impact donne un cadre pour assumer ces choix, et les rendre visibles, compréhensibles et légitimes. 

Télécharger la fiche pratique

27 janvier

L’impact poker : aligner l’équipe sur la valeur et l’empreinte

L’Impact Poker est une méthode d’évaluation collective qui permet à l’équipe de “jouer” les impacts d’une fonctionnalité. Mais sous son apparence ludique, il s’agit d’un outil structurant pour instaurer une culture produit responsable. 

1. Un rituel collaboratif et fédérateur 

Chaque membre de l’équipe vote simultanément sur les impacts d’une User Story : 

• valeur, 

• risque, 

• faisabilité, 

• impact utilisateur, 

• impact environnemental. 

Les écarts de vote deviennent la matière première d’une discussion précieuse. 

2. Un outil pour démocratiser l’écoconception 

Grâce à ce jeu, l’impact environnemental n’est plus une spécialité d’experts : il devient un sujet normal, partagé, débattu. 

Il permet : 

• d’ouvrir les yeux sur la lourdeur potentielle d’une fonctionnalité, 

• d’éviter que l’impact environnemental soit oublié dans les arbitrages, 

• d’améliorer la qualité des décisions collectives. 

3. Des équipes alignées prennent de meilleures décisions 

En quelques minutes, l’équipe aligne sa compréhension de la valeur et de l’impact écologique. 

C’est une manière simple et efficace de changer la culture produit : si tout le monde en parle, tout le monde y contribue. 

Plus d’infos

28 janvier

L’Experience Map éco‑conçue : comprendre l’utilisateur… et ses impacts

L’Experience Map est un grand classique de l’UX. Mais dans ta formation, elle devient un outil clé d’écoconception : elle ne cartographie pas seulement l’expérience, mais aussi l’empreinte environnementale du parcours utilisateur. 

1. Rendre visible ce qui ne l’est pas 

L’Experience Map version numérique responsable inclut : 

• le terminal utilisé, 

• la qualité réseau, 

• les étapes longues ou intensives, 

• la charge technique implicite. 

Chaque étape est une “consommation” : temps d’écran, requêtes, chargements, données envoyées. 

Et ce qui consomme… peut souvent être réduit. 

2. Un révélateur des leviers de sobriété 

Grâce à la map, l’équipe peut se poser les bonnes questions : 

• le parcours est‑il trop long ? 
• certaines étapes sont‑elles inutiles ? 
• peut‑on charger moins de contenu ? 
• peut‑on éviter un retour serveur ? 
• une page pourrait‑elle être allégée ? 

Souvent, améliorer l’UX revient à réduire l’impact, ce qui crée un alignement rare entre priorité métier et sobriété. 

3. Un outil puissant pour aligner équipe, métiers et direction 

• d’expliquer l’importance d’un design sobre, 

Parce qu’elle est très visuelle, l’Experience Map permet aussi : 

• de convaincre que certaines optimisations ont un vrai sens, 

• d’ancrer l’écoconception dans la stratégie produit. 

Pour allez plus loin, découvrez l’outil grâce au travail d’Antoine Pezé :

Découvrir l’outil

29 janvier

GreenTrackr : mesurer pour mieux décider

Impossible de piloter sans mesurer. 

GreenTrackr, issu de notre “lab” et basé sur les travaux de la communauté Boavizta, répond exactement à ce besoin : donner une mesure fiable et actionnable de l’impact environnemental d’un service numérique. 

1. Rendre l’invisible visible 

GreenTrackr permet une évaluation multi-critères ce qui est crucial : l’écoconception ne se limite pas au CO₂. 

2. Passer d’un indicateur marketing à un outil d’aide à la décision 

La force de GreenTrackr est de pouvoir être utilisé par : 

• les designers, 

• les développeurs, 

• les PM/PO, 

• les architectes. 

L’outil ne se contente pas de “noter” : il permet de comparer, d’améliorer et de suivre dans le temps. 

À partir de ces données, l’équipe peut instaurer un budget environnemental dans sa Definition of Done ou en COPIL. 

3. Une nouvelle métrique pour piloter la roadmap 

GreenTrackr fait entrer l’écoconception dans la gouvernance produit. 

Il permet d’imaginer de nouveaux arbitrages : 

• réduire un parcours, 

• supprimer une image, 

• choisir un format différent, 

• différer un traitement côté serveur, 

• éliminer une fonctionnalité non utilisée. 

Mesurer change tout : on ne pilote bien que ce que l’on mesure. 

Pour plus d’infos, découvrez notre outil gratuit et open source :  

Estimer l’empreinte environnementale, un pré-requis à toute démarche d’éco-conception

30 janvier

The post Le Calendrier de l’après 2026 appeared first on Conserto.

Explorer l’hybridation entre chefferie de projet traditionnelle et agilité

Pendant 10 semaines, Conserto donne la parole à des experts et praticiens du pilotage projet pour partager leurs expériences de terrain.
Objectif : comprendre comment hybrider les méthodes traditionnelles et agiles, sans dogme ni théorie — juste du concret, du vécu et des bonnes pratiques.

📅 Du 7 octobre au 16 décembre 2025 tous les mardis à 12h15*

(*sauf le 4 novembre, la conférence de Marc Dugué ayant été décalée à 13h)

🎥 En direct sur notre chaîne YouTube, puis disponible en replay sur cette page.

Recevez une alerte 15 minutes avant chaque conférence.

*promis, vous ne recevrez rien de plus !

Découvrez les liens des lives & replays des conférences

The post Les Conf’Hybrides : 10 conférences en ligne – 10 regards croisés appeared first on Conserto.

Introduction

Travailler efficacement en équipe exige de prendre en compte les forces et les faiblesses de chacun. À commencer par les siennes. En pratique, être capable de reconnaître lorsque l’on a besoin d’aide et savoir l’exprimer clairement, sans détour.

Mais dans les faits, demander de l’aide dans un groupe n’est pas toujours si simple. En effet, cela convoque un certain nombre de biais de comportement tels que :

• Je n’ose pas déranger

• J’ai peur de renvoyer une image d’incompétence

• Je suis un peu trop optimiste ou j’ai un peu sous-évalué la difficulté de la tâche

• Je n’ai pas clairement exprimé mon besoin, la demande est mal formulée et, du coup, elle n’est pas audible/compréhensible

Dans cet article, nous allons vous décrire un outil de communication très utile pour simplifier et rendre efficace chaque demande d’aide exprimée par n’importe quel membre de votre équipe.

Les pièges à éviter

Avez-vous déjà vécu les situations suivantes :

1. Un membre de l’équipe qui est visiblement en difficulté, met le groupe dans une situation problématique en refusant l’aide qu’on lui propose. C’est le cas où une personne affirme, chaque jour, depuis un certain temps, qu’elle aura fini demain. Et pendant ce temps, le reste du groupe ne voit rien sortir.
2. Ou bien vous avez pourtant sollicité de l’aide mais sans aucune réponse de la part de vos collègues.

Dans la situation 1, ce qui m’empêche de demander de l’aide, c’est probablement des biais comportementaux tels que :

• Le biais « des coûts irrécupérables » j’ai déjà tellement investi d’effort que je m’acharne sur une approche infructueuse car repartir de zéro impliquerait de « perdre » l’effort que j’ai déjà investi sur cette tâche.
• Le biais « sur-confiance / sur-classement » qui me fait surestimer mes capacités ou sous-estimer la taille du reste-à-faire.

Ou encore peut-être un certain manque de sécurité psychologique qui me freine pour exprimer une forme de vulnérabilité dans cette équipe, à ce moment-là.

Dans la situation 2, pour une équipe qui travaille en mode collaboratif, un appel à l’aide ignoré est probablement le signe d’une demande mal formulée. Cela peut être pour différentes raisons :

• Ce n’est pas le bon moment
• Ce n’est pas le bon canal
• La demande est trop vague et elle ne permet pas de comprendre quel est le besoin exprimé, voire elle n’est même pas interprétée comme une demande d’aide.
• La demande n’est pas nominative et personne ne se sent concerné.

A partir de ce constat, qu’est-il possible de faire ?

Un protocole simple mais puissant : “Ask For Help”

Voici un outil qui peut vous aider. Le protocole “Ask For Help” qui est un modèle-guide pour bien formuler sa demande d’aide.

Cet outil de communication est issu de la boîte à outils les Core Protocols qui regroupe 11 engagements et 11 protocoles pour interagir efficacement en équipe.

C’est un package qui contient des outils de communication très simples qui sont des guides pour sortir de nos mauvais réflexes d’interaction, issus de notre éducation et de nos expériences passées. Ils visent à améliorer la collaboration en équipe.

Comment ça marche ? Voici le guide à respecter :

1) Formuler une demande claire :

• Quelle est la demande : ce que j’attends des autres

• Pour quelle finalité : j’explique ce que je cherche à atteindre comme objectif (cela peut aider les autres à me proposer une solution alternative)

• Quelle est l’action concrète attendue

• Quelles sont les contraintes possibles éventuelles (durée, moment, matériel, …)

2) L’Exprimer nominativement à la personne qui peut potentiellement t’aider

3) Attention, c’est une demande, pas une exigence : l’aidant potentiel est libre de refuser ou de proposer une aide alternative

A quoi ressemble une demande d’aide efficace, en suivant ce guide « Ask For Help » :

Pouvez-vous m’aider à réaménager la salle ? [DEMANDE]
Nous allons avoir besoin de cet espace pour dérouler notre atelier de tout à l’heure. [FINALITÉ]
Pour ça, il faudrait retirer et empiler toutes les tables au fond de la salle et faire un grand cercle avec les chaises. [AIDE CONCRÈTE]
À deux, ça pourrait prendre 5 minutes. [CONTRAINTE]
Est-ce possible pour vous ?

💡Astuce : Une autre pratique qui peut paraitre étonnante consiste à demander de l’aide à des personnes non expertes de votre sujet ! 

Pourquoi ? Paradoxalement, ce sont ces personnes là qui vous aideront le mieux à prendre du recul sur votre situation grâce à leurs questions naïves. D’ailleurs, rien qu’en formulant votre problématique de manière à ce qu’ils la comprennent, il est possible que vous découvriez vous-même une solution ! (effet canard en plastique)

Conclusion

Utiliser un protocole guide l’équipe, en rendant les choses explicites on évite les malentendus. Ici on entre dans une interaction codifiée qui a été établie comme règle de l’équipe ce qui peut éviter certains mauvais réflexes et certains biais d’une communication instinctive.

C’est utile car :

• ça permet au demandeur de gagner du temps en utilisant au mieux les talents de chacun
• ça donne un canevas simple pour formuler des demandes claires et efficaces
• ça permet de décomplexer la demande d’aide et d’obtenir l’accord entier des aidants

⚠️ Attention : ça reste une demande (ce n’est pas une exigence et chacun reste libre de refuser de donner de l’aide sans que ce soit une attaque personnelle. Bien sûr, il est toujours possible de proposer une solution alternative.

Nous t’invitons à l’essayer dans ton équipe et à nous partager ce que ça aura donné pour toi.

En savoir plus

• Notre dossier sur les Core Protocols
• Une série d’articles à propos des Core Protocols sur le blog de Maxence Walbrou
  Un article dédié avec retour d’expérience
• Le site d’origine des MacCarthy : https://mccarthyshow.com/the-core/

The post Demander de l’aide efficacement appeared first on Conserto.

PHPStorm est un IDE de référence pour les développeurs PHP, offrant une multitude de fonctionnalités qui améliorent la productivité et la qualité du code.

Dans cet article, je vous propose un tour d’horizon de 15 fonctionnalités qui m’ont particulièrement marqué et qui, je l’espère, sauront vous être utiles au quotidien. Pour chaque fonctionnalité, vous trouverez des liens vers la documentation officielle pour approfondir vos connaissances.

Un article de Quentin Métivier et de la communauté Symfony de Conserto.

🟢 Fonctionnalités de Base

✅ Gestion du Versionning

🔍 Visibilité des stash

PHPStorm affiche tous les stash enregistrés, permettant de les appliquer, supprimer ou comparer en un clic, sans passer par la ligne de commande.

🔀 Meilleure Gestion des Commits

L’IDE offre un aperçu visuel des modifications, permet les partial commits, et intègre des validations automatiques avant commit (linting, tests…).

⚡ Gestion Avancée des Conflits

Un éditeur interactif facilite la résolution des conflits Git avec une visualisation claire des modifications à conserver.

✅ Services et Conteneurs

🔍 Vue complète des conteneurs, images et volumes

PHPStorm affiche tous les conteneurs en cours d’exécution, leurs ports, ainsi que les images et volumes stockés.
Il offre la possibilité de gérer ces ressources sans passer par la ligne de commande, simplifiant leur utilisation.

🔀 Accès direct au terminal d’un conteneur

Un terminal intégré permet d’exécuter des commandes directement dans un conteneur sans docker exec.
Utile pour tester, déboguer et inspecter un environnement sans quitter l’IDE.

✅ Base de Données

🔍 Vue des bases et tables par projet

L’IDE affiche une arborescence claire des bases de données connectées, avec leurs tables et schémas.
Grâce à cette vue, on peut explorer la structure rapidement, sans passer par un client externe.

🔎 Filtrage des données

Un système de filtrage simple pour afficher uniquement les lignes correspondant à certains critères.
Idéal pour parcourir rapidement une table et identifier les données pertinentes.

💻 Console pour requêtes SQL avancées

PHPStorm intègre une console SQL avec autocomplétion et surlignage syntaxique.
Cela permet d’exécuter des requêtes complexes directement dans l’IDE et d’en voir les résultats instantanément.

✅ Debugging Amélioré (avec Xdebug)

🎯 Ajout de points d’arrêt

Possibilité de placer des points d’arrêt pour stopper l’exécution et inspecter l’état du programme.
On peut ainsi analyser le fonctionnement du code sans avoir à modifier les fichiers avec des var_dump().

🔍 Visualisation de la stack trace

Affichage détaillé de la pile d’appels pour comprendre le chemin d’exécution du programme.
Cela aide à identifier rapidement l’origine d’un bug et les fonctions impliquées.

✨ Évaluations d’expressions en direct

Exécution de morceaux de code pendant le débogage pour tester des valeurs et conditions.
Utile pour vérifier l’état des variables sans relancer l’application.

⚙️ Éditeur de points d’arrêt personnalisés

Définition de points d’arrêt conditionnels pour s’arrêter uniquement dans certains cas spécifiques.
Possibilité d’ajouter des logs ou de modifier le comportement sans toucher au code source.

✅ Structure du Code

🔍 Navigation simplifiée et meilleure lisibilité

PHPStorm permet une navigation facile dans le code grâce à sa vue Structure, qui affiche l’organisation des classes, méthodes et autres éléments du projet.

Vous pouvez rapidement accéder aux sections du code et utiliser des raccourcis pour sauter directement à la définition de classes ou de fonctions.

🟡 Fonctionnalités Intermédiaires

🔹 Merge Request

🔍 Relecture de MR directement dans l’IDE

On peut relire les Merge Requests directement dans l’IDE, en affichant les différences entre les branches et les modifications. Cela facilite la gestion des révisions sans avoir à quitter l’environnement de développement.

🔎 Suivi des étapes CI/CD

PHPStorm offre une intégration avec les outils CI/CD, permettant de suivre l’état des pipelines de déploiement directement dans l’IDE. Vous pouvez ainsi voir si les tests passent ou échouent sans avoir à consulter un outil externe.

🔹 Gestion des Tasks

🔧 Normalisation des commits

Grâce aux tasks, vous pouvez automatiser les noms des commits selon une nomenclature propre au projet, ce qui réduit les erreurs sur ces noms et améliore leur lisibilité pour les personnes au sein du projet.

📂 Ouverture/fermeture automatique des fichiers liés à une tâche

L’IDE peut automatiquement ouvrir ou fermer les fichiers associés à une tâche spécifique, ce qui améliore l’organisation du travail et permet de se concentrer sur les fichiers pertinents pour chaque tâche en cours.

🔹 Refactorisation

🔧 Refactor

Lors d’un clic droit sur le code, PHPStorm propose un menu de refactorisation permettant de renommer des variables, extraire des méthodes, ou encore réorganiser le code facilement. Ces outils aident à restructurer le code rapidement tout en minimisant les erreurs, garantissant un code plus propre et plus maintenable.

🔹 Génération de Code

⚙️ Generate…

L’IDE offre la possibilité d’automatiser la création de code pour des tâches répétitives, comme la génération de getters, setters, ou de constructeurs. Cela permet de gagner du temps et de réduire les erreurs humaines en générant du code standardisé rapidement.

🔹 Diagrammes

📊 Vue de la base de donnée

PHPStorm offre des outils de visualisation pour les bases de données, permettant de générer des diagrammes des structures de tables et des relations entre elles. Cela aide à mieux comprendre la conception de la base de données et facilite la gestion de son architecture.

🔹 Services Docker

🐳 Lecture seule de l’arborescence des fichiers

On peut accéder aux fichiers des différents conteneurs Docker, en lecture seule. Cela vous permettra de naviguer sereinement au sein de ceux-ci sans risquer une modification. De plus, vous pouvez décider d’ouvrir les fichiers et d’en créer une copie en local dans les fichiers scratch du projet.

🔴 Fonctionnalités Avancées

🚀 Diagramme de Classe

📐 Comme pour la base de données, mais pour les classes

PHPStorm génère des diagrammes de classes pour offrir une vue d’ensemble claire de l’architecture logicielle. Grâce à cela, on peut visualiser les relations entre les différentes classes et d’améliorer la compréhension du design du code.

🚀 Explain Plan

📊 Une version plus visuelle et ergonomique

PHPStorm propose une analyse SQL avancée avec la fonctionnalité Explain Plan, permettant d’examiner le plan d’exécution des requêtes. Cela aide à optimiser les performances en identifiant les éventuels goulets d’étranglement dans les requêtes SQL. Similaire à celle déjà proposée par PostgreSQL, un des avantages notables est le fait de pouvoir déplier/replier les différentes sous parties du explain, ce qui augmente grandement la lisibilité lors de l’analyse de requêtes très complexes.

🚀 Exportation de Configuration

⚙️ Pour une configuration uniforme

PHPStorm permet de créer et d’exporter des configurations types pour un projet, facilitant ainsi la réutilisation des paramètres de l’environnement de développement. Cela permet de standardiser les configurations entre différents projets ou membres d’une équipe.

🛠️ Plugins Externes

🔥 SonarQube for IDE

🔍 Vérification des bonnes pratiques

PHPStorm intègre SonarQube pour analyser le code et détecter les violations des bonnes pratiques de développement. Cela permet de maintenir un code propre et conforme aux normes de qualité définies.

🔒 Contrôle pré-commit

Avant chaque commit, SonarQube vérifie le code pour s’assurer qu’il respecte les règles de qualité. Cela aide à éviter l’introduction de bugs ou de mauvaises pratiques dans le projet.

🔗 Intégration avec un serveur SonarQube

PHPStorm permet une intégration fluide avec un serveur SonarQube, centralisant les analyses et les rapports de qualité du code. Cela offre une visibilité complète sur la qualité du code à travers différents projets et équipes.

Beaucoup d’autres fonctionnalités sont disponibles, n’hésitez pas à parcourir la documentation afin de sûrement mettre la main sur une fonctionnalité qui vous était inconnue et qui augmentera votre confort au quotidien :

https://www.jetbrains.com/help/phpstorm/quick-start-guide-phpstorm.html

The post 15 Fonctionnalités de PHPStorm : un IDE surpuissant pour Développeurs PHP appeared first on Conserto.

Série d’articles “La Rétrospective Agile : une pratique essentielle, pas toujours bien comprise”

Episode n°3 : Aller plus loin

Précédemment :
– Episode n°1 : Evolution de ma pratique
– Episode n°2 : Eviter les chausse-trappes

William Bartlett, dans son article “Où je me suis trompé sur l’agilité : la rétrospective“, s’interroge sur la pertinence de cette pratique et sur ses limites.

« Personnellement, ça fait deux ans que je considère que c’est la pratique agile qui apporte le plus de gaspillage. Si vous avez une expérience plus positive et que vos rétrospectives vous réussissent, tant mieux. Je serais intéressé d’échanger avec vous. »

— William Bartlett

Cette prise de position peut surprendre… mais elle résonne avec certaines observations que j’ai pu faire moi aussi.

Pendant longtemps, j’ai vu les rétrospectives comme un moment précieux, porteur de sens et d’amélioration continue. Je continue à penser qu’elles peuvent être extrêmement utiles, mais pas à n’importe quelles conditions.

Avec le temps, l’expérience et de nombreux échanges avec d’autres praticiens, ma façon d’animer et de concevoir les rétrospectives a profondément évolué. Cette série d’articles est l’occasion pour moi de revenir sur ce cheminement : ce que j’ai appris, ce que j’ai ajusté, ce que j’ai parfois laissé de côté, et surtout pourquoi.

Dans ce troisième et dernier épisode, je vous propose de voir des pratiques qui peuvent nous aider dans des situations complexes.
Nous verrons le rôle délicat de l’Agile Master qui a la mission de guider l’équipe… tout en faisant partie ! Des pratiques pour prendre soin des relations dans l’équipe puis de pistes pour s’organiser lorsque l’on est nombreux.

Sommaire

1. Le rôle délicat de l’Agile Master : guider sans imposer
   • Créer un climat de confiance
   • Vers une équipe autonome et responsable
   • Rester à l’écoute de ce qui se fait ailleurs
   • Impliquer les membres de l’équipe
   • Sonder l’équipe sur sa propre attitude d’agile master
   • Utiliser la facilitation croisée
   • Inspecter notre processus d’amélioration continue
2. Utiliser le temps de la rétro pour prendre soin de l’équipe
   • Améliorer la qualité de nos relations
   • Expérimenter des pratiques pour les temps collectifs
   • Eviter l’accumulation de la dette émotionnelle
3. Rétrospective à l’échelle
   • Quelles modalités pour des actions concertées ?
   • Quels participants inviter ?
   • Des leaders et des managers impliqués
4. Ressources et références
   • Livres
   • Articles
   • Vidéos
   • Jeux sérieux et ateliers

1. Le rôle délicat de l’Agile Master : guider sans imposer 

🔎 Vocabulaire : Agile Master = personne (souvent membre de l’équipe) qui aide l’équipe à s’auto-organiser de manière agile. Par exemple : Le rôle de “Scrum Master” dans Scrum, Le rôle de “Coach” dans XP, …

En tant qu’agile master, je suis de fait, en position de leadership (par mon expérience, par le rôle qu’on m’a donné, …). Si c’est moi l’animateur de l’atelier et que je contribue aussi au sujet en tant que participant je peux vite prendre de la place. Ce n’est pas toujours évident car, sur certains sujets, en vérité je fais peut-être partie du problème… Est-ce que le reste l’équipe est à l’aise pour parler de ça avec moi ? 

Au début de ma pratique, je croyais avec naïveté que, vu qu’il y avait la rétrospective à intervalles réguliers, nous aurions la capacité de détecter tous les points de blocages, sans non-dits. Spoiler alert : ce n’est pas comme ça que ça marche ! 

En tant qu’agile master, j’ai pour mission d’aider l’équipe à mettre en place un processus d’amélioration continue qui fonctionne et à prendre du recul et de la hauteur sur ses pratiques. 

1.1 Créer un climat de confiance

En premier, il faut réussir à créer un climat de confiance pour que chacun puisse s’exprimer sans crainte. En clair, il faut créer les conditions pour établir un niveau minimum de sécurité psychologique. Sur ce sujet j’ai beaucoup apprécié l’excellent atelier de Maylis Cohen et Benjamin Couet « Pas de performance sans sécurité psychologique ». 

Quand j’arrive dans une équipe où je sens un petit déficit à ce niveau-là, je commence par des interviews individuels puis, je partage les éléments collectés sous forme d’une synthèse anonyme qui est le point de départ des futurs échanges. 

En cas de doute, je commence par une activité ESVP (Explorateur, Acheteur, Vacancier, Prisonnier) pour vérifier l’état d’esprit des participants. Cette activité invite les participants à indiquer leur état d’esprit en arrivant à ce RDV de manière anonyme.

1.2 Vers une équipe automne et responsable

Pour une équipe qui débute, il y a souvent plein de difficultés identifiées. Au niveau des actions, la tentation peut être grande de rejeter la faute sur les autres et d’imaginer des actions en dehors du cercle d’influence de l’équipe sur lesquelles l’équipe n’a pas ou peu de prise. « C’est les autres qui doivent changer ». 

Exemple : Pour nous débloquer, l’équipe plateforme doit améliorer son processus de réception des demandes. 

Voici 2 modèles que j’ai utilisé, avec succès, pour aider des équipes à faire la part des choses : 

• Le processus de responsabilité de Christopher Avery 

• Les cercles d’influence décrits par Stephen Covey dans son livre ”The 7 Habits of Highly Effective People” 

1.3 Rester à l’écoute de ce qui se fait ailleurs 

L’équipe ne doit pas tourner en circuit fermé. De temps en temps, il peut être bon s’ouvrir au monde et de se confronter à des référentiels externes. 

Voici des choses qui ont marché pour moi : 

• Les cartes Agile Smells Bad 
• Les cartes Squad Health Check 
• Les cartes Maturité Produit par Thiga
• Le modèle Agile Fluency 

Sur le modèle des cartes Squad Health Check, j’ai créé en 2024, des cartes pour inspecter les pratiques de tests de l’équipe. 

1.4 Impliquer les membres de l’équipe

Plus les membres de l’équipe seront impliqués dans la préparation et l’animation de cet évènement et plus ce sera un temps collectif et non pas juste le sujet de l’Agile Master. 

Une très bonne pratique est de décider que chaque membre de l’équipe anime la rétro à tour de rôle. Ce qui a plusieurs vertus : la compétence de facilitation se diffuse dans l’équipe (ce qui sera utile pour d’autres temps collectifs), les participants sont plus respectueux de l’animateur par empathie. 

Bon au début, ça peut faire peur à certains. Il n’y aura peut-être pas beaucoup de volontaires. Dans ce cas je commence par demander de l’aide : « J’ai besoin d’aide pour préparer la prochaine rétro qui aurait 1h à m’accorder ». L’idée c’est de faire avec puis progressivement laisser faire. 

Et si vraiment ça n’accroche pas, il est toujours possible, à minima, de mettre en place une boîte à idées pour collecter le thème ou les points clés à aborder la prochaine fois.

1.5 Sonder l’équipe sur sa propre attitude d’agile master

Il est important pour l’agile master d’aller chercher du feedback sur sa posture et ses pratiques. Les discussions en rétrospective ne suffiront probablement pas pour obtenir une vue complète et honnête de ce que pense chaque membre de l’équipe. 

Un sondage anonyme et/ou des entretiens individuels peuvent être utiles pour obtenir ce feedback plus complet, suivant le niveau de sécurité psychologique et la proximité relationnelle entre l’agile master et les autres membres de l’équipe. 

Pour le sondage anonyme, voici les questions que je pose, en général : 

• Quel est ton niveau de satisfaction par rapport à ma manière d’incarner le rôle d’agile master dans l’équipe (évaluation entre 1 et 5) ? 
• Qu’est-ce que tu apprécies dans mon attitude ou mes actions ? 
• Y a-t-il des choses que je fais et que je ne devrais pas ? 
• Y a-t-il des choses que je ne fais pas et que je devrais ? 
• As-tu d’autres choses à me dire ou un conseil à me donner ? 

Pour les entretiens individuels, cela doit rester une invitation pas une obligation. J’observe une durée de 45 min en moyenne. Il est bon d’arriver avec une trame d’entretien préparée à l’avance. Exemple : la trame proposée par Jean-Christophe Pages. 

1.6 Utiliser la facilitation croisée

Un autre moyen pour éviter la position ambiguë de l’agile master, à la fois animateur de la rétro et membre de l’équipe est de faire appel à un facilitateur externe à l’équipe. 

Dans un contexte de travail, il y a souvent plusieurs équipes agiles en proximité. Il peut être bon de croiser la facilitation des rétros où chaque agile mater va faciliter la rétro d’une autre équipe. Dans ce cas les 2 agiles masters ont besoin d’un temps de préparation ensemble. 

Ainsi l’agile master se retrouve comme simple participant au même titre que les autres membres de l’équipe. Cela permet aussi aux différents agiles master d’élargir leurs pratiques ainsi que la compréhension du contexte dans lequel ils évoluent. 

1.7 Inspecter notre processus d’amélioration continue

A intervalles réguliers (du genre 6 mois / 1 an), il est bon de proposer à l’équipe d’inspecter son processus d’amélioration continue. Est-ce que cela fonctionne pour nous ? Est-ce que tout le monde est à l’aise avec les pratiques en place ? 

Il y a deux exercices que j’aime bien pour ça : 

• La rétrospective de la rétrospective : pour répondre à question suivante : doit-on faire évoluer notre pratique ? (une fois par an ça peut être bien) 
• La rétrospective de l’année comme bilan d’une année qui termine ou comme lancement d’une nouvelle année qui commence. Bien sûr, dans ce cas, il y aura certainement des biais mnésiques, dus à la longueur de la période inspectée, mais compensés par le plus ample détachement que nous aurons face aux évènements passés 

2. Utiliser le temps de la rétro pour prendre soin de l’équipe

Nous ne sommes pas obligés de faire de la rétrospective un atelier de type remue-méninge/plan d’action. Il est aussi efficace d’utiliser ce temps directement comme un temps de travail et d’expérimentation. 

2.1 Améliorer la qualité de nos relations

Prendre soin de l’équipe, c’est-à-dire travailler sur la qualité de nos relations et augmenter le plaisir que nous avons à travailler ensemble. Ce peut se faire à l’aide d’ateliers permettant des échanges riches sur les motivations, les préférences et les forces de chacun des membres de l’équipe. 

Voici 4 ateliers qui ont bien fonctionnés pour moi, à plusieurs reprises, dans différents contextes : 

• Le cartes Moving Motivators issues du Management 3.0 et qui sont dérivées des publications de Daniel Pink, Steven Reiss, et Deci/Ryan.
• Le jeu Totem un jeu de cartes qui fait du bien pour découvrir, en s’amusant, nos forces et qualités à travers le regard des autres.
• Les 4 quadrants DISC.❗Attention pas pour mettre les gens dans des cases, mais comme un prétexte pour démarrer une discussion sur les préférences de chacun et pour une prise de conscience que ce n’est pas forcément les mêmes pour tout le monde.
• Les 50 cartes forces issues de la psychologie positive et éditées par Positran.

La participation à ce type d’atelier se fait sur invitation et chacun doit rester libre de refuser de participer.

2.2 Expérimenter des pratiques pour les temps collectifs

La rétrospective peut aussi être, directement, un temps d’expérimentation. 

C’est le bon moment pour tester, en séance, des pratiques utiles pour la vie de l’équipe que l’on peut réutiliser pour d’autres moments de travail collectif. 

Voici des pratiques que j’aime bien proposer à l’équipe : 

• Attribution de Rôles délégués, décrits par Alain Cardon, afin de distribuer l’effort (et les compétences) d’animation sur les participants. 
• The Meeting Spicer un jeu de cartes avec des actions très courtes (quelques minutes) pour améliorer la qualité des réunions  
• Attribution de la parole par l’animateur (pour éviter les interruptions et la monopolisation de la parole)
• Reformulation systématique des propositions. La qualité de l’écoute n’est pas la même si on est susceptible d’être interrogé par l’animateur pour reformuler ce qui vient d’être dit.
• Décision par consentement mutuel afin d’avoir une décision véritablement collective dans un temps raisonnable. Il existe plein de méthodes de prise de décision la rétro peut être le lieu où l’on expérimente des nouvelles façons de faire.

2.3 Eviter l’accumulation de la dette émotionnelle

De mon expérience, dans la plupart des équipes, les pratiques d’amélioration (qui ne se limitent pas à la rétro) concernent surtout les sujets techniques et les processus et beaucoup moins les relations humaines. Et pourtant l’ambiance de travail est en majeure partie le fruit de l’état du réseau relationnel entre les membres de l’équipe. 

La dette émotionnelle, telle que définie par Marilyn Kol, c’est l’accumulation des problèmes relationnels non résolus. A l’image de la dette technique pour le code, le non-traitement de cette dette peut conduire à des situations de blocages (des personnes ne pouvant plus travailler ensemble) voir à l’éclatement de l’équipe. 

Il est salutaire pour une équipe de mettre en place de mécanismes permettant de désamorcer les nœuds relationnels dès leur apparition avant que leur accumulation conduise à une situation inextricable. 

Un bon moyen est d’introduire dans l’équipe une culture du feedback respectueux. Ceci afin que les membres de l’équipe soient autonomes dans la clarification de leurs interactions. Au début, certains membres peuvent ne pas être à l’aise avec la formulation ou la réception de feedbacks invitants à changer d’attitude ou de façon de faire.. 

Pour cela, j’aime bien commencer par introduire uniquement les feedbacks positifs, c’est sans danger et ça améliore l’ambiance naturellement. La rétrospective est le bon endroit pour introduire ce type de pratique. 

Voici 4 pratiques que j’ai expérimenté, avec succès, pour garder la dette émotionnelle sous contrôle et améliorer la qualité des relations et l’ambiance de travail :

2.3.1 – Le tour des mercis

Pour commencer la rétro sur une touche positive j’invite chaque participant à écrire des remerciements pour le reste de l’équipe. Il y juste 2 règles :  

• Les mercis sont individuels et spécifiques 
• Il faut en écrire au moins 1 (pas de maximum) 

C’est une pratique complémentaire aux Kudo Cards (cf. épisode n°2 § 2. Limiter les biais individuel et collectifs).

2.3.2 – Le cercle restauratif

Une fois les équipiers à l’aise avec la pratique des feedbacks positif il est temps d’introduire la pratique de feedbacks correctifs dans un cadre sécurisé. 

Pour cet exercice, je demande à chaque équipier d’apporter un objet qui lui est personnel. 

Tout le monde se met en cercle. Tous ceux qui sont émotionnellement disponible pour recevoir un feedback posent l’objet qui les représentent à leurs pieds. A partir de ce moment-là, chacun est libre d’aller se mettre face à un autre membre de l’équipe et de lui faire son feedback. 

• La personne ramasse l’objet et le donne à celui qui reçoit qui dit merci. 
• Le feedback peut être soit juste positif soit un feedback positif suivi d’un feedback correctif. 
• Le feedback n’invite pas à une réaction ni à une justification. Celui ou celle qui reçoit est libre de le prendre en compte ou pas.
• Certains feedbacks peuvent être difficiles à recevoir et générer de l’émotion. Celui ou celle qui reçoit garde son objet en main jusqu’à être à nouveau disponible pour recevoir de nouveau. 

Exemple de feedback : 

• Lorsque tu fais ceci … j’aime beaucoup et je te remercie pour ça. 
• Lorsque tu fais cela … c’est plus difficile pour moi. A la place, je préfèrerais… (optionnel) 

La pratique de cet exercice, à intervalle régulier, nous a permis d’évacuer une partie de la dette émotionnelle et a fait beaucoup de bien à l’équipe. Cela nous a surtout permis d’éviter que certaines relations se dégradent au-delà de ce qui est le minimum requis pour travailler ensemble. 

Pour une équipe souhaitant améliorer sa pratique du feedback, il existe un jeu de cartes excellent, publié par Good!, pour s’entrainer : Feedback en milieu sauvage. Ce jeu a été co-créé par Gégory ALEXANDRE, Maria TENARD et Isabelle GAUTHIER.

2.3.3 – Le rôle de médiateur tournant

Dans une équipe, nous avons testé, avec succès, le rôle de médiateur. 

En effet, parfois la qualité de la relation que j’ai avec mon/ma collègue ne permet pas d’aborder sereinement certains sujets. La présence d’un tier de confiance pour les 2 partis peut nous permettre de dépasser cette situation inconfortable. 

Avoir un rôle de médiateur/médiatrice dont les compétences et les qualités relationnelles sont reconnues par l’équipe peut faciliter le choix de cette tierce personne. 

Le rôle mis en place (suite à une rétro) avait les caractéristiques suivantes : 

• Un rôle tournant (sur une période de 6 mois / 1 an) 
• Mandat : La personne se tient disponible pour faciliter la communication entre 2 personnes sur demander OU peut proposer son aide (sans l’imposer) si elle observe une situation qui le mérite. Ce rôle n’est pas exclusif. 
• Nomination en suivant le principe élection sans candidats (c’est un principe que s’appuie sur la décision par consentement mutuel (cf. épisode n°1 § 1. Des espaces d’expérimentation de collaboration) 

2.3.4 – La rétro du bonheur

J’ai découvert par la pratique le format La rétro du bonheur lors de la conférence Agile Games France à Lille en 2017. C’est un format assez puissant basé sur 3 questions très simples. 

De quoi avez-vous envie : pour vous-même, pour le monde, pour l’équipe ? 

Les 2 premières questions ne sont pas là pour trouver des actions d’amélioration mais pour nous inviter à partager ce qui est important pour nous, ce qui touche à nos valeurs. Le simple fait d’en parler augmente la proximité relationnelle. La 3^ème question permet éventuellement de trouver des pistes d’amélioration. 

J’ai expérimenté avec succès ce format auprès d’une équipe en situation de blocage où concrètement le contexte l’empêchait d’atteindre ses objectifs. Cette session avait fait beaucoup de bien aux participants. En effet dans cette situation, il était plus important de soigner les relations et le ressenti des équipiers : 1h30 de plaisir à échanger et apprendre à mieux se connaitre dans un contexte, par ailleurs, assez pesant. 

Et vous, quelles pratiques recommandez-vous pour prendre soin de l’équipe, améliorer la qualité des relations et éviter l’accumulation de la dette émotionnelle ?

3. Rétrospective à l’échelle

Losrque l’on est nombreux et qu’il y a plusieurs équipes agiles qui ont besoin de coordonner leurs travaux, les besoins d’amélioration continue se trouvent à plusieurs niveaux du cadre de travail commun : 

• Soit c’est interne aux équipes 
• Soit cela concerne le besoin de faire évoluer le cadre de travail commun ou les pratiques de coordination. 

On pourrait naïvement imaginer 2 temps d’amélioration continue : 

• 1 qui se passe dans chaque équipe pour améliorer les pratiques des équipes 
• 1 qui se passe au niveau de la couche de coordination pour améliorer les pratiques transverses 

Et c’est déjà bien ! Mais en réalité, les différents niveaux de l’organisation ne sont pas indépendants les uns des autres. 

• Certaines difficultés rencontrées par les équipes nécessitent une évolution de cadre de travail commun pour être dépassées 
• Certaines améliorations transverses nécessitent une évolution des pratiques ou du cadre de travail de certaines (ou de toutes les) équipes 

Cela étant dit, comment organiser les temps d’amélioration continue ? Comment faire monter ou descendre les problématiques au niveau suivant ? Qui inviter ?

3.1 Quelles modalités pour des actions concertées ? 

Afin d’obtenir des actions concertées entre les différentes couches de l’oralisation il y a 2 options principales pour le mode opératoire : 

• Bottom-up : les différentes équipes font leur rétro chacune individuellement puis les éléments qui émergent de ces ateliers servent de point d’entrée pour la rétro générale (c’est le mode que j’ai le plus souvent observé). 
• Top-down : La retro générale est faite en premier et les actions qui impactent les équipes servent d’inputs pour les rétros des équipes concernées 

3.2 Quels participants inviter ? 

Si on organise une rétrospective au niveau équipe d’équipes (Train SAFe, Tribu, Factory, …) quels participants doit-on inviter ? Tout le monde ou seulement des représentants de chaque équipe ?

💡A noter : Le pattern organisationnel dit du Double Lien permet d’assurer, qu’au bout d’un certain temps, tous les équipiers auront eu un échange direct avec la couche de coordination, même si seulement 2 délégués de chaque équipe sont invités à chaque évènement. En effet, en plus du porte-parole de l’équipe, par exemple l’Agile Master, à tour de rôle un autre équipier est invité à participer à l’évènement. 

💡Pour éviter l’effet redite, dans le cas où tout le monde est invité à la rétro générale il est possible de de ne pas faire les rétros d’équipes pour la dernière itération de la période. 

A mon avis, au minimum 1 fois par an il est bon de faire l’exercice avec tout le monde car rien de remplace les échanges face à face pour une communication de qualité. Tout dépend aussi du nombre d’occasion qu’ont les membres des équipes d’échanger en direct avec les personnes qui incarnent la couche de coordination. 

3.3 Des leaders et des managers impliqués

La rétrospective générale, qui se situe au niveau de la couche de coordination, concerne le cadre de travail commun à plusieurs équipes. En général, on se situe à l’échelle d’un service ou d’un département. 

Les problématiques abordées concernent des sujets tels que : coordination et suivi, principes et règles de fonctionnement, communication, alignement entre la stratégie et l’opérationnel… 

Les personnes qui ont une mission dans cette strate de l’organisation sont soit des managers, soit des leaders sur certains aspects importants. On y trouve des rôles avec principalement des missions d’alignement, de coordination et de suivi. Par exemple : Release Train Engineer, Product Manager, Delivery Manager, Release Manager, Manager Agile etc. 

En français, « manager » = « cadre ». C’est une personne responsable du maintien et de l’évolution du cadre de travail, permettant aux équipes d’effectuer leur travail dans de bonnes conditions. 

Il est important que les personnes ayant une mission à cet étage de l’organisation s’impliquent concrètement dans les actions d’amélioration continue et donnent le bon exemple. (en étant porteurs de certaines actions par exemple). De plus, avoir des managers impliqués sur la résolution des problèmes et le maintien d’un cadre de travail général efficace permet aux équipiers de se sentir écoutés et soutenus dans leur mission. 

Et chez vous, comment ça se passe la rétrospective lorsque qu’il y a plusieurs équipes qui travaillent ensemble sur un même périmètre ?

4. Ressources et Références

📘 4.1 Livres 

• Agile Retrospectives: Making Good Teams Great de Esther Derby et Diana Larsen  
• Project Retrospectives: A Handbook for Team Reviews de Norman L. Kerth 
• Game Storming de Dave GRAY, James MACANUFO et Sunni BROWN 
• Solution Focus de Géry Derbier 

📰 4.2 Articles 

• Où je me suis trompé sur l’agilité : la rétrospective de William Bartlett 
• Les 5 phases d’une rétrospective ne suffisent pas : le modèle Double Diamond de Jean Michel Diaz 
• Droit à l’erreur, enjeu personnel ou d’organisation ? de Damien Roquel 
• Pas de performance sans sécurité psychologique ! de Benjamin Couet
• Le travail vivant – La Revue Pratiques Interview de Christophe Dejours (Psychiatre et Psychanalyste) 
• Devenez maître du monde… avec la conversation structurée (méthode ORID) ! de Maxence Walbrou
• Les “Core Protocols”, des pratiques simples et puissantes pour une véritable vie d’équipe de Frantz Degrigny
• Etes-vous “Agile Fluent” ? de Frantz Degrigny

🎬 4.3 Vidéos 

• La Rétrospective & Notre Rapport À L’Erreur Naveed Mirza et Emeline Boulet 
• Comment réduire la dette émotionnelle d’une équipe Marilyn Kol 
• Spotify de l’intérieur Rachel Dubois 
• Les bons Scrum et les mauvais Scrum Alexandre Boutin 
• Décider ensemble efficacement Gaëlle Abautret et Frantz Degrigny
• Dan Pink Drive : la vérité surprenante sur ce qui nous motive Daniel Pink 

🎲 4.4 Ateliers et Jeux Sérieux 

• Le jeu Fearless Journey 
• Les cartes Squad Health Check 
• Les cartes Tests Health Check 
• Les cartes forces Positran 
• Les cartes Maturité Produit de Thiga
• Les cartes Agile Smells Bad 
• Les cartes Moving Motivators 
• Les cartes Feedback en milieu sauvage Good!
• Le jeu Totem 
• The Meeting Spicer 
• Les Liberating Structures
• La Conversation Structurée ORID (Focus Conversation)
• Les cartes unFIX decisions methods 

Conclusion

Dans cette série d’articles, je vous ai partagé mon point de vue sur la Rétrospective Agile ainsi que l’évolution de ma pratique au cours des 15 dernières années. 

Pour les équipes auto-gérées, telles que les équipes Scrum par exemple, la rétrospective est aussi l’espace démocratique dans lequel sont prises les décisions pour faire évoluer le cadre de travail commun ainsi qu’un temps pour prendre soin de l’équipe. 

J’ai partagé avec vous mon expérience complétée avec les apports les réflexions d’autres agilistes qui m’ont inspiré ainsi toutes ces choses que j’aurai aimé connaitre lorsque j’ai débuté 

Et vous ? Comment ça se passe pour vous ? 
Que pensez-vous de la rétrospective ? 
Selon vous, quelles sont les pratiques qui fonctionnent et celles qui sont discutables ? 

Je serais très intéressé d’avoir votre avis.

The post La Rétrospective Agile 3/3 : aller plus loin appeared first on Conserto.

Comment l’écoute active des utilisateurs a permis d’améliorer une application métier et de renforcer son adoption dans un projet agile.

Un peu de contexte

Je suis intervenu en tant que PO chez un de nos client de Montpellier sur un projet qui consiste à refondre l’ensemble du SI qui gère les dossiers des assurés, de l’ordre de mission à la facturation.

C’est un projet en mode scrum avec des fonctionnalités développées en itération, qui a commencé par un POC avec un périmètre restreint à 4 régions, qui s’est élargi au fur et à mesure, soit environ 50 utilisateurs au début, puis 117 au bout de 4 ans.

Notre équipe était composée de 7 développeurs, 1 architecte, 4 PO (dont 1 interne chez le client).

Les objectifs principaux du projet étaient d’augmenter la productivité des gestionnaires de dossier, notamment en simplifiant les formulaires et en automatisant la gestion des tâches à réaliser.

Dans le cadre du projet, notre nouvelle application de gestion des dossiers assurés, les retours utilisateurs ont rapidement pris une place centrale dans notre manière de travailler. Dès le lancement, nous avons voulu faire de l’écoute active un levier de qualité, d’agilité… et de confiance.

Mettre en place l’écoute terrain

Nous avons mis en place au fur et à mesure plusieurs supports et formats d’échange avec les utilisateurs :

• Des visios mensuels appuyées par un tableau Miro pour visualiser l’état d’avancement des US/Tickets par grandes fonctionnalités.
• Les canaux Teams dédiés (permanent) un général et un par groupe d’utilisateurs uniquement pour gérer les bugs bloquants avec un SLA associé.
• Lors des démos toutes les 3 semaines : où chaque session se conclut par un temps d’échange ouvert, précieux pour récolter les impressions sur les nouvelles fonctionnalités.

Ce dispositif nous a permis de capter un grand nombre de retours, très concrets, et souvent faciles à prioriser car récurrents ou rapidement impactants.

Objectifs des visios :

• Donner de la visibilité aux utilisateurs sur le traitement de leurs sujets : Sont-ils en instruction ? En cours de développement ?…
• Communiquer sur la priorisation des sujets en fonction de la roadmap
• Remonter les bugs lors de l’utilisation de l’appli
• Répondre aux questions
• Constater que les retours des points mensuels précédents ont été pris en compte

Ce rendez-vous a vu son format évoluer, au départ nous faisions le suivi des fonctionnalités avec 3 statuts, puis avec 5 statuts. De plus certains de ces points ont pu avoir des thématiques précises, par exemple :

En 2024, je veux…

• Arrêter
• Commencer
• Améliorer

Ce format a permis de relever les besoins des utilisateurs d’une façon plus libre, plus large qu’avec le support habituel.

Plus globalement l’ensemble des actions mises en place ont permis de :

• Remonter les problèmes bloquants
• Identifier les irritants récurrents pour les traiter rapidement : ici on analyse le ration effort de travail face au bénéfice utilisateur.
• Donner un maximum de visibilité aux utilisateurs : sujets en instruction, en développement…
• Garder les utilisateurs sur l’application

Du retour utilisateur à l’amélioration produit

Deux exemples illustrent bien l’impact de cette démarche :

1. Les formulaires ont été largement repensés à partir des retours utilisateurs. Nous avons introduit :
   • des champs à auto-complétion,
   • des champs secondaires masqués par défaut,
   • des zones extensibles,
   • un stepper pour guider la saisie,
   • et une amélioration globale de l’ergonomie.

Résultat : une réduction de 30 % du temps passé sur les formulaires. Les retours positifs ont été quasi immédiats, ce qui a eu un effet très motivant sur toute l’équipe.

2. Autre cas significatif : au lancement, l’algorithme d’attribution de tâches ne prenait pas en compte les absences des gestionnaires. Résultat : des tâches assignées pendant les congés.
   Suite aux retours, nous avons intégré les périodes d’absence, et mis en place un système de back-up automatique pour assurer la continuité. Une évolution bien accueillie, et qui a renforcé l’adoption de l’application.

Informer, expliquer, valoriser : la communication au cœur de la démarche

L’écoute n’a de valeur que si elle s’accompagne d’un dialogue clair et régulier. C’est pourquoi nous avons mis en place plusieurs supports pour maintenir un lien actif avec les utilisateurs tout au long du projet :

• des questionnaires de satisfaction ponctuels pour évaluer la perception de l’outil et recueillir des suggestions,
• des communications de Mise en Production, systématiquement accompagnées d’une notice détaillant les nouvelles fonctionnalités,
• un guide utilisateur régulièrement mis à jour,
• des notifications directement dans l’application, pour signaler les nouveautés sans perturber l’usage,
• et des comptes rendus de nos points mensuels en visio, pour que l’information reste accessible à tous, même en différé.

Ces actions permettent non seulement de mieux accompagner les évolutions, mais aussi de valoriser les retours qui ont mené à des améliorations visibles.

Nous avons pu mesurer ces progrès dans splunk avec moins de temps de chargement lors de la création de dossier, moins de temps passé sur les formulaires : deux facteurs importants qui généraient de la frustration chez les utilisateurs.

Des résultats concrets et un apprentissage collectif

Au-delà des améliorations produit, cette approche a généré un vrai engagement utilisateur. L’écoute régulière a renforcé la confiance et facilité l’appropriation de l’outil. Résultat : une meilleure adoption globale de l’application, et une dynamique continue d’amélioration.

Et la suite ?

Nous poursuivons cette démarche, avec l’objectif d’automatiser encore certaines remontées, et de mieux catégoriser les retours pour faciliter leur traitement.
L’écoute ne s’arrête pas à la livraison d’une fonctionnalité : elle commence dès sa première utilisation.

The post Écouter pour mieux construire : retour d’expérience sur le traitement des retours utilisateurs appeared first on Conserto.

Série d’articles “La Rétrospective Agile : une pratique essentielle, pas toujours bien comprise”

Episode n°2 : Eviter les chausse-trappes

Précédemment :
– Episode n°1 : Evolution de ma pratique


Et pour approfondir le sujet :
– Episode n°3 : Aller plus loin

William Bartlett, dans son article “Où je me suis trompé sur l’agilité : la rétrospective“, s’interroge sur la pertinence de cette pratique et sur ses limites.

“Personnellement, ça fait deux ans que je considère que c’est la pratique agile qui apporte le plus de gaspillage. Si vous avez une expérience plus positive et que vos rétrospectives vous réussissent, tant mieux. Je serais intéressé d’échanger avec vous.”

— William Bartlett

Cette prise de position peut surprendre… mais elle résonne avec certaines observations que j’ai pu faire moi aussi.

Pendant longtemps, j’ai vu les rétrospectives comme un moment précieux, porteur de sens et d’amélioration continue. Je continue à penser qu’elles peuvent être extrêmement utiles, mais pas à n’importe quelles conditions.

Avec le temps, l’expérience et de nombreux échanges avec d’autres praticiens, ma façon d’animer et de concevoir les rétrospectives a profondément évolué. Cette série d’articles est l’occasion pour moi de revenir sur ce cheminement : ce que j’ai appris, ce que j’ai ajusté, ce que j’ai parfois laissé de côté, et surtout pourquoi.

Dans ce second épisode, je vous propose d’explorer les pièges à éviter. Quels sont les biais auxquels nous sommes confrontés durant un tel exercice ? Et surtout, quelles pratiques sont à notre disposition pour les éviter ou en limiter les effets. Quel format choisir pour maximiser l’impact positif de cette activité sur l’équipe.

Sommaire

• Des espaces d’expérimentation et de collaboration
• Limiter les biais individuels et collectifs
  • Eviter le biais de récence
  • Eviter le biais de cascade
  • Appropriation collective des idées
  • Un format pour sortir des séquences courtes à base de post-it 
• Adapter le rythme et le format à la situation de l’équipe
  • Mise en route de l’équipe
  • L’équipe est en situation d’échec
  • L’équipe est en situation d’erreur
  • L’équipe est en situation d’amélioration

1. Des espaces d’expérimentation de collaboration

S’il est bon, pour une équipe, d’avoir un temps dédié pour inspecter sa façon de travailler comme indiqué dans le Manifeste pour le développement Agile de logiciels :

“À intervalles réguliers, l’équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence.“

Il est probablement illusoire, voire malsain, de soumettre l’équipe à une injonction de trouver toutes les 2 semaines des actions d’amélioration à ajouter dans sa liste des tâches à faire (backlog).

Ce qui est important, ce n’est pas de faire des rétros à chaque itération, c’est d’avoir assez d’espaces d’expérimentation et de collaboration. Cela peut inclure des temps de partage et veille technique, des Kata de code pour s’entraîner etc… 

On découvre que pour que la coopération fonctionne, il faut des espaces de délibération dans lesquels les gens discutent de “comment on fait”, et pas seulement de ce qui est efficace ou inefficace, de ce qui est vrai ou faux, mais aussi de ce qui est juste et injuste, de ce qui est bien et ce qui est mal, de ce qui est équitable.
[…] Or, cet espace de délibération est construit exactement comme l’espace public au sens d’Aristote, au sens de la cité. C’est l’espace public dans lequel les gens vont ouvertement confronter leurs opinions. Il s’agit, à propos du travail, de discuter sur quelle base se feront les accords, puis les accords normatifs en matière d’organisation du travail.

Le travail vivant – La Revue Pratiques Extrait d’un interview de Christophe Dejours – Psychiatre et Psychanalyste 

De mon expérience, les premières rétros sont souvent le lieu où l’équipe peut décider de la forme que prendront ces autres espaces d’expérimentation. La rétro est le point de départ pour en créer d’autres. 

Il est aussi possible de vivre la rétro, non pas comme un atelier de type remue-méninge/plan d’action, mais plutôt comme un point de mutation, une assemblée où l’équipe ajuste son mode de fonctionnement pour la suite, à partir de propositions élaborées en amont. C’est, en quelque sorte, l’assemblée législative de l’équipe. 

Ces propositions peuvent prendre la forme de RFC (Request For Change, inspirés des RFC “Request For Comment” du processus normatif autour d’Internet) comme dans l’entreprise Spotify très bien expliqué par Rachel Dubois dans sa conférence à Rennes en 2024. 

La prise de décision par consentement mutuel est un bon moyen pour affiner et adopter ces propositions en équipe. J’en ai parlé en détails dans ma conférence “Décider ensemble efficacement”. 

2. Limiter les biais individuels et collectifs

Les biais cognitifs individuels et collectifs sont inévitables, néanmoins certaines pratiques peuvent en limiter les effets négatifs. 

2.1 Eviter le biais de récence

Même si l’on fait le point régulièrement, c’est plus difficile de se rappeler de ce qui s’est passé au début de la période inspectée. 

Voici plusieurs pratiques qui peuvent limiter cet effet : 

2.1.1 – La frise chronologique 

Chaque membre de l’équipe vient écrire les évènements, dont il se souvient, et qui sont importants pour lui sur une frise chronologique de la période. 

Et même si ce récit est biaisé par notre mémoire, ce n’est peut-être pas très grave, ce qui compte c’est le récit collectif qui émerge du groupe. Une perception partagée de ce qui s’est passé pendant la période observée. 

2.1.2 – Partage de nos ressentis sous forme de courbes 

Chaque personne partage l’évolution de son ressenti au cours de la période observée, sous forme d’une courbe, et explique à quel moment c’était agréable ou désagréable pour elle et dit pourquoi. C’est très utile, surtout si les histoires individuelles sont très différentes. Cela permet à chacun de se rendre compte que tout le monde n’a pas vécu la même chose bien que nous soyons dans la même équipe. 

Cet exercice peut (ou pas) être combiné à la frise chronologique. 

2.1.3 – Bac rouge / Bac bleu 

Pour éviter d’oublier les problèmes ainsi que les bonnes idées : on peut réserver 2 espaces pour les stocker. Le bac rouge 💥 pour les problèmes rencontrés, le bac bleu 💡 pour les bonnes idées. Ainsi on reste focus sur la tâche en cours. Au moment de la rétro, le contenu des bacs est analysé. 

Le bac rouge comme analogie au Toyota Production System (TPS) dans lequel un bac rouge est réservé aux pièces défectueuses. Plutôt que de perdre du temps à réparer sur le moment, l’ouvrier met la pièce non conforme dans le bac rouge et continue son travail. Au bout d’une période le bac rouge est vidé pour analyse et éventuelles corrections. Ainsi, il n’y a pas d’interruption dans le travail et du temps est réservé à l’amélioration continue. 

2.1.4 – Les Kudo Cards 

Réserver du temps lors de la rétro pour des feedbacks positifs et des remerciements est un bon moyen de commencer l’atelier sur une note positive.

Mais pourquoi attendre ? Les Kudo Cards et la Kudo Box, outils issus du Management 3.0, sont un bon moyen d’exprimer sa gratitude auprès de ses collègues tout au long de l’itération. L’inspection du contenu de la boîte peut servir d’introduction à la rétro. 

Cela peut être bon un moyen d’introduire la culture du feedback dans une équipe. 

2.1.5 – Le Ticket d’or 

Il est dommage d’attendre la rétrospective pour réaliser des actions d’améliorations. Le Ticket d’or, attribué à chaque personne, correspond à un volume d’heure que chacun est libre de consommer (ou pas) à sa convenance (expérimentation, correction, veille, …) à la seule condition de montrer les résultats de son travail ou ses apprentissages au reste de l’équipe. 

Pour l’anecdote, cette pratique a permis de convaincre un de mes clients que la refonte d’un module, très mal conçu, était non seulement possible mais finançable grâce à la présentation, en revue d’itération, du résultat d’un petit prototype sur l’initiative d’un développeur alors que le reste de l’équipe avait baissé les bras face à cette difficulté. 

2.2 Eviter le biais de cascade

Le biais de cascade apparait lorsque les premières prises de positions influencent la suite des échanges. 

2.2.1 – Le Dot Voting à bulletin secret 

C’est pour cela que je n’utilise plus le vote par points (Dot Voting) si celui-ci n’est pas réalisé à bulletin secret. Heureusement, des outils comme de tableaux numériques comme Klaxoon ou Miro incluent cette fonctionnalité. 

2.2.2 – La Liberating Structure 1, 2, 4 Tous 

La séquence apportée par la Liberating Structure 1, 2, 4 Tous est très intéressante. Elle permet à chacun de commencer par réfléchir, en silence et par écrit à ses propres opinions. Puis d’avoir un premier en échange en binôme avant d’élargir la discussion. Cela permet aux personnes plus introverties de se sentir à l’aise et aux bavards de ne pas monopoliser les échanges. 

Et vous, quelles pratiques connaissez-vous pour limiter l’effet des biais individuels et collectifs ?

2.3 – Appropriation collective des idées 

Il est souvent difficile de laisser de côté les égos et souvent la discussion s’enlise car chacun reste campé sur ses positions. Voici 2 séquences qui permettent de conforter les idées entre elles sans savoir qui en est l’auteur. 

2.3.1 – Le 5 / 35  

Le 5 / 35 (ou le 35) est un jeu cadre de Thiagi qui permet de faire émerger les idées ou les points d’observation les plus intéressants en les confrontant les unes aux autres, de manière anonyme, en 5 rounds. 

💡A noter : cette séquence prend le même temps quelle que soit la taille du groupe. 

2.3.2 – Le storytelling collaboratif 

J’ai découvert le Storytelling Collaboratif lors d’un atelier animé par Charles-Louis De Maere à la conférence Agile Tour Nantes 2023. C’est un format dans lequel les idées se diffusent progressivement dans le groupe, suite à un certain nombre d’échanges en binômes. 

A la fin des échanges on ne sait plus qui est l’auteur de quoi. Les idées deviennent la propriété du groupe. 

2.4 Un format pour sortir des séquences courtes à base de post-it 

Les ateliers à base de séquences courtes où les idées sont matérialisées sur des post-it peuvent ne pas convenir à tout le monde.  

La Conversation Structurée (Focus Conversation) est un format plus proche d’une conversation informelle. Elle conviendra mieux aux personnes dont les préférences cognitives se tournent vers le temps long, l’oralité, l’auditif, un style plus “littéraire” à base de phrases complètes. 

Et vous, quelles pratiques connaissez-vous pour favoriser l’inclusion et la propriété collective des idées ?

3. Adapter le rythme et le format au contexte de l’équipe 

Il faut adapter le rythme et la durée des sessions ainsi que le format de l’atelier de rétro à la situation de l’équipe. Souvent, j’ai vu des équipes choisir le format de rétro sur des critères “cosmétiques”: seul l’habillage change (ex Mario, Halloween, Football, … ) le fond reste le même, ce qui peut induire une lassitude de l’équipe. De plus, la fréquence et la durée sont rarement questionnées.

3.1 Adapter le rythme et la durée à la situation de l’équipe 

Il faut adapter le rythme et la durée de cette activité à la situation de l’équipe : L’équipe est-elle à temps plein ou à temps partiel ? Est-elle dans une situation où les choses doivent évoluer rapidement ou au contraire le contexte est stable et performant et demande peu d’ajustement ? 

Savez-vous que dans la version 1 du Scrum Guide la rétro n’existait pas ? En effet l’amélioration continue se fait en continu. Les auteurs ne voyaient pas l’intérêt d’un évènement dédié. En pratique, les retours d’expérience ont montré que si n’y a pas de temps dédié pour ça nous avons tendance à ne pas le faire. 

C’est comme chez moi, si j’arrête de faire le ménage et les réparations, ma maison devient vite beaucoup moins agréable et utilisable. 

De plus, l’équipe est peut-être très à l’aise avec son mode de fonctionnement mais le reste du monde évolue. Les attentes changent et les interactions se modifient, des gens arrivent et d’autres partent. A intervalles régulier l’équipe doit ajuster son mode de fonctionnement pour rester en phase avec son environnement. 

La fréquence peut varier de 30 min chaque jour en situation de crise à une fois par trimestre ou même par semestre (quand d’autres espaces d’expérimentation et de partage sont en place). La durée de l’atelier dépend de la fréquence et du nombre de difficultés et des ajustements auxquels l’équipe est confrontée. 

3.2 Utiliser un format adapté à la situation de l’équipe 

Naveed Mirza et Emeline Boulet dans leur session La Rétrospective & Notre Rapport À L’Erreur à Agile Niort 2024 proposent, pour qualifier la situation de l’équipe, 3 niveaux en qualifiant l’écart que l’on observe par rapport à ce qui est attendu de l’équipe, en termes de livrables et/ou de modes de fonctionnement. 

En effet, la situation de l’équipe devrait guider la préparation de l’atelier. L’équipe doit-elle se sortir d’une crise ou bien juste optimiser ce qui marche déjà ? 
J’aime beaucoup cette idée de qualifier la situation de l’équipe avant toute chose. Je n’y avais pas forcément pensé avant cette session, maintenant c’est plus clair dans ma tête. 

J’ajouterai un premier niveau qui est la situation ou l’équipe est en train de se mettre en ordre de marche et où tout est à construire (les 1 ou 2 premières itérations / la phase de préparation). 

Typologie des situations : 

1. Mise en route de l’équipe, rodage : mise en place des pratiques et des outils 

2. Echec : l’équipe est en situation d’échec 

3. Erreur : l’équipe fonctionne mais il y a des problèmes qui doivent être corrigés rapidement 

4. Amélioration : l’équipe fonctionne, il y a des choses qui peuvent être améliorées 

Voici quelques idées pour guider la préparation (non exhaustives, ni exclusives) en fonction de la situation. 

3.2.1 – Mise route de l’équipe 

Situation : 

L’équipe est en phase de démarrage. Il faut définir le mode de fonctionnement et mettre en place les outils pour travailler efficacement (certains parlent de sprint 0, ou phase de préparation) 

Exemples : 

• Il faut définir le mode de fonctionnement et mettre en place les outils pour livrer rapidement 
• Les équipes doivent faire connaissance et découvrir les préférences de communication de chacun. 

Besoins :

Il faut rapidement mettre en place le cadre de travail minimum pour livrer rapidement de la valeur et être en mesure de recevoir les premiers feedbacks des parties prenantes. Il faut faire connaissance et créer une certaine intimité relationnelle pour établir un climat de confiance. 

Quoi faire :

Des pratiques de type : cohésion d’équipe (Personal Map, Manual of Me), remue-méninge, plan d’action et suivi 

3.2.2 – L’équipe est en situation d’échec 

Situation :  

L’équipe est en situation d’échec par rapport à ce qui est attendu (livrables et/ou mode de fonctionnement). 

Exemples :

• L’équipe n’arrive pas à livrer. 
• La communication est rompue. Certains acteurs refusent de travailler ensemble. D’autres viennent travailler la boule au ventre. 

Besoins :

L’équipe a besoin de sortir du chaos pour retrouver un fonctionnement nominal et regagner la confiance (en elle-même et avec ses partenaires). 

Quoi faire :

Pratiques de type gestion de crise. Faire cycles très courts (ex faire le point 30 min chaque jour ou tous les 2 jours), faire des petits pas, afficher des victoires rapides pour regagner la confiance, rétablir un fonctionnement minimal pour passer en situation 3 

3.2.3 – L’équipe est en situation d’erreur 

Situation :

L’équipe fonctionne à peu près mais Il y a des problèmes qui doivent être corrigés rapidement. Ou bien, l’équipe fonctionne et répond aux attentes, vis à vis des parties prenantes et du reste de l’organisation mais cette fois-ci il y une erreur ponctuelle qui est survenue.

Exemples :

• L’équipe arrive à livrer mais il y a plein de bugs à corriger. 
• La communication est globalement OK mais elle reste très difficile entre certains acteurs. 

Besoins :

L’équipe a besoin de comprendre ce qui c’est passé afin d’éviter que ce type d’erreur se reproduise à l’avenir.

Quoi faire :  

Des sessions de type résolution de problème (5 pourquoi, Ishikawa, Appreciative Inquiry), Augmenter ce qui fonctionne déjà bien. 

3.2.4 – L’équipe est en situation d’amélioration continue

Situation : 

L’équipe qui fonctionne globalement et répond aux attentes. Il reste des choses qui peuvent être améliorées et/ou optimisées. L’équipe est dans une situation où le principe d’amélioration continue est parfaitement adaptée.

Exemples : 

• L’équipe livre régulièrement des choses qui fonctionnent et répondent aux attentes mais le processus de livraison reste fastidieux et pénible. 
• La communication est fluide. Le respect est là. Néanmoins il est surement possible d’améliorer la qualité de notre écoute et de nos feedbacks. 

Besoins :

L’équipe a besoin d’optimiser ce qui peut l’être afin d’éviter le gaspillage et continuer d’être en accord avec son écosystème.

Quoi faire : 

Célébrer les succès. Mesurer ce qui compte vraiment pour savoir où mettre l’effort d’optimisation. 

Et vous, comment choisissez-vous le format adapté pour votre rétrospective ? Quels sont vos critères ?

Conclusion

Dans ce second article sur la rétrospective agile, je vous ai partagé :

• Des idées sur la mise en perspective de cette activité par rapport à d’autres espaces de partage et d’expérimentation ainsi que son importance fondamentale pour la vie de l’équipe

• Des pratiques pouvant limiter les biais cognitifs qui ont toutes les chances d’être convoqués lors de ce type d’exercice, ainsi que des formats favorisant l’inclusion et la propriété collectives des idées

• Des réflexions et des pistes d’actions pour mieux choisir le format en fonction de la situation de l’équipe (rodage, échec, erreur ou amélioration)

Et vous, quelles autres pratiques avez-vous expérimenté ? Quelles sont celles que vous avez abandonnées ?

Pour poursuivre votre lecture

Découvrez le dernier épisode de cette série.

L’épisode 3 : Aller plus loin, aborde :

• Le rôle délicat de l’Agile Master : guider sans imposer

• La rétro comme moyen pour prendre soin de l’équipe

• Rétrospective à l’échelle (quand plusieurs équipes sont concernées)

• Ressources et références (articles, livres, vidéos, ateliers et jeux)

The post La Rétrospective Agile 2/3 : éviter les chausse-trappes appeared first on Conserto.

Série d’articles “La Rétrospective Agile : une pratique essentielle, pas toujours bien comprise”

– Episode n°1 : Evolution de ma pratique

À lire ensuite :
– Episode n°2 : Eviter les chausse-trappes

– Episode n°3 : Aller plus loin

William Bartlett, dans son article “Où je me suis trompé sur l’agilité : la rétrospective“, s’interroge sur la pertinence de cette pratique et sur ses limites. 

« Personnellement, ça fait deux ans que je considère que c’est la pratique agile qui apporte le plus de gaspillage. Si vous avez une expérience plus positive et que vos rétrospectives vous réussissent, tant mieux. Je serais intéressé d’échanger avec vous. »

— William Bartlett

Cette prise de position peut surprendre… mais elle résonne avec certaines observations que j’ai pu faire moi aussi.

Pendant longtemps, j’ai vu les rétrospectives comme un moment précieux, porteur de sens et d’amélioration continue. Je continue à penser qu’elles peuvent être extrêmement utiles, mais pas à n’importe quelles conditions.

Avec le temps, l’expérience et de nombreux échanges avec d’autres praticiens, ma façon d’animer et de concevoir les rétrospectives a profondément évolué. Cette série d’articles est l’occasion pour moi de revenir sur ce cheminement : ce que j’ai appris, ce que j’ai ajusté, ce que j’ai parfois laissé de côté, et surtout pourquoi.

Dans ce premier épisode, je vous propose un retour d’expérience : comment ma pratique a changé au fil des années et ce que j’en retiens.

Sommaire

1. Au début était, l’étoile de mer
2. Eviter « la purge »
3. Evaluons-nous réellement l’impact de nos actions ?
4. Rentrer dans le dur
5. Un temps nécessaire pour un partage des ressentis
6. Limiter la divergence des idées pour se concentrer ce qui compte vraiment 

1. Au début était l’étoile de mer

A mes débuts, comme beaucoup, j’ai fait simple en utilisant le format étoile de mer (Starfish). Et c’était bien : cela a généré des échanges et de la discussion, l’équipe a trouvé plein de pistes d’amélioration… un peu trop, en vérité ! 

C’est un format que je n’utilise plus : il génère facilement trop de divergence, de plus les catégories se chevauchent et entraînent de la confusion, des répétitions.

2. Eviter « la purge »

Un premier défaut que j’ai vu arriver assez souvent, notamment dans des équipes qui démarrent, ce sont des sessions de type « purge » où l’équipe râle beaucoup, souvent sur des aspects qui ne sont pas dans son domaine d’influence. On reporte la faute sur les autres et, finalement, il n’y a pas vraiment de pistes de solution.  

Exprimer les frustrations, c’est bien. Mais sans pistes d’action ça peut vite devenir anxiogène. Laisser la discussion dans l’espace des problèmes peut vite créer une ambiance délétère. 

Se projeter dans l’espace des solutions est plus agréable, plus motivant et donne de meilleurs résultats. Pour ce faire, il est intéressant de suivre des approches telle que Solution Focus. La Rétro 4L est plutôt bien pour ça. C’est un format dont je n’avais pas assez bien compris l’intérêt la première fois que je l’ai découvert.

La Rétro 4L c’est répartir les observations et constats, sur la période inspectée, en 4 catégories :

• Like : Ce que j’ai aimé
• Learn : Ce que j’ai appris
• Lack : Ce qui m’a manqué pour bien travailler
• Long For : Ce dont je rêve pour la suite

Si vous ne la connaissez pas, je vous invite à l’essayer.

3. Evaluons-nous réellement l’impact de nos actions ?

Un autre défaut très commun c’est de ne pas suivre les actions d’amélioration décidées ensemble mais surtout de ne pas évaluer leur impact. Le but n’est pas de réaliser les actions listées mais bien d’améliorer la situation. 

J’ai vraiment pris conscience de la non-évaluation quasi-systématique des impacts réels lors de la conférence « Les bons Scrum et les mauvais Scrum » par Alexandre Boutin à Agile Grenoble 2022.

3.1 – Un plan d’action avec intentions et observables

Désormais, je passe beaucoup plus de temps sur l’affinage des actions. J’invite l’équipe à décrire l’intention avant de lister des actions. Puis pour chaque action, j’invite l’équipe à préciser la définition des bénéfices attendus : que voulons-nous observer comme changements une fois l’action terminée ? Quels sont les métriques et/ou observables qui pourront nous montrer que l’action est un succès ? Un peu comme lorsque que l’on suit une approche OKR.  

J’observe souvent des aller-retours entre la description des actions et l’explicitation des observables attendus. En effet, parfois les attendus ne correspondent pas à la description de l’action : il faut peut-être imaginer une autre action ou bien affiner les observables. 

Le rôle du facilitateur de l’atelier est d’aider l’équipe dans ce processus d’affinage du plan d’action. Parfois les objectifs sont très intéressants mais trop ambitieux pour être atteints dans un intervalle de temps raisonnable. Dans ce cas, il faut guider l’équipe vers des premiers pas activables. Avec des questions du type : par quoi pouvons-nous commencer ? 

J’aime bien mettre les idées sous forme d’un tableau avec les colonnes suivantes : 

• Intention / objectif 

• Description de l’action 

• Observables / Evolutions attendues / Futur désiré 

• Porteur 

• Échéance envisagée 

J’utilise aussi un modèle de fiche action pour aider des petits groupes à concrétiser leurs idées. 

3.2 – Evaluer l’impact réel des actions

A la fin de la période, lors de la rétrospective suivante, il faut évaluer l’impact de nos actions. Pas seulement si les actions ont été réalisées ou non. Voici ce que l’on veut savoir : Qu’observe-t-on de différent dans notre environnement ? Est-ce bénéfique ? Y compris si ce n’est pas ce qui était attendu ! 

En préparant l’atelier, J’aime bien recopier le tableau du plan d’action en ajoutant une colonne : 

• Nos observations : Que s’est-il passé ? Qu’observe-t-on aujourd’hui ? 

Et en supprimant la colonne “échéance” (normalement plus tellement utile, la période étant terminée). 

Cela est suffisant pour une période inspectée assez courte. Pour une période plus longue (par exemple trimestre ou plus), ou dans le cas d’un grand groupe, afin de faciliter les échanges et la remontée d’informations vraiment utiles, j’aime bien dédier une séquence à l’analyse en utilisant le format : Liberating Structure W3 (What, Now What, So What) par petits groupes (ou en binômes).

• What : Qu’a-t-on observé (les faits) ?

• Now What : Que peut-on en déduire (analyse) ?

• So What : Que va-t-on faire maintenant (action) ?

4. Rentrer dans le dur

Au bout d’un certain temps, toutes les actions d’amélioration « faciles » ont été mises en place. Les formats de rétro généralistes ne permettent plus de passer assez de temps sur les sujets difficiles. C’est peut-être le moment de se concentrer sur certains sujets plus « difficiles » pour les explorer plus en détail. 

C’est aussi à cette époque que je me suis documenté pour améliorer ma pratique, notamment au travers des livres :

• Agile Retrospectives: Making Good Teams Great de Esther Derby et Diana Larsen.
• Games Storming de Dave GRAY, James MACANUFO et Sunni BROWN, notamment le chapitre qui parle de la conception d’atelier et de comment on peut chaîner les séquences, où les éléments en sortie d’une séquence sont les entrées de la suivante. 

4.1 – Quand toutes les actions « faciles » ont déjà été traitées 

La première fois que je me suis retrouvé dans cette situation, en tant que Scrum Master, j’ai proposé une rétro avec un thème que j’avais choisi moi-même. Et ça a plutôt bien marché. Cela nous a permis, en tant qu’équipe, de nous concentrer sur un problème important pour nous, à ce moment-là. Néanmoins, les membres de l’équipe ont exprimé de la frustration à ne pas pouvoir aborder d’autres sujets que celui mis à l’ordre du jour. 

Depuis, je procède différemment. Je propose de choisir parmi plusieurs thèmes ou je laisse émerger un thème de l’assemblée (soit en séance, soit en préparation à l’aide d’un sondage ou d’une boite à idée). 

Pour l’anecdote, le thème que j’avais proposé concernait la qualité de notre automatisation. Bien que beaucoup de choses aient été automatisées, la qualité de nos scripts et de notre code de test n’était pas au RDV et faisait peser un risque sur la pérennité de cette pratique dans notre équipe. Les actions qui ont émergé de ce constat ont porté sur la réécriture, la modularisation et l’introduction d’API spécifiques pour le code de test et les scripts d’automatisation.

4.2 – Quand l’équipe est dans le déni 

Dans le cas d’une équipe qui se retrouve un peu dans le déni, j’aime bien poser la question suivante : Quel est l’éléphant qui est dans la pièce dont personne ne parle ? (ou bien une autre question impactante du même type).  

Exemples :

• La communication est mauvaise entre 2 membres de l’équipe à tel point qu’ils évitent de travailler ensemble. Et pourtant, ce sujet ne remonte jamais dans les constats.
• Du point de vue de l’équipe tout va bien, et pourtant lorsque l’on interroge les parties prenantes la qualité n’est pas au niveau attendu et les délais sont inacceptables.

Au bout d’un certain temps, où les sessions commencent toutes par une question impactante, la question peut même devenir celle-ci : A votre avis, quelle est la question que je vais vous poser ? (Merci Kervin pour l’idée). Ceci dans le but d’inviter les membres de l’équipe à faire leur propre prise de recul.

Quel autre moyen pouvez-vous imaginer pour sortir une équipe de son déni ?

4.3 – Quand l’équipe se sent « coincée » 

Dans certains cas, c’est surtout du contexte que viennent les difficultés. L’équipe peut alors avoir l’impression d’être coincée et que rien n’est possible. 

L’atelier Fearless Journey est très utile dans ce cas, car il apporte à l’équipe des stratégies à essayer sous forme de 75 cartes. De plus, la forme de l’atelier donne envie de réfléchir à toutes les manières dont ces stratégies peuvent s’appliquer à la situation. 

Cet atelier est particulièrement utile pour une équipe de managers ou des personnes dont l’activité se situe dans la couche de coordination, au niveau de l’entreprise. 

En plus de tout ça, je laisse toujours un minimum de temps, au début, pour que chacun ait l’opportunité d’exprimer ses ressentis de manière ouverte afin de garder un équilibre entre les séquences guidées et la prise de parole libre. 

5. Un temps nécessaire pour un partage des ressentis

Il me semble important de commencer une rétro par un temps où chacun est libre de partager ses ressentis sans jugements. Nos émotions sont des éléments importants à prendre en compte et à partager dans notre analyse de la situation. 

C’est sûr que ce n’est peut-être pas si simple pour tout le monde, dans le contexte de l’entreprise où on a l’habitude de mettre un couvercle sur ses émotions. 

5.1 – L’aide précieuse du photolangage 

Une approche qui donne de bons résultats, le photolangage où j’invite chacun à choisir une image pour illustrer son vécu sur la période qui s’achève. Le partage est souvent plus intéressant et plus profond sous cette forme. 

💡Variante 1 : on peut choisir une chanson à la place d’une image 

💡Variante 2 : en mode empathique, on peut essayer de deviner pourquoi notre voisin de gauche a choisi cette image (pour cette pratique un certain niveau de sécurité psychologique est nécessaire). 

5.2 – Un partage anonyme pour esquiver de multiples biais 

Notre cadre de travail peut être aussi bienveillant que possible ça ne suffira peut-être encore pas. En effet, c’est notre propre rapport à l’erreur et à nos émotions qui intervient ici. Notre histoire personnelle, nos succès et nos échecs passés comptent aussi. 

Il y a de multiples biais individuels et collectifs qui peuvent être convoqués ici. 

A ce sujet, j’ai participé à une excellente expérience apprenante sous forme d’un atelier animé par Damien Roquel « Droit à l’erreur, enjeu personnel ou d’organisation ? » lors de la conférence Agile Tour Rennes 2024. 

Lors de cette simulation, nous avons expérimenté que partager nos ressentis de manière anonyme peut être un moyen pour esquiver un certain nombre de biais. 

5.3 – Deux questions impactantes

Pour évaluer les ressentis de manière un peu factuelle, j’aime bien poser les deux questions suivantes. Etes-vous en accord avec les affirmations suivantes : 

• Je suis fier de ce que nous avons réalisé collectivement. 

• C’est plaisant et confortable de travailler de cette façon. 

Il y a beaucoup de choses derrière ces 2 questions :  

• La qualité, le sens et l’utilité du travail, la reconnaissance pour la question sur la fierté. 

• L’ambiance, la qualité de l’écoute, la pertinence des outils à disposition, l’absence de pression excessive sur l’équipe pour le confort de travail. 

Je demande à chacun de donner son avis sur une échelle de 5 niveaux (le partage des avis peut être anonyme ou non suivant la situation de l’équipe) : 

• Tout à fait 

• Plutôt oui 

• Bof 

• Plutôt non 

• Pas du tout 

Puis, je partage l’évolution des réponses (anonymisées) sur le tableau de bord des métriques de l’équipe. Le partage de ces données en revue m’a déjà permis de déclencher des actions managériales. 

Et vous, comment encouragez-vous le partage des ressentis ? Quels sont les formats qui donnent de bons résultats ?

6. Limiter la divergence des idées pour se concentrer ce qui compte vraiment 

Au fil des années j’ai pris conscience que limiter les idées ou ajouter des contraintes dans la phase de divergence (remue-méninges) peut grandement aider à conclure dans un temps raisonnable lors de la phase suivante de convergence. Une façon qui marche bien est de limiter les participants à une idée par catégorie. Qu’est-ce qui est vraiment important pour toi ? 

Désormais, je passe moins de temps sur la phase de collectes des données et beaucoup plus de temps sur la phase d’analyse et de plan d’action. 

La première idée de solution qui vient n’est pas forcément la bonne. Que se passerait-il si on faisait autre chose ? Que se passerait-il si on ne faisait rien ? 

Dans son article, Jean Michel Diaz propose d’utiliser le modèle en double diamant (inspiré de la démarche Design Thinking) : 2 phases de divergence-convergence, 1 fois dans l’espace des problématiques et 1 fois dans l’espace des solutions. 

Evolution du déroulé typique de mes rétrospectives (exemple en minutes sur un atelier d’1h30) 

Conclusion

Dans cet article, j’ai expliqué comment ma pratique de la Rétrospective Agile a évoluée au cours du temps.

A partir de mes propres observations et expérimentations, combinées aux réflexions d’autres personnes, je vous ai partagé ce que j’ai changé depuis mes premiers pas de Scrum Master débutant naïf pour arriver à la combinaisons d’outils et de techniques de facilitation que je préfère actuellement.

Et vous comment avez-vous fait évoluer votre pratique ? Quelles techniques avez-vous abandonné ? Quelles découvertes ont fait la différence pour vous ?

Je serais très intéressé d’avoir vos retours.

Pour poursuivre votre lecture

2 nouveaux épisodes sont disponibles pour continuer cette série.

L’épisode 2 : Eviter les chausse-trappes, aborde :

• La rétro comme espace d’expérimentation et de collaboration

• Limiter les biais individuels et collectifs 

• Comment adapter le rythme et le format de l’atelier à la situation de l’équipe

L’épisode 3 : Aller plus loin, aborde :

• Le rôle délicat de l’Agile Master : guider sans imposer

• La rétro comme moyen pour prendre soin de l’équipe

• Rétrospective à l’échelle (quand plusieurs équipes sont concernées)

• Ressources et références (articles, livres, vidéos, ateliers et jeux)

The post La Rétrospective Agile 1/3 : Evolution de ma pratique appeared first on Conserto.

L’un des derniers meet-ups de l’Association Drupal France & Francophonie a eu lieu dans nos locaux et a mobilisé la communauté Drupal de Conserto. Découvrez les 3 talks de cet événement et leurs replays !

💪 Tester, c’est assurer !

Par Matthieu Jacquemin et Antony Cochet

Un focus sur les tests Kernel pour Drupal : validation de tes plugins et services, manipulation sûre de la base de données, le tout avec des exemples concrets et des astuces pratiques.

🎯 Adieu aux hooks, bienvenue aux attributs : Objectif Drupal 11 !

Par Clara Cassinat et Jordan Bettin

L’ère des attributs a débuté avec PHP8, ils deviendront la norme avec Drupal 11. Découvrez comment cette transition impactera vos projets et comment anticiper l’évolution du développement sous Drupal.

⚙️ Drupal AI : Démo et concepts

Par Mathieu Le Cain, de IOSAN

Loin de se limiter à un chat, Drupal AI permet d’intégrer l’IA générative et les RAG aux APIs de Drupal. Découvrez ses possibilités avec un exemple concret, du prompt et du code !

The post 3 talks Drupal France appeared first on Conserto.