AFRINIC et l'économie du pouvoir d'adressage des fournisseurs cloud

Une entreprise de paiement basée à Lagos qui se prépare à déplacer une plus grande partie de son système de gestion des risques commerçants vers le cloud public ne commence pas par un séminaire sur la gouvernance d’internet. Elle commence par une feuille de calcul de migration. L’API centrale dessert déjà des banques, des portefeuilles électroniques, des processeurs de cartes et des milliers de petits commerçants. Les banques partenaires tiennent des listes blanches. Les systèmes de détection de fraude reconnaissent les points de terminaison existants. Quelques clients du secteur public et des entreprises ont encore des règles de pare-feu approuvées lors d’un cycle d’approvisionnement antérieur. Le conseil d’administration souhaite une meilleure résilience et une reprise après sinistre plus efficace. La décision réseau semble routinière: prendre des adresses IPv4 publiques auprès du fournisseur cloud, intégrer les adresses propres de l’entreprise dans la plateforme, ou pousser davantage de services derrière des réseaux privés et du NAT en ne laissant que quelques points de terminaison publics.

Ces choix ne sont pas purement techniques. Les adresses IPv4 publiques fournies par le fournisseur sont rapides à obtenir, bien intégrées et facturées comme le reste de la plateforme. Elles peuvent être attachées à des machines virtuelles, des équilibreurs de charge, des passerelles et des services gérés sans que l’entreprise n’ait besoin de trouver un courtier ou de mettre à jour un fichier de registre au préalable. Elles lient également l’identité publique à l’inventaire du fournisseur, aux contrôles de compte et aux conditions futures. L’apport de sa propre adresse IP, généralement appelé BYOIP, préserve davantage de continuité pour le client, mais exige des preuves: le contrôle du préfixe, des données d’enregistrement cohérentes, un routage autorisé, un DNS inverse utilisable, une réputation acceptable et l’absence de chevauchement dangereux avec une autre annonce. Le NAT réduit le nombre d’adresses publiques visibles, mais transfère les coûts vers les passerelles, la journalisation, la traçabilité, la gestion des ports et l’assurance client. Les adresses IPv4 portables rares, qu’elles soient détenues, louées ou acquises, ne constituent l’option la plus indépendante que lorsque les banques, les auditeurs, les plateformes cloud et les opérateurs réseau font confiance à l’enregistrement qui les sous-tend.

La feuille de calcul devient une carte de négociation. Si la fintech utilise des adresses fournies par le cloud, elle gagne en rapidité mais accepte un certain coût de sortie futur. Si elle apporte son propre espace, elle protège la continuité client mais doit passer par un processus d’admission cloud où les preuves du registre comptent. Si elle s’appuie fortement sur le NAT, elle économise des adresses publiques tout en rendant les points de terminaison publics restants plus critiques. Si elle tente d’utiliser un espace administré par l’AFRINIC, elle doit expliquer non seulement le routage et le prix, mais aussi si la couche de registre africaine est suffisamment stable pour que les tiers considèrent le plan d’adressage comme bancable.

C’est là l’économie du pouvoir d’adressage des fournisseurs cloud. Le cloud public a transformé la rareté IPv4, d’une contrainte de fond, en un intrant industriel tarifé, surveillé, rationné, validé et conditionné dans les comptes. Les grandes plateformes détiennent ou contrôlent d’importants inventaires d’IPv4 publiques. Elles exploitent des systèmes de gestion d’adresses IP, imposent des quotas, exécutent des contrôles de réputation, valident les préfixes appartenant aux clients, annoncent l’espace approuvé depuis des dorsales mondiales et proposent les adresses du fournisseur comme la voie la plus simple. Le résultat n’est pas un monopole brut. C’est de l’optionalité. Un fournisseur peut offrir à un client un choix entre la commodité détenue par la plateforme et la diligence appartenant au client. Si les enregistrements d’adresses indépendants sont fiables, le client dispose d’un levier. S’ils ne le sont pas, l’inventaire propre de la plateforme gagne en valeur.

L’AFRINIC se trouve au cœur de ce problème car c’est le registre Internet régional pour l’Afrique et certaines parties de l’océan Indien. Ses documents publics décrivent un registre pour les adresses IPv4, IPv6 et les numéros de systèmes autonomes, avec des services WHOIS, RDAP, DNS inverse, registre de routage Internet et RPKI. Dans un dossier de migration cloud, ces services deviennent des preuves. Une demande BYOIP, une autorisation d’origine de route, un plan de DNS inverse, un enregistrement de contact en cas d’abus et une lettre d’autorisation reposent tous sur la même prémisse institutionnelle: l’enregistrement du registre peut être lu comme une déclaration neutre, actuelle et prévisible de reconnaissance.

L’AFRINIC apporte également un contexte difficile. La région est entrée dans la phase 2 d’atterrissage en douceur IPv4 en janvier 2020, le cadre officiel d’épuisement limitant l’échelle d’allocation ordinaire. Les rapports publics depuis 2019 ont décrit des allégations de manipulation de registres d’adresses, le litige à haute valeur de Cloud Innovation, un conflit juridique sur l’autorité du registre et l’examen des ressources, la mise sous séquestre par la Cour suprême de Maurice, des années de légitimité compromise du conseil d’administration, un processus électoral de 2025 annulé, les efforts ultérieurs de rétablissement du conseil et l’attention juridique continue de la part de l’ICANN en 2026. Ces faits ne prouvent pas que chaque préfixe administré par l’AFRINIC est risqué. Ils expliquent pourquoi les contreparties prudentes posent des questions supplémentaires.

La question centrale est étroite. L’AFRINIC ne réglemente pas AWS, Azure, Google Cloud ni aucune autre plateforme. Son rôle économique est plus simple et plus important: maintenir des registres d’adresses administrés en Afrique suffisamment fiables pour que les opérateurs africains et les clients cloud ne soient pas poussés vers des adresses appartenant aux plateformes simplement parce que l’espace AFRINIC indépendant ou loué comporte une prime de risque de registre évitable. La continuité neutre des enregistrements réduit l’enfermement. Le contrôle discrétionnaire l’augmente.

Le cloud a rendu la rareté IPv4 visible comme une ligne de facture

Les adresses IPv4 publiques se cachaient autrefois dans la connectivité. Une entreprise achetait un accès Internet, un hébergement ou un serveur, et une adresse apparaissait comme faisant partie du service. Leur rareté était réelle, mais le prix était souvent groupé. Le cloud a suffisamment désagrégé la pile pour rendre l’adresse visible. Une adresse IPv4 publique est désormais une ligne de facture, un objet de quota, un avertissement de ressource inactive, un sujet d’examen architectural et un risque de migration.

Les grands fournisseurs cloud sont explicites à ce sujet. La page de tarification VPC d’AWS considère les adresses IPv4 publiques associées aux ressources AWS, et les adresses IPv4 publiques inactives dans un compte, comme facturables à 0,005 $ par heure. Elle indique également que les adresses BYOIP et les adresses IP appartenant au client dans le chemin fonctionnel correspondant ne sont pas facturées comme des adresses IPv4 publiques AWS. La même page décrit IP Address Manager, ou IPAM, avec un niveau gratuit qui inclut la gestion BYOIP v4 et v6 et Public IP Insights, et un niveau avancé qui facture les adresses IP actives. La tarification réseau de Google Cloud facture les adresses IPv4 externes et répertorie les adresses IP publiques statiques et éphémères utilisées sur les instances VM standard à 0,005 $ par heure, avec les adresses statiques réservées inutilisées à 0,01 $ par heure. Google indique séparément que les adresses BYOIP apportées par un client sont disponibles uniquement pour ce client et n’entraînent aucun frais d’adresse IP inactive ou utilisée. La documentation sur les préfixes IP personnalisés d’Azure indique qu’il n’y a aucun frais pour approvisionner ou utiliser des préfixes IP personnalisés ou les adresses IP publiques qui en dérivent, bien que les frais de trafic normaux s’appliquent toujours.

Ces pages doivent être lues comme des pièces à conviction du marché, et non comme des déclarations morales. Elles montrent que les fournisseurs cloud traitent les adresses IPv4 publiques comme un inventaire rare qui doit être tarifé, surveillé et gouverné. Une adresse inactive n’est plus simplement désordre; elle est facturable ou visible pour un outil de gestion IP. Le préfixe propre d’un client n’est pas accepté sur confiance; il est placé derrière des règles de validation, d’approvisionnement et d’annonce. Un architecte réseau se demande désormais si chaque point de terminaison public vaut le coût, si la connectivité privée peut remplacer l’exposition, si une conception NAT ne fait que déplacer le problème, et si un préfixe appartenant au client doit être intégré à la plateforme.

C’est un changement dans l’économie institutionnelle. La tarification rend la rareté lisible pour les équipes financières. IPAM rend l’utilisation des adresses lisible pour les équipes d’exploitation. BYOIP rend la propriété et les preuves de registre lisibles pour les équipes d’intégration cloud. Les frais d’adresses IP publiques incitent les ingénieurs à traiter l’allocation d’adresses comme une question d’architecture plutôt que d’habitude. Une fois ces contrôles en place, l’inventaire d’adresses du fournisseur devient un actif stratégique. Cela permet à la plateforme de dire: une IPv4 atteignable est disponible maintenant, mais l’identité d’adresse appartient à notre système de compte, à moins que vous ne passiez les tests requis pour apporter la vôtre.

