Travailler chez BMO, l'une des cinq grandes banques canadiennes, tout en étant quelqu'un qui suit de près le domaine du développement IA m'a placé dans une position intéressante. Je tiens profondément à utiliser des outils modernes pour construire de meilleurs logiciels plus rapidement. Et le secteur bancaire est un environnement où chaque outil, chaque flux de données et chaque service externe est censé passer par des couches de revue de sécurité, de validation de conformité et d'évaluation des risques avant de toucher la production.
Ces deux réalités ne sont pas incompatibles, mais les réconcilier demande une vision lucide de l'endroit où passent les lignes et du pourquoi. Ce qui suit n'est ni une défense de la prudence en entreprise ni une plainte à son sujet. C'est ce que j'ai trouvé utile à l'intérieur des contraintes.
La contrainte fondamentale : la confidentialité des données
La chose la plus importante à comprendre sur l'utilisation de l'IA dans le secteur bancaire est que la contrainte ne porte pas sur le fait d'être anti-technologie. C'est une question de données. Les banques détiennent certaines des données personnelles et financières les plus sensibles qui existent : numéros de compte, historiques de transactions, profils de crédit, données financières d'entreprises, informations personnelles identifiables de millions de clients. Les cadres qui régissent ces données au Canada, dont la LPRPDE et les lignes directrices du BSIF, ne sont pas optionnels et ne sont pas abstraits.
Quand vous collez du code dans un outil IA commercial, ce code contient potentiellement du contexte. Des noms de variables, des endpoints d'API, des noms de colonnes de base de données, de la logique métier qui suggère des structures de produits. Même si vous ne collez pas de données clients réelles, vous pourriez révéler une architecture système confidentielle. C'est une préoccupation réelle, et je le dis en tant que quelqu'un qui veut utiliser ces outils autant que possible.
Ce que vous ne pouvez pas partager avec les outils IA
Voici ma liste pratique de travail de ce qui ne va absolument pas dans un outil IA externe dans un contexte bancaire :
- Toute donnée client réelle, même des échantillons 'anonymisés'. Le risque de ré-identification est réel
- Les URLs d'endpoints d'API internes ou les schémas qui ne sont pas documentés publiquement
- Les noms de tables et de colonnes de bases de données des systèmes de production
- Les flux d'authentification, les structures de tokens ou la logique de middleware de sécurité
- La logique métier qui révèle des fonctionnalités produit non publiées ou des stratégies de tarification
- Les workflows de conformité, les implémentations de pistes d'audit ou le code de reporting réglementaire
- Tout ce qui est marqué confidentiel, propriétaire ou interne dans le système de classification de votre organisation
- Le code des dépôts à accès restreint
Ce n'est pas une liste juridique exhaustive. C'est le travail de l'équipe sécurité de votre organisation. C'est mon heuristique personnelle de fonctionnement. En cas de doute, je retire le contexte de manière agressive avant de formuler un prompt.
Ce que vous pouvez faire avec l'IA dans le secteur bancaire
La liste ci-dessus semble limitante. La majorité des problèmes difficiles dans le développement Angular en entreprise ne sont pas spécifiques au secteur bancaire. Ce sont des problèmes de scalabilité, de patterns, de tests et d'architecture. Et l'IA est extrêmement utile pour tout cela.
- Générer du boilerplate pour les composants, services et tests en utilisant des schémas génériques ou anonymisés
- Expliquer des concepts, des patterns et des API Angular que vous connaissez moins bien
- Déboguer des erreurs de compilation TypeScript en collant des messages d'erreur assainis
- Refactoriser de la logique en utilisant des structures de données abstraites (remplacer les vrais noms de champs par des noms génériques)
- Écrire des fonctions utilitaires : formateurs de dates, validateurs, transformateurs de chaînes. Elles ne contiennent aucune donnée sensible
- Réviser l'accessibilité : patterns ARIA, navigation clavier, gestion du focus
- Rédiger de la documentation, des commentaires ou des descriptions de PR à partir de code assaini
- Apprendre les opérateurs RxJS, les patterns de signals ou les mécanismes internes d'Angular
La compétence clé est l'abstraction. Je suis devenu bon pour transformer un problème réel en une version structurellement équivalente mais neutre en termes de données du même problème. Les détails spécifiques au secteur bancaire vivent dans ma tête et dans nos systèmes internes. L'IA m'aide à résoudre le défi structurel.
Un exemple concret d'abstraction sûre
Voici à quoi ressemble l'abstraction. Le système ci-dessous est inventé pour cet article, parce que le vrai ne m'appartient pas et ne peut pas être publié, mais la forme de l'erreur est identique. Disons qu'un composant interroge un endpoint et affiche un nombre tiré de la réponse, et que je veux de l'aide avec le pattern de réactivité. Voici la version que je n'enverrais jamais :
// DON'T DO THIS
Here is our FleetStatusComponent that pulls from the /api/v2/fleet/summary endpoint.
It reads from fleetState.activeVehicles and needs to refresh every 30s...
[actual internal code pasted here]Au lieu de cela, j'abstrais complètement :
// DO THIS INSTEAD
I have an Angular component that polls a REST endpoint every 30 seconds and displays
a numeric value from the response. Using signals, I need to handle:
1. A loading state on initial fetch
2. A silent background refresh (no loading spinner on re-poll)
3. An error state that doesn't clear the last known good value
The endpoint returns { value: number; lastUpdated: string }.
What's a clean signal-based pattern for this?Le second prompt me donne tout ce dont j'ai besoin pour résoudre le vrai problème et ne révèle rien du système dont il provient. Le défi technique est identique. Les données sont génériques. Cette étape de traduction, c'est tout le savoir-faire.
Processus d'approbation des outils IA en entreprise
Au-delà des préoccupations liées aux données, l'utilisation de l'IA en entreprise passe par un processus d'approvisionnement et de revue de sécurité. Si votre organisation évalue un outil IA, un plugin d'assistant de code pour IDE, un abonnement LLM entreprise, une licence GitHub Copilot Business, attendez-vous à ce que ce processus prenne des mois, pas des jours. Cela implique des évaluations de sécurité du fournisseur, des accords de traitement des données, l'examen de l'endroit où vos données sont stockées et de leur utilisation pour l'entraînement, et la validation par de multiples parties prenantes.
C'est frustrant d'un point de vue productivité. Le temps que l'outil passe la revue, la version que vous avez évaluée peut être obsolète. J'en suis aussi venu à respecter pourquoi ce processus existe. Une violation de données impliquant la chaîne d'outils de développement d'une banque n'est pas un scénario hypothétique. C'est arrivé à des institutions financières dans le monde entier. La prudence est calibrée sur un risque réel.
Mon conseil pour naviguer dans ce processus : poussez tôt et fournissez des preuves. Si vous voulez qu'un outil soit approuvé, construisez un dossier qui inclut la documentation de sécurité, les spécificités des cas d'usage, et des institutions comparables qui l'ont déjà adopté. Les champions internes qui peuvent articuler les contrôles de risque en même temps que les bénéfices de productivité avancent plus vite que le pur enthousiasme.
Outils IA internes : la meilleure voie
La vraie réponse n'est pas une façon plus sûre d'utiliser un outil commercial externe. C'est un modèle qui tourne là où les données se trouvent déjà. La version gratuite est plus proche que la plupart des gens ne le pensent. Des modèles à poids ouverts servis localement avec Ollama ou llama.cpp ne coûtent rien de plus que le matériel que vous possédez déjà, ne font aucun appel réseau, et sont assez bons pour le boilerplate, les explications et l'écriture de tests, qui représentent de toute façon l'essentiel de l'usage quotidien. Vous pouvez prouver l'idée sur un portable avant que quiconque signe un contrat, et une démo locale qui fonctionne est un bien meilleur argument dans une discussion d'approvisionnement qu'une diapositive.
La version payante, c'est la même idée avec les GPU de quelqu'un d'autre et un contrat signé : un déploiement géré à l'intérieur de votre propre tenancy cloud, où les prompts et les résultats restent dans le périmètre de l'organisation. Dans les deux cas, le compromis est le même. Ces modèles sont plus faibles que les modèles de pointe que vous utilisez à titre personnel, et vous pouvez leur donner le contexte complet. Un modèle plus faible avec le vrai problème sous les yeux bat un modèle plus fort pour lequel vous avez dû tout abstraire.
Si vous pouvez influencer la décision, plaidez pour le déploiement que vous contrôlez plutôt que pour l'abonnement que vous ne contrôlez pas. L'écart de capacité se réduit tous les quelques mois. L'écart de conformité, non.
Ce à quoi ressemble la productivité en pratique
Étant donné toutes les contraintes, à quoi ressemble mon workflow augmenté par l'IA au travail ? Chez BMO, l'équipe utilise un assistant approuvé, GitHub Copilot Business, que j'ai configuré avec des guardrails. Dans ce cadre, j'utilise l'IA grosso modo pour ces choses, grosso modo dans cet ordre de fréquence :
- 1. Générer du boilerplate de composants et services à partir de spécifications assainies. C'est là que le gain de temps est le plus évident
- 2. Écrire des cas de test à partir de comportements décrits. Le pattern de prompt basé scénario que j'utilise me donne la plupart des cas de test utiles sans code sensible
- 3. Expliquer des API ou des mécanismes internes Angular peu familiers que je rencontre dans le code existant
- 4. Rédiger des descriptions de PR à partir de diffs assainis
- 5. Refactoriser des versions abstraites de problèmes de performance. Puis appliquer manuellement le pattern au vrai code
Je n'utilise pas l'IA pour : tout ce qui touche à l'authentification, tout ce qui nécessiterait de partager des schémas internes, toute tâche où le contexte lui-même est sensible. Pour ceux-là, je travaille de manière traditionnelle, ce qui reste parfaitement rapide quand on a plus de dix ans d'expérience.
Il y a une tension évidente dans tout cela, et c'est la première question qu'un lecteur attentif devrait poser. Si rien d'interne ne va vers un outil IA, que fait un assistant d'IDE avec le dépôt ouvert devant lui ? Ce ne sont pas les mêmes canaux. Copilot Business lit l'espace de travail ouvert sous contrat : les prompts et les suggestions ne sont pas conservés et ne servent pas à entraîner des modèles, et les administrateurs peuvent exclure des chemins pour que l'assistant ne les voie jamais. C'est un canal revu, avec une trace écrite. Une fenêtre de clavardage grand public, non. La discipline d'abstraction de cet article concerne ce second canal et tout ce que le contrat ne couvre pas. Le premier est régi par la liste d'exclusions de contenu et par les dépôts sur lesquels la licence est activée, et si vous ne savez pas ce qui figure sur cette liste d'exclusions pour votre propre dépôt, c'est la chose à aller vérifier aujourd'hui.
Le côté culturel : les attitudes des collègues
Une chose que je n'avais pas anticipée est à quel point les attitudes envers les outils IA divergent dans une grande organisation. Le scepticisme est courant, parfois sur la qualité des résultats, parfois sur le risque lié aux données, et les deux versions sont des positions raisonnables défendues par de bons développeurs. Ce qui m'a le plus surpris, c'est le nombre de gens qui traitent la question comme binaire : soit l'outil est approuvé pour tout, soit il est totalement interdit. Ce n'est ni l'un ni l'autre. La conversation utile ne commence qu'une fois cette supposition écartée.
J'essaie de tenir une position précise : enthousiaste quant à la productivité, rigoureux sur les contraintes, et vocal en faveur de meilleurs outils internes. Je ne suis pas la personne qui dit aux collègues ce qu'ils ne peuvent pas utiliser. Je suis la personne qui dit voici comment utiliser ça pour que ça ne devienne pas votre problème dans six mois.
Ce que je dirais à mon moi passé
Si je pouvais donner un seul conseil à quelqu'un rejoignant une grande institution financière avec un état d'esprit orienté IA : n'arrivez pas en vous attendant à brancher directement votre workflow personnel. Les outils que vous adorez en dehors du travail ne sont peut-être pas approuvés. Les données que vous donneriez normalement comme contexte sont interdites. C'est réel, et s'adapter prend du temps.
Mais les compétences sous-jacentes du prompt engineering, savoir quoi demander et comment structurer la question, sont entièrement transférables. Vous les redirigez simplement. Au lieu de prompter avec le contexte complet, vous apprenez à prompter avec des abstractions précises. Au lieu d'obtenir une solution complète, vous obtenez un pattern structurel que vous appliquez avec vos connaissances internes. C'est un rythme différent mais pas moins productif. Une fois que vous vous êtes adapté.
La contrainte n'est pas l'ennemie de la productivité. La contrainte est le paramètre autour duquel on conçoit. Les ingénieurs font cela tous les jours.
Références
- Ollama, pour exécuter des modèles à poids ouverts localement. https://ollama.com
- Azure OpenAI Service. https://azure.microsoft.com/en-us/products/ai-services/openai-service
- AWS Bedrock. https://aws.amazon.com/bedrock/
- PIPEDA. https://www.priv.gc.ca/en/privacy-topics/privacy-laws-in-canada/the-personal-information-protection-and-electronic-documents-act-pipeda/