Reprendre un projet que plus personne ne maîtrise
Reprise de projet web et dette technique — BelgiqueLa reprise de projet web, c’est le travail que je fais : reprendre ce projet-là, comprendre ce qu’il fait vraiment, le stabiliser, et le remettre en mouvement — sans l’arrêter.
Il y a un moment précis où un projet bascule. Ce n’est pas le jour où il tombe en panne — c’est le jour où quelqu’un dit « on ne peut plus y toucher ». Le prestataire d’origine n’est plus joignable, ou il ne répond plus qu’une fois sur trois. Personne ne sait ce que fait exactement le code. Chaque modification casse autre chose. Alors on arrête de demander des évolutions, et l’outil qui devait faire avancer l’entreprise devient une contrainte qu’on contourne.
Les trois situations de reprise de projet web que je traite
Si vous vous reconnaissez dans l’une d’elles, nous parlons du même problème.
Le prestataire n’est plus là
Il a cessé son activité, changé de métier, ou simplement arrêté de répondre. Vous avez peut-être les accès, peut-être pas. Personne n’a jamais documenté quoi que ce soit. La première question n’est pas « comment on améliore » mais « qu’est-ce qu’on a exactement ».
Le projet est vivant mais bloqué
Ça fonctionne, les utilisateurs s’en servent tous les jours, et pourtant plus rien n’avance. Chaque demande d’évolution revient avec un délai et un prix sans rapport avec ce qu’elle représente. C’est la définition de la dette technique : le coût de chaque changement futur, accumulé par les raccourcis passés.
Le projet a été mal cadré
Le code fonctionne, mais il ne fait pas ce dont l’entreprise a besoin. Le problème n’est pas technique, il est dans ce que personne n’a posé au bon moment. C’est la situation la moins bien traitée sur le marché, et souvent la plus coûteuse.
Je commence par un état des lieux, pas par une proposition
Vous avez déjà été déçu par un prestataire. Vous ne voulez pas d’un discours, vous voulez savoir comment ça commence.
- Inventaire de l’existant — code, base de données, hébergement, noms de domaine, comptes tiers, accès. Ce qui manque est identifié et listé.
- Lecture du code — ce que fait réellement l’application, ce qui est utilisé, ce qui est mort, ce qui est dangereux.
- Ce qui tient, ce qui doit être repris, ce qui doit être jeté — et pourquoi, pour chaque point.
- Les risques immédiats — sécurité, dépendances obsolètes, absence de sauvegarde, point de défaillance unique.
- Une recommandation tranchée — reprendre, réécrire partiellement, ou repartir de zéro. Avec l’argument qui la porte.
Cet état des lieux vous appartient. Si vous décidez de confier la suite à quelqu’un d’autre, il est directement exploitable — c’est un document de travail, pas un argumentaire commercial.
Reprendre, réécrire, ou repartir de zéro
La réponse commercialement confortable est toujours « on refait tout ». Elle est rarement la bonne.
Je vous dirai laquelle des trois s’applique, y compris quand la réponse est « votre plateforme actuelle est récupérable, ça coûtera moins cher que ce que vous imaginiez ».
Reprendre
Quand le code est lisible, l’architecture tient, et la dette est localisée. C’est le moins cher et le plus rapide. C’est aussi ce qu’il faut privilégier quand la plateforme est en production et ne peut pas s’arrêter.
Réécrire par morceaux
Quand une partie du système est saine et l’autre non. On isole, on remplace un bloc à la fois, la plateforme continue de tourner. C’est le cas le plus fréquent, et le plus exigeant.
Repartir de zéro
Quand le coût de comprendre l’existant dépasse celui de le refaire, ou quand l’outil ne correspond plus à ce dont l’entreprise a besoin. C’est vrai plus rarement qu’on ne le dit.
Ce que donne une reprise de projet web menée jusqu’au bout
Une fois la plateforme stabilisée, la suite est un partenariat technique au mois : une réserve d’heures garantie, et quelqu’un qui connaît déjà le système.
Étude de cas — plateforme financière Symfony
Une plateforme métier reprise après deux prestataires successifs, en production, utilisée quotidiennement, et qui ne pouvait à aucun moment être arrêtée. Le vrai problème ne s’est pas révélé technique. La mise en production, elle, est devenue un processus au lieu d’un pari. Un an plus tard, la mission continue. C’est le seul indicateur qui compte vraiment pour ce type de projet. Lire l’étude de cas complète →
Comment je travaille
- Tarification à la valeur et à la difficulté, jamais au temps passé. Le prix est fixé à l’avance et ne bouge pas. Ce que ça vous coûte ne dépend pas de mes heures.
- Je pose des questions plutôt que de supposer. Votre temps est précieux, le mien aussi : je préfère une question directe à une semaine de travail dans la mauvaise direction.
- Le contact se fait par e-mail. C’est volontaire : ça laisse une trace, ça permet de répondre de façon construite, et ça respecte le rythme de chacun.
- Après mise en production, je corrige gratuitement les bugs pendant un mois, sur signalement.
- Le code et les accès vous appartiennent. À tout moment.
Ce que je ne prends pas
Le dire à l’avance nous fait gagner du temps à tous les deux.
- Les missions où l’on attend un exécutant qui applique des décisions déjà prises sans pouvoir les discuter.
- Les projets chiffrés à l’heure ou à la journée.
- Les reprises où le client ne peut pas donner accès à l’existant.
Questions fréquentes sur la reprise de projet web
Je n’ai pas les accès au code de mon site. Est-ce bloquant ?
Pas nécessairement. On commence par identifier ce qui existe et qui le détient : hébergeur, registrar, prestataire d’origine. Dans la majorité des cas, tout est récupérable — c’est votre propriété. Si vraiment rien n’est accessible, on le saura vite, et ça oriente la décision.
Combien coûte la reprise d’un projet existant ?
Ça dépend de l’état de l’existant, et c’est justement ce que l’état des lieux détermine. Le prix est ensuite fixé à l’avance, pas facturé au temps passé. L’état des lieux lui-même peut être commandé seul.
Faut-il arrêter la plateforme pendant la reprise ?
Non. Une plateforme en production se reprend sans interruption : on isole, on remplace bloc par bloc, on met en production par étapes contrôlées. C’est exactement ce qui a été fait sur l’étude de cas Symfony.
Travaillez-vous avec d’autres technologies que Symfony et WordPress ?
Ce sont mes deux environnements principaux, en PHP. Pour le reste, la vraie question est celle de l’état des lieux : je vous dirai honnêtement si je suis la bonne personne, plutôt que d’apprendre sur votre budget.
Que se passe-t-il si vous concluez qu’il vaut mieux tout refaire ?
Je vous le dis, avec l’argument chiffré qui va avec. Et l’inverse est vrai aussi : il m’arrive de conclure qu’une plateforme jugée irrécupérable est en fait réparable pour bien moins cher.
Puis-je vous confier seulement l’état des lieux ?
Oui. Il est conçu pour être utilisable par quelqu’un d’autre que moi. C’est un document de travail, pas un argumentaire commercial.
Intervenez-vous pour des entreprises hors de Belgique ?
Oui, à distance. Une partie de mon activité se fait déjà de cette façon.
Un projet que vous n’osez plus toucher ?
Décrivez-moi la situation en quelques lignes. Je vous dis franchement si c’est récupérable, et ce que ça implique.