Sécurité de l'IA en entreprise : protéger les données avant d'accélérer

1. La sécurité doit arriver avant l'automatisation

Dans plusieurs entreprises, l'IA commence par des usages simples: rédiger un courriel, résumer un document, préparer une proposition, générer un compte rendu ou analyser une réunion.

Puis les usages deviennent plus avancés.

L'IA commence à traiter des documents internes. Elle accède à des données clients. Elle se branche à des courriels. Elle interagit avec un CRM. Elle génère des scripts. Elle crée des automatisations. Elle prépare des décisions.

C'est à ce moment que la sécurité devient critique.

Un outil IA qui rédige un texte public présente un risque limité. Un agent IA qui accède à des fichiers internes, analyse des données clients ou déclenche des actions dans un système d'entreprise présente un risque beaucoup plus élevé.

La règle devrait être simple: plus l'IA a accès à des données ou à des systèmes, plus les contrôles doivent être stricts.

Il ne faut pas attendre qu'un outil IA devienne important pour se demander s'il est sécuritaire. La sécurité doit être intégrée dès le départ.

2. Le premier risque: copier les mauvaises données au mauvais endroit

Le risque le plus fréquent n'est pas toujours une cyberattaque sophistiquée. C'est souvent un geste simple: un employé copie de l'information sensible dans un outil IA non approuvé.

Cela peut inclure:

• des renseignements personnels;
• des informations clients;
• des contrats;
• des données financières;
• des secrets commerciaux;
• des stratégies internes;
• des données RH;
• des notes de réunion confidentielles;
• des documents de propriété intellectuelle;
• du code source.

L'employé ne cherche pas à nuire. Il veut gagner du temps. Il veut résumer, reformuler, analyser ou structurer l'information.

Mais si l'outil utilisé n'est pas approuvé, si les conditions d'utilisation sont mal comprises ou si les données sont traitées hors du contrôle de l'entreprise, le risque augmente rapidement.

Pour une PME, la première mesure de sécurité IA devrait donc être très concrète: définir quelles données ne doivent jamais être copiées dans un outil IA non approuvé.

Cette règle doit être courte, claire et connue de tous.

3. Le contexte canadien impose une attention particulière aux renseignements personnels

Au Canada, les entreprises qui traitent des renseignements personnels doivent tenir compte des lois applicables en matière de protection de la vie privée. Selon le secteur, la province et la nature des données, différentes obligations peuvent s'appliquer.

Au Québec, la Loi 25 a renforcé les exigences de gouvernance des renseignements personnels. Elle touche notamment la désignation d'un responsable de la protection des renseignements personnels, la gestion des incidents de confidentialité, les évaluations des facteurs relatifs à la vie privée et l'encadrement de certains transferts de renseignements personnels à l'extérieur du Québec. [1]

Dans ce contexte, l'usage de l'IA ne doit pas être vu comme une simple question technologique. Si une entreprise utilise l'IA pour traiter des renseignements personnels, elle doit se demander:

• quelles données sont utilisées;
• pourquoi elles sont nécessaires;
• où elles sont envoyées;
• qui peut y accéder;
• combien de temps elles sont conservées;
• si elles sont utilisées pour entraîner un modèle;
• si elles peuvent être supprimées;
• si un fournisseur étranger y a accès;
• si une évaluation de risque ou de vie privée est nécessaire.

Pour une PME, cela peut sembler lourd. Mais la logique est simple: les renseignements personnels ne doivent pas être traités dans des outils IA sans comprendre le parcours des données.

4. La souveraineté des données devient un enjeu stratégique

La souveraineté des données signifie que l'entreprise conserve un contrôle réel sur ses données: où elles sont stockées, sous quelle juridiction elles se trouvent, qui peut y accéder, quelles lois s'appliquent et quels fournisseurs peuvent les traiter.

Ce sujet devient plus important avec l'IA, parce que les données ne sont plus seulement stockées. Elles sont utilisées dans des prompts, des modèles, des systèmes de recherche, des outils d'automatisation, des agents et parfois des environnements infonuagiques distribués.

Pour une entreprise canadienne, la souveraineté des données ne veut pas dire que tout doit obligatoirement rester au Canada dans tous les cas. Mais cela veut dire que les décisions doivent être conscientes.

Il faut savoir:

• si les données sont hébergées au Canada;
• si elles peuvent transiter par d'autres pays;
• si un fournisseur étranger peut y accéder;
• quelles lois étrangères pourraient s'appliquer;
• si les données sont utilisées pour améliorer ou entraîner des modèles;
• si l'entreprise peut obtenir la suppression des données;
• si les journaux, prompts et résultats sont conservés;
• si les sous-traitants du fournisseur sont connus.

