Un projet logiciel repris trop vite coûte souvent plus cher qu’un projet retardé de deux semaines. C’est le point que beaucoup de dirigeants découvrent après un départ de prestataire, une équipe qui se délite ou un produit qui continue à tourner sans personne pour vraiment le comprendre. Savoir comment reprendre un projet informatique n’est pas une question de bonne volonté. C’est une question de méthode, de responsabilité et de lecture honnête de l’existant.
Le réflexe le plus dangereux consiste à vouloir relancer la machine immédiatement. Ajouter un développeur, rouvrir le backlog, remettre de la pression sur les livraisons. Sur le papier, cela donne l’impression d’agir. En production, cela crée surtout plus d’incertitude. Quand personne ne maîtrise clairement le code, l’infrastructure, les dépendances et les flux métier, chaque nouvelle modification augmente le risque.
Comment reprendre un projet informatique sans casser l’existant
La première règle est simple: je lis votre code avant d’en écrire. Tant qu’on ne sait pas ce qui tourne réellement, ce qui est documenté, ce qui dépend d’un service tiers, et ce qui repose sur des habitudes implicites de l’ancienne équipe, il est prématuré de promettre un planning ou une roadmap fiable.
Reprendre un projet sérieux commence donc par une phase de diagnostic. Pas un audit cosmétique destiné à remplir un PDF, mais une lecture active de l’existant. Cela inclut le dépôt de code, l’historique des commits, les environnements, la chaîne de déploiement, les accès, les sauvegardes, la supervision, les erreurs applicatives, les jobs planifiés, la qualité des données et les points de friction côté métier.
Ce diagnostic répond à des questions très concrètes. Le produit est-il déployable sans la personne partie ? Les secrets et accès sont-ils maîtrisés ? Peut-on reproduire un environnement ? Existe-t-il des tests utiles, ou seulement une illusion de couverture ? Le backlog reflète-t-il les vrais problèmes, ou seulement les demandes visibles des utilisateurs ?
Dans beaucoup de TPE et PME, le problème n’est pas un mauvais choix technologique. Le vrai sujet est plus banal et plus sérieux: personne n’a gardé une vue complète du système. Le projet continue, mais il devient progressivement opaque. C’est exactement le moment où une reprise doit être menée avec discipline.
Ce qu’il faut vérifier avant de promettre une relance
Un projet peut sembler récupérable et pourtant être bloqué par des détails très prosaïques. Un certificat expiré, un accès cloud détenu par un ancien prestataire, un serveur sans sauvegarde vérifiée, une librairie critique non maintenue, un pipeline CI cassé depuis des mois. Ces sujets paraissent secondaires jusqu’au jour où ils immobilisent l’activité.
Avant toute reprise, il faut donc remettre à plat quatre couches.
D’abord, la couche métier. À quoi sert vraiment l’application ? Quels processus supporte-t-elle ? Quelles fonctions génèrent du revenu, évitent des erreurs opérationnelles ou permettent de servir les clients ? Sans cette lecture métier, on risque de consacrer du temps à des irritants visibles mais non critiques.
Ensuite, la couche applicative. Il faut comprendre la structure du code, les modules réellement utilisés, la qualité de séparation des responsabilités, les zones fragiles, les contournements historiques, et le niveau de dépendance à une ou deux personnes clés. Un codebase n’a pas besoin d’être élégant pour être repris. Il doit surtout être compréhensible et modifiable sans roulette russe à chaque déploiement.
Puis vient la couche infrastructure. Où le système tourne-t-il ? Comment se fait le déploiement ? Quelles sont les machines, conteneurs, services managés, bases de données, queues, stockages et DNS impliqués ? Qui surveille quoi ? Que se passe-t-il la nuit, le week-end, en cas de surcharge ou d’échec d’un traitement ?
Enfin, la couche gouvernance. Qui décide ? Qui valide ? Qui possède les accès ? Qui tranche entre correction urgente et évolution produit ? Beaucoup de projets bloqués ne sont pas d’abord des problèmes techniques. Ce sont des projets sans arbitrage propre.
Reprendre un projet informatique: stabiliser avant d’accélérer
Une reprise saine commence rarement par de nouvelles fonctionnalités. Elle commence par la stabilisation. C’est frustrant pour une équipe ou un dirigeant qui attend de la vitesse, mais c’est le seul chemin sérieux si le socle est fragile.
Stabiliser veut dire remettre sous contrôle ce qui menace l’exploitation. Corriger les incidents récurrents, restaurer un déploiement fiable, sécuriser les accès, vérifier les sauvegardes, documenter l’architecture réelle, assainir l’observabilité minimale, et réduire les zones où une seule erreur peut casser la production.
Cette phase a un intérêt business immédiat. Elle réduit les interruptions, évite les régressions coûteuses et permet enfin de distinguer l’urgent du bruyant. Un dirigeant a surtout besoin de savoir ceci: qu’est-ce qui met réellement le système en danger, qu’est-ce qui peut attendre, et quel budget de remise à niveau est raisonnable.
Il faut accepter un point moins confortable. Stabiliser ne signifie pas tout refaire. Le réflexe du rewrite complet est séduisant parce qu’il donne l’impression d’un nouveau départ propre. Dans la majorité des cas, c’est une erreur de gestion. Réécrire sans comprendre l’ancien système revient à perdre le peu de connaissance opérationnelle encore présente. Et pendant qu’on réécrit, l’ancien système continue de vivre, de facturer, de tomber parfois, et d’exiger de l’attention.
Le bon choix dépend du contexte. Parfois, une refonte partielle est nécessaire. Parfois, il faut isoler un composant critique, migrer une dépendance, ou simplifier un flux de données avant toute ambition produit. Mais une décision de refonte sérieuse se prend après lecture et mesure, pas par fatigue psychologique face à un code qui déplaît.
Ce qu’un plan de reprise doit produire
Une reprise utile ne se limite pas à dire que le projet est en mauvais état. Elle doit produire des décisions exploitables.
Le premier livrable attendu est une cartographie honnête. Pas une architecture idéale, mais l’architecture réelle. Ce qui tourne, ce qui dépend de quoi, ce qui est critique, ce qui est obsolète, et ce qui reste inconnu. Tant que cette base n’existe pas, tout échange sur les délais reste fragile.
Le deuxième livrable est une hiérarchisation des risques. Tous les problèmes ne se valent pas. Un style de code hétérogène est rarement prioritaire si les sauvegardes n’ont jamais été testées. Une dette technique visible peut attendre si le processus de déploiement permet à n’importe quelle manipulation de casser la production.
Le troisième livrable est un plan de reprise réaliste, en séquences courtes. D’abord sécuriser, ensuite stabiliser, puis rendre le système maintenable, et seulement après accélérer les évolutions. Cette logique paraît ennuyeuse. Pragmatique et ennuyeux - comme ça doit l’être.
Le quatrième livrable est un cadre de décision. Qui intervient ? Avec quelles validations ? Quel niveau d’autonomie donne-t-on au consultant ou à l’équipe de reprise ? Quels sujets nécessitent un arbitrage dirigeant ? Sans ce cadre, les projets repartent souvent dans le même brouillard qu’avant.
Les erreurs classiques au moment de la reprise
La plus fréquente consiste à sous-estimer la phase de compréhension. On veut un chiffrage immédiat, un délai ferme, et un engagement sur les fonctionnalités futures alors même que personne n’a encore vérifié la capacité à déployer proprement. C’est la meilleure façon de fabriquer une déception rapide.
La deuxième erreur est de confondre documentation et maîtrise. Un dossier peut exister sans être fiable. À l’inverse, un système peu documenté peut être reprenable si sa structure reste lisible et si les environnements sont propres. Il faut donc vérifier, pas croire.
La troisième erreur est de traiter la production comme un détail. Beaucoup de prestataires savent développer. Moins savent reprendre un système vivant sans perturber l’exploitation. Or la vraie difficulté est là: intervenir sur un existant qui sert déjà des clients, des équipes internes ou des flux métier quotidiens.
La quatrième erreur est politique. Si l’entreprise cherche seulement un responsable à blâmer pour l’état du projet, la reprise part mal. Ce qu’il faut, c’est un état des lieux clair et une capacité à décider. Pas un procès.
Quand faire appel à un senior externe
Certaines reprises peuvent être absorbées en interne. Si l’équipe restante connaît le produit, maîtrise l’infra et dispose de temps protégé, elle peut remettre le projet sous contrôle. Mais ce cas est moins fréquent qu’on ne le croit dans les petites structures.
Faire intervenir un senior externe devient pertinent quand il faut lire vite, diagnostiquer sans politique interne, prioriser avec sang-froid et intervenir directement sur la production. C’est particulièrement vrai lorsqu’il n’y a pas de CTO, quand plusieurs prestataires se sont succédé, ou quand l’entreprise a besoin d’un avis capable de distinguer ce qui est réparable de ce qui doit être remplacé.
C’est aussi une question de niveau de responsabilité. Une reprise sérieuse ne consiste pas à empiler des tickets dans un outil de gestion. Elle consiste à prendre en main un système réel, avec ses dépendances, ses contraintes et ses zones d’ombre, puis à remettre de la lisibilité là où il n’y en a plus. C’est précisément le type d’intervention que Rocket Services traite pour des entreprises qui ont besoin de résultats avant d’avoir besoin de storytelling.
Reprendre un projet informatique, ce n’est pas relancer un sprint. C’est rétablir de la maîtrise sur un actif opérationnel. Quand cette maîtrise revient, le produit recommence à avancer pour de bonnes raisons, pas par inertie ni sous pression.
Questions fréquentes
- Pourquoi ne pas ajouter un développeur immédiatement quand on reprend un projet ?
- Ajouter un développeur sans d'abord comprendre le code, l'infrastructure et les dépendances augmente surtout le risque. Chaque modification devient une roulette russe si personne ne maîtrise clairement le système. Il faut d'abord lire et diagnostiquer.
- Qu'est-ce qu'on doit vérifier avant de promettre un planning de reprise ?
- Il faut vérifier quatre couches : la couche métier (à quoi sert vraiment l'app), la couche applicative (structure du code, zones fragiles), la couche infrastructure (où ça tourne, comment ça se déploie), et la couche gouvernance (qui décide, qui valide). Sans cette lecture, tout délai reste fragile.
- Faut-il réécrire complètement un projet en mauvais état ?
- Non, le réflexe du rewrite complet est une erreur dans la majorité des cas. Réécrire sans comprendre l'ancien système fait perdre la connaissance opérationnelle restante, et pendant ce temps l'ancien système continue de vivre et d'exiger de l'attention. Une refonte sérieuse se décide après diagnostic, pas par fatigue face au code.
- Quel est le premier objectif d'une reprise : nouvelles fonctionnalités ou stabilisation ?
- La stabilisation doit venir en premier. Il faut remettre sous contrôle ce qui menace l'exploitation : incidents récurrents, déploiement fragile, accès non sécurisés, sauvegardes non testées. Ce n'est que après cette phase qu'on peut accélérer les évolutions.
- Quand est-ce qu'un senior externe est vraiment utile pour reprendre un projet ?
- Un senior externe devient pertinent quand il faut diagnostiquer vite sans politique interne, prioriser les risques avec sang-froid, et intervenir directement sur la production. C'est particulièrement vrai s'il n'y a pas de CTO, si plusieurs prestataires se sont succédé, ou si l'entreprise a besoin d'un avis capable de distinguer ce qui est réparable de ce qui doit être remplacé.