Souveraineté numérique : cinq dimensions à doser selon votre organisation

Héberger ses données à Montréal ne suffit pas à les rendre souveraines. Un serveur situé au Canada, mais opéré par une entreprise américaine, reste soumis au CLOUD Act (2018), qui permet aux autorités américaines d'exiger d'une entreprise sous leur juridiction les données qu'elle détient, où qu'elles soient stockées. Confondre résidence des données et souveraineté est l'erreur la plus répandue, et l'intelligence artificielle la rend plus coûteuse : chaque question envoyée à un modèle, chaque document indexé, chaque journal conservé est un flux de plus à maîtriser.

Cet article s'appuie sur les travaux du chantier Architectures IA souveraines de la Brigade IA, que dirige notre fondateur. Il en résume la grille de lecture pour les dirigeants : cinq dimensions, un spectre d'options pour chacune, et une façon de décider ce qui doit être souverain selon le type d'organisation. Pour le volet stratégique (dépendance aux fournisseurs, expertise interne), voir aussi notre article sur la souveraineté technologique.

Qu'est-ce que la souveraineté, concrètement?

Être souverain, c'est pouvoir décider soi-même de ses choix technologiques et les faire respecter : examiner, modifier, déplacer ou remplacer ses données, ses modèles et ses infrastructures sans qu'un fournisseur ou un État tiers puisse imposer une décision, couper l'accès ou exiger les données. Le Cadre de souveraineté numérique du gouvernement du Canada la décrit comme la capacité d'exercer une autonomie sur son infrastructure numérique, ses données et sa propriété intellectuelle.

Deux nuances changent tout. D'abord, la souveraineté n'est pas un absolu : elle se mesure en degrés, et un niveau faible n'est pas fautif en soi, il dépend de ce qu'on protège. Ensuite, souveraineté et sécurité ne progressent pas toujours ensemble. Les grands fournisseurs infonuagiques offrent d'emblée une sécurité mature (équipes en service continu, certifications, correctifs rapides) difficile à reproduire à l'interne. Une architecture plus souveraine permet d'aller plus loin (isolation complète, clés de chiffrement sous contrôle exclusif, journaux conservés à l'interne), mais seulement si l'organisation investit dans les compétences pour l'exploiter.

Une analogie aide à situer les options : on peut louer un appartement clé en main (l'API publique d'un fournisseur), acheter un condo dans une tour gérée par un syndicat (un nuage dédié ou souverain) ou construire sa maison sur son propre terrain (une infrastructure déployée sur site). Aucune option n'est meilleure en soi. L'erreur la plus fréquente n'est pas de choisir la mauvaise, mais de choisir sans avoir vu le menu complet.

Cinq dimensions, cinq questions

Un système peut être souverain sur une dimension et dépendant sur une autre. Un modèle ouvert déployé chez un fournisseur soumis au CLOUD Act donne le contrôle des poids, pas celui de l'infrastructure. Un modèle propriétaire branché sur une base documentaire hébergée à l'interne protège le corpus au repos, mais la question de l'utilisateur et les extraits retrouvés partent chez le fournisseur à chaque requête. Ces écarts ne sont pas un problème en soi. Ils le deviennent quand ils sont invisibles.

1. Les données : qui contrôle ce qui alimente le système?

Quatre catégories circulent dans un système d'IA : les données d'entraînement du modèle, les données de référence de l'organisation (documents interrogés, jeux d'ajustement), les requêtes et réponses échangées à chaque interaction, et les traces d'utilisation (journaux, caches). Les requêtes sont les plus exposées; les traces, les plus négligées. Du moins au plus souverain, le spectre va comme suit :

