Ce que vos développeurs ne voient jamais (et qui change tout)

Article inspiré de notre échange avec Frédéric Leguédois dans le podcast On part en prod.

Lien vers l'épisode complet :

Une équipe développe une application mobile pour des techniciens terrain. L’application est bien construite, les parcours sont réfléchis, la recette est passée. Et puis les retours commencent à remonter. Pas un appel direct, pas un bug report. Plutôt des bruits de couloir. L’application n’est pas adaptée. Elle n’est pas ergonomique. C’est trop lent. C’est mal pensé. Les retours sont diffus, contradictoires et l’équipe de développement a du mal à comprendre ce qui ne va pas. Sur son poste de travail, tout fonctionne bien.

Il faudra du temps pour réaliser que le problème n’a rien à voir avec le code. Le technicien est debout, il porte des gants, il travaille sur un petit écran de téléphone renforcé, avec du réseau intermittent. Ce que l’équipe a conçu depuis un bureau calme ne survit pas au contact du réel.

Ce type de scénario, on le rencontre régulièrement. Et dans la plupart des cas, la cause n’est ni un problème de compétence, ni un problème de budget, ni un problème de méthode. C’est un angle mort : personne dans l’équipe de développement n’a mis les pieds là où le logiciel est utilisé.

Le réflexe qui aggrave le problème

Dans notre épisode de On part en prod, Frédéric Leguédois pose un principe simple : face à un problème, le réflexe de toute organisation est d’ajouter. Un contrôle supplémentaire, un comité de validation, une étape dans le process, un nouveau document. Chaque ajout complexifie, et chaque complexité crée de nouvelles sources de problèmes.

On retrouve exactement ce mécanisme dans la relation entre les équipes de développement et les utilisateurs.

Un développement ne correspond pas aux attentes ? On rédige une spécification plus détaillée. Les spécifications ne suffisent pas ? On ajoute un proxy Product Owner. Les allers-retours prennent trop de temps ? On crée un comité de validation. Les validations passent mais le résultat n’est pas au rendez-vous ? On ajoute une étape de recette.

A chaque déception, une couche supplémentaire. Le développeur se retrouve de plus en plus loin de l’utilisateur, séparé par des intermédiaires qui filtrent, reformulent, et parfois déforment l’information. Les surprises à la livraison ne diminuent pas. Elles augmentent.

Trois histoires qui reviennent toujours

Frédéric raconte l’histoire d’une équipe qui avait développé un logiciel de dessin de plans pour un laboratoire. Plusieurs itérations avec les utilisateurs, des démonstrations régulières, des retours plutôt positifs. La livraison se passe, et le responsable appelle, furieux. Le logiciel est inutilisable. L’équipe prend la voiture, se rend sur place, et découvre le problème. Les utilisateurs, ceux qui font des plans toute la journée, avaient les plus petits écrans de l’entreprise. Pourquoi ? Parce qu’ils étaient fâchés avec le service informatique, qui avait renouvelé tous les écrans sauf les leurs. Aucun document de cadrage n’aurait capturé cette information. Il fallait être sur place.

Chez exFabrica, nous avons eu une situation comparable. Une équipe conçoit une application pour les opérateurs d’une usine. Tout va bien sur le papier : les écrans sont propres, les parcours utilisateurs sont pensés. Puis on décide d’aller simuler l’utilisation sur site avec une première version testable de l’application. On sort le téléphone, on commence le parcours. Scanner un barcode ici, aller scanner un tag RFID là-bas. Et on se rend compte qu’entre deux opérations, il y a 200 mètres de marche dans l’usine. La proportion d’un site industriel, ça ne rentre pas dans un user flow dessiné sur Figma. On a dû tout repenser.

Frédéric en raconte une autre, toujours en milieu industriel. Un système de production sophistiqué, avec impression d’étiquettes. Tout est testé en laboratoire avec des machines réelles. Le jour de l’installation en atelier, la production s’effondre. Pas à cause du logiciel : l’imprimante est au bout du couloir. Les opérateurs lancent leurs impressions, mais chacun change le format de papier. Le premier met ses étiquettes, le second change le format, le premier relance et tout sort sur les mauvais formats. Des produits de haute technologie, bloqués par un problème d’imprimante à 30 mètres.

