Le développeur de votre application est parti : par où commencer ?

Première règle : ne rien modifier tout de suite

Le réflexe est de vouloir « remettre de l'ordre ». C'est la meilleure façon de casser ce qui marche encore, sans pouvoir revenir en arrière. Tant que vous ne savez pas ce qui tourne, où et comment, la seule action utile est de reprendre les accès et de faire l'inventaire.

Étape 1 : les comptes, avant tout

Ce qui vous appartient vraiment, c'est ce qui est à votre nom. Faites la liste, et pour chaque ligne, vérifiez qui en est propriétaire :

• le nom de domaine (chez OVH, Gandi, GoDaddy…) : s'il expire ou s'il est au nom du développeur, c'est la priorité absolue ;
• l'hébergement du site ou de l'application ;
• la base de données et les services associés (Supabase, Firebase…) ;
• le compte de paiement (Stripe…) et l'endroit où arrive l'argent ;
• le dépôt de code (GitHub, GitLab…) ;
• la messagerie d'envoi (e-mails de confirmation) et les outils tiers (analyse, cartes, IA) ;
• le compte de l'outil de génération (Lovable, Bolt…), s'il y en a un.

Pour chaque compte qui n'est pas à votre nom, demandez son transfert, par écrit. Pour chaque compte à votre nom, changez les mots de passe et retirez les accès des personnes qui n'en ont plus besoin. Un ancien prestataire qui garde un accès à la production est un risque, même avec les meilleures intentions.

Vérifiez aussi la double authentification : si elle est liée au téléphone du développeur, faites-la transférer sur un téléphone de l'entreprise et récupérez les codes de secours, sinon vous ne pourrez plus vous connecter. Et changer un mot de passe ne révoque pas les clés et jetons d'accès qu'il a créés (clés d'API, jetons GitHub, clés de déploiement) : faites-en la liste. Révoquez tout de suite ceux qui lui sont personnels ; pour ceux dont l'application se sert, créez d'abord la nouvelle clé et installez-la, puis seulement révoquez l'ancienne.

Étape 2 : le code et ce qui va avec

Récupérez une copie complète du code, avec son historique, dans un dépôt dont vous êtes propriétaire. Demandez aussi ce qui ne se trouve jamais dans le code : les variables d'environnement (les réglages et clés de chaque service), la liste des tâches planifiées, les webhooks déclarés chez les prestataires, et toute documentation, même partielle.

Si le développeur est joignable, une heure d'appel pour qu'il vous montre comment il déploie une mise à jour vaut plus que dix pages de documentation.

Étape 3 : vérifier que l'application se relance

C'est le test le plus parlant : une autre personne peut-elle lancer l'application sur une machine vierge, à partir du code et des informations récupérées ? Si oui, vous avez repris la main. Si non, ce qui manque est exactement ce que vous perdriez le jour où la production tombe : à documenter en priorité.

Étape 4 : comprendre ce qui tourne

Avant de décider quoi que ce soit, il faut savoir :

• où tourne chaque morceau (l'interface, la base, les fonctions serveur, les tâches planifiées) ;
• comment une mise à jour arrive en production, et comment on revient en arrière ;
• ce que ça coûte chaque mois, poste par poste ;
• ce qui est critique : le parcours qui porte votre argent ou les données de vos clients.

Étape 5 : décider, preuves en main

Trois décisions sont possibles, et aucune n'est la bonne par défaut :

• garder et faire évoluer l'existant, après l'avoir stabilisé ;
• reprendre en partie : corriger les fondations, garder le reste ;
• reconstruire, si l'existant coûte plus cher à maintenir qu'à refaire.

Méfiez-vous d'une reconstruction proposée avant que quelqu'un ait lu le code : refaire sans avoir lu, c'est souvent payer deux fois.

Ce que vous pouvez faire seul, et ce qui demande de l'aide

Les étapes 1 et 2 sont à votre portée : ce sont des questions de comptes et de propriété. Les étapes 3 et 4 demandent quelqu'un qui lit le code. C'est exactement le travail de notre diagnostic : la fiche d'identité de l'application (où elle tourne, qui détient quoi, ce qu'elle coûte, qui sait), les risques classés, et le plan pour décider en connaissance de cause.