Comment nous sauvons les projets logiciels qui ont déraillé

Peu de choses sont plus frustrantes que d'investir des mois — voire des années — dans un projet logiciel, pour finalement découvrir qu'il ne répond pas aux besoins de votre entreprise.

Parfois, les échéances ne cessent de reculer. Parfois, le code devient impossible à maintenir. Et il arrive plus d'une fois que le partenaire de développement initial disparaisse tout simplement de la circulation.

La bonne nouvelle ? Tous les projets logiciels en difficulté n'ont pas besoin de repartir de zéro. Tout l'investissement n'est pas perdu et, avec le bon plan… votre logiciel verra le jour.

Chez We Do Dev Work, nous avons repris plusieurs projets considérés comme « trop complexes » ou « irrécupérables ». Bien que chaque situation soit unique, notre approche reste remarquablement constante.

Étape 1 : Garder son calme

La première discussion porte rarement sur le code.

Il s'agit de comprendre où les choses ont mal tourné, ce qui fonctionne encore et ce dont l'entreprise a réellement besoin aujourd'hui.

Beaucoup de clients partent du principe qu'ils devront jeter tout ce qu'ils ont construit. Souvent, c'est faux.

Un projet de sauvetage commence par des faits, pas par des suppositions.
Les émotions ne construiront pas un plan de relance.

Étape 2 : Ne pas perdre de temps à blâmer l'équipe précédente

Il peut être tentant de pointer du doigt les responsables.

Nous ne le faisons pas.

Chaque équipe de développement travaille avec des budgets, des délais, des exigences et des contraintes différents. Sans connaître toute l'histoire, il est impossible de juger les décisions qui ont été prises.

L'échec nous apporte également des informations qui nous aident à réussir. Ainsi, même si l'équipe précédente a échoué : elle nous a aidés à aider notre client.

Plus important encore, blâmer les anciens développeurs ne fait pas avancer le projet.

Il nous est arrivé plus d'une fois qu'ils soient ravis de nous aider en nous donnant des retours précieux. La plupart des gens sont de bonne volonté et espèrent sincèrement que nous mènerons le projet à bien.

Notre travail est de résoudre le problème, pas de désigner un coupable.

Étape 3 : Revenir aux objectifs commerciaux

Avant d'ouvrir le moindre fichier de code source, nous réexaminons les objectifs commerciaux initiaux.

Les questions que nous posons typiquement incluent :

• Quel problème le logiciel est-il censé résoudre ?

• Quelles sont les fonctionnalités essentielles ?

• Quelles exigences ont changé pendant le développement ?

• À quoi ressemble concrètement un lancement réussi ?

• Quelles attentes sont réalistes par rapport au budget disponible ?

Ce n'est qu'après avoir répondu à ces questions que nous définissons un périmètre et une feuille de route clairs.

Sans cette étape, même un logiciel techniquement parfait peut être un échec.

Étape 4 : Réaliser un audit technique honnête

C'est seulement à ce moment-là que nous plongeons dans le code.

Notre but n'est pas de débusquer des erreurs, mais de comprendre ce qui peut être réutilisé de manière réaliste.

Nous analysons des points tels que :

• L'architecture

• La qualité du code

• La sécurité

• La performance

• La maintenabilité

• Les tests

• La documentation

• Le processus de déploiement

La plupart des projets ne sont ni totalement bons, ni totalement mauvais.

En général, on y trouve un mélange de travail solide et de zones nécessitant des améliorations significatives.

Étape 5 : Garder ce qui est pertinent (Remplacer le reste)

C'est ici que l'expérience entre en jeu.

Certaines agences recommandent immédiatement de tout réécrire. D'autres tentent de préserver chaque ligne de code. Ces deux approches peuvent s'avérer coûteuses.

Au lieu de cela, nous évaluons chaque composant individuellement. Si un élément est stable, maintenable et s'intègre dans la future architecture, nous le gardons. S'il est devenu une dette technique qui coûte plus cher à entretenir qu'à reconstruire, nous le remplaçons.

L'objectif est simple : offrir la voie la plus rapide vers un produit stable et maintenable.

Exemples concrets

C'est bien beau tout ça, We Do Dev Work, mais mettez-vous vraiment vos principes en pratique ?
Cher lecteur, la réponse est oui !

Et chaque projet de sauvetage est différent.

PUT-IT-ON

Dans ce projet, le backend reposait sur des bases solides.

Plutôt que de le remplacer, nous avons décidé de conserver la majeure partie du backend tout en reconstruisant le frontend pour créer une expérience utilisateur plus moderne et facile à maintenir.

Cela nous a permis de protéger l'investissement initial du client tout en améliorant considérablement le produit.

Waterleau

Ce projet a nécessité l'approche inverse.

Le frontend répondait déjà assez bien aux besoins de l'entreprise, mais l'architecture backend limitait les développements futurs.

Au lieu de réécrire l'interface, nous avons conçu une nouvelle architecture backend et introduit de nouveaux points de terminaison API, rendant le système plus évolutif et plus simple à maintenir.

Encore une fois, le but n'était pas de tout réécrire.

C'était de ne réécrire que ce qui devait réellement l'être.

Parfois, la meilleure solution n'est pas la réécriture complète

L'une des plus grandes idées reçues en développement logiciel est qu'un projet en échec nécessite toujours un redémarrage complet.

En réalité, la plupart des projets contiennent un travail de valeur.

Le défi consiste à identifier ce qui mérite d'être conservé et ce qui ne le mérite pas.

Faire cette distinction peut faire gagner des mois de développement et économiser une part importante du budget du projet.

Sauver un projet demande une vision business

Récupérer un projet logiciel n'est pas seulement un exercice technique.

Il s'agit de comprendre l'entreprise, de réduire les risques, de rétablir la confiance et de prendre des décisions pragmatiques.

La technologie doit soutenir votre activité, pas devenir l'obstacle qui la freine.

Si votre projet logiciel actuel ne progresse pas comme il le devrait, ne partez pas du principe qu'il faut tout jeter.

Parfois, la solution la plus intelligente est de savoir exactement quoi garder. Discutons-en ensemble.