Un carnet alimentaire qui part d'une photo de l'assiette

Ce brief a été distribué à l'édition 08, le lundi 21 septembre 2026. Prenez deux heures et l'outil de votre choix, commencez par le Socle, puis lisez le compte rendu de la soirée pour voir ce que les autres en ont fait.

La situation

Nadia sort de chez le médecin avec une consigne simple et une application qu'elle a déjà désinstallée deux fois.

« On m'a demandé de noter ce que je mange pendant un mois. J'ai essayé, sincèrement. Le problème c'est qu'à midi je suis dehors, j'ai un plat devant moi, et pour le noter il faut que je tape « salade de lentilles », qu'on me propose quarante résultats, que je devine si c'est la bonne marque, que je dise combien il y en a en grammes. Je ne sais pas combien pèse mon assiette. Personne ne le sait. »

« Ce que je voudrais, c'est prendre la photo et passer à autre chose. Que ça reconnaisse, que ça note, et que je corrige quand c'est à côté. Et surtout, je veux savoir d'où sortent les chiffres. Si votre truc me dit 600 calories, je veux pouvoir cliquer et voir que ça vient de quelque part, pas d'une intuition d'ordinateur. Quitte à ce qu'il me dise qu'il n'a rien trouvé, ça je peux le comprendre. »

C'est le besoin. À toi de le faire exister.

L'esprit de l'exercice

Noter ce qu'on mange, tout le monde abandonne au bout de quatre jours. Pas par manque de volonté : parce qu'il faut ouvrir une application, chercher « poulet », choisir entre quarante-deux résultats dont on ne sait rien, saisir un poids qu'on ne connaît pas, recommencer pour l'accompagnement. Une photo prend deux secondes. Un modèle vision sait dire ce qu'il y a dessus. Mais il ne sait pas combien de calories il y a dedans, et il vous le dira quand même si vous le lui demandez. Tout l'exercice de ce soir tient dans cette frontière : le modèle reconnaît, la base de données chiffre.

Un brief volontairement sous-spécifié

Ce brief décrit ce que l'application doit faire, jamais comment le faire. Aucune architecture imposée, aucune maquette, aucun format de réponse, aucun prompt fourni. Web, mobile, terminal : peu importe. Partout où une décision se présente, elle t'appartient. Un brief trop précis devient un prompt prêt à coller, et l'exercice perd tout son intérêt.

Un chiffre faux est pire que pas de chiffre

On n'a pas tous le même bagage : trois paliers attendus, un bonus hors session. Le premier suffit à repartir avec quelque chose d'utilisable. Mais ici, une application qui affiche 420 kcal avec aplomb quand elle n'en sait rien est plus nuisible qu'une application qui affiche « je ne sais pas ». Ne cours pas après le palier 3 si le socle raconte n'importe quoi.

Avant de commencer

Ce soir, l'application lit des photos : il faut un modèle vision, et donc une clé. Elle est gratuite et se crée en cinq minutes. Chacun crée la sienne. Ce n'est pas une formalité : les quotas Groq s'appliquent par compte, pas par machine ni par adresse IP. Une clé unique partagée par la salle, et tout le monde se retrouve à se disputer trois photos par minute. Faites-le maintenant, avant même de lire le sujet.

1. Ouvrir console.groq.com et créer un compte. Un compte Google ou GitHub suffit, un compte créé sur place fonctionne aussi.
2. Aller dans API Keys, puis Create API key. Lui donner un nom quelconque.
3. Copier la clé tout de suite : elle commence par gsk_ et ne sera plus affichée en entier ensuite.
4. La tester avec la commande ci-dessous qui correspond à votre système. Elle liste les modèles du compte et ne consomme aucun token.
5. Dans la réponse, repérer les modèles dont le champ input_modalities contient "image". Ce sont les seuls qui acceptent une photo. Au 21/09 il n'y en a qu'un, qwen/qwen3.8-27b. Si la liste est vide ou si le JSON contient une erreur : lever la main, plutôt que d'attaquer le sujet avec une clé morte.

Remplacer VOTRE_CLE par la clé qui vient d'être créée.

macOS / Linux — Terminal

curl -s https://api.groq.com/openai/v1/models \
  -H "Authorization: Bearer VOTRE_CLE"

Windows — PowerShell

