> For the complete documentation index, see [llms.txt](https://docs.ipcheck.ing/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ipcheck.ing/knowledge-base/fr/concepts/latency-jitter-packet-loss.md).

# Latence, gigue et perte de paquets

Votre test de vitesse indique 500 Mbps. Votre visioconférence s’interrompt quand même. Comment cela peut-il être vrai ?

Parce que la vitesse n’est qu’une dimension d’une connexion, et souvent pas celle qui compte. Trois autres chiffres expliquent généralement la différence.

## Les trois métriques en termes simples

Imaginez envoyer une lettre et attendre une réponse.

**Latence** est le temps que prend l’aller-retour. Vous envoyez, ils répondent, la réponse arrive. Mesurée en millisecondes (ms). C’est ce qu’indique un test de ping. Une faible latence signifie que la connexion paraît réactive.

**Gigue** est l’ampleur de la variation de ce temps aller-retour. Si les réponses reviennent en 20 ms, puis 22 ms, puis 21 ms, la livraison est fiable. Si elles reviennent en 20 ms, puis 90 ms, puis 15 ms, quelque chose est incohérent — même si la moyenne semble correcte. La gigue est l’ampleur de cette variation, elle aussi en millisecondes.

**Perte de paquets** ce sont des lettres qui n’arrivent jamais. Les données voyagent sous forme de petits éléments appelés paquets, et une fraction peut être perdue en route. Mesurée en pourcentage. Les éléments perdus sont généralement renvoyés, ce qui prend du temps ; pour l’audio et la vidéo en direct, il n’y a pas le temps de renvoyer, donc la coupure est tout simplement audible.

Et **la bande passante**, le chiffre mis en avant par un test de vitesse, c’est ce qui peut être transporté à la fois — la largeur de la route, pas la vitesse à laquelle une voiture la traverse.

| Métrique         | Question à laquelle elle répond                | Unité | Expérience gâchée                               |
| ---------------- | ---------------------------------------------- | ----- | ----------------------------------------------- |
| Latence          | Combien de temps avant d’obtenir une réponse ? | ms    | Tout semble lent ; jeux injouables              |
| Gigue            | À quel point le délai est-il constant ?        | ms    | Appels vocaux saccadés, robotiques              |
| Perte de paquets | Quelle quantité n’arrive jamais ?              | %     | Bégaiements, blocages, coupures                 |
| Bande passante   | Combien tient en même temps ?                  | Mbps  | Téléchargements lents ; vidéo de faible qualité |

## Pourquoi la latence n’est pas la vitesse

C’est l’idée la plus utile de cette page.

La bande passante et la latence sont indépendantes. Une liaison satellite peut offrir une énorme bande passante alors que chaque aller-retour prend une demi-seconde, parce que le signal voyage physiquement jusqu’à l’orbite puis revient. Une connexion domestique modeste vers un serveur proche peut avoir une très faible latence et une bande passante modeste.

La latence dépend surtout de **la distance et du nombre de sauts**, et non de ce que vous payez. La lumière dans la fibre parcourt environ 200 kilomètres par milliseconde, et chaque routeur, chaque réseau intermédiaire, chaque file d’attente ajoute un peu de délai. Un aller-retour à travers l’océan ne peut pas être plus rapide que la physique ne le permet, quel que soit le forfait acheté.

Donc, passer à un forfait plus rapide ne corrigera pas un jeu en retard sur un serveur distant. En revanche, cela fera finir plus vite les gros téléchargements. Ce sont deux problèmes différents.

## Ce qui compte comme bon

Méfiez-vous de tout ensemble unique de seuils, y compris ceux-ci. Ce qui est acceptable dépend fortement de ce que vous faites, de la distance de l’autre extrémité et de la technologie de connexion utilisée. Un aller-retour de 60 ms vers un serveur situé sur un autre continent est excellent ; les mêmes 60 ms vers un serveur dans votre propre ville suggèrent un problème. Les connexions mobiles et satellites fonctionnent dans des plages totalement différentes de celles de la fibre.

Avec cette réserve, voici des repères approximatifs pour une connexion fixe à domicile vers un serveur raisonnablement proche :

|                  | Bon              | Utilisable     | Problématique         |
| ---------------- | ---------------- | -------------- | --------------------- |
| Latence          | moins de \~30 ms | \~30–100 ms    | au-dessus de \~150 ms |
| Gigue            | moins de \~10 ms | \~10–30 ms     | au-dessus de \~30 ms  |
| Perte de paquets | 0%               | moins de \~1 % | au-dessus de \~2–3 %  |

Deux choses comptent plus que les chiffres exacts.

D’abord, **comparez-vous à vous-même**. Une connexion qui affiche normalement 18 ms et qui affiche aujourd’hui 90 ms a un problème, quel que soit ce qu’un tableau indique. Votre propre référence est le repère le plus utile que vous ayez.

Ensuite, **mesurez en charge**. Une latence mesurée sur une connexion inactive peut sembler excellente puis s’effondrer quand quelqu’un lance un envoi — un symptôme appelé bufferbloat, où des files d’attente trop importantes dans l’équipement réseau retardent tout ce qui se trouve derrière un gros transfert. Une latence mesurée pendant que la connexion est occupée est beaucoup plus proche de ce que vous vivez réellement.

## D’où vient réellement le délai

Un aller-retour n’est pas un seul délai mais plusieurs, additionnés.

* **Distance.** La partie inévitable. Les signaux voyagent à vitesse finie, et les trajets réels en fibre sont plus longs que la ligne droite sur une carte.
* **Sauts.** Chaque routeur sur le trajet prend un instant pour examiner et transmettre chaque paquet. Un trajet de trente sauts coûte plus qu’un trajet de huit.
* **Mise en file d’attente.** Lorsqu’une liaison est plus chargée qu’elle ne peut servir, les paquets attendent dans une file. C’est le principal facteur, et le plus variable, sur une connexion saturée, ainsi que la principale source de gigue.
* **Le dernier kilomètre.** La technologie qui relie votre bâtiment compte. La fibre ajoute très peu ; les anciennes technologies cuivre et câble ajoutent davantage ; le mobile et le satellite ajoutent nettement plus.
* **L’extrémité distante.** Le serveur lui-même a besoin de temps pour réfléchir avant de répondre. Une application lente peut ressembler exactement à un réseau lent.

Seule la première de ces causes est fixe. Tout le reste peut être amélioré — c’est pourquoi une connexion lente aujourd’hui peut aller bien demain sans que rien ne change de votre côté.

## Ce que chacun gâche

**Le jeu est détruit par la latence, puis par la perte de paquets.** Les jeux compétitifs exigent que votre saisie atteigne le serveur et que le résultat revienne avant que le moment ne passe. La bande passante est presque sans importance — les jeux envoient de très petites quantités de données. C’est pourquoi un joueur avec une connexion modeste mais proche du serveur bat un joueur avec une connexion très rapide mais éloignée. La perte de paquets se manifeste par des retours élastiques, où les éléments reviennent brusquement à leur position précédente.

**Les appels vocaux et vidéo sont détruits par la gigue, puis par la perte de paquets.** L’audio doit être diffusé à un rythme régulier. Les applications conservent un petit tampon pour absorber les variations, mais si les arrivées sont suffisamment irrégulières, le tampon se vide et vous obtenez la voix robotique et hachée bien connue. Les paquets perdus ne peuvent pas être renvoyés à temps, ils deviennent donc de brèves silences. Les appels nécessitent étonnamment peu de bande passante, ce qui explique pourquoi ils échouent sur des connexions qui affichent pourtant de bonnes vitesses. Voir [Qu’est-ce que WebRTC ?](/knowledge-base/fr/concepts/what-is-webrtc.md).

**La vidéo en streaming est détruite par la bande passante, et seulement légèrement gênée par la latence.** Un lecteur vidéo met en mémoire tampon plusieurs secondes d’avance, ce qui lui permet d’absorber facilement la gigue et une latence modérée. Ce qu’il ne peut pas absorber, c’est une bande passante insuffisante : il réduit la qualité, et si la situation empire, il s’arrête pour recharger le tampon. Quelques secondes de délai supplémentaire au démarrage sont un symptôme de latence ; une image qui se dégrade en cours de scène est un symptôme de bande passante.

**La navigation web ordinaire est surtout un problème de latence.** Une page charge des dizaines de ressources distinctes, chacune nécessitant une requête et une réponse. La latence est payée plusieurs fois, donc une connexion à forte latence paraît lente même quand la bande passante brute est abondante. Au-delà d’environ 50 Mbps, une bande passante supplémentaire change à peine la vitesse ressentie des pages.

## Idées reçues courantes

**« Plus de Mbps corrige le lag. »** Ce n’est pas le cas. Le lag, c’est la latence. La bande passante et la latence sont des propriétés distinctes du trajet.

**« Zéro perte de paquets est requis. »** Une perte occasionnelle est normale et invisible. C’est une perte constante au-delà d’un ou deux pour cent qui dégrade les choses — et une perte qui apparaît seulement à un saut dans un traceroute est souvent le routeur qui donne une priorité moindre à ses propres réponses, et non une vraie perte affectant votre trafic.

**« Un seul test me dit la qualité de ma connexion. »** Une mesure n’est qu’un instantané d’un moment donné sur un trajet donné. Répétez-la, à différents moments, vers différents endroits, avant de tirer une conclusion.

**« Un ping élevé vers un site signifie que ma connexion est mauvaise. »** Cela peut vouloir dire que ce site est loin, ou qu’un trajet est encombré. Tester plusieurs destinations permet de distinguer un problème local d’un problème de trajet.

{% hint style="info" %}
**Voyez-le vous-même sur MyIP**

L’outil [Test de vitesse](/knowledge-base/fr/network-tests/speed-test.md) indique plus que les débits de téléchargement et d’envoi : il affiche aussi la latence, la gigue et la latence mesurée *pendant que la connexion est chargée* — puis traduit tout cela en scores de qualité pour le streaming vidéo, le jeu et la visioconférence. Cette dernière ligne est l’essentiel de cette page en un seul coup d’œil.

Pour voir comment ces chiffres changent avec la distance, [Test de latence mondial](/knowledge-base/fr/network-tests/global-latency-test.md) envoie des pings à votre adresse depuis des sondes partout dans le monde. Et lorsqu’un trajet précis semble mauvais, [test MTR](/knowledge-base/fr/network-tests/mtr-test.md) décompose le chemin en sauts et indique la latence et la perte à chacun d’eux, afin que vous puissiez voir où les dégâts commencent.
{% endhint %}

## Concepts connexes

* [Qu'est-ce qu'un ASN ?](/knowledge-base/fr/concepts/what-is-an-asn.md) — pourquoi le trajet entre réseaux détermine votre latence
* [Qu’est-ce que WebRTC ?](/knowledge-base/fr/concepts/what-is-webrtc.md) — pourquoi les appels sont si sensibles à la gigue
* [Adresses publiques, privées et CGNAT](/knowledge-base/fr/concepts/public-private-cgnat.md) — des sauts supplémentaires entre vous et Internet
* [Pourquoi mon Internet est-il lent ?](/knowledge-base/fr/diagnose/why-is-my-internet-slow.md) — un diagnostic étape par étape


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.ipcheck.ing/knowledge-base/fr/concepts/latency-jitter-packet-loss.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.