Cohere est canadienne. Ce seul fait ne réglera pas votre problème de conformité

Cohere a bouclé son tour de série D en 2024 à une valorisation dépassant les 5 milliards de dollars, et son siège social se trouve sur King Street West, à Toronto. Ces deux faits reviennent constamment dans les conversations sur l'approvisionnement en IA au Canada, généralement comme raccourci pour dire « ce fournisseur est sécuritaire ». Ce ne sont pourtant pas les mêmes affirmations, et c'est en les confondant que bien des révisions de conformité déraillent.

Cohere est, selon toute définition raisonnable, une entreprise d'IA canadienne. Elle a été fondée par d'anciens chercheurs de Google Brain en 2019, elle a son siège social à Toronto, et elle est devenue le nom le plus visible du secteur de l'IA au pays — celui que les fonctionnaires fédéraux pointent du doigt quand ils veulent démontrer que le Canada peut rivaliser avec la Silicon Valley sur les modèles fondationnels. Ce qui mérite qu'on s'y attarde, c'est ce que « entreprise canadienne » achète réellement à une organisation qui tente de satisfaire à la Loi 25 du Québec ou à la Loi fédérale sur la protection des renseignements personnels et les documents électroniques (LPRPDE). Quelque chose, oui, mais moins que ce que les équipes d'approvisionnement présument souvent.

La question du siège social n'est pas la question de la conformité

Le pays de constitution en société d'une entreprise indique où son conseil d'administration se réunit et où ses impôts sont produits. Il n'indique pas où les données des clients sont stockées, où l'inférence a lieu, ni quels sous-traitants touchent à ces données en cours de route.

Cette distinction compte parce que la Loi 25, la loi québécoise sur la protection des renseignements personnels dans le secteur privé qui a terminé son déploiement échelonné au cours de 2023 et 2024, impose des obligations précises concernant les transferts transfrontaliers de données : les organisations doivent évaluer le cadre juridique de la juridiction de destination avant que les renseignements personnels ne quittent la province. La LPRPDE, la loi fédérale qui s'applique partout où la loi québécoise ne s'applique pas, adopte une approche similaire fondée sur la responsabilisation — une organisation demeure responsable des renseignements personnels qu'elle transmet à un tiers, peu importe où ce tiers est constitué en société.

La documentation d'entreprise de Cohere précise que les données des clients peuvent être traitées dans plusieurs régions selon le déploiement, et l'entreprise offre des options de déploiement incluant son propre nuage, Amazon Web Services, ainsi que des installations sur site pour les grands clients. Une entreprise dont le siège social est à Toronto peut très bien faire transiter l'inférence par la Virginie. La constitution en société et l'infrastructure sont deux questions distinctes, et un responsable de la conformité qui ne vérifie que la première n'a fait que la moitié du travail.

Cet écart a un coût concret, et il n'est pas hypothétique. Sous la Loi 25, une organisation qui transfère des renseignements personnels hors du Québec sans avoir mené et documenté ce que la loi appelle une évaluation des facteurs relatifs à la vie privée pour ce transfert s'expose à des sanctions administratives pécuniaires en son propre nom, indépendamment de ce que le fournisseur a fait ou non correctement. Le choix d'infrastructure du fournisseur devient l'angle mort de conformité du client. Une équipe d'approvisionnement qui signe un contrat avec un fournisseur d'IA constitué en société au Canada, qui saute la révision des sous-traitants parce que l'en-tête disait Toronto, et qui découvre plus tard que l'inférence transitait par une région américaine n'a pas pris le fournisseur en flagrant délit de mensonge — la documentation de Cohere divulguait le traitement multirégional assez clairement. C'est l'équipe qui a omis d'appliquer sa propre obligation de divulgation à ce fait avant la signature du contrat, et la CAI a précisé dans ses lignes directrices sur les transferts transfrontaliers que ce fardeau documentaire incombe à l'organisation qui effectue le transfert, et non au fournisseur dont elle a utilisé l'infrastructure.

Ce que le CLOUD Act peut réellement atteindre

Le CLOUD Act américain permet aux forces de l'ordre américaines de contraindre la divulgation de données par des fournisseurs assujettis à la juridiction américaine, peu importe où se trouvent physiquement les serveurs sous-jacents. C'est le détail qui se perd dans les arguments du type « notre fournisseur est canadien ». La juridiction s'attache au contrôle corporatif et à la structure opérationnelle, pas à une adresse postale.

