Risques IA générative en entreprise : les cadrer

Typologie des risques propres à l'IA générative

L'IA générative n'est pas un risque numérique comme un autre. Elle se diffuse par capillarité dans tous les métiers, brouille la frontière entre données internes et services externes, et évolue plus vite que les processus de contrôle qui devraient l'encadrer^[4]. Un dirigeant de PME/ETI se retrouve donc face à une catégorie de risque hybride, à la fois technique, juridique, opérationnel et réputationnel.

Selon Deloitte, en avril 2026, les dépenses mondiales des entreprises en IA générative auraient triplé en un an, passant d'environ 15 à 50 milliards de dollars canadiens^[2]. Cette adoption va plus vite que la mise en place des mécanismes de gouvernance associés, ce qui alimente des risques réglementaires, financiers et réputationnels^[2]. Le chiffre date, à vérifier pour l'exercice en cours.

Les catégories qui reviennent le plus souvent dans les analyses de cabinets et de normalisateurs sont proches : protection des données personnelles, biais, inégalité de traitement, sécurité et sûreté des systèmes^[1]. À cela s'ajoutent, côté usage, la dépendance à un fournisseur, les décisions influencées par des sorties erronées et les non-conformités liées à un cadre réglementaire mouvant^[7]. Pour un lecteur qui souhaite structurer cette lecture, la démarche d'évaluation des risques IA fournit un point d'ancrage.

Regroupement issu des analyses ISO, Deloitte et de retours de terrain de cabinets spécialisés.

1Fuite de données vers modèles tiers

2Shadow AI et perte de traçabilité

3Décisions biaisées ou erronées

4Fraude documentaire et vulnérabilités inédites

Sources 1, 2, 4 et 6 du dossier.

Shadow AI et dette invisible

Le premier risque, dans la majorité des PME, n'est pas technique. Il tient au fait que la direction ne sait pas quelles IA sont utilisées, par qui, avec quelles données et pour quels usages^[7]. Les collaborateurs ouvrent un compte gratuit sur un outil génératif, l'utilisent pour rédiger un courrier client, résumer un contrat ou trier des candidatures, et personne ne le documente.

Un cabinet spécialisé parle de dette invisible : des usages qui s'accumulent sans cadre, sans traçabilité, sans propriétaire, et de dépendances à des briques IA, API et fournisseurs qui créent des angles morts^[4]. La formule n'a pas de valeur officielle, mais l'observation qualitative est cohérente avec ce que décrivent d'autres analyses : l'IA s'intègre dans les processus essentiels sans que la surveillance ne suive^[2].

Interdire n'est pas une réponse tenable. Selon le même cabinet, l'interdiction pousse les usages vers le shadow AI, plus difficile à maîtriser qu'un usage encadré^[4]. Le préalable réaliste : un audit des usages pour rendre visible ce qui circule réellement, avant d'écrire une politique. La cartographie des systèmes IA attendue par ISO/IEC 42001 remplit exactement cette fonction.

Fuites de données vers les modèles tiers

Deuxième famille, la plus documentée : les données sensibles envoyées à des modèles externes sans contrôle ni chiffrement^[4]. Un collaborateur colle une liste de clients pour la reformater, un juriste soumet un projet de contrat pour le résumer, un développeur envoie un extrait de code propriétaire pour le déboguer. Le prompt part chez le fournisseur, et selon les conditions contractuelles, peut être conservé, journalisé ou utilisé pour l'entraînement.

Le risque se lit sur trois axes. Sur le plan des données personnelles, l'obligation de licéité, de finalité et de minimisation portée par la nLPD ou le RGPD reste intacte, quel que soit l'outil. Sur le plan du secret d'affaires, un prompt envoyé peut échapper au périmètre juridique de protection. Sur le plan sécurité, l'injection de prompt et l'exfiltration ouvrent des vulnérabilités inédites que les architectures classiques ne couvrent pas^[4].

Pour la direction, la question n'est donc pas de savoir si un incident arrivera, mais de savoir quelles règles s'appliquent quand il arrivera. Cela suppose un inventaire, une politique d'usage écrite, des outils validés pour les données sensibles et une supervision humaine. C'est précisément l'objet d'un SMIA conforme à ISO/IEC 42001, qui traite ces objets comme des exigences documentées, pas comme des recommandations optionnelles.

Fraude documentaire générée par l'IA

Une troisième famille émerge, plus récente : la fraude documentaire industrialisée. L'IA générative produit désormais en quelques secondes des factures, reçus, contrats, attestations et courriers officiels crédibles, difficiles à distinguer de documents légitimes^[6]. La fraude n'est plus artisanale, elle devient silencieuse et massive.

Selon un article de janvier 2026 sur ce phénomène, plus de 200 millions de dollars de pertes liées aux fraudes par deepfakes auraient été enregistrés à l'échelle mondiale sur le seul premier trimestre 2025, et les pertes liées aux escroqueries à l'identité alimentées par l'IA pourraient dépasser 40 milliards de dollars d'ici 2027^[6]. Ces chiffres proviennent d'une source de niveau cabinet, à recouper sur une source officielle avant tout usage externe. Vérifier l'évolution depuis cette date.

