Un modèle pour planifier, un autre pour exécuter : ma méthode avec l'IA

Quand je travaille avec des agents IA, je ne confie pas une demande entière à un seul modèle. Je la scinde en deux temps : un modèle performant conçoit le plan, un modèle plus économique l'exécute. Entre les sessions, un simple fichier CHANGELOG.md leur sert de mémoire commune.

Le raisonnement coûte cher, l'exécution beaucoup moins. Autant ne payer le premier qu'une seule fois.

Planifier avec un modèle performant

Le plus exigeant dans une tâche n'est pas d'écrire le code, c'est de comprendre : lire l'existant, repérer les dépendances, anticiper les effets de bord, choisir une approche. C'est là qu'un modèle haut de gamme fait la différence. Je lui demande un plan précis : les fichiers concernés, les étapes dans l'ordre, ce qui ne doit pas bouger et la manière de vérifier que le travail est terminé.

Exécuter avec un modèle plus économique

Une fois le plan validé, l'exécution devient une tâche cadrée : appliquer des étapes claires dans des fichiers identifiés. Un modèle plus rapide et nettement moins cher s'en charge très bien. Comme l'essentiel du volume d'une session se situe généralement dans l'exécution, c'est là que l'économie se fait sentir, sans rogner sur la qualité de la réflexion.

Cette répartition a ses règles. Le plan doit se suffire à lui-même, car le second modèle ne refera pas le raisonnement du premier. Si le code contredit le plan, l'exécutant doit s'arrêter et le signaler plutôt qu'improviser. Et pour une correction de deux lignes, scinder ne sert à rien : la préparation coûterait plus que le gain.

Un CHANGELOG.md comme mémoire de travail

Un modèle démarre chaque session sans souvenir de la précédente. Sans repère, il relit le projet, devine ce qui a déjà été fait et refait parfois un travail existant. C'est pourquoi je tiens un fichier CHANGELOG.md à la racine du projet, où chaque tâche terminée est consignée.

• Les entrées les plus récentes en haut : en lisant les premières lignes, le modèle connaît immédiatement le contexte dans lequel il évolue.
• Pour chaque tâche : la date, ce qui a été fait et pourquoi, les fichiers touchés et les points restés en suspens.
• Des entrées courtes, et les plus anciennes archivées : un journal trop long consommerait le contexte qu'il est censé économiser.

L'historique Git dit ce qui a changé ; le journal dit pourquoi, et ce qui reste à faire. Une consigne dans les instructions du projet boucle la boucle : lire les dernières entrées avant de commencer, en ajouter une à la fin. Le planificateur comme l'exécutant partent alors du même contexte.

Ce que j'en retire

Ces deux habitudes reposent sur la même idée : l'IA donne le meilleur d'elle-même quand quelqu'un pose le cadre. Je décide de la répartition, j'écris les règles, je valide le plan et je relis le résultat. Les modèles exécutent, chacun à sa place.