L'Ingénierie des Agents IA : Pourquoi les bons principes surpassent la puissance brute
Dans le monde du développement piloté par l'IA, il y a une vérité pragmatique que l'on découvre vite en production : un modèle abordable doté d'excellentes instructions surpassera toujours un modèle onéreux livré à lui-même.
La puissance de calcul et l'entraînement des grands modèles génératifs (GenAI) coûtent des dizaines de millions de dollars 1. Pourtant, s'appuyer uniquement sur cette puissance brute est une erreur. J'ai constaté que lorsque l'on laisse un modèle "développer" ses propres compétences (skills) de manière autonome, les résultats sont souvent décevants. Le modèle a tendance à dériver, à reproduire des biais inhérents à ses données d'entraînement, ou à générer des solutions sous-optimales. Parfois, c'est le modèle qui est biaisé ; parfois, ce sont nos propres angles morts.
Le "Hack" de l'Architecte : L'asymétrie des modèles
Ma stratégie actuelle pour contourner ce problème est simple mais redoutablement efficace : j'utilise un modèle très puissant (et coûteux) pour concevoir et rédiger les instructions et les "skills", que j'injecte ensuite dans un modèle beaucoup plus abordable pour l'exécution.
Dans l'ère de l'IA générative, l'architecture du modèle est heureusement découplée de la structure de l'entrée grâce au "Prompt Engineering" 4. Le modèle onéreux agit comme l'Architecte, tandis que le modèle abordable devient l'Exécutant, guidé par un contexte riche et structuré.
L'importance vitale des frameworks de Workflow
Par défaut, je privilégie toujours l'utilisation de frameworks orientés "workflow" pour encadrer ces agents. Mes favoris actuels sont d'excellents exemples open-source (ressources externes) :
Superpowers (github.com/obra/superpowers)
Compound Engineering (github.com/EveryInc/compound)
Git. Ship. Done. (github.com/open-gsd/gsd-core)
Ce qui est fascinant avec ces outils modernes d'orchestration d'agents, c'est qu'ils partagent tous les mêmes principes. Et le plus beau dans tout ça ? Derrière l'évolution rapide de ces technologies d'IA, on retrouve les principes d'ingénierie intemporels qui restent vrais depuis des décennies 5. La philosophie UNIX des années 70, qui prônait de construire des programmes qui font une seule chose mais la font bien, résonne de manière frappante avec les pratiques agiles et DevOps d'aujourd'hui.
Qu'il s'agisse d'un humain ou d'un agent IA, un système ne fonctionne que s'il respecte ces 4 règles fondamentales :
L'agent ne doit pas simplement commencer à taper du code. Tout comme on ne construit pas une infrastructure en écrivant des requêtes au hasard, l'agent doit éviter l'écueil de générer aveuglément. Il doit diviser le grand projet en blocs gérables.
L'agent doit d'abord comprendre ce qu'il construit. Avant d'écrire une ligne de logique, il est impératif de clarifier les exigences fonctionnelles et non fonctionnelles. C'est l'étape de cadrage (Framing) qui définit les frontières du système et les entrées/sorties attendues.
L'agent doit suivre un processus clair. Le développement d'un système IA nécessite bien plus que l'entraînement d'un modèle : il exige un pipeline structuré (préparation des données, développement, évaluation, déploiement). L'agent doit s'inscrire dans ce flux ordonné et prévisible.
L'agent doit vérifier le résultat par rapport à l'objectif réel. Une exécution sans validation est inutile. L'agent doit intégrer une boucle d'évaluation stricte, mesurant la perte (écart entre prédiction et résultat souhaité) et s'assurant que le contenu généré correspond aux attentes initiales.
Conclusion
Peu importe qui écrit le code aujourd'hui — un développeur junior, un ingénieur senior ou un agent IA autonome de dernière génération. Les bonnes pratiques du System Design ne sont pas des options, ce sont des lois fondamentales. Les outils changent, mais la rigueur architecturale reste.
Thoughts ? Dites-moi ce que vous en pensez.