La souveraineté des données est donc moins un slogan qu'une question de contrôle opérationnel.

Une PME n'a pas toujours les moyens d'exploiter sa propre infrastructure IA. Mais elle peut choisir ses fournisseurs avec plus de rigueur et éviter de placer des données sensibles dans des environnements qu'elle ne comprend pas.

5. Les fournisseurs IA doivent être évalués comme des fournisseurs critiques

Plus une entreprise dépend d'un outil IA, plus cet outil doit être traité comme un fournisseur critique.

Il ne suffit pas de demander si l'outil est performant. Il faut aussi comprendre ses pratiques de sécurité, de confidentialité, de conservation et de traitement des données.

Avant d'utiliser un outil IA avec des données sensibles, une PME devrait poser quelques questions simples:

• Où les données sont-elles stockées?
• Les données sont-elles chiffrées?
• Les prompts sont-ils conservés?
• Les données peuvent-elles servir à entraîner le modèle?
• Peut-on désactiver l'entraînement sur les données de l'entreprise?
• Qui a accès aux données chez le fournisseur?
• Le fournisseur utilise-t-il des sous-traitants?
• Les données peuvent-elles sortir du Canada?
• Quelles certifications ou attestations de sécurité sont disponibles?
• Que se passe-t-il en cas d'incident?
• Peut-on exporter ou supprimer les données?

Ces questions ne sont pas réservées aux grandes entreprises. Elles sont aussi pertinentes pour les PME, surtout lorsqu'elles traitent des renseignements personnels, des données clients ou de l'information stratégique.

6. Les agents IA augmentent le risque d'accès excessif

Les agents IA changent la nature du risque.

Un assistant IA qui répond à une question est relativement limité. Un agent IA qui peut consulter des données, utiliser des outils, écrire dans des systèmes ou déclencher des actions demande plus de contrôle.

Le risque principal est l'accès excessif.

Un agent peut recevoir trop de permissions. Il peut accéder à des dossiers inutiles. Il peut récupérer des informations que l'utilisateur ne devrait pas voir. Il peut exécuter une action sans validation suffisante. Il peut être manipulé par une instruction malveillante.

Pour les PME, la règle devrait être la même que pour les employés: un agent IA ne devrait avoir accès qu'aux données et aux actions nécessaires à son mandat.

Il faut éviter les agents génériques avec des permissions trop larges.

Un bon agent IA devrait avoir:

• un rôle précis;
• un périmètre limité;
• des permissions minimales;
• des actions autorisées;
• des actions interdites;
• une validation humaine pour les étapes sensibles;
• des journaux d'activité;
• un responsable interne;
• une procédure de suspension.

Plus l'agent agit, plus il doit être surveillé.

7. Les risques propres aux grands modèles de langage doivent être connus

Les systèmes IA basés sur des grands modèles de langage introduisent des risques particuliers.

• l'injection de prompt;
• la fuite de données sensibles;
• la mauvaise gestion des sorties;
• les réponses inventées ou trompeuses;
• les vulnérabilités dans les intégrations;
• la dépendance à des composants ou modèles externes;
• la manipulation de l'agent par des instructions cachées;
• l'autonomie excessive accordée à un agent;
• la génération de code vulnérable;
• la divulgation involontaire de renseignements confidentiels.

Ces risques ne sont pas théoriques. Ils sont suffisamment importants pour que l'OWASP maintienne un référentiel spécifique aux applications basées sur les grands modèles de langage, incluant notamment l'injection de prompt, la divulgation d'information sensible, la conception non sécurisée des plugins, l'autonomie excessive et la dépendance excessive aux résultats générés. [2]

Pour une petite entreprise, cela signifie qu'il ne faut pas traiter une application IA comme un simple outil de productivité. Dès qu'elle est connectée à des données, des utilisateurs ou des systèmes, elle devient une application à sécuriser.

8. Le code généré par IA doit être vérifié

Le vibe coding et les assistants de programmation permettent de créer des applications, des scripts et des automatisations beaucoup plus vite.

C'est utile.

Mais le code généré par IA peut contenir des failles de sécurité. Il peut mal gérer l'authentification, exposer des clés API, ignorer les erreurs, stocker des données sensibles au mauvais endroit ou utiliser des librairies vulnérables.

Pour une PME, le risque est que du code généré rapidement devienne un outil opérationnel sans revue technique.

La règle devrait être claire: tout code généré par IA qui touche des données internes, des clients, des paiements, des accès ou des systèmes d'entreprise doit être revu avant d'être utilisé en production.

