# Analyse de risque de ré-identification — MapsNav

**Version 1.0 — 2 août 2026**
Responsable de la protection des renseignements personnels : Michel Cousineau, propriétaire — info@mapsnav.com

Document exigé par le *Règlement sur l'anonymisation des renseignements personnels* (en vigueur le 30 mai 2024), pris en vertu de l'article 23 de la *Loi sur la protection des renseignements personnels dans le secteur privé* (RLRQ c. P-39.1).

Le registre d'anonymisation lui-même est tenu dans la table `anonymisation_registre` de la base `mapsnav-registry`, et référence la version du présent document.

> Ce document est une analyse technique, rédigée par l'exploitant. Il n'a pas été revu par un conseiller juridique.

---

## 1. Pourquoi anonymiser plutôt que détruire

L'article 23 offre deux voies lorsque les fins sont accomplies : détruire, **ou** anonymiser « pour utiliser à des fins sérieuses et légitimes ».

La fin poursuivie ici est la **connaissance halieutique** : savoir où l'on pêche au Québec, dans quels lacs, à quelles profondeurs, pour quelles espèces. C'est ce qui alimente les modèles d'habitat et l'amélioration des cartes bathymétriques — le cœur du produit. Cette fin ne demande **aucune identité** : elle porte sur des lieux et des espèces, jamais sur des personnes.

Détruire ces points effacerait une connaissance d'intérêt réel sans protéger personne davantage qu'une anonymisation correcte. Nous anonymisons donc.

---

## 2. Ce qui rend un jeu de points géographiques ré-identifiant

Le résultat de référence est celui de de Montjoye et coll. (*Unique in the Crowd*, 2013) : quatre points spatio-temporels suffisent à isoler une personne dans un jeu de données de mobilité.

**Ce résultat tient parce qu'on sait que les quatre points appartiennent à la même personne.** C'est l'appartenance commune — la *clé de regroupement* — qui porte le pouvoir d'identification, bien plus que la précision de chaque point pris isolément.

Un spot de pêche isolé, sans lien vers les autres, ne dit presque rien : une bonne fosse est marquée par des dizaines de pêcheurs différents. En revanche, l'**ensemble** des spots d'une même personne dessine un territoire d'usage — son lac d'attache, la fréquence de ses sorties, parfois le voisinage de son chalet — et redevient identifiant.

Il faut aussi noter une différence avec la littérature sur la mobilité : nos points ne sont **pas** des traces de déplacement. Ce sont des lieux **choisis** et marqués volontairement au clic. La position GPS du pêcheur, elle, ne quitte jamais son appareil — vérifié dans le code : un seul appel `watchPosition` dans tout le projet, aucune requête sortante ne la transporte.

---

## 3. Risques identifiés, et traitement retenu

| Élément | Risque | Traitement | Justification |
|---|---|---|---|
| `user_uid` | **Élevé.** Clé de regroupement : permet de reconstituer l'ensemble des spots d'une personne | **Détruit** (mis à NULL) | C'est le vecteur principal. Sans lui, chaque spot devient un point isolé |
| `description` (texte libre, 500 car.) | **Élevé.** Peut nommer des personnes, des chalets, des propriétés — identification directe | **Détruite** | Aucune technique ne rend sûr un texte libre. Seule la destruction le rend sûr |
| `created_at` (à la milliseconde) | **Moyen.** Clé de regroupement implicite : deux spots créés à quelques secondes d'intervalle proviennent visiblement de la même session | **Généralisé au mois** | Conserve la saisonnalité, qui a une valeur halieutique réelle, sans permettre le regroupement |
| `lat`, `lon` (pleine précision) | **Faible une fois isolés.** Un point seul est partagé par de nombreux pêcheurs | **Conservés** | C'est la donnée utile. La dégrader détruirait la finalité sans réduire un risque déjà traité à la source |
| `species`, `lake_id` | **Faible.** Attributs très peu discriminants (5 espèces, ~3 280 lacs) | **Conservés** | Valeur halieutique directe |
| Courriel, identifiant d'authentification, identifiant de paiement | **Identification directe** | **Détruits** | Aucune finalité ne les justifie après la fermeture |
| Journal d'appareils, drapeaux de partage | **Moyen.** Pays, empreintes, horodatages | **Détruits** | Aucune valeur une fois détachés d'un compte |
| Preuve de consentement | **Identification directe** | **Détruite** | Elle prouve qu'on a informé *une personne*. Sans personne, elle ne prouve plus rien et ne fait que conserver un courriel |
| Registre des transactions | Conservé | **Détaché de l'identité** | Obligation comptable et fiscale. La clé interne subsiste, mais elle ne pointe plus vers personne |

