Tout le monde au Canada parle de souveraineté en ce moment. Telus a un centre d'IA souverain à Rimouski. Bell construit un supercluster souverain en Colombie-Britannique. CGI y consacre une page. DXC a ouvert un centre à Halifax pour l'occasion. Entre ton café du matin et ton fil d'actualité LinkedIn, tout le monde en parle.
Personne ne se demande à qui leur fournisseur de cloud doit vraiment rendre des comptes.
C’est la question qui se cache derrière les communiqués de presse. Il ne s’agit pas de savoir où se trouvent les données, mais qui peut en exiger l’accès. Quel tribunal est compétent pour juger l’entreprise qui gère l’infrastructure où tes données sont stockées ? Qu’en est-il de ta position en matière de souveraineté lorsque cette entreprise signe un nouveau partenariat, est rachetée ou restructure sa forme juridique dans une juridiction qui n’est pas la tienne ? Ce sont des questions d’architecture, pas de marketing, et pour l’instant, c’est le marketing qui occupe tout le devant de la scène.
La juridiction que tu n'as pas choisie
Le CLOUD Act américain autorise les forces de l’ordre américaines à obliger les entreprises basées aux États-Unis à fournir des données, peu importe où elles sont stockées. En juin 2025, le directeur des affaires juridiques et publiques de Microsoft France a déclaré sous serment devant le Sénat français qu’il ne pouvait pas garantir que les données des citoyens français resteraient hors de portée des autorités américaines. Pas dans un communiqué de presse. Sous serment. Ce qui était le plus révélateur dans ce témoignage, ce n’était pas l’analyse juridique.C’était la confirmation que le stockage local des données ne résout pas le problème si l’entreprise qui les détient doit répondre à un tribunal étranger.
Des études citées dans les documents Balsillie ont montré qu’une part importante du trafic Internet canadien passe par des points d’échange américains avant d’atteindre sa destination. Tes données ont quitté le Canada pendant trois millisecondes lors de leur trajet de Toronto à Montréal, sans que tu en sois informé. C’est le problème d’architecture qui est à l’origine du problème juridique. Un centre de données canadien avec un drapeau canadien sur son site web, mais dont la société mère est enregistrée au Delaware.
Et puis, il y a la couche IA. Celle qui relie ce sujet à tout ce qui a été abordé dans les trois premiers articles de cette série. Les modèles intégrés par les fournisseurs que ton CRM a ajoutés lors d’une mise à jour logicielle. L’assistant IA que ton service client utilise pour trier les tickets. Le chatbot qui résume les interactions avec les clients. Chacun traite tes données au sein d’une plateforme dont la société mère pourrait devoir répondre devant un tribunal étranger. Certains s’entraînent sur les données qu’ils manipulent, selon des conditions d’utilisation enfouies dans une note de mise à jour que personne n’a remarquée. Quand un fournisseur SaaS de confiance annonce un partenariat pour entraîner un nouveau LLM financé par un fonds d’investissement étranger, tes données clients pourraient se retrouver dans l’ensemble d’entraînement. Pas parce qu’il y a eu une faille de sécurité, mais parce que l’architecture l’a permis et que personne n’a posé la question.
Tu ne peux pas sécuriser une IA qui repose sur une infrastructure que tu ne contrôles pas. Et tu ne peux pas parler de souveraineté quand l'entreprise qui détient les clés reçoit des ordres de quelqu'un d'autre que toi.
Gary a signé un contrat de trois ans avec une clause de résiliation de douze mois
L'équipe d'approvisionnement de Gary a choisi le fournisseur de services cloud. L'équipe commerciale a parlé d'un centre de données canadien, a montré un endroit sur une carte et a souri. L'équipe de Gary a signé. L'équipe chargée de la conformité a coché la case « lieu d'implantation ». Tout le monde est passé au projet suivant.
Personne n’a demandé à qui appartient l’entreprise propriétaire du centre de données. Personne n’a demandé ce qui se passerait si cette entreprise était rachetée par une société enregistrée dans un pays avec lequel le Canada est en conflit commercial. Personne n’a demandé ce qu’exigeait réellement la clause de sortie : un préavis de douze mois et une migration jamais prévue, impliquant des dépendances non documentées et des systèmes interconnectés par un prestataire parti en 2021.
Le mois dernier, une nouvelle sur les droits de douane a fait la une. Le directeur financier a demandé : « Est-ce qu’on peut tout délocaliser ? » Un silence s’est installé. Pas parce que la réponse est non, mais parce qu’elle est : « Pas sans casser des liens invisibles, selon un calendrier imprévisible et à un coût impossible à estimer. » Pendant ce temps, le fournisseur vient d’annoncer un nouveau partenariat en IA avec une entreprise que Gary ne connaît pas, basée dans un pays avec lequel le gouvernement canadien est en plein conflit sur le bois d’œuvre et les pièces automobiles. L’architecture de Gary ne peut pas s’adapter à tout ça. Elle a été conçue pour fonctionner, pas pour changer.
Ce n'est pas de la souveraineté. C'est une prise d'otage où la rançon, c'est ta propre architecture d'intégration.
La souveraineté, c'est pouvoir changer d'avis
Chaque communiqué de presse sur l'IA souveraine parle de l'endroit où se trouvent les données. Personne ne parle de ce qui se passe quand il faut les déplacer.
L’interchangeabilité, c’est la souveraineté en action. Ça veut dire que tu comprends suffisamment bien tes dépendances pour pouvoir remplacer n’importe quel élément de ta pile technologique sans que le reste ne s’effondre. Ça veut dire qu’aucun fournisseur, y compris celui qui écrit cet article, ne détient les clés de tes données ou de tes plateformes. Ça veut dire que ta couche de gouvernance de l’IA sait quels modèles accèdent à quelles données, où vont les résultats et ce qui change si tu changes de fournisseur le trimestre prochain. Ça veut dire que quand le monde change un mardi matin, tu prends une décision au lieu de te rendre compte que tu en es incapable.
Ça demande un boulot fastidieux. Cartographier les dépendances. Documenter les flux de données. Concevoir une architecture d’intégration pensée pour être démantelée. Faire l’inventaire des actifs d’IA pour savoir quels outils s’entraînent sur quoi et où vont les données. Le genre de boulot qui ne fait pas l’objet d’un communiqué de presse, mais qui s’avère utile lors de la réunion où le directeur financier demande « est-ce qu’on peut changer ça ? » et où quelqu’un répond « oui » en toute connaissance de cause. On a abordé les bases dans la série sur les données et sur la page consacrée à la souveraineté des données.
La réponse que ton client n'a jamais besoin de demander
ISM est profondément ancrée dans l’infrastructure du gouvernement et des entreprises canadiennes depuis plus de cinquante ans. Pas au gré de cycles de consultation de trois ans. Elle est intégrée. Ce sont les personnes qui ont mis en place ces systèmes, qui savent où se cachent les dépendances non documentées, qui se souviennent pourquoi la solution de contournement de 2004 est toujours indispensable et quels sont les trois éléments qui vont planter si tu la déplaces.
Grâce à la solidité des partenariats de Kyndryl, l’architecture n’est pas liée à la pile technologique d’un seul fournisseur. Quand une charge de travail doit être acheminée vers l’Europe ou le Japon pour des raisons de conformité ou de latence, on ne fait pas appel à des équipes sous-traitantes. Ce sont des collègues au sein de la même entreprise, soumis au même cadre de gouvernance. Le centre des opérations de sécurité (SOC) de Barrie est composé de Canadiens ayant reçu une habilitation de sécurité, conformément à la législation canadienne. Les clés de chiffrement restent là où le client les place. La gouvernance d’entreprise est assurée depuis la Saskatchewan, et non depuis la Virginie.
L’objectif, c’est une architecture dont tu gardes le contrôle. Où tu sais exactement où se trouvent tes données et comment elles circulent. Où l’histoire que tes clients se racontent est celle que tu veux : leurs données sont au Canada, gérées par des Canadiens, régies par la législation canadienne. Sans mise en garde. Sans notes de bas de page. Sans petits caractères qui s’effacent dès qu’une personne en Virginie décroche le téléphone. Le client qui reste, c’est parce qu’il n’a jamais eu de raison de se poser des questions. Le coût d’une souveraineté bien assurée, ce n’est pas une ligne budgétaire dédiée aux infrastructures. C’est la question qu’on n’a jamais besoin de poser.
À lire ensuite
Tu peux concevoir une architecture parfaite sans avoir les ressources humaines pour la mettre en place. Le prochain article parle de cette offre d’emploi en sécurité de l’IA que personne ne peut pourvoir : architecture de sécurité, gouvernance des données, ML ops et conformité, tout ça pour une seule personne. Cette personne n’existe pas. Le poste, lui, existe bel et bien. Il y a une autre façon de constituer l’équipe. Le problème, c’est le manque de ressources humaines.
Références
Gouvernement du Canada : Souveraineté des données et cloud public (livre blanc sur les limites de la souveraineté face aux fournisseurs de cloud étrangers)
Les documents Balsillie: implications de la loi américaine CLOUD Act pour les données canadiennes et l'acheminement du trafic Internet via des points d'échange américains
Déposition de Microsoft France devant le Sénat français, juin 2025 : impossibilité de garantir la souveraineté des données, quel que soit leur lieu de stockage
OVH c. GRC, Cour de justice de l'Ontario, septembre 2025 : un tribunal canadien ordonne à une entreprise française de communiquer des données stockées en Europe
