IA locale : Outside Hour vous aide à sortir sans écran
Découvrez Outside Hour, l’application qui utilise une IA locale pour préparer une sortie en plein air, puis vous inciter à poser votre téléphone.
Outside Hour : une IA locale qui vous aide à poser votre téléphone
La plupart des applications qui promettent de vous faire sortir commencent par vous demander de rester devant votre écran. Elles ajoutent des recommandations, des notifications ou un fil de contenus à consulter. Outside Hour fait l'inverse : l'application vous donne une minute pour préparer une sortie, puis elle vous demande de fermer le téléphone.
Le principe est simple. Vous indiquez votre point de départ, le temps dont vous disposez et l'heure à laquelle vous voulez partir. Un modèle Gemma exécuté localement propose ensuite un parc, un lac ou un jardin proche, puis rédige une fiche pratique : direction, horaires, choses à regarder et affaires à emporter. Les données de lieu et de météo viennent de services ouverts ; les calculs sensibles passent par le code, pas par le modèle.
Le projet, développé pour un défi Hacktoberfest consacré à l'IA open source, pose une question qui va au-delà de la technologie : peut-on faire un produit numérique dont la réussite se mesure au moment où l'utilisateur le quitte ? Voici comment Outside Hour fonctionne, ce qu'il fait bien, et ce qu'il vaut mieux garder à l'esprit si vous voulez vous en inspirer.
Une application conçue pour s'effacer
Outside Hour ne cherche pas à devenir une appli qu'on ouvre plusieurs fois par jour. Son usage est plutôt ponctuel : préparer une courte sortie, prendre les infos utiles, puis mettre le téléphone de côté. La promesse tient autant à l'interface qu'à la génération par IA.
Une fiche de sortie plutôt qu'un nouveau fil à parcourir
L'utilisateur saisit un lieu de départ et le temps dont il dispose. L'outil propose alors un endroit réel à proximité à partir des données d'OpenStreetMap : parc, jardin, point de vue ou espace avec un plan d'eau. La fiche détaille :
- le lieu recommandé et des éléments cartographiés sur place (étangs, arbres, bancs, etc.) ;
- une flèche de direction, un relèvement et une distance à vol d'oiseau ;
- les heures de départ, de retour et de demi-tour, avec une limite liée au coucher du soleil ;
- trois suggestions d'observation adaptées au lieu et à la lumière ;
- des indications pratiques selon la météo, comme la pluie, la chaleur, l'indice UV, le vent ou la qualité de l'air.
L'exemple donné par le créateur part de la station de métro MG Road, à Bengaluru, pour une marche d'une heure le lendemain à 7 heures. La fiche oriente vers Cubbon Park, en s'appuyant sur des éléments cartographiés comme Lotus Pond ou Bamboo Island Pond. L'intérêt, ici, c'est qu'on ne vous balance pas une phrase générique du type « profitez de la nature » : on vous invite plutôt à observer quelque chose de précis, au bon moment de la journée.
Le compte à rebours fait partie du produit
À l'écran, un anneau décompte les 60 secondes prévues pour préparer la sortie. Quand le délai est écoulé, l'interface passe au rouge, s'assombrit et vous invite à poser le téléphone. Elle peut ensuite afficher un écran noir où restent visibles le lieu, la direction et l'heure de retour.
L'idée est prolongée avec trois options : un écran minimaliste pour partir, une fiche imprimable au format A6 et un fichier calendrier .ics avec une alarme à l'heure du demi-tour. Sur ce dernier point, l'approche reste simple : l'alarme peut être gérée par l'horloge du téléphone, sans garder l'application ouverte.
Le compteur ne prétend pas mesurer toute l'activité du smartphone. Il s'appuie sur l'API Page Visibility du navigateur : l'application sait si sa page est visible ou masquée, mais elle ne voit pas ce que vous faites dans les autres applications. L'interface le dit clairement. Et, franchement, c'est mieux qu'une métrique jolie mais trompeuse.
Une IA locale, mais pas responsable de tout
Le projet utilise Gemma 4 E2B-it, un modèle à poids ouverts exécuté localement sur l'ordinateur de l'utilisateur avec llama.cpp. L'IA sert à choisir une option parmi des lieux déjà collectés et à rédiger le texte de la fiche. En revanche, elle ne décide pas des horaires de retour, ne calcule pas la direction et ne crée pas librement une destination.
Séparer les faits des formulations
C'est le choix d'architecture le plus important. Dans une appli qui donne des indications de déplacement, les erreurs ne se valent pas : un texte imprécis se corrige, une heure ou une distance fausses, c'est plus gênant. Le code calcule donc les horaires, les distances, le relèvement et la contrainte du coucher du soleil. Les lieux viennent des données cartographiques ; la météo, les heures de soleil et la qualité de l'air proviennent d'Open-Meteo.
Ensuite, le modèle reçoit une liste restreinte de lieux candidats, avec des informations structurées. Un schéma JSON limite son choix à un identifiant de lieu existant. Un validateur rejette, par exemple, les réponses qui mentionnent un endroit qui n'est pas dans les données, qui inventent un horaire, qui parlent d'eau sans élément cartographié correspondant, ou qui reprennent une formule trop générique. Si une réponse ne passe pas, l'application tente une nouvelle génération, puis bascule sur un modèle de texte de secours.
Cette séparation ne rend pas le résultat infaillible. Mais elle réduit clairement le champ d'erreur du modèle : au lieu de tout lui laisser faire, on lui confie surtout la rédaction à partir d'éléments déjà vérifiés. La règle est assez facile à transposer ailleurs : demandez à l'IA de classer, résumer ou reformuler quand c'est utile, et gardez les faits vérifiables pour des composants déterministes.
Ce que recouvre vraiment le « local »
Le modèle tourne sur la machine, sans clé d'API, sans compte utilisateur et sans facturation à chaque génération. Dans les mesures publiées, un ordinateur portable avec un processeur Intel Core i5 de 2019, 10 Go de RAM et sans carte graphique dédiée produit un plan en 28,7 secondes en moyenne, après récupération des données de la zone.
Mais ça ne veut pas dire que tout l'app fonctionne sans réseau. Les recherches cartographiques et les données météorologiques nécessitent des requêtes externes lors de la première consultation d'une zone. Les coordonnées envoyées sont arrondies (environ 100 mètres pour OpenStreetMap et 1 kilomètre pour Open-Meteo) puis les données sont mises en cache. Résultat : pour une zone déjà récupérée, on peut préparer un plan hors ligne.
Autrement dit : la génération du texte est locale, mais la collecte initiale des infos géographiques et météo dépend de services tiers. L'application reste donc « locale » au sens IA, pas au sens « avion mode, jamais de réseau ». Les services d'IA externes ne reçoivent pas les informations de localisation, mais les fournisseurs de données ouvertes reçoivent les requêtes nécessaires à leur fonctionnement.
Les choix techniques et leurs compromis
Outside Hour reste un petit projet plutôt qu'une plateforme lourde : environ 1 500 lignes de Python, une page HTML et du JavaScript, sans étape de compilation et sans bibliothèque chargée depuis un CDN. Deux scripts récupèrent llama.cpp et le modèle dans le dossier du projet. Le dépôt est sous licence MIT ; Gemma et les données utilisées ont leurs propres licences et conditions.
Des données ouvertes, avec une qualité variable
OpenStreetMap fournit les lieux et les détails cartographiés : étangs nommés, arbres, bancs, points d'eau ou toilettes, selon ce que les contributeurs ont renseigné. Les prévisions, les heures de soleil et la qualité de l'air viennent d'Open-Meteo. Le projet indique respecter les licences : ODbL pour OpenStreetMap et CC BY 4.0 pour Open-Meteo.
Le point fort, c'est la couverture locale. Une base contributive peut contenir un petit jardin ou un étang qu'on ne trouverait pas forcément dans des bases commerciales plus centrées sur certaines catégories. Le revers, c'est la variabilité de la cartographie : un lieu non nommé peut être ignoré, les horaires d'ouverture ne sont pas forcément vérifiés, et une information manquante ne peut pas être « comblée » par le modèle sans risque d'invention.
La précision apparente n'est pas une route GPS
Le temps de marche est estimé à partir d'une vitesse de 4,5 km/h, puis corrigé par un facteur de 1,3 pour tenir compte du fait qu'un trajet réel n'est pas une ligne droite. La flèche, elle, donne un relèvement et une distance à vol d'oiseau, pas un itinéraire piéton. Pour certains grands parcs, le calcul peut reposer sur le bord d'une boîte englobante.
C'est suffisant pour une indication d'orientation dans le cadre d'une courte sortie, mais ce n'est pas fait pour remplacer une navigation. Les chemins peuvent être fermés, les traversées impossibles, et les entrées parfois éloignées du point calculé. En pratique, il faut vérifier l'accès et le parcours avec une source adaptée avant de partir, surtout si vous ne connaissez pas le secteur.
Même logique pour le coucher du soleil et la météo : ces infos aident à planifier, mais elles ne garantissent ni l'état d'un sentier, ni les conditions observées sur place. L'application l'assume : elle propose une fiche de préparation, pas une validation « sécurité ».
Un petit modèle gagne en précision grâce aux données
Au début, les fiches générées avec Gemma étaient exactes, mais un peu vagues : le modèle conseillait surtout de profiter de l'ombre et de la végétation. Le problème ne venait pas uniquement de la taille du modèle. Il manquait surtout des détails sur le lieu.
La solution a été d'enrichir ce qui est transmis : informations présentes dans la carte, éléments observables compatibles avec le lieu, et indications liées à la lumière du moment. Avec ça, le modèle peut proposer une observation concrète plutôt qu'une formule générique. Les limites de longueur ont aussi été ajustées après des sorties interrompues au milieu d'une phrase. Et côté code, des vérifications de forme ont été ajoutées, avec une logique qui injecte certaines heures importantes pour éviter qu'elles soient modifiées par le modèle.
Dans le benchmark annoncé, dix plans ont été générés par Gemma sans recours au texte de secours, avec une médiane de 28,7 secondes. Sept fiches sur dix mentionnaient un élément cartographié correspondant, selon un contrôle simple par correspondance de mots. Le résultat est intéressant, mais il ne suffit pas à dire que les autres fiches étaient forcément mauvaises : ce type de mesure ne juge pas finement la qualité rédactionnelle ni la pertinence d'une suggestion.
À qui ce modèle peut-il servir ?
Outside Hour intéressera surtout les personnes qui veulent planifier une sortie courte sans transformer cette préparation en séance de navigation sur leur téléphone. Il peut aussi servir de cas d'étude pour des équipes produit qui travaillent sur des assistants IA, des apps de bien-être numérique ou des services basés sur des données de localisation.
Ce qui ressort, à mes yeux, c'est moins le fait que l'IA aide à « choisir » un endroit que la façon dont le projet limite son rôle et coupe le temps d'usage. Beaucoup de produits cherchent à augmenter la rétention ; ici, l'objectif est que l'utilisateur obtienne rapidement ce dont il a besoin, puis ferme la page. C'est cohérent, et un peu à contre-courant.
Cela dit, il faut aussi relativiser. La démonstration est faite à Bengaluru, avec des données cartographiques assez détaillées pour les lieux ciblés. Dans une ville française, le résultat dépendra de la couverture OpenStreetMap, des lieux réellement accessibles et de la qualité des informations disponibles. Il faudra aussi regarder les règles locales : horaires d'ouverture, accès à des espaces privés, restrictions temporaires, conditions sur place. L'outil indique qu'il écarte certains types de lieux, mais il ne peut pas garantir que chaque destination soit ouverte ou praticable.
Le délai joue aussi : en moyenne, la génération prend près de 29 secondes sur le processeur testé, et la récupération des données pour une nouvelle zone peut ajouter de l'attente. Le compte à rebours de 60 secondes inclut cette génération. Pour éviter de commencer sa journée en attendant le modèle, le développeur recommande de préparer la sortie la veille. Ce n'est pas un détail : parfois, la « meilleure technologie » consiste à déplacer le travail au moment où ça gêne le moins.
Le code source et les instructions d'installation sont accessibles sur le dépôt GitHub d'Outside Hour. Pour le contexte complet, les résultats de mesure et les limites reconnues par l'auteur, voir aussi la présentation originale du projet. Les données de référence sont disponibles chez OpenStreetMap et Open-Meteo.
Conclusion
Outside Hour montre une approche assez cohérente pour intégrer une IA générative dans un produit : faire gérer au code les calculs et les contraintes, donner au modèle un cadre de choix borné, vérifier les réponses, et dire clairement ce que l'application ne sait pas faire. Son exécution locale aide à garder le contrôle et évite d'envoyer les demandes à un service d'IA, tout en gardant l'accès nécessaire aux données cartographiques et météo.
Reste que c'est un prototype : estimations, couverture dépendante d'OpenStreetMap, temps de génération non instantané. Mais le principe mérite d'être gardé en tête : une application utile n'a pas forcément besoin de viser un temps d'écran maximal. Si vous concevez un assistant IA, regardez le dépôt et posez-vous la même question : quelles tâches doivent rester déterministes, et à quel moment votre produit devrait-il laisser l'utilisateur partir ?