Un plan incident IA PME sert à décider quoi faire quand un outil d’IA laisse fuiter des données, génère une sortie nuisible ou subit un incident chez un fournisseur. Pour une PME, l’objectif n’est pas de tout interdire : c’est de protéger l’activité, documenter les preuves, assigner un responsable et choisir une mesure proportionnée. Si vous préparez un audit IA PME ou un diagnostic IA entreprise, le bon résultat concret est un registre des risques exploitable par la direction, avec seuils d’action, preuves à conserver et prochaines étapes claires.
Risque principal
Le risque principal n’est pas seulement l’erreur du modèle. C’est l’enchaînement : donnée sensible exposée, contenu trompeur envoyé à un client, puis absence de réaction coordonnée. Dans une PME, le plan incident doit couvrir trois familles de cas : fuite de données, sortie nuisible et incident fournisseur. Le responsable de départ est le sponsor métier du cas d’usage, avec appui de l’IT et, si besoin, du juridique ou du DPO. La preuve à inspecter en priorité : journal d’accès, logs de prompts, contrat fournisseur, paramétrage de conservation, et historique des validations humaines. Décision seuil : si l’outil touche des données clients, RH ou commerciales, la traçabilité doit être suffisante pour reconstituer qui a vu quoi et quand.
Surface d’exposition
La surface d’exposition d’une PME dépend de quatre zones : entrée des données, accès des utilisateurs, intégrations tierces et sortie des contenus. C’est là que le plan incident doit être concret. Une règle utile : pour chaque flux, nommer un propriétaire et un point de contrôle.
| Flux / surface | Propriétaire | Preuve à vérifier | Seuil de décision | Action immédiate |
|---|---|---|---|---|
| Données entrantes | Métier | Politique de classification, exemples de saisies | Donnée sensible possible | Bloquer l’usage ou masquer les champs |
| Comptes et accès | IT | Liste des accès, MFA, droits d’admin | Accès non revu | Révoquer, remettre à niveau |
| Fournisseur IA | Achats / IT | DPA, clauses de sous-traitance, rétention | Données réutilisées hors cadre | Suspendre l’API ou basculer |
| Sorties générées | Responsable métier | Exemples de réponses, validation humaine | Réponse trompeuse ou dangereuse | Corriger le workflow, ajouter revue |
Cette cartographie sert aussi à un audit IA PME : elle montre où une défaillance peut devenir un incident opérationnel avant même de devenir réglementaire.
Registre des risques
Le cœur du dispositif est un registre des risques avec probabilité, impact, responsable et mesure de réduction. C’est le livrable que la direction peut relire sans jargon. Pour chaque risque, utilisez une échelle simple : faible, moyen, élevé. La décision ne repose pas sur l’intuition du plus vocal, mais sur une combinaison de faits : nature des données, dépendance fournisseur, niveau de supervision humaine et historique d’incidents.
| Risque | Probabilité | Impact | Responsable | Mesure de réduction |
|---|---|---|---|---|
| Fuite de données via prompt | Moyenne | Élevé | IT / métier | Masquage, interdiction de certaines saisies |
| Réponse nuisible au client | Moyenne | Élevé | Responsable opérationnel | Revue humaine avant envoi |
| Incident fournisseur | Faible à moyenne | Élevé | Achats / IT | Clause de sortie, plan de repli |
| Mauvaise décision automatisée | Moyenne | Moyen à élevé | Direction métier | Seuils d’escalade, échantillonnage |
Le seuil de passage à l’action : si au moins un risque est élevé en impact et moyen ou plus en probabilité, le plan doit prévoir une mesure de réduction avant élargissement du pilote. C’est aussi cohérent avec les attentes de gouvernance IA et de risques IA mises en avant par la CNIL et l’ENISA, qui insistent sur la documentation, la maîtrise des accès et la gestion du cycle de vie. Voir https://www.cnil.fr/fr/intelligence-artificielle et https://www.enisa.europa.eu/topics/artificial-intelligence.
Contrôles
Les contrôles utiles ne sont pas décoratifs. Ils doivent prévenir, détecter ou contenir. Pour une PME, trois contrôles donnent le meilleur rapport effort / protection :
- Validation humaine ciblée — Propriétaire : manager métier. Preuve : échantillon de sorties signées. Seuil : toute sortie client ou RH sensible.
- Journalisation minimale mais exploitable — Propriétaire : IT. Preuve : horodatage, utilisateur, source de donnée, version du modèle. Seuil : impossible de retracer un incident.
- Clause fournisseur et plan de repli — Propriétaire : achats / direction. Preuve : contrat, SLA, rétention, exit plan. Seuil : fournisseur ne documente pas l’usage des données.
L’AI Act PME n’impose pas le même niveau de traitement à tous les usages, mais il renforce l’intérêt de classifier l’usage, d’identifier les responsabilités et de tenir des preuves avant de généraliser. Le texte officiel est ici : https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689.
Signaux d’alerte
Le plan doit inclure des signaux d’alerte simples à surveiller chaque semaine : augmentation des corrections manuelles, plaintes clients sur le ton ou l’exactitude, nouveaux accès non prévus, écarts entre sortie du modèle et base documentaire, ou dépendance croissante à un fournisseur sans réversibilité. Le propriétaire du suivi est le responsable du cas d’usage ; la preuve est le tableau de bord ou le journal d’incidents ; la décision est d’ouvrir une revue si deux signaux apparaissent sur une même période.
Exemple hypothétique, clairement identifié
Une PME de services utilise une IA pour rédiger des réponses clients. Un collaborateur colle un extrait contenant des informations contractuelles sensibles. La sortie de l’outil réutilise un détail non destiné au client. Le responsable métier constate la fuite, l’IT isole le compte, et la direction décide : suspension temporaire du flux, purge des données du test, ajout d’un filtre de masquage et validation humaine obligatoire. Ici, la bonne réponse n’est pas de faire une formation générale, mais d’actualiser le registre des risques, d’assigner un responsable au contrôle de saisie et de vérifier les clauses du fournisseur.
FAQ
Par où commencer pour mesurer les gains ?
Commencez par trois indicateurs : incidents évités, temps de traitement d’un incident et part des sorties revues avant envoi. Propriétaire : direction métier. Preuve : registre des incidents. Seuil : si le temps de réaction ne baisse pas, renforcez les contrôles.
Quels points de preuve comptent avant d’augmenter le budget ?
Cherchez des preuves de traçabilité, d’incidents réels et de corrections appliquées. Propriétaire : IT et métier. Preuve : logs, tickets, clauses fournisseur. Décision : n’augmentez le budget que si les contrôles actuels sont utilisés et mesurés.
Quand une PME doit-elle arrêter le pilote ?
Arrêtez-le si vous ne pouvez pas prouver qui a accès aux données, si le fournisseur refuse les garanties de base, ou si les sorties nuisibles se répètent. Propriétaire : direction. Action : suspendre, corriger, puis reprendre sur une base documentée.
Pour aller plus loin, consultez le cadrage et les ressources d’AI Audit : https://artificialintelligence-audit.com/fr, https://artificialintelligence-audit.com/fr/blog, puis les règles d’usage collaborateur pour PME : https://artificialintelligence-audit.com/fr/blog/regles-ia-collaborateurs-pme-2026-07-03. Si vous souhaitez comparer votre niveau de préparation à une démarche d’audit ou de mise en conformité, ce point d’entrée peut aider de façon pratique : https://buy.stripe.com/eVqdR9bE91R5fZt2EK7AI01?locale=fr.