Le prix par adresse peut sembler faible à côté des factures de calcul, de stockage ou de transfert de données. Ce n’est pas là tout le signal. Le coût réel apparaît lorsque les adresses deviennent attachées aux clients, aux partenaires et à la réputation. Un point de terminaison public qui semble bon marché au lancement peut devenir coûteux à déplacer. Une adresse statique qui figure dans une liste blanche bancaire, un moteur de détection de fraude, un rappel de paiement, un pare-feu du secteur public ou un système de réputation de messagerie acquiert un coût de changement.

Le cloud a donc rendu visibles deux types de rareté. La première est numérique: il n’y a pas assez d’adresses IPv4 pour les traiter comme une décoration gratuite. La seconde est institutionnelle: il n’y a pas assez d’identités d’adresses fiables, portables, à la réputation propre et adossées au registre pour rendre chaque client indépendant de l’inventaire de la plateforme. Le fournisseur cloud peut gérer la première par la tarification et l’architecture. Le client a besoin que la couche de registre résolve la seconde.

La pertinence de l’AFRINIC commence là. Dans une région post-épuisement, un préfixe propre reconnu par l’AFRINIC n’est pas seulement une ressource de routage. C’est une alternative possible à l’identité publique appartenant à la plateforme. Si l’enregistrement qui le sous-tend est fiable, le client cloud peut peser les adresses du fournisseur par rapport au BYOIP sur des conditions commerciales ordinaires. Si l’enregistrement est incertain, l’inventaire du fournisseur devient le choix par défaut le plus sûr, même lorsque le client préférerait la portabilité.

L’adresse de la plateforme est une commodité avec un prix de sortie

L’attrait des adresses fournies par le fournisseur est réel. Un client peut créer une machine virtuelle, un équilibreur de charge, un tunnel VPN ou un point de terminaison géré et recevoir une adresse IPv4 publique sans avoir à trouver un courtier, négocier un bail, acheter un préfixe, mettre à jour un objet de registre ou rédiger un plan d’origine de route. La plateforme absorbe la complexité du routage. Elle détient d’importants inventaires, annonce depuis sa dorsale, gère l’attribution d’adresses côté cloud, intègre les adresses dans la surveillance et la facturation, et peut souvent remplacer une ressource défaillante plus rapidement qu’un client ne peut mettre à jour son propre réseau.

Pour une startup ou un organisme public soumis à des délais, cette commodité est précieuse. L’entreprise de paiement de Lagos peut lancer une nouvelle API dans une région cloud sud-africaine, la placer derrière un équilibrage de charge géré, utiliser les services de sécurité du fournisseur et atteindre une étape de déploiement. L’équipe d’approvisionnement de la banque voit une plateforme majeure. L’équipe d’ingénierie voit moins de pièces mobiles. L’équipe financière voit une facture mensuelle plutôt qu’une transaction sur le marché des adresses. Le régulateur voit un fournisseur cloud nommé. Le conseil d’administration voit une rapidité opérationnelle.

Le prix de sortie est moins visible. L’adresse IP publique fait partie de la surface opérationnelle du client. Les partenaires l’intègrent en dur dans les listes blanches. Les fournisseurs de sécurité la traitent comme un signal. Les rappels commerçants l’utilisent. Les intervenants en cas d’incident recherchent dans les journaux par son intermédiaire. Les systèmes de détection de fraude apprennent son comportement. Le DNS inverse peut être configuré autour d’elle. Des corrections de géolocalisation peuvent être déposées pour elle. Les clients peuvent la documenter dans leurs propres enregistrements de contrôle des modifications. Au fil du temps, l’adresse du fournisseur devient un élément de la continuité des activités.

Quitter la plateforme, ou même déplacer un service entre comptes, régions ou architectures, nécessite alors plus qu’un redéploiement de code. Cela exige une communication avec les partenaires, des modifications de pare-feu, des mises à jour de listes blanches, des fenêtres de test, de nouveaux arrangements de DNS inverse, une remise en chauffe de la réputation, un examen des certificats et des points de terminaison, des avis aux clients et parfois une explication réglementaire. L’adresse était facile à utiliser parce que la plateforme la contrôlait. Elle devient difficile à quitter pour la même raison.

L’identité groupée fait partie du produit. Un fournisseur qui peut fournir des IPv4 publiques propres à partir de son propre pool réduit les frictions pour le client. Le problème économique est que cette réduction des frictions devient un pouvoir de négociation lorsque les alternatives appartenant au client sont incertaines. La plateforme n’a pas besoin de bloquer le BYOIP pour gagner en levier. Il lui suffit que le chemin indépendant du client paraisse plus lent, plus risqué ou moins bancable.

Le NAT et l’adressage privé modifient la forme du pouvoir plutôt que de l’éliminer. Ils réduisent le nombre de points de terminaison publics, mais ils concentrent l’identité publique en moins de points d’étranglement. Quelques adresses de sortie deviennent critiques pour les listes blanches des partenaires, la journalisation et l’examen des incidents. Si ces adresses appartiennent à la plateforme, la dépendance est concentrée. Si elles appartiennent au client, le client a besoin d’une autorité adossée au registre pour les embarquer dans la plateforme et les en ressortir.

C’est pourquoi une décision d’adressage cloud est prise tôt mais chiffrée tard. Au début, les adresses publiques appartenant au fournisseur ressemblent à une commodité. Après deux ans, elles peuvent être intégrées dans les contrats partenaires, les dossiers de conformité et les plans de reprise après sinistre. Le client peut encore être libre de partir en théorie, mais le coût du changement d’identité publique devient un péage privé. Les grands clients peuvent gérer ce péage grâce à des équipes dédiées et des migrations par étapes. Les petites fintechs africaines, les plateformes SaaS, les systèmes de santé, les universités et les plateformes de service public ne le peuvent souvent pas.

Les adresses IPv4 portables sont le contrepoids. Si un client peut utiliser son propre préfixe reconnu sur une plateforme cloud, une autre plateforme cloud, un site sur site, un hébergement régional et un environnement de reprise après sinistre, l’identité publique devient moins dépendante d’un seul fournisseur. Le client achète toujours du calcul, du stockage, de la sécurité et des services réseau auprès des plateformes cloud. Il ne loue pas la totalité de son identité d’adresse publique auprès d’elles. Cette différence est la valeur économique de la portabilité.

Mais la portabilité n’est pas auto-exécutoire. Elle dépend de la chaîne de preuves derrière l’adresse. Le préfixe doit être reconnu. Le détenteur ou l’utilisateur autorisé doit être lisible. L’autorisation d’origine de route doit concorder. Le DNS inverse et les contacts en cas d’abus doivent être gérables. Le fournisseur cloud doit être disposé à accepter le préfixe dans son système. Si la couche d’enregistrement de l’AFRINIC est perçue comme incertaine ou discrétionnaire, l’option appartenant au client perd une partie de son avantage. La commodité de l’adresse de la plateforme devient plus forte non pas parce que la plateforme s’est améliorée, mais parce que l’alternative est devenue institutionnellement plus faible.

Le BYOIP transforme les enregistrements du registre en preuves d’admission cloud

Le BYOIP est la preuve la plus claire que les enregistrements du registre sont devenus des preuves d’admission cloud. C’est aussi la discipline la plus utile pour réfléchir au rôle de l’AFRINIC. Un fournisseur cloud ne laisse pas un client annoncer n’importe quel préfixe via une dorsale mondiale simplement parce que le client le demande. Le fournisseur doit protéger son réseau, les autres clients, sa réputation de routage et ses relations avec ses pairs. Il demande donc des preuves que le préfixe est contrôlé par le client, que l’annonce de route est autorisée, que le bloc est suffisamment grand et propre pour le routage Internet, et que l’annonce du fournisseur ne chevauchera pas dangereusement une autre origine.

La documentation BYOIP d’EC2 d’AWS définit les enregistrements RDAP comme des données d’enregistrement consultées auprès d’un registre Internet régional et décrit l’autorisation d’origine de route comme un objet créé par les RIR pour que les clients puissent authentifier l’annonce IP dans des systèmes autonomes particuliers. Sa page EC2 actuelle indique qu’une plage doit être enregistrée auprès d’un RIR, doit être enregistrée au nom d’une entité commerciale ou institutionnelle plutôt que d’une personne physique, et que la plage IPv4 la plus spécifique qu’un client peut apporter est /24. Le chemin de certificat RDAP de la même page répertorie actuellement ARIN, RIPE NCC et APNIC; un chemin distinct Amazon VPC IPAM peut vérifier le contrôle du domaine avec un enregistrement DNS TXT, que le registre prenne en charge RDAP ou non. Il s’agit d’une portée de documentation produit, et non d’une règle AWS universelle. Le point économique est plus étroit: AWS demande un contrôle vérifiable lié au registre avant d’annoncer l’espace client.

La documentation sur les préfixes IP personnalisés d’Azure rend la même relation visible sous une autre forme. Elle décrit la validation, l’approvisionnement et la mise en service. Elle indique que les clients peuvent conserver leurs plages IP pour préserver une réputation établie et continuer à passer les listes blanches contrôlées de l’extérieur. Elle exige une vérification de la propriété et de l’enregistrement, ainsi qu’une autorisation pour Microsoft d’annoncer la plage. Ses limites IPv4 par défaut pour les préfixes personnalisés unifiés incluent /21 à /24. Le DNS inverse pour les préfixes personnalisés exige des zones inverses appartenant au client plutôt que des zones appartenant à Azure. Les préfixes personnalisés eux-mêmes ne sont pas facturés, bien que le trafic le soit, et le déplacement des préfixes est limité par les règles du produit. Ces détails ne sont pas des notes secondaires. Ils montrent que le BYOIP est un processus d’admission contrôlé façonné par la réputation des adresses, la preuve de routage, la taille du préfixe, la responsabilité du DNS inverse et les limites côté cloud.

