Le mode plan est peut-être la meilleure commande pour développer avec une IA

Demander à un agent de coder tout de suite, c’est tentant. En quelques minutes, il peut créer un service, modifier un contrôleur, toucher aux templates et ajouter des tests. On voit du mouvement, parfois même une démo. Mais on ne sait pas encore si l’agent a bien compris le besoin.

Une demande incomplète ne l’arrête pas forcément. Elle lui laisse des zones à interpréter. L’agent les remplit avec des hypothèses, puis les transforme en code. C’est là que le problème commence : le résultat peut être propre, bien rangé et pourtant répondre à la mauvaise question.

Le premier jet est devenu très facile à produire

Les agents ont réduit le coût du premier jet. Ils savent explorer un dépôt, repérer les fichiers concernés et proposer une implémentation en peu de temps. Ce gain est réel. Il déplace simplement le risque.

Le problème n’est plus seulement de réussir à produire le code. C’est de décider quoi produire, où le placer et quelles contraintes respecter. Une demande comme « ajoute la gestion de X » laisse souvent plusieurs questions sans réponse : que se passe-t-il dans les cas limites ? Quelles données sont disponibles à cet endroit du système ? Quelles versions faut-il prendre en charge ? Faut-il rendre le comportement configurable ? Comment le désinstaller ou revenir en arrière ?

Quand ces réponses manquent, l’agent ne peut pas deviner le contexte métier. Il choisit une interprétation plausible et avance. Plus il avance, plus cette interprétation s’installe dans l’architecture.

Le code qui en résulte n’est pas nécessairement mauvais. Il peut même être très cohérent. Il repose simplement sur une décision que personne n’a encore validée.

Ce que on demande pendant le mode plan

Pour moi, le mode plan n’est pas une formalité avant le « vrai » travail. On demande à l’agent de ne pas modifier le code pendant cette phase. D’abord, il reformule le besoin. Ensuite, il inspecte l’existant, sépare ce qu’il a vérifié de ce qu’il suppose et relève les informations qui manquent.

On lui demande aussi de montrer les choix qui auront un impact sur la suite : fichiers ou services concernés, compatibilité, dépendances, données manipulées, risques et façons de vérifier le résultat. S’il existe plusieurs approches raisonnables, il doit les présenter avec leurs compromis.

Les questions à choix multiples aident à faire émerger les décisions qu’on n’avait pas encore formulées. Faut-il privilégier la compatibilité avec l’existant, la simplicité, la performance ou l’évolution future ? Quel comportement doit rester non négociable ? L’agent peut éclairer ces choix, mais c’est à nous de décider.

Le but n’est pas d’obtenir un document de plus. C’est de pouvoir relire le raisonnement, contester une hypothèse et corriger la direction avant qu’elle ne soit déjà répartie dans plusieurs fichiers.

Un hook PrestaShop peut engager toute l’implémentation

Prenons un cas concret : ajouter une fonctionnalité à un module PrestaShop. Le choix du hook peut sembler n’être qu’un détail technique. En pratique, il détermine quand le code s’exécute, dans quel contexte, avec quelles données et selon les versions ciblées. Il peut aussi avoir des conséquences sur le thème, le cache, les interactions avec d’autres modules et les performances.

Si l’agent choisit le hook avant d’avoir vérifié ces contraintes, il peut bâtir toute la fonctionnalité autour du mauvais point d’entrée. On s’en rend compte plus tard : les données utiles ne sont pas disponibles à cet endroit, le comportement diffère selon la version de PrestaShop ou l’intégration au thème ne correspond pas au besoin.

À ce stade, on ne change pas forcément une seule méthode. Il faut peut-être déplacer la logique, revoir un service, adapter un template et reprendre les tests. Il faut aussi vérifier l’installation et la désinstallation du module : un hook enregistré ou une configuration devenue inutile peut rester en place après le changement.

