Reprendre une application en difficulté : audit, diagnostic et plan de redressement

Votre application métier ou votre plateforme client fonctionnait, plus ou moins. Puis les choses se sont dégradées : des délais qui s’allongent, des bugs qui reviennent, un prestataire qui ne répond plus, des utilisateurs qui se plaignent. Et vous vous retrouvez avec un outil dont votre activité dépend, mais que plus personne ne semble vraiment maîtriser.

C’est une situation plus courante qu’on ne le pense, et elle se redresse dans la grande majorité des cas, à condition de procéder dans le bon ordre. La pire réaction est de décider trop vite : tout jeter et repartir de zéro, ou au contraire continuer à empiler des correctifs sans comprendre le problème. Voici la méthode que nous appliquons lorsque l’on nous confie la reprise d’une application en difficulté.

Les signaux d’alerte

Une application ne bascule pas en difficulté du jour au lendemain. Plusieurs signes, souvent cumulés, doivent vous alerter :

• Des délais qui dérivent : chaque évolution, même simple, prend plusieurs semaines et les estimations ne sont jamais tenues.
• Des bugs récurrents : corriger un problème en crée un autre ailleurs, et les mises en production deviennent redoutées.
• Un prestataire parti ou injoignable : le freelance a changé de projet, l’agence a fermé ou la relation s’est dégradée.
• Aucune documentation : personne ne sait expliquer comment l’application est construite, ni comment la déployer.
• Des performances en baisse : pages lentes, traitements qui échouent, serveur qui sature aux heures de pointe.
• Des inquiétudes de sécurité : composants jamais mis à jour, mots de passe partagés par e-mail, incident déjà survenu.

Si vous cochez plusieurs cases, il est temps d’agir de manière structurée.

Étape 1 : sécuriser les accès avant tout

Avant même de regarder le code, la priorité absolue est de vous assurer que vous contrôlez votre propre application. Dans nos reprises, c’est souvent là que se cachent les risques les plus graves : un nom de domaine enregistré au nom du prestataire, un hébergement payé sur sa carte bancaire, un code source dont personne d’autre n’a de copie.

Faites l’inventaire et récupérez :

• Le code source : l’accès administrateur au dépôt (GitHub, GitLab, Bitbucket), avec l’historique complet, pas une simple archive.
• L’hébergement : les comptes chez l’hébergeur ou le fournisseur cloud, idéalement à votre nom et avec votre moyen de paiement.
• Les noms de domaine et les DNS : le registraire, le compte propriétaire et les accès à la configuration.
• Les identifiants des services tiers : paiement, envoi d’e-mails, stockage de fichiers, cartographie, API diverses, comptes des stores mobiles le cas échéant.
• Les sauvegardes : où sont-elles, à quelle fréquence, et surtout, une restauration a-t-elle déjà été testée ?

Stockez ensuite ces accès dans un gestionnaire de mots de passe partagé, changez ceux qui ont circulé sans précaution et retirez les accès des personnes qui n’en ont plus besoin. Si le prestataire précédent est encore joignable, une passation formelle, même courte, est précieuse.

Étape 2 : l’audit technique

Une fois les accès sécurisés, on peut évaluer l’état réel de l’application. Un audit technique sérieux examine plusieurs dimensions :

Qualité du code

Le code est-il lisible, cohérent, organisé ? Les mêmes logiques sont-elles copiées à plusieurs endroits ? Un développeur qui découvre le projet peut-il s’y retrouver ? On ne cherche pas la perfection, mais à savoir s’il est raisonnable de continuer à construire dessus.

Architecture

Comment l’application est-elle découpée ? Les responsabilités sont-elles séparées (interface, logique métier, accès aux données) ou tout est-il entremêlé ? L’architecture est-elle adaptée au volume d’utilisateurs et aux évolutions prévues ?

Dépendances

Les bibliothèques et frameworks utilisés sont-ils encore maintenus ? Quel retard de version accusent-ils ? Une application bâtie sur une version abandonnée d’un framework pose un problème de sécurité et rend les évolutions de plus en plus difficiles.

Sécurité

Gestion de l’authentification, protection contre les failles courantes, stockage des mots de passe, secrets présents en clair dans le code, droits d’accès aux données : ces points sont vérifiés en priorité, car ils exposent votre responsabilité.

Tests

Existe-t-il des tests automatisés ? Couvrent-ils les parcours critiques (inscription, paiement, calculs métier) ? Sans tests, chaque modification se fait à l’aveugle, ce qui explique souvent les régressions à répétition.

Infrastructure et déploiement

Comment l’application est-elle mise en production ? Par un processus automatisé et reproductible, ou par une manipulation manuelle que seul l’ancien prestataire connaissait ? Existe-t-il un environnement de test séparé ? Une supervision qui alerte en cas de panne ?

Données

La base de données est-elle cohérente ? Y a-t-il des doublons, des données orphelines, des incohérences entre tables ? Les données personnelles sont-elles traitées conformément au RGPD ? Ce sont vos données qui ont le plus de valeur : leur état conditionne toutes les options de redressement.

Étape 3 : l’audit produit

L’audit technique dit comment l’application est construite. L’audit produit dit si elle sert vraiment. Les deux sont indispensables.

