← Blog

Les invites sont des cibles de refactorisation : journaliser un flux de travail IA pour trouver quoi automatiser

IA/LLM Ingénierie Flux de travail

La démarche à laquelle je me fie le plus dans mon propre travail est celle-ci : prendre quelque chose que l'expérience signale comme perfectible, puis prouver le pourquoi et le comment avec des données réelles — plutôt que d'agir sur l'intuition. L'intuition vous dit où regarder ; les données vous disent si vous aviez raison et quoi en faire. Ce qui a changé récemment, c'est qu'un LLM peut faire le « regarder », à une échelle qui rendait autrefois ce genre de preuve trop coûteux pour qu'on s'en soucie.

Je me suis appuyé exactement là-dessus chez Google. Au sein de l'équipe Legal Content Policy and Standards, en tant que Policy Lead, j'avais une intuition sur les types de demandes de retrait juridique qui engorgeaient l'arriéré et ceux qui étaient assez routiniers pour être automatisés. Plutôt que de le défendre à partir de l'expérience, j'ai fait classer et résumer les cas à grande échelle par un LLM — des milliers d'entre eux — jusqu'à ce que les données confirment l'hypothèse ou la corrigent. Dans Privacy Sandbox, en tant que TPM, c'était la même forme : une intuition sur les documents partant en relecture juridique qui méritaient réellement un examen plus approfondi, transformée en un pipeline où un LLM relisait et classait chacun d'eux, pour que la coûteuse attention humaine se pose là où elle comptait. Dans les deux cas, l'intuition était le point de départ, pas le verdict. Le LLM a rendu le verdict abordable.

Alors un récent article d'ingénierie de LayerX (par Maeda Yōhei (前田洋平), un responsable d'ingénierie de l'équipe application mobile du produit de gestion financière Bakuraku de LayerX, qui écrit sous le nom de id:myohei11) a retenu mon attention, parce qu'il applique cette démarche à une cible que je n'avais pas pensé à viser : le flux de travail IA lui-même. Les ingénieurs qui travaillent toute la journée avec un agent de codage tapent sans cesse les mêmes choses — « commit, push, ouvre une PR », « traite les commentaires de relecture », « répare le CI en échec ». Ça semble répétitif, mais une impression est une base fragile pour décider quoi automatiser. Alors ils journalisent chaque invite envoyée à l'agent, analysent le journal à intervalles réguliers, et laissent les schémas qui reviennent vraiment dire quoi construire. La formule qui m'est restée, c'est que les invites deviennent des cibles de refactorisation : les instructions à une IA, comme du code, sont quelque chose à observer, mesurer et remodeler en pièces réutilisables — et dire la même chose une douzaine de fois est de la duplication, ce qui constitue une odeur de code précisément parce que cela marque une unité qui mérite d'être extraite.

Comment ça fonctionne

Les rouages sont délibérément modestes. Un hook UserPromptSubmit ajoute chaque invite à un prompts.jsonl local — une ligne JSON avec un horodatage, un identifiant de session et le texte — en écartant les entrées trivialement courtes et en gardant le fichier lisible par son seul propriétaire. Les journaux sont masqués, conservés localement, et supprimés au bout de sept jours. (Ce dernier point n'est pas une arrière-pensée : un journal d'invites est un enregistrement de tout ce que vous avez demandé, donc les garde-fous de confidentialité sont porteurs, pas facultatifs.)

Deux chemins de détection tournent au-dessus du journal. L'un fonctionne à l'intérieur d'une session en direct, remarquant en temps réel quand la même opération se représente. L'autre est une tâche planifiée quotidienne qui lit la semaine écoulée d'invites et les regroupe par intention. Faire tourner les deux attrape plus que l'un ou l'autre seul : le chemin temps réel voit les rafales au sein d'une conversation, le chemin par lot voit la même requête éparpillée sur plusieurs jours. Quand un schéma franchit un seuil bas — trois occurrences ou plus — il poste sur Slack, avec le résumé du schéma et une invite toute prête pour construire le Skill ou la commande correspondante en pièce jointe.

