Si vous avez déjà installé Nextcloud sur un serveur, vous savez que c'est pas une partie de plaisir ! La stack PHP + MySQL, les mises à jour qui cassent tout, les performances qui s'effondrent dès que vous dépassez 50 utilisateurs... Relouuu.

Mais c'est là qu' OpenCloud débarque avec une approche radicalement différente puisque tout est écrit en Go, y'a zéro base de données, et l'installation se fait en deux commandes sur n'importe quel serveur à 5 balles par mois.

OpenCloud, en fait, c'est un fork d'ownCloud Infinite Scale (OCIS). Les développeurs du projet original chez Heinlein Group ont quitté ownCloud, forké le code, et relancé le tout sous licence Apache 2.0. Du coup, c'est pas un projet qui part de zéro mais une réécriture déjà très mature qui tourne en prod.

Là où Nextcloud utilise une base MySQL ou PostgreSQL pour stocker les métadonnées, OpenCloud balance donc tout dans le système de fichiers. Pas de SGBD ce qui veut dire pas de migration de base à gérer ni de tables corrompues après un crash. Tout atterrit dans le dossier $HOME/.opencloud/ et c'est réglé. Donc si vous savez faire un rsync, vous savez aussi faire une sauvegarde complète de votre instance. Oui la vie est belle !

Côté fonctionnalités, on retrouve donc le partage de fichiers, la collaboration en temps réel avec une suite bureautique intégrée, le chiffrement, le versioning (pratique contre les ransomwares), l'authentification via OpenID Connect... bref tout le classique d'un cloud privé correct.

Maintenant, le problème je trouve, c'est que l'écosystème d'apps est pas forcément au niveau de Nextcloud. Le CalDAV/CardDAV passe par Radicale en conteneur séparé (pas intégré au core), y'a pas d'app Notes ni de client mail intégré. Donc si vous avez besoin de tout ça, Nextcloud reste le bon choix. Mais bon, pour du stockage et de la collaboration pure, c'est clairement plus léger (genre 200 Mo de RAM au lieu de 2 Go pour Nextcloud) et surtout plus rapide.

D'ailleurs, l'architecture microservices en Go fait que ça scale nettement mieux.

Maintenant, pour installer ça, le plus simple c'est Docker Compose. Le repo opencloud-compose vous propose même des configs prêtes à l'emploi. À vrai dire, si vous êtes du genre à auto-héberger vos services , c'est un candidat sérieux pour remplacer votre Nextcloud donc si vous avez surtout besoin de fichiers et de collaboration, ça vaut le test. D'ailleurs, comme OpenCloud utilise OIDC pour l'auth, Pocket ID s'intègre pile poil avec pour du SSO sans mot de passe. Je dis ça, je dis rien ^^.

Bref, si Nextcloud vous gonfle avec sa lourdeur PHP et ses 47 tables MySQL, OpenCloud mérite un bon petit coup d'oeil !

Merci à fredix pour le lien !

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 .

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

Pour faire tourner du JavaScript côté serveur, y'a pas que Node.js dans la vie. Y'a maintenant workerd (prononcez "worker-dee"), qui est le runtime open source de Cloudflare, celui-là même qui fait tourner les Workers en prod (le service tourne depuis 2017, le runtime est open source depuis 2022), et que vous pouvez l'installer sur votre Debian, votre Mac ou même votre PC Windows avec un simple npx.

Mais alors pourquoi s'embêter avec un énième runtime JS ?

Hé bien parce que celui-ci n'est pas un runtime généraliste. C'est un vrai serveur HTTP pur et dur, basé sur le moteur V8 de Chrome, conçu pour recevoir des requêtes et y répondre. Pas de filesystem, pas d'accès disque sauvage... ici, votre code vit dans un isolate V8, bien cloisonné, et communique avec l'extérieur uniquement via des bindings explicites qu'on appelle des "capabilities". En gros, votre Worker ne peut accéder qu'aux ressources qu'on lui a branchées dans son fichier de config Cap'n Proto .

Et cela a plein d'avantages ! Par exemple, les attaques SSRF classiques c'est mort ! Et n'oubliez pas que c'est du JavaScript pur, donc y'a pas d'affreux require('fs') ni de child_process qui traîne.

