Pas le temps de lire ?!: cet article revient sur l’échec industriel de SNCF Connect et soutient la théorie que le projet était raté dès le départ, plombé par une ambition disproportionnée,
Avertissement: il s’agit d’un article d’opinion. Je me base sur l’expertise acquise au fil de mes années d’expériences autour des projets informatique pour déduire ce qui a pu mal se passer durant la construction de SNCF Connect. Je peux bien évidemment me tromper; au delà de cette évidence, je tiens à rappeler qu’il ne s’agit pas de juger les acteurs de cette catastrophe, mais bien de mieux la comprendre pour éviter de la reproduire. Enfin, même si je mets en avant certains aspects précis, une catastrophe est le résultat de plusieurs défaillances et il est mensonger, et impossible, d’identifier une cause prétendument unique.
Point de départ
J’ai suivi le sujet depuis le début, tout d’abord en tant qu’utilisateur qui a subit les avanies de ’SNCF Connect’ mais ensuite très vite en tant qu’informaticien. Si l’envie d’écrire sur ce sujet était là depuis longtemps, c’est la sortie d’un très bon article (le Ticket: Dans les coulisses produit de SNCF Connect, l’appli qui a déraillé dès le départ) qui m’a poussé à mettre mes idées sur octets. Il retrace l’historique du projet tel que vu de l’intérieur. Je vous invite à le lire, car je ne vais pas le résumer, mais m’appuyer dessus pour mon analyse.
Tout va bien maintenant!
Globalement, la plupart des problèmes rencontrés au départ sur SNCF Connect sont réglés. Nous sommes 8 mois après le go live tout de même, le contraire eut été impensable. Mais surtout, il faut se rappeler du battage médiatique à sa sortie, où elle est annoncée comme la 8ième merveille du monde, alors que les utilisateurs découvrent une appli mal ficelée, jugée moche et qui ne marche que par accident, en descente et avec le vent dans le dos.
Après une campagne de communication choc: l’appli est très bien, ce sont les utilisateurs qui n’ont pas compris; l’entreprise réagit face à l’ampleur de la boulette et se met au travail. Les plus gros bugs ont été réparés, quelques options ajoutées et ou revues dans les semaines et mois qui suivent.
Il reste un impact d’image terrible.
Pas vraiment un succès donc.
Qu’est ce qui s’est donc passé ?
1. Une erreur stratégique avant tout
Sur la base du récit tel qu’il est présenté dans l’article le projet était condamné à l’échec peu après avoir été lancé.
Objectifs contradictoires
D’une part, l’idée est de faciliter la vie des utilisateurs SNCF Connect est moins une nouvelle application qu’un nouveau positionnement produit.
… ne pas seulement se positionner comme un opérateur de trains mais bien comme un acteur de la mobilité globale “porte à porte”, du premier au dernier kilomètre
Ces ambitions sont orthogonales: je veux faciliter la vie des utilisateurs, et je veux qu’il me comprenne comme faisant plus que du train (du coup, quoi?). Au fait, la ‘vie des utilisateurs de quoi’?
Courir 2 lièvres est la garantie d’en n’attraper aucun.
Ce qu’il fallait faire selon moi
Prudence et simplicité
Choisir entre ces 2 ambitions: soit on veut une nouvelle appli intégrant les 2 existantes et on laisse tomber le côté ‘acteur de la mobilité totale’, soit offrir une nouvelle offre et construire une nouvelle appli en plus des existantes, quitte à basculer la ou les applis existantes quelques temps plus tard.
2. Méconnaissances des besoins existants
Le prototype, lui, a été élaboré autour de 4 cas d’usage :
L’achat d’un billet TGV en aller-retour et en multi passagers (la base de OUI.sncf)
La recherche de mobilité urbaine en Île-de-France (la base de l’Assistant)
L’achat d’abonnement TER régionaux
L’accompagnement des personnes à mobilité réduite
Cas « d’usage »?
Le cas 1, qui est mon principal, voir unique, usage à titre personnel, a été infernal depuis la toute première version: trop de manipulations, besoin de ressaisir à chaque fois les noms des voyageurs….
J’ai vu des gens râler pour le cas ‘4’ parce que justement, les infos sur la compatibilité fauteuil roulant était introuvable.
Quand on a manipulé les premières versions de SNCF.Connect, on est amené à ce demander ce qu’il mettait derrière ces cas d’usage ? C’était sans doute les seules fonctions implémentées, mais leur usage était combats et souffrances pour l’utilisateur.
Ce qu’il fallait faire selon moi:
Le problème n’est pas nouveau, et est essentiel à la réorganisation de la SNCF en plusieurs structures: Voyage-SNCF se comporte en vendeur de billets et non en voyagiste.
Typiquement, le cas d’usage 1 devrait être: je dois voyager à plusieurs (en famille?) du point A au point B.
Voyager, pas acheter des billets. Acheter des billets est un pré-requis pour effectuer le voyage, pas une fin en soi.
Cette définition aurait permis d’identifier et de régler les problèmes liés à la multi saisie de certaines infos durant le cycle de vie du voyage, le fait qu’il est honteusement compliqué de retrouver son numéro de place dans le billet (encore aujourd’hui), le fait que les QRCodes ne passent pas sur les bornes…
Et dans l’idée de simplifier la vie des voyageurs, j’aurai ajouté le support de voyage plus complexe, tel que l’aller ou le retour sont à des dates différentes pour les passages; variante, certains passagers ne font qu’un aller. Ces cas doivent actuellement se gérer à la main, en espérant obtenir un placement proche dans le train et de ne pas se tromper sur les numéros de trains choisis.
Les principes sont là pour ne pas être appliqués
En découlent les 5 principes de l’expérience client de SNCF Connect, qui doit ainsi être un service :
fiable (qui sécurise les trajets)
inclusif
proactif (qui favorise l’autonomie de l’utilisateur)
délivrant une expérience globale cohérente
et responsable
J’ai envie de voir quelqu’un essaye de m’expliquer en quoi SNCF Connect répond à un quelconque critère de cette liste.
3. Organisation inadaptée
De la loi de Conway jusqu’à ‘Team Topologies, en passant par ‘Mythical Man Month’ et le ‘Blue Book’ (DDD), l’importance de la structure pour la réussite de ce type de projets fait partie de la connaissance générale des ITs un poil expérimentés. Donc, l’idée d’ajuster l’organisation semble légitime; encore faut-il le faire correctement…
Des feature teams aux impact teams
En effet, on l’a évoqué au préalable, ce projet a été l’occasion de tester un nouveau modèle d’organisation. Auparavant, chaque équipe de OUI.sncf s’occupait d’une partie spécifique du parcours client (le panier, la page des résultats, le paiement, le compte client etc.). Autrement dit, un fonctionnement en feature teams (“à la Spotify”, si tu préfères).
…
Là, ils n’ont rien compris aux feature teams: il y avait une organisation fonctionnelle classique, qu’ils appelaient « feature teams » (qui n’en n’étaient pas), et ils ont tentés de basculer en feature teams, en les appelant des impact teams (spoiler: qui n’en seront toujours pas); vous suivez ?. Et qu’ont-ils choisi comme ‘impacts’ ?
La vente et de l’après-vente des billets de train
La présentation des résultats de recherche multimodaux et des déplacements du quotidien
L’accompagnement du client dans son voyage
La personnalisation des interfaces et du compte client
L’intelligence artificielle
et d’autres non donnés.
Ces « impacts » sont très dépendants les uns des autres: la vente dépend de la recherche, l’accompagnement doit dépendre de l’après-vente… Quant à « l’intelligence artificielle », je suis sans voix. Cela désigne tout ou rien.
Moi, j’y voit des équipes fonctionnelles, interdépendante, mais sur la base d’une cible fonctionnelle différente de la précédente.
Toute transformation de ce genre entraîne à minima une dilution de l’expertise, mais le plus souvent une perte sèche: on ne sait plus vraiment comment cela fonctionnait avant. L’hypothèse de la bascule en feature teams, est qu’elle permette de garantir l’arrivée de fonctionnalités complètes pour l’utilisateur, au prix d’une perte (acceptable) d’efficacité interne. Ça, je soupçonne que personne ne leur ait dit.
Mais ici, il s’agit juste d’une réorganisation vers de nouvelles fonctions, le bilan est donc uniquement la perte de compétences. Résultats, retards supplémentaires et dysfonctionnement.
Ce qu’il fallait faire selon moi:
Ne pas changer l’organisation, mais ajouter des products/UX owners/leads, en charge de surveiller la bonne implémentation (de bout en bout) des cas d’usages listés précédemment.
Alternativement, avoir des VRAIS feature teams, basé sur les cas d’usages listés.
Cela reste difficile à dire en l’absence d’élément sur la structure socio technique (architecture du système et/ou organisation des équipes); mais la révolution retenue conduisait nécessairement à une belle collection de problèmes.
4. Tests: un drame classique en 3 actes
1 Une stratégie de test insuffisante
Dans le plan de bataille initial, … avoir un semestre entier pour la phase de “mise en qualité”
La stratégie de test s’appuie massivement sur une phase de test concentrée sur la fin du projet. Note: Il est probable qu’il y ait eu des tests automatisés (ou non) internes effectués par les différentes équipes, mais du fait d’une organisation fonctionnelle et non ‘features’, ces tests ne permettent pas d’évaluer le produit final.
2 …et qui n’est pas correctement exécutée
… (à peine trois mois avant le lancement donc), des versions d’évaluation “bêta” sont déployées respectivement sur mobile puis sur Web. Elles sont mises entre les mains des équipes SNCF & Tech…Et de quelques utilisateurs externes… obligés de venir les essayer au sein des locaux de l’entreprise, sans pouvoir repartir avec.
Sans surprise, cette phase de test est sévèrement raccourcie du fait des retards du projet. Qui plus est, ce n’est pas une campagne de test traditionnelle, pas plus qu’une phase beta ou alpha. C’est juste se donner une occasion de remonter des bugs si jamais on a le temps de tester l’application. Je soupçonne d’ailleurs que l’application ne soit pas reliée à la production, et ne permette donc pas d’obtenir de vrais billets.
Donc, en gros, cela permet de faire des smoke tests et c’est tout.
3 des bons bugs bien gras le jour du go live
Rappel, les bugs sont toujours découverts par quelqu’un. Mais quand c’est par les clients, ça coûtent beaucoup plus cher…
Un drame à la sortie. Le sujet a fait la une des journées en Février 2022, voici un article
Un mois plus tard, la situation n’est toujours pas brillante
5. Bonus: une tentative de coup avec la « kailler fiture »
“La barre de recherche unique, qui a tant fait parler, a été testée et validée dès ce moment. Ce fut le premier parti pris fort de la nouvelle application”, confie David Ruiz.
Personnellement, j’ai fait marcher la barre de test sur les exemples donnés: par exemple, Paris Nantes, ça marche.
Par contre, je vais régulièrement aux Sables d’Olonne, ce qui était systématiquement refusé par la fameuse barre de recherche. En fait, j’ai découvert que cette barre de recherche partait en sucette dès qu’on entrait un nom de ville composé. Le nom était découpé, chaque partie transformé par approximation. Typiquement, Paris les Sables D’Olonne se transformait en Paris Sablons (qui est une gare de métro à Neuilly).
En préparant cet article, je suis tombé sur ce tweet qui illustre encore mieux le niveau proprement hallucinant de cette fonction lors du go live:
Le trajet Paris-Toulouse n’est même pas proposé dans les résultats!
Perso, il me semble que tester cette barre de recherche sur les quelques centaines/milliers de nom de gare était assez faisable en automatique….
et je ne rentrerai même pas dans le débat de l’UX au final: je pense que même une fois fonctionnelle, elle restera médiocre; mais si le sujet vous intéresse, je vous recommande cet article ici, qui finira de clouer le cercueil de ce projet.
Autres illustrations des divers problèmes, du point de vue design:
Au fond, un problème d’arrogance
Au delà des problèmes d’exécutions purs évoqués dans l’article que j’ai cité au début et des défauts de démarche que je liste ici, il y a sans doute un problème au niveau du sponsoring de ce projet. Refonte importante au départ, il a été transformé en objectif stratégique à part entière ce qui a ouvert la porte a une forte augmentation des exigences. S’y ajoute une bien dommageable arrogance qui s’est manifesté de deux manières:
- L’exigence du secret: comme si cette application allait révolutionner l’industrie du voyage. On peut imaginer le meeting où quelques CxO se sont plus à imaginer qu’il tenait le nouvel ‘iPhone’ via la ‘Barre’
- Les réactions de la SNCF suite aux premières remontées qui avaient un fort relent de: nos clients sont trop cons pour comprendre qu’on vient de changer leur vie, mais ils vont y venir
L’exigence du secret a parfaitement fonctionné. En interdisant tout période beta grand publique, démonstration intermédiaire ou discussion avec des vrais utilisateurs, elle a permis à cet échec d’éclater au grand jour en une seule fois, façon final de feux d’artifice.
Quand aux réactions, outre le fait qu’elles n’ont pas aidé en terme d’image, elles indiquent clairement que le top management n’a jamais touché l’application (pas plus que la précédente d’ailleurs, sans doute).
Je me demande à quoi ressemble une réunion de GoLive chez eux, d’ailleurs…
En conclusion
J’espère que cet article vous a apporté un angle de vue différent sur le sujet; même si je ne peux guère défendre ce résumé, qui est très circonstanciel et indirect, je reste convaincu que je suis proche de ce qui s’est réellement passé.
Qu’en retenir ?
- Un projet peut être plombé dès le départ et que c’est important à détecter pour ne pas être pris dans la tourmente
- Le secret n’aide jamais (aller, peut être dans 0.001% des cas)
- Il ne faut pas délibérément changer tout en même temps. Il faut changer ce qui est le plus important, d’un point de vue stratégique, et laisser le reste s’aligner.
