• 3 mai 2026 à 18:39

    Séance elliptique à la cool devant Scrubs 👌
  • 3 mai 2026 à 16:55

    Ces derniers temps je m’intéresse à Next.js et honnêtement je comprend pas pourquoi je ne m’y suis pas intéressé plus tôt. #vismavie
  • dimanche 03 mai 2026 @ 16:33:36

    Balade du gnome pour éviter les écrans 👌

    • 3,85 km
    • 5 608 pas
    • 57min 49s
  • One Developer, Two Dozen Agents, Zero Alignment

    Maggie Appleton bosse chez GitHub Next sur un truc qu’ils appellent Ace — un workspace d’agents en temps réel, multijoueur. Le pitch tient en une phrase : et si les agents de code n’étaient pas juste des outils solo, mais des collaborateurs partagés entre toute une équipe ?

    La conférence part d’un constat qui m’a bien parlé. On est en train de vivre l’ère du “un dev + vingt-quatre Claudes = une équipe entière”. Et ça m’a fait sourire, parce que c’est exactement l’illusion qu’on se raconte. Sauf que le vrai problème n’a jamais été la vitesse d’implémentation. C’est l’alignement — savoir ce qu’on est censé construire, pourquoi, et pour qui.

    Son image est imparable : “neuf femmes ne font pas un bébé en un mois”. Produire plus vite individuellement ne résout pas les problèmes qui demandent coordination et communication. Ça les aggrave.

    Ce qui m’a le plus frappé, c’est le constat sur les outils actuels. GitHub, Slack, Jira — tous conçus pour une époque où l’implémentation prenait du temps.

    Aujourd’hui, le temps entre l’ouverture d’une issue et le PR de l’agent, c’est quelques minutes. On planifie plus. On aligne plus. Et on laisse le pauvre PR porter tout le poids d’une conversation qui aurait dû avoir lieu bien avant.

    Ace essaie de répondre à ça : un espace partagé, des agents en commun, un contexte visible pour tout le monde en temps réel.

    Est-ce que ça va marcher ? Je sais pas. Mais la question posée, elle, est bonne.

    Ah, et y’a un moment où elle dit que les agents sont nuls en CSS. Enfin quelqu’un qui dit la vérité.

  • Menu horizontal CSS : les sprites, c’était malin en 2009, beaucoup moins en 2026

    La technique des sprites CSS a longtemps été une excellente solution pour optimiser les menus à base d’image, mais en plus de 15 ans, le Web a bien évolué. En 2026, on peut (on doit 🤔) construire des menus horizontaux plus souples, responsives et accessibles. Dans cet article, on va voir comment recréer l’idée d’un « menu horizontal avec sprites CSS » en utilisant des techniques modernes, en gardant les mêmes objectifs qu’à l’époque : esthétique et performance.

    (suite…)
  • Three Ways phpMyAdmin Saves Your WordPress Site and Your Sanity

    phpMyAdmin, c’est un peu l’outil qu’on oublie jusqu’au moment où tout part en vrille. L’article rappelle trois trucs super pratiques : corriger les URL cassées après une migration (parce qu’on a tous déjà galéré avec ça), nettoyer les révisions qui bouffent la base, et réparer les tables corrompues en deux clics.

    Ce qui me plaît, c’est que c’est direct et sans bullshit. Pas de plugin miracle à installer, juste une connexion à la base et quelques requêtes SQL bien senties. C’est le genre de conseil qu’on donne à un pote qui flippe devant son site planté.

    Bon, évidemment, faut pas jouer avec la base les yeux fermés. Backup d’abord, explore ensuite. Mais franchement, phpMyAdmin reste un couteau suisse indispensable quand WordPress fait sa crise. Ça rassure de savoir qu’on peut encore mettre les mains dans le cambouis.

  • 8 février 2026 à 21:20

    En parcourant mon reader RSS, je suis tombé sur cet article https://www.alwaystwisted.com/articles/ive-been-compiling-my-sass-wrong-for-years et ça m’a fait réaliser que j’avais moi aussi ce warning quand je compile mes SCSS au boulot. Premier truc que je ferai en arrivant demain matin !
  • CSS @scope: An Alternative To Naming Conventions​​​​​​​​​​​​​​​​

    Alors là, je dois dire que @scope me parle vraiment. J’ai passé des années à jongler avec BEM, SMACSS, et toutes ces conventions de nommage qui finissent par te donner l’impression d’écrire du morse plutôt que du CSS. L’idée de pouvoir scoper du CSS natif sans avoir à préfixer chaque classe avec le nom du composant trois fois, c’est exactement ce qu’il me fallait.

    Ce qui me botte, c’est que ça reste lisible. Pas de .card__header–modifier à rallonge. Juste du CSS qui dit clairement “ça s’applique dans ce contexte, point final”. Et le support navigateur est déjà là pour une bonne partie. Bon, évidemment, il faut un peu de temps pour que tout le monde suive, mais l’approche progressive me va bien.

    Je pense tester ça sur mon prochain side project, histoire de voir comment ça se comporte dans la vraie vie. Parce qu’en vrai, les conventions c’est bien, mais si le langage peut gérer le problème nativement, pourquoi se compliquer la vie ?

  • Windsurf et moi : journal d’un dev qui apprend à parler à une IA

    Ça fait deux semaines que j’utilise Windsurf pour développer un plugin WordPress.
    Le principe ? Ajouter des options sur les blocs Gutenberg natifs (en React/JSX), et gérer des Custom Post Types proprement.

    Rien de dingue sur le papier.
    Mais en vrai, c’est le genre de projet où tu te retrouves vite avec du code front mélangé au code métier, des fichiers qui grossissent, et un moment où tu te demandes « mais pourquoi j’ai foutu ça là ? ».

    Avant, j’aurais passé une journée entière à refactoriser pour que ce soit propre.
    Là, j’ai tenté de faire équipe avec l’IA.

    Spoiler : c’est ni parfait, ni magique. Mais franchement, c’est troublant.

    Le moment où j’ai compris que c’était différent

    Au début, je lui ai juste balancé :

    « J’ai du code pour étendre des blocs Gutenberg. Aide-moi à séparer proprement le front-end de la logique métier. »

    Windsurf ne m’a pas juste craché trois suggestions de fonctions.
    Il a réorganisé des fichiers.
    Il a créé des dossiers, proposé une archi, déplacé du code React d’un côté, les enregistrements de CPT de l’autre.

    Pas parfait, hein. Mais cohérent.

    Et moi, pendant ce temps, je ne codais presque pas.
    Je lisais, je validais, je virais ce qui ne me plaisait pas.

    C’est là que j’ai senti le truc : je n’étais plus vraiment en train de « coder ».
    J’étais en train de piloter.

    Font Awesome sur les boutons : ou comment j’ai réécrit mes prompts 15 fois

    Le truc qui m’a le plus pris la tête, c’est l’ajout d’icônes Font Awesome sur les blocs core/button.

    Sur le papier, c’est simple :
    tu rajoutes un control dans le panneau Gutenberg, tu laisses l’utilisateur choisir une icône, tu l’affiches côté front avec la bonne classe Font Awesome.

    Dans la réalité ?
    Windsurf m’a sorti :

    • Des contrôles Gutenberg qui ne compilaient pas.
    • Des attributs qui disparaissaient au save/reload.
    • Du JSX bancal avec des icônes qui se dupliquaient ou qui partaient dans le mauvais sens.
    • Une fois, il m’a même proposé d’importer tout Font Awesome en JS côté éditeur (merci, mais non).

    Le problème, c’est que je lui demandais des trucs trop vagues.
    Genre :

    « Ajoute une option pour choisir une icône Font Awesome. »

    Résultat : il partait dans tous les sens.

    J’ai dû affiner. Beaucoup.
    Jusqu’à arriver à des prompts du style :

    « Ajoute un SelectControl dans InspectorControls pour choisir parmi 5 icônes Font Awesome.
    L’attribut doit s’appeler faIcon, de type string.
    L’icône doit s’afficher avant le texte du bouton, côté front uniquement, avec la classe fa-solid fa-{nomIcone}. »

    Là, ça commençait à tourner.

    Mais j’ai quand même dû tout recommencer à zéro une fois, parce qu’il m’avait généré une logique tellement tordue que je ne m’y retrouvais plus.

    Ce que j’ai appris : parler à une IA, c’est un métier

    Ce qui m’a le plus marqué, c’est à quel point la façon dont tu poses la question change tout.

    Si tu dis :
    « Fais-moi un truc pour gérer des icônes »,
    tu obtiens du code générique, verbeux, à moitié cassé.

    Si tu dis :
    « Crée un attribut faIcon de type string, ajoute un SelectControl avec 5 options fixes, affiche l’icône en <i> avec la classe correspondante dans le RichText »,
    là, ça roule.

    Et ça, pour moi, c’est nouveau.
    Avant, coder, c’était : je sais ce que je veux, je le tape.
    Maintenant, c’est : je sais ce que je veux, j’apprends à le formuler pour qu’une IA le fasse.

    C’est presque un exercice de specs en temps réel.
    Et franchement, ça m’a forcé à être plus clair dans ma tête sur ce que je voulais vraiment.

    La structure du plugin : là où l’IA m’a vraiment aidé

    Ce qui est cool, c’est que Windsurf m’a aidé à mettre en place une archi propre dès le début.

    Avant, j’aurais fait un gros index.php, un dossier assets, et je me serais dit « je rangerai plus tard ».
    Jamais fait, évidemment.

    Là, il m’a proposé direct :

    • Un dossier src/blocks pour tout le code React/JSX qui étend les blocs Gutenberg.
    • Un dossier includes pour les CPT et la logique métier.
    • Un build propre avec webpack (enfin… plus ou moins propre, j’ai dû ajuster).
    • Une séparation claire entre ce qui tourne côté éditeur et ce qui se charge côté front.

    C’est pas révolutionnaire.
    Mais c’est exactement ce que j’aurais dû faire depuis le début, et que je faisais jamais par flemme.

    L’IA m’a forcé à être structuré dès le départ, parce qu’elle avait besoin de comprendre où mettre les fichiers.

    Et résultat : mon code est plus maintenable. Plus facile à relire. Moins bordélique.

    Les moments de frustration (parce qu’il y en a)

    Je ne vais pas mentir : il y a eu des phases où j’ai eu envie de tout fermer et de retourner coder comme avant.

    Genre :

    • Quand l’IA me modifiait 4 fichiers alors que je lui avais demandé d’en toucher qu’un.
    • Quand elle « corrigeait » du JSX qui marchait très bien, merci.
    • Quand elle m’inventait des hooks React qui n’existent pas, et que je perdais 20 minutes à comprendre pourquoi ça plantait.

    Il y a aussi ce moment bizarre où tu te rends compte que tu lis plus de code que tu n’en écris.
    Et parfois, ça frustre.
    Parce que coder, c’est pas juste produire du code. C’est aussi réfléchir, tâtonner, trouver des solutions.

    Avec l’IA, tu sautes une partie de ce process.
    Des fois c’est génial.
    Des fois, tu te sens un peu… spectateur.

    Ce que je retiens après deux semaines

    Windsurf, c’est un outil de structure avant tout.
    Il te force à penser ton projet proprement, parce qu’il a besoin de comprendre où il met les pieds.

    C’est aussi un amplificateur de clarté mentale.
    Si tu ne sais pas vraiment ce que tu veux, il va partir en vrille.
    Si tu es clair, il va vite.

    Mais ça reste un assistant, pas un dev.
    Tu ne peux pas lui laisser la main sur tout.
    Surtout si tu fais du React/JSX un peu poussé, ou si tu touches à des trucs sensibles (attributs Gutenberg, save/edit, etc.).

    Le truc à retenir ?
    L’IA produit le squelette. Toi, tu mets la chair.

    Et franchement, pour l’instant, ça me va bien comme ça.

    Et toi, t’en es où ?

    Je suis curieux de savoir si d’autres devs WordPress ont testé ce genre d’outils sur des projets Gutenberg.
    Parce que franchement, entre le JSX, les attributs, le save vs edit, et tout le bordel de la compilation… c’est pas toujours évident de savoir ce qu’on peut déléguer à l’IA et ce qu’il vaut mieux garder sous contrôle.

    Si t’as des retours d’expérience, des prompts qui marchent bien (ou qui partent complètement en couille), ou juste une opinion tranchée sur le fait de coder avec une IA, balance-moi ça.

    Parce qu’au fond, on est tous un peu en train d’apprendre ensemble comment bosser avec ces trucs-là.
    Et autant partager les galères, non ?

  • dimanche 01 février 2026 @ 12:15:02

    J’ai fais le fifou ce week-end ! J’en avais un peu marre des couleurs de mon blog, alors j’ai un tout petit peu rafraîchi tout ça ! Et en prime j’ai utilisé ma couleur préférée #vismavie #osef