Contrat de sous-traitance

En un coup d'œil

Hébergement et lieu de stockage des données

Bases de données de l'application, hébergement et surveillance des erreurs : Allemagne. Cloudflare KV (application Eltern) : UE. E-mail technique (Brevo) : hébergement en France/Allemagne (OVH), stockage en Belgique (Google Cloud). Boîte e-mail : Pays-Bas. Les données principales sont exclusivement hébergées dans l'UE. Exceptions présentant un lien avec un pays hors UE : notifications push Apple/Android, cartes Wallet, la génération optionnelle d'images par IA (point de terminaison mondial, voir annexe C) ainsi que les sites Internet publics des établissements (Cloudflare Pages, diffusion mondiale).

Chiffrement

TLS 1.2/1.3 pour chaque transmission. HTTPS uniquement. Aucune interface non chiffrée.

Séparation et pseudonymisation

Les données de chaque établissement sont techniquement séparées de celles de tous les autres. Seuls les utilisateurs autorisés de l'établissement concerné y ont accès. L'application Eltern fonctionne sans comptes utilisateurs : les représentants légaux n'utilisent qu'un code enfant pseudonyme. Sur demande, l'ensemble du logiciel fonctionne avec des codes au lieu de noms réels ; les fonctions d'IA peuvent être limitées à des identifiants ou désactivées, et le Träger peut fixer un plafond à cet effet (annexe C). Détails techniques : §5.

Modifications du contrat

La partie contractante est le Träger dès que l'établissement est rattaché à un compte Träger ; la confirmation contractuelle s'effectue alors uniquement là (sur ordinateur, pas sur le terminal d'enregistrement). Les établissements rattachés peuvent prendre connaissance des documents une fois, puis ne voient plus qu'une indication. Sans rattachement à un Träger, l'établissement confirme lui-même. Modifications substantielles : e-mail le jour de la mise à disposition, un rappel au bout de deux semaines, affichage dans le tableau de bord ; le nouveau traitement reste techniquement bloqué jusqu'à confirmation. Le logiciel reste utilisable dans l'intervalle. Précisions de la description et des TOM sans nouveau point de données sur la même infrastructure : immédiatement. Nouveaux sous-traitants ultérieurs : techniquement bloqués jusqu'à confirmation (§5, §9, §12).

entre

[Client / Träger / Établissement] (« responsable du traitement »)

et

997 Ventures UG (haftungsbeschränkt)
Sonnenhof 13, 67677 Enkenbach-Alsenborn
(ci-après : « sous-traitant »)

§1 Objet et durée du traitement

(1) Le sous-traitant traite des données à caractère personnel pour le compte du responsable du traitement dans le cadre de la mise à disposition du logiciel de gestion d'établissements d'accueil du jeune enfant (KiTa) app.bienenstock-kita.de.

(2) Le traitement commence à la conclusion du contrat d'utilisation du logiciel et vaut pour la durée d'utilisation du logiciel par le responsable du traitement. Le contrat d'utilisation du logiciel est conclu par la confirmation, par case à cocher, des documents juridiques (AGB, présent AVV, informations sur la protection des données) par la personne signataire (détails au §12). Le contrat d'utilisation du logiciel comprend expressément aussi le forfait gratuit.

§2 Nature et finalité du traitement

Le traitement comprend les opérations concrètes suivantes :

• Enregistrement et sortie en temps réel des enfants par code QR et du personnel par identifiant/pseudonyme
• Calcul automatique de la capacité sur la base des données de présence enregistrées (déclencheurs de base de données)
• Synchronisation en temps réel des données de présence via une connexion WebSocket (Supabase Realtime)
• Gestion des données de base, des affectations aux groupes et des modèles de prise en charge
• Réception et traitement des désinscriptions, annulations de repas et déclarations de récupération via l'API Eltern
• Réception et traitement des déclarations du personnel via l'application Personnel (temps de travail, enregistrement en télétravail, déclarations d'absence et de maladie, communication d'équipe ; annexe 2B)
• Mise à disposition d'un chat interne du personnel (accessible via l'application Personnel, y compris sur des appareils privés ; annexe 2B) avec suppression automatique après le délai du §3
• Fonctions d'IA selon l'annexe C : activables individuellement ; ce que l'IA apprend sur des personnes est régi par le niveau de protection des données IA, que le Träger peut plafonner
• Publication du site Internet de l'établissement créé avec le constructeur de sites, sous kitas.bienenstock-kita.de via Cloudflare Pages (réseau de diffusion mondial, car accessible publiquement). Le responsable du traitement détermine seul le contenu et les images, y compris les photos téléchargées par l'établissement ; pour la publication de photos de personnes, en particulier d'enfants, il recueille les consentements nécessaires
• Envoi de notifications push aux représentants légaux (application Eltern) et au personnel (application Personnel) via Expo et le worker push Cloudflare, détails à l'annexe 2A §2 et à l'annexe 2B §2
• Envoi de documents aux représentants légaux par e-mail (adresse figurant sur la fiche enfant), journal d'envoi inclus (quel document, quand, à quelle adresse)
• Décompte facultatif des repas par enfant : établissement d'un justificatif pour une période et envoi par e-mail à l'adresse des représentants légaux enregistrée sur la fiche enfant, déclenchable dans le compte Träger et dans la gestion de l'établissement ; enregistrement des caractéristiques de facturation et du journal d'envoi
• Paiements facultatifs des parents (activés par le responsable du traitement) : motifs et postes de paiement par enfant avec code d'objet, affichage du montant, du compte bénéficiaire et du GiroCode dans l'application Eltern, enregistrement des paiements en espèces avec le sigle de la personne qui encaisse (visible sur le justificatif destiné aux représentants légaux), confirmation « virement effectué » par les représentants légaux, notification « paiement reçu » par push, dans la mesure où l'application Eltern est utilisée et où le push est autorisé sur l'appareil ; cotisations de membre facultatives avec profils de paiement par famille et destinataire de facture facultatif
• Connexion bancaire (facultative) : consultation des mouvements du compte de l'établissement auprès de la banque choisie par le responsable du traitement (par ex. Qonto ; d'autres banques à venir), en lecture seule et au moyen d'une autorisation d'accès accordée par le responsable du traitement (OAuth), pour l'affectation des paiements parentaux entrants ; à défaut, lecture d'un relevé de compte (CAMT.053). La banque est partenaire contractuel du responsable du traitement et non sous-traitant ultérieur. Sont consultés pour chaque mouvement le nom, l'IBAN, le motif, le montant et la date d'opération. Sont enregistrés uniquement le montant, la date d'opération, le motif et l'identifiant de mouvement de la banque, et uniquement pour les entrées affectées ou vraisemblablement affectables et pour les sorties que le responsable du traitement affecte à un motif ; le nom et l'IBAN ne sont jamais enregistrés. Les sorties des 60 derniers jours ne sont affichées pour sélection que (nom et IBAN abrégé du bénéficiaire), sans être enregistrées. Tous les autres mouvements sont supprimés. Les identifiants d'accès à la banque sont enregistrés chiffrés et supprimés lors de la déconnexion
• Recueil de consentements et de procurations des représentants légaux par e-mail confirmé envoyé à l'adresse enregistrée par l'établissement (libérations, procuration de récupération, enregistrement d'un entretien avec les parents) via une page publique de confirmation ; enregistrement du texte confirmé et de l'horodatage comme preuve
• Gestion des libérations par enfant (par exemple photos, crème solaire) avec preuve de chaque octroi et de chaque retrait ; affichage dans l'application Eltern sans possibilité de modification
• Photo facultative de l'enfant pour la reconnaissance par le personnel, uniquement avec la libération active « Photo de l'enfant sur les appareils de la KiTa » ; sans IA ; suppression en cas de retrait
• Gestion des personnes autorisées à venir chercher chaque enfant, déclaration de la personne venant chercher l'enfant pour un jour via l'application Eltern, procuration de récupération pour les nouvelles personnes par e-mail confirmé, marquage des personnes nouvellement déclarées jusqu'à la vérification d'identité et preuve de remise dans la vue par groupe (annexe 5 §3)
• Demandes d'entretien entre représentants légaux et établissement avec propositions de rendez-vous, e-mail de confirmation et rappels ; rendez-vous du personnel pour les participants
• Enregistrement d'un entretien avec les parents uniquement avec un consentement préalablement enregistré ; évaluation selon l'annexe C
• Calendrier avec des rendez-vous pour l'établissement, les groupes ou les modèles de prise en charge, confirmations et annulations par enfant, coûts facultatifs par enfant et publication facultative de la date et du titre sur le site Internet de l'établissement
• Réservation de salles de l'établissement
• Envoi du courrier QR d'un enfant par e-mail à l'adresse parentale enregistrée, selon le réglage du responsable du traitement, avec le mot de passe parents de l'établissement
• Messages de l'établissement à son Träger et réponses du Träger ; copie facultative par e-mail à une liste de diffusion définie par l'établissement ; transmission de messages individuels par le Träger par e-mail à des destinataires qu'il choisit, avec journal
• Portail d'inscription facultatif d'un Träger pour des places en KiTa : candidatures des représentants légaux avec confirmation de l'adresse e-mail, traitement exclusivement par le Träger, suppression automatique aux délais mentionnés au §8
• Envoi et réception d'e-mails techniques via Brevo (Sendinblue) dans les fonctions du logiciel (par ex. invitations, messages système) ; boîte e-mail chez Zoho (Pays-Bas)
• Surveillance technique des erreurs via Sentry (région UE Francfort), y compris Session Replay de l'application web (masqué ; détails au §5 n° 9) ; en complément, journaux d'erreurs propres à l'application dans la base de données de la KiTa, pouvant contenir un identifiant de personne dans le contexte
• Établissement d'évaluations et de rapports, y compris export Excel
• Établissement d'évaluations des temps de personnel pour la direction et le Träger (par établissement et à l'échelle du Träger), export inclus, et consultation par les salariés de leurs propres temps
• Mise à disposition de comptes Träger : consultation des données des établissements rattachés au Träger ; invitation d'utilisateurs supplémentaires au compte Träger, qui obtiennent après acceptation de l'invitation l'accès à ces données d'établissement et la possibilité de les modifier
• Envoi de messages de groupe au sein du logiciel
• Accès facultatif pour le fournisseur de repas : le fournisseur de repas désigné par le responsable du traitement peut consulter les indications alimentaires (y compris les allergies et régimes alimentaires) ; le fournisseur est destinataire sur instruction du responsable du traitement, et non sous-traitant ultérieur du sous-traitant
• Sondages dans l'application Eltern : enregistrement du vote avec identifiant d'appareil, afin qu'un seul vote par appareil soit compté
• Conservation des actions d'enregistrement rejetées, qui restent volontairement conservées après la suppression de la personne concernée (conservation documentée)

Finalités du traitement :

