Depuis le 23 juin, Microsoft déploie sur Windows 11 une nouvelle fonction de récupération baptisée point-in-time restore, et il y a de bonnes chances qu'elle tourne déjà sur votre PC sans que vous l'ayez demandé. En effet, sur les éditions Home et les Pro non gérées en entreprise, elle est allumée par défaut dès que votre disque système dépasse 200 Go.

Le principe ressemble à ce que fait ce bon vieux point de restauration, sauf qu'il va beaucoup plus loin ! Toutes les 24 heures environ, Windows capture en arrière-plan un instantané complet de la machine via le service VSS (Volume Shadow Copy). Le système, les applications, les réglages... et cette fois vos fichiers locaux aussi !! Woohoo ! Et oui, aussi bizarre que cela puisse paraître, l'ancien System Restore ne touchait jamais vos documents.

Celui-là embarque enfin absolument tout !

Comme ça, en cas de mise à jour foireuse ou de PC qui part en vrille (ça n'arrive JAMAIS sous Windows, c'est bien connu ^^), vous redémarrez dans l'environnement de récupération, vous choisissez un instantané, et la machine revient à son état d'il y a quelques heures en quelques minutes.

Et c'est là qu'il faut faire gaffe car si vous restaurez un instantané d'il y a 48 heures, ça ne remontera pas que le système. Tout ce que vous avez créé depuis disparaîtra... Vos fichiers, vos applications installées, vos mots de passe enregistrés, les certificats, les clés... TOUT ce qui est postérieur à votre date de restauration sera balayé. Il n'y a que vos données OneDrive dans le cloud qui seront épargnées, mais tout ce qui vit en local repartira à la version de l'instantané.

Donc, autrement dit, ce truc peut vous sauver après un update raté mais il peut aussi vous faire perdre une journée de boulot si vous cliquez sans réfléchir.

Autre point à garder en tête, ce n'est pas une sauvegarde. La rétention plafonne à 72 heures, et passé ce délai les vieux instantanés sont supprimés automatiquement, en commençant par les plus anciens. Donc oubliez l'idée de récupérer un fichier effacé la semaine dernière, on est sur du rollback court terme pour se sortir d'un mauvais pas, et pas sur un coffre-fort de vos archives.

Côté stockage, la fonction se réserve par défaut 2% de votre disque, jusqu'à 50 Go maximum, en la jouant maligne puisque l'espace n'est pas bloqué à l'avance. En effet, VSS pioche dedans quand il en a besoin et rend la place quand ça devient tendu. Et si vous passez sous 20 Go de libre, les instantanés dégageront dans la joie et la bonne humeur pour laisser respirer le système.

Voilà, si vous êtes super chaud et dans la panade et que vous voulez restaurer votre Windows, tout se passe en local depuis WinRE, dans Troubleshoot puis Point-in-time restore, et si votre disque est chiffré il faudra que vous ayez la fameuse clé de récupération BitLocker sous la main sinon vous restez à la porte de votre propre machine.

Notez aussi qu'après une restauration, Recall se coupe et vous redemandera votre accord avant de reprendre ses captures. De plus, sur une machine à plusieurs volumes, seul le disque système est restauré, et le reste ne bougera pas. Donc, ça peut être pas mal de garder le système sur un disque et vos données sur l'autre. Comme ça, vous pouvez restaurer votre système quand vous voulez sans perdre vos données. Et ces données, il faudra les sauvegarder par un autre moyen, évidemment.

Ah et si vous êtes passé de Home à Pro entre-temps, les instantanés créés sous l'ancienne édition ne sont plus utilisables.

Enfin, seule l'édition Enterprise peut ajuster la fréquence et la durée de rétention. Sur Home et Pro, vous subirez donc les valeurs par défaut rikiki, à prendre ou à laisser, même si vous pouvez toujours couper la fonction dans Paramètres > Système > Récupération.

