Jadi-Booti Solo : l’IA pour explorer les plantes

Une boucle d'usage tournée vers le terrain

Le parcours imaginé est volontairement direct :

1. Sortir dans un parc, un jardin, un quartier ou sur un chemin.
2. Repérer une plante qu'on ne connaît pas ou qu'on veut mieux observer.
3. La photographier (ou importer une image) pour obtenir une identification indicative.
4. Lire ou écouter quelques informations, puis comparer avec ce qu'on observe réellement.
5. Noter une observation ou garder un souvenir de la sortie.
6. Reprendre la promenade sans rester bloqué dans l'application.

Le point, c'est que l'app n'aspire pas l'attention : elle sert de déclencheur. Une application qui demande de consulter l'écran en continu risque d'aller contre son propre but. Ici, l'objectif est plutôt de proposer un prétexte utile à l'observation, puis de laisser la place à l'expérience.

À qui le projet peut-il servir ?

L'idée s'adresse à plusieurs profils : quelqu'un qui veut donner plus de relief à ses promenades du quotidien, un étudiant curieux d'explorer les abords de son campus, une famille en balade, ou un débutant qui veut apprendre à distinguer quelques plantes locales.

Évidemment, l'application ne remplace pas un guide botanique, un spécialiste ou une sortie encadrée. Elle peut surtout fonctionner comme un carnet de terrain assisté : donner une première piste, donner envie de vérifier, et garder une trace de ce qui a été observé.

Le positionnement se juge mieux à l'usage réel qu'à la liste des fonctionnalités. Le succès ne se mesure pas seulement au nombre d'identifications. Il dépend aussi de la qualité des observations que l'outil encourage et de sa capacité à ne pas monopoliser l'attention.

Identifier une plante à partir d'une image

L'utilisateur peut prendre une photo ou importer une image (feuille, écorce, fleur). Le projet prévoit d'analyser l'image avec le modèle de vision Llama 3.2 11B Vision, via l'infrastructure d'inférence Groq.

L'identification ne se limite pas au nom courant. La réponse peut inclure le nom botanique, un niveau de confiance, des caractéristiques visuelles, ainsi que des informations sur des usages traditionnels ou écologiques. Le projet prévoit aussi d'afficher clairement l'incertitude : l'IA donne une hypothèse, pas une certification.

Cette distinction compte vraiment. Une photo peut être floue, prise sous un mauvais angle, ou ne montrer qu'une partie de la plante. Des espèces peuvent se ressembler de près, et l'identification peut dépendre de détails que l'image ne révèle pas. L'utilisateur doit donc lire le résultat comme un point de départ à vérifier - surtout quand l'identification pourrait conduire à une décision concrète.

Même prudence pour les « usages » annoncés. Ces informations ne doivent pas être traitées comme un conseil médical, ni comme une autorisation de cueillir ou de consommer une plante. Une identification incertaine peut avoir des conséquences réelles. L'application devrait donc maintenir cette limite visible, plutôt que laisser une réponse bien présentée faire croire à une certitude.

Des quêtes pour donner une raison d'explorer

Jadi-Booti Solo propose des missions physiques, appelées « quêtes nature », pour orienter l'attention vers ce qu'on a autour de soi. L'exemple de la présentation du projet est le « Tri-Leaf Hunter », une mission qui invite à trouver un type de feuille. L'objectif est de transformer une promenade « comme d'habitude » en exploration légère.

Ce genre de mécanique peut aider quand on ne sait pas par où commencer. Une consigne simple - observer une forme, comparer des feuilles, repérer une plante - donne un sujet à la balade sans exiger de connaissances préalables. Reste que les missions doivent pouvoir s'adapter : une quête impossible dans un environnement urbain, ou hors saison, risque surtout de frustrer.

Le contenu local devient donc un point pratique, pas un détail éditorial. Une mission pertinente dans un parc peut être moins utile dans une rue résidentielle, ou dans une autre région. Des contributions sur les plantes locales, les saisons et les contextes de promenade rendraient cette partie plus convaincante.

Un journal pour conserver ses découvertes

Le journal de nature permet de sauvegarder des observations et des souvenirs de sortie. Le projet mentionne des notes vocales et des souvenirs liés à un lieu, en option. Il prévoit aussi des fonctions de narration audio, avec des lectures en hindi ou en anglais selon la description du dépôt.

Un journal change la façon d'utiliser l'application : on ne fait pas que recevoir une réponse sur le moment. On peut retrouver une observation et comparer ses promenades dans le temps. Par exemple, on peut noter la date, l'endroit, l'aspect de la plante, ou les conditions de la découverte. Cette mémoire reste utile même quand l'identification n'est pas totalement certaine.

La localisation, elle, impose une décision explicite. Associer un souvenir à un lieu peut enrichir le carnet, mais il faut comprendre ce qui est enregistré et pouvoir choisir de partager ou non. En France et dans l'Union européenne, la localisation peut être une donnée personnelle lorsqu'elle peut être reliée à une personne. L'option « simple » ne dispense donc pas d'expliquer ce qui est fait avec la donnée et de respecter le RGPD.

