Sous-traitants — WeInspect

Version v1.2 — 2026-06-21 Mise à jour à chaque ajout, retrait ou changement de fournisseur.

Loi 25 (RLRQ c P-39.1) art. 18 et 18.1 imposent l'identification claire des sous-traitants traitant des renseignements personnels pour notre compte. La présente liste est tenue à jour. Tout changement substantiel (ajout fournisseur, expansion de scope) déclenche une notification utilisateurs et, le cas échéant, une nouvelle demande de consentement.

En clair

On a 9 sous-traitants. Pas un de plus. Pas un de moins.

🇨🇦 Canada : 2  (Supabase, Stripe Canada)
🇺🇸 États-Unis : 5 (Anthropic, OpenAI, Resend, Netlify, Sentry)
🇪🇺 Union européenne : 1 (Plausible)
🌐 À confirmer au provisionnement : 1 (Microsoft Azure AI Translator — région demandée : Canada `canadacentral` ; la résidence du traitement n'est pas garantie par l'endpoint global, au pire = États-Unis, à parité avec nos sous-traitants IA américains existants)

Huit d'entre eux ont un Data Processing Agreement (DPA) signé avec nous ; celui de Microsoft (Azure AI Translator) reste à signer par le DPO.
Chacun a un usage précis et limité.
Aucun "data broker" intermédiaire.
Aucun routage caché.
Aucune monétisation indirecte de vos données.

Tableau détaillé

Détails complémentaires

Anthropic — Zero Data Retention (ZDR)

ZDR est un tier API enterprise Anthropic qui garantit que les payloads (prompts + réponses) ne sont pas conservés au-delà du temps strict de la génération. Pas de logs côté Anthropic après ~30s. Pas d'utilisation pour entraîner Claude.

OpenAI — aucun paramètre de rétention envoyé

Depuis 2023, OpenAI ne forme plus ses modèles sur les données envoyées via API par défaut.

La rétention, en revanche, n'est pas un réglage que nous poserions requête par requête : aucun paramètre de rétention ne figure dans nos appels. La transcription poste file, model, language et prompt ; la réécriture poste model et input. Rien d'autre. Ce qui s'applique est donc la politique de rétention API d'OpenAI, telle qu'elle est publiée au lien ci-dessus. Une version antérieure de cette liste annonçait ce réglage comme activé de notre côté ; c'était faux, et nous l'écrivons plutôt que de le corriger en silence.

Microsoft Azure AI Translator — résidence et finalité

Azure AI Translator traduit entre le français et l'anglais le contenu complet du champ traduit — constat, lettre au client, introduction de rapport, bloc de contexte ou bloc de la bibliothèque de textes partagés, jamais une sélection. Ce n'est donc pas seulement le texte des constats : la correspondance client passe par le même chemin.

Deux déclencheurs, pas un. Le bouton « Traduire » en est un. L'autre est automatique : quand vous quittez un champ bilingue, si l'IA est activée sur votre compte et que la version dans l'autre langue est vide ou a été produite automatiquement, elle est retraduite sans que vous ayez rien demandé. Le texte part alors chez Microsoft sans clic. Nous l'écrivons parce que c'est le point qui décide si vous savez, ou non, quand votre texte quitte WeInspect. Cette finalité — traitement IA des constats — est identique à celle déjà couverte par le consentement ai_processing existant ; l'ajout d'Azure ne crée pas de nouveau scope de consentement (sous-traitant iso-finalité), il s'ajoute aux sous-traitants IA américains existants (OpenAI, Anthropic) qui reçoivent déjà cette classe de renseignements.

Résidence — posture honnête (Loi 25) : la ressource Azure Translator est provisionnée best-effort en région Canada (canadacentral), mais la résidence du traitement n'est pas garantie par l'endpoint global api.cognitive.microsofttranslator.com. La zone réelle est confirmée au provisionnement et documentée ici à ce moment-là. Au pire, le traitement a lieu aux États-Unis, à parité avec nos sous-traitants IA américains existants — la posture Loi 25 ne se dégrade donc pas par rapport à aujourd'hui.

Stripe — Données bancaires jamais stockées chez nous

WeInspect utilise Stripe Elements (front) + webhooks (backend) → la carte de paiement n'est jamais envoyée à nos serveurs. Stripe la tokenise (pm_xxx). Nous stockons uniquement le customer_id Stripe et le statut paiement.

Observabilité (crash reports / monitoring)

Sentry est utilisé pour les crash reports mobiles. L'intégration mobile désactive l'envoi de PII par défaut et applique un filtrage explicite des courriels, tokens, coordonnées GPS, chemins de fichiers locaux, notes, transcriptions et constats générés avant envoi. Les erreurs côté serveur restent consignées dans les logs Netlify (rétention 30j max).

Tout ajout d'un autre outil d'observabilité ferait l'objet :

• D'une mise à jour de cette liste avec DPA + scrubbing PII documenté
• D'une notification utilisateurs 30 jours avant transit si le changement est matériel
• D'un audit trimestriel des données envoyées

Politique d'évolution

Ajout d'un nouveau sous-traitant

Procédure obligatoire :

1. Évaluation due diligence : sécurité, conformité, juridiction, références
2. Négociation DPA signé avant tout transit de RP
3. Mise à jour de cette page + bump version
4. Notification utilisateurs par courriel + in-app 30 jours avant transit
5. Si nouveau scope nécessitant consentement (ex: nouveau fournisseur IA) : nouvelle demande de consentement explicite ; refus = bascule sans cette feature
6. Mise à jour DPIA si le risque change

Retrait d'un sous-traitant

1. Migration des données vers fournisseur de remplacement
2. Suppression chez l'ex-sous-traitant documentée (clause DPA "fin de contrat = suppression dans 30j")
3. Mise à jour de cette page

Changement de scope

Toute extension du scope d'un sous-traitant existant (ex: un fournisseur passe de mobile-only à web aussi) → traitée comme un ajout (procédure ci-dessus).

Historique des versions

Contact

Question sur un sous-traitant spécifique, demande de copie d'un DPA pour audit interne (clients institutionnels) :

dpo@ouiinspect.ca