Présence IX — Internet Exchange Points

Définition

Un point d'échange Internet (Internet Exchange Point — IX ou IXP) est une infrastructure physique neutre où plusieurs systèmes autonomes (cf. /criteres/as-bgp-propre/) interconnectent leurs réseaux pour échanger du trafic — le plus souvent gratuitement (peering settlement-free) ou contre une cotisation modique. Les IX évitent que tout le trafic Internet remonte systématiquement vers des opérateurs de transit Tier-1 internationaux (Cogent, Lumen, Telia, NTT) avec les coûts et la latence associés.

En France et dans la zone francophone, les IX significatifs sont notamment :

• France-IX Paris — le plus important IX français, plus de 600 membres, présent dans 8 datacenters parisiens (Interxion, Equinix, TelecityGroup, etc.). Trafic agrégé > 5 Tbps en pic.
• France-IX Marseille — extension méditerranéenne, hub câbles sous-marins (SeaMeWe, AAE-1, IMEWE).
• LyonIX — IX de la métropole lyonnaise, géré par CCI Lyon Métropole, ~80 membres.
• TouIX — Toulouse.
• LillIX — Lille.
• SFINX — IX historique opéré par Renater, focus académique/recherche.
• FranSIX — IX historique non commercial, hébergé chez Iliad-Free.
• MIX (Milan), DE-CIX (Frankfurt), AMS-IX (Amsterdam), LINX (London) — IX européens majeurs où certains acteurs français sont aussi présents.

La présence en IX d'un acteur est déclarée volontairement dans PeeringDB (peeringdb.com), registre coopératif des politiques de peering. C'est la source de référence pour vérifier la présence IX réelle d'un opérateur.

Pourquoi c'est important pour un hébergeur HDS

La présence d'un hébergeur dans un ou plusieurs IX est un indicateur opérationnel et stratégique :

1. Latence réduite pour les clients locaux. Si l'hôpital client est à Lyon et que l'hébergeur HDS peere à LyonIX avec le FAI de l'hôpital, le trafic ne fait pas un détour par Paris ou Francfort. Latence < 5 ms vs 20-30 ms via un transit.
2. Indépendance vis-à-vis des Tier-1. Les IX réduisent la dépendance aux gros opérateurs de transit, dont la plupart sont sous juridiction américaine (Lumen ex-CenturyLink, Cogent) ou suédoise (Telia). Plus un hébergeur est peeré localement, moins ses flux dépendent de routages transitant par des pays tiers.
3. Résilience. En cas d'incident sur un transitaire, le peering direct via IX continue de fonctionner. Le multi-homing IX + transit est l'architecture standard des opérateurs matures.
4. Coût. Le trafic peeré gratuitement (settlement-free) sur IX ne consomme pas de quota de transit payant.
5. Signal de maturité. Un hébergeur sans aucune présence IX déclarée à PeeringDB est probablement un acteur qui s'appuie entièrement sur un opérateur tiers pour sa connectivité — c'est tenable mais limitant.

Pour les cas santé où la latence importe (téléchirurgie, télémédecine HD, imagerie temps réel), une présence IX dans la région du client est un atout direct.

Comment ce critère est attribué dans le comparateur

• ✓ Vérifié — l'acteur est listé dans PeeringDB avec présence sur au moins un IX, et son ASN propre est confirmé (cf. /criteres/as-bgp-propre/).
• ◆ Revendiqué — mention « présence IX » ou « peering direct » sur le site officiel sans entrée PeeringDB correspondante.
• — Non documenté — pas de mention, pas de présence PeeringDB attribuable.

À noter : si l'acteur n'opère pas son propre AS BGP (cf. /criteres/as-bgp-propre/), la question de la présence IX se pose au niveau de son fournisseur de transit, pas au sien.

Pour quel profil c'est critique

Comment un hébergeur peut s'inscrire en IX

Procédure simplifiée :

1. Opérer un AS BGP propre (cf. /criteres/as-bgp-propre/) — prérequis.
2. Adhérer à l'IX cible — cotisation annuelle modique (1 à 10 k€/an selon IX et port utilisé).
3. Connecter un port dans le datacenter où l'IX est physiquement présent (Interxion, Equinix, Telehouse, DATA4, Free DC, etc.). Coûts datacenter en sus.
4. Configurer BGP — sessions avec le route server IX, peerings bilatéraux avec les autres membres qui ont une politique « open ».
5. Déclarer la présence à PeeringDB — pour rendre le peering détectable par les autres membres.

Délai typique d'installation : 4-12 semaines selon disponibilité du port datacenter et de l'équipement BGP.

Plus-value vs coût

Le ROI d'une présence IX dépend du volume de trafic local. Pour un hébergeur HDS qui sert principalement la France métropolitaine, le break-even est rapide : une présence à France-IX Paris (et idéalement Lyon, Marseille) ramène une part significative du trafic vers du peering gratuit et améliore mesurablement la latence vers les clients français.

Pour un hébergeur servant un marché purement régional (ex. CHU de la région X), une présence sur l'IX régional est très pertinente. Pour un hébergeur servant l'international, l'enjeu se déplace vers les IX européens (DE-CIX, AMS-IX, LINX).

Sources officielles

• PeeringDB — Registre coopératif des politiques de peering : peeringdb.com.
• France-IX — france-ix.net.
• LyonIX — lyonix.net.
• Euro-IX — Fédération des IX européens, statistiques agrégées : euro-ix.net.
• RIPE NCC — Documentation peering et IX : ripe.net/manage-ips-and-asns/asn.

Limites connues

PeeringDB est un registre déclaratif : les acteurs y inscrivent volontairement leurs présences. Un acteur peut donc être physiquement présent dans un IX sans avoir mis à jour PeeringDB, ou inversement (information périmée). Le critère reflète la donnée PeeringDB à la date de fetch, complétée par la vérification AS BGP.

Par ailleurs, le critère ne mesure pas la qualité du peering (volume de trafic peeré, nombre de sessions actives), seulement la présence formelle. Pour une évaluation fine sur un projet exigeant, demander à l'hébergeur le détail de ses peerings et de ses transitaires.