Consultant MOA / Business Analyst : comprendre les LLM et les agents sans coder

Une position qui devient centrale

Le consultant MOA ou business analyst a toujours occupé la zone de traduction entre un besoin métier et une réalisation technique. Avec les systèmes IA, cette zone s'élargit : le métier formule une attente en langage naturel, la technique répond par un système dont le comportement n'est pas garanti à l'avance. Personne ne tient naturellement cette frontière. C'est exactement là que le rôle prend de la valeur — à condition d'acquérir un socle technique suffisant pour ne pas être spectateur.

Ce guide décrit ce socle : ce qu'il faut comprendre des LLM, du RAG et des agents pour spécifier correctement, comment cadrer un cas d'usage, comment écrire des exigences testables sur un système probabiliste, et comment mener une recette qui ait un sens.

Le socle technique utile — sans coder

Il ne s'agit pas de devenir ingénieur. Il s'agit de comprendre assez du fonctionnement pour poser les bonnes questions et repérer une promesse intenable. Quatre notions suffisent à couvrir la grande majorité des projets d'entreprise.

• Un LLM produit du texte plausible à partir d'un contexte : il ne consulte pas votre base de données et ne raisonne pas sur des règles métier qu'il n'a jamais vues.
• Le RAG consiste à retrouver des documents pertinents puis à les fournir au modèle : la qualité de la réponse dépend d'abord de la recherche, pas du modèle.
• Un agent enchaîne des actions — appeler un outil, lire un système, écrire quelque part — avec une part de décision autonome à chaque étape.
• L'évaluation consiste à mesurer la qualité des réponses sur un jeu de cas connus : sans elle, il n'existe aucune façon de savoir si le système fonctionne.

Un test simple pour vérifier votre compréhension : si une réponse est fausse, savez-vous distinguer un problème de recherche documentaire, un problème de données sources, un problème de formulation et un problème de modèle ? Ces quatre causes appellent quatre corrections différentes.

Comprendre le RAG côté métier

La majorité des projets IA en entreprise sont des projets de RAG : répondre à partir d'un corpus documentaire interne. Vue du métier, la difficulté n'est presque jamais le modèle. Elle est dans le corpus.

• Le périmètre documentaire : quels documents entrent, lesquels sont exclus, qui décide.
• Les droits d'accès : deux utilisateurs différents ne doivent pas voir les mêmes réponses si leurs droits diffèrent.
• La fraîcheur : à quelle fréquence le corpus est mis à jour, et ce qui arrive aux versions périmées.
• Les doublons et versions concurrentes : la première cause de réponses contradictoires.
• Les documents non textuels : tableaux, scans, présentations, qui se retrouvent souvent illisibles pour le système.

Ces sujets relèvent du métier, pas de la technique. Un business analyst qui cadre correctement le corpus fait plus pour la qualité finale que n'importe quel changement de modèle.

Comprendre les agents sans écrire de code

Un agent est un système qui décide d'une suite d'actions pour atteindre un objectif. Là où un traitement classique suit un chemin défini, un agent choisit son chemin. Cette différence a des conséquences directes sur la spécification, la responsabilité et le contrôle.

• Quelles actions l'agent a-t-il le droit d'exécuter, et lesquelles lui sont explicitement interdites ?
• Quelles actions sont réversibles, lesquelles ne le sont pas ? Ces dernières exigent une validation humaine.
• Que se passe-t-il quand l'agent échoue au milieu d'une séquence : reprise, annulation, alerte ?
• Quelle trace reste-t-il de ce qui a été fait, pour audit ou pour litige ?
• Quelles limites de volume et de coût s'appliquent par exécution ?

Ces questions sont exactement celles que pose une MOA sur n'importe quel workflow. La nouveauté est que le chemin n'est plus connu à l'avance : il faut donc spécifier les bornes plutôt que la séquence.

Cadrer un cas d'usage qui tient debout

