IA dans la banque : les cas d'usage qui passent en production (et ceux qui restent en POC)

On nous appelle beaucoup, en ce moment, depuis le quai du Mont-Blanc et la Paradeplatz. Le discours est presque toujours le même : « On a fait des POC d'IA en 2025, c'était impressionnant en démo, rien n'est en production. » Et derrière, une question plus dure, rarement formulée : est-ce que l'IA dans la banque, c'est du marketing de fournisseur, ou est-ce qu'il y a vraiment des choses qui tournent ?

Réponse courte : il y a des choses qui tournent. Pas celles qu'on croit, pas partout, et jamais sans une couche de discipline que les démos ne montrent pas. Cet article fait le tri. Quels cas d'usage IA passent en production dans la banque — surtout la banque privée et la gestion de fortune — et lesquels restent coincés au stade du prototype, par fonction, avec les contraintes réelles et des chiffres en CHF.

C'est un état des lieux de terrain, pas un livre blanc. On ne vous vendra pas l'agent autonome qui gère le portefeuille à votre place. On vous dira ce qu'on a câblé, ce qui passe l'audit, et ce qui ne le passe pas.

Pourquoi la banque est un terrain IA à très fort potentiel — et ultra-contraint

La banque, et la banque privée en particulier, est une cible idéale pour l'IA générative. La matière première, c'est du texte : notes de marché, comptes rendus de RDV, documents KYC, réglementation, recherche, correspondance client. Des volumes énormes, de la valeur ajoutée à forte densité, des collaborateurs chers dont une part substantielle du temps part en tâches de rédaction, de synthèse et de recherche documentaire. Sur le papier, le ROI est évident.

Sauf que c'est aussi l'un des environnements les plus contraints qui soient. Quatre verrous, qu'aucune démo ne mentionne :

• Le secret bancaire. En Suisse, les données client identifiantes ne se baladent pas chez un fournisseur de modèle américain. Ce n'est pas une préférence, c'est l'art. 47 LB. Cela conditionne tout l'hébergement.
• La supervision prudentielle. La FINMA n'a pas de circulaire IA dédiée, mais traite l'IA comme un risque opérationnel et de modèle — gouvernance, maîtrise des prestataires tiers, résilience. Côté France, l'ACPR pousse dans le même sens. On a détaillé ce que les auditeurs demandent vraiment dans notre cartographie souveraineté FINMA 2026.
• La traçabilité. Une réponse IA non auditable n'a pas sa place en production bancaire. Il faut pouvoir reconstituer, des mois plus tard, ce qui s'est passé dans le modèle.
• L'interdiction de l'hallucination sur le chiffre. Une note de marché qui invente un rendement, un screening LCB-FT qui rate une alerte : le coût d'erreur n'est pas le même qu'un chatbot e-commerce.

Takeaway : dans la banque, la faisabilité technique n'est jamais le facteur limitant. C'est la conformité, la souveraineté et la traçabilité qui décident ce qui passe en prod.

La grille de lecture : ce qui passe, ce qui cale

Avant le détail par fonction, le principe qui structure tout. Un cas d'usage bancaire passe en production quand il réunit trois conditions :

1. L'humain reste décideur. L'IA produit un brouillon, une pré-analyse, une synthèse. Un collaborateur valide. Aucune décision financière n'est prise par le modèle seul.
2. La sortie est sourcée. Chaque affirmation chiffrée renvoie à un document d'origine. Pas de génération « libre » sur des chiffres.
3. Les données sensibles restent dans un périmètre maîtrisé. Hébergement souverain dès qu'il y a de la donnée client identifiante.

Un cas d'usage cale quand il viole l'une des trois — typiquement la décision autonome (« l'IA qui valide les ouvertures de compte ») ou la génération non sourcée (« l'IA qui rédige la recherche from scratch »). C'est aussi la ligne de partage qu'on observe entre agents IA de démo et agents IA de production.

Front office : le terrain qui produit le plus de valeur

C'est là que ça marche le mieux, parce que la sortie est toujours relue par un humain — le banquier ou le gérant — avant d'atteindre le client.

Génération de notes de marché et de recherche. Le cas le plus mûr. Une banque privée genevoise, génération de notes de marché hebdomadaires : RAG sur quatre ans d'archives de notes maison plus flux Bloomberg, et la note sonne maison — le ton, les angles, les formats habituels. Le gérant relit et ajuste plutôt que de partir de la page blanche. Gain mesuré : passage de 6 heures à 1h30 de rédaction par cycle, sur une équipe de 4 analystes. La condition non négociable : chaque chiffre cité est sourcé vers le document Bloomberg ou la note d'origine, et un encart « sources » accompagne chaque paragraphe. Sans citation, le cas serait resté en POC.

