Comment sauver un projet logiciel en difficulté (et quand repartir de zéro)

Un projet échoue rarement du jour au lendemain. Il dérive, et chaque signal pris isolément s’explique facilement. Ensemble, ils deviennent difficiles à ignorer :

• Les dates glissent sans cesse, chaque fois pour une nouvelle raison.
• Chaque correction casse autre chose, et les mêmes bugs reviennent.
• Personne ne sait dire clairement quand le produit sera lancé.
• Le développeur ou l’agence répond lentement, ou plus du tout.
• Vous n’avez pas accès au code, aux serveurs ou aux comptes.
• Les nouveaux développeurs disent qu’ils ne peuvent pas travailler sur le code « sans d’abord le réécrire ».

Un seul de ces signaux est un avertissement. Trois ou plus signifient en général que le projet a besoin d’une reprise, pas d’une nouvelle échéance.

Par exemple, une startup dont le freelance ne répond plus et détient seul le mot de passe du serveur a besoin d’une reprise, même si le code en lui-même est correct.

La première semaine pose les bases de tout le reste. Avant tout travail technique, quatre étapes :

• Mettre en pause les nouvelles fonctionnalités. Continuer à construire sur une base instable renchérit chaque correction à venir.
• Sécuriser les accès. Vérifiez que vous contrôlez le code, les serveurs, le domaine et chaque service dont dépend le produit.
• Noter ce qui a été promis et ce qui existe. Rassemblez la proposition, le contrat, les maquettes et la liste de ce qui fonctionne réellement aujourd’hui.
• Suspendre les paiements non liés à un travail livré. Si les paiements suivent des jalons, mettez le prochain en attente jusqu’à ce qu’un plan clair existe.

Ne commencez pas par chercher un coupable. Qui a mené le projet là et pourquoi compte bien moins que de savoir ce qui peut être fait maintenant, combien cela coûtera et quand le produit fonctionnera.

Les accès sont ce qui manque le plus souvent aux fondateurs au moment où ils en ont besoin. Passez en revue chaque point de cette liste et notez qui le contrôle aujourd’hui :

• Le dépôt de code avec tout son historique, pas une archive zip de la dernière version.
• Les comptes d’hébergement et de serveurs, y compris les bases de données et les sauvegardes.
• Le registraire du domaine et les réglages DNS.
• Les comptes développeur des stores, s’il existe une application mobile.
• Les services tiers : paiement, e-mail, analytics, cartes, API d’IA.
• Les fichiers de design et toute documentation existante.

Si le dépôt se trouve sur le compte de quelqu’un d’autre, demandez son transfert. La documentation de GitHub explique comment un transfert conserve l’historique, les issues et les pull requests.

Si quelqu’un refuse de coopérer, récupérez ce que vous pouvez de votre côté : le domaine et l’hébergement sont souvent payés avec votre carte ou enregistrés à votre adresse e-mail, et c’est une porte de retour.

Un audit est un examen structuré du produit tel qu’il est, et non tel que le dernier prestataire l’a décrit. Un audit utile couvre ces domaines :

• Architecture. Comment les éléments s’articulent et si la structure peut porter les fonctionnalités dont vous avez besoin.
• Qualité du code. Lisibilité, duplication et niveau de risque de chaque modification.
• Sécurité. Les risques courants comme ceux du Top 10 de l’OWASP, ainsi que la façon dont les secrets et les données personnelles sont stockés.
• Infrastructure. Hébergement, déploiement, sauvegardes et supervision.
• Tests et documentation. Ce qui existe, ce qui manque et ce que coûterait l’ajout.

Le résultat doit être un verdict clair pour chaque partie du produit : garder, réparer ou réécrire, chacun avec sa justification. Ce n’est qu’ensuite qu’on peut vous donner un prix qui reflète le code tel qu’il est.

Chez Sakura, nous travaillons exactement dans cet ordre : d’abord l’audit, ensuite le devis. C’est le seul moyen de ne pas chiffrer une reprise sur des promesses que le code ne tient pas.

Votre projet est bloqué en ce moment ? Racontez-nous ce qui s’est passé. Nous commencerons par les accès et l’audit, et nous vous dirons honnêtement ce qui peut être sauvé.

