Une doctrine fixe une direction. Elle ne dit pas encore comment instruire un premier cas d’usage lundi matin, évaluer un fournisseur, tester un modèle, sécuriser du code généré ou décider qu’une expérimentation peut passer en production.
Le premier volet, « IA, vibe coding, low-code, no-code : une doctrine de gouvernance pour la banque et la finance », posait quatre ambitions : expérimenter librement, industrialiser consciemment, gouverner proportionnellement et maintenir une responsabilité humaine. Il est accessible ici : https://makysarts.io/TIT/publications/ia-vibe-coding-low-code-no-code-une-doctrine-de-gouvernance-pour/
Ce second volet transforme ces principes en manuel d’exécution. Il ne cherche ni à empiler les contrôles ni à promettre une recette universelle. Il organise des décisions concrètes : quoi mesurer, quelle preuve demander, qui doit trancher et à quel moment arrêter.
1. Le signal du marché : l’usage avance plus vite que la maîtrise
Les données publiques donnent l’échelle du mouvement, mais pas encore son rendement réel.
Dans son enquête publiée en avril 2025 auprès d’environ 400 établissements financiers suisses, la FINMA indique que près de la moitié utilisent déjà l’IA ou développent des applications fondées sur celle-ci. Un quart supplémentaire prévoit de le faire dans les trois années suivantes. Parmi les établissements utilisateurs, 91 % recourent à l’IA générative. La dépendance à des prestataires externes et à quelques grandes entreprises technologiques augmente, tandis qu’environ la moitié seulement des établissements interrogés disposent d’une stratégie explicite en matière d’IA. Source : https://www.finma.ch/fr/news/2025/04/20250424-mm-umfrage-ki/
Au Royaume-Uni, l’enquête 2024 de la Banque d’Angleterre et de la FCA constate que 75 % des entreprises financières interrogées utilisent déjà l’IA et que 10 % supplémentaires prévoient de l’adopter. Un tiers des cas d’usage repose sur des implémentations tierces. Les trois principaux prestataires représentent respectivement 73 %, 44 % et 33 % des prestataires tiers nommés pour le cloud, les modèles et les données. Parmi les entreprises utilisant déjà l’IA, 84 % déclarent avoir désigné une personne responsable du cadre IA. Parmi celles qui l’utilisent ou prévoient de le faire, 34 % déclarent comprendre complètement les technologies employées, contre 46 % qui n’en ont qu’une compréhension partielle. Sources : https://www.bankofengland.co.uk/report/2024/artificial-intelligence-in-uk-financial-services-2024 et https://www.fca.org.uk/publications/research-notes/ai-uk-financial-services
Ces chiffres montrent une diffusion rapide, une forte dépendance aux tiers et un écart de compréhension. Ils ne fournissent toutefois pas un coût universel de mise en conformité, un retour sur investissement standard ou un taux d’incident directement transposable. Publier de faux benchmarks serait aussi trompeur que ne rien mesurer. Chaque établissement doit donc construire sa propre référence à partir de pilotes comparables.
2. Trois pilotes pour apprendre avant de généraliser
Un pilote utile ne sert pas seulement à démontrer que la technologie fonctionne. Il doit produire une décision : poursuivre, corriger, reclasser, reconstruire ou arrêter. Les volumes et seuils suivants sont des exemples à calibrer ; ils ne constituent pas des résultats observés ni des normes sectorielles.
3. Pilote 1 — Assistant de synthèse réglementaire interne
Périmètre illustratif : 40 utilisateurs, huit semaines, corpus de documents publics ou internes autorisés, aucune décision client et aucune donnée bancaire sensible.
Avant le démarrage, un échantillon de dossiers est traité manuellement pour établir la durée médiane, le taux d’erreur factuelle, le nombre de sources correctement citées et le coût par dossier. Pendant le pilote, les mêmes indicateurs sont mesurés, auxquels s’ajoutent les sorties corrigées par un humain, les réponses non étayées, les incidents de données, la latence et le coût d’inférence.
Une porte de décision peut exiger : aucun incident de confidentialité ; 100 % des affirmations matérielles reliées à une source vérifiable ; aucune dégradation de la qualité par rapport à la référence ; un gain de temps démontré ; un coût d’exploitation et de revue acceptable. Un gain de vitesse accompagné d’une hausse des erreurs ne justifie pas le passage à l’échelle.
4. Pilote 2 — Workflow low-code de traitement interne
Périmètre illustratif : 200 dossiers par mois, douze semaines, un processus interne réversible, des connecteurs approuvés et un propriétaire métier.
La référence initiale couvre le délai de traitement, le taux de dossiers repris, les erreurs de droits, les interventions manuelles et les jours de maintenance. Le pilote ajoute la disponibilité, les échecs de flux, les changements non autorisés, le temps de restauration, les comptes orphelins et le coût par dossier.
Le passage en production suppose notamment un test de retour arrière, une identité de service maîtrisée, l’absence de connecteur non déclaré, des contrôles d’accès testés et un responsable capable de maintenir le workflow. Si la logique ne peut être exportée, comprise ou restaurée, la rapidité de construction masque une dette opérationnelle.
5. Pilote 3 — Assistant de développement fondé sur l’IA
Périmètre illustratif : cinq développeurs, six semaines, dépôt non critique et interdiction de déploiement autonome en production.
La mesure compare le délai de livraison, le temps de revue, les défauts échappés aux tests, les dépendances ajoutées, les vulnérabilités connues, les secrets détectés et la part de code effectivement comprise par l’équipe. La productivité ne se résume pas au nombre de lignes acceptées.
Une porte de décision peut imposer : aucun secret dans le dépôt ou les prompts ; provenance vérifiable des dépendances ; analyses statiques et de composition logicielle sans défaut critique non accepté ; tests négatifs indépendants ; approbation humaine distincte de la génération ; procédure de retour arrière éprouvée.
Le schéma de décision reste identique pour les trois pilotes :
Référence initiale → Expérimentation limitée → Mesure des risques et de la valeur → Décision explicite
Hypothèses écrites → Preuves conservées → Poursuivre, corriger, reclasser ou arrêter
6. Acheter un service, c’est aussi acheter ses dépendances
Une démonstration commerciale évalue ce que le produit sait faire aujourd’hui. La diligence fournisseur doit évaluer ce que l’établissement pourra encore comprendre, contrôler et récupérer demain.
La grille d’achat minimale doit obtenir des réponses écrites sur les points suivants.
Données — Quelles entrées, sorties, métadonnées et télémétries sont collectées ? Sont-elles réutilisées pour entraîner ou améliorer un modèle ? Où sont-elles stockées, combien de temps et chez quels sous-traitants ?
Identités et administration — Le service prend-il en charge l’authentification fédérée, le moindre privilège, la séparation des rôles, les comptes de service et l’export des journaux ?
Modèles et changements — Le modèle, sa version et ses paramètres peuvent-ils être identifiés ? Quel préavis accompagne un changement matériel ? Une version antérieure ou un comportement stable peuvent-ils être conservés ou restaurés ?
Sécurité — Quelles preuves couvrent le développement sécurisé, la gestion des vulnérabilités, les tests d’intrusion, la chaîne logicielle et les incidents ?
Continuité — Quels sont les engagements de disponibilité, le délai maximal de reprise du service (RTO), la perte maximale de données admissible (RPO), les capacités dégradées et les résultats des tests de continuité ?
Audit et supervision — L’établissement, ses auditeurs et les autorités compétentes disposent-ils des droits d’accès, d’information, d’inspection et de coopération nécessaires ?
Notification — Dans quel délai un incident, une fuite, une vulnérabilité critique, une dégradation ou un changement de sous-traitant est-il signalé ?
Propriété intellectuelle — Qui détient les prompts, workflows, configurations, codes, données dérivées et sorties ? Quelles garanties couvrent la provenance du code, les licences open source et les réclamations de tiers ?
Responsabilité — Les plafonds et exclusions sont-ils cohérents avec le dommage possible ? Les atteintes à la confidentialité, à la sécurité, à la propriété intellectuelle ou aux obligations réglementaires font-elles l’objet de dispositions adaptées ?
Concentration et substituabilité — Quels composants critiques dépendent du même cloud, du même modèle ou du même sous-traitant ? Une solution de remplacement a-t-elle été évaluée ?
Portabilité et sortie — Les données, configurations, prompts système, journaux et règles peuvent-ils être exportés dans des formats documentés et exploitables ? Quel accompagnement est fourni à la sortie ?
Effacement et coûts — Une attestation d’effacement est-elle disponible ? Quels coûts de consommation, de dépassement, d’export, de sortie et d’assistance peuvent apparaître ?
DORA impose aux entités financières une gestion structurée du risque lié aux prestataires TIC. Pour les services soutenant une fonction critique ou importante, les contrats et stratégies de sortie doivent permettre une résiliation et une migration sans perturbation indue, avec des droits d’accès, d’audit et d’inspection adaptés. Le recours à un fournisseur ne transfère pas la responsabilité de l’établissement. Source : https://eur-lex.europa.eu/eli/reg/2022/2554/oj?locale=fr
Le contrat n’efface pas un risque de concentration ; il rend seulement ses conditions visibles. Un fournisseur impossible à remplacer reste une décision de risque à assumer au niveau approprié.
7. Le socle de sécurité du code et des automatisations
Le code généré, le workflow low-code et l’agent doivent être considérés comme non fiables jusqu’à preuve proportionnée du contraire. Un socle opérationnel peut être organisé en sept barrières.
Secrets et identités — Aucun secret ne doit être placé dans un prompt, un dépôt, une variable en clair ou un fichier de configuration partagé. Les secrets résident dans un coffre, sont renouvelables et associés à des identités dédiées. Les droits des agents et des comptes de service sont limités par action, ressource, environnement et durée.
Isolation — L’exécution d’un agent ou d’un code proposé par IA s’effectue dans un environnement isolé, sans accès implicite au poste, au réseau interne, aux données de production ou à Internet. Les sorties réseau, outils appelables, volumes d’opérations et ressources consommées sont plafonnés.
Dépendances — Les bibliothèques sont résolues dans des registres approuvés, verrouillées par version et soumises à une analyse de composition logicielle. Une nomenclature des composants, ou SBOM, facilite l’identification d’une dépendance vulnérable. Une bibliothèque suggérée par un modèle ne devient pas fiable parce que son nom paraît plausible.
Entrées et sorties — Les contrôles couvrent les injections SQL, commandes système, XSS, désérialisation, traversée de chemins et contournements d’autorisation. Pour les agents et applications fondés sur un grand modèle, ils couvrent aussi l’injection de prompt directe ou indirecte, l’exfiltration par outil et les sorties qui deviennent des instructions exécutables. Toute sortie est validée selon le contexte où elle sera utilisée.
Chaîne de livraison — Le dépôt, la branche, la revue, les propriétaires de code, les tests, les analyses statiques, les signatures d’artefacts, les approbations et le déploiement sont traçables. Le système qui génère un changement ne l’approuve pas seul.
Tests de rupture — Les tests positifs vérifient le cas attendu ; les tests négatifs recherchent les abus, les entrées ambiguës, les erreurs de droits, les refus de service, les changements de modèle et les comportements hors périmètre. Pour un usage matériel, une personne ou une équipe indépendante de la construction conçoit une partie des scénarios.
Exploitation — Limites de débit, seuils de dépense, mécanisme d’arrêt, journalisation, alertes, restauration et gestion d’incident sont testés avant l’ouverture. Un bouton d’arrêt non testé reste une hypothèse.
OWASP documente notamment les risques de dépendances inexistantes ou obsolètes, de fuite du contexte de prompt, d’injection indirecte, de modification hors périmètre et d’agents de développement disposant de droits excessifs. Sources : https://cheatsheetseries.owasp.org/cheatsheets/Secure_Coding_with_AI_Cheat_Sheet.html et https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html
Sur Power Platform, les politiques de données permettent de classer et de contraindre les connecteurs ; les politiques avancées peuvent soutenir une logique d’autorisation explicite. À ce jour, cette couverture avancée concerne principalement les connecteurs certifiés. Les connecteurs personnalisés et HTTP doivent rester encadrés par les politiques classiques et le filtrage des points de terminaison ; les connecteurs virtuels nécessitent un traitement distinct. Ces contrôles doivent être éprouvés dans les environnements concernés, car leur portée et leur effet dépendent de la configuration et du déploiement. Sources : https://learn.microsoft.com/fr-fr/power-platform/admin/wp-data-loss-prevention et https://learn.microsoft.com/fr-fr/power-platform/admin/advanced-connector-policies
Intention → Génération → Revue → Tests → Déploiement → Observation
Provenance et contexte → Séparation des rôles → Sécurité et métier → Retour arrière → Arrêt et incident
8. Auditer un modèle sans chercher une métrique magique
Un audit de modèle n’est ni une démonstration de précision moyenne ni une collection de captures d’écran. Il confronte une finalité, une population, un dommage possible et des seuils de décision.
9. Définir la décision et sa matérialité
La fiche d’audit précise la finalité autorisée, les utilisateurs, les personnes affectées, les données, les actions permises, le rôle de l’humain et la frontière au-delà de laquelle le système ne décide pas. Une aide à la rédaction et un classement influençant l’accès au crédit ne partagent ni les mêmes dommages ni les mêmes preuves.
10. Geler un jeu de référence
Le jeu de référence doit être représentatif des situations réelles, documenté, versionné et séparé des données ayant servi à régler le système. Il couvre les cas fréquents, rares, ambigus et adversariaux, ainsi que les segments susceptibles de subir des erreurs différentes. Sa qualité, sa fraîcheur et ses limites sont explicites.
11. Choisir des métriques liées au dommage
La performance peut combiner exactitude, précision, rappel, faux positifs, faux négatifs, calibration et coût des erreurs. Le choix dépend du cas : manquer une fraude et bloquer à tort un paiement n’ont pas le même impact.
L’équité ne possède pas de métrique universelle. Parité de sélection, égalité des taux d’erreur ou calibration peuvent entrer en tension. La métrique retenue doit correspondre au dommage, au cadre juridique, au processus et à la taille suffisante des échantillons. Les résultats par segment, les intervalles d’incertitude et les arbitrages sont documentés ; un score global ne doit pas masquer une dégradation locale.
12. Tester les explications et la robustesse
Une explication doit être utile à son destinataire : opérateur, client, contrôle interne, auditeur ou autorité. Les motifs fournis sont testés pour leur stabilité, leur fidélité au comportement et leur capacité à soutenir une contestation. La robustesse couvre les données manquantes, les changements de formulation, les entrées extrêmes, les attaques, la dérive et les changements du fournisseur.
13. Organiser une revue indépendante
L’ACPR a proposé une approche à deux volets : un audit analytique du code, des données et de la documentation, puis un audit empirique fondé notamment sur des explications, des jeux de référence et, lorsque pertinent, un modèle challenger construit par l’auditeur. Ce document est une contribution méthodologique, pas une règle universellement contraignante. Le modèle challenger aide à révéler des écarts ; il ne devient pas l’autorité qui approuve. Source : https://acpr.banque-france.fr/fr/publications-et-statistiques/publications/gouvernance-des-algorithmes-dintelligence-artificielle-dans-le-secteur-financier
14. Définir les déclencheurs de réévaluation
La surveillance porte sur la qualité des entrées, la performance, les écarts par segment, les explications, les refus ou corrections humaines, les incidents, la dérive, le coût et les changements de version. Une nouvelle finalité, une nouvelle population, un nouveau fournisseur, un changement significatif de données ou de modèle déclenchent une réévaluation. Une fréquence calendaire seule ne suffit pas.
Le NIST AI Risk Management Framework est un cadre volontaire. Il organise ce cycle autour de quatre fonctions complémentaires : Govern, Map, Measure et Manage. Il insiste sur la contextualisation, la mesure, les décisions go/no-go, la documentation des limites et le suivi pendant tout le cycle de vie. Source : https://airc.nist.gov/airmf-resources/airmf/5-sec-core/
15. L’encart juridique et contractuel à ne pas repousser
Les qualifications exactes dépendent du système, de l’usage, des parties, de la juridiction et du contrat. Elles doivent être établies avec les équipes juridiques, de conformité et de protection des données. Quelques questions ne peuvent toutefois pas attendre la fin du pilote.
Qui détermine les finalités et les moyens du traitement ? Qui agit comme responsable, sous-traitant, fournisseur, déployeur ou intégrateur selon les textes applicables ? Quelles obligations demeurent chez l’établissement malgré l’externalisation ?
Qui détient les entrées, prompts, règles, workflows, configurations, code généré et sorties ? Le fournisseur peut-il les réutiliser pour entraîner ou améliorer ses services ? La confidentialité et le secret des affaires sont-ils protégés ? La provenance et les licences des composants open source sont-elles vérifiables ? Une garantie et une indemnisation couvrent-elles une réclamation de propriété intellectuelle ?
Le contrat décrit-il les incidents, les délais de notification, les sous-traitants, les transferts, la conservation, l’effacement, les audits, la coopération avec les autorités, la réversibilité et l’assistance à la sortie ? Les plafonds de responsabilité sont-ils compatibles avec les scénarios de dommage ?
Le règlement européen sur l’IA ajoute des obligations selon le rôle et la catégorie du système. DORA encadre le risque lié aux prestataires TIC dans le secteur financier. Le RGPD demeure applicable aux traitements de données personnelles. Une validation générique de l’outil ne remplace donc pas l’analyse du cas d’usage.
Ce guide ne constitue pas un avis juridique ou réglementaire.
16. Observer assez pour gouverner, sans recréer un entrepôt de données sensibles
L’observabilité rend la doctrine applicable. Pour chaque exécution significative, les preuves peuvent inclure l’actif et son propriétaire, la finalité, l’environnement, le modèle ou l’outil et sa version, la catégorie de données utilisée, la version du code ou du workflow, les contrôles exécutés, la décision ou l’action produite, l’intervention humaine, les erreurs, la latence, le coût et le mécanisme d’arrêt disponible.
Cette traçabilité n’autorise pas à conserver indistinctement tous les prompts et toutes les sorties. Les journaux doivent être minimisés, filtrés, protégés par des droits, associés à une durée de conservation et adaptés au risque. Les secrets et données sensibles doivent être masqués ou exclus lorsque leur conservation n’est pas justifiée.
Construire → Observer → Comparer aux seuils → Décider → Conserver la preuve
Si un seuil est franchi → Corriger, reclasser ou arrêter → Reprendre le cycle
17. Réduire le shadow IT par les incitations, pas seulement par la surveillance
Le shadow IT est souvent le symptôme d’un besoin légitime confronté à un chemin officiel trop lent ou trop opaque. La réponse doit combiner découverte, sécurité et amélioration du service interne.
Un guichet d’entrée unique doit donner une réponse rapide : environnement d’exploration immédiat pour les cas à faible risque, délai annoncé pour les revues, interlocuteur identifiable et voie d’escalade. Les équipes qui déclarent un actif pendant une période de découverte doivent bénéficier d’une logique de régularisation plutôt que d’une sanction automatique, hors fraude ou violation délibérée.
Des sandboxes préconfigurées, des connecteurs autorisés, des composants certifiés, des permanences techniques, des champions métier et du mentorat réduisent le coût du comportement conforme. Un budget central de remédiation peut absorber la première mise sous contrôle d’actifs déjà devenus utiles ; laisser la totalité du coût au métier encourage la dissimulation.
Les droits augmentent avec la compétence démontrée, la sensibilité des données et l’autonomie demandée. La reconnaissance doit valoriser la réutilisation, la déclaration précoce, la qualité et le retrait propre, pas seulement la vitesse de livraison.
Le tableau de bord du shadow IT doit mesurer le délai d’obtention d’un environnement, le taux d’abandon des demandes, les actifs découverts, le taux de régularisation, l’âge des dérogations, les incidents, la réutilisation des composants et le temps de remédiation. Une hausse des contournements doit déclencher l’analyse des frictions et des incitations, pas uniquement un renforcement des interdictions.
18. Une mise en œuvre en 90 jours
Jours 1 à 30 — Voir et protéger. Inventorier les outils, actifs et fournisseurs déjà utilisés ; ouvrir une période de déclaration ; imposer le socle sur les données, secrets, identités et connecteurs ; sélectionner trois pilotes ; établir leurs références initiales ; désigner les responsables et les décideurs.
Jours 31 à 60 — Tester et produire des preuves. Exécuter les pilotes en sandbox ; appliquer la grille fournisseurs ; mettre en place la chaîne de sécurité ; constituer les jeux de référence ; définir les seuils, tests de rupture, journaux minimisés, procédures d’arrêt et scénarios de sortie.
Jours 61 à 90 — Décider et industrialiser. Tenir les revues go/no-go ; publier les composants et chemins approuvés ; affecter les budgets de maintenance et de remédiation ; contractualiser les engagements manquants ; arrêter les usages sans propriétaire ou sans valeur ; publier le premier tableau de bord de gouvernance.
À la fin des 90 jours, le succès ne se mesure pas au nombre de règles écrites. Il se mesure à la capacité de répondre rapidement à cinq questions : quels actifs existent, qui en répond, quelles données et actions sont permises, quelles preuves justifient leur exploitation et comment les arrêter sans désorganiser l’activité ?
19. Le véritable test d’une gouvernance
Une gouvernance crédible ne cherche pas à prévoir chaque outil futur. Elle installe une discipline stable face au changement : une finalité explicite, une responsabilité attribuée, des droits limités, une preuve proportionnée, une décision réversible et une surveillance utile.
La doctrine protège l’intention. L’exécution protège l’organisation.
Entre les deux se trouve le travail décisif : transformer les règles en chemins praticables, les contrôles en capacités réutilisables et les signaux d’alerte en décisions assumées.
20. Repères de référence
FINMA, enquête sur l’intelligence artificielle dans les établissements financiers suisses : https://www.finma.ch/fr/news/2025/04/20250424-mm-umfrage-ki/
Banque d’Angleterre et FCA, enquête 2024 sur l’IA dans les services financiers britanniques : https://www.bankofengland.co.uk/report/2024/artificial-intelligence-in-uk-financial-services-2024
Règlement européen DORA : https://eur-lex.europa.eu/eli/reg/2022/2554/oj?locale=fr
Règlement européen sur l’intelligence artificielle : https://eur-lex.europa.eu/legal-content/FR/TXT/?uri=CELEX:32024R1689
ACPR, gouvernance des algorithmes d’intelligence artificielle dans le secteur financier : https://acpr.banque-france.fr/fr/publications-et-statistiques/publications/gouvernance-des-algorithmes-dintelligence-artificielle-dans-le-secteur-financier
NIST AI Risk Management Framework : https://airc.nist.gov/airmf-resources/airmf/5-sec-core/
OWASP, Secure Coding with AI : https://cheatsheetseries.owasp.org/cheatsheets/Secure_Coding_with_AI_Cheat_Sheet.html
Microsoft, politiques de données Power Platform : https://learn.microsoft.com/fr-fr/power-platform/admin/wp-data-loss-prevention