• Organisation et documentation de l'exploitation de l'établissement au moyen du logiciel
• Enregistrement en temps réel et documentation juridique de la capacité pour remplir les obligations légales (selon le droit national de l'État membre du responsable du traitement)
• Communication avec les représentants légaux via l'application, les notifications push et l'envoi de documents par e-mail
• Indications au personnel via l'application Personnel (chat, feu, temps de travail), dans la mesure où le push est activé
• Planification du personnel, enregistrement du temps de travail et reporting des temps de personnel (par établissement et à l'échelle du Träger)
• Pilotage de l'alimentation, y compris information facultative du fournisseur de repas désigné par le responsable du traitement, ainsi que décompte facultatif des repas avec envoi des justificatifs aux représentants légaux
• Traitement des paiements parentaux et des cotisations de membre, y compris affectation des paiements entrants
• Recueil et documentation des consentements, procurations et de leur retrait (annexe 5)
• Assistance de l'établissement dans la documentation des autorisations de récupération et des remises (annexe 5) ; la décision de remise appartient à l'établissement
• Organisation de rendez-vous, d'entretiens avec les parents et de salles
• Communication entre l'établissement et le Träger
• Attribution de places d'accueil par le Träger (portail d'inscription)
• Assistance par l'IA : finalités selon l'annexe C §2 (dans la mesure du niveau et des interrupteurs)
• Correction technique des erreurs et assurance qualité
• Avis des représentants légaux recueilli par sondages (un vote par appareil)

§3 Nature des données et personnes concernées

Catégories de données traitées, par groupes de personnes concernées :

Principe de minimisation des données - champs obligatoires et facultatifs (art. 5 al. 1 lit. c RGPD)

Le nom réel de l'enfant n'est pas obligatoire ; s'il reste vide, « Kein Name » est affiché. Un fonctionnement avec des codes ou des surnoms est prévu. Les indications obligatoires des tableaux sont nécessaires au check-in, à la capacité et au contrat de prise en charge. Les indications facultatives ne sont traitées que si le responsable du traitement les saisit ou si la fonction correspondante est activée (art. 5 al. 1 lit. c RGPD).

Enfants

Les champs de statistique ainsi que les catégories particulières au sens de l'art. 9 RGPD figurent dans la colonne Facultatif et ne sont collectés que dans la mesure où l'établissement les saisit (statistique officielle selon le droit national de l'État membre du responsable du traitement, ou, sur le plan opérationnel, allergies et indications alimentaires). Les données au sens de l'art. 9 sont traitées séparément et avec un niveau de protection renforcé. La base juridique au sens de l'art. 9 al. 2 RGPD est assurée par le responsable du traitement. Lorsque l'accès du fournisseur est activé, les allergies et indications alimentaires sont transmises au fournisseur de repas désigné par le responsable du traitement (destinataire sur instruction, non sous-traitant ultérieur).

Personnel

Les champs de statistique du personnel figurent dans la colonne Facultatif et ne sont collectés que dans la mesure nécessaire à une statistique officielle. Chat et Pinnboard : voir ci-dessous, sous Messages.

Motifs d'absence du personnel. Les absences (y compris celles résultant des arrêts maladie, du départ anticipé au terminal et de la question hebdomadaire) sont enregistrées avec un motif issu d'un catalogue fixe et une note facultative : maladie, enfant malade, rendez-vous médical, interdiction d'exercer, protection de la maternité, congé parental, congé pour soins, résiliation, absence prolongée, grève, congé, congé spécial, congé sans solde, formation continue, récupération d'heures supplémentaires, dispense, jour de récupération ou de conversion, temps partiel (jour libre), course de service, déplacement professionnel, ainsi que texte libre ; pour certains services, s'ajoutent « non excusé » et « annulé ». La maladie, l'enfant malade, le rendez-vous médical, l'interdiction d'exercer et la protection de la maternité sont des données relatives à la santé ; la grève peut permettre de déduire une appartenance syndicale (art. 9 RGPD) ; le congé pour soins et la résiliation sont particulièrement dignes de protection.

Qui voit les motifs. La personne elle-même voit ses propres motifs dans l'application Personnel et lors du check-out au terminal. Les motifs d'autres personnes n'apparaissent que dans la gestion de l'établissement (planification du personnel avec mot de passe administrateur ; déclarations et rapports avec mot de passe du personnel), dans l'espace Träger ainsi que dans les rapports, exports et impressions (rapport journalier, planning de service, affiche hebdomadaire). Les tablettes d'enregistrement et de groupe ainsi que l'application Personnel affichent les absences d'autres personnes sans motif. Le responsable du traitement décide qui obtient l'accès à ces espaces et impressions.

Représentants légaux (via l'application Eltern et l'API) :

• Identifiant d'enfant pseudonymisé (code enfant)
• Désinscriptions (enfant, date ; sans motif), annulations de repas, déclarations de récupération, y compris la personne venant chercher l'enfant, date et heure
• Adresses e-mail et numéro de téléphone des représentants légaux figurant sur la fiche enfant (adresse du Träger pour les documents et les justificatifs de décompte des repas ; adresse et téléphone de l'établissement pour le courrier QR, les consentements et les confirmations d'entretien), ainsi que le journal d'envoi
• Langue des représentants légaux par enfant (saisie par l'établissement ou choisie dans l'application Eltern) pour les traductions selon l'annexe C §3 n° 17
• Consentements par e-mail confirmé : texte confirmé, horodatage, origine ; adresse du destinataire et valeur de contrôle du lien dans la demande uniquement jusqu'à la confirmation ; le lien est valable une heure, après quoi les deux sont supprimés dans l'heure suivante (§8 al. 8) ; pour les demandes de libération et d'enregistrement, en outre une entrée dans le journal d'envoi (enfant, adresse, type, horodatage, compte déclencheur)
• Demandes d'entretien (sujet, destinataire, rendez-vous choisi), réponses aux rendez-vous, confirmations de participation et signalements « virement effectué » pour des postes de paiement
• Si la connexion bancaire est active : motif, montant et date d'opération des entrées affectées et des sorties affectées par le responsable du traitement ; nom et IBAN du payeur ou du bénéficiaire uniquement lors de la consultation, non enregistrés (§2)
• Pour l'enregistrement d'un entretien avec les représentants légaux : nom et rôle de la personne consentante, image de la signature ou e-mail confirmé, texte du consentement
• Votes aux sondages avec identifiant d'appareil (un vote par appareil)
• Réception de notifications push dans l'application Eltern, dans la mesure où elles sont autorisées sur l'appareil et utilisées par l'établissement : messages de groupe, changements de statut du feu (Ampel), rappels de rendez-vous, rendez-vous d'entretien, nouvelles entrées du carnet de l'enfant et réceptions de paiements ; détails à l'annexe 2A §2

Personnel (en plus via l'application Personnel ; annexe 2B) :

• Déclarations de temps, déclarations d'arrivée et de départ, arrêts maladie
• Messages du chat interne du personnel (contenu, horodatage, nom ou sigle de l'expéditeur)
• Réception de notifications push dans l'application Personnel (uniquement avec l'accord sur l'appareil et uniquement pour les fonctions activées) : changements de statut du feu, chat d'équipe, appels, indications automatiques sur le temps de travail et rappels de rendez-vous ; détails à l'annexe 2A §2 et à l'annexe 2B §2

Comptes utilisateurs (tous les rôles) :

• Adresse e-mail, données d'authentification (JWT Supabase Auth), indicateurs de rôle
• Confirmation de l'AVV et des AGB : nom, e-mail et rôle de la personne qui confirme, horodatage, numéro de version du document concerné, y compris annexes, version précédemment confirmée ; confirmation du contrat dans le compte Träger ou, sans rattachement à un Träger, dans l'administration de la KiTa. En outre, prise de connaissance unique par la direction d'un établissement rattaché (pas de seconde partie contractante, §12)
• Compte Träger : rattachement à des établissements ; invitations d'utilisateurs supplémentaires (personnes invitantes, personnes invitées, horodatage, statut). Après acceptation de l'invitation, ces utilisateurs obtiennent l'accès et la possibilité de modifier les données des KiTas rattachées au Träger
• Échanges entre l'établissement et le Träger : messages, réponses, état du traitement ; liste de diffusion e-mail de l'établissement (dix adresses au maximum) ; journal de chaque transmission par le Träger (destinataire, indication), que seul le Träger voit

Données de journalisation (logs) :

• Chaque enregistrement d'arrivée et de départ avec horodatage, type de personne et capacité calculée ; pour l'enfant, en plus, le facteur d'encadrement ; pour le personnel, en plus, les indicateurs de lieu de travail (télétravail, sortie, hors établissement)
• Actions d'enregistrement rejetées (discarded_actions) : sont volontairement conservées après la suppression de la personne concernée (conservation documentée, pour la traçabilité des actions du terminal). Suppression ou restitution avec le reste du stock contractuel selon le §8
• Journaux d'erreurs propres à l'application (error_logs), dans la mesure où le contexte de l'erreur comporte un identifiant de personne ; stockage sur des serveurs allemands, séparé de la surveillance des erreurs via Sentry (annexe 1, y compris Session Replay)
• Journal d'envoi aux représentants légaux (parent_mail_log) : quel document, quel justificatif de décompte des repas ou quel message adressé à une famille a été envoyé, à quel moment et à quelle adresse
• Réponses des représentants légaux aux messages adressés à une famille : action choisie et horodatage (annexe 4 §5 al. 7)
• Corrections d'horaires : motif (catégorie et texte libre obligatoire), personne qui corrige avec son adresse e-mail, ainsi que les valeurs avant et après la correction ; la vue quotidienne transmise au Träger ne contient que des pseudonymes ou sigles et la catégorie de base, sans noms ni texte libre
• Protection contre le devinage des mots de passe : à chaque tentative échouée, une valeur de contrôle chiffrée (HMAC) du réseau et de la valeur erronée, jamais l'adresse ou la valeur elle-même ; suppression automatique au bout d'une heure
• Preuves des consentements des représentants légaux (nature, texte, horodatage, origine)

Messages :

• Messages de groupe (contenu, horodatage, affectation au groupe)
• Chat interne du personnel : contenu, horodatage, expéditeur (nom ou sigle) ; suppression automatique après un délai d'un à sept jours choisi par le responsable du traitement (réglage par défaut : un jour, suppression à minuit dans le fuseau horaire de l'établissement) ; les messages du Pinnboard restent enregistrés durablement, jusqu'à leur suppression manuelle ou la fin de la relation contractuelle ; selon les consignes d'utilisation, non destinés aux données sensibles ou aux catégories particulières de données à caractère personnel (art. 9 RGPD)

Rapports de groupe, rapports journaliers et signalements :

• Rapports de groupe (rapport journalier d'un groupe), notes sur des enfants individuels (carnet de l'enfant) et signalements en texte libre, saisis ou dictés ; stockage sur des serveurs allemands. Les représentants légaux ne voient une entrée que si le responsable du traitement active l'affichage dans l'application Eltern (réglage par défaut : désactivé) et si le personnel publie explicitement l'entrée ; ils reçoivent alors une notification push sans contenu. La dictée peut être désactivée (réglage par défaut : activé). Les textes libres peuvent contenir des catégories particulières au sens de l'art. 9 RGPD (annexe 4).

Métadonnées de la KiTa (facultatives, dans la mesure où elles sont configurées) :

• Seuils (marge, feux jaune et rouge), délais d'annulation des repas, horaires d'ouverture, jours de fermeture, slug de l'établissement, verrouillages de sections de l'établissement (mots de passe administrateur, personnel, parents et fournisseur : mots de passe communs qui bloquent certains domaines du logiciel, et non des données d'accès personnelles ; enregistrés en clair pour que l'établissement puisse les consulter et les transmettre, vérifiés par comparaison à temps constant et freinés contre les essais systématiques), exigences du Träger (dotation horaire de la direction, encadrement de stagiaires), configuration des pauses obligatoires, mot de passe du fournisseur (opt-in)

Autres personnes concernées (dans la mesure où la fonction correspondante est utilisée) :

• Personnes autorisées à venir chercher l'enfant : nom, lien avec l'enfant, origine de l'indication (établissement ou représentants légaux), texte de la procuration et horodatage de la confirmation, date de vérification de la pièce d'identité (pas de numéro de pièce d'identité)
• Candidats à une place d'accueil (portail d'inscription du Träger) : prénom et date de naissance de l'enfant, nom, adresse e-mail et, facultativement, numéro de téléphone des représentants légaux, établissements souhaités et ordre de préférence, volume de prise en charge, début souhaité, état du traitement, note interne du Träger
• Destinataires des factures de cotisations de membre : nom, adresse postale, adresse e-mail
• Payeurs de virements à l'établissement et bénéficiaires de virements de l'établissement (uniquement si la connexion bancaire est active) : nom et IBAN uniquement lors de la consultation ; ne sont enregistrés que le motif, le montant et la date d'opération des entrées affectées et des sorties affectées par le responsable du traitement
• Participants aux entretiens enregistrés avec les représentants légaux : nom, rôle, horodatage et forme du consentement (signature ou confirmation par e-mail), ainsi que ce qui a été dit pendant l'entretien (annexe C §3 n° 11)
• Destinataires de copies e-mail et de transferts dans les échanges entre l'établissement et le Träger : adresse e-mail

Fonctions d'IA (selon les paramètres par défaut et les interrupteurs ; détails à l'annexe C) :

Les fonctions d'IA peuvent être activées et désactivées individuellement ; si une fonction est désactivée, les catégories de données correspondantes ne sont plus traitées. Le Träger peut bloquer des fonctions et plafonner le niveau de protection des données IA. Selon le paramétrage, les données suivantes sont traitées :

• Saisies en texte libre des utilisateurs, telles qu'elles ont été écrites (l'interface invite à ne pas saisir de données de santé ; détails sur les champs de texte libre à l'annexe 4)
• Désignations d'organisation : nom de l'établissement, noms des groupes et des modèles de prise en charge
• Indicateurs (feu, capacité, présence par catégorie, prévu et réel, seuils, horaires d'ouverture)
• Journaux par personne (présence, événements, plans de service et de pause, horaires contractuels, comptes d'heures, jours d'absence), selon le niveau de protection des données IA, avec identifiants, avec noms du personnel ou avec noms du personnel et des enfants ; motifs d'absence uniquement sous forme de nombre
• Enregistrements vocaux (dictée, assistant e-mail, entretien avec les représentants légaux), exclusivement pour le traitement ; l'audio n'est jamais conservé durablement
• Résultats d'entretiens avec les représentants légaux (rapport, tâches, version destinée aux parents) et de l'assistant e-mail (e-mails types, consigne, brouillon)
• Consentements à l'enregistrement d'entretiens (nom, rôle, horodatage, version du texte, signature ou confirmation par e-mail)
• Photos pour le plan des locaux, le brouillon de manuel et les thèmes de danger, ainsi que les propres images de style de la direction pour le site Internet (compréhension d'images sur le point de terminaison UE) ; le générateur d'images ne reçoit qu'une description d'image sans lien avec une personne
• Informations du site Internet fournies par la direction (textes, contact, mentions légales)
• Résultats enregistrés selon l'annexe C (déroulement de la journée, actions confirmées, paquets de modifications de l'IA de planification de service, analyses journalières, rapports mensuels)
• Consentement à l'IA enregistré par compte (horodatage et version du texte)

§4 Obligations du sous-traitant

Le sous-traitant s'engage à respecter les obligations suivantes conformément à l'art. 28 al. 3 RGPD :

(1) Obligation de n'agir que sur instruction (art. 28 al. 3, deuxième phrase, lit. a RGPD)

Le sous-traitant ne traite les données à caractère personnel que sur instruction documentée du responsable du traitement, y compris en ce qui concerne les transferts de données à caractère personnel vers un pays tiers ou vers une organisation internationale, à moins qu'il ne soit tenu d'y procéder en vertu du droit de l'Union ou du droit de l'État membre auquel il est soumis. Dans un tel cas, le sous-traitant informe le responsable du traitement de ces exigences juridiques avant le traitement, sauf si le droit concerné interdit une telle information pour un motif important d'intérêt public. Le sous-traitant informe immédiatement le responsable du traitement s'il estime qu'une instruction constitue une violation du RGPD ou d'autres dispositions de protection des données de l'Union ou des États membres.

(2) Confidentialité (art. 28 al. 3, deuxième phrase, lit. b RGPD)

Le sous-traitant garantit que les personnes autorisées à traiter les données à caractère personnel se sont engagées à la confidentialité ou sont soumises à une obligation légale de secret appropriée. L'obligation de confidentialité subsiste après la fin de la prestation.

(3) Mesures techniques et organisationnelles (art. 28 al. 3, deuxième phrase, lit. c, en liaison avec l'art. 32 RGPD)

Le sous-traitant prend toutes les mesures requises en vertu de l'art. 32 RGPD. Compte tenu de l'état de la technique, des coûts de mise en œuvre, de la nature, de la portée, des circonstances et des finalités du traitement, ainsi que de la probabilité et de la gravité variables du risque pour les droits et libertés des personnes physiques, le sous-traitant garantit un niveau de protection adapté au risque. Les mesures concrètes sont décrites au §5 du présent contrat.

(4) Sous-traitants ultérieurs (art. 28 al. 3, deuxième phrase, lit. d, en liaison avec l'art. 28 al. 2 et 4 RGPD)

Le sous-traitant ne recourt à aucun autre sous-traitant sans l'autorisation écrite préalable du responsable du traitement. Les sous-traitants ultérieurs mentionnés aux annexes 1 et 2A sont réputés autorisés dès la conclusion du contrat ; tout recours supplémentaire ou tout remplacement reste techniquement bloqué jusqu'à confirmation (§9).

(5) Assistance pour les droits des personnes concernées (art. 28 al. 3, deuxième phrase, lit. e RGPD)

Le sous-traitant aide le responsable du traitement, dans la mesure du possible, par des mesures techniques et organisationnelles appropriées, à répondre aux demandes d'exercice des droits des personnes concernées prévus aux art. 15 à 22 RGPD. Il s'agit notamment du droit d'accès (art. 15), du droit de rectification (art. 16), du droit à l'effacement (art. 17), du droit à la limitation du traitement (art. 18), de l'obligation de notification (art. 19), du droit à la portabilité des données (art. 20), du droit d'opposition (art. 21) ainsi que du droit de ne pas faire l'objet d'une décision individuelle automatisée (art. 22).

(6) Assistance pour les obligations de sécurité (art. 28 al. 3, deuxième phrase, lit. f RGPD)

Compte tenu de la nature du traitement et des informations dont il dispose, le sous-traitant aide le responsable du traitement à respecter les obligations prévues aux art. 32 à 36 RGPD. Cela comprend notamment l'assistance pour :

• la sécurité du traitement (art. 32 RGPD)
• la notification de violations de données à caractère personnel à l'autorité de contrôle (art. 33 RGPD)
• la communication de violations aux personnes concernées (art. 34 RGPD)
• l'analyse d'impact relative à la protection des données (art. 35 RGPD)
• la consultation préalable de l'autorité de contrôle (art. 36 RGPD)

(7) Notification des violations de données à caractère personnel (art. 33 al. 2 RGPD)

Le sous-traitant notifie au responsable du traitement toute violation de données à caractère personnel dans les meilleurs délais, et au plus tard dans les 24 heures après en avoir pris connaissance, afin que le responsable du traitement puisse respecter son obligation de notification prévue à l'art. 33 al. 1 RGPD (délai de 72 heures à l'égard de l'autorité de contrôle). La notification contient au minimum :

• une description de la nature de la violation
• dans la mesure du possible, les catégories et le nombre approximatif de personnes concernées et d'enregistrements de données
• une description des conséquences probables
• une description des mesures prises ou proposées

(8) Effacement et restitution (art. 28 al. 3, deuxième phrase, lit. g RGPD)

À l'achèvement des prestations de traitement, le sous-traitant efface toutes les données à caractère personnel ou les restitue, au choix du responsable du traitement, et détruit les copies existantes, sauf si le droit de l'Union ou le droit des États membres impose leur conservation. Les modalités sont régies par le §8 du présent contrat.

(9) Obligations de démonstration (art. 28 al. 3, deuxième phrase, lit. h RGPD)

Le sous-traitant met à la disposition du responsable du traitement toutes les informations nécessaires pour démontrer le respect des obligations énoncées à l'art. 28 RGPD, et permet et facilite les audits, y compris les inspections, menés par le responsable du traitement ou par un auditeur mandaté par lui. Les modalités sont régies par le §7 du présent contrat.

(10) Registre des activités de traitement (art. 30 al. 2 RGPD)

Le sous-traitant tient un registre de toutes les catégories d'activités de traitement qu'il effectue pour le compte du responsable du traitement, contenant les indications visées à l'art. 30 al. 2 lit. a à d RGPD.

§5 Mesures techniques et organisationnelles

Le sous-traitant a mis en œuvre les mesures suivantes au titre de l'art. 32 al. 1 lit. a à d RGPD. Conformément à l'art. 32 al. 1 RGPD, compte tenu de l'état de la technique, des coûts de mise en œuvre, de la nature, de la portée, des circonstances et des finalités du traitement, ainsi que de la probabilité et de la gravité variables du risque pour les droits et libertés des personnes physiques, il convient de prendre des mesures techniques et organisationnelles appropriées afin de garantir un niveau de sécurité adapté au risque. Ces mesures comprennent notamment :

• la pseudonymisation et le chiffrement des données à caractère personnel (art. 32 al. 1 lit. a RGPD)
• la capacité à garantir sur la durée la confidentialité, l'intégrité, la disponibilité et la résilience des systèmes et services de traitement (art. 32 al. 1 lit. b RGPD)
• la capacité de rétablir rapidement la disponibilité des données à caractère personnel et l'accès à celles-ci en cas d'incident physique ou technique (art. 32 al. 1 lit. c RGPD)
• une procédure visant à tester, analyser et évaluer régulièrement l'efficacité des mesures techniques et organisationnelles pour assurer la sécurité du traitement (art. 32 al. 1 lit. d RGPD)

Pour apprécier le niveau de sécurité approprié, il convient notamment de tenir compte des risques que présente le traitement, résultant en particulier de la destruction, de la perte, de la modification ou de la divulgation non autorisée de données à caractère personnel ou de l'accès non autorisé à de telles données (art. 32 al. 2 RGPD).

Les mesures s'orientent selon les objectifs de protection suivants :

1. Contrôle des accès
2. Contrôle des supports de données
3. Contrôle de la conservation
4. Contrôle des utilisateurs
5. Contrôle d'accès aux données
6. Contrôle de la transmission
7. Contrôle de la saisie
8. Contrôle du transport
9. Restaurabilité
10. Fiabilité
11. Intégrité des données
12. Contrôle de la sous-traitance
13. Contrôle de la disponibilité
14. Séparabilité

La présentation suivante décrit les mises en œuvre concrètes de ces objectifs de protection. Les mesures font l'objet d'un contrôle régulier et sont adaptées à l'état de la technique (art. 32 al. 1 lit. d RGPD).

Modifications des TOM se distinguent comme suit :

• Immédiatement opérationnelles, sans nouvelle case à cocher : uniquement les adaptations qui ne collectent aucune nouvelle donnée à caractère personnel et qui fonctionnent sur la même infrastructure, déjà mentionnée à l'annexe 1 ou à l'annexe 2A (par exemple correctifs, durcissement, configuration, remplacement de mesures de protection de même nature). Le sous-traitant documente ces modifications. Aucun consentement distinct ni information préalable n'est requis à cet effet.
• Non immédiatement opérationnelles (modification substantielle) : toute modification des TOM qui collecte de nouvelles données à caractère personnel, introduit une nouvelle fonction avec collecte de données ou utilise une infrastructure autre que celle déjà approuvée. Pour ces modifications s'applique la procédure prévue au §12 al. 3 (notification, e-mail, blocage technique jusqu'à confirmation).

1. Contrôle de l'entrée (logique)

Supabase Auth avec JWT et renouvellement automatique des jetons ; Row-Level Security (RLS) sur toutes les tables de la base de données ; Column-Level Security sur la table Kita.

2. Contrôle des accès

Côté client : mots de passe distincts par rôle (administrateur, personnel, parents, fournisseur) ; mot de passe administrateur avec jeton serveur complémentaire, de courte durée, pour les actions sensibles ; mot de passe personnel de chaque personne dans l'application Personnel ; authentification par clé API pour l'API Eltern ; limitation côté serveur des tentatives échouées par réseau et par établissement ; second facteur lors de la connexion (code à usage unique par e-mail) pour les comptes Träger et les comptes d'établissement.

Côté exploitant : l'accès aux systèmes de production, aux bases de données et à l'infrastructure est limité au personnel autorisé et protégé par une authentification individuelle.

3. Contrôle d'accès aux données

Côté client : politiques RLS au niveau de la base de données ; concept d'autorisation fondé sur les rôles, avec les niveaux gestionnaire Träger, admin de KiTa et Staff. L'admin de KiTa et le Staff n'accèdent qu'aux données de leur propre établissement. Un compte Träger voit les données des KiTas rattachées au Träger ; les utilisateurs invités par le compte Träger obtiennent eux aussi, après acceptation de l'invitation, l'accès à ces données de KiTa et la possibilité de les modifier. Il n'existe aucun accès aux données d'autres Träger.

Côté exploitant : accès aux données à caractère personnel uniquement selon le principe du besoin d'en connaître (need-to-know), limité à la maintenance, au support et à la correction des erreurs.

4. Contrôle de la transmission

TLS 1.2/1.3 pour toutes les transmissions de données ; configuration HTTPS uniquement (Vercel) ; aucune interface non chiffrée.

5. Contrôle de la saisie

Validation côté client (Formik + Yup) ; validation côté serveur ; journalisation de toutes les opérations de check-in et de check-out avec horodatage.

6. Contrôle de la disponibilité

Supabase Managed Database (Francfort) avec sauvegardes automatiques et Point-in-Time Recovery ; réseau Edge de Vercel offrant une résilience aux pannes ; logique de reconnexion avec backoff exponentiel (2 s → 30 s), puis nouvelles tentatives à intervalles de 60 secondes.

7. Contrôle de la séparation

Niveau base de données : séparation des mandants (multi-tenant) par Row-Level Security (RLS) sur toutes les tables ; chaque politique vérifie l'appartenance à l'établissement concerné (kita_id). Column-Level Security (CLS) sur les colonnes sensibles (par ex. mots de passe). Refus global comme base (REVOKE ALL pour les accès non authentifiés). Les buckets de stockage sont également protégés par RLS.

Niveau application : le frontend n'utilise que des clés API restreintes (pas de clé service-role) ; la clé service-role n'est utilisée que côté serveur, dans les routes API. Les abonnements Realtime sont filtrés par RLS. Les établissements ne peuvent consulter que leurs propres données. Les comptes Träger (y compris les utilisateurs invités) voient et modifient les données des KiTas rattachées au Träger ; aucune consultation transversale entre Träger n'est possible.

8. Pseudonymisation

Configurable en option : codes au lieu de noms réels dans l'affichage ; identifiants d'enfants pseudonymisés (codes enfant) dans l'application Eltern.

9. Surveillance des erreurs

Les événements d'erreur techniques sont transmis à Sentry (Functional Software, Inc.) dans la région UE de Francfort (FRA). Traces de pile et métadonnées techniques, sans charges utiles de chat, de prompt ou d'audio ; en cas d'erreurs de dictée, au maximum la taille en octets et le type MIME. Session Replay enregistre les déroulements d'écran de l'application web pour la reproduction des erreurs, y compris sur les tablettes d'enregistrement et les pages publiques destinées aux représentants légaux ; les textes et saisies sont masqués, les images et médias ne sont pas enregistrés ; dans la mesure où le masquage ne fonctionne pas dans un cas particulier, des noms visibles peuvent être contenus.

10. Fonctionnement hors ligne des tablettes d'enregistrement

Pour que l'enregistrement se poursuive en cas de coupure réseau, la tablette conserve une copie de travail dans le stockage local du navigateur (IndexedDB) : enfants (nom, sigle ou PIN, groupe, type de prise en charge, facteur d'encadrement, caractéristique repas), personnel (nom, sigle ou PIN, groupe, type de personnel) ainsi que les messages d'état du jour en cours ; les enregistrements non encore transmis sont conservés jusqu'à la synchronisation. La copie ne se trouve que sur l'appareil concerné et est supprimée à la déconnexion ou au changement de compte. Le responsable du traitement sécurise les appareils par verrouillage et chiffrement de l'appareil.

11. Consentements et preuves

Un consentement d'origine « Eltern » n'est créé que par un lien envoyé à l'adresse enregistrée par l'établissement ; l'établissement peut en outre saisir lui-même des libérations (origine « Einrichtung », annexe 5 §2 al. 3). Le lien contient un jeton à usage unique, qui n'est enregistré que sous forme de valeur de contrôle, est valable une heure et est retiré des journaux d'erreurs. L'ouverture et la confirmation sont séparées, afin qu'une consultation automatique du lien ne déclenche pas de consentement. Le texte confirmé est enregistré ; une libération modifiée rend caducs les liens ouverts. Les consentements accordés ne sont plus modifiables a posteriori ; un consentement accordé par les parents ne peut être écrit que par le serveur. Les signatures se trouvent dans un stockage privé, sans accès depuis le navigateur.

12. Connexion bancaire

Accès en lecture seule au compte de l'établissement ; jetons d'accès chiffrés en AES-256-GCM, lisibles uniquement côté serveur et supprimés lors de la déconnexion ; seules les informations sur les entrées affectées et les sorties affectées par le responsable du traitement sont enregistrées, jamais le nom ni l'IBAN des payeurs ou bénéficiaires.

État : octobre 2026. Les adaptations des TOM à effet immédiat sont documentées et mises à disposition du responsable du traitement sur demande. Toutes les autres modifications des TOM suivent le §12 al. 3.

§6 Droits et obligations du responsable du traitement

(1) Le responsable du traitement est, au sens de l'art. 4 n° 7 RGPD, la personne physique ou morale qui, seule ou conjointement avec d'autres, détermine les finalités et les moyens du traitement de données à caractère personnel. Il demeure responsable de la licéité du traitement (art. 24 al. 1 RGPD).

(2) Le responsable du traitement veille à ce que le traitement soit conforme aux principes de l'art. 5 al. 1 RGPD, notamment :

• licéité, traitement loyal et transparence (art. 5 al. 1 lit. a RGPD)
• limitation des finalités (art. 5 al. 1 lit. b RGPD)
• minimisation des données (art. 5 al. 1 lit. c RGPD)
• exactitude (art. 5 al. 1 lit. d RGPD)
• limitation de la conservation (art. 5 al. 1 lit. e RGPD)
• intégrité et confidentialité (art. 5 al. 1 lit. f RGPD)

(3) Le responsable du traitement est notamment chargé de :

• respecter les obligations d'information lors de la collecte de données à caractère personnel auprès de la personne concernée (art. 13 RGPD) ainsi qu'en cas de collecte auprès de tiers (art. 14 RGPD)
• recueillir les consentements, si nécessaire, dans le respect des exigences de l'art. 7 RGPD
• tenir un registre des activités de traitement conformément à l'art. 30 al. 1 RGPD
• réaliser une analyse d'impact relative à la protection des données conformément à l'art. 35 RGPD, dans la mesure où le traitement est susceptible d'engendrer un risque élevé pour les droits et libertés des personnes physiques
• garantir une base juridique conformément à l'art. 6 al. 1 RGPD pour chaque traitement (autorisation légale et/ou consentement)
• inviter d'autres utilisateurs au compte Träger et accorder ainsi l'accès aux données des KiTas rattachées ainsi que la possibilité de les modifier ; le responsable du traitement veille à n'inviter que les personnes habilitées à cet effet
• instruire ses utilisateurs sur le contenu des champs de texte libre et vérifier les textes avant leur transmission aux représentants légaux ou leur publication (annexe 4 §3)
• respecter les obligations prévues à l'annexe 5 §6 pour les libérations, les consentements par e-mail, les personnes autorisées à venir chercher l'enfant et les remises, notamment la vérification de l'identité des personnes venant chercher l'enfant, de l'autorité parentale et de l'exactitude des adresses e-mail enregistrées

(4) Le responsable du traitement a le droit de donner au sous-traitant des instructions concernant la nature, l'étendue et la procédure du traitement des données. Les instructions doivent être données par écrit ou sous un format électronique. Les instructions orales doivent être confirmées par écrit sans délai.

(5) Le responsable du traitement informe sans délai le sous-traitant s'il constate des erreurs ou irrégularités lors de la vérification des résultats du traitement.

(6) Non applicable en dehors de l'Allemagne.

(7) Non applicable en dehors de l'Allemagne.

(8) Accès. Les comptes Träger et le compte de l'établissement sont des comptes de connexion avec adresse e-mail et mot de passe. Dans l'espace Träger, chaque compte peut inviter d'autres comptes personnels ; tous les comptes disposent des mêmes droits (consultation et modification de tous les établissements rattachés). Il n'existe pas actuellement de rôles différenciés ; le sous-traitant supprime un compte sur demande. Le compte de l'établissement est utilisé en commun par la direction ; certaines zones sont en outre protégées par les verrouillages de section (§3). Le responsable du traitement

• a) crée, dans l'espace Träger, un compte personnel invité pour chaque personne, au lieu de partager un accès ;
• b) limite le cercle des personnes qui connaissent un mot de passe commun (compte de l'établissement, verrouillages de section) ;
• c) modifie régulièrement et immédiatement les mots de passe partagés lorsqu'une personne quitte ses fonctions ou qu'un appareil est perdu : le mot de passe de connexion via « Passwort vergessen » sur la page de connexion, les verrouillages de section dans les paramètres ;
• d) signale les personnes sortantes disposant d'un compte Träger personnel en vue de la suppression de ce compte.

