Désynchronisation
La désynchronisation se produit lorsque la vision locale d'un match par un joueur ne correspond plus à l'état faisant foi du serveur. Le joueur voit un adversaire à un certain endroit alors que le serveur le situe ailleurs, ce qui fait que les tirs manquent leur cible, les personnages se téléportent et les positions se replacent brusquement. Il s'agit d'un problème de divergence plutôt que de vitesse, ce qui le distingue du décalage (lag).
Aussi appelé
désynchronisation
,
Quels sont les deux types de désynchronisation ?
Les joueurs utilisent un même mot pour deux défaillances différentes, et les solutions ne se recoupent pas. Deux articles présentés à la GDC 2001 décrivent encore ces deux aspects : le travail sur la compensation de latence de Yahn Bernier chez Valve, et l'article 1500 Archers on a 28.8 sur le lockstep de Paul Bettner et Mark Terrano chez Ensemble Studios.
La désynchronisation de réplication se produit dans les jeux disposant d'un serveur faisant autorité. Le client prédit ce qui va se passer, le serveur n'est pas d'accord, et le client est corrigé. Les joueurs voient un personnage se téléporter en arrière ou un tir traverser quelqu'un.
La désynchronisation de déterminisme se produit dans les jeux en lockstep, où chaque machine exécute la même simulation et seules les entrées (inputs) sont envoyées. Les machines comparent les sommes de contrôle (checksums) de leur état, et lorsque les chiffres ne correspondent plus, il n'y a pas de copie faisant autorité vers laquelle se tourner. La session s'arrête.
Le second type possède son propre message d'erreur. « Une désynchronisation s'est produite » est la phrase exacte que les joueurs recherchent, souvent pour des jeux populaires comme Madden NFL 26 ou College Football 26.
Savoir de quel type souffre votre jeu constitue la majeure partie du travail.
En pratique - Aperçus du blog de Edgegap
Points clés de l'article
La désynchronisation est un désaccord, pas un retard : Le lag signifie que l'information arrive tardivement. La désynchronisation signifie que deux machines détiennent des versions différentes du même monde, ce qui est une défaillance distincte avec des corrections distinctes.
Il en existe deux types distincts : La désynchronisation de réplication, où un serveur faisant autorité corrige un client qui a mal deviné, et la désynchronisation de déterminisme, où les simulations des pairs divergent et la session s'arrête carrément.
L'effet d'élastique (rubberbanding) a deux leviers : La fréquence à laquelle le client fait de mauvaises prédictions, qui dépend de la latence, et la visibilité de chaque correction, qui dépend du netcode. Modifiez l'un ou l'autre de ces leviers et les joueurs le verront moins.
Le tick rate (taux de rafraîchissement) n'est aucun de ces leviers : L'augmenter ne rend pas les prédictions plus précises, et sur une connexion qui perd déjà des paquets, cela aggrave les artefacts.
« Une désynchronisation s'est produite » est un échec de checksum (somme de contrôle) : Les jeux en lockstep comparent les hachages d'état à chaque tour, donc un seul flottant divergent ou un seul appel aléatoire non synchronisé met fin à la session.
Pourquoi le rubberbanding (effet d'élastique) se produit-il ?
L'effet élastique (rubberbanding) est une correction à l'écran d'une désynchronisation de réplication. Il résulte du produit de deux facteurs : la fréquence à laquelle le client fait une mauvaise prédiction, et la visibilité de chaque mauvaise prédiction.
Le premier facteur est déterminé par la latence. Chaque milliseconde séparant le client du serveur est un temps que le client passe à simuler sur la base de ses propres prédictions. À un taux de simulation de 60 Hz, un client situé à 30 ms de son serveur tourne avec environ deux images d'avance sur la confirmation. À 180 ms, il en a environ onze d'avance. Même code, même moteur, environ cinq fois plus d'exposition. La gigue (jitter) et la perte de paquets aggravent la situation, car un signal d'entrée perdu signifie que le serveur progresse sans tenir compte de l'action du joueur.
Le second facteur est déterminé par le netcode. Le rollback rembobine jusqu'à la dernière image confirmée lorsque le serveur n'est pas d'accord, la resimulation rejoue les entrées du joueur à partir de là, et le lissage de l'affichage estompe ce qui reste sur quelques images au lieu d'effectuer une téléportation. Lorsque cela est bien fait, la plupart des corrections sont si proches de l'endroit où le joueur se trouvait déjà que personne ne s'en rend compte.
Aucun de ces deux leviers ne remplace l'autre. Un bon netcode à 200 ms produit toujours des corrections visibles. Une route courte sur un jeu sans prédiction donne toujours une impression de manque de réactivité.
Pourquoi un taux de rafraîchissement plus élevé ne résout-il pas la désynchronisation ?
Les studios à la recherche d'une solution d'infrastructure se tournent généralement d'abord vers le tick rate. Ce n'est pas le bon levier.
Le tick rate définit la fréquence à laquelle le serveur résout et diffuse l'état du monde. L'augmenter permet d'obtenir un timing plus précis pour l'enregistrement des touches (hit registration). Cela n'améliore en rien la précision de la prédiction, car cette dernière dépend du code de simulation et des entrées parvenues au serveur, et non de la fréquence à laquelle le serveur communique. Sur une connexion qui subit déjà des pertes de paquets, un taux plus élevé signifie davantage de paquets à perdre, et des corrections qui arrivent plus fréquemment.
Le levier d'infrastructure qui permet de réduire la désynchronisation est la latence. Un serveur placé plus près des joueurs d'une partie réduit l'ampleur du problème que le code réseau (netcode) doit résoudre, sans nécessiter le déploiement d'un correctif. Le guide explicatif sur la désynchronisation d'Edgegap détaille le fonctionnement de ces deux leviers.
Un serveur peut-il empêcher la désynchronisation ?
Un serveur dédié modifie ces deux aspects, pour des raisons différentes.
Pour la désynchronisation de réplication, c'est la voie de secours. Lorsqu'un client dérive trop, le serveur peut cesser d'envoyer des deltas (l'approche habituelle consistant à transmettre uniquement ce qui a changé) et pousser à la place l'état complet. La copie divergente du client est écrasée. Cela consomme de la bande passante, c'est pourquoi cela reste l'exception, mais cela transforme une session interrompue en un simple contretemps temporaire.
Pour la désynchronisation de déterminisme, cela modifie l'architecture. Les sessions en mode "Lockstep" se terminent en cas d'incohérence car aucune machine n'a la légitimité de l'emporter sur les autres. Avec un serveur faisant autorité au milieu, il y a par construction une source de vérité unique.
Ce qu'un serveur ne fait pas, c'est réduire de lui-même la distance avec les joueurs, ou rendre la prédiction inutile. Il vous donne un état que vous possédez, que vous pouvez instrumenter et que vous pouvez corriger.
Un mot de notre sponsor (nous-mêmes !)
La majeure partie du lag provient de la distance, non du code. L'Edge Cloud d'Edgegap est un réseau distribué disposant de plus de 615 emplacements disponibles sur demande, garantissant que chaque partie se déroule au meilleur endroit possible pour ses joueurs. Des tests indépendants sur le trafic d'un studio en direct ont mesuré une baisse de 58 % du temps de trajet aller-retour moyen par rapport au cloud public.
Quand la désynchronisation devient-elle de la triche ?
Parfois, le joueur qui signale une désynchronisation est celui qui en est à l'origine, et les jeux en peer-to-peer sont les plus exposés. Lorsqu'une machine d'un joueur héberge la partie, il n'y a pas de tiers neutre pour confirmer les actions de chacun, comme le décrit le guide d'Edgegap sur les coûts cachés du P2P. Les joueurs cherchent également comment déclencher volontairement une désynchronisation, et sur certaines plateformes, ce terme désigne un exploit.
En octobre 2025, le développeur Roblox loleris a signalé une faille de « désynchronisation » se propageant dans les jeux sur le forum des développeurs Roblox. La position de l'auteur de l'exploit parvenait toujours au serveur mais cessait de se répliquer chez les autres joueurs, de sorte que « le serveur vous voit dans l'arène, mais tous les autres clients vous voient quelque part très loin ». L'équipe de Roblox l'a reproduite et a déployé un correctif.
La leçon concerne l'emplacement de l'autorité. Un serveur dans la boucle n'est utile que s'il est celui qui décide du résultat. Tout ce qu'un client est autorisé à signaler de manière fiable, de sa propre position au résultat d'un match, est susceptible d'être falsifié par ce dernier.
Cela ne nécessite pas un serveur lourd. Bloody Bastards, un jeu mobile avec plus de 40 millions de téléchargements (Tibith Ltd, 2026), fonctionnait en peer-to-peer, l'hôte étant garant des résultats des matchs. L'étude de cas décrit une triche rampante, ainsi que des problèmes de désynchronisation liés à cette configuration. Tibith est passé à de petits serveurs faisant autorité et sans interface graphique sur Edgegap, et ne signale plus aucune triche réussie depuis la version 5.0.0. Pour un jeu qui n'aurait pas besoin d'un serveur dédié complet, un arbitre peut être conçu sur quelque chose d'aussi léger que LightNet d'Edgegap, une bibliothèque réseau Unity de bas niveau, bien que les règles de l'arbitre restent à la charge du développeur.
L'avis d'Edgegap (ce n'est que notre opinion, à prendre avec des pincettes !)
L'avis d'Edgegap
Lorsqu'un joueur signale une désynchronisation (desync), ce mot ne vous apprend pas grand-chose. C'est le symptôme qui vous indique à qui revient la correction.
Une session qui s'arrête avec le message « une désynchronisation s'est produite » est un bug de simulation. Aucun serveur, région ou taux de rafraîchissement (tick rate) ne peut le corriger, car les deux machines ont effectué des calculs différents.
Un personnage qui se téléporte en arrière (rubberbanding) est un écart de prédiction. Une latence plus faible le réduit, et une meilleure réconciliation le rend moins visible.
Un joueur invisible ou impossible à toucher est un écart d'autorité. Une information pour laquelle le client a reçu de la confiance aurait dû être décidée sur un serveur.
Triez les signalements par symptôme avant d'attribuer le travail, et chacun parviendra à l'équipe qui est réellement en mesure de le corriger.
,
