Habr AI a expliqué pourquoi Zero Shot est risqué pour extraire des exigences à partir de lois et d’actes normatifs

Sur Habr AI est paru une analyse expliquant pourquoi tenter d'extraire les exigences du système informatique d'une loi avec un simple prompt zero-shot produit presque toujours une fausse confiance. L'auteur soutient que le problème n'est pas dans la capacité du modèle à lire les documents réglementaires, mais dans le fait qu'entre une norme légale et une exigence système se trouve toute une chaîne de décisions analytiques.

Pourquoi une Loi n'est pas une Spécification

L'idée semble logique : une loi contient déjà des règles, un modèle sait lire et structurer le texte, il suffit donc de demander « extraire les exigences ». Mais c'est précisément là qu'intervient la substitution. Un acte réglementaire ne décrit pas une interface, un processus ou une API, mais un champ juridique : les rôles, les conditions, les définitions, les interdictions, les conséquences et les références à d'autres normes.

Traduire tout cela en exigences de projet en une seule étape est impossible sans perdre le sens. Pour un analyste, ce n'est que de la matière première, pas un énoncé de problème finalisé pour l'équipe de développement. L'auteur montre que Zero Shot fait prématurément croire que le travail est déjà terminé.

Le modèle rassemble les obligations de différents acteurs dans une seule liste, mélange les définitions, les contraintes et les actions, puis empaquette le tout dans un format pratique « le système doit ». À la lecture, cette réponse semble cohérente, mais elle s'intègre mal dans l'architecture, le backlog et la spécification vérifiable, car elle ne répond pas aux questions élémentaires : qui agit, que se passe-t-il exactement et dans quelle partie du système doit-on le placer.

Où se Produisent les Pertes

La principale critique de cette approche n'est pas simplement une imprécision, mais une perte de maîtrise. Lorsqu'une équipe reçoit une liste toute prête « d'exigences », il lui devient difficile de comprendre ce que le modèle a exactement écarté en chemin, ce qu'il a interprété lui-même et quelles normes concernent réellement non pas le produit, mais des acteurs externes du processus. C'est ainsi que disparaît la frontière entre une exigence obligatoire, une hypothèse de travail et simplement une reformulation de la norme. Cela crée une illusion dangereuse de complétude.

• Les exceptions et les conditions d'application de la norme peuvent disparaître de la réponse
• Les contraintes se transforment facilement en fonctionnalités
• Les définitions se déguisent en exigences à part entière
• Le sujet de l'action est perdu : qui initie, vérifie et enregistre le résultat
• La traçabilité d'une norme spécifique vers une conclusion du projet disparaît

De ce fait, une réponse élégante s'avère non vérifiable. Si quelqu'un de l'équipe demande d'où provient un point spécifique, une référence à l'article de loi sera insuffisante. Une traçabilité est nécessaire : quel fragment de la norme a produit quelle conclusion et pourquoi. Sans elle, n'importe quelle exigence est vulnérable aux discussions avec les avocats, les analystes et les développeurs, surtout si l'on parle de scénarios complexes, d'audits ou de contrôles réglementaires. Et plus l'environnement réglementaire est strict, plus cette manque de transparence devient coûteux.

Où Zero Shot est Utile

Cependant, l'auteur ne propose pas d'abandonner les LLMs dans le travail avec la législation. Au contraire, Zero Shot peut être utile comme reconnaissance initiale : entrer rapidement dans le sujet, obtenir une carte préliminaire des entités, formuler des hypothèses sur les scénarios et comprendre quelles parties du document nécessitent d'abord une analyse manuelle. Le problème commence à partir du moment où cette ébauche est traitée comme un résultat final de l'analyse. En tant qu'outil de navigation textuelle primaire, c'est un gain de temps.

« Zero Shot peut servir à commencer le travail avec une loi.

Mais il ne faut pas l'utiliser pour considérer ce travail comme terminé. »

Une alternative fonctionnelle semble moins brillante, mais est plus fiable : d'abord déterminer pour quel rôle et quel objet d'automatisation on recueille les exigences, puis décomposer le texte par types de matériau, rétablir la subjectivité, vérifier l'exhaustivité et seulement ensuite transformer les conclusions en artefacts de projet. L'IA dans un tel schéma reste un assistant utile, mais ne remplace plus la logique analytique elle-même. C'est dans un tel mode qu'un modèle accélère le travail sans remplacer l'expertise.

Ce que Cela Signifie

Pour les équipes qui souhaitent accélérer l'analyse juridique à l'aide des LLMs, la conclusion est simple : un prompt élégant ne remplace pas une analyse systématique des documents réglementaires. Zero Shot convient pour un premier passage et des brouillons, mais non pour les exigences défendables dont dépendent les décisions de produit, l'architecture et la conformité légale. Sinon, la rapidité en entrée se transforme en erreurs déjà à l'étape de la conception et des accords réels, et non seulement en théorie.