TouchGrass AI : une IA locale pour sortir davantage
Découvrez TouchGrass AI, un compagnon open source qui transforme vos préférences en missions dehors grâce à un modèle local, sans IA cloud. Essayez-le.
TouchGrass AI : quand l'IA vous aide à poser votre téléphone
Les applications cherchent souvent à prolonger notre temps d'écran. TouchGrass AI fait l'inverse : l'IA propose une activité, puis vous invite à ranger le téléphone. Une promenade attentive, quelques minutes de jardinage, l'écoute des oiseaux, un mouvement doux... L'idée est simple : transformer l'envie un peu floue de prendre l'air en petite mission faisable tout de suite.
Le projet, présenté dans le cadre de la semaine « Touch Grass » du défi open source de Hacktoberfest, repose sur une architecture locale. Vous indiquez votre humeur, le temps disponible, votre niveau d'énergie et vos préférences. Ensuite, un modèle open weight lancé avec Ollama génère une suggestion. Si le modèle n'est pas installé (ou pas disponible), un planificateur intégré prend le relais.
Cette approche est intéressante au-delà du côté « bien-être ». Elle pose une question très concrète : peut-on faire une expérience d'IA qui soit réellement utile, sans compte obligatoire, sans service cloud propriétaire et sans chercher à retenir l'utilisateur dans l'application ? Voyons ce que TouchGrass AI met en place, ce que le choix du local change vraiment, et ce qu'il faut vérifier avant d'en reprendre l'idée.
TouchGrass AI : une IA au service d'une action simple
TouchGrass AI est un compagnon d'activités extérieures qui vise à proposer des idées personnalisées à partir de quelques préférences. Pas de réseau social, pas de suivi d'activité, pas d'assistant généraliste. Son périmètre est volontairement étroit : aider quelqu'un à choisir une activité accessible et à la démarrer.
Le parcours est direct. Vous renseignez votre humeur, le temps dont vous disposez, votre niveau d'énergie et les activités qui vous tentent. L'application transforme tout ça en une proposition : une durée, un niveau de difficulté, des consignes étape par étape, et une alternative si sortir n'est pas possible.
Les activités suggérées restent volontairement « ordinaires » : marche attentive, exploration de la nature, écoute des oiseaux, jardinage, mouvement doux. Et c'est précisément là que ça compte. Une recommandation utile n'a pas besoin d'être spectaculaire. Elle doit surtout être assez concrète pour réduire le temps passé à décider, sans vous imposer une organisation que vous n'avez ni le temps ni l'énergie de suivre.
Réduire la friction plutôt qu'ajouter une fonctionnalité
Dans ce type d'application, le défi n'est pas seulement de trouver une idée. C'est aussi d'éviter que la préparation devienne une activité en soi. Si l'utilisateur doit parcourir un catalogue, régler plein de paramètres et lire une réponse trop longue, l'outil risque d'allonger exactement le temps d'écran qu'il prétend réduire.
TouchGrass AI pousse un principe qui me paraît cohérent : obtenir un plan, ranger le téléphone, passer à autre chose. Ce principe doit se sentir dans l'interface autant que dans le modèle. En pratique, une réponse courte, compréhensible et directement exécutable vaut souvent mieux qu'un long texte « plus détaillé » mais difficile à transformer en action.
Le projet annonce une interface responsive et simple, pensée pour limiter les interactions inutiles. Sur mobile, chaque écran de plus, chaque demande d'autorisation et chaque décision « non essentielle » augmentent le risque d'abandon. Si l'objectif est de déclencher une action hors de l'application, le succès ne se mesure pas au nombre de minutes passées à l'intérieur.
Un cas d'usage modeste, donc testable
TouchGrass AI ne prétend pas résoudre un problème médical, ni remplacer un professionnel. Il s'agit d'une aide à la décision pour des activités du quotidien. Et justement, cette limite rend l'évaluation plus réaliste : les suggestions sont-elles compréhensibles ? adaptées au temps disponible ? réalistes par rapport à l'énergie déclarée ? L'utilisateur peut-il passer à l'action sans devoir corriger le plan lui-même ?
Ce type de contrainte rappelle une règle simple en IA appliquée : mieux vaut un périmètre réduit avec un résultat vérifiable qu'un assistant généraliste dont on ne sait pas trop comment mesurer si ça marche. La valeur du projet tient moins à la « sophistication » du modèle qu'à l'enchaînement entre une demande simple, une réponse utilisable et une sortie rapide de l'écran.
Comment fonctionne l'application
L'architecture décrite s'appuie sur Node.js et Express côté serveur, avec HTML, CSS et JavaScript pour l'interface. Pour la génération, l'application utilise Ollama pour lancer localement le modèle open weight llama3.2:3b. Le serveur envoie une requête à l'API locale d'Ollama, qui renvoie une proposition basée sur les préférences de l'utilisateur.
L'idée reste classique, mais elle a un intérêt pratique : le produit ne dépend pas d'un fournisseur distant d'IA dans son fonctionnement « normal ». La génération se fait sur la machine où le modèle est installé. L'application inclut aussi un planificateur intégré, activé quand le modèle n'est pas disponible.
Du formulaire à la mission
Le flux décrit par le projet se résume en quatre étapes :
- L'utilisateur précise son humeur, son temps disponible, son énergie et ses préférences d'activité.
- Le backend construit une consigne destinée au modèle local.
- Le modèle génère une mission : durée, difficulté, étapes, et une option de remplacement.
- Si Ollama ou le modèle ne répond pas, le planificateur intégré propose une suggestion.
Cette séparation compte, parce qu'elle évite qu'une fonctionnalité centrale s'effondre dès qu'il y a un problème de dépendance. Le planificateur de secours ne produira probablement pas la même variété qu'un modèle génératif, mais il garde une base utilisable. En production, cette différence entre « qualité idéale » et « service disponible » est souvent plus importante que le choix d'un modèle un peu plus puissant.
Le démarrage en local
Pour lancer la démonstration, le projet indique de récupérer le code depuis son dépôt GitHub, d'installer les dépendances avec npm install, puis de démarrer le serveur avec npm start. Ensuite, l'interface est accessible à http://localhost:3000. Il faut aussi installer et configurer Ollama, ainsi que le modèle mentionné, si vous voulez tester la génération locale ; en revanche, le planificateur intégré permet d'utiliser l'application sans avoir téléchargé de modèle.
Ces instructions correspondent à la présentation du projet. Pour les prérequis exacts, les variables de configuration éventuelles et l'état actuel du dépôt, il faut consulter le README. La présentation de TouchGrass AI sur Dev.to renvoie au projet et à sa démonstration locale.
La différence entre « tout tourne chez soi » et « ça s'installe vite » mérite d'être gardée en tête. Faire tourner un modèle sur son ordinateur évite une API distante, mais demande une installation en plus et consomme des ressources machine. Ça peut convenir à des gens qui veulent expérimenter ; pour un public qui s'attend à ouvrir une page web et obtenir un résultat immédiatement, c'est moins évident.
Pourquoi choisir une IA locale et open source
Le projet défend une idée simple : les infos sur votre humeur et vos préférences personnelles ne devraient pas forcément quitter l'appareil pour produire une suggestion. Sans compte, sans analytique et sans dépendre d'une IA cloud tierce, TouchGrass AI limite certains flux de données qu'on retrouve souvent sur le web.
Cette architecture donne aussi plus de contrôle aux développeurs. Ils peuvent examiner et modifier les consignes, tester d'autres modèles compatibles et ajuster le comportement sans être coincés par une API commerciale précise. Pour un apprentissage ou un prototype, cette liberté rend les expérimentations plus accessibles et évite de compter chaque génération comme un coût facturé.
Ce que « local » change - et ne garantit pas
L'inférence locale peut réduire les données envoyées à des services externes. C'est un vrai point positif quand on parle de préférences personnelles. Mais « local » ne veut pas automatiquement dire « privé » ni « conforme au RGPD » dans tous les cas. Il faut regarder l'application dans le détail : appels réseau, journaux serveur, stockage côté navigateur, dépendances tierces, et configuration d'hébergement.
Ici, l'absence de comptes, d'analytique et d'IA cloud fait partie du choix de conception annoncé. Mais ça ne remplace pas une vérification du code et du comportement réel avant de déployer ou d'y saisir des informations sensibles. Une application utilisée uniquement sur la machine locale n'a pas le même profil de risque qu'une version hébergée accessible à plusieurs personnes.
Cette nuance compte pour les équipes européennes. Le RGPD ne se joue pas seulement sur « fournisseur européen » ou « modèle installé sur un ordinateur ». Ce qui compte, c'est la collecte, la finalité, la durée de conservation, les accès, et l'information des personnes concernées. La bonne question, pour des données personnelles, reste donc très terre-à-terre : quelles données circulent, où, pendant combien de temps, et dans quel but ?
L'ouverture comme levier d'expérimentation
Le code ouvert rend le projet plus facile à examiner et à adapter. Un développeur peut comprendre comment les préférences alimentent la consigne, tester les réponses du modèle, et modifier le planificateur de secours. Il peut aussi intégrer une inférence locale sans devoir démarrer par un contrat d'API ni un budget récurrent.
Ça ne rend pas le projet « prêt pour le travail » par magie. Un dépôt open source peut rester un prototype : disponibilité, sécurité, documentation, maintenance et qualité réelle des suggestions doivent être évaluées séparément. L'ouverture aide à l'audit et aux contributions, mais elle ne remplace pas un audit ni la maintenance.
Pour les entreprises, le choix entre local et cloud dépend du contexte. Une petite équipe qui expérimente un cas d'usage peu critique peut préférer le contrôle et l'absence de coût par appel. Une équipe qui doit garantir une disponibilité élevée, gérer beaucoup d'utilisateurs, ou produire des résultats très homogènes devra comparer le coût matériel, les performances, le support et la charge opérationnelle. L'indépendance vis-à-vis d'un fournisseur a de la valeur, mais elle n'est pas gratuite : elle déplace le travail sur l'équipe qui exploite le système.
Ce que le projet permet de conclure - et ses limites
TouchGrass AI montre un exemple utile d'IA « au service d'un objectif », où la technologie doit s'effacer. Le modèle n'est pas là pour maintenir la conversation, ni pour personnaliser indéfiniment le parcours. Il sert à produire une proposition, puis l'utilisateur est censé quitter l'écran. Ça, ça distingue le projet de beaucoup de produits numériques pensés pour la rétention.
Il reste cependant un écart entre ce que la présentation affirme et ce qu'elle ne documente pas. Le projet décrit sa pile technique, le modèle, le mécanisme de secours et l'absence annoncée de comptes, d'analytique ou de cloud tiers. En revanche, rien ne remplace des retours de test : qualité réelle des recommandations, évaluation d'accessibilité, et audit concret de confidentialité.
La génération n'est pas la même chose que la qualité
Un modèle peut produire une mission bien structurée sans que ce soit pertinent dans toutes les situations. Une promenade peut être impossible à cause de la météo, d'un handicap, d'un environnement urbain peu sûr, ou juste de contraintes familiales. Le projet prévoit une alternative si sortir n'est pas pratique, ce qui va dans la bonne direction, mais encore faut-il voir comment elle est formulée et dans quels scénarios elle est réellement testée.
Et il faut éviter une confusion facile : une suggestion générée ne doit pas être présentée comme une évaluation fiable de l'état de santé ou des capacités physiques. Pour rester dans son périmètre, l'application devrait proposer des activités faciles à ignorer ou à adapter, signaler clairement leur caractère indicatif, et éviter les consignes qui pourraient créer un risque. Les recommandations doivent rester modestes, surtout quand l'utilisateur donne peu d'informations.
Le modèle de secours est un choix produit, pas un détail
Le planificateur intégré mérite autant d'attention que le modèle. Il améliore la disponibilité quand l'IA ne démarre pas, et il aide à tester sans téléchargement. Mais ça soulève une question de cohérence : l'utilisateur sait-il quand il reçoit une suggestion produite « autrement » ? Si les résultats varient beaucoup, une indication claire peut éviter l'idée que tout est généré de la même manière.
Pour juger ce mécanisme, une équipe peut construire des scénarios concrets : peu de temps, faible énergie, préférence pour le jardinage, impossibilité de sortir, météo défavorable. Puis comparer les propositions du modèle et celles du planificateur. Le but n'est pas de prouver que le modèle est « créatif », mais de vérifier que les deux chemins restent compréhensibles et sûrs.
Les critères à examiner avant un déploiement
Avant de reprendre cette approche dans un produit, je vérifierais au minimum :
- Utilité : les suggestions mènent-elles vraiment à une action, ou ajoutent-elles surtout une étape de plus ?
- Fiabilité : le planificateur de secours couvre-t-il les situations les plus courantes ?
- Confidentialité : les données saisies restent-elles sur l'appareil dans la configuration prévue ?
- Accessibilité : les activités et l'interface conviennent-elles à des contextes et capacités différents ?
- Coût total : le calcul local et la maintenance sont-ils acceptables pour les utilisateurs visés ?
- Maintenance : le dépôt, les dépendances et les instructions d'installation sont-ils revus régulièrement ?
Ce cadre évite une erreur fréquente : juger un projet uniquement sur une démonstration. Un modèle local qui marche chez le développeur n'est pas automatiquement une solution adaptée à tous les appareils. Un prototype intéressant reste un prototype tant que ses usages réels, ses contraintes et sa maintenance dans le temps ne sont pas établis.
Conclusion : concevoir l'IA pour qu'elle sache s'effacer
TouchGrass AI défend une idée simple : utiliser un modèle local pour transformer quelques préférences en une activité concrète, sans faire de l'interaction numérique une fin en soi. L'architecture combine une génération avec Ollama, un planificateur de secours et une interface pensée pour limiter le temps passé dans l'application.
Le projet ne prouve pas que l'IA locale est toujours le meilleur choix, ni qu'un design sans cloud suffit à garantir la confidentialité. Il illustre plutôt un compromis intéressant : plus de contrôle et moins de dépendance à une API distante, contre une installation plus exigeante et une responsabilité plus lourde côté maintenance.
Pour juger un cas d'usage similaire, posez-vous trois questions : est-ce que l'IA aide vraiment à décider ? Le service de base continue-t-il de fonctionner quand le modèle échoue ? Les données et les contraintes d'exploitation sont-elles comprises ? Si oui, l'IA a sa place. Sinon, une approche plus simple risque d'être plus convaincante.
Vous pouvez consulter la présentation du projet TouchGrass AI, puis regarder le dépôt et le README avant de lancer la démonstration. Le vrai test n'est pas seulement de voir si le modèle « répond » : c'est de vérifier si la réponse vous aide réellement à quitter l'écran.