Idée principale

La règle de décision tient en trois lignes : gros gain et faible complexité, on fait maintenant ; gain moyen et complexité moyenne, on planifie ; petit gain, on ignore.

Sa fragilité est dans la seconde colonne. Le gain se mesure sur la consommation ; l'effort, lui, est estimé depuis le skill, comme si le code d'accueil était propre et modulaire. Une optimisation classée « faible » — passer une synthèse en mode incrémental, par exemple — peut demander de tracer ce qui a déjà été intégré à travers un code ancien que personne ne veut rouvrir. C'est cet écart qui décale le classement, et il justifie de majorer d'emblée les estimations d'effort.

Pourquoi c'est important

Cela empêche de lire un rapport d'audit comme une liste de tâches : il propose un ordre de grandeur de gains, pas un plan.

Et cela remet la décision là où sont les informations qui manquent au rapport — auprès de ceux qui connaissent la base de code.

Nuances et limites

Certaines optimisations à faible gain immédiat changent la trajectoire : passer en incrémental rapporte peu aujourd'hui et de plus en plus à mesure que les données s'accumulent. Un classement instantané les sous-estime systématiquement.

Questions ouvertes

• Comment valoriser une optimisation dont le gain croît avec le volume des données plutôt que de rester constant ?