Cadrer les besoins utilisateurs pour accompagner le choix d'un ERP
Comment j'ai aidé Desmazières à transformer les usages réels de ses équipes en critères de choix pour son futur ERP.
01 · Contexte
Changer d'ERP sans savoir précisément ce dont les équipes ont besoin
Desmazières produit des plants de pommes de terre et voulait remplacer son ERP par un système mieux adapté à ses processus. L'enjeu : comprendre les usages actuels, objectiver les besoins métier et faire émerger des critères fiables pour guider le choix. Les livrables devaient être joints au cahier des charges de l'appel d'offres.
02 · Problème
Un cahier des charges sans les usages réels risquait de mener au mauvais outil
Chaque équipe avait ses tâches, ses outils et ses contournements. Sans vision commune, les éditeurs d'ERP auraient répondu à une liste de fonctionnalités plutôt qu'aux vrais problèmes des utilisateurs. Le risque : choisir un ERP qui ne règle pas les difficultés du quotidien.
03 · Recherche
Faire dessiner leurs processus aux équipes elles-mêmes
J'ai préparé un protocole d'entretien fondé sur l'approche Jobs To Be Done, pour comprendre les tâches, les objectifs, les outils, les contournements et les frictions.





Le cycle de vie des équipes étant à cheval sur plusieurs années et avec des temporalités différentes, il était plus simple pour les utilisateurs de poser leurs connaissances sur papier. Cela a permis aux interviewés de rebondir et de compléter les frises au fur et à mesure des entretiens.
04 · Analyse
Synthèse et regroupement des besoins avec l'IA
Les ateliers pouvaient durer entre 1 h et 3 h selon les équipes. Le parti pris a été de les enregistrer pour les retranscrire, puis de partir de cette base pour lister et synthétiser les verbatims.




Étapes de traitement : importation de l'audio de l'atelier dans MacWhisper → exportation de la retranscription au format Google Doc → importation dans NotebookLM → sortie d'un tableau avec les verbatims, les tâches, les outils et l'équipe.
Une fois la matière synthétisée dans le tableau, j'ai complété et corrigé les erreurs et les approximations de l'IA, avant de regrouper et trier les frictions en thèmes et sous-thèmes. Cela a permis d'identifier les thèmes communs à toutes les équipes, ceux propres à chacune, et leur récurrence.
05 · Livrables
Des personæ construits par thématiques et non par équipes
Plutôt que de décrire les besoins département par département, j'ai construit 3 personæ UX à partir des besoins et des frictions communs. Chacun a donné lieu à une experience map, qui montre où l'outil actuel freine le travail.



Trois personæ construits sur les besoins et les frictions communs, et non par service : Aurélie coordonne les flux, Damien garantit la qualité et la traçabilité, Manon pilote l'activité et les relations avec les partenaires.



Une experience map par persona. Les frictions les plus fortes n'arrivent pas au même moment selon le profil : en coordination et en exécution pour Aurélie, en anticipation, coordination et contrôle pour Damien, en préparation et dans la gestion des imprévus pour Manon.
Ces supports ont servi à prioriser les besoins et à définir les critères de cadrage du futur ERP, puis ont été restitués aux équipes projet pour aligner les parties prenantes.
06 · Résultats
Des critères de choix issus des usages, joints à l'appel d'offres
- Participants, issus de toutes les équipes
- 15
- Ateliers, de 1 h à 3 h chacun
- 12
- D'enregistrements analysés
- 22 h
Desmazières comprend mieux les problèmes rencontrés au quotidien et dispose d'une vision commune des usages. Les livrables ont été joints à l'appel d'offres et mis à disposition des éditeurs d'ERP.

Projet suivant





