Contrat de sous-traitance (DPA)

Contrat de sous-traitance (DPA)

Traitement de données personnelles pour le compte du Client

Parties

Le présent contrat de sous-traitance (« DPA ») est un contrat autonome entre le Sous-traitant et le Client. Il régit l'ensemble des traitements de données personnelles que LogSheet effectue pour le compte du Client et il est conclu lorsque le Client enregistre un compte d'entreprise et l'accepte lors de l'inscription, selon les modalités décrites sous « Conclusion du présent DPA » ci-dessous.

Dans le présent DPA, le « Contrat principal » désigne la relation de service entre les parties par laquelle LogSheet met à la disposition du Client les applications web et iPhone LogSheet — formée lors de l'enregistrement d'un compte d'entreprise et se poursuivant aussi longtemps que ce compte est utilisé. Si les parties conviennent ultérieurement de conditions générales ou d'un contrat d'abonnement distincts, ceux-ci font partie du Contrat principal et le présent DPA continue de s'appliquer parallèlement. En cas de contradiction sur une question de protection des données, le présent DPA prévaut.

1. Objet, rôles et durée

1.1 Rôles. LogSheet est une application SaaS multi-locataire de saisie du temps de travail, des absences, des demandes de congé et — en option — du temps consacré aux clients et projets. S'agissant des données personnelles des collaborateurs du Client et des contacts commerciaux du Client saisis dans l'application, le Client est responsable du traitement et LogSheet est sous-traitant au sens des art. 5 let. j et 9 de la loi fédérale sur la protection des données du 25 septembre 2020 (« nLPD / revDSG / nFADP », en vigueur depuis le 1er septembre 2023) et, le cas échéant, des art. 4 ch. 8 et 28 RGPD.

1.2 Objet. LogSheet traite les données personnelles à seule fin de fournir, maintenir, sécuriser et supporter l'application web LogSheet (logsheet.ch) et l'application iPhone LogSheet, telles que décrites dans le Contrat principal.

1.3 Ce que le présent DPA ne couvre pas. LogSheet agit comme responsable du traitement indépendant, et non comme sous-traitant, pour : (a) la relation de compte et de facturation avec le Client ; (b) les demandes de support adressées via le widget de support intégré et le formulaire de contact ; (c) les diagnostics techniques d'erreur collectés pour maintenir le service en état de marche ; et (d) les visiteurs du site public logsheet.ch. Ces traitements relèvent de la déclaration de confidentialité LogSheet, non du présent DPA. L'annexe A les identifie expressément.

1.4 Durée. Le présent DPA prend effet à la date indiquée et demeure en vigueur aussi longtemps que LogSheet traite des données personnelles pour le compte du Client, soit pendant la durée du Contrat principal, prolongée du délai de restitution/suppression prévu au ch. 12.

2. Nature et finalité du traitement

LogSheet effectue, pour le compte du Client, les opérations de traitement suivantes :

Les catégories de données et de personnes concernées figurent à l'annexe A.

3. Instructions du responsable du traitement

3.1 LogSheet ne traite les données personnelles que sur instruction documentée du Client, y compris s'agissant des transferts vers un État tiers. Le Contrat principal, le présent DPA et l'utilisation par le Client des options de configuration de l'application (rôles, départements, réglage de confidentialité des absences, décisions de conservation, exports, suppressions) constituent les instructions documentées du Client.

3.2 LogSheet informe le Client sans délai si, à son avis, une instruction viole la nLPD, le RGPD ou une autre disposition applicable en matière de protection des données. LogSheet peut suspendre l'exécution de cette instruction jusqu'à confirmation ou modification.

3.3 LogSheet n'utilise pas les données du Client à ses propres fins, ne les vend pas, ne les utilise pas à des fins publicitaires et ne les utilise pas pour entraîner des modèles d'apprentissage automatique ou d'IA. LogSheet peut calculer des statistiques d'usage agrégées et non identifiantes à des fins de dimensionnement et d'amélioration du service.

3.4 Le Client garantit qu'il dispose d'une base légale pour les données qu'il saisit dans LogSheet, qu'il a informé ses collaborateurs conformément à l'art. 19 nLPD (ou aux art. 13/14 RGPD) et qu'il respecte les limites du droit suisse du travail en matière de surveillance des travailleurs, en particulier l'art. 26 OLT 3, qui interdit les systèmes de surveillance destinés à contrôler le comportement des travailleurs.

4. Confidentialité