Préparation de RDV client. Un gestionnaire de fortune zurichois, synthèse pré-RDV : le système agrège la fiche client, l'historique des échanges, la composition du portefeuille et les mouvements récents en un brief d'une page que le gérant lit dans l'ascenseur. Gain : 25 à 40 minutes de préparation par rendez-vous, sur des gérants qui en enchaînent 6 à 8 par semaine. Donnée ultra-sensible : tourne intégralement sur hébergement suisse, modèle open-weights ou Mistral hébergé en Suisse.

Synthèse de portefeuille en langage naturel. Traduire une allocation et sa performance en un commentaire client lisible. Mûr, à condition que les chiffres viennent du système de gestion de portefeuille par requête déterministe — l'IA met en forme, elle ne calcule pas.

Takeaway : au front, l'IA est un accélérateur de rédaction sous contrôle humain. C'est le quadrant où le ROI se matérialise le plus vite.

Conformité et LCB-FT : prometteur, mais le plus exigeant sur la traçabilité

La conformité est paradoxale : énorme potentiel, et exigences de traçabilité parmi les plus dures.

Revue documentaire KYC. Une banque de gestion vaudoise, revue d'entrée en relation : extraction structurée des documents KYC (statuts, registres, justificatifs de provenance des fonds), détection des pièces manquantes, pré-remplissage du dossier. L'analyste conformité valide. Gain : temps de revue par dossier complexe divisé par deux environ, et surtout une homogénéité de traitement que l'humain seul ne garantit pas. Le modèle ne prononce jamais le « oui » d'entrée en relation — il prépare la décision.

Screening et revue d'alertes LCB-FT. Là, prudence maximale. L'IA aide à enrichir et hiérarchiser les alertes (résumé d'articles de presse négative, désambiguïsation d'homonymes, première qualification), mais ne ferme jamais une alerte seule. Une fermeture d'alerte AML décidée par un modèle, c'est inaudible pour la FINMA comme pour l'ACPR. Le gain est dans la réduction du temps de traitement par alerte, pas dans la suppression du compliance officer.

Recherche réglementaire interne. Assistant sourcé sur le corpus réglementaire et les politiques internes : « Quelle est notre procédure pour un PEP de telle juridiction ? » avec réponse citée vers la politique applicable. Mûr, et très apprécié, parce que le risque est borné — c'est de la recherche documentaire interne, pas une décision.

Back office : le quick win sous-estimé

Le back-office est le terrain le moins glamour et l'un des plus rentables, parce que le risque y est souvent plus borné.

Réponses sourcées aux demandes internes. Un assistant qui répond aux questions opérationnelles récurrentes (procédures, conditions tarifaires, documents requis) en citant la source interne. Déploiement rapide, ROI net sur le temps des équipes support et middle-office.

Traitement et routage de demandes. Classification et pré-traitement des demandes entrantes (réclamations, requêtes documentaires), extraction des informations clés, proposition de réponse. L'opérateur valide et envoie. Sur un volume de plusieurs centaines de demandes par jour dans un back-office de taille moyenne, le gain de temps est significatif.

Recherche réglementaire et veille. Synthèse de circulaires, de notes de l'autorité, de mises à jour de politiques, avec liens vers les textes. Mûr.

Takeaway : pour une première mise en production bancaire, le back-office offre souvent le meilleur ratio valeur/risque. C'est un bon endroit pour choisir un premier cas d'usage qui débloque le budget.

Crédit PME : pré-analyse oui, décision non

Le crédit est l'exemple parfait de la frontière production/POC.

Ce qui passe : la pré-analyse de dossier. Une banque régionale, financement PME : le système lit les liasses fiscales, les comptes, le business plan, en extrait les ratios clés, repère les incohérences et produit une note de synthèse structurée pour l'analyste crédit. Gain : 2 à 3 heures par dossier sur l'instruction préparatoire, et une grille d'analyse homogène. C'est une matière qu'on connaît bien côté crédit, dans la lignée de ce qu'on a documenté sur Loxia / Doxallia chez Crédit Agricole.

Ce qui ne passe pas : la décision d'octroi. Un modèle qui accorde ou refuse un crédit, c'est un système à haut risque au sens de l'AI Act (scoring de crédit), avec obligations renforcées, et de toute façon inacceptable côté gouvernance prudentielle. L'IA prépare, le comité de crédit décide. La nuance entre les deux est tout le sujet de l'AI Act, du RGPD et de la nLPD comme garde-fous d'un pilote.

Synthèse : production vs POC, par fonction

Fonction	Cas d'usage	Statut 2026	Contrainte dominante
Front	Notes de marché / recherche (RAG)	Production	Sourçage obligatoire des chiffres
Front	Brief pré-RDV client	Production	Hébergement souverain (donnée client)
Front	Synthèse de portefeuille	Production	Chiffres issus du SGP, pas du modèle
Conformité	Revue documentaire KYC	Production	Validation humaine, audit trail
Conformité	Enrichissement d'alertes LCB-FT	Production (assistance)	Jamais de fermeture autonome
Conformité	Screening / décision AML autonome	POC / interdit	Décision réservée à l'humain
Back-office	Réponses sourcées internes	Production	Risque borné, citations
Back-office	Routage / pré-traitement demandes	Production	Validation avant envoi
Crédit	Pré-analyse de dossier PME	Production	Note préparatoire, pas décision
Crédit	Octroi / scoring autonome	POC / haut risque	AI Act + gouvernance prudentielle

