Data, IA & Transformation
Parcours d’entretien — banque, finance et transformation

Comprendre l’IA comme un décideur, pas comme un simple utilisateur.

Ce cours relie les concepts techniques aux décisions métier : choix du bon type de solution, qualité des données, mesure de performance, risques, gouvernance, coûts d’exploitation et création de valeur.

Ce que vous devez savoir faire en entretien

Votre crédibilité repose sur la capacité à relier technologie, risque, processus et résultat économique.

10blocs de connaissances fondamentales
3niveaux : concept, cas métier, décision
12questions de quiz corrigées
6cas d’entretien orientés banque

La trame de réponse qui fonctionne presque toujours

1. Problème métier
2. Données disponibles
3. Solution proportionnée
4. Métrique de succès
5. Risques et contrôles
6. Coût et exploitation
Réflexe d’entretien : ne commencez pas par « on met de l’IA ». Commencez par la décision, la friction ou le coût à améliorer, puis démontrez pourquoi l’IA est — ou n’est pas — l’outil approprié.
1

Automatisation, machine learning et IA générative

Savoir choisir la bonne famille de solution.

Automatisation classique

Une automatisation applique des règles explicites à un processus connu. Le comportement est déterministe : à entrée identique, sortie identique. Exemples : rapprocher deux fichiers avec une clé commune, envoyer une relance lorsque l’échéance est dépassée, exécuter un workflow KYC.

Bon choix lorsque : les règles sont stables, explicables et peu ambiguës.

Machine learning

Le modèle apprend une relation statistique à partir d’exemples. On ne code pas toutes les règles : on optimise des paramètres pour minimiser une erreur. Le résultat est probabiliste.

Exemples bancaires : score de fraude, probabilité de défaut, churn, classification d’une demande, prévision de volumes d’appels.

IA générative

Un modèle génératif produit un nouveau contenu — texte, code, image, synthèse — à partir d’un contexte. Un grand modèle de langage prédit des suites de tokens plausibles. Il peut raisonner en apparence, mais ne garantit ni vérité ni conformité sans contrôles complémentaires.

ApprocheEntréeSortieRisque clé
AutomatisationRègles et données structuréesAction déterministeRègles incomplètes
MLDonnées historiques étiquetées ou nonScore / classe / prévisionBiais, dérive
GenAIInstruction + contexteContenu généréHallucination, fuite de données
Erreur fréquente : appeler « IA » une simple macro ou, inversement, utiliser un LLM pour un calcul déterministe qu’une règle ou une requête SQL ferait mieux, moins cher et plus sûrement.
Réponse d’entretien prête à l’emploi

« Je distingue d’abord les processus à règles stables, que j’automatise de manière déterministe, des décisions nécessitant une estimation statistique, adaptées au machine learning. J’utilise l’IA générative lorsqu’il faut comprendre ou produire du langage non structuré. Mon critère n’est pas la sophistication, mais le meilleur compromis entre valeur, fiabilité, explicabilité et coût d’exploitation. »

2

Cas d’usage : prédire, classer, extraire, générer, rechercher

Reconnaître la nature exacte du problème.

TypeQuestion poséeExemple bancaireMétrique typique
PrédictionQue va-t-il probablement se passer ?Probabilité de défaut à 12 moisMAE, RMSE, AUC, calibration
ClassificationÀ quelle catégorie appartient cet élément ?Fraude / non-fraude ; motif de contactPrécision, rappel, F1
ExtractionQuelles informations sont présentes ?Nom, montant, date et IBAN dans un justificatifExactitude par champ
GénérationQuel contenu peut être produit ?Brouillon de réponse au clientQualité, factualité, conformité
Recherche documentaireQuel passage répond à la question ?Retrouver une clause dans une politique interneRecall@k, précision des sources

Un même besoin peut combiner plusieurs briques

Exemple : traitement d’un dossier de crédit. L’OCR numérise, l’extraction récupère les champs, des règles contrôlent la complétude, un modèle prédit un risque, un moteur documentaire retrouve les procédures, puis un LLM rédige une synthèse sourcée destinée à l’analyste.

La bonne architecture est souvent hybride : règles + modèles spécialisés + GenAI + validation humaine.

