Aller au contenu principal

Conception logicielle pour les agents IA

Un discours fréquent dans le développement assisté par IA affirme qu'il suffit désormais de rédiger des spécifications et de laisser les modèles de langage générer l'intégralité du code. Selon cette approche « Spec-to-Code », le code deviendrait un produit jetable et peu coûteux : en cas d'erreur, il suffirait d'ajuster la spécification et de relancer la génération sans jamais inspecter le code source.

Dans les projets complexes, cette hypothèse atteint rapidement ses limites. Lorsque les développeurs cessent de structurer le code, l'entropie logicielle (concept que Pocock emprunte à The Pragmatic Programmer) s'accumule à un rythme soutenu : les correctifs locaux multiplient la duplication logique, les frontières d'isolation s'effacent et la base de code devient ingérable. Les agents IA ne rendent pas les mauvaises bases de code bon marché ; au contraire, une architecture confuse rend les agents inefficaces et coûteux.

Le codage assisté par IA renforce la valeur d'une conception logicielle rigoureuse. Lors de sa conférence à AI Engineer Europe, Matt Pocock a mis en évidence cinq modes de défaillance récurrents dans la programmation assistée par IA, en les associant à des principes éprouvés du génie logiciel.

Dérive d'intention : bâtir le « concept de conception » par le dialogue contradictoire​

Mode de défaillance​

Le développeur a une idée précise du système, mais le modèle interprète la spécification brute dans une direction divergente et produit une grande quantité de code inadapté.

Fondement théorique cité en conférence​

Pocock s'appuie sur The Design of Design de Frederick Brooks pour rappeler qu'en conception collaborative, l'actif essentiel n'est pas un document statique, mais le concept de conception (Design Concept) : la compréhension partagée et immatérielle des mécanismes internes et des limites du système.

Pratique d'ingénierie​

Avant de générer du code, on peut aligner la conception avec grill-me ou grill-with-docs du dépôt mattpocock/skills :

  • La procédure commune grilling construit un arbre de décision et pose par tours les questions dont les prérequis sont déjà résolus, avec une réponse recommandée pour chacune ;
  • grill-with-docs associe cet entretien à la modélisation du domaine afin de consigner les termes clarifiés et les décisions difficiles à inverser dans CONTEXT.md et des ADR ;
  • Après l'alignement, les commandes distinctes to-spec et to-tickets peuvent synthétiser la conversation en spécification ou en tickets verticaux.

Décalage de vocabulaire : ancrer le contexte avec le langage omniprésent​

Mode de défaillance​

L'agent génère des explications verbeuses et introduit des dénominations de classes et de fonctions déconnectées des concepts métier réels.

Fondement théorique cité en conférence​

Pocock cite Domain-Driven Design d'Eric Evans pour insister sur le langage omniprésent (Ubiquitous Language) : les experts métier, les développeurs et le code source doivent partager un vocabulaire strictement identique pour éliminer toute ambiguïté.

Pratique d'ingénierie​

  • Extraire un glossaire structuré des entités, verbes d'action et états du cycle de vie depuis la base de code (comme un fichier CONTEXT.md) ;
  • Injecter ce glossaire dans le contexte actif de l'agent lors des phases de planification et de refactorisation ;
  • Un vocabulaire unifié rend les raisonnements de l'agent plus concis et aligne directement l'implémentation sur le modèle métier.

Excès de vitesse : imposer une vitesse limite avec le TDD et le typage​

Mode de défaillance​

Le modèle produit un grand volume de code d'un coup. Le code semble plausible, mais échoue à l'exécution ou accumule des erreurs invisibles.

Fondement théorique cité en conférence​

Pocock reprend la métaphore d'Andrew Hunt et David Thomas dans The Pragmatic Programmer : ne roulez pas plus vite que vos phares (Don't outrun your headlights). En conduite de nuit, la portée des phares dicte la vitesse maximale sécurisée ; en logiciel, la vitesse du retour d'information constitue la vitesse limite du développement.

