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 : des capacités distinctes

La documentation produit Frozen Save décrit un export JSON versionné avec somme de contrôle, un import strict et un export CSV. Le JSON constitue la sauvegarde complète restaurable ; le CSV sert à consulter les données et ne remplace pas cette sauvegarde. Vérifiez le format du fichier conservé avant de compter sur une reprise : un export lisible ne prouve pas que vous pourrez le restaurer.

L'import valide le schéma et les relations avant écriture. Suivez les indications du produit et conservez une copie de sauvegarde avant un remplacement ; ne corrigez pas arbitrairement le contenu du JSON pour forcer son acceptation. Ces capacités documentées ne garantissent pas la compatibilité de tout ancien fichier ni une restauration sans contrôle.

Le mode local ne synchronise pas spontanément les appareils. Un accès Frozen Save facultatif permet de configurer un foyer partagé chiffré ; cette voie demande le réseau et reste distincte de l'export manuel. Le serveur ne reçoit pas la clé de foyer en clair. La disponibilité de ce mécanisme ne démontre pas que votre appareil a envoyé ou reçu sa dernière modification : vérifiez l'état effectivement affiché. Les parcours publics connectés demeurent à qualifier dans leur périmètre réel.

Avant un changement de foyer ou un import, identifiez la copie : appareil ou registre source, date d’export, foyer concerné et périmètre annoncé par l’outil. Gardez ces indications dans une note privée au nom neutre, sans publier l’inventaire. Une somme de contrôle valide peut aider à détecter une altération ; elle ne démontre ni que le fichier décrit le foyer voulu, ni que les quantités sont encore actuelles.

Comparez quelques entrées avec le registre de référence et les contenants réels : même zone, même objet, même unité. Un numéro manuscrit peut avoir été réutilisé depuis l’export ; un nom identique ne suffit pas à identifier le même sachet. Relevez séparément les produits entrés, utilisés ou déplacés depuis la copie. Conservez cette liste de différences et une sauvegarde actuelle distincte avant d’envisager un remplacement. Ne réintroduisez pas automatiquement les quantités d’un ancien fichier.

Lisez la portée annoncée avant de confirmer : quel inventaire sera concerné et quels éléments seront remplacés ? Une connexion au bon compte ne suffit pas à identifier le bon foyer. Si l’interface ne permet pas de comprendre l’effet sur le contexte local ou partagé, interrompez la manipulation et clarifiez cette portée ; le guide ne promet pas de fusion automatique, de prévisualisation ou d’annulation après écriture. Prévenez les personnes qui utilisent le registre de référence pour éviter des corrections concurrentes pendant le rapprochement.

En cas d’annulation ou de refus du fichier, ne purgez pas le navigateur et ne supprimez pas la dernière copie utile pour recommencer. Conservez l’original et le message exact, puis vérifiez séparément l’état actuellement accessible. Un refus ne prouve pas une perte ; un message de réussite ne prouve pas que la liste correspond au stock réel. Après l’opération, relisez le contexte, les entrées témoins et les différences conservées avant de reprendre les mises à jour ordinaires. Si le résultat reste ambigu, évitez les imports répétés et demandez une clarification sans transmettre de clé ni d’inventaire privé.

Exemple fictif : un export du dimanche contient deux sachets repérés 12 et 13. Le lundi, le sachet 12 a été utilisé et un nouveau contenant 14 a été rangé. Avant un changement de foyer le mercredi, restaurer aveuglément le fichier du dimanche ferait réapparaître 12 et omettrait 14. Le foyer garde la copie actuelle et la note des changements, rapproche les objets présents puis décide quoi reprendre. Une confirmation de transmission vers une autre application ne reconstitue pas ces changements et ne remplace pas ce contrôle.

La synchronisation ne constitue pas une sauvegarde distante indépendante du foyer. Le site-guide ne reçoit ni fichier d'inventaire ni clé et ne publie aucune API de stock pour récupérer vos données. Le mode local reste utilisable séparément.

Une confirmation de transmission n’est pas une sauvegarde d’inventaire. Si un envoi vers MAJORDHOM reste en attente après expiration, ne concluez pas qu’il a échoué ou qu’il a été accepté. Gardez la copie et l’attente existantes ; ne supprimez pas les données du navigateur et ne créez pas un nouvel envoi pour deviner le résultat du premier. Dans MAJORDHOM, le panneau de reprise peut afficher « Identifiant de l’import à retrouver dans Frozen Save » et « Copier l’identifiant ». Cette référence désigne l’opération : ce n’est ni le lien de transfert complet, ni un mot de passe, ni une clé. Elle n’accorde aucun accès par elle-même ; ne la publiez pas avec le contenu de votre liste.

Frozen Save est la source de cet envoi ; MAJORDHOM en est la cible. Rejoignez Frozen Save par son entrée officielle et utilisez le compte source autorisé pour cette opération, avec son appareil reconnu. Lorsque la commande « Obtenir la confirmation officielle » est proposée, demandez la confirmation de l’envoi existant. Si la référence locale manque, le champ facultatif « Référence d’envoi MAJORDHOM » permet d’indiquer l’identifiant relevé côté cible. Fournir cet identifiant ne remplace pas la connexion ni les contrôles d’autorisation. Une confirmation indisponible reste indisponible : vérifiez le compte et la référence sans relancer indéfiniment l’ancien lien ou changer de compte pour contourner un refus.

Si Frozen Save affiche la confirmation signée à copier, copiez le texte JSON complet tel quel, sans le modifier ni le remplacer par une capture. Dans MAJORDHOM, utilisez le champ « Confirmation signée officielle de Frozen Save », puis « Vérifier et réconcilier ». Le document contient la référence, la cible, l’état, la date, un identifiant de clé de vérification et une signature ; il ne contient pas votre clé de contenu. Sa présence ou son apparence ne prouve pas l’acceptation : attendez le résultat de la vérification pour cette opération et ce compte exacts. La lecture côté source conserve la liste ; elle ne décide pas à votre place de la libérer. L’expiration empêche de réutiliser l’ancienne décision, mais ne garantit ni l’existence d’un reçu final ni la réussite de cette reprise. Si le résultat reste inconnu, préservez la copie en attente. Les commandes documentées ne valent pas qualification d’un parcours humain complet après expiration, ni restauration universelle ou synchronisation par My DOHM.

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.