Audit / reprise
Votre développeur ne répond plus : comment reprendre votre application sans repartir de zéro ?
Quand un développeur, un freelance ou une agence disparaît, la première peur est souvent de devoir tout refaire. Pourtant, dans beaucoup de cas, une reprise de l’existant reste possible si l’on commence par récupérer les bons éléments et analyser le projet proprement.
Votre application existe encore. Vos clients, vos salariés ou vos adhérents l’utilisent peut-être tous les jours. Mais le développeur qui l’a créée ne répond plus, l’agence a fermé, le freelance a arrêté son activité, ou la relation avec l’ancien prestataire est terminée.
Dans ce contexte, la question revient presque toujours tout de suite : faut-il tout refaire ? La réponse est souvent non. Avant d’engager une refonte lourde, il faut d’abord comprendre ce qui existe réellement, ce que vous possédez déjà, ce qui peut être récupéré et ce qu’un nouveau prestataire peut reprendre sans repartir à zéro.
Réponse courte
Si votre développeur ne répond plus, le bon réflexe n’est pas de jeter immédiatement l’application. Il faut d’abord sécuriser les accès, cartographier l’existant et faire un audit de reprise avant de décider ce qu’il faut garder, corriger, moderniser ou reconstruire.
Synthèse de l’article
Situation
Une application existe, mais plus personne ne peut la faire évoluer sereinement ou garantir ses accès.
À récupérer
Code source, hébergement, domaine, comptes administrateur, base de données, services externes et documents du projet.
Premier réflexe
Faire analyser l’existant avant d’annoncer une refonte complète ou de changer toute la stack.
Objectif
Reprendre l’application sans tout recommencer quand cela reste techniquement et économiquement défendable.
Demander un premier échange sur votre existant
Ne pas repartir immédiatement de zéro
Une application déjà en place contient souvent beaucoup plus de valeur qu’on ne le croit au premier abord : des comptes utilisateurs, des données, une logique métier, des habitudes d’usage, parfois un back-office, parfois des intégrations externes, parfois même une interface que les équipes maîtrisent déjà.
Refaire sans audit peut coûter deux fois : une première fois en budget, une deuxième fois en perte de repères, en reprise de données, en retards et en risques de régression. Avant de conclure qu’il faut tout reconstruire, il faut donc vérifier si l’existant peut être stabilisé ou repris progressivement.
Vérifier ce que vous possédez réellement
La priorité n’est pas de parler technique en détail, mais d’identifier ce qui vous appartient, ce qui est accessible, et ce qui dépend encore de l’ancien prestataire.
Code source et dépôt
Le code est-il disponible ? Existe-t-il un dépôt Git, une archive, une version exportée ou une documentation minimale sur la structure du projet ?
Hébergement et domaine
Savez-vous où l’application est hébergée, qui gère le nom de domaine, qui reçoit les factures et quels comptes administrateur existent ?
Données et services liés
Base de données, emails, services cloud, API, sauvegardes, stockage de fichiers, comptes Apple ou Google si l’application est mobile : tout cela doit être repéré.
Documents et historique
Contrat, devis, cahier des charges, échanges, factures, accès de support et contacts utiles peuvent faire gagner un temps important lors d’une reprise.
Si vous n’avez pas tout, ce n’est pas forcément bloquant. Mais il faut savoir rapidement ce qui manque vraiment, ce qui peut être récupéré et ce qui devra être remplacé.
Que faire si vous n’avez pas tous les accès ?
C’est une situation fréquente. Il manque parfois l’accès au dépôt de code, à l’hébergement, au compte du nom de domaine, à la base de données ou aux comptes stores. Cela ne signifie pas automatiquement que le projet est perdu.
- vérifier ce qui appartient réellement à votre structure ;
- identifier les comptes transférables ou récupérables ;
- repérer les services que l’application continue d’utiliser ;
- prévoir les éléments qu’il faudra éventuellement remplacer.
Point de vigilance
La propriété du code, des accès ou de certains comptes dépend notamment du contrat et de la situation réelle. Il faut donc éviter les certitudes juridiques trop rapides et commencer par vérifier les pièces disponibles.
Faire un audit avant de modifier l’application
Une reprise sérieuse commence par un diagnostic. C’est précisément le rôle d’un audit de reprise d’application existante : déterminer l’état du projet avant de promettre une refonte, une migration ou une simple maintenance.
État du code et des dépendances
L’objectif n’est pas de faire un procès du code, mais de savoir s’il reste maintenable, stable et compréhensible.
Sécurité, accès et hébergement
Un audit utile vérifie aussi les comptes, les environnements, les sauvegardes, les droits et les dépendances critiques.
Parcours encore utilisés
Il faut distinguer ce qui sert vraiment au quotidien de ce qui existe encore dans l’interface mais n’apporte plus de valeur.
Risques de reprise
L’audit sert enfin à mesurer le risque de régression, le niveau de dette technique et la faisabilité d’une reprise progressive.
Pour aller plus loin sur cette logique, l’article audit et reprise d’application existante détaille la façon de trier ce qu’il faut garder, corriger ou refaire.
Trois scénarios après l’audit
Cas 1 : l’application est saine
Le socle peut être repris. Il faut surtout remettre les accès au clair, corriger quelques blocages et relancer les évolutions.
Cas 2 : certaines parties doivent être modernisées
On conserve l’essentiel, mais certaines briques vieillissantes, trop fragiles ou trop coûteuses à maintenir sont remplacées progressivement.
Cas 3 : une reconstruction est préférable
C’est parfois la bonne décision, mais seulement après analyse : quand l’existant est réellement trop fragile, trop ancien, inaccessible ou trop cher à reprendre proprement.
Le point important est simple : la décision doit venir d’un diagnostic, pas d’une impression ou d’une réponse automatique du type “il faut tout refaire”.
Changer de développeur ne veut pas dire recommencer le projet
Une application peut être transférée vers un autre prestataire si l’existant est compris et les accès suffisamment clarifiés. Le nouveau développeur devra surtout analyser l’état réel du projet avant de travailler dessus.
Un professionnel sérieux n’annonce pas une refonte totale sans avoir examiné le produit, les usages, les données et les points de blocage. C’est encore plus vrai pour une application web, une PWA ou un outil métier déjà utilisé en production.
Les informations utiles à préparer avant de contacter un nouveau développeur
- l’URL de l’application ou du site ;
- le type d’application et les usages principaux ;
- les problèmes actuels et les urgences métier ;
- les fonctions à conserver et celles à faire évoluer ;
- les accès déjà disponibles ;
- le nom de l’hébergeur, du domaine ou du dépôt si vous les connaissez ;
- les coordonnées de l’ancien prestataire si elles existent encore ;
- les documents, devis, factures ou sauvegardes liés au projet.
Peut-on reprendre une application Angular, Ionic, React, Vue ou autre ?
Oui, mais la technologie ne suffit pas à répondre. Ce qui compte surtout, c’est l’état du projet, la disponibilité du code, la qualité des dépendances, l’accès aux services et la clarté de l’architecture générale.
Dans certains cas, une stack moderne reste pourtant difficile à reprendre. Dans d’autres, une application plus ancienne peut être stabilisée efficacement. Le bon arbitrage se fait au cas par cas, comme lorsqu’on compare application web, PWA ou mobile selon les usages réels.
Combien coûte la reprise d’une application existante ?
Il n’existe pas de tarif universel sérieux pour ce type de situation. Le coût dépend de la taille du projet, de son état, du nombre de problèmes, des accès disponibles, des dépendances à reprendre et du niveau de sécurisation ou de modernisation nécessaire.
La meilleure façon d’éviter un devis trop flou reste donc de commencer par un audit ou un premier échange de cadrage. Cela permet de distinguer une simple stabilisation, une reprise partielle et une reconstruction plus large.
Conclusion
Quand un développeur ne répond plus, le pire réflexe est souvent de supposer que tout est perdu. Dans beaucoup de cas, une reprise de l’existant reste possible à condition de commencer par récupérer les accès, sécuriser ce qui peut l’être et faire analyser l’application avant toute décision lourde.
Avant de payer pour refaire entièrement une application, il est souvent préférable de faire analyser ce qui peut être récupéré. C’est la meilleure manière de protéger le budget, de limiter les risques et de remettre le projet en mouvement sur une base plus claire.
Voir l’offre de reprise / audit d’application existante
Aller plus loin
Reprise / audit d’application existante
La page service dédiée pour cadrer un existant bloqué, reprendre les urgences et décider de la suite.
Audit, conseil ou développement ?
Pour savoir si la bonne première étape est un audit technique, un cadrage ou une intervention plus opérationnelle.
Premier échange
Décrivez l’application, les accès disponibles et le blocage actuel pour savoir ce qui peut être repris.
Questions fréquentes
Que faire si votre développeur ne répond plus ?
Commencer par rassembler les accès, identifier l’hébergement et faire auditer l’existant avant toute refonte ou migration.
Peut-on reprendre une application sans le développeur initial ?
Oui, très souvent. Tout dépend surtout de l’état réel du projet et des éléments récupérables autour du code, des données et des services.
Que faire si vous n’avez pas tous les accès ?
Il faut distinguer ce qui peut être récupéré, transféré, remplacé ou reconstruit, sans conclure trop vite que tout est perdu.