Ce que les entreprises d’IA doivent savoir sur la gouvernance des adresses IP

Les discussions sur les infrastructures d’IA commencent généralement par les moyens de calcul : GPU, alimentation électrique, refroidissement, centres de données, stockage et interconnexions. Ces investissements sont visibles. L’identité réseau qui les sous-tend passe plus facilement inaperçue.

Un service d’IA accessible au public a pourtant besoin de points de terminaison joignables. Ses clients peuvent inscrire des adresses précises dans leurs listes d’autorisation. Son routage peut dépendre d’un numéro de système autonome. Ses dispositifs de sécurité peuvent reposer sur RPKI, le DNS inverse et un historique rattaché à cette même identité réseau.

D’où la question à laquelle répond ce guide : comment une entreprise d’IA peut-elle maintenir son réseau joignable lorsqu’une adresse, un fournisseur ou un registre devient un facteur de risque ?

D’abord, distinguer capacité et identité

Une adresse IP peut d’abord constituer une simple capacité. Un environnement de développement temporaire peut passer à une autre adresse sans grande perturbation. Il en va autrement d’une API en production dès lors que des clients, des partenaires, des pare-feu, des systèmes de supervision et des dossiers de conformité dépendent de cette adresse précise.

L’adresse fait alors partie de l’identité réseau de l’entreprise. Le coût n’est plus celui d’une adresse. C’est celui de la modification de tous les systèmes externes qui ont appris à lui faire confiance.

Cette distinction offre à une équipe d’infrastructure un meilleur point de départ que la seule question du nombre d’adresses nécessaires. Elle doit se demander quelles adresses sont remplaçables sans conséquence, lesquelles servent la production et lesquelles sont devenues difficiles à remplacer.

Quatre couches faciles à confondre

Les équipes d’IA peuvent prendre de meilleures décisions en distinguant quatre couches :

• La ressource. Les préfixes IPv4 et IPv6, ainsi que les numéros de système autonome, donnent aux réseaux des identifiants uniques à l’échelle mondiale.
• L’enregistrement dans le registre. Un registre consigne qui détient ou contrôle une ressource et aide l’ensemble d’Internet à éviter les revendications contradictoires.
• Le réseau en fonctionnement. Les annonces BGP, les routeurs, les fournisseurs de connectivité en amont et les applications déterminent si le trafic atteint effectivement un service.
• L’assertion de sécurité. RPKI et une autorisation d’origine de route, ou ROA, aident les autres réseaux à vérifier si un ASN est autorisé à être à l’origine des annonces d’un préfixe.

Un enregistrement dans un registre n’achemine aucun paquet à lui seul. Un enregistrement exact reste néanmoins précieux, car les autres réseaux s’appuient sur les enregistrements et les assertions de sécurité pour décider de ce qu’ils reconnaissent. La précision est essentielle : consigner une ressource relève de la coordination et ne confère pas la propriété de l’activité construite autour d’elle.

Pourquoi cela devient un problème de continuité d’activité

Imaginons une plateforme d’IA dont le préfixe de l’API principale figure dans les listes d’autorisation des clients, les pare-feu des partenaires, les VPN, les dispositifs de lutte contre les abus, la supervision et le routage régional. L’entreprise peut avoir acheté la ressource, l’avoir louée ou l’avoir obtenue auprès d’un fournisseur. Chaque formule crée des dépendances différentes, mais toutes deviennent plus coûteuses à modifier une fois le préfixe profondément intégré.

Une panne de fournisseur n’est qu’une forme de défaillance. Le service administratif qui l’entoure peut aussi devenir indisponible, faire l’objet d’un litige, perdre l’accès à ses systèmes ou prendre une décision qui prive le réseau en fonctionnement de tout moyen pratique de préserver son identité.

Le cluster de calcul de l’entreprise peut encore fonctionner normalement. Ses clients peuvent continuer à payer. Pourtant, le coût d’une renumérotation peut transformer un problème administratif en problème de service et de chiffre d’affaires.

Acheter ou louer une adresse ne supprime pas la dépendance

L’achat peut être judicieux lorsqu’une entreprise d’IA a besoin d’une capacité prévisible à long terme. La location peut l’être lorsqu’elle recherche de la souplesse ou une expansion rapide. Aucune de ces transactions ne répond à toutes les questions de continuité.

Avant que la production ne dépende d’un préfixe, l’équipe doit savoir :

• Qui est inscrit comme titulaire de la ressource ?
• Quel registre administre l’enregistrement ?
• Quel ASN peut être à l’origine des annonces du préfixe ?
• Qui peut créer ou modifier le ROA ?
• Qui contrôle le DNS inverse et les accès administratifs ?
• Que se passe-t-il si un fournisseur, un courtier ou un bailleur disparaît ?
• Que se passe-t-il lorsqu’une location prend fin ou qu’un registre devient indisponible ?

Le prix par adresse n’est donc qu’un critère d’achat parmi d’autres. Pour un préfixe critique, un critère plus utile est la continuité assurée par adresse.

RPKI doit suivre le réseau qui fonctionne réellement

Supposons qu’une entreprise fasse passer un préfixe d’un ASN à un autre. Sa configuration BGP peut être correcte, alors que l’ancien ROA n’autorise encore que l’origine précédente. Les réseaux qui valident l’origine des routes peuvent alors considérer la nouvelle annonce comme invalide.

