Résumé

  • La proposition AFPUB-2026-GEN-002-DRAFT01 prévoit des contrôles périodiques, aussi automatisés que possible, des notifications aux membres et des états d’escalade.
  • L’étude d’impact d’AFRINIC reconnaît l’intérêt de la visibilité, mais avertit que des règles coercitives indéfinies et des appréciations qualitatives ne peuvent être réduites sans risque à un statut produit par une machine.

Un tableau de bord est utile parce qu’il réduit la complexité. C’est aussi son principal danger. Lorsqu’un membre voit une cellule rouge à côté d’un contact abuse-c, d’un objet de routage ou d’une exigence de DNS inverse, il doit savoir s’il s’agit d’un test technique échoué, d’une interprétation contestée ou d’une constatation formelle. Ces situations n’ont ni la même portée ni les mêmes conséquences.

Note de publication de BTW : la date « Publié », 2026-09-06, est la date éditoriale programmée. L’heure réelle de publication par le serveur reste indéterminée jusqu’au succès de publish-now.

La proposition a été déposée le 30 avril 2026, puis sa version 1 a été diffusée sur la liste RPD le 26 mai. Elle reste « Under Discussion ». AFRINIC-37 l’a inscrite à l’ordre du jour de la réunion de politique publique du 24 juin 2026. Elle ajouterait une section au Consolidated Policy Manual et intégrerait une vue de conformité à MyAFRINIC ou à une future plateforme de communication. Le dispositif prévoit des contrôles périodiques, des notifications lors de la détection d’une non-conformité, des rappels et une saisine du personnel en cas de non-conformité persistante.

Il évoque aussi des procédures pouvant concerner la suspension de services, la révocation de ressources ou la fin de l’adhésion sur le fondement des pouvoirs contractuels existants.

L’étude d’impact du 23 juin précise l’intérêt opérationnel. Des contrôles pourraient porter sur l’exactitude des contacts WHOIS, la validité d’abuse-c, la cohérence des objets de routage, la couverture RPKI ROA lorsqu’elle est pertinente et le DNS inverse. Chaque anomalie pourrait suivre des états horodatés — notification, remédiation, escalade, clôture — et offrir au membre une trace plus claire.

Mais une observation technique n’est pas nécessairement un jugement de conformité. Une adresse de contact mal formée peut être détectée objectivement. Déterminer si l’utilisation d’une ressource est dûment justifiée ou appropriée, ou si la documentation est suffisante, peut exiger du contexte et un jugement professionnel. L’étude d’AFRINIC met précisément en garde contre l’idée que toutes les obligations puissent être décidées par une métrique.

La question de l’autorité est tout aussi importante. Le texte renvoie au Registration Services Agreement, à des procédures définies ultérieurement par le personnel et à des mesures spéciales du Conseil pour les infrastructures stratégiques ou certaines situations exceptionnelles. L’analyse juridique estime que le tableau de bord n’est pas le problème principal. Le risque est qu’une politique communautaire serve à créer des mécanismes coercitifs relevant plutôt du contrat et de la gouvernance opérationnelle, tout en laissant des notions décisives sans définition.

Elle relève séparément des lacunes de protection de la vie privée et de gouvernance des données dans le dispositif proposé.

La solution n’est pas d’abandonner le tableau de bord, mais de joindre à chaque constat un registre de preuve et de recours : règle et version applicables, donnée observée et horodatage, méthode et limites du test, origine automatique ou humaine du résultat, responsable de l’examen, réponse du membre, corrections et état du recours. Aucun statut ne devrait contribuer à une sanction avant que le membre puisse consulter et contester ce dossier.

Ce registre protégerait la valeur d’alerte précoce du dispositif sans transformer silencieusement une interface pratique en source d’autorité. Les documents gelés ne prouvent ni adoption, ni mise en service, ni sanction. Le choix de conception reste donc ouvert.