Lorsque des accès sont partagés, il n'est pas possible de déterminer quelle personne a agi ; cela concerne également la preuve de la confirmation du contrat selon le §12, qui consigne le nom et le compte de la personne qui confirme.

§7 Contrôle et preuves

(1) Le responsable du traitement a le droit de vérifier le respect du présent contrat et des exigences de protection des données (art. 28 al. 3, deuxième phrase, lit. h RGPD). Le contrôle peut s'effectuer par :

• la demande de renseignements et de preuves
• la réponse écrite du sous-traitant à un questionnaire
• des audits à distance après concertation préalable ; des inspections sur site sont rendues possibles, dans la mesure où cela est opportun compte tenu de l'infrastructure exclusivement cloud

(2) Le sous-traitant met à la disposition du responsable du traitement, sur demande, des preuves actualisées du respect des mesures techniques et organisationnelles. Cela comprend notamment les certifications et rapports d'audit des sous-traitants ultérieurs utilisés.

(3) Les efforts allant au-delà d'un contrôle par année civile et de l'assistance légalement due sont rémunérés au temps passé, à des tarifs usuels sur le marché.

§8 Restitution ou effacement des données

(1) Les obligations légales de conservation des données traitées pour le compte du responsable du traitement, notamment en vertu du droit national de l'État membre du responsable du traitement ainsi que des dispositions budgétaires, de subventions ou fiscales, incombent exclusivement au responsable du traitement. Le sous-traitant ne conserve les données que pour la durée du présent contrat et conformément aux instructions du responsable du traitement ; une obligation légale de conservation propre au sous-traitant au sens de l'art. 28 al. 3, deuxième phrase, lit. g RGPD n'existe pas.

(2) Pendant la durée du contrat, les délais d'effacement sont régis par les instructions du responsable du traitement (durée de conservation paramétrable dans le logiciel). Le sous-traitant n'efface pas les données avant l'expiration du délai fixé par le responsable du traitement, sauf instruction contraire de ce dernier. Les personnes prises individuellement (enfants, personnel) sont archivées dans le logiciel et ne sont pas supprimées immédiatement, afin que le responsable du traitement puisse remplir ses obligations de conservation ; les enregistrements archivés sont retirés de l'usage courant. Sur instruction du responsable du traitement, le sous-traitant donne suite aux demandes d'effacement des personnes concernées (art. 17 RGPD) en supprimant définitivement les enregistrements concernés, dans la mesure où aucune obligation de conservation du responsable du traitement ne s'y oppose.

(3) Le responsable du traitement peut à tout moment, et au plus tard jusqu'à la fin du contrat, obtenir un export complet dans un format lisible par machine (CSV) ainsi que des justificatifs de présence au format PDF ; il s'agit de la restitution au sens de l'art. 28 al. 3, deuxième phrase, lit. g RGPD. Le sous-traitant assiste le responsable du traitement pour tous les exports et transferts de données et met l'export à disposition, sur demande, par une voie de transmission sécurisée.

(4) Le sous-traitant efface toutes les données à caractère personnel dans les systèmes de production 30 jours après la fin du contrat ou, si cela intervient plus tôt, 7 jours après l'export confirmé par le responsable du traitement. Les copies figurant dans les sauvegardes sont écrasées par rotation au plus tard 30 jours après la fin du contrat et ne sont pas restaurées jusque-là, sauf pour une restauration sur instruction. Les actions d'enregistrement rejetées (discarded_actions) sont volontairement conservées après la suppression d'une personne isolée (conservation documentée, §3) ; elles sont néanmoins supprimées avec le reste de l'ensemble de données selon la première phrase. Une fois l'opération achevée, le responsable du traitement reçoit une confirmation d'effacement (date, étendue, systèmes).

(5) Le responsable du traitement est tenu de conserver lui-même les documents exportés pendant la durée de ses délais légaux de conservation.

(6) Forfait gratuit : si l'utilisation du forfait gratuit prend fin, les al. 3 et 4 s'appliquent à l'export et à l'effacement.

(7) Un appareil de prêt (tablette) mis à disposition par le sous-traitant doit être débarrassé de toutes les données avant sa restitution et réinitialisé aux paramètres d'usine. Le sous-traitant contrôle la réinitialisation après réception de l'appareil et la répète si nécessaire.

(8) Délais d'effacement automatiques de certaines fonctions (indépendamment de l'al. 4) :

• Demandes de consentement par e-mail : l'adresse du destinataire et la valeur de contrôle du lien sont supprimées lors de la confirmation, lors de leur remplacement par une nouvelle demande, ou au plus tard environ une heure après l'expiration du lien d'une heure ; demandes non confirmées après 30 jours ; demandes confirmées conservées comme preuves. Le journal d'envoi des demandes de libération et d'enregistrement reste conservé jusqu'à sa suppression par le responsable du traitement, au plus tard jusqu'à la fin du contrat.
• Consentements à l'enregistrement d'un entretien avec les représentants légaux qui n'ont pas été utilisés pour un enregistrement : après 30 jours, avec l'image de la signature ; ceux qui ont été utilisés restent attachés à l'entretien jusqu'à ce que le responsable du traitement le supprime.
• Fichier audio d'un entretien avec les représentants légaux : immédiatement après l'évaluation.
• Photo d'un enfant : en cas de retrait de la libération, au plus tard lors de la vérification quotidienne.
• Candidatures dans le portail d'inscription : non confirmées après sept jours ; refusées ou retirées douze mois après la clôture.
• Valeurs de contrôle des tentatives de mot de passe échouées : après une heure.
• Destinataires de factures de cotisations de membre et messages entre l'établissement et le Träger : jusqu'à leur suppression par le responsable du traitement, au plus tard selon l'al. 4.

§9 Sous-traitants ultérieurs

(1) Le responsable du traitement autorise, dès la conclusion du contrat, le recours aux sous-traitants ultérieurs mentionnés aux annexes 1 et 2A (art. 28 al. 2 RGPD).

(2) Tout recours supplémentaire à un sous-traitant ultérieur ou tout remplacement d'un sous-traitant ultérieur est techniquement bloqué tant que la personne signataire n'a pas lu l'accord actualisé (y compris l'annexe modifiée) et ne l'a pas confirmé par case à cocher. Avant cette confirmation, aucune donnée à caractère personnel ne circule vers le prestataire nouveau ou remplacé. Un délai d'opposition de 14 jours sans blocage ne s'applique pas. Jusqu'à la confirmation, seuls les sous-traitants ultérieurs préalablement autorisés restent en service.

(3) Pour la demande de confirmation, l'e-mail et le rappel, le §12 al. 1 et 2 s'applique.

(4) Conformément à l'art. 28 al. 4 RGPD, le sous-traitant veille à conclure avec chaque sous-traitant ultérieur un contrat qui lui impose au moins les mêmes obligations en matière de protection des données que celles fixées dans le présent AVV.

§10 Transfert international de données

(1) Lieux de stockage : Les données à caractère personnel sont stockées exclusivement au sein de l'Union européenne ; les exceptions sont réglées de manière exhaustive à l'al. 2. À la date du présent contrat, les sous-traitants ultérieurs sont configurés comme suit :

• Supabase : Francfort (AWS) - base de données, authentification, stockage ; site principal de toutes les données principales
• Vercel : Francfort - hébergement, fonctions serverless et stockage de données
• Cloudflare : résidence des données dans l'UE (Francfort / Cloudflare Regional Services) - intermédiation de l'API de l'application Eltern et envoi des notifications push des deux applications, ainsi que stockage durable dans Cloudflare KV (mot de passe parents de l'établissement, nom de l'établissement, jetons push, identifiants d'appareils avec affectation au groupe, identifiants d'enfants enregistrés sur l'appareil (au maximum 20, afin que les messages liés à un enfant n'atteignent que les appareils de cet enfant) et, le cas échéant, identifiant du personnel ; passes Wallet comportant le nom de l'enfant, pendant 5 minutes au maximum) ; aucun accès à la base de données Supabase
• Brevo (Sendinblue) : e-mails techniques ainsi qu'envoi et réception dans les fonctions du logiciel - hébergement chez OVH (France et Allemagne), stockage des données chez Google Cloud (Belgique)
• Sentry : Francfort - surveillance des erreurs et Session Replay de l'application web (masqué)
• Zoho : Pays-Bas - boîte e-mail
• Google Cloud (Vertex AI / Gemini Enterprise Agent Platform) : point de terminaison multirégional UE (aiplatform.eu.rep.googleapis.com) - tous les flux de données d'IA sauf la génération d'images, uniquement si les fonctions d'IA sont activées (annexe C)

L'application Personnel envoie ses requêtes directement à l'application (Vercel, Francfort). Les déclarations issues des deux applications (désinscriptions, annulations de repas, déclarations de récupération, temps, enregistrements d'arrivée et de départ, arrêts maladie, messages de chat) ne sont transmises à Supabase qu'à l'intérieur de l'Allemagne.

(2) Exceptions : Les flux de données suivants peuvent, pour des raisons techniques, transiter par une infrastructure située hors UE :

• Notifications push de l'application Eltern et de l'application Personnel - via Apple Push Notification service (APNs), Firebase Cloud Messaging (FCM) et la couche d'orchestration Expo, déclenchées par le worker push Cloudflare. Elles sont imposées impérativement par les plateformes Apple/iOS et Google/Android ; une distribution uniquement par une infrastructure UE n'est pas possible. Les contenus des messages n'y transitent que de manière transitoire et ne sont pas stockés durablement ; les services conservent les jetons push pour la durée de leur validité (annexe 2A §4). Les données métier restent dans Supabase Francfort. Types et contenus des push : annexe 2A §2 et annexe 2B §2
• Cartes Wallet (cartes de récupération numériques iOS/Android) - dans la mesure où les services Wallet d'Apple et de Google interviennent dans l'affichage ; également imposées par les plateformes (annexe 2A)
• Génération optionnelle d'images par IA (images de site Internet, logo du terminal, images d'aperçu des thèmes de danger) - point de terminaison Vertex mondial, car Google ne propose pas les modèles d'image sur le multirégional UE ; pour ce flux, il n'existe donc aucune garantie de résidence dans l'UE. Seules sont transmises des descriptions d'images sans lien avec des personnes (indications de style et de conception, nom de l'établissement, description d'objets) ; les photos, noms, identifiants et descriptions de personnes ne sont pas transmis. Avec le générateur d'images utilisant un modèle hors UE, le texte libre et les images de référence de l'utilisateur ou de l'utilisatrice y parviennent également ; ils ne doivent contenir aucune donnée à caractère personnel (annexe C §3 n° 19). Fondement du transfert : clauses contractuelles types à l'égard de Google ; le Cadre de protection des données UE-États-Unis s'applique dans la mesure où le traitement a lieu aux États-Unis. Désactivable individuellement ; détails à l'annexe C
• Sites Internet des établissements (Cloudflare Pages) - les contenus accessibles publiquement sont diffusés dans le monde entier ; le contenu est déterminé par le responsable du traitement

Le produit de base n'a besoin d'aucun de ces flux. Le responsable du traitement peut à tout moment les désactiver, ainsi que les autres fonctions d'IA, ou ne pas les utiliser.

(3) Pas de transfert vers des pays tiers pour le reste : À la conclusion du contrat, il n'existe - hors al. 2 - aucun transfert actif de données vers des pays tiers au sens de l'art. 44 RGPD qui viserait un stockage durable hors UE. Les bases DPF et CCT visées aux al. 4 et 5 offrent une garantie à l'égard des sociétés mères américaines des fournisseurs cloud utilisés et des accès potentiels au titre du droit américain (notamment le CLOUD Act), et, pour la génération d'images, également à l'égard du traitement sur le point de terminaison mondial.