Voilà, cette restauration express s'inscrit dans le grand chantier de Microsoft pour rendre Windows plus solide et plus facile à réparer après le fiasco CrowdStrike. L'intention est bonne, et l'approche 100% locale, sans passer par le cloud, est plutôt rassurante je trouve. Reste juste à ne pas confondre filet de sécurité et sauvegarde, et à garder en tête que ça travaille en silence chez vous.

Bref, faites un tour dans Paramètres > Système > Récupération pour voir si c'est actif et combien de place ça grignote.

Et pour tout ce qui compte vraiment, gardez une vraie sauvegarde à côté.

Merci à Tijer pour le lien !

Source : Microsoft Learn

Snif, snif, macOS 28 ne lira plus vos disques chiffrés en Mac OS Étendu . C'est écrit dans un document de support Apple publié le 7 juillet, alors si vous stockiez là-dessus vos photos de 2014, vos factures, votre mémoire de fac ou une sauvegarde Time Machine chiffrée de l'ancienne époque, bah c'est grave le moment de vous en occuper.

Pas de panique cela dit, seul le chiffrement dégage. Un volume HFS+ non chiffré restera donc lisible sous macOS 28 et après. Ce qui part à la benne, c'est surtout CoreStorage, la couche qui chiffre ces volumes... Et c'est aussi elle qui fait tourner les Fusion Drives avec lesquels j'aimais bien m'amuser à l'époque. Mais hormis ça, rien ne change.

Et vu qu'APFS est le format par défaut depuis High Sierra en 2017, les disques concernés ont, pour la plupart, grosso modo 9 ans au compteur, donc ce sont des disques d'archives que vous ne branchez jamais j'imagine... jusqu'au jour où vous en avez vraiment besoin évidemment !

Alors pour vérifier si vous êtes concerné, ouvrez l'Utilitaire de disque et regardez le libellé sous le nom de vos volumes externes. S'il affiche "CoreStorage Logical Volume" avec la mention "Encrypted", c'est lui. Et si vous êtes sous macOS 26, le système peut aussi vous envoyer une notification quand il détecte un disque qui ne passera pas le cap. Même si ça fait chier, c'est quand même assez réglo de la part d'Apple de prévenir 1 an à l'avance.

Côté solutions, Apple vous laisse 2 portes de sortie. La douce d'abord... Vous faites un clic droit sur le volume dans le Finder pour le déchiffrer, et si le cœur vous en dit, vous le convertissez ensuite en APFS sans perdre le moindre fichier. Ou alors la radicale ensuite où vous reformatez le volume direct en APFS. Attention hein, ça efface tout, et définitivement donc on sauvegarde bien avant de jouer à ça, les amis ^^.

Apple prévient aussi que le déchiffrement prend beaucoup de temps, spécialement si le volume est gros. Du coup lancez la machine avant d'aller vous coucher, et vous pourrez ensuite faire un petit diskutil cs list dans le Terminal pour savoir où ça en est !

Malheureusement, la méthode douce, vous pouvez l'oublier pour les disques de sauvegarde Time Machine chiffrés. Howard Oakley en parlait déjà sur Eclectic Light Company 3 semaines avant que les gros sites américains ne captent le truc et il a expliqué pourquoi dans son article. En fait, ces vieilles sauvegardes s'appuient sur des liens en dur de répertoires, et c'est un mécanisme qu'APFS ne sait tout simplement pas reproduire.

Du coup, ces sauvegardes-là, c'est impossible de les convertir, donc... il faudra repartir de zéro avec une sauvegarde toute neuve. Rassurez-vous, vos fichiers actuels ne craignent rien. Par contre, tout votre historique de versions restera coincé sur le vieux disque, que vous pourrez encore lire sous macOS 26 et 27, et après, ce sera terminé.

Donc si vous êtes motivé (et avez-vous bien le choix ?), vous branchez vos vieux disques, vous faites des backups, vous checkez le format, vous déchiffrez ou reformatez ce qu'il faut puis vous relancez une sauvegarde propre, que vous pouvez d'ailleurs accélérer avec cette astuce . Allez, un petit week-end là-dessus à le laisser tourner et c'est plié !

