05 septembre 2012

L'alerte RATP comme exemple d'erreur de conception

Ayant installé la nouvelle application de la RATP hier, j’ai reçu ma première alerte, ce matin (voir les illustrations). Je parlais hier des besoins et des usages que je pouvais avoir de ce genre d’application.

Certes ! L’usager de la RATP est forcément un peu con, comme le démontre Cyril. Et je ne suis pas le dernier. L’usager veut savoir pourquoi il est bloqué… Du coup, la RATP fait des efforts pour informer les clients, ici par l’intermédiaire d’une alerte, dans les rames, par des annonces du conducteur.

Satisfaire le client (l’usager…) est important une entreprise. Néanmoins, dans l’absolu, je me fous de savoir pourquoi la rame est arrêtée. Ce qui m’intéresse est de savoir à quelle heure je vais arriver au bureau le matin ou au bistro le soir.

Et l’alerte de la RATP ne répond pas au besoin : je n’ai aucune information quant à l’état du trafic, au retard potentiel que je vais prendre… Le « provincial » ne sait pas l’importance de ce genre de perturbation : il n’y a pas seulement un retard ou une attente de dix minutes ou une demi heure, qui serait somme toute tolérable, un tel incident va amener des répercutions sur tout le trafic à cause du nombre de passagers qui va s’accumuler rapidement, empêchant les gens d’entrer dans la rame.

L’alerte que je viens de recevoir est totalement inexploitable. Il me faudrait un truc qui me dise soit « attention, vous allez être un peu perturbé mais rien de grave » soit « nous vous conseillons sérieusement de changer votre itinéraire ».

Je prends l’exemple de cette alerte RATP parce qu’elle est compréhensible par la plupart des gens mais elle est particulièrement significative des erreurs commises par mes collègues informaticiens : ne pas prendre en compte le vrai besoin ou le vrai usage de l’utilisateur mais uniquement ce qui pourrait lui fait plaisir.

C’est bien, c’est ce qui va lui une apparente satisfaction… Mais les avantages pour le lascar qui paye l’application sont dérisoires…

Je vais donner un autre exemple : sur une des illustrations de ce billet, on voit le fond d’écran de mon iPhone quand il est « en veille mais pas trop ». Ce fond d’écran est très moche. Je l’ai mis quand j’ai acheté mon premier iPhone parce que je jouais avec au bistro et c’était la vue que j’avais.

Un lascar moyen s’empressera de le remplacer avec la photo d’une jeune fille nue mais, au fond, ce fond d’écran ne sert strictement à rien, on ne le regarde jamais… Il pourrait être totalement noir…

Edit : juste après avoir publié ce billet, j'ai reçu une nouvelle alerte m'indiquant que le trafic reprend progressivement. Là, l'information est intéressante : je n'ai plus à me presser...

8 commentaires:

  1. C'est vrai qu'elle est nulle cette alerte, si au moins on t'avais dit que le voyageur avait la peste bubonique, tu aurais su que tu avait tout intérêt a rebrousser chemin (on sait jamais, c'est contagieux ces trucs)

    RépondreSupprimer
    Réponses
    1. Ah ben tu tombes bien, toi, je viens de faire un billet à propos du JEGOUNOTRON.

      Supprimer
  2. j'imagine toutes les alertes absurdes et les causes de retard que l'on pourrait voir : Conducteur a envie de pisser, Chef de gare saute la caissière,...

    RépondreSupprimer
    Réponses
    1. Ouais. Faudrait que ça envoie un mail au chef : "votre collaborateur est retard parce qu'une cliente suce le mécanicien".

      Supprimer
  3. Réponses
    1. Oui, mais ça pompe la batterie : il faut des mails...

      Supprimer
  4. J'utilise le tag #qml sur twitter et suit quoimaligne, alimenté par les internautes, il m'a sauvé de soirées RERB+ plusieurs fois . Ce qui est amusant c'est que la ratp n'avait reservé que le nom de quatre lignes et des petits malins se Sont rués dans le #fail créeant meme des lignes assez exotiques comme la 17...

    RépondreSupprimer

La modération des commentaires est activée. Je vous lis, voire vous publie, après la sieste.