# Présence IX — Internet Exchange Points

> Catégorie : **Souveraineté réseau** · Slug : `presence-ix` · Source canonique : <https://www.hebergeurs-de-donnees-de-sante.fr/criteres/presence-ix/>

**Définition courte** : L'hébergeur est membre déclaré d'un ou plusieurs points d'échange Internet (France-IX, LyonIX, DE-CIX, LINX…) — signal de maturité d'opérateur.

## Statistiques sur les 404 hébergeurs HDS

- ✓ Vérifiés sur source publique : **0**
- ◆ Revendiqués sur source publique : **0**

## 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/](/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&nbsp;:

- **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](https://www.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**&nbsp;:

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/](/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&nbsp;: si l'acteur n'opère pas son propre AS BGP (cf. [/criteres/as-bgp-propre/](/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

| Profil | Niveau d'exigence |
|---|---|
| Téléchirurgie, robotique chirurgicale | **Important** — latence < 10 ms exigée |
| Téléconsultation HD (CHU multi-sites) | **Important** — qualité d'expérience |
| Imagerie radiologique partagée (PACS) | **Important** — débit + latence |
| Hôpital local avec connectivité unique | **Différenciant** — résilience |
| EHPAD avec dispositifs IoT standards | **Non critique** |
| Médecine de ville | **Non critique** |

## Comment un hébergeur peut s'inscrire en IX

Procédure simplifiée&nbsp;:

1. **Opérer un AS BGP propre** (cf. [/criteres/as-bgp-propre/](/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&nbsp;: 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&nbsp;: 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&nbsp;: [peeringdb.com](https://www.peeringdb.com/).
- **France-IX** — [france-ix.net](https://www.france-ix.net/).
- **LyonIX** — [lyonix.net](https://www.lyonix.net/).
- **Euro-IX** — Fédération des IX européens, statistiques agrégées&nbsp;: [euro-ix.net](https://www.euro-ix.net/).
- **RIPE NCC** — Documentation peering et IX&nbsp;: [ripe.net/manage-ips-and-asns/asn](https://www.ripe.net/).

## Limites connues

PeeringDB est un registre **déclaratif**&nbsp;: 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.

## Hébergeurs satisfaisant ce critère

_Aucun hébergeur n'est marqué comme satisfaisant ce critère sur les sources publiques consultées._
## Méthodologie et limites

- ✓ **Vérifié** = source publique citée (registre officiel, verbatim site acteur).
- ◆ **Revendiqué** = mention déclarative non vérifiée indépendamment.
- ◐ **En cours** = démarche datée publiquement.
- — **Non documenté** = information non trouvée. **N'implique pas l'absence du service**.
- Méthodologie complète : <https://www.hebergeurs-de-donnees-de-sante.fr/verification/>
- Équité Guardis vs concurrents : <https://www.hebergeurs-de-donnees-de-sante.fr/equite-methodologique/>

---

_Comparateur édité par Hasgard SARL. Publication éditoriale indépendante. Licence CC BY-SA 4.0._
_Variante Markdown brut : ajoutez `.md` à l'URL de n'importe quelle page._