A côté de nos cas clients parfois complexes à décrypter, voici une étude d’un cas réel d’un petit projet, mais qui permet de mettre en lumière certaines erreurs à ne pas faire et que l’on peut également retrouver sur des projets bien plus gros avec pourtant de vrais professionnels de l’informatique d’entreprise à la manœuvre. Toutes ces erreurs ici simples à identifier viennent toutes de la même cause racine : la non perception d’un changement majeur des utilisateurs. Dans tous les cas et sur tous les projets Web vous avez tout intérêt à investir suffisamment dans la conception de l’expérience et de l’interface utilisateur (UX / UI design) ainsi qu’à dimensionner et organiser correctement  les phases de tests utilisateurs.

Laisser les clés du camion à l’informaticien de service ?

Au cours de ma carrière, j’ai eu à conduire ou à auditer de nombreux projets de transformation ou plus simplement des  projets de mise en œuvre d’outils numériques avec des impacts plus ou moins forts sur les usages, les organisations, la gouvernance de l’entreprise… Ces projets se passent pour la plupart correctement même si cela nécessite parfois des recadrages ou des renoncements. Normal me direz vous puisque ISLEAN est dans le paysage ! Nous intervenons souvent dans les phases amont et nous cadrons, ou recadrons quand les études sont parties sur les mauvais rails. En sortie de cadrage nos clients ont bien détouré leur projet et savent pourquoi le lancer. Ils savent ce qu’ils peuvent en attendre en terme de gains voire de retour sur investissement et ont validé les principes structurants qui doivent guider leur projet de transformation sous peine de rater leurs objectifs. Il nous arrive aussi parfois d’aboutir à des décisions de ne pas faire ou à les aider à arrêter des projets (souvent des giga projets). Dans ces cas d’échecs nous avons souvent affaire à des projets gigantesques et les causes d’échecs sont nombreuses avec de multiples responsabilités. Et lorsque nous intervenons en pilotage et coordination de projet, avec un ou plusieurs maitres d’œuvres du numérique, nous mettons tout sous contrôle et nous assurons à nos clients que tout va se passer correctement et que les objectifs métiers seront peu ou prou atteints. Bref, on ne voit pas beaucoup d’échecs finalement. Heureusement j’ai une vie en dehors du travail, et cela m’a donné l’occasion de suivre (et aussi subir) un petit projet directement géré par des techniciens du numérique pourtant compétents sur leur domaine et pleins de bonne volonté, sans contrôle ni pilotage. C’est très dangereux.

Etude de cas : Une idée séduisante sur le papier… à condition de ne pas oublier un paramètre essentiel

Le cas est le suivant. Je m’occupe bénévolement d’une association locale. Cette association est affiliée à une fédération qui gère également les adhérents puisque l’adhésion à l’association entraine automatiquement l’adhésion à la fédération. Cette fédération a développé une base nationale qui existe depuis 20 ans (a peu près). Chemin faisant, au fil des années, la transmission dématérialisée des documents d’adhésion par les associations à la fédération est devenue la règle. Les associations se sont organisées pour que le responsable ou un très petit nombre de membres du bureau ou du comité de direction s’impliquent sur la tâche fastidieuse de scanner les documents nécessaires aux adhésions, et de renseigner manuellement les données dans la base de données. Bref ce processus est utilisé et mis en œuvre par un millier de personnes sur le territoire national. Et ce sont toujours les mêmes personnes années après années car peu de monde à part des bénévoles masochistes ou parfois un salarié administratif de ces associations (dans les plus grosses d’entre elles) ne veut s’y coller. Autant dire que ces personnes maitrisent bien le processus (numérisation, enregistrement des métadonnées – dont certaines dépendent de règlementations complexes – exemple accords de transferts entre fédérations d’autres pays et la fédération française –  et téléversement des pièces sur la base nationale de la fédération).

Au bout de quelques années, un adhérent féru d’informatique et par ailleurs très compétent sur ce domaine se dit, « bon, il serait temps de passer à l’an 2020, je vais développer une application, en collaboration avec la fédération, pour que les adhérents fassent leur dossier eux-mêmes directement en ligne. Je vais faire une application début juillet, après je pars en vacances, fin août je termine l’appli et hop le service est ouvert le 30 août, les adhérents peuvent s’inscrire dès la fin août. ça va bien se passer, de toute façon j’ai choisi une pile logicielle que je maîtrise parfaitement et tout à fait conforme aux standards de l’internet donc ça va bien se passer »
Euh… ! cherchez l’erreur….
Fibre optique école

