Le projet devait être livré en quelques mois. Aujourd'hui, le prestataire ne répond plus, le code est difficile à comprendre, la documentation est inexistante et personne en interne ne sait vraiment par où reprendre.

Si vous êtes dans cette situation, retenez d'abord ceci : un projet abandonné n'est pas forcément un projet perdu. Dans bien des cas, une partie du travail déjà réalisé peut être récupérée, à condition de commencer par un audit plutôt que par une décision prise à chaud.

Cet article vous aide à évaluer l'état réel de votre projet, à savoir quoi réclamer à l'ancien prestataire, à trancher entre réparer et reconstruire, et à choisir qui reprendra la main.

Repartir de zéro est rarement la première réponse. C'est le plus souvent la conclusion d'un audit, pas son point de départ.

Projet web abandonné : pourquoi est-il si difficile de le reprendre ?

Reprendre un projet, c'est travailler dans la maison de quelqu'un d'autre sans avoir le plan ni les clés. Les blocages reviennent presque toujours aux mêmes endroits.

👉Un code peu lisible ou non documenté. Sans conventions, commentaires ni fichier d'explication, chaque modification commence par une enquête pour comprendre ce que le code fait réellement
👉Des technologies obsolètes. Un framework dont les versions ne sont plus maintenues, des bibliothèques abandonnées : la moindre mise à jour devient un chantier
👉Une architecture inconnue. On ignore comment les briques communiquent (API, base de données, services tiers), donc on ignore ce qu'une modification peut casser
👉De la dette technique. Raccourcis pris pour tenir un délai, code dupliqué, contournements jamais nettoyés : le projet fonctionne, mais chaque évolution coûte plus cher que la précédente
👉Aucun test automatisé. Sans tests, impossible de vérifier rapidement qu'une correction n'a rien cassé ailleurs.
👉Des dépendances mal maîtrisées. Paquets jamais mis à jour, parfois porteurs de failles de sécurité connues
👉Un hébergement mal documenté. Serveurs configurés à la main, déploiement non reproductible, configurations connues d'une seule personne
👉Des accès détenus par l'ancien prestataire. Dépôt de code, hébergeur, comptes cloud, noms de domaine, comptes développeur des boutiques d'applications : ils sont parfois ouverts au nom du prestataire et non de l'entreprise cliente

Ce dernier point est souvent le plus bloquant, et il se traite avant même de parler de code.

Peut-on réellement reprendre le travail d'un autre prestataire ?

Oui, c'est possible, et c'est une situation courante dans les métiers de l'IT. La vraie question est de savoir à quel coût et avec quel niveau de risque. Plusieurs éléments se vérifient avant toute décision :

👉L'accès au code source. Sans code, il n'y a rien à reprendre : on ne peut que reconstruire à partir de ce qui est visible à l'écran
👉La lisibilité du code. Un code propre mais peu documenté se reprend. Un code sans logique d'ensemble coûte cher à comprendre, parfois autant qu'à réécrire
👉L'état des technologies. Une stack encore supportée se reprend bien plus facilement qu'une stack en fin de vie
👉La qualité des données. Une base de données structurée est un vrai atout. Des tables incohérentes et des doublons demandent un nettoyage préalable
👉Le niveau de sécurité. Failles connues, mots de passe mal protégés, identifiants laissés dans le code : ces points doivent être traités en priorité
👉L'écart avec le besoin. Le projet répond-il encore à ce que l'entreprise attend aujourd'hui ?

Prenons deux situations illustratives. Une application mobile à moitié terminée, avec un dépôt de code ordonné et une API qui répond, se reprend généralement bien. À l'inverse, un site dont le code n'existe plus que sur l'ordinateur d'un développeur injoignable pose un problème d'une tout autre nature : avant de parler de reprise technique, il faut régler la question de l'accès.

Les 7 étapes pour reprendre un projet web ou mobile existant

Voici une méthode que l'on retrouve dans les reprises bien menées. Chaque étape conditionne la suivante.

1. Récupérer tous les accès et éléments du projet

Avant de lire une ligne de code, reprenez le contrôle : dépôt, hébergement, domaine, comptes tiers. Dressez l'inventaire de ce qui existe et de qui en est titulaire. La checklist plus bas détaille ce qu'il faut demander.

2. Faire un audit technique complet

L'audit passe en revue le code, la base de données, l'infrastructure et la sécurité. Il répond à une question simple : qu'est-ce qui est solide, qu'est-ce qui est fragile, qu'est-ce qui est inutilisable ? Un bon audit se termine par un rapport écrit, pas par une impression.

3. Comprendre l'architecture et la stack technique

Langages, frameworks, base de données, services externes, flux de données. Un schéma d'architecture, même simple, évite les mauvaises surprises : on sait où intervenir sans tout déstabiliser.

4. Identifier les fonctionnalités existantes