(4) Surveillance de la base de transfert : Le sous-traitant surveille en permanence la validité du Cadre de protection des données UE-États-Unis (décision d'exécution (UE) 2023/1795). Les transferts de données ou les accès potentiels depuis les États-Unis sont actuellement couverts (également) sur la base du DPF auprès des sous-traitants ultérieurs suivants :

• Vercel Inc. (hébergement / fonctions serverless - annexe 1)
• Google Ireland Ltd. / Google LLC (Firebase Cloud Messaging - annexe 2A ; Vertex AI / Gemini Enterprise Agent Platform en cas de fonctions d'IA activées, y compris la génération d'images sur le point de terminaison mondial - annexe 1 et annexe C ; stockage des e-mails techniques chez Google Cloud Belgique via Brevo - annexe 1)
• Cloudflare Inc. (transit API et Cloudflare KV de l'application Eltern, résidence des données dans l'UE - annexe 2A)
• Functional Software, Inc. (Sentry, surveillance des erreurs et Session Replay, région UE Francfort - annexe 1)
• Apple Inc. (Apple Push Notification service, transit uniquement, annexe 2A) : certification DPF d'Apple Inc. ; pas de contrat au sens de l'art. 28 et pas de CCT spécifiques à APNs, voir annexe 2A §4 et §5

(5) Repli sur les clauses contractuelles types : Pour les services susmentionnés, à l'exception d'Apple (APNs), des clauses contractuelles types (CCT) selon la décision d'exécution (UE) 2021/914 existent en complément, en tant que base de transfert autonome au sens de l'art. 46 al. 2 lit. c RGPD. En cas de caducité, de suspension ou d'invalidation du DPF UE-États-Unis, le sous-traitant fait basculer la base de transfert de ces services vers les CCT sans interrompre le service et en informe le responsable du traitement sans délai, au plus tard dans les 30 jours suivant sa connaissance de la situation. Pour APNs, Apple ne propose pas de CCT ; dans ce cas, le push iOS peut être désactivé sans compromettre le produit de base. Pour Supabase Inc., les clauses contractuelles types (2021/914) s'appliquent.

(6) Mesures de protection complémentaires (analyse d'impact du transfert) : Conformément aux recommandations 01/2020 du CEPD, les mesures techniques et organisationnelles de protection supplémentaires suivantes sont appliquées :

• chiffrement de transport (TLS 1.2/1.3) pour toutes les transmissions de données
• aucun stockage de données principales à caractère personnel en dehors de l'UE (lieux de stockage selon l'al. 1, exceptions selon l'al. 2)
• pseudonymisation dans la mesure techniquement possible (par ex. codes enfant au lieu de noms réels dans l'application Eltern)
• minimisation des données au strict nécessaire pour chaque finalité ; invites d'image sans lien avec des personnes (obligation des utilisateurs pour le générateur d'images selon l'annexe C §3 n° 19) ; pour les autres fonctions d'IA, identifiants au lieu de noms selon le niveau de protection des données IA choisi (annexe C)
• contenu des push selon le type (annexe 2A §2 et annexe 2B §2). Conformément à l'usage prévu, le texte libre ne doit pas contenir de données sensibles concernant des enfants, mais des indications d'organisation et, pour le personnel, des indications sur le temps de travail. Ne sont contrôlés que les messages adressés aux groupes et à une famille depuis l'application web, les messages directs adressés à une collaboratrice ou à un collaborateur et, si elles sont activées, les messages du chat d'équipe provenant de l'application Personnel, par le garde-fou de données IA (annexe C §3 n° 18) ; sinon, aucun filtrage technique n'a lieu
• événements d'erreur sans charges utiles de chat, de prompt ou d'audio, et Session Replay masqué dans la région UE Francfort (§5 n° 9)

(7) Escalade en cas de caducité également des CCT : Si les clauses contractuelles types étaient elles aussi jugées insuffisantes par arrêt de la CJUE ou décision contraignante d'une autorité de contrôle, le sous-traitant prend au moins l'une des mesures suivantes et en informe le responsable du traitement avec un préavis d'au moins 14 jours :

• migration vers un prestataire de remplacement établi dans l'UE, dans la mesure où il est disponible sur le plan technique et économique
• désactivation du service concerné, dans la mesure où cela est techniquement raisonnable - concerne notamment les fonctions facultatives de l'application Eltern (notifications push, éléments Wallet) ainsi que les flux de données d'IA individuels, y compris la génération d'images (interrupteur d'arrêt, annexe C)
• mise en œuvre de mesures de protection supplémentaires (par ex. chiffrement côté client), dans la mesure où celles-ci maintiennent le service opérationnel

(8) Incidences sur le produit de base : La localisation des données du produit de base n'est pas affectée par une caducité du DPF UE-États-Unis : toutes les données principales à caractère personnel restent à leur lieu de stockage selon l'al. 1. Seule est concernée la base juridique du transfert pour les prestataires dont la société mère a son siège aux États-Unis (concrètement : Vercel Inc., Supabase Inc., Functional Software, Inc. et Google). Pour ceux-ci, les CCT s'appliqueraient comme base de transfert (voir al. 5), sans interruption du lieu physique de stockage ni de l'exploitation du service. Si les CCT étaient également jugées insuffisantes par arrêt ou décision administrative, le sous-traitant migrerait vers des prestataires de remplacement établis dans l'UE, sans société mère américaine. Les fonctions push de l'application Eltern et de l'application Personnel (FCM, APNs, Expo) ainsi que la génération optionnelle d'images par IA peuvent, dans un tel scénario, être désactivées sans compromettre le produit de base.

§11 Responsabilité

La responsabilité des parties est régie par les dispositions légales du RGPD, notamment l'art. 82 RGPD. Chaque partie répond des dommages causés par une violation du RGPD qui lui est imputable. Le sous-traitant répond de la faute de ses salariés et des sous-traitants ultérieurs qu'il emploie comme de sa propre faute.

§12 Conclusion du contrat et confirmation

(1) Le contrat est conclu par une confirmation active (case à cocher) dans le compte authentifié de la personne signataire. La personne signataire est la personne connectée au compte concerné, qui agit pour le responsable du traitement. La partie contractante est déterminée par le rattachement de l'établissement :

• Établissement rattaché à un Träger : seul le Träger est partie contractante et responsable du traitement au sens de l'art. 4 n° 7 RGPD. La personne connectée au compte Träger confirme au moyen d'une case à cocher incontournable dans l'interface d'administration (ordinateur). Les terminaux d'enregistrement n'affichent pas cette boîte de dialogue. La direction de la KiTa rattachée peut être invitée une fois à prendre connaissance des documents ; il ne s'agit ni d'une seconde partie contractante, ni d'une acceptation du présent AVV. Les mises à jour ultérieures des documents n'apparaissent là que comme une indication, sans blocage.
• Établissement sans rattachement à un Träger : la direction de la KiTa confirme dans l'administration, pour le responsable du traitement. La boîte de dialogue d'acceptation n'apparaît que dans ce cas, dans l'administration de la KiTa, et pas non plus sur les terminaux d'enregistrement.

Chaque confirmation de contrat et chaque prise de connaissance est enregistrée avec le nom, l'adresse e-mail, le rôle (compte Träger ou direction de la KiTa), la nature de l'opération (contrat ou prise de connaissance), l'horodatage, le numéro de version du présent AVV, y compris ses annexes (annexe 1, annexe 2A, annexe 2B, annexe 3, annexe 4, annexe 5, annexe 6, annexe C), ainsi que la version précédemment confirmée.

(2) Le jour de la mise à disposition d'une nouvelle version et à chaque confirmation selon l'al. 1, la personne signataire reçoit par e-mail l'ensemble des documents : le présent AVV, y compris toutes ses annexes dans le numéro de version respectif, ainsi que, après confirmation, les enregistrements de confirmation (nom, e-mail, rôle, horodatage). Les e-mails contiennent en outre des liens de téléchargement vers les mêmes versions. La même version peut à tout moment être téléchargée, consultée et enregistrée sur le site (fonction d'impression). Aucun envoi postal séparé n'a lieu. Les confirmations en attente et les versions modifiées sont affichées dans le tableau de bord de la personne signataire (tableau de bord Träger en cas de rattachement à un Träger, sinon administration de la KiTa) et présentées lors de la prochaine connexion à l'interface d'administration. Si la confirmation fait toujours défaut après deux semaines, un rappel est envoyé par e-mail. Aucun autre e-mail de rappel n'est envoyé. Les établissements rattachés restent utilisables dans l'intervalle.

(3) Les modifications substantielles du présent AVV, y compris ses annexes (nouveaux points de données, nouvelle fonction avec collecte de données, infrastructure autre que celle déjà approuvée, ainsi que toutes autres modifications ne relevant pas de l'al. 4), sont affichées à la personne signataire dans le tableau de bord et lui sont transmises par e-mail le jour de leur mise à disposition, en règle générale au moins 14 jours avant la date de début prévue. La fonction concernée ou le traitement modifié reste techniquement bloqué jusqu'à ce que la personne signataire ait donné son accord par case à cocher. Le reste du logiciel demeure utilisable ; les données à caractère personnel ne sont intégrées au nouveau traitement qu'après cette confirmation. D'ici là, la version précédemment confirmée reste déterminante. Si la modification concerne un sous-traitant ultérieur nouveau ou remplacé, le blocage technique prévu au §9 al. 2 s'applique en outre.

(4) Aucune procédure de mise à jour (ni case à cocher, ni e-mail, effet immédiat) ne s'applique :

• aux précisions de la description du présent AVV et de ses annexes : formulations décrivant plus précisément un traitement déjà convenu (par exemple désignation de champs concrets, de lieux de stockage ou de processus déjà objets de l'accord), ainsi que la correction de fautes de frappe et de renvois. Les précisions ne modifient ni l'objet, ni la finalité, ni la nature des données, ni le cercle des personnes concernées, ni les sous-traitants ultérieurs, les lieux de stockage, le niveau de protection des TOM, ni les droits et obligations des parties. Chaque précision est documentée avec sa date ; la version en vigueur est consultable sous /fr/dpa.
• aux adaptations des TOM selon le §5, qui ne collectent aucune nouvelle donnée à caractère personnel et fonctionnent sur la même infrastructure déjà approuvée

Dès qu'une précision ou une adaptation des TOM concerne de nouveaux points de données, une nouvelle fonction avec collecte de données ou une autre infrastructure, l'al. 3 s'applique.

(5) La case à cocher du système est la procédure ordinaire pour les al. 1 et 3. Une signature manuscrite n'est pas requise (art. 28 al. 9 RGPD). La confirmation électronique, y compris l'e-mail visé à l'al. 2, satisfait à l'exigence de forme écrite du §13 al. 1.

§13 Dispositions finales

(1) Les modifications et compléments du présent accord requièrent la forme écrite ; celle-ci est satisfaite selon le §12 al. 5. La procédure et les exceptions sont régies par le §12 al. 3 et 4.

(2) Si une disposition du présent contrat est nulle, le contrat demeure valable pour le surplus. La disposition nulle doit être remplacée par une disposition valable qui se rapproche le plus possible de la finalité économique de la disposition nulle.

(3) Le droit de la République fédérale d'Allemagne est applicable. Le tribunal compétent est celui de Kaiserslautern.

(4) En cas de contradiction entre le présent contrat et les conditions d'utilisation, les dispositions du présent contrat prévalent pour les questions relatives au traitement de données à caractère personnel.

(5) La version anglaise fait foi ; les traductions dans d'autres langues sont fournies uniquement pour la compréhension.

Annexe 1 : Sous-traitants ultérieurs

Le sous-traitant fait appel aux sous-traitants ultérieurs suivants. Un contrat distinct de sous-traitance (DPA) existe avec chacun d'eux. Les données principales à caractère personnel ne sont pas stockées durablement en dehors de l'UE. Pour l'exception de la génération optionnelle d'images par IA (point de terminaison mondial), voir annexe C §1 al. 2.

Les banques dont les comptes sont reliés par le responsable du traitement pour la consultation des mouvements (§2, connexion bancaire) sont partenaires contractuels du responsable du traitement et ne sont pas des sous-traitants ultérieurs. Le paiement de la redevance d'utilisation par carte de crédit est traité par Stripe Payments Europe, Ltd. (Irlande) ; Stripe ne reçoit alors que les données contractuelles et de paiement du Client, aucune donnée traitée pour le compte, et n'est pas sous-traitant ultérieur.

État : octobre 2026. Conformément au §9 al. 2, les sous-traitants ultérieurs nouveaux ou remplacés ne sont engagés qu'après lecture de l'accord et confirmation par case à cocher par la personne signataire.

Remarque sur le choix des sous-traitants ultérieurs (art. 32 RGPD - pondération des risques)

Le choix de Supabase (base de données, authentification, stockage) et de Vercel (hébergement, fonctions serverless) comme fournisseurs d'infrastructure centraux, tous deux techniquement déployés sur AWS Francfort (eu-central-1), résulte d'une pondération soigneuse entre les exigences de protection des données et la sécurité d'exploitation, conformément à l'art. 32 al. 1 RGPD. Les critères déterminants étaient les suivants :

• Disponibilité et uptime : plusieurs zones de disponibilité AWS dans la région Francfort ; engagements SLA des prestataires dans la plage de 99,9 % ; basculement automatisé sans intervention manuelle
• Support : joignabilité 24h/24 et 7j/7 en cas d'incidents critiques ; processus éprouvés de réponse aux incidents ; voies d'escalade documentées
• Sécurité : SOC 2 Type II, ISO 27001, gestion continue des correctifs, tests d'intrusion réguliers, Row-Level Security comme fonction native de la base de données (Supabase), protection DDoS en périphérie (Vercel)
• Usage éprouvé : utilisation en production large et de longue date ; développement continu ; cycles stables de publications et de mises à jour de sécurité

Alternatives évaluées et motifs de rejet :

• Auto-hébergement sur matériel propre ou dans des centres de données allemands spécialisés : augmente le risque opérationnel (délai de correctifs, absence d'équipe d'exploitation 24h/24, résilience ponctuelle) ; conforme formellement au RGPD, mais en pratique inférieur, et non supérieur, au niveau de protection de la pile AWS Francfort
• Hébergeurs allemands ou européens plus petits : offrent une localisation dans l'UE, mais pas le même niveau de services managés (authentification, Realtime, fonctions edge). Développer soi-même ces composants augmenterait le risque de sécurité au lieu de le réduire
• Open Telekom Cloud / T-Systems : techniquement viable, mais sans la pile complète de services managés ; effort de migration et d'exploitation disproportionné par rapport au statu quo déjà juridiquement encadré

La combinaison retenue garantit un niveau de protection adapté au risque au sens de l'art. 32 RGPD (protection contre la perte, la destruction et la divulgation non autorisée), tout en maintenant la localisation dans l'UE (Francfort). Le risque résiduel lié à l'exposition aux sociétés mères américaines est couvert juridiquement par le DPF et les CCT (§10 al. 4 à 5) et techniquement par les mesures décrites au §5.

Annexe 2A : Complément - application Eltern (iOS/Android)

Le complément suivant régit le traitement de données dans le cadre de l'application Eltern optionnelle (iOS/Android). Il s'applique si le responsable du traitement utilise l'application Eltern comme extension du produit de base ; l'application n'est pas une condition d'utilisation du produit de base. Le sous-traitant met à disposition, au sein de l'application Eltern, une demande d'acceptation de la déclaration de confidentialité et des conditions d'utilisation de l'application. Il incombe au responsable du traitement, sous sa propre responsabilité et à sa discrétion, de s'assurer d'un consentement effectif allant au-delà, au sens de l'art. 6 al. 1 lit. a et de l'art. 7 RGPD. Les §4 et §5 de la présente annexe (services push, Wallet, sous-traitants ultérieurs, transfert international) s'appliquent également à l'application Personnel (annexe 2B).

§1 Caractère volontaire et base juridique

(1) L'utilisation de l'application Eltern est volontaire et n'est pas une condition de recours aux prestations d'accueil. La non-utilisation n'a aucune incidence sur le contrat de prise en charge ni sur la qualité de l'accueil.

(2) Toutes les informations mises à disposition via l'application sont également accessibles par d'autres voies (par ex. affichage, entretien personnel).

(3) La base juridique du traitement via l'application Eltern est déterminée par le responsable du traitement (par exemple un consentement au sens de l'art. 6 al. 1 lit. a et de l'art. 7 RGPD). S'il se fonde sur un consentement, celui-ci peut être retiré à tout moment, sans inconvénient. Indépendamment de cela, les représentants légaux acceptent dans l'application les informations sur la protection des données et les conditions d'utilisation de celle-ci ; ils ne reçoivent les notifications push qu'après leur propre accord sur l'appareil.

§2 Nature et finalité du traitement

Le traitement comprend :

• notifications push via iOS/Android (types voir ci-dessous)
• désinscriptions, annulations de repas, déclarations de récupération
• votes aux sondages (un vote par appareil ; identifiant d'appareil uniquement pour empêcher les votes multiples)
• affichage du carnet de l'enfant et du rapport de groupe
• élément Wallet (carte de récupération numérique)
• affichage des personnes autorisées à venir chercher l'enfant (nom, lien) sur chaque appareil sur lequel le code enfant est enregistré, et déclaration d'une personne venant chercher l'enfant (y compris d'une nouvelle personne, qui n'est enregistrée qu'après confirmation par e-mail ; annexe 5 §3)
• demandes d'entretien et choix d'un rendez-vous proposé
• rendez-vous de l'établissement avec confirmation ou annulation par enfant
• affichage des libérations de son propre enfant (sans possibilité de modification)
• affichage des postes de paiement ouverts avec compte bénéficiaire et GiroCode, confirmation de participation, signalement « überwiesen » ; rappels sous forme de notification locale de l'appareil
• articles de blog de l'établissement

Non traité : heures d'arrivée et de départ des enfants. Elles ne sont enregistrées que sur le terminal de la KiTa.

Minimisation des données : l'application Eltern est conçue pour utiliser le moins de données possible. Les parents ne créent pas de compte utilisateur et ne saisissent ni leurs propres noms ni leurs coordonnées. Lorsqu'un parent indique une nouvelle personne autorisée à venir chercher l'enfant, son nom et son lien avec l'enfant sont transmis. L'application ne collecte pas de données de localisation, n'accède ni aux photos, ni aux contacts, ni au microphone, et ne contient aucun outil d'analyse ou de suivi ; l'appareil photo ne sert qu'à scanner le code enfant. Les données métier ne sont pas enregistrées sur l'appareil, mais chargées à chaque appel depuis la base de données de l'UE. Ne restent sur l'appareil que l'accès à l'établissement, les codes enfant et les propres réponses, ainsi que, pour l'affichage hors ligne du calendrier, les jours de fermeture et les fermetures de l'établissement ainsi que ses messages datés à partir du mois en cours (titre, texte, groupe). Si les représentants légaux utilisent l'application dans une autre langue, les contenus de l'établissement (messages, blog, entrées du carnet, plan des repas) sont traduits sur l'appareil (Apple Translation ou Google ML Kit, sans transmission à des tiers) et les traductions sont enregistrées sur l'appareil (au maximum 500 entrées). La vue web de l'application Eltern n'affiche que le feu, les messages de l'établissement et le statut de la KiTa ; elle est fournie par l'application (Vercel, Francfort, annexe 1).

Notifications push : tous les types passent sous forme de push Expo par le worker push Cloudflare. Les données métier restent enregistrées dans Supabase Francfort. Sans le transit par APNs, FCM et Expo, une distribution sur iOS et Android n'est pas possible. Les contenus des messages ne sont pas stockés durablement chez les services push (transit uniquement pour la distribution). Aucun filtrage technique des textes libres n'a lieu.

(1) Message de groupe. Destinataires : appareils de l'application Eltern de l'établissement, filtrés selon les groupes enregistrés lors de l'inscription. Les messages à l'échelle de l'établissement vont à tous les appareils inscrits de l'établissement. Contenu : titre = titre du message, texte = texte du message, chacun tel que rédigé par le personnel ; le nom de l'établissement est placé devant le titre. Conformément à l'usage prévu, indications d'organisation, pas de données sensibles concernant les enfants.

(2) Changement de statut du feu. Destinataires : appareils de l'application Eltern et de l'application Personnel. Uniquement lors du passage au jaune (texte fixe : « Kita nah am Limit ») ou au rouge (texte fixe : « Kita voll ausgelastet »). Pas de push pour le vert. Supprimé les jours de fermeture et en dehors des horaires d'ouverture. L'établissement peut désactiver séparément le jaune et le rouge pour l'application Eltern (activés par défaut) ; les appareils de l'application Personnel reçoivent toujours les deux.

(3) Rappel de rendez-vous. Destinataires : appareils du groupe ou de l'établissement. Contenu : « Termin: <Titel> » ou « Heute: <Titel> » ainsi que date et heure ; pas de noms d'enfants ni de groupes.

(4) Rendez-vous d'entretien. Destinataires : appareils sur lesquels l'enfant concerné est enregistré. Textes fixes sans enfant, groupe, heure ni personne.

(5) Nouvelle entrée du carnet. Destinataires comme pour (4). Titre fixe « Neue Notiz » ou « Neuer Gruppenbericht », sans texte.

(6) Paiement reçu. Uniquement si l'établissement utilise les paiements parentaux et l'application Eltern. Destinataires comme pour (4). Contenu : montant et désignation du motif ; aucun nom d'enfant.

(7) Message à une famille. Destinataires comme pour (4). Titre fixe « Neue Nachricht » avec le nom de l'établissement, sans texte ; l'application récupère le contenu dans la base de données de l'UE. Les actions de réponse (annexe 4 §5 al. 7) passent par l'API chiffrée, et non par push.

Désinscriptions, annulations de repas et déclarations de récupération passent par l'API chiffrée (worker Cloudflare dans l'UE vers Supabase Francfort), et non par les charges utiles push. La notification push sert de déclencheur ; l'application récupère les contenus dans la base de données de l'UE.

Réutilisation par les représentants légaux. Les contenus que l'application Eltern affiche à un parent sont transmis à ce parent par l'affichage. Les représentants légaux peuvent les réutiliser librement, y compris avec leurs propres programmes ou services d'IA ; ils répondent eux-mêmes de cette réutilisation, et le service choisi n'est ni sous-traitant ultérieur ni destinataire du responsable du traitement. Le responsable du traitement en tient compte pour les contenus destinés aux représentants légaux (annexe 4 §3 al. 4 et §5).

§3 Catégories de données traitées

• identifiant d'enfant pseudonymisé (code enfant), identifiant de KiTa
• désinscriptions (enfant, date ; l'application ne demande aucun motif)
• annulations de repas, déclarations de récupération (avec note facultative)
• votes aux sondages avec identifiant d'appareil (finalité : un vote par appareil)
• entrées du carnet de l'enfant concernant son propre enfant et rapports de groupe (affichage seul)
• carte de récupération Wallet : nom ou surnom de l'enfant, code enfant, établissement, adresse, groupe
• jetons push des appareils (pseudonymes) avec affectation au groupe et identifiants d'enfants enregistrés
• charges utiles push selon les types (1) à (7) du §2
• personnes venant chercher l'enfant (nom, lien), demandes d'entretien (sujet, choix du créneau), réponses aux rendez-vous, signalements de participation et de paiement, libérations (affichage seul)

§4 Sous-traitants ultérieurs (application Eltern et application Personnel)

Pour l'application Eltern et l'application Personnel, les sous-traitants ultérieurs supplémentaires suivants sont employés. Avec Cloudflare, Expo et Google (Firebase Cloud Messaging), un contrat distinct de sous-traitance (DPA) existe à chaque fois. Avec Apple, il n'existe pas de DPA pour l'Apple Push Notification service ; s'applique l'Apple Developer Program License Agreement, y compris l'Attachment 1.

Remarque concernant Apple (APNs) : Apple ne propose pas, pour l'Apple Push Notification service, de contrat de sous-traitance au sens de l'art. 28 RGPD ni de clauses contractuelles types spécifiques à APNs. La base contractuelle est l'Apple Developer Program License Agreement, y compris l'Attachment 1 (Additional Terms for Apple Push Notification Service and Local Notifications). Le DPLA actuel ne comporte pas de Schedule 4 à contenu relatif à la protection des données. Apple Inc. est certifiée au titre du Cadre de protection des données UE-États-Unis. APNs est l'infrastructure de plateforme d'iOS ; sans cette voie, le push iOS n'est pas possible.

APNs, FCM et Expo n'ont aucun contact avec la base de données Supabase de l'application principale. Les contenus des messages n'y sont pas stockés durablement. Ce que Cloudflare enregistre dans Cloudflare KV (résidence des données dans l'UE) figure au §10 al. 1 ; Cloudflare n'a pas accès à la base de données Supabase. Si le responsable du traitement ou les représentants légaux n'activent pas les notifications push et les éléments Wallet, le recours à Expo (650 Industries Inc.), à Firebase Cloud Messaging (Android) et à l'Apple Push Notification service (iOS) comme sous-traitants ultérieurs n'a pas lieu. Condition : la demande d'autorisation pour les services push (iOS/Android) est refusée sur l'appareil. L'enregistrement en KV du mot de passe parents subsiste tant que l'application Eltern est activée pour l'établissement.

Précision sur l'indication « transit uniquement » du tableau : La mention « transit uniquement » figurant pour l'Apple Push Notification Service (APNs), Firebase Cloud Messaging (FCM) et Expo se rapporte aux contenus des messages (charge utile push, contenus Wallet) : ceux-ci ne sont pas stockés durablement chez les services push, mais traités exclusivement pendant la durée de la distribution (dans des structures en mémoire ou de file d'attente, et non dans des bases de données). Les jetons d'appareil eux-mêmes (jetons d'appareil APNs, jetons d'enregistrement FCM, ExpoPushTokens) sont traités et enregistrés chez les services push respectifs pendant la durée de validité du jeton, car sinon la distribution ne serait pas possible pour des raisons systémiques. Cet enregistrement des jetons fait partie de l'infrastructure de la plateforme et non du contenu proprement dit de la sous-traitance des données de la KiTa.

Aucune alternative technique : il n'existe pas, au niveau des plateformes, d'infrastructure push exclusivement européenne ou indépendante des fournisseurs pour iOS et Android. APNs est l'unique voie de distribution autorisée pour le push iOS, FCM l'unique voie autorisée pour le push Android. Le déplacement de ces services vers une infrastructure UE, ou l'évitement de l'enregistrement des jetons chez les services push, ne peut être ni configuré ni empêché au niveau de l'application. Expo n'est utilisé que comme couche d'orchestration entre l'application et APNs/FCM, afin de permettre une mise en œuvre indépendante de la plateforme.

Consentement manuel de l'utilisateur (opt-in) : le traitement par APNs, FCM et Expo repose exclusivement sur une activation manuelle et explicite de l'autorisation push par l'utilisateur concerné, via la demande d'autorisation du système d'exploitation (iOS/Android). Cela vaut pour les représentants légaux dans l'application Eltern et pour les collaborateurs dans l'application Personnel. Qui installe l'application Personnel et accorde l'autorisation sur l'appareil consent ainsi à nouveau à la distribution sur cet appareil. Si l'utilisateur refuse l'autorisation ou la retire ultérieurement dans les réglages de l'appareil, toute génération et transmission ultérieure de jetons aux sous-traitants susmentionnés cesse. L'enregistrement des données métier reste à Supabase Francfort ; le transit par APNs, FCM et Expo n'est techniquement pas possible autrement pour la distribution sur iOS et Android.

Remarque sur le rôle de Cloudflare : Cloudflare achemine les requêtes API de l'application Eltern et l'envoi push des deux applications (routage en périphérie, terminaison TLS, protection DDoS) et enregistre dans Cloudflare KV, avec résidence des données dans l'UE, les données mentionnées au §10 al. 1. Le carnet de l'enfant et le rapport de groupe sont transmis à l'application Eltern via Cloudflare et n'y sont pas enregistrés. Cloudflare n'a pas accès à la base de données Supabase du sous-traitant. Le transit API et KV sont configurés dans l'UE (Cloudflare Regional Services / Francfort).

§5 Transfert international de données

(1) Le transfert vers Cloudflare, Expo et Google (Firebase Cloud Messaging) repose sur la décision d'adéquation de la Commission européenne au sens de l'art. 45 RGPD (Cadre de protection des données UE-États-Unis, décision d'exécution (UE) 2023/1795), dans la mesure où le prestataire concerné est certifié. En complément, des clauses contractuelles types au sens de l'art. 46 al. 2 lit. c RGPD (décision d'exécution (UE) 2021/914) ont été conclues avec ces prestataires.

(2) Pour APNs s'applique le Cadre de protection des données UE-États-Unis, dans la mesure où Apple Inc. est certifiée. Apple ne conclut pas de clauses contractuelles types pour APNs. Le Developer Program License Agreement, y compris l'Attachment 1, s'applique.

(3) Le sous-traitant vérifie régulièrement la validité du Cadre de protection des données UE-États-Unis. En cas de caducité, il fait basculer dans les meilleurs délais la base de transfert chez les prestataires ayant conclu des clauses contractuelles types vers ces seules clauses. Pour APNs, la base DPF disparaît dans ce cas ; le push iOS peut alors être désactivé sans compromettre le produit de base (§10 al. 8).

§6 Renvoi

Pour le surplus, les dispositions du contrat de sous-traitance s'appliquent.

État : octobre 2026.

Annexe 2B : Complément - application Personnel (iOS/Android)

Le complément suivant régit le traitement de données dans le cadre de l'application Personnel optionnelle destinée aux collaborateurs de l'établissement. Il s'applique si le responsable du traitement utilise l'application Personnel. Pour les services push, le Wallet, les sous-traitants ultérieurs et le transfert international, les §4 et §5 de l'annexe 2A s'appliquent.

§1 Base juridique et caractère volontaire

(1) Le traitement a lieu dans le cadre de la relation de travail entre le responsable du traitement et ses collaborateurs. Le responsable du traitement assure la base juridique, notamment au titre de l'art. 6 al. 1 lit. b et c RGPD, de l'art. 9 al. 2 lit. b RGPD pour les déclarations de maladie, d'un accord d'entreprise ou de service au sens de l'art. 88 RGPD ou du droit national de l'État membre du responsable du traitement.

(2) L'utilisation de l'application Personnel est volontaire pour les collaborateurs. Le temps de travail dans l'établissement est enregistré au terminal ; les absences et communications sont également possibles sans l'application. La non-utilisation ne doit entraîner aucun inconvénient.

§2 Nature et finalité du traitement

• temps de travail personnels et compte d'heures supplémentaires ; enregistrement en télétravail avec catégorie de travail ; demandes d'ajustement
• déclarations d'absence et de maladie
• planning journalier de l'équipe
• chat interne du personnel, Pinnboard et sondages ; messages aux parents (après nouvelle saisie du mot de passe)
• Postfach (boîte de réception) : messages directs de la direction à une personne unique, réponses aux demandes concernant le temps de travail et propres rendez-vous du personnel à venir
• badge de service Wallet
• notifications push : feu (annexe 2A §2) ainsi que chat d'équipe, appels, indications automatiques, rappels de rendez-vous, Postfach, confirmation du temps de travail et fin de la prise en charge (voir ci-dessous)

Minimisation des données : l'application Personnel est conçue pour utiliser le moins de données possible. Elle ne collecte aucune donnée de localisation, n'accède ni aux photos, ni aux contacts, ni au microphone, et ne contient aucun outil d'analyse ou de suivi ; l'appareil photo ne sert qu'à scanner son propre code QR lors de la connexion. Ce que l'application affiche sur les enfants dépend du mode de protection des données (§4 al. 1a) : en mode « Private Telefone », elle n'affiche aucune donnée de base sur les enfants, seulement des valeurs de comptage ; en mode « Dienstgeräte », elle peut afficher les noms des enfants du groupe propre, dans la mesure où une fonction en a besoin. Elle n'affiche en aucun mode les codes enfant. Les textes libres de collègues ou de la direction, ainsi que le sujet d'un rendez-vous d'entretien indiqué par les parents, peuvent, dans les deux modes, contenir des indications sur des enfants. Les données métier ne sont pas enregistrées sur l'appareil, mais chargées à chaque appel depuis la base de données de l'UE ; ne restent sur l'appareil que les jetons de session dans le stockage protégé de l'appareil. Une session dure au maximum 30 jours.

Chemin des données : les requêtes de l'application Personnel vont, chiffrées, directement à l'application (Vercel, Francfort, annexe 1), puis à Supabase Francfort, et non via Cloudflare. Les notifications push passent par le worker push Cloudflare (annexe 2A).

Chat d'équipe, appels et indications. Les destinataires sont exclusivement les appareils de l'application Personnel. Le responsable du traitement peut désactiver le chat d'équipe dans l'application Personnel (activé par défaut).

• Push du chat : titre = nom de la personne rédactrice, texte = texte du chat (raccourci). Destinataires selon le marquage : toute l'équipe, le personnel d'un groupe ou les personnes mentionnées ; sans marquage, pas de push. Cela comprend les contributions que la direction confirme via l'autopilote.
• Corrections d'horaires effectuées depuis l'application Personnel vont à la direction sous forme de demande d'ajustement, et non dans le chat d'équipe ; la fonction n'existe que si le pointage d'entrée et de sortie dans l'application est activé.
• Appels : push « <Name> ruft Sie » avec le motif, uniquement à la personne appelée, si elle a pointé son arrivée.
• Indications automatiques (expéditeur « Automatischer Hinweis »), activables séparément pour chaque règle dans les paramètres du chat. Réglages par défaut : pause obligatoire désactivée, « Tages-Arbeitszeit erreicht » activé, « geplant, aber nicht da » activé (uniquement si la planification du personnel est active). « Nicht ausgecheckt » sert à la documentation complète de la présence et ne peut pas être désactivé. Les indications nomment la personne concernée et sont visibles dans le chat d'équipe. Le push part, pour la pause obligatoire, « Tages-Arbeitszeit erreicht » et « Nicht ausgecheckt », uniquement à la personne concernée ; pour « geplant, aber nicht da », au personnel du groupe.
• Rappels de rendez-vous ne mentionnent que le type, l'heure et le groupe.
• Postfach : la direction écrit dans l'application web un message direct à une personne unique ; seule celle-ci le lit dans l'application Personnel. L'envoi et la suppression exigent le mot de passe administrateur. Pas de fonction de réponse, pas d'envoi par e-mail. Les messages restent enregistrés jusqu'à ce que le responsable du traitement les supprime ; il n'existe pas de suppression automatique. Push « Neue Nachricht im Postfach » sans expéditeur ni contenu.
• Confirmation du temps de travail : push à la personne elle-même après un pointage d'entrée, de sortie ou de changement dans l'application, avec événement et heure, sans noms.
• Fin de la prise en charge : à partir du 1er novembre 2026, une fois par jour, peu après la fin des horaires d'ouverture, aux personnes dont l'arrivée dans la prise en charge est encore pointée (et non au personnel de l'intendance), avec un texte fixe sans noms.

Conformément à l'usage prévu, les contenus comprennent des indications d'organisation et de temps de travail, et non des données sensibles concernant les enfants. Les messages du chat d'équipe provenant de l'application Personnel ne sont contrôlés avant envoi que par le garde-fou de données IA, si le responsable du traitement l'a activé pour le chat d'équipe (§4 al. 1a, annexe C §3 n° 18) ; les autres textes libres ne sont pas filtrés techniquement.

Les collaborateurs qui installent l'application Personnel accordent eux-mêmes l'autorisation push sur l'appareil et peuvent la retirer à tout moment dans les réglages de l'appareil. L'enregistrement des données métier reste à Supabase Francfort.

§3 Catégories de données traitées

• nom ou sigle, identifiant du personnel, données de connexion (code QR et mot de passe personnel, jetons de session)
• temps de travail personnels et compte d'heures supplémentaires, enregistrement en télétravail, demandes d'ajustement
• déclarations d'absence et de maladie (motif et note facultative ; données de santé au sens de l'art. 9 RGPD), y compris le motif lors d'un départ anticipé et lors de la question hebdomadaire sur les heures négatives ; catalogue et visibilité selon le §3 du présent contrat
• planning journalier de l'équipe : noms, services, pauses et présence actuelle des collègues ; motifs d'absence uniquement pour la personne elle-même, les autres apparaissent comme « abwesend »
• messages du chat (contenu, nom ou sigle de l'expéditeur), contributions du Pinnboard, votes aux sondages, messages aux parents
• Postfach : messages directs de la direction (destinataire, titre, texte, moment)
• en mode « Dienstgeräte » : noms des enfants du groupe propre, uniquement pour affichage dans les fonctions qui en ont besoin ; pas d'enregistrement sur l'appareil, pas de transmission aux fonctions d'IA
• badge de service Wallet : nom, identifiant du personnel, groupe
• jetons push des appareils (pseudonymes, liés à l'identifiant du personnel) ; contenus push selon le §2
• appels (personne appelante et appelée, motif, réponse et moment), mentions @
• dangers : notes avec la personne rédactrice, triangles d'alerte et « pouce levé » par personne ; image d'aperçu d'un thème selon l'annexe C §3 n° 15
• réservations de salles avec la personne qui réserve
• calendrier : rendez-vous de l'établissement et propres rendez-vous du personnel
• questions à l'assistant IA, si activé (transmission seulement, pas d'enregistrement ; annexe C §3 n° 4)

§4 Paramètres, appareils et obligations du responsable du traitement

(1) Paramètres. Le responsable du traitement définit dans les paramètres les fonctions de l'application Personnel qui sont utilisées. Réglages par défaut : application Personnel, chat d'équipe, pointage d'entrée et de sortie dans l'application et messages aux parents activés, chacun désactivable ; planning journalier et semaine d'équipe uniquement si la planification du personnel est active (désactivé par défaut) ; conservation du chat d'équipe 1 jour (au choix de 1 à 7) ; indications automatiques selon le §2 ; assistant IA désactivé (annexe C §3 n° 4) ; mode de protection des données « Private Telefone » ; garde-fou de données IA dans le chat d'équipe désactivé. Les paramètres sont des instructions au sens du présent contrat.

(1a) Mode de protection des données. Le responsable du traitement choisit pour l'établissement l'un de deux modes ; le mode vaut pour tous les appareils sur lesquels l'application Personnel est connectée.

• a) Private Telefone (réglage par défaut) : l'application n'affiche aucune donnée sur les enfants, seulement des valeurs de comptage ; les fonctions qui ont besoin de noms d'enfants sont bloquées. Les textes libres ne doivent contenir ni noms ni descriptions reconnaissables d'enfants. Le sous-traitant recommande d'activer le garde-fou de données IA dans le chat d'équipe.
• b) Dienstgeräte : par ce choix, le responsable du traitement déclare que l'application n'est exploitée que sur ses appareils et ne sélectionne ce mode que dans ce cas. L'application peut afficher les noms des enfants du groupe propre, dans la mesure où une fonction en a besoin ; à la date du présent contrat, aucune fonction ne le fait encore, la première prévue étant la demande d'un entretien avec les parents. Dans le chat d'équipe, des enfants peuvent être nommés dans la mesure où cela est nécessaire au déroulement de la journée ; les données de santé ainsi que les indications relatives à la protection de l'enfance ou à l'autorité parentale n'y ont pas leur place non plus. Le sous-traitant recommande le garde-fou de données IA dans le chat d'équipe également dans ce mode.

Le garde-fou de données IA du chat d'équipe fonctionne de la même manière dans les deux modes (annexe C §3 n° 18). Les règles applicables aux textes libres sont fixées par le responsable du traitement à l'intention des collaborateurs, conformément à l'al. 4.

(2) Appareils. L'application Personnel peut être utilisée sur les appareils de service du responsable du traitement et, dans la mesure où il l'autorise, sur les appareils privés des collaborateurs. Le sous-traitant recommande un fonctionnement exclusivement sur des appareils de service appartenant à l'établissement. L'application n'accède pas aux contenus privés de l'appareil (§2). Le sous-traitant ne fournit pas de gestion d'appareils (MDM) et ne peut ni consulter les appareils ni les effacer à distance.

(3) Appareils privés. Si le responsable du traitement autorise des appareils privés, il en fixe au préalable les conditions (instruction de service ou accord d'entreprise ou de service). Il s'assure que l'utilisation est volontaire, qu'une alternative équivalente existe (terminal, appareil de service ou signalement à la direction) et que la non-utilisation n'entraîne aucun inconvénient. L'utilisation sur des téléphones privés constitue donc une option que le responsable du traitement peut choisir.

(4) Information. Le responsable du traitement informe les collaborateurs avant la première utilisation (art. 13 RGPD), y compris des paramètres choisis, et attire leur attention sur les obligations de diligence : verrouillage de l'écran, pas de transmission du mot de passe ni du badge, déconnexion sur les appareils partagés, signalement sans délai de la perte, pas de données de santé dans les textes libres et indications sur les enfants uniquement selon l'al. 1a, pas de captures d'écran et pas de transmission.

(5) Appareils de service partagés. La connexion est personnelle et vaut jusqu'à 30 jours ; il n'existe pas de déconnexion automatique. Le responsable du traitement règle la déconnexion après usage.

(6) Cogestion. Certaines fonctions sont susceptibles de surveiller le comportement ou la performance, notamment les temps de travail enregistrés et le compte d'heures, le planning journalier avec présence actuelle, les indications automatiques activées, les appels avec réponse, les sondages avec vote personnel, un assistant IA activé avec noms pour les directions, ainsi que l'enregistrement du temps, l'IA de planification de service, l'analyse journalière, l'autopilote du Träger et les schémas de présence des fonctions d'IA (annexe C §1 al. 14). Si le responsable du traitement introduit l'application Personnel ou l'une de ces fonctions, il respecte les droits de participation des représentants des salariés (selon le droit national de l'État membre du responsable du traitement, indications par pays à l'annexe 6), conclut le cas échéant un accord d'entreprise ou de service et règle en conséquence les interrupteurs de l'al. 1.

(7) Départ. Si le responsable du traitement archive une personne, le logiciel met fin à toutes ses sessions (un jeton d'accès déjà émis reste valable au maximum 15 minutes), supprime son mot de passe d'application et désinscrit ses appareils de l'envoi push ; son badge de service n'est plus accepté au terminal.

(8) Perte d'un appareil. Le responsable du traitement remplace dans l'administration le badge QR de la personne ; cela produit le même effet que l'al. 7. Le sous-traitant apporte son soutien sur demande.

(9) Écran verrouillé. Le contenu des notifications push peut être visible sur l'écran verrouillé et rester dans le centre de notifications ; les collaborateurs peuvent désactiver l'aperçu dans les réglages de l'appareil.

§5 Renvoi

Pour le surplus, les §4 et §5 de l'annexe 2A ainsi que les dispositions du contrat de sous-traitance s'appliquent.

État : octobre 2026.

Annexe C : Complément - fonctions d'IA

Le présent complément régit le traitement de données dans le cadre des fonctions d'IA. Elles sont disponibles dans l'interface d'administration (application web), dans l'espace Träger, sur la tablette de groupe (dictée vocale) et, uniquement si l'établissement l'active, comme assistant IA dans l'application Personnel ; si quelqu'un crée un thème Gefahren dans l'application Personnel, son image d'aperçu naît selon le §3 n° 15. Sur les terminaux d'enregistrement, il n'existe aucune fonction d'IA ; dans l'application Eltern, seule la traduction par IA est disponible (§3 n° 17), et uniquement si l'établissement a choisi le niveau « Alle ». Les fonctions d'IA peuvent être activées et désactivées individuellement ; avec une fonction désactivée, les flux de données correspondants ne sont plus traités. Ce que l'IA apprend sur des personnes est régi par le niveau de protection des données IA (§1 al. 5). Un Träger peut bloquer des fonctions pour tous les établissements qui lui sont rattachés et plafonner le niveau ; les établissements ne peuvent pas lever ce blocage. Le logiciel est pleinement utilisable sans fonctions d'IA.

§1 Constats communs

Les constats suivants valent pour tous les flux de données mentionnés au §3, sauf disposition expressément contraire à cet endroit. Ils sont posés ici une seule fois et ne sont pas répétés dans chaque flux.

(1) Sous-traitant ultérieur : Google Ireland Ltd. / Google Cloud (Vertex AI / Gemini Enterprise Agent Platform). La base contractuelle est le Vertex AI Data Processing Addendum. L'authentification se fait sans clés API, par Workload Identity Federation (Vercel OIDC) ; en développement local, par Application Default Credentials (ADC). Hébergement de l'application appelante : Vercel (annexe 1). Base de transfert ou garantie contre les accès potentiels : Cadre de protection des données UE-États-Unis, complété par des clauses contractuelles types.

(2) Résidence des données : tous les flux de données, à l'exception de la génération d'images, passent par le point de terminaison de juridiction multirégional UE (aiplatform.eu.rep.googleapis.com). Le traitement est contractuellement limité à la zone géographique UE (pas de verrouillage sur une seule région en Allemagne). Exception pour la génération d'images : Google ne fournit pas les modèles d'image sur le multirégional UE. Ce flux de données utilise le point de terminaison mondial ; pour lui, il n'existe aucune garantie de résidence dans l'UE. Vers le point de terminaison mondial ne vont que des descriptions d'images sans lien avec des personnes (indications de style, de couleur et de conception, y compris le nom de l'établissement, ainsi qu'une description d'objets sans personnes, préalablement produite sur le point de terminaison UE) ; les photos, le texte libre de l'établissement, les noms, identifiants et descriptions de personnes ne vont pas au point de terminaison mondial. Par dérogation, avec le générateur d'images utilisant le modèle hors UE, le texte libre et les images de référence de l'utilisateur ou de l'utilisatrice vont au point de terminaison mondial (§3 n° 19). L'exception est également mentionnée au §10 de l'AVV.

(3) Modèles (état au 19.10.2026), tous via Google Cloud (Vertex AI) : texte et compréhension gemini-3.8-flash (UE) ; tâches rapides comme la dictée, la traduction et les contrôles gemini-3.5-flash-lite et gemini-3.1-flash-lite (UE) ; Claude Haiku 5.5 d'Anthropic (claude-haiku-5-5, dans le Model Garden de Google Cloud, sur le point de terminaison multirégional Europe, traitement en Europe ; le partenaire contractuel reste Google) ; génération d'images gemini-3.1-flash-image et gemini-3.1-flash-lite-image (mondial). Un changement vers un autre modèle du même sous-traitant ultérieur, sur le même point de terminaison, est documenté comme précision selon le §12 al. 4.

(4) Pas d'entraînement : les saisies ne sont pas utilisées pour entraîner des modèles d'IA (conditions contractuelles de Vertex). Conservation chez Google : Google ne conserve pas les saisies durablement, en principe. Si des filtres de sécurité automatiques détectent un soupçon d'abus, Google peut conserver les prompts concernés, exclusivement pour contrôler l'abus, pendant 90 jours au maximum, et ce dans la multirégion UE choisie pour le projet.

(5) Niveau de protection des données IA : ce que l'IA apprend sur des personnes est déterminé par un niveau à trois valeurs : a) « Aus » : l'Autopilot (y compris l'IA de planification de service, « Eigener Export » et l'analyse journalière) et l'assistant IA de l'application Personnel sont désactivés ; b) « Pseudonymisiert » : les enfants et les éducateurs:trices n'apparaissent que sous forme d'identifiants (par exemple « Kind 7F3A », « Erzieher:in K2QM ») ; c) « Alle » : les vrais noms des éducateurs:trices et des enfants. L'établissement choisit son niveau dans les paramètres ; le réglage par défaut est « Alle ». Celui qui passe d'un niveau inférieur à « Alle » le confirme séparément. Avant l'utilisation, le responsable du traitement vérifie si le réglage par défaut correspond à ses exigences (art. 25 al. 2 RGPD) et, dans le cas contraire, choisit un niveau inférieur. Le Träger peut fixer pour tous les établissements qui lui sont rattachés un niveau maximal ; le niveau effectif est toujours le plus bas des deux. Sans niveau maximal fixé, aucune limitation ne s'applique. Si le logiciel ne peut pas lire le niveau maximal d'un Träger, il fonctionne avec « Pseudonymisiert ». Indépendamment du niveau, les motifs d'absence et les autres indications de santé ne sont jamais transmis à l'IA en lien avec une personne, mais tout au plus sous forme de nombre.

(6) Champ d'application du niveau : le niveau vaut pour les fonctions qui lisent les données d'exploitation du logiciel : chat Autopilot, « Eigener Export », IA de planification de service, analyse journalière, assistant IA de l'application Personnel ainsi que, pour chaque établissement, l'Autopilot du Träger et le rapport mensuel. L'IA de planification de service et l'assistant IA pour la direction ne fonctionnent qu'au niveau « Alle » ; l'assistant IA pour les éducateurs:trices fonctionne à tout niveau sauf « Aus », toujours avec des identifiants. Le niveau ne vaut pas pour les fonctions qui traitent uniquement ce que les utilisateurs:trices saisissent, disent ou téléversent eux-mêmes (par exemple dictée, assistant e-mail, entretien avec les parents, brouillons de textes, plan des locaux, site Internet) ; celles-ci sont pilotées par des interrupteurs propres (al. 8). Ce que l'équipe écrit elle-même (en particulier chat d'équipe, Pinnwände, notes et rendez-vous), l'IA le lit à tout niveau sauf « Aus » tel qu'il a été écrit, y compris les noms qui y figurent.

(7) Pseudonymisation et pilotage : les identifiants sont formés par le sous-traitant avant la transmission, à partir de l'identifiant interne de la personne, avec une clé secrète. La même personne porte durablement le même identifiant ; Google ne peut pas en déduire la personne. La correspondance entre identifiants et noms n'est connue que du sous-traitant ; elle est enregistrée avec le déroulement de la journée (al. 12), afin que les utilisateurs:trices autorisés voient la réponse avec les noms. Les données pseudonymisées restent des données à caractère personnel. Google ne voit les saisies que de façon transitoire, sous réserve du contrôle d'abus selon l'al. 4. Le texte libre et les téléversements sont pilotés par les utilisateurs:trices ; l'interface demande de ne pas saisir de données de santé, mais ce qui est saisi ou téléversé est transmis dans tous les cas. Le responsable du traitement donne les instructions correspondantes à ses utilisateurs:trices. Les boutons qui déclenchent une fonction d'IA sont uniformément signalés dans l'interface d'administration (violet avec symbole d'étincelle).

(8) Interrupteurs : en complément du niveau, l'établissement peut désactiver individuellement : le constructeur de site Internet, la dictée vocale (et avec elle l'assistant e-mail, l'entretien avec les parents, les lettres aux parents et les brouillons de textes par IA), le plan des locaux à partir d'une photo, la traduction par IA (§3 n° 17) et le garde-fou de données IA (§3 n° 18). Seule l'activation par l'établissement permet le fonctionnement de la génération d'images et de l'assistant IA de l'application Personnel. Le Träger peut bloquer pour tous les établissements qui lui sont rattachés des fonctions individuelles, bloquer toutes les fonctions avec traitement hors UE (actuellement la génération d'images, y compris les images d'aperçu des thèmes Gefahren, et le modèle hors UE du générateur d'images) et désactiver le rapport mensuel. Si le logiciel ne peut pas lire un blocage du Träger, celui-ci est considéré comme posé. Un niveau maximal « Aus » du Träger désactive les fonctions selon l'al. 6 phrase 1, mais pas les fonctions pilotées par des interrupteurs propres. Ne peuvent pas être désactivés le chat d'aide et le chat AVV, qui ne traitent aucune donnée d'exploitation. Les fonctions qui ne travaillent que sur appel explicite d'un utilisateur ou d'une utilisatrice ne transmettent rien tant qu'elles ne sont pas utilisées. L'IA Gefahren et le brouillon de manuel n'ont actuellement pas d'interrupteur propre. Le sous-traitant peut à tout moment désactiver certaines fonctions d'IA pour des raisons de sécurité ou d'exploitation.

(9) Mise en œuvre des résultats : les résultats de l'IA sont des propositions et des brouillons. Les actions proposées par l'Autopilot (par exemple un message aux parents, une contribution au chat d'équipe, une planification de pause ou un check-out) ne sont exécutées par le logiciel qu'après confirmation individuelle par la direction, qui s'est préalablement identifiée avec le mot de passe administrateur. Exception IA de planification de service : sur instruction de la personne qui planifie, elle modifie directement le plan de service ; chaque modification est signalée, journalisée et peut être annulée. Aucun résultat de l'IA n'est envoyé sans action d'un utilisateur ou d'une utilisatrice ; font exception l'analyse journalière et le rapport mensuel, qui sont envoyés par e-mail à la direction ou aux utilisateurs du Träger.

(10) Processus automatiques : en principe, un appel n'a lieu que sur action d'un utilisateur ou d'une utilisatrice. Exceptions : l'analyse journalière, le rapport mensuel et l'image d'aperçu d'un thème Gefahren nouvellement créé.

(11) Boîte de dialogue d'information : avant la première utilisation du chat Autopilot, de l'IA de planification de service, de « Eigener Export », du chat d'aide, de l'Autopilot du Träger et du chat AVV, une boîte de dialogue d'information liée au compte s'affiche ; la confirmation est enregistrée de façon versionnée dans le compte utilisateur. Cette boîte de dialogue sert à la transparence et ne constitue pas un consentement au sens de l'art. 6 al. 1 lit. a RGPD.

(12) Conservation chez le sous-traitant (serveurs en Allemagne) : a) historique du chat Autopilot et de l'IA de planification de service : par utilisateur ou utilisatrice, par établissement et par jour, 60 entrées au maximum ; suppression automatique après un délai d'un à sept jours choisi par l'établissement (réglage par défaut : à la fin du jour civil, dans le fuseau horaire de l'établissement). « Eigener Export », le chat d'aide, le chat AVV, l'Autopilot du Träger et l'assistant IA de l'application Personnel ne sont pas conservés. b) actions Autopilot confirmées et paquets de modifications de l'IA de planification de service (avec l'état avant la modification) : jusqu'à leur suppression selon le §8 de l'AVV. c) analyses journalières et rapports mensuels : jusqu'à leur suppression selon le §8 de l'AVV. d) assistant e-mail (e-mails types, consigne, résultat), entretiens avec les parents (rapport, tâches, version destinée aux parents) et consentements à des enregistrements, y compris la signature : jusqu'à ce que l'établissement les supprime, au plus tard selon le §8 de l'AVV. e) pour chaque appel d'IA, un enregistrement d'usage sans contenu (établissement, Träger, fonction, modèle, données de quantité) pour la facturation du crédit IA. f) traductions selon le §3 n° 17 avec une valeur de contrôle de l'original, sans l'original : 30 jours au maximum. Le fait que les entrées selon a) à c) contiennent des noms ou des identifiants dépend du niveau effectif (al. 5). L'audio n'est jamais conservé durablement : les dictées vont directement à l'IA ; les enregistrements d'entretiens avec les parents ne restent dans un stockage protégé que jusqu'à la fin de l'évaluation, puis sont supprimés, même si l'évaluation échoue. Les photos pour le plan des locaux et le brouillon de manuel, ainsi que les images et images de référence du générateur d'images, et les documents téléversés et les lettres générées pour les lettres aux parents ne sont pas conservés ; les modèles de lettre épurés restent conservés jusqu'à ce que l'établissement les supprime (§3 n° 20). Les erreurs techniques vont à Sentry (annexe 1), sans contenus de chat, de prompt, d'audio ou d'image.