Le plus souvent, réparer. Un vieux code qui tourne en production contient des années de petites corrections apportées à de vrais problèmes, et une réécriture les jette avec les mauvaises parties.

Joel Spolsky l’a expliqué dans son célèbre essai Things You Should Never Do. Il qualifiait la réécriture complète du code de « pire erreur stratégique qu’une entreprise de logiciels puisse commettre », en prenant l’exemple de Netscape : la réécriture a pris près de trois ans pendant que les concurrents prenaient de l’avance.

Il existe des cas où réécrire est la réponse honnête. Ce tableau montre comment nous pesons le pour et le contre :

Même quand la réécriture l’emporte, elle se fait rarement d’un bloc. Le modèle Strangler Fig de Martin Fowler décrit comment remplacer un système morceau par morceau : les nouvelles parties grandissent à côté des anciennes jusqu’à ce que l’ancien code puisse être arrêté.

Si l’ancien développeur ou l’ancienne agence reste joignable, une transmission courte et sereine fait gagner du temps et de l’argent. Demandez trois choses : l’accès à tout, la liste des problèmes connus et une session d’une heure sur la façon dont le produit est déployé.

Restez sur les faits. Les gens en disent plus quand ils ne se sentent pas accusés, et les détails dont ils se souviennent sur le code valent plus que n’importe quel débat sur les responsabilités.

Si l’ancienne équipe ne coopère pas, ne l’attendez pas. Récupérez les comptes que vous contrôlez, lancez l’audit avec ce qui existe et consignez par écrit ce que vous avez demandé et quand.

Une fois le verdict posé, travaillez dans un ordre strict. D’abord le lancement, ensuite les améliorations :

• Stabiliser. Corrigez les bugs critiques qui font planter le produit, perdent des données ou bloquent les paiements.
• Terminer les parcours du lancement. Ne finalisez que ce dont le produit a besoin pour sortir ; le reste attend.
• Mettre en place déploiement et supervision. Pour que les mises en production deviennent une routine et que les problèmes soient visibles avant que les utilisateurs ne les signalent.
• Lancer. Les vrais utilisateurs vous montreront lesquels des problèmes restants comptent vraiment.
• Améliorer. Traitez le reste de la liste selon son impact sur l’activité.

Des versions hebdomadaires que vous pouvez tester gardent la reprise honnête. Après un projet qui a déjà dérapé une fois, vous devez voir l’avancement chaque semaine, pas seulement en entendre parler.

Par exemple, une startup dont l’agence a manqué plusieurs échéances peut découvrir que l’essentiel du produit fonctionne et que trois parcours cassés bloquent le lancement. En réparant ces trois-là en premier, le produit sort, et le reste du backlog se planifie avec de vraies données d’usage.

Tout dépend de ce que trouve l’audit, c’est pourquoi un devis honnête vient après l’audit et non avant. Quiconque chiffre une reprise sans regarder le code devine.

Après l’audit, le travail jusqu’au lancement peut généralement être chiffré au forfait. Vous obtenez ainsi un montant clair pour la mise en production, séparé des améliorations qui suivent.

Si vous comparez des devis pour la reprise elle-même, les mêmes règles s’appliquent qu’à tout projet. Notre guide forfait ou régie explique quand chaque modèle convient.

Un projet repris est l’occasion de mettre en place les garde-fous qui manquaient la première fois :

• Propriété. Le dépôt, l’hébergement, le domaine et les comptes des stores restent au nom de votre entreprise.
• Documentation. Elle s’écrit au fil du travail, pour que le produit ne dépende plus jamais d’une seule personne.
• Jalons. Les paiements suivent des résultats vérifiables, comme une version fonctionnelle accessible par un lien de test.
• Un processus de changement. Les nouvelles demandes sont estimées et validées avant que quiconque ne s’y mette.
• Un support après le lancement. Un plan clair pour les corrections et les mises à jour, comme un forfait de support mensuel.

Si vous choisissez une nouvelle équipe pour la suite, notre guide pour choisir une agence de développement réunit les questions qui révèlent les partenaires fragiles avant la signature.

Si vous voulez que votre produit reparte, envoyez-nous un court brief. Nous commencerons par les accès et l’audit pour que vous sachiez où vous en êtes avant tout engagement important.