Résumé

  • Le registre actuel du Conseil d’administration attribue la ratification d’AFPUB-2018-V6-004-DRAFT01 à la Résolution 201808.448, alors que le procès-verbal approuvé du 7–8 août imprime 201808.449 pour le même point. Or le registre réserve 201808.449 à un autre acte. Aucun document primaire examiné ne permet de transformer cette contradiction en certitude, ni de soutenir le numéro 201809.448.
  • La ratification du 8 août n’était pas une mise en œuvre achevée. Les Actions 201808.22 et 201808.23 distinguaient notification et exécution ; le CPM v1.3 a incorporé les sections 6.8–6.8.4 le 1er novembre ; à AFRINIC-29, fin novembre, l’automatisation des contrôles liés au routage et à la non-désagrégation restait en attente.
  • La réforme avait une utilité concrète : elle ouvrait la voie IPv6 PI à des sites terminaux sans passé IPv4 PI, organisait le dimensionnement initial et les demandes ultérieures, puis offrait une rectification unique. Cette utilité ne conférait toutefois à AFRINIC aucune souveraineté : un registre privé peut authentifier, attribuer sans duplication et tenir des données exactes, non gouverner les réseaux ni juger des droits publics.

Analyse

Le même acte sous deux références incompatibles

Il faut commencer là où le dossier résiste au résumé. Dans le registre public actuel des réunions du Conseil d’administration, la ratification de l’« IPv6 PI Update », identifiée exactement comme AFPUB-2018-V6-004-DRAFT01, porte le numéro de Résolution 201808.448. Dans le procès-verbal approuvé de la réunion tenue les 7 et 8 août 2018 à Maurice, le point 9.3 relatif à la même proposition imprime au contraire Résolution 201808.449.

Le désaccord ne peut pas être évacué comme une simple variante typographique sans conséquence, car le registre attribue justement 201808.449 à un acte différent : l’autorisation donnée au directeur général de signer le protocole d’accord avec l’hôte d’AFRINIC-29.

Un troisième repère complique encore la reconstitution. En septembre, la Résolution 201809.450 a approuvé le procès-verbal d’août « avec amendements », mais la trace publique examinée ne donne pas le texte de ces amendements. Elle ne dit donc pas si le numéro du point 9.3 a été corrigé, comment il l’aurait été, ni quelle version était considérée comme contemporaine de la décision. Surtout, aucune pièce primaire du corpus ne soutient l’étiquette 201809.448 parfois attachée à cet épisode. La date certaine de l’acte est le 8 août ; le code mensuel « 201809 » ne peut lui être greffé par commodité.

Cette incertitude impose une discipline simple : citer les deux références avec leur provenance. Le registre dit 201808.448 ; le procès-verbal dit 201808.449. Choisir silencieusement l’une et corriger l’autre donnerait au lecteur une certitude que les archives ne fournissent pas. Additionner les deux, ou inventer une résolution de septembre, produirait une nouvelle erreur. Un système de registre digne de confiance devrait permettre de relier sans ambiguïté l’acte, le texte adopté, son identifiant de proposition et sa date. Ici, le lien substantiel existe, mais son identifiant corporatif est fendu.

Pour un opérateur, aucun de ces documents ne constitue de toute façon une date magique à laquelle toute la chaîne serait devenue utilisable. Le registre prouve qu’AFRINIC publie une ratification sous une référence. Le procès-verbal prouve que le Conseil a examiné le point 9.3 et a consigné une ratification sous une autre référence. La résolution de septembre prouve l’approbation ultérieure du procès-verbal avec des amendements non exposés. Aucune de ces pièces, isolément, ne prouve que les formulaires, contrôles, instructions internes et mécanismes de traitement nécessaires étaient tous prêts.

Faire dépendre un plan d’adressage de l’unique numéro « qui semble le plus propre » reviendrait à confondre l’index d’une décision avec l’état réel du service.

Le procès-verbal demande une autre prudence. Il indique les initiales SO pour la proposition et SI pour l’appui du point IPv6 PI. Mais il n’imprime pas, après ce point, la phrase constatant une adoption unanime que l’on trouve pour les deux propositions de politique précédentes. L’absence de cette formule ne permet ni d’affirmer que le vote a été divisé, ni d’affirmer qu’il a été unanime. Elle oblige seulement à ne pas fabriquer un décompte. La proposition a été ratifiée ; le résultat détaillé du vote n’est pas établi par les pièces scellées.

Quatre étapes, et non un seul interrupteur

La chronologie devient intelligible dès qu’on sépare quatre états documentaires et opérationnels. Le premier est celui de la proposition. Le 28 mars 2018, AFPUB-2018-V6-004-DRAFT01 a été publiée pour modifier l’article 6.8 du Consolidated Policy Manual. Lors de la réunion AFRINIC-28, le 9 mai, la discussion a porté notamment sur la suppression de la dépendance à un historique IPv4 PI, la rectification de l’attribution initiale et la portée d’une disposition concernant le routage. Une objection a été enregistrée ; elle n’a pas entraîné de nouvelle version du texte à ce stade, et les coprésidents ont décidé le passage en Last Call.

Le Last Call n’était pas la ratification. Il appartenait au chemin interne du groupe de travail et fondait ensuite une recommandation des coprésidents. Une annonce de consensus ou une transmission au Conseil atteste ce qu’un processus privé a constaté selon ses règles ; elle ne vaut pas encore acte corporatif du Conseil, et moins encore service opérationnel. Cette distinction n’est pas une subtilité procédurale. Elle empêche qu’une proposition débattue soit présentée comme déjà disponible à un demandeur alors que le destinataire institutionnel n’a pas achevé ses propres étapes.

