Les projets digitaux ne se passent pas toujours comme prévu ou comme espéré. Ils peuvent être semés d'embûches et difficiles à gérer si des erreurs sont commises, notamment en début de projet. Et nous en savons quelque chose ! Pas parce que nous enchaînons les erreurs, mais parce que lorsque que l'on travaille sur un projet de l'idée à son développement, nous devons anticiper chaque potentiel problème.

Il nous paraît donc intéressant de vous partager l'une de nos expériences projet, qui a connu un certain nombre d'erreurs et de rebondissements inattendus. Cela pourra vous permettre, vous, lecteurs avertis, d'éviter de faire les mêmes erreurs pour votre projet, et pour nous, de faire en quelque sorte une catharsis et de nous améliorer.

Ah oui, avant de commencer : ne vous en faites pas, le projet se porte bien et s'est finalement terminé sans trop d'encombres. 🙏

2 ans ⏱

En 2018, nous avons commencé à concevoir une application destinée à la gestion de maintenances et des dépannages sur des systèmes de génie climatique. Pendant 2 ans, nous avons enchaîné les phases de conception, de design et de développement, un lot après l'autre et une fonctionnalité après une autre fonctionnalité. En ce début de novembre 2020, le projet voit enfin le jour, et commence à être utilisé. Hip hip hip !

Attendez, pas si vite. L'application est bel et bien disponible et opérationnelle, mais nous nous sommes aussi rendus compte qu'elle n'est finalement pas complètement adaptée à la réalité du terrain et des usages de ses utilisateurs, et que des ajustements sont encore nécessaires.

"Mais qu'est-ce que vous avez fait pendant 2 ans ?! Personne ne s'est rendu compte plus tôt que ça n'allait pas ? Vous êtes pourtant extrêmement professionnels, un phare dans la nuit des agences digitales !"

Il est vrai. Mais la réponse est toujours plus compliquée qu'il n'y paraît. Laissez-nous vous expliquer modestement et en toute transparence les raisons qui ont amené à ce constat.

"Ils ont besoin de ça !" 👌

Au début, tout allait bien. En y repensant, si ça ne va pas au début, c'est mauvais signe. Toujours est-il que ça allait bien, très bien même ! La prise de besoin était claire, synthétisée dans un cahier des charges rédigé par notre product owner et le responsable des équipes de notre client. Plusieurs réunions de cadrages ont été réalisées pour organiser, planifier et gérer les détails de départ du projet.

Les besoins exprimés étaient claires : "Mes techniciens doivent pouvoir ajouter des équipements !", "L'application doit pouvoir s'utiliser hors connexion", "Je veux que l'application place automatiquement des maintenances", et bien d'autres fonctionnalités et contraintes établies clairement en amont de la conception et du développement web. Tout. Allait. Bien. 🙃

En fait, non : loin de là. Mais nous ne le savions pas encore. En effet, si tout paraissait se dérouler comme on peut s'y attendre pour un projet de ce type, il y avait un grand absent de ce début de conception. Une idée ? Voilà un indice : ils utilisent l'application.

Ça peut paraître bête, mais c'est finalement ce qui se passe dans une grande majorité des projets digitaux qui sont réalisés aujourd'hui dans le monde. On crée avec et surtout pour un chef d'équipe, un responsable marketing, un directeur, une cible marketing. Mais trop rarement pour les utilisateurs finaux et réels de l'application. Oups.

Comment concevoir une application sans leur demander ce dont ils ont besoin, sans valider ensuite nos hypothèses, sans regarder comment ils travaillent et sans comprendre pourquoi et comment ça pourrait les aider ? Nous nous demandons encore comment nous avons pu commencer à travailler en passant à côté de ces questions pourtant essentielles. Nous avons bien tenté de pousser à notre client une étude utilisateur en début de projet, mais n'avons vraisemblablement pas été assez bons pour le convaincre de l'importance capitale qu'elle représente. Ce fut notre première erreur.

La recherche utilisateur pour comprendre les besoins 🙋‍♀️

Vous l'avez donc compris, l'erreur est de ne pas avoir réalisé de recherche et de tests utilisateur afin de connaître et comprendre les utilisateurs finaux de la solution. C'est finalement aussi simple que ça.

Ce n'est pourtant pas compliqué à mettre en place ! Nous aurions pu commencer par nous entretenir avec eux, écouter leurs besoins, leurs attentes, leurs frustrations actuelles et l'apport que nous aurions pu apporter face à la demande du client. Les entretiens permettent aussi de découvrir de nouveaux éléments et questionnements, insoupçonnés, qui peuvent nous permettre d'en apprendre plus et de toujours tendre vers une conception "parfaite".