Questions de cadrage

  • Quelle décision doit être prise et par qui ?
  • Quel est le coût d’une erreur dans chaque direction ?
  • La donnée est-elle structurée, textuelle, image ou audio ?
  • Faut-il une réponse en temps réel ?
  • Le résultat doit-il être explicable ou opposable ?
  • Existe-t-il une vérité terrain pour mesurer la qualité ?
Piège d’entretien

Une « recherche dans les documents » n’exige pas toujours un LLM. Une recherche plein texte ou un moteur sémantique peut suffire. La génération n’est utile que si l’on veut reformuler ou synthétiser les passages retrouvés.

3

Données d’entraînement, validation et test

Mesurer la capacité de généralisation sans se tromper soi-même.

Rôle des trois jeux

  • Train : ajuster les paramètres du modèle.
  • Validation : choisir les hyperparamètres, le seuil, les variables et comparer les versions.
  • Test : estimer une seule fois la performance finale sur des données jamais utilisées.
Historique
Train 60–80 %
Validation 10–20 %
Modèle figé
Test 10–20 %
Estimation finale

Data leakage : le danger majeur

Une fuite de données survient lorsqu’une information indisponible au moment réel de la décision apparaît dans l’entraînement. Exemple : utiliser la date de clôture d’un dossier pour prédire s’il sera accepté.

Un modèle peut afficher 98 % de performance en laboratoire et échouer en production si le découpage est incorrect.

Dans le temps

Pour un cas bancaire, un split chronologique est souvent plus réaliste qu’un split aléatoire : entraîner sur les mois passés et tester sur une période future. On simule ainsi le déploiement réel et la dérive.

ProblèmeSymptômeRemède
SurapprentissageExcellent sur train, faible sur validationRégularisation, simplification, plus de données
Échantillon non représentatifPerformance différente selon agence ou segmentStratification, analyse par sous-population
Labels faiblesLes « vraies réponses » sont elles-mêmes contestablesGuide d’annotation, double revue, arbitrage
Classes déséquilibrées99,8 % de non-fraudesSeuil, pondération, métriques adaptées
Réponse d’entretien prête à l’emploi

« Je sépare strictement l’apprentissage, la sélection du modèle et l’évaluation finale. Pour un phénomène temporel, j’utilise un découpage chronologique afin d’éviter qu’une information future contamine le passé. J’analyse aussi la qualité des labels, la représentativité des segments et les performances par sous-population, pas seulement la moyenne. »

4

Précision, rappel, faux positifs et faux négatifs

Traduire une performance statistique en coût métier.

Matrice de confusion

Réel positifRéel négatif
Prédit positifVrai positif (TP)Faux positif (FP)
Prédit négatifFaux négatif (FN)Vrai négatif (TN)
Précision = TP / (TP + FP) Rappel = TP / (TP + FN) F1 = 2 × précision × rappel / (précision + rappel)

Interprétation métier

Précision élevée : quand le modèle alerte, il a souvent raison.

Rappel élevé : le modèle retrouve la majorité des cas réellement positifs.

Pour la fraude, un faux négatif laisse passer une fraude ; un faux positif bloque un client légitime. Le bon seuil dépend donc du montant, du canal, du segment client et de la capacité des équipes de revue.

Il n’existe pas de « meilleur seuil » universel. Le seuil transforme un score probabiliste en décision et matérialise un arbitrage économique et opérationnel.

Exemple chiffré

Sur 100 000 paiements, 200 sont frauduleux. Le modèle détecte 160 fraudes et génère 640 alertes injustifiées. Le rappel vaut 160/200 = 80 %. La précision vaut 160/(160+640) = 20 %. La faible précision peut rester acceptable si la revue est peu coûteuse et si le montant des fraudes évitées est élevé.

Question classique : « précision ou rappel ? »

« Cela dépend du coût relatif des erreurs. Pour un contrôle de fraude à fort enjeu, je chercherais un rappel élevé, tout en limitant les faux positifs pour ne pas dégrader le parcours client et saturer les analystes. Je choisirais le seuil à partir d’une courbe coût-bénéfice et de la capacité opérationnelle, puis je suivrais ces métriques en production. »

5

RAG — Retrieval-Augmented Generation

