Résumé

  • Publié le 17 février 2020, AFPUB-2020-GEN-001-DRAFT01 proposait un tableau de bord privé dans MyAFRINIC : chaque membre devait pouvoir consulter des indicateurs périodiquement réexaminés, recevoir des notifications et corriger des informations.
  • Les signaux envisagés ne formaient pourtant pas une catégorie unique. Un paiement manquant, une donnée WHOIS ancienne, une réponse tardive, une annonce de route et une question de transfert exigent des preuves, des règles et des degrés d’interprétation différents.
  • Une indication automatique peut déclencher une vérification, jamais créer à elle seule une faute ni un pouvoir de punir. Le registre technique tient les écritures utiles au fonctionnement du réseau ; il n’invente pas les droits qu’il consigne.
  • Le projet n’a pas obtenu de consensus à AFRINIC-32 en septembre 2020 et sa page officielle le classe désormais comme expiré. Il atteste une proposition de conception, non un système appliqué ni une sanction infligée à un membre.

L3 — Un écran, plusieurs catégories de preuves

La promesse concrète d’un écran commun

Imaginons le premier regard d’un responsable réseau ouvrant MyAFRINIC. Au lieu de parcourir plusieurs échanges de courriel, historiques de tickets et outils techniques, il trouverait une vue rassemblant des éléments qui, jusque-là, pouvaient être dispersés : paiement enregistré ou non, document présent ou manquant, réponse reçue, ressource annoncée, coordonnées WHOIS à jour, délégation de DNS inverse, information sur une sous-attribution PI, autorité déclarée pour un transfert et récurrence d’un problème.

Draft 1 présentait cette consolidation comme un moyen de revoir périodiquement la situation de chaque membre, avec autant d’automatisation que possible.

La promesse est sérieuse. Une organisation peut omettre une mise à jour sans mauvaise foi. Une adresse de contact peut devenir obsolète après le départ d’un salarié. Une donnée technique peut ne plus correspondre à l’exploitation réelle. Une facture peut être réglée tandis que son rapprochement tarde. Une demande du registre peut avoir reçu une réponse que le système n’a pas correctement rattachée au dossier. Rassembler ces signaux dans un espace réservé au membre peut réduire le temps consacré à chercher ce qui manque, permettre une correction plus tôt et éviter qu’un différend mineur ne se transforme en longue correspondance.

Le bénéfice ne vient toutefois pas du mot « conformité ». Il vient de fonctions beaucoup plus modestes : rendre une différence visible, identifier sa provenance, avertir la bonne personne, conserver la réponse, montrer la correction et laisser une trace des versions successives. Ce sont des fonctions de tenue de registre et de service. Elles peuvent améliorer l’exactitude sans préjuger de la signification juridique d’un écart.

La difficulté commence dès que l’interface résume ces éléments par un seul état. Le vert et le rouge semblent efficaces parce qu’ils réduisent la complexité. Ils donnent aussi l’impression que les faits ont déjà été qualifiés, comparés selon une règle certaine et tranchés. Or les éléments réunis par Draft 1 n’étaient pas équivalents. La simplicité visuelle n’abolit ni leurs différences ni les questions qu’elles soulèvent.

Neuf signaux, neuf chemins de vérification

Un paiement possède une date, un montant, une référence et un rapprochement comptable. Un document possède une origine, une version, une signature éventuelle et une question d’authenticité. L’absence de réponse dépend du message envoyé, du destinataire, du canal, de la date, de la clarté de la demande et de l’existence d’une réponse ailleurs dans le dossier. Chacun de ces objets peut produire une différence observable, mais pas selon le même test.

L’annonce d’une ressource relève d’un autre registre. Une observation de routage peut varier dans le temps et dépendre d’un contexte opérationnel. Elle ne dit pas à elle seule pourquoi une ressource est annoncée, ne l’est pas ou l’est par une organisation donnée. La fraîcheur d’une donnée WHOIS paraît plus directement vérifiable, mais « ancienne » n’est pas nécessairement synonyme de « fausse ». Une information stable peut demeurer correcte ; une information récemment modifiée peut être erronée. Le tableau doit donc distinguer l’âge d’une donnée de sa validité.

Le DNS inverse comporte encore d’autres dépendances techniques. Une délégation, une réponse de serveur et la cohérence d’un enregistrement peuvent être observées, mais la portée d’un écart doit rester explicitée. De même, une sous-attribution PI ou une question d’autorité de transfert ne se réduit pas à la présence d’une chaîne dans une base. Il faut savoir quel fait est recherché, quelle pièce l’établit, à quelle date et au titre de quel texte applicable.