• service externe sans entente particulière, où les données peuvent servir à entraîner le modèle du fournisseur;
• service externe avec entente professionnelle (exclusion de l'entraînement, conservation bornée);
• environnement dédié chez un grand fournisseur infonuagique;
• environnement dédié avec chiffrement sous des clés que seule l'organisation détient (HYOK);
• fournisseur canadien hors de toute juridiction étrangère;
• hébergement complet sur les serveurs de l'organisation.

Un piège fréquent : gérer ses propres clés chez le fournisseur (BYOK) améliore le contrôle de leur cycle de vie, mais ne change rien à l'exposition juridictionnelle, puisque les clés restent dans son infrastructure. Seules des clés hors de sa portée (HYOK) modifient ce paramètre.

2. Le modèle : qui contrôle ses poids, son comportement et ses mises à jour?

Le critère fondamental est l'accès aux poids du modèle. Sans lui, le fournisseur peut modifier le comportement, augmenter les prix ou retirer le service sans que l'organisation dispose d'une solution de rechange immédiate.

• API propriétaire dont la version évolue sans préavis;
• API propriétaire à version figée : stable, mais avec des migrations imposées;
• modèle ouvert déployé chez un grand fournisseur : souveraineté du modèle, pas de l'infrastructure;
• modèle ouvert déployé sur site ou chez un fournisseur souverain;
• modèle ouvert ajusté sur les données de l'organisation, dans un environnement qu'elle contrôle.

Attention : confier l'ajustement à la plateforme d'un fournisseur lui transmet les données d'ajustement, et la version spécialisée peut rester captive de sa plateforme. La souveraineté recule alors au lieu de progresser.

3. L'infrastructure : où s'exécutent les traitements, et sous quel droit?

C'est la dimension la plus difficile à pousser jusqu'au bout, parce que le matériel subit des contraintes physiques et géopolitiques mondiales. Trois paliers se dessinent :

• souveraineté juridique et opérationnelle : un nuage opéré par une entité canadienne, sans société mère étrangère, avec une orchestration ouverte; les puces, elles, proviennent toujours d'un petit nombre de fabricants étrangers;
• souveraineté physique : des serveurs possédés et un environnement déconnecté, sans flux sortant; la dépendance se déplace vers les pièces de rechange et le renouvellement du matériel;
• souveraineté technologique totale : de la conception des puces à leur fabrication; hors de portée de presque toutes les organisations pour l'IA de pointe.

4. La couche applicative : qui décide de ce que l'IA fait réellement?

C'est la dimension sur laquelle l'organisation garde le plus de prise, quel que soit le modèle. Quatre questions suffisent pour se situer. La logique qui entoure l'appel au modèle est-elle lisible, modifiable et portable? Les garde-fous survivraient-ils à un changement de modèle? Pourrait-on justifier une décision trois mois plus tard à partir de journaux que l'on contrôle? A-t-on défini non seulement qui utilise l'IA, mais ce que l'IA a le droit de faire? À une extrémité du spectre se trouve un service opaque; à l'autre, une couche que l'organisation possède, examine et peut redéployer ailleurs.

5. Les opérations : qui peut maintenir et faire évoluer le système?

Une architecture souveraine sur papier ne l'est réellement que si l'organisation peut reproduire le système, examiner son comportement passé, le corriger sans l'accord d'un fournisseur et remplacer le modèle sans refondre l'application. Cela suppose des environnements distincts, un registre des modèles, une surveillance de la dérive et des journaux conservés sous son contrôle. Sans ces pratiques, un système est en production, pas en exploitation.

Organisme public ou entreprise privée : ce qui doit être souverain diffère

Dans un organisme public, l'enjeu central est la confiance des citoyens : leurs renseignements personnels, la continuité de services essentiels et la reddition de comptes. Avant de communiquer un renseignement personnel à l'extérieur du Québec, la Loi sur l'accès aux documents des organismes publics exige une évaluation des facteurs relatifs à la vie privée (art. 70.1), et l'Énoncé de politique de souveraineté numérique du Québec vise à réduire la dépendance technologique de l'État. Pour les usages sensibles, la cible devient un modèle ouvert sur une infrastructure contrôlée, une couche applicative possédée et des journaux conservés à l'interne. Les services externes encadrés gardent leur place pour l'exploration et les données publiques.

Dans une entreprise privée, l'enjeu se déplace vers la propriété intellectuelle, les secrets d'affaires, les exigences des clients et des assureurs, et le coût. La Loi sur la protection des renseignements personnels dans le secteur privé impose elle aussi une évaluation avant toute communication hors Québec (art. 17). La plupart des entreprises gagnent à une architecture combinée : services externes encadrés pour les usages courants, base documentaire souveraine pour le savoir qui les distingue, environnement sous leur contrôle pour les secrets industriels.

Dans les deux cas, la sensibilité des données guide le curseur :

• données publiques ou promotionnelles : un service infonuagique public, encadré par contrat, suffit souvent;
• données de ressources humaines, opérationnelles ou personnelles : un nuage canadien hors de toute juridiction étrangère;
• secrets industriels, santé, juridique : un environnement sur site, voire déconnecté.

Comment y tendre : une trajectoire, pas un saut

Trois questions orientent la plupart des décisions. Quelle est la classification la plus élevée des données qui transiteront par le système? Quel volume d'usage est attendu, et avec quelle variabilité? Quelle capacité d'exploitation interne peut-on bâtir d'ici 12 à 18 mois?

Les organisations passent rarement d'un coup à l'hébergement sur site. La trajectoire courante va de l'assistant branché sur une API à une base documentaire souveraine (RAG), dont l'index et les contrôles d'accès restent à l'interne, puis à un modèle ouvert déployé sur une infrastructure contrôlée pour les usages sensibles. Les agents s'ajoutent ensuite comme couche d'orchestration, avec le principe du moindre privilège et une validation humaine pour toute action irréversible.

Ce qui rend cette trajectoire possible se décide dès le premier projet : une couche d'abstraction qui permet de changer de modèle, des formats ouverts, une journalisation conservée chez soi et des tests de régression versionnés. Une question simple sert de test : si votre fournisseur doublait ses prix demain, combien de temps vous faudrait-il pour migrer?

Le rôle du leader : arbitrer en connaissance de cause

Ces choix ne sont pas d'abord techniques. Ils engagent le budget, le risque juridique, la continuité des services et la capacité d'innover. Un dirigeant n'a pas à configurer un moteur d'inférence, mais il doit savoir lire le menu complet, poser les bonnes questions aux fournisseurs et distinguer un compromis assumé d'une dépendance subie.

C'est ce que vise notre programme de coaching IA : un accompagnement individuel, à partir de votre contexte, pour cartographier vos dépendances dimension par dimension, situer chacun de vos cas d'usage sur son spectre, décider ce qui doit être souverain chez vous et bâtir la trajectoire pour y arriver. Vous êtes accompagné par Olivier Garand, qui dirige le chantier Architectures IA souveraines de la Brigade IA. Notre fondateur cumule 25 ans d'expérience en technologies de l'information, au public comme au privé, avec une expérience concrète de l'intégration de l'IA en entreprise.

Le bon niveau de souveraineté n'est pas le plus élevé possible. C'est celui que vous avez choisi en connaissant les options, et que vous pouvez faire évoluer.