La règle opérationnelle est simple : une modification de routage et son assertion de sécurité relèvent du même processus de changement. RPKI doit répondre à la question technique précise pour laquelle il a été conçu : quel ASN est autorisé à être à l’origine des annonces de ce préfixe ?

Il ne doit pas devenir un mécanisme général de sanction pour des différends commerciaux ou institutionnels sans rapport avec cette fonction. La sécurité doit protéger le réseau en fonctionnement. Elle ne doit pas créer un point de contrôle supplémentaire, sans possibilité de recours, sur l’activité de l’entreprise.

Pour les fondements techniques, voir l’architecture RPKI et les références de l’IANA sur les ressources de numérotation.

La solution : une coordination limitée à l’essentiel et une véritable possibilité de sortie

Les entreprises d’IA ont bien besoin de coordination. Les adresses doivent rester uniques. Les enregistrements doivent être exacts. La sécurité du routage doit être vérifiable. Les transferts et les changements de contrôle doivent pouvoir être audités.

Ces fonctions n’exigent pas qu’un administrateur devienne irremplaçable. Une conception plus robuste permettrait au titulaire d’une ressource de prouver son contrôle, de transmettre à un autre service un enregistrement vérifiable de manière indépendante et de maintenir le réseau en fonctionnement si un administrateur fait défaut.

C’est le sens concret de la portabilité. Il ne s’agit pas de pouvoir déménager un bureau ou adhérer à une autre organisation. Il s’agit de pouvoir préserver l’enregistrement de la ressource, la preuve de contrôle, les assertions de sécurité et la continuité opérationnelle lorsque le dispositif administratif en place doit changer.

Changer le nom sur la porte ne résout pas le problème structurel si l’entreprise ne peut toujours pas partir. La procédure de remplacement doit faire partie du système avant qu’une crise ne la rende nécessaire. Cet argument est développé dans La Déclaration des droits de la coordination de l’unicité et L’illusion de la continuité des registres.

Un inventaire pratique pour une équipe d’infrastructure d’IA

Avant de faire passer un service d’IA accessible au public à plus grande échelle, tenez à jour un inventaire unique répondant aux questions suivantes :

• Quels préfixes IPv4 et IPv6 servent la production ?
• Quels ASN sont utilisés, et quel ASN est à l’origine des annonces de chaque préfixe ?
• Qui contrôle le compte auprès du registre, le DNS inverse et les clés RPKI ?
• Quelles ressources sont louées, attribuées par un fournisseur ou détenues directement ?
• Quels clients et partenaires ont inscrit les adresses dans leurs listes d’autorisation ?
• Combien coûterait la renumérotation de chaque préfixe critique ?
• Quelle procédure de remplacement est prévue si un fournisseur ou un registre fait défaut ?

Classez les résultats en trois catégories : capacité remplaçable sans conséquence, capacité de production et identité critique pour l’activité. Cette dernière mérite la même réflexion sur le basculement de secours que celle déjà appliquée à l’alimentation électrique, au stockage, au transit et aux fournisseurs de cloud.

Pourquoi il faut commencer avant la première défaillance

IPv6 peut réduire la pression sur IPv4, et les entreprises devraient l’utiliser lorsqu’il convient à leurs clients et à leurs systèmes. Il ne fait pas disparaître du jour au lendemain toutes les dépendances à IPv4. De nombreux réseaux d’entreprise, listes d’autorisation et services externes dépendent encore d’une identité IPv4 stable.

Attendre qu’un fournisseur ou un registre soit déjà défaillant prive du temps nécessaire pour tester les enregistrements, comparer les solutions et se coordonner avec les clients. L’urgence est opérationnelle, sans qu’il soit besoin de dramatiser : plus les systèmes s’habituent à une identité, plus un changement imprévu devient coûteux.

Les entreprises d’IA construisent des infrastructures à longue durée de vie, fortement dépendantes de systèmes externes. Elles devraient appliquer aux ressources de numérotation la même rigueur qu’au calcul et à l’alimentation électrique : supprimer les points de défaillance uniques inutiles, documenter la dépendance et rendre le remplacement possible avant qu’il ne soit nécessaire.

La question à poser au conseil d’administration

Les dirigeants n’ont pas besoin de configurer BGP. Ils doivent en revanche demander si les identités réseau les plus importantes de l’entreprise peuvent résister à un changement de fournisseur, à une assertion de sécurité obsolète ou à une défaillance institutionnelle.

La bonne question n’est pas seulement : « Avons-nous assez d’adresses IP ? » C’est aussi :

• Qui peut les modifier ?
• Qui peut les router ?
• Qui peut modifier les assertions de sécurité ?
• Quels clients en dépendent ?
• L’entreprise peut-elle les préserver si l’administrateur ne peut plus assurer sa mission ?

Voilà ce que signifie la gouvernance des adresses IP à l’échelle des infrastructures. Protéger l’unicité, l’exactitude, les assertions de sécurité légitimes et le réseau en fonctionnement. Faire en sorte que l’administrateur reste remplaçable.

Pour approfondir l’argument de fond

Ce guide explique la question opérationnelle. L’argument plus général est développé dans les Notes de Lu Heng : identité réseau et continuité pour les clients, Primauté du code opérationnel et la proposition de droits pour la coordination de l’unicité.

Sur la question de l’approvisionnement, lire Pourquoi i.LEASE existe. Le fil conducteur est simple : une transaction peut donner à une entreprise accès à une ressource, mais seule une conception qui prévoit la continuité peut rendre cet accès durable.