Le passage du poste local au déploiement

Le retour d'expérience associé au projet pointe cette difficulté : une fonctionnalité peut marcher sur l'ordinateur de développement et échouer une fois le site déployé, si le serveur, le frontend ou les paramètres d'accès ne sont pas correctement configurés. C'est un problème assez courant : une interface peut donner l'impression d'être « prête » alors que les appels à l'API, les variables de configuration ou le service externe ne répondent pas comme prévu en production.

Comme le projet dépend d'un service d'inférence, il faut aussi gérer la disponibilité du fournisseur, les délais de réponse, les erreurs réseau et le traitement des images. L'expérience ne se résume pas à « le modèle a répondu ». Il faut prévoir ce qu'il se passe quand l'image est trop lourde, quand la réponse tarde, ou quand le service est indisponible.

Le projet indique que la fiabilité de l'expérience déployée, notamment pour les fonctions d'IA, reste un chantier. Cette réserve est utile pour les personnes qui testent le dépôt : elle distingue une démo en cours de stabilisation d'un produit dont toutes les fonctions seraient garanties. Elle rappelle aussi qu'un prototype peut être intéressant sans prétendre être déjà « fini ».

L'IA doit rester une aide, pas une autorité

Un modèle de vision peut repérer des motifs et proposer une espèce probable. Mais il ne distingue pas toujours des plantes très proches à partir d'une photo unique, et la qualité dépend de l'image, du modèle et des données sur lesquelles il a été entraîné. Le score de confiance peut aider à rendre l'incertitude visible - sans pour autant en faire une preuve.

Dans une application de découverte, le bon usage consiste à rapprocher la réponse de l'observation : regarder les feuilles, la tige, les fleurs quand elles sont présentes, puis confronter avec une source botanique fiable. L'interface devrait éviter les formulations catégoriques quand il n'y a pas assez d'éléments.

La prudence doit être encore plus forte dès qu'on parle de comestibilité, de toxicité ou d'usage médicinal. L'application ne devrait pas encourager l'ingestion ou la manipulation sur la base d'une identification générée par IA. Une mention de sécurité visible, une réponse capable de reconnaître ses limites et des renvois vers des sources fiables valent mieux qu'une assurance « automatique ».

Une expérience qui doit fonctionner dehors

Le contexte d'usage impose des contraintes très concrètes. On peut utiliser l'application avec une forte luminosité, une connexion mobile instable, ou avec les mains occupées. Une interface adaptée devrait rendre les actions principales faciles à atteindre, limiter les saisies longues, et éviter de bloquer chaque étape du journal sur une connexion parfaite.

Les fonctions audio et les notes vocales peuvent aider à l'accessibilité et faciliter la prise de notes en promenade. Mais elles doivent être évaluées dans les conditions réelles : bruit ambiant, accents, langues prises en charge, et capacité à corriger une transcription erronée. Une fonction qui paraît pratique en démo peut vite devenir pénible si la correction prend plus de temps que la prise de note initiale.

Où les contributions peuvent avoir le plus d'impact

Pour Jadi-Booti Solo, les contributions les plus utiles ne sont pas forcément de nouvelles fonctions « visibles ». Elles peuvent surtout renforcer les fondations :

• Enrichir les informations sur des plantes présentes dans différentes régions.
• Documenter les sources et les limites des informations botaniques.
• Tester les parcours sur des téléphones et avec des connexions variés.
• Améliorer l'accessibilité de l'interface et des contenus audio.
• Rendre les erreurs de l'API compréhensibles et plus faciles à rattraper.
• Proposer des quêtes réalisables en ville comme à la campagne.
• Clarifier la gestion des images, des notes et des données de localisation.

Ces chantiers se tiennent. Ajouter des plantes sans documenter la qualité des données risque d'augmenter le volume sans améliorer la fiabilité. Ajouter une fonction de localisation sans choix clairs sur la confidentialité peut faire chuter la confiance. Une contribution vaut surtout par le problème concret qu'elle résout.

Tester le projet avec des attentes réalistes

Le dépôt GitHub est accessible à l'adresse AKSA119/jadi-booti-solo. Le code source mentionne une démonstration en ligne, mais sans fournir son adresse ; mieux vaut donc consulter le dépôt pour trouver les instructions à jour plutôt que de supposer qu'une URL de démo existe toujours.

Avant de tester une identification, il est utile de vérifier si la fonction marche dans la version déployée et de garder en tête que les réponses restent indicatives. Pour contribuer, on gagnera souvent du temps en commençant par lire les instructions du dépôt, reproduire un problème, puis décrire précisément les conditions : appareil, navigateur, étape suivie et résultat attendu.

Cette démarche évite de confondre une piste intéressante avec une fonctionnalité déjà stabilisée. Elle aide aussi les mainteneurs avec des retours exploitables. Dans un projet ouvert, un rapport clair sur un échec d'intégration peut valoir plus qu'une idée générale du type « ajoutons encore plus d'IA ».