Sauvetage de projet logiciel
Le sauvetage de projet logiciel, c’est ce qu’il vous faut quand un développement que vous avez déjà payé est en retard, dépasse le budget ou ne fait pas ce qu’il devait faire, et que vous essayez de décider s’il faut continuer, repartir de zéro ou faire appel à quelqu’un d’autre. Si vous en êtes là, voici comment y voir clair, et comment un sauvetage se déroule concrètement.
Les signes qu’un projet a besoin d’un sauvetage
Quelques scénarios reviennent constamment :
Les échéances reculent sans cesse, et personne ne peut vous donner une date crédible. Le coût a déjà dépassé le budget initial, et on n’en voit pas la fin. Chaque nouvelle fonctionnalité en brise deux anciennes. L’équipe ne peut pas expliquer comment le système fonctionne, ou les personnes qui l’ont construit sont parties. Et vous avez peur de déployer, parce que quelque chose tourne toujours mal.
Un ou deux de ces signes, c’est normal dans n’importe quel projet. Trois ou plus, et le projet n’est pas seulement en retard. Il est en difficulté.
Sauver ou reconstruire
La première vraie décision est de savoir s’il faut sauver le code existant ou le reconstruire à partir de zéro. On croit souvent qu’une reconstruction est plus propre, mais une réécriture complète jette tout ce qui fonctionne déjà et prend presque toujours beaucoup plus de temps que prévu. La plupart des projets devraient être sauvés, pas reconstruits.
La réponse honnête dépend de l’état du code, et on ne peut le connaître qu’en le lisant. C’est la première étape de tout vrai sauvetage : un ingénieur senior lit le code, l’architecture et la configuration de déploiement, puis vous donne une évaluation franche. Pas un argumentaire de vente, une lecture franche. Parfois, la bonne réponse est de reconstruire. Plus souvent, le cœur est récupérable et les problèmes sont concentrés à quelques endroits.
Comment un sauvetage se déroule
Une fois que vous savez à quoi vous avez affaire, un sauvetage suit un chemin clair :
Premièrement, on gèle la portée. On arrête d’ajouter des fonctionnalités, parce qu’on ne peut pas stabiliser une cible qui bouge. Deuxièmement, on évalue et on documente ce qui existe, ce qui fonctionne et où se trouvent les vrais problèmes. Troisièmement, on stabilise, c’est-à-dire qu’on corrige ce qui rend le système risqué à modifier ou à déployer, pour pouvoir travailler sans l’abîmer davantage. Quatrièmement, on ramène la portée à l’essentiel et on rend fonctionnel et livrable ce qui a le plus de valeur pour l’entreprise, avant tout le reste. Cinquièmement, on refait le plan avec des dates réalistes et des responsabilités claires, à partir de ce que le code est réellement plutôt que de ce que le plan initial supposait.
L’objectif est de vous faire passer de « on a peur d’y toucher » à « on livre de nouveau » le plus vite possible, puis de vous amener là où le logiciel peut grandir sans s’effondrer.
Pourquoi les projets en arrivent là
Il est utile de savoir pourquoi vous en êtes là, parce qu’un bon sauvetage corrige la cause, pas seulement les symptômes. Les raisons sont presque toujours les mêmes : le travail a été confié à des développeurs juniors ou à une firme à bas prix sans supervision senior, la portée s’est élargie parce que personne n’osait dire non, et personne n’était responsable de l’architecture. Le code reflète ces décisions. Un sauvetage qui ne fait que corriger les bogues actuels, sans s’attaquer à la façon dont le code est construit, vous ramènera au même point dans six mois.
Quoi rechercher chez un partenaire de sauvetage
Savoir écrire un logiciel ne veut pas dire savoir en sauver un qui échoue. Sauver est plus difficile que construire à partir de zéro, parce qu’il faut comprendre les décisions de quelqu’un d’autre, sous pression. Recherchez des ingénieurs seniors qui liront le code eux-mêmes plutôt que de le confier à des juniors, une évaluation honnête dès le départ, y compris la possibilité qu’on vous dise de reconstruire ou même d’arrêter, et des gens qui corrigent la cause plutôt que le bogue visible.
Notre approche
Chez NorthSight Technologies, c’est une partie centrale de notre travail. Nous sommes des ingénieurs seniors canadiens qui travaillent avec des clients au Canada et aux États-Unis, et les personnes qui évaluent votre projet sont celles qui font le travail. Nous commençons par une lecture honnête du code, nous vous disons clairement s’il faut sauver ou reconstruire et, s’il s’agit d’un sauvetage, nous stabilisons le système, livrons l’essentiel et vous redonnons le contrôle. Pas de transfert à des juniors, et personne ne prétend qu’une réécriture est gratuite.
Si vous avez un projet logiciel qui est en retard, qui dépasse le budget ou qui dérape, nous pouvons vous aider. Pour en savoir plus sur notre façon de travailler, consultez notre page développement de logiciels sur mesure.