Expérience et projets

Le contexte

EPC Familia gère un réseau de 102 pharmacies. Pour surveiller son infrastructure, l'équipe IT jonglait entre plusieurs outils séparés (Centreon, Jenkins...) sans vue d'ensemble rapide, et certains contrôles propres au métier n'étaient couverts par aucun outil.

SAMI (Surcouche d'Alerting et Monitoring IT) ne remplace pas ces outils : elle rassemble leurs informations et y ajoute ses propres contrôles, sur deux écrans affichés en permanence dans le bureau IT. À gauche, une grille de services colorés (vert, orange, rouge) ; à droite, le détail des sondes du service sélectionné.

Ce que j'ai réalisé

J'ai développé l'application de bout en bout, de l'analyse au déploiement :

• une API REST en Spring Boot avec une base PostgreSQL, couverte par des tests JUnit et Mockito ;
• l'interface en Vue.js sur deux écrans synchronisés, mise à jour en temps réel grâce aux WebSockets ;
• des alertes Microsoft Teams pour les pannes critiques, avec des filtres pour éviter le spam (heures de bureau, week-end, pas plus d'une alerte toutes les 5 minutes) ;
• l'authentification avec l'annuaire de l'entreprise et des jetons JWT, et le chiffrement des mots de passe et clés stockés en base ;
• le déploiement en conteneurs Docker, automatisé par des pipelines Jenkins, avec sauvegarde de la base de données.

Le choix technique principal : des sondes sans redéploiement

Au départ, chaque type de sonde (ping, appel d'API, requête SQL...) était une classe Java. Ajouter une nouvelle sonde demandait donc de modifier le code, recompiler et redéployer l'application.

J'ai remplacé ce système par un moteur unique : chaque sonde est un petit script Groovy stocké en base de données et exécuté dans un bac à sable sécurisé (les instructions dangereuses, comme lancer un programme ou lire un fichier, sont interdites). Une nouvelle sonde se crée maintenant depuis l'interface d'administration, avec un test du script avant de l'enregistrer.

Mesurer avant de choisir

Pour planifier l'exécution des sondes, j'ai comparé trois stratégies (un seul planificateur global, un par service, un par sonde) en mesurant la mémoire, les threads et le processeur sur 100 sondes. Les trois tenaient la charge : j'ai retenu un planificateur par sonde, car chacune garde sa propre fréquence (certaines toutes les 30 secondes, d'autres toutes les 5 minutes). Le pattern Strategy permet de changer de stratégie sans toucher au reste du code.

Résultat

À la fin du stage, plus de 150 sondes tournaient en production, les pannes critiques déclenchaient une alerte dans Microsoft Teams, et l'équipe IT avait une vue d'ensemble de son infrastructure. Un manuel utilisateur et un manuel technique accompagnent l'outil, pour faciliter sa prise en main et sa maintenance. Aujourd'hui, SAMI est utilisé chaque jour par l'équipe IT d'EPC Familia, et son déploiement dans d'autres départements est prévu.

Ce projet est documenté en détail dans mon travail de fin d'études.

Le contexte

Après mon stage, EPC Familia m'a engagé en job étudiant pour participer à la migration de ses bases de données Oracle vers PostgreSQL. Ce chantier est mené domaine métier par domaine métier, sans interrompre les applications utilisées chaque jour par les pharmacies.

Ce que j'ai réalisé

• Migrer la structure et les données de sept domaines métier avec Ora2Pg ; quatre d'entre eux sont passés en production pendant mon contrat.
• Adapter les microservices Spring Boot et les traitements Spring Batch pour qu'ils lisent et écrivent dans PostgreSQL.
• Réécrire en Java de la logique métier qui était stockée dans la base Oracle (procédures PL/SQL), pour rendre les applications indépendantes de la base de données.
• Écrire des tests unitaires (JUnit, Mockito) avant chaque test sur une vraie base, puis valider chaque migration sur l'environnement de test avant la mise en production.

Ma méthode, pour chaque domaine

• Lire le code des applications qui utilisent les tables, pour n'en oublier aucune.
• Configurer Ora2Pg : conversion des types, choix des tables et des colonnes à copier.
• Créer les tables et copier les données sur l'environnement de test, puis vérifier le résultat.
• Adapter le code Java, le tester, puis préparer la mise en production avec le référent technique.

Ce que j'en retiens

Ce job m'a appris à travailler dans un code existant et volumineux que je n'avais pas écrit, à vérifier dans le code plutôt que de supposer, et à avancer prudemment sur des données de production.

Ce que j'ai mis en place

• deux langues (next-intl) : chaque page existe en /fr et en /en ;
• un formulaire de contact qui envoie un email (Resend), avec validation côté serveur, protection CSRF et un champ piège contre les robots ;
• des en-têtes de sécurité (Content-Security-Policy, HSTS...) ;
• des tests Vitest et une intégration continue GitHub Actions (lint, types, tests, build) à chaque push ;
• un déploiement automatique sur Vercel, avec sitemap et données structurées pour le référencement.

Back-office web (React)

Application mobile Key2Go (React Native)

Librairie en ligne (Spring Boot, JSP)

Application desktop (Java Swing)