« Les fournisseurs de plateformes en ligne mettent en place des mécanismes permettant à toute personne ou entité de signaler des contenus illicites, et accusent réception de ce signalement sans retard injustifié. » Ce texte, extrait du règlement européen sur les services numériques applicable depuis 2023, a servi de cahier des charges direct pour tester un module de signalement de commentaires sur un site d’actualités.
Contrairement à un test fonctionnel classique, il ne s’agissait pas de vérifier qu’une fonctionnalité marche, mais qu’elle respecte des obligations légales précises, avec une checklist qui traduit chaque exigence réglementaire en assertion automatisée.
Traduire le texte réglementaire en assertions vérifiables
Quatre exigences ont été extraites du règlement et converties en tests : l’accusé de réception immédiat, la conservation d’une trace horodatée indépendante du commentaire signalé, la notification de la décision à l’auteur du signalement, et la possibilité de contester cette décision.
- Un accusé de réception est généré dans la seconde suivant le signalement
- La trace du signalement survit même si le commentaire est ensuite supprimé
- L’auteur du signalement reçoit la décision motivée par email
- Un lien de contestation reste actif pendant trente jours
Vérifier que la trace survit à la suppression du contenu
Le point le plus délicat à tester : que se passe-t-il si le commentaire signalé est supprimé avant le traitement du signalement ? Un modérateur pressé pourrait supprimer directement le contenu litigieux sans traiter le signalement associé, faisant disparaître la trace exigée par le règlement.
public function test_trace_survit_a_suppression_commentaire() {
$signalement_id = $this->creer_signalement( $comment_id );
wp_delete_comment( $comment_id, true );
$trace = Signalement::get( $signalement_id );
$this->assertNotNull( $trace );
$this->assertSame( 'commentaire_supprime', $trace->statut_contenu );
}
Le module stocke la trace dans une table dédiée, distincte de la table wp_comments, précisément pour qu’elle ne dépende pas du cycle de vie du contenu qu’elle documente.
Tester le format de l’accusé de réception
Le règlement n’impose pas un format précis, mais la checklist interne du projet exige quatre champs minimum dans chaque accusé : un identifiant unique de signalement, l’horodatage de réception, un résumé du motif signalé, et un délai indicatif de traitement.
- Identifiant unique généré via
wp_generate_uuid4() - Horodatage en UTC, indépendant du fuseau du serveur
- Motif repris tel que sélectionné par le signalant, sans reformulation
Notifier la décision, y compris en cas de rejet
Un test vérifie qu’une décision de rejet du signalement déclenche la même notification qu’une décision d’acceptation, avec un motif différent. Un oubli fréquent, observé dans une version antérieure du module, ne notifiait que les signalements acceptés — une non-conformité passée inaperçue faute de test dédié.
Une checklist réglementaire n’est utile que traduite en tests exécutables : sinon elle reste un document que personne ne revérifie après la première mise en conformité.
Ce que cette checklist ne couvre pas
La conformité au règlement général sur la protection des données, notamment la conservation et l’anonymisation des informations personnelles du signalant, relève d’un chantier distinct traité par ailleurs. Ce module de tests se concentre uniquement sur les obligations de traçabilité et de notification propres au règlement sur les services numériques.
En résumé
Convertir un texte réglementaire en checklist de tests exécutables réduit le risque de non-conformité à chaque évolution du code. Les quatre points vérifiés ici — accusé de réception, trace persistante, notification systématique, voie de contestation — ont depuis servi de modèle pour d’autres modules de modération sur le même site.
