Résumé

  • L’engagement de niveau de service d’AFRINIC, affiché comme Version 1 de novembre 2015, promet une réponse effective dans les deux jours ouvrables pour toute demande adressée à l’équipe des opérations. La table qui suit comporte douze files nommées.
  • L’annuaire des courriels d’assistance en propose seize, avec une terminologie partiellement différente. La page Contact Us ramène encore le choix à trois adresses générales et à un formulaire sans catégorie de service visible.
  • Rien dans ces pages ne prouve qu’une demande a été perdue ou que le délai a été dépassé. Elles ne publient cependant pas la correspondance qui indiquerait quelle file reçoit chaque entrée et si un transfert conserve l’heure du premier dépôt.
  • Une table de routage publique, datée et versionnée permettrait de garder à la fois la simplicité du guichet général et la précision des canaux spécialisés, sans exposer le contenu des tickets.

« Prochainement » n’est pas une unité de service

La page de contact d’AFRINIC invite la personne qui s’interroge sur l’adhésion, l’attribution d’adresses IP ou le registre de routage BGP à remplir un formulaire. L’équipe, dit-elle, lui répondra « shortly ». La formule est accueillante. Elle n’est ni un délai, ni une définition du moment où commence le délai.

Ailleurs, AFRINIC emploie une mesure beaucoup plus nette. Son engagement de niveau de service promet une réponse effective à toutes les demandes adressées à l’équipe des opérations dans les deux jours ouvrables. L’annexe sépare le temps de réponse, c’est-à-dire la rapidité avec laquelle l’organisation réagit au problème soulevé, du temps de résolution, qui va de l’enregistrement du problème à sa résolution complète.

Cette séparation est saine. Une analyse de ressources, une correction de facturation ou un incident de sécurité ne peut pas toujours être achevé en quarante-huit heures ouvrées. Le demandeur peut néanmoins savoir que son message a été reçu, que la bonne équipe en a la charge et que l’étape suivante est identifiée.

Encore faut-il savoir à quelle réception l’horloge se rattache. Est-ce l’arrivée sur l’adresse publique ? L’émission d’un accusé automatique ? Le classement dans une file spécialisée ? La première intervention humaine ? Les pages publiques examinées ne relient pas ces événements.

Douze files sous la même promesse

Le document de service porte la mention « Version 1 | November 2015 ». Il couvre notamment l’enregistrement et le service aux clients, les bases publiques, le DNS inverse, la facturation et l’infrastructure de service. Sous la promesse des deux jours se trouve une table de douze lignes utiles.

Elle distingue les renseignements pour devenir membre, l’évaluation d’une demande d’adhésion, Hostmaster, la facturation, l’assistance de service, la maintenance de l’infrastructure, l’assistance RPKI, l’assistance DNS et DNSSEC, le registre de routage, les informations relatives au site, le dépôt d’une réclamation et l’escalade d’une réclamation.

Ce vocabulaire n’est pas seulement décoratif. La table associe chaque file à une description. Hostmaster reçoit les demandes de ressources supplémentaires et les questions de gestion des ressources IP. L’assistance de service couvre notamment le DNS inverse, les certificats BPKI, MyAFRINIC et Whois. RPKI et le registre de routage ont leurs propres lignes.

Pour les réclamations, la séquence est encore plus explicite. Une réclamation reçue par téléphone ou par courriel doit obtenir une réponse dans les deux jours ouvrables, hors jours fériés observés à Maurice. Si elle n’est pas résolue à la satisfaction du demandeur, celui-ci peut l’escalader en joignant les informations utiles, dont le numéro du ticket. Une nouvelle réponse dans les deux jours ouvrables est annoncée pour ce stade.

Il ne s’agit pas d’une promesse de donner raison au plaignant. Le texte ne dit pas non plus que le problème sera résolu dans ce délai. Il décrit en revanche une chaîne de responsabilité où le ticket sert de fil entre la demande et l’escalade. Si l’entrée publique a changé depuis la rédaction du document, cette chaîne a besoin d’une liaison visible.

