Recul sur mes missions Flashcards

1
Q

FDJ : Contexte de la mission

A

Le contexte est le jeu de loterie : l’application se trouve sur les terminaux que l’on retrouve chez les buralistes. J’ai travaillé sur le projet DPP (Digital PoS Platform).

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

FDJ : Résultats apportés

A

Mon apport : Permettre à la FDJ de vendre sa solution à de nouveaux clients que sont les loteries étrangères

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

FDJ : Equipe Agile sans Tech Lead

A

J’ai travaillé dans une équipe Agile Scrum. Il n’y avait pas vraiment de Tech Lead, il y avait un tech lead sur le papier mais qui n’avait pas vraiment ce role, la FDJ voulait un TL en interne, mais tous les devs étaient sur le même pied d’égalité, on faisait tous plus ou moins les tâches du TL, on était plutôt Lead sur des sujets qu’on prenait en main de A à Z, on était référent.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

FDJ : Refonte de l’application technicien

A

On a travaillé sur la refonte d’une application technicien pour la remettre au gout du jour, avec des technos plus récentes et un design plus moderne pour inciter les clients à vouloir utiliser la solution.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

FDJ : Architecture en microservices

A

Architecture en microservices avec des microservices packagés et versionnés de façon indépendante. Publication sur un registre npm privé. Release de l’application principale tous le 3 mois contenant les packages des microservices.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

FDJ : DevOps

A

On utilisait la suite Atlassian pour gérer le projet : Jirz Confluence pour le ticketing et la doc mais aussi bitbucket pour les repositories et Bamboo pour la ci cd. On avait un devops dédiés aux tâches devops mais on pouvait aussi être amenés en fonction de nos besoins à adapter le fonctionnnement : on avait des scripts qui permettent de derouler le fonctionnement des jobs de ci : build, test, release, artifiacts, déploiement

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

FDJ : TSW

A

DPP est une partie du TSW. Le TSW c’est toutes les briques de l’application qui sont installées dans le terminal : DIP, DLA, DLS, DPP, Front … Ce sont des briques optionnelles, chaque client choisit ce qu’il veut payer comme brique. S’il ne choisit pas une brique, cela veut dire que le client (une loterie étrangère) devra s’occuper de l’implémentation de cette partie lui-même.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

FDJ : C’est quoi DPP

A

C’est une API Node.js qui permet aux clients de simplifier l’accès aux fonctionnalités matérielles du terminal comme l’imprimante, le scanner, l’audio … Et également aux fonctionnalités software comme l’authentification, la configuration système …

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

FDJ : SSE

A

On utilise les Server Sent Events pour envoyer des notifications aux clients. Les SSE sont un moyens d’envoyer des messages de façon unidirectionnelle. Les clients s’abonnent aux évènements voulus de leur côté. On les utilisaient pur notifier les clients des évènements matériels. Ensuite les équipes front avec lesquelles on travaillait ont rencontré des problèmes elles devaient ouvrir des canaux pour chaque route et ils étaient limités par la limite de 6canaux ouverts dans le navigateur, on est donc passé aux websockets pour les nouveaux devs.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

FDJ : Plugins d’authentification

A

Certaines fonctionnalités nécessitaient une authentificaiton en amont, et comme nous avions des différents venant de différents pays, chaque client avait un fournisseur d’authentification différent. On a donc mis en place un système spécifique de plugins où de notre côté on a implémenté des fonctions génériques d’authentification comme la création de session, l’execution de fonction en mode connecté, le refresh de token … Le client devait remplir un les paramètres de son serveur d’authentification dans son fichier de configuration et devait développer le plugin qui implémentait l’interface qu’on leur a fourni. Ce qui que nous n’avions pas besoin de stocker le code sensible du client chez nous. Le plugin client était ajouté au build time dans le projet DPP était importé dans le code grâce aux dynamic imports de Javascript.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

FDJ : Backend-lib

A

En plus du backend dpp, toujours dans le but d’être un accélérateur de dev, on a développé un outil qu’on a appelé la backend-lib qui est une librairie front qui permet de faire les appel api au backend sans avoir à faire les requêtes, les paramètres des requêtes sont encapsulées dans notre librairie, le client n’avait plus qu’à appeler les fonctions fournies par la backend-lib pour accéder aux fonctionnalités du terminal. Pour faire ça on a utiliser les typescripts décoratiors.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

FDJ : OS du terminal

A

Avant DPP il n’y avait pas d’API accessible par le client. Le terminal était fourni avec un os linux custom, qui contenait un middleware développé en c++ qui permettait d’interagir avec le matériel. Les clients devaient eux mêmes coder l’utilisation des middlewares dans leur application de loteries pour interagir avec le materiel.

DPP implémente un fork maintenu en interne de la librairie fastcall permettant d’utiliser des librairies c++ dans un serveur node.js. Et une API est fournie pour toutes les interactions nécessaires pour le matériel.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

FDJ : Livraisons, releases

A

