Un schéma que je rencontre constamment dans le secteur bancaire canadien : l'examen de l'architecture n'échoue pas sur la qualité du modèle. Il échoue sur une carte. Où va le prompt, où va le contexte, et quelle frontière traverse-t-il en chemin ? La plupart des architectures de référence multi-agents supposent tacitement que chaque agent peut appeler une API frontalière dans une autre juridiction. Dans les industries réglementées, cette hypothèse s'effondre dès la première réunion. Les données client ne peuvent pas sortir. Parfois, elles ne peuvent même pas quitter le segment réseau. Le schéma qui perdure est une frontière de confidentialité entre les agents. Les agents traitant des données sensibles s'exécutent localement, avec des modèles hébergés localement. Les agents traitant des données publiques (études de marché, recherche documentaire, tout ce qui est déjà "hors les murs") peuvent s'exécuter là où se trouve le meilleur modèle. La jonction protocolaire entre eux véhicule des descriptions de tâches et des conclusions, pas des enregistrements bruts. J'ai détaillé les mécanismes dans le [guide de terrain A2A](/fr/guides/a2a-field-guide/). Deux observations pratiques issues de cette construction. Premièrement, le choix du modèle devient une décision de souveraineté, pas seulement une décision de qualité, c'est pourquoi j'ai développé un [connecteur Cohere](https://github.com/zishan-c8academy/camunda-connector-cohere) pour l'orchestration de processus : un modèle robuste avec des options de déploiement qui s'intègrent "intra-muros". Deuxièmement, la frontière doit être appliquée par la couche d'orchestration, et non par le prompt de l'agent. Une instruction qui dit "ne pas envoyer de données client à l'extérieur" est un vœu pieux. Une topologie où l'agent externe ne reçoit jamais l'enregistrement est un contrôle. La souveraineté n'est pas une préoccupation canadienne de niche. Elle s'impose à toute architecture qui considère "appeler la meilleure API" comme une action libre.