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é, avec la raison 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.
Ce qu’il faut réclamer à un prestataire qui part
Le moment où vous pouvez encore tout obtenir, c’est maintenant. Après, vous dépendez de la bonne volonté de quelqu’un qui n’a plus de raison de vous répondre.
- Le code source complet, avec son historique. Pas une archive du dossier en production : le dépôt Git, avec les commits. C’est l’historique qui raconte pourquoi les choses sont comme elles sont.
- Les accès à l’hébergement et à la base de données, en tant que propriétaire du compte, pas en tant qu’invité sur le sien.
- Le registrar des noms de domaine. C’est le point le plus souvent oublié et celui qui fait le plus de dégâts : un domaine bloqué chez quelqu’un d’autre peut arrêter votre activité du jour au lendemain.
- Les comptes tiers : passerelle de paiement, envoi d’e-mails, cartes, API, stockage. Chacun a un propriétaire, et ce doit être vous.
- La documentation, même partielle et même mauvaise. Un fichier de notes vaut mieux que rien.
- La liste des personnes qui ont encore un accès, sous-traitants compris. Vous ne pouvez pas révoquer ce que vous ne connaissez pas.
Demandez tout cela par écrit, tant que la relation est encore ouverte. Une demande formulée avant la fin du contrat obtient une réponse ; la même demande trois mois plus tard n’en obtient plus.
Ce qui ne se récupère pas
On récupère presque toujours le code. On ne récupère jamais le raisonnement : pourquoi cette table porte ce nom, pourquoi ce contournement existe, ce qui avait été essayé avant. Ces décisions n’ont pas été écrites, et la personne qui les a prises est partie.
C’est exactement ce que reconstitue l’état des lieux, et c’est ce qui prend du temps. Personne ne peut vous le rendre, mais on peut faire en sorte que ça n’arrive plus une deuxième fois, en écrivant cette fois ce qui doit l’être.
Ce que vous recevez à la fin de l’état des lieux
Un document de travail, pas une présentation commerciale. Voici ce qu’il contient, point par point.
- L’inventaire de ce qui existe et de ce qui manque, avec le nom du détenteur pour chaque accès. C’est cette liste qui vous dit si vous êtes réellement propriétaire de votre outil.
- La cartographie du système : ce que fait chaque partie, ce qui est réellement utilisé, ce qui est mort depuis des années et occupe de la place dans toutes les têtes.
- Les risques classés par ce qu’ils peuvent vous coûter, pas par leur difficulté technique. Une faille sur le paiement passe avant une dépendance obsolète qui ne gêne personne.
- Une recommandation tranchée : reprendre, réécrire par morceaux, ou repartir de zéro, avec l’argument qui la porte et ce que chaque option implique en délai et en interruption de service.
- Ce que je ferais en premier si vous me confiez la suite, et pourquoi cet ordre-là plutôt qu’un autre.
Ce document vous appartient, et il est écrit pour être lisible par quelqu’un d’autre que moi. Si vous décidez de confier la reprise à un autre prestataire, il lui fait gagner les mêmes semaines qu’il m’aurait fait gagner. C’est le prix de votre liberté de choisir, et je le paie volontiers.
Ce qui détermine le délai
Je ne donne pas de durée avant d’avoir ouvert le projet, ce serait un chiffre inventé, et vous en avez probablement déjà entendu. En revanche, je peux vous dire exactement ce qui fait varier ce délai.
L’état des accès
Un projet dont vous avez tous les accès démarre en quelques jours. Un projet où il faut retrouver un registrar, relancer un ancien prestataire et reconstituer des comptes tiers peut prendre plusieurs semaines avant la première ligne de code.
La taille du domaine métier
Ce n’est pas le nombre de fichiers qui compte, c’est le nombre de règles métier à comprendre. Une plateforme de cent entités et d’une douzaine de rôles se lit plus lentement qu’un site de trois cents pages.
Ce qui doit continuer de tourner
Reprendre une plateforme à l’arrêt et reprendre une plateforme utilisée tous les jours par des centaines de personnes ne demandent pas les mêmes précautions. La seconde est plus lente, et c’est normal.
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.
Trois croyances qui coûtent cher avant une reprise
Ce sont les trois phrases que j’entends le plus souvent au premier échange. Aucune n’est absurde ; toutes les trois mènent à des décisions coûteuses.
« Il vaut mieux tout refaire »
C’est la réponse commercialement confortable, et elle est rarement la bonne. Refaire, c’est repayer ce qui fonctionnait déjà, réintroduire des bugs qui avaient été corrigés une fois, et laisser vos utilisateurs sur la version défaillante pendant des mois. Ça se justifie parfois. Ça se démontre, jamais ça ne se suppose.
« Le code est mauvais, donc tout est à jeter »
Un code mal écrit n’est pas la même chose qu’un code inutilisable. Ce qui décide, ce n’est pas l’élégance : c’est le coût du prochain changement. Un système laid mais lisible se reprend ; un système élégant dont personne ne comprend les règles métier ne se reprend pas.
« On verra la documentation plus tard »
Plus tard n’arrive jamais, et c’est exactement comme ça que le projet précédent est devenu intouchable. Documenter ce qu’on découvre pendant la reprise ne coûte presque rien sur le moment ; le reconstituer deux ans après coûte une reprise entière.
Le choix de la technologie
Symfony et PHP sont mes environnements principaux : ce sont ceux où je vais le plus vite et le plus sûrement, et c’est pour ça qu’ils reviennent souvent. Ce ne sont pas ma limite.
Le choix se fait au cadrage, en fonction de ce que le projet demande, pas de ce que je préfère. Le risque, avec un développeur qui ne connaît qu’un framework, c’est que tous les problèmes finissent par ressembler à ce framework.
La seule limite
Je ne prends pas un projet dans une technologie que je ne saurais pas relire ligne à ligne. Ce n’est pas une précaution commerciale : c’est ce qui fait la différence entre livrer du code et en répondre.
Reprendre depuis la Belgique
OWL Concept est une société belge, OWL CONCEPT SRL, établie à Boussu en Hainaut, avec un numéro de TVA belge et une adresse que vous pouvez vérifier. Sur une reprise, ce n’est pas un détail de façade : vous confiez à quelqu’un les accès de production de votre outil de travail, parfois les données de vos clients. Savoir à qui vous les confiez, sous quel droit et devant quelle juridiction, fait partie de la décision.
Concrètement, ça veut dire un contrat de droit belge, une facturation en TVA belge pour une société belge, le RGPD appliqué par quelqu’un qui y est soumis comme vous, et la possibilité de se voir si le projet le demande. Une partie de mon activité se fait à distance, y compris hors d’Europe, et une reprise ne demande pas d’être dans la même ville. Mais elle demande de savoir qui répond, et où.
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.
Travaillez-vous uniquement en Symfony ?
Non. Symfony et PHP sont mes environnements principaux, ceux où je vais le plus vite et le plus sûrement, et c’est pour ça qu’ils reviennent souvent. Mais le choix de la technologie se fait au cadrage, en fonction de ce que le projet demande, pas de ce que je préfère. Le risque, avec un développeur qui ne connaît qu’un framework, c’est que tous les problèmes finissent par ressembler à ce framework. La seule règle que je m’impose : je ne prends pas un projet dans une technologie que je ne saurais pas relire ligne à ligne.
Est-ce que vous utilisez l’intelligence artificielle pour développer ?
Oui, comme outil, au même titre qu’un IDE, un debugger ou un profileur, et comme à peu près tous les développeurs aujourd’hui. Ce qui ne change pas : le cadrage, l’architecture et les décisions restent les miennes, et je ne mets pas en production une ligne que je ne peux pas expliquer. Un outil n’a jamais rendu un projet solide. C’est ce qu’on lui demande, et surtout ce qu’on vérifie derrière, qui le fait.
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.