Coup de gueule / questionnement : les messages d’erreur sur les sites/applis aujourd’hui

23 comments

1. Je me pose la même question. Une hypothèse peut être “dev payés au lance pierre dans un pays où tout le monde delocalise, fort turn over et ce sont toujours des nouveaux qui reprennent le code des précédents”

2. Sur nos produits (je suis dev), on a des erreurs explicites quand on peut. Ce type de message on va l’afficher quand on sait pas ce qu’il s’est passé, OU alors quand on pourrait savoir mais que c’est très gênant.

   Il faudrait l’avis d’un UX mais il faut toujours gérer la question du “jusqu’où peut on être technique avec le client”. Je me vois mal expliquer dans un message d’erreur à mamie huguette qu’on a une référence nulle dans le code et qu’en conséquence on peut pas continuer son virement, par exemple. Les rares cas clair qu’on pourrait afficher pour une erreur technique sur un site web c’est les erreurs due à une maintenance ou une trop grosse affluence, le reste c’est pas présentable à mon sens.

   ​

   EDIT : je suis un connard j’ai mal lu tes exemples, je m’exprimais surtout au sujet des erreurs tech.

3. En tant qu’ancien dev, je déconseille aux nouveaux venus de s’orienter vers le web/mobile. Le SaaS est aussi un cancer moderne.

4. > Développeurs qui n’ont plus le temps de gérer les messages d’erreur, ou qui ont juste la flemme ?

   Pas le temps / trop cher.

   Et les applis sont de plus en plus découpées (de moins en moins de monolithe), donc pour avoir un message précis, il faut que la cause de l’erreur soit communiquée tous le long, ça fait beaucoup de complexité en plus.

   Et bien souvent, tu n’en sait rien côté dev de pourquoi ça a planté, tu reçois une 500, bon ben “something went wrong”…

   Et bien souvent aussi, on n’a pas trop envie d’expliquer les causes de l’erreur à l’utilisateur parce que c’est un peu honteux / qu’il peut de toute façon rien y faire.

5. SysAdmin ici, je suis totalement d’accord avec toi.

   Le traitement des erreurs est une balance ultra-fragile.

   Quoi que tu fasse, pour la moindre instruction, il y a une infinité de possibilités d’erreurs, il est purement impossible de donner un nom sur toutes les erreurs (c’est bien pour ça que ces codes génériques existent genre `400`/`500`)

   Et même quand on se prépare à une erreur en particulier, rien ne te garantis que ton piège va être assez précis pour ne pas catch une autre erreur et qu’il n’est pas trop précis et ne pas catch une variation minuscule de l’erreur.

   Le reste de l’équation /u/red_spaniel l’a bien résumé.

   En plus du fait qu’on peut pas trouver toutes les erreurs, on va pas afficher une réponse API entière avec le traceback par ex., oui ce serait bien, mais en plus d’effrayer les novices, en plus du risque inhérant de sécurité si tu gère mal ta réponse, ça ouvrirait un tapis rouge aux arnaqueurs où il suffirait de créer une fausse page, modifier un peu le traceback et les envoyer vers un support malicieux…

   Cette balance peut sauter à tout moment et causer des gros soucis

6. En général il y’a 2 grand types d’erreurs, celles liées à une erreur de l’utilisateur (et donc que ce dernier peux facilement corriger) et celles liées à un problème interne (que l’utilisateur ne peux pas gérer). Normalement dans le premier cas l’appli est censé retourner un message explicite et l’utilisateur doit pouvoir corriger son erreur de lui même (exemple : l’IBAN n’est pas au bon format). Dans le second cas l’appli retourne un message générique (exe : Oups ça marche pas) pour éviter de faire fuiter des informations techniques internes (le message peut contenir beaucoup d’infos sur les technos, des urls, des logins, voir des mot de passe quand c’est mal fait….) et pour éviter d’embrouiller l’utilisateur avec un message qu’il ne comprendra pas et dont il ne peut rien faire.

   Dans le développement on utilise beaucoup de framework qui facilite le travail mais ne simplifie pas toujours la gestion des erreurs du coup on peut se retrouver à avoir des erreurs internes à cause d’une erreur utilisateur ce qui provoque un message générique alors que l’utilisateur pourrait lui meme faire la correction.

   Pour les cas que tu donne :

   * J’imagine que l’appli qui fait l’installation part du principe qu’il y’a assez de place et ne prends pas le temps de vérifier du coup elle tente l’installation, prend une erreur interne (pas assez de place) et retourne une erreur générique. Dans ce cas c’est plus une feignantise des devs;
   * J’imagine que l’appli de ta banque analyse l’IBAN pour trouver les infos et retourne une erreur si elle ne trouve pas ce qu’il lui faut. Dans ce cas là c’est compliqué pour l’appli d’expliquer pourquoi elle n’arrive pas analyser l’IBAN et ça retourne directement une erreur interne. Dans ce cas je pense que c’est le framework qui analyse l’IBAN qui ne donne pas d’infos assez précise;
   * Reddit à l’air d’avoir été codé avec le cul, pas la peine de chercher plus loin…

   Dans l’ensemble c’est souvent un mélange de complexité technique, de flemme et d’oubli (difficile de penser à tous les cas possible).

