Un dirigeant peut lancer un projet avec une idée déjà formulée : « il nous faut un CRM », « ajoutons de l’IA » ou « développons une application ». Cette intuition peut être juste, mais elle enferme trop tôt la discussion dans une technologie. L’équipe risque alors d’adapter son travail aux limites de l’outil, de reproduire une mauvaise procédure ou d’oublier les cas qui font réellement perdre du temps. Commencer par les utilisateurs ne signifie pas leur demander une liste infinie de souhaits. Il s’agit d’observer ce qu’ils cherchent à accomplir, les décisions qu’ils prennent et les obstacles qu’ils rencontrent.
Un besoin exprimé n’est pas encore le problème
« Nous avons besoin d’un nouveau logiciel » décrit une solution. Demandez plutôt ce qui déclenche la demande : dossiers introuvables, doubles saisies, retard de validation, erreurs de version ou manque de visibilité. Faites préciser qui subit la difficulté, à quel moment et avec quelle conséquence. Un problème bien formulé permet de comparer une amélioration de procédure, une configuration de l’existant, une connexion entre outils ou un développement.
Fixez un résultat observable. « Le responsable retrouve l’état et les pièces d’un dossier sans appeler trois personnes » est plus utile que « centraliser l’information ». Ce résultat donne une direction à toute démarche de digitalisation de l’entreprise. Il évite aussi de mesurer la réussite au nombre de fonctions livrées ou à la modernité de la technologie choisie.
Observer le travail réel, y compris ses raccourcis
Les procédures écrites racontent souvent le parcours prévu. Les utilisateurs connaissent le parcours réel : le fichier temporaire créé pour attendre une validation, le message envoyé parce qu’un champ ne suffit pas, la colonne ajoutée pour distinguer deux cas. Regardez plusieurs dossiers récents avec la personne qui les a traités. Demandez-lui de montrer les écrans, documents, échanges et vérifications, sans chercher immédiatement à corriger sa méthode.
Ces contournements ne sont pas toujours de mauvaises habitudes. Ils peuvent compenser une règle absente ou une exception fréquente. Si le futur outil les ignore, ils réapparaîtront à côté du système officiel. À l’inverse, certaines étapes sont conservées uniquement parce que « l’on a toujours fait ainsi ». L’observation aide à distinguer une nécessité métier d’un héritage que le projet peut supprimer.
Cartographier les décisions, pas seulement les écrans
Un écran est une représentation ; la décision est le cœur du travail. Pour chaque étape, notez qui agit, quelles informations sont consultées, quelle règle conduit au choix et quel résultat est produit. Demandez ce qui se passe lorsque les informations se contredisent ou manquent. Une application peut afficher un bouton « Valider », mais elle reste mal conçue si l’utilisateur ne dispose pas des éléments permettant de valider.
Cette cartographie révèle également les responsabilités. Une alerte doit arriver à une personne capable d’agir. Un statut doit correspondre à une situation comprise par tous. Une donnée ne devrait pas être modifiable partout sans définir quelle source fait foi. En clarifiant ces points avant le choix technique, l’entreprise évite de transformer une ambiguïté d’organisation en règle informatique difficile à changer.
Traiter les exceptions dès le cadrage
Les démonstrations de logiciels utilisent des cas complets. L’activité quotidienne apporte des pièces absentes, des doublons, des clients particuliers, des urgences ou des validations refusées. Choisissez un dossier normal, un incomplet et un difficile. Décrivez ce qui doit être bloqué, ce qui peut continuer et ce qui exige une décision humaine. Le premier périmètre n’a pas besoin de couvrir toutes les raretés, mais il doit savoir les détecter et organiser leur reprise.
Les exceptions influencent fortement le choix. Un outil standard peut convenir si ses règles et possibilités de configuration couvrent les situations importantes. Une intégration suffit parfois à éviter une ressaisie entre deux services. Une application métier sur mesure devient pertinente lorsque des règles distinctives, des droits précis ou un parcours spécifique justifient réellement sa construction. La technologie répond alors à des constats documentés.
Faire participer sans transformer le projet en vote
Interroger les utilisateurs ne signifie pas accepter chaque préférence. Le dirigeant fixe les objectifs, les contraintes et le budget ; les utilisateurs apportent la connaissance du terrain. Nommez un responsable capable d’arbitrer et un petit groupe représentant les rôles principaux. Expliquez ce qui est décidé, ce qui reste ouvert et pourquoi certaines demandes sont reportées. Cette transparence réduit les frustrations et les ajouts tardifs.
Utilisez des supports simples : schéma du parcours, exemples de dossiers, prototype cliquable ou tableau des règles. Faites réaliser une tâche, puis observez les hésitations. La question « aimez-vous cet écran ? » produit des opinions ; la consigne « retrouvez le dossier à relancer et expliquez votre décision » révèle si la conception soutient réellement le travail. Conservez les retours liés à un objectif précis plutôt qu’une liste de goûts contradictoires.
Choisir la technologie après un test limité
Une fois le problème cadré, comparez les options avec les mêmes scénarios. Testez les cas réels dans un logiciel existant, évaluez les API si plusieurs outils doivent dialoguer et construisez un prototype seulement sur le parcours prioritaire. Examinez aussi les droits, les exports, le coût d’exploitation, la maintenance et la possibilité de changer de prestataire. Une solution rapide à installer peut devenir difficile à faire évoluer si les données restent prisonnières.
Le premier lot doit produire une valeur utilisable sans attendre la vision complète. Prévoyez les critères d’acceptation, les données de test, la formation et le retour à l’ancienne méthode si un incident survient. Après le lancement, mesurez le parcours : délai, reprises, erreurs, compréhension et usage réel. Si les utilisateurs continuent à travailler ailleurs, ne concluez pas trop vite à une résistance au changement ; recherchez la fonction, l’information ou la confiance qui manque.
Commencer par les utilisateurs est donc une discipline de réduction du risque. L’entreprise choisit moins vite un outil, mais elle choisit avec de meilleures questions. Elle sait quel problème résoudre, quel parcours tester et quelles exceptions maîtriser. Logiciel, automatisation, IA ou développement deviennent des moyens comparables, et non le point de départ qui dicte le projet.