Où vit vraiment votre journal alimentaire
Sur votre téléphone. Pas comme un slogan — comme l’endroit où les entrées sont physiquement écrites. Une copie part aussi vers le serveur, scellée, et rien là-bas ne peut l’ouvrir : la clé reste chez vous.
Ce qui quitte l’appareil, et sous quelle forme
Les entrées, le poids des portions, votre suivi du poids et les petits aperçus des photos sont écrits dans le stockage propre de votre navigateur, et une copie part vers notre serveur scellée : la clé n’existe que sur votre appareil. Le serveur ne peut en montrer le contenu à personne — non parce que nous l’avons promis, mais parce qu’il n’a pas de clé. Une sauvegarde est un fichier que vous exportez vous-même et gardez où bon vous semble.
La conséquence pratique mérite d’être dite franchement, car c’est la même propriété vue de l’autre côté : perdez votre code de récupération avec l’appareil, et personne ne pourra rendre le journal, nous compris. Il n’y aurait rien pour le déchiffrer.
Ce qui quitte bel et bien l’appareil
Deux choses, et seulement quand vous agissez : la photo du repas et le texte de votre recherche de produit.
Le texte de recherche — seulement si vous avez touché « Chercher dans la base ouverte ». L’entrée Produits cherche dans vos propres produits et dans le catalogue téléchargé sur l’appareil — sans réseau. Quand le catalogue n’a pas ce qu’il vous faut, un bouton apparaît sous la liste, et sur ce toucher ce que vous avez tapé part vers Open Food Facts directement depuis votre appareil, sans passer par notre serveur. Aucune saisie semi-automatique pendant la frappe, aucune requête en arrière-plan : sans ce toucher rien ne part, et rien ne voyage avec le texte — ni le journal, ni les photos, ni aucun identifiant. Une case dans les réglages (Produits par code-barres) désactive cette recherche, et le bouton disparaît alors complètement ; chercher un produit par le code imprimé sur l’emballage ne passe jamais par le réseau, quel que soit l’état de la case.
La photo du repas. Son trajet dépend de la clé qui signe la requête, et ce choix vous revient dans l’application :
- Avec votre propre clé, la photo va de votre appareil directement à la plateforme dont vous avez saisi la clé, sans passer par notre serveur. Nous ne la voyons pas et ne la gardons pas. L’application comprend les clés de dix plateformes, et une photo peut atteindre neuf adresses ; elles sont nommées une à une dans la politique de confidentialité, et l’application ne connaît aucune autre adresse.
- Avec la clé Snapfork, la photo passe par notre serveur, parce que la requête y est signée, puis par OpenRouter — la plateforme qui transmet la requête au fournisseur du modèle. Elle n’est pas stockée chez nous : ni le fichier, ni une copie dans les logs. Il reste une ligne de chiffres — le modèle, les jetons, ce que cela nous a coûté. À chaque requête, nous demandons à la plateforme de ne pas passer par des fournisseurs qui conservent ce qu’on leur envoie — cela fait partie de la requête, ce n’est pas une promesse en prose.
L’application commence par votre propre clé et ne passe à la nôtre qu’après l’échec de la vôtre : quota épuisé, clé révoquée, plateforme muette. C’est le comportement par défaut, et une case dans les réglages le désactive — un échec de votre clé signifie alors simplement pas de reconnaissance, et la photo ne va jamais plus loin que la plateforme que vous avez choisie. Chaque photo reconnue avec notre clé l’indique à l’écran.
Ensuite, ce sont les conditions de la plateforme qui s’appliquent, pas les nôtres. Chez Google, par exemple, elles ne sont même pas les mêmes pour les deux niveaux d’une même clé : au niveau gratuit, Google se réserve le droit d’utiliser ce que vous envoyez pour améliorer ses produits ; au niveau payant, non. Les autres plateformes ont leurs propres conditions, à lire à la source. Quelle clé saisir, et à quel niveau, c’est votre choix — et c’est la chose la plus lourde de conséquences à comprendre avant de photographier ce que vous mangez.
Ce que le serveur garde bel et bien
Plus que ce qu’exige une connexion, et mieux vaut le dire franchement. Pour la connexion : votre adresse e-mail sous forme de transformation irréversible plutôt qu’en clair, une empreinte de session, et les codes des e-mails de connexion, hachés, pendant dix minutes. Pour le journal : sa copie scellée, les aperçus des photos et les versions en conflit, ainsi que vos réglages si vous en avez activé la synchronisation — le tout scellé avec votre clé. Au-delà : votre correspondance avec le développeur, les recharges du solde de reconnaissance, la liste de vos appareils, les amis et les invitations si vous vous en servez, et des sauvegardes horaires de la base de données. La politique de confidentialité en est l’unique version de référence, et elle énumère tout cela en entier, avec la durée de conservation de chaque élément.
Ce qu’il n’y a pas ici
- Pas de bandeau de cookies. Il y a exactement un cookie ici — celui qui vous garde connecté ; sans lui la connexion ne fonctionne pas, et nulle part on ne vous demande votre consentement pour cela. Rien n’est déposé pour l’analyse d’audience ou la publicité.
- Pas d’analyse tierce, pas de pixels publicitaires, pas de widget de chat.
- Pas de polices web depuis un CDN — le texte que vous lisez est composé dans la police de votre propre système, ce qui ne coûte aucune requête.
Tout cela se vérifie au lieu de se promettre : ouvrez les outils de
développement et regardez l’onglet Réseau pendant le chargement de cette
page. Une requête y vient de nous, et mieux vaut la nommer ici que vous
laisser la trouver : une balise vers /hit qui compte la visite
sans cookies et sans le code de personne d’autre. Ce qu’elle enregistre, et
ce qu’elle n’enregistre délibérément pas, est détaillé sur la
page Confidentialité.