Politique de confidentialité

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

• votre adresse e-mail — pas en clair, mais sous forme d’une transformation irréversible à clé secrète : on ne peut pas en retrouver l’adresse, mais on peut y comparer une adresse connue ;
• votre identifiant de compte chez Google ou Apple, si vous vous êtes connecté par ce biais — transformé de la même manière ;
• les sessions : seulement une empreinte du jeton contenu dans votre cookie, jamais le jeton lui-même, et l’heure de votre connexion ;
• les codes des e-mails de connexion — hachés, valables dix minutes ;
• des compteurs de requêtes, pour qu’un code ne puisse pas être deviné par force brute ;
• votre correspondance avec le développeur, si vous l’avez utilisée — voir la section qui lui est consacrée plus bas ;
• une connexion inachevée : une procédure commencée et non terminée reste quelques minutes sur le serveur et expire d’elle-même ;
• vos recharges, si vous avez rechargé votre solde de reconnaissances : le montant, l’heure et l’identifiant du paiement chez le prestataire qui l’a encaissé (le numéro de carte reste chez lui) ;
• la liste de vos appareils — seulement l’identifiant aléatoire qu’un appareil s’est attribué lui-même et le moment de son dernier signe de vie. Ni modèle, ni système, ni nom : la liste répond à « combien y en a-t-il et sont-ils actifs », et à rien d’autre ;
• des copies de sauvegarde de toute la base de données, faites une fois par heure et conservées jusqu’à 14 jours — pour qu’une panne n’emporte pas les comptes de tout le monde. Ce qu’elles contiennent et pour combien de temps, voir Durées de conservation.

Où se trouve le serveur. Le serveur, la base de travail et les sauvegardes locales tournent chez l’hébergeur Railway (États-Unis), dans sa région de Singapour. Les données de travail des personnes de l’Union européenne et du Royaume-Uni sont donc stockées en dehors de ces territoires. Les sauvegardes externes chiffrées sont stockées dans Cloudflare R2 sous la juridiction de l’Union européenne.

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, leurs copies agrandies 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.

L’image de profil est une photo que vous choisissez ou un animal intégré. Elle est stockée sur votre appareil et figure dans votre fichier de sauvegarde. Elle n’arrive sur le serveur que si vous activez la synchronisation de l’image : elle a son propre interrupteur dans la section « Données », distinct de celui des réglages et désactivé tant que vous ne l’activez pas. Le serveur garde alors une seule copie actuelle, dans une enveloppe à part scellée par votre code de récupération : seuls vos appareils peuvent l’ouvrir. Nous n’envoyons l’image ni au modèle ni à vos amis. L’enveloppe a la même taille, qu’elle contienne une photo ou un animal : le serveur voit seulement qu’une copie existe, son numéro de version et quand elle a changé. Désactiver la synchronisation efface l’enveloppe aussitôt ; il reste un enregistrement technique sans image — le numéro de version et l’heure de la désactivation — qui permet à vos autres appareils de savoir qu’elle est désactivée. Supprimer votre compte l’efface aussi. Les copies de sauvegarde du serveur gardent ce qui a été effacé jusqu’à 14 jours — voir Durées de conservation.

La synchronisation Health conserve aussi des métadonnées de contrôle sur le serveur : clés publiques de vérification du téléphone, droits d’exécution, cibles hachées et limites de version, états des opérations, annulations et anciens transferts. Elles ne contiennent ni valeurs Health, ni identifiants système des entrées, ni noms d’appareils, ni notes. Elles sont effacées avec le compte ; les opérations et états figurent dans l’export du serveur, les clés publiques de vérification en sont exclues.

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.

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.

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é liée à ce téléphone : une sauvegarde peut la restaurer sur le même appareil, mais pas la transférer vers un autre. Une sauvegarde iCloud ne reçoit les réponses 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.

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 :

• Avec votre propre clé, la photo part de votre appareil directement vers la plateforme dont vous avez saisi la clé, sans passer par notre serveur. Nous ne la voyons pas et ne la conservons pas. La plateforme, c’est vous qui la choisissez ; aujourd’hui, l’application envoie la photo à neuf adresses et n’en connaît aucune autre :
  • Google Gemini — generativelanguage.googleapis.com
  • OpenAI — api.openai.com
  • Grok xAI — api.x.ai
  • DeepSeek — api.deepseek.com
  • Qwen — dashscope-intl.aliyuncs.com
  • Mistral AI — api.mistral.ai
  • Llama Meta — api.llama.com
  • Poe — api.poe.com
  • OpenRouter — openrouter.ai
  La liste est intégrée à l’application et à la politique de sécurité du navigateur, si bien que la photo ne peut aller nulle part ailleurs que vers la plateforme que vous avez choisie. L’application reconnaît aussi la clé d’une dixième plateforme, Claude, mais n’y envoie rien : celle-ci n’ouvre l’accès depuis un navigateur qu’avec un en-tête spécial qu’elle qualifie elle-même de dangereux, et nous ne le définissons pas.
• À partir de là, ce sont les conditions de la plateforme qui s’appliquent, pas les nôtres, et elles ne sont pas les mêmes partout. Chez Google, par exemple, elles diffèrent même entre les formules d’une seule et même clé : en formule gratuite, Google se réserve le droit d’utiliser ce que vous envoyez pour améliorer ses produits ; en formule payante, non. Nous ne résumons pas les conditions des autres : elles changent sans nous, et c’est à la source qu’il faut les lire. La façon d’obtenir une clé est indiquée dans les réglages de l’application, à côté du champ de la clé.
• Avec la clé Snapfork, la photo passe par notre serveur, où la requête est signée, puis par OpenRouter — la plateforme qui la transmet au fournisseur du modèle. Elle n’est pas stockée chez nous : ni le fichier, ni une copie dans les logs ; il ne reste qu’une ligne de chiffres — modèle, jetons, coût ; pour une personne venue par une invitation, tant que l’invitation n’est pas validée, s’y ajoute la date locale (voir « Liens d’invitation »). À chaque requête, nous demandons à la plateforme de ne pas passer par des fournisseurs qui conservent ce qui leur est envoyé.

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 (pour une personne invitée, aussi la date locale, voir « Liens d’invitation »). 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 Open Food Facts (en ligne) ». 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 Open Food Facts (en ligne) » 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 Open Food Facts (en ligne) 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 national ou, lorsqu’il est disponible, de noyau mondial ; l’adresse nomme la base choisie (par exemple /products/de.2026-09-24.csv). Le nom de la base téléchargée et votre adresse IP sont visibles par notre serveur et par Cloudflare, qui traite les requêtes vers snapfork.app. Le chemin et l’adresse IP peuvent figurer dans les journaux de Railway. Leur durée de conservation dépend des réglages des prestataires et doit être vérifiée avant la publication. Un fichier national déjà installé peut être proposé à la mise à jour. Son pays n’est pas forcément votre pays de résidence ; le noyau mondial ne le nomme pas. La requête part sans le cookie de connexion. L’application ne rattache pas 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 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.

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.

L’application peut vous donner un lien d’invitation permanent. Qui s’inscrit par ce lien reçoit en cadeau des reconnaissances avec notre clé tant que le lien a encore des cadeaux, et vous recevez les vôtres une fois qu’il a fait reconnaître des repas avec la clé Snapfork deux jours différents (comptés selon son calendrier local), jusqu’à la limite des récompenses. Rien d’autre ne change : personne n’obtient l’accès au journal de quelqu’un d’autre.

Pour cela, l’application envoie, avec chaque reconnaissance par la clé Snapfork, la date locale de l’appareil. Elle n’est conservée que pour une personne venue par un lien, tant que l’invitation n’est pas validée et que la personne qui invite n’a pas supprimé son compte, et 30 jours au plus. Une date qui n’existe dans aucun fuseau horaire est refusée : un tel appel, comme un appel sans date, est compté selon le fuseau des autres dates de cette personne, sans elles en temps universel. Si ses dates ne concordent pas (déménagement, appareils dans des fuseaux différents, changement d’heure), tout son décompte se fait en temps universel.

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 d’entre eux ont fait reconnaître des repas avec la clé Snapfork deux jours différents, combien de reconnaissances ont été reçues et combien de cadeaux il reste au lien. 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é.

L’export « Ce que le serveur détient sur vous » contient vos liens, y compris ceux qui ont été révoqués, la trace de la façon dont vous êtes arrivé, de la date et de la récompense gagnée ou non, le nombre de personnes venues par vos liens et combien d’entre elles ont compté — en chiffres seulement —, vos écritures de récompense et le nombre de cadeaux qu’il reste à votre lien. Qui vous a invité et qui est venu par votre lien n’y sont pas nommés.

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.

Si vous êtes lié à un ami et l’avez autorisé à voir votre semaine, votre semaine quitte votre appareil — dérivée de votre journal, 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 n’entre dans la semaine, à aucun niveau de partage. En dehors de la semaine, un ami ne reçoit que ce que vous envoyez vous-même : une note choisie dans une liste fixe d’encouragements, ou une fiche produit — voir plus bas.

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 ; chez votre ami, notre application lui montre exactement autant de choses sur vous qu’elle vous en montre 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.

Une fiche produit ne part que si vous l’envoyez vous-même. Sur l’écran des amis, vous pouvez envoyer à un ami un produit de votre bibliothèque. La fiche contient son nom, les valeurs pour 100 g (calories, protéines, lipides et glucides), le code-barres s’il y en a un et l’origine des valeurs ; le sucre, les acides gras saturés, le sel et les fibres seulement s’ils viennent d’une étiquette, d’un scan de code-barres ou du catalogue. Elle ne contient ni poids, ni date, ni rien sur le moment ou la quantité que vous en avez mangé. Elle voyage scellée dans la même enveloppe qu’une note, de même longueur et par le même chemin : le serveur ne distingue donc pas une fiche d’une note. Votre ami décide quoi en faire : rien n’arrive dans son journal ni dans sa bibliothèque tant qu’il n’a pas enregistré une entrée avec elle, et une fiche non acceptée disparaît au bout de sept jours. Vous pouvez envoyer à un même ami au plus cinq fiches par jour, comptées à rebours depuis l’envoi et non depuis minuit. « Annuler l’envoi » efface l’enveloppe sur le serveur, et la fiche quitte l’écran de votre ami à son prochain échange ; s’il l’a déjà ajoutée, il la garde. Supprimer l’amitié efface les fiches entre vous sur le serveur, avec le lien.

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 et les fiches produit 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.

Le blocage. Le bouton « Bloquer » sur la fiche d’un ami rompt le lien tout de suite — comme « Supprimer l’amitié », avec les enveloppes dans les deux sens — et vous empêche tous les deux de vous réinviter : plus aucune invitation entre vous ne sera acceptée. Pour cela, le serveur garde qui a bloqué qui, et depuis quand — sans motif et sans un mot de votre part — jusqu’à ce que vous débloquiez dans la liste « Bloqués » du même écran, ou que l’un de vous supprime son compte. Nous ne prévenons pas l’autre partie : elle voit ce qu’elle verrait après « Supprimer l’amitié » — l’amitié a pris fin, et votre lien d’invitation ne fonctionne pas chez elle, comme un lien expiré. Débloquer ne rétablit pas l’amitié : elle ne reprend que si l’un de vous accepte le lien de l’autre. L’export « Ce que le serveur détient sur vous » contient vos amis tels que le serveur les conserve : votre clé publique, vos liens avec le jour où chacun a commencé, vos invitations, vos interdictions s’il y en a, et les enveloppes envoyées ou reçues — scellées : seuls votre appareil avec vos amis ou celui de l’ami peuvent les ouvrir. Un ami y figure sous un identifiant de compte, pas sous un nom ; ni sa clé, ni ses enveloppes à d’autres, ni les interdictions posées contre vous n’y sont, pas plus que les niveaux et les consentements — ils sont conservés sur l’appareil.

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 :

• qui est lié à qui, et depuis quand ;
• votre clé publique ;
• que vous avez un coffre de la clé des amis, et quand il a changé ; tant qu’une demande de réinitialisation de vos amis est en attente, la demande elle-même et la date à laquelle elle prend effet, ainsi qu’un second texte chiffré du coffre, de la même longueur fixe ;
• quand vous ouvrez l’écran des amis — c’est là que votre appareil relève sa boîte de réception et, si vous avez partagé votre semaine, l’envoie — et quand une enveloppe avec une note ou une fiche a été envoyée ou reprise, et, si vos amis sont sur plusieurs appareils sous la clé commune, aussi quand vous avez pris la fiche produit d’un ami ou l’avez refusée ;
• que des invitations existent, et combien.

