Politique de confidentialité

S’applique au site et à l’application, tous deux à l’adresse snapfork.app. Mis à jour le 24 septembre 2026.

Ce que conserve le serveur

Uniquement ce sans quoi la connexion, la synchronisation et la correspondance avec le développeur ne peuvent pas fonctionner :

Où se trouve le serveur. Le serveur, la base de données et ses sauvegardes tournent chez l’hébergeur Railway (États-Unis), dans sa région de Singapour. Les données des personnes de l’Union européenne et du Royaume-Uni sont donc stockées hors de ces territoires.

Ce qu’il advient de votre journal

Votre journal vit à la fois sur votre appareil et sur le serveur — mais sur le serveur, il est chiffré. Les entrées, les aperçus de photos et les relevés de poids vivent dans le stockage de votre navigateur, et une copie scellée part vers le serveur : sa clé n’existe que sur votre appareil. Le serveur peut voir que des entrées ont été ajoutées et quand — mais pas ce que vous avez mangé, en quelle quantité, ni combien vous pesez.

Nous ne pouvons pas non plus lire votre journal. Ce n’est pas une promesse de bonne conduite ; c’est ainsi que le système est construit — nous n’avons pas la clé. D’où un prix qu’il faut connaître d’avance : perdez votre code de récupération en même temps que votre appareil, et personne ne pourra rendre le journal, nous compris. Il n’y aurait rien à partir de quoi le restaurer. Le code est affiché dans les Réglages, sous « Données » — notez-le et gardez-le ailleurs que sur votre téléphone.

Le serveur garde aussi les versions en conflit — et c’est à votre avantage. Si une même entrée a été modifiée sur deux appareils, la modification la plus récente l’emporte, et celle qui a perdu n’est pas jetée : elle reste un mois sur le serveur, scellée de la même façon, et l’application peut vous la montrer. Sinon, « ça s’est arrangé tout seul » serait notre parole contre votre mémoire. Nous ne pouvons pas la lire non plus, bien sûr — elle est dans la même enveloppe que tout le reste.

Les réglages ne partent vers le serveur que si vous activez leur synchronisation. Les objectifs, le profil (prénom, sexe, année de naissance, taille, niveau d’activité, but, rythme, poids cible, ce qu’il faut prendre en compte et ce que vous ne mangez pas), l’objectif d’eau, la répartition entre les repas, les fonctions du journal, les réglages de nutrition, l’historique des ajustements de la norme, les actions rapides, les unités, le thème de la carte de partage et deux interrupteurs — la note des produits masquée et la recherche désactivée dans la base ouverte — voyagent dans une seule enveloppe, scellée avec la même clé que le journal. Une partie de ces éléments, nous la nommons séparément, car elle peut laisser deviner votre foi ou votre santé : l’ensemble prêt à l’emploi et les objectifs de nutrition (par exemple « Végétal » ou « Sans alcool »), la liste de ce que vous ne mangez pas et vos propres mots dans les réglages de nutrition — mots exclus et exceptions — voyagent dans la même enveloppe, scellés de la même façon. La synchronisation s’active par un interrupteur à part dans la section « Données » ; tant que vous ne l’avez pas fait, les réglages ne sont envoyés nulle part. Vous la désactivez au même endroit — la copie du serveur est effacée aussitôt, et la synchronisation est désactivée sur tous vos appareils. Le serveur voit que l’enveloppe existe, quand elle a changé, quelle est sa taille et quand la synchronisation a été désactivée — mais pas ce qu’elle contient. Le thème de l’application, la langue, les rappels, la connexion à Apple Santé et votre propre clé de fournisseur de reconnaissance ne quittent jamais l’appareil : ils appartiennent à l’appareil, pas à vous.

Votre pays de résidence, si vous l’avez choisi, est stocké sur cet appareil. Il figure dans le fichier de sauvegarde à côté de la langue et s’efface avec vos autres réglages personnels quand quelqu’un d’autre reprend l’appareil. Il ne fait pas partie de l’enveloppe de synchronisation des réglages, et nous ne le déduisons ni de l’adresse IP ni de la langue de l’interface. Le code du pays part vers notre serveur comme champ de requête seulement avec une demande de reconnaissance par la clé Snapfork et seulement quand l’interrupteur « Tenir compte de mon pays » est activé — en transit, il n’y reste pas (voir « Où vont les données »). La ligne « Suggéré par l’appareil » du choix du pays est calculée sur l’appareil lui-même — à partir de la région du système, du fuseau horaire ou de la région indiquée dans les réglages de langue du navigateur — et ne choisit rien d’elle-même.

