Le prestataire ne répond plus. Le chantier a six mois de retard et chaque livraison casse quelque chose. Ou le site est en ligne, mais personne n’ose plus y toucher de peur de tout faire tomber. Les projets web mal partis se ressemblent tous par un point : le client a perdu la visibilité, puis la confiance. La bonne nouvelle, c’est qu’un sauvetage bien mené coûte presque toujours moins cher qu’une reconstruction complète. Voici notre méthode.
Reconnaître un projet à sauver
Quelques symptômes reviennent systématiquement : les délais glissent sans explication claire, chaque correction fait apparaître deux nouveaux problèmes, la documentation est inexistante, les accès (serveur, domaine, code source) sont éparpillés ou retenus par le prestataire, et plus personne ne sait dire précisément ce qui est terminé et ce qui ne l’est pas.
Aucun de ces symptômes ne dit que le code est irrécupérable. Ils disent que le projet n’est plus piloté. Ce sont deux problèmes différents, et le second se règle plus vite qu’on ne le croit.
Étape 1 : récupérer les clés
Avant tout diagnostic, il faut réunir ce qui vous appartient : le code source et son historique, les accès à l’hébergement et à la base de données, le nom de domaine (vérifiez que vous en êtes bien titulaire), les comptes tiers (emails, paiement, API). Cette étape est parfois délicate quand la relation avec le prestataire sortant s’est tendue, mais elle est non négociable : on ne soigne pas un patient qu’on ne peut pas examiner.
Étape 2 : auditer froidement
L’audit répond à trois questions, dans cet ordre. Qu’est-ce qui fonctionne réellement en production ? Quel est l’état du code : architecture saine mais inachevée, ou fondations à risque ? Et où sont les dangers immédiats : failles de sécurité, absence de sauvegardes, dépendances abandonnées ?
Le livrable est une carte honnête du projet, avec les risques classés par priorité. C’est souvent la première fois depuis des mois que le client voit son projet en face, sans filtre commercial.
Étape 3 : stabiliser avant d’évoluer
L’erreur classique du sauvetage est de vouloir rattraper le retard fonctionnel immédiatement. Nous faisons l’inverse : d’abord sécuriser (sauvegardes, mises à jour critiques, accès), ensuite fiabiliser ce qui existe, et seulement après reprendre les évolutions. Un chantier stabilisé avance ensuite deux fois plus vite qu’un chantier où chaque nouveauté s’écroule sur des fondations mouvantes.
Étape 4 : remettre un pilotage en place
Le sauvetage technique ne tient que s’il s’accompagne d’un pilotage clair : un périmètre écrit, des livraisons courtes et vérifiables, et un point d’avancement régulier où l’on montre ce qui tourne, pas des promesses. C’est ainsi que la confiance se reconstruit, livraison après livraison.
Deux sauvetages, deux échelles
L’association Parentalité Jeunesse est arrivée avec un site WordPress fragile et inutilisable au quotidien : nous l’avons stabilisé, nettoyé et optimisé, sans lui vendre la refonte complète qu’elle redoutait. À l’autre bout du spectre, Finaxy Group nous a confié la reprise et la maintenance d’un logiciel métier Java critique que nous n’avions pas développé : audit, sécurisation, puis TMA en production depuis.
Deux tailles de projet, une même méthode : reprendre les clés, auditer, stabiliser, piloter.
Votre projet est mal parti ?
Plus le sauvetage démarre tôt, moins il coûte. Décrivez-nous la situation, même confuse, même sans accès complets : le premier échange sert justement à y voir clair, sans jugement sur ce qui s’est passé avant.
