Votre prestataire est parti : l'application tourne encore, mais plus personne ne peut la rouvrir. Un freelance qui ne répond plus, une société qui a fermé : la scène est banale dans les PME d'Île-de-France, et elle se joue toujours au même moment — le jour où une facture doit sortir ou où l'outil tombe en panne.

Réponse courte : on ne reprend pas une application métier en relisant du code, on la reprend en récupérant quatre choses — les accès, la base de données, le code et un environnement de test. Ce que vous obtenez dans les premiers jours décide du reste. Ce qui ne se récupère jamais, ce sont les règles que personne n'a écrites.

TL;DR

Une application orpheline n'est pas une application en panne : elle fonctionne, et c'est ce qui la rend urgente.
Quatre éléments se réclament par écrit et dans l'ordre : accès, base, code, environnement de test.
Une reprise se compte en jours de travail, pas en mois de développement — de dix à soixante jours selon la plateforme, sur notre grille publiée.
L'irrécupérable n'est pas technique : ce sont les règles maison non écrites et les comptes restés au nom du prestataire.

Votre prestataire ne répond plus : ce qui est perdu, et ce qui ne l'est pas

Un outil métier ne s'arrête pas parce que son auteur s'arrête. Le serveur tourne, la base se remplit, les devis partent. Ce qui disparaît, c'est la capacité de modifier l'outil : personne ne sait plus où vit le code, à qui appartiennent les comptes, ni ce que fait cet écran que plus personne n'ose toucher.

C'est la différence entre un outil en panne et un outil orphelin. Un outil en panne se répare : il y a un numéro à appeler, une garantie, un contrat. Un outil orphelin fonctionne — jusqu'au jour où une obligation change, où un client demande une évolution, où une clé d'API tierce expire.

Ce qui est perdu, ce n'est pas l'application : c'est le contexte. Les données sont dans la base, le code vit sur un serveur ou dans un dépôt, le nom de domaine est au nom de quelqu'un — vérifiez lequel des deux aujourd'hui, c'est une recherche de deux minutes. Reprendre une application que nous n'avons pas écrite consiste précisément à entrer dans un existant, à l'expliquer, puis à le remettre en marche.

Reprise application métier : panneau mural à trois accès dont un éteint, une clé suspendue à une chaîne et un serveur posé au sol — les accès qu'il faut récupérer un par un

Ce qu'il faut réclamer en premier, et dans quel ordre

Le préalable n'est pas technique, il est écrit. Une demande orale adressée à quelqu'un qui ne répond plus ne laisse aucune trace. Le premier acte utile reste un courrier : une mise en demeure adressée en recommandé avec accusé de réception, quelques lignes qui rappellent l'obligation, fixent un délai et demandent des éléments précis. Ce n'est pas une procédure agressive, c'est une preuve datée.

Les accès. Des comptes nominatifs, pas un compte partagé : hébergeur, registrar du nom de domaine, zone DNS, messagerie professionnelle, services tiers raccordés à l'outil — paiement, signature, envoi d'e-mails, facturation. Demandez aussi l'inventaire des mots de passe.

La base de données. Un export complet, structure et données, plus l'emplacement des sauvegardes et la procédure de restauration. C'est le seul élément de la liste que le droit vous garantit : les clauses de sort des données publiées par la CNIL prévoient que le prestataire vous renvoie les données au terme de sa prestation, et détruise les copies restantes.

Le code. Le dépôt avec son historique de versions, et non une archive posée sur un disque. L'historique raconte les corrections et les arbitrages : il fait gagner des semaines à qui reprend l'outil.

Un environnement de test. Une copie isolée de l'application et de sa base, pour manipuler sans toucher à ce qui fait tourner votre activité. Une reprise qui commence en production commence par un incident.

Un mot d'honnêteté : le RGPD n'oblige pas un prestataire à livrer son code, seulement à vous rendre vos données. Ce sont deux discussions différentes, et la seconde se gagne avec le contrat.

