AI-agent pour la vérification des spécifications techniques : développement, architecture, pratique

Construire un agent IA pour l'audit des spécifications techniques : Leçons du terrain

Développer un outil d'apprentissage automatique pour l'audit automatisé des spécifications techniques (specs) exige une stratégie claire et une bonne connaissance des pièges courants. Notre expérience pratique a révélé que le succès repose sur des données d'entraînement de haute qualité et une architecture hybride combinant des modèles de langage large (LLM) avec des algorithmes traditionnels.

Construire l'ensemble de données d'entraînement

La première et la plus critique étape a été la collecte et l'étiquetage des données. Nous avons constitué un ensemble de données représentatif de 90 spécifications techniques, réparties en trois catégories :

• Spécifications de haute qualité (30 exemples) qui ont traversé le développement avec des changements minimes.
• Spécifications problématiques (30 exemples) qui ont provoqué des conflits, des reprises et des retards.
• Spécifications moyennes (30 exemples) qui ont fonctionné mais présentaient des failles découvertes pendant le développement.

Chaque spécification était accompagnée d'une analyse détaillée d'un expert mettant en lumière forces et faiblesses. Pour accroître la diversité, nous avons inclus des specs d'auteurs et de projets variés dans des secteurs comme la distribution, l'industrie et les services.

Classifier les erreurs courantes des specs

L'analyse des specs problématiques a mis en évidence des problèmes systémiques que notre agent devait détecter. Principales catégories :

• Scénarios positifs uniquement. L'exigence décrit le chemin heureux mais omet la gestion d'erreurs, les cas limites et les exceptions.
• Formulations vagues. Termes subjectifs ou flous comme « rapide », « convivial » ou « flexible » sans métriques mesurables.
• Exigences non testables. Absence de moyen clair pour construire un cas de test définitif de vérification.
• Conflits internes. Incohérences entre sections ou clauses au sein de la même spec.
• Cas limites manquants. Aucune indication sur le comportement du système face à des entrées extrêmes ou inhabituelles.

Exemples de transformation d'exigences non testables en testables

Énoncés vagues typiques et comment les rendre concrets :

• Original : « Les utilisateurs doivent pouvoir personnaliser flexiblement les rapports. »

Concret : « Les rapports proposent des paramètres personnalisables : plage de dates (tout intervalle), contrepartie (sélection multiple). Les paramètres sont sauvegardés par utilisateur. Inclure des options de regroupement par contrepartie et entrepôt. »

• Original : « Le système doit gérer correctement de gros volumes de données. »

Concret : « Le chargement de 10 000 documents totalisant 500 000 lignes doit s'achever en moins de 15 minutes. Utilisation mémoire limitée à 2 Go. »

• Original : « Tous les formulaires d'écran doivent suivre un style cohérent. »

Concret : « Dans tous les formulaires de documents, les boutons « Enregistrer » et « Publier » sont en haut à droite. Couleur des boutons : vert (R=0, V=128, B=0). Police : Arial, 10 pt. »

Critères de qualité et architecture de l'agent

Nous avons défini une checklist pour l'évaluation des specs couvrant les objectifs métier, la complétude des scénarios, la clarté, la testabilité, la cohérence et la faisabilité. Ces éléments ont servi de base aux prompts et à la logique de l'agent.

La solution repose sur un modèle hybride combinant la Génération Augmentée par Récupération (RAG) avec la classification par arbre de décision.

• Composant RAG gère la recherche contextuelle. Lors de l'examen d'une nouvelle exigence, l'agent extrait des extraits sémantiquement similaires de la base de connaissances (90 specs étiquetées), rappelant les erreurs courantes et leurs contextes.
• Arbres de décision catégorisent les erreurs à l'aide de caractéristiques structurées. L'agent LLM parse d'abord le texte brut en caractéristiques structurées (ex. : JSON), qui alimentent le classificateur.

Mise en œuvre technique de l'analyse

La vérification d'une exigence unique suit ces étapes :

• Extraction de caractéristiques : Un analyseur basé sur LLM convertit le texte en vecteur de caractéristiques. Par exemple :

* has_numbers : 1 (inclut des spécificités numériques) ou 0.

* has_negative_keywords : 1 (mentionne « si », « sinon », « erreur ») ou 0.

* boundary_conditions_mentioned : 1 (couvre les cas limites) ou 0.

* stopword_score : poids des marqueurs subjectifs (« flexible », « intuitif »).

• Classification : Le vecteur de caractéristiques structuré est transmis à un modèle d'arbre de décision (ex. : Scikit-learn), qui l'assigne à une catégorie d'erreur ou la marque comme solide.
• Génération de rapport : L'agent produit un commentaire détaillé indiquant le type de problème, sa localisation dans le texte et des recommandations de correction tirées d'analogies de la base de connaissances.

Cette séparation — LLM pour la compréhension sémantique et l'extraction de données, classificateur pour la logique rigide — garantit transparence et contrôle.

Enseignements clés

• La qualité des données est primordiale. Sans un ensemble de données représentatif et bien étiqueté (au moins des dizaines d'exemples), un entraînement efficace est impossible.
• Hybride bat LLM pur. Associer RAG pour le contexte aux arbres de décision pour une classification précise donne des résultats plus fiables et explicables.
• Priorisez la testabilité. Une bonne spec permet des cas de test sans ambiguïté. Toutes les exigences doivent être mesurables et spécifiques.
• Automatisez les tâches ingrates. L'agent ne remplace pas les analystes mais agit comme une paire d'yeux frais, repérant systématiquement les erreurs courantes pour gagner du temps et réduire les erreurs humaines.
• Continuez d'apprendre. Mettez régulièrement à jour la base de connaissances avec de nouvelles specs et analyses pour améliorer la précision et s'adapter à de nouveaux types de projets.

— Editorial Team