Le fichier de sauvegarde, lui, c’est toujours vous qui l’exportez et le conservez. Il n’est pas chiffré, et c’est le seul moyen de lire votre journal sans le code.

Nous ne demandons pas aux services de connexion votre prénom, votre nom de famille ni votre photo de profil — seulement la confirmation de l’adresse e-mail. Un nom que vous saisissez vous-même dans votre profil n’arrive sur le serveur qu’à l’intérieur de l’enveloppe scellée des réglages, et seulement si la synchronisation des réglages est activée ; nous ne pouvons pas le lire.

La sauvegarde propre à votre appareil

Il s’agit ici de l’application pour iPhone. Elle n’est pas encore sur l’App Store, et ce qui suit décrit son comportement une fois publiée. Le site n’a rien de tel : dans un navigateur, il n’y a ni conteneur d’application ni sauvegarde de ce genre.

Une sauvegarde iPhone emporte les données des applications vers iCloud — c’est ainsi que fonctionne la sauvegarde, ce n’est pas le fait de notre application. Que votre journal y figure ou non, c’est vous qui le décidez, et par défaut il n’y figure pas. La question vous est posée au premier lancement, et vous pouvez changer de réponse à tout moment : Réglages → « Données » → « Journal dans la sauvegarde iCloud ».

Ce qui est décrit ici, c’est le mécanisme, pas le résultat, et ce n’est pas une dérobade : une fois que vous avez répondu, la phrase « mon journal est dans iCloud » est vraie pour certains lecteurs et fausse pour d’autres. Répondez oui, et la sauvegarde est faite et conservée par Apple selon les règles d’Apple — c’est sa copie, pas la nôtre : nous ne la voyons pas et ne pouvons pas l’ouvrir. Répondez non, ou ne répondez rien du tout, et le dossier de l’application est marqué comme exclu de la sauvegarde : le journal n’y part donc pas.

Rien de tout cela ne concerne le fichier de sauvegarde que vous exportez vous-même : celui-là, vous le créez et le gardez où vous voulez. Ce qui y entre de la part de vos amis est décrit sous Amis.

Réponses de santé

L’application a une section « Prévention » — un ouvrage de référence sur les recommandations publiées en matière d’examens de prévention, choisies selon l’âge, le sexe et vos réponses. Ces réponses sont des données de santé, et nous les traitons plus strictement que le journal. La section ne s’ouvre qu’après un consentement distinct sur son écran d’accueil ; tant que vous ne l’avez pas donné, elle n’enregistre rien.

Ce qui est conservé. Où vous êtes soigné (le pays) ; si vous fumez, avez arrêté ou n’avez jamais fumé — avec les paquets-années et l’année d’arrêt ; si vous prévoyez une grossesse ; quels points liés aux organes vous concernent ; les marques « fait » avec le mois et le type de test ; les points reportés ; l’interrupteur « Rien sur la perte de poids » et la date de votre consentement. Dans votre profil, la section lit l’année de naissance, le sexe, l’objectif et la liste « Ce que vous ne mangez pas » — mais pas votre poids. Elle ne demande ni ne conserve de diagnostics, d’antécédents familiaux ou de résultats d’analyses.

Où. Sur votre appareil, dans le stockage de l’application. Dans l’application pour iPhone, les réponses sont scellées par une clé qui n’existe que sur ce téléphone et n’entre dans aucune sauvegarde : une sauvegarde iCloud ne les reçoit que scellées, et rien ne permet de les ouvrir sur un autre téléphone — là, la section repart de zéro. Dans un navigateur, les réponses restent dans son stockage, comme le journal.

Vers le serveur — seulement scellées, et seulement si vous le décidez. Les réponses de santé partent vers le serveur seulement si vous activez leur synchronisation entre appareils, et alors scellées par une clé qui n’existe que sur vos appareils, comme le journal et les réglages. Cette synchronisation a son propre interrupteur et son propre consentement ; elle est désactivée par défaut et ne fonctionne qu’à l’intérieur de la synchronisation des réglages — mais activer celle-ci ne l’active pas. Si vous avez indiqué être soigné en Russie, les réponses ne vont pas au serveur, même synchronisation activée.

