Résumé

  • L’aperçu de l’API de statut d’AFRINIC indique operational et affiche « All systems are go! ».
  • L’avis non planifié 502905, ouvert le 3 juillet 2026 pour le site web, est toujours present et recovering, sans valeur ended_at.
  • Les deux composants liés sont pourtant opérationnels, et l’avis ne contient que le message initial d’enquête promettant des mises à jour.
  • Rien ne prouve une panne actuelle. Le constat porte sur la cohérence : une même identité d’incident doit relier observation du service, décision de clôture, résumé global et historique.

Le vert est une conclusion. Sur la page de statut d’AFRINIC, il ressemble aujourd’hui davantage à une couche posée au-dessus d’une histoire inachevée.

L’API simple répond que la page est opérationnelle. Elle résume la situation par « All systems are go! ». La liste des composants confirme l’apparence d’un retour à la normale : « AFRINIC Web Sites » et www.afrinic.net sont marqués opérationnels. Mais l’API détaillée des avis conserve l’événement 502905 dans le présent. Son état est recovering, sa position temporelle est present, et sa date de fin est nulle.

Le 3 juillet, AFRINIC avait indiqué qu’un problème technique affectait son site et que celui-ci avait été mis hors ligne par précaution pendant l’enquête. Le dossier public ne contient qu’une mise à jour, celle de l’enquête initiale. Le texte annonçait que d’autres informations seraient fournies. Aucune note de résolution, aucune heure de rétablissement et aucune décision finale ne figurent dans la réponse capturée.

Il serait tentant d’en déduire que le site est encore indisponible. Ce serait dépasser les sources. L’état opérationnel des composants peut fort bien refléter la situation réelle. Le site peut répondre normalement depuis longtemps. Le problème vérifiable est autre : le public reçoit, dans le même système, des réponses incompatibles à la question de savoir si l’événement est terminé.

Quatre vues, aucun ordre de priorité

Une page de statut moderne n’est pas seulement une page destinée à rassurer. C’est une petite comptabilité temporelle. Un incident possède une identité, un début, une portée, des composants affectés, des observations et une fin. À partir de ce dossier, le système produit plusieurs vues : couleur générale, état des composants, fil de l’avis, messages aux abonnés et historique.

Ces vues peuvent légitimement avoir des rythmes différents. Un composant peut recommencer à répondre pendant que l’équipe observe sa stabilité. La page générale peut revenir au vert avant la rédaction d’un compte rendu. Mais cette différence doit être déclarée, sinon les lecteurs ne savent pas si elle exprime une politique ou un oubli.

Le cas de juillet juxtapose quatre projections. L’ensemble de la page est opérationnel. Les deux composants web sont opérationnels. L’avis reste en rétablissement. L’historique public présente comme dernier incident celui du site AIS 2026, commencé et résolu le 20 juin. L’événement du 3 juillet, plus tardif, n’apparaît pas comme incident clos.

L’incident de juin sert de comparaison limitée. Sa fiche contient le message d’enquête puis une mise à jour indiquant que l’incident est résolu, avec une heure de fin. Il ne renseigne ni la cause ni la durée réelle du problème de juillet. Il montre seulement que la plateforme sait représenter une clôture explicite. L’absence de cette transition pour l’avis 502905 ne vient donc pas d’une incapacité évidente du support.

L’observation n’est pas la décision

Le rétablissement d’un service commence par une observation. Une requête réussit, une page répond, un contrôle de dépendance revient dans sa plage acceptable. La clôture d’un incident ajoute une décision : l’équipe accepte que l’évidence soit suffisante, décrit les éventuels risques résiduels et ferme le dossier.

Confondre ces deux moments produit deux erreurs opposées. Fermer dès la première réponse favorable peut effacer une reprise instable. Maintenir indéfiniment un incident après un retour vérifié transforme l’historique en collection de dossiers fantômes. La bonne conception conserve les deux horloges : heure du rétablissement observé et heure de la décision de clôture.

L’API d’AFRINIC ne permet pas actuellement au lecteur public de reconstruire ces horloges pour le 3 juillet. L’état recovering suggère qu’une transition a eu lieu après l’enquête, mais aucune mise à jour ne la documente. Les composants sont opérationnels, mais leur état ne dit pas quelle observation a justifié le changement. La valeur ended_at reste vide, donc la durée de l’événement ne peut être calculée.

Il ne s’agit pas d’exiger la publication des journaux techniques. Une organisation peut protéger la topologie, les contrôles de sécurité et les détails des fournisseurs. Elle peut néanmoins publier l’unité de preuve minimale : catégorie de service vérifiée, moment de l’observation, critère accepté, rôle ayant décidé la clôture et lien entre cette décision et l’avis d’origine.

La page simple doit expliquer sa simplification

