Souvent les développeurs sont connu pour parler énormément de technique, quel langage, quel outil, quelle performance… Même entre eux d'ailleurs il n'est pas rare d'entendre des débat de pourquoi telle techno serait meilleure qu'une autre, a un point qu'on se sent même un peu inférieur si l'on n'est pas vraiment capable d'avoir de répartit dans ce type de débat.
Pourtant, dans la réalité, ce n’est pas ça qui fait la différence. De manière générale aujourd'hui la pluspart des techno un tant soit peu récente permettent de répondre a 90% des projets client donc en vrai, il est très rare que le choix ai un réel impact sur votre client final.
Pour moi la vrai différence se faite ailleurs, sur la compréhension du terrain.
Parce qu’un outil peut être parfaitement fonctionnel, hyper performant… et pourtant complètement à côté de la manière dont l'utilisateur travaille au quotidien.
Le problème : des outils pensés sans le terrain
Trop souvent, les outils ont été conçus de manière assez “descendante”. On part d’un besoin global, on fait des maquettes, on développe… puis on livre.
Et ensuite ?
Sur ce bouton, tu cliqueras
On explique au client comment utiliser l’outil “Clique ici, fais ça comme ça”, entre tech, on râle un peu parce que le client ne suit jamais le cheminement qu'on avait prévu "mais pourquoi il est passé par là". A la fin, on finis avec un outil utilisé qu'à moitié s'il ne finis pas totalement aux oubliettes et une équipe tech frustrée. C'est assez caricatural, mais j'en parle avec autant d'assurance que j'ai moi même fait partie dans le passé de ceux qui alors qu'on leur remontant un bug disaient "mais pourquoi il a été cliquer ici" ou encore le fameux "c'est normal il ne fallait pas passer par là". Le pire, c'est qu'on est plutôt plein d'assurance à ce moment là.
Et d'ailleurs, les utilisateurs de logiciels s'y sont tellement habitué qu'encore récemment lorsque je sortait une fonction dans un outil d'un client, je lui dit "c'est bon c'est disponible tu peux t'en servir". Il teste, puis me dit "ça ne m'affiche pas ce que je voulais".
J'avais testé ce que je faisait, j'était relativement sûr que l'outil faisait exactement ce qui m'avait été demandé 30mn avant. Pour comprendre je demande donc "par ou es tu passé pour y arriver ?". Il m'explique.... forcément ce n'était pas le chemin que j'avais prévue, le comprenant, dessuite il me dit "C'est pas grave dit moi par ou passer je m'adapterais". Et bien non je ne lui dirait pas ! Parce qu'en fait, il m'a donné une information précieuse, le cheminement qui était le plus naturel pour lui, celui qu'il allait faire sans avoir a réfléchir ne serait ce qu'une seconde, alors le vrai chemin, ce sera celui là !
C'est l'outil qui s'adaptera, pas l'humain, sinon ce n'est pas du sur mesure.
(Alors bien sur, ça ne veux pas dire qu'il faut basculer dans la clan des "Oui oui", il faut tout de même réfléchir pour garder une certaines logiques etc. mais quand ça fait sens, la meilleure solution, c'est celle qui est naturelle pour l'utilisateur final)
Comprendre avant de construire
Avec les ajustements, on peut faire énormément de choses pour corriger le tir et petit a petit épouser le quotidien de l'utilisateur comme si on en avait toujours fait partie, c'est d'ailleurs pour ça que j'essaie d'en prévoir pas mal. Mais si on veux éviter d'avoir un lancement chaotique suivit de mois et de mois de retours, il faut avoir une bonne vision du terrain avant d'attaque l'outil. Comprendre la manière dont vous travaillez.
Quand c’est possible, je viens sur place. Je regarde comment les choses se passent vraiment. D'une part, c'est toujours ultra passionnant, j'adore découvrir de nouveaux métiers. Mais surtout, ça me permet de comprendre dans quel univers va réellement évoluer l'outil, voir ce qui est tellement logique que vous ne le direz pas, comprendre ce que vous faites, pourquoi vous le faites comme ça, quelle est le but recherché dans vos actes, qu'est ce qui est complexe, qu'est ce qui est chronophage, qu'est ce qui est répétitif. Dans quelle condition c'est utilisé.
Tout ça permet d'avoir une meilleur compréhension de la base pour adapter l'outil. Je me rappelle par exemple il y a quelques années j'ai travaillé sur un site de presse régionale. A l'époque, dans la société ou j'était, les techniques n'allaient pas vraiment passer de temps en immersion en amont. On a passé énormément de temps a faire le site, le jour de la sortie, on était assez fier de voir le bébé sortir, et puis soudain une question innocente du client :
Comment je fait pour voir les analytics de mon article ?
En fait, ce truc qui nous semblait relativement futile et qu'on pensait pouvoir ajouter sans urgence, on était en train de découvrir qu'au contraire c'était le coeur même de leur métier. On nous expliqua alors "Quand on publie un article, ensuite on passe plusieurs minutes les yeux rivés sur les stats, en fonction du nombre de clics, on modifie le titre jusqu'à ce que ça décolle". Si on avait passé ne serait ce que 1heure avec un journaliste a le regarder travailler, on aurait repéré ça en amont, mais là on a était obligé de le corriger dans l'urgence.
Pour que cet exemple reste enfouis comme un souvenir du passé, aujourd'hui le terrain fait partie intégrante de mon analyse. J'essaie autant que faire se peut d'avoir les retours des différentes personnes qui vont interagir autour de l'outil. Ainsi dans un projet récent pour une agence de conférencier, j'ai interrogé l'un des conférencier pendant 30 mn pour comprendre son quotidien, ses problématiques. Très vite, on comprend que si une partie de la demande est plutôt en phase avec ce que l'agence de conférencier commanditaire de l'outil demandait, quelques points de vigilances nouveaux apparaissent "Il peut arriver que je soit contraint d'arriver à l'accueil de l'hôtel, après les check-ins officiels avec juste un gardien de nuit qui n'a pas (ou difficilement) accès aux informations de paiement, si je n'ai pas la preuve de paiement, je vais perdre une demie heure".
Adapter l’outil, pas l’utilisateur
C’est là que ma manière de travailler diffère souvent des habitudes du monde du développement. Aujourd'hui avec l'IA, on peut en quelques minute faire des ajustements qui changent tout pour l'utilisateur. Basculer une action sur un autre bouton, rajouter une logique pour la rendre plus intelligente et plus en phase avec la demande. Du coup quand je lance un projet aujourd'hui, je prévoie volontairement du temps pour permettre de faire une grosse quantité de retours. A mesure que ces itérations se font, l'outil se rapproche de plus en plus du besoin du client. Au début, le client n'ose pas trop dire, ne sais pas trop quelle est la limite, puis petit à petit il prend confiance et ose. Il comprend que je ne suis pas la pour le brider. Sur mon premier projet, je ne communiquais pas encore assez dessus, je me rappelle 2 semaines après le lancement, on fait un point avec la cliente et elle m'avoue être un peu en retrait sur ce point et na pas oser trop me faire de retour car elle avait l'impression d'en avoir déjà fait pas mal (il faut dire qu'en réalité son outil était déjà largement plus avancé que ce qui avait été prévue au départ et sans surcout). En fait, ce qu'elle ne savait pas, c'est qu'au contraire, j'adorait ses retours parce qu'a chaque fois qu'elle en faisait, je voyais non pas le temps que ça allait me prendre (souvent négligeable grâce à l'IA) mais plutôt le gain qu'elle allait avoir elle au quotidien et la qualité de l'outil qui allait encore augmenter.
Et quand je voie comment même un développeur, qui est sensé être a l'aise avec l'informatique et avoir une compréhension accéléré des interfaces, peut parfois avoir du mal a trouver ses informations sur certains sites je me dis qu'on part de loin. Pourtant l'effet que ça procure :agacement, perte de temps pour des résultats dégradés montre bien qu'on marche sur la tête. Je me répète :
Arrêtons de s'adapter à l'outil, c’est à l’outil de s’adapter à vous.
On a tous pris l’habitude de s’adapter :
apprendre un logiciel
retenir des manipulations
contourner ce qui ne fonctionne pas
Alors que ce sont justement ces points-là qu’on peut améliorer. Surtout sur un outil ou on passe la totalité de ses journées. Comment peut on avoir la banane et être agréable avec nos clients et collègue si l'on est continuellement contrarié par un outil qui nous met des batons dans les roues.
Au contraire, un outil devrait être le prolongement naturel de notre pensée et de nos mains, quelque chose qui nous facilite la vie, pour lequel on n'a pas trop a réfléchir et qui réfléchit à notre place pour nous laisser nous concentrer sur l'essentiel, la valeur ajoutée de notre poste, que ce soit la relation client, la conception, la préparation manuelle ou que sais je, tout sauf la saisie.
Et la technologie dans tout ça ?
La technique reste importante, évidemment, mais aujourd’hui, elle n’est plus le principal frein. En plus celles actuellement sur le marché sont toutes relativement abouties, celles qui étaient plus lourdes ont été optimisées, celles qui manquaient de fonctionnalités ont petit a petit vue leur écosystème grandir suffisamment pour combler les lacunes. Bien sur si demain une nouvelle sort, il lui faudra un petit temps pour prendre de la maturité, encore qu'avec l'IA, il y a fort a parier que la courbe d'évolution de la techno soit suffisamment rapide pour que rapidement elle atteigne un niveau suffisant pour la pluspart des projets.
Ce qu’il faut retenir
Un bon outil ne commence pas par du code.
Il commence par une compréhension de votre manière de travailler, le code, c'est la cerise, pas le gâteau.
