Ce qui est réalisé
Application installable avec listes hebdomadaires, cases d’achat, ajouts hors liste et association aux tickets via Google Drive. Une copie adaptée figure dans Suivis PC v2.
Organiser & rapprocher / UML classes
Une liste de courses
reliée à ce qui a été payé.
Cocher ses achats en magasin, puis rattacher la liste aux tickets correspondants : le coût réel de l’alimentation se suit dans le temps, sans ressaisir un seul prix.
Le besoin
Les listes de courses sont préparées à partir d’un plan alimentaire. La question posée était simple : combien coûte réellement ce plan, semaine après semaine ?
L’analyse
Saisir des prix ligne par ligne aurait été fastidieux et peu fiable. Le modèle retenu sépare deux choses : la liste dit ce qui a été acheté, les tickets disent combien cela a coûté. Le lien entre les deux se fait au niveau du ticket entier.
La liste est un simple fichier JSON déposé dans le Drive. L’application la retrouve par son nom, quel que soit le dossier.
Le processus documenté
Modèle de données d’une liste de courses
UML 2 · diagramme de classes← Faire défiler le schéma →
Règles de gestion
Ce que l’outil doit respecter.
- RG-01Une liste = un fichier nommé
courses_from_AAAA-MM-JJ_to_AAAA-MM-JJ.json, retrouvé par son nom, dossier libre. - RG-02Cocher = acheté. Un achat imprévu s’ajoute pendant les courses dans la catégorie « Hors liste ».
- RG-03Aucun prix par ligne : le coût provient exclusivement des tickets liés.
- RG-04La liaison copie la date, le magasin et le total du ticket analysé.
- RG-05Conflit de versions : entre le téléphone et le Drive, la copie la plus récemment modifiée l’emporte.
Limites assumées
La règle « la plus récente gagne » suffit pour un utilisateur seul. Pour un usage partagé, le périmètre d’accès Google et la gestion des conflits seraient à réexaminer.
Consulter le dépôt suivi_courses ↗L’outil en images
Un parcours visible.
État au 13 octobre 2026
Une réalisation, un périmètre précis.
Ce qui a été vérifié
Interface, documentation, service worker et manifeste sont présents. Le dernier état publié et sa synchronisation réelle ne sont pas reconfirmés dans l’inventaire.
Revue du 13 octobre : variante PC v2 exécutée sur une liste fictive ; cocher un article actualise le compteur. Identité réseau simulée dans le banc d’essai ; aucun trajet Drive testé.
Limites actuelles
Le choix de la version la plus récente est adapté à un utilisateur unique ; il ne constitue pas une fusion de modifications partagées.
Prochaine étape
Identifier la version publiée et valider le parcours téléphone–Drive avec modification locale, reconnexion et rattachement d’un ticket.
Exemples de critères de recette
Ces critères décrivent le résultat attendu. Ils ne constituent pas, à eux seuls, des tests réussis.
- Cocher un article et ajouter un achat hors liste met à jour le bon fichier hebdomadaire sans créer de prix par ligne.
- Lier un ticket copie sa date, son magasin et son total ; après reconnexion, la version choisie suit la règle de modification la plus récente.
Parlons de votre projet
Un besoin concret.
Une première discussion.
Un processus trop manuel, une donnée peu fiable ou une idée à tester ? Commençons par clarifier ce qui vous serait vraiment utile.
Échanger avec Loïc