4.1 LogSheet maintient confidentielles toutes les données personnelles traitées au titre du présent DPA et ne les communique à aucun tiers, hormis aux sous-traitants ultérieurs listés à l'annexe B ou lorsque la loi l'impose.

4.2 L'accès aux données du Client en production est limité aux personnes qui en ont besoin pour exploiter et supporter le service. À la date d'entrée en vigueur, il s'agit d'une seule personne : Ben Chaulet, exploitant de LogSheet. Cette personne est soumise à une obligation de confidentialité qui survit à la fin de son intervention. Tout futur employé, mandataire ou indépendant disposant d'un accès sera soumis à un engagement écrit de confidentialité équivalent avant l'octroi de cet accès.

4.3 Lorsque la loi contraint LogSheet à communiquer des données du Client à une autorité, LogSheet en informe le Client au préalable — sauf interdiction légale — et limite la communication à ce qui est juridiquement exigé.

5. Sécurité du traitement (mesures techniques et organisationnelles)

5.1 LogSheet met en œuvre des mesures techniques et organisationnelles (« MTO ») appropriées pour garantir un niveau de sécurité adapté au risque, conformément à l'art. 8 nLPD et aux art. 1 à 3 de l'ordonnance sur la protection des données (OPDo), ainsi que, le cas échéant, à l'art. 32 RGPD. Les mesures en vigueur sont décrites à l'annexe C.

5.2 LogSheet tient compte du fait que les données comprennent des données personnelles sensibles au sens de l'art. 5 let. c ch. 2 nLPD (données sur la santé), dès lors que des absences peuvent être enregistrées comme maladie et que les champs libres de remarques et de commentaires de validation peuvent contenir des informations de santé. L'annexe C décrit les mesures spécifiques applicables à ces données.

5.3 LogSheet peut adapter les MTO en tout temps, pour autant que le niveau de protection ne soit pas réduit. Toute réduction substantielle est annoncée au Client au préalable.

6. Sous-traitance ultérieure

6.1 Autorisation générale. Le Client autorise LogSheet, de manière générale, à recourir à des sous-traitants ultérieurs. Ceux auxquels il est recouru à la date d'entrée en vigueur figurent à l'annexe B.

6.2 Conditions. LogSheet impose à chaque sous-traitant ultérieur, par contrat écrit, des obligations de protection des données substantiellement équivalentes à celles du présent DPA, et demeure pleinement responsable envers le Client de l'exécution de leurs obligations.

6.3 Modifications. LogSheet informe le Client au moins 30 jours avant l'ajout ou le remplacement d'un sous-traitant ultérieur, par courriel au contact administratif du Client et par la mise à jour de la liste publique des sous-traitants ultérieurs sur logsheet.ch/subprocessors, qui porte la date de sa dernière modification (cette adresse renvoie à la section « sous-traitants ultérieurs » de la politique de confidentialité). Le Client peut s'y opposer dans ce délai pour des motifs raisonnables et documentés tenant à la protection des données. À défaut d'accord, le Client peut résilier sans pénalité la partie concernée du Contrat principal, avec effet à la date d'entrée en vigueur du changement.

6.4 Connexions à un assistant IA (export à l'initiative de l'utilisateur). LogSheet propose une connexion facultative permettant à un utilisateur autorisé du Client de mettre des données de temps de travail à la disposition d'un assistant d'intelligence artificielle choisi par le Client lui-même, au moyen d'une interface en lecture seule. La connexion est établie par utilisateur, exige que celui-ci s'authentifie et donne son consentement explicite, se limite à la lecture des données et peut être révoquée à tout moment par l'utilisateur ou par le Client. Lorsqu'une telle connexion est établie, le Client demeure responsable du traitement et le fournisseur de l'assistant IA agit en qualité de sous-traitant du Client, et non de LogSheet : LogSheet ne choisit pas le fournisseur, ne détermine pas les finalités du traitement et ne transmet aucune donnée en dehors d'une requête authentifiée avec le consentement de cet utilisateur. Ce fournisseur n'est donc pas un sous-traitant ultérieur de LogSheet et ne figure pas à l'Annexe B ; il appartient au Client de conclure avec lui les accords nécessaires.

