Reprendre une application existante

Pourquoi et quand reprendre une application existante

On reprend une application existante quand le prestataire d'origine est parti, quand le projet est bloqué, ou quand on hérite d'un code qu'on n'a pas écrit. Dans tous les cas, l'application vit déjà, en production ou à moitié terminée. L'enjeu n'est pas de repartir de zéro, mais de reprendre la main sur un actif qu'on ne maîtrise pas encore.

La situation est bien plus fréquente qu'on ne le croit. Un développeur freelance qui ne répond plus, une agence avec laquelle le courant ne passe plus, un associé technique qui quitte le projet, un rachat de société avec son logiciel maison : du jour au lendemain, vous vous retrouvez responsable d'une application dont personne ne connaît plus les entrailles. Le code existe, il tourne peut-être même très bien, mais il est devenu une boîte noire.

Le premier réflexe, souvent, est la panique : faut-il tout jeter et recommencer ? La réponse est presque toujours non. Un code hérité (ce qu'on appelle en anglais le legacy code, du code existant dont on prend la suite) représente une valeur réelle : des mois de travail, des fonctionnalités qui marchent, des utilisateurs habitués. Le jeter par confort serait gaspiller cet actif. La bonne démarche consiste à comprendre avant de décider, et c'est exactement ce que couvre une reprise de projet bien menée.

Auditer l'existant : code, architecture, dette technique

Auditer l'existant, c'est établir un diagnostic précis de trois choses : la qualité du code, la solidité de l'architecture et le poids de la dette technique. Cet audit répond à une seule question : dans quel état est vraiment cette application, et combien coûtera de la faire évoluer ? Sans ce diagnostic, tout engagement se fait à l'aveugle.

L'audit d'une application reprise se déroule sur plusieurs axes. On regarde d'abord le code lui-même : est-il lisible, organisé, commenté ? Utilise-t-il des technologies encore maintenues ou des briques abandonnées ? On examine ensuite l'architecture : la façon dont l'application est structurée, comment ses parties communiquent, si elle peut supporter la charge et évoluer sans tout casser. On vérifie aussi la présence de tests automatisés, ce filet de sécurité qui permet de modifier le code sans tout casser à chaque fois.

Le cœur de l'audit, c'est l'évaluation de la dette technique : l'accumulation des raccourcis et des choix vieillissants qui ralentissent toute évolution future. Une dette légère, c'est du code un peu daté mais sain. Une dette lourde, c'est une application où le moindre changement en casse trois autres. Cette distinction change tout : elle sépare une reprise sereine d'un chantier à haut risque. Voici les points que je regarde systématiquement :

• La lisibilité du code. Un code clair se reprend ; un code obscur se paie en heures de rétro-ingénierie avant la moindre modification.
• Les dépendances et les versions. Des bibliothèques obsolètes ou des langages en fin de vie sont un risque de sécurité et un frein aux évolutions.
• La présence de tests et de documentation. Leur absence multiplie le coût de chaque changement et le risque de régression.
• Les failles de sécurité. Une application non maintenue accumule les vulnérabilités connues, qu'il faut identifier avant qu'elles ne soient exploitées.

Récupérer les clés : code, accès et propriété

Avant toute reprise technique, il faut récupérer les clés du projet : le code source complet, tous les accès (hébergement, domaines, bases de données, services tiers) et la propriété intellectuelle du travail. Sans ces éléments, on ne reprend rien du tout. C'est l'étape la plus négligée, et pourtant celle qui bloque le plus de projets.

La reprise d'un projet est d'abord une opération de récupération. Le code source doit vous être transmis dans son intégralité, idéalement avec son historique Git (l'outil qui archive chaque version du code et retrace qui a modifié quoi). Il faut aussi rassembler les accès à l'hébergement et au serveur, les identifiants des noms de domaine, les bases de données, et les comptes de tous les services tiers connectés à l'application (paiement, envoi d'e-mails, cartographie, etc.). Un seul accès manquant peut immobiliser un projet entier.

Reste la question, souvent floue, de la propriété du code. Qui possède réellement ce qui a été développé ? Cela dépend du contrat initial et de la répartition des rôles entre le donneur d'ordre et le réalisateur. Cette distinction entre celui qui commande et celui qui produit est structurante ; je la détaille dans le glossaire MOA, MOE et AMOA. En pratique, faites clarifier par écrit que la propriété intellectuelle du code vous revient bien, sans quoi la moindre évolution future peut se transformer en litige.

Décider : reprendre, refactorer ou reconstruire

Une fois l'audit posé, trois options se présentent : reprendre le code en l'état et l'améliorer par petites touches, refactorer les zones fragiles sans tout réécrire, ou reconstruire tout ou partie de l'application. Le bon choix dépend du niveau de dette technique et de la valeur du socle existant. La réécriture totale est presque toujours la plus coûteuse et la plus risquée.

C'est la décision centrale d'une reprise, et elle mérite d'être prise à froid, pas sous le coup de l'agacement face à un code qu'on n'a pas écrit. La reprise en l'état convient quand les bases sont saines : on garde le socle et on le fait évoluer progressivement. Le refactoring (réécrire proprement une partie du code sans changer ce qu'il fait) s'impose quand certaines zones sont fragiles mais que l'ensemble reste exploitable : on assainit les points critiques, un par un, sans interrompre le service.

