Le prestataire ne répond plus
L'application tourne encore, mais personne ne peut la modifier. La première urgence est de récupérer les accès et le code avant qu'un incident ne survienne.
Un prestataire parti, un code que plus personne ne comprend, des évolutions à l'arrêt. La première étape n'est jamais de coder : c'est de savoir exactement ce que vous avez entre les mains.
Aucune n'est désespérée. Toutes demandent un état des lieux avant d'engager quoi que ce soit.
L'application tourne encore, mais personne ne peut la modifier. La première urgence est de récupérer les accès et le code avant qu'un incident ne survienne.
Ce qui prenait deux jours en prend dix. C'est le symptôme d'une dette technique : le code a grossi sans être entretenu, et chaque ajout devient risqué.
Il avait tout en tête et rien n'est documenté. Le code existe, mais personne ne sait comment le déployer ni ce qui se passerait en cas de panne.
Dépendances jamais mises à jour, mots de passe stockés en clair, absence de sauvegardes. Tant que rien n'est vérifié, vous ne savez pas ce que vous risquez.
Deux à cinq jours selon la taille du projet. Vous en ressortez avec des faits, pas une impression.
Ce qui est examiné
Chaque constat est illustré par un exemple précis dans votre code.
Ce que vous recevez
Y compris quand la réponse est qu'il vaut mieux repartir de zéro, ou ne rien toucher.
Si votre prestataire est encore joignable, demandez-lui ces quatre choses aujourd'hui. Elles deviennent beaucoup plus difficiles à obtenir ensuite.
Dépôt Git complet, avec son historique
→ Sans lui, rien n'est modifiable
Serveur, base de données, noms de domaine
→ À basculer à votre nom
Paiement, e-mail, cartes, stores
→ Souvent ouverts au nom du prestataire
Export complet de la base de données
→ Votre filet de sécurité
Dans la plupart des cas, oui. Si le contrat prévoyait une cession des droits, le code vous appartient et le prestataire doit vous le remettre. À défaut, on repart de l'application en production et des accès d'hébergement, ce qui permet souvent de récupérer l'essentiel. L'audit commence justement par établir ce que vous détenez réellement.
L'audit représente deux à cinq jours selon la taille du projet, facturés au forfait et annoncés avant de commencer. S'il débouche sur une mission, il est déduit du projet.
Rarement. Une application qui fonctionne en production a de la valeur, même si son code est imparfait. Repartir de zéro coûte presque toujours plus cher que remettre à niveau, et fait perdre des mois. Je ne recommande la refonte que lorsque la remise à niveau dépasserait le coût d'une reconstruction.
L'audit prend une à deux semaines calendaires. La remise à niveau de sécurité suit immédiatement quand c'est urgent. Les évolutions en attente démarrent ensuite, par lots de deux semaines comme tout autre projet.
Je reprends couramment du React, du Node.js, du PHP, du WordPress et des bases PostgreSQL ou MySQL. Si votre application repose sur une technologie que je ne maîtrise pas suffisamment pour m'engager, je vous le dis au premier échange plutôt que d'apprendre à vos frais.
Décrivez la situation en quelques lignes : technologie, ce qui bloque, ce dont vous disposez. Je vous dis dès le premier échange si c'est récupérable.