(13) Crédit IA : les fonctions d'IA consomment un crédit mensuel ou unique de l'établissement ou du Träger. Une fois épuisé, le logiciel refuse les appels supplémentaires ; le chat d'aide et le chat AVV sont gratuits et exemptés ; les processus automatiques (al. 10) ne sont pas bloqués.

(14) Finalité liée aux données du personnel : le logiciel traite les données de présence, de temps de travail et de planning de service du personnel à trois fins : respect de l'obligation de surveillance et du taux d'encadrement pour protéger les enfants, enregistrement du temps de travail et facturation, ainsi que respect du droit du temps de travail. Pour la planification de la dotation, les fonctions d'IA peuvent décrire des schémas de présence, y compris en lien avec certains membres du personnel (par exemple heures d'arrivée habituelles ou accumulation d'absences certains jours de la semaine). Elles n'évaluent ni la performance ni le comportement : pas de jugements, pas de classements, pas de comparaisons entre personnes, pas de suppositions sur les motifs ou la santé. L'IA de planification de service planifie à partir des contrats, des absences, des qualifications et des besoins. Les droits de participation des représentants des salariés (selon le droit national de l'État membre du responsable du traitement, indications par pays à l'annexe 6) demeurent inchangés ; le responsable du traitement peut régler l'utilisation de ces fonctions dans un accord d'entreprise ou de service et régler le niveau de protection des données IA en conséquence.

