Ce que gérer une entreprise agricole m'a appris sur l'expression de besoin
Pendant plusieurs années, j’ai co-dirigé une entreprise de remise en forme pour chevaux en Bretagne. Pas vraiment le CV classique d’un consultant tech. Et pourtant, c’est là que j’ai appris l’essentiel de ce que je sais aujourd’hui sur l’expression de besoin.
Pas dans un cours. Pas dans un livre. Sur le terrain, les bottes dans la boue — au sens propre.
Le besoin ne ressemble jamais à ce qu’on imagine depuis un bureau
Quand on gère une structure agricole, on se rend vite compte d’un truc : les gens qui conçoivent les outils n’ont jamais mis les pieds dans ton quotidien.
Avec ma femme, on avait un cahier. Un simple cahier dans lequel on notait tout : le travail de chaque cheval, les livraisons, les pépins de santé. Ça marchait. Mais on s’est dit qu’il fallait passer au numérique — pour la pérennité des données, pour pouvoir chercher, croiser, ne rien perdre. Intention louable.
On a pris le logiciel le plus complet possible. Résultat : tout saisir était trop long, trop fastidieux. L’interface n’avait pas été pensée pour des gens qui enchaînent les soins et les séances, les mains pas toujours libres, la tête déjà au cheval suivant. L’abonnement qu’on payait ne réglait aucune douleur — il en ajoutait une. L’adoption a été un échec. On est revenus au cahier.
Le logiciel n’était pas mauvais. Il ne répondait juste pas à notre réalité.
Aujourd’hui, quand je cadre un besoin, je commence toujours par aller voir. Observer. Poser des questions qui n’ont rien de technique. C’est quoi votre journée type ? Qu’est-ce qui vous agace ? À quel moment vous bricolez un contournement parce que l’outil ne suit pas ?
Les meilleurs cadrages ne naissent pas d’un atelier en salle de réunion. Ils naissent de la friction du réel.
Ce qui compte, c’est ce qui se passe quand ça déraille
En élevage, tu ne gères pas des scénarios nominaux. Tu gères des imprévus. Un cheval qui ne réagit pas comme prévu, un fournisseur qui décale, une météo qui bouleverse le planning. Le quotidien, c’est l’exception.
Dans l’expression de besoin, c’est pareil. Le chemin “tout va bien” prend dix lignes à décrire. Les vrais enjeux sont dans les cas limites, les erreurs, les exceptions. Que se passe-t-il quand l’utilisateur perd sa connexion à mi-parcours ? Quand les données arrivent incomplètes ? Quand deux personnes modifient le même enregistrement en même temps ?
J’ai vu trop de projets où l’expression de besoin décrit parfaitement le scénario idéal — et ignore tout le reste. Ce “reste”, c’est 80 % du vécu utilisateur.
Les gens ne te disent pas ce dont ils ont besoin — ils te montrent ce qu’ils font
Demande à un éleveur ce qu’il veut comme outil, il te répondra “un truc simple”. Ça ne t’avance pas beaucoup. Mais regarde-le travailler une matinée, et tu verras le tableau blanc dans l’écurie, le groupe WhatsApp avec le véto, les photos envoyées à la volée aux propriétaires pour donner des nouvelles.
Nous, c’était ça. On partageait des photos et des vidéos des chevaux avec leurs propriétaires — par SMS, par mail, par WhatsApp, un peu partout. Un outil qui aurait centralisé tout ça aurait changé notre quotidien. Même chose pour les dossiers vétérinaires : quand il fallait transmettre un historique, c’était la chasse au trésor. Le rapport du véto, les clichés radios, les ordonnances, les protocoles de soins — tout ça éparpillé entre des mails, des papiers et des photos dans le téléphone.
Personne ne nous aurait dit “on a besoin d’un outil de centralisation documentaire”. Et pourtant, c’était exactement ça, le besoin.
C’est ça, le matériau brut d’une bonne expression de besoin. Pas ce que les gens déclarent vouloir — ce qu’ils font réellement, avec les moyens du bord. Chaque bidouillage est un besoin qui n’a pas encore trouvé sa réponse.
L’expression de besoin n’est pas un livrable, c’est une conversation
Le truc qui m’a le plus marqué dans la gestion d’une entreprise à deux, c’est qu’un plan ne survit jamais au contact du réel. On ajustait en permanence. On discutait, on testait, on corrigeait.
L’expression de besoin devrait fonctionner pareil. Un document figé de quarante pages que personne ne relit après la signature, ça ne sert à rien — sinon à couvrir juridiquement celui qui l’a écrit.
Je préfère une expression de besoin vivante : courte, claire, versionnée, et surtout discutée. Un support de conversation entre ceux qui construisent et ceux qui utilisent. Pas un mur entre les deux.
Le fond du sujet
Je ne dis pas que tout le monde devrait aller gérer une exploitation agricole avant de cadrer un projet. Mais je dis que la distance entre “comprendre la technique” et “comprendre le métier qu’on sert” est le vrai fossé dans nos projets IT.
Les meilleures expressions de besoin ne sont pas les plus détaillées. Ce sont celles qui prouvent que quelqu’un a pris le temps de comprendre le problème avant de décrire la solution.
C’est ce que les chevaux m’ont appris. Entre autres.