Résumé

  • Dans DRAFT02, soumis le 25 septembre 2026, les contrôles automatisés peuvent signaler une non-conformité possible, mais le personnel doit vérifier les informations avant une enquête ou une action fondée sur le RSA ou les statuts.
  • Le texte s’écarte de DRAFT01 : un résultat automatisé n’est plus présenté comme un constat de non-conformité, mais comme un indice à examiner.
  • Un référentiel reliant chaque test à la version de la politique, à sa date d’effet, à son périmètre et à ses données sources permettrait de comprendre ce qu’une alerte établit — et ce qu’elle ne prouve pas.
  • La proposition reste en cours de discussion. Les documents publics ne montrent ni tableau de bord en service, ni alerte adressée à un membre, ni constat ou sanction.

Un indicateur ne décide pas quelle règle s’applique

Un détenteur reçoit un message signalant qu’un champ du registre ne correspond pas à une condition attendue. Le logiciel peut avoir lu une fiche de contact, comparé un objet de route ou confronté une ressource à une règle. La comparaison peut être répétable. Elle ne démontre pas à elle seule que la bonne politique s’applique à ce membre, que la donnée est à jour ou qu’une obligation a été violée.

C’est la frontière centrale du projet de tableau de bord de conformité d’AFRINIC, AFPUB-2026-GEN-002-DRAFT02. La version du 25 septembre demande de privilégier les éléments que l’on peut mesurer aussi objectivement que possible et de ne relever que des signes possibles de non-conformité. Elle précise que le tableau de bord n’est pas l’arbitre final : le personnel doit vérifier les informations issues des tests automatisés. Le texte envisage ensuite une enquête plus approfondie et d’éventuelles mesures selon le RSA ou les statuts si des éléments suggèrent une non-conformité.

Ces dispositions ne décrivent pas un produit opérationnel. L’index actuel des propositions classe toujours DRAFT02 en cours de discussion. L’enjeu est donc la limite fixée par le texte et les éléments nécessaires si AFRINIC décide un jour de développer le système.

DRAFT02 modifie la portée du résultat automatisé

La version archivée DRAFT01 employait des termes plus affirmatifs. Elle prévoyait des notifications dès qu’une non-conformité était détectée, puis des rappels, une période de persistance définie par le personnel, des procédures ultérieures et des règles à définir pour suspendre un service, révoquer des ressources ou fermer un membre. Elle ajoutait une exception du Conseil dans certains cas touchant une infrastructure critique ou une situation exceptionnelle.

DRAFT02 ne se contente pas de raccourcir un calendrier. Il retire les clauses séparées sur la durée de persistance et les règles de sanction que le personnel devait encore établir. Deux réserves apparaissent désormais clairement : la conformité ne se mesure pas de manière entièrement objective, et les contrôles automatisés ne peuvent que suggérer des signes possibles. Le texte proposé attribue explicitement la vérification au personnel. Il conserve toutefois la possibilité d’autres mesures au titre du RSA ou des statuts, notamment la suspension d’un service, la révocation ou la fermeture du membre.

La fonction du logiciel change donc. L’ancienne rédaction commençait par un état détecté et nommé « non-conformité ». La nouvelle commence par un signal qui peut être erroné, incomplet ou hors périmètre. La vérification humaine fait le lien entre les deux. Sa fiabilité dépend des pièces visibles par la personne chargée du contrôle et des éléments que le membre peut reproduire.

La version de la politique doit accompagner le résultat

Le projet indique que l’automatisation devra évoluer avec les révisions du manuel consolidé des politiques (CPM). Ce n’est pas un détail de maintenance. Un test fidèle à la règle d’hier peut classer incorrectement une ressource après une modification, ou appliquer un nouveau critère avant sa date d’entrée en vigueur. Un statut vert ou rouge sans version de référence masque cette différence.