La reconstruction complète, elle, ne se justifie que dans les cas extrêmes : code irrécupérable, technologie totalement obsolète, ou architecture incapable de porter les ambitions du produit. C'est la tentation classique du développeur qui découvre le code d'un autre : « autant tout refaire ». Or, réécrire de zéro fait perdre des mois, réintroduit des bugs que l'ancienne version avait déjà corrigés, et coûte bien plus cher qu'une amélioration progressive. Mon principe : on ne reconstruit que ce qui est prouvé irrécupérable, jamais par confort.

Sécuriser la transition : documentation et tests

Sécuriser la transition, c'est transformer une boîte noire en un projet maîtrisé et transmissible. Cela passe par deux leviers concrets : documenter ce qui existe (architecture, procédures, environnements) et mettre en place des tests qui protègent contre les régressions. Une application reprise sans ces garde-fous reste fragile, quelle que soit la qualité du code.

Le danger d'un code hérité, c'est de rester dépendant d'une connaissance qui n'est écrite nulle part. La première mesure est donc de documenter : comment l'application est structurée, comment on la déploie, quels sont les environnements, où se trouvent les points sensibles. Cette documentation n'a pas besoin d'être parfaite : elle doit être suffisante pour qu'un nouveau développeur puisse prendre le relais sans repartir de l'enquête à zéro.

Le second levier, ce sont les tests. Sur une application reprise, ils jouent un rôle particulier : ils figent le comportement attendu avant qu'on ne touche au code. Ajouter des tests sur les parcours critiques avant de modifier quoi que ce soit, c'est se donner un filet : on saura immédiatement si une modification casse une fonctionnalité qui marchait. Une fois la transition sécurisée, la reprise débouche naturellement sur un régime de maintenance de l'application durable, qui empêche la dette technique de se reconstituer.

Le rôle du pilote dans une reprise

Dans une reprise, le pilote fait le lien entre l'ancien code et la suite du projet. Il commande l'audit, arbitre entre reprendre, refactorer et reconstruire, sécurise la récupération des accès, et cadre la transition. Son rôle est de transformer une situation subie en décisions maîtrisées, sans se laisser intimider par un code qu'il n'a pas écrit.

Une reprise réussie tient moins à la virtuosité technique qu'à la qualité du pilotage. C'est lui qui pose les bonnes questions : dans quel état est vraiment cette application ? Que garde-t-on, que jette-t-on ? Qui va reprendre le développement, en interne, avec une agence, ou avec un nouveau prestataire ? Le pilote évite deux écueils symétriques : s'accrocher à un code irrécupérable par peur du changement, ou tout jeter par excès de confiance.

Choisir à qui confier la suite est d'ailleurs une décision aussi structurante que sur un projet neuf, et elle se cadre de la même manière qu'un cahier des charges de développement, en repartant du besoin réel plutôt que de l'existant. Les mécaniques de suivi, elles, sont exactement celles d'un projet mené de bout en bout : sprints, recette, arbitrages. Je les détaille dans le guide piloter une équipe de développeurs. Une reprise n'est, au fond, qu'un projet de développement qui commence au milieu.