Le règlement européen sur les services numériques impose depuis cette année un mécanisme de signalement des contenus illicites accessible sur toute plateforme qui héberge du contenu déposé par des utilisateurs. Pour un site WordPress qui accepte des commentaires, des avis ou des dépôts de fichiers, cela veut dire concrètement : un formulaire de signalement présent, un traitement des signalements tracé, et une preuve que ce dispositif est actif au moment où le site est exposé publiquement.
Sur nos projets, cette obligation a un point faible connu : elle repose sur une extension ou un module maison qui peut être désactivé par erreur lors d’une migration, d’un changement de thème ou d’une réinitialisation de configuration. Un contrôle manuel avant chaque mise en ligne ne suffit pas sur la durée ; il finit par être oublié. La solution que nous avons retenue consiste à transformer cette vérification en étape automatisée de la chaîne de déploiement, qui échoue et bloque la publication si le dispositif n’est pas détecté actif.
Étape 1 : définir ce qu’on vérifie réellement
Avant d’écrire le moindre script, il faut lister ce que la pipeline doit constater. Sur nos projets, trois éléments sont contrôlés : la présence d’une route de signalement répondant en HTTP 200, la présence du plugin ou du module de modération dans la liste des extensions actives, et l’existence d’une table ou d’un stockage de traçabilité des signalements. Ces trois vérifications sont indépendantes : un module actif mais avec une route cassée doit quand même déclencher une alerte.
Étape 2 : écrire le contrôle en WP-CLI et en requête HTTP
Le contrôle du plugin actif s’appuie sur wp plugin is-active, qui renvoie un code de sortie exploitable directement dans un script shell. Le contrôle de la route de signalement s’appuie sur un simple curl avec vérification du code de statut.
#!/usr/bin/env bash
set -euo pipefail
SITE_URL="https://exemple-client.fr"
PLUGIN_SLUG="signalement-contenus"
echo "Verification du plugin de signalement..."
if ! wp plugin is-active "$PLUGIN_SLUG" --path=/var/www/html; then
echo "ECHEC : le plugin $PLUGIN_SLUG n'est pas actif"
exit 1
fi
echo "Verification de la route de signalement..."
STATUS=$(curl -s -o /dev/null -w "%{http_code}" "$SITE_URL/signaler-un-contenu/")
if [ "$STATUS" != "200" ]; then
echo "ECHEC : route de signalement en statut $STATUS"
exit 1
fi
echo "Conformite DSA verifiee avec succes"
Étape 3 : intégrer ce script comme job bloquant
Ce script est ensuite appelé comme un job à part entière dans la chaîne de déploiement, positionné juste avant l’étape de bascule en production. S’il échoue, le déploiement s’arrête et une notification est envoyée à l’équipe. Il ne s’agit pas d’un simple avertissement : sur ce type d’obligation légale, nous préférons un blocage dur plutôt qu’un message ignoré dans les logs.
- Le job tourne après le build et avant la synchronisation des fichiers vers le serveur cible.
- Il s’exécute contre une copie de staging identique à la production, jamais contre la production elle-même.
- Son échec renvoie un code de sortie non nul, ce qui suffit à faire échouer la pipeline dans la quasi-totalité des outils de CI.
Étape 4 : gérer les faux positifs et les exceptions
Certains sites de notre parc n’hébergent aucun contenu généré par des utilisateurs : pas de commentaires ouverts, pas de dépôt de fichiers, pas d’espace membre. Pour ceux-là, l’obligation ne s’applique pas de la même façon, et le job doit pouvoir être désactivé explicitement plutôt que contourné en douce. Nous avons ajouté un fichier de configuration à la racine du dépôt, compliance.json, qui déclare si le contrôle DSA doit s’appliquer au projet.
{
"dsa_check": true,
"dsa_route": "/signaler-un-contenu/",
"dsa_plugin_slug": "signalement-contenus"
}
Le script lit ce fichier avant de s’exécuter et s’arrête proprement, sans erreur, si dsa_check vaut false. Cette déclaration explicite oblige à documenter le choix plutôt que de le laisser implicite dans une variable d’environnement oubliée.
Étape 5 : historiser les résultats pour les audits
Un contrôle qui bloque un déploiement est utile dans l’instant, mais un client ou un partenaire peut demander plus tard une preuve que le dispositif était actif à une date donnée. Nous archivons donc la sortie de chaque exécution du job dans un fichier de log horodaté, conservé douze mois, associé au hash du commit déployé. Cette traçabilité coûte peu à mettre en place et évite de devoir reconstituer une preuve a posteriori.
Un contrôle de conformité qui n’est vérifié qu’à l’œil avant la mise en ligne finit toujours par être oublié un jour de rush. Le transformer en étape de pipeline, c’est le rendre impossible à sauter sans s’en rendre compte.
En résumé
Ajouter une vérification de conformité DSA à la chaîne de déploiement ne demande ni outil complexe ni service tiers : un script shell de quelques lignes, un appel WP-CLI, une requête HTTP et un code de sortie suffisent à transformer une obligation réglementaire en garde-fou technique. La difficulté n’est pas dans l’écriture du script, mais dans la discipline de le maintenir à jour à mesure que le dispositif de modération évolue, et de documenter clairement les exceptions plutôt que de les contourner.
