Accord de sous-traitance (DPA)

Le présent accord (l’« Accord ») est conclu en application de l’article 28, paragraphe 3, du RGPD entre :

• le Client, professionnel titulaire d’un abonnement Replyxia, agissant en qualité de responsable de traitement ; et
• RSOFTWAIRE, éditrice du service Replyxia, agissant en qualité de sous-traitant (le « Prestataire »).

Il fait partie intégrante du contrat formé par les CGU et les CGV, et prévaut sur ceux-ci pour tout ce qui concerne le traitement des données à caractère personnel des internautes tiers. Il est réputé accepté lors de la création d’un compte. Une version signée peut être demandée à cadjeenail@gmail.com.

Périmètre. L’Accord ne couvre que les données traitées pour le compte du Client, c’est-à-dire les commentaires publics, messages privés et avis des internautes, ainsi que les métadonnées associées. Les données relatives au compte du Client et à sa facturation relèvent d’un traitement dont le Prestataire est lui-même responsable, décrit dans la politique de confidentialité.

1. Objet, nature et finalité du traitement

Le Prestataire traite les données à caractère personnel aux seules fins de fournir le service Replyxia au Client, à savoir :

• collecter auprès des API de Meta et de Google les commentaires, messages privés et avis adressés aux comptes du Client ;
• les enregistrer, les organiser, les conserver et les restituer dans une interface unique ;
• les analyser au moyen de modèles de langage afin de les classer et de proposer une réponse ;
• publier, sur instruction du Client, la réponse retenue sur la plateforme d’origine ;
• produire des statistiques d’activité à l’usage exclusif du Client.

2. Durée

L’Accord prend effet à la création du compte et demeure en vigueur pendant toute la durée du contrat, puis jusqu’à l’achèvement des opérations prévues à l’article 9 (restitution et effacement).

3. Catégories de personnes concernées et de données

Aucune catégorie particulière de données (art. 9 RGPD) ni donnée relative à des condamnations pénales (art. 10 RGPD) n’est demandée par le service. Le contenu libre d’un commentaire ou d’un message peut néanmoins en contenir de façon fortuite. Le Client s’interdit d’utiliser le service pour collecter délibérément de telles données.

4. Obligations du Prestataire

Le Prestataire s’engage à :

• a) Instructions documentées — ne traiter les données que sur instruction documentée du Client. Les présentes, le contrat et les actions réalisées par le Client dans l’interface (activation d’une connexion, génération d’une suggestion, envoi d’une réponse, paramétrage de l’auto-réponse, choix du fournisseur d’IA) constituent ces instructions. Le Prestataire informe le Client s’il estime qu’une instruction constitue une violation du RGPD.
• b) Confidentialité — veiller à ce que les personnes autorisées à traiter les données soient soumises à une obligation contractuelle ou légale de confidentialité, et limiter les accès au strict nécessaire.
• c) Sécurité — mettre en œuvre les mesures techniques et organisationnelles décrites à l’annexe, conformément à l’article 32 du RGPD.
• d) Sous-traitance ultérieure — respecter les conditions de l’article 5.
• e) Assistance aux droits des personnes — assister le Client, par des mesures techniques et organisationnelles appropriées, pour répondre aux demandes d’exercice de droits. Toute demande reçue directement par le Prestataire est transmise au Client sous 5 jours ouvrés, sans y répondre au fond, sauf si le Client l’a expressément mandaté pour le faire.
• f) Assistance à la conformité — assister le Client dans le respect de ses obligations au titre des articles 32 à 36 du RGPD (sécurité, notification de violation, analyse d’impact, consultation préalable), compte tenu de la nature du traitement et des informations à sa disposition.
• g) Notification des violations — notifier au Client toute violation de données à caractère personnel sans délai injustifié et au plus tard 48 heures après en avoir pris connaissance, en fournissant la nature de la violation, les catégories et le nombre approximatif de personnes et d’enregistrements concernés, les conséquences probables et les mesures prises. Le Prestataire ne notifie pas l’autorité de contrôle à la place du Client.
• h) Registre — tenir le registre des catégories d’activités de traitement effectuées pour le compte du Client (art. 30-2 RGPD) et le mettre à disposition sur demande.
• i) Mise à disposition et audit — mettre à la disposition du Client toute information nécessaire pour démontrer le respect de l’article 28, et permettre la réalisation d’audits dans les conditions de l’article 7.
• j) Absence de réutilisation — ne pas utiliser les données pour ses propres finalités, ne pas les revendre, ne pas les croiser entre organisations clientes, et ne pas les utiliser pour entraîner de modèle d’intelligence artificielle.

5. Sous-traitants ultérieurs

Le Client donne au Prestataire une autorisation générale de recourir aux sous-traitants ultérieurs énumérés ci-après. Le Prestataire leur impose par contrat des obligations de protection des données équivalentes à celles du présent Accord et demeure pleinement responsable de leur exécution devant le Client.

Meta Platforms et Google ne sont pas des sous-traitants ultérieurs du Prestataire : ce sont les plateformes d’origine des contenus, avec lesquelles le Client entretient une relation directe et qui agissent pour leur propre compte comme responsables de traitement.

Changements. Le Prestataire informe le Client de tout projet d’ajout ou de remplacement d’un sous-traitant ultérieur au moins 30 jours avant sa mise en œuvre. Le Client peut s’y opposer par écrit et de façon motivée dans ce délai ; à défaut de solution alternative, il peut résilier le contrat sans frais ni pénalité, avec remboursement au prorata des sommes payées d’avance.

6. Transferts hors de l’Union européenne

Comme le montre le tableau ci-dessus, la fourniture du service implique un transfert de données vers les États-Unis, notamment pour l’exécution des modèles de langage. Ces transferts sont encadrés par les clauses contractuelles types adoptées par la décision d’exécution (UE) 2021/914 (module 3, sous-traitant vers sous-traitant ultérieur) et, le cas échéant, par la certification Data Privacy Framework du destinataire. Des mesures complémentaires sont appliquées : chiffrement en transit, minimisation du contenu transmis, absence d’identifiant de compte du Client dans les requêtes adressées aux fournisseurs d’IA.

Le Client, en tant que responsable de traitement, doit mentionner ces transferts dans sa propre information aux personnes concernées. Le détail des mécanismes et des dates de conclusion est fourni sur demande : [[À_COMPLÉTER: pour chaque sous-traitant ultérieur hors UE, CCT signées et / ou certification DPF en vigueur]].

7. Audit

Le Client peut, à ses frais, au maximum une fois par période de douze mois et moyennant un préavis écrit de 30 jours, auditer le respect du présent Accord, soit par un questionnaire documentaire, soit par un tiers indépendant soumis à confidentialité et n’étant pas un concurrent du Prestataire. L’audit ne doit pas porter atteinte à la sécurité ni à la confidentialité des données des autres clients. Une fréquence supérieure est admise à la suite d’une violation de données avérée ou d’une injonction de l’autorité de contrôle.

8. Obligations du Client

Le Client, responsable de traitement, garantit :

• disposer d’une base légale valable pour les traitements qu’il confie au Prestataire ;
• informer les personnes concernées conformément aux articles 13 et 14 du RGPD, y compris sur le recours à l’intelligence artificielle, sur les transferts hors de l’Union et sur l’identité du sous-traitant ;
• répondre aux demandes d’exercice de droits qui le concernent et transmettre au Prestataire les instructions nécessaires à leur exécution technique ;
• ne saisir dans l’interface (fiche d’établissement, instructions IA, réponses) que des données nécessaires, et en aucun cas des données sensibles ;
• paramétrer l’auto-réponse en connaissance de cause et contrôler les réponses publiées ;
• gérer les accès de ses propres utilisateurs et retirer sans délai les habilitations devenues inutiles.

