# Remplacer le module de commentaires WordPress par une solution tierce

> Plutôt que de reproduire l'API des commentaires WordPress côté front, retour d'expérience sur l'intégration de Cusdis dans un projet headless, plus léger qu'attendu.

- Auteur : Clément Hadrot
- Publié le : 2022-04-28
- Mis à jour le : 2022-04-28
- Catégorie : Headless & API
- URL : https://wpmoderne.dev.wordpress-developpement.fr/headless/remplacer-commentaires-wordpress-disqus-cusdis-headless/

## L’essentiel

- Reproduire l'API des commentaires coûtait plus cher que prévu
- Cusdis a demandé une demi-journée d'intégration
- La modération est restée entièrement côté service tiers

Sur un blog culinaire consommant WordPress en headless via Nuxt, le client tenait à conserver une fonctionnalité de commentaires sous les articles, comme sur son ancien site. L'estimation initiale pour reproduire fidèlement le système de commentaires natif de WordPress, avec l'API REST, la gestion des réponses imbriquées et la modération, dépassait quatre jours de développement. Ce retour d'expérience explique pourquoi nous avons finalement opté pour un service tiers, et lequel.

Cet article ne traite pas l'affichage des commentaires natifs WordPress via l'API REST, un sujet distinct déjà couvert ailleurs sur ce blog pour les projets où cette option reste pertinente.

## Pourquoi reproduire les commentaires natifs coûtait cher

L'API REST de WordPress expose bien un point de terminaison `/wp-json/wp/v2/comments`, capable de lister et de créer des commentaires. Le problème ne venait pas de la lecture, simple à mettre en œuvre, mais de l'écriture : la création d'un commentaire anonyme nécessite de gérer soi-même la protection anti-spam, l'envoi de notification par email à l'auteur de l'article, la modération manuelle depuis l'administration, et l'affichage correct des réponses imbriquées. Reproduire cet ensemble côté front, avec un niveau de fiabilité comparable à ce qu'offre nativement WordPress avec Akismet, représentait un investissement disproportionné pour un blog qui recevait, en moyenne, une trentaine de commentaires par mois.

## Le choix entre Disqus et Cusdis

Deux services ont été comparés avant de trancher. Disqus, solution ancienne et largement répandue, impose l'affichage de publicités sur son offre gratuite et charge un script tiers assez lourd, ce qui posait un problème direct sur un projet où la performance de chargement faisait partie des exigences contractuelles du client. Cusdis, plus récent et open source, propose un script beaucoup plus léger, sans publicité, avec une interface de modération minimaliste mais suffisante pour le volume de commentaires du site.

> L'essentiel à retenir : Reproduire l'API des commentaires coûtait plus cher que prévu ; Cusdis a demandé une demi-journée d'intégration ; La modération est restée entièrement côté service tiers

## L'intégration réalisée avec Cusdis

Cusdis fonctionne par simple intégration d'un script et d'une balise dédiée, sans nécessiter d'appel à l'API REST de WordPress pour cette fonctionnalité précise :

```
<div
  id="cusdis_thread"
  data-host="https://cusdis.com"
  data-app-id="votre-app-id"
  data-page-id="{{ article.slug }}"
  data-page-url="https://exemple.fr/blog/{{ article.slug }}"
  data-page-title="{{ article.title }}"
></div>
<script async defer src="https://cusdis.com/js/cusdis.es.js"></script>
```

Le `data-page-id` correspond au slug de l'article WordPress, ce qui permet de faire cohabiter la source de contenu (WordPress) et le stockage des commentaires (Cusdis) sans jamais les synchroniser explicitement : chaque page reste identifiée de façon unique et stable, tant que le slug d'un article ne change pas après publication.

## Ce que Cusdis a demandé côté configuration

1. Créer un compte sur la plateforme Cusdis et déclarer le domaine du site.
2. Récupérer l'identifiant d'application fourni et l'ajouter en variable d'environnement du front, pour ne jamais l'écrire en dur dans le code source versionné.
3. Ajouter le script et la balise dans le gabarit d'article Nuxt, avec le slug de l'article comme identifiant de page.
4. Configurer les notifications email de modération, pour que le client reçoive une alerte à chaque nouveau commentaire à valider.
5. Tester le parcours complet : publication d'un commentaire test, validation depuis l'interface de modération Cusdis, affichage effectif sur le site public.

L'ensemble a pris une demi-journée de travail, essentiellement consacrée aux tests et à la vérification du rendu visuel, très en deçà des quatre jours envisagés pour une solution maison.

## Ce qui a été perdu au passage

- Les commentaires ne sont plus visibles depuis l'administration WordPress, l'équipe éditoriale doit désormais consulter l'interface Cusdis séparément.
- Aucune donnée de commentaire ne réside plus dans la base WordPress du client, un point qu'il a fallu clarifier explicitement dans le contrat en matière de propriété des données.
- La personnalisation visuelle du bloc de commentaires reste plus limitée qu'un développement entièrement maison, même si les options de thème proposées par Cusdis ont suffi ici.

> Ne pas reproduire une fonctionnalité que WordPress gère nativement n'est pas un renoncement : c'est parfois le choix le plus raisonnable, dès que le service tiers correspond réellement au besoin du client.

## En résumé

Sur ce projet, intégrer un service tiers de commentaires a coûté huit fois moins cher en temps de développement qu'une reproduction fidèle de l'API native de WordPress, pour un résultat parfaitement adapté au volume réel de commentaires du site. Ce choix ne convient pas à tous les contextes, en particulier lorsque la propriété complète des données de commentaires est une exigence non négociable, mais il mérite d'être posé sur la table avant de se lancer dans une réimplémentation coûteuse.