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

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 :

Vue de la page avec uniquement les puces de la liste visible

Ç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 dans le 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 !

Vue avec juste la définition de la grille

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

:

#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

Vue avec les jours en forme de cercle

C'est un peu mieux, mais il y a toujours les puces des différents

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

Grille minimaliste sans aucune indication

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
avec l'attribut data-previous-year ;
ajouter un fond pour les
qui contiennent un élément (pour mettre en évidence les jours avec un article) ;

ajouter une bordure colorée pour la date du jour (les

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

Vue de la grille en mettant en évidence les éléments intéressants

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

qui ont l'attribut data-date avec une valeur contenant (*=) la chaîne de caractère -02-", autrement dit pour nous "tous les

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

Avec les mois en évidence

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

qui suivent un

.

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

Vue avec les dates futures identifiées

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

dans notre liste

#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 :

Ancre vue dans la barre d'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

Mise en avant de la cible de l'ancre

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 :

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.

Créer un composant Tabs avec Angular

Anthony Pena — Tue, 24 Mar 2026 07:00:00 GMT

Récemment j'ai eu besoin de créer un composant Tabs pour une vue avec des onglets. Ce n'est pas très compliqué, mais il y a quelques trucs intéressants à faire pour avoir des éléments très simples à manipuler en tant que consommateur du composant, avec peu d'effort de maintenance ensuite.

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 1button>li>
      <li class="tab-header active"><button data-tab="tab-2">Tab 2button>li>
      <li class="tab-header"><button data-tab="tab-3">Tab 3button>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

Vu avec seulement HTML et 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 1li>
        <li app-tab="tab-2">Tab 2li>
        <li app-tab="tab-3">Tab 3li>
    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

et

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 :

: 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: `
    
        
    
`,
})
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: `
    
        
            
        
    
`,
})
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: `
    
    `,
})
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
Tab 1
que d'écrire Tab 1.

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: "",
})
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.

Version non finie mais en composant Angular

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 , 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: `
    
    `,
})
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: "",
})
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

Démonstration des onglets fonctionnels

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.

2025 c'est fini, en route pour 2026 !

Anthony Pena — Wed, 11 Mar 2026 07:00:00 GMT

Nouvelle année, nouveau bilan ! Cette année est encore une année un peu mouvementée !

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.

Revue de presse - Mars 2026

Anthony Pena — Tue, 03 Mar 2026 07:00:00 GMT

Frontend🔗

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:

How often does the team routinely ship new versions of the software they build?

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.

[…]

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.

Les trucs à lire dans votre vie de dev

Anthony Pena — Wed, 18 Feb 2026 07:00:00 GMT

On m'a déjà demandé ce que je pouvais recommander comme lecture pour s'améliorer en tant que développeur. J'ai fini par écouter cette demande (particulièrement merci à toi Bich de m'avoir vraiment poussé sur ce sujet même si j'aurai mis du tout à le faire !) et me poser sur ce guide !

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.

Nouveau blog -- partie 4 : et le reste...

Anthony Pena — Tue, 10 Feb 2026 07:00:00 GMT

Dans cet article je vais parler en vrac de tous les petits trucs qui font que tout fonctionne et qu'on voit moins : le flux RSS, le déploiement chaque matin, des problèmes aussi…

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

Différentes vue de Read You sur mon smartphone

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.

Démonstration 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.

Revue de presse - Fevrier 2026

Anthony Pena — Wed, 04 Feb 2026 07:00:00 GMT

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é🔗

#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.

Nouveau blog -- partie 3 : JavaScript

Anthony Pena — Tue, 27 Jan 2026 07:00:00 GMT

Dans la première partie je parlais du contenu en HTML, dans la seconde des outils CSS que j'ai utilisés pour vous présenter le contenu plus proprement, que reste-t-il à présenter ?