Une entreprise constituée en société au Canada mais ayant une société mère américaine, des investisseurs majoritaires américains, ou des contrats d'infrastructure avec des fournisseurs infonuagiques américains peut tout de même créer une exposition au CLOUD Act pour les données des clients, parce que cette exposition suit la chaîne corporative et d'infrastructure, pas l'en-tête. Il ne s'agit pas ici d'une affirmation portant spécifiquement sur Cohere — l'entreprise n'a pas publié un portrait complet de sa structure de propriété corporative ou de sa table de capitalisation des investisseurs qui permettrait de trancher la question dans un sens ou dans l'autre. Il s'agit d'un point structurel sur le fonctionnement du CLOUD Act, et il s'applique à tout fournisseur d'IA qu'une organisation canadienne évalue, qu'il soit basé ici ou non.

La portée du CLOUD Act suit le contrôle corporatif et la juridiction de l'infrastructure, pas l'endroit où se trouve le siège social d'une entreprise.

Un lecteur sceptique pourrait faire remarquer que cela fonctionne dans les deux sens : un fournisseur sans société mère américaine et sans infrastructure américaine pour le contenu des clients peut tout de même être contraint de remettre des données par une ordonnance d'un tribunal canadien, une enquête de la CAI, ou un mandat en vertu du droit canadien, et le fait d'éviter le CLOUD Act n'y change rien. C'est exact, et il vaut la peine de le dire clairement, parce que l'expression « non assujetti au CLOUD Act » se retrouve parfois présentée comme si elle signifiait « non assujetti à aucune divulgation forcée ». Ce n'est pas le cas. Cela signifie qu'un mécanisme juridique américain précis n'atteint pas ces données par l'entremise d'un fournisseur contrôlé par les États-Unis. Le processus juridique canadien les atteint de la même façon qu'il atteint n'importe quelle entreprise qui opère ici, et c'est là une réalité différente — et incontournable — de faire des affaires dans une juridiction réglementée, point final.

C'est également là où l'argumentaire d'Augure se distingue du simple « nous aussi, on est canadiens ». Augure affirme n'avoir aucune société mère américaine ni aucun investisseur américain, et que les conversations, documents et inférences d'IA des clients sont traités sans transiter par des fournisseurs de juridiction américaine — ce qui signifie que la portée du CLOUD Act sur les entités contrôlées par les États-Unis ne s'étend pas à ce contenu client en particulier. L'inférence s'exécute sur une infrastructure canadienne pour certains niveaux de modèles et par l'entremise de partenaires européens validés sous des ententes de non-conservation des données pour d'autres, y compris la capacité de basculement, sans qu'aucune de ces opérations ne soit acheminée vers des fournisseurs d'inférence basés aux États-Unis, selon l'entreprise. Certaines fonctions en aval — le traitement des paiements par carte, l'acheminement des courriels — font effectivement appel à des services basés aux États-Unis, un détail qu'Augure divulgue dans sa politique de confidentialité plutôt que de le camoufler. Cette divulgation compte plus qu'on pourrait le penser, parce que la réponse honnête à la question « est-ce que quoi que ce soit touche à une infrastructure américaine » n'est presque jamais un « non » sans nuance pour une entreprise SaaS, et les fournisseurs qui prétendent le contraire sont généralement ceux qui n'ont pas lu leur propre liste de sous-traitants.

Bien lire une liste de sous-traitants

La solution pratique à la question « mon fournisseur est-il vraiment canadien » n'est pas de se fier à la page marketing. C'est de lire la divulgation des sous-traitants, que la plupart des fournisseurs sérieux publient et mettent à jour lorsqu'elle change.

Quelques éléments à vérifier dans ce document :

• Où les données sont stockées au repos, et si cet emplacement est divulgué par région ou laissé vague
• Où l'inférence ou le traitement a réellement lieu, ce qui peut différer de l'emplacement de stockage
• Si un sous-traitant est une entreprise de juridiction américaine, et pour quelle fonction
• Si les données des clients servent à entraîner les modèles du fournisseur, et si c'est un mécanisme de retrait volontaire ou une impossibilité structurelle

