Reprendre une application web existante : audit et transfert

Reprendre une application web héritée d’un prestataire ou d’un développeur parti se joue en quatre temps : récupérer le code, les accès et les données, auditer le code et ses dépendances, chiffrer en jours de travail les corrections reportées (la dette technique), puis stabiliser l’existant avant toute nouveauté. L’ordre compte plus que la vitesse.

Reprendre une application web : trois situations, trois risques

Une reprise commence rarement dans le calme. Elle suit une rupture, et la nature de cette rupture décide de ce que vous récupérerez sans effort.

• Le prestataire défaillant : société liquidée, interlocuteur injoignable, factures d’hébergement qui ne sont plus réglées. Les comptes sont à son nom, et rien ne garantit qu’ils resteront ouverts.
• La fin de contrat : la relation s’arrête et le transfert se négocie. Ce que le contrat n’a pas écrit devient une demande à formuler.
• Le développeur parti : salarié démissionnaire ou indépendant appelé ailleurs. Le code reste, la connaissance s’en va : la commande qui relance le serveur, la raison d’un contournement, le mot de passe d’un service tiers.

Dans les trois cas, quatre choses sont exposées. La continuité du service d’abord : un nom de domaine expiré ou un serveur suspendu pour impayé coupent l’application du jour au lendemain. Les données des clients ensuite, dont votre entreprise reste responsable même quand un tiers les héberge, puis la propriété du code, qui ne va pas de soi. La sécurité enfin, avec des comptes d’administration encore ouverts au nom d’une personne partie.

Une application web reprise sans méthode cumule ces risques en silence, jusqu’à la première panne. Un projet neuf suit une autre logique, détaillée dans le guide pour créer une application web ; ici, tout part de l’existant.

Récupérer le code, les accès et les environnements

Avant tout échange avec l’ancien intervenant, dressez la liste de ce qui fait tourner l’application. Elle sert de base à la demande écrite, puis de liste de contrôle à la réception.

• Les dépôts de code source, gérés en général avec Git, un outil de gestion de versions qui conserve l’historique de chaque modification : exigez cet historique complet, pas une archive du dernier état
• Les comptes d’hébergement et de services en ligne (serveurs, stockage, envoi de courriels), rattachés à une adresse de l’entreprise
• Les noms de domaine et leur zone DNS, l’annuaire qui relie le nom du site à l’adresse du serveur, enregistrés au nom de la société
• Les bases de données, avec un export récent et la description de leur structure
• Les clés d’API, ces identifiants qui ouvrent à l’application des services tiers par une interface de programmation : paiement, cartographie, authentification
• Les sauvegardes, leur emplacement, leur fréquence et la preuve qu’une restauration a déjà réussi
• Les environnements de test et de préproduction, avec leurs fichiers de configuration

Le transfert des accès se vérifie ligne par ligne : un identifiant reçu se teste le jour même.

Le code soulève ensuite une question de droit. Le Code de la propriété intellectuelle range les logiciels parmi les œuvres de l’esprit (article L112-2), et son article L113-9 attribue à l’employeur les droits patrimoniaux sur un logiciel écrit par un salarié dans l’exercice de ses fonctions, sauf stipulation contraire. Rien d’équivalent pour un prestataire extérieur : la propriété du code passe par un acte de cession, et l’article L131-3 exige que chaque droit cédé y fasse l’objet d’une mention distincte, avec un domaine d’exploitation délimité en étendue, destination, lieu et durée.

Les données personnelles suivent leur propre règle. Quand l’ancien prestataire les traitait pour votre compte, l’article 28 du RGPD (règlement général sur la protection des données) exige que son contrat prévoie, au terme de la prestation, leur suppression ou leur renvoi selon votre choix, puis la destruction des copies existantes. Demandez le renvoi par écrit, avant toute suppression.

Si vous confiez la suite à un prestataire, le contrat de reprise signé avec une agence développement web garantit ce que le premier projet n’avait pas écrit : un cadrage de la reprise, la propriété du code et une maintenance qui ne dépend plus d’une seule personne. C’est la règle qu’affiche Digital Unicorn : les droits de propriété intellectuelle sont cédés au client dès le paiement, et le code est versionné dans un dépôt Git ouvert à son nom, qui le laisse libre de poursuivre en interne ou avec une autre équipe. L’interface que voient les utilisateurs comme la logique métier exécutée sur le serveur y sont développées sous tests automatisés, chaque modification passant par une revue de code : exactement ce qui évite de revivre une reprise à l’aveugle.

Auditer le code et ses dépendances

Accès en main, l’audit du code porte sur votre application telle qu’elle tourne en production, dès les premières semaines : versions du langage et du cadriciel (framework), bibliothèques obsolètes, couverture de tests, failles déjà connues. Le but n’est pas de juger l’ancien développeur, mais de savoir ce qui casse quand vous touchez à quoi.

Ce que la lecture du code révèle

• La version du langage et du cadriciel, comparée au calendrier de support publié par leurs éditeurs
• Les bibliothèques tierces : leur nombre, la date de leur dernière mise à jour, celles que leurs auteurs ont abandonnées
• La couverture de tests, c’est-à-dire la part du code exécutée par des tests automatisés, et surtout leur présence sur les parcours critiques comme la connexion ou le paiement
• Les secrets écrits en clair dans le code, les comptes par défaut et les droits d’accès trop larges
• La structure : fichiers démesurés, code dupliqué, fonctions que plus rien n’appelle

Deux lectures se complètent. Les outils d’analyse statique parcourent le code sans l’exécuter et signalent duplications, complexité excessive et défauts de sécurité courants. La lecture humaine juge ce qu’aucun outil ne comprend : l’architecture, la cohérence des règles métier, les choix qui avaient une raison.

