Loi 25 : votre automatisation envoie déjà des données hors Québec

Vous avez branché Zapier à votre CRM la semaine dernière. Le scénario roule, les leads arrivent, personne ne s’est posé de question. Vous pensez être en règle parce que la loi 25 vise les États-Unis, l’Europe, les grands joueurs technologiques loin d’ici.

Faux départ. L’article 17 ne parle pas de « hors Canada ». Il parle de « hors Québec ». Un scénario qui écrit dans un système hébergé à Toronto constitue une communication hors Québec, au sens de la loi, exactement comme s’il écrivait vers la Californie. Et cette communication exige, avant de brancher quoi que ce soit, une évaluation des facteurs relatifs à la vie privée : l’EFVP.

Ce que « communication hors Québec » veut dire quand vos outils sont dans le nuage

Un renseignement personnel, c’est toute information qui permet d’identifier une personne physique : nom, courriel, numéro de téléphone, adresse, historique d’achat. Dès qu’un de ces renseignements quitte vos systèmes pour atteindre un serveur ailleurs, vous le communiquez au sens de la loi.

L’automatisation rend cette communication invisible. Un formulaire web se soumet, un webhook se déclenche, une requête part vers une plateforme d’automatisation, une réponse revient dans votre CRM. Personne ne signe rien au moment où ça se passe. Le connecteur, lui, se fiche de vos ententes.

Zapier, Make et n8n ne sont pas de simples logiciels que vous installez sur votre poste. Ce sont des intermédiaires qui font transiter vos données par leur propre infrastructure pour exécuter le scénario. Le renseignement personnel quitte votre CRM, traverse les serveurs de la plateforme d’automatisation, puis arrive dans le système de destination, que ce soit un outil de facturation, une liste d’envoi ou un système d’accueil client. Chacune de ces étapes est une communication distincte. L’article 17 s’applique dès la première.

Ce n’est pas un détail technique réservé aux entreprises technologiques. Une PME de services professionnels qui automatise l’accueil de ses nouveaux clients, la facturation de ses contrats ou le suivi de ses courriels marketing communique des renseignements personnels hors Québec plusieurs fois par jour, sans jamais y avoir pensé.

Suivons un exemple concret, étape par étape. Un client remplit le formulaire de contact de votre site web. Ce geste déclenche un webhook Zapier, qui part vers l’infrastructure de Zapier aux États-Unis. Zapier lit le nom, le courriel et le numéro de téléphone du client, puis les pousse vers votre CRM, hébergé lui aussi hors Québec. De là, un second scénario automatique s’enclenche : le CRM transmet les mêmes coordonnées à votre outil de facturation, hébergé à Toronto, pour créer une fiche client. Trois communications viennent de se produire en quelques secondes, chacune hors Québec : vers Zapier, vers le CRM, vers l’outil de facturation. Aucune n’a fait l’objet d’une EFVP. Personne n’a lu de politique de confidentialité avant de brancher le premier connecteur. Chacune de ces trois étapes est, individuellement, une communication hors Québec au sens de l’article 17.

La responsabilité ne retombe pas sur la personne qui a construit le scénario un jeudi après-midi. Elle retombe sur l’entreprise, au sens de la loi. Un connecteur configuré par un employé sans en parler à personne n’exempte pas l’entreprise de l’obligation. C’est même le scénario le plus fréquent : l’automatisation existe, elle fonctionne bien, et personne au-dessus n’est au courant qu’elle communique des renseignements hors Québec.

Où vont vos données selon l’outil (Zapier, Make, n8n infonuagique, n8n auto-hébergé)

Outil	Où vivent vos données
Zapier	Serveurs aux États-Unis
Make	Serveurs dans l’Union européenne
n8n infonuagique (Cloud)	Serveurs à Francfort, en Allemagne
n8n auto-hébergé	Là où vous installez le serveur

Les trois premières options ont un point commun : vos renseignements personnels quittent le Canada, et donc le Québec. La quatrième dépend entièrement de vous. Un n8n auto-hébergé sur un serveur au Québec règle la question de la communication hors Québec pour ce scénario précis. Un n8n auto-hébergé sur un serveur en Ontario ne la règle pas.

Cette dernière phrase surprend la plupart des propriétaires d’entreprise. On y revient plus loin, parce que c’est précisément là que la plupart des PME croient avoir réglé le problème sans l’avoir réglé.

L’article 17 en clair : EFVP préalable, entente écrite, protection adéquate

L’article 17 de la loi 25 impose trois obligations avant toute communication de renseignements personnels hors Québec.

Première obligation. Réaliser une EFVP avant que la communication ait lieu. Pas après avoir branché le scénario. Avant.