La documentation de l’API présente l’aperçu comme une réponse globale qui évite la complexité des composants et des avis. C’est un bon produit : beaucoup de consommateurs ont besoin d’un signal simple. Mais une compression n’est fiable que si sa règle est connue.

Si la couleur générale dérive exclusivement de l’état courant des composants, l’API pourrait l’indiquer et compter séparément les incidents ouverts. Le résultat dirait alors : services observés opérationnels, un incident encore en rétablissement administratif. Si, au contraire, toute alerte non planifiée classée present doit empêcher l’annonce générale, la validation devrait refuser le vert tant que l’événement n’est pas clos.

Le système ne doit pas nécessairement choisir une seule vérité. Il doit éviter qu’un consommateur soit forcé d’en choisir une. Un champ de dérivation, un nombre d’incidents ouverts et une phase agrégée suffiraient à transformer la contradiction en nuance explicite.

Cette règle est particulièrement importante pour l’automatisation. Un outil qui ne lit que l’aperçu peut arrêter l’escalade. Un autre qui surveille les avis présents peut maintenir une alerte pendant des mois. Aucun n’est fautif : chacun suit une interface officielle. L’écart se situe dans le contrat entre les interfaces.

Une quittance de clôture, pas un récit exhaustif

Le correctif utile est une quittance de clôture monotone. Elle commence avec l’identifiant stable de l’avis, les composants affectés et l’heure de début. Elle ajoute l’observation de reprise : service testé, critère, heure et résultat. Elle enregistre ensuite la décision de clôture, le rôle responsable, l’heure effective de fin, les réserves éventuelles et le message final destiné au public.

« Monotone » signifie que chaque étape s’ajoute. Le retour à l’état opérationnel ne doit pas faire disparaître l’étape d’enquête. Une correction tardive ne doit pas antidater silencieusement la décision. Si AFRINIC clôturait aujourd’hui un incident rétabli en juillet, la fiche pourrait conserver deux dates : le rétablissement observé, s’il est connu, et la clôture administrative enregistrée aujourd’hui.

Le résumé général, les composants, l’avis et l’historique devraient être recalculés à partir de cette même transition. Une validation simple peut détecter les combinaisons impossibles ou exigeant une explication : page entièrement verte avec un incident non planifié présent; incident terminal sans ended_at; composant opérationnel sans observation de reprise; événement clos absent de l’historique.

Cette discipline n’est pas punitive. Les pages de statut sont opérées sous pression et les oublis sont ordinaires. Une piste de correction visible réduit l’incitation à cacher une erreur administrative. Elle permet de réparer le dossier sans transformer une date de saisie tardive en fausse durée de panne.

Le coût d’un incident qui ne finit jamais

La première perte concerne les mesures. Avec une date de fin nulle, le temps de rétablissement ne peut être calculé à partir de la source publique. L’événement ressemble à un incident de plus de deux mois, même si le service a été restauré rapidement. Toute statistique automatique devient soit fausse, soit obligée d’exclure le dossier.

La deuxième perte concerne les responsabilités. Un statut opérationnel indique un résultat présent; il ne dit pas qui a accepté la reprise ni selon quel critère. Après rotation des journaux et changement d’équipe, cette information devient difficile à reconstituer.

La troisième touche la confiance. Si les avis ouverts restent durablement visibles pendant que la page générale est verte, les lecteurs apprennent à ignorer une des deux surfaces. Ils risquent alors d’ignorer le mauvais signal lors d’un événement futur. La cohérence n’est pas une question esthétique; elle détermine le canal auquel le public accorde la priorité.

AFRINIC exploite plusieurs services dont les conséquences ne sont pas identiques. Le site institutionnel n’est ni la base WHOIS, ni le système RPKI, ni le portail membre. L’article ne les confond pas. Justement, la page de statut commune doit préserver ces différences et montrer comment un événement précis passe de l’impact à la reprise, puis à la clôture.

La limite honnête

Les réponses officielles figées établissent l’incohérence publique au 11 septembre 2026. Elles n’établissent pas une indisponibilité actuelle, une violation d’engagement, un dommage pour les membres ou une dissimulation. Elles ne révèlent pas le code de calcul du statut, la fréquence des sondes ni les messages éventuellement envoyés hors de la page publique. Les dates updated_at des composants ne peuvent pas être assimilées à des heures de contrôle.

Il est possible qu’AFRINIC possède déjà une fiche interne complète. Il est possible que le rétablissement ait été rapide et que seule la clôture publique ait été omise. Dans les deux cas, la réparation reste la même : relier l’observation, la décision et la projection dans l’identité publique de l’événement.

Le vert peut être exact. L’avis ouvert peut être un vestige. Sans quittance de clôture, le public ne peut pas distinguer cette explication d’un rétablissement encore en cours.

Sources