Isabelle André nous fait part de l’ensemble des défis techniques et humains auxquels elle a dû se confronter lors du passage d’IdTGV à la nouvelle offre low-cost de la SNCF : OuiGO.
Ayant débuté sa carrière en tant que Revenue Manager pour la compagnie aérienne Air France, c’est en 2009 qu’elle rejoint le monde ferroviaire en intégrant Rail Solutions, filiale de la SNCF. Elle devient en 2015, la DSI de OUIbus, l’offre de cars longue distance de la SNCF, puis directrice générale d’iDTGV et enfin, DSI de OUIGo depuis 2018.
Au sommaire de cet épisode :
I) Squirel : la DSI de OuiGo, l’offre low-cost de trains à grande vitesse proposée par la SNCF. Quelle histoire et quelle organisation pour la direction des systèmes d’information de OuiGO ?
II) Le passage d’iDTGV à OUIGo : quelles conséquences sur l’organisation et sur les ressources humaines ? Isabelle André évoque le défi majeur qui s’est présenté lors de la transition d’IdTGV à la DSI de OuiGO, en lien avec ses effectifs.
III) La proximité avec les directions métiers pour mieux saisir leurs besoins et leurs attentes. La mise en place de “flash études” et de “flash design” au centre de la méthodologie d’Isabelle André.
I) Squirel : la DSI de OuiGo, l’offre low cost de trains à grande vitesse proposée par la SNCF
Quand IdTGV a été stoppé, c’est toujours la même équipe qui s’occupait de ce système d’information et à ce moment-là, il fallait transformer IdTGV en une société qui continue à assurer l’informatique de OuiGo. On a donc proposé un projet de transformation : on souhaitait transformer IdTGV (dont l’objet social était en train d’être changé) pour en faire ce qui est devenu Squirel.
Historiquement, il existait une entité propre à la SNCF qui s'appelait IdTGV. Au moment où l’offre OUIGo a été créée, c’est l’équipe informatique d’IdTGV qui a monté le système d’information de OUIGo. À la base, l’équipe IdTGV était composée d’une centaine de personnes dont une vingtaine correspondait à l’équipe IT.
Lorsque iDTGV a été stoppé, c’est toujours la même équipe qui s’occupait de ce système d’information. En parallèle à cela, il fallait transformer IdTGV en une société qui continue à assurer l’informatique de OuiGo. Isabelle André a donc proposé un projet de transformation : elle souhaitait transformer l’équipe IT IdTGV (dont l’objet social était en train d’être changé) pour en faire ce qui est devenu Squirel.
Squirel, c’est avant tout la DSI de OuiGo, qui est restée filialisée. OUIGo est l’offre de transport de passagers low cost de la SNCF. D’un côté, il y a TGV Inoui, l’offre classique de TGV et puis OuiGo, qui est, disons, l’innovation de la SNCF, qui consistait à proposer des prix plus petits aux clients en changeant le modèle de production ferroviaire.
Le product owner, je le mets en corrélation avec le chef de projet. Quand c’est un produit externe, c’est pas le même rôle qu’avec des développeurs donc dans ces cas là, on peut les appeler chef de projet. [...] D’ailleurs, on devrait même dire que c’est proxy product owner (proxy-PO) parce qu’en réalité, le vrai product owner, il est souvent du côté des métiers.
Squirel est composé de trois pôles principaux :
- Le premier est constitué d’une seule personne : le delivery manager. Il est celui qui, pour chaque client, va avoir la vue d’ensemble de tous les sujets que la DSI traite. C’est la personne qui est en copie de tous les mails et qui va connaître le périmètre d’action de tous les projets, de toutes les tâches, etc.
- Le second est le pôle de développement. Cette équipe va développer les applicatifs que Squirel souhaite mettre en place pour OUIGo. En général, ce sont des middleware qui permettent à toutes ces briques de communiquer entre elles et qui vont être utilisées pour les canaux de vente internet ou pour les applications mobiles utilisées par les contrôleurs. On retrouve aussi des spécialistes infra réseaux qui s’occupent de l’hébergement et du monitoring.
- Le troisième est le pôle “projet/applicatif/recette”. Dans cette entité, on retrouve :
- Plusieurs chefs de projets ou des product owners. Leur rôle est double selon le fait que la DSI travaille sur du développement interne ou sur des services (SaaS souvent) apportés par des éditeurs de logiciels. Il y
- Des analystes qui vont aller dans l’analyse de l’impact d’un sujet en particulier, contrairement au product owner qui va être plus sur l’ordonnance de la roadmap chez les fournisseurs internes ou externes pour faire arriver tous les features dont on a besoin par rapport à l’ensemble des demandes de la .
- Des experts en matière de support et de recette. Squirel fait beaucoup de recettes en interne. C’est un modèle qu’à déjà connu Isabelle Andé lorsqu'elle a travaillé pour Ouibus. L’accent mis sur la compréhension du besoin métiers et clients, pour faire en sorte que la vraie recette utilisateur formelle soit la plus légère possible.
À retenir :
-
Squirel est organisé de telle manière à avoir un pôle de développement qui s'occupent des applicatifs que la filiale souhaite avoir et de la gestion de l'hebergement cloud. Un pôle projets/applicatifs/recette a la double casquette chef de projet et proxy product owner, des analyses seront présents pour analyser l'impact d'un sujet et une équipe s'occupe également de la recette et du support. Enfin, un Delivery Manager centalise les données et constitue le point d'ancrage de l'obtention d'une information sur un client ou sur des projets internes.
II) Le passage de IdTGV à Ouigo/Squirel : quelles conséquences sur l’organisation et sur les ressources humaines ?
Certains d’entre eux ont vécu ce changement comme un traumatisme. Quand t’es au service d’une offre et d’un produit sur lequel tu as longuement travaillé et qu’on te dit « Maintenant, tu vas être au service d’un nouveau produit » et qu’on te retire l’ancien, qui peut être perçu comme celui qui fait que le produit sur lequel tu travaillais est « mort »
Isabelle André s’est vu proposer le poste de DSI de OUIGo lorsqu’elle était DSI de OUIbus. Grâce à cette première expérience en tant que DSI, le pilotage d’une direction informatique au service d’une offre low cost n’était pas un aspect inconnu pour elle. Ce qui l’a intéressé dans cette proposition, c’est qu’au-delà du challenge d’opérer la SI pour une offre en pleine croissance, il y avait également un challenge “humain”.
Au moment où l’offre IdTGV a été arrêtée, la moitié des collaborateurs de la DSI de cette offre ont démissionné : un véritable coup dur pour Isabelle qui voit certains de ses meilleurs experts partir pour d’autres structures. Il y a eu tout un défi de réussir à remobiliser les personnes restantes au service de la nouvelle aventure OUIGo. Les collaborateurs restants étaient « orphelins » de leur produit IdTGV qu’ils avaient perdu, et de leurs collègues avec qui, ils ne travaillaient plus.
Isabelle André considère que cela a été un gros travail qui a duré environ six mois. Selon elle, ce qui a été déterminant a été le travail autour du changement de nom, du passage de la SI de iDTGV vers celle de OUIGo. Elle a utilisé ce changement de nom pour travailler avec toute l’équipe sur les valeurs qu’ils prodiguent lorsqu’ils travaillaient ensemble.
Ainsi, le nom “Squirel” est en fait un synonyme de “petit écureuil” car l’équipe se voyait comme étant petite, agile, dynamique, proche, rapide et sympathique. À partir du moment où le changement de nom a été effectif, la SI a réussi à tourner la page, la nouvelle équipe SI était actée.
TPersonnellement, je considère et je leur rappelle tout le temps qu’on ne fait pas de SI pour une centrale nucléaire, on fait de la SI pour des clients qui vont prendre le train. Il est tout à fait possible de se mettre à la place de personnes qui prennent le train pour comprendre ce qu’on demande. C’est quand même un métier qui est sympa car on peut tous devenir, du jour au lendemain, le client de cette offre.
À retenir :
-
Lors d’un changement d’offre, attendez vous à ce qu’une partie de vos futurs effectifs ne soient pas convaincus par ce nouveau produit.
Dans le monde du digital, il existe souvent de grosses tensions sur les effectifs et il n’est pas facile de recruter.
Il faut faire en sorte de remobiliser l’équipe : il faut que vous réussissiez à ce qu’ils soient concernés par la nouvelle offre proposée afin qu’ils puissent travailler ensemble dans la bonne humeur.
III) La proximité avec les directions métiers pour mieux saisir leurs besoins et leurs attentes
Exprimer ses besoins au travers d’une vidéo ? L’intérêt, c’est que ce soit interactif, un peu comme un brainstorm. Je te parle vraiment un moment où on est à l’émergence du besoin côté métier. Je pense que la vidéo, ça peut être intéressant si ça permet d’avoir, en live vraiment, le vrai enjeu qu’il y a derrière, mais je pense qu’il faut qu’il y ait échange et interactivité qui fait que la personne du métier te parle de son idée pour qu’ensuite, toi, tu puisses réagir et l’orienter vers des solutions différentes et plus facile à mettre en place.
Au sein de OUIGo, La DSI n’est pas une filiale externe de prestation de services. Cela permet une articulation managériale et une compréhension des enjeux, en circuit très court, contrairement à ce qui peut exister en externe où l'information transite auprès de nombreuses personnes. Grâce à sa casquette de DSI de OUIGo, Isabelle André est présente dans le comité de direction de OuiGo et donc présente dans toutes les réflexions stratégiques : elle est ainsi alimentée en direct sur l’importance relative de tous les sujets qui incombent l’offre.
Sa méthodologie avec les directions métiers est la suivante : avec son équipe, elle évalue très rapidement un sujet émergent à l’aide de “flash études”. Une réunion est organisée entre son équipe et l’équipe métier demandeuse. Pendant deux heures, la direction métier peut expliquer le sujet, ses ressentis, les techniques qu’ils vont utiliser pour mener à bien le projet. La SI, elle, peut réagir promptement et rapidement afin de les orienter au mieux. C’est ce qu’Isabelle André appelle un “flash design”.
Parfois, certains membres de son équipe considèrent que ces deux heures sont une “perte de temps”, qu’évoquer un projet émergent qui ne sera effectif que dans plusieurs mois n’est pas important tandis qu’ils sont sur le qui-vive pour d’autres projets plus importants sur le court terme. La réponse de la DSI est clingante : elle considère que cela vaut le coup de poser deux heures, deux ou trois fois dans le mois pour éviter qu’un métier passe plusieurs semaines à rédiger une expression de besoin que ses équipes vont mettre plusieurs jours à lire et à analyser.
L’exemple parfait de cette dynamique de travail est le pass sanitaire. Rendu obligatoire dans le train le 12 juillet pour le 1er aout. Donc une quinzaine de jours pour préparer cela.[...] Imagine si les différents métiers impactés par ce changement avaient pris du temps à nous faire un cahier des charges, avec des expressions de besoins détaillés. Le temps qu’on reçoive toutes ces informations, on n’aurait pas été alimenté rapidement et efficacement. On a donc travaillé d’arrache-pied avec nos équipes pendant deux semaines afin de développer la solution en collaboration avec les équipes SNCF.
Pour ce qui est de la petite demande d’évolution, au lieu de passer par des flash designs, Isabelle André privilégie un système de ticket. Cette pipeline de demandes est analysée et discutée par le Codir tous les trois mois environ et est classé selon une maturité métier et une maturité SI.
À retenir :
-
Être présent dans les réunions du comité exécutif en tant que DSI est un véritable plus pour mieux comprendre l’évolution de l’offre et les attentes du Codir.
Ne pas hésiter à faire des “flash design”, des petites réunions de deux heures maximum pour discuter avec un métier, d’un sujet émergent.
Pour les demandes d’évolutions qui ne sont pas des projets émergents : un système de ticket prend le relais.
Conclusion
Il y a malheureusement beaucoup d’entreprises, peut-être de moins en moins, où l’on met l’informatique un peu en soute et loin du métier, et je pense que c’est des modes d’organisations qui ne permettent pas d’être efficient car cela fait trop d’intermédiaires entre le vrai enjeu et ceux qui mettent en production. Ça ne permet pas d’avoir du développement agile ou des circuits courts de décision et de compréhension. Et ce modèle double d’avoir la responsabilité d’une équipe tout en étant au comité de direction, c’est le modèle le plus performant.
Dans ce podcast, Isabelle André nous a présenté comment elle a organisé son équipe SI pour faire en sorte d’être en adéquation avec la nouvelle offre proposée par la SNCF, OUIGo. Elle a dû composer avec une équipe qui a été “orpheline” de son projet initial, iDTGV et a eu pour défi de réussir cette transition vers Squirel, la DSI de OUIGo. Cette immense équipe est composée trois pôles au sein de son équipe : un delivery manager, le pôle de développement et le pôle projets/applicatif/recette, pour une meilleure hiérarchisation du travail.
Afin de mieux travailler avec les métiers et de hiérarchiser les projets, elle a mis en place des “flash design” ainsi qu’un système de tickets. De plus, sa position prépondérante de DSI de la filiale lui permet d’être au plus près du Codir afin de mieux cerner l’évolution de l’offre et les idées émergentes.
