Ma méthode
Une approche structurée pour remettre en état vos applications Java — sans tout réécrire, sans surprises, avec un transfert de compétences réel.
Audit & Discovery
Comprendre avant d'agir
Je commence par des discussions avec votre équipe métier pour isoler les flux d'utilisation critiques. J'applique la loi de Pareto : environ 20% des flux couvrent 80% de la valeur de l'application. C'est là qu'on concentre l'effort.
Si vous avez une suite de tests d'acceptation (e2e), on la review ensemble et on complète les manques. Sinon, je fais de l'Example Mapping avec vos équipes pour poser une base solide — en Gherkin, réutilisable ensuite pour les tests de charge.
Je développe les tests e2e manquants si nécessaire, puis je lance l'analyse technique.
Analyse technique
Mesurer la dette, identifier les risques
Je mets en place un pipeline d'analyse complet sur votre environnement de pré-production :
J'ajoute à ça une analyse manuelle de l'architecture et du design — les outils ne voient pas tout.
À l'issue de cette phase, vous avez un état des lieux clair : où est la dette, où sont les risques, où sont les goulots de performance.
Point d'arrêt possible. Ces deux premières phases constituent un micro-forfait indépendant. Vous pouvez repartir avec l'audit et gérer la suite en interne. Pas de problème — vous savez où vous en êtes.
Phasage & Priorisation
Intégrer le refactoring dans votre réalité
On construit ensemble la roadmap de remise en état avec vos décideurs. Le refactoring s'intègre dans votre roadmap existante — on ne bloque pas le business.
La priorisation se fait selon la criticité des problèmes identifiés : sécurité d'abord, puis performance, puis maintenabilité. Chaque brique est un micro-forfait avec un périmètre, un livrable et un prix définis.
Exécution & Accompagnement
Refactorer en transférant les compétences
J'exécute la roadmap avec votre équipe — pas à leur place. L'objectif est de les rendre autonomes, pas de créer une dépendance.
- Mob-programming obligatoire sur les éléments critiques — votre équipe comprend ce qui est fait et pourquoi
- Formation continue intégrée au travail quotidien
- Mise en place CI/CD progressive — les bonnes pratiques s'ancrent dans le process
- Documentation des décisions (ADR) au fil de l'exécution — tout reste dans le repo, à jour avec le code
Clôture & Validation
Prouver que le travail est fait — et que l'équipe est prête
La fin de mission est définie clairement :
Dans les deux cas, je propose une période de validationOffert : votre équipe travaille sans moi pendant un à trois mois selon la complexité, puis je fais un dernier audit pour valider qu'elle est autonome.
C'est ma façon de prouver que j'ai fait mon travail. Vous n'avez pas à payer pour ça.
Un doute sur l'état de votre application ?
Échangeons 30 minutes. On regarde votre situation, je vous dis si cette méthode s'applique à votre cas.
Réserver un créneau