Projet tech compliqué ? Comment reprendre la main sans tout jeter à la poubelle

C’est un scénario classique, mais douloureux. Vous aviez une vision, un budget et une deadline. Six mois plus tard, le budget est consommé, la deadline est dépassée et l’application est instable.

Vous vous posez alors la question fatidique : faut-il persévérer avec l’équipe actuelle ou changer d’agence web ?

Chez Fenxi, nous voyons arriver ce genre de projets régulièrement. C’est même la première étape de notre offre : Reprendre l’existant.

Pourquoi tant de projets tech finissent dans le mur ?

Avant de chercher le remède, il faut comprendre la maladie. Dans 90% des cas de reprise de projet, les causes sont identiques :

• un scope flou : L’objectif n’a pas été bien défini. Résultat : on ajoute des fonctionnalités au fil de l’eau, complexifiant le code sans jamais stabiliser la base.
• Des mauvaises décisions techniques : L’agence précédente a choisi une technologie parce que c’est la seule qu’ils connaissent, et non parce qu’elle est adaptée à votre besoin business.
• Manque de transparence : Tout semblait avancer alors que la dette technique s’accumulait en silence.

La Check-list vitale avant de « virer » votre prestataire actuel

Vous avez décidé de changer d’agence ? Attention. Assurez vous d’abord d’avoir sécurisé vos actifs. Une transition brutale peut faire perdre tout ce que vous avez construit jusqu’ici.

Voici ce que vous devez récupérer impérativement (par ordre d’importance) :

1. L’accès au code source (Git) : Assurez-vous d’avoir les droits administrateur sur le dépôt (GitHub, GitLab, Bitbucket, …). C’est votre propriété intellectuelle, et c’est ce qu’il y a de plus important.
2. Les accès Hébergement et SaaS : Les serveurs (ordinateurs), ou votre code et les outils qui l’entourent, sont hébergés. Si l’agence détient les clés du serveur, vous êtes otage.
   • Cloud : AWS, Google Cloud, Azure, OVH, Scaleway, …
   • Paiement: Stripe, Adyen, …
   • Mails automatisés : Sendgrid, Mailgun, …
3. La documentation technique : Si l’agence précédente a fait des documentations techniques, n’hésitez pas à leur demander. Cela pourra être utile pour la nouvelle agence.

Conseil : Faites cet audit discrètement ou contractuellement avant d’annoncer la rupture commerciale.

Comment structurer une reprise de projet (La Méthode Fenxi)

Reprendre une application existante, ce n’est pas juste « copier-coller » le code chez un autre hébergeur. Voici notre roadmap standard sur les premières semaines :

1. L’Audit de Code

Nous analysons la qualité du code, la sécurité et la scalabilité. L’objectif est de répondre à la question : Sommes nous en mesure de travailler avec le code existant ?

2. La Sécurisation et les « Quick Wins »

Avant de développer de nouvelles fonctionnalités, nous nous focalisons sur la correction des bugs critiques qui bloquent le business et mise à niveau des versions.

3. La Roadmap à 90 jours

Une fois l’incendie éteint, on peut enfin se focaliser sur la suite. Généralement, nous faisons un audit (UX, UI, besoins utilisateurs) pour définir les priorités à venir. Nous définissons un périmètre strict pour les 3 prochains mois. L’objectif est de pouvoir livrer des fonctionnalités utiles, rapidement.

Le dilemme : Réparer ou Refaire ?

C’est la décision la plus difficile. Parfois, la dette technique est telle que tenter de réparer le code coûtera plus cher (en temps et en argent) que de repartir de zéro, avec les bonnes technologies.

Besoin d’un diagnostic honnête ?

Vous avez assez perdu de temps avec des promesses. Chez Fenxi, nous proposons un audit de reprise de votre logiciel. Nous analysons le code, l’architecture et vos process. À la fin de la semaine, nous vous livrons un rapport transparent vous indiquant si ça vaut le coup de continuer sur l’existant ou s’il est temps de repartir sur des bases saines.

Si vous n’avez pas encore démarrer de projet tech, n’hésitez pas à consulter cet article pour bien choisir votre agence.