Romain Payet — Pour comprendre la façon dont nous avons commencé à créer le produit digital de Midnight Trains, il faut revenir un peu en arrière. Juste un peu, juste avant le recrutement de Claire, la dernière arrivée dans cette équipe. En effet, après les deux premières missions confiées à Maxime et Yann — dont nous avons parlé la semaine dernière — nous avons commencé à travailler avec Capgemini Invent et Frog.
Cette collaboration a été double. La première partie a consisté à travailler avec les architectes qui nous ont expliqué la façon dont fonctionne un produit digital ferroviaire classique, comment il doit être organisé pour être fonctionnel, ce qu’il doit absolument contenir et ce qui est optionnel. Un échange qui nous a permis d’y voir plus clair sur ce dont nous avons besoin au plan purement technique. La seconde partie s’est passée avec Frog, une entreprise récemment rachetée par Capgemini, avec laquelle nous avons essayé de définir ce à quoi devrait ressembler le produit digital du train de nuit du futur. Nous avons l’ambition de produire quelque chose de très différent de ce qui se fait aujourd’hui. Quelque chose de contemporain, d’intuitif, d’efficace, de réinventé.
Pour cela, nous avons fonctionné par élimination. Ils nous ont d’abord présenté les différents éléments que nous pourrions intégrer en les séparant en catégories. Comme pour l’architecture, il y a des incontournables. Mais il s’y ajoute des options “nice to have”, qui ne sont pas obligatoires mais qui seraient un bonus. Ou encore des features qui, si nous ne les avions pas, classeraient notre site parmi ceux que nous voulons laisser derrière nous, les sites ferroviaires du passé. Les différences entre ces catégories peuvent sembler minimes mais elles ne le sont pas. Elles sont subtiles, ténues. Ce sont ces choix qui vont nous donner de l’avance si nous les faisons bien. Nous avons donc trié progressivement ces options jusqu’à obtenir une V0.
Adrien Aumont — À la fin de ce chantier, sur lequel nous avons avancé rapidement grâce à l’expérience de Capgemini et la pertinence de notre équipe, nous arrivons à plusieurs conclusions. D’abord, il nous semble que même si nous avions une vision précise de ce que nous voulions, tout nous ramène à la complexité. Contrairement à l’hôtellerie, le ferroviaire peut faire face à des impondérables : retard de trains, besoin de maintenance, passagers devant être évacués en urgence, intempéries, etc. Or, ils doivent tous pouvoir être gérés par la partie IT de Midnight Trains. En cas de problème, il faut pouvoir prévenir les gares, les passagers, éventuellement les rembourser, les aider à avoir leurs correspondances, parfois les loger s’ils les ratent et ainsi de suite. Bref, il faut écrire des milliers de scénarios possibles et faire en sorte que le produit digital soit capable de les gérer.
Cette partie s’avère d’autant plus complexe qu’avec un produit digital classique, on peut effectuer des stress-tests, des tests de stress, pour vérifier que tout fonctionne correctement. Mais avec un train, c’est un peu différent. Il est évidemment impossible de faire rouler un faux train avec de faux passagers pour vérifier ce qu’il se passe si l’un d’eux fait un faux malaise ou qu’une fausse chute de neige obstrue les voies.
Romain Payet — Notre seconde conclusion, c’est que le produit digital idéal pour Midnight Trains est un doux mélange entre celui de l’hôtellerie et celui du ferroviaire. Il faut qu’il propose un niveau de service proche de celui des applications des grands hôtels, tout en s’appuyant sur les outils techniques permettant de faire correctement rouler un train. Et pour cause, SNCF Connects ou Trainline ne proposent que peu ou pas de services. Tandis que les applis de l’hôtellerie de luxe en débordent mais ne sont pas adossées à des outils de gestion de circulation ferroviaire. Si on se contente de cela, nos trains n’iront nulle part. Il nous faut donc le meilleur des deux mondes.
Maintenant que nous savons ce que nous voulons prendre dans chaque univers, nous atteignons le point où il faut faire appel à la méthode In or Out, dedans ou dehors. Elle consiste à séparer ce que nous allons adopter comme programmes déjà existants et ce que nous allons coder nous-mêmes. Pour déterminer cela, nous nous lançons donc dans de grandes tournées, des roadshows, au cours desquels nous allons découvrir les différents outils disponibles sur le marché. Trois ou quatre outils d’hôtellerie, quelques autres réservés au ferroviaire et même des hybrides, comme ceux utilisés par les croisiéristes ferroviaires (les trains de luxe au long cours). À chacun d’eux nous donnons notre cahier des charges, nous évaluons l’écart entre ce que nous voulons et ce qu’ils font, puis nous établissons avec eux ce qu’ils peuvent coder en supplément.
Adrien Aumont — Ces entreprises ont toutes des produits déjà développés que l’on peut interconnecter avec l’interface principale. Elles peuvent créer du code supplémentaire si besoin, à condition qu’elles estiment que ce bout de code intéressera d’autres entreprises. Il faut donc qu’elles croient un minimum au développement du train de nuit, qu’elles estiment que d’autres viendront après nous et auront besoin des mêmes choses.
Notre rôle consiste donc à centraliser et à vérifier ce qui marche et ce qui ne marche pas avec les outils que nous découvrons. Puis, plus nous choisissons certains d’entre eux, plus nous nous enfonçons dans de nouveaux niveaux de détails. Maxime et Yann, chacun dans leur domaine, identifient les trous, les bouts de code nécessaires pour que les logiciels — caisse, divertissement, restauration et autres — communiquent entre eux. Le tout avec le gestionnaire d’inventaire comme cœur de réacteur. Quant à Claire, elle nous fait faire un roadshow sur les outils de revenue management. L’heureux élu sera greffé sur ce produit digital qui n’est pas encore terminé à ce jour. Nous vous l’avons dit, c’est un chantier aussi colossal que fondamental.
