Aller au contenu
AFUP Forum PHP 2024 Baromètre Planète PHP PUFA
 

GRAOU : la production ferroviaire collaborative

Description

Les conducteurs et contrôleurs des trains SNCF ont toujours eu leur planning au format papier. En tant que conducteur de trains, j'en avais assez de le saisir tout à la main, et me suis mis en tête de créer un outil simple de synchro entre nos agendas électroniques et nos métiers. Puis en voyant les données passer, et grâce à l'arrivée de l'openData, le champ des possibles est devenu immense : qui est sur quel train, quel matériel, quels statistiques, quand vais-je croiser mes collègues, où manger, qui dort où, etc. et tout ça dans une web-app construite from scratch en PHP/MariaDb, un peu de JS et une grosse réflexion UX (le métier développe pour le métier !). GRAOU est aujourd'hui la première application interne collaborative SNCF, unanimement plébiscitée et massivement utilisée par les agents concernés. C'est l'histoire d'un conducteur de trains qui jongle désormais avec les containers docker et optimise php-fpm pour gérer les 800k vues/jour...

Conférence donnée lors du PHP Tour Montpellier 2018, ayant eu lieu les 17 et 18 mai 2018.

Informations complémentaires

Vidéo

Le speaker

Nicolas WURTZ

Bac littéraire, conducteur de train, et devOps (c'est possible). Aujourd'hui chef de projet à la direction Digital SNCF, Nicolas Wurtz s'occupe principalement de prototypage et de rappeler la réalité d'une circulation ferroviaire ou d'un serveur.

Commentaires

Brillant !
Grégoire HUBERT, le 18/05/2018
impressionnant ! bravo !!
lnc, le 19/05/2018
Super conf, ça s'est senti vu la standing ovation à la fin. Pas très technique mais inspirant, Bravo !
Jonathan Champion, le 21/05/2018
Un bel exemple d'une application avec un vrai but sociétal, très inspirant. Très intéressant (révélateur ?) aussi, le rapport entre l'homme et sa société, l'homme et sa direction à la SNCF. Un grand bravo pour la forme et le rythme de la présentation !!
Steven VAN POECK, le 22/05/2018
Conférence intéressante sur la technique et la gestion de projet et la conduite du changement, par un orateur qu'on aimerait revoir sur d'autres sujets ! #gommettesSurLeFront
Sarah Haïm-Lubczanski, le 23/05/2018

Transcript

Merci beaucoup, merci d'être là. Je suis Nicolas Wurtz, je conduis des trains depuis 15 ans chez SNCF.

J'ai un bac littéraire... ne partez pas ! J'ai fait pas d'administration système et de développement sur mon temps libre, j'aime bien.

Je suis de ces gens qui peuvent compiler un driver d'imprimante de 23h à 8h... sans que ça marche ! J'aimerais vous raconter une histoire. Je vais pas vous parler de technique, des gens très qualifiés et très compétents qui le font ici.

Je vais tout simplement raconter la petite histoire de pourquoi et comment, pour faire plaisir à mon épouse, j'ai fini par créer une application à laquelle je m'attendais pas forcément, qui est aujourd'hui l'application collaborative interne la plus utilisée chez SNCF.

GRAOU : Gestion des Roulements Assistée par OUrdinateur - il n'y a pas de faut de typo, sinon ça faisait GRAO, c'était nul ! On va revenir sur la gestion, sur pourquoi un roulement, de ce que c'est, etc.

Mais on va commencer par un truc un peu pénible, surtout à cette heure-ci ! J'ai aucune prétention, j'ai l'impression de présenter mes lasagnes à des grands chefs ! Je ne vais pas parler d'objets ni de Symfony, j'y viendrai un jour dans ma vie mais je n'y suis pas encore.

J'appartiens une petite entreprise qui s'appelle SNCF, que vous connaissez peut-être.

Quelques fondamentaux (pas parce qu'il me l'ont demandé mais vraiment pour établir certaines vérités) : c'est un grand groupe public ferroviaire de 260 000 salariés, avec un chiffre d'affaires de 32 milliards par an et 1,6 milliard de bénéfices.

C'est important parce que quand on parle de la dette, c'est celle du réseau, du gouvernement qui a demandé à faire du TGV, mais derrière l'entreprise est rentable, notamment Mobilités, le transporteur qui transporte des gens et du FRET.

La SNCF est constitué de 3 EPIC (Etablissements Publics d'Intérêt Commerciaux) : SNCF, l'entité de tête, SNCF Mobilités et SNCF Réseau.

Aujourd'hui, je suis plus dans Mobilités qui gère les conducteurs entre autres, je suis dans la direction tête, dans la direction du digital, on fait des choses qui me plaisent beaucoup plus que ce que je faisais avant, même si conduire un train c'est quand-même rigolo ! SNCF Mobilités contient quatre activités : Voyages (TGV), Transilien, Intercités et TER, entre autres parce qu'il y a aussi le FRET, Gare et connexions et pas mal d'autres choses.

Mais on va s'intéresser plus particulièrement à SNCF Mobilités, parce qu'elle contient les "roulants" : une catégorie professionnelle particulière avec un statut particulier dans le statut déjà particulier de la SNCF.

Les ADC et les ASCT - on adore les acronymes chez SNCF, on en a plus de 3000, on a même un dico pour les nouveaux entrants ! ADC : agents de conduite et ASCT : agents du service commercial des trains, soit environ 20 000 personnes qui sont tous les jours (pas tous en même temps) à bord des trains, et qui vont souvent être amenés à dormir à un autre endroit 2 à 3 fois par semaine, qui seront absents pour les fêtes, pas là forcément avec leurs enfants quand il le faut.

C'était mon métier, c'était sympa, ça laisse du temps libre à la maison en journée mais avec certaines contraintes (compensées d'une autre manière).

Et le moment très compliqué, très pénible : chaque conducteur ou contrôleur, dans son année de formation, va apprendre à lire un planning de conducteur ou de contrôleur comme celui-ci.

Les traits noirs ce sont des trains (ça va de minuit à minuit), ça se lit verticalement et horizontalement.

On voit l'heure de prise de service, les tâches (préparer le train, vérifier les freins, etc.), ensuite on fait un train, on a un petit battement, on fait un autre train, encore petit battement, etc.

Le lieu où on va est marqué aussi, c'est pas très clair mais c'est juste pour vous montrer.

Ça ce sont des journées de service avec un nom précis, un validité donnée, de telle date à telle date, etc.

Quand vous devez faire par exemple la E421, elle roule le lundi mais avec deux variantes, et soit vous pouvez rentrer chez vous le soir, soit vous enchaînez encore deux trains.

C'est assez compliqué à lire, faut pas se tromper et encore aujourd'hui officiellement, le planning d'un conducteur ou d'un contrôleur, c'est ce papier.

Ces journées de service sont organisées dans une grille.

C'est pas si compliqué que ça : une grille c'est l'organisation des journées à la suite (c'est important de comprendre ça pour la suite).

Par exemple, si je sais que le lundi 14 août je vais faire la E321, le lendemain je vais celle-ci et ainsi de suite.

Donc une semaine après, je serai sur la ligne 2. La semaine suivante la 3 et ainsi de suite.

Donc si je sais qu'à telle date je fais la E230 je peux vous dire qu'à telle autre date je ferais la E945.

J'en reviens à mon épouse : vous lui donnez ça et vous lui mettez sur la porte du frigo.

"Comme ça, Chérie, tu sais ce que je vais faire et comment je vais travailler".

On met les dates, on rature quand il y a des congés, et puis on espère qu'elle va pas se tromper ! Mon épouse étant une femme brillante qui n'a pas envie de se casser la tête (c'est pour ça qu'elle est brillante), me dit de mettre ça dans un Google agenda partagé ("ce sera beaucoup plus simple").

Donc tous les six mois, Bibi rentre tout ça à la main pendant 3-4 heures ! Comme tout bon informaticien, je suis très flemmard, donc j'ai préféré passer trois mois développer du code pour m'économiser ces quelques heures tous les 6 mois ! Pendant les vacances d'août 2014, j'ai voulu transformer cette grille et ces données, les convertir dans un format ICS et l'envoyer dans du Google Calendar.

Sauf qu'en voyant les données passer je me suis dit qu'on pourrait en faire plein de choses...

On peut les afficher, les contextualiser, les lier à l'open data (en train d'arriver), et puis faire un truc un peu sexy.

Donc GRAOU, c'est c'est ça la même chose qu'avant sauf que c'est du web, c'est responsive, on affiche des petits pictos (c'est plus sympa d'avoir la tête des trains plutôt que juste leur nom), on affiche un peu plus de données puisqu'on va indiquer l'endroit où on dort (quand c'est lié comme ça, c'est qu'on va dormir à un autre endroit), on a les jours de repos et on va pouvoir se balader dedans et cliquer. Là c'est la grille théorique.

