# Accord de traitement des données personnelles — Infenix **Modèle prérempli pour comprendre — version 2026-10-05 (5 octobre 2026).** SARL CATHODE — RCS Avignon 985 067 610 — 12 rue des Villas, 84130 Le Pontet, France Contact : contact@cathode-obsolescence.fr > Ce modèle doit être complété et accepté par les représentants habilités des parties. Les modules applicables, les instructions, les localisations des prestataires et le calendrier de suppression doivent être confirmés dans les annexes avant signature. La consultation de cette page ou l’acceptation des CGU ne vaut pas signature du DPA ni autorisation générale des fournisseurs recensés. ## Comment lire ce modèle prérempli Les coordonnées de **CATHODE**, la présence d'agents en France et le prestataire de messagerie **OVH** sont des informations confirmées. Les mécanismes applicatifs cités proviennent du dépôt ; ils ne prouvent pas la configuration de production. **EXEMPLE** signale une situation pédagogique fictive. **Agent Démonstration** n'est pas un partenaire identifié ; les dates, volumes et références ne sont pas convenus. L'adresse **agent@example.invalid** est fictive. **OBSERVÉ DANS LE CODE** décrit un mécanisme ou champ vérifié dans cette version du dépôt au 5 octobre 2026, sans attester son déploiement. **À CONFIRMER** signale une information réelle encore manquante. ### Le cas concret Un agent indépendant en France dispose d'un carnet de vingt contacts professionnels constitué pour son activité. Il souhaite transmettre une partie de ce carnet à CATHODE pour présenter Infenix. CATHODE contrôle la provenance, les bases, l'information et les oppositions avant toute utilisation. Ensuite, l'agent mène des relances selon une campagne définie par CATHODE. - **Apport du carnet — module C** : dans l'exemple, l'agent est responsable de sa collecte et transmission ; CATHODE est responsable de la réutilisation qu'elle décide. Le fait d'apporter un fichier ne suffit pas à fixer ce rôle : vérifier les opérations réelles. - **Relances pour CATHODE — module B** : CATHODE choisit l'objectif, les destinataires et les instructions ; l'agent est sous-traitant pour cette mission. Les clauses relatives au sous-traitant s'appliquent à ce périmètre ; elles ne transforment pas le module C en sous-traitance. - **Client industriel — module A** : si un client utilise Infenix pour gérer ses techniciens et historiques de maintenance, il décide de cette finalité et CATHODE fournit l'outil comme sous-traitant. Ce cas demande sa propre fiche et n'est pas sélectionné dans l'exemple d'agent. Ces qualifications illustrent les critères des [articles 26 et 28 du RGPD](https://www.cnil.fr/fr/reglement-europeen-protection-donnees/chapitre4) ; elles restent à confirmer selon les opérations réellement convenues. La durée de mission d'un agent n'est pas automatiquement celle de l'abonnement SaaS de douze mois. La période d'octobre à décembre utilisée ci-dessous est illustrative. ### Pour préparer le document réel 1. Créer une copie par relation et remplacer les valeurs EXEMPLE par les faits vérifiés. 2. Confirmer les représentants, rôles et instructions ; adapter les modules aux opérations réelles. 3. Valider les mesures, fournisseurs, localisations, preuves et délais marqués À CONFIRMER. 4. Faire accepter le document et ses annexes par les représentants habilités et conserver la preuve. 5. Le modèle pédagogique est public ; conserver les informations et preuves propres à la relation dans le dossier approprié. Le téléchargement ne conclut aucun accord. Les exemples ne décrivent pas des automatismes déjà attestés. ## 1. Parties, périmètre et acceptation Les parties sont SARL CATHODE, 12 rue des Villas, 84130 Le Pontet, France, RCS Avignon 985 067 610, et l’organisation cliente, partenaire ou agent identifiée dans le contrat et l’annexe de traitement. Leurs représentants acceptent par écrit la version datée du présent accord et les annexes complétées. Le présent accord encadre les données personnelles au sens du règlement (UE) 2016/679 (« RGPD ») et de la loi Informatique et Libertés. Il complète le contrat principal et prévaut pour les obligations de protection des données, sans dérogation aux droits impératifs des personnes ni aux pouvoirs des autorités. ## 2. Qualification des rôles et modules Module A — Fourniture du service : l’organisation cliente ou partenaire détermine les finalités des traitements confiés à Infenix ; CATHODE agit comme sous-traitant. L’organisation peut elle-même agir comme sous-traitant de son client, auquel cas elle documente la chaîne et les autorisations nécessaires. Module B — Mission confiée : CATHODE détermine une finalité, par exemple une campagne pour Infenix, et confie à un agent ou partenaire des opérations selon ses instructions. CATHODE est responsable du traitement et cet intervenant est sous-traitant pour ces opérations si les faits correspondent à cette qualification. Module C — Fichier apporté : l’annexe de transmission encadre les opérations entre responsables distincts lorsque l’agent collecte pour ses finalités et CATHODE réutilise les contacts pour les siennes. L’apport d’un fichier ne détermine pas à lui seul les rôles des opérations ultérieures. Un intervenant choisi directement par le client industriel n’est pas automatiquement sous-traitant ultérieur de CATHODE. Les parties identifient son donneur d’ordre et son rôle. Une décision conjointe sur les finalités et moyens essentiels nécessite un accord distinct conforme à l’article 26, dont les grandes lignes sont accessibles aux personnes ; le module C ne le remplace pas. ## 3. Description et durée des traitements L’annexe 1 identifie, pour chaque module, le responsable, le sous-traitant, la mission, les finalités, les opérations, les personnes, les données, les destinataires, la durée et les instructions. Les opérations peuvent comprendre la collecte autorisée, l’enregistrement, l’organisation, la consultation, la mise à jour, le partage habilité, l’export et la suppression. Le traitement ne dure que le temps nécessaire à la mission et à sa clôture. Une conservation légale distincte est identifiée et limitée. Les données sensibles ou pénales sont exclues du périmètre standard et ne sont admises qu’après instruction licite et annexe définissant les garanties adaptées. ## 4. Instructions et obligations du responsable Le responsable détermine la base légale, informe les personnes, vérifie la licéité des données et transmissions, respecte la minimisation et fixe les durées. Il garantit que ses instructions restent dans les droits dont il dispose et documente l’habilitation de ses représentants. Le sous-traitant agit uniquement sur instructions documentées, y compris pour les transferts. Le contrat, les annexes et les opérations effectuées dans le périmètre autorisé constituent les instructions initiales. Toute nouvelle finalité nécessite un accord écrit. Une obligation légale de traitement est communiquée avant exécution, sauf interdiction légale. Le sous-traitant informe immédiatement le responsable lorsqu’une instruction lui paraît contraire au droit applicable. Les parties clarifient l’instruction ; une opération manifestement illicite est suspendue dans le périmètre concerné. ## 5. Confidentialité et absence de réutilisation libre Les personnes autorisées sont soumises à une obligation de confidentialité et accèdent aux seules données nécessaires à leur mission. Les habilitations sont réexaminées et retirées lorsque la mission ou l’accès prend fin. Le sous-traitant ne vend pas les données confiées, ne prospecte pas pour ses propres finalités avec elles et ne les utilise pas pour entraîner un modèle général sur la seule base de cet accord. Une autre finalité ne peut être autorisée par une clause générale : elle exige l’analyse des rôles, de la compatibilité, de la base légale et de l’information des personnes. Les obligations de confidentialité survivent à la mission. ## 6. Mesures techniques et organisationnelles Le sous-traitant met en œuvre les mesures appropriées aux risques conformément à l’article 32 : confidentialité, intégrité, disponibilité, résilience, capacité de restauration et évaluation régulière de leur efficacité. Leur description concrète figure à l’annexe 2, avec les responsabilités du client et des fournisseurs. Cette annexe distingue les mécanismes effectivement vérifiés des mesures restant à confirmer : comptes nominatifs, séparation des organisations, droits partenaires, protection des échanges et fichiers, sauvegardes, accès d’administration, journalisation, correctifs et procédures d’incident. Aucune certification ni fréquence de sauvegarde ne peut être déduite de la simple présence d’un fournisseur dans le code. ## 7. Sous-traitants ultérieurs Le responsable donne une autorisation écrite spécifique ou générale, choisie à l’annexe 3. Seuls les prestataires identifiés et couverts par cette autorisation peuvent traiter les données de la mission. L’inventaire indicatif publié ici ne constitue pas une autorisation. En cas d’autorisation générale, le sous-traitant informe le responsable d’un ajout ou remplacement au moins trente jours avant sa mise en œuvre, afin de permettre une objection motivée liée à la protection des données. Les parties recherchent une solution ; à défaut, le traitement concerné n’est pas confié au prestataire contesté et la prestation affectée peut être arrêtée selon le contrat. Le sous-traitant impose contractuellement les mêmes obligations de protection des données à ses sous-traitants ultérieurs et reste pleinement responsable envers le responsable de leur exécution. Il tient leur liste et les informations nécessaires à disposition. ## 8. Localisations et transferts internationaux L’annexe 3 décrit les lieux de stockage, de traitement, de sauvegarde et les éventuels accès distants depuis un pays tiers. Une région d’hébergement en Europe ne démontre pas à elle seule l’absence de transfert hors de l’Espace économique européen. Un transfert est exécuté uniquement sur instruction documentée et avec le mécanisme légal approprié : décision d’adéquation applicable au destinataire ou garanties conformes au chapitre V. Lorsqu’il est fondé sur l’article 46, l’évaluation du transfert et les mesures supplémentaires nécessaires sont documentées. Les clauses européennes de sous-traitance 2021/915 et les clauses de transfert 2021/914 ont des objets distincts. Le présent texte est un accord spécifique et ne se présente pas comme une reproduction inchangée de ces clauses. Une demande d’une autorité étrangère est examinée selon le droit applicable, limitée et signalée lorsque légalement possible. ## 9. Assistance aux droits des personnes Le sous-traitant transmet sans délai au responsable toute demande relative aux données confiées, au plus tard dans les cinq jours ouvrés de sa réception. Il ne répond pas sur le fond sans instruction, sauf obligation légale. Il aide à identifier les données et à mettre en œuvre accès, rectification, effacement, limitation, opposition et portabilité dans les conditions applicables. Le responsable conduit la réponse dans les délais du RGPD. Les procédures permettent de traiter les copies, exports et données partagées dans la limite des responsabilités de chacun. Une vérification d’identité reste proportionnée ; un justificatif n’est demandé que si nécessaire. ## 10. Violations et signalement Le sous-traitant informe le responsable sans délai injustifié après connaissance d’une violation de données confiées, et au plus tard dans les vingt-quatre heures. Un premier signalement est adressé au contact d’incident de l’annexe 1 avec les informations disponibles ; les compléments sont transmis progressivement sans attendre la fin des investigations. Le signalement indique la nature, les catégories de données et de personnes, les volumes approximatifs si connus, les conséquences possibles, les mesures prises ou proposées et le contact de suivi. Les parties contiennent l’incident, préservent les preuves utiles et documentent les décisions. Le responsable apprécie le risque et procède, lorsque nécessaire, à la notification à l’autorité dans les meilleurs délais et au plus tard soixante-douze heures après en avoir eu connaissance, ainsi qu’à l’information des personnes lorsque requise. Une notification par le sous-traitant en son nom nécessite un mandat explicite. ## 11. Analyse d’impact et coopération Compte tenu du traitement et des informations à sa disposition, le sous-traitant assiste le responsable pour la sécurité, les violations, les analyses d’impact et les consultations préalables prévues aux articles 32 à 36. Il coopère avec l’autorité compétente et fournit les informations nécessaires. La nécessité d’une analyse d’impact ou d’un DPO est appréciée selon les critères légaux et les traitements réels. Les présentes clauses ne valent ni analyse d’impact achevée ni désignation d’un DPO. ## 12. Preuves et audits Le sous-traitant met à disposition les informations nécessaires pour démontrer le respect de l’article 28 et permet les audits, y compris les inspections, par le responsable ou un auditeur mandaté. Les modalités protègent les secrets légitimes et les données d’autres organisations sans empêcher une vérification effective. Un préavis raisonnable et une revue documentaire initiale peuvent être convenus pour les audits ordinaires. Ils ne font pas obstacle à un audit urgent, justifié par un incident ou requis par l’autorité. Les frais et modalités ne peuvent rendre ce droit illusoire. Les écarts sont documentés et suivis jusqu’à leur correction. ## 13. Restitution, effacement et sauvegardes Au terme de la mission, le responsable choisit la restitution ou la suppression des données personnelles confiées. Le sous-traitant exécute l’instruction, détruit les copies existantes et remet une confirmation documentée, sauf conservation imposée par le droit de l’Union ou d’un État membre. L’annexe 2 définit le délai de récupération et le calendrier d’effacement des données actives et sauvegardes. Pendant ce délai, les données sont limitées à la restitution, la sécurité et les obligations légales. La conservation légale précise son fondement, son périmètre et sa durée ; elle n’autorise pas une nouvelle prospection. Une restauration de sauvegarde réapplique les instructions d’effacement déjà reçues. La fin d’accès d’un agent inclut ses copies locales et exports ; une conservation distincte pour une finalité propre doit être licite, annoncée et séparée. Les droits de changement de fournisseur prévus par les CGV et les textes applicables sont préservés. ## 14. Responsabilité et droit applicable Chaque partie assume ses obligations selon son rôle réel. Aucune clause ne supprime les droits des personnes, la responsabilité prévue à l’article 82 ou les pouvoirs de l’autorité. Le sous-traitant qui détermine lui-même des finalités et moyens devient responsable pour le traitement concerné dans les conditions du RGPD. Le présent accord est soumis au droit français, sous réserve des règles impératives. Les contacts, la procédure amiable et les règles de compétence suivent le contrat principal. Les obligations de confidentialité, d’assistance, de restitution et de protection des données survivent autant que nécessaire à la clôture. ## Annexe 1 — Fiche de traitement à compléter Pour chaque mission : identité et adresse des parties ; représentant habilité ; contrat principal ; module A, B ou C ; responsable et sous-traitant ; point de contact de chacun ; dates de début et fin ; instructions ; catégories de destinataires ; lieux autorisés. Contact CATHODE : contact@cathode-obsolescence.fr. Profil industriel : collaborateurs, techniciens et intervenants identifiables ; coordonnées professionnelles, fonctions, habilitations, affectations, historiques de maintenance, notes, échanges et documents contenant des informations personnelles. Finalités : organisation du parc, maintenance, coordination et demandes autorisées. Profil commercial : contacts de clients et prospects, agents et utilisateurs commerciaux ; identité, entreprise, fonction, coordonnées, profils professionnels, notes de qualification, appels, relances et historique de mission. Finalités et canaux de campagne sont précisés. Les objectifs, performances et commissions concernant les agents sont traités dans le rôle et le cadre appropriés. Champs commerciaux observés : prénom, nom, civilité, fonction, persona, e-mail, téléphone, profil LinkedIn et contact principal ; entreprise, SIREN/SIRET, NAF, effectif, adresse, géolocalisation et ciblage ; notes libres, contexte et résultat d’appel, réponses, argumentaire, dates et prochaines relances. L’affectation, les auteurs, statuts et métadonnées d’événements permettent un suivi interne. Ces champs ne prouvent ni une source de collecte licite, ni une information remise, ni une opposition enregistrée ; seules les données nécessaires à la mission sont retenues. Les champs effectivement nécessaires sont listés pour la mission ; les données sensibles sont exclues sauf annexe spécifique. Une liste de rôles générique ne remplace pas l’identification du responsable pour chaque jeu de données. ### Catégories commerciales vérifiées — à sélectionner pour la mission Cette liste est **OBSERVÉE DANS LE CODE** ; elle précise ce que l'outil peut enregistrer. Elle n'autorise pas à remplir tous les champs pour tous les prospects. Les informations d'entreprise peuvent concerner une personne physique, notamment un entrepreneur individuel. | Jeu de données | Champs effectivement présents | Usage et limite pour la fiche réelle | | --------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Contact professionnel | Prénom, nom, civilité, fonction, persona, e-mail, téléphone, LinkedIn, contact principal. | Identifier l'interlocuteur pertinent et le canal justifié ; persona n'est pas une base légale. | | Entreprise | SIREN/SIRET, nom, NAF, effectif, adresse, ville, code postal, géolocalisation, statut, type de cible et profil partenaire. | Qualifier la cible et sa pertinence professionnelle ; ne pas inférer d'autorisation générale de prospection. | | Notes et appels | Contenu libre, contact rattaché, script et version, contexte/résultat, réponses structurées, reformulation et argumentaire. | Préparer et consigner des échanges professionnels ; exclure les notes privées ou sensibles inutiles. Il s'agit de comptes rendus, pas d'une preuve d'enregistrement audio. | | Relances | Date de l'échange, prochaine relance/action, dates de suivi et tentatives de rappel. | Organiser la mission ; une relance sortante ne remet pas à zéro la conservation du prospect. | | Attribution et statut | Utilisateur affecté, créateur, auteur de modification, archivage, historique de statut, acteur, motif, source technique et métadonnées. | Traçabilité commerciale interne ; aucune preuve automatique de source initiale du contact, d'information ou d'opposition. | | Activités de l'agent | Partenaire, entreprise, acteur, type d'événement, points, identifiant source, métadonnées et horodatages. | Suivre la mission et ses activités ; choisir le rôle RGPD et informer l'agent. Journal applicatif ne signifie pas stockage matériellement inaltérable. | | Compte utilisateur | Identité/coordonnées, droits, consentement marketing du compte ; pour les nouvelles inscriptions Infenix, version CGU et date d'acceptation côté serveur. | Preuve limitée au titulaire du compte ; ni signature du DPA, ni consentement d'un contact CRM. Ne pas présumer cette preuve sur les comptes historiques ou d'autres applications. | | Copie exportée | Export individuel vCard : identité, fonction, téléphone, e-mail et LinkedIn. | Fichier local à protéger et à effacer selon les instructions ; aucune restitution CRM globale déduite de cet export. | ### Identification des parties — valeurs à remplacer - Contrat principal : **EXEMPLE** — DEMO-AGENT-2026-01 ; à remplacer par le mandat ou contrat réel. Le DPA ne fixe pas les commissions. - Cocontractant : **EXEMPLE** — Agent Démonstration, agent commercial indépendant, personne fictive. - Forme juridique et immatriculation : **À CONFIRMER** — identité professionnelle, forme et immatriculation réelles ; aucun numéro inventé. - Adresse : **À CONFIRMER** — adresse professionnelle complète de l'agent en France. - Représentant de l'agent : **EXEMPLE** — l'agent signe personnellement s'il exerce en son nom ; pour une société, identifier le représentant habilité. - Contact données et incidents de l'agent : **EXEMPLE** — agent@example.invalid ; remplacer par l'e-mail et le numéro professionnels réels. - Partie CATHODE : **CONFIRMÉ** — SARL CATHODE, RCS Avignon 985 067 610, 12 rue des Villas, 84130 Le Pontet, France. - Représentant de CATHODE : **À CONFIRMER** — nom, qualité et pouvoir de signature ; aucun dirigeant présumé. - Contact données et incidents de CATHODE : **CONFIRMÉ** — contact@cathode-obsolescence.fr ; non présenté comme un DPO désigné. ### Modules retenus dans l'exemple - [ ] Module A : non retenu ici ; cadre d'une organisation confiant ses données à Infenix. - [x] Module B : **EXEMPLE** — qualification et relances sur instructions de CATHODE. - [x] Module C : **EXEMPLE** — transmission d'une partie du carnet constitué pour les finalités propres de l'agent. **Justification — EXEMPLE** : collecte autonome d'origine et mission pour CATHODE sont distinctes. L'agent ne peut pas réutiliser librement les données confiées dans B au motif qu'il a apporté d'autres contacts dans C. **Responsabilité conjointe — EXEMPLE** : non retenue, CATHODE définissant seule la campagne après réception ; à réexaminer si les parties en déterminent ensemble les finalités et moyens essentiels. ### Fiche B-01 — Relances pour CATHODE (exemple fictif) | Champ | Valeur pédagogique | | ----------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Identifiant et module | EXEMPLE : B-01, qualification et relance Infenix. | | Responsable | CATHODE, qui définit la campagne et les instructions dans l'exemple. | | Sous-traitant | EXEMPLE : Agent Démonstration, uniquement pour cette mission ; aucun outil tiers propre autorisé sans validation. | | Finalités et opérations | EXEMPLE : présenter Infenix aux entreprises industrielles ; consulter les contacts confiés, vérifier la pertinence de leur fonction, noter la réponse, organiser une démonstration et transmettre la demande. | | Base légale | EXEMPLE : intérêt légitime à une prospection B2B liée à la fonction, avec information et opposition simple. Analyse et canal à valider ; signer le DPA ne vaut pas consentement. | | Personnes | EXEMPLE : responsables maintenance, techniques et achats d'entreprises industrielles en France. | | Données nécessaires | EXEMPLE : nom, fonction, entreprise, e-mail professionnel, téléphone professionnel si justifié, source, date d'information, opposition, date et résultat du contact, note de suivi factuelle. Pas de données sensibles ou commentaires personnels inutiles. | | Sources | EXEMPLE : contacts CATHODE ou lot C-01 uniquement après validation de sa réutilisation. | | Canaux | EXEMPLE : e-mail B2B pertinent et téléphone professionnel, à vérifier avant usage ; aucune campagne grand public dans cette fiche. | | Destinataires | EXEMPLE : agent de mission et collaborateurs habilités de CATHODE ; aucun accès général aux autres fichiers ou clients. | | Période | EXEMPLE : du 5 octobre au 31 décembre 2026, dates fictives à remplacer. | | Lieux | Agent et CATHODE en France ; hébergement, sauvegardes et accès fournisseurs À CONFIRMER dans l'annexe 3. | | Instructions | EXEMPLE : vérifier les oppositions avant chaque contact, noter la réponse factuelle, arrêter les sollicitations en cas d'opposition et ne pas créer de copie pour sa prospection personnelle. | | Information | EXEMPLE : premier message identifiant CATHODE, la source réelle, la finalité, les droits et le moyen d'opposition ; lien à la politique de confidentialité pour le détail. | | Fin de mission | EXEMPLE : restituer les notes, retirer les accès et supprimer les copies de mission selon l'annexe 2 validée. La base de CATHODE suit son propre calendrier licite. | | Chaîne | EXEMPLE : aucune sous-traitance propre à l'agent autorisée ; tout besoin d'outil tiers est soumis à CATHODE avant usage. | ### Fiche C-01 — Apport d'un carnet (exemple fictif) | Champ | Valeur pédagogique | | -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Responsables distincts | EXEMPLE : Agent Démonstration pour sa collecte et transmission ; CATHODE pour sa réception, contrôle et réutilisation décidée. | | Opération | EXEMPLE : transmission de vingt contacts pertinents pour la maintenance industrielle. | | Finalités | EXEMPLE : carnet initial de l'activité de l'agent ; nouvel usage pour présenter Infenix. Compatibilité, attentes et licéité de la transmission à vérifier. | | Données | EXEMPLE : coordonnées professionnelles minimales, provenance, information et restrictions, sans notes privées. | | Bases | EXEMPLE : évaluer séparément l'intérêt légitime de la transmission et de la réutilisation, avec information et opposition. Un nom dans un carnet ne prouve pas que la transmission est autorisée. | | Dates | EXEMPLE : collecte en septembre 2026, transmission envisagée le 5 octobre 2026 ; dates et preuves fictives. | | Information indirecte | EXEMPLE : informer dès le premier contact s'il intervient plus tôt et au plus tard dans le mois après la collecte indirecte, sous réserve des exceptions applicables. | | Destinataires et transfert | EXEMPLE : vérificateur CATHODE habilité, puis agent seulement pour les contacts validés ; canal sécurisé à convenir, pas de diffusion générale. | | Décision d'usage | EXEMPLE : lot en attente de vérification ; aucune campagne avant contrôle de provenance, bases, information et oppositions. | | Durées | EXEMPLE : contacts acceptés selon calendrier de prospection CATHODE ; lot non justifié non réutilisable. Toute archive de preuve a une finalité et durée distinctes. | ## Annexe 2 — Mesures et durées à confirmer Mécanismes observés dans le dépôt : authentification Supabase, comptes nominatifs, contrôle des accès par organisation et permissions, liens clients–partenaires acceptés et non expirés, révocation, journal d’événements partenaire et stockage de certaines factures avec accès signé. Leur effectivité en production doit être vérifiée ; le journal n’est pas présenté comme une preuve de stockage matériellement inaltérable. Précisions vérifiées dans le code : identité interrogée côté serveur auprès de Supabase et rafraîchissement des cookies de session ; factures partenaires PDF limitées à dix mégaoctets avec téléchargement signé de trois cents secondes après contrôle du partenaire ; pièces jointes de devis avec autorisation de l’acteur, contrôle du périmètre, quarantaine et vérification du type et de la taille avant disponibilité. Ces mécanismes ne prouvent ni une analyse antivirus, ni des politiques RLS actives, ni une purge automatique des fichiers. À compléter par les parties : administration et MFA, chiffrement en transit et au repos avec périmètre, sauvegardes et restauration testée, durée des journaux, contrôle des exports, gestion des vulnérabilités, confidentialité du personnel, procédure de droits et d’incidents, responsabilités et preuves de vérification. Calendrier proposé à valider techniquement avant signature : récupération pendant au moins trente jours après fin de service ou transition applicable ; effacement des données actives au plus tard soixante jours après fin de mission, sauf instruction plus rapide ; effacement des sauvegardes au plus tard quatre-vingt-dix jours après cette fin. Le contrat signé indique les délais réellement garantis et les exceptions légales ; ces valeurs ne décrivent pas un automatisme actuellement attesté. ### Mesures observées et organisation à confirmer | Mesure | Information préremplie | Limite / preuve à réunir | | ---------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Identité et sessions | OBSERVÉ DANS LE CODE : Supabase, vérification de l'utilisateur côté serveur et rafraîchissement des cookies de session. | Durée de session, paramètres de cookies déployés et révocation effective À CONFIRMER. Le contrôle de navigation ne remplace pas les permissions de chaque opération. | | MFA et administration | OBSERVÉ DANS LE CODE : client administratif Supabase distinct, sans persistance de sa session ; utilisé notamment pour le stockage. | MFA, personnes habilitées et protection des clés en production À CONFIRMER ; aucune activation MFA présumée. | | Séparation des organisations | OBSERVÉ DANS LE CODE : accès de facture lié au partenaire de l'utilisateur ; pièces jointes de devis soumises à l'acteur, au périmètre et à la visibilité du devis. | Ces contrôles portent sur les flux examinés ; étendre les preuves au périmètre réellement confié. Politiques RLS À CONFIRMER, les accès administratifs n'en prouvent pas l'effectivité. | | Factures partenaires | OBSERVÉ DANS LE CODE : PDF de taille supérieure à zéro et au plus dix mégaoctets ; chemin lié au partenaire ; téléchargement signé de 300 secondes. | Configuration du stockage, accès de production, conservation et suppression des objets À CONFIRMER. Les 300 secondes concernent le lien, pas la conservation du fichier. | | Pièces jointes de devis | OBSERVÉ DANS LE CODE : bucket déclaré privé, envoi signé, chemins construits côté serveur, quarantaine puis contrôle du type et de la taille avant disponibilité. | État réel du bucket et sécurité de production À CONFIRMER. Le contrôle de format ne constitue pas une analyse antivirus. | | Messagerie | OBSERVÉ DANS LE CODE : rendu HTML côté serveur et envoi SMTP avec hôte, port, identifiants et option de connexion sécurisée configurés côté serveur. OVH confirmé par CATHODE. | Produit OVH, TLS réellement négocié, boîtes, copies et journaux À CONFIRMER. Aucun traitement automatique des réponses ou oppositions n'est déduit du transport d'envoi. | | Base applicative | OBSERVÉ DANS LE CODE : PostgreSQL via Neon HTTP et client transactionnel WebSocket par défaut ; variante node-postgres configurable. | Fournisseur et pilote réellement déployés, région, chiffrement au repos, sauvegardes et règles d'accès À CONFIRMER. | | Assistance IA | OBSERVÉ DANS LE CODE : références/fabricants, images et annotations peuvent être envoyés à Gemini ; résultat brut d'analyse d'images conservable dans l'historique d'import de l'usine. | Préparer les contenus avant envoi ; aucun masquage automatique attesté. Contrat Google, localisations, usages propres, conservation et suppression du cache À CONFIRMER. | | Chiffrement des données | EXEMPLE : échanges protégés et postes sécurisés, copies locales limitées. | TLS des services, chiffrement au repos et des postes À CONFIRMER ; ne pas transformer une option du code en preuve de configuration réelle. | | Sauvegardes et restauration | EXEMPLE : restaurer après incident en réappliquant les instructions d'effacement avant remise en usage. | Fréquence, localisation, rétention, responsable et test de restauration À CONFIRMER. | | Journaux et exports | OBSERVÉ DANS LE CODE : journal d'événements partenaire ; des téléchargements existent sur certains flux. | Couverture, destinataires, format de restitution et durées À CONFIRMER ; aucune inaltérabilité matérielle revendiquée ni restitution complète automatique attestée. | | Vulnérabilités | EXEMPLE : consigner, corriger puis vérifier une anomalie d'accès. | Responsable, cadence et preuves opérationnelles À CONFIRMER. | | Confidentialité du personnel | EXEMPLE : engagement de confidentialité et instructions sur les copies locales. | Signatures, personnes habilitées et remise des consignes À CONFIRMER. | | Droits et incidents | CONFIRMÉ : point de contact CATHODE contact@cathode-obsolescence.fr. Obligations et délais prévus aux articles 9 et 10. | Responsable opérationnel, journal des demandes et exercice de procédure À CONFIRMER ; délais contractuels ne prouvent pas un dispositif déjà testé. | | Audits | OBSERVÉ DANS LE CODE : des tests ciblés vérifient les mécanismes examinés ; EXEMPLE : revue d'accès et preuve de suppression des exports. | Tests locaux distincts d'un audit de production. Organisation, preuves de production et contrôles de l'agent À CONFIRMER. | ### Exemple de calendrier — à valider, aucune purge automatique attestée Ces délais concernent la mission et les copies détenues pour celle-ci par le sous-traitant. Ils ne suppriment pas automatiquement la base conservée licitement par CATHODE comme responsable, ni le carnet d'origine de l'agent pour une finalité propre distincte et licite. | Opération | Point de départ | Proposition à confirmer | Illustration pour une fin au 31 décembre 2026 | | ------------------------------------- | ---------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------- | | Révocation des accès | Fin de mission ou décision de révocation | EXEMPLE : dès la fin de mission. | Vérifier le retrait le 31 décembre 2026. | | Restitution / récupération | Fin de mission | EXEMPLE : remise à CATHODE ; fenêtre de récupération de trente jours à convenir si nécessaire. | Jusqu'au 30 janvier 2027 si cette fenêtre est convenue. | | Effacement des copies actives | Fin de mission | Proposition du modèle : au plus tard soixante jours, sauf instruction plus rapide et exceptions légales ; À CONFIRMER. | Au plus tard le 1er mars 2027 si convenu. | | Effacement des sauvegardes concernées | Fin de mission | Proposition du modèle : au plus tard quatre-vingt-dix jours ; À CONFIRMER avec les fournisseurs et l'agent. | Au plus tard le 31 mars 2027 si convenu. | | Copies locales et exports | Fin de mission et restitution | EXEMPLE : effacer les téléchargements et duplications, puis consigner la suppression ; échéance À CONFIRMER. | Ne pas conserver un export comme carnet personnel. | | Effacements après restauration | Chaque restauration | EXEMPLE : réappliquer les effacements avant remise en usage. | Un contact effacé ne redevient pas prospectable après restauration. | **Prospection chez CATHODE — EXEMPLE** : référence CNIL de trois ans depuis collecte ou dernier contact émanant du prospect, à adapter au traitement. Une relance sortante ne réinitialise pas le délai. Une opposition arrête les sollicitations ; seuls les éléments nécessaires pour la respecter sont conservés dans la liste de blocage. **Archives légales — EXEMPLE** : preuve nécessaire à un litige isolée à accès limité, fondement et durée documentés, sans nouvelle prospection. La conservation comptable de certaines pièces ne justifie pas de conserver tout un carnet de prospects. **Restitution — EXEMPLE** : CSV UTF-8 des contacts et notes autorisés avec restrictions/oppositions utiles, remis à CATHODE par canal sécurisé. Format disponible et procédure réelle À CONFIRMER ; aucun export automatique complet présumé. **OBSERVÉ DANS LE CODE — conservation et copies** : l'entreprise peut être archivée ; cet état réversible n'efface pas les données. L'interface prévoit la suppression d'un contact, ce qui n'atteste pas l'effacement des historiques, exports, courriels ou sauvegardes. Un export individuel vCard est disponible dans le parcours partenaire. Aucun import CSV de contacts, export CRM complet, purge à trois ans ou effacement propagé des copies n'est attesté par ce parcours. Le CSV de restitution ci-dessus est donc un format proposé à organiser ; les imports CSV de pièces/stock ne sont pas des imports de fichiers de personnes. ## Annexe 3 — Inventaire des fournisseurs Pour chaque fournisseur effectivement retenu, préciser : entité juridique contractante, service, opérations et données, pays de traitement et d’accès, durée, contrat article 28, autorisation et mécanisme de transfert. L’inventaire ci-dessous prépare cette annexe ; les régions et contrats de production ne sont pas confirmés. Neon — base PostgreSQL et données applicatives. Supabase — authentification et certains fichiers, notamment factures et pièces jointes selon les fonctions. OVHcloud — messagerie, destinataires et contenus des courriels ; le fournisseur OVH est confirmé par CATHODE, mais le produit, l’entité et la localisation restent à préciser. Le code utilise PostgreSQL avec un pilote Neon HTTP et un client transactionnel WebSocket par défaut, ou un pilote node-postgres selon configuration. Les courriels sont rendus côté serveur puis envoyés par un transport SMTP configuré côté serveur ; cela ne prouve ni la réception des réponses dans Infenix, ni le chiffrement SMTP effectivement négocié en production. Google Gemini API — extraction d’images/documents et rapports selon fonctions. Identifier le régime contractuel, les conditions de réutilisation et de conservation et les éventuels transferts avant d’y confier des données personnelles. Vercel — hébergement prévu dans la documentation ; son utilisation effective et sa configuration doivent être confirmées. Flux IA précisément observés : classification de références et fabricants par le modèle gemini-3.1-flash-lite ; analyse d’images et annotations par gemini-3.1-pro-preview. Le résultat brut de cette analyse peut être conservé dans l’historique d’import avec l’identifiant d’usine et une empreinte des images. Les modèles décrivent cette version du code, pas un engagement de modèle permanent. Aucune suppression automatique de données personnelles dans les images, aucune durée de cache et aucune absence de conservation par Google ne sont attestées par ces flux. Tout fournisseur supplémentaire ou service activé figure dans l’annexe signée. Les partenaires choisis directement par le client et les responsables autonomes ne sont pas assimilés par défaut à des sous-traitants ultérieurs de CATHODE. ### Exemple d'autorisation pour le module B - [x] **EXEMPLE — autorisation spécifique** : l'agent ne confie pas les données de mission à un outil ou fournisseur supplémentaire sans autorisation écrite de CATHODE. - [ ] Autorisation générale : non retenue ici ; à choisir expressément si nécessaire avec la procédure de l'article 7. - [ ] Module C seul : non retenu ici puisque la mission comprend aussi B. Contact pour demander une autorisation : contact@cathode-obsolescence.fr. **EXEMPLE** : « Je souhaite utiliser un CRM tiers : voici le service, les données, les pays d'accès, les durées et le contrat. » Aucun transfert avant validation. Les fournisseurs de l'environnement propre de CATHODE ne sont pas, pour ce seul motif, des sous-traitants de l'agent. Si CATHODE traite pour un client dans le module A, sa liste doit être autorisée dans cette relation. Cet exemple n'autorise aucun prestataire par sa seule présence. ### Fournisseurs identifiés et informations encore manquantes | Service | Utilisation identifiée | À confirmer avant finalisation | | ----------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Neon | OBSERVÉ DANS LE CODE : base PostgreSQL, données applicatives et historique d'import ; pilote HTTP et transactions WebSocket par défaut. Variante node-postgres possible. | Déploiement effectif, entité, région, sauvegardes, accès, DPA, sous-traitants, rétention et transferts. | | Supabase | OBSERVÉ DANS LE CODE : identifiants/comptes et sessions ; certains fichiers de devis et factures ; liens temporaires de téléchargement. | Entité, régions des projets et fichiers, pays de support, configuration des buckets, DPA, rétention et transferts. | | OVH / OVHcloud | CONFIRMÉ par CATHODE : messagerie. OBSERVÉ DANS LE CODE : envoi SMTP de destinataires, objet, corps HTML et pièces jointes selon le courriel. | Produit réel, entité, stockage et accès, TLS effectif, contrat et rétention ; ne pas déduire France du seul nom OVH. | | Google Gemini API | OBSERVÉ DANS LE CODE : références, fabricants, catégories pour classification ; images et annotations pour extraction ; résultat brut d'extraction réutilisable depuis un cache par usine. Non nécessaire à la relance de cet exemple. | Régime du compte, périmètre activé, minimisation, rétention chez Google et dans Infenix, usages propres, entité et transferts avant données personnelles. | | Vercel | Hébergement prévu dans la documentation ; une configuration locale de l'application partenaires déclare cdg1. | Usage effectif et région de l'application Infenix non prouvés par cette configuration ; entité, régions d'exécution, journaux, sauvegardes, accès et garanties. | ### Exemple de fiche fournisseur : messagerie OVH - Entité contractante : **À CONFIRMER** dans le contrat CATHODE ; le fournisseur est connu, pas l'entité exacte. - Service : **OVH confirmé** ; **OBSERVÉ DANS LE CODE** — envoi par SMTP avec Nodemailer, rendu HTML côté serveur et adresse d'expéditeur issue du compte SMTP. Produit de boîtes/Exchange et configuration réelle **À CONFIRMER**. - Opérations et données : **OBSERVÉ DANS LE CODE** — envoi de destinataires, objet, corps et pièces jointes selon le message. **EXEMPLE** — utilisation pour des envois B2B autorisés ; réception des réponses et oppositions à organiser, sans automatisme de réception attesté par le transport d'envoi. - Sécurité de transport : **OBSERVÉ DANS LE CODE** — hôte, port, identifiants et option de connexion sécurisée configurés côté serveur. **À CONFIRMER** — TLS effectif et configuration du produit ; aucune valeur secrète reproduite. - Stockage et sauvegardes : **À CONFIRMER** pour le produit exact ; aucune région inventée. - Accès support et administration : **À CONFIRMER**, y compris hors EEE. - Conservation et effacement : **À CONFIRMER** pour messages, boîtes, journaux et copies. - Contrat article 28 : **À CONFIRMER** — garder le contrat réellement applicable, sa version et date. - Sous-traitants ultérieurs : **À CONFIRMER** dans la liste de ce service. - Autorisation : **À CONFIRMER** dans la relation où nécessaire ; l'inventaire ne vaut pas autorisation. - Transfert hors EEE : **À CONFIRMER** après vérification des stockages et accès ; aucune absence de transfert présumée. - Garanties : **À CONFIRMER** — documenter le mécanisme légal, l'évaluation et les mesures complémentaires lorsqu'elles sont requises ; aucune adhésion ou clause présumée. - Usage IA : non applicable à cette fiche de messagerie ; l'analyse IA demande une fiche distincte. ## Annexe 4 — Fichiers apportés et transmission Avant une transmission, l’apporteur fournit une fiche de provenance par lot : sources, dates, contexte, catégories, finalités initiales et envisagées, bases légales, information des personnes, canaux autorisés, oppositions et restrictions. Le destinataire vérifie ces éléments et refuse ou isole les données insuffisamment justifiées avant usage. Lorsque les parties sont responsables distincts, chacune répond de ses opérations. L’apporteur justifie la licéité de la transmission ; le destinataire justifie sa réutilisation. L’information prévue à l’article 14 est fournie au plus tard dans le mois et, si elle intervient plus tôt, lors de la première communication ou divulgation, sous réserve des exceptions applicables. Les oppositions à la prospection sont respectées sans délai et communiquées aux parties concernées dans le périmètre licite. Les listes de blocage conservent seulement les éléments nécessaires pour éviter une nouvelle sollicitation. Un nouvel import ou une protection commerciale du prospect ne neutralise pas une opposition. Les parties fixent les destinataires, le transfert sécurisé, les copies locales autorisées, la durée et la fin de mission. Les prospects non clients sont conservés pour la prospection suivant la durée justifiée, avec trois ans depuis la collecte ou le dernier contact émanant du prospect comme référence CNIL ; une relance sortante ne remet pas ce délai à zéro. Une finalité de preuve distincte est documentée. Limites vérifiées du parcours CRM : aucun champ dédié ni circuit complet de provenance, d’information et d’opposition du contact n’a été identifié dans les flux examinés. Le consentement marketing du compte utilisateur et la source technique d’un événement ne remplacent pas ces preuves. Un export individuel vCard existe ; aucun import CSV de contacts, export CRM global, purge automatique à trois ans ou effacement propagé des copies n’est attesté par ce parcours. L’archivage d’une entreprise n’est pas un effacement. Les obligations ci-dessus nécessitent une procédure opérationnelle documentée, dans Infenix ou un système externe maîtrisé. ### Ce que le code remplit et ce que la procédure doit documenter | Élément de contrôle | État vérifié | Préremplissage utilisable | | ------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Apporteur, responsable, mission | Champs d'acteur, de partenaire et d'affectation présents ; rôles juridiques à décider selon les faits. | CATHODE et agent identifiés dans la fiche ; contrat et représentants À CONFIRMER. | | Source et date initiales de collecte | Pas de champ dédié identifié sur le contact CRM ; créateur et dates techniques existent. | Fiche de provenance par lot à conserver dans un dossier sécurisé ; date de création CRM ne suffit pas. | | Finalités, base légale, information | Qualification commerciale possible, mais pas de circuit complet de preuve identifié. | Décrire finalités, analyse, notice/version/date et référence des preuves dans le dossier du lot. | | Consentement du prospect | Le consentement marketing trouvé concerne l'utilisateur du compte. | Preuve séparée pour le prospect lorsque requise ; ne pas copier la case du compte. | | Opposition et restrictions | Aucun champ ou workflow CRM dédié identifié dans les flux examinés ; des demandes peuvent arriver par courriel ou un outil externe. | Procédure CATHODE à confirmer, avec liste minimale protégée et contrôle avant saisie, réimport et sollicitation. Aucun blocage logiciel automatique présumé. | | Information après transmission | Obligation documentaire de l'article 14 ; aucun envoi automatique attesté dans ce parcours. | Pour le scénario fictif : premier contact ou au plus tard 5 novembre 2026, sous réserve des exceptions ; conserver la preuve réelle. | | Import du fichier | Aucun import CSV de contacts attesté dans le parcours CRM examiné. | Canal de transmission et mode de saisie à convenir ; ne pas promettre un bouton d'import de carnet. | | Restitution et copies | Export individuel vCard vérifié ; procédure complète non attestée. | Inventorier données, pièces, historiques et copies avant de choisir le format et le canal réels. | | Archivage et purge | Archivage entreprise réversible ; aucune purge automatique liée à une durée RGPD attestée. | Désigner le responsable du calendrier et des preuves d'effacement ; paramètres trente/soixante/quatre-vingt-dix jours à confirmer techniquement. | ### Lot C-01 — exemple fictif de fichier apporté - Identifiant : **EXEMPLE** — DEMO-CARNET-2026-01, vingt contacts fictifs ; aucune liste nominative dans ce modèle public. - Apporteur / destinataire : **EXEMPLE** — Agent Démonstration transmet à CATHODE. - Source et dates : **EXEMPLE** — échanges professionnels lors de rencontres industrielles en septembre 2026, à documenter. Une rencontre ou carte de visite ne suffit pas à autoriser une transmission à CATHODE. - Personnes et données : **EXEMPLE** — responsables maintenance et achats ; coordonnées professionnelles minimales, source, date et opposition. Téléphone seulement si utile et justifié. - Finalités : **EXEMPLE** — carnet de l'activité propre de l'agent, puis présentation d'Infenix par CATHODE ; compatibilité et attentes à vérifier. - Rôles : **EXEMPLE** — agent responsable de sa collecte/transmission, CATHODE responsable de son contrôle/réutilisation ; relances ultérieures confiées selon B. - Bases : **EXEMPLE** — intérêts légitimes de transmission et réutilisation à évaluer séparément, avec information, opposition et respect du canal. Le DPA ne rend pas automatiquement licite le carnet. - Preuves : **À CONFIRMER** — source, date, fonction pertinente, notice réellement remise, autorisation si nécessaire, oppositions et analyse ; le modèle ne fournit pas ces pièces. - Information d'origine : **À CONFIRMER** — ce qui a été réellement communiqué, notamment sur la transmission à CATHODE ; pas de statut informé sans preuve. - Information complémentaire : **EXEMPLE** — collecte indirecte le 5 octobre 2026 : informer au plus tard le 5 novembre 2026, et dès un premier contact antérieur, sous réserve des exceptions applicables. - Canaux : **EXEMPLE** — e-mail B2B pertinent avec opposition simple ; pas de campagne grand public ou numéro personnel sans analyse adéquate. - Oppositions : **EXEMPLE** — contrôle des restrictions du lot et de la liste CATHODE avant import puis envoi ; un réimport ne réactive pas un contact opposé. Procédure et outil réels **À CONFIRMER**. - Transfert : **EXEMPLE** — espace à accès restreint ou canal chiffré convenu, limité au vérificateur CATHODE ; aucun lien public. Canal réel **À CONFIRMER**. - Conservation : **EXEMPLE** — contacts validés : référence de trois ans depuis collecte ou dernier contact émanant du prospect, avec revue et arrêt immédiat en cas d'opposition. Lot non justifié non réutilisable ; sort et preuves à définir séparément. - Contrôle : **EXEMPLE — EN ATTENTE DE VÉRIFICATION**, aucune campagne tant que les pièces réelles ne sont pas validées. - Vérificateur et décision : **À CONFIRMER** — collaborateur habilité CATHODE, date, décision et référence du dossier sécurisé ; aucune validation fictive présentée comme faite. ### Exemple de premier message d'information — à adapter après validation > Bonjour, CATHODE vous contacte au sujet d'Infenix en lien avec vos fonctions professionnelles. Dans cet exemple, votre contact nous a été transmis par l'agent qui l'a recueilli lors d'un échange professionnel ; la source réelle doit être précisée. Vous pouvez vous opposer à toute nouvelle prospection en répondant à ce message ou en écrivant à contact@cathode-obsolescence.fr. Les informations sur les finalités, les données, les destinataires, la conservation et vos droits sont disponibles dans la politique de confidentialité d'Infenix. Utiliser la source exacte, la base applicable et le lien public réel à l'information complète avant envoi. Ce texte pédagogique ne remplace pas toute l'information requise. Aucun message n'est envoyé par ce modèle. ## Annexe 5 — Validation et signature Le document accepté indique la version, le contrat principal, les modules et annexes complétés. Pour chaque partie sont consignés la dénomination, le représentant et sa qualité, la date et la signature ou la preuve d’acceptation électronique. Les autorisations de sous-traitants et instructions ultérieures sont conservées. Les annexes opérationnelles incomplètes doivent être finalisées avant que les traitements correspondants soient confiés. Un simple lien dans les CGU ou un compte utilisateur ne remplace pas cette acceptation par les personnes habilitées. ### Validation finale — exemple non signé - Référence : **EXEMPLE** — DPA-DEMO-2026-01. - Contrat principal : **EXEMPLE** — DEMO-AGENT-2026-01, à remplacer par le mandat réel. - Version du modèle : 2026-10-05. - Version préremplie : **EXEMPLE** — pédagogique du 5 octobre 2026, pas une version acceptée. - Modules : **EXEMPLE** — B pour la relance et C pour le carnet transmis ; A non retenu ici. - Annexes : **EXEMPLE** — 1 à 5, fiches B-01 et C-01 ; preuves et informations techniques non finalisées. - Prise d'effet : **À CONFIRMER** après finalisation et acceptation réelles ; le 5 octobre indiqué pour la mission est fictif. - État : **NON SIGNÉ — EXEMPLE PÉDAGOGIQUE**. ### Pour CATHODE - Dénomination et adresse : SARL CATHODE, 12 rue des Villas, 84130 Le Pontet, France. - Représentant : **À CONFIRMER** — personne réellement habilitée. - Qualité et pouvoir : **À CONFIRMER** — par exemple gérant ou mandataire avec pouvoir suffisant ; ne pas présumer la qualité. - Lieu et date : Le Pontet ; date **À CONFIRMER** à la signature réelle. - Signature / preuve : **AUCUNE DANS CET EXEMPLE**, référence à renseigner après acceptation. ### Pour l'agent - Identité : **EXEMPLE** — Agent Démonstration, personne fictive à remplacer. - Représentant : **À CONFIRMER** — personne signant en son nom ou pour la société. - Qualité et pouvoir : **À CONFIRMER** selon la structure réelle. - Lieu et date : **À CONFIRMER** à la signature réelle. - Signature / preuve : **AUCUNE DANS CET EXEMPLE**, référence à renseigner après acceptation. ## Sources pour les explications pédagogiques - [RGPD : responsables et sous-traitants, articles 26 et 28](https://www.cnil.fr/fr/reglement-europeen-protection-donnees/chapitre4). - [CNIL : prospection commerciale par courrier électronique](https://www.cnil.fr/fr/la-prospection-commerciale-par-courrier-electronique-sms-mms-et-automate-dappel).