ISO IEC 42001 et gouvernance de l'IA Les angles morts du déploiement des agents intelligents
Déployer un agent intelligent n’est pas seulement une question de modèle, de données et de performance. C’est une question de contrôle. Qui décide ce que l’agent peut faire? Qui vérifie ses réponses? Qui surveille les outils qu’il appelle? Qui arrête le système si le risque devient trop élevé?
Au Québec et au Canada, les règles encadrent déjà une partie de ces enjeux. La Loi 25 impose des exigences fortes sur les renseignements personnels et les Évaluations des facteurs relatifs à la vie privée. L’AMF demande une gouvernance claire de l’utilisation de l’IA dans les institutions financières. Le BSIF insiste sur le risque de modélisation, la gestion des tiers et la résilience technologique.
Mais ces cadres ne disent pas toujours comment exploiter un système d’IA au quotidien. Ils posent les attentes. Ils ne donnent pas le mode d’emploi complet.
C’est là que la norme ISO/IEC 42001 devient utile. Elle propose un système de management de l’intelligence artificielle, souvent appelé SMIA. Son intérêt n’est pas de remplacer la loi. Son rôle est de transformer les obligations générales en pratiques concrètes, auditables et répétables.
Ce que la conformité juridique ne couvre pas toujours
Une politique d’utilisation de l’IA ne suffit pas. Une clause de confidentialité ne suffit pas non plus. Même une ÉFVP bien préparée peut rester incomplète si personne ne surveille le système après son lancement.
Le problème vient souvent du vide opérationnel. Une organisation peut respecter plusieurs exigences sur papier, tout en étant incapable de répondre à des questions simples après le déploiement.
Par exemple :
Quel modèle a produit cette décision?
Quelle version était en production ce jour-là?
Quelles données ont été envoyées à une API externe?
L’agent avait-il le droit d’utiliser cet outil?
Qui a approuvé ce changement de comportement?
Comment détecte-t-on une dérive du modèle?
Que se passe-t-il si l’agent pose une action non prévue?
Ces questions deviennent critiques avec les LLM, l’IA générative et les architectures multi-agents. Un agent ne se limite pas à prédire ou classer. Il peut planifier, appeler des outils, consulter une base de données, résumer un dossier, déclencher un flux de travail ou communiquer avec un système tiers.
Plus l’agent gagne en autonomie, plus la gouvernance doit passer d’un document statique à un système vivant.
Le risque principal n’est pas seulement que l’IA se trompe. Le risque est de ne pas savoir exactement où, quand, pourquoi et sous quelle autorité elle s’est trompée.
Ce que la norme ISO/IEC 42001 apporte aux dirigeants
ISO/IEC 42001 structure la gouvernance de l’IA comme un système de management. L’approche ressemble à d’autres normes ISO connues : définir le contexte, attribuer les responsabilités, gérer les risques, documenter les contrôles, surveiller la performance et améliorer le système.
Pour une direction, l’avantage est clair. La norme aide à passer de la bonne intention à une discipline d’exploitation.
Elle soutient notamment :
la définition des rôles et responsabilités;
la classification des systèmes selon le risque;
la gestion du cycle de vie des systèmes d’IA;
la documentation des données, modèles, outils et décisions;
la supervision humaine;
le suivi des fournisseurs;
la gestion des incidents;
l’amélioration continue.
Elle ne garantit pas qu’un système d’IA sera sans risque. Aucun cadre sérieux ne peut promettre cela. Elle aide plutôt à démontrer que l’organisation a mis en place une méthode cohérente pour identifier, réduire et surveiller les risques.
Au Canada, cette logique s’accorde avec les attentes de l’AMF et du BSIF. Elle s’accorde aussi avec l’esprit de la Loi 25, surtout lorsque des renseignements personnels sont utilisés, transférés ou traités par des systèmes algorithmiques.
Les 4 angles morts du déploiement des agents intelligents
1. L’absence de propriétaire réel du cycle de vie
Le premier angle mort est organisationnel. Beaucoup d’équipes savent qui a développé le prototype. Moins savent qui possède le système une fois en production.
Un agent intelligent traverse plusieurs étapes :
cadrage du cas d’usage;
sélection du modèle;
choix des données;
intégration des outils;
tests;
mise en production;
surveillance;
mise à jour;
retrait ou remplacement.
Chaque étape crée des risques différents. Si la direction approuve le projet au départ, puis disparaît du processus, la gouvernance devient fragile.
La bonne pratique consiste à nommer un propriétaire du système d’IA, appuyé par des rôles clairs. Le propriétaire n’a pas à être la personne la plus technique. Il doit plutôt avoir l’autorité nécessaire pour faire respecter les contrôles, demander des preuves et suspendre un usage si le risque dépasse le seuil accepté.
ISO/IEC 42001 pousse les organisations à documenter cette chaîne de responsabilité. Cela réduit le flou entre les équipes juridiques, TI, données, conformité, cybersécurité et opérations.
2. La sous-estimation des données sensibles et des transferts
Le deuxième angle mort touche les données. Les agents intelligents mélangent souvent plusieurs sources d’information : courriels, documents internes, historiques clients, transcriptions, tickets de soutien, contrats, données transactionnelles ou dossiers RH.
Le risque augmente quand ces données sortent de l’environnement contrôlé de l’organisation. Cela peut arriver avec une API de modèle, un service infonuagique, un connecteur externe ou une chaîne d’outils mal configurée.
Au Québec, la Loi 25 exige une analyse sérieuse lorsque des renseignements personnels sont communiqués hors Québec ou traités par un fournisseur. L’ÉFVP devient alors un outil central, pas une formalité.
Pour un agent intelligent, l’ÉFVP doit tenir compte de scénarios précis :
l’agent peut inclure des renseignements personnels dans une requête;
le modèle peut produire une réponse contenant des données confidentielles;
un connecteur peut accéder à plus d’information que nécessaire;
un journal d’activité peut conserver des extraits sensibles;
une base vectorielle peut rendre des données récupérables par erreur.
La norme ISO/IEC 42001 aide à intégrer ces contrôles dans le fonctionnement normal du système. Elle invite à documenter les sources de données, les usages permis, les limites, les mesures de protection et les responsabilités liées aux fournisseurs.
3. La dépendance aux fournisseurs et aux API tierces
Le troisième angle mort concerne les dépendances externes. Un système d’IA moderne repose rarement sur un seul composant. Il peut combiner un LLM, une base vectorielle, un outil de recherche, un module de classification, une API de traduction, un système CRM et un moteur d’automatisation.
Chaque dépendance ajoute une surface de risque.
Le BSIF insiste déjà sur la gestion du risque lié aux tiers et à la résilience opérationnelle. Dans le contexte de l’IA, ce risque devient plus fin. Il ne suffit pas de savoir qu’un fournisseur est fiable. Il faut comprendre ce que le système lui envoie, ce qu’il reçoit, ce qui est journalisé, ce qui est conservé et ce qui peut changer sans préavis.
Les agents autonomes ajoutent une difficulté particulière : le `tool chaining`. L’agent peut enchaîner plusieurs outils pour atteindre un objectif. Une action isolée semble faible risque. La combinaison peut produire un résultat inattendu.
Par exemple, un agent autorisé à lire une base documentaire, rédiger un courriel et créer une tâche peut, selon sa configuration, exposer des informations à la mauvaise personne ou déclencher une action sans validation suffisante.
La réponse n’est pas d’interdire tous les outils. Il faut plutôt définir :
les outils permis;
les outils interdits;
les seuils où l’humain doit approuver;
les données que l’agent peut consulter;
les actions que l’agent peut exécuter seul;
les journaux nécessaires pour retracer les décisions.
4. Le manque de surveillance après la mise en production
Le quatrième angle mort est le plus courant : traiter le lancement comme la fin du projet.
Un système d’IA peut se dégrader après sa mise en production. Les données changent. Les comportements des utilisateurs changent. Le fournisseur modifie son modèle. Les instructions système évoluent. Les attaques par injection de prompt deviennent plus ciblées. Les utilisateurs trouvent des manières imprévues de contourner les limites.
La validation initiale ne suffit donc pas. Il faut surveiller les entrants, les incidents, les plaintes, les exceptions et les changements de performance.
Dans le cas d’un agent intelligent, la surveillance doit couvrir au moins quatre éléments :
la qualité des réponses;
le respect des limites d’usage;
les appels d’outils;
les signaux d’anomalie ou d’abus.
Cette surveillance doit aussi être liée à un processus de changement. Une modification de prompt, de modèle, de base de connaissances ou d’outil peut changer le profil de risque. Elle mérite donc une revue proportionnée.
ISO/IEC 42001 soutient cette logique par l’amélioration continue. L’organisation ne se contente pas de documenter le système au départ. Elle garde des preuves de suivi, de correction et de décision.
Lors de nos audits d'architecture GRC-T, nous observons que les vulnérabilités ne proviennent presque jamais de la mauvaise foi, mais plutôt de zones d'ombre en ingénierie que la législation ne précise pas et qui sont souvent négligées :
1. L'illusion du « Human-in-the-Loop » (L'humain dans la boucle)
De nombreuses entreprises prétendent qu'un employé vérifie les résultats produits par l'IA. En réalité, le biais d'automatisation entraîne une confiance aveugle des employés envers les suggestions de la machine. Sans critères de validation documentés et mesurables (conformément à l'ISO/IEC 42001), la présence humaine se réduit à une simple formalité qui n'exonère pas l'entreprise de sa responsabilité.
2. Le risque de l'IA agentive et le « Tool Chaining »
Contrairement à un simple chatbot, les agents intelligents modernes effectuent des actions : ils interrogent des bases de données CRM, appellent des API tierces, génèrent du code ou envoient des courriels. Si un agent a des autorisations d'accès excessives ou est victime d'une injection de requête malveillante (prompt injection), il peut exfiltrer des données confidentielles sans qu'aucun pare-feu traditionnel ne le détecte.
3. La dérive du modèle et le calibrage dynamique
Un système d'IA n'est pas un logiciel statique. Les modèles qui sont continuellement entraînés ou ajustés subissent une dérive (model drift). Sans un suivi régulier de la performance et de la qualité des données d'apprentissage (exigé par l'ISO/IEC 42001 et ISO/IEC 38507), le système peut commencer à produire des résultats discriminatoires ou inexacts des mois après son déploiement initial.
Comment mettre en place une gouvernance opérationnelle efficace
1. Cartographiez tous les systèmes d’IA et agents actifs
Commencez par un inventaire. Il doit inclure les projets officiels, les prototypes, les outils achetés par les équipes et les usages intégrés dans les logiciels existants.
Pour chaque système, documentez :
le cas d’usage;
les utilisateurs;
les données utilisées;
le modèle ou le fournisseur;
les outils connectés;
le niveau d’autonomie;
les décisions ou recommandations produites;
les contrôles en place.
Sans inventaire, la gouvernance reste théorique.
2. Classez les usages selon le risque réel
Tous les systèmes d’IA ne posent pas le même risque. Un outil qui reformule du contenu public n’a pas le même poids qu’un agent qui analyse des données clients ou recommande une décision financière.
La classification devrait tenir compte de plusieurs facteurs :
impact sur les personnes;
présence de renseignements personnels;
sensibilité des données;
niveau d’autonomie;
dépendance à des tiers;
possibilité d’erreur difficile à détecter;
portée juridique, financière ou réputationnelle.
Cette classification permet d’appliquer des contrôles proportionnés. Les systèmes à faible risque n’ont pas besoin du même niveau de revue qu’un agent qui agit sur des dossiers sensibles.
3. Définissez les limites d’autonomie des agents
Un agent intelligent doit avoir un périmètre clair. Il faut écrire ce qu’il peut faire, ce qu’il ne peut pas faire et ce qui exige une approbation humaine.
Les limites devraient couvrir :
l’accès aux données;
les outils autorisés;
les actions permises;
les seuils de confiance;
les cas où l’agent doit arrêter;
les messages à transmettre aux utilisateurs;
les mécanismes de journalisation.
Une règle simple aide : plus l’action est difficile à renverser, plus la supervision humaine doit être forte.
4. Intégrez l’ÉFVP et la cybersécurité dès la conception
La protection de la vie privée ne doit pas arriver après l’intégration technique. Elle doit guider les choix d’architecture.
Avant le déploiement, vérifiez :
quelles données entrent dans le système;
quelles données sortent;
où elles sont traitées;
combien de temps elles sont conservées;
qui peut y accéder;
comment les journaux sont protégés;
comment les fournisseurs respectent les exigences contractuelles.
La cybersécurité doit aussi couvrir les risques propres aux LLM, comme l’injection de prompt, l’exfiltration de données par réponse générée et les accès excessifs aux outils.
5. Documentez les preuves de contrôle
La gouvernance ne vaut pas grand-chose si elle ne laisse aucune trace. Les régulateurs, auditeurs et comités internes chercheront des preuves.
Conservez notamment :
les décisions d’approbation;
les évaluations de risque;
les résultats de tests;
les revues de fournisseurs;
les changements de configuration;
les incidents et correctifs;
les validations périodiques;
les retraits ou suspensions de systèmes.
Cette documentation doit être utilisable. Un registre incomplet ou jamais mis à jour crée un faux sentiment de sécurité.
6. Mettez en place une surveillance continue
La surveillance doit être adaptée au niveau de risque. Pour un agent à faible impact, un échantillonnage régulier peut suffire. Pour un système sensible, il faut des alertes, des revues fréquentes et des mécanismes d’arrêt.
Surveillez les éléments suivants :
Élément à surveiller | Exemple de signal utile |
Qualité des réponses | Hausse des corrections humaines |
Respect des limites | Appels d’outils non prévus |
Données sensibles | Présence de renseignements personnels dans les sorties |
Dérive du comportement | Réponses qui s’éloignent des consignes validées |
Fournisseurs | Changement de modèle, de conditions ou de lieu de traitement |
La surveillance donne de la valeur seulement si elle mène à des décisions. Il faut donc prévoir qui reçoit les alertes, qui enquête et qui peut suspendre le système.
À quoi ressemble une gouvernance réussie
Une organisation bien préparée ne cherche pas à prouver que son IA est parfaite. Elle peut plutôt démontrer qu’elle comprend ses systèmes, qu’elle connaît les risques et qu’elle applique des contrôles adaptés.
Concrètement, elle sait répondre à ces questions :
Quels agents sont en production?
Qui en est responsable?
Quels fournisseurs interviennent?
Quelles données sont traitées?
Quels contrôles limitent l’autonomie?
Quels tests ont été réalisés?
Quels incidents ont été observés?
Quelles améliorations ont été appliquées?
C’est cette capacité de démonstration qui fait la différence entre une conformité de façade et une gouvernance réelle.
La loi fixe les attentes. Les lignes directrices précisent les responsabilités. ISO/IEC 42001 aide à bâtir la structure opérationnelle qui relie le tout.
Pour les organisations québécoises et canadiennes, le bon prochain geste consiste à partir d’un inventaire, classer les systèmes selon le risque, puis bâtir un SMIA proportionné. Les agents intelligents peuvent créer de la valeur, mais seulement si leur autonomie reste visible, encadrée et vérifiable.