Sécurité et sous-traitants

Cette page décrit, de façon factuelle, l'hébergement, les sous-traitants nommés, le chiffrement, l'authentification et la gestion des incidents d'Agreely. Elle est écrite pour être jointe telle quelle à une analyse de risque fournisseur, pas pour convaincre.

Dernière mise à jour : 24 octobre 2026

Version : 1.2

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

La production d'Agreely est hébergée au Québec, chez OVH, à Beauharnois, sur deux serveurs : le premier fait tourner l'application et sa base de données PostgreSQL, le second les tâches de fond. Les sauvegardes de la base de données sont chiffrées et conservées dans deux dépôts, un sur chacun de ces serveurs, tous deux à Beauharnois.

Pour nos clients, confier à Agreely la conservation de renseignements personnels au Québec est une communication nécessaire à l'exécution d'un mandat ou d'un contrat de service (P-39.1, art. 18.3 ; A-2.1, art. 67.2), et non une communication à l'extérieur du Québec (P-39.1, art. 17 ; A-2.1, art. 70.1). Les courriels qu'Agreely envoie pour ses clients passent toutefois par le relais Zoho Mail, aux États-Unis : ce volet demeure une communication à l'extérieur du Québec, qui appelle l'évaluation des facteurs relatifs à la vie privée de chaque client. La catégorisation des témoins des bannières fait aussi appel à Anthropic, aux États-Unis, à partir de métadonnées conçues pour ne contenir aucun renseignement personnel. Voir notre politique de confidentialité pour la portée complète.

Nous administrons nous-mêmes ces deux serveurs : le système d'exploitation, le pare-feu et les correctifs relèvent d'Agreely. OVH fournit les serveurs, le centre de données et le réseau.

La page d'état publique, status.agreely.ca, est elle aussi hébergée chez OVH, à Beauharnois : elle ne fait que vérifier la disponibilité de nos services et ne contient aucune donnée de client.

3. Sous-traitants nommés

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

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, aucun renseignement personnel en clair. 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 est chiffré par TLS : le serveur PostgreSQL refuse toute connexion réseau en clair. Son certificat n'est toutefois pas vérifié par une autorité de certification ; entre nos deux serveurs, cette connexion passe aussi par un tunnel WireGuard chiffré, qui authentifie chaque machine par sa clé.

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.

Ce qu'Agreely contrôle en amont

Depuis le 22 octobre 2026, l'application d'Agreely calcule, au moment où elle consigne un élément, un code d'authentification au moyen d'une clé détenue par Agreely. Avant d'ancrer une racine sur la chaîne, Agreely vérifie que chaque élément que cette racine regroupe est couvert par un code valide. Un élément modifié ou ajouté directement dans la base de données sans cette clé n'est pas ancré, et l'équipe d'exploitation d'Agreely en est alertée. La clé est conservée sur les serveurs d'Agreely : ce contrôle est une défense en profondeur contre un accès à la seule base de données, pas contre une personne qui contrôle ces serveurs ou le code de l'application, et personne hors d'Agreely ne peut vérifier ce code. Il ne porte ni sur un événement que l'application n'a jamais consigné, ni sur ce qui est fait au moyen de l'application ou de son API avec un accès valide, même usurpé, ni sur l'étiquette qui rattache une racine à une organisation sur la chaîne, ni sur les racines ancrées au bloc 52929948 de Base ou avant (le 22 octobre 2026) et les éléments qu'elles regroupent.

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

Des questions sur cette page, ou un problème de sécurité à signaler ?

David Tucker, responsable de la protection des renseignements personnels
Ophelios Studio
david.tucker@ophelios.com