Ce qui ne se récupère jamais d'un outil abandonné

Tout ne se rattrape pas. Ce qui se perd en premier, ce sont les règles maison que personne n'avait écrites — la remise tolérée sur ce type de client, la règle de calcul absente du manuel, le dossier qu'on traite toujours en dernier. L'outil applique ces règles, il ne les explique pas.

Se perdent aussi les contournements : ces corrections faites à la main, qui ne figurent nulle part et qui tiennent parfois l'activité à bout de bras. Un repreneur qui ne les connaît pas casse ce qui marchait encore, en croyant nettoyer une anomalie.

Se perdent enfin les comptes restés au nom du prestataire : une licence, une clé prise sous son compte personnel, un service tiers facturé à son entreprise. Ces dépendances se retrouvent en répertoriant ce que l'outil échange avec l'extérieur, et elles se renégocient. Nous avons décrit ce que cela déplace dans un budget : qui détient le code, les comptes et les données à la livraison décide de ce que vous pourrez faire l'année suivante.

Reprise application métier : établi d'atelier avec machine ouverte, cadre vide en pointillés au mur et outils posés sur le plan de travail — la pièce qui manque ne se rachète pas

Combien de temps prend une reprise, et de quoi cela dépend

Une durée de reprise ne se promet pas, elle se mesure sur trois inconnues. La qualité des accès : un dépôt versionné, une base sauvegardée et des comptes au nom du client font gagner plusieurs semaines. La lisibilité du code : un projet écrit par une seule personne pendant deux ans, sans commentaire ni historique, ne se lit pas au même rythme qu'un projet structuré. La propreté de la base : une base documentée se reprend sereinement, une base dupliquée se reconstitue morceau par morceau.

Chez nous, l'unité de mesure est le jour de travail, et elle est publique : notre grille se lit en paliers de dix à soixante jours selon la plateforme. Une reprise se situe dans cette échelle, et son premier jalon n'est jamais une fonctionnalité : c'est la remise en marche de l'existant, avec sa documentation. Tant que l'outil n'est pas stable, ajouter des écrans revient à poser des travaux sur des fondations qu'on n'a pas regardées.

Vient la question que personne ne pose au bon moment : que se passe-t-il si la copie reprise s'effondre pendant la reprise. La réponse tient au premier jour — on ne travaille jamais sur la seule copie qui existe. Sauvegarde complète, environnement isolé, restauration testée avant la première modification. Après la remise en service, le suivi que nous facturons 350 € par mois couvre les mises à jour, les sauvegardes, la surveillance et la remise en route après un incident.

Nous reprenons des applications écrites par d'autres : comment nous procédons

Notre atelier est régulièrement appelé sur des outils qu'il n'a pas écrits, et cela ne nous gêne pas : nous préférons remettre en marche un existant qui rend service que le refuser au motif qu'il n'est pas de nous. Ce que nous refusons, c'est de repartir de zéro quand ce n'est pas nécessaire — c'est plus confortable pour celui qui facture, et plus coûteux pour vous. Une reprise bien menée coûte le prix d'une remise en état, pas celui d'un projet neuf.

Nous commençons par un inventaire plutôt que par du code : ce qui tourne, ce qui dépend de quoi, ce qui communique vers l'extérieur, ce qui est sauvegardé et ce qui ne l'est pas. Cet inventaire produit la première pièce qui manquait — un document qui décrit l'existant. Viennent ensuite la copie vers un environnement isolé, une passe de sécurité, puis les corrections prioritaires, dans l'ordre où elles touchent votre activité et non dans l'ordre où elles amusent celui qui code.

La remise en service s'accompagne de la surveillance et des sauvegardes que nous assurons ensuite. Et quand l'outil repris doit parler à vos autres logiciels, nous raccordons puis documentons chaque échange — une intégration sans documentation reproduit le problème qui vous a amené ici. Sur le reste, nous savons dire non : certains outils méritent mieux qu'une reprise, et les applications que nous avons reprises et remises en service donnent des ordres de grandeur réels de ce qui sort d'un existant conservé.