(15) Protection des saisies : ce que les utilisateurs:trices saisissent dans les fonctions d'IA relève de la responsabilité du responsable du traitement et de son personnel (annexe 4 §3). Comme mesure technique de protection supplémentaire, l'IA est instruite de ne pas traiter les saisies qui contiennent certaines indications. Elle signale alors l'erreur et interrompt l'opération, sans répéter l'indication, sans appeler d'outils et sans proposer d'actions :

• a) toujours : données de santé d'enfants ou du personnel et autres catégories particulières au sens de l'art. 9 RGPD, soupçons de mise en danger du bien de l'enfant, indications relatives à l'autorité parentale, décisions de justice, interdictions de contact et conflits familiaux, données d'accès (mots de passe, PIN, codes QR et codes enfant), numéros bancaires, d'identité, fiscaux et de sécurité sociale, ainsi que les évaluations de membres du personnel pris individuellement (al. 14) ;
• b) selon le niveau effectif de protection des données IA : au niveau « Pseudonymisiert », noms de membres du personnel et d'enfants ; dans l'assistant IA de l'application Personnel pour les éducateurs:trices, toujours des noms ;
• c) selon la fonction : dans le chat d'aide et le chat AVV, toute indication concernant des personnes réelles ; pour les brouillons de site Internet et de consentements, noms et descriptions de certains enfants.

