Pour découvrir les vrais besoins d’une application métier, il faut regarder les utilisateurs travailler avant de leur demander ce qu’ils veulent. L’observation terrain montre les contournements, les ressaisies et les cas particuliers que personne ne pense à citer en réunion ; les ateliers collectifs permettent ensuite de confronter les points de vue, de cartographier les processus et de prioriser. Les deux se complètent : l’observation fournit les faits, l’atelier construit l’accord.
Ce guide explique pourquoi les réunions ne suffisent pas, comment observer sans déranger, quels ateliers organiser et comment transformer ce que l’on a vu en besoins exploitables.
Pourquoi les réunions ne suffisent-elles pas à recueillir le besoin ?
Dans beaucoup de projets, le besoin est exprimé par la direction, puis validé en réunion par quelques responsables. Le résultat décrit le processus tel qu’il devrait fonctionner, pas tel qu’il fonctionne.
Jakob Nielsen résume le problème dans un article devenu classique : pour bien concevoir, il faut prêter attention à ce que les utilisateurs font, pas à ce qu’ils disent. Il recommande de ne pas croire ce que les personnes disent faire, et encore moins ce qu’elles prédisent qu’elles feront. Ce n’est pas de la mauvaise foi : une tâche répétée cent fois devient invisible pour celui qui l’exécute.
Trois catégories d’information échappent presque toujours aux réunions :
- les contournements : le fichier Excel tenu « à côté », les notes adhésives sur l’écran, le coup de téléphone systématique avant de valider une commande ;
- les cas particuliers : le client qui paie en trois fois, la livraison partielle, le produit sans code article ;
- le contexte physique : des gants qui empêchent d’utiliser un écran tactile, un entrepôt sans réseau, un comptoir où l’on est interrompu toutes les deux minutes.
Ce sont précisément ces éléments qui font qu’un nouvel outil est adopté ou contourné, comme nous l’expliquons dans notre article sur la conduite du changement.
Qu’est-ce que l’observation terrain, concrètement ?
Une étude de terrain est une recherche menée là où les utilisateurs travaillent réellement, et non dans une salle de réunion. Le Nielsen Norman Group en distingue plusieurs formes, des plus discrètes aux plus immersives.
| Méthode | Principe | Quand l’utiliser |
|---|---|---|
| Observation directe | On regarde sans intervenir, en notant les gestes, le vocabulaire et les outils | Comprendre un flux de travail naturel, repérer les contournements |
| Enquête contextuelle | On observe et on interroge au fil du travail, sur le poste de l’utilisateur | Comprendre le pourquoi de chaque étape et les règles implicites |
| Visite guidée | L’utilisateur fait visiter son environnement et explique son métier | Découvrir un site, un atelier, une organisation inconnue |
| Suivi d’une journée type | On accompagne une personne sur une période longue | Processus étalés dans le temps, travail itinérant |
Pour un outil métier, l’enquête contextuelle est souvent la plus rentable. Le Nielsen Norman Group la décrit sur le modèle du maître et de l’apprenti : l’utilisateur est l’expert de son travail, l’observateur apprend en le regardant faire et en posant des questions. Elle repose sur quatre principes : observer dans le contexte réel, partager la conduite de l’échange, valider ses interprétations avec l’utilisateur, et garder un objectif de recherche précis.
Comment mener une observation sans déranger ?
Une demi-journée par personne suffit souvent pour un outil interne. Voici le déroulé que nous recommandons.
- Préparer : définir trois à cinq questions de recherche (« comment une commande urgente est-elle traitée ? »), choisir des personnes variées (ancienneté, site, équipe), obtenir l’accord des managers.
- Ouvrir : expliquer que l’on observe le processus et les outils, pas la personne ; préciser que rien ne sera rapporté individuellement ; demander l’autorisation avant toute photo.
- Regarder travailler : laisser la personne faire ses tâches réelles, sur des dossiers réels. Noter ce qui est fait, avec quel outil, et les hésitations.
- Questionner au bon moment : « pourquoi avez-vous vérifié dans ce fichier ? », « que se passe-t-il si ce champ est vide ? ». Éviter les questions qui suggèrent la réponse.
- Collecter les traces : documents papier, exports, fichiers personnels, captures d’écran anonymisées. Ce sont des mines d’informations sur les règles de gestion.
- Restituer à chaud : résumer en fin de séance ce que l’on a compris, pour que la personne corrige ou complète.
Le service public britannique, dans son manuel de conception des services, va plus loin : il recommande que tous les membres de l’équipe, et pas seulement le chercheur, observent régulièrement de vrais utilisateurs, avec un minimum d’environ deux heures toutes les six semaines. Appliqué à un projet d’entreprise, cela signifie que les développeurs et le chef de projet gagnent à passer eux-mêmes du temps au poste des futurs utilisateurs.
Quels ateliers organiser après l’observation ?
L’observation produit des faits individuels. Les ateliers servent à les confronter, à construire une vision commune et à décider. Chacun a un objectif précis.
L’atelier de cartographie du processus
On reconstitue au mur, avec des notes adhésives, le processus de bout en bout : de la demande du client à la facture, par exemple. Le format EventStorming, présenté sur eventstorming.com comme un format d’atelier flexible pour explorer collectivement des domaines métier complexes, consiste à poser les événements métier dans l’ordre chronologique (« commande reçue », « stock réservé », « livraison planifiée »), puis à faire apparaître les acteurs, les règles et les points de friction. Il est particulièrement efficace quand plusieurs services interviennent sur un même flux.
L’atelier de cartographie des parcours
On organise les activités de chaque profil d’utilisateur de gauche à droite, puis on place sous chaque activité les fonctionnalités nécessaires. Cette technique, le story mapping popularisé par Jeff Patton, a un double avantage : elle garde l’utilisateur au centre des discussions et elle permet de découper une première version cohérente en traçant une ligne horizontale sous les fonctionnalités indispensables.
L’atelier de priorisation
On confronte les besoins identifiés aux objectifs du projet et on les classe : indispensable, important, souhaitable, hors périmètre. Cet atelier réunit des utilisateurs et des décideurs, car c’est là que se font les arbitrages.
L’atelier de test des maquettes
Une fois les premiers écrans dessinés, on les fait manipuler par des utilisateurs sur des tâches réelles. C’est le sujet de notre article sur le prototype interactif.
Les erreurs qui faussent la découverte
Certaines erreurs reviennent souvent, et elles produisent des besoins biaisés.
- N’interroger que les managers. Ils connaissent les objectifs, pas les gestes. Les deux points de vue sont nécessaires.
- Choisir uniquement les volontaires enthousiastes. Ils sont précieux, mais les plus sceptiques connaissent souvent les limites réelles de l’existant.
- Observer un seul site. Deux agences d’une même entreprise ont rarement le même processus, même avec la même procédure écrite.
- Demander aux utilisateurs de concevoir l’écran. Ils sont experts de leur problème, pas de l’interface. Demandez-leur de décrire et de montrer, puis proposez des solutions à tester.
- Faire un atelier de deux heures à vingt personnes. Au-delà d’une dizaine de participants, l’atelier devient une réunion d’information. Mieux vaut plusieurs sessions ciblées.
- Ne rien restituer. Les participants qui ne voient jamais le résultat de leur contribution ne reviendront pas aux ateliers suivants.
Comment transformer ce que l’on a vu en besoins exploitables ?
La matière brute (notes, photos, documents) doit être convertie en éléments utilisables par l’équipe de développement. Nous utilisons quatre livrables simples.
| Livrable | Contenu | Utilité |
|---|---|---|
| Fiches profils | Pour chaque type d’utilisateur : tâches, contexte, outils, irritants | Concevoir des écrans adaptés à chaque usage |
| Carte du processus actuel | Étapes, acteurs, outils, ressaisies, délais | Mesurer les gains et identifier les ruptures |
| Liste des irritants priorisés | Chaque problème observé, sa fréquence, son impact | Choisir ce que la première version doit résoudre |
| Backlog initial | Besoins formulés en user stories avec exemples réels | Estimer et planifier le développement |
Les besoins issus de l’observation sont plus précis que ceux recueillis en réunion, car ils s’appuient sur des exemples vus. Ils se formulent naturellement en user stories avec critères d’acceptation et alimentent un cahier des charges solide. Ils permettent aussi de chiffrer les gains : le temps passé à ressaisir une commande, observé et mesuré, devient un argument tangible, comme le montre notre méthode pour repérer les ressaisies.
Où placer cette étape dans le projet ?
L’observation et les ateliers forment le cœur de la phase de cadrage. Ils interviennent avant toute maquette et avant toute estimation détaillée. Pour un outil interne de taille moyenne, comptez quelques jours d’observation répartis sur deux ou trois semaines, puis deux à quatre ateliers.
La recherche ne s’arrête pas là. Chaque livraison est une nouvelle occasion d’observer l’usage réel et de corriger le tir, ce qui fait partie de notre méthode de travail : démonstration à chaque sprint, retours des utilisateurs, ajustement du backlog.
Vous préparez un projet et vous voulez savoir quels profils observer et quels ateliers organiser en priorité ? Décrivez votre contexte dans notre diagnostic de projet : en deux minutes, nous identifions avec vous les zones à explorer sur le terrain.