La documentation BYOIP de Google Cloud indique qu’un client peut approvisionner et utiliser ses propres adresses IP publiques pour les ressources Google Cloud, que les adresses importées ne sont disponibles que pour le client qui les a apportées, et qu’il n’y a pas de frais d’adresse IP inactive ou utilisée pour ces adresses apportées. Elle met également en garde contre les annonces de route BYOIP qui se chevauchent, car des annonces qui se chevauchent peuvent entraîner un routage inattendu et des pertes de paquets. Sa validation de préfixe d’accès externe utilise des vérifications ROA et de DNS inverse avant que le préfixe importé ne soit attribué aux structures de projet et de portée de Google Cloud.

D’un fournisseur à l’autre, le schéma est cohérent même lorsque les détails des produits diffèrent. La plateforme cloud traduit l’autorité d’adresse externe en politique de plateforme. L’enregistrement du registre, la preuve d’origine de route, la taille du préfixe, la réputation, le DNS inverse, l’association de compte, la portée régionale ou mondiale et le moment de l’annonce sont tous convertis en objets cloud. Le client peut posséder ou contrôler l’adresse en dehors du cloud, mais à l’intérieur du cloud, l’adresse devient une ressource gérée soumise aux règles de la plateforme.

Cette conversion n’est pas sinistre. Elle est nécessaire. Un fournisseur qui annonce le préfixe d’un client crée un risque pour le fournisseur et pour Internet. Il doit éviter le détournement, le chevauchement, les abus, les fuites de réputation et la confusion des clients. Le danger apparaît lorsque la couche de preuves externe n’est pas fiable. Si l’enregistrement du registre est ambigu, si l’autorité du compte est contestée, si le contrôle du DNS inverse est difficile à prouver, si la preuve d’origine de route ne peut pas être modifiée de manière prévisible, ou si un préfixe est empêtré dans un litige ou un examen discrétionnaire, le fournisseur cloud rejettera la demande, la ralentira, demandera plus de preuves ou considérera l’utilisation du client comme un risque plus élevé.

À ce moment-là, la qualité administrative de l’AFRINIC devient un élément du dossier d’admission cloud. Un préfixe administré par l’AFRINIC peut être techniquement routable et néanmoins soulever des questions supplémentaires. Qui est le détenteur reconnu actuel? Le détenteur est-il en règle? Y a-t-il un litige? Qui peut autoriser une ROA? Qui contrôle le DNS inverse? Le registre accepte-t-il l’utilisation autorisée prévue? Les enregistrements sont-ils à jour? Le client peut-il montrer une chaîne crédible du détenteur au compte cloud? Un blocage de compte ou un litige de gouvernance affectera-t-il les preuves publiques après l’intégration du préfixe?

Les fournisseurs cloud ne résoudront pas ces questions pour le marché africain. Ils se protégeront. Si le chemin d’adresse indépendant semble difficile, ils proposeront les adresses du fournisseur. C’est un comportement rationnel de la plateforme. Le travail du registre est de rendre le chemin indépendant suffisamment prévisible pour que les clients ne soient pas orientés vers la dépendance par un risque de preuve évitable.

Le BYOIP révèle donc un test politique simple pour l’AFRINIC. Un détenteur ou utilisateur autorisé africain peut-il présenter un ensemble de preuves propre, standard et non discriminatoire à une plateforme cloud sans que le fournisseur cloud n’ait à comprendre les politiques de l’AFRINIC? Si oui, le registre soutient l’optionalité du marché. Si non, l’inventaire d’adresses de la plateforme gagne en pouvoir.

L’incertitude de l’AFRINIC ajoute une prime à l’espace administré africain

L’incertitude de l’AFRINIC n’a pas besoin de casser le routage pour modifier le prix. Il suffit qu’elle amène les contreparties à demander plus de preuves. L’équipe d’intégration d’un fournisseur cloud, le comité des risques technologiques d’une banque, le conseiller d’un régulateur ou un prêteur finançant une migration cloud n’a pas besoin de juger du bien-fondé de chaque procès de l’AFRINIC. Elle pose une question plus étroite: cet arrangement d’adressage restera-t-il reconnu et opérationnel pendant toute la durée du contrat?

Le contexte factuel suffit à rendre la question rationnelle. Les propres documents de l’AFRINIC l’identifient comme le registre pour l’Afrique et la région de l’océan Indien et décrivent des services importants pour l’utilisation du cloud: WHOIS, RDAP, DNS inverse, IRR et RPKI. Sa page sur l’épuisement IPv4 indique que la région est entrée dans la phase 2 d’atterrissage en douceur le 13 janvier 2020, avec une taille minimale d’allocation ou d’assignation de /24 et un maximum de /22 dans cette phase. La rareté signifie que les clients sont plus susceptibles de dépendre des avoirs existants, des transferts, des baux, des fusions, des adresses de fournisseur ou du BYOIP plutôt que de nouvelles allocations généreuses.

Les rapports publics ajoutent la prime institutionnelle. En 2019, KrebsOnSecurity a décrit des allégations selon lesquelles de grands blocs d’adresses IPv4 africaines associés à des organisations dormantes ou disparues auraient été manipulés ou vendus par le biais de sociétés liées à un ancien employé de l’AFRINIC, avec une valeur de marché estimée à plus de 50 millions de dollars. L’AFRINIC a déclaré à l’époque qu’elle enquêtait. Des rapports et analyses ultérieurs ont décrit le litige Cloud Innovation, y compris les avoirs IPv4 de grande valeur, les allégations d’utilisation hors région, l’économie de la location, l’examen des ressources, les gels de comptes bancaires, les litiges et le stress institutionnel. En septembre 2023, la Cour suprême de Maurice a nommé un administrateur judiciaire, et la déclaration publique de la NRO a décrit le rôle de l’administrateur dans le maintien du statu quo, la préservation de la valeur de l’entreprise, la supervision des élections et le rétablissement d’une gouvernance fonctionnelle. Le processus électoral de 2025 a été suspendu puis annulé après que des préoccupations concernant la documentation des électeurs et l’autorité de procuration ont été signalées publiquement. Un effort ultérieur de rétablissement du conseil d’administration et les travaux budgétaires et stratégiques de 2026 ont également été rapportés, parallèlement à des litiges en cours et à une intervention de l’ICANN dans un contexte de liquidation.

Ces faits doivent être utilisés avec prudence. Ils ne signifient pas que tous les services de l’AFRINIC sont défaillants. Ils ne signifient pas que chaque préfixe AFRINIC est entaché. Ils ne signifient pas qu’un fournisseur cloud devrait refuser l’espace africain. Ils signifient que les adresses administrées par l’AFRINIC peuvent comporter un écart de risque de registre, à moins que l’institution ne rende les preuves routinières à nouveau ennuyeuses.

L’écart apparaît sous des formes pratiques. Un fournisseur cloud peut demander plus de documents avant d’accepter le BYOIP. Un client peut préférer les adresses du fournisseur parce que son propre espace AFRINIC nécessite des explications. Une banque peut demander si un bloc d’adresses impliqué dans une migration fait l’objet d’un litige. Un avocat spécialisé dans les achats peut demander si le détenteur, l’opérateur et le compte cloud correspondent. Un comité des risques peut craindre qu’un changement de DNS inverse, une mise à jour de ROA ou un statut de registre puisse être retardé par un conflit institutionnel. Un courtier ou un bailleur peut facturer la gestion du risque de continuité. Un petit opérateur peut abandonner le BYOIP et utiliser les adresses du fournisseur parce que le dossier de diligence est trop coûteux.

Le cloud rend la décote plus visible parce que l’admission cloud est formalisée. Le BYOIP n’est pas une poignée de main entre deux ingénieurs locaux. C’est un processus de plateforme qui demande des preuves standard. Si les preuves sont plus difficiles à produire pour l’espace AFRINIC que pour l’espace sous un registre plus stable, le client paie en temps, en risque et en dépendance de repli.

La bonne réponse institutionnelle n’est pas la défensive. Un registre réduit la prime en publiant des procédures prévisibles, en préservant la continuité du service, en distinguant les faits contestés des faits non contestés, en traitant les mises à jour autorisées, en tenant des registres publics exacts et en traitant de la même manière les détenteurs placés dans des situations similaires. Il augmente la prime lorsqu’il transforme la maintenance des enregistrements en jugements discrétionnaires sur le modèle d’affaires, la géographie ou la loyauté institutionnelle. Sur les marchés cloud, l’incertitude ne reste pas confinée au registre. Elle est transmise aux décisions d’intégration, d’approvisionnement, de migration et de sortie.

Les grandes plateformes peuvent supporter un risque d’adressage que les petits opérateurs africains ne peuvent pas

Le pouvoir d’adressage des fournisseurs cloud est en partie un avantage d’échelle. Les grandes plateformes détiennent d’importants inventaires d’adresses, exploitent des dorsales mondiales, entretiennent des relations avec d’autres réseaux, dirigent des équipes de réputation, emploient du personnel juridique et politique, et suivent l’utilisation des adresses IPv4 publiques entre les régions et les comptes. Elles peuvent traiter le risque d’adressage comme une variable opérationnelle. Les petits opérateurs et clients africains subissent souvent le même risque comme une menace pour la continuité des activités.