Faire répondre un LLM à partir d’un corpus maîtrisé.

Le RAG enrichit la requête adressée au modèle avec des passages retrouvés dans une base documentaire. Il ne réentraîne pas nécessairement le LLM. Il construit un contexte spécifique à la question.

Question utilisateur
Recherche de passages
Contexte + instruction
Réponse sourcée

Chaîne d’ingestion

  1. Collecte et contrôle des documents.
  2. Découpage en segments ou chunks.
  3. Création d’embeddings ou index lexical.
  4. Stockage avec métadonnées et droits d’accès.
  5. Indexation et mise à jour.

Chaîne de réponse

  1. Comprendre ou reformuler la requête.
  2. Récupérer les passages les plus pertinents.
  3. Éventuellement reranker les résultats.
  4. Générer à partir des sources autorisées.
  5. Afficher citations et niveau de confiance.

Ce que le RAG ne résout pas automatiquement

  • Document obsolète ou contradictoire.
  • Mauvais découpage des contenus.
  • Droits d’accès insuffisamment propagés.
  • Question nécessitant un calcul ou une base transactionnelle.
  • Hallucination malgré des sources correctes.
Le contrôle d’accès doit s’appliquer avant la génération. Un document interdit ne doit jamais être placé dans le contexte du modèle, même si l’interface masque ensuite la citation.

Mesurer un RAG

CoucheQuestionMesure
RetrievalLe bon passage est-il dans les k premiers ?Recall@k, MRR, nDCG
GénérationLa réponse est-elle fidèle aux passages ?Factualité, groundedness
ProduitL’utilisateur résout-il son problème ?Taux de succès, temps gagné, escalades
RisqueLes droits et données sensibles sont-ils respectés ?Tests d’accès, audits, incidents
Réponse d’entretien prête à l’emploi

« Un RAG sépare la connaissance documentaire du modèle génératif. J’évalue d’abord le retrieval, car un LLM ne peut pas produire une réponse fiable si le bon passage n’est pas remonté. J’impose ensuite des citations, des règles d’abstention et une propagation des habilitations documentaires jusqu’au moteur de recherche. »

6

Human-in-the-loop

Conserver une supervision humaine là où elle crée réellement de la sécurité.

Le human-in-the-loop (HITL) signifie qu’un humain intervient dans la boucle de décision : validation, correction, arbitrage, annotation ou gestion des cas incertains.

Trois modèles d’exploitation

  • Human in the loop : chaque décision sensible est validée.
  • Human on the loop : l’humain supervise et peut reprendre la main.
  • Human out of the loop : traitement entièrement automatisé dans un périmètre maîtrisé.

Quand imposer une revue ?

  • Faible confiance du modèle.
  • Montant ou conséquence élevée.
  • Décision réglementée ou contestable.
  • Nouveau segment peu représenté.
  • Conflit entre règle métier et modèle.
  • Détection d’une anomalie ou d’un drift.
Une validation humaine n’est pas automatiquement efficace. Si l’analyste clique « approuver » par habitude, le dispositif crée une illusion de contrôle. Il faut mesurer le taux de correction, le temps de revue et les désaccords.

Conception pratique

ÉlémentBonne pratique
Seuil d’escaladeFondé sur risque, confiance et capacité opérationnelle
InterfacePrésenter sources, facteurs clés et options de correction
TraçabilitéConserver prédiction, données, version, décision humaine et motif
ApprentissageRéutiliser les corrections après contrôle qualité, pas automatiquement
Formulation utile en entretien

« Je ne place pas un humain dans la boucle uniquement pour rassurer. Je définis précisément les cas à escalader, les informations fournies au décideur, la responsabilité finale et la manière dont les corrections sont capitalisées. Je vérifie ensuite que la revue humaine modifie réellement les décisions lorsque c’est nécessaire. »

7

Monitoring et dérive

Un modèle en production est un service vivant, pas un livrable figé.

Type de dériveDéfinitionExemple
Data driftLa distribution des entrées changePlus de paiements mobiles qu’à l’entraînement
Concept driftLa relation entre entrées et cible changeNouveau mode opératoire de fraude
Label driftLa proportion des classes changeHausse du taux de défaut
Model driftLa performance observée se dégradeBaisse du rappel des fraudes

