Lecture seule par conception

Sécurité chez Mozaic : lecture seule, chiffré, posé.

Partager ses informations financières, c'est un geste sérieux. Voici exactement ce que Mozaic peut faire, ce qu'il ne peut pas faire, et comment nous gardons le périmètre suffisamment petit pour être défendable. Pas de mots à la mode, pas de mise en scène « grade militaire » : juste les choix d'architecture qui rendent les paragraphes suivants vrais.

7 engagements · 5 questions · Dernière revue 2026-05-24
01 · Connexions

Connexions de niveau bancaire via Plaid et SnapTrade

Mozaic ne manipule pas directement les identifiants bancaires ou de courtage. Lorsque vous connectez un compte, vous vous identifiez auprès de votre institution via Plaid (pour les banques canadiennes et américaines) ou SnapTrade (pour les courtiers), et vos identifiants passent directement de vous à la banque. Mozaic ne reçoit jamais qu'un jeton d'accès opaque utilisable uniquement pour lire les soldes, les positions et les transactions : jamais pour s'authentifier comme vous, jamais pour récupérer votre mot de passe.

Plaid et SnapTrade sont tous deux audités SOC 2 Type II, transportent tout via du TLS 256 bits et utilisent OAuth ou ses équivalents bancaires partout où les institutions le supportent. Nous les avons choisis précisément parce que leur posture de sécurité est la seule infrastructure de données financières qu'ils vendent. Chaque autre application grand public que vous avez déjà connectée à votre banque (Wealthsimple, Venmo, Robinhood) repose sur les mêmes rails. Quand vous révoquez une connexion dans Mozaic, le jeton sous-jacent Plaid ou SnapTrade est révoqué à la source : l'institution cesse immédiatement de lui faire confiance. Plaid et SnapTrade ne sont que deux des services externes sur lesquels Mozaic s'appuie; la liste complète se trouve sur notre page pile technologique.

02 · Permissions

Lecture seule par conception, et pas seulement par promesse

Les jetons que Mozaic détient n'autorisent que des lectures. Ils ne peuvent pas initier un virement, passer un ordre, modifier une position ni changer un bénéficiaire. Ce n'est pas une règle interne qui pourrait être assouplie dans une future version ; c'est la portée des permissions que nos intégrations demandent au moment où vous connectez un compte, et c'est ce que l'écran d'autorisation de votre banque vous confirme en clair avant d'émettre le jeton.

La raison est simple : un modèle de sécurité ne vaut pas mieux que son pire échec possible. Si Mozaic était un jour compromis (par un attaquant externe, par un employé malveillant, par un bug), le pire scénario serait que quelqu'un puisse voir les mêmes chiffres que vous voyez. Il ne pourrait pas déplacer de fonds, pas passer d'ordres, pas changer votre adresse chez la banque. La lecture seule réduit le rayon d'impact de tout incident à de l'« exposition », pas à une « perte ».

03 · Juridiction

Résidence des données au Canada, conforme PIPEDA et Loi 25 du Québec

Vos données vivent dans la région northamerica-northeast1 de Google Cloud, le centre de données de Montréal. Rien des informations de votre compte n'est répliqué vers des régions américaines ou européennes. Nous avons choisi la résidence canadienne parce qu'elle s'aligne sur les deux régimes de protection des renseignements personnels qui s'appliquent à la plupart de nos utilisateurs : PIPEDA au fédéral, et la Loi 25 du Québec pour les résidents québécois.

PIPEDA et Loi 25 sont nommées ici par leur nom légal car la terminologie ne se traduit pas. Elles vous accordent des droits précis : le droit de savoir ce que nous détenons, le droit de le corriger, le droit de retirer votre consentement et le droit à l'effacement. Les fonctions qui mettent en œuvre ces droits existent dans l'application, pas seulement dans la politique de confidentialité : l'export et la suppression des données sont en libre-service depuis Paramètres, pas une file d'attente de tickets.

04 · Suppression

Fenêtre de grâce de 30 jours, ou suppression immédiate, synchrone

Lorsque vous supprimez votre compte dans Paramètres, vous choisissez entre deux chemins. Le défaut est une fenêtre de grâce de 30 jours : vos données sont verrouillées en synchronisation et en accès, mais conservées récupérables ; ainsi, si vous changez d'avis dans le mois, vous pouvez annuler la suppression et reprendre où vous en étiez. Après 30 jours, la suppression s'exécute et vos données sont effacées de manière permanente.

Le second chemin est la suppression immédiate : même destination, sans fenêtre de grâce : l'effacement s'exécute de façon synchrone dans la requête, et vos données disparaissent avant que la réponse ne revienne. Dans les deux cas, vous pouvez exporter tout votre historique en CSV au préalable, et dans les deux cas il n'y a pas de faille de rétention : les sauvegardes tournent sur un calendrier aligné sur les fenêtres de suppression, donc une sauvegarde restaurée ne peut pas servir à ressusciter un compte supprimé au-delà de sa fenêtre.

05 · Chiffrement

Chiffrement en transit et au repos

Chaque octet qui circule entre votre navigateur et Mozaic est transporté via HTTPS avec TLS 1.2 ou supérieur. Les requêtes HTTP sont redirigées vers HTTPS au bord du réseau, et un en-tête HSTS d'un an indique aux navigateurs de refuser toute tentative de rétrogradation pendant douze mois. Un réseau hostile ne peut donc pas démonter le TLS de la connexion.

