Une époque s’ouvre où une intention formulée en langage naturel peut devenir, en quelques minutes, un agent, une application, un flux automatisé ou du code exécutable. L’IA générative, le vibe coding, le low-code et le no-code abaissent radicalement la barrière entre l’idée et le système. Pour les organisations financières, cette accélération est une chance immense. Elle permet aux métiers de résoudre eux-mêmes des irritants, d’automatiser des tâches et de tester de nouveaux services sans attendre plusieurs mois.
Mais elle modifie aussi la nature du risque. Ce qui était autrefois visible — un projet, un budget, une équipe, une mise en production — peut désormais naître discrètement sur le poste d’un collaborateur, se connecter à une donnée sensible, être partagé à dix collègues, puis devenir indispensable avant même d’avoir été identifié par l’organisation.
Une conviction guide ce texte : on ne gouverne pas une technologie. On gouverne une capacité d’agir et les conséquences qu’elle peut produire.
La bonne question n’est donc pas : « Faut-il autoriser ChatGPT, Copilot, Power Platform ou tel outil de vibe coding ? » La bonne question est : « Qu’est-ce que cet usage peut lire, décider, modifier, déclencher ou exposer — et qui en répond ? »
Ni interdiction générale, ni liberté sans responsabilité
Dans la banque et la finance, deux réflexes opposés conduisent à la même impasse.
Le premier consiste à tout bloquer. Cette approche ne supprime pas le besoin métier ; elle le déplace vers le shadow AI, le shadow IT et des outils non déclarés. L’organisation perd alors la visibilité dont elle a précisément besoin pour maîtriser ses risques.
Le second consiste à ouvrir largement les outils en supposant qu’un avertissement, une charte ou un humain « dans la boucle » suffiront. Or une validation humaine sans compétence, sans temps, sans preuve et sans pouvoir d’arrêt n’est pas un contrôle. C’est une formule rassurante.
La doctrine proposée se situe ailleurs : rendre le chemin conforme plus simple, plus rapide et plus utile que le contournement. La gouvernance doit être un produit offert aux équipes, pas seulement un corpus de règles opposé aux équipes.
Premier principe : gouverner l’usage, pas l’étiquette de l’outil
Un tableur peut être plus critique qu’un modèle d’IA. Un petit flux no-code peut déclencher un paiement. Une application construite en quelques heures peut devenir le point d’entrée d’un processus de connaissance client. À l’inverse, un assistant d’idéation utilisant uniquement des informations publiques peut présenter un risque limité.
Le niveau de contrôle doit donc dépendre de l’impact potentiel : nature des données, nombre d’utilisateurs, exposition externe, capacité à prendre ou influencer une décision, effet financier, réversibilité, dépendance créée et criticité du processus.
Trois zones permettent de proportionner la gouvernance.
La zone d’exploration couvre les usages personnels ou temporaires qui utilisent uniquement des données publiques, synthétiques ou anonymisées selon un processus approuvé, sans décision client, sans écriture dans un système de référence et sans conséquence financière. Toute donnée personnelle, client, confidentielle, bancaire ou réglementée en est exclue. Cette zone doit être largement accessible, dans un environnement balisé, avec des outils approuvés et des règles simples.
La zone contrôlée concerne les solutions partagées, les données internes, les connecteurs d’entreprise ou les automatisations qui commencent à soutenir une activité. Elle exige un propriétaire identifié, un enregistrement dans l’inventaire, des tests, une gestion des accès, une supervision et un chemin de mise en production.
La zone critique comprend tout usage susceptible de produire un effet juridique, financier ou autrement matériel sur un client, ou d’influencer une décision le concernant. Elle couvre aussi les paiements, le crédit, le conseil, le trading, la fraude, la lutte contre le blanchiment, le KYC, le reporting réglementaire, les données hautement sensibles et les actions autonomes difficilement réversibles. Ici, l’IA et les plateformes de développement rapide doivent entrer pleinement dans les dispositifs de gestion des risques technologiques, de sécurité, de conformité, de validation indépendante, de continuité et de gestion des changements.
La liberté de construire augmente lorsque l’impact est faible. La preuve exigée augmente lorsque l’impact devient fort.
Une gouvernance minimale viable pour éviter la bureaucratie
La proportionnalité ne doit pas rester un principe abstrait. Elle doit se traduire par des parcours réellement différents. L’exploration doit être presque immédiate dans un cadre préconfiguré. La zone contrôlée doit bénéficier d’une revue courte, avec un délai de réponse mesuré. L’instruction indépendante complète est réservée par défaut à la zone critique. Des déclencheurs spécialisés — donnée sensible, connecteur puissant, exposition externe, dépendance de tiers ou exigence locale — peuvent néanmoins imposer une revue ciblée ou une reclassification. Appliquer le parcours le plus lourd à chaque usage fabriquerait exactement le shadow IT que la gouvernance cherche à réduire.
Trois critères permettent d’ajuster l’effort : la matérialité d’une erreur, la réversibilité de l’action et la capacité de propagation. Un usage à faible impact, facilement annulable et strictement local appelle peu de preuves. Un usage qui peut affecter de nombreux clients, déplacer de l’argent ou diffuser une erreur dans plusieurs systèmes appelle des contrôles renforcés.
Chaque parcours doit avoir un engagement de service, un interlocuteur et une voie d’escalade. Les dérogations doivent rester possibles, mais être justifiées, attribuées à un responsable, limitées dans le temps et assorties d’une date de régularisation. Une gouvernance crédible mesure autant son propre délai et son propre coût que les risques qu’elle demande aux équipes de maîtriser.
Deuxième principe : tout actif exécutable doit avoir une identité
Ce qui n’est pas inventorié n’est pas gouvernable. Toute application, tout agent, tout flux et tout composant généré par IA qui dépasse l’expérimentation personnelle doit posséder une fiche d’identité minimale : un propriétaire métier, un responsable technique, une finalité, des utilisateurs, les données manipulées, les connexions, le modèle ou le service d’IA utilisé, le niveau de criticité, l’environnement d’exécution et une date de revue.
Cet inventaire ne doit pas devenir un fichier Excel oublié. Il doit être alimenté autant que possible par les plateformes elles-mêmes et relié aux catalogues de services, aux référentiels de données, à la gestion des identités, aux incidents et aux processus de décommissionnement.
La traçabilité utile n’est pas l’accumulation de documents. C’est la capacité à répondre rapidement à cinq questions : qui possède cet actif ? que peut-il faire ? avec quelles données ? sur quelle base a-t-il été autorisé ? comment l’arrête-t-on ?
Troisième principe : le code généré est du code non fiable jusqu’à preuve du contraire
Le vibe coding change la vitesse de production, pas les lois de l’ingénierie. Un résultat qui fonctionne pendant une démonstration n’est pas encore un logiciel de production. Il peut contenir une dépendance vulnérable, une clé exposée, une autorisation trop large, une erreur silencieuse, un comportement non déterministe ou une logique que personne dans l’équipe ne sait maintenir.
Une règle s’impose : une suggestion produite par IA n’est ni une revue, ni une preuve, ni une approbation. Le code généré doit suivre la même chaîne de confiance que tout autre code, avec un dépôt identifié, une revue adaptée au risque, des tests utiles, une analyse des dépendances et des secrets, une séparation des environnements, une procédure de déploiement et un retour arrière possible.
L’IA ne doit pas devenir l’unique validateur de ce qu’elle a elle-même produit. Pour un composant matériel, le générateur, l’auteur des tests et le validateur ne peuvent pas constituer une seule chaîne de confiance. Les tests indépendants et un éventuel modèle challenger doivent rechercher des modes d’échec différents de ceux anticipés lors de la génération. Le modèle challenger reste un outil complémentaire, jamais une autorité d’approbation. Pour un usage matériel ou critique, l’évaluation doit inclure une personne qualifiée indépendante de la réalisation ou une fonction de contrôle compétente.
Pour les usages critiques, l’organisation doit aussi conserver la capacité humaine de comprendre le système. Si personne ne peut expliquer la logique, diagnostiquer un incident ou reprendre la main sans l’outil qui a généré la solution, le résultat est une dépendance, pas une capacité.
Quatrième principe : la donnée et les droits d’action déterminent le danger réel
Le risque principal n’est souvent pas le modèle lui-même, mais ce qu’on lui donne et ce qu’on l’autorise à faire. Une IA sans accès à des données confidentielles et sans capacité d’action a un rayon d’impact limité. Un agent connecté aux dossiers clients, à la messagerie, aux paiements et à des API internes peut amplifier une erreur à la vitesse de la machine.
Les contrôles prioritaires sont donc concrets : classification des données, outils approuvés, interdiction d’envoyer des secrets ou des données protégées vers des services non autorisés, moindre privilège, comptes de service maîtrisés, connecteurs soumis à politique, séparation des tâches et journalisation des actions sensibles.
La fragmentation mérite la même attention que la fuite. Copier des données dans des environnements personnels, multiplier les tables parallèles ou contourner les systèmes de référence détruit progressivement la qualité, la cohérence et la capacité d’audit. Les plateformes doivent donc encadrer les connecteurs, la duplication, la durée de conservation et la réconciliation avec les sources officielles.
Un agent ne doit jamais recevoir davantage de droits que ceux strictement nécessaires à sa mission. Et plus son autonomie augmente, plus les plafonds, validations, limites de débit, mécanismes d’arrêt et contrôles après exécution doivent être explicites.
Cinquième principe : la responsabilité humaine ne se délègue pas
L’IA peut proposer, synthétiser, classer, détecter ou exécuter. Elle ne porte ni mandat, ni obligation professionnelle, ni responsabilité morale. Pour chaque usage significatif, une personne doit être nommément responsable de l’objectif, des risques acceptés, de la qualité attendue et de l’arrêt du système lorsque les conditions ne sont plus réunies.
Dans un processus sensible, « human in the loop » ne suffit pas. Il faut préciser quel humain, à quel moment, avec quelles informations, selon quels critères, dans quel délai, avec quelle formation et avec quel pouvoir réel de contredire la machine.
Cette exigence rejoint un principe de gouvernance bancaire fondamental : la direction conserve la responsabilité ultime du dispositif, même lorsque la technologie, le modèle ou l’exploitation sont fournis par un tiers.
Le recours à un tiers doit être gouverné selon son importance : conditions de collecte et de réutilisation des données, localisation, sous-traitants, sécurité, notification des incidents, auditabilité, changements de modèle, concentration, substituabilité, continuité, portabilité et stratégie de sortie. La banque doit savoir ce qu’elle fera si le service change, se dégrade ou disparaît.
Un RACI décisionnel, pas seulement une liste de rôles
Dans les lignes suivantes, A désigne l’autorité qui assume la décision, R la fonction qui réalise, C les fonctions consultées ou appelées à valider selon leur mandat, et I les parties informées. L’autorité métier n’accepte un risque résiduel que dans les limites de sa délégation et de l’appétence au risque de l’établissement. L’organe de direction conserve la responsabilité ultime du dispositif.
Classification — A : responsable métier. R : responsable métier et responsable technique documentent ensemble l’usage. C : plateforme, données, sécurité, risque ou conformité lorsque leurs déclencheurs sont atteints. I : propriétaire de l’inventaire.
Mise en service en zone contrôlée — A : responsable métier dans sa délégation. R : responsable technique, qui réunit les preuves et organise le déploiement. C : fonctions de contrôle requises par les seuils de données, de sécurité, de tiers ou de réglementation. I : support et utilisateurs concernés.
Mise en service en zone critique — A : dirigeant ou comité disposant de la délégation formelle. R : responsables métier et technique. C : avis ou validations formels des fonctions de contrôle compétentes. I : direction, exploitation et parties concernées. L’audit interne n’approuve pas la mise en production ; il conserve son rôle d’assurance indépendante.
Arrêt et incident — A : responsable métier, ou autorité de crise lorsque le seuil d’escalade est atteint. R : exploitation technique. C : sécurité, risque, conformité, juridique, protection des données et communication selon la nature de l’incident. I : direction et parties soumises à notification.
Sortie fournisseur — A : dirigeant propriétaire du service. R : responsables technique, achats et continuité. C : juridique, sécurité, risque et métiers dépendants. I : utilisateurs et entités affectées.
Remédiation — le propriétaire de l’actif finance les défauts propres à la solution ; le propriétaire de la plateforme finance les défauts du socle mutualisé ; les recours contre un fournisseur suivent les clauses contractuelles. Cette allocation budgétaire n’efface ni les obligations légales ni la responsabilité ultime de l’établissement.
La responsabilité juridique exacte dépend du rôle, de la juridiction, du contrat et du système concerné ; elle ne peut pas être déduite du seul fait que l’IA ou une plateforme low-code a produit le composant.
Sixième principe : la preuve doit accompagner la vitesse
Les méthodes classiques demandent souvent aux équipes de produire tardivement une documentation massive. À l’ère du développement assisté par IA, cette approche ne tiendra pas. Les changements sont trop nombreux et trop rapides.
Il faut remplacer le contrôle documentaire tardif par une fabrication continue de preuves : historique des versions, provenance des composants, tests automatisés, résultats des contrôles de sécurité, approbations, décisions de dérogation, journaux d’exécution, indicateurs de qualité et incidents. Ces preuves doivent elles-mêmes respecter la minimisation des données, le contrôle d’accès et une durée de conservation définie afin de ne pas recréer un dépôt de prompts, de secrets ou de données clients. La gouvernance doit se déplacer dans les plateformes et les chaînes de livraison.
Pour les générations automatiques de code ou de logique, la traçabilité doit couvrir au minimum l’outil, la version du modèle lorsqu’elle est disponible, le contexte autorisé, le dépôt et la version du résultat, les contrôles exécutés et la décision de mise en service. Enregistrer systématiquement les prompts, entrées et sorties bruts serait parfois contre-productif : ils peuvent contenir des secrets ou des données personnelles. Leur conservation doit donc être justifiée par le risque, filtrée, protégée et limitée dans le temps.
Chaque solution devrait pouvoir produire un dossier de preuve proportionné à son risque. Pour la zone d’exploration, quelques métadonnées suffisent. Pour un système critique, ce dossier doit démontrer la robustesse, la sécurité, la conformité, la surveillance, la continuité, l’explicabilité nécessaire et la capacité de reprise.
La vitesse de construction crée une dette de preuve. Cette dette doit être remboursée avant que l’usage ne devienne critique.
Septième principe : gouverner tout le cycle de vie, y compris la fin
Une validation au lancement n’est pas une garantie permanente. Les modèles changent, les données dérivent, les connecteurs évoluent, les fournisseurs modifient leurs services et les usages réels s’éloignent parfois de l’intention initiale.
La gouvernance doit donc couvrir l’idée, l’expérimentation, la qualification du risque, la construction, la mise en production, la surveillance, les changements, les incidents et le retrait. Chaque actif doit avoir des seuils d’alerte, une fréquence de revue, un plan de continuité et des critères de suspension.
La fin de vie est un contrôle à part entière. Une application abandonnée, un flux orphelin ou un agent dont le propriétaire a quitté l’entreprise restent des surfaces de risque. La capacité à désactiver, archiver et supprimer proprement fait partie de la qualité du système.
Huitième principe : organiser une gouvernance fédérée
Le centre ne pourra jamais examiner manuellement chaque prompt, chaque flux et chaque application. Mais abandonner les métiers à eux-mêmes serait tout aussi inefficace. Le bon modèle est fédéré.
Une équipe centrale définit les standards, les environnements, les composants approuvés, les politiques de données, les contrôles automatisés et les voies d’escalade. Les métiers et les équipes techniques possèdent leurs cas d’usage et exécutent les contrôles de premier niveau. Les fonctions de risque, de conformité, de sécurité et de protection des données exercent leur contrôle selon leur mandat. L’audit interne apporte une assurance indépendante : il ne conçoit ni ne possède le dispositif qu’il devra évaluer.
Les équipes doivent disposer de « chemins pavés » : environnements sécurisés prêts à l’emploi, modèles de solution, connecteurs autorisés, bibliothèques validées, journalisation native, gestion des secrets, tests standards et déploiement automatisé. La conformité devient ainsi un accélérateur réutilisable.
La formation complète ce dispositif. La culture IA ne consiste pas seulement à apprendre à rédiger un prompt. Elle comprend la qualité des données, les limites des modèles, la sécurité, le droit, le risque d’automatisation, la vérification des sorties et le devoir de signaler un incident.
Neuvième principe : gouverner les incitations et les réalités locales
Les contrôles techniques ne suffisent pas lorsque les objectifs de délai, les budgets ou les critères de performance encouragent implicitement le contournement. Un manager ne peut pas demander une livraison en deux semaines tout en imposant un parcours de validation de deux mois. Les indicateurs, les budgets et les responsabilités doivent être cohérents avec la doctrine.
L’application sera nécessairement inégale entre le siège, les filiales, les pays et les partenaires. Un socle commun doit donc définir les invariants — données, identité, traçabilité, responsabilité, arrêt — tandis que l’exécution locale peut adapter les parcours aux risques et aux contraintes réglementaires. Chaque entité doit nommer un propriétaire local, documenter les équivalences de contrôle et faire approuver toute dérogation avec une échéance. Les inventaires, incidents et exceptions sont consolidés au niveau du groupe. Pour les partenaires, le socle doit être décliné dans les contrats, les obligations de notification et les droits de contrôle. Des relais métier formés, accompagnés par des mentors techniques, réduisent davantage le shadow IT qu’une certification conçue comme une barrière d’entrée.
La formation et l’habilitation doivent être progressives. Les droits d’accès augmentent avec les compétences démontrées, la sensibilité des données et l’autonomie demandée. L’objectif n’est pas de créer une nouvelle caste de développeurs autorisés, mais de rendre les capacités, les limites et les voies d’escalade explicites.
Dixième principe : rendre le coût et la dette visibles
Une solution rapide n’est pas nécessairement une solution peu coûteuse. Le coût total comprend les licences, les connecteurs, les contrôles, le support, les changements de fournisseur, la supervision, la correction des incidents et le retrait. Toute décision de passage à l’échelle doit comparer la valeur attendue, le coût de maîtrise et le coût potentiel d’une défaillance.
La dette low-code et no-code est souvent invisible : logique dispersée, dépendances propriétaires, comptes orphelins, limites de performance et absence de tests. Un budget de maintenance et de refactoring doit être attaché aux actifs qui deviennent durables. Lorsque le coût de remise sous contrôle dépasse la valeur attendue, la bonne décision peut être de limiter, reconstruire ou retirer la solution.
Dix exigences non négociables
Cette doctrine peut se résumer en dix exigences.
1 — Un usage significatif est déclaré. 2 — Un responsable métier et un responsable technique sont nommés. 3 — Les données et les droits sont limités au strict nécessaire. 4 — Les environnements d’exploration et de production sont séparés. 5 — Le code généré est revu et testé. 6 — Les décisions ou actions sensibles sont traçables. 7 — Les tiers et les dépendances sont évalués. 8 — Un mécanisme d’arrêt et de retour arrière existe. 9 — Le comportement, le coût et la dette technique sont surveillés après la mise en production. 10 — L’actif est réévalué, puis retiré lorsqu’il n’a plus de propriétaire ou de valeur.
Ces exigences ne signifient pas que chaque prototype doit suivre un parcours bancaire de six mois. Elles signifient que chaque passage à l’échelle doit être conscient, visible et proportionné.
Une trajectoire en trois horizons
De 0 à 3 mois — sélectionner deux ou trois pilotes représentatifs dans des sandboxes sécurisées ; imposer le socle minimal sur les données, les identités et les secrets ; nommer les responsables ; mesurer le délai de mise en production, les incidents, la valeur créée et le coût de maintenance. Le pilote doit avoir une date de fin et des critères explicites de poursuite, de correction ou d’arrêt.
De 3 à 12 mois — industrialiser un catalogue de composants et de connecteurs approuvés ; déployer des environnements séparés et des chemins de livraison ; mettre en place la traçabilité adaptée au risque ; formaliser les RACI, les engagements de service et les clauses contractuelles de continuité, d’audit, de notification et de portabilité.
Au-delà de 12 mois — financer durablement la maintenance et la réduction de la dette ; organiser une habilitation progressive des citizen developers avec mentorat ; tester les plans de sortie fournisseur et les mécanismes d’arrêt ; comparer les filiales et partenaires sur un tableau de bord commun sans effacer leurs contraintes locales.
Ce que les dirigeants doivent mesurer
Une gouvernance mature ne se mesure pas au nombre de comités ni au volume de politiques publiées. Elle se mesure à la réalité du terrain : part des actifs découverts et possédés, délai pour obtenir un environnement conforme, délai de décision par zone, proportion des solutions qui suivent un chemin de livraison approuvé, ancienneté des dérogations, incidents liés à des usages non recensés, temps de correction, coût de maintenance, dette en attente et capacité à couper rapidement un composant à risque.
Il faut aussi mesurer la valeur. Une gouvernance qui ne voit que le risque pousse les équipes dans l’ombre. Le temps économisé, les erreurs évitées, la qualité de service, le taux d’adoption des chemins approuvés et les capacités nouvelles doivent être suivis avec le même sérieux. Si les équipes contournent le dispositif, le premier diagnostic doit porter sur la friction, les délais et les incitations avant de conclure à un simple défaut de conformité.
Chaque indicateur doit posséder une référence initiale, une cible, un seuil d’alerte ou d’arrêt, un propriétaire et une fréquence de revue. Le tableau de bord n’a de valeur que s’il déclenche une décision explicite : poursuivre, corriger, reclasser, reconstruire ou retirer.
Une position à défendre
Dans la banque et la finance, l’enjeu n’est pas de ralentir l’IA, le vibe coding, le low-code ou le no-code. Il est d’empêcher que leur vitesse dépasse la capacité collective à comprendre, assumer et corriger ce que les organisations mettent en mouvement.
Cette approche autorise largement l’apprentissage, encadre progressivement le partage et exige fortement la preuve lorsque l’impact devient matériel. Elle maintient la responsabilité humaine, intègre les contrôles aux outils, donne un propriétaire à chaque actif et impose que toute automatisation importante puisse être expliquée, surveillée et arrêtée.
Le futur ne sera pas gagné par les organisations qui auront le plus interdit. Il ne sera pas davantage gagné par celles qui auront tout ouvert. Il appartiendra à celles qui sauront transformer la confiance en architecture, les principes en chemins praticables et la vitesse en capacité durable.
Voilà une doctrine à porter : expérimenter librement, industrialiser consciemment, gouverner proportionnellement et rester responsable, toujours.
Repères de référence
Règlement européen sur l’intelligence artificielle (AI Act), notamment l’obligation de maîtrise de l’IA applicable aux fournisseurs et déployeurs (article 4) et le système de gestion des risques applicable aux fournisseurs de systèmes d’IA à haut risque (article 9) : https://eur-lex.europa.eu/legal-content/FR/TXT/?uri=CELEX:32024R1689
Règlement européen sur la résilience opérationnelle numérique du secteur financier (DORA), notamment la gouvernance et le cadre de gestion du risque informatique : https://eur-lex.europa.eu/eli/reg/2022/2554/oj?locale=fr
FINMA, communication sur la gouvernance et la gestion des risques lors de l’utilisation de l’intelligence artificielle : https://www.finma.ch/fr/news/2024/12/20241218-mm-finma-am-08-24/
NIST AI Risk Management Framework, structuré autour des fonctions Govern, Map, Measure et Manage : https://airc.nist.gov/airmf-resources/airmf/5-sec-core/
NIST Secure Software Development Framework : https://csrc.nist.gov/projects/ssdf
Microsoft, stratégie de gouvernance et d’environnements pour Power Platform : https://learn.microsoft.com/fr-fr/power-platform/guidance/adoption/environment-strategy
Ce texte exprime une doctrine professionnelle de gouvernance. Il ne constitue pas un avis juridique ou réglementaire.