On travaillait en Agile Scrum, mais en réalité la vraie chronologie projet était basée sur notre rythme de releases qui était tous les 3 mois pour les versions majeures en plus d’une ou deux versions mineures. Chaque client décide ou non d’intégrer nos releases ou de rester sur une version plus ancienne en fonction de ses besoins en fonctionnalités

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

RATP - HORUS : Contexte

A

J’ai travaillé au sein de l’Usine Digitale de la RATP, une factory au sein de laquelle plusieurs projet innovant de la RATP sont développés. Ce sont généralement des projets développés dans un but de livraison de version rapide, en 6 à 12 mois maximum. Et si besoin, lancer le développment d’une V2, d’une V3 etc …

Au sein de l’Usine Digitale, il y a une core team RATP chargée de chapeauter les différents projets, de fournir un cadre commun avec l’architecture devops, un boilerplate d’application commun, qui est amélioré au fur et à mesure des préconisation des persones présente ddans l’Usine Digitale.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

RATP - HORUS : C’est quoi Horus ?

A

Horus est une application de suivi des précurseurs d’incidents. Un précurseur d’incident est tout événement qui peut provoquer un accident grave sur le reseau Ratp. Par exemple une porte mal fermée, des personnes sur les voies, …

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

RATP - HORUS : Objectif

A

Je suis arrivé sur le projet en tant que Tech Lead pour travailler sur la refonte de cette application. Mon travail sur ce projet s’est déroulé en 2 étapes.

17
Q

RATP - HORUS : Cadrage Métier

A

Une première partie de cadrage sur 6 semaines qui avait pour objectif d’obtenir un MVP à développer.

  • Métier : conception, interview

Pour cela, avec le PO et l’UX designer, nous avons beaucoup discuté avec le métier pour comprendre le besoin, pour identifier les point critiques de l’application existante. On a fait des interview utilisateur pour recueillir le ressenti des utilisateurs sur le terrain.

18
Q

RATP - HORUS - Cadrage - Chiffrage

A

Ensuite j’ai dû réaliser le chiffrage des fonctionnalités à développer en concertation avec la Core Team RATP. Finalement il s’est avéré que le budget nécessaire était bien plus élevé que le budget alloué pour le projet. Nous avons dû retravailler avec le métier pour trouver des solutions en identifiant les fonctionnalités non vitales pour l’application, trouver des concessions pour simplifier des fonctionnalités et arriver un accord.

19
Q

RATP - HORUS : Equipe Dév Agile

A

Ensuite la deuxième partie était bien sûr le développement de l’application. Pour cela j’ai pu récruter une équipe de 3 développeurs, 2 développeurs assez confirmés qui connaissaient déjà le contexte RATP et une développeuse plus junior.

On travaillait sur des sprints de 2 semaines. Ma fonction de Tech Lead impliquait plusieurs taches.

20
Q

RATP - HORUS : Lead Dev

A

L’accompagnement de es développeurs avec le Pair Programming, les Code Review, répondre à leurs questions techniques et fonctionnelles

21
Q

RATP - HORUS : POC

A

J’ai également travaillé sur la réalisation de POCs pour valider le choix de librairies et l’implémentation de fonctionnalités, en collaboration avec le responsable cyber qui était très regardant. Il testait la sécurité de nos implémentations et de nos librairies, validait les licences des librairies et le score de sécurité sur socket.dev …

22
Q

RATP - HORUS : Algo 6 mois

A

Un algorithme de génération de recommandations sur les occurrences des 6 derniers mois pour compléter celui existant qui prend les occurrences des 5 dernières années

23
Q

RATP - Horus : Inducteurs

A

L’ajout d’inducteurs : un coefficient à appliquer sur le nombre d’occurrence, pour tempérer le nombre d’occurrence en fonction de facteurs extérieurs comme les grèves …

24
Q

RATP - HORUS : Texte enrichi

A

L’implémentation d’un éditeur de texte enrichi permettant de aux opérateurs de remplir leurs rapports mensuels qui étaient auparavant rédigés sur Powerpoint et surtout étaient volatiles, il n’y avait pas un endroit commun pour les collecter

