Jidoka Lab

App · foyer

Kago

La liste de courses du foyer qui se rappelle au bon endroit : quand l'un de nous entre dans un magasin où il reste quelque chose à prendre, l'iPhone le signale, sans suivi GPS continu.

État
bêta privée iPhone depuis octobre 2026, usage réel par le foyer · démontré par le code et les tests
Stack
Swift, SwiftUI, régions iOS, Postgres, fonctions serveur, notifications push
Depuis
2026
Preuves
29 tests automatisés (17 sur le cœur logique, 12 sur les notifications), des scénarios en base, une porte de qualité avant chaque livraison, 23 corrections issues d'une revue indépendante

Les croquettes oubliées

À la maison, les grosses courses se font toutes les deux ou trois semaines. Entre deux, chacun complète de son côté : un passage rapide au supermarché, une bricole dans une enseigne de déstockage. Et c’est là qu’on oublie. L’un de nous passe au Leclerc pour autre chose et ressort sans les croquettes du chat, qu’on ne trouve que là. L’autre entre chez Action sans savoir qu’on voulait y regarder une nouveauté. La liste existait, mais personne ne l’ouvre en entrant dans un magasin qu’il n’avait pas prévu.

Ce que j’ai construit

Vidéo de présentation en motion design (48 s, sans son), reconstitution avec des données fictives : foyer et prénoms inventés.

Une app iPhone pour les deux téléphones du foyer. Une seule liste, groupée par magasin. Un article vise un magasin, plusieurs, ou « n’importe où » ; il peut être urgent, ou seulement « à voir » quand il s’agit de regarder un produit sans forcément l’acheter. Un lien ou une image montre le bon produit. Le magasin se propose d’après les habitudes : les croquettes, c’est Leclerc.

Chacun choisit dans Plans les magasins qu’il fréquente, vingt au maximum. Le téléphone surveille ces zones, et seulement elles : pas de suivi GPS continu. Quand l’un de nous entre dans une zone où il reste quelque chose à prendre, une notification arrive sur l’écran verrouillé avec la liste, et un appui long suffit à tout cocher. Quand l’autre ajoute un article, l’autre téléphone est prévenu et la liste se met à jour. Pas de compte : un code de foyer à partager.

Kago est en bêta privée sur TestFlight depuis le 3 octobre 2026, et le foyer s’en sert pour de vraies courses. Quatre builds en dix jours, chacun né d’un usage réel.

La dernière nouveauté vient d’un détail du quotidien. Deux magasins de la même enseigne, par exemple deux Action, étaient indiscernables dans la liste. Ils sont maintenant distingués par leur ville, partout : la liste, la carte, la notification d’arrivée et la notification d’ajout. Les magasins créés avant la nouveauté en profitent aussi : l’app retrouve seule leur ville. Les magasins portent aussi le logo de leur enseigne. Pour les enseignes que l’app ne connaît pas, le logo est cherché en ligne avec une règle stricte : un faux logo est pire qu’une initiale, donc au moindre doute l’initiale reste.

Ce que ça raconte de ma façon de travailler

  • Challenger l’idée avant de la coder. L’idée de départ était une détection de toutes les grandes surfaces en temps réel. Un iPhone sait surveiller vingt zones en arrière-plan sans vider la batterie : le produit suit donc des magasins précis, choisis une fois. La contrainte de la plateforme a dessiné le produit, pas l’inverse.
  • Filtrer le faux positif. Un cercle de magasin déborde souvent sur la route. À l’entrée, l’app réveillée n’a que quelques secondes : elle demande une position fraîche, ne prévient que si on est vraiment là, puis se tait deux heures pour ce magasin.
  • Un bug de prod est une leçon de QA. Le lendemain de la mise en service, un ajout d’article était refusé. La cause : l’app et la base ne s’accordaient pas sur la façon de transmettre les paramètres vides. J’ai d’abord corrigé la base, ce qui a réparé les téléphones déjà installés sans rien leur demander, puis l’app, et ajouté les scénarios qui rejouent ce cas. Les tests étaient verts parce qu’ils parlaient à une base qui n’avait pas ce défaut de vocabulaire.
  • La revue trouve ce que les tests laissent passer. Avant la première mise en prod, une revue indépendante a rendu vingt-trois remarques, dont une notification d’ajout qui partait avant que l’article soit relié à son magasin. Tout a été corrigé, puis revu une seconde fois.

Sous le capot

Swift et SwiftUI, un cœur de logique séparé et testé (groupement par magasin, règle d’arrivée, nom d’affichage des magasins, textes des notifications). Une base où chaque foyer ne voit que ses lignes, des fonctions serveur pour les opérations sensibles, un stockage privé pour les images compressées sur le téléphone, et des notifications push. Les évolutions de la base sont additives, et la base est mise à jour avant chaque nouveau build, pour qu’un téléphone resté sur l’ancienne version continue de fonctionner.

Ce que j’ai vérifié

  • Signal observé : des achats propres à un magasin oubliés lors des petites courses faites séparément, puis, à l’usage, deux magasins homonymes impossibles à distinguer et un ajout refusé en production.
  • Test ou contrôle : dix-sept tests sur le cœur logique, douze sur les notifications côté serveur, des scénarios sur une base jetable qui prouvent qu’un foyer ne voit rien d’un autre et que le vingt et unième magasin est refusé, une porte de qualité qui doit passer avant chaque livraison, et une revue indépendante avant la première mise en production.
  • Résultat : quatre builds livrés en bêta privée, le foyer l’utilise pour ses courses, et le bug de production du 4 octobre a été réparé sans réinstaller quoi que ce soit.
  • Limite actuelle : le rappel à l’entrée doit encore faire ses preuves sur la durée (détection avec une à trois minutes de latence, magasins au bord d’une route) ; la bêta ne compte que deux téléphones.

← Tous les projets