7. Récemment une appli web me répondait un générique « impossible erreur technique » et du coup j’ai lancé la console debug JavaScript, qui m’indique clairement « action impossible contrat en cours de validation »

   Ma théorie dans ce cas c’est que les développeurs de l’interface n’ont pas géré correctement les messages d’erreurs renvoyés par l’api qui leur sert a communiquer avec le serveur.
   Ça peut s’expliquer par la flemme et par la consigne de pas afficher directement les réponses de l’api.. et même si le développeur de l’interface veut bien faire il a pas toujours toutes les billes

   Alors ça parait bête mais ça a un peu de sens par exemple dans une banque ton conseiller va peut-être te dire non à un crédit mais sans détailler les raisons du refus de son responsable, qu’il ne connaît peut être pas.

   Après dans le domaine de l’encaissement cb, un site marchand a pas tout le temps les vraies raisons du refus de la banque et selon les banques ont des réponses qui vont de indisponible à erreur alors que la banque a une raison détaillée mais qu’elle ne communique pas par sécurité : crypto erroné, montant du plafond mois dépasse etc..

8. La croyance que l’utilisateur n’a aucune connaissance, et lui mettre un message trop technique va lui faire peur…

   Donc on a plus que ces message “gnéééé, ça a planté ” dont tu ne peux rien tirer.

9. Il faudrait avoir les spécifications des applications pour déterminer le coupable.

   Il y a tellement de situations différentes qui peuvent aboutir à un message pas assez explicite que c’est juste impossible d’en tirer une généralisation.

10. J’ai le même sentiment, et comme toi ça m’énerve.

    Je pense que c’est dû à l’infantilisation à outrance des logiciels, mais aussi du mouvement de positivité à tout prix qui est très présent aux USA et en particulier en Californie. Ça a commencé doucement avec les “messages d’erreur simplifiés” des navigateurs il y a 10-15 ans. Une erreur 500 ça fait peur, un petit message “Something is wrong, don’t worry” c’est mignon et rassurant (mais débile). Les développeurs avaient d’ailleurs gueulé parce que les rapports d’erreur ne contenaient plus le code d’erreur. On pensait que le bon sens reviendrait, mais au contraire…

    Même les outils pour développeur s’y mettent. Quand je fais un merge sur Gitlab, il me met un message “This is going to be great!” pendant l’opération. Je trouve ça débile, inutile, et infantilisant, et j’aimerais bien avoir la personne qui a décidé de mettre ça à côté de moi pour lui dire ce que j’en pense.

    Du coup, les erreurs doivent être positives également. Un message avec une stack trace, ça fait peur. Une animation débile comme celle de Twitter quand c’est down, avec un message gentil et mignon (mais débile, du genre “Oopsie! Something happened, but the fairy is on its way. Why don’t you take a small break in the meantime?”), ça fait moins peur, mais c’est tellement débilisant que ça va finir par rendre tout le monde débile. Et surtout, putain mais qu’est-ce que c’est inutile comme message, et qu’est-ce que ça m’énerve !

    Et pour les développeurs, c’est un véritable cancer cette nouvelle mode. Essayer de comprendre ce qui s’est passé quand le client reçoit un message générique débile sans information, ça n’aide personne.

