Cette définition a des conséquences. Elle exclut la commodité avant d’exclure les fournisseurs.

Ce que cela signifie concrètement

Concrètement, une infrastructure souveraine repose sur quatre engagements non négociables : les données restent là où vous les posez sans sous-traitant dans le chemin ; la piste d’audit est locale et physique ; chaque système est reproductible depuis un dépôt Git sur du matériel que vous pouvez toucher ; et chaque composant a un chemin de sortie documenté avant son adoption.

Pour nous, une infrastructure souveraine, c’est quatre engagements :

1. Les données restent là où vous les avez posées. Aucun sous-traitant dans le chemin de requête sans décision explicite, et vous savez le nommer.
2. La piste d’audit est locale. Journaux, prompts, documents : si un régulateur ou un client demande où cette donnée vit physiquement, la réponse est une baie, pas une région.
3. Reconstruire est une commande, pas un projet. Tout ce que nous opérons est décrit en code et reproductible depuis un dépôt Git sur du matériel que l’on peut toucher.
4. La sortie est conçue à l’entrée. Si un composant disparaît demain, le chemin de migration est documenté avant l’adoption du composant.

Rien de tout cela n’est exotique. Les opérateurs réseau carrier-grade travaillent ainsi depuis des décennies. Ce qui a changé, c’est que l’outillage convient enfin aux petites équipes : Talos Linux pour un Kubernetes déclaratif, Ansible pour le métal, GitOps pour le cycle de vie.

Ce que cela coûte

La souveraineté échange du labeur opérationnel contre du contrôle : vous patchez vos propres hyperviseurs, possédez l’astreinte de 3 h du matin pour un disque en fin de vie, et maintenez la rotation TLS et le capacity planning qu’une plateforme managed absorberait. Le compromis vaut le coup pour les charges qui comptent : données de planification, télémétrie, identité client. Pas pour tout.

L’honnêteté exige l’étiquette de prix. La souveraineté échange du labeur opérationnel contre du contrôle. Vous patcherez vos propres hyperviseurs. Vous posséderez l’astreinte de 3 h du matin quand un disque décidera de prendre sa retraite avant l’heure. Vous maintiendrez la rotation TLS, les restaurations de sauvegarde et le capacity planning qu’une plateforme managée absorberait invisiblement.

Notre position est que ce compromis vaut le coup pour les charges de travail qui comptent : données de planification, télémétrie de sécurité, tout ce qui touche à l’identité d’un client. Pour le reste, le pragmatisme est une qualité, pas un renoncement. Le savoir-faire, c’est de tracer la ligne délibérément au lieu de l’hériter d’un deck marketing.

Pourquoi cela compte pour l’IA

Les grands modèles de langage rendent la souveraineté urgente : les équipes collent contrats, identifiants et données clients dans des chats externes avec pour seule protection un accord de sous-traitance. La réponse : inférence locale pour les documents sensibles, passerelle d’assainissement devant toute API externe, et évaluations reproductibles versionnées comme tout artefact.

Les grands modèles de langage ont déplacé les lignes. Des équipes collent désormais contrats, identifiants et données clients dans des fenêtres de chat hébergées on ne sait où, et la réponse conformité est un accord de sous-traitance que personne ne lit.

Les mêmes quatre engagements s’appliquent, presque inchangés :

• Inférence locale pour les documents sensibles, avec des poids de modèle que l’on peut épingler et auditer.
• Une passerelle d’assainissement devant toute API externe, masquant les identifiants avant l’envoi.
• Des campagnes d’évaluation reproductibles, avec prompts et sorties versionnés comme n’importe quel artefact.

C’est le raisonnement derrière les produits que nous construisons chez Cardinal Codes, et c’est le fil que vous trouverez dans chaque article de ce blog : les décisions d’infrastructure comme décisions de souveraineté.

Bienvenue dans les notes de terrain.