Je peux dérouler ma grille dans mon agenda, j'avais besoin de faire cette interface pour indiquer à l'ordinateur que je fais la E210 tel jour, automatiquement il sait où je suis, il sait que le roulement est valide de telle date à telle date, donc de telle date à telle date il va dérouler en suivant jour par jour, dans mon calendrier personnel.

Et j'ai voulu ouvrir ce calendrier personnel à mes autres collègues et créer du lien entre tout ça.

Si je fais le train 2400, je vais être relevé par le train 2401, avant je savais pas qui faisait le 2401, maintenant je sais que ça appartient à telle journée de service de telle grille et si le conducteur utilise mon système, on va le voir.

Je me suis dit "ça va marcher à peu près, c'est sympa". Je l'ai lancé dans mon d'établissement à Strasbourg.

En fin de journée il y avait cinquante inscrits, le lendemain, les Lorrains arrivaient et six mois plus tard on était 2000.

Aujourd'hui on est 18 000 sur 20000, parce que GRAOU ne fait pas juste le planning.

On va pouvoir contextualiser, organiser les données qui nous intéressent pour créer des intéractions, remettre des noms sur des numéros de train, répondre à plein de questions pour lesquelles on appelait avant les services de commandes, etc.

On va pouvoir faire ça de manière un peu plus sexy, rajouter des choses comme la synchronisation avec Calendar...