Deuxième obligation. Conclure une entente écrite avec le destinataire des renseignements. Cette entente précise les mesures que le destinataire s’engage à respecter : sécurité, limitation d’usage, sous-traitance, destruction en fin de mandat.

Troisième obligation. S’assurer que les renseignements bénéficient, chez le destinataire, d’une protection jugée adéquate au regard des principes reconnus en matière de protection des renseignements personnels.

L’article 3.3 étend la même obligation d’EFVP à un autre moment : celui où vous acquérez, développez ou reconfigurez un système d’information qui traite des renseignements personnels. Configurer un nouveau scénario Zapier qui écrit dans un système jamais utilisé auparavant compte. L’EFVP ne s’applique pas seulement au moment du transfert. Elle s’applique déjà au moment où vous construisez le système qui va transférer.

Dans la pratique, ça veut dire que l’EFVP se produit deux fois pour une même automatisation : une fois quand vous concevez le scénario, une fois avant de l’activer en production.

Vérifier une protection adéquate ne veut pas dire enquêter sur toute l’infrastructure du fournisseur. Ça veut dire lire ses conditions de service et sa politique de confidentialité, et vérifier qu’elles couvrent au minimum les mêmes principes que la loi 25 : consentement, finalité, sécurité, durée de conservation. Pour la plupart des outils grand public, cette information est publique et se trouve en quelques minutes.

Le piège du seuil : l’Ontario aussi est « hors Québec »

Voici l’erreur la plus commune, et la plus coûteuse à corriger après coup. La plupart des propriétaires d’entreprise lisent « transfert international » et pensent aux États-Unis, à l’Europe, à l’Asie. Ils installent un logiciel comptable hébergé à Toronto et cochent la case conformité dans leur tête.

Le seuil de la loi 25 n’est pas le Canada. C’est le Québec.

Un fournisseur en Ontario est hors Québec. Un fournisseur en Colombie-Britannique est hors Québec. Une facture qui part de Sherbrooke pour atterrir sur un serveur à Waterloo déclenche exactement les mêmes obligations qu’une facture qui part pour la Californie.

Le même raisonnement s’applique à un outil de sondage client hébergé à Waterloo, à une plateforme de recrutement hébergée à Vancouver, ou à un service d’infolettre hébergé ailleurs qu’au Québec. Le nom du fournisseur ne change rien au calcul. Seule la localisation des serveurs et le siège de l’entreprise comptent.

Ce détail change le calcul pour à peu près toutes les PME québécoises qui utilisent un outil SaaS canadien sans EFVP documentée. Votre logiciel de paie, votre plateforme de sondage, votre outil de gestion de projet, votre système de réservation : si le siège social ou les serveurs sont ailleurs qu’au Québec, l’article 17 s’applique. Ce n’est pas une hypothèse rare. C’est probablement votre situation en ce moment, dans au moins un outil de votre pile.

Une EFVP proportionnée pour une PME tient en 3 à 5 pages

Le mot « évaluation » fait peur. Les gens imaginent un rapport de 80 pages, un consultant qui facture des semaines, un exercice réservé aux grandes entreprises avec un service juridique interne.

Ce n’est pas ce que la loi exige. L’EFVP doit être proportionnée à la nature et à la sensibilité des renseignements en cause, à leur utilisation, à leur quantité, à leur répartition et au support sur lequel ils sont accessibles. Pour un scénario Zapier qui envoie un nom, un courriel et un numéro de téléphone vers un outil de facturation en Ontario, l’évaluation tient en 3 à 5 pages.

Le modèle de rapport que propose la Commission d’accès à l’information elle-même tient en sept sections. Voici à quoi chacune ressemble, réduite à l’échelle d’une PME et appliquée au scénario Zapier vers l’Ontario décrit plus haut.

Résumé de l’évaluation : deux ou trois phrases. Quel outil, quel renseignement, quelle décision finale.

Description du projet : le scénario en une phrase. « Zapier transmet le nom, le courriel et le numéro de téléphone du client vers l’outil de facturation pour créer une fiche client automatiquement. »

Rôles et responsabilités : qui a configuré le scénario, qui approuve l’EFVP, qui répond si la CAI pose une question.

Renseignements personnels impliqués et ampleur de l’évaluation : la liste exacte des champs qui transitent, le volume approximatif de clients concernés, la fréquence du transfert.

Conformité aux obligations et aux principes : la vérification que le destinataire respecte les principes reconnus, soit sécurité, finalité, limitation d’usage. C’est ici que vous consignez ce que vous avez lu dans ses conditions de service.

