Résumé

  • Le procès-verbal d'AFRINIC-37 rattache à MyAFRINIC v2 l'exécution complète des ROA AS0, le système technique des transferts et le travail interne sur le contact d'abus ; l'évaluation d'un projet AS-SET encore en Last Call place également sa réalisation après le portail.
  • Une dépendance commune ne crée pas un état commun. Trois textes sont ratifiés, le quatrième ne l'est pas ; leurs surfaces se trouvent dans RPKI, les procédures entre RIR, la validation interne, WHOIS et IRR.
  • La disponibilité d'un portail ne démontre ni l'activation d'une politique, ni sa conformité au texte, ni sa tenue après lancement. Un registre public doit relier chaque politique à une version du portail, des prérequis, des tests, une date d'effet et une procédure de correction.
  • Mutualiser l'infrastructure peut réduire les divergences des systèmes anciens et rendre les contrôles plus cohérents. Le danger apparaît lorsque le vocabulaire de programme — « lancé », « terminé » — remplace quatre conclusions d'acceptation qu'il ne suffit pas à établir.

Une équipe produit peut annoncer un portail en une phrase. Il est ouvert à telle date, accessible à tel public, dans telle version. Une politique ne devient pas opérationnelle aussi simplement. Elle doit avoir une autorité, une version, une interprétation appliquée, un système qui se comporte en conséquence, des usagers capables d'emprunter le chemin prévu et un moyen de corriger les résultats faux sans effacer leur histoire.

Autour de MyAFRINIC v2, cette différence est devenue un objet de contrôle en soi. Les propres documents d'AFRINIC décrivent quatre trajectoires qui attendent le même jalon ou passent derrière lui. Mais l'expression « derrière le portail » peut tromper. Elle ressemble à une file homogène alors qu'elle réunit quatre objets institutionnels et techniques distincts.

Le premier concerne les ROA AS0 pour les espaces d'adresses non alloués et non assignés. Le deuxième concerne les transferts de ressources numériques, dont certains supposent une coordination avec un autre registre régional. Le troisième concerne la validation du contact d'abus. Le quatrième est une proposition imposant des noms hiérarchiques aux nouveaux AS-SET. Les trois premiers textes sont ratifiés ; le quatrième demeure en Last Call dans le dossier vérifié.

Il n'est donc pas possible de demander si « les quatre politiques sont dans MyAFRINIC v2 » et d'en tirer une réponse utile. Il faut demander, pour chacune, quel seuil a été franchi, par quel test et sous quelle version du texte. L'enjeu n'est pas de prédire un échec. Les sources n'en établissent aucun. Il est de construire une preuve capable de reconnaître un succès sans lui attribuer davantage qu'il ne démontre.

Le calendrier ne vaut pas état de service

Le procès-verbal d'AFRINIC-37, réunion tenue le 24 juin 2026, replace MyAFRINIC v2 dans une histoire longue. Le développement avait commencé en 2020, puis rencontré plusieurs années de contraintes budgétaires et d'autres limites de ressources. Le projet avait été relancé et devait alors être mis en service avant la fin de 2026. Pour respecter ce calendrier, le périmètre devait être tenu afin d'éviter le scope creep.

La discipline de périmètre est un bénéfice possible, non une preuve de défaillance. Lorsqu'un portail relie identité des membres, droits d'action et registres de ressources, une version étroite et testable peut être préférable à une accumulation de fonctions. Une base commune peut également éliminer des règles contradictoires accumulées dans plusieurs systèmes. Le procès-verbal ne dit toutefois pas quelle fonctionnalité aurait été différée.

Il ne permet donc pas d'associer la maîtrise du périmètre à l'une des quatre politiques.

La page d'AFRINIC consacrée à l'AfPIF 2026 apporte un autre repère. Elle décrit MyAFRINIC v2 comme une reconstruction complète du portail libre-service. AFRINIC y sollicitait des contacts pour les tests d'acceptation utilisateurs et la bêta, ainsi que des entretiens courts sur les flux de travail. Le texte se situe « ahead of » ces étapes.

Il prouve une préparation et une invitation, pas l'achèvement d'une UAT, d'une bêta ou d'une mise en production.

Enfin, l'évaluation du projet AS-SET cite le 15 novembre 2026 comme date alors attendue pour MyAFRINIC v2. Le procès-verbal de juin parle plus largement de la fin de l'année. Il faut conserver les deux formulations avec leur provenance. Le 15 novembre appartient au plan d'impact AS-SET ; il n'est pas une échéance commune, encore moins la preuve que les quatre politiques doivent produire leurs effets le même jour. À la date de gel des sources, il n'était d'ailleurs pas encore arrivé.

Une date de calendrier peut donc décrire une intention. Elle ne décrit ni le périmètre livré, ni les essais passés, ni les politiques activées. La réception commence là où le calendrier s'arrête.

AS0 : une politique qui nomme déjà l'état partiel