Où elles ne vont jamais. Ni au modèle de langage, ni aux amis, ni dans les informations sur l’appareil jointes à un message au support. Elles ne sont pas mises par défaut dans le fichier de sauvegarde (le bouton « Exporter en JSON ») : une case à cocher séparée les ajoute — et rappelez-vous alors que ce fichier n’est pas chiffré.

Masquer, désactiver la synchronisation, effacer — trois actions différentes. « Masquer la section » la retire de la vue sans toucher aux réponses. « Désactiver et effacer les réponses du serveur » efface la copie du serveur, et vos autres appareils effacent la leur à leur prochaine synchronisation ; les réponses restent sur cet appareil. « Effacer les réponses sur cet appareil » les efface ici et, synchronisation activée, à la prochaine synchronisation aussi sur le serveur et sur vos autres appareils ; le consentement est retiré avec elles, et la section recommence par son écran d’accueil. La suppression du compte emporte la copie du serveur avec tout le reste ; la durée de vie des sauvegardes de la base est indiquée sous Durées de conservation.

Où vont les données

Les photos de repas, d’emballages ou d’étiquettes sont envoyées pour être reconnues, et leur trajet dépend de la clé qui signe la requête. Il y a deux voies, et le choix vous appartient :

L’application démarre avec votre propre clé et ne passe à la nôtre qu’après l’échec de la vôtre — ou passe directement à la nôtre si le modèle que vous avez choisi ne regarde pas les photos. C’est le comportement par défaut, et une case à cocher dans les réglages le désactive — la photo ne passe alors jamais par notre serveur, en aucune circonstance.

Les aliments décrits en mots, et le recalcul à partir d’une description. Lorsque vous décrivez un repas par écrit, le texte que vous avez saisi est envoyé à la reconnaissance par les deux mêmes voies qu’une photo, afin que le modèle puisse estimer les calories, les protéines, les lipides et les glucides. Lorsque vous demandez à l’application de recalculer les valeurs d’un élément à partir de sa description, la description de l’élément — ce qu’indique son champ de nom — est envoyée au modèle de la même façon. La description d’un repas transporte aussi son poids total, si vous l’avez indiqué, ainsi que les noms des produits de votre bibliothèque avec la quantité que vous en prenez habituellement (la portion en grammes), qui aident le modèle à reconnaître ce qu’il connaît déjà et à juger du poids ; ces mêmes noms de la bibliothèque, avec leurs portions en grammes, partent aussi avec la photo d’un plat. La description d’un repas, comme une photo, transporte également la langue de l’interface, pour que le modèle nomme les plats dans cette langue. Le texte n’est pas stocké chez nous, pas plus que la photo : seule reste la ligne de chiffres.

Votre pays de résidence, si vous l’avez choisi. Une photo, une étiquette ou une description de repas transporte aussi, avec la langue de l’interface, le code à deux lettres de votre pays, pour que le modèle reconnaisse les plats locaux et la taille des portions. Avec la clé Snapfork, le code du pays passe par notre serveur vers la plateforme de reconnaissance ; avec votre propre clé, il part directement à la plateforme, sans passer par nous. Notre serveur se contente de le transmettre : comme pour une photo, le journal des appels garde seulement le modèle, les jetons et le coût. Le recalcul d’un élément et le classement des produits par groupes ne reçoivent jamais le pays, et votre liste « Je ne mange pas » ne part jamais vers le modèle. Cela se désactive avec l’interrupteur « Tenir compte de mon pays » dans la section « Reconnaissance des aliments ».

Votre recherche de produit — si vous avez appuyé sur « Chercher dans la base ouverte ». L’application a une porte Produits : elle cherche parmi vos propres produits et dans le catalogue téléchargé sur votre appareil, et tout cela se passe sans aucun réseau. Quand le catalogue ne contient pas ce que vous cherchez, un bouton « Chercher dans la base ouverte » apparaît sous la liste. À cet appui — et seulement à celui-là — ce que vous avez tapé dans le champ de recherche quitte votre appareil pour Open Food Facts, sans passer par notre serveur : nous ne voyons pas cette chaîne et ne la stockons pas. Il n’y a ni saisie semi-automatique pendant la frappe ni requête en arrière-plan : sans l’appui, rien ne part.