Seize adresses pour atteindre la compétence

L’annuaire des courriels d’assistance suit une autre logique. AFRINIC y explique que des matières différentes exigent une expertise particulière et que des adresses distinctes doivent contribuer à ce qu’aucune demande ne passe inaperçue. C’est un argument opérationnel convaincant.

L’annuaire affiche seize catégories : Hostmaster/IP Resources, Billing, Account Info & Services, Routing Registry, DB-help, Prospective Members, Training, Outage, Fellowship, Fellowship Alumni, General, Escalation, RPKI, DNS and DNSSEC, Data Protection et IT security/Responsible disclosure.

Plusieurs équivalences paraissent naturelles. Account Info & Services peut correspondre à Service support. Outage peut alimenter Service Infrastructure Maintenance. Prospective Members peut reprendre une partie des deux lignes consacrées à l’adhésion. Mais « peut » n’est pas « est ». Aucune des pages figées ne fournit une table officielle de ces équivalences.

Les écarts sont instructifs. Le document de service nomme Complaint report ; l’annuaire ne présente pas de ligne portant ce nom exact, bien qu’il publie une adresse d’escalade. Le premier prévoit Website information ; le second ajoute au contraire la formation, les bourses, la protection des données et la divulgation responsable. Ces ajouts peuvent être parfaitement légitimes. Ils montrent simplement que les deux listes n’ont ni la même date, ni la même fonction apparente, ni le même nombre de catégories.

Il serait excessif d’en conclure qu’elles aboutissent à des systèmes différents. Une adresse peut être un alias. Deux étiquettes peuvent alimenter la même file. Une équipe peut reclasser un message tout en conservant sa date originale. Le défaut est précisément l’absence d’un reçu public qui permette de distinguer ces scénarios.

Trois choix sur la page que trouvera le visiteur

La page Contact Us simplifie beaucoup plus. Son encadré Support Emails présente trois destinations nommées : Registry Queries, Technical Support et Media & Press. Il ne montre ni les seize lignes de l’annuaire, ni les douze files du document de service.

Cette réduction peut être un bon choix d’interface. La personne qui veut modifier un objet Whois ne devrait pas être obligée de connaître l’organigramme. Celle qui ignore si sa question relève du registre de routage ou de l’assistance générale doit pouvoir choisir un guichet large sans perdre sa place.

Le formulaire général pousse cette logique jusqu’au bout. Il demande le nom, l’adresse électronique, l’objet et le message. Aucun menu visible n’oblige le demandeur à sélectionner une catégorie de la promesse de service. L’objet libre peut suffire à une équipe de tri expérimentée. Le formulaire peut aussi transmettre des informations techniques que sa page n’affiche pas.

Cette enquête n’a envoyé aucun message et n’a pas accédé au système de tickets. Elle ne permet donc pas de juger le tri réel. Elle permet seulement d’observer ce que voit l’expéditeur : aucune indication ne dit à quelle file correspond le formulaire, quand commence le délai ou ce qu’il advient de l’heure d’envoi si le message est déplacé.

Le point de friction se trouve dans le transfert

Tant qu’une demande arrive directement au spécialiste attendu, les différences de vocabulaire ont peu d’effet. Le cas décisif est celui du transfert.

Supposons qu’un membre utilise Technical Support pour une difficulté de facturation. Le service général peut répondre rapidement et transmettre le dossier. L’équipe de facturation peut ensuite mesurer son propre délai à partir de la réception interne. Le membre, lui, mesure depuis l’envoi à l’adresse affichée. Ces deux chronologies peuvent être de bonne foi et ne pas raconter la même promesse.

Même difficulté pour une demande qui devient réclamation. Le document de service demande un numéro de ticket lors de l’escalade. La page de contact ne rend pas visible un point d’entrée intitulé Complaint report. Si le demandeur choisit le formulaire, puis écrit à l’adresse d’escalade publiée dans l’annuaire, le registre public ne lui dit pas si l’identifiant et la date d’origine suivront automatiquement.