---

## 4. Risque résiduel

**Il n'est pas nul, et il faut le dire.**

Un pêcheur qui aurait marqué un très grand nombre de spots sur un lac peu fréquenté pourrait, en théorie, être rapproché de cet ensemble par quelqu'un qui le connaît personnellement — même sans clé de regroupement, si le volume et la localisation sont assez singuliers.

Trois éléments limitent ce risque :

1. **La base est de petite taille et privée.** Elle n'est ni publiée, ni communiquée à des tiers, ni interrogeable de l'extérieur. La ré-identification supposerait d'abord un accès non autorisé.
2. **Les spots ne sont pas ordonnables.** Sans `user_uid` ni horodatage fin, rien dans le schéma ne permet de dire que deux lignes viennent de la même personne.
3. **L'attaquant devrait déjà connaître la personne** et ses habitudes de pêche — auquel cas il détient déjà l'information que l'anonymisation protège.

Le critère de l'article 23 est qu'il soit « en tout temps, raisonnablement prévisible dans les circonstances » que le renseignement ne permette plus d'identifier la personne, directement ou indirectement, **de façon irréversible**. L'irréversibilité est acquise : aucune table ne conserve la correspondance entre l'ancien identifiant et les lignes anonymisées.

---

## 5. Techniques et mesures de sécurité

- **Suppression** des identifiants directs et des clés de regroupement.
- **Généralisation** temporelle (mois) sur `created_at`.
- **Conservation** des attributs analytiques peu discriminants.
- Traitement exécuté par `functions/api/_lib/anonymisation.js` (registre) et par `anonymiserSpotsEchus` dans `Map/server/src/index.ts` (spots), tous deux versionnés dans git.
- Accès aux bases restreint au responsable, par jeton Cloudflare. Chiffrement en transit (TLS).
- Chaque exécution est inscrite au registre avec les quatre mentions réglementaires.

---

## 6. Calendrier

| Moment | Ce qui se passe |
|---|---|
| J+0 | Fermeture immédiate : statut `closed`, sessions coupées, appareils révoqués. Rien n'est encore détruit |
| J+0 à J+30 | Délai de grâce. La personne peut se reconnecter et annuler ; tout est intact |
| J+30 | Anonymisation, irréversible |
| 13 mois | Journal d'appareils purgé de toute façon, indépendamment d'une fermeture |
| Obligations fiscales | Registre des transactions conservé, détaché de toute identité |

Le délai de grâce protège contre la suppression accidentelle et contre celle qu'un tiers déclencherait depuis un écran resté ouvert. La loi n'impose pas de délai ; celui-ci est annoncé dans les conditions d'utilisation, et la personne peut demander de l'écourter.

---

## 7. Ré-évaluation

Le Règlement exige une mise à jour de l'analyse. Elle est refaite :

- à chaque **changement de schéma** touchant `user_fishing_spots` ou `customers` ;
- à chaque **ajout d'un attribut conservé** après anonymisation ;
- si le **volume** de spots anonymisés dépasse 100 000 lignes, la singularité des ensembles augmentant avec la densité ;
- **au moins une fois par an** en l'absence de changement.

Chaque révision incrémente la version de ce document et est inscrite au registre via `analyse_version`.

| Version | Date | Motif |
|---|---|---|
| 1.0 | 2 août 2026 | Analyse initiale |