Quand Washington peut couper votre IA: le réveil de la souveraineté numérique canadienne (Bye Bye Mythos)

Si une directive étrangère peut suspendre du jour au lendemain une capacité numérique critique, le problème dépasse la technologie; il touche l'architecture, la gouvernance et la continuité.

On aime bien se raconter que les services infonuagiques sont mondiaux, toujours disponibles, presque neutres. Jusqu'au jour où la réalité débarque avec ses grosses bottes. Une décision réglementaire tombe, un fournisseur coupe un accès, une capacité qu'on croyait durable devient soudainement conditionnelle. Et là, surprise: le nuage avait une adresse légale depuis le début.

La suspension récente d'accès à des capacités avancées d'IA, à la suite d'une directive américaine, n'est pas juste une nouvelle de plus dans le grand buffet techno. Pour les organisations canadiennes, c'est un rappel assez sec que la souveraineté numérique ne se résume pas à choisir une belle plateforme avec une bonne page marketing. C'est une question de pouvoir d'accès, de dépendance, de résilience et de gouvernance réelle.

Chez JPSoftWorks, on le dit déjà sans trop de poésie: la résilience de plateforme ne s'achète pas comme une option fournisseur. Elle vit dans le design de reprise, dans les habitudes d'ingénierie et dans la gouvernance qui tient quand la journée tourne croche. Cet épisode-là ne fait qu'étendre cette vérité au monde de l'IA.

Le mythe du service "mondial"

Dans bien des organisations, surtout celles qui ont avancé vite sur le cloud et l'automatisation, on a fini par traiter certains fournisseurs comme des services publics privés. C'est pratique, c'est accessible, c'est documenté, et ça semble disponible partout. On finit par oublier qu'en arrière de l'API, il y a une entreprise, des obligations légales, des contrôles d'exportation, une juridiction, puis une marge de manœuvre qui n'appartient pas au client.

Autrement dit, quand on adopte un service, on n'adopte pas juste une fonctionnalité. On adopte aussi les limites politiques, contractuelles et réglementaires qui viennent avec. C'est moins sexy qu'une démo produit, mais c'est beaucoup plus utile le jour où ça casse.

Et quand cette dépendance touche une capacité qui commence à influencer vos opérations, vos processus d'analyse, vos assistants de développement, vos outils de support ou vos mécanismes de prise de décision, on n'est plus dans le laboratoire. On est dans l'exploitation.

La souveraineté numérique, ce n'est pas juste "les données sont au Canada"

Il faut élargir la conversation. Oui, la résidence des données compte. Bien sûr. Mais si on s'arrête là, on regarde le problème par le petit bout de la lorgnette.

La souveraineté numérique, c'est aussi:

• qui peut suspendre l'accès au service;
• qui contrôle l'identité et les autorisations;
• qui peut retirer une fonction critique sans négociation;
• si les journaux, artefacts, paramètres et sorties sont exportables;
• si un mode dégradé existe pour continuer à opérer;
• si les contrats couvrent vraiment un scénario de restriction réglementaire.

Vu comme ça, la souveraineté devient une propriété d'exploitation, pas juste une case de conformité. Et ça, en DevSecOps, on devrait être capables de le comprendre assez vite. Après tout, on prône déjà une gouvernance intégrée, des politiques-en-tant-que-code, des contrôles embarqués dans les pipelines et des revues de conformité qui ne sont pas collées à la fin du projet comme un plaster sur une fuite.

Le problème canadien: une dépendance de décision

Au Canada, notre enjeu n'est pas seulement la dépendance technologique aux plateformes américaines. C'est la dépendance au maintien d'accès. Nuance importante. On peut héberger, développer, collaborer, déployer, scanner, journaliser et même raisonner à partir d'outils formidables… tout en restant exposés à des décisions prises ailleurs, selon des intérêts qui ne sont pas nécessairement les nôtres.

Ça vaut pour le cloud. Ça vaut pour l'identité. Ça vaut pour les pipelines CI/CD. Ça vaut pour des outils de sécurité. Et maintenant, ça vaut aussi pour certaines capacités d'IA qu'on commence à brancher dans des processus qui comptent vraiment.

Ce n'est pas une critique morale. C'est une lecture de risque. Si une autorité étrangère peut changer vos conditions d'exploitation plus vite que votre comité d'architecture peut convoquer une rencontre, vous avez un enjeu de continuité d'affaires, pas juste un enjeu techno.

Les questions qu'une organisation mature devrait déjà poser

C'est ici qu'on quitte les belles abstractions pour revenir au plancher des vaches.

Pour chaque dépendance critique, surtout celles liées à l'IA, les dirigeants et architectes devraient être capables de répondre à des questions très simples:

