Reprendre un site abandonné par son prestataire

Pas d'accès, pas de dépôt, pas de documentation. La méthode d'audit que j'applique avant de dire si on répare ou si on refait.

Le cas typique

Le prestataire ne répond plus. Personne ne sait où est le code. Le site tourne encore, et c'est bien le problème : tant qu'il tourne, rien n'oblige à agir — jusqu'au jour où il ne tourne plus.

Voici l'ordre dans lequel je procède. Il ne varie pas, parce que chaque étape conditionne la suivante.

1. Les clés avant le code

Un site, ce n'est pas seulement des fichiers. Avant de regarder une ligne de PHP, j'établis qui détient quoi :

• le nom de domaine, chez quel bureau d'enregistrement, à quel nom, et quand il expire
• les serveurs de noms : qui pilote réellement le DNS
• l'hébergement : accès SSH ou FTP, panneau d'administration
• les certificats et leur renouvellement automatique
• les comptes tiers : paiement, transporteurs, messagerie

C'est la partie la plus ingrate et la plus urgente. Un domaine qui expire pendant qu'on discute du budget coûte plus cher que la refonte.

2. Versionner immédiatement

S'il n'y a pas de dépôt, je récupère l'existant et je le mets sous Git le jour même, avant toute modification. Le premier commit s'appelle « état trouvé ». Il ne sert à rien d'autre qu'à pouvoir répondre, plus tard, à la question « c'était comme ça avant ? ».

Même chose pour la base : un export daté, stocké ailleurs que sur le serveur.

3. L'audit, en quatre passes

Technique. Versions de PHP, du CMS ou du framework, des dépendances. Ce qui n'est plus maintenu. Ce qui empêche de monter de version.

Sécurité. C'est là que les surprises arrivent. Sur un audit récent, un module maison lisait un identifiant dans l'URL et l'injectait tel quel dans une requête de suppression — sans échappement ni conversion en entier. Il fallait une session d'employé pour l'exploiter, donc pas de panique publique ; mais n'importe quel compte, même limité, pouvait lire toute la base. Ce genre de chose ne se voit qu'en lisant le code.

Référencement. Redirections en 302 là où il fallait des 301, balises vides, sous-domaines entièrement indexables qui dupliquent le contenu principal. Ce sont des corrections rapides et des gains immédiats.

Performance. Temps de réponse, images non redimensionnées, absence de cache.

4. Décider : réparer, faire évoluer, refaire

La question n'est pas « le code est-il beau », mais « peut-on encore le faire évoluer sans risque ». Un site laid mais sain se répare. Un site élégant dont personne ne comprend la logique métier se refait.

Je rends l'audit sous la forme d'un document lisible par un non-technicien : ce qui va, ce qui coûte de l'argent aujourd'hui, ce qui deviendra bloquant, et dans quel ordre corriger. Avec les coûts en face. Le client décide ensuite, y compris de ne rien faire.

Ce que je refuse

Reprendre un site sans audit. Ce serait s'engager sur un contenu qu'on n'a pas regardé, et hériter d'une dette qu'on n'a pas mesurée. C'est aussi pour ça que l'audit est gratuit chez moi : il protège autant celui qui le reçoit que celui qui l'écrit.