Les faits : Google rapproche l’agent, les contrôles et les données
Google a présenté le 8 octobre son « agent Gemini » comme un assistant capable de travailler dans Gmail, Drive, Docs, Slides, Sheets, Chat et Calendar. Selon l’entreprise, le produit doit respecter l’identité et les permissions de chaque personne, utiliser des environnements isolés et passer par des passerelles réseau contrôlées lorsqu’il agit dans d’autres systèmes. Google ajoute des limites de dépenses et une orchestration de plusieurs modèles. Autrement dit, le lancement porte autant sur les accès et la gouvernance que sur le modèle lui-même. Le fournisseur affirme que près de 80 % de ses clients infonuagiques utilisent déjà ses produits d’IA et que près de 90 % des entreprises du Fortune 100 emploient Gemini Enterprise. Ces chiffres viennent de Google et ne constituent pas une mesure indépendante. Ils montrent néanmoins pourquoi le lieu d’exécution devient une question opérationnelle. La documentation de Gemini Enterprise offre maintenant des régions nationales, dont le Canada, pour la résidence des données au repos et le traitement d’apprentissage automatique. L’accès général demeure soumis à une liste d’autorisation, et certaines fonctions régionales diffèrent de l’offre mondiale.
Résider, traiter et contrôler sont trois questions différentes
La résidence décrit surtout l’endroit où les données persistantes sont conservées. Elle ne dit pas automatiquement où un message est traité, où une copie de sauvegarde se trouve, qui peut consulter les journaux ni quelle équipe intervient pendant un incident. Google reconnaît lui-même cette distinction : dans sa documentation sur la souveraineté, l’entreprise écrit que la résidence seule est souvent insuffisante et que le traitement d’apprentissage automatique doit aussi se dérouler dans le territoire exigé. Le contrôle ajoute une troisième couche. Une organisation peut stocker et traiter au Canada tout en dépendant d’un fournisseur étranger pour les clés, l’identité, les connecteurs, les mises à jour et la résolution des pannes. Elle peut aussi avoir choisi une fonction qui revient à une région mondiale lorsque l’équivalent canadien n’existe pas. La bonne question n’est donc pas seulement « nos données sont-elles au Canada? », mais « quelles données, à chaque étape, sous quelle autorité et avec quelles preuves? ». Cette nuance transforme une promesse de marketing en architecture vérifiable.
Au Québec, le lieu du serveur ne remplace pas l’EFVP
La Commission d’accès à l’information rappelle que, depuis septembre 2023, une organisation doit mener une évaluation des facteurs relatifs à la vie privée avant de communiquer un renseignement personnel à l’extérieur du Québec. La Loi 25 demande notamment de considérer la sensibilité du renseignement, la finalité de son utilisation, les mesures de protection prévues au contrat et le régime juridique applicable dans le territoire visé. Une région canadienne ne répond donc pas à elle seule à toutes les questions de conformité. Une équipe devrait cartographier le trajet complet des requêtes, des réponses, des pièces jointes, des index de recherche, des journaux, des sauvegardes et des données de soutien. Si un employé branche un agent à une boîte courriel ou à un disque partagé, la portée réelle peut dépasser de loin le document qu’il croit analyser. Le contexte, les métadonnées et les résultats intermédiaires peuvent aussi contenir des renseignements personnels. Cette analyse ne remplace pas un avis juridique; elle permet toutefois de repérer les décisions qui exigent l’intervention des responsables de la vie privée, de la sécurité et des contrats.
La souveraineté se mesure le jour où le fournisseur change
Une offre paraît souveraine tant que tout fonctionne. Le véritable test arrive lorsque le prix augmente, qu’une fonction régionale disparaît, qu’un modèle est retiré ou qu’un incident exige une enquête. L’organisation peut-elle exporter ses configurations, ses journaux et ses index dans un format utilisable? Peut-elle remplacer le modèle sans reconstruire tous les connecteurs? Peut-elle révoquer elle-même les clés et prouver la suppression des copies? Un contrat qui promet un lieu de stockage, mais ne prévoit ni portabilité ni délai de sortie, laisse un risque important intact. Les nouveaux agents rendent cette dépendance plus profonde. Ils ne font pas qu’héberger un fichier : ils relient l’identité, les permissions, les outils et les étapes d’un processus. Plus une organisation automatise autour d’un seul environnement, plus le coût d’un changement dépasse la facture infonuagique. Mon interprétation est qu’une souveraineté utile repose sur la capacité de décider et de partir, pas sur une case géographique. Elle peut inclure un service étranger, à condition que les choix critiques restent documentés, réversibles et testés.
Un test en six preuves plutôt qu’une case Canada
Avant de déployer un agent, une organisation peut demander six preuves concrètes. Premièrement, un schéma d’architecture qui nomme chaque région. Deuxièmement, un inventaire des données couvrant les messages, les sorties, les journaux, les sauvegardes et le soutien. Troisièmement, les clauses sur les sous-traitants, les demandes légales et les délais d’avis. Quatrièmement, la liste des personnes qui contrôlent les clés, les rôles administratifs et les connecteurs. Cinquièmement, les limites fonctionnelles de la région canadienne, y compris tout traitement mondial. Sixièmement, un exercice d’exportation, de suppression et de continuité avec un délai mesuré. Ce test évite deux raccourcis. Héberger localement ne rend pas un système automatiquement sécuritaire; une mauvaise permission peut exposer des données dans la même province. À l’inverse, un fournisseur mondial n’empêche pas toute maîtrise si l’architecture, les contrats et le plan de sortie donnent des contrôles réels. L’annonce de Google illustre une tendance utile : les fournisseurs ajoutent des choix régionaux et des outils de gouvernance. Pour les organisations québécoises, la prochaine étape consiste à exiger des preuves qui couvrent tout le cycle de vie, puis à les retester lorsque le modèle, le produit ou le contrat change.
