Idée principale

Le seul signal reçu est le blocage. Il arrive des heures après la dépense qui l'a causé, et il ne distingue pas le skill lancé trois fois de celui lancé une seule. Rien d'autre ne se manifeste : pas d'erreur, pas de lenteur, pas de message — un skill qui gaspille produit exactement le même résultat qu'un skill sobre.

La répartition n'existe donc pas d'elle-même : il faut la construire, étape par étape, en attribuant à chacune une part du total. Tant que cette vue n'a pas été fabriquée, la seule réaction disponible face au plafond est d'attendre, ou de travailler moins.

Pourquoi c'est important

Cela distingue un problème de consommation d'un défaut ordinaire : il ne se signale pas par un dysfonctionnement mais par une capacité de travail qui se réduit.

Et cela explique pourquoi le sujet est repoussé si longtemps — il n'y a aucun moment où il se présente comme un incident à traiter.

Nuances et limites

Connaître la répartition ne désigne pas toujours une cible : si trois skills se partagent la dépense à parts égales, la vue construite ne dit rien de plus que le blocage.

Et cette vue reste une reconstitution, pas un relevé : ce qu'elle attribue à une étape est estimé.

Questions ouvertes

• Quel signal, avant le blocage, dirait qu'une exécution vient de coûter dix fois ce qu'elle aurait dû ?