25
RATP - HORUS : CI CD
Je m’occupais des déploiements sur les environnements de dev, staging et productions, on avait un environement de CI/CD mis en place par la core team qui comprenait jobs de build de test, de déploiement, d’analyse de qualité qui nous permettait de mettre en production de façon confiante
26
RATP - HORUS : Résultat
L’application a été livrée au client, elle est plus rapide, contient des fonctionnalités supplémentaires, le client est satisfait, elle permet de suivre plus efficacement les évènements sur les réseau, de prendre des actions plus rapides et mieux ciblées et donc d’améliorer la sécurité du réseau RATP.
27
MCM : Contexte
Moncomptemobilité est une plateforme regroupant les offres d’aide à la mobilité douce. Les mobilités douces sont les vélos, les trottinettes, les transports en commun, le covoiturage …Les aides peuvent venir de différentes sources : l’état, les régions, les collectivités, les entreprises… et il était difficile d’avoir accès à toutes ces offres, d’avoir la connaissance qu’il y a des aides disponibles. Ce projet est financé par les amendes infligés par l’état dans le cadre des crédit carbone. J’ai travaillé sur ce projet dans le cadre d’une expérimentation avec quelques entreprises et collectivités partenaires.
28
MCM : Organisation Equipes
Il y avait 2 équipes Scrum, 1 en France 1 au maroc. Avec un architecte projet. Il y a plus ou moins 5 développeurs ar équipe et un Tech Lead. Je suis arrivé sur le projet en tant que developpeur fullstack Node React.
29
MCM : C'est quoi MOB
MOB est composé de deux parties. La plateforme web qui permet aux citoyens d’avoir accès à la liste des aides, d’accèder à leur compte et de souscrire à ces aides. Et une API indépendante, qui est utilisé par la plateforme mais également fournie aux partenaires qui leur permet d’intégrer leurs aides et gérer la souscription à ces aides
30
MCM : Complexité être générique
La complexité qu’on a rencontré était l’objectif de rester générique. Chaque partenaire souhaitait intégrer ses propres process et l’objectif de notre API était d’étre indépendante des partenaires. Il y avait donc un gros travail de conception à faire à chaque intégration d’une nouvelle règle pour la rendre générique et utilisable par tout le monde
31
MCM : Dév front et back
Sur ce projet j’avais bien sûr la charge de développer des fonctionnalités back en améliorant ou ajoutant de nouvelles routes API disponibles pour les utilisateurs. On travaillait avec Loopback côté back, qui intégrer nativement Swagger, et créer différentes pages côté Front dans le site web développé en React
32
MCM : Keycloak
Pour gérer les utilisateurs, on utilisait Keycloak qui intègre différentes formules d’authentification, permet de gérer des mails de gestion de compte, d’étre un identity provider. On a également réaliser l’intégration FranceConnect
33
MCM : CI CD
On avait une platforme de CI/CD avec gitlab CI. Tout le projet était géré sur Gitlab : les tickets, la doc du projet, la CI, les environnements de dev et test… Pour chaque branche un environnement distant était créé pour permettre au testeur de valider les devs sur un environnement propre. On a développé un script d’isertion de JDD de tests qui était lancé lors de la création de l’environnement. On avait des jobs pour cleaner les JDD, pour relancer les déploiements …
34
MCM : Vault
J’ai également travaillé en relation avec l’architecte projet sur la mise en place d’un key manager permettant aux partenaires de gérer les données privées des citoyens sans que notre plateforme ait accès à ces données. Ce Vault permettait de générer un couple de clé privée clé publique utilisé pour chiffrer et déchiffrer les justificatifs fournis par les citoyens lors de leurs demandes d’aides. La solution était Dockerisée et fournie au partenaire qui n’avait plus qu’à la lancer chez lui
35
MCM : Résultat
Expérimentation validée avec les entreprises et collectivités partenaires de l’experimentation, produit livré à la Fabrique des Mobilités. Plateforme d’aides à la mobilité accessible à tous les citoyens vivant en france.
36
Conclusion
Pour conclure De mon côté je réitère que je suis très intéressé par ce poste. Je suis quelqu’un de passionné, je travaille dur pour satisfaire le client, je sais remonter la alertes en temps et en heure pour ne pas mettre en péril les livraisons. J’aime ce que je fais, si je vois qu’il y a un sujet où j’ai besoin de monter en compétence par rapport au reste de l’équipe je n’ai pas de problème à investir de mon temps pour combler ce manque, j’ai toujours envie d’apprendre et de progresser. Et puis ce n’est pas très intéressant si je connais déjà tout.
37
Introduction
Je suis développeur avec 6 ans d’expérience dans le développement d’applications fullstack javascript complexes pour des clients grand compte comme la FDJ, la RATP, Bouygues ou EDF. J’ai travaillé principalement sur une stack Node React sur des projets en methodologie Agile. J’ai vu dans la description du poste que vous etiez en SAFe, j’ai déjà cette experience chez EDF où on etait sur un projet avec une 40aines d’equipe. On etait organisés en PI planning de 5 sprints où on se regroupait pendant 2 jours dans le technopole edf de Saclay pour préparer le prochain PI : Se repartir les fonctionnalités entre équipes, gerer les dependances, chiffrer dans le but d’avoir une nouvelle iteration du produit livrable à la fin du PI. Chez EDF je suis arrivé en premier pour mettre en place un socle de tests automatisé avec Selenium Cucumber et Gherkin avant de continuer dans la même equipe en tant que développeur. Chez Bouygues c’est la seule mission où je ne travaillais pas dans ine équipe agile. J’avais intégré l’equipe Hermès dans laquelle j’étais en charge de la mise en place des nouvelles communications mail et sms de bouygues. je travaillais en lien direct avec le métier avec qui je m’occupais de planifiais les livraisons, intégrer les maquettes proposées par l’equipe desing, je proposais des améliorations, je participais aux campagnes de test je faisais les mises en productions.