« Les fournisseurs de plateformes en ligne mettent en place un système interne de traitement des réclamations » : cette exigence, posée par le règlement européen sur les services numériques, ne relève pas seulement d’un texte juridique à faire lire à un service commercial. Elle a des conséquences directes sur l’architecture technique d’une marketplace construite sur WordPress.
Depuis son application générale le 17 février 2024, ce règlement concerne toute plateforme mettant en relation vendeurs et acheteurs, y compris une marketplace de taille modeste construite avec une extension multi-vendeurs. La question qui se pose à un développeur n’est pas juridique mais structurelle : que faut-il enregistrer, et où, pour pouvoir répondre à une demande de traçabilité le jour où elle survient ?
Ce que la traçabilité recouvre concrètement
Le règlement distingue plusieurs obligations qui touchent directement la couche de données d’un site : l’identification vérifiable de chaque vendeur professionnel, la motivation systématique de toute décision de retrait ou de restriction de contenu, et la conservation d’un historique consultable de ces décisions. Aucune de ces obligations ne se satisfait d’une simple suppression silencieuse d’une fiche produit ou d’un compte vendeur.
Techniquement, cela signifie qu’une marketplace ne peut plus se contenter d’un changement de statut de publication classique, comme passer un article de publish à trash, sans conserver par ailleurs la raison de ce changement, son auteur, et sa date, dans un espace distinct du contenu lui-même.
Fonctionnement interne d’un journal de modération conforme
Un journal de modération dédié, distinct des révisions natives de contenu, répond à ce besoin sans dépendre d’un service tiers. Une table personnalisée, créée via dbDelta() lors de l’activation de l’extension, permet d’enregistrer chaque décision avec son contexte complet.
function marketplace_creer_table_journal_moderation() {
global $wpdb;
$table = $wpdb->prefix . 'journal_moderation';
$charset = $wpdb->get_charset_collate();
$sql = "CREATE TABLE $table (
id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
objet_id BIGINT UNSIGNED NOT NULL,
type_objet VARCHAR(20) NOT NULL,
decision VARCHAR(50) NOT NULL,
motif TEXT NOT NULL,
auteur_id BIGINT UNSIGNED NOT NULL,
date_decision DATETIME NOT NULL,
PRIMARY KEY (id)
) $charset;";
require_once ABSPATH . 'wp-admin/includes/upgrade.php';
dbDelta( $sql );
}
register_activation_hook( __FILE__, 'marketplace_creer_table_journal_moderation' );
Chaque retrait de fiche produit ou de compte vendeur passe ensuite par une fonction unique, qui journalise la décision avant de l’appliquer, garantissant qu’aucune action de modération ne peut avoir lieu sans laisser de trace exploitable.
Cas d’usage : une réclamation de vendeur retiré
Lorsqu’un vendeur retiré conteste la décision, l’équipe de modération doit pouvoir présenter, en quelques minutes, l’ensemble des éléments ayant motivé le retrait : signalement initial, personne ayant validé la décision, motif précisément formulé, date exacte. Sans journal structuré, cette reconstitution repose sur la mémoire des équipes ou des échanges d’e-mails dispersés, une situation intenable dès que le volume de réclamations dépasse quelques cas isolés par mois.
- Chaque décision de modération référence l’identifiant du signalement à l’origine, s’il existe.
- Le motif est un champ obligatoire, jamais une valeur par défaut générique.
- L’historique reste consultable même après suppression définitive de la fiche concernée.
Pièges fréquents à éviter
Le premier piège consiste à confondre journalisation technique et transparence publique : le règlement impose de motiver une décision auprès du vendeur concerné, pas nécessairement de publier ce motif sur le site. Le second piège consiste à journaliser la décision après l’avoir appliquée plutôt qu’avant, ce qui expose à des incohérences si l’application de la décision échoue partiellement en cours de traitement.
| Piège | Conséquence |
|---|---|
| Journal appliqué après la décision | Incohérence possible entre action réelle et trace enregistrée |
| Motif générique non spécifique | Réclamation impossible à instruire correctement |
| Historique supprimé avec la fiche produit | Perte de la preuve en cas de contestation ultérieure |
Repère retenu par l’équipe technique concernée : un journal de modération n’a de valeur que s’il survit à l’objet qu’il concerne. Une fiche supprimée ne doit jamais emporter avec elle la trace de sa propre suppression.
Notion à retenir
La traçabilité imposée par ce règlement européen ne relève pas d’une fonctionnalité optionnelle de conformité, mais d’une exigence structurelle qui touche directement la façon dont une marketplace WordPress modélise ses décisions. La question de la modération éditoriale du contenu lui-même — ce qui doit ou non être retiré sur le fond — reste un sujet distinct ; celui-ci porte uniquement sur ce qu’il faut conserver, techniquement, une fois la décision prise.