Beaucoup de projets échouent avant la première ligne de code, parce que le cas d'usage n'a jamais été formulé de manière évaluable. Un cadrage solide tient en six points, tous formulables par un profil métier.

• La tâche précise : qui fait quoi aujourd'hui, combien de fois par semaine, en combien de temps.
• La sortie attendue : à quoi ressemble une bonne réponse, avec trois exemples réels.
• Les cas limites connus : les situations où l'humain lui-même hésite.
• Le coût d'une erreur : gênante, coûteuse, ou inacceptable — cela détermine tout le niveau de contrôle.
• La donnée disponible : existe-t-elle, est-elle accessible, est-elle à jour, qui l'autorise.
• Le critère d'arrêt : à partir de quel résultat on décide de continuer ou d'abandonner.

Écrire des exigences sur un système non déterministe

L'exigence classique décrit un comportement garanti : dans telle situation, le système fait exactement ceci. Sur un système IA, cette formulation est intenable pour la sortie elle-même. Elle reste parfaitement valable pour tout ce qui entoure la sortie — et c'est là qu'il faut concentrer la spécification.

• Ce qui reste déterministe : droits d'accès, traçabilité, format de sortie, actions autorisées, journalisation.
• Ce qui devient statistique : la pertinence de la réponse, mesurée sur un jeu de cas de référence.
• Ce qui doit être garanti absolument : l'absence d'action irréversible sans validation, le respect des droits, la citation des sources.
• Ce qui doit être conçu explicitement : le comportement en cas de doute, d'absence d'information ou de question hors périmètre.

Formulation utile : « le système doit s'abstenir plutôt que répondre lorsqu'aucune source pertinente n'est trouvée » est une exigence testable. « Le système doit répondre correctement » ne l'est pas.

Constituer le jeu de cas de référence

C'est la contribution la plus concrète et la plus sous-estimée d'un profil MOA sur un projet IA. Le jeu de cas est ce qui permet de dire si le système progresse ou régresse. Personne n'est mieux placé pour le construire : il demande une connaissance fine du métier, pas des compétences techniques.

1. 1

   Collecter des cas réels

   Extraire des demandes historiques — tickets, e-mails, dossiers — plutôt qu'inventer des exemples. Cinquante à cent cas suffisent pour commencer.

2. 2

   Écrire la réponse attendue

   Pour chaque cas, la réponse qu'un bon professionnel donnerait, avec la source qui la justifie.

3. 3

   Couvrir les cas difficiles

   Inclure délibérément des questions ambiguës, des cas sans réponse, des questions hors périmètre et des pièges connus.

4. 4

   Définir ce qui compte comme échec

   Réponse fausse, réponse sans source, réponse hors périmètre traitée comme si elle était valide : préciser la gravité de chaque type.

5. 5

   Faire valider par le métier

   Le jeu de cas engage l'organisation. Il doit être relu et accepté par les responsables du domaine, pas seulement par l'équipe projet.

6. 6

   Le maintenir

   Ajouter les erreurs rencontrées en production. Un jeu de cas figé perd sa valeur en quelques mois.

Mener une recette qui a du sens

La recette traditionnelle valide un comportement attendu, cas par cas, avec un verdict binaire. Sur un système IA, ce format donne une fausse assurance : dix tests réussis ne disent rien du onzième. La recette doit changer de forme sans perdre sa fonction de décision.

• Mesurer un taux sur l'ensemble du jeu de cas plutôt que valider des tests isolés.
• Fixer les seuils avant l'exécution, avec le métier, et distinguer les erreurs tolérables des erreurs bloquantes.
• Tester les cas hors périmètre autant que les cas nominaux : le refus correct est un résultat attendu.
• Vérifier les droits d'accès avec plusieurs profils utilisateurs différents.
• Rejouer le même jeu de cas à chaque évolution : c'est la seule protection contre les régressions silencieuses.

