« 404 : cette page n’existe pas. » C’est le seul message que recevait la nouvelle chargée de communication d’une coopérative de producteurs maraîchers en tentant de retrouver l’ancien front de son site vitrine, plusieurs mois après le départ sans transition du prestataire qui l’avait développé. Le WordPress d’origine, lui, tournait toujours, silencieusement, sur un hébergement dont personne dans la coopérative ne connaissait plus les identifiants exacts.
Le WordPress exposait une API REST manifestement construite sur mesure, avec plusieurs espaces de noms personnalisés visibles dans la racine de l’API, mais aucun dépôt de code, aucune documentation, et aucun contact chez l’ancien prestataire, disparu de tout registre professionnel consultable. La mission confiée consistait à reconstruire un front fonctionnel à partir de ce seul WordPress, sans repartir de zéro sur le contenu déjà accumulé au fil des années.
Symptôme : un WordPress qui parle dans le vide
La première observation a été simple : le WordPress répondait normalement à des requêtes sur /wp-json/, révélant plusieurs routes personnalisées comme /wp-json/maraichers/v2/producteurs ou /wp-json/maraichers/v2/paniers-hebdo. Mais aucun domaine public n’affichait quoi que ce soit d’exploitable : l’ancien nom de domaine du front avait expiré et été racheté par un tiers, qui y affichait désormais une page de parking publicitaire.
Diagnostic : remonter le fil par les logs d’accès
Sans documentation, la seule source fiable pour comprendre ce que le front consommait réellement était le journal d’accès du serveur WordPress. En filtrant les entrées correspondant aux requêtes vers /wp-json/maraichers/v2/ sur les six derniers mois avant la coupure, un schéma s’est dégagé : certains endpoints recevaient des appels réguliers jusqu’à une date précise, d’autres n’apparaissaient plus depuis bien plus longtemps, signe qu’ils avaient probablement été abandonnés avant même la disparition du prestataire.
grep "wp-json/maraichers/v2" /var/log/apache2/access.log* \
| awk '{print $7}' \
| sort | uniq -c | sort -rnCette analyse a permis de distinguer trois catégories d’endpoints : ceux activement appelés jusqu’à la fin (producteurs, paniers de la semaine, points de retrait), ceux appelés sporadiquement (une page d’archive de recettes, visiblement peu consultée), et ceux qui n’apparaissaient plus dans les six mois de logs disponibles, probablement des vestiges d’une version antérieure du front jamais nettoyés côté API.
Correctif : reconstruire endpoint par endpoint, en confirmant l’usage
Plutôt que de reconstruire un front complet en une seule fois en supposant la pertinence de chaque endpoint découvert, la reconstruction s’est faite par étapes, chaque endpoint n’étant intégré au nouveau front qu’après confirmation avec la coopérative qu’il correspondait bien à un contenu encore utile aujourd’hui.
L’ordre de reconstruction retenu
- Les points de retrait des paniers, endpoint le plus appelé dans les logs et confirmé comme prioritaire par la coopérative
- La liste des producteurs membres, avec leurs fiches individuelles
- Le panier hebdomadaire, dont la structure de données a nécessité une relecture attentive pour comprendre le format de dates utilisé, non documenté nulle part
- L’archive de recettes, ajoutée en dernier, une fois confirmé qu’elle restait consultée malgré son faible volume d’appels
Les endpoints sans trace d’appel récent n’ont volontairement pas été reconstruits dans le nouveau front, la coopérative confirmant qu’ils correspondaient à une ancienne section du site abandonnée avant même le départ du prestataire.
Sans documentation, les logs d’accès ne mentent pas : ils disent exactement ce qu’un système faisait vraiment, pas ce qu’il était censé faire selon un cahier des charges disparu avec son auteur.
Prévention : une documentation minimale, mais réelle
Un fichier README a été ajouté à la racine du projet WordPress, listant chaque endpoint personnalisé, son rôle, et le front qui le consomme, avec la date de sa dernière modification connue. Ce n’est pas une documentation exhaustive, mais elle garantit qu’une prochaine reprise, si elle devait arriver, ne partirait pas d’une page blanche comme celle-ci.
Ce que ce fichier contient
- La liste des espaces de noms REST actifs, avec un exemple de requête pour chacun
- Le nom du front actuel et l’adresse de son dépôt de code
- Un contact interne à la coopérative, désormais responsable de la relation avec le prestataire technique en charge de la maintenance
Ce que cette reprise n’a pas traité
La sécurité du WordPress d’origine, resté sans mise à jour pendant plusieurs mois avant la reprise, n’a pas été auditée dans le cadre de cette mission précise. Une intervention distincte a été programmée pour ce volet, la priorité immédiate étant de redonner à la coopérative un front fonctionnel avant de traiter les questions de sécurité de fond.
Ce qu’il faut retenir
Reprendre un headless abandonné sans documentation n’est pas une fatalité, à condition d’accepter de reconstruire lentement, endpoint confirmé après endpoint confirmé, plutôt que de tout redévelopper d’un bloc en supposant que chaque route découverte a encore un sens aujourd’hui. Les logs d’accès, souvent négligés, se sont révélés être la seule source d’information fiable dans ce projet.
