Résumé

  • Une mise à jour datée du 18 août 2026 distingue quatre états BGP dans le moniteur d'AFRINIC : préfixe d'origine annoncé, routes plus spécifiques seulement, absence de routage et absence de données.
  • Dans le fichier complet de l'Afrique du Sud consulté le 3 septembre, l'algorithme public additionne 239 cas du premier type et 42 du second. Ces 281 blocs sur 522 donnent 54 % après arrondi.
  • Le fichier indique une génération le 20 août, sans date d'instantané BGP. Cette vérification reconstitue un calcul public ; elle ne mesure ni la disponibilité des services ni l'état actuel de toutes les routes.

Un pourcentage voyage facilement. Son intitulé tient sur une diapositive, sa variation entre dans un compte rendu. L'explication de ce qui a été compté suit moins souvent. AFRINIC a pourtant ajouté une distinction qui mérite de faire le voyage avec son indicateur IPv6.

Dans l'historique du 18 août, Africa IPv6 & DNSSEC Deployment Monitor décrit le passage de deux à quatre états BGP. Il sépare le préfixe d'origine annoncé des seules routes plus spécifiques. Il distingue aussi un bloc sans données d'un bloc classé non routé. Ne plus confondre ignorance et résultat négatif est un progrès concret pour l'utilisateur.

La présence de catégories plus fines ne signifie toutefois pas que le total ne retient que la première. L'exemple sud-africain permet de regarder le calcul sans lui prêter une promesse supplémentaire.

Une addition explicite

Le fichier public de l'Afrique du Sud, intégralement récupéré le 3 septembre, comporte 522 préfixes distincts. Il contient 451 enregistrements au statut allocated et 71 au statut assigned. Le dénominateur est donc un ensemble de blocs répertoriés, pas 522 opérations d'allocation identiques.

Le code public de la page vérifie d'abord l'absence explicite de couverture par les données BGP, puis l'annonce exacte, puis la présence d'annonces plus spécifiques. Les autres cas deviennent non routés. Sur le fichier examiné, cette règle donne :

État selon la règle du moniteur Blocs
Préfixe d'origine annoncé 239
Routes plus spécifiques seulement 42
Classés non routés 241
Classés sans données 0

Le total des annonces réunit les deux premières lignes : 239 + 42 = 281. Le quotient 281/522, arrondi à l'entier, vaut 54 %. La phrase explicative construite par le code détaille ensuite les deux composantes. L'information n'est donc pas entièrement enfouie derrière le chiffre.

Ne retenir que les 239 annonces exactes produirait environ 46 %. Ce ne serait pas la correction d'un taux de disponibilité erroné : ce serait la réponse à une autre question. Chaque bloc pèse une unité, quelle que soit sa taille. Ni 54 % ni 46 % ne mesure la part des adresses, des organisations, des clients ou des connexions réussies.

Une route plus spécifique n'est pas une note inférieure

Le vocabulaire peut suggérer qu'un bloc visible par morceaux est nécessairement mal desservi. Ce n'est pas ce que dit la relation technique. La RFC 4271 décrit une route plus spécifique comme un préfixe plus long couvrant un ensemble de destinations plus petit. Il s'agit d'une relation entre ensembles, pas d'un jugement sur l'exploitation.

Un exemple arithmétique suffit : les deux moitiés /33 correctement alignées d'un /32 peuvent couvrir l'ensemble du /32 sans que le /32 lui-même soit annoncé. Aucun des 42 cas observés n'a été identifié ici comme utilisant cette configuration. L'exemple établit seulement que l'absence de l'annonce agrégée ne démontre pas, à elle seule, une lacune dans la couverture des adresses.

Inversement, une annonce exacte ne garantit ni la présence d'une machine à chaque adresse, ni l'acceptation de la route par tous les observateurs, ni la réponse d'une application. Le nombre de routes plus spécifiques ne permet pas non plus de reconstituer leur union et leurs chevauchements. L'information de routage ne dispense pas de tester le service voulu.

Les 42 cas ne peuvent donc être qualifiés de défaillants, inutilisés ou dangereux sur cette base. Les 241 classements négatifs valent dans les limites du jeu de données du moniteur, et non pour tous les points d'observation possibles. Le zéro dans la dernière ligne est propre à ce fichier sud-africain ; il ne prouve pas une couverture exhaustive de l'Afrique.

La prudence déjà présente dans la date

L'historique explique que l'ancienne méthode comptait un bloc dès qu'une partie apparaissait et attribue des pourcentages plus faibles à une mesure devenue plus stricte. C'est le récit du changement fourni par le site. Cette enquête n'a pas reconstruit l'ancienne version ni comparé les jeux BGP avant et après modification. Elle ne chiffre donc aucune baisse et n'établit aucune dégradation du réseau.

Le fichier consulté porte la date de génération du 20 août 2026, mais son champ de date BGP est vide. Le code conserve cette différence : il affiche la date de l'instantané lorsqu'elle existe, sinon celle de la génération. Le 3 septembre, date de consultation, ne remplace pas une date d'observation manquante.

La page nationale sépare par ailleurs services des domaines, adoption par les utilisateurs, espace d'adressage et BGP. Cette organisation évite de demander au même test de tout certifier. Voir une route ne signifie pas avoir vérifié un site web, une messagerie ou une connexion d'abonné.

L'apport du changement est donc moins un chiffre à classer qu'une différence à examiner. Les deux formes d'annonces peuvent alimenter un résumé commun. Leur séparation aide à poser la question suivante, sans transformer une préférence d'affichage en norme de bonne conduite technique.