Si on revient sur la journée de service, de la même manière, c'est du CSS, du vectoriel, c'est responsive...

on rajoute la météo, pas parce que c'est rigolo mais parce que c'est super utile.

Là, j'ai un train de Strasbourg à Metz, j'ai une coupure de 14h à 16h : je pourrais me faire un ciné, manger quelque part...

sauf que s'il pleut, je vais prévoir un parapluie. Ça semble anodin mais pour un conducteur qui se balade tout le temps, qui passe son temps à changer d'endroit, c'est super important de savoir comment s'organiser.

Sur les 16 jours à venir il a une prévision météo sur toutes ses journées pour le lieu concerné (Strasbourg, Metz, etc.) Si on clique sur un numéro de train, on va voir des informations contextuelles.

Sachant que tous ces numéros de train sont stockés dans toutes les données dans l'entreprise, on va savoir quels sont les services, qui y travaille (on a les noms, les numéros de téléphone, les adresses mail), et leur statut (conducteur, contrôleur, etc.) : si on a un problème, on va pouvoir contacter ces personnes.

On a la liste des arrêts, les points kilométriques, le retard (s'il y en a), le type de matériel, etc.

On peut faire des recherches, par numéro de train ou sur des parcours particuliers (par exemple les trains Paris Est Meaux, les MICI pour ceux qui font du RER en région parisienne).

On a la liste de tous les trains, les statistiques de régularité (je stocke le temps réel... on y reviendra !), le type de ligne, les horaires, le nom des conducteurs, les contrôleurs s'ils sont renseignés, le type de modèle, etc.

En fin de journée, on se retrouve souvent dans d'autres endroits et ce qui était compliqué à organiser, (et c'est peut-être un des points fondamentaux du système), c'est avec qui on va manger le soir, qui dort dans le même hôtel, etc.

En général on se connaît, mais on ne connaît pas tout le monde, on connaît pas les noms, les prénoms.