Rien d’autre ne voyage avec cette chaîne : ni entrées du journal, ni photos, ni poids, ni identifiant de compte — la requête n’en a pas besoin, et l’application n’en joint aucun. À partir de là, ce sont les conditions d’Open Food Facts qui s’appliquent, pas les nôtres. Une case à cocher la désactive : Réglages → Produits par code-barres → « Chercher dans la base ouverte sur appui » ; décochée, elle retire le bouton lui-même, et plus rien ne part du tout. La recherche d’un produit par le code de son emballage, comme la recherche dans le catalogue téléchargé, ne passent jamais par le réseau — ni case cochée, ni case décochée.

L’application télécharge la base de produits depuis notre serveur sous forme de fichier d’un pays, et l’adresse du fichier nomme ce pays (par exemple /products/de.2026-09-24.csv). Le pays de la base téléchargée est donc visible, avec votre adresse IP, par notre serveur, par le réseau Cloudflare où passent toutes les requêtes vers snapfork.app, et dans les journaux de notre hébergeur Railway, qui conserve ces entrées de 7 à 30 jours. La requête part sans le cookie de connexion : nous n’avons rien pour relier le téléchargement à un compte. La base ne se télécharge que par le bouton des Réglages ; la recherche dedans se fait ensuite sans réseau.

Les e-mails contenant le code de connexion passent par le prestataire de messagerie choisi par le propriétaire du service. En dehors de ce qui est énuméré ici, rien n’est transmis à qui que ce soit : il n’y a ni statistiques d’audience, ni publicité, ni script tiers sur le site ou dans l’application.

Dans le message lui-même, le prestataire ajoute un compteur d’ouverture — une petite image chargée depuis son serveur à l’ouverture du message. Il apprend ainsi que le message a été ouvert et quand ; les clients de messagerie qui chargent les images directement lui montrent aussi l’adresse depuis laquelle le message a été lu. Cela ne peut pas être désactivé avec notre formule. Le message tel que nous le rédigeons ne contient aucune image ni aucun lien.

Le compteur de visites

Le site compte lui-même les visites, sans cookies et sans scripts de tiers. Ce qui arrive dans la base de données, ce sont des chiffres journaliers : page, langue, provenance de la visite. Ni l’adresse IP ni le User-Agent ne sont stockés, sous aucune forme — ils sont transformés en clé avec un sel journalier, et le sel lui-même n’est écrit nulle part, si bien que même nous ne pouvons pas rapprocher deux jours l’un de l’autre. L’en-tête Sec-GPC est respecté : en sa présence, rien n’est compté du tout.

Correspondance avec le développeur

Les réglages de l’application contiennent une section « Assistance » : vous pouvez y signaler quelque chose qui ne marche pas ou qui manque, et recevoir une réponse au même endroit. C’est une conversation plutôt qu’un formulaire — ce qui veut dire qu’elle est stockée sur le serveur : sinon, il n’y aurait nulle part où répondre.

Ce qui est stocké, c’est le texte de vos messages et les réponses du développeur, rattachés à votre compte. Ils ne sont lus que par les personnes dont le propriétaire du service a inscrit les adresses confirmées sur la liste des développeurs : cette liste est fermée, elle se trouve dans la configuration du serveur, et personne d’autre ne voit la correspondance. Ni adresse e-mail ni nom ne figurent à côté — de toute façon, le serveur ne les détient pas en clair, et la conversation se tient avec un journal, pas avec une personne.

Les informations sur l’appareil ne sont jointes que si vous cochez la case, et avant l’envoi, on vous montre exactement le texte qui partira : la version de l’application et de la base de données, la plateforme et le navigateur, la langue, la taille de la fenêtre, l’écran depuis lequel vous écrivez et le code de la panne si c’est d’elle que vous venez, le nombre de vos entrées et de vos pesées, en simples nombres, si l’appareil était en ligne, si l’application a été ouverte depuis son icône ou dans un onglet du navigateur, si le mode débogage est activé et si une clé de plateforme est définie — « oui » ou « non », jamais la clé elle-même. Pas une seule entrée du journal, photo, relevé de poids ou champ du profil n’y part.

