Inventaire, dates, quantités et recettes : quelles données garder, sous quel format ?

2. Distinguer l’objet physique, l’entrée locale et le concept public

L’objet physique est le produit ou le contenant dans le réfrigérateur ou le congélateur. L’entrée locale est sa représentation sur un terminal. Le concept public est une catégorie ou une recette partageable sans révéler le foyer. Ces trois niveaux ne sont pas interchangeables.

Deux sachets identiques sont deux objets physiques. Ils peuvent partager la catégorie publique « courgettes » tout en possédant des quantités, repères et dates distincts. À l’inverse, une préparation maison peut réunir plusieurs ingrédients et devenir une nouvelle entrée.

Un identifiant interne sert à distinguer les entrées dans le stockage local. Il n’a pas à être lisible ni placé dans une URL. Un numéro manuscrit sert à retrouver un contenant opaque. Un `recipe_id` public sert à ouvrir une famille de recette autorisée. Employer la même valeur pour ces trois usages provoquerait collisions et fuites.

La donnée publique doit rester peu descriptive : un slug éditorial stable ou un identifiant fermé. La donnée du foyer reste locale. Un mapping explicite permet à l’application de relier une catégorie locale à une page publique sans transmettre le nom libre saisi.

3. Nom, catégorie et libellé : trois fonctions différentes

Le nom aide une personne à reconnaître l’objet : « soupe carotte-lentille », « courgettes en dés » ou « pain tranché ». Il peut contenir une précision utile au foyer et doit rester sur le terminal lorsqu’il est librement saisi.

La catégorie sert au tri ou à la correspondance avec des recettes. Elle est plus stable et moins précise : légume, fruit, préparation, pain, produit laitier selon la taxonomie réellement retenue. Une catégorie n’est pas une composition ni un diagnostic alimentaire.

Le libellé éditorial appartient au site public. Il est relu, traduit et lié à une page substantielle. Les slugs `avec-courgettes` ou `avec-poissons` représentent des portes d’entrée publiques, pas les aliments exacts d’un utilisateur.

Lorsque plusieurs langues existent, stockez une clé stable et présentez un libellé localisé. Ne traduisez pas automatiquement le texte libre du foyer dans l’URL. Une catégorie sans page complète peut aboutir à un fallback `noindex`, mais ne doit pas générer une page mince indexable.

4. Quantité et unité : représenter ce que le foyer peut maintenir

Une quantité sans unité est ambiguë. `2` peut désigner deux pièces, deux portions, deux grammes ou deux boîtes. Le modèle doit associer valeur et unité, ou employer une expression qualitative claire lorsque la mesure exacte n’existe pas.

Les unités possibles dépendent du geste : masse réellement pesée, volume mesuré, nombre d’unités, portions estimées ou état « inconnu ». Une conversion automatique entre unités demande une densité, une taille ou une recette que l’outil ne possède pas forcément.

Les nombres décimaux doivent être affichés selon la locale tout en restant calculables. L’interface française peut montrer une virgule, mais le stockage technique ne doit pas confondre texte et valeur. Une quantité ne devient pas exacte simplement parce qu’elle contient deux décimales.

Après cuisine, la mise à jour porte sur l’usage réel. Une recette donne des quantités prévues ; elle ne doit pas être déduite automatiquement sans confirmation. Si le foyer emploie « portions », la taille doit rester compréhensible pour les personnes qui partagent le registre.

• Toujours associer valeur et unité.
• Conserver inconnu comme état valide.
• Éviter les conversions sans donnée.
• Afficher selon la locale.
• Confirmer la sortie réelle.

5. Dates : stocker le type, la valeur et le contexte

Une date isolée ne dit pas ce qu’elle représente. DLC, DDM, ouverture, préparation et congélation ont des origines et conséquences différentes. Le modèle doit donc conserver le type de date avec la valeur et, lorsque pertinent, la source déclarée.

Pour un instant technique — création ou modification d’une entrée — un format non ambigu avec fuseau comme celui décrit par la RFC 3339 facilite l’échange. Pour une date portée sur un emballage, une date civile peut suffire si l’information ne contient pas d’heure. Ne transformez pas arbitrairement minuit local en instant universel.

L’affichage suit la langue et le contexte : `25/08/2026` peut être lisible en français, tandis que le stockage conserve une représentation structurée. Le fuseau du terminal doit être considéré pour les événements horodatés, notamment lors d’un voyage ou d’un changement d’heure.

Aucune date calculée par l’application ne remplace l’étiquette ou l’historique réel. Une alerte invite à vérifier. Le champ peut être absent ; une valeur inventée pour satisfaire une validation est plus dangereuse qu’une information inconnue.

6. Emplacement et repère : assez précis pour retrouver, pas pour profiler

L’emplacement décrit une zone domestique utile : réfrigérateur, congélateur, tiroir bas, bac ou étagère. Il ne s’agit pas d’une géolocalisation. Une adresse, des coordonnées ou l’identité du foyer n’apportent rien à la recherche d’un contenant et ne doivent pas être collectées.