11. > Complot du monde de l’IT pour irriter les utilisateurs ?

    Le problème vient plutôt du côté design. Ça fait des années que le but des designers est de créer des chemins précis que les utilisateurs doivent suivre à la lettre de A à Z, avec un des objectifs principal de “masquer” le fait qu’on est face à une machine.

    Le moindre petit pet de travers n’est généralement même pas considéré, ça ne doit pas arriver, c’est tout, ça casse l’expérience, c’est mal.

    Je passe tellement de temps à discuter avec des designers pour leur demander “mais il se passe quoi quand tout est pas parfait?”, c’est déprimant parfois. (et ça ne concerne par que les cas d’erreurs, y’a souvent 3/4 cas qui sont totalement ignorés: quand ça lag, quand y’a une erreur, et le cas où le résultat est différent du cas parfait). Après en plus de ça, balancer une erreur avec des détails techniques ça peut être une grosse faille de sécurité. L’ancien reddit est un bon exemple, l’erreur permet (peut-être?) de deviner des infos techniques qui peuvent potentiellement être utiliser pour essayer d’attaquer le site. D’un point de vue sécurité, ça peut être la merde cette erreur. Idéalement un truc entre les 2 serait mieux, mais ça demande du boulot.

    Une grande partie des devs suivent simplement ce que les designers prévoient maintenant: le cas parfait. Dans pas mal de boite aucun temps de dev ne sera même réservé pour le reste: si c’est pas dans le design, ça existe pas.

    (edit: La plupart du temps toutes les erreurs sont remontées aux devs quand même, mais sans prévenir l’utilisateur généralement. Beaucoup de boites n’en ont pas grand chose à faire par contre, à moins que ça n’affecte vraiment beaucoup de monde. J’ai vu pas mal de boites avec des stats achement dévelopées sur les erreurs, mais *personne* qui les regardent, juste quelques bots qui vont balancer des alertes dans des cas très spécifiques de temps en temps. Généralement très mal configurés: soit qui ne détectent quasiment rien, soit qui finissent par être ignorés parce que trop de faux positifs.)

12. Pour moi on est sur un des impacts assez classique de la méthode agile quand le monde de dehors continue d’avancer sans toi. Pour ceux qui ne connaissent pas la méthode agile, le principe c’est de bosser par fragments de 2 semaines. Si je prends l’exemple d’un navigateur sur un bateau, pendant 2 semaines je me concentrer sur bien ramer pour aller droit et vite, puis je prends une journée pour vérifier que je suis là où je crois et vers où aller ensuite, et je repars pour 2 semaines de tout droit. L’idée c’est d’éviter de changer de cap tous les jours et du coup de zigzager, ne pas finir ce qu’on commence, etc.

    Un des inconvénients c’est qu’on fait souvent des choses qui prennent plus que deux semaines. Si je prends l’exemple de l’iban par exemple, on va devoir découper. Y’a des choses qu’on va faire en parallèle et d’autres en même temps mais globalement, le but c’est de gérer le cas nominal, celui qui est assez simple pour être fait en 2 semaines et suffisamment fréquent pour avoir une valeur pour le client ou l’entreprise. Donc ici c’est l’ajout d’un iban valid français. Tu fais ça, ça prend 2 semaines et ça correspond à 90% du besoin de tes clients. Et vient le sprint suivant et là une urgence à fait surface entre temps, un bug détecté, la mise à jour d’un service duquel on dépend, un concurrent qui a pondu un truc ou autre.

    Vient alors le moment de décider : est-ce qu’on s’occupe du truc important, ou est-ce qu’on s’occupe des ibans étrangers, assez rares ? Ou des messages d’erreur quand on ajoute son iban ? Quelle sera la valeur de ces 2 semaines de travail ? Et là l’arbitrage est très souvent le même. Jusqu’au jour où 3 mois plus tard par exemple, la relation client dit “y’a trop de gens qui nous appellent par ce qu’ils n’arrivent pas à saisir leur iban, wtf ?” et là ça devient la nouvelle urgence de corriger ces erreurs, qui vient t’interrompre dans le nouveau truc que tu étais en train de faire.

    D’un point de vue entreprise et valeur, c’est pertinent, tu dépenses tes ressources sur les sujets le plus important à l’instant T, sauf que du coup ça implique souvent de laisser des trucs pas vraiment finis un peu partout…

13. J’y connais rien en téléphone mais, habituellement, qui prévient du manque d’espace pour l’installation de l’appli ? Le système ou l’appli ?

    Si c’est le système et que l’erreur a été génériquisée (néologisme qui me plaît bien) à ce point, c’est effectivement très regrettable. Si c’est l’appli, alors c’est juste qu’elle a été codée avec le cul, non ?

    De manière globale pour tous les autres cas, le but est de simplifier au maximum le parcours utilisateur.

    Moins d’étapes pour aller jusqu’à l’achat, moins de liens pour que ce soit rassurant, moins d’outils disponibles parce qu’on s’y perd, moins d’icône et plus de mots facilement lisibles…

    Les gens en ont rien à foutre de Linux, des modules Firefox, de leur vie privée numérique etc. Ils veulent une interface comme Apple, des achats comme sur Amazon et une compatibilité digne de Microsoft Office.

    On est entre geeks ici et on se positionne pour nos mamies et autres personnes d’un certain âge dans les commentaires, mais dans les faits je peux te certifier que la plupart des utilisateurs ont une approche technique proche de celle d’un mâle de 13 ans face à un clito.

14. One word: WebShit