L’e-mail de notification qui parvient au développeur ne contient ni le texte du message ni votre identifiant : seulement « il y a un nouveau message dans la conversation ». Le contenu de la correspondance ne parvient jamais au prestataire de messagerie et n’apparaît jamais dans les logs du serveur.

Liens d’invitation

L’application peut vous donner un lien d’invitation permanent. Si quelqu’un s’inscrit par ce lien, vous recevez tous les deux des reconnaissances supplémentaires avec notre clé — rien d’autre ne change, et personne n’obtient l’accès au journal de quelqu’un d’autre.

Ce qui est stocké, c’est le fait qu’un compte est arrivé par le lien d’un autre : quel lien, quand, et si la récompense a été acquise. C’est une donnée sur un lien entre deux personnes : elle est donc réduite au minimum et n’est montrée à personne. La personne qui a invité ne voit que des nombres — combien sont venus, combien sont revenus, combien de reconnaissances ont été reçues. Ni nom, ni adresse, ni moment de connexion. Nous ne disons pas qui a accepté, car ce serait apprendre à un tiers qu’une personne précise a commencé à tenir un journal alimentaire.

Le lien lui-même porte un code et rien sur vous. Son ouverture est comptée par le compteur de visites comme une campagne à part — l’étiquette seulement : le code n’arrive jamais au compteur, sinon les chiffres journaliers deviendraient un tableau indiquant de qui les liens fonctionnent.

La suppression d’un compte supprime le lien et la trace de la provenance de ce compte ; les écritures de récompense restent, dépouillées de l’identifiant du compte, car c’est à partir d’elles que se calculent les limites de ce qui peut être distribué.

Les écritures de recharge se comportent de la même façon : la suppression d’un compte les laisse en place, mais elles cessent de désigner qui que ce soit. La raison n’est pas la comptabilité, mais vous : une banque peut contester un paiement un mois après la disparition du compte, et sans montants conservés, il n’y aurait rien pour répondre à une telle contestation. Le solde restant est perdu à la suppression, et cela est inscrit comme une écriture à part : l’argent pour lequel aucun service n’a été rendu reste visible exactement comme tel, au lieu de se fondre dans le chiffre d’affaires.

Amis

Si vous invitez un ami et qu’il accepte, quelque chose de dérivé de votre journal commence à quitter votre appareil — et ce sont exactement deux faits par jour pour les sept derniers jours : si vous avez noté quoi que ce soit et, si vous l’avez partagé séparément, si vous êtes resté dans votre propre objectif. Plus le nombre de jours d’affilée où vous avez noté. Ni ce que vous avez mangé, ni combien de calories, ni votre poids — rien de cela ne part, à aucun niveau de partage.

Le partage est le même dans les deux sens et à chaque niveau : vous voyez la semaine d’un ami seulement si vous avez partagé votre semaine avec lui, et son fait d’objectif seulement si vous avez aussi partagé votre objectif ; votre ami voit exactement autant de choses sur vous que vous sur lui : votre appareil n’affiche la semaine d’un ami qu’avec un consentement mutuel. Votre fait d’objectif part vers votre ami dans une enveloppe chiffrée dès que vous avez partagé votre objectif avec lui, mais il ne lui est montré que s’il a lui aussi partagé son objectif avec vous. Le consentement est demandé pour chaque amitié et pour chaque niveau, et nous enregistrons le texte auquel vous avez consenti : si le sens de ce texte change, nous redemandons au lieu de l’étendre en silence. Vous pouvez revenir dessus n’importe quel jour, et il y a deux boutons : « Arrêter le partage » garde l’amitié, « Supprimer l’amitié » supprime le lien et efface ce que chacun de vous a vu de l’autre.

Il y a une exception — le fichier de sauvegarde que vous exportez vous-même : il n’est pas chiffré, et il contient la semaine de votre ami — exactement ce que vous avez vu de lui. Les réponses n’y figurent pas. Supprimer une amitié efface ce qui a été vu, ici comme sur l’appareil, mais n’atteint pas les fichiers que vous avez déjà enregistrés : leur sort dépend de vous.