• Quelles fonctionnalités sont réellement utilisées ? Les statistiques d’usage, quand elles existent, réservent souvent des surprises : des écrans entiers que personne n’ouvre, et des contournements bricolés pour combler un manque.
• Que disent les utilisateurs ? Quelques entretiens avec ceux qui utilisent l’outil au quotidien révèlent les vrais points de friction.
• Quelle valeur l’application crée-t-elle ? Chiffre d’affaires, temps gagné, satisfaction client : qu’est-ce qui serait perdu si elle s’arrêtait ?

Cet audit permet souvent de réduire le périmètre : inutile de réparer ou de réécrire une fonctionnalité que personne n’utilise.

Étape 4 : stabiliser, refactorer ou réécrire ?

Le diagnostic posé, vient la décision structurante. Trois grandes options existent.

Stabiliser

Si l’application est globalement saine mais négligée, on corrige les urgences : mises à jour de sécurité, bugs bloquants, sauvegardes fiables, déploiement documenté. C’est l’option la plus rapide, et souvent la première étape quelle que soit la suite.

Refactorer progressivement

Refactorer consiste à améliorer la structure du code sans changer ce qu’il fait pour l’utilisateur. On assainit l’application par petites touches, module par module, en ajoutant des tests au fur et à mesure. L’application continue de fonctionner et d’évoluer pendant ce temps. C’est l’option que nous recommandons le plus souvent.

Réécrire

Parfois, la réécriture est justifiée : technologie obsolète et non maintenue, architecture incompatible avec les besoins, code impossible à faire évoluer sans tout casser. Mais la réécriture complète d’un coup est l’option la plus risquée. Pendant des mois, vous financez une nouvelle version qui ne rapporte rien, l’ancienne continue de vivre avec ses problèmes, et la nouvelle doit rattraper des années de règles métier implicites que personne n’avait documentées. Beaucoup de réécritures dépassent largement leurs délais, voire n’aboutissent jamais.

L’approche du « figuier étrangleur »

Pour réécrire sans prendre ce risque, il existe une stratégie éprouvée appelée strangler fig pattern, du nom d’un figuier tropical qui pousse autour d’un arbre existant jusqu’à le remplacer complètement.

Le principe est simple : plutôt que de tout reconstruire à côté, on remplace l’ancienne application morceau par morceau. On place un point d’entrée unique devant l’application existante, puis on reconstruit une première fonctionnalité dans le nouveau système, on y redirige le trafic correspondant, et on recommence avec la suivante. Les utilisateurs continuent d’utiliser un outil qui fonctionne, chaque étape apporte une amélioration visible, et l’on peut s’arrêter ou changer de priorité à tout moment. Quand plus rien ne passe par l’ancien système, on peut l’éteindre.

Étape 5 : le plan de redressement

La décision prise, on la traduit en un plan par phases, chacune avec des objectifs mesurables.

1. Sécurisation (premières semaines) : accès récupérés, sauvegardes testées, failles critiques corrigées, supervision en place.
2. Stabilisation : bugs bloquants corrigés, déploiement automatisé, environnement de test, documentation minimale de l’existant.
3. Assainissement : refactorisation des zones les plus fragiles, ajout de tests sur les parcours critiques, mise à jour des dépendances, ou premières étapes du remplacement progressif.
4. Reprise des évolutions : retour à une feuille de route produit, avec un rythme de livraison prévisible, en consacrant une part de chaque cycle à la réduction de la dette technique.

Chaque phase se conclut par un point avec vous, pour mesurer les progrès et ajuster la suite. Un projet de reprise se pilote comme un projet à part entière, idéalement avec un responsable technique identifié, en interne ou à travers un CTO à temps partagé.

Se protéger contractuellement pour l’avenir

Une reprise difficile est souvent la conséquence d’un contrat mal ficelé. Pour éviter que la situation se reproduise :

• Propriété du code : le contrat doit prévoir la cession des droits de propriété intellectuelle sur le code développé spécifiquement pour vous, une fois les prestations réglées.
• Clause de réversibilité : elle oblige le prestataire à vous remettre, en fin de contrat, le code, les données, les accès et la documentation nécessaires pour qu’un tiers reprenne le projet, et à accompagner cette transition.
• Accès à votre nom : dépôt de code, hébergement, nom de domaine et services tiers doivent appartenir à votre entreprise, le prestataire n’y ayant que des droits délégués.
• Séquestre du code (escrow) : lorsque le code n’est pas cédé (logiciel édité par le prestataire, par exemple), un dépôt chez un tiers de confiance vous garantit d’y accéder si le prestataire disparaît.
• Documentation et tests comme livrables : inscrivez-les explicitement dans le contrat, au même titre que les fonctionnalités.

Ces points sont à intégrer dès la rédaction du cahier des charges de vos prochains projets.

En résumé

• Ne décidez rien avant d’avoir sécurisé vos accès : code, hébergement, domaines, identifiants, sauvegardes.
• Réalisez un audit technique (code, architecture, dépendances, sécurité, tests, infrastructure, données) et un audit produit (usages, valeur).
• Privilégiez la stabilisation puis la refactorisation progressive ; si une réécriture s’impose, faites-la morceau par morceau plutôt que d’un seul bloc.
• Pilotez le redressement par phases, avec des objectifs mesurables.
• Protégez-vous pour l’avenir : propriété du code, réversibilité, accès à votre nom.

Reprendre une application que d’autres ont construite fait partie de notre métier. Chez JDDW, nous auditons, stabilisons et faisons évoluer des applications web existantes, avec une approche pragmatique et transparente. Si votre outil vous inquiète, présentez-nous la situation : nous vous dirons honnêtement ce que nous en pensons et par où commencer.