Le deuxième état est l’adoption corporative du 8 août. Réuni à Maurice, le Conseil a examiné AFPUB-2018-V6-004-DRAFT01 au point 9.3. La phrase opératoire publiée est étroite : après des considérants relatifs à l’achèvement du processus, au consensus et à la saisine par les coprésidents du PDWG, le Conseil ratifie la proposition. Elle ne transforme pas le Conseil en législateur. Elle dit ce que l’organe d’une société privée accepte pour son propre manuel et son propre service.

Les mesures qui suivent montrent que la décision n’était pas auto-exécutoire. L’Action 201808.22 chargeait la présidence d’informer les coprésidents du PDWG de la ratification. L’Action 201808.23 chargeait le personnel de mettre en œuvre les politiques ratifiées. Informer et mettre en œuvre sont consignés comme des tâches postérieures à l’acte. Le 21 août, l’annonce de la présidence a repris cette séquence au futur : le personnel allait procéder à la mise en œuvre, puis la communauté serait informée lorsque celle-ci serait accomplie. Le choix des temps verbaux importe davantage que le cérémonial du numéro.

Il établit qu’au 8 août la décision avait franchi la porte du Conseil, pas nécessairement celle de chaque opération de production.

Le troisième état apparaît le 1er novembre. L’historique de révision du CPM v1.3 date de ce jour l’incorporation de l’IPv6 PI Update. Les clauses se trouvent alors dans une version nommée du manuel, aux sections 6.8, 6.8.1, 6.8.2, 6.8.3 et dans la nouvelle section 6.8.4. Cette étape est importante : elle fournit au demandeur et au personnel un texte stabilisé et repérable, plutôt qu’une proposition flottante ou un compte rendu de réunion. Mais incorporation documentaire et capacité d’exécution ne sont pas synonymes.

Le quatrième état est précisément la qualification opérationnelle donnée fin novembre, lors d’AFRINIC-29. Le compte rendu indiquait que l’IPv6 PI Update était encore « en cours de mise en œuvre », dans l’attente de l’automatisation de contrôles relatifs au fait que l’espace attribué soit routé et ne soit pas désagrégé. Le document ne précise pas quelles demandes auraient pu être traitées manuellement, quelle clause était déjà pleinement utilisable, ni le jour où l’automatisation a finalement été terminée.

On peut donc affirmer l’existence du texte dans le CPM v1.3 au 1er novembre et l’inachèvement d’un pan de l’exécution à la fin du même mois ; on ne peut pas remplir l’intervalle par supposition.

Cette quadruple distinction fournit une meilleure notion de l’entrée en vigueur qu’un seul drapeau binaire. Le 28 mars établit la publication du projet. Le passage en Last Call établit un état de procédure. Le 8 août établit la ratification corporative, quelle que soit la référence conflictuelle. Le 1er novembre établit l’état du manuel. La fin novembre établit que l’état des outils n’avait pas rejoint complètement celui du texte. L’expression « la politique est entrée en vigueur » devient trompeuse si elle ne dit pas lequel de ces plans elle décrit.

Ce que le Conseil a adopté, et ce qu’il n’a pas fait

L’acte du 8 août a porté sur une proposition précise, non sur une compétence générale en matière d’IPv6. Son effet utile était de faire avancer une règle de service qui dissociait l’accès IPv6 PI d’un ancien parcours IPv4 PI. Cette ouverture répondait à une incohérence pratique : une organisation ayant besoin d’adresses IPv6 indépendantes de son fournisseur ne devait pas être forcée de justifier son admissibilité par un produit historique d’une autre famille d’adresses. La proposition organisait aussi le dimensionnement initial et une possibilité de corriger une prévision devenue inadéquate.

Il ne faut pourtant pas refaire ici tout le débat de la première version. Le sujet décisif n’est pas de raconter à nouveau chaque mérite de Draft 1, mais de comprendre la transformation d’un texte en acte, d’un acte en manuel, et d’un manuel en traitement réellement soutenu. C’est dans cette transformation que le conflit de numérotation prend son importance. Une politique peut être techniquement raisonnable et néanmoins mal documentée dans sa chaîne d’autorité interne. Inversement, un registre parfaitement numéroté ne suffirait pas à prouver qu’un contrôle automatique ou un circuit de demande fonctionne.

L’objet adopté restait celui d’un service d’attribution. AFRINIC pouvait définir, pour les demandeurs de ce service, les éléments nécessaires à la vérification de l’identité, du besoin, de la qualité de membre et du volume demandé. Il pouvait enregistrer un bloc unique et tenir les informations qui évitent une attribution en double. Le Conseil ne s’est pas vu attribuer, par le fait de ratifier le texte, un pouvoir public sur l’architecture des réseaux africains. Il n’a pas créé une loi continentale.

Il n’a pas obtenu de compétence policière sur le routage, de pouvoir de sanction publique ou de juridiction sur des opérateurs absents de ce contrat de service.

Ce cadrage n’enlève rien à l’intérêt de la traçabilité corporative. Au contraire, plus l’autorité est limitée, plus la précision du registre est essentielle. Une organisation privée ne peut pas s’appuyer sur une présomption générale de validité législative ; elle doit montrer exactement quelle règle contractuelle ou opérationnelle elle administre, dans quelle version, pour quel service et à quelle date. Le double numéro n’est donc pas la preuve d’un abus. Il est la preuve d’une lacune documentaire qu’il serait irresponsable de masquer.