Le registre actuel des politiques classe AFPUB-2019-GEN-006-DRAFT03, RPKI ROAs for Unallocated and Unassigned AFRINIC Address Space, comme ratifiée et Awaiting Implementation. Le procès-verbal de juin affine cette photographie. L'implémentation passait par des tests internes avec une évolution de KRILL. Une bêta était attendue à la fin du mois et devait être annoncée comme partly implemented.

L'exécution complète du texte dépendait du lancement de MyAFRINIC v2.

Ce vocabulaire a une vertu : il refuse de faire de la ratification, du test, du partiel et du complet un seul état. Mais il n'est utile que si le contenu de chaque état reste observable.

Pour AS0, le simple fonctionnement d'une page ne suffit pas. Il faut savoir quels objets sont couverts, quelle étendue des ressources est incluse, quelles exceptions demeurent, comment une erreur de publication est identifiée et corrigée, et quel événement permet de quitter l'état partiel. La source examinée ne fournit pas toute cette matrice. Elle ne permet donc pas d'affirmer que la bêta annoncée a eu lieu, ni de lui attribuer une couverture.

La réception devrait lier le texte ratifié, une baseline MyAFRINIC v2, la version opérationnelle pertinente de KRILL, les cas d'essai et les résultats de publication. Elle devrait aussi préserver la différence entre un contrôle interne réussi et une opération durable. Une mise en œuvre complète « as written » est une proposition falsifiable : elle doit dire ce qui serait observé si un objet attendu manquait ou si une correction ne suivait pas le chemin prévu.

Transferts : le portail n'est qu'un côté de la procédure

La présentation des politiques ratifiées date du 4 février 2026 la ratification de AFPUB-2020-GEN-006-DRAFT03, la Number Resources Transfer Policy. Selon AFRINIC-37, elle couvre les transferts intra-RIR et inter-RIR. La réciprocité avec les quatre autres RIR avait été confirmée en avril 2026.

Member Services travaillait avec ses homologues à la cartographie des procédures, tandis que le système technique devait être priorisé après le déploiement de MyAFRINIC v2.

La dépendance est ici à la fois logicielle et institutionnelle. Une demande peut entrer par un portail, mais un transfert inter-RIR ne s'achève pas dans ce portail. Il traverse des règles d'admissibilité, des pièces justificatives, une coordination de statuts, puis des mises à jour de registre et des avis aux parties. Une interface visible peut coexister avec une voie non encore acceptée de bout en bout. À l'inverse, une procédure manuelle ou interne peut être prête avant l'interface générale.

L'objet d'acceptation doit donc être une route précise. Pour chaque catégorie admissible, le registre devrait indiquer le préalable, l'état de la procédure avec la contrepartie, le test technique, le point où une décision devient attribuable, et la façon dont une interruption ou une erreur est reprise. Le premier transfert réussi, s'il est un jour annoncé, prouvera cette instance ; il ne prouvera pas automatiquement toutes les routes et toutes les catégories.

Cette analyse ne rouvre pas le débat sur les restrictions de sortie ou sur la valeur économique du texte. Son objet est plus sobre : empêcher qu'un écran de transfert soit pris pour la preuve d'un service complet, ou qu'un portail non général soit pris pour la preuve qu'aucun travail procédural n'existe.

Contact d'abus : accepter un workflow, pas un champ

Le même aperçu date du 4 février 2026 la ratification de l'Abuse Contact Policy Update AFPUB-2018-GEN-001-DRAFT07. Le procès-verbal dit que l'implémentation technique dans les systèmes internes devait être priorisée après l'achèvement du déploiement de MyAFRINIC v2.

Le statut de cette trajectoire ne peut être déduit de la présence d'un attribut abuse-c. Un workflow de validation comprend l'objet contrôlé, le déclenchement du test, l'envoi, le retour, l'échec, l'avis, le délai de correction, l'exception et l'éventuelle conséquence. Il faut aussi savoir quel texte gouverne chacun de ces passages.

Cette dernière exigence est décisive parce que la proposition a connu plusieurs versions. Un ancien Draft 2 a fait l'objet d'une analyse distincte chez BTW ; ses conséquences ne peuvent pas être transportées mécaniquement dans Draft 7. Une implémentation correctement attribuée doit citer AFPUB-2018-GEN-001-DRAFT07, sa date d'effet et les cas d'acceptation dérivés de ce texte.

Les pratiques internes et les interprétations historiques peuvent compléter la procédure ; elles ne doivent pas changer silencieusement l'autorité appliquée.

Une réception peut également être partielle de plusieurs façons. Le contrôle peut viser les nouveaux dossiers sans avoir traité les anciens. L'envoi peut fonctionner sans que la correction soit observable. Les procédures peuvent être prêtes alors que l'interface membre ne l'est pas. Ce sont des états légitimes s'ils sont nommés. Ils deviennent opaques lorsqu'un seul mot les absorbe.

AS-SET : la faisabilité précède l'autorité

AFPUB-2026-ASN-001-DRAFT02 se trouve dans une autre catégorie. Le registre le présente en Last Call, et les sources vérifiées n'établissent pas sa ratification. L'évaluation du personnel indique que les points d'entrée WHOIS et l'interface IRR de MyAFRINIC devraient empêcher la création de nouveaux AS-SET non hiérarchiques. Les objets existants ne seraient pas renommés. Le plan situe la priorité de réalisation après MyAFRINIC v2.