Ces trois histoires ont le même schéma. Un projet techniquement abouti qui échoue au contact du réel. Et dans les trois cas, la solution n’était pas d’ajouter une étape de validation. C’était d’aller sur le terrain, plus tôt.

Moins d’intermédiaires, plus de compréhension

Envoyer le développeur sur le terrain, ce n’est pas ajouter une pratique dans un processus. C’est en retirer. C’est le même principe que Frédéric applique partout dans notre conversation : au lieu d’empiler des couches entre le problème et la solution, on en supprime. On raccourcit la chaîne. On connecte directement celui qui construit avec celui qui utilise.

Nous pouvons observer quelque chose d’intéressant quand ça se produit : le développeur qui voit l’utilisateur se débattre avec un outil ne revient pas avec la même posture. Il y a un mouvement de compassion assez naturel. La personne se dit « ce n’est pas possible, comment ils font pour travailler avec ça ? ». Et spontanément, elle va chercher la solution la plus simple au problème le plus douloureux. Pas la solution la plus élégante techniquement, pas la plus ambitieuse : la plus utile.

C’est aussi un antidote à l’over-engineering. Quand un développeur ne rencontre jamais ses utilisateurs, il finit par se tourner vers ce qui le motive : la technique. C’est humain. Mais quand il voit concrètement les conditions dans lesquelles son code est utilisé (les gants, le bruit, l’écran minuscule, le réseau instable), la sophistication technique perd de son attrait au profit de ce qui fonctionne vraiment.

Il y a un point qu’on sous-estime souvent : il est rare que le persona utilisateur corresponde au développeur ou au designer. On a beau rédiger des fiches persona, faire preuve d’empathie, se mettre à la place de l’autre, il y a un fossé entre imaginer les contraintes de quelqu’un et les voir de ses propres yeux. Un opérateur en usine ne travaille pas comme un développeur assis à son bureau. Un technicien sur un chantier ne manipule pas un téléphone comme nous. Ces conditions de travail changent tout dans le comportement face à l’application, et c’est presque impossible de les anticiper sans les avoir observées.

Concrètement, comment on fait ?

Il y a deux niveaux de mise en pratique, selon les contraintes de votre contexte.

Le terrain physique, quand c’est possible. C’est le meilleur cas. Sur un projet de refonte d’application mobile pour des techniciens de chantier, la première chose que nous avons faite a été d’envoyer une partie de l’équipe passer une journée complète avec un technicien sur le terrain. Pas une réunion dans une salle, pas une démonstration sur un vidéoprojecteur : une journée à suivre le technicien dans ses tournées, à voir comment il sort son téléphone, dans quelles conditions il manipule l’application, ce qui le ralentit, ce qui le frustre. Cette journée a changé la direction du projet. Des choix de conception qu’on pensait évidents se sont révélés inadaptés, et des problèmes qu’aucun document n’avait mentionnés sont devenus la priorité.

Se déplacer pour constater les conditions de travail aide à mieux concevoir l’application. C’est vrai pour les applications industrielles, mais aussi pour n’importe quel logiciel métier où l’environnement d’utilisation diffère de l’environnement de développement. Et cette compréhension du terrain ne doit pas se limiter aux Product Owners et aux designers : les développeurs doivent eux aussi saisir comment les utilisateurs interagissent avec ce qu’ils construisent.

Le terrain numérique, quand l’accès direct est compliqué. Dans beaucoup d’organisations, envoyer un développeur chez l’utilisateur final est un parcours d’obstacles. Intermédiaires, règles de sécurité, sensibilités politiques. Ce n’est pas une raison pour renoncer à comprendre comment le produit est réellement utilisé.