Si un fournisseur cloud a un bloc d’adresses problématique, il peut faire tourner son inventaire, mettre en quarantaine la réputation, attribuer une plage différente, ajuster les filtres, utiliser sa propre influence de routage, faire remonter par les relations industrielles et absorber l’examen juridique. Si une petite plateforme SaaS ne possède qu’un /24, ce bloc constitue peut-être toute son identité publique. Si une banque régionale utilise un petit ensemble d’adresses publiques pour la connectivité des partenaires, leur modification peut nécessiter des mois d’approbations tierces. Si une plateforme de service public s’appuie sur une poignée de points de terminaison, la renumérotation peut devenir un incident de service aux citoyens. Si un client d’hébergement régional amène un espace AFRINIC dans un environnement cloud ou hybride et que cet espace est remis en question institutionnellement, le client ne peut pas facilement le remplacer par un portefeuille d’adresses mondial.

Cette asymétrie donne aux plateformes une optionalité de marché. Elles peuvent proposer des adresses appartenant au fournisseur comme un service, le BYOIP comme une exception contrôlée, la mise en réseau privée comme un motif d’architecture, le NAT comme un outil de conservation d’adresses, et les services de périphérie gérés comme un moyen de cacher l’origine du client. Chaque option peut être rationnelle. Le fournisseur en profite parce qu’il peut les tarifer, les contrôler et les conditionner. Le client en profite si les options sont véritablement comparables. Il perd son levier si seule la voie des adresses du fournisseur est assez simple pour passer l’examen commercial.

Prenons l’exemple d’une entreprise SaaS ghanéenne qui vend des logiciels de paie et de déclaration fiscale aux moyennes entreprises. Elle s’est développée sur un hébergeur local et utilise un petit pool d’adresses IPv4 publiques que les clients ont mises en liste blanche. Elle souhaite déployer des parties de l’application dans une région cloud majeure pour la résilience et la productivité des développeurs. Elle peut utiliser des adresses cloud, mais un futur déménagement vers un autre fournisseur signifierait à nouveau changer les clients. Elle peut apporter son propre bloc d’adresses, mais le processus d’intégration cloud demande des preuves, une preuve d’origine de route et des données de registre propres. Si ses enregistrements AFRINIC sont anciens, si le nom du détenteur diffère de la société d’exploitation après une restructuration, ou si un arrangement de location est mal documenté, l’option appartenant à la plateforme devient la voie de la moindre résistance.

La plateforme n’a pas forcé l’entreprise à accepter l’enfermement. L’environnement institutionnel a rendu l’indépendance coûteuse. C’est la forme subtile du pouvoir d’adressage. Ce n’est pas le pouvoir de refuser le service. C’est le pouvoir d’être l’alternative la plus simple lorsque le registre neutre n’est pas suffisamment neutre, à jour ou fiable.

Le même schéma s’applique aux FAI africains, aux sociétés d’hébergement et aux intégrateurs de systèmes qui servent des clients cloud. Un opérateur local disposant d’un espace portable propre peut offrir des services hybrides: des points de terminaison publics appartenant au client, une sortie locale, un basculement cloud, une reprise après sinistre, une connectivité sécurisée et une sortie multi-cloud. Si les preuves d’adressage de l’opérateur sont décotées, les adresses propres du fournisseur cloud deviennent plus crédibles que celles de l’opérateur local. L’opérateur local vend alors de la connectivité tandis que la plateforme possède la couche d’identité publique. La valeur se déplace vers le haut.

La rareté IPv4 intensifie l’asymétrie. Lorsque les adresses étaient abondantes, un petit opérateur pouvait en demander davantage ou renuméroter avec moins de difficulté. Dans un marché post-épuisement, chaque adresse publique propre comporte un coût d’opportunité. Les grandes plateformes peuvent répartir ce coût sur des millions de clients et de gammes de produits. Les petits opérateurs sont confrontés à un risque indivisible. Un /24 rejeté, une lettre d’autorisation contestée, une défaillance de DNS inverse, une liste noire de réputation ou un blocage de registre peut affecter une part importante du chiffre d’affaires.

C’est pourquoi la discipline de continuité de l’AFRINIC a des conséquences distributives. Un registre prévisible aide les petits acteurs à utiliser des avoirs d’adresses rares comme actifs de négociation. Un registre imprévisible les laisse avec des actifs techniquement utiles mais commercialement décotés. La décote est alors captée par les parties qui peuvent vendre de la certitude: les plateformes cloud, les grands opérateurs, les courtiers dotés d’une capacité juridique et les acteurs en place disposant de pools d’adresses attribués par les fournisseurs.

Le marché n’a pas besoin que l’AFRINIC favorise les petits opérateurs. Il a besoin que l’AFRINIC n’impose pas d’incertitude évitable sur les preuves que ces opérateurs utilisent pour négocier avec les grandes plateformes.

Le client achète la continuité avant d’acheter du calcul

Les documents d’approvisionnement cloud mettent souvent l’accent sur le calcul, le stockage, la sécurité, les certifications de conformité et l’empreinte régionale. Les adresses IPv4 publiques apparaissent comme un détail de mise en réseau. Pour de nombreux clients africains, l’ordre d’importance est différent. Ils achètent la continuité avant le calcul. La charge de travail ne peut être déplacée que si les clients, les banques, les régulateurs, les partenaires et les systèmes de sécurité peuvent encore la reconnaître.

L’entreprise de paiement de Lagos est typique. Ses banques partenaires peuvent maintenir des listes blanches IP pour les rappels, les fichiers de règlement ou les flux de risques. Les partenaires d’argent mobile peuvent n’autoriser que les points de terminaison publics connus. Les commerçants peuvent avoir des pare-feu qui autorisent le trafic provenant des adresses de service publiées. Les fournisseurs de détection de fraude peuvent associer un comportement aux plages sources. Les fournisseurs de messagerie peuvent suivre la réputation de l’expéditeur. Les journaux de support client peuvent dépendre d’adresses sources stables. Un régulateur peut demander si la migration modifie l’endroit où le trafic est traité ou qui contrôle l’accès. Chaque dépendance transforme une adresse en un point d’ancrage de continuité.

Les adresses cloud du fournisseur résolvent le premier problème de déploiement. Elles ne résolvent pas nécessairement le problème de continuité. L’entreprise doit distribuer de nouvelles adresses, mettre à jour les enregistrements des partenaires, tester les chemins, attendre les fenêtres de changement et gérer les exceptions. Si elle reste sur la même plateforme pendant de nombreuses années, l’adresse du fournisseur peut devenir acceptée. Cette acceptation est utile mais collante. Le prochain déménagement devient plus difficile parce que l’identité publique est désormais intégrée dans un compte fournisseur.

Le BYOIP résout un problème différent. Il permet au client de conserver la même identité publique tout en changeant l’endroit où le service s’exécute. Le client peut déplacer un préfixe d’un environnement sur site ou d’hébergement local vers le cloud, ou concevoir une posture hybride où le même espace d’adressage reconnu prend en charge plusieurs sites d’exploitation. La valeur n’est pas seulement la réduction des frais IP. C’est d’éviter la renumérotation à l’échelle du client et de préserver la réputation. La documentation d’Azure le dit clairement lorsqu’elle décrit la conservation des plages IP pour maintenir une réputation établie et passer à travers les listes blanches contrôlées de l’extérieur. Cette phrase capture une grande partie de l’économie.

Le NAT et la mise en réseau privée aident lorsque l’identité publique n’est pas nécessaire. Les services internes ne devraient pas consommer d’IPv4 publiques simplement parce que les ingénieurs n’ont pas conçu de connectivité privée. Mais le NAT ne peut pas remplacer toutes les identités publiques. Les rappels de paiement, les API publiques, les pairs VPN, les appliances de sécurité, les systèmes de messagerie, les intégrations de détection de fraude et les partenaires d’entreprise historiques exigent souvent encore des IPv4 publiques stables. Une architecture privée peut réduire la surface d’attaque tout en rendant les adresses publiques restantes plus importantes.

La décision du client n’est donc pas « cloud ou pas cloud ». C’est « à quelle continuité d’adressage l’entreprise fera-t-elle confiance? » Si elle fait confiance à l’inventaire d’adresses du fournisseur cloud, elle accepte le contrôle du fournisseur comme faisant partie du service. Si elle fait confiance à son propre espace reconnu ou autorisé par l’AFRINIC, elle peut utiliser le cloud tout en préservant une certaine sortie. Si elle ne fait confiance ni à l’un ni à l’autre, elle retarde la migration, abuse du NAT, conserve un hébergement ancien fragile ou paie pour une assurance sur mesure.

C’est là que la qualité institutionnelle de l’AFRINIC entre dans la transformation numérique africaine ordinaire. Une plateforme de service public migrant vers le cloud, une université construisant des services de recherche, une banque modernisant ses API, une entreprise SaaS de logistique en expansion régionale ou une plateforme de santé concevant une reprise après sinistre peuvent toutes être confrontées à la même question. Elles ne cherchent pas à débattre de la gouvernance d’Internet. Elles ont besoin d’une identité d’adresse publique qui survive au choix du cloud.

Lorsque l’AFRINIC est ennuyeuse, la réponse peut être commerciale. Utilisez les adresses du fournisseur lorsque la rapidité et la faible friction sont importantes. Utilisez le BYOIP lorsque la continuité et la sortie sont importantes. Utilisez le NAT et les services privés lorsque la joignabilité publique n’est pas nécessaire. Acquérez ou louez de l’espace lorsque l’analyse de rentabilisation le justifie. Lorsque l’AFRINIC est incertaine, la réponse devient institutionnelle. Évitez la voie d’adressage indépendante à moins de pouvoir supporter la charge de la preuve. Cela pousse le marché vers les plateformes.

