# Un projet headless livré sans la moindre documentation : par où commencer > Aucun schéma d'architecture, aucun README, aucune trace des choix passés : c'est le point de départ le plus courant à la reprise d'un projet headless existant. Une liste pour s'y retrouver. - Auteur : WordPress Développement - Publié le : 2022-08-10 - Mis à jour le : 2022-08-10 - Catégorie : Headless & API - URL : https://www.wpmoderne.fr/headless/projet-headless-livre-sans-documentation-par-ou-commencer/ ## L’essentiel - Cartographier d'abord les routes réellement appelées par le front - Comparer les extensions actives à celles réellement utilisées dans le code - Consigner chaque découverte au fur et à mesure, pas à la fin Aucun schéma d'architecture, aucun fichier README à jour, aucune trace écrite des choix techniques passés : c'est le point de départ le plus courant lorsqu'un développeur reprend un projet headless existant sans que son auteur d'origine ne soit encore joignable. Cette liste commentée décrit l'ordre dans lequel mener l'exploration, pour éviter de perdre des jours sur de fausses pistes. L'objectif n'est pas de tout comprendre en une seule fois, mais de reconstituer progressivement une vision suffisante pour intervenir sans casser un mécanisme invisible au premier regard. ## 1. Identifier les routes réellement consommées par le front Avant même d'ouvrir le code WordPress, observer les requêtes réseau émises par le front en fonctionnement donne une image fidèle de ce qui est réellement utilisé, contrairement au code source qui peut contenir des routes obsolètes jamais nettoyées. - Ouvrir l'onglet réseau du navigateur sur chaque écran principal du front - Noter chaque route appelée, avec ses paramètres récurrents - Repérer les routes natives de WordPress utilisées telles quelles, sans surcouche personnalisée ## 2. Recenser les extensions actives et leur usage réel La commande `wp plugin list` donne la liste complète des extensions actives, mais ne dit rien de leur utilité réelle. Un grep sur le code du thème ou des extensions maison permet de vérifier si une extension listée est réellement appelée quelque part : ``` $ wp plugin list --status=active --format=csv $ grep -r "wpgraphql" wp-content/themes wp-content/plugins/mon-plugin-maison ``` > L'essentiel à retenir : Cartographier d'abord les routes réellement appelées par le front ; Comparer les extensions actives à celles réellement utilisées dans le code ; Consigner chaque découverte au fur et à mesure, pas à la fin ## 3. Vérifier les tâches cron planifiées Un projet headless dépend presque toujours d'au moins une tâche cron pour déclencher un rebuild ou une synchronisation. `wp cron event list` révèle les hooks planifiés, dont certains portent parfois des noms hérités d'une extension depuis longtemps désactivée, signe d'un nettoyage jamais fait. ## 4. Comparer la base de données aux types de contenus déclarés Une table de métadonnées volumineuse pour un type de contenu qui n'apparaît plus dans aucune route consommée par le front signale souvent un ancien module abandonné en cours de route, dont les données dorment sans utilité actuelle, ni supprimées ni documentées. ### Questions à se poser à ce stade 1. Ce type de contenu est-il encore alimenté par une saisie éditoriale active ? 2. Une route REST l'expose-t-elle encore, même sans être appelée actuellement par le front ? 3. Sa suppression aurait-elle un impact identifiable sur un système externe ? ## 5. Vérifier les identifiants et secrets encore valides Un fichier `.env` ou un `wp-config.php` ancien contient parfois des identifiants de services tiers encore actifs, parfois liés à un compte personnel de l'ancien développeur plutôt qu'à un compte de l'entreprise cliente. Faire l'inventaire de ces identifiants, puis vérifier avec le client s'ils doivent être régénérés, évite une dépendance silencieuse à une personne qui n'est plus joignable. ## 6. Consigner chaque découverte au fur et à mesure Un fichier de notes, même sommaire, ouvert dès la première heure d'exploration, évite de refaire deux fois le même travail d'investigation quelques semaines plus tard, lorsque la mémoire des détails techniques s'est déjà estompée. > La documentation la plus utile sur un projet repris sans notes, c'est celle qu'on commence à écrire soi-même dès le premier jour, pas celle qu'on espère retrouver quelque part. ## Ne pas corriger avant d'avoir compris La tentation la plus fréquente, face à un code qui semble maladroit, consiste à le corriger immédiatement. Sur un projet sans documentation, cette précipitation est risquée : une construction qui paraît étrange au premier regard répond parfois à une contrainte réelle du client, oubliée depuis, mais toujours valable. Une correction hâtive peut ainsi réintroduire un problème que l'ancien développeur avait justement réglé de cette façon. ## En résumé Reprendre un projet headless sans documentation demande une méthode d'exploration progressive : observer le trafic réel du front, croiser les extensions actives avec leur usage effectif, vérifier les tâches planifiées, puis confronter la base de données aux types de contenus réellement exploités. Cette liste ne couvre pas la refonte du front lui-même, qui suppose des enjeux et des priorités différents une fois la partie WordPress correctement cartographiée.