Projet d'accord de traitement des données

Clauses et annexes à compléter et accepter avant contractualisation

Projet mis à jour : 8 septembre 2026

Projet en attente d’annexes complétées et d’acceptation : les clauses ci-dessous définissent les obligations proposées aux parties. Elles ne prouvent ni l’acceptation d’un contrat ni le déploiement de toutes les mesures requises. Les champs ouverts des annexes A à D doivent être complétés et les mesures applicables vérifiées avant d’utiliser ce document comme DPA conclu.

1. Parties et périmètre

Client : [Nom et adresse ; responsable du traitement ou sous-traitant autorisé, selon l’annexe A]
Sous-traitant : MAIKO BOSSUYT, Entrepreneur individuel (EI), SIREN 834180911, opérant le_dns, 8 Rue Vasco de Gama, 77700 Serris, France
Service : DNS autoritatif primaire et secondaire géré

Selon les instructions documentées du client, le_dns stocke, consulte, modifie, signe, publie, restitue et supprime les données personnelles nécessaires au service décrit en annexe A. Une instruction de publier des enregistrements DNS rend leur contenu accessible par le DNS public ; le client demeure responsable du contenu et de la licéité de ses instructions.

2. Objet, durée et finalités

Le traitement couvre l’hébergement DNS autoritatif :

• stockage, signature et diffusion de zones primaires ;
• réception et diffusion de zones secondaires par AXFR/IXFR ;
• gestion des comptes, accès, clés, équipes et automatisations nécessaires ;
• supervision, sécurité, sauvegarde et assistance liées au service.

Le traitement dure pendant le service contractuel, puis pendant les opérations de restitution et de suppression de la section 8 et de l’annexe D. Le renouvellement, l’échec d’un paiement ou le retour à une offre gratuite ne constitue pas, à lui seul, une instruction de supprimer les zones. Ce DPA ne modifie pas les politiques commerciales de résiliation ou de continuité DNS.

3. Données et personnes concernées

Les données peuvent inclure :

• les enregistrements DNS confiés par le client, qui peuvent eux-mêmes contenir des données personnelles ;
• les domaines, adresses de primaires, données de configuration et historiques de zone ;
• les emails professionnels des utilisateurs, membres et invités ;
• les identifiants, rôles, traces d’administration et mises à jour DDNS ;
• les informations techniques nécessaires aux health checks et à la sécurité.

Les catégories de personnes comprennent les administrateurs du client, les contacts de domaines et les personnes identifiées dans les enregistrements fournis ; elles sont précisées en annexe A. La présence d’une donnée dans cette liste n’attribue pas tous ses usages au rôle de sous-traitant. Le service n’est pas destiné aux données sensibles ; une instruction exceptionnelle licite nécessite un périmètre expressément convenu et des garanties appropriées avant traitement.

4. Instructions et confidentialité

Le client détermine les finalités et le contenu de ses zones comme responsable du traitement ou, s’il agit comme sous-traitant, confirme que son responsable du traitement a autorisé les instructions et le recours à le_dns. Le rôle et l’autorisation sont consignés en annexe A. le_dns agit comme sous-traitant ou sous-traitant ultérieur uniquement pour les traitements confiés. Ses finalités propres de sécurité des comptes, prévention de la fraude, statistiques du résolveur et facturation sont décrites séparément dans la politique de confidentialité ; elles n’autorisent pas une réutilisation des données de zone confiées pour d’autres finalités.

Le client est responsable de la base légale, de l’information et des autorisations nécessaires à ses instructions. Il peut émettre et modifier ses instructions par les actions autorisées du portail/de l’API ou par écrit via les contacts vérifiés de l’annexe A. le_dns consigne les instructions écrites et assure la traçabilité de leur exécution. Une requête API ne constitue une instruction que dans les limites des droits de son auteur ; elle n’étend pas les droits légaux du client.

le_dns traite les données confiées uniquement sur instructions documentées, y compris pour un transfert hors EEE. Si le droit de l’Union ou d’un État membre impose un autre traitement, le_dns informe le client de cette exigence avant le traitement, sauf interdiction légale de divulgation pour des motifs importants d’intérêt public. Si le_dns estime une instruction contraire au droit applicable de la protection des données, il en informe immédiatement le client et s’abstient d’exécuter l’instruction contestée dans l’attente d’une clarification licite. Il coopère à une solution licite sans modifier silencieusement la finalité.

le_dns limite l’accès aux personnes dont les fonctions le nécessitent et veille à ce qu’elles soient liées par un engagement de confidentialité ou une obligation légale appropriée. Ces personnes reçoivent les instructions adaptées à leur rôle et ne traitent les données que dans leur cadre autorisé. La confidentialité subsiste après la fin de leur accès.

5. Mesures techniques observées

le_dns met en œuvre les mesures techniques et organisationnelles requises par l’article 32 du RGPD, selon les traitements, les risques, l’état des connaissances et les coûts de mise en œuvre. Elles couvrent notamment la confidentialité, l’intégrité, la disponibilité et la résilience appropriées, la capacité de restauration et l’évaluation régulière de l’efficacité des mesures. L’annexe B consigne les mesures effectives et les preuves du déploiement contractuel ; leurs évolutions doivent maintenir un niveau de protection adapté aux risques.

Le code v2 inspecté comporte les contrôles suivants ; leur présence ne constitue pas une preuve de déploiement ou une certification :

• authentification par session ou clés API dont seule l’empreinte SHA-256 est stockée ;
• MFA TOTP et WebAuthn, équipes et rôles selon les offres, ainsi que SAML pour les comptes Enterprise explicitement inscrits à la préversion après validation externe ;
• TLS pour le portail et l’API ;
• TSIG HMAC-SHA256 pour l’authentification et l’intégrité des transferts secondaires ;
• DNSSEC et service de signature PKCS#11 basé sur SoftHSM ;
• audits restreints, limitation de débit et contrôles anti-abus ;
• rétention par lots de plusieurs catégories d’audit et d’artefacts de sécurité.

TSIG ne chiffre pas AXFR/IXFR. SoftHSM est un HSM logiciel, pas un module matériel certifié. Le chiffrement des volumes et sauvegardes, les accès SSH et les procédures de restauration doivent être vérifiés sur la production avant d’être garantis contractuellement. Les mesures non vérifiées de l’annexe B restent à résoudre avant acceptation ; elles ne constituent pas des exceptions à l’article 32.

6. Sous-traitants ultérieurs

Dans l’instantané de production inspecté le 29 août 2026, la flotte utilisait OVHcloud et Scaleway dans l’Union européenne. Cette preuve datée doit être revérifiée sur le déploiement et les contrats exécutés avant signature. La configuration cible mentionne également du stockage objet OVH. Le prestataire de messagerie transactionnelle et toute autre dépendance de production doivent être identifiés avant signature.

Paddle est le revendeur prévu pour les nouvelles ventes et agit comme responsable du traitement pour ses propres finalités commerciales et financières, décrites dans sa politique de confidentialité. Cela n’en fait pas un sous-traitant ultérieur du contenu des zones DNS. Les données de compte transmises et le parcours déployé doivent être vérifiés et documentés dans la politique de confidentialité ; les ventes en mode réel restent fermées pendant cette préparation.

le_dns ne recourt à un sous-traitant ultérieur qu’après autorisation écrite préalable, spécifique ou générale, du client. L’annexe C consigne les prestataires autorisés, leurs fonctions et localisations, le mode d’autorisation et les contrats correspondants. Une présence dans un inventaire historique ne vaut pas autorisation par ce projet.

En cas d’autorisation générale, le_dns informe le client de tout ajout ou remplacement envisagé assez tôt pour permettre une opposition effective pour des motifs de protection des données avant l’intervention du prestataire. Le canal et le délai de préavis sont à compléter en annexe C. Les parties recherchent une solution appropriée lorsqu’une opposition ne peut être résolue ; le traitement concerné ne commence pas sans autorisation valide. Cette clause n’introduit ni frais, ni consentement automatique par silence, ni droit unilatéral de résiliation commerciale.

le_dns impose contractuellement à chaque sous-traitant ultérieur autorisé des obligations de protection des données équivalentes à celles applicables à l’activité confiée par ce DPA, vérifie ses garanties suffisantes et demeure responsable envers le client de l’exécution de ces obligations. Il fournit les informations nécessaires pour démontrer ces garanties, avec des occultations proportionnées protégeant les informations confidentielles sans rapport avec le traitement.

le_dns ne transfère les données confiées vers un pays tiers ou une organisation internationale que sur instruction documentée ou selon l’exigence légale de la section 4, avec un mécanisme applicable du chapitre V du RGPD. L’annexe C précise les pays de destination et d’accès, le mécanisme et les moyens d’obtenir les garanties. Une autorisation de sous-traitance ne suffit pas à établir la licéité d’un transfert. Aucun engagement global d’absence de transfert n’est pris tant que cet inventaire reste incomplet ; ce DPA ne constitue pas lui-même des clauses contractuelles types de transfert international.

7. Assistance et droits des personnes

Compte tenu du traitement, le_dns assiste le client par des mesures techniques et organisationnelles appropriées, dans toute la mesure du possible, pour les demandes du chapitre III du RGPD. Cette assistance couvre la recherche et la remise sécurisée des données confiées, la rectification, la limitation et l’effacement, ainsi que la portabilité et l’opposition lorsqu’elles s’appliquent. le_dns transmet rapidement au client les demandes reçues concernant les traitements pour son compte et ne répond pas au fond en son nom sans instruction ou obligation légale.

Le client détermine la réponse et vérifie les droits du demandeur ; le_dns coopère aux vérifications nécessaires d’identité et d’autorité sans collecte excessive. Les parties utilisent les contacts de l’annexe A pour identifier le délai applicable et coordonner l’assistance à temps pour respecter les obligations légales du client. L’absence de fonction en libre-service ne suspend pas ces obligations et ne subordonne pas l’assistance à l’achat d’une option.

L’API inspectée permet de télécharger un instantané d’historique de zone conservé. Cela ne constitue pas une restitution complète de toutes les données personnelles confiées. Le périmètre et la procédure de restitution complète figurent en annexe D ; aucune garantie de restitution automatisée en sept jours n’est déduite du code inspecté.

8. Conservation et fin de contrat

À la fin du traitement confié, le client choisit la restitution suivie de la suppression, ou la suppression sans restitution. le_dns exécute ce choix pour les données personnelles confiées et supprime les copies restantes, y compris chez les sous-traitants ultérieurs, sauf conservation imposée par le droit de l’Union ou d’un État membre. L’annexe D précise le format et le délai de restitution sécurisée, le calendrier d’effacement des stockages actifs et sauvegardes et les preuves d’achèvement. L’archivage par le logiciel n’autorise pas une conservation indéfinie.

En cas de conservation légalement imposée, le_dns communique au client le fondement, les catégories et la durée, sauf interdiction de divulgation ; il isole les données retenues et limite leur usage à cette obligation. Les pièces de facturation traitées sous responsabilité propre restent distinctes des données de zone confiées et ne justifient pas la conservation de secrets DNS ou de tout le contenu client.

Pendant un intervalle d’expiration des sauvegardes convenu, les copies restent protégées et indisponibles pour les usages courants. La procédure de restauration doit réappliquer les instructions d’effacement valides avant le retour des données en service normal. le_dns fournit un relevé écrit d’achèvement indiquant les stockages concernés, les dates et toute conservation légale restante ; il ne certifie pas une suppression non vérifiée.

Les limites constatées dans cette revue figurent en annexe D. Elles doivent être résolues pour le traitement convenu avant acceptation et ne neutralisent pas le choix du client. Les obligations protégeant les données légalement retenues subsistent après la fin du service. Les parties documentent les responsabilités et dépendances du retrait DNSSEC ; celles-ci n’autorisent pas une conservation indéfinie. Le retour à l’offre gratuite ne détourne, ne gare et ne monétise pas les réponses DNS.

9. Incidents de sécurité

