Projet 10 – Application de recettes iOS : la création de Mijot
Mijot est une application iOS de gestion des repas que j’ai imaginée pour répondre à une question très simple : que peut-on cuisiner avec les aliments que l’on vient réellement d’acheter ?
Après les courses, il est facile d’oublier ce qui se trouve dans le réfrigérateur, de laisser certains produits expirer ou de manquer d’idées au moment de préparer un repas. Mon objectif était donc de construire un parcours continu : partir d’un ticket de caisse, créer automatiquement un inventaire, proposer des recettes adaptées, puis organiser ces repas dans la semaine.
Mijot combine une interface native développée en SwiftUI avec l’analyse de documents et la génération structurée de recettes à l’aide de l’API Gemini.
ILLUSTRATION 1 — Image à la une
1. L’idée du projet
La plupart des applications de recettes partent d’un catalogue : l’utilisateur cherche un plat, puis vérifie s’il possède les ingrédients nécessaires. Avec Mijot, j’ai voulu inverser cette logique. L’application part du stock réel de l’utilisateur et construit les propositions autour de ce qui est déjà disponible.
Le parcours principal se déroule en six étapes :
sélectionner un ticket de caisse au format PDF ;
détecter les produits alimentaires, leurs quantités et leurs prix ;
vérifier et corriger les informations proposées ;
ajouter les produits à un inventaire local ;
générer des recettes correspondant au stock et aux préférences de l’utilisateur ;
placer les repas dans un planning hebdomadaire et, si souhaité, dans Apple Calendar.
L’objectif n’est pas de retirer tout contrôle à l’utilisateur. L’intelligence artificielle accélère la saisie et propose des idées, mais les informations importantes restent modifiables avant leur enregistrement.
ILLUSTRATION 2 — Parcours général
Le parcours complet de Mijot, des courses à la planification des repas
2. Transformer un ticket en données utilisables
La première difficulté concernait la grande diversité des tickets de caisse. Un même produit peut être abrégé, séparé sur plusieurs lignes ou accompagné de nombreux nombres : poids, prix au kilogramme, remise et prix final.
Mijot commence par ouvrir le document avec PDFKit. Pour les PDF suffisamment légers, le document est envoyé directement à Gemini afin de conserver sa mise en page et de mieux comprendre les différentes colonnes. Lorsque le fichier est trop volumineux ou ne contient pas de texte exploitable, l’application extrait localement son contenu et peut utiliser Vision comme solution OCR de secours.
Gemini renvoie ensuite une réponse JSON structurée contenant notamment :
le nom lisible de chaque aliment ;
la quantité et son unité ;
le prix réellement payé pour la ligne ;
une catégorie alimentaire ;
le rangement conseillé ;
un niveau de confiance ;
un émoji permettant d’identifier rapidement le produit.
Les adresses, moyens de paiement, totaux, numéros de téléphone et autres lignes administratives doivent être exclus. Comme aucun système de reconnaissance n’est parfait, Mijot affiche toujours un écran de validation avant l’importation. L’utilisateur peut modifier le nom, la quantité, le prix, la catégorie ou le rangement, mais aussi retirer un produit détecté par erreur.
ILLUSTRATION 3 — Analyse d’un ticket
Un ticket non structuré devient une liste d’aliments vérifiable
3. Un inventaire local et compréhensible
Une fois validés, les aliments rejoignent un inventaire privé enregistré sur l’appareil. Les produits sont séparés entre ceux qui se conservent au réfrigérateur et ceux qui peuvent rester à température ambiante. Ils sont également classés en quatre familles : viandes et poissons, fruits et légumes, laitages, puis snacks et épicerie.
Chaque élément conserve sa quantité, son unité, son prix unitaire éventuel, sa date d’ajout et, lorsque cela est pertinent, une date limite estimée. Les viandes et poissons frais peuvent ainsi être mis en avant pour être utilisés rapidement.
L’inventaire peut aussi être corrigé manuellement. Un historique conserve les ajouts provenant des tickets et les quantités retirées lorsqu’un plat est indiqué comme préparé.
ILLUSTRATION 4 — Inventaire Ajouter une capture de l’écran « Mes aliments » montrant les différentes catégories et quelques produits avec leurs quantités. Texte alternatif : « Inventaire alimentaire de Mijot organisé par rangement et catégorie ».
4. Des recettes générées à partir du stock réel
Mijot ne présente pas un catalogue fixe. L’utilisateur choisit le nombre de propositions souhaitées, entre une et quatorze, puis Gemini compose les recettes à partir des aliments présents.
Un profil permet de préciser :
le régime alimentaire ;
les allergies ou intolérances ;
les aliments appréciés ou refusés ;
les cuisines favorites ;
la plage calorique souhaitée ;
les féculents autorisés ;
le niveau d’épices ;
le temps maximal de préparation ;
les appareils disponibles, comme le four, la poêle ou l’Airfryer.
Les réponses sont contraintes par un schéma JSON afin d’obtenir, pour chaque recette, un titre, un temps de préparation, une estimation calorique, une liste d’ingrédients et des étapes ordonnées. Les quantités utilisées sont ensuite comparées à l’inventaire.
Lorsque le prix d’un ingrédient est connu grâce au ticket, Mijot estime également le coût de la portion. Cette fonctionnalité permet d’afficher le budget total des recettes et un prix moyen par repas.
Les informations nutritionnelles restent des estimations produites par un modèle génératif. Elles ne remplacent pas une base nutritionnelle certifiée ni un avis médical, et chaque recette doit être vérifiée en cas d’allergie importante.
ILLUSTRATION 5 — Recettes et budget Utiliser un montage de deux captures : la liste des recettes avec leur coût, puis le détail d’une recette avec ses ingrédients et ses étapes. Légende : « Des recettes personnalisées selon le stock, les préférences et le budget ».
5. Planifier la semaine et synchroniser le calendrier
Une recette peut être ajoutée à un ou plusieurs déjeuners ou dîners. Le planning hebdomadaire permet ensuite de déplacer les repas par glisser-déposer, de les supprimer ou d’indiquer qu’ils ont été préparés.
L’intégration repose sur EventKit, le framework de calendrier d’Apple. Avec l’autorisation de l’utilisateur, Mijot crée un événement comprenant le nom du plat, l’horaire, le nombre de portions et la liste des ingrédients. Le calendrier de destination peut être un calendrier Apple, iCloud ou Google déjà configuré sur l’iPhone.
Le stock n’est diminué qu’après l’action « Plat préparé ». Ce choix évite de considérer automatiquement qu’un repas planifié a réellement été cuisiné.
ILLUSTRATION 6 — Planning
Screenshot
6. Architecture technique
Mijot est développé entièrement avec les technologies natives d’Apple et ne dépend d’aucune bibliothèque Swift externe.
Besoin
Technologie utilisée
Interface
Swift et SwiftUI
Lecture des tickets
PDFKit
OCR local de secours
Vision
Analyse et génération
API Gemini avec réponses JSON structurées
Modèles et persistance
Codable, JSON et UserDefaults
Stockage de la clé API
Keychain Services
Calendrier
EventKit
Tests
XCTest
L’état principal de l’application regroupe l’inventaire, les mouvements de stock, les recettes, le profil alimentaire et les repas planifiés. Les services responsables de Gemini, des PDF et du calendrier sont séparés de l’interface afin de conserver un flux de données lisible.
ILLUSTRATION 7 — Schéma technique
Architecture simplifiée de l’application Mijot
7. Confidentialité et limites de l’intelligence artificielle
Le projet a été conçu comme un prototype personnel. L’inventaire, l’historique, le profil et le planning restent enregistrés localement. La clé Gemini fournie par l’utilisateur est conservée dans le Trousseau de l’iPhone et n’est jamais intégrée au code source.
Certaines données doivent néanmoins être transmises à Gemini pour fournir les fonctionnalités attendues :
le ticket lors de son analyse, ou son texte extrait localement ;
les noms, quantités, catégories et prix du stock lors de la génération ;
les préférences alimentaires nécessaires à la personnalisation.
Cette distinction est expliquée directement dans l’application. Pour une éventuelle distribution à plus grande échelle, les appels au modèle devraient être placés derrière un service intermédiaire avec authentification, suivi des quotas et politique de confidentialité complète.
8. Les principaux défis rencontrés
Passer d’un document ambigu à une structure fiable
Un ticket est conçu pour être lu par une personne, pas par une application. J’ai dû définir précisément les données attendues et ajouter une étape de validation humaine plutôt que de considérer la réponse du modèle comme toujours correcte.
Conserver des unités cohérentes
Les aliments peuvent être exprimés en pièces, grammes, kilogrammes, millilitres, centilitres ou litres. Les conversions sont nécessaires pour comparer le stock aux besoins d’une recette et calculer correctement son coût.
Relier plusieurs fonctionnalités dans un seul parcours
Le projet ne consiste pas uniquement à appeler une API. L’intérêt vient de la continuité entre l’importation, la persistance locale, la génération, le calcul du budget, le planning et le calendrier. Concevoir ces transitions m’a appris à raisonner sur un produit complet plutôt que sur une démonstration isolée.
Définir la bonne place de l’IA
Gemini est utile pour interpréter des libellés irréguliers et produire des idées variées. En revanche, les opérations déterministes — conversions, prix, stockage, dates et mouvements d’inventaire — restent gérées par le code de l’application. Ce projet m’a appris à ne pas utiliser un modèle génératif pour les tâches qui exigent un résultat exact.
9. Ce que j’ai appris
Ce projet m’a permis d’approfondir plusieurs aspects du développement iOS :
concevoir une application SwiftUI composée de plusieurs parcours liés ;
utiliser PDFKit et Vision pour traiter des documents ;
obtenir des sorties JSON structurées depuis un modèle multimodal ;
protéger une clé API avec le Trousseau iOS ;
gérer des données persistantes avec Codable ;
synchroniser des éléments avec EventKit ;
calculer des coûts à partir de quantités et d’unités différentes ;
prévoir les erreurs, les corrections manuelles et les limites d’un système basé sur l’IA.
10. Prochaines évolutions
Mijot reste un prototype en développement. Les prochaines étapes envisagées sont :
améliorer les tests avec davantage de formats de tickets anonymisés ;
permettre l’analyse d’une photo en plus des PDF ;
conserver une copie complète des recettes déjà planifiées ;
renforcer les contrôles des quantités avant de retirer des ingrédients ;
ajouter un mode famille avec plusieurs profils et un calendrier partagé ;
proposer un suivi quotidien facultatif des repas et collations.
Avant d’ajouter de nouvelles fonctionnalités, ma priorité est de fiabiliser le cœur du produit : la reconnaissance du ticket, la cohérence de l’inventaire et la conservation des recettes planifiées.
11. Résultat
Mijot m’a permis de construire une application qui associe traitement de documents, intelligence artificielle, stockage local et services natifs iOS autour d’un usage quotidien concret.
Le résultat est un prototype capable de transformer un ticket de caisse en informations directement utiles : un inventaire, des idées de repas, une estimation du budget et un planning de la semaine.