La première étape de toute démarche de sécurisation est de savoir précisément quelles données transitent entre quels systèmes. Cette cartographie doit identifier la nature des données — transactionnelles, personnelles, agrégées — leur niveau de sensibilité, les systèmes source et destination, et les protocoles de transport utilisés. Sans cette cartographie, il est impossible d'évaluer les risques de manière cohérente. Les organisations qui ont sauté cette étape ont souvent découvert lors d'audits des flux de données sensibles qu'elles ignoraient ou qu'elles pensaient chiffrés mais qui ne l'étaient pas. La cartographie doit être maintenue à jour à chaque modification de l'architecture d'intégration, ce qui implique de l'intégrer dans les processus de gestion des changements.

L'authentification entre systèmes d'intégration est différente de l'authentification utilisateur. Les connexions machine-à-machine requièrent des mécanismes spécifiques — certificats mutuels TLS, tokens OAuth2 avec rotation automatique, clés API avec durée de vie limitée — qui doivent être choisis en fonction du niveau de sensibilité des données échangées. Une erreur fréquente est d'utiliser des credentials à longue durée de vie sans mécanisme de rotation, créant des risques significatifs en cas de compromission. La gestion du cycle de vie des credentials d'intégration — création, rotation, révocation — doit être formalisée dans les procédures opérationnelles de l'équipe responsable.

Le chiffrement des données financières en transit est une obligation réglementaire dans la plupart des contextes suisses. TLS 1.3 est aujourd'hui la version minimale recommandée pour les nouvelles intégrations. Au-delà du chiffrement en transit, les données financières au repos — dans les files de messages, les caches d'intégration ou les zones de transit temporaires — doivent également être chiffrées. Les équipes qui n'ont pas explicitement adressé le chiffrement des données au repos dans leurs couches d'intégration ont souvent des surprises lors des audits de sécurité. La gestion des clés de chiffrement est un sujet à part entière qui mérite une attention spécifique dès la conception.

Les exigences réglementaires du secteur financier suisse imposent une traçabilité des traitements automatisés qui va au-delà de la simple journalisation opérationnelle. Chaque décision influencée par un modèle IA doit pouvoir être reconstituée avec suffisamment de contexte pour satisfaire un auditeur externe. Cette exigence doit être traduite en contraintes concrètes sur l'architecture de journalisation : quelles données journaliser, pendant combien de temps les conserver, comment garantir leur intégrité et comment les rendre accessibles lors d'un audit. Un journal d'audit immuable, distinct des logs opérationnels, est une bonne pratique que les architectures financières les plus robustes partagent.

Une architecture de sécurité conçue sur le papier n'est pas une architecture de sécurité validée. Les tests de sécurité des flux d'intégration doivent inclure des tests de pénétration ciblés sur les points d'intégration, des tests de charge pour vérifier que les mécanismes de sécurité tiennent sous pression et des tests de gestion des erreurs pour s'assurer que les échecs d'authentification et les anomalies sont correctement détectés et alertés. Ces tests doivent être répétés à chaque modification significative de l'architecture d'intégration, pas seulement lors de la mise en production initiale.