Quatre niveaux de monitoring

  1. Technique : disponibilité, erreurs, latence, débit.
  2. Données : schéma, valeurs manquantes, distributions.
  3. Modèle : score, calibration, métriques par segment.
  4. Métier : fraude évitée, temps gagné, satisfaction, coût.

Pour un LLM / RAG

  • Taux d’abstention et réponses sans source.
  • Documents les plus utilisés et requêtes sans résultat.
  • Violations de garde-fous.
  • Coût et nombre de tokens.
  • Latence par étape : retrieval, modèle, outils.
  • Évaluations humaines régulières.
Un bon tableau de bord relie une alerte technique à un impact métier et à une action : observer, investiguer, ajuster le seuil, revenir à la version précédente, réentraîner ou suspendre.
Question classique : « quand réentraîner ? »

« Je ne réentraîne pas uniquement selon un calendrier. Je définis des déclencheurs : dérive significative, baisse de performance, évolution réglementaire, changement de produit ou accumulation suffisante de nouveaux labels. Le nouveau modèle repasse alors par validation, comparaison avec le champion et procédure de déploiement contrôlé. »

8

Confidentialité et contrôle d’accès

Protéger la donnée tout au long du cycle de vie.

Questions de sécurité à poser

  • Quelles données entrent dans le système ?
  • Où sont-elles stockées et pendant combien de temps ?
  • Sont-elles utilisées pour entraîner un fournisseur tiers ?
  • Qui peut voir les prompts, réponses, logs et documents ?
  • Comment les droits sont-ils révoqués ?
  • Comment gérer export, suppression et incident ?

Principes structurants

Minimisation Moindre privilège Need-to-know Chiffrement Séparation des environnements Traçabilité Pseudonymisation Rétention limitée

Contrôles par couche

CoucheContrôles
IdentitéSSO, MFA, rôles, groupes, revues d’habilitation
DonnéesClassification, masquage, chiffrement, DLP
ApplicationPermissions par fonction, validation d’entrée, rate limit
RAGFiltrage par ACL au retrieval, métadonnées de sécurité
LogsAccès restreint, rétention, redaction des secrets
FournisseurContrat, localisation, sous-traitants, isolation, audit
Ne jamais confondre « modèle privé » et « usage sécurisé ». La sécurité dépend de l’ensemble de la chaîne : identité, données, connecteurs, prompts, logs, stockage, fournisseurs et processus humain.
Réponse d’entretien prête à l’emploi

« J’applique la minimisation des données et le moindre privilège. Pour un assistant documentaire, je propage les habilitations de la source jusqu’au retrieval, je contrôle la rétention des prompts et des logs, et je vérifie contractuellement que les données ne servent pas à entraîner un service tiers sans autorisation. »

9

Gouvernance des modèles

Organiser la responsabilité, la validation et la traçabilité.

La gouvernance répond à six questions : quel modèle existe, à quoi sert-il, qui en est responsable, sur quelles données repose-t-il, comment a-t-il été validé et comment est-il surveillé.

Cycle de gouvernance

  1. Qualification du cas d’usage et niveau de risque.
  2. Enregistrement dans un inventaire.
  3. Documentation des données, hypothèses et limites.
  4. Validation indépendante proportionnée au risque.
  5. Approbation et mise en production contrôlée.
  6. Monitoring, revue périodique et retrait.

Rôles typiques

  • Business owner : valeur et usage.
  • Model owner : performance et cycle de vie.
  • Data owner : qualité et droits.
  • IT / MLOps : exploitation et sécurité.
  • Validation indépendante : challenge méthodologique.
  • Risk / Compliance / Legal : exigences et contrôles.

Artefacts à connaître

ArtefactContenu minimal
Model cardObjectif, données, performance, limites, usages interdits
Data sheetOrigine, qualité, représentativité, transformations, rétention
Journal de versionsCode, paramètres, environnement, date, approbation
Plan de monitoringMétriques, seuils, fréquence, responsabilités, actions
Plan de continuitéMode dégradé, rollback, arrêt d’urgence, reprise manuelle
La gouvernance doit être proportionnée : un générateur de compte rendu interne n’est pas traité comme un modèle affectant une décision de crédit, mais aucun modèle ne doit être totalement hors inventaire.
Réponse d’entretien prête à l’emploi

