Avant de corriger ou de refaire quoi que ce soit, une reprise commence par un cadrage : un inventaire écran par écran de ce qui fonctionne, ce qui casse, et ce qui n'aurait jamais dû être développé en premier lieu. C'est ce travail, plus que le code lui-même, qui détermine si une reprise prend 6 semaines ou 6 mois.
La semaine 1 d'une reprise : audit et plan de sauvetage
La première semaine d'une reprise ne produit pas de code. Elle produit un diagnostic : un test fonctionnel complet de l'application (chaque écran, chaque parcours), un inventaire de ce qui est récupérable techniquement, et une décision documentée (garder, corriger, refaire ou supprimer) pour chaque fonctionnalité existante. C'est ce diagnostic qui sert de base au devis, pas une estimation à l'aveugle.
Les 3 questions à reposer
Une application qui ne marche pas est souvent une application qui n'a jamais eu de réponse claire à trois questions, posées avant la première ligne de code : quel problème précis elle résout, pour qui exactement, et pourquoi ce moment précis. Reposer ces trois questions sur l'existant permet de distinguer les fonctionnalités qui servent réellement l'objectif initial de celles qui ont été ajoutées en cours de route sans raison claire, et qui sont souvent la source des bugs les plus coûteux à maintenir.
La grille garder, corriger, refaire, supprimer
L'inventaire fonctionnel classe chaque écran ou fonctionnalité dans l'une de quatre catégories :
- Garder : fonctionne correctement, ne demande aucune intervention.
- Corriger : le principe est bon, l'exécution a des défauts identifiés et localisés.
- Refaire : le code est absent, illisible, ou construit sur une base qui ne tient pas.
- Supprimer : la fonctionnalité n'a jamais servi l'objectif initial de l'application ; l'entretenir coûte plus qu'elle ne rapporte.
Cette grille, remplie écran par écran, remplace une estimation globale approximative par une décision précise et justifiable pour chaque partie de l'application.
Couper pour relancer
Une application de 20 écrans dont aucun ne fonctionne vraiment redevient souvent, après cadrage, une application de 6 écrans qui fonctionne. Couper des fonctionnalités n'est pas un aveu d'échec : c'est reconnaître que chaque fonctionnalité maintenue en production a un coût de maintenance récurrent, et que peu d'entre elles sont réellement utilisées par les utilisateurs. La question à se poser pour chaque fonctionnalité existante n'est pas « est-ce qu'elle pourrait servir ? » mais « qui l'utilise, aujourd'hui, et à quelle fréquence ? ».
Le coût du flou
Un scope mal défini se paie plus tard, presque toujours à un taux plus élevé qu'au moment du cadrage. Une fonctionnalité ajoutée « parce qu'on y avait pensé », sans lien clair avec l'objectif de l'application, coûte du temps de développement, du temps de test, et souvent de la dette technique quand elle interagit mal avec le reste du code. Le cadrage n'élimine pas ce risque, mais il le rend visible avant qu'il ne se traduise en semaines de retard.
Le guide gratuit propose une checklist similaire, à faire vous-même avant de payer un cadrage complet.
Exemple de plan de sauvetage en une page
Le livrable concret d'une semaine de cadrage tient sur une page : la liste des écrans avec leur statut (garder / corriger / refaire / supprimer), les accès et informations encore à récupérer, l'ordre de traitement retenu, et une estimation de délai par bloc. Ce document sert de référence tout au long de la reprise : c'est lui qui est vérifié à chaque étape, pas une impression générale de progression.
Une application à cadrer avant de vous lancer dans la reprise ?
Ce cadrage est la semaine 1 de l'offre de reprise Zuhd Studio : 9 500 € prix fixe, 60 jours ouvrés au total.
Voir l'offre de reprise