Vous cherchez une app de prise de notes que vous pouvez héberger vous-même, sans dépendre d'un cloud propriétaire qui va analyser vos pensées les plus intimes pour vous balancer de la pub ciblée ?

Ça tombe bien car j'ai reçu un mail d'un lecteur, Tim, qui bosse dessus depuis des années et qui vient de la partager en open source. Alors je fais mon taf et je vous en parle !

Ça s'appelle Poznote , et c'est une application web légère pour la prise de notes. Le truc cool, c'est que vous gardez la main sur vos données puisque tout tourne chez vous. Pas de cloud tiers, pas de tracking, pas de "on analyse vos notes pour améliorer notre IA". Vos notes restent vos notes.

Côté fonctionnalités, y'a de quoi faire puisque c'est un éditeur de texte enrichi, avec support Markdown, une recherche super puissante, un système de tags, le support des pièces jointes, des espaces de travail multiples... Et y'a aussi des trucs plus originaux comme l'intégration d'Excalidraw pour dessiner des schémas et les diagrammes Mermaid pour les devs qui aiment visualiser leurs architectures. Et bien sûr, mode sombre parce qu'on est en 2025 quand même et que cette année était bien bre-som quand même !

Ce projet tourne avec PHP 8, SQLite pour la base de données, et un peu de JavaScript vanilla avec React juste pour le composant Excalidraw. Et les notes sont stockées en HTML/Markdown avec les métadonnées dans SQLite et les pièces jointes dans le système de fichiers.

Pour l'installation, c'est du Docker comme d'hab, donc vous récupérez l'image, vous configurez quelques variables d'environnement, et hop ça tourne sur le port 8040 avec les credentials par défaut admin/admin123! . Le projet supporte même les instances multiples si vous voulez séparer vos notes perso de vos notes pro sur le même serveur.

Y'a aussi une API REST complète avec documentation Swagger intégrée pour ceux qui veulent automatiser des trucs ou intégrer Poznote dans leur workflow. Vous pouvez aussi partager des notes publiquement si besoin, créer des listes de tâches, et y'a un système de corbeille pour récupérer ce que vous avez supprimé par erreur.

Le backup est également intégré directement dans l'app avec export complet de vos données et vous pouvez même consulter vos notes offline une fois exportées. Et tout le code est sous licence MIT.

Voilà, si vous voulez tester avant de vous lancer, y'a une démo dispo sur poznote-demo.up.railway.app avec les identifiants poznote/poznote. Ça vous donnera une idée de l'interface et des fonctionnalités sans rien installer.

Bref, si vous cherchez une solution de notes auto-hébergée incroyable, Poznote c'est gratuit, c'est open source, et ça respecte votre vie privée. C'est le top du top alors je dis un grand bravo à Tim pour le boulot accompli !!

• lien nᵒ 1 : Site de Prestashop
• lien nᵒ 2 : Prestashop build

Commentaires : voir le flux Atom ouvrir dans le navigateur

WordPress, c’est bien. Mais WordPress qui injecte des scripts d’emojis, des styles Gutenberg, des shortlinks et 47 autres trucs dont vous n’avez pas besoin dans chaque page de votre site… c’est moins bien évidemment. Heureusement, Terence Eden, un dev qui en avait marre de voir son code source ressembler à un plat de spaghetti, a compilé une petite liste de tout ce qu’on peut virer .

Car WordPress a adopté une philosophie de type “Decisions, not options” (des décisions, pas des options) où en gros, au lieu de vous laisser choisir, ils décident pour vous de ce qui est bon pour vous. Un peu comme Macron ^^. Le problème c’est que leurs décisions incluent un tas de fonctionnalités dont la plupart des gens n’ont rien à faire 🥲.

Par exemple les emojis. J’sais pas si vous savez, mais WordPress charge un script de détection d’emojis et une feuille de style dédiée sur CHAQUE page de votre site. Pourquoi tant de haine ? Hé bien parce que si vous tapez :-) dans un article, WordPress veut le transformer en joli emoji. Sauf que si vous utilisez les vrais emojis Unicode (comme tout le monde en 2025), hé ce script ne sert à rien. Et il y a aussi le grand remplacement des emojis dans les flux RSS…. Bref, tout ça, ça dégage.

Ensuite y’a le formatage automatique avec wptexturize qui transforme vos guillemets droits en guillemets typographiques “comme ça”. Et mon préféré, capital_P_dangit qui remplace automatiquement “Wordpress” par “WordPress” avec le P majuscule. Oui, vous ne le saviez pas, mais WordPress corrige l’orthographe de son propre nom dans vos articles. Mais quelle bande de nazes ^^.

Gutenberg, l’éditeur de blocs que j’adore, injecte lui aussi ses styles globaux même si vous utilisez l’éditeur classique. Et c’est pareil pour les styles de la librairie de blocs et l’éditeur de widgets basé sur les blocs. Si vous êtes resté sur le Classic Editor comme beaucoup de gens, tout ça ne sert alors qu’à alourdir vos pages.

Côté métadonnées, WordPress ajoute aussi pleiiiiin de trucs dans le code de vos pages comme les shortlinks, le RSD (Real Simple Discovery, un truc d’il y a 20 ans), des liens vers les flux de commentaires, les liens JSON de l’API REST…

Aux chiottes toutes ces conneries !

Le script de Terence fait aussi sauter l’ajout automatique des tailles d’images (wp_img_tag_add_auto_sizes), les templates de pièces jointes, et les block hooks qui modifient votre contenu. L’idée c’est donc de reprendre le contrôle sur ce que WordPress génère, au lieu de le laisser décider tout seul.

Et grâce à son script, le site de Terence (sans Philippe) obtient d’excellents scores sur PageSpeed Insights , ce qui prouve que tout ce bloat n’est vraiment pas nécessaire. Son script PHP complet fait environ 190 lignes et il est dispo sur son GitLab , bien commenté pour que vous puissiez choisir ce que vous voulez garder ou virer.

Attention quand même, certaines de ces désactivations peuvent casser des fonctionnalités si vous les utilisez vraiment. Par exemple, si vous avez des plugins qui dépendent de l’API REST, la virer complètement serait une mauvaise idée. Même chose pour les blocks Gutenberg si vous utilisez cet éditeur. L’astuce c’est donc de tester chaque modification une par une et de voir ce qui se passe.

Amusez-vous bien et un grand merci à Terence !

Face à une hausse du prix de la RAM, HP va augmenter le prix de ses PC en 2026 ou réduire les configurations mémoire. La pénurie mondiale s’aggrave.

Cet article HP alerte, la flambée du prix de la RAM va faire grimper le coût des PCs a été publié en premier par GinjFo.

ImunifyAV, le scanner AV qui protège 56 millions de sites Linux, vient de se faire pwn par le malware qu’il essayait de détecter. Et c’est pas la première fois…

En effet, Patchstack vient de révéler une faille RCE critique dans ImunifyAV, qui je le rappelle est un scanner antivirus gratuit ultra répandu dans l’hébergement mutualisé. Le problème en fait c’est que AI-bolit, le composant qui déobfusque le code PHP malveillant pour l’analyser, utilise la fonction call_user_func_array sans vérifier les noms de fonctions qu’elle exécute.

Boooh ! Du coup, vous uploadez un fichier PHP malveillant spécialement conçu pour l’occasion par un attaquant, ImunifyAV le scanne pour voir si c’est un malware, le déobfusque pour comprendre ce qu’il fait, et hop, le code malveillant s’exécute avec les privilèges du scanner.

Game over.

Hé pour qu’un antimalware détecte un virus, il doit analyser son code mais si les cybercriminels obfusquent leur malware pour cacher le code, l’antimalware doit alors le déobfusquer avant d’analyser. Mais déobfusquer du code PHP, ça veut dire aussi l’exécuter partiellement pour voir ce qu’il fait vraiment… d’où cette RCE.

La faille affecte donc toutes les versions avant la 32.7.4.0 et le correctif apporte juste une fonctionnalité de whitelist de fonctions autorisées pendant la déobfuscation. Il était temps, même si maintenir une whitelist de fonctions safe, à terme c’est un cauchemar car y’a des centaines de fonctions dans PHP. Certaines sont safe seules mais dangereuses combinées et je pense que les cybercriminels trouveront toujours un moyen de contourner cette whitelist.

En tout cas, comme je le laissais entendre en intro, c’est pas la première fois qu’AI-bolit se fait avoir sur la déobfuscation. En 2021, Talos avait déjà trouvé une faille sur unserialize dans le même composant. C’est la même blague car pour analyser du code malveillant sérialisé, il faut le désérialiser. Et désérialiser du contenu malveillant sans validation, ça fait “pwn” !

Voilà, 2 fois en 4 ans sur le même composant, c’est pas ce que j’appelle un accident. C’est un problème structurel car détecter du malware sans l’exécuter, c’est quasi impossible avec du code dynamique. Les signatures statiques ça marche bien pour les virus classiques mais face à du PHP obfusqué qui se reconstruit à l’exécution, vous êtes obligé de lancer le code pour voir ce qu’il fait vraiment. Et là, on est forcement en zone grise…

Même si on exécute du code potentiellement malveillant dans un environnement censé être isolé, si celui-ci “fuit” ou si le code malveillant trouve un moyen de sortir de la sandbox, vous avez une RCE. Et comme ImunifyAV tourne avec les privilèges nécessaires pour scanner tous les fichiers d’un serveur mutualisé, si vous compromettez cet antivirus, vous avez potentiellement accès à tous les sites hébergés sur la machine.

Si vous voulez tester, voici le proof of concept :

<?php
$data = "test";

$payload = "\x73\x79\x73\x74\x65\x6d"("\x74\x6f\x75\x63\x68\x20\x2f\x74\x6d\x70\x2f\x6c\x33\x33\x74\x2e\x74\x78\x74\x20\x26\x26\x20\x65\x63\x68\x6f\x20\x22\x44\x45\x46\x2d\x33\x36\x37\x38\x39\x22\x20\x3e\x20\x2f\x74\x6d\x70\x2f\x6c\x33\x33\x74\x2e\x74\x78\x74");
eval("\x70\x61\x63\x6b"($payload));
?>

php ai-bolit.php -y -j poc.php