« Je mets en place une gouvernance proportionnée au risque avec un owner métier, un owner modèle, un inventaire, une documentation standard, une validation indépendante pour les usages sensibles et des critères explicites de surveillance, de rollback et de retrait. »

10

Business case et coût d’exploitation

Passer du démonstrateur séduisant au service économiquement viable.

Valeur potentielle

  • Temps opérationnel économisé.
  • Réduction d’erreurs ou de pertes.
  • Hausse de conversion ou rétention.
  • Réduction du délai de traitement.
  • Capacité supplémentaire sans recrutement.
  • Réduction du risque ou meilleure conformité.

Coût total de possession

  • Licences, API, tokens, GPU et stockage.
  • Intégration, sécurité et connecteurs.
  • Nettoyage et mise à jour des données.
  • Évaluation, validation et gouvernance.
  • Monitoring, support, incidents et réentraînement.
  • Conduite du changement et formation.
Valeur nette annuelle = (gain de productivité + pertes évitées + revenus additionnels) − (coûts variables + coûts fixes + coût des erreurs résiduelles)

De la preuve de concept à l’échelle

ÉtapeQuestion décisionnellePreuve attendue
ExplorationLe problème mérite-t-il d’être résolu ?Volume, douleur, sponsor
PrototypeLa technologie peut-elle fonctionner ?Résultats sur échantillon
PiloteLe processus complet crée-t-il de la valeur ?KPI métier et adoption
IndustrialisationLe service est-il robuste et gouverné ?SLA, sécurité, coûts, runbook
ScaleLa valeur reste-t-elle positive avec le volume ?Économie unitaire et capacité
Un gain théorique de 10 minutes n’est pas une économie réelle si le temps libéré n’est pas réalloué, si les utilisateurs refont le travail ou si une revue manuelle absorbe le bénéfice.
Réponse d’entretien prête à l’emploi

« Je chiffre un business case sur le flux réellement automatisable, le taux d’adoption, le temps net gagné, le coût des erreurs et le coût du run. Je distingue les coûts fixes d’intégration des coûts variables par transaction. Je valide la valeur sur un pilote instrumenté avant de généraliser. »

Outils pratiques

Manipulez les métriques et le business case plutôt que de les apprendre passivement.

Calculateur de matrice de confusion

Calculateur de business case

Mini-simulateur RAG

Cette simulation illustre la chaîne de traitement ; elle n’appelle aucun modèle externe.

Choisissez une question puis lancez la simulation.

Quiz de validation

Objectif recommandé : au moins 10 bonnes réponses sur 12.

Cas d’entretien

Répondez à voix haute en 90 secondes avant d’afficher la correction.

1. Assistant documentaire conformité

La conformité veut un chatbot répondant aux procédures internes. Comment cadrez-vous le projet ?

  1. Définir population, décisions couvertes et usages interdits.
  2. Qualifier corpus, propriétaires, fraîcheur et habilitations.
  3. Construire un RAG avec citations et abstention.
  4. Tester retrieval et factualité sur un jeu de questions représentatif.
  5. Prévoir escalation vers un expert, logs et monitoring.
  6. Mesurer temps de recherche, taux de résolution et erreurs critiques.

2. Détection de fraude

Le modèle bloque trop de clients légitimes. Que faites-vous ?

  1. Analyser précision, rappel et faux positifs par segment.
  2. Vérifier dérive, qualité des données et nouvelles règles de fraude.
  3. Simuler différents seuils avec coût de fraude et coût client.
  4. Créer des seuils différenciés selon montant, canal et profil.
  5. Ajouter une étape de confirmation ou revue pour les cas intermédiaires.
  6. Déployer progressivement et mesurer l’impact opérationnel.

3. Génération d’e-mails clients

Le métier veut automatiser les réponses aux réclamations. Quel niveau d’autonomie ?

Commencer par un copilote générant un brouillon à partir de motifs, historique autorisé et base de réponses. Imposer validation humaine pour les réclamations sensibles, les gestes commerciaux et les mentions réglementaires. Mesurer temps net gagné, taux de modification, erreurs, satisfaction et escalades avant toute automatisation complète.

