Le WordPress d'aujourd'hui, décodé pour les développeurs

Outils & workflow

Afficher la rotation des correctifs de sécurité sans dépendre d’un tableur partagé

Un fichier de rotation versionné, lu par un petit script, évite qu'une mise à jour critique n'attende que quelqu'un pense à ouvrir le tableur partagé.

Par Clément Hadrot • 22 septembre 2025 • 4 min de lecture • Aucun commentaire
Afficher la rotation des correctifs de sécurité sans dépendre d'un tableur partagé

« Qui est de rotation cette semaine pour les correctifs de sécurité ? » Cette question revenait presque chaque lundi dans le canal de discussion de l’équipe, signe que le tableur partagé censé y répondre n’était tout simplement pas consulté à temps. Le tableur existait, il était même correctement rempli la plupart du temps, mais rien n’obligeait à l’ouvrir avant d’agir, et personne n’était notifié quand son tour arrivait.

La solution retenue n’a pas consisté à changer d’outil de tableur ni à ajouter un système de notification séparé, mais à sortir la rotation du tableur pour la placer dans un fichier versionné, lu automatiquement par un script au moment où l’information est réellement nécessaire.

Le fichier de rotation, simple et versionné

La rotation est désormais définie dans un fichier rotation.json à la racine du dépôt qui centralise les scripts de maintenance de l’agence, aux côtés des autres fichiers de configuration déjà versionnés. Trois personnes s’y relaient à la semaine, dans un ordre fixe, avec une date de début de rotation servant de point de référence pour calculer qui est de service à n’importe quelle date donnée.

{
  "debut_rotation": "2025-01-06",
  "duree_jours": 7,
  "equipe": [
    "camille",
    "yanis",
    "leïla"
  ]
}

Contrairement à un tableur, ce fichier ne peut pas rester ouvert sur une ancienne version dans l’onglet oublié d’un navigateur : chaque lecture repart de la version actuellement présente sur la branche principale du dépôt.

Le script qui calcule la personne de service

L'essentiel à retenir : Un fichier versionné ne peut pas rester ouvert par erreur sur une ancienne version ; Un script de lecture affiche l'état réel sans ressaisie manuelle ; La rotation reste lisible par toute l'équipe sans droits d'édition spécifiques

Un petit script PHP, exécuté en ligne de commande, lit ce fichier et calcule automatiquement, à partir de la date du jour, quelle personne est actuellement responsable de la vérification des correctifs de sécurité.

<?php
$config = json_decode( file_get_contents( __DIR__ . '/rotation.json' ), true );

$debut = new DateTime( $config['debut_rotation'] );
$aujourdhui = new DateTime();
$jours_ecoules = $debut->diff( $aujourdhui )->days;

$index_semaine = intdiv( $jours_ecoules, $config['duree_jours'] );
$nombre_personnes = count( $config['equipe'] );
$personne = $config['equipe'][ $index_semaine % $nombre_personnes ];

echo "Responsable des correctifs de sécurité cette semaine : $personne\n";

Ce script est appelé chaque lundi matin par une tâche planifiée, qui publie son résultat dans le canal de discussion de l’équipe. La personne concernée reçoit ainsi l’information directement, sans avoir à consulter quoi que ce soit de sa propre initiative.

Croiser la rotation avec l’état réel des correctifs

Une fois la personne de service identifiée, encore fallait-il lui fournir une liste claire de ce qu’il y avait réellement à vérifier. Le même script enchaîne avec un appel à wp plugin list --update=available --format=json sur chacun des sites du parc, via les alias wp-cli déjà configurés, pour dresser la liste des extensions disposant d’une mise à jour de sécurité disponible.

  • Rotation calculée automatiquement, sans ressaisie manuelle chaque semaine
  • Liste des correctifs disponibles générée à la volée, jamais figée dans un document
  • Publication automatique le lundi matin dans le canal d’équipe

Ce que ce changement a résolu, et ce qu’il ne résout pas

Le nombre de correctifs de sécurité appliqués avec plus d’une semaine de retard a nettement diminué depuis la mise en place de ce mécanisme, la responsabilité étant désormais annoncée directement plutôt que de dépendre d’une consultation volontaire. Ce mécanisme ne remplace toutefois pas un outil de notification dédié aux vulnérabilités critiques elles-mêmes : il organise seulement qui doit regarder, pas comment on est alerté d’une faille particulièrement urgente entre deux rotations.

Le fichier rotation.json reste modifiable par une simple demande de fusion, ce qui garde une trace de chaque changement de composition d’équipe, un avantage que le tableur ne permettait pas d’obtenir aussi naturellement.

En résumé

Sortir une information critique d’un tableur partagé pour la placer dans un fichier versionné et lu automatiquement transforme une donnée passive, qu’il faut aller chercher, en une notification active, poussée au bon moment vers la bonne personne. Ce changement modeste a suffi à résoudre un problème récurrent qu’aucune relance dans le tableur n’était parvenue à corriger durablement.

Partager :

À propos de l'auteur

Clément Hadrot

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi