Sécurité et sous-traitants

1. À propos de cette page

Agreely outille des obligations précises de la Loi 25 pour ses clients ; il ne garantit pas, à lui seul, leur conformité, qui demeure la responsabilité de chaque entreprise. Cette page décrit un registre différent : notre propre posture de sécurité, à titre de fournisseur, pour le service Agreely lui-même.

Elle complète notre politique de confidentialité, qui détaille ce qu'Agreely recueille et pourquoi. Le registre des mesures de sécurité que le produit tient pour chaque client, à l'appui de son propre article 10, est un outil distinct, rempli et déclaré par ce client, pas par nous.

2. Hébergement et résidence des données

La base de données de production principale tourne sur Fly Postgres (application agreely-db, région yyz), à Toronto, en Ontario, colocalisée avec la couche applicative. L'ensemble de notre flotte d'applications de production est hébergé dans cette même région.

Toronto est au Canada, mais à l'extérieur du Québec. Au sens de la Loi 25, confier la conservation de renseignements personnels à une base de données torontoise est donc une communication à l'extérieur du Québec (article 17), qui déclenche, pour chaque client, sa propre évaluation des facteurs relatifs à la vie privée. Voir notre politique de confidentialité pour la portée complète.

La base de données de production est une instance gérée par Fly.io : le système d'exploitation, le pare-feu et les correctifs de cet hôte relèvent de ce fournisseur, pas d'Agreely. Nous n'administrons pas ce serveur nous-mêmes.

La résidence ci-dessus vise les renseignements personnels au repos. Certains sous-traitants, par exemple pour le paiement, traitent des données limitées à l'extérieur du Canada : voir la section suivante.

3. Sous-traitants nommés

Un petit nombre de fournisseurs traitent des renseignements personnels pour notre compte, chacun pour une tâche précise.

Fournisseur	Rôle	Emplacement
Fly.io, Inc.	Hébergement de l'application et de la base de données de production.	Toronto, Ontario, Canada
Stripe	Paiements et facturation des abonnements. Les numéros de carte ne transitent jamais par nos serveurs.	États-Unis
Zoho Mail	Relais des courriels transactionnels : invitations, codes de vérification, confirmations.	À confirmer
Anthropic, PBC	Catégorisation des témoins par modèle de langage, pour les sites qui utilisent le produit Témoins.	États-Unis

La charge transmise à Anthropic est conçue pour ne porter aucun renseignement personnel : noms et attributs de témoins, domaines. Le seul résidu possible est le titre de la page balayée, tronqué à 300 caractères, qui pourrait exceptionnellement contenir le nom d'une personne.

L'ancrage sur la chaîne publique Base n'apparaît pas dans ce tableau : seuls des engagements cryptographiques opaques y sont inscrits, jamais un renseignement personnel. Voir la section 7.

Nous tenons cette liste à jour à mesure que nos fournisseurs changent.

4. Chiffrement en transit et au repos

En transit

Chaque surface publique d'Agreely (le site, l'application, le portail citoyen, le vérificateur) impose le HTTPS. Les appels vers nos sous-traitants nommés se font aussi par des connexions chiffrées.

Le lien entre notre application et sa base de données n'utilise pas le chiffrement TLS à la couche PostgreSQL : la protection y repose sur une adresse réseau privée et non publique, et sur le chiffrement déjà appliqué à la couche applicative pour les champs les plus sensibles (section suivante). C'est une lacune connue, que nous travaillons à combler.

Au repos

Les champs les plus sensibles sont chiffrés à la couche applicative avant d'être écrits, sous une clé propre à chaque client : une clé maîtresse enveloppe une clé de chiffrement générée aléatoirement pour l'entreprise (bibliothèque libsodium, chiffrement authentifié). La compromission de la clé d'un client ne permet jamais de déchiffrer les données d'un autre.

Cette protection couvre notamment les déclarations de consentement et les reçus, les coordonnées conservées de vos clients, le nom du tuteur derrière le consentement d'un mineur, et l'ensemble du traitement des demandes de droits.

Le journal d'accès et le registre des témoins ne sont délibérément pas chiffrés de cette façon : ils sont ancrés par engagement cryptographique (section 7), une protection différente et tout aussi réelle, fondée sur une référence pseudonyme et un sel destructible plutôt que sur un texte chiffré.

5. Authentification et contrôle d'accès