Enfin, la répétition n’est pas une preuve autonome. Compter trois apparitions d’un même signal peut être utile pour orienter l’assistance ou déterminer qu’une vérification humaine est opportune. Mais trois mesures dérivées de la même source défectueuse ne deviennent pas trois violations. Trois alertes qui n’ont pas été remises à zéro après une correction ne prouvent rien de plus que la mauvaise mémoire du système. Une récurrence ne prend sens qu’avec une définition stable de l’événement compté, un moment de départ, une règle de remise à zéro, la conservation des corrections et une explication de ce que le compteur ne signifie pas.

Cette non-équivalence doit être visible dans l’architecture même de l’écran. Chaque ligne devrait former un objet distinct plutôt qu’alimenter un indice global. La ligne devrait nommer la source de données, la version de la règle ou de la clause invoquée, l’heure de la mesure, la nature objective ou interprétative du test, la marge d’incertitude et la dernière action connue. Un membre doit pouvoir comprendre non seulement qu’une case diffère, mais comment le registre est arrivé à cette observation.

De la couleur à la pièce vérifiable

Un tableau de bord fiable répondrait à des questions très concrètes. Le test a-t-il été exécuté aujourd’hui ou il y a trois mois ? Portait-il sur une règle en vigueur au moment considéré ? La source est-elle une donnée du registre, une observation extérieure ou une déclaration du membre ? Une valeur absente signifie-t-elle « non fournie », « non retrouvée » ou « non applicable » ? Le système distingue-t-il un écart certain d’une situation qui exige du contexte ? Le membre voit-il la même pièce que le personnel ?

Ces détails ne sont pas des ornements. Ils déterminent si l’outil permet une correction ou impose une énigme. Un état rouge sans date ni preuve oblige l’organisation à deviner ce qu’elle doit contester. Une alerte accompagnée de la donnée observée, du texte précis auquel elle est comparée et du moment de la comparaison permet une réponse ciblée. La qualité de l’interface se mesure ainsi à la distance qu’elle réduit entre l’observation et sa vérification, non à la force de l’étiquette qu’elle affiche.

La conservation de l’historique est tout aussi importante. Il faut pouvoir voir l’état initial, la notification envoyée, la réponse du membre, la modification effectuée, le nouvel examen et la raison pour laquelle le signal a été fermé ou maintenu. Sans cette suite, une correction efface peut-être le symptôme présent mais ne permet pas de comprendre le différend. Avec elle, le registre et le membre disposent d’une mémoire commune, susceptible de révéler une erreur récurrente de donnée, un problème de contact ou une règle mal comprise.

L’accès doit rester privé. La proposition envisageait que chaque membre consulte son propre état, et non une publication générale de fiches nominatives. Cette limite protège plus que la réputation. Une indication non vérifiée peut fournir à des tiers une image trompeuse d’une organisation, influencer une diligence commerciale ou révéler des points de friction opérationnels. Le principe adéquat est donc celui de la divulgation minimale : la personne concernée et les agents qui doivent traiter la correction voient le détail ; les autres n’en déduisent pas une culpabilité par simple exposition.

Ce que Draft 1 proposait réellement

La chronologie évite de confondre une idée avec un mécanisme en vigueur. L’instrument AFPUB-2020-GEN-001-DRAFT01, intitulé Policy Compliance Dashboard Draft 1, a été soumis le 17 février 2020 en version 1.0. Sa page officielle nomme Jordi Palet Martinez, Frank Habicht, Mark Elkins et Haitham El Nakhal comme auteurs. Le texte proposait une révision périodique de l’état de chaque membre dans MyAFRINIC, des notifications après les examens ou mises à jour, des rappels périodiques lorsqu’un manque de conformité restait affiché et des avertissements au personnel.

Le même texte allait au-delà d’un service de visibilité. Une clause distincte envisageait une enquête plus exhaustive et des actions ultérieures au titre du RSA lorsque des éléments suggéraient une non-conformité. La gradation proposée comprenait la prise de contact et la rectification, puis la publication, la suppression d’enregistrements de serveurs de noms pertinents, la récupération, la rétention de services, la révocation et la fermeture de l’adhésion.

Le texte envisageait aussi que le Board prolonge un délai de révocation pour une infrastructure stratégique essentielle ou des circonstances exceptionnelles, après appréciation du personnel.

