« Le site tourne encore, mais personne n’y a touché depuis deux ans. » Cette phrase revient souvent chez les intégrateurs qui héritent d’un projet headless sans documentation ni suivi, sans être eux-mêmes développeurs capables de relire chaque ligne du front React ou Vue laissé en place. Sans compétence de code approfondie, l’intégrateur peut pourtant mener seul une grande partie du diagnostic initial, à condition de suivre un ordre précis plutôt que de corriger au hasard ce qui saute aux yeux.
Voici la liste, commentée, des quatorze vérifications qui structurent ce type d’audit, dans l’ordre où elles doivent être menées.
Ce qu’il faut vérifier côté WordPress, sans toucher au front
- Version de WordPress installée, comparée à la dernière version stable disponible, visible directement dans le tableau de bord d’administration.
- Mises à jour de sécurité automatiques activées, ce que WordPress gère nativement depuis la version 5.5 pour les correctifs mineurs, sauf si une configuration a désactivé cette fonctionnalité.
- Liste des extensions actives, avec une attention particulière à celles qui n’ont reçu aucune mise à jour depuis plus d’un an, un signal fort d’abandon par leur auteur.
- Comptes utilisateurs existants, en particulier ceux avec un rôle administrateur qui ne correspondent plus à personne dans l’organisation actuelle.
- Jetons ou mots de passe d’application actifs, à réconcilier avec les services qui les utilisent réellement aujourd’hui.
Ce qu’il faut vérifier côté API, sans lire le code du front
- Accessibilité de l’API REST depuis l’extérieur, testée simplement avec un appel
curlvers l’endpoint racine du site. - Routes exposées publiquement, en vérifiant qu’aucune route sensible (comme celle des utilisateurs) ne renvoie d’information nominative sans authentification.
- Temps de réponse de l’API, mesuré à plusieurs heures de la journée, pour repérer une dégradation progressive passée inaperçue.
- Certificat de sécurité du domaine, sa date d’expiration et son renouvellement automatique ou non.
Ce qu’il faut vérifier côté front, même sans lire le code
- Le site s’affiche-t-il correctement sur les principaux navigateurs actuels, testé simplement à l’œil, page par page ?
- Les liens internes fonctionnent-ils tous, ou certains renvoient-ils vers des pages disparues, signe d’un contenu supprimé côté WordPress sans mise à jour du front ?
- Le formulaire de contact envoie-t-il réellement un message, testé avec un envoi réel plutôt que supposé fonctionnel ?
- L’hébergement du front est-il toujours facturé et actif, en particulier s’il s’agit d’un service tiers dont l’abonnement peut expirer sans alerte visible ?
- Existe-t-il une sauvegarde récente, à la fois du contenu WordPress et du code du front, avant toute intervention corrective ?
Ce que cette checklist ne remplace pas
Cet audit initial ne dispense pas d’un diagnostic de code plus poussé si des anomalies sérieuses apparaissent : une dépendance front avec une faille de sécurité connue, par exemple, nécessite l’intervention d’un développeur capable de la mettre à jour sans casser le reste de l’application. Cette checklist sert à décider s’il faut aller plus loin, pas à s’y substituer.
Prioriser sans se disperser
Face à quatorze points, la tentation est de vouloir tout corriger en même temps. La priorité doit toujours aller aux failles de sécurité identifiées (mises à jour manquantes, comptes fantômes, jetons oubliés) avant toute amélioration esthétique ou fonctionnelle, aussi tentante soit-elle une fois qu’on commence à explorer le projet.
Un projet abandonné ne demande pas un miracle technique, il demande d’abord qu’on sache exactement ce qui tourne encore et ce qui ne tourne plus.
Quand faire appel à un développeur devient indispensable
Certains signaux, découverts lors de cette checklist, dépassent clairement les compétences d’un intégrateur non codeur : une dépendance front associée à une faille de sécurité publiquement documentée, un certificat de sécurité expiré depuis plusieurs semaines sans renouvellement automatique fonctionnel, ou une route d’API exposant sans le vouloir des données personnelles. Face à l’un de ces signaux, la bonne décision consiste à arrêter l’audit à ce stade et à solliciter un développeur, plutôt que de tenter une correction sans en mesurer complètement les conséquences.
En résumé
Un intégrateur non codeur peut mener seul le plus gros de ce diagnostic initial, à condition de procéder par étapes et de prioriser systématiquement la sécurité avant la refonte graphique, qui reste un chantier distinct à budgéter séparément.
