Contrat de sous-traitance RGPD (DPA)

Modèle Wilder Labs v1.1 · publié le 5 novembre 2026 · applicable le 5 décembre 2026 · Conforme aux exigences de l'article 28 du Règlement (UE) 2016/679 (RGPD)

Historique : v1.1 (publiée le 5 novembre 2026, applicable le 5 décembre 2026) ; v1.0 du 18 mai 2026, qui reste applicable jusqu'au 4 décembre 2026 inclus, conformément au préavis de 30 jours de l'article 11 des CPS. Pour une convention déjà signée, la v1.1 fait l'objet d'un avenant (voir la dernière ligne de ce document).

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 : Vienne (86), France
• Représentée par : Guillaume RICHARD, entrepreneur individuel (exploitant)
• DPO : dpo@sallia.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, y compris ses reconductions, et prend fin avec lui, sous réserve de l'article 3.9 (restitution et destruction des données).

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
• Mise à disposition des liens de paiement PayFiP (le paiement est traité par la DGFiP pour la régie du RT) et suivi des encaissements
• 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

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=Strict
• 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 de la base de données au moins quotidiennes, copies hors site chiffrées, conservées au moins 30 jours
• Tests de restauration au moins trimestriels, compte rendu communiqué sur demande
• 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 ») pour traiter les données du RT :

Ne sont pas des sous-traitants secondaires pour les données du RT : Stripe Payments Europe Ltd (Irlande, UE), qui encaisse uniquement l'abonnement du RT au ST et ne reçoit aucune donnée d'habitant ; PayFiP / DGFiP, qui encaisse les paiements des habitants pour la régie du RT, pour le compte de la collectivité ; FranceConnect, opéré par la DINUM, que le RT active au moyen de sa propre demande d'habilitation ; l'IGN Géoplateforme et la Base Adresse Nationale, services publics appelés depuis le navigateur de l'utilisateur.

Aucun transfert de données du RT hors Union européenne dans la configuration livrée. 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.

Services désactivés ou optionnels : aucun des services suivants n'est activé en production, et aucune clé d'accès correspondante n'y est configurée :

• Légendeur IA local EDL (Florence-2) : non déployé.
• Synthèse d'incident (Google Gemini) et assistant conversationnel (Anthropic) : présents dans le code, désactivés, services établis hors Union européenne.
• Signature électronique Yousign (France), en repli de WilderSign.
• Synchronisation Google Agenda et connexion par compte Microsoft pour les agents : fournisseurs établis aux États-Unis, activables par le RT.

Toute activation de l'un de ces services est explicite, demandée par écrit par le RT, signalée à l'utilisateur, et notifiée au RT au moins 30 jours à l'avance conformément à la clause ci-dessus. Pour tout transfert hors Union européenne qui en résulterait, le ST met en place les garanties de l'article 46 du RGPD (clauses contractuelles types) avant activation.

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 — actions export (article 15/20) et delete (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 :

• Remet à la collectivité, dans les 30 jours suivant la fin du contrat et sans frais, une archive complète : dump de la base au format SQL ou JSON, fichiers et documents, dictionnaire des données
• Détruit les données au plus tard 90 jours après la fin du contrat, sauf obligation légale de conservation ou demande écrite de destruction anticipée après confirmation par la collectivité de la bonne réception de l'archive
• Purge les copies de sauvegarde par rotation, dans la limite de leur durée de conservation (au plus 35 jours après la destruction de la base active)
• Fournit, sur demande, 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 = false jusqu'à 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.

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
• 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

Modèle de DPA v1.1 — publié le 5 novembre 2026, applicable le 5 décembre 2026 — Wilder Labs. Toute modification d'une convention signée doit faire l'objet d'un avenant signé des deux parties ; la liste des sous-traitants de l'article 3.4 évolue selon la procédure de notification de 30 jours qui y figure.