Reprise application métier : carton ouvert sur une table avec disque dur, liste à cocher et boîtier de sauvegarde, feuille et stylo posés à côté — ce qui vous est remis à la livraison

Le dépôt, la base, la documentation : ce qui vous revient à la livraison

Une reprise se juge sur ce que vous détenez le jour où elle s'arrête, y compris si elle s'arrête parce que vous changez de partenaire. C'est pourquoi nous livrons trois choses, et pas seulement une application qui fonctionne : le dépôt de code avec son historique, un export complet de la base, et la documentation de ce qui a été écrit et repris. Un outil dont vous ne détenez ni le code, ni la base, ni les accès n'est pas un actif : c'est une location dont vous ne connaissez pas le terme. Ce que vous possédez le jour où vous changez de prestataire se décide le jour où vous commencez à travailler avec lui.

L'hébergement mérite le même sérieux : quand l'outil tourne sur une machine à votre nom, personne ne peut éteindre votre activité à distance. Chez un hébergeur français, ce type de serveur se loue à l'heure — 0,1023 € HT de l'heure pour une instance b3-16, soit 73,66 € HT les trente jours (0,1023 € × 24 h × 30 jours). Côté données, la règle est écrite depuis longtemps : l'article 28 du RGPD impose au sous-traitant de vous rendre les données ou de les supprimer au terme de sa prestation. Ce n'est pas une faveur, c'est un levier le jour où le prestataire a disparu.

Vous parlez directement à ceux qui codent, du cadrage au déploiement. Vos données et votre base restent sur votre infrastructure, pas chez un SaaS étranger. Le devis écrit tient le périmètre, et nous restons après la mise en ligne.

Pour chiffrer une reprise, prenez un rendez-vous en visio de 15 minutes et décrivez ce qui tourne, qui l'a écrit, et ce que vous avez en main aujourd'hui — accès, base, dépôt. Si vous préférez l'écrit, écrivez-nous la situation en quelques lignes. Nous vous dirons ce qui est récupérable, ce qui ne l'est pas, et ce que cela coûte.

Questions fréquentes sur une reprise d'application métier

Que faire quand son prestataire ne répond plus ?

Avant de chercher un repreneur, datez la situation : un courrier recommandé qui rappelle l'obligation et fixe un délai. Inventoriez ensuite ce que vous détenez déjà — nom de domaine, hébergeur, accès. Tant que les données restent accessibles, la reprise est réalisable sans l'ancien prestataire.

Peut-on reprendre une application sans le code source ?

Oui, si vous disposez de la base et d'un serveur qui fonctionne. Le code est alors reconstruit à partir du comportement observé de l'outil et de vos règles métier. C'est plus long et moins précis, mais souvent préférable à une reconstruction complète qui efface des années d'ajustements.

Combien de temps prend la reprise d'une application existante ?

Le rythme dépend de ce que vous récupérez. Des accès propres, un dépôt versionné et une base sauvegardée raccourcissent la reprise de plusieurs semaines ; des accès épars et un code non documenté l'allongent. Nous chiffrons en jours de travail, après l'inventaire, jamais avant.

Qu'est-ce qui est irrécupérable dans un outil abandonné ?

Les règles métier jamais écrites, les contournements faits à la main, et certaines dépendances souscrites au nom du prestataire — licences, comptes d'API, services tiers. Le code et les données se récupèrent ; ces trois éléments-là se reconstituent, avec vos équipes qui les connaissent.

À qui appartiennent le code et la base après une reprise ?

Les données vous reviennent dans tous les cas : le RGPD impose leur restitution au terme de la prestation. Pour le code, tout dépend de ce qui est écrit au contrat. C'est pourquoi nous livrons dépôt, base et documentation à chaque projet, sans que cela ait à se négocier.