Penser en morceaux

Le guide du voyageur galactique de l’économie en K : compétence 3, la décomposition

Il y a un paradoxe caché au cœur des outils les plus puissants que nous ayons jamais construits. Plus un agent d’IA devient capable, plus il a besoin que nous pensions petit.

Pas petit au sens de sans ambition. Petit au sens de spécifique. Borné. Assez concret pour qu’un système qui n’a aucune intuition de ce que vous vouliez dire puisse exécuter sans deviner. Nous avons des outils capables de travailler de façon autonome pendant des heures, voire des jours. Opus 4.6, Gemini 3.1 Pro, GPT 5.3 Codex : ils acceptent une tâche le matin et livrent un travail fini le soir. Le hic, c’est qu’ils feront exactement cela, que la tâche ait été bien définie ou non. Ils ne s’arrêtent pas pour vous dire que la consigne était floue. Ils construisent simplement quelque chose, avec assurance et jusqu’au bout, et vous laissent découvrir le désalignement après coup.

La différence entre quelqu’un qui utilise bien ces outils et quelqu’un qui les utilise mal tient rarement à l’intelligence, à l’expérience ou même à la compétence technique. C’est quelque chose de plus discret : la capacité de fragmenter une grande ambition en morceaux assez petits pour être portés.

C’est la décomposition. Et c’est peut-être la compétence la plus sous-estimée de l’économie actuelle.

Le tout n’est pas plus grand. Il est ingérable.

Des chercheurs qui étudient les grands modèles de langage ont découvert quelque chose qui devrait changer notre façon de travailler à tous. Quand on donne un problème à un modèle et qu’on lui demande de le décomposer en étapes avant de le résoudre, en déployant le raisonnement en un arbre de sous-problèmes, il surpasse nettement le même modèle qui tente de résoudre le problème d’un bloc. La technique s’appelle le tree-of-thought prompting, et les résultats ne sont pas marginaux. Ils sont substantiels.

Ce constat rejoint ce que les meilleurs gestionnaires de projet et architectes ont toujours su : un plan n’est pas une seule grande intention. C’est une séquence de petits engagements vérifiables. Si la plupart des projets ambitieux s’enlisent, ce n’est pas que l’ambition soit mauvaise. C’est que personne n’a traduit l’ambition en morceaux qui peuvent réellement être exécutés, vérifiés et corrigés indépendamment.

Ce qui a changé, c’est le coût de l’erreur. Quand l’exécution était lente et coûteuse, une mauvaise décomposition signifiait des retards et du gaspillage. Quand l’exécution est rapide et autonome, une mauvaise décomposition signifie un agent qui fonce à pleine vitesse dans la mauvaise direction pendant six heures, produisant un monument cohérent et bien structuré à la gloire d’une exigence mal comprise. La boucle de rétroaction n’est plus lente. Elle est absente.

À quoi ressemble vraiment la décomposition

Cette compétence est plus facile à reconnaître en pratique qu’à décrire en théorie. Voici la différence.

Une directive vague ressemble à ceci : « Construis un système d’intégration des clients qui se connecte à nos outils existants et gère élégamment les cas limites. » Cette phrase contient au moins six décisions, quatre ambiguïtés et zéro frontière. Confiée à un agent autonome, elle produira quelque chose. Ce quelque chose reflétera l’interprétation que l’agent se fait de « élégamment », sa supposition quant aux outils existants et sa propre définition des cas limites. Vous passerez plus de temps à comprendre ce qu’il a construit qu’il n’en a passé à le construire.

La même ambition, décomposée, sonne autrement. D’abord : définir le modèle de données d’une nouvelle fiche client, incluant ces cinq champs, contraints à ces types. Ensuite : écrire un point d’accès API qui crée une fiche client et retourne une confirmation, avec validation du format de courriel et détection des doublons. Puis : bâtir une intégration webhook avec le CRM, déclenchée à la création réussie, avec une logique de réessai en cas d’échec. Chaque morceau est assez spécifique pour qu’un agent puisse l’exécuter indépendamment, et chaque morceau est assez petit pour que vous puissiez vérifier le résultat en minutes plutôt qu’en heures.

Le travail n’est pas devenu plus simple. Il est devenu plus clair. C’est tout l’enjeu.

Vertical, pas horizontal

Il y a un piège précis dans lequel tombent même les équipes expérimentées. Les agents d’IA produisent naturellement des plans horizontaux : tout le travail de base de données d’abord, puis tous les services, puis tous les points d’accès API, puis tout le frontend. Douze cents lignes d’implémentation plus tard, rien n’est testable, rien n’est intégré, et la première fonctionnalité visible par l’utilisateur reste théorique.

Les équipes de HumanLayer ont tout essayé pour enrayer ce schéma. Différents modèles, différents prompts, des évaluations poussées. Les modèles continuaient de produire des plans horizontaux malgré tout. Le correctif n’était pas un meilleur prompting. C’était une meilleure décomposition par l’humain : imposer des tranches verticales. Simuler le point d’accès API d’abord, le faire fonctionner dans le frontend, puis brancher le vrai service derrière, puis faire la migration. Même portée, mais avec des points de contrôle où l’on peut vérifier la justesse en cours de route.

C’est la différence entre un plan logiquement organisé et un plan opérationnellement utile. Les modèles excellent au premier. Les humains doivent fournir le second.

Ce n’est pas une compétence de programmation

C’est ici que la conversation tend à se rétrécir, et elle ne le devrait pas. La décomposition n’est pas une affaire de génie logiciel. C’est une discipline de pensée qui s’applique à tout domaine où des agents d’IA font le travail.