• Peut-on remplacer cette capacité en moins de 30 jours?
• Avons-nous une couche d'abstraction ou sommes-nous soudés à une API propriétaire?
• Nos prompts, journaux, résultats, configurations et preuves sont-ils exportables?
• Que devient notre flux opérationnel si ce fournisseur est bloqué, suspendu ou dégradé?
• Les identités, secrets et approbations peuvent-ils survivre à cette perte?
• A-t-on inclus ce scénario dans la gouvernance de continuité?

Si ces réponses sont floues, le problème n'est pas l'IA. Le problème, c'est qu'on a laissé une dépendance critique pousser sans la gouverner.

Le réflexe DevSecOps s'applique ici aussi

Le plus ironique là-dedans, c'est qu'on possède déjà une bonne partie des réflexes nécessaires. Le DevSecOps nous apprend que la sécurité fait partie de la route, pas d'un guichet final. Il nous apprend aussi que l'automatisation utile doit rester visible, gouvernée, traçable, et qu'elle doit servir les gens plutôt que les remplacer.

Donc, si une capacité IA entre dans vos façons de livrer ou d'opérer, elle doit être soumise aux mêmes exigences que le reste:

• traçabilité dans les flux CI/CD;
• supervision humaine pour les usages significatifs;
• moindre privilège sur les intégrations et accès;
• observabilité sur l'usage, la dérive et les pannes;
• garde-fous techniques et de gouvernance;
• plan de relève réaliste quand l'accès disparaît.

Ce n'est pas être parano. C'est juste arrêter de confondre commodité et maîtrise.

Quelques anti-patterns qu'on devrait cesser d'ignorer

Il y a des habitudes qu'on voit encore trop souvent.

La première, c'est le culte du gros fournisseur: croire qu'un acteur énorme élimine le risque stratégique. Non. Il en réduit certains, puis il en concentre d'autres.

La deuxième, c'est le couplage paresseux: intégrer directement une capacité propriétaire partout sans couche d'abstraction, sans classification des usages, sans stratégie de sortie. Après ça, on appelle ça "innovation rapide". Jusqu'à la facture.

La troisième, c'est le théâtre de conformité: parce qu'on a parlé de confidentialité et signé des clauses standards, on se convainc qu'on a traité la souveraineté, la continuité et la dépendance juridictionnelle. Malheureusement, non.

Et la quatrième, mon classique préféré, c'est la résilience PowerPoint: un fournisseur de relève jamais branché, un mode dégradé jamais testé, puis une belle conviction exécutive que "ça devrait aller". D'habitude, c'est là que quelqu'un passe sa fin de semaine en incident majeur.

Une posture canadienne plus crédible

Non, la solution n'est pas de tout rapatrier dans un bunker numérique à saveur d'érable. Le vrai travail est plus exigeant, et pas mal moins photogénique.

Une posture sérieuse devrait inclure:

• une cartographie des dépendances numériques soumises à une juridiction étrangère;
• une classification des services IA selon leur impact sur les opérations;
• des architectures plus portables et moins collées à un seul fournisseur;
• l'exportabilité des données, journaux, configurations et artefacts;
• des identités, secrets et flux d'approbation capables de survivre à une interruption fournisseur;
• de l'infrastructure en tant que code, du policy-as-code et des contrôles auditables pour rendre la migration moins improvisée;
• des exercices de continuité qui testent la perte d'une capacité IA, pas seulement la perte d'un serveur.

Le but, ce n'est pas d'éliminer toute dépendance étrangère. Ce serait irréaliste. Le but, c'est d'arrêter de dépendre aveuglément. Nuance essentielle.

Le fond du problème

Chaque État protège ses intérêts. Ce n'est pas ça, le scandale. Le vrai problème, c'est de bâtir nos opérations comme si ces intérêts n'allaient jamais entrer en collision avec les nôtres.

Pour les organisations canadiennes, la souveraineté numérique ne commence pas avec un drapeau dans une présentation exécutive. Elle commence quand on est capables de nommer ce qui peut nous arrêter, de mesurer combien de temps on peut survivre sans ces dépendances, puis de concevoir des plateformes qui encaissent le choc sans s'effondrer comme une chaise pliante cheap.

Si cet épisode crée un malaise, tant mieux. Un malaise utile vaut mieux qu'une fausse impression de contrôle. C'est peut-être le bon moment pour remplacer l'optimisme contractuel par de la gouvernance, puis la dépendance implicite par des choix d'architecture assumés.

Et ça, honnêtement, c'est une conversation qui mérite d'avoir lieu avant la prochaine coupure, pas après.

Références

• Annonce d'Anthropic sur la suspension d'accès à Fable 5 et Mythos 5: https://www.anthropic.com/news/fable-mythos-access
• JPSoftWorks: la résilience de plateforme ne s'achète pas comme une option fournisseur