9. Sort des données en fin de contrat

Au terme du contrat, quelle qu’en soit la cause :

• Période de récupération — pendant 30 jours à compter de la date d’effet de la résiliation, le Client peut demander la restitution de ses données dans un format structuré et couramment utilisé (JSON ou CSV).
• Effacement — à l’expiration de ce délai, ou immédiatement sur demande écrite du Client, le Prestataire supprime l’ensemble des données couvertes par le présent Accord ainsi que les copies existantes, et efface les jetons d’accès aux plateformes.
• Exceptions — sont conservés, pour la seule durée légale applicable, les éléments dont la conservation est imposée par le droit de l’Union ou d’un État membre (notamment les pièces comptables) ainsi que les journaux d’audit techniques, dans les durées annoncées dans la politique de confidentialité.
• Sauvegardes — les données présentes dans les sauvegardes chiffrées sont éliminées selon le cycle de rotation de ces sauvegardes, sans pouvoir être restaurées de façon sélective. Ce cycle est celui appliqué par l’hébergeur de la base de données : [[À_COMPLÉTER: durée de rétention des sauvegardes Supabase du plan souscrit]].
• Attestation — une attestation écrite d’effacement est délivrée sur demande du Client.

10. Responsabilité

Chaque partie supporte les conséquences des manquements qui lui sont imputables, dans les conditions de l’article 82 du RGPD. Le régime de responsabilité de l’article 10 des CGU s’applique, étant rappelé que les plafonds qu’il prévoit ne sont opposables qu’aux Clients professionnels et qu’aucune limitation n’est opposable à un Client consommateur. Ces stipulations ne peuvent en aucun cas faire obstacle aux droits des personnes concernées, à leur droit à réparation, ni aux sanctions administratives prononcées par une autorité de contrôle.

Annexe — Mesures techniques et organisationnelles de sécurité

Les mesures ci-dessous sont celles effectivement mises en œuvre dans le service à la date de mise à jour du présent Accord. Elles peuvent évoluer, sans que le niveau de sécurité global puisse être diminué.

A.1 Chiffrement

• Chiffrement en transit par TLS sur l’ensemble des échanges, avec HSTS d’une durée de deux ans sur le domaine de production.
• Chiffrement au repos des secrets applicatifs en AES-256-GCM (vecteur d’initialisation aléatoire de 96 bits, étiquette d’authentification) : jetons de Page Meta, jeton utilisateur Meta, jeton de rafraîchissement Google, clés d’API d’IA propres à l’organisation, cookie OAuth intermédiaire.
• Chiffrement au repos de la base de données assuré par l’hébergeur.
• Les mots de passe ne sont jamais stockés en clair : Supabase Auth n’en conserve qu’une empreinte.

A.2 Contrôle d’accès et authentification

• Authentification multifacteur TOTP obligatoire : l’accès aux données est refusé tant que le second facteur n’est pas validé, contrôle appliqué à trois niveaux (routage, résolution de l’identité côté serveur, politique de sécurité en base).
• Gestion des habilitations par rôle (owner, admin, staff) appliquée dans les routes, les actions serveur et les politiques de base de données.
• Expiration de session : 12 heures d’inactivité, 7 jours en durée absolue, au moyen d’un cookie d’activité signé par HMAC-SHA256 et vérifié côté serveur à chaque requête protégée.
• Ré-authentification de moins de 5 minutes exigée pour les opérations sensibles (connexion d’une Page, invitation d’un membre, modification des clés d’API d’IA).

A.3 Cloisonnement des données entre clients

• Chaque table métier porte un identifiant d’organisation ; les politiques de sécurité au niveau des lignes (RLS) restreignent la lecture aux membres de l’organisation, et un filtrage applicatif explicite est appliqué en complément.
• Aucune politique d’écriture n’est ouverte aux rôles applicatifs : toute mutation passe par le serveur.
• Les colonnes contenant des jetons sont explicitement révoquées pour le rôle authentifié et ne peuvent pas être lues par un client.
• Un déclencheur en base rejette toute tentative de rattacher une même Page ou un même compte Instagram à deux organisations différentes.