Sont exclus la dictée vocale (transformation littérale en texte) et l'exploitation d'entretiens enregistrés avec les parents. Une saisie interrompue n'est pas conservée. Elle a toutefois déjà atteint l'IA à ce moment-là et, comme toutes les saisies, n'a été traitée que sur le point de terminaison UE (al. 2), n'y a pas été utilisée pour l'entraînement et n'a pas été conservée durablement chez le sous-traitant ultérieur (al. 4). La détection repose sur l'IA et n'est pas exhaustive ; elle ne remplace pas les obligations du responsable du traitement selon l'annexe 4 §3.

(16) Recherche sur Internet : dans le chat Autopilot, dans l'Autopilot du Träger, dans le chat « Mit KI schreiben » de la rétroaction vers le Träger et lors de « KI destillieren » (Gefahren), l'IA peut effectuer une recherche générale sur Internet (recherche Google) et afficher la réponse avec ses sources. La question ne contient ni noms, ni adresses, ni indications sur des enfants, des représentants légaux ou du personnel ; une question contenant un nom issu de la demande en cours est refusée par le logiciel. Google peut conserver les requêtes de recherche jusqu'à trois jours ; cela ne peut pas être désactivé. Le sous-traitant peut désactiver cette fonction de manière centralisée.

§2 Finalités

Conseil et évaluation pour l'établissement (chat Autopilot, « Eigener Export », analyse journalière), planification de service (IA de planification de service), information pour le personnel (assistant IA de l'application Personnel), évaluations pour le Träger (Autopilot du Träger, rapport mensuel), aide sur le produit et explication du contrat (chat d'aide, chat AVV), transformation de la parole en texte (dictée), rédaction de textes (assistant e-mail, brouillons de textes par IA, site Internet), documentation des entretiens avec les parents, évaluation des dangers et manuels (IA Gefahren, brouillon de manuel), illustration (génération d'images) et planification des locaux (plan à partir d'une photo), chaque fois selon le niveau et les interrupteurs du §1.

§3 Les flux de données

1. Chat Autopilot et « Eigener Export » (interface d'administration, uniquement avec le mot de passe administrateur). Saisies : questions de la direction, chemin de la page et sorties d'outils, donc indicateurs (feu, capacité, présence par catégorie, sous-effectif, prévu/réel, horaires d'ouverture, seuils, modèles de prise en charge), journaux par personne (présence, événements, plans de service et de pause) selon le niveau, noms de groupes et de modèles de prise en charge, ainsi que texte libre de l'équipe (§1 al. 6). Pour « Eigener Export », l'IA formule une voie de calcul que le sous-traitant exécute dans un environnement isolé sur les données de l'établissement ; l'IA ne voit pas les données sur lesquelles porte ce calcul. Actions selon le §1 al. 9. Niveau : tel que paramétré.

2. IA de planification de service (planification du personnel). Saisies : plan de service de la période visible, personnes avec temps contractuels, minutes planifiées et absences sans motif, besoin en personnel par tranche de 15 minutes, enfants uniquement sous forme de totaux. Elle modifie directement le plan de service (§1 al. 9). Niveau : uniquement « Alle ».

3. Analyse journalière (automatique peu avant l'heure de fermeture, les jours de forte occupation ; la première sans demande de confirmation, chaque suivante seulement après accord de la direction ; absente au niveau « Aus »). Saisies comme au n° 1. Destinataire : la direction, par e-mail. Conservation selon le §1 al. 12 c.

4. Assistant IA de l'application Personnel (uniquement après activation par l'établissement). Répond aux questions sur ce que l'application affiche déjà à la personne connectée (temps de travail propre, plan de service, occupation, chat d'équipe, Pinnwände, dangers, manuels) ; lecture seule. Pour les éducateurs:trices toujours avec identifiants, pour la direction avec noms du personnel au niveau « Alle ». Texte libre selon le §1 al. 6. Aucune conservation chez le sous-traitant.

5. Autopilot du Träger (espace Träger, uniquement pour les utilisateurs:trices ayant un rôle Träger). Saisies : questions des utilisateurs:trices du Träger et sorties d'outils sur les établissements rattachés, donc indicateurs, heures planifiées, services, comptes d'heures et jours d'absence par personne avec statut d'approbation ; motifs d'absence uniquement sous forme de nombre. Noms du personnel et textes d'événements (qui peuvent contenir des noms d'enfants) uniquement pour les établissements au niveau « Alle », sinon des identifiants. Pour chaque établissement vaut le niveau le plus bas entre son propre réglage et le niveau maximal du Träger ; les établissements au niveau « Aus » ne sont pas inclus. Aucune conservation.

6. Rapport mensuel (automatique le premier jour du mois ; désactivable par le Träger). Saisies : indicateurs mensuels agrégés sans noms de personnes, noms des établissements et désignations des jours de fermeture. Destinataires : utilisateurs:trices du Träger, par e-mail. Conservation selon le §1 al. 12 c.

7. Chat d'aide. Saisies : questions formulées librement, chemin de la page et documentation produit ; aucune donnée d'exploitation. Aucune conservation.

8. Chat AVV (espace Träger). Saisies : questions formulées librement et le texte du présent contrat ; aucune donnée d'exploitation. L'IA explique exclusivement le texte du contrat et ne fournit aucun conseil juridique. Aucune conservation.

9. Dictée vocale (tablette de groupe : rapport journalier, rapport sur un enfant). Saisie : enregistrement audio ; il peut contenir des voix d'enfants, des noms et des observations. Seule la transformation en texte a lieu ; le texte est conservé dans le rapport journalier, l'enregistrement jamais.

10. Assistant e-mail. Saisies : exemples d'e-mails insérés par l'établissement (ils peuvent contenir des noms et des contenus de correspondance avec des parents) et la consigne tapée ou dictée. Résultat : un brouillon qui n'est pas envoyé. Conservation selon le §1 al. 12 d.

11. Entretien avec les parents (uniquement avec le mot de passe administrateur). Saisie : enregistrement d'un entretien d'au maximum 30 minutes ; il contient tout ce qui est dit, y compris les noms et, le cas échéant, des indications sur la santé et le développement de l'enfant. Les noms ou autres données de l'enfant issus du logiciel ne vont pas à l'IA. Le logiciel n'exploite un enregistrement que si des consentements enregistrés à l'avance existent pour l'entretien, dont au moins celui d'un parent ; les consentements sont signés à l'écran ou donnés par e-mail confirmé et valent pour un seul enregistrement. Résultat : rapport interne avec tâches et une version pour les parents, qui ne sont pas envoyés. Conservation selon le §1 al. 12 d.

12. Brouillons de textes par IA (textes de consentement ; retour au Träger). Saisies : titre et mots-clés tels que l'établissement les saisit. Le résultat remplit le formulaire ; aucune conservation avant reprise.

13. Constructeur de site Internet. Saisies : réponses de la direction dans l'assistant d'établissement (textes, indications de contact et de mentions légales) et, le cas échéant, deux images de style propres ; les images de style sont décrites par l'IA sur le point de terminaison UE, seule cette description va à la génération d'images. Conception et textes sur le point de terminaison UE ; images selon le n° 14.

14. Génération d'images pour le site Internet et le logo du terminal (uniquement après activation par l'établissement ; pouvant être bloquée par le Träger). Saisies : indications de style, de couleur et de conception ainsi que le nom de l'établissement ; aucune donnée personnelle, aucune photo. Point de terminaison mondial (§1 al. 2).

15. Image d'aperçu d'un thème Gefahren (automatique après création, y compris depuis l'application Personnel ; exclue par le blocage hors UE du Träger). Étape 1 (point de terminaison UE) : la photo ou le texte du thème ; l'IA ne décrit que des objets et le danger, aucune personne, et rejette les photos qui montrent principalement des personnes. Étape 2 (point de terminaison mondial) : uniquement cette description. L'image d'aperçu est enregistrée avec le thème.

16. Plan des locaux à partir d'une photo, IA Gefahren et brouillon de manuel. Plan des locaux : une photo d'un croquis de pièce (elle peut montrer des personnes si celles-ci figurent sur l'image), non conservée. IA Gefahren : thème et notes de l'équipe, tels qu'ils ont été écrits ; le résultat est constitué de propositions que seule la direction reprend. Brouillon de manuel : jusqu'à cinq photos d'un guide imprimé ou une description de la direction ; les photos ne sont pas conservées.

17. Traduction par IA (interrupteur « Übersetzung », activé par défaut ; effective uniquement au niveau « Alle », dans la mesure où le niveau maximal du Träger la permet). Traduction dans la langue des représentants légaux que l'établissement a enregistrée pour l'enfant ou, tant qu'aucune langue n'y figure, que les représentants légaux ont choisie dans l'application Eltern (allemand, anglais, turc, arabe, ukrainien, russe, polonais, roumain) : a) e-mails de l'établissement aux représentants légaux (demandes de consentement, procuration de récupération, courrier QR, confirmation de rendez-vous) ; les noms, dates, liens et codes sont remplacés au préalable par des espaces réservés et ne vont pas à l'IA ; l'IA lit le texte libre de l'établissement tel qu'il a été écrit ; b) contenus de l'application Eltern (messages, rendez-vous, blog, rapports de groupe, notes du carnet, notes sur les demandes d'entretien) ; l'IA lit l'intégralité du texte tel qu'il a été écrit, y compris les noms et, dans les notes du carnet, le cas échéant des indications de santé sur l'enfant ; c) le sujet d'une demande d'entretien des représentants légaux, retraduit dans la langue de l'établissement sur pression du bouton par la direction. Traitement sur le point de terminaison UE (§1 al. 2). Seule la traduction est conservée, avec une valeur de contrôle de l'original, et non l'original (§1 al. 12 f). Les notifications push ne sont pas traduites. Sans traduction par IA, la traduction reste sur l'appareil des représentants légaux (annexe 2A).

18. Garde-fou de données IA (interrupteur « KI-Datenwächter », activé par défaut et toujours affiché). Le garde-fou ne fonctionne qu'au niveau « Alle », parce que l'IA doit pour cela lire le texte complet ; aux autres niveaux, il est désactivé, et l'interface l'indique. Sans crédit IA, seule la comparaison des noms sans IA a lieu. Avant qu'un texte écrit dans l'application web ne parte vers des représentants légaux ou le public (messages et Pinnwand, y compris sondages, messages à une famille, rendez-vous, rapports de groupe et notes du carnet libérés, blog, textes du site Internet et mentions légales), il est contrôlé. D'abord, le serveur le compare sans IA aux noms des enfants de l'établissement ; la liste des noms ne quitte pas le serveur. Ensuite, l'IA (avec crédit) contrôle les indications selon le §1 al. 15 a) ainsi que les noms ou descriptions reconnaissables d'enfants individuels et de personnes privées adultes ; les prénoms et noms complets des enfants y sont remplacés par des espaces réservés, les autres noms sont traités tels qu'ils ont été écrits. Pour un message à une famille, le nom de l'enfant choisi ne compte pas comme constat. L'IA ne fournit qu'un jugement et une catégorie et ne modifie pas le texte. Un texte critique ne peut être envoyé que par la direction, après nouvelle saisie du mot de passe administrateur. Si le contrôle n'est pas possible, le texte est envoyé et une indication est affichée. Les textes ne sont pas conservés ; seul le processus est compté, sans texte et sans personne. Un message direct de la direction à une personne unique (Postfach de l'application Personnel, annexe 2B §2) est également contrôlé. Dans le chat d'équipe, le garde-fou ne contrôle que si le responsable du traitement active en plus l'interrupteur « KI-Datenwächter im Team-Chat » (désactivé par défaut) ; il contrôle alors aussi les messages de l'application Personnel. Là, seul le contrôle par l'IA a lieu, sans comparaison de noms, et sans crédit IA aucun contrôle n'a lieu. En cas de constat, le message n'est pas envoyé ; la personne qui écrit peut le modifier ou l'envoyer malgré tout. Les autres textes de l'application Personnel, y compris les appels et les messages aux parents, ne sont pas contrôlés. Le contrôle n'est pas exhaustif et ne modifie rien à l'annexe 4 §5 al. 5.

19. Générateur d'images (uniquement après déblocage par le Träger, désactivé par défaut, et activation par l'établissement ; signalé comme fonction d'IA). Les utilisateurs:trices décrivent une image en texte libre et peuvent téléverser une image de référence, seulement après avoir confirmé qu'elle ne montre ni personnes ni enfants ; sans cette confirmation, le serveur ne l'accepte pas. Ils choisissent un modèle ; le logiciel indique pour chaque modèle s'il traite dans l'UE ou hors UE (point de terminaison mondial, §1 al. 2, sans garantie de résidence dans l'UE). Le texte libre et les images de référence vont sans modification au modèle choisi. Les images de référence ne doivent montrer ni personnes ni autres données à caractère personnel (sont admises, par exemple, des images librement utilisables trouvées sur Internet ou des images propres sans personnes) ; le texte libre ne contient ni noms ni descriptions de personnes réelles. Cette obligation incombe aux utilisateurs:trices (annexe 4 §3) ; le logiciel ne contrôle pas les images de référence. Les images générées sont téléchargées sur l'appareil de l'utilisateur ou de l'utilisatrice ; les images générées et les images de référence ne sont pas conservées chez le sous-traitant. Le blocage du Träger « Bild-KI außerhalb der EU sperren » désactive tous les modèles hors UE.

20. Lettres aux parents (via l'interrupteur de la dictée vocale ; envoi uniquement avec le mot de passe administrateur). a) Modèle : l'établissement téléverse une lettre existante (PDF, fichier Word ou photo). L'IA reçoit le document intégralement, tel qu'il est, et remplace les indications personnelles par des espaces réservés (par exemple « {Kind} », « {Eltern} ») ; les adresses e-mail et numéros de téléphone restants sont en outre retirés par le logiciel. Seul le modèle épuré est conservé, jusqu'à ce que l'établissement le supprime, avec le nombre des indications retirées par catégorie, jamais leurs valeurs ; le document téléversé n'est pas conservé. Le responsable du traitement répond du contenu du document téléversé (annexe 4 §3). b) Lettre : sur demande de modification, l'IA rédige une lettre avec des espaces réservés ; les noms et indications des enfants ne parviennent jamais à l'IA. Le logiciel insère pour chaque enfant les valeurs (nom, pseudonyme, date de naissance, âge, groupe, modèle de prise en charge, dates d'admission et d'entrée à l'école ; pour « Eltern » apparaît « Eltern von » avec le prénom de l'enfant). Si l'établissement a enregistré la langue des représentants légaux, l'IA traduit la version à espaces réservés (n° 17). c) Sortie : pour chaque enfant, un PDF à télécharger (ZIP) ou un e-mail avec le texte de la lettre et le PDF à l'adresse des représentants légaux enregistrée pour l'enfant (expéditeur « [Nom de l'établissement] via Bienenstock », envoi via Brevo, annexe 1), au maximum une fois par enfant et par envoi. Chaque e-mail envoyé figure dans le journal d'envoi ; les e-mails qui n'ont pas pu être remis figurent sans adresse et sans texte d'erreur comme indication pour l'établissement, jusqu'à ce qu'il la traite. Le garde-fou de données IA ne contrôle pas le texte de la lettre. Traitement sur le point de terminaison UE (§1 al. 2).

§4 Base juridique et obligations du responsable du traitement

(1) Le traitement a lieu pour le compte et sur instruction du responsable du traitement ; le choix du niveau et l'activation ou la désactivation des fonctions selon le §1 sont des instructions.

(2) Dans la mesure où des catégories particulières de données à caractère personnel peuvent être concernées (en particulier la dictée, l'entretien avec les parents et le texte libre de l'équipe), le responsable du traitement assure une base juridique au sens de l'art. 9 al. 2 RGPD.

