La plupart des projets d'IA bancaire échouent pour une raison qui n'a rien à voir avec la qualité du modèle. Les équipes de direction passent des mois à comparer le nombre de paramètres et les scores de référence, tandis qu'une menace plus discrète érode tout ce qu'elles construisent. Elles considèrent la taille du modèle comme la condition de victoire. Ce n'est pas le cas. Dans les flux de travail réglementés et multi-étapes qui dominent la finance, la précision ne se multiplie pas. Elle se dégrade. Si vous vous focalisez sur le score d'une étape unique, vous serez pris de court par une défaillance systémique.
Le vrai problème n'est pas la taille du modèle
Voici l'arithmétique qui empêche les responsables des risques de dormir. Imaginez un pipeline composé de six étapes distinctes : extraction de données, validation, scoring de risque, contrôle de conformité, génération de documents et approbation finale. Chaque étape fonctionne parfaitement de manière isolée, atteignant une précision de 97 %. L'instinct est de célébrer. Mais la probabilité ne suit pas l'intuition. Enchaînez ces étapes et la fiabilité de bout en bout s'effondre pour atteindre environ 83 %.
Cet écart entre la perfection locale et l'échec global est le fossé de coordination de l'IA (AI Coordination Gap). C'est la friction que vous perdez lors des passages de relais entre les agents, les outils logiciels et les réviseurs humains. Les régulateurs recherchent déjà précisément cette vulnérabilité. Ils la repéreront avant même que votre équipe d'ingénierie n'ait terminé son post-mortem.
D'ici 2026, le débat aura changé. La question n'est plus de savoir quel modèle domine un classement de recherche. Il s'agit de discipline budgétaire, de souveraineté des données et de contrôle des mises à jour. Vous devrez choisir entre un Small Language Model (SLM) personnalisé que vous pouvez confiner dans votre propre infrastructure, ou un Large Language Model (LLM) prêt à l'emploi que vous louez au jeton (token).
SLM vs LLM : ce qui change réellement en 2026
Les modèles de pointe prêts à l'emploi — GPT-4o, Claude et leurs pairs — restent inégalés pour le raisonnement ouvert et les tâches analytiques à faible volume. Ils lisent entre les lignes. Ils gèrent les nuances. Mais cette commodité a un coût. Vous ne possédez pas les poids (weights). Vous ne contrôlez pas le calendrier des mises à jour. Une mise à jour silencieuse effectuée un week-end par le fournisseur peut modifier la façon dont votre application interprète les seuils de ratio d'endettement ou signale des transactions suspectes, et vous pourriez ne pas avoir de trace exacte de ce qui a changé. Dans un secteur où chaque décision exige une piste d'audit, cette opacité coûte cher.
Les SLM personnalisés basés sur des poids ouverts (open weights) comme Llama ou Mistral inversent l'équation. Ils sont conçus spécifiquement pour des tâches intensives et à haut volume : extraction de champs à partir de PDF de prêts hypothécaires, classification de documents KYC ou analyse de mémos de transaction. Comme vous les hébergez, vous pouvez figer une version, effectuer des tests différentiels et prouver à un auditeur que le modèle se comportant en mars est identique à celui de juin. Ils sont également extrêmement peu coûteux, avec un coût par jeton environ dix à trente fois inférieur à celui de leurs cousins basés sur le cloud. Le compromis réside dans une capacité plus restreinte. Un SLM ne fera pas de philosophie sur les tendances du marché. Il pourra, en revanche, traiter dix mille factures par heure sans envoyer de données propriétaires en dehors de votre pare-feu.
Routage hétérogène : la répartition 80/20
Les banques qui prennent l'avantage ont cessé de considérer cela comme un choix binaire. Leur architecture est hétérogène. Un SLM peu coûteux et affiné (fine-tuned) gère le premier passage sur les travaux prévisibles et structurés — extraction de documents, étiquetage d'entités ou contrôles d'éligibilité de routine — traitant environ quatre-vingts pour cent du volume total. Les vingt pour cent restants, les cas limites nécessitant un raisonnement analogique ou une interprétation complexe de politiques, sont transférés vers un LLM de pointe.
Ce n'est pas théorique. Un gestionnaire de prêts hypothécaires pourrait laisser un SLM extraire les revenus à partir de bulletins de paie, puis ne transmettre que les dossiers ambigus à un modèle plus large qui recoupe plusieurs types d'emplois avec les directives fédérales changeantes. Vous réduisez les dépenses cloud sans réduire les capacités.
Un cadre en cinq couches pour combler l'écart
Combler le fossé de coordination exige plus qu'un routage intelligent. Cela nécessite une pile technologique explicite. Voici un cadre en cinq couches que les équipes peuvent déployer dès maintenant.
Sélection du modèle. Traitez l'inférence comme un infirmier de triage. Orientez les tâches en fonction du volume et de la sensibilité. Les opérations à haute fréquence et à faible risque sont confiées à votre SLM. Les cas impliquant du jugement, de l'ambiguïté ou la résolution de plaintes clients sont confiés au LLM. Écrivez les règles de routage dans le code, pas dans un prompt.
Ancrage. Chaque réponse adressée à un client doit renvoyer à un document source. Utilisez la génération augmentée par récupération (RAG) pour ancrer les résultats dans vos manuels de politiques, vos grilles tarifaires et vos avis réglementaires réels. Ne faites jamais confiance à la mémoire paramétrique d'un modèle pour les taux d'intérêt actuels ou les barèmes de frais. La mémoire dérive. Un PDF avec un numéro de version, non.
Orchestration. Construisez des flux de travail où le chemin est visible. Des outils comme LangGraph vous permettent de définir des machines à états explicites et auditables. Une décision doit passer par des étapes définies : extraction, vérification, décision, journalisation. Ne laissez pas les agents arriver à une conclusion par simple « discussion » dans une boucle conversationnelle ouverte. Si vous ne pouvez pas dessiner l'organigramme, vous ne pourrez pas l'expliquer à un régulateur.
Accès aux outils. Les agents doivent pouvoir appeler les systèmes bancaires centraux, mais chaque intégration est un point de défaillance potentiel. Utilisez le Model Context Protocol pour standardiser la manière dont les agents s'authentifient et interrogent vos grands livres, vos dossiers CRM et vos bases de données de conformité. Des interfaces uniformes réduisent la surface de risque de ruptures silencieuses.
Vérification. Réservez une voie dédiée au jugement humain. Aiguillez les décisions à haut risque — virements importants, dépassements de limite de crédit, déclarations de soupçon (SAR) — vers un réviseur humain ou vers un second agent de vérification fonctionnant sur un modèle isolé. La redondance en périphérie protège le centre.
Mesurez les bonnes choses
Arrêtez de récompenser les équipes pour la précision par étape. Un pipeline où chaque module affiche 99 % de précision sur un jeu de test peut tout de même échouer auprès d'un client sur cinq dans la réalité lorsque les étapes interagissent. Commencez à mesurer la fiabilité de bout en bout. Injectez des cas de défaillance synthétiques. Testez les passages de relais de la même manière que les attaquants testent les points de jonction.
Les banques qui gagnent réellement avec l'IA en 2026 ne sont pas celles qui louent les plus grands modèles. Ce sont celles qui assemblent les systèmes les plus clairs. Elles savent qu'un petit modèle que l'on peut auditer l'emporte sur un grand modèle que l'on ne peut pas expliquer, et que