22 Aug 2026
Planet Grep
Steven Wittens: Curvature Beziers
Improving on a timeless recipe
The bezier curve is a staple of CAD and computer graphics. Like Bic pens, the design is decades old and they're everywhere. You'll often find them as the default or only choice in various illustration and animation tools.
Conceived by Paul de Casteljau in 1959, and refined by Pierre Bézier in the 1960s at Renault, the enduring appeal of the bezier curve lies in its simplicity. While more sophisticated curves have been invented, and new ones continue to be proposed, these are limited to specific domains, like high-precision CAD or road design. In general use, the bezier stubbornly refuses to be dethroned, despite its shortcomings.
Hence bezier curves are a piece of legacy tech we appear to be stuck with. As a software engineer, my question then is: can we make beziers better without invalidating all the tech built on and with them?
The answer is yes.
Lerp-a-derp
Drawing a bezier curve is a surprisingly simple and linear process:
Tip: All the diagrams in this post are fully interactive.
Given a series of control points, we connect them with lines. We then run along those lines simultaneously, to produce new points, which can be connected again. This process is repeated until we are left with a single point, which lies on the curve.
This construction makes beziers far more regular than they might first appear.
The linear interpolations (aka lerps) can be summarized into a single compact formula, e.g. for 4 control points $ \left(A, B, C, D\right) $:
The rule is simple: descending powers of $\left(1 - t\right)$, ascending powers of $t$, with coefficients taken from the n'th row of Pascal's triangle:
For curves in 2D and 3D, the formula is applied to the individual X, Y or Z coordinates.
While beziers can be constructed for any number of control points, the common practice is to only use cubic beziers with 4 control points. This is because the curve is only guaranteed to cross through the first and last control point, which makes higher degree beziers more difficult to shape.
Larger curves are instead constructed by joining together multiple cubic bezier segments, with the tangents lined up to create a segmented curve that appears smooth:
This is the cubic bezier spline, as commonly understood. The precision "pen tool" in most drawing apps then consists of drawing and editing the control points, rather than drawing curves directly.
A Lie Told Everywhere
Pen tools typically have a few different modes for the control points:
Intuitively these represent various degrees of smoothness. Symmetric tangents are offered as the smoothest option, with some qualities of smoothness being lost as you relax the constraints.
In reality this is completely wrong, and this is easy to demonstrate.
Bezier curves can be split exactly, by reading off the new control points from the interpolation diagram:
The left and right segments are 100% identical to the original curve, and always join up perfectly at the seam. Yet the tangents in the middle will be asymmetric except for one split near the middle. This can be confirmed using a curvature comb which represents the (inverse) radius of curvature at every point:
The curvature comb remains continuous, with no jumps.
This means that whether or not adjacent tangents are of equal length, i.e. symmetric, is completely irrelevant. Attempting to draw smooth and intuitive bezier curves this way is a fool's errand.
A simple way to improve this is to treat the tangents as relative rather than absolute. e.g. We can make them proportional to the distance between the start and end of each segment:
This spline is easier to edit, because as you move each curve point around, the adjacent segments naturally flex to get out of the way. There are far fewer cusps created this way. Editing the tangents remains the same.
However if we plot curvature again, we can tell this isn't a great solution:
Scaling tangents proportionally doesn't guarantee that curvature is preserved as you edit, nor does curvature remain continuous from one segment to the next.
This also shows that offering users a curvature comb visualization as a "helpful tool" is really quite mean: adjusting the curvature on one end will also affect the other side, requiring repeated adjustments back and forth until it's close enough.
Handle Carefully
A much more effective strategy is to work with curvature directly.
While this is a difficult problem in general, it turns out there are some surprising relationships here, which we can observe directly:
Consider the curvature at the start of segment $A-B-C-D$. This is affected only by the positions of $A$, $B$ and $C$. Point $D$ can be moved freely if it's detached from $C$.
Furthermore, because the tangent $A-B$ is horizontal, only the vertical position of $C$ matters. This is a result of the underlying linear interpolations, which end up cancelling out a lot of terms in the formulas.
The curvature at $A$ is therefor only affected by the length of $A-B$, and the perpendicular distance from $C$ to $A-B$. The same applies to $D$ on the other side with $C-D$ and $B$.
This isn't very useful by itself though. When we move a curve point ($A$ or $D$), typically the adjacent control point ($B$ or $C$) is moved as well to preserve the tangent. And when we turn a symmetric or asymmetric tangent, the adjacent tangent in the next segment is turned by the same angle, altering the curvature on that side.
Still, this shows that preserving curvature is not by itself a crazy idea and can be done simply by scaling the tangents appropriately. The rules would be simple:
-
When we move a curve point, we have to preserve the start and end curvature in the adjacent segments
-
When we move a tangent, we have to preserve the curvature on the opposite end of the current segment, as well as on both sides of the adjacent segment
This ought to produce an editing experience where the curve actually respects your intent. Except not quite:
Moving curve points works great, but when turning a tangent, the length of that tangent is itself a poor representation of the user's intent. Small changes can cause huge shifts in curvature, which can cause the curve to jump around and explode unexpectedly as it tries to find a matching solution.
Hence it's better to work with curvature handles instead, where the length corresponds directly to curvature:
Unlike the curvature comb, the length of the handles is the non-inverted radius of curvature, which is the more natural choice.
These handles are very stable and can be converted just-in-time to classic bezier control points, without needing to round-trip back and forth between the two representations. Helpfully, this also avoids numerical drift.
Goldilocks
To actually pull this off, we need to solve for the lengths $l_0$ and $l_1$ of the tangents, given the desired curvatures $k_0$ and $k_1$, the start/end points $A$ and $D$, and the unit-length tangents at the start/end.
Given a curve $\gamma\left(t\right)$, we can express the unit tangent vector $\mathbf{T}\left(t\right)$ as the normalized derivative:
This can be used to find the curvature vector $\mathbf{K}\left(t\right)$ via two vector cross products using the first and second derivative:
The cross products ensure that $\mathbf{K}\left(t\right)$ is perpendicular to $\mathbf{T}\left(t\right)$, i.e. they extract the normal vector component of the middle term. Now we can solve for $\mathbf{K}\left(0\right) = k_0$ and $\mathbf{K}\left(1\right) = k_1$.
After working through the math, we end up with a quadratic system of equations in $l_0$ and $l_1$:
Where:
This captures a few things:
-
The sign of the curvature $k_i$ defines whether the curve turns clockwise or counterclockwise. When moving curve points around, the curve may be forced to flip, hence the $±$ is necessary, and both signs can change independently.
-
The coupling between $l_0$ and $l_1$ is influenced only by $b$. If $b = 0$, then the two equations are independent and the problem is trivial to solve. This corresponds to the situation where the two tangents are parallel.
-
The constant term $c_i$ is influenced only by the perpendicular distance $D - A$ (or $A - D$) to the tangent $\mathbf{T_i}$. This matches the earlier finding that only perpendicular distance affects curvature.
Hence, the problem is reduced to finding the intersection of two double-parabolas, one horizontal and one vertical:
The two sides of each double-parabola represent bending clockwise or counterclockwise. We have to solve 4 times, one for each sign combination $\left(+,+\right)$, $\left(+,-\right)$, $\left(-,+\right)$, $\left(-,-\right)$.
To solve this system, we can rewrite either of the equations to isolate $l_1$ or $l_0$:
Pick one, and square it to plug it into the other original equation as the $l_1^2$ or $l_0^2$ term. This produces a quartic equation in the other variable (resp. $l_0$ or $l_1$), which can be solved directly using the quartic formula.
We can then compute the other $l_i$, either:
Not all solutions of the quartic will be actual solutions to the system however, because of the squaring. So we have to double check that the original equations hold before accepting a solution for $\left(l_0, l_1\right)$.
We also want to reject solutions where $l_0 < 0$ or $l_1 < 0$, because these represent situations where the tangents have been flipped by 180º.
In most cases, there will only be one valid solution, and this works pretty well:
For corner-type points, one or both $k_i$'s are infinite. This is straightforward to solve as the matching $l_i$ is zero and the other can be computed directly.
Grouper and Snapper
Unfortunately if there are multiple solutions, these each represent a different curve:
Having the curve jump around as you edit it would be a very bad editing experience, but there is no obvious way to pick the right one.
One strategy would be to remember the previous $l_0$ and $l_1$ as you edit, and pick the solution that is closest to the previous curve. However this would introduce path-dependence into editing, where the order and direction that you moved points around in affects which curve you end up with. For a drawing tool, this is quite frustrating and undesirable.
Different solutions to the equation can also appear and vanish suddenly, so this wouldn't eliminate popping either, merely reduce it.
Ideally the resulting curvatures should always change smoothly themselves. This can be accomplished by designing an appropriate weighting heuristic for the solutions, and calculating their weighted average.
1) The forbidden regions:
When a solution approaches either $l_0 0$ or $l_1 0$, it's about to vanish, so its weight should go to zero there.
2) When two opposite-bending parabolas are about to become tangent, two solutions will move towards each other, before both vanishing at the same time:
These solutions are unstable and should be avoided. To detect this, I calculate the gradient vector of each equation.
The angle between them can be found via their dot product, after dividing by their respective lengths:
A value close to $-1$ means two opposite-bending parabolas, while a value close to $1$ means two aligned parabolas. The latter is not as bad, as this implies many almost-equivalent solutions.
3) When the radius of curvature is very big compared to the bezier itself, one of the possible solutions is for the curve to cross through itself, forming a loop. This should be discouraged:
We can divide by the length of $|\mathbf{l}|$ i.e. $\sqrt{l_0^2 + l_1^2}$, preferring solutions that have shorter tangents.
Putting it all together, the weighting heuristic I chose is:
-
By applying $\arccos \left(-\cos \theta\right)$, we remap the dot-product range $(-1..1)$ to $(0..π)$ which effectively neutralizes the unstable solutions
-
Large $|\mathbf{l}|$'s represent undesirable solutions, so should be strongly penalized and only chosen if they are the only option
-
When the entire heuristic approaches $0$, the influence should vanish smoothly, hence the overall squaring
Using this as the weight, the resulting bezier curves always change smoothly, even when the start and end are moved around and through each other.
But when multiple solutions are averaged together, the resulting $(l_0, l_1)$ is not necessarily a solution to the original system. This means the resulting curvatures are not always exact, even when there is an exact solution nearby.
To mitigate this, we can add an additional resampling step, where we re-weigh the solutions according to the inverse distance^4 to the weighted average:
This causes the solution to snap smoothly to exact solutions when available.
Migratory Curves
What's especially nice about this approach is that it can largely be slotted into existing systems with little modification required.
The UI of adjusting and editing bezier handles can be kept, including the notion of the 4 point types. Just the meaning of the lengths of the tangents changes. Converting an asymmetric point to a symmetric point will actually equalize the curvature of the left and right side, which is what the user actually wants.
The internal representation can mostly remain the same type, i.e. a series of points, just those points represent curvature tangents, not bezier tangents. Though it's better to explicitly store the unit length tangents and curvatures directly, which is more numerically stable. For the demos here I made pairwise conversion functions between curvature handles ↔︎ points/tangents/curvatures ↔︎ bezier handles.
Splitting a curvature bezier is a lot simpler than splitting a classic bezier, because the start and end handles don't change at all, and the newly created handles are symmetric:
There is one remaining flaw though. When splitting a curve with an S-bend, the splits near the bend are not exact:
The heuristic picks the wrong curve on one or both sides. This can be fixed by remembering the specific orientation of the curvature, and only flipping the curvature sign when necessary. Though this does introduce some minimal path-dependence into editing.
So really you would need to expose this in the UI as an extra orientation toggle for ambiguous control points. It would also mean that the internal representation has to be in tangent + signed curvature form to be fully stable, not just curvature handles.
Near the S-bend, the radius of curvature-and thus the handle size-effectively becomes infinite, because $|k|$ becomes $0$. The bezier control points lie on a straight line, as perpendicular distance to the tangent is zero.
So even when handled exactly, this can still create impractically large curvature handles. Perhaps what's needed is a 5th "Inflection" point type, for points with exactly zero $|k|$, though such points tend to be very unstable, and sometimes no solution exists:
To migrate a classic bezier to a curvature bezier, you can measure the unit tangents and curvature at the start and end. In the vast majority of cases this will result in the exact same curve. If it doesn't, then you must split the original bezier to avoid the ambiguity.
For complex operations on bezier curves, e.g. boolean union or intersection, these still have to be done in bezier form. This implies some amount of round-tripping between the two representations, which would introduce numerical drift. However, only the newly created points need to be converted back, because the curvature and tangents elsewhere remain the same.
* * *
This post started from the observation that "symmetric" bezier tangents aren't actually symmetric as you'd expect. Hopefully you found the resulting exploration enlightening.
The practice of showing curvature combs to diagnose problems with splines is really backwards. If we can show a curvature comb, we can also compute an appropriate spline to match the desired curvature.
So beziers as they commonly exist are quite inadequate. We can retrofit a better system to edit them without breaking the expectations of a smooth editing experience, or introducing a new class of curves that behaves very differently.
The code for the diagrams and implementation can be found on GitLab.
22 Aug 2026 8:03pm GMT
Mattias Geniar: PWAs: Personal Web Apps
I've found my ideal format for shipping apps for personal & family use: PWAs, with an offline-first focus, rendering (mostly) entirely client-side. JavaScript is powerful enough to do pretty much anything these days - especially if you don't have to write the code yourself.
22 Aug 2026 8:03pm GMT
Mattias Geniar: Deduplicating git worktrees on EXT4 with jdupes
A git worktree workflow eats a lot more disk than you'd expect. On the remote box I run my coding agents on , ten worktrees took a 28 GB volume down to 687 MB free in about a day. Here's one way to limit that.
22 Aug 2026 8:03pm GMT
Lionel Dricot: Un manifeste Offpunk
Un manifeste Offpunk
Ce texte est une traduction en français du Offpunk Manifesto rédigé par Arlon de Serra Grande et que j'ai co-signé
La révolution ne sera pas numérique
Alors que l'hyperconnexion apparait comme le symptôme d'un futur inéluctable, un timide mouvement semble prendre de l'ampleur : celui de la déconnexion volontaire et intentionnelle. L'adoption des « dumb phones » est en train de croître. Les appareils photo numériques font leur retour. Tout comme les cassettes audio et les machines à écrire… Il existe un mouvement pour se réabonner à la presse papier. Même le minidisc, vite oublié après le succès des lecteurs MP3, semble renaître de ses cendres.
Au début du siècle, Internet semblait être la dernière pièce pour mettre en place le fameux « village global » de Marshall McLuhan. Les ordinateurs, rares et chers (et donc parfois partagés) étaient des portails vers un autre monde. Les gouvernements consacraient beaucoup d'argent pour s'assurer que même les plus pauvres ne soient pas des exclus numériques.
Et nous y sommes arrivés ! Nous allons bientôt passer le cap de trois appareils connectés par humain, selon l'estimation du Cisco Visual Network 2020.
Le numérique est partout et considéré comme acquis. Que nous le voulions ou non, nous sommes tous connectés en permanence. Car nous ne nous connectons plus à Internet : nous y vivons sans plus jamais le quitter !
Comme si nous portions un uniforme, nous gardons toutes et tous notre téléphone dans notre poche pour travailler, pour vivre, pour aimer et sous l'oreiller pour dormir.
Le numérique a cessé d'être un outil pour devenir un environnement duquel on ne peut s'échapper. Autrement dit une prison.
« Préserver le non numérique n'est pas un retour vers le passé, c'est un devoir »
- Giulio Cavalli
Lorsque la connexion, même non nécessaire, devient obligatoire, la résistance ne consiste pas à détourner le système, mais bien à refuser tout simplement d'en faire partie.
Comme l'écrit l'auteur belge de science-fiction et développeur informatique Ploum, les punks de notre époque sont ceux qui osent vivre sans smartphone. Ce sont des « offpunks », comme je les appelle désormais.
La connexion est une arme de guerre
La première conséquence de cette centralisation monopolistique de la technologie est que la fourniture d'un accès à Internet est devenue une arme de guerre. Lorsque les grandes puissances entrent dans un conflit, elles ne cherchent plus seulement à perturber l'approvisionnement en eau ou en énergie, mais également à couper l'accès à Internet ou à certains services en ligne. La Russie a utilisé plusieurs fois cette tactique contre l'Ukraine. Israël fait de même contre la Palestine.
Fin 2025, le juge français Nicolas Guillou de la Cour Pénale Internationale a perdu ses accès à plusieurs services en ligne américains, dont Airbnb, Amazon et Paypal. La justification de cette sanction prise par les États-Unis était que Nicolas Guillou avait signé un mandat d'arrêt contre le Premier ministre israélien Benjamin Netanyahu et son ministre de la défense Yoav Gallant, suite au caractère génocidaire des attaques israéliennes contre les territoires palestiniens. Les États-Unis sont pourtant l'un des seuls pays à soutenir les actions d'Israël au Proche-Orient.
La philosophie Offpunk est née de constatations simples, mais inconfortables : le monde numérique est fragile et notre vie sociale est intrinsèquement liée à notre environnement. Le corollaire évident est que nous ne devrions jamais dépendre entièrement de services propriétaires virtuels, car nous pouvons en être exclus sans préavis.
De nombreux exemples illustrent notre dépendance envers cette fragile infrastructure : le bug Microsoft qui a mis hors service des milliers de banques, de transports et de services critiques en 2024, le gouvernement brésilien qui a bloqué Twitter/X en 2024 ou la panne globale d'Amazon et Cloudfare qui a rendu une bonne partie des sites web injoignables fin 2025.
Lorsqu'un système est injoignable, que ce soit à cause d'une panne, d'une sanction politique ou d'une guerre, tout un univers virtuel disparaît purement et simplement. Vous n'avez aucun recours si le numérique connecté était votre seule option.
Après tout, une connexion permanente à haut débit n'est jamais garantie, spécialement dans les pays en voie de développement ou qui connaissent des troubles politiques. Même les pays riches et industrialisés ne sont pas à l'abri. À cause de sa politique de gestion de l'énergie, la ville de Sao Paulo, au Brésil, connait des coupures d'électricité fréquentes lorsqu'il pleut.
Dans ces pays, avoir un plan B « analogique » est une question de survie.
Le minimalisme numérique et l'Offpunk
Il ne faut pas confondre le mouvement « Offpunk » et le minimalisme numérique.
Le minimalisme numérique est une vision individuelle et autonome de la déconnexion, sans aucune remise en question des tendances sociétales et des structures de pouvoir.
Puisqu'une vie complètement déconnectée n'est plus possible, le minimalisme numérique tente de supprimer les aspects les plus addictifs et les plus envahissants de la connexion permanente.
Off, ma non troppo.
Mais ce dont nous avons réellement besoin c'est d'une possibilité de se déconnecter réellement, d'avoir le droit de vivre et de nous déplacer sans emporter avec soi un téléphone suffisamment récent, suffisamment chargé et avec un forfait suffisant pour être connecté 24h sur 24.
Dans "Digital Detox: The Politics of Disconnecting" (2020), Trine Syvertsen démontre comment la mouvance du minimalisme numérique contribue à un agenda néo-libéral qui fait endosser par les individus, comme l'utilisateur lambda d'un smartphone, la responsabilité de résoudre les problèmes structurels auparavant gérés par des institutions collectives. L'autrice identifie trois raisons principales qui motivent le minimalisme numérique, les 3 « P » : présence, productivité et vie privée. Les trois étant des motivations purement individuelles.
En d'autres termes, si vous avez l'impression de rater des moments importants de sociabilité, si vous n'êtes pas productifs dans votre travail ou vos projets à cause des notifications ou si vous n'aimez pas être espionné en permanence par les grands monopoles de la tech, c'est uniquement de votre faute, car vous n'avez pas assez d'autodiscipline. Ce n'est en rien lié à l'économie de l'attention, au capitalisme de surveillance et aux logiciels conçus pour être addictifs.
Ce déchargement de la responsabilité fait notamment partie de l'analyse de la société contemporaine par l'intellectuel germano-coréen Byung-CHul Han dans son livre « The Agony of Eros ». Il y dit notamment :
L'auto-exploitation est bien plus efficace que l'exploitation par d'autres, car elle donne une impression de liberté.
Un autre symptôme de ce déchargement des responsabilités sont les caisses automatiques et les distributeurs en libre-service dans les supermarchés, les banques voire les pharmacies. Le client doit désormais faire le travail des employés, le plus souvent sans aucune aide et pourtant sans payer moins cher. S'il y a une erreur dans le processus, c'est de toute façon le compte en banque du client qui sera débité, pas celui de l'entreprise.
Bien qu'initialement issue d'une tendance technophile, la mouvance Offpunk, au contraire du minimalisme numérique, promeut une déconnexion simple et sans prétention. Une déconnexion non excluante des activités sociales ou de l'exercice de ses droits de citoyen·ne·s.
Quand le minimalisme numérique voit la détox numérique comme un outil d'amélioration de la productivité, les offpunks envisagent la déconnexion comme une attitude anti-consumériste.
Définitions
Le mouvement Offpunk n'est pas un style de vie, c'est un positionnement par rapport à notre usage du numérique, une forme de quête de sevrage numérique collective qui explore les impacts sociaux et politiques de la déconnexion. Le mouvement tente de permettre aux individus de se réapproprier leurs loisirs, leur citoyenneté et leurs communications sans passer par un intermédiaire numérique incontournable. L'Offpunk ne s'oppose nullement à Internet ou à la technologie, il cherche juste à rendre possible une vie sans connexion permanente.
Dans son positionnement, Offpunk se rapproche plus des méthodes non dogmatiques comme la méditation ou les techniques de guérilla.
De plus, il est particulièrement remarquable que même les activités professionnelles traditionnellement analogiques, comme l'enseignement, soient de plus en plus envahies par le numérique. L'utilisation d'Internet est de plus en plus liée au travail et le terme même de « déconnexion » implique le loisir ou l'oisiveté.
En conséquence de quoi, la philosophie Offpunk défend le fait de vivre sa vie au sens large, au-delà de la séparation travail/vie privée.
Paradoxalement, toutes ces couches inutiles numériques dans notre vie quotidienne rendent l'interaction analogique et directe de plus en plus efficace ou confortable pour résoudre nos problèmes du quotidien (voir aussi la section « Instruments Offpunk »).
Offpunk embrasse autant l'adolescent qui achète un téléphone basique et rejoint un club luddite, un audiophile qui quitte Spotify pour se créer une collection de vinyles ou un lecteur MP3 hors-ligne, un expert qui utilise des systèmes de cybersécurité minimalistes. Le mouvement comprend également les militants qui luttent contre l'obsolescence programmée, qui installent Linux ou des ROMs dédiées sur des appareils normalement condamnés, un indépendant qui désactive Facebook et Instagram pour se concentrer sur ses clients directs voire une personne âgée qui refuse le smartphone pour effectuer ses démarches administratives.
Offpunk n'est pas de la nostalgie ! Ce n'est pas une technophobie naïve ou une idéalisation romantique d'un passé imaginaire. C'est, avant toute chose, la quête d'une indépendance et d'une souveraineté. Pour paraphraser Edouardo Fernandes :
La révolution technologique n'est pas révolutionnaire et se laisser dépasser n'est pas réactionnaire.
L'esthétique Offpunk
Offpunk n'a pas encore de visage, mais certains indices peuvent nous permettre de voir à quoi il va ressembler. La première vient d'une définition que donne Ploum de ses propres actions sur Internet : « Technopunk », un technophile antisystème.
Comme mentionné plus haut, Offpunk est un positionnement envers la technologie contemporaine, pas une utopie/dystopie ou une esthétique visuelle culturelle, comme le sont les mouvements Solarpunk ou Cyberpunk.
Quelques exemples :
1) En informatique, le navigateur Offpunk, qui donne son nom à ce manifeste, et le protocole Gemini.
2) En design, le concept du « Forever Computer » ou le téléphone Mudita Kompakt.
- The computer built to last 50 years (ploum.net)
- Mudita Kompakt, a minimalist E Ink® phone. (mudita.com)
3) Dans la société, le New York Luddite Club
4) Dans la culture, le roman « Bikepunk » (2024) ou le film « One Battle After Another » (2025)
Dans One Battle After Another, l'obsolescence, le « downgrade » est une stratégie pour conquérir sa liberté. Les personnages reviennent à des anciens appareils personnalisables pour créer un réseau de communication parallèle. Lorsque les nouvelles technologies apparaissent, comme le smartphone, elles ont pour objectif de mettre les personnages en danger, de les empêcher de réaliser leurs plans voire de les supprimer tout simplement.
- Edouardo Fernandes
Dans le film Germano-japonais « Perfect Days » (2023), on peut voir la routine idyllique de Hirayama, un nettoyeur de toilettes publiques à Tokyo, qui, dans son temps libre, prend des photographies, écoute des cassettes audio, se déplace à bicyclette et lit des livres avant de dormir. La particularité étant qu'il semble apprécier chaque moment de sa vie tout en étant totalement déconnecté.
Au Japon, un pays qui a toujours cherché l'équilibre entre la modernité et la tradition, on trouve encore partout des terminaux pour payer en espèce, des lignes téléphoniques fixes pour conduire la majorité des communications professionnelles et d'anciennes technologies encore utilisées par les plus grandes entreprises, comme le fax ou les disquettes.
En Inde, qui possède l'un des meilleurs réseaux téléphoniques du monde, un citoyen passe en moyenne 90 appels par jour !
Priorités du mouvement Offpunk
Offpunk s'inscrit dans les luttes sociétales plus larges telles que :
1) La lutte contre la surproduction
2) La lutte contre l'obsolescence programmée
3) La lutte contre « l'Internet of Things », qui veut que chaque objet, même le plus mondain, soit connecté, récolte des données envoyées à Big Data, nécessite des mises à jour et des applications externes.
4) La lutte contre l'économie de l'attention
5) La réduction des heures de travail qui sont de plus en plus virtuelles
6) Le droit au loisir, à la citoyenneté et au travail sans avoir besoin d'un appareil numérique connecté.
7) Le droit à l'inclusion des populations précarisées ou plus âgées qui dépendent non seulement d'un accès à un appareil numérique connecté, mais doivent également avoir les moyens de se former et de s'adapter pour le mettre à jour et continuer à l'utiliser en dépit des changements introduits.
L'éditorialiste italien Giulio Cavalli disait :
C'est vrai : la digitalisation simplifie, accélère et standardise les procédures. Mais seulement pour ceux qui ont les moyens d'en faire partie. Pour tous les autres, la porte du futur est en train de se fermer.
Les outils Offunk
1) Le paiement en espèce. Pratique, ne nécessitant ni électricité ni Internet et garantissant que vos données personnelles ne sont pas stockées, agrégées, ni revendues.
2) Les médias analogues. Garantissant qu'une communication reste possible sans Internet et que les données vous appartiennent bel et bien. Disques, livres, journaux, radio…
3) Les médias numériques indépendants et décentralisés. Email, sites web « brutalistes » ou minimalistes, flux RSS, appareils photo numériques non connectés, lecteurs MP3, dumbphones…
4) Stockage et transfert physique des données. Disques durs, clés USB, cartes mémoires ou solutions en ligne indépendantes et contrôlées individuellement. Afin de garantir que nos données ne dépendent pas du bon vouloir d'un « cloud » propriétaire.
5) Des protocoles de communications décentralisés : messagerie via Bluetooth (Bitchat), protocole Gemini, emails chiffrés, Tor, XMPP…
Les challenges
1) La première difficulté est la commodité, la convénience des outils propriétaires : amusement, normes sociales, ubiquité.
2) L'accès aux espaces sociaux qui nécessitent de plus en plus un outil numérique : concerts, parking, cinémas, clubs de sport voire menus de restaurants.
3) Construire des réseaux de relations, y compris professionnelles, sans intermédiaire numérique.
Nous défendons le droit non négociable à un monde non numérique. Le droit de partager sans algorithmes, de nous organiser socialement sans plateformes centralisées. Le droit de ne pas être en permanence connecté ni espionné.
Tant qu'une poignée de sociétés maintiendra un monopole sur la technologie, tant qu'une surveillance de masse sera en place avec la complicité des États, sans la moindre transparence sur les moyens mis en œuvre ni l'utilisation de ces données, tant que l'économie de l'attention pourra monnayer nos temps libres contre de la publicité, tant que les infrastructures mettront à mal l'indépendance des pays du Sud, tant qu'il y aura une digitalisation forcée alors que les accès à Internet ne sont pas considérés comme un droit basique, alors la révolution ne sera pas numérique !
Ce texte a été initialement rédigé en Portugais par Arlon de Serra Grande et cosigné par Ploum (Lionel Dricot)
À propos de l'auteur :
Je suis Ploum et je viens de publier Bikepunk, une fable écolo-cycliste entièrement tapée sur une machine à écrire mécanique. Pour me soutenir, achetez mes livres (si possible chez votre libraire) !
Recevez directement par mail mes écrits en français et en anglais. Votre adresse ne sera jamais partagée. Vous pouvez également utiliser mon flux RSS francophone ou le flux RSS complet.
22 Aug 2026 8:03pm GMT
Lionel Dricot: L’onanisme des utilisateurs de chatbots
L'onanisme des utilisateurs de chatbots
Quand bien même les chatbots ne seraient pas les produits de gigantesques entreprises centralisées qui cherchent à nous exploiter en pourrissant nos cerveaux et Internet tout en étant une catastrophe écologique et sociale, je ne les utiliserais pas.
Quand bien même l'outil serait éthique à tous les points de vue, je le détesterais !
Le guitariste et le joueur de Guitar Hero
John Scalzi explique enfin pourquoi je n'aime pas ça. Parce que ç'est littéralement une perte de temps, un jeu vidéo qui ne sert à rien.
Il prend l'analogie de Guitar Hero : oui, c'est fun. Mais, fondamentalement, c'est inutile. Vous n'apprenez rien ! En demandant à un chatbot de répondre à une question, de produire un texte ou une image, vous n'avez littéralement rien appris. Les études le montrent : un étudiant qui répond à une question d'un prof en utilisant ChatGPT est incapable de répéter cette réponse quelques minutes plus tard. L'investissement intellectuel est nul. L'étudiant est comme une interface transparente entre le chatbot et le prof.
Je l'ai vécu lors d'un examen où j'avais autorisé l'usage de l'IA : un étudiant a été incapable de répondre à une question alors que la réponse était affichée sur son écran.
Mais, comme Guitar Hero, jouer avec un chatbot est amusant, voire addictif.
Je le comprends très bien. J'ai pris une demi-heure pour jouer avec la génération d'images de Lumo, le chatbot de Proton. Je lui ai demandé une couverture de Bikepunk et j'ai itéré en notant les défauts. J'avais plein de choses à dire sur l'output (notamment que, quoi qu'on fasse, une jeune femme à vélo doit obligatoirement porter un crop top). C'était très marrant de voir que quand j'ai précisé que je voulais que le personnage masculin ressemble à Thierry Crouzet, il a soudainement acquis une musculature impressionnante. Ce n'est pas que Thierry n'est pas musclé en vrai, mais, quand même, j'évite d'éternuer trop fort dans sa direction.
Et là, vous voyez le truc : c'était amusant. Ça me donnait envie de partager les différentes images.
Mais, en réalité, quand on n'est pas dans le délire, c'est juste nul. C'est comme regarder un pote jouer à Guitar Hero : il s'éclate, mais c'est un peu emmerdant pour le public. Voir c'est gênant. Un peu comme si vos amis vous racontaient à quel point leurs dernières séances masturbatoires étaient jouissives.
L'utilisation de l'IA est un plaisir solitaire. Je n'ai rien contre le fait que ça vous amuse, mais, par pitié, ne le partagez pas avec moi !
On ne gagne pas du temps en poussant sur un bouton
Les gens disent gagner du temps avec l'IA, mais ils n'améliorent pourtant pas leur productivité. Le paradoxe viendrait que le temps pris à utiliser l'IA lui-même ne serait, intuitivement, pas pris en compte.
C'est un paradoxe bien connu des bons managers : le management prend du temps et de l'énergie. Souvent plus que faire les tâches soi-même. Si tu engages un jardinier pour tondre ta pelouse, tu dois trouver le jardinier, le contacter, convenir d'un rendez-vous, négocier un tarif puis, une fois qu'il est là, lui expliquer le travail, vérifier qu'il a bien compris et puis vérifier qu'il a fait tout correctement.
Outre l'argent que ça coûte, cela n'est clairement pas une tâche anodine. En fait, si c'est juste pour faire une seule fois un petit jardin, c'est beaucoup plus rentable de tondre ta pelouse toi-même. Le bénéfice ne se fait sentir que lorsque tu as confiance et que tu as un accord pour que le jardinier vienne une fois par mois tondre une grande pelouse, sans même avoir besoin de te prévenir.
Les jeunes parents connaissent tous cela : junior veut absolument aider au montage du meuble Ikea, mais, honnêtement, ça te prend cinq fois plus de temps que de le faire tout seul.
On en est là avec l'IA. Parfois on gagne un peu de temps (une vraiment grande pelouse à tondre), parfois on en perd (l'armoire Ikea), mais l'attrait de la nouveauté fait que c'est fun. Un peu comme le fait de regarder un jardinier travailler depuis son salon en lui donnant des ordres. Cela donne un sentiment de puissance. C'est littéralement masturbatoire.
Le problème c'est que la rentabilité à long terme de notre jardinier se base sur le fait de créer une confiance, un automatisme. Et là, on est face à une entreprise de jardinage qui a un monopole mondial, qui augmente ses tarifs arbitrairement et envoie, à chaque fois, un nouvel ouvrier qui ne connait pas votre jardin, mais fait semblant du contraire. En plus, il est sous ecstasy.
Vos outputs de chatbots sont de la pollution
Mon principal grief, c'est que les utilisateurs des chatbots sont persuadés d'avoir une compétence ou une valeur ajoutée quelconque. J'en ai été témoin de première main : les projets open source sont noyés de contributions générées. Souvent, les utilisateurs sont de bonne foi : ils ont réellement trouvé un bug et plutôt que de le rapporter, ils demandent à un LLM de générer un patch.
Parfois, ils poussent le vice jusqu'à faire écrire le rapport de bug par le LLM. Ils sont très fiers.
Fier de quoi ? D'avoir cliqué sur l'icône Claude ou ChatGPT ?
Et c'est une catastrophe : parce que le mainteneur doit désormais tenter de comprendre dans tout ce charabia et ce jargon quel est le problème de base. Au lieu d'avoir un utilisateur qui se plaint, parfois un peu maladroitement, nous sommes face à une machine qui réinterprète tout et il faut deviner ce que l'utilisateur avait en tête. En gros, il faut essayer de déduire le prompt.
Ce n'est déjà pas évident de se comprendre entre humains en communication directe alors si un chatbot sert d'intermédiaire…
Ou cette connaissance à qui je pose une question et qui m'envoie la réponse de ChatGPT. Comme si c'était d'une aide quelconque. Parce que si je demande quelque chose à quelqu'un, c'est vraisemblablement parce que je ne trouve pas de réponse facile et que je pense que cette personne a une expertise du domaine. Me renvoyer la réponse de ChatGPT est à la fois injurieux (tu n'en as rien à foutre de m'aider) et hautain (tu penses que je ne suis pas capable de faire une recherche Web).
Que ce soit clair : un output de chatbot n'est pas fait pour être partagé. Si vous souhaitez le faire, alors partagez juste le prompt, ce sera beaucoup plus efficace.
De plus en plus d'artistes professionnels se plaignent : plutôt que d'avoir des instructions claires, les clients leur envoient des « idées » générées par IA. Et les artistes doivent deviner ce que veulent leurs clients.
Le chatbot, c'est comme la masturbation : pratiquez-le seul ou dans un cercle restreint d'adultes consentants. Jamais en public. Jamais en présence de personnes non consentantes. Jamais dans un cadre professionnel.
Apprendre de ses expériences
Mais le principal problème, outre l'opacité de la communication, c'est ce que dit Scalzi avec Guitar Hero ou comme le montre l'analogie de la masturbation : vous n'apprenez rien.
Vous ne saurez pas jouer bon anniversaire à la guitare même après des centaines d'heures de Guitar Hero. Vous ne rencontrerez jamais un partenaire amoureux en vous masturbant. Ce n'est pas un jugement de valeur : c'est juste que ces activités n'ont pas le moindre rapport entre elles !
L'énorme majeure partie des patches que je reçois pour mes projets Open Source me prennent plus de temps à relire et à intégrer que si je le faisais moi-même. Pourtant, j'apprécie cela, car je sais que la personne a dû fournir un effort pour comprendre mon code. Elle a appris. Et, petit à petit, elle va être de plus en plus à l'aise pour faire des changements plus importants tandis que moi, j'aurais appris à lui faire confiance. Je peux également poser des questions sur les choix techniques qui ont été faits, en discuter, remettre en question mes propres perspectives, mes propres choix.
Accepter un patch n'est jamais un gain de temps, c'est un investissement sur le futur. C'est également une manière de faire grandir deux personnes.
Ce qui n'est pas le cas avec les patchs générés. C'est même exactement le contraire : accepter un patch généré va introduire dans le projet du code qui fonctionne peut‑être aujourd'hui, mais que personne ne comprend et, surtout, dont on ne peut même pas présupposer qu'il a une logique.
Si vous n'avez rien appris en utilisant un chatbot et si la personne qui reçoit l'output n'apprend rien, pourquoi le faire tout court ?
Un tas de débris aléatoire n'est pas une maison
Vous vous souvenez de l'expérience de pensée qui dit que si on assied assez de chimpanzés qui tapent aléatoirement sur des machines à écrire, on va finir par générer du Shakespeare ou du Proust ?
Et bien c'est exactement ce que font les chatbots avec le code : ils génèrent presque aléatoirement des morceaux de code jusqu'à ce que le code en question réponde superficiellement à la question. Ça fonctionne, parfois, ici et maintenant, mais, bien entendu, ça va craquer de partout dès qu'on bouge quelque chose.
Un peu comme si on construisait une maison en jetant aléatoirement des poutres et des briques jusqu'à ce que, ô miracle de la loi des grands nombres, l'édifice de matériau dégage un espace assez grand pour qu'on l'appelle "chambre" avec une ouverture appelée "porte". Ce serait cool.On prendrait des photos.
Mais pensez-vous sérieusement que cette "maison" tiendrait face à la première pluie, au premier souffle de vent ou à la première vibration d'un camion sur la route ?
De la même façon, communiquer par écrit est une compétence qui se travaille. C'est même plus important que cela : l'écrit permet de structurer ses propres pensées. Tant que vous n'avez pas écrit vos idées, elles ne sont pas réelles, pas claires.
Tant que vous n'avez pas fixé votre idée sur un support, elle ne vaut rien. Et si ce n'est pas vous qui la fixez, ce n'est pas votre idée.
En déléguant l'écriture de vos emails et de vos rapports, non seulement vous perdez la compétence communicationnelle, mais, pire, vous perdez simplement vos idées.
Les singes bientôt remplacés ?
Dans le cliquetis des milliards de machines à écrire actionnées par les singes, une feuille tomba soudainement sur le sol. Un entrepreneur s'en saisit et lut : « Longtemps, je me suis couché de bonne heure… »
- Ça y est, hurla-t-il ! Nous avons réussi ! Ce singe écrit du Proust !
Le singe en question fut mis sur un piédestal, choyé, dorloté. Mais les entrepreneurs avaient beau faire, il n'écrivait plus que du charabia sans signification.
- Dommage, fit un entrepreneur. Peut-être n'est-ce pas la bonne approche.
- Et si nous remplacions les singes par des utilisateurs de ChatGPT ?
- Pas bête. Statistiquement, ça devrait fonctionner…
- Et puis, on ferait des économies de bananes !
À propos de l'auteur :
Je suis Ploum et je viens de publier Bikepunk, une fable écolo-cycliste entièrement tapée sur une machine à écrire mécanique. Pour me soutenir, achetez mes livres (si possible chez votre libraire) !
Recevez directement par mail mes écrits en français et en anglais. Votre adresse ne sera jamais partagée. Vous pouvez également utiliser mon flux RSS francophone ou le flux RSS complet.
22 Aug 2026 8:03pm GMT
Lionel Dricot: L’arnaque du bilan carbone
L'arnaque du bilan carbone
Pourquoi nous nous sommes fait avoir dans notre soi-disant lutte contre le réchauffement climatique
Ne plus prendre l'avion, acheter des électroménagers de moindre consommation ou se déplacer en voiture électrique semblent être les mesures antiréchauffement climatique dont j'entends le plus parler. Ça et guillotiner les milliardaires qui voyagent en jet privé. D'ailleurs, les estimateurs de bilan carbone pullulent.
Mais je suis de plus en plus convaincu que c'est une grossière erreur. Nous sommes en train de compter nos grammes de CO₂ produits et cela a probablement autant d'impact que faire pipi sous la douche. Cela nous occupe pour nous donner l'impression de faire quelque chose tout en permettant aux politiciens de ne surtout rien changer.
Comprendre le réchauffement climatique.
Revenons à la base. Il existe sur la planète une quantité fixe de carbone qui est invariable (on peut oublier les très rares apports de météorites). De ce carbone, une grande quantité est prisonnière dans le centre de la terre dont elle s'échappe parfois lors des éruptions volcaniques. Mais simplifions et oublions cela.
Nous avons donc une quantité de carbone fixe pour la surface et l'atmosphère, que j'appelle « le système surface ».
Il y a des milliards d'années, il n'y avait pas d'oxygène dans l'atmosphère, mais énormément de gaz carbonique. L'abondance de CO₂ a permis une explosion de la vie, principalement le plancton, extrayant le carbone de l'atmosphère grâce à la photosynthèse. Mais la photosynthèse produit un déchet éminemment toxique pour beaucoup de formes de vies : l'oxygène !
Cette période porte le nome de « Grande Oxydation ».
Heureusement, ce processus ayant eu lieu sur des centaines de millions d'années, des formes aérobiques ont eu le temps d'évoluer, formes de vie qui survivaient grâce au processus inverse : consommer de l'oxygène et produire du CO₂ Nous faisons nous-mêmes partie de cette forme de vie. Nous devons donc ingérer du carbone, via l'alimentation, afin de le brûler avec de l'oxygène pour produire de l'énergie et expirer le déchet, le CO₂
Un point particulièrement important est que la somme du carbone de la surface et du carbone de l'atmosphère n'est jamais modifiée. S'il y a plus de plantes et de planctons, le carbone est fixé sur la surface et dans les océans. S'il y a plus d'humains et d'animaux, il y a un peu plus de carbone dans l'atmosphère. Mais la somme des deux reste constante.
Lorsqu'un être vivant meurt, quel qu'il soit, son carbone est soit rendu à l'atmosphère via la décomposition (qui est une forme de combustion), soit intégré à un autre être vivant via l'alimentation.
La fossilisation du carbone
Une troisième voie est cependant possible. Lorsqu'un « cadavre » s'enfonce dans le sol ou dans un fond marin, son carbone est comme capturé par la planète. Il ne peut plus rejoindre l'atmosphère ni être consommé. Avec le temps et les très hautes pressions, ce carbone se fossilise.
Les plantes fossilisées deviennent essentiellement du charbon tandis que les autres formes de vie, principalement les espèces de planctons, se transforment en hydrocarbures : pétrole et gaz fossile (aussi appelé « gaz naturel »).
Le point le plus important de cette fossilisation est qu'elle a retiré énormément de carbone de la surface. Au fil des milliards d'années, le taux de CO₂ de l'atmosphère a donc chuté de manière extrêmement importante, entraînant un refroidissement climatique. Le CO₂ a en effet la propriété de « capturer » la chaleur du soleil comme le ferait une serre. Cette particularité du CO₂ a été mainte fois observée et prouvée depuis la moitié du 19e siècle.
Avec moins de CO₂ dans l'atmosphère, la terre s'est lentement refroidie, au détriment de certaines espèces, mais au plus grand bonheur d'autres dont l'Homo Sapiens Sapiens. Le « lentement » est important. On parle de dizaines de millions d'années.
L'extraction du fossile
Le grand malheur de notre espèce est que, depuis la révolution industrielle, nous avons découvert que ce carbone fossile brûle très bien. C'est donc un formidable réservoir d'énergie, de joules, que chacun veut exploiter. En fait, on sait depuis longtemps qu'il brûle bien, mais les réserves étaient inaccessibles : il fallait plus de joules pour extraire du charbon que ce qu'il produisait en brûlant. L'invention du moteur à vapeur va changer la donne et permettre l'industrialisation des mines de charbon puis des puits de pétrole (relisez « À l'ombre des derricks »).
Comme me le disait Philippe Samyn, le Joule est l'unité qui fait tourner le monde. Et le carbone fossile en est une fameuse réserve.
Mais, en brûlant ce fossile, nous remettons en circulation dans l'atmosphère du carbone qui était séquestré depuis des millions ou des milliards d'années.
Le changement climatique est bel et bien humain, la question ne devrait même pas se poser vu que chaque puits de pétrole, chaque mine de charbon et chaque gisement de gaz n'a, au fond, qu'une seule utilité : remettre dans l'atmosphère du carbone qui n'y était plus depuis des milliards d'années.
J'espère que cette explication cloue aussi définitivement le bec aux idées absurdes comme le fait que les cyclistes contribuent également au réchauffement climatique en respirant et en mangeant des côtelettes. Que vous mangiez un steak ou une salade de pois chiche, tout le carbone que vous consommez était encore dans l'atmosphère il y a quelques jours. Vous n'ajoutez aucun atome au système de la surface. Par contre, allumez la flamme d'un briquet et vous êtes littéralement en train d'envoyer dans l'atmosphère du carbone qui n'y était plus depuis des milliards d'années.
Ce billet est également la réponse à l'idée parfois entendue que cette recarbonisation serait « naturelle ». Il a fallu des milliards d'années pour capturer ce carbone que nous relâchons presque totalement en moins de 200 ans ! C'est 10 millions de fois plus vite ! Aucune adaptation du vivant ne peut se faire à cette vitesse !
Le renouvelable est-il la solution ?
Intuitivement, vous vous dites qu'il suffit de ne pas utiliser de briquet et de passer à une énergie dite « renouvelable », des joules propres produits sans carbone fossile. Qu'il faudrait consommer « intelligemment » pour savoir combien de grammes de CO₂ ont été produits pour tel ou tel objet.
Mais c'est à la fois très compliqué à calculer et complètement inutile.
Tout l'effort pour passer vers le renouvelable se base sur la théorie (essentiellement fausse dans le monde réel) de l'offre et la demande en se disant que « si le renouvelable devient moins cher, les gens n'achèteront plus de pétrole et les puits ne seront plus rentables et donc se fermeront ».
Cela permet aux néolibéraux de se déclarer écologistes, mais c'est évidemment complètement et dangereusement faux. À l'heure actuelle, la moitié du pétrole extrait sert à déplacer l'autre moitié jusqu'aux pompes ou aux centrales tout en restant l'un des produits les plus rentables du monde !
Tout le pétrole, charbon et gaz déjà extrait sera consommé, quoi que vous fassiez. Une fois extrait, le carbone fait littéralement partie du système de la surface. À moins d'arriver à convaincre 100% des humains de ne plus utiliser de pétrole ou de charbon et de laisser intactes les réserves mondiales, ce dont je doute fort, il sera brûlé. Même si le pétrole devenait soudain beaucoup trop cher, il serait revendu à perte (vu que déjà extrait). Et il restera toujours un atout stratégique essentiel des armées, ce qui lui confère une valeur intrinsèque importante (le jet supersonique, le missile balistique et le char d'assaut sont difficilement imaginables en version électrique).
La seule mesure réaliste et efficace pour lutter contre le réchauffement climatique est d'arrêter l'extraction de carbone fossile. Point à la ligne. Tout le reste n'est que poudre aux yeux malhonnête ou confondante naïveté.
Entendons-nous bien : toutes les mesures « écologiques » sont généralement positives et procurent bien des avantages (moins de particules fines, moins de pollution dans les océans ou les sols …). Je les encourage fortement. Mais, quand on parle du réchauffement climatique, elles nous distraient de l'essentiel.
Capturer le carbone
Planter des arbres, c'est pas mal. J'aime beaucoup les arbres. Cela permet de modifier l'équilibre sol/atmosphère, ce qui est toujours appréciable. Mais il faut en planter beaucoup et s'assurer qu'ils ne brûlent pas. Même avec beaucoup d'arbres, le carbone fait désormais partie de notre cycle de surface !
Prétendre que planter des arbres contrebalance l'extraction fossile est une escroquerie pure et simple, car, en pourrissant ou en brûlant, le carbone de l'arbre va bientôt revenir dans l'atmosphère. Et quand bien même c'est utile, le mécanisme économique des certificats de compensation carbone est une arnaque qui entraîne plus d'émissions !
C'est également la raison pour laquelle les tentatives d'extraction industrielles du carbone de l'atmosphère sont vouées à l'échec. Il faudrait non seulement extraire plus de carbone qu'on en produit, mais aussi arriver à le fossiliser, à faire en sorte que celui-ci ne puisse plus jamais revenir dans l'atmosphère.
Certains imaginent capturer le carbone dans le béton de constructions, mais l'échelle est ridicule par rapport à la quantité de carbone fossile qui est extraite à chaque seconde. Et, au fond, mettre du carbone dans nos constructions, ça s'appelle des planches en bois. Mais comparez cela avec la quantité de barils de pétrole extrait à chaque instant.
De nouveau, on tente de se distraire, d'imaginer toutes les solutions les plus absurdes les unes que les autres. Toute sauf la seule réelle : arrêter l'extraction.
Parce que je ne vois pas d'autres solutions
Il suffira de quelques jours froids cet hiver pour faire oublier les canicules de 2026 et entendre les habituels poncifs sur le déni du réchauffement climatique. Et puis, quand bien même le sujet reviendrait dans l'actualité, les militants accuseront les jets privés et les politiques annonceront une prime pour l'installation de panneaux photovoltaïques. Les geeks se rassureront en achetant un smartphone « éthique » avec un chiffre arbitraire de grammes de CO₂ sur la boîte (qui est bien, car entouré en vert).
Il n'en reste pas moins que chaque litre de pétrole, chaque kilogramme de charbon extrait contribue au réchauffement climatique. Que les entreprises qui se livrent à cette activité sont criminelles, que leurs cadres devraient être traduits en justice pour tous les morts et toutes les catastrophes climatiques. Bref, pour crime contre l'humanité.
Les états devraient en prendre la mesure et interdire toute importation de produits issus de l'extraction du carbone fossile.
C'est la seule solution réelle si nous voulons efficacement ralentir puis stopper le réchauffement climatique. Il n'y a pas de demi-mesures possibles. Et, en plus, c'est techniquement assez simple. Il « suffirait » d'une résolution de l'ONU suivie d'un Nuremberg du climat.
Mais, franchement, vous y croyez vous ?
Vous connaissez un seul politicien qui pourrait être élu avec cette idée ?
Alors on va aller faire pipi sous la douche en tentant de se convaincre que la fameuse parabole du colibri n'est pas une pure intoxication néolibérale pour rejeter la culpabilité d'une catastrophe planétaire sur les choix de consommation de l'individu.
Je suis sans cesse tiraillé entre l'idée qu'il faut que je produise moins de CO₂ et la certitude que, de toute façon, cela ne sert à rien : tout carbone fossile extrait sera bientôt dans l'atmosphère, que ce soit demain ou dans dix ans.
Il n'y a pas de bilans carbone honnêtes. Il n'y a que le carbone de surface et le carbone fossile. Si nous ne condamnons pas rapidement et durement ceux qui extraient le carbone fossile, le trou qu'ils sont en train de creuser sera la tombe de l'humanité…
À propos de l'auteur :
Je suis Ploum et je viens de publier Bikepunk, une fable écolo-cycliste entièrement tapée sur une machine à écrire mécanique. Pour me soutenir, achetez mes livres (si possible chez votre libraire) !
Recevez directement par mail mes écrits en français et en anglais. Votre adresse ne sera jamais partagée. Vous pouvez également utiliser mon flux RSS francophone ou le flux RSS complet.
22 Aug 2026 8:03pm GMT
Frederic Descamps: Teaching MariaDB About Your Domain
When we talk about extending a database server, we usually think about features that could benefit a very large number of users. A new authentication mechanism, a storage engine, an audit plugin, a new generic data type such as UUID or INET, additional JSON functions… these are relatively easy to justify because their potential audience […]
22 Aug 2026 8:03pm GMT
Frederic Descamps: Say the Name: MariaDB, MySQL, and the Ecosystem We Share
Names are important. They help us identify people, projects, products, pets, database servers, and occasionally the correct bug tracker. This may sound obvious, but the database world has spent more than fifteen years proving that it is not. MySQL and MariaDB share a substantial amount of history, syntax, tooling, knowledge, applications, and community. They also […]
22 Aug 2026 8:03pm GMT
Frederic Descamps: MariaDB InnoDB Disk Space & Fragmentation
As a DBA, disk space has always worried me. In fact, the biggest problem for a MySQL/MariaDB DBA is the large, fragmented InnoDB Tablespaces. It was even more problematic when a single tablespace handled everything. But even with a tablespace per table (innodb_file_per_table=ON) fragmentation on large tables can still be an issue and waste disk […]
22 Aug 2026 8:03pm GMT
Frederic Descamps: MariaDB GTID Info & Flashback Plugin
Reversing Transactions Directly from the Binary Log Some ideas never completely disappear. They remain somewhere in your brain, waiting for the right opportunity-or the right API-to come back. For me, recovering rows from the binary log is one of those ideas. More than ten years ago, I started experimenting with a simple question: If row-based […]
22 Aug 2026 8:03pm GMT
Frederic Descamps: MariaDB 13.1 Feature in Focus: JSON Operators and JSON_TABLE Improvements
MariaDB 13.1 introduces the long-awaited `->` and `->>` JSON operators, together with `FORMAT JSON` support in `JSON_TABLE()`. Discover how these improvements simplify JSON queries, preserve nested objects and arrays, and improve compatibility with MySQL applications.
22 Aug 2026 8:03pm GMT
Dries Buytaert: The software business after code scarcity
If AI can generate an application from a description, is software still worth anything?
I have lived with a version of that question longer than most.
I released Drupal for free more than twenty-five years ago, and later co-founded Acquia, which has grown into a large enterprise software company built around Drupal.
Granted, Drupal is free in a different way than AI-generated applications are free, but I'm not sure that changes the basic question of how to build a successful business around either one.
Open Source made code abundant by giving people broad rights to use, modify, and redistribute it. AI is lowering the cost of producing code. One lets you copy the software; the other makes it cheaper to recreate software.
Free code changes what customers pay for
Because anyone could use Drupal for free, Acquia could never build a durable business around access to the code. From the start, we had to make money another way.
We built that business around helping enterprises build, run, and manage Drupal applications throughout their lifecycle. That includes hosting, but goes well beyond it: the tools and services needed to develop, deploy, secure, scale, monitor, and improve applications in production.
Proprietary SaaS typically bundles access to the application with the hosting and operations required to run it. With Open Source, organizations can run the software themselves or choose who hosts and operates it.
As AI makes applications cheaper to recreate, the traditional SaaS bundle of software and operations comes under pressure. Customers may become less willing to pay for access to application functionality without becoming any less willing to pay to run and manage applications in production. For Open Source businesses those economics are not new.
Dependability becomes the product
Software can be free, or nearly free, without becoming cheap to depend on. The more people and organizations depend on a system, the more of its value comes from operating it securely, reliably, and at scale.
Once people depend on an application, the cost of its failure has little to do with how much it cost to build. An application that costs $1,000 to build can still cause a $10 million failure.
As AI makes enterprise applications easier to create, adapt, and integrate, they still have to be deployed, secured, scaled, monitored, and run reliably over time. As software cost comes down, dependability becomes a differentiator.
Linux is abundant; dependable cloud infrastructure is a service worth paying for. Drupal is abundant; dependable digital experience infrastructure is a service worth paying for.
Acquia has lived with those economics for nearly 20 years. Drupal made the code abundant, so we built our business around helping organizations build, run, and improve what they created with it. As AI makes code cheaper to generate, that business model may start to look a lot less unusual.
Either way, more software companies will have to answer the same question: if code and capabilities are abundant, what are customers really paying you for?
22 Aug 2026 8:03pm GMT
Dries Buytaert: Responsibility follows control
The text is clean. I found only one minor issue: a double space.
An AI model does not decide what data it can access, which tools it can use, or whether it can act without approval. People make those decisions at different points. Upstream, a model developer trains and tests the model and decides whether and how to release it. Downstream, a developer builds the model into a system, connects that system to data and tools, and decides whether a person must review its proposed actions before they take effect.
Those choices determine whether harm is possible at all. So when harm occurs, responsibility should fall on those who controlled the relevant choices. That responsibility may be shared: model developers control training and release, product builders control permissions and deployment, and users control deliberate misuse.
Responsibility should follow meaningful control
That principle is missing from much of the debate over open-weight AI models, which often treats the decision to release a model as the only one that counts.
Axios recently reported that United States officials had considered measures that could restrict American companies from using Chinese open-weight models. Open-weight models make their trained parameters available for others to download, modify, and run on their own infrastructure, without going through the company that built them.
More than 230 companies and organizations have since signed an industry letter defending open weights. After critics accused Anthropic of supporting a ban on open-weight models, Anthropic CEO Dario Amodei published a statement denying that position. He described open-weight models that do not have dangerous capabilities as a public good and supported mandatory safety testing for sufficiently capable models, open or closed.
The disagreement is less about whether open weights can create risk than about when those risks justify restricting a release, and whether restrictions would improve safety or mainly concentrate power in the largest AI labs.
I am firmly in the open-weights camp. I have run and compared open-weight models, argued that digital sovereignty depends on who controls software, not where it comes from, and believe organizations should control their infrastructure and data instead of depending on a handful of providers.
I also believe consequential algorithms need oversight. More than a decade ago, I argued that we would eventually need something like an FDA for software. The harder question is where responsibility for that oversight should lie.
Open-weight models unbundle control
With hosted, closed-weight models from providers such as Anthropic and OpenAI, the provider typically keeps the weights private, controls how customers access the model, and decides when to update the hosted service.
Open weights can separate those roles. One organization creates and releases the model. A repository such as Hugging Face hosts and distributes the weights. Another team might fine-tune them. A product builder incorporates the model into a product and connects it to data, tools, and users.
Each team controls something different. Because open weights unbundle control, it becomes harder to say who is responsible when harm occurs.
A model developer controls the training process, capability testing, documentation, and release decisions. A repository controls what information it displays about a model's origin, which security checks it performs on uploaded files, and which access restrictions it provides or enforces. A product builder controls what data and tools the resulting system can reach, which actions require human approval, and what gets logged.
Control is not the only thing that matters, but it shows who could still have changed the outcome. When harm involves AI, several actors may bear responsibility for the same incident because each controlled a different opportunity to prevent it.
Open Source shows how responsibility follows control
Like open-weight models, Drupal's Open Source code can be copied and changed without asking anyone's permission. A site owner could use it to spread misinformation or operate a fraudulent website. The site owner controls the content and operation of the site and is responsible for those choices. The Drupal project is not responsible merely because someone used its code.
But the Drupal project controls other decisions. When someone privately reports a security vulnerability, the Drupal Security Team follows a coordinated disclosure policy. It keeps the issue private while a fix is prepared. Once a security release is available, the team publishes an advisory and tells site owners to upgrade. The timing of that disclosure can give site owners a fair chance to protect themselves.
The same distinction applies to AI. Responsibility should follow the decisions each actor controls.
Products turn capability into authority
A model generates outputs. An agent is a software system that uses a model to work toward a goal, often by calling tools and taking actions. The people who build and configure the agent decide what it can access, which actions it can take, and when it needs a person's approval.
In a coding agent such as Claude Code, a model can generate a database command. Whether that command can run depends on the tools and permissions the agent provides, as well as the access allowed by the computer, network, and database.
A content management agent can propose deleting an article. The content management system (CMS) determines whether the agent has permission to delete it, whether the deletion is reversible, and whether the action is recorded.
Permissions, isolation, audit logs, rate limits, human approval, and rollback are not merely engineering details. They determine who has control at the point where harm can still be prevented. That is why AI governance is becoming an essential part of product architecture.
Regulate AI at each point of control
Deciding who should answer after harm is easier, even when the answer is not obvious. The harder question is what government should require before any harm has happened.
If control and responsibility are distributed across several actors, government rules should be distributed across them too. This is not a new idea. We already regulate many technologies this way.
More than a decade ago, when I argued for something like an FDA for software, I had drug approval in mind. I no longer think that is the right model. The FDA approves a drug for one or more intended uses, while a general-purpose model may be used for many different purposes.
Cars are a better comparison. The government sets safety standards, and manufacturers certify that their vehicles meet them. Separately, drivers must pass a test defined by the government before they are licensed to drive.
The layers extend beyond cars and drivers. States set legal blood-alcohol limits for drivers and require bars to have licenses they can lose. In many states, a bar can also be held liable for serving a visibly intoxicated person who later causes harm.
Each rule targets the actor who controls a particular decision. Together, they reduce risk for everyone. I would take the same layered approach to AI.
Blocking a model's release is a much stronger step, and one that should rarely be used. For an open-weight model, that means preventing the developer from publishing the weights. For a closed model, it could mean preventing the provider from offering access.
I would support that only when safeguards in products and rules governing their use could not prevent a serious danger in time. The two-part test below applies only to this exceptional step, not to AI regulation in general.
Require extraordinary evidence to block a release
The strongest argument for restricting an open-weight release is that it is effectively irreversible. Once the weights are public, the developer cannot withdraw every copy, monitor how the model is used, or ensure that its safeguards remain in place.
If a model made catastrophic harm much easier, its release could be the last moment anyone had meaningful control. By catastrophic, I mean mass-casualty or comparably systemic harm, not ordinary product failure, fraud, or abuse.
As of July 2026, I have not seen public evidence that an open-weight model has crossed this threshold. That said, I believe it is just a matter of time, which is why I still think meaningful regulation is coming.
Before blocking a model's release, a government should have clear evidence that the answer to both questions is yes:
-
Would releasing this model make catastrophic harm much easier? Compare it with closed models and other tools people can already access.
-
Would blocking its release meaningfully reduce that danger? A restriction should not merely shift access to another country or distribution channel.
Default to openness with distributed responsibility
So where do I land today? I would default to allowing publication and place obligations where control already exists: on model creators for testing and release decisions, on distributors for provenance and file integrity, on product builders for permissions and deployment, and on users for deliberate misuse.
This approach also protects competition. A regulatory regime that only the largest labs can satisfy could protect them from competition without necessarily making anyone safer. It could also push organizations toward depending on a handful of providers for infrastructure they cannot inspect.
Open weights do not eliminate control. They distribute it, making it harder to say who is responsible when harm occurs. Regulation should follow that structure: place obligations on each actor at the point where harm can still be prevented, and block publication only when release would make catastrophic harm substantially easier and a restriction would materially reduce the danger.
22 Aug 2026 8:03pm GMT
Dries Buytaert: Helping agents discover my site search with MCP
This is the third post in a series about making my site's search available to AI agents. First, I published an API Catalog, which helps agents that already know to check my site find its search API. Second, I added an Agentic Resource Discovery (ARD) entry so my search can be indexed by "AI registries" (think search engines for AI agents).
So far, no agent has found my search on its own. The API Catalog has been a published IETF standard for over a year but I found no evidence that either OpenAI or Anthropic checks for it. ARD is newer, still a v0.9 draft, and I found no evidence that OpenAI or Anthropic supports it either.
In the meantime, what does work is a custom Agent Skill that points my AI assistants to the API Catalog, which leads them to my OpenAPI description and from there to the search itself. If and when agents adopt one or more of these discovery standards, I might be able to drop the skill and have it all work automagically.
Until last week, I had decided Model Context Protocol (MCP) was not worth implementing for my search API endpoint. It required an initialization handshake and could involve protocol-level sessions. My search doesn't need either: every query is stateless and anonymous. MCP felt like overkill for my simple use case.
The 2026-07-28 revision changed my mind because both the protocol-level session and the initialization handshake are gone. Every request can now be self-contained, which means that, for a service like mine, an MCP server is basically a POST route that returns JSON.
So I went ahead and implemented MCP support for my search endpoint. The whole thing came to one route and three small RPC methods: fewer than 150 lines of code, excluding tests.
You can call it from any terminal
In my testing, adding my site as a custom MCP connector to Claude Desktop, Claude Code, or ChatGPT still fails. These clients don't support the new protocol yet, which is understandable because it is only a week old. Once they catch up, anyone will be able to add dri.es as a connector, not just me.
Until then, an easy way to talk to my site with an MCP client is Simon Willison's mcp-explorer. You can run it with uvx, which comes with uv:
uvx mcp-explorer list https://dri.es/mcp
uvx mcp-explorer call https://dri.es/mcp search -a q "open source"
The first command prints the tool's name, description, and arguments. The second runs a search across my posts and returns up to twenty results.
Alternatively, you can use the raw protocol by running this curl command from a terminal:
curl -s https://dri.es/mcp \
-H "Content-Type: application/json" \
-H "MCP-Protocol-Version: 2026-07-28" \
-H "Mcp-Method: tools/call" \
-H "Mcp-Name: search" \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"search","arguments":{"q":"open source"},"_meta":{"io.modelcontextprotocol/protocolVersion":"2026-07-28"}}}' \
| jq .result.structuredContent
Discovery and invocation are separate layers
Having implemented support for three new standards, the useful thing I learned is that they are not alternatives.
ARD handles discovery: it gives registries a standard way to index and search for services like mine. OpenAPI and MCP handle invocation by defining how agents can call and use those services.
So the choice is not ARD or MCP. It is ARD plus OpenAPI, or ARD plus MCP.
For an anonymous, read-only API like mine, I prefer OpenAPI. It was easier to implement and anything that can make an HTTP request can use it.
MCP becomes more attractive when you have services that involve multi-step interactions, authentication, or explicit application state.
Ultimately, agent and crawler adoption will decide. Time will tell, but my money is on ARD and MCP right now.
22 Aug 2026 8:03pm GMT
Dries Buytaert: Helping agents discover my site search with Agentic Resource Discovery
Yesterday I blogged about the API catalog that announces my site's search API to agents. In response, someone pointed me to the ARD specification, a draft announced last month by a working group that includes Google, Microsoft, GitHub, Hugging Face, Cisco, Nvidia, and Salesforce.
What ARD adds to yesterday's API catalog is discovery. If an agent has never heard of you, it does not know to look for your API catalog. Ask an agent what people have written about the future of Drupal, for example, and it will probably search Google. It may not think to check dri.es or drupal.org directly.
The web solved discovery decades ago. Search engines find the right site, so you do not have to know where the answer lives.
ARD brings search-engine-style discovery to AI agents. ARD registries crawl the web for catalogs published by sites and add their resources to a searchable index. An agent can then ask a registry a plain-language question, such as "Who can answer questions about the future of Drupal?". The registry returns a ranked list of relevant resources, perhaps pointing the agent to my site's search API.
You opt in by publishing a manifest at /.well-known/ai-catalog.json. Here is what my mine currently returns:
{
"specVersion": "1.0",
"host": {
"displayName": "Dries Buytaert"
},
"entries": [
{
"identifier": "urn:air:dri.es:search",
"displayName": "Site search",
"type": "application/openapi+json",
"url": "https://dri.es/openapi.json",
"description": "Full-text search across the site's content, ranked by relevance.",
"representativeQueries": [
"Find posts about the future of Drupal",
"What has been written about open source sustainability?",
"Find writing about digital sovereignty",
"How is AI changing how we build websites?",
"Search Dries Buytaert's blog and notes"
]
}
]
}
Each entry describes a resource an agent can use. ARD deliberately defines "resource" broadly: it can be an API, an MCP server, another agent, a skill, or even a nested catalog containing more resources.
My site offers just one resource: a simple search API. The whole thing took less than an hour to implement because the ARD entry simply points to the existing OpenAPI document, https://dri.es/openapi.json, that I wrote about yesterday. In other words, it makes the same API description available through a second discovery mechanism.
The representativeQueries field is the interesting part. It lists example questions registries use to match an agent's intent. Mine are first guesses that I will revise once I can see how they get used.
Of the eleven companies listed as contributors, Hugging Face is the only one whose AI catalog I could find on its primary domain. It also runs an early registry. So I queried Hugging Face's registry. It responded correctly using the protocol defined by the specification, but for my queries, it returned only skills hosted by Hugging Face.
Broad adoption will depend on whether major agents begin searching ARD registries. Microsoft, Google, and GitHub are members of the working group, but OpenAI and Anthropic are not. Google has said its Agent Platform will connect to ARD registries in the coming months, but it remains to be seen how widely the specification will be adopted.
Does my blog need this? Probably not. Other sites have more to gain. An online store could announce its product search and checkout APIs, a restaurant its reservation system, and a city its appointment system for renewing a permit.
Many of these sites run on a content management system. A CMS that made its capabilities discoverable through ARD by default could therefore be interesting. Experiments like this help me understand whether Drupal should be that CMS.
22 Aug 2026 8:03pm GMT
Dries Buytaert: From personal AI experiments to shared tools
In April 2025, I published Claude Code meets Drupal, my first public experiment with an AI coding agent. I have been experimenting with coding agents ever since, often by building tools to solve problems in my own work.
Last week, I joined the Drupal AI Learners Club to discuss several experiments I had already published. Angie Byron started the club and runs it with co-organizer Amber Himes Matz. It gives people in the Drupal community a place to show how they are using AI and talk honestly about what works and what does not.
I spent an hour walking through some of my AI experiments, starting with Drupal Digests, a tool that uses AI to summarize key developments across Drupal Core, Drupal CMS, Drupal Canvas, and the Drupal AI initiative.
Drupal Digests led to another experiment: AI-generated Rector rules. When a Drupal Core change deprecates an API, Drupal Digests analyzes the issue and code changes and generates a rule that can automate the corresponding upgrade in other Drupal projects.
I also showed my API Catalog that helps AI agents discover my website's search API.
These are only some of my AI experiments. Most begin as tools I build for myself, and many never go any further. When one seems useful beyond my own work, I publish it so others can benefit from it.
Once a tool is public, we can see whether people use it and want to help improve it. If they do, it may eventually become a proper community project. If not, that is useful to know too.
The recording goes into more detail, with demonstrations of the tools and questions from the group. You can watch it below.
22 Aug 2026 8:03pm GMT