15. C’est l’économie de marché. Est-ce que, quand tu choisis un produit, tu accordes de l’importance à la qualité des messages d’erreur ? Combien serais-tu prêt à dépenser pour (par exemple) passer à une autre banque qui donne de bons messages d’erreurs ?

    Probablement très peu et donc ça a très peu de valeur pour la banque aussi, et par conséquent, ça ne sera jamais implémenté car ça coûte trop cher vis-à-vis de ce que ça rapporte. C’est le mantra rentabiliste de notre modèle économique. C’est vrai pour les logiciels, les meubles, la bouffe, les transports… Si on peut rogner 10 cm d’espace entre les sièges d’un avion pour augmenter sa profitabilité, on le fait. C’est pareil. Le capitalisme tend vers une maximisation de la rentabilité, pas une maximisation de la qualité. Parfois les deux intérêts convergent, parce que faire mieux que les autres, ça t’apporte des clients, mais c’est pas toujours le cas. Ça dépend de l’importance que les clients apportent à tel ou tel aspect… on a ce qu’on mérite, quoi.

16. OUI OUI OUI OUI OUI.

    (C’est pas très constructif mais je suis d’accord à 100%)

    (À noter que je travaille aussi dans l’informatique et que du coup je pense être un peu plus “compétent” pour comprendre ces erreurs que les gens qui n’y connaissent rien. Je les plains vraiment).

    Le nombre de fois où j’ai dû aller en mode débugger pour trouver l’erreur… Le nombre de fois où j’ai dû piffer totalement aussi pour trouver ce qui posait le souci.

17. Pas le temps pour les beaux messages d’erreur quand tu fais de l’agile mec /s

18. > Développeurs qui n’ont plus le temps de gérer les messages d’erreur, ou qui ont juste la flemme ?

    Dans une boîte à peu près “normale” les développeurs n’ont pas de choix en ce qui concerne les messages d’erreurs et les textes qui s’affichent. Il faut demander au chef pourquoi il a fait de la merde une fois de plus.

19. Il semble y avoir un phénomène similaire de “masquage de la technique” un peu partout. Mais pas sûr que ce soit toujours délibéré comme tu dis.

    Exemples :

    – Des panneaux de chantier qui recouvrent toute vue du chantier, surtout dans les centres commerciaux. Oui, un chantier c’est un peu salissant, c’est **normal**.
    – Logo au démarrage des PC (“splash screen”) au lieu des journaux de démarrage. Non, un PC qui démarre **ce n’est pas sale**. C’est bien chiant quand tu ne peux pas démarrer, pour en trouver la raison.
    – Idem au chargement de certaines pages web.

    Je crois que certains communistes ont une analyse sur la question, supposément ça irait de pair avec la logique “produit” du capitalisme où le consommateur est censé ne pas se poser trop de questions ou chercher à comprendre. Faudrait poser la question dans les écoles de gestion.

20. je schématise

    le message d’erreur qui vient du fin fond du système est très technique mais compréhensible par un informaticien qui connait le contexte

    du coup pour le commun des mortel on l’encapsule, quand le dev est flemmard : “oups ça coince”, quand il s’est un peu cassé le cul avec toutes les erreurs possibles et les a testées (et ça peut être très complexe et chronophage) : “Uniquement les IBAN en français sont acceptés.”

21. pour le coup je n’ais jamais ce probleme sauf quand je dois coder la tout d’un coup il manque des ; ou tel var n’est pas definie, mais sur des lignes vides….

22. Après ça dépend aussi des outils utilisés. J’ai eu un cas où je devais afficher une vidéo de pub (*shame*) et j’avais juste une erreur mais incapable de déterminer si c’était un adblocker ou une erreur du presta de pub. Au début j’affichais un message de vérifier le adblocker mais j’ai eu beaucoup de retours d’utilisateurs se plaignant de ne pas avoir d’adblocker (voir de ne pas savoir ce que c’est) et d’avoir le problème. Et un message “erreur interne ou adblocker, à vous de vérifier” n’a pas été accepté donc on a fini par un simple “erreur interne, réessayez plus tard” en espérant que c’était un problème du presta…

23. (Ingé info)

    Aaaaaaaaaah je suis trigger rien que de lire le titre, j’ai beau savoir quelles sont les difficultés de mettre en place un système d’erreurs résiliant, il n’y a rien de plus frustrant. Surtout quand on est au support et qu’on reçoit des demandes d’utilisateurs qui se résument à “ça marche pas” avec une capture d’écran d’un message d’erreur générique. J’ai beau avoir développé cette appli, même moi je suis démuni face à ça !
    Du coup quand c’est mon tour de signaler une erreur, je fais tout mon possible pour inclure le maximum de détails, mais on est limité par ce qu’on nous affiche au final…