L'observation est également très importante pour comprendre des besoins et mécaniques de fonctionnements des utilisateurs. Nous aurions dû aller sur le terrain, autant avec les techniciens qu'avec les administrateurs pour comprendre comment ils fonctionnent aujourd'hui réellement et non à travers un cahier des charges de plusieurs dizaines de pages. Après tout, nous ne sommes pas des techniciens experts en génie climatique, mais de modestes artisans du web. Un grand homme a dit un jour : “L’observation recueille les faits ; la réflexion les combine ; l’expérience vérifie le résultat de la combinaison”. Et croyez-nous, avec du recul : c'est vraiment ça (on y croit vraiment, et on n'a pas attendu de taper "Citation observation" sur Google pour s'en rendre compte 👌).

Il aurait également été intéressant de formaliser toutes ces données sous forme d'expérience map afin d'identifier de nouveaux points de friction ou les anticiper et y trouver des opportunités d'améliorations. Il faut bien comprendre que la conception centrée sur l'utilisateur peut-être longue, et qu'elle intervient à chaque étape de la conception, mais qu'elle permet de concevoir utilement et de répondre à de réels besoins.

Pas de place au bullshit. C'est certain, nous ne répèterons plus la même erreur, celle de foncer tête baissée en ayant pour seul interlocuteur un non-utilisateur final de la solution, quelqu'un qui ne sera finalement jamais en interaction avec le système, malgré toute son expérience et sa bonne volonté.

Concevoir, tester, recommencer

Je poursuis. Une fois notre mauvais travail de préparation effectué, une autoroute se traçait dans nos esprits. Il ne nous restait plus qu'à abattre les nombreuses vues de l'application dans notre logiciel de design d'interface favoris, et à les faire valider au plus vite pour passer au développement et voir le résultat de notre dur labeur.

Deux erreurs ici. La première, c'est d'avoir voulu tout faire d'un coup. Une application de cette envergure pouvait sembler très complexe à réaliser si on réfléchit d'un point de vue global, et elle l'était. Une manière simple et efficace d'aborder le problème aurait été de découper cette application en plusieurs lots plus petits et plus faciles à appréhender. Mieux : de réfléchir au socle de l'application, avec quelle(s) fonctionnalité(s) l'application ne peut pas fonctionner ? Et à partir de cette réflexion, de travailler sur un MVP : Minimum Viable Product. Une version simplifiée de l'application, permettant d'avoir une base que l'on va pouvoir par la suite faire évoluer. Mais c'est un concept que nous aborderons plus en détail une autre fois. 🦦

La seconde erreur a été de ne pas présenter notre travail aux techniciens et administrateurs, futurs utilisateurs de l'application. Certes, un prototype interactif très détaillé a été réalisé, mais nous ne l'avons présenté qu'au chef d'équipe. Nous avons évidemment pu obtenir des retours de ces présentations, et pu faire des ajustements pertinents, mais ce n'est rien par rapport à ce que l'on aurait dû et pu avoir de la part des équipes sur le terrain. Tout ce que nous souhaitions, c'est entendre ces doux mots : "C'est validé !"

Ces deux mots prononcés par un client déclenchent souvent un branle-bas de combat général. On pourrait presque entendre le chef de projet crier : "Développeeeeeeeeez !" dans l'open space, et les développeurs se mettre en rang sur leurs machines et taper frénétiquement sur leurs claviers pour pousser des fonctionnalités les unes après les autres.

D'une manière générale : même si vous pensez avoir pensé une application à toute épreuve, pensez à nouveau : il est presque toujours bénéfique de faire tester un prototype quand on est encore en phase de conception et que tout peut encore changer de manière assez flexible. Nous disposons aujourd'hui de tellement d'outils permettant de créer un prototype interactif à partir de simples maquettes qu'il serait trop bête de se lancer dans des semaines de développement onéreuses, sans avoir fait tester le résultat de son travail préliminaire. Et ne nous forcez pas à ressortir une citation !

Le mot de la fin

Même si nous vous l'avons ici présenté comme une série d'erreurs, ce projet n'est pas un échec. D'abord parce qu'il a vu le jour, et qu'il fonctionne aujourd'hui parfaitement (Yayy ! 👏). Mais surtout parce qu'il a été une vraie source d'expérience et de remise en question, pour le mieux.

Si nous accordons autant d'importance à vos utilisateurs, ce n'est pas pour surfer sur des termes à la mode et essayer de faire comme tout le monde. C'est parce qu'il n'y a rien de plus frustrant que de se rendre compte, après beaucoup d'efforts, que le résultat n'est pas à la hauteur de ce qu'il aurait pu être et que cela aurait pu être évité en travaillant pas nécessairement plus, mais plus intelligemment et surtout plus humainement.

Nous espérons que cette (vraie) histoire vous a plu. Peut-être vous êtes-vous retrouvé ou identifié dans ce récit, que ce soit d'un côté comme de l'autre. Si c'est le cas, n'hésitez pas à nous envoyer un message, nous adorerions écouter vos déboires digitaux. ✌️