Idée principale

Convertir un JSON en CSV, renuméroter un index, recopier un frontmatter, trier une liste : ces opérations ont un résultat unique, déductible de leurs entrées. Confiées au modèle, elles sortent par le canal le plus cher — celui de la génération — et rapportent en plus une variabilité dont personne n'avait besoin. Confiées à un script, elles coûtent zéro token et s'exécutent en millisecondes.

Sur competitor_analyze, deux étapes déplacées vers Python — l'écriture des frontmatter et le calcul du delta de l'index — ont retiré 111 000 unités de la consommation, sans rien changer aux livrables produits.

Le critère de partage n'est pas la difficulté de la tâche mais la présence d'un jugement : si le résultat se déduit des entrées, il n'y a rien à faire décider.

Pourquoi c'est important

Cela donne une règle de découpe pour la conception d'un skill : chaque étape se demande ce qu'elle attend du modèle, et une étape qui n'attend aucun arbitrage n'a pas à lui être adressée.

Le gain n'est d'ailleurs pas seulement économique : ce qu'un script produit est reproductible, ce qu'un modèle produit ne l'est qu'approximativement.

Nuances et limites

Écrire et maintenir le script a un coût, invisible dans un rapport de tokens. Pour une transformation ponctuelle qui ne sera jamais rejouée, passer par le modèle reste moins cher que par le développement.

Et certaines transformations paraissent déterministes jusqu'à la première donnée mal formée — le modèle absorbe l'irrégularité là où le script s'arrête.

Questions ouvertes

• Où placer la frontière quand une transformation est mécanique à quatre-vingt-dix pour cent et ambiguë pour le reste ?