le_dns doit informer le client sans retard injustifié après avoir pris connaissance d’une violation de données personnelles traitées pour son compte et fournir les informations disponibles nécessaires à sa propre analyse et à ses obligations. Cette notification n’attend pas une enquête exhaustive.

Un engagement plus court, par exemple 24 heures, ne doit être ajouté qu’après validation de l’astreinte, des procédures et des moyens d’investigation. Les délais de notification aux autorités ou personnes concernées relèvent du responsable du traitement selon le RGPD et le niveau de risque.

La notification initiale précise, selon les informations disponibles, la nature de la violation, les catégories et nombres approximatifs de personnes et d’enregistrements concernés, un contact, les conséquences probables et les mesures prises ou proposées pour contenir et atténuer l’incident. Les compléments sont transmis progressivement sans retard injustifié supplémentaire. le_dns préserve les éléments d’enquête nécessaires, coopère à la maîtrise et à la correction de l’incident et assiste le client pour les notifications des articles 33 et 34. Le délai conditionnel de notification du responsable du traitement à l’autorité n’est pas un délai d’attente pour le sous-traitant.

10. Audit

le_dns met à disposition les informations nécessaires pour démontrer le respect de ses obligations de l’article 28 et permet les audits, y compris les inspections, du client ou de son auditeur mandaté, auxquels il contribue. Les parties coordonnent un périmètre proportionné, des accès sûrs et la protection des données des autres clients. Ces modalités ne doivent pas empêcher un audit effectif ni retarder une vérification légalement urgente ; un rapport de synthèse ne remplace pas automatiquement une inspection nécessaire.

Compte tenu du traitement et des informations dont il dispose, le_dns assiste également le client pour les évaluations de sécurité, les analyses d’impact et la consultation préalable des articles 32 à 36. Il fournit les informations utiles sur les traitements, risques et contrôles, coopère avec les autorités compétentes et signale toute lacune pouvant affecter la conformité du client. Aucun audit achevé ou certification indépendante n’est revendiqué sans rapport existant applicable au déploiement.

11. Responsabilité et droit applicable

Le RGPD et les autres dispositions impératives prévalent. Pour le traitement des données confiées, le DPA accepté prévaut sur les conditions de service incompatibles. Il ne modifie pas les prix, renouvellements, règles de revente ou préavis. Le droit français a vocation à s’appliquer, sous réserve des règles impératives de compétence et de protection des consommateurs. Les modifications du DPA accepté ou des instructions sont documentées ; une modification de ce projet public ne modifie pas à elle seule un accord existant.

12. Contact

• Questions DPA : legal@ledns.eu
• Vie privée : privacy@ledns.eu
• Sécurité : security@ledns.eu

13. Acceptation

Ce projet ne crée pas d’accord avant d’être complété et accepté par les représentants autorisés des deux parties. Le relevé d’acceptation écrit ou électronique identifie les parties, leur autorité, la version du document, les annexes complétées et la date d’effet. Un emplacement de signature, une création de compte ou un paiement ne prouve pas cette acceptation. Une obligation inexécutable doit être résolue avant de confier le traitement concerné ; laisser une annexe ouverte ne dispense pas des obligations du RGPD.

Client : ____________________
le_dns : ____________________
Date : ____________________

Annexe A — Parties, traitements et instructions

Annexe B — Mesures de sécurité et preuves opérationnelles

Annexe C — Sous-traitants ultérieurs et transferts internationaux

Il s’agit d’un inventaire à compléter, pas d’une liste autorisée. Pour chaque prestataire réel, consigner l’entité juridique, la fonction, les données, les pays y compris d’accès distant, le contrat, l’autorisation et les garanties de transfert éventuelles.

Les ventes et paiements traités par Paddle pour ses propres finalités relèvent des documents commerciaux et de confidentialité ; leur mention ne l’autorise pas à recevoir le contenu des zones DNS. Les preuves historiques de l’ancien prestataire sont conservées séparément.

Annexe D — Restitution, conservation et suppression

Référence : articles 28 et 32 à 36 du RGPD publiés par la CNIL.