Idée principale

Deux manières de demander la même chose à un assistant comme Claude Code : lui faire trier les fichiers d'un répertoire directement dans son contexte, ou lui faire écrire le script Python qui les trie. Le résultat visible est identique — les fichiers sont triés. Ce qui reste derrière ne l'est pas.

Dans le premier cas, l'opération n'existe nulle part : on ne peut ni la relire, ni savoir ce qui a été fait sur le cinquantième fichier, ni la rejouer le mois suivant sans redemander. Dans le second, l'assistant produit un objet inspectable — la règle de tri est écrite, elle se lit en deux minutes, elle se corrige, elle se relance sur d'autres fichiers, et elle donne le même résultat à chaque exécution.

Le déplacement porte sur ce que l'on délègue. On ne délègue plus l'exécution, on délègue l'écriture de la règle d'exécution — et c'est cette règle, pas son résultat, qui devient l'objet à vérifier.

Pourquoi c'est important

Cela donne un critère pour choisir la forme d'une délégation, avant de choisir le modèle ou le prompt : dès qu'une opération doit se répéter, porter sur un volume qu'on ne relira pas, ou être justifiée plus tard, la bonne sortie est le script, pas le résultat.

Cela explique aussi pourquoi ce type de délégation restait confortable : le périmètre était borné, la sortie était courte, et la vérification tenait dans la relecture d'une fonction. Le passage à un produit complet — des écrans, des API internes, des modifications de données — fait sauter cette propriété sans que rien n'annonce le changement de régime.

Nuances et limites

La règle ne vaut que pour les opérations déterministes. Un tri par extension s'écrit en script ; un classement qui demande de juger le contenu de chaque fichier ne s'écrit pas, et forcer le script revient à figer un mauvais critère.

Et le script déplace la vérification sans la supprimer : un script juste sur l'échantillon de test peut se tromper sur le reste, exactement comme l'exécution directe.

Questions ouvertes

• À partir de quel volume de code généré la sortie cesse-t-elle d'être inspectable, et que faut-il alors produire à la place du script pour garder la même propriété de vérification ?