Procédure de suppression de compte et de données et de demande d'exercice des droits (DSAR / ARCO)

1. Objet

Le présent document constitue la procédure opérationnelle par laquelle Happy Songs reçoit, vérifie, exécute et clôture une demande de suppression d'un compte et de ses données, ou d'exercice de tout autre droit de la personne concernée (accès, rectification, annulation/effacement, opposition, portabilité, retrait (opt-out) et retrait du consentement — les derechos ARCO au Mexique ; les droits de protection de la vie privée des consommateurs prévus par la CCPA/CPRA, la Texas TDPSA et la version amendée de la règle COPPA (COPPA Rule) aux États-Unis).

Il est à la fois destiné au Client (les écrans in-app, la page web de suppression et les textes de confirmation) et interne (le moteur d'admission, de vérification, d'exécution et d'audit). Il est rédigé de sorte qu'une demande ne puisse être perdue, ne puisse être exécutée contre la mauvaise personne, et ne puisse être clôturée avant que chaque magasin de données ne retourne un résultat documenté dans le délai légal applicable.

2. Définitions

• Le Client (« the Customer »). Le titulaire du compte : un adulte — âgé d'au moins 18 ans, ou de l'âge de la majorité là où le Client réside — qui s'inscrit, exploite et paie le service, et qui est la seule personne habilitée à déposer et à recevoir la réponse à toute demande au titre de la présente procédure. L'identifiant de référence du Client est un numéro de téléphone vérifié (Section 7).
• Parent ou tuteur légal. La qualité en laquelle agit le Client lorsqu'il fournit les informations d'un mineur. Lorsque le Client fournit le prénom d'un mineur, le Client déclare qu'il est le parent ou le tuteur légal de ce mineur et consent au traitement pour le compte de l'enfant. Un mineur ne détient jamais de compte, n'exploite jamais le service et ne dépose jamais de demande ; le Client exerce tout droit relatif aux données d'un mineur (Section 8).
• Prénom du destinataire. Le seul élément d'information que Happy Songs conserve au sujet de la personne pour laquelle une chanson est créée : un prénom uniquement. Happy Songs ne conserve ni nom de famille, ni surnom, ni âge, ni date de naissance, ni profil, ni localisation précise, ni aucune donnée relevant de catégories particulières de cette personne. L'âge ou l'étape de vie peut être utilisé sur le moment pour parcourir ou personnaliser une chanson et n'est pas conservé.
• Suppression de compte. L'effacement de l'intégralité du compte et la cascade décrite à la Section 9, initiée par le Client via le contrôle in-app ou la page web de suppression.
• Demande DSAR / ARCO. Tout exercice d'un droit de la personne concernée : accès/Acceso, rectification/Rectificación, annulation-effacement/Cancelación, opposition/Oposición, portabilité, retrait (opt-out) de la « vente »/du « partage » et respect du Global Privacy Control, ainsi que le retrait du consentement.
• Données côté serveur. Tout ce que détiennent Happy Songs ou ses sous-traitants. Incluses dans le périmètre de suppression, sous réserve de la conciliation de conservation prévue à la Section 11.
• Cache sur l'appareil (on-device cache). La copie des chansons gérée par l'App et stockée sur l'appareil aux seules fins de lecture hors ligne au sein de l'App. Dans le cadre du modèle d'accès en écosystème fermé (Section 3), il ne s'agit pas d'un fichier appartenant au Client, il n'est pas exportable et il est à la portée de l'App ; il est purgé lors de la suppression ou de la fin de l'accès (Section 9.4).
• Horloge SLA (SLA clock). Démarre lorsqu'une demande vérifiée est reçue ; mesurée par régime (Section 12).
• Liste de suppression (suppression list). Un enregistrement à clé, minimal et non sensible, conservé après suppression afin qu'une restauration depuis une sauvegarde ou une réinscription ne ressuscite pas les données supprimées ni ne recible l'ancien Client (Sections 9.5 et 13).

3. Le modèle d'accès que la présente procédure met en œuvre

Happy Songs exploite un écosystème fermé. Le Client reçoit une licence personnelle, non exclusive et révocable d'accéder à chaque chanson et de la lire uniquement au sein de l'App. Une chanson n'est pas la propriété du Client, n'est pas livrée sous forme de fichier téléchargeable ou exportable, et n'est ni unique ni exclusive (un remplissage de nom (name-fill) est réutilisé ; un autre Client dont le destinataire partage le même prénom peut recevoir la même chanson). Parce qu'aucun fichier exportable n'est jamais livré, la suppression est complète : il n'existe aucune copie détenue par le Client que la suppression laisserait subsister. Le cache sur l'appareil n'existe que pour permettre la lecture hors ligne et est purgé lorsque l'accès prend fin. C'est le fondement factuel des déclarations relatives à la suppression et à la purge du cache faites tout au long de la présente procédure et il ne doit pas être contredit par les textes destinés au Client (Section 15).

4. Droits inclus dans le périmètre (le menu des demandes)

L'écran in-app « Privacy & Data », la page web de suppression et la boîte de réception confidentialité doivent proposer, au minimum, les droits ci-dessous. Chaque canal est gratuit pour une première demande ; une demande répétée manifestement infondée ou excessive peut être traitée selon les règles du régime applicable, appliquées de manière étroite et jamais comme un obstacle à une demande légitime.

Pour tout droit portant sur les données d'un mineur, le Client est le seul demandeur éligible (Section 8).

5. Parcours A — Suppression de compte in-app (libre-service, imposée par les magasins d'applications)

Point d'entrée. Réglages → « Privacy & Data » → « Delete my account », accessible en pas plus de 2 taps depuis les Réglages. Apple exige que la suppression puisse être initiée au sein de l'App ; Google Play exige en outre une URL web de suppression (Parcours B).

Étapes.

1. Divulgation avant confirmation (texte à l'écran, sous réserve de la Section 15). L'écran indique, de manière véridique et sans culpabilisation ni friction :
   • Ce qui est supprimé : le compte ; les données du Client (numéro de téléphone, toute adresse e-mail facultative, données techniques/de l'appareil, données d'usage/analytiques et communications) ; chaque prénom de destinataire fourni par le Client ; et chaque chanson générée (paroles, pochette et audio) — sur les serveurs de Happy Songs et chez nos prestataires.
   • Que les chansons mises en cache dans l'App sont également supprimées : parce que les chansons existent uniquement au sein de l'App et qu'aucun fichier exportable n'existe, la suppression arrête la lecture et purge le cache sur l'appareil ainsi que toutes les copies serveur ; plus rien de lisible ne subsiste ensuite.
   • Ce que cela coûte : l'irréversibilité ; la perte d'accès à toutes les chansons ; la déchéance des droits et récompenses in-app (Jacks) et la rupture de tout lien de « restore purchases » et de récupération rétroactive par code.
   • Que les enregistrements que Happy Songs est légalement tenue de conserver — principalement les enregistrements de transaction, d'abonnement et fiscaux, ainsi que tout enregistrement sous conservation légale (legal-hold) active ou de sécurité — survivent à la suppression du compte sous une forme minimisée et à accès restreint (Section 11).
   • Délais : la désactivation est immédiate ; la purge complète des serveurs et des sous-traitants s'achève dans un délai de 30 days, la valeur unique reflétée depuis le Calendrier de conservation des données (D17 §6.2), à l'exception des enregistrements légalement conservés au titre de la Section 11.
2. Ré-authentification par code à usage unique (one-time passcode) envoyé au téléphone de référence, ou par une étape de renforcement (step-up) d'une session authentifiée (Section 7).
3. Confirmation par saisie d'une confirmation ou par un interrupteur explicite. Aucune friction de type dark pattern et aucune incitation à la rétention ne sont permises ; cet écran est utilisé par le Client adulte, et la norme anti-manipulation s'applique à ce Client.
4. Désactivation immédiate. Les jetons de session sont révoqués, la connexion est désactivée et le contenu est retiré de la liste du compte ; la demande entre dans la file d'attente de suppression.
5. Confirmation à l'écran et par un message au téléphone ou à l'e-mail de référence, indiquant que la demande a été reçue, la fenêtre d'achèvement, que l'accès in-app a pris fin, et que le cache sur l'appareil a été purgé.
6. Ticket créé dans le moteur (Section 10) avec l'horloge SLA démarrée.

Fenêtre de grâce / d'annulation. Une fenêtre facultative de suppression douce (soft-delete) (recommandée : pas plus de 72 hours) peut permettre au Client d'annuler avant la purge définitive (hard purge). Si elle est adoptée, elle doit être divulguée et ne doit jamais dépasser un quelconque délai légal applicable. Posture par défaut : courte, ou nulle.

6. Parcours B — Page web de suppression (exigée par Google Play)

• Une page publique à l'adresse https://happysongs.ai/delete-account (et son équivalent en espagnol), accessible sans installer l'App et sans franchir de connexion ou de mur payant (paywall), reliée depuis le formulaire Data Safety de la Play Console et depuis l'Avis de confidentialité.
• La page présente les mêmes textes véridiques sur le périmètre que le Parcours A, recueille le téléphone de référence, et déclenche la vérification par code à usage unique (Section 7) afin qu'aucun tiers ne puisse supprimer le compte d'un Client.
• Une fois vérifiée, la demande entre dans le même moteur et la même file d'attente que le Parcours A. Un Client qui ne peut pas se vérifier (par exemple, un numéro perdu) est acheminé vers le canal DSAR/ARCO (mécanisme de repli de la Section 7) pour une vérification manuelle d'identité.
• La page indique les délais et la conciliation de conservation (Section 11).

7. Parcours C — Canal DSAR / ARCO, et vérification d'identité

Canaux. Le formulaire de demande in-app « Privacy & Data » ; la page web de suppression (pour la suppression) ; et la boîte de réception surveillée privacy@happysongs.ai (une demande ARCO peut être formulée par écrit). Chaque canal est gratuit pour une première demande et alimente un système de billetterie unique doté d'une seule horloge SLA. Aucune demande ne peut vivre uniquement dans un fil de boîte de réception.

Ce que l'admission recueille. L'identité du demandeur ; la qualité (soi-même, ou parent/tuteur légal agissant pour un mineur) ; le droit demandé ; le périmètre ; le signal de résidence qui détermine le délai (Section 12) ; et l'identifiant.

Vérification d'identité (garde-fou anti-abus). La suppression et l'accès sont destructifs et révélateurs ; Happy Songs vérifie avant d'exécuter, et minimise les données de vérification — elles ne sont pas réaffectées à d'autres fins et ne sont jamais plus sensibles que les données initialement collectées.

• Principal. L'identifiant de compte est le numéro de téléphone du Client ; la vérification se fait par code à usage unique envoyé à ce numéro (via Twilio). Cela est proportionné et en libre-service.
• Renforcement de session (session step-up). Une session in-app déjà authentifiée peut re-confirmer au moyen d'un nouveau code à usage unique ou d'un déverrouillage biométrique de l'appareil.
• Repli (numéro perdu, cas limites). Vérification manuelle par l'opérateur confidentialité au moyen d'un ensemble limité de faits non sensibles et spécifiques au compte. Aucune donnée sensible n'est jamais requise.
• Demandes concernant un mineur. Le Client vérifie son propre compte ; il n'existe pas d'étape distincte d'identité de l'enfant, car un mineur ne détient jamais de compte. Une demande qui concerne une personne non liée au compte du demandeur est refusée et journalisée.
• Échec de la vérification. Ne pas divulguer et ne pas supprimer ; journaliser la tentative ; répondre que l'identité n'a pas pu être vérifiée et comment réessayer, sans révéler si le compte existe (afin de prévenir l'énumération).

8. Mineurs — droits exercés par le parent ou le tuteur légal

Happy Songs est un service exploité par le Client : un mineur ne s'inscrit jamais, n'exploite jamais, ne paie jamais, ne fournit jamais de données et ne dépose jamais de demande ; le Client adulte est le seul utilisateur. Il s'agit d'un modèle de traitement licite, et non d'une exemption de protection de l'enfance. Happy Songs ne fait pas de marketing auprès des enfants, ne leur adresse pas de publicité, ne les suit pas, ne les profile pas, ne collecte pas de données auprès d'eux, et ne permet pas sciemment à un enfant d'exploiter le compte. Dans la mesure où le service peut être consulté par un enfant, cela est traité de manière proportionnée — en ne faisant pas de marketing auprès des enfants et en limitant les données relatives à un mineur à un prénom fourni par le Client adulte avec consentement — et non en concevant une interface utilisateur destinée à l'enfant. Les protections de suppression parentale et de minimisation des données de la version amendée de la règle COPPA (COPPA Rule) s'appliquent à ce prénom, et la présente procédure ne les restreint pas.

Un accès accessoire par un enfant sous la supervision d'un parent ne fait pas de Happy Songs un service dirigé vers les enfants. Comme pour toute application grand public, un Client adulte peut laisser un enfant écouter une chanson sur l'appareil de l'adulte ; cette écoute accessoire et supervisée ne constitue pas une « utilisation » ou un « accès » du service par un enfant en tant qu'utilisateur, et elle ne transforme pas un service exploité par un adulte en un service dirigé vers les enfants — pas plus qu'elle ne confère à Happy Songs une « connaissance effective » (actual knowledge) qu'elle collecte des informations personnelles auprès d'un enfant — au sens de la version amendée de la règle COPPA (COPPA Rule). Trois faits affirmatifs sur la façon dont le produit est conçu tiennent cette ligne : (1) Happy Songs ne construit aucun profil de l'enfant — elle ne détient que le prénom fourni par l'adulte ; (2) Happy Songs ne dirige aucune fonctionnalité, aucun écran, aucun contenu, aucun personnage ni aucun message vers un enfant — il n'y a pas de connexion d'enfant, pas de mode destiné à l'enfant, et rien qui invite un enfant à agir, à gagner ou à effectuer une transaction ; et (3) Happy Songs ne collecte aucune donnée auprès de l'enfant — chaque saisie est fournie par le Client adulte, et le compte est exploité par lui. La limite honnête, que la présente procédure ne surestime pas au-delà : le prénom d'un mineur est traité, avec le consentement parental de l'adulte, et Happy Songs continue néanmoins de ne pas faire de marketing auprès d'un enfant, de ne pas lui adresser de publicité, de ne pas le suivre ni le profiler. Si une future fonctionnalité venait à s'adresser à un enfant ou à être exploitée par un enfant, cela modifierait cette analyse, et Happy Songs réévaluerait avant sa mise en service.

• La seule information que Happy Songs détient au sujet d'un mineur est le prénom du mineur — fourni par le Client en tant que prénom de destinataire — et ce prénom tel qu'il apparaît dans les paroles et l'audio de la chanson. Happy Songs ne détient aucun nom de famille, surnom, âge, date de naissance, profil, localisation précise, ni donnée relevant de catégories particulières d'un quelconque mineur.
• Lorsque le Client fournit le prénom d'un mineur, le Client déclare et garantit qu'il est le parent ou le tuteur légal de ce mineur et consent au traitement pour le compte de l'enfant.
• Le Client exerce tout droit sur les données d'un mineur : accès à, rectification de et effacement de l'enregistrement du destinataire et de toute chanson ou donnée dérivée faisant référence à ce prénom. La suppression du compte supprime tous ces enregistrements ; le Client peut également supprimer un enregistrement de destinataire individuel sans supprimer l'ensemble du compte, via le gestionnaire in-app.
• Les données d'un mineur sont traitées comme une cible prioritaire dans la cascade : purgées en premier, sans stationnement en suppression douce (soft-delete) au-delà de ce qui est techniquement inévitable, et seule une clé de suppression minimisée est conservée.
• Conformément à la version amendée de la règle COPPA (COPPA Rule), les données d'un mineur ne sont jamais conservées indéfiniment ; les exceptions de conservation de la Section 11 sont lues de la manière la plus étroite pour les données d'un mineur, et le Calendrier de conservation des données (D17) impose un plafond affirmatif d'inactivité afin que rien ne soit conservé « pour toujours ».

9. Cascade de suppression (côté serveur) — ce qui est purgé, et où

Sur une suppression de compte vérifiée, le moteur exécute la cascade ci-dessous. Chaque cible comporte une action de propriétaire (owner action), un mécanisme et une vérification d'achèvement. Une suppression n'est pas « terminée » tant que chaque cible ne retourne pas un succès ou une exception licite documentée (Section 11).

9.1 Magasin de données principal (Supabase — système de référence)

Les enregistrements de transaction, d'abonnement et fiscaux ne sont pas supprimés définitivement (hard-delete) par la cascade ; ils sont conservés sous une forme minimisée et à accès restreint au titre de la Section 11.

9.2 Stockage d'objets et CDN

Supprimer les objets audio (qui portent le filigrane Google SynthID) et les objets d'image de pochette du stockage d'objets, et purger les caches de périphérie (edge) du CDN de sorte que toute URL de re-téléchargement renvoie 404.

9.3 Sous-traitants

La Liste des sous-traitants (D11) est la source faisant foi pour les prestataires et les données que chacun reçoit ; le DPA (accord de traitement des données) de chaque prestataire doit contenir une obligation d'assistance à la suppression sur laquelle repose la présente cascade. Le moteur appelle le mécanisme de suppression de chaque prestataire et enregistre le résultat. Une minimisation par clé s'applique : le prénom réel du destinataire n'est envoyé qu'au fournisseur de musique, qui le chante ; les fournisseurs de paroles reçoivent un nom fictif (placeholder) et le nom réel est inséré localement. Cela réduit les endroits où un prénom réel est susceptible d'être conservé côté prestataire.

Une distinction que le moteur doit respecter : les données qui ont transité par un prestataire pour générer une chanson sont distinctes de la sortie stockée dans canciones. Happy Songs supprime la sortie stockée ; les entrées côté prestataire sont traitées selon chaque DPA. Les deux sont couvertes.

9.4 Purge du cache sur l'appareil

• Dans le cadre du modèle d'accès, une chanson est délivrée par accès in-app uniquement. La copie sur l'appareil est un cache hors ligne géré par l'App, et non un fichier appartenant au Client, et elle est à la portée de l'App.
• Sur une suppression de compte (ou sur la fin ou la révocation de l'accès), l'App arrête la lecture et purge le cache sur l'appareil, tandis que Happy Songs supprime les copies serveur et prestataire. Parce que la chanson n'est jamais livrée sous forme de fichier exportable, aucune copie du Client ne subsiste en dehors de l'App. Ceci est indiqué sur l'écran de pré-confirmation (Section 5) et dans le message de confirmation.
• Le cache sur l'appareil est hors du périmètre de chaque exception de conservation de la Section 11 : aucun fondement de conservation légale (legal-hold), fiscal, de sécurité ou de responsabilité (accountability) ne préserve jamais une copie lisible. Les exceptions n'atteignent que des enregistrements côté serveur minimaux et à accès restreint. Le cache est donc purgé intégralement et immédiatement lors de la suppression ou de la fin de l'accès, indépendamment de tout enregistrement côté serveur qui se poursuit licitement.
• Le cache est protégé par une mesure technique de protection ; extraire, copier, ré-héberger ou partager une chanson en dehors de l'App est interdit par les Conditions (D1/D7) et, lorsqu'une mesure technique de protection est contournée, peut engager les dispositions anti-contournement de 17 U.S.C. § 1201. Il s'agit d'une dépendance d'ingénierie : la protection n'est disponible que là où la mesure technique est effectivement mise en œuvre.

9.5 Sauvegardes

Les données supprimées peuvent persister dans des sauvegardes chiffrées et à accès contrôlé jusqu'à leur expiration selon la rotation des sauvegardes (Section 13). La suppression est enregistrée sur la liste de suppression de sorte que toute restauration réapplique la suppression et que les données ne soient jamais renvoyées en production. Le décalage des sauvegardes est divulgué dans l'Avis de confidentialité (D2).

10. Le moteur — admission → vérification → routage → exécution → confirmation → audit

Un système unique de billetterie/gestion de dossiers est la source faisant foi. Chaque demande, quel que soit le canal (Sections 5–7), devient un ticket unique avec une horloge SLA démarrée.

Cycle de vie.

1. Admission. Capturer le canal, le demandeur, le droit, le périmètre, la juridiction/résidence, l'identifiant et l'horodatage ; accuser réception automatiquement au demandeur.
2. Vérification. Identité selon la Section 7. L'horloge de l'action substantielle court ; les retards de vérification sont journalisés mais ne suspendent pas indéfiniment les délais légaux.
3. Classification et routage. Déterminer le type de droit et la juridiction pour en déduire le délai (Section 12) et les étapes requises (cascade de suppression, export d'accès, portabilité, retrait (opt-out)).
4. Exécution. Exécuter la cascade (Section 9) au moyen d'un orchestrateur qui appelle chaque cible et enregistre le succès ou l'échec par cible ; les échecs font l'objet de nouvelles tentatives avec temporisation (backoff) et alertent l'opérateur ; une cible qui ne peut pas s'achever est escaladée.
5. Application des exceptions. Enregistrer chaque exception de conservation et son fondement juridique (Section 11).
6. Vérification de l'achèvement. Contrôle automatisé que chaque cible dans le périmètre a retourné un succès ou une exception journalisée. Aucun ticket ne se clôture avec une cible ouverte.
7. Confirmation au demandeur. Dans le délai, indiquer ce qui a été supprimé (copies serveur et prestataire et le cache sur l'appareil), que l'accès in-app a pris fin, et ce qui est légalement conservé et pourquoi.
8. Audit. Entrée de journal immuable (id de demande, actions, cibles, horodatages, opérateur, exceptions), minimisée/anonymisée, conservée selon D17.

Rôles. Propriétaire des opérations confidentialité (Privacy Operations) = le responsable confidentialité de Happy Songs (privacy@happysongs.ai), avec un suppléant désigné au sein de la même équipe, joignable à privacy@happysongs.ai. L'ingénierie d'astreinte (on-call) est propriétaire de l'orchestrateur de cascade et des intégrations des sous-traitants. Le contact juridique de Happy Songs (legal@happysongs.ai) est propriétaire des déterminations d'exception, des conservations légales (legal holds) et de la configuration des délais.

Déclencheurs d'escalade. Identité invérifiable ; une API de suppression de sous-traitant échouant au-delà des nouvelles tentatives ; une conservation légale (legal hold) active ; une demande couvrant une exception ; une demande soumise à un délai plus strict que le délai par défaut ; activité frauduleuse ou d'énumération soupçonnée.

Surveillance. Un tableau de bord des tickets ouverts par rapport à leurs délais ; une alerte un nombre de jours configuré avant tout délai ; des indicateurs mensuels (volume, temps médian d'achèvement, pourcentage de respect des délais, exceptions). Objectif : zéro délai légal dépassé.

Automatisation. Les suppressions des Parcours A et B sont substantiellement automatisées (libre-service vers la file d'attente vers la cascade orchestrée). Les demandes DSAR/ARCO plus larges et les cas d'exception sont pilotés par un opérateur sur la même horloge.

11. Conciliation de conservation — ce qui peut légalement survivre à la suppression

La suppression n'est pas absolue. Le moteur applique, et les textes de confirmation reflètent, que Happy Songs ne conserve que le minimum nécessaire, pour une finalité déclarée, sous une forme à accès restreint, et le supprime lorsque le fondement expire. Les durées sont régies par le Calendrier de conservation des données (D17) ; les catégories ci-dessous sont les fondements qui peuvent survivre à une suppression de compte.

• Enregistrements de transaction, d'abonnement et fiscaux. Happy Songs est un service d'abonnement payant, actuellement proposé avec un accès promotionnel gratuit (aucune carte capturée et aucun prélèvement automatique pendant la promotion). Là où une transaction payante a eu lieu, elle passe uniquement par l'achat in-app Apple/Google (statut d'abonnement et reçus via RevenueCat), pour lequel les magasins d'applications sont le commerçant/vendeur officiel (merchant/seller of record) ; Happy Songs est l'éditeur et le responsable du traitement / responsable, non le commerçant officiel. Happy Songs conserve les enregistrements de transaction, d'abonnement et fiscaux pendant la durée légale. Happy Songs ne stocke pas de numéros de carte. Pendant l'accès promotionnel gratuit, il n'y a généralement aucun tel enregistrement à conserver.
• Enregistrements du Programme de parrainage (présenté dans l'App sous le nom « Familia Emprendedora »). Là où Happy Songs a effectué ou doit effectuer un versement de récompense de parrainage au Client adulte (le bénéficiaire est toujours le Client adulte ; un mineur n'est jamais participant ni bénéficiaire), Happy Songs conserve les enregistrements de versement, de reprise (chargeback-clawback) et de déclaration fiscale (CFDI/retenue au Mexique ; formulaire 1099 aux États-Unis) pendant la durée légale. Ce sont des enregistrements ordinaires de bénéficiaire adulte ; supprimer le compte n'efface pas une obligation fiscale. Le canal de versement est Wise, qui exécute son propre KYC et sa propre conservation.
• Identifiant publicitaire et attribution — Client adulte uniquement. L'identifiant publicitaire du Client adulte (IDFA / Android AD_ID) et les données d'attribution/de mesure du MMP sont conservés pendant une période glissante de 180 days puis purgés (via l'API de suppression du MMP), conformément au Calendrier de conservation des données (D17) Cat. P et à Privacy §12. Lors de la suppression du compte, l'enregistrement d'attribution adulte est purgé avant l'échéance de cette fenêtre et le retrait (opt-out) est propagé (retrait ATT / Do-Not-Sell-or-Share). Exclusion absolue des enfants (child carve-out) : aucune donnée d'enfant n'entre jamais dans ce pipeline d'identifiant/d'attribution, de sorte que rien concernant un mineur n'est jamais conservé ici.
• Liste d'attente d'accès anticipé / prospects du site web — données d'adultes uniquement. Les enregistrements de contact collectés par le formulaire « #waitlist » du site web (nom, e-mail et/ou téléphone, indicateur de consentement et horodatage, pays approximatif, CTA/source) résident dans le projet Supabase dédié happy-songs-growth (Section 9.3), sur la base légale du consentement, et sont utilisés uniquement pour contacter la personne au sujet de l'accès anticipé, du lancement et des mises à jour produit connexes, et pour gérer la liste d'attente. Ils sont conservés jusqu'à ce que la personne se désinscrive ou demande sa suppression, et par défaut au plus tard 24 mois après la collecte, puis supprimés. Le retrait du consentement, la désinscription ou une demande de suppression purge l'enregistrement avant l'échéance de cette fenêtre. Cette liste d'attente est dirigée vers les adultes ; Happy Songs n'y collecte pas sciemment d'informations sur un enfant, de sorte que l'exclusion absolue des enfants (child carve-out) est inchangée et rien concernant un mineur n'est conservé ici.
• Journaux de sécurité, d'abus et de fraude ; conservation légale (legal hold). Là où un litige, une enquête ou une demande d'une autorité est actif, les enregistrements pertinents sont préservés sous conservation légale (legal hold) (voir D15).
• Preuve de consentement et preuve de demande. Enregistrements de responsabilité (accountability) minimaux, anonymisés lorsque c'est possible.
• Clé de la liste de suppression. Une clé minimale et non sensible (Section 13).

Règles. Les données conservées sont minimisées, à accès restreint et verrouillées par finalité, et sont supprimées lorsque leur fondement expire. Les exceptions sont lues de la manière la plus étroite pour les données d'un mineur (version amendée de la règle COPPA (COPPA Rule)). Le cache sur l'appareil n'est jamais une cible de conservation et est toujours purgé (Section 9.4). Chaque exception appliquée à une demande spécifique est journalisée avec son fondement juridique et communiquée au demandeur (par exemple : « nous avons supprimé vos données ; nous sommes tenus de conserver certains enregistrements jusqu'à une date déterminée pour le motif juridique indiqué »).

12. Délais (États-Unis et Mexique)

Le délai du ticket est configuré à partir de la juridiction et de la résidence du demandeur. Happy Songs s'engage sur une norme interne mondiale et respecte ou surpasse chaque régime spécifique. Les écarts (deltas) pour d'autres juridictions sont traités dans le document distinct relatif aux écarts juridictionnels.

Notes. Pour les demandes d'État américain, respecter le retrait (opt-out) de la « vente »/du « partage » et le Global Privacy Control (D6). Pour le Mexique, l'autorité est la Secretaría de Anticorrupción y Buen Gobierno (à la suite de la dissolution de l'INAI) au titre de la Ley Federal de Protección de Datos Personales en Posesión de los Particulares de 2025 ; le canal en langue espagnole est requis.

13. Accès, rectification, portabilité, sauvegardes et suppression

• Accès et portabilité. Sur une demande vérifiée, fournir les données que Happy Songs détient au sujet du Client et les prénoms des destinataires fournis par le Client, dans un format structuré, couramment utilisé et lisible par machine (JSON ou CSV), dans le délai applicable. Dans le cadre du modèle d'accès, les chansons sont fournies sous forme d'accès in-app, et non de fichiers exportés ; l'export contient les enregistrements de données, non un fichier audio téléchargeable.
• La liste d'attente / les prospects du site web sont inclus dans le périmètre. Les processus d'accès, d'effacement, d'opposition et de retrait du consentement de la présente procédure atteignent les données de la liste d'attente d'accès anticipé / des prospects du site web détenues dans le projet Supabase happy-songs-growth (Sections 9.3 et 11) : une personne concernée qui s'est inscrite à la liste d'attente peut, à tout moment via privacy@happysongs.ai, retirer son consentement, se désinscrire, ou demander l'accès à cet enregistrement ou sa suppression, et le moteur le purge ou l'exporte en clé sur l'adresse e-mail et/ou le numéro de téléphone. Une suppression de compte/de données d'un Client purge également par recoupement tout enregistrement de liste d'attente correspondant. Cette liste d'attente est dirigée vers les adultes ; aucune donnée d'un mineur n'y est détenue (exclusion absolue des enfants).
• Rectification. Un numéro de téléphone, une adresse e-mail facultative ou un prénom de destinataire peut être corrigé, essentiellement en libre-service dans le profil.
• Liste de suppression. Lors de la suppression, stocker une clé minimale et non sensible (par exemple, un numéro de téléphone haché) marquant « supprimé — ne pas restaurer, ne pas recibler ». Elle est verrouillée par finalité et elle-même supprimée lorsqu'elle n'est plus nécessaire.
• Procédure de restauration. Toute restauration de sauvegarde doit réappliquer la liste de suppression avant que les données ne reviennent en production, de sorte qu'un sujet supprimé ne soit jamais ressuscité.
• Expiration des sauvegardes. Les données supprimées dans les sauvegardes expirent selon la rotation des sauvegardes de 35 jours (reflétée depuis D17 §6.4) ; ceci est divulgué dans D2.

14. Autres juridictions

La présente procédure énonce la base des États-Unis et du Mexique. Là où un Client ou une personne concernée se trouve dans l'Union européenne, au Royaume-Uni, au Brésil ou dans une autre juridiction latino-américaine, le document distinct relatif aux écarts juridictionnels fournit les délais supplémentaires ou plus courts, les spécificités de portabilité et d'objection, toute exigence de langue locale et tout acheminement vers un représentant local. Ces écarts s'ajoutent aux protections énoncées ici et ne les réduisent jamais.

15. Textes destinés au Client — exigences d'exactitude

Tous les écrans et messages doivent être véridiques et non manipulateurs : aucune incitation à la culpabilité ou à la perte pour conserver le compte, aucune dissimulation du chemin de suppression, et aucun faux « nous ne conservons rien » (des exceptions licites existent). Dans le cadre du modèle d'accès, il est exact de dire au Client que la suppression met fin à l'accès in-app et purge le cache sur l'appareil de sorte que plus rien de lisible ne subsiste, et qu'il n'y a aucune copie exportée à laisser subsister. Chaque confirmation indique, en langage clair : ce qui a été supprimé (serveur, prestataire et le cache sur l'appareil), que l'accès a pris fin, ce qui est légalement conservé et pourquoi, et le calendrier. Les textes respectent WCAG 2.2 AA (D10) et sont localisés en espagnol pour les résidents mexicains et les Clients servis en espagnol.

16. Cohérence et conciliation

La présente procédure doit demeurer cohérente avec, et s'en remet, sur leur propre objet, à : D2 (Avis de confidentialité — le menu des droits et le canal), D17 (Calendrier de conservation des données — chaque durée), D1/D7 (Conditions/EULA — la licence du modèle d'accès et l'anti-contournement), D9 (configuration des magasins — l'URL web de suppression et les déclarations Data Safety), et D11 (Liste des sous-traitants et DPA — les prestataires et leurs obligations d'assistance à la suppression).

Actions de conciliation signalées par la présente v0.2 (les documents apparentés sont antérieurs aux décisions verrouillées suivantes et doivent y être conformés) :

1. Minimisation au prénom uniquement. La présente procédure stocke, au sujet de la personne à laquelle une chanson est destinée, un prénom uniquement. Les projets apparentés (notamment D17 et D11) décrivent encore cet enregistrement comme « nom, surnom (apodo) et tranche d'âge » ; ils doivent être conformés à la norme du prénom uniquement. L'âge ou l'étape de vie n'est utilisé que sur le moment et n'est pas stocké.
2. Acteur = le Client. Le titulaire du compte est le Client adulte, non « le parent » en tant qu'opérateur générique. « Parent ou tuteur légal » n'est utilisé que là où le Client fournit le prénom d'un mineur et consent pour le compte de l'enfant.
3. Les paiements sont actifs. Happy Songs est un service d'abonnement payant actuellement en accès promotionnel gratuit ; le fondement de conservation transaction/abonnement/fiscal de la Section 11 est opérationnel (non « N/A »), et les numéros de carte ne sont jamais stockés — tous les frais d'abonnement passent par les achats in-app Apple/Google (via RevenueCat), pour lesquels les magasins d'applications sont le commerçant/vendeur officiel (merchant/seller of record) ; il n'y a pas de ventes web directes.
4. Les enregistrements du Programme de parrainage pour le bénéficiaire adulte (Section 11) sont conservés lors de la suppression ; un mineur n'est jamais bénéficiaire.
5. Posture d'attribution publicitaire adulte (v0.2). Le présent document a été concilié avec la posture d'attribution publicitaire adulte de la v0.2 : ATT côté adulte + IDFA / Android AD_ID avec un partenaire de mesure mobile (MMP ; prestataire sélectionné par la croissance, candidat Singular), et l'étiquette App Store « Data Used to Track You ». La suppression du compte se propage désormais en cascade vers le MMP (via son API de suppression), Meta (Meta Pixel/Ads) et Google Ads avec propagation du retrait ATT / Do-Not-Sell-or-Share / opt-out (Section 9.3) ; les cibles du retrait (opt-out) de vente/partage sont corrigées en conséquence (Section 4) ; et l'élément de conservation de 180 days de l'identifiant publicitaire / de l'attribution MMP réservé aux adultes est ajouté (Section 11, selon Privacy §12 et Data-Retention Cat. P). L'exclusion des enfants (child carve-out) est absolue : aucune donnée d'enfant n'entre jamais dans le pipeline publicité / IDFA / MMP / attribution, de sorte qu'aucun de ces flux ne touche jamais les données d'un mineur.
6. Liste d'attente d'accès anticipé / prospects du site web (v0.2.3). Les données de contact du formulaire « #waitlist » du site web — nom, e-mail et/ou téléphone, indicateur de consentement et horodatage, pays approximatif (cf-ipcountry de Cloudflare, uniquement pour l'acheminement à des fins de conformité juridique), et CTA/source — sont détenues dans un projet Supabase happy-songs-growth dédié (hébergé aux États-Unis, INSERT uniquement, séparé du magasin de données principal de l'App), sur la base légale du consentement, à des fins d'usage marketing/contact uniquement. La présente procédure concilie désormais ce magasin dans le cadre de suppression + DSAR : il est ajouté à la cascade de suppression / des sous-traitants de sorte qu'une suppression de compte/de données et une demande autonome de désinscription/suppression de la liste d'attente atteignent et purgent chacune le prospect correspondant (Section 9.3) ; un élément de conservation avec un plafond de 24 mois est ajouté (Section 11) ; et les processus d'accès/effacement/opposition/retrait du consentement sont confirmés comme le couvrant via privacy@happysongs.ai (Section 13). La liste d'attente est dirigée vers les adultes et ne contient que des données d'adultes ; l'exclusion absolue des enfants (child carve-out) est inchangée (aucune donnée d'enfant n'entre jamais dans ce magasin de prospects).

17. Points ouverts pour un conseil juridique agréé (US / MX)

1. Délais ARCO du Mexique — confirmer les termes de réponse et d'effet au titre de la Ley Federal 2025 et de son reglamento en attente, ainsi que l'acheminement actuel vers l'autorité (Secretaría de Anticorrupción y Buen Gobierno).
2. SLA d'achèvement mondial — confirmer 30 days en tant qu'engagement interne au regard de chaque obligation d'État américain et COPPA.
3. Repli de vérification — approuver l'ensemble de corroboration en cas de numéro perdu (ne doit pas sur-collecter).
4. Couverture de suppression des sous-traitants — confirmer que chaque DPA (D11) contient une clause d'assistance à la suppression et un point de terminaison opérationnel ; documenter les limites de conservation de Twilio, Vertex/Lyria, Anthropic, OpenAI et Nano Banana (pochette) (y compris la conservation fondée sur un signalement (flag)). Nano Banana doit être accédé via Vertex AI / un niveau d'API payant, PAS via l'API grand public Gemini Dev (qui interdit les services destinés aux moins de 18 ans) — la même raison pour laquelle Lyria s'exécute sur Vertex.
5. Fenêtre de grâce de suppression douce (soft-delete) — confirmer nulle ou ≤ 72 hours ; ne doit pas dépasser un quelconque délai légal.
6. Fenêtre de rotation des sauvegardes — confirmer 35 days et aligner D2/D17.
7. Politique de demandes répétées/excessives et toute règle de frais — confirmer selon le régime.
8. Conformité au prénom uniquement — confirmer que les descriptions de catégories de D17 et D11 sont mises à jour pour supprimer le surnom et la tranche d'âge, conformément à la Section 16(1).