Résumé

  • La page officielle d’AFRINIC sur l’AfPIF 2026 présente MyAFRINIC v2 comme une refonte complète du portail en libre-service destiné aux membres.
  • AFRINIC y recherchait des contacts pour la recette utilisateurs et le programme bêta, ainsi que pour de courts entretiens portant sur les pratiques et les améliorations attendues.
  • Cette même page annonçait une présentation le 19 août, mais elle ne démontre ni que la session a eu lieu, ni que les entretiens, les tests ou la bêta ont commencé.
  • La source ne publie pas le nombre de participants, le périmètre de la recette, les critères d’acceptation, les anomalies, les résultats de migration ou une date de mise en production.

1. Une invitation vérifiable n’est pas une validation du portail

Le choix de solliciter des membres est défendable. Un portail de registre ne se résume pas à une interface bien présentée. Il doit permettre à des organisations de demander des ressources, de modifier leurs contacts, de suivre la facturation et d’effectuer les consultations nécessaires au quotidien. Les personnes qui réalisent réellement ces opérations peuvent repérer des écarts qu’une équipe produit ne voit pas dans une démonstration préparée.

La page officielle d’AFRINIC établit l’intention. Elle décrit MyAFRINIC v2 comme une refonte complète du portail en libre-service et indique qu’AFRINIC recueillait les réactions de la communauté avant une phase de recette utilisateurs et une bêta accessible en conditions réelles. Elle invite des contacts de membres à participer au programme de test et à de courts entretiens sur leurs méthodes de travail et les améliorations souhaitées.

Le calendrier publié constitue une autre couche de faits, plus limitée. La page situe l’AfPIF à Kigali du 17 au 20 août 2026, puis mentionne une réunion des membres le 21 août. Une intervention d’AFRINIC sur ses services, MyAFRINIC v2 et le processus d’élaboration des politiques y était programmée le 19 août à 11 heures. Le fuseau horaire de cette séance et la date de publication initiale de la page ne sont pas indiqués.

Au 28 août, ces dates étaient passées. Cela ne transforme pas un programme en compte rendu. La source disponible ne précise pas si la présentation s’est tenue, combien de personnes se sont portées volontaires, si les entretiens ont été réalisés ou si un environnement de recette a été ouvert. Elle n’identifie ni la version présentée aux testeurs, ni les parcours effectivement disponibles, ni les critères d’acceptation, ni les anomalies constatées.

Il faut donc maintenir une frontière simple. L’invitation atteste qu’AFRINIC voulait recueillir des contributions avant le lancement. Elle n’atteste pas que MyAFRINIC v2 est complet, sécurisé, accessible, accepté ou prêt pour la production. Elle ne prouve pas davantage qu’une identité de membre a été validée, qu’une demande de ressources a abouti, qu’un solde de facturation est exact ou que des données ont été migrées correctement.

2. La bonne unité de preuve est un parcours métier

Une liste d’anomalies isolées ne suffit pas à gouverner la recette d’un portail de registre. Pour décider si une version peut entrer en bêta, il faut savoir quelle tâche un membre cherchait à accomplir, avec quel rôle, dans quel environnement et selon quel résultat attendu. Sans ces liens, une mention comme « mise à jour du contact échouée » ne dit pas si le problème vient des droits, de la validation, des données, d’une intégration ou du code visible.

Chaque exercice devrait donc commencer par un identifiant de parcours et un résultat métier précis. Pour une modification de contact, le dossier peut distinguer l’acteur autorisé, la nature du changement, les validations nécessaires, l’état attendu dans les systèmes du registre et la notification que le membre doit recevoir. Pour une demande de ressources, il peut indiquer les préconditions, les étapes critiques et le point où une décision humaine reste nécessaire.

La représentativité mérite également un enregistrement, sans publier l’identité des participants. Un résumé respectueux de la vie privée peut montrer si la recette a couvert différents types et tailles de membres, plusieurs rôles opérationnels et des besoins d’accessibilité pertinents. Il ne s’agit pas de transformer quelques volontaires en échantillon statistique parfait. Il s’agit de rendre visible ce que les tests couvraient et ce qu’ils ne couvraient pas.

La version et l’environnement doivent rester attachés au résultat. Une anomalie sans numéro de build, fenêtre d’exécution, environnement et règle sur les données ne peut pas être reproduite de manière fiable. Les tests doivent aussi distinguer les données synthétiques ou masquées des données réelles, ainsi que les services connectés qui sont simulés de ceux qui fonctionnent réellement. Cette séparation est essentielle lorsque le parcours touche à l’identité, à la facturation ou aux ressources enregistrées.

3. Relier le défaut à la décision de bêta

Le registre proposé n’est pas un simple outil de suivi technique. Sa fonction est de conserver la chaîne de décision depuis l’observation d’un membre jusqu’à l’état de la version. Le dossier minimal peut être organisé ainsi :

Étape Preuve contrôlée Vue publique possible
Recrutement Éligibilité, consentement et rôle du participant Couverture de la cohorte et état du recrutement
Parcours Préconditions, étapes, données et résultat attendu Identifiant et état de couverture du parcours
Exécution Build, environnement et horodatage Version et période de test
Constat Éléments de reproduction et données affectées Identifiant, classe, gravité et parcours concerné
Traitement Responsable, motif et autorité d’exception Corrigé, reporté, rejeté ou limitation acceptée
Nouveau test Build corrigé, résultat et périmètre de régression État de vérification et version validée
Décision bêta Approbation, limites et voie de repli Inclus ou exclu, avec motif institutionnel

La décision de traitement est le point où une anomalie devient un acte institutionnel. Un constat peut être corrigé, différé, jugé non reproductible, classé hors périmètre ou accepté temporairement. Chacune de ces issues devrait porter un responsable et une raison. Si une limitation est admise dans la bêta, le dossier devrait préciser l’autorité qui l’a acceptée, les utilisateurs concernés, la mesure compensatoire et la condition de clôture.

Une correction ne devrait pas fermer automatiquement la chaîne. Le nouveau test doit référencer à la fois le défaut et le build qui contient le correctif. Il doit aussi indiquer le périmètre de régression. Un changement qui répare l’authentification peut affecter l’autorisation de contact ou d’autres parcours ; un ajustement de migration peut modifier des données voisines. Un résultat positif sur un cas unique ne permet pas de conclure que les fonctions connexes restent intactes.

Enfin, la décision de bêta doit pouvoir être reconstruite. Quels parcours ont été inclus ? Quelles limites demeuraient ouvertes ? Qui a estimé que le risque était acceptable ? Quel canal d’assistance et quelle solution de repli étaient disponibles ? Le registre ne retire pas à l’équipe ou à l’institution son pouvoir d’appréciation. Il empêche que les raisons disparaissent une fois la réunion terminée.