Bref, prenez 10 minutes maintenant, plutôt que de vous retrouver dans 1 an devant un disque qui refusera de répondre. Votre moi du futur vous dira merci !!

Source

OpenZFS 2.4.2 est sortie ce 12 mai, et c'est une mise à jour qu'attendaient pas mal de gens qui font tourner du Linux 7.0 (le tout dernier noyau Linux stable). OpenZFS, pour ceux qui ne suivent pas, c'est le portage libre du célèbre système de fichiers ZFS originellement développé par Sun Microsystems, et désormais maintenu par une communauté autour de FreeBSD et Linux.

ZFS, en gros, c'est ce qui permet de gérer des pools de disques de plusieurs téraoctets avec snapshots, compression, déduplication et auto-réparation des données. Le genre d'outil qu'on retrouve dans les NAS sérieux et les serveurs de stockage.

La grosse nouveauté de cette 2.4.2, c'est le support du noyau Linux 7.0 stable. La version précédente 2.4.1 plafonnait à Linux 6.19, et beaucoup d'admins qui ont mis à jour leur distribution se retrouvaient avec un système qui refusait de charger le module ZFS.

C'est résolu. La compatibilité historique est aussi maintenue jusqu'à Linux 4.18, ce qui permet aux serveurs un peu anciens de continuer à profiter des dernières corrections. Côté BSD, FreeBSD 13.3 et plus restent supportés.

Dans le détail des changements, on trouve des corrections sur initramfs (le système qui charge le noyau au démarrage), le support de l'appel système POSIX_FADV_DONTNEED qui permet à une application de dire au noyau qu'elle n'a plus besoin d'un fichier en cache (ce qui libère de la RAM), les premiers patchs préparatoires pour Linux 7.1, et un durcissement des en-têtes SPDX (les balises de licence en tête de chaque fichier). Rien de spectaculaire, mais c'est ce genre de maintenance discrète qui fait tenir un projet sur la durée.

Pour ceux qui ne veulent pas passer sur la branche 2.4, l'équipe a aussi publié OpenZFS 2.3.7 en parallèle. Mêmes corrections de stabilité, kernels supportés un peu plus anciens. Ça permet aux infrastructures conservatrices de rester sur leur branche sans rater les fixes importants.

Si vous tournez sur Proxmox, TrueNAS, ou un Linux avec ZFS en racine, allez donc vérifier la version dispo dans vos dépôts. La 2.4.2 va probablement arriver sous quelques jours.

Source : Phoronix

Edit du 22/12/2025 : Bonne nouvelle ! Le développeur a finalement récupéré son compte. Un employé d'Apple Executive Relations basé à Singapour l'a contacté pour lui annoncer que tout était réglé. Il s'avère que la carte cadeau qu'il avait essayé d'utiliser avait déjà été "consommée" d'une manière ou d'une autre (probablement du tampering classique de carte cadeau), et son compte s'est retrouvé flaggé à cause de ça. Apple lui a conseillé de n'acheter des cartes cadeaux que directement chez eux et quand il a demandé si ça signifiait que leur chaîne d'approvisionnement (Blackhawk Network, InComm et autres revendeurs) était peu fiable, Apple a refusé de commenter. Comme quoi, même après 25 ans de fidélité, faut quand même gueuler un bon coup pour que ça bouge...

Vous vous souvenez de mes conseils sur les backups ? Ceux que je vous rabâche régulièrement depuis des années ? Hé bien voici une histoire qui va vous donner envie de les suivre une bonne fois pour toutes.

Dr Paris Buttfield-Addison, c'est un développeur Apple depuis 25 ans. Le mec a écrit plus de 20 bouquins sur Objective-C et Swift, il co-organise le plus ancien événement développeur Apple non-officiel... Bref, c'est pas un random qui a téléchargé une app météo une fois. C'est un évangéliste Apple depuis 30 ans.

Et bien du jour au lendemain, son compte Apple ID a été fermé. Sans explication. Sans recours. Sans rien.

L'élément déclencheur ? Il a essayé de racheter une carte cadeau Apple de 500 dollars pour payer son abonnement iCloud+ de 6 To. Le code a foiré, le vendeur lui a proposé un remplacement, et quelques temps après... boom, compte verrouillé.

