Erreurs Zero Shot dans l'Extraction des Exigences à partir de NPA

Pourquoi le prompting zero-shot échoue pour extraire les exigences des textes légaux

Le prompting zero-shot dans les LLM pour extraire les exigences des réglementations légales donne une fausse impression de produit fini. Le modèle produit une liste structurée de phrases comme « le système doit », mais ce ne sont pas de véritables exigences — ce sont juste des règles reformulées. Cette approche ignore la nature multi-étapes de l'analyse : de l'identification des rôles et conditions à la traçabilité vers les sources.

La tâche exige de la décomposer en étapes — repérer les sujets, classer les règles, vérifier la complétude. Un seul prompt rate les subtilités du langage légal : voix passive, exceptions, renvois croisés.

Pourquoi les textes légaux ne sont pas des spécifications techniques

Les réglementations délimitent un paysage juridique, pas un système spécifique. Elles contiennent quatre couches d'informations :

• Définitions d'objets et statuts (ex. : signatures électroniques simples comme codes ou mots de passe selon la loi fédérale 63-FZ) ;
• Règles d'actions des participants ;
• Conditions, limites, exceptions ;
• Conséquences et renvois à d'autres règles.

Le zero-shot brouille ces distinctions, traitant tout comme des fonctions. Le résultat semble prêt pour l'ingénierie mais n'est pas lié à votre projet : on ne sait pas qui fait quoi, où c'est implémenté, ni sous quelles conditions.

Pour les développeurs intermédiaires à seniors, c'est crucial : sans décomposition, les LLM mélangent définitions et contraintes, transformant des phrases passives (« l'accès doit être restreint ») en interprétations invérifiables.

Erreurs courantes du zero-shot dans l'extraction légale

Le modèle ignore le contexte du projet. Les pièges principaux incluent :

• Pas de sélection de sujet : Il regroupe les règles pour tous les rôles (utilisateur, opérateur, autorité) en une seule liste, ignorant le focus de votre système.
• Mélange des types de règles : Les définitions deviennent des exigences ; les limites se transforment en fonctionnalités.
• Voix passive sans acteur : « L'information doit être fournie » ne précise pas qui initie, vérifie ou journalise.
• Formulation générique 'Le système doit' : Ignore la gestion des données, audits, modèles de rôles, dépendances externes.
• Pas d'analyse des lacunes : Incapable de repérer les règles manquantes, exceptions ou rôles oubliés.
• Traçabilité faible : Citer un article n'explique pas comment un extrait devient une exigence.
• Ignore l'impact multi-systèmes : Une réglementation engendre apps clients, backends, modules d'audit — le modèle ne différencie pas.

Test de qualité : Pouvez-vous répondre « qui, quoi, où dans le système ? » Non ? C'est de la matière brute, pas des exigences.

Défis des textes légaux pour les LLM

Extraire des infos des documents légaux est ardu à cause des contextes longs, jargon et structures éparpillées. Les retours d'OpenAI et Anthropic préconisent chain-of-thought, critères de qualité et analyse étape par étape plutôt que zero-shot pour ces tâches.

Les erreurs coûtent cher : un contrôle manqué signifie architecture défaillante et risques légaux.

Quand le zero-shot fonctionne vraiment

Limitez-le à une prospection initiale :

• Aperçu rapide du document ;
• Cartographie approximative des entités ;
• Hypothèses de scénarios ;
• Familiarisation au domaine.

Puis itérez : affinez les prompts, vérifiez, tracez.

Points clés :

• Le zero-shot donne un brouillon plausible, pas des exigences — décomposez la tâche.
• Épinglez toujours sujet, conditions, type de règle pour la traçabilité.
• Vérifiez la complétude : qu'est-ce qui manque, quelles exceptions ignorées ?
• Pour la legal tech, utilisez chain-of-thought et prompting multi-étapes.
• Une réglementation = plusieurs systèmes : définissez les frontières d'automatisation dès le départ.

En CI/CD : Intégrez les LLM avec validation (comparaisons benchmarks, revue experte) pour réduire les risques de conformité.

— Editorial Team