Résumé

  • Le noyau utile du projet du 12 août 2018 était simple : imposer un champ abuse-c aux ressources directement attribuées et vérifier objectivement que la boîte associée restait joignable.
  • Son dispositif allait pourtant bien au-delà de la délivrabilité. Il imposait une intervention humaine, interdisait le filtrage et le passage obligé par un formulaire web, puis exigeait une attestation portant sur les mesures prises et sur la réponse donnée aux signalements.
  • La séquence de deux puis trois jours ouvrables comprimait une correction de donnée dans un parcours d’escalade : invalidité temporaire, invalidité permanente et, lors d’un nouvel échec, violation de la politique susceptible d’entraîner un suivi lié notamment aux procédures de révocation.
  • Ce mécanisme exposait les opérateurs à des coûts et à des risques sans établir qu’un message était fondé, qu’un réseau avait négligé un abus réel ou qu’une autorité compétente avait constaté une faute.
  • La solution proportionnée est un contact de rôle joignable, un test technique prévisible, une notification, un délai de correction significatif et un état public de qualité des données, sans aucune conséquence sur le contrôle reconnu des ressources numériques.

L3 — La mécanique des cinq jours

Le détail le plus révélateur du premier projet n’est pas le nom du champ proposé, mais le petit rituel censé prouver sa validité. AFRINIC devait envoyer deux messages consécutifs, tous deux en texte brut. L’un contenait une adresse à ouvrir ; l’autre, un code unique à reporter sur une page protégée par CAPTCHA. La personne placée devant cette page ne confirmait pas seulement que le courriel avait atteint sa destination. Elle devait aussi accepter une déclaration beaucoup plus large : la boîte était régulièrement surveillée, des mesures étaient prises et un signalement d’abus recevait une réponse.

Deux jours ouvrables au maximum étaient accordés pour accomplir cette opération.

Si le code restait inutilisé à l’expiration de cette première période, le contact était marqué comme temporairement invalide. Le personnel devait alors se tourner vers le registre Internet local concerné et accorder une seconde période ne dépassant pas trois jours ouvrables. Sans correction, l’invalidité devenait permanente. Le texte ne s’arrêtait pas à un constat visible dans la base : il prévoyait une nouvelle validation et disposait qu’un échec répété serait considéré comme une violation de la politique.

D’autres passages envisageaient un suivi plus approfondi selon les politiques ou procédures pertinentes d’AFRINIC, en visant spécialement celles qui concernaient la révocation des ressources. La somme de deux et trois jours formait ainsi bien davantage qu’un contrôle d’adresse. Elle reliait une interaction électronique, une attestation de conduite et la possibilité d’une conséquence sur la relation de registre.

Cette architecture figurait dans l’« Abuse Contact Policy Update Draft 1 », AFPUB-2018-GEN-001-DRAFT01, soumis par Jordi Palet Martinez le 12 août 2018. Il proposait de remplacer la section 8.0 du manuel consolidé des politiques. Le statut historique importe : il s’agissait d’un projet en discussion, non d’une règle alors adoptée ou mise en œuvre. L’analyse porte donc sur le pouvoir que ce texte cherchait à construire, pas sur une révocation qui aurait été prononcée en son nom.

Aucun cas individuel ne permet d’affirmer qu’une ressource a été retirée, qu’un membre précis a été bloqué ou qu’un électeur a été privé de vote en application de cette première version.

Le changement partait d’un régime antérieur plus souple. Une politique ratifiée en 2011 et donnée comme mise en œuvre en 2012 avait créé un objet IRT spécialement conçu pour les informations de contact relatives aux abus. Les objets inetnum, inet6num et aut-num pouvaient y faire référence, mais cette référence demeurait facultative ; AFRINIC encourageait son usage comme bonne pratique. Ce dispositif fournissait donc déjà un emplacement consacré sans garantir que chaque ressource directement attribuée conduise le chercheur à une adresse évidente et actuelle. Le premier projet de 2018 voulait fermer cette lacune.