Vous pouvez inviter certains utilisateurs clés au revue de sprint, pour leur présenter les résultats du dernier sprint et recueillir des feedbacks terrains précieux pour alimenter votre backlog. Vous pouvez dire qu’une revue toutes les x revues est spéciale avec des utilisateurs clés en tant qu’invité.

Les solutions de session replay (Screeb par exemple) permettent de voir les sessions d’utilisation réelles. Comment l’utilisateur navigue, où il hésite, où il abandonne, quels parcours prennent trois fois plus de temps que prévu. Ce n’est pas un outil réservé au Product Owner ou au designer UX. C’est un outil à mettre entre les mains des développeurs. Quand un développeur regarde une session replay et voit un utilisateur cliquer frénétiquement sur un bouton qui ne répond pas, ou remplir trois fois le même formulaire parce que la page se recharge, il ne réagit pas de la même manière que quand il lit un ticket Jira qui dit « améliorer la réactivité du formulaire X ».

Une première étape encore plus simple : faire des tests utilisateurs sur des prototypes interactifs ou sur l’application réelle, même en visio. L’idéal est de répéter ces tests tout au long du projet, pas une seule fois en début de cadrage.

Dans tous les cas, l’objectif est le même : réduire la distance entre celui qui construit et celui qui utilise.

Autonomie et responsabilité : la vraie différence

Ce qu’on décrit ici, ce n’est pas juste une bonne pratique de product management. C’est une question d’autonomie de l’équipe de développement, un des principes fondamentaux de l’agilité.

Frédéric en parle dans notre échange : une équipe autonome, c’est une équipe qui peut décider de ses priorités, qui est capable de réagir à ce qu’elle découvre, qui n’attend pas qu’on lui dise quoi faire à chaque étape. Mais l’autonomie sans compréhension du terrain, ça ne fonctionne pas. On ne peut pas prendre de bonnes décisions sur ce qu’il faut développer, dans quel ordre, avec quel niveau de sophistication, si on n’a aucune idée des conditions dans lesquelles le produit sera utilisé.

C’est là que la responsabilité entre en jeu. Une équipe qui va sur le terrain, qui observe les utilisateurs, qui comprend leurs contraintes, cette équipe peut s’engager sur la pertinence de ce qu’elle livre. Elle ne se contente plus de développer conformément à une spécification. Elle est capable de dire « ce qu’on nous demande ne va pas résoudre le vrai problème » ou « il y a une solution beaucoup plus simple à laquelle personne n’a pensé parce que personne n’a vu le contexte d’utilisation ».

Et c’est là que l’expérience de l’équipe fait une différence qu’on ne mesure pas assez. Aller sur le terrain, c’est une chose. Savoir quoi observer, quelles questions poser, comment synthétiser ce qu’on a vu pour en tirer des décisions concrètes, c’en est une autre. Une équipe qui a déjà vécu des projets où le terrain a révélé des surprises sait reconnaître les signaux faibles. Elle sait aussi faire cette démarche sans créer de friction chez le client, parce qu’elle a appris à observer et écouter avant de juger ce qui est en place. Ce n’est pas un savoir théorique, c’est un réflexe qui se construit projet après projet.

La combinaison autonomie, terrain et expérience donne une équipe qui livre des solutions qui fonctionnent dans le réel. Pas sur un PowerPoint, pas dans une salle de démonstration. Dans l’usine, sur le chantier, derrière le comptoir.

Par où commencer ?

La prochaine fois qu’un projet dérape, avant d’ajouter une couche de spécification ou une étape de validation supplémentaire, posez-vous la question inverse : est-ce qu’on peut retirer un intermédiaire et rapprocher le développeur de l’utilisateur ?

Ça peut être une journée sur le terrain. Ça peut être un accès au session replay partagé avec l’équipe de développement. Ça peut être simplement un test utilisateur en visio, ou une conversation directe, sans filtre, entre celui qui code et celui qui utilise.

Le résultat est souvent le même : moins de malentendus, des solutions plus simples, et un produit qui fonctionne dans les conditions réelles.