Aller au contenu
Marie DadomoStudio de développement
Étude de cas

VetSafe : lire une étiquette sans laisser l’IA décider de tout

Par
Marie Dadomo
Le
Lecture
5 minutes
En résumé
De la photo à un résultat explicable

VetSafe aide les propriétaires de chiens et de chats à examiner la composition d’un produit ou à rechercher un danger du quotidien. Le développement demande de distinguer ce que l’étiquette dit, ce que l’IA en extrait et ce que l’application peut expliquer à propos de l’animal. Voici comment ces responsabilités sont réparties dans le projet.

Une liste d’ingrédients peut être lisible et rester difficile à interpréter. Le nom commercial du produit n’explique pas sa composition, et une réponse générale ne tient pas compte de l’animal auquel il est destiné. VetSafe couvre ce besoin avec une application mobile pour chiens et chats, accompagnée d’un site de fiches et de conseils. J’ai assuré la conception du produit, le développement de l’application et la création de son site.

Deux parcours qui répondent à deux questions différentes

Le parcours de scan d’un aliment part de son étiquette. L’application en extrait la composition, présente les ingrédients et produit une évaluation. Un parcours distinct concerne les dangers : plantes, aliments du quotidien, produits et objets. Dans ce cas, la question porte sur un risque d’exposition, pas sur la qualité d’un produit alimentaire. Les produits de soin ont également leur propre traitement.

Cette distinction se retrouve dans les écrans et dans les services d’analyse. Une friandise, un repas complet et un produit de soin ne reçoivent pas le même traitement. Le catalogue des dangers distingue aussi les informations pour le chien et pour le chat : le modèle de données conserve séparément le niveau de risque, les symptômes et la conduite à tenir pour chaque espèce.

Lire l’étiquette, puis contrôler ce qui a été lu

VetSafe utilise Gemini pour lire et structurer les informations du produit. Les appels passent par des Cloud Functions Firebase, côté serveur. L’application reçoit des données structurées : ingrédients, informations sur le produit et, lorsqu’ils sont disponibles, constituants analytiques. Le texte source et l’origine de l’extraction sont conservés avec le produit pour permettre de reprendre une extraction après une amélioration du traitement.

Le code documente une difficulté précise : le modèle pouvait évoquer un ingrédient absent de la composition, puis construire une alerte à partir de cet ingrédient. Pour limiter ce problème, un filtre serveur confronte les éléments de l’analyse à la liste fournie. Il retire des ingrédients non corroborés et certaines affirmations sur des substances ou des additifs absents. Ce contrôle porte aussi sur les textes explicatifs.

Même cette vérification demande de l’attention. Une recherche par fragments de mots pouvait confondre « ail » et « volaille ». Le contrôle utilise donc des mots entiers pour rechercher les substances concernées. Le filtre réduit certains faux résultats ; il ne garantit pas que la photo ou la lecture initiale soient exactes. Lorsque l’extraction échoue, sa provenance permet à l’interface de signaler le problème plutôt que de présenter la liste de secours comme une lecture fiable.

Une note de composition et un avis pour l’animal

Dans la version du moteur examinée pour cette étude, la note de composition est calculée par des règles dans le code. Elle est séparée de l’avis concernant l’animal sélectionné. Le produit conserve ainsi une référence de qualité de composition, tandis que les informations de profil servent à examiner des incompatibilités ou des points de vigilance. La note n’est pas simplement un nombre demandé au modèle dans une réponse libre.

Le traitement distingue aussi une information manquante d’une information défavorable. Une composition qui n’a pas pu être suffisamment lue peut demander des données supplémentaires. Une friandise reçoit une indication précisant que sa note concerne les ingrédients et qu’elle n’est pas un repas complet. Pour un aliment diététique, l’interface distingue la qualité de composition de son intérêt pour une maladie. Cette séparation évite de faire porter à un seul score des conclusions qu’il ne mesure pas.

Conserver une analyse quand l’utilisateur change d’écran

Le résultat ne doit pas dépendre uniquement de l’écran qui a déclenché l’analyse. Le projet documente des problèmes d’historique : résultats perdus lors d’une réanalyse quittée en cours, écritures dans une ancienne entrée et doublons pour un même produit et un même animal. Ce sont des problèmes de cycle de vie et d’enregistrement, même si l’appel à l’IA a correctement répondu.

Le traitement des aliments a été regroupé dans un service commun. Pour une réanalyse, il enregistre un état d’attente, lance le traitement puis écrit le résultat ou l’échec dans l’historique. L’écran observe cette entrée au lieu de porter seul l’opération. La cause d’un échec est également enregistrée : un résultat en attente, une analyse échouée et une analyse terminée peuvent être distingués lors de la consultation.

Un catalogue disponible hors ligne et partagé avec le site

Le catalogue utilise Firestore pour les données distantes, un cache persistant avec AsyncStorage et une version embarquée dans l’application. Le chargement cherche les données disponibles et se replie sur le catalogue embarqué si les autres sources ne répondent pas. La consultation des fiches peut ainsi fonctionner hors connexion. Une nouvelle analyse par IA nécessite, elle, un accès au serveur.

Le chargement filtre les fiches masquées et rapproche les doublons. Cette étape s’applique également aux anciennes données en cache, afin qu’une fiche retirée ne réapparaisse pas simplement parce que le téléphone avait enregistré une ancienne liste. Le site récupère les données du catalogue lors de sa construction et génère des pages statiques. Une fiche web réunit les informations pour les deux espèces, avec des liens vers les catégories et les contenus associés.

Ce que le projet permet de montrer

Le projet associe React Native, Expo et TypeScript pour l’application, Firebase pour les services et les données, Gemini pour la lecture et l’analyse, et RevenueCat pour la gestion des accès payants. L’application est présentée sur l’App Store et Google Play ; son site permet également de consulter des fiches sans installer l’application.

L’intérêt de cette réalisation tient à la chaîne complète : lire une photo, vérifier une partie des informations produites, appliquer des règles, expliquer le résultat et le conserver. Le catalogue hors ligne complète cette chaîne pour les contenus déjà disponibles. VetSafe reste un outil d’information et ne remplace pas un avis vétérinaire. Ces choix décrivent le fonctionnement du projet ; ils ne constituent pas une mesure de précision clinique.

Pour voir d’autres réalisations, découvrez les applications et plateformes que j’ai développées. Si votre produit doit intégrer une lecture de documents ou de photos, un historique et des règles propres à votre métier, vous pouvez consulter ma prestation de développement mobile ou me décrire votre besoin.

Marie Dadomo

Développeuse indépendante à Angers. Huit ans de projets pour l’hôpital, les services de secours, l’aéronautique et l’assurance (CNP, Sodifrance), et trois applications publiées sur l’App Store et Google Play : Equio, VetSafe et Ellyo.

À lire ensuite