Reprise d'un projet après deux échecs successifs

Reprise d'un projet après deux échecs successifs

Comment un projet web resté bloqué avec deux prestataires successifs a été repris et unifié en une seule application Laravel.

Secteur : privé - Service : Diagnostic & reprise de projet en difficulté

Trois ans de projet. Deux prestataires. Trois applications. Je commence la reprise en ouvrant directement le code.

Le contexte

Le client avait besoin d'un outil web pour trois audiences différentes. Deux prestataires avaient déjà travaillé successivement sur le projet pendant plus de trois ans, sans parvenir à un résultat complètement fonctionnel.

Les deux interventions successives avaient abouti à trois sites distincts, un par audience, mais interconnectés entre eux, avec une forte duplication du code et de la logique métier. À cela s'ajoutait un problème sur le parcours de paiement : le système n'était pas correctement configuré, et la gestion de la TVA était erronée.

Le projet n'avait donc pas seulement un problème de finition. Il fallait remettre en question une partie de l'existant.

Le diagnostic

Avant de proposer une solution, j'ai analysé directement le code source de l'application, faute de documentation suffisante : ni spécifications fonctionnelles complètes, ni documentation technique. Il fallait reconstituer le fonctionnement réel du système à partir de ce qui avait été développé, puis confronter ce fonctionnement au besoin métier avec le porteur de projet.

L'analyse a montré que les trois audiences avaient été traitées comme des applications quasiment indépendantes, alors qu'elles partageaient un socle fonctionnel commun. La duplication n'était donc pas qu'un problème de maintenance, elle était la conséquence d'un choix d'architecture qui avait progressivement éloigné le système de son besoin réel.

La décision : reconstruire plutôt que rafistoler

J'ai proposé une refonte complète, pas simplement une succession de corrections : conserver les besoins fonctionnels identifiés tout en supprimant la duplication. La nouvelle architecture repose sur une seule application, où les différences entre audiences sont gérées au niveau des droits et des interfaces, plutôt que par des applications distinctes.

La reprise du projet

Le développement s'est fait progressivement, avec des points hebdomadaires pour présenter l'avancement et recueillir les retours. Les écarts pouvaient ainsi être identifiés pendant le développement, plutôt que découverts au moment de la livraison.

Le système de paiement a été reconfiguré pour corriger la gestion de la TVA. L'application a été livrée sur un serveur de recette pour validation, puis mise en production sur une configuration strictement identique. Des sauvegardes automatiques ont été mises en place.

Les aspects techniques

  • Analyse et reprise d'une application existante avec très peu de documentation
  • Refonte de l'architecture autour d'une application commune
  • Gestion différenciée des droits et des audiences
  • Configuration du système de paiement et de la TVA
  • Mise en place d'un environnement de recette distinct de la production
  • Déploiement en production depuis une version validée en recette

Le résultat

Une seule application à maintenir au lieu de trois.

Surtout, une application enfin fonctionnelle, permettant au client de commencer à l'utiliser réellement et de générer ses premiers abonnements.

Le projet est passé d'un système bloqué depuis plusieurs années à une application opérationnelle en quatre mois.

Ce que ce projet illustre

Après trois ans et deux prestataires, continuer à corriger l'existant aurait surtout consisté à prolonger les choix qui avaient conduit au blocage.

Le travail de reprise ne consiste donc pas nécessairement à sauver ce qui existe. Il consiste d'abord à déterminer ce qui mérite de l'être.

Dans ce projet, la bonne décision était de conserver le besoin fonctionnel, mais de remettre à plat l'architecture. Dans un autre contexte, le diagnostic pourrait conduire à conserver l'existant, à n'en reprendre qu'une partie ou à changer complètement de solution.

Questions fréquentes

Pourquoi les précédents prestataires n'avaient-ils pas vu le problème ?

Traiter chaque audience comme un site distinct peut sembler plus simple à court terme. Le coût de cette duplication apparaît surtout ensuite, quand les fonctionnalités doivent évoluer sur plusieurs applications à la fois.

Fallait-il forcément tout reconstruire ?

Non. Une reconstruction complète n'est pertinente que lorsque l'analyse montre que poursuivre sur l'existant coûterait davantage, techniquement ou fonctionnellement, que repartir sur une nouvelle base.

Pourquoi commencer par analyser le code plutôt que par refaire les spécifications ?

Parce que le système existant était la principale source d'information disponible. Sans documentation suffisante, l'analyse du code permet de comprendre ce qui a réellement été construit, indépendamment de ce qui était prévu au départ.

Peut-on reprendre un projet avec un nouveau prestataire sans repartir de zéro ?

Oui. Une reprise commence par distinguer ce qui est exploitable de ce qui ne l'est pas, pas nécessairement jeter le travail précédent.

Votre projet est bloqué après plusieurs prestataires ou plusieurs années de développement ?

Discutons de votre situation →
Cette réalisation illustre une intervention de diagnostic, de reprise et de développement. Chaque situation étant différente, un premier échange permet d'évaluer si une intervention est pertinente avant toute proposition.