Résumé

  • Le report annoncé le 8 mai donnait jusqu'au 17 mai pour transmettre les observations sur les statuts au moyen d'un formulaire en ligne désigné.
  • Le 13 mai, AFRINIC a indiqué que l'hôte forms.afrinic.net était temporairement indisponible. L'avis promettait une mise à jour après rétablissement, sans publier l'heure de début, l'heure de retour ni un canal de secours.
  • Rien ne prouve qu'une contribution ait été perdue. L'absence concerne la preuve de continuité : disponibilité, accusés de réception, nouvelles tentatives, dédoublonnage et concordance avec le corpus examiné.

Le 17 mai figurait toujours au calendrier. La voie qui conduisait à cette date, elle, avait cessé d'être vérifiable.

La première consultation prévoyait initialement une période du 20 avril au 10 mai 2026. Membres, parties prenantes et communauté Internet étaient invités à proposer des modifications. Le message archivé du 19 avril donne une adresse précise : forms.afrinic.net/brc-comment.

Le 8 mai, AFRINIC a repoussé la clôture au 17 mai, afin de laisser davantage de temps pour préparer des remarques complètes. La copie diffusée sur la liste Announce a été archivée le 9 mai à 13 h 41 min 12 s UTC. La page et le courriel renvoient au même formulaire. Ils n'indiquent ni adresse électronique, ni liste publique, ni second formulaire susceptible de prendre le relais.

Quatre dates civiles avant la nouvelle échéance, l'avis de maintenance décrit un problème technique et un hôte indisponible. Il ne date pas l'incident à l'heure près. Il ne précise pas si toutes les routes du domaine étaient touchées, si l'URL des commentaires refusait effectivement chaque requête, ni quand un test a confirmé le retour du service. Compter du 13 au 17 mai ne permet donc pas de fabriquer une durée de panne de quatre jours.

Cette retenue est essentielle. Les sources consultées ne montrent aucune personne empêchée de participer. Elles ne recensent ni échec, ni plainte, ni texte perdu. Elles montrent seulement que la promesse d'accès et l'interruption annoncée ne sont pas reliées par un enregistrement public complet.

Trois seuils, et non un seul envoi

Une contribution traverse au moins trois états. L'utilisateur tente de transmettre le texte. La plateforme l'accepte et produit idéalement un accusé de réception. Le comité l'intègre ensuite à son registre d'analyse.

tentative → acceptation technique → prise en charge éditoriale

Une page d'erreur ne crée pas forcément une ligne côté serveur. Une réponse positive peut ne pas parvenir au navigateur. Une nouvelle tentative peut engendrer un doublon. Enfin, un objet accepté peut rester dans une file sans atteindre le tableau utilisé par le comité.

Les termes de référence du Comité de révision rendent cette chaîne particulièrement importante. Le comité doit mettre au point des mécanismes de soumission, assurer l'accessibilité publique des contributions et des sources, puis expliquer les contributions reçues et la manière dont chacune a été traitée.

Le lancement du second tour, le 4 août, affirme que toutes les contributions reçues ont été étudiées, individuellement et collectivement. C'est une information utile sur le corpus accepté. Ce n'est pas une mesure des tentatives qui n'auraient pas franchi le formulaire. Les deux propositions peuvent être vraies en même temps.

Le reçu de continuité

Le contrôle nécessaire est modeste. Un reçu public commencerait par l'identité de la consultation, l'empreinte de la version soumise, l'ouverture, l'instant exact de clôture et le fuseau horaire. Il énumérerait tous les canaux autorisés, au lieu de laisser une adresse devenir de fait l'unique porte.

Lors d'un incident, il noterait la détection, l'avis public, l'opération affectée, le rétablissement et la méthode de vérification. Il distinguerait l'indisponibilité générale de l'hôte de l'impossibilité précise d'accepter un commentaire valide. Cette dernière affirmation exige des éléments que l'avis du 13 mai ne fournit pas.

La partie publique ne doit contenir ni texte confidentiel, ni coordonnées, ni adresse IP, ni journal de sécurité. Des nombres agrégés suffisent : soumissions acceptées, erreurs observées, nouvelles tentatives, doublons, envois tardifs et dossiers finalement rapprochés. Chaque auteur pourrait conserver un identifiant aléatoire d'accusé de réception et vérifier sa présence sans révéler son identité.

Le dédoublonnage mérite une règle. Le second envoi d'un texte dont le premier a échoué ne doit pas être écarté comme doublon sans preuve de la première acceptation. À l'inverse, deux envois réussis ne doivent pas compter pour deux voix. Le reçu doit conserver l'état et la raison du rapprochement.

La compensation du délai constitue un autre champ. Une brève interruption avec une solution de secours testée peut ne justifier aucun report. Une panne proche de la clôture peut appeler du temps supplémentaire. L'enjeu n'est pas d'imposer une prolongation automatique, mais de rendre la décision et son fondement lisibles.

Le formulaire faisait partie de la procédure

forms.afrinic.net n'était pas un élément décoratif du site. Les deux appels le désignaient comme le passage par lequel une opinion devenait une pièce du dossier constitutionnel. Sa disponibilité relevait donc de l'exécution de la consultation.

Cela ne transforme pas AFRINIC en autorité publique et ne permet pas de conclure à l'invalidité du projet ultérieur. AFRINIC reste une société privée de registre. L'obligation est proportionnée à son propre engagement : lorsqu'elle choisit une interface unique pour recevoir la participation, elle doit pouvoir expliquer les interruptions matérielles de cette interface.

L'index actuel des actualités conservait, lors de la capture, le report et la maintenance. Aucune annonce distincte de rétablissement n'y a été identifiée. Cette observation est limitée à l'index vérifié. Une communication a pu exister sur une page d'état, par message direct ou ailleurs. Le meilleur remède est précisément de relier l'événement de retour à l'avis qui le promettait et à la consultation concernée.

Ce que le dossier ne dit pas

Le « problème technique » n'autorise aucune conclusion sur une attaque, une fuite ou les services de registre. Il ne dit rien de WHOIS, RDAP, RPKI ou de la base des ressources. Il ne chiffre ni durée, ni volume d'échecs.

La publication ultérieure du projet n'est pas non plus la preuve qu'aucun problème n'a existé. Elle appartient à l'étape suivante. Un registre commentaire-décision explique le sort des textes reçus; un reçu de continuité explique comment ils ont pu entrer. Confondre ces deux contrôles ferait disparaître le seuil le plus fragile.

Sources