$key = "VOTRE_CLE"
Invoke-RestMethod -Uri "https://api.groq.com/openai/v1/models" -Headers @{ Authorization = "Bearer $key" } |
  Select-Object -ExpandProperty data |
  Where-Object { $_.input_modalities -contains "image" } |
  Select-Object id

Ce qu'il faut savoir

Le modèle

qwen/qwen3.8-27b, le seul du compte qui accepte une image. Ne pas se fier à un identifiant trouvé dans un article : la liste des modèles change, et l'API la donne.

La vraie limite

7000 tokens d'entrée par minute et par compte. C'est elle qui bloque, pas les 1000 requêtes par jour affichées à côté.

L'en-tête ment

Groq renvoie x-ratelimit-limit-tokens: 8000, mais le refus tombe à 7000 tokens d'entrée. Aucun en-tête n'annonce ce seuil. Le message du 429 est le seul endroit où il apparaît.

Le coût d'une photo

Une image de 512 pixels de côté consomme entre 1650 et 2160 tokens d'entrée. Soit trois photos par minute, pas plus. Mesuré le 21/09 sur huit images.

Redimensionner

512 pixels sur le plus grand côté suffisent pour reconnaître un plat. Envoyer l'original d'un téléphone multiplie le coût en tokens sans rien améliorer, et fait tomber le quota d'un coup.

Du JSON, sans garantie

Le modèle accepte response_format json_object, mais pas de schéma imposé : il n'y a pas de structured_outputs. Le JSON revient bien formé, ce qu'il contient reste à vérifier.

La confiance est décorative

Sur huit photos de test, le modèle a répondu « confiance haute » huit fois, y compris en lisant une poutine comme des « frites au fromage et sauce BBQ ». Ne construisez rien sur ce champ.

Sous Windows

Ne pas taper « curl » dans PowerShell : c'est un alias d'Invoke-WebRequest, qui ne comprend pas les options de curl et renvoie une erreur trompeuse. Le « \ » de fin de ligne n'existe pas non plus. D'où la variante ci-dessus.

Les grosses images

En Python, urllib et requests peuvent fermer la connexion en cours d'envoi sur une image de plusieurs centaines de kilo-octets : « Broken pipe », sans code HTTP. Redimensionner règle le problème dans la plupart des cas.

Après la session

La clé reste valable sans limite de durée. Ce qui est construit ce soir continue de tourner chez vous demain.

Un seul métier : transformer une photo en ligne de carnet, sans jamais inventer une valeur nutritionnelle. La promesse est étroite, et c'est ce qui la rend tenable en deux heures. Ce qui se durcit d'un palier à l'autre, c'est l'honnêteté du produit quand il ne sait pas.

Palier 1 · Socle

Attendu de tous

À la fin de ce palier, Nadia photographie son assiette et voit apparaître ce que c'est, avec des valeurs nutritionnelles dont elle peut remonter la source. Y compris quand la source n'existe pas.

Ce que l'application doit faire

• Partir d'une photo. Une photo prise sur le moment ou choisie dans la pellicule, et c'est tout. Pas de formulaire à remplir avant, pas de catégorie à choisir, pas de nom à taper pour amorcer la recherche.
• Dire ce que c'est, en français. Le modèle rend un nom lisible, et dit s'il regarde un plat cuisiné ou un produit dans son emballage. Les deux ne se traitent pas de la même façon par la suite.
• Aller chercher les chiffres ailleurs. Les valeurs nutritionnelles viennent d'Open Food Facts, une base publique et gratuite. Le modèle sert à reconnaître, jamais à chiffrer. C'est la règle qui structure toute la soirée.
• Montrer d'où vient le chiffre. Chaque valeur affichée renvoie au produit de la base dont elle est tirée. Nadia doit pouvoir vérifier que les 380 kcal qu'elle lit correspondent bien à quelque chose, et à quoi.
• Savoir ne rien trouver. Une photo sans nourriture, un plat introuvable dans la base, une recherche qui ne ramène rien d'approchant : chacun de ces cas a sa réponse, et aucune ne consiste à afficher un chiffre plausible.

Les règles

Aucun chiffre du modèle

Pas une calorie, pas un gramme de protéines ne sort du modèle vision. S'il en propose spontanément, ces valeurs sont jetées. Tout ce qui est chiffré vient de la base.

La photo sans nourriture

Une photo de chien, de facture ou de salle de réunion se solde par « ce n'est pas un repas ». L'application ne fabrique pas un aliment pour avoir l'air de fonctionner. Test de la soirée : photographier son clavier.