Les mots de passe sont hachés avec l'algorithme Argon2id (bibliothèque libsodium), jamais stockés en clair ni de façon réversible.

Les tentatives de connexion sont limitées, par adresse IP et par compte, avec verrouillage temporaire au-delà d'un seuil : une attaque par force brute ne peut pas essayer un nombre illimité de mots de passe.

L'authentification à deux facteurs est offerte à chaque utilisateur, activable individuellement (application d'authentification, code à usage unique par courriel, ou clé d'accès WebAuthn), et une entreprise peut l'exiger pour ses rôles propriétaire et administrateur.

Les sessions sont conservées côté serveur, dans la base de données, jamais dans un fichier éphémère ; le témoin de session est HttpOnly, SameSite=Lax, et transmis uniquement en HTTPS en production.

L'accès aux paramètres sensibles d'un compte (domaine vérifié, identité did:web, facturation) est limité par rôle : tous les membres d'une entreprise cliente n'ont pas les mêmes droits.

L'accès à l'API se fait par une clé propre à chaque entreprise, comparée par hachage à temps constant, et chaque requête est bornée à l'entreprise qui la présente.

Les citoyens qui gèrent leur propre consentement s'authentifient sans mot de passe, avec une clé d'accès résistante à l'hameçonnage.

6. Isolation entre clients

Chaque enregistrement appartenant à un client porte l'identifiant de ce client, et chaque requête est bornée par cet identifiant en premier paramètre. Il n'existe aucune jointure entre les données de deux clients dans notre code, une règle appliquée par convention et vérifiée par des tests automatisés.

L'application se connecte à la base de données avec un rôle dédié, à privilège minimal : elle n'est jamais l'administratrice de la base. L'administration suit un chemin distinct.

Cette isolation, combinée au chiffrement propre à chaque client (section 4), fait de chaque client une unité proprement séparée des autres.

7. Signature et preuve

Chaque décision de consentement enregistrée par la plateforme est chaînée par hachage et ancrée sur la chaîne publique Base (réseau principal, chain id 8453) : toute altération après coup devient détectable.

Seuls des engagements cryptographiques opaques sont inscrits sur la chaîne. Aucun renseignement personnel, et aucune déclaration lisible, n'y figure jamais.

Le reçu est signé avec la clé DID enregistrée de votre entreprise. Cette clé est hébergée par Agreely : générée et conservée de notre côté, scellée sous la clé de chiffrement propre à votre entreprise. Cela prouve l'attribution, qu'une identité enregistrée précise a signé une déclaration précise, jamais la non-répudiation. Nous le disons clairement plutôt que d'emprunter un mot plus fort que ce que le mécanisme permet.

Cette preuve démontre l'intégrité d'un enregistrement, enregistré et non modifié. Elle ne démontre jamais, à elle seule, la validité juridique de ce qu'il enregistre.

8. Gestion des incidents et signalement d'une vulnérabilité

Si nous constatons, ou si l'on nous signale, un incident de sécurité touchant le service Agreely lui-même, nous l'examinons, le contenons et le corrigeons, puis nous avisons les entreprises clientes concernées et, lorsque la loi l'exige, la Commission d'accès à l'information du Québec (article 3.5).

Ceci est distinct du registre des incidents de confidentialité que le produit tient pour chaque client au sujet de ses propres obligations (article 3.8) : ce registre est rempli et déclaré par le client, pas par nous.

Si vous croyez avoir trouvé une vulnérabilité de sécurité, écrivez-nous à l'adresse ci-dessous. Décrivez le problème et les étapes pour le reproduire, évitez d'accéder à des renseignements au-delà de ce qui démontre le problème, et laissez-nous un délai raisonnable pour intervenir avant toute divulgation publique. Nous accusons réception et travaillons avec vous de bonne foi.

Nous n'offrons pas de programme de récompense rémunéré aujourd'hui.

9. Ce que nous ne détenons pas

Nous ne détenons aucune certification SOC 2, aucune certification ISO 27001, et aucun audit de sécurité indépendant publié aujourd'hui. Ce que nous avons, c'est cette page : un compte rendu factuel, que nous garderons à jour.

Aucune certification Loi 25 n'existe au Québec : aucun organisme n'en délivre, et la Commission d'accès à l'information n'approuve ni n'homologue aucun produit.

10. Nous joindre