Description

Développeur Fullstack sur les stack Java et Python. Je monte très vite en compétence sur des sujets très complexes et peu connus, je suis travailleur, curieux et ambitieux. Très orienté PROBLEM SOLVING du fait que j'apporte dans le cadre de mon travail des solutions efficaces aux problèmes rencontrés.

Expérience pro 10+. Intéressé par des projets innovants et la TMA.

J'ai bossé dans les domaines suivants:

- Sport (FFF)

- Pneumatique (Michelin)

- Energie (le leader de l'énergie en IDF)

Langues

Français
Bilingue ou natif
Anglais
Capacité professionnelle complète

Préférences en matière de lieu de travail

Accepte de travailler sur site

Paris (jusqu’à 50 km)

FFF
Suivi Projet Club : outil de labélisation des clubs
SPORT
juillet 2020 - Aujourd'hui (5 ans et 11 mois)
Paris, France
Projet : SPC (Suivi Projet Club : outil de labélisation des clubs)
Technolgies : Front : framework7, Back : Python3, Data : Oracle, Postgres
Problème 1 : Edition de l’autodiagnostic au format PDF
Description : Les clubs de football de la Fédération Française de Football font des demandes de labélisation en
cours de saison. Pour cela ils renseignent un ensemble de critères et ces demandes sont vérifiées par des
évaluateurs ou accompagnateurs qui vont noter (notion de points et niveaux) le club demandeur. A un moment
donné de la saison les utilisateurs ont besoin d’imprimer cette au format PDF très utiles pour es séances de
travail au sein de la fédération.
Problématiques :
1. L’édition du PDF doit être assez proche de l’IHM de l’outil de labélisation.
2. La profondeur de navigation vers les pages à imprimer rend la tâche complexes car une page de niveau
N+1 a besoin des données de la page N. Il faut préciser que le niveau de profondeur des pages est de
l’ordre de 4. Il faut préciser que l’impression du PDF doit se faire dès la page d’accueil de l’application sans
que ce soit nécessaire de naviguer vers toutes les pages. En quelque sorte la navigation au moment de
l’impression est implicite.
3. Le volume de données à compiler et à afficher est énorme.
4. Le nombre de graphes et leur complexité rend la tâche plus difficile
5. Le calcul de point attribué aux clubs est fortement couplé à l’IHM donc difficile de réutiliser
Solution :
Comme solution générale, j’ai préconisé l’usage d’un framework js (jsPDF) pour l’impression front du PDF. Le
choix se justifie par le rendu que les utilisateurs de l’applications veulent assez exact par rapport aux IHMs.
1. A défaut d’intégrer un moteur de navigation automatique que j’estimais coûteux et non maitrisé j’ai
proposé une solution d’extraction de toutes les pages à imprimer dans un bloc invisible mais disponible
sur la page d’accueil. Il a été toutefois nécessaire de réécrire une partie des services web pour que ce soit
possible. La réécriture des services web s’est avérée moins couteuse qu’autrement.
2. La programmation réactive côté js avec les Promise a permis d’améliorer la performance et aussi la
mécanique d’impression a été conçue pour être la plus optimale possible (l’extraction préalable des
contenus à imprimer à l’affichage de la page d’accueil rend le dispositif assez performant). La temps max
prévu était de 40s pour l’autodiagnostic mais la solution proposée a fait 4 fois moins soit 10s.
3. L’usage des caches a été implémenté, l’optimisation de certains web services et la délégation de la charge
du front vers le back de certains traitements identifiés.
4. Pour les graphes utilisés des outils js tels que ChartJS, HighCharts, pour leur génération et leur affichage
(la réécriture des services web de synthèse a été absolument importante pour améliorer les perofrmances)
5. L’application du principe SOLID (Single responsibility principle, Open/closed principle, Liskov substitution
principle, Interface segregation principle, Dependency inversion principle) a permis de séparer l’IHM des
traitements métiers et ainsi réutiliser notamment ceux du calcul du points côté front. Cette séparation a
aussi a rendu possible la réutilisation du calcul de points à plusieurs niveaux.
Bénéfices :
✓ Aucun impact sur l’architecture.
✓ Rendu PDF assez fidèle de l’IHM
✓ Performance du système maintenu.
✓ Génération du PDF de l’autodiagnostic en 10s.
ISTA
Developpeur Fullstack angular8/Spring
ENERGIE
septembre 2019 - juin 2020 (9 mois)
Projet: Selfcare (Portail clients de consultation de la consommation eau chaude, eau froide et électricité)
Problème 1 : Données d’un utilisateur accessibles par les autres utilisateurs (projet Selfcare)
Description : Les données d’un utilisateur sont visibles par tous les autres utilisateurs. Comment le régler de
façon générique pour gagner en temps. Le régler de façon générique évite devoir le faire pour les requêtes
existantes et à chaque fois pour de nouvelles requêtes.
Solution : En réalité le problème ne vient pas des requêtes en elles même mais du fait qu’elles s’exécutent en
s’appuyant sur des données dont la confidentialité n’est pas garantie. Fort de ce constat je propose d’’intégrer
un mécanisme de filtre qui intercepte les appels clients, tri les données et passe à la couche d’exécution des
requêtes des données uniquement de l’utilisateur demandeur. Cette solution a été implémentée avec AspectJ
+ AOP pour l’interception des méthodes et la customisation des annotations pour la configuration des appels
à sécuriser. Les appels n’ayant pas de besoin d’être sécurisés ne sont simplement pas annotés. De plus il est
possible pour un appel donné de définir uniquement les données qu’on souhaite filtrer.
Bénéfices :
✓ Aucun impact sur l’architecture, le filtre étant totalement transverse.
✓ Pas de modification des requêtes, donc la couche d’accès aux données reste inchangée
✓ Le mécanisme est intégré une fois pour toute
✓ Augmentation de la performance, sauf les données d’utilisateur sont pris en compte à chaque appel
Problème 2 : Tri de données complexes (projet Selfcare front)
Description : L’utilisateur souhaite voir ses logements triés à l’écran suivant des critères ayant un ordre de
priorité et une valeur. Exemple je veux afficher mes logements en fonction prioritairement du statut (REGLE,
EN COURS, EN ATTENTE, ACTION CLIENT, etc.), ensuite du nombre de passage le plus élevé, ensuite du nombre
d’interventions, ensuite de la date du passage le plus ancien, ainsi de suite.
Solution : Conception d’un algorithme de tri des sur la base de deux paramètres le coefficient et la valeur
intrinsèque du critère. Le poids total du logement étant la somme des produits coefficient et valeur.
Implémentation de l’algorithme à travers un utilitaire qui prend en entrée une liste de binômes (critère,
priorité).
Bénéfices :
✓ Utilisation simple et intuitive par appel de fonction avec en entrée les critères et leurs priorités
✓ Code non verbeux (deux lignes de code, l’une pour l’appel de la fonction et l’autre pour le tri suivant
le poids calculé)
✓ Réutilisation simple et rapide pour le tri des installations, queues de chantier et signalements