Cet article rassemble ce que nous avons vérifié en production lors de l’ingénierie d’un peering redondant pour un environnement opérateur, anonymisé comme toujours.

Le socle

La topologie de référence est deux datacenters annonçant le même préfixe RIPE /32 via deux transitaires chacun, reliés par un interconnect privé pour la synchronisation. Toute la politique de steering tient en quatre valeurs de communautés BGP : prepend x1, x2, x3 et un blackhole protégé, appliquées cohéremment sur les deux sites.

La topologie est volontairement ennuyeuse : deux datacenters, un bloc RIPE /32 annoncé des deux côtés, interconnect privé pour la synchro. Les deux sites reçoivent les tables complètes de deux transitaires chacun. Ce qui est intéressant, ce n’est pas le schéma, c’est la politique qui y est attachée.

Les communautés qui ont fait leurs preuves

Trois conventions de communautés BGP ont porté tout le poids du steering : une échelle de prepend canonique (x1, x2, x3) détenue par un seul ASN, une réécriture des communautés entrantes en bordure dans cet espace canonique, et une communauté blackhole à débit limité protégée comme une règle de pare-feu. L’idée clé : maîtriser le vocabulaire de bout en bout.

Trois conventions ont porté tout le poids :

# Lisible, stable, documenté dans la base de peering
65000:100   prepend x1 vers le voisin marqué
65000:200   prepend x2
65000:300   prepend x3
65000:666   blackhole (filtre URF, protégé par max-prefix)

Deux détails comptent plus que le schéma lui-même :

1. Un seul ASN possède le vocabulaire. Mélanger votre numérotation avec la table de communautés de chaque transit, c’est s’assurer des astreintes de 3 h du matin. On réécrit les communautés entrantes en bordure dans notre espace canonique, et seul l’espace canonique apparaît dans les route-maps.
2. La communauté blackhole est gardée. Elle n’est annoncée qu’aux upstreams qui la filtrent correctement, et elle est limitée en débit de notre côté. Une communauté qui supprime du trafic est assez puissante pour mériter la même revue qu’une règle de pare-feu.

Les checklists

Deux artefacts opérationnels sont nés d’incidents de production : une procédure de drain par service et par direction qui déplace le trafic avec les communautés BGP avant de toucher aux sessions, avec les compteurs de paquets attendus à chaque étape, et un cron « prove it » de sondes synthétiques depuis l’extérieur des deux sites qui alerte quand le chemin gagnant diverge du chemin attendu.

Après l’astreinte inévitable (une maintenance où les annonces d’un site étaient retirées une minute entière avant que celles de l’autre site ne soient acceptées, laissant une fenêtre de rien), deux artefacts ont émergé :

• Une procédure de drain : par service, par direction, les étapes pour déplacer le trafic avec les communautés avant de toucher aux sessions, avec les compteurs de paquets attendus à chaque étape.
• Un cron « prove it » : des sondes synthétiques depuis l’extérieur des deux sites qui alertent quand le chemin gagnant n’est pas celui prévu. Du steering sans observation, c’est juste de la latence avec de la confiance en plus.

Ce que nous ferions différemment

Démarrer en actif-actif dès le premier jour avec une préférence par communautés au lieu de primaire/secours. Les configurations de secours s’ossifient vite : le jour où vous en avez besoin, elles décrivent un réseau qui n’existe plus. Et traitez votre politique de communautés comme de la documentation exécutable : l’écrire fait partie de la livrer.

Annoncer depuis les deux sites dès le premier jour avec des prepends, au lieu de démarrer en primaire/secours et d’évoluer ensuite. Les configurations de secours s’ossifient : le jour où vous en avez besoin, elles décrivent un réseau qui n’existe plus. L’actif-actif avec préférence par communautés se dégrade plus gracieusement que l’actif-n’importe-quoi.

Si vous ne devez retenir qu’une chose : votre politique de communautés n’est pas de la configuration, c’est de la documentation qui s’exécute. Traitez sa rédaction comme une partie de sa livraison.