Quand un projet commence-t-il à couler ?
Tout projet informatique commence de manière similaire. Il y a des plans ambitieux, un calendrier, la présentation des premières maquettes et la conviction que dans quelques mois l'entreprise utilisera un système moderne. Au début tout semble prometteur, mais avec le temps apparaissent les premiers retards. La date est repoussée d'une semaine, puis d'un mois. Le nombre d'erreurs augmente, la communication avec le prestataire devient de plus en plus difficile, et les réponses suivantes reviennent : "Encore un peu", "Ce n'est qu'une petite correction" ou "Nous sommes presque au bout."
À un certain moment il s'avère que, au lieu d'un produit prêt, l'entreprise a un projet inachevé que personne ne veut reprendre.
C'est un scénario beaucoup plus fréquent qu'on ne pourrait le croire.
Le plus grand problème n'est pas le code
La plupart des entrepreneurs partent du principe que si le projet ne fonctionne pas, c'est à cause d'un mauvais code. Certes - parfois c'est effectivement le cas. En pratique toutefois le problème réside bien plus souvent plus profondément.
Il manque de la documentation. L'architecture a été construite "au fil de l'eau". Il n'y a pas de tests automatisés. Les intégrations ont été faites de manière provisoire. De nouvelles fonctionnalités ont été ajoutées sans analyse de leur impact sur l'ensemble du système. En conséquence, même une petite modification provoque d'autres erreurs.
C'est un peu comme rénover une maison sans plan. Chaque pièce peut encore être finie, mais avec le temps on constate que les murs ne sont pas là où ils devraient être, que les installations sont posées au hasard, et que la reconstruction devient de plus en plus coûteuse.
Quand faut-il dire "stop" ?
L'un des moments les plus difficiles pour le dirigeant est la décision d'interrompre la collaboration avec le prestataire actuel. Beaucoup d'entrepreneurs tardent trop à la prendre.
Pourquoi ?
Parce que le projet a déjà englouti beaucoup d'argent.
Parce que c'est du temps perdu.
Parce qu'on se dit que "peut-être ça va marcher".
La psychologie appelle cela l'effet des coûts irrécupérables. Plus nous avons déjà investi, plus il est difficile d'admettre que la direction actuelle mène nulle part.
Or, parfois la meilleure décision n'est pas de continuer à injecter du budget dans le même problème, mais d'arrêter le projet et d'analyser calmement la situation.
Tous les projets peuvent-ils être sauvés ?
Non. - Et il est important de le dire honnêtement.
Il existe des projets dont la réparation coûterait plus que de les recréer depuis zéro. Il arrive aussi que la technologie utilisée soit déjà obsolète ou que l'architecture ait été conçue de façon à empêcher tout développement futur.
C'est pourquoi la première étape ne devrait jamais être de faire des promesses.
La première étape doit être un audit.
Ce n'est qu'après une analyse approfondie du code, de la documentation, de l'infrastructure et des processus que l'on peut répondre à la question : vaut-il mieux réparer la solution existante ou lancer un nouveau projet ?
Un bon partenaire technologique ne dira pas ce que le client veut entendre.
Il dira ce qui est le mieux pour lui d'un point de vue business.
À quoi ressemble la reprise d'un projet en pratique ?
Contrairement aux idées reçues, cela ne commence pas par du codage.
Il faut d'abord comprendre avec quoi nous avons affaire.
Nous analysons l'architecture du système, la qualité du code, la façon dont les modules communiquent entre eux, la sécurité des données, les performances et les possibilités d'évolution. Nous vérifions la documentation, l'historique des changements et les technologies utilisées. Souvent, dès les premiers jours, on sait où se trouve le véritable problème.
Ce n'est qu'ensuite qu'un plan d'action est établi.
Parfois il suffit d'organiser le code et de corriger quelques éléments clés. D'autres fois, une refonte de certains modules est nécessaire. Il arrive également que la solution la plus raisonnable soit de créer un nouveau système en réutilisant ce qui a déjà été produit.
Il n'y a pas deux projets identiques.
De même, il n'existe pas une seule recette pour les sauver.
Pourquoi reprendre un projet est-il plus difficile que d'en créer un nouveau ?
C'est une question que nous entendons souvent de la part des clients.
La réponse est simple.
En créant un système depuis le début, nous connaissons chaque décision de conception. Nous savons pourquoi une solution a été choisie et quelles en étaient les hypothèses.
En reprenant le projet d'autrui, nous devons d'abord reconstituer ces connaissances.
C'est un peu comme reprendre la construction d'une maison après une équipe qui a laissé le chantier sans plans, sans documentation et sans informations sur ce qui a été fait.
C'est pourquoi sauver des projets demande non seulement des compétences en développement, mais aussi de l'expérience en architecture, en analyse et en conception.
Le partenaire technologique doit aussi être à vos côtés quand apparaissent des problèmes
Un bon software house se reconnaît non pas à la façon dont il démarre un projet.
Mais à la manière dont il réagit lorsqu'apparaissent des difficultés.
On ne peut pas tout prévoir. Les exigences business, les technologies et les besoins des utilisateurs évoluent. L'important est de savoir si l'équipe est capable de trouver une solution, de communiquer clairement les risques et de prendre, avec le client, les meilleures décisions.
C'est ainsi que se construit la confiance.
Comment travaillons-nous chez Web24 ?
Nous abordons les projets à reprendre avec une grande prudence.
Nous ne faisons pas de promesses après le premier entretien.
Nous analysons d'abord la situation. Nous vérifions ce qui a été réalisé, ce qui peut être réutilisé et ce qui devra être reconstruit. Ce n'est qu'ensuite que nous préparons une recommandation et un plan d'actions.
Notre objectif n'est pas d'écrire des milliers de lignes de code supplémentaires.
Notre objectif est d'amener le projet au point où il commencera réellement à soutenir le développement de l'entreprise.
Résumé
Si votre projet est bloqué, que le prestataire ne répond plus, que le planning n'existe plus que sur le papier et que chaque correction engendre de nouvelles erreurs, cela ne signifie pas encore que tout est perdu.
Dans de nombreux cas, le problème peut être résolu.
Il faut cependant commencer par une étape : une analyse rigoureuse de la situation.
Car avant de tenter de sauver le projet, il vaut mieux d'abord comprendre pourquoi il a commencé à couler.