Un plan utile fait donc vérifier le point d’entrée avant l’implémentation : le hook existe-t-il dans les versions visées ? Fournit-il le contexte nécessaire ? Est-ce bien le bon endroit pour porter cette responsabilité ? Ces questions sont rapides à traiter avant de coder. Elles coûtent davantage une fois que plusieurs composants dépendent de la réponse.

Les corrections successives ne remplacent pas le cadrage

Une fois le code commencé, on peut toujours demander : « déplace cette logique », « ajoute cette règle » ou « garde la compatibilité avec ce cas ». Ces échanges font partie du développement. Le problème, c’est quand ils servent à compenser une décision de départ qui n’a jamais été examinée.

L’agent peut corriger le fichier qu’on lui montre et adapter ce qui l’entoure. Cela ne garantit pas qu’il va repérer tout ce qui doit disparaître, être déplacé ou être retesté. Une suite de retouches localement raisonnables peut rendre l’ensemble plus difficile à comprendre.

Quand les corrections s’accumulent, il faut parfois arrêter d’ajouter des consignes et revenir à la question de départ : est-ce encore la bonne structure ? Qu’est-ce qui doit être supprimé ou repris proprement ?

Éviter l’AI bloat

J’appelle AI bloat l’accumulation de code plausible, mais dont le besoin n’a jamais été démontré : une abstraction créée trop tôt, une dépendance supplémentaire, une option de configuration qui ne sert à rien, ou un service ajouté parce qu’il semblait utile à l’agent.

Ce code n’est pas toujours mauvais. C’est même souvent du code raisonnable, et c’est ce qui le rend facile à laisser passer. Pourtant, chaque fichier et chaque mécanisme ajouté devra être compris, testé et maintenu.

Le plan aide à poser la question avant la création : pourquoi cette responsabilité doit-elle exister ? Pourquoi cette dépendance est-elle nécessaire ? Pourquoi faut-il cette configuration ou ce mécanisme de cache ? Si la réponse reste vague, mieux vaut clarifier le besoin avant d’ajouter la solution.

Le but n’est pas de compter les lignes ni de refuser toute abstraction. C’est de ne pas confondre une solution complète avec une solution utile.

Un plan validé sert aussi à vérifier le résultat

Un plan relu et validé donne un point de comparaison pendant la revue. On peut vérifier que l’implémentation respecte le besoin, les contraintes de compatibilité et les décisions prises au départ. On ne s’arrête pas à « ça compile » ou « la démo fonctionne ».

Il aide aussi à définir les tests. Si le plan a identifié les cas limites, les versions concernées et les critères d’acceptation, ces éléments peuvent guider la validation. Sans cette référence, on teste souvent surtout le scénario heureux qui a servi à construire la fonctionnalité.

Plus les agents produisent vite, plus il faut savoir ce qu’on cherche à vérifier. La vitesse du premier jet ne dispense pas de comprendre ce qui a été ajouté ni pourquoi.

Avant l’exécution, il faut une direction

Le mode plan ne remplace ni l’expérience ni la responsabilité du développeur. L’agent peut aider à examiner le besoin et à rendre les choix visibles ; c’est toujours à nous de décider si les hypothèses tiennent et si le plan mérite d’être exécuté.

Ma règle est simple : avant de laisser l’agent modifier le code, on veux comprendre le besoin qu’il a retenu, les contraintes qu’il a vérifiées, celles qu’il suppose et la manière dont on validera le résultat. Si un point important reste flou, le code attend.

Le premier prompt d’une fonctionnalité n’a donc pas toujours besoin de demander une implémentation. Il peut commencer par demander à l’agent de réfléchir, d’inspecter et de challenger la direction. Une fois le plan validé, reste à encadrer son exécution et à vérifier ce qu’il produit. Mais sans direction claire, les meilleurs contrôles ne feront que détecter plus tard une erreur qu’on aurait pu éviter au départ.