Deux choix de conception en font plus qu'un gadget de journalisation. D'abord, l'analyse quotidienne utilise un LLM pour regrouper les invites sémantiquement plutôt que de faire du clustering d'embeddings — de sorte que « fais une PR », « commit, push, et ouvre une PR », et « commit le correctif et remonte une PR » se rassemblent tous en un seul schéma, parce qu'ils partagent une intention indépendamment de la formulation. C'est exactement le regroupement flou, chargé de jugement, que les modèles de langage font bien et que les métriques de similarité rigides font mal — la même raison pour laquelle le LLM, et non un filtre par mots-clés, était le bon outil pour trier ces dossiers juridiques. Ensuite, l'automatisation s'arrête à la proposition. Elle ne crée ni ne supprime jamais un Skill d'elle-même ; un humain approuve chacun. Cela empêche le système de faire proliférer en silence un fourré de règles à moitié utiles — le mode de défaillance qui fait de la plupart des automatisations « auto-améliorantes » un fardeau.

Le retournement intéressant : l'IA améliorant notre façon de travailler avec l'IA

Ce qui fait de cela plus qu'une astucieuse manœuvre de rangement, c'est ce vers quoi cela pointe. Le même journal qui fait ressortir de nouvelles automatisations fait aussi ressortir celles qui sont cassées : si les gens continuent d'invoquer un Skill existant puis d'y accoler aussitôt d'autres instructions — « mets aussi à jour la page Notion », « poste aussi sur Slack », « tu n'as pas fini » — ce bavardage résiduel est la preuve que le Skill est sous-spécifié, avec des critères d'achèvement flous ou une étape manquante. Le système se retourne donc sur lui-même, et un volant d'inertie apparaît : une meilleure instrumentation fait ressortir de meilleures automatisations, qui affûtent le système même qui trouve la suivante.

Ce volant d'inertie est pourquoi je pense que la cible compte plus que l'astuce. Le codage agentique devient le modèle de travail par défaut de l'ingénierie logicielle — ce qui fait de « comment une personne et un agent interagissent réellement » une surface d'amélioration nouvelle, et largement non mesurée. La plupart des équipes y avancent à l'aveugle. Les résultats rapportés ici sont délibérément peu spectaculaires — 29 schémas répartis sur 691 occurrences, 22 d'entre eux (76 %) convertis en Skills ou commandes, 652 invites répétées éliminées ; le seul cycle commit-push-PR est apparu 94 fois avant de devenir une unique commande /ship — et c'est bien là le propos. C'est le labeur ennuyeux et à haute fréquence qui reste invisible tant qu'on ne le compte pas, et le compter est désormais bon marché.

La fréquence est le signal ; l'effet de levier est le critère

Deux réserves me gardent honnête à ce sujet. La première, c'est que la fréquence n'est pas l'importance. Ce n'est pas parce qu'une chose arrive souvent qu'elle vaut la peine d'être abstraite — il y a peu de valeur réelle à épargner à un ingénieur la saisie de quelques mots. La valeur, c'est quand tout un processus devient automatisé, reproductible et extensible ; le décompte vous dit seulement où chercher cela, pas que vous l'avez trouvé. La seconde, c'est le coût : un journal d'invites est une donnée qu'il faut désormais gouverner, les invites ne capturent qu'une tranche d'un flux de travail, et un empilement de Skills marginaux peut encombrer l'environnement jusqu'à ce que l'agent ne puisse plus dire lequel s'applique. Rien de tout cela n'est fatal, mais c'est une dette technique bien réelle, et c'est la raison pour laquelle le point de validation humaine n'est pas facultatif.

Le jugement, autrement dit, reste là où il doit être — et le plus grand gain n'est aucun flux de travail automatisé en particulier. C'est d'améliorer l'efficacité de l'interaction humain–IA elle-même, parce que c'est désormais ce qui se trouve sur le chemin critique de presque tout développement. Accélérez cela et vous accélérez tout ce qui en découle en aval. L'intuition que quelque chose est répétitif n'est encore qu'une intuition ; ce qui est nouveau, c'est que le prouver, et agir en conséquence, est passé d'un projet de recherche à une habitude quotidienne. Je vais commencer à journaliser les miennes.

esc