AFK.exe : le jeu de bureau qui mise sur l’IA locale
Découvrez AFK.exe, un jeu de bureau qui associe pause active, IA locale avec Ollama et progression de développeur. Fonctionnement, limites et installation.
AFK.exe : quand votre bureau virtuel vous pousse à sortir
Un jeu vidéo qui récompense le fait de fermer son ordinateur et d'aller marcher : l'idée va à contre-courant des réflexes numériques. C'est pourtant le principe d'AFK.exe, un projet open source où les contrats de programmation font progresser votre personnage, tandis que vos sorties rechargent son énergie et transforment votre bureau virtuel en espace végétalisé. Une IA multimodale tourne localement sur votre machine pour analyser les photos de certaines missions.
Mais l'intérêt ne se limite pas à l'esthétique ni à la boucle de jeu. AFK.exe combine une application web, une expérience mobile, des données stockées sur l'appareil et un modèle d'IA exécuté avec Ollama. "Local", cependant, ne veut pas dire "sans contraintes" : il faut installer le modèle, disposer d'une machine assez puissante, et accepter les limites du suivi GPS dans un navigateur mobile.
Voici comment le projet fonctionne, comment son architecture affecte la confidentialité, et ce qu'il faut vérifier avant de le lancer. L'objectif n'est pas de vendre l'IA locale comme une solution universelle, mais de voir si elle a du sens pour ce type d'usage.
Le principe : coder, sortir, faire évoluer son bureau
AFK.exe démarre dans un petit bureau en 3D. Le joueur s'installe, ouvre l'écran et accepte des contrats de développement courts : corriger un bug, puis vérifier la solution avec des tests. Les contrats rapportent de l'argent virtuel, de l'expérience et de la pratique sur plusieurs compétences.
Une compagne, Inez, accompagne le joueur : c'est un personnage à tête de plante, simple mais efficace pour donner de l'ambiance. Ensuite, la progression permet d'ajouter des plantes, des lianes, un éclairage plus chaud ou du matériel, comme un second écran. Le bureau n'est donc pas juste un décor : il change avec vos progrès.
La boucle centrale est volontairement claire : coder, dépenser de l'énergie, sortir, puis revenir pour améliorer l'espace. Les contrats consomment cette énergie. Pour la récupérer, le joueur doit faire une sortie suivie depuis la vue mobile : une marche "éligible" dure au moins dix minutes et le téléphone doit s'éloigner d'au moins 150 mètres du point de départ. La marche rapporte des récompenses ; une mission optionnelle peut aussi demander de photographier un élément naturel pour obtenir un bonus.
Une progression pensée autour du travail de développement
Le jeu vise les développeurs et les personnes qui apprennent à coder, surtout celles qui aiment les systèmes de progression. Cinq compétences structurent les contrats : débogage, TypeScript, tests, performance et programmation asynchrone. Elles alimentent ensuite dix titres de carrière, puis une progression continue de maîtrise.
Certains paliers débloquent aussi des outils "orientés développement" : un débogueur assisté par IA au niveau 2, un optimiseur de code au niveau 4 et un générateur de tests au niveau 6. Ce sont des suggestions affichées à l'écran. Elles ne s'exécutent pas automatiquement sur le code du joueur - point important, parce qu'un modèle peut se tromper.
Le jeu cherche donc à relier une progression ludique à une activité réelle. Mais il ne faut pas confondre les deux : réussir un contrat dans AFK.exe ne remplace ni une revue de code, ni une pratique encadrée. Les contrats s'appuient sur des jeux de tests préparés par le projet ; ça ne prouve pas qu'une solution serait robuste en conditions réelles.
Une pause qui n'est pas seulement une notification
L'application mobile ne cherche pas à vous garder collé à l'écran. Elle vous invite à démarrer une marche, à ranger le téléphone, puis à revenir brièvement si une mission photo apparaît. Le thème "Touch Grass" du défi open source Hacktoberfest 2026 est clairement dans la même direction : la "valeur" est dehors, pas dans l'app.
La conséquence, c'est que tout dépend de la façon dont le GPS se comporte sur mobile. Une application qui utilise la localisation tout en demandant de mettre le téléphone en poche doit composer avec les règles des navigateurs et des systèmes mobiles : le suivi peut être suspendu quand l'écran est éteint. AFK.exe prévoit un mode de poche avec un écran minimal actif quand c'est possible, mais ça ne rend pas l'expérience identique d'un téléphone à l'autre.
Comment l'IA locale s'intègre au jeu
AFK.exe utilise Qwen3.5 4B, un modèle multimodal à poids ouverts, exécuté localement via Ollama. L'IA sert surtout dans deux cas : l'évaluation d'une photo de mission "nature" et les outils d'aide au développement débloqués au fil de la progression.
Pour une mission photo, le modèle regarde une version réduite de l'image, choisie selon les critères visuels de la mission. Il renvoie une réponse structurée : une décision de correspondance, un niveau de confiance estimé, une justification, et un indicateur signalant si un examen est nécessaire. Le résultat passe ensuite par Zod, une bibliothèque de validation de schémas.
Et c'est important de comprendre ce que ça garantit... et ce que ça ne garantit pas. Une sortie "en JSON" ne rend pas l'analyse vraie pour autant. La validation vérifie la structure des données, pas si l'image est interprétée correctement. Si le résultat est incertain, le bonus est retenu plutôt que distribué automatiquement. Dans un jeu, c'est plutôt une bonne règle : retarder une récompense vaut souvent mieux que d'attribuer des points sur une décision douteuse.
Ce que l'IA décide - et ce qu'elle ne décide pas
Les auteurs ont gardé des garde-fous déterministes. Les tests des contrats sont des tests écrits à l'avance. La qualification d'une marche repose sur des calculs GPS faits sur le téléphone. Le modèle, lui, ne "décide" pas que tel test a réussi, ni que la distance minimale a été atteinte.
Cette séparation évite pas mal de travers de conception. Un modèle de langage ou d'image est utile quand la tâche reste ambiguë (par exemple interpréter une photo). Il colle beaucoup moins bien quand la règle est mesurable et explicite, du genre "au moins dix minutes et 150 mètres". Dès qu'un calcul classique peut faire le travail, ajouter de l'IA rend souvent le système moins prévisible, sans bénéfice évident.
Les outils de développement suivent la même logique : ils génèrent des propositions, mais ne les appliquent pas automatiquement. Dans un contexte sérieux, la règle "suggestion ≠ exécution" devrait être de base. Une suggestion peut accélérer une première analyse, mais c'est le développeur qui décide si elle est bonne, s'il faut tester, ou s'il faut la rejeter.
Une architecture où l'inférence reste sur l'ordinateur
Le schéma général tient en trois étapes : le téléphone suit la marche et conserve les éléments de mission ; les données sont ensuite transférées vers le jeu sur l'ordinateur ; puis un adaptateur local envoie la photo au service Ollama, qui renvoie un résultat validé avant attribution éventuelle du bonus.
Le transfert entre téléphone et ordinateur ne contient pas l'historique détaillé des coordonnées GPS. Il transporte plutôt un résumé de la marche et des photos réencodées. Les récompenses sont attribuées via une transaction, pour éviter qu'une importation répétée de la même sortie déclenche plusieurs paiements.
Dans cette architecture, photos, code et données de progression ne passent pas par une API d'inférence distante. Ça réduit les transferts vers un fournisseur tiers, mais ça ne rend pas la confidentialité magique. Il faut toujours savoir où les données sont stockées, qui a accès à l'appareil, et comment le transfert est configuré. La lecture du code et de la documentation reste préférable à une confiance purement basée sur le terme "local".
Installation, architecture et limites
Le jeu utilise React, TypeScript et Vite. Le bureau 3D s'appuie sur Three.js et React Three Fiber, tandis que la progression, les marches et les preuves photo sont enregistrées dans IndexedDB, une base de données intégrée au navigateur.
Concrètement : le navigateur exécute le jeu, IndexedDB conserve les données localement, le téléphone collecte les infos de sortie et Ollama fournit le modèle multimodal sur l'ordinateur. Le dépôt contient le jeu, une application web progressive pour le téléphone, l'adaptateur Ollama local, des tests, des instructions d'installation et des informations sur les composants tiers. Le code est sous licence MIT.
Lancer la version locale
Pour tester la version complète, il faut cloner le dépôt et installer ses dépendances. Il faut aussi télécharger le modèle avec Ollama : cette étape demande une connexion Internet. Ensuite, l'inférence tourne localement, sans clé d'API ni facturation à la requête côté fournisseur distant.
git clone https://github.com/bmartin2000/Gooutdoors.git
cd Gooutdoors
npm install
ollama pull qwen3.5:4b
npm run dev
Ollama doit être lancé sur la machine. Si besoin, ollama serve démarre le service. Le dépôt précise aussi l'installation de l'application mobile, la mise en place en HTTPS local, l'association sur le réseau local et le transfert via fichiers. Selon le navigateur et les réglages réseau, faire communiquer téléphone et ordinateur peut demander plus de configuration que "juste lancer dans le navigateur".
La démo hébergée permet d'explorer le jeu, mais elle n'embarque pas le modèle local. GitHub Pages ne peut pas servir le modèle : l'IA nécessite la version du dépôt exécutée sur votre ordinateur, avec Ollama en fonctionnement. Pour voir le code et les instructions, consultez le dépôt AFK.exe sur GitHub.
Les compromis à prévoir
Le mode local évite de dépendre en permanence d'un service d'inférence distant, mais le coût se déplace : téléchargement du modèle, installation initiale (avec Internet), puis consommation de ressources et d'électricité pendant l'inférence. Les performances dépendront de votre matériel, de la taille du modèle et de ce que vous exécutez en même temps. Il ne faut pas supposer que tous les ordinateurs offriront la même expérience.
Le GPS pose aussi un autre problème, indépendant de l'IA. Un navigateur mobile peut interrompre le suivi en arrière-plan, et le mode de poche n'agit pas pareil selon les appareils. Autrement dit : testez le parcours sur vos téléphones réels, plutôt que de promettre une mesure parfaite pour chaque sortie.
Enfin, une photo jugée "plausible" ne prouve ni le lieu ni l'heure de prise de vue. AFK.exe le dit clairement : la vérification visuelle n'est pas un mécanisme de preuve de géolocalisation. C'est une limite "proportionnée" pour une récompense ludique à faible enjeu. Pour une validation à enjeu (financier, légal, etc.), ce ne serait pas suffisant.
La démonstration du projet inclut aussi des accélérations et des scénarios de test. La progression de carrière y est accélérée, et la séquence extérieure utilise une image exemple avec validation administrative. La démo ne montre donc pas une sortie réellement validée par GPS ni une reconnaissance photo locale réellement validée à partir d'une prise de vue pendant l'enregistrement. Les écrans des outils développeur affichent des parcours disponibles, pas des résultats produits au moment de l'enregistrement. Cette transparence aide à distinguer la démonstration de l'expérience complète.
Ce que le projet révèle sur l'innovation ouverte
L'intérêt de l'IA à poids ouverts ne se résume pas à "remplacer une API payante". Dans AFK.exe, l'exécution locale répond à une contrainte assez concrète : les photos sont prises dehors, mais peuvent être traitées plus tard, quand vous êtes de retour devant l'ordinateur. Vous pouvez marcher sans réseau mobile, puis traiter la mission sur votre machine.
Une API cloud aurait pu analyser les images, évidemment. Elle aurait aussi ajouté une dépendance réseau et un transfert vers un prestataire tiers - ce qui colle moins à l'intention du projet. À l'inverse, l'approche locale demande un modèle téléchargé, une machine compatible et une installation que tout le monde ne voudra pas faire. Le choix n'est donc pas "cloud = mauvais, local = bon". Il s'agit plutôt de comparer déploiement, coût récurrent, dépendance au réseau, contrôle des données et capacité matérielle.
L'open source apporte aussi un avantage plus direct : les règles peuvent être inspectées et adaptées. Un contributeur peut relire les instructions données au modèle, regarder le seuil d'incertitude, vérifier la logique des récompenses et comprendre comment les missions sont ajoutées. Ça ne garantit pas l'absence de défauts, mais ça rend les choix plus vérifiables qu'une fonctionnalité entièrement opaque.
Le projet cite aussi Codex pour aider sur l'implémentation, le débogage et des ajustements (renouvellement des contrats, exigences de progression, navigation mobile, etc.). L'auteur précise aussi qu'aucune transcription de session agent n'est jointe. Il distingue enfin l'automatisation de déploiement GitHub Actions de l'usage de Copilot : le fait qu'un projet participe à une catégorie de concours ne veut pas dire que Copilot a écrit le jeu.
Cette distinction compte, surtout dans un contexte où les projets qui touchent à l'IA et au développement sont parfois résumés de façon floue. Il faut séparer l'outil utilisé pendant la création, le modèle intégré au produit et les automatisations de livraison. Trois usages, avec des risques et des bénéfices différents.
Pour replacer le projet dans un paysage plus large, l'article original renvoie aussi à des réflexions sur l'IA local-first et les assistants hors ligne pour des activités de plein air. Ces lectures servent de contexte, pas de dépendances techniques d'AFK.exe. Vous pouvez retrouver la présentation originale du projet et comparer les choix décrits avec ceux de vos propres applications.
Conclusion
AFK.exe propose une idée simple, mais cohérente : faire de la sortie une partie de la progression, plutôt qu'une notification de plus à ignorer. Son architecture associe un jeu web, un suivi mobile et une IA locale, sans confier au modèle les règles qui peuvent être vérifiées via des calculs déterministes.
Le compromis est net. L'exécution locale limite les transferts vers un service d'IA distant, mais impose une installation et des ressources côté matériel. Le GPS et l'analyse photo apportent une expérience de jeu, sans offrir pour autant des preuves fiables quand l'enjeu devient sérieux. C'est acceptable tant que le projet assume clairement ces limites.
Si vous voulez évaluer le projet, commencez par explorer le dépôt GitHub, lisez les instructions d'installation, puis testez le parcours sur votre ordinateur et votre téléphone. Le meilleur test n'est pas de savoir si la démo est séduisante : c'est de vérifier que l'ensemble fonctionne chez vous, avec vos appareils et dans les conditions où vous comptez l'utiliser.