Le développeur est parti.
L'application, elle,
tourne toujours.
Personne dans l'entreprise ne sait comment ça marche. Il n'y a pas de documentation, parfois pas d'accès complet, et le produit continue de servir des clients tous les jours. La première décision à prendre n'est pas technique : c'est de savoir exactement où vous en êtes.
Une application que personne ne comprend est un risque, pas un actif.
Le scénario se répète avec une régularité frappante : un freelance ou une agence a construit l'outil, la collaboration s'est arrêtée — départ, désaccord, fin de contrat, parfois cessation d'activité — et il ne reste qu'un produit en production, quelques identifiants transmis à la hâte, et personne pour répondre aux questions.
Tant que tout fonctionne, la situation paraît supportable. Elle cesse de l'être au premier des événements suivants : une panne, une demande de nouvelle fonctionnalité, un client qui exige des garanties de sécurité, ou un investisseur qui pose des questions.
Le réflexe fréquent est d'appeler un développeur pour « reprendre le projet ». Le problème est qu'un développeur découvrant une base de code inconnue donnera presque toujours la même réponse — il faut tout refaire — parce que c'est la voie la plus confortable pour lui, pas nécessairement la plus rationnelle pour vous.
Ce que l'audit de reprise établit
1. L'inventaire réel de ce que vous possédez
- Où le code est-il hébergé, et qui y a encore accès ?
- Quels services tiers sont utilisés, à quel coût, et sur quels comptes sont-ils enregistrés ?
- Le nom de domaine, les certificats et les accès d'administration sont-ils au nom de l'entreprise ?
Cette étape révèle régulièrement qu'un élément critique dépend encore de l'adresse personnelle d'un ancien intervenant. C'est le premier point à refermer, avant même de parler de code.
2. Les risques de sécurité immédiats
- Comptes et clés d'accès toujours actifs pour des personnes qui ne travaillent plus pour vous.
- Secrets présents dans le code ou dans l'historique du dépôt — un mot de passe supprimé dans la version actuelle reste lisible dans l'historique.
- Dépendances non mises à jour comportant des vulnérabilités publiquement connues.
- Données personnelles : ce que l'application collecte réellement, et où elle l'envoie.
3. La capacité à reprendre la main
- Peut-on installer et faire tourner l'application sur un poste neuf ? C'est le test le plus révélateur, et il échoue plus souvent qu'on ne l'imagine.
- Existe-t-il un moyen de déployer une correction sans casser la production ?
- Y a-t-il des sauvegardes, et ont-elles déjà été restaurées pour vérifier qu'elles fonctionnent ?
- Quelle part du produit est réellement compréhensible par un développeur extérieur, et en combien de temps ?
4. La décision : reprendre, corriger ou refaire
C'est la question qui justifie l'audit. La réponse est rarement uniforme : le plus souvent, une partie du produit est saine et peut vivre des années, une autre demande des corrections ciblées, et une portion limitée mérite d'être reconstruite. L'audit donne le découpage et l'ordre, avec pour chaque bloc un ordre de grandeur d'effort.
Le cas des applications construites avec l'IA
Une variante de plus en plus courante : l'application n'a pas été écrite par un prestataire parti, mais par un fondateur non technique avec Lovable, Bolt ou Cursor — et ce fondateur ne sait plus expliquer comment elle fonctionne. La difficulté est comparable, avec une nuance : le code est souvent verbeux et régulier en apparence, ce qui masque des incohérences profondes entre les différentes parties.
Voir l'audit sécurité Lovable et Supabase et l'audit d'application IA.
Une question qui n'est pas technique : à qui appartient le code ?
En droit français, la cession des droits patrimoniaux sur un logiciel doit être expressément prévue par écrit. Avoir payé une prestation n'emporte pas automatiquement la titularité des droits sur le code produit. Beaucoup de contrats de développement restent silencieux sur ce point.
Avisers n'est pas un cabinet d'avocats et ne rend pas d'avis juridique : ce point doit être vérifié par un professionnel du droit. L'audit se contente de le signaler quand les éléments disponibles suggèrent un doute — c'est utile de le savoir avant une levée de fonds ou une cession, moment où la question devient bloquante.
Reprise d'application — questions fréquentes
Mon prestataire est parti sans documentation, par où commencer ?
Par l'inventaire, pas par le code. Avant de lire une ligne, il faut savoir ce qui tourne, où, avec quels accès, et qui détient les clés : hébergement, nom de domaine, base de données, services tiers payants, comptes d'administration. Beaucoup d'entreprises découvrent à ce moment-là qu'un service critique est rattaché à l'adresse e-mail personnelle d'un ancien prestataire.
Peut-on auditer une application sans accès au développeur d'origine ?
Oui, c'est même le cas le plus courant dans ce type de mission. Le code, la configuration et l'historique du dépôt racontent l'essentiel de ce qu'il faut savoir. L'absence d'interlocuteur ralentit la compréhension des choix métier, pas l'évaluation technique.
Faut-il tout réécrire ?
C'est la conclusion la plus fréquemment avancée, et souvent la plus coûteuse. Une réécriture complète reprend des mois et fait perdre au passage toutes les règles métier implicites accumulées dans l'existant. L'audit sert précisément à trancher cette question avec des éléments : ce qui doit être corrigé d'urgence, ce qui peut vivre en l'état, et ce qui mérite éventuellement d'être refait.
Le code m'appartient-il vraiment ?
Cela dépend de ce que prévoit le contrat signé avec le prestataire. En droit français, la cession des droits patrimoniaux sur un logiciel doit être expressément prévue par écrit : sans clause de cession, le fait d'avoir payé la prestation ne suffit pas nécessairement à en détenir les droits. C'est un point à faire vérifier par un avocat, et il devient bloquant en cas de revente de l'entreprise.
Quels sont les risques immédiats à vérifier en priorité ?
Les accès encore ouverts à d'anciens intervenants, les secrets et clés d'API présents dans le code ou dans l'historique du dépôt, les sauvegardes qui n'existent pas ou n'ont jamais été testées, et les dépendances non maintenues comportant des vulnérabilités connues. Ce sont les quatre points qui transforment une situation inconfortable en incident.
Savoir ce que vous avez,
avant de décider quoi en faire.
30 minutes en visio, sans engagement. On regarde la situation et je vous dis franchement si un audit est utile ou si votre problème est ailleurs.
→ Demander un devis