Le coût n’est pas visible sur une seule facture. Il apparaît dans la prudence des achats, les migrations retardées, les architectures conservatrices, les environnements dupliqués, la réticence des partenaires et la faiblesse des droits de sortie. Un client peut économiser de l’argent sur un projet cloud tout en renonçant à une optionalité d’adressage qui aurait compté lors de la prochaine négociation.

La réputation rend le pouvoir d’adressage durable

Les adresses IPv4 publiques portent une mémoire. Elles apparaissent dans les listes de spam, les signaux de fraude, les bases de données de géolocalisation, les historiques d’abus, les classifications VPN et proxy, les listes blanches d’entreprise, les enregistrements DNS, les journaux de certificats, la télémétrie des applications, les rapports d’incidents, les fichiers des fournisseurs de paiement et la documentation client. Une nouvelle adresse peut être techniquement joignable mais commercialement non fiable. Une ancienne adresse peut être précieuse parce qu’elle est déjà connue des bonnes parties et inconnue des mauvaises.

Les fournisseurs cloud le comprennent. Leur documentation BYOIP présente souvent les adresses appartenant au client en termes de réputation et de continuité. Azure mentionne explicitement la réputation établie et les listes blanches contrôlées de l’extérieur. Google sépare les adresses apportées par le client de l’inventaire ordinaire du fournisseur et ne les rend disponibles qu’au client qui les a apportées. La tarification IPv4 publique d’AWS et les documents IPAM traitent l’utilisation des IP publiques comme quelque chose à suivre, à gérer et à surveiller. Ce ne sont pas des fonctionnalités réseau abstraites. Ce sont des outils de gestion de la réputation.

Pour les clients africains, la réputation a plusieurs couches. Les adresses API d’une fintech peuvent être mises en liste blanche par les banques. Les propres points de terminaison publics d’une banque peuvent figurer dans la documentation de la banque centrale et des banques correspondantes. Les adresses sortantes d’un fournisseur SaaS peuvent être fiables pour les entreprises clientes. Les services de recherche d’une université peuvent avoir des règles d’accès de longue date. Un organisme public peut publier des adresses dans les plans de reprise après sinistre. Un système d’envoi de courrier peut avoir besoin de mois pour se forger une réputation après un changement. Un bloc d’adresses utilisé par des spammeurs ou des pirates peut nécessiter une remédiation avant que des partenaires prudents ne l’acceptent.

L’histoire de l’AFRINIC rend les preuves de réputation particulièrement importantes. Le reportage de 2019 sur le vol d’adresses n’était pas simplement un scandale sur de vieux enregistrements. Il a montré que des enregistrements de registre périmés ou manipulés peuvent avoir des effets de réputation en aval. Des blocs d’adresses dormants peuvent être réquisitionnés, vendus, utilisés pour du trafic abusif, répertoriés par les systèmes anti-abus et devenir difficiles à réhabiliter pour les utilisateurs légitimes ou ultérieurs. Un registre qui ne peut pas maintenir des données fiables sur les détenteurs et les contacts ne crée pas seulement une confusion administrative. Il endommage le capital de réputation attaché aux adresses.

Le cloud peut soit atténuer, soit aggraver ce risque. Une adresse appartenant au fournisseur peut arriver avec le soutien opérationnel de la plateforme, mais aussi avec son propre environnement de réputation partagée. Une adresse appartenant au client peut préserver la réputation mais exige que le client prouve le contrôle et assure le traitement des abus. Une adresse louée peut être efficace mais peut exiger une documentation claire sur qui traite les abus, qui contrôle le DNS inverse, qui peut demander des ROA et ce qui se passe à la fin du bail. Une architecture fortement basée sur le NAT peut réduire la consommation d’adresses IP publiques mais peut aussi concentrer les signaux d’abus derrière quelques adresses de sortie.

La réputation rend le pouvoir d’adressage durable parce qu’elle s’accumule au fil du temps. Une fois qu’un client a passé des années à former les partenaires et les systèmes à faire confiance aux adresses du fournisseur, quitter le fournisseur signifie reconstruire cette réputation ailleurs. Une fois qu’un fournisseur cloud a intégré la surveillance des adresses et les contrôles de réputation dans sa plateforme, il peut vendre de la certitude comme faisant partie du lot. Une fois que l’espace AFRINIC indépendant est perçu comme plus difficile à valider, l’actif de réputation propre du client peut être décoté avant même d’atteindre le cloud.

Le DNS inverse est un exemple utile. Les systèmes de messagerie, les outils de sécurité et les équipes d’exploitation lisent souvent les enregistrements PTR comme faisant partie de l’identité et de la confiance. La documentation sur les préfixes personnalisés d’Azure indique que les préfixes personnalisés ne prennent pas en charge la recherche DNS inverse à l’aide de zones appartenant à Azure et que les clients doivent intégrer leurs propres zones inverses. C’est logique: un client qui apporte son propre préfixe devrait apporter l’autorité de DNS inverse nécessaire pour rendre les adresses crédibles. Mais le DNS inverse dépend du registre et du chemin de délégation. Si le client ne peut pas mettre à jour ou prouver ce chemin de manière prévisible, le BYOIP devient plus difficile même si le routage est possible.

Les contacts en cas d’abus se comportent de manière similaire. Un fournisseur cloud acceptant un préfixe client a besoin de savoir qui répondra aux plaintes. Une banque utilisant l’API du client a besoin de savoir que les incidents peuvent être remontés. Un organisme public a besoin d’auditabilité. Si les enregistrements AFRINIC sont périmés, contestés ou difficiles à corriger, le dossier de réputation s’affaiblit. La plateforme peut alors dire, explicitement ou implicitement, que ses propres adresses s’accompagnent d’un historique opérationnel plus propre.

La réponse n’est pas de laisser toute utilisation d’adresse se faire sans preuves. La réputation exige de la discipline. La réponse consiste à lier les preuves au fait pertinent. Qui contrôle le préfixe? Qui est autorisé à l’utiliser? Qui gère les abus? Qui contrôle le DNS inverse? Quel AS peut l’annoncer? Quel est le statut du litige? Un registre qui répond à ces questions de manière prévisible renforce la réputation des adresses africaines. Un registre qui étend son champ d’action à des jugements sur la vertu d’un modèle d’affaires l’affaiblit, car les contreparties ne peuvent pas distinguer où s’arrêtent les preuves et où commence l’autorisation.

L’approvisionnement en résidence de données ne supprime pas la dépendance d’adressage

L’empreinte des régions cloud compte pour les clients africains. Les principaux fournisseurs exploitent des régions africaines et les arrangements adjacents de périphérie, de cache et de partenariat étendent leur portée. Une banque, une fintech, un organisme public ou un acheteur d’entreprise peut préférer qu’une charge de travail s’exécute dans une région africaine pour la latence, la résilience, l’approvisionnement, le confort réglementaire ou l’acceptabilité politique. Mais la résidence des données n’est pas la même chose que l’indépendance d’adressage.

Une charge de travail peut s’exécuter dans une région cloud africaine tout en utilisant des adresses appartenant au fournisseur. Elle peut satisfaire une exigence d’approvisionnement concernant l’emplacement régional tout en laissant son identité publique sous le contrôle de la plateforme. Elle peut stocker les données plus près des utilisateurs tout en rendant la sortie du client coûteuse. Elle peut sembler locale en termes d’infrastructure alors que la capacité à préserver les points de terminaison publics dépend de l’inventaire d’adresses, des conditions, des quotas et de la politique de routage d’un fournisseur mondial.

Cette distinction est facile à manquer parce que l’approvisionnement cloud réduit de nombreuses dépendances en un seul fournisseur. Le fournisseur propose du calcul, du stockage, de la sécurité, de la surveillance, des bases de données gérées, de l’équilibrage de charge, une protection DDoS, l’IAM, la journalisation, le support et l’identité réseau. Un acheteur public peut considérer cet ensemble comme une maturité opérationnelle. La question de l’adressage est alors cachée dans l’architecture du fournisseur. Si l’acheteur souhaite ultérieurement passer à un autre environnement d’hébergement, un deuxième cloud, un cadre d’approvisionnement souverain ou un environnement de secours d’urgence, il découvre que les adresses publiques faisaient partie de l’accord initial.

Pour les clients africains réglementés, le problème n’est pas seulement la sortie. C’est la position de négociation. Une banque qui peut apporter son propre espace d’adressage dans une région cloud peut négocier le service cloud sans renoncer à toute la continuité des points de terminaison publics. Un ministère qui possède ou contrôle des ressources d’adresses stables peut concevoir un plan de reprise après sinistre entre plusieurs fournisseurs. Une fintech disposant d’adresses portables peut déplacer une API critique si les prix, le support, la politique ou le risque changent. Une plateforme SaaS dotée d’une identité d’adressage indépendante peut utiliser le cloud comme infrastructure plutôt que comme fournisseur d’identité permanent.

Si l’espace d’adressage administré par l’AFRINIC comporte une prime, cette position de négociation s’affaiblit. L’acheteur peut toujours insister sur l’utilisation d’une région locale mais accepter les adresses du fournisseur parce que le dossier BYOIP est trop lent. Un fournisseur local adjacent au cloud peut toujours construire un centre de données ou une offre de services gérés, mais dépendre de la couche d’adressage de l’hyperscaler pour la joignabilité des clients. Un client du secteur public peut parler le langage de la souveraineté numérique tout en louant l’identité publique à une plateforme parce que le registre régional neutre n’est pas suffisamment fiable.