Résultat : environ 30 000 dollars de matos Apple devenu inutilisable, des milliers de dollars de logiciels et médias achetés auxquels il n'a plus accès, plus d'iMessage, et surtout des téraoctets de photos de famille qu'il ne peut plus récupérer. 25 ans de souvenirs numériques, volatilisés.

Le support Apple ? Réponse standard : fermé pour "conformité avec les conditions". Pas d'explication. Zéro escalade possible. Et comme conseil : créer un nouveau compte. Sauf que ça pourrait aussi le faire bannir ce nouveau compte. Logique Apple...

Et le pompon ? On lui a également suggéré de se présenter physiquement au siège australien d'Apple. Comme si le mec allait prendre un billet d'avion pour aller plaider sa cause en personne. C'est difficilement compréhensible comme réponse venant d'une boîte qui vaut 3000 milliards de dollars.

Le truc, c'est que cette histoire peut arriver à n'importe qui. Que ce soit chez Apple, Google ou Microsoft, vous êtes à la merci d'un algorithme qui décide un beau matin que votre compte est suspect. Et bonne chance pour trouver un interlocuteur prêt à mouiller sa chemise pour vous. Spoiler : y'en a pas.

Moi-même j'ai eu tellement de problèmes de synchro avec iCloud au fil des années que j'ai perdu des fichiers. C'est de la merde, vraiment. Optez pour un truc mieux si vous le pouvez.

Du coup, comment éviter ça ? L'idéal c'est l'auto-hébergement si vous avez le temps et les compétences. Sinon, au minimum, faites des backups réguliers de vos données. Pour Apple Notes par exemple, y'a un outil qui s'appelle Exporter qui permet d'exporter toutes vos notes vers du Markdown ou du HTML. Comme ça le jour où Tim Cook décide que votre tronche lui revient pas, vous aurez au moins une copie de vos données quelque part.

Bref, ne faites jamais confiance à 100% à ces plateformes avec vos données les plus précieuses. Elles peuvent vous couper l'accès du jour au lendemain, et vous n'aurez aucun recours...

Source : hey.paris

Vous avez des dossiers sensibles que vous aimeriez chiffrer avant de les balancer sur un cloud ou un disque externe ? Ça tombe bien, je vous ai trouvé un petit outil en Rust qui va vous plaire.

Obsidenc , c'est son nom, est un utilitaire de chiffrement que son créateur qualifie de "paranoid-grade". Et après avoir jeté un œil au code source, je peux vous dire que c'est pas du marketing puisque ce truc archive votre répertoire en TAR et le chiffre avec XChaCha20-Poly1305, un algorithme AEAD moderne qui assure à la fois la confidentialité et l'intégrité de vos données.

Côté dérivation de clé, ça utilise Argon2id conforme à la RFC 9106. Pour les non-initiés, Argon2id c'est l'algo qui a gagné le Password Hashing Competition et qui est spécifiquement conçu pour résister aux attaques par GPU et circuits spécialisés (ASIC). L'outil adapte automatiquement les paramètres à votre machine en utilisant 85% de votre RAM disponible (entre 512 Mo minimum et 2 Go maximum) afin de rendre le brute-force astronomiquement coûteux. Et si vous avez moins de RAM dispo, il compense en augmentant le nombre d'itérations.

C'est du code Rust bien propre qui utilise les bibliothèques cryptographiques RustCrypto (bien auditées par la communauté) et le code implémente des bonnes pratiques de sécurité comme le memory locking (mlock sur Unix, VirtualLock sur Windows) pour éviter que vos clés se retrouvent dans le swap, et le zeroize pour effacer la mémoire sensible après utilisation.

Vous compilez ça avec cargo build --release, puis pour chiffrer un dossier :

obsidenc encrypt ~/mon-dossier ~/mon-dossier.oen

Pour déchiffrer :

obsidenc decrypt ~/mon-dossier.oen ~/mon-dossier-dechiffre

