L'essentiel
Reprendre un projet laissé par une agence qui a disparu prend 3 à 6 semaines. Voici notre méthode en 5 étapes, basée sur 40+ reprises de projet réalisées : audit d'urgence, rapport de reprise, sécurisation, stabilisation, évolution.
Les projets abandonnés présentent tous les mêmes problèmes : secrets dans le code, dépendances non mises à jour depuis 2 à 5 ans, zéro tests automatisés, configuration hardcodée, absence de CI/CD.
L'audit d'urgence (étape 1) prend 5 jours et coûte à partir de 2 125 € HT chez Nehos. Il produit un rapport complet avec le score de dette technique, les risques immédiats et la roadmap de stabilisation.
La sécurisation immédiate est non négociable : rotation de tous les credentials (clés API, mots de passe, tokens), audit des accès, backup complet avant toute intervention.
Le coût total d'une reprise de projet chez Nehos : audit à partir de 2 125 € HT + stabilisation entre 3 000 et à partir de 32 000 € HT selon l'état. Souvent moins cher qu'une semaine de production dégradée.
Reprendre un projet laissé par une agence disparue : la méthode en 5 étapes
3 à 6 semaines suffisent pour reprendre la maîtrise d'un projet abandonné. Méthode basée sur 40+ reprises réalisées par les équipes Nehos.
Adapté à toute taille de structure
Reprendre un projet laissé par une agence qui a disparu prend 3 à 6 semaines. Voici notre méthode en 5 étapes, basée sur 40+ reprises de projet réalisées par les équipes Nehos depuis 2018.
#Les 4 profils de « projets abandonnés »
Tous les projets abandonnés ne se ressemblent pas. En pratique, on rencontre 4 situations distinctes :
#1. L'agence liquidée ou en redressement judiciaire
Situation la plus délicate : l'agence n'existe plus légalement. Ses dirigeants sont injoignables, les locaux fermés. Le risque principal est la perte des accès (serveurs hébergés chez l'agence, domaines enregistrés à leur nom). La procédure de liquidation judiciaire permet en théorie de récupérer les actifs numériques — mais c'est long (plusieurs mois). La solution pragmatique : travailler à partir de s accès que vous avez (accès Git direct, accès hébergeur si vous en avez un), et recréer les accès manquants via les procédures de récupération standard (hébergeur, registrar).
#2. L'agence qui refuse de continuer
Relation commerciale rompue, litige en cours, ou simplement l'agence qui « dépriorise » votre projet. Le code existe et est accessible, mais l'agence ne fait plus d'interventions. C'est la situation la plus confortable pour une reprise, car vous avez généralement accès à tout — la difficulté est de comprendre ce que l'agence sortante a construit sans son aide.
#3. Le freelance disparu
Très fréquent. Le développeur freelance qui avait tout en tête est injoignable : accident, arrêt de son activité, départ à l'étranger. Le code est là, mais la connaissance métier est entièrement dans sa tête. C'est souvent la situation avec le moins de documentation et le plus de dépendances implicites.
#4. L'équipe interne qui a quitté
Tout le pôle technique interne part en 6 mois (débauchage massif, restructuration, conflit). Le code est propriétaire, bien documenté parfois, mais personne ne reste pour le maintenir. Ce profil est souvent le plus « propre » techniquement, mais nécessite un transfert de connaissance métier approfondi.
#Étape 1 — Audit d'urgence (1 semaine)
Avant toute intervention, on inspecte systématiquement :
| Ce qu'on inspecte | Ce qu'on cherche |
|---|---|
| Historique Git | Dernière activité, nombre de contributeurs, patterns de commits |
| Inventaire des dépendances | Versions, dates de dernière mise à jour, CVE connues |
| Credentials dans le code | grep sur secrets, tokens, mots de passe hardcodés |
| Architecture applicative | Monolithe, microservices, couplage, points d'entrée |
| Couverture de tests | Quels tests existent, sont-ils en état de fonctionner ? |
| Infrastructure | Hébergement, DNS, certificats, expiration des services |
| Documentation existante | README, wiki, commentaires de code |
En 1 semaine (5 jours-homme), cet audit produit une photographie complète de l'état du projet. Nous avons repris des projets sans une ligne de documentation — l'audit est faisable à partir du seul code source.
#Étape 2 — Rapport de reprise (2-3 jours)
Le rapport de reprise Nehos contient systématiquement :
Score de dette technique (sur 100) : nous évaluons 4 dimensions :
- Sécurité (vulnérabilités CVE, gestion des secrets, authentification)
- Obsolescence (versions des dépendances, framework, runtime)
- Testabilité (couverture de tests, CI/CD, environnements)
- Documentation (architecture, API, déploiement)
En moyenne, les projets abandonnés arrivent avec un score de 25 à 45/100. Un score en dessous de 30 indique des risques immédiats à traiter avant toute évolution fonctionnelle.
Risques immédiats identifiés : par ordre de priorité, avec l'impact potentiel de chaque risque (exemple : « CVE-2024-XXXX sur la version d'OpenSSL utilisée — risque d'exécution de code distant »).
Roadmap de stabilisation : les 5 à 10 actions prioritaires, estimées en jours-homme, avec l'impact attendu sur le score de dette technique.
Estimation du contrat TMA : sur la base de l'état constaté, nous proposons un périmètre et un tarif pour la TMA post-stabilisation.
#Étape 3 — Sécurisation immédiate
C'est la priorité absolue avant toute autre intervention. Elle comprend :
Rotation complète des credentials :
- Changer tous les mots de passe de base de données
- Révoquer et régénérer toutes les clés API (Stripe, SendGrid, AWS, etc.)
- Changer les clés SSH des serveurs
- Régénérer les tokens d'authentification des services tiers
- Mettre à jour les variables d'environnement de production
Pourquoi c'est urgent : l'agence sortante (ou ses anciens employés) conserve potentiellement des copies des credentials. Un incident de sécurité sur une application « abandonnée » est souvent lié à des accès non révoqués.
Audit des accès : qui a accès à quoi ? On dresse la liste de tous les accès (utilisateurs Git, accès serveurs, comptes d'hébergeur) et on supprime les accès des personnes qui ne sont plus impliquées dans le projet.
Backup complet : avant la moindre intervention sur le code, on prend un snapshot complet (code + données + configuration). Si quoi que ce soit se passe mal pendant la stabilisation, on peut revenir à cet état en moins d'une heure.
#Étape 4 — Stabilisation (2 à 4 semaines)
Une fois le projet sécurisé, la stabilisation consiste à :
- Résoudre les bugs bloquants identifiés lors de l'audit — ceux qui empêchent l'utilisation normale de l'application ou représentent un risque de perte de données
- Mettre à jour les dépendances critiques (celles avec des CVE actives ou dont le support est terminé)
- Documenter l'existant : architecture, flux métier principaux, procédures de déploiement — ce que nous apprenons en intervenant, nous l'écrivons
- Mettre en place un pipeline CI/CD minimal : au minimum, tests automatiques avant chaque déploiement et procédure de rollback documentée
- Mettre en place le monitoring : alertes sur les erreurs critiques, tableau de bord de disponibilité
Après la phase de stabilisation, l'application est dans un état « maintenable » — c'est le pré-requis pour passer sous TMA ou démarrer des évolutions fonctionnelles.
#Étape 5 — Évolution : reprendre la maîtrise du produit
C'est l'étape la plus agréable, celle qu'on atteint quand les étapes précédentes sont faites sérieusement. La base de code est documentée, les tests sont en place, le monitoring fonctionne. On peut maintenant parler roadmap avec le client.
Cette phase commence par un atelier product avec les équipes métier : qu'est-ce qui était prévu ? Qu'est-ce qui est prioritaire ? Quels sont les bugs fonctionnels que les utilisateurs ont appris à contourner ? On reconstruit une backlog propre, estimée et priorisée.
Pour les projets avec une dette technique importante, nous proposons souvent une approche strangler fig : construire les nouvelles fonctionnalités dans une architecture moderne, tout en maintenant l'ancien code en l'état jusqu'à ce que toutes les fonctionnalités aient été migrées. Cette approche est détaillée dans notre service de modernisation applicative.
#Ce que ça coûte chez Nehos
| Prestation | Tarif HT |
|---|---|
| Audit de reprise initial (5 jours, rapport complet) | à partir de 2 125 € (forfait fixe) |
| Stabilisation légère (score dette ≥ 50/100) | 2 15 872 € |
| Stabilisation standard (score dette 30–50/100) | à partir de 873 € |
| Stabilisation lourde (score dette < 30/100) | Sur devis (généralement 10–20 jours) |
| TMA post-stabilisation | à partir de 1 113 €/mois selon périmètre |
L'audit de reprise à partir de 2 125 € est réalisable sans engagement sur la suite. Si notre analyse révèle que votre situation ne correspond pas à notre expertise, nous vous le disons — et nous vous orientons vers les bons profils.
Pour comparer ces tarifs avec le coût de ne rien faire (production dégradée, incidents récurrents, temps interne mobilisé), notre outil de diagnostic propose un calculateur de coût d'inaction.
Pour en savoir plus sur nos tarifs ou démarrer directement, prenez rendez-vous avec notre équipe.