Il existe un troisième bouton, pour les cas où mettre fin ne suffit pas : le refus. Après cela, une nouvelle invitation de cette personne n’aboutira pas — sinon « Supprimer l’amitié » voudrait seulement dire « jusqu’à la prochaine invitation ». Pour cela, le serveur tient une liste des personnes que vous avez refusées : des identifiants et une date, sans motif et sans un mot de votre part ; elle dure jusqu’à ce que vous reveniez dessus. Nous ne prévenons pas l’autre partie — une personne refusée voit exactement ce qu’elle verrait après une fin ordinaire : il n’y a pas d’amitié. Cette liste est volontairement exclue de l’export « Ce que le serveur détient sur vous » : c’est un fichier que vous pouvez transmettre à quelqu’un.

Nous ne pouvons rien lire de tout cela — à condition que la clé soit authentique. Le contenu voyage scellé avec une clé que nous n’avons pas, chaque enveloppe a la même longueur, et même la taille ne trahit rien du nombre de jours qu’elle contient. Mais certaines choses, nous les voyons, et nous le disons franchement :

Ce que nous ne voyons pas : ce qu’il y a dedans, en quelle quantité, le nom que vous avez donné à votre ami sur votre propre appareil, et qui a regardé la semaine de qui.

Cette réserve sur la clé n’est pas une façon de parler. Les clés que vous échangez transitent par notre serveur — ce qui veut dire qu’en théorie, nous pourrions les substituer. Vous pouvez le vérifier : huit chiffres calculés à partir des deux clés publiques doivent coïncider chez vous et chez votre ami. Nous proposons cette vérification sans l’exiger — et tant que vous ne l’avez pas faite, vous faites confiance au serveur pour avoir transmis la vraie clé. L’écran de l’amitié indique toujours si elle a été vérifiée.

La clé qui scelle votre semaine est gardée sur votre appareil et ne voyage jamais — ni vers nous, ni dans votre sauvegarde. Sur un nouvel appareil, les amitiés doivent donc être confirmées à nouveau.

Les durées : une invitation non acceptée vit 30 jours et ne fonctionne qu’une fois ; votre semaine reste sur le serveur jusqu’à la suivante et est effacée aussitôt qu’une amitié prend fin ; les notes vivent sept jours ; le lien dure jusqu’à ce qu’on y mette fin ou que le compte soit supprimé. Les fonctions sociales ne sont proposées à personne dont le profil indique moins de 16 ans.

Vous pouvez avoir 50 amis au maximum, et ce plafond est le nôtre plutôt que celui du produit : plus la liste est longue, plus le serveur connaît de liens. Les invitations sont plafonnées pour la même raison — cinq actives à la fois, dix par jour.

Cookies

Un seul sur tout le domaine : celui de la session de connexion. Il est technique, n’est déposé qu’à la connexion, vit jusqu’à 180 jours après la dernière connexion et n’est visible que par l’application. Avant la connexion, il n’existe pas — et ensuite, il accompagne chaque page ici, celle-ci comprise, car le site et l’application répondent à une même adresse. Il n’y a pas de bandeau, car le consentement n’est pas demandé pour le cookie sans lequel la connexion ne peut pas fonctionner, et il n’y a rien d’autre à demander : ni statistiques d’audience, ni publicité.

Base légale

Chaque finalité a sa propre base légale au titre du RGPD (articles 6 et 9) :

Vous pouvez aussi saisir l’autorité de contrôle de la protection des données de votre pays.

Durées de conservation

Session — jusqu’à 180 jours après la dernière connexion. Code par e-mail — 10 minutes. Chiffres journaliers du compteur — sans limite de durée, mais ils ne contiennent rien sur une personne. Compte — jusqu’à ce que vous le supprimiez. Correspondance avec le développeur — exactement aussi longtemps que le compte : elle part avec lui et n’a pas de durée propre. Nous avons délibérément choisi de ne pas fixer de durée propre : ce serait une promesse d’effacer selon un calendrier, et il n’y a pas de calendrier — la promesse serait donc fausse dès la première vérification.