Il faut tenir ensemble ces deux dimensions sans laisser la seconde redéfinir la première. Un tableau privé peut rendre service. Une liste de conséquences sévères soulève une question indépendante : d’où vient, pour chacune, le pouvoir valable de l’appliquer à cette partie, sur cette preuve et dans ces circonstances ? L’existence d’une case dans MyAFRINIC ne répond pas à cette question. Le fait qu’une enquête soit dite plus exhaustive ne la résout pas davantage.

L’évaluation d’impact publiée par AFRINIC en août 2020 a elle-même mis en lumière des distinctions et des difficultés de mise en œuvre. Elle séparait la non-conformité à une politique de la non-conformité contractuelle et mentionnait des outils existants concernant notamment le paiement et le DNS inverse, sans tableau consolidé. Elle reproduisait un chemin de notification et de correction tiré du RSA : notification écrite, invitation à expliquer ou remédier, délai de trente jours pour répondre, puis cessation du processus si AFRINIC jugeait l’explication ou la correction satisfaisante.

Ce chemin montre pourquoi un indicateur ne peut pas constituer le dernier mot. Même dans le cadre décrit par AFRINIC, une notification ouvre une possibilité d’explication et de correction. L’évaluation demandait en outre des précisions sur le seuil des violations répétées ou continues, sur la remise à zéro de leur compteur, ainsi que sur les mécanismes de publication, de suppression d’objets de domaine et de quarantaine. Elle prévoyait un développement important de MyAFRINIC, du travail pour Member Services et la possibilité de personnel supplémentaire.

La prétendue simplicité du voyant recouvrait donc des décisions de définition, de traitement, de logiciel et de responsabilité humaine.

Le meilleur cas en faveur de la visibilité

Une analyse rigoureuse doit reconnaître le meilleur argument en faveur du projet. Les membres peuvent manquer une modification de politique ou de contrat. Les équipes changent. Les boîtes de réception se remplissent. Les données de contact vieillissent. Des outils séparés peuvent donner des réponses difficiles à rapprocher. Une vue privée et ordonnée peut faire apparaître tôt un renseignement obsolète, assurer que des organisations placées dans une situation comparable reçoivent une notification comparable et réduire les échanges nécessaires pour localiser une anomalie.

Un tel écran peut aussi discipliner le registre. Pour afficher l’origine d’un signal, AFRINIC devrait expliciter la donnée utilisée. Pour indiquer la version d’une règle, elle devrait conserver ses changements. Pour montrer une correction, elle devrait relier la réponse du membre au test initial. Pour permettre une révision humaine, elle devrait enregistrer les raisons de confirmer ou d’écarter l’alerte. L’utilité est alors réciproque : le membre sait ce qui lui est demandé et le registre devient plus responsable de la qualité de ses propres observations.

Cette version bénigne n’exige ni accusation générale ni conséquence automatique. Elle peut débuter par un mode exclusivement informatif. Elle peut traiter les signaux objectifs comme des invitations à vérifier et les questions qualitatives comme des demandes de contexte. Elle peut fermer automatiquement une différence purement technique une fois la donnée corrigée tout en conservant l’historique. Elle peut orienter vers un agent les cas ambigus sans conférer à cet agent un pouvoir nouveau.

Le point de conception décisif est donc une séparation : observer, notifier, corriger et revoir sont quatre étapes de service ; punir en serait une cinquième, juridiquement distincte, qui ne découle d’aucune des quatre précédentes. Plus le tableau rend cette séparation lisible, plus il est utile. Plus il compresse les étapes dans un statut unique, plus il risque de produire une apparence de certitude et d’autorité que ses données ne soutiennent pas.

Une proposition restée proposition

La réunion AFRINIC-32 de septembre 2020 a consigné à la fois un soutien à une meilleure visibilité et des préoccupations concernant la redondance opérationnelle, le coût, les ressources nécessaires et l’efficacité des notifications automatiques. Les co-présidents ont conclu à l’absence de consensus et renvoyé la discussion à la liste de diffusion. La page officielle classe aujourd’hui Draft 1 comme expiré.

Ces faits ferment la porte à plusieurs raccourcis. Ils ne permettent pas d’écrire que le tableau a été adopté ou ratifié. Ils ne prouvent pas sa mise en œuvre. Ils ne prouvent pas qu’un calcul automatisé a été correct, qu’un membre réel a été visé, qu’une sanction a été prononcée, qu’une ressource a été révoquée, qu’une adhésion a été fermée ou qu’une perte chiffrée a eu lieu. Draft 1 est un document sur une architecture envisagée et sur les pouvoirs qu’elle risquait de sembler relier. C’est précisément à ce niveau — celui du dessin institutionnel — qu’il doit être examiné.