Un développeur qui disparaît du jour au lendemain. Une agence qui ferme. Un freelance injoignable depuis trois mois. Dans tous ces cas, l'entreprise se retrouve avec le même problème : un site ou une application qui tourne, mais que plus personne ne sait vraiment faire évoluer. La reprise de projet web n'est pas un cas marginal — c'est une situation que nous traitons régulièrement, et qui obéit à des règles précises. Voici comment l'aborder sans perdre ce qui fonctionne, ni s'enfermer dans ce qui ne fonctionne plus.
Une reprise n'est pas un projet neuf
La première erreur, la plus fréquente, consiste à traiter une reprise comme un développement classique. Ce n'est pas le cas. Sur un projet neuf, l'équipe part d'une page blanche : elle choisit son architecture, ses conventions, ses outils. Sur une reprise, elle hérite de décisions prises par quelqu'un d'autre, parfois documentées, souvent non.
Cette différence change tout dans la manière de travailler. Avant d'écrire la moindre ligne de code, il faut comprendre ce qui existe : pourquoi telle fonctionnalité a été codée de telle façon, quelles dépendances sont critiques, quelles parties du système sont fragiles. Sauter cette étape, c'est prendre le risque de casser en silence quelque chose qui fonctionnait.
Les signaux qui doivent alerter une PME ou une startup
Certaines situations doivent déclencher une réflexion sur la reprise avant qu'elles ne deviennent des urgences :
Aucun de ces signaux n'est, seul, une raison de tout jeter. Mais ignorés collectivement, ils transforment un problème gérable en blocage complet.
L'audit : l'étape qu'on ne peut pas sauter
Avant de décider quoi que ce soit, il faut savoir précisément ce qu'on a entre les mains. C'est le rôle d'un audit de site web ou d'application : il établit un état des lieux factuel, pas une impression.
Ce qu'un audit sérieux doit couvrir
Un audit bien mené se termine par une recommandation claire, pas par un rapport de cinquante pages illisible. C'est ce document qui permet ensuite de trancher en connaissance de cause.
Continuer, reprendre ou reconstruire : la vraie décision
À l'issue de l'audit, trois options se dessinent. Aucune n'est meilleure dans l'absolu — chacune correspond à un état du projet différent.
Continuer avec de la maintenance
Si le code est globalement sain, documenté a minima, et que les fondations tiennent la route, une simple prise en main suffit. C'est le scénario le plus économique : on stabilise, on corrige les points faibles identifiés par l'audit, et on repart sur des bases connues via un contrat de maintenance de site web.
Reprendre le projet existant
Si les fondations sont correctes mais que certaines parties sont fragiles ou mal comprises, une reprise de projet web permet de récupérer l'existant, de le documenter proprement, et de le faire évoluer sans repartir de zéro. C'est le scénario le plus fréquent : ni le projet n'est irrécupérable, ni il ne peut continuer sans intervention.
Reconstruire
Si l'audit révèle une architecture obsolète, une dette technique trop lourde, ou un produit qui ne correspond plus du tout au besoin actuel, mieux vaut reconstruire sur des bases saines. C'est un choix plus coûteux à court terme, mais souvent moins cher qu'un rafistolage sans fin.
Le critère qui doit trancher n'est jamais l'ancienneté du code, mais sa capacité à évoluer sans risque. Un code de trois ans bien structuré vaut mieux qu'un code de six mois déjà fragile.
Les pièges d'une reprise mal préparée
Certaines erreurs reviennent systématiquement quand la transition n'a pas été cadrée :
Sécuriser la transition, concrètement
Trois réflexes limitent les risques quand un projet change de mains :
Ces trois étapes ne coûtent rien en développement, mais elles évitent la majorité des mauvaises surprises constatées après coup.
Ce qu'il faut retenir
Une reprise de projet web réussie commence toujours par un diagnostic honnête, jamais par une décision prise à chaud. L'objectif n'est pas de « sauver » ou de « jeter » un projet par principe, mais de choisir l'option qui correspond réellement à son état technique et à vos ambitions pour les mois qui viennent. Un audit rigoureux coûte peu face au risque de reconstruire ce qui aurait pu être conservé — ou de maintenir ce qui aurait dû être refait.
Un exemple concret : Po-Scorad
Po-Scorad est une application médicale native que nous avons reprise après son développement initial par un tiers. Le projet illustre bien la situation : un produit déjà en usage, avec des utilisateurs réels, qu'il fallait comprendre en profondeur avant de pouvoir le faire évoluer sereinement. Ce type de reprise s'inscrit naturellement dans notre activité de développement d'applications mobiles et SaaS, où la continuité de service ne laisse pas de place à l'improvisation.
Découvrez le projet Po-Scorad et la manière dont la reprise a été menée.
Vous avez hérité d'un site ou d'une application dont vous ne maîtrisez plus vraiment le fonctionnement ? Parlons-en — un audit initial suffit souvent à transformer une source d'inquiétude en plan d'action clair.
