Quels accès récupérer en premier ?
Tous ceux qui permettent de faire tourner, modifier et mettre en ligne l'application. Ils doivent être à ton nom, pas à celui du prestataire : c'est la première chose à régler, tant que le contact existe encore.
- Le dépôt du code (GitHub, GitLab, Bitbucket), avec tout l'historique.
- L'hébergement et les serveurs.
- Le nom de domaine et sa zone DNS, chez le bureau d'enregistrement.
- La base de données et ses sauvegardes.
- Les services tiers : paiement, envoi d'e-mails, cartes, statistiques.
- Les comptes développeur Apple et Google, s'il y a une application mobile.
- Les clés et les secrets de configuration (variables d'environnement).
- La documentation, les tickets et les maquettes, s'ils existent.
Que vérifie un audit de reprise ?
Il dit ce qui risque de casser, ce qu'il faut sécuriser tout de suite et ce qui peut attendre. Il se termine par un rapport écrit, avec les risques classés et une estimation.
| Point | Ce qu'on regarde | Pourquoi |
|---|---|---|
| Versions | Langage, framework, serveur, dépendances : sont-ils encore maintenus ? | Une version qui ne reçoit plus de correctifs de sécurité est une porte ouverte. Node.js 20, par exemple, n'est plus maintenu depuis 2026. |
| Sécurité | Failles connues des dépendances, mots de passe, droits, configuration. | Le Top 10 de l'OWASP sert de grille : contrôle d'accès, configuration, chaîne d'approvisionnement logicielle. |
| Données | Sauvegardes réelles et restaurables, données personnelles stockées. | Une sauvegarde jamais restaurée n'est pas une sauvegarde. |
| Code | Lisibilité, tests, dette technique, parties fragiles. | C'est ce qui fixe le coût de chaque évolution future. |
| Mise en ligne | Comment on déploie, et comment on revient en arrière. | Sans retour arrière, chaque mise en ligne est un pari. |
| Coûts | Hébergement, services tiers, abonnements oubliés. | On découvre souvent des frais inutiles, ou un service qui va expirer. |
Faut-il tout réécrire ?
Rarement. Réécrire coûte cher, prend du temps et réintroduit des bugs déjà corrigés. Le plus souvent, on consolide par morceaux, en gardant l'application en production.
La réécriture se justifie dans trois cas : la technologie n'est plus maintenue et ne peut plus être mise à jour, le code bloque chaque évolution, ou le produit a tellement changé que l'existant ne correspond plus.
Comment sécuriser sans casser la production ?
En préparant un filet avant de toucher au code : une sauvegarde restaurée, un environnement de test et un moyen de revenir en arrière. Les corrections passent ensuite par petits lots.
- Faire une sauvegarde complète, et tester sa restauration.
- Monter un environnement de test, copie fidèle de la production.
- Appliquer les mises à jour critiques par petits lots, testées une à une.
- Brancher une surveillance des erreurs, pour voir ce que voient tes utilisateurs.
- Écrire un processus de mise en ligne avec retour arrière en une commande.
Combien coûte une reprise d'application ?
L'audit de reprise démarre à 1 500 € HT, pour 3 à 5 jours de travail. La maintenance représente ensuite en général autour de 15 % du coût de développement par an.
Ce qui fait monter la facture : l'absence d'accès au code, l'absence de documentation et de tests, des versions très anciennes, ou des données à remettre en ordre. Les évolutions se chiffrent ensuite au forfait ou au temps passé. Le détail est sur l'offre reprise et maintenance.
Et si tu n'as pas le code source ?
Sans le code, on ne peut pas reprendre l'application telle quelle. On cherche d'abord à le récupérer ; à défaut, on reconstruit à partir de ce qui existe.
Première piste : le demander au prestataire, contrat en main. Pour une application web, le code est parfois récupérable sur le serveur où elle tourne. Si rien n'aboutit, on repart des écrans et surtout de la base de données, qu'on peut presque toujours conserver : c'est alors un nouveau projet, mais pas un retour à zéro.
Sources
- OWASP Top 10:2025, OWASP Foundation
- Node.js : versions et fin de maintenance, Node.js (site officiel)
- Guide de la sécurité des données personnelles, édition 2024, CNIL
Publié le 29 octobre 2026, par Eddy Monnot, tech lead et développeur fullstack freelance.