AlimCheck est une application Web de recherche et de comparaison de produits alimentaires.
Elle permet aux utilisateurs de rechercher un aliment par son nom, sa marque ou sa catégorie, puis de consulter et comparer ses caractéristiques selon plusieurs critères : ingrédients, valeurs nutritionnelles, allergènes, présence d'additifs, certification bio, information ou certification halal lorsqu'elle est disponible, régime vegan/végétarien, sans gluten, sans lactose, origine du produit ou encore certains critères environnementaux.
Nous avons choisi ce sujet car l'alimentation occupe une place importante dans la vie quotidienne et il est parfois difficile pour les consommateurs de trouver rapidement des informations fiables et compréhensibles sur les produits qu'ils achètent.
Aujourd'hui, lorsqu'une personne veut vérifier la composition d'un produit ou le comparer avec d'autres, elle doit souvent lire les étiquettes, consulter plusieurs sites ou utiliser différentes applications. Cela prend du temps et rend la comparaison moins simple.
AlimCheck a pour objectif de regrouper ces informations dans une seule application afin d'aider l'utilisateur à mieux comprendre les produits alimentaires et à faire un choix plus adapté à ses besoins.
L'utilité sociale d'AlimCheck repose sur plusieurs aspects :
- Meilleure information des consommateurs : l'application aide à mieux comprendre les produits alimentaires grâce à un accès plus simple aux ingrédients, aux nutriments et aux différentes caractéristiques.
- Aide à l'alimentation : elle permet d'identifier plus facilement certains produits selon des besoins particuliers, par exemple peu sucrés, riches en protéines, sans gluten ou sans lactose.
- Prise en compte des contraintes personnelles : chaque utilisateur peut filtrer les produits selon ses propres critères, comme la présence d'allergènes, le bio, le vegan ou l'information halal.
- Aide à la comparaison : l'application facilite la comparaison entre plusieurs produits sans devoir consulter plusieurs sources.
- Consommation plus réfléchie : en rendant les informations plus accessibles, AlimCheck encourage des choix plus informés.
Comme tout service numérique, AlimCheck présente des effets positifs mais aussi certaines limites qu'il faut prendre en compte.
L'application permet de regrouper dans un même espace plusieurs informations qui sont aujourd'hui dispersées entre les emballages, les sites des marques et d'autres plateformes.
Cela simplifie la recherche et permet à l'utilisateur d'accéder plus rapidement aux informations qui l'intéressent.
La numérisation rend plus simple la comparaison entre plusieurs produits.
Par exemple, un utilisateur peut comparer rapidement plusieurs aliments selon :
- la quantité de sucre ;
- la teneur en protéines ;
- les allergènes ;
- la présence d'additifs ;
- le caractère bio ;
- l'information ou la certification halal lorsqu'elle est disponible ;
- certains critères environnementaux.
Même si AlimCheck peut apporter une utilité réelle, son fonctionnement a lui aussi un impact environnemental.
L'application nécessite notamment :
- un hébergement ;
- une base de données ;
- des échanges de données ;
- l'utilisation d'un smartphone ou d'un ordinateur ;
- l'affichage d'images et d'informations ;
- éventuellement des traitements supplémentaires.
Le service doit donc rester simple, léger et limité aux fonctionnalités réellement utiles.
AlimCheck peut se substituer à certaines pratiques actuelles.
Aujourd'hui, un utilisateur peut :
- lire directement l'étiquette d'un produit ;
- consulter le site d'une marque ;
- utiliser un moteur de recherche ;
- consulter d'autres applications de comparaison ou d'analyse alimentaire.
AlimCheck pourrait rassembler une partie de ces démarches dans un seul outil.
Cependant, cette substitution n'est pas forcément totale. Si l'utilisateur continue à utiliser les autres sites ou applications en plus d'AlimCheck, alors le service ne remplace pas réellement les pratiques existantes : il s'y ajoute simplement.
AlimCheck peut également avoir un impact indirect sur les pratiques de consommation.
- aider l'utilisateur à mieux choisir selon ses besoins ;
- rendre les critères alimentaires plus visibles ;
- encourager une consommation plus informée ;
- faciliter la recherche de produits adaptés à certaines contraintes.
Comme la recherche devient plus facile, l'utilisateur pourrait être amené à consulter plus de produits qu'avant, à multiplier les comparaisons ou à passer plus de temps sur l'application.
Il existe également un risque si l'application met trop en avant de nouveaux produits ou de nombreuses alternatives : cela pourrait encourager une augmentation de la consommation au lieu de simplement aider au choix.
L'application devra donc éviter d'ajouter des fonctionnalités inutiles ou trop gourmandes en ressources et se concentrer sur l'essentiel.
AlimCheck ne doit pas décider à la place de l'utilisateur.
Son rôle est de fournir des informations claires et de permettre à chacun de choisir les critères qui lui semblent importants.
Par exemple, certains utilisateurs vont privilégier :
- le bio ;
- l'absence d'allergènes ;
- l'information halal ;
- les valeurs nutritionnelles ;
- l'origine du produit ;
- un critère environnemental.
L'application doit donc laisser une liberté de choix importante, rester compréhensible et signaler clairement lorsqu'une information n'est pas disponible.
Nous avons retenu deux scénarios représentant deux usages différents d'un service de recherche d'informations alimentaires.
Cas étudié : rechercher un produit connu, par exemple Nutella, afin de consulter sa composition et ses informations nutritionnelles.
- Rechercher Nutella par son nom ou sa marque.
- Sélectionner le produit dans les résultats.
- Consulter les ingrédients, les allergènes et les valeurs nutritionnelles.
- Revenir à la liste des résultats.
Cas étudié : rechercher une catégorie de produits, par exemple céréales, afin de comparer plusieurs produits selon leurs caractéristiques.
- Rechercher la catégorie céréales.
- Consulter la liste des produits proposés.
- Sélectionner un premier produit et consulter ses nutriments, ingrédients et labels/certifications disponibles.
- Revenir à la liste.
- Sélectionner un deuxième produit.
- Comparer les informations disponibles : sucre, protéines, ingrédients, allergènes, bio ou autres labels.
L'EcoIndex d'une page est calculé en fonction de plusieurs indicateurs, notamment :
- le nombre de requêtes lancées ;
- le poids des téléchargements ;
- le nombre d'éléments du document (DOM).
Nous avons choisi de comparer l'impact de nos scénarios sur deux services proposant des fonctionnalités proches d'AlimCheck : Open Food Facts et FatSecret.
| Service | Score EcoIndex moyen (sur 100) | Classe | Détail des mesures |
|---|---|---|---|
| Open Food Facts | 23,44 | F | Scénario 1 / Scénario 2 |
| FatSecret | 59,08 | C | Scénario 1 / Scénario 2 |
Tab. 1 : EcoIndex moyen obtenu par Open Food Facts et FatSecret sur les deux scénarios étudiés.
Les mesures montrent une différence importante entre les deux services étudiés.
FatSecret obtient un EcoIndex moyen de 59,08/100, contre seulement 23,44/100 pour Open Food Facts.
Dans le détail, Open Food Facts présente en moyenne davantage de requêtes, un DOM beaucoup plus complexe et des pages plus lourdes que FatSecret.
Open Food Facts compte environ 2239 éléments dans le DOM en moyenne, contre environ 445 éléments pour FatSecret.
Le nombre moyen de requêtes est également plus élevé pour Open Food Facts, avec environ 115 requêtes par page, contre environ 76 pour FatSecret.
Le poids moyen des pages est d'environ 1298 Ko pour Open Food Facts, contre environ 1049 Ko pour FatSecret.
Ces résultats montrent que la complexité du DOM, le nombre de requêtes et le poids des ressources ont une influence importante sur l'impact du service.
Pour la conception d'AlimCheck, nous chercherons donc à :
- limiter le nombre d'éléments présents dans les pages ;
- limiter les requêtes réseau inutiles ;
- réduire le poids des ressources téléchargées ;
- limiter le nombre d'images et optimiser leur taille ;
- privilégier des parcours courts.
L'objectif est de proposer un service plus sobre que les services existants étudiés.
Le modèle économique d'AlimCheck doit permettre de garantir la viabilité du service tout en restant cohérent avec notre objectif de sobriété numérique.
Le marché des services d'information alimentaire comporte plusieurs acteurs proposant des fonctionnalités proches : recherche de produits, informations nutritionnelles, ingrédients, allergènes ou comparaison entre produits.
Cependant, ces services sont différenciés. Certains sont davantage orientés vers la nutrition, d'autres vers la composition des produits ou le suivi alimentaire.
AlimCheck cherche à se différencier en regroupant dans une même application plusieurs critères de recherche : ingrédients, nutriments, allergènes, bio, certifications disponibles, préférences alimentaires et comparaison entre produits.
Il existe également plusieurs produits de substitution : l'utilisateur peut consulter directement l'étiquette d'un produit, utiliser un moteur de recherche ou consulter une autre application alimentaire.
Nous pouvons donc considérer qu'AlimCheck évolue dans un marché de concurrence monopolistique : plusieurs offreurs proposent des services proches mais différenciés.
Nous avons choisi un modèle économique freemium, complété éventuellement par des financements publics.
Le principe serait de conserver gratuitement les fonctionnalités essentielles afin que l'information alimentaire reste facilement accessible, tout en proposant certaines fonctionnalités avancées dans une offre Premium.
| Fonctionnalité | Utilisateur gratuit | Utilisateur Premium |
|---|---|---|
| Recherche par nom, marque ou catégorie | Oui | Oui |
| Consultation des ingrédients et nutriments | Oui | Oui |
| Consultation des allergènes et labels disponibles | Oui | Oui |
| Filtres avancés et multicritères | Limités | Oui |
| Comparaison avancée de plusieurs produits | Limitée | Oui |
| Sauvegarde des préférences | Non | Oui |
| Favoris et historique | Limités ou absents | Oui |
Le financement principal pourrait donc reposer sur les abonnements Premium.
Des subventions publiques pourraient également compléter ce financement, notamment dans le cadre de projets liés à l'information des consommateurs, à la transition numérique ou à la consommation responsable.
Nous ne souhaitons pas baser principalement AlimCheck sur la publicité.
Un modèle publicitaire pourrait encourager l'ajout de contenus, de traceurs et de ressources supplémentaires afin de capter davantage l'attention des utilisateurs, ce qui serait peu cohérent avec notre objectif de conception frugale.
Nous ne souhaitons pas non plus baser le modèle économique sur la vente des données personnelles des utilisateurs.
Notre modèle repose donc principalement sur :
- un accès gratuit aux fonctionnalités essentielles ;
- un abonnement Premium pour les fonctionnalités avancées ;
- éventuellement des subventions publiques.
Ce modèle permettrait de financer le développement, l'hébergement, la maintenance et les ressources humaines nécessaires au fonctionnement d'AlimCheck tout en limitant les fonctionnalités susceptibles d'augmenter inutilement son impact environnemental.
Au vu des services comparés, des scénarios retenus et des objectifs de sobriété définis précédemment, nous allons définir les principales ressources Web manipulées par AlimCheck.
L'application n'est pas pensée uniquement comme un ensemble de pages, mais comme un ensemble de ressources identifiées par des URI, pouvant disposer de différentes représentations et être reliées entre elles.
Les principales ressources de notre application sont :
| Ressource | Patron d'URI | Exemple |
|---|---|---|
| Collection de produits | /products |
/products |
| Produit alimentaire | /products/{id} |
/products/3017620425035 |
| Marque | /brands/{name} |
/brands/ferrero |
| Catégorie | /categories/{name} |
/categories/cereales |
| Ingrédient | /ingredients/{name} |
/ingredients/huile-de-palme |
| Label / certification | /labels/{name} |
/labels/bio |
La ressource principale est le produit alimentaire.
Nous utiliserons de préférence un identifiant stable, par exemple le code-barres du produit, pour construire son URI.
Exemple :
/products/3017620425035
Cette URI identifie le produit lui-même, indépendamment de la manière dont celui-ci est représenté à l'utilisateur.
La recherche correspond à une représentation filtrée de la collection de produits.
Par exemple :
/products?q=nutella
permet de rechercher les produits correspondant au terme Nutella.
D'autres critères peuvent être ajoutés sous forme de paramètres :
/products?category=cereales&bio=true
ou :
/products?q=chocolat&sans_gluten=true
Ces paramètres permettent de conserver des URI compréhensibles et directement liées aux critères sélectionnés par l'utilisateur.
Une même ressource pourra avoir plusieurs représentations.
Par exemple, un produit pourra être représenté :
- en
text/htmlpour l'affichage dans le navigateur ; - en
application/jsonpour l'accès structuré aux données.
La ressource :
/products/3017620425035
peut ainsi représenter le même produit sous forme d'une page HTML ou de données JSON.
La représentation HTML pourra afficher notamment :
- le nom du produit ;
- la marque ;
- éventuellement une image du produit ;
- les ingrédients ;
- les allergènes ;
- les valeurs nutritionnelles ;
- les labels disponibles ;
- les informations concernant le bio ou les certifications disponibles.
Lorsqu'une information n'est pas connue ou vérifiée, l'application indiquera qu'elle est non disponible, plutôt que d'en déduire automatiquement une valeur.
La représentation JSON contiendra ces informations sous une forme structurée.
Les représentations contiendront également des liens vers les autres ressources associées.
Par exemple, depuis la fiche d'un produit, l'utilisateur pourra accéder :
- à sa marque ;
- à sa catégorie ;
- à certains ingrédients ;
- aux labels associés ;
- à d'autres produits appartenant à la même catégorie.
Exemple :
/products/3017620425035
peut contenir des liens vers :
/brands/ferrero/categories/pates-a-tartiner/ingredients/noisettes
Ainsi, l'utilisateur peut naviguer d'une ressource à une autre sans devoir effectuer systématiquement une nouvelle recherche.
À partir de la maquette, nous avons identifié les principaux composants métiers réutilisables de l'application.
Nous retenons deux types de pages principales.
Cette page correspond à la recherche et à la consultation d'une liste de produits.
Elle est composée de :
AppHeader: en-tête commun de l'application ;SearchBar: recherche par nom, marque ou catégorie ;FilterPanel: sélection des différents critères de filtrage ;ProductList: affichage de la liste des produits correspondant à la recherche.
Cette page correspond à la consultation détaillée d'un produit.
Elle est composée de :
AppHeader: en-tête commun réutilisé ;Breadcrumb: navigation vers les ressources précédentes ;ProductContent: informations principales du produit ;RelatedProducts: produits similaires ou appartenant à la même catégorie.
Fig. 1 : Découpage de l'interface AlimCheck en composants React : (a) page de recherche et liste des produits ; (b) page de consultation d'un produit.
Afin de construire le prototype d'AlimCheck sans dépendre immédiatement d'une base de données externe, nous avons généré un échantillon de données avec dummy-json.
Le modèle contient les principales informations manipulées par l'application :
- produits ;
- marques ;
- catégories ;
- ingrédients ;
- allergènes ;
- valeurs nutritionnelles ;
- labels ;
- critères alimentaires.
L'échantillon contient plusieurs produits fictifs possédant une structure proche des données qui seront nécessaires au prototype.
Les données générées sont utilisées uniquement pour le développement et le test de l'interface. Elles ne doivent donc pas être considérées comme des informations réelles sur des produits existants.
Pour cette première version du prototype (v1.0.0), les données sont chargées
localement à partir de sample_data.json.
Les fonctionnalités implémentées sont volontairement limitées à celles nécessaires au scénario prioritaire :
- consulter la liste des produits ;
- sélectionner un produit ;
- consulter sa fiche détaillée ;
- revenir à la liste des produits.
Deux types de pages sont ainsi implémentés :
/products: page de liste des produits ;/products/{id}: page détaillée d'un produit.
La page /products affiche l'échantillon de produits sous une forme simple,
proche de la maquette définie précédemment.
Fig. 2 : Prototype de la page de liste des produits.
Dans un objectif de sobriété, nous utilisons PicoCSS et avons choisi de ne pas inclure d'images de produits dans cette première version.
Nous évitons également les publicités, les traceurs et les ressources tierces non nécessaires.
À ce stade, les données étant encore chargées statiquement, l'évaluation ne représente pas encore l'ensemble de l'impact d'une future application connectée à un backend.
Elle permet néanmoins d'évaluer l'impact de l'affichage des données et des ressources nécessaires au frontend.
Nous avons mesuré la page de liste des produits dans deux configurations : le mode de développement de Vite et le mode pré-production après génération du build.
| Mode | EcoIndex | GES (gCO2e) | Taille du DOM | Requêtes | Taille de la page (Ko) |
|---|---|---|---|---|---|
| Développement | 71,79 B | 1,56 | 203 | 20 | 5573 |
| Pré-production | 87,82 A | 1,24 | 199 | 4 | 100 |
Tab. 2 : Évaluation de l'impact du prototype de la page de liste des produits.
Le passage en pré-production améliore nettement les résultats.
L'EcoIndex passe de 71,79 (B) à 87,82 (A), tandis que le nombre de requêtes passe de 20 à 4.
La taille de la page diminue également fortement, de 5573 Ko à 100 Ko.
La taille du DOM reste presque identique, avec 203 éléments en développement contre 199 éléments en pré-production.
Cette différence s'explique principalement par l'optimisation des ressources effectuée lors de la construction de la version de production.
La page /products/{id} permet de consulter les informations détaillées
d'un produit sélectionné depuis la liste.
Elle affiche notamment :
- le nom du produit ;
- la marque et la catégorie ;
- les ingrédients ;
- les allergènes ;
- les valeurs nutritionnelles ;
- certaines caractéristiques alimentaires.
Fig. 3 : Prototype de la page détaillée d'un produit.
Un lien permet de revenir directement à la liste des produits, ce qui permet d'exécuter le parcours principal de navigation prévu dans cette première version du prototype.
Avec l'ajout de la page détaillée d'un produit et de la navigation entre les deux types de pages, il devient possible d'exécuter le scénario prioritaire complet et d'en mesurer l'impact.
Le scénario mesuré est le suivant :
- consulter la liste des produits ;
- choisir et consulter un premier produit ;
- revenir à la liste des produits ;
- choisir et consulter un autre produit.
| Étape du scénario | EcoIndex | GES (gCO2e) | Taille du DOM | Requêtes | Taille de la page (Ko) |
|---|---|---|---|---|---|
| 1. Consulter la liste des produits | 87,82 A | 1,24 | 199 | 4 | 100 |
| 2. Choisir et consulter un produit | 93,63 A | 1,13 | 53 | 4 | 100 |
| 3. Revenir à la liste des produits | 87,82 A | 1,24 | 199 | 4 | 100 |
| 4. Choisir et consulter un autre produit | 93,63 A | 1,13 | 53 | 4 | 100 |
Tab. 3 : Évaluation de l'impact du scénario prioritaire dans le prototype AlimCheck v1.0.0.
Les résultats obtenus sont globalement très bons puisque toutes les étapes du scénario sont classées A par EcoIndex.
La page de liste des produits obtient un EcoIndex de 87,82, avec 199 éléments dans le DOM, tandis que les pages détaillées obtiennent un EcoIndex de 93,63, avec seulement 53 éléments dans le DOM.
La différence entre les deux types de pages s'explique principalement par la complexité de l'interface. La liste doit afficher plusieurs produits simultanément, ce qui augmente le nombre d'éléments présents dans le DOM. À l'inverse, la fiche détaillée ne présente qu'un seul produit et possède donc une structure beaucoup plus légère.
Le nombre de requêtes reste stable à 4 pour chaque étape et la taille mesurée de la page reste de 100 Ko.
Les émissions estimées sont également légèrement plus faibles sur les pages de détail, avec 1,13 gCO2e, contre 1,24 gCO2e pour la liste des produits.
Ces résultats montrent que le prototype v1.0.0 reste relativement sobre pour l'ensemble du scénario prioritaire. Le choix d'une interface simple, sans images de produits, sans publicité et sans ressources tierces non nécessaires contribue à limiter son impact.