Votre serveur Minecraft lag et vous voyez passer un fameux “Can’t keep up!” dans la console ? Pas de panique : avant d’optimiser, il faut comprendre deux notions clés qui pilotent tout le gameplay côté serveur : les ticks et le main thread (le “fil principal”).

Dans ce guide (version 2026), on va voir comment Minecraft découpe le temps, pourquoi tout n’est pas parallélisable, et comment les TPS chutent dès qu’un tick dépasse la limite. L’objectif : vous donner une lecture simple de ce qui se passe “sous le capot”, pour diagnostiquer plus vite les vraies causes de lag.

Comprendre les ticks sur un serveur Minecraft

Minecraft fonctionne comme beaucoup de jeux : une grande boucle qui se répète en continu. Chaque tour de boucle s’appelle un tick, et c’est pendant ces ticks que le serveur calcule tout ce qui se passe en jeu.

À chaque tick, le serveur traite notamment :

• Traiter les paquets joueurs (mouvements, blocs, attaques)

• Mettre à jour positions joueurs et entités

• Envoyer les mises à jour aux joueurs (blocs, entités, événements)

• Gérer le spawn, l’IA et le pathfinding des mobs

• Calculer la redstone

• Et bien d’autres systèmes du jeu

Pour aller plus loin sur la définition, vous pouvez consulter la page dédiée : Tick de jeu (Minecraft Wiki).

📝 Note : Un serveur vise 20 ticks par seconde, soit 1 tick toutes les 50 ms. C’est la “cadence” normale d’un serveur fluide.

Le main thread : pourquoi tout ne va pas plus vite

La plupart des actions de gameplay sur Minecraft sont mono-thread : elles sont calculées principalement sur le main thread. En clair, une grosse partie du travail passe par un seul “fil” d’exécution, donc un seul cœur CPU à un instant donné.

Exemple simple : pour qu’un zombie attaque un joueur, le serveur doit enchaîner des vérifications (positions, distance, chemin, états, visibilité, etc.). Tant que ces calculs ne sont pas terminés, le tick ne peut pas “valider” l’action suivante.

💬 Bon à savoir : C’est pour ça qu’un CPU avec de bonnes performances par cœur (single-core) aide énormément sur un serveur Minecraft, surtout avec beaucoup d’entités et de redstone.

Quand votre serveur fonctionne correctement

Quand tout va bien, le serveur termine chaque tick en moins de 50 ms. S’il finit plus tôt, il “attend” simplement le prochain tick pour garder une cadence stable.

Exemple : si un tick est calculé en 15 ms, le serveur a encore 35 ms de marge avant le tick suivant. Résultat : gameplay fluide, interactions instantanées, et TPS stables.

Quand votre serveur lag (et ce que ça implique)

Si un tick prend plus de 50 ms, le tick suivant est retardé, car les ticks ne s’exécutent pas en parallèle. À partir de là, tout le gameplay se dégrade : mobs qui “téléportent”, blocs qui se cassent en retard, redstone au ralenti, etc.

Vous verrez souvent le message “Can’t keep up!” lorsque le serveur accuse plus de 2000 ms de retard dans le traitement des ticks. Et si le serveur reste bloqué trop longtemps (souvent plus de 60 secondes), le watchdog peut le considérer comme “crash” et arrêter le processus.

⚠️ Attention : Un serveur peut “tourner” mais être injouable si le main thread est saturé. Les joueurs ressentent le lag avant même un crash.

Pourquoi les ticks dépassent 50 ms

La cause la plus fréquente, c’est une charge trop lourde à traiter sur le main thread : trop d’entités, trop d’IA, trop de redstone, ou des mécaniques qui multiplient les interactions. Et comme tout doit être recalculé 20 fois par seconde, ça grimpe très vite.

Imaginez 500 zombies : à chaque tick, le serveur doit recalculer leur comportement, leurs déplacements, leurs collisions, et leurs cibles. Ajoutez à ça des fermes à mobs, des chunks chargés en permanence, ou des zones ultra-denses, et la boucle n’arrive plus à tenir le rythme.

Cas classique : 50 poulets enfermés dans un espace minuscule (2x2). Chaque poulet entre en collision avec les autres, ce qui génère énormément d’interactions à calculer en continu. Même si “ça a l’air petit”, côté serveur c’est une usine à ticks trop longs.

💡 Astuce : Si votre lag arrive surtout quand des joueurs sont dans une zone précise, suspectez en priorité une ferme, une redstone intensive, ou une densité d’entités anormale.

TPS : lire la santé du serveur en un chiffre

Les TPS (Ticks Par Seconde) indiquent combien de ticks le serveur arrive réellement à produire chaque seconde. À 20 TPS, tout est au rythme normal. Dès que le serveur prend du retard, les TPS baissent, et le jeu ralentit côté serveur.

Une formule simple permet d’illustrer l’impact du retard :

(1000 - retard en ms) / 50 = TPS

Exemple : si votre serveur accumule 250 ms de retard sur une seconde, vous obtenez (1000 - 250) / 50 = 15 TPS. En pratique, 15 TPS se ressent déjà très clairement en jeu.

Identifier la cause avec une analyse Spark

Pour savoir précisément ce qui consomme du temps sur le main thread, le plus efficace est de faire un profil de performance. Dans la plupart des cas, une analyse avec Spark suffit à repérer le plugin, la zone, ou le type d’activité responsable.

Vous pouvez suivre le tutoriel officiel MineStrator ici : analyser les lags de votre serveur avec Spark.

Conclusion

Les ticks sont le rythme de votre serveur, et le main thread est la route principale que la majorité des calculs doit emprunter. Dès qu’un tick dépasse 50 ms, vos TPS chutent et le lag s’installe, souvent à cause d’entités, d’IA ou de redstone trop coûteuses.

Vous voulez un diagnostic rapide et propre ? Lancez une analyse Spark, puis si besoin, passez par la FAQ MineStrator ou contactez le support via notre page de contact pour régler ça ensemble.