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 serait devenu extrêmement 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 abandonnent le contrôle de la structure du code, le désordre s'accumule plus vite : les correctifs locaux s'empilent, la logique dupliquée se propage et la base de code se dégrade rapidement. Pocock décrit ce phénomène à l'aide du concept d'entropie logicielle, emprunté à The Pragmatic Programmer. Une mauvaise base de code ne s'améliore pas grâce à l'IA ; elle égare au contraire les agents dans un enchevêtrement de dépendances.

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 imagine les grandes lignes d'une fonctionnalité, mais le modèle interprète son prompt ou sa spécification sommaire dans une direction complètement différente ; il peut aussi élaborer un plan trop tôt et produire une grande quantité de code non souhaité.

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 GLOSSARY.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​

Le modèle produit de longues explications chargées de qualificatifs génériques, mais ses concepts ne correspondent pas à ceux des experts métier. Les modèles et les noms de fonctions générés se retrouvent ainsi déconnectés du métier réel.

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, par analyse automatique ou manuelle, les concepts centraux du code et du métier dans un tableau Markdown de vocabulaire de domaine (par exemple CONTEXT.md), avec noms d'entités, verbes d'action, transitions d'état et définitions explicites ;
  • Injecter systématiquement ce glossaire dans le contexte de l'agent pendant les échanges, la planification et la 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 s'écarte progressivement de l'objectif faute de vérification immédiate.

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 un système de typage statique fort tel que TypeScript et fournir à l'agent un environnement d'exécution immédiate, comme un navigateur ou un terminal ;
  • 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 fonctions auxiliaires dispersées et les états intermédiaires 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 d'effectuer une modification locale sans devoir comprendre l'ensemble du système.

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 (calculs financiers, authentification et autorisation de sécurité, infrastructure).
  • Répartition des rôles : l'humain intervient comme Architecte Stratégique (Strategic Architect : analyse des exigences, conception des interfaces et critères de validation) ; l'IA intervient comme Programmeur Tactique (Tactical Programmer : 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 conception (Design Concept)Frederick Brooks (The Design of Design)Dérive d'intention, code inadaptéQuestionnement contradictoire (grill-me), génération des artefacts après un dialogue suffisant
VocabulaireLangage omniprésent (Ubiquitous Language)Eric Evans (Domain-Driven Design)Verbiage, termes incohérentsGlossaire métier Markdown (CONTEXT.md), conventions de nommage communes
RythmeNe pas dépasser la portée des pharesHunt & Thomas (The Pragmatic Programmer)Code non fonctionnel, dérive non contrôléeBoucles TDD pas à pas, typage statique
StructureModules profonds (Deep Modules)John Ousterhout (A Philosophy of Software Design)Perte de contexte dans le code éparpilléInterfaces simples, encapsulation à forte cohésion, frontières de test aux interfaces
CollaborationInvestissement dans la conception système / délégation en boîte griseKent BeckSurcharge cognitive de relectureL'humain maîtrise les interfaces et les tests ; l'IA prend en charge l'implémentation interne

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 central lié à la vérification des permissions, au règlement des paiements, aux communications chiffrées et aux migrations 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 :

Explorer les liens

À lire avant (1)

Discussions connexes (4)

Citée par (1)

Sur les mêmes sujets (20)

Ouvrir le réseau