Ce que fait une reprise de projet
Elle commence par établir l'état réel de ce qui est livré, indépendamment de ce qui est annoncé. Ensuite seulement viennent les options : réparer avec le prestataire en place, réduire le périmètre pour sortir une version utilisable, ou changer d'équipe en récupérant ce qui peut l'être. Le diagnostic prend quelques jours, la décision vous appartient.
Le constat d'abord, les responsabilités après
La tentation naturelle, quand un projet dérape, est de chercher un responsable. C'est compréhensible et c'est prématuré : tant que personne ne sait ce qui fonctionne réellement, toute discussion de responsabilité se tient sur des récits contradictoires. La reprise commence donc par regarder ce qui tourne, pas par écouter ce qu'on en dit.
Le travail tient en quatre gestes : ouvrir le dépôt de code, exécuter ce qui est livré, relire le contrat et les comptes rendus, puis comparer avec ce qui était engagé. Cet écart, écrit noir sur blanc, change la nature de la conversation avec le prestataire. La plupart des renégociations réussies commencent là.
Ce que les symptômes indiquent
Les mêmes signes reviennent, et ils n'ont pas tous la même cause ni la même issue.
| Ce que vous observez | Cause la plus fréquente | Premier geste |
|---|---|---|
| Les dates glissent sans explication | Le périmètre a grossi sans avenant | Reconstituer les demandes ajoutées |
| Les démonstrations sont toujours partielles | Ce qui est montré n'est pas ce qui est livré | Exiger un accès à l'environnement de test |
| Le prestataire répond de moins en moins | Marge épuisée sur un forfait mal chiffré | Ouvrir la discussion sur le périmètre, pas sur le retard |
| Le budget est consommé, rien n'est utilisable | Aucune version intermédiaire livrable | Définir une version minimale et s'y tenir |
| Personne ne sait ce qui reste à faire | Pas de suivi partagé depuis le début | Reconstruire la liste des restes à faire |
Les trois issues, et leur coût réel
Réparer avec l'équipe en place est presque toujours l'option la moins coûteuse, quand la compétence technique est là et que seul le pilotage a manqué. Elle suppose un avenant qui redéfinit le périmètre et un suivi qui ne se relâche plus.
Réduire pour sortir consiste à accepter une version plus petite mais réellement utilisable, et à repousser le reste. C'est souvent la meilleure décision et la plus difficile à faire accepter, parce qu'elle ressemble à un renoncement alors qu'elle met fin à l'hémorragie.
Changer d'équipe est l'option la plus chère et parfois la seule. Elle ne se décide qu'après avoir vérifié ce qui est récupérable : le code, les maquettes, les données, les accès. Un changement décidé avant cette vérification fait perdre une deuxième fois ce qui avait déjà été payé.
Éviter la deuxième fois
Un projet qui a dérivé une fois dérive une seconde fois si rien ne change dans la façon de le tenir. La sortie de crise se termine donc par ce qui manquait : un suivi lisible, des jalons avec un contenu vérifiable, et une personne nommée qui arbitre. C'est le passage naturel vers un pilotage classique.
Le guide projet en dérive détaille le diagnostic étape par étape, et la page reprise d'un projet applicatif traite le cas d'une application déjà développée. Les deux sont en accès libre : une partie du travail peut se faire sans moi.
Une reprise de projet, en chiffres
Reprise, France
Sauvetage refonte en dérive
Projet bloqué depuis 6 mois. Audit express, redéfinition MVP.
- Premier retour
- 48 hPremier retour
- Mise en ligne
- 6 sem.Mise en ligne
« Excellente prestation, Laurent est très pro ! »