Résumé

  • Le rapport d’activité Q2 2026 d’APNIC donne 99,17 % de disponibilité à Honeynet, pour un objectif de moins de 5 % d’indisponibilité de l’infrastructure Honeynet « centrale ».
  • Le même document indique que la mise à niveau de l’infrastructure et des logiciels des capteurs est terminée. Il ne donne ni intervalle de mesure, ni liste des composants, ni formule de calcul.

Un chiffre précis, sans calendrier

99,17 %. Deux décimales, assez pour inspirer confiance dans une présentation de conseil d’administration. Les minutes du conseil exécutif de l’APNIC, adoptées le 19 octobre, joignent le rapport d’activité du deuxième trimestre 2026 et attribuent ce score à la disponibilité de Honeynet. L’objectif associé est de maintenir l’indisponibilité sous 5 % pour l’infrastructure Honeynet dite « centrale ». Le rapport précise aussi que la mise à niveau de l’infrastructure et des logiciels des capteurs est achevée.

Le calcul semble flatteur. Si la cible et le résultat portent sur la même période et le même dénominateur, moins de 5 % d’indisponibilité revient à plus de 95 % de disponibilité. Le résultat annoncé dépasse ce plancher de 4,17 points ; son complément arithmétique est de 0,83 %. Mais sans méthode publiée, un lecteur ne peut pas refaire le calcul à partir des observations.

Le document ne date pas le début et la fin de la mesure. Il ne dit pas si le chiffre couvre tout le trimestre. Il ne définit pas les éléments inclus dans « centrale », ne donne aucun total de contrôles réussis ou échoués et ne précise pas ce qui constitue un échec. Les maintenances planifiées comptent-elles comme indisponibilité ? Le résultat mesure-t-il des minutes, des sondes ou une moyenne pondérée de plusieurs composants ? La mise à niveau est déclarée terminée, mais son calendrier et son éventuel effet sur le score restent inconnus.

Or Honeynet n’est pas un seul serveur. Les pages publiques de sécurité d’APNIC indiquent que le projet exploite les données de plus de 400 pots de miel dans le monde et alimente notamment les informations de trafic suspect dans DASH. La disponibilité d’une infrastructure centrale, la portée des capteurs, la fraîcheur des flux et l’accès au tableau de bord décrivent des fonctions liées, pas une seule et même prestation.

Le rapport de Q2 recense des échanges de renseignement sur les menaces au Phoenix Summit, à l’atelier PKCERT et à PacNOG, ainsi que des présentations lors de ces événements et de CyberQuest Honiara. Il indique également que le contenu Honeynet prévu a été repoussé au troisième trimestre, faute de données suffisantes pour tirer des conclusions. Cette retenue éditoriale est défendable. Elle rend seulement plus visible l’absence de méthode derrière le pourcentage de disponibilité publié dans le même bloc.

Rien ici ne prouve une panne. Le rapport ne signale ni défaillance de capteur, ni perte de données, ni préjudice pour un membre. Le 99,17 % est un résultat déclaré par APNIC. À lui seul, il ne décrit pas quels capteurs répondaient ni si les données de DASH arrivaient à temps. Un indicateur ne peut pas tenir lieu de tous les autres.

Le périmètre devrait accompagner le score

Une note de méthode courte rendrait la prochaine édition bien plus exploitable : dates exactes, systèmes classés comme « centraux », fréquence des contrôles, seuil d’échec, dénominateur, traitement des travaux programmés et méthode de pondération. Un indicateur distinct sur la fraîcheur du flux, accompagné d’un compte de capteurs couverts, éviterait de confondre la disponibilité du socle avec la qualité du renseignement.

Cette distinction sert les équipes qui s’appuient sur le flux. Un tableau silencieux peut signaler l’absence d’activité pertinente, des données anciennes ou une interruption. Le score Q2 peut être parfaitement exact tout en ne répondant à aucune de ces questions.

Sources