Idée principale

Rien ne change dans le skill et sa dépense augmente quand même. La base passe de 88 à 138 analyses, et toutes les phases qui la relisent coûtent davantage. Le fichier d'instructions grossit de moitié au fil des ajustements, et ce supplément est acquitté à chaque appel.

Sur competitor_analyze, deux optimisations implémentées ont retiré 186 000 unités, et la croissance des données en a repris 71 000 dans le même temps. Un coût audité est donc daté : c'est une mesure prise sur un scénario, à un moment, pas une propriété du skill. D'où les trois moments où l'audit se rejoue — au déploiement, quand le plafond est atteint plus vite qu'avant, et périodiquement sur le skill le plus lourd.

Pourquoi c'est important

Cela empêche de tenir une optimisation pour acquise : un gain réalisé peut être absorbé sans que personne ne le remarque, et le skill redevient le premier suspect quelques mois plus tard.

Cela fait aussi de l'audit une opération répétée plutôt qu'un chantier ponctuel.

Nuances et limites

La dérive n'est pas toujours subie : un skill qui coûte plus parce qu'il traite plus n'a pas régressé. Ce qui se dégrade est le coût par unité de travail utile, et le total ne le montre pas.

Questions ouvertes

• Quel indicateur ramené à l'unité de travail permettrait de distinguer une dérive d'une simple montée en charge ?