Deux garanties s'appliquent à chaque connexion. Premièrement, LogSheet pseudonymise les données avant qu'elles ne quittent la plateforme : les noms des personnes physiques sont remplacés par leurs initiales accompagnées d'un code stable et non réversible, les adresses de courriel et les numéros de téléphone sont masqués, et la raison sociale du Client est remplacée par un code. Le fournisseur reçoit ainsi des données de temps de travail qui ne sont pas directement attribuables à une personne physique identifiée, et LogSheet ne transmet pas les identifiants qui le permettraient. Deuxièmement, une administratrice ou un administrateur n'obtient des enregistrements de temps de travail individuellement identifiables que pour les périodes que la personne concernée a validées ; pour toute autre période, seules des données agrégées portant sur au moins trois personnes sont disponibles. Il appartient au Client d'informer ses collaboratrices et collaborateurs de l'usage d'une telle connexion lorsque son propre cadre juridique l'exige.

7. Assistance à l'exercice des droits des personnes concernées

7.1 Compte tenu de la nature du traitement, LogSheet assiste le Client, par des mesures techniques et organisationnelles appropriées, dans l'exécution de son obligation de donner suite aux demandes d'exercice des droits prévus aux art. 25 à 29 nLPD (accès, rectification, effacement, remise/portabilité, opposition) et, le cas échéant, au chapitre III RGPD.

7.2 Si une personne concernée s'adresse directement à LogSheet, LogSheet n'y répond pas sur le fond. LogSheet transmet la demande au Client sans délai et renvoie la personne concernée au Client, responsable du traitement.

7.3 Ce que l'application permet déjà. Le Client peut satisfaire lui-même la plupart des demandes, sans intervention de LogSheet :

• Accès / portabilité : exports Excel mensuels et annuels, exports CSV pour la paie, vue Archives, calendrier annuel par collaborateur.
• Rectification : les administrateurs peuvent corriger les saisies et les paramètres d'emploi pour tout mois non verrouillé/approuvé ; un mois verrouillé peut être rouvert par un administrateur.
• Effacement : les administrateurs peuvent supprimer des saisies et désactiver des comptes ; le collaborateur peut supprimer son propre compte dans l'application iPhone (voir ch. 7.4).

7.4 Suppression de compte en libre-service et ses limites assumées. L'application iPhone LogSheet propose la suppression du compte depuis l'application. Lorsqu'un utilisateur la déclenche :

• le compte Firebase Authentication est supprimé et tous les jetons de rafraîchissement sont révoqués — la personne ne peut plus se connecter ;
• ses données de profil identifiantes (nom affiché, adresse e-mail, date de naissance, numéro de personnel) sont retirées de sa fiche utilisateur et remplacées par un marqueur « Deleted employee » ;
• ses feuilles de temps, saisies journalières et saisies de travail client sont délibérément conservées, rattachées à un identifiant qui ne correspond plus à une personne dans le système, avec les paramètres d'emploi (taux d'activité, horaire hebdomadaire, droit aux vacances) qui rendent ces enregistrements interprétables.

Ce choix s'explique par le fait que ces enregistrements constituent la documentation de la durée du travail du Client, que celui-ci est légalement tenu de conserver (art. 73 al. 2 OLT 1 : cinq ans) et qui n'appartient donc pas au collaborateur d'effacer. Toute suppression allant au-delà ne peut être ordonnée que par le Client, en sa qualité de responsable du traitement. LogSheet ne prétendra jamais, envers une personne concernée, effacer davantage que ce qui l'est réellement.

7.5 L'assistance dépassant les fonctions en libre-service ci-dessus est fournie dans une mesure raisonnable, sur demande ; LogSheet peut facturer un effort disproportionné, après en avoir informé le Client.

8. Assistance aux autres obligations du responsable du traitement

Compte tenu de la nature du traitement et des informations à sa disposition, LogSheet assiste le Client pour :

• la sécurité du traitement (art. 8 nLPD / art. 32 RGPD) — en fournissant l'annexe C et en répondant, dans une mesure raisonnable, aux questionnaires de sécurité ;
• les analyses d'impact relatives à la protection des données (art. 22 nLPD / art. 35 RGPD) et la consultation préalable de l'autorité — en fournissant les informations techniques nécessaires ;
• l'annonce des violations de la sécurité des données (art. 24 nLPD / art. 33 et 34 RGPD) — conformément au ch. 9.

9. Violations de la sécurité des données

9.1 Annonce au Client. LogSheet annonce au Client toute violation de la sécurité des données affectant les données personnelles du Client dans les meilleurs délais et en tout état de cause dans les 48 heures suivant sa prise de connaissance, par courriel au contact administratif du Client et, lorsqu'un canal plus rapide se justifie, par téléphone.

9.2 Contenu. L'annonce décrit, dans la mesure des informations disponibles : la nature de la violation ; les catégories et le nombre approximatif de personnes concernées et d'enregistrements en cause ; les conséquences probables ; les mesures prises ou envisagées pour y remédier et en atténuer les effets ; et un point de contact. Si les informations ne sont pas disponibles immédiatement, elles sont fournies par étapes, sans nouveau retard injustifié.