Ce n’est pas la même chose qu’une fragmentation géopolitique générale. Le mécanisme est plus étroit. La dépendance d’adressage convertit le choix de région cloud en pouvoir de négociation du fournisseur. Elle rend l’approvisionnement en résidence de données moins indépendant qu’il n’y paraît. Elle donne également aux plateformes une position plus forte dans les négociations futures parce que les points de terminaison publics du client, les listes blanches de partenaires et la réputation sont intégrés dans le réseau de la plateforme.

L’effet est susceptible d’être le plus fort dans les secteurs où la continuité d’adressage compte le plus: les paiements, les portails publics, les systèmes de santé, les réseaux éducatifs, les SaaS B2B, les services de sécurité, la messagerie, les fournisseurs d’identité, les API d’entreprise et l’externalisation réglementée. Les applications web grand public peuvent parfois se cacher derrière des domaines, des réseaux de diffusion de contenu et des portes d’entrée gérées. Même là, les adresses d’origine, les règles de pare-feu, le traitement des abus et les partenaires API comptent encore. Dans les systèmes d’entreprise et du secteur public, le dossier d’adressage est plus difficile à abstraire.

Le rôle de l’AFRINIC n’est pas de décider si les clients africains devraient utiliser des fournisseurs cloud mondiaux, un hébergement régional, des architectures hybrides ou une infrastructure sur site. Ces décisions appartiennent aux clients, aux régulateurs et aux marchés. Le rôle de l’AFRINIC est de maintenir une reconnaissance des adresses suffisamment neutre pour que ces décisions soient de véritables choix. Si le client choisit les adresses du fournisseur parce qu’elles sont efficaces, c’est une décision commerciale. S’il les choisit parce que l’indépendance adossée à l’AFRINIC est trop incertaine, c’est un échec institutionnel.

Les débats sur la résidence des données demandent souvent où se trouvent les données. La question du pouvoir d’adressage des fournisseurs cloud demande qui contrôle les identifiants publics qui permettent aux clients, aux régulateurs, aux partenaires et aux utilisateurs d’atteindre le service. Ces questions sont liées mais pas identiques. Un registre africain crédible réduit le risque que les ambitions d’infrastructure locale ne deviennent une autre voie vers une identité publique appartenant à la plateforme.

La continuité neutre du registre est l’antidote à l’enfermement propriétaire

L’outil anti-enfermement le plus important sur ce marché n’est pas l’hostilité envers le cloud. C’est la continuité neutre du registre. Un client peut utiliser le cloud public de manière intensive tout en préservant son pouvoir de négociation si son identité d’adresse publique est portable, étayée par des preuves et reconnue. Un client peut éviter le cloud tout en étant enfermé si ses adresses sont attribuées par un fournisseur local en place. La question institutionnelle n’est pas de savoir si le cloud est bon ou mauvais. C’est de savoir si la reconnaissance des adresses permet aux clients de choisir.

La continuité neutre commence par le dernier enregistrement vérifié. Un détenteur reconnu ne devrait pas craindre que les services de registre routiniers ne deviennent des monnaies d’échange lors de litiges sans rapport avec ces services. Les fonctions RDAP, WHOIS, DNS inverse, IRR et RPKI devraient être traitées comme une infrastructure de continuité. Si une ordonnance judiciaire spécifique, une constatation de fraude ou un risque technique affecte un service particulier, la limitation devrait être étroite, étayée par des preuves et susceptible de recours. Sinon, l’enregistrement devrait continuer à soutenir les réseaux et les clients qui en dépendent.

Cela compte pour le cloud parce que le BYOIP et l’architecture hybride dépendent de preuves continues. Un fournisseur cloud peut accepter un préfixe aujourd’hui, mais se demander si la preuve d’origine de route, la délégation de DNS inverse ou l’enregistrement public restera stable demain. Un client peut terminer une migration, mais craindre qu’un litige de compte n’affecte les mises à jour ultérieurement. Un prêteur peut financer une plateforme dont les revenus dépendent de points de terminaison stables. Une autorité d’approvisionnement peut exiger la preuve que le fournisseur peut maintenir son identité publique pendant une catastrophe. La continuité n’est pas une vertu philosophique; c’est un intrant commercial.

La neutralité exige également une discipline de mandat. Un registre doit vérifier les faits pertinents pour l’unicité, la reconnaissance du détenteur, l’utilisation autorisée, la possibilité de contact, l’origine de la route, le DNS inverse, le traitement des abus, les transferts et les litiges. Il ne doit pas utiliser ces faits comme une voie pour approuver ou désapprouver une stratégie cloud. Si un détenteur apporte un préfixe à une plateforme mondiale, la question du registre ne doit pas être de savoir si la plateforme est souhaitable. Elle doit être de savoir si le détenteur ou l’utilisateur autorisé est correctement étayé par des preuves et si l’enregistrement reste exact. Si un client loue un espace d’adressage pour une migration cloud, la question ne doit pas être de savoir si la location est moralement attrayante. Elle doit être de savoir si l’enregistrement d’utilisation autorisée, le traitement des abus, l’origine de la route et la durée sont suffisamment lisibles pour les contreparties.

Un registre neutre réduit l’enfermement de plateforme en rendant les alternatives appartenant au client moins chères. Le fournisseur cloud peut toujours vendre de la commodité, de la performance, de la sécurité et des services gérés. Il ne peut pas compter sur l’incertitude du registre pour faire de son propre inventaire d’adresses la seule option pratique. L’opérateur local peut toujours être compétitif en proposant des services hybrides. La banque peut toujours choisir le cloud pour des raisons légitimes. L’organisme public peut toujours décider que les adresses du fournisseur sont acceptables. Mais ces choix sont faits en présence d’une voie indépendante crédible.

La crise de gouvernance de l’AFRINIC montre pourquoi cette discipline est difficile. Lorsqu’une institution est confrontée à des litiges, des antécédents de corruption, des élections contestées, des questions sur la légitimité du conseil d’administration et des conflits de ressources, elle peut être tentée de se défendre en élargissant son pouvoir discrétionnaire. Elle peut présenter davantage de décisions comme nécessaires pour protéger la communauté, préserver l’intérêt régional ou empêcher les abus. Une certaine protection est nécessaire. La fraude et les autorités forgées doivent être rejetées. Les enregistrements dormants doivent être nettoyés avec soin. Les litiges doivent être consignés. Mais si la protection devient un contrôle sans limite de l’utilisation commerciale, elle augmente la prime même qui pousse les clients vers les plateformes.

La continuité n’est donc pas une faiblesse. C’est une force institutionnelle. Elle montre que le registre est suffisamment confiant dans sa fonction étroite pour ne pas juger chaque stratégie cloud, de location, de résidence de données ou de client. Il préserve l’enregistrement, et non l’effet de levier du registre sur l’enregistrement. Cela réduit la valeur marchande du contrôle d’accès.

Pour l’AFRINIC, le test anti-enfermement est pratique. Un petit opérateur africain peut-il mettre à jour les données de contact, le DNS inverse et les preuves d’origine de route sans se retrouver piégé dans un conflit institutionnel sans rapport? Un utilisateur autorisé peut-il montrer à un fournisseur cloud un ensemble de preuves standard? Un client peut-il distinguer un vrai litige d’un vague malaise du registre? Les services peuvent-ils rester disponibles pendant que les processus du conseil d’administration ou des tribunaux se poursuivent? Les détenteurs placés dans des situations similaires peuvent-ils s’attendre à un traitement similaire? Si oui, l’AFRINIC soutient l’optionalité d’adressage. Si non, les plateformes cloud et les opérateurs en place héritent du pouvoir de négociation.

La mauvaise réponse consiste à lutter contre les plateformes en élargissant le pouvoir discrétionnaire du registre

Une réponse tentante au pouvoir d’adressage des fournisseurs cloud est que les registres deviennent plus interventionnistes. Si les grandes plateformes ont trop d’inventaire d’adresses, restreignez les transferts. Si les clients apportent des adresses dans les clouds mondiaux, demandez-vous si l’utilisation sert la région. Si la location crée une dépendance à la plateforme, considérez la location comme suspecte. Si du trafic hors région apparaît, transformez la géographie en test d’autorisation. Si les fournisseurs cloud bénéficient de la rareté, utilisez la politique de registre pour rationner qui peut la monétiser.

Cette réponse prend l’économie à l’envers. Élargir le pouvoir discrétionnaire du registre renforce souvent la position de plateforme qu’elle prétend combattre. La raison est simple: les clients ne cessent pas d’avoir besoin d’IPv4 publiques parce qu’un registre n’aime pas un modèle d’affaires. Ils cherchent la voie qui passe l’approvisionnement et la livraison. Si l’espace AFRINIC appartenant au client ou loué devient plus difficile à expliquer, les adresses cloud du fournisseur deviennent plus faciles à accepter. Le registre peut croire qu’il défend les intérêts régionaux tout en poussant les clients dans l’inventaire mondial des plateformes.

Le pouvoir discrétionnaire a un effet de marché caché. Il rend les adresses indépendantes moins bancables. Un fournisseur cloud qui envisage le BYOIP se demande si le client peut maintenir une autorité reconnue. Une banque se demande si un préfixe pourrait être contesté en raison d’une théorie d’utilisation commerciale. Un client se demande si un bail d’adresse pourrait être contesté. Un acheteur public se demande si le plan d’adressage d’un fournisseur dépend de la vision changeante du registre quant à l’intérêt régional. Chaque question ajoute du risque au chemin indépendant. La voie appartenant à la plateforme semble plus propre parce que la plateforme a déjà internalisé le risque de registre par ses propres allocations et son architecture.