Ce que nous ne voyons pas : ce qu’il y a dedans, en quelle quantité, et le nom que vous avez donné à votre ami sur votre propre appareil. Votre ami voit quand votre semaine a été mise à jour pour la dernière fois — c’est la dernière fois que vous avez ouvert l’écran des amis.

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 : trente-deux 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.

Si vous synchronisez votre journal, la clé privée des amis voyage entre vos appareils par le même chemin que le journal : dans le coffre de la clé des amis, scellé avec la clé de votre journal, que nous n’avons pas. Vos autorisations, vos vérifications et les noms donnés à vos amis y sont aussi. Vos amis sont donc disponibles sur chaque appareil où le code de clé du journal est saisi, la révocation d’une autorisation sur l’un vaut pour tous, et la vérification est commune : il n’est pas nécessaire de comparer les chiffres une seconde fois. Une vérification porte sur toute la clé de votre ami, et si la clé d’un ami déjà vérifié change, votre semaine ne lui est plus envoyée tant que vous n’avez pas comparé les chiffres à nouveau. Tant que vos amis ne sont pas sur la clé commune, l’écran des amis propose d’y passer : sans amis ni invitation en attente, c’est possible à tout moment, mais dès que vous avez des amis ou une invitation en attente, le passage — comme le transfert de vos amis ici — change une clé sur laquelle d’autres comptent déjà et n’est donc possible que juste après une connexion. En émettant un nouveau code, vous pouvez aussi changer la clé des amis et, dans les réglages du compte, vous déconnecter des autres appareils (là aussi, seulement juste après une connexion) : c’est ainsi qu’on coupe un appareil perdu. L’ordre est le suivant : synchronisez vos autres appareils, émettez un nouveau code, puis déconnectez-vous des autres appareils. Le nouveau code ferme à l’appareil perdu les nouvelles entrées du journal sur le serveur, le changement de clé des amis lui ferme les nouvelles semaines de vos amis, et la déconnexion lui coupe l’accès au serveur ; ce qui se trouve déjà sur l’appareil perdu y reste. Vos amis verront alors une nouvelle clé et pourront comparer les chiffres à nouveau. Quand la clé des amis change, le serveur efface aussi ce qui vous attendait sous l’ancienne clé — semaines de vos amis, notes et fiches produit : la nouvelle clé ne peut pas les ouvrir, et vos amis en déposeront de nouvelles. Si le code est perdu, vous pouvez réinitialiser vos amis avec le bouton « Réinitialiser les amis » — juste après une connexion (avec le code reçu par e-mail ou avec Google ou Apple). Il faut pour cela un appareil avec le code de clé du journal ; s’il n’en a pas non plus, créez d’abord un nouveau code — c’est une nouvelle clé du journal. La réinitialisation prend effet au bout d’un jour, sauf si, entre-temps, l’app s’ouvre en ligne sur un appareil avec votre code : un tel appareil retire la demande de lui-même, même sans que vous ouvriez l’écran des amis — c’est donc que vous avez encore le code. Après la réinitialisation, la clé change, les vérifications sont effacées, et il faudra autoriser à nouveau le partage de votre semaine. La moitié privée de la clé des amis n’entre jamais dans votre fichier de sauvegarde ; sur l’appareil lui-même, elle se trouve dans l’instantané du coffre, dans la même base de l’appareil que la clé du journal, et une sauvegarde de l’appareil dans laquelle vous avez laissé entrer votre journal l’emporte avec la clé du journal.

Sans synchronisation du journal ou sans clé commune des amis, la clé qui scelle votre semaine est gardée sur votre appareil et ne voyage jamais — ni vers nous, ni dans votre fichier de sauvegarde. Sur un nouvel appareil, les amitiés doivent donc être confirmées à nouveau. Vos amis vivent sur un seul appareil, et le serveur ne change votre clé que tant que vous n’avez encore ni amis ni invitation en attente, ou lors d’un transfert (seulement juste après une connexion) — par une sauvegarde sur un nouvel appareil encore vide ou avec « Transférer ici » : ils s’arrêtent sur l’ancien (« Ramener ici »), et le partage de votre semaine doit être autorisé à 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 ou que vous passez à un nouvel appareil — dès qu’un nouvel appareil encore vide restaure votre sauvegarde ou que vous confirmez le transfert sur l’écran des amis — et, avec la clé commune des amis, aussi lorsque vous y passez, lorsque la clé des amis change avec un nouveau code et lorsqu’une réinitialisation prend effet ; les notes vivent sept jours ; le coffre de la clé des amis reste jusqu’à la suppression du compte ; 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.

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é.

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

