« Le mode plan est mort » : un fondateur tire les leçons de l'échec de son outil de planification IA

Début 2026, le développeur Ayman Nadeem était persuadé que la planification deviendrait l'étape la plus importante pour construire des logiciels avec l'intelligence artificielle. Sa conviction était assez forte pour lancer une application de bureau entière autour de cette idée, Nuanced. Dans un billet publié le 24 septembre, cet ancien ingénieur senior de GitHub reconnaît que l'approche a échoué, et explique pourquoi.

Le point de départ : aller plus vite que sa propre compréhension

Le constat initial reste, selon lui, pertinent : les modèles écrivent désormais des milliers de lignes de code en quelques minutes, plus vite que ne peut suivre un humain. Il décrit l'expérience de se retrouver avec un produit avant d'avoir pris la moindre décision de produit, avec des choix d'architecture comblés à sa place par l'agent et des malentendus qui se propagent dans plusieurs fichiers sans que l'on s'en aperçoive. Avec plusieurs agents lancés en parallèle, il dit s'être senti déconnecté, presque « zombie », et moins capable de vérifier que les résultats étaient corrects.

L'idée : donner un domicile au plan

Les modes de planification existants lui paraissaient insuffisants : les plans se perdaient dans l'historique de la conversation, et il passait son temps à copier des morceaux de texte d'un message à l'autre pour les corriger. Nuanced devait en faire un document vivant et durable. Chaque discussion faisait remonter les ambiguïtés et les décisions à trancher, aboutissait à un plan persistant, puis passait à la réalisation, à la relecture et à la vérification du code.

Quatre raisons de l'échec

• Planifier n'est pas disposer d'un plan. Réfléchir avant de construire reste utile, mais les premiers utilisateurs avaient étonnamment peu d'appétit pour de longues spécifications.
• Les modèles se sont nettement améliorés. Ils explorent mieux un projet et font des hypothèses raisonnables : chaque décision qu'ils prennent seuls est une question de moins à poser à l'humain.
• Le texte généré par IA est pénible à lire. Les spécifications étaient longues, très structurées, et l'auteur dit avoir fini par les survoler. La « visite guidée » ajoutée pour y remédier n'a fait qu'ajouter du texte.
• Le découpage était artificiel. Le parcours « discussion, questions, spécification, relecture, validation, réalisation, relecture du code » obligeait à « finir de penser » trop tôt, alors que comprendre un problème se fait en essayant.

Comprendre, agir, inspecter, ajuster

Pour Ayman Nadeem, le schéma « planifier, valider, exécuter » date d'une époque où se tromper de direction coûtait cher. Les agents actuels comprennent mieux les systèmes, agissent seuls, testent leur travail et corrigent leur approche. La boucle devient : comprendre, agir, inspecter, clarifier, ajuster, puis agir à nouveau. La planification n'a pas disparu, elle se fait à l'intérieur de cette boucle, sans forcément prendre la forme d'un document intitulé « le plan ». Sa principale erreur, écrit-il, a été de transformer le plan en objet plutôt que de concevoir un processus qui aide les humains à comprendre. Il juge aussi que devoir décider soi-même quand passer en mode plan ajoute une charge mentale inutile : la simplicité d'une conversation où l'on planifie au besoin était finalement très bien.

Un problème qui reste entier

L'auteur ne considère pas que le besoin disparaît. Réfléchir à ce que l'on construit, à ce qui le justifie et évaluer les décisions reste essentiel, mais une grande quantité de texte généré n'est pas la bonne interface pour cela. Le défi grandit lorsque l'on passe de cinq agents à des centaines : suivre ne peut plus consister à lire chaque conversation. Les agents devraient repérer les rares endroits où l'attention humaine compte le plus et fournir assez de contexte pour qu'elle serve à quelque chose. Les interfaces changent avec la technologie, conclut-il, mais le besoin de rendre la complexité compréhensible demeure.

À lire avec recul

Il s'agit du retour d'expérience d'un fondateur sur son propre produit, et non d'une étude : ses conclusions valent pour son outil et ses usages, pas nécessairement pour toutes les équipes ni tous les types de projets. Elles rejoignent néanmoins un débat plus large sur la manière de garder la maîtrise d'un travail confié à des machines.

À lire aussi dans notre réseau :

• Pourquoi l'intelligence artificielle pourrait fragiliser la méthode scientifique elle-même
• « Je suis désormais plus inquiet » : pourquoi certains experts durcissent le ton sur le risque lié à l'IA