Listez ce qui fonctionne vraiment, ce qui fonctionne à moitié et ce qui était prévu mais n'existe pas. On compare ensuite avec le cahier des charges initial. Cet inventaire permet aussi de discuter objectivement de ce qui a réellement été livré.

5. Évaluer la dette technique

Toutes les dettes ne se valent pas. Certaines peuvent attendre, d'autres bloquent toute évolution ou exposent l'entreprise à un risque. L'objectif est de les classer, pas de tout corriger d'un coup.

6. Définir un plan de reprise priorisé

À partir de l'audit, on sépare les corrections urgentes (sécurité, bugs bloquants), les fonctionnalités à terminer et les chantiers à planifier plus tard. Le plan précise l'ordre, la charge estimée et les jalons, et il se valide avec vous avant tout démarrage.

7. Sécuriser puis poursuivre le développement

Premier réflexe : sauvegardes, environnements séparés, déploiement reproductible, documentation minimale. Ensuite seulement, on reprend le développement par lots courts et livrables, avec des points réguliers pour garder la visibilité.

Quels éléments faut-il récupérer auprès de l'ancien prestataire ?

Demandez-les par écrit, avec une liste précise. Voici la checklist de base :

👉Le code source et le dépôt Git complet, historique des modifications compris
👉Les bases de données (export complet et schéma)
👉L'hébergement et les accès aux serveurs
👉Les noms de domaine, en vérifiant que l'entreprise en est bien titulaire
👉Les comptes cloud
👉Les clés API et les accès aux services tiers (paiement, envoi d'e-mails, cartographie…)
👉Les certificats SSL
👉Les comptes App Store et Google Play
👉La documentation technique et fonctionnelle
👉Les maquettes UX/UI, avec les fichiers sources
👉Les outils de gestion de projet (backlog, tickets)
👉Les environnements de développement, de test et de production
👉Les accès aux outils d'analyse de trafic
👉Les variables d'environnement et les fichiers de configuration

Relisez aussi le contrat initial : il précise souvent qui détient les droits sur le code et dans quelles conditions il vous est transmis. Pour les comptes qui ne sont pas à votre nom, demandez un transfert de propriété plutôt qu'un simple partage d'identifiants.

Faut-il réparer le projet ou repartir de zéro ?

Il n'existe pas de réponse universelle. Celui qui vous recommande systématiquement de tout refaire, ou l'inverse, n'a probablement pas examiné votre code.

Quand la reprise est préférable

Le code est lisible, la technologie est encore maintenue, l'architecture est cohérente et les défauts sont localisés. Le travail restant consiste surtout à terminer des fonctionnalités et à corriger. Reprendre est alors le choix le plus rapide et le plus économique.

Quand une refonte partielle est préférable

Certaines parties sont saines, d'autres non : par exemple un back-end solide avec une interface vieillissante, ou un module central mal conçu au milieu d'un ensemble correct. On conserve ce qui a de la valeur et on remplace le reste progressivement.

Quand une reconstruction complète peut être plus rentable

Technologie en fin de vie, architecture incapable de supporter la croissance, failles structurelles, code incompréhensible : quand le coût des correctifs s'approche de celui d'un nouveau développement, reconstruire peut devenir plus rationnel. Même alors, les maquettes, les règles métier et les données restent des acquis précieux. On ne repart presque jamais vraiment de zéro.

C'est l'audit qui permet de trancher, avec des éléments concrets plutôt qu'une intuition.

Combien coûte la reprise d'un projet web ou mobile ?

Aucun tarif sérieux ne peut être annoncé sans avoir vu le projet. Le coût dépend avant tout de ce que l'on découvre dans l'existant. Les principaux facteurs sont :

👉La taille du projet et le nombre de fonctionnalités
👉La qualité du code et l'ampleur de la dette technique
👉La présence ou l'absence de documentation
👉La technologie utilisée et sa disponibilité en compétences
👉L'état de la base de données
👉L'infrastructure et le mode de déploiement
👉Le niveau de sécurité
👉L'urgence
👉Le besoin de refonte, partielle ou totale

Pour cadrer un budget, l'étape la plus efficace reste l'audit. Son périmètre est limité, il transforme une inconnue en estimation argumentée, et son rapport peut être remis à n'importe quel prestataire. Méfiez-vous d'un devis ferme de reprise annoncé sans accès préalable au code.

Comment choisir un nouveau prestataire pour reprendre son projet ?

Reprendre un projet est un exercice différent de la création à partir d'une page blanche. Voici les points à comparer entre prestataires :

👉Expertise technique. Maîtrise de votre stack, ou capacité démontrée à la comprendre vite
👉Pratique de l'existant. Savoir lire, corriger et faire évoluer le travail d'autrui sans tout casser
👉Méthodologie d'audit. Quels livrables, quel format de rapport, quels critères d'évaluation
👉Transparence. Dit-il clairement ce qui est fragile dans le code, même si le constat est inconfortable ?
👉Documentation. S'engage-t-il à documenter pour que vous ne dépendiez plus d'une seule personne ?
👉Sécurité. Gestion des accès, des secrets, des sauvegardes, des mises à jour
👉Communication. Interlocuteur identifié, points réguliers, comptes rendus écrits
👉Expérience en reprise de projets. Retours d'expérience concrets, pas seulement des références de créations neuves
👉Plan de continuité. Que se passe-t-il si un développeur quitte le projet ?

Un bon signe : le prestataire qui propose de commencer par un audit plutôt que de vous faire signer tout de suite un engagement lourd.

Pourquoi faire appel à ValanoTech pour reprendre un projet existant ?

ValanoTech est une ESN basée à Antananarivo, à Madagascar, qui accompagne des PME, des startups et des entreprises européennes dans leurs projets IT et data. Une reprise de projet mobilise justement plusieurs des compétences que l'entreprise met en avant :

ValanoTech est une ESN basée à Antananarivo, à Madagascar, qui accompagne des PME, des startups et des entreprises européennes dans leurs projets IT et data. Une reprise de projet mobilise justement plusieurs des compétences que l'entreprise met en avant :

👉Développement web et mobile sur mesure. Sites, plateformes, applications natives et multiplateformes, PWA
👉Front-end et back-end. Pour comprendre une interface comme une architecture serveur
👉Bases de données et API. Pour auditer l'état des données et les échanges entre les briques du projet
👉DevOps, cloud et CI/CD. Pour sécuriser l'hébergement et rendre les déploiements reproductibles
👉Un travail d'équipe. Des profils expérimentés qui se complètent, plutôt qu'un développeur isolé
👉Des modèles d'engagement adaptés. Forfait ou régie, selon que le périmètre est clair (un audit, par exemple) ou évolutif (une reprise progressive)

Cela ne signifie pas que chaque projet est récupérable : certains ne le sont pas. C'est précisément pour cela que la première étape consiste à analyser l'existant avant de s'engager sur une trajectoire.

FAQ : reprise de projet web ou mobile

Peut-on reprendre le code d'un autre développeur ?

Oui, à condition d'avoir accès au code source et de disposer des droits pour l'utiliser. La difficulté dépend de la lisibilité du code, de sa documentation et de l'âge des technologies employées. Un audit permet de le mesurer avant de s'engager.

Combien coûte la reprise d'un site web existant ?

Cela dépend de la taille du site, de la qualité du code, de la dette technique et de l'état de l'hébergement. Sans examen de l'existant, toute somme annoncée est approximative. Un audit préalable permet d'obtenir une estimation argumentée.

Peut-on changer de prestataire en cours de projet ?

Oui. Vérifiez d'abord le contrat : préavis, livrables intermédiaires, paiement des travaux réalisés, transmission du code. Mieux vaut organiser la transition par écrit, avec un inventaire des éléments à remettre.

Comment récupérer son code source auprès d'une agence web ?

Commencez par une demande écrite qui s'appuie sur le contrat et sur la cession des droits prévue. Si l'agence tarde, un courrier recommandé puis un avis juridique sont les étapes suivantes. Gardez les preuves de vos paiements et de vos échanges.

Faut-il refaire un site lorsque le projet est abandonné ?

Pas nécessairement. Si le code est exploitable et la technologie encore maintenue, la reprise est souvent plus rapide. La reconstruction ne devient pertinente que lorsque l'audit montre que corriger coûterait autant que refaire.

Combien de temps faut-il pour auditer un projet existant ?

De quelques jours pour un site simple à plusieurs semaines pour une plateforme complexe. La durée dépend de la taille du code, de la documentation disponible et de la rapidité avec laquelle les accès sont obtenus.

Que faire si l'ancien prestataire ne transmet pas les accès ?

Identifiez d'abord ce que vous contrôlez déjà : nom de domaine chez le registrar, factures d'hébergement, comptes à votre nom. Appuyez-vous ensuite sur le contrat, envoyez une demande formelle et sollicitez un avis juridique si le blocage persiste. Les hébergeurs et les boutiques d'applications ont généralement des procédures pour justifier la titularité d'un compte.

Comment éviter une nouvelle dépendance à un prestataire ?

Exigez que le dépôt de code, l'hébergement, les domaines et les comptes soient à votre nom. Demandez une documentation à jour et des environnements reproductibles, et prévoyez dans le contrat une clause de réversibilité qui organise la transmission en fin de mission.

Votre projet est bloqué par votre prestataire actuel ?

ValanoTech peut commencer par analyser l'existant afin d'évaluer les possibilités de reprise : état du code, risques, options réalistes. Décrivez-nous brièvement votre situation, nous reviendrons vers vous pour échanger sur la suite.