Le 15 juin 2023, un développeur récupère l’accès à un tableau de bord d’hébergement pour un projet headless dont la précédente agence a cessé toute activité sans laisser le moindre document technique. Aucun schéma de routes, aucune liste de webhooks, aucun inventaire des clés d’API en circulation. Le contrat de maintenance stipule pourtant que le projet doit continuer à fonctionner sans interruption.
Cette situation, plus fréquente qu’on ne le pense sur les projets headless confiés à des prestataires successifs, impose une méthode de reprise différente de celle d’un site WordPress classique. Là où un thème seul se lit intégralement dans un dossier, un projet découplé disperse ses secrets et ses automatismes entre plusieurs plateformes, parfois invisibles depuis le seul code source récupéré.
Étape 1 : cartographier les identités applicatives
La première étape consiste à lister l’ensemble des mots de passe d’application actifs, via le tableau Utilisateurs → Profil de chaque compte administrateur, ou directement en base dans wp_usermeta sous la clé _application_passwords. Chaque entrée représente un accès potentiellement encore utilisé par un service externe dont plus personne dans l’équipe actuelle ne connaît l’existence.
wp user meta get 3 _application_passwords --format=json \
| php -r "print_r(json_decode(file_get_contents('php://stdin'), true));"Étape 2 : retrouver les webhooks enregistrés
Un webhook déclenché depuis WordPress vers un service tiers ne figure dans aucune interface native : il provient presque toujours d’un hook personnalisé accroché à save_post, transition_post_status ou un événement équivalent, dans du code de thème ou d’extension maison. Une recherche systématique dans le code déployé permet d’en dresser la liste :
grep -rn "wp_remote_post" wp-content/themes wp-content/plugins \
--include="*.php" | grep -i "hook\|http"
Chaque URL trouvée mérite d’être vérifiée individuellement : répond-elle encore ? Appartient-elle à un service encore facturé, ou à un compte de test abandonné depuis longtemps ? Un webhook qui pointe vers une plateforme de reconstruction du front toujours active, mais dont personne ne surveille plus les échecs, représente un risque silencieux : le contenu continue d’être publié côté WordPress sans que le front ne se mette réellement à jour.
Étape 3 : inventorier les clés côté front
Si l’accès au dépôt du front est disponible, les fichiers d’environnement méritent une attention particulière, en gardant à l’esprit qu’un fichier .env committé par erreur dans l’historique d’un dépôt Git reste consultable même après suppression du fichier courant.
- Vérifier la présence de clés dans l’historique complet du dépôt, pas seulement dans son état courant.
- Comparer les variables d’environnement déclarées côté plateforme d’hébergement du front avec celles réellement utilisées dans le code.
- Identifier les jetons dont la date de dernière rotation dépasse largement la durée de vie recommandée par le service émetteur.
Étape 4 : la rotation complète, sans exception
Une fois l’inventaire dressé, la tentation est grande de ne renouveler que les clés jugées sensibles. Cette approche laisse toujours un oubli possible. La méthode la plus sûre consiste à révoquer systématiquement chaque mot de passe d’application, chaque jeton d’API et chaque secret de webhook découvert, puis à recréer un jeu de clés entièrement nouveau, en vérifiant une par une les intégrations qui cessent de fonctionner : c’est justement ce test négatif qui confirme qu’aucun usage actif n’a été oublié.
wp user application-password delete 3 --all
wp user application-password create 3 "integration-front-2023"Étape 5 : documenter pour la prochaine reprise
Reconstituer un inventaire à l’aveugle prend un temps disproportionné par rapport à sa rédaction initiale. Un document minimal — liste des webhooks actifs avec leur destination, liste des intégrations tierces avec leur usage, procédure de rotation des secrets — protège la prochaine personne qui héritera du projet, y compris soi-même dans deux ans.
Un projet sans documentation ne signifie pas un projet sans secrets actifs. Il signifie seulement que ces secrets attendent d’être découverts par la première personne suffisamment méthodique pour les chercher.
Pour aller plus loin
La documentation officielle sur les mots de passe d’application, disponible sur developer.wordpress.org, détaille leur cycle de vie complet. Elle ne remplace toutefois pas une méthode de reprise rigoureuse : sur un projet headless, l’absence de schéma écrit des routes et des automatismes actifs constitue en soi un risque de sécurité qu’aucune extension ne peut combler après coup.