Pratique d'ingénierie​

  • Typage statique et exécution directe : utiliser TypeScript ou un typage strict, combiné à un accès direct aux tests et à l'environnement d'exécution ;
  • Développement piloté par les tests (TDD) :
    1. Rédiger un test ciblé définissant les entrées et sorties attendues ;
    2. Exécuter le test pour vérifier l'échec initial (rouge) ;
    3. Demander à l'agent de produire l'implémentation minimale pour réussir le test (vert) ;
    4. Refactoriser et consolider la conception interne.
  • Le TDD contraint le modèle à progresser par petits pas vérifiables, ce qui aide à limiter les dérives massives.

Perte dans le superficiel : modules profonds pour masquer la complexité​

Mode de défaillance​

La base de code est fragmentée en une multitude de petites fonctions et de modules superficiels. L'agent sature rapidement sa fenêtre de contexte en tentant de démêler les graphes de dépendances.

Fondement théorique cité en conférence​

Pocock se réfère à la distinction établie par John Ousterhout dans A Philosophy of Software Design entre deux formes de modules :

  • Modules superficiels (Shallow Modules) : interfaces complexes dissimulant peu de logique, générant une lourde charge cognitive de navigation ;
  • Modules profonds (Deep Modules) : interfaces simples et stables encapsulant une logique interne riche et des états complexes.

Pratique d'ingénierie​

  • Refactoriser les utilitaires dispersés en modules profonds avec improve-codebase-architecture, qui recherche les possibilités d'approfondissement et applique le deletion test ;
  • Restreindre et stabiliser les contrats d'interface exposés ;
  • Positionner les frontières de tests sur les interfaces publiques, masquant les détails internes pour permettre à l'agent de modifier l'implémentation sans saturer son contexte global.

Surcharge cognitive : délégation en boîte grise et investissement architectural​

Mode de défaillance​

Avec l'accélération de la génération de code, la relecture humaine ligne à ligne devient un goulot d'étranglement épuisant.

Fondement théorique cité en conférence​

Pocock associe cela à la recommandation de Kent Beck d'« investir chaque jour dans la conception système » : la valeur durable de l'ingénierie réside dans l'arbitrage des frontières, des flux de données et des responsabilités, et non dans la saisie de syntaxe.

Pratique d'ingénierie​

  • Délégation en boîte grise (Gray-Box Delegation) :
    • Considérer les modules profonds comme des boîtes grises sur les chemins non critiques ;
    • Le développeur définit les contrats d'interface et vérifie les tests d'intégration, tout en déléguant les détails internes à l'agent ;
    • Conserver une relecture en boîte blanche rigoureuse pour les sous-systèmes sensibles (authentification, sécurité, calculs financiers, transactions).
  • Répartition des rôles : l'humain intervient comme Architecte Stratégique (exigences, contrats et critères de validation) ; l'IA intervient comme Programmeur Tactique (implémentation et exécution des tests dans le cadre fixé).

Synthèse des principes et pratiques​

DimensionPrincipe classiqueThéoricien cité en conférenceMode de défaillance IAPratique pour agents
IntentionConcept de conceptionFrederick Brooks (The Design of Design)Dérive d'intention, code inadaptéQuestionnement contradictoire (grill-me)
VocabulaireLangage omniprésentEric Evans (Domain-Driven Design)Verbiage, termes incohérentsGlossaire métier (CONTEXT.md) injecté
RythmePortée des pharesHunt & Thomas (The Pragmatic Programmer)Code non fonctionnel, dérive non contrôléeBoucles TDD pas à pas, typage statique
StructureModules profondsJohn Ousterhout (A Philosophy of Software Design)Perte de contexte dans le code éparpilléInterfaces simples, encapsulation forte
CollaborationInvestissement systèmeKent BeckSurcharge cognitive de relectureDélégation en boîte grise, tests aux interfaces

Limites d'application​

  1. La délégation en boîte grise exige des tests automatisés solides : sans validation automatisée des interfaces, la délégation conduit directement à la dégradation silencieuse du code.
  2. Les zones critiques requièrent une relecture complète : le code lié à la sécurité, à la cryptographie, aux paiements ou aux schémas de base de données doit faire l'objet d'une vérification humaine ligne par ligne.
  3. Restructurer avant de déléguer : transformer les modules superficiels en modules profonds avant de lancer des tâches d'agents peut améliorer la navigabilité du code.

Sources et définitions des outils​

Les cinq associations entre modes de défaillance et principes sont attribuées à la conférence de Pocock ; le comportement des outils repose sur leurs définitions actuelles dans le dépôt :