Latence IA à La Réunion :
réseau ou hébergement ?

Oui, un délai de réponse existe pour un assistant IA utilisé depuis La Réunion quand l’outil est hébergé en métropole, en Europe continentale ou aux États-Unis. Ce délai vient du trajet réseau, pas d’un défaut de l’outil : la distance, le nombre de câbles sous-marins traversés et le nombre d’intermédiaires réseau s’additionnent avant même que le modèle commence à répondre.

La Réunion n’est pas un cas comme un autre : selon le fournisseur d’accès local ZEOP (base de connaissances, consultée le 20 septembre 2026), la distance vers un serveur situé en Europe dépasse 10 000 km, ce qui place un plancher théorique autour de 180 ms de latence, avant tout traitement côté serveur. ZEOP publie des ordres de grandeur théoriques par zone : environ 45 ms vers l’Afrique du Sud, 115 ms vers l’Asie, 200 ms vers l’Europe continentale.

Ce trajet ne passe pas par des satellites mais par des câbles sous-marins. Trois liaisons desservent aujourd’hui l’île : SAFE (2002, moins de 1 Tbit/s, en fin de vie, démantèlement prévu à partir de 2027), LION et LION 2 (depuis 2009, 1,2 Tbit/s, vers Madagascar puis Mayotte et le Kenya) et METISS (depuis 2018, 24 Tbit/s), qui transporte aujourd’hui l’essentiel du trafic entrant et sortant de l’île. Un nouveau câble, ReuNION, a été annoncé le 2 septembre 2026 : il reliera la côte ouest de l’île à Durban (Afrique du Sud) avec 16 paires de fibre d’environ 20 Tbit/s chacune, pour un investissement de 93,1 millions d’euros, dont plus de 50 millions de fonds européens (Feder et Connecting Europe Facility).

Un délai de quelques centaines de millisecondes ne se vit pas de la même façon selon l’usage. Un assistant conversationnel affiché en direct pendant qu’un client attend une réponse rend chaque milliseconde perceptible. Une automatisation qui trie, classe ou route un message en arrière-plan, sans personne devant un écran à cet instant, absorbe le même délai sans que quiconque le remarque.

La distinction utile n’est donc pas « rapide » contre « lent », mais « gênant » contre « bloquant ». Un délai gênant ralentit une interaction en direct sans empêcher le travail. Un délai bloquant empêche une décision d’être prise dans la fenêtre de temps où elle a de la valeur (un système de contrôle en temps réel, par exemple, hors du champ des usages professionnels courants).

Une partie de ces mesures se joue avant même d’atteindre le modèle. Cloudflare, qui héberge la fiche Jev et sert de porte d’entrée à de nombreux outils IA, liste officiellement « Saint-Denis, RE » parmi les villes de son réseau mondial (cloudflare.com/network/, consulté le 20 septembre 2026). Un point de présence sur l’île réduit la partie du trajet qui s’arrête à la périphérie du réseau (mise en cache, filtrage, première réception de la requête), mais le calcul du modèle lui-même continue de s’exécuter là où tourne le matériel de calcul, pas nécessairement à La Réunion.

Le relevé public de la démo askjev.ai (19 septembre 2026, 172 appels observés) illustre cette distinction : les temps qu’il rapporte (117 ms au minimum, 188 ms de médiane, 622 ms au maximum) sont mesurés côté serveur de la démonstration, entre la requête et la réponse de Jev. Ils n’incluent pas le trajet depuis un poste réunionnais jusqu’à ce serveur : c’est exactement la part que le réseau local ajoute par-dessus, et qui varie selon la connexion.

Aucun de ces leviers ne supprime la distance physique. Chacun agit sur une part différente du délai perçu, et se combine avec les autres plutôt que de s’y substituer.

1. Privilégier une connexion filaire à un poste de travail sensible à la latence : le Wi-Fi ajoute une variabilité que le câble n’a pas, avant même de sortir de l’île.
2. Vérifier si l’outil IA passe par un point de présence ou une tarification qui inclut déjà un relais proche (Cloudflare AI Gateway, par exemple, ne facture aucun surcoût de passerelle au-delà du tarif du fournisseur du modèle).
3. Choisir une architecture d’automatisation tolérante à l’attente pour les tâches qui n’ont pas besoin d’un résultat instantané : un traitement en arrière-plan absorbe un délai de quelques centaines de millisecondes sans qu’aucun client ne le perçoive.
4. Réserver l’exigence de vitesse maximale aux usages réellement en direct devant un client, et accepter un délai plus large pour tout le reste.

Les leviers précédents sont à la portée de l’utilisateur. Ceux-ci relèvent de la personne qui construit l’outil : prestataire, développeur ou équipe technique. Ils ne suppriment pas non plus la distance, mais ils réduisent le nombre de fois où la requête la parcourt et le temps pendant lequel l’utilisateur attend sans rien voir.

Chaque levier se vérifie avec la méthode de mesure de la section suivante, avant et après le changement : un réglage qui ne se voit pas dans les mesures n’a pas besoin d’être conservé.

Cette méthode ne mesure pas un modèle d’IA en particulier : elle mesure la part réseau, celle qui dépend de votre connexion et de votre position à La Réunion, indépendamment de l’outil choisi ensuite. Elle se rejoue depuis n’importe quel poste, sans installation.

1. Répétez la mesure vingt fois, à des heures différentes de la journée : la latence réseau varie avec la charge du réseau, pas seulement avec la distance.
2. Notez le temps de connexion (`time_connect`) séparément du temps total : le premier est la part réseau, le second inclut le traitement côté serveur.
3. Comparez une cible filaire et une cible en Wi-Fi depuis le même lieu pour isoler la part qui vous appartient de celle qui ne dépend pas de vous.
4. Refaites la même série depuis une deuxième connexion, par exemple le partage de connexion mobile d’un téléphone : si l’écart est net, une partie du délai vient de votre accès, pas de l’outil IA.

# Remplacez la cible par le point de présence ou l'API à mesurer
for i in $(seq 1 20); do
  curl -o /dev/null -s -w "essai $i : connect=%{time_connect}s tls=%{time_appconnect}s total=%{time_total}s\n" \
    https://votre-cible.example.com/
  sleep 1
done

Un dirigeant qui perçoit un délai avec un assistant IA a raison de le remarquer : la distance qui sépare La Réunion des principaux points d’hébergement mondiaux est réelle et mesurable. Elle ne rend pas pour autant un projet d’automatisation irréaliste. Les modèles conçus pour des décisions répétitives, comme celui pris en exemple plus haut, répondent déjà en centaines de millisecondes selon leur éditeur et selon deux vérifications indépendantes publiées la même semaine : la plupart des automatisations métier, tri de messages, comptes rendus, chatbots de premier niveau, tolèrent cet ordre de grandeur sans que le client final s’en aperçoive.

La bonne question n’est donc pas « la latence va-t-elle bloquer mon projet ? », mais « quelle part de mon usage se joue vraiment en direct, devant un client, et laquelle peut attendre quelques centaines de millisecondes sans que personne ne le sache ? ». C’est cette question qui oriente le choix d’architecture, pas la distance seule.

Les mesures de DodoIA depuis un réseau réunionnais viendront compléter ce dossier avec des temps de bout en bout mesurés sur ses propres cibles : l’outil de mesure, partagé avec La Refonte, est déjà déployé.

Le guide d’implémentation de référence sur Cloudflare Workers AI

Chatbot entreprise : comment il s’adapte à ce délai