GET /wp-json/redaction/v1/score/1842. C’est par cette requête que le tableau de bord interne d’une rédaction obtient le détail du score de qualité SEO d’un article, sans passer par une extension commerciale complète dont la salle de rédaction n’utilisait qu’une fraction des fonctionnalités. L’idée de départ : plutôt que d’installer un outil généraliste chargé de dizaines de vérifications inutiles pour ce contexte éditorial, construire un point de terminaison REST sur mesure, focalisé sur cinq critères réellement suivis par les rédacteurs.
Pourquoi un point de terminaison plutôt qu’un calcul côté client
La première tentation, pour ce genre de tableau de bord, consiste à calculer le score directement en JavaScript, dans l’interface d’administration, en lisant le contenu affiché à l’écran. Cette approche pose un problème de cohérence : le score dépendrait alors de l’état du DOM au moment du calcul, potentiellement différent du contenu réellement enregistré en base de données. En centralisant le calcul côté serveur, dans un point de terminaison REST dédié, la même logique sert aussi bien le tableau de bord que d’éventuels scripts d’audit en ligne de commande, sans duplication.
Architecture du point de terminaison
Le point de terminaison s’enregistre classiquement via register_rest_route, sur un espace de noms propre à la rédaction plutôt que sur l’espace wp/v2 réservé aux ressources natives :
add_action( 'rest_api_init', function () {
register_rest_route( 'redaction/v1', '/score/(?P<id>\d+)', array(
'methods' => 'GET',
'callback' => 'redaction_calculer_score_article',
'permission_callback' => function () {
return current_user_can( 'edit_posts' );
},
'args' => array(
'id' => array(
'validate_callback' => function ( $param ) {
return is_numeric( $param );
},
),
),
) );
} );La fonction de calcul elle-même agrège cinq critères simples, chacun pondéré différemment selon son impact estimé : présence et longueur du titre SEO, présence d’une méta-description dans la fourchette recommandée, présence d’au moins un lien interne sortant, longueur du corps de texte, et présence d’un sous-titre H2 contenant l’expression cible déclarée par le rédacteur dans un champ personnalisé.
function redaction_calculer_score_article( WP_REST_Request $request ) {
$post_id = (int) $request['id'];
$post = get_post( $post_id );
if ( ! $post ) {
return new WP_Error( 'introuvable', 'Article introuvable.', array( 'status' => 404 ) );
}
$criteres = array(
'titre_seo' => redaction_verifier_titre( $post ),
'meta_description' => redaction_verifier_meta( $post ),
'lien_interne' => redaction_verifier_maillage( $post ),
'longueur_texte' => redaction_verifier_longueur( $post ),
'sous_titre_cle' => redaction_verifier_sous_titre( $post ),
);
$score = array_sum( array_column( $criteres, 'points' ) );
return rest_ensure_response( array(
'post_id' => $post_id,
'score' => $score,
'criteres' => $criteres,
) );
}Une réponse pensée pour l’interface, pas seulement pour la donnée brute
Chaque critère renvoie non seulement un nombre de points, mais aussi un message explicatif destiné à s’afficher directement dans le tableau de bord : « Méta-description absente » plutôt qu’un simple booléen à interpréter côté client. Cette décision d’architecture déplace la responsabilité de la lisibilité vers le serveur, ce qui évite de dupliquer les messages dans plusieurs vues front-end si le tableau de bord évolue vers une application mobile interne, par exemple.
Ce que cette architecture évite délibérément
- Aucune action d’écriture sur le contenu : le point de terminaison reste strictement en lecture, la modification du contenu passant par les mécanismes habituels de l’éditeur.
- Aucune dépendance à un service externe : tout le calcul s’exécute localement, sans appel réseau sortant, ce qui garantit un temps de réponse stable même hors ligne en environnement de test.
- Aucune duplication de la logique métier entre PHP et JavaScript : le front-end du tableau de bord se contente d’afficher ce que l’API retourne.
Limites assumées de cette approche
Ce score reste volontairement simpliste comparé à l’analyse sémantique fine que proposent certains outils commerciaux, capables d’évaluer la pertinence thématique d’un texte. L’objectif n’était pas de remplacer une analyse éditoriale humaine, mais de donner un signal rapide sur des critères mécaniques que les rédacteurs oublient parfois sous la pression d’un planning de publication chargé.
Un score automatisé n’a de valeur que s’il reste interprétable en un coup d’œil. Dès qu’un rédacteur doit se demander pourquoi le score a baissé, l’outil a manqué son objectif premier.
Pour aller plus loin
Cette architecture, volontairement minimale, montre qu’un point de terminaison REST personnalisé peut remplacer une partie significative des fonctionnalités d’une extension SEO généraliste, pour un coût de maintenance réduit et une logique entièrement compréhensible par l’équipe technique interne. Elle s’adresse toutefois à des organisations disposant des ressources pour maintenir ce code dans la durée, un arbitrage à poser clairement avant de s’engager dans cette voie plutôt que dans une solution prête à l’emploi.