L’évaluation de DRAFT01 citait comme exemples l’exactitude des contacts, la validité des contacts d’abus, la cohérence des objets de route, la couverture RPKI lorsque pertinente et les exigences de DNS inverse. Ce sont des exemples de l’évaluation de la version précédente, pas un catalogue définitif pour DRAFT02 et pas la preuve que ces contrôles sont déployés. Ils montrent pourquoi un résultat « automatisé » n’est pas forcément explicite. L’absence d’un champ peut se constater directement ; savoir si ce champ est exigé pour cette ressource par la politique applicable est une autre question.

Une comparaison de routes ou de RPKI suppose elle aussi une source identifiée, une heure d’observation et un périmètre.

Chaque contrôle devrait donc relier deux dossiers. Le premier décrirait la règle : identifiant, version, date d’effet, classe de ressources visée et conditions d’application. Le second serait le reçu du test : source, heure de collecte, transformation, version du test, résultat et limites connues. Un membre du personnel pourrait remonter à la donnée et expliquer pourquoi la règle s’applique — ou pourquoi l’alerte doit être levée. Le membre concerné pourrait vérifier le même fondement sans accéder aux données privées d’autres organisations.

C’est une recommandation éditoriale, pas une fonctionnalité annoncée par AFRINIC. DRAFT02 ne définit ni catalogue complet, ni méthode de versionnement, ni mesure de précision, ni registre de décision du personnel. Or, si un résultat est seulement un signal possible jusqu’à vérification, il faut rendre visibles la donnée et la règle que cette vérification doit contrôler.

Séparer la donnée, le signal et l’action

Une chaîne vérifiable distingue au moins quatre états : une donnée du registre ou du réseau ; une comparaison automatisée qui signale un risque possible ; une vérification par le personnel de la source et de la règle applicable ; puis, le cas échéant, une mesure prise séparément au titre du RSA ou des statuts. Ce ne sont pas des formulations équivalentes. Une étiquette de tableau de bord ne devrait pas transformer silencieusement le premier état en décision finale.

Cette séparation protège les deux parties. Un membre peut corriger une donnée inexacte ou expliquer pourquoi une règle ne le concerne pas. Le personnel peut distinguer un problème de qualité des données d’une question d’interprétation de politique. AFRINIC peut documenter les éléments qui soutiendraient une enquête ultérieure. Si le test était erroné, l’alerte peut être corrigée sans laisser un statut inexpliqué dans l’historique du membre.

Le mécanisme économique est prospectif, mais concret. La proposition indique que des demandes ultérieures, des services et l’adhésion pourraient être affectés au titre du RSA. Un statut trompeur pourrait mobiliser le temps d’un opérateur ou peser sur un examen ultérieur ; un avertissement exact pourrait aider à corriger un problème. Les sources publiques ne démontrent aujourd’hui aucun de ces résultats. Elles posent une question de conception : comment distinguer une alerte utile d’un test périmé ou mal appliqué ?

L’historique éclaire la révision, pas l’issue de DRAFT02

AFRINIC-37 a examiné DRAFT01 le 24 juin. Le procès-verbal indique que les coprésidents n’ont pas constaté de consensus approximatif et ont renvoyé cette version à la liste de discussion ; un avis d’août consigne le même résultat. DRAFT02 est arrivé le 25 septembre et sa page indique qu’il tient compte des échanges RPD et de l’évaluation d’impact. La décision de juin concerne DRAFT01, pas la version actuelle.

La révision limite ce que l’automatisation est censée décider et ajoute une vérification humaine. C’est une frontière probatoire plus nette, mais pas une garantie déjà testée. La prochaine étape devrait rendre le catalogue des tests consultable avec la politique appliquée : version, date d’effet, périmètre, source, logique, limites et compte rendu de vérification. Les membres et les opérateurs pourraient alors examiner le mécanisme avant qu’une alerte ne soit traitée autrement que comme une piste.

Sources et périmètre. La proposition DRAFT02 et l’index des propositions établissent le texte et le statut actuels. La DRAFT01 archivée et son évaluation d’impact fournissent l’ancienne rédaction et des exemples de contrôles. Le procès-verbal d’AFRINIC-37 et l’avis des coprésidents du 12 août documentent le retour de DRAFT01 à la liste. Aucun de ces documents ne prouve un déploiement ni un résultat concernant un membre.