Une régression sur un système IA ne se manifeste pas par une erreur technique. Elle se manifeste par des réponses légèrement moins bonnes, que personne ne remarque avant plusieurs semaines. Le rejeu systématique du jeu de cas est la seule défense.

Données, droits et conformité : la part métier

Sur un projet IA, les questions de données ne sont pas un préalable administratif : elles déterminent la faisabilité. Un profil MOA les traite naturellement, et leur omission est une cause fréquente d'arrêt en fin de projet.

• Quelles données personnelles peuvent entrer dans le système, et sous quelle base légale.
• Quelles données sont confidentielles au point de ne jamais devoir quitter certains périmètres.
• Comment les droits d'accès existants se traduisent dans les réponses du système.
• Combien de temps les échanges sont conservés, et qui peut les consulter.
• Ce qui doit être documenté pour un audit interne ou une exigence réglementaire sectorielle.

Adoption : le vrai facteur de réussite

Un système correct que personne n'utilise est un échec. L'adoption d'un outil IA se heurte à deux réactions opposées et également problématiques : le rejet — « il se trompe, je préfère faire moi-même » — et l'acceptation aveugle — « il l'a dit, donc c'est vrai ». Le travail d'accompagnement consiste à installer un usage lucide entre les deux.

• Expliquer le périmètre réel dès la formation, y compris ce que l'outil ne sait pas faire.
• Montrer des erreurs typiques pendant la démonstration, pas seulement des réussites.
• Donner une consigne claire sur ce qui doit être vérifié systématiquement.
• Mettre en place un canal de signalement simple et l'exploiter visiblement.
• Suivre l'usage réel : fréquence, abandon, corrections apportées aux sorties.

Cas concret : une demande mal spécifiée

Demande initiale reçue par l'équipe projet : « automatiser le traitement des réclamations clients avec de l'IA ». Formulée ainsi, elle est inexploitable — elle ne dit ni quelle partie du traitement, ni sur quelle base, ni ce qui constitue un bon résultat.

Le travail de cadrage la transforme en trois éléments distincts, dont un seul est réellement traitable à court terme :

• Classer la réclamation par motif et par urgence : tâche répétitive, données historiques disponibles, erreur peu coûteuse et corrigeable. Traitable.
• Rédiger un projet de réponse à partir des conditions contractuelles : faisable avec citation des sources et validation humaine systématique, car une réponse fausse engage l'entreprise.
• Décider d'un geste commercial : décision engageante, règles métier variables, arbitrage humain. Hors périmètre — le système peut au mieux préparer les éléments de décision.

Le cadrage précise ensuite : 200 réclamations historiques comme jeu de référence, seuil de 90 % de classement correct sur les motifs principaux, toute réponse rédigée validée avant envoi, traçabilité complète de qui a validé quoi. Ce niveau de précision ne demande aucune compétence de développement — uniquement une méthode d'analyse rigoureuse appliquée à un objet nouveau.

La posture qui fait la différence

Le risque, pour un profil MOA, est de rester dans un rôle de rapporteur : transmettre au métier ce que dit la technique, et à la technique ce que veut le métier. Sur un projet IA, cette position n'apporte plus grand-chose, parce que les deux camps parlent d'un objet qu'ils comprennent mal chacun de son côté.

• Demander à voir des sorties réelles du système, y compris ratées, avant de valider une spécification.
• Refuser un objectif non mesurable et proposer sa reformulation évaluable.
• Porter le jeu de cas de référence comme un livrable métier, pas comme une tâche de test.
• Rendre visible le coût d'une erreur, qui détermine tout le dispositif de contrôle.
• Dire non à un cas d'usage dont la donnée n'existe pas : c'est souvent la contribution la plus utile.

Ce socle ne fait pas de vous un ingénieur IA et ce n'est pas le but. Il fait de vous la personne capable de transformer une intention floue en un système que l'on peut évaluer, contrôler et faire adopter — une compétence dont très peu d'organisations disposent aujourd'hui.

• Cadrage de cas d'usage
• Culture IA
• Adoption