Les entrées du journal sur le serveur — tant que le compte existe. Elles n’ont pas de durée propre, et c’est une décision, pas un oubli. Le serveur garde une copie scellée du journal pour votre deuxième appareil — et une copie qui disparaît d’elle-même ne sert à rien à un deuxième appareil : il n’aurait nulle part où récupérer ce que le serveur a oublié, et le journal y serait, sans bruit, plus court que sur l’autre. Les entrées partent avec le compte, et seulement avec lui : supprimez-le, et la copie scellée du journal quitte aussitôt la base de données du serveur, puis ses copies de sauvegarde au fil de leur rotation — dans quel délai, c’est dit à la fin de cette section. Le journal sur l’appareil lui-même reste le vôtre et s’efface séparément.

Les trente jours mentionnés plus bas ne concernent pas les entrées elles-mêmes, et il ne faut pas confondre les deux durées. Trente jours, c’est la durée de vie des aperçus de photos (sur l’appareil comme sur le serveur) et des versions d’entrées qui ont perdu un conflit de synchronisation. Les uns comme les autres se trouvent À CÔTÉ d’une entrée et non à sa place : ce qui part, c’est une image ou une version précédente de la ligne, tandis que l’entrée elle-même reste où elle est. Les deux durées se comptent dans la base de données de travail du serveur ; dans ses copies de sauvegarde, une image ou une version peut leur survivre jusqu’à 14 jours — voir le dernier paragraphe de cette section.

Aperçus des photos de repas — 30 jours. L’application garde une petite copie de l’image à côté de l’entrée et la supprime de l’appareil trente jours après la prise de vue. L’entrée elle-même reste : seule l’image part. Cette durée, nous la nommons justement parce qu’ici un calendrier existe — le nettoyage s’exécute à chaque ouverture de l’application et immédiatement après la restauration d’une sauvegarde — et vous pouvez le vérifier en ouvrant un jour ancien. La photo en taille réelle n’entre jamais dans le journal : l’entrée ne contient que cet aperçu.

Une photo mise de côté pour plus tard — sur l’appareil, 30 jours au plus. Une photo que vous mettez de côté pour la faire reconnaître plus tard reste sur l’appareil en entier, pas sous forme d’aperçu : jusqu’à ce qu’elle ait été reconnue et que vous ayez enregistré l’entrée, et pas plus de trente jours après la prise de vue. À l’expiration de ce délai, la photo est supprimée, tandis que le rappel du repas reste, pour que vous puissiez le noter à la main. Elle ne quitte l’appareil qu’au moment de la reconnaissance — par la même voie que n’importe quelle autre photo (voir Où vont les données) — et elle ne reste pas sur notre serveur, pas plus qu’une autre photo. Elle n’entre jamais dans la copie scellée du journal sur le serveur.

Sur le serveur, l’aperçu vit selon la même durée — trente jours au plus. Il y arrive scellé, avec le journal, pour pouvoir apparaître sur votre deuxième appareil ; nous ne pouvons pas l’ouvrir, pas plus que les entrées. Le serveur compte la durée à partir du jour où l’image est arrivée, et non du jour de la prise de vue : ce jour-là, il ne le connaît pas — il se trouve dans le texte chiffré. L’aperçu part donc d’abord de l’appareil, puis du serveur, et le nettoyage s’exécute selon un calendrier, une fois par jour, et non « un jour ou l’autre ».

Versions d’entrées ayant perdu un conflit de synchronisation — trente jours au plus. Quand vous modifiez une entrée, vous remplacez sa version précédente ; le serveur ne jette pas aussitôt cette version précédente mais la met de côté — pour que « ça s’est arrangé tout seul » ne soit pas notre parole contre votre mémoire. Vous pouvez les voir et les rétablir dans l’application, dans la carte des versions en conflit. Elles y sont scellées, comme les entrées : nous ne pouvons pas les ouvrir non plus. Le nettoyage s’exécute selon un calendrier, une fois par jour — et c’est pourquoi nous nommons la durée ici.

Une telle version peut partir avant la fin de la durée, et il est plus honnête de le dire franchement : le serveur en garde au plus vingt par entrée, et la vingt et unième évince la plus ancienne. C’est une limite technique contre un code qui s’emballe, pas une promesse d’en garder vingt. La version actuelle d’une entrée n’est touchée ni par la durée ni par la limite : c’est votre journal, et elle ne part qu’avec le compte.