A.4 Sécurité de la surface HTTP

• Politique de sécurité de contenu (CSP) à nonce unique par requête, avec strict-dynamic, frame-ancestors 'none', object-src 'none', base-uri 'self' et form-action 'self'.
• En-têtes X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Referrer-Policy, Permissions-Policy ; masquage de la signature du serveur.
• Contrôle de l’origine de toute mutation, jeton anti-CSRF de 32 octets en cookie HttpOnly pour les parcours OAuth.
• Restriction des méthodes HTTP et limitation de la taille des corps de requête, appliquée avant lecture.

A.5 Intégrité des flux entrants

• Vérification de la signature HMAC-SHA256 des webhooks Meta en temps constant, validation de la structure du message et rejet des charges utiles hors limites.
• Idempotence des traitements : empreinte SHA-256 du corps brut de chaque webhook, contraintes d’unicité sur les identifiants externes des commentaires et des messages, verrou d’envoi unique par commentaire.

A.6 Limitation de débit et disponibilité

• 16 politiques de limitation de débit nommées, avec pseudonymisation par HMAC des identifiants envoyés au service Redis : ni l’adresse IP ni les identifiants internes n’en sortent en clair.
• Comportement fail-closed en production : si le service de limitation est indisponible, la requête est refusée plutôt que laissée passer.
• File d’attente durable des webhooks avec reprise sur erreur et mise en file d’attente morte au-delà de 10 tentatives.

A.7 Maîtrise des traitements d’IA

• Le contenu soumis au modèle est explicitement déclaré donnée non fiable dans l’invite de classement.
• Détection de neuf motifs de tentative de manipulation de consigne : leur présence bloque tout envoi automatique de réponse.
• L’auto-réponse est désactivée par défaut ; lorsqu’elle est activée, elle est bornée par un seuil de confiance, une liste de catégories autorisées, un plafond quotidien, et un interrupteur d’environnement supplémentaire est requis pour tout envoi entièrement automatique.

A.8 Traçabilité

• Journalisation de 40 types d’actions sensibles, avec auteur, cible, horodatage et adresse IP. Les journaux ne contiennent jamais de jeton, de clé ni de secret.
• Lecture des journaux réservée aux rôles administrateur et plus.

A.9 Développement et chaîne d’approvisionnement logicielle

• Validation systématique des entrées par schéma typé sur toutes les routes et actions serveur.
• Intégration continue bloquante : tests, vérification de types, analyse statique, contrôle de format, construction, et audit des dépendances de production échouant au niveau de sévérité « élevé ».
• Actions d’intégration continue épinglées par empreinte, mises à jour de dépendances automatisées.
• Aucun secret en dur dans le code source.

A.10 Limites connues — déclaration de transparence

Conformément au principe de loyauté, les limites suivantes sont portées à la connaissance du Client :

• Aucune purge automatisée des données n’est actuellement programmée : les durées de conservation annoncées dans la politique de confidentialité sont appliquées par opération administrative. Une demande d’effacement est en revanche exécutée dans les délais annoncés.
• Aucune fonctionnalité d’export en libre-service n’est disponible : la restitution prévue à l’article 9 s’effectue sur demande écrite.
• La clé de chiffrement des jetons sert également au calcul de la signature des cookies de session, et aucun mécanisme de rotation de clé n’est en place à ce jour.
• La planification des tâches périodiques est partielle : la synchronisation de secours et le renouvellement des jetons d’accès dépendent d’un déclencheur externe. Cette limite affecte la disponibilité du service, non la confidentialité des données.
• Calendrier de remédiation : [[À_COMPLÉTER: échéances de correction des limites ci-dessus, ou suppression des lignes résolues]].

A.11 Contact sécurité

Toute vulnérabilité ou incident peut être signalé à cadjeenail@gmail.com.