Son point de départ était défendable. Chaque ressource allouée directement par AFRINIC devait comporter, dans l’entrée WHOIS correspondante — inetnum, inet6num ou aut-num — un contact abuse-c obligatoire. Au moins une boîte dédiée aux abus devait être valide, surveillée et gérée activement. Les objets enfants pouvaient hériter du contact de leur parent ou publier leur propre référence.

Une même convention de données, visible dans WHOIS, accessible par les interfaces de programmation et par de futures techniques, pouvait éviter au plaignant de deviner si l’adresse pertinente était abuse@, security@, un contact administratif ancien ou une boîte générale jamais consultée.

Dans sa version la plus solide, l’idée répondait à une défaillance concrète. Lorsqu’un opérateur, un centre de réponse aux incidents ou un utilisateur découvre une campagne de hameçonnage, une machine compromise ou une activité malveillante provenant d’un espace d’adresses, il a besoin de savoir à quelle équipe transmettre des éléments vérifiables. Une donnée uniforme réduit le temps de recherche, le nombre de messages envoyés au mauvais destinataire et le délai avant que le détenteur du réseau puisse examiner le problème. Une validation périodique peut repérer une boîte abandonnée après un départ, un domaine expiré ou une réorganisation.

Un registre dont les coordonnées publiques mènent systématiquement à des impasses ne remplit pas correctement son rôle de répertoire.

La proposition cherchait aussi à empêcher un contournement rudimentaire : une adresse qui répondrait uniquement au message connu du test tout en ignorant les communications ordinaires. Elle autorisait AFRINIC à modifier les domaines d’envoi, les objets et le contenu de certains messages de validation. Un accusé automatique initial restait possible. De tels choix montrent que les auteurs ne visaient pas seulement une chaîne de caractères syntaxiquement valide ; ils voulaient qu’un véritable bureau puisse être atteint. Cette préoccupation conserve une valeur opérationnelle.

Une boîte factice, ou configurée uniquement pour réussir un essai prévisible, ne rend service ni au public ni au titulaire de la ressource.

Mais le texte changeait de catégorie lorsqu’il définissait ce que le bureau destinataire devait faire. Tout message envoyé à la boîte devait nécessiter à un moment une intervention manuelle. Il ne pouvait pas être filtré. Le déclarant ne pouvait pas être obligé de remplir un formulaire web. Ces prescriptions ne vérifiaient plus la présence d’un chemin de communication ; elles imposaient une conception du système de traitement.

Un opérateur pouvait utiliser un outil de tickets, des filtres antipourriel, une quarantaine pour pièces jointes, une vérification de réputation ou un portail structuré afin d’obtenir l’horodatage, les en-têtes et les traces nécessaires. Le projet tendait à juger ces décisions depuis l’extérieur, sans connaître la menace, le volume de messages ni l’organisation interne du réseau.

La case à cocher renforçait ce déplacement. Confirmer que la boîte est surveillée reste proche de la qualité de la donnée. Affirmer que des « mesures » sont prises et que chaque signalement reçoit une réponse est autre chose. Quelles mesures suffisent devant une accusation incomplète ? Une réponse automatique compte-t-elle ? Faut-il informer le déclarant d’une enquête interne ? Que faire lorsqu’un client en aval contrôle le serveur visé, lorsqu’un message est une tentative d’extorsion, ou lorsque la divulgation d’une mesure compromettrait une investigation ?

Le projet créait une obligation générale sans fournir l’institution compétente pour trancher ces questions contradictoires.

La fréquence ajoutait une dimension de surveillance. La validation devait intervenir lors de la création ou de la modification de l’objet, puis périodiquement au moins une fois tous les trois mois, et encore chaque fois qu’AFRINIC le jugerait opportun. Création et modification sont des moments compréhensibles : le registre vérifie la donnée qui vient d’être inscrite. Un cycle régulier peut également être justifié si son objet demeure la seule délivrabilité. En revanche, une faculté discrétionnaire illimitée, combinée à une attestation de comportement et à des conséquences croissantes, rend l’interaction imprévisible.