L'IA peut accélérer la création. Elle ne remplace pas la revue de sécurité.

9. La sécurité IA commence par les accès

Avant de parler de modèles, d'agents ou d'automatisation, il faut revenir à une base simple: les accès.

• Qui peut utiliser l'outil IA?
• Qui peut voir les données?
• Qui peut connecter une source?
• Qui peut créer un agent?
• Qui peut approuver une action?
• Qui peut consulter les journaux?
• Qui peut modifier les instructions système?
• Qui peut exporter les résultats?

Une PME peut réduire beaucoup de risques en appliquant quelques principes:

• utiliser l'authentification multifactorielle;
• éviter les comptes partagés;
• limiter les permissions;
• retirer rapidement les accès des anciens employés;
• séparer les environnements de test et de production;
• protéger les clés API;
• limiter les accès administrateurs;
• documenter les outils utilisés;
• surveiller les activités inhabituelles.

Ces pratiques ne sont pas nouvelles. Mais elles deviennent encore plus importantes quand l'IA est connectée aux processus.

10. Les données sensibles doivent être minimisées

La minimisation est un principe essentiel.

Il ne faut pas donner à l'IA plus d'information que nécessaire.

Si l'objectif est de résumer une tendance, il n'est peut-être pas nécessaire d'inclure des noms de clients. Si l'objectif est de tester une automatisation, des données fictives peuvent suffire. Si l'objectif est de rédiger une réponse, les renseignements identifiants peuvent souvent être retirés.

Une PME peut adopter quelques réflexes simples:

• anonymiser les données quand c'est possible;
• utiliser des exemples fictifs pour les tests;
• retirer les noms, adresses, numéros de téléphone et identifiants;
• éviter de copier des documents complets si un extrait suffit;
• limiter les données transmises aux outils externes;
• ne pas utiliser de données clients dans des outils non approuvés.

Moins l'IA reçoit de données sensibles, moins le risque de fuite est élevé.

11. Les journaux et traces d'activité sont nécessaires

Quand une solution IA devient opérationnelle, l'entreprise doit pouvoir comprendre ce qui s'est passé.

• Qui a demandé quoi?
• Quel outil a été utilisé?
• Quelle donnée a été consultée?
• Quelle réponse a été produite?
• Quelle action a été proposée?
• Quelle action a été exécutée?
• Qui a validé?

Sans journalisation, il devient difficile d'expliquer une erreur, de retracer une fuite, de corriger un processus ou de démontrer une diligence raisonnable.

Pour les PME, la journalisation n'a pas besoin d'être complexe au départ. Mais les usages sensibles devraient laisser des traces.

C'est particulièrement important pour:

• les agents IA;
• les décisions assistées par IA;
• les données personnelles;
• les communications clients;
• les documents contractuels;
• les systèmes financiers;
• les accès à des informations confidentielles.

Une IA utile doit aussi être une IA traçable.

12. Prévoir une procédure d'incident IA

Une entreprise devrait prévoir quoi faire si un incident IA survient.

• un employé a copié des données sensibles dans un outil non approuvé;
• un agent a envoyé une réponse erronée;
• un outil IA a exposé un document interne;
• une clé API a été publiée dans du code généré;
• une réponse générée a causé un problème client;
• une automatisation a modifié une donnée incorrectement.

La procédure n'a pas besoin d'être compliquée.

1. Qui doit être informé?
2. Comment contenir l'incident?
3. Quelles données sont touchées?
4. Quels systèmes doivent être suspendus?
5. Qui évalue l'impact?
6. Qui communique avec les clients ou personnes concernées?
7. Qui documente l'incident?
8. Quelles corrections doivent être mises en place?

Au Canada et au Québec, les incidents impliquant des renseignements personnels peuvent aussi déclencher des obligations de notification selon le cadre applicable. Pour une PME, il est donc important de savoir à l'avance qui évaluera l'impact et qui décidera si une notification est requise. [1]

13. Choisir entre outil public, outil entreprise et environnement privé

Toutes les solutions IA ne se valent pas du point de vue de la sécurité.

Pour une PME, il est utile de distinguer trois niveaux.

Outil public

C'est l'usage le plus simple: un outil accessible en ligne, utilisé individuellement.

Il peut convenir pour des tâches à faible risque: idées de contenu, reformulation, structure de document ou résumé d'information publique.

Mais il ne devrait pas recevoir de données confidentielles ou personnelles sans validation.

Outil entreprise

C'est une version commerciale ou organisationnelle avec meilleurs contrôles: gestion des utilisateurs, paramètres de confidentialité, protection des données, administration centralisée, journaux et options de non-entraînement.