Cela ne signifie pas que chaque transaction d’adresse doit être approuvée. Un registre doit rejeter les documents falsifiés, les transferts non autorisés, les espaces dormants détournés et les fausses déclarations. Il doit maintenir l’unicité. Il peut avoir besoin d’enregistrer les ordonnances judiciaires, les faits de sanctions, les litiges d’autorité d’entreprise et les défaillances de contact prouvées liées aux abus. Il devrait exiger des enregistrements à jour et des contacts responsables. Il devrait soutenir la sécurité du routage. Mais ce sont des règles de preuve. Elles diffèrent du pouvoir discrétionnaire de politique industrielle.

La distinction est cruciale dans le contexte de l’AFRINIC. Les litiges publics autour de Cloud Innovation, Larus, la location, l’utilisation hors région et l’examen des ressources ont rendu l’utilisation commerciale des IPv4 administrées en Afrique politiquement saillante. Certains observateurs considèrent la location et la monétisation comme un abus des ressources communautaires. D’autres les voient comme des réponses ordinaires du marché à la rareté et comme un moyen pour les détenteurs de tirer de la valeur de ressources rares assimilables à du capital. L’AFRINIC n’a pas besoin de résoudre ce conflit politique pour remplir sa fonction de registre. Elle doit définir les preuves requises pour l’autorité reconnue du détenteur, l’utilisation autorisée, l’origine de la route, la possibilité de contact, le statut du transfert et la notation des litiges.

Si un tribunal rend une ordonnance spécifique, le registre doit la respecter dans le cadre de son champ d’application. Si un contrat autorise ou limite une utilisation, les parties peuvent le plaider ou l’arbitrer. Si une fraude est prouvée, les enregistrements doivent être corrigés. Mais le registre ne devrait pas introduire subrepticement une vaste politique cloud ou de location dans la reconnaissance des enregistrements. C’est du blanchiment de mandat: utiliser l’autorité étroite de maintenir un grand livre d’adresses unique comme véhicule pour un contrôle économique plus large.

La mauvaise réponse est particulièrement préjudiciable aux petits opérateurs. Un grand fournisseur cloud peut se conformer à des règles complexes, détenir plusieurs pools d’adresses, contourner l’incertitude et employer des avocats. Un petit opérateur ne le peut pas. Si le pouvoir discrétionnaire du registre rend plus difficile l’utilisation de l’espace indépendant dans le cloud, le petit opérateur perd précisément le levier de rareté qu’IPv4 pourrait autrement lui donner. Il devient un client du système d’adressage de la plateforme plutôt qu’un détenteur d’identité réseau portable.

La meilleure réponse est la modestie procédurale. Rendez l’enregistrement exact. Rendez l’utilisation autorisée lisible. Rendez les litiges précis. Rendez les mises à jour prévisibles. Rendez les recours disponibles. Rendez la continuité du service robuste. Laissez les clients cloud, les plateformes, les opérateurs et les régulateurs négocier leurs propres arrangements commerciaux au-dessus d’un grand livre stable. Un registre qui tente de vaincre le pouvoir du cloud en élargissant son propre pouvoir discrétionnaire risque de devenir l’allié accidentel de la plateforme.

L’admission cloud devrait être traitée par des preuves prévisibles

Un régime AFRINIC adapté au cloud n’exigerait pas de l’AFRINIC qu’elle construise des produits cloud ou qu’elle bénisse les migrations cloud. Cela exigerait du registre qu’il comprenne comment ses enregistrements sont utilisés dans l’admission cloud et qu’il rende les preuves pertinentes prévisibles. L’unité d’analyse devrait être le dossier de preuves, et non l’opinion du registre sur la stratégie commerciale du client.

Le dossier commence par la reconnaissance du détenteur. Qui est le détenteur reconnu actuel ou le détenteur historique? Le nom est-il à jour après des fusions, restructurations ou changements d’entreprise? Le compte est-il dans un statut qui permet des mises à jour de routine? Y a-t-il un litige spécifique ou une ordonnance du tribunal? Si oui, quels faits sont contestés et quels services sont affectés? Un fournisseur cloud ne devrait pas avoir à déduire cela de rumeurs, de communiqués de presse ou de déclarations factionnelles.

Le deuxième élément est l’utilisation autorisée. De nombreux cas cloud impliquent une différence entre le détenteur, la société d’exploitation, le compte cloud et l’AS d’origine. Cette différence n’est pas automatiquement suspecte. Un groupe d’entreprises peut centraliser les avoirs d’adresses. Une banque peut utiliser un fournisseur de services gérés. Une entreprise SaaS peut louer un préfixe. Un organisme public peut externaliser ses opérations. Le registre n’a pas besoin d’approuver chaque contrat, mais les preuves publiques et privées devraient rendre la chaîne d’autorité lisible: détenteur, utilisateur autorisé, durée le cas échéant, mécanismes de révocation, contact en cas d’abus, autorité d’origine de route et responsabilité du DNS inverse.

Le troisième élément est la preuve d’origine de route. Les processus BYOIP reposent sur les ROA, les vérifications d’origine de route, les annonces de route ou une validation équivalente. L’AFRINIC devrait rendre prévisible qui peut demander, modifier ou retirer les ROA et les preuves de routage connexes, comment les litiges affectent ces actions et quelles protections de continuité s’appliquent en cas de stress de compte ou de gouvernance. La migration cloud d’un client ne devrait pas échouer parce que le registre ne peut pas distinguer entre un transfert contesté et une mise à jour d’origine de route non contestée pour le dernier détenteur vérifié.

Le quatrième élément est le DNS inverse et la réputation. Les clients qui apportent des adresses dans le cloud le font souvent parce qu’ils ont besoin d’une réputation établie et d’une continuité de liste blanche. Le DNS inverse, les contacts en cas d’abus et les données d’enregistrement publiques soutiennent cette continuité. L’AFRINIC devrait les préserver et les mettre à jour selon des règles claires. Si une délégation de DNS inverse est rejetée, la raison devrait être liée à un défaut technique ou d’autorité spécifique, et non à une vision vague du modèle commercial du client.

Le cinquième élément est la précision des litiges. « En litige » n’est pas un signal de marché suffisant si les contreparties ne savent pas ce que le litige affecte. Une ordonnance du tribunal préservant le statut d’entreprise est différente d’une allégation de fausse autorité. Un problème de paiement est différent d’une contestation de transfert. Un litige électoral au conseil d’administration est différent d’une injonction spécifique à un préfixe. Un registre qui consigne des états de litige précis aide les fournisseurs cloud et les clients à gérer le risque. Un registre qui laisse un langage de litige vague les oblige à réagir de manière excessive.

Le sixième élément est des niveaux de service non discriminatoires. Des demandes similaires devraient recevoir un traitement similaire, que le détenteur soit un grand opérateur, une plateforme adjacente au cloud, un petit FAI, une université, un organisme public, un client soutenu par un courtier ou un plaideur impopulaire auprès d’une partie de la communauté. Les délais, les exigences en matière de preuves, les voies de recours et les droits d’appel devraient être publiés. Plus IPv4 prend de la valeur, plus il est important que le pouvoir discrétionnaire en matière de service ne ressemble pas à une préférence économique.

Enfin, le registre devrait maintenir une piste d’audit. L’admission cloud et la diligence financière récompensent toutes deux la traçabilité. Qui a demandé un changement? Quelles preuves ont été fournies? Qu’est-ce qui a été approuvé? Qu’est-ce qui a été rejeté? Quel service a été affecté? Quel litige a été consigné? Quelle voie existe pour corriger une erreur? Ce n’est pas de la bureaucratie pour la bureaucratie. C’est ainsi qu’une ressource d’adresses rare devient suffisamment bancable pour être utilisée sur plusieurs plateformes.

La documentation des fournisseurs cloud va dans ce sens. AWS interroge les enregistrements RDAP et les preuves d’origine de route dans son processus BYOIP EC2 et utilise IPAM comme autre voie de contrôle. Azure sépare la validation, l’approvisionnement et la mise en service et met en évidence la vérification de la propriété, la réputation et les listes blanches. Google utilise la validation ROA et de DNS inverse, les préfixes annoncés publics, les préfixes délégués, la portée du projet et les avertissements concernant les annonces qui se chevauchent. Tous ces systèmes supposent que l’enregistrement d’adresse externe peut produire des faits fiables. Le travail de l’AFRINIC est de rendre cette hypothèse sûre pour l’espace administré en Afrique.

Des preuves prévisibles ne garantissent pas l’acceptation. Un fournisseur peut toujours imposer des limites de produit, des restrictions régionales, des tailles minimales de préfixe, des seuils de réputation, des exigences de compte ou des politiques de sécurité. Mais un registre prévisible donne au client africain une chance équitable de respecter ces règles. Un registre imprévisible permet aux adresses propres de la plateforme de l’emporter avant même que l’architecture du client ne soit évaluée.

Le plan d’adressage est le point de rencontre entre la stratégie cloud et le capital IPv4