La conséquence opérationnelle : les contrôles reposant sur la vérification visuelle, la conformité du format et la confiance dans la pièce justificative ne suffisent plus^[6]. Pour une PME qui traite des notes de frais, des factures fournisseurs ou des dossiers clients, cela signifie revisiter les processus de validation et intégrer des contrôles complémentaires. Ce risque, souvent négligé, entre pleinement dans la analyse d'impact des systèmes d'IA.

Ce que la clause 6.1 attend du dirigeant

ISO/IEC 42001 est décrite par l'ISO comme la première norme mondiale de système de management de l'IA. Elle couvre l'éthique, la responsabilité, la transparence, la protection des données, et propose une approche intégrée allant de l'évaluation du risque à son traitement effectif^[1]. La clause 6.1, sur la planification face aux risques et opportunités, est le pivot de cette logique.

En pratique, elle attend trois choses. D'abord, une identification structurée des risques liés aux systèmes d'IA, en tenant compte du contexte, des parties intéressées et du périmètre du SMIA. Ensuite, une appréciation reproductible : critères de vraisemblance et de conséquence, échelles claires, arbitrages tracés. Enfin, un plan de traitement qui affecte des mesures, des responsables et des délais. La démarche est détaillée dans notre article dédié à l'appréciation des risques IA selon la clause 6.1.2.

Ce que la clause 6.1 n'exige pas : une méthode unique. Une PME peut s'appuyer sur ISO 31000, sur EBIOS Risk Manager ou sur sa méthode ISO 27001 existante, à condition de couvrir les spécificités IA : biais, dérive du modèle, explicabilité, données d'entraînement, supervision humaine. Ce point est repris dans plusieurs référentiels de management d'IA^[8].

Articulation avec l'AI Act

L'EU AI Act et ISO/IEC 42001 ne se recouvrent pas complètement. L'AI Act fixe un cadre légal fondé sur le niveau de risque des systèmes, avec une prochaine échéance importante en août 2026, et concerne aussi les entreprises utilisatrices, pas uniquement les éditeurs^[7]. ISO/IEC 42001 fournit le mode opératoire de gouvernance qui manque au règlement^[6]. Le dirigeant qui traite les risques d'IA générative avec la norme prépare une partie du terrain réglementaire, sans que la conformité soit automatique.

Prouver sa gouvernance : documents et arbitrages

Prouver sa gouvernance IA à un auditeur, un client grand compte ou un régulateur ne se fait pas avec des intentions. La confiance devient un facteur de différenciation, et selon Deloitte, elle doit être rendue mesurable, vérifiable et cohérente d'un territoire à l'autre^[2]. Concrètement, cela veut dire produire des artefacts.

Les objets minimaux, observés dans les démarches ISO/IEC 42001 documentées : politique d'IA validée par la direction, inventaire des systèmes d'IA avec finalité et données, appréciation des risques et plan de traitement, rôles et responsabilités, procédure de supervision humaine, journalisation des incidents. Ils recoupent en partie ce qu'un dirigeant a déjà pour ISO 27001, mais avec des exigences propres à l'IA.

La direction doit aussi assumer des arbitrages tracés : quel usage est autorisé, quel usage est proscrit, quelle donnée peut être partagée avec un modèle externe, quelle décision doit rester humaine. Sans ces arbitrages écrits, la politique est cosmétique. Ces choix nourrissent la déclaration d'applicabilité qu'un auditeur ISO 42001 examinera.

Pièges observés dans les PME romandes

Les démarches observées dans le tissu des PME romandes montrent trois pièges récurrents. Le premier consiste à confondre politique d'usage et gouvernance : une charte affichée sur l'intranet ne remplace pas une appréciation de risques ni un plan de traitement. Le deuxième consiste à traiter l'IA comme un dossier IT alors qu'elle relève d'une décision de direction, avec des enjeux juridiques, RH et de conformité.

Le troisième piège est plus subtil : vouloir tout couvrir d'un coup. Une PME de 40 à 200 personnes n'a pas les moyens d'un projet global de 18 mois. La logique recommandée par plusieurs cabinets et par la structure même de la norme est incrémentale : audit des usages, cadre de gouvernance, sécurisation, puis certification si elle apporte une valeur^[4]. Pour cadrer une démarche PME, notre guide sur comment démarrer ISO 42001 propose une séquence réaliste.

Dernier point d'attention pour un dirigeant : la confiance des parties prenantes ne se rattrape pas. Un incident sérieux, fuite de données ou décision automatisée contestée, se paie sur des exercices entiers. Investir dans la gouvernance avant l'incident coûte moins cher, et permet, pour ceux qui vont au bout, de transformer la contrainte en argument commercial vérifiable^[2]. Pour situer la démarche dans son contexte plus large, le hub Risques et conformité, le cornerstone Comprendre et la page ISO 42001 face à ISO 27001, AI Act et nLPD donnent les repères utiles.

Questions fréquentes

À lire ensuite