Last February, I wrote about productivity and quality: poorly thought-out delegation, the cognitive load on validators, the silent erosion of collective skills. A text built from an organizational perspective, drawing on my conversations with colleagues who ultimately hold roles peripheral…

En février dernier, j’écrivais sur productivité et qualité : la délégation mal pensée, la charge cognitive des validateurs, l’érosion silencieuse des compétences collectives. Un texte construit depuis une perspective organisationnelle à partir de mes discussions avec mes confrères et consoeurs occupant des rôles finalement périphériques au code lui-même. ## Ce que j’avais manqué L’une d’entre elles m’a partagé un article de Siddhant Khare qui lui, a vécu la même réalité, de plus près. Il construit une infrastructure d’agents IA, c’est-à-dire les outils que d’autres ingénieurs utilisent pour faire tourner des IA en production. Et il a quand même fini par se heurter à un mur. Pas un mur de performance. Un mur humain. Son article, “AI fatigue is real and nobody talks about it” (en anglais : je traduirai les citations par la suite), me hante, tant il complète ce que j’avais écrit de façon significative. **NOTE** Ce n’est pas la peine de venir me dire que les IA sont une gabegie écologique et économique, je suis au courant. Je m’intresse au fait que ces outils sont, aujourd’hui, une réalité, et que cette réalité a des conséquences humaines et organisationnelles. On peut parler d’à quel point il est difficile de se passer de cette technologie dans une réalité compétitive où elle est utilisée massivement, tout en sachant qu’elle n’est pas rentable à long terme. Mais ce n’est pas le sujet de ce billet spécifique. ### Le choc des systèmes probabilistes Mon article parlait de la **surcharge cognitive liée à la validation**. Ce que je n’avais pas nommé, c’est une source bien spécifique de cette surcharge : le fait de collaborer avec un système fondamentalement imprévisible, alors que notre cerveau est câblé pour le déterminisme. Siddhant le formule avec une précision que je n’avais pas eue : > Vous interagissez avec un système probabiliste, alors que votre cerveau est programmé pour des systèmes déterministes. Ce décalage est une source constante et latente de stress. Le fait que le modèle ait décidé d’aller dans une autre direction aujourd’hui, que le même prompt produise des résultats différents selon les jours, sans explication accessible, sans log consultable, c’est terrible. Pour quelqu’un dont le métier repose sur la capacité à raisonner sur des systèmes déterministes, c’est une source d’anxiété discrète mais permanente. Alors je sais, ce n’est pas une fatalité. Il existe des moyens de réduire cette variabilité des LLMs, de les rendre plus prévisibles. Mais c’est un travail de longue haleine, et il est facile de sous-estimer à quel point cette imprévisibilité est une source de stress pour les équipes. ### Le tapis roulant des nouveaux outils D’autant que la pression est constante pour rester “à jour” dans un fonctionnement des équipes qui se réinvente chaque semaine, chaque jour. > Je suis tombé dans ce piège sans hésiter. Je passais mes week-ends à évaluer de nouveaux outils. Je lisais chaque note de service. Je regardais chaque démo. J’essayais de rester à la pointe car j’avais une peur bleue d’être à la traîne. Des semaines entières à configurer un nouvel outil, pour le voir dépassé la semaine d’après. Des workflows construits minutieusement, obsolètes en trois mois après une mise à jour du modèle. Siddhant appelle ça le **Knowledge Decay** , la dépréciation du savoir accumulé. J’était passé à côté de ça, mais c’est réel. Ce n’est pas seulement de la fatigue. C’est une **destruction régulière de notre investissement cognitif** , sans garantie de retour. Et cette destruction est systémique, pas individuelle. ### Le piège du “aller, j’essaie encore un truc” Mon article portait sur des dysfonctionnements organisationnels. Siddhant descend à l’échelle du geste de travail quotidien. > Tu avais un objectif clair au départ. Trente minutes plus tard, tu débogues l’invite de commande au lieu de déboguer ton code. Tu optimises tes instructions pour un modèle de langage au lieu de résoudre le problème lui-même. Il appelle ça le **Prompt Spiral** et je serais malhonnête en disant que je ne l’ai pas ressenti. On commence avec un objectif clair. La première réponse est bonne à 70 %. À partir de là, on affine le prompt. La deuxième itération est bonne à 75 %, mais elle a cassé quelque chose que la première avait réussi. Et ainsi de suite. Quarante-cinq minutes plus tard, on a perdu de vue l’objectif initial, on est dans un cercle vicieux, et on n’a pas avancé d’un pouce. Ce que je trouve remarquable dans son texte, c’est que Siddhant ne s’arrête pas au diagnostic. Il propose des règles concrètes, issues de sa propre expérience : trois tentatives maximum, puis on écrit soi-même ; des sessions limitées à trente minutes. La première heure du matin sans IA, pour “échauffer” sa propre pensée avant de déléguer quoi que ce soit. Il y a quelque chose de tristement fascinant à voir à quel point ces règles sont devenues nécessaires à une bonne hygiène mentale, et à quel point elles sont difficiles à respecter. **Mon article s’adressait aux managers et aux organisations. Le sien s’adresse aux praticien·nes, directement.** Ce n’est pas la même altitude. Les deux sont nécessaires. Les deux sont terribles. Bref, je vous invite à lire “AI fatigue is real and nobody talks about it” parce qu’il le complète tout ce que j’avais laissé de côté : l’anxiété du déterministe face au probabiliste, l’épuisement de la veille permanente, les micro-décisions qui s’accumulent jusqu’au burn-out. Et si vous avez vécu ce qu’il décrit, sachez que vous n’êtes pas seul·e. Et que ce n’est pas une question de compétence ou de discipline. Ce que nous vivons, ce qui est imposé aujourd’hui par le marché est dur, et aura des conséquences notables sur notre santé mentale, notre capacité à faire du bon travail, et notre plaisir à faire ce métier. Et ce, même si la bulle éclate. ## Je suis tombé par terre… 🎶 Entre deux articles s’interrogeant sur le **comment** (comment mieux utiliser ces outils, comment réorganiser les processus, comment préserver sa santé mentale), j’ai aussi récemment lu un autre texte qui, lui, pose une question différente : celle du **pourquoi**. Mon article et celui de Siddhant analysent des **effets** : surcharge, érosion des compétences, fatigue individuelle et collective. Nous décrivons ce qui se passe sur le pont du navire. “Programming Still Sucks”, de Steven Langbroek, décrit comment le navire a été construit, qui a décidé de jeter le manuel par-dessus bord, et qui a signé la liste des postes supprimés en se convainquant que “les juniors s’adapteront” (indice : non). > L’IA n’a pas volé nos emplois. C’est la cupidité qui l’a fait. Cette même cupidité qui a délocalisé les usines au Bangladesh et qui maintient l’exploitation des mineurs de cobalt au Congo sous un nouveau masque. Le texte est plus littéraire, plus politique, délibérément plus en colère (autant dire que je l’aime). C’est une excellente illustration de ce que l’obsession productive à court terme détruit sans le voir, sans même savoir ce qu’elle détruit. Là où mon article demande “comment mieux déléguer ?” et celui de Siddhant demande “comment survivre à ce rythme ?”, ce troisième texte demande : **qui a décidé que c’était acceptable, et pourquoi ?** Le tableau est assez complet, et malheureusement assez sombre. ## Et malheureusement, nous avons raison Histoire d’enfoncer le clou, une dernière lecture : la note de conjoncture de l’INSEE pour mars 2026, intitulée “Éclairage – Avec l’essor de l’intelligence artificielle générative, l’investissement numérique tire davantage la croissance aux États-Unis qu’en France, tandis que l’emploi recule dans les activités informatiques des deux côtés de l’Atlantique”. On y lit notamment que : > En particulier, les indicateurs sectoriels suggèrent un retournement de l’emploi depuis deux ans dans les segments les plus exposés, notamment dans les activités de programmation informatique, et pour lesquels la valeur ajoutée est orientée à la hausse, aux États-Unis comme en France. En outre, dans les deux pays, l’ajustement de l’emploi de ce secteur serait concentré sur les jeunes entrants. “Retournement de l’emploi”, au cas où vous ne seriez pas sûr de ce que ça veut dire, c’est une façon élégante de dire que des emplois sont détruits. C’est explicité plus loin dans la légende d’un graphique : > L’emploi dans le secteur des activités informatiques et des services d’information a baissé de 3,0 % entre le quatrième trimestre 2023 et le quatrième trimestre 2025. La contribution des 15-29 ans (hors alternants) a été de -3,8 points, contre +1,4 point pour les 30-54 ans. Car dans ce contexte difficile, les plus âgé·es, qui sont en mesure de puiser dans leur expérience pour prendre le nécessaire recul émotionnel dont nous parlons tous·tes, sont plus à même de faire face à la situation (enfin, en tout cas, d’y faire face le moins mal). Les jeunes, eux, sont plus vulnérables. Ils n’ont pas encore eu le temps de construire une carrière, de développer des compétences transférables, de se forger une expérience qui les rendrait plus résilient·es face à ce genre de choc. Bref, les chiffres sont là, et ils ne sont pas bons. Nous avons raison d’être inquiet·es. Nous avons raison de nous sentir fatigué·es. Nous avons raison de nous demander comment nous allons faire pour continuer à faire du bon travail dans ces conditions. * * * Vous êtes abonné·e au flux des articles : * rédigés en français. Si vous voulez uniquement suivre les articles en rapport avec le Web, vous préférerez sûrement suivre ce flux.

Refs #334. This is the smallest patch I could reduce the build to in order to produce a working ImageOptim.app on Apple Silicon under the current toolchain (tested on Xcode 26.4.1, macOS 26.4.1). E...

This document defines an API that web page authors can use to detect presence of "long animation frames" that monopolize the UI thread for extended periods of time and block other critical tasks from being executed - e.g. reacting to user input.

HTML isn't only for people working in the tech field. It's for everyone. Learn how to make a website from scratch in this beginner friendly web book.

Few things are more annoying than losing your progress halfway through a form. Maybe the browser crashes. Maybe the tab gets closed. Maybe your kid yells from the other room and you come back three hours later wondering why you ever thought now was a good time to fill out a mortgage application. Whatever the cause, `form-saver` makes those interruptions a lot less obnoxious. Which is nice, because forms are usually annoying enough on their own. At its core, `form-saver` is a small web component that wraps a form, keeps an eye on it, stores values in `localStorage`, and restores them when the page loads again. Better yet, it clears out saved data after a successful submission so you’re not accidentally resurrecting stale information the next time someone stops by. Nobody wants yesterday’s half-finished support request shambling back to life. ## # Basic usage All you need to do is wrap your form in the component: <form-saver> <form action="/contact" method="post"> <label> Name <input name="name" autocomplete="name" /> </label> <label> Email <input name="email" type="email" autocomplete="email" /> </label> <label> Message <textarea name="message"></textarea> </label> <button type="submit">Send</button> </form> </form-saver> That’s it. The component targets the first descendant `form`, saves values as users type or make changes, and restores them when they come back. No extra plumbing. Just a form with a slightly better memory than most of us have before coffee — depending on the day, that may not be a terribly high bar, but still. This is especially handy for forms that are a little more involved than a simple email signup. Job applications, checkout flows, support requests, and multi-question onboarding forms all benefit from a little resilience. So do the people filling them out, who generally have better things to do than retype the same answers because a tab got squirrelly. ## # What actually gets saved? `form-saver` supports the controls most of us reach for every day: * Text-style `input` fields * `textarea` elements, * `select` elements (including multi-selects), and * `checkbox` and `radio` controls. File inputs are intentionally excluded. Because the component works in light DOM, your form remains your form. Your labels, validation, layout, and CSS continue to work exactly as they did before. `form-saver` just adds a bit of memory and, ideally, cuts down on a few muttered curses. ## # Want to keep a few fields after submit? In many cases, clearing everything after a successful submission is the right call. Sometimes, though, it makes sense to keep a few details around. Maybe you want to preserve a visitor’s name and email address on a contact form while clearing the message body. That way they do not have to keep retyping the boring bits. Nobody wakes up excited to enter their email address for the fourth time. That is what the `retain` attribute is for: <form-saver retain="name email"> <form action="/contact" method="post"> … </form> </form-saver> After a successful submission, `name` and `email` stick around, but `message` gets cleared. Simple, sensible, and less likely to leave someone staring at your form like it just betrayed them personally. ## # Better yet, let users decide Persisting form data can be incredibly helpful, but there is a human side to this too. Just because we _can_ keep someone’s information around does not necessarily mean we _should_ do it without asking. That is where `retain-choice` comes in. It lets you be useful without getting presumptuous. Add it alongside `retain` and `form-saver` will inject an opt-in checkbox for the user. Nice and easy: <form-saver retain="name email" retain-choice retain-choice-label="Store my contact information for later" > <form action="/contact" method="post"> … </form> </form-saver> By default, that checkbox is inserted just before the first submit control. If the user leaves it unchecked, the retained fields are cleared along with everything else after submit. If they opt in, those selected fields remain. Their call, as it should be. Gotta love a little informed consent. Need to place that control somewhere more appropriate in your layout? Use `retain-choice-container` to point to a CSS selector: <form-saver retain="name email" retain-choice retain-choice-label="Remember my details next time" retain-choice-container=".form-footer" > <form action="/contact" method="post"> … <div class="form-footer"> <button type="submit">Send</button> </div> </form> </form-saver> That gives you a lot more control over the experience without making you build the retention UI yourself. ## # Need a custom storage key? By default, `form-saver` derives its storage key from the wrapped form’s method and action, which is usually exactly what you want. It keeps different forms from stepping on one another and keeps the setup nice and boring. Boring is good. If you need something more explicit, you can provide your own `storage-key`: <form-saver storage-key="checkout:shipping-address"> <form action="/checkout/shipping" method="post"> <label> Street Address <input name="street-address" autocomplete="street-address" /> </label> <label> Postal Code <input name="postal-code" autocomplete="postal-code" /> </label> <button type="submit">Continue</button> </form> </form-saver> This is useful when a form’s URL is not stable or when you want multiple views to intentionally share the same saved state. Sometimes explicit is just easier. Sometimes it is the only way to stay sane. ## # Want to drive it yourself? If you need more direct control, the component exposes a few methods: const saver = document.querySelector("form-saver"); // Persist the current state saver.saveFormState(); // Restore previously saved values saver.restoreFormState(); // Clear out anything stored for this form saver.clearSavedData(); That can be useful when you want to pair it with your own UI, analytics, or some custom workflow around save and restore. Or when you just like being the one driving and do not fully trust anything labeled “automatic.” ## # Progressive enhancement, as usual This component follows a pattern I am always going to favor: start with a perfectly ordinary form, then layer on the enhancement. If JavaScript fails, the form still works. Users can still fill it out and submit it. They just will not get the recovery behavior. Annoying, perhaps, but not catastrophic. And that is very much the point. That’s a pretty good trade-off. And because saved values are only cleared after a successful submit flow, you do not lose everything just because client-side validation blocked submission or some other script got clever at exactly the wrong moment. That matters. A lot of “smart” form experiences are only smart right up until they are not. ## # Demo If you want to kick the tires, I put together a live demo with examples of the retention options as well: ## # Grab it The project is available on GitHub, and you can install it from npm: npm install @aarongustafson/form-saver If you want the easiest path, just import it and let the component register itself: import "@aarongustafson/form-saver"; If you would rather define it yourself, you can import the class directly: import { FormSaverElement } from "@aarongustafson/form-saver/form-saver.js"; customElements.define("form-saver", FormSaverElement); Either way, you wind up with a more forgiving form experience and a little less needless frustration for the people filling it out. Which, in my book, is a pretty solid deal. The bar for delight in forms is often just “don’t make me do that again,” and honestly, I’ll take it.

Currently, when it comes to being an accessibility specialist - particularly in Europe -, you mostly have two options: * either join a Consulting company, where you'll most of the time be running compliance audits, * or be a freelancer. Rarely will you find companies that will hire Accessibility specialists within their ranks. Why? Simply because, Accessibility is not something currently seen as that people should or must do. They only see it as a hindrance, something that will slow them down in their business. Indeed, companies still do not consider how important it is for their websites and applications to be accessible for ALL users, including people with disabilities. They don't see the fact that those people need this access as much as the rest of the population, for the same reasons as anyone, as well as sometimes, because it'd be their only way to access the information, the product or the service. And I hate using this argument, but they don't see either the fact that it would increase their market shares, their revenue, their brand. In addition, the European law is only slowly evolving such that, to date: * only private companies with over 250 million revenue * and more recently, companies selling products and services online for a specific range of domains1 will be required to make their websites and applications accessible. This last obligation just came out in June 2025. And for now, what almost all companies have done in preparation for this law, was to publish an accessibility statement - because it's one of the requirements of this law. Barely any actually started on the accessibility of their website. * these laws do not cover a big chunk of the sites and applications existing on the web. Although that's not the initial topic of this post, there is a link: because there are still a lot of companies which websites and applications are not covered by the law, accessibility is not seen as a necessity, nor as something mandatory. When European Companies had to comply with the GDPR law, it was ALL companies at once, so they did recognise it as mandatory and as a necessity for users (or at least that's what they are saying). Because they recognised quickly this was a technical domain they knew nothing about and this was something that would last in the long run, they were very quick to hire experts on the subject for many, within less than a year. For accessibility, they turn to consulting companies or independent accessibility specialists. Indeed, if you wish to make a website or application accessible, you need the people building it to be, at the minimum, trained for it (and yes, all teams will need to be trained!), as well as, people specialised in the topic. Let's say your company trains their teams on accessibility. It's a good start: they will be able to apply what they learned to their day to day jobs. But, as accessibility is not their domain of expertise (development or design or project/program management is their expertise), you will also need to ensure that what they produced is indeed accessible. Also, there will, for sure, be cases where they will be stuck, not being sure of how to build the component they are designing/developing so it is indeed accessible. Not just compliant! Accessible, as in usable for users with disabilities as well as for all other users. It is key to remember that Accessibility is not a one off it's a continuity. Your websites or applications evolve on a daily basis, with constant updates releases, regular partial or full revamping or replatforming. At the same time as your website or application will change, you must ensure all those changes remain accessible. Having a Accessibility consultant working with your teams will help your teams work on their accessibility... for the time of his/her mission, at the least. This consultant may not be working full time within your company, only 2 or 3 days of the week. This means that the rest of the week, your employees do not have anyone to refer to for questions or help. Also what happens when their mission is over? (because time of missions are limited and consulting companies don't like to keep one consultant working for one company for too long) Of course, you could always get another consultant to replace the first one, but this implies periods of time where there won't be a specialist to assist your teams. Also, with every new consultant, you'll have to get them acquainted with your team, your product/website/application, your processes, etc. This takes time. Time during which the consultant will have difficulties providing the appropriate help to your teams. In my opinion, working with consultants should really be a matter of punctual missions on specific topics. For example to run the annual audit of your website and help update your accessibility statement, or to help on a specific subject in Accessibility where they may have a defined speciality, like for example to advise on the strategy of making a Design System accessible, or on Data Visualisation, or on MathML... In addition, it would be much more interesting for the specialised accessibility consultant! Indeed, as an accessibility consultant, you want to be able to provide a service that won't be always the same. Your mind wants something picking your interest, your curiosity, that feeds your need to resolve complex maters. Of course through all these arguments, I prone the fact that companies should hire in-house accessibility specialists that will be able to support your teams in the long term, knowing full well the processes, strategies, intricacies, politics, and website/product/application of the company. ## Footnotes 1. Domains are: * E-commerce and online services * Banking services * Air travel and other passenger transport (excluding government-run transport) * Media streaming and telephony * Computers and mobile devices (devices and softwares) * Shops and restaurants (point of sales services, self-service devices, kiosks) ↩ Retour au texte 1

How can we balance increased productivity through tools like LLMs with maintaining high quality? This is a question I’ve been asking myself for a while, and I think we’re at a critical turning point.

A quick update on my team's work to bring video and audio lazy loading to browsers today

Réseau professionnel minimaliste, sans tracking, respectueux de votre vie privée. Conforme RGPD.

This specification defines the QUERY method for HTTP. A QUERY requests that the request target process the enclosed content in a safe and idempotent manner and then respond with the result of that processing. This is similar to POST requests but can be automatically repeated or restarted without concern for partial state changes.