Évaluer cette réalisation avant la décision finale est rationnel. Un processus de politique ne devrait pas voter à l'aveugle sur un texte dont personne n'a étudié les systèmes touchés. Mais la faisabilité n'est pas l'autorité. Avant ratification, la bonne colonne du registre est « évaluation de proposition ». Après une éventuelle ratification, il faudra attacher l'implémentation au texte final et à sa date d'effet.

Le test devra aussi couvrir tous les chemins de création. Une règle appliquée dans l'interface MyAFRINIC mais contournable par un autre point WHOIS ne serait pas pleinement reçue. Le respect de la promesse sur les objets existants doit être testé séparément. Le système peut refuser une nouvelle création non conforme sans réécrire les données anciennes ; les deux résultats appartiennent au même contrat, mais pas au même cas d'essai.

Trajectoire État vérifié Dépendance déclarée Réception à démontrer
ROA AS0 Ratifiée, Awaiting Implementation, tests internes et bêta partielle projetée Le complet selon le texte dépend de MyAFRINIC v2 Couverture, frontière partiel/complet, corrections, activation et continuité de publication
Transferts Ratifiée le 4 février 2026, cartographie procédurale en cours Système technique après le portail Essais par route, coordination de contrepartie, résultat de registre, avis et reprise
Contact d'abus Ratifiée le 4 février 2026 Technique interne après le portail Liaison à Draft 7, validation, avis, correction, exceptions et limites de conséquence
Noms AS-SET Proposition en Last Call WHOIS et portail évalués ; priorité après MyAFRINIC v2 Ratification éventuelle, texte effectif, couverture de tous les points de création, protection des anciens objets

Le registre de réception

AFRINIC n'a pas besoin de rendre publics ses tickets, le code, les justificatifs des membres ou les détails de sécurité. Un registre compact suffit, à condition qu'il ne soit pas une page de communication réécrite à chaque étape.

Chaque ligne doit commencer par le titre, l'identifiant, la version et l'état juridique de la politique. Cette discipline empêche un système d'être associé rétrospectivement au mauvais draft. Elle laisse aussi la ligne AS-SET au stade de proposition tant que l'autorité n'a pas changé.

Vient ensuite la baseline du portail. Le nom MyAFRINIC v2 ne permet pas de reproduire un état. Une version, un identifiant de livraison ou une date de baseline doit montrer quel comportement a été testé. Si un correctif modifie la règle, il faut ajouter un événement, non remplacer l'affirmation précédente.

La classe de dépendance doit être explicite : interface, WHOIS, IRR, RPKI, workflow interne, migration de données, procédure externe. Cela empêche un succès sur la couche visible de valider par contagion un service en arrière-plan.

Pour chaque dépendance viennent le préalable, le responsable, le cas d'essai et le critère d'acceptation. Le responsable n'est pas désigné pour recevoir un blâme ; il est celui qui peut attester un résultat. Registry Products peut attester une baseline. Member Services peut attester la cartographie d'un transfert. L'équipe opérationnelle compétente peut attester une publication ou une validation. Le processus de politique reste la source de l'autorité du texte.

Le registre doit enfin dire qui a testé. Un contrôle interne, une UAT de membres et une bêta répondent à trois questions. Le premier vérifie la logique, la deuxième les droits et flux ordinaires, la troisième les interactions dans un contexte plus proche du réel. Les résultats peuvent être agrégés sans exposer les membres.

Une étiquette partielle exige une définition, un périmètre exclu et un événement de sortie. Une étiquette complète exige un avis, une date d'activation, une correction, un retour arrière et une fenêtre d'observation. La disponibilité du portail est un indicateur de plateforme ; l'issue d'une politique a besoin d'un indicateur propre.

Ce que les documents ne permettent pas de raconter

Les sources ne prouvent pas que MyAFRINIC v2 soit aujourd'hui en production. Elles ne prouvent ni UAT achevée, ni bêta achevée, ni ratification du projet AS-SET, ni exécution complète des trois politiques ratifiées. Elles ne décrivent aucune panne, aucune échéance manquée, aucun transfert rejeté, aucun contact invalide, aucune collision AS-SET et aucun effet de routage RPKI attribuable à la dépendance.

Cette absence impose une conclusion modeste. Le problème n'est pas un dysfonctionnement établi. Il est la nécessité de préserver quatre objets de preuve avant qu'une annonce générale ne les confonde.

AFRINIC a déjà employé des termes précis : Awaiting Implementation, test interne, partly implemented, cartographie de procédures, priorité après le portail, Last Call. Ces mots forment l'ébauche d'un registre. Il reste à les relier à des versions, des tests et des corrections.

MyAFRINIC v2 peut alors jouer son rôle de fondation commune. Il ne sera pas chargé de prouver, à lui seul, quatre réceptions qu'aucun portail ne peut signer en une fois.

Sources