Dans le monde du développement de produits digitaux, la collaboration entre l’UX et le développement est souvent plus un idéal qu’une réalité. Pourtant, c’est précisément de cette synergie que naissent les produits les plus performants, ceux qui non seulement répondent aux besoins des utilisateurs, mais qui donnent aussi du sens au travail de ceux qui les créent. Cet article est un retour d’expérience sur la manière dont une collaboration renforcée entre UX et développeurs peut transformer un produit en difficulté et insuffler une nouvelle dynamique à une équipe.
Le point de départ : Un produit en péril et une équipe sous pression
Notre histoire débute avec un outil numérique essentiel pour les directeurs de magasin et responsables de rayon chez Decathlon. Conçu pour optimiser la performance économique et l’efficience des heures, cet outil s’adresse à environ 20 000 utilisateurs répartis dans 78 pays.
Depuis 2017, l’équipe travaillant sur ce produit fonctionne en silo, avec une culture agile superficielle. Les développeurs, spécialisés (front-end, back-end, data), travaillent sur des micro-tâches sans vision d’ensemble, ce qui entraîne au fur et à mesure des délais de livraison interminables et une accumulation de dettes techniques. À titre d’exemple, et l’un des déclencheur de ce qui suivra, est une fonctionnalité estimée à trois semaines qui aura pris près d’un an à être livrée (et de manière instable !!).
Du côté du produit, les problèmes étaient tout aussi criants : une adoption faible, une utilisation forcée par les utilisateurs due à l’absence d’alternatives et des pressions de la hiérarchie, et surtout, une disponibilité aléatoire. Les temps de chargement étaient excessivement longs, et l’application était fréquemment inaccessible à des moments clés, frustrant considérablement les utilisateurs. Enfin, la complexité de l’outil le rendait difficile à appréhender tant pour les nouveaux développeurs que pour les nouveaux utilisateurs. Le constat était clair : le lien entre les développeurs, le produit et les utilisateurs était fragile, voire inexistant.
La stratégie de transformation : Autonomie et connaissance
Face à cette situation critique, l’équipe Mayday, une initiative interne à Decathlon reconnue pour son approche pragmatique, est intervenue.
La solution ne pouvait pas être uniquement technique. Il fallait un pivot, une approche holistique pour rétablir l’équilibre. L’équipe renfort, composée de 4 développeurs et une UX Researcher, intervient. La stratégie s’est articulée autour de deux axes majeurs : améliorer l’autonomie de l’équipe et augmenter la connaissance des utilisateurs et du produit.
1. Développer l’autonomie de l’équipe par l’agilité et le Software Craftsmanship
L’objectif était de passer d’une culture de “projet” à une culture de “produit”, où l’équipe se sentirait pleinement responsable de la valeur qu’elle délivre.
- Nouvel alignement de l’équipe : L’équipe doit évoluer vers une culture fullstack et fulltask. L’idée est de casser les interdépendances en encourageant la polyvalence et la capacité à mener les sujets de la conception à la production.
- Renforcer la collaboration d’équipe et permettre la montée en compétence : Des sessions de pair programming sont mises en place pour partager les connaissances et les bonnes pratiques. Des revues de code collectives permettent d’uniformiser les conventions et d’améliorer la qualité du code.
- Auto-organisation des rituels d’équipe : Les rituels agiles sont revus pour retrouver leur sens. Le daily meeting devient un point sur l’avancement des livrables en production plutôt qu’un simple rapport de tâches. Des rétrospectives régulières permettent de déceler et résoudre les problématiques d’équipe. Un atelier de backlog refinement est programmé de façon hebdomadaire, pour spécifier et évaluer la maturité des sujets à développer.
- Intégration d’un Product Owner (PO) avec une vision 360 : Un nouveau PO a rejoint l’équipe, apportant une vision globale intégrant les besoins utilisateurs, les contraintes réglementaires et la stratégie d’entreprise. Son rôle est devenu crucial pour canaliser et arbitrer les demandes, apprendre à dire “non” si nécessaire, et prioriser les développements avec l’équipe.
- Les “enablers” du flow : Des pratiques comme le WIP limit (limiter le travail en cours) et l’approche “Stop starting, start finishing” permettent de se concentrer sur l’achèvement des tâches. Comme précédemment évoqué, le pair-programming favorise le partage de compétences et la complémentarité.
- Livraison continue : La simplification des branches de code (trunk-based development) et l’automatisation des tests (passant d’un mode manuel à quasi-totalement automatisés) ont considérablement réduit le time to market, permettant des livraisons plusieurs fois par jour si nécessaire. C’est la “non-event delivery”, où l’outillage permet un déploiement fluide du poste du développeur à l’utilisateur.
2. Augmenter la connaissance des utilisateurs et du produit
Le rôle de l’UX researcher a été central pour imprégner l’équipe de la réalité des utilisateurs et pour comprendre le produit de l’intérieur.
- Immersion directe avec les utilisateurs : La première action a été d’organiser des interviews utilisateurs auxquelles les développeurs étaient conviés. Cette écoute directe a permis de créer une connexion et de donner du sens au travail de chacun.
- Mise en place d’analytics d’usage : Avant l’intervention, aucun outil d’analytics n’était en place. Des traceurs ont été déployés pour comprendre le comportement réel des utilisateurs sur le produit. Un atelier de nomenclature accessible a eu lieu pour que chacun, y compris les développeurs, puisse consulter et interpréter ces données.
- Suivi de l’état de la production : Au-delà des analytics d’usage, un tableau de bord a été créé en équipe pour suivre les erreurs et les taux de disponibilité de la production. Cela a permis à l’équipe de comprendre l’état de santé du produit et de prendre des décisions éclairées, par exemple en identifiant si les problèmes venaient de l’équipe ou de partenaires externes.
- Démarche de Design Thinking enrichie : L’approche s’est basée sur un modèle de Design Thinking amélioré, intégrant l’ensemble de l’équipe à chaque étape :
- Compréhension des besoins : Interviews, analytics.
- Validation et scoping : Formalisation des insights, partage avec toute l’équipe.
- Idéation et construction : Ateliers collaboratifs avec l’équipe (worst ideas, crazy eight, brainstorming, feature values, …).
- Modélisation et tests continus : Mise en place de tests A/B pour comparer deux versions du produit et observer les statistiques d’utilisation. Le feature flag a permis de proposer une version spécifique du produit à un échantillon d’utilisateurs pour recueillir des retours qualitatifs. La collaboration UX-Dev est ici essentielle, les développeurs réalisant les modifications d’interface et l’UX guidant ces changements et gérant les échanges avec les utilisateurs.
L’objectif pour l’UX n’est pas de se rendre indispensable, mais de faciliter les retours terrain et de faire en sorte que rechercher des réponses auprès des utilisateurs devienne un réflexe pour tous les développeurs. Il s’agit de s’assurer que la viabilité (par les stakeholders), la faisabilité (par les développeurs) et la désirabilité (par l’UX) soient prises en compte dès le début du processus.
Les premiers résultats : Un produit et une équipe transformés
Les actions menées ont eu un impact profond sur l’équipe et le produit.
D’une équipe qui réalise des tâches, on passe à une équipe qui apporte de la valeur et donne du sens à son travail quotidien. Elle a des interactions directes avec ses utilisateurs, et est armée pour challenger les besoins remontants plutôt que de n’être qu’une simple exécutante. Le time to market a été considérablement réduit. L’équipe n’est plus seulement plusieurs individus qui travaillent côte à côte, mais des personnes qui communiquent et collaborent au quotidien pour prendre des décisions éclairées.
D’un produit qui ne tient pas la charge de trop nombreux utilisateurs, on passe à un produit disponible à tout moment. Alors qu’on essayait d’adresser un peu tout le monde en apportant finalement peu de valeur à chacun, on apporte désormais une valeur certaine aux cibles prioritaires identifiées. Le produit devient finalement beaucoup plus facile à appréhender pour les développeurs comme pour les utilisateurs.
La collaboration UX-Dev : Un levier d’arbitrage et de sens
En conclusion, la transformation de l’outil et de son équipe est le résultat d’un travail combiné. Des actions côté développeurs ont renforcé leur autonomie (cadrage des rituels, amélioration du backlog, support utilisateurs, livraison continue, feature toggle). Des actions côté UX ont augmenté la connaissance (audit, observations, interviews, personae, parcours). Mais c’est la collaboration étroite et continue entre UX et développeurs, au travers d’ateliers conjoints, d’analyse d’analytics partagée et de tests (A/B testing, feature flag), qui a permis de donner du sens à toutes ces actions.
Cette collaboration est essentielle pour les arbitrages. Il ne s’agit pas de “tout faire”, mais de choisir ses combats avec une connaissance globale du projet et du produit. Qu’il s’agisse d’adapter le niveau de support, de décider de la qualité du code ou de prioriser les bugs, ces décisions sont prises avec une compréhension mutuelle des enjeux techniques, utilisateurs et business.
Nous n’avons rien inventé, mais nous avons mis en œuvre les bonnes pratiques de l’agilité et du Software Craftsmanship. Le plus important est de s’être concentré sur le fond et non seulement sur la forme. Donner du sens à chaque décision, à chaque ligne de code, à chaque interaction utilisateur, c’est ce qui transforme un projet en un produit performant et une équipe en un moteur d’innovation. C’est en faisant en sorte que la recherche de réponses auprès du terrain devienne un réflexe pour tous les développeurs, et en intégrant la faisabilité technique dès la conception, que l’UX et le Dev peuvent réellement collaborer pour construire des produits qui comptent.

Florine Auffrait, UX Researcher chez UX-Republic