Sauvegardes du serveur — jusqu’à 14 jours. Une fois par heure, le serveur copie toute sa base de données — une assurance pour le jour où un disque défaillant ou une mise à jour ratée emporterait sinon les comptes de tout le monde. Les copies des dernières 48 heures sont gardées à raison d’une par heure, les plus anciennes à raison d’une par jour, et une copie de plus de 14 jours est supprimée à la rotation horaire suivante. Les copies ne sont supprimées que par un serveur en marche : tant qu’il est éteint, toutes les copies restent, et dès qu’il redémarre, celles qui ont expiré partent aussitôt. Une réserve : la copie la plus récente reste toujours — même expirée, si les nouvelles copies ont cessé de réussir — jusqu’à la prochaine copie réussie, car une vieille copie est plus utile qu’une étagère vide. Une copie contient exactement ce que contenait la base à cette heure-là, et sous la même forme. Ce qui est scellé avec votre clé — le journal, les aperçus, les réglages, les versions en conflit — reste scellé dans la copie, et nous n’en avons pas la clé ; ce que le serveur voit en clair — la correspondance avec le développeur, qui est ami avec qui — il le voit aussi dans la copie. C’est pourquoi chaque durée ci-dessus est une durée dans la base de données de travail : ce qui y a été effacé — par le nettoyage ou avec le compte — ne reste pas plus de 14 jours après cela dans les copies de sauvegarde, sauf dans les cas décrits ci-dessus. Quatorze jours, c’est une limite supérieure, pas une promesse de conservation : une copie peut partir plus tôt, par exemple quand le disque manque d’espace.

Une copie hors de l’hébergeur — jusqu’à 35 jours, pas encore activée. La base et ses copies sont chez un seul hébergeur, et le perdre emporterait les deux. Pour ce cas, le serveur peut envoyer une copie par jour vers un stockage séparé chez un autre fournisseur — la même copie, sous la même forme. Là-bas, seule la règle du stockage lui-même efface les copies, au bout de 35 jours, et d’ici là personne ne peut les supprimer, pas même nous — c’est ce qui les protège d’une clé volée. Ce qui a été effacé dans la base de travail y resterait jusqu’à 35 jours après cela. Aujourd’hui ce n’est pas activé : les copies n’existent que sur le serveur. Avant de l’activer, nous nommerons ici le stockage et changerons la date en haut de la page.

Suppression

Dans l’application : Réglages → « Supprimer le compte ». Cela efface le compte, tous ses moyens de connexion, toutes les sessions et toute la correspondance avec le développeur ; pour la connexion avec Apple, cela révoque aussi l’accès du côté d’Apple. Ce que le serveur gardait pour la synchronisation part aussi avec le compte : la copie scellée de votre journal, les aperçus de photos, la copie scellée de vos réglages, l’historique des versions en conflit et la liste de vos appareils — il n’en reste rien dans la base de données du serveur. Les copies de sauvegarde horaires le contiennent encore jusqu’à 14 jours, sous la même forme, puis il disparaît aussi de celles-ci (à condition que le serveur ait été en marche et que les nouvelles copies aient réussi) ; le fonctionnement des copies est décrit sous Durées de conservation. Les chiffres journaliers du compteur de visites restent : ils ne contiennent rien sur une personne, et ne peuvent pas être supprimés compte par compte, puisqu’il n’y a pas de compte dedans. Le journal sur votre appareil s’efface par un bouton séparé — il n’appartient qu’à vous, et nous ne déciderons pas de son sort à votre place.

Modifications

Cette politique évolue avec le service ; la date en haut de la page est celle de la dernière modification. Les changements importants sont annoncés ici plutôt que par e-mail : le serveur ne garde aucune adresse à laquelle il pourrait écrire — seulement son empreinte.

Contact

Le responsable du traitement — celui qui décide de ce qui est stocké ici et en répond — est une personne physique, pas une société : Snapfork n’a aucune personne morale derrière lui. Cette personne est Oleksandr Trifonov. Tout ce qui concerne le service, y compris les demandes relatives à vos propres données, s’adresse à l’adresse ci-dessous. Ce que cela signifie en pratique est expliqué sur la page Qui est derrière.

Questions, accès à vos propres données et suppression — via la page Questions ou en écrivant à hello@snapfork.app.

Conditions d’utilisation · Ouvrir l’application