Le français et la Loi 25 : ce que votre plateforme doit gérer pour vos marchands au Québec

Le Québec n’est pas un cas particulier en matière de logiciels verticaux. C’est un marché doté de ses propres règles linguistiques et de sa propre loi sur la protection des renseignements personnels, et ces deux éléments s’appliquent à quiconque contrôle l’expérience client. Lorsque votre plateforme gère le flux des transactions par carte, c’est vous qui êtes concerné. Le processeur auquel vous confiez habituellement les paiements n’est plus celui qui rédige le texte de la page de paiement, envoie le reçu ou décide de la durée de conservation des données du titulaire de la carte dans votre base de données.

C’est le compromis inhérent au fait de conserver les revenus liés aux paiements à l’interne. Vous en tirez des avantages économiques. Vous héritez également d’une responsabilité en matière de conformité qui relevait auparavant d’un autre acteur. L’argument est simple : intégrez la prise en charge du français et de la Loi 25 dans l’infrastructure de votre produit avant de devenir le facilitateur de paiement, et non comme un correctif apporté après la première plainte d’un commerçant québécois.

Maîtriser le flux, c’est maîtriser la langue

Les règles linguistiques du Québec s’étendent plus loin dans le commerce que ne le prévoient la plupart des équipes de développement logicielles basées aux États-Unis. Les contrats d’adhésion, les factures, les reçus, les bons de commande et les interfaces destinées aux consommateurs doivent généralement être en français. Pas un français traduit par une machine. Pas un français qui n’apparaît que lorsqu’un utilisateur fouille dans un menu de paramètres. La norme pratique veut qu’un client québécois puisse effectuer la transaction du début à la fin sans quitter sa langue.

Lorsque les paiements étaient gérés par un processeur externe, une partie importante de ce texte appartenait à ce processeur. Sa page de paiement hébergée. Son modèle de reçu. Son avis de contestation. Intégrez le flux à l’intérieur de votre produit et ces chaînes de caractères deviennent les vôtres. La page de paiement, le message de refus, la confirmation de remboursement, l’écran de gestion des cartes enregistrées, l’avis de rétrofacturation que vous transmettez au commerçant, l’entente que votre commerçant signe pour commencer à accepter les cartes. Chacun de ces éléments vous appartient désormais et c’est à vous de les traduire et de les maintenir.

C’est justement la partie « maintenance » que les équipes sous-estiment. Une seule mise à jour en anglais qui ajoute un nouvel état d’erreur crée une lacune non traduite. Au bout de dix-huit mois de déploiements, ces lacunes s’accumulent pour aboutir à un processus de paiement mi-français, mi-anglais, ce qui est pire que l’un ou l’autre. La solution est structurelle. Traitez la locale comme un attribut de premier ordre du compte marchand, et non comme un paramètre de navigateur. Bloquez les déploiements qui introduisent des chaînes de caractères non traduites liées au paiement. Faites valider la terminologie financière par un réviseur du français du Québec, et non par un réviseur francophone généraliste.

La Loi 25 modifie la responsabilité en matière de données

La Loi 25 du Québec est pleinement en vigueur depuis plusieurs années maintenant, et l’approche en matière d’application s’est durcie. Les obligations les plus importantes pour une plateforme de paiement comprennent la nomination d’un responsable de la protection de la vie privée, le maintien d’une politique de confidentialité publiée et précise, l’obtention d’un consentement éclairé pour la collecte et l’utilisation des données, la divulgation des transferts à l’extérieur du Québec accompagnée d’une évaluation, le signalement des incidents liés à la confidentialité et le respect des demandes de portabilité des données.

Sous l’ancien régime, votre prestataire de services de traitement assumait une grande partie de la responsabilité relative aux données des titulaires de carte. En tant que facilitateur de paiement, vous recueillez et traitez des renseignements personnels concernant à la fois les commerç s et leurs clients finaux. L’inscription d’un commerçant nécessite à elle seule la collecte de documents d’identité, de renseignements bancaires, d’informations sur la propriété effective et, souvent, une vérification de solvabilité personnelle du responsable. Il s’agit là d’une forte concentration de données sensibles stockées dans vos systèmes, car vous avez choisi d’effectuer une évaluation de crédit.

Il en découle trois réalités opérationnelles. Premièrement, votre cartographie des données doit être exacte et à jour, car une demande de portabilité ou un rapport d’incident ne vous laisse pas le temps d’aller chercher où se trouvent les informations. Deuxièmement, les transferts transfrontaliers nécessitent des évaluations documentées, ce qui est important si votre infrastructure, votre banque de référence ou votre fournisseur de services de lutte contre la fraude est situé à l’extérieur du Québec. Troisièmement, la conservation des données nécessite un calendrier précis assorti d’une procédure de suppression efficace, car le stockage indéfini est le mode par défaut de la plupart des systèmes de paiement et c’est ce qui est le plus difficile à démanteler par la suite.

Pourquoi la mise à niveau coûte plus cher que l’intégration dès le départ

La tentation est grande de lancer le modèle de facilitateur de paiement, d’attirer des commerçants, puis de s’occuper du Québec lorsque le volume le justifie. Cet enchaînement coûte cher pour une raison bien précise : les données de paiement sont les plus difficiles à réorganiser a posteriori.

Les interfaces traduites peuvent être ajoutées progressivement. La conservation et la suppression, en revanche, ne le peuvent pas – ou du moins pas facilement – une fois que les enregistrements de transactions, les instruments tokenisés, les preuves de litiges et l’historique des règlements sont entremêlés dans des systèmes conçus pour tout conserver indéfiniment. Il en va de même pour le consentement. Si vous n’avez pas capturé un enregistrement de consentement défendable lors de l’inscription, vous ne pouvez pas en reconstituer un à partir d’un fichier-journal deux ans plus tard.

Il y a également un argument commercial. Un logiciel vertical s’impose lorsqu’il devient le système de référence d’un secteur. Une clinique, un entrepreneur ou un concessionnaire québécois qui évalue votre plateforme demandera si ses clients reçoivent un reçu en français et si les données de ses patients ou clients sont traitées conformément à la Loi 25. Une réponse vague fera échouer la transaction. Une réponse précise, appuyée par un processus de paiement en français que votre ingénieur des ventes peut démontrer en direct, permettra de conclure l’affaire.

Prochaines étapes

Choisissez un segment de commerçants québécois et cartographiez l’ensemble du parcours. Dressez la liste de toutes les chaînes de caractères liées au paiement, de l’intégration jusqu’au règlement des litiges, et indiquez celles qui existent déjà en français. Par ailleurs, cartographiez où les renseignements personnels des commerçants et des titulaires de carte sont saisis, transitent et sont stockés dans votre infrastructure, puis associez une règle de conservation à chaque étape.

Faites appel à un conseiller juridique québécois dès le début, avant de rédiger les exigences, et demandez à votre partenaire de paiement de documenter précisément quelles obligations lui incombent et lesquelles vous incombent. Obtenez cette répartition par écrit. Intégrez ensuite la gestion de la langue et de la protection des renseignements personnels dans le même cycle de lancement que celui du facilitateur de paiement, afin que les commerçants québécois puissent être convaincus dès le premier jour plutôt que d’être reportés à un élément de la feuille de route dont personne n’est responsable.