(3) Les enregistrements d'entretiens (§3 n° 11) supposent le consentement de tous les participants à l'entretien (selon le droit national de l'État membre du responsable du traitement). Le logiciel vérifie uniquement si des consentements enregistrés selon le §3 n° 11 existent ; le recueil du consentement de toutes les personnes présentes, y compris du personnel, incombe au responsable du traitement.

(4) La boîte de dialogue d'information selon le §1 al. 11 n'est pas un consentement au sens de l'art. 6 al. 1 lit. a RGPD.

§5 Renvoi

Pour le surplus, les dispositions du contrat de sous-traitance s'appliquent.

État : octobre 2026.

Annexe 3 : Dispositions complémentaires pour les Träger ecclésiastiques et publics

Non applicable en dehors de l'Allemagne.

Annexe 4 : Champs de texte libre

§1 Notion

Les champs de texte libre sont des champs de saisie dans lesquels les utilisateurs peuvent écrire ou dicter un texte quelconque, par exemple des notes, des messages, des motivations, des descriptions et des contributions de chat. Les données à caractère personnel qui figurent dans un champ de texte libre sont déterminées uniquement par la personne qui écrit. Le sous-traitant ne peut ni limiter le contenu à l'avance, ni le reconnaître a posteriori.

§2 Vue d'ensemble selon le risque

(1) Risque élevé (contenus concernant un enfant en particulier, la santé ou le comportement de membres du personnel sont probables, ou le texte atteint les parents, l'IA ou le Träger) :

• notes sur l'enfant dans les données de base et dans le carnet de l'enfant, rapports journaliers de groupe, y compris lorsqu'ils sont dictés (dictée désactivable, activée par défaut) ; les représentants légaux ne reçoivent les notes et rapports journaliers que si le responsable du traitement active l'affichage dans l'application Eltern (désactivé par défaut) et si le personnel libère l'entrée concernée
• entretiens avec les parents : enregistrement, rapport et version pour les parents ; motifs des entretiens et demandes d'entretien des représentants légaux
• messages et contributions de Pinnwand aux représentants légaux, ainsi que messages à une famille (y compris sous forme de notification push)
• chat interne du personnel, y compris Pinnboard et appels ; demandes de correction du temps de travail
• notes sur les absences et les arrêts maladie du personnel
• notes dans le domaine Gefahren
• notes d'événement de la direction qui entrent dans les rapports et évaluations pour le Träger
• saisies dans l'assistant e-mail
• notes sur les récupérations et les annulations de repas, autres motifs d'absence du personnel

(2) Risque moyen (lien avec des personnes probable, cercle de destinataires limité) : motifs des corrections de temps, notes de service et de rapport ; rendez-vous pour les parents et le personnel ; personnes autorisées à venir chercher l'enfant et remises exceptionnelles ; notes sur les paiements ; retours au Träger et réponses, notes internes du Träger sur les candidatures ; textes du propre site Internet et du blog (publics) ; saisies dans les fonctions d'IA.

(3) Risque faible (indications d'organisation) : désignations de groupes, de salles, de modèles et d'occasions ; réservations de salles, motifs de fermeture, articles de manuel et descriptions de libérations.

La liste actuelle des champs, avec leurs destinataires et leurs délais de suppression, est mise à disposition par le sous-traitant sur demande, sous forme écrite.

§3 Obligations du responsable du traitement

(1) Le responsable du traitement décide si et à quelles fins son personnel utilise les champs de texte libre, et instruit les utilisateurs de ne saisir que ce qui est nécessaire à la finalité (art. 5 al. 1 lit. c RGPD).

(2) Les catégories particulières (art. 9 RGPD), en particulier les diagnostics, les suppositions sur des maladies, les médicaments et les blessures, ainsi que les indications sur l'autorité parentale, les conflits familiaux et les interdictions de contact, ne sont saisies que dans la mesure où une base juridique existe et où le champ y est destiné ; jamais dans le chat interne du personnel, dans les messages aux représentants légaux, dans les notes Gefahren ni dans les saisies destinées aux fonctions d'IA.

(3) Les évaluations de la performance ou du comportement de membres du personnel pris individuellement n'ont leur place ni dans le chat du personnel, ni dans les notes Gefahren. Le responsable du traitement respecte les dispositions relatives aux données des salariés et, si elle existe, la participation de la représentation du personnel.

(4) Avant de libérer un texte pour des représentants légaux ou de le publier sur le site Internet, le responsable du traitement vérifie si le texte contient des données de tiers, en particulier celles d'autres enfants.

(5) Le responsable du traitement supprime les textes libres dont il n'a plus besoin ; le logiciel propose à cet effet des fonctions de suppression.

§4 Prestations du sous-traitant

(1) Le sous-traitant n'exploite pas les textes libres à ses propres fins, ne les analyse pas quant à leur contenu et ne les utilise pas pour entraîner des modèles d'IA.

(2) Les textes libres ne vont aux fonctions d'IA que selon l'annexe C et en fonction des réglages du responsable du traitement (niveau et interrupteurs, annexe C §1 al. 5 à 8). Les fonctions qu'un utilisateur déclenche au cas par cas (par exemple assistant e-mail, entretien avec les parents, IA Gefahren, brouillons de textes et de manuel) transmettent intégralement le texte sélectionné ; lorsque la traduction par IA est activée (annexe C §3 n° 17), cela vaut pour les contenus traduits.

(3) Les textes libres ne sont pas filtrés techniquement. Font exception le rejet de saisies destinées à l'IA (al. 5) et le garde-fou de données IA pour les textes destinés aux représentants légaux et au public (annexe C §3 n° 18).

(4) Délais de suppression : le chat interne du personnel selon le §3 de l'AVV (contributions du Pinnboard exceptées) ; l'historique du chat Autopilot selon l'annexe C §1 al. 12 ; les enregistrements d'entretiens immédiatement après leur évaluation ; les candidatures selon le §8 al. 8. Tous les autres textes libres restent enregistrés jusqu'à ce que le responsable du traitement les supprime ou que le contrat prenne fin (§8).

(5) Pour soutenir le responsable du traitement, l'IA rejette les saisies contenant des indications inadmissibles (annexe C §1 al. 15).

§5 Textes destinés aux représentants légaux

(1) Certains champs de texte libre transmettent leur contenu aux représentants légaux ou au public. Le logiciel signale ces champs de manière visible pour le personnel et indique qui reçoit le texte.

(2) Cercles de destinataires :

• Tous : tous les représentants légaux de l'établissement
• Groupe ou modèle de prise en charge : les représentants légaux des enfants des groupes ou modèles de prise en charge choisis
• Enfant : uniquement les appareils sur lesquels cet enfant est enregistré
• Public : toute personne, dans la mesure où le responsable du traitement publie des contenus sur son site Internet. Pour le site Internet, ses mentions légales et sa déclaration de confidentialité, seul le responsable du traitement est compétent (Conditions d'utilisation, section 9c) ; le sous-traitant les diffuse uniquement sur le plan technique.

(3) Formats :

• messages et contributions de Pinnwand, y compris avec sondage : à tous ou à des groupes
• message à une famille (texte libre de la direction) : à l'enfant, dans l'application Eltern et, sur demande, en plus par e-mail (al. 7)
• rendez-vous avec titre, description et, le cas échéant, coûts, y compris avec acceptation ou refus de participation : à tous ou à des groupes ou modèles de prise en charge ; sur demande, date et titre aussi sur le site Internet
• jours de fermeture et fermetures avec motif : à tous
• plan des repas : à tous
• rapport de groupe (rapport journalier d'un groupe) : au groupe, uniquement après libération par le personnel
• note du carnet de l'enfant : à l'enfant, uniquement après libération par le personnel
• postes de paiement et rendez-vous d'entretien : à l'enfant
• lettres aux parents : pour chaque enfant, à l'adresse e-mail enregistrée des représentants légaux (annexe C §3 n° 20)
• articles de blog : à tous dans l'application Eltern et au public sur le site Internet

Les notifications push correspondantes suivent l'annexe 2A §2.

(4) Avec l'affichage, les contenus sont transmis aux destinataires ; les représentants légaux peuvent les réutiliser librement, y compris avec leurs propres programmes et services d'IA (annexe 2A).

(5) Le responsable du traitement instruit son personnel d'être extrêmement réservé pour les textes destinés à tous, aux groupes et au public : pas de noms ni de descriptions reconnaissables d'autres enfants, pas de données de santé, pas d'indications sur des familles, des conflits ou des incidents concernant des personnes précises. Même les textes concernant un enfant ne contiennent aucune indication sur d'autres enfants. Les messages à une famille ne contiennent que ce qui concerne cette famille ; les indications de santé concernant l'enfant de cette famille uniquement dans la mesure où la finalité l'exige. Avant l'envoi, le responsable du traitement vérifie l'enfant choisi, car un envoi à la mauvaise famille constitue une violation de données à caractère personnel (art. 33 RGPD).

(6) Le garde-fou de données IA (annexe C §3 n° 18) assiste en la matière ; les obligations selon l'al. 5 demeurent à la charge du responsable du traitement.

(7) Message à une famille. a) Envoi : la direction choisit un enfant et rédige un texte ; avant l'envoi, le logiciel affiche clairement l'enfant choisi. Le message apparaît dans l'application Eltern sur les appareils de cet enfant (notification push selon l'annexe 2A §2 (7)). Sur demande de la direction, il part en plus par e-mail à l'adresse des représentants légaux enregistrée pour l'enfant (expéditeur « [Nom de l'établissement] via Bienenstock », envoi via Brevo, annexe 1 ; uniquement après nouvelle saisie du mot de passe administrateur ; entrée dans le journal d'envoi ; remise comme à l'annexe 5 §4 al. 2). b) Réponses : les représentants légaux ne répondent pas par texte libre, mais uniquement par une action prédéfinie par la direction, dans l'application ou via un lien limité dans le temps figurant dans l'e-mail : « OK » (prise de connaissance), « Annehmen » (accepter), « Termin » (choix d'un rendez-vous proposé) ou « Beitreten » (acceptation d'un rendez-vous de l'établissement). L'action et son horodatage sont enregistrés auprès de l'enfant. Si « Annehmen » concerne une libération, l'octroi s'effectue exclusivement par le consentement par e-mail selon l'annexe 5 ; une réponse dans l'application n'est pas un octroi. Le logiciel ne vérifie pas, au-delà de la connaissance du lien ou de l'accès à l'application Eltern, qui a répondu. c) Conservation : le message et les réponses restent enregistrés jusqu'à ce que le responsable du traitement les supprime ou que le contrat prenne fin (§4 al. 4).

État : octobre 2026.

Annexe 5 : Consentements, libérations et personnes autorisées à venir chercher l'enfant

§1 Objet et rôle du logiciel

(1) La présente annexe décrit les fonctions « Freigaben », « Einwilligung per E-Mail », « Abholberechtigte », « Abholperson anmelden » (application Eltern) et « Übergabe-Nachweis » (vue par groupe).

(2) Le logiciel est en l'occurrence un outil de documentation et de communication. Il consigne ce que l'établissement saisit et ce qui est confirmé sur la page de confirmation, et il affiche des indications au personnel. Il ne décide pas si un consentement est valable ni si un enfant est remis à une personne. Ces décisions relèvent du seul responsable du traitement, par l'intermédiaire de son personnel.

§2 Libérations

(1) Le responsable du traitement crée les libérations (titre et description) et en détermine seul le contenu. Le logiciel ne distingue pas entre les consentements au sens du RGPD, les consentements à des mesures concernant l'enfant et les autres autorisations. Les brouillons de la fonction IA « Mit KI formulieren » ne constituent pas un conseil juridique (annexe C).

(2) Chaque établissement dispose d'une libération fixe « Foto des Kindes auf den Geräten der KiTa », au texte prédéfini, que le responsable du traitement ne peut pas modifier. Sans octroi actif, aucune photo de l'enfant ne peut être enregistrée ni affichée ; en cas de retrait, la photo est supprimée, au plus tard lors de la vérification quotidienne.

(3) Une libération naît selon deux voies :

a) Saisie par l'établissement. Le personnel coche la case au nom de l'enfant dans l'administration. Sont enregistrés l'horodatage, l'origine « Einrichtung », ainsi que le titre et la description dans leur formulation d'alors. Aucun justificatif, par exemple une déclaration signée, n'est enregistré ; le responsable du traitement le conserve lui-même.

b) Confirmation par e-mail. L'établissement déclenche, pour chaque enfant et chaque libération, un e-mail envoyé à l'adresse qu'il a enregistrée pour l'enfant (§4). L'e-mail contient le titre et la description ainsi qu'un lien vers la page de confirmation. Le lien est valable une heure et une seule fois. Consulter la page ne produit aucun effet ; seul le clic sur « Freigabe erteilen » enregistre l'octroi, avec l'origine « Eltern », l'horodatage et le texte envoyé par e-mail.

(4) La confirmation échoue si, d'ici là, le titre ou la description ont été modifiés, si la libération a été archivée ou retirée, si l'adresse enregistrée a été modifiée ou si l'enfant a été archivé. Le consentement porte toujours sur le texte envoyé par e-mail.

(5) Lors de la confirmation, ne sont enregistrés ni le nom, ni l'adresse IP, ni l'appareil de la personne qui clique. La confirmation atteste qu'elle a été donnée via la boîte e-mail enregistrée, mais pas quelle personne a confirmé.

(6) Le retrait est déclaré par les représentants légaux à l'établissement ; le personnel l'inscrit dans l'administration. Les octrois et les retraits ne sont ni modifiés ni supprimés, mais complétés. Si le responsable du traitement supprime un enfant au lieu de l'archiver, ses octrois sont également supprimés.

(7) Les représentants légaux voient les libérations de leur enfant dans l'application Eltern, sans possibilité de modification. Le personnel les voit dans l'administration ; elles ne sont pas affichées dans la vue par groupe ni dans l'application Personnel, à l'exception de l'effet de la libération photo.

§3 Personnes autorisées et remise

(1) L'établissement tient pour chaque enfant une liste des personnes autorisées à venir le chercher (nom, lien). Les personnes sont désactivées, et non supprimées.

(2) Lorsque la fonction « Abholperson in der App anmelden » est activée (désactivée par défaut), l'application Eltern permet :

a) de déclarer pour un jour, comme personne venant chercher l'enfant, une personne déjà enregistrée. Le mot de passe parents de l'établissement et le code enfant suffisent à cet effet ; aucune confirmation par e-mail n'a lieu ;

b) d'indiquer une nouvelle personne avec son nom et son lien. Elle n'est enregistrée qu'une fois la procuration de récupération confirmée via l'adresse enregistrée pour l'enfant, selon la procédure du §2 al. 3 lit. b (lien valable une heure). La procuration est libellée ainsi : « Ich/Wir als Sorgeberechtigte bevollmächtigen [Name] ([Beziehung]), [Vorname des Kindes] in der Einrichtung [Name] abzuholen. Die Vollmacht gilt bis zum Widerruf gegenüber der KiTa. Die abholende Person weist sich bei der Abholung aus. » Sont enregistrés le nom, le lien, le texte de la procuration et l'horodatage de la confirmation.

(3) Une personne ainsi créée porte la mention « Neu – Ausweis prüfen » jusqu'à ce que le personnel inscrive « Ausweis geprüft » dans l'administration. Seul l'horodatage est enregistré, sans données de pièce d'identité, et sans indication de la personne qui a procédé à la vérification.

(4) Le personnel est informé d'une récupération déclarée, sans nom : par une indication automatique dans le chat du personnel (supprimée avec le chat) et, le jour de la récupération, par une indication dans la vue par groupe. Le nom, le lien et l'indication de vérification figurent dans la boîte de dialogue de remise. Aucune notification push n'est envoyée à cet effet.

(5) Dans le justificatif de remise (Übergabe-Nachweis), le personnel documente à qui l'enfant a été remis ou qui l'a amené, à titre exceptionnel à une personne non enregistrée, avec motivation, ainsi que la personne qui confirme la remise. L'indication « Bestätigt von » constitue une documentation ; elle n'est pas garantie par une connexion personnelle. Le justificatif est facultatif, séparé de l'enregistrement d'arrivée et de départ, et ne peut être ni modifié ni supprimé.

(6) Le logiciel n'empêche ni la remise ni le check-out, y compris à une personne sans vérification d'identité ni inscription dans la liste.

§4 E-mails aux représentants légaux

(1) Les e-mails selon les §§2 et 3 sont envoyés à l'unique adresse que l'établissement enregistre dans la fiche de l'enfant à l'usage de l'établissement. Ils partent au nom de l'établissement (expéditeur « [Nom de l'établissement] via Bienenstock ») via le service d'e-mail mentionné à l'annexe 1.

(2) Un e-mail est réputé envoyé lorsque le serveur de messagerie l'a accepté. Le logiciel ne sait pas s'il a été remis, classé comme spam ou lu ; les messages retournés ne sont pas exploités. Pour les libérations, l'administration affiche « wartet auf Bestätigung » et, après expiration du délai, « nicht bestätigt » ; pour les procurations de récupération, elle n'affiche la personne qu'une fois confirmée.

(3) Les demandes de libération figurent dans le journal d'envoi avec l'adresse du destinataire (§8 al. 8).

§5 Ce que le logiciel ne vérifie pas

Le logiciel ne vérifie pas :

a) qui déclenche une confirmation, ni si la boîte e-mail appartient à un représentant légal ou est accessible à des tiers ;

b) si l'adresse enregistrée est correcte ;

c) l'existence et l'étendue de l'autorité parentale, les décisions de justice, les interdictions de droit de visite ou de contact ;

d) si les deux représentants légaux consentent, lorsque cela est nécessaire ;

e) l'identité de la personne venant chercher l'enfant ;

f) le contenu, la validité et la base juridique d'une libération, ainsi que l'exactitude des saisies de l'établissement ;

g) qui signale une récupération dans l'application Eltern et qui est sélectionné comme personne confirmant dans le justificatif de remise.

§6 Obligations du responsable du traitement

Le responsable du traitement veille, par l'organisation et les instructions données à son personnel, notamment à ce que :

a) les textes de libération aient été vérifiés juridiquement, mentionnent la finalité, l'étendue, les destinataires, la durée et le retrait, et qu'une base juridique existe pour chaque libération ;

b) l'adresse e-mail enregistrée pour l'enfant soit exacte, appartienne à un représentant légal et soit mise à jour en cas de changement ;

c) il vérifie si l'accord des deux représentants légaux est nécessaire pour une libération ou une procuration de récupération et, le cas échéant, le recueille, par exemple au moyen d'une seconde déclaration sur papier ;

d) les indications sur l'autorité parentale, les décisions de justice et les interdictions de contact soient prises en compte en dehors du logiciel ou dans un champ prévu à cet effet (annexe 4 §3 al. 2) ;

e) pour chaque récupération par une personne qu'il ne connaît pas, le personnel vérifie son identité à l'aide d'une pièce d'identité officielle avant de remettre l'enfant, et inscrive la vérification dans l'administration ;

f) le personnel décide sur place de chaque remise, indépendamment des saisies et indications du logiciel, et que les indications du logiciel (chat, vue par groupe, signalements) soient effectivement lues dans le fonctionnement courant ;

g) les saisies par case à cocher ne soient effectuées que lorsque la libération a effectivement été octroyée, et que le justificatif correspondant soit conservé hors du logiciel ;

h) les retraits soient inscrits sans délai et les personnes autorisées désactivées dès que l'autorisation prend fin ;

i) le personnel sache quelles libérations valent pour un enfant avant d'agir en conséquence ;

j) les représentants légaux qui ne souhaitent pas ou ne peuvent pas utiliser l'e-mail disposent d'une alternative équivalente sur papier ;

k) les parents soient informés de ces fonctions (modèle d'information sur demande) ;

l) les enfants soient archivés plutôt que supprimés tant que la preuve des consentements est nécessaire.

§7 Prestations du sous-traitant

(1) Le sous-traitant enregistre les octrois, retraits, procurations et justificatifs de remise de façon à ce qu'ils ne puissent plus être modifiés après coup ; un octroi d'origine « Eltern » ne peut naître que par la page de confirmation.

(2) Il met à disposition des liens de confirmation comportant un jeton à usage unique, enregistré uniquement comme valeur de contrôle et valable une heure, et supprime l'adresse du destinataire et la valeur de contrôle selon le §8 al. 8.

(3) Il ne doit pas de prestations supplémentaires, notamment la vérification de l'identité, de l'autorité parentale ou de la validité, l'acheminement des e-mails ou l'empêchement de remises.

État : octobre 2026.

Annexe 6 : Indications par pays

La présente annexe indique, pour les États membres dans lesquels le sous-traitant propose le logiciel en dehors de l'Allemagne, les organismes et prescriptions auxquels le présent contrat renvoie par « droit national de l'État membre du responsable du traitement ». Elle ne fonde aucune obligation supplémentaire. Les indications marquées [verifiziert] ont été vérifiées par rapport à la source citée ; celles marquées [verify] sont encore ouvertes et doivent être vérifiées par rapport à la source avant toute utilisation.

§1 France

• Autorité de contrôle en matière de protection des données : Commission nationale de l'informatique et des libertés (CNIL). [verifiziert]
• Loi nationale de mise en œuvre : Loi n° 78-17 du 6 janvier 1978 (Informatique et Libertés). [verifiziert] Source : https://www.legifrance.gouv.fr/loda/article_lc/LEGIARTI000037822923/
• Participation de la représentation du personnel : Le comité social et économique (CSE) est informé et consulté avant l'introduction de moyens ou de techniques permettant de surveiller l'activité des salariés (information-consultation, Code du travail art. L2312-38). [verifiziert] Source : https://www.legifrance.gouv.fr/codes/article_lc/LEGIARTI000035610275/
• Information des salariés : Aucune collecte de données au moyen d'un dispositif qui n'a pas été porté préalablement à la connaissance des salariés (Code du travail art. L1222-4). [verify]
• Langue : Les documents qui fondent des obligations pour les salariés doivent être rédigés en langue française (Code du travail art. L1321-6) ; loi Toubon n° 94-665. [verify]

§2 Pays-Bas

• Autorité de contrôle en matière de protection des données : Autoriteit Persoonsgegevens (AP). [verifiziert]
• Loi nationale de mise en œuvre : Uitvoeringswet AVG (UAVG). [verify]
• Participation de la représentation du personnel : ondernemingsraad (OR) avec droit d'approbation (instemmingsrecht) ou personeelsvertegenwoordiging (PVT), selon la Wet op de ondernemingsraden (WOR). [verifiziert] Source : https://wetten.overheid.nl/BWBR0002747/
• Droit d'approbation pour les systèmes de suivi du personnel : art. 27 al. 1 lit. l WOR. [verify]

État : octobre 2026.