Contrat de sous-traitance RGPD (DPA)
Entre les soussignées
LA COLLECTIVITÉ ci-après dénommée « le Responsable de Traitement » (RT)
- Nom de la collectivité : à compléter
- Adresse : à compléter
- SIRET : à compléter
- Représentée par : à compléter, ès qualité de à compléter
- DPO de la collectivité : à compléter (nom, email)
ET
WILDER LABS ci-après dénommée « le Sous-Traitant » (ST)
- Forme juridique : Entrepreneur individuel (micro-entreprise)
- SIRET : 103 011 508 00019
- Adresse : Tercé (86)
- Représentée par : Gillian RICHARD, ès qualité de gérant
- DPO : dpo@wilderlabs.fr
Préambule
Dans le cadre du contrat de service portant sur la solution Sallia (gestion de réservations de salles municipales), le ST traitera des données à caractère personnel pour le compte du RT. Le présent contrat de sous-traitance précise les obligations respectives des parties conformément à l'article 28 du RGPD.
Article 1 — Objet, durée, finalité
1.1 Objet
Définir les conditions dans lesquelles le ST traite, pour le compte du RT, les données à caractère personnel des administrés, agents et associations utilisant la solution Sallia.
1.2 Durée
Le présent contrat prend effet à la date de sa signature et reste en vigueur pendant toute la durée du contrat de service principal, soit par tacite reconduction annuelle. Il prend fin à la résiliation du contrat principal.
1.3 Finalités du traitement
- Gestion administrative des demandes de réservation de salles communales
- Tenue d'états des lieux d'entrée et de sortie
- Génération et envoi de conventions de location
- Gestion des paiements (caution, acompte, solde)
- Communication transactionnelle (confirmations, rappels, factures)
- Tenue de statistiques d'occupation des équipements
- Optionnellement : envoi de newsletters informatives aux opt-in
Article 2 — Catégories de données et de personnes concernées
2.1 Catégories de personnes concernées
- Habitants de la commune
- Membres et bureaux d'associations utilisatrices
- Particuliers extérieurs à la commune
- Professionnels louant un équipement
- Agents municipaux utilisateurs de la plateforme
2.2 Catégories de données traitées
| Catégorie | Données | Sensibilité |
|---|---|---|
| Identité | Nom, prénom, adresse postale | Courante |
| Contact | Email, téléphone | Courante |
| Identité contractuelle | Organisation, fonction (asso) | Courante |
| Données de réservation | Salle, dates, objet, nombre de personnes | Courante |
| Données de paiement | Tokens Stripe (jamais le PAN), montants | Financière (DSP2) |
| Photo EDL | Photos d'état des lieux | Courante (vigilance image tiers) |
| Authentification | Hash bcrypt mot de passe, sessions | Sensible sécurité |
| Connexion | IP, user-agent, horodatage | Technique |
| Données de santé (module « Espace famille » — sous-module santé) | Allergies, PAI (projet d'accueil individualisé), restrictions alimentaires, aptitude à la baignade d'un enfant inscrit en périscolaire/ALSH — uniquement si le sous-module sante_activee est activé pour le tenant du RT | Catégorie particulière — article 9 RGPD |
Par défaut, aucune catégorie particulière au sens de l'article 9 RGPD n'est traitée. Le module « Espace famille » de Sallia comporte un sous-module optionnel de gestion des fiches sanitaires périscolaires/ALSH (allergies, PAI), désactivé par défaut (sante_activee = false) et activable uniquement à la demande explicite et documentée du RT. Dès lors que ce sous-module est activé pour le tenant du RT, l'article 3.10 ci-dessous s'applique de plein droit et prévaut sur la présente mention générale.
Article 3 — Obligations du Sous-Traitant
Le ST s'engage à :
3.1 Traitement
- Ne traiter les données que sur instruction documentée du RT, sauf obligation légale contraire (auquel cas le ST informe le RT préalablement)
- Ne pas utiliser les données à d'autres fins que celles définies à l'article 1.3
3.2 Confidentialité
- Garantir que les personnes autorisées à traiter les données s'engagent à respecter la confidentialité ou sont soumises à une obligation légale
- Limiter l'accès aux données aux seuls personnels habilités selon le principe de la moindre privilège
3.3 Sécurité (article 32 RGPD)
Mettre en œuvre les mesures techniques et organisationnelles appropriées, notamment :
- Chiffrement TLS 1.3 sur tous les flux (HSTS + preload, certificat valide)
- Chiffrement at-rest des tokens sensibles via AES-GCM
- Hash bcrypt des mots de passe (facteur de coût 10 minimum)
- Sessions HttpOnly + Secure + SameSite=lax
- Isolation forte multi-tenant : un schéma PostgreSQL dédié par commune
- Helmet middleware sur tous les endpoints (CSP stricte, anti-clickjacking, etc.)
- Rate-limiting par endpoint pour résister aux attaques brute-force et DoS
- Sauvegardes quotidiennes pg_dump chiffrées, rétention 30 jours
- Tests de restauration trimestriels
- Audit OWASP API Top 10 automatisé
- Test d'intrusion par un cabinet tiers à la demande du Client, à ses frais, sur un périmètre convenu (cf. CPS article 9)
3.4 Sous-traitance ultérieure
Le ST est autorisé à recourir aux sous-traitants suivants (« sous-traitants secondaires ») :
| Sous-traitant | Finalité | Localisation | Statut SCC |
|---|---|---|---|
| Stripe (Stripe Payments Europe Ltd) | Encaissements en ligne | Irlande (UE) | DPA Stripe + SCC |
| Brevo (ex-Sendinblue) | Envoi emails transactionnels | France | DPA Brevo |
| OVH SAS | Hébergement infrastructure (datacenter Strasbourg, région SBG) | France (UE) | RGPD natif |
| OVHcloud | DNS, CDN | France | RGPD natif |
Aucun transfert hors UE. Toute modification du panel de sous-traitants secondaires est notifiée au RT au moins 30 jours avant entrée en vigueur, lui permettant le cas échéant de s'y opposer.
Traitements IA distincts, tous deux inactifs en prod — à ne pas confondre :
- Légendeur IA local EDL (Florence-2, conteneur
sallia-cv) — génération de légendes descriptives sur photos d'état des lieux. Statut : absent de la prod, jamais déployé. - Anthropic (API Claude) — module distinct, assistant conversationnel (sans lien avec l'EDL). Statut : inactif en prod (aucune clé API en configuration). Hébergement USA, SCC article 46 applicables en cas d'activation.
Toute activation de l'un ou l'autre de ces traitements est explicite côté tenant, signalée à l'utilisateur, et notifiée au RT conformément à la clause de préavis ci-dessus.
3.5 Droit des personnes
Le ST aide le RT à répondre aux demandes d'exercice des droits via :
- Endpoint public
/t/:slug/public/rgpd/request— actionsexport(article 15/20) etdelete(article 17/anonymisation) - Token HMAC signé, validité 24h, lien envoyé par email à la personne concernée pour confirmation
3.6 Notification des violations
- Le ST notifie le RT toute violation de données dans un délai maximum de 24 heures après en avoir pris connaissance
- Notification CNIL via téléservice : à la charge du RT, dans les 72 heures, avec assistance documentaire du ST
- Communication aux personnes concernées : à la charge du RT en cas de risque élevé
3.7 Analyse d'impact (DPIA)
Le ST fournit au RT une analyse d'impact relative à la protection des données et l'assiste pour la mettre à jour à chaque évolution significative du traitement.
3.8 Registre des traitements
Le ST tient à jour le registre prévu à l'article 30.2 RGPD et le met à disposition du RT et de la CNIL sur demande.
3.9 Restitution des données
À la fin du contrat de service, le ST :
- Restitue à la collectivité toutes les données à caractère personnel sous format CSV / JSON / SQL dump (au choix)
- Détruit toute copie au-delà d'un délai de conservation contractuel de 30 jours post-restitution
- Fournit une attestation de destruction signée
3.10 Traitement de catégories particulières de données — module santé « Espace famille » (article 9 RGPD)
Cette clause s'applique de plein droit dès que le RT active le sous-module santé du module « Espace famille » (flag sante_activee) pour la gestion des fiches sanitaires périscolaires/ALSH (allergies, PAI, restrictions alimentaires, aptitude à la baignade) d'enfants mineurs inscrits. Elle complète, sans s'y substituer, les articles 3.1 à 3.9 ci-dessus.
3.10.1 Base légale
Le traitement de ces données de santé relève des exceptions de l'article 9(2)(b) et (h) du RGPD (traitement nécessaire aux fins de l'exécution des obligations du RT en matière de sécurité des mineurs accueillis, imposées par la réglementation applicable aux accueils collectifs de mineurs — CASF R227-6 — et à la protection des personnes physiques). Cette base n'est pas le consentement de l'article 9(2)(a) : le dépôt de la fiche sanitaire par le responsable légal de l'enfant est une modalité de collecte, non le fondement juridique du traitement, celui-ci restant la mission d'intérêt public/l'obligation réglementaire portée par le RT.
3.10.2 Minimisation
Seuls sont conservés en base, sous forme structurée : les indicateurs opérationnels de sécurité (allergie sévère oui/non, PAI en vigueur oui/non, date de révision, aptitude à la baignade, restrictions alimentaires) et la référence au dépôt de la fiche. Le détail médical (ordonnances, diagnostics, PAI complet signé) n'est pas saisi en texte libre dans l'application.
3.10.3 Mesures de sécurité renforcées (complètent l'article 3.3)
- Chiffrement applicatif dédié AES-256-GCM des champs structurés de la fiche sanitaire, distinct du chiffrement au repos générique de l'infrastructure
- Journalisation synchrone et fail-closed de tout accès (lecture ou écriture) à la fiche complète : en cas d'échec du journal, l'accès est refusé plutôt qu'autorisé en mode dégradé
- Contrôle d'accès par rôle dédié (admin/directeur ALSH uniquement) pour la fiche complète
- Limitation stricte de l'exposition aux encadrants de terrain : un encadrant affecté à un créneau ne voit jamais le détail médical, uniquement deux indicateurs booléens (« allergie sévère », « PAI en vigueur »)
- Gate d'activation dormant par défaut :
sante_activee = falsejusqu'à activation explicite et documentée par le RT
3.10.4 Analyse d'impact
Le ST met à disposition du RT l'analyse d'impact relative à la protection des données portant sur ce traitement et l'assiste, conformément à l'article 3.7, pour toute mise à jour requise avant ou après activation.
3.10.5 Non-activation par défaut
En l'absence de demande expresse du RT, ce sous-module reste désactivé et aucune donnée de santé n'est collectée ni traitée pour son tenant.
Article 4 — Obligations du Responsable de Traitement
Le RT s'engage à :
- Fournir au ST les données nécessaires au traitement
- Documenter par écrit toute instruction concernant le traitement
- Veiller au respect des obligations RGPD au sein de la collectivité (information des personnes, recueil du consentement le cas échéant, exercice des droits)
- Désigner un DPO (Délégué à la Protection des Données) et en communiquer les coordonnées au ST
Article 5 — Audit et contrôle
Le RT a le droit, après préavis raisonnable (minimum 15 jours ouvrés), d'auditer le ST une fois par an, à ses frais, soit directement soit par un auditeur indépendant. L'audit porte sur le respect des obligations prévues au présent contrat.
Le ST met à disposition du RT toute la documentation nécessaire (registre, DPIA, journaux de sécurité, attestations sous-traitants secondaires).
Article 6 — Responsabilité
Chaque partie est responsable des dommages causés par le traitement lorsqu'elle n'a pas respecté les obligations RGPD spécifiques aux sous-traitants ou les instructions licites du RT (article 82 RGPD).
La responsabilité du ST envers le RT est limitée à deux fois le montant des redevances annuelles versées par le RT au ST au titre du contrat de service, sauf cas de faute lourde ou intentionnelle. Ce plafond spécifique est également celui visé à l'article 10 bis des CPS, dont les présentes constituent l'annexe applicable en matière de responsabilité liée aux données personnelles.
Article 7 — Droit applicable et juridiction
Le présent contrat est régi par le droit français. Tout litige relatif à son interprétation ou son exécution relève des tribunaux du ressort de la cour d'appel de Poitiers, sous réserve des règles d'ordre public.
Article 8 — Signature
Le présent contrat est rédigé en deux exemplaires originaux, un pour chaque partie.
| Le Responsable de Traitement | Le Sous-Traitant | |
|---|---|---|
| Nom | à compléter | Gillian RICHARD |
| Fonction | à compléter | Gérant Wilder Labs |
| Date | à compléter | à compléter |
| Signature | (lu et approuvé, manuscrit) | (lu et approuvé, manuscrit) |
Annexes
- Annexe A : Analyse d'impact relative à la protection des données (DPIA) — sur demande à dpo@sallia.fr
- Annexe B : Registre des traitements — sur demande
- Annexe C : Déclaration d'accessibilité RGAA 4.1.2
- Annexe D : Liste des sous-traitants secondaires (présent contrat, article 3.4)
- Annexe E : Procédure de notification de violation de données — sur demande
- Annexe F (si module santé activé) : Analyse d'impact Espace famille — sur demande