En bref
- Dans un projet IA, le Business Analyst ne spécifie plus un comportement exact : il définit un niveau de qualité mesurable, car l’IA est probabiliste.
- Ses livrables clés deviennent le processus to-be avec supervision humaine, le jeu d’évaluation et les critères d’acceptation en taux.
- Le gain se mesure sur le processus complet, vérification humaine comprise, pas sur la tâche de l’IA seule.
- En Europe, l’AI Act classe certains usages en haut risque (crédit, assurance vie et santé, RH, prestations publiques) : le BA doit qualifier le cas d’usage dès le cadrage.
Qu’est-ce qui change pour un Business Analyst dans un projet IA ?
Réponse courte : le métier de base reste le même (comprendre le besoin, modéliser le processus, rédiger des exigences, accompagner la recette), mais l’IA donne des réponses probables et non certaines. Le BA doit donc raisonner en taux de qualité, en supervision humaine et en suivi dans le temps.
| Sujet | Projet classique | Projet avec IA |
|---|---|---|
| Comportement | Même entrée, même sortie | Sortie probable, parfois variable d’un appel à l’autre |
| Exigence | « Le système calcule le bon montant » | « Le montant est exact dans au moins 95 % des cas du jeu d’évaluation » |
| Recette | Cas de test réussis ou échoués | Taux mesuré sur un jeu fixe, par segment |
| Rôle de l’humain | Utilise le système | Supervise, valide, corrige, reprend la main |
| Après la mise en production | Le système fonctionne ou est en panne | La qualité peut baisser sans aucune erreur visible (dérive) |
| Données | Entrées du traitement | Elles déterminent aussi la qualité et les biais du résultat |
Les 6 étapes d’un projet IA vues par le Business Analyst
Réponse courte : cadrer, évaluer la faisabilité, concevoir le processus, définir et mesurer la qualité, déployer sous contrôle, puis suivre dans le temps. Chaque étape se termine par une décision explicite de continuer ou non.
Cadrer : le problème mérite-t-il de l’IA ?
Une règle simple, un formulaire ou une refonte du processus ne suffiraient-ils pas ?
- Décrire le besoin métier et la valeur attendue (temps, coût, qualité).
- Chiffrer la situation actuelle : volumes, délais, taux d’erreur.
- Choisir entre IA, règle, évolution du processus ou approche hybride.
Livrables : fiche d’opportunité chiffrée, verdict IA / règle / hybride.
Évaluer la faisabilité : processus, données, réglementation
Le processus est-il maîtrisé, les données disponibles et l’usage autorisé ?
- Vérifier que le processus est documenté, stable et a un propriétaire.
- Identifier la source qui fait foi pour chaque donnée, sa qualité et ses droits d’accès.
- Classer le cas d’usage selon l’AI Act et repérer les analyses d’impact nécessaires.
Livrables : analyse de faisabilité, fiche de classification réglementaire.
Concevoir : intégrer l’IA dans le processus
Où intervient l’IA, où l’humain reste-t-il en contrôle, que se passe-t-il en cas de doute ?
- Modéliser le processus as-is et to-be (par exemple en BPMN) en distinguant tâches IA, tâches humaines et règles.
- Définir la supervision humaine, le seuil de confiance et le chemin d’escalade.
- Prévoir le mode dégradé quand l’IA est indisponible.
Livrables : processus to-be, exigences fonctionnelles, matrice de supervision.
Évaluer : définir ce que « suffisamment bon » signifie
Comment saura-t-on que la solution est prête ?
- Définir la vérité terrain avec les experts métier.
- Constituer un jeu d’évaluation représentatif, avec cas limites et cas où l’IA doit refuser de répondre.
- Rédiger des critères d’acceptation en taux, par segment et par groupe de personnes.
Livrables : jeu d’évaluation, critères d’acceptation IA, rapport de recette.
Déployer : mettre en service sous contrôle
Les utilisateurs savent-ils quand faire confiance à l’IA et quand la contredire ?
- Mettre à jour procédures et rôles (propriétaire du processus, superviseurs).
- Former aux limites du système et au biais d’automatisation.
- Prévoir la journalisation et l’explication due aux personnes concernées.
Livrables : plan de déploiement, procédures, supports de formation.
Opérer : vérifier que la solution reste bonne dans le temps
Qui s’aperçoit que la qualité baisse, et que fait-on alors ?
- Suivre des indicateurs de qualité, pas seulement de disponibilité.
- Détecter la dérive : nouvelles données, nouvelles règles métier, changement de modèle chez le fournisseur.
- Repasser le jeu d’évaluation à chaque changement.
Livrables : tableau de bord qualité, revues périodiques.
Les 15 notions IA qu’un Business Analyst doit maîtriser
Réponse courte : pas besoin de savoir coder, mais il faut comprendre ces notions pour poser les bonnes questions et rédiger des exigences testables.
| Notion | Définition simple | Ce que fait le BA |
|---|---|---|
| Use case fit | Le problème convient-il à l’IA, ou une règle fait-elle mieux ? | Qualifie et chiffre le besoin avant toute solution |
| Déterministe vs probabiliste | Une règle donne toujours la même réponse ; un modèle donne une réponse probable | Garde déterministes les calculs et règles légales |
| Human in the loop | Un humain valide ou corrige avant que la sortie ait un effet | Définit qui valide quoi, en combien de temps |
| Ground truth (vérité terrain) | La bonne réponse vérifiée, servant de référence | Identifie qui la connaît et écrit les règles d’étiquetage |
| Jeu d’évaluation | Ensemble fixe de cas de test repassé à chaque changement | Le constitue avec des cas fréquents, rares et pièges |
| Hallucination | Réponse fausse ou inventée, présentée avec assurance | Prévoit des questions sans réponse dans les sources |
| RAG | L’IA répond à partir de documents retrouvés dans une base | Identifie les sources qui font foi et leurs droits d’accès |
| Prompt template | Instruction réutilisable et versionnée | La relit comme une spécification |
| Guardrail (garde-fou) | Contrôle qui bloque ou signale une entrée ou une sortie hors limites | Liste ce que l’IA ne doit jamais dire ni faire |
| Seuil de confiance | Niveau sous lequel la sortie part chez un humain | Fait choisir le seuil par le métier sur données mesurées |
| Data lineage | D’où vient chaque donnée et comment elle a été transformée | Cartographie les flux et les propriétaires |
| Model drift (dérive) | Baisse de qualité dans le temps, sans modification volontaire | Définit les indicateurs et seuils d’alerte |
| Critères d’acceptation IA | Exigences exprimées en taux sur un jeu d’évaluation | Les rédige, par segment et par groupe |
| Chemin d’escalade | Qui reprend la main quand l’IA ne peut pas décider | Le modélise, mode dégradé compris |
| Effort total du processus | Temps gagné moins temps ajouté pour vérifier et corriger | Mesure le gain sur le processus complet |
À connaître aussi : biais et équité, explicabilité, précision et rappel, fenêtre de contexte, agents IA, prompt injection.
Comment rédiger un critère d’acceptation pour une IA ?
Réponse courte : en taux mesuré sur un jeu d’évaluation fixe, jamais en réussite d’un cas unique. Un bon critère contient une métrique, un seuil, le jeu de mesure, un découpage par segment et les erreurs à tolérance zéro.
| ID | AI-AC-014 |
|---|---|
| Objectif | Router correctement les demandes entrantes vers le bon service |
| Métrique | ≥ 95 % de bonnes réponses |
| Jeu d’évaluation | 300 cas réels, anonymisés et représentatifs |
| Segmentation | Français et néerlandais mesurés séparément |
| Cas critiques | 0 erreur tolérée : ces cas sont toujours escaladés |
Trois pièges à éviter
- Le taux global qui cache un segment défaillant : 95 % en moyenne peut cacher 70 % sur une langue ou un type de dossier.
- L’exactitude sur des classes déséquilibrées : avec 2 % de fraude, un système qui ne détecte jamais rien affiche 98 % d’exactitude. On mesure alors la précision et le rappel.
- Optimiser sur le jeu d’évaluation : si l’on ajuste le prompt en regardant les cas de test, ceux-ci ne mesurent plus rien.
Comment mesurer le gain réel d’une IA ?
Réponse courte : sur le processus complet. Le temps gagné par l’IA doit être diminué du temps ajouté pour vérifier, corriger et gérer les escalades.
Gain réel = temps avant − (temps IA + vérification + reprises)
Exemple : un dossier traité en 12 minutes passe à 2 minutes de traitement IA, 6 minutes de vérification humaine et 1 minute de reprises, soit 9 minutes. Le gain réel est de 3 minutes par dossier (−25 %), et non de 10 minutes comme le suggérerait le temps de l’IA seule.
Il faut aussi intégrer les coûts cachés : maintenance du jeu d’évaluation, surveillance, formation, licences et conformité, ainsi que le coût d’une erreur qui passe à travers les contrôles.
Ce que l’AI Act et la réglementation imposent au projet
Réponse courte : le niveau d’obligation dépend de l’usage. Le BA doit classer le cas d’usage dès le cadrage : un assistant de rédaction n’a presque aucune contrainte, une décision de crédit ou d’aide sociale en a beaucoup.
L’AI Act (Règlement (UE) 2024/1689) distingue quatre niveaux : pratiques interdites, haut risque, obligations de transparence (par exemple un chatbot) et risque minimal. Depuis le 27 juillet 2026, le Digital Omnibus (Règlement 2026/1744) reporte au 2 décembre 2027 les obligations des systèmes haut risque de l’Annexe III. Les interdictions, l’obligation de maîtrise de l’IA pour le personnel (article 4, en vigueur depuis février 2025) et la plupart des obligations de transparence ne sont pas reportées.
| Secteur | Exemples d’usages haut risque (Annexe III) | Exemples en général hors haut risque |
|---|---|---|
| Banque | Évaluation de solvabilité et credit scoring de personnes physiques | Détection de fraude financière (exclue explicitement), assistants internes |
| Assurance | Évaluation des risques et tarification en assurance vie et santé | Tarification non-vie, gestion de sinistres, service client |
| Secteur public | Éligibilité, octroi ou récupération de prestations d’aide publique | Assistant de rédaction, résumé de dossiers |
| Ressources humaines | Recrutement, tri de CV, évaluation, promotion | Planification, FAQ interne |
Les obligations qui touchent directement le travail du BA
- Supervision humaine effective (article 14) : la personne qui supervise doit comprendre les limites du système et pouvoir l’ignorer ou l’arrêter.
- Gouvernance des données (article 10) : données pertinentes, représentatives et examinées pour les biais.
- Analyse d’impact sur les droits fondamentaux (article 27) : obligatoire avant déploiement pour les organismes publics, les entités privées fournissant des services publics, et les déployeurs de credit scoring ou de tarification vie et santé.
- RGPD : l’article 22 encadre les décisions entièrement automatisées ayant des effets juridiques ou similaires.
Les régulateurs sectoriels ajoutent leurs propres attentes, par exemple l’avis de l’EIOPA d’août 2025 sur la gouvernance de l’IA en assurance. Ce guide n’est pas un avis juridique : la classification d’un cas d’usage se valide avec la conformité.
Les erreurs fréquentes d’un BA sur un projet IA
- Partir de la technologie (« il nous faut un cas d’usage GenAI ») au lieu du problème métier.
- Automatiser un processus instable : l’IA reproduit alors ses défauts à plus grande échelle.
- Prendre les décisions passées pour la vérité : elles contiennent les erreurs et les biais des décideurs.
- Une validation humaine de façade : un relecteur qui traite 300 cas par jour ne relit plus rien.
- Mesurer le gain sur la tâche et non sur le processus complet.
- Considérer le projet terminé à la mise en production alors que la qualité peut dériver en silence.
Checklist du Business Analyst pour un projet IA
- Le besoin justifie-t-il vraiment l’IA, plutôt qu’une règle simple ?
- La situation actuelle est-elle chiffrée (temps, volumes, erreurs) ?
- Le cas d’usage est-il classé selon l’AI Act, avec les analyses d’impact nécessaires ?
- Sait-on quelle est la bonne réponse, et qui peut la confirmer ?
- Les données et documents utilisés sont-ils à jour et correctement protégés ?
- Le processus to-be montre-t-il où intervient l’humain et où passe l’escalade ?
- Existe-t-il un jeu d’évaluation fixe, avec des cas difficiles ?
- Les critères d’acceptation sont-ils chiffrés, par segment et par groupe ?
- Le superviseur a-t-il le temps, la compétence et le pouvoir de dire non ?
- Peut-on expliquer une décision à la personne concernée ?
- Quelqu’un suit-il la qualité après la mise en production ?
- Le gain est-il mesuré sur le processus complet ?
Questions fréquentes
Quel est le rôle d’un Business Analyst dans un projet IA ?
Le Business Analyst vérifie que l’IA répond à un vrai besoin, l’intègre dans le processus métier, définit ce que « suffisamment bon » signifie en chiffres et organise le contrôle humain. Il traduit un système probabiliste en exigences vérifiables.
Faut-il savoir coder pour être Business Analyst sur un projet IA ?
Non. Il faut comprendre le fonctionnement général de l’IA (probabiliste, RAG, hallucinations, dérive) pour poser les bonnes questions et rédiger des exigences testables, mais la construction reste le travail de l’équipe technique.
Comment rédiger un critère d’acceptation pour une IA ?
Un critère d’acceptation IA s’exprime en taux mesuré sur un jeu d’évaluation fixe : une métrique, un seuil, le jeu de mesure, un découpage par segment et la liste des erreurs à tolérance zéro. Exemple : au moins 95 % de bonnes réponses sur 300 cas réels, mesurés séparément en français et en néerlandais.
Qu’est-ce qu’un jeu d’évaluation ?
C’est un ensemble fixe de cas de test avec leur bonne réponse, repassé à chaque changement de prompt, de modèle ou de données. C’est l’équivalent IA d’une suite de tests de non-régression.
Quand les obligations haut risque de l’AI Act s’appliquent-elles ?
Depuis l’entrée en vigueur du Digital Omnibus (Règlement 2026/1744) le 27 juillet 2026, les obligations pour les systèmes haut risque de l’Annexe III s’appliquent à partir du 2 décembre 2027. Les pratiques interdites, l’obligation de maîtrise de l’IA et la plupart des obligations de transparence ne sont pas reportées.
Comment mesurer le gain réel d’une IA ?
On compare le temps du processus complet avant et après, en incluant le temps de vérification humaine, de correction et d’escalade. Un traitement qui passe de 12 à 9 minutes par dossier, vérification comprise, fait gagner 3 minutes, soit 25 %, même si l’IA seule ne prend que 2 minutes.
Mathieu Romain, Lead Business & Functional Analyst, plus de 13 ans d’expérience, principalement en assurance vie et non-vie.
Certifié IREB (ingénierie des exigences). Ce guide synthétise les bonnes pratiques publiques et le cadre réglementaire européen ; il ne remplace pas un avis juridique.
Sources
- Règlement (UE) 2024/1689, AI Act, EUR-Lex
- AI Act Service Desk (Commission européenne), Annexe III
- AI Act Service Desk, Article 27
- National Law Review, entrée en vigueur du Digital Omnibus
- EIOPA, Opinion on AI governance and risk management (août 2025)
Un projet IA à cadrer ?
J’accompagne les équipes sur l’analyse métier, la conception du processus et la définition d’exigences vérifiables.
Me contacter