Les quatre pièges spécifiques à la banque

Piège 1 : croire que « cloud européen » suffit. Azure EU ou AWS eu-central stockent en Europe mais restent opérés par des acteurs soumis au CLOUD Act. Pour de la donnée client identifiante d'une banque privée, le standard est l'hébergement suisse (Infomaniak, Exoscale, Swisscom, parfois on-prem) ou, à défaut, du Mistral / open-weights hébergé en France. La souveraineté n'est pas une option de confort, elle détermine si le cas d'usage est seulement légal.

Piège 2 : laisser le modèle décider. Toute architecture où l'IA prononce une décision financière — octroi, fermeture d'alerte, entrée en relation — est disqualifiée. L'humain dans la boucle n'est pas une lourdeur, c'est la condition de mise en production.

Piège 3 : tolérer l'hallucination sur le chiffre. Un rendement inventé dans une note client est une faute. La parade est architecturale : RAG avec citations obligatoires, chiffres extraits par requête déterministe vers les systèmes de référence, et refus explicite du modèle quand la source manque. C'est précisément le genre d'arbitrage qu'on instruit dans RAG vs fine-tuning vs MCP.

Piège 4 : sous-estimer l'audit trail. Sans journalisation complète (prompt, modèle et version, sources retrouvées, réponse, validation humaine), pas de mise en production en environnement régulé. La traçabilité se conçoit en amont, jamais après coup.

Takeaway : ces quatre pièges expliquent l'essentiel des POC bancaires bloqués. Aucun n'est un problème de modèle.

Build vs buy : où commencer

Faut-il acheter une solution verticale « IA pour la banque » ou construire ? La réponse dépend de la couche.

Sur les briques commodité — un assistant de recherche réglementaire générique, de la transcription de réunion — l'achat est souvent rationnel, à condition de vérifier l'hébergement et le contrat de non-rétention. Sur les briques différenciantes — la note de marché qui sonne maison, le brief client nourri de vos données — la valeur est dans vos données et votre ton. Une solution sur étagère ne saura pas reproduire ça. C'est là qu'on construit, autour d'une couche de données propre.

Et la course au dernier modèle n'est pas le sujet. Claude Sonnet 4.6 fait très bien le travail de synthèse et de rédaction sur la majorité de ces cas ; Claude Opus 4.8 se réserve aux raisonnements lourds (analyse de dossier crédit complexe) ; Mistral Large 2 hébergé en Suisse ou en France couvre les cas à forte sensibilité où la souveraineté prime. Le choix du modèle est une décision d'architecture parmi d'autres, pas le cœur du projet — et le coût marginal en production se chiffre, ce qu'on détaille dans le coût d'un projet IA pour PME et ETI en 2026.

Côté budget, un premier cas d'usage bancaire mis en production proprement — cadrage, couche de données, RAG sourcé, audit trail, hébergement souverain — se situe typiquement entre CHF 40 000.- et CHF 90 000.- pour le pilote industrialisable, selon la complexité des données et le niveau de contrainte. La part « modèle » y est marginale ; la part « données + conformité + traçabilité » est l'essentiel.

La position BUMPSLAB

Notre conviction tient en une phrase : dans la banque, ce qui passe en production n'est pas le meilleur modèle, c'est la meilleure discipline.

Concrètement, on travaille trois couches. La couche de données d'abord — propre, indexée, sourçable —, parce que c'est elle qui fait qu'une note sonne maison et qu'un chiffre est citable. La souveraineté ensuite — hébergement suisse ou français par défaut pour la donnée client, et on argumente quand on s'en éloigne, pas l'inverse. La traçabilité enfin — audit trail complet, validation humaine sur tout ce qui a un impact financier. Le modèle vient après, et il est interchangeable.

C'est cette approche qu'on a packagée dans Atlas (/solutions/atlas), notre socle pour déployer des assistants IA sourcés et auditables en environnement régulé : couche de données, citations, journalisation et hébergement souverain par construction. Et quand un dirigeant ne sait pas par quel cas d'usage commencer, l'AI Use Case Audit en cinq jours sort une fiche initiative chiffrée et signable, plutôt qu'un catalogue qui dort.

---

Si vous avez accumulé des POC d'IA impressionnants en démo et rien en production, la cause est rarement le modèle. C'est presque toujours la couche de données, la souveraineté ou la traçabilité qui manque. Cinq jours suffisent à identifier le cas d'usage bancaire qui passera vraiment l'audit — et à le chiffrer honnêtement, en CHF.