Au repos, les champs sensibles, les jetons d'accès Plaid, les secrets utilisateur SnapTrade, les parties les plus révélatrices de votre historique de transactions (noms de commerçants, descriptions et lieux), les noms et institutions de vos comptes, ainsi que le détail de vos placements (les noms des titres que vous détenez), sont chiffrés au niveau applicatif sous une clé propre à chaque utilisateur : les données de chaque compte sont chiffrées avec leur propre clé (Fernet : AES-128-CBC plus une étiquette d'authentification HMAC-SHA256), et non avec une clé partagée unique. Chaque clé d'utilisateur est elle-même enveloppée par une clé maîtresse conservée dans Google Cloud KMS, qui ne quitte jamais le coffre de clés. Déchiffrer un champ exige donc un appel KMS authentifié dont nous accordons l'accès via IAM et que nous pouvons révoquer de façon centralisée. Le stockage Cloud SQL sous-jacent est lui-même chiffré indépendamment par Google. Effet pratique : à elle seule, une copie de la base est inerte : elle ne contient que du texte chiffré et des clés enveloppées, jamais la clé maîtresse. Nous gardons volontairement les détails plus fins de gestion des clés hors de la copie publique.

06 · Usage des données

Nous ne vendons pas vos données

Ni à des annonceurs, ni à des courtiers de données, ni à des cabinets de recherche, à personne. Mozaic ne fait pas de régie publicitaire, ne vend pas de jeux de données agrégés ou anonymisés, et ne participe pas à l'industrie de la revente de données financières grand public. La raison pour laquelle nous pouvons nous y engager durablement plutôt qu'aspirativement, c'est le modèle économique : un service par abonnement est payé par les utilisateurs ; dès qu'un utilisateur devient un produit plutôt qu'un client, le modèle casse.

La même logique vaut à l'interne. L'accès en production est limité à une petite équipe fondatrice, tous les accès sont journalisés, et les jetons d'intégration sensibles décrits plus haut sont chiffrés avant écriture, donc même les lectures légitimes en base lors d'un incident renvoient du texte chiffré plutôt que des identifiants utilisables.

07 · Connexion

Connexion via Identity Platform, avec MFA et appareils de confiance en option

L'authentification est assurée par Google Cloud Identity Platform (le produit géré derrière Firebase Authentication). Lorsque vous vous connectez, votre navigateur reçoit un jeton d'identité de courte durée (RS256, signé par Google) que le backend Mozaic vérifie auprès des clés publiques de Google à chaque requête. La durée de session, le rafraîchissement et la révocation sont gérés par Identity Platform, ce qui veut dire qu'une déconnexion sur un appareil se propage proprement, et qu'une session compromise peut être tuée de manière centralisée.

Vous pouvez activer l'authentification à deux facteurs par TOTP depuis Paramètres avec n'importe quelle application authentificateur : Google Authenticator, Authy, 1Password, l'application Mots de passe d'iOS. Les jetons d'appareils de confiance vous permettent de sauter le second facteur sur des appareils déjà utilisés, sans affaiblir la protection lors d'une connexion depuis une machine inconnue. La récupération de compte et la vérification du courriel passent par l'infrastructure de Google, c'est-à-dire la même chaîne sur laquelle reposent déjà des milliards de personnes pour leur messagerie principale.

La version courte.

Cinq questions qui reviennent le plus souvent. Les réponses correspondent mot pour mot au schéma FAQPage ci-dessus : ce que vous lisez ici, c'est ce que Google lit.

Non. Nos connexions à vos banques et à vos courtiers sont en lecture seule : nous recevons des soldes et des transactions, mais nous n'avons aucune permission pour transférer des fonds, passer des ordres ou modifier des positions. Même si nos systèmes étaient compromis, un attaquant ne pourrait pas faire sortir un cent de vos comptes via Mozaic. Cette permission n'existe tout simplement pas sur les jetons d'intégration que nous détenons.
La connexion est gérée par Google Identity Platform, donc la récupération de compte et la révocation des sessions utilisent l'infrastructure de Google. Vous pouvez activer en option l'authentification à deux facteurs par mot de passe à usage unique (TOTP) dans Paramètres. Comme chaque connexion bancaire ou de courtage est en lecture seule, même le pire des accès à votre compte ne peut pas entraîner de mouvement de fonds : l'attaquant pourrait voir, sans agir.
Vos données vivent dans la région northamerica-northeast1 de Google Cloud (Montréal). Mozaic est conforme à la PIPEDA fédérale et à la Loi 25 du Québec. Les champs sensibles comme les jetons d'accès Plaid et SnapTrade, ainsi que les détails sensibles des transactions tels que les noms de commerçants, les descriptions et les lieux, sont chiffrés au niveau applicatif sous une clé propre à chaque utilisateur dont la clé maîtresse est conservée dans Google Cloud KMS (de sorte qu'à elle seule une copie de la base ne peut être déchiffrée sans un appel KMS authentifié contrôlé via IAM), et le stockage de la base est lui-même chiffré par Google Cloud SQL.
L'accès en production est limité à une petite équipe fondatrice et est journalisé. Les jetons d'intégration sensibles sont chiffrés avant d'être écrits, donc même une lecture directe de la base renvoie du texte chiffré plutôt que des identifiants utilisables. Nous ne vendons, ne louons et ne partageons pas vos données avec des annonceurs ou des courtiers de données. Notre modèle économique est l'abonnement, ce qui rend cet engagement durable plutôt qu'aspirationnel.
Nos engagements sur les connexions en lecture seule, l'absence de revente de données et la résidence canadienne sont inscrits dans l'architecture du produit, pas seulement dans la politique de confidentialité, ce qui veut dire qu'ils survivraient à un rachat comme survit le code source. En cas de changement matériel de propriété ou de conditions, nous vous préviendrions par courriel à l'avance et vous laisserions exporter vos données et supprimer votre compte avant toute application des nouvelles conditions.

Prêt quand vous l'êtes.

Voir les tarifs