Oublier le petit détail qui tue… : et les utilisateurs dans tout ça ?

Il y a plusieurs omissions majeures dans le raisonnement de mon camarade adhérent, petit génie de l’informatique.

  • Le premier concerne le passage sous silence complet du changement d’utilisateurs.
    • Il ne s’agit plus de s’adresser à des personnes formées et rodées (qui font cette procédure d’inscription depuis plusieurs années), volontaires et motivées… mais de s’adresser à des utilisateurs n’ayant rien demandé et dont certains ne sont pas du tout à l’aise voire refusent le numérique
    • Par ailleurs l’ancien système s’adressait à, grosso modo, 1 000 utilisateurs sur le territoire national. La nouvelle application s’adresse à 300 000 utilisateurs. Rien de problématique techniquement, mais 300 000 utilisateurs qui n’ont rien demandé en comparaison de 1 000 utilisateurs formés et motivés c’est radicalement différent
  • Cette incompréhension à conduit à négliger complètement les aspects expérience utilisateur et à ne pas être suffisamment ou pas suffisamment bien accompagné de fortes compétences en UX/UI Design.

Négliger les tests utilisateurs

Mon camarade génie de l’informatique a de plus omis le temps à passer sur les tests utilisateurs avant l’ouverture en production ! Dans la vraie vie (véridique, je caricature à peine) il a testé le truc sur son PC et « ça fonctionnait parfaitement » (sic) ! La réalité c’est que 50% des adhérents utilisent leur téléphone (Androïd ou Apple) pour faire leur dossier. Sur les 50% autres il y en a qui n’ont pas forcément fait la mise à jour de leur navigateur internet sur leur PC (Sur Chrome c’est difficile de ne pas le faire, mais sur Firefox ou Opera par exemple, rien n’oblige à faire les mises à jour). Je ne vous parle même pas de ceux qui ont un Mac avec une version plus ou moins ancienne de Safari, ou les geek qui veulent le faire sur Linux avec Chromium (et qui bien sûr critiquent à qui mieux mieux la réalisation de mon petit génie de l’informatique). Au delà des problèmes techniques et fonctionnels, les tests utilisateurs (avec de vrais utilisateurs), seuls permettent de remonter et prioriser les problématiques d’interface ou d’expérience utilisateurs (UX/UI design Test).

Croire que le respect des derniers standards du W3C est suffisant

Quand on développe une application pour 300 000 utilisateurs lambda, utiliser les technologies de l’internet c’est indispensable, nous en sommes intimement convaincus. Mais il ne suffit pas seulement d’utiliser les dernières possibilités d’HTML5 et de CSS3. C’est peut-être conforme aux standards du W3C mais pas supporté à un instant t par tous les navigateurs et sur tous les types de périphériques. Il faut s’attacher à développer un code qui prévoit des cas avec d’autres fonctions pour les navigateurs un peu plus anciens ou en version mobile.

Le résultat était probablement prévisible

Avec tout ça, ça ne pouvait pas bien se passer, et sur l’échantillon d’associations pilotes ayant accepté d’essuyer les plâtres, une seule les a véritablement essuyés, les autres ayant déclaré forfait très rapidement.
Mais devinez quoi…
Je pensais naïvement qu’après cette mini catastrophe, notre génie du numérique aurait compris.

Leçons apprises… aucune !

J’ai du insister comme un fou pour lui expliquer qu’un retour d’expérience avec la fédération nationale s’imposait et que je souhaitais y participer (et qu’il serait utile d’exploiter la log de tous les tickets de maintenance ou d’évolution qui avaient été remonté) –> j’ai rapidement compris qu’il n’avait rien enregistré de toutes les demandes de correction ou d’évolutions remontées et s’était plutôt évertué à en faire le maximum (ce qui est très bien si tant est qu’il ait une capacité infinie à les faire ce qui n’est évidemment pas le cas). L’idée pour moi était de repartir sur de bonnes bases et de refaire un pilote en 2022 en s’organisant correctement pour être dans une dynamique d’amélioration avant déploiement.
Et là, mon collègue génie de l’informatique mais néanmoins ami m’a définitivement scié en me sortant :
« mais de toute façon c’est bon, l’année prochaine on déploie nationalement…. » (sic)
Avec 300 personnes ça a été le carnage… mais ayez confiance j’ai compris : maintenant ça ne se reproduira plus : on déploie à 300 000 !
La folie disait Einstein, c’est de reproduire les mêmes erreurs et croire qu’on va finir par obtenir un résultat différent.
Einstein : e= mc2