Le vocabulaire doit être partagé par les personnes concernées. Une clé stable peut être associée à un libellé local, mais les zones restent configurables. Une hiérarchie trop fine devient fragile dès qu’un produit est déplacé.

Le numéro manuscrit est un repère physique facultatif. Il peut être unique dans le contexte local sans devenir un identifiant mondial. Si deux terminaux sont utilisés sans synchronisation, la méthode doit prévenir les collisions ou désigner un registre de référence.

Une photo, un code-barres ou un QR pourrait apporter d’autres fonctions, mais ils ne sont pas nécessaires au contrat actuel. Le guide ne prétend pas que Frozen Save les exige ou les qualifie. Le feutre et l’étiquette restent des solutions valides.

• Zone compréhensible.
• Aucune adresse ou coordonnée.
• Repère unique dans le contexte utile.
• Pas de QR obligatoire.
• Limite multi-terminal explicite.

7. Stockage local avec IndexedDB : capacité et limites

IndexedDB est une API Web destinée au stockage local de données structurées sous forme de clés, valeurs, magasins d’objets et index. La spécification décrit aussi transactions, risques de persistance et considérations de confidentialité. Elle ne garantit pas à elle seule une sauvegarde éternelle.

Local signifie que les données sont attachées au contexte de stockage du navigateur et de l’origine. Suppression des données du site, politique du navigateur, changement d’origine, réinitialisation ou perte du terminal peuvent affecter leur disponibilité. Le mode local de Frozen Save ne synchronise pas les appareils ; le foyer partagé chiffré est une option distincte avec compte et réseau.

Une migration de version doit préserver ou transformer les enregistrements de manière atomique. Une opération d’ajout ou de diminution doit éviter un état partiellement écrit. Ces exigences relèvent du produit ; le site-guide n’accède jamais à la base locale du visiteur.

Le stockage local réduit la transmission par défaut, mais ne rend pas les données invisibles à toute personne ayant accès au même terminal ou profil. Verrouillage, partage de session, sauvegarde du système et export éventuel doivent être expliqués selon les fonctions réellement présentes.

8. Versionner sans publier le schéma privé

Un stockage évolutif a besoin d’une version : nouveaux champs, renommage de catégorie, séparation des dates ou correction d’un identifiant. La migration doit être déterministe, testée sur une copie fictive et capable d’échouer sans rendre les données illisibles.

Versionner ne signifie pas exposer tout le schéma dans le HTML. Le site peut documenter les concepts publics et les contrats d’URL. Les détails internes restent dans le produit et ses passations, car les figer publiquement créerait une compatibilité non promise.

Les valeurs fermées doivent prévoir un état inconnu et rejeter les chaînes inattendues lorsqu’elles entrent dans un contrat. Les textes libres restent locaux et doivent être traités comme des données, jamais comme du code ou du HTML.

Une migration additive conserve les anciens enregistrements jusqu’à validation de la nouvelle forme. Un rollback doit connaître la compatibilité descendante ; revenir au code antérieur après une migration irréversible peut être plus dangereux que rester sur la nouvelle version. Cette décision appartient au produit, pas au site.

• Version explicite.
• Migration déterministe.
• Entrées inattendues rejetées ou mises en quarantaine.
• Texte libre non interprété.
• Rollback pensé avec les données.

9. URL de retour : liste blanche de paramètres publics

Une URL est visible dans l’historique, les journaux techniques, les captures, le presse-papiers et parfois les en-têtes. Elle ne doit donc contenir ni stock, ni quantité, ni date, ni foyer, ni liste de courses, ni note, ni identifiant sensible.

Le retour autonome qualifié vers Frozen Save utilise `fs_source=seo`, `fs_return=local-list-v1`, un `recipe_id` public et `fs_lang`. Les identifiants publics autorisés sont `soup`, `gratin`, `pan`, `pasta`, `tart` et `dessert`. Toute autre valeur doit être refusée ou traitée par un fallback sûr.

L’ordre des paramètres n’a pas de sens métier. L’application doit les parser selon le standard URL et valider séparément chaque valeur. La canonical du site-guide reste propre, sans paramètres d’origine, afin d’éviter les duplications indexables.

Le parcours autonome ne vérifie aucun jeton et n’importe aucune liste. Frozen Save demande une confirmation, puis calcule localement depuis son propre stock. La voie tokenisée future reste distincte et fermée tant que le gateway central n’est pas qualifié.

10. Manifeste PWA : métadonnées d’installation, pas données métier

Le Web Application Manifest est un document JSON qui décrit notamment le nom, les icônes, l’URL de démarrage, la portée et le mode d’affichage d’une application Web. Il aide le navigateur à présenter l’installation ; il ne transporte pas l’inventaire.

Le `start_url` et la `scope` doivent correspondre à l’origine et au parcours réellement servis. Ajouter des paramètres personnels au démarrage serait contraire à la minimisation recherchée. Les icônes et couleurs décrivent l’identité publique, pas un profil utilisateur.

Une PWA installée reste une application Web avec les limites du navigateur, du stockage et du terminal. Le manifeste ne promet ni publication Store, ni synchronisation, ni conservation absolue des données. Ces capacités demandent des preuves distinctes.