Identification des risques et stratégies d’atténuation : que se passe-t-il si le fournisseur est compromis? Quelle est la probabilité, quelle est la gravité, et qu’est-ce qui réduit le risque, comme le chiffrement, l’accès restreint ou une clause contractuelle.

Plan d’action et approbation : la décision finale, la date, et qui a approuvé le tout.

Sept sections, chacune réduite à quelques lignes pour un scénario simple. C’est ce qui tient en 3 à 5 pages. Le guide d’accompagnement de la CAI et son modèle de rapport ne sont pas obligatoires à suivre à la lettre, mais ils donnent la structure que la Commission elle-même reconnaît.

On observe régulièrement le même scénario chez des PME en croissance : le connecteur Zapier existe depuis six mois, il fonctionne très bien, et personne n’a jamais produit ce document de 3 à 5 pages. Le connecteur n’attend pas votre EFVP pour transférer des données. Il l’a déjà fait à répétition avant que quelqu’un y pense.

Ce qui change si vous hébergez n8n au Canada (et ce qui ne change pas)

Un n8n auto-hébergé sur un serveur infonuagique canadien garde vos données au Canada. C’est un pas dans la bonne direction : moins de distance, moins de juridictions étrangères dans le portrait.

Mais le Canada n’est pas le Québec. La loi 25 fixe son seuil à la frontière provinciale, pas à la frontière nationale. Un serveur à Toronto, à Vancouver ou même à Ottawa reste hors Québec au sens de l’article 17.

Ce que l’hébergement canadien règle : vos renseignements ne traversent plus de frontière internationale, ce qui simplifie l’analyse de risque dans l’EFVP. Ce que l’hébergement canadien ne règle pas : l’obligation de produire l’EFVP elle-même, l’entente écrite avec l’hébergeur, et la vérification que la protection offerte est adéquate.

Le seul hébergement qui élimine complètement l’article 17 est un serveur physiquement situé au Québec. C’est une option réaliste pour un n8n auto-hébergé. Ce n’en est pas une pour Zapier, pour Make, ni pour n8n infonuagique, dont l’infrastructure est fixée par le fournisseur.

Auto-héberger au Canada réduit le risque. Ça ne remplace pas le document.

Le point de départ reste le même, peu importe l’hébergement choisi : dresser la liste des outils qui reçoivent des renseignements personnels, identifier où vivent leurs serveurs, puis documenter une EFVP pour chacun qui est hors Québec. Ce travail se fait une fois par outil, pas une fois par mois.

Chez Telos Machina, on bâtit les automatisations et on connaît l’article 17. La plupart des cabinets de conformité au Québec vendent des gabarits d’EFVP sans jamais toucher à un scénario Zapier. La plupart des ateliers d’automatisation configurent des connecteurs sans savoir que l’article 17 existe. On fait les deux dans la même conversation : le scénario se construit avec l’EFVP déjà réglée, pas après coup.

Le Diagnostic Conformité (Bilan) part de là. Il repère les communications hors Québec déjà actives dans votre pile technologique, avant qu’un contrôle de la Commission d’accès à l’information (CAI) le fasse à votre place. Parlez-nous de votre automatisation et on regarde ensemble ce qui traverse déjà la frontière du Québec.

FAQ

L’article 17 s’applique-t-il à un fournisseur situé en Ontario?

Oui. Le texte de l’article 17 parle de communication « à l’extérieur du Québec », pas « à l’extérieur du Canada ». Un fournisseur en Ontario, en Colombie-Britannique ou ailleurs au pays déclenche exactement la même obligation d’EFVP qu’un fournisseur aux États-Unis ou en Europe. Le nom du pays d’origine du fournisseur ne change rien au calcul.

Combien de temps faut-il conserver une EFVP?

La loi ne fixe pas de durée précise pour l’EFVP elle-même. La Commission d’accès à l’information la décrit comme une démarche évolutive : vous la révisez chaque fois que le projet change, pas seulement au moment de la rédiger. Dans la pratique, gardez le document actif aussi longtemps que l’automatisation tourne, et mettez-le à jour dès qu’un outil change dans la chaîne.

L’auto-hébergement au Canada suffit-il pour respecter l’article 17?

Non. Le seuil de la loi est le Québec, pas le Canada. Un serveur à Toronto, à Vancouver ou à Ottawa reste hors Québec au sens de l’article 17, même si les données ne quittent jamais le pays. Auto-héberger n8n au Canada réduit l’exposition à des juridictions étrangères, ce qui simplifie l’analyse de risque dans l’EFVP, mais ça ne dispense ni de l’EFVP ni de l’entente écrite. Seul un serveur physiquement situé au Québec élimine l’obligation pour ce scénario précis.