IA locale ⚡ TouchGrass AI : sortez (éthique) !
Découvrez TouchGrass AI : IA locale et intelligence artificielle locale qui convertit vos idées en missions pour sortir, en IA open source et éthique. Testez !
TouchGrass AI : quand l'IA nous aide à quitter les écrans
On présente souvent l'intelligence artificielle comme un moyen de faire davantage sur un écran : écrire, chercher, planifier, créer. TouchGrass AI part d'une idée différente : et si une IA aidait surtout à passer moins de temps en ligne - et à sortir davantage ? Le projet transforme ce qui intéresse une personne, son temps libre et son niveau d'énergie en une mission simple à faire dehors.
L'application est open source et a été développée pour le défi Hacktoberfest Open-Source AI Challenge. Elle s'appuie sur un modèle exécuté localement, plutôt que sur un service d'IA distant. L'objectif est clair, mais la question reste la même pour n'importe quel produit qui intègre un modèle : qu'est-ce qu'on confie vraiment à l'IA ? Comment éviter qu'une réponse imprévisible ne casse l'expérience ? Et, surtout, qu'est-ce qu'on gagne - ou qu'est-ce qu'on perd - quand on traite les demandes sur l'appareil de l'utilisateur ?
TouchGrass AI n'est pas une « preuve » que l'IA résout le temps d'écran. Son intérêt est ailleurs : montrer, de façon concrète, comment un modèle local peut soutenir une expérience qui pousse à s'éloigner de la technologie.
Une IA qui propose une action plutôt qu'un nouveau fil à consulter
TouchGrass AI prend le contre-pied d'un réflexe devenu courant : demander à un assistant de nous garder plus longtemps dans le numérique. L'application demande à l'utilisateur ce qui l'intéresse, le temps dont il dispose et son niveau d'énergie. Ensuite, elle génère une mission extérieure, avec des étapes concrètes.
Les activités proposées vont de la marche et de la découverte d'un lieu proche à la (petite) séance de jardinage, l'observation des oiseaux, la photographie en plein air ou un moment pour se détendre. L'idée n'est pas de prescrire une performance sportive ni d'imposer un programme. Elle vise surtout à réduire le poids mental du démarrage : au lieu de se demander quoi faire, l'utilisateur reçoit une proposition adaptée à sa situation.
Transformer une intention vague en consigne réalisable
« Sortir davantage » reste une intention. Un bon « brief » pour une mission doit répondre à des questions très concrètes : quoi faire, combien de temps, avec quel niveau d'effort. Une suggestion du type « partez marcher » peut rester trop ouverte. Une consigne ajustée au temps disponible et à l'énergie rend l'action bien plus probable.
Le modèle de langage peut aider sur ce point : reformuler des préférences en consignes utilisables et varier les propositions. Mais l'IA ne remplace pas tout le travail de produit. Le formulaire doit rester simple pour ne pas faire fuir l'utilisateur, tout en fournissant assez de contexte pour que la mission ait du sens.
Cette tension, on la retrouve dans beaucoup d'applications. Plus on ajoute de champs, plus on améliore la personnalisation - mais plus on risque aussi d'abandonner. Et si l'objectif est d'aider à sortir, une configuration longue est déjà un mauvais signal. La valeur dépend autant de la sobriété de l'interface que de ce que le modèle arrive à produire.
Un cas d'usage modeste, donc mesurable
Le projet ne prétend pas réduire le temps d'écran ni améliorer la santé. Les informations disponibles indiquent surtout une application qui génère des idées de sorties : pas d'étude d'impact auprès d'utilisateurs. Cette distinction compte. Une intention de conception n'est pas, en elle-même, un résultat prouvé.
Pour évaluer le produit, il faut regarder des indicateurs liés à l'usage réel : les missions sont-elles comprises ? Les utilisateurs les font-ils ? Les propositions leur paraissent-elles pertinentes ? Reviennent-ils parce que l'appli les aide vraiment, ou seulement parce qu'elle ajoute encore une habitude « écran » ? Ces questions sont, à mon avis, plus utiles qu'un simple décompte des sorties générées.
Cela dit, l'approche intéresse les équipes produit. Elle montre qu'on peut concevoir un usage de l'IA autour d'une action hors ligne, plutôt que d'une interaction numérique qui s'étire. Pour les services qui cherchent une valeur concrète sans pousser l'utilisateur à rester dans l'app, c'est une piste.
Comment fonctionne TouchGrass AI
L'application repose sur une architecture plutôt lisible : React, TypeScript et Vite pour l'interface ; Python et FastAPI côté serveur ; puis Ollama pour exécuter le modèle Qwen2.5 1.5B en local. Elle est aussi pensée comme une PWA, donc une application web progressive installable sur des appareils compatibles.
Le choix de cette pile technique suit un objectif pratique : proposer quelque chose de léger et permettre l'inférence sans dépendre, à chaque requête, d'une API hébergée. Ce n'est pas la seule architecture possible, ni forcément la plus simple à déployer pour tout le monde. Mais c'est un compromis cohérent avec le cadre de l'expérimentation.
Du formulaire à la mission
Le parcours tient en quatre étapes :
- L'utilisateur choisit ses centres d'intérêt et indique le temps dont il dispose.
- L'interface envoie ces préférences au backend FastAPI.
- Le backend prépare une requête pour le modèle local, exécuté par Ollama.
- L'application affiche la mission générée sous une forme exploitable.
Le découpage entre interface, backend et modèle a un avantage : le traitement de la réponse ne dépend pas uniquement du navigateur. Le serveur peut valider le résultat et prévoir un comportement de repli si la sortie est invalide ou si l'inférence échoue.
Ce point compte. Un modèle de langage ne fournit pas, à chaque appel, une réponse structurée « fiable » juste parce qu'on lui demande de respecter un format. Dans une app grand public, une erreur brute ou un écran vide devient vite un problème de confiance, pas un simple souci technique.
Le mode de secours fait partie du produit
TouchGrass AI prévoit des missions prédéfinies si la réponse est invalide ou si la connexion au modèle échoue. Concrètement, ça rend le parcours moins fragile : l'utilisateur a quand même une suggestion, même quand la génération ne se passe pas comme prévu.
Il y a un compromis : la proposition prédéfinie sera parfois moins personnalisée que celle produite par le modèle. Mais une réponse déterministe et compréhensible vaut souvent mieux qu'une fonctionnalité « intelligente » qui échoue sans explication. En production, la vraie question n'est pas seulement « est-ce que le modèle marche ? », mais « que voit l'utilisateur quand il ne marche pas ? ».
Les tests mentionnés couvrent les contrôles de santé du service, la validation des requêtes, les réponses locales, les sorties invalides et les échecs de connexion. Le projet indique que les six tests backend ont réussi et que la compilation de production du frontend a abouti. C'est une vérification utile du fonctionnement technique, sans pour autant mesurer la qualité des missions ou la satisfaction des utilisateurs.
Hors ligne ne veut pas dire sans préparation
L'application a été vérifiée sans connexion Internet après le téléchargement du modèle. Cette précision évite une confusion fréquente avec les applis locales et les PWA : être « hors ligne » ne veut pas dire que tout se déclenche sans rien avoir fait avant.
Il faut d'abord avoir téléchargé le modèle (il prend de la place), puis avoir chargé ou installé l'application. Une fois ces conditions réunies, la génération locale peut fonctionner sans réseau. C'est utile quand le réseau est indisponible, mais ça dépend de l'appareil, de sa capacité de calcul, et de la configuration choisie.
Ce que l'IA locale apporte - et ce qu'elle coûte
Exécuter l'inférence localement change l'endroit où se fait le calcul. Quand la génération se fait sur l'appareil de l'utilisateur, il n'est pas nécessaire de transmettre les préférences à un fournisseur distant à chaque requête. C'est un avantage possible pour la confidentialité. Mais il ne faut pas en faire une promesse « automatique » : le comportement dépend de l'architecture complète - notamment de la collecte de données, des journaux, des mises à jour et des services utilisés autour du modèle.
Pour un public européen, cette nuance est importante. La conformité RGPD ne vient pas du seul fait que le modèle est local. Elle dépend des données traitées, de la finalité, de la durée de conservation et des responsabilités des acteurs. Le traitement local peut limiter certains transferts, mais il ne dispense pas de documenter les flux et de concevoir une expérience respectueuse de la vie privée.
Confidentialité et maîtrise technique
Le dépôt ouvert permet d'inspecter le backend, de modifier les instructions envoyées au modèle et d'expérimenter avec d'autres modèles ou outils d'inférence. Cette transparence donne une marge de contrôle aux développeurs et aux contributeurs. Elle aide aussi à comprendre les choix techniques, à condition que le code et la documentation soient assez clairs.
L'ouverture du code ne garantit pas, à elle seule, la sécurité ou la protection des données. Elle rend l'examen possible ; elle ne prouve pas que chaque utilisateur ou organisation a réellement fait cet examen. Pour un déploiement professionnel, il faudrait aussi vérifier la journalisation, l'exposition du service, les dépendances et les conditions de distribution du modèle utilisé.
Ressources, rapidité et qualité variable
L'IA locale a un coût opérationnel différent, pas un coût nul. Il faut stocker le modèle et l'exécuter sur un appareil qui dispose de ressources suffisantes. La vitesse de génération et la qualité des réponses peuvent varier selon le matériel. Un modèle plus léger allège certaines contraintes, mais il ne supprime ni les limites de raisonnement ni les erreurs possibles.
Le choix de Qwen2.5 1.5B vise la légèreté. Mais on ne peut pas en conclure que ce modèle conviendra à tous les appareils ou à tous les cas d'usage. Une équipe doit tester avec les équipements réellement visés : un PC récent, un appareil modeste ou un environnement pro administré n'ont pas les mêmes contraintes.
En pratique, le choix entre inférence locale et service distant dépend de plusieurs paramètres : sensibilité des données, budget d'infrastructure, parc matériel, latence acceptable, qualité attendue et capacité de maintenance. Pour un usage simple et peu sensible, un service hébergé peut être plus facile à exploiter. Pour un besoin de contrôle plus fort ou un fonctionnement sans réseau, l'exécution locale mérite d'être évaluée. Le « bon » choix est celui qui tient dans les conditions réelles d'utilisation.
Les enseignements pour concevoir un produit fiable
TouchGrass AI reste une expérimentation, mais plusieurs décisions de conception peuvent être reprises dans d'autres produits intégrant des modèles. L'enjeu n'est pas tant le choix du fournisseur que la façon d'encadrer une technologie probabiliste dans un parcours utilisateur.
Partir du problème, pas du modèle
La question de départ n'est pas : « on a un modèle, qu'est-ce qu'on peut lui faire générer ? ». Il y a une friction plus simple : une personne veut sortir, mais elle ne sait pas toujours quoi faire ni comment adapter l'activité à son temps et à son énergie. Le modèle intervient à ce moment précis.
Cette approche réduit le risque de greffer une fonctionnalité « IA » sans raison fonctionnelle. Avant d'ajouter un modèle, une équipe peut se poser ces trois questions :
- Quelle décision ou quelle tâche est difficile pour l'utilisateur ?
- Est-ce qu'une génération apporte vraiment un mieux à cette étape, par rapport à des règles ou à des suggestions déjà éditorialisées ?
- Que se passe-t-il si le modèle est lent, indisponible ou incorrect ?
Si une logique simple suffit, elle sera souvent plus rapide, moins coûteuse et plus prévisible. L'IA se justifie quand la variation ou l'adaptation apporte une valeur que les mécanismes classiques ne donnent pas - et à un coût raisonnable.
Concevoir l'échec avant le lancement
Le mécanisme de secours est une règle d'ingénierie : si une fonctionnalité dépend d'un modèle, elle doit dire quoi faire en cas d'échec. Cela concerne les délais dépassés, les réponses incomplètes, les contenus inadaptés et les appareils trop faibles.
Une stratégie minimale peut prévoir : validation des entrées, vérification de la sortie, délai maximal, message d'erreur compréhensible, puis solution de repli. Les tests devraient couvrir ces cas, pas uniquement le « chemin heureux ». C'est souvent dans ces scénarios qu'on découvre si l'IA a été intégrée au produit, ou juste ajoutée à côté.
Mesurer l'utilité plutôt que l'activité « IA »
Un volume élevé de générations ne prouve pas forcément que l'app aide. Pour TouchGrass AI, une évaluation utile porterait sur la pertinence des missions et sur leur réalisation, tout en évitant de collecter plus de données que nécessaire. Un retour volontaire sur l'intérêt d'une proposition sera souvent plus informatif qu'un suivi détaillé des déplacements ou des habitudes personnelles.
Toutes les fonctionnalités évoquées - météo et localisation, historique des missions, suivi de progression, choix de modèles et retours utilisateurs - n'ont pas le même niveau de risque ni le même coût. Par exemple, la localisation peut rendre la suggestion plus contextualisée, mais elle introduit aussi une donnée personnelle sensible dans certains contextes. Il faut donc clarifier le bénéfice attendu, demander uniquement ce qui est nécessaire et prévoir une option sans localisation.
Un historique peut aussi éviter les répétitions, mais il oblige à décider où les données sont conservées et pendant combien de temps. Le suivi de progression peut encourager l'usage, mais aussi recréer une logique de compétition et de notifications que le projet cherche justement à éviter. En bref : chaque fonctionnalité doit être évaluée par rapport à l'objectif initial, aider l'utilisateur à passer à l'action - puis le laisser tranquille.
Enfin, TouchGrass AI est publié sous licence MIT, ce qui facilite l'étude et la réutilisation du code sous les conditions de cette licence. Les développeurs peuvent consulter le dépôt GitHub et regarder la démonstration vidéo. L'ouverture aide à la contribution, mais la pérennité dépendra aussi de la maintenance, de la documentation et de la façon dont les retours seront traités.
Conclusion : concevoir l'IA pour qu'elle sache aussi s'effacer
TouchGrass AI ne prouve pas que l'intelligence artificielle fera sortir davantage de monde. Ce qu'elle propose, c'est une expérimentation concrète : utiliser un modèle local pour transformer des préférences et une contrainte de temps en une activité extérieure, tout en prévoyant une solution quand la génération ne se déroule pas comme prévu.
Le message principal, pour moi, c'est que l'intégration de l'IA ne se résume pas au modèle. Elle dépend du problème choisi, de la qualité du parcours, des modes dégradés, des données traitées et de la capacité à faire fonctionner le tout sur les appareils visés. Le local donne plus de contrôle et peut réduire la dépendance à un service distant, mais il impose aussi ses contraintes : matériel, stockage, maintenance.
Si vous concevez un produit qui intègre de l'IA, commencez par identifier l'action utile pour l'utilisateur. Ensuite, vérifiez si un modèle est vraiment nécessaire, définissez clairement le comportement en cas d'échec et mesurez ce qui change réellement - sans confondre activité numérique et valeur créée. Pour creuser cette approche, consultez le code source et la démonstration.