Comment reprendre un projet web bloqué ou mal codé

Un projet bloqué n’est pas toujours à refaire

Un projet web peut se retrouver à l’arrêt pour plusieurs raisons : un prestataire qui n’est plus disponible, un code difficile à maintenir, des accès manquants, un budget mal défini ou des fonctionnalités qui n’ont jamais été stabilisées. Dans ce contexte, la première erreur consiste à promettre une reconstruction complète avant d’avoir compris ce qui existe déjà.

Une reprise sérieuse commence par réduire l’incertitude. Il faut savoir ce qui fonctionne, ce qui est récupérable, ce qui est risqué et ce qui doit être remplacé.

Étape 1 : sécuriser les accès et les actifs

Avant toute modification, rassemblez les accès au dépôt de code, à l’hébergement, au domaine, à la base de données, aux services de paiement, aux comptes d’analytique et aux fournisseurs tiers. Vérifiez qui possède réellement ces comptes et mettez en place une sauvegarde vérifiable.

Cette étape est souvent sous-estimée. Sans accès au domaine ou à la base de données, même une équipe compétente peut perdre du temps et augmenter le risque de panne.

Étape 2 : faire un audit technique ciblé

L’objectif n’est pas de produire un rapport de centaines de pages. Il faut répondre à des questions opérationnelles :

• Comment le projet est-il construit et déployé ?
• Quelles versions et dépendances sont utilisées ?
• Où sont les erreurs, la dette technique et les secrets exposés ?
• La base de données peut-elle être sauvegardée et restaurée ?
• Les formulaires, paiements et intégrations sont-ils testables ?
• Le site respecte-t-il les exigences de performance et d’accessibilité ?

Un audit utile classe les problèmes par impact et urgence. Une erreur de configuration qui empêche le déploiement n’a pas la même priorité qu’une amélioration visuelle.

Étape 3 : choisir entre corriger, isoler ou reconstruire

Trois stratégies sont généralement possibles. Corriger permet de préserver l’investissement existant lorsque l’architecture est saine. Isoler une partie permet de sécuriser progressivement un système qui fonctionne encore. Reconstruire devient pertinent lorsque les fondations sont irrécupérables, les accès sont impossibles à rétablir ou le coût de correction dépasse celui d’une base propre.

La décision devrait se prendre sur des preuves : état du code, risque commercial, coût de maintenance et délai acceptable. Elle ne devrait pas dépendre uniquement de la préférence technologique de la nouvelle équipe.

Étape 4 : établir un plan de relance par petits jalons

Un bon plan commence par remettre le projet dans un état déployable et observable. Ensuite, l’équipe traite les parcours critiques : connexion, formulaire, paiement, commande, réservation ou gestion interne. Chaque jalon doit avoir un résultat vérifiable et une démonstration.

Ajoutez progressivement les tests, la documentation, les contrôles de sécurité et la surveillance. Cette méthode évite de passer plusieurs mois à « nettoyer le code » sans remettre de valeur aux utilisateurs.

Les signaux d’alerte à ne pas ignorer

• le code en production n’est pas dans un dépôt accessible ;
• les secrets sont présents dans les fichiers ou les logs ;
• personne ne sait restaurer la base de données ;
• les déploiements sont faits manuellement sans historique ;
• les dépendances sont anciennes et non inventoriées ;
• les objectifs changent sans périmètre ni critères d’acceptation.

Ces signaux ne signifient pas toujours qu’il faut tout jeter. Ils indiquent qu’il faut ralentir, documenter et reprendre la gouvernance du projet.

Comment éviter un second blocage

Définissez la propriété des comptes, les responsabilités, les environnements, les critères de livraison et la procédure de transfert. Demandez une documentation minimale : installation locale, variables d’environnement, architecture, sauvegardes, déploiement et procédures d’urgence.

KCGA accompagne les reprises de projets web et l’assainissement d’architectures. Vous pouvez consulter notre portfolio, puis décrire l’état de votre projet pour commencer par un diagnostic concret.