Un monde ouvert de la taille de Skyrim tourne sur Nintendo 64
James Lambert, le développeur derrière Portal 64, vient de dévoiler Junkrunner 64 : un jeu en monde ouvert qui tourne sur une vraie Nintendo 64. La carte est comparable à celle de Skyrim, sans écran de chargement. Difficile à croire, et pourtant ça tourne.
Le créateur de Portal 64 récidive
James Lambert n'en est pas à son coup d'essai sur la console de Nintendo. Après avoir porté Portal sur la N64 (un projet qui avait fait pas mal de bruit), il s'est attaqué à un défi encore plus ambitieux : créer un moteur de monde ouvert capable de gérer une carte immense sur un hardware de 1996.
Le jeu, baptisé Junkrunner 64, a été développé dans le cadre du game jam N64brew 2025 avec une petite équipe composée de Pyroxene, Caitlin G. Cooke, terzdesign et kaelin. Vous pouvez littéralement vous tenir dans un coin de la carte et voir jusqu'à l'autre bout.
Le joueur parcourt ce monde à bord d'un hovercycle qui tape dans les 290 km/h une fois amélioré, et le framerate tient la route sur du hardware original.
Un double rendu pour contourner les limites de la N64
Le gros problème technique, c'est le Z-buffer de la N64. La console n'a qu'un Z-buffer 15 bits, ce qui provoque du Z-fighting dès qu'on essaie d'augmenter la distance d'affichage. Les objets lointains se superposent n'importe comment.
La solution de Lambert est élégante, et c'est un peu technique. Il dessine le monde deux fois. Premier passage : les objets lointains sont rendus avec le Z-buffer désactivé, en partant du plus éloigné vers le plus proche, avec des modèles basse résolution.
Deuxième passage : les objets proches sont affichés normalement. Le tout est découpé en tuiles avec plusieurs niveaux de détail, et un système de frustum culling vire tout ce qui se trouve hors du champ de vision du joueur. Résultat : la RAM est préservée, ce qui sur une N64 n'est pas un luxe.
Gratuit et jouable dès maintenant
Junkrunner 64 est téléchargeable gratuitement sur GitHub. Il vous faudra soit une vraie N64 avec un linker, soit un émulateur précis comme Ares. Les émulateurs classiques risquent de ne pas faire l'affaire vu les techniques de rendu utilisées.
Lambert ne compte pas s'arrêter là : le moteur sert déjà de base à un projet plus gros appelé Spellcraft, et le code source est dispo pour ceux qui veulent fouiller.
Un monde de la taille de Skyrim sur une console sortie il y a 30 ans, c'est le genre de truc qui devrait faire rougir certains studios qui peinent à optimiser leurs jeux sur du matériel actuel. Lambert fait partie de ces développeurs homebrew un peu dingues qui refusent d'accepter les limites officielles d'une machine.
Bon, on ne va pas comparer la densité de contenu avec un Elder Scrolls, évidemment, mais la prouesse technique est bien là. Et le fait que tout soit gratuit et open source, ça rend le projet encore plus appréciable. On a hâte de voir Spellcraft, surtout que Lambert a déjà prouvé avec Portal 64 qu'il savait aller au bout de ses projets.
Source : Time Extension
Cooklang - Le Git de vos recettes de cuisine
Si vous en avez marre de perdre vos recettes de cuisine dans des apps comme Whisk ou Paprika qui ferment tous les 6 mois, ou de devoir scroller 14 pages de storytelling avant d'arriver aux ingrédients... y'a un truc qui devrait vous plaire. Ça s'appelle Cooklang , et c'est un langage de markup pour écrire vos recettes en texte brut et les garder à vie !
En gros, vous créez un fichier .cook avec Notepad, Sublime Text ou votre terminal favori, vous écrivez votre recette en français normal et vous ajoutez quelques marqueurs type : @farine{200%g} pour un ingrédient avec sa quantité, #fouet{} pour un ustensile, ~{25%minutes} pour un minuteur.
Du coup, à partir de ce petit fichier texte, l'outil génère alors automatiquement la liste de courses, les minuteurs et un joli rendu lisible. Y'a pas de compte à créer, ni de serveur Notion à monter... C'est juste vos recette chez vous !
Et le truc vraiment sympa, c'est que la syntaxe reste parfaitement lisible même sans l'outil... en fait votre recette de carbonara reste une recette de carbonara, et pas un fichier XML avec 47 balises imbriquées. D'ailleurs si vous versionnez vos fichiers avec un Git, vous pouvez tracer l'évolution de vos recettes au fil du temps, pour voir par exemple quand vous avez décidé de mettre plus d'ail dans la marinade et pourquoi votre tarte aux pommes de 2024 était meilleure que celle de 2023.
La syntaxe Cooklang : lisible par un humain, exploitable par la machine
Côté écosystème, c'est très complet pour un projet open source et complètement gratuit ! Y'a un CLI écrit en Rust qui fait serveur web intégré ( la démo est ici ), des apps iOS et Android avec synchronisation, des plugins pour VS Code, Vim et Emacs (pour les puristes), un plugin Obsidian pour afficher vos recettes directement dans votre vault, et même un mode Raspberry Pi Zero pour héberger votre précieux livre de recettes familial sur le réseau WiFi local.
Comme ça, un petit cookcli server et tout le monde à la maison peut consulter les recettes depuis son téléphone. Par contre, attention, y'a pas de mode collaboratif en temps réel, c'est chacun son fichier... c'est pas Google Docs non plus.
Le système de mise à l'échelle est pas mal non plus. Quand vous triplez les quantités de votre blanquette pour le repas du dimanche, le sel et le poivre restent fixes (parce que non, on ne triple pas la quantité de pincées de sel quand on passe à 6 personnes). Sauf que ça marche pas pour tout : les temps de cuisson, faut quand même les ajuster vous-mêmes et si une recette dépend d'une autre, genre votre sauce hollandaise maison, vous pouvez la référencer directement dans votre préparation avec @./sauces/Hollandaise{150%g}.
D'ailleurs, y'a une astuce que je trouve carrément cool, c'est que si vous trouvez une recette en ligne qui vous plaît, vous pouvez coller cook.md/ devant l'URL et ça la convertit automatiquement au format Cooklang, prête à être intégrée dans votre collection de recette. Comme ça, pas besoin de tout retaper à la main comme un scribe du Moyen Âge !
Le projet existe depuis janvier 2021 et c'est sous licence MIT. Dans un monde (prenez une grosse voix grave) où chaque app de cuisine veut votre email, vos données et 5 euros par mois, la vraie résistance s'organise avec des fichiers texte de cuisine de 2 Ko qu'on peut ouvrir dans n'importe quel éditeur de texte , synchroniser via Syncthing ou balancer sur une clé USB.
Et si tout ce qui vous intéresse c'est uniquement la bouffe, il y a des recettes ici et des recettes là .
Bref, créez un fichier boeufbourguignon.cook, balancez-y votre recette avec les marqueurs et lancez cookcli server pour voir le résultat... il manque plus qu'un git blame pour savoir qui a mis trop d'oignons !
Merci à Fabien pour la découverte !
msgvault - Libérez vos emails de la prison Gmail
Gmail, c'est 20 ans de notre vie numérique enfermée à double tour sur les serveurs de Google. Nos mails, nos factures PDF, nos photos en pièce jointe, les powerpoint de nichons des collègues...etc tout ça coincé dans une interface web qui rame de plus en plus et qui vous colle du Gemini dans la tronche à chaque clic. C'est pour cela que Wes McKinney (oui, le créateur de pandas et Apache Arrow) a décidé de régler le problème à sa façon avec msgvault , un outil codé en Go qui aspire l'intégralité de votre boîte Gmail en local.
C'est un binaire unique qui se connecte via OAuth à votre compte Gmail, télécharge tous vos messages et pièces jointes, et stocke le tout dans une base SQLite. C'est fait pour ceux qui galèrent à récupérer leurs mails sans passer par le très lent Google Takeout... Par contre, la première sync prend du temps parce que Google rate-limite sévère, mais ensuite les syncs incrémentales se font en quelques secondes. Avec un petit cron, c'est vite réglé.
Ce qui est bien foutu avec ce projet c'est l'architecture puisque SQLite sert de base de référence, mais pour les requêtes, msgvault génère des fichiers Parquet et utilise DuckDB pour fouiller vos millions de mails quasi instantanément. À vrai dire, McKinney a testé avec près de 2 millions d'emails et plus de 150 000 pièces jointes stockées sur son disque, soit 39 Go au total, et ça tourne nickel sur sa machine.
Les pièces jointes sont même dédupliquées par hash de contenu, du coup si vous avez reçu le même PDF 47 fois... hé bien il n'est stocké qu'une seule fois.
Côté interface, y'a le choix. Soit vous passez par une TUI pour naviguer dans vos mails depuis le terminal, ou un CLI pour scripter en bash, voire pourquoi pas un serveur MCP qui permet de brancher l'outil directement sur Claude Desktop ou n'importe quel agent IA compatible.
L'interface TUI pour gérer vos emails
Comme ça, vous lui demandez des trucs genre "retrouve-moi ce contrat envoyé par machin en 2019" et ça sort un résultat en quelques secondes ! Tout ça en local, sans que vos données ne transitent chez qui que ce soit.
D'ailleurs, si vous aviez déjà sauvegardé vos emails Gmail avec les bonnes vieilles méthodes (Thunderbird, getmail, fetchmail...), msgvault va carrément plus loin puisque l'outil gère plusieurs comptes Gmail, et surtout il permet de supprimer vos mails côté Google tout en gardant votre copie locale (vérifiez bien quand même que votre archive locale est complète avant, hein, sinon oups la boulette). Donc msgvault c'est clairement un vrai plan de sortie de Gmail...
Attention quand même, c'est de l'alpha ! Y'a des bugs, et des trucs qui vont forcement changer / casser en fonction des releases. Par exemple projet a débuté en Python et Rust avant de basculer sur du Go pur, histoire de simplifier la distribution (un seul fichier binaire, zéro dépendance) et la roadmap de Wes prévoit l'import de fichiers .mbox, le support d'autres fournisseurs mail, et à terme l'archivage de WhatsApp, iMessages et de vos SMS. Une Web UI compatible Tailscale est aussi dans les cartons pour accéder à vos archives depuis votre téléphone.
Bref, c'est que du bon ! Et comme les mails c'est le nerf de la guerre et beaucoup de souvenirs, autant les garder chez vous !
Le code est sur GitHub .
Dégooglisation - Vos Google Docs ne sont pas de vrais fichiers
Vous savez ce qui est super vicieux avec Google Drive ?
C'est que les fichiers .gdoc, .gsheet et .gslides que vous voyez dans votre explorateur de fichiers et bien ce ne sont pas de VRAIS documents. Ce sont en fait des raccourcis JSON de quelques octets qui pointent vers les serveurs de Google. Essayez par exemple de les copier avec FreeFileSync ... y'a rien dedans ! Vous pensez donc avoir une copie mais le jour où vous fermez votre compte Google, pouf, tout disparaît comme par magie !
Y'a bien sûr Takeout, l'outil officiel d'export de Google, mais cette merde ne résout pas vraiment le problème non plus, car il vous balance un zip géant de tout votre Drive sans garantie de conversion propre des Google Docs en fichiers exploitables. Et l'export manuel via Fichier > Télécharger > Word, quand vous avez des centaines de documents éparpillés dans des dizaines de dossiers... c'est pas trop une option quoi...
Voilà pour notre point petit point d'introduction sur cette situation ubuesque... ^^
Mais heureusement,
un lecteur du blog prénommé Jérémy
(ça me fait penser à la première saison de Beast Games... Argh !) a pondu
Export-GoogleShortcuts
, un script PowerShell (Windows, donc) qui règle ça en utilisant l'API officielle Google Drive. Le principe c'est qu'il parcourt vos dossiers, repère les raccourcis .gdoc/.gsheet/.gslides et les convertit automatiquement en .docx, .xlsx et .pptx. Les fichiers atterrissent alors au même endroit que les originaux, avec un suffixe _from_gdocs pour pas mélanger.
Côté mise en place, faut passer par la Google Cloud Console pour créer un petit projet, activer l'API Drive et générer des identifiants OAuth (l'éternel duo clé secrète + ID client). C'est un one-shot, vous le faites une fois et c'est réglé ! Ensuite, une commande PowerShell avec le chemin de votre Drive et vos identifiants, et ça mouline tout seul.
Le truc bien pensé c'est que le script gère les noms de fichiers foireux (caractères spéciaux que Windows digère mal) via une petite recherche mais par contre, attention, y'a une limite ! Hé oui, Google coupera la connexion si le fichier converti dépasse les 10 Mo environ. Donc vos grosses présentations de darons bourrées d'images HD, faudra les télécharger à la main via le navigateur. Après pour le reste, soit environ 95% des fichiers, ça passe sans broncher.
Voilà donc une bonne bidouille pour sortir des griffes de Google... Car oui, stocker ses docs chez Google c'est pratique... mais comme d'hab, le problème, arrive le jour où ça ne l'est plus. Que ce soit pour migrer vers un NAS hébergé chez vous , vers Nextcloud, ou juste pour récupérer une copie locale, ce script fait finalement très bien le boulot.
Et si la conversion de documents entre différents formats c'est votre truc, Pandoc reste un compagnon carrément solide pour tout ce qui est markdown, HTML, ODT ou EPUB.
Voilà, donc n'oubliez pas, vos données vous appartiennent... mais encore faudrait-il les extraire avant que Google ne vous mette une carotte !
Ce capteur photo est capable de se réparer tout seul pour survivre aux radiations de Jupiter
Des chercheurs ont mis au point une puce CMOS qui détecte ses pixels endommagés par les radiations et les répare en les chauffant. De quoi intéresser les futures missions autour de Jupiter.
Un environnement qui détruit les caméras
L'orbite de Jupiter est l'un des pires endroits du système solaire pour l'électronique. Le champ magnétique de la planète, gigantesque, ionise le dioxyde de soufre craché par Io, sa lune volcanique, et alimente une ceinture de radiation de particules chargées à haute vitesse.
Pour les caméras embarquées sur les sondes spatiales, c'est un cauchemar. Les pixels du capteur accumulent des charges parasites, le courant de fuite explose, et au bout de quelques semaines l'image devient inutilisable.
La NASA en a fait l'expérience avec JunoCam, la caméra de la sonde Juno. À partir de l'orbite 47, les images ont commencé à se dégrader. À l'orbite 56, elles étaient quasiment inexploitables. En décembre 2023, les ingénieurs ont tenté un coup de poker : commander à distance au chauffage embarqué de monter la température à 25 degrés Celsius, bien au-dessus des conditions normales.
L'idée, forcer un recuit thermique du silicium pour libérer les charges piégées et restaurer la structure cristalline. Ça a marché. JunoCam a retrouvé une image nette juste à temps pour survoler Io.
Un capteur qui se soigne lui-même
Une équipe de la Southern University of Science and Technology et de l'université de Kyoto a poussé le concept beaucoup plus loin. Leur puce, présentée en février à l'ISSCC 2026 à San Francisco, intègre directement le mécanisme de réparation dans le capteur. Plus besoin d'intervention humaine à 600 millions de kilomètres.
Le capteur effectue régulièrement une lecture dans le noir complet. Si un pixel affiche encore un courant anormal, il est marqué comme endommagé et un courant fort lui est envoyé pour le chauffer localement. Pendant que ce pixel se répare, le reste de la matrice continue à fonctionner.
La puce embarque aussi un système de compression adaptative qui repère les zones d'intérêt et réduit le volume de données transmises de 75 %. Quand vous envoyez des images depuis Jupiter, chaque octet compte.
Le prototype est une matrice de 128 x 128 pixels. Les chercheurs l'ont exposée à l'équivalent de trente jours de radiation en orbite jovienne. Résultat : le capteur était devenu inutilisable. Après quatre cycles de recuit, l'image était quasiment restaurée.
Un vrai sujet pour les prochaines missions
La technologie arrive à un moment où elle peut servir. JUICE, la mission de l'ESA, est en route vers Jupiter et ses lunes glacées. Europa Clipper de la NASA doit étudier Europe et son océan souterrain.
Ces sondes vont passer de longs mois dans la ceinture de radiation jovienne, et jusqu'à présent la seule parade consistait à blinder les composants avec des semi-conducteurs durcis aux radiations, avec un coût et un poids en plus. Un capteur capable de se réparer en vol, c'est une ligne de défense supplémentaire qui pourrait allonger la durée de vie des instruments.
Ce qui était un bricolage de dernière minute à 600 millions de kilomètres est devenu un système automatisé, intégré directement dans le silicium. 128 x 128 pixels, c'est encore loin d'un capteur opérationnel pour une vraie mission, mais le principe fonctionne.
On imagine bien que la prochaine étape sera de passer à des résolutions plus élevées et de valider tout ça dans des conditions réelles. En tout cas, si ça permet d'éviter de perdre des mois de données scientifiques à cause de pixels grillés, on prend.
Source : Spectrum.IEEE.org
Orbitiny - Un environnement de bureau Linux 100% indé
GNOME trop rigide, KDE Plasma trop usine à gaz, Xfce trop vintage... J'sais pas si vous êtes d'accord avec ça, mais c'est l'avis de ce développeur solo ultra acharné qui a décidé de tout refaire from scratch. Ça lui a pris 9 ans de boulot à coder du C++ sur le framework Qt, et à créer 48 composants modulaires pour fourer tout ça dans un environnement de bureau Linux, entièrement indépendant qui ne dérive d'aucun projet existant, qu'il a appelé Orbitiny Desktop !
Le truc chouette avec cet environnement de bureau, c'est sa modularité car chaque composant tourne dans son propre processus, ce qui veut dire que si le gestionnaire de fichiers plante, votre panneau et vos icônes de bureau restent en place. On est donc trèèèès loin du crash GNOME Shell qui vous renvoie sur l'écran de connexion en plein milieu d'un truc important !
Et le truc qui va plaire aux bidouilleurs, c'est que le bazar est 100% portable. Vous décompressez l'archive tar.gz de 185 Mo sur une clé USB, vous lancez le script start-orbitiny et hop, vous avez votre bureau perso sur n'importe quelle machine Linux. Tous les réglages sont sauvegardés dans le dossier d'extraction... du coup vous pouvez trimballer votre config partout avec vous. Et si vous préférez une installation classique, y'a aussi un script graphique install-orbitiny à lancer avec sudo.
Côté features, c'est plutôt fourni ! Orbitiny intègre son propre gestionnaire de fichiers (Qutiny), un presse-papier système, un gestionnaire de périphériques USB et un tableau de bord avec barre de recherche.
Le gestionnaire de fichiers gère la recherche par nom et contenu, la vue en double panneau et des trucs assez originaux genre le "File Join" qui permet de fusionner des fichiers texte par simple drag and drop, ou le "Image Join" qui colle des images entre elles verticalement. Y'a aussi un système de gestes de souris configurables sur le bureau (jusqu'à 12 tracés par bouton gauche ou droit), des bureaux indépendants par moniteur ET par bureau virtuel (chaque écran physique a son propre fond d'écran et ses propres raccourcis), et un panneau avec 18 applets qu'on repositionne par simple glisser-déposer, sans passer par un mode édition.
Le petit bonus sympa, c'est le support WINE et DOSBOX intégré. Vous balancez un .exe Windows sur le bureau ou dans le gestionnaire de fichiers et ça lance direct via WINE. Pareil pour les vieux programmes DOS via DOSBOX. Pas besoin de bidouiller des fichiers .desktop custom à la main (bon ok, faut quand même que WINE soit installé sur votre distro). Après ça ne marche pas forcément avec tous les programmes Windows non plus... va savoir pourquoi certains .exe passent et d'autres plantent. Les mystères de la vie !
Ah et j'allais oublier un truc : Orbitiny peut aussi tourner en mode overlay, c'est-à-dire par-dessus un autre environnement de bureau. Vous gardez votre GNOME ou votre KDE en dessous et vous superposez Orbitiny par-dessus pour profiter de ses fonctionnalités sans tout changer. C'est pratique pour tester sans engagement !
Le projet est sous licence GPLv2, disponible sur SourceForge et tourne sur toute distro Linux basée sur X11. Attention par contre, pas de support Wayland pour l'instant, c'est du X11 only, ce qui risque de poser souci à terme vu que Wayland remplace progressivement X11 sur Ubuntu, Fedora et compagnie. Oubliez pas non plus que c'est un projet d'un seul développeur, donc les mises à jour arrivent quand elles arrivent. Après si vous cherchez d'autres moyens de personnaliser votre bureau Linux , y'a de quoi faire.
Bref, 9 ans de boulot solo pour un environnement de bureau qui tient plutôt bien la route, faut quand même saluer l'effort !! Et un grand merci à François pour le partage !
Pangolin - Proxy, VPN et auth enfin réunis
Si vous auto-hébergez vos propres services parce que VOUS AVEZ DU TEMPS GRÂCE A VOTRE BULLSHIT JOB SURPAYÉ, vous connaissez la chanson... il vous faut un reverse proxy type Nginx Proxy Manager pour router le trafic, un tunnel Cloudflare ou WireGuard pour exposer vos services sans ouvrir de ports, et un truc genre Authentik pour l'auth. Donc 3 outils, 3 configs différentes, et surtout 3 trucs qui peuvent vous péter à la gueule à tout moment, surtout quand vous êtes en vacances ou en train de jouer avec vos enfants.
Mais heureusement, j'arrive à la rescousse avec Pangolin , un projet open source qui colle tout ça dans un seul paquet : Proxy inversé, tunnels WireGuard chiffrés, authentification zero-trust, le tout orchestré par Docker. Une commande de grosse feignasse dans le terminal et c'est installé !!
curl -fsSL https://static.pangolin.net/get-installer.sh | bash
Le truc peut tourner sur n'importe quel VPS avec une IP publique (Ubuntu 20.04+ ou Debian 11+, AMD64 ou ARM64). L'installeur pose Docker, Traefik et les conteneurs en 2-3 minutes chrono et ensuite vos services à la maison se connectent via des tunnels WireGuard... sans ouvrir le moindre port sur votre box ! Comme ça, que ce soit votre Jellyfin de cyberpirate, votre Nextcloud ou votre Gitea... tous deviennent accessibles depuis n'importe où, avec les certificats Let's Encrypt automatiques derrière qui vont bien.
Sous le capot, c'est du NAT traversal intelligent. Même derrière un CGNAT Orange ou un firewall restrictif de chez Free, les tunnels WireGuard trouvent, comme la vie dans Jurassic Park, toujours leur chemin via UDP. Pas besoin de DDNS, pas besoin de supplier votre FAI pour une IP fixe. Par contre, si vous avez déjà galéré avec du port forwarding sur une Livebox 5, vous savez à quel point c'est appréciable !
D'ailleurs, côté sécurité c'est carrément différent d'un VPN mesh classique type Tailscale . Au lieu de filer l'accès à tout un réseau (et prier pour que personne ne fasse n'importe quoi), Pangolin fonctionne en zero-trust : Chaque utilisateur n'accède qu'aux ressources que vous avez explicitement définies. SSH, RDP, bases de données, apps web... vous choisissez qui voit quoi et y'a même du MFA, du geo-blocking, voire du blocage par ASN si le cœur vous en dit.
Côté architecture, c'est un petit zoo : Pangolin (le serveur en TypeScript), Gerbil (le tunneling WireGuard), Newt (le connecteur réseau local) et Traefik comme reverse proxy. Oui, y'a un genre de thème "animaux fouisseurs"... à vrai dire c'est assez mignon tant que ça trimballe pas des virus. Et des clients natifs existent pour Mac, Windows, Linux, iOS et Android, pas forcément courant pour un projet de cette taille.
Pour l'auth, ça supporte Azure AD, Google, ou n'importe quel provider OAuth2/OIDC. Du coup, si vous utilisez déjà Pocket ID pour votre SSO passkey, ça s'emboîte bien (qui a dit "comme papa" ??). Pangolin c'est donc le top pour disposer d'un accès public à vos services (là où Tailscale gère le mesh privé).
Attention quand même, y'a 4 ports à ouvrir sur votre VPS : 80 et 443 en TCP (classique), plus 51820 et 21820 en UDP pour les tunnels WireGuard. Oubliez pas le 21820 sinon les clients ne se connecteront pas. La licence est dual : AGPL-3 pour la Community Edition (gratuite), et une licence commerciale pour l'Enterprise (gratuite aussi pour un usage perso et les boîtes sous 100K$ de CA). Si vous ne voulez pas gérer l'infra, y'a aussi une offre cloud managée et un installer one-click sur DigitalOcean.
CrowdSec , que j'adore, est même intégrable en option pour ajouter une couche de sécurité collaborative, et si vous utilisiez Nginx Proxy Manager avant, la migration vaut le coup d'être envisagée.
Bref, si votre stack self-hosted ressemble à un millefeuille de conteneurs, Pangolin mérite clairement un essai poussé. Et un grand merci à Tom Nook pour le partage !