Aller au contenu Hors ligne — vous consultez une version enregistrée, en lecture seule.
Scout Magic

Protection des données

Dernière mise à jour : Date de publication

Modifications de cette politique : En cas de modification de cette politique de confidentialité, la date de dernière mise à jour ci-dessus sera modifiée. Nous vous encourageons à consulter régulièrement cette page pour rester informé.

1. Qui sommes-nous et objet de cette politique

Cette politique de confidentialité décrit de manière exhaustive comment notre unité scoute traite vos données personnelles dans le cadre de ce site web, conformément au Règlement Général sur la Protection des Données (RGPD — Règlement UE 2016/679) et à la législation belge en matière de protection de la vie privée.

1.1. Identité du responsable du traitement

Responsable du traitement : Le chef d'unité (responsable du groupe « chefs d'U ») de notre unité scoute.

Contact RGPD : Pour toute question relative à vos données personnelles ou pour exercer vos droits, contactez-nous à l'adresse email indiquée sur la page de contact du site. En tant qu'organisation à but non lucratif gérée par des bénévoles, nous nous engageons à traiter votre demande dans un délai raisonnable, en visant le délai d'un mois recommandé par l'article 12.3 du RGPD dans la mesure de nos moyens.

1.2. Cadre légal et fédération

Notre unité est affiliée à la fédération Les Scouts ASBL (n° d'entreprise BE0409580916, 21 rue de Dublin, 1050 Ixelles). Les données des membres sont également soumises à la politique de protection des données de la fédération, qui s'applique en complément de la présente page, notamment pour les traitements effectués via la plateforme Desk.

1.3. Acceptation de cette politique

En participant aux activités de l'unité scoute et en utilisant ce site web, les membres et leurs représentants légaux acceptent les termes de cette politique de confidentialité. L'inscription d'un membre ou la création d'un compte utilisateur implique l'acceptation du traitement des données personnelles tel que décrit dans ce document.

1.4. Formation des animateurs

Tous les animateurs de notre unité suivent régulièrement la formation Code Qualité des Adultes de la fédération Les Scouts, qui inclut une sensibilisation à la gestion des données personnelles et au respect de la vie privée des membres.

1.5. Logiciel open source

Ce site utilise un logiciel open source développé pour les unités scoutes belges, publié sous licence AGPL-3.0. Le code source est disponible publiquement et auditable. Les principales dépendances open source utilisées sont :

Ces composants sont maintenus par leurs communautés respectives et font l'objet de mises à jour de sécurité régulières.

1.6. Vérification des mises à jour

Le site est averti par GitHub, via un webhook (une requête entrante depuis github.com vers le site), lorsqu'une nouvelle version du logiciel est publiée, ou — si le mode développement est activé, réservé aux environnements de test — lorsqu'un nouveau commit est envoyé sur la branche surveillée. Le site interroge également ponctuellement l'API publique de GitHub (api.github.com) pour télécharger l'archive d'une mise à jour lors de son installation, automatique ou déclenchée par un administrateur. Aucune donnée personnelle ne transite dans ces échanges, dans un sens comme dans l'autre : il s'agit uniquement de métadonnées publiques (numéro de version, notes de version) et du code source du logiciel lui-même. GitHub n'est donc pas un sous-traitant au sens du RGPD pour ce site — il s'agit d'une intégration technique, mentionnée ici par souci de transparence.

2. Quelles données collectons-nous et pourquoi

2.1. Gestion des comptes et authentification

Finalité : Permettre l'accès sécurisé au site et gérer l'identité des utilisateurs.

Données traitées :

Base légale : Exécution d'un contrat (accès au service) et intérêt légitime (sécurité, information des membres).

2.2. Gestion des membres de l'unité

Finalité : Gérer les inscriptions, organiser les activités, communiquer avec les membres et leurs familles.

Données traitées : Les données des membres sont importées depuis la plateforme Desk de la fédération Les Scouts. Toutes sont chiffrées au repos (AES-256-GCM) :

Base légale : Intérêt légitime (gestion de l'unité scoute).

Documents privés : L'espace personnel d'un membre (« Espace des animés ») peut afficher des documents qui lui sont propres — une attestation fiscale, une attestation de présence après un camp. Ces documents sont chiffrés au repos et ne sont accessibles qu'aux comptes explicitement liés à ce membre et aux chefs d'unité. Ces derniers y ont accès depuis la fiche du membre, dans un seul but : répondre à une famille qui n'a pas reçu son document et le lui renvoyer. Chaque ouverture et chaque renvoi sont consignés au journal d'audit (identifiants techniques uniquement, jamais de contenu, jamais d'adresse). Un animateur de section n'y a aucun accès, quel que soit son rôle. Ces documents sont déposés par le module Attestations lorsqu'il est actif (section 2.4).

Adresse postale du responsable de section : Le nom complet et l'adresse postale du chef désigné responsable d'une section sont affichés, sur la page de chaque membre de cette section, aux comptes liés à ce membre (le membre lui-même, ses parents) — afin de faciliter le contact avec le responsable. Cette information reste soumise aux mêmes règles de chiffrement et n'est jamais publique. Sur la page « Sections », le nom complet du responsable — jamais son adresse — est également affiché à tout visiteur connecté, qu'il soit ou non lié à cette section, afin qu'une famille puisse savoir qui anime chaque section ; un visiteur non connecté n'y voit que son nom d'usage — le totem, ou le prénom à défaut, jamais le nom de famille.

Adresses email supplémentaires : Depuis son espace personnel (« Espace des animés »), un membre peut ajouter une ou plusieurs adresses email en complément de celle importée depuis Desk (chiffrées au repos avec index aveugle, au même titre que l'adresse Desk). Le domaine d'une adresse ajoutée est vérifié par une requête DNS au moment de l'ajout (limiter les fautes de frappe) — cette vérification ne transmet l'adresse à aucun tiers, seul le nom de domaine est interrogé. L'adresse doit ensuite être confirmée via un lien de validation envoyé par email (valable 48h, à usage unique) avant d'être utilisée pour l'envoi des communications groupées ou pour se connecter au site. Ces adresses sont liées au membre lui-même (et non à l'année scoute en cours) : elles sont donc conservées d'une année à l'autre. Un membre peut supprimer une adresse secondaire à tout moment ; l'adresse Desk ne peut ni être modifiée ni supprimée depuis le site, mais peut, elle aussi, être désinscrite des envois groupés (voir « Module Envoi de mails » ci-dessous pour les conséquences de cette désinscription, y compris sur la connexion).

Fichier d'import Desk conservé : Chaque import conserve le fichier CSV exporté depuis Desk qui l'a produit. Ce fichier contient, en clair à l'intérieur du document, l'ensemble des données listées ci-dessus pour toute l'unité — c'est l'artefact de données personnelles le plus dense du site. Il est chiffré au repos, n'est jamais écrit en clair de façon durable sur le serveur, n'est accessible qu'aux chefs d'unité, et chaque téléchargement est consigné dans le journal d'audit (identifiants techniques uniquement, jamais de contenu). Sa finalité est vérifiable : pouvoir réexaminer un import douteux en confrontant son rapport au fichier exact qui l'a produit. Sa durée de conservation figure en section 3.1.

Fiches fusionnées : Lorsqu'un membre revient après une absence et qu'il a été recréé dans Desk au lieu de voir son ancienne fiche rouverte, un chef d'unité peut réunir les deux fiches. Rien n'est alors supprimé : l'historique (années, photos, badges, documents, périodes de section) est rattaché à la fiche conservée, et l'ancienne fiche est gardée, marquée comme fusionnée. L'ancien numéro de tiers Desk est enregistré comme alias de la fiche conservée, afin qu'un import ultérieur ne recrée pas la scission. Chaque fusion est consignée au journal d'audit sous forme d'identifiants numériques uniquement, jamais de noms.

Historique d'appartenance aux sections : Le site conserve, pour chaque membre, l'historique des sections auxquelles il a appartenu au fil des années scoutes (y compris un changement de section en cours d'année) — cette information (aucune donnée personnelle au-delà de la référence au membre et à la section) sert uniquement à déterminer quels documents de section (voir ci-dessous) un membre peut consulter, aujourd'hui comme pour les années passées.

Marquage de départ : Un chef ou un animateur peut indiquer qu'un animé ne reviendra probablement pas l'année scoute suivante, bien qu'il soit encore inscrit sur Desk — cette information alimente les projections de places et d'effectifs de l'unité. Le motif éventuellement renseigné (souvent une information sensible : conflit, situation familiale, difficulté de l'enfant, parfois de santé) est chiffré au repos et n'est jamais visible dans le journal d'audit ni dans un message d'erreur.

Notes internes sur un membre : Les chefs d'unité peuvent consigner, sur la fiche d'un membre, des notes libres datées — chacune portant son auteur et sa date. Elles servent à transmettre d'un staff au suivant ce qu'il faut savoir pour bien accompagner un enfant (par exemple une allergie signalée par la famille, ou une difficulté à prendre en compte lors d'une activité). Ce texte est écrit librement : il peut donc contenir des informations sensibles, y compris de santé ou relatives à la situation familiale. Il est chiffré au repos et n'apparaît jamais dans le journal d'audit, ni dans un message d'erreur, ni dans un export, ni dans un publipostage. Ces notes ne sont jamais visibles par le membre ni par ses parents, ni sur sa page personnelle ni ailleurs, et ne sont accessibles qu'aux chefs d'unité — un animateur de section n'y a pas accès. Chaque ajout, modification et suppression est consigné au journal d'audit sous forme d'identifiants numériques uniquement, jamais de contenu. Toute personne y ayant accès peut corriger ou supprimer une note, y compris celle d'un autre : une note écrite par erreur sur la mauvaise personne doit pouvoir disparaître. Les notes sont rattachées à la personne et non à une année scoute : voir leur durée de conservation en section 3.1.

Documents de section : Les responsables d'une section (carnets de camp, feuilles d'activité, listes de matériel) peuvent y déposer des documents, chiffrés au repos comme tout autre fichier sur le site. Chaque document reste visible, sur sa propre page « Espace des animés », par tout membre ayant appartenu à cette section l'année scoute concernée — y compris les années précédentes, et même si la section a depuis été masquée ou n'a plus de membres actifs. Les documents PDF peuvent être compressés automatiquement en arrière-plan pour réduire leur taille (traitement effectué entièrement sur le serveur, jamais transmis à un service externe) ; le fichier reste consultable pendant toute la durée de cette opération.

2.3. Photos et droit à l'image

Finalité : Documenter les activités de l'unité, partager les souvenirs avec les parents et les membres, illustrer la vie scoute.

Consentement explicite : En participant aux activités de l'unité scoute, les parents et les membres acceptent explicitement que des photos de leurs enfants ou d'eux-mêmes puissent être prises lors des activités (réunions, camps, sorties).

Utilisation des photos :

Droit de retrait : Les parents ou les membres peuvent à tout moment demander le retrait d'une photo les concernant en contactant le responsable de l'unité. La demande sera traitée dans un délai raisonnable.

Base légale : Consentement explicite (participation aux activités) pour la prise de photos et le partage aux parents. Intérêt légitime pour la documentation des activités de l'unité.

2.4. Fonctionnalités optionnelles (modules)

Les fonctionnalités suivantes peuvent être activées ou désactivées par l'administrateur. Seuls les modules actifs traitent des données.

Module Calendrier

Finalité : Permettre aux membres de synchroniser les événements de l'unité avec leur calendrier personnel (Google Calendar, Outlook, etc.) via le protocole standard iCalendar (RFC 5545).

Données traitées :

Base légale : Intérêt légitime (faciliter la participation aux activités).

Risque : Le jeton ICS donne accès aux événements sans authentification. En cas de divulgation involontaire du lien iCal, il doit être régénéré via les préférences du compte.

Module Présences

Finalité : Permettre au staff d'une section de noter, réunion par réunion, quels animés étaient présents, afin de repérer un décrochage et d'en parler avec la famille.

Qui est concerné : les animés d'une section, et eux seuls. La présence des animateurs et des intendants n'est pas suivie.

Données traitées :

Qui peut les voir : les animateurs de la section concernée, et les chefs d'unité. Ce droit est recalculé à chaque consultation à partir des fonctions de l'année scoute en cours — un animateur qui quitte la section perd l'accès dès l'import suivant, sans que rien n'ait à être révoqué. Les familles ne voient jamais ces données, ni sur la page de leur enfant, ni ailleurs : c'est une appréciation du staff, elle reste au staff, au même titre que les notes internes sur un membre.

Sortie du site : un chef ou un animateur de la section peut exporter la section entière au format Excel, commentaires compris, pour préparer une conversation ou un conseil d'unité. Le fichier quitte alors les protections du site et sa diffusion relève de la personne qui l'a téléchargé ; l'export est journalisé sous forme de compteurs, sans aucun nom.

Base légale : Intérêt légitime (suivi de la participation des animés et sécurité de l'encadrement — savoir qui était présent lors d'une activité).

Module Covoiturage

Finalité : Permettre aux familles de proposer les places libres de leur voiture pour une sortie de l'unité, et d'en demander une pour leurs enfants, sans passer par un service extérieur.

Données traitées :

Les noms, les numéros de téléphone et la note sont chiffrés en base. Le numéro est recopié au moment où la personne le confirme — il est pré-rempli depuis sa fiche mais modifiable — et n'est jamais relu depuis la fiche ensuite : c'est le numéro qu'elle a vu et accepté de montrer qui est partagé.

Qui voit quoi : tous les membres identifiés voient les covoiturages et les voitures (conducteur, point de rendez-vous, heure, places libres). Le conducteur voit les demandes faites sur sa voiture ; une famille voit sa propre demande ; les animateurs d'une section concernée, le Staff d'Unité et les administrateurs voient qui monte dans quelle voiture. Un numéro de téléphone n'est montré qu'à l'autre partie d'une demande acceptée — le conducteur à la famille, la famille au conducteur — et à personne d'autre, animateurs compris.

Base légale : Intérêt légitime (faciliter la participation des enfants aux activités).

Module Réseaux sociaux

Finalité : Relier au site la Page Facebook et le compte Instagram de l'unité, et y publier un album ou une actualité.

Fonctionnement : l'unité relie sa propre Page Facebook et/ou son propre compte Instagram professionnel au moyen de sa propre application Meta. Le site ne publie jamais de lui-même : chaque publication est décidée par un animateur qui gère l'album ou peut modifier l'actualité, après avoir vu l'image exacte qui partira. Une publication est publique et le site ne peut pas la reprendre : elle se retire sur Facebook ou Instagram.

Données traitées :

Base légale : Intérêt légitime (faire connaître les activités de l'unité).

Module Gardes SOS (Staff d'Unité)

Finalité : Organiser les permanences téléphoniques des chefs et transférer automatiquement les appels entrants vers le chef de garde via un fournisseur de téléphonie sur IP.

Fournisseurs de téléphonie supportés : Actuellement, seul OVH Télécom (France, UE) est implémenté. D'autres fournisseurs (Twilio) sont prévus mais non disponibles.

Données traitées :

Transfert vers OVH Télécom : Les identifiants API sont envoyés à l'API OVH (https://eu.api.ovh.com) pour configurer le renvoi d'appel. OVH traite les numéros de téléphone pour le routage. Politique de confidentialité : OVH Cloud Privacy Policy.

Base légale : Intérêt légitime (organisation interne, joignabilité d'urgence).

Module Connecteur Intelligence Artificielle

Finalité : Automatiser des tâches administratives répétitives (reconnaissance de texte sur photos de factures, génération de contenu RGPD personnalisé) et répondre aux questions posées à l'assistant d'aide (section 2.7), via des modèles d'intelligence artificielle hébergés par des fournisseurs tiers.

Fournisseurs IA supportés :

Données traitées :

Transfert vers les fournisseurs IA : Les données envoyées dépendent de l'utilisation (OCR de factures : montants, noms de commerçants ; génération RGPD : aucune donnée personnelle). Les fournisseurs ne conservent pas les données au-delà du traitement (selon leurs politiques respectives). Pour Anthropic (USA), le transfert est encadré par les Standard Contractual Clauses (SCC) de la Commission européenne.

Base légale : Intérêt légitime (efficacité administrative, réduction de la charge de travail des bénévoles).

Module Photos et vidéos

Finalité : Permettre le partage de photos et vidéos des activités de l'unité entre les membres identifiés (animés, chefs), organisées en albums associés à une date, un titre et éventuellement une section.

Données traitées :

Stockage des fichiers : l'administrateur peut configurer plusieurs emplacements de stockage à la fois (le serveur de l'hébergeur pour le stockage local, et/ou un ou plusieurs stockages externes : fournisseur de stockage objet compatible S3, partage WebDAV, dossier Google Drive) — chaque album est associé, dès sa création, à l'un de ces emplacements, qui ne change jamais ensuite pour cet album, même si l'emplacement proposé par défaut pour les nouveaux albums change par la suite (voir section 4.2 pour le ou les sous-traitants de stockage effectivement configurés). Un emplacement local n'introduit aucun sous-traitant supplémentaire. Les fichiers ne sont pas chiffrés au repos (il ne s'agit pas de données personnelles au sens strict), mais leur accès est restreint aux utilisateurs identifiés (rôle minimum requis).

Suppression : la suppression d'un album entraîne la suppression immédiate et définitive de l'ensemble des photos et vidéos qu'il contient, quel que soit le support de stockage utilisé.

Base légale : Intérêt légitime (partage de souvenirs entre membres de l'unité) et consentement explicite pour la prise et le partage de photos (voir section 2.3).

Module Discussions

Finalité : Permettre aux membres d'une section, et aux membres invités d'un groupe créé par un chef, d'échanger entre eux dans un espace privé propre à l'unité — messages, réponses, photos, vidéos et réactions.

Données traitées :

Qui peut voir quoi : un groupe est privé et invisible aux non-membres — il n'existe ni annuaire, ni groupe public, ni demande d'adhésion. Ses membres sont les membres de la ou des sections liées au groupe pour l'année scoute concernée, plus les membres explicitement invités par un chef. Cette liste est recalculée à chaque consultation : un membre qui quitte une section perd immédiatement l'accès au groupe de cette section, sans qu'aucune suppression n'ait à être faite. Les photos et vidéos du groupe suivent exactement la même règle : elles ne sont accessibles qu'aux membres de ce groupe, jamais depuis la galerie générale de l'unité.

Modération : tout membre peut signaler un message ou une réponse. Au-delà d'un seuil configurable de signalements, le contenu est automatiquement masqué pour tout le monde sauf pour les modérateurs du groupe, qui décident ensuite de le rétablir ou de le supprimer. Le masquage est la seule conséquence automatique : rien n'est jamais supprimé sans décision humaine. Ces décisions sont journalisées, avec des identifiants uniquement — jamais le texte concerné.

Vérification automatique par IA (optionnelle, activable par l'administrateur) : si le module Connecteur Intelligence Artificielle est actif, le texte d'un message ou d'une réponse peut être analysé avant sa publication pour détecter une attaque personnelle ou un propos irrespectueux, avec une reformulation proposée à son auteur. Seul le texte du message est transmis, jamais l'identité de son auteur ni le contenu du groupe. Un texte refusé n'est jamais enregistré, ni journalisé, ni conservé où que ce soit : il n'est rendu qu'à la personne qui l'a écrit, dans sa propre session, le temps d'un affichage. En cas d'indisponibilité, de dépassement de délai ou d'erreur du service, le message est publié sans vérification — la vérification est un filet de courtoisie, jamais un contrôle bloquant. Voir la section « Module Connecteur Intelligence Artificielle » pour le fournisseur et les transferts concernés.

Notifications : un membre est prévenu (dans le site et, s'il l'a autorisé, par notification push) d'un nouveau message dans un de ses groupes, d'une réponse à son message, ou d'une réaction à son message ; un modérateur est prévenu d'un signalement. Ces notifications ne contiennent jamais plus que ce que leur destinataire peut déjà voir dans le groupe, et jamais le texte d'un contenu masqué ou refusé. Aucun email n'est envoyé pour ces évènements.

Conservation : trois durées, toutes configurables par l'administrateur et appliquées automatiquement chaque nuit. (1) Un groupe sans aucune activité depuis un certain nombre de mois (12 par défaut) est clôturé : il reste entièrement visible et consultable par ses membres, mais n'accepte plus de nouvelle publication. (2) Un message est supprimé définitivement un certain nombre de mois après sa dernière activité (24 par défaut), avec ses réponses, ses réactions, ses signalements, ses photos et l'image de son lien — les fichiers eux-mêmes, pas seulement les données. Un message épinglé n'est jamais supprimé automatiquement. (3) Un groupe clôturé est supprimé intégralement un certain nombre de mois après sa clôture (12 par défaut), sa galerie comprise ; un groupe de l'année scoute en cours ou d'une année à venir n'est jamais supprimé automatiquement. Aucune de ces durées n'est modifiable groupe par groupe.

Base légale : Intérêt légitime (communication interne de l'unité entre ses membres, nécessaire à son organisation et à la vie de ses sections).

Module Attestations

Finalité : Découper le PDF unique d'attestations nominatives envoyé par la fédération (attestation fiscale, attestation de présence après un camp) en un document par membre, le déposer sur la page du membre concerné et l'envoyer à sa famille.

Données traitées : Le PDF déposé contient, pour toute l'unité, les attestations nominatives de chaque membre — nom et montants. Le site le lit pour en déduire où commence et où finit chaque attestation, et pour rapprocher chaque document d'un membre sur le seul nom : c'est la seule information que ce document porte. Le nom tel qu'imprimé dans le PDF est conservé sur la ligne correspondante, chiffré au repos, le temps que le chef d'unité vérifie l'appariement.

Le fichier déposé n'est jamais conservé : il contient les données de toutes les familles dans un seul document et n'a plus d'utilité une fois les attestations découpées. Il est supprimé immédiatement après le découpage, que celui-ci ait réussi ou échoué.

Chaque attestation découpée est chiffrée au repos et rattachée à son membre : elle n'est lisible que par les comptes liés à ce membre et par les chefs d'unité, comme tout document privé (section 2.2). Un chef d'unité l'ouvre depuis la fiche du membre pour répondre à une famille, jamais depuis l'écran du lot, et chaque ouverture est consignée au journal d'audit. Un animateur de section n'y a aucun accès.

Envoi par e-mail : sur décision explicite du chef d'unité — jamais automatiquement — chaque attestation est envoyée en pièce jointe à la dernière adresse connue du membre dans Desk. C'est ce qui permet à une famille ayant quitté l'unité, et donc sans accès au site, de recevoir malgré tout son document. L'adresse est celle des données de membre décrites en section 2.2 : aucune adresse nouvelle n'est collectée. Le message ne contient que le libellé du lot et la pièce jointe.

Notifications : une seule notification par compte, jamais une par enfant, prévenant qu'un document est disponible. Elle ne porte que le libellé du lot — jamais un montant, jamais un nom.

Reprise d'un lot : un chef d'unité peut reprendre un lot entier — les documents que ce lot avait déposés sur les pages des membres sont alors supprimés définitivement, fichiers compris, et le lot disparaît. Cette action existe parce qu'un découpage décalé donnerait à chaque famille l'attestation d'une autre. Elle ne rattrape évidemment pas les e-mails déjà envoyés.

Journal : les dépôts, publications, reprises et envois sont consignés sous forme de compteurs et d'identifiants numériques uniquement — jamais un nom, jamais une adresse, jamais le contenu d'une attestation. Il en va de même de chaque consultation d'une attestation par un chef d'unité et de chaque renvoi effectué depuis la fiche d'un membre, consignés au niveau « sécurité ».

Base légale : Intérêt légitime (transmettre à chaque famille un document nominatif que la fédération a émis à son intention).

Module Documents officiels

Finalité : Remettre à une famille le formulaire officiel de la fédération — l'autorisation parentale — déjà pré-rempli avec ce que le site sait déjà, pour qu'elle l'imprime, le signe à la main et le remette à l'animateur.

Seule la version signée sur papier a une valeur. Ce que le site produit n'est qu'un brouillon de pré-remplissage. Il n'y a ni signature électronique, ni renvoi du document signé au site, ni tableau de bord pour le staff — et il n'y en aura pas : un animateur qui lirait la version du site lirait une version non signée, donc sans valeur, en croyant savoir.

Données traitées : Le document reprend le nom et le prénom du membre, sa branche, le nom de l'unité, ainsi que le nom, le prénom et l'adresse postale de l'animateur responsable de sa section — toutes déjà décrites en section 2.2, aucune n'est collectée à cette occasion. S'y ajoute ce que le parent tape sur l'écran : son propre nom, en quelle qualité il signe, les dates de l'activité et le lieu où il signe.

Rien de ce que le parent tape sur l'autorisation parentale n'est enregistré. Ces valeurs ne servent qu'à écrire le document, dans la mémoire du serveur, le temps de la requête. Le PDF lui-même n'est écrit nulle part : il est produit puis transmis, sans jamais toucher le disque, et le site n'en garde aucune copie. Rouvrir la page plus tard propose un formulaire vierge.

La fiche santé, elle, est conservée, et c'est tout son intérêt : elle est saisie une fois et réutilisée les années suivantes plutôt que retapée. Le site y conserve deux personnes à contacter en cas d'urgence (nom, lien de parenté, téléphone, adresse e-mail, remarque), le médecin traitant (nom, prénom, téléphone) et les informations de santé que le formulaire de la fédération demande : taille et poids, participation aux activités, niveau de natation, affections, maladies et opérations, vaccination contre le tétanos, allergies et leurs conséquences, régime alimentaire, traitement en cours. Tout y est facultatif : une famille peut n'en remplir aucune partie, ou n'utiliser que l'autorisation parentale.

Ces données sont chiffrées au repos et rattachées au membre. Elles sont déchiffrées uniquement au moment où la famille ouvre son propre écran ou produit son propre document ; ni l'écran ni le journal ne les montrent à personne d'autre. Une famille peut tout effacer d'un bouton, ce qui supprime définitivement l'enregistrement — pas de corbeille, pas de copie conservée ailleurs. Le site note alors qu'un effacement a eu lieu, avec la date et l'identifiant du membre, jamais le contenu effacé.

Combien de temps la fiche santé est conservée : dix-huit mois sans le moindre usage, après quoi le site l'efface tout seul. Le compteur repart à zéro dès qu'une famille modifie sa fiche ou qu'elle en imprime le document : retélécharger sans rien changer suffit, parce que c'est un geste délibéré et non un oubli. La durée est un réglage de l'unité, modifiable par un chef d'unité, et dix-huit mois en est la valeur par défaut — de quoi laisser passer une année scoute entière.

Cet effacement est définitif et silencieux : il n'y a ni corbeille, ni copie conservée ailleurs, ni avertissement préalable. Le site n'envoie aucun message à ce sujet — prévenir par e-mail qu'une fiche médicale va être supprimée ferait voyager cette information dans une boîte aux lettres que le site ne maîtrise pas, pour éviter une suppression qu'il suffit d'ouvrir la page pour repousser. Une famille dont la fiche a été effacée la ressaisit quand elle en a besoin. Le site note qu'un effacement de conservation a eu lieu, avec la date et l'identifiant du membre, jamais le contenu effacé.

Aucun animateur, aucun chef d'unité et aucun administrateur n'a accès à la fiche santé depuis le site, quel que soit son rôle. La seule façon dont ces informations parviennent à l'unité est celle que la famille choisit : elle imprime la fiche, la signe et la remet en main propre.

Qui peut l'obtenir : les comptes liés à ce membre, et eux seuls. Le lien entre le compte et le membre est revérifié à chaque action, sans exception pour un chef d'unité ni pour un administrateur — seule la substitution temporaire de membre, visible à l'écran tant qu'elle dure, permet à un administrateur d'agir pour quelqu'un.

Journal : aucune valeur saisie, aucun nom, aucun contenu de document n'y figure. L'effacement d'une fiche santé y est noté — qu'il vienne du bouton « Tout effacer » ou de la conservation — avec l'identifiant numérique du membre et rien d'autre, pas même le nom des rubriques qui avaient été remplies.

Ce module n'introduit aucun sous-traitant et ne fait aucun appel à une intelligence artificielle : le formulaire de la fédération est un fichier livré avec le site, et tout est produit sur le serveur.

Base légale : Intérêt légitime (fournir à une famille, pré-rempli, un document que la fédération exige pour la participation de son enfant aux activités).

Module Trombinoscope

Finalité : Montrer aux familles, section par section, les photos, totems, noms et fonctions des animateurs et des chefs d'unité, et leur permettre de les joindre. La page est réservée aux personnes connectées : elle n'est jamais accessible sans authentification.

Données traitées : Aucune donnée personnelle supplémentaire n'est collectée. Le module lit les données déjà présentes dans les fiches membres (section 2.2) et affiche celles marquées comme « responsable » par le chef d'unité. Le téléphone et l'adresse e-mail personnelle de chaque animateur sont affichés sous sa photo ; le Staff d'Unité peut les masquer pour toute l'unité au moyen d'un réglage unique. L'adresse e-mail d'une section n'est pas une donnée personnelle — elle appartient à la section et non à la personne qui l'anime — et reste affichée dans tous les cas.

Document imprimable : toute personne connectée peut télécharger le trombinoscope sous forme de PDF — un annuaire des responsables, puis une page par section — afin de l'imprimer ou de l'envoyer aux familles. Ce document ne contient rien de plus que ce que la page affiche déjà à la même personne : il suit le même réglage, et n'est donc jamais généré avec des coordonnées personnelles lorsque celles-ci sont masquées. Il est produit à la demande, sur le serveur, sans aucun envoi à un service externe, et n'est conservé nulle part : le fichier est transmis puis oublié. Une fois téléchargé, sa diffusion échappe au site.

Base légale : Intérêt légitime (permettre à une famille de joindre l'encadrement de son enfant) et consentement implicite (les animateurs acceptent la fonction en connaissance de cause).

Module Rétrospectives

Finalité : Permettre aux chefs de créer des tableaux de rétrospective anonymes après un événement d'unité (trois colonnes de commentaires libres — ce qui a bien marché, à améliorer, suggestions — et un vote), accessibles via un lien ou un QR code.

Données traitées :

Modération et synthèse par IA (optionnelles) : si le module Connecteur Intelligence Artificielle est actif, le texte d'un commentaire peut être analysé avant publication pour détecter une attaque personnelle ou un propos irrespectueux, avec une reformulation plus respectueuse proposée par l'IA en cas de signalement. Le niveau de vérification est configurable par l'unité (désactivée, avertissement — le participant choisit de publier son texte tel quel ou d'accepter la suggestion — ou obligatoire — le participant doit reformuler ou accepter la suggestion avant de pouvoir publier) ; son propre texte reste toujours modifiable, jamais rejeté silencieusement. Un participant peut aussi demander à raccourcir son propre texte avant de l'envoyer. À la clôture d'un tableau, une courte synthèse thématique des commentaires visibles peut être générée automatiquement. Ces appels ne transmettent que le texte du commentaire lui-même, jamais d'identité — voir la section « Module Connecteur Intelligence Artificielle » pour le fournisseur et les transferts concernés.

Masquage d'un commentaire : un chef peut masquer un commentaire jugé injurieux ou irrespectueux (action réversible), sans jamais découvrir qui l'a écrit.

Base légale : Intérêt légitime (amélioration continue des activités de l'unité).

Module Encadrement

Finalité : Aider l'équipe d'unité à savoir qui contacter au sujet de sa formation d'animateur, des échéances légales liées à l'âge, et des inscriptions d'intendants. Ce module ne collecte rien : il relit les données déjà importées de Desk et les présente sous forme de listes.

Données traitées : uniquement des données déjà présentes dans le site et importées de Desk — nom et prénom, totem, date de naissance, niveau de formation, fonction, section, date de début de fonction. Le module ne stocke aucune donnée personnelle : sa seule table enregistre la correspondance entre une formulation de niveau de formation utilisée par Desk (par exemple « Animateur breveté ») et l'étape normalisée correspondante — une information sur un mot, jamais sur une personne. Tout le reste est recalculé à chaque affichage.

Ce que ce module ne contient jamais : aucune information relative au Code Qualité des Adultes (CQA) ni à un extrait de casier judiciaire — ni le document, ni une date, ni un statut, ni un motif, sous aucune forme et dans aucune table. Le site n'affiche donc jamais qu'un tel document serait en ordre, manquant, valide ou expiré : il se limite à répercuter le fait que Desk signale, ou non, une fonction comme « candidat » au moment de l'import, et à rappeler la date à laquelle un animateur atteindra 20 ans. La vérification elle-même se fait dans Desk, jamais ici.

Note d'unité : une note libre unique, rédigée par l'équipe d'unité et visible d'elle seule, est enregistrée avec les autres contenus éditables du site et n'est pas chiffrée au repos. La page qui permet de la rédiger le rappelle explicitement et invite à n'y consigner aucune information sensible.

Visibilité : les quatre pages du module sont réservées aux chefs d'unité. Chaque membre voit en revanche, sur sa propre page personnelle et sur elle seule, son propre parcours de formation — un chef consultant la page de quelqu'un d'autre ne le voit pas.

Base légale : Intérêt légitime (organisation de l'encadrement de l'unité et respect des obligations de formation de la fédération).

Module Cotisations

Finalité : Vérifier que les cotisations facturées par la fédération correspondent à ce que l'unité a encodé dans Desk. Le module lit ; il n'écrit jamais dans Desk et ne demande jamais de paiement à une famille.

Données traitées : à chaque import Desk, le module enregistre une photographie de la composition du roster. Cette photographie ne contient aucune donnée personnelle : uniquement, pour chaque membre, son identifiant interne et des codes — catégorie tarifaire, section, rôle de la fonction, niveau de formation, et l'indication qu'un départ a été annoncé. Les noms et les dates de naissance ne sont pas recopiés : ils restent là où l'import les a mis, dans la fiche annuelle du membre. Cette photographie est prise par le site lui-même à chaque import, indépendamment de ce module : elle existe donc même si le module n'a jamais été activé, et suit la durée de conservation des imports Desk indiquée en section 3.1. Sans elle, une facture émise en février ne serait plus vérifiable en mars.

Foyers mis de côté : un chef d'unité peut écarter une adresse de la vérification — garde alternée, colocation, deux familles au même numéro — en écrivant pourquoi. Ce motif est du texte libre pouvant décrire une situation familiale : il est chiffré au repos, n'apparaît jamais dans le journal d'audit, et n'est visible que sur cet écran. L'adresse elle-même n'est jamais enregistrée ici en clair, seulement son index de recherche chiffré.

Factures de la fédération : les factures reçues peuvent être importées pour être vérifiées. Le site en enregistre l'en-tête (numéro, date, total, communication structurée) et les lignes tarifaires. Les personnes que chaque ligne facture nommément sont rapprochées des fiches annuelles au moment de l'import, et seul l'identifiant interne du membre reconnu est conservé : ni nom, ni prénom, ni date de naissance ne sont recopiés depuis la facture, et une personne que le site n'a pas reconnue devient une ligne anonyme qui préserve le compte sans conserver son identité. Ces données sont conservées aussi longtemps que l'année scoute concernée.

PDF conservé (facultatif) : si le module Finances est actif, le chef d'unité peut demander que le PDF de la facture soit rattaché à un compte de l'unité comme justificatif de dépense ordinaire. Ce document contient, lui, les noms et les dates de naissance imprimés par la fédération : il est alors chiffré au repos comme tout justificatif du module Finances, visible uniquement des personnes autorisées sur ce compte, et soumis à la durée de conservation du module Finances (purge de l'exercice comptable le plus ancien dépassant la durée configurée). Si la case n'est pas cochée, ou si le module Finances n'est pas actif, aucun PDF n'est conservé et la vérification fonctionne à l'identique.

Recherche des montants de cotisation (facultatif, IA) : le barème du module comporte trois montants saisis à la main, qui ne servent qu'à chiffrer un écart en euros. Si le module Intelligence artificielle est actif et configuré, un chef d'unité peut demander au site de les chercher. Le serveur consulte alors, en lecture seule, une page publique du site de la fédération dont l'adresse est un réglage du site — c'est une requête sortante vers un tiers, sans aucune donnée personnelle et sans aucune donnée de l'unité : rien n'est envoyé, seule la page est demandée. Le texte de cette page est ensuite transmis au fournisseur d'IA configuré pour en extraire trois nombres et une année scoute. Aucune donnée de membre, de foyer ou de facture n'est transmise à l'occasion de cette recherche, et le résultat n'est jamais enregistré automatiquement : les montants sont pré-remplis à l'écran et un chef d'unité doit les valider lui-même. Sans connecteur IA actif, cette fonction n'est pas proposée et aucune requête n'est faite.

Base légale : Intérêt légitime (contrôle des sommes facturées à l'unité par sa fédération).

Module Actualités

Finalité : Publier les articles de l'unité et, quand l'auteur en ajoute un, recueillir les inscriptions à une activité par un formulaire — puis, pour un évènement ouvert au public, contrôler les entrées à la porte.

Données traitées : une adresse email de contact, toujours demandée et chiffrée au repos (avec index aveugle pour permettre les recherches sans déchiffrement), et les réponses aux champs configurés par l'auteur de l'article — qui peuvent contenir un nom, un téléphone, une adresse ou du texte libre, et sont toutes chiffrées au repos, sans distinction. Un formulaire peut être ouvert à des personnes extérieures à l'unité, qui n'ont donc pas de fiche membre ici : leur réponse est la seule donnée les concernant.

Billet d'entrée (facultatif) : l'auteur peut demander qu'un formulaire délivre un billet. Chaque réponse reçoit alors une référence aléatoire — une suite de dix lettres et chiffres tirée au hasard, qui ne nomme personne et ne se déduit de rien — envoyée au répondant par email avec le code QR qui l'encode. À la porte, valider ce billet enregistre la date et l'heure du passage : c'est une donnée de présence à un évènement, conservée et supprimée avec la réponse à laquelle elle appartient, et utilisée uniquement pour compter les entrées et les recouper avec les paiements. Un animateur peut annuler cette validation.

Image du code QR d'un billet : pour qu'un logiciel de messagerie puisse afficher le code dans un rappel, il est servi par une adresse web publique portant la référence et une empreinte cryptographique de celle-ci. Cette adresse ne révèle que la référence — jamais un nom, un montant ou le nom de l'évènement — et il n'existe aucune page publique du billet : le contrôle à l'entrée se fait derrière une connexion.

Date et lieu, fichier d'agenda : si l'auteur renseigne la date et le lieu de l'évènement, l'email de confirmation emporte un fichier d'agenda standard (iCalendar). Ce fichier part chez le destinataire et n'est plus modifiable ensuite ; il ne contient que le titre, la date et le lieu de l'évènement, aucune donnée du répondant.

Paiement : si le module Finances est actif et que le formulaire déclare un prix, l'inscription génère une communication structurée bancaire belge et un code QR de virement SEPA. Aucune donnée de carte bancaire n'est jamais collectée ni stockée, et la génération est entièrement locale au site — aucun sous-traitant n'intervient. Entrer et payer restent deux faits distincts : valider un billet à la porte ne modifie jamais la créance.

Conservation : toutes les réponses, leurs billets et leurs horodatages d'entrée sont conservés aussi longtemps que l'article existe et sont supprimés automatiquement avec lui. Il n'y a pas de purge automatique séparée.

Base légale : Intérêt légitime (organisation des activités de l'unité) et exécution d'une demande de la personne concernée pour une inscription qu'elle a elle-même déposée.

Modules Banner et Member Stats

Ces modules n'ajoutent aucun traitement de données personnelles. Banner affiche des bannières visuelles éditables. Member Stats génère des statistiques anonymisées sur la répartition des membres (par branche, genre, âge).

Module Finances

Finalité : Gérer les comptes bancaires et caisses de l'unité, catégoriser automatiquement les mouvements financiers, conserver les reçus justifiant les dépenses, et suivre les sommes attendues des familles (campagnes de paiement).

Données traitées :

Extraction automatique par IA (optionnelle) : si le module Connecteur Intelligence Artificielle est actif, le montant, la date et le nom du commerçant d'un reçu peuvent être suggérés automatiquement après son ajout, par un appel à un modèle IA de niveau « économique » uniquement (le module Finances ne choisit jamais un modèle ou un fournisseur précis — voir la section « Module Connecteur Intelligence Artificielle » pour les fournisseurs et transferts concernés). Cette suggestion reste modifiable ou ignorable par l'utilisateur ; en l'absence du module ou en cas d'échec, la saisie reste entièrement manuelle.

Catégorisation automatique par IA (optionnelle, désactivée par défaut) : si le module Connecteur Intelligence Artificielle est actif, l'administrateur peut activer une règle de catégorisation par IA, appliquée uniquement aux mouvements qu'aucune règle manuelle n'a su catégoriser. Un appel à un modèle IA de niveau « économique » reçoit alors le libellé, le montant, la date, la contrepartie et le commentaire du mouvement, la liste des catégories existantes avec leur description, la description des reçus éventuellement associés à ce mouvement, ainsi que les événements du calendrier de la section liée au compte survenant dans les trois semaines avant ou après la date du mouvement (si le module Calendrier est actif). Ces informations peuvent donc contenir des données personnelles (nom d'un membre dans un commentaire, une description de reçu ou un événement de calendrier). La catégorie suggérée reste modifiable manuellement à tout moment ; le mouvement conserve une indication de son origine (automatique ou manuelle) mais aucune de ces informations transmises au modèle IA n'est elle-même conservée par le module Finances au-delà de l'appel.

Visibilité restreinte : chaque compte n'est visible que par les chefs dont le rôle atteint le niveau minimum configuré par l'administrateur pour ce compte (intendant, chef, ou admin).

Conservation du fichier d'une campagne : le fichier Excel chargé pour créer une campagne, et la copie de ses colonnes utilisée pour les rappels, sont supprimés lorsque l'année scoute de la campagne sort de la fenêtre de conservation des imports Desk (2 années scoutes par défaut, voir la section 3.1) — la même durée, réglée au même endroit. La campagne, ses montants et ses créances sont conservés au-delà : ce sont des données comptables, et elles ne portent plus alors que l'identifiant interne des membres concernés.

Conservation : chaque mois, l'exercice comptable le plus ancien dépassant la durée de conservation configurée par l'administrateur (5 ans par défaut) est purgé intégralement (mouvements et soldes de référence). Un reçu archivé ou actif qui ne se rattache plus à aucun mouvement après cette purge est alors définitivement supprimé (fichier chiffré et donnée) — c'est le seul cas où un reçu est réellement effacé ; une suppression manuelle par un utilisateur ne fait, elle, toujours qu'archiver le reçu.

Base légale : Intérêt légitime (gestion administrative et comptable de l'unité, obligation de transparence financière envers la fédération).

Module Envoi de mails

Finalité : Permettre aux chefs d'envoyer des communications groupées (par email) aux membres de l'unité, à partir de listes de diffusion par section, par fonction, ou personnalisées — et, depuis une liste personnalisée, à des personnes extérieures à l'unité dont l'unité conserve elle-même l'adresse (voir « Adresses propres à une liste » ci-dessous).

Données traitées :

Désinscription : chaque email envoyé comporte un lien de désinscription (dans le corps du message) ainsi que les en-têtes techniques standard List-Unsubscribe et List-Unsubscribe=One-Click (RFC 8058), reconnus par la plupart des messageries pour proposer une désinscription en un clic. Le clic sur le lien visible dans l'email affiche toujours une page de confirmation avant toute action (afin d'éviter qu'un simple survol ou une analyse automatique du lien par un client de messagerie ne désinscrive quelqu'un par erreur) ; seule la requête technique « en un clic » envoyée directement par la messagerie peut agir immédiatement, conformément à la RFC 8058. Une désinscription rend l'adresse concernée inactive pour les envois groupés futurs et pour la connexion au site par lien magique (y compris pour l'adresse Desk elle-même, la seule exception à la règle « toujours utilisable » qui s'applique par ailleurs à cette adresse) — dans la mesure où une même adresse peut être associée à plusieurs membres (ex. l'adresse d'un parent renseignée pour plusieurs enfants), la désinscription s'applique à l'adresse dans son ensemble, pour tous les membres concernés. Un membre peut réactiver une adresse désinscrite à tout moment depuis son espace personnel. Cet évènement déclenche deux emails automatiques : un email informatif au Staff d'U (adresse de contact configurée pour la section Staff d'U), listant le(s) prénom(s) et nom(s) des membres concernés, l'invitant à vérifier si une action complémentaire est nécessaire (l'évènement pouvant aussi signaler une volonté de quitter l'unité) ; et un email de confirmation à l'adresse désinscrite elle-même, expliquant comment revenir en arrière en cas d'erreur et listant les mêmes membres concernés.

Adresses propres à une liste : une liste de diffusion personnalisée peut contenir, en plus des membres que ses critères désignent, des adresses saisies par un chef d'unité pour des personnes qui ne sont pas membres de l'unité — la commune, la paroisse, le propriétaire d'un terrain de camp, un ancien membre. Deux données sont conservées pour chacune : un nom (facultatif) et une adresse email, toutes deux chiffrées au repos et déchiffrées uniquement au moment d'afficher l'écran qui les gère ou de préparer un envoi. Une empreinte irréversible de l'adresse (index aveugle) est conservée à côté, uniquement pour deux usages techniques : éviter deux fois la même adresse dans une liste, et propager une désinscription. Ces adresses appartiennent à la liste qui les contient : il n'existe aucun carnet d'adresses global du site, et modifier une adresse dans une liste ne modifie rien ailleurs. La désinscription, elle, vaut pour toutes les listes à la fois : une personne qui demande que l'unité cesse de lui écrire s'adresse à l'unité, pas à une liste. Une adresse désinscrite est conservée en l'état, marquée comme telle et définitivement exclue des envois ; elle ne peut plus être ni modifiée, ni supprimée, ni réabonnée depuis le site — c'est ce qui donne sa valeur au lien de désinscription. Ces adresses sont conservées tant que la liste existe et sont supprimées avec elle ; une personne extérieure peut demander l'effacement de la sienne auprès du responsable du traitement (section 7).

Publipostage depuis un fichier Excel : un chef peut également constituer les destinataires d'un envoi en important un fichier Excel (« publipostage ») : chaque ligne du fichier correspond à un email, adressé soit à un membre identifié par son numéro Desk (colonne « Tiers », l'email partant alors vers toutes les adresses connues du membre), soit à l'adresse indiquée dans la colonne « Email » de la ligne (qui peut donc concerner une personne extérieure à l'unité). Toutes les valeurs du fichier (chaque colonne pouvant être insérée comme variable dans le message, par exemple un prénom ou un montant) sont conservées chiffrées au repos ; le fichier Excel lui-même est supprimé immédiatement après sa lecture. Ces données importées sont automatiquement et définitivement supprimées 18 mois après l'envoi de l'email (durée fixe, non modifiable) — le suivi des envois lui-même (statut par destinataire, adresse copiée au moment de l'envoi) suit la règle de conservation du paragraphe précédent. Un destinataire extérieur à l'unité dispose du même lien de désinscription que les membres ; sa désinscription est conservée sous forme d'empreinte irréversible de son adresse (jamais l'adresse elle-même) et bloque tout publipostage futur vers cette adresse, sans limite de durée.

Conservation : les emails envoyés et la liste de leurs destinataires (y compris l'adresse copiée au moment de l'envoi) sont conservés indéfiniment, au même titre que le reste des données actives de l'unité (section 3.1) — il n'existe pas, à ce jour, de purge automatique dédiée aux anciens envois groupés (les valeurs importées d'un publipostage font exception : voir ci-dessus). Une suppression peut être demandée par un membre auprès du responsable du traitement (section 7).

Liste additionnelle du module Inscriptions : lorsque le module Inscriptions est actif, une liste de diffusion supplémentaire est proposée — voir le détail de son contenu dans la sous-section « Module Inscriptions » ci-dessous.

Base légale : Intérêt légitime (communication interne de l'unité, nécessaire à son organisation et à la participation aux activités).

Module Inscriptions

Finalité : Permettre aux familles de déposer une demande d'inscription pour un enfant via un formulaire public, de consulter à tout moment l'état de leur demande, et à l'unité de traiter cette demande de bout en bout : examen, acceptation ou refus, rapprochement avec l'import Desk une fois l'enfant réellement encodé, et conservation limitée dans le temps une fois la demande clôturée.

Données traitées :

Décision du staff et emails d'acceptation/de refus : une demande est explicitement acceptée, refusée, retirée ou remise en attente par un membre du staff — jamais de changement d'état automatique en dehors du rapprochement décrit ci-dessous. Un email d'acceptation ou de refus est ensuite envoyé explicitement (jamais automatiquement au moment de la décision) ; la page de suivi de la famille n'affiche une acceptation ou un refus qu'une fois cet email réellement envoyé, jamais avant, afin qu'une décision ne soit jamais découverte par la famille avant que l'unité n'ait eu l'occasion de la communiquer elle-même.

Rapprochement et migration : à chaque import depuis Desk, les demandes acceptées de l'année concernée sont automatiquement comparées aux membres nouvellement importés, uniquement via les index de recherche chiffrés décrits ci-dessus (aucun déchiffrement en boucle de l'ensemble des demandes). Une correspondance unique migre automatiquement la demande vers le membre réel : les adresses email secondaires confirmées par la famille sont reportées sur la fiche du membre (pour que l'accès déjà configuré ne soit jamais perdu), la demande cesse d'apparaître dans l'espace personnel de la famille au profit de la fiche membre réelle, mais reste consultable par le staff pendant toute la durée de conservation ci-dessous. Les données d'identité elles-mêmes ne migrent jamais : Desk reste la source faisant foi. En l'absence de correspondance, ou en cas de correspondance ambiguë (plusieurs demandes ou plusieurs membres partageant les mêmes nom, prénom et date de naissance — homonymes, jumeaux), aucun rapprochement automatique n'est effectué et la situation est signalée au staff, qui peut alors rapprocher manuellement la demande d'un membre en indiquant son numéro de tiers Desk (le staff ne peut renseigner qu'un numéro correspondant à un membre déjà importé et non déjà lié à une autre demande) ; qu'il soit automatique ou manuel, ce rapprochement suit systématiquement le même traitement. Le journal d'audit (section 2.5) ne conserve dans les deux cas que des identifiants numériques, jamais de nom.

Alerte à l'unité : à chaque nouvelle demande, un email automatique est envoyé à l'adresse configurée par l'administrateur, contenant uniquement le prénom de l'enfant, le créneau (branche et année) concerné et un lien vers la demande — jamais les coordonnées complètes de la famille dans cet email.

Ouverture du formulaire : le formulaire est ouvert ou fermé par l'administrateur, manuellement ou à des horaires programmés à l'avance ; un code d'inscription distinct, communiqué directement par l'unité, permet en complément de déposer une demande pour l'année scoute en cours, en dehors des périodes d'ouverture générale pour l'année suivante.

Préparation de l'année suivante (pages « Départs » et « Passage ») : deux pages réservées aux chefs préparent la transition vers l'année scoute suivante. La page « Départs », réservée à un chef ou animateur pour les seules sections dont il a la charge (l'administrateur voit l'ensemble de l'unité), permet d'indiquer qu'un animé ne reviendra probablement pas l'année suivante ; ce marquage (et son éventuel motif, chiffré au repos et jamais consigné dans le journal d'audit) est décrit en détail à la section 2.2. La page « Passage », accessible à l'ensemble des chefs sans restriction de section (la répartition des arrivées entre sections suppose de voir toute l'unité), assigne une section prévue aux nouvelles demandes acceptées (la même donnée que celle décrite ci-dessus) et une section de destination aux animés changeant de branche l'année suivante ; cette destination est une donnée de planification propre au module, associée au membre et à l'année scoute ciblée, jamais écrite dans les données Desk du membre. Cette page regroupe également les personnes vivant à la même adresse normalisée qu'un animé (technique identique à celle décrite en section 8 pour la suggestion de catégorie de cotisation) afin de faciliter une répartition cohérente entre sections — un tel regroupement reflète une adresse commune, non un lien de fratrie déclaré.

Liste de diffusion pour le module Envoi de mails : lorsque le module Envoi de mails (section 2.4) est également actif, celui-ci propose une liste de diffusion supplémentaire, prédéfinie et non modifiable, nommée d'après l'année scoute ciblée (ex. « Inscriptions 2026-2027 ») et recomposée à chaque envoi. Elle ne contient que les demandes acceptées et effectivement encodées dans Desk pour cette année — jamais une demande encore en attente, refusée ou retirée.

Prévisions et blocage de la bascule d'année scoute : une page « Prévisions », accessible à l'ensemble des chefs sans restriction de section, affiche un effectif projeté pour l'année scoute suivante — uniquement sous forme de chiffres agrégés (répartitions par section, équilibre filles/garçons, pyramide des âges) : aucun nom ni donnée individuelle n'y apparaît. Par ailleurs, tant qu'il subsiste une demande d'inscription en attente ou acceptée (quelle que soit l'année scoute visée), la bascule de l'ensemble du site vers l'année scoute suivante est refusée à l'administrateur ; ce blocage ne repose que sur un décompte de demandes, jamais sur leur contenu, et une activation réservée au staff (étape intermédiaire du processus) reste, elle, toujours possible.

Réinscription (réponse des familles pour l'année suivante) : chaque année, l'unité peut demander aux familles de ses animés si l'enfant revient l'année scoute suivante. La réponse de la famille est conservée par le module, associée au membre et à l'année scoute visée, et comporte trois données personnelles :

L'absence de réponse est un état à part entière : rien n'est enregistré tant qu'une famille n'a pas répondu, et une famille qui a répondu ne reçoit plus de rappel. La réponse de la famille positionne l'indication de départ décrite à la section 2.2 ; le staff peut ensuite la corriger et sa décision fait foi, mais la réponse de la famille elle-même n'est ni modifiée ni effacée par cette correction.

Notes du staff sur la page « Passage » : à côté de la réponse de la famille, un chef d'unité peut enregistrer sa propre lecture du souhait (la section qu'il retient) et une note interne chiffrée au repos, propre au module et à l'année scoute visée. Ces deux données appartiennent au staff, jamais à la famille : la note n'est jamais visible par la famille, ne figure dans aucun export qui lui est destiné, et n'est jamais consignée dans le journal d'audit. Elles ne modifient ni n'effacent la réponse de la famille, qui reste affichée telle qu'elle a été donnée.

Relecture facultative des commentaires par une IA : lorsque le module Intelligence artificielle est actif et qu'un fournisseur y est configuré, un chef d'unité peut demander explicitement une relecture des commentaires libres des familles, afin de repérer un souhait de placement exprimé en toutes lettres plutôt que dans les champs prévus. Trois points comptent :

Sans le module Intelligence artificielle, ou sans fournisseur actif, cette relecture n'existe pas et aucun commentaire n'est transmis nulle part.

Conservation de la réponse de réinscription : la réponse, son commentaire et les noms cités sont conservés tant que l'année scoute visée reste pertinente, puis supprimés en même temps que les autres données de planification du module — au plus tard lors de la suppression définitive décrite ci-dessous. Ils ne sont jamais recopiés dans les données Desk du membre ni dans celles du membre cité. La note interne du staff et la lecture IA suivent le même sort, au même moment.

Conservation : une demande encore en cours (en attente ou acceptée) est conservée sans limite de durée, comme le reste des données actives de l'unité (section 3.1). Une fois une demande clôturée (encodée dans Desk, refusée ou retirée), deux délais courent à partir de cette clôture, jamais à partir du dépôt initial : elle disparaît de l'espace personnel de la famille après un délai configurable par l'administrateur (3 mois par défaut ; une demande encodée en disparaît immédiatement, remplacée par la fiche membre réelle) puis est supprimée définitivement et irréversiblement après un second délai configurable, plus long (2 ans par défaut). Ces deux délais sont automatiquement appliqués chaque jour par une tâche planifiée.

Base légale : Consentement explicite (case à cocher obligatoire lors du dépôt de la demande) et intérêt légitime de l'unité (gestion des demandes d'inscription).

Module Locations

Finalité : Permettre à l'unité de mettre en location ses propres biens (locaux, terrains, tentes, remorques, matériel) : présenter chaque bien publiquement et désigner, parmi les membres, les personnes qui en assurent la gestion.

Données traitées :

Mise à jour automatique après un import Desk : à chaque import depuis Desk, la désignation d'un gestionnaire qui n'apparaît plus dans l'unité est automatiquement désactivée — son accès au bien cesse immédiatement. Elle n'est jamais supprimée et se réactive d'elle-même si la personne réapparaît dans un import ultérieur. Le journal d'audit (section 2.5) n'en conserve qu'un décompte, jamais l'identité des personnes concernées.

Confidentialité publique : la page publique d'un bien ne montre jamais le nom, le téléphone ni l'email d'un gestionnaire, ni le téléphone d'urgence du bien, ni aucune information relative à un locataire ou à une réservation.

Demande de location (personne extérieure à l'unité) : lorsque vous introduisez une demande de location, nous enregistrons votre nom, votre adresse email, et — si vous les indiquez — votre téléphone, l'organisation que vous représentez, l'objet de votre séjour et votre commentaire libre. Le nom, l'email, le téléphone, l'organisation, l'objet et le commentaire sont chiffrés au repos (AES-256-GCM) : ils ne sont lisibles ni dans une sauvegarde de la base de données, ni par une personne qui accéderait au serveur sans la clé de chiffrement. Ces données ne sont accessibles qu'aux gestionnaires du bien concerné et au staff d'unité. Sont également conservées les dates demandées, le nombre de personnes annoncé, l'estimation de prix telle qu'elle vous a été présentée, ainsi que la date et la version des conditions de location et de la présente politique que vous avez confirmé avoir lues.

Base légale de la demande de location : Exécution d'un contrat, ou mesures précontractuelles prises à votre demande (art. 6.1.b RGPD). Ce n'est pas un consentement : nous ne pouvons pas traiter votre demande sans ces informations, et la case que vous cochez au formulaire atteste que vous avez été informé, elle n'autorise pas le traitement.

Votre lien de suivi : l'email d'accusé de réception contient un lien personnel qui vous donne accès à l'état de votre demande, sans compte ni mot de passe. Ce lien vaut autorisation : quiconque en dispose voit votre demande. Ne le transmettez qu'aux personnes concernées. Il n'est jamais affiché ailleurs sur le site, jamais consigné dans nos journaux, et n'est conservé chez nous que sous forme d'empreinte — nous ne pouvons pas le retrouver, seulement en émettre un nouveau, ce qui invalide immédiatement l'ancien. La page de suivi ne montre jamais les notes internes des gestionnaires.

Ce que reçoivent les gestionnaires par email : l'email qui les prévient d'une nouvelle demande ne contient aucune de vos données personnelles — seulement la référence du dossier et un lien vers la page protégée. Vos coordonnées ne circulent pas dans les boîtes mail.

Journal d'audit : une demande de location n'y apparaît que par sa référence et son identifiant interne. Ni votre nom, ni votre email, ni votre téléphone, ni votre commentaire n'y sont jamais écrits.

Suivi de votre dossier : l'unité conserve, à côté de votre demande, l'historique de ce qui lui est arrivé — changements d'état, modifications de prix, dates proposées. Cet historique ne contient aucune donnée personnelle : il parle de la réservation, jamais de vous.

Commentaires internes : les gestionnaires peuvent s'écrire des notes de service à propos d'une location. Ces notes sont chiffrées au repos au même titre que vos coordonnées, ne sont lisibles que des gestionnaires du bien et du staff d'unité, et n'apparaissent jamais sur votre page de suivi — celle-ci ne les charge même pas. Vous pouvez en demander la communication au titre de votre droit d'accès (section 7).

Demandes de modification : si vous demandez d'autres dates, un autre nombre de participants ou une annulation, votre demande et le message qui l'accompagne sont enregistrés — le message chiffré, comme le reste. Une demande ne modifie jamais votre réservation d'elle-même : elle attend une décision, et la décision est elle aussi conservée.

Paiements : si l'unité utilise le module « Finances » pour ce bien, une créance est enregistrée à la confirmation de votre location, avec une communication structurée qui vous est communiquée. Cette créance ne contient que la référence de votre dossier, votre nom et un montant — jamais votre email, votre téléphone ni votre commentaire. Le montant déjà reçu n'est pas stocké : il est recalculé à chaque affichage à partir des virements de votre communication figurant sur l'extrait de compte de l'unité. Aucune donnée de carte bancaire n'est jamais collectée : les paiements se font par virement, jamais sur ce site.

Caution : lorsqu'une caution est demandée, elle fait l'objet d'une créance séparée avec sa propre communication, pour qu'elle ne se confonde jamais avec le prix de la location. Si une partie en est retenue, l'unité en enregistre le motif ; ce motif est chiffré au repos comme les autres informations vous concernant, et vous pouvez en obtenir communication (section 7). La restitution est saisie manuellement par l'unité : ScoutMagic ne rapproche pas les virements sortants d'un compte bancaire.

Contrat et facture : votre contrat et votre facture sont générés au format PDF et conservés par l'unité. Ils contiennent les informations que vous avez fournies : nom, organisation, coordonnées, et — pour la facture — vos coordonnées de facturation. Ces documents vous parviennent uniquement par email : ils ne sont pas téléchargeables depuis le site, et le lien de suivi de votre demande ne donne accès à aucun fichier. En cas d'email perdu, demandez simplement à l'unité de vous le renvoyer.

Versions successives : chaque regénération d'un contrat ou d'une facture crée une nouvelle version et ne remplace jamais la précédente — une version déjà signée doit rester consultable telle quelle. Les valeurs utilisées pour produire chaque version sont conservées à côté du document, afin de pouvoir expliquer plus tard pourquoi une version affichait tel montant.

Coordonnées de facturation : raison sociale, adresse, pays, numéro de TVA ou de BCE, email de facturation et votre propre référence ou bon de commande. Elles ne sont demandées qu'au moment où elles servent, jamais au formulaire public, et sont chiffrées au repos comme le reste de vos informations. Base légale : obligation légale (facturation et conservation des pièces comptables).

Documents ajoutés par l'unité : états des lieux, photos, relevés, attestations. Ils ne sont accessibles qu'aux gestionnaires du bien concerné et au staff d'unité — jamais publiquement, et jamais via votre lien de suivi. Ceux qui vous concernent vous sont envoyés par email si l'unité l'a prévu.

Relevés de compteurs et état des lieux : pendant votre séjour, l'unité relève ses compteurs à l'entrée et à la sortie et vérifie une liste d'éléments (clés, mobilier, sanitaires…). Ces informations portent sur le bien, pas sur vous. Les photos éventuelles sont dépouillées de leurs métadonnées de localisation avant d'être enregistrées, et ne sont accessibles qu'aux gestionnaires du bien.

Incidents et dégâts : lorsqu'un dégât est constaté, l'unité en enregistre la description et, le cas échéant, une photo et un montant. Cette description est chiffrée au repos, car elle parle en pratique de votre groupe. Aucune facturation n'est automatique : un gestionnaire décide explicitement d'ajouter le montant au décompte, de le retenir sur la caution, ou de ne rien facturer. Tant que rien n'est décidé, le constat n'apparaît nulle part de votre côté.

Décompte final : après le séjour, l'unité établit un décompte reprenant le nombre réel de participants, les consommations relevées, les éventuels dégâts facturés, ce que vous avez déjà payé et le solde. Le décompte est versionné : une correction crée une nouvelle version et ne réécrit jamais la précédente. Il ne modifie jamais le prix convenu, qui reste conservé tel qu'il a été négocié.

Publication au calendrier de l'unité : si l'unité l'a activé pour le bien, l'occupation apparaît dans le calendrier de l'unité et dans les flux d'abonnement (.ics) correspondants. Cette publication ne vous nomme jamais : un lecteur ordinaire du calendrier — membre, parent, visiteur — voit uniquement le nom du bien et le fait qu'il est loué, à la même enseigne qu'une indisponibilité décidée par l'unité. Ni votre nom, ni l'organisation que vous représentez, ni vos coordonnées, ni le nombre de participants ne sont publiés, et ils ne sont pas davantage présents dans le fichier .ics téléchargé : ils ne sont tout simplement pas produits pour un lecteur qui n'y a pas droit. Seuls les gestionnaires du bien et le staff d'unité voient, dans leur propre calendrier, le détail de la réservation ; ce droit est vérifié à chaque consultation, de sorte qu'un gestionnaire qui n'en est plus un cesse immédiatement de le voir.

Votre propre flux d'abonnement : votre page de suivi vous propose un lien .ics qui n'ajoute que votre séjour à votre agenda, avec les dates, le nom du bien et le contact que l'unité vous a communiqué. Il est protégé par le même lien personnel que votre page de suivi, obéit aux mêmes précautions, et ne contient aucun montant. Si votre location est annulée, le flux le signale au lieu de la faire disparaître, afin que votre agenda se mette à jour au lieu de garder un séjour qui n'aura pas lieu.

Rien n'est recopié : la publication au calendrier ne crée pas de second enregistrement de votre location. Elle est calculée à la demande, à partir de votre dossier, et disparaît d'elle-même si l'unité désactive la publication ou supprime le dossier.

Vos emails rattachés à votre dossier : si l'unité utilise le module « Courrier entrant », les messages que vous lui envoyez au sujet de votre location sont rattachés automatiquement à votre dossier et visibles des seuls gestionnaires du bien et du staff d'unité — d'abord grâce à la référence figurant dans l'objet, puis grâce à la conversation, puis, à défaut, grâce à votre adresse email — directement si vous n'avez qu'une réservation chez l'unité, et sinon seulement si le message tombe dans une fenêtre de temps autour de l'un de vos séjours ; une demande refusée, annulée ou restée sans suite n'entre pas en ligne de compte. En cas d'ambiguïté, rien n'est rattaché : si plusieurs de vos réservations correspondent, le site les propose à un gestionnaire et n'en choisit aucune — le mettre sur la mauvaise serait pire, car personne ne pourrait s'en apercevoir. L'objet, votre adresse et le corps du message sont chiffrés au repos, et le gestionnaire voit toujours comment le rattachement a été fait : un rattachement sur la seule adresse est présenté comme incertain, parce qu'il l'est.

Ce qu'un rattachement fait à la main apprend au site : lorsqu'un gestionnaire rattache lui-même à votre dossier un message venu d'une autre adresse que la vôtre — celle du trésorier de votre groupe, par exemple —, cette adresse est retenue comme une adresse de votre dossier, sous la même protection que la vôtre, et les messages suivants qui en proviennent y sont rattachés sans nouvelle intervention. Elle est supprimée avec le dossier. Un rattachement fait par le site lui-même n'apprend jamais rien. Pour reconnaître votre réponse au premier email que l'unité vous envoie, le site conserve par ailleurs une empreinte de l'identifiant technique de chaque email qu'il vous adresse au sujet de votre dossier — un identifiant de message, jamais son contenu ni votre adresse.

Aide du modèle pour départager (uniquement si le module « Intelligence artificielle » est actif) : lorsque plusieurs de vos réservations correspondent à un message et que l'unité a activé le connecteur, l'objet et le corps du message sont transmis au fournisseur d'IA avec la liste des réservations possibles — dates et nom du bien, jamais votre nom ni votre adresse —, pour que sa suggestion soit affichée en tête des propositions. Le modèle ne rattache jamais rien : les autres réservations restent proposées, et c'est un gestionnaire qui tranche. Sans le connecteur, les propositions sont affichées telles que les règles les ont produites, et rien n'est transmis nulle part.

Vos pièces jointes : un fichier que vous envoyez devient un document de votre dossier, en visibilité interne et en type « non classé » — jamais présumé être un contrat signé, jamais renvoyé automatiquement. Un gestionnaire peut le reclasser. Les logos de signature sont écartés, et seuls les PDF, images et documents bureautiques sont conservés.

Si un gestionnaire détache un message de votre dossier, il cesse immédiatement d'apparaître dans votre dossier et les gestionnaires du bien cessent d'y avoir accès ; ses pièces jointes qui n'auraient pas été reclassées entre-temps sont retirées du dossier. Le message lui-même subsiste dans le courrier de l'unité, où seul le chef d'unité le voit, et il est supprimé automatiquement au terme de la durée de conservation décrite à la sous-section « Module Courrier entrant » — un détachement est le plus souvent une correction de rattachement, et faire disparaître le message sur-le-champ empêcherait de le rattacher au bon dossier.

Rappels automatiques : l'unité reçoit des rappels internes au sujet de votre dossier — acompte non reçu, état des lieux à faire, décompte à établir. Ces rappels ne contiennent aucune donnée vous concernant : ils citent la référence de votre dossier et le nom du bien, jamais votre nom, votre adresse email ni votre téléphone. Un seul rappel vous est adressé, par email : les informations pratiques une semaine avant votre séjour (heures d'arrivée et de départ, contacts sur place). Il ne contient ni prix, ni lien de suivi supplémentaire.

Registre de conformité du bien : l'unité tient, pour chacun de ses biens, la liste des documents qui arrivent à échéance (attestation incendie, assurance, autorisation communale…). Ce registre porte sur le bâtiment et ses papiers, jamais sur une personne, et n'est accessible qu'aux gestionnaires du bien et au staff d'unité.

Assistance par intelligence artificielle (optionnelle) : si l'unité a activé le module « Intelligence artificielle », un gestionnaire peut demander une aide ponctuelle — lire l'index d'un compteur sur une photo, proposer le classement d'une pièce jointe, résumer un échange, repérer ce qui manque dans une demande. Dans ces cas, l'élément concerné (la photo du compteur, le nom du fichier et l'objet de l'email, le texte de l'échange) est transmis au fournisseur d'IA choisi par l'unité et quitte les serveurs de ScoutMagic : ce fournisseur est alors un sous-traitant à part entière (voir section 4). Ni votre nom, ni votre adresse, ni vos coordonnées ne lui sont transmis.

L'IA ne décide jamais : elle ne peut ni accepter ni refuser une réservation, ni modifier un prix convenu, ni déclarer un dégât imputable, ni retenir une caution, ni déclencher un remboursement, ni modifier un statut financier définitif. Chacune de ses propositions est affichée à un gestionnaire, qui la valide ou l'écarte. Sans le module « Intelligence artificielle », rien de tout cela n'existe et le module fonctionne à l'identique.

Base légale : Intérêt légitime (gestion du patrimoine de l'unité et des locations qui en financent les activités).

Module Courrier entrant

Finalité : permettre à l'unité de connecter une ou plusieurs de ses propres boîtes mail en lecture seule, afin que les réponses reçues soient rattachées automatiquement au dossier auquel elles se rapportent, sans qu'un membre du staff ait à les recopier à la main.

Ce n'est pas un client mail, et la boîte distante n'est jamais modifiée : aucun message n'est marqué comme lu, déplacé, supprimé ni renommé. ScoutMagic lit, et rien d'autre.

Ce qui est conservé : tous les messages lus dans les boîtes que l'unité a configurées sont enregistrés, y compris ceux qu'aucun dossier ne reconnaît. Ce n'était pas le cas auparavant — un message que rien ne reconnaissait était ignoré et n'était jamais écrit — et le changement est délibéré : un message ignoré était un message perdu, une demande arrivée sur la mauvaise adresse ou une réponse à laquelle plus personne ne pouvait remonter, sans que l'unité en sache jamais rien.

Ce que cela implique, et ce qui l'encadre : ce choix constitue bien une archive du courrier reçu sur les boîtes configurées, et l'unité l'assume comme telle plutôt que de la constituer sans le dire. Elle est encadrée, et les garanties suivantes sont indissociables du choix lui-même : un message que rien ne rattache à un dossier est supprimé automatiquement au terme d'une durée réglable par l'unité (90 jours par défaut, voir la section 3.1) ; le chef d'unité en est responsable et est le seul à pouvoir consulter un message qui n'est rattaché à aucun dossier ; et l'espace occupé est plafonné, le dépassement du plafond effaçant les plus anciens messages non rattachés et prévenant le superadministrateur.

Ce qui n'est pas conservé comme du courrier : les envois en nombre — listes de diffusion, réponses automatiques, rapports de non-remise, messages signalés comme indésirables — sont reconnus comme tels à la réception et écartés des écrans de travail. Ils suivent la même durée de conservation que les autres. Un message d'une taille déraisonnable est conservé tronqué, et le fait qu'il l'ait été est affiché : personne ne lit un message amputé en croyant le lire en entier.

Contenu conservé pour un message rattaché : l'objet, l'adresse et le nom de l'expéditeur, la date, le corps du message en texte et en HTML, et les pièces jointes retenues. L'objet, les adresses et les deux versions du corps sont chiffrés au repos (AES-256-GCM), au même titre que les autres données personnelles du site.

Images distantes et pixels de traçage : le contenu HTML est nettoyé à la réception et aucune image distante n'est jamais chargée. Une image invisible placée dans un email est un accusé de lecture : la charger indiquerait à l'expéditeur quand un gestionnaire a ouvert son message, et depuis quel réseau. Elle est supprimée, pas relayée.

Pièces jointes : seuls les PDF, les images et les documents bureautiques courants sont conservés — jamais d'archives ni de fichiers exécutables. Le type réel est déterminé à partir du contenu du fichier, jamais de son nom ni de ce que l'email annonce. Les logos de signature sont écartés automatiquement. Les fichiers retenus sont stockés hors du site public, sous un nom généré, accessibles aux seuls gestionnaires du dossier concerné et au chef d'unité, et les métadonnées de localisation des photos sont supprimées.

Une pièce jointe non conservée est dite, pas escamotée : lorsqu'un fichier est écarté parce qu'il est trop volumineux, d'un type refusé ou que le plafond de stockage est atteint, son nom, son type et sa taille sont enregistrés et affichés avec la raison, sans son contenu. Un lecteur voit ainsi que l'expéditeur avait bien joint un fichier et qu'il doit aller le chercher dans la boîte d'origine, au lieu de compter une pièce jointe de moins sans savoir pourquoi. Les logos et images de signature, eux, sont écartés sans être signalés : ce ne sont pas des pièces jointes.

Identifiants de connexion : l'adresse et le mot de passe de la boîte sont chiffrés et ne sont jamais réaffichés, même partiellement, même à l'administrateur qui les a saisis. Ils ne sont accessibles qu'au superadministrateur, et les messages d'erreur techniques ne les reprennent jamais. Un chef d'unité ou un gestionnaire peut utiliser une boîte déjà configurée dans son travail quotidien, mais ne voit ni le serveur, ni le compte, ni aucun paramètre technique.

Un accès n'ouvre jamais la boîte : un gestionnaire qui peut consulter un dossier voit les messages rattachés à ce dossier, et rien d'autre. Il n'existe pour lui ni recherche, ni liste générale, ni écran donnant accès au reste du courrier. Le chef d'unité fait exception, et c'est la contrepartie assumée de la conservation décrite plus haut : puisque le courrier non rattaché est désormais conservé, quelqu'un doit pouvoir le lire et l'orienter, faute de quoi il ne serait qu'une archive aveugle. Ce droit ne s'étend à aucun autre rôle et il est vérifié à chaque consultation.

Rattachement à un séjour déjà connu (module Camps, boîte dédiée aux camps uniquement) : lorsqu'un message arrivé dans une boîte entièrement consacrée aux camps annonce une période — « du 18 au 20 septembre 2026 », ou les lignes « Arrivée » et « Départ » d'un contrat — et que l'unité a exactement un séjour couvrant ces jours-là, le message est rattaché à ce séjour. Sur une boîte partagée, la période annoncée sert uniquement à départager plusieurs séjours d'un même contact déjà connu ; elle ne rattache jamais seule. Cette reconnaissance n'écrit aucune donnée nouvelle : elle relie un message à une réservation que l'unité avait déjà encodée. Elle ne fait appel à aucun modèle d'intelligence artificielle et ne dépend pas du réglage de création automatique décrit ci-dessous. Si plusieurs séjours couvrent la même période, aucun n'est choisi : ils sont proposés au chef d'unité, qui tranche. L'objet et le corps du message sont lus d'abord ; le texte des pièces jointes n'est ouvert que s'ils n'ont rien donné. Le rattachement est affiché comme « Période annoncée dans le message », c'est-à-dire explicitement comme un rapprochement et non comme une certitude.

Ce qu'un rattachement fait à la main apprend au site (module Camps) : lorsqu'un chef rattache lui-même un message à un séjour et que l'adresse de l'expéditeur n'est celle d'aucun contact de ce séjour, elle y est ajoutée comme contact, avec le nom d'expéditeur tel qu'il figure dans le message et la mention « Correspondant ». C'est une donnée d'un tiers extérieur à l'unité : elle est chiffrée au repos comme tout contact d'un séjour, visible des seuls chefs qui voient ce séjour, et l'effacement d'un contact décrit à la sous-section « Module Camps » l'atteint de la même façon. Un rattachement fait par le site lui-même n'ajoute jamais de contact.

Aide du modèle pour départager (module Camps, uniquement si le module « Intelligence artificielle » est actif) : lorsque plusieurs séjours d'un même contact correspondent à un message, l'objet et le corps du message sont transmis au fournisseur d'IA avec la liste des séjours possibles — dates et nom du lieu, jamais le nom d'une personne —, pour que sa suggestion soit affichée en tête des propositions. Le modèle ne rattache jamais rien : les autres séjours restent proposés et un chef tranche. Sans le connecteur, rien n'est transmis nulle part.

Reçus reçus par email (module Finances) : une pièce jointe qui cite l'IBAN d'un compte de l'unité est enregistrée comme reçu de ce compte sans confirmation dans deux cas seulement — la boîte est entièrement consacrée à la trésorerie, ou l'expéditeur anime la section à laquelle ce compte appartient — et proposée à un trésorier dans tous les autres. Pour qu'une même facture transmise deux fois ne devienne pas deux reçus, une empreinte du contenu du fichier est conservée avec le reçu ; elle ne dit rien du fichier et ne concerne aucune personne.

Création automatique d'un séjour (module Camps, boîte dédiée aux camps uniquement) : lorsqu'un message arrivé dans une boîte entièrement consacrée aux camps n'a été rattaché à aucun séjour et annonce des dates sans ambiguïté, un séjour peut être créé automatiquement et le message rattaché dessous. Cela ne se produit jamais sur une boîte partagée, jamais si l'unité a désactivé la création automatique, et jamais sur un message que quelqu'un a déjà rattaché lui-même. Le lieu est d'abord rapproché d'un terrain déjà connu. Le nom d'expéditeur du message ne sert jamais à nommer un terrain : il sert uniquement à reconnaître un terrain déjà enregistré, ce qui n'écrit rien nulle part.

Si le module Connecteur Intelligence Artificielle est actif, et dans ce cas seulement, le nom et l'adresse d'un nouveau terrain (rue, code postal, commune) sont extraits du contenu du message : l'objet, le corps et le texte des pièces jointes (couche texte d'un PDF ou pièce en texte brut ; et, lorsqu'aucun texte n'a pu être lu, l'image d'une page scannée ou photographiée est envoyée telle quelle au modèle pour transcription — au plus une par message, et jamais si le texte a pu être lu autrement) — signature comprise, telle que l'expéditeur l'a écrite, et document contractuel compris, où peuvent figurer le nom, l'adresse et le téléphone d'un tiers — sont transmis au fournisseur d'IA configuré, qui reçoit la consigne explicite de ne renvoyer que le nom et l'adresse du terrain, du domaine ou du bâtiment dont le message parle, jamais un nom de personne, jamais celui de l'expéditeur, et jamais l'adresse de l'expéditeur, de sa signature ou d'un bureau où renvoyer un contrat, et de ne rien renvoyer en cas de doute. L'adresse ainsi lue est enregistrée en clair avec le lieu, comme son nom ; un lieu déjà connu de l'unité n'est jamais réécrit par cette lecture. Le nom d'un terrain est stocké en clair, comme toute donnée d'un lieu ; un chef d'unité peut le corriger, le fusionner ou l'archiver depuis la fiche du lieu. Voir la section « Module Connecteur Intelligence Artificielle » pour le fournisseur et les transferts concernés.

Sans ce module — ou si l'appel échoue, ou si le modèle n'a nommé aucun lieu — aucun terrain n'est créé et rien n'est envoyé nulle part : le message reste rattaché à rien, où un chef d'unité le retrouve et valide lui-même le nom du lieu avant qu'il n'entre en base. Un séjour créé automatiquement est marqué « à confirmer », signalé comme venant d'un message dans son historique, et annoncé aux chefs des sections concernées par une notification qui ne cite que le séjour — jamais l'expéditeur ni l'objet du message. Cette création automatique peut être désactivée dans la configuration du module.

Conservation : un message rattaché à un dossier suit la durée de conservation de ce dossier et disparaît avec lui, pièces jointes comprises. Un message que rien ne rattache — ni association à un dossier, ni proposition de rattachement encore en attente — est supprimé automatiquement au terme d'un délai réglable par l'unité, 90 jours par défaut. Ce délai se compte depuis la date du message, jamais depuis le moment où il a été détaché : détacher un message ancien ne lui offre pas une nouvelle période de conservation. Un message détaché par erreur dispose néanmoins d'un délai plancher de trente jours, le temps que l'erreur soit remarquée.

Notifications internes : lorsqu'un module hésite entre plusieurs dossiers et propose un rattachement, les personnes qui peuvent trancher — gestionnaires du bien, chefs du séjour, trésoriers — en sont averties par une notification du site, désactivable dans leurs préférences. Elle ne cite que le dossier concerné : jamais l'expéditeur, l'objet ni une ligne du message. Ce qui n'a pas été tranché est compté, par module, sur la page des points d'attention du chef d'unité, sans autre détail qu'un nombre.

Adresse de réponse signée : les e-mails que le site envoie au sujet d'un dossier portent une adresse de réponse qui reprend la référence de ce dossier et une signature (par exemple locations+rental.LOC-2027-0042.9f3a1b2c4d5e@votre-unite.be), afin qu'une simple réponse soit rattachée au bon dossier dès son arrivée. Cette adresse ne contient aucune donnée personnelle — la référence figure déjà dans l'e-mail — et une adresse dont la signature ne vérifie pas est traitée comme une adresse ordinaire. L'unité peut désactiver ce mécanisme.

Base légale : Intérêt légitime (assurer le suivi des échanges liés à un dossier de l'unité), et exécution du contrat lorsque l'échange porte sur une location ou une inscription en cours.

2.5. Sécurité et traçabilité

Finalité : Détecter et prévenir les abus, assurer la sécurité du site.

Données traitées : Journal d'audit contenant l'adresse IP, l'identifiant du compte (jamais l'email en clair), la date et l'action effectuée.

Base légale : Intérêt légitime (sécurité du système).

2.6. Messages en attente d'envoi

Finalité : Ne pas perdre un e-mail que le site voulait vous adresser lorsque aucun serveur d'envoi n'est disponible au moment voulu.

Données traitées : Le message entier — votre adresse, l'objet, le contenu et les pièces jointes éventuelles — conservé chiffré au repos (AES-256-GCM) et déchiffré uniquement au moment de la nouvelle tentative d'envoi.

Portée : Cette file ne contient que ce qui n'est pas encore parti ; ce n'est pas un archivage des e-mails envoyés. Un message parti en est effacé immédiatement, contenu compris. Les liens de connexion n'y entrent jamais : ils échouent tout de suite plutôt que d'être livrés trop tard.

Base légale : Intérêt légitime (fiabilité des communications du site).

2.7. Consultation hors ligne (uniquement avec votre consentement fonctionnel)

Finalité : Permettre de consulter certaines pages du site sans connexion internet, lorsque le site est installé comme application sur votre appareil.

Données traitées : Si vous acceptez les cookies fonctionnels et utilisez l'application installée, une copie des pages suivantes est enregistrée localement sur votre appareil : les pages publiques (accueil, contact, sections, protection des données), le calendrier, le centre de notifications, le trombinoscope, les staffs, les statistiques et les prévisions (pour les chefs), ainsi que votre propre page personnelle et « Mon compte » (accessibles uniquement à vous). La page personnelle d'un membre peut afficher le nom complet et l'adresse postale du chef désigné responsable de sa section, ainsi que ses fonctions — ces informations sont alors conservées localement dans les mêmes conditions que le reste de la page. Le trombinoscope affiche de même le téléphone et l'adresse e-mail des animateurs lorsque le réglage de l'unité le prévoit ; sa copie locale les contient alors aussi, et cesse de les contenir dès que ce réglage est désactivé et la page rafraîchie. Chaque page affiche les photos qu'elle montre normalement (photo du membre, photo de groupe d'une section, logo de branche d'âge), dans la même résolution réduite que celle utilisée en ligne. Cette copie locale n'inclut jamais vos documents privés, les données financières ni le contenu des emails groupés — ces contenus restent uniquement accessibles en ligne, quel que soit l'appareil. Chaque page consultée hors ligne affiche la date et l'heure de la copie enregistrée.

Portée : Cette copie locale est propre à l'appareil et au compte utilisé — un autre membre se connectant sur le même appareil ne peut pas y accéder, elle est effacée automatiquement à sa connexion. Elle est également effacée intégralement à votre déconnexion, ainsi qu'en cas de retrait du consentement aux cookies fonctionnels (page /cookies). Seule l'application installée enregistre de nouvelles copies ou les met à jour ; une simple visite du site depuis un onglet de navigateur ordinaire n'écrit jamais dans cette copie locale, même si elle peut continuer à la lire tant qu'elle reste valable.

Base légale : Consentement (retirable à tout moment depuis la page de gestion des cookies).

2.8. Assistant d'aide (uniquement si un fournisseur d'IA est configuré)

Finalité : Répondre en français à une question sur l'utilisation du site, à partir de sa documentation intégrée.

Données traitées : Uniquement le texte de la question que vous écrivez, et les sujets d'aide du site — qui sont de la documentation livrée avec le logiciel et ne contiennent aucune donnée de l'unité. L'assistant ne consulte jamais la base de données : ni les membres, ni les sections, ni les montants, ni sous forme agrégée ou anonymisée. Il ne peut donc pas répondre à une question portant sur une personne ou sur un montant, et il n'a aucun moyen technique d'y accéder.

Transfert : Votre question est transmise au fournisseur d'IA choisi par l'unité et quitte les serveurs de ScoutMagic ; ce fournisseur est alors un sous-traitant à part entière (voir section 4). Écrivez donc votre question sans y mettre de nom ni de coordonnées : rien de tel n'est nécessaire pour obtenir une réponse, et rien d'autre que votre question n'est envoyé — ni votre nom, ni votre adresse email, ni votre identifiant.

Conservation : Aucune. La conversation vit uniquement dans votre session : elle disparaît à votre déconnexion et après une heure d'inactivité. Elle n'est enregistrée dans aucune table, et le journal du site n'en retient que des compteurs — jamais le texte de vos questions. Les réponses de l'assistant, qui ne décrivent que le fonctionnement du site, sont mises en cache pour éviter de refaire le même appel ; ce cache ne contient aucune donnée personnelle et est purgé automatiquement.

Base légale : Intérêt légitime (aide à l'utilisation du site). La recherche dans l'aide, elle, fonctionne entièrement sur votre appareil, sans aucun appel extérieur, et reste disponible si l'unité n'a configuré aucun fournisseur d'IA.

2.9. Vérification de la délivrabilité des e-mails (sonde)

Finalité : Savoir où arrivent réellement les messages de l'unité — dans la boîte de réception ou dans les indésirables — ce qu'aucun site ne peut observer depuis l'extérieur. Un administrateur envoie un message de test à une adresse qu'il choisit, va regarder, et note lui-même le résultat.

Données traitées : L'adresse de destination saisie par l'administrateur, conservée chiffrée au repos (AES-256-GCM) et déchiffrée uniquement pour être réaffichée sur la page de configuration. Sont conservés avec elle la date d'envoi, le fournisseur d'envoi utilisé, la voie empruntée et le verdict saisi à la main. Il s'agit en pratique de l'adresse de l'administrateur lui-même, ou de l'adresse témoin d'un service d'analyse extérieur ; le site n'y écrit jamais l'adresse d'un membre de sa propre initiative.

Si le message de test revient : Lorsqu'un serveur de messagerie nous renvoie ce message de test comme non remis, nous ajoutons sur la même ligne la catégorie du refus (boîte pleine, adresse inexistante, message refusé, serveur injoignable), le code technique renvoyé et la date de ce refus — de quoi expliquer un « jamais reçu » qui, sans cela, resterait une énigme. Le texte que le serveur distant a écrit n'est ni conservé ni affiché, ici comme ailleurs : il recite l'adresse et n'apprendrait rien de plus. Ce rapprochement est souvent impossible — un serveur qui refuse avant de citer le message refusé ne renvoie aucune référence —, et la page se contente alors de ce que l'administrateur a constaté lui-même.

Destinataire : Le message de test part par le relais SMTP choisi (voir section 4.1) et arrive à l'adresse indiquée, comme n'importe quel e-mail du site. Aucun service d'analyse n'est appelé par le site : si un administrateur utilise l'adresse témoin d'un tel service, c'est lui qui consulte le résultat chez ce service, et le site ne communique avec lui d'aucune autre manière.

Portée : L'adresse n'apparaît ni dans le journal technique ni dans l'archive de diagnostic (« paquet de support »), qui ne portent que le fournisseur, la voie et le verdict. La sonde n'est jamais envoyée automatiquement : chaque envoi est une action explicite d'un administrateur.

Base légale : Intérêt légitime (fiabilité des communications du site).

2.10. Adresses qui refusent nos messages (rebonds)

Finalité : Savoir qu'une de vos adresses a cessé de recevoir nos messages, vous le dire, et arrêter d'écrire à une adresse qui refuse — ce qui protège l'acheminement du courrier de toute l'unité. Sans cela, l'unité continue d'écrire dans le vide et sa réputation d'expéditeur se dégrade pour tout le monde.

Données traitées : Lorsqu'un serveur de messagerie nous renvoie un message comme non remis, nous conservons l'adresse concernée chiffrée au repos (AES-256-GCM), la catégorie du refus (boîte pleine, adresse inexistante, message refusé, serveur injoignable), le code technique renvoyé, le nombre d'échecs, les dates du premier et du dernier refus, et la date de suspension le cas échéant. Une ligne par adresse, jamais une par fiche : une même adresse figurant sur les fiches de plusieurs enfants n'est enregistrée qu'une fois.

La preuve que nous vous avons écrit : Nous gardons, séparément, la date du dernier message envoyé à chaque destinataire. L'adresse elle-même n'y figure pas, même chiffrée : seule une empreinte irréversible permettant de reconnaître la même adresse, et une date. Sans cela, n'importe qui pourrait nous envoyer un faux avis de non-remise nommant votre adresse et la faire suspendre. Nous n'enregistrons donc un refus que si un message est effectivement parti vers cette adresse depuis le dernier refus enregistré : un refus est une réponse, et il lui faut un envoi à quoi répondre. Cette date sert aussi à constater qu'une adresse refonctionne : un envoi qui ne provoque aucun refus efface le compteur du précédent.

Ce que nous ne conservons pas : Le texte que le serveur distant nous a renvoyé n'est jamais conservé ni affiché. Il cite votre adresse, il est rédigé par un logiciel tiers, et il ne vous apprendrait rien — nous le lisons pour en extraire le code, puis nous le jetons. L'adresse n'apparaît ni dans le journal technique, ni dans les notifications qui vous sont envoyées, ni dans l'archive de diagnostic.

Ce que vous pouvez faire : La raison et la marche à suivre s'affichent sur la page de vos adresses, en français ordinaire, pour votre adresse principale et pour toute adresse secondaire dont vous avez suivi le lien de confirmation — une adresse que vous avez seulement déclarée, sans l'avoir confirmée, n'y montre rien, faute de quoi il suffirait de déclarer l'adresse d'un autre pour lire son état et lever sa suspension. Vous pouvez y réactiver vous-même une adresse suspendue : c'est le site qui l'a suspendue, c'est donc à vous de décider qu'elle refonctionne. Un administrateur peut lui aussi lever une suspension, mais il ne peut pas réactiver une adresse que vous avez vous-même désactivée : ce sont deux décisions différentes et elles appartiennent à deux personnes différentes.

Destinataire : Personne. Ces informations ne quittent pas le site et ne sont transmises à aucun tiers.

Base légale : Intérêt légitime (fiabilité des communications du site, et information de la personne concernée).

2.11. Rapports d'authentification du domaine (DMARC)

Finalité : Savoir quels serveurs envoient du courrier en se présentant sous le nom de domaine de l'unité, et si ces messages sont correctement authentifiés. Cela permet de repérer un outil oublié qui écrit encore au nom de l'unité, et d'éviter de durcir la politique d'authentification du domaine d'une manière qui ferait disparaître silencieusement des messages légitimes.

Données traitées : Aucune donnée vous concernant. Les grands fournisseurs de messagerie nous envoient chaque jour un résumé statistique de ce qu'ils ont reçu en notre nom. Ce résumé ne contient que des compteurs et des adresses de serveurs expéditeurs : le nom du fournisseur qui rapporte, le domaine concerné, la période, la politique publiée, l'adresse du serveur ayant envoyé, le nombre de messages et le résultat de l'authentification. Il ne nomme aucun destinataire, ne contient aucun objet et aucun contenu de message. Nous conservons ces résumés tels quels, sans les rapprocher d'aucune fiche ni d'aucune adresse de membre.

Ce que nous refusons : Il existe une seconde sorte de rapport, dite « forensique », qui joint une copie du message en cause — et donc l'adresse de la personne à qui nous écrivions, l'objet et le contenu. Notre configuration ne les demande pas, et le site ne les traite pas.

Destinataire : Personne. Ces résumés ne quittent pas le site. L'archive de diagnostic qu'un administrateur peut produire pour obtenir de l'aide n'en emporte que des totaux, jamais une adresse de serveur.

Base légale : Intérêt légitime (sécurité et fiabilité des communications de l'unité).

2.12. Fiche de contact d'un membre (code QR et fichier)

Finalité : Permettre à un chef d'unité d'enregistrer les coordonnées d'un membre dans le carnet d'adresses de son propre téléphone ou de son ordinateur, sans les recopier à la main.

Données traitées : Le nom et le prénom, le totem, l'unité et la section, la fonction de l'année scoute en cours, les adresses e-mail connues, les deux numéros de téléphone provenant de Desk, les adresses postales, la photo et l'historique des fonctions année par année. Ces données existent déjà sur la fiche du membre : aucune nouvelle donnée n'est collectée pour cette fonctionnalité.

Ce qui n'y figure jamais : Le champ Handicap, qui est une donnée de santé, l'assurance complémentaire, le sexe, la date de naissance, l'identifiant Desk, la patrouille, le niveau de formation et les consentements de communication. Le code QR ne porte pas la photo.

Qui peut la produire : Uniquement un chef d'unité (role_min: admin), depuis la fiche d'un membre dans l'Espace chefs d'U. Le bouton n'existe sur aucune autre page du site, et en particulier pas sur le trombinoscope.

Destinataire : L'appareil personnel de la personne qui produit la fiche, et lui seul. Aucun service extérieur n'intervient : le code QR est fabriqué par le site lui-même, et la fiche n'est jamais écrite sur le disque du serveur — elle est produite en mémoire et transmise directement.

Ce que cela implique : Une fois descendue sur un appareil, la copie appartient à cet appareil : elle suit ses sauvegardes, elle ne se met pas à jour toute seule, et le site n'a plus aucun moyen de l'effacer. C'est la raison pour laquelle chaque fiche produite est consignée au journal du site, avec l'identifiant du membre concerné et rien d'autre — ni son nom, ni son adresse, ni un numéro.

Base légale : Intérêt légitime (organisation de l'unité et communication entre l'équipe d'animation et les familles).

2.13. Identifiants d'appareil pour la synchronisation des contacts

Finalité : Permettre au carnet d'adresses d'un téléphone ou d'un ordinateur de se tenir à jour tout seul avec les coordonnées des animateurs et du Staff d'unité. Les clients de carnet d'adresses ne savent s'authentifier qu'avec un identifiant et un mot de passe dédiés : aucune des méthodes de connexion du site ne convient à un logiciel qui se synchronise en arrière-plan.

Données traitées : Pour chaque appareil enregistré, le compte auquel il appartient, le nom que son propriétaire lui a donné, la date de création, la date de dernière synchronisation et la date de révocation éventuelle. Le mot de passe n'est jamais conservé en clair : seule une empreinte irréversible l'est, et le mot de passe lui-même n'est affiché qu'une seule fois, à la création.

Qui peut en créer : Uniquement un chef d'unité ou un superadministrateur, pour son propre compte. Le droit est revérifié à chaque requête : une personne qui quitte le Staff d'unité perd la synchronisation au passage suivant, sans qu'aucune révocation manuelle soit nécessaire.

Ce qui est consigné : La création d'un appareil, sa révocation et les échecs d'authentification, avec des identifiants techniques et rien d'autre — jamais un mot de passe, jamais un nom, jamais une adresse. Les synchronisations réussies ne sont pas consignées : elles arrivent toutes les quelques minutes.

Destinataire : L'appareil personnel de la personne qui l'a enregistré, et lui seul. Aucun service extérieur n'intervient.

Ce que cela implique : La copie descendue appartient à l'appareil : elle suit ses sauvegardes et le site n'a plus aucun moyen de l'effacer. Révoquer un appareil arrête les synchronisations suivantes, rien de plus. Un superadministrateur peut à tout moment couper la synchronisation pour tout le site et révoquer n'importe quel appareil.

Base légale : Intérêt légitime (organisation de l'unité et communication au sein de l'équipe d'animation).

2.14. Carnet d'adresses synchronisé (CardDAV)

Finalité : Ce que les identifiants d'appareil ci-dessus permettent de lire. Le carnet d'adresses d'un téléphone ou d'un ordinateur autorisé se tient à jour tout seul avec les coordonnées de l'équipe d'animation, au lieu qu'un fichier soit réexporté et renvoyé à chaque changement.

Qui figure dans ce carnet : Les animateurs et le Staff d'unité de l'année en cours, et personne d'autre. Aucun animé, aucun numéro de téléphone de parent. C'est exactement l'ensemble que le trombinoscope montre déjà à tout membre identifié du site.

Données transmises : Pour chaque animateur, les mêmes informations que la fiche de contact décrite au point 2.12 — nom, prénom, totem, fonction et section, adresses électroniques, numéros de téléphone, adresse postale, photo de profil et historique des fonctions. Ni la date de naissance, ni le genre, ni le numéro de membre, ni aucune donnée de santé — la mention d'un handicap, notamment, ne quitte jamais le site.

Qui peut y accéder : Uniquement un chef d'unité ou un superadministrateur, depuis un appareil qu'il a lui-même enregistré. Le droit est revérifié à chaque requête, et un superadministrateur peut couper la synchronisation pour tout le site.

Sens de circulation : Le carnet est en lecture seule. Rien de ce qui est modifié sur l'appareil ne remonte vers le site : la source de vérité reste la plateforme Desk de la fédération.

Ce que cela implique : Les coordonnées des animateurs se retrouvent dans le carnet d'adresses d'un appareil personnel, avec les sauvegardes de cet appareil. Le site ne peut plus les en retirer ; révoquer l'appareil arrête seulement les mises à jour suivantes. C'est la raison pour laquelle ce carnet ne contient que l'équipe d'animation, jamais les animés.

Base légale : Intérêt légitime (organisation de l'unité et communication au sein de l'équipe d'animation).

3. Combien de temps conservons-nous vos données

Conformément au principe de limitation de la conservation (art. 5.1.e RGPD), nous ne conservons vos données personnelles que pendant la durée strictement nécessaire aux finalités pour lesquelles elles ont été collectées, ou lorsque la loi l'impose.

3.1. Durées de conservation actives

3.2. Archivage et conservation prolongée

Données des anciens membres : Après le départ d'un membre de l'unité (fin de participation, démission, passage dans une autre unité), ses données personnelles sont conservées pendant une durée maximale de 5 ans puis supprimées définitivement. Cette période permet :

Passé ce délai de 5 ans, toutes les données sont supprimées de manière irréversible, à l'exception des données strictement nécessaires au respect d'une obligation légale (par exemple, conservation des pièces comptables pour l'administration fiscale : 7 ans).

3.3. Journaux et traces techniques

3.4. Suppression sur demande

Vous pouvez demander la suppression anticipée de vos données à tout moment en exerçant votre droit à l'effacement (section 7). La suppression sera effectuée dans un délai d'un mois, sauf obligation légale de conservation.

4. Avec qui partageons-nous vos données

Vos données personnelles ne sont jamais vendues à des tiers. Nous faisons appel à des sous-traitants pour assurer le fonctionnement du site :

4.1. Sous-traitants essentiels

Hébergeur web : L'hébergeur web stocke la base de données, les fichiers uploadés et exécute l'application. La localisation des serveurs et l'identité de l'hébergeur dépendent de la configuration technique de l'unité. Conformément à l'article 28 du RGPD, l'unité s'assure que l'hébergeur présente des garanties suffisantes quant à la sécurité des données. Si l'hébergeur est situé hors de l'Espace économique européen, des garanties appropriées sont mises en place (clauses contractuelles types de la Commission européenne, art. 46 RGPD).

Relais SMTP (optionnel) : Si l'unité utilise un ou plusieurs services SMTP externes pour l'envoi d'emails (au lieu de l'envoi direct depuis le serveur), les emails transitent par ces fournisseurs — liens de connexion, notifications et envois groupés. L'unité peut en déclarer plusieurs et décider, par type de message, lequel est utilisé et lequel prend le relais en cas de panne ou de quota atteint ; la liste en vigueur est consultable dans la configuration du site, page « Courrier sortant ». Les mêmes garanties contractuelles s'appliquent à chacun.

Boîtes témoins de délivrabilité (optionnel, désactivé par défaut, activable et désactivable par l'unité) : Pour savoir si ses envois groupés arrivent bien dans la boîte de réception des familles ou s'ils sont classés en indésirables, l'unité peut déclarer quelques boîtes aux lettres lui appartenant chez différents fournisseurs de messagerie (par exemple une adresse Gmail, une adresse Outlook), puis demander au site d'envoyer à ces boîtes une copie de chaque publipostage. Cette copie porte le texte réel du publipostage, celui que l'unité a écrit et que toutes les familles reçoivent ; elle peut donc contenir les données personnelles que ce texte comporte lui-même. Elle est en revanche débarrassée de tout ce que le site fabrique pour une personne en particulier : le lien de désinscription d'un membre n'y figure jamais — c'est un lien qui permettrait d'agir à la place de cette personne, et il ne sort pas du message qui lui est adressé —, et lorsque le publipostage est personnalisé (les champs de fusion « Bonjour {{Prénom}} », remplis depuis le fichier de l'unité), aucune valeur d'aucune famille n'est recopiée : chaque champ porte, dans la copie, le nom de sa propre colonne. Les pièces jointes ne sont pas recopiées non plus. Les fournisseurs qui hébergent ces boîtes sont, pour ces copies, des sous-traitants au sens de l'article 28 du RGPD, et l'unité choisit lesquels en décidant où elle ouvre ces boîtes ; si elles sont hébergées hors de l'Espace économique européen, les garanties appropriées de l'article 46 s'appliquent. Trois points limitent la portée de ce traitement : les copies ne partent que vers des boîtes appartenant à l'unité, jamais vers un service d'analyse extérieur ; aucune adresse de famille n'y figure, puisque la copie est adressée à la boîte témoin seule ; et le site supprime chaque copie de la boîte témoin dès qu'il a relevé dans quel dossier elle avait atterri, ne conservant ensuite que ce constat — un nom de fournisseur, un dossier, une date. Tant que l'unité n'a pas activé cette option, aucune copie n'est envoyée nulle part.

Le constat tiré de ces boîtes peut amener l'unité — ou, si elle l'a expressément demandé, le site lui-même — à faire passer les envois destinés à un fournisseur de messagerie donné par un autre de ses relais. Ce choix ne concerne que les envois groupés et n'introduit aucun nouveau sous-traitant : il ne fait que désigner, parmi les relais déjà déclarés ci-dessus, lequel est essayé en premier.

Rattachement d'un domaine à son fournisseur de messagerie : Une adresse sur un domaine personnel (par exemple prenom@famille.be) peut être hébergée chez un grand fournisseur sans que rien dans l'adresse ne le dise. Pour compter ces adresses chez leur vrai fournisseur, dans les résultats des boîtes témoins comme dans le choix du relais, le site lit les enregistrements MX publics de chaque domaine auquel il envoie un publipostage, et de celui de chaque boîte témoin configurée : c'est une requête DNS ordinaire, faite une fois par jour en tâche de fond et jamais au moment d'un envoi, par le résolveur DNS du serveur d'hébergement. Seul le nom de domaine est interrogé, jamais l'adresse, et le site ne conserve que le rapprochement « domaine → fournisseur », sans aucune adresse ni aucun nombre de destinataires ; le nom de domaine y est chiffré au repos, comme les adresses email, puisqu'un domaine personnel peut désigner une famille. Cette lecture n'introduit aucun nouveau sous-traitant : elle passe par l'hébergeur déjà mentionné et interroge des informations que chaque domaine publie lui-même.

Service de notifications push du navigateur (optionnel, uniquement si vous activez les notifications push dans « Mon compte ») : Les notifications sont transmises via le protocole standard Web Push (RFC 8030) jusqu'à votre appareil, en passant par le service de push propre à votre navigateur — non choisi par l'unité, mais imposé par le navigateur que vous utilisez :

Ce service ne reçoit que le contenu chiffré de la notification (que lui seul ne peut pas déchiffrer, la clé restant entre le serveur de l'unité et votre appareil) et l'endpoint technique de votre souscription — jamais de donnée personnelle en clair.

Statistiques d'utilisation (optionnel, activable et désactivable par l'unité) : Si l'unité l'autorise, le site transmet une fois par jour un rapport d'utilisation agrégé à l'équipe qui développe ScoutMagic, afin de fournir un meilleur support, de repérer les fonctionnalités réellement utilisées et de décider des développements à venir. Ce rapport n'est pas anonyme : il contient l'adresse de ce site, ce qui permet de rattacher un rapport à l'unité qui demande de l'aide. Il ne contient en revanche aucune donnée de membre — ni nom, ni adresse email, ni photo, ni contenu — mais uniquement des compteurs (nombre de membres actifs, nombre de sections actives, et — si le module « Fréquentation » est activé — le nombre de pages ouvertes par module sur les douze derniers mois) et des informations techniques sur le logiciel et l'hébergement (version installée, modules actifs, version de PHP, moteur de base de données, mode d'envoi des emails, espace disque libre). Il contient en outre le vocabulaire Desk de l'unité : les libellés des fonctions, des branches et des catégories de tarif tels qu'ils ont été importés, et — parmi les fonctions et les branches — ceux que le site n'a pas su rattacher à ses propres tables, afin que ces correspondances manquantes soient ajoutées dans une version suivante du logiciel. Ce sont des mots de la fédération, jamais une donnée de personne : aucun nom de section n'est transmis, parce qu'il est choisi par l'unité et l'identifie bien plus qu'un libellé fédéral, et aucun dénombrement de personnes n'accompagne ces libellés. Si ce site a été remonté ailleurs depuis une sauvegarde emportée — un changement d'hébergeur, une reprise après sinistre — le rapport porte en plus l'identifiant technique de l'installation d'origine, afin que les deux ne soient pas comptées comme deux unités différentes ; c'est un identifiant de site, jamais une donnée de personne. Le détail page par page ne quitte jamais ce site : seul le total par module est transmis. Le destinataire est configurable par l'unité et figure, avec le contenu exact du rapport, sur la page Configuration > Diagnostic du site.

Mesure de la fréquentation du site (module « Fréquentation », optionnel) : lorsqu'il est activé, le site compte les pages ouvertes, par mois et par grande catégorie de public (visiteur anonyme, membre identifié, staff). Le comptage porte sur le motif de la page — « la page d'un membre » — et jamais sur l'adresse consultée, de sorte qu'aucun identifiant de membre n'est enregistré. Aucune donnée nominative n'est conservée : ni adresse IP, ni navigateur, ni parcours individuel, et aucun cookie n'est déposé pour cette mesure — c'est pourquoi elle ne figure dans aucune catégorie des préférences de cookies. Ces compteurs restent sur ce serveur, sauf le total par module si l'unité a activé l'envoi des statistiques d'utilisation ci-dessus. Ils sont supprimés après trois années scoutes.

Sauvegarde hors site (optionnel, raccordé et déraccordé par l'unité) : L'unité peut raccorder son propre compte Google Drive afin que les sauvegardes du site ne dorment pas sur le seul serveur qui les héberge. Le raccordement se fait avec un projet Google créé par l'unité elle-même : c'est son compte, sa console, ses identifiants — l'équipe ScoutMagic n'y a aucun accès et ne reçoit rien. L'autorisation demandée à Google est volontairement la plus étroite qui existe (drive.file) : elle ne donne accès qu'aux fichiers que ce site a lui-même créés, jamais au reste du Drive. Tant que le raccordement est actif, Google connaît l'existence de ce site. L'adresse du compte raccordé s'affiche sur la page Configuration > Maintenance ; elle est conservée chiffrée sur le serveur, au même endroit que les clés du site, et n'apparaît ni dans les réglages ni dans le journal.

Une fois la destination raccordée, l'envoi est récurrent et automatique : le site y dépose une sauvegarde toutes les vingt-quatre heures, sans intervention. Ce qui part est une sauvegarde portable — l'archive complète du site, base de données comprise, donc les données des membres — et elle réside durablement chez Google, et non le temps d'un échange : c'est précisément ce qui lui permet de servir le jour où l'hébergeur a disparu. Google est donc, pour cette copie, un sous-traitant au sens de l'article 28 du RGPD, et les données peuvent être stockées ou traitées hors de l'Espace économique européen ; les transferts reposent sur les garanties appropriées de l'article 46 (clauses contractuelles types) et sur la décision d'adéquation dont bénéficie le cadre de protection des données UE—États-Unis. C'est l'unité, en raccordant son propre compte, qui décide de ce recours et en contracte les conditions avec Google.

L'archive est chiffrée avant de quitter le serveur, avec une phrase de passe que ce site génère lui-même et conserve avec ses clés de chiffrement : son contenu est illisible pour quiconque ne la connaît pas, Google compris, qui ne détient qu'un fichier chiffré dont il n'a pas la clé. La phrase est consultable par un administrateur depuis Configuration > Maintenance, et peut y être régénérée. La galerie photo n'est pas envoyée, sauf si l'unité le demande explicitement par un réglage. Le site éclaircit les archives conservées chez la destination : il garde la plus récente, puis une par semaine sur le mois écoulé, puis une par mois au-delà, ce qui fait remonter les copies jusqu'à environ un an ; ce qui reste est en outre borné en nombre et en volume, et tout le reste est supprimé automatiquement. Le bouton « Déraccorder » efface le jeton d'autorisation et les identifiants du projet : à partir de là, le site ne peut plus rien écrire chez Google, et plus rien ne part. Les sauvegardes déjà déposées restent dans le Drive de l'unité : déraccordé, le site n'y touche plus du tout, ni pour déposer ni pour purger, et leur suppression relève alors de l'unité seule.

Archive de diagnostic : L'unité peut générer, depuis cette même page, une archive de diagnostic destinée à accompagner une demande d'assistance. Cette archive reste sur le serveur et n'est jamais transmise automatiquement : ni tâche planifiée, ni courriel, ni envoi décidé par le site. Elle peut contenir des adresses IP (extraits des journaux du serveur web) et des identifiants internes de membres (journal d'événements du site), mais aucun nom, adresse email ni contenu de membre.

Transmission d'une archive de diagnostic au support ScoutMagic : un administrateur peut choisir de transmettre cette archive à l'équipe qui développe ScoutMagic, en la joignant à un ticket de support depuis Configuration > Diagnostic. Cette transmission n'a jamais lieu sans une action explicite : la page affiche d'abord le contenu de l'archive et sa taille, et demande de cocher que l'administrateur en accepte la transmission. Parce que l'archive peut contenir des adresses IP et des identifiants internes de membres, l'équipe ScoutMagic devient alors sous-traitante pour ces données, au sens de l'article 28 du RGPD. L'archive reçue y est conservée chiffrée, accessible aux seuls administrateurs de l'installation qui la reçoit, et supprimée avec le ticket auquel elle est rattachée. Tant qu'aucun administrateur n'a effectué cette démarche, aucune archive n'a quitté ce serveur.

Copie anonymisée pour le triage des signalements publics : lorsqu'un administrateur cite la référence d'un ticket de support dans un signalement de dysfonctionnement sur le dépôt public du logiciel (GitHub), le triage automatique de ce signalement peut demander à l'équipe ScoutMagic une copie réduite et anonymisée de l'archive transmise avec ce ticket : les adresses IP, les identifiants de compte, les adresses e-mail et les identifiants de membres reconnaissables y sont remplacés par des jetons sans correspondance conservée, et la configuration détaillée du serveur, les paramètres du site, la description du ticket et l'identifiant de l'installation en sont retirés. Cette copie est produite à la demande, n'est pas conservée, et est lue par un service d'intelligence artificielle exécuté sur l'infrastructure de GitHub, qui rédige la première réponse au signalement ; ces deux prestataires, établis aux États-Unis, sont alors sous-traitants pour cette copie. Elle n'est jamais produite sans qu'un administrateur ait lui-même cité la référence du ticket, et la case d'acceptation de la transmission de l'archive le dit expressément.

4.2. Sous-traitants pour fonctionnalités spécifiques (modules)

Ces sous-traitants ne sont sollicités que si les modules correspondants sont activés.

Fournisseurs d'intelligence artificielle (module llm_connector) :

Fournisseur de téléphonie sur IP (module sos_staff) :

Fournisseurs de stockage externe (module gallery, uniquement si au moins un emplacement de stockage externe est configuré — stockage objet compatible S3, partage WebDAV ou dossier Google Drive, et plusieurs peuvent l'être simultanément ; pour un emplacement en stockage local, les fichiers restent sur le serveur de l'hébergeur, déjà couvert en 4.1) :

Résumé automatique des lieux de camp (module camps avec connecteur IA actif) : un court texte résumant ce que les séjours et les avis d'un terrain racontent est écrit par le modèle configuré dans le connecteur IA (voir le paragraphe « Intelligence artificielle » de cette section). Ne lui sont transmis que les avis, notes, prix, statuts, dates, nombres de participants et sections — jamais les coordonnées des contacts, jamais les e-mails reçus. Cette fonctionnalité peut être désactivée dans la configuration du module.

Nom d'un terrain lu dans un message reçu (module camps avec module Courrier entrant et connecteur IA actifs) : pour créer un terrain à partir d'un message arrivé dans une boîte dédiée aux camps, l'objet et le texte du message sont transmis au modèle configuré dans le connecteur IA, à seule fin d'y lire le nom du lieu dont le message parle. Ce texte est écrit par un tiers extérieur à l'unité et peut donc contenir n'importe quelle donnée personnelle qu'il a choisi d'y mettre, sa propre signature comprise : le fournisseur d'IA est un sous-traitant à part entière pour ce traitement. Le modèle a pour consigne de ne jamais renvoyer un nom de personne et de ne rien renvoyer en cas de doute ; rien de ce qui lui est transmis n'est conservé au-delà de l'appel, et seul le nom du terrain retenu est enregistré. Sans connecteur IA, ce traitement n'a pas lieu du tout et aucun texte de message ne quitte l'installation (voir « Création automatique d'un séjour » en section 2.4).

Fond de carte et géocodage (modules camps et covoiturage, uniquement si l'un d'eux est activé) :

Meta (module social, uniquement si une Page Facebook ou un compte Instagram est raccordé) :

4.3. Garanties contractuelles

Conformément à l'article 28 du RGPD, nous nous assurons que tous nos sous-traitants :

5. Où sont stockées vos données et transferts internationaux

5.1. Localisation principale du stockage

La base de données et les fichiers sont stockés sur les serveurs de l'hébergeur web. La localisation géographique des serveurs dépend de l'hébergeur sélectionné par l'unité. Pour toute question sur la localisation précise des données, vous pouvez contacter le responsable de l'unité à l'adresse email indiquée sur la page de contact.

5.2. Transferts hors de l'Union européenne

Certains transferts de données peuvent avoir lieu hors de l'Espace économique européen (EEE) dans les cas suivants :

Aucun autre transfert hors UE n'est effectué. Les fournisseurs Mistral AI, Scaleway et OVH Télécom opèrent tous au sein de l'Union européenne, de même que Hetzner Object Storage, Scaleway Object Storage et OVHcloud Object Storage pour le module galerie. Un partage WebDAV se trouve là où son hébergeur l'héberge, et un dossier Google Drive relève de Google Ireland Limited : lorsque l'un de ces deux emplacements est configuré, sa localisation est celle décrite en section 4.2.

6. Comment protégeons-nous vos données

Conformément à l'article 32 du RGPD, nous mettons en œuvre des mesures techniques et organisationnelles appropriées pour garantir un niveau de sécurité adapté au risque.

6.1. Mesures techniques de sécurité

Chiffrement des données au repos :

Protection des mots de passe :

Protection des API et secrets :

Chiffrement en transit :

6.2. Contrôle d'accès et authentification

6.3. Mesures de sécurité applicative

6.4. Journal d'audit et traçabilité

6.5. Mesures organisationnelles

6.6. Plan de réponse aux incidents

En cas de violation de données personnelles, nous nous engageons à :

7. Vos droits sur vos données personnelles

Conformément au RGPD, vous disposez des droits suivants concernant vos données personnelles :

Comment exercer vos droits : Contactez-nous via l'adresse email indiquée sur la page de contact du site. Nous vous répondrons dans un délai d'un mois maximum.

Réclamation : Si vous estimez que vos droits ne sont pas respectés, vous avez le droit d'introduire une réclamation auprès de l'Autorité de protection des données (APD) belge.

8. Cookies et technologies similaires

Ce site utilise des cookies pour assurer son bon fonctionnement et améliorer votre expérience.

Gestion de vos préférences : Vous pouvez consulter la liste complète des cookies utilisés et gérer vos préférences (accepter ou refuser les cookies non essentiels) à tout moment sur la page de préférences cookies. Les cookies essentiels au fonctionnement du site (authentification, sécurité) ne peuvent pas être désactivés.

Base légale : Consentement pour les cookies non essentiels (art. 6.1.a RGPD), intérêt légitime pour les cookies essentiels (art. 6.1.f RGPD).

9. Politique de la fédération Les Scouts

En tant qu'unité affiliée aux Scouts ASBL, les données de nos membres sont également soumises à la politique de protection des données de la fédération Les Scouts. Nous vous invitons à consulter leur charte de protection des données personnelles pour plus d'informations sur les traitements effectués au niveau fédéral.

10. Modifications de cette politique

Nous nous réservons le droit de modifier cette politique de confidentialité à tout moment pour refléter les évolutions de nos pratiques ou de la législation. La date de dernière mise à jour est indiquée en haut de cette page. Nous vous encourageons à consulter régulièrement cette page pour rester informé de la manière dont nous protégeons vos données.

Aide · Protection des données
Vos données personnelles

La page « Protection des données » explique quelles informations le site traite, pourquoi, combien de temps, et quels sont vos droits. Elle est publique : vous pouvez la lire sans être connecté, et un lien y mène depuis le bas de chaque page.

D'où viennent les informations vous concernant

L'essentiel provient de l'inscription de votre enfant auprès de l'unité et de la base de la fédération : noms, coordonnées, section. Le site y ajoute ce que vous faites vous-même : une photo déposée, une adresse e-mail ajoutée, un message publié dans un groupe. La page détaille chaque catégorie et sa durée de conservation.

Vos droits

Vous pouvez demander à consulter, corriger ou effacer les données qui vous concernent, dans les limites que la page décrit. Votre interlocuteur est le Staff d'Unité : ses coordonnées se trouvent sur la page Contact. Pour les informations issues de la base de la fédération (coordonnées, date de naissance...), la correction se fait à la source, par le Staff d'Unité — c'est pourquoi la page d'un animé ne permet pas de les modifier directement.

Les cookies

La page renvoie vers « Préférences cookies » pour la liste complète des cookies et le réglage de votre consentement : la liste y est toujours à jour, catégorie par catégorie, avec la finalité et la durée de chacun.

La date en haut de page

La ligne « Dernière mise à jour » indique quand le texte a réellement changé pour la dernière fois. Le contenu est sous la responsabilité du Staff d'Unité, qui peut utiliser le texte de référence fourni avec le site ou l'adapter à la situation de l'unité.

Ouvrir dans l'aide Tous les sujets

Ce site utilise des cookies

Nous utilisons des cookies strictement nécessaires au fonctionnement du site. D'autres cookies optionnels peuvent améliorer votre expérience. En savoir plus

Personnaliser