C'est souvent le minimum requis pour des usages professionnels plus sensibles.

Environnement privé ou contrôlé

C'est une solution plus encadrée: hébergement contrôlé, intégration aux systèmes internes, règles d'accès, supervision, journalisation, gouvernance et parfois résidence des données au Canada.

C'est l'option à considérer pour les usages sensibles, les données réglementées ou les processus critiques.

La bonne question n'est pas seulement: « Quel outil est le meilleur? » La bonne question est: « Quel niveau de contrôle est nécessaire pour cet usage? »

14. La souveraineté n'est pas seulement une question d'hébergement

Il serait réducteur de limiter la souveraineté des données à l'emplacement du serveur.

L'hébergement au Canada peut être important. Mais il faut aussi regarder:

• la juridiction du fournisseur;
• les sous-traitants;
• les accès administratifs;
• le support technique;
• les sauvegardes;
• les journaux;
• les environnements de traitement;
• les transferts transfrontaliers;
• les clauses contractuelles;
• les droits de suppression;
• les dépendances technologiques.

Une donnée peut être stockée au Canada, mais traitée par un fournisseur étranger. Elle peut être hébergée dans une région canadienne, mais accessible par du personnel situé ailleurs. Elle peut être supprimée de l'interface, mais conservée dans des journaux ou des sauvegardes.

La souveraineté réelle exige donc de comprendre toute la chaîne de traitement.

Pour les PME, cela ne veut pas dire qu'il faut tout internaliser. Mais il faut poser les bonnes questions avant de confier des données importantes à un fournisseur IA.

15. Une méthode simple pour sécuriser l'IA dans une PME

Une petite entreprise peut commencer avec une méthode en huit étapes.

1. Inventorier les outils IA utilisés. Identifier tous les outils utilisés par les employés, y compris les usages individuels non déclarés.
2. Classer les usages selon le risque. Distinguer les usages faibles, modérés, sensibles et critiques selon les données et les systèmes impliqués.
3. Définir les données interdites. Préciser les informations qui ne doivent jamais être copiées dans un outil IA non approuvé.
4. Approuver certains outils. Établir une liste d'outils autorisés selon les usages, les données et les contrôles offerts par chaque fournisseur.
5. Vérifier les fournisseurs. Examiner l'hébergement, la conservation, l'entraînement, les accès, les sous-traitants et les options de suppression.
6. Limiter les accès. Appliquer le principe du moindre privilège: chaque employé et chaque agent ne doit accéder qu'aux données nécessaires à son rôle.
7. Journaliser les usages sensibles. Garder une trace des actions IA pour les usages impliquant des données personnelles, clients ou financières.
8. Prévoir les incidents. Définir la procédure à suivre si un incident IA survient: responsable, confinement, évaluation et communication.

Cette méthode n'exige pas une grande équipe de sécurité. Elle exige surtout de la clarté.

Conclusion: une IA sécuritaire est une IA contrôlée

L'IA peut aider les petites entreprises à aller plus vite. Elle peut améliorer la productivité, accélérer les suivis, soutenir les équipes, générer des prototypes et simplifier certains processus.

Mais l'accélération ne doit pas se faire au prix du contrôle.

Dans le contexte canadien, les entreprises doivent porter une attention particulière aux renseignements personnels, aux transferts de données, aux fournisseurs, aux accès, aux incidents et à la souveraineté des données.

La sécurité de l'IA repose sur quelques principes simples:

• ne pas mettre de données sensibles dans des outils non approuvés;
• choisir les fournisseurs avec rigueur;
• limiter les accès;
• garder l'humain dans les décisions importantes;
• journaliser les actions sensibles;
• vérifier le code généré par IA;
• comprendre où les données sont stockées et traitées;
• prévoir une procédure d'incident.

L'IA sécuritaire n'est pas l'IA la plus verrouillée. C'est l'IA dont l'entreprise comprend les risques, les limites, les accès et les responsabilités.

Pour une PME, le bon objectif n'est pas de tout contrôler parfaitement dès le départ. C'est de commencer avec des règles simples, de protéger les données critiques et d'augmenter les contrôles à mesure que les usages deviennent plus sensibles.

Références pour poursuivre la lecture

1. Commission d'accès à l'information du Québec - Principaux changements apportés par la Loi 25
2. OWASP - Top 10 for Large Language Model Applications
3. Gouvernement du Canada - Guide sur l'utilisation de l'IA générative
4. Commissariat à la protection de la vie privée du Canada - Vie privée et intelligence artificielle
5. NIST - AI Risk Management Framework
6. ISO/IEC 42001 - Système de management de l'intelligence artificielle