• Exécution du contrat (art. 6(1)(b)) — ce sans quoi le service que vous demandez ne fonctionne pas : compte, connexion et e-mails de code, copie scellée de votre journal, reconnaissance avec la clé Snapfork avec la langue et le pays, téléchargement de la base de produits, correspondance avec le développeur, liens d’invitation et mécanique de l’amitié : le lien, les clés, le coffre de la clé des amis, la remise des enveloppes, les interdictions de nouvelle invitation, ainsi que les notes et les fiches produit — vous les envoyez vous-même, et elles ne demandent aucun consentement au partage de votre semaine.
• Consentement (art. 6(1)(a)) — synchronisation des réglages : elle s’active séparément et se retire à tout moment avec le même interrupteur.
• Consentement explicite (art. 9(2)(a)) — réponses de santé et leur synchronisation, retrait avec les boutons de la section, et votre semaine pour un ami : chaque amitié et chaque niveau de partage demandent leur propre consentement, retrait avec le bouton « Arrêter le partage ».
• Intérêt légitime (art. 6(1)(f)) — sauvegardes de la base, journaux de l’hébergeur, compteur de visites et enregistrements anonymisés des recharges gardés pour les litiges de paiement. Vous pouvez vous y opposer en écrivant à l’adresse ci-dessous (art. 21).

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

Le journal des appels au modèle est conservé sur le serveur tant que le compte existe.

L’export du serveur comprend aussi votre journal des appels au modèle : jour, heure, type de requête, modèle, source de paiement, statut, jetons et coût en dollars américains, ainsi que la date locale d’une personne invitée tant qu’elle est conservée. Le journal ne contient ni photos, ni texte des requêtes, ni réponses du modèle ; l’empreinte de l’adresse IP est exclue du fichier.

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.

La date locale d’une personne invitée — 30 jours au plus, moins si l’invitation est validée ou si la personne qui invite supprime son compte (voir « Liens d’invitation »).

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) , des copies agrandies sur le serveur et des versions d’entrées qui ont perdu un conflit de synchronisation. Ces trois types de données 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 durées sur le serveur 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. Le fichier original de l’appareil photo n’est pas conservé dans le journal. Avec cet aperçu, l’entrée garde sur l’appareil une copie agrandie et compressée pour la même durée. Le fichier de sauvegarde que vous exportez contient cette copie sans chiffrement.

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). La photo entière envoyée pour la reconnaissance n’est pas conservée sur notre serveur. Si vous enregistrez une entrée, son aperçu et sa copie agrandie compressée sont conservés séparément, scellés avec votre clé, comme expliqué ci-dessous.

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 ».

Copies agrandies des photos de repas — au plus 30 jours sur le serveur. Si une entrée en contient une, l’application l’envoie séparément de l’aperçu, chiffrée avec votre clé. Le serveur conserve seulement le texte chiffré ; l’adresse de la photo se trouve dans l’entrée chiffrée. Un autre appareil télécharge la copie quand vous ouvrez la photo. Le serveur la supprime lors du nettoyage quotidien, à compter de son arrivée, et dès la suppression du compte. L’export du compte contient cette même copie chiffrée.

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, l’image de profil, les versions en conflit, le coffre de la clé des amis — 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.

Sauvegarde externe — expiration prévue après 35 jours. Une fois par jour, le serveur envoie une sauvegarde de la base à Cloudflare R2 sous la juridiction de l’Union européenne. L’archive entière est chiffrée avant l’envoi avec une clé distincte pour les sauvegardes. Le délai d’expiration prévu est de 35 jours. Après expiration, R2 supprime les objets de manière asynchrone : leur conservation réelle peut donc durer plus longtemps. Les données effacées de la base de travail restent dans les copies externes jusqu’à la suppression effective de ces copies.

Au 9 octobre 2026, le stockage externe contient aussi une sauvegarde du 2 octobre 2026, créée avant l’activation du chiffrement de l’archive entière. Cette ancienne copie est soumise à la même règle d’expiration prévue.

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’image de profil scellée, 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. Il en va de même pour vos liens d’amitié, votre clé publique, le coffre de la clé des amis, les enveloppes entre vous et vos amis, vos invitations et les interdictions de nouvelle invitation. 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.

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.

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.