Le rien-trouvé

Si la base ne renvoie aucun résultat exploitable, l'application le dit et s'arrête là. Un plat reconnu sans valeurs est une réponse honnête ; un plat reconnu avec des valeurs inventées est un bug grave.

La confiance ne prouve rien

Le modèle annonce sa confiance et elle est presque toujours haute, même quand il se trompe. Ce champ ne sert pas à décider d'afficher ou non un résultat.

Le nom long ne cherche rien

« Escalope de dinde panée, haricots verts et galettes de pommes de terre » ne ramène aucun résultat dans Open Food Facts, qui indexe des noms de produits, pas des descriptions d'assiettes. Ce qui est envoyé à la base n'est pas forcément ce qui est montré à Nadia.

Le quota

Trois photos par minute et par compte. L'application ne part pas dans une rafale d'appels, et si elle se prend un refus, elle le dit et propose de réessayer plutôt que de boucler en silence.

Le poids de l'image

Une photo de téléphone n'est pas envoyée telle quelle. Elle est réduite avant l'appel, et ce qui est envoyé reste sous le seuil qui ferait sauter le quota d'un seul coup.

L'attente

La reconnaissance prend une seconde, la recherche dans la base parfois plus. Nadia voit que quelque chose tourne, et rien ne reste dans un état bancal si elle ferme l'écran en cours de route.

La panne

Clé absente, quota dépassé, base injoignable, JSON illisible : chacun a son message et sa suite. « Une erreur est survenue » ne renseigne personne.

La clé

La clé appartient au participant et ne quitte pas sa machine. Ni dans un dépôt, ni dans une page publiée, ni dans une capture d'écran de démonstration.

Le plat composé

À TRANCHER (participant) : une assiette avec une viande, un féculent et un légume, c'est une ligne de carnet ou trois ? Une seule ligne est simple à lire mais introuvable telle quelle dans la base. Trois lignes collent mieux aux données mais demandent à Nadia de valider trois fois. Les deux se défendent ; le choix se voit dans tout le produit.

Palier 2 · Avancé

Du plat au carnet

Une photo isolée ne sert à rien : ce qu'on a demandé à Nadia, c'est un mois de relevés. L'application cesse d'être une curiosité et devient un carnet, avec ce que ça implique de corrections et de totaux.

Ce que l'application doit faire

• Enregistrer un repas. Ce qui vient d'être reconnu rejoint le journal du jour, daté, et reste consultable ensuite. Nadia doit pouvoir rouvrir son lundi le jeudi suivant.
• Corriger ce que le modèle a dit. Le modèle se trompe régulièrement, et Nadia sait ce qu'elle a mangé. Elle doit pouvoir rectifier le nom, changer de produit, ou écarter une ligne, sans repasser par la photo.
• Poser une quantité. Les valeurs de la base sont données pour 100 grammes. Le carnet parle d'assiettes. Le passage de l'un à l'autre est visible et modifiable par Nadia, jamais enfoui dans un calcul.
• Totaliser la journée. Un total par jour, sur les repas qui ont des valeurs réelles. C'est le chiffre que Nadia montrera à son médecin, et il doit pouvoir se justifier ligne par ligne.
• Reconnaître un plat déjà noté. Nadia mange souvent la même chose. Un plat déjà identifié et corrigé une fois se retrouve sans repayer un appel au modèle.

Les règles

La correction prime

Une valeur corrigée par Nadia ne se fait jamais réécrire par une nouvelle reconnaissance. Elle a toujours raison contre le modèle, sans exception.

Le total ne se fabrique pas

Seules les lignes qui portent des valeurs réelles entrent dans le total. Une ligne sans valeurs n'est pas comptée pour zéro : elle est comptée nulle part, et le total dit qu'il est partiel.

Ce qui manque reste visible

Un repas sans valeurs nutritionnelles reste dans le carnet, avec sa photo et son nom. Le faire disparaître parce qu'il n'est pas chiffrable, c'est perdre l'information la plus utile au médecin.

La quantité est une hypothèse

Un poids estimé se présente comme estimé, pas comme mesuré. Nadia doit voir en un coup d'œil ce qu'elle a confirmé et ce que l'application a supposé pour elle.

Le coût

Rouvrir son carnet, corriger une ligne, consulter un total : rien de tout cela ne rappelle le modèle. On paye pour reconnaître une photo, pas pour relire ce qui est déjà écrit.

