Le site est en panne, et celui qui l'a construit est parti.
Voici comment arrêter l'hémorragie.
Le site marchait hier. Aujourd'hui il affiche une erreur, et la seule personne qui comprenait sa construction ne répond plus. Chaque heure de panne coûte des ventes, le premier réflexe est donc le tri, pas la panique.
Le tri d’abord, le diagnostic ensuite
Quand un site est en panne et ne rapporte rien, l’envie de tout réparer d’un coup se comprend, et c’est en général le mauvais réflexe. La première heure devrait écarter les causes banales, parce qu’elles sont fréquentes et vite réparées. Un domaine expiré. Une facture d’hébergement impayée. Un certificat SSL discrètement expiré. Une mise à jour de plugin qui a cassé sur son propre calendrier. Une bonne part des cas “le développeur a disparu, le site est en panne” se révèle être exactement ça, pas un problème de code profond.
Ce que cherche un vrai audit
Si les causes banales sont écartées, l’étape suivante est de lire le code et le serveur eux-mêmes. Ce qui a changé juste avant la panne. Ce que disent vraiment les journaux d’erreur. Si le problème est dans le code applicatif, une base de données, une intégration tierce, ou la configuration serveur. Pour un site de taille normale, ça prend en général des jours, pas des semaines. Ça se termine par une liste écrite de ce qui est cassé, classée par ce qui coûte vraiment de l’argent plutôt que ce qui est juste désordonné.
Réparer sans tout reconstruire
La plupart des sites qui cassent après le départ d’un développeur n’ont pas besoin d’une réécriture. Ils ont besoin que la partie cassée précise soit réparée, et le reste du système laissé tranquille. Une réécriture jette tout ce qui fonctionnait déjà, et remplace une panne connue par des mois de nouveau risque. Reconstruire n’a de sens que là où l’audit montre vraiment que c’est plus rentable. C’est une décision basée sur des vrais chiffres, pas une réponse par défaut.
Pourquoi “personne ne comprend le code” se résout
Un site sans documentation semble irrécupérable, mais le code lui-même explique presque toujours ce qu’il fait, à qui le lit attentivement. La structure de la base de données. Comment les pages se génèrent. À quoi sert chaque intégration. Tout ça se découvre sans le développeur d’origine, juste plus lentement qu’avec ses notes. Une fois la panne résolue, la vraie solution est d’écrire ce qui a été trouvé, pour que la prochaine personne ne reparte pas de zéro.
Sortir du mode “une personne de la prochaine panne”
Une fois le site de retour en ligne, réparez ce qui a permis à une seule disparition de mettre toute l’entreprise hors ligne. Un accès hébergement et domaine que l’entreprise contrôle directement. Une seconde personne capable au moins de vérifier si le site est vivant. Une documentation de la construction du système. Rien de tout ça n’empêche chaque futur problème. Ça transforme la prochaine panne en une heure de gêne, plutôt qu’en crise où personne ne peut se connecter.
Quoi faire dans l'heure qui suit
- 01
Vérifiez d'abord les causes banales : domaine expiré, facture d'hébergement impayée, certificat SSL expiré.
- 02
Essayez de contacter directement l'hébergeur ou le registrar. Ils confirment souvent la vraie cause plus vite qu'une supposition.
- 03
Notez exactement le message d'erreur et le moment où le problème a commencé, avec une capture d'écran si possible.
- 04
Ne touchez pas à un panneau admin que vous ne comprenez pas complètement. Une supposition sous pression peut aggraver les choses.
Quand nous appeler
Appelez-nous si le site est en panne et perd des ventes chaque heure, ou que personne ne trouve d'accès qui fonctionne. Aussi si un premier regard suggère un vrai débogage. Obtenir un plan gratuit →
FAQ
À quelle vitesse pouvez-vous vraiment remettre un site en ligne ?
Ça dépend entièrement de la cause. Un domaine expiré ou une facture d'hébergement impayée se résolvent en quelques heures une fois l'accès réglé. Un vrai problème de code demande d'abord un regard honnête dans les premiers jours, avant qu'on donne un délai.
Avez-vous besoin de l'ancien développeur ?
Non. Nous lisons le code et la configuration serveur nous-mêmes. Quelques réponses de l'ancien développeur aideraient, mais une disparition est exactement la situation pour laquelle ce service existe.
Allez-vous tout réécrire ?
Pas par défaut. Nous réparons d'abord ce qui est cassé dans le code existant et le stabilisons. Une réécriture complète seulement là où l'audit montre que c'est vraiment plus rentable, et nous le disons par écrit avant de le recommander.
Que se passe-t-il une fois le site de retour en ligne ?
Nous documentons comment le système fonctionne vraiment et transmettons des instructions claires. Le code devient le vôtre au paiement, comme le fixe l'accord, avec un accès en lecture dès le premier jour.