Le mot de passe doit faire minimum 20 caractères (pas de négociation possible, déso pas déso) et vous devez le confirmer deux fois. Vous pouvez aussi ajouter un fichier de clé en plus du mot de passe pour du 2FA old-school.

L'outil a aussi quelques protections défensives sympas. Par exemple, il refuse les symlinks (vecteur d'attaque classique), limite le nombre de fichiers à 1 million et la longueur des chemins à 4096 caractères pour éviter les zip bombs. Sur les systèmes Unix, il vérifie même que votre fichier de clé n'est pas lisible par tout le monde (chmod 600 obligatoire).

Cet outil part du principe qu'un attaquant peut avoir accès à votre fichier chiffré et dispose de temps illimité pour tenter de le casser, du coup, tout est conçu pour rendre l'attaque offline la plus douloureuse possible.

Bref, si vous cherchez un moyen de sauvegarder vos dossiers sensibles de manière vraiment sécurisée avant de les balancer sur un cloud ou un disque externe, obsidenc fait le taf et en plus c'est open source (MIT/Apache 2.0) !

Vous savez, ce script bash de backup que vous avez écrit en 2018 et que vous n’osez plus toucher ? Celui avec les 150 lignes de mysqldump + tar + gzip + aws s3 cp qui marche à moitié et que vous relancez manuellement quand il plante ?

Hé bien vous allez pouvoir le foutre à la poubelle parce que maintenant y’a GoBackup !

GoBackup c’est un binaire codé en Go qui remplace tous vos scripts de backup maison d’un coup. MySQL, PostgreSQL, MongoDB, Redis, peu importe. Local, FTP, S3, Google Cloud, Azure, peu importe. Vous installez, vous configurez un fichier YAML, et c’est fini.

Ensuite, vous n’aurez plus jamais besoin de retoucher à tout ce bordel.

Avant GoBackup y’avait backup/backup, une gem Ruby qui faisait exactement ce job avec de la sauvegarde automatique, multi-bases, multi-destinations et c’était bien. Sauf que Ruby c’est lourd et les dépendances Ruby c’est l’enfer. Du coup le projet est mort tout doucement. Heureusement, huacnlee, un dev chinois, en a eu marre alors il a tout réécrit en Go. Zéro dépendance externe et un seul binaire compilé (installable aussi avec Brew pour ceux qui sont sous macOS).

Vous pouvez l’installer comme ceci (vérifiez le script) :

curl -sSL https://gobackup.github.io/install | sh

Ou via homebrew comme ceci :

brew install gobackup

Avec GoBackup, vous définissez vos bases de données, vos fichiers à archiver, vos destinations de stockage, votre planning, tout dans un fichier YAML propre et ensuite le binaire gère tout : Compression, chiffrement, upload, rotation des backups, notifications si ça échoue…etc. Bref, tout ce que vous faisiez à la main avec vos scripts pourris.

Et GoBackup est pas juste un CLI (Interface en ligne de commande). C’est un CLI + un daemon + une Web UI + un scheduler. Comme ça vous lancez “gobackup start” et ça tourne en background.

Le daemon surveille alors le planning défini dans votre config et lance les backups automatiquement. Et l’interface web vous permet de voir l’état des backups, les logs, les erreurs.

Avec GoBackup, vous remplacez littéralement 5 outils en un : votre script bash + cron + un monitoring pourri + un truc pour lire les logs + l’interface d’admin que vous avez jamais eu le temps de faire.

Votre config ressemble à ça :

models:
 mon_app:
 compress:
 type: tgz
 databases:
 mon_mysql:
 type: mysql
 host: localhost
 database: ma_base
 username: user
 password: $MYSQL_PASSWORD
 storages:
 mon_s3:
 type: s3
 bucket: mes-backups
 region: eu-west-1
 access_key_id: $AWS_KEY
 secret_access_key: $AWS_SECRET
 schedule:
 every: 1day
 at: "04:05"

Et c’est tout. Avec ce fichier, GoBackup dump votre base MySQL tous les jours à 4h05, compresse en .tar.gz, chiffre si vous voulez, et upload sur S3. Et si ça échoue vous recevez une notif. Et si ça marche vous avez les logs comme ça, pas besoin de surveiller, ni de débugger à 3h du matin parce que le backup a planté et que vous avez perdu 6 mois de données.

Notez quand même que GoBackup fait du backup classique, et pas du backup incrémental intelligent à la Restic ou à la Borg donc si vous avez 500 GB de données à backup tous les jours vous allez peut-être préférer un outil plus sophistiqué mais pour 90% des cas d’usage sysadmin standard, GoBackup suffira largement.

Votre script bash dégeu a eu une belle vie, il peut maintenant partir à la retraite.

Vous vous souvenez de cette règle de base en informatique, que je vous rabâche régulièrement, et qui dit de toujours avoir plusieurs sauvegardes de vos données critiques ?

Hé bien apparemment, le gouvernement sud-coréen a zappé ce cours, car le 26 septembre dernier, un incendie s’est produit au centre de données NIRS (National Information Resources Service) à Daejeon et a cramé 858 téraoctets de fichiers gouvernementaux . Et y’a pas de backup. Nada.

Le feu a démarré pendant une opération de maintenance sur une batterie lithium-ion dans laquelle une cellule a lâché , déclenchant ce qu’on appelle un emballement thermique… En gros, la batterie s’est transformée en bombe incendiaire et le brasier s’est propagé dans la salle serveur du cinquième étage, faisant tomber 647 services en ligne gouvernementaux d’un coup. Parmi eux, 96 systèmes critiques ont été directement détruits, et 551 autres ont été coupés préventivement pour éviter que la chaleur les bousille aussi.

Le système qui a morflé le plus, c’est G-Drive, le cloud de stockage utilisé par les fonctionnaires sud-coréens depuis 2018. Environ 750 000 employés du gouvernement central peuvent stocker leurs documents de travail dessus, mais seulement 125 000 l’utilisaient vraiment. Chacun disposait d’environ 30 Go d’espace de stockage, ce qui fait qu’au total le système contenait 858 To de données de travail accumulées sur huit ans.

Snif…

Mais attendez, je ne vous ai pas encore donné la raison pour laquelle il n’y avait aucune sauvegarde externe. En fait, leur G-Drive est conçu comme un système de stockage haute capacité, mais basse performance, et ils ont des contraintes réglementaires qui imposent un stockage exclusif sur cette plateforme afin d’éviter les fuites de données.

Autrement dit, pour se prémunir contre les risques de fuite, ils ont créé un point de défaillance unique. Bravo !

Du coup, quand l’incendie a détruit les serveurs physiques, tout est parti en fumée. Huit ans de documents de travail pour certains ministères, qui ont été complètement perdus… C’est surtout le ministère de la Gestion du Personnel qui s’est pris la claque la plus violente parce qu’il avait rendu obligatoire le stockage de tous les documents sur G-Drive uniquement. D’autres organismes comme le Bureau de Coordination des Politiques Gouvernementales, qui utilisaient moins la plateforme, ont moins souffert.

Bref, les autorités essaient maintenant de récupérer ce qu’elles peuvent depuis d’autres sources. Y’a des petits bouts de fichiers sauvegardés localement sur les ordinateurs personnels des fonctionnaires le mois précédent, les emails, les documents officiels validés et les archives papier… Bref, pour tous les documents officiels passés par des processus d’approbation formels, il y a un espoir de récupération via leur système OnNara (un autre système gouvernemental qui stocke les rapports finaux), mais pour tout le reste (brouillons, fichiers de travail en cours, notes internes…etc.) c’est mort de chez mort…

Le ministère de l’Intérieur a expliqué que la plupart des systèmes du centre de Daejeon sont normalement sauvegardés quotidiennement sur des équipements séparés dans le même centre ET dans une installation de backup distante. Mais G-Drive, lui, n’avait pas, comme je vous le disais, cette possibilité.

Évidemment, cet incident a déclenché une vague de critiques acerbes sur la gestion des données gouvernementales sud-coréennes. Un système de backup en miroir en temps réel qui duplique le serveur principal pour assurer la continuité de service en cas de panne, était complètement absent de l’infrastructure et pour un système aussi critique que le stockage de documents de 750 000 fonctionnaires, c’est difficilement compréhensible.

Voilà donc le gouvernement estime qu’il faudra jusqu’à un mois pour récupérer complètement les 96 systèmes de base directement endommagés par l’incendie et pour G-Drive et ses 858 To de données, par contre, c’est une autre histoire, car sans backup, les données sont définitivement perdues.

De plus, cet incendie déclenche actuellement un genre d’examen mondial des batteries lithium-ion dans les datacenters et des architectures de plan de reprise d’activité (PRA). Les batteries lithium-ion sont en effet utilisées partout pour l’alimentation de secours, mais leur risque d’emballement thermique en cas de défaillance pose de sérieuses questions sur leur place dans des infrastructures critiques…

Bref, je souhaite bon courage aux Coréens, et j’espère que tout le monde saura tirer des enseignements de ce malheureux incendie…

Source

Vous avez des milliers de notes éparpillées dans Evernote, Notion, Google Keep ou ailleurs, et à juste titre, vous commencez à flipper parce que votre app favorite devient payante ou menace de fermer ? Heureusement, il y a Jimmy qui va pouvoir vous aider dans ces épreuves de la vie ^^ !

Développé par marph91, Jimmy est donc un convertisseur universel de notes qui transforme tout en Markdown. Il gère plus de 40 applications différentes et tourne sur Linux, Windows et macOS sans aucune dépendance. Vous téléchargez l’exécutable, vous le lancez, et c’est parti.

Jimmy supporte une liste impressionnante d’applications : Anki, Anytype, Bear, Cacher, CherryTree, Day One, Drafts, Evernote, Facebook, Google Docs, Google Keep, Joplin, Notion, Obsidian, QOwnNotes, Roam Research, Simplenote, Telegram, Tiddlywiki, UpNote, Zettelkasten, Zim, Zoho Notebook, et j’en passe.

Il gère aussi les formats classiques comme DOCX, ODT, HTML, EPUB, CSV et même les Jupyter Notebooks. Par contre, pas d’Apple Notes dans le lot… Pour celui-là, vous devrez utiliser Exporter .

Jimmy propose deux modes d’utilisation. Soit en ligne de commande (CLI) pour les scripteurs, et une interface texte interactive (TUI) pour les autres.

Par exemple, pour convertir un seul fichier, faites :

jimmy-linux cli mon_document.docx

jimmy-linux cli /chemin/vers/mes/notes

jimmy-linux cli takeout-20240401.zip --format google_keep

jimmy-linux cli Evernote_backup.enex

Vous venez de lancer un bon gros rsync en prod pour migrer 3 téraoctets de données et votre boss vous sur-saoule toutes les 10 minutes avec des : “Alors, ça en est où ?” en boucle et vous, en bonne victime, vous répondez “Ça avance chef, ça avance…”.

On peut faire mieux non ? Et oui, avec rsyncy qui vous permet au lieu d’avoir un rsync muet qui vous laisse dans le noir, de profiter d’une vraie barre de progression visuelle. Comme ça, vous voyez le pourcentage d’avancement, la vitesse de transfert, le volume copié, le temps écoulé, l’ETA, le nombre de fichiers traités… Bref, toutes les infos pour répondre factuellement à votre hiérarchie et prendre des décisions éclairées de grand professionnel qui aura bientôt une augmentation de salaire ^^.

L’installation est super simple. Vous avez plusieurs options selon votre setup :

# One-liner universel
curl https://laktak.github.io/rsyncy.sh|bash

# Sur macOS avec Homebrew
brew install rsyncy

# Avec Go
go install github.com/laktak/rsyncy/v2@latest

# Avec pipx (version Python)
pipx install rsyncy

rsyncy -a /source/ /destination/

rsync -a --info=progress2 -hv /source/ /destination/ | rsyncy

NO_COLOR=1 rsyncy /source/ /destination/