Une EFVP n’est pas un formulaire : c’est le test de réalité de votre projet d’IA
Une EFVP ne sert pas seulement à documenter un projet d’IA. Elle sert à découvrir ce que le système fera réellement avec les renseignements personnels avant que les choix soient figés.
Beaucoup d’entreprises parlent de l’EFVP comme d’un document de conformité. Une case à cocher avant le lancement d’un projet. Un rapport que l’on produit si le service juridique le demande.
C’est probablement la moins bonne façon de la comprendre.
Une évaluation des facteurs relatifs à la vie privée — ou EFVP — sert à découvrir ce qu’un projet fera réellement avec les renseignements personnels avant que les choix importants soient figés.
Pour les projets d’intelligence artificielle, cette démarche devient particulièrement utile. Une IA peut lire des courriels, interroger un CRM, analyser des dossiers, créer des inférences, transmettre des informations à des fournisseurs et conserver des traces de ses opérations.
L’EFVP permet de transformer une idée séduisante — « branchons l’IA à nos données » — en une question beaucoup plus concrète : qu’allons-nous réellement permettre au système de voir et de faire?
L’EFVP commence avant le déploiement
Pour les entreprises privées québécoises, l’article 3.3 de la Loi sur la protection des renseignements personnels dans le secteur privé prévoit une EFVP pour tout projet d’acquisition, de développement ou de refonte d’un système d’information ou d’une prestation électronique de services impliquant la collecte, l’utilisation, la communication, la conservation ou la destruction de renseignements personnels.
Le responsable de la protection des renseignements personnels doit être consulté dès le début du projet.
La Commission d’accès à l’information décrit également l’EFVP comme une démarche préventive et évolutive.
Le mot important est « début ».
Une EFVP produite après le déploiement peut documenter un système. Mais elle a perdu une partie de sa valeur la plus importante : influencer les décisions avant qu’elles deviennent coûteuses à changer.
Une EFVP ne demande pas seulement si le fournisseur est sécuritaire
C’est une confusion fréquente.
Une entreprise reçoit un rapport de sécurité, une certification ou une documentation technique du fournisseur et considère que l’analyse est terminée.
Ces documents peuvent être utiles. Mais ils répondent principalement à des questions sur le fournisseur.
L’EFVP doit aussi répondre à des questions sur votre projet.
Pourquoi l’IA a-t-elle besoin de ces renseignements? Peut-elle accomplir la tâche avec moins de données? Quels employés pourront utiliser le système? Quels dossiers seront accessibles? Quelles informations pourront être envoyées à un modèle externe? Où seront conservés les journaux? Que se passe-t-il si une personne demande accès ou rectification?
La même plateforme d’IA peut présenter un risque très différent selon qu’elle sert à reformuler un texte public ou à analyser des dossiers d’employés.
Le produit n’est qu’une partie de l’équation.
Prenons un projet qui semble simple
Une PME veut aider son équipe de service à traiter ses courriels plus rapidement.
Le projet est simple sur papier :
un courriel arrive; l’IA le résume; elle consulte le dossier client; elle prépare une réponse; un employé la révise; le message est envoyé.
Sans EFVP, l’équipe peut se concentrer sur la vitesse et la qualité de la réponse.
Avec une EFVP, d’autres questions apparaissent.
L’IA a-t-elle besoin du dossier client complet ou seulement de quelques champs? Les notes internes doivent-elles être accessibles? Les pièces jointes peuvent-elles contenir des renseignements sensibles? Le contenu est-il transmis à un fournisseur externe? Les conversations sont-elles conservées? Qui peut consulter les traces du système?
L’EFVP ne transforme pas le projet en exercice juridique.
Elle révèle simplement son architecture réelle.
Le moment où le projet change
C’est souvent pendant cette analyse qu’une équipe fait ses meilleures découvertes.
Elle constate par exemple qu’un agent n’a pas besoin d’accéder à tous les dossiers. Qu’une information peut être masquée avant transmission. Qu’un historique complet n’est pas nécessaire pour produire une réponse. Qu’un fournisseur conserve plus longtemps que prévu certaines données. Ou qu’une validation humaine devrait être ajoutée avant une action sensible.
Autrement dit, l’EFVP peut modifier la conception du système.
C’est précisément ce qui la rend intéressante.
Une bonne EFVP ne décrit pas seulement le risque. Elle change le projet avant que le risque devienne structurel.
Pourquoi les projets d’IA rendent l’exercice plus important
Les systèmes d’IA évoluent rapidement.
Un projet peut commencer comme un assistant rédactionnel puis être connecté au CRM. Quelques semaines plus tard, on lui donne accès aux courriels. Ensuite, une fonction de mémoire est activée. Puis le système reçoit le droit de modifier certaines informations.
Le nom du projet n’a pas changé.
Son profil de risque, oui.
C’est pourquoi la description de la CAI comme démarche « évolutive » est particulièrement pertinente pour l’IA.
Une EFVP ne devrait pas être considérée comme une photographie définitive. Elle devrait être revue lorsque le système change de modèle, de fournisseur, de source de données, de finalité ou de niveau d’autonomie.
La CAI fournit d’ailleurs un guide d’accompagnement ainsi qu’un modèle générique de rapport d’EFVP pour aider les organisations à structurer cette démarche.
Source : Commission d’accès à l’information — Guides et fiches d’information
Le piège du pilote « temporaire »
L’un des risques les plus fréquents avec l’IA est le pilote qui devient graduellement un outil de production.
Quelqu’un ouvre un compte. Quelques employés l’essaient. Puis les résultats sont bons. On ajoute de vraies données. Ensuite un connecteur. Puis un deuxième département commence à utiliser le système.
Le projet « expérimental » traite maintenant des renseignements personnels réels.
Mais les décisions de gouvernance n’ont jamais été formalisées.
Cette façon de procéder est compréhensible : l’IA se teste facilement.
C’est justement pourquoi la discipline doit commencer plus tôt.
Un pilote n’a pas nécessairement besoin de toutes les données de production pour démontrer sa valeur. Des données fictives, limitées ou dépersonnalisées peuvent parfois permettre de vérifier le concept avant d’ouvrir l’accès réel.
Le but n’est pas de ralentir l’expérimentation.
Il est d’éviter que l’expérimentation décide silencieusement de l’architecture finale.
Le vrai test de réalité
Avant de mettre un projet d’IA en production, une entreprise devrait être capable d’expliquer clairement :
quels renseignements sont utilisés; pourquoi ils sont nécessaires; où ils circulent; qui peut y accéder; combien de temps ils sont conservés; quels risques ont été identifiés; quelles mesures ont été prises pour les réduire; et quels changements obligeraient l’entreprise à refaire une partie de l’analyse.
Si ces réponses sont difficiles à obtenir, l’EFVP est probablement en train de révéler quelque chose d’important.
Ce n’est pas une faiblesse du processus.
C’est précisément son rôle.
L’EFVP n’est pas le document qui dit qu’un projet est conforme. C’est le processus qui vérifie si l’entreprise comprend vraiment le projet qu’elle est sur le point d’autoriser.