Le risque n’est pas nécessairement un retard. C’est l’impossibilité de départager après coup l’attente du demandeur et la mesure du service. Une promesse qui commence seulement une fois le bon classement effectué récompense la qualité du tri interne, mais fait porter à l’expéditeur le coût d’une nomenclature qu’il ne contrôle pas.

Une carte de correspondance, pas un nouvel appareil administratif

La solution tient dans un tableau assez mince. Chaque ligne commencerait par un besoin exprimé dans le langage d’un membre : rejoindre AFRINIC, demander des ressources, modifier un contact, corriger Whois, gérer le DNS inverse, utiliser l’IRR ou RPKI, signaler une panne, contester une réponse, traiter une facture, protéger des données ou signaler une vulnérabilité.

La ligne indiquerait ensuite l’entrée publique actuelle, l’intitulé de la file auquel se rattache l’engagement, et quelques exemples de périmètre. Une personne incertaine pourrait toujours utiliser le formulaire général ; la table dirait vers quelle classe il sera orienté.

Le cœur du dispositif serait temporel. L’événement de réception devrait être défini. Un transfert devrait conserver ou non l’heure initiale selon une règle publiée. Le calendrier des jours ouvrables devrait être indiqué. Le délai de première réponse resterait séparé de la durée de résolution. Un canal de secours serait nommé pour le cas où une adresse rejette le message ou où le formulaire est indisponible.

La réclamation et son escalade formeraient deux états liés au même identifiant. La personne responsable serait désignée par fonction, non par nom individuel. Une date d’effet, une version et un historique de modification permettraient enfin de savoir si une nouvelle page complète ou remplace une ancienne entrée.

Ce tableau ne révélerait ni le texte des demandes, ni les règles de détection des incidents, ni les personnes chargées de la sécurité. Il rendrait visible le contrat entre un geste public—envoyer—et un état administratif—être reçu dans la file à laquelle s’applique la promesse.

Mesurer sans exposer les membres

Une fois les classes stabilisées, AFRINIC pourrait publier des agrégats prudents : nombre de demandes reçues, proportion reclassée, premières réponses dans le délai, stock non résolu et tranches d’ancienneté. Les sujets sensibles pourraient être regroupés ou omis lorsque de faibles volumes risquent d’identifier un cas.

L’indicateur le plus utile ne serait pas une moyenne générale. Une moyenne faible peut coexister avec quelques demandes très anciennes. Un bon taux de réponse peut aussi masquer des transferts dont le compteur a été remis à zéro. Il faut d’abord définir l’unité et conserver le premier reçu ; la statistique vient ensuite.

Cette précision protège aussi AFRINIC. Si le service respecte son engagement depuis l’arrivée au guichet général, le registre peut le démontrer. Si le délai d’une catégorie est différent, il peut l’annoncer. Si une question est hors périmètre, l’accusé peut le dire sans laisser croire qu’elle a disparu.

Ce que les pages ne prouvent pas

Les quatre sources ne montrent aucune demande perdue, ignorée ou mal classée. Elles ne documentent aucun dépassement de délai. Aucun compte de membre, aucun ticket et aucune règle interne n’ont été consultés. Une adresse générale peut distribuer les messages sans défaut ; le formulaire peut produire un accusé et une classification impeccables.

La mention de 2015 ne suffit pas non plus à déclarer l’engagement périmé. Les pages étaient accessibles au moment du relevé. Leurs en-têtes techniques de modification peuvent refléter une mise en ligne et non une révision éditoriale. L’analyse porte sur l’absence de liaison publiée, pas sur l’âge supposé d’un processus.

Enfin, répondre n’est pas résoudre. La carte proposée ne transformerait pas chaque problème en obligation de résultat sous deux jours. Elle dirait seulement où commence le délai de première réaction et comment il survit aux changements de file.

Sources