Certaines fonctionnalités sont tellement ancrées que personne ne se pose plus la question : pourquoi est-ce qu’on fait ça ? La question est pourtant légitime : s’il n’y a pas vraiment de besoin derrière, on perd du temps à concevoir, développer et maintenir des fonctionnalités qui ne servent jamais.
(photos de l’article : pexels - CC0, photo de couverture : leeloTheFirst, licence Pexels)
Le cas Excel
Un des exemples les plus courant est l’export en CSV/Excel. En général, on dispose d’un bon gros tableau de données et souvent arrive une demande pour l’exporter vers Excel pour exploitation. Et très souvent, la fonctionnalité est développée et disponible dans l’application concernée sans trop rencontrer de soucis.
Sauf que trop souvent personne ne s’est posé la question : pour quoi faire ? Pourquoi le client a besoin d’un export CSV/Excel ? Pourquoi a-t-il besoin d’ouvrir les données dans Excel alors qu’il les a déjà dans notre application ?
Coupage de cheveux en quatre ?
Pas vraiment.
Si par exemple, vous avez du mal à chauffer votre maison, vous allez peut-être voir un chauffagiste en lui disant : “je veux un plus gros chauffage”. Le plus gros chauffage va chauffer plus mais va aussi consommer beaucoup plus et la facture va augmenter. Alors qu’en creusant un peu votre besoin, on peut se rendre compte que votre maison est mal isolée. Et résoudre plutôt ce problème d’isolation vous fait garder le même chauffage, améliore votre confort et peut même réduire votre facture. Un problème, deux solutions et celle que vous pensiez initialement n’est pas forcément la meilleure.
Il en est de même avec un export Excel : si on a besoin d’un outil tierce, c’est que l’application à ne couvre pas un besoin, un cas d’usage d’utilisateur. Excel est une solution générique passe-partout qui, certes, peut combler le manque mais qui est trop souvent utilisé à tort, sans connaître les effets de bords. Et souvent, il existe une meilleur solution pour répondre au besoin, d’où l’importance de questionner la fonctionnalité.
Bon, c’est facile de dire ça mais allons vers du concret.
Les problèmes de confidentialité
Le contrôle d’accès
Commençons par la base : pourquoi fait-on cette application ?
Si le client est une entreprise, il y a de grandes chances qu’on retrouve le besoin de contrôler et d’auditer les accès aux données. L’application doit permettre de contrôler qui voit quelles données, qui peut accéder à quoi et pouvoir faire des audits de ces données (traçabilité des modifications). Dans le monde des assurances, c’est plutôt demandé :)
Faire un export Excel, ça veut dire que l’on sort ces données du cadre de l’application. Et donc, que l’on perd tous les mécanismes de contrôle d’accès et d’audit. Et bien oui, une fois les données dans un fichier Excel, qu’est ce qui empêche quelqu’un de les envoyer par mail à une personne qui ne devrait pas y avoir accès ?
Rien.
Sans chercher à voir un vilain pirate, ça peut être des grilles de salaire qui sont diffusées dans l’entreprise parce que quelqu’un qui y avait accès à fait une extraction pour montrer à quelqu’un d’autre qui l’a transféré à son tour, etc. En général, la diffusion de ce genre de document installe une bonne ambiance.
À partir du moment où des données peuvent être exportées, il faut quasiment les considérer comme “publiques” parce qu’il arrivera forcément un jour où elles seront vues par la mauvaise personne. Dès lors, pourquoi mettre des contrôles d’accès si c’est pour laisser des fuites ?
Bien entendu, toutes les données ne sont pas sensibles. Des données de toute façon publiques, ça ne pose pas de problème de les exporter. De même, les données personnelles de l’utilisateur, s’il a envie d’exporter ses propres données et de les diffuser, c’est son droit le plus légitime, ce sont ses données à lui.
Là où il faut se questionner, c’est quand les données ne sont ni publiques, ni propres à l’utilisateur : données personnelles d’autres personnes, données commerciales confidentielles, etc. Derrière un bête export excel, on peut faire un gros trou dans la confidentialité des données.
CNIL, RGPD et amendes
Autre joyeuseté du même acabit, le Règlement Général sur la Protection des Données (ou RGPD, pour les intimes). Dans les obligations liés à ce Référentiel, au delà de la confidentialité des accès (cf. point plus haut), il y a la durée de rétention des informations.
Concrètement, ça veut dire qu’à intervalle régulier, les vieilles données doivent être purgées (droit à l’oubli, etc.). Sur l’application, ça se gère : un petit script de nettoyage à intervalle régulier et on en parle plus.
Mais sur des fichiers Excel qui sont enregistrés sur un poste, comment fait-on ? On ne peut pas, tout simplement. Exporter des données vers un fichier, c’est accepter que des données ne puissent plus être purgées. Sauf que légalement, si ce sont des données personnelles, c’est une obligation et les amendes sont assez élevées (petit exemple avec Carrefour : https://www.cnil.fr/fr/sanctions-2250000-euros-et-800000-euros-pour-carrefour-france-carrefour-banque).
Bref, une fonctionnalité aussi anodine qu’un export Excel peut parfois coûter cher
Ça, c’est pour la partie légale. Intéressons-nous à présent aux besoins derrière un export Excel.
Les vraies-fausses raisons de l’export
Les fonctionnalités manquantes
Une des raisons simple qui revient assez souvent, c’est le besoin de filtrer selon le critère X ou Y. Très souvent, les personnes qui le demande ne connaissent qu’Excel et dans le doute, elles demandent l’export parce qu’elles sauront s’en sortir avec Excel.
La réponse à apporter est assez simple : on peut ajouter des fonctionnalitées de filtrage sur l’application. Tout simplement.
Et on évite ainsi les allers-retours entre les fichiers exportés et l’application, de devoir systématiquement faire des exports à chaque modification, etc. Oui, il y a des gens qui travaillent vraiment dans ces conditions là et leur mettre un simple filtre peut leur changer la vie.
C’est le même genre de réponses à apporter pour les personnes qui veulent se servir d’Excel pour générer des graphiques et rapports : il existe des librairies qui permettent de faire des graphiques dynamiques, responsives et bien meilleurs que ce qu’Excel peut produire. Et on peut rajouter ça dans la liste des fonctionnalités. Bien entendu, les rapports et graphiques générés ne pourront pas être bidouillés pour apparaître meilleurs qu’ils ne le sont… mais personne ne fait ça, voyons…
“Faciliter” le changement
Dans les autres raisons qui peuvent “justifier” un export Excel, on retrouve le “c’est pour faciliter le changement”. Le contexte : la nouvelle application doit remplacer un fichier Excel devenu difficile à maintenir mais pour éviter de froisser Jean-Pierre et Marie-Paule qui ont un bac+13 en formule Excel et ont toujours fonctionnés comme ça, on leur laisse la possibilité d’exporter vers le même format de fichier Excel, comme ça ils ne sont pas perdus le temps de faire la transition.
Je vais spoiler : avec cet export Excel, la transition ne se fera jamais. On est ici sur une problématique d’accompagnement du changement, pas de manque de fonctionnalité. Il faut accompagner les utilisateurs vers le nouvel outil, pas le maintenir dnas quelque chose d’obsolète.
Parce que comme ils utiliseront cet export Excel pour retrouver leur ancienne façon de travailler, il vont travailler de la même façon. Et on aura des utilisateurs sur l’application et d’autres dans leur coin qui utilisent les fichiers Excel et oublieront parfois de reporter leurs données dans l’application : ingérable.
Non, comme pour le sparadrap, il vaut retirer d’un coup ! À l’Ux designer de faire en sorte que les marques soient plus rapidement prises et qu’il n’y ait pas de raison de regretter l’ancienne façon ! Mais l’export Excel pour combler l’entre-deux, c’est une très mauvaise idée.
La communication inter-application
Une autre raison invoquée pour demander un export Excel, c’est pour le charger dans un autre outil. Le scénario est le suivant : je suis sur l’application 1, j’ai traité les données et je veux les charger dans l’application 2 pour lancer d’autres traitements. Et pour ça, je vais exporter en CSV les infos de application 1 pour les charger dans application 2.
C’est un besoin légitime et qui peut s’entendre. Mais est-ce la seule solution à disposition ?
Il arrive parfois que cet import/export Excel est dû à des questions historiques : comme application 1 n’existait pas et était un fichier Excel, forcément, l’import dans application 2 c’était le fichier Excel. Et avec la mise en place d’application 1, on s’est dit que ça allait fonctionner pareil : il faut le fichier Excel intermédiaire et donc faire un import/export.
Sauf qu’aujourd’hui, avec la nouvelle application 1, on peut peut-être utiliser des APIs de chargement direct.
Avantage : pas de fichier intermédiaire, pas de problème de corruption de données entre l’export et l’import, moins de risques de fuite de données. Et en prime, un expérience utilisateur améliorée : l’utilisateur n’a plus qu’un bouton à appuyer pour charger dans l’autre application au lieu de générer le fichier, l’enregistrer, aller sur l’autre application et le charger. Gain d’efficacité !
Bien sûr, des fois on ne peut pas faire autrement. S’il n’existe pas d’API, on ne peut pas connecter les deux applications et il faut passer par l’import/export. Mais il faut se poser la question : est-ce qu’on peut faire autrement que l’export Excel?
Parce qu’on ne sait jamais
Et une petit dernière pour conclure (ma préférée) : l’anticipation de besoin hypothétiques et futurs. en général, la spécification est assez floue voir tautologique, du genre “j’ai besoin d’exporter vers un fichier Excel afin d’utiliser les fonctionnalités d’Excel”. Bah oui, Excel gère des fichiers Excel donc pour pouvoir utiliser Excel, il faut un fichier Excel. Mais ça me dit pas pourquoi on a besoin d’utiliser les fonctionnalités d’Excel.
Et quand on commence à creuser, la personne en général vous dit “peut-être que plus tard on aura besoin de filtrer sur le critère X ou le critère Y et à ce moment là, le fichier Excel sera utile”. Ou peut-être pas, mais “on ne sait jamais, il vaut mieux prévoir”.
La personne anticipe ici un besoin qui, à 80% du temps, n’arrive jamais. On a toujours tendance à trop charger dans le doute mais beaucoup de filtres/tris sur des tableaux de données ne servent pas en pratique.
Et quand on dit qu’on s’en occupera quand le besoin se présentera, généralement la réponse contient les expressions “ça prendra du temps”, “il faudra redévelopper” et “ça va coûter de l’argent”. Et donc pour éviter de payer des développements supplémentaires, on demande un export Excel qui paliera d’hypotéhétiques manques futurs en s’asseyant sur les questions de confidentialité et de sécurité (voir points plus hauts).
Honnêtement, je n’ai pas encore trouvé quoi répondre à ça. Je comprends très bien que développer une application à un coût et que le budget est alloué pour une année N et qu’il peut être compliqué d’en débloquer pour l’année N+1. On veut tout faire d’un coup et ne plus y toucher pendant 10 ans. Sauf que ça ne fonctionne pas comme ça. Il y aura forcément des nouveaux développements.
Parce qu’il faudra mettre à jour des dépendances et résoudre un problème de sécurité. Parce que la DSI aura changé le système d’authentification de l’entreprise et qu’il faudra adapter l’application. Parce qu’il y aura un nouveau besoin à prendre en compte.
Une application ça vit et ça se maintient à jour. Elle ne va pas être redéveloppée intégralement tous les ans. Mais ajouter un filtre parce qu’un nouveau besoin se fait sentir, ça fait partie de la maintenance. Ce n’est pas énorme, ça ne révolutionne pas tout, ça ne prendra pas 4 mois de développement (ou alors il y a un gros problème). Et il faudra le faire.
Anticiper des besoins futurs sans avoir des besoins réels, c’est faire des plans sur la comète, c’est dépenser du temps et de l’argent pour des choses qui n’arriveront peut-être jamais. Ou dont on se rendra compte, quand le besoin arrivera, que l’export Excel ne résoudra rien et qu’il faudra développer de nouvelles choses, quoi qu’il arrive. Anticiper des besoins hypothétiques complexifie tout, de l’Ux au développement. C’est donc important de les questionner.
Je pourrais continuer encore un bon moment sur le sujet mais je pense que vous avez suffisament de billes pour comprendre mon point de vue.
Une fonctionnalité doit répondre à un besoin, à une problématique réel des utilisateurs. Connaître ce besoin permet d’y répondre au mieux et d’éviter l’écueil d’une solution générique au conséquence trop souvent sous-évaluées. Parfois, la solution qui a été proposée initialement est la bonne. Un export Excel pour éviter de passer 6 mois à développer une fonctionnalité utile à une seule personne une fois par an, c’est très bien, il faut aussi être réaliste et pragmatique.
Mais comme on a pu le voir, parfois on peut faire mieux et plus adapté. Et pour ça, il faut toujours revenir au besoin utilisateur.