Un architecte de systèmes d'IA a conçu un « Canon » pour les analystes : 17 exigences métier en 8 jours

La plupart des histoires sur les agents d'IA au travail s'arrêtent à la productivité personnelle : un passionné a configuré ses prompts et tout file chez lui. Nikolaï Karpov, architecte de systèmes d'IA, a raconté sur Habr ce qui se passe ensuite, quand il faut offrir le même résultat à tout un département d'analystes sans obliger chacun à suivre une formation de prompt engineering.

Une épreuve du feu plutôt qu'une présentation

Le premier vrai test n'a pas eu lieu dans un bac à sable. Un analyste devait remettre au client un lot d'exigences métier pour un nouveau produit de paiement, alors que les sources réglementaires venaient d'être mises à jour. Selon l'estimation de l'analyste lui-même, le faire à la main aurait pris plus de deux semaines. Un ensemble minimal composé d'un modèle, de rôles, de compétences et d'outils a été assemblé au fil de l'eau, et pendant une semaine l'auteur a travaillé comme copilote de l'analyste, en corrigeant le canon directement en fonction de la tâche.

Conclusion clé : l'essentiel du temps n'a pas été consacré à la génération, mais aux conditions de confiance. Quel modèle utiliser pour assembler le document, où puiser les données, comment détecter les collisions, que faire en cas de données manquantes. Quand l'agent s'est mis à inventer, ce n'est pas seulement la baisse de la température à 0,2 et du top-p à 0,85 qui a aidé, mais aussi les règles de traitement des données manquantes. Ces paramètres variaient d'ailleurs selon les spécialistes : une température de 0,6 suffisait à certains. Résultat : 14 documents en 8 jours ouvrés, puis le lot est passé à 17, chacun relu par un humain et publié dans Confluence.

Comment le canon est structuré

L'auteur a distingué quatre entités. Le rôle définit les limites de l'autorité et la gestion de l'incertitude. La compétence décrit la méthode : un Use Case, une interface et une API nécessitent des vérifications différentes. L'outil est un script pour une opération répétable, par exemple l'assemblage d'un DOCX ou la validation d'un XML. Le modèle (template) fournit la forme. Les instructions détaillées ne sont chargées qu'en cas de besoin, de sorte que le contexte n'est pas saturé.

La structure des projets a elle aussi dû être refondue après les retours des collègues. Au départ, il y avait trois couches : sources, brouillons, artefacts. Puis il est apparu qu'un document passe par de nombreuses itérations, et des répertoires par type de document ont vu le jour, avec à côté md/ et docx/. Le contrat est simple : tout ce qui se trouve dans les répertoires de travail est un brouillon, même si l'assemblage a réussi. Les versions validées par le spécialiste partent dans un répertoire de release distinct.

Les détails qui font la différence

La numérisation des sources est présentée comme le socle : si l'agent lit mal un tableau, l'erreur se propage dans les exigences. Les tableaux complexes des régulateurs, avec des lignes imbriquées, perdaient leur hiérarchie en représentation à plat ; la règle est donc devenue stricte : tableaux uniquement en HTML. Les schémas sont convertis en PlantUML, draw.io ou BPMN, mais vérifiés par rapport à l'original, car un schéma syntaxiquement correct ne garantit pas des liens corrects.

Les lacunes dans les données sont enregistrées par l'agent dans open-questions.md avec un identifiant et un statut, et dans le document il laisse une mention explicite avec un lien. Il lui est interdit d'inventer une réponse, et à la session suivante, il relit le registre et poursuit.

Ce qu'il faut en retenir

Si vous déployez des agents dans une équipe, ne commencez pas par le choix du modèle, mais par les contrats : qui est responsable de quoi, où se trouvent les brouillons et où le contenu validé, comment consigner les inconnues. Les erreurs des utilisateurs doivent se traduire en corrections du canon, et non rester dans un chat. Et ne confondez pas un montage d'urgence avec un montage durable : le basculement entre modèles à cause des limites d'abonnement est qualifié par l'auteur de solution sous pression, et non de recommandation.

L'article s'interrompt à mi-parcours ; pour le support via messageries et la mémoire, on ne peut donc juger que d'après la table des matières, mais la base est déjà utile à ceux qui construisent ce type d'infrastructure.