Habr AI montre comment préparer une entrée structurée pour un agent IA plutôt qu'un cahier des charges brut

Habr AI publie une analyse détaillée de ce qu'il faut exactement fournir en entrée à un agent IA lorsque la tâche consiste à vérifier des exigences techniques, et non simplement à les résumer. L'idée centrale : au lieu du cahier des charges complet, l'agent reçoit un ensemble d'exigences atomiques sous forme de passeports JSON.

Pourquoi un cahier des charges ne suffit pas

L'autrice part d'un problème que connaît presque quiconque a déjà soumis un long document en bloc à un réseau de neurones. Face à un cahier des charges de plusieurs pages sans préparation préalable, le modèle perd le fil, mélange les exigences de différentes sections et produit des remarques trop générales. Résultat : le système peut repérer certaines imprécisions, mais peine à expliquer quel point pose problème, pourquoi, et comment le corriger.

Le document est donc d'abord découpé en exigences individuelles : une action, une règle ou une contrainte par fragment. Pour ne pas perdre le contexte lors de ce découpage, chaque élément reçoit des champs comme `parent_section` et `parent_object`, et les points liés logiquement sont marqués `linked`. C'est essentiel lorsque plusieurs exigences doivent être vérifiées ensemble : par exemple, quand le système doit envoyer une notification à la fois par e-mail et sur Telegram, et pas seulement sur l'un des deux canaux.

Le passeport d'exigence

L'étape suivante consiste à transformer la formulation humaine en un ensemble d'attributs exploitables par un classifieur. Dans ce schéma, le LLM n'est pas le juge final et ne cherche pas à « tout comprendre ». Son rôle est bien plus restreint : il extrait du texte des signaux structurés et les range dans un JSON. Cette approche offre du contrôle : les attributs peuvent être vérifiés, comparés et, si besoin, corrigés en post-traitement. Comme le formule l'autrice,

« l'agent ne travaille pas avec du texte, mais avec ces structures ».

L'article décrit six attributs de base sur lesquels repose ce passeport. Plutôt qu'une évaluation abstraite de la qualité, le modèle cherche des signaux concrets : chiffres, termes flous, exceptions, limites et acteurs explicites du scénario. En pratique, ce passeport transforme une phrase comme « l'utilisateur doit pouvoir configurer le rapport de manière flexible » en un jeu d'indicateurs clair, qui montre immédiatement ce qui manque à l'exigence. C'est cette interprétabilité qui distingue le schéma d'une simple demande au modèle d'évaluer le texte dans son ensemble.

• `has_numbers` — l'exigence contient-elle des chiffres, des limites, des dates ou d'autres paramètres concrets
• `stopword_score` — à quel point la formulation est floue à cause de mots comme « flexible », « pratique » ou « rapide »
• `has_negative_keywords` — les exceptions et les erreurs sont-elles décrites
• `boundary_conditions_mentioned` — les valeurs vides, maximums, minimums ou autres limites sont-ils indiqués
• `actor_count` — combien d'acteurs figurent explicitement dans l'exigence

Les attributs sont extraits via le JSON mode et des exemples few-shot, afin que le modèle ne s'écarte pas du format. Si le LLM laisse malgré tout passer quelque chose d'évident, comme des chiffres dans le texte, le post-traitement par expressions régulières prend le relais. Un arbre de décision entre ensuite en jeu : il reçoit les attributs numériques et attribue à l'exigence une étiquette comme `ok`, `unverifiable`, `no_negative`, `no_boundary` ou `ambiguity`. Pour l'entraînement, l'autrice a annoté 90 cahiers des charges, découpés en 270 exigences, et obtenu environ 82% d'accuracy sur le jeu de test.

Le critique et le passage à l'échelle

Le pipeline ne s'arrête pas là. Même un bon classifieur ne voit qu'une exigence à la fois et laisse donc facilement passer les contradictions entre sections. Pour ces cas, un agent critique distinct reçoit le texte complet du cahier des charges, la liste des passeports JSON et les étiquettes prédites. Sa mission n'est pas de réévaluer chaque phrase, mais d'examiner le document dans son ensemble pour y débusquer des conflits, des lacunes dans les droits d'accès et des erreurs de mapping des intégrations. Ce critique peut par exemple remarquer que le champ « Entrepôt » est obligatoire à un endroit, alors qu'une valeur vide est admise ailleurs.

Pour que le schéma fonctionne au-delà des exemples courts, les exigences sont traitées en parallèle via `ThreadPoolExecutor`, et les modèles locaux tournent dans Ollama. Selon l'autrice, sur un PC de jeu classique, le système encaisse sans difficulté 4–6 requêtes parallèles sans dégradation notable, ce qui se traduit par une accélération d'environ 3–4 fois sur un lot d'une centaine d'exigences. Les exigences liées restent dans le même thread, afin de préserver l'ordre et le contexte global de la vérification.

Ce que cela signifie

L'analyse publiée sur Habr AI illustre bien l'évolution du développement pratique d'agents IA : on passe des tentatives de « tout donner d'un coup au modèle » à des pipelines étroits et contrôlés, avec des attributs explicites, des modèles locaux et un niveau d'arbitrage distinct. Une équipe qui veut construire un agent appliqué à l'analyse, à la QA ou au traitement de documentation devra réfléchir non seulement au choix du modèle, mais aussi à l'organisation des données d'entrée, de l'annotation et de la vérification finale des résultats.