Trois services à surveiller, une équipe produit de quatre personnes, et une question simple posée en réunion : faut-il payer un abonnement à une page de statut dédiée pour afficher trois indicateurs verts ou rouges sur le site public ? La réponse retenue s’est éloignée des solutions packagées, au profit d’un bloc dynamique qui interroge un fichier statique publié à intervalle régulier.
Le choix d’un fichier plutôt qu’un service tiers
L’équipe technique met déjà à jour manuellement un fichier statut.json, hébergé sur son infrastructure existante, chaque fois qu’un incident survient ou se résout. Ce fichier ne dépend d’aucun service de supervision commercial :
{
"derniere_mise_a_jour": "2023-03-14T17:12:00Z",
"services": [
{ "nom": "API principale", "statut": "operationnel" },
{ "nom": "Tableau de bord", "statut": "degrade" },
{ "nom": "Export de données", "statut": "operationnel" }
]
}
Arborescence du bloc dans le projet
wp-content/plugins/monsite-statut/
├── block.json
├── src/
│ ├── index.js
│ ├── edit.js
│ └── style.scss
├── build/
│ ├── index.js
│ └── style-index.css
└── monsite-statut.php
Le fichier monsite-statut.php enregistre le bloc et expose une route REST interne qui relaie le contenu du fichier statut.json, plutôt que de laisser le bloc l’interroger directement depuis le navigateur :
Pourquoi passer par une route REST intermédiaire
Interroger directement le fichier statut.json depuis le navigateur aurait fonctionné, mais aurait exposé l’adresse exacte de l’infrastructure interne dans le code source du site public. La route REST sert d’écran :
register_rest_route( 'monsite/v1', '/statut', array(
'methods' => 'GET',
'callback' => 'monsite_recuperer_statut_services',
'permission_callback' => '__return_true',
) );
function monsite_recuperer_statut_services() {
$reponse = wp_remote_get( 'https://interne.monsite.example/statut.json', array( 'timeout' => 3 ) );
if ( is_wp_error( $reponse ) ) {
return new WP_REST_Response( array( 'erreur' => true ), 200 );
}
return json_decode( wp_remote_retrieve_body( $reponse ) );
}
Le rendu côté bloc
Le bloc, côté client, interroge simplement sa propre route interne et affiche un indicateur coloré par service :
wp.apiFetch( { path: '/monsite/v1/statut' } ).then( ( donnees ) => {
if ( donnees.erreur ) {
afficherMessageIndisponible();
return;
}
donnees.services.forEach( ( service ) => {
afficherLigneStatut( service.nom, service.statut );
} );
} );
- Un statut « operationnel » affiche un indicateur vert ;
- Un statut « degrade » affiche un indicateur orange avec un message court ;
- Un statut « interrompu » affiche un indicateur rouge, avec la date de dernière mise à jour visible en toutes lettres.
Une mise à jour manuelle, assumée
Aucune détection automatique de panne n’alimente ce fichier : c’est une personne de l’équipe qui modifie manuellement statut.json lorsqu’un incident est constaté. Ce choix peut surprendre pour une startup technique, mais il correspond à la taille réelle de l’équipe : à quatre personnes, l’information circule déjà en interne dès qu’un problème survient, et automatiser la détection aurait demandé un système de supervision que l’équipe ne possédait pas encore.
Ce que ce montage ne couvre pas
L’alerting interne, qui prévient l’équipe elle-même d’un problème avant que les clients ne le remarquent, reste un sujet totalement distinct, traité par d’autres outils déjà en place chez cette équipe. Ce bloc ne sert qu’à communiquer publiquement un état déjà connu en interne, pas à le détecter.
Une page de statut n’a pas besoin d’être automatisée pour être utile : elle a d’abord besoin d’être mise à jour honnêtement, au bon moment.
En résumé
Pour une jeune équipe produit qui ne voulait pas d’un abonnement supplémentaire pour une page de statut, un simple fichier JSON, relayé par une route REST interne et affiché par un bloc dynamique, a suffi à donner une visibilité publique honnête sur l’état des services, sans dépendance à un outil tiers dédié.
