Une demande décrit souvent une solution : un nouvel outil, une réunion ou une formation. Pour travailler utilement, cherchez le problème auquel cette solution est censée répondre. Qui rencontre la difficulté ? À quel moment ? Quel effet observable faudrait-il améliorer ? Notez séparément les faits, les interprétations et les informations manquantes.
Formulez ensuite un résultat du point de vue du bénéficiaire. « Trouver le document valide sans demander à trois collègues » est plus vérifiable que « moderniser le partage ». Comparez plusieurs façons de répondre au besoin, y compris une adaptation du fonctionnement actuel. Avant d'engager du temps ou de l'argent, définissez ce qui permettra de vérifier l'utilité du choix.
Un exemple fictif
Cas fictif : Léa demande un nouveau logiciel pour retrouver les contrats. Son équipe constate surtout des noms de fichiers incohérents. Elle teste un classement commun avant de décider si un autre outil est nécessaire.
La méthode pas à pas
Construisez une fiche de besoin en cinq rubriques : utilisateur, moment de difficulté, conséquence, résultat attendu et contrainte. Dans chaque rubrique, indiquez ce que vous savez et ce qui reste supposé. Ne partez pas d’une liste de fonctionnalités. Demandez plutôt une description de la dernière situation où le problème est apparu. Comparez ensuite une modification du processus, un outil et une clarification de rôle. Pour chaque option, notez ce qui pourrait invalider son intérêt. Le critère final doit être visible par le bénéficiaire, pas seulement par le concepteur.
Votre exercice
Écrivez une demande réelle ou fictive. Reformulez-la en problème, bénéficiaire et résultat observable. Proposez deux solutions différentes et une information à vérifier avant de choisir.
Atelier d’application
Atelier fictif : une petite équipe veut créer une application de réservation. Les demandes arrivent par trois canaux, certaines sont traitées deux fois, et les usagers ne savent pas si leur place est confirmée. Le budget est limité. Produisez une fiche de besoin, deux options et un premier test. Vous ne pouvez pas supposer qu’une application résoudra les doublons sans changer les responsabilités.
Voir une correction possible
Une correction possible définit le besoin comme une confirmation fiable, avec une référence de demande et un responsable de traitement. L’équipe peut d’abord essayer un registre partagé et un message de confirmation. Elle mesure les doublons et les demandes sans réponse sur une période définie. Une autre option serait un formulaire, mais il doit aussi prévoir le suivi. Le choix dépend des résultats, des accès et de la charge créée, pas du caractère plus moderne de l’interface.
Plusieurs réponses peuvent convenir si les choix respectent le besoin et les limites du cas. Gardez vos fiches pour le travail de synthèse.