Et le concept qui tue, ce sont les nanoservices. En fait, faut imaginer des microservices, mais qui tournent tous dans le même processus Linux, sur le même thread. Comme ça quand un nanoservice en appelle un autre, y'a zéro latence TCP, c'est un juste appel de fonction local !

Et vous pouvez en faire tourner des centaines sur un seul serveur parce que les API sont implémentées en C++ natif et tous les isolates V8 partagent le même code compilé en mémoire. C'est carrément pas intuitif, mais visiblement, ça tient la route.

Côté rétrocompatibilité, c'est cool puisque chaque Worker déclare une "date de compatibilité" dans son fichier .capnp. Comme ça, vous fixez compatibilityDate = "2024-06-15" et le runtime vous garantit que les API fetch() et WebCrypto se comporteront toujours comme à cette date-là, même si le binaire a été recompilé 200 fois depuis. Des releases sortant tous les jours, cette garantie n'est pas anecdotique !

Cap'n Proto, un format de sérialisation binaire créé par Kenton Varda, le même gars qui est derrière Protocol Buffers chez Google (excusez du peu). C'est un poil déroutant au début si vous êtes habitués au YAML ou au JSON, mais c'est très efficace et hyper rapide. Et pour ceux qui bossent déjà avec l'écosystème Cloudflare parce que vous avez l'Amérique qui coule dans les veines, sachez le runtime s'intègre nickel avec l'outil CLI Wrangler pour le dev local.

Par contre, attention, ce n'est PAS un sandbox sécurisé. Cloudflare le dit cash : si vous faites tourner du code potentiellement malveillant, faudra l'isoler dans une VM KVM ou un conteneur Docker. Hé oui les amis, en prod chez Cloudflare, y'a des couches de sécurité supplémentaires (isolation kernel Linux, patching V8 en urgence, segmentation par profil de risque) que le runtime seul ne fournit pas.

Le problème, c'est surtout Spectre et les bugs du moteur V8... car ça reste du code C++ compilé avec clang derrière. Après, pour du self-hosting de vos propres Workers sur votre VPS Ubuntu, c'est largement suffisant.

Maintenant pour tester concrétement c'est mui rapido.

npx workerd serve config.capnp

On archive nos photos avec Immich , nos documents avec Readur , nos mots de passe avec Vaultwarden ... mais nos emails ? Ah bah non, ça on les laisse chez Google en croisant les doigts pour que tout se passe bien jusqu'à la fin de nos jours. C'est quand même un peu dinguo quand on y réfléchit sérieusement.

Et pourtant, y'a des années de conversations là-dedans ! Des factures en pièce jointe, des confirmations de commande, des échanges pro avec votre comptable, des mots de passe envoyés en clair (oui, hélas, ça arrive encore). Du coup, quand un hébergeur mail décide de changer ses conditions générales ou de fermer boutique, tout part à la poubelle si vous n'y faites pas attention.

Eonvelope , c'est un outil open source en Python qui permet de sauvegarder automatiquement tout ça sur votre propre serveur et qui se lance avec un simple docker compose up.

Le truc, c'est que des outils comme Gmvault font déjà le boulot via cron, mais uniquement pour Gmail et en ligne de commande alors qu'Eonvelope, lui, un peu à la manière de Bichon , tourne en arrière-plan avec une interface web et archive en continu tous vos comptes. Franchement, c'est pas le même délire. Vous branchez vos comptes IMAP, POP3, Exchange, et même JMAP (le protocole poussé par Fastmail qui commence tout juste à se démocratiser), vous réglez la fréquence, et hop, vos mails atterrissent dans votre instance sans que vous ayez à y penser.

Attention par contre, c'est de l'archivage, pas un client mail... vous ne répondrez pas à vos mails depuis l'interface.

Côté installation, c'est du Docker avec seulement 2 conteneurs, le serveur web et la base de données. En fait, comptez 5 minutes chrono si vous avez déjà un serveur dédié ou un VPS, le fichier docker-compose.yml est fourni et les variables d'environnement sont bien documentées sur ReadTheDocs . Y'a même un mode basse consommation pour ceux qui font tourner ça sur un Raspberry Pi 4 avec 2 Go de RAM ou un petit Synology ! SSL et HTTPS sont inclus par défaut, et l'authentification multifacteur aussi.