9.3 Rôles. Il appartient au Client, en sa qualité de responsable du traitement, d'apprécier si la violation entraîne vraisemblablement un risque élevé pour la personnalité ou les droits fondamentaux des personnes concernées et, le cas échéant, d'annoncer la violation au Préposé fédéral à la protection des données et à la transparence (PFPDT / EDÖB / FDPIC) dans les meilleurs délais, conformément à l'art. 24 al. 1 nLPD, et/ou à l'autorité de contrôle européenne compétente dans les 72 heures conformément à l'art. 33 RGPD, ainsi que d'informer les personnes concernées lorsque cela est requis. LogSheet ne procède pas à cette annonce au nom du Client, sauf instruction écrite expresse.

9.4 Coopération et documentation. LogSheet coopère avec le Client à l'investigation et à la remédiation, et documente les faits, les effets et les mesures correctives.

10. Droit d'audit

10.1 LogSheet met à la disposition du Client toutes les informations nécessaires pour démontrer le respect du présent DPA, en premier lieu sous la forme des annexes du présent DPA, de sa documentation de sécurité et des certifications et rapports d'audit de ses sous-traitants ultérieurs (notamment les rapports ISO/CEI 27001, 27017, 27018 et SOC 2/3 de Google Cloud, disponibles sur le portail de conformité Google Cloud).

10.2 Si ces documents s'avèrent insuffisants, le Client peut — à ses frais, au maximum une fois par année civile sauf après une violation de la sécurité des données, moyennant un préavis écrit de 30 jours, pendant les heures ouvrables et sous réserve de confidentialité — procéder à un audit ou mandater à cet effet un auditeur indépendant qui ne soit pas un concurrent de LogSheet. L'audit ne doit ni perturber le service ni compromettre la confidentialité des données d'autres clients.

10.3 Les audits des centres de données des sous-traitants ultérieurs sont exclus ; leurs certifications et rapports d'audit s'appliquent à leur place. LogSheet n'a aucun accès physique à l'infrastructure Google Cloud.

11. Transferts internationaux et localisation des données

11.1 Lieu de conservation principal. Les données applicatives du Client — profils utilisateurs, feuilles de temps, saisies journalières, absences, données clients/projets, factures, notifications, sauvegardes — sont conservées dans Google Cloud Firestore, multirégion `nam5` — les États-Unis (confirmé dans la console Firebase le 29 juillet 2026). Les Cloud Functions qui traitent ces données s'exécutent dans la région `europe-west6` (Zurich, Suisse) : la logique de traitement est donc suisse, mais la base de données ne l'est pas. Le transfert de données personnelles vers les États-Unis repose sur la certification de Google LLC au titre du Swiss–U.S. Data Privacy Framework et de l'EU–U.S. Data Privacy Framework, ainsi que sur les clauses contractuelles types avec avenant suisse figurant au Google Cloud Data Processing Addendum.

11.2 Services non liés à une région. Les composants suivants sont fournis par Google sur une infrastructure mondiale et ne sont pas confinés à la Suisse :

• Firebase Authentication (identitytoolkit.googleapis.com) — conserve l'adresse e-mail, l'empreinte du mot de passe, l'identifiant de compte (UID) et les horodatages de connexion. Google n'offre pas d'option de résidence Suisse/UE pour ce service ; le traitement peut avoir lieu aux États-Unis.
• Firebase Hosting — l'application web statique est distribuée depuis le CDN mondial de Google ; les journaux serveur peuvent être traités hors de Suisse.
• App Check (reCAPTCHA v3 sur le web, Apple App Attest sur iOS) — jetons d'attestation et, pour reCAPTCHA, adresse IP et signaux d'interaction.
• Google Analytics for Firebase — site public uniquement, soumis au consentement ; voir ch. 11.5.

11.3 Mécanisme juridique. Les transferts vers les États-Unis sont couverts par (i) la décision d'adéquation du Conseil fédéral reconnaissant le Swiss–U.S. Data Privacy Framework (Google LLC est certifiée au titre de l'EU–U.S. DPF et de son extension suisse) et, à titre de garantie complémentaire, (ii) les clauses contractuelles types avec l'avenant suisse figurant dans le Cloud Data Processing Addendum de Google, auquel LogSheet a souscrit. Le Client en prend acte.