La rareté IPv4 a fait de la planification d’adressage un problème d’allocation de capital. Une entreprise qui décide d’utiliser les adresses du fournisseur, d’apporter son propre préfixe, de louer de l’espace, d’acquérir un bloc, d’économiser par le NAT ou d’attendre l’adoption d’IPv6 alloue une optionalité rare. Le plan d’adressage affecte le coût de migration, la fidélisation de la clientèle, le financement, la reprise après sinistre, l’accès des partenaires et le pouvoir de négociation.

Le caractère quasi-capitalistique d’IPv4 n’exige pas de prétendre que les adresses sont des terrains ou que la doctrine du registre n’a aucune force. Les ressources de numérotation font toujours partie d’un système d’unicité. Elles dépendent de la coordination. Ce ne sont pas des biens physiques ordinaires. Mais la dépendance économique est indéniable. Un bloc IPv4 reconnu peut soutenir des revenus, des relations clients, des contrats, une migration de plateforme, une diligence de prêt et une continuité opérationnelle. Sa valeur dépend de la rareté et de la confiance dans le fait que la reconnaissance persistera.

Le cloud a aiguisé cette logique de capital. Les IPv4 publiques ont un coût observable dans les factures cloud. Le BYOIP peut éviter certains frais d’adresse tout en préservant la réputation et les listes blanches. Les adresses du fournisseur réduisent les frictions initiales mais peuvent augmenter le coût de changement futur. Le NAT économise de rares points de terminaison publics mais concentre l’identité publique. Un bloc portable propre peut être utilisé comme option stratégique entre les fournisseurs. Un bloc contesté ou faiblement étayé par des preuves ne le peut pas.

Pour les opérateurs africains, cela crée une question financière difficile. Une entreprise devrait-elle dépenser un capital rare pour acquérir ou louer des IPv4 si l’incertitude du registre peut réduire leur utilisabilité dans le cloud? Devrait-elle compter sur les adresses de la plateforme si cela crée un coût de sortie futur? Devrait-elle conserver les charges de travail dans un hébergement local parce que le BYOIP est incertain? Devrait-elle concevoir des services IPv6-first même si de nombreux partenaires exigent encore IPv4? Ce sont des décisions d’allocation de capital sous incertitude institutionnelle, et non de simples préférences d’ingénierie.

Les grandes plateformes en profitent parce qu’elles peuvent transformer la certitude d’adressage en optionalité de produit: utilisez nos adresses et évitez le dossier d’adressage indépendant; apportez les vôtres si vous pouvez satisfaire la validation; utilisez la connectivité privée si l’exposition publique n’est pas nécessaire; achetez des services gérés qui abstraient les points de terminaison publics. Ce menu est précieux. C’est aussi une façon de monétiser l’écart entre la certitude de la plateforme et l’incertitude externe.

La crise de l’AFRINIC ajoute à cet écart. Lorsqu’un registre se remet d’une mise sous séquestre, de litiges et de questions de légitimité, les clients prudents attribuent moins de valeur au capital d’adressage indépendant. Ils peuvent toujours détenir un bloc rare, mais l’utilisabilité cloud du bloc est décotée. La décote n’est pas inévitable. C’est une fonction de la qualité des preuves. Si l’AFRINIC peut rendre l’utilisation autorisée, l’origine de route, le DNS inverse et la reconnaissance du détenteur prévisibles, la valeur en capital de l’espace administré en Afrique augmente. Si elle ne le peut pas, les mêmes adresses rares restent utiles opérationnellement mais stratégiquement plus faibles.

La perspective du capital clarifie également pourquoi « utilisez simplement IPv6 » est insuffisant pour le problème de cet article. IPv6 peut réduire la rareté numérique à long terme, et de nombreuses conceptions cloud et réseau devraient le prendre en charge. Mais les fintechs africaines, les banques, les organismes publics et les plateformes SaaS opèrent toujours dans un environnement commercial dépendant d’IPv4. Les partenaires, les pare-feu, les systèmes hérités, les réseaux grand public, les systèmes de détection de fraude et les dossiers d’approvisionnement continuent de rendre la joignabilité IPv4 précieuse. Pendant la période de double pile, IPv4 reste un pont rare entre les anciens et les nouveaux systèmes. Celui qui contrôle l’identité IPv4 fiable contrôle le levier de négociation.

Ce levier peut être détenu par les clients, les opérateurs locaux, les détenteurs d’adresses régionaux, les courtiers, les opérateurs ou les plateformes cloud. La conception institutionnelle de l’AFRINIC affecte la distribution. Un enregistrement neutre permet au détenteur d’un capital d’adressage rare de le déployer sur les clouds et les réseaux. Un enregistrement discrétionnaire supprime ce capital et rend les substituts appartenant aux plateformes plus forts. Le plan d’adressage est donc le point où la légitimité du registre devient l’économie du cloud.

La leçon pratique pour les clients est de traiter les décisions d’adressage comme des actifs stratégiques, et non comme des restes de déploiement. La leçon pratique pour l’AFRINIC est de rendre ces actifs lisibles sans prétendre posséder leur destin commercial.

Le futur compromis est la portabilité sans politique de permission

Revenons à l’entreprise de paiement de Lagos. Son conseil d’administration n’a pas besoin que l’AFRINIC choisisse un fournisseur cloud, approuve une stratégie fintech, subventionne l’hébergement local ou punisse les plateformes mondiales. Il a besoin d’un environnement d’adressage public dans lequel les choix ont des prix clairs. Si l’entreprise utilise les adresses du fournisseur cloud, elle doit savoir qu’elle achète de la commodité et accepte un certain coût de sortie. Si elle apporte son propre préfixe, elle doit savoir quelles preuves sont requises et comment la continuité sera protégée. Si elle utilise le NAT, elle doit savoir quels points de terminaison publics deviennent un risque concentré. Si elle loue ou acquiert des IPv4 portables rares, elle doit savoir comment la reconnaissance du détenteur, l’utilisation autorisée, l’origine de la route, le DNS inverse et les contacts en cas d’abus seront documentés.

C’est la portabilité sans politique de permission. Le registre tient le registre neutre. Le client fait le choix commercial. Le fournisseur cloud fixe les exigences et les prix des produits. La banque demande une assurance opérationnelle. Le régulateur applique la loi. Les tribunaux résolvent les litiges spécifiques. Aucun de ces acteurs n’a besoin que le registre devienne un gardien économique général de l’utilisation du cloud.

Les enjeux sont importants parce que le cloud public devient l’un des principaux moyens pour les services numériques africains de monter en échelle. Les fintechs, les banques, les entreprises de logistique, les plateformes de santé, les universités, les diffuseurs, les sociétés de sécurité et les organismes publics continueront d’utiliser les plateformes hyperscale là où elles sont utiles. Ils auront également besoin d’hébergement local, de systèmes hybrides, de reprise après sinistre et de levier multi-fournisseurs. La portabilité des adresses est l’un des instruments silencieux qui permet à ces options de coexister.

Si la couche d’enregistrement de l’AFRINIC est fiable, les IPv4 administrées en Afrique peuvent servir de capital de négociation. Un client peut entrer dans le cloud sans renoncer à toute son identité publique. Un opérateur local peut vendre des services gérés sans être réduit à de la plomberie d’accès. Un organisme public peut exiger une continuité entre les fournisseurs. Une banque peut concevoir une sortie cloud sans renuméroter chaque partenaire. Une entreprise SaaS peut préserver sa réputation tout en changeant d’infrastructure. Dans ce monde, les fournisseurs cloud gagnent toujours des affaires en offrant de meilleures plateformes, et non en étant la seule source sûre d’adresses publiques.

Si la couche d’enregistrement de l’AFRINIC n’est pas fiable, c’est l’inverse qui se produit. Les adresses du fournisseur deviennent le choix conservateur. Le BYOIP devient une voie spécialisée pour les grandes entreprises. L’espace africain loué s’accompagne d’une diligence supplémentaire. Les petits opérateurs perdent le levier de la rareté. L’approvisionnement du secteur public parle de contrôle local tout en acceptant la dépendance aux adresses de la plateforme. La rareté IPv4, au lieu de donner du pouvoir aux détenteurs africains, est monétisée par les acteurs disposant des plus grands inventaires et des dossiers de confiance les plus solides.

La réponse conceptuelle est concrète: des enregistrements prévisibles, des preuves d’utilisation autorisée, des mises à jour non discriminatoires, une continuité de service, une notation précise des litiges, des pistes d’audit, une fiabilité de l’origine de route, une continuité du DNS inverse, une exactitude des contacts en cas d’abus et une séparation claire entre la politique industrielle du cloud et la reconnaissance des adresses. Ce sont des règles modestes, mais elles façonnent un vaste marché.

La crise de l’AFRINIC rend la leçon plus vive parce qu’elle montre à quelle vitesse un registre peut devenir économiquement visible lorsque la rareté, les litiges et la dépendance aux plateformes se rencontrent. Un registre neutre n’est pas impuissant. Il peut réduire l’asymétrie de négociation en rendant les faits publics fiables. Un registre discrétionnaire n’est pas plus fort; il transfère le pouvoir à celui qui peut survivre à son incertitude.

Les fournisseurs cloud ont déjà fait de l’IPv4 publique un intrant tarifé, surveillé et régi par des politiques. Le test pour l’AFRINIC est de savoir si un client africain peut apporter un préfixe légitime à une plateforme, maintenir les preuves d’origine de route et de DNS inverse, répondre aux questions d’abus et de réputation, et partir plus tard sans demander à un registre de bénir le modèle d’affaires. Si ce dossier est ordinaire, le cloud devient une infrastructure. S’il est exceptionnel, la plateforme devient le propriétaire par défaut de l’identité publique.