Bien lire cette liste n'est pas un exercice de cinq minutes, et il vaut la peine de nommer ce que ce processus implique réellement avant de le traiter comme une simple case à cocher. Cela signifie extraire le tableau des sous-traitants, recouper chaque entrée avec la politique de confidentialité du fournisseur pour comprendre à quelle fonction elle correspond, puis vérifier si une entrée a changé depuis la dernière fois qu'un conseiller juridique s'y est penché — la plupart des fournisseurs sérieux mettent la liste à jour au moins trimestriellement, certains seulement lors de changements substantiels, et une révision périmée est pire qu'aucune révision, car elle crée une trace documentaire laissant croire à une diligence qui n'a jamais eu lieu. Pour une organisation disposant d'un conseiller juridique externe spécialisé en confidentialité, cette révision représente typiquement quelques heures facturables par fournisseur, pas un mandat complet, à moins que la liste des sous-traitants ne révèle quelque chose qui nécessite une question de suivi directement auprès du fournisseur.

La documentation de confidentialité de Cohere elle-même est raisonnablement détaillée sur le traitement des données pour ses produits d'API, et l'entreprise a déclaré publiquement que les données des clients soumises par l'entremise de son API d'entreprise ne servent pas, par défaut, à entraîner ses modèles. C'est un engagement significatif. C'est toutefois un engagement différent d'une garantie juridictionnelle, et les organisations qui mènent des évaluations sous la Loi 25 doivent évaluer les deux séparément plutôt que de laisser l'un impliquer l'autre.

Le Commissariat à la protection de la vie privée du Canada a été direct à ce sujet dans ses lignes directrices sur l'IA et les obligations en matière de vie privée : la responsabilisation à l'égard des renseignements personnels ne se transfère pas simplement parce que le traitement a été confié à un tiers, et les organisations demeurent tenues de démontrer qu'elles ont évalué le risque. La Commission d'accès à l'information, qui applique la Loi 25 au Québec, a pris une position similaire dans ses lignes directrices publiées sur les transferts hors province — c'est l'organisation qui effectue le transfert qui porte le fardeau documentaire, pas le fournisseur.

Là où l'IA canadienne a réellement un avantage

Rien de tout cela ne fait de « IA canadienne » une étiquette vide de sens. Cela signifie que l'étiquette répond à une seule question, celle de la constitution en société et de la juridiction de la société mère, alors qu'une révision de conformité a besoin de réponses à plusieurs autres questions avant d'être complète.

Une plateforme d'IA canadienne véritablement souveraine mérite son positionnement en alignant les réponses à ces autres questions dans la même direction : stockage des données au Canada, infrastructure d'inférence exclusivement canadienne ou européenne sans acheminement vers les États-Unis pour le contenu des clients, aucune propriété américaine, et des modèles conçus en tenant compte du contexte réglementaire canadien plutôt qu'adaptés après coup. C'est une affirmation plus étroite que « nous sommes une entreprise canadienne », et c'est celle qui accomplit réellement le travail de conformité.

Augure est l'un des fournisseurs qui font cette affirmation plus étroite : résidence des données au Canada, inférence partagée entre une infrastructure canadienne et des partenaires européens sous des ententes de non-conservation des données, aucune société mère américaine, et des cadres de conformité pour la Loi 25 et la LPRPDE intégrés au produit plutôt qu'assemblés pour un appel de vente. Son architecture appuie le propre travail de conformité d'un client — elle ne s'y substitue pas. Ce n'est pas la seule option sur le marché, et une équipe d'approvisionnement qui l'évalue devrait lui poser les mêmes questions sur les sous-traitants qui viennent d'être exposées ici pour Cohere, parce que la réponse devrait résister au même examen minutieux.

Posez des questions sur la constitution en société, mais ne vous arrêtez pas là. Posez des questions sur le tableau des sous-traitants. Posez des questions sur l'emplacement de l'inférence, pas seulement sur l'emplacement du stockage. Demandez ce qui se passe en cas de basculement, parce que c'est souvent là que les véritables engagements d'infrastructure d'un fournisseur se révèlent et que les pages marketing deviennent floues. Qu'une entreprise soit canadienne est un fait qui vaut la peine d'être connu. C'est le début d'une évaluation de conformité, pas la fin.

Les organisations qui mènent cette évaluation peuvent consulter la documentation sur le traitement des données et les sous-traitants d'Augure au augureai.ca.