4. PoC performant, mais pas d’adoption

Le modèle fonctionne techniquement, pourtant les équipes ne l’utilisent pas. Pourquoi ?

Examiner l’intégration au workflow, la confiance, l’ergonomie, les temps de réponse, les incitations et la clarté de la responsabilité. Comparer la métrique du PoC avec le KPI métier réel. Impliquer des utilisateurs pilotes, instrumenter les abandons et traiter les causes avant de conclure que « le changement est culturel ».

5. Réutilisation de données clients

Une équipe souhaite entraîner un modèle sur des conversations clients. Quels contrôles ?

Vérifier finalité, base légale, minimisation, information, rétention, localisation et droits. Pseudonymiser ou supprimer les données inutiles, contrôler l’accès, séparer les environnements, auditer le fournisseur et documenter les usages autorisés. Prévoir des tests de mémorisation et une procédure de suppression.

6. Prioriser trois cas d’usage

Comment arbitrer entre valeur, faisabilité et risque ?

Utiliser une matrice : impact économique, volume, qualité des données, complexité d’intégration, exposition réglementaire, coût d’erreur, délai de mise en œuvre et sponsor métier. Privilégier un cas à valeur mesurable, périmètre maîtrisé et données accessibles, sans sélectionner uniquement le cas le plus spectaculaire.

Flashcards

Cliquez sur une carte pour afficher la réponse.

Précision
Parmi les éléments prédits positifs, quelle proportion est réellement positive ? TP / (TP + FP)
Rappel
Parmi les éléments réellement positifs, quelle proportion le modèle retrouve-t-il ? TP / (TP + FN)
Data drift
Changement de la distribution des données d’entrée par rapport à la référence.
Concept drift
Changement de la relation entre les variables d’entrée et la cible à prédire.
RAG
Recherche de passages pertinents, ajout au contexte, puis génération d’une réponse idéalement sourcée.
Human-on-the-loop
Le système agit automatiquement, mais un humain supervise, reçoit des alertes et peut reprendre la main.
Data leakage
Utilisation d’une information indisponible au moment réel de la décision, créant une performance artificielle.
Model card
Document décrivant objectif, données, performances, limites, risques et usages interdits d’un modèle.
TCO
Coût total de possession : build, licences, données, intégration, sécurité, run, monitoring, support et retrait.

Plan de crédibilisation en 30 jours

Produire des preuves concrètes plutôt que réciter du vocabulaire.

Semaine 1 — Fondamentaux

Semaine 2 — Mini-projet

Semaines 3–4 — Entretien

Projet portfolio recommandé

Construisez un assistant documentaire sur un corpus public de rapports annuels, procédures ou documents réglementaires. Livrez : architecture, jeu d’évaluation, résultats, analyse des erreurs, matrice de risques, règles d’accès simulées, tableau de monitoring et business case. Ce livrable démontre simultanément produit, data, IA, gouvernance et transformation.

En entretien, présentez ce projet comme une décision de produit : problème, utilisateurs, données, architecture, métriques, risques, coût, résultats et prochaines étapes.

Glossaire essentiel

Les termes à utiliser avec précision.

Embedding
Représentation numérique d’un contenu dans un espace où la proximité reflète une similarité.
Chunk
Segment de document indexé et récupéré par le moteur de recherche.
Fine-tuning
Ajustement des paramètres d’un modèle sur des exemples spécifiques ; différent du RAG.
Prompt injection
Instruction malveillante visant à détourner le comportement du modèle ou révéler des données.
Hallucination
Réponse plausible mais non fondée ou incorrecte produite par un modèle génératif.
Calibration
Correspondance entre score prédit et fréquence réelle. Un score de 0,8 devrait se vérifier environ 80 % du temps.
Champion / challenger
Comparaison du modèle en production avec un candidat alternatif avant remplacement.
Feature
Variable utilisée par un modèle pour produire une prédiction.
Ground truth
Référence considérée comme vraie pour entraîner ou évaluer.
Guardrail
Contrôle limitant les entrées, sorties ou actions autorisées d’un système d’IA.
Latency
Temps de réponse total du service, souvent critique pour l’adoption.
Model registry
Référentiel des versions, métadonnées, statuts et approbations des modèles.