Votre application métier fonctionne, mais plus personne ne sait vraiment comment. Le développeur d’origine est parti, le prestataire ne répond plus, chaque modification provoque un nouveau bug, ou la technologie utilisée n’est plus mise à jour. Reprendre une application existante est une situation fréquente, et elle ne se traite pas en jetant tout pour recommencer.
La démarche raisonnable commence toujours par un audit, qui permet de choisir en connaissance de cause entre trois voies : stabiliser et maintenir l’existant, le refondre progressivement, ou migrer vers une nouvelle application. Voici comment se déroule cette reprise et sur quels critères trancher.
Les situations qui poussent à reprendre une application
Les déclencheurs sont variés, mais on retrouve souvent les mêmes cas de figure :
- le prestataire ou le développeur indépendant qui a créé l’outil n’est plus disponible ;
- le langage, le framework ou le serveur ne reçoivent plus de mises à jour de sécurité ;
- chaque évolution, même minime, prend des semaines et casse autre chose ;
- l’application est devenue lente à mesure que les données se sont accumulées ;
- elle n’est pas utilisable sur téléphone alors que vos équipes travaillent sur le terrain ;
- vos besoins ont changé et l’outil ne suit plus.
Aucune de ces situations n’impose à elle seule de tout réécrire. Elles imposent en revanche de faire le point sérieusement.
L’audit : la première étape indispensable
Un audit d’application consiste à examiner l’existant sous plusieurs angles pour produire un état des lieux factuel et des recommandations. Il dure généralement de quelques jours à quelques semaines selon la taille de l’application, et c’est un investissement modeste au regard des décisions qu’il éclaire.
Ce que l’audit examine
- L’accès : disposez-vous du code source, des accès au serveur, au nom de domaine, à la base de données ? C’est le premier point à sécuriser, parfois le plus délicat quand un prestataire a disparu.
- La technique : versions des technologies utilisées, qualité et lisibilité du code, présence de tests automatisés, documentation.
- La sécurité : failles connues des composants, gestion des mots de passe, droits d’accès, sauvegardes.
- Les données : structure de la base, cohérence, volumes, qualité des informations saisies au fil des années.
- L’usage : ce que les utilisateurs font réellement de l’outil, les contournements qu’ils ont inventés, les fonctions inutilisées.
Ce que l’audit produit
Un rapport lisible par un dirigeant, pas seulement par un développeur : les risques classés par gravité, les actions urgentes, et une comparaison chiffrée en ordres de grandeur des scénarios possibles. C’est sur cette base que la décision se prend.
Trois options pour la suite
1. Stabiliser et maintenir
Si le code est globalement sain et que la technologie reste supportée, la meilleure option est souvent de reprendre la maintenance : mettre à jour les composants, corriger les failles, documenter, mettre en place des sauvegardes testées. L’application continue sa vie, avec un prestataire qui la connaît désormais. Les points à prévoir sont détaillés dans notre article sur la maintenance d’une application web.
2. Refondre progressivement
Lorsque certaines parties sont saines et d’autres problématiques, on peut remplacer l’application module par module. Par exemple, on réécrit d’abord la gestion des plannings, la plus utilisée et la plus fragile, tandis que le reste continue de fonctionner. Cette approche limite les risques et étale l’investissement, mais elle demande une coordination rigoureuse entre l’ancien et le nouveau.
3. Migrer vers une nouvelle application
Quand la technologie est obsolète, le code impossible à faire évoluer ou les besoins profondément changés, une nouvelle application devient la solution la plus raisonnable. Ce n’est pas repartir de zéro : l’existant constitue une spécification précieuse, qui montre ce qui est utilisé et ce qui ne l’est pas. La migration des données historiques est alors un chantier à part entière.
Comparatif des trois approches
| Critère | Maintenir | Refondre progressivement | Migrer |
|---|---|---|---|
| Coût à court terme | Faible | Moyen, étalé | Plus élevé |
| Risque de rupture pour les utilisateurs | Faible | Modéré, par étapes | Concentré sur la bascule |
| Capacité à faire évoluer l’outil | Limitée par l’existant | Croissante | Forte |
| Pertinent si… | Le code et la technologie sont sains | Une partie de l’application est à sauver | L’existant n’est plus viable |
Les points de vigilance lors d’une reprise
- Récupérer la propriété de tout : code source, accès aux serveurs, nom de domaine, comptes chez les services tiers. Vérifiez aussi ce que prévoit votre contrat initial en matière de propriété intellectuelle.
- Sécuriser avant d’améliorer : une sauvegarde complète et une restauration testée doivent précéder toute modification.
- Corriger les failles urgentes : une application qui tourne sur des composants non maintenus est exposée. Notre guide des bonnes pratiques de sécurité donne les priorités.
- Impliquer les utilisateurs : ce sont eux qui savent quelles fonctions sont vitales et lesquelles peuvent disparaître.
- Ne pas reproduire à l’identique : en cas de migration, c’est l’occasion de simplifier les processus, pas de recopier des écrans conçus il y a dix ans.
Préparer la refonte ou la migration
Si l’audit conclut à une refonte ou à une migration, le projet se cadre comme un nouveau développement, avec un avantage : vous savez précisément ce qui fonctionne et ce qui manque. Formaliser ces besoins dans un document clair reste indispensable ; notre méthode pour rédiger le cahier des charges d’une webapp s’applique pleinement. Les étapes suivantes, de la conception à la mise en production, sont décrites dans notre article sur le déroulement d’un projet de webapp avec une agence.
Questions fréquentes
Peut-on reprendre une application sans le code source ?
C’est très difficile. Sans le code, on ne peut ni corriger ni faire évoluer l’application ; il reste alors à en reconstruire une nouvelle à partir de l’observation de l’existant et de ses données. D’où l’importance de récupérer le code au plus vite.
Faut-il arrêter l’ancienne application pendant la refonte ?
Non, dans la grande majorité des cas. L’ancienne application continue de fonctionner jusqu’à la bascule, qui est planifiée à un moment calme de votre activité.
Conclusion : décider sur des faits, pas sur des impressions
Une application vieillissante n’est pas forcément à jeter, et une application qui fonctionne n’est pas forcément sûre. L’audit permet de sortir des impressions pour décider entre maintenance, refonte progressive ou migration, avec une vision claire des risques et des coûts. Symbiose réalise ce type d’audit et accompagne ensuite la voie choisie. Si vous devez reprendre en main une application existante, parlons de votre situation.