Les dépendances, premier foyer de failles

L’OWASP publie une liste de référence des dix risques majeurs des applications web, qu’il présente comme un document de sensibilisation destiné aux développeurs. Son édition 2025 élargit une catégorie apparue en 2013 sous l’intitulé « Using Components with Known Vulnerabilities » : elle couvre désormais toutes les défaillances de la chaîne d’approvisionnement logicielle (Software Supply Chain Failures). Le texte vise les composants vulnérables, plus pris en charge ou dépassés, et les projets qui ne suivent pas les versions de tous leurs composants, côté client comme côté serveur.

Les recommandations associées tracent le plan d’action d’une reprise : tenir un inventaire central des composants (nomenclature logicielle, ou Software Bill of Materials), surveiller en continu les bases publiques de vulnérabilités comme le catalogue CVE, retirer les dépendances, fonctions et fichiers qui ne servent plus. Les dépendances obsolètes repérées à cette étape alimentent le chiffrage qui suit.

Dette technique : la reconnaître, puis l’estimer en jours

Ward Cunningham a forgé la métaphore en 1992, dans un retour d’expérience présenté à la conférence OOPSLA : livrer un premier code revient à s’endetter, et chaque minute passée sur un code pas tout à fait juste compte comme un intérêt sur cette dette. Dans une reprise, la dette technique est héritée. Elle ne figure dans aucun contrat et se paie à chaque modification.

Pour la rendre visible, classez-la par nature :

• Le code : duplications, fonctions trop longues, contournements laissés « provisoires » depuis des mois
• Les dépendances : montées de version repoussées, bibliothèques sans successeur désigné
• Les tests : parcours critiques sans test automatisé, recette (la vérification fonctionnelle avant mise en ligne) menée de mémoire
• L’infrastructure : serveur configuré à la main, déploiement impossible à reproduire
• La documentation, traitée dans la section suivante

Chaque ligne reçoit ensuite une estimation en jours de travail, comme un devis de développement : la méthode des jours-homme pour chiffrer une application s’applique telle quelle. Les outils d’analyse font une partie du chemin. La documentation de SonarQube Server définit sa mesure de dette technique comme la somme des efforts de correction des défauts de maintenabilité, chacun estimé en minutes, et compte des journées de huit heures quand le total s’affiche en jours. Ce total ignore l’architecture et l’infrastructure : complétez-le à la main.

Reste à prioriser. Croisez deux critères : le risque si rien ne change, et la fréquence à laquelle la zone sera modifiée. Une zone fragile que personne ne touche peut attendre ; une zone fragile retouchée chaque mois passe en tête de liste.

Reconstituer la documentation manquante

La documentation manquante pèse lourd dans une reprise : chaque question sans réponse se paie en heures de recherche dans le code.

Les documents à reconstituer, par ordre d’utilité :

• Un fichier de présentation (README) qui explique comment installer le projet, lancer les tests et déployer
• Un schéma d’architecture : composants, flux, services tiers appelés
• Le modèle de données, avec les tables qui contiennent des données personnelles
• La liste des variables de configuration et des secrets, sans leurs valeurs, avec leur lieu de stockage
• La procédure de mise en production et de retour arrière
• Un registre des décisions techniques (Architecture Decision Records) : chaque choix, sa date, sa raison

Les sources existent, même dispersées : l’historique Git raconte pourquoi un fichier a changé, quand les messages de validation sont soignés. Les journaux d’erreurs montrent ce qui casse en production. Et si le contrat le prévoit, quelques heures de passation rémunérées avec l’ancien développeur épargnent des jours de lecture. Écrivez au fil de l’audit, pas après.

Pour la trame, le cycle décrit dans ce guide pour développer une application web, de l’architecture au déploiement, fournit un plan de documentation réutilisable.

Les premières semaines : stabiliser avant d’ajouter

Les équipes métier attendent souvent des nouveautés dès l’arrivée du repreneur. Résistez. Une reprise d’application réussie commence par un gel des fonctionnalités, le temps de rendre l’existant fiable.

Sécuriser ce qui tourne déjà

• Changer tous les secrets hérités : mots de passe, clés d’API, jetons d’accès
• Fermer les comptes de l’ancien intervenant et activer la double authentification sur les consoles d’administration
• Restaurer une sauvegarde sur un environnement de test, pour vérifier qu’elle fonctionne
• Appliquer d’abord les correctifs des failles connues relevées pendant l’audit

Ces gestes prolongent les réflexes de cybersécurité pour protéger vos données, appliqués cette fois à l’infrastructure d’une application. Pour une revue plus large, le guide d’hygiène informatique de l’ANSSI, publié en 2017, rassemble 42 mesures à l’intention des responsables de l’informatique d’une organisation.

Rendre l’exploitation reproductible

Viennent ensuite la supervision, avec des alertes de disponibilité et un suivi des erreurs, puis l’intégration continue : une chaîne automatique qui compile, teste et déploie chaque modification. Un déploiement doit pouvoir être rejoué par une autre personne que celle qui l’a conçu. Les premiers tests automatisés couvrent les parcours qui rapportent ou qui exposent : connexion, paiement, saisie de données personnelles.

La feuille de route fonctionnelle reprend quand trois conditions sont réunies : un déploiement reproductible, une sauvegarde testée, des dépendances encore maintenues.

Prochaine étape : ouvrez un document partagé et notez, pour chacun des sept éléments de l’inventaire, qui détient l’accès aujourd’hui et à quel nom il est enregistré. Chaque case vide devient votre première demande écrite.