11.4 Courrier électronique sortant. Les courriels transactionnels (vérification, réinitialisation de mot de passe, message de bienvenue au collaborateur, rappels, digests, avis d'exploitation) sont envoyés via le relais SMTP authentifié de Hostpoint AG (Rapperswil-Jona, Suisse), depuis la boîte info@logsheet.ch, en TLS implicite sur le port 465. Le contenu du message — adresse du destinataire, nom affiché et objet de la notification — transite et est conservé sur une infrastructure suisse. L'acheminement ultérieur vers le fournisseur de messagerie du destinataire échappe au contrôle de LogSheet.

11.5 Analyse d'audience. Google Analytics for Firebase ne fonctionne que sur le site public logsheet.ch, uniquement après acceptation de la bannière cookies, et jamais dans l'application iPhone (la version mobile remplace le module d'analyse par un module inerte). Aucun SDK d'analyse ou de publicité ne traite de données à l'intérieur de l'application authentifiée. Aucun SDK tiers de publicité, d'attribution ou de rejeu de session n'est présent dans l'une ou l'autre application — ce point a été vérifié dans les manifestes de dépendances des trois paquets (web, functions/, TimeSheetApp/).

11.6 Flux iCal. Lorsqu'un collaborateur active le flux calendrier optionnel, les événements d'absence sont servis par un point d'accès Cloud Functions (europe-west6) en HTTPS, authentifié par un jeton non devinable inclus dans l'URL d'abonnement. Le flux comporte le nom du collaborateur et ses absences, libellées selon les catégories listées à l'annexe A. Une fois l'abonnement établi, une copie de ces données réside chez le fournisseur d'agenda choisi par le collaborateur (Apple, Google, Microsoft, etc.), en dehors du contrôle de LogSheet et du Client et hors du champ du présent DPA. Le collaborateur peut invalider et renouveler le jeton en tout temps depuis l'application.

12. Restitution et suppression au terme du contrat

12.1 À la fin du Contrat principal, le Client dispose de 30 jours pour exporter lui-même ses données au moyen des fonctions d'export Excel, CSV et PDF de l'application. Sur demande écrite dans ce même délai, LogSheet fournit un export complémentaire des données de l'espace du Client dans un format structuré, couramment utilisé et lisible par machine.

12.2 À l'issue de ce délai, LogSheet supprime les données personnelles du Client, y compris des systèmes actifs, dans un délai de 90 jours, sauf obligation légale suisse ou européenne de conservation. Les copies résiduelles présentes dans les sauvegardes automatiques de Google Cloud sont écrasées au fil du cycle ordinaire de sauvegarde.

12.3 Le Client reconnaît qu'en sa qualité d'employeur il est soumis à des obligations légales de conservation des enregistrements de la durée du travail (cinq ans selon l'art. 73 al. 2 OLT 1, et dix ans pour les pièces comptables selon l'art. 958f CO) et qu'il lui incombe d'exporter et de conserver ces enregistrements avant que la suppression n'intervienne.

12.4 Sur demande, LogSheet confirme la suppression par écrit.

13. Responsabilité, droit applicable et dispositions diverses

13.1 La responsabilité entre les parties est régie par le Contrat principal et, à défaut de dispositions convenues, par le droit suisse. Aucune disposition du présent DPA ne restreint les droits des personnes concernées à l'égard de l'une ou l'autre partie en vertu du droit applicable en matière de protection des données.

13.2 Le présent DPA est régi par le droit suisse, à l'exclusion des règles de conflit de lois et de la CVIM. Le for est Lucerne, sous réserve de tout for impératif.

13.3 Lorsque le RGPD s'applique au traitement du Client, le présent DPA doit être lu comme satisfaisant également à l'art. 28 par. 3 RGPD, et les parties concluront les clauses contractuelles types de l'UE si et dans la mesure où la loi l'exige.

13.4 Toute modification requiert la forme écrite (la forme électronique suffit). L'invalidité d'une clause n'affecte pas les autres.

Conclusion du présent DPA

Le présent DPA est autonome et conclu par voie électronique ; aucune signature n'est requise pour qu'il lie les parties. Le Client le conclut lors de l'enregistrement de son compte d'entreprise : le formulaire d'inscription indique que la personne qui s'inscrit accepte, au nom de l'entreprise, la politique de confidentialité et le présent contrat de sous-traitance, et renvoie à l'un comme à l'autre. LogSheet conserve la date de cette acceptation avec le compte.

La personne qui enregistre le compte garantit qu'elle est habilitée à conclure le présent DPA au nom du Client.

Un exemplaire PDF contresigné, ainsi qu'une version portant les données propres au Client, sont disponibles sur demande à info@logsheet.ch.

Annexe A — Catégories de données et de personnes concernées

Reflète le modèle de données réellement persisté par l'application au 29 juillet 2026 (collections Firestore `users`, `timesheets` et sous-collections, `projectTimesheets`, `customers`, `projects`, `invoices`, `notifications`, `archives`, `icalTokens`, `holidays`, `announcementAssignments`, `officeTaskAssignments`).

A.1 Catégories de personnes concernées

A.2 Catégories de données personnelles traitées par LogSheet en qualité de sous-traitant

A.3 Catégories de données traitées par LogSheet en qualité de responsable du traitement (hors du présent DPA)

A.4 Fréquence et volume

Traitement continu pendant la durée du Contrat principal. Volume : un jeu d'enregistrements par collaborateur et par jour ouvré, plus les récapitulatifs mensuels et les instantanés hebdomadaires de sauvegarde.

Annexe B — Sous-traitants ultérieurs

Au 29 juillet 2026. Vérifié sur la base de `firebase.json`, `.firebaserc`, `src/firebase.js`, `functions/index.js` et des manifestes de dépendances des trois paquets.

Remarques

• Aucun prestataire de paiement. LogSheet n'intègre aucun prestataire de paiement (ni Stripe, ni PayPal). La gestion des plans est interne (free / enterprise, avec une règle de droits acquis) ; la facturation éventuelle est traitée en dehors de l'application.
• Aucun SDK d'analyse, de publicité, d'attribution, de rejeu de session, de suivi d'erreurs ou de CRM au-delà de la mesure Google Analytics décrite ci-dessus. Vérification effectuée : ni Sentry, ni PostHog, ni Mixpanel, ni Amplitude, ni Segment, ni Intercom, ni Crisp, ni Hotjar, ni Clarity, ni pixel Meta/LinkedIn/TikTok, ni Plausible, ni Matomo dans aucun des trois manifestes de dépendances.
• L'application iPhone ne contient aucune mesure d'audience — la version mobile résout le module d'analyse vers un module volontairement inerte.
• Le site public intègre deux images de badge statiques (Product Hunt, PostYourStartup). Toutes deux sont servies depuis le domaine de LogSheet : leur affichage ne provoque aucune requête vers un hôte tiers et ne divulgue aucune adresse IP de visiteur.

Annexe C — Mesures techniques et organisationnelles (MTO)

Art. 8 nLPD et art. 1 à 3 OPDo ; art. 32 RGPD le cas échéant. Chaque mesure ci-dessous correspond à un élément réellement mis en œuvre dans le code ou dans le projet Firebase au 29 juillet 2026. Les lacunes connues et les améliorations prévues sont listées ici délibérément plutôt qu'omises.

C.1 Confidentialité — contrôle d'accès

Cloisonnement des espaces clients. Chaque document porte un companyId, et chaque lecture et écriture est filtrée par des règles de sécurité Firestore qui le comparent à celui de l'appelant. Les requêtes par groupe de collections sur les saisies journalières et le travail client sont filtrées sur companyId au niveau des règles : un client qui omettrait ce filtre est rejeté plutôt que servi avec les données d'un autre locataire. Le fichier de règles est traité comme un contrat d'interface et est couvert par une suite de tests automatisés (30 tests) qui doit passer avant tout déploiement.

Modèle de rôles. Trois rôles (user, admin, super_admin), complétés par un mécanisme de délégation : un administrateur peut accorder à un collaborateur l'accès à certains onglets d'administration uniquement, éventuellement restreint à un ou plusieurs départements et en lecture seule (settings.viewableDepartments). Cette restriction départementale est appliquée dans les règles de sécurité, et non seulement dans l'interface, et lit le département de la personne visée en direct sur sa fiche, jamais depuis une valeur fournie par le client.

Autorité côté serveur. Les opérations sensibles s'exécutent dans des Cloud Functions avec le SDK Admin et revérifient les droits de l'appelant côté serveur : création d'entreprise, création de compte collaborateur, vérification de domaine, nettoyage des comptes orphelins, suppression de compte, émission de jeton iCal. Un client ne peut pas les déclencher en manipulant l'interface.

Moindre privilège en exploitation. L'accès à la production est limité à l'exploitant (ch. 4.2). Les scripts d'administration lisent leurs identifiants depuis .env, exclu du dépôt Git.

C.2 Confidentialité — pseudonymisation et minimisation

• Contrôle de confidentialité des absences maladie : un réglage au niveau de l'entreprise masque le motif de l'absence d'un collègue aux autres collaborateurs ; un consultant restreint voit « Absent » au lieu de « Malade ». Un collaborateur voit toujours le motif réel sur sa propre ligne. La règle est portée par un hook partagé utilisé par les applications web et mobile, qui ne peuvent donc pas diverger.
• La suppression de compte est un marqueur, non une purge : les champs identifiants sont retirés et remplacés par un marqueur non identifiant, tandis que l'enregistrement de la durée du travail — que l'employeur doit conserver — reste rattaché à un identifiant ne correspondant plus à une personne (ch. 7.4). Il s'agit d'une pseudonymisation par conception.
• Les journaux d'erreurs sont tronqués : message et contexte plafonnés à 1 000 caractères, user-agent à 300, et les erreurs identiques sont dédupliquées dans une fenêtre de 60 secondes, afin que les diagnostics restent minimaux.
• Aucune surveillance du comportement des collaborateurs : l'application enregistre le temps de travail tel que le collaborateur le saisit. Aucune capture de frappe, d'écran, de position ou d'activité. lastActive est un simple horodatage servant à afficher la présence dans la vue Équipe.
• Authentification non énumérante : les flux de réinitialisation de mot de passe et d'aide à la connexion renvoient la même réponse que l'adresse existe ou non, et sont limités en débit côté serveur.

C.3 Confidentialité — chiffrement

• En transit : HTTPS/TLS partout. HSTS configuré avec max-age=63072000; includeSubDomains; preload. Le SMTP sortant utilise TLS implicite sur le port 465.
• Au repos : toutes les données Firestore et Cloud Functions sont chiffrées au repos par Google Cloud (AES-256, clés gérées par Google) par défaut.
• Mots de passe : conservés et vérifiés exclusivement par Firebase Authentication (scrypt) ; LogSheet ne voit ni ne stocke jamais un mot de passe. Une check-list de robustesse est imposée à l'inscription et lors du changement de mot de passe.
• Secrets : le mot de passe SMTP est conservé dans Google Secret Manager et injecté dans les seules fonctions qui en ont besoin ; aucun identifiant n'est versionné dans le dépôt. Des mots de passe autrefois codés en dur dans des scripts ont été retirés en juillet 2026 mais subsistent dans l'historique Git tant qu'ils n'ont pas été renouvelés.

C.4 Confidentialité — durcissement applicatif et plateforme

• App Check atteste que les requêtes proviennent de l'application authentique : reCAPTCHA v3 sur le web, Apple App Attest sur iOS. L'application forcée est actuellement activée pour Firebase Authentication (`identitytoolkit`) et désactivée pour Firestore (vérifié le 27 juillet 2026). Son activation sur Firestore est une décision en attente et assumée, car elle doit être séquencée derrière la barrière de mise à jour forcée de l'application mobile.
• Content-Security-Policy stricte sur chaque réponse, avec frame-ancestors 'none', object-src 'none', base-uri 'self', form-action 'self' et une liste blanche explicite connect-src ; complétée par X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin et une Permissions-Policy désactivant caméra, microphone, géolocalisation, paiement et USB.
• Contrôle des inscriptions : l'auto-inscription n'est possible que pour les domaines e-mail dont l'entreprise a prouvé le contrôle, par un enregistrement DNS TXT ou un courriel de vérification adressé à une boîte standard. Les domaines gratuits et jetables sont refusés sur la base d'une liste de plus de 12 000 entrées. La liste des entreprises n'est pas lisible publiquement ; la recherche passe par un appel serveur.
• Limitation de débit sur les demandes de réinitialisation de mot de passe et d'aide à la connexion, par adresse et appliquée côté serveur.
• Le flux iCal est protégé par un jeton aléatoire de 192 bits (crypto.randomBytes(24)), que le collaborateur peut renouveler à volonté ; un jeton inconnu renvoie 404 et non 401, de sorte qu'un jeton scanné ne se distingue pas d'une faute de frappe. Le flux est, par nature, une capacité au porteur : quiconque détient l'URL peut la lire. C'est inhérent au standard iCal ; le point est documenté pour les collaborateurs et le jeton est renouvelable.

C.5 Intégrité

• Les règles de sécurité Firestore constituent le point unique d'application des écritures et sont couvertes par une suite de tests automatisés.
• Verrouillage et approbation des mois : un mois approuvé est gelé ; la tâche de sauvegarde automatique ignore explicitement les mois approuvés, de sorte qu'une archive ne peut pas être écrasée silencieusement.
• Les noms de champs persistés sont traités comme un contrat gelé entre les clients web et iPhone (on peut ajouter un champ, jamais le renommer), ce qui évite toute corruption silencieuse pendant les 24 à 48 h de décalage de publication sur l'App Store.
• La numérotation des factures est attribuée dans une transaction Firestore : deux administrateurs ne peuvent pas entrer en collision.
• Détection des échecs silencieux : chaque écriture en base rejetée est capturée, enregistrée et envoyée par courriel à l'exploitant, afin qu'une erreur de permission ou de quota ne puisse pas faire perdre silencieusement les données d'un collaborateur.

C.6 Disponibilité et résilience

• Google Cloud Firestore en nam5 assure une réplication multirégionale et des sauvegardes automatiques au niveau de la plateforme, au sein de cette multirégion (États-Unis).
• Sauvegarde applicative : une Cloud Function planifiée (snapshotWeeklyTimesheets, chaque lundi à 03h00 Europe/Zurich) écrit un instantané des saisies journalières et des totaux de chaque mois non approuvé dans une sous-collection backups. Les instantanés sont idempotents par semaine ISO. Les administrateurs peuvent restaurer depuis un instantané dans l'interface.
• Les utilisateurs peuvent exporter à tout moment leurs données et celles de leur entreprise vers Excel, CSV ou PDF — une copie hors ligne indépendante, sous le contrôle du Client.
• Les Cloud Functions s'exécutent avec un nombre maximal d'instances plafonné, ce qui limite l'emballement de la charge et des coûts.

C.7 Contrôle, évaluation et tests réguliers

• Tests unitaires automatisés de la logique métier partagée (npm run test:unit) et suite de tests dédiée aux règles Firestore (npm run test:rules), exécutés en intégration continue à chaque poussée et chaque pull request, séparément pour le paquet web et pour le paquet mobile.
• Analyse statique (lint) avec tolérance zéro aux avertissements en CI.
• Un audit documenté de sécurité et de scalabilité, en lecture seule, a été mené en juillet 2026 ; sa conclusion critique (une règle de lecture trop large sur les archives) a été corrigée, et les conclusions restantes sont suivies avec des décisions explicites.
• Les dépendances sont figées dans des fichiers de verrouillage et mises à jour de manière délibérée.

C.8 Mesures organisationnelles

• La protection des données relève de la responsabilité personnelle de l'exploitant, point de contact unique à info@logsheet.ch.
• Obligations de confidentialité selon le ch. 4.2.
• Contrats de sous-traitance ultérieure : le Google Cloud Data Processing Addendum ; les accords du programme pour développeurs Apple ; et, pour Hostpoint AG, les clauses de sous-traitance figurant dans ses conditions générales, conformes à la nLPD révisée et applicables au compte de plein droit, sans signature distincte. Une copie datée de chacun est conservée.
• Gestion des incidents : les alertes d'exploitation (erreurs de base de données, nouvelles inscriptions, tickets de support) sont adressées par courriel à l'exploitant ; le traitement des violations suit le ch. 9.
• Un plan de réponse aux incidents écrit ainsi qu'un calendrier documenté de conservation et de suppression sont en place. Une procédure d'intégration documentée pour toute future personne disposant d'un accès à la production reste un point ouvert ; il n'en existe pas à ce jour, l'accès étant limité à une seule personne (clause 4.2).

C.9 Mesures spécifiques aux données sensibles (santé)

• Les jours de maladie sont enregistrés comme une catégorie de journée, jamais comme un diagnostic. LogSheet ne demande aucun détail médical et l'interface n'en sollicite aucun.
• Le réglage d'entreprise sur la confidentialité des absences limite la visibilité du motif de l'absence à la personne concernée et aux administrateurs autorisés (C.2).
• Les champs libres de remarques et de commentaires de validation peuvent contenir des informations de santé. Il incombe au Client, responsable du traitement, d'instruire ses administrateurs de ne pas y consigner de détail médical. L'application appuie cette instruction : une mention permanente est affichée à côté de chaque champ libre de remarque et de commentaire de validation, invitant les utilisateurs à ne pas y saisir de détail médical ou sensible.
• Les mêmes mesures de contrôle d'accès, de chiffrement, de cloisonnement et de conservation s'appliquent à ces données qu'à toutes les autres ; il n'existe pour elles aucun canal d'export distinct ni moins protégé.

Fin du document. Modèle — à faire relire par un·e avocat·e suisse spécialisé·e en protection des données avant toute utilisation.