# DSA et les avis clients republiés sur un front headless : les obligations > Le Digital Services Act impose des obligations de modération dès qu'un front découplé republie des avis clients hébergés dans WordPress. - Auteur : Clément Hadrot - Publié le : 2025-04-20 - Mis à jour le : 2025-04-20 - Catégorie : Headless & API - URL : https://wpmoderne.dev.wordpress-developpement.fr/headless/dsa-avis-clients-republies-front-headless-obligations/ ## L’essentiel - Le DSA s'applique dès qu'un contenu utilisateur est republié publiquement - Un mécanisme de signalement doit rester accessible depuis le front - La traçabilité des décisions de modération doit être conservée « Ce commentaire est-il un contenu généré par un utilisateur au sens du Digital Services Act ? » C'est la question que s'est posée l'équipe technique d'un site d'avis sur des prestataires de services locaux, construit en front découplé, quand son service juridique a demandé une revue de conformité au printemps 2025. La réponse, sans surprise, est oui : dès qu'un visiteur peut publier un avis affiché à d'autres visiteurs, le site entre dans le champ du règlement européen sur les services numériques. La difficulté propre à une architecture headless tient à la séparation entre le back-office qui stocke les avis (WordPress) et le front qui les affiche (un client React consommant l'API REST). Les obligations du DSA ne s'arrêtent pas à la couche de stockage : elles concernent l'expérience effectivement proposée à l'utilisateur final, donc le front autant que l'API. ## Ce que le règlement exige concrètement Le Digital Services Act, entré en application progressive depuis 2024, impose à tout service qui héberge du contenu généré par les utilisateurs de proposer un mécanisme de signalement clair, accessible et facile à utiliser. Pour un site d'avis, cela signifie qu'un bouton « signaler cet avis » doit être visible à côté de chaque contenu publié, et pas seulement dans une page de contact générique noyée dans le pied de page. ## Où placer la logique de signalement dans une architecture découplée > L'essentiel à retenir : Le DSA s'applique dès qu'un contenu utilisateur est republié publiquement ; Un mécanisme de signalement doit rester accessible depuis le front ; La traçabilité des décisions de modération doit être conservée Deux options existent. La première consiste à faire remonter le signalement directement au front, qui appelle ensuite un endpoint REST dédié côté WordPress. La seconde consiste à rediriger vers une page hébergée par WordPress lui-même, hors du front headless. La première option offre une meilleure expérience utilisateur, mais elle exige un endpoint capable de recevoir un signalement sans authentification préalable, tout en évitant les abus : - Un endpoint `POST` dédié, protégé par une limitation de fréquence par adresse IP. - Un enregistrement du signalement en tant qu'entrée de journal, distincte du commentaire lui-même, pour ne jamais le modifier sans trace. - Une notification automatique vers l'équipe de modération, avec un délai de traitement affiché à l'utilisateur. ## Conserver la traçabilité des décisions de modération Le règlement impose de documenter les décisions prises sur un contenu signalé : suppression, maintien, ou demande de complément d'information. Dans une architecture headless, cette trace doit vivre côté WordPress, indépendamment du front qui peut être reconstruit ou changé sans perdre l'historique. Un type de contenu personnalisé `decision_moderation`, non exposé publiquement dans l'API REST, permet de conserver qui a décidé quoi et quand, sans que cette donnée sensible ne transite jamais vers le front public. ## Ce que le DSA ne couvre pas ici Le règlement ne dit rien sur la conservation des données personnelles associées à un avis, ce point relevant du RGPD et méritant un traitement séparé. Il ne fixe pas non plus de délai légal strict pour traiter un signalement, contrairement à une idée reçue : il exige seulement que le mécanisme soit « en temps utile », une notion à préciser dans les conditions générales du service plutôt que dans le code. ## Les pièges observés sur ce type de projet Le piège le plus fréquent consiste à traiter le signalement uniquement côté front, dans un état local qui disparaît au rechargement de la page. Un autre piège consiste à supprimer purement et simplement l'avis signalé sans conserver de trace, ce qui prive l'éditeur du site de tout moyen de répondre à une demande d'explication ultérieure, qu'elle vienne de l'auteur de l'avis ou d'une autorité compétente. ### Former l'équipe qui traite les signalements La technique ne suffit pas : encore faut-il qu'une personne identifiée traite effectivement les signalements reçus. Sur ce projet, l'équipe a désigné un modérateur référent, avec une procédure écrite qui précise les critères de suppression (propos manifestement diffamatoires, contenu hors sujet, tentative de démarchage déguisée) et ceux qui justifient un simple maintien malgré un signalement infondé. Cette procédure, courte mais formalisée, évite des décisions arbitraires prises dans l'urgence par une personne différente à chaque fois. > Un mécanisme de signalement qui ne laisse aucune trace n'est pas un mécanisme de modération, c'est un bouton de suppression. ## Pour aller plus loin Un front headless ne dispense d'aucune des obligations de modération qui s'appliqueraient à un WordPress classique : il déplace simplement la question de l'endroit où placer le bouton de signalement et de la manière de faire remonter l'information vers le back-office. La bonne pratique reste de traiter cette exigence dès la conception de l'endpoint, pas en correctif après coup.