Pourquoi nous plafonnons les variations mensuelles de valorisation — et ce que ce compromis nous coûte

La valorisation de chaque joueur est recalculée intégralement chaque mois à partir des statistiques du mois, de l'âge, du contexte de championnat et de quelques autres signaux. Sans garde-fou, ce processus peut occasionnellement produire un chiffre qui varie bien plus qu'un vrai changement de valeur marchande ne le justifierait — un trou de données, un artefact de transition de saison, ou simplement le modèle qui réagit trop fort à une courte séquence de matchs. Depuis le 24 août 2026, nous appliquons une règle finale stricte par-dessus tous les autres ajustements : aucun mois ne peut faire varier la valorisation d'un joueur de plus de 30 % par rapport au mois précédent, dans un sens comme dans l'autre. Le plafond était initialement fixé à 20 % et a été élargi à 30 % le 2 septembre 2026.

Ce plafond est volontairement un instrument grossier, et il a un vrai coût : il peut masquer un bug de calcul réel derrière un chiffre qui paraît simplement un peu suspect plutôt que manifestement cassé. C'est exactement ce qui s'est passé avec la valorisation de Harry Kane ce mois-ci. Un incident d'ingestion de statistiques pendant la transition de saison d'août a corrompu le point de départ sur lequel se base notre comparaison mensuelle — son chiffre d'août s'est retrouvé figé à environ le double de ce qu'il aurait dû être. Notre cycle de recalcul quotidien, fonctionnant correctement et respectant le plafond, a passé le reste du mois à ramener sa valorisation en temps réel vers le bon chiffre. Mais le point de départ corrompu était lui-même un champ distinct, figé, que le plafond n'a jamais été conçu pour vérifier — si bien qu'au moment où le snapshot de septembre s'est figé, la comparaison mois par mois montrait une baisse d'environ 50 % pour Kane, un chiffre qui ressemblait à une vraie histoire mais résultait en réalité de deux bugs cumulés : l'un venant de la corruption de données initiale, l'autre d'un angle mort de surveillance qui a laissé le problème passer inaperçu pendant plus d'une semaine.

Nous avons depuis corrigé les deux : le snapshot de départ corrompu est en cours de correction, et nous avons ajouté une vérification automatique d'intégrité qui détecte désormais précisément ce type d'incohérence — une valeur figée qui dérive hors du plafond par rapport au chiffre en temps réel du mois précédent — dès la prochaine exécution du calcul mensuel, plutôt que d'attendre qu'une personne remarque un chiffre invraisemblable à l'œil nu. Le plafond lui-même reste en place, car l'alternative est pire : qu'une variation mensuelle non bornée atteigne un vrai utilisateur à cause d'un autre problème de données non détecté est un risque plus grand que de masquer occasionnellement un bug pendant quelques semaines. Nous préférons être transparents sur ce compromis plutôt que de prétendre que le modèle est exempt de bugs.