Au début d’un projet logiciel, le travail le plus utile consiste à expliquer le problème avant de dresser la liste des écrans. Un même problème peut avoir plusieurs réponses : mieux configurer un outil existant, modifier le processus ou développer une nouvelle application.

Quelle tâche est difficile aujourd’hui ?

Au lieu de dire « nous avons besoin d’un panneau d’administration », décrivez les tâches qui font perdre du temps. Une équipe peut, par exemple, suivre les demandes dans des fichiers séparés et effectuer deux fois le même travail. Le besoin porte alors sur des dossiers partagés, des responsabilités claires et des informations à jour, pas seulement sur un écran.

Notez la fréquence du problème et les personnes concernées. Une courte tâche hebdomadaire n’a pas nécessairement la même priorité qu’un travail répété toute la journée. Si possible, décrivez simplement les étapes actuelles.

Qui utilisera la solution ?

Les intitulés de poste ne suffisent pas à décrire les utilisateurs. Pensez au lieu de travail, à l’appareil utilisé et aux informations nécessaires. Une personne sur le terrain avec un téléphone peut avoir des attentes différentes d’une personne devant un grand écran au bureau.

Une personne peut créer une demande et une autre l’approuver. Cette distinction compte pour les droits d’accès et le déroulement du travail. Demandez-vous dès le départ si chacun doit voir toutes les informations.

Qu’est-ce qui est indispensable dans la première version ?

Limitez le périmètre initial aux tâches qui résolvent le problème principal. Séparez les fonctions nécessaires, celles qui pourront venir plus tard et les éléments hors périmètre. Il ne s’agit pas de dévaloriser une fonction, mais d’établir un ordre.

Par exemple, un registre partagé des demandes et le suivi de leur statut peuvent être indispensables, tandis que des rapports détaillés peuvent attendre. Ce choix permet d’observer plus tôt l’utilisation réelle par l’équipe.

Comment reconnaître un travail terminé ?

« Facile à utiliser » est une attente compréhensible, mais peu mesurable à elle seule. Pouvoir créer une demande, la rendre visible à une personne autorisée et enregistrer un changement de statut sont des conditions d’acceptation plus concrètes.

Décrivez quelques situations de travail réelles dès le début. Elles aideront ensuite à vérifier si la solution répond aux attentes.

Que préparer pour le premier échange ?

Une brève description du problème, un résumé du processus actuel et les principales priorités constituent un bon départ. L’absence de cahier des charges technique n’empêche pas la discussion. Rendez les inconnues visibles plutôt que de les cacher.

Ces informations donnent une base plus pertinente au choix technologique. Le premier objectif est de comprendre ensemble le bon problème et ses limites, plutôt que de demander le plus grand nombre de fonctions.