Une gestionnaire de produit qui décompose une feuille de route trimestrielle en tâches de recherche exécutables par des agents pratique cette compétence. Un directeur marketing qui découpe le lancement d’une campagne en briefs de contenu distincts, chacun avec son public et ses critères de succès, la pratique aussi. Une fondatrice qui traduit la vision de son entreprise en une série d’expériences bornées, chacune testable en une semaine, la pratique également.

La compétence est la même partout : pouvons-nous prendre une grande intention et l’exprimer comme une séquence de morceaux bornés, vérifiables et exécutables indépendamment? Les outils ne se soucient pas de savoir si le domaine est le logiciel, le marketing, la stratégie ou la logistique. Ils se soucient de savoir si la tâche est claire.

L’écart de 10x, et pourquoi il se creuse

Nate B. Jones a récemment fait une observation qui mérite plus d’attention qu’elle n’en a reçu. Le prompting, que nous traitions comme une compétence unique, s’est discrètement scindé en au moins quatre capacités distinctes. La décomposition en est une. Et l’écart entre les personnes qui l’ont développée et celles qui ne l’ont pas fait est déjà d’un ordre de grandeur.

Ce n’est pas une hyperbole. Dans les équipes qui utilisent régulièrement des agents autonomes, ceux qui décomposent produisent systématiquement du travail qui est revu, approuvé et livré. Ceux qui ne décomposent pas produisent systématiquement du travail qui est revu, retravaillé et finalement réécrit (ou remis au même agent, cette fois avec un brief digne de ce nom). L’écart de temps approche le facteur dix, parce que le travail du décomposeur se compose : chaque morceau bien cadré s’appuie sur le résultat vérifié du précédent, tandis que celui qui ne décompose pas recommence perpétuellement à partir d’un tout raté.

L’écart se creuse parce que les outils s’améliorent en exécution, ce qui veut dire qu’ils amplifient de mieux en mieux tant la bonne décomposition que la mauvaise. Un agent plus capable, à qui l’on confie une tâche bien cadrée, produit un meilleur travail plus vite. Le même agent, à qui l’on confie un mandat vague, produit des absurdités plus impressionnantes plus vite. Le levier tranche dans les deux sens.

Apprendre à découper

La vérité rassurante, c’est que la décomposition s’apprend. Ce n’est pas un don. C’est une discipline, et comme la plupart des disciplines, elle s’améliore avec la pratique et quelques habitudes concrètes.

La première habitude est de résister à l’instinct de décrire le résultat avant de décrire les étapes. Quand nous confions une tâche à un agent, la tentation est de décrire le produit fini : « construis-moi un tableau de bord qui montre X, Y et Z ». La meilleure approche est de décrire la première étape seulement : « crée une source de données qui retourne X ». Puis vérifier. Puis passer à Y. L’ambition reste grande. Les instructions restent petites.

Une équipe l’a appris à la dure. Elle avait commencé avec un flux de travail en trois étapes (recherche, plan, implémentation) gouverné par un seul prompt de 85 instructions. La moitié de ses utilisateurs obtenaient de mauvais résultats. Elle a décomposé le processus lui-même en sept étapes plus petites, chacune avec moins de 40 instructions, chacune produisant un artefact qui alimente la suivante. Meilleure recherche, meilleurs plans, code nettement meilleur. Le processus avait besoin de la même décomposition que les tâches.

La deuxième habitude est de rendre chaque morceau vérifiable indépendamment. Si nous ne pouvons pas vérifier qu’un morceau a réussi sans voir le tout, le morceau est trop gros. Une bonne décomposition produit des morceaux qui ont leurs propres critères de succès, leurs propres frontières, leur propre définition du terminé. Une tâche bien découpée peut être évaluée isolément, et c’est ce qui rend l’ensemble fiable.

La troisième habitude, et peut-être la plus difficile à développer, est de séquencer selon les dépendances, pas selon l’importance. Nous voulons naturellement commencer par la partie la plus excitante, l’interface utilisateur, la grosse fonctionnalité, le résultat visible. Mais les agents, comme les fondations d’un bâtiment, ont besoin des morceaux les moins glorieux d’abord : le modèle de données avant l’API, l’API avant l’interface, l’interface avant le peaufinage. La séquence la moins satisfaisante à planifier est habituellement celle qui produit le résultat le plus fiable.

Aucune de ces habitudes n’exige de connaissances techniques. Elles exigent de la patience, de la précision et la volonté de réfléchir au travail avant de commencer le travail. Ce qui, en fin de compte, est la plus vieille forme de sagesse habillée de neuf.

La permission

Si vous confiez de grosses tâches à des agents d’IA et obtenez des résultats inégaux, vous ne vous y prenez pas mal. Vous faites ce que les outils vous invitent à faire : voir grand, agir vite. Les outils ont simplement omis de mentionner que voir grand et agir vite ne fonctionnent qu’après avoir pensé petit et agi en séquence.

La compétence, ce n’est pas de construire. C’est de découper. Et elle appartient à tout le monde : l’ingénieure, le responsable produit, la directrice, le fondateur, la personne qui porte une ambition claire et veut en faire quelque chose de réel. Les outils sont prêts à porter le poids. Il nous reste à le tailler en morceaux qu’ils peuvent tenir.

Ce texte fait partie du « Guide du voyageur galactique de l’économie en K ». Précédent : « L’écart du goût », sur le jugement. À venir : l’orchestration.