Audit, réparation et reprise après un autre développeur
Comprendre un code inconnu, identifier les causes profondes, corriger le chemin critique et établir un plan sûr pour la suite.
En quoi consiste ce travail
Quand un projet en production est fragile, lent ou abandonné, je reproduis les problèmes et corrige les causes par ordre de priorité. Une réécriture complète n’est envisagée que si les faits la justifient.
Pour qui
- Propriétaires d’un système qui fonctionne mais qu’il semble risqué de modifier
- Entreprises après le départ d’un prestataire ou d’un développeur
- Équipes qui ont besoin d’un second regard sur l’architecture et les risques
Questions réglées avant le début de la réalisation
- Qu’est-ce qui fonctionne, et qu’est-ce qui échoue ?
- Quels processus sont critiques pour l’activité ?
- Que sait-on des décisions passées et de la dette technique ?
- Quel budget est disponible pour réparer plutôt que réécrire ?
Déroulement du travail
Diagnostic
Lancer le système, examiner sa structure et reproduire les défaillances.
Prioriser
Distinguer les correctifs urgents, ce qui peut attendre et les zones à ne pas toucher.
Modifier avec prudence
Apporter des corrections ciblées et tester les processus liés.
Transmettre
Documenter ce qui a changé, ce qui reste et comment poursuivre.
Limites et règles de travail
- Ne réécrire que si c’est réellement plus sûr et moins coûteux
- Diagnostiquer avant de budgéter
- Tester les changements sur des processus réels