Le développeur historique est parti, votre CTO se met en retrait, une agence ne répond plus ou la refonte de votre application s’éternise. Pendant ce temps, les utilisateurs continuent d’attendre des corrections et chaque mise en production devient risquée. Faire reprendre le développement d’une application existante est possible, même avec peu de documentation, mais la reprise doit commencer par la sécurisation et la compréhension du produit — pas par l’ajout précipité de nouvelles fonctionnalités.
Ce guide présente une méthode concrète pour reprendre une application web, mobile ou SaaS, remettre son exploitation sous contrôle et retrouver une cadence de livraison prévisible.
Dans quelles situations faut-il organiser une reprise d’application ?
Une reprise ne concerne pas uniquement les projets abandonnés. Elle devient nécessaire dès que l’entreprise ne maîtrise plus suffisamment son produit pour le maintenir et le faire évoluer sereinement. Les situations les plus fréquentes sont :
- le départ du développeur, du CTO ou d’une grande partie de l’équipe technique ;
- une refonte web ou mobile commencée mais jamais terminée ;
- un prestataire qui ne dispose plus des ressources nécessaires ou avec lequel la relation s’est dégradée ;
- une application en production dont les bugs et la dette technique s’accumulent ;
- des déploiements manuels, rares ou dépendants d’une seule personne ;
- plusieurs versions, API ou dépôts de code sans vision d’ensemble ;
- une documentation absente, obsolète ou dispersée entre différents outils.
Le premier objectif n’est pas de promettre une nouvelle date de livraison. Il consiste à rétablir la maîtrise des accès, de la production, du code et des priorités.
Que faut-il faire dans les premières 48 heures ?
1. Sécuriser tous les accès indispensables
L’entreprise doit être propriétaire, ou au minimum administratrice, des services qui font fonctionner son produit. Il faut recenser et tester les accès aux :
- dépôts Git et outils d’intégration continue ;
- serveurs, fournisseurs cloud, conteneurs et registres d’images ;
- bases de données, sauvegardes et outils de supervision ;
- noms de domaine, DNS, certificats et comptes d’envoi d’e-mails ;
- services tiers utilisés par l’application ;
- consoles Apple et Google, certificats de signature et comptes de publication pour une application mobile ;
- outils de gestion de projet, de support et de documentation.
Cette étape permet aussi de supprimer les comptes qui ne doivent plus intervenir, de renouveler les secrets sensibles et d’activer l’authentification multifacteur. Avant toute modification importante, les sauvegardes doivent être localisées et leur restauration vérifiée.
2. Geler les changements risqués sans arrêter le produit
Une reprise en urgence ne doit pas provoquer un second incident. Tant que le nouveau responsable technique ne sait pas comment construire, tester, déployer et restaurer l’application, mieux vaut limiter les évolutions aux corrections indispensables. Cela ne signifie pas arrêter le projet : le support utilisateur, la surveillance et le traitement des incidents critiques continuent.
3. Identifier un responsable de la reprise
Une personne doit pouvoir arbitrer entre urgence commerciale, risque technique et capacité réelle de l’équipe. Il peut s’agir d’un responsable interne, d’un lead developer expérimenté ou d’un CTO externalisé. Sans ce rôle, plusieurs intervenants risquent d’explorer les mêmes sujets sans décider de la trajectoire.
Quels éléments transmettre au nouveau prestataire ?
Il ne faut pas attendre d’avoir une documentation parfaite. Commencez avec ce qui existe : code source, schémas, tickets, maquettes, historique des incidents, contrats, statistiques d’utilisation et liste des personnes connaissant encore le produit.
La transmission doit couvrir quatre dimensions :
- Le métier : utilisateurs, parcours essentiels, obligations réglementaires et opérations qui ne peuvent pas être interrompues.
- Le produit : fonctionnalités en production, refonte en cours, bugs connus, demandes clients et roadmap annoncée.
- La technique : architecture, dépôts, dépendances, données, environnements, tests, déploiements et services externes.
- L’organisation : rôles, prestataires, rituels, processus de validation et canaux de support.
Lorsque l’ancien développeur est encore disponible, quelques sessions enregistrées peuvent faire gagner beaucoup de temps. Demandez-lui de montrer un déploiement complet, le traitement d’un incident, la restauration d’une sauvegarde et les parties du code qu’il juge les plus fragiles. Une démonstration réelle apporte souvent davantage qu’un document rédigé trop rapidement.
Pourquoi réaliser un audit technique avant de relancer les développements ?
Un devis établi uniquement à partir d’une liste de fonctionnalités repose sur une inconnue majeure : l’état de l’existant. L’audit technique réduit cette incertitude et transforme les suppositions en décisions.
Il doit notamment vérifier :
- la possibilité de lancer le projet dans un environnement de développement reproductible ;
- la capacité à construire et déployer chaque application ;
- l’architecture et les dépendances entre le web, le mobile, les API et les traitements asynchrones ;
- l’état des tests, de la sécurité, des sauvegardes et de la supervision ;
- les versions des frameworks et bibliothèques critiques ;
- la qualité et la cohérence des données ;
- le fonctionnement de la CI/CD et la séparation entre développement, préproduction et production ;
- les zones de dette technique susceptibles de bloquer les prochaines évolutions.
L’audit ne doit pas seulement produire une liste de défauts. Son livrable utile est un plan priorisé : risques immédiats, corrections nécessaires, scénarios possibles, ordre de grandeur des charges et dépendances entre les chantiers. Une première étude technique de votre application permet de cadrer cette phase.
Faut-il stabiliser, terminer la refonte ou réécrire l’application ?
La réponse dépend de l’état du produit et non de la préférence technologique du nouveau développeur.
Stabiliser l’existant
Cette option est adaptée lorsque l’application rend encore le service attendu, mais souffre de bugs, de déploiements fragiles ou d’un manque de supervision. On corrige d’abord les risques de production, on automatise les opérations répétitives et on remet les dépendances à niveau progressivement.
Terminer la refonte engagée
Une refonte inachevée n’est pas nécessairement à jeter. Si ses choix restent cohérents et si les principaux parcours fonctionnent, l’achever peut être plus rapide que revenir en arrière. Il faut toutefois comparer précisément le reste à faire avec les contraintes des versions déjà utilisées en production.
Réécrire tout ou partie du produit
La réécriture devient raisonnable lorsque l’architecture empêche réellement les évolutions, que les technologies ne sont plus maintenues ou que le produit a profondément changé. Elle doit être découpée pour éviter un long tunnel sans livraison : migration d’une API, d’un parcours ou d’une application à la fois, avec une stratégie claire pour les données et la coexistence temporaire des versions.
Dans de nombreux projets, la meilleure solution est hybride : sécuriser la production actuelle, terminer les composants déjà avancés et remplacer progressivement les parties qui concentrent le risque.
À quoi ressemble un plan de reprise sur 30 jours ?
Première semaine : reprendre le contrôle
L’équipe sécurise les accès, reproduit les environnements, vérifie les sauvegardes et cartographie l’écosystème. Elle identifie les parcours vitaux et traite uniquement les incidents critiques. À la fin de cette semaine, elle doit pouvoir expliquer comment le produit fonctionne et où se trouvent ses principaux risques.
Deuxième semaine : auditer et choisir une trajectoire
Le code, les données, les déploiements et les dépendances sont évalués. Les demandes métier sont réunies dans un backlog unique. Les décideurs peuvent alors arbitrer entre stabilisation, poursuite de la refonte et remplacement progressif.
Troisième semaine : sécuriser la livraison
L’équipe remet en place les contrôles indispensables : revue de code, tests sur les parcours critiques, environnement de préproduction, automatisation des builds et procédure de retour arrière. Les premières corrections à faible risque permettent de valider toute la chaîne de livraison.
Quatrième semaine : retrouver une cadence durable
Une roadmap courte et réaliste remplace l’accumulation de demandes. Les sujets sont priorisés selon leur valeur et leur risque, puis découpés en livraisons vérifiables. Des rituels simples — planification, point d’avancement, démonstration et rétrospective — donnent de la visibilité sans surcharger l’équipe.
Le résultat attendu au bout de 30 jours n’est pas la résolution magique de toute la dette technique. C’est une production maîtrisée, une équipe capable de livrer et une trajectoire comprise par la direction.
Retour d’expérience : la reprise technique de MyTwiga
Farrago a rencontré cette situation avec MyTwiga, une startup dédiée à l’éducation numérique des familles. Après le départ de plusieurs développeurs, la refonte des applications mobiles, la nouvelle API et l’infrastructure étaient restées inachevées. Les tâches et la connaissance technique étaient dispersées, tandis que les applications devaient continuer à fonctionner.
La reprise a commencé par l’audit et la cartographie de treize dépôts, puis par la remise en ordre des environnements, des déploiements et du backlog. Des cycles courts et des priorités partagées ont permis de terminer les refontes, de remettre les applications en production et d’organiser ensuite leur maintenance, leur DevOps et leurs évolutions.
Cette expérience illustre un point essentiel : reprendre une application ne consiste pas seulement à comprendre son code. Il faut agir en même temps sur le produit, l’infrastructure, les processus et la circulation de l’information. Découvrez la réalisation MyTwiga pour voir le périmètre de cette intervention.
Combien coûte la reprise d’une application ?
Le prix dépend moins du nombre d’écrans que du niveau d’incertitude. Une petite application sans documentation peut être plus difficile à reprendre qu’un produit important disposant de tests, d’environnements reproductibles et d’une équipe disponible pour transmettre ses connaissances.
Les principaux facteurs sont :
- le nombre d’applications, d’API, de dépôts et d’environnements ;
- la disponibilité des accès et de l’ancienne équipe ;
- la criticité de la production et les délais d’intervention attendus ;
- l’état des tests, des déploiements et de la documentation ;
- les migrations de données ou de technologies déjà engagées ;
- le niveau de sécurité et de conformité requis.
Une démarche saine sépare l’audit initial, les travaux de stabilisation et les évolutions produit. Elle évite de faire financer une estimation arbitraire et permet d’ajuster l’équipe une fois les risques connus.
Comment choisir l’équipe qui reprendra le projet ?
Demandez au prestataire comment il aborde les deux premières semaines, quels accès il souhaite vérifier et quels livrables vous permettront de reprendre la maîtrise du projet. Une équipe sérieuse doit savoir travailler sur un code qu’elle n’a pas écrit et expliquer ses arbitrages à des interlocuteurs non techniques.
Vérifiez également :
- son expérience des technologies réellement utilisées ;
- sa capacité à intervenir sur le développement, le mobile et le DevOps ;
- ses pratiques de revue, de test, de documentation et de sécurité ;
- sa façon de prioriser les incidents face aux évolutions ;
- la propriété du code et des comptes à la fin de la mission ;
- les conditions de support, de réversibilité et de continuité.
La reprise peut ensuite déboucher sur une équipe dédiée, un accompagnement de direction technique ou une Tierce Maintenance Applicative. Notre guide pour choisir un prestataire TMA fiable complète ces critères.
Comment éviter qu’une application redevienne dépendante d’une personne ?
La continuité technique se prépare pendant le fonctionnement normal du projet. Les dépôts, comptes cloud et consoles de publication doivent appartenir à l’entreprise. Au moins deux personnes doivent savoir déployer et diagnostiquer le produit. La documentation doit rester courte, proche du code et mise à jour à chaque changement important.
Une chaîne CI/CD reproductible, des sauvegardes testées, une supervision utile et des revues de code réduisent aussi le risque. Enfin, un backlog partagé et des démonstrations régulières empêchent la connaissance produit de rester dans la tête d’un seul développeur.
Faire reprendre votre application sans repartir dans l’urgence
Une application existante peut être reprise même après un départ soudain, une refonte bloquée ou une longue période sans maintenance. La bonne séquence consiste à sécuriser les actifs, comprendre l’existant, choisir une trajectoire sur la base d’un audit, puis restaurer progressivement une capacité de livraison fiable.
Farrago intervient sur l’ensemble de cette chaîne : direction technique, développement web et mobile, API, DevOps et maintenance. Parlons de votre application et de ce qui bloque aujourd’hui.