ÉTUDE DE CAS 01 — LOGICIEL BESTT · GROUPE AURIOR
Reprendre seul deux SaaS critiques — puis industrialiser leur delivery
Le seul développeur en poste s'en va. Cinq jours de passation, deux produits à forte volumétrie, aucune documentation — et un « pipeline » qui consiste à pousser du code directement sur le serveur de production. Voilà où ça commence.
— LE PROBLÈME
Deux logiciels SaaS métier, utilisés chaque jour par des agences d'intérim, des entreprises et des candidats. Un seul développeur les connaissait — et il partait. J'ai eu cinq jours de passation pour absorber l'ensemble : architecture, hébergement, particularités clients, dettes cachées.
Le plus inquiétant n'était pas le code. C'était le delivery : un hook post-push branché sur le serveur de production. Chaque push partait immédiatement en prod, sans test, sans build, sans retour arrière possible. Sur des applications critiques, chaque intervention était un pari.
Il fallait donc deux choses à la fois : ne rien casser pendant que j'apprenais le système, et construire au plus vite un filet de sécurité.
— LES DÉCISIONS D'ARCHITECTURE
1Stabiliser avant de refondre
Premier réflexe : cartographier et documenter l'existant plutôt que le réécrire. Geler les interventions risquées, noter chaque découverte. En quelques semaines, cette documentation m'a fait passer de « nouveau » à référence technique de l'équipe — c'est elle qui a rendu tout le reste possible.
2Une infrastructure de delivery dédiée : GitLab auto-hébergé + Jenkins
Plutôt qu'un service SaaS, un GitLab auto-hébergé — maîtrise des données clients et des coûts — couplé à Jenkins pour l'orchestration fine des jobs de build et de déploiement. L'arbitrage : séparer clairement la forge (code, MR, revues) de la chaîne de déploiement, pour pouvoir faire évoluer l'une sans toucher l'autre.
3Conteneuriser et rendre observable
Portainer pour la gestion des conteneurs, Traefik en reverse proxy, Grafana pour le monitoring. Objectif : des environnements reproductibles, un routage propre entre applications, et des métriques visibles par toute l'équipe — plus de production « boîte noire ».
— L'IMPLÉMENTATION
Tout s'est fait par étapes, sans jamais interrompre le service : j'assurais en parallèle le support expert en lien direct avec la hotline. D'abord la forge et les premières pipelines de build, puis les déploiements à la demande sur un produit pilote, enfin la généralisation aux deux produits.
Cette base a permis d'accueillir progressivement deux développeurs, avec un cadre déjà posé : spécifications techniques, revues de code systématiques, répartition des sujets. L'équipe est aujourd'hui autonome sur l'ensemble du périmètre.
— LES RÉSULTATS
AVEC LE RECUL
« La meilleure décision n'était pas technique : c'était de documenter avant d'agir. Sur du legacy critique, la connaissance partagée est le premier filet de sécurité — avant même la CI. »