Le site-guide possède sa propre identité éditoriale et ses canonicals. Le manifeste de l’application ne doit pas faire croire que les pages de recettes appartiennent à la base privée, et le site ne doit pas revendiquer une installation qu’il ne fournit pas.

11. JSON-LD Recipe : décrire uniquement la recette visible

Schema.org définit le type `Recipe` et des propriétés comme les ingrédients, instructions, rendement et durées. Le balisage structuré doit décrire exactement la recette visible. Il ne doit pas ajouter une note, un prix, une nutrition ou une image absente du contenu humain.

Les durées utilisent un format structuré adapté, tandis que le texte visible reste compréhensible. Les ingrédients incluent quantités et unités éditoriales, pas les quantités personnelles. Les instructions suivent les étapes réellement publiées.

Une page catégorie ou un fallback mince n’est pas une recette et ne doit pas recevoir `Recipe`. Une idée générale sans quantités ni étapes reste un guide ou une collection. Cette distinction évite un balisage trompeur destiné seulement aux moteurs.

Le JSON-LD n’est pas une API d’inventaire. Il est public dans le HTML et peut être lu par tout visiteur. Aucun ingrédient du foyer, aucune substitution personnelle et aucun résultat local ne doit y être injecté.

• Contenu visible et JSON-LD cohérents.
• Aucune propriété marketing inventée.
• Recipe seulement pour une recette complète.
• Données éditoriales publiques uniquement.
• Dates et auteurs réels.

12. Export, import et synchronisation : ne promettre que ce qui existe

Un export permettrait de récupérer ou transférer des données ; un import les validerait ; une synchronisation résoudrait les modifications de plusieurs terminaux. Ces fonctions ont des risques distincts et ne sont pas prouvées dans la capacité publique actuelle de Frozen Save.

Un futur format d’export devrait être versionné, documenter unités et types de date, exclure les secrets et permettre une validation avant écriture. L’import devrait rejeter ou mettre en quarantaine les valeurs invalides plutôt que corriger silencieusement.

La synchronisation demanderait une identité, des règles de conflit, un chiffrement, une révocation et une information de confidentialité. Copier une base locale dans le cloud sans ces contrats ne serait pas une simple amélioration technique.

Le site peut préparer des concepts compatibles et des slugs stables, mais il ne doit pas publier une API ou une promesse d’interopérabilité avant la passation produit. L’utilisateur actuel doit pouvoir agir entièrement avec le stockage local disponible.

13. Exemple minimal : une entrée, une recette et aucun secret dans l’URL

Une entrée locale peut représenter « courgettes en dés », deux portions estimées, tiroir bas, repère 12 et date de congélation déclarée. Chaque élément répond à une décision : retrouver, doser approximativement et distinguer le contenant. Cette entrée ne quitte pas le terminal.

Le catalogue public associe la catégorie à des pages comme `avec-courgettes`. Une recette complète choisie peut appartenir à la famille publique `gratin`. Le site sert son HTML, ses sources et son JSON-LD depuis une URL canonical sans données personnelles.

Pour retourner dans l’application, le lien contient seulement la source SEO, le mode autonome, `recipe_id=gratin` et la locale. Frozen Save affiche une confirmation, consulte son IndexedDB et calcule localement les manquants. Le site n’a jamais vu les deux portions ni le tiroir bas.

Après cuisine, la personne confirme les quantités réellement utilisées et crée un reste si nécessaire. L’entrée locale évolue ; la recette publique reste stable. Cette séparation est le principe essentiel du format : données du foyer locales, concepts éditoriaux publics et contrat de passage minimal.

1. Créer l’entrée locale minimale.
2. Rapprocher une catégorie publique.
3. Lire une recette complète.
4. Retourner avec quatre paramètres bornés.
5. Confirmer et corriger localement.

14. Checklist de qualité des données

Avant de considérer le registre utile, vérifiez chaque champ : sens clair, unité, origine, date de mise à jour, responsable du geste et exposition. Une donnée exacte mais jamais maintenue devient un piège ; une donnée approximative clairement qualifiée peut rester utile.

Vérifiez les frontières : aucun texte libre dans l’URL, aucun identifiant interne dans le site, aucune donnée privée dans le JSON-LD, aucune publicité alimentée par le stock et aucune synchronisation supposée. Les paramètres inconnus sont refusés ou ignorés de manière sûre.

Contrôlez le cycle : création, modification, sortie, transformation en reste, suppression et migration. Le modèle doit accepter les événements réels sans inventer de valeur. Une page éditoriale insuffisante reste `noindex` plutôt que de recevoir un balisage trompeur.

Ce guide est révisé lorsque les standards Web, le contrat public ou les capacités Frozen Save changent. Les références techniques sont des documents vivants ou des standards identifiés ; leur date de vérification est visible ci-dessous.

• Champ lié à une décision.
• Valeur inconnue autorisée.
• Unité et type de date explicites.
• Identifiants séparés par niveau.
• URL limitée aux paramètres publics.
• Stock local absent du HTML public.
• Migration et suppression prévues.
• Promesses alignées sur la capacité prouvée.