Le même champ qui devait renseigner le public devenait le point d’entrée d’un contrôle récurrent.

L’évaluation du personnel datée elle aussi du 12 août 2018 confirme la façon dont l’organisation comprenait l’instrument. Elle relevait le caractère obligatoire d’abuse-c sur les objets inetnum, inet6num et aut-num directement attribués, le contrôle à la création et au moins trimestriel, ainsi que le traitement d’un échec de vérification comme violation de la politique. Elle estimait à au moins un mois et demi le développement, les essais et le déploiement nécessaires. Elle ne consignait aucun commentaire du conseil juridique.

Cette absence n’établit pas que le projet était illégal ; elle montre simplement que l’évaluation officielle ne fournissait pas d’analyse juridique capable de transformer un mécanisme privé de base de données en compétence coercitive.

Le texte prévoyait en outre une intermédiation d’AFRINIC dans l’escalade de certains signalements. Là encore, aider un déclarant à identifier le bon contact peut être un service de coordination. Recevoir un dossier, apprécier si le membre a réagi et rapprocher l’issue d’une procédure de révocation produit une tout autre relation. Le registre n’est plus seulement le plan qui indique une porte ; il devient celui qui observe ce qui se passe derrière cette porte et qui menace de changer les conditions d’accès à une ressource essentielle si la réaction ne lui paraît pas conforme.

Il faut aussi maintenir les frontières chronologiques. La deuxième version a été publiée le 20 novembre 2018. La discussion d’AFRINIC-29, le 29 novembre, a porté ensuite sur les contacts vérifiés, les restrictions de MyAFRINIC, les effets possibles sur l’accès au vote, la proportionnalité des sanctions et l’objection selon laquelle le registre risquait de se comporter en « police de l’Internet ». Les coprésidents ont constaté l’absence de consensus et renvoyé la proposition à la liste. Le rapport annuel 2018 a lui aussi décrit la proposition dans un contexte où la deuxième version existait déjà.

Ces éléments éclairent le désaccord que la mécanique suscitait, mais ils ne doivent pas être replacés mot pour mot dans le projet du 12 août.

La même prudence vaut pour la septième version, soumise le 17 mai 2021, et pour son statut ultérieur décrit comme ratifié dans les documents disponibles au 4 février 2026. Sept versions successives signalent précisément que le texte a changé. Ni les formulations ultérieures, ni les recours, ni un consensus ou une ratification postérieure ne peuvent être projetés rétrospectivement sur AFPUB-2018-GEN-001-DRAFT01. Le premier projet a sa propre portée : rendre abuse-c obligatoire, tester la boîte selon un protocole précis, exiger une conduite déclarée et associer les échecs à un parcours de non-conformité.

Cette précision historique évite deux erreurs opposées. La première serait de minimiser l’instrument au motif qu’il n’était qu’un projet. Un texte en discussion mérite d’être examiné lorsqu’il dessine un mécanisme capable d’exercer une pression réelle s’il est adopté. La seconde serait de raconter cette pression comme un dommage déjà prouvé. Le dossier établit une exposition proposée, pas l’usage effectif de cette exposition contre un titulaire nommé.

Ce que l’on peut établir avec rigueur est plus circonscrit et déjà significatif : la structure des sections 8.2 à 8.7 faisait passer l’adresse publique de l’état de donnée vérifiable à celui de point de contrôle sur la réponse opérationnelle.

Le cœur du problème apparaît donc avant toute spéculation sur un cas futur. Un message a-t-il été délivré ? Voilà une question technique susceptible d’une réponse observable. La personne a-t-elle « pris des mesures » ? A-t-elle répondu de manière appropriée ? Son filtre était-il acceptable ? Son portail demandait-il trop d’effort ? Ces interrogations supposent des faits, des normes, des responsabilités, des preuves contradictoires et parfois un droit applicable. Le protocole de cinq jours les rapprochait toutes d’une même case, puis d’un même statut d’invalidité.

Il confondait la qualité du chemin de contact avec la qualité du traitement de l’affaire.