Les agents de programmation basés sur l’IA peuvent aider les équipes logicielles à traiter des problèmes architecturaux qui vont au-delà de la simple écriture de code, mais leur utilité dépend de la clarté des objectifs et des contraintes définis par l’équipe. L’article publié sur InfoQ, rédigé par Pierre Pureur, Kurt Bittner et Todd Miller, et relu par Daniel Bryant, avertit que fournir à l’agent uniquement des exigences fonctionnelles ne garantit pas une architecture évolutive, sûre ou facile à maintenir.
L’approche proposée repose sur les exigences relatives aux attributs de qualité (Quality Attribute Requirements ou QARs), comme les performances, la sécurité et l’évolutivité, ainsi que sur la clarification des compromis que l’agent doit prendre en compte. L’article insiste également sur la nécessité de tester ce que produit l’agent au moyen de mesures claires, plutôt que de se contenter d’examiner le code ou de faire confiance à ses recommandations.
1. Documenter les services anciens avant de s’y fier
Une architecture moderne peut dépendre d’un service ancien qui assure une fonction précise, comme la récupération de données de contrats d’assurance depuis un ancien système basé sur une base de données IMS. Le problème est que ces services peuvent manquer de documentation précise, ce qui rend difficile la compréhension des flux de données ou la détection de défauts logiques et de sécurité susceptibles d’apparaître à des étapes avancées du développement ou après le passage en production.
L’agent peut représenter la conception du service et documenter les flux de données, puis examiner le code et proposer des corrections ou une refactorisation si le service est difficile à comprendre et à maintenir. Toutefois, cette utilisation ne supprime pas la nécessité d’une décision d’ingénierie humaine concernant le maintien du service ou le fait que ses risques exigent son remplacement.
2. Rechercher les défauts architecturaux
L’agent peut être orienté pour trouver des écarts par rapport aux normes architecturales, des pratiques de programmation dégradées ou des parties nécessitant une refactorisation. Les exemples d’examen comprennent la conception des interfaces de programmation, ainsi que les interfaces complexes, non sécurisées ou inefficaces, et les violations des limites de la conception pilotée par le domaine (DDD).
L’article indique que l’agent trouvera souvent de nombreuses améliorations. L’équipe doit donc distinguer les problèmes importants des suggestions de faible valeur. La qualité des résultats augmente lorsque les ingénieurs définissent des objectifs mesurables, des alternatives connues et des compromis clairs, plutôt que de se contenter de décrire les fonctions demandées.
3. Auditer la sécurité en isolant l’agent
L’agent peut être utilisé pour représenter les flux de données, identifier les fichiers à haut risque, examiner des défauts logiques complexes, créer des tests ou des scripts simulant des tentatives d’exploitation, puis proposer des correctifs pour les problèmes détectés. L’article présente une expérience portant sur des paquets npm classés comme présentant un risque de sécurité : deux paquets ont été mis à jour, un paquet a été remplacé et un autre a été conservé après que l’alerte a été considérée comme un faux positif.
Toutefois, cette utilisation exige des restrictions opérationnelles explicites : limiter l’accès de l’agent aux fichiers autorisés, masquer les mots de passe des bases de données et les secrets, exécuter les tests sur un réseau isolé et imposer une revue humaine avant l’intégration de toute modification.
4. Créer une base architecturale pour les prototypes
La rapidité des agents permet de construire rapidement un prototype, mais le modèle produit peut être temporaire et inutilisable si aucun objectif architectural ne lui est défini. L’article propose de préparer des applications structurées préalables comprenant le style d’écriture du code, la conception de la base de données, les interfaces, les plateformes et les frameworks préférés, ainsi que des QARs rédigées au format Markdown.
Des modèles GitHub peuvent également être utilisés pour uniformiser la structure initiale des applications et intégrer les normes de l’équipe dès le départ. Il est préférable de décrire l’objectif, les contraintes et la manière de vérifier leur réalisation, plutôt que d’imposer à l’agent une solution détaillée à l’avance.
5. Générer des architectures initiales testables
L’article propose d’utiliser l’agent pour créer des Minimum Viable Architectures ou MVAs, qui ne se limitent pas à du code démontrant les fonctionnalités, mais comprennent également les tests, les données de test et l’environnement d’exécution nécessaires à la vérification des QARs. L’agent peut générer les outils de test et les configurations des conteneurs, mais l’équipe doit s’assurer que les tests mesurent réellement les attributs requis.
Il convient également d’évaluer la capacité de la MVA à prendre en charge des scénarios d’évolution architecturale, car l’extension d’une architecture générée automatiquement peut devenir coûteuse si elle n’a pas été conçue pour évoluer.
Qu’est-ce qui change concrètement ?
Le message principal de l’article est que les agents de programmation accélèrent la production de code, mais qu’ils accroissent l’importance de la formulation des exigences, des contraintes et des tests. Les compétences liées à l’écriture du code ne disparaissent pas, mais la définition de ce qui doit être construit, de ce qui constitue une qualité acceptable et de la manière dont elle sera mesurée devient plus sensible. Il faut donc considérer l’agent comme un outil placé sous supervision architecturale, et non comme un substitut au jugement d’ingénierie.