Donc on appelait le service de commande des agents pour savoir, mais vous comprenez que côté RGPD, c'est compliqué ! Dans GRAOU on a du opt-in d'emblée (je voulais pas que mes données soient utilisées différemment donc j'ai fait pareil pour mes collègues), donc chaque agent a autorisé le partage de ces données et on a une table qui dit qui dort à tel endroit tel jour.

Voici l'heure d'arrivée de tous ses agents, avec des pictogrammes : ceux-là ils mangent pas avec, celui-là fait à manger, celui qui vient juste boire un coup, celui qui ramène sa gamelle, celui qui sort manger etc.

On a une messagerie, on a même les allergies (anonymisées pour le coup).

C'est assez révolutionnaire pour nous : on peut s'organiser et créer des choses nouvelles.

Par exemple des conducteurs de Montparnasse qui se retrouvaient à 10 ou 15, qui se connaissaient pas, on fait un repas à 19 ! Grâce au système (ils n'auraient jamais pu faire ça autrement), donc on a créé du lien grâce à l'outil numérique.

On a un système de wiki aussi partagés avec tout le monde, on peut partager les données, les bons plans, etc.

Pour aller encore plus loin, dans le système SNCF, il y a des couples d'agents, des groupes de musique, des clubs de foot, etc.

Imaginez avec le planning que je vous montrais, comment on fait pour trouver un moment en commun : on prend tous les plannings à plat sur une table et on cherche, ça prend deux heures ! Pour les coupes, pour garder les enfants, c'est super compliqué.

Donc pareil, chaque agent autorise un autre agent à voir son planning, ils créent des groupes, et le système trouve dans les journées de service, les moments où tout le monde est au même endroit au même moment.

On a une liste de ces périodes, on peut cliquer dessus pour envoyer des invitations Google agenda à tout le monde, on la liste des trains sur lequel on est ensemble, ça permet de se retrouver.

Et quelque chose qui prenait des heures avant se fait en quelques secondes, avec des alertes, etc.

C'est super utilisé, c'était quelque chose de très demandé et de très utile.

Et moi j'adore les statistiques (j'aime bien les camemberts c'est peut-être pour ça que je suis toujours pas totalement développeur !) : elles permettent d'avoir une information sur ce qu'on fait réellement : souvent le problème c'est que notre ressenti correspond pas à la réalité.

Et si on râle pour un ressenti faux, on a pas de justification. Là, si je dis à mon service de commande que je fais toujours la même ligne, le même engin, et qu'il faudrait que ça change, parce que c'est pas bon niveau sécurité, je peux lui prouver : je sais sur quoi j'ai roulé, quand, combien de fois, à quel endroit, le nombre de tâches, de kilomètres, d'arrêts...

(On peut aussi répondre au vieux tonton facho qui vous dit que les cheminots ils foutent rien, au repas de Noël !) J'ai aussi la liste des endroits où où j'ai dormi, les fréquences de travail, plein de choses.

Si vous regardez sur mon Twitter en fin d'année, vous verrez les gens qui postent le nombre de km qu'ils ont fait, vous avez un petit podium (le record c'est 160 000 km pour un conducteur de Strasbourg qui ne fait que du Strasbourg-Bordeaux et 12 000 arrêt par an pour un conducteur du RER C (ça fait 68 arrêts par jour donc c'est plutôt pénible) Ça vous connaissez, c'est les tableaux d'affichage qu'on a en gare, je me suis dit tant qu'à faire un peu d'UI, autant qu'elle ressemble un peu à ce dont on a l'habitude, et ce qui est très intéressant, c'est que les données viennent des roulements, où j'ai la liste de tous les trains qui partent d'une gare, j'ai l'open data donc tous les trains théoriques, je récupère le temps réel pour le resservir immédiatement (pas de problème d'API par rapport aux quotas).

Donc j'ai la liste de tous les trains (voyageurs, fret, les trains vides ou machines seules) : quand un conducteur ou un contrôleur veut s'acheminer à un autre endroit, au lieu de prendre un taxi, il sait qu'il va pouvoir prendre un train, il sait qui fait quoi, et il a le temps réel avec les retards, les suppressions, etc.

Mais ça suffit pas : on a des numéros mais moi j'aime les noms. On peut rajouter le nom des agents, donc je sais que le train qui part à 11h44, c'est Alexandre Machin qui le fait, je peux cliquer pour voir sa journée, qui est son contrôleur, son type de train, etc.

Donc dans une gare, pour tous ces trains que je vois, je sais qui est à bord, qui sont mes copains (si jamais j'ai le choix entre deux trains).

On va pouvoir créer plein de choses comme ça et comme je dis, on "humanise le système".

Ça j'aime beaucoup, je vais expliquer rapidement : on a des horaires. Un horaire c'est des arrêts avec des heures donc des gares (lieu géographique) et un horaire.

On met l'horaire en abscisse on met les gares en ordonnée en séparant proportionnellement par rapport à la distance, on trace un point chaque fois qu'il ya un arrêt et on trace une ligne qui représente tout le trajet.

Ça donne l'endroit et l'heure où deux trains se croisent (au croisement des différentes lignes de trajet).

A quoi ça sert ? Si le mec a laissé ses pleins phares, on peut l'engueuler parce qu'on sait qui c'est, mais ça permet surtout de se croiser : parfois on a besoin de se passer des informations, ou les courses pour le découché du soir (celui qui va arriver pour faire à manger n'est pas forcément celui qui avait le temps de faire les courses).

Donc ce système nous permet de qui on va croiser, quand et où. On recrée de la donnée à partir d'une donnée qui existe déjà.

On appelle ça un graph de circulation, c'est ce qu'utilisent les régulateurs pour réguler les trains sur des grandes lignes, ça gère les retards, ça suit les trains qui se suivent, qui se dépassent (plus la courbe est pentue, plus le train va vite).

Voilà, j'aime beaucoup cette idée et il y a plein d'autres choses dans le système : la création de grille, de roulement, on peut s'en servir pour gérer une entreprise ferroviaire complète, on peut suivre son métier savoir comment on va travailler (en lien avec les statistiques), faire des recherches dans ses propres données (la dernière fois où j'ai roulé sur telle ligne, les dernières tâches), les vacances scolaires le suivi des demandes de congés, la liste des collègues qui travaillent le même jour que moi, etc.

Y'a pas mal de demandes de besoin de covoiturage, quand on travaille très tôt, qu'on peut pas forcément prendre le train à l'aller, mais qu'on peut le prendre au retour par exemple, autant prendre une voiture à 4 et chacun rentre de son côté.

On peut ouvrir aux sédentaires (les aiguilleurs, etc.) : quand l'aiguilleur est tout seul pendant la soirée, avec 14 conducteurs qui mangent à côté, il aimerait peut être en faire partie. Donc ça c'est une demande aussi qui arrive.

La synchronisation des outils de production parce qu'on a un système collaboratif : les données sont rentrées par les agents, on est 18 000 sur 20000 à l'utiliser mais les 2 000 qui manquent c'est parce que ça les soûle de rentrer les données à la main.

Une fois que ce sera synchronisé il y aura plus de soucis puisque les données seront réelles.

Fiabiliser et faciliter les échanges de congés, les permutations : le conducteur qui veut aller à Marseille, l'autre à Paris, celui de Strasbourg qui veut aller à Rennes, ils peuvent faire des triangulaires et des des quadrangulaires parce qu'on les met en relation.

Aujourd'hui c'est pas possible mais demain avec ce système ce sera facile, on présente au RH une solution toute faite et tout le monde est content.

Comment et sur quoi ça tourne ? La partie un peu technique, mais rien de très sorcier.

Il y 18 000 utilisateurs, à peu près 800 000 vues par jour (j'ai constaté des pointes à 250 requêtes secondes), 15 Giga de données (mais avec des Gigas d'index donc pas non plus énorme), beaucoup d'open data SNCF, les données internes (les roulements de service) et d'autres données externes comme la météo.

Tout ça tourne sur un petit serveur sympa de 32 Giga, ça tourne assez bien, il y a une passerelle interne dont je me sers pour les échanges en interne, et puis un serveur mail dédié, c'est important. Mon frère me dirait "Prends MailChimp c'est vachement plus simple", oui mais MailChimp, ça coûte des sous, et on y viendra près mais tout ça c'est dans mes frais.

J'ai appris à me servir d'un serveur mail, à gérer sa réputation (coucou Hotmail !) et si vous avez besoin d'un expert DKIM/SPF on peut en reparler après.

Tout ça sur des techno que je connais, qu'on m'a recommandées, du docker pour séparer, du PHP, du MariaDB.

Un peu de NodeJS parce que j'avais pas le choix ! Le front c'est du JS, il n'y a pas de framework, à part bootstrap pour mon CSS et encore j'en suis très éloigné maintenant.

Je vais venir un jour mais pour l'instant c'est ce que je connaissais, ça marche plutôt bien.

L'avantage du procédural c'est que c'est assez optimisé et j'ai à peu près 10% des capacités serveur utilisés avec des requêtes en continu.

On en vient au cœur du sujet : ce n'est pas hébergé en interne SNCF. On m'a l'a proposé mais je n'avais pas confiance, non pas dans la technique mais parce que je suis tout seul, je ne suis pas une DSI ni une équipe projet, je suis un conducteur, et le statut dont on parle tellement, il a un côté négatif : c'est que quand on a un statut de conducteur, on est un conducteur.

Et quand on veut être corporate - c'est mon cas j'adore mon entreprise, mes collègues et j'aime bien le service qu'on rend, je veux le faire bien - si on est un hacker, on n'est pas corporate, en tout cas dans l'esprit des gens qui sont pas dans le milieu du digital.

Ça a été très compliqué notamment dans ma direction dans tout ce qui est conducteurs et contrôleurs, de faire accepter cette idée qu'on allait ouvrir les données, les utiliser... parce qu'il faut d'abord mettre les données.

En disponibilité et fiabilité aussi j'étais pas sûr, parce que quand on facture 3 € le gigaoctet d'espace disque sur un serveur, si je demande du H24, en termes de support, ça va être compliqué à faire accepter pour ma direction qui sera facturée...

Donc en interne, c'est plus simple, mon serveur me coûte 30 € par mois, mais ça tourne bien et je fais un peu ce que je veux.

En termes de sécurité, j'ai fait ce que j'ai pu, je reste clairement un amateur. J'ai eu des audits plutôt bon, j'essaie de faire beaucoup de veille, de pas me reposer sur mes lauriers quand j'apprends un truc, si je peux faire mieux, je fais mieux.

Autant pour le code, il y a une limite à la refactorisation, autant pour la sécurité, il faut y aller.

Mais c'est assez passionnant parce que j'ai appris plein de choses sans trop casser des trucs donc c'était plutôt sympa.

Dans l'histoire de ce process - et c'est toute la complexité du truc - c'est que je me suis retrouvé tout sourire, arrivant à la direction métier (donc très conducteur) pour leur présenter mon outil.

J'avais été repéré par des directeurs de cette direction, qui étaient prêts à soutenir mon projet., et le middle management est arrivé j'en suis pris plein la figure ! Ils disaient qu'on ne devrait pas ouvrir les données, que les agents qui conçoivent les roulements de Narbonne ne veulent pas que ceux de Montpellier voient comment ils travaillent...

Donc tout est très siloté on à peur de casser les silos. C'est une culture qui heureusement est en train de changer, en positif, côté SNCF notamment côté direction digitale, mais on est une entreprise répartie dans toute la France, qui n'est pas centralisée : on est 140 000 sur tout le pays et chacun bosse un peu comme il veut.

Je vous raconte pas la qualité des données que je reçois des fois (on en reparlera après) ! Bref tout ce process a été très long, une DSSI m'a bien aidé en taclant un peu les projets métier, en disant : "Lui a fait des audits sécurité et vous, les vôtres, c'était quand ?" La direction de digital m'a ouvert ses bras, m'a dit : "on te prend avec nous, on va te soutenir, t'aider, parce que ça nous plaît, ça fait de l'humain, ça crée du lien et c'est tout ce qui compte." Mais le process a été très long - surtout les process internes SNCF - et j'ai mis autant de temps à développer GRAOU qu'à obtenir une passerelle interne (et elle avait pas internet !).

Et "nettoyer, balayer, astiquer : la donnée est toujours pimpante" (de rien pour avoir la chanson en tête) : je passe un temps fou avec les tables de traduction des données que je reçois, parce que chacun fait un peu à sa sauce.

Démonstration : prenons un engin standard, un AGC 4 caisses (Autorail Grande Capacité de Bombardier), ça c'est un modèle particulier, le BGC (hybride, bimode diesel et électrique), son vrai nom c'est BGC 4C.

A Rennes, ils l'appellent B 81 500, à Nantes C 81 500, à Paris encore autre chose, etc.

Et ça c'est juste le BGC 4C, on a plusieurs centaines de séries d'engins, je vous laisse imaginer la taille de mes tables de traduction, qui sont rentrées à la main.

Je reçois des notifs à chaque modification de roulement pour dire voilà il a telle est l indice qui n'existe pas il va falloir les ajouter dans le dans le système donc c'est pas travail ultra passionnant pour le coup mais le fait d'avoir un typique tôt après ça voilà ça compense On trouve un peu les moyens qu'on veut voir dans l'est un peu dans les histoires aussi qu'ils ont qui ont pu se passer dans les temps de ce rôle un peu d'amateur par rapport à tout ce système j'ai quelques frayeurs ça c'était il ya quelques mois c'était en décembre donc là on vous avez le graphe d'apache du reverse proxy avec le nombre de requêtes par pas de cinq minutes, donc 2000 requêtes par pas de cinq minutes. Et là vous allez en dessous le nombre de marqueurs php fpm temps et pour le coup je voyais mon site qui répondait plus à partir de 14h30 je commençais à paniquer puis je trouvais pas d'où ça venait j'ai passé un temps fou là tout mon après midi j'ai passé mon temps à optimiser à redémarrer mon serveur sql à optimiser la mémoire au taquet, a provisionner d'emblée tous mes workers. J'ai ma ligne rouge la 450, c'est ce que me permets ma mémoire dans mon idée je me disais quand même 18 mille personnes c'est beaucoup ville parmi ne passera pas par cinq minutes ça fait quand même beaucoup de 150 secondes j'ai pas de notion c'est la première fois que j'ai des trucs comme ça et je me disais bon peut-être c'est normal que ça augmente trop mais il fallait que je prenne un deuxième serveur ou etc jusqu'à ce que je me rende compte là ici à 23h30 que en fait sur une page où j'avais une dizaine de roquettes ajax y avait un timeout à 60 secondes vers un site qui marchait plus donc forcément en 1450 worker avec 60 secondes de timeout, bah ça allait exploser il est passé à 4 et puis j'ai plus de problèmes depuis Ce genre de choses alors ça m'est arrivé plusieurs fois je me suis rendu compte qu'en fait triturer dans du code quand on a 20 utilisateurs c'est pas grave on peut faire des MEP dans le train avec une connexion SSH un peu oscillante, il y a pas de soucis, mais là on peut pas.

un autre exemple j'ai fait une mise en prod un dimanche matin à 4 heures voilà pour être sûr que personne m'embête, j'avais prévenu, j'ai mis un beau bordeaux et à partir du moment où j'ai voulu mettre en porte ça marchait pas et j'ai un peu eut des froides à 4h du mat donc j'ai dépanné j'ai rajouté une heure de plus à ma mise en prod avant de remettre le site en ligne j'avais dix mail parce que oui les conducteurs des contrôleurs bossent la nuit aussi, "c'est grave GRAOU marche plus : qu'est ce qui se passe ? tu as un problème ?" etc Jamais fait ça un lundi à 17 heures c'était la panique, bref et ça met une certaine pression alors c'est chouette, il y a côté un peu grisant, mais des fois j'aimerais bien prendre des vacances Bref ça donne pas un avantage d'être tout seul quand même parce qu'effectivement, je suis autonome, j'ai choisi mes techno je choisis comment je vais travailler avec qui aussi puis ça commence à se monter il ya quand même plein de gens intelligents chez sncf et heureusement c'est ce qui fait que la boîte avance on est quand même une boîte qui est pas mal leader dans plein de choses et techno on est leader dans les drones sais pas si vous le saviez mais en tout cas en europe mais c'est super important ça évite de faire passer des trains pour surveiller la voix ont fait passer des drones ça coûte moins cher c'est plus écologique on a eu dix fois plus de données donc voilà plein de choses comme ça qui sont qui se font chez nous il y en a des exosquelettes on beaucoup de big data beaucoup d'IOT.

bref et je peux choisir un peu pioché là dedans ça permet de répondre très vite j'adore quand sur twitter on me demande une fonctionnalité, "ça serait super si tu pouvais faire ça", et quand 20 minutes après ouais je l'ai ajoutée.

Certes j'ai pas fais tous mes tests unitaires d'accord mais on s'en fiche parce que GRAOU si sa tombe c'est pas grave hein personne ne paye pour ça, il y a que moi de 2 les trains continueront de rouler juste les gens seront un peu plus triste bref le suivi des bugs fonctionnalités, j'essaie de m'organiser pour faciliter la vie au maximum encore une fois si j'étais si je n'étais pas tout seul ça aurait été plus simple. Et là pour le coup j'ai découvert discourse c'est absolument génial avec son système d'auto modération. J'ai un Gitlab, bien utilisé avec le kanban, etc pour gérer les fonctionnalités, les bugs ou autre et ça ça se remplit plus ou moins automatiquement ce qui permet vraiment de gérer les besoins les demandes de trier de pas toujours répondre ce que moi j'ai envie de faire d'abord ce que mes utilisateurs ont envie d'avoir et comme je le disais avant effectivement l'entreprise de soutien quand même beaucoup et je suis très content de ça y'a pas que la majorité de quand même des aspects très très positif bref tout ça pour dire que tout ce qui compte dans cette histoire pour moi et j'y tiens beaucoup ça fait un peu bisounours, c'est l'humain. Parce que j'ai créé un outil est un peu comme tout outil numérique le but c'est quand même nous faciliter la vie faire gagner du temps à gagner de l'argent dans certains cas Mais de créer du lien parce que si on se lève le lundi matin pour aller bosser et finalement pour avoir envie de s'intéresser à ses collègues pour repartir moi je fais partie de ces personnes qui arrivent pas je vais m'intéresser à l'autre ce qu'est ce qui fait dans sa vie qui est comme une vie ça est-ce qu'il est bien évidemment bref et tout ça, GRAOU, c'est en fait la brique manquantes entre les outils de gestion personnelle et les outils de gestion de production, Et d’ailier un petit peu les deux pour que les contraintes dans l'un et de l'autre n'aient plus trop de problème sur l'un ou l'autre.

L'exemple majeur que je pourrais vous citer à ce moment là, c'est ce mail d'une contrôleuse qui me disais : "voilà je suis jeune maman, divorcée récemment malheureusement c'était super compliqué d'organiser avec mon ex mari qui n'est pas du tout du métier c'était par rapport à mon planning, là aujourd'hui il a mon planning dans sa poche moi je vais au boulot je suis sereine je suis hyper contente, merci.

des trucs comme ça j'en ai plein toutes les semaines je remplis une boîte mail que ces trucs là, et ça fait plaisir bien sûr, mais surtout on sent qu'on répond à un besoin. C'est ce qu'on appelle la QVT (Qualité de Vie au Travail) : c'est pas juste un baby foot ou une machine à café qu'on met dans un coin, c'est comment faire en sorte qu'on soit suffisamment bien dans son travail pour bien bosser.

Parce qu'un salarié heureux c'est un salarié en général productif.

Et qu'on soit content de rentrer chez soi parce qu'on a bien bossé, mais surtout parce qu'on peut oublier son boulot.

Quand on peut le faire et qu'on a les outils pour le faire c'est super. Donc ça créé du bonheur ! "Le bonheur n'a de sens que s'il est partagé" (Sean Penn - Into the wild).

Donc on en revient au même système : on donne des informations sur le métier, on les humanise, on met le nom dessus en respectant la vie privée et on permet de partager ces infos là entre nous.

On peut le faire seulement avec la donnée (datafirst) et ensuite on voit ce qu'on fait en termes d'innovation.

On parle beaucoup d'innovation de machin de trucs, mais donnez-nous d'abord les données, ensuite on fera de l'IA, du deep learning, des outils... mais d'abord il faut voir les données.

C'est comme une boîte de Lego : d'abord on les étale devant nous et après on construit des trucs avec.

Et l'XML, je rigole parce que j'ai commencé à parser du XML, à transformer ça dans un tableau, faire des trucs sympas, pour faire plaisir à ma femme et finalement pour rendre service à mes collègues. Donc en me faisant plaisir à monter des trucs avec des bases de données, sans trop le vouloir d'emblée ça a rendu service à la plupart de mes collègues, et ça, c'est super en termes d' approche pour nos projets perso, d'avoir cette vision de l'utilisateur final, de ce qu'on va faire, du partage - même si c'est pour deux personnes, tant qu'on s'amuse et que ça fait plaisir à l'autre c'est tout ce qui compte. Merci Merci beaucoup. J'ai une première question (je triche un peu, je fais partie du staff c'est moi qui ai le micro).

J'ai deux questions même : est-ce que la SNCF plutôt que de te proposer de mettre le projet en interne, t'a proposé de le financer ? Non jamais... parce que l'argent ça coûte cher ! Non, parce que j'ai un statut pourri, je suis au milieu : je suis un conducteur, pas un développeur...

Je suis un développeur mais je suis plus conducteur.

L'application tourne, je leur ai jamais rien demandé donc si maintenant j'allais demander 5 euros par utilisateur, par mois, à la fin du mois, je roule en Tesla ! Par contre on a réfléchi, j'ai reçu de l'aide aide de pas mal de personnes notamment de collègues de mon frère, notamment Xavier avec qui on a pas mal discuté, et qui me disaient : "faire une entreprise, monter ça comme ça tout seul dans mon coin, ce serait se tirer une balle dans le pied.

J'aime mon entreprise, j'ai envie de la faire vivre". Et je le rejoins assez sur cet avis : j'ai une entreprise qui est ce qu'elle est, que j'aime bien, j'ai envie de faire avancer, et pourquoi pas devenir éditeur d'une solution à laquelle je participerai, ce qui serait beaucoup plus logique. On est en train d'y réfléchir avec une filiale technologique de la SNCF, pour distribuer mon outil pour SNCF, donc me payer l'acquis, payer le service, et ensuite l'exporter.

Parce que vous imaginez bien que sur Twitter, la SNCB, la RENFE - pas les entreprises mais les agents, j'aime bien faire ça : proposer d'abord l'outil aux agents, les fédérer et ensuite dire aux entreprises que leurs agents en ont besoin, que ça leur plaît...

et essayer de trouver un arrangement sachant que c'est du service, c'est pas compliqué.

Je m'oriente un petit peu vers ça pour essayer d'arrêter faire ça bénévolement, pour embaucher du monde.

J'ai mes limites de développeur, j'ai deux enfants et une femme, j'aimerais passer du temps avec eux, et si je voulais apprendre Symfony from scratch, me mettre à des technos que j'apprécie, il me faudrait beaucoup plus de temps.

Je préfère laisser ça à d'autres qui savent bien le faire, guider ça en maîtrisant une partie des choses et m'attacher un peu plus à l'UX.

Une autre question ? Bonjour. Total respect... juste pour être sûr d'avoir compris : tu étais roulant, tu es devenu développeur, administrateur de bases de données, hébergeur, admin sys... tu t'arrêtes où ? Et en trois mois si j'ai bien compris en plus ? Non en fait, très rapidement, à la base je suis musicien et ingénieur du son...

c'est ça qui me plaisait, j'ai toujours eu l'informatique à côté parce que c'était rigolo, j'ai commencé sur Atari et j'avais développé à l'époque (j'avais 12-13 ans), je faisais du V-jaying avec du MIDI.

J'ai toujours une très grande proportion de programmation. J'ai arrêté pendant des années pour me consacrer à autre chose, Niveau scolaire, je n'aime pas trop ça donc je préfère être derrière mon PC à coder des trucs qui me plaisent, que des trucs qu'on m'a demandé.

Idem pour la musique, donc en vivre c'était pas possible. J'ai choisi de conduire des trains parce que c'était une opportunité chouette, c'est très concret.

Puis vous savez quand vous avez fait 300 lignes de code qui vous plaisent pas, que vous êtes obligés de partir conduire des trains, vous êtes pendant huit heures à regarder la voie défiler, au bout de huit heures vous avez plus que dix lignes de code, donc il y a un très bon côté à avoir un métier très concret - qui me manque un petit peu aujourd'hui.

Entre temps j'ai toujours continué à faire de l'admin sys et du développement, donc y'a pas de surprise, je me suis pas mis à faire ça en trois mois, mais j'essaie d'apprendre toujours au maximum en continue, de me remettre en question si j'y arrive.

D'autres questions ? Pas de question sur les grèves par contre s'il vous plait ! Je sais pas si votre train roule ce soir, il faut regarder les applications...

Bonjour et félicitations ! Si j'ai bien compris : pour éviter d'avoir à remplir les informations personnelles, qui prenaient quelques heures en trois mois vous avez fait une appli pour que 18 000 personnes rentrent leurs données personnelles...

Parce qu'aujourd'hui toutes les données viennent des agents qui les remplissent eux-même ? Tout à fait.

Non, c'est tout.

En fait l'idée est de créer une vraie plus-value : s'ils autorisent le partage de données, ils vont forcément voir les données des autres.

Donc c'est toujours donnant-donnant : je verrai pas ce qu'ils ont partagé et je ne verrais personne si je ne partage pas moi même.

Y'a des petits malins qui ont essayé mais comme au bout de cinq allers-retours du bouton ça bloque, ils ont arrêté.

Et puis j'ai des gros bandeaux qui expliquent que si vous voulez voir un peu plus d'infos, faut partager vos données, cliquez là pour partager : j'encourage énormément à partager les données mais on peut très bien l'utiliser en étant complètement anonyme et sans que personne ne nous voie.

Une autre question ? Tu parlais de temps réel : est-ce que les agents ont accès à ces données quand ils sont dans les trains ? Un conducteur n'a pas le droit d'utiliser son téléphone portable en roulant, un contrôleur peut l'utiliser s'il a plus personne.

Ils ont accès au temps réel, mais pour moi, le temps réel c'est juste la liste des retards, des suppressions des trains et le minutage qui correspond au différentiel du train. C'est la seule information en temps réel que j'ai.

Toutes ces données, c'est de l'open data, tout ce que vous avez vu à 80% c'est de l'open data, pour le reste, j'ai pas de données de prod temps réel internes, et c'est pas plus mal, c'est une chose compliquée en moins à gérer, demander des accès ou autre, on arrive quand-même à faire pas mal de choses en ayant que de l'open data.

Et les agents peuvent pas mettre à jour ces données en temps réel ? Les données temps réel, non, ils ne peuvent pas y toucher. Je me base sur les flux officiels pour avoir quelque chose assez exhaustif, même si je pourrais peut-être avoir plus de précisions avec un outils collaboratif à la Waze, mais c'est super compliqué à gérer.

Ça m'intéresse beaucoup moins parce que ce qui m'intéresse c'est de fournir un outil pour les agents qui font le temps réel, plutôt que de faire remplir les données temps réel par les agents.

On a fini de l'autre côté niveau questions donc si vous avez encore des choses à demander à Nicolas, n'hésitez pas je pense qu'il y a pas mal de choses encore à explorer et merci.

Merci à vous