Cocher un produit sur une liste de courses est un geste simple. Il laisse pourtant plusieurs questions ouvertes : quelle quantité a été achetée, où se trouve-t-elle maintenant, et faut-il encore en rapporter ?
En développant la Borne Frigo, j’ai voulu conserver une continuité entre ces moments. L’information devait pouvoir suivre le parcours du produit, puis servir à retrouver ce qui était disponible dans la maison.
Il a fallu commencer par choisir sur quelles données et quelle interface construire ce parcours.
Le point de départ avec Bring
Bring! faisait déjà partie des outils utilisés pour les courses. J’ai essayé de l’intégrer à l’écran du frigo, mais l’affichage et la récupération des données se prêtaient mal à ce que je voulais développer.
Entre la place occupée à l’écran, les particularités de l’interface mobile et les difficultés d’intégration, les ajustements s’accumulaient. Je cherchais une base qui me permette de travailler aussi sur les quantités, les emplacements et les opérations après l’achat.
J’ai donc retenu Grocy pour porter ces informations, avec une interface adaptée dans Home Assistant. Le premier catalogue repris comptait 309 produits. C’était un point de départ conséquent, mais connaître un produit ne signifiait pas en posséder un exemplaire.
Cette distinction a d’ailleurs demandé une correction lors de l’import : les fiches devaient pouvoir exister sans remplir artificiellement le panier ou les réserves.
Un ERP à l’échelle du foyer
En changeant d’outil, je retrouvais une logique familière dans l’industrie : celle d’un ERP, un logiciel qui relie plusieurs activités autour des mêmes données. Dans un système comme SAP, les achats, les stocks et la production peuvent ainsi partager leurs informations. Grocy reprend une partie de cette logique pour les besoins du foyer.
Les courses jouent le rôle des approvisionnements, les placards celui des stocks. Une recette ressemble à une nomenclature : elle indique les ingrédients et les quantités nécessaires pour préparer un repas. Quand je travaillerai sur les menus, cette relation pourra aider à déduire les achats à partir de ce qui est déjà disponible.
Les usages ont fait évoluer le modèle. Il fallait distinguer ce qui reste à rapporter, ce qui a été acheté et transporté, puis ce qui est rangé dans les réserves.
Ces catégories peuvent coexister pour un même produit. Un paquet peut déjà être dans le placard pendant qu’un autre attend d’être rangé, avec une quantité supplémentaire encore prévue sur la liste. Une seule étiquette de statut ne suffit donc pas à décrire la situation.
Il a fallu travailler sur les quantités associées à chaque étape et sur les mouvements qui les modifient. Ajouter un achat, ranger une quantité ou déplacer un lot ont des effets différents. Les dates de péremption et les emplacements doivent rester attachés aux bonnes informations.
Le vocabulaire change, mais je retrouve des questions familières : identifier les produits, suivre leurs mouvements et définir ce que chaque action modifie. L’interface, elle, doit rester assez simple pour donner envie de s’en servir. Personne n’a envie de remplir une fiche de production pour ranger un paquet de pâtes.
Construire les gestes qui vont avec
L’interface a été revue autour des actions les plus courantes. Les fenêtres produit regroupent maintenant les informations de stock, les dates connues et les opérations utiles. Des boutons permettent d’ajuster les quantités rapidement. Les réserves sont présentées selon les lieux où elles se trouvent réellement.
La lecture des codes ajoute un autre point d’entrée. Sur téléphone, elle permet de retrouver une fiche ou d’associer un code encore inconnu. L’opération à effectuer reste ensuite explicite : lire un code ne suffit pas à savoir si l’on souhaite acheter, consulter ou ranger.
La tablette a imposé une limite matérielle. Sa caméra avant, sans autofocus, rendait la lecture peu pratique. Les téléphones ont été retenus pour cet usage. Je préfère tenir compte de cette limite plutôt que construire tout le parcours autour d’un geste pénible à reproduire.
Le parcours complet imaginé avec les codes d’étagères et la reconnaissance du contexte reste une évolution à réaliser.
Une interface se juge aussi sur son appareil
Une version pouvait être fluide sur mon PC et mon téléphone, puis devenir lente sur la tablette. Les fenêtres tardaient à s’ouvrir, la recherche réagissait mal, et les gestes simples perdaient leur spontanéité.
Une première optimisation a réduit les traitements répétés et les reconstructions inutiles de l’interface. Le retour au rendu matériel dans Fully Kiosk a ensuite corrigé la latence restante et le défaut d’affichage pendant la saisie. Un ancien contournement en rendu logiciel avait fini par faire partie du problème.
Cet épisode m’a rappelé de vérifier le résultat là où il doit être utilisé. Pour la Borne Frigo, l’appareil de référence est celui qui reste dans la maison, avec son navigateur et ses contraintes propres.
Préparer les repas viendra sur cette base
Les courses et les réserves sont aujourd’hui utilisées en bêta. L’interface de gestion du stock reste encore assez lourde par endroits, et les retours d’usage doivent aider à supprimer les étapes inutiles.
Le travail sur les recettes est engagé, avec une relecture des données avant leur import. Il prépare un objectif plus large : rapprocher les repas envisagés, les produits disponibles et les achats nécessaires. Les données nutritionnelles commencent aussi à trouver leur place dans les fiches.
Les caméras ou le guidage lumineux restent des pistes pour plus tard. Avant de demander à la maison de repérer un produit ou d’indiquer une étagère, je veux que les informations de base et les gestes de rangement aient déjà un sens pour nous.