La journée

Un repas appartient à un jour, et le changement de jour est explicite. Une photo prise à minuit vingt ne doit pas atterrir au hasard d'un côté ou de l'autre.

Qui estime les grammes

À TRANCHER (participant) : le poids d'une portion, c'est le modèle qui le devine, Nadia qui le saisit, ou une portion type par catégorie d'aliment ? Le modèle est rapide et faux, la saisie est juste et pénible, la portion type est un compromis que personne ne vérifie. Choisis, et assume-le jusque dans l'affichage du total.

Palier 3 · Poussé

Décisions produit & cas limites

Le chemin par le nom est le maillon faible : il ramène des milliers de résultats sans rapport, ou aucun. Il existe un chemin exact, et il passe par le code-barres. Ce palier consiste à préférer ce qui est sûr, et à montrer le doute quand il n'y a rien de sûr.

Ce que l'application doit faire

• Lire un code-barres. Sur un produit emballé, le code-barres donne une réponse exacte, immédiate, sans ambiguïté de marque ni de recette. Partout où il est lisible, il prend le pas sur la recherche par nom.
• Assumer le doute. Quand le modèle hésite entre plusieurs plats, ou quand la base renvoie plusieurs produits également plausibles, Nadia choisit. L'application ne tranche pas à sa place en silence.
• Montrer l'écart. Cinq résultats pour « frites » vont de 333 à 528 kcal aux 100 grammes. Cet écart est une information : il dit à Nadia si la valeur affichée est solide ou approximative.
• Séparer les deux mondes. Un produit industriel se retrouve à l'identique dans la base. Un plat cuisiné n'y est jamais, au mieux une recette approchante. Les deux ne s'affichent pas avec le même degré de certitude.

Les règles

Le code-barres prime

Quand un code-barres est lu et trouvé, c'est lui qui fait foi. Le nom rendu par le modèle devient une information secondaire, et ne contredit pas le produit trouvé.

Pas de code inventé

Un code-barres flou, tronqué ou reconstitué est un code absent. Un modèle qui complète un chiffre manquant renvoie vers un tout autre produit, avec un aplomb parfait.

Le premier résultat n'est pas la réponse

La base classe par pertinence textuelle, pas par justesse. Prendre le premier résultat sans le montrer à Nadia, c'est afficher du Pringles quand elle a photographié des frites maison.

L'écart se montre

Quand les candidats plausibles s'écartent fortement en valeurs, Nadia le voit. Une fourchette honnête vaut mieux qu'un chiffre unique faussement précis.

Le plat cuisiné est une estimation

Une assiette maison ne correspond à aucune entrée exacte de la base. Ce qui est affiché pour elle est signalé comme une approximation, et ne se présente pas comme un relevé.

Deux fois la même photo

La même photo envoyée deux fois donne deux formulations différentes du même plat. Le produit retenu, lui, ne doit pas changer d'une fois à l'autre sans raison visible.

Le refus de quota

Un 429 en pleine session ne perd pas la photo de Nadia. Elle est conservée, et la reconnaissance reprend quand le quota le permet.

Quand rien ne colle

À TRANCHER (participant) : la base renvoie huit mille résultats et aucun ne correspond vraiment. Que voit Nadia ? Les cinq premiers avec leur écart, une invitation à préciser sa recherche, ou un aveu d'échec assumé ? Le pire est de choisir pour elle sans le dire.

Bonus

Hors session — aucune attente

Un réservoir d'ambition pour qui aurait solidifié le reste : l'export du carnet en un document présentable au médecin, avec les photos ; la reconnaissance de plusieurs aliments distincts sur une même photo, chacun avec sa ligne ; le mode hors ligne, où les photos s'accumulent et se font reconnaître quand le réseau revient ; la contribution en retour à Open Food Facts quand Nadia a corrigé une fiche incomplète. À ne pas attaquer avant d'avoir consolidé le reste.

Et deux questions à garder pour la discussion de fin. Où passent les photos — ce soir ce sont des assiettes envoyées à un service américain gratuit, donc aucun enjeu ; demain, un carnet alimentaire est une donnée de santé, et la question change complètement de nature. L'utile et le juste — une application qui refuse de chiffrer ce qu'elle ne connaît pas est honnête, mais un carnet à moitié vide finit désinstallé comme les précédents. Où place-t-on le curseur entre ne jamais mentir et rester utilisable ?