# Stabiliser le headless expérimental laissé par un alternant chez un notaire > Une étude notariale doit stabiliser un projet headless expérimental laissé par un stagiaire parti, sans budget pour tout reconstruire depuis zéro. - Auteur : Clément Hadrot - Publié le : 2025-12-11 - Mis à jour le : 2025-12-11 - Catégorie : Headless & API - URL : https://wpmoderne.dev.wordpress-developpement.fr/headless/stabiliser-headless-experimental-alternant-notaire/ ## L’essentiel - Documenter d'abord ce qui existe avant de corriger quoi que ce soit - Isoler les dépendances non maintenues plutôt que les supprimer d'un coup - Prioriser la stabilité avant toute nouvelle fonctionnalité « Ça marchait très bien avant qu'il parte. » Cette phrase, prononcée par l'associé d'une étude notariale à propos du site vitrine de l'étude, précède presque toujours une découverte moins réjouissante : le front React consommant l'API REST de WordPress avait été monté par un alternant en fin de cursus, parti sans documentation, sans schéma d'architecture, et avec un dépôt Git dont le dernier commit remontait à plus d'un an. L'étude ne disposait d'aucun budget pour une refonte complète, seulement de quelques heures facturées ponctuellement à un développeur extérieur pour éviter que le site ne s'arrête de fonctionner. La mission n'était donc pas d'améliorer le projet, mais de le stabiliser suffisamment pour qu'il tienne encore quelques années sans surprise. ## Première étape : cartographier avant de toucher au code Avant tout correctif, la priorité a été de comprendre ce qui existait réellement. Un inventaire simple, mené en une demi-journée, a permis de lister les dépendances du projet front, leur version installée, et leur dernière mise à jour publiée en amont. Cette étape, souvent négligée par impatience de corriger, évite de casser une pièce du projet dont personne ne connaît encore le rôle exact. ``` npm outdated npm ls --depth=0 ``` Sur ce projet, six dépendances majeures n'avaient reçu aucune mise à jour depuis plus de dix-huit mois, dont le framework de rendu front lui-même, resté figé sur une version antérieure à plusieurs correctifs de sécurité connus. ## Isoler plutôt que supprimer > L'essentiel à retenir : Documenter d'abord ce qui existe avant de corriger quoi que ce soit ; Isoler les dépendances non maintenues plutôt que les supprimer d'un coup ; Prioriser la stabilité avant toute nouvelle fonctionnalité La tentation, face à une dépendance obsolète, est de la supprimer immédiatement. Mais sans tests automatisés (le projet n'en contenait aucun) et sans documentation des choix initiaux, une suppression brutale risque de casser une fonctionnalité invisible en apparence, comme un composant de mise en cache local ou une gestion spécifique des erreurs réseau vers l'API REST. La méthode retenue a consisté à isoler chaque dépendance suspecte derrière une interface simple, testée manuellement fonctionnalité par fonctionnalité, avant tout remplacement. ## Vérifier que l'API REST elle-même n'avait pas dérivé Le WordPress derrière ce front avait continué à recevoir des mises à jour automatiques de sécurité, activées par défaut depuis WordPress 5.5, sans que personne ne surveille si ces mises à jour modifiaient la forme des réponses de l'API REST. Une comparaison, endpoint par endpoint, entre la documentation retrouvée dans un ancien fichier README abandonné et le comportement réel de l'API a révélé un champ personnalisé renommé sans que le front n'en tienne compte, provoquant un affichage vide silencieux sur une section secondaire du site. - Comparer chaque endpoint utilisé par le front avec sa réponse réelle actuelle. - Vérifier les journaux d'erreurs du serveur pour repérer les appels API qui échouent silencieusement côté front. - Documenter, au fur et à mesure, chaque découverte dans un fichier simple, pour que la prochaine intervention ne reparte pas de zéro. ## Ce qui n'a volontairement pas été touché Le design visuel du site, jugé daté mais fonctionnel, n'a fait l'objet d'aucune intervention : ce n'était pas l'urgence, et l'étude n'avait pas budgété une refonte graphique. La priorité absolue est restée la stabilité technique, la sécurité des dépendances critiques, et la fiabilité du lien entre le front et l'API REST. ## Ce que cette reprise a coûté, en heures Douze heures de travail ont suffi à cartographier le projet, isoler les dépendances les plus risquées, mettre à jour celles qui pouvaient l'être sans casse visible, et documenter le tout pour la prochaine personne qui interviendra. Un budget bien plus modeste qu'une refonte complète, pour un résultat qui tient la route sans promettre l'excellence. > Un projet abandonné n'a pas besoin d'un héros qui reconstruit tout : il a besoin de quelqu'un qui prend le temps de comprendre avant de corriger. ## Ce que l'étude a retenu de cette expérience Au-delà du correctif technique, l'associé de l'étude a retenu une leçon organisationnelle : confier un projet destiné à durer à une personne en fin de contrat, sans prévoir de passation ni de documentation minimale, revient à accepter un risque de dette technique différée. Pour la suite, l'étude a demandé au développeur externe un court document de passation à chaque intervention, même mineure, afin qu'une future reprise ne reparte plus jamais de zéro comme celle-ci a dû le faire. ## En résumé Stabiliser un projet headless hérité sans documentation demande de la méthode plus que de la vitesse : cartographier, isoler, vérifier la cohérence entre front et API, puis documenter, dans cet ordre, avant même de penser à améliorer quoi que ce soit.