Vous êtes en train de lire un blog généré statiquement, il y a assez peu d'interaction possible à part des liens (logique pour un blog au fond), donc que manque-t-il ? Techniquement rien. En vrai j'aurai pu m'arrêter là, mais j'ai ajouté une fonctionnalité de zoom sur deux parties des articles : les images et les galeries d'images, et pour que ça fonctionne bien j'ai été obligé d'ajouter du JavaScript.

Sans JavaScript🔗

Pour moi c'était important que tout fonctionne sans JavaScript. Je suis peut-être vieux jeux sur ce coup-là, mais j'estime que si vous arrivez avec un grille-pain avec un navigateur textuel vous devriez pouvoir lire mon blog (si vous lisez ce blog sur un grille-pain via un navigateur textuel : envoyez-moi une photo, ça me fera un kiff de ouf !).

Donc voyons ce que ça donne sans JavaScript :

Vue d'un article sans JavaScript

À priori rien de particulier à signaler. Mais si maintenant on ajoute le JavaScript ?

Vue d'un article avec du JavaScript

Vous noterez le changement de curseur au survol d'une image pour indiquer qu'on peut cliquer, au clic le zoom pour passer l'image en plein écran. Pareil pour les galeries mais en plus l'option de pouvoir défiler les images de la galerie en cours.

L'amélioration est petite (mais indispensable pour certains articles à mon sens), mais elle est là. Et je l'ai fait sans aucune librairie externe, avec deux Web Components très simple.

Web Component ? kézako ?🔗

Un Web Component c'est simplement le nom qu'on donne à une brique JavaScript qui est composé d'un Custom Element, de Shadow DOM et des éléments

Anthony Pena

Revue de presse - Mai 2026

Frontend🔗

IA🔗

Sécurité🔗

Divers🔗

Un VPN ça ne sert à rien

VPN ? Kézako ?🔗

Pouvez-vous faire confiance à votre serveur VPN ?🔗

Est-ce que tout passe par le VPN ?🔗

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

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

Conclusion🔗

Reprendre le contrôle de vos dépendances NPM

C'est quoi une dépendance ?🔗

Visualisé vos dépendances🔗

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

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

Renovate / Dependabot🔗

Astuce : SemVer Calculator🔗

Conclusion🔗

Revue de presse - Avril 2026

Frontend🔗

Backend🔗

IA🔗

Sécurité🔗

Divers🔗

Créer une vue calendrier minimaliste avec du HTML et du CSS

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

Let's go HTML!🔗

Note sur le thème🔗

D'une liste à une grille🔗

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

Conclusion🔗

Créer un composant Tabs avec Angular

Le style🔗

Côté utilisation🔗

Construisons les composants🔗

Créer un état partagé entre tout le monde🔗

Conclusion🔗

2025 c'est fini, en route pour 2026 !

Côté mission🔗

Côté SFEIR🔗

Côté langage et projets perso🔗

Conférences / Talks🔗

Le blog🔗

Mon BuJo et moi🔗

Côté lecture🔗

Conclusion🔗

Revue de presse - Mars 2026

Frontend🔗

IA🔗

Sécurité🔗

Divers🔗

Les trucs à lire dans votre vie de dev

Avant-propos🔗

L'open space m'a tuer — Alexandre des Isnards🔗

12 factors app — Adam Wiggins🔗

Refactoring — Martin Fowler🔗

Design Driven Development — Eric Evans🔗

The Agile Manifesto & Extreme Programming🔗

Conclusion🔗

Nouveau blog -- partie 4 : et le reste...

Le flux RSS🔗

Deno et TypeScript everywhere🔗

Pipeline très simple🔗

Deno Deploy🔗

Là où ça grince encore🔗

Conclusion🔗

Revue de presse - Fevrier 2026

Frontend🔗

IA🔗

Sécurité🔗

Jeux-videos🔗

Divers🔗

Nouveau blog -- partie 3 : JavaScript

Sans JavaScript🔗

Web Component ? kézako ?🔗

Composant de zoom d'image🔗

Conclusion🔗

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

The Agile Manifesto & Extreme Programming 🔗