Mais le vrai point fort, c'est les intégrations avec le reste de l'écosystème self-hosted. Concrètement, vous pouvez envoyer vos pièces jointes PDF vers Paperless-ngx pour l'OCR, les photos vers Immich, et exporter vos contacts vers votre carnet d'adresses Nextcloud. Y'a aussi un endpoint Prometheus pour brancher Grafana et suivre vos stats d'archivage. En gros, si vous avez déjà un homelab qui tourne, ça vient se brancher dessus comme une pièce de Lego.

L'interface web est en PWA (donc utilisable sur votre téléphone), avec un moteur de recherche, du filtrage par date et par expéditeur, des fils de conversation reconstitués et de l'import/export en EML et MBOX. Franchement, c'est propre. Y'a aussi une API REST pour ceux qui préfèrent scripter par-dessus plutôt que de passer par l'interface.

Le projet est sous licence AGPLv3 et son dev déclare l'utiliser lui-même au quotidien, ce qui est souvent bon signe. Notez que la migration depuis un backup existant n'est pas forcément fluide mais qui ne tente rien n'a rien !

Bref, ça comble un vrai manque dans la stack de nos machins auto-hébergés mais je trouve que l'approche est clairement plus intégrée que ce qui existe (genre MailPiler ou un combo fetchmail+dovecot). À surveiller donc !

Source

Depuis qu'Amazon a supprimé le "Télécharger & transféré via USB" de nos ebooks Kindle en février de l'année dernière je suis triste de fou... Si vous n'avez pas de Kindle, en fait ça veut dire que nos fichiers .azw3 restent prisonniers de l'app Kindle, et qu'il est impossible de les balancer ensuite sur une liseuse Kobo ou dans Calibre. Du coup, si vous voulez garder le contrôle sur vos e-bouquins, faut se retrousser les manches et héberger tout ça soi-même.

Alors voilà le topo pour ceux qui veulent reprendre leur bibliothèque en main.

Le vétéran du game, c'est Calibre . Depuis 2006, une base de données SQLite bien rangée, une communauté énorme et un écosystème de plugins (dont le fameux DeDRM pour récupérer vos ebooks verrouillés ). Le problème c'est que l'interface est restée coincée en 2006 et que la mise en place sur un serveur est plus complexe que les alternatives modernes. Ça marche, mais bon... c'est moche et c'est un peu pénible !

Pour mettre une jolie couche de peinture là-dessus, y'a aussi Calibre-Web qui ajoute une interface web potable. Et la version encore mieux, c'est Calibre-Web Automated (CWA) qui embarque tout dans un seul conteneur Docker (un docker-compose.yml et c'est plié)... avec sync Kobo, import via BookDrop (un dossier surveillé) et conversion EPUB/MOBI/AZW3 automatique. CWA consomme environ 160 Mo de RAM contre plus de 800 Mo pour Booklore (qui en Java peut taper dans le 1 Go+ à vide), ce qui est pas négligeable si vous tournez sur un Raspberry Pi ou un petit VPS.

D'ailleurs, parlons de Booklore . Sur le papier, c'est le Jellyfin des ebooks : metadata auto depuis Google Books, Goodreads et Amazon, sync OPDS avec Kobo et KOReader, Magic Shelves avec filtres automatiques, lecteur intégré pour EPUB, PDF et CBZ... Sauf que le dev a récemment pété un câble. Télémétrie cachée envoyée sans consentement, code largement généré par IA (du "AI slop" c'est-à-dire du code vomi par ChatGPT sans relecture), et quand la communauté a râlé, le mec a répondu en gros "si ça vous plaît pas, désinstallez". Puis il a posté des excuses... générées par ChatGPT. Grosse ambiance ouais ouais.

Pour ceux qui lisent aussi des comics et des mangas, Kavita est une alternative sérieuse. Léger, interface clean, lecteur web rapide, et ça gère aussi bien les EPUB que les CBZ. Y'a aussi Komga dans la même catégorie, plus orienté comics purs. Perso, Kavita est le choix le plus équilibré du lot parce que ça couvre ebooks ET comics sans se prendre la tête. Testé avec des bibliothèques de 50 000 fichiers et plus, ça tient clairement la route.

Et hop, la pépite que beaucoup ignorent c'est Audiobookshelf . À la base c'est fait pour les audiobooks, mais ça gère aussi très bien les EPUB. Le gros avantage c'est qu'un même bouquin peut appartenir à plusieurs séries (genre l'univers Cosmere de Sanderson avec Stormlight Archives ET Mistborn dedans).

Calibre ne le gère pas nativement (faut bidouiller avec des colonnes custom) mais le setup simple, y'a deux ans de retours positifs, et toujours pas de drama en vue.

Côté automatisation maintenant, c'est la zone dans le ter-ter les amis ! Readarr est officiellement abandonné, LazyLibrarian fait le taf mais l'interface est tellement chelou que franchement personne ne comprend ce qu'il regarde. Ah mais y'a aussi le petit nouveau Rreading Glasses , qui est un successeur en alpha (dispo sur Docker Hub ). Donc en attendant mieux, Shelfmark wrappe Prowlarr et pousse directement vos trouvailles vers Booklore ou CWA... ça retire au moins l'étape de la copie manuelle !

Readarr a été remplacé par Rreading-glasses

Je sais, ça fait beaucoup d'outils alors pour vous aider, sachez que le combo qui revient le plus souvent chez les gens qui ont tout essayé c'est CWA pour la gestion et le stockage, Kavita ou Audiobookshelf pour la lecture, et Shelfmark pour la recherche. Bon, c'est pas aussi sexy qu'un Plex clé en main, mais ça marche. Et si vous voulez juste un lecteur multi-plateforme sans vous prendre la tête avec un serveur, Readest est une option open source plutôt pas mal avec sync cross-device.

Bref, gardez un œil sur Rreading Glasses qui promet d'être le Sonarr des livres et en attendant, Calibre reste le cafard du self-hosting : moche, mais indestructible !

Faut le reconnaître, la doc et qui plus est, la doc réseau, c'est un peu le parent pauvre du homelab. Tout le monde sait qu'il faudrait la tenir à jour sur un petit wiki tout mignon mais personne le fait parce qu'on n'est pas cinglé et qu'on aime trop la vie pour ça. Heureusement, pour nous aider, y'a maintenant Scanopy qui est un outil open source qui scanne automatiquement votre réseau pour générer une topologie interactive incroyable qui se met à jour toute seule !

Pour l'installer, deux lignes suffisent :

curl -O https://raw.githubusercontent.com/scanopy/scanopy/refs/heads/main/docker-compose.yml
docker compose up -d

Un vieux smartphone Android, c'est quoi en fait ? Un bon petit quad-core, 1 ou 2 Go de RAM, et du WiFi. Soit de quoi largement servir des pages web finalement... Hé bien CompHost vous montre comment en faire un serveur en quelques commandes, sans rooter quoi que ce soi. Vous faut juste Termux et basta !

En gros, vous installez Termux depuis F-Droid sur n'importe quel Android 7+ (pour Android 5-6, y'a également une version spéciale dispo sur GitHub), vous tapez pkg update && pkg upgrade -y puis termux-setup-storage -y, et hop, vous avez un environnement Linux sur votre téléphone.

Un vieux téléphone qui sert des pages web, la classe quand même

De là, un pkg install python suivi d'un python -m http.server 8080 et votre serveur web tourne ! Pensez surtout à lancer termux-wake-lock pour éviter qu'Android tue le processus en arrière-plan, sinon votre super site web ne sera pas accessible longtemps.

Le wiki fournit aussi des fiches PDF, une cheatsheet Termux et des présentations annotées pour ceux qui voudraient par exemple animer un atelier. Bref, j'ai trouvé ça plutôt bien ficelé !

D'ailleurs, j'sais pas si vous vous souvenais, mais je vous avais déjà parlé de Far Computer qui héberge un site sur un Fairphone 2 avec PostmarketOS, sauf que CompHost a une approche un peu différente. En fait y'a pas besoin de flasher l'OS ni besoin d'avoir un PC Linux sous la main et encore moins un bootloader à déverrouiller. Vous installez une app, vous ouvrez un terminal, c'est parti. Du coup c'est bien plus accessible, même si faut quand même être prêt à taper quelques commandes.

Le truc sympa avec Termux, c'est que ça tourne dans une sandbox Android classique, donc sans root et le gestionnaire de paquets pkg donne accès à tout ce qu'il faut pour héberger ce que vous voulez comme Python, Node.js, nginx...

Et aussi bizarre que ça puisse paraitre, votre vieux Samsung de 2018 a largement les specs pour servir un site statique, une petite API ou même un wiki perso. Et vu que ces machins consomment que dalle en électricité (2-3 watts à otut casser), c'est carrément viable comme micro-serveur permanent branché dans un coin (surveillez quand même l'état de la batterie, les vieilles cellules Li-ion n'aiment pas forcement rester en charge 24/7).

Après côté limites, attention, c'est pas pour iPhone et pour les Android vraiment antiques (genre Android 4 et moins), le wiki renvoie vers PostmarketOS qui flashe une vraie distrib Linux sur le mobile... là c'est plus technique, par contre.

Ce projet CompHost est dispo sur GitLab et comme ça, au moins, plutôt que de jeter vos appareils, vous leur filez une utilité concrète. Puis ça permet de piger ce qu'est vraiment un serveur web... Et quand je vois que certains montent même des clusters Kubernetes avec des vieux smartphones , je me dit que y'a vraiment un filon à creuser côté recyclage / compostage de vieux matos.

Et qui sait, peut-être qu'un jour, Korben.info tournera sur l'un de ces trucs ?

Si vous auto-hébergez déjà des services chez vous, y'a un truc qui revient tout le temps c'est l'authentification. Chaque app a son propre login, ses propres mots de passe, et du coup vous finissez avec une ribambelle de comptes différents pour des trucs qui tournent sur le même serveur. Nextcloud par-ci, Jellyfin par-là, Gitea en prime... C'est con hein, mais c'est comme ça !

Pocket ID , c'est un provider OpenID Connect (OIDC) qui fait UNE chose et qui la fait bien : vous authentifier avec vos passkeys. Pas de mot de passe, pas de TOTP, pas de SMS... juste votre empreinte digitale via Touch ID, Face ID, Windows Hello, ou votre clé physique type YubiKey. Le projet tourne en Go côté serveur (un seul binaire de ~15 Mo) et SvelteKit pour l'interface, le tout sous licence BSD-2-Clause.

Bon, vous allez me dire "y'a déjà Keycloak pour ça". Sauf que Keycloak, c'est un monstre. Genre, vous voulez juste centraliser l'auth de votre Nextcloud et de votre Jellyfin, et vous vous retrouvez à configurer 47 fichiers XML. Pocket ID, c'est donc l'inverse... un simple docker compose up -d et hop, c'est lancé sur localhost:1411 ! En fait l'interface web est tellement propre que vous créez vos clients OIDC en 3 clics, plutôt que de passer 2 heures dans la doc.

D'ailleurs, le truc cool c'est la liste des intégrations. Il y a plus de 80 services compatibles, documentés avec des procédures pas à pas : Nextcloud, Immich, Grafana, Portainer, Proxmox, Vaultwarden, GitLab, Jellyfin... en gros tous les classiques du self-hosting. Si vous avez déjà mis en place Authelia pour protéger vos services derrière un reverse proxy , Pocket ID c'est le complément idéal côté SSO.

Attention par contre, y'a un prérequis : HTTPS obligatoire. C'est pas un caprice hein, c'est une contrainte technique de WebAuthn (le standard derrière les passkeys ). Du coup si votre homelab tourne en HTTP sur le réseau local genre http://192.168.1.x ... faudra d'abord passer par un reverse proxy avec certificat TLS. Caddy fait ça carrément bien avec ses certificats Let's Encrypt auto-gérés sur le port 443, c'est même plutôt facile à déployer. Il y a aussi Nginx Proxy Manager qui est génial pour tout ce qui est reverse proxy facile à implémenter !

Ensuite, côté installation, Pocket-ID vous donne le choix : Docker (le plus simple), standalone, Proxmox, Unraid, Kubernetes ou même NixOS.

Y'a aussi un système de groupes d'utilisateurs et des options de suivi pour savoir qui s'est connecté quand, depuis quelle IP. Pas mal hein, pour un outil qui tient dans un conteneur Docker de 50 Mo !

Bon, c'est pas non plus parfait hein. Le fait de n'accepter QUE les passkeys, ça veut dire que si un de vos utilisateurs n'a pas de device compatible (vieux navigateur, OS ancien), il sera coincé. Et si vous perdez votre YubiKey 5 NFC (lien affilié) sans avoir enregistré de passkey de secours sur un iPhone ou un Android... bah bon courage. C'est un choix délibéré des devs, mais faut quand même le savoir avant de migrer toute votre infra dessus.

Bref, simple, efficace, et ça fait pas semblant d'être autre chose. Ah et y'a une démo ici pour tester avant de tout casser sur votre serveur ^^.