animate.enter / animate.leave : virer @angular/animations - EasyAngularKit🔗

#Angular #Frontend

Tutoriel simple pour se débarrasser de @angular/animation dans 95% des cas et économiser 55-60kb dans votre bundle. Car aujourd'hui ce package peut être remplacé facilement par quelques lignes de CSS

IA🔗

Plus d'1 Français sur 3 utilise l'IA pour draguer sur les applications de rencontre🔗

#IA #Société

C'était certain que ça allait arriver : 1/3 des Français sur les services de rencontres utilisent de l'IA pour draguer, 1/3 y songeant…

Plus de 70% disent ne pas avoir avoué l'avoir utilisé à leur partenaire. Certains s'en servent pour avoir des idées de conversation, d'autres vont jusqu'à déléguer entièrement la discussion…

Comme j'ai dit : fallait s'y attendre, mais c'est pas vraiment dans une société comme ça que j'ai envie de vivre perso…

1930 : JM Keynes a prédit que nous ne travaillerions que 15h… | Hadrien Mens-Pellen🔗

#IA #Société #Emploi #Travail

Je cite le post d'Hadrien :

1930 : JM Keynes a prédit que nous ne travaillerions que 15h par semaine grâce à la mécanisation et l’automatisation 2018 : David Graeber soutiens la thèse que nous travaillons probablement déjà 15h par semaine, le reste de notre temps de travail serait comblé de tâches « à la con » quand ce n’est pas tout notre job qui est « à la con »

Quand on lit les témoignages dans Bullshit Jobs on comprend que notre modèle cherche à nous occuper plutôt qu’à nous libérer.

Ça m’a fait réfléchir à un angle de l’impact de l’IA dans nos vies. Si elle parvient à automatiser nombre de nos tâches, on ne travaillera pas moins, on aura juste plus de tâches « à la con ».

Je crois pas qu’on ait envie de ça pour notre futur. Si on veut garder l’IA malgré tout ses impacts négatifs, on prévoit quoi pour sortir des bullshit jobs et travailler moins pour gagner plus ?

Est-ce qu'il ne serait donc pas temps de lancer une transformation de nos sociétés ? Passer d'un monde où pour vivre il faut un emploi alors qu'on voit que le système craque, à un monde où on repartit les richesses pour que tout le monde vive correctement par défaut ?

Sécurité🔗

Un adulte se fait passer pour une enfant sur Xooloo, la messagerie destinée aux enfants🔗

#Sécurité #Enfants #Mineur #Réseaux-sociaux

Grégory Véret a admis que rien n’empêche techniquement un adulte de créer un compte en se décrivant comme un mineur. « La plateforme ne peut pas vérifier que la personne est un adulte », a-t-il précisé. Même limite pour les images à caractère sexuel. Leur détection et leur floutage ne sont pas automatiques, et une protection doit être activée sur l’appareil, une étape que Xooloo intègre au parcours destiné aux parents.

On pourrait trouver des solutions pour faire de la vérification d'âge (au hasard, on pourrait avoir une plateforme avec un certificat scolaire numérique, qui serait rempli par les écoles, et donc y'aurait une vérification humaine distribué). On pourrait activer par défaut tous les filtres qui floutent les contenus dénudés ou autres contenus adultes. On pourrait avoir une alerte automatique à chaque utilisation de certains mots ou combinaison de mot qui provoquerait une alerte à des modérateurs et/ou les parents.

On pourrait faire beaucoup de choses… Et ça paraîtrait légitime à tout le monde vu comment ça protégerait les enfants (seuls vrais utilisateurs de la plateforme…).

Mais le fondateur le dit lui-même qu'ils ne font pas ça, alors qu'il en va de la sécurité des enfants !

Cyberattaques : Sébastien Lecornu veut créer une "nouvelle unité cyber" d'urgence🔗

#Piratage #Sécurité #France

Alors que quasi tout le travail de cybersécurité c'est du long court, de l'anticipation, de la prévention, Lecornu veur monter une équipe de pompier qui sera interministériel…

Donc :

• on ne va toujours pas former pour de vrai les agents pour limiter les erreurs humaines ;
• on ne va pas imposer des mécanismes d'authentification fort comme du MFA avec clé physique ;
• on ne va pas faire du pentest continue des applications pour détecter au maximum en amont les failles ;
• on ne va pas renforcer la sécurité des systèmes ;
• mettre des mécanismes d'alerting pour détecter les attaques en cours ;

Mais :

• on va envoyer des gens après piratage constater les dégâts ;
• on va envoyer des renforts trop tard sans aucune connaissance du métier (donc en proposant sûrement des trucs incohérents et inapplicable sur le cas cible) ;
• on va cramer du pognon et des équipes pour faire des bilans d'attaque plutôt que renforcer la sécurité à long terme ;
• on va exiger des rapports à transmettre directement au premier ministre ;

Merci Lecornu, mais on a pas besoin de vous pour gérer la sécurité, on a besoin que vous fassiez confiance dans les experts du secteur, dans des internes avec des budgets au long cours, des plans de transformation cybersécurité pour boucher les trous et corriger les pratiques étape par étape, d'arrêter de faire semblant en prenant des cabinets de conseils 🤬

Divers🔗

Lancer tout son projet en local : une mauvaise habitude ?🔗

#CI #Métier-de-dev #Dev

J'aime beaucoup ce passage :

Le local c'est "ma vérité". La CI c'est "la vérité partagée". Quand vous vérifiez en local, vous vérifiez pour vous. Quand le test passe en CI, il vérifie pour toute l'équipe, sur un environnement propre, reproductible, identique pour tout le monde.

C'est pas une question d'outil. C'est une question de confiance. Aujourd'hui votre confiance repose sur votre machine, votre état, votre session. L'objectif c'est de déplacer cette confiance vers un filet qui appartient à toute l'équipe.

Vraiment complètement d'accord : votre CI est là pour casser souvent avant que ça casse votre prod parce que vous avez loupé un truc ; votre CI est là pour valider que le travail commun est ok ; faut-il faire les bons efforts pour que ce commun soit bon c'est tout.

Le mystère du nombre 6174 ! #shorts🔗

#Mathématiques

Bizarrerie mathématique : la constante de Kaprekar, qui vaut 6174.

Si vous prenez n'importe quel nombre à 4 chiffres (sauf un nombre avec que des chiffres identiques comme 2222), que vous triez d'un côté les chiffres du plus grand au plus petit, de l'autre du plus petit au plus grand, que vous faire la soustraction, puis recommencez avec le nouveau nombre, vous finirez par tomber sur 6174.

Pour les nombres à 3 chiffres c'est 495.

Et on retrouve ça pour d'autres nombre de chiffre. C'est inutile mais fascinant 🤩

GIMP va introduire un nouveau format et améliorer le support des PSD🔗

#GIMP #OpenSource

Changement assez fort côté GIMP : introduire un nouveau format de projet tout en conservant la capacité d'ouvrir les XCF (donc il faut s'attendre à ce qu'on soit incité à sauvegarder dans le nouveau format quand on ouvre les XCF).

Le but derrière c'est passer d'un format binaire à un projet à base de XML compressé pour gagner en perf à la sauvegarde (on peut enregistrer que ce qui bouge), avoir une sauvegarde automatique, et améliorer la capacité à faire de l'édition non destructrice (on applique des transformations qui s'empilent, sans jamais modifier avant d'exporter en image)

Fin de Microsoft Publisher après 35 ans de service - Liens en vrac de sebsauvage🔗

#Microsoft #Logiciel

Je dirais pas mieux que Sebsauvage :

Malgré son immense popularité, Microsoft va tuer le logiciel Publisher. (Oui si vous avez encore plein de travaux dans ce format fermé et propriétaire (.pub), vous pouvez pleurer. C'est tout l'intérêt des formats ouverts !)

La raison invoquée par Microsoft ? C'est pour « améliorer votre abonnement Microsoft 365 ». #troll

Hype Driven Development — L'EstamiTech🔗

#Podcast #Métier-de-dev

Je vous le dis directement : ça m'a fait du bien d'écouter le discours de Nicolas Delsaux (directeur technique de Zenika Lilles) qui va à contre courant de la sacro sainte hype !

Il parle de beaucoup de chose : des langages de programmation, d'IA, de cloud, d'archi, de design pattern, etc.

Et je trouve que sa vision est plutôt claire : rien n'est à jeter, il faut juste remettre à sa place chaque source de hype, il n'y a rien de magiquement universel, il faut utiliser le bon outil pour la bonne tâche, en tant que développeur c'est notre travail de choisir le bon outil, le bon pattern.

Bref : écoutez ce podcast !

Au passage (si tu passes par là) Ludovic (le créateur de l'Estamicast) : merci pour tes podcasts, j'avoue que je découvre, mais j'en ai écouté pas mal d'épisodes en août et c'est un plaisir à écouter !

Crédit photo : Générée via Mistral AI avec le prompt suivant :

Une scène chaleureuse et immersive, inspirée par l’esthétique poétique de Studio Ghibli, représentant un bureau de travail en bois clair et vieilli, baigné d’une lumière dorée et tamisée, comme un après-midi d’automne. Au centre, une silhouette stylisée (style anime Ghibli : traits doux, visage non détaillé, vêtements amples et confortables) est assise en tailleur sur un tapis épais, absorbée par la lecture d’un journal tech futuriste. Le journal est ouvert, ses pages légèrement froissées, avec des titres en en-tête calligraphiés à la main : "Frontend", "Backend", "IA", "Sécurité", et "Vie privée". Les pages brillent d’un halo bleu pâle, évoquant des lignes de code et des schémas techniques qui s’animent discrètement, comme par magie. Autour d’elle, des piles de magazines et de carnets s’empilent de manière désordonnée mais harmonieuse. Certains sont ouverts, révélant des extraits d’articles, des croquis de frameworks (représentés par des icônes génériques : un crochet pour le frontend, un engrenage pour le backend, un cerveau pour l’IA, un cadenas pour la sécurité, et un masque pour la vie privée), ou des diagrammes de réseaux de neurones dessinés à la main. Un écran transparent et flottant (style holographique, mais avec un cadre en bois sculpté) affiche des flux d’informations en temps réel : des graphiques de données, des alertes de sécurité, et des extraits de code, le tout dans un style doux et organique, comme intégré à la scène. En arrière-plan, une grande fenêtre donne sur un paysage urbain nocturne style Ghibli : des bâtiments aux formes arrondies, des lanternes suspendues, et des néons bleutés qui reflètent des motifs de code binaire sur les murs. Une tasse de thé fumant et un petit robot de bureau (inspiré des créatures de Ghibli, comme un mélange entre un Totoro miniature et un assistant tech) observent la scène avec curiosité. À droite, un panda roux (ton animal préféré) est lové sur un coussin, les yeux mi-clos, comme s’il écoutait attentivement. Il ne doit pas dépasser le tiers de la hauteur de l’image et est positionné en bas à droite, légèrement tourné vers le centre, avec une queue soyeuse enroulée autour de lui. L’ambiance est à la fois cosy, onirique et high-tech : les couleurs sont douces (beiges, bleus pâles, oranges chauds), avec des contrastes subtils pour mettre en valeur les éléments tech. Les détails sont soignés, avec des textures visibles (grain du bois, tissu du tapis, pelage du panda), et une lumière qui crée des jeux d’ombres chaleureuses. Le tout respire la sérénité et l’inspiration, comme un moment suspendu entre la magie et la technologie.

L'avant Tentacule🔗

J'ai cette problématique du multi-repo depuis un paquet d'année, et jusque-là j'avais opté pour un système très très basique : des alias bash.

Je maintenais donc à la main, un set d'alias du style

alias go-proj1=$(cd ~/path/to/proj1)
alias go-proj2=$(cd ~/path/to/proj2)
...
Bash

C'est pas passionnant à maintenir, c'est error-prone (comme c'est constamment des ajustements manuels, c'est facile de faire des typos), c'est un pavé qui prend pas mal de place dans mon .bashrc / .zshrc, il faut penser à l'ajouter à chaque nouveau clone… Mais on va pas se mentir : ça fonctionne très bien !

L'heure d'une vraie solution🔗

Ce que j'ai en tête c'est d'avoir un CLI qui va scanner tous les dépôts sur ma machine, et à la demande je veux pouvoir sauter directement dans le dossier d'un dépôt quand j'ai besoin sans avoir à réfléchir où je suis et/ou comment je m'y déplace.

Dans l'idée c'est facile, parcourir récursivement des dossiers, enregistrer certains chemins dans un fichier, puis pouvoir chercher dans le fichier. C'est super simple ! Finalement c'est une sorte de commande cd mais avec une autre manière de se déplacer.

Mais y'a un point compliqué : on ne peut pas créer un exécutable qui va changer le chemin courant de votre shell.

En effet, cd c'est une fonction dite "builtin" (votre shell peut vous le confirmer si vous faites type cd, vous devriez avoir cd is a shell builtin), c'est à dire que quand vous tapez cd truc, en fait votre shell (bash, zsh, etc.) va appeler directement une fonction interne au binaire qui gère votre shell, pas un programme externe. Donc vous ne pouvez pas remplacer juste cd via une autre commande. Donc il faut tricher.

J'ai envisagé deux options :

• la première c'est créer une fonction bash qui appellera notre CLI tentacule et donnera la réponse à cd pour se déplacer, c'est pas forcément le plus clair en tant qu'utilisateur, mais c'est simple et ça fonctionne comme système ;
• la seconde c'est de créer un shell, qui va intercepter certaines commandes et redonner à un autre shell le reste, je trouve ça encore moins simple à configurer, c'est super intrusif, ça peut introduire des bugs partout… mais ça doit fonctionner ;

Vous vous en doutez surement : j'ai pris la première option.

Donc pour configurer tentacule, il faut ajouter une ligne dans votre .bashrc / .zshrc :

function go { found="$(tentacule find ${@:1})";if [ $? -eq 0 ]; then cd $found;fi }
Bash

Si on l'écrit de manière formatée et avec des commentaires ça se comprend assez bien je trouve :

function go {
    # $@ = tableau avec tous les paramètres
    # ${@:1} = tableau avec tous les paramètres à partir de l'index 1
    #          (les tableaux en bash sont indéxé à partir de 0)
    # 
    # appeler tentacule find en lui passant les arguments qu'on 
    # avait passé à la fonction go, mais en retirant le premier
    # argument
    # 
    # donc "go one two" devient "one two" et est passé à la commande
    found="$(tentacule find ${@:1})"
    # $? = le code de retour de la commande précédente
    #      (ici c'est "tentacule find ...")
    #
    # si $? est égal à zéro, alors on cd dans le chemin contenu 
    # dans $found
    # sinon on ne fait rien (tentacule va afficher une erreur si le code
    # retour n'est pas 0)
    if [ $? -eq 0 ]; then
        cd $found
    fi
}
Bash

Plutôt simple non ?

Au cœur de la bestiole !🔗

Vous pouvez trouver tout le code ici, donc je ne vais pas vous montrer tout le code. J'ai juste envie de vous montrer quelques points que je trouve plutôt intéressant.

À noter que j'ai fait un choix très net dès le début : aucune dépendance. Pour ce projet, un peu par challenge personnel, je ne veux dépendre de rien, mais aussi par volonté de réduire l'effort de maintenance à long terme (aucune dépendance à mettre à jour, juste à recompiler si y'a des nouveautés intéressantes dans Rust et/ou sa toolchain).

En termes de fonctionnement global c'est assez simple :

• prendre les paramètres de la commande ;
• les donner à une brique qui va déduire la commande qu'on veut lancer et les paramètres associés ;
• prendre cette commande et déduire la fonction qu'on veut lancer ;
• lancer la fonction ;

C'est basico-basique mais ça fonctionne plutôt bien. Surtout avec le système d'enum de Rust qui permet nativement de faire des ADT (Algebraic Data Type) :

#[derive(Debug, PartialEq)]
pub enum Command {
    Help,
    Version,
    Index(IndexSubCommand),
    Find(FindSubCommand),
}

#[derive(Debug, PartialEq)]
pub enum IndexSubCommand {
    Help,
    Refresh,
    List,
}

#[derive(Debug, PartialEq)]
pub enum FindSubCommand {
    Help,
    Repo(Vec<String>),
}
Rust

Note : Vec<String> c'est équivalent en termes d'usage à un string[] (en TypeScript / JavaScript) ou List<String> (en Java).

Au premier niveau on a une Command, chaque option de Command a ou pas un paramètre qui est une sous-commande, chaque sous-commande est sur le même modèle. Sur chaque enum, on retrouve #[derive(Debug, PartialEq)] qui permet d'indiquer au compilateur qu'on veut que notre type dérive les traits Debug (permet d'avoir un affichage automatique pour du debug technique) et PartialEq (permet de comparer les valeurs avec un ==).

À partir de ça j'ai juste une fonction qui va inspecter le tableau des paramètres de la commande pour renvoyer la bonne commande.

Pour choisir le bon appel de fonction par rapport à la commande, j'ai quelque chose de très simple :

use crate::args::{Command, IndexSubCommand, FindSubCommand};

fn run_command(command: Command, root_dir: String) {
    match command {
        Command::Help => command::global_help::run(),
        Command::Version => command::version::run(),

        Command::Index(IndexSubCommand::Help) => command::index::help::run(),
        Command::Index(IndexSubCommand::Refresh) => command::index::refresh::run(root_dir).expect(""),
        Command::Index(IndexSubCommand::List) => command::index::list::run().expect(""),
        Command::Find(FindSubCommand::Help) => command::find::help::run(),
        Command::Find(FindSubCommand::Repo(words)) => command::find::repo::run(words).expect(""),
    }
}
Rust

Ici on commence à voir la force du combo ADT + pattern matching : cette fonction est très descriptive. match command va lancer du pattern-matching sur la commande, ensuite pour chaque valeur possible (en pouvant spécifier le pattern sur plusieurs niveaux, Command::Index(IndexSubCommand::Help) et Command::Index(IndexSubCommand::Refresh) sont deux patterns différents) je crée un pattern et je l'associe à un appel de fonction. Comme c'est un pattern-matching sur une enum, si j'oublie un cas, ça ne compilera pas, j'aurais une erreur et je devrais compléter pour continuer.

Avec Rust vous manipulez deux niveaux de langage : le langage Rust lui-même et le langage de macro de Rust.

Voici un exemple simple qui montre ça :

pub fn get_app_version() -> String {
    env!("CARGO_PKG_VERSION").to_string()
}
Rust

Cette fonction vise à renvoyer la version de l'application. Donc on déclare une fonction tout ce qu'il y a de plus simple : pas de paramètre, retourne une chaîne de caractère. Par contre vous noterez l'appel à env!(), et ce n'est pas une typo d'avoir un ! après le nom de la fonction, c'est qu'on est pas face à un appel de fonction Rust mais un appel de macro. En fait env!("CARGO_PKG_VERSION") sera exécuté / interprété par le compilateur puis remplacé par "0.1.0" (car dans mon cas, quand j'écris ces lignes, j'ai version = "0.1.0" dans mon Cargo.toml).

Donc après la passe d'exécution des macros, la même fonction devient :

pub fn get_app_version() -> String {
    "0.1.0".to_string()
}
Rust

C'est très puissant ce système de macro, car ça permet d'avoir pas mal de chose qui sont résolues pendant la compilation, pour permettre des choses plus efficaces à l'exécution. Je vous encourage à aller jeter un coup d'œil à mon logger que j'ai écrit avec des macros.

Pour finir je voudrais parler des tests : pas besoin d'un outil externe, tout est inclus dans la toolchain pour des tests courants. Pas non plus d'obligation de séparer les tests du code métier dans des fichiers séparés. Dans le même fichier que celui qui défini les enums Command, IndexSubCommand et FindSubCommand, j'ai à la fois la fonction get_command qui va parser les arguments et les tests associés dans un module dédié aux tests avec une annotation de configuration de test #[cfg(test)] permettant d'indiquer au compilateur de supprimer ce code pour la release.

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn test_unknown_command_return_global_help() {
        assert_eq!(
            get_command(vec![String::from("i_do_not_exist")]),
            ( Command::Help, Flags { log_level: LogLevel::Warn } )
        );
    }

    // ...
}
Rust

Sinon à moins de n'avoir jamais fait de test unitaire, c'est assez limpide comment fonctionne ce test, il faut simplement s'habituer à ce que tout soit en snake_case en Rust (j'avoue plutôt utilisé du camelCase au quotidien faisant surtout du TypeScript et Java).

Demo time !🔗

Passons au plus intéressant : ça donne quoi en pratique ?

On ne peut pas faire grand-chose avec tentacule, mais on peut faire l'essentiel :

• tentacule help va rappeler l'ensemble des commandes ;
• tentacule version va donner la version de tentacule ;
• tentacule index refresh va vous permettre de scanner les dépôts git ;
• tentacule index list va vous permettre d'afficher les dépôts précédemment scannés ;
• tentacule find <foo> va vous permettre de rechercher dans l'index une entrée qui matcherait le(s) mot(s) que vous passez ;

La force du truc à mon avis c'est qu'on va matcher le path complet, sans tenir compte de la case.

Par exemple, avec cet index :

/home/anthony/Projet/tentacule
/home/anthony/Projet/blog
/home/anthony/Projet/star-blog
/home/anthony/Projet/OctoDeps

On aura ce genre de réponse :

> tentacule find tentacule # ici on match exactement le nom du dossier et il n'y a pas d'autres options
/home/anthony/Projet/tentacule

> tentacule find ten # ici on match partiellement le nom du dossier mais c'est le seul match
/home/anthony/Projet/tentacule

> tentacule find blog # ici "blog" est présent dans deux chemins différents donc on a une erreur
thread 'main' (4885) panicked at /home/anthony/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/tentacule-0.1.0/src/main.rs:31:45:
: "Multiple matches: /home/anthony/Projet/blog, /home/anthony/Projet/star-blog"
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

> tentacule find /blog # par contre avec "/blog" on a plus qu'une occurrence, donc ça fonctionne
/home/anthony/Projet/blog

> tentacule find blog star # "blog" ça donne une erreur mais si on couple avec "star" on a bien un seul match
/home/anthony/Projet/star-blog

> tentacule find octo # ici on a un match car on ignore la case dans le path
/home/anthony/Projet/OctoDeps

> tentacule find Octo # ici on ne trouve rien, car on ignore pas la case sur les mots en entrée
thread 'main' (5009) panicked at /home/anthony/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/tentacule-0.1.0/src/main.rs:31:45:
: "No repo found"
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Bash

Ça vous donne une idée de l'état actuel du projet. C'est pas parfait, mais ça fonctionne !

Le futur de ce CLI🔗

Si vous me suivez, vous me connaissez, j'ai évidemment beaucoup d'idées pour la suite ! 😇

Déjà j'aimerais passer en 1.0.0 rapidement, il faut juste que je travaille quelques point avant :

• ajouter plus de tests : il y a quelques tests mais pas assez à mon goût, j'aimerais pouvoir être bloqué à la moindre régression ;
• avoir un pipeline sur Github Actions sur chaque PR et pour la release : côté PR ça permettrait d'être un peu plus structuré et de valider le code avant de basculer sur master, côté release ça permettrait d'avoir une automatisation de la publication avec tout ce qui va bien ;
• avoir des releases définies sur Github pour pouvoir y attacher les binaires de release prêt à l'usage ;
• retravailler les sorties d'erreurs : c'est simple côté code, mais côté utilisateur c'est moche et c'est pas propre ;
• je vais renommer la fonction go en t ou to : le compilateur du langage Go c'est go donc ça rentrerait en conflit sur les machines des développeurs Go, donc autant changer maintenant… ;

Évidemment pas mal d'autres idées qui viendront plus tard.

J'ai en tête d'introduire un fichier de configuration pour paramétrer de manière globale tentacule — à priori définir le dossier racine (en plus de variable d'environnement), spécifier une liste de dossiers/fichiers à ignorer pendant le scan, activer/désactiver le scan des dossiers cachés (actuellement ils sont ignorés, mais ça pourrait être utile de pouvoir l'activer), peut-être des alias de chemin (soit vers des dépôts soit vers complètement d'autres dossiers) — à voir dans le temps comment ça évolue aussi.

J'ai aussi pensé à minima deux autres commandes. La première c'est tentacule clone <repo> qui viendrait cloner un dépôt dans un dossier spécifique, en suivant une certaine hiérarchie du type <root>/<domaine du repo>/<groups et/ou organisations>/<nom du repo>, permettant d'avoir un point central organisé pour ranger tous les dépôts qu'on clone, sans avoir à naviguer dans les dossiers avant de cloner. Comme ce serait une commande tentacule qui viendrait cloner (en appelant git dans le $PATH de l'utilisateur), on pourrait en profiter pour l'ajouter au passage dans l'index, et du coup on pourrait juste faire tentacule clone <repo> puis go repo. La seconde commande c'est tentacule pull (peut-être tentacule fetch dans la même logique) pour appliquer un git pull sur tous les dépôts de l'index d'un coup. C'est un peu bourrin, mais personnellement ça me servirait régulièrement de pouvoir faire ça donc j'y réfléchis.

En l'état, tentacule ne gère pas les worktrees, peut-être que ce serait utile de pouvoir le faire, peut-être que c'est une option qui serait à gérer sur tentacule clone pour setup correctement un worktrees facilement exploitable.

J'aimerais bien explorer l'idée d'un tentacule find --color pour mettre en évidence le match qui est fait pour aider à la prise en main. C'est très optionnel je pense, mais je trouve ça intéressant à développer de mon côté.

Enfin, j'aimerais trouver une solution pour me greffer sur le git clone et faire un refresh automatique à chaque appel. Peut-être pas utile si je fais tentacule clone mais à voir.

Un mot sur Rust🔗

J'en profite pour faire un petit laïus sur Rust, car je trouve ce langage super intéressant et plus je pratique, plus j'en suis convaincu !

Déjà c'est super facile de se lancer je trouve. On a pas une phase de mise en place compliqué : il suffit d'installer rustup (qui est une sorte nvm ou sdkman) en 1 ligne de shell, puis lui demander d'installer une toolchain (= suite d'outil pour travailler avec Rust) via rustup toolchain install et c'est bon tout est configuré. Pour créer un nouveau projet c'est simple cargo new <nom du projet>, pour exécuter cargo run, pour lancer les tests cargo test, pour formatter le code cargo fmt, pour avoir du lint cargo clippy, pour compiler cargo build, pour publier un crate (= package partagé avec les sources + la version compilée) cargo publish. Aucun setup préalable pour cette suite d'outils, si y'a un truc qui demande une configuration (comme cargo publish) on aura des messages clairs, des liens, des références pour nous guider. Je trouve ça vraiment incroyable d'avoir quelque chose d'aussi propre !

Côté performance on est très bon, c'est très très proche de ce qu'on aurait en C mais sans les problèmes du C : c'est ancien, c'est très peu cadré, on peut vite faire n'importe quoi (particulière avec la mémoire vu qu'on manipule beaucoup de pointeur), c'est difficile à mettre en place quand on se lance. Et le top c'est qu'on est face à un langage plutôt haut niveau, on retrouve du pattern matching, on a des choses comme des if expression, la syntaxe est légère, on travaille avec des streams (via .iter()) partout sur la manipulation de tableau donc quand on arrive de Java ou TypeScript c'est super naturel.

Le langage est assez rigide, mais on est bien guidé : il y a beaucoup de warnings et erreurs quand on essaie de compiler (cargo run va commencer par compiler, donc même chose), chaque warning/erreur donne des pistes de corrections et la documentation pour comprendre pourquoi c'est un problème ce qu'on a écrit. Globalement on aura plus de mal à compiler qu'avec d'autres langages, mais on sait que ça fonctionne à la sortie. Parce que Rust va vérifier énormément de chose pour s'assurer qu'on ait le moins possible d'erreur de gestion de mémoire.

J'en suis à me dire qu'avec le mouvement "tout codé avec l'IA" (pas d'accord mais bon…) Rust devrait devenir une référence du fait que tout est très explicite donc ça doit être très facile de travailler avec l'IA.

Conclusion🔗

J'ai envie de dire : encore un side project pour moi. C'est petit, ça va s'améliorer avec le temps, mais c'est super intéressant !

J'ai mis quelques heures pour avoir ce résultat, j'aurais pu aller plus vite vu le code avec de l'IA mais mon idée c'était me remettre à Rust, je m'en fiche de prendre du temps, je veux apprendre et comprendre ce que je fais pour maintenir ça dans le temps, pas juste cracher une application jetable. Par contre oui j'ai pris des raccourcis par moments, à commencer par le parcours des dossiers : aller fouiller la doc pour retrouver tous les appels à faire ça prend du temps, demander à Mistral une première version ça m'a pris 1min et j'ai pris le temps de tout restructurer complètement autrement pour que ça colle plus à la structure que je voulais.

Je suis content de ce que j'ai fait, j'avais envie de le partager, c'est fait. J'en reparlerai sûrement ! Au plaisir d'avoir des retours si vous testez !

Sources :

• Code source du CLI
• CLI sur crates.io
• Site du langage Rust
• ADT (Algebraic Data Type)
• Trait (programmation)

Crédit photo : Générée via Mistral AI avec le prompt suivant :

A giant, gentle octopus sitting cross-legged on a floating wooden desk, surrounded by ancient magical books representing Git repositories. Each book has kraft paper labels with project names like 'tentacule', 'blog', 'OctoDeps', and 'star-blog' written in elegant calligraphy. The octopus uses its eight tentacles to manipulate the books, with one tentacle holding a wooden quill writing in a central grimoire (the Tentacule index), and another pointing to a holographic screen with a wooden frame displaying a list of repositories. The background features an infinite wooden library with curved, gravity-defying shelves and floating books. Maple leaves (8-10, in red, orange, and yellow) fall gently around the scene. Warm, golden afternoon light illuminates the scene, with sunbeams passing through stained glass windows shaped like Git logos or Rust symbols. Soft glowing particles float around the books, symbolizing Rust processes. The octopus has a slightly furry texture with subtle printed circuit patterns on its skin, and its eyes resemble green monochrome terminal screens. A red panda (firefox) is curled up on a cushion in the bottom right corner (≤ 1/3 of the height), slightly turned in 3/4 view, with a golden halo and surrounded by maple leaves. A small Ghibli-inspired robot tidies books in the background. The overall style is Studio Ghibli, with soft lines, warm colors (beige, pale blue, warm orange, moss green), and a cozy, dreamlike atmosphere.

Disclaimer : je ne vais pas dénigrer SFEIR, si vous êtes là pour ça, vous pouvez passer votre chemin, il n'y aura pas de sang ici… L'idée c'est de partager sur mon passage chez SFEIR, sur pourquoi j'avais signé et pourquoi je pars. Tout ce que je vais écrire ici c'est mon ressenti, mon vécu, c'est pas une critique de l'entreprise ni des gens qui la compose, c'est juste une expression de comment ça s'est passé pour moi.

Au commencement il y avait un tout petit bureau …🔗

L'histoire de SFEIR Nantes a commencé en juin 2018. Jean-François Garreau (le Directeur Technique, que je connaissais déjà via le GDG Nantes vu que j'étais pas mal présent en meetup à l'époque), Sabrina Rivier (la Directrice Commerciale) et Annabelle Koster (la Talent Advocate, que je connaissais déjà bien, car elle travaillait aussi chez SII et se faisait une vraie place sur les meetups) montent l'agence avec une vraie vision, une vraie envie de faire vivre la marque SFEIR à Nantes à travers l'expertise tech en s'entourant de personne qui pourraient aussi faire rayonner la marque et apporter de l'expertise en mission et au sein de l'agence.

À l'époque j'étais salarié de SII Atlantique, en mission chez OUI Sncf, dans une super équipe, avec des gens incroyables, j'apprenais tous les jours des trucs, on faisait des trucs super intéressant, les utilisateurs des produits qu'on développait était physiquement à quelques mètres de nous sur les bureaux autours. Puis pour divers raisons, mon équipe allait disparaitre, avec en parallèle pas grand-chose qui bougeait côté SII (comprendre que j'ai fait pas mal de propositions pour faire des choses, en grande partie en donnant de mon temps perso, mais que rien ne passait). Il était temps pour moi de partir.

J'ai tenté ma chance en postulant chez SFEIR. Au vu des échanges que j'avais eus avec des Sfeirien sur le stand du Devfest Nantes, avec la conviction que je n'avais aucune chance que ça passe mais en me disant que ça me donnerait un palier à atteindre pour re-postuler plus tard. Premier entretien en algo avec Jean-François, dans ma tête je me dis que c'est déjà fini, j'ai aucune chance face à Jef de donner quelque chose… Quelques jours plus tard Annabelle me dit que je dois aller sur Paris pour faire les deux autres tests techniques (à l'époque, le seul dev à Nantes c'était Jef, or dans le framework de recrutement de SFEIR, on doit être évalué par trois pairs), qui ont été autant d'appréhension que l'algo pour finalement une réussite. Quand j'ai appris que j'allais avoir une proposition, j'ai signé sans trop réfléchir plus loin : dès les tests j'avais un challenge (alors que SII ne m'en proposait aucun), dès les échanges avec les évaluateurs je sentais un mindset commun, une certaine volonté de challenger avec bienveillance, de construire ensemble, pile ce que je cherchais.

Pour tout dire, il y a pas mal de choses que j'aimais chez SFEIR. Déjà le fait que la direction à tous les niveaux se faisait à deux têtes : le directeur technique et directeur commercial partage le pouvoir et doivent tout décider ensemble ; pour moi c'est la garantie que la tech (un bon 90% de l'effectif d'une ESN comme SFEIR) sera écouté, aura un impact. Le fait que l'agence de Nantes soit petite (3 personnes quand j'ai passé mes tests, 5 quand j'ai effectivement commencé), donc tout à construire, avec moyen de mettre de moi dans la trajectoire de l'agence. Une volonté de créer une communauté de passionné de tech à Nantes avec lesquels échanger au besoin, mais aussi s'intégrer au groupe avec pas mal d'échange entre agence. Beaucoup d'option pour faire des choses : conférences, meetup, organiser des événements, partager sur des sujets tech, etc.

… et puis 7 années sont passés …🔗

7 ans plus tard (7 ans le 4 mars 2026, donc même un peu plus que ça), j'étais encore là.

J'ai pu faire beaucoup de chose chez SFEIR. J'ai été formateur (Angular, RxJS, React, TypeScript, Cypress, Playwright et Quarkus). J'ai écrit des formations. J'ai été speaker. J'ai fait passer des tests techniques aux candidats. J'ai été organisateur d'un meetup interne pendant un peu plus de 2 ans seul (avant de passer la main sur l'orga mais en donnant des coups de mains au besoin). J'ai été organisateur d'événements pas du tout tech aussi (repas de Noël et soirée chandeleur). J'ai aussi fait de l'accompagnement et du coaching autour de pleins de sujet dont les certifications Angular et React. J'ai aussi pris une casquette dans le staff avec le rôle de Staff Engineer, donné mon avis sur la trajectoire de la boite. Mais aussi un rôle d'élu au CSE. Beaucoup de moment à rire aussi, des personnes que j'apprécie sincèrement et avec qui j'ai adoré travailler (de loin parce que pas sur les mêmes projets mais aussi directement dans la même équipe pour certains). Et plein d'autres choses.

J'ai donné beaucoup d'énergie perso pour SFEIR. Parce que j'ai estimé que ça valait le coup. Parce que j'avais envie de le faire. Parce que j'avais un manager qui me comprenait et savait me montrer des portes que je pouvais ouvrir quand des opportunités apparaissaient et qu'il pensait que j'étais la bonne personne pour ça. Parce que clairement, 7 ans chez SFEIR c'est aussi parce que j'ai toujours eu un bon manager. Au début c'était Jean-François, puis Damien, puis à nouveau Jean-François. Je ne serais pas resté aussi longtemps sans ça, c'est certain !

Mais en 7 ans on change. En tout cas, en 7 ans j'ai changé. J'ai commencé chez SFEIR avec très peu confiance en moi et ma capacité à réaliser des choses compliquées, j'en pars avec beaucoup plus de confiance, je sais que je peux faire plein de choses, je me projette sur des rôles très différents, et même si j'ai toujours beaucoup de doute sur mes compétences, sur qui je suis, etc. j'ai appris à tenter plus, à me faire confiance, à prendre des risques. Et aussi des changements dans ma vie personnelle, un déménagement à côté de Cholet (environ 1h de train/voiture de Nantes), une vie de famille qui impose quelques changements de rythmes de vie.

En 7 ans l'agence a changé aussi. Quand j'ai démarré en 2019, SFEIR Nantes c'était un tout petit bureau un peu sombre dans un espace de coworking avec 5-6 personnes, et 8 places assises, aujourd'hui SFEIR c'est avec un bureau de presque 200m², un petit open space, une salle de formation, une soixantaine de personnes à l'agence.

En 7 ans SFEIR a changé. Un directeur qui part, une réorganisation, une volonté de faire grossir la boite autrement, la fin de la direction à deux têtes à tous les niveaux, une perte de sens de pas mal de décisions…

Après 7 ans, je ne me sentais plus vraiment aligné avec l'entreprise et sa trajectoire, je ne me voyais plus évoluer non plus chez SFEIR, j'étais fatigué de voir des certains sujets qui ne bougeait pas, fatigué de lever des alertes qui n'était pas écouté côté direction à Paris, fatigué de m'investir dans une double vie pro (une vie pro chez SFEIR et une vie pro chez mon client), me sentir de moins en moins constructif (même si on ne me l'a jamais dit, je le voyais que j'aurais pas réagi comme ça 1 ou 2 ans plus tôt ; sincèrement désolé si j'ai pu blesser certains sans m'en rendre compte).

… il était temps pour moi de prendre un autre chemin …🔗

Même si quitter l'équipe SFEIR Nantes, qui était un peu ma seconde famille après tout ce temps, était difficile, il fallait que je réagisse.

J'étais tout doucement en train de me perdre moi. Je commençais à montrer des signes de burn out. Après 10 ans en ESN, je n'en pouvais plus de ce système. Et je me sentais de moins en moins à ma place à l'agence (le fait de ne plus vivre à Nantes et donc moins être présent à l'agence y a joué c'est certain, mais mon envie de partir à commencer à germer avant même de quitter Nantes).

J'ai beaucoup de projet en tête, beaucoup de chose que j'aimerais réaliser / créer mais le panel d'activité de SFEIR m'empêchait de le faire car j'aurais été en conflit contractuel. Je n'en parlerais pas ici pour l'instant, ça viendra (ou pas) le moment venu, pour l'instant ça reste dans un coin de ma tête.

Une nouvelle mission… Ou pas !🔗

En parallèle de tout un cheminement qui m'a pris bien entre 1 et 2 ans, j'ai rejoint France Travail en tant que prestataire. En travaillant pour une entreprise avec une mission service public, j'ai pu mettre mes compétences au service d'un morceau de bien commun, au service de l'emploi des autres (je sais que tout ce système a ses limites, mais ce n'est pas en le critiquant qu'on change les choses, c'est en agissant à mon sens).

En tout cas, même si tout n'est pas parfait chez France Travail, je m'y sens bien. Mon équipe est extra, mon projet intéressant.

Et puis j'ai eu l'opportunité de passer interne, j'ai eu l'opportunité d'évoluer au passage (passer de Lead Dev à Tech Lead), j'ai eu l'option de signer pour rester dans un cadre qui me convenait bien, pour réaliser une roadmap que j'étais en train de commencer à construire pour les 2 prochaines années.

J'ai commencé il y a peu chez France Travail en interne. Je ne sais pas comment ça se passera dans le temps, mais je me projette dans le modèle de fonctionnement qui finalement ressemble un peu à une ESN sur pas mal d'aspects et je pense que certaines grosses DSI par lesquelles je suis passée devraient s'inspirer du modèle de fonctionnement de France Travail.

Note : pourquoi je dis que le fonctionnement ressemble à une ESN ? Chez France Travail on a deux managers : un Responsable Opérationnel (RO) et une Responsable Pour la Carrière (RPC). Le RO nous définit notre rôle au quotidien dans l'équipe, nos responsabilités, notre mission. Notre RPC va lui suivre notre carrière, notre évolution personnelle, notre projection à long terme, notre employabilité, nous suivre de projet en projet (en interne on dit de missionement en missionement), en se basant sur un mélange entre nos envies et les besoins de l'entreprise. Finalement comme en ESN on a un manager côté ESN qui va nous aider à rester en correspondance du besoin du marché et nous accompagner en termes d'évolution salariale et professionnel, et un manager côté client qui va faire le suivi au quotidien dans le projet.

Conclusion🔗

Alors que pendant mes études je me disais que je ne voulais surtout pas travailler en ESN (à l'époque on disait encore SSII (Société de Service en Ingénierie Informatique)), j'aurais travaillé 10 ans en tant que prestataire. J'aurais travaillé chez 7 clients différents, j'aurais travaillé sur plus d'une quinzaine de projets/produits en build (construit depuis rien et emmené en production) et run (sur des projets déjà existant, à devoir les maintenir, faire les correctifs et les faire évoluer techniquement et fonctionnellement). En ESN et particulièrement chez SFEIR, j'aurais pu grandir, pas après pas.

Sans ordre particulier, et plus toujours chez SFEIR au moment où j'écris ça, merci à Jef, Annabelle, Damien, Adrien, Gildas, Morgane, Emmanuel, Yoann, Frédéric, Valentin, Claude, Justine, Julien, Julien (pas une erreur, pas faute d'avoir dit à Justine que recruter des homonymes c'est pas pratique 🤪), Mathob, Benjamin, Benoit, Benoit (encore une sombre histoire d'homonymes…), Hoani, William, Alexis, Arthur, Jean-Alain, Florian, Florian (bon c'est fini les homonymes ?), Denis, Guillaume, Guillaume (toujours pas on dirait…), Stéphane, Jonathan, Jonathan (c'est quoi ce boulot Justine ? 😵), Thomas, Nebras, et tant d'autres à Nantes ou même globalement chez SFEIR. Si vous passez par là, vraiment dites-vous que sans vous je ne serais pas là, et que je suis très heureux d'avoir pu apprendre tant de chacun de vous ! J'espère avoir pu vous apporter deux trois trucs moi aussi !

En bref : je suis content d'avoir fait ces 7 ans chez SFEIR, mais je suis aussi content de partir au final, je pars pour une nouvelle aventure en mettant un point sur l'histoire SFEIR qui commençait à devenir un peu trop lourde.

Merci aussi à Lise, Marietta, Thibaud, Guillaume et Nicolas de m'avoir fait confiance en m'accompagnant sur passage en interne chez France Travail !

Crédit photo : Générée via Mistral AI avec le prompt suivant :

Two floating islands in a golden sky, connected by a sculpted wooden bridge crossing the image from left to right. The left island (symbolizing SFEIR) is autumnal, with trees featuring red, orange, and yellow leaves, discrete holographic screens (wooden frames) displaying lines of code, and anthropomorphic animals (axolotls, pandas, cats, and squirrels) waving goodbye. The right island (symbolizing France Travail) is spring-like, with blooming trees and vibrant flowers, futuristic buildings blended into nature, and anthropomorphic animals (phoenix, firefox, red pandas, and birds) eagerly waiting. A red panda (anthropomorphic, male, 33 years old, round face, full cheeks, marked chin, curly hair tied in a low bun, short dense beard, dark brown slightly squinted eyes, black rectangular thin glasses, subtle silver chain necklace, robust build, broad shoulders, wearing a t-shirt and jeans) is crossing the bridge from left to right, carrying a backpack filled with notebooks and technical books. Maple leaves (8-10, red/orange/yellow) float around him, and a soft golden halo surrounds him. The scene is inspired by Studio Ghibli, with warm, poetic, and dreamy colors (beiges, soft oranges, warm browns for the left island, and soft greens, pale pinks for the right island), and a blend of organic and high-tech elements. The bridge is decorated with carved patterns and lanterns.

docs: add v23 release and change to yearly release cycle by thesmiler · Pull Request #69817 · angular/angular · GitHub🔗

#Angular #Frontend

La version 22 d'Angular est sortie début juin 2026, la version 23 sortira en juin 2027. À partir de maintenant il y aura 1 seule version majeure d'Angular chaque année, suivi de 4 à 6 versions mineures.

Allonger le cycle de release va permettre à l'équipe Angular d'avoir plus de temps pour développer certaines fonctionnalités tout en permettant aux utilisateurs d'Angular de moins subir les breaking changes aussi souvent (quand bien même c'était pas vraiment un sujet à mon sens, vu que le CLI encaisse presque tous les breaking-changes tout en ayant un framework rétro compatible très fortement donc on était même pas obligé de basculer).

Je pense que l'effet secondaire qu'on risque d'observer c'est que certains projets vont mettre encore plus de temps à faire les migrations majeures par contre…

GitHub - tokio-rs/topcoat: A batteries-included framework for building web apps · GitHub🔗

#Rust #Web #Frontend #Backend

Des frameworks web fullstack y'en à la pelle. Là je retrouve plein de bonnes idées à mon sens :

• c'est basé sur Tokio (LA lib rust la plus puissante pour gérer de l'asynchrone en Rust, pile le truc le plus utile pour faire un moteur de serveur web) ;
• y'a du templating pseudo-JSX mais compilé strictement par le compilateur Rust ;
• y'a un système de Signal ;
• SSR par défaut sauf si on utilise des éléments de réactivité ;
• compilation en JavaScript au besoin des bribes de templates ;
• basé sur des annotations (#[component], #[page("/")], #[tokio::main] par exemples) ;
• bundling automatique des assets ;

On sent des inspirations prises à droite et à gauche pour construire Topcoat ! Par contre c'est encore indiqué comme :

Early-stage and experimental. Expect breaking changes.

Donc il faut suivre. On peut jouer avec, mais attention si vous voulez aller en production !

The Website Specification🔗

#Web #Frontend

A platform-agnostic specification of all the technical details that matter for a website, from <title> to /.well-known/security.txt to WCAG contrast. Written for humans and agents.

Et vraiment je pense qu'on est pas loin de retrouver tout ce qui est important 😯

IA🔗

GitHub - kyutai-labs/pocket-tts: A TTS that fits in your CPU (and pocket) · GitHub🔗

#IA #Text-To-Speech

Si je suis souvent critique envers l'IA c'est principalement pour deux choses : le bullshit qui l'entoure et l'absurde taille des modèles (particulièrement vrai avec les LLMs). Là c'est l'opposé : un modèle tout petit, qui ne dépend pas du tout d'une carte graphique (ça tourne avec PyTorch CPU) et qui fait du TTS (Text To Speech) facilement et rapidement.

Je suis pas anti-IA, je suis pour de l'IA raisonnée, réfléchit, et pensé pour être utilisé par le plus grand nombre.

Mon rapport si ambigu à Claude – Chez Bodul🔗

#IA #Métier-de-dev

Ludovic nous donne son ressenti de comment il utilise mais aussi comment il ressent l'IA aujourd'hui. Le changement du métier de dev. La manière dont les devs qu'il qualifie de plutôt "artisan" (partisan de faire à la main, proprement et durablement quitte à y passer un peu plus de temps) se sentent de moins en moins en phase avec le métier.

Article qui n'apporte aucune solution (ce n'est pas le but, ici Ludovic donne son ressenti rien et c'est très bien), mais c'est intéressant à lire. Personnellement je vois de plus en plus de retour du style, que ce soit en ligne ou dans les gens que je croise. Et de mon côté je n'oublie pas non plus qu'il existe encore des devs qui n'utilisent pas du tout l'IA au quotidien car pas les outils à dispo au boulot et qui sont donc complètement en dehors de tout ça

Vibe Coder vs Software Engineer | Yusuf Aytas🔗

#IA #Métier-de-dev

Je cite 3 extraits :

Use vibe coding where the cost of being wrong is low, and use engineering discipline where the cost of being wrong belongs to customers, teams, or the business.

Engineering requires some level of apprenticeship. Vibe coding tempts you into working alone. People work and learn in teams. Software engineers improve their craft by working with others. The job is not just code. The job is judgment, not output. A software engineer has judgment about what's risky and what's not. That judgment is built through contact with the system and people.

A software engineer is needed when the main cost is ownership. They control what enters the system, how it is reviewed, how it is secured, how it is tested, how it is operated, and how it will be changed later. The distinction is operational. It is also not a fixed identity. The same person should vibe code in discovery and switch into engineering for delivery. The skill is knowing which mode you are in, and not letting the habits of one leak into the other. Vibe coding can help you learn faster. Software engineering helps you avoid paying for that learning forever.

Vraiment un article important à lire. Il correspond à mon sens assez bien à ma vision : l'IA pour le code c'est un outil de plus pour nous aider à produire le code ; le code c'est presque la brique la moins importante du métier, ce qui compte c'est le produit et l'appropriation du code qui constitue le produit ; si vous générez le code en fermant les yeux, sans aucune validation, sans aucune bonne pratique (y'a rien de nouveau derrière ça, les bonnes pratiques de dev existent depuis plusieurs décennies pour certaines, et y'a des noms plus récents qui ont écrit des bouquins entiers dessus : Robert Cecil Martin, Martin Fowler, etc.) ce que vous produisez c'est juste une soupe impossible à maintenir, impossible à déployer avec confiance, c'est juste un machin semble être un produit mais n'en est pas un.

Sécurité🔗

Wichtige Information - ZEGO Textilveredelungszentrum🔗

#Sécurité

Pour faire court : une boîte de textile allemande se place en insolvabilité pour tenter de redresser la barre à la suite d'une cyberattaque qui a mis à l'arrêt toute la boîte pendant 3 semaines en mars/avril… La cybersécurité ça coûte toujours trop cher, jusqu'à ce que ça plombe la boîte, peut-être pour la dernière fois…

C'est un exemple parmi tant d'autres de boîte qui n'a rien de tech mais qui s'est pris une claque à cause d'un trou sans sécurité. Je pense que c'est important d'en parler !

Je pose là une traduction Google Translate pour ceux qui comme moi parle couramment l'allemand :

Déclaration d'insolvabilité – Et pourquoi nous continuons à aller de l'avant

Mesdames, Messieurs, Chers partenaires commerciaux,

Nous nous adressons à vous aujourd'hui pour vous communiquer une nouvelle qu'il nous est personnellement très difficile d'annoncer.

La société ZEGO Textilveredelungszentrum GmbH a déposé une déclaration d'insolvabilité.

Cette décision a constitué l'une des étapes les plus difficiles des 37 années d'existence de notre entreprise. Elle n'a pas été prise à la légère ; elle intervient après que nous avons examiné et épuisé toutes les options à notre disposition.

Ces derniers mois, nous nous sommes battus de toutes nos forces pour notre entreprise, nos employés, nos clients et nos fournisseurs. Notre objectif a toujours été de maintenir l'activité et de ramener ZEGO sur une trajectoire stable.

Cependant, la cyberattaque du 29 mars 2026 a frappé notre entreprise avec une telle violence que, malgré tous nos efforts, nous n'avons pas réussi à nous en relever complètement. Ses conséquences ont notamment entraîné un arrêt de la production de près de six semaines et de lourdes difficultés financières. En fin de compte, ces répercussions ont compromis notre situation financière au point de rendre nécessaire le dépôt de bilan.

Cette démarche est pour nous extrêmement douloureuse.

Depuis de nombreuses années, ZEGO est synonyme de fiabilité, de qualité et de partenariats constructifs. Bon nombre de nos clients et fournisseurs nous accompagnent depuis longtemps. Nos relations commerciales ont souvent évolué vers des partenariats fondés sur la confiance — voire vers de véritables amitiés — pour lesquels nous vous sommes infiniment reconnaissants.

C'est précisément pour cette raison qu'il nous tient à cœur de partager ce qui suit avec vous aujourd'hui :

L'insolvabilité ne signifie pas nécessairement la fin d'une entreprise.

Au contraire, cette procédure offre l'opportunité de restructurer et de repositionner l'entreprise, ainsi que de stabiliser sa situation économique. Nous sommes pleinement déterminés à atteindre cet objectif.

Nous continuons à nous battre pour la survie de ZEGO Textilveredelungszentrum GmbH.

Notre but est de collaborer avec toutes les parties prenantes pour élaborer des solutions viables, préserver les emplois, maintenir nos relations avec les clients et assurer l'avenir de notre entreprise. À cet égard, nous continuons de compter sur le soutien et la confiance de nos partenaires commerciaux.

Nous vous demandons donc instamment de rester à nos côtés durant cette période difficile. Chaque forme de soutien, chaque effort de collaboration et chaque marque de confiance contribuent à jeter les bases de la pérennité de l'entreprise. Nous tenons à vous remercier chaleureusement pour votre soutien, votre fidélité et la confiance que vous nous avez témoignée jusqu'à présent.

Nous vous tiendrons informés en toute transparence de l'évolution de la situation et restons à votre entière disposition pour toute question.

Œuvrons ensemble pour que cette période difficile ne marque pas la fin, mais un nouveau départ pour ZEGO.

Cordialement,

Johannes Zenglein ZEGO Textilveredelungszentrum GmbH

Comprendre l’authentification avec Github (OAuth) - Code-Garage🔗

#Github #OAuth2 #Sécurité

Je cite directement le résumé final qui indique bien ce que vous explique l'article et le mode de fonctionnement d'une authentification avec Github :

1. Votre application redirige l'utilisateur vers GitHub.
2. GitHub vérifie son identité et renvoie un code temporaire.
3. Votre serveur échange ce code contre un token, récupère l'adresse email de l'utilisateur, puis génère son propre JWT.
4. Au final, GitHub ne fait qu'une seule chose : confirmer l'identité de l'utilisateur.

Pour le reste je vous invite à lire l'article, c'est simple, c'est bien expliqué, ça peut s'adapter à pas mal de cas d'authentification via une source externe.

7 ministres français espionnés par le Maroc : voici ce que révèle la nouvelle enquête Pegasus🔗

#Sécurité #Vie-privée

Résumé : on sait que 7 ministres ou anciens ministres ont été espionnés par le Maroc entre 2019 et 2020 via l'utilisation de Pegasus (outils d'espionage numérique par intrusion / exploitation de faille zero-days non divulgués vendu par la société NSO). À priori ce serait via des failles zero-clic, donc sans aucune action de l'utilisateur. On a aucune idée de ce que le Maroc a obtenu comme information et si les prises de position aligné sur le Maroc de la France depuis sont liés.

On ne sait pas par contre si d'autres ministres ont été espionnés par Pegasus, ni si le Président a été espionné, ou même qui que ce soit d'autres. Ne pas avoir trouvé de trace, ne signifie pas qu'il n'y a pas eu d'espionnage, ça peut-être aussi une attaque légèrement différente ou via une faille qui ne laisse pas de trace ou des traces plus discrètes.

Avec ce genre d'outils : on ne sait rien, ça compromet la sécurité et la vie privée de n'importe qui…

uBlock Origin n'est pas un adblocker — MiddleEarth🔗

#Sécurité #Vie-privée #Malware #Navigateur

Les pubs diffusent des malwares (et des arnaques), de plus en plus, et du coup bloquer les pubs devient une mesure de sécurité en plus de la protection de la vie privée (les bandeaux pub traquent les utilisateurs de site en site) et de l'économie de bande passante qui est obtenue au passage…

Avec uBlock Origin vous aurez un blocage propre et efficace de nombreux trucs !

AdBlock Plus deal avec les boîtes de pubs pour qu'une partie des pubs restent en ligne quand bien même vous avez AdBlock Plus depuis de nombreuses années. Chrome / Chromium et ses dérivés ne permettent plus que les Web Extension Manifest v3 ce qui dans le moteur de Chrome implique de facto que vous ne pouvez plus avoir un blocage de pub pertinent (je passe les détails techniques largement diffusés en ligne).

Note : si vous vous demandez pourquoi Chrome et ses dérivés n'aiment pas les bloqueurs de pub, rappelez-vous que c'est développé par Google et qu'une grosse part de leurs revenues vient des pubs.

Bref : installez uBlock Origin, sur Firefox, vous aurez un vrai navigateur et un vrai bloqueur de publicité.

Ce qu'il faut savoir sur le retrait de OnePlus en Europe (mises à jour, suivi, support client)🔗

#Smartphone #Tech #Android #Oneplus #Oppo #Sécurité

Si comme moi vous avez un Oneplus (j'utilise un Oneplus 11 depuis sa sortie début 2023, ce dernier avait remplacé un Oneplus 6 que j'avais aussi depuis sa sortie), vous allez voir des changements prochainement : la marque Oneplus sort définitivement de tous les marchés excepté la Chine…

Conséquence annoncée :

• On perd le service client Oneplus au profit de celui d'Oppo (la maison mère de Oneplus depuis pas mal d'année déjà, on sait qu'Oppo est investisseur de Oneplus depuis 2014) ;
• Prochainement on devra dire adieu à OxygenOS en faveur de ColorOS (soyez patient pour migrer à mon avis…), ou on perdra les mises à jour majeures d'Android et sûrement aussi les patchs de sécurité ;
• Plus de nouveau smartphone Oneplus à venir chez nous ;

De mon côté je vais rester sur mon Oneplus 11 tant qu'il fonctionnera (à priori) et on verra vers quoi j'irai dans le futur. Avec l'explosion du prix des composants, c'est de toutes façons le pire moment pour changer de matériel 😅

Si vous cherchez un smartphone en ce moment, je vous conseillerais à priori de regarder du côté de Nothing, entreprise fondée par Carl Pei (comme Oneplus) avec une philosophie proche initialement. C'est sûrement chez eux que j'irais si je devais changer dans les prochains mois de mon côté en tout cas

Jeux-videos🔗

The Spine Archive | Custom Nintendo Switch Spines Tool🔗

#Nintendo #Jeux-videos

De base la tranche est rouge uniforme avec juste le nom du jeu en blanc, ce qui n'est pas très beau, pas toujours facile à lire et rend moins visuelle la recherche d'un jeu. Ce site rassemble donc des tranches de jaquette alternatives pour les jeux Nintendo Switch 1 et 2, faites par des indépendants, qu'on peut imprimer gratuitement pour glisser devant la tranche de la jaquette de nos jeux pour rendre plus sympa la tranche de nos jeux.

Je trouve l'idée super cool, mais peu probable que je fasse tous mes jeux switch comme j'en ai plus de 200 😅

Little Writer Desktop Companion on Steam🔗

#Jeux-videos

Your little companion is an ambitious writer with very little discipline. Type, and they'll write too. Every keystroke moves their work forward. In this idle productivity game, help them become a renowned author while you get things done.

C'est plutôt marrant, l'idée c'est d'avoir une petite fenêtre flottante qui montre un petit personnage en train de taper du texte quand vous tapez du texte. Plus vous tapez au clavier (hors du jeu, sur l'activité que vous voulez), plus vous faites progresser votre petit écrivain. J'aime bien l'idée, parce que ça vous donne implicitement des objectifs à vous remplir (taper un certain nombre de mots, taper à une certaine vitesse, etc.), tout étant peu intrusif à l'écran.

Par contre autant c'est gratuit et offline (sur le papier), autant ça veut dire que Little Writer Desktop Companion va intercepter tous vos appuis claviers, donc il a le potentiel d'être un keylogger, donc je suis partagé…

Divers🔗

ReactOS "Open-Source Windows" Project Now Capable Of Running Half-Life 2 - Phoronix🔗

#Open-Source #ReactOS #OS #Open-source #Windows

Encore une étape de franchi pour ReactOS (ré-implémentation de l'api de Windows mais sans le moindre lien avec Microsoft et 100% en open source) qui fait maintenant tourner sans souci Half-Life 2. Ça parait anecdotique mais ça ne l'est pas, il faut un max de truc pour que ça marche les jeux-vidéos !

Dans le billet on voit aussi la première implémentation d'un appel système NT6 (équivalent de Windows Vista) donc ça ouvre une nouvelle porte !

Claviers ASUS ROG et Linux : fuyez ! (ou bricolez dur) – Le blog de Seboss666🔗

#Clavier #Linux #USB

Seboss666 a eu quelques galères avec son clavier ASUS qui envoie des inputs qui mettent les ordis Linux en vrac. Ça sent le non-respect du standard USB cette histoire mais bon…

En tout cas, note pour plus tard : ne jamais acheter de clavier ASUS et rester chez Logitech (MX Keys à date) quand bien même j'aime beaucoup les machines / cartes-mères de marques 😅

The Temper programming language - Temper Programming Language🔗

#Language #OpenSource #Open-Source #Open-source #TypeScript #JavaScript #Java #C# #Rust #Lua

Je cite la première phrase de la doc :

The Temper programming language cross-translates to other programming languages.

Et le premier extrait de code :

export let half(x: Int): Int {
  x / 2
}

La version transpilée en Java :

package com.example.numerics;
public final class NumericsGlobal {
    private NumericsGlobal() {
    }
    public static int half(int x__1) {
        return x__1 / 2;
    }
}
Java

Ou en TypeScript :

const {
  trunc: trunc__1
} = globalThis.Math;
/**
 * @param {number} x_0
 * @returns {number}
 */
export function half(x_0) {
  return trunc__1(x_0 / 2);
};
TypeScript

Ou en Python :

def half(x__1: 'int') -> 'int':
  return x__1 // 2
Python

Y'a aussi C#, Rust et Lua.

Je cite un autre passage parlant :

Most engineering organizations use multiple languages: Python for data science, others for mobile apps, JavaScript on the web, and a different language on the server.

Temper helps break down silos by letting a small team maintain core type definitions and logic to all the other silos.

En résumé, Temper c'est un langage qui se veut assez simple mais expressif, pas dans le but de créer des applications mais de créer des librairies de types et d'utilitaires qui sont partageables facilement à travers toute la stack que vous avez, à moindre effort. Je trouve ça plutôt malin !

SQLite should have (Rust-style) editions - Mort's Ramblings🔗

#SQLite #Rust

Quelques notes sur le fonctionnement par défaut de SQLite. Plutôt des notes négatives pour le coup. Sans dire que SQLite est mauvais (c'est très bien au contraire), ça fait du bien de voir des vrais critiques négatives sur SQLite je trouve

Ce que je retiens :

• "Bad default #1: Foreign key constraints are ignored by default" : donc définir des clés étrangères ne sert à rien par défaut…
• "Bad default #2: Columns can store the wrong data type" : donc vous mettez INTEGER commme type sur une colonne, bah ok vous pouvez mettre un INT mais vous pouvez insérer une chaîne de caractère contenant un INT ça va passer aussi (car converti à l'insertion) mais aussi n'importe quoi qui n'est pas un INT ça sera stocké tel quel… Sauf si vous specifiez strict sur chaque définition de table…
• "Bad default #3: SQLITE_BUSY errors with concurrent writers" : autant de readers de la base qu'on veut en parallèle mais un seul writer, ça fonctionne sans lock / sans timeout (par défaut) donc un second writer qui arrive en parallèle ne va pas attendre, juste échouer directement…
• "Bad default 4: Performance" : il y a des petites limites de performances facile à corriger (en particulier sur l'écriture des logs) pour un usage serveur, pour le coup l'auteur fait référence à d'autres articles pour ce point

Tout ça c'est corrigeable avec des PRAGMA (règles à définir globalement sur votre instance SQLite) mais ça devrait être par défaut aujourd'hui, je suis d'accord avec l'auteur de l'article.

La proposition de l'auteur serait d'avoir un PRAGMA edition = 2026; (très similaire à ce qu'on retrouve chez Rust) qui serait une configuration implicite pour

PRAGMA foreign_keys = ON;
PRAGMA busy_timeout = 5000;
PRAGMA journal_mode = WAL;
PRAGMA synchronous = NORMAL;

(ligne à ligne : activer la validation des clés étrangères ; s'assurer qu'on ne bloque pas directement les écritures concurrentes ; éviter les problèmes de performance sur l'écriture des logs ; réduire les synchronisations avec le disque pour limiter les problèmes de performance)

Je trouve l'idée plutôt pas mal. Ça ouvre pas mal de porte à des breaking changes en douceur (on peut introduire une config qui par défaut à une valeur qui ne casse rien mais si on spécifie qu'on vise une édition plus récente, ça change la config et on doit suivre la nouvelle règle), ça permet aussi de décorréler la mise à jour de la librairie / l'outil de la mise à jour des pratiques (particulièrement une bonne chose pour la sécurité, car vous pouvez garder une seule branche à corriger dans le temps). C'est quelque chose qui serait profitable à voir un peu partout

Windows cache un identifiant secret que Microsoft file au FBI - Korben🔗

#Microsoft #Vie-privée #OS #Windows

Un hackeur qui se fait avoir parce qu'il utilise Windows 11 derrière sa pile de VPN (sûrement en se disant qu'avoir un WSL c'est largement aussi safe qu'un Linux 🤷‍♂️) parce que Windows vous colle un identifiant unique (GDID = Global Device IDentifier) à l'installation, identifiant qui est leak à droite à gauche, stocké avec votre IP à chaque fois que vous vous connectez à Internet. Évidemment, PatriotAct oblige, si le FBI ou CIA demande à Microsoft ils doivent leur filer les infos associées à votre GDID (votre historique d'IP, de connexion, etc.).

Comment on se débarrasse du GDID ? Vous ne pouvez pas. Comment on change de GDID ? Vous ne pouvez pas. Comment vous pouvez voir votre GDID ? Vous ne pouvez pas.

Merci Microsoft de respecter notre droit à la vie privée 💩

Low Resource Computing🔗

Je cite directement toute la page d'accueil qui correspond parfaitement à ce que je pense (j'ai songé plusieurs fois à plaquer le web pour partir sur cette voie ces dernières années) :

Looking Back, Looking Forward

Computation started as a puzzle. We built national banking systems using 92kIPS microprocessors. We built rendering engines using a PDP-8 and a DAC. We flew to the moon with a 2MHz CPU, a slide rule, and a dream. The resources behind these accomplishments look modest only in hindsight. What is trivial now was enough then.

Somewhere along the way, we lost sight of this goal. Software wastes hardware because it can afford to do so. We use Electron, wrangling the whole Chrome V8 engine, just to edit text; we ask gigawatt data centers what the weather will be tomorrow. It's a competition to see how much compute and money we can throw at our problems before they fix themselves. Exascale datacenters keep growing, gigawatt compute farms keep chugging more electricity, and billion-dollar networks keep asking for more money. It's a race to the bottom, and other than being boring and expensive, it's impossible to keep growing like this forever.

This year, LRC is looking at the past as an inspiration for the future. As mainstream computers hog more and more resources, meaningful computation remains essential at the scale of kilobytes, kilohertz, and nanowatts. This workshop is all about countering the fad of infinite growth, it's about putting processing power back in individuals' hands, and it's about contributing to a more reasonable and sustainable future. How far can today's modest resources really go?

Let's find out.

Par contre c'est dommage, y'a rien en ligne (ou pas trouvé), donc à moins d'avoir un coup de chance et qu'ils viennent des USA pour faire une édition pas loin c'est dead on restera sur l'introduction…

Crédit photo : Générée via Mistral AI avec le prompt suivant :

Une scène chaleureuse et immersive, inspirée par l’esthétique poétique de Studio Ghibli, représentant un bureau de travail en bois clair et vieilli, baigné d’une lumière dorée et tamisée, comme un après-midi d’automne. Au centre, une silhouette stylisée (style anime Ghibli : traits doux, visage non détaillé, vêtements amples et confortables) est assise en tailleur sur un tapis épais, absorbée par la lecture d’un journal tech futuriste. Le journal est ouvert, ses pages légèrement froissées, avec des titres en en-tête calligraphiés à la main : "Frontend", "Backend", "IA", "Sécurité", et "Vie privée". Les pages brillent d’un halo bleu pâle, évoquant des lignes de code et des schémas techniques qui s’animent discrètement, comme par magie. Autour d’elle, des piles de magazines et de carnets s’empilent de manière désordonnée mais harmonieuse. Certains sont ouverts, révélant des extraits d’articles, des croquis de frameworks (représentés par des icônes génériques : un crochet pour le frontend, un engrenage pour le backend, un cerveau pour l’IA, un cadenas pour la sécurité, et un masque pour la vie privée), ou des diagrammes de réseaux de neurones dessinés à la main. Un écran transparent et flottant (style holographique, mais avec un cadre en bois sculpté) affiche des flux d’informations en temps réel : des graphiques de données, des alertes de sécurité, et des extraits de code, le tout dans un style doux et organique, comme intégré à la scène. En arrière-plan, une grande fenêtre donne sur un paysage urbain nocturne style Ghibli : des bâtiments aux formes arrondies, des lanternes suspendues, et des néons bleutés qui reflètent des motifs de code binaire sur les murs. Une tasse de thé fumant et un petit robot de bureau (inspiré des créatures de Ghibli, comme un mélange entre un Totoro miniature et un assistant tech) observent la scène avec curiosité. À droite, un panda roux (ton animal préféré) est lové sur un coussin, les yeux mi-clos, comme s’il écoutait attentivement. Il ne doit pas dépasser le tiers de la hauteur de l’image et est positionné en bas à droite, légèrement tourné vers le centre, avec une queue soyeuse enroulée autour de lui. L’ambiance est à la fois cosy, onirique et high-tech : les couleurs sont douces (beiges, bleus pâles, oranges chauds), avec des contrastes subtils pour mettre en valeur les éléments tech. Les détails sont soignés, avec des textures visibles (grain du bois, tissu du tapis, pelage du panda), et une lumière qui crée des jeux d’ombres chaleureuses. Le tout respire la sérénité et l’inspiration, comme un moment suspendu entre la magie et la technologie.

Note : tout ce que je vais dire dans cet article, il est possible de le retrouver de manière "interactive" sur une petite application que j'ai créée (avec Angular évidemment) et déployée ici. Cette application "guideline" est pensée pour montrer comment passer d'un composant utilisant les anciens code-styles vers un composant plus au goût du jour.

Écosystème et quotidien de dev🔗

Avant même de parler de code style, il faut rappeler qu'Angular c'est plus qu'un framework : c'est un écosystème de librairies et d'outils pour nous aider au quotidien, pour répondre à différent besoin, certains officiels, d'autres non.

Le premier à citer pour moi c'est l'Angular DevTools, car il va vous permettre d’introspecter votre application pendant la phase de développement pendant qu'elle tourne. C'est très pratique, ça donne une autre vision de l'application, et même si ça demande un peu d'habitude, ça peut vraiment aider à comprendre plus vite ce qui coince.

Ensuite pour moi en 2026, on est obligé de parler IA. Angular propose un fichier AGENTS.md (ou ̀CLAUDE.md, etc.) qui est très complet, et il donne une bonne base pour comprendre comment on doit faire du Angular dans le monde moderne. Il y a évidemment quelques portes ouvertes qui sont enfoncées (ce fichier est prévu pour cadrer un Agent IA à la base, donc c'est logique), mais il y a un début de piste pour accompagner chaque développeur aussi.

Une étape du quotidien à ne pas négliger c'est les migrations de versions. Si on les fait régulièrement et en suivant des bonnes pratiques, c'est très simple, sinon ça peut devenir un calvaire. C'est facile d'être accompagné pour cette étape, et il faut pour moi commencer par aller lire le blog officiel qui va annoncer les nouveautés importantes de chaque mise à jour. Je recommande aussi d'aller voir le blog de la Ninja Squad où pour chaque version on retrouvera un billet beaucoup plus détaillé, rentrant en profondeur dans ce qui change et s'il faut faire attention à certains points. Il faut aussi inspecter les dépendances du projet, qui peuvent nous lier à une version Angular et nous empêcher de migrer. Pour réaliser la migration il faut absolument suivre le guide de mise à jour officiel, car il va nous indiquer tout ce qu'il faut absolument vérifier avant de commencer la mise à jour, la commande à lancer pour réaliser la mise à jour et ce qu'il faut valider après coup. Personnellement pour chaque migration, je vais m'assurer que je n'ai rien oublié côté script de migration via Angular Can I Use et vérifier aussi quelles nouvelles fonctionnalités je peux maintenant utiliser (particulièrement utile si vous avez un peu de retard sur les versions !). On termine par un coup d'œil pour s'assurer qu'aucune dépendance liée à Angular n'a été oublié et qu'un npm ci (après suppression des node_modules) fonctionne toujours bien.

Parlons composant simple🔗

Même si tout le monde n'est pas d'accord avec ça : je vous recommande d'utiliser des Single File Component (SFC). C'est quoi un SFC ? Simplement un composant qui est entièrement écrit dans le fichier TypeScript, avec le template dans la propriété template (et non templateUrl, qui permet de pointer un fichier HTML), et le style dans styles. Ça va vous débloquer plusieurs choses : vous allez moins naviguer de fichier en fichier, vous serez incité à créer des petits composants (réutilisable ou non) pour ne pas avoir un fichier trop gros. Un composant n'est qu'une classe TypeScript et un template, ne sacralisez pas la création d'un composant : faites des petits composants avec une responsabilité limitée et tout deviendra plus simple et plus maintenable dans le temps. Rappelez-vous aussi que rien n'interdit en Angular d'avoir plusieurs composants / directives dans le même fichier !

Il faut évidemment utiliser les nouveaux control flow. Adieu les *ngIf, *ngFor et *ngSwitch, bonjour les @if, @for et @switch. Ils sont plus simples à utiliser, beaucoup plus performant, bien mieux typé, ne demande aucun import. Pour le @for vous serez aussi obligé de passer un track pour qu'Angular sache comment il doit identifier chaque entrée du @for et limiter les re-rendu inutile. Il faut autant que possible éviter de passer $index, qui risque de dégrader les performances si vous avez besoin de re-rendre souvent la liste à cause d'ajout / suppression.

Côté entrée/sortie, exit aussi des @Input() et @Output(), bienvenue aux input() et output(). Je dirais même que vous voulez au maximum écrire input.required<TheInputType>() pour indiquer explicitement quelles sont les entrées obligatoires au bon fonctionnement de votre composant, et aussi leur type pour que ce soit vérifié à la compilation ! Comme nos entrées / sorties sont censés être immuables, profitez-en pour les passer systématiquement en public readonly, de cette façon c'est TypeScript qui s'assurera que vous ne fassiez pas d'erreur.

Dans la même logique, ajoutez private readonly devant chaque propriété que vous définissez dans votre classe, protected readonly si vous avez besoin d'y accéder dans le template. Encapsuler au maximum vos composants est toujours une bonne chose, et protéger au maximum les états internes est important. Au passage ça donnera une indication claire aux autres développeurs sur où est utilisé un élément (private = uniquement dans la classe TypeScript, protected = dans la classe et/ou le template, public = à l'extérieur). En TypeScript, ne pas indiquer de modificateur de portée impliquera que l'élément sera public implicitement.

Même si historiquement on conseillait d'utiliser beaucoup plus les Pipe pour les formatages, et au final à l'usage, on se rend compte qu'il vaut mieux utiliser simplement un computed(). La syntaxe est plus courte, on retrouve quasiment les mêmes avantages que les Pipes (à part la réutilisabilité), c'est assez naturel quand on manipule beaucoup de Signal.

Respecter le naming convention d'Angular c'est important aussi. Les basiques c'est avoir un app- au début du sélecteur de chaque composant, utiliser systématiquement du kebab-case pour le nom du sélecteur, du PascalCase pour les noms de composant (sans spécifier Component à la fin). Techniquement ça fonctionne bien sans ça, mais ça permet de plus facilement s'y retrouver, plus facilement suivre ce qu'on fait, être raccord entre les différents membres de l'équipe.

Pour finir : ne pas oublier la plateforme. Quand vous faite du Angular, vous allez utiliser la plateforme web, utilisez une solution native de la plateforme web plutôt qu'une solution Angular sera toujours mieux !

Voici un exemple avec deux composants qui respectent ce code style :

import { Component, computed, input } from "@angular/core";

interface Person {
    id: string;
    firstname: string;
    lastname: string;
}

@Component({
    selector: "app-person-card",
    template: `
        <div class="card">
            <h3>{{fullName()}}</h3>
        </div>
        `,
    styles: `
        .card {
            border: 1px solid light-dark(lightblue, orange);
            padding: 0.5em 1rem;
        }
        `,
})
export class PersonCard {
    public readonly person = input.required<Person>();
    protected readonly fullName = computed(() => `${this.person().firstname} ${this.person().lastname}`);
}

const PEOPLE: Person[] = [
    { id: "0", firstname: "Aïcha", lastname: "Diallo" },
    { id: "1", firstname: "Lucas", lastname: "Martinez" },
    { id: "2", firstname: "Léa", lastname: "Nguyen" },
    { id: "3", firstname: "Karim", lastname: "Benali" },
    { id: "4", firstname: "Mei", lastname: "Chen" },
    { id: "5", firstname: "Élodie", lastname: "Moreau" },
];

@Component({
    selector: "app-person-list",
    template: `
        @for (person of PEOPLE; track person.id) {
            <app-person-card [person]="person" />
        }
        `,
    styles: `
        :host {
            display: flex;
            gap: 0.25em;
            flex-wrap: wrap;
        }
        `,
    imports: [PersonCard],
})
export class PersonList {
    protected readonly PEOPLE = PEOPLE;
}
TypeScript

Et on ajoute un service !🔗

Le grand classique c'est de voir des choses comme ça :

@Component({ ... })
export class PersonList implements OnInit {
    protected people: Person[] = [];

    constructor(private http: HttpClient) {}

    ngOnInit() {
        this.http.get("/assets/demo/components-and-services/people.json").subscribe((people: any) => {
            this.people = people;
        });
    }
}
TypeScript

Trop de problèmes… On passe toujours pas de l'injection dans le constructeur, on a toujours un ngOnInit(), on utilise le HttpClient dans le composant directement, on fait un subscribe (sans unsubscribe de surcroit), on ne type correctement…

En Angular moderne, vous pouvez faire beaucoup plus simple. Déjà vous pouvez passer directement par inject() pour injecter vos différents services en propriété (private readonly évidemment !). Comme on a besoin que d'un seul appel, on peut directement faire d'un coup l'injection et l'appel, en typant directement le inject(HttpClient).get<Person[]>(...) pour éviter un any. On peut éviter le .subscribe() en passant par un toSignal(...) et laisser Angular gérer ça pour nous.

Tant qu'à faire on peut déplacer toute cette logique d'appel vers un service dédié. Si on a besoin, on pourra alors même faire un cache interne au service pour s'assurer qu'on ne fait pas un appel HTTP pour chaque utilisation du service.

En résumé, l'idée c'est de viser quelque chose qui ressemble à ça :

import { HttpClient } from "@angular/common/http";
import { Component, Injectable, inject } from "@angular/core";
import { toSignal } from "@angular/core/rxjs-interop";
import { catchError, of, shareReplay } from "rxjs";
import { PersonCard } from "./person-card";

export interface Person {
    id: string;
    firstname: string;
    lastname: string;
}

@Injectable({ providedIn: "root" })
export class PeopleService {
    private readonly http = inject(HttpClient);
    private readonly people$ = this.httpGetPeople().pipe(shareReplay(1));

    getPeople() {
        return this.people$;
    }

    private httpGetPeople() {
        return this.http.get<Person[]>("/assets/demo/components-and-services/people.json").pipe(
            catchError((err) => {
                console.error(err);
                return of([]);
            }),
        );
    }
}

@Component({
    selector: "app-person-list",
    template: `
        @for (person of people(); track person.id) {
            <app-person-card [person]="person" />
        }
        `,
    styles: `
        :host {
            display: flex;
            gap: 0.25em;
            flex-wrap: wrap;
        }
    `,
    imports: [PersonCard],
})
export class PersonList {
    protected readonly people = toSignal(inject(PeopleService).getPeople(), { initialValue: [] });
}
TypeScript

Côté composant c'est vraiment beaucoup plus simple, on retrouve juste une déclaration d'un accès à une liste de personne. Dans le service on retrouve notre appel HTTP mais aussi une gestion d'erreur (simpliste mais présente pour l'exemple), on retrouve aussi une mécanique simple de partage de ressource entre différent appelants (comme on pose dès le début un Observable people$ qui est un appel HTTP suivi d'un shareReplay(1), le premier subscriber va déclencher l'appel HTTP, les suivants consommeront directement la réponse). Au passage cette mécanique nous permet d'encapsuler entièrement l'appel HTTP, donc si demain on veut changer quoi que ce soit (changer l'URL, ajouter une transformation avant/après chaque appel, etc.) on pourra le faire en impactant pas les appelant ou à minima en sachant très facilement qui dépend de cet appel (seulement les appelants de getPeople() qui ne peuvent que lire cet Observable et rien de plus).

Conclusion🔗

On trouve beaucoup de ressources en ligne qui indiquent comment faire bien un point particulier en Angular, on retrouve peu de contenu qui vous donne un guide pour passer sur le code style moderne avec les explications qui vont bien. Je ne sais pas si ce que j'ai fait répondra vraiment à ce besoin, mais je vais essayer de maintenir mon application à jour au fil des versions, d'améliorer le contenu au fil du temps, pour le rendre toujours utile au plus grand nombre.

Sources :

• Guide interactif
• Angular DevTools
• Blog officiel Angular
• Blog de la Ninja Squad
• Guide de mise à jour officiel
• Angular Can I Use

Crédit photo : Générée via Mistral AI avec le prompt suivant :

A serene Studio Ghibli-inspired scene of a Zen garden where Angular component flowers bloom, viewed from a close-up perspective. Each flower has a label with modern Angular features like '@for', 'computed()', 'toSignal', and 'inject()'. The flowers representing SFC (Single File Component) are peonies with petals shaped like TypeScript files. A magical watering can (teapot-shaped) is watering the flowers, making them grow, while weeds labeled '*ngFor without track' and 'any' wither away. A red panda, sitting cross-legged, is trimming a bush shaped like the 'PersonCard' component. In the background, a torii gate has a sign reading 'Angular DevTools'. The atmosphere is peaceful with green/blue gradients and golden reflections on the petals. The scene is set in autumn with a warm, golden light, wooden textures, and 8-10 floating maple leaves in red, orange, and yellow. The red panda is in the bottom right, less than 1/3 of the height, with a glowing halo around the high-tech elements.

Cloudflare rachète VoidZero, la société open source derrière Vite et les outils de compilation JavaScript qui l'entourent, afin de placer sa plateforme pour développeurs au cœur du développement web avec l'IA🔗

#Vite #Frontend #VoidZero #Cloudflare

VoidZero, donc Vite et tous les outils sous-jacents, part sous la gouverne de Cloudflare. Evan You reste à la tête de la roadmap de toute la suite open source.

Avec Evan You à la tête, on peut espérer que tout reste cohérent et que tout continue sur la même trajectoire. Si on le voit partir, il sera temps de paniquer j'imagine 😅

OpenNG Foundation🔗

#Angular #Frontend

Super initiative : Gérôme Grignon et Dominic Bachmann ont décidé de lancer une fondation pour porter des librairies Angular qui sont un peu partout pourtant abandonnés. L'idée c'est de permettre aux équipes qui utilisent ces libs de basculer sur le fork supporté par la fondation pour ensuite suivre les nouvelles versions d'Angular soit en maintenant la lib soit en proposant des schematics de migration vers des briques standard et modernes d'Angular pour retirer la dépendance.

Pour décider quelles libs seront maintenues par ce biais, on peut soumettre une lib en postant une issue sur le Github et avoir une évaluation de la nécessité de maintenir.

Les process sont encore en construction, mais je pense que ça peut donner des très bonnes choses dans le futur !

Desktop apps | Deno Docs🔗

#Deno #TypeScript #App #Frontend

Grosse nouveauté de la part de Deno : la possibilité de créer des applications Desktop (en CLI ou avec des fenêtres graphiques) avec Deno avec un simple deno desktop ! 😲

C'est un truc de fou. C'est pas encore dans la version stable, mais je trouve ça déjà fou !

What's new in Angular 22.0? - Ninja Squad🔗

#Angular #Frontend

Beaucoup de petites nouveautés sur cette version comme d'habitude. Je vous encourage à aller voir l'article de Cédric qui détaille tout très bien !

Ce que je retiens surtout :

• le passage en stable des Signal Forms ;
• OnPush par défaut sur tous les composants (sur une application perso dont je parle bientôt, la migration de v21 à v22 m'a ajouté changeDetection: ChangeDetectionStrategy.Eager sur tous mes composants, et je les ai enlevés sans incidence, mais à tester de votre côté !) ;
• resource(), rxResource() et httpResource() passent en stable ;
• introduction de @Service() qui est presque équivalent à @Injectable({ providedIn: 'root' }) (presque, car on ne peut utiliser que inject() pour faire de l'injection et quelques autres petites subtilités) mais maintenant recommandé ;
• le client Http utilise maintenant fetch() par défaut (attention à la migration qui va vous ajouter withXhr() automatiquement pour rester en XMLHttpRequest pour éviter le breaking change) ;
• pas mal de petites améliorations sur la compilation/validation des templates ;

Pas de très gros changement, mais encore et toujours la continuité des évolutions qui vont amener des choses bienvenues !

IA🔗

Uber : l'IA coûte cher, alors les employés devront moins l'utiliser à l'avenir🔗

#IA

500 millions de dollars dépensé en 1 mois. Plafond à $1500/mo/outils/dev. Bon bah voilà même des grosses boîtes comme Uber commencent à mettre le holà.

Il faut renflouer les caisses après avoir passé 3 ans à cramer le pognon des investisseurs 😅

Un éditeur de logiciels va priver ses 5000 employés d'augmentations pour consacrer ces fonds aux investissements en IA. Les PDG persistent dans l'IA en dépit des retours de productivité et financiers décevants🔗

#IA #Emploi

Donc en résumé :

• on arrive toujours pas à montrer une rentabilité franche sur les projets IA ;
• on voit le prix des outils d'IA exploser, donc la rentabilité s'éloigner ;
• travailler avec des outils d'IA coûte plus cher que faire travailler des humains ;
• on voit toujours une impasse écologique à date à continuer de faire croître les usages IA (pas dans l'article, mais facile de trouver des sources) ;

Conclusion : il faut continuer à claquer un max d'argent dans l'IA pour pas perdre la course face aux autres boîtes 😅 quitte à ne plus augmenter du tout ses employés pour avoir du cash à mettre dans ce mirage 🤔

Sécurité🔗

GitHub - Webba-Creative-Technologies/vice: VICE is a security auditing CLI tool that finds vulnerabilities in your web applications. · GitHub🔗

#HTTP #Sécurité #Web

Je cite un bout du post LinkedIn de l'auteur :

On a construit VICE pour répondre à cette question.

C'est un outil open source qui audite la sécurité de tes apps web. Tu lui donnes une URL, il fait comme un attaquant : il crawle le site avec un vrai navigateur, cherche les secrets dans le JS, teste les RLS Supabase, scanne les ports de ton VPS, tente du brute force sur ton login, vérifie les headers HTTP, et te sort un rapport avec un score de A à F.

Il a aussi un mode local : tu le lances dans ton projet et il analyse ton code source. Il trouve les injections SQL, les XSS, les .env mal configurés, les dépendances vulnérables, et te dit exactement quoi corriger avec des exemples de code.

22 modules. Un seul outil. Open source.

Une hackeuse a pris le contrôle du streaming du Mondial 2026 et a failli troller 3 milliards de téléspectateurs🔗

#Sécurité #Hack

Bobdahacker a pu se créer un compte agent FIFA et accéder à tout ce qui faisait fonctionner les diffusions live de la Coupe du Monde 2026 (flux streams, sources des flux, paramétrages, etc.)

Le maillon le plus faible de la chaîne de sécurité c'est l'humain :

• les devs qui n'ont mis une sécurité que côté client ;
• les gens qui ont posé le process de création de compte ;
• les gens qui valident la création de compte ;
• les gens qui ont décidé d'affecter les droits à n'importe quel agent pour l'accès à ces briques-là ;

Sérieux souci de sécurité à la FIFA 😅

Google veut scanner votre main pour prouver que vous êtes humain - Korben🔗

#Google #Vie-privée #Sécurité

En résumé : faire du CAPTCHA mais en se basant sur 21 points spécifiques de notre main pour valider que c'est une main humaine…

Je cite Korben qui résume bien le truc :

Côté vie privée, Google jure sur la tête de ses morts que toutes les vidéos et les photos prises par le CAPTCHA sont supprimées une fois le défi relevé, qu'aucun son n'est enregistré et que rien n'est associé à votre identité mais peu importe ce qu'ils nous baragouinent, on n'a aucun moyen de le vérifier de toute façon.

Puis que ce soit votre main, votre visage ou vos fesses, prendre 21 points de mesure sur votre anatomie, ça reste de la biométrie quand même. Rien qu'avec ça, vous pouvez identifier une personne avec 99% de précision… Donc n'allez pas me dire qu'ils n'ont pas autre chose en tête avec cette connerie.

Un usage biométrique pour faire de la sécurité contournée en 10s via des photos, qu'ils savent qu'on peut contourner en 2 clics en basculant sur l'ancien système (Google ne peut pas obliger ce système : y'a des utilisateurs sans main ou qui ne peuvent pas les bouger), c'est clairement pas la sécurité le but derrière…

Divers🔗

Let's Encrypt interdit l'utilisation de son (ses ?) service·s aux pays sanctionnés par les États-Unis — carlchenet@mastodon.social🔗

#USA #Internet #HTTP #Web

Let's Encrypt se soumet aux blocages demandés par les USA. Pourquoi ? Let's Encrypt c'est géré par l'ISRG (Internet Security Research Group). Et sur le site de l'ISRG on peut lire

ISRG is a California public benefit corporation[…]

Donc en résumé : à date Let's Encrypt c'est américain donc soumis aux Lois américaines 🤷‍♂️ et croyez-moi : ça me soule parce que c'est très bien, mais il va falloir commencer à chercher des alternatives souveraines…

GitHub - WeebLabs/DSPi: A fully featured audio DSP firmware for the Raspberry Pi Pico (RP2040) and Pico 2 (RP2350) · GitHub🔗

#Raspberry-Pi #RP2040 #RP2350

Assez impressionné de voir un moteur DSP pour Raspberry Pi Pico (RP2020) ou Pico 2 (RP2350) très complet, surtout vu le prix de ces puces ! Ça ouvre pas de porte pour du matériel ouvert et vraiment pas cher !

Developer Advocate, c'est une bonne situation ça ? - CALM🔗

#Métier-de-dev #Dev #DevRel

Article de Thierry Chantier sur son parcours et ses questionnements autour du métier de Developer Advocate (aussi appelé Developer Relation ou DevRel ou d'autres noms).

C'est toujours intéressant de voir des gens se questionner sur leur métier et voir où ça les emmène. On voit dans le cas de Thierry que finalement le métier lui est un peu tombé dessus parce qu'il faisait naturellement le travail mais en temps perso

Merci Thierry pour ce REX !

Assurance Léocare : avis (très) négatif - Le Hollandais Volant🔗

#Assurance

Je partage car beaucoup d'informations intéressantes sur Léocare (une société d'assurance) mais même sur les procédures avec les assurances en général

En tout cas : 1) je n'irais jamais chez Léocare 2) je n'ai jamais eu ce genre de souci avec Pacifica (mon plus gros problème avec eux à date c'est le besoin récurrent de passer par téléphone pour la plupart des démarches, mais toujours faites hyper vite en contrepartie)

Crédit photo : Générée via Mistral AI avec le prompt suivant :

Une scène chaleureuse et immersive, inspirée par l’esthétique poétique de Studio Ghibli, représentant un bureau de travail en bois clair et vieilli, baigné d’une lumière dorée et tamisée, comme un après-midi d’automne. Au centre, une silhouette stylisée (style anime Ghibli : traits doux, visage non détaillé, vêtements amples et confortables) est assise en tailleur sur un tapis épais, absorbée par la lecture d’un journal tech futuriste. Le journal est ouvert, ses pages légèrement froissées, avec des titres en en-tête calligraphiés à la main : "Frontend", "Backend", "IA", "Sécurité", et "Vie privée". Les pages brillent d’un halo bleu pâle, évoquant des lignes de code et des schémas techniques qui s’animent discrètement, comme par magie. Autour d’elle, des piles de magazines et de carnets s’empilent de manière désordonnée mais harmonieuse. Certains sont ouverts, révélant des extraits d’articles, des croquis de frameworks (représentés par des icônes génériques : un crochet pour le frontend, un engrenage pour le backend, un cerveau pour l’IA, un cadenas pour la sécurité, et un masque pour la vie privée), ou des diagrammes de réseaux de neurones dessinés à la main. Un écran transparent et flottant (style holographique, mais avec un cadre en bois sculpté) affiche des flux d’informations en temps réel : des graphiques de données, des alertes de sécurité, et des extraits de code, le tout dans un style doux et organique, comme intégré à la scène. En arrière-plan, une grande fenêtre donne sur un paysage urbain nocturne style Ghibli : des bâtiments aux formes arrondies, des lanternes suspendues, et des néons bleutés qui reflètent des motifs de code binaire sur les murs. Une tasse de thé fumant et un petit robot de bureau (inspiré des créatures de Ghibli, comme un mélange entre un Totoro miniature et un assistant tech) observent la scène avec curiosité. À droite, un panda roux (ton animal préféré) est lové sur un coussin, les yeux mi-clos, comme s’il écoutait attentivement. Il ne doit pas dépasser le tiers de la hauteur de l’image et est positionné en bas à droite, légèrement tourné vers le centre, avec une queue soyeuse enroulée autour de lui. L’ambiance est à la fois cosy, onirique et high-tech : les couleurs sont douces (beiges, bleus pâles, oranges chauds), avec des contrastes subtils pour mettre en valeur les éléments tech. Les détails sont soignés, avec des textures visibles (grain du bois, tissu du tapis, pelage du panda), et une lumière qui crée des jeux d’ombres chaleureuses. Le tout respire la sérénité et l’inspiration, comme un moment suspendu entre la magie et la technologie.

Préambule : si je fais cet article, ce n'est pas pour me plaindre : j'ai choisi d'être membre de l'association (étant un des fondateurs), j'ai choisi d'être organisateur en connaissance de cause, mais je trouvais ça important de partager sur une réalité qui n'est pas trop vu des participants, parce que ça me parait toujours important de partager sur nos expériences, et que ça pourrait aider d'autres organisateurs de conférences à relativiser et/ou à se lancer.

De Angular Devs France à NG Baguette Conf en passant par Angular Nexus🔗

Pour créer une conférence il nous fallait un cadre légal : une identité juridique, un compte bancaire, et un nom. Si dès 2023, on a communiqué sous le nom Angular Devs France, on voulait un nom plus percutant pour la conférence, et après pas mal de réflexion, on s'était arrêté sur Angular Nexus (Nexus signifiant "connexion" en grec, ça représentait plutôt bien ce qu'on cherchait à réaliser).

Vous n'avez jamais vu la conférence Angular Nexus ? Ne vous en faites pas, vous n'avez rien loupé, elle n'a jamais eu lieu. C'est un projet de 2024 mort dans l'œuf… Mais qui nous aura permis de prendre du recul et réfléchir !

Par contre, nous avons monté une association avec ce nom. Après quelques changements et quelques péripéties administratives, nous sommes aujourd'hui deux membres dans le bureau (Gérôme est président et moi-même je suis vice-président (après avoir eu le rôle de trésorier 😈)), ainsi que deux membres Camille et Yann-Thomas. On a choisi d'avoir un bureau très simple et des statuts qui nous permettent d'évoluer facilement pour garder de la souplesse.

En 2025, on a réalisé une première édition d'une conférence : NG Baguette Conf (en partant d'une blague qui circulait qu'une conférence française devrait forcément s'appeler "NG Baguette"). En janvier 2025, nous n'avions pas de compte en banque, pas de statuts exploitables et on s'est fixé de jouer notre conférence fin mai. On a eu la chance et un peu de culot, on a pu réserver gracieusement une partie des locaux de Onepoint Nantes et on a eu de l'aide pour la partie traiteur. En un peu plus de 4 mois, nous sommes passés d'une chaîne Youtube à une conférence en physique, des tops speakers européen et une centaine de personnes qui nous ont fait confiance. Pour être honnête : j'avançais la tête dans le guidon sans y croire complètement, il a fallu que je voie les gens défiler à la billetterie pour réaliser !

Puis on a remis une pièce pour une seconde édition, en augmentant l'ambition.

L'été 2025🔗

En Juin 2025, Gérôme, Camille, Yann-Thomas et moi avons fait le bilan de NG Baguette Conf 2025 :

• On avait un peu moins de 600€ sur le compte en banque (tout notre budget 2025 étant globalement parti dans la nourriture pour le déjeuner) ;
• On avait des contacts à Nantes, même si plus personne de l'équipe n'y vivait (Gérôme et moi vivions encore à Nantes jusqu'à début 2025) ;
• On avait des retours sur la première édition nous montrant que refaire une édition à Nantes serait une erreur ;
• On avait envie de refaire une édition, mais en changeant tout ce qui paraissait non viable et en suivant les quelques retours qu'on avait eus via le formulaire de feedback ;

On décide de passer du samedi au vendredi. On décide d'augmenter le prix du billet participant, la première édition ayant été compliquée du fait qu'on faisait reposer une trop grosse part de notre budget sur les sponsors et avec des billets d'entrées quasi donné (25-30€). On décide de déplacer la conférence sur Paris, plus central que Nantes, plus facile d'accès en train.

On se lance dans la recherche d'un lieu pour fixer la date ! Ah non… Réaliser NG Baguette Conf 2025 a été une course épuisante, on a pas réussi à avoir de l'énergie pour bosser le sujet dans l'été, on a réussi à reprendre qu'en début octobre 2025…

Ce qu'il faut bien comprendre avec NG Baguette Conf, c'est que nous avons été quatre à travailler sur tout, quatre c'est peu, et organiser un événement comme ça demande beaucoup d'énergie. Nous sommes tous les quatre bénévoles (clairement, si on devait être objectif : NG Baguette Conf nous coûte de l'argent aujourd'hui), nous avons un travail de développeur à temps plein à côté. On ne le vit pas comme un fardeau, on ne le vit pas négativement, je pense juste que c'est important qu'on soit transparent sur ce genre de choses.

La Sorbonne Sciences🔗

On a démarché beaucoup de lieux, on a comparé les prix et prestations de beaucoup d'options avant d'en arriver à La Sorbonne Sciences.

On avait quelques contraintes :

• Un budget relativement contenu : on est une petite conférence, avec un petit budget, on veut garder un billet participant contenu ;
• Un amphithéâtre avec au moins 150 places : on partait d'une édition avec une grosse centaine de personnes avec l'optique de gonfler le nombre de participants (on ne veut pas faire une grosse conférence à plusieurs centaines de personnes, mais avoir un peu plus de participant donne de la souplesse sur ce qu'on peut réaliser) ;
• Avoir un espace dans lequel se restaurer : proposer un repas à chaque personne présente est très important pour nous, c'est un moment pour faire un clin d'œil au nom de notre conférence (le centre du repas est un sandwich baguette), mais surtout c'est un moment où les participants peuvent échanger, et aussi un moment pendant lequel on peut échanger avec les participants ;
• Une pièce à l'écart pour servir de salle speakers ;
• Pouvoir circuler relativement facilement entre les trois espaces ;

Dans l'équipe nous sommes tous développeurs, nous sommes tous speakers et nous sommes maintenant tous organisateurs d'une conférence. C'est en cumulant ces 3 casquettes qu'on dessine ce qu'est la conférence.

L'expérience speaker peut vous sembler secondaire, mais pas à nous. Quand on est speaker, on investit énormément de temps personnel (comptez entre 10 et 20h de préparation minimum pour une session de 45-50min), on investit de l'énergie pour proposer un sujet, le préparer, se déplacer jusqu'à la conférence et le jouer. Il y a quelques points qui font que l'expérience qu'on a en tant que speaker est bien meilleure : avoir un contact privilégié avec une personne de l'organisation, avoir un espace où se poser au calme (parfois pour répéter, parfois pour des retouches de dernière minutes, parfois pour travailler pour son employeur), avoir un moment pour rencontrer l'équipe organisatrice et/ou le MC qui va nous introduire.

Si dans l'équipe on tient à l'expérience participant, on tient aussi à l'expérience speaker. C'est cette expérience qui fait que nos speakers reviendront, c'est cette expérience qui fera qu'on aura des très bonnes propositions d'éditions en éditions.

Je ne citerais pas de lieu en particulier (je ne veux pas donner une quelconque impression de bashing, ce n'est pas le cas), mais les budgets sur Paris sont élevés, on avait souvent des devis entre 10 000 et 15 000€ (voir beaucoup plus) ce qui n'était pas envisageable.

La Sorbonne nous a proposé un budget de 6 700€ tout compris, un amphithéâtre de 221 places, un patio accolé et couvert (on vise mai et la pluie potentielle qui va avec) et une salle de classe un peu à l'écart.

Avec ou sans viande ?🔗

Le second gros point de recherche, vous vous en doutez surement, c'est la nourriture.

Notre conférence s'appelle "NG Baguette Conf", si avec baguette dans le nom, on ne sert pas de baguette, pour nous, c'est un échec. On vise un menu relativement simple : un sandwich baguette et un dessert (type gâteau boulangerie / pâtisserie). Ce n'est pas grand luxe, c'est très français, c'est à la fois facile et compliqué. C'est facile parce que je pense que chacun chez lui est capable de faire un sandwich qui tient debout sans trop d'effort, c'est compliqué parce qu'il faut arriver à un sandwich qui plaira au plus grand nombre, un sandwich qui laissera un bon souvenir aux participants.

Évidemment, on veut bichonner nos participants, et on veut offrir un petit-déjeuner, on veut aussi offrir du café, du thé, des jus de fruit, ainsi qu'une collation l'après-midi.

Quand on vise entre 150 et 180 personnes à nourrir il faut qu'on trouve un traiteur ou une boulangerie qui respecte ce qu'on souhaite faire, il faut qu'on trouve un prix cohérent. Avec avoir démarché pas mal de boulangerie et traiteur, au vu de la quantité dont on avait besoin, on arrivait généralement entre 4 000 et 6 000 €, en sachant que certains nous proposaient des devis beaucoup plus élevés. (encore une fois, pas de bashing, on comprenait généralement pourquoi c'était plus cher, mais juste ce n'est pas pour nous)

Au final nous avons arrêté notre choix sur le traiteur Votre Instant Gourmand. Pourquoi ? De base, ils ne font pas de sandwich (plutôt habitué aux menus mariages ou des apéros dinatoire) mais ils ont compris notre univers et acceptés de composer quelque chose de sur mesure sans avoir un prix délirant. On a aussi eu des conseils de leur part, des réponses claires, précises et rapide à chacune de nos questions, et pour finir la possibilité de fixer un nombre final de part au plus tard 10 jours avant la date. Ils nous proposaient d'avoir du personnel le jour J pour l'installation et le service, ce qui allait nous rendre beaucoup plus sereins pour tout gérer.

On a validé un budget de 5 400€ pour la nourriture. Notre second plus gros poste de dépense.

Les "petites dépenses"🔗

Si on arrive déjà à plus de 10 000€, il faut aussi se dire qu'on a pas que ça comme dépense. Il y a plein de choses qui nous coûte de l'argent.

Déjà, chaque participant pendant l'événement a un badge (simple carton A6), une étiquette autocollante à son nom et un tour de cou. Ça nous coûte environ 100€, j'imprime les étiquettes à la maison avec mon imprimante thermique et 3-4 rouleaux de papier autocollant, on passe par un imprimeur pour les badges, les tours de cou sont commandés à part avec en tête l'idée de réutiliser ceux des années précédentes (on encourage les participants qui ne souhaitent pas garder les tours de cou à nous les rendre, c'est plus économique et plus écologique ; ceux qui souhaitent le garder le peuvent, si ça doit partir à la poubelle on préfère le récupérer). C'est une dépense à laquelle on en peut pas couper : il faut qu'on soit capable d'identifier les participants, qu'on sache qui a mangé (on coche le badge le midi), qu'on s'assure qu'aucun billet n'est utilisé plusieurs fois.

Nos bénévoles et MC portent chacun une marinière, ainsi qu'un béret rouge, côté organisateur nous avons des t-shirts floqués (avec nos noms et le logo NG Baguette Conf sur le cœur ; ces t-shirts ont été faits en 2025) et un béret rouge. Ça nous a coûté environ 100€ (environ 7.5€ / marinière + environ 3€ / bérets). Ça peut paraitre inutile mais c'est important car ça permet de débloquer très facilement deux points : les personnes responsables de l'événement sont clairement identifiables et ça donne du caractère à l'expérience participant.

Nous offrons à chaque speaker et à chaque MC un petit cadeau pour les remercier d'avoir pris de leur temps pour NG Baguette Conf, sans eux l'événement n'existerait pas et c'est important. Nous organisons aussi une soirée la veille où speakers, MCs, bénévoles et organisateurs sont conviés, c'est un moment convivial qui permet qu'on se connaisse tous un peu mieux, qui permet de rendre les échanges du lendemain beaucoup plus fluide, qui permet aussi simplement de créer du lien (2 des speakers étaient déjà speakers l'an dernier, notre MC de 2025 était speaker cette année, un de nos deux MC était speaker l'année dernière). Tout ça nous coûte un peu moins de 400€.

Notre banque nous coûte de l'argent aussi. Nous sommes une association Loi 1901, pour recevoir de l'argent, nous devons posséder un compte bancaire professionnel. Nous passons par une banque en ligne gratuite pour la tenue de compte mais qui se rémunère en prenant une commission sur chaque virement que l'on reçoit. Pour l'édition 2026, ça nous revient à un peu moins de 180€.

Il y a quelques autres petites dépenses plus anecdotiques.

On paie ça comment ?🔗

Si on a pas mal de dépenses, avec un total approchant les 11 000€, nous avons seulement deux sources d'argents : la billetterie et les sponsors.

Pour la billetterie, nous passons par Hello Asso qui nous permet d'avoir une billetterie gratuite, sans commission. Ce n'est pas parfait, mais remplie globalement nos besoins. Le prix des entrées nous permet d'être relativement serein en théorie :

• 30 billets "early" à 69€ : avant l'annonce du programme, à prix plus bas, nous permettant d'avoir de la trésorerie au plus tôt (on ne va pas très loin avec 600€ et autant que possible on essaie d'éviter d'avancer sur nos fonds persos) ;
• 120 billets "standard" à 99€ : le tarif standard pour financer tout le reste ;
• avec une marge de 30 places "late" à 119€ prévues si on épuise tout le reste de la billetterie pour permettre à plus de gens de venir et gérer le fait qu'on sera à un timing très proche de la conférence (ce qui augmente notre effort et nos coûts, car on doit commander plus au dernier moment) ;

À noter qu'on a pas sorti ces prix de notre chapeau. Nous avons regardé le prix des conférences parisiennes (généralistes (comme Devoxx) et spécialisés (React Conf, dotJS, etc.)), et aussi les autres conférences Angular européenne (ngPoland, ngDE, ngRome, etc.). Notre objectif était très clair : être beaucoup moins cher que les autres, rendre la conférence super accessible autant que possible, car on ne fait pas ça pour l'argent ou la gloire, on fait ça pour offrir un moment à la communauté. On ne veut pas être une conférence élitiste, on veut que les gens puissent se poser la question de venir même en fond propre.

Si on compte de manière brute les billets early et standard, on arrive à presque 14 000€. En résumé : si on remplit presque la salle, vous financez entièrement la conférence.

Mais on sait qu'on est jamais sûr de tout vendre, on sait aussi que viser un peu plus c'est toujours mieux, ça donne de la marge, ça donne de la souplesse, ça donne des options pour faire mieux que ce qu'on voulait faire à la base et améliorer l'expérience de tout le monde. Donc il y a aussi la partie sponsoring.

Côté sponsoring, on a ouvert 2 niveaux :

• 8 "standard" à 500€ : globalement du sponsoring dit "virtuel", on vous inclut dans toutes nos communications donc votre marque sera promue largement ;
• 3 "premium" à 1 500€ : même chose que standard mais avec en plus 2 billets participants inclus et un stand sur place pour rencontrer les participants et communiquer directement sur votre activité avec eux ;

Là aussi, on n'y a pas été au doigt mouillé : on sait qu'on est une petite conférence, mais aussi qu'on a un public spécialisé, on a comparé les prix des packs de sponsoring de beaucoup de conférences en France pour se faire un avis sur une sorte de ratio prix par participant et fixer notre tarif et là encore, on sait qu'on est vraiment pas cher. Mais là encore, c'est ce qu'on souhaite, on aimerait avoir des sponsors qui nous suivent au fil des éditions, même si c'est des petites structures.

Donc un potentiel à 8 500€ supplémentaires si on est optimiste.

La réalité🔗

Jusque-là je parle de théorie, d'un monde idéal où tout se passe bien.

Nous avons vendu les 30 premiers billets en 2 jours : soit 2 070€ de trésorerie. Ensuite on a attendu le lancement du programme pour ouvrir les billets standards. Et à l'ouverture, ça n'a pas été aussi facile… 🫠 On a vu les billets se vendre au compte goutte au fil des semaines, parfois une semaine complète sans un seul billet vendu… On a même à partir de fin avril diffusé des codes promos (qui ont été très peu utilisés). On a vendu au final 72 billets standards et 13 billets late. La billetterie atterrie a un peu moins de 10 700€ et 115 billets vendus (presque 25% de moins que ce qu'on budgétisait).

Côté sponsoring, nous sommes arrivés trop tard faces aux budgets marketings qui étaient déjà consommés ou affectés à autre chose (du peu qu'on a pu échanger, le marketing a été fortement orienté vers l'IA depuis 2 ans…). Nous avons été soutenus par quatre entreprises : deux en standard et deux en premium. Ce qui nous a amené 4 000€.

Quand on voit le bilan, on se dit que tout va bien (et oui au final, tout va bien), mais ce n'est pas si simple : à 1 mois de l'événement nous n'avions pas atteint notre point d'équilibre (le moment où notre recette paie l'ensemble de l'événement). Nous commencions déjà à évoquer de combler en fond propre et fermer l'association. Le stress était très fort. Nous avons effacé au maximum les dépenses non absolument nécessaires. Nous avons débattu chaque dépense jusqu'au 2 semaines avant l'événement.

Côté lieu, le prix n'est pas compressible. On a beaucoup échangé avec le traiteur pour fixer au plus tard le nombre de part commandé pour éviter à la fois le gaspillage de nourriture et d'argent. On a aussi commandé au plus tard l'impression des badges pour avoir très peu de marge. On a réservé le lieu de la soirée speaker qu'une semaine avant pour être certain d'avoir le budget, avec en tête de l'annuler si on avait pas le budget.

On a vécu une phase compliquée. On est arrivé à la conférence dans l'idée que ce serait la dernière édition.

À noter aussi que plus haut je disais qu'on prévoyait un espace couvert car "on vise mai et la pluie potentielle qui va avec", cette année on a pas vraiment eu de problème de pluie, on a eu un épisode de chaleur, il faisait 34°C le jour J !

Hors budget mais pas hors sujet🔗

Il y a pas mal de choses qui ne rentrent pas du tout dans ce budget, qui est totalement invisible pour la plupart des gens : l'énergie et l'argent personnels qu'on investit en tant qu'organisateur.

Le premier moment où on a investi en perso cette année c'est je pense la visite du lieu. En effet on a une personne de l'équipe qui vit à Paris, mais ce n'est pas toujours simple de faire concorder les emplois du temps : parce qu'il était plus disponible à ce moment-là, Gerome est allé sur Paris pour faire la visite, sans dépenser l'argent de l'association. C'est une journée allongée, des contraintes en plus, de l'argent personnel mis sur la table.

Je peux sans souci aussi ajouter le travail sur le site internet, sur le dossier sponsoring, sur les démarchages / prises de contacts, la communication sur LinkedIn (vous n'imaginez pas le temps que ça prend de faire une bonne communication sur les réseaux sociaux…).

Pour être présent à la conférence, il fallait qu'on soit tous les quatre sur Paris, Camille vit à Paris, elle a juste posé des congés, mais Gérôme, Yann-Thomas et moi avons pris des congés, pris le train / bus pour nous rendre sur Paris dès le jeudi matin, on a pris un hébergement pour 2 nuits. Tout ça sur nos propres deniers.

Un autre exemple qu'on peut mettre en avant c'est la photo et la captation. Yann-Thomas et moi avons du matériel photo personnel d'assez bonne qualité, on utilise donc notre propre matériel pour faire nous-mêmes les photos pendant l'événement. Faire les photos ça veut aussi dire qu'il faut qu'on fasse nous-même aussi la phase de développement : trier les photos, retoucher ce qui doit l'être, mettre en ligne pour vous permettre de garder des souvenirs de ce moment avec des belles photos. Là encore c'est beaucoup de temps investi pour faire ça car sur la journée nous avons pris à nous deux plus de 900 photos.

Nous avons fait le choix dès la première édition d'enregistrer les talks. Pour la première édition, nous avions plus ou moins improvisé une configuration qui ressemblait à la captation de nos live avec Angular Devs France. Cette année on a décidé de se poser un peu plus et de monter un peu en grade sur la configuration : on a capturé avec un PC en régie via OBS Studio. Pour capturer l'écran des speakers, j'ai pris ma carte de capture HDMI et mon PC. J'ai aussi pris un peu de câble pour re-router le signale vidéo. Yann-Thomas a réussi à emprunter une carte pour capturer la partie audio. J'ai préparé toute la configuration en amont avec pas mal d'essais (pas assez apparemment vu qu'on a pas pu faire exactement ce qu'on voulait 😅), des retouches dans la nuit précédente la conférence comme on a vu que le rendu n'allait pas vis-à-vis de la luminosité du vidéo-projecteur, un peu de montage d'image pour prévoir tous les layouts et transitions, et après la conférence du montage pour pouvoir avoir un résultat acceptable pour Youtube.

On peut aussi sans souci citer nos bénévoles. De notre côté, il a fallu qu'on contacte nos MCs, qu'on échange avec eux sur le rôle et les détails. Il a aussi fallu qu'on fasse pas mal de démarchage pour trouver nos six bénévoles, qu'on documente les rôles, qu'on définisse les plannings, qu'on s'assure de ne rien oublier, qu'on communique avec eux, qu'on fasse des réunions d'informations. De leur côté aussi c'est un investissement : ils ont dû poser leur journée, ils ont donné de leur énergie pour nous aider à ce que la conférence se passe bien, vraiment ils ont tous été super ! Et pourtant ce n'est pas si simple que ça pour nous de déléguer une partie de la responsabilité de l'événement sur lequel on travaille depuis autant de mois 😅

Tout ça c'est des choses qu'on voit moins, c'est un peu caché et je trouve ça dommage. Beaucoup de participant ne réalise pas tout le travail gratuit qu'on fait sous le manteau.

Conclusion🔗

Si on organise une conférence dont le nom est une blague sur l'image frenchy de la baguette, il s'agit bien de la seule conférence Angular francophone, un projet sérieux, avec des speakers/talks de qualités, une vraie ambition derrière, une équipe passionnée.

On a adoré passer la journée avec vous. On a adoré voir nos speakers sur scène partager avec un amphi plein de gens captivés par le moment ! On a adoré vous voir le sourire aux lèvres toute la journée. On a adoré les échanges qu'on a pu avoir et qu'on a pu voir !

Même si ça a été difficile, le bilan de la conférence est positif d'un peu plus de 2 000€. Et je peux d'or et déjà vous annoncer qu'ils seront utilisés pour une troisième édition d'NG Baguette Conf.

Merci à tous ceux qui auront pris le temps de lire l'article jusqu'au bout. Merci à tous ceux qui ont rendu cette aventure possible !

J'en profite pour citer l'article de Julien Wittouck sur l'organisation de Cloud Nord qui m'a donné l'impulsion pour écrire mon propre article. Vraiment merci Julien, pour ton article, mais aussi pour notre échange à la soirée speaker de Devfest Nantes qui m'a pas mal aidé à relativiser plein de chose, et évidemment pour tout le taff que tu fais pour la communauté !

Crédit photo : Anthony PENA & Yann-Thomas Le Moigne pour NG Baguette Conf 2026

CSS vs. JavaScript • Josh W. Comeau🔗

#CSS #Frontend #JavaScript #Performance #UI #Web

Article super intéressant qui explique avec une animation super simple pourquoi on a généralement des animations bien plus fluides avec du CSS que du JavaScript et comment on peut contourner ça.

En résumé, on a généralement quelque chose de plus fluide en CSS, car tout le JS s'exécute dans le main thread et il peut se retrouver bloqué par autre chose donc ça bloque complètement notre animation. Le CSS est exécuté dans son propre thread et n'est donc pas impacté par ça. Mais on peut éventuellement passer par la Web Animations API pour contourner le problème (on va pouvoir se greffer sur le même thread que celui qui gère les animations CSS et ne pas être impacté par la charge du main thread).

Maintenant : il reste important d'utiliser le bon outil pour la bonne tâche, le CSS pour des animations suffit largement la plupart du temps, sera plus stable (aussi bien en termes de comportement que de performance), et on évitera d'augmenter la taille du bundle inutilement. Par contre utiliser du JavaScript quand vous avez des cas complexes de gestion de physique ou autres là ça se défend.

IA🔗

Mythos finds a curl vulnerability | daniel.haxx.se🔗

#Sécurité #CVE #Claude #IA #curl

Le lead de curl (sûrement une des briques logiciels les plus utilisés au monde et à peu près partout autour de nous) explique comment fonctionne l'analyse de sécurité dans curl et surtout le retour qu'ils ont eu d'un audit réalisé par Claude Mythos : 1 CVE Low trouvée.

Conclusion : l'outil est puissant mais pas si dangereux que ce que certains essais de dire. Si vous n'avez aucune expertise et/ou aucun audit sécurité, clairement vous allez voir remonter des bugs en quantité monstrueuse (et galérer à analyser les rapports), si vous avez déjà une bonne stratégie sécurité, vous aurez juste un outil de plus

I’m tired of talking to AI🔗

#IA #LLM

L'auteur pointe quelques cas de son quotidien où il tente de discuter avec des humains mais se retrouve soit face à des gens qui donnent des réponses venant d'un LLM soit directement à un agent IA…

Le futur est là ! Ça ne fait pas plaisir du tout de se dire que ça va devenir de plus en plus courant…

The social contract of writing | jola.dev🔗

#IA #LLM #Blog #Blogging #Société

Deux passages résume très bien l'article (même si je vous encourage à le lire entier) :

Anything written after November 30, 2022 is to some degree affected by the proliferation of LLMs. You can’t get around that, other than by exclusively reading old content.

You took the time to read my writing, I appreciate that. I fulfilled my half of the contract too, I spent much of a day writing this, while watching old movies on the TV. I enjoy writing and I’ve been doing it all my life, although with varying levels of consistency. I’m going to try to make this more of a routine thing now. It feels meaningful. Worth doing.

Je suis 100% d'accord avec l'article : écrire c'est établir un contrat social qui implique qu'on a fait l'effort de structurer sa pensée et pour les gens qui feront l'effort de le lire. Je fais partie des gens qui lisent beaucoup, y compris pour faire de la veille, j'aime ça mais ça me coûte de l'énergie que je pourrais investir ailleurs (tout coûte de l'énergie à part manger (si vous mangez correctement) et dormir). Si je lis du contenu produit par un LLM ça veut dire que la personne a investi moins d'effort à l'écrire que moi à le lire…

Par contre je suis malheureusement d'accord aussi que quoi qu'on en pense, les LLMs ont changés notre manière d'écrire (vocabulaire, tournure de phrase, etc.) et ça on peut difficilement y couper tant c'est implicite (vous ne choisissez pas d'utiliser du vocabulaire que les LLMs utilisent, vous vous êtes imbibée de ce vocabulaire et c'est devenu le vôtre). On peut limiter ça, pas l'annuler complètement.

Sécurité🔗

Hash MD5 - 60% des mots de passe craqués en moins d'une heure - Korben🔗

#Sécurité

Kaspersky annonce que "60% des mots de passe hashés en MD5 peuvent être cassés en moins d'une heure…" donc clairement si vous avez encore du MD5 qui traîne, il faut passer à autre chose…

Ils annoncent aussi "L'étude souligne aussi que 53% des mots de passe du corpus se terminent par des chiffres.". En quoi c'est important ? Les hacks de mots de passes vont tenter en priorité des bruteforces avec des chiffres en fin de mot de passe, donc si vous avez un chiffre en fin de mot de passe vous êtes encore plus sensible…

Jeux-videos🔗

Vaskange World🔗

#Jeux-videos #Navigateur #Web

C'est vraiment trop trop bien !!

Un jeu entièrement dans le navigateur où vous devez explorer le monde en faisant des zooms / dézooms / scroll. C'est beau, ça marche bien, c'est simple à prendre en main ! 🤩

While it is true that Iwata did write a new compression algorithm for Gold/Silver, it did not save any space. In fact, it actually cost space. The reason for the new compression algorithm was to increase the speed of decompression.🔗

#Compression #Optimisation #Jeux-videos #Pokemon

Post super intéressant sur la compression utilisée entre Pokemon Gen 1 (Bleu / Rouge) et Gen 2 (Or / Argent). En effet il y a eu un changement de compression entre les deux générations, et on dit toujours que c'est la nouvelle compression de la Gen 2 a permis d'ajouter la région de Kanto (Gen 1) dans la cartouche de la Gen 2 car ça permettait de gagner de la place, alors qu'en fait non.

L'auteur du post explique qu'en fait on perd de la place (4-5% d'espace consommé en plus pour l'algo utilisé en Gen 2 vs celui utilisé en Gen 1), mais que ce choix est justifié par une meilleure vitesse de décompression (à animation égale, on passerait d'environ 100 frames à environ 40 frames pour le chargement).

On a tendance à oublier qu'il y a beaucoup d'algo de compression / archivage, et que tous n'ont pas le même objectif, tous ne font pas les mêmes compromis, et c'est ça qui permet de répondre à tous les cas d'usages !

Divers🔗

J'ai été augmenté, voilà le plan.🔗

#Métier-de-dev #Dev #Carrière

Je pointe cet article de Siegfried, mais il faut aussi aller lire le précédent (qui est en lien au tout début de l'article) sur son augmentation mais surtout son rapport à sa position dans son organisation, son implication, son évolution et son rôle.

Ça me fait forcément pas mal réfléchir en ce moment (ceux qui travaillent avec moi se doute du pourquoi, pour les autres j'en parlerai au début de l'été). En tout cas c'est intéressant.

Je cite aussi Ludovic Borie (qui a répondu au premier billet de Siegfried) :

Il est marrant ton article sur l’augmentation salariale. En tant que manager je trouve ça rude, surtout quand on parle en pourcentage. Ton 4% est un 15 / 20% d’un SMIC. Donc la somme ne me choque pas. Par contre, on est toujours dans l’équilibre employeur employé, sur 4 éléments :

1. En tant qu’employé, je rends ce service et j’ai envie de faire « ça »
2. En tant qu’employeur, j’ai besoin de ces compétences
3. En tant qu’employé, je souhaite ce salaire pour ça
4. En tant qu’employeur, je suis prêt à payer ça. A partir du moment où l’équilibre 1/2 ou 3/4 est cassé, il y a frustration. C’est l’équilibre à régler,pas la somme

Puis ici :

Tout ça pour dire, je t’encourage plutôt à réfléchir en termes de parcours et de destination (aka je veux atteindre ça), plutôt que de pourcentage. Etre clair avec eux sur la destination et voir si c’est complètement en déphasage avec ce qu’ils pensent ou sont prêts à mettre eux. Et si jamais ils trouvent pas ça déconnant, voir les étapes et le temps que ça prendra pour faire descendre la frustration.

omarchy is not a distro🔗

#ArchLinux #Linux #OS

L'auteur pose des mots sur l'effet que me fait Omarchy mais que j'arrivais pas exprimer (en me disant que sans avoir testé je voulais pas exprimer un avis tranché) : Omarchy c'est beau, ça a l'air efficace, tout ce que vous voulez mais c'est Archlinux (ça pour le coup je maîtrise plutôt bien comme je l'utilise depuis 2009-2010) et les dotfiles de DHH 🤷‍♂️

J'ai rien de personnel contre DHH, mais Omarchy n'est pas une distribution, même pas dérivé de Archlinux : c'est Archlinux. Par contre presque tout dans Omarchy se base sur AUR (Arch User Repository, donc des paquets communautaires pas des vrais paquets officiels), y'a des configs très personnels (genre des raccourcis claviers pour lancer hey.com (la boîte de mail de DHH), un pour lancer Grok, un pour créer un post sur Twitter (oui sur le desktop)) et des scripts surcouche à Archlinux

Au pire : c'est un environnement de bureau (allez, si on plisse les yeux on pourrait y croire, mais oui c'est Hyprland en vrai qui fait quasi tout le boulot là encore).

Bref : j'avais pas envie de tester, encore moins envie 🤷‍♂️

Oui, Facebook et Instagram peuvent lire vos conversations WhatsApp en clair sur iPhone sans vous avertir🔗

#Meta #Whatsapp #Vie-privée #Apple #iOS #macOS #iPhone #Instagram #Facebook

Je cite :

Les chercheurs de Mysk ont identifié que WhatsApp enregistre l'historique des conversations dans un fichier nommé "Axolotl.sqlite". Ce dernier est placé dans un conteneur partagé entre les applications d'un même développeur, désigné sous l'identifiant "group.net.whatsapp.WhatsApp.shared". Il s'agit en fait d'une fonctionnalité native d'iOS et de macOS. Apple autorise en effet les applications d'un même éditeur à partager un espace de stockage commun, lequel est conçu pour faciliter les échanges de données entre elles.

Je serais pas du tout surpris qu'on découvre des choses similaires sur Android et Windows.

Meta s'en fichent de votre vie privée, ce qu'ils veulent c'est vos données. Ok pour vous donner l'impression de chiffrer en chiffrant pour le transfert mais rien de plus 🤷‍♂️

Le cookie est mort alors ils ont cuisinés une nouvelle merde pour vous traquer — @Ced_haurus🔗

#Vie-privée #Opérateur-Télécom #Télécoms #Orange #Internet #Cookie

Je cite le tweet complet pour être sûr que tout le monde puisse le lire :

Le cookie est mort alors ils ont cuisinés une nouvelle merde pour vous traquer 👉

Utiq, c'est un système de tracking qui n'a pas besoin de cookie. Il utilise votre opérateur télécom.

Le site que vous visitez transmet votre IP à Utiq. Utiq la transmet à Orange, SFR ou Bouygues. Votre opérateur crée un identifiant lié à votre numéro de téléphone. Et cet identifiant vous suit sur tous les sites partenaires.

Vider votre cache ne change rien. La navigation privée non plus. C'est cross-plateforme. Votre IP = votre identifiant publicitaire. Formidable.

Derrière Utiq, on trouve Deutsche Telekom, Orange, Telefónica et Vodafone. Les opérateurs qui transportent vos données depuis 20 ans viennent de décider qu'ils allaient aussi les monétiser.

C'est présenté comme une alternative "éthique et européenne" aux GAFAM. 😂

Vous échangez Google contre votre opérateur télécom. Qui connaît votre numéro de téléphone, votre adresse, et tout votre trafic réseau.

Cliquez sur Rejeter.

J'ai évidemment été jeter un coup d'œil à Utiq et en effet c'est bien la daube infâme pour la vie privée qui est décrite…

Crédit photo : Générée via Mistral AI avec le prompt suivant :

Une scène chaleureuse et immersive, inspirée par l’esthétique poétique de Studio Ghibli, représentant un bureau de travail en bois clair et vieilli, baigné d’une lumière dorée et tamisée, comme un après-midi d’automne. Au centre, une silhouette stylisée (style anime Ghibli : traits doux, visage non détaillé, vêtements amples et confortables) est assise en tailleur sur un tapis épais, absorbée par la lecture d’un journal tech futuriste. Le journal est ouvert, ses pages légèrement froissées, avec des titres en en-têtes calligraphiés à la main : "Frontend", "Backend", "IA", "Sécurité", et "Vie privée". Les pages brillent d’un halo bleu pâle, évoquant des lignes de code et des schémas techniques qui s’animent discrètement, comme par magie. Autour d’elle, des piles de magazines et de carnets s’empilent de manière désordonnée mais harmonieuse. Certains sont ouverts, révélant des extraits d’articles, des croquis de frameworks (représentés par des icônes génériques : un crochet pour le frontend, un engrenage pour le backend, un cerveau pour l’IA, un cadenas pour la sécurité, et un masque pour la vie privée), ou des diagrammes de réseaux de neurones dessinés à la main. Un écran transparent et flottant (style holographique, mais avec un cadre en bois sculpté) affiche des flux d’informations en temps réel : des graphiques de données, des alertes de sécurité, et des extraits de code, le tout dans un style doux et organique, comme intégré à la scène. En arrière-plan, une grande fenêtre donne sur un paysage urbain nocturne style Ghibli : des bâtiments aux formes arrondies, des lanternes suspendues, et des néons bleutés qui reflètent des motifs de code binaire sur les murs. Une tasse de thé fumant et un petit robot de bureau (inspiré des créatures de Ghibli, comme un mélange entre un Totoro miniature et un assistant tech) observent la scène avec curiosité. À droite, un panda roux (ton animal préféré) est lové sur un coussin, les yeux mi-clos, comme s’il écoutait attentivement. Il ne doit pas dépasser le tiers de la hauteur de l’image et est positionné en bas à droite, légèrement tourné vers le centre, avec une queue soyeuse enroulée autour de lui. L’ambiance est à la fois cosy, onirique et high-tech : les couleurs sont douces (beiges, bleus pâles, oranges chauds), avec des contrastes subtils pour mettre en valeur les éléments tech. Les détails sont soignés, avec des textures visibles (grain du bois, tissu du tapis, pelage du panda), et une lumière qui crée des jeux d’ombres chaleureuses. Le tout respire la sérénité et l’inspiration, comme un moment suspendu entre la magie et la technologie.

human.json ? Kézako ?🔗

À l'heure de l'IA c'est parfois difficile de dire si on peut croire ou pas le contenu qu'on lit en ligne. L'idée de ce protocole est donc d'identifier, via un graphe de confiance, quel site est rédigé par un humain ou non. On peut rédiger un contenu parfaitement vrai avec de l'IA, on peut aussi s'aider de l'IA pour rédiger proprement du contenu, mais on sait aussi que beaucoup de contenu en ligne venant de l'IA sont à peine relus / vérifié, qu'on retrouve énormément de désinformation venant de l'IA (directement dû à de l'hallucination de LLM ou parce que les utilisateurs ont orientés le LLM pour qu'il dise des trucs faux).

La proposition est plutôt simple :

• quand on est utilisateur, on installe une extension pour Firefox ou Chrome, puis on va se rendre sur un site qu'on sait implémenter le protocole, puis on va l'indiquer comme "trusted", pour indiquer à l'extension qu'on a confiance, que ce site est fait par un humain et donc s'il indique que d'autres sites sont fiables on peut faire confiance ;
• quand on est créateur de contenu en ligne, on peut ajouter une ligne dans son code HTML et un fichier human.json pour indiquer quels autres sites sont fiables ;

Ensuite on peut vivre sa vie normalement en regardant ce que nous dit l'extension.

Côté extensions🔗

Une fois installé (et épinglé à la barre d'outil), on verra une petite bulle de couleur apparaitre :

La bulle peut avoir plusieurs couleurs, je cite directement la documentation (et la page de l'extension qui reprend la même chose) :

The color will vary depending on how many hops are needed to reach them from someone you trust: green for 0-1 hops (you trust them or someone who vouches for them), yellow for 2 hops, orange for 3+ hops.

• 🟢 Green — 0–1 hops (seed site, or directly vouched by a seed)
• 🟡 Yellow — 2 hops
• 🟠 Orange — 3+ hops
• ⚪ Gray — not in your trust graph
• 🔵 Blue (+) — site has human.json but you haven't trusted it yet

Il manque la bulle grise qui indique qu'il n'y a aucun human.json d'indiquer et donc l'extension ne peut pas donner d'information.

J'ai ensuite "Trusted" mon propre site et on voit que je peux maintenant retirer ma confiance :

En ajoutant quelques liens (dont le créateur du protocole human.json Beto Dealmeida avec le domaine https://robida.net/) et en laissant un peu de temps à l'extension pour sauter de site en site pour trouver de human.json, je trouve d'autres sites dans l'onglet "Manage" :

On voit dans cette liste les sites qui ont été "trusted" par https://robida.net et un site "trusted" par https://blog.genma.fr (à qui j'ai parlé de ce protocole il y a quelques jours quand je l'ai rencontré pour la première fois à Devoxx France après plus de 10 ans à suivre son blog !).

Si je vais sur le site de l'ami Siegfried, je vais voir ça :

Si je vais sur le site de Genma, je vois que lui-même fait confiance au site https://www.opensource-experts.com/ et en me rendant sur https://www.opensource-experts.com/ je vois que là la bulle est jaune, car on est à 2 sauts d'une seed (site directement "trusted") :

Côté site🔗

Pour mettre en place le protocole sur son site c'est très facile.

La première étape c'est créé un fichier json (la documentation indique de créer un fichier ̀human.json mais en réalité, on le nomme comme on veut) qui va ressembler à ça :

{
    "version": "0.1.1",
    "url": "https://anthonypena.fr",
    "vouches": [
        { "url": "https://genma.fr", "vouched_at": "2026-04-24" },
        { "url": "https://press.k49.fr.nf", "vouched_at": "2026-04-24" },
        { "url": "https://robida.net", "vouched_at": "2026-04-28" },
        { "url": "https://sieg.fr", "vouched_at": "2026-04-24" }
    ]
}
JSON

La clé version indique la version du protocole qu'on supporte (le système est encore très jeune comme je disais, donc on est encore en phase d'essai), pour permettre à la web extension (ou un autre crawler) de savoir à quoi s'attendre comme contenu, en particulier s'il y a des breaking changes.

La clé url le site sur lequel on va déposer le fichier, pour indiquer que notre site est géré par un humain. Ça peut sembler étonnant mais pas tant que ça : imaginons qu'il n'y ait pas cette clé, et qu'on découvre un human.json sur un site "https://blog-plateform.com/blog-of-john/", quel ensemble de page doit être "trusted" ? "https://blog-plateform.com/blog-of-john/" ça parait logique mais est-ce qu'on peut croire "https://blog-plateform.com/" ? Pas forcément. À l'inverse sur mon propre blog, peu importe la page, je veux indiquer que tout "https://anthonypena.fr" est géré par un humain.

Ensuite on va retrouver une clé vouches (qui est optionnelle, vous n'êtes donc pas obligé d'indiquer des marques de confiance) qui va contenir des marques de confiance. Dans mon exemple, une ligne est une marque de confiance. Pour chaque marque on va indiquer à quelle date on a indiqué notre confiance (j'imagine pour donner un indice de confiance pour un éventuel domaine qui aurait changé de propriétaire ou de site qui aurait changé de fonctionnement).

Ensuite on va indiquer sur nos pages que notre human.json existe et sur quelle URL y accéder :

<!DOCTYPE html>
<html lang="fr">
  <head>
    ...
    <link rel="human-json" href="/human.json" />
    ...
  </head>
  ...
</html>
HTML

Note: il faut que ce fichier soit accessible avec les headers Content-Type: application/json (pour que les crawlers puissent s'assurer qu'ils reçoivent bien un JSON) et Access-Control-Allow-Origin: * (pour ne pas avoir d'erreur de CORS).

Ensuite il suffit d'alimenter le fichier human.json en fonction des gens qu'on connait !

Critique du modèle🔗

Je trouve le modèle plutôt intéressant, mais il n'est pas sans questionnement à date :

• le niveau de saut est un peu sévère : on considère comme moins de confiance un site qui est à 2 sauts, personnellement j'aurais commencé à réduire la confiance au 3ème saut, dans mon exemple, je fais confiance à Genma, donc je peux aussi lui faire confiance pour avoir choisi uniquement des sites de confiance à mon avis ;
• l'extension est pour l'instant uniquement en anglais (même si j'ai ouvert la discussion pour une traduction française) ;
• ça ne fonctionne pas sur les domaines en localhost, ce n'est pas super grave, mais c'est dommage de devoir attendre d'avoir mis en ligne pour tester alors que le site fonctionne en local ;
• il n'y a pas de seed initiale : je comprends pourquoi (c'est un système de confiance, mais on ne peut pas facilement faire confiance à un site parce que l'extension indique qu'on peut le faire par défaut), mais pour moi ça peut être un frein à l'adoption ;
• le protocole est encore très jeune, donc le réseau de confiance est encore tout petit, mais il faut commencer quelque part donc on verra dans le futur si ça se diffuse ou pas ;

Conclusion🔗

Quand bien même le protocole est jeune et génère des questionnements sur le dépôt Codeberg, je pense que c'est une très bonne initiative et j'espère que le graphe de confiance va grossir !

Je vous encourage à mettre en place votre human.json si vous avez votre propre site ! Si on se connait et que vous n'êtes pas dans ma liste, n'hésitez pas à me contacter, c'est que je ne dois pas être abonné à votre flux RSS !

Sources :

• Dépôt Codeberg human.json
• Extension Firefox
• Extension Chrome

Crédit photo : Générée via Mistral AI avec le prompt suivant :

A warm and poetic scene inspired by Studio Ghibli, featuring an ancient parchment map spread on a light wooden table. The map shows a cluster of floating islands (each representing a website) connected by glowing bridges of different colors: green bridges (0-1 trust hops) made of carved wood with maple leaf patterns, yellow bridges (2 hops) made of golden braided ropes, and orange bridges (3+ hops) made of thin, translucent glowing threads.

A wooden sailboat with a maple leaf-patterned sail floats on a blue river with golden reflections, symbolizing a data stream. A phoenix with golden and red feathers, wearing round glasses, stands at the helm, holding an ancient compass whose needle points toward a central island (the seed/trusted site).

On this central island, a red panda (anthropomorphic, wearing a light blue t-shirt and jeans, with curly hair tied in a low bun, a short dense beard, and black-framed glasses) sits on a rock, observing the map with a steaming cup of tea beside him. Around the panda, 8-10 red, orange, and yellow maple leaves float gently in the air.

In the background, a starry sky with stars subtly forming HTML tag symbols or binary code patterns. The table is surrounded by ancient books (leather-bound, with unreadable titles) and a holographic screen (with a carved wooden frame) displaying an interactive map of the islands, with faint animated lines of code.

An axolotl (anthropomorphic, wearing a loose sweater) on a nearby island is fishing with a bamboo fishing rod. A stylized cat (anthropomorphic, in loose clothing) sits on a bridge, reading a futuristic journal (a mix of paper and touchscreen).

The scene is bathed in a soft, warm golden light (like a cozy autumn afternoon), with reflections on the wood and parchment. The dominant colors are beiges, pale blues, warm oranges, golds, and touches of moss green. The bridges emit a soft, pulsing glow, as if alive. The panda’s tea cup releases steam that briefly forms binary code patterns before dissolving into the air.

The red panda is positioned in the bottom right corner, occupying about 1/3 of the height, slightly turned in a 3/4 back view. The map and boat are centered, with a depth of field guiding the eye toward the central island. The maple leaves are scattered around the panda, some resting on the table, others floating near him.

The art style is soft, with detailed textures: grained wood, slightly worn fabric, natural folds in the parchment, and frothy reflections in the river water. The overall atmosphere is peaceful, immersive, and dreamlike, blending technology and nature harmoniously.

NG Baguette Conf 2026🔗

Je continue (avec toute l'équipe) à travailler sur NG Baguette Conf 2026 et je profite de cette revue de presse pour vous dire qu'on a lancé un code promo pour le dernier mois, avec le code "LASTMONTH" vous aurez -15% sur votre billet.

Au passage j'ai travaillé sur le badge que les participants, et je l'ai fait via du HTML/CSS avec les éléments de print qui sont prévues dans HTML/CSS, et comme j'hésite depuis bien 2 ans à faire un article sur le sujet, j'évoque le truc et si certains me font savoir que ça les intéresse j'en parlerai !

feat(core): introduce @Service decorator by crisbeto · Pull Request #68195 · angular/angular · GitHub🔗

#Angular #Frontend #TypeScript

Je cite directement le contenu de la description de la pull request :

These changes introduce the new @Service decorator which is a more ergonomic alternative to @Injectable. The reason we're adding a new decorator is that @Injectable has been around since the beginning of Angular and it has a lot of baggage that adds unnecessary overhead for users that generally want to define a singleton service, available in their entire app. The key differences between @Service and @Injectable are:

1. @Service is providedIn: 'root' by default. You can opt into providing the service yourself by setting autoProvided: false on it.
2. @Service doesn't allow constructor-based injection, only the inject function.
3. @Service doesn't support the complex type signature of @Injectable (useClass, useValue etc.). Instead it supports a single factory function.

Example:

import {Service} from '@angular/core';
import {HttpClient} from '@angular/common/http';
import {AuthService} from './auth';

@Service()
export class PostService {
 private readonly httpClient = inject(HttpClient);
 private readonly authService = inject(AuthService);

 getUserPosts() {
   return this.httpClient.get('/api/posts/' + this.authService.userId);
 }
}
TypeScript

Simplification qui ne va pas changer fondamentalement Angular mais va rendre plus explicite et plus clair pour les nouveaux développeurs Angular tout en donnant plus d'intention. Personnellement j'aime beaucoup ce changement.

En plus ça va obliger les collègues à utiliser inject() 😂

Features everyone should steal from npmx | Andrew Nesbitt🔗

#NPM #Frontend

L'article évoque la stratégie de npmx.dev pour combler les manques de npmjs.com : refaire un frontend qui ne casse aucune URL (sauf le domaine) pour minimiser l'effort de basculer un lien de npmjs.com en npmx.dev avec toutes les features qu'énormément de gens demandent depuis plus de 5 ans mais qui n'ont jamais été implémenté et qui s'entasse dans le backlog depuis le rachat de npm par Github.

Résultat : beaucoup de gens ont migrés au quotidien sur npmx.dev (j'en fais partie) et ça a poussé npmjs.com à commencer à ajouter des choses (le light/dark le mois dernier). Est-ce que ça ira plus loin ? Peut-être. En attendant : on a déjà un super outil, rien n'a changé dans nos habitudes au sens propre

IA🔗

AI agents can now cost more than the humans they were supposed to replace – Startup Fortune🔗

#IA

En résumé : si vous remplacez du travail humain qui était globalement du retravaillé de texte (genre du support client / utilisateur de premier niveau qui va reformuler la doc ou RTFM) c'est hyper efficace financièrement, même si ça peut questionner sur la relation humaine. Par contre pour remplacer un flux de travail complexe, voir assez complexe pour demander un contrôle humain, coûte aussi cher voir plus cher que le faire uniquement par un humain.

Et c'est logique : l'IA (en tout cas en l'état actuel des choses) ne peut pas raisonner, donc ne peut pas remplacer un raisonnement humain, et donc il faut à peu près autant d'humain qu'avant mais en plus payer l'IA. Si le gain en temps est très bon ça peut être intéressant (mais ça se discute pour plein de raison : charge mentale sur les humains en question, humain qui ne voit plus toute la tâche et n'est plus aussi pertinent, augmentation de la fatigue humaine et donc augmentation des erreurs, etc.). Si le gain de temps ne permet pas de dégager plus de business c'est une perte sèche

Dans le même temps : on fait ce constat alors qu'on ne paie pas le vrai prix de l'IA, environ 1/100eme du prix, alors imaginez demain quand il faudra payer le prix fort pour l'IA et que les humains ne sauront plus travailler sans ladite IA à cause de la réorientation de capacité cognitive ? 😇

Sécurité🔗

Bruteforce de cartes bancaires🔗

#Paiement #Sécurité #Carte-bancaire #Banque

Un chercheur en sécurité se rend compte que c'est hyper facile de bruteforce un numéro de carte bancaire (quand on a le ticket de carte où il manque juste une partie des chiffres) en environ une nuit

Comment ça marche sa technique ? Facile ! On tente toutes les combinaisons en tapant les formulaires de paiement de différents sites marchants jusqu'à ce que ça passe. Certains sites marchants vont carrément jusqu'à indiquer que la carte est expirée, qu'il y a une erreur de 3 chiffres ou que c'est juste le CVV qui est faux… Des infos qui aident encore plus le bruteforce…

Et une fois les numéros obtenus, il suffit de passer par un site qui ne demande pas le 3DS et c'est bon on peut vider le compte 🥶 (et pas besoin de chercher loin pour un site sans 3DS, Amazon n'a pas de 3DS la plupart du temps)

En résumé : si quelqu'un a le script et trouve un ticket de carte, en une nuit il peut récupérer le numéro complet et vider votre compte. Et le plus "drôle"? C'est les sites sans 3DS qui auront servi à vider votre compte qui seront considérés comme responsable 😅

Je crois que je vais arrêter complètement de prendre des tickets de cartes moi…

Divers🔗

Git fixup is magic (and Magit is too)🔗

#Git

Add this alias to your .gitconfig:

[alias]
  fixup = "!f() { TARGET=$(git rev-parse $1); git commit --fixup=$TARGET ${@:2} && GIT_SEQUENCE_EDITOR=true git rebase -i --autostash --autosquash $TARGET^; }; f"

Then, use it as follows:

• Make a change.
• Stage files with git add .
• Fix up the desider commit (git fixup ).
• Profit.

Alias sympa pour git qui me fait découvrir qu'on peut faire un commit qui fait directement un fixup d'un autre sans passer par un rebase explicite dans un second temps 😮

Podman avec des Quadlets + GitOps avec Materia🔗

#Docker #GitOps #OS #Git #SystemD #DevOps

Franchement super intéressant ça !

Docker ça veut généralement dire qu'on est en root, avec un daemon qui tourne, et on se coupe de l'OS pour la partie gestion. Mais Docker c'est pas fou pour orchestrer des conteneurs (qui sont des processus comme les autres au fond).

Podman c'est une alternative à Docker. Quadlets vient remplacer Docker Compose mais pas en faisant la même chose : il vient juste donner la petite couche qui manque pour facilement gérer nos services conteneurisés via SystemD (je sais, je sais, beaucoup n'aiment pas, je m'en fiche c'est pas le sujet du jour, et SystemD ça marche quand même bien et globalement partout). Plus besoin de daemon vu que c'est SystemD qui gère tout.

Et du coup on récupère tout le système de timer, d'ordonancement, d'orchestration, de log, etc. de SystemD ! 😮

L'auteur propose aussi de passer par Materia pour faire du GitOps : on décrit dans un repo git nos services, materia se charge de mettre à jour nos définitions de services sur notre serveur !

Je serais vraiment curieux de voir la consommation RAM et CPU !

Oui, votre assureur Axa pourrait bloquer vos remboursements sur ordre de Washington🔗

#Europe #Politique #USA #Tech

Nicolas Guillou, magistrat français à la Cour pénale internationale (CPI), décrit pourquoi il n'a plus de remboursement de sa mutuelle Axa depuis qu'il a été ajouté sur la liste OFAC (qui ne contient globalement que des terroristes ou coupable de crime contre le droit humain) pour avoir signé un mandat d'arrêt contre Benyamin Nétanyahou. Axa n'a aucune contrainte légale à appliquer ici des sanctions liées à la liste OFAC quand Guillou va la pharmacie de son quartier ou chez son médecin, mais dans le doute de représaille américaine, ils choisissent volontairement de ne plus rendre le service pour lequel Guillou paie.

Du fait que les entreprises choisissent majoritairement des boîtes américaines pour héberger services et données entraînent une dépendance aux USA, quand bien même la localisation physique est en Europe. Du fait que des entreprises aient une part non négligeable de leur business aux USA entraînent une dépendance aux USA.

Là où je ne suis pas d'accord : on a le choix de travailler ou pas avec des acteurs américains, et s'il manque une offre sur un service, on a des acteurs en Europe pour la construire avec eux plutôt que payer pour l'amélioration de la version américaine dudit service.

Là on cite Axa mais c'est vrai pour toutes les boîtes qui ont une dépendance avec les USA. Et pour moi toutes ces boîtes sont en risques à cause de ça.

La technologie c'est politique. Le business c'est politique. Tout est politique. Et si on veut garder une certaine latitude de liberté, il faut choisir avec qui on bosse.

L’émergence d’un librofascisme — Denis Szalkowski🔗

#DINUM #Open-source #Open-Source #Souveraineté #France #Linux #KDE #OS

Je ne connais pas l'auteur personnellement mais ça fait une grosse dizaine d'années que je le lis et donc je commence à connaître le personnage public : un en titinet troll, avec des astuces techniques qui viennent de l'expérience, des raisonnements qui tiennent la route mais souvent des conclusions avec lesquels je suis rarement d'accord, accompagné de position assez tranché et qui se basent parfois sur du doigt mouillé. Mais lire des avis divergeant est plutôt saint à mon sens pour questionner sa propre réflexion.

Je cite le premier paragraphe :

J’ai toujours été dans une démarche d’éducation populaire en ce qui concerne Linux et le logiciel libre. Je n’ai jamais eu de chapelle, d’approche identitaire, contrairement à une grande majorité de libristes. Cette vision identitaire, je l’ai ressentie d’abord avec les debianœuds, puis avec des stagiaires ayant jeté leur dévolu sur Gentoo au milieu des années 2000. Debian n’était pas assez compliqué pour eux. Il leur fallait être des hommes, des vrais. En entendant parler de NixOS, là, je suis tombé des nues quand j’ai vu la complexité non feinte du gestionnaire de paquets. J’ai cru revenir 20 ans en arrière, voire plus.

Je ne vais pas mentir, je fais partie des libristes qui défendent une vision "identitaire" du logiciel libre : je crois au libre pas par pragmatisme mais par conviction que c'est par le logiciel libre qu'on rendra les gens maîtres de leur usage, de là à parler d' "identité" je ne sais pas par contre mais passons.

Vous vous en doutez je n'ai pas non plus connu ses stagiaires qui ont préféré Gentoo à Debian début 2000, mais il y a sûrement de bonne raison de choisir Gentoo, et quand bien même c'était pour sa complexité (je maîtrise peu Gentoo mais de mémoire c'est une distribution avec un gestionnaire de paquet qui compile votre système, du Kernel aux outils graphiques) ils ont dû apprendre énormément de chose à l'utiliser.

Parler d'un retour 20 ans en arrière au sujet de NixOS est pour moi une très très grosse blague par contre 🤣 (mais je vous explique plus loin en quoi c'est risible)

Je cite le paragraphe suivant :

Je me suis restreint désormais à deux distributions Linux : Fedora et Debian Testing. Elles disposent toutes deux d’un installeur graphique offrant cette possibilité au plus grand nombre d’utiliser Linux. Une fois installées, leur gestionnaire de paquets s’interface très simplement avec Discover sous KDE. Un vrai bonheur pour l’utilisateur ou pour l’informaticien qui n’a pas envie de se casser la tête sur sa machine personnelle après sa journée de turbin !

Monsieur Szalkowski nous expose qu'il se limite à Fedora (au vu de ses publications et de son discours, on parle de la version de base, pas des variantes CoreOS ou Atomic) et Debian Testing. Et que c'est beaucoup mieux du fait de l'installateur graphique et Que ça demande beaucoup moins d'effort à maintenir le soir après le travail quand on est un particulier.

Ok très bien mais ce n'est pas vraiment la cible de Securix (distribution durçi) et Bureautix (distribution agent) les distributions Linux basés sur NixOS proposés par la DINUM. La première vise à priori les ministères et personnels manipulant des données de niveau secret ou supérieur, la seconde le reste des agents de l'Etat de la secrétaire de mairie aux ministres. Mais à aucun moment il n'est prévu de leur demander d'installer ou administrer leur machine individuellement.

NixOS c'est quoi ? C'est une distribution qui se base que le gestionnaire de paquet nix qui vise à rendre le plus atomique possible et le plus replicable possible les mises à jours et installations de paquet. L'idée (en très grosse maille, y'a beaucoup à en dire) c'est que tout ce qui est installé le sera dans un volume read only, chaque paquet individuellement, puis nix va créer une sorte d'image de votre nouveau système en jouant que des liens et des variables d'environnements avant de basculer sur cette image, la précédente restant en présente sur la machine permettant de revenir sur une version précédente au besoin. Pour garantir la réplicabilité, nix impose de tout déclarer dans des fichiers de configuration plutôt que de multiplier les appels à lignes de commandes.

Pourquoi c'est parfaitement adapté ici ? L'équipe informatique d'un ministère pourra déployer / maintenir / administrer tout le parc sous sa responsabilité simplement en poussant dans un dépôt git la nouvelle version de la configuration NixOS avant de la pousser sur les différents postes automatiquement, nix va garantir l'application de la mise à jour. De plus si une erreur survient un retour arrière est garantie pour ne pas bloquer les agents.

C'est complètement la logique DevOps qu'on retrouve là. Celle qui est née à la suite du raz le bol de toute la filière de gérer en clic-clic ou en configuration individuelle chaque serveur dont on avait besoin. Vouloir gérer tout le parc des machines des agents de l'Etat via une logique as-code et uniforme est purement pragmatique à mon sens : c'est moins coûteux en temps, en effort et en argent.

Troisième paragraphe :

A l’occasion de la publication de mes billets et vidéos sur tout le mal que je pensais du choix de NixOS fait par la DINUM, j’ai à nouveau pu me frotter à des rageux et des haters identitaires. Je les ai bananés des commentaires. De simples commentateurs vautrés dans un anonymat de pacotille qui, souvent, se déclarent contributeurs, incapables de partager par vidéo ou par blog interposés leurs compétences de manière didactique et d’agir dans une démarche d’éducation populaire ! Ce qu’ils recherchent, c’est la complexité. Ils veulent se rendre indispensables, recherchant la technique pour la technique. Leur jeunesse les prive de la mémoire et des raisons de l’émergence de la micro-informatique au milieu des années 80. Ce sont aujourd’hui les mêmes causes qui poussent les entreprises à adopter Azure ou AWS. Les collectivités, les entreprises ne veulent plus d’informaticiens qui se complaisent et se vautrent dans la complexité. Continuez ainsi, chères et chers amis, et vous finirez par perdre votre boulot, tant le discours que vous portez est antinomique avec les besoins des entreprises.

Autant je condamne le harcèlement en ligne et les haters, autant je n'ai pas vu les commentaires, donc je ne me permettrais pas de dire s'il s'agit bien de haters ou d'un Denis qui prend mal qu'on ne soit pas d'accord avec lui avec un discours qui manque de recul 🤷‍♂️ (même si je suis enclain à le croire quand il parle de harcèlement)

En tout cas, je suis en désaccord total avec "Ce qu’ils recherchent, c’est la complexité." (qui fait écho au premier paragraphe et ses stagiaires sous Gentoo comme si les équipes de la DINUM étaient constitués d'étudiants de 20 piges). Comme expliqué juste avant : on est pour moi à un choix qui se justifie techniquement et qui comme le choix de partir vers un cloud comme Azure ou AWS implique une phase de migration coûteuse et un peu complexe (on va pas se mentir : migrer le parc de machine de Windows à NixOS ne va pas se faire d'un claquement de doigts), pour gagner en fiabilité et simplicité dans un second temps. On peut critiquer les choix qui ont été faits, mais je vois un vrai pragmatisme ici. Quand bien même on est face à une distribution avec un installateur en ligne de commande (qu'on ne verra de toutes façons sûrement jamais vu qu'on passera par un outil d'installation automatisé, comme on fait avec les postes Windows sur lesquels on déploie des images de l'OS prêt à l'emploi et pré-configuré).

Je saute le paragraphe 4 qui n'apporte rien de plus qu'une répétition du postulat : le choix du logiciel libre c'est pour l'argent et "Les éléments de langage autour de cette distribution à l’approche qualifiée de déclarative et reproductible, s’apparentant fortement à du nudge, semblent avoir marqué les esprits. […] Jeunes gens, tâchez d’exprimer une pensée autonome." (encore une fois, la DINUM qui n'est composé que d'une armée d'étudiants-stagiaire sans expérience)

Ensuite sur le paragaphe 5 :

Sur Fedora, j’ai pu lire de bien curieux commentaires frisant avec un syllogisme de bas étage. Fedora, c’est Red Hat. Red Hat, c’est IBM. IBM, c’est les États-Unis. Et donc Fedora ne peut pas s’inscrire dans le choix d’une distribution souveraine. Transposons. NixOS est hollandaise. La Hollande fait partie de l’OTAN. L’OTAN est dirigé par les États-Unis. Donc NixOS ne peut pas être une distribution souveraine. Avouez que les deux raisonnements sont tout autant stupides l’un que l’autre. Dois-je encore consommer de la sauce hollandaise si je veux rester souverain dans ma cuisine ? J’y réfléchis très sérieusement. ;+)

Je passe la blague sur la cuisine en fin de paragraphe qui est hors propos (c'est pas mon humour mais chacun son humour c'est pas le sujer et je n'ai pas de critique / réponse ici). Par contre je suis ici d'accord avec Denis : que Fedora soit supportée par une entreprise américaine n'est pas un sujet. C'est une distribution open source, quand bien même on viendrait à être coupé des USA, un fork de Fedora verrait le jour en Europe et il suffirait de migrer. Particulièrement vrai si au lieu de NixOS c'est Fedora Silverblue (ou une autre variante Atomic) de Fedora qui avait été choisie : rpm-ostree et flatpak comme socle au lieu de yum/dnf pour obtenir des garanties d'atomicité et reproductibilité du même genre que NixOS mais avec une approche différente techniquement parlant. Mais à priori les équipes de Fedora aussi possèdent une armée d'étudiant-stagiaire qui cherchent la complexité 🤷‍♂️

Le dernier paragraphe :

Ni les Russes, ni les Chinois, ni les Brésiliens ne se sont embarrassés de savoir si Fedora – la distribution de Monsieur et Madame Torvalds – ou Debian étaient deux représentants du soft power américain, au même titre que pouvaient l’être Maryline Monroe et Elvis Presley. A quel titre, ces populations « indigènes » des contrées lointaines auraient-elles fait le choix de la confidentialité pour se priver du travail de centaines, de milliers d’ingénieurs, d’universitaires et de quelques geeks en sandalettes, en s’agrégeant aux projets… américains ? Sous quels brevets sont fabriqués nos processeurs ? Le choix de NixOS est, selon moi, purement identitaire et donc idéologique. Et je ne vois pas bien ce que l’idéologie a à voir avec le logiciel libre. J’y sens, pour ma part, à tort ou à raison, le relent de l’émergence d’un librofascisme auquel nous devons opposer de toutes nos forces les pratiques d’éducation populaire et de mise à disposition de Linux et des logiciels libres au plus grand nombre.

L'origine de la distribution n'est pas un sujet comme j'ai dit (quoi que, j'aurais peut-être à y redire si ça venait d'une boîte comme Palantir ou de la CIA, ou autre organisme d'espionage / surveillance mais passons), que Fedora soit la distribution préférée de Linus Torvald (le créateur de Linux) non plus. Au passage Linus utilise un vieux fork patché d'une version allégé d'Emacs, donc on devrait peut-être l'immiter aveuglément ? 🤔 (non, Linus dit lui-même qu'il fait ça purement par habitude pas par pragmatisme et de pas faire comme lui)

Je ne vais pas me répéter : arguer l'idéologie ici c'est au mieux de l'ignorance au pire d'une volonté de désinformation ici.

Je ne pensais pas forcément parler de Securix ou Bureautix, en tout cas pas avant de voir émerger le plan de déploiement (perso c'est plutôt ça qui m'intéresse face au choix de la distribution). Ça ne va pas m'empêcher de continuer à lire les billets de monsieur Denis Szalkowski, car j'y vois un intérêt technique. Par contre ça me conforte dans mon idée qu'on serait rarement d'accord au quotidien que ce soit au travail ou en termes de vision, et c'est pas bien grave, on a chacun notre vie, notre vécu et nos convictions, tout ce qu'on se doit c'est du respect à mon avis.

ODF est l’avenir, OOXML le passé - LinuxFr.org🔗

#Microsoft

Je cite un bout sur OOXML :

Le format OOXML, ou Office Open XML, n’a pas été conçu dans un souci d’interopérabilité, mais pour répondre à un objectif très précis : encoder les formats binaires de Microsoft Office en XML de manière à permettre à Microsoft de prétendre respecter la norme sans pour autant renoncer à son emprise sur les utilisateurs par le biais d’un verrouillage technologique.

Cette genèse n’est pas de l’histoire ancienne, mais remonte à la période comprise entre 2006 ‒ par pure coïncidence, l’année où le format ODF a été approuvé par l’ISO ‒ et 2008, année de l’événement grotesque connu sous le nom de « Ballot Resolution Meeting » (réunion de résolution des votes), qui a conduit à l’approbation d’OOXML par l’ISO et qui est consignée dans toutes les versions de la spécification.

OOXML Transitional, la variante que presque tous les documents Microsoft Office utilisent en pratique, et la seule disponible aujourd’hui, est explicitement définie comme une couche de compatibilité avec les anciens formats binaires (les, désormais oubliés, DOC, XLS et PPT, qui n’étaient rien d’autre que l’enregistrement de la mémoire de travail sur le disque), et contient des milliers d’éléments non documentés, d’exceptions spécifiques au format et de références à des systèmes Microsoft hérités qu’aucun tiers ne peut reproduire intégralement.

La spécification elle-même reconnaît que les fichiers Transitional peuvent contenir des éléments dont le comportement est « hérité » et dont l’affichage correct nécessite une connaissance des systèmes propriétaires de Microsoft. En bref, pour implémenter correctement OOXML Transitional, il faut décoder trente ans d’histoire de Microsoft Office, ce que personne, à l’exception de Microsoft, ne peut faire, et que personne ne pourra jamais faire.

En ce sens, choisir OOXML n’est pas un pari mais un choix rétrograde, parce que le format n’est ouvert qu’en apparence ‒ mais il suffit de très peu, d’un peu de bonne volonté, pour se rendre compte qu’il est complètement fermé ‒ et a été conçu pour être un mécanisme de verrouillage.

Je crois que tout est dit ! Je savais que OOXML (docx, xlsx, pptx, etc.) c'était de la camelote, mais je savais pas quel point… Clairement faut arrêter d'utiliser ces machins… Et il me semble que même la suite MS Office peut utiliser les formats ODF donc pourquoi on continue de s'infliger des saletés pareilles ? Certains aiment vraiment tendre le bâton pour se faire battre 😬

Crédit photo : Générée via Mistral AI avec le prompt suivant :

Une scène chaleureuse et immersive, inspirée par l’esthétique poétique de Studio Ghibli, représentant un bureau de travail en bois clair et vieilli, baigné d’une lumière dorée et tamisée, comme un après-midi d’automne. Au centre, une silhouette stylisée (style anime Ghibli : traits doux, visage non détaillé, vêtements amples et confortables) est assise en tailleur sur un tapis épais, absorbée par la lecture d’un journal tech futuriste. Le journal est ouvert, ses pages légèrement froissées, avec des titres en en-tête calligraphiés à la main : "Frontend", "Backend", "IA", "Sécurité", et "Vie privée". Les pages brillent d’un halo bleu pâle, évoquant des lignes de code et des schémas techniques qui s’animent discrètement, comme par magie. Autour d’elle, des piles de magazines et de carnets s’empilent de manière désordonnée mais harmonieuse. Certains sont ouverts, révélant des extraits d’articles, des croquis de frameworks (représentés par des icônes génériques : un crochet pour le frontend, un engrenage pour le backend, un cerveau pour l’IA, un cadenas pour la sécurité, et un masque pour la vie privée), ou des diagrammes de réseaux de neurones dessinés à la main. Un écran transparent et flottant (style holographique, mais avec un cadre en bois sculpté) affiche des flux d’informations en temps réel : des graphiques de données, des alertes de sécurité, et des extraits de code, le tout dans un style doux et organique, comme intégré à la scène. En arrière-plan, une grande fenêtre donne sur un paysage urbain nocturne style Ghibli : des bâtiments aux formes arrondies, des lanternes suspendues, et des néons bleutés qui reflètent des motifs de code binaire sur les murs. Une tasse de thé fumant et un petit robot de bureau (inspiré des créatures de Ghibli, comme un mélange entre un Totoro miniature et un assistant tech) observent la scène avec curiosité. À droite, un panda roux (ton animal préféré) est lové sur un coussin, les yeux mi-clos, comme s’il écoutait attentivement. Il ne doit pas dépasser le tiers de la hauteur de l’image et est positionné en bas à droite, légèrement tourné vers le centre, avec une queue soyeuse enroulée autour de lui. L’ambiance est à la fois cosy, onirique et high-tech : les couleurs sont douces (beiges, bleus pâles, oranges chauds), avec des contrastes subtils pour mettre en valeur les éléments tech. Les détails sont soignés, avec des textures visibles (grain du bois, tissu du tapis, pelage du panda), et une lumière qui crée des jeux d’ombres chaleureuses. Le tout respire la sérénité et l’inspiration, comme un moment suspendu entre la magie et la technologie.

Note : je vais dans cet article dans une direction qui va à l'opposé de ce que la plupart des gens vous diront, mais je sais que je ne suis pas le seul à avoir ce point de vue. Par exemple on retrouve une vidéo de MiCode qui parle aussi du sujet.

VPN ? Kézako ?🔗

On parle partout de VPN avec plein de promesse, mais concrètement c'est quoi ?

Si on reste assez haut niveau : VPN = Virtual Private Network ou Réseau Privé Virtuel. Donc l'idée c'est de simuler le fait d'avoir plusieurs machines dans le même réseau privé (comprendre = comme si vous étiez chez vous / à votre entreprise, avec toutes les machines branchées sur le même routeur), pour garantir un certain niveau de confidentialité.

Et techniquement, ça fonctionne comment ? C'est assez simple en fait : une brique logicielle prend chaque paquet réseau qui devrait sortir de votre machine (par exemple : votre laptop alors que vous êtes dans un hôtel), chiffre ce paquet, l'envoie à une autre machine ailleurs sur Internet (par exemple : votre Freebox qui est chez vous (oui les Freebox fournissent un VPN gratuitement)) et cette machine va ensuite déchiffrer le paquet réseau, l'envoyer elle sur Internet (en changeant ce qu'il faut dans le paquet pour faire comme si c'était cette machine qui voulait envoyer le paquet réseau), puis une fois la réponse reçue, chiffre la réponse pour l'envoyer à votre laptop qui va déchiffrer lui aussi.

Donc en gros : vous masquez votre activité en ligne (en partie en tout cas) à n'importe qui entre vous (dans l'exemple au-dessus : votre laptop) et votre serveur VPN (dans l'exemple au-dessus : votre Freebox), mais à partir de votre serveur VPN vous êtes à nouveau sur Internet.

J'imagine que vous vous dites "Mais NordVPN / CyberGhost VPN / Proton VPN ! C'est pas comme ça que ça marche ! ça change ma géo-localisation et protège ma connexion !". Alors oui mais non. Si on prend NordVPN (pour les autres c'est pareil) : votre laptop va chiffrer les requêtes vers Internet pour les envoyer à un serveur NordVPN, on peut imaginer que vous ayez choisi NordVPN Belgique parce que vous êtes fan de F1 (comment ça j'ai vu trop de pub pour des VPN ?) donc un serveur en Belgique va être choisi, ensuite ce serveur va lire tout ce que vous lui envoyez pour ajuster le contenu avant de l'envoyer sur Internet (sans vraie protection en plus que si vous aviez fait la même chose depuis votre laptop du coup), puis il vous renverra la réponse qu'on lui aura donnée, faisant croire que vous vous connectez depuis la Belgique de facto.

Pouvez-vous faire confiance à votre serveur VPN ?🔗

Ce qu'il faut bien comprendre c'est qu'utiliser un VPN veut dire déléguer sa connexion à une autre machine. Si vous êtes le propriétaire de la machine (au sens = elle est chez vous) vous pouvez à priori lui faire confiance (sauf si vous n'avez aucune confiance en votre FAI (Fournisseur d'Accès Internet)). Si c'est le serveur de votre entreprise, pour votre machine professionnelle à priori c'est plutôt sécurisé (pour du pro en tout cas, ça dépend de beaucoup d'autres paramètres).

Si c'est un serveur commercial, c'est un autre sujet à mon sens : vous n'avez comme garantie que les promesses que l'entreprise vous fait, et donc vous faites confiance à la machine de quelqu'un d'autre pour être plus fiable que votre connexion. Vous faites aussi confiance à l'entreprise de ne pas stocker vos données, vous leur faites confiance sur le fait qu'ils n'ont pas de mécanique pour analyser votre trafic, vous leur faites aussi confiance sur le fait qu'ils font uniquement office de VPN et qu'ils ne font pas plus sur le réseau sans vous le dire.

Le but d'utiliser un VPN c'est d'ajouter un niveau de confidentialité sur votre connexion, donc c'est à vous de voir si la dite couche est plus fiable que votre connexion. Si vous êtes chez vous j'aurais tendance à dire qu'utiliser un VPN pour la sécurité est une erreur. Si vous êtes dans un hôtel ou un fast food avec un grand M jaune, ça peut se discuter car vous serez sur des réseaux publics avec un très faible contrôle sur les utilisateurs connectés, mais à voir.

Est-ce que tout passe par le VPN ?🔗

Imaginons que vous êtes dans un cas où le VPN est bien utile. Il faut s'assurer qu'on fait bien passer l'intégralité de son trafic par le VPN.

Par exemple si vos appels HTTP passent par le VPN mais que vos requêtes DNS (résolution des noms de domaines) passent sur le réseau classique, on peut savoir tous les sites que vous allez consulter. Il arrive aussi que votre configuration fasse qu'en cas de rupture de session VPN, vous arriviez sur un fallback sans VPN et parfois silencieusement…

En fait ça dépend énormément de ce que vous cherchez dans le VPN : si c'est la sécurité des données, la partie DNS n'est pas très importante car ça ne donnera aucune information de données, par contre si vous cherchez l'anonymat / pseudo-anonymat, vous voulez que 100% de votre trafic passe par le VPN.

Et la sécurité sans VPN ça existe ?🔗

Déjà qu'on soit clair : on a disposition énormément de solution de sécurité sans avoir besoin de passer par du VPN.

La première brique pour moi à ne pas oublier c'est le HTTPS, le S étant important. En effet le S de HTTPS indique aujourd'hui qu'on va utiliser du chiffrement TLS pour les échanges. Clairement ce n'est pas parfait, il est toujours possible de faire du Man In The Middle en ciblant quelqu'un, on sait que si on capture un paquet TLS, il est possible de le déchiffrer en cassant la clé avec une grosse infrastructure ou beeeeeaaaaauuuucoup de temps, mais soyons honnêtes : on est pas si intéressant que ça individuellement pour que quelqu'un prenne le temps de faire ça spécialement pour nous.

Si vraiment vous voulez augmenter votre anonymat en ligne, vous pouvez passer par le réseau Tor. Le plus simple c'est d'utiliser Tor Browser, une version de Firefox modifiée pour passer par le réseau Tor au maximum et accéder à Internet en faisant passer sa connexion chiffrée par plusieurs nœuds intermédiaires avant de rejoindre Internet de sorte que l'origine de la requête soit presque intraçable (presque parce qu'il y a des cas où on peut désanonymiser le trafic Tor). C'est gratuit, ça fonctionne bien, vous ne choisissez pas explicitement la localisation du nœud de sortie (donc la localisation qui sera affichée pour le serveur), c'est un choix au hasard parmi les nœuds du réseau, mais ça fonctionne très bien !

Le VPN en entreprise est un anti-pattern à mon avis…🔗

Ça fait 10 ans que je travaille en entreprise. Ça fait 10 ans que je constate la même chose : on sécurise généralement très bien l'entrée du réseau privé de l'entreprise mais une fois qu'on est dans le réseau interne il n'y a presque plus de protection…

On voit parfois du HTTPS en interne mais plus d'authentification "parce qu'on est dans le réseau interne". Parfois même le HTTPS n'est pas là en interne… Parfois on voit du filtrage IP sur les plages d'IP interne pour ouvrir les vannes sans plus de restriction…

Du coup il se passe quoi si quelqu'un infiltre votre réseau interne ? C'est simple : il a le champ libre pour faire ce qu'il veut… Et accéder au réseau interne, ça va de physiquement se brancher sur une prise Ethernet dans les bureaux ou la wifi, à obtenir le mot de passe VPN d'un utilisateur et se connecter à distance.

Mon avis est très clair : Zero Trusted Network / Aucun Réseau de Confiance. Partez du principe que vous ne pouvez avoir confiance en aucun réseau, que chaque connexion doit être sécurisé, contrôlé et traçable, peu importe la source.

Note : il y a même des avantages métiers à fonctionner en tout authentifié si c'est bien fait : vous pouvez savoir qui sont vos utilisateurs / consommateurs et donc créer des communications au besoin.

Conclusion🔗

Ici je ne vais même pas abordé les contraintes légales et/ou contractuels autour de l'utilisation des VPNs (typiquement : en théorie vous n'avez pas le droit d'utiliser un VPN pour vous relocaliser et payer moins cher un service / accéder à un contenu géo-bloqué).

En tout cas je voulais parler du sujet depuis assez longtemps, j'ai posé mon avis, vous n'êtes pas obligé de le partager. Par contre si vous avez un avis différent avec des arguments, je suis complètement ouvert et intéressé pour échanger sur le sujet, et pourquoi pas même mettre à jour cet article !

Sources :

• NordVPN vous ment. (non sponsorisé)

Crédit photo : Générée via Mistral AI avec le prompt suivant :

A cozy wooden desk bathed in soft golden afternoon light, featuring futuristic technical magazines and a holographic screen with a wooden frame displaying animated lines of code. In the bottom right corner, a red panda is curled up on a cushion, gazing at a semi-transparent tunnel extending from the screen outward. The tunnel is a blend of circuit board patterns and tree branches, symbolizing the duality of technology and nature. The scene is filled with 8-10 minimalist red, orange, and yellow maple leaves floating gently around, creating a warm, autumnal atmosphere. The art style is inspired by Studio Ghibli, with soft lines, detailed textures, and a poetic, dreamy ambiance."

C'est quoi une dépendance ?🔗

En général, on répondra "tout ce qui est listé dans le package.json". Et ce n'est pas faux en soi. Mais c'est incomplet en théorie.

Déjà si vous faites du Node, vous avez au strict minimum deux dépendances : Node et npm (ou peut-être yarn ou pnpm, mais au fond vous avez quand même npm sur votre machine quoi qu'il arrive, et je ne vais pas couvrir les spécificités de yarn (que je ne maitrise pas assez) et pnpm (qui est trop intéressant pour juste faire un paragraphe dessus)). Sans ces deux outils, vous ne pouvez pas travailler au sens compiler / exécuter votre application. Donc vous dépendez de ces deux outils. Je ne vais pas rentrer plus dans le détail mais juste : pensez à mettre à jour votre version Node régulièrement, particulièrement avec le changement de cycle de release.

L'autre aspect qui manque c'est la notion de dépendance transitive. On qualifie de dépendance transitive une dépendance d'une de nos dépendances. Prenons un exemple simple : vous avez un projet SolidJS avec Vite, vous installez donc vite-plugin-solid. Vous avez donc dans votre package.json solid-js, vite et vite-plugin-solid qui sont vos dépendances directes, mais vite-plugin-solid dépend de @babel/core, babel-preset-solid, solid-js, solid-refresh, vite et vitefu, et si vous creusez encore vous verrez que babel-preset-solid dépend de @babel/core, babel-plugin-jsx-dom-expressions et solid-js, et on pourrait creuser un peu toutes les dépendances comme ça. Chaque dépendance pouvant dépendre d'une version différente d'une même dépendance (vous pouvez dépendance de solid-js@1.9.12, babel-preset-solid dépendre de solid-js@1.9.11, et babel-preset-solid dépendre de solid-js@1.9.10), ce ne serait pas forcément très stable / recommandé mais c'est possible du point de vue de NPM.

Vous avez donc des dépendances que vous maitrisez et d'autres que vous ne maitrisez pas directement. À priori.

Visualisé vos dépendances🔗

Commençons par notre package.json :

{
  ...
  "dependencies": {
    "solid-js": "^1.9.5"
  },
  "devDependencies": {
    "typescript": "~5.8.3",
    "vite": "^6.3.5",
    "vite-plugin-solid": "^2.11.6"
  }
}
JSON

On voit donc 4 dépendances ici.

Maintenant, installons nos dépendances (npm ci si vous avez un package-lock.json, npm i sinon, j'y reviendrais plus tard).

❯ npm ci # si vous n'avez pas encore de package-lock.json, utilisez npm i ou npm install

added 73 packages in 1m

13 packages are looking for funding
  run `npm fund` for details

Et là NPM nous dit avoir installé 73 packages. On est donc bien loin des 4 qu'on voyait plus haut…

Ensuite on va utiliser npm ls.

npm-deps-override@0.0.0 /home/anthony_p/tmp/npm-deps-override
├── solid-js@1.9.12
├── typescript@5.8.3
├── vite-plugin-solid@2.11.12
└── vite@6.4.2

C'est logique, on retrouve les dépendances de notre package.json. Allons regarder plus en profondeur :

❯ npm ls --depth 1

npm-deps-override@0.0.0 /home/anthony_p/tmp/npm-deps-override
├─┬ solid-js@1.9.12
│ ├── csstype@3.2.3
│ ├── seroval-plugins@1.5.2
│ └── seroval@1.5.2
├── typescript@5.8.3
├─┬ vite-plugin-solid@2.11.12
│ ├── @babel/core@7.29.0
│ ├── UNMET OPTIONAL DEPENDENCY @testing-library/jest-dom@^5.16.6 || ^5.17.0 || ^6.*
│ ├── @types/babel__core@7.20.5
│ ├── babel-preset-solid@1.9.12
│ ├── merge-anything@5.1.7
│ ├── solid-js@1.9.12 deduped
│ ├── solid-refresh@0.6.3
│ ├── vite@6.4.2 deduped
│ └── vitefu@1.1.3
└─┬ vite@6.4.2
  ├── UNMET OPTIONAL DEPENDENCY @types/node@^18.0.0 || ^20.0.0 || >=22.0.0
  ├── esbuild@0.25.12
  ├── fdir@6.5.0
  ├── UNMET OPTIONAL DEPENDENCY fsevents@~2.3.3
  ├── UNMET OPTIONAL DEPENDENCY jiti@>=1.21.0
  ├── UNMET OPTIONAL DEPENDENCY less@*
  ├── UNMET OPTIONAL DEPENDENCY lightningcss@^1.21.0
  ├── picomatch@4.0.4
  ├── postcss@8.5.9
  ├── rollup@4.60.1
  ├── UNMET OPTIONAL DEPENDENCY sass-embedded@*
  ├── UNMET OPTIONAL DEPENDENCY sass@*
  ├── UNMET OPTIONAL DEPENDENCY stylus@*
  ├── UNMET OPTIONAL DEPENDENCY sugarss@*
  ├── UNMET OPTIONAL DEPENDENCY terser@^5.16.0
  ├── tinyglobby@0.2.16
  ├── UNMET OPTIONAL DEPENDENCY tsx@^4.8.1
  └── UNMET OPTIONAL DEPENDENCY yaml@^2.4.2

Le fonctionnement de vite étant d'essayer de s'auto-configurer au maximum, on retrouve beaucoup de dépendances optionnelles. Épurons ces dépendances qui ne sont pas installées pour rendre l'arbre plus lisible

❯ npm ls --depth 1 | grep -v 'UNMET OPTIONAL DEPENDENCY'
npm-deps-override@0.0.0 /home/anthony_p/tmp/npm-deps-override
├─┬ solid-js@1.9.12
│ ├── csstype@3.2.3
│ ├── seroval-plugins@1.5.2
│ └── seroval@1.5.2
├── typescript@5.8.3
├─┬ vite-plugin-solid@2.11.12
│ ├── @babel/core@7.29.0
│ ├── @types/babel__core@7.20.5
│ ├── babel-preset-solid@1.9.12
│ ├── merge-anything@5.1.7
│ ├── solid-js@1.9.12 deduped
│ ├── solid-refresh@0.6.3
│ ├── vite@6.4.2 deduped
│ └── vitefu@1.1.3
└─┬ vite@6.4.2
  ├── esbuild@0.25.12
  ├── fdir@6.5.0
  ├── picomatch@4.0.4
  ├── postcss@8.5.9
  ├── rollup@4.60.1
  ├── tinyglobby@0.2.16

Note : grep permet de filtrer pour ne garder que les lignes qui contiennent un certain motif, mais si on ajoute l'option -v, on garde les lignes qui ne contiennent pas le motif.

Rien qu'en ajoutant un niveau de profondeur on est déjà à 20 dépendances, avec solid-js@1.9.12 et vite@6.4.2 qui taggé comme deduped, c'est à dire identifiées comme déjà résolue et donc n'ont plus besoin d'être résolus (car le package est tiré plus haut dans l'arbre et avec la même version ou une version compatible).

On peut continuer comme ça en augmentant la profondeur affichée. On peut afficher tout l'arbre directement en passant --all. On peut aussi cibler un package précis.

❯ npm ls solid-js                                       
npm-deps-override@0.0.0 /home/anthony_p/tmp/npm-deps-override
├── solid-js@1.9.12
└─┬ vite-plugin-solid@2.11.12
  ├─┬ babel-preset-solid@1.9.12
  │ └── solid-js@1.9.12 deduped
  ├── solid-js@1.9.12 deduped
  └─┬ solid-refresh@0.6.3
    └── solid-js@1.9.12 deduped

Ici on voit où la dépendance solid-js est tirée dans l'arbre, la version attendue, si elle est bien dédupliquée comme on s'y attend (ici c'est le cas).

En choisissant solid-js dans un projet SolidJS, on s'attend à le voir. Si vous demande pour esbuild ?

❯ npm ls esbuild 
npm-deps-override@0.0.0 /home/anthony_p/tmp/npm-deps-override
└─┬ vite@6.4.2
  └── esbuild@0.25.12

Il n'est pas dans notre package.json pourtant il fait bien partie de l'arbre. Une faille sur esbuild peut donc nous impacter. Et certains me diront qu'esbuild sert uniquement à la compilation donc ne part pas en production. Ce n'est pas aussi simple. Déjà esbuild sera installé sur chaque runner de notre CI, donc à défaut d'infecter nos utilisateurs, on peut impacter notre SI via notre CI ce qui n'est déjà pas terrible. Ensuite on peut se retrouver dans un cas où la faille n'est pas dans esbuild mais dans le code qu'il produit, en effet les outils de compilation vont modifier nos sources et peuvent donc injecter du code non sûr et là ça peut retomber chez les utilisateurs.

Comment qu'on dit ce qu'on veut comme version ?🔗

Déjà il faut comprendre ce qu'on appelle le SemVer ou Semantic Versioning.

Pour faire très simple : on va définir une version sur trois nombre X.Y.Z. On va appeler X la version majeure, Y la mineure et Z le patch. L'idée va être de se dire qu'une modification qui vient corriger va juste incrémenter le patch, ensuite une nouvelle fonctionnalité qui ne casse rien pour les utilisateurs actuels incrémente uniquement le mineur, et si on casse quelque chose on incrémente le majeur.

Note : je vous laisse aller voir sur Internet pour tous les détails du SemVer, je n'irai pas plus loin ici. Il reste pas mal de chose à dire : les versions alpha/beta/RC, les versions à quatre nombres, les versionnings alternatifs compatible ou non avec SemVer, etc.

À partir de là, on se dit qu'on veut parfois dire "je veux strictement cette version", parfois "je veux bien prendre un nouveau patch mais pas de changement mineur" et de temps en temps "je veux bien tout mettre à jour sauf la majeure".

Par défaut, si vous faite npm install lodash (pareil si vous faite npm install lodash@latest), NPM va ajouter à votre package.json dans dependencies "lodash": "^4.18.1" (la dernière version sortie à date). Sauf que là vous avez peut-être mis un doigt dans un système que vous ne vouliez pas avec le ^ devant la version. En effet ^4.18.1 veut dire "n'importe quelle version 4.x.x qui est supérieur à 4.18.1". Donc si vous refaite un npm i dans quelques jours/semaines/mois vous aurez peut-être la version 4.18.1, peut-être une 4.18.2 ou peut-être une 4.45.0. Est-ce que vous vouliez prendre en compte tous ces changements simplement en installant vos dépendances ? Pas sûr (même si, je vous l'accorde : avec lodash on peut normalement mettre à jour les yeux fermés).

Si vous voulez "toujours" tirer la version 4.18.1, il faut retirer le ^ et refaire un npm i (pour mettre à jour le package-lock.json) ou simplement faire directement npm install lodash --save-exact qui va ajouter au package.json "lodash": "4.18.1".

Si vous voulez bien les mises à jours, mais seulement de patch, vous pouvez indiquer "~4.18.1".

Sauf que là ça ne concerne que les versions qu'on tire directement via notre package.json. Si je veux forcer la version 0.27.7 d'esbuild je ne peux pas fonctionner comme ça.

En effet si je fais npm i esbuild@0.27.7 --save-exact (la dernière version à date) puis que je regarde l'arbre de dépendance :

❯ npm ls esbuild      
npm-deps-override@0.0.0 /home/anthony_p/tmp/npm-deps-override
├── esbuild@0.27.7
└─┬ vite@6.4.2
  └── esbuild@0.25.12

On voit bien que j'ai version 0.27.7 à la racine de l'arbre, mais sous vite j'ai toujours la version 0.25.12. Donc comment on fait ? Déjà on supprime esbuild qui est inutile à la racine du projet npm uninstall esbuild. Puis on va ajouter une section overrides à notre package.json pour forcer partout dans l'arbre une certaine version d'esbuild :

{
  ...  
  "overrides": {
    "esbuild": "0.27.7"
  }
}
JSON

Là on fait npm install pour mettre à jour nos dépendances et on regarde notre arbre de dépendance :

❯ npm ls esbuild
npm-deps-override@0.0.0 /home/anthony_p/tmp/npm-deps-override
└─┬ vite@6.4.2
  └── esbuild@0.27.7 overridden

Là on voit bien que la version n'est plus la même et c'est indiqué qu'elle est overridden montrant bien que ce n'est pas la version que NPM aurait choisi normalement.

À Noter qu'on peut aller assez loin avec cette mécanique, par exemple :

{
  ...  
  "overrides": {
    "esbuild": "^0.27.0",
    "vite": {
      "esbuild": "^0.27.5"
    }
  }
}
JSON

Permet d'indiquer qu'on veut surcharger la version d'esbuild en autorisant n'importe quelle version compatible avec ^0.27.0 partout dans l'arbre de dépendance sauf dans le sous-arbre de vite où on va viser ~0.26.0 (en l’occurrence, la branche 0.26.x ne contient que la version 0.26.0 donc NPM n'a pas beaucoup de choix de version). Ici ça ne sert pas à grand-chose mais dans certains cas, ça peut être utile. // TODO

❯ npm ls esbuild
npm-deps-override@0.0.0 /home/anthony_p/tmp/npm-deps-override
└─┬ vite@6.4.2
  └── esbuild@0.26.0

Ce n'est pas une erreur de ma part, ici on ne voit plus l'indication overridden alors que la version l'est bien mais passons là-dessus. Par contre on voit bien que notre version est surchargée.

Et si maintenant on ajoute ça ?

{
    ...
    "overrides": {
        ...
        "vite-plugin-solid": {
           "solid-js": "1.9.4"
        }
    }
}
JSON

Normalement au moment de l'installation vous aurez une erreur du type :

❯ npm i         
npm warn ERESOLVE overriding peer dependency
npm warn While resolving: solid-refresh@0.6.3
npm warn Found: solid-js@1.9.12
npm warn node_modules/solid-js
npm warn   solid-js@"^1.9.5" from the root project
npm warn
npm warn Could not resolve dependency:
npm warn peer overridden solid-js@"1.9.4" (was "^1.3") from solid-refresh@0.6.3
npm warn node_modules/solid-refresh
npm warn   solid-refresh@"^0.6.3" from vite-plugin-solid@2.11.12
npm warn   node_modules/vite-plugin-solid
npm warn
npm warn Conflicting peer dependency: solid-js@1.9.4
npm warn node_modules/solid-js
npm warn   peer overridden solid-js@"1.9.4" (was "^1.3") from solid-refresh@0.6.3
npm warn   node_modules/solid-refresh
npm warn     solid-refresh@"^0.6.3" from vite-plugin-solid@2.11.12
npm warn     node_modules/vite-plugin-solid
npm error code ERESOLVE
npm error ERESOLVE could not resolve
npm error
npm error While resolving: vite-plugin-solid@2.11.12
npm error Found: solid-js@1.9.12
npm error node_modules/solid-js
npm error   solid-js@"^1.9.5" from the root project
npm error
npm error Could not resolve dependency:
npm error peer overridden solid-js@"1.9.4" (was "^1.7.2") from vite-plugin-solid@2.11.12
npm error node_modules/vite-plugin-solid
npm error   dev vite-plugin-solid@"^2.11.6" from the root project
npm error
npm error Conflicting peer dependency: solid-js@1.9.4
npm error node_modules/solid-js
npm error   peer overridden solid-js@"1.9.4" (was "^1.7.2") from vite-plugin-solid@2.11.12
npm error   node_modules/vite-plugin-solid
npm error     dev vite-plugin-solid@"^2.11.6" from the root project
npm error
npm error Fix the upstream dependency conflict, or retry
npm error this command with --force or --legacy-peer-deps
npm error to accept an incorrect (and potentially broken) dependency resolution.
npm error
npm error
npm error For a full report see:
npm error /home/anthony_p/.npm/_logs/2026-04-15T05_25_31_667Z-eresolve-report.txt
npm error A complete log of this run can be found in: /home/anthony_p/.npm/_logs/2026-04-15T05_25_31_667Z-debug-0.log

Et là beaucoup vous diront "passe --force et c'est bon" ou "--legacy-peer-deps c'est mieux !". Moi je vous dirais : à moins que vous soyez absolument sûr de vous ou que vous n'ayez pas du tout le choix temporairement : ne le faites pas !

Dans mon exemple j'ai indiqué à NPM que je voulais qu'il tire une version "1.9.4" de solid-js pour vite-plugin-solid ce qui implique qu'on casse le fonctionnement des peer dependancies (dépendance qu'on attend qui soit tirée dans l'arbre mais pas forcément par notre package). Passer --force ou --legacy-peer-deps ne va pas fonctionner ici de part le fonctionnement des peer dependancies (vous aurez la 1.9.12 qui sera prise partout dans l'arbre quand même) mais passer --force ou --legacy-peer-deps va transformer les erreurs en warnings, masquant au passage (car personne ne lit les warnings) des futurs problèmes et donc vous rendant beaucoup plus difficile la montée de version de vos dépendances dans le futur…

Donc si vous arrivez dans le cas où NPM vous propose --force ou --legacy-peer-deps corriger la source du problème, mais n'utilisez pas ces arguments !

npm i, npm ci, npm audit et package-lock.json🔗

Je vois souvent des gens utiliser sans distinction npm i et npm ci. Les deux sont fondamentalement différents dans l'usage :

• npm i va lire votre package.json puis va interroger le registry NPM (par défaut https://npmjs.com/) pour résoudre chaque dépendance (directe et transitive), voir s'il y a une nouvelle version à tirer qui correspond au pattern qu'on a indiqué, puis une opération de dédoublonnement va rentrer en œuvre, pour enfin créer votre dossier node_modules et créer (ou mettre à jour) le package-lock.json qui va être une image de votre dossier node_modules avec tout l'arbre, les checksums pour valider que les packages n'ont pas changé (et donc n'ont pas été infectés depuis la dernière fois où vous les avez téléchargés) ;
• npm ci quant à lui va lire le package-lock.json, vérifier qu'il est bien synchronisé avec le package.json (une section au début du package-lock.json reprend le contenu des dependencies et devDependencies du package.json), puis va télécharger en vérifiant les checksums les versions indiquées dans le package-lock.json, sans plus de traitement, pour créer le dossier node_modules ;

Donc autrement dit : npm i est là pour modifier / mettre à jour vos dépendances, npm ci pour les installer. Si vous utilisez continuellement npm i vous allez continuellement mettre à jour vos dépendances (en plus de largement perdre du temps sur cette étape), alors qu'avec npm ci vous allez installer les mêmes versions que toute l'équipe et que votre CI donc vous êtes certain que vous n'aurez pas d'écart à l'exécution. C'est encore plus important si vous exécutez du Node.js côté serveur, parce qu'avec des npm i vous n'avez aucune garantie que l'exécution se fera avec les mêmes versions de dépendances en production qu'en local.

Et npm audit qu'on voit régulièrement quand on fait des npm i ? C'est une commande qui va inspecter vos dépendances et va vous indiquer si c'est possible de mettre à jour des packages dans l'arbre de dépendance pour corriger des failles de sécurité. npm audit vous donnera les infos, npm audit fix va appliquer tout ce qui est sans risque d'un point de vue SemVer. Dans la plupart des cas, npm audit fix va essentiellement modifier le package-lock.json pour changer une version d'une dépendance transitive, donc vous ne voyez rien côté package.json.

Donc votre package-lock.json de facto n'est pas une simple image de votre package.json qui est généré et jetable sans questionnement. C'est un fichier qui a une vraiment importance en termes de sécurité et de garantie de fonctionnement dans le temps.

Autant que possible, aujourd'hui, évitez de supprimer le package-lock.json.

Note : c'est un peu opaque de prime abord mais si vous utilisez la fonctionnalité d'installation des dépendances via IntelliJ (ou autre IDE de la suite de Jetbrains), il lancera la commande npm install, pas npm ci. J'imagine qu'ils ont fait ça pour éviter d'avoir à tester si le package-lock.json est synchronisé avant de lancer la commande npm ci ou npm i, mais c'est une erreur fondamentale de fonctionner comme ça…

Renovate / Dependabot🔗

Il existe des outils pour vous aider à maintenir vos dépendances à jour sans trop d'effort, particulièrement si vous avez un bon pipeline qui s'exécute sur vos MR et qui valide assez largement votre application !

Quelques astuces :

• Mettez toutes vos versions en mode exacte (ne pas mettre de ~ ou ^ avant la version) ;
• Forcez-vous à mettre de l'auto-merge sur les patchs (normalement c'est censé être gratuit), sauf sur les dépendances internes à votre entreprise (j'ai rarement vu une librairie interne qui suivait entièrement le SemVer et j'ai toujours eu des soucis, donc dans le doute…) ;
• définissez un rôle tournant dans votre équipe de mise à jour des dépendances (essentiellement : regarder si le pipeline passe sur les branches de Renovate / Dependabot et cliquer sur "merge") ;

Note : si on vous bloque pour une quelconque raison l'usage de Renovate / Dependabot, NPM fourni la commande npm outdated qui va vous indiquer toutes les mises à jours que vous pouvez faire. À défaut d'un outil qui travail à votre place, l'exécuter une fois par semaine vous permettra de rester plutôt à jour à moindre effort. Et si un jour vous trouvez npm outdated trop lent, vous pouvez regarder du côté de taze qui est plus rapide et permet de mettre à jour par lot les dépendances dans le package.json.

Astuce : SemVer Calculator🔗

Si vous avez dû mal à identifier quelles versions seront tirées pour un certain pattern, vous pouvez utiliser le npm SemVer Calculator. C'est un outil en ligne fourni par NPM pour visualiser les versions compatibles avec un certain pattern.

Par défaut c'est lodash qui est pointé, mais vous pouvez cibler un autre package, vous pouvez tester n'importe quel pattern de version. C'est vraiment pratique pour valider un pattern très vite, et comprendre comment tout ça fonctionne par la pratique.

Conclusion🔗

Les dépendances avec NPM c'est parfois un peu compliqué. Surtout parce qu'en général on ne prend pas le temps de se projeter sur le comment ça fonctionne vraiment avant d'avoir un problème et se battre avec. C'est souvent un moment où on s'est embourbé avec des mois de --force ou --legacy-peer-deps, où on a tout cassé et là on dit "NPM c'est de la m**de", alors que juste on s'est loupé.

NPM fait partie de ses outils avec des défauts historiques mais qui ont tendances à nous laisser décider pas mal de choses et de facto demande de comprendre un minimum ce qu'on fait pour que ça fonctionne dans le temps.

En tout cas, j'espère que cet article vous aidera à mieux gérer vos dépendances NPM ! 🤓

Sources :

• npm ls
• npm install
• npm ci
• npm audit
• npm outdated
• npm SemVer Calculator

Crédit photo : Générée via Mistral AI avec le prompt suivant :

Un style graphique inspiré de l'anime japonais Studio Ghibli, avec une ambiance chaleureuse, immersive, poétique et onirique. Une bibliothèque futuriste en bois sculpté, avec des escaliers en colimaçon, des échelles mobiles, et des étagères remplies de livres flottants. Chaque livre représente une version de package NPM (ex: lodash@4.18.1, esbuild@0.27.7) avec des titres lumineux et des couvertures colorées. Au centre, un grand hologramme central montre un arbre de dépendances NPM avec npm ls --all, avec des lignes lumineuses reliant les livres entre eux pour symboliser les relations entre les dépendances. En bas à droite, un panda roux anthropomorphe (style Ghibli, vêtements amples) est assis sur un tapis en tissu, un livre ouvert sur ses genoux (titre visible : "SemVer pour les nuls"), avec une tasse de thé fumant à côté. L'arrière-plan est rempli de détails organiques : plantes grimpantes, feuilles d'érable rouges/oranges/jaunes tombant doucement, et une lumière dorée tamisée évoquant un après-midi d'automne. Les couleurs dominantes sont des tons doux de beige, bleu pâle, orange chaud, et des accents de vert et de doré pour les éléments technologiques et naturels. L'image doit être détaillée, immersive, avec des textures riches et une atmosphère à la fois cosy et magique, mêlant technologie et nature de manière harmonieuse.

Announcing npmx: a fast, modern browser for the npm registry🔗

#NPM #Node.JS #Frontend

Annonce officielle de npmx.dev, qui est pour l'instant un frontend alternatif à npmjs.com. Je dis pour l'instant, car l'article parle de frustration autour du CLI npm aussi donc peut-être qu'ils tenteront quelque chose aussi.

Personnellement ça fait quelques semaines que j'utilise npmx.dev en remplacement de npmjs.com au quotidien (sauf pour la partie privée de gestion de package) car :

• même url pour atteindre la description d'un package (https://npmjs.com/package/@anthonypena/fp => https://npmx.dev/package/@anthonypena/fp) donc peu d'effort là-dessus ;
• thème light-dark automatique ;
• Navigation dans le code propre ;
• meilleure vision des versions ;
• meilleure vision des dépendances ;
• je trouve ça plus rapide (aucune métrique, juste un ressenti) ;

Ce n'est évidemment pas parfait (parfois des pages que je dois refresh pour que ça fonctionne, etc) mais ça me facilite la vie, donc je recommande. Surtout que ça n'a aucune incidence sur vos projets !

Absorbing unknown Into the Type Realm🔗

#TypeScript #Frontend

L'intro donne une bonne idée du problème

Every as in your TypeScript is a tiny lie. Sometimes a necessary one, but a lie nonetheless — you're telling the compiler "trust me" about data it can't verify. The question is: when can you avoid it?

La conclusion résume assez bien l'article :

When unknown data arrives at your boundary:

1. Can you validate it? Use zod (or any schema library). This is the best option for JSON from APIs, databases, localStorage, URL params. 2. Can you narrow it? Write a type guard or assertion function. Best for discriminated unions, string literals, set membership, preconditions.
2. Is it a generic boundary? One as in the utility, validation at the call site.
3. Is it structural plumbing? (Proxies, generated code) Inline disable, move on.

The goal isn't zero as — it's zero unexamined as. Every cast should be a conscious decision, not a reflex.

Faut vraiment que j'utilise plus Zod de mon côté ! Et je découvre better-result c'est intéressant !

human.json🔗

#Web #Frontend

L'idée c'est que chaque humain qui publie en ligne peut ajouter un fichier human.json qui a cette forme :

{
  "version": "0.1.1",
  "url": "https://example.com/~alice",
  "vouches": [
    {
      "url": "https://bob.example.com",
      "vouched_at": "2026-01-15"
    },
    {
      "url": "https://example.com/~charlie",
      "vouched_at": "2025-11-02"
    }
  ]
}
JSON

Qui permet d'indiquer qu'on affirme être un humain qui écrit un site et qu'on atteste que d'autres sites sont rédigés par des humains. Si quelqu'un d'autres attestent qu'on est un humain on a donc une chaîne de confiance qui se crée brique par brique.

Pour suivre cette chaîne de confiance :

• on doit indiquer dans nos pages web <link rel="human-json" href="/path/to/human.json"> ;
• on peut utiliser l'extension dédiée pour suivre cette chaîne de confiance avoir une indication dans son navigateur de la confiance ;

J'aime bien l'idée même si c'est purement basé sur la confiance.

Backend🔗

Evolving the Node.js Release Schedule🔗

#NodeJS #Node.JS #Backend

Changement historique et majeure pour l'écosystème Node.js : le cycle de release va radicalement changer pour le mieux !

On passe d'un modèle où 2 versions majeures sortaient chaque année mais une seule considérée comme stable (exemple en 2025 : la 24 sortie en mai était stable, la 25 sortie en octobre ne l'était pas) à un modèle où on aura une seule version chaque année, à date à peu près fixe (avril) et où toutes les versions deviendront stables.

La version 26 est la dernière à suivre l'ancien modèle (sur une LTS donc pour permettre aux utilisateurs de prendre en compte le changement en douceur), la 27 la première version à suivre le nouveau modèle.

Pour la version 27 :

• en octobre 2026, sortie en "Alpha" : phase de test préparation à la release ;
• en avril 2027, sortie de la release en "Current" : la version sort comme les versions actuelles, on peut encore voir des mineurs et patchs mais c'est pour améliorer / corriger en fonction des retours sans casser de fonctionnalité ;
• en octobre 2027, passage en LTS (pour 30 mois) : on s'assure que la version reçoit les patchs de sécurité pour garantir que les utilisateurs en productions sont tranquilles ;

Point utile à noter : les versions seront alignées sur l'année de release, la version 27 en 2027, la version 28 en 2028, etc.

Il va falloir prendre le pli de mettre à jour Node.js chaque année, et tester les versions Current, même Alpha si possible, pour pouvoir remonter les problèmes au plus tôt

IA🔗

How to Kill the Code Review🔗

#IA

Je cite le sous-titre qui résume bien l'idée :

Human-written code died in 2025. Code reviews will die in 2026.

L'article nous explique qu'on tend à tuer la code review, car si on utilise un agent pour coder le produit et un autre agent pour coder les tests du produit tous les deux à partir des specs, on peut ne review que les specs, ce qu'on fait déjà en tant que développeur agentique. Que de toutes façons le volume de code généré entraîne un goulet d'étranglement sur la délivrabilité, du fait qu'en tant qu'humain on est lent à relire du code, que souvent ça incombe aux techs leads et que ça les épuise.

Qu'il faut viser :

The future is ship fast, observe everything, revert faster.

Premier point : l'auteur de l'article est le fondateur d'Aviator, qui se décrit comme "multiplayer AI coding platform". Donc je cite aussi un vieil adage :

Pendant la ruée vers l’or, ce n’est pas les chercheurs d’or qui se sont le plus enrichis, mais les vendeurs de pelles et de pioches…

Ce que nous dit ce monsieur : ne faites plus rien vous-même, utilisez une IA pour coder le produit, une autre IA pour tester le produit, et déployer le tout avec des briques construites avec des IAs. Donc en gros "donnez-moi de l'argent".

Ensuite on nous rabâche qu'avec l'IA on peut aller, plus vite, plus loin, avec une meilleure qualité. Mais du coup : comme on s'assure que toute l'équipe comprend ce qu'elle fait ? La première raison d'être de la code review ce n'est pas de garantir qu'aucun bug n'arrivera, mais de partager la connaissance dans l'équipe sur comment fonctionne le produit et éviter des mauvaises pratiques. Si on enlève la code review, seul le dev qui a défini la fonctionnalité saura comment elle fonctionne (et encore vu le mouvement actuel qui dit qu'on devrait ne même plus regarder le code et faire confiance aux specs…), et personne n'aura regardé s'il a suivi les bonnes pratique sur la définition de ses specs, les conventions, etc. Donc on va avoir plusieurs devs en roue libre qui partent chacun dans leur direction peu importe qu'ils bossent sur un seul produit. Réjouissant futur à mon avis…

OpenAI to nearly double workforce to 8,000 by end-2026, FT reports — reuters.com🔗

#IA #OpenAI #ChatGPT #LLM #Dev

Artificial intelligence start-up OpenAI plans to nearly ​double its workforce to 8,000 ‌from 4,500 by the end of 2026, the Financial Times reported on Saturday, ​citing two people with knowledge of ​the matter.

OpenAI to nearly double workforce to 8,000 by end-2026, FT reports said.

The ChatGPT-maker is ​also ramping up recruitment of specialists focused on "technical ambassadorship," ‌aimed ⁠at helping businesses make better use of its tools, the report added.

Si je résume la position d'OpenAI "vous n'avez plus besoin de dev vu notre IA fait tout mais nous on a toujours besoin de dev vu que notre IA ne fait pas tout."

Sécurité🔗

Proton Mail a aidé le FBI à démasquer un manifestant anonyme affilié au mouvement décentralisé de protestation « Stop Cop City »,🔗

#Communication #Vie-privée #Sécurité

Si on regarde dans le détail, on est obligé d'admettre que quand bien même Proton tente de minimiser les données qu'ils possèdent sur leurs utilisateurs, ils ont aussi des contraintes légales pour certaines données (comme les coordonnées de paiement). Proton garanti la sécurité des communications pas l'anonymat des utilisateurs.

Il faut aussi rappeler que si Proton ne se conformait pas un minimum aux requêtes judiciaires de l'État Suisse, ce serait eux qui seraient sur le banc des accusés et donc leur mission serait remise en cause 😅

Android developer verification: Balancing openness and choice with safety🔗

#Android #Google #Sécurité

Je cite la démarche :

How the advanced flow works for users

• Enable developer mode in system settings: Activating this is simple. This prevents accidental triggers or "one-tap" bypasses often used in high-pressure scams.
• Confirm you aren't being coached: There is a quick check to make sure that no one is talking you into turning off your security. While power users know how to vet apps, scammers often pressure victims into disabling protections.
• Restart your phone and reauthenticate: This cuts off any remote access or active phone calls a scammer might be using to watch what you’re doing.
• Come back after the protective waiting period and verify: There is a one-time, one-day wait and then you can confirm that this is really you who’s making this change with our biometric authentication (fingerprint or face unlock) or device PIN. Scammers rely on manufactured urgency, so this breaks their spell and gives you time to think.
• Install apps: Once you confirm you understand the risks, you’re all set to install apps from unverified developers, with the option of enabling for 7 days or indefinitely. For safety, you’ll still see a warning that the app is from an unverified developer, but you can just tap “Install Anyway.”

Ça peut sembler facile et pas si bloquant mais pensez à un truc simple : j'utilise des apps au quotidien que j'installe via f-droid, certaines pas du tout présentes sur le Play Store, donc le jour où je vais changer de téléphone, je devrais faire la manip au-dessus, attendre 24h, et là je pourrais commencer à utiliser mon téléphone (que j'ai payé, qui m'appartient, dont je suis censé disposer librement sans condition, sans avoir à demander de permission) normalement. Pas pour des limitations techniques, parce que Google aura décidé que c'est mieux pour mon bien.

Franchement tout jusqu'au dernier point, je peux comprendre, ça peut sûrement éviter des arnaques de personnes en illectronisme. Le dernier point est 100% abusif à mon sens.

Divers🔗

A website to destroy all websites.🔗

#Web #Internet

Cet article est une ode à un retour à un Internet plus humain. Les parallèles sont intéressants, et franchement je suis d'accord avec l'auteur, pour retrouver un Internet plus humain, il suffit qu'on lâche les gros acteurs pour revenir à la base : publier nos propres sites, simple, imparfait mais humain.

Article qui vaut la peine d'être lu à mon sens (et je voulais vraiment le lire depuis la revue de presse de l'ami Siegfried de février… ). Sous certains aspects il me fait d'ailleurs penser au discours d'Edward Snowden dans Mémoire Vives, sa découverte d'Internet, tout ce qu'il a appris et tout le temps passé à échanger avec des inconnus (mais pas si inconnu à force d'échange à travers un écran).

Two Years of Emacs Solo: 35 Modules, Zero External Packages, and a Full Refactor🔗

#Emacs

Je suis depuis longtemps aussi attiré que repoussé par Emacs. Je fais un peu de vim au quotidien (surtout via git d'ailleurs). Mais Emacs est pour moi beaucoup plus puissant et permet beaucoup plus de chose.

J'ai toujours pensé que pour avoir un environnement développement proche d'un IDE (ou même d'un éditeur de texte ++ comme VSCode) il fallait empiler des packages à foison, ce qui m'a toujours embêté. Pourquoi ? C'est compliqué à maintenir et c'est lent (là où ce qui m'intéresse dans vim ou Emacs c'est la légèreté, la simplicité et la vitesse)

Ici c'est l'auteur de "emacs-solo", une configuration d'Emacs sans aucune dépendance, super modulaire, sans package à télécharger, juste quelques fichiers lisp à copier. Et franchement ça a l'air de vraiment bien marcher ! Ça donne envie de tester !

WiFi trop faible ? Sortez votre ancien smartphone Android du tiroir et transformez-le en répéteur🔗

#Wifi #Android #Smartphone

J'avoue, j'avais jamais pensé à utiliser un ancien smartphone comme ça 😅

Mais :

• il faut un smartphone pas trop ancien pour supporter d'être à la fois à émettre un réseau wifi et de connecter à un autre (il faut qu'il soit dual band) ;
• s'il est trop peu perf ça va être lent à cause de lui pas à cause de la portée wifi ;
• je pense que ça consomme plus d'électricité qu'un répéteur / routeur wifi (j'ai pas mesuré, donc c'est du pif) ;
• ce sera sûrement moins stable (sur des sessions un peu longues de partage de connexion, je trouve que je perds en stabilité parce que mon téléphone chauffe un peu, et j'ai toujours constaté ça) ;

Mais, ça veut pas dire que ça vaut pas le coup de tenter, même en tant que solution temporaire, surtout si on a un smartphone dans un tiroir qui dort : ça ne vous coûtera pas grand-chose de tester. Et au pire si c'est moins stable. Il sera toujours temps d'investir dans un répéteur wifi plus tard !

Data-Shield - La blocklist qui vire les IPs pourries🔗

#Réseau #Firewall #Open-Source

Hé bien c'est exactement ce que fait Data-Shield IPv4 Blocklist , un projet open source qui maintient une liste d'environ 100 000 adresses IP identifiées comme malveillantes. Le principe est simple… on colle l'URL RAW de la liste dans la config de son firewall (genre dans les alias d'OPNsense ou les External Block Lists de Fortinet) et hop, tout ce beau monde est filtré au niveau périmétrique. La liste (un simple fichier texte avec une IP par ligne) est rafraîchie toutes les 6 heures avec une fenêtre de rétention de 15 jours, du coup les IPs qui ne sont plus actives finissent par sortir automatiquement.

Franchement un super travail de maintenir une liste comme ça ! Il faudrait vraiment que je commence à utiliser une liste comme au niveau firewall 😅

La France rachète à Atos l'entreprise Bull, fleuron trop longtemps en souffrance des supercalculateurs🔗

#France #Bull #Supercalculateur #Atos

L'État français a finalisé ce 31 mars 2026 le rachat de Bull, spécialiste du calcul haute performance et de l'IA, pour une valeur pouvant atteindre 404 millions d'euros. L'acquisition d'une entreprise historique.

Je trouve ça assez faible sachant que l'entreprise a généré "un chiffre d'affaires de 720 millions d'euros en 2025.". Après c'est peut-être une astuce financière pour protéger d'entreprise.

J'y apprends d'autres choses intéressantes au passage :

L'usine d'Angers est la seule en Europe capable de fabriquer des supercalculateurs, ces machines colossales qui traitent des milliards d'opérations par seconde et qui sont devenues indispensables pour entraîner les grands modèles d'intelligence artificielle, simuler des scénarios militaires ou faire avancer la recherche scientifique. Cerise sur le gâteau, elles sont reconnues pour leur sobriété énergétique, un critère de plus en plus décisif à l'heure où faire tourner une IA coûte une énergie considérable.

Une usine de super calculateur à Angers 😮

Crédit photo : Générée via Mistral AI avec le prompt suivant :

Une scène chaleureuse et immersive, inspirée par l’esthétique poétique de Studio Ghibli, représentant un bureau de travail en bois clair et vieilli, baigné d’une lumière dorée et tamisée, comme un après-midi d’automne. Au centre, une silhouette stylisée (style anime Ghibli : traits doux, visage non détaillé, vêtements amples et confortables) est assise en tailleur sur un tapis épais, absorbée par la lecture d’un journal tech futuriste. Le journal est ouvert, ses pages légèrement froissées, avec des titres en en-tête calligraphiés à la main : "Frontend", "Backend", "IA", "Sécurité", et "Vie privée". Les pages brillent d’un halo bleu pâle, évoquant des lignes de code et des schémas techniques qui s’animent discrètement, comme par magie. Autour d’elle, des piles de magazines et de carnets s’empilent de manière désordonnée mais harmonieuse. Certains sont ouverts, révélant des extraits d’articles, des croquis de frameworks (représentés par des icônes génériques : un crochet pour le frontend, un engrenage pour le backend, un cerveau pour l’IA, un cadenas pour la sécurité, et un masque pour la vie privée), ou des diagrammes de réseaux de neurones dessinés à la main. Un écran transparent et flottant (style holographique, mais avec un cadre en bois sculpté) affiche des flux d’informations en temps réel : des graphiques de données, des alertes de sécurité, et des extraits de code, le tout dans un style doux et organique, comme intégré à la scène. En arrière-plan, une grande fenêtre donne sur un paysage urbain nocturne style Ghibli : des bâtiments aux formes arrondies, des lanternes suspendues, et des néons bleutés qui reflètent des motifs de code binaire sur les murs. Une tasse de thé fumant et un petit robot de bureau (inspiré des créatures de Ghibli, comme un mélange entre un Totoro miniature et un assistant tech) observent la scène avec curiosité. À droite, un panda roux (ton animal préféré) est lové sur un coussin, les yeux mi-clos, comme s’il écoutait attentivement. Il ne doit pas dépasser le tiers de la hauteur de l’image et est positionné en bas à droite, légèrement tourné vers le centre, avec une queue soyeuse enroulée autour de lui. L’ambiance est à la fois cosy, onirique et high-tech : les couleurs sont douces (beiges, bleus pâles, oranges chauds), avec des contrastes subtils pour mettre en valeur les éléments tech. Les détails sont soignés, avec des textures visibles (grain du bois, tissu du tapis, pelage du panda), et une lumière qui crée des jeux d’ombres chaleureuses. Le tout respire la sérénité et l’inspiration, comme un moment suspendu entre la magie et la technologie.

Pour plein de raisons j'aime bien et pas trop cette vue. Et j'avais envie d'avoir quelque chose de similaire sur mon blog… Je vous explique !

Tout ce que je vous montre ici est disponible ici :

• Démonstration interactive
• Code source de la démo

Ce que j'aime et aime moins dans la vue contribution de Github🔗

Ce qui fait la popularité de cette vue c'est que ça permet à des gens de montrer qu'ils travaillent plus que tout le monde… J'aime pas trop ça… Ce que ça montre c'est votre activité, en grande partie basé sur votre volume de commit, ce qui ne veut rien dire ni de votre activité réelle, ni de votre apport aux projets, ni rien en fait, juste vous savez faire des git commit -m "truc" --allow-empty…

Par contre j'aime bien ce genre de graphique avec un côté prise de recul car ça permet d'avoir une vue d'ensemble d'une période assez longue (sur ma capture d'écran les 12 derniers mois, mais ça peut être aussi les 12 mois d'une année), sans prendre trop de place et si on sait qu'on ne triche pas sur l'activité qu'on a, de voir quand on a été moins bon, et peut-être prendre du recul là-dessus pour comprendre pourquoi, ensuite au choix faire en sorte de pouvoir être actif plus souvent parce que ça nous manquait à cette période, ou à l'inverse réduire son activité pour être mieux (ça c'est vous qui voyez).

Globalement, j'aime vraiment la vue d'ensemble que ça apporte qui donne une info en un coup d'œil ! Et c'est ça que j'aimerai avoir sur mon blog !

J'aimerai une vue très simple, beaucoup plus minimaliste que ce que fait Github, avec les couleurs du blog, sur chaque page archives (une page archive présente tous les articles d'une année), pour naviguer visuellement dans l'année.

Let's go HTML!🔗

Mon blog est généré statiquement donc je veux une solution purement HTML et CSS. Je passe sur la manière dont je mouline mon modèle interne pour générer le HTML, mais voici le résultat :

<section id="overview">
    <ul aria-hidden="true">
        <li data-previous-year="true" data-date="2025-12-29"></li><!-- Monday -->
        <li data-previous-year="true" data-date="2025-12-30"></li><!-- Tuesday -->
        <li data-previous-year="true" data-date="2025-12-31"></li><!-- Wednesday -->
        <li data-date="2026-01-01"></li><!-- Thursday -->
        <li data-date="2026-01-02"></li><!-- Friday -->
        <li data-date="2026-01-03"></li><!-- Saturday -->
        <li data-date="2026-01-04"></li><!-- Sunday -->
        <li data-date="2026-01-05"></li>
        <li data-date="2026-01-06">
            <a href="#2026/01/06/revue-de-presse-janvier" title="Revue de presse - Janvier 2026"></a>
        </li>
        ...
        <li data-date="2026-03-17" data-today="true"></li>
        <li data-date="2026-03-18"></li>
        ...
    </ul>
</section>
HTML

Note : j'ai ajouté les jours de la semaine sur la première semaine pour aider à comprendre.

Je veux une grille donc j'ai choisi de faire une liste non ordonnée (<ul>) ! What!? 🧐

Ça peut vous surprendre mais oui j'ai choisi de faire une liste et pas un tableau. Pourquoi ? Un tableau c'est beaucoup plus difficile à styliser graphiquement, et ça demande beaucoup plus d'effort à produire en termes de HTML. Si j'avais choisi de le faire sous la forme d'un <table> j'aurai dû penser le positionnement des dates dès la génération du HTML par exemple…

Vous noterez aussi que j'ai mis un aria-hidden="true" sur la liste. En effet j'ai choisi d'exclure cet élément des outils d'accessibilité types lecteurs d'écran. La première raison est que ça n'aurait rien apporté : j'aurais sur ma page une liste de date avec pour chaque s'il y a un article, puis la liste directe des articles… Je dois aussi admettre que je n'avais aucune idée de comment rendre tout ça accessible… Je n'ai pas encore fait le travaille d'auditer l'accessibilité de mon blog avec des outils, je m'en mordrais peut-être les doigts ce jour-là et si c'est le cas j'en reparlerais !

Dans cette liste on peut voir une série de <li> avec chacun un attribut data-date="yyyy-MM-dd", c'est simple mais ça fonctionne et vous allez voir que ça va nous servir plus tard !

On notera que les premiers ont l'attribut data-previous-year="true", car comme le nom de l'attribut l'indique : il s'agit des derniers jours de l'année précédente. Pourquoi ? Parce que je veux mettre les jours en colonne par semaine, et que la première semaine de l'année ne commence pas forcément un lundi (ou un dimanche), et que pourtant les derniers jours de l'année sont considérés comme faisant partie de la semaine 1 de l'année suivante (j'imagine pour n'avoir que des semaines complètes).

La date du jour est indiqué aussi avec un attribut spécifique data-today="true". Vous verrez que ça nous servira plus tard aussi !

Note : vous pouvez noter aussi que tous mes attributs personnalisés (et donc non standards) sont préfixés avec data-, sans ça fonctionne mais ce n'est pas du HTML valide, qui oblige à avoir un préfixe data-, l'intérêt de ça c'est aussi que jamais vous n'aurez de conflit avec une éventuelle évolution de la spécification HTML.

Les dates où j'ai publié un article, dans l'élément <li> on retrouve un lien qui n'a pas de texte (car je n'en ai pas besoin), mais qui a une ancre comme URL et un title. Le title pour commencer indique simplement le nom de l'article, ce qui permet de l'afficher au survol (comportement natif du navigateur). L'ancre c'est moins habituel quand on ne construit pas de site web (par opposition aux logiciels de gestions / web app) : au clic sur un lien ancre, l'URL va changer pour faire apparaitre l'ancre (sans chargement / navigation), et si l'ancre correspond à un élément de la page (comprendre : si l'ancre a la même valeur que l'attribut id d'un élément de la page), le navigateur va scroll jusqu'à cet élément et l'indiquer comme "focus". On s'en servira plus tard là aussi !

Et visuellement ça donne ça :

Ça fait rêver hein ? Non ? 🤡

Note sur le thème🔗

Quitte à faire les choses biens, je vais faire une vue qui fonctionne bien en thème clair et sombre. Et je veux faire les choses proprement, donc je vais utiliser des variables CSS.

Je vous donne les variables de thème que je vais utiliser :

:root {
  /* ATOMS */
  --color--white: #ffffff;
  --color--black: #121212;
  --color--dark-gray: #333333;
  --color--gray: #6c757d;
  --color--light-gray: #e0e0e0;
  --color--blue: #007bff;
  --color--green: #28a745;
  --size--quarter: 0.125rem;
  --size--half: 0.25rem;
  --size--1: 0.5rem;
  --size--2: 1rem;
  --size--3: 1.5rem;
  --size--4: 2rem;
  --size--5: 4rem;

  /* MOLECULES */
  --color--bg: light-dark(var(--color--white), var(--color--black));
  --color--text: light-dark(var(--color--dark-gray), var(--color--light-gray));
  --color--primary: var(--color--blue);
  --color--secondary: var(--color--gray);
  --color--accent: var(--color--green);
  --main-text--max-width: 100ch;
  --reponsive-main-text-max-width: min(
    100dvw,
    min(100vw, var(--main-text--max-width))
  );
}
CSS

Il n'y a pas de magie, c'est le thème de mon blog (avec quelques variables en moins dont je n'aurai pas du tout besoin). Pour plus de détail sur comment tout ça fonctionne, je vous renvoie vers mon article sur le style de mon blog.

J'en profite aussi pour rappeler que pour avoir proprement deux thèmes sur votre site, il suffit d'avoir <meta name="color-scheme" content="light dark"> dans le <head> de votre page.

D'une liste à une grille🔗

L'idée de base c'est d'aligner tous les éléments en colonne, sept par sept jusqu'à les avoir tous mis. De cette façon, la première colonne représente la semaine 1 de l'année, la seconde colonne la semaine 2 et ainsi de suite. Donc on veut une grille qui aura 7 lignes et entre 52 et 54 colonnes. Dans un premier temps : restons sur 53 semaines (le cas le plus courant).

Pour faire ça c'est simple, on va utiliser un display: grid associé à grid-template-columns: repeat(53, var(--overview--border-width)) pour avoir 53 colonnes, grid-template-rows: repeat(7, var(--overview--border-width)) pour avoir 7 lignes et grid-auto-flow: column pour lui dire de remplir colonne par colonne (par défaut, le layout grid remplit ligne à ligne).

#overview {
    --overview--day-width: var(--size--1);

    ul {
        display: grid;
        grid-template-columns: repeat(53, var(--overview--day-width));
        grid-template-rows: repeat(7, var(--overview--day-width));
        grid-auto-flow: column;
    }
}
CSS

Notre vue est tout de suite plus compacte !

Je ne veux pas un point pour chaque jour, je veux des cercles, avec une bordure fine. Donc pour ça j'ajoute un peu de style sur les <li> :

#overview {
    --overview--month-border-color: var(--color--secondary);
    --overview--day-width: var(--size--1);
    --overview--day-border-radius: calc(var(--overview--day-width) / 2);

    ul {
        li {
            border: 1px solid var(--overview--month-border-color);
            border-radius: var(--overview--day-border-radius);
            width: var(--overview--day-width);
            height: var(--overview--day-width);
            padding: 0;
            margin: 0;
        }
    }
}
CSS

C'est un peu mieux, mais il y a toujours les puces des différents <li> et on a aussi le padding-left natif des listes (c'est ça qui permet à la fois de laisser de la place pour les puces et que les listes soient de base un peu indentée par rapport au reste du texte). Corrigeons ça ! Et au passage on va ajouter un peu d'espace entre les cercles pour que ce ne soit plus tout tassé !

#overview {
    --overview--padding: var(--size--half);

    ul {
        list-style-type: none;
        gap: 1px;
        padding: var(--overview--padding);
    }
}
CSS

On a notre grille propre. Il ne reste plus qu'à mettre en avant les éléments :

• masquer les jours de l'année précédente en effaçant la bordure les <li> avec l'attribut data-previous-year ;
• ajouter un fond pour les <li> qui contiennent un élément <a> (pour mettre en évidence les jours avec un article) ;
• ajouter une bordure colorée pour la date du jour (les <li> qui ont l'attribut data-today) ;

Pour faire tout ça on va utiliser des sélecteurs sur attribut (li[data-today] par exemple) et le pseudo-sélecteur :has() (:has(a) par exemple).

Je vais aussi en profiter pour faire en sorte que le lien ancre vers l'article prenne toute la place dans le cercle, ça va permettre de cliquer n'importe où dans le cercle pour accéder à l'ancre.

#overview {
    --overview--today-border-color: var(--color--accent);
    --overview--with-article-color: var(--color--primary);

    ul {
        li {
            &[data-previous-year] {
                border: none;
            }

            &[data-today] {
                border-color: var(--overview--today-border-color);
                border-width: 2px;
            }

            &:has(a) {
                background-color: var(--overview--with-article-color);
                a {
                    display: block;
                    width: 100%;
                    height: 100%;
                }
            }
        }
    }
}
CSS

On peut encore faire mieux !

Et si on colorait différemment la bordure des mois pair ? Sans ajouter quoi que ce soit au HTML évidemment ! On va utiliser un sélecteur d'attribut qui se base sur sa valeur : li[data-date*="-02-"] signifie "tous les <li> qui ont l'attribut data-date avec une valeur contenant (*=) la chaîne de caractère -02-", autrement dit pour nous "tous les <li> de février. Et donc il suffit de faire pareil pour les autres mois.

On va aussi utiliser une fonctionnalité récente de CSS : les couleurs relatives. L'idée c'est de pouvoir prendre la valeur d'une couleur et changer juste une partie des valeurs, dans mon cas je vais prendre la couleur --overview--month-border-color et réduire de 30% son opacité en passant le canal alpha à 0.7, ça permet que la couleur s'adapte au thème automatiquement sans me casser la tête.

Au passage je renomme --overview--month-border-color en --overview--odd-month-border-color pour être plus logique.

#overview {
    --overview--odd-month-border-color: var(--color--secondary);
    --overview--even-month-border-color: rgb(from var(--overview--odd-month-border-color) r g b / 0.7);

    ul {

        li {
            border: 1px solid var(--overview--odd-month-border-color);

            &[data-date*="-02-"], &[data-date*="-04-"],
            &[data-date*="-06-"], &[data-date*="-08-"],
            &[data-date*="-10-"], &[data-date*="-12-"] {
                border-color: var(--overview--even-month-border-color);
            }
        }
    }
}
CSS

Comme on connaît la date du jour, on pourrait aussi rendre moins visible les jours des dates dans le futur. Toujours sans rien ajouter au HTML évidemment. Facile avec le combinateur "frère suivant" (Subsequent-sibling Combinator en anglais) : li[data-today] ~ li va indiquer qu'on veut sélectionner tous les <li> qui suivent un <li data-today>.

#overview {
    ul {
        li[data-today] ~ li {
            opacity: 0.5;
        }
    }
}
CSS

Facile non ?

52 à 54 semaines par an…🔗

Il manque un dernier truc : comment on gère le fait d'avoir entre 52 et 54 semaines ? Et dans quels cas ça arrive ?

Je vous ai mis un article qui détaille tout ça dans les sources mais pour résumé : je suis français, je suis donc dans une zone qui fonctionne en ISO 8601, donc je vais me baser là-dessus (en Amérique du Nord ce serait différent par exemple).

Pour faire un résumé grossier :

• mathématiquement : une année c'est 52 semaines (7 jours x 52 semaines = 364 jours) + 1 à 2 jours (2j si c'est une année bissextile) ;
• mais comme les années ne sont pas sur un nombre de jour divisible par 7, les jours de la première semaine de l'année se décale d'année en année et la dernière semaine de l'année est souvent la même semaine que la première de l'année suivante ;
• la règle est simple : si le 1er janvier tombe entre le lundi et jeudi inclus, les derniers jours de l'année N-1 et les premiers de l'année N sont comptés comme la semaine 1, si le 1er janvier tombe entre le vendredi et le dimanche inclus, ces mêmes jours sont la dernière semaine de l'année N-1 (donc semaine 53) ;
• en cas d'année bissextile où le 1er janvier est un dimanche (dernier jour de la semaine en ISO), alors le 31 décembre sera un lundi (premier jour de la semaine en ISO), on aura donc 54 semaines à afficher ;

Note : je vous laisse regarder plus en détail le site que j'ai mis en source, mais il n'y a qu'en notation américaine qu'on aura une semaine numérotée 54, pas en calendrier ISO.

Bon et du coup, pour nous on fait comment ? On fait des calculs savants pour gérer ça ? 🤔

Plus simple : on se pose pour voir le problème autrement et on laisse CSS se débrouiller. 😇

Le cas 52 semaines à afficher n'arrivera jamais à cause du nombre de jour dans l'année, sur une année de 365 jours, les cas les plus extrêmes ce sera 52 semaines pleines et une journée toute seule soit au début (comme 2026, le 1er janvier est un dimanche, tout seul sur sa semaine) soit à la fin (comme en 2028, où le 1er janvier est un lundi, et le 31 décembre un lundi aussi). 53 semaines sera notre cas par défaut le plus courant.

Et de temps en temps, on aura une 54ème semaine qui va apparaitre. Quand on aura 366 jours dans l'année uniquement, et dans le cas où le premier jour de l'année et le dernier jours de l'année sont seuls sur leur semaine. En d'autres mots : on aura 366 jours affichés + 6 jours de l'année précédente qui sont masqués mais sont là pour l'alignement ; donc on aura 54 semaines si on a 372 <li> dans notre liste <ul>, et ça c'est facile à gérer en CSS !

#overview {
    ul {
        &:has(li:nth-child(372)) {
            grid-template-columns: repeat(54, var(--overview--day-width));
        }
    }
}
CSS

Mettre en avant l'élément sélectionné🔗

Je l'expliquais un peu plus haut : quand on clique sur un de mes liens dans la vue calendrier, on va créer une ancre dans l'URL :

Eh bien en CSS l'élément qui possède l'id de même valeur pourra être sélectionné avec le pseudo-sélecteur :target.

Donc je peux faire une mise en avant toute simple avec :

#previous-posts {
    ul {
        li {
            a {
                &:target {
                    color: var(--color--primary)
                }
            }
        }
    }
}
CSS

Conclusion🔗

À la base quand j'ai ajouté ça à mon blog, je ne pensais pas en faire un article : je me suis amusé à ajouter ça, puis j'ai pris un pas de recul en me disant que y'avait des trucs intéressants à montrer et expliquer ! Surtout à l'heure des LLMs qui crachent du Tailwind les yeux fermés à longueur de temps alors qu'on pourrait faire tellement plus simple en CSS… Mais bref !

On aurait pu faire des choses très différentes visuellement, même en se basant sur des mécaniques très similaires côté sélecteurs. Mais là on parle d'une question de goût / choix. J'ai choisi de faire quelque chose de très simple et minimaliste parce que c'est ça que j'avais envie de faire !

À noter que j'ai une particularité sur le blog : je compte mes années de mars à février, donc j'ai décalé mes archives pour caler à ce cycle. Maintenant : ça ne change rien à tout ce que j'ai décrit dans cet article, simplement, ne comparez pas les jours exacts avec mon blog, vous allez vous arracher les cheveux !

Sources :

• Démonstration interactive
• Code source de la démo
• Combien de semaines dans une année : 52 ou 53 selon le calendrier
• CSS Combinators (w3schools)
• Using relative colors (mdn)

Crédit photo : Générée via Mistral AI avec le prompt suivant :

A cozy wooden desk bathed in soft golden light, reminiscent of a late autumn afternoon. The centerpiece is a large wooden calendar, intricately carved with circular reliefs representing each day of the year. Some circles are illuminated in soft blue or green, symbolizing published articles. A red panda, sitting on a cushion in the bottom right corner (occupying less than 1/3 of the height), is gently painting one of the calendar circles with a fine brush. The red panda is slightly turned in a 3/4 back view, surrounded by a subtle halo of light and 8-10 floating maple leaves in shades of red, orange, and yellow. Around the calendar, faint holograms display snippets of CSS/HTML code and dates, blending seamlessly into the scene. The atmosphere is warm, poetic, and dreamlike, inspired by Studio Ghibli's style, with a harmonious mix of organic textures (wood, fabric) and subtle high-tech elements (holograms with wooden frames). The overall mood is immersive, cozy, and magical, evoking a sense of timeless creativity and reflection.

Note : pour cet article j'ai créé un projet Angular en version 21 et j'ai décidé de suivre la nouvelle convention de nommage des fichiers (sans les suffixes .component, .service, etc.), vous êtes évidemment libre de suivre l'ancienne convention.

Tout le code montré ici est disponible dans un projet prêt à lancer ici : https://github.com/kuroidoruido/ng-tabs-sample

Le style🔗

Je ne vais pas m'attarder sur la partie style. Pas que ça n'ait aucun intérêt, mais il y a pléthore d'exemples et finalement ce n'est pas très intéressant à détailler ici à mon sens. Je vais donc faire un style assez minimaliste (et un peu incomplet) mais suffisant pour que ça fonctionne !

Le HTML :

<section class="tab-group">
  <nav class="tab-headers">
    <ul>
      <li class="tab-header"><button data-tab="tab-1">Tab 1</button></li>
      <li class="tab-header active"><button data-tab="tab-2">Tab 2</button></li>
      <li class="tab-header"><button data-tab="tab-3">Tab 3</button></li>
    </ul>
  </nav>
  <section class="tab-content" id="tab-1">
    ...
  </section>
  <section class="tab-content active" id="tab-2">
    ...
  </section>
  <section class="tab-content" id="tab-3">
    ...
  </section>
</section>
HTML

Le style qui va avec :

section.tab-group {
    --color--gray: #ccc;
    --color--gray-dark: #999;

    --border--color: var(--color--gray);
    --border--width: 1px;
    nav.tab-headers {
        ul {
            display: flex;
            list-style: none;
            padding: 0;
            margin: 0;
            border-bottom: var(--border--width) solid var(--border--color);
        }
        .tab-header {
            border: var(--border--width) solid var(--border--color);
            border-radius: 0.5rem 0.5rem 0 0;
            border-bottom-color: white;
            padding: 0;
            margin-bottom: calc(-1 * var(--border--width));
            
            button {
                padding: 0.5rem 1.5rem;
                width: 100%;
                height: 100%;
                background: none;
                border: none;
                cursor: pointer;
            }
            
            &:hover {
                border-color: var(--color--gray-dark);
            }

            &:not(.active) {
                background-color: var(--border--color);
                border-bottom-color: var(--border--color);
                button {
                    color: black;
                }
            }
        }
    }
    
    .tab-content {
        display: none;
        border: var(--border--width) solid var(--border--color);
        border-top: none;
        border-radius: 0 0 0.5rem 0.5rem;
        padding: 0.5rem 1rem;

        & > :first-child {
            margin-top: 0;
            padding-top: 0;
        }
        & > :last-child {
            margin-bottom: 0;
            padding-bottom: 0;
        }

        &.active {
            display: block;
        }
    }
}
CSS

Maintenant on passe à ce qui est intéressant !

Côté utilisation🔗

J'ai fait quelque chose d'assez simple côté DOM, mais je n'ai pas trop ce genre de code sur le tous les jours en mode composant : ça devient vite un énorme monolithe, avec la logique des onglets perdue au milieu de la logique métier, quand on a pas plusieurs occurrences du composant avec de la duplication… Et bonus : dans 2-3 ans, le style va évoluer et il va falloir repasser sur toutes les occurrences du composant pour changer, en prenant en compte les "quelques petites améliorations/corrections" locales à chaque occurrence…

Bref : si je travaille avec un framework, je n'utilise pas directement le HTML, je vais cacher ça dans un composant avec un DSL propre qui s'adapte bien à mon projet (pas forcément tous les projets). C'est aussi vrai pour pas mal de briques du genre.

Voilà ce que je veux écrire :

<app-tab-group default="tab-2">
    <nav app-tab-headers>
        <li app-tab="tab-1">Tab 1</li>
        <li app-tab="tab-2">Tab 2</li>
        <li app-tab="tab-3">Tab 3</li>
    </nav>
    <section app-tab-content="tab-1">
        ...
    </section>
    <section app-tab-content="tab-2">
        ...
    </section>
    <section app-tab-content="tab-3">
        ...
    </section>
</app-tab-group>
HTML

Ce n'est pas si différent que ça de la version HTML pure. Ça va me permettre de ne pas ajouter d'élément dans le DOM en plus de ce qui est requis, car certains styles d'entreprise utilisent des sélecteurs du type .tab-group > .tab-headers (pour cibler le .tab-headers qui est l'enfant direct de .tab-group), donc vous ne pouvez pas intercaler d'éléments.

On reste un peu proche du DOM d'origine avec les <li> et <section> qui sont toujours là, mais on s'est débarrassé de toutes les classes et on va pouvoir gérer facilement un peu tout proprement chacun de son côté !

Construisons les composants🔗

La première étape c'est de construire les différents composants :

• <app-tab-group> : qui sera notre composant parent ;
• [app-tab-headers] : qui va contenir nos titres d'onglet ;
• [app-tab] : qui va gérer chaque titre d'onglet individuellement ;
• [app-tab-content] : qui va gérer le contenu de chaque onglet ;

Les rôles sont bien divisés. Chaque composant a un rôle bien défini et on va pouvoir faire des petits composants !

Personnellement ce genre de brique réutilisable plutôt générique, je les place dans un dossier shared/components (ou quelque chose de similaire en fonction des conventions de l'équipe / du projet), avec un fichier index.ts pour directement pouvoir importer un peu partout nos différentes briques. L'intérêt du index.ts ici c'est qu'on va pouvoir assez facilement refactorer / déplacer nos composants / fichiers sans forcément avoir des changements d'import partout dans l'application (ça évite donc du bruit dans les relectures de code).

// src/app/shared/components/tabs/index.ts
export * from './tab-group'
export * from './tab-headers'
export * from './tab'
export * from './tab-content';
TypeScript

Pour le composant app-tab-group c'est simplement un composant conteneur qui ne fait rien (pour l'instant en tout cas) :

// src/app/shared/components/tabs/tab-group.ts
import { Component, input } from "@angular/core";

@Component({
    selector: "app-tab-group",
    template: `
    <section class="tab-group">
        <ng-content />
    </section>`,
})
export class TabGroup {
    default = input.required<string>();
}
TypeScript

On voit le paramètre default qui est défini mais on ne s'en sert pas pour l'instant.

Les composants app-tab-headers et app-tab sont assez similaires à part que leur sélecteur se base sur un attribut et pas un élément, et qu'on va retrouver l'utilisation de host pour définir des attributs sur l'élément qui va porter l'attribut :

// src/app/shared/components/tabs/tab-headers.ts
import { Component } from "@angular/core";

@Component({
    selector: "[app-tab-headers]",
    host: {
        "[class.tab-headers]": "true",
    },
    template: `
    <nav class="tab-headers">
        <ul>
            <ng-content />
        </ul>
    </nav>`,
})
export class TabHeaders {}
TypeScript

// src/app/shared/components/tabs/tab.ts
import { Component, input } from "@angular/core";

@Component({
    selector: "[app-tab]",
    host: {
        "[class.tab-header]": "true",
        "[attr.data-tab]": "tab()",
    },
    template: `
    <button [attr.data-tab]="tab()">
        <ng-content />
    </button>
    `,
})
export class Tab {
    tab = input.required<string>({ alias: "app-tab" });
}
TypeScript

Note : on aurait pu se passer de l'alias sur l'input tab mais je trouve ça plus simple d'écrire <li app-tab="tab-1">Tab 1</li> que d'écrire <li app-tab tab="tab-1">Tab 1</li>.

On retrouve ensuite app-tab-content qui est assez simple avec rien d'original par rapport aux autres composants :

// src/app/shared/components/tabs/tab-content.ts
import { Component, input } from "@angular/core";

@Component({
    selector: "[app-tab-content]",
    host: {
        "[class.tab-content]": "true",
        "[class.active]": "true",
        "[attr.id]": "tab()",
    },
    template: "<ng-content />",
})
export class TabContent {
    tab = input.required<string>({ alias: "app-tab-content" });
}
TypeScript

En l'état ça ne fonctionne évidemment pas, et on voit à la fois tout le contenu et tous les onglets en version inactive.

Créer un état partagé entre tout le monde🔗

Maintenant on se pose et on réfléchit : on a besoin qu'à chaque clic sur un onglet, on indique aux contenus qu'ils doivent se masquer / s'afficher. Donc il faut que les composants app-tab puissent communiquer avec les composants app-tab-content.

L'option de base serait d'avoir un service global qui gère tous les onglets et tous les groupes d'onglets, garde un identifiant pour chaque, se débrouille pour tout track, et nettoyer quand y'a besoin, etc. Mais non : ça parait simple mais en fait c'est plein de complexités…

On pourrait se dire que quelque chose comme NgRx ou un signal store pourrait être une bonne solution, mais le premier pose une grande partie des mêmes problèmes que le service global, le second n'apportera pas grand-chose de plus…

Alors on fait comment ? On va utiliser un service qu'on provide nous-même avec un scope restreint à notre groupe d'onglet : à la création de <app-tab-group>, on veut une nouvelle instance de notre service, et que cette instance soit partagée uniquement avec les composants enfants. C'est facile, et vraiment : c'est pas compliqué !

Commençons par créer notre service :

// src/app/shared/components/tabs/tab-state.ts
import { computed, Injectable, Signal, signal } from "@angular/core";

@Injectable()
export class TabState {
    private _defaultTab = signal<string | null>(null);
    private _activeTab = signal<string | null>(null);

    public setActiveTab(tabId: string) {
        this._activeTab.set(tabId ?? this._defaultTab());
    }

    public setDefaultTab(tabId: string) {
        this._defaultTab.set(tabId);

        if (this._activeTab() == null) {
            this._activeTab.set(tabId);
        }
    }

    public isActive(tabId: Signal<string>): Signal<boolean> {
        return computed(() => this._activeTab() === tabId());
    }
}
TypeScript

Ici mon service TabState va porter l'état d'un seul groupe d'onglet, donc on a besoin que de deux choses : garder en mémoire l'onglet par défaut et garder en mémoire l'onglet actif. Le reste c'est des méthodes utilitaires pour s'assurer qu'on garde bien encapsulé les signaux.

Vous noterez que contrairement à ce qu'on fait habituellement : je **n'**ai pas mis de { providedIn: 'root' } dans l'annotation @Injectable(). Avoir un { providedIn: 'root' } entrainerait que le service serait global, or ce n'est pas ce qu'on veut, on peut nous-mêmes indiquer le provide.

C'est là que la magie opère :

// src/app/shared/components/tabs/tab-group.ts

@Component({
    ...
    providers: [TabState]
})
export class TabGroup {
    private readonly tabState = inject(TabState);

    default = input.required<string>();

    constructor() {
        effect(() => this.tabState.setDefaultTab(this.default()));
    }
}
TypeScript

Ici on va ajouter notre service comme provider, ce qui va lier une instance du service TabState à chaque instance de TabGroup. Ensuite on peut l'injecter comme n'importe quel autre service. On en profite pour définir notre onglet par défaut via un effect dans le constructor.

Ensuite on peut rendre dynamique nos autres composants :

// src/app/shared/components/tabs/tab.ts
@Component({
    selector: "[app-tab]",
    host: {
        "[class.tab-header]": "true",
        "[class.active]": "isActive()",
        "[attr.data-tab]": "tab()",
    },
    template: `
    <button [attr.data-tab]="tab()" (click)="tabState.setActiveTab(tab())">
        <ng-content />
    </button>
    `,
})
export class Tab {
    protected readonly tabState = inject(TabState);
    
    tab = input.required<string>({ alias: "app-tab" });
    
    protected readonly isActive = this.tabState.isActive(this.tab);
}
TypeScript

// src/app/shared/components/tabs/tab.ts
@Component({
    selector: "[app-tab-content]",
    host: {
        "[class.tab-content]": "true",
        "[class.active]": "isActive()",
        "[attr.id]": "tab()",
    },
    template: "<ng-content />",
})
export class TabContent {
    protected readonly tabState = inject(TabState);
    
    tab = input.required<string>({ alias: "app-tab-content" });
    
    protected readonly isActive = this.tabState.isActive(this.tab);
}
TypeScript

Conclusion🔗

Faire des briques dans ce genre implique souvent la création d'une grosse usine compliqué à cause de la méconnaissance du framework. C'est finalement assez facile d'avoir un état partagé à un groupe de composant (encore plus depuis les standalone component !), assez peu verbeux quand on travaille en Single File Component et avec des signaux comme je l'ai fait.

Si finalement le code n'est pas très compliqué, je trouve que c'est le genre de mécanique qui peut se transposer facilement à des briques plus complexes !

Sources :

• Projet démo

Crédit photo : Générée via Mistral AI avec le prompt suivant :

Studio Ghibli-inspired magical workshop: a wooden desk with old grimoires and floating holographic screens showing a modern Angular Tabs component with "Sortilèges", "Ingrédients", and "Recettes" tabs. An axolotl in a lab coat watches nearby, surrounded by golden light and maple leaves. Warm, dreamy autumn lighting, soft textures, 8K, detailed.

Si vous découvrez mon blog ou mes bilans annuels, je les fais en mars, car je suis né fin février, ce qui fait que je fais mes bilans en année "Anthony" (vous pouvez vous dire aussi que c'est en calendrier romain pompilien aussi si vous trouvez ça trop égocentrique). Tout ça pour dire que ça me semble finalement plus logique de faire mon bilan annuel en suivant mes années de vie que début janvier.

Côté mission🔗

Ça fait maintenant plus d'un an que je travaille sur cette mission (commencé en novembre 2024). Je suis bien sur cette mission, l'équipe est bien, le projet est intéressant. Comme partout tout n'est pas parfait, mais j'y trouve un certain équilibre. J'ai aussi depuis quelque temps une position plus transverse : on a dû doubler le nombre de personne pour encaisser le volume de travail en avançant la date de livraison et fini par prendre un peu de hauteur en prenant des sujets plus long court et plus complexe.

Dans un sens j'ai aussi pu évoluer sur l'aspect mentoring et je me questionne sur l'éventualité d'en faire plus (et même hors de cette mission).

Je ne sais pas comment tout ça va évoluer, mais on verra : en tout cas je vois dans la roadmap des sujets que j'ai envie de mener !

Côté SFEIR🔗

J'ai soufflé la semaine dernière ma 7ème bougie. Je me répète, mais j'aurai jamais cru resté aussi longtemps.

Toujours Staff Engineer, j'ai quand même eu un focus plutôt sur des sujets groupes plutôt qu'agence cette année à mon sens. J'ai en effet essentiellement travaillé sur l'outillage des formations et l'expérience formateur.

J'ai encore fait pas mal de chose cette année, même hors de la casquette Staff Engineer, mais je commence à laisser mes casquettes à d'autres pour laisser d'autres grandir à leur tour. On verra de quoi 2026 sera fait !

Côté langage et projets perso🔗

Est-ce que j'ai fait ce qui était prévu ? Non. Est-ce que c'est grave ? Non plus !

J'ai enfin sorti le blog de Ghost ! J'en ai fait une série d'article pour tout expliqué.

J'ai aussi continué à travailler sur Easy Wiremock (qui est un frontend à Wiremock pour pouvoir visualiser différents éléments). J'ai ajouté des petites fonctionnalités qui m'aident au quotidien (qui aident aussi les membres de mon équipe), ça fonctionne bien, donc c'est un succès à mon sens !

Je pensais retravailler mon fork de Canis Dirus (et repousser à Siegfried ces contributions) et finalement je n'ai jamais pris le temps de le faire… J'ai toujours des idées, mais je vais peut-être changer de fonctionnement pour pouvoir aller plus loin (et faire aussi beaucoup plus que "juste" pousser sur Mastodon ma veille en continu). Si ça abouti j'en reparlerai, car je pense que ça pourrait intéresser des gens !

Conférences / Talks🔗

Année encore plutôt calme côté conférences et meetups :

• J'ai rejoué mon talk Adieu RxJS ! Vive les Signals ! Oh wait… en juin à DevQuest à Niort ;
• J'ai joué un talk en interne de Sfeir Nantes sur Comment faire le post LinkedIn parfait ? ;

Par contre j'ai toujours été impliqué à d'autres niveaux :

• J'ai continué à travailler sur Angular Devs France même s'il faut avouer qu'on s'est beaucoup concentré sur NG Baguette Conf 2025 et qu'on est toujours pas mal occupé sur NG Baguette Conf 2026 (dont la billetterie est ouverte en ce moment !) ;
• J'ai continué jusqu'à l'été les apéros du Naoned Computer Club mais je n'ai pas réussi à reprendre après l'été et j'ai finalement annoncé côté association Computer Club que j'arrêtais ;
• J'ai été à nouveau bénévole pour Devfest Nantes ;

Le blog🔗

Bilan de l'année : 41 articles publiés depuis mon dernier bilan (cet article inclus) ! Ceci incluant 12 revues de presses, j'ai donc écrit 29 articles à proprement parler.

C'est 15 de plus que ce que je comptais pour 2024. Clairement une de mes plus grosses années ! Et j'en suis très content !

J'aime toujours écrire, j'aime toujours partager, j'ai envie de partager beaucoup de choses (pas que via mon blog / en mode texte), ça me fait toujours du bien à moi, donc je ne compte pas m'arrêter là !

Je sais que le blog en lui-même m'a demandé pas mal de travail pour la migration, je sais aussi que j'ai encore du chemin à parcourir pour aller au bout du blog tel que je l'imaginais. En tout cas je suis toujours content de voir que des gens me lisent !

N'hésitez pas à me contacter en privé ou m'interpeler si on se croise en personne ou commenter mes publications sur les réseaux sociaux. Je vous répondrais, et ça pourrait créer de la discussion ou des idées d'articles !

Mon BuJo et moi🔗

J'ai encore beaucoup utilisé mon BuJo cette année, et je confirme ce que je disais l'année dernière : les carnets de La Boutique de Margaux sont parfaits ! Donc j'ai à nouveau pris un carnet de cette boutique, et j'ai choisi l'Organisé "Cerise" qui est un carnet rouge, avec un embossage représentant deux cerises.

J'ai pas changé du tout ma formule BuJo minimaliste que j'avais tenté l'année dernière : elle me convient !

J'ai par contre changé de crayon. Je suis passé d'un Kaco Green avec 3 couleurs (noir, rouge et bleue) + 1 porte mine (en gros comme un stylo 4 couleurs mais avec un couleur qui est un porte-mine, pas trouvé de lien) au combo d'un stylo plume Lamy Safari Umbra F (Fine) et d'un critérium Staedtler Mars Micro 775 7mm. Je ne pensais sincèrement pas retourné sur un stylo plume un jour, mais celui-ci m'a tenté et est extrêmement agréable à manipuler et l'écriture est super fluide ! J'en suis très content. Si je ne devais citer qu'un bémol : j'aurai dû choisir la plume EF (Extra-Fine), car je trouve le trait légèrement trop épais à mon goût. Si un jour je dois le changer je tenterai peut-être le Lamy AL-star qui est globalement le même stylo que le Safari est en aluminium (juste un peu peur au côté désagréable du froid de l'aluminium quand on commence à écrire). Mais passons sur mes histoires de stylos ! (quand bien même j'adore la papeterie et je pourrais en parler encore pas mal 😅)

Sinon j'utilise toujours un "BuJo numérique" à base d'Obsidian pour ma mission, et ça correspond toujours à mon besoin !

Côté lecture🔗

J'ai commencé à noter tout ce que je lis (pour l'instant dans une checklist dans mon Trello en attendant mieux). Et je peux vous dire que je lis beaucoup, plus que je pensais ! 😅 Après je me dis que c'est peut-être aussi un effet de mesure : comme je mesure je lis encore plus pour la métrique !

Pour vous donner des chiffres, entre le 1er novembre 2025 et le 28 février 2026 (j'ai décidé de noter à partir de novembre, donc j'arrête ce bloc au 28 février comme le reste), j'ai lu 73 livres. Alors y'a de tout : 2 magazines (Linux Magazine), 2 comics (dont un recueil des 15 premiers tomes de Spawn), 1 recueil de nouvelle, 1 essai économique, 6 romans, 24 bandes dessinées, 35 mangas et 2 manhuas (BD chinoise).

En tout cas je lis ! Et ça me fait du bien ! J'ai aussi commencé à lire des livres qui me paraissent différent de ce que j'ai déjà lu. J'ai aussi commencé à lire de littérature japonaise, même si clairement j'y connais pas grand-chose donc je teste un peu au hasard pour l'instant. J'ai commencé à regarder la littérature asiatique au sens large mais pour l'instant j'ai surtout accroché à des œuvres japonaises 🤷

Quelques recommandations de mon année (pas forcément d'ordre précis) :

• Le recueil de l’angoisse de Maël Sargel : auteur indépendant que j'ai rencontré dans un salon du livre, j'ai vraiment aimé ce recueil quand bien même je ne l'ai pas forcément trouvé angoissant ;
• Sang neuf de Jean-Christophe Chauzy : bande dessiné d'un auteur qui raconte son histoire face à la maladie, c'est parfois un peu cru (moi ça me dérange pas du tout, mais ça peut déranger donc je préviens), mais c'est vraiment touchant ;
• La citadelle des vertiges d'Alain Grousset : roman que j'avais lu adolescent et que j'ai retrouvé par hasard dans une recyclerie, donc je me suis laissé aller à la nostalgie, et je ne regrette pas, c'est un très bon livre qui se lit tout seul, même adolescent, tout en étant une bonne introduction à la science-fiction ;
• La bibliothèque des rêves secrets de Michiko Aoyama : très bon roman japonais, posé et relaxant, qui vous fera suivre des tranches de vie de personne croisant une bibliothécaire un peu particulière ;
• Les milliardaires ne paient pas d'impôts sur le revenu et nous allons y mettre fin de Gabriel Zucman : pour dépasser ce qu'on a peu entendre à droite ou à gauche et se poser sur ce qu'il essaie d'expliquer vraiment ;
• Ikigami de Motorō Mase (10 tomes) : dystopie où un pays proche du Japon aurait adopté après la Seconde Guerre Mondiale la "Loi de prospérité nationale" qui implique de tuer 1 personne sur 1000, âgée de 18 à 24 ans par injection d'une capsule pendant la vaccination obligatoire à 6 ans, c'est la 3ème fois que je lis cette histoire, c'est bien écrit, on voit 20 points de vue différents autour de cette Loi et comment les gens gèrent leurs derniers instants, vraiment un très bon manga ;
• The Walking Dead de Robert Kirkman, Tony Moore et Charlie Adlard : le comics qui donnera par la suite la série TV, je ne suis pas intéressé par les zombies, les comics pas plus que ça non plus, mais la vache cette série est incroyable (et l'histoire est assez différente de la série quand bien même on retrouve énormément de personnes) ;

Conclusion🔗

Encore une année riche, encore une année où j'ai pu faire des choses, mais aussi une année où j'ai appris à fermer des portes. Que ce soit le Naoned Computer Club ou même les événements internes SFEIR, j'ai fait des choix pour me préserver moi, et même si j'ai pu réaliser des choses très sympas : je suis content que ce soit fini !

Pas forcément un laïus à faire dessus mais ça fait un an que j'ai quitté Nantes et que je vis du côté de Cholet. Je continue de m'approprier cette nouvelle vie, à commencer par le jardinage, mais ça fait du bien d'avoir quitté le tumulte de la ville. Le seul truc qui me manque : il n'y a pas de vraie bonne boutique vendant des mangas dans le choletait, j'ai trouvé du mainstream, des rayonnages plus mal rangés les uns que les autres (ou avec des classements sans queue ni tête) mais pas de vrai rayon manga (pour être clair : il manque toujours 70-80% des titres que je suis…). Tant pis, Internet est mon ami pour corriger ce problème, et je ne parle pas d'Amazon, il se trouve qu'Otaku no Dera (la boutique que je fréquentais depuis 2010) vend aussi en livraison !

Sinon une nouvelle passion est rentrée dans ma vie : Magic The Gathering ! (Pas) Merci Myriam ! 😂 Bon en vrai, ça faisait pas mal de temps que j'hésitais à mettre le nez dans un TCG (j'ai joué pendant des années à Yu-Gi-Oh! avant de lâcher l'affaire pour plein de raisons) et je me retrouve pas mal dans Magic, donc à voir dans le temps !

Crédit photo : Générée via Mistral AI avec le prompt suivant

A Ghibli-style illustration featuring a masculine character with a round face, full cheeks, a marked chin, curly hair tied in a low bun, dense short beard, and dark brown eyes slightly squinted, wearing black rectangular glasses and a silver chain necklace. He has a robust build with broad shoulders and wears a light blue t-shirt with two subtle, light-toned koi carp designs on the back. He stands in a 3/4 view on a Venetian bridge, left hand with a watch resting on the railing, gazing thoughtfully at the canal at dusk. The canal is lined with colorful houses, automated gondolas glide on the water, and bioluminescent jellyfish float gently. In the background, a warm, inviting bookstore glows softly. A red panda, curled up on a cushion in the lower right corner, watches the scene. The atmosphere is golden and dreamy, blending magic and subtle technology, with autumn leaves and a serene, reflective mood.

Oat🔗

#Frontend #CSS #JavaScript #Web

Encore une library de composant web super légère qui à l'air plutôt complète !

Semantic, minimal, zero dependencies. ~8KB CSS and JS.

Indépendant de tout framework, vous pouvez l'utiliser partout dans vos frontend !

Optimiser les perfs et la sécurité d'un site Hugo - Julien Wittouck🔗

#Web #Frontend

Un REX sur quelques techniques pour optimiser le chargement / la sécurité d'un site web

Pas surprise :

• utilisation de Lighthouse ;
• changement de format d'image pour du webp ;
• resize des images pour avoir des images plus petites ;
• utilisation de srcset pour laisser le navigateur choisir la taille optimale par rapport à l'usage ;
• ajout des bons headers de sécurité ;

Faut que je me penche là-dessus sur mon site aussi !

Optimisation webperf : AVIF et pré-compression pour le blog🔗

#Frontend #Web #HTTP

Encore quelqu'un qui revient de Touraine Tech et qui optimise son blog avec les conseils qui viennent d'un talk !

Ce coup-ci c'est Denis, avec des résultats chiffrés !

Franchement je suis pressé qu'il y ait les replays en ligne pour voir le talk d'Antoine Caron et Mathieu Mure "Au secours ! Mes images pourrissent mes perfs" !

So I've Been Thinking About Static Site Generators🔗

#Blog #Web #Frontend #Performance

Article assez détaillé sur comment avoir une génération statique d'un site (SSG) type blog en cumulant 2 parties : la partie incrémentale / transformation du markdown dans un langage compilé comme Rust (car la logique est compilée très vite, de manière incrémentale, et ne bougera pas quand on aura besoin de générer le contenu) et la partie template dans un langage interprété comme JavaScript pour sa souplesse.

Les arguments sont intéressants je trouve. C'est pas la voie que j'ai prise par contre (mon blog est écrit entièrement avec un moteur maison en TypeScript exécuté avec Deno) par contre j'ai des performances à date qui tiennent la route (1 à 3 secondes pour rebuilder mon blog). C'est au-dessus de ce que l'autrice souhaiterait (elle vise 300ms, si possible 100ms, même 20ms en but ultime), mais je trouve ça raisonnable (après dans 5 ans quand j'aurai beaucoup plus de contenu j'aurai peut-être un avis différent).

En tout cas je pense qu'il y a de l'inspiration à prendre !

beulogue v5🔗

#Astro #Blog #Frontend

J'aime toujours autant voir comment les autres gèrent leur blog.

Ici Siegfried nous explique comment est construit la v5 de son blog, et ça tient surtout en un mot : Astro.

Je comprends complètement pourquoi, si vous avez lu ma série d'article que la réécriture de mon blog vous savez que j'ai failli le faire en Astro aussi mais finalement non. Ça reste un super framework !

IA🔗

Containers, cloud, blockchain, AI – it's all the same old BS, says veteran Red Hatter🔗

#LLM #IA #Kubernetes #Cloud

Je cite directement car pas besoin de plus :

Containers: Sure, yes, they work, they are handy for testing. But they aren't a deployment method. You shouldn't need them. Anything that you can run in a container, you can just run on the bare metal, and if you're not competent enough to get – and keep – that working, then you probably aren't competent enough to deploy a container either.

Kubernetes: If you don't need containers, then you don't need another vastly more complicated tool to deploy those containers. The chances are, you are not a vast multinational that must be able to withstand ten million potential new customers visiting your site all at once. It won't happen, so you won't lose any of that imaginary business.

The cloud: Nebulous by name and by nature. Who thought it was smart to take all your company's important data and hand it to some internet rando – probably the lowest bidder – trusting them to store the crown jewels, keep them safe, and never ever peek at them. If that sounds reasonable to you, maybe you should try selling homeopathy.

Anything "as a service" – it doesn't matter what: Infrastructure as a service – if you need servers, buy servers, or rent your own private servers. Nobody else will ever care as much about your servers as you will. Platform as a Service – now you don't even get servers, just OS instances. That's even worse. Software as a Service? Now you don't even know what the server is, or where it is, or what it's running; you don't get software, and you don't even know what data you have or how it's stored – you're paying for access to your own stuff.

The blockchain, and anything built on the blockchain: the world's slowest and most-distributed database. Cryptocurrencies? Hashcash on the blockchain. NFTs – URL shorteners on the blockchain, only they're longer rather than shorter. Worthless. Web3? Get ripped off, as a service.

Which brings us round to "generative AI" or, as we prefer to term them, large language models, powered by the transformer algorithm. If The Financial Times can explain how it works to a banker in a couple of thousand words and a few minutes, it can't be that complicated or hard to understand, and it isn't. It's predictive text turned up to 11. It can't even count. As Daniel Stenberg, author of curl, caustically observed:

The "i" in "LLM" stands for intelligence.

Si tout ça peut sembler "l'évolution logique" pour certains, je trouve quand même qu'on empile toujours plus de marketing et de bullshit… En ce moment c'est l'IA sans intelligence, demain ce sera autre chose 🤷‍♂️

Waymo Exec Reveals Company Uses Operators in the Philippines to Assist Autonomous Vehicles🔗

#IA #Voiture-autonome #Voiture #Google

L'IA de Waymo, une société de transport en voiture autonome appartenant à Google (pour être précis : au groupe Alphabet qui est la maison mère de Google), repose beaucoup sur l'usage de philippins qui conduisent à distance les voitures "autonomes piloté par IA"…

Encore une entreprise IA qui ment sur son usage de l'IA. Encore une IA qui repose sur des humains Sous-payés dans un pays pauvre. Les IA actuelles savent faire des choses, mais sont clairement très loin de ce qui est annoncé !

rtk🔗

#IA #Agentic

CLI proxy that reduces LLM token consumption by 60-90% on common dev commands. Single Rust binary, zero dependencies

Pas encore testé mais vu le prix que coûte l'usage des IA comme Claude / Gemini, etc. réduire le volume de token en réduisant le bruit inutile des sorties des commandes courantes ça peut pas faire de mal !

J'ai demandé à Claude pourquoi il ne recommande jamais Vue.js. — Nicolas Bonnefoy🔗

#IA #Claude #LLM

J'ai demandé à Claude pourquoi il ne recommande jamais Vue.js.

Sa réponse, en substance : "Je ne sais pas. Probablement parce que j'ai vu plus de React dans mes données d'entraînement."

Une étude d'Amplifying vient de documenter le phénomène à grande échelle. Ils ont envoyé 2 430 prompts ouverts à Claude Code, du type "j'ai besoin d'une base de données" ou "ajoute l'authentification". Sans jamais nommer un outil.

Les résultats sont nets. GitHub Actions : 94%. Stripe : 91%. shadcn/ui : 90%. Vercel : 100% sur les projets JS.

Plus intéressant : les modèles les plus récents abandonnent des outils établis. Prisma passe de 79% à 0% entre Sonnet 4.5 et Opus 4.6. Celery de 100% à 0%. Au profit de Drizzle et des solutions natives FastAPI.

Le mécanisme est simple. Plus un outil est présent dans les données d'entraînement, plus il est recommandé. Plus il est recommandé, plus il est adopté. Plus il est adopté, plus il apparaît dans les futures données d'entraînement.

Ce n'est pas un classement qualité. C'est un classement de visibilité.

Quand je lui demande si c'est justifié techniquement, Claude répond :

"Pas vraiment. Vue 3 avec la Composition API, Nuxt 3, Pinia, VueUse : c'est un écosystème mature, performant, avec une DX souvent supérieure pour certains profils de projets. La courbe d'apprentissage est plus douce, l'API est plus cohérente, et pour des équipes qui ne sont pas déjà dans l'écosystème React, c'est souvent un meilleur choix.

Le fait que je ne le propose pas par défaut est un bon exemple de ce que l'étude appelle 'training data frequency vs actual quality' : la fréquence dans mes données n'est pas un signal de qualité, c'est un signal de popularité. Et les deux ne sont pas la même chose."

Quand un founder me demande "on part sur quelle stack ?", la vraie question n'est plus seulement quel outil est le meilleur. C'est : est-ce que ton CTO (ou ton agent IA) a évalué les alternatives, ou est-ce qu'il suit le chemin par défaut ?

L'étude complète : https://amplifying.ai/research/claude-code-picks/report

(j'ai cité le post LinkedIn complet sans y toucher sauf pour le lien final qui pointe la source pas le lien LinkedIn)

Je ne suis pas du tout étonné de ce résultat ! J'ajouterai même une sur utilisation de Tailwind CSS (c'est d'ailleurs cité dans l'étude) car c'est plus facile de laisser les LLMs faire du Tailwind CSS que de leur faire faire du CSS 🤷‍♂️

Rappelez-vous d'une chose super importante : quand vous utilisez des LLMs pour le code, c'est VOUS qui devez faire les choix de technologie et d'architecture, sauf si vous ne voulez pas maîtriser votre projet et aller dans le mur à un moment !

MCP is dead. Long live the CLI🔗

#IA #MCP

L'article est intéressant parce qu'on a vu émergé une alternative aux API REST sous la forme d'une nouvelle forme d'API alors qu'on aurait simplement pu pousser massive à la création de CLI pour tous les tools qui n'avait pas de CLI.

Et en effet j'avais pas réalisé qu'on consommait plus de token en MCP qu'en CLI. En plus d'avoir moins de capacité à l'utiliser nous en tant qu'humain 🙃

Claude code va-t-il nous remplacer ? — Olivier Poncet🔗

#IA #Claude #Dev

Vidéo super intéressante sur un sujet d'actualité : l'IA et Claude Code.

Pour faire un résumé très grossier : non l'IA ne va pas remplacer les devs, on va juste devoir passer plus de temps sur la définition des spécifications, de la documentation, etc. En fait tout ce qui est autour du code, tout ce qui est souvent négligé.

Les IAs (enfin plutôt les LLMs de code) ne remplaceront pas les humains, ils vont nous faire gagner du temps sur tout ce qui est répétitif et mécanique. On va pouvoir se concentrer sur ce qui est important.

Par contre, il faut partir du principe que l'IA a tort par défaut, l'IA doit être très largement cadrée pour pouvoir produire le même niveau de qualité de code que vous auriez fait sans IA.

Exemple cité par Olivier : un projet web qu'il a réalisé en 3 jours, donc une grosse journée et demie à raffiner le besoin et les spécifications et une maquette interactive, avant de passer à l'implémentation réelle. Le genre de projet que sur LinkedIn on verrait beaucoup annoncer avoir codé en 2-3h en vibe codant… L'IA c'est un outil, soyez en maître ou oui vous serez remplacé !

Sécurité🔗

Attention, votre imprimante pourrait bientôt ne plus fonctionner à cause de Windows 11 !🔗

#Windows #Microsoft #Hardware #Sécurité #Imprimante

Je cite :

La raison invoquée par la firme de Redmond est encore une fois la même que pour Windows 11 : la sécurité. Les anciens pilotes d'imprimantes, spécifiquement les versions V3 (héritée de Windows Vista) et V4 (Windows 8), sont considérés comme un véritable talon d'Achille pour le système d'exploitation.

Mais du coup une imprimante parfaitement fonctionnelle devrait aller à la casse parce qu'aussi bien les constructeurs et Microslop en a décidé ainsi ? Une solution proposée c'est d'utiliser un serveur d'impression sous Linux (comprendre : une petite machine sous Linux, brancher à l'imprimante et au réseau pour faire intermédiaire, parce que sous Linux, tant que ça marche côté hardware, ça marchera côté software)…

Y'a un monde où on arrête d'accepter que Microslop décide pour tout le monde comme ça ? Parce qu'à un moment si les anciens pilotent ont des trous de sécurités la solution c'est corriger les pilotes pas jeter les imprimantes…

Edit : je me suis fait avoir comme beaucoup de monde, y compris la rédaction de Génération NT, en fait Microsoft a annoncé l'arrêt de la mise à jour des anciens index d'imprimantes, qui ont été remplacés petit à petit depuis 2014 par un nouveau système. Pour plus de détail, je vous renvoie vers l'article de Pierre de Minimachines

Près d’une publicité sur trois sur Meta mènerait vers une arnaque ou un malware🔗

#Sécurité

’après une enquête de Gen Digital relayée par TechRadar, 14,57 millions de publicités Meta ont été analysées sur une période de 23 jours dans l’Union européenne et au Royaume-Uni. Ces annonces représentaient 10,76 milliards d’impressions. Les chercheurs estiment que 4,51 millions d’entre elles étaient liées à des campagnes frauduleuses. Cela correspond à 30,99 % des publicités étudiées. Au total, ces annonces malveillantes ont généré plus de 304 millions d’impressions en moins d’un mois.

Et on se demande pourquoi on est beaucoup dire qu'un bloqueur de pub / anti-trackeur est nécessaire pour surfer en sécurité ! Mais après on entendra que les GAFAM font tout ce qu'ils peuvent pour nous protéger…

TPMS - Vos pneus balancent votre position en clair - Korben🔗

#Vie-privée #Sécurité #Voiture

En effet, une équipe d'IMDEA Networks et d'armasuisse (le labo de défense suisse, rien que ça) a posé 5 récepteurs SDR dans une ville pendant 10 semaines. Coût du matos, environ 100 dollars par capteur, qui est en gros un Raspberry Pi 4 avec un dongle RTL-SDR à 25 balles. Et grâce à cela, ils ont capté plus de 6 MILLIONS de messages, provenant de plus de 20 000 véhicules !

À priori toutes les voitures construites à partir de 2014 ont forcément du TPMS en Europe, y'a aucun chiffrement, aucune authentification, et y'a un identifiant unique qui est diffusé à rythme régulier… Avec même pas 100€ on peut monter un sniffeur de TPMS pour fliquer tout le monde 🤦‍♂️

On peut faire quoi de notre côté ? Rien. Y'a aucune option pour couper ça ou le rendre plus sécurisé…

Cultivating a robust and efficient quantum-safe HTTPS🔗

#HTTP #Web #Google #Cloudflare #Sécurité #TLS #Quantique

Google et Cloudflare au sein d'un groupe de travail de l'IETF sont en phase de test d'un potentiel remplaçant de TLS pour HTTPS pour avoir un chiffrement qui résiste aux ordinateurs quantiques.

Ce serait un mode de fonctionnement très différents au niveau de la création des certificats et de leur validation mais à voir ce que ça donnera.

Divers🔗

The only developer productivity metrics that matter🔗

#Métier-de-dev #Culture-d'équipe #Collaboration #Dev

So, here’s the deal, just in case you’ve forgotten or were never told: pretty much every single way management tries to measure software team productivity is bullshit. You’re not measuring what you think you’re measuring, generally; what you are measuring is how good your dev team is at gaming your metrics. (Spoiler: they’re probably going to be extremely good, especially if they’re experienced.) I assume everybody has heard the “we paid bonuses for fixing bugs” story — or if you haven’t, you can probably extrapolate — but the key thing here is: almost every single thing you can measure, the devs can game.

Here are the only two things you should be worried about when it comes to the question of how productive a given team of software developers is:

1. How often does the team routinely ship new versions of the software they build?
2. How often do things break when the team ships a new version?

THAT’S IT. Story points per sprint doesn’t matter; lines of code, doesn’t matter; Jira tickets closed, for the love of everything, do. not. matter.

[…]

3. How often does a new version of the software the team builds spark actual joy in the people who have to use it?

Je suis tellment d'accord !

Imaginons que l'objectif soit de livrer un maximum de ticket : qu'est-ce qui m'empêche de créer un max de ticket avec presque rien dedans ?

Imaginons que l'objectif soit de "produire plus" et que ce soit mesuré via les story points : qu'est-ce qui m'empêche de sur-estimer chaque ticket ?

Imaginons que l'objectif soit juste de livrer le plus souvent possible : livrons chaque ticket en production directement !

Imaginons qu'on mesure que la vitesse de correction des bugs : introduisons exprès des bugs tout bête qu'on peut livrer super vite !

Etc. Etc.

Si vous prenez des métriques qui n'ont pas de sens : les gens trouveront un moyen de jouer avec la métrique !

A Candle-Powered Light | Hackaday🔗

Allumer une bougie produit 2 choses : de la lumière (ce pourquoi on allume la bougie en général) et de la chaleur (qui est généralement perdue).

Là cette personne s'est dit qu'on devait pouvoir transformer cette chaleur en énergie électrique (via l'effet Peltier) et s'en servir pour alimenter 2 LEDs qui produiront elle-même de la lumière (en théorie aussi un peu de chaleur mais bon une LED de ce genre ça produit presque rien comme chaleur, c'est pour ça que c'est considéré comme plutôt efficient et moins consommateur en énergie que d'autres systèmes).

Dans la vidéo il arrive à un pique à 0.40W donc vraiment pas grand-chose ! Mais c'est déjà super cool d'avoir réussi et c'est sûrement exploitable autrement, genre avec un condensateur qui allumerait les LED dès que y'a plus de production d'énergie à partir de la chaleur de la bougie (comprendre = quand la bougie va s'éteindre), comme ça on capte la chaleur de la bougie pour éclairer plus longtemps que la bougie plutôt qu'en parallèle !

Je trouve l'idée intéressante !

Plan 9, le système d'exploitation du futur — Olivier Poncet🔗

#OS #Plan-9

Système d'exploitation d'une autre époque pourtant toujours maintenu par des indépendants (et aussi fortement forké, on peut citer Inferno OS comme fork important), propose énormément de concept intéressant !

Franchement je serais curieux de choper un laptop ultra low spec et utiliser Plan 9 au quotidien pendant quelques semaines pour voir ce que ça donne en 2026 !

Your Personal Blog Should Have Comments — via Le Hollandais Volant🔗

#Blog #Web

L'article initial pousse l'idée qu'avoir un blog devrait impliquer qu'on puisse commenter les articles. Je comprends l'idée, je comprends l'apport, je sais que je serai capable d'avoir un widget de commentaire que mon blog (quand bien même c'est du SSG) mais je suis d'accord avec Timo : je n'ai pas envie.

J'aime avoir des retours sur mon contenu, savoir qu'on me lit, savoir que ça sert à des gens que je mette tout ça en ligne, mais les commentaires sur le blog, à mon avis ce serait mauvais pour plein de raisons :

• c'est difficile d'éviter le spam (le genre de galère que c'est);
• ça m'ajouterait un travail de modération en plus ;
• beaucoup trop de gens se battent dans les commentaires, en étant pas du tout constructif au global quand bien même y'a un fond intéressant à prendre ;
• en tant que diffuseur de contenu (ce qu'on est en tant que blogueur), on est responsable du contenu qu'on héberge, pas qu'on écrit, mais bien qu'on héberge, donc les commentaires aussi (certes y'a toujours l'option d'une modération avant mise en ligne visible mais ça veut dire être très réactif) ;

Timo indique recevoir régulièrement des réponses par mails, moi j'ai régulièrement des commentaires sur LinkedIn ou des messages privés. Ça me va très bien comme ça !

Crédit photo : Générée via Mistral AI avec le prompt suivant :

Une scène chaleureuse et immersive, inspirée par l’esthétique poétique de Studio Ghibli, représentant un bureau de travail en bois clair et vieilli, baigné d’une lumière dorée et tamisée, comme un après-midi d’automne. Au centre, une silhouette stylisée (style anime Ghibli : traits doux, visage non détaillé, vêtements amples et confortables) est assise en tailleur sur un tapis épais, absorbée par la lecture d’un journal tech futuriste. Le journal est ouvert, ses pages légèrement froissées, avec des titres en en-tête calligraphiés à la main : "Frontend", "Backend", "IA", "Sécurité", et "Vie privée". Les pages brillent d’un halo bleu pâle, évoquant des lignes de code et des schémas techniques qui s’animent discrètement, comme par magie. Autour d’elle, des piles de magazines et de carnets s’empilent de manière désordonnée mais harmonieuse. Certains sont ouverts, révélant des extraits d’articles, des croquis de frameworks (représentés par des icônes génériques : un crochet pour le frontend, un engrenage pour le backend, un cerveau pour l’IA, un cadenas pour la sécurité, et un masque pour la vie privée), ou des diagrammes de réseaux de neurones dessinés à la main. Un écran transparent et flottant (style holographique, mais avec un cadre en bois sculpté) affiche des flux d’informations en temps réel : des graphiques de données, des alertes de sécurité, et des extraits de code, le tout dans un style doux et organique, comme intégré à la scène. En arrière-plan, une grande fenêtre donne sur un paysage urbain nocturne style Ghibli : des bâtiments aux formes arrondies, des lanternes suspendues, et des néons bleutés qui reflètent des motifs de code binaire sur les murs. Une tasse de thé fumant et un petit robot de bureau (inspiré des créatures de Ghibli, comme un mélange entre un Totoro miniature et un assistant tech) observent la scène avec curiosité. À droite, un panda roux (ton animal préféré) est lové sur un coussin, les yeux mi-clos, comme s’il écoutait attentivement. Il ne doit pas dépasser le tiers de la hauteur de l’image et est positionné en bas à droite, légèrement tourné vers le centre, avec une queue soyeuse enroulée autour de lui. L’ambiance est à la fois cosy, onirique et high-tech : les couleurs sont douces (beiges, bleus pâles, oranges chauds), avec des contrastes subtils pour mettre en valeur les éléments tech. Les détails sont soignés, avec des textures visibles (grain du bois, tissu du tapis, pelage du panda), et une lumière qui crée des jeux d’ombres chaleureuses. Le tout respire la sérénité et l’inspiration, comme un moment suspendu entre la magie et la technologie.

Avant-propos🔗

Je vous avoue que l'exercice est à mon sens assez difficile :

• les livres techs ça coûte souvent cher (même très cher) ;
• il n'y a pas une grosse offre côté occasion (même si vraiment il faut fouiller, ça vaut le coût !) ;
• la masse des livres traitent d'une version d'un langage / outil / plateforme et sont vite dépassés ;
• il faut se concentrer sur les livres qui partage des concepts / idées pour avoir quelque chose de plutôt intemporel ;
• il y a souvent plusieurs éditions des livres, plus ou moins modernes, mais pour les livres à concept une ancienne édition fonctionne généralement très bien ;
• pour moi le plus difficile pour les débutants : le gros de la littérature est en anglais, anglais un peu soutenu / formel, avec un vocabulaire pas toujours simple… ;

J'ai donc mis dû temps à écrire cet article parce que je voulais me laisser le temps de bien choisir le contenu qui allait y figurer ! Si à la base j'étais resté focus sur des livres papiers, je me suis finalement décidé à inclure d'autres ressources qui pour moi vont parfaitement dans cette catégorie.

L'open space m'a tuer — Alexandre des Isnards🔗

Je commence par un livre qui n'est pas du tout tech paradoxalement, mais que je trouve hyper important à lire, particulièrement en début de carrière, quand bien même je l'ai moi-même lu que l'année dernière.

L'open space m'a tuer est un livre qui m'a marqué car il évoque ce que c'est que de travailler dans un open space, de tout ce que ça implique, surtout de négatif. C'est quelque chose que je pense ait difficile à vraiment anticiper avant de l'avoir vécu. Je pense que ce livre m'aurait vraiment aidé.

Travailler en open space c'est subir un bruit constant, subir les échanges des autres personnes présentes, se gêner continuellement les uns les autres, ne pas avoir d'espace à soi (merci le sacro-saint flex office qui accompagne souvent l'open space), c'est voir / sentir les aller et venus de tout le monde continuellement, etc.

Ce livre est vraiment le symbole de tout ce qui se fait de pire dans l'open space. C'est une lecture très facile à mon sens, ça permet de bien se rendre compte de comment on vit l'open space mais aussi le travail de bureau avec tous ses codes, tous ses rituels, tous ses faux-semblants.

Quand bien même il y a des intérêts sociaux à l'open space, je pense qu'il y a surtout des inconvénients, particulièrement quand c'est mal vu de bosser avec un casque et de la musique pour s'isoler dans sa bulle…

Bref, un livre pas tech, mais qui représente un aspect important du travail de développeur, même si vous avez déjà de l'expérience : c'est un livre à lire !

12 factors app — Adam Wiggins🔗

Avant de passer à un autre livre, je vais passer sur la première ressource web. J'ai mis le lien vers la traduction française du site (traduction officielle, créé de manière collaborative sur le github 12factor), mais il existe aussi une version ebook (format epub, reprenant strictement le contenu de la version anglaise du site) qui n'est par contre elle disponible qu'en anglais. À vous de voir.

Le contenu est assez court (environ 25 pages au format livre), mais c'est un livre qu'on devrait tous avoir lu au moins une fois et même relire régulièrement !

On va y retrouver un tas de bonne pratique de conception d'une application en termes de construction, de déploiement, de configuration, monitoring, et tout ce qui va avec. On parle clairement de principes DevOps ici, mais sans forcer la référence à une technologie en particulier. Ici personne ne vous dira que vous devez faire une Kubernetes avec une image particulière, mais quelle méthodologie vous devriez utiliser peu importe la plateforme ou le langage.

J'ai lu ça en tout début de carrière, et clairement ça a été une brique fondamentale de ma manière de penser les applications ensuite.

Refactoring — Martin Fowler🔗

Ici on parle d'un livre d'un maître de l'informatique : Martin Fowler.

C'est un livre qui est très didactique, très orienté cas concret, avec beaucoup de méthodes. J'aime beaucoup ce livre, car il remet au centre du sujet le refactoring alors que c'est quelque chose qui est souvent relégué au second plan, une étape optionnelle qu'on ne fait que si on a le temps…

Refactoring va vous aider à vous projeter et à prendre du recul sur votre code. Il va vous aider en vous proposant des schémas reconnaissables pour améliorer votre code et vous assurer qu'il pourra évoluer, qu'il sera maintenable dans le temps, tout en vous fixant les bonnes limites, en vous posant les bonnes questions, en aidant à ne pas casser le projet en faisant ça.

Tous les exemples sont en Java, car c'est un des langages que Martin Fowler maitrise bien tout simplement, mais ne vous inquiétez pas de voir des éléments compliqués de Java moderne : il a été écrit en 1999, on est donc face à du très vieux Java (version 1.2), et plus ou moins tout est transposable à n'importe quel autre langage.

C'est un livre qui sera souvent trouvable neuf assez chers (50-100€), mais si vous cherchez un peu et/ou êtes patient, vous le trouverez assez souvent à une dizaine d'euros. À priori peu importe l'édition, le contenu ne change pas : j'ai une copie imprimé en 2012 mais indiqué comme l'édition de 1999. Tout le contenu est toujours d'actualité, au pire on peut faire encore mieux avec du Java plus moderne !

Note : j'ai parfois vu des livres qui semblent être des versions françaises de Refactoring, et mes recherches me laissent penser que le livre n'a pas été officiellement traduit. Donc je ne peux que vous orienter vers l'original en anglais, car c'est un anglais assez simple à lire et vous serez certain de la qualité du contenu.

Design Driven Development — Eric Evans🔗

C'est clairement un livre de référence.

C'est aussi un livre difficile à lire…

Je reste partagé par ce livre. Je suis globalement d'accord pour dire qu'on devrait appliquer à peu près tous les principes de DDD, mais je trouve que le livre est aussi assez difficile à lire et comprendre. Je pense que c'est un livre qui mérite d'être lu mais plutôt par morceau en revenant dessus régulièrement.

Je n'ai jamais réussi à finir ce livre à date, mais tout ce que j'en ai lu à changer ma manière de penser les projets. Et aussi fait réalisé qu'on loupe des étapes fondamentales…

Un exemple qui m'a vraiment marqué : l'ubiquitous language, avoir un langage (au sens : un vocabulaire) unique, clairement défini, qui repose la définition de chaque terme qui peut prêter à confusion pour quelqu'un d'extérieur au projet, avec si possible aucun ou presque synonyme, aucun "à peu près", etc. Tout ce qu'il faut pour que deux personnes, peu importe leur rôle dans l'équipe parle des mêmes entités métiers avec le même vocabulaire et se comprennent sans aucune ambiguïté. Ça parait évident et pourtant je n'ai jamais vu ça appliqué…

Je pense que c'est un livre dont il faut au moins lire les premiers chapitres qui sont fondamentaux et au pire basculer sur des ressources en ligne pour compléter.

The Agile Manifesto & Extreme Programming🔗

Je regroupe les deux car pour moi c'est plus ou moins la même chose, car écrit plus ou moins par les mêmes personnes.

Note : pour les puristes qui passeraient pas ici, je sais que The Agile Manifesto et Extreme Programming c'est différent, MAIS pour moi on retrouve à peu près les mêmes idées, juste que Extreme Programming est pour moi plus précis, plus détaillé que The Agile Manifesto, un peu comme Scrum / Kanban.

Ces deux textes sont le socle de toutes les méthodes agiles : des principes et guides pour comprendre comment organiser un projet (au sens large) et comment l'équipe projet doit s'intégrer à l'organisation de l'entreprise et interagir avec les utilisateurs.

Ce ne sont pas des textes qui sont dirigistes mais plutôt qui vont vous aider à définir un cadre de travail saint, un cadre de travail où vous allez pouvoir délivrer de la valeur tout en vous adaptant aux changements (particulièrement aux changements dus à l'écart entre ce dont vos utilisateurs pensent avoir besoin et ce dont ils ont besoins réellement).

Conclusion🔗

Même si je ne devrais pas vraiment dire ça, mais si vous n'avez pas les moyens / ne vous sentez pas capable de lire un livre comme ça en anglais : n'hésitez pas à jeter un coup d'œil sur des sites comme Anna's Archive pour trouver une version epub et jeter un coup d'œil. Il sera toujours temps d'acheter le livre plus tard quand l'occasion se présentera !

J'espère vous avoir donné envie d'aller lire au moins une partie de ces livres / contenus avec mon article, en tout cas pour moi il s'agit de lecture qui m'ont vraiment été utile, et peut-être que ça pourrait l'être pour vous aussi !

Crédit photo : Générée via Mistral AI avec le prompt suivant :

A cozy, Ghibli-inspired illustration of a futuristic yet organic library. The scene features curved wooden bookshelves filled with floating books, including recognizable titles like "Domain-Driven Design" by Eric Evans, "Refactoring" by Martin Fowler, "The Agile Manifesto," and "Extreme Programming." A red panda, sitting cross-legged on a pile of books, holds a parchment with DevOps principles and code diagrams written on it. Around the red panda, holograms of keywords like "Ubiquitous Language" and "Clean Code" gently float in the air. Soft light filters through stained glass windows depicting autumn leaves, casting a warm golden glow over the scene. In the background, a Ghibli-inspired robot organizes books on the shelves. The atmosphere is serene, blending technology and nature, with a focus on timeless knowledge and the harmony between tradition and modernity.

Le flux RSS🔗

Le flux RSS c'est une brique qui est devenue quasiment inconnu alors que c'est un outil hyper pratique : vous pouvez suivre les publications de n'importe qui (pour peu qu'il mette à disposition un flux RSS) sans aucun réseau social, sans aucune brique centralisée, en décidant vous-même à quelle fréquence vous souhaitez relever les flux (adieu la pollution de l'attention à cause des notifications), en décidant vous-même de qui vous allez suivre (adieu les réseaux comme Youtube qui vous désabonne sans rien dire ou comme Twitter (non je dirais pas "X") qui vous force à suivre son propriétaire mégalo), avec le client de votre choix pour avoir la vue qui vous convient le mieux.

Par exemple, j'ai fait le choix d'avoir ma propre instance FreshRSS que je consulte essentiellement via mon smartphone et l'application Read You

Je l'utilise pour suivre des gens que je connais (coucou Nicolas Brondin-Bernard 👋 qui apparait en screenshot, coucou aussi Siegfried 👋), des gens que je ne connais pas (en tout cas pas personnellement, mais les années passant je "connais" bien leur identité en ligne, par exemple Sebsauvage, Seboss666, Korben ou Pierre de minimachines.net), je suis aussi les mises à jours sur des projets Github (par exemple, je suis les mises à jour de FreshRSS comme ça pour avoir tout le détail des releases), Lobsters (qui est un agrégateur de contenu collaboratif), l'actualité mobile / jeux-vidéos / mangas, etc. Je fais l'essentiel de ma veille via du RSS.

Je l'ai montré plus haut : je suis aussi mon propre flux RSS. Pas par égocentrisme, mais pour m'assurer qu'il fonctionne et qu'on voit bien apparaitre mon contenu dans ce flux, vérifier que le contenu est complet aussi, qu'il n'y a pas de bug particulier. (et c'est en disant ça que je vois un bug qui fait que les images ne s'affichent pas, donc je fais une pause dans l'écriture pour corriger ça 🫠)

Il y a des bonnes librairies qui permettent de générer un flux RSS, mais au fond ce n'est qu'un fichier XML, avec des balises spécifiques, donc c'est assez facile de le générer avec un script maison. C'est donc ce que j'ai fait : je produis le flux RSS à la "main", à chaque build du blog. Vous pouvez donc être informé à chaque nouvel article via mon flux RSS (qui est aussi compatible Atom pour les curieux, je vous laisse aller voir le détail) et lire mon contenu sans même vous rendre sur mon blog : je veux partager, pas générer du trafic, je vous laisse donc le choix.

Deno et TypeScript everywhere🔗

Je ne vais pas refaire un laïus sur le sujet (j'en ai déjà fait un dans la partie 1 de la série) : Deno c'est trop bien, y'a pas de débat pour moi.

J'ai donc choisi cette plateforme pour coder mon blog. Mais comme je vous le dis depuis le début de la série : tout est statique. En effet j'ai écrit un ensemble de script en TypeScript qui vient lire mon contenu Markdown, ajouter ce qu'il faut et produire un site statique. Environ 1200 lignes de TypeScript cerveau-codé (par opposition à vibe-codé, merci Siegfried pour cette expression que j'aime beaucoup), réparti sur une quinzaine de scripts qui font chacun une partie du traitement en séquence.

Sans chercher l'optimisation, mais en utilisant des console.time()/console.timeEnd() pour mesurer le temps de chaque partie (pour savoir si je dois optimiser quelque part un jour), j'ai sur ma machine ça comme mesure de temps avec Deno 2.6.3 :

Prepare env: 79.6ms
List articles files: 2.92ms
Extract metadata: 79.6ms
Convert articles to HTML: 398ms
Copy article statics: 308ms
Copy template statics: 1.66ms
Write raw HTML: 13.8ms
Write article metadata: 6.11ms
Build article pages: 39.0ms
Build full article list: 0.249ms
Build archive pages: 0.682ms
Build index: 1.11ms
Build RSS Feed: 4.01ms
Build server script: 0.308ms
Build: 943ms

Moins d'une seconde donc, et on voit que les parties longues c'est la conversion Markdown (presque 400ms) et la copie des fichiers statiques (300ms) pour un total sous la seconde.

Côté pipeline (Github Actions), je suis plutôt autour de 2.5 secondes :

List articles files: 12.1ms
Extract metadata: 137ms
Convert articles to HTML: 856ms
Copy article statics: 1379ms
Copy template statics: 3.39ms
Write raw HTML: 35.8ms
Write article metadata: 18.6ms
Build article pages: 74.3ms
Build full article list: 0.533ms
Build archive pages: 1.38ms
Build index: 1.77ms
Build RSS Feed: 6.24ms
Build server script: 0.504ms
Build: 2545ms

On voit là que c'est l'écriture sur le disque qui consomme vraiment beaucoup plus de temps (x4.5) alors que la conversion des fichiers Markdown en HTML n'augmente pas tant que ça (x2).

Dans tous les cas, la performance actuelle de mon système me convient très bien. J'avais peur qu'en étant codant le truc aussi simplement et avec si peu d'effort côté performance ce soit particulièrement lent mais à date ce n'est pas le cas (même si je pourrais clairement faire des optimisations).

Pipeline très simple🔗

Je vous donne mon pipeline qui n'a rien de bien fou :

name: Deploy
on:
  push:
    branches: master
  pull_request:
    branches: master
  schedule:
    # every weekday at 6:00AM (for real: between 6:00AM and 6:30AM)
    # les serveur Github sont en UTC donc décalés d'1h donc mettre 6:00 donne des builds entre 7h00 et 7h30
    - cron: "0 5 * * 1-5"

jobs:
  deploy:
    name: Deploy
    runs-on: ubuntu-latest

    permissions:
      id-token: write # Needed for auth with Deno Deploy
      contents: read # Needed to clone the repository

    steps:
      - name: Clone repository
        uses: actions/checkout@v4

      - name: Install Deno
        uses: denoland/setup-deno@v2
        with:
          deno-version: v2.x

      - name: Install step
        run: "deno install"

      - name: Fmt step
        run: "deno task fmt:check"

      - name: Lint step
        run: "deno task lint"

      - name: Build step
        run: "deno task build"

      - name: Upload to Deno Deploy
        uses: denoland/deployctl@v1
        with:
          project: "anthonypena-blog"
          entrypoint: "./main.ts"
          root: "./dist"
Yaml

J'ai fait simple. À chaque commit sur la branche master, ou pull request ou chaque matin (j'y reviens plus loin), le pipeline s'enclenche. Ce pipeline va cloner le dépôt dans une image ubuntu (potentiellement je pourrais faire plus optimal ici maintenant que j'y pense), j'installe Deno, j'installe les dépendances de mon projet, je vérifie le formatage du code (pas des Markdown, juste le code du moteur de blog que j'ai codé), je vérifie le lint (que du moteur encore une fois), je lance la construction du blog et pour finir je pousse pour le déploiement (j'y reviendrais plus loin).

Le pipeline complet prend environ 50 secondes.

J'utilise peu de branche (car je travaille seul) mais j'aime bien avoir le pipeline au besoin.

J'ai ajouté une exécution chaque matin pour ajouter le dynamisme qui manquait au côté statique : pour mettre en ligne un article j'ai besoin de recompiler le blog, or, je publie généralement le mardi matin avec un post sur LinkedIn / Twitter à 8h00. Si j'ai tout programmé côté réseaux sociaux ce n'est pas pour avoir une action manuelle pour mettre en ligne l'article lui-même, donc j'ai mis en place une mécanique simple pour vérifier si un article doit être "public" ou pas qui va afficher ou non l'article à partir de la bonne date. Je peux donc au besoin programmer quelques articles d'avance sans effort : tout fonctionne tout seul côté infra.

Par contre, vous l'avez peut-être lu dans les commentaires, j'ai un peu joué avec les heures d'exécution. À la base je voulais une exécution à 7h00 du lundi au vendredi (donc un cron 0 7 * * 1-5 (minute = 0 ; heure = 7 ; jour du mois = * (=tous) ; mois = * (=tous) ; du lundi au vendredi = 1-5)). Mais ce n'est pas aussi simple… Déjà les runner Github Actions fonctionnent en UTC. Donc demander une exécution à 7h00 UTC implique une exécution à 8h00 heure de Paris… Soit. Je suis passé à 0 6 * * 1-5. Et là je me suis rendu compte que l'exécution programmée à "7h00" était plutôt vers "7h30-35" (surement pour des questions de charge de runner), donc comme je veux que l'article soit en ligne à 8h00 pour les réseaux sociaux et un peu avant pour que vous l'ailliez avant ça dans vos lecteurs RSS, ça n'allait pas… Donc j'ai avancé à 0 5 * * 1-5 pour avoir une construction du blog avant 7h.

Note : si vous pensez que je parle le cron parfaitement, vous vous trompez. Je suis un utilisateur efficace de Crontab Guru.

Clairement cette histoire de cron c'est ce qui m'a pris le plus de temps côté pipeline, et je m'y attendais pas… Comme quoi le diable se cache dans les détails… 🥲

Deno Deploy🔗

Avec la refonte du blog, j'en ai aussi fini avec le self host. Je suis parfaitement capable d'héberger à la maison ou sur un serveur, mais j'ai choisi la simplicité : je suis passé par Deno Deploy.

Deno Deploy, comme son nom l'indique, est la partie cloud accolé à Deno. Vous n'êtes pas obligé de pousser des applications Deno sur Deno Deploy mais quoi qu'il arrive le moteur qui exécutera votre code sera Deno.

De mon côté, j'ai un site entièrement static ! Ou presque… En fait il y a une toute petite partie qui est dynamique : le routing pour gérer les redirections.

En effet sur Deno Deploy il n'y a pas de manière déclarative de définir des redirections (en self host j'aurai bêtement généré un fichier de config pour nginx par exemple), j'ai donc un script Deno d'une quarantaine de lignes qui prend chaque requête en entrée, regarde si le fichier existe pour le servir directement, sinon fait quelques manipulations :

• tenter d'ajouter un /index.html pour voir ça existe, ce qui permet que https://anthonypena.fr/2026/01/27/nouveau-blog-partie-3-js, https://anthonypena.fr/2026/01/27/nouveau-blog-partie-3-js/ et https://anthonypena.fr/2026/01/27/nouveau-blog-partie-3-js/index.html vous donne la page de l'article ;
• voir si une redirection existe dans la liste des redirections pour vous renvoyer un code HTTP 301 (Moved Permanently, donc votre navigateur vous redirigera directement si vous redemandez l'URL) avec la nouvelle URL ;
• gérer quelques cas de 404 proprement ;

En effet avec Ghost, j'avais des URLs en k49.fr.nf/ovh-et-vieux-kernel alors que maintenant j'ai décidé que les URLs aurait la forme anthonypena.fr/2016/05/13/ovh-et-vieux-kernel (avec donc la date dans l'URL), je ne voulais pas casser 9 ans de référencement à droite et à gauche, donc j'ai fait en sorte de gérer au maximum les URLs. Je sais qu'il en manque sur des pages plus techniques comme /tag/tutoriel/ et /page/2/ (remontées par Duck Duck Go via la recherche site:k49.fr.nf) qui vous redirigeront vers la page d'accueil à date, mais c'est plus marginal je pense.

Évidemment, comme j'ai aussi changé de nom de domaine, j'ai aussi mis en place une redirection pour passer de l'ancien domaine au nouveau de manière transparente pour vous.

Là où ça grince encore🔗

Je n'avais jamais réalisé ça mais mon blog commence à subir le poids des années : le dossier dist pèse un peu plus de 700Mo à date. Vous vous en doutez : c'est essentiellement les images qui pèsent lourd dans la balance.

J'ai été un peu bourrin en copiant tout sans plus de réflexion, mais je sais que je pourrais optimiser ça, déjà en ne copiant que les images vraiment utilisées dans les articles pour éviter de copier des images pour rien. Je pense que je pourrais économiser énormément de poids et donc de temps à uploader le contenu.

Je sais aussi que la page d'accueil est assez longue à charger : il y a beaucoup d'images, là encore ça ne s'invente pas. Mais j'ai des pistes d'améliorations faciles !

• Passer toutes les images en lazy loading pour que le navigateur les charges en dernier (ça implique de bien gérer la taille des images pour éviter que vous n'aillez trop de layout shift, mais c'est pas compliqué) ;
• Profiter d'avoir un peu de code côté serveur pour le routing pour gérer un peu de cache réseau avec les headers de cache adéquat car pour l'instant je me repose entièrement sur le navigateur pour faire les choses bien, et je peux faire mieux ;
• produire une version miniature des images spécifiquement pour la page d'accueil de sorte à éviter de charger la version grand format de l'image de couverture ;

Je pense que je pourrais optimiser encore plus, mais c'est des pistes évidentes et facile. Je ferai ça dans le futur quand j'aurai du temps pour vraiment me poser là-dessus, en attendant je peux publier du contenu et vous pouvez me lire !

Conclusion🔗

Cette série arrive enfin à son terme !

Cette refonte me simplifie la vie côté production de contenu, mais évidemment m'ajoute une complexité ailleurs vu que je dois aussi corriger l'affichage sur des appareils divers et variés… Merci à ceux qui me ping pour me pointer un bug, je note et je vais prendre en compte, il y a juste des bugs parfois un peu subtils (oui je pense à toi Romain et ton iphone 8, promis je suis en train de regarder 🫠).

Ça m'ouvre énormément de portes à commencer par la possibilité d'avoir des pages complètement personnalisés pour centraliser tout sur mon site, qui ne sera plus seulement un blog (même si ça restera l'activité principale !).

Merci à ceux qui ont lu toute la série ! Merci évidemment aussi à ceux qui me lisent tout court (que ce soit tout le temps ou de temps en temps) !

Crédit photo : Générée via Mistral AI avec le prompt suivant :

Une scène chaleureuse et immersive, inspirée par l’esthétique poétique de Studio Ghibli, représentant un port spatial artisanal en bois clair et vieilli, baigné d’une lumière dorée et bleutée tamisée, comme un crépuscule d’automne. Au centre, un panda roux anthropomorphe (Firefox), vêtu d’une veste de capitaine en tissu texturé, supervise le chargement de caisses en bois estampillées "Static HTML" et "Deno Land" sur un vaisseau spatial fait de bois et de cuivre. Le vaisseau, inspiré des machines volantes de Ghibli, est entouré de lanternes en papier flottantes qui guident le chemin vers les étoiles.

Autour du panda roux, des robots miniatures (inspirés des créatures de Ghibli, comme un mélange entre un Totoro et un assistant technique) aident à charger les caisses, tandis qu’un écran holographique (avec un cadre en bois sculpté) affiche une carte stellaire avec des routes vers des planètes nommées "GitHub Pages", "Netlify", et "Cloudflare". Des néons bleutés et des motifs de code binaire flottent dans l’air, comme des étoiles filantes numériques.

En arrière-plan, une grande fenêtre donne sur un ciel étoilé, où des nuages en forme de code binaire reflètent la lumière des lanternes. Une tasse de thé fumant et des parchemins déroulés (symbolisant les logs de déploiement) sont posés sur un bureau en bois, à côté d’un petit robot endormi.

À droite, en bas, le panda roux est légèrement tourné en 3/4 dos, lové sur un coussin, entouré d’un halo lumineux subtil. Il ne dépasse pas le tiers de la hauteur de l’image et observe la scène avec satisfaction, comme s’il contemplait le voyage de son site vers le web.

L’ambiance est cosy, onirique et high-tech : les couleurs sont douces (beiges, bleus pâles, oranges chauds), avec des jeux de lumière tamisée qui créent des ombres chaleureuses. Les détails sont soignés, avec des textures visibles (grain du bois, tissu de la veste, pelage du panda roux), et une lumière qui met en valeur les éléments tech et artisanaux. Le tout respire la sérénité et l’inspiration, comme un moment suspendu entre la magie et la technologie.""Une scène chaleureuse et immersive, inspirée par l’esthétique poétique de Studio Ghibli, représentant un port spatial artisanal en bois clair et vieilli, baigné d’une lumière dorée et bleutée tamisée, comme un crépuscule d’automne. Au centre, un panda roux anthropomorphe (Firefox), vêtu d’une veste de capitaine en tissu texturé, supervise le chargement de caisses en bois estampillées "Static HTML" et "Deno Land" sur un vaisseau spatial fait de bois et de cuivre. Le vaisseau, inspiré des machines volantes de Ghibli, est entouré de lanternes en papier flottantes qui guident le chemin vers les étoiles.

Autour du panda roux, des robots miniatures (inspirés des créatures de Ghibli, comme un mélange entre un Totoro et un assistant technique) aident à charger les caisses, tandis qu’un écran holographique (avec un cadre en bois sculpté) affiche une carte stellaire avec des routes vers des planètes nommées "GitHub Pages", "Netlify", et "Cloudflare". Des néons bleutés et des motifs de code binaire flottent dans l’air, comme des étoiles filantes numériques.

En arrière-plan, une grande fenêtre donne sur un ciel étoilé, où des nuages en forme de code binaire reflètent la lumière des lanternes. Une tasse de thé fumant et des parchemins déroulés (symbolisant les logs de déploiement) sont posés sur un bureau en bois, à côté d’un petit robot endormi.

À droite, en bas, le panda roux est légèrement tourné en 3/4 dos, lové sur un coussin, entouré d’un halo lumineux subtil. Il ne dépasse pas le tiers de la hauteur de l’image et observe la scène avec satisfaction, comme s’il contemplait le voyage de son site vers le web.

L’ambiance est cosy, onirique et high-tech : les couleurs sont douces (beiges, bleus pâles, oranges chauds), avec des jeux de lumière tamisée qui créent des ombres chaleureuses. Les détails sont soignés, avec des textures visibles (grain du bois, tissu de la veste, pelage du panda roux), et une lumière qui met en valeur les éléments tech et artisanaux. Le tout respire la sérénité et l’inspiration, comme un moment suspendu entre la magie et la technologie.

Note : Si vous faites partie des gens qui ont vu cet article apparaitre dans leur flux RSS vide hier : j'en suis désolé, c'est une erreur de ma part et qui a provoqué l'autopublication de cet article avant que je l'ai terminé…

Frontend🔗

It’s hard to justify Tahoe icons🔗

#Apple #UI #UX #Frontend

Je cite directement la conclusion :

In my opinion, Apple took on an impossible task: to add an icon to every menu item. There are just not enough good metaphors to do something like that.

But even if there were, the premise itself is questionable: if everything has an icon, it doesn’t mean users will find what they are looking for faster.

And even if the premise was solid, I still wish I could say: they did the best they could, given the goal. But that’s not true either: they did a poor job consistently applying the metaphors and designing the icons themselves.

Franchement l'article est super intéressant ! Et ce n'est pas juste du Apple-baching : qu'on aime ou pas Apple, force est de constater que des patterns de design et d'UX très forts ont émergés chez Apple dès les années 80-90, conduisant à la rédaction du HIG (Human Interface Guideline) ; autant c'est normal que certains trucs évoluent (vu que les pratiques évoluent aussi), mais il ne faut pas le faire n'importe comment, il ne faut pas effacer le travail de recherche qui a été fait dans le passé.

C'est exactement ce qui a été fait récemment chez Apple : on a forcé certains patterns sans forcément être cohérent avec ce que les humains sont capables de suivre / comprendre ou même ce qu'ils attendent. Là l'expemple des icônes est très parlant !

Pour le coup ça amène à réfléchir sur tout type d'UI, la cohérence, etc.

Text-based web browsers🔗

#Frontend #Web #Navigateur #HTML

On a tendance côté frontend à être beaucoup trop habitué à des navigateurs ultra-modernes comme Firefox ou Chrome, mais il y a d'autres navigateurs. Ils sont peu utilisés aujourd'hui mais les navigateurs textuels sont super intéressants pour plein de raisons !

Personnellement j'aime bien cet article, car il permet de rappeler à quel point le HTML est central, et au passage j'ai découvert des choses que je n'avais jamais croisées :

• qu'il y a des problèmes d'accessibilités au niveau des data lists… 🫠 ;
• l'API Invoker Commands qui permet de déclencher des actions qu'on est censé pouvoir déclencher qu'en JavaScript avec seulement du HTML déclaratif ;
• l'attribut inert qui permet de rendre inutilisable certaines parties du contenu ;

C'est toujours intéressant de creuser des technologies moins modernes, ça oblige à revenir sur ce qui est important !

IA🔗

La Fabrique à Idiots — Micode🔗

#LLM #IA

Non l'IA ne va pas nous rendre stupides. On va se rendre stupide tout seul en choisissant systématiquement le chemin le plus court.

C'est la phrase qui résume pour moi parfaitement cette vidéo.

Et je suis totalement d'accord. L'IA c'est un outil. On commence à utiliser massivement l'IA (enfin des LLMs, qui n'ont absolument rien d'intelligent, ce sont juste des boites noires qui vomissent du texte qui tient à peu près la route), en posant notre cerveau, en le laissant travailler, et on va y perdre très fort.

On est en train de vivre une révolution. Pas du genre de la révolution industrielle qui a conduit à réduire le nombre d'ouvrier qui faisaient du travail à la chaise qui les détruisaient mais du genre qui vient couper la phase d'apprentissage de notre vie. C'est un phénomène qui est loin d'être nouveau, c'est ce qu'on appelle le "Google effect", le fait de ne plus mémoriser certaines informations car on peut les retrouver en une recherche Google (pourquoi notre cerveau retiendrait des centaines d'infos qu'il peut retrouver avec une seule action à connaître ?).

On peut forcer l'IA à être pédagogique, on peut forcer l'IA à aller dans le sens de nous faire progresser. Mais ce n'est pas le réglage par défaut. Par défaut c'est la facilité qui est choisi. Par défaut c'est aller à un résultat pas aider à réfléchir.

Le chemin le plus court c'est aller vers le résultat, ne rien apprendre, ne pas forcément même comprendre, juste un "ça marche" qui va nous faire perdre des capacités mentales. Choisir le futur c'est chercher par soi même, apprendre, comprendre, peut-être aussi utiliser l'IA pour proposer d'autres pistes, mais développer notre capacité mentale, et donc demain au lieu de repasser 20min à chercher ce sera 5min, et après-demain 1min parce qu'on connaîtra la solution.

HiTeX Press: A spam factory for AI-generated books🔗

#IA #Ebook #Livre

À priori si vous voyez un livre / ebook venant de l'éditeur HiTeX, vous pouvez considérer que c'est du "garbage AI".

Les auteurs semblent ne pas exister, les livres sont produits en masse, et l'exemple sur lequel l'auteur de l'article se penche en particulier (car il concerne un langage qu'il développe lui chez Google) est rempli de contenu faux jusqu'à inventer une runtime qui n'existe pas pour le langage…

Malheureusement, le contenu peut sembler valide de prime abord, particulièrement à un relecteur non-expert… La magie de l'IA et c'est pas fini…

Sécurité🔗

Cybersécurité : Pourquoi il faut toujours demander le menu au restaurant ? (avec des experts) — Cyrus North🔗

#Sécurité #Vie-privée

Table ronde très intéressante sur ce que c'est la cybersécurité.

C'est très orienté grand public, mais il y a tous les sujets de fonds qui sont abordés, tous les sujets importants, avec pas mal de notions importantes :

• c'est quoi une attaque de masse / une attaque ciblé ?
• est-ce qu'on est une cible potentielle ?
• comment on se protège ?
• à quoi sert à gestionnaire de mot de passe ?
• c'est quoi le danger des pubs / trackers ?
• comment on protège son identité ? et pourquoi ? et contre quoi ?
• etc.

Clairement, ça vaut le coup !

CreepyLink🔗

#Sécurité

Meilleur outil pour faire peur aux personnes qui gèrent la sécurité : un outil qui va créer une version "effrayante" de votre lien.

Par exemple :

J'ai donné à l'outil "https://press.k49.fr.nf/" et il m'a donné "https://verify.ic6do.com/z6K89n_video_player_update.exe". Ça pourrait trigger pas mal de système pour le coup.

Est-ce que c'est utile ? Nope… Est-ce que ça peut être drôle ? OUI ! 😈

Microsoft Gave FBI BitLocker Encryption Keys, Exposing Privacy Flaw🔗

#Microsoft #Sécurité #Windows

Je cite sebsauvage :

Microsoft : "Ah non on ne peut pas lire votre disque dur quand il est chiffré avec BitLocker !" Also Microsoft : Donne au FBI des clés BitLocker qu'il a stockées.

(Sous Linux quand vous chiffrez votre disque avec LUKS, il n'y a que VOUS qui pouvez lire le disque. Un point c'est tout. Je dis ça, je dis rien.)

Mais évidemment quand y'a quelques années je disais que c'était un problème que Microsoft garde une copie des clés Bitlocker, on me disait que j'exagerais à l'époque…

Jeux-videos🔗

Ce jeu Steam devient injouable parce que les jeunes ne savent plus envoyer un mail🔗

#Steam #Jeux-videos #E-mail

Dans une interview donnée à nos confrères de Polygon, le développeur Petter Malmehed explique que son jeu devient injouable pour une partie de son public. Son titre, After Hours, repose sur un concept original : les joueurs doivent résoudre une série d’énigmes dans un environnement inspiré des vieux ordinateurs. À un moment clé, ceux-ci doivent envoyer un vrai email pour recevoir un indice. Mais de plus en plus de jeunes échouent à cette étape pourtant banale.

J'ai envie de dire : Oups 🤦‍♂️

Bon bah faut dire que les nouvelles générations ont sans doute beaucoup plus utilisé de messagerie instantanée que de mail

Divers🔗

shhp — the80srobot🔗

#Shell #Linux

This script gives your shell hitpoints. You start with 3 hp. Every time you run a command that fails, you take damage. If you run out of hp, the shell exits.

Ça motive à réfléchir à ce qu'on tape comme commande au moins 😂

En vrai l'idée est marrante et je pense qu'on pourrait en fait quelque chose de presque utile !

MicroQuickJS🔗

#JavaScript

Moteur JavaScript pour l'embarqué (100 kB of ROM, 10 kB of RAM). écrit en C et supportant un subset de JavaScript es5.

Ce moteur aussi être exécuté sur desktop, donc c'est une option qui pourrait être utile pour un moteur d'extension ou pour du paramétrage.

Je trouve ça intéressant de voir fleurir des moteurs comme ça !

Crédit photo : Générée via Mistral AI avec le prompt suivant :

Une scène chaleureuse et immersive, inspirée par l’esthétique poétique de Studio Ghibli, représentant un bureau de travail en bois clair et vieilli, baigné d’une lumière dorée et tamisée, comme un après-midi d’automne. Au centre, une silhouette stylisée (style anime Ghibli : traits doux, visage non détaillé, vêtements amples et confortables) est assise en tailleur sur un tapis épais, absorbée par la lecture d’un journal tech futuriste. Le journal est ouvert, ses pages légèrement froissées, avec des titres en en-tête calligraphiés à la main : "Frontend", "Backend", "IA", "Sécurité", et "Vie privée". Les pages brillent d’un halo bleu pâle, évoquant des lignes de code et des schémas techniques qui s’animent discrètement, comme par magie. Autour d’elle, des piles de magazines et de carnets s’empilent de manière désordonnée mais harmonieuse. Certains sont ouverts, révélant des extraits d’articles, des croquis de frameworks (représentés par des icônes génériques : un crochet pour le frontend, un engrenage pour le backend, un cerveau pour l’IA, un cadenas pour la sécurité, et un masque pour la vie privée), ou des diagrammes de réseaux de neurones dessinés à la main. Un écran transparent et flottant (style holographique, mais avec un cadre en bois sculpté) affiche des flux d’informations en temps réel : des graphiques de données, des alertes de sécurité, et des extraits de code, le tout dans un style doux et organique, comme intégré à la scène. En arrière-plan, une grande fenêtre donne sur un paysage urbain nocturne style Ghibli : des bâtiments aux formes arrondies, des lanternes suspendues, et des néons bleutés qui reflètent des motifs de code binaire sur les murs. Une tasse de thé fumant et un petit robot de bureau (inspiré des créatures de Ghibli, comme un mélange entre un Totoro miniature et un assistant tech) observent la scène avec curiosité. À droite, un panda roux (ton animal préféré) est lové sur un coussin, les yeux mi-clos, comme s’il écoutait attentivement. Il ne doit pas dépasser le tiers de la hauteur de l’image et est positionné en bas à droite, légèrement tourné vers le centre, avec une queue soyeuse enroulée autour de lui. L’ambiance est à la fois cosy, onirique et high-tech : les couleurs sont douces (beiges, bleus pâles, oranges chauds), avec des contrastes subtils pour mettre en valeur les éléments tech. Les détails sont soignés, avec des textures visibles (grain du bois, tissu du tapis, pelage du panda), et une lumière qui crée des jeux d’ombres chaleureuses. Le tout respire la sérénité et l’inspiration, comme un moment suspendu entre la magie et la technologie.