Acte I : le rayon qui casse

Un moteur-roue de 2 000 W, c’est un moyeu de vingt et un centimètres de diamètre lacé dans une jante par des rayons courts et épais : 160 mm hors tout, 2,6 mm de diamètre, trente-six au total, croisés une fois. Quand l’un d’eux casse, ce n’est jamais une surprise pour la roue, seulement pour le cycliste. J’en étais à ma deuxième roue : la première avait fini de la même façon, un rayon, puis deux, puis une jante qui se dévoile et qu’on ne rattrape plus.

Un rayon ne casse presque jamais parce qu’il est trop tendu. Il casse parce qu’il ne l’est pas assez : à chaque tour de roue, quand il passe en bas, la charge le détend, et un rayon qui se détend et se retend des milliers de fois par kilomètre finit en fatigue, le plus souvent au coude, dans le trou du flasque. La bonne réponse n’est donc pas de remplacer le rayon cassé, c’est de savoir à quelle tension sont les trente-cinq autres, et de les amener tous au même niveau, le bon.

Le problème, c’est que ce niveau, personne ne me le donnait. Égaliser à l’oreille, en faisant sonner les rayons, c’est une vieille méthode qui marche pour égaliser, mais qui ne dit rien de la valeur absolue : une roue entière trop tendue sonne aussi bien qu’une roue entière trop détendue, et sur les forums de vélos électriques, les jantes fendues par excès de tension sont aussi courantes que les rayons cassés par défaut. Il me fallait une mesure.

Acte II : pourquoi pas un tensiomètre du commerce

Un tensiomètre de vélo classique, le modèle à 18 euros comme le modèle à 80, fonctionne en fléchissant le rayon entre deux appuis espacés d’une soixantaine de millimètres avec un ressort calibré, et une table convertit la flèche lue en tension. Ça marche bien sur un rayon de vélo de 2 mm et de 280 mm de long, parce que ce rayon-là, laissé à lui-même, ne résiste presque pas à la flexion : ce que l’appareil mesure, c’est bien la tension qui le raidit.

Sur mon rayon de 2,6 mm, c’est une autre histoire. La raideur propre d’une tige en flexion croît comme la puissance quatre de son diamètre : passer de 2 à 2,6 mm la multiplie par presque trois. Sur 60 mm d’appuis, la part de la tension dans ce que l’appareil mesure tombe à moins de la moitié ; le reste, c’est le rayon lui-même qui se défend, tension ou pas. Et la table papier de ces appareils s’arrête de toute façon avant 2,6 mm. J’aurais eu un chiffre, mais pas une mesure.

La solution tient en deux idées. D’abord fléchir sur une portée aussi longue que possible, parce que la part de la tension grandit avec la portée : sur 125 mm au lieu de 60, elle passe de 45 % à plus de 70 % pour un rayon libre. Ensuite, remplacer le ressort par une force vraiment reproductible. J’avais une clé dynamométrique à déclic de 3 à 20 Nm dans un tiroir. Un déclic, c’est un couple connu, le même à chaque fois, à 4 % près. Avec un levier, c’est une force connue.

Acte III : la conception, et ses fausses pistes

Le principe est resté le même du premier croquis à l’outil soudé : trois points de contact sur le rayon, deux d’un côté aux extrémités de la portée, un au milieu de l’autre côté, porté par un bras que la clé fait tourner autour d’un pivot. La clé déclenche, le bras a poussé le rayon avec une force fixée, et la flèche qu’il a prise dépend de sa tension.

Ce qui a changé, ce sont tous les détails, et je les ai travaillés sur un modèle paramétrique en 3D, avec un assistant IA pour tenir le modèle, l’ouvrir dans Blender et faire les calculs à chaque itération. Quelques fausses pistes valent d’être racontées, parce qu’elles sont instructives.

La première version était imprimée en plastique. Le calcul l’a tuée avant l’impression : pour 1,5 mm de flèche à mesurer sur le rayon, le bras en PLA fléchissait de 2,5 mm. Tout le chemin d’effort est passé en acier.

La deuxième fléchissait le rayon hors du plan de la roue, vers l’extérieur, parce que c’était plus facile à construire. Je l’ai refusée : un rayon travaille dans le plan de la roue quand le moteur pousse, et je voulais le mesurer dans ce sens-là. Pour un rayon rond les deux sont équivalents, mais ce n’était pas naturel, et le pivot aurait été à un endroit impossible une fois l’outil posé sur une vraie roue, avec les rayons voisins qui passent à 24 mm.

Les appuis sont des roulements, pas des pions. La littérature sur les tensiomètres est claire : le frottement du rayon sur ses appuis fausse la lecture, et de beaucoup. Deux roulements de roller, 22 mm de diamètre, 8 mm d’alésage, coûtent presque rien et roulent sans frotter. Le troisième point est une simple fourche, parce qu’il ne bouge pas.

Le déclic relâche la charge. C’est en animant le mécanisme dans Blender que ça m’a sauté aux yeux : une clé à déclic prend environ trois degrés de jeu au moment où elle déclenche, et le couple chute. Le rayon, lui, ne demande que deux degrés au bras pour revenir. Si on lisait la position du bras après le déclic, on lirait n’importe quoi. D’où une lecture au maximum retenu : la tige de profondeur d’un pied à coulisse, poussée par le bras, reste là où le bras l’a amenée quand il recule. On lit le maximum, celui du déclic.

Acte IV : l’outil soudé

Entre le modèle et l’atelier, l’outil a encore changé, comme toujours quand on a des plats d’acier, un poste à souder et une boîte de boulons sous la main plutôt que l’inventaire exact du modèle. Le modèle 3D a été recalé ensuite sur l’outil réel, cote par cote, photos à l’appui. Voilà ce qui existe.

Le bâti est un tube carré de 25 mm qui se pose au-dessus du rayon, à 6 mm de lui, et qui reste entièrement hors de la nappe des rayons voisins. Seuls trois éléments descendent au niveau du rayon : la fourche à l’extrémité côté moyeu, une fente de 3,5 mm pendue sous le bout du tube, et les deux roulements, chacun au bout d’un boulon vertical. Le premier roulement, A, est au bout d’un boulon soudé sous le tube, à 125 mm de la fourche. Le second, B, de l’autre côté du rayon, à 60 mm de A, est au bout d’un boulon soudé au bras mobile.

Le bras mobile est un plat de 4 mm posé au-dessus du tube. Il pivote sur un boulon laissé glissant, X, planté dans une plaque de 4 mm soudée sur le tube, à 15 mm de A et 46 mm de B. Une douille soudée sur le bras, à 25 mm de A, reçoit le carré de la clé dynamométrique, dont le manche part radialement vers la jante. Quand la clé pousse, le bras tourne autour de X et B appuie sur le rayon avec le couple divisé par 46 mm : 111 N à 5 Nm, 156 N à 7.

Le pied à coulisse est glissé entre le bras et le tube, à côté de la plaque du pivot, et sa tige de profondeur vient toucher le boulon de B. Il lit directement le déplacement de B par rapport au tube, c’est-à-dire la flèche du rayon par rapport à la corde qui joint ses deux appuis fixes, A et la fourche.

Acte V : les premiers chiffres, et une leçon de mécanique

Première surprise, et c’est celle qui m’a appris le plus. Sur un rayon libre, tenu en l’air dans l’outil, j’ai lu 3,4 mm à 3 Nm, 4,6 mm à 5 Nm et 5,9 mm à 7 Nm. Trois points parfaitement alignés, 0,625 mm par Nm, mais une droite qui ne passe pas par zéro : il y a 1,5 mm de lecture avant que le rayon ne commence à se défendre. C’est le jeu de montage, la fente de 3,5 sur un rayon de 2,6, le pivot glissant, les boulons. Il est constant, du moins ces trois fois-là, et il se retranche. Mais il interdit de lire une mesure seule sans l’avoir caractérisé.

Deuxième surprise : cette pente était deux fois et demie plus faible que ce que prévoyait le calcul pour un rayon de 2,6 mm libre sur deux appuis. J’ai d’abord cherché où partait le couple. Il ne partait nulle part. C’est la poutre qui était fausse : un rayon qu’on tient par le bout entre deux doigts n’est plus libre, et surtout, un rayon monté dans une roue a ses extrémités tenues, le coude dans le trou du flasque à 20 mm de la fourche, l’écrou dans la jante à 15 mm du galet A. Avec des bouts tenus aussi près des appuis, la raideur en flexion est quatre fois celle d’une poutre libre. Du coup la part de la tension dans ce que lit l’outil retombe à 40 % environ vers 1 000 N. C’est moins qu’espéré, mais c’est encore largement mesurable.

Sur le rayon monté, j’ai lu 3,8 mm à 7 Nm. Une fois le jeu retranché, il reste 2,3 mm élastiques, et le modèle les convertit en 850 N environ, entre 640 et 1 140 selon que le jeu vaut vraiment 1,2 ou 1,8 mm. Pour un rayon de 2,6 mm sur un moteur-roue, l’ordre de grandeur couramment visé est de 1 000 N. Ce rayon-là n’est donc pas loin, mais ce chiffre reste un calcul, pas une mesure : la position exacte des appuis et l’encastrement réel du coude pèsent 20 % sur le résultat. Pour comparer les rayons entre eux, le modèle suffit. Pour des newtons, il faudra un banc.

Et la contrainte dans le rayon, parce que l’outil peut plier ce qu’il mesure. Le rayon libre a pris 6,7 mm de flèche vraie sur 125 mm à 7 Nm sans garder de courbure, ce qui correspond à 1 300 MPa en surface : la limite élastique d’un rayon étiré, pas plus haut. Sur un rayon monté et détendu, 7 Nm montent à 1 500 MPa. Le bon réglage est 5 Nm : entre 800 et 1 100 MPa quelle que soit la tension, 0,07 mm de lecture pour 100 N autour de 1 000 N, et la clé dans la zone de sa plage où ses 4 % sont garantis. Ces 4 % de couple se lisent comme 8 % de tension, c’est l’incertitude dominante, et aucun levier ne la réduit. Pour égaliser une roue, c’est suffisant.

Lecture attendue au pied à coulisse à 5 Nm, jeu de 1,5 mm compris, pour un rayon monté :

La courbe s’aplatit vers les fortes tensions : au-delà de 1 200 N, l’outil distingue mal. Pour ma roue, ce n’est pas le problème.

Acte VI : ce qu’il reste à faire

Tout ce qui précède repose sur une poignée de relevés. La prochaine étape, c’est de faire parler l’outil sérieusement, dans cet ordre.

1. Dix mesures à 5 Nm sur un même rayon, sans toucher l’écrou, coulisseau remis à zéro entre chaque, manche de la clé toujours dans la même direction. C’est la dispersion réelle de l’outil, celle qui compte.
2. Cinq mesures à 3 Nm sur le même rayon, pour vérifier que le jeu de 1,5 mm ne bouge pas.
3. Un point de contrôle à tension nulle, sur le rayon libre, en ne tenant que le tube cette fois.
4. Un banc d’étalonnage : un profilé, un rayon de rechange, un peson, de 600 à 1 200 N. C’est lui qui transformera les millimètres en newtons sans passer par le modèle.
5. Puis le relevé des trente-six rayons, la recherche de la tension cible, et le remplacement du rayon cassé, en notant exactement où il a cassé.

Si vous cassez des rayons sur un moteur-roue, retenez surtout ceci : le son ne vous donnera pas le niveau, un tensiomètre de vélo classique non plus sur du 12G, et un rayon monté se comporte autrement qu’un rayon libre. Le reste, c’est de la ferraille, une clé à déclic et un pied à coulisse.

La version du 19 septembre, fermée, vélos chargés. Essieu de Cordoba, caisse de 2,30 × 1,61 m, timon de 2 m avec le mât de levage démonté et couché dessus. Celle que j’ai finalement retenue est plus bas : elle fait 1,30 m de moins en hauteur.

Le cahier des charges tient en une phrase

Quand on part grimper, surfer ou marcher en famille, le T5 se remplit vite. L’idée : sortir de l’habitacle tout ce qui encombre — la cuisine, le frigo, le matériel, les vélos — et le mettre dans une remorque pensée pour ça, où chaque chose a sa place et s’ouvre sans déballer le reste.

Je l’ai décrit d’une traite, à peu près comme ça : un essieu de Mini ; au niveau zéro, des tiroirs de cuisine d’un côté (évier et petit réchaud), le frigo et sa bouteille de gaz de l’autre ; au niveau au-dessus, un grand bac pour la grimpe, le surf et les bâtons de marche, fermé par un couvercle sur charnières de coffre tenu ouvert par des vérins à gaz ; enfin, sur le dessus, trois emplacements pour nos trois vélos, montés par une rampe amovible rangée sous la remorque.

C’est une IA (Claude) qui a transformé cette phrase en modèle 3D : un script Python qui construit la remorque pièce par pièce dans Blender, avec toutes les cotes en tête de fichier. Je n’ai pas ouvert Blender pour la dessiner. J’ai regardé les images, corrigé, précisé — et c’est précisément quand on est passé des images aux chiffres que le projet a changé.

Trois étages, un par usage

Le principe est celui d’une commode : ce qui est lourd en bas, ce qui est encombrant au milieu, ce qui est léger et volumineux en haut.

Les cotes principales de la version retenue. Le plancher est haut (0,75 m) parce que la caisse passe au-dessus des roues : c’est ce qui permet une caisse plus large que la voie.

Le rez-de-chaussée, côté trottoir, c’est la cuisine. Un volet se relève et sert d’auvent. Dessous, deux tiroirs bas coulissent vers l’extérieur : l’un porte l’évier et son robinet, l’autre un réchaud deux feux. Leur dessus forme le plan de travail, à 0,95 m du sol, la hauteur d’une cuisine. Ce n’est pas un hasard : la hauteur de ces tiroirs est calculée à partir de la hauteur du plancher, qui dépend de l’essieu. Changez d’essieu, le plan de travail reste à 0,95 m. Au-dessus, deux tiroirs pour la vaisselle et l’épicerie ; au bout, une colonne pour deux jerrycans de 20 L, une pompe 12 V et la batterie.

Côté cuisine, vélos en place. Tout s’ouvre sans rien décharger du toit.

De l’autre côté, le frigo et le gaz. Un frigo trimixte de 40 L (12 V, 230 V, gaz) sur une coulisse extractible, pour l’ouvrir par le dessus une fois sorti. À l’avant, un coffre étanche vers l’intérieur et ventilé vers l’extérieur — grilles haute et basse sur la porte, grille au plancher, parce que le propane est plus lourd que l’air — pour une bouteille de 6 kg. À l’arrière, la table et les chaises pliantes.

Côté frigo. La bouteille est isolée du reste par une cloison, avec sa propre ventilation.

Au-dessus, le bac. 2,26 m de long à l’intérieur : de quoi coucher une planche de surf de 7‘0, un crash-pad, les cordes, les sacs et les bâtons. Le couvercle pivote sur trois charnières de coffre et tient ouvert à 82° grâce à deux vérins à gaz.

Le bac ouvert, sans les vélos — et ce n’est pas un choix de mise en scène.

C’est la première chose que le modèle m’a apprise, avant même le moindre calcul : les vélos sont posés sur le couvercle. Tant qu’ils y sont, le bac ne s’ouvre pas. La cuisine et le frigo, si. C’est une contrainte à assumer (on charge le bac avant les vélos) ou à contourner (une galerie fixe sur montants et des trappes latérales), mais pas une chose qu’on découvre sur le parking du site d’escalade.

Mise à jour du 21 septembre : contrainte levée. Les vélos ont quitté le couvercle, et le bac s’ouvre vélos chargés — voir Les vélos descendent du toit.

Le premier jet était beau, et il ne prouvait rien

La première version sortait des images propres en une soirée. Essieu de Mini, caisse de 2,30 × 1,45 m, timon de 1,35 m, essieu placé « un peu en arrière du milieu pour avoir du poids sur la boule », rampe télescopique de quatre éléments pour monter les vélos. Tout avait l’air plausible.

Et c’est exactement le problème : un rendu propre ressemble à une validation. Rien sur ces images ne disait combien pèse la remorque, ce que l’essieu supporte, ni comment elle se comporte à 130 km/h derrière un fourgon. J’ai donc demandé ce qu’un carrossier aurait demandé : la répartition des masses calculée pour de bon, et une flèche assez longue pour manœuvrer facilement avec mon T5 long.

Le calcul est un second script, indépendant de Blender. Il reprend chaque élément — cadre, timon, panneaux, tiroirs, frigo, eau, gaz, matériel, vélos — avec sa masse estimée et sa position, et en tire le centre de gravité, la charge sur la boule et sur l’essieu, pour cinq cas de chargement : à vide ; chargée sans vélos ; chargée avec vélos ; au retour, eau et vivres consommés ; et avec des vélos électriques.

Premier résultat : la remorque pèse 416 kg à vide dans sa version la plus légère (cadre en tube 50×30, contreplaqué de peuplier de 15 mm). Chargée avec les vélos, 582 kg. La toute première estimation, faite à la louche avant ce calcul, annonçait 260 à 400 kg à vide : le bas de la fourchette était très optimiste.

L’essieu de Mini n’a pas passé les chiffres

Mon essieu, c’est le train arrière d’une Mini classique : un berceau, deux bras tirés, des cônes en caoutchouc en guise de ressorts, des roues de 10 pouces. C’est compact et léger. C’est aussi le train arrière d’une voiture de 650 kg, qui porte en temps normal 250 à 300 kg — et de l’ordre de 450 kg au maximum.

Chargée avec les vélos, la remorque met 541 kg sur son essieu ; 563 kg avec des vélos électriques. Soit 20 à 25 % au-dessus de ce que le train est censé porter, en permanence, sur autoroute. Même en allégeant tout ce qui peut l’être, on ne descend pas sous le seuil avec une cuisine, un frigo, 40 L d’eau et trois vélos.

J’avais deux autres options sous la main ou à portée : un train arrière de Peugeot 205 ou 206, et celui de Seat Cordoba 1.9D (première génération). Le calcul les passe tous au même crible :

Les charges maximales sont des ordres de grandeur ; la vraie valeur « essieu AR » se lit sur la plaque constructeur de la voiture donneuse.

La même remorque sur les quatre trains, générée en changeant une seule variable. La caisse s’élargit d’elle-même pour couvrir les roues. Le Cordoba y est dessiné avec des ressorts séparés, posés sur les bras : ce n’est pas le montage de la voiture (voir la correction).

Sur le papier, le Cordoba l’emporte : la plus grosse marge de charge, des roues de 13 pouces qui encaissent mieux les nids-de-poule et chauffent moins leurs roulements à 130, une voie large. Et sa suspension devrait travailler dans sa plage d’origine : l’arrière d’une Cordoba diesel est dimensionné pour des charges du même ordre que celles de la remorque (430 à 610 kg selon le chargement). Bonus que je n’avais pas vu venir : sur ce type d’essieu, la poutre qui relie les deux bras se tord quand une roue monte et l’autre pas — elle fait office de barre anti-roulis, exactement ce qu’on veut avec des vélos perchés en hauteur.

Correction : les ressorts prennent bien de la place

Ajout du 19 septembre 2026, le jour même de la publication.

La première version de ce billet disait ici que les ressorts hélicoïdaux du Cordoba « ne coûtent pas un centimètre de hauteur » : ils devaient se loger entre le bras de suspension et le dessous du cadre, dans la trentaine de centimètres que le pneu laisse de toute façon libre sous le plancher. C’est ce que montre le rendu ci-dessus, avec ses ressorts rouges.

En relisant, j’ai tiqué : sur la voiture, le ressort remonte dans la caisse, bien au-dessus de la roue. Vérification faite sur un guide de démontage de la Polo 6N, qui partage sa plateforme avec la Cordoba 6K, c’est bien ça. Le ressort entoure l’amortisseur, les deux forment un combiné, et sa tête se boulonne dans le coffre, en haut du passage de roue, derrière les garnitures. En bas, un œil horizontal le fixe à la poutre, près du moyeu. L’IA avait raisonné sur un ressort séparé posé sur le bras, comme on en trouve sur d’autres essieux de ce type, sans vérifier sur cette voiture-là. Et le rendu propre a rendu l’hypothèse crédible : exactement le piège décrit plus bas.

La conséquence : entre l’œil du bas et le dessous du cadre, il reste environ 38 cm, et le combiné est nettement plus long. Il dépasserait dans le niveau 0, précisément sous le tiroir réchaud d’un côté et sous le frigo de l’autre. Quatre façons de s’en sortir, que je n’ai pas encore tranchées :

• séparer ressort et amortisseur : garder la poutre et les bras du Cordoba, poser le ressort seul dans une coupelle sur le bras (boulonnée plutôt que soudée, sur une pièce de suspension) et une autre sous le cadre, avec un amortisseur court monté à part ;
• des tourelles dans le niveau 0, en réorganisant la cuisine et le côté frigo autour de l’essieu ;
• monter le plancher de ce qui dépasse : le plus simple, mais les vélos et le centre de gravité montent d’autant, alors que le vent latéral est déjà le point faible ;
• revenir au train de 205, dont les barres de torsion logent dans le tube et les amortisseurs sont couchés : aucun problème de hauteur, mais une marge de charge mince avec des vélos électriques.

Pour choisir, il me faut trois mesures sur l’essieu : la longueur du combiné monté, celle du ressort seul au repos, et la hauteur de l’œil inférieur par rapport au centre de la roue.

Mise à jour du 21 septembre : le calcul a depuis ramené ces trois mesures à une seule. Voir Le Cordoba, ramené à une cote.

Tenir la route derrière le T5

La règle qu’on entend partout : du poids sur la flèche, sinon la remorque louvoie. Encore faut-il savoir combien. J’ai visé 7 % de la masse sur la boule en charge complète. Le calcul place alors l’essieu à 1,20 m de l’arrière de la caisse — 5 cm devant le milieu, là où le premier jet l’avait mis 17 cm derrière, au jugé. Selon le chargement, la charge sur la boule reste entre 5,8 et 7,6 %, soit 31 à 45 kg, loin des 100 kg qu’accepte l’attelage du T5.

Pour le louvoiement lui-même, le calcul utilise un modèle classique de dynamique : la voiture et la remorque vues d’en haut, reliées par la rotule, chacune avec sa masse, son inertie et ses pneus qui dérivent. On cherche la vitesse à partir de laquelle une petite oscillation, au lieu de s’amortir, s’amplifie.

Résultat : au-delà de 400 km/h. Dans tous les cas de chargement, avec tous les essieux, et même en plaçant l’essieu pour avoir un poids sur flèche nul ou négatif.

Un résultat aussi confortable, je m’en méfie. Un modèle qui répond « tout va bien » quoi qu’on lui donne peut très bien être un modèle qui ne calcule rien. Alors on l’a testé sur un cas dont on connaît la réponse : une caravane de 1,5 t derrière une berline de 1,4 t. Le même modèle la fait décrocher vers 160 km/h avec 5 % sur la flèche, 110 km/h avec 3 %, 80 km/h avec rien — ce qui correspond à ce qu’on lit partout sur les caravanes. Le modèle sait donc prédire un décrochage ; s’il n’en trouve pas ici, c’est que le T5 pèse quatre fois la remorque. Le chien remue la queue, pas l’inverse.

Le vrai risque est ailleurs, et il est bien plus banal : le vent latéral. Trois vélos à près de 3 m de haut, une caisse de 1,20 m de flanc, une voie de 1,40 m. Au retour, quand l’eau et les vivres sont consommés, une rafale de travers de 55 km/h suffit à délester la roue au vent quand on roule à 110 km/h ; en courbe, une trentaine. (Correction du 21 septembre : la première version annonçait « environ 100 km/h ». Ce chiffre sortait d’un modèle maison, et il ne vaut que pour une remorque à l’arrêt. L’histoire de cette correction est racontée plus bas.) La consigne en découle : par vent fort annoncé, on roule moins vite, ou les vélos voyagent dans le T5.

Une flèche pour reculer sans y penser

Reculer avec une remorque courte est un exercice de nerfs : elle part en biais avant qu’on ait compris pourquoi. Ce qui compte, c’est le rapport entre deux longueurs : la distance de la boule à l’essieu de la remorque, et celle de l’essieu arrière du T5 à la boule (environ 1,10 m sur un T5 long). Plus ce rapport est grand, plus la remorque réagit lentement, et plus on a le temps de corriger.

Avec un timon de 2 m, la boule est à 3,10 m de l’essieu : un rapport de 2,8. Allonger encore ne fait gagner que peu (3,0 avec 2,20 m de timon) et coûte de l’encombrement (4,35 m hors tout, déjà 9,60 m pour l’ensemble avec le T5).

Deux erreurs de calcul, au passage, ont été plus instructives que les bons résultats. La première version du calcul annonçait qu’à fond de braquage, la remorque ferait un angle de 164° avec le T5 — autrement dit qu’elle le doublerait. Une rotation dans le mauvais sens ; corrigé, l’angle tombe à 51°. La seconde annonçait un contact entre la remorque et le T5 à 55°, quelle que soit la longueur du timon. Suspect : si la longueur ne change rien, c’est que ce n’est pas elle qui limite. C’était la tête d’attelage elle-même, à 25 cm de la boule — qui en réalité passe sous le pare-chocs, comme sur n’importe quelle remorque. Une fois ce point retiré, ce qui limitait vraiment est apparu : l’écartement du V du timon près de la boule.

D’où la forme retenue : une poutre centrale seule sur le premier mètre derrière la boule, le V ne s’ouvrant qu’au-delà. Le premier contact avec le T5 recule alors au-delà de 100° d’articulation. En tournant à fond, on n’en utilise que 51.

À fond de braquage, en régime établi : 51° entre le T5 et la remorque, avec une bonne marge avant le moindre contact. La remorque coupe le virage d’environ 1 m à l’intérieur de la trajectoire des roues arrière du T5.

Un détail que le modèle rend évident et auquel je n’aurais pas pensé : la remorque (1,61 m) est plus étroite que le T5 (1,90 m). En ligne droite, on ne la voit pas dans les rétroviseurs. Une caméra de recul sans fil, ou deux piquets-témoins aux angles arrière, font partie du projet.

Attelée. Les vélos dépassent le toit du T5 d’un mètre : à garder en tête devant les barrières de parking.

Monter trois vélos à près de 2 m

Mise à jour du 21 septembre : cette section décrit une solution abandonnée deux jours plus tard. Je la laisse, parce que le raisonnement qui tue la rampe reste valable — et parce que la bonne réponse était de ne plus monter les vélos du tout. Voir Les vélos descendent du toit.

La rampe de mon idée de départ est morte d’un simple calcul de trigonométrie. Les vélos reposent à près de 1,90 m ; pour une pente de 25°, déjà raide pour pousser un vélo, il faut une rampe de plus de 4,40 m — quatre éléments télescopiques, une béquille au milieu pour qu’elle ne plie pas, et un vélo électrique de 25 kg à pousser à bout de bras. Jouable à deux avec des vélos musculaires, pénible autrement.

L’alternative est venue de moi, et c’est celle qu’on a gardée : un mât amovible, une potence qui pivote en tête de mât, une poulie au bout. Le mât, en deux tronçons d’alu de 1,50 m, s’emmanche dans un fourreau soudé sur la poutre du timon, juste devant la caisse. La potence, 1,45 m de portée, couvre les trois gouttières et une prise au sol à côté de la remorque. Un treuil à main sur le mât, un câble qui passe par une poulie en tête puis par celle du bout de potence, et un palonnier accroché à la selle et à la potence du vélo pour qu’il monte à plat.

Le vélo de droite en cours de levage. Démonté, le mât et la potence se couchent sur le timon (visible sur les autres vues).

Deux contraintes sont sorties du modèle. La hauteur d’abord : pour qu’un vélo posé dans sa gouttière passe sous la poulie, palonnier compris, le mât doit monter à 3,45 m. Et l’ordre de chargement : le vélo du milieu en premier. Sinon il faudrait le faire passer par-dessus un autre, et aucun mât raisonnable ne monte assez haut. Enfin, une évidence qu’il vaut mieux écrire : on ne lève rien sur une remorque dételée et mal calée.

Mise à jour du 21 septembre : la Mini revient par deux, et le vent passe par la bibliothèque

Deux jours après la publication. Rien n’est construit, donc tout peut encore bouger — et ça a bougé.

Et avec deux essieux de Mini ?

Après la publication, on m’a soufflé une idée que j’avais écartée trop vite : puisqu’un berceau de Mini ne suffit pas, en mettre deux, l’un derrière l’autre, avec des élargisseurs de voie de 5 cm par roue. L’argument tenait en une ligne : la charge est doublée, la tenue de route bien supérieure, la résistance au vent latéral bien plus importante.

Ajouter la variante au modèle a pris une ligne de paramètres, comme pour les autres essieux. Restait à chiffrer chaque affirmation.

• La charge : vrai, et mieux que prévu. Chaque berceau porte 290 kg, soit 145 kg par roue — à peu près ce que porte une roue arrière de Mini sur la route. Chaque cône de caoutchouc travaille donc là où il a été conçu pour travailler. La marge passe de −25 % avec un seul berceau à +33 %, vélos électriques compris.
• La tenue de route : vrai, pour une raison précise. Deux essieux écartés de 80 cm s’opposent à la rotation de la remorque sur elle-même (le lacet) bien plus qu’un seul : le rappel exercé par les pneus est multiplié par 4,7. C’est ce qui calme une remorque après une rafale ou le passage d’un poids lourd.
• Le vent latéral : match nul. Le renversement ne dépend que de deux choses, la largeur de voie et la hauteur du centre de gravité. Le tandem gagne parce que ses roues de 10 pouces autorisent un plancher 11 cm plus bas, et reperd l’équivalent parce que sa voie reste plus étroite que celle du Cordoba.
• « La charge est doublée » : oui pour l’essieu, non pour la remorque. Ce qui plafonne la charge utile, c’est le poids total déclaré à l’homologation : au-delà de 750 kg, il faut des freins et un autre permis. Le tandem achète de la marge et de la durée de vie, pas des kilos à emporter.

La variante à deux berceaux de Mini. Tout le reste du modèle s’est adapté seul : caisse de 1,46 m, plancher à 0,64 m, vélos à 2,82 m au lieu de 2,93.

Et il a un prix. Le ripage, d’abord : pour pivoter, une remorque à deux essieux doit faire glisser ses pneus de côté. À fond de braquage, il faut 52 kg de poussée latérale à la boule. Le T5 ne s’en aperçoit pas ; moi si, le jour où je voudrai la déplacer à la main sur un emplacement de camping. Ensuite, un défaut connu de ce montage, que j’ai trouvé décrit chez les fabricants d’essieux : deux suspensions indépendantes ne se partagent pas la charge toutes seules. C’est la hauteur de la boule du T5 qui règle l’assiette — 5 cm d’écart, et l’essieu avant perd 51 kg pendant que l’arrière en prend 39 — et sur une bosse, un seul essieu encaisse presque tout. Les fabricants déclassent ces essieux d’environ 20 % quand ils les montent par deux ; ici chacun travaille à 65 % de sa charge, donc la règle est respectée. Enfin, 43 kg de plus à vide, et cinq pneus de 10 pouces à trouver, une taille devenue rare.

Le vent : trois objections, puis la méthode des ponts

Le passage sur le vent latéral, plus haut, était faux. Pas dans sa conclusion — les vélos sur le toit restent le point faible — mais dans ses chiffres. L’histoire de la correction m’a plus appris que la correction elle-même.

Le premier calcul était un modèle écrit à la main par l’IA : la poussée du vent sur le flanc de la remorque, comme sur un panneau. J’ai tiqué trois fois.

« J’ai vu des remorques hautes, sans suspension, qui ne souffrent pas du vent. » Vérification faite : la même caisse, sans les vélos, encaisse une rafale bien plus forte. Le problème n’est pas la hauteur de la caisse, ce sont les vélos : perchés à 2,30 m, ils font à eux seuls 41 % de l’effort qui cherche à coucher la remorque. Au passage, le modèle s’est révélé trop optimiste. Il oubliait qu’une remorque qui roule ne reçoit pas le vent de côté mais de trois quarts, additionné à sa propre vitesse, et qu’une caisse prise de biais est poussée bien plus fort qu’un panneau pris de face.

« Un vélo n’est pas un panneau plein. » Exact. Compté pièce par pièce — pneus, jantes, rayons, cadre — un vélo ne présente au vent que 34 % de sa silhouette. Et l’air passe au travers : il subit de la traînée, pas l’effet d’aile que subit la caisse. Les deux vélos sous le vent sont en plus abrités par le premier.

« Tu oublies le T5 devant, qui ouvre la voie. » Là, j’ai été étonné que ce soit moi qui y pense. Réponse : le T5 abrite bien la remorque… par vent faible. Son sillage part avec le vent, pas dans l’axe de la route. À 110 km/h, l’abri est complet sous 20 km/h de vent de travers, à moitié perdu à 40, presque nul à 60. Et les vélos dépassent de toute façon de son toit.

Trois corrections en trois objections : on tâtonnait. J’ai donc demandé ce que j’aurais dû demander d’emblée — comment font les gens dont c’est le métier ? Dix minutes de recherche ont suffi. La méthode existe, elle est publiée et en accès libre : c’est celle de Baker et Soper (2018), qui sert à décider à partir de quelle rafale on interdit un pont aux camions. Elle tient en trois lignes, elle repose sur des coefficients mesurés en soufflerie et en vraie grandeur, et elle contenait déjà ma troisième objection : une remorque mesurée derrière son camion ne gagne qu’environ 10 % d’abri.

Refait avec cette méthode, au retour et vélos sur le toit : une rafale de 55 km/h suffit à délester la roue au vent quand on roule à 110 km/h, 61 km/h quand on roule à 90. Remorque pleine et sans vélos : 85. Ces vitesses s’entendent à hauteur de remorque ; la météo annonce des rafales mesurées à 10 m de haut, et en terrain dégagé le vent est environ un quart plus faible au ras de la route. La méthode classe chaque véhicule par une « vitesse caractéristique » : avec ses vélos, ma remorque est plus vulnérable qu’un autobus à impériale vide, le premier véhicule qu’on arrête quand le vent se lève sur le pont de Queensferry, en Écosse. La consigne pratique : dès 80 km/h de rafales annoncées, on ralentit à 90, ou les vélos voyagent dans le T5.

Le modèle maison donnait 58 km/h au lieu de 55 : le bon ordre de grandeur, obtenu après trois rustines. Une part du calcul reste de mon cru, et elle est signalée comme telle : le traitement des vélos, faute de mesure publiée sur des vélos posés sur un toit.

Quand ça décroche

Ce que je voulais savoir, au fond, ce n’est pas ce que dit le Code de la route : c’est où sont les limites réelles. Le calcul en sort trois, réunies sur un graphique.

Les trois façons de décrocher, pour la variante à deux berceaux de Mini. Le Cordoba donne les mêmes courbes à quelques km/h près. Cliquer pour agrandir.

• Le vent. Pleine et sans vélos, rien ne décroche par temps normal : il faudrait 110 km/h de rafales annoncées pour l’inquiéter à 130 km/h. Avec les vélos, la marge fond.
• Le virage. La remorque verse entre 0,56 et 0,64 g d’accélération latérale, selon le chargement. C’est avant que les pneus ne glissent sur route sèche (0,8 g), mais après sur route mouillée (0,5 g). Autrement dit : sur le sec, elle se couche sans avoir glissé ; sur le mouillé, l’attelage glisse d’abord. Avec les vélos, 0,58 g, c’est 61 km/h dans une bretelle de 50 m de rayon.
• Le louvoiement. Pas de vitesse critique derrière le T5, même avec 120 kg mal placés tout à l’arrière. La courbe verte est le cas témoin, une caravane de 1,5 t derrière une berline du même poids : elle passe sous zéro vers 115 km/h.

Le Cordoba, ramené à une cote

Restait le problème laissé ouvert par la correction : le combiné ressort-amortisseur qui monte vers la caisse. En regardant ce qu’il y a à cet endroit dans la remorque, la contrainte s’est d’abord durcie : le tiroir du réchaud d’un côté et la coulisse du frigo de l’autre balayent le plancher juste au-dessus. Aucune saillie n’est tolérable, pas même un bossage.

Puis le calcul l’a desserrée. Sous la charge de la remorque (290 kg par roue), le ressort d’origine se comprime et le combiné ne mesure plus qu’environ 41 cm. Sa tête peut alors se loger dans l’épaisseur du cadre, 45 mm sous le plancher, sur une simple platine percée soudée entre deux longerons.

À une condition, et c’est la seule inconnue qui reste : que l’œil inférieur du combiné soit à moins de 1,5 cm au-dessus du centre de la roue. Je l’ai supposé 3 cm en dessous ; ça se mesure en cinq minutes sur la voiture, avant de la démonter. Si la cote est mauvaise, il existe des combinés filetés, réglables en hauteur, homologués pour cette voiture.

Le montage du Cordoba tel que le calcul le dessine maintenant : le combiné s’arrête dans le cadre, et deux chapes descendent chercher les articulations des bras.

Le vrai travail de chaudronnerie est ailleurs, et je ne l’avais pas vu. Comme la caisse passe au-dessus des roues, le cadre est à 67 cm du sol, alors que les articulations des bras de l’essieu sont à 33 cm. Il faut donc deux chapes descendantes de 35 cm, qui encaissent environ 1,6 kN·m sur un nid-de-poule pris vite : des caissons en tôle de 5 mm, une jambe de force vers l’avant, et un tube entre les deux pour tenir les efforts de côté.

Ce montage reste bien plus simple que le tandem : un train, quatre points de fixation, aucun réglage, des pneus qu’on trouve partout, et une remorque qu’on déplace encore à la main. Le tandem a plus de marge et un plancher plus bas. Je n’ai pas tranché.

Seconde mise à jour du 21 septembre : tout redescend

Le même jour, quelques heures plus tard. Deux questions de conception ont fait plus pour la remorque que tous les raffinements de calcul de la matinée.

Noyer l’essieu dans la caisse

Depuis le début, la caisse passait au-dessus des roues. C’est ce qui lui permettait d’être plus large que la voie, et c’est aussi ce qui perchait le plancher à 75 cm. D’où ma question : pourquoi ne pas faire comme la Seat elle-même, ou comme n’importe quelle camionnette ? Descendre le plancher entre les roues, laisser celles-ci monter dans des passages de roue à l’intérieur de la caisse, et construire les tiroirs autour.

Le plancher peut descendre jusqu’à frôler la poutre qui relie les deux roues : 0,51 m au lieu de 0,75. Tout le reste suit d’un bloc, 24 cm plus bas. Et les deux difficultés du montage, celles de la mise à jour du matin, disparaissent d’un coup :

• les chapes de 35 cm qui devaient descendre du cadre jusqu’aux articulations des bras n’en font plus que 10 : les paliers se boulonnent presque directement sous les longerons, comme sur la voiture ;
• la tête du combiné ressort-amortisseur n’a plus à tenir sous un plancher. Elle monte dans le passage de roue, exactement comme dans le coffre de la Seat. La fameuse cote à mesurer ne conditionne plus rien : elle fixe seulement la hauteur du passage de roue.

Le prix, c’est de la menuiserie et du cadre. Deux passages de roue de 73 × 36 cm, hauts de 20 cm, prennent une centaine de litres sur 2 400. Chaque volet latéral reçoit une encoche au droit de la roue. Et le cadre n’est plus un rectangle : la roue est sur le chemin des longerons de rive, donc deux longerons passent à l’intérieur des roues, et des traverses portent les flancs devant et derrière.

L’aménagement, lui, se réorganise selon une règle simple : ce qui se contente de peu de hauteur va au-dessus de la roue, ce qui en veut va devant ou derrière. Le tiroir du réchaud fait 22 cm de haut. Il était déjà au droit de l’essieu, il y reste, posé sur le passage de roue. L’évier gagne un tiroir profond, avec la place d’un bidon d’eaux grises dessous. Le frigo quitte le droit de l’essieu pour l’arrière — et comme tout a baissé, son couvercle passe de 1,27 m à 1,03 m : on peut enfin y plonger le bras.

Côté cuisine. Le tiroir du réchaud est posé sur le passage de roue ; l’évier et la colonne d’eau, de part et d’autre, descendent jusqu’au nouveau plancher.

Côté frigo. Le frigo est passé à l’arrière ; au-dessus de la roue, ce qui se range à plat.

Sur la route : le centre de gravité descend de 21 cm, le renversement en virage passe de 0,58 à 0,71 g, et la rafale limite à 110 km/h de 55 à 66 km/h.

L’idée ne se cumule pas avec celle du matin. Avec deux essieux de Mini, les passages de roue feraient 1,45 m de long, soit 63 % de chaque flanc : il ne resterait presque plus de tiroirs bas.

Les vélos descendent du toit

Seconde question : pourquoi s’acharner à monter trois vélos à près de 2 m ? On pourrait les poser sur un support derrière la remorque. Ou deux derrière et un devant, sur le timon.

Côté vent, il n’y a pas photo. Posés en travers à un mètre du sol, les vélos sont pris de bout par le vent de côté, et ils ne sont plus perchés : ils ne comptent presque plus dans le renversement. Mais c’est le poids sur la boule qui départage les emplacements, et là le calcul n’a pas dit ce que j’attendais.

Au milieu, le poids sur la boule pour chaque emplacement : un point par cas de chargement, entre les bornes de 4 et 10 %. Cliquer pour agrandir.

• Trois vélos à l’arrière : 40 à 60 kg à un mètre cinquante derrière l’essieu. Selon que la remorque est pleine ou vide, avec ou sans vélos, le poids sur la boule va de 3 à 10 % de la masse. Trop peu au retour avec des vélos électriques, trop quand on roule sans vélos. C’est exactement ce que les caravaniers reprochent au porte-vélos arrière.
• Trois vélos sur le timon : le défaut inverse. La boule se déleste dès qu’on roule sans vélos.
• Deux derrière, un devant : le vélo de devant compense ceux de derrière. Le poids sur la boule reste entre 5 et 8 % dans tous les cas, aussi sagement qu’avec les vélos sur le toit. Le plus lourd va devant.

Le louvoiement, lui, ne bouge pas. Trois vélos tout à l’arrière augmentent de 17 % l’inertie de la remorque en rotation, et derrière un T5 quatre fois plus lourd, ça ne change rien. Derrière une berline, ce serait une autre histoire.

Le porte-vélos, je le ferai moi-même, et il est d’une simplicité reposante : une plateforme, et une pince qui coulisse sur un rail dans l’axe de la remorque. On pose les vélos en travers, on avance la pince jusqu’à plaquer les cadres contre des butées fixées à la caisse, on goupille, on cadenasse — la pince fait antivol — puis on sangle les roues. Le modèle a fait apparaître deux détails. Le guidon doit être tourné d’un quart de tour. Et même manivelles à la verticale, la pédale dépasse de 14 cm : les butées sont donc déportées de 15 cm de la caisse, sinon c’est la pédale qui touche avant le cadre.

Le porte-vélos arrière. La pince coulisse sur le rail percé, dans l’axe ; goupille orange et cadenas sur le coulisseau ; sangles orange sur les roues ; feux et plaque répétés derrière les vélos.

Le même principe sur le timon, pour le vélo le plus lourd. En braquant à fond, il reste loin du T5.

Ce que ça change à l’usage compte plus que les chiffres. Le mât, la potence et le treuil de la section Monter trois vélos à près de 2 m n’existent plus : on charge un vélo à hauteur de taille. Et la première leçon du modèle — les vélos sont posés sur le couvercle, tant qu’ils y sont le bac ne s’ouvre pas — tombe elle aussi.

Le bac s’ouvre vélos chargés.

La version retenue

Cette fois j’ai tranché : train de Cordoba, caisse surbaissée, deux vélos derrière et un sur le timon.

Attelée. Tout l’ensemble passe sous le toit du T5.

À 0,79 g, le seuil de renversement rejoint la limite d’adhérence des pneus sur route sèche : la remorque glisserait avant de verser. Et à 1,63 m, tout l’attelage passe sous le toit du T5, donc sous les mêmes barrières de parking que lui.

Le prix : 74 cm de plus en longueur, des feux et une plaque à répéter derrière les vélos, des vélos exposés aux projections de la route, et un cadre plus compliqué à souder qu’un rectangle.

Caisse sur les roues contre caisse surbaissée, pour le Cordoba et pour les deux essieux de Mini. Cliquer pour agrandir.

Ce que je retiens

Un rendu n’est pas une vérification. Les premières images étaient convaincantes et reposaient sur un essieu en surcharge de 20 %. Ce qui a fait avancer le projet, ce n’est pas le modèle 3D, c’est la question « combien ça pèse, et où ».

Se méfier d’un résultat trop confortable. « Stable au-delà de 400 km/h » aurait pu être un bug. Le seul moyen de le savoir était de faire tourner le même calcul sur un cas dont on connaît la réponse. C’est le même réflexe qu’avec une somme de cotes qui tombe juste : la cohérence n’est pas une preuve.

Vérifier sur la vraie pièce. L’erreur des ressorts n’est venue ni d’un calcul ni d’un rendu, mais d’une généralisation (« sur ce type d’essieu, le ressort est posé sur le bras ») jamais confrontée à la voiture. Il a suffi de se souvenir de la voiture pour la voir, et d’un guide de démontage pour la confirmer.

Une erreur absurde est une bonne nouvelle. 164° d’articulation, on le voit tout de suite. Les erreurs dangereuses sont celles qui donnent un chiffre plausible — comme ces 55° qui ne dépendaient pas de la longueur du timon, et que seul ce détail trahissait.

Tout paramétrer. Changer d’essieu a pris une ligne : la caisse s’est élargie, le plancher a monté, les tiroirs de cuisine se sont raccourcis pour garder le plan de travail à 0,95 m, et le calcul a replacé l’essieu. Sur papier, c’était une semaine de gomme.

Chercher la méthode publiée avant d’en écrire une. (Ajout du 21 septembre.) Le calcul de vent a été corrigé trois fois avant que je demande ce qu’en disait la littérature. La réponse tenait en trois lignes et reposait sur des mesures ; le modèle maison, sur des hypothèses empilées. Une IA écrit un modèle physique plausible en trente secondes, et c’est bien le danger : rien ne la pousse à aller voir s’il existe déjà.

Une objection de terrain vaut une revue de code. Je ne sais pas calculer une portance latérale. Mais « j’ai vu des remorques hautes qui ne souffrent pas du vent », « un vélo n’est pas un panneau », « il y a un fourgon devant » : chacune de ces remarques a trouvé un vrai défaut. Il faut les faire, et exiger qu’elles soient vérifiées par le calcul plutôt que réfutées par un argument.

Le levier était l’architecture, pas le calcul. (Ajout du 21 septembre au soir.) Une matinée à raffiner le modèle de vent a déplacé le résultat de quelques km/h. Deux questions de conception — pourquoi la caisse est-elle si haute, pourquoi les vélos sont-ils sur le toit — l’ont fait passer de 55 à 91. L’IA optimisait avec application le projet que je lui avais donné ; elle ne l’a jamais remis en cause. C’était à moi de le faire, et j’ai mis deux jours.

Ce qui reste à faire

• Mesurer deux cotes sur la Cordoba, voiture sur ses roues : la hauteur de la poutre d’essieu (elle fixe les 43 cm sous le cadre, donc tout le reste) et celle de l’œil inférieur du combiné (elle fixe la hauteur du passage de roue). Relever en même temps la position des articulations des bras et le gabarit de perçage de leurs supports.
• Dessiner le cadre pour de bon : deux longerons à l’intérieur des roues, des traverses qui portent les flancs, un pont de tubes au-dessus de chaque roue, et l’étanchéité des passages de roue.
• Essayer le vélo de timon en vrai : il doit cohabiter avec la roue jockey et la porte du coffre à gaz.
• Relever la charge maximale de l’essieu arrière sur la plaque constructeur de la Cordoba, et vérifier l’état des silentblocs et des roulements.
• Peser. Les masses du calcul sont des estimations. La remorque finie passera sur une balance, flèche et essieu séparément, et l’essieu pourra encore glisser de quelques centimètres sur ses longerons avant soudure définitive.
• L’administratif. Chargée, la remorque dépassera 500 kg de PTAC : elle aura besoin de sa propre carte grise, donc d’une réception à titre isolé à la DREAL pour une construction artisanale. En restant sous 750 kg, pas de freins obligatoires et le permis B suffit. À confirmer, avec la masse remorquable et le PTRA inscrits sur la carte grise du T5.
• Construire léger. Chaque kilo gagné sur la caisse est un kilo de marge sur l’essieu et un peu de stabilité en plus par vent de travers.

Questions fréquentes

Peut-on utiliser un essieu de Mini pour une remorque ?

Oui, pour une petite remorque légère : c’est compact, bas, et les roues de 10 pouces permettent un plancher bas. Mais c’est le train arrière d’une voiture de 650 kg, prévu pour de l’ordre de 450 kg au maximum. Une remorque aménagée (cuisine, frigo, eau, vélos) dépasse facilement 500 kg sur l’essieu.

Quel poids sur la flèche viser pour une remorque ?

Entre 5 et 10 % de la masse de la remorque, et jamais moins de 4 % ni plus que ce qu’accepte l’attelage de la voiture (souvent 75 à 100 kg). Ici, 7 % en charge complète, soit environ 44 kg. On l’obtient en plaçant l’essieu, pas en ajoutant du lest.

Un essieu à ressorts hélicoïdaux prend-il plus de place ?

Ça dépend du montage. Un ressort séparé, posé sur le bras, tient sous le cadre quand la caisse passe au-dessus des roues. Un combiné ressort-amortisseur, comme sur la Seat Cordoba 6K ou la VW Polo 6N, monte au-dessus de la roue : il faut lui faire de la place dans la caisse, relever le plancher, ou le remplacer par un ressort et un amortisseur séparés. À vérifier avant de conclure : sous la charge, le ressort se comprime, et sur ma remorque le combiné d’origine tient finalement dans l’épaisseur du cadre, à une cote près.

Quelle longueur de timon pour reculer facilement ?

Ce qui compte est le rapport entre la distance boule–essieu de la remorque et la distance essieu arrière–boule de la voiture. Au-dessus de 2,5, la marche arrière devient confortable ; ici, 2,8 avec un timon de 2 m. La forme compte autant que la longueur : une poutre centrale seule près de la boule évite que le V du timon touche la voiture en braquage serré.

Une remorque légère derrière un fourgon peut-elle louvoyer ?

Très peu probable si le fourgon est nettement plus lourd : le calcul ne trouve pas d’instabilité en dessous de 400 km/h avec un T5 de 2,4 t et une remorque de 0,6 t. Le risque pratique est le vent latéral, et surtout ce qu’on perche sur le toit.

À partir de quel vent une remorque risque-t-elle de se renverser ?

Ça dépend de sa masse, de sa voie, de sa hauteur et de la vitesse à laquelle on roule. La méthode de référence est celle de Baker et Soper (2018), utilisée pour les restrictions de circulation sur les ponts. Pour ma remorque de 0,6 t : 85 km/h de rafale de travers à 110 km/h sans rien sur le toit, 55 km/h avec trois vélos. Ce sont des vitesses de vent à hauteur de remorque ; les rafales annoncées par la météo, mesurées à 10 m, sont plus fortes d’environ 40 %.

Deux essieux valent-ils mieux qu’un sur une petite remorque ?

Ils portent plus et tiennent mieux le cap : les pneus s’opposent près de cinq fois plus à la mise en lacet. En échange, la remorque ripe en manœuvre et ne se déplace plus à la main, elle pèse plus lourd à vide, et si les deux essieux sont indépendants (suspension caoutchouc), c’est la hauteur de la boule qui règle le partage de la charge : il faut la tracter bien de niveau.

Petit glossaire

Bogie, tandem — Deux essieux rapprochés montés l’un derrière l’autre sous la même remorque.

Combiné ressort-amortisseur — Un amortisseur autour duquel est enfilé le ressort ; les deux se montent et se démontent d’un bloc. Sa tête se fixe dans la caisse de la voiture.

Flèche (poids sur) — La charge verticale que la remorque exerce sur la boule d’attelage. Trop faible ou négative, elle déleste l’arrière de la voiture et favorise le louvoiement.

Louvoiement — Oscillation de la remorque de gauche à droite qui, au-delà d’une vitesse critique, s’amplifie au lieu de s’amortir.

Lacet — Rotation d’un véhicule autour d’un axe vertical : l’avant part à gauche, l’arrière à droite.

Poutre de torsion — Essieu où les deux bras tirés sont reliés par une traverse qui se tord quand les roues ne débattent pas ensemble ; elle joue le rôle de barre anti-roulis.

PTAC / PTRA — Poids total autorisé en charge (d’un véhicule) / roulant autorisé (d’un ensemble voiture + remorque). Inscrits sur la carte grise.

Ripage — Glissement latéral forcé des pneus quand une remorque à deux essieux tourne : ses deux essieux ne peuvent pas suivre le même cercle.

RTI — Réception à titre isolé : homologation, par la DREAL, d’un véhicule construit ou modifié à l’unité.

Timon — La partie avant de la remorque, du châssis jusqu’à la tête d’attelage.

Voie — Distance entre les centres des deux roues d’un même essieu.

Références et copies locales

• Le modèle complet, régénérable : scripts Blender et Python, remorque.blend, calcul détaillé — remorque-famille.zip
• Le calcul seul, lisible en ligne : CALCULS.md
• Les graphiques, en vectoriel : limites.svg, architecture.svg, velos.svg
• Baker & Soper (2018), The calculation of the overturning wind speed of large road vehicles at exposed sites (en anglais, accès libre) — la méthode de calcul du vent, et la mesure d’une remorque derrière son camion
• Mechanical Elements : les essieux à suspension caoutchouc montés par deux (en anglais) — pourquoi ils ne se partagent pas la charge
• Guide Autodoc : remplacer la jambe de suspension arrière d’une VW Polo 6N1 (en anglais) — la source de la correction sur les ressorts
• Le billet précédent — une autre pièce dessinée en dialoguant avec une IA, et le piège de la somme de cotes qui tombe juste

Le problème de la première contribution

Tout le monde donne le même conseil : « trouve une issue étiquetée good first issue ». C’est un bon conseil et il ne marche pas très bien, pour une raison simple — ces tâches sont soit triviales au point de n’apprendre rien, soit déjà prises par quelqu’un de plus rapide.

Ce qui marche mieux, je crois, c’est de partir de ce qu’on a que les autres n’ont pas. Dans mon cas : un vieux téléphone que j’avais décidé de faire tourner sous Linux, et donc du matériel physique sur lequel exécuter le code que d’autres écrivent à l’aveugle.

C’est un avantage plus rare qu’il n’y paraît. Beaucoup de développeurs travaillent sur des pilotes de matériel qu’ils ne possèdent pas, en se fiant à des fiches techniques et aux rapports des utilisateurs. Celui qui a l’appareil branché sur son bureau peut répondre à des questions que personne d’autre ne peut trancher.

Le fil : une tâche bien délimitée

Le projet postmarketOS maintient une liste de tâches par appareil. Pour le mien, une issue parapluie intitulée « Camera TODOs » listait une dizaine d’items, tous cochés sauf un :

imx355 driver (front camera) is missing features for libcamera, makes the later complain (e.g. when running cam -l)

Périmètre net, symptôme reproductible, une commande pour le constater. Exactement ce qu’on cherche.

J’ai lancé la commande sur le téléphone. Elle s’est plainte, comme annoncé. J’ai ouvert le dépôt de libcamera pour écrire le correctif.

Et l’entrée était déjà là.

Première leçon : une issue ouverte n’est pas forcément ouverte

Le support du capteur avait été ajouté le 17 juillet 2026, par un ingénieur de Raspberry Pi. La version installée sur mon téléphone datait du 10 juillet.

Sept jours d’écart. L’avertissement que je voyais n’était pas un manque dans le projet, c’était un décalage entre la version publiée et le dépôt.

C’est une confusion facile à faire, et elle mérite un réflexe : avant de coder quoi que ce soit, vérifier que le problème existe encore en amont, pas seulement sur sa propre machine. Ça se fait en deux requêtes.

F="src/libcamera/sensor/camera_sensor_properties.cpp"
for ref in v0.7.2 master; do
  echo -n "$ref : "
  curl -s ".../repository/files/$(urlencode $F)/raw?ref=$ref" | grep -c '"imx355"'
done
# v0.7.2 : 0
# master : 1

Deux tâches sur trois s’étaient donc évaporées. J’aurais pu m’arrêter là avec le sentiment d’avoir perdu ma soirée. Sauf qu’en lisant l’entrée fraîchement ajoutée, quelque chose n’allait pas.

Deuxième leçon : la relecture ne voit pas les tables

L’entrée associait deux motifs de test à des valeurs numériques. Or le pilote du capteur, dans le noyau, définit ces valeurs dans l’ordre inverse. « Couleur unie » et « barres de couleur » étaient interverties.

J’ai vérifié trois fois, par des chemins indépendants :

Et j’ai cherché activement le contexte où l’auteur aurait eu raison : son entreprise maintient son propre noyau, avec parfois des pilotes différents. J’ai vérifié — même ordre dans les deux arbres. L’erreur était réelle, y compris sur son propre matériel.

Ce qui rend cette histoire intéressante, ce n’est pas l’erreur. C’est que le commit avait été relu par quatre personnes, dont le mainteneur du projet, et portait la mention « testé » par une cinquième.

Comment cinq personnes compétentes laissent-elles passer deux valeurs interverties ?

Parce qu’il n’y a aucune logique à relire. C’est une correspondance entre deux documents qui ne vivent pas dans le même dépôt : une table d’un côté, un tableau de chaînes de caractères dans le noyau de l’autre. Pour la vérifier, il faut ouvrir les deux fichiers côte à côte, ou avoir l’appareil sous la main. Et « testé » signifiait ici la caméra fonctionne, je pointe l’objectif et j’obtiens une image — ce qui est vrai, et n’exerce jamais les motifs de test, qui sont un outil de diagnostic.

Le reste de l’entrée était juste. La taille du photosite, les délais du capteur : tout ce qui est exercé au quotidien était correct. Seule la partie que personne ne fait tourner était fausse.

C’est là que possède l’appareil devient un avantage décisif. Pas parce que je suis meilleur, mais parce que j’étais le seul à pouvoir poser la question au matériel.

Ce qu’un correctif de deux lignes doit contenir

Le correctif fait deux lignes. Son message de commit en fait trente, et c’est délibéré.

Un relecteur ne doit rien avoir à aller chercher. J’y ai donc mis le tableau du pilote noyau cité tel quel, la sortie de la commande qui interroge mon téléphone, la conséquence concrète en une phrase — demander une couleur unie produit des barres, et réciproquement — et l’argument de cohérence avec les deux capteurs correctement décrits.

Et j’ai devancé la question qui allait venir : « et les autres entrées, elles sont fausses aussi ? » Non, et je l’ai vérifié pilote par pilote : deux autres capteurs utilisent bien l’ordre inverse, parce que leurs pilotes le définissent ainsi. Une phrase dans le message évite un aller-retour de trois jours.

Fixes: a1db25dabaee ("libcamera: camera_sensor: Add Sony IMX355 sensor properties")

git rev-parse --short=12 <référence>

Le vrai travail, et la valeur qu’on ne peut pas prouver

Restait quelque chose de réellement absent : le second capteur du téléphone ne figurait nulle part. Ni dans la bibliothèque, ni dans le noyau officiel — son pilote a été écrit chez un fondeur il y a huit ans et n’a jamais été remonté en amont.

J’ai relevé les valeurs sur l’appareil et dans le code du pilote. Trois se déduisent rigoureusement. La quatrième, non : c’est un paramètre qui se lit dans une fiche technique, et les fiches techniques de ces capteurs ne sont pas publiques.

J’ai cherché à l’étayer. J’ai trouvé un fichier de configuration, sur mon propre téléphone, qui déclarait exactement la valeur que j’avais supposée. Excellente nouvelle pendant environ trois minutes — jusqu’à ce que je vérifie s’il était indépendant. Il ne l’était pas : les dix fichiers équivalents du projet déclarent tous la même valeur, y compris pour des capteurs de trois fabricants différents. Ce n’était pas dix mesures concordantes, c’était un défaut recopié dix fois.

Alors je l’ai écrit tel quel dans le message de commit : cette valeur suit ce qui est documenté pour les capteurs de la même famille. Pas « d’après la fiche technique », pas de formulation qui laisserait croire à une mesure. Un relecteur qui a la documentation la corrigera en un message, et c’est très bien.

Habiller une incertitude est la façon la plus efficace de perdre la confiance d’un projet dès son premier patch.

La prédiction que j’ai ratée

En lisant le code, j’avais compris ce que l’absence de ce capteur provoquait : sans lui, la bibliothèque ne convertit plus le gain de la caméra. Elle écrit un numéro de réglage là où elle devrait écrire un facteur d’amplification, et relit le numéro comme s’il était le facteur. La boucle d’exposition automatique est faussée dans les deux sens.

J’en ai déduit une prédiction : après correction, les photos en basse lumière devraient être meilleures. J’ai monté un protocole propre — téléphone calé et jamais déplacé, mesures objectives de luminance et de bruit, série avant et série après.

Résultat : 39,2 % de luminance avant, 38,1 % après. Rien.

L’explication tient à l’arithmétique, et je l’avais signalée comme un risque avant de lancer le test — sans en tirer les conséquences, ce qui était l’erreur.

L’erreur n’est énorme qu’à fort gain. Ma scène de test avait une zone blanche saturée : l’exposition automatique avait de la lumière à revendre, restait près de zéro de gain, et à cet endroit-là les deux formules donnent le même résultat.

Le patch reste correct, et il fonctionne — je l’ai vérifié autrement. Après installation, la bibliothèque n’émet plus aucun avertissement pour ce capteur, tandis que l’autre capteur du téléphone, non corrigé, les émet toujours tous. Un témoin négatif propre.

Mais je n’ai pas démontré d’amélioration visible, et je ne l’écrirai donc pas. La mention « testé » que je joindrai dira que le capteur est désormais reconnu. Pas que les images sont meilleures.

C’est une distinction qui paraît tatillonne et qui ne l’est pas. Un raisonnement correct sur un mécanisme ne dit rien de son amplitude dans les conditions du test. J’avais le mécanisme ; je n’avais pas l’amplitude.

La trouvaille qui ne figurait dans aucune liste

Pendant tout ce travail, l’application photo gelait régulièrement. Une nuisance, que j’ai d’abord contournée en relançant.

Puis j’ai instrumenté, faute de mieux. Et il s’est trouvé qu’une seule ligne, émise une fois à l’initialisation, expliquait tout :

Importing input DMABuf failed, falling back to upload

Le traitement d’image se fait sur le processeur graphique. Normalement, l’image brute lui est transmise sans copie, par partage de mémoire. Ici l’import échoue — et la bibliothèque bascule en mode recopie : douze mégapixels transférés vers le GPU à chaque image. Le bus mémoire sature, l’affichage n’obtient plus la bande passante pour ses propres opérations, et le pipeline finit étranglé.

Ce n’est pas un plantage. C’est un étouffement, ce qui explique pourquoi il ne laissait aucune trace exploitable.

Et voici ce qui donne à cette ligne toute sa valeur. Elle vient d’un correctif ajouté par le mainteneur du paquet, qui l’avait délibérément remise après que le projet amont l’eut retirée. Son argumentaire :

Les imports en échec dégradent massivement les performances et signalent des problèmes actionnables dans les pilotes V4L2 ou GPU.

Le mainteneur avait donc posé le détecteur, en écrivant noir sur blanc que son déclenchement mérite une investigation. Il s’est déclenché sur mon téléphone. Personne ne l’avait remonté.

Je n’ai pas encore prouvé la causalité — la corrélation est nette, le mécanisme cohérent, et un test simple trancherait. Mais c’est de loin la chose la plus utile que j’aie trouvée ce matin-là, et elle ne figurait dans aucune liste de tâches.

Ce que je retiens, pour une prochaine fois

Ce qu’on apporte, ce n’est pas du talent, c’est une position. Je n’ai été meilleur que personne. J’avais l’appareil branché, et cinq relecteurs compétents ne l’avaient pas. C’est tout, et ça suffit.

Vérifier que le problème existe encore avant d’écrire. Deux tâches sur trois s’étaient évaporées, corrigées en amont mais pas encore publiées. Deux requêtes l’auraient dit d’emblée.

Une source qui confirme n’est utile que si elle est indépendante. Dix documents qui recopient le même défaut ne valent pas mieux qu’un seul.

Séparer ce qui est démontré de ce qui est déduit — dans un message de commit comme dans une conversation. J’avais un mécanisme juste et une prédiction fausse ; dire l’un sans l’autre aurait été un mensonge poli.

Et instrumenter ce qui agace. Le gel de l’application était une nuisance que je contournais depuis des heures. C’est en cessant de la contourner que j’ai trouvé la seule chose que personne d’autre ne cherchait.

C’est bien une pelote de ficelle : on tire sur un fil de deux lignes, et il vient trois choses qu’on n’avait pas demandées.

Le point de départ : trois vues, sept cotes, et la pièce d’origine posée à côté. Tout ce que l’IA aura jamais de cette ventouse, c’est cette photo.

Le problème n’est pas de dessiner, il est de se comprendre

J’avais une ventouse en caoutchouc à refaire et une imprimante fraîchement calibrée. La modélisation elle-même n’est pas le sujet : une ventouse, c’est un disque, un cylindre, un téton et un perçage. N’importe quel logiciel de CAO la sort en dix minutes — à condition de savoir ce qu’on dessine.

Le sujet, c’est que je voulais la faire dessiner par une IA. Pas par confort : parce que je voulais voir où ça casse. Une IA qui écrit du code a la boucle de retour la plus courte possible — le code tourne ou pas. Une IA qui dessine une pièce mécanique n’a aucune boucle de retour : elle ne voit pas l’objet, ne peut rien mesurer, et son résultat ne devient faux qu’au moment où la pièce sort de l’imprimante et n’entre pas dans son logement. Tout ce qui se passe entre les deux est de la conversation.

Alors j’ai fait un croquis. Trois vues, cotées, propres : ce qu’on apprend à faire en dessin technique. Et c’est là que ça devient intéressant, parce que ce croquis est juste — et qu’il n’a pas suffi.

Six questions posées sur ma propre photo

Premier réflexe de l’IA, et il était bon : ne pas deviner. Elle a repris ma photo, y a posé six pastilles numérotées en rouge, et m’a renvoyé l’image avec ses six questions rattachées à des endroits précis du dessin.

Les six ambiguïtés, repérées sur le croquis lui-même. Annoter l’image plutôt que décrire en texte : c’est la seule chose qui a marché du premier coup dans toute cette histoire.

Cette méthode-là, je la connaissais déjà : elle vient du billet précédent, où décrire un geste de mesure en français m’avait bloqué deux fois de suite, et où annoter ma propre photo avait débloqué en un envoi. Ça marche dans les deux sens. Quand l’IA ne comprend pas mon dessin, elle doit me montrer où elle ne comprend pas, pas me demander « pouvez-vous préciser les dimensions ».

Et pourtant. J’ai répondu aux six questions, une par une, en une ligne chacune. « C’est une vue en coupe de la même pièce, elle matérialise l’épaisseur de la ventouse. » « C’est le trou, en dessous de la ventouse. » « Il fait 3 mm de diamètre et 4 de profondeur. » « Il est borgne. » Six réponses exactes, sans ambiguïté. Au terme de quoi la géométrie était toujours fausse.

Ce qui manque à un croquis, ce ne sont pas les cotes

Voilà le nœud. Mon croquis portait toutes les cotes nécessaires. Ce qu’il ne portait pas, c’est à quoi chaque cote se rattache — et ça, c’est précisément ce qu’un dessin à main levée ne dit pas, alors qu’un plan coté normalisé le dit par la position des lignes d’attache.

Un exemple. J’avais écrit « 6,5 mm » avec une flèche verticale sur la droite de ma coupe. Pour moi, évident : c’est la hauteur du fût. Pour l’IA, tout aussi évident : c’est la hauteur hors-tout, puisque la flèche va d’un bout à l’autre du dessin. Les deux lectures sont défendables sur une photo prise de biais, où la flèche déborde un peu.

Même chose pour le trou et le téton, qui font tous les deux 3 et quelques millimètres, aux deux extrémités de la pièce. J’ai écrit « 3 » d’un côté et « 3,5 » de l’autre en sachant lequel était lequel. Rien sur le papier ne le disait.

Ce qui marche : lui faire montrer, pas lui faire dire

Au bout du sixième échange, changement de méthode : au lieu de me poser une septième question, l’IA a modélisé la pièce avec ses hypothèses, sorti un rendu, et me l’a envoyé — avec un code couleur explicite sur la coupe cotée : en rouge les cotes qui viennent de moi, en cyan celles qu’elle avait inventées.

J’ai regardé le rendu trois secondes et j’ai écrit : « du sommet du téton au bord de la lèvre, la ventouse fait 10,5 mm. 2 mm de téton, 6,5 mm de fût, 2 mm de corps de ventouse. »

La même pièce, les mêmes cotes, deux lectures. À gauche ce que l’IA avait compris ; à droite ce que j’avais dessiné. Aucune question n’aurait produit cette phrase — c’est le dessin faux qui l’a produite.

C’est le renversement intéressant. Une question ouverte (« la cote 6,5, elle mesure quoi ? ») me demande de reconstruire mentalement le contexte, de retrouver ce que j’avais en tête trois jours plus tôt, et de formuler une réponse dans le vide. Un rendu faux me met la géométrie sous les yeux, et mon œil corrige plus vite que ma mémoire. La correction ne coûte plus rien : je vois que le fût est écrasé, donc je sais quoi dire.

Il y a une condition pour que ça marche, et elle n’est pas anodine : l’IA doit signaler ce qu’elle invente. Un rendu propre, sans distinction entre ce qui vient de moi et ce qu’elle a comblé, m’aurait fait valider une pièce dont je n’aurais pas vu qu’elle contenait cinq valeurs sorties de nulle part. Le cyan sur la coupe, c’est l’aveu d’ignorance rendu visible. C’est ce qui rend le rendu utilisable comme instrument de mesure plutôt que comme illustration.

Le piège de la somme qui tombe juste

Voici la partie que je trouve la plus instructive, et elle mérite qu’on s’y arrête.

Quand l’IA a produit sa deuxième version — celle avec le fût, encore fausse — elle m’a expliqué qu’elle avait enfin réussi à placer la dernière cote orpheline de mon croquis, le fameux 3,5. Sa démonstration : la coupelle fait 1,0, le fût 3,5, le téton 2,0, total 6,5, exactement la hauteur hors-tout du dessin. Toutes les cotes se refermaient entre elles. Elle a écrit, et c’était sincère : « tes cinq cotes se referment entre elles, ce qui est plutôt bon signe pour ma lecture ».

Sauf que c’était faux. Le 6,5 n’était pas le hors-tout, le 3,5 n’était pas la hauteur du fût, et la pièce reconstruite ne ressemblait à rien. La bonne lecture donne 2 + 6,5 + 2 = 10,5, et le 3,5 est le diamètre du perçage — une cote qui n’a rien à voir avec un empilement de hauteurs.

Une somme qui tombe juste n’est pas une preuve. Avec sept cotes et une pièce à symétrie de révolution, il y a assez de degrés de liberté pour que des combinaisons fausses se referment par hasard. La cohérence arithmétique est un indice faible, et c’est exactement le genre d’indice faible qu’une IA présente avec assurance parce qu’il ressemble à une vérification. C’est un raisonnement qui a la forme d’une preuve sans en avoir la force.

Ce qui a tranché, ce n’est pas un calcul : c’est que la pièce dessinée ne ressemblait pas à la pièce posée sur la table. Le seul juge, dans cette affaire, c’est l’objet.

Quand c’est un mot qui bloque, il faut colorier

Un dernier blocage, d’une autre nature. Pour qu’une ventouse tienne, sa face inférieure ne doit pas être plate : elle remonte légèrement vers le centre. J’appelle ça, faute de mieux, le « creux ». On appuie, l’air emprisonné s’échappe par la lèvre ; on relâche, le caoutchouc veut reprendre sa forme, la pression baisse dans la cavité, et la pression atmosphérique plaque la pièce. C’est tout le mécanisme.

Sauf que ma pièce a aussi un trou borgne au centre. Alors quand on m’a parlé de « creux », j’ai répondu : « tu appelles quoi le creux ? au centre de la ventouse tu as un trou de 3,5 mm par 4 mm de profondeur, c’est le retrait au centre de la ventouse ? »

Reformuler n’aurait rien donné — le mot était déjà pris. Ce qui a marché tient en une image :

Le creux, c’est le bleu. Le trou, c’est le blanc, à l’opposé. Colorier le volume dont on parle règle en une image ce que trois paragraphes n’auraient pas réglé.

La leçon générale : quand un échange bloque sur un mot, ce n’est pas une question de vocabulaire mais de référent. Il ne faut pas mieux définir le mot, il faut désigner la chose. En géométrie, désigner se fait avec une couleur.

Détail qui compte : sur ses premières coupes, l’IA dessinait le perçage comme un rectangle blanc qui débordait sous la pièce et dans le creux, « pour qu’on le voie bien ». Je le lui ai dit — cette vue-là était moins claire, parce qu’un trait qui déborde laisse croire à une géométrie qui n’existe pas, et il débordait précisément dans la zone qu’on essayait de discuter. Un schéma technique ne s’améliore pas en exagérant les traits ; il s’améliore en cadrant sur la zone utile et en coloriant les volumes.

La pièce

La pièce finie : coupelle Ø19,5, corps 2, fût Ø9 × 6,5, téton de centrage Ø3 × 2, perçage borgne Ø3,5 × 4. Hors-tout 10,5.

Le modèle est un script Python de 120 lignes qui utilise manifold3d, une bibliothèque de géométrie solide. La pièce étant de révolution, tout tient dans un profil (rayon, hauteur) qu’on fait tourner :

def profil(n=80):
    """Contour ferme (r, z) de la demi-coupe, sens antihoraire."""
    p = []
    r = np.linspace(0, R_INT, n)                    # dessous : concavite parabolique
    p += [(x, CREUX * (1 - (x / R_INT) ** 2)) for x in r]
    p += [(R_EXT, 0.0), (R_EXT, E_LEVRE)]           # levre : portee plate puis flanc
    r = np.linspace(R_EXT, R_FUT, n)                # dessus du corps, legerement bombe
    t = (r - R_FUT) / (R_EXT - R_FUT)
    p += [(x, E_LEVRE + (Z_FUT - E_LEVRE) * (1 - u) ** BOMBE) for x, u in zip(r, t)]
    p += [(R_FUT, Z_TET), (R_TETON, Z_TET), (R_TETON, H), (0.0, H)]
    return p

m = Manifold.revolve(CrossSection([profil()]), 128) - trou

Ce qui rend l’exercice tenable, ce n’est pas la bibliothèque : c’est que toutes les cotes sont des constantes en tête de fichier, avec en commentaire d’où vient chacune — croquis, déduction, ou hypothèse. Corriger une valeur et regénérer le STL prend dix secondes. Sur cinq allers-retours, c’est la différence entre une conversation et une corvée.

Dessiner pour le TPU, ce n’est pas dessiner une ventouse

La bobine qui a lancé toute l’affaire. L’étiquette annonce 20 à 40 mm/s — en précisant, un peu plus haut, qu’elle vise les imprimantes à extrudeur direct.

Une vraie ventouse est en silicone ou en PVC souple, autour de 40 à 60 Shore A. Le TPU le plus courant, celui que j’ai, est du 95A : à peu près la dureté d’une roulette de chariot. Ce n’est pas un détail de réglage, c’est une contrainte de dessin.

Une lèvre épaisse en 95A ne se conformera pas aux micro-défauts de la surface : elle portera sur trois points hauts et fuira entre les deux. Il faut donc une lèvre fine, 0,6 à 0,8 mm, qui puisse fléchir — au risque de la fragiliser. Et il y a pire : une pièce imprimée en dépôt de fil est un empilement de cordons soudés, et entre deux cordons il reste des micro-canaux. Sur une pièce d’aspect, personne ne les remarque. Sur une pièce dont la fonction est de tenir une dépression, ce sont des fuites. D’où des couches fines, une température haute et un léger excès de matière — non pas pour la solidité, mais pour souder les couches entre elles.

C’est le genre d’arbitrage qu’un dialogue avec une IA fait bien remonter, à condition de lui donner le matériau avant la géométrie. Si j’avais demandé « dessine-moi une ventouse » sans préciser, j’aurais eu une lèvre de 2 mm, correcte en caoutchouc moulé, inutilisable ici.

Le TPU sur une imprimante à extrudeur déporté : le pire cas

Reste à l’imprimer, et c’est là que ma machine se rappelle à moi. Sur une FLSun QQ-S, le moteur qui pousse le filament n’est pas sur la tête : il est sur le châssis, et le fil parcourt environ 700 mm dans un tube guide avant d’atteindre la buse. On appelle ça un montage bowden. Avec un filament rigide, ça marche : le fil se comporte comme une tige qu’on pousse. Avec un filament souple, il se comporte comme un ressort — on pousse d’un côté, rien ne sort de l’autre, puis tout sort d’un coup.

Trois choses en découlent, et elles se voient dans le profil de tranchage :

• La rétraction. Mon profil PLA rétracte de 5 mm. Sur du TPU, 5 mm détendent le fil au point qu’il peut s’enrouler à l’entrée du tube et bloquer — c’est le mode de panne du souple en bowden. Descendu à 2 mm, à vitesse réduite.
• La vitesse. L’étiquette annonce 20 à 40 mm/s, en supposant un extrudeur direct. En bowden, 15 à 25.
• L’accélération. Sur une delta rapide, les à-coups sont absorbés par l’élasticité du fil plutôt que par la buse : la matière manque dans les angles. Ramenée de 1500 à 800 mm/s², restaurée en fin d’impression.

Ce que j’en retiens

Une IA qui dessine n’a aucune boucle de retour. Elle ne voit pas la pièce, ne mesure rien, et son erreur ne devient visible qu’à l’impression. Tout le travail consiste à lui fabriquer cette boucle de retour à la main — et le rendu, c’est ça.

Montrer bat demander. Une question ouverte me demande de reconstruire un contexte ; un dessin faux met la géométrie sous mes yeux et mon œil corrige tout seul. Six questions n’ont pas convergé ; deux rendus ont suffi.

L’IA doit signaler ce qu’elle invente. Le code couleur rouge/cyan — vos cotes, mes hypothèses — est ce qui transforme un joli rendu en instrument de mesure. Sans lui, j’aurais validé cinq valeurs sorties de nulle part.

Une cohérence arithmétique n’est pas une vérification. Mes cotes se refermaient parfaitement sur une pièce fausse. Une IA présente ce genre d’indice avec l’assurance d’une preuve, parce qu’il en a la forme. Le seul juge est l’objet posé sur la table.

Quand un mot bloque, désignez la chose. Pas de reformulation : une image où l’on colorie le volume dont on parle.

Le matériau se donne avant la géométrie. « Une ventouse » et « une ventouse en TPU 95A imprimée en dépôt de fil » ne sont pas la même pièce, et la deuxième ne s’obtient pas en ajustant les réglages de la première.

Et le paramétrage rend tout ça supportable. Cinq versions successives, dix secondes chacune. Si chaque correction avait coûté une reprise dans un logiciel de CAO, j’aurais abandonné au deuxième rendu et dessiné la pièce moi-même — ce qui, d’ailleurs, aurait été parfaitement raisonnable.

Où on en est

Pour reproduire

Ce qu’il faut : la pièce d’origine, un pied à coulisse, de quoi faire un croquis, et un environnement Python avec manifold3d, numpy et matplotlib. Pas de logiciel de CAO.

Le croquis. Trois vues valent mieux qu’une perspective. Mais surtout : écrivez à côté de chaque cote ce qu’elle mesure, en toutes lettres. « 6,5 = hauteur du fût » et non « 6,5 ». C’est laid sur un plan normalisé, c’est ce qui vous fera gagner cinq allers-retours ici.

La boucle. À chaque itération, exigez trois sorties : le STL, une vue 3D (est-ce que ça ressemble à l’objet ?) et une coupe cotée (est-ce que les cotes sont aux bons endroits ?). La coupe est celle qui trouve les erreurs ; la 3D est celle qui trouve les absurdités.

Le code couleur. Demandez explicitement que les cotes reprises de votre croquis et celles inventées par l’IA soient distinguées à l’écran. C’est le point le plus rentable de toute la méthode.

Les règles de dessin qui ont émergé, pour un schéma technique lisible : chaque forme s’arrête à sa géométrie réelle, jamais de trait qui déborde « pour qu’on le voie » ; le texte hors de la pièce, jamais par-dessus ; cadrer sur la zone discutée — un creux de 1 mm est invisible à l’échelle d’une pièce de 20 ; et colorier les volumes plutôt qu’épaissir les traits.

Les fichiers : le modèle ventouse.py et le STL qu’il produit ; le profil de tranchage qqs-tpu.ini (PrusaSlicer en ligne de commande, delta 260 mm, buse 0,4) ; et esp32-supermini-tray.py, une pièce antérieure faite avec la même chaîne, pour comparer une géométrie prismatique à une géométrie de révolution.

Le profil TPU en résumé, si vous imprimez du souple en bowden : rétraction 2 mm à 25 mm/s, périmètres 15–20 mm/s, accélération 800, buse 225–230, plateau 45–50, ventilation 40–60 %, première couche moins écrasée que d’habitude (le souple refoule au lieu de s’étaler), et un bâton de colle sur le verre comme démoulant — le TPU adhère assez pour arracher un éclat.

Questions fréquentes

Peut-on vraiment faire de la CAO en dialoguant avec une IA, sans logiciel ?

Pour une pièce simple et bien définie, oui, et le résultat est paramétrique, versionnable et commenté — trois choses qu’un fichier de CAO donne mal. Pour une pièce dont vous ne savez pas encore la forme, non : le dialogue coûte plus cher que l’esquisse. La bascule se situe à peu près là où vous savez décrire la pièce en une phrase.

Pourquoi mon croquis coté n’a-t-il pas suffi ?

Parce qu’un croquis à main levée porte les cotes mais pas leurs attaches. Sur un plan normalisé, la position des lignes d’attache dit à quoi la cote se rapporte ; à main levée, sur une photo prise de biais, cette information disparaît. Écrire en toutes lettres ce que mesure chaque cote la restitue.

Une IA peut-elle inventer des cotes sans le dire ?

Elle le fait nécessairement — une pièce a plus de dimensions qu’un croquis n’en porte. La question est de savoir si elle le signale. Exigez que les valeurs inventées soient marquées dans le rendu et commentées dans le code ; c’est vérifiable en un coup d’œil, et ça change tout.

Le TPU 95A convient-il pour une ventouse ?

Il est nettement plus dur que le silicone d’une vraie ventouse (40–60 Shore A). Ça peut fonctionner sur une surface bien lisse avec une lèvre fine et des couches fines, mais il ne faut pas s’attendre à la tenue d’une pièce moulée. Un TPU plus souple, en 85A, serait meilleur pour l’usage — et bien plus difficile à imprimer en bowden.

Faut-il un extrudeur direct pour imprimer du TPU ?

Non pour du 95A, oui en pratique pour du 85A et plus souple. En bowden, ce qui compte le plus n’est pas la longueur du tube mais l’extrudeur : un double entraînement tient le filament des deux côtés, là où un galet unique le laisse s’échapper. Un tube d’alésage 1,9 mm complète bien.

Pourquoi ne pas monter l’extrudeur sur la tête d’une delta ?

Parce que la masse mobile y est le paramètre critique et qu’elle pénalise les trois axes à la fois. Doubler la masse de l’effecteur fait chuter la fréquence de résonance d’un facteur √2 ; en dessous de 25 Hz, la compensation logicielle commence à arrondir les détails. Voir l’encart de la section sur le bowden.

Combien de temps a pris l’ensemble ?

Une petite heure de conversation, cinq versions du modèle. L’essentiel de ce temps est passé à lever six ambiguïtés de croquis — pas à dessiner.

Petit glossaire

Bowden (montage) — Le moteur qui pousse le filament est fixé au châssis, et le fil rejoint la buse par un tube guide. Allège la tête mobile, mais introduit de l’élasticité dans la poussée.

Direct drive — L’inverse : le moteur est sur la tête. Meilleur contrôle de la matière, tête plus lourde.

Effecteur — Sur une imprimante delta, la pièce mobile qui porte la buse, suspendue aux trois paires de bras.

manifold3d — Bibliothèque de géométrie solide qui garantit des maillages toujours valides ; on décrit la pièce en Python par des opérations booléennes et des révolutions.

Pressure advance — Compensation logicielle du retard entre la commande d’extrusion et la sortie de matière, dû à la compressibilité du filament. D’autant plus élevé que le montage est souple.

Rétraction — Recul du filament pendant les déplacements sans extrusion, pour éviter les fils. Longue en bowden, très courte en direct.

Shore A — Échelle de dureté des élastomères. Un silicone de ventouse est à 40–60, un joint de porte à 70, un TPU d’impression courant à 95, une roulette de chariot à 98.

STL — Format de fichier décrivant une surface par un maillage de triangles. Ce que le trancheur attend.

Trancheur (slicer) — Le logiciel qui transforme un STL en trajectoires de buse. Ici PrusaSlicer, piloté en ligne de commande par un fichier de profil.

TPU — Polyuréthane thermoplastique : le filament souple le plus courant.

Références et copies locales

• Le modèle et ses sorties : ventouse.py, ventouse.stl
• Le profil de tranchage TPU : qqs-tpu.ini
• Une pièce prismatique faite avec la même chaîne : esp32-supermini-tray.py
• manifold3d — la bibliothèque de géométrie solide utilisée
• Documentation Klipper — mesure de résonance — sur le seuil des 25 Hz et le compromis masse/rigidité
• Le billet précédent — la calibration de la même machine, où la méthode de la photo annotée est née

Le dos de l’appareil. « Model G020F » — la variante européenne. À côté, le marquage CE et la poubelle barrée, ce pictogramme qui signifie « ne pas jeter avec les ordures ménagères ». Il aura fallu attendre sept ans pour que ce symbole cesse d’être une formalité et devienne le sujet.

Ce que veut dire « fin de support »

Le Pixel 3a est sorti en mai 2019. C’était le bon élève de sa génération : un appareil photo remarquable pour 400 €, une prise casque que les modèles haut de gamme avaient déjà supprimée, un processeur Snapdragon 670 sans prétention. Google l’a mis à jour jusqu’au 5 mai 2022. La dernière version installée sur celui-ci porte le numéro SP2A.220505.008 — Android 12, correctif de sécurité de mai 2022.

Depuis, plus rien. Pas parce que le matériel a lâché : il fonctionne parfaitement. Parce qu’une entreprise a décidé qu’une durée était écoulée.

C’est une phrase qu’on lit sans y penser, « l’appareil n’est plus supporté ». Traduisons-la. Le processeur, l’écran, les caméras, le modem, la batterie — tout cela marche encore. Ce qui s’arrête, c’est un service : quelqu’un, quelque part, cesse de compiler du logiciel pour cette combinaison de puces. Le téléphone ne devient pas défectueux, il devient orphelin. Et comme le logiciel qu’il exécute n’est pas modifiable par son propriétaire, orphelin veut dire condamné.

Sauf que celui-ci était un Pixel. Et les Pixel ont une propriété rare : Google, contrairement à presque tous ses concurrents, autorise le propriétaire à déverrouiller le chargeur d’amorçage — le petit programme qui décide quel système d’exploitation a le droit de démarrer. Cette autorisation, sur laquelle je vais revenir, est ce qui sépare un appareil récupérable d’une brique.

Trois façons de mettre Linux sur un téléphone, et une seule qui compte ici

Un téléphone Android exécute déjà un noyau Linux. Mais un noyau Android, c’est une version ancienne du noyau officiel, à laquelle le fabricant de la puce a ajouté des milliers de modifications qu’il ne publie jamais en amont. Ce code ne vit que le temps du produit. C’est là toute la différence entre les trois options qui s’offraient :

Ubuntu Touch est objectivement le meilleur choix pour utiliser ce téléphone : les appels, les SMS, la 4G, le Bluetooth, le NFC, les deux caméras, le lecteur d’empreinte — tout marche. Mais il y parvient en réutilisant les pilotes binaires d’Android 9. C’est-à-dire en embaumant 2019. Rien de ce qu’on y corrige ne profite à personne d’autre, et le jour où cette base pourrira, il n’y aura rien à faire.

postmarketOS prend le chemin inverse : faire tourner le noyau Linux officiel, celui que tout le monde utilise, sur cette puce. C’est plus dur, il manque des choses, et c’est précisément l’intérêt — ce qui est écrit là remonte dans le noyau que le monde entier utilisera dans dix ans. Un groupe de développeurs s’y consacre spécifiquement pour ce processeur, sous le nom sdm670-mainline.

Le choix était donc simple, à condition d’assumer ce qu’il implique : ce téléphone ne sera pas mon téléphone. C’est un banc d’essai.

Le déverrouillage, et le piège du téléphone réinitialisé

L’appareil arrivait réinitialisé, ce qui semblait simplificateur. Ça ne l’était pas.

Pour déverrouiller le chargeur d’amorçage, il faut activer une option nommée Déverrouillage OEM dans les réglages Android. Or cette option reste grisée tant que le téléphone n’a pas joint le réseau au moins une fois : Google vérifie que l’appareil n’est pas signalé volé. Il faut donc rallumer le téléphone, traverser l’assistant de mise en route, connecter le Wi-Fi — puis seulement activer l’option. Sur un appareil qu’on s’apprête entièrement à effacer, c’est un détour absurde mais obligatoire.

Second piège, plus vicieux : la combinaison de touches pour entrer en mode fastboot — le mode de maintenance du bootloader — est Volume Bas + Power, mais uniquement depuis un téléphone complètement éteint. Sur un appareil allumé, cette même combinaison prend une capture d’écran. On appuie, il ne se passe rien d’attendu, on recommence, on doute de son matériel. Il faut éteindre, attendre deux secondes, maintenir Volume Bas d’abord, puis appuyer sur Power.

Le reste tient en une commande, et un avertissement rouge sur l’écran qu’il faut confirmer avec les touches physiques :

fastboot flashing unlock

L’écran de fastboot après l’opération. « Device state: unlocked » en rouge : le téléphone accepte désormais de démarrer un système qui n’est pas signé par Google. Notez « sargo MP1.0 (ROW) » — sargo est le nom de code du Pixel 3a, ROW confirme la variante internationale.

Le téléphone efface tout et redémarre. À partir de là, il n’appartient plus vraiment à Google.

Préparer le système : une demi-heure de questions

Côté ordinateur, postmarketOS se construit avec un outil nommé pmbootstrap, disponible dans les dépôts de la plupart des distributions. Il ne télécharge pas une image toute faite : il assemble le système pour votre appareil précis, dans un environnement isolé, en vous posant une vingtaine de questions.

La plupart appellent une réponse par défaut. Trois méritent réflexion, et j’ai tranché les trois selon le même principe : coller à ce que les mainteneurs testent.

C’est un principe qui mérite d’être explicité, parce qu’il est contre-intuitif. Quand on installe un système pour soi, on choisit ce qu’on préfère. Quand on l’installe pour contribuer, chaque écart au choix majoritaire est une variable supplémentaire qui rendra vos rapports de bogue inexploitables. Si je remonte un problème audio sur une pile que personne d’autre n’utilise, le mainteneur ne peut ni le reproduire, ni le comparer. Mon rapport devient du bruit.

J’ai donc pris pulseaudio plutôt que le plus moderne pipewire, wpa_supplicant plutôt qu’iwd, l’interface Phosh plutôt que la très tentante sxmo, et — à contrecœur — systemd. Sur ce dernier point, postmarketOS est un des rares endroits où OpenRC reste un citoyen de première classe ; mon réflexe n’avait rien de marginal. Mais quatre des quinze bogues ouverts pour cet appareil sont rapportés sous Phosh avec systemd, et journalctl reste l’outil le plus commode pour extraire une trace propre.

Deux réponses valent un avertissement.

Ne pas activer le chiffrement du disque. L’option est là, elle est tentante, et sur ce téléphone elle rend l’appareil non démarrable : un bogue ouvert décrit un système qui ne détecte pas la saisie du mot de passe au démarrage. On se retrouve avec une machine qui demande une phrase secrète impossible à taper.

Garder la locale en anglais. Contre-intuitif pour un billet en français, mais les messages d’erreur et les journaux sortiront en anglais, donc directement collables dans un rapport et comparables à ceux des autres. Ça n’empêche nullement d’avoir un clavier AZERTY.

Channel          edge          # là où les bogues sont rapportés et les correctifs atterrissent
Vendor           google
Device           sargo
UI               phosh
Audio backend    pulseaudio    # défaut
WiFi backend     wpa_supplicant # défaut
usb-moded        developer     # réseau USB TOUJOURS actif — le cordon de sécurité
Service manager  default       # systemd pour Phosh
Locale           en_US

libcamera-tools,v4l-utils,evtest,tmux,vim,strace,usbutils

curl -s -o idx.tar.gz \
  "https://dl-cdn.alpinelinux.org/alpine/edge/community/aarch64/APKINDEX.tar.gz"
tar xzf idx.tar.gz -O APKINDEX | grep '^P:' | sed 's/^P://' > paquets.txt
grep -qx "libcamera-tools" paquets.txt && echo présent

Une trentaine de minutes plus tard, le système était construit. Restait à l’écrire dans le téléphone. C’est là que la soirée a dérapé.

Une heure à accuser le mauvais coupable

Le téléphone était en mode fastboot, branché, reconnu. La commande d’écriture partait — et se figeait. Indéfiniment. Sans le moindre message d’erreur, ni sur la sortie standard, ni sur la sortie d’erreur. Un processus endormi, à l’infini.

Ce qui rendait la chose déroutante, c’est que l’appareil semblait parfaitement présent :

$ fastboot devices
058AY1WZGT     fastboot

Il répondait. Il était là. Et pourtant toute écriture se bloquait.

J’ai formulé quatre hypothèses. Les quatre étaient fausses, et les écarter m’a pris une heure. Elles valent d’être listées, parce que ce sont exactement celles que n’importe qui formulerait.

Un problème de permissions. L’hypothèse classique : le nœud USB appartient à root, l’utilisateur n’a pas le droit d’écrire dessus. Vérification faite, le fichier portait une liste de contrôle d’accès accordant explicitement l’accès à mon compte. Écarté par la mesure, pas par la supposition.

Un câble ou un port défectueux. C’est le réflexe suivant, et le plus répandu sur les forums. Sauf que les journaux du noyau étaient d’une propreté irréprochable : énumération en haute vitesse, aucune erreur, aucune réinitialisation, aucune déconnexion intempestive. Un câble abîmé laisse des traces ; il n’y en avait aucune.

Un problème de contrôleur USB. Piste sérieuse : les Pixel n’ont qu’de l’USB 2.0, et les contrôleurs modernes sont réputés capricieux avec certains chargeurs d’amorçage. Le conseil habituel est « branchez sur un port USB 2.0 ». Deux mesures l’ont écarté : le téléphone négociait déjà en 480 mégabits, donc bien en USB 2.0, et la carte mère de la machine (une Raptor Lake d’Intel) n’a plus de contrôleur d’ancienne génération — tout passe par le même bloc. « Changer pour un port USB 2.0 » n’avait pas de sens.

Une régression dans le logiciel. pmbootstrap exécute sa propre copie de fastboot, en version 37, tandis que mon système en avait une version 35. J’ai donc contourné l’outil pour flasher directement avec la version du système. Elle s’est figée exactement pareil. Hypothèse morte.

Quatre pistes, quatre impasses. Et un détail qui aurait dû m’alerter bien plus tôt : à chaque nouvelle entrée en mode fastboot, la première commande passait — en treize millisecondes — et toutes les suivantes se figeaient.

J’avais ce fait sous les yeux depuis le début. J’ai mis une heure à l’écouter, parce que je continuais à interroger l’appareil au lieu d’interroger le système.

La réponse tenait dans un fichier

Le mode fastboot est un dialogue : l’ordinateur pose des questions, le bootloader répond. J’ai fini par regarder non pas ce que répondait le téléphone, mais ce que le noyau Linux pensait de lui. Ces informations vivent dans /sys, un système de fichiers virtuel où le noyau expose son état interne sous forme de fichiers lisibles.

$ cat /sys/bus/usb/devices/1-9/power/control
auto
$ cat /sys/bus/usb/devices/1-9/power/autosuspend_delay_ms
2000
$ cat /sys/bus/usb/devices/1-9/power/runtime_status
suspended

Endormi.

Pour économiser l’énergie, le noyau met les périphériques USB en veille après un délai d’inactivité — ici, deux secondes. C’est un comportement normal et souhaitable pour la plupart des appareils, qui savent se réveiller quand on leur reparle. Le chargeur d’amorçage du Pixel ne sait pas. Une fois endormi, il ne répond plus jamais.

Tout s’explique d’un coup :

La correction est une règle de trois lignes, qui demande au noyau de ne jamais endormir les appareils Google :

# /etc/udev/rules.d/52-fastboot-no-autosuspend.rules
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", \
    TEST=="power/control", ATTR{power/control}="on"

Sauf que ça n’a rien changé. Et la raison de cet échec est la partie la plus intéressante de l’histoire.

Le second coupable, tapi derrière le premier

Ma règle était pourtant correcte — l’outil de diagnostic d’udev confirmait qu’elle était bien évaluée et bien appliquée. Mais après le branchement, le réglage retombait à auto.

Quelqu’un repassait derrière moi. Ce quelqu’un s’appelait TLP, un gestionnaire d’énergie très répandu sur les ordinateurs portables Linux, qui applique ses propres réglages d’autosuspend USB après udev, et écrase donc silencieusement les vôtres. Beaucoup de gens l’installent une fois pour gagner de l’autonomie, puis l’oublient complètement.

TLP a précisément une option prévue pour ce cas :

# /etc/tlp.conf
USB_EXCLUDE_PHONE=1
USB_DENYLIST="18d1:4ee0 18d1:4ee1 18d1:4ee2 18d1:4ee3 18d1:4ee7"

Cette fois le réglage a tenu. Un détail à connaître : poser la correction ne débloque pas un appareil déjà endormi. L’état USB du bootloader ne se répare qu’à la ré-énumération. Il faut donc corriger, puis ressortir et rentrer en mode fastboot.

Et pour maximiser les chances, j’ai groupé les trois écritures en une seule invocation, plutôt que trois processus successifs :

fastboot flash vbmeta   vbmeta.img \
         flash boot     boot.img \
         flash userdata google-sargo.img

Sending 'vbmeta_b' (4 KB)                   OKAY [  0.120s]
Writing 'vbmeta_b'                          OKAY [  0.071s]
Sending 'boot_b' (28008 KB)                 OKAY [  0.747s]
Writing 'boot_b'                            OKAY [  0.194s]
Sending sparse 'userdata' 1/9 (258751 KB)   OKAY [  6.306s]
...
Finished. Total time: 94.883s

Quatre-vingt-quinze secondes. Après une heure de blocage.

lsusb | grep 18d1

cat /sys/bus/usb/devices/<port>/power/runtime_status

sudo readlink /proc/<pid>/root        # tourne-t-il dans un chroot ?
sudo ls -l /proc/<pid>/fd | grep usb  # a-t-il ouvert le périphérique ?

Ce qui a démarré

Vingt secondes après le redémarrage, la machine a vu apparaître une interface réseau. Le téléphone distribuait lui-même les adresses.

$ ssh sam@172.16.42.1
$ uname -r
7.1.3-sdm670
$ df -h /
/dev/loop0p2   47.9G   2.2G   43.2G   5% /

Noyau 7.1.3. Sur un téléphone dont le fabricant a cessé de s’occuper en mai 2022, avec un noyau Android figé en 4.9. Le système de fichiers s’était agrandi tout seul au premier démarrage pour occuper les 48 gigaoctets disponibles.

Premier démarrage. L’écran est fissuré depuis longtemps ; l’appareil, lui, vient de rajeunir de quatre ans.

Le panneau de réglages rapides. Wi-Fi, Bluetooth, batterie à 94 %. Et dans les notifications, le sélecteur « USB Developer mode » — exactement le profil choisi à l’installation, celui qui garde le réseau USB actif en permanence. L’horloge affiche « jeudi 1er janvier, 4 h 12 » : l’horloge matérielle n’a pas encore été mise à l’heure, personne ne lui a encore dit quel jour on était.

La caméra, ou comment un outil bien écrit vous tend le travail

Restait à vérifier ce que je venais chercher. Sur postmarketOS, la gestion des caméras passe par libcamera, une bibliothèque libre qui remplace la pile propriétaire d’Android. Un bogue connu signale que le pilote du capteur avant de ce téléphone est incomplet, et que la commande cam -l — qui liste les caméras — s’en plaint.

Elle s’en est plainte, en effet. Mais bien mieux que je ne l’espérais :

ERROR V4L2 'imx355 4-001a': Unable to get rectangle 2 on pad 0/0
ERROR V4L2 'imx355 4-001a': Unable to get rectangle 1 on pad 0/0
ERROR V4L2 'imx355 4-001a': Unable to get rectangle 0 on pad 0/0
 WARN  'imx355 4-001a': Failed to retrieve the sensor crop rectangle
 WARN  'imx355 4-001a': The sensor kernel driver needs to be fixed
 WARN  See Documentation/sensor_driver_requirements.rst

Il y a quelque chose de réjouissant dans un logiciel qui vous dit littéralement « le pilote noyau du capteur a besoin d’être corrigé » et vous donne la référence du document qui explique comment. C’est l’opposé exact d’une erreur 4202 sur un aspirateur.

Concrètement : le pilote ne sait pas répondre quand on lui demande les dimensions réelles de sa matrice de pixels. libcamera invente alors des valeurs par défaut, et travaille sur une géométrie approximative.

Mais la sortie révélait aussi ceci, que je n’attendais pas :

WARN 'imx363': No static properties available — Please consider updating the database
WARN 'imx355': No static properties available
WARN IPASoft: Failed to create camera sensor helper for imx355 / imx363

Ce second problème n’est pas dans le noyau. Ce sont deux tables de données, dans libcamera elle-même, où les capteurs du Pixel 3a manquent à l’appel — alors que des dizaines d’autres y figurent déjà et fournissent un modèle à recopier. Des données pures, aucune algorithmique.

Mise à jour, quelques heures plus tard. En allant écrire ce correctif, j’ai découvert que la moitié venait d’être faite : le capteur avant, l’imx355, a été ajouté en amont après la version 0.7.2 qu’exécute ce téléphone. L’avertissement ci-dessus est donc un artefact de version, pas un manque — une mise à jour suffira. Le capteur arrière, l’imx363, reste absent de tout le dépôt, et son pilote n’est même pas dans le noyau officiel : il a été écrit chez Intel, jamais remonté en amont, et postmarketOS le charge en module.

Et en comparant l’entrée neuve de l’imx355 avec ce que le pilote expose réellement sur l’appareil, un détail cloche : elle associe « barres de couleur » à la valeur 1 et « couleur unie » à la valeur 2, quand le pilote fait exactement l’inverse. Deux autres capteurs au menu identique, l’imx258 et l’imx471, sont correctement décrits juste à côté. Ça fait donc deux correctifs au lieu d’un — et le plus simple est celui que personne n’attendait.

Autrement dit : le premier correctif à écrire n’est pas celui que je visais en arrivant. Il a fallu allumer le vrai matériel pour s’en apercevoir. C’est une leçon assez générale — on peut lire des rapports de bogue pendant des jours sans voir ce qu’une machine allumée vous dit en trois secondes.

Pourquoi ce n’est pas seulement un passe-temps

Le matin même où ce téléphone a démarré, le compte balade.nomade publiait un reel (copie locale de la légende et du fil de commentaires) qui résume ce qui se joue en ce moment à Bruxelles. Il se termine par une question que je trouve bien posée :

Es-tu prêt à scanner ta carte d’identité pour utiliser Instagram ?

Le ton est militant, alors j’ai vérifié les trois points. Deux tiennent solidement, le troisième mérite une nuance — et le fil de commentaires en a ajouté un quatrième, plus pertinent que les trois autres pour ce billet.

Chat Control. Exact. Le règlement européen dit CSAR reste bloqué en trilogue, et les négociations reprennent fin septembre 2026 sous présidence irlandaise du Conseil. Le 9 juillet 2026, le Parlement européen a voté à 314 voix contre 276 le retrait du dispositif — sans atteindre le seuil de 360 voix nécessaire pour bloquer la position du Conseil. La dérogation autorisant le scan « volontaire » des messages a donc été prolongée jusqu’en 2028. L’analyse côté client a été retirée de la dernière version du texte, mais le service juridique du Conseil lui-même, dans un avis du 10 juin 2026, estime que ce scan volontaire demeure une recherche généralisée dans les communications, incompatible avec l’article 7 de la Charte des droits fondamentaux.

La fin de l’anonymat. Exact, avec une actualité que le reel ne mentionne pas : la loi française du 21 juillet 2026 interdisant les réseaux sociaux aux moins de quinze ans a été censurée le 14 août par le Conseil constitutionnel (décision n° 2026-911 DC), pour atteinte disproportionnée à la liberté d’expression et à la vie privée. Elle n’entrera donc pas en vigueur en l’état. Mais le mouvement de fond continue ailleurs : la Commission européenne a annoncé le 15 avril 2026 que sa solution de vérification d’âge était prête au déploiement, et le portefeuille d’identité numérique européen doit arriver dans les États membres d’ici la fin de l’année.

Les métadonnées. Là je nuance. L’EDPB a bien adopté le 7 juillet 2026 de nouvelles lignes directrices sur l’anonymisation, en consultation jusqu’au 30 octobre, qui remplacent l’avis de référence de 2014. Mais c’est un travail de clarification technique, pas un coup de poing sur la table. Et la jurisprudence récente va plutôt dans l’autre sens : la Cour de justice de l’Union européenne, en septembre 2025, a retenu une approche relative — une même donnée pseudonymisée peut être anonyme pour qui n’a aucun moyen de réidentifier, et personnelle pour un autre.

Le quatrième point, celui qui parle vraiment de ce billet

Dans les commentaires, quelqu’un signale que Google change sa politique d’installation d’applications et s’inquiète que cela « mette en péril GrapheneOS ». La réponse de l’auteur corrige à juste titre la crainte, et les faits lui donnent raison.

Depuis août 2025, Google impose que toute application installée sur un appareil Android certifié provienne d’un développeur vérifié — y compris quand on installe un fichier APK à la main, en dehors de toute boutique. Les premières restrictions visibles arrivent le 30 septembre 2026 au Brésil, en Indonésie, à Singapour et en Thaïlande, avant une extension mondiale en 2027. Installer l’application d’un développeur non vérifié passera par un parcours détourné avec un délai d’attente obligatoire de vingt-quatre heures. Et pour être vérifié, un développeur doit ouvrir un compte, payer vingt-cinq dollars et fournir une pièce d’identité officielle.

Relisez la question du reel, et remplacez l’utilisateur par le développeur. C’est le même geste : une pièce d’identité comme condition d’accès. D’un côté pour lire, de l’autre pour écrire.

Le commentateur se trompait pourtant sur un point, et c’est celui qui compte. La contrainte porte sur les appareils certifiés — ceux qui embarquent les services Google sous licence. GrapheneOS ne les embarque pas : il est hors du périmètre. La restriction ne met donc pas en péril les systèmes dégooglisés, elle rend leur existence plus nécessaire.

Installer son propre logiciel, ce combat

C’est ce qui m’exaspère le plus, et c’est antérieur à toute cette actualité. Sur Android comme sur iOS, installer un logiciel qu’on a compilé soi-même, ou récupéré sur un dépôt Git, est un parcours d’obstacles.

Sur Android, il faut autoriser une source inconnue, passer trois avertissements, et bientôt fouiller les options développeur puis patienter vingt-quatre heures. Sur iOS c’est pire : une application que vous compilez et signez avec un compte Apple gratuit cesse de fonctionner au bout de sept jours et doit être réinstallée depuis un ordinateur. Pour qu’elle survive, il faut payer quatre-vingt-dix-neuf euros par an. Le règlement européen sur les marchés numériques a entrouvert la porte en 2024 — boutiques alternatives, distribution depuis son propre site — mais uniquement dans l’Union, et sous conditions d’Apple.

La justification est toujours la même : la sécurité. Elle mérite d’être prise au sérieux, donc examinée.

Si l’ouverture causait l’insécurité, ça se verrait. Linux laisse installer n’importe quoi depuis n’importe où — un dépôt, une archive, du code compilé à la main — et ce n’est pas un désastre sécuritaire : c’est le système qui fait tourner l’essentiel des serveurs de la planète, sous attaque permanente. Windows, à l’inverse, a longtemps eu le modèle le plus permissif et la pire réputation. Si la théorie était bonne, Android et iOS seraient les systèmes les plus sûrs jamais conçus. On observe à peu près l’inverse de ce qu’elle prédit.

Ce qui protège n’est donc pas la fermeture, c’est une chaîne de confiance vérifiable : des dépôts signés, des mainteneurs identifiés, du code source que n’importe qui peut relire, des constructions reproductibles. La sécurité vient de la transparence, pas de la permission. Et cette chaîne existe déjà sur Android : F-Droid distribue depuis des années des applications libres compilées à partir de sources publiques, sans péage ni pièce d’identité.

Pendant ce temps, la boutique officielle laisse passer. En 2026, une famille de logiciels malveillants baptisée NoVoice a été trouvée dans plus de cinquante applications du Play Store, cumulant au moins 2,3 millions de téléchargements — avec accès root et survie à une réinitialisation d’usine. L’année précédente, la campagne SlopAds : 224 applications, 38 millions de téléchargements. Et Google a banni 80 000 comptes développeurs en 2025, sous un régime qui exige déjà une vérification d’identité pour publier sur le Play Store.

C’est ce chiffre qui règle la discussion. La vérification des développeurs existe déjà là où elle est censée protéger, et il faut quand même bannir quatre-vingt mille comptes par an. L’étendre à l’installation manuelle n’arrêtera pas les campagnes industrielles — elles passent par la grande porte, et c’est documenté. Ça arrêtera le développeur isolé qui publie son code sur un dépôt Git.

Le risque, lui, est réel : quelqu’un qui installe un fichier reçu par SMS se fait effectivement piéger. Mais ça plaide pour un avertissement clair, pas pour un droit d’entrée. On protège quelqu’un en lui disant ce qu’il est en train de faire ; on ne le protège pas en faisant payer celui qui écrit.

Et il y a un critère qui tranche la question. Pour opérer une boutique alternative dans l’Union européenne, Apple exige, à compter du 1er octobre 2026, d’être coté en bourse, ou financé par du capital-risque, ou d’avoir passé un audit financier, ou de totaliser un million d’installations annuelles. Aucun de ces critères ne mesure la sécurité de quoi que ce soit. Ce sont des critères de taille.

Je veux bien croire à la bonne foi sur le principe. J’ai plus de mal quand la même entreprise verrouille la porte et tient la caisse.

Ce que ça change pour un vieux téléphone

Le point commun de tout ça est technique, et c’est lui qui relie cette actualité à un Pixel de 2019.

L’analyse côté client, c’est inspecter les messages sur l’appareil, avant chiffrement. Un tel dispositif ne s’implémente pas dans une application : il s’implémente dans le système. C’est le déplacement décisif. Tant que la garantie reposait sur le protocole, on pouvait l’auditer de l’extérieur. Dès qu’elle repose sur l’appareil, la seule question qui compte devient : qui décide de ce que fait cet appareil ?

Sur un téléphone dont le système ne peut pas être remplacé, la réponse est : le fabricant. Et à travers lui, quiconque légifère sur le fabricant. Ce n’est pas un scandale, c’est une chaîne de décision parfaitement ordinaire — mais elle ne passe à aucun moment par le propriétaire.

Les deux échappatoires existantes — GrapheneOS, postmarketOS — reposent sur exactement la même chose : un bootloader qu’on a le droit de déverrouiller. La même case à cocher dans les options développeur qui a ouvert cette soirée. Toute la voie de sortie pratique, pour Android, a tenu jusqu’ici à la bonne volonté d’un seul fabricant sur un seul réglage. GrapheneOS n’est disponible que sur Pixel ; il faudra attendre les Motorola haut de gamme de 2027 pour que ce ne soit plus vrai.

Et il faut dire ce que ce billet ne démontre pas. postmarketOS sur un Pixel 3a n’est pas une solution de vie privée. Le modem reste une boîte noire, un processeur autonome exécutant du logiciel propriétaire auquel le système n’a pas accès. Cet appareil-ci n’est pas utilisable au quotidien, je l’ai dit dès le départ. Pour un usage réel, la réponse sérieuse est celle que le reel met en mot-clé : GrapheneOS.

Ce que démontre ce billet est plus modeste, et suffit : la capacité existe, elle est à la portée d’une soirée, et elle s’exerce. Une capacité qu’on n’exerce jamais finit par disparaître sans que personne ne s’en aperçoive — pas par interdiction, simplement parce qu’un jour plus aucun appareil ne la propose et que personne ne l’aura réclamée.

Et votre téléphone à vous ?

C’est la première question qu’on m’a posée, et elle est la bonne. Voici de quoi y répondre — les chiffres viennent du dépôt pmaports au 5 septembre 2026 et du site officiel d’Ubuntu Touch, pas d’une liste recopiée quelque part.

D’abord un avertissement sur le vocabulaire. postmarketOS classe ses appareils en trois niveaux, et ils veulent dire quelque chose :

• community — ça marche globalement, avec des manques identifiés. 39 appareils, dont seulement quatorze téléphones.
• testing — de « ça démarre, en un sens » à « presque tout fonctionne ». 149 appareils. C’est là que se trouve la majorité du parc, et c’est là qu’il y a du travail.
• downstream — noyau Android d’origine, fonctionnalités très limitées. 20 appareils, déconseillés.

Aucun appareil n’est aujourd’hui classé au-dessus de community. Ça situe honnêtement l’état de l’écosystème.

Les quatorze téléphones en community

Deux surprises dans cette liste. Le Xiaomi Poco F1 et les OnePlus 6 / 6T sont d’excellents candidats : puissants pour leur âge, très répandus d’occasion, et portés depuis longtemps. Et le PinePhone d’origine, pourtant conçu pour Linux, est en testing — c’est son successeur Pro qui est en community.

Le reste de la catégorie n’est pas fait de téléphones : une douzaine de Chromebooks ARM, le Lenovo ThinkPad X13s, la PineNote, l’Odroid XU4, le RockPro64. Si vous cherchez un petit ordinateur ARM sous Linux plutôt qu’un téléphone, c’est une piste largement sous-estimée.

Côté testing, les 149 appareils se répartissent surtout entre Samsung (30), Xiaomi (18), Sony, OnePlus, LG et Google (5 chacun), et Fairphone (4). Il y a donc de fortes chances que votre téléphone y figure — avec du travail à faire dessus, ce qui est précisément l’intérêt.

Si vous voulez un téléphone qui marche, pas un banc d’essai

C’est un autre besoin, et il a d’autres réponses. Ubuntu Touch annonce 111 appareils pris en charge, avec un taux de fonctionnalités par appareil. Les mieux servis :

Le Fairphone 4 est le point d’équilibre de tout ça : il est à la fois en community chez postmarketOS et à 97,3 % chez Ubuntu Touch, et c’est par ailleurs le téléphone le plus réparable du marché. Si quelqu’un me demandait quoi acheter pour faire ça sérieusement, ce serait lui — ou le Fairphone 5 si l’objectif est d’abord de s’en servir.

Et si vous voulez rester sur Android tout en sortant de chez Google, GrapheneOS reste la réponse la plus solide — mais uniquement sur Pixel 6 et suivants, avec sept ans de mises à jour garanties sur les Pixel 8, 9 et 10. Le partenariat annoncé en août 2026 avec Motorola devrait lever cette exclusivité en 2027 ; la liste officielle, elle, est encore exclusivement Pixel aujourd’hui.

Comment vérifier pour le vôtre

Cherchez le nom de code de votre appareil — pas son nom commercial — sur le wiki de postmarketOS et sur devices.ubuntu-touch.io. Le nom de code se lit en une commande, l’appareil branché en USB :

adb shell getprop ro.product.device

Sur le mien, ça répond sargo. Et deux conditions préalables valent pour tout le monde, indépendamment de la liste : le bootloader doit être déverrouillable, ce qui exclut la plupart des appareils vendus par les opérateurs américains ; et l’opération efface tout.

Ce que je retiens

La partie technique est presque anecdotique. Trois choses me restent.

Le piège n’est nulle part. L’autosuspend USB n’est mentionné dans aucun guide d’installation. Quelqu’un qui le rencontre voit une commande qui se fige sans message, essaie un autre câble, un autre port, et conclut que son matériel est en cause. Il renonce. Le correctif fait deux lignes et vaut pour tous les Pixel. C’est ce que je vais écrire en premier — avant tout code, avant la caméra. Une soirée perdue par moi peut en épargner beaucoup à d’autres, et c’est probablement la contribution la plus rentable de toute l’histoire.

J’ai cherché au mauvais endroit pendant une heure. Non par manque de méthode, mais parce que je continuais à interroger l’appareil — retenter la commande, changer un paramètre, réessayer — au lieu d’interroger le système qui pilotait l’appareil. La réponse était dans un fichier texte de neuf caractères. Chaque fois qu’un outil se tait au lieu d’échouer, il faut arrêter de le relancer et aller lire l’état de la couche d’en dessous.

Et puis il y a le fond. Ce téléphone porte gravée au dos une poubelle barrée, ce pictogramme qui signifie qu’on ne le jette pas avec les ordures. Le symbole est là depuis 2019, obligatoire, décoratif. Ce soir il est devenu exact : l’appareil n’est pas allé à la benne, il tourne, et il tourne sur un noyau plus récent que celui de bien des machines en service.

Ce n’est pas un exploit technique — des gens autrement compétents ont fait le travail difficile, celui de porter un noyau moderne sur cette puce. Je n’ai fait que suivre leurs traces et me cogner à un piège qu’ils n’avaient pas documenté. Mais c’est une démonstration : la fin de support n’est pas une propriété du matériel. C’est une décision. Et quand le fabricant laisse la porte ouverte — comme Google le fait sur les Pixel, à son honneur —, cette décision peut être reprise par quelqu’un d’autre.

Un Pixel 3a d’occasion se trouve pour quelques dizaines d’euros. Il y en a des millions dans des tiroirs.

La suite, c’est la caméra.

L’établi le troisième jour. Tout ce qui a servi de juge : le pied à coulisse, un vieux micromètre en pouces, le cube de 20 mm, les cadres de première couche, les carrés d’épaisseur numérotés au feutre, et derrière, la pièce à sept piliers de la calibration étendue.

Une machine « toujours un peu décevante »

J’ai une imprimante delta FLSun QQ-S, achetée en janvier 2020. Une delta, c’est cette imprimante en forme de tour triangulaire où la buse est suspendue à trois bras articulés qui montent et descendent le long de trois colonnes ; il n’y a pas d’axe X, Y et Z séparés comme sur une imprimante cartésienne, la position de la buse est le résultat d’un calcul à partir de la hauteur des trois chariots. C’est rapide, silencieux, élégant, et beaucoup plus sensible aux erreurs de géométrie qu’une machine à axes droits : un bras d’un millimètre trop long ou une colonne décalée d’un degré ne donnent pas une erreur simple, mais une déformation en creux, en dôme ou en trèfle qui varie sur tout le plateau.

Peu utilisée, cette machine a toujours été un peu décevante. Pas catastrophique : les pièces sortaient. Mais les parois manquaient de tenue, les cotes étaient fausses de quelques dixièmes, la première couche n’accrochait jamais partout, et surtout aucun réglage n’avait d’effet net. J’avais fini par imprimer avec une buse plus grosse « pour que ça aille plus vite », changé les courroies après en avoir détruit un jeu par sur-tension, et rangé la machine à côté d’une Bambu Lab qui, elle, imprime juste sans qu’on lui demande rien.

C’est cette comparaison qui a lancé l’enquête. Non pas « comment régler mon slicer », mais qu’est-ce que cette machine a, exactement, et qu’est-ce qui est rattrapable. Le billet raconte trois jours, du 4 au 6 septembre 2026, menés avec une IA (Claude) qui pilote l’imprimante, écrit les outils et lit les manuels, pendant que je tiens le pied à coulisse, la feuille de papier et l’appareil photo. Il raconte aussi une belle erreur de méthode, la sienne et la mienne, parce que c’est ce qui arrive quand on cherche pour de vrai.

Le dispositif

Le firmware d’origine allait être remplacé par Klipper. Klipper est un firmware d’imprimante 3D en deux parties : un tout petit programme sur la carte de l’imprimante, qui ne fait que piloter les moteurs et les chauffes en temps réel, et un programme hôte, sur un ordinateur à côté, qui fait tout le reste — la cinématique, les calibrations, les macros. On perd l’écran tactile de l’imprimante (Klipper ne sait pas le piloter), on gagne des outils de calibration qui n’existent nulle part ailleurs, en particulier pour les deltas.

Ce que Klipper apporte, concrètement, par rapport au Repetier d’origine — ou à un Marlin :

• Le calcul déporté. Un firmware classique fait toute la cinématique delta sur le petit microcontrôleur de la carte, avec les approximations que ça impose ; Klipper la fait sur l’ordinateur hôte, en virgule flottante, et n’envoie à la carte que des instants de pas précalculés. Sur une delta, où chaque déplacement est une racine carrée par colonne, ça se voit dans la précision des mouvements et la vitesse possible.
• Les outils de calibration : DELTA_CALIBRATE, qui déduit la géométrie complète de sept points, avec ou sans palpeur ; la calibration étendue des bras ; la grille de plateau ; et TUNING_TOWER, qui fait varier un paramètre avec la hauteur pendant l’impression, pour régler en une pièce ce qui demanderait dix essais.
• Le pressure advance et l’input shaper, la compensation de la pression dans le bowden et celle des vibrations, que le firmware d’origine n’a pas, et qui font l’essentiel de l’écart de qualité avec une machine moderne.
• Une configuration en fichier texte, lisible, commentable, versionnable, où chaque valeur a sa provenance ; et une prise locale par laquelle on pilote tout depuis un script.

Ce qu’il n’apporte pas : il ne relève pas le plafond de débit du hotend, il ne remplace pas une mécanique fausse, et il demande un ordinateur à côté.

L’hôte, provisoirement, c’est mon ordinateur portable branché en USB ; un Raspberry Pi prendra le relais. Pas d’interface web pour l’instant : Klipper expose une prise locale sur laquelle on envoie des commandes, et l’IA a écrit en une heure ce qu’il fallait pour ne pas taper de G-code à la main : un client pour envoyer une commande et lire la réponse, un script de suivi d’impression, et surtout calib.py, un pilotage au clavier où une touche vaut un geste — h pour le homing, s pour lancer la calibration delta, m pour la grille du plateau, d/u pour descendre ou monter la buse de 0,1 mm, [/] pour ajuster la première couche pendant qu’elle s’imprime.

Le parti pris, dès le départ, est le même que sur la Bambu : on mesure, on n’invente pas. Chaque valeur inscrite dans la configuration vient d’une mesure sur la machine, et chaque correction est suivie d’une pièce de contrôle.

D’abord la mécanique : les courroies

Avant de toucher au firmware, un audit rapide de ce qui bouge. Les courroies, sur cette machine, ont une histoire : un premier jeu détruit par sur-tension (« j’avais lu qu’il ne fallait jamais les tendre, et c’est ce qui m’est arrivé »), à l’époque où « aucun réglage n’avait d’effet ». Cette phrase-là, avec le recul, était la signature d’un problème mécanique et non de slicer, et c’est ce qui justifie de commencer par là.

L’IA a d’abord proposé la méthode qu’on lit partout : pincer la courroie, mesurer la note avec une application de guitare, viser une fréquence. Trois tours d’échanges plus tard, j’ai tranché : « c’est pas une corde, si je tends assez pour que ça sonne ça cassera tout ». Elle a vérifié, et j’avais raison : sur cette machine le brin libre fait 65 cm, la fréquence cible serait sous 30 Hz, là où les applications décrochent d’une octave (je lisais 70 Hz sans jamais retomber sur la même valeur). Surtout, un article de Hackaday rappelle que la qualité d’impression ne change quasiment pas avec des courroies franchement lâches, tant que l’axe ne prend pas de retard sur le moteur ; alors que trop tendre casse des arbres de moteur (un NEMA 17 accepte 28 N de charge radiale). Il n’y a pas de compromis à chercher : aucun bénéfice à serrer, un risque à serrer.

La méthode retenue est celle que j’utilise depuis des années : détendre franchement, puis retendre juste au seuil où la courroie se met à vibrer mollement au lieu de flotter. On approche par en dessous, donc la sur-tension est impossible ; le seuil est exactement la limite basse du sans-jeu ; le même geste sur les trois colonnes égalise par construction. Les six poulies tournaient librement. Audit clos. On verra plus loin que cette retension, faite au mauvais moment, a quand même coûté cher.

Ce que la machine avait dans le ventre

Avant de flasher, il fallait lire la mémoire du firmware d’origine : les valeurs qu’il utilisait sont le point de départ de la configuration Klipper, et une fois flashé, on ne peut plus les lire. Première surprise, en branchant l’USB : ce n’est pas Marlin. Tout ce qu’on lit sur la QQ-S suppose Marlin, et l’IA avait préparé les commandes Marlin (M503 pour lire la configuration, M665/M666 pour la géométrie delta). Réponse de la machine : Unknown command. Le firmware s’annonce FIRMWARE_NAME:Robin et c’est Repetier, qui dumpe sa mémoire avec M205. Première leçon, pas la dernière : vérifier avant d’affirmer.

Le dump, 970 m de filament et 233 heures de machine, a livré deux choses.

D’abord les valeurs réelles : bras 278,6 mm (la config Klipper de référence dit 280), rayon delta 140,8 (la référence dit 130 — dix millimètres d’écart, de quoi faire un dôme monstrueux si on avait pris la référence), hauteur 376,03, pas de moteur 100 pas/mm sur les colonnes et 367 pas/mm sur l’extrudeur (retenez ce chiffre).

Ensuite, un constat qui expliquait déjà beaucoup : tous les termes de correction par colonne étaient à zéro. Rayon delta A/B/C, correction de diagonale A/B/C, tout à zéro. Cette machine n’avait jamais été finement calibrée en delta — ou l’avait été en usine et l’avait perdu lors d’une mise à jour du firmware, qui réinitialise l’EEPROM : c’est mon hypothèse, et l’EEPROM ne garde pas d’historique pour la trancher. Dans les deux cas, ses erreurs de géométrie, quelles qu’elles soient, étaient intactes depuis des années, et les pas de l’extrudeur venaient probablement du même reset.

Klipper, et des moteurs qui n’ont plus de force

Le flash lui-même est sans histoire : Klipper compilé pour le STM32F103 de la carte MKS Robin Mini, avec un bootloader de 28 Ko, un quartz de 8 MHz et le port série USART3 ; le binaire passé par le petit script update_mks_robin.py de Klipper qui le brouille au format que le bootloader MKS attend ; copié sur une carte SD de 4 Go en FAT32, imprimante éteinte à l’insertion. Un bip, « complete » en vert, et Klipper répond Klipper state: Ready.

Et puis le premier homing a échoué. No trigger on stepper_b after full movement : un chariot n’a pas atteint son interrupteur. Le deuxième homing aussi, sur une autre colonne. Les moteurs grognaient, montaient à 5 mm/s, décrochaient à 25, et redescendaient « mollement ».

La suite tient en une leçon plutôt qu’en un récit. L’IA a enchaîné les hypothèses — durée des impulsions de pas, mode de micro-pas, courroies, un potentiomètre de courant qui n’existe pas sur cette carte —, chacune testée, chacune écartée, et chaque test allongeait la conversation sans y ajouter d’information. C’est un comportement à connaître quand on travaille avec une IA : plus sa fenêtre de contexte se remplit d’essais ratés, plus elle glisse vers l’essai suivant au lieu de revenir aux faits. Ce qui l’a arrêtée tient en une phrase, une contrainte forte : « avant le flash, tout marchait parfaitement ». La veille, sous Repetier, la même mécanique fonctionnait ; le matériel était hors de cause par construction, et la seule question valable devenait : qu’est-ce que l’ancien firmware faisait que le nouveau ne fait pas ?

Elle a alors fait ce qu’elle aurait dû faire d’abord : lire le fichier de brochage de cette carte dans les sources de Marlin, pins_MKS_ROBIN_MINI.h, et y chercher tout ce que l’ancien firmware initialisait au démarrage. Et là :

MOTOR_CURRENT_PWM_XY_PIN  PA6
MOTOR_CURRENT_PWM_Z_PIN   PA7
MOTOR_CURRENT_PWM_E_PIN   PB0
MOTOR_CURRENT_PWM_RANGE   1500
DEFAULT_PWM_MOTOR_CURRENT { 800, 800, 800 }

Sur la Robin Mini, la tension de référence qui fixe le courant des moteurs n’est pas réglée par un potentiomètre : elle est générée par le microcontrôleur, par un signal PWM sur trois broches. Repetier les fixait au démarrage. Klipper les laissait flotter — référence quasi nulle, couple minuscule, dérive au fil des minutes (« ça bouge mieux qu’au début »). Et la configuration Klipper officielle de cette imprimante, printer-flsun-qqs-2020.cfg, ne contient pas ces lignes (au moment où j’écris). Quiconque suit cette config sur une Robin Mini a des moteurs sous-alimentés.

La correction tient en trois blocs de configuration : une sortie PWM matérielle par broche, 800 sur une échelle de 1500, à 1 kHz, la valeur par défaut de Marlin. Homing immédiat, trois colonnes déclenchées, vitesse normale. « Déplacement parfait ! »

[output_pin motor_current_ab]
pin: PA6
pwm: True
hardware_pwm: True
cycle_time: 0.001
scale: 1500
value: 800

[output_pin motor_current_c]
pin: PA7
# idem

[output_pin motor_current_e]
pin: PB0
# idem

Calibrer une delta sans palpeur

Le palpeur de la machine n’était pas là. Ce n’est pas grave : la documentation de Klipper recommande de toute façon la calibration manuelle sur une delta, parce qu’un palpeur monté à côté de la buse introduit sa propre erreur quand l’effecteur s’incline. La méthode, c’est la feuille de papier : DELTA_CALIBRATE METHOD=manual envoie la buse à 2 mm au-dessus de sept points du plateau, un au centre et six en cercle ; à chaque point on descend la buse par pas de 1 mm, puis 0,1, puis par bissection, jusqu’à ce qu’une feuille de papier de 0,1 mm frotte juste entre la buse et le verre ; on valide, la buse va au point suivant. Sept points, un quart d’heure. Klipper calcule ensuite les paramètres qui mettent ces sept points dans un plan.

La pièce calibrate_size.stl livrée avec Klipper, pour la calibration étendue des bras. Elle sera imprimée mais pas utilisée : on verra pourquoi.

Le premier résultat, le 4 septembre après-midi : rayon delta 141,18 (l’EEPROM disait 140,8), et surtout angle de la colonne A à 211,02° et de la colonne B à 330,45°, au lieu des 210° et 330° nominaux. Un degré sur A. C’est énorme pour une delta, et c’était le défaut « qu’aucun réglage ne corrigeait » : un angle de colonne faux vrille les pièces et déforme le plateau en trèfle, et aucun réglage de slicer, aucune grille de plateau, ne rattrape ça.

Dans la foulée, la bed mesh, la grille du plateau : BED_MESH_CALIBRATE METHOD=manual, même geste au papier sur 13 points, pour corriger ce que le verre a de non plan. Étendue 0,51 mm, dominée par les deux bords de l’axe Y. Sauvegardé, chargé au début de chaque impression. Calibration à froid terminée.

Notez ce détail : la grille a été mesurée à froid, et j’ai retendu les courroies entre la calibration delta et sa vérification. On y reviendra.

L’extrudeur mentait de 11,5 %

Le test le plus simple du monde, et je ne l’avais jamais fait en six ans : un trait au feutre sur le filament à 120 mm de l’entrée de l’extrudeur, on demande à la machine d’en avancer 100, on mesure ce qui reste. Attendu : 20 mm. Mesuré : 31,5 mm. La machine avait poussé 88,5 mm pour 100 demandés.

Les 367 pas/mm de l’EEPROM, reportés fidèlement dans Klipper (rotation_distance 8,719), étaient faux de 11,5 %. Corrigé à 7,716, contre-vérifié sur un second test : 20,0 mm restants, « parfait ! ».

Mesurez ce que ça veut dire : chaque couche jamais posée par cette machine manquait d’un dixième de sa matière. Parois faibles, jointures ouvertes, dessus irréguliers, mauvaise adhérence entre couches — tout ce que je mettais sur le compte de « la delta » ou « le PETG ». Et aucun réglage de slicer ne compense une erreur qu’on ignore : on peut monter le débit à 110 % au hasard, on ne sait pas pourquoi, et ça ne tient pas d’un filament à l’autre.

Avec les angles de colonnes et le courant moteur, ça fait trois défauts d’origine — d’origine ou d’une mise à jour de firmware qui a tout remis à zéro, la machine ne dira pas lequel — jamais vus.

PID, PETG humide et le premier print

Les régulations de température (PID) se recalibrent en dix minutes, mais celle de la buse a fait sauter la protection thermique de Klipper : heater extruder not heating at expected rate. La courbe montrait une chauffe parfaitement saine (27 → 234 °C en 95 s), puis une inertie inhabituelle entre le bloc et sa thermistance qui fait croire à la protection que la chauffe s’arrête. Pas de désactivation : une fenêtre élargie dans [verify_heater extruder], documentée dans la config.

Puis la première pièce, en PETG, celui qui vivait sur la machine depuis des lustres. Le cube est sorti… comme ça :

Le premier cube, en PETG. Ça crépitait dans la buse pendant l’impression : la bobine était saturée d’eau. Les parois sont de la mousse.

Ce n’est pas l’imprimante : c’est le filament. Le PETG est hygroscopique, et une bobine laissée à l’air pendant des années crépite dans la buse (l’eau se vaporise) et sort mousseux. Une bonne part de la « fiabilité décevante » de cette machine, c’était ça. Bobine de PLA neuve pour toute la calibration ; le PETG passera au sèche-filament.

En PLA, square.stl de Klipper (un cadre d’un millimètre de paroi, cinq millimètres de haut, six minutes) : paroi 1,00 mm, hauteur 5,00. Et le premier cube de contrôle : Z 20,00 · X 20,40 · Y 20,45. La hauteur est parfaite — les colonnes sont bonnes. L’excès de 2 % en XY, on le règlera à la fin.

square.stl : le test de première couche et de débit de Klipper. Paroi 1,00 mm pile.

Le pied d’un cadre, vu de très près : la petite lèvre qui déborde à la base dit que la première couche est un peu trop écrasée. C’est avec ce test qu’on règle le décalage de première couche, par pas de 0,05 mm, pendant l’impression.

Pressure advance

Dernier réglage avant de s’attaquer au plateau : le pressure advance. Sur une machine à bowden (le moteur d’extrudeur est sur le châssis, un long tube amène le filament à la buse), la pression dans le tube met du temps à monter et à retomber ; sans compensation, les coins gonflent et les fins de ligne bavent. Klipper compense en poussant un peu plus avant les accélérations et en retirant avant les décélérations, avec un seul paramètre. On le mesure avec une tour de test où le paramètre augmente avec la hauteur (TUNING_TOWER), et on cherche à l’œil la hauteur où les coins sont les plus nets.

La tour square_tower.stl : en bas, pas assez de compensation, les coins gonflent ; en haut, trop, ils se creusent. Le meilleur coin est à 19 mm.

Meilleur coin à 19 mm, pas de 0,020 par millimètre : pressure advance 0,38, dans la plage attendue pour un bowden. Gravé.

La spirale, ou comment voir sa première couche

Pour juger le nivellement, il me fallait mieux que la feuille de papier : je me souvenais d’un objet en spirale qu’on imprime pour voir la première couche d’un coup d’œil. Plutôt que de chercher un fichier tranché pour une autre machine, l’IA a généré le G-code directement : une seule ligne continue, en spirale d’Archimède, du centre jusqu’à 120 mm de rayon, une spire tous les 2,5 mm, une seule couche de 0,2. Douze minutes. Là où la buse est trop près, le cordon est écrasé, plat, translucide ; là où elle est trop loin, il est rond, étroit, mal collé. Sur un plateau rond, c’est le test le plus lisible qui soit.

La première spirale. Trois lobes brillants à 120° l’un de l’autre : la signature d’une géométrie delta, pas d’un plateau gondolé.

La première spirale montrait un trèfle à trois lobes. Un verre gondolé ne fait pas de trèfle ; une delta mal calibrée, si. Et pourtant la calibration venait d’être faite. La bonne conclusion aurait été : la géométrie n’est pas encore juste, refaire la calibration. On a pris l’autre chemin.

La fausse piste : deux jours à corriger la grille

Ma demande était raisonnable : « une impression avec une épaisseur prédéterminée serait plus pertinente que le test de la feuille ». L’IA a construit la méthode : imprimer un carré d’une couche sur chacun des 13 points de la grille, mesurer leur épaisseur, et corriger chaque point de la grille de l’écart à la moyenne. Un carré plus épais que les autres = la buse était plus haute là = le plateau y est plus bas que ce que la grille croit = on abaisse le point. Elle a écrit le script (fix-mesh.py) qui fait le homing, place la buse à 100 mm au-dessus de chaque carré pour l’identifier (« comment déterminer qui est qui ? » — le logo n’est pas une référence), enregistre les mesures, réécrit la grille. Mon micromètre étant gradué en pouces, on saisit en millièmes (13t).

Passe 1 : treize carrés de 20 mm, une couche, un par point de la grille.

Le micromètre, gradué en pouces : un trait du fourreau vaut 25 millièmes, le tambour donne l’unité. 13 thou = 0,33 mm.

L’instrument lui-même : un Lufkin Rule Co. de Saginaw, Michigan, n° 1941. Il a plus d’années que moi et mesure toujours au millième de pouce. Entre ses touches, une couche de PLA.

Ça marchait. Passe 1 : étendue des épaisseurs 0,30 mm. Passe 2 : 0,084 mm. La spirale suivante était nettement meilleure, le trèfle s’estompait. Puis on est passés à une grille plus fine, 7×7 (29 points, pas de 40 mm au lieu de 55), parce que les défauts restants semblaient tomber entre les points. Passe 3, passe 4, gain réduit pour ne pas osciller. Et à chaque spirale, les mêmes zones revenaient, atténuées mais au même endroit.

Spirale n°3, annotée par moi : rouge = trop près (raclé), bleu = trop loin (pas collé). Cinq taches, plus de trèfle net.

Spirale n°4, après la grille 7×7 : deux zones rouges au lieu de cinq, le bleu toujours au même coin.

Grille 7×7, 29 carrés de 10 mm. Deux carrés de gauche sont arrachés : trop près. Le micromètre, lui, les mesurait « épais ».

C’est là que j’ai dit ce qu’il fallait dire : « pour moi l’erreur est très répétable sur les trois dernières spirales. On a du manque aux mêmes zones et les corrections ont bien amélioré les choses mais ça ne corrige pas vraiment le fond du problème. » Trois passes de correction auraient dû suffire. Quelque chose d’indépendant du réglage résistait.

Spirale n°5 : rouge, quasi absence de filament ; rose, léger manque ; bleu, pas collé. Les mêmes zones, encore.

Deux macros ont tranché. Dans la zone bleue, le cordon est rond, étroit, posé sans être pressé, et la transition est progressive sur 25 mm vers le bord : la buse s’éloigne régulièrement en allant vers le bord. Dans la zone rouge, les cordons sont larges, plats, translucides, écrasés jusqu’au film — on voit les points du plateau à travers. Trop près, réellement.

Zone bleue : cordon rond, non pressé, qui ondule et fait des nœuds là où il a accroché. Trop loin.

Zone rouge : cordons écrasés, translucides, on voit le plateau à travers. Trop près, sans discussion.

Et voilà la contradiction : dans ces zones rouges, les carrés mesuraient une épaisseur normale. Explication, une fois qu’on la voit : un carré imprimé trop près se fait une lèvre relevée sur son pourtour, et les touches du micromètre, six millimètres de diamètre, se posent sur cette lèvre. Il lit « épais » exactement là où c’est écrasé. La méthode des carrés était biaisée dans le sens précis qui empêchait de converger. Deux conclusions de l’IA bâties sur ces mesures (« la buse est à 0,4 mm du verre en moyenne », « il faut descendre le zéro global ») sont tombées avec.

Restait la question de fond : pourquoi des zones si répétables ? Ma piste était les courroies. L’IA a écrit un test de répétabilité (touche R : même point, cinq approches par des chemins différents, feuille de papier) : répétable à 0,1 mm quel que soit le chemin. Courroies et jeu hors de cause. Mais ce test a donné autre chose : à ces points, la feuille frottait à Z = +0,2 et +0,6 mm — la machine croyait le plateau un demi-millimètre plus bas qu’il n’est. Et la grille elle-même portait une pente de 0,65 mm d’avant en arrière, que rien ne justifie sur une delta calibrée.

La cause était dans le déroulé du premier jour. La calibration delta avait été faite à froid ; entre cette calibration et sa vérification, j’avais retendu les courroies ; la vérification avait montré un décalage, et l’IA avait appliqué +0,4 mm uniforme aux trois butées. Mais la retension avait déplacé les trois colonnes inégalement. Le résidu, une pente inclinée, était parti dans la grille, et une grille de delta ne rend jamais une pente plane : elle laisse des lobes, que quatre passes de carrés au micromètre ont poursuivis sans les attraper.

L’arrivée : tout refaire à chaud, au papier

Plateau à 60 °C, buse froide, grille vidée. DELTA_CALIBRATE manuel, sept points au papier, quinze minutes. Le verdict est dans les butées :

Les angles n’ont presque pas bougé (A 211,02 → 210,93, B 330,45 → 330,33), le rayon non plus (141,18 → 141,29). La géométrie tenait. Ce qui était faux, c’étaient les butées, inégalement : 0,38 mm d’écart entre A et B. Exactement la pente que la grille portait.

Sauvegarde, homing, puis la grille au papier sur les 29 points, une demi-heure. Centre plat à ±0,1 mm sur 80 mm de rayon ; le bord avant plonge de 0,6 mm à 120 mm du centre — c’est le verre lui-même, ou la delta en bout de course, et cette fois c’est mesuré directement et la grille le sait. Puis la spirale :

Spirale n°6, la première avec géométrie et grille cohérentes, toutes deux mesurées à chaud. Uniforme d’un bord à l’autre, bord avant compris.

Le cordon, à la loupe : régulier, même largeur d’une spire à l’autre, collé partout.

Six spirales, et la bonne a été celle où l’on a arrêté de corriger et recalibré, en trente-cinq minutes, avec une seule méthode.

Restait un dernier piège, de la même famille : le décalage de première couche, +0,07 mm, avait été réglé le premier jour sur le zéro froid. Sur le nouveau zéro, à chaud, le cube de contrôle n’a pas collé. Un nouveau zéro implique de re-régler l’offset de première couche, jamais de reporter l’ancien. Cadre de test, ajustement en direct par pas de 0,05 : −0,10 colle à peine, −0,20 colle avec une lèvre de 0,3 mm au pied ; gravé à −0,15.

Le cube de contrôle relancé avec l’ancien décalage de première couche : il n’a pas collé. Le zéro avait changé, l’offset non.

Et le cube, enfin : 20,3 × 20,4 × 20,00, lèvre de 0,1 mm par côté. Le premier jour il faisait 20,40 × 20,45 × 20,00. L’excès en XY n’a pas bougé avec la géométrie, parce que ce n’est pas de la géométrie : la pièce à sept piliers, mesurée au pied à coulisse, donnait un entraxe de 65,0 ± 0,4 mm sur 65 nominaux, soit une échelle juste à 0,5 % près ; une erreur de bras aurait donné +1,3 mm là-bas. Ce qui reste est un excès constant de largeur de cordon, coins qui gonflent, paroi à 1,07 pour 1,00, et ça se règle dans le tranchage comme sur n’importe quelle machine : multiplicateur d’extrusion 0,95, compensation XY −0,1 mm, compensation de pied d’éléphant 0,1 mm, dans un profil de production séparé du profil brut de test. La calibration étendue des bras, longue et délicate, n’était pas nécessaire. Cube de contrôle avec ce profil : 20,0 × 20,1 × 20,0.

Ce que j’en retiens

Calibrer dans l’état où l’on imprime. À chaud. Une machine calibrée à froid décrit un plateau qui n’existe plus quand le PLA arrive.

Une seule méthode de mesure, du début à la fin. Le papier pour la géométrie, le papier pour la grille, le cadre de test pour la première couche. Chaque changement de méthode a introduit un biais que personne ne voyait.

La géométrie d’abord, la grille ensuite, jamais l’inverse. Une grille qui n’arrive pas à converger en deux passes ne manque pas de points : elle compense une erreur qui n’est pas la sienne. Et toute retension de courroie remet la géométrie en jeu — refaire s puis m, pas de raccourci.

Quand deux mesures se contredisent, on va voir. La loupe sur le cordon a tranché en une minute ce que quatre passes de micromètre n’avaient pas résolu. Une mesure n’est pas une vérité, c’est un instrument avec ses angles morts.

L’IA sur-ingénie quand elle comprend mal. Le script de correction de grille par carrés au micromètre était astucieux, bien fait, persistant, avec reprise et corrections — et il optimisait une mauvaise idée. C’est moi qui ai dit « c’est répétable, ce n’est pas le réglage », et c’est la macro qui a tranché. Elle a en revanche trouvé en une lecture ce que six ans de forums n’avaient pas : le courant moteur par PWM, l’extrudeur faux de 11,5 %, la calibration jamais faite.

« Ça marchait avant » est une donnée. Deux fois dans cette histoire, mon jugement sur ma machine valait mieux qu’une méthode lue ailleurs : sur la tension des courroies, sur le homing. Et deux fois, l’IA a fini par le vérifier et me donner raison, avec les sources. C’est la bonne répartition : elle lit vite, elle ne mesure pas à ma place.

Où on en est

Pour reproduire

Matériel : une FLSun QQ-S de 2020 (carte MKS Robin Mini) — la démarche vaut pour toute delta, les broches non ; un ordinateur sous Linux avec un port USB ; une carte SD ≤ 8 Go en FAT32 ; une feuille de papier de 80 g ; un pied à coulisse ; une bobine de PLA sèche. Pas de palpeur, pas d’accéléromètre.

Avant de flasher, lire la mémoire du firmware d’origine (sur Repetier : M205 ; sur Marlin : M503) et garder le dump. Noter en particulier la longueur des bras, le rayon delta, la hauteur, et les pas/mm de l’extrudeur.

Firmware : Klipper, make menuconfig → STM32F103, bootloader 28 KiB, quartz 8 MHz, USART3 (PB11/PB10), 250000 bauds ; puis scripts/update_mks_robin.py out/klipper.bin Robin_mini.bin ; le fichier à la racine de la carte SD, imprimante éteinte à l’insertion, allumer, attendre « complete ». Le bootloader renomme le fichier en .CUR. Le script build-firmware.sh fait tout ça.

Configuration : printer.cfg, avec ses valeurs réelles et ses commentaires. Les trois blocs [output_pin motor_current_*] sont indispensables sur une Robin Mini. Le bloc SAVE_CONFIG en fin de fichier contient les résultats des calibrations ; pour repartir de zéro, le supprimer et remettre les valeurs de l’EEPROM en [stepper_a/b/c] et [printer].

Outils : start-klipper.sh (démarrer l’hôte), send-gcode.sh et klippy-client.py (envoyer une commande), calib.py (pilotage clavier des calibrations), watch-print.py (suivi d’impression), make-spiral.py (la spirale). Les profils PrusaSlicer en ligne de commande sont dans slicer/ : qqs-pla.ini brut pour les tests, qqs-pla-prod.ini pour les pièces.

Dans l’ordre, à chaud (plateau à la température d’impression, buse froide pour le papier) :

Trois règles, si vous vous y mettez : à chaud, une seule méthode de mesure, et toute intervention mécanique (courroies, bras, plateau) renvoie à l’étape 2. Si une grille ne converge pas en deux passes, ne pas ajouter de points : refaire la géométrie.

Lire la spirale : rouge = trop près (cordon plat, translucide, raclé), bleu = trop loin (cordon rond, mal collé). Un trèfle à trois lobes = géométrie ; des taches locales = plateau ou grille ; un bord qui plonge progressivement = le verre ou la delta en bout de course. En cas de doute, la loupe.

Questions fréquentes

Faut-il un palpeur pour calibrer une delta sous Klipper ?

Non. La documentation Klipper recommande la calibration manuelle au papier sur les deltas, parce qu’un palpeur décalé de la buse introduit sa propre erreur quand l’effecteur s’incline. Sept points pour la géométrie, treize à vingt-neuf pour la grille, une demi-heure en tout.

Mes moteurs grognent et le homing échoue après le passage à Klipper sur une MKS Robin Mini. Pourquoi ?

Parce que le courant des moteurs est réglé par PWM depuis le microcontrôleur (broches PA6, PA7, PB0) et que la config Klipper officielle de la QQ-S ne le fait pas. Trois blocs [output_pin] en PWM matériel, valeur 800 sur 1500, règlent le problème. Voir Klipper, et des moteurs qui n’ont plus de force.

Ma FLSun QQ-S est-elle sous Marlin ?

Pas la QQ-S de 2020 : elle est sous Repetier (FIRMWARE_NAME:Robin). M503, M665, M666, M900 répondent Unknown command ; c’est M205 qui lit la mémoire. Les tutoriels Marlin ne s’appliquent pas.

Ma grille de plateau ne converge pas, même après plusieurs passes. Faut-il plus de points ?

Presque jamais. Une grille qui ne converge pas compense en général une erreur de géométrie (butées inégales, angle de colonne) ou une calibration faite à froid. Refaire DELTA_CALIBRATE à chaud, puis la grille, avec la même méthode de mesure.

Comment savoir si mon extrudeur pousse la bonne quantité ?

Un trait sur le filament à 120 mm de l’entrée de l’extrudeur, M83 puis G1 E100 F60, mesurer ce qui reste : 20 mm attendus. Ici il en restait 31,5 : 11,5 % de sous-extrusion depuis toujours. Nouveau rotation_distance = ancien × extrudé / 100.

La méthode des carrés d’épaisseur au micromètre est-elle bonne ?

Elle est biaisée là où la buse est trop près : le carré écrasé fait une lèvre relevée sur son pourtour, et le micromètre la lit « épais ». Si vous y tenez, des carrés de 20 mm mesurés au centre, touches loin du bord. La spirale et le papier sont plus fiables.

Faut-il tendre les courroies d’une delta à une fréquence précise ?

Non. La fréquence dépend de la longueur du brin, de la masse et de la composition de la courroie ; une même note ne signifie pas une même tension d’une machine à l’autre, et sur une QQ-S le brin est trop long pour être mesuré. Détendre, puis retendre au seuil où la courroie vibre mollement au lieu de flotter, sur les trois colonnes. Et refaire la calibration delta après.

Le cube fait 20,3 au lieu de 20,00 en XY : dois-je calibrer les bras ?

Pas si l’excès est constant. Vérifiez sur une pièce plus grande (la pièce à sept piliers de Klipper, entraxe 65 mm) : si l’échelle est juste, l’excès vient de la largeur de cordon et se corrige dans le slicer (multiplicateur d’extrusion, compensation XY). La calibration des bras corrige une erreur d’échelle, pas un excès constant.

Qu’a fait l’IA exactement, et qu’a fait l’humain ?

Claude a lu l’EEPROM et le fichier de brochage de la carte, compilé et préparé le firmware, écrit la configuration et tous les scripts, généré la spirale, conduit les calibrations et rédigé ce billet avec moi. Elle s’est trompée sur le firmware (Marlin), sur la cause du homing (plusieurs heures), sur la tension des courroies, et sur la méthode des carrés. J’ai tenu la feuille de papier, le pied à coulisse, le micromètre et l’appareil photo ; j’ai lu les spirales ; j’ai dit « ça marchait avant », « c’est pas une corde » et « c’est répétable, ce n’est pas le réglage ». Les trois fois, c’était la bonne piste.

Petit glossaire

• Delta : imprimante où la buse est portée par trois bras articulés sur trois chariots verticaux ; la position est calculée, pas mesurée axe par axe.
• Effecteur : la pièce centrale qui porte la buse, au bout des bras.
• Bras (arm_length), rayon delta (delta_radius), angle de colonne, butée (position_endstop) : les paramètres de la géométrie ; voir l’encart « ce que chaque réglage corrige ».
• Homing : envoyer les chariots en haut jusqu’à leurs interrupteurs, pour connaître leur position.
• Bed mesh (grille du plateau) : carte des hauteurs du plateau, mesurée en quelques points, que le firmware interpole pour corriger la buse en continu.
• Test du papier : descendre la buse jusqu’à ce qu’une feuille de 0,1 mm frotte juste ; le Z = 0 est alors 0,1 mm au-dessus du verre.
• Offset de première couche : petit décalage en Z appliqué au début de chaque impression pour ajuster l’écrasement de la première couche.
• Rotation distance : sous Klipper, la distance parcourue (ou de filament poussée) par tour de moteur ; remplace les pas/mm.
• Pressure advance : compensation de la pression dans le tube bowden, qui nettoie les coins.
• PID : la régulation de température ; se recalibre par PID_CALIBRATE.
• Bowden : configuration où le moteur d’extrudeur est sur le châssis et pousse le filament dans un long tube jusqu’à la buse ; léger pour l’effecteur, mais élastique.
• Thou : millième de pouce, 0,0254 mm. Les micromètres anciens sont gradués ainsi.
• Lèvre / pied d’éléphant : bourrelet à la base d’une pièce, signe d’une première couche trop écrasée.
• PWM : signal carré dont on module la largeur ; sert ici à fabriquer une tension de référence pour le courant des moteurs.
• EEPROM : la mémoire du firmware d’origine où il garde ses réglages.

Références et copies locales

Pour que ce billet reste utile quand les liens auront disparu, les fichiers du projet sont hébergés ici.

• Klipper, documentation : Delta Calibrate · Bed Mesh · Bed Level · Manual Level · Pressure Advance · Resonance Compensation · Config Reference. Les pièces de test (square.stl, square_tower.stl, calibrate_size.stl, ringing_tower.stl) sont dans docs/prints/ du dépôt.
• Config Klipper de référence pour la QQ-S 2020 — printer-flsun-qqs-2020.cfg (sans les sorties de courant moteur, au 6 septembre 2026).
• Brochage de la MKS Robin Mini dans Marlin — pins_MKS_ROBIN_MINI.h (source des broches PWM de courant).
• Hackaday, « Don’t Tune Your 3D Printer To Middle ‘C’ After All » — sur la tension des courroies par fréquence (recherche sur le site).
• PrusaSlicer 2.8.1, dernière version avec une AppImage Linux — releases. Lancé en ligne de commande sans affichage (env -u DISPLAY) ; il ajoute ses propres commandes de chauffe sauf s’il trouve de vrais M104/M140 dans le G-code de départ.
• Les fichiers du projet : printer.cfg · calib.py · klippy-client.py · send-gcode.sh · start-klipper.sh · watch-print.py · build-firmware.sh · make-spiral.py · profils slicer/ · README-flsun.md (l’état de la machine et le mode d’emploi du dépôt).
• Pour mémoire, la fausse piste : fix-mesh.py, mesh-to-7.py, first_layer_29.stl, et analyze-delta.py pour la calibration étendue des bras, si un jour elle devient nécessaire.

Photos et mesures : les miennes. Firmware, configuration, scripts et rédaction : avec Claude. Ce billet est aussi disponible en Markdown brut.

La carte du pack, une fois la gaine ouverte. Les deux petites pastilles marquées « DA » et « CL », à droite, sont tout ce dont on a besoin. Les grosses au centre, C+ et C−, sont celles qu’on ne touche pas.

Un cloud éteint, puis un bouton qui meurt

Mon robot aspirateur est un Neato D800. Un bon robot : un LIDAR rotatif (un petit radar laser qui tourne sur le dessus et mesure les distances aux murs), une cartographie de la maison, des lignes interdites qu’on trace dans l’application, 600 € à l’époque. En 2023, Neato Robotics a fermé. Vorwerk, la maison mère, a gardé les serveurs allumés un moment — le « cloud », c’est-à-dire les ordinateurs distants sans lesquels l’application, les cartes et la programmation ne fonctionnent pas —, puis a annoncé le 6 octobre 2025 (copie locale) que ce cloud s’éteignait. « Your Neato robot will continue to function manually. Simply press the button once to launch a full house run. » Un robot à 600 € rétrogradé en aspirateur à un bouton, par communiqué.

Et puis, quelques mois plus tard, le bouton lui-même a cessé de répondre. Voyant rouge, erreur 4202, « batterie déchargée ». L’application, dans ses derniers souffles, précisait que le compteur de charge de la batterie était dépassé et qu’il fallait la remplacer. Batterie d’origine : 90 €, quand on en trouve. Compatible : 30 à 50 €, avec le risque bien documenté sur les forums que le robot la refuse.

Ce billet raconte comment on est passé de « robot mort, batterie morte » à une batterie qui explique elle-même ce qui ne va pas — sans rien acheter, avec trois fils et un microcontrôleur qui coûte le prix d’un café. Il raconte aussi un faux espoir, parce que c’est ce qui arrive quand on cherche pour de vrai. Il s’arrête sur ce que cette enquête m’aurait coûté il y a trois ans, avant qu’une IA puisse lire un manuel de 250 pages à ma place, et sur la petite puce remarquable qui gère cette batterie. Et il explique pourquoi cette histoire me laisse un goût amer sur la manière dont on fabrique les objets.

Premier réflexe : les cellules

Une batterie de robot, c’est un boîtier qui contient plusieurs cellules — des accumulateurs lithium au format 18650 (18 mm de diamètre, 65 mm de long, l’allure d’une grosse pile AA) — reliées en série et gérées par une petite carte électronique. Une batterie « déchargée » qui ne se recharge plus, c’est classiquement des cellules mortes. J’ai donc fait ce que fait tout bricoleur : ouvert le pack, dessoudé les quatre cellules, soudé à la place quatre cellules de récupération — dépareillées, ce qui aura son importance plus loin —, refermé.

Résultat : toujours erreur 4202.

Multimètre en main (l’appareil qui mesure la tension, c’est-à-dire la « pression » électrique, en volts), pourtant, tout était parfait. 4,1 V sur chaque cellule, ce qui est une cellule lithium pleine ; 16,4 V aux bornes du pack ; 16,4 V au connecteur de sortie, ce qui signifie que le circuit de protection — l’interrupteur électronique qui peut isoler les cellules en cas de danger — laissait bien passer le courant. La thermistance (une résistance dont la valeur change avec la température, que le robot lit pour surveiller la batterie) affichait 6 kΩ, une valeur normale pour une pièce tiède. Le robot avait entre les mains une batterie chargée à 95 % et en bonne santé, et il affichait « batterie déchargée ».

C’est le moment où l’on comprend que le problème n’est pas la batterie. C’est ce que la batterie dit d’elle-même.

La batterie a un cerveau

Les packs des Neato de dernière génération (D8, D9, D10, D800) sont des « batteries intelligentes » (smart batteries) : à côté des cellules, la petite carte porte une jauge de charge, une puce — un circuit intégré, une minuscule plaquette de silicium qui contient un ordinateur spécialisé — de Texas Instruments, le bq40z50-R2. C’est elle qui mesure le courant, additionne ce qui entre et ce qui sort, en déduit l’état de charge, coupe en cas de surtension ou de surchauffe — et c’est elle qui parle au robot, par un bus série : deux fils sur lesquels circulent des messages numériques, un fil pour les données et un pour l’horloge qui rythme la conversation. Le protocole (la langue parlée sur ces fils) s’appelle SMBus, cousin industriel de l’I²C que connaissent tous les bricoleurs d’Arduino. Un fil bleu supplémentaire dans le connecteur du pack porte cette conversation jusqu’au robot.

Le robot ne mesure pas la tension de la batterie. Il demande à la jauge : « tu es chargée à combien ? », « quel courant de charge veux-tu ? », « quelle tension ? », « combien de cycles as-tu faits ? ». Et il obéit à ce qu’elle répond. Si la jauge dit « 0 % » ou « ne me charge pas », le robot affiche « batterie déchargée », quelle que soit la réalité électrique à trois centimètres de là.

Cette architecture n’est pas absurde : une jauge dans le pack connaît l’historique des cellules, gère leur équilibrage (maintenir les quatre cellules au même niveau de charge, faute de quoi la plus faible s’use en premier), et protège efficacement contre l’emballement thermique (la réaction en chaîne qui fait prendre feu une cellule lithium maltraitée). Mais elle a une conséquence : remplacer les cellules ne remet pas la jauge à zéro. Le compteur de cycles, la capacité apprise, les drapeaux d’erreur (des cases « oui/non » que la puce coche quand elle détecte un problème) — tout ça vit dans la mémoire de la puce, pas dans les cellules. On change le cœur, le cerveau garde ses souvenirs.

Sur les forums, la piste s’arrête généralement là. Les puces des packs D3–D7 sont d’un fabricant obscur et verrouillées ; pour les bq40z50 « il faut un EV2400 et bqStudio » — l’adaptateur officiel de Texas Instruments, 150 €, et son logiciel Windows — et personne ne sait vraiment quelles données le robot vérifie. Fin de l’histoire, achetez une batterie.

Trois fils et un ESP32 à deux euros

Sauf que le bq40z50 est une puce publiquement documentée. Texas Instruments publie son Technical Reference Manual — le manuel de référence, 250 pages qui décrivent chaque registre, chaque commande, chaque adresse en mémoire (copie locale du PDF, 1,6 Mo). Et le SMBus, n’importe quel microcontrôleur — un ordinateur complet sur une puce, quelques euros, celui qu’on trouve dans une carte Arduino — sait le parler dès qu’il a deux broches I²C.

J’ai des ESP32-C3 « Super Mini » plein un tiroir : une carte de la taille d’un timbre, deux euros pièce, qui se branche en USB et se programme comme un Arduino.

Sur la carte du pack, deux pastilles de test — des points de contact laissés exprès par le fabricant pour brancher ses appareils de contrôle en fin de chaîne — sont sérigraphiées DA et CL : data et clock, les deux fils du SMBus. Un fil sur DA, un sur CL, un sur le moins des cellules, et de l’autre côté les broches GPIO 4, GPIO 5 (GPIO : les broches d’entrée-sortie numérotées d’un microcontrôleur) et GND (la masse, le « zéro volt » commun) de l’ESP32. Pas de composant à ajouter, pas d’alimentation à fournir : la jauge est alimentée par ses cellules et l’ESP32 par son USB.

Côté logiciel, deux cents lignes en Arduino, écrites avec une IA (Claude) qui a lu le manuel à ma place : on lit les registres standards (tension, courant, état de charge, compteur de cycles, tensions par cellule), puis les registres d’état internes — statut de sécurité, défauts permanents, état des transistors de charge et de décharge —, puis on recopie la mémoire flash. Rien n’est écrit sans un ordre explicite. On écoute.

Ce que la puce a dit

Première lecture, sur le moniteur série :

Voltage            : 16386 mV
RSOC               : 97 %
RemainingCapacity  : 2343 mAh
FullChargeCapacity : 2437 mAh
DesignCapacity     : 2500 mAh
CycleCount         : 1547
ChargingCurrent    : 0 mA
ChargingVoltage    : 0 mV
Cellules           : 4094 / 4097 / 4100 / 4095 mV
ManufacturerName   : BLUEWAY-
DeviceName         : bq40z50-
ManufactureDate    : 2022-01-09
OperationStatus    : PRES DSG CHG SEC0  -> sécurité : FULL ACCESS
SafetyStatus       : (aucun flag)
PFStatus           : (aucun flag)

Pour lire ce relevé : mV et mA sont des millivolts et des milliampères (millièmes de volt et d’ampère) ; les mAh, milliampères-heures, mesurent une quantité d’énergie stockée — 2437 mAh, c’est de quoi fournir 2,4 A pendant une heure ; RSOC est le pourcentage de batterie affiché ; FullChargeCapacity est ce que la jauge pense pouvoir stocker aujourd’hui, DesignCapacity ce que le pack stockait neuf.

Trois choses sautent aux yeux.

La jauge est en pleine forme. Aucun défaut de sécurité, aucun défaut permanent, transistors de charge et de décharge passants (les transistors, ou FET, sont les interrupteurs électroniques par lesquels la jauge autorise ou coupe la charge et la décharge), état de charge estimé à 97 % — cohérent avec les 4,1 V par cellule. Elle n’est pas « déchargée », et elle le sait.

Elle n’est même pas verrouillée. Le niveau de sécurité est FULL ACCESS : le mode le plus permissif de la puce, celui que TI recommande de quitter avant de sortir de l’usine. Pas de mot de passe à casser, pas de clé à deviner. Toute la mémoire est lisible et inscriptible. Le fabricant du pack a livré la maison avec les clés sur la porte.

Et pourtant elle dit au robot de ne pas la charger. ChargingCurrent = 0 mA, ChargingVoltage = 0 mV. Ce sont les deux registres qu’un chargeur intelligent lit pour savoir quoi faire. À zéro, ils signifient : « n’envoie pas de courant ».

Et le compteur : 1547 cycles. Un cycle, pour une jauge, c’est une décharge cumulée équivalant à une batterie entière — deux demi-décharges font un cycle. Pour une batterie fabriquée en janvier 2022, c’est un cycle par jour depuis quatre ans — plausible pour un robot qui passe quotidiennement. C’est aussi le nombre que l’application m’avait reproché.

Dix-sept mille lignes de manuel, et un faux espoir

La question devient : pourquoi la jauge refuse-t-elle la charge ? Le manuel TI liste précisément les cas où ChargingVoltage() tombe à zéro : transistor de charge coupé par une protection, température hors plage, défaut permanent, pack déclaré « retiré », surtension du chargeur détectée. On les a tous vérifiés, registre par registre. Aucun n’était actif. Température 26 °C, région de température « recommandée », région de tension « haute », tout au vert.

On a aussi exploré une piste séduisante : le bq40z50 possède une fonction de dégradation par compteur de cycles, qui réduit volontairement la tension et le courant de charge à mesure que le pack vieillit — une obsolescence programmée au sens littéral, activable par un bit de configuration. On a lu ce bit dans la mémoire flash. Il était à zéro. Neato ne l’avait pas activée. La table de charge disait 4,2 V par cellule et 1,5 A dans toutes les plages de température. Sur le papier, la jauge devait annoncer 16,8 V et 1500 mA. Elle annonçait 0 et 0.

Avant d’aller plus loin, on a fait ce qu’il faut toujours faire avant de toucher à une mémoire qu’on ne pourra pas racheter : une sauvegarde complète. 8 Ko, 256 blocs de 32 octets (un octet, c’est huit bits, la plus petite unité de mémoire), lus un par un et rangés dans un fichier (le voici, si le vôtre est le même pack). Si une écriture tourne mal, on peut tout remettre.

Puis on a tenté la chose la plus bête du monde. Le manuel documente une commande 0x0041 : Reset — redémarrage de la puce : sa mémoire vive (la mémoire de travail, effacée à chaque redémarrage) est reconstruite depuis la flash, rien n’est écrit. L’équivalent de « tu as essayé de l’éteindre et de le rallumer ? ». Une lettre r envoyée sur le moniteur série, trois secondes d’attente :

>>> Envoi MAC 0x0041 Reset
ChargingCurrent    : 1500 mA
ChargingVoltage    : 16800 mV
RSOC               : 97 %
FET DSG ON, FET CHG ON, PF inactif

Victoire, a-t-on cru. Pack remonté, robot posé sur sa base : plus d’erreur, il charge, il annonce qu’il est prêt. J’ai écrit une première version de ce billet le soir même, avec une conclusion triomphante sur le compteur de cycles dont « le robot ne s’était jamais soucié ».

Le lendemain matin, voyant rouge, erreur 4202.

Le symptôme qui disparaît quand on le regarde

Pack rebranché sur l’ESP32. ChargingCurrent : 0 mA, à nouveau. Redémarrage : 1500 mA. Et là, au lieu de crier victoire, on a laissé tourner et on a regardé l’horloge.

À 3 secondes : 1500 mA. À 20 secondes : 1500 mA. À 31 secondes : 0 mA — et dans le même relevé, un drapeau qui n’y était pas dix secondes plus tôt : SLEEP. Deux essais, deux relevés complets comparés ligne à ligne : entre 20 et 31 secondes, la seule chose qui change, c’est ce drapeau.

La jauge s’endort. Dès qu’il ne circule presque aucun courant (moins de 10 mA, seuil réglé dans sa configuration), elle passe en veille pour économiser ses cellules, et dans cet état elle annonce « courant de charge : 0 ». Le redémarrage ne réparait rien : il la réveillait trente secondes. Sur l’établi, avec un ESP32 qui ne consomme rien, elle se rendormait aussitôt. Dans le robot, qui tire quelques centaines de milliampères, elle est éveillée et annonce 1500 mA. Le « ne me charge pas » n’a jamais été le problème. C’était un mirage de laboratoire.

Le laboratoire du lendemain matin : un canapé, le pack sous kapton (le ruban adhésif jaune qui isole et résiste à la chaleur), l’ESP32 au bout de trois fils, et un terminal qui compare les relevés à dix secondes d’intervalle.

C’est une leçon que je connaissais et que j’ai quand même dû réapprendre : quand un symptôme disparaît au moment où on l’observe, c’est probablement l’observation qui l’a fait disparaître. Il faut regarder ce qui revient, pas ce qui part.

Le compteur

Restait le suspect initial, celui que l’application avait nommé : 1547 cycles. La jauge, elle, s’en moque — la dégradation par cycles est désactivée, on l’a vérifié. Mais le robot lit ce nombre (CycleCount, commande 0x17), et un logiciel embarqué (un firmware : le programme gravé dans le robot) qui affiche « compteur de charge dépassé » a forcément un seuil quelque part.

Le compteur est une simple valeur sur deux octets en flash, à l’adresse 0x4340. En Full Access, on l’écrit comme on l’a lue : une commande de bloc, l’adresse, deux octets. On a écrit zéro.

>>> CycleCount SBS avant = 1547 ; écriture DF 0x4340 = 0
>>> relecture 0x4340 : 00 00  (OK)
>>> CycleCount SBS après écriture = 0

Immédiat, sans redémarrage, aucun drapeau de sécurité levé. Une batterie neuve, aux yeux de qui ne regarde que ce nombre.

Le rebondissement

Le 1er septembre au soir, voyant rouge. Erreur 4202. Le robot avait tenu une journée.

Troisième fois que le scénario se joue : on touche au pack, on le rebranche, le robot repart, et le lendemain il s’arrête. Le redémarrage de la jauge avait « marché » un soir ; le compteur à zéro, un jour et quelques cycles. Vu de près, ces deux « victoires » ont un point commun qui n’est pas la correction : à chaque fois, on a débranché puis rebranché le pack. Le robot redémarre, oublie son état « batterie déchargée », réessaie — et retombe sur la même cause, qu’on n’avait pas trouvée.

Cette fois, avant tout redémarrage, pack sur l’ESP32 tel quel. Compteur de cycles : toujours 0. Aucune protection active, aucun défaut permanent, jauge en pleine forme — le même relevé rassurant que le premier soir. Sauf qu’on avait appris à se méfier des relevés rassurants, et on est allé lire une zone de la flash qu’on n’avait jamais décodée : les données de vie (Lifetimes), le journal que la jauge tient sur elle-même depuis sa sortie d’usine — tensions extrêmes vues par chaque cellule, nombre de fois où chaque protection s’est déclenchée, et à quel cycle pour la dernière.

Comparée à la sauvegarde du 29 août, elle disait ceci :

                          29 août      1er septembre
COV (surtension cellule)  6            246   (+240 en trois jours)
Vmax à vie, cellule 4     4213 mV      4293 mV   (seuil COV : 4225)
Fins de charge valides    21813        21813 (aucune depuis le recellage)
Cellules au repos         —            3986 / 3986 / 3995 / 3939 mV

Deux cent quarante déclenchements de la protection de surtension en trois jours, tous sur la cellule 4 — et pas une seule charge menée à son terme. Le pack d’origine en avait connu six en quatre ans.

L’explication tient en une image. Quatre cellules en série, c’est quatre seaux qu’on remplit par le même tuyau : si l’un est plus petit, il déborde le premier. La cellule 4 de mon jeu de récupération a moins de capacité que les trois autres — au repos elle est la plus basse (3,94 V contre 3,99), et en charge elle est la première à franchir 4,225 V. La jauge fait alors son travail : elle coupe le transistor de charge, attend que la cellule redescende à 4,1 V, rouvre, recoupe une seconde plus tard. Deux cent quarante fois. Le chargeur du robot, lui, voit une charge qui ne se termine jamais ; au bout d’un moment, son firmware en tire la seule conclusion qu’il connaît : « batterie déchargée », 4202.

Le compteur de cycles n’y était pour rien — ou pas pour tout. Pour le pack d’origine, on ne le saura pas : j’ai changé deux choses à la fois. Ses données de vie, elles, montrent 67 sous-tensions, la dernière au 1547ᵉ cycle ; la cellule à 41 mΩ qui s’affaissait en pleine aspiration est une explication au moins aussi bonne que le compteur. Le code 4202 est un fourre-tout.

La nouvelle tentative. La solution propre, c’est de passer les quatre cellules de récupération au testeur, comme les originales, et de remonter un pack avec les quatre cellules les mieux appariées parmi les huit. En attendant, la jauge permet un palliatif sans fer à souder, toujours par les trois fils — et c’est ce qu’on a fait le soir même :

• tension de charge abaissée de 4200 à 4100 mV par cellule : le pack s’arrête à 16,4 V au lieu de 16,8 ; la cellule 4 reste sous le seuil de surtension, et on perd environ 10 % d’autonomie ;
• capacité de référence ramenée à 2100 mAh (elle était restée à 2500, celle du pack neuf), capacité chimique des cellules alignée dessus ;
• jauge remise en mode apprentissage : ses valeurs apprises (capacité chimique, table de résistances) dataient des cellules de 2022 ; un bit lui dit de tout réapprendre sur les prochains cycles.

Redémarrage : la jauge annonce 16 400 mV et 1500 mA, une capacité à pleine charge estimée à 1792 mAh, aucun défaut. Pack refermé, robot sur sa base. Cette fois, on ne crie pas victoire : on attend quelques jours, et on rouvrira le journal de la jauge. Si le compteur de surtensions est toujours à 246, c’était ça.

Où on en est

Et puis il y a l’épilogue que je n’avais pas vu venir. Les quatre cellules d’origine, celles que j’avais dessoudées au début parce que « la batterie était morte », traînaient sur l’établi. Par acquit de conscience, je les ai mesurées : 3,6 V chacune. Aucune n’est en dessous du seuil où une cellule lithium se condamne. Je les ai donc passées au testeur de capacité — un Liitokala Lii-500, un chargeur-analyseur d’une trentaine d’euros, en mode « NOR TEST » : il charge la cellule à fond, la décharge ensuite à courant constant en comptant les milliampères-heures qui sortent, puis la recharge. C’est la seule façon honnête de savoir ce que vaut une cellule : la vider en la chronométrant.

Verdict, sur des cellules données pour 2500 mAh neuves :

Le testeur donne aussi la résistance interne de chaque cellule — la « friction » électrique du chimique, en milliohms (mΩ) : plus elle est élevée, plus la tension s’effondre quand le robot tire du courant, et plus la cellule chauffe au lieu de fournir. Trois cellules oscillent entre 16 et 19 mΩ, ce qui est bon pour des 18650 de cet âge. La quatrième est à 41 mΩ : plus du double. C’est le maillon faible du pack — celui qui s’affaisse le premier en pleine aspiration, entraîne les autres vers le seuil de coupure et donc écourte l’autonomie bien plus que ses 1819 mAh ne le laissent croire.

Mais aucune n’est morte. Après quelque chose comme 1547 cycles, ces cellules rendent encore les trois quarts de leur capacité d’origine : une perte normale, celle qu’on attend d’un lithium arrivé au bout de sa vie annoncée. Concrètement, l’autonomie serait passée de la pleine heure et demie à un peu plus d’une heure. Un aspirateur un peu moins endurant — pas un aspirateur mort.

C’est là que l’histoire prend son sens. Le pack qui a déclenché tout ça n’était pas défaillant : il était usé de 25 %, et quelque chose — un compteur, ou plus probablement sa cellule à 41 mΩ qui s’affaissait en pleine aspiration — a décidé que c’était fini. Le recellage que j’ai fait au premier réflexe n’était probablement pas nécessaire, et fait avec des cellules de récupération jamais mesurées, il a ajouté un problème (voir Le rebondissement) ; il m’aura au moins laissé quatre cellules d’origine en état de marche, mesurées, tracées, prêtes à servir de rechange le jour où celles de récupération lâcheront.

Ce que ça m’aurait coûté il y a trois ans

Soyons honnêtes sur la marche que j’ai franchie sans la voir.

Il y a trois ans, cette histoire se serait arrêtée au paragraphe « Premier réflexe : les cellules ». Cellules changées, erreur toujours là, multimètre formel : la batterie est bonne. Et ensuite ? Ensuite, un cul-de-sac. J’aurais cherché sur les forums, trouvé les mêmes fils que tout le monde — « il faut un EV2400 et bqStudio », « la puce est verrouillée », « achetez une batterie » — et j’aurais soit acheté, soit rangé le robot dans un placard en attendant un courage qui ne vient jamais.

Car la suite de la démarche, qui tient ici en quelques paragraphes, représente un travail que je n’aurais pas pu fournir en soirées de bricoleur. Mettons-le à plat :

1. Identifier la puce et trouver son manuel : facile.
2. Lire le manuel : 250 pages, 17 000 lignes en anglais technique dense, écrites pour des ingénieurs batterie qui en connaissent déjà le vocabulaire. Il ne s’agit pas de le survoler : il faut y trouver les trois tables qui disent quand le courant de charge tombe à zéro, la procédure d’écriture de la flash, la carte des 400 adresses de configuration, la signification de chaque bit d’une dizaine de registres d’état.
3. Apprendre le SMBus au niveau du protocole (le block read, le block write, la commande 0x44 et son écho, l’auto-incrément d’adresse) et écrire un programme qui le parle sans erreur.
4. Interpréter un relevé de quarante drapeaux et 8 Ko d’octets bruts, en les croisant avec le manuel.
5. Concevoir les expériences : le redémarrage, puis — après le faux espoir — l’idée de comparer deux relevés complets à dix secondes d’intervalle pour isoler la ligne qui change.
6. Écrire dans la flash sans rien casser.

Pour un développeur compétent qui n’est pas ingénieur batterie, c’est plusieurs semaines de soirées, avec un vrai risque d’abandon au point 2 — et c’est exactement là que s’arrêtent les fils de forum. Ce n’est pas que ce soit difficile au sens intellectuel ; c’est que c’est long, et que rien ne garantit, au départ, que ces semaines mènent quelque part.

Avec Claude, les points 2 à 6 ont pris deux soirées et une matinée. L’IA a absorbé le manuel en quelques secondes, écrit le sketch en une passe, décodé les registres à mesure qu’ils arrivaient, proposé le redémarrage, puis — quand le redémarrage a menti — proposé de le refaire en enregistrant tout, et trouvé le drapeau SLEEP dans la comparaison. Ce que je gardais, moi : le fer à souder, le multimètre, les photos, les décisions (« on ne touche pas à Qmax, on laisse apprendre »), et surtout le doute : c’est le test d’une nuit dans le vrai robot qui a démenti la victoire, pas une lecture de plus.

Deux nuances, pour ne pas en faire un conte. D’abord, l’IA a co-signé le faux espoir : elle avait la même fausse conclusion que moi le premier soir, parce qu’on avait les mêmes données incomplètes. Elle lit vite, elle ne mesure pas à ma place. Ensuite, elle a trouvé une erreur dans le manuel lui-même (la veille qui met le courant à zéro alors que la doc dit le contraire) uniquement parce qu’on a mesuré le contraire ; sans l’ESP32 branché, elle aurait défendu la doc.

Mais le déplacement est réel, et il me semble important pour la réparation en général : un savoir qui était enfermé dans un manuel de 250 pages, donc réservé aux professionnels, devient accessible à quelqu’un qui sait tenir un fer à souder et poser une question. Les fabricants comptent, sans le dire, sur le fait que personne ne lira le manuel. Cette hypothèse vient de tomber.

Focus : le bq40z50, la puce qui gère votre batterie

Puisqu’on a passé deux jours avec elle, présentons-la. Le bq40z50-R2 est ce que Texas Instruments appelle un battery pack manager : une seule puce, de la taille d’un ongle (boîtier QFN de 32 broches, les contacts sont sous le boîtier), qui fait tout ce qu’un pack lithium de 1 à 4 cellules en série a besoin de faire. On la trouve dans une grande partie des batteries d’ordinateurs portables des dix dernières années, dans des outils électroportatifs, des robots, des drones, des batteries médicales.

Ce qu’elle fait

• Jauger : elle mesure le courant à travers une résistance de mesure (un shunt, quelques milliohms) et la tension de chaque cellule, et en déduit l’état de charge par un algorithme maison, Impedance Track : au lieu de simplement compter ce qui entre et sort (ce qui dérive avec le temps), elle apprend la capacité chimique réelle des cellules (Qmax) et leur résistance interne à chaque cycle, et corrige en permanence. C’est ce qui donne les pourcentages précis des portables récents.
• Protéger : elle intègre l’AFE (analog front-end : la partie analogique qui surveille les tensions et les courants en temps réel, indépendamment du logiciel) et pilote directement les transistors de charge et de décharge. Surtension et sous-tension par cellule, surintensité en charge et en décharge, court-circuit, surchauffe et sous-température, chacune avec ses seuils, ses délais et ses conditions de retour à la normale.
• Se condamner : une seconde famille de protections, les défauts permanents (PF), coupe définitivement le pack — au besoin en faisant fondre un fusible chimique irréversible — en cas de cellule ouverte, de déséquilibre incorrigible, de transistor grillé ou de trop de surtensions répétées.
• Équilibrer : pendant la charge, elle décharge légèrement les cellules en avance pour que toutes arrivent pleines ensemble.
• Se souvenir : compteur de cycles, températures et tensions extrêmes vues au cours de sa vie (lifetime data), et une boîte noire qui enregistre les derniers événements de sécurité avant un défaut permanent — de quoi faire l’autopsie d’un pack mort.
• Parler : SMBus, tout le standard SBS, plus les commandes du fabricant. Et s’authentifier : un mécanisme cryptographique (SHA-1 avec une clé secrète) permet à l’appareil de vérifier que le pack est d’origine. C’est ce qui bloque les batteries compatibles sur certains appareils.

Ses points forts

• Complète et documentée. Tout est dans un seul boîtier, et le manuel décrit tout : c’est ce qui a rendu cette enquête possible. Beaucoup de puces concurrentes sont documentées sous accord de confidentialité, ou pas du tout.
• Précise. Impedance Track reste la référence en jauge grand public ; l’erreur d’estimation descend à 1 % sur un pack bien configuré.
• Sûre par construction. L’AFE protège même si le logiciel plante ; les défauts permanents ne se négocient pas.
• Ubiquitaire. Des dizaines de millions d’exemplaires dans des packs de portables : les cartes, les fichiers de configuration et les retours d’expérience abondent.
• Ouvrable. Le logiciel officiel bqStudio et l’adaptateur EV2400 existent, mais comme on l’a vu, un microcontrôleur à deux euros suffit à lire, et souvent à écrire.

Ses points faibles

• Complexe à configurer. Plus de 400 paramètres en flash. Faire fonctionner correctement Impedance Track demande une « image de référence » (golden image) construite en laboratoire : identification de la chimie des cellules, calibration, cycle d’apprentissage complet. Un pack DIY mal configuré jauge mal, et l’apprentissage que nous avons choisi prend plusieurs cycles.
• La sécurité dépend du fabricant du pack. TI fournit les serrures ; c’est l’assembleur qui choisit de les fermer. Le pack Neato a été livré en Full Access. Une batterie de portable de marque, elle, est presque toujours scellée, et sans les clés on ne lit que les registres standards.
• La sécurité, à l’inverse, peut être un mur. L’authentification SHA-1 et le scellement sont précisément ce qui rend certains packs irréparables : un défaut permanent sur un pack scellé, c’est une poubelle, quel que soit l’état des cellules.
• Pas plus de 4 cellules en série. Pour un vélo électrique (10 à 13 cellules en série) il faut son grand frère bq40z80 (jusqu’à 7 en série) ou une autre architecture.
• Difficile à câbler soi-même. Le boîtier QFN se soude au four ou à l’air chaud, pas au fer ; les cartes de développement TI coûtent une centaine d’euros. En pratique, le DIY passe par des cartes récupérées.

Ce qu’on peut en faire, hors Neato

• Diagnostiquer une batterie de portable avant de la jeter. Un pack Dell, HP ou Lenovo « mort » contient très souvent un bq40z50 (ou un cousin : bq30z55, bq40z80) et six cellules dont trois vont bien. L’ESP32 et le sketch de ce billet lisent l’état de santé, le compteur, les défauts, et disent si ce sont les cellules ou la puce. Sur un pack scellé on lit moins, mais on lit.
• Réarmer un pack après recellage. Exactement ce billet : compteur, éventuellement défaut permanent (PFStatus se remet à zéro par commande, en Full Access ou avec la clé), puis cycle d’apprentissage.
• Construire une « batterie intelligente » pour ses propres projets. Une carte BMS de récupération avec son bq40z50, quatre cellules 18650 neuves, et l’on obtient un pack 14,4 V qui s’auto-protège, s’équilibre et annonce son pourcentage : pour un robot DIY, une radio de terrain, un onduleur de secours pour un serveur domestique, une lampe de chantier.
• Surveiller une batterie à distance. L’ESP32 a le Wi-Fi : le même sketch peut publier tension, courant, température et état de charge en MQTT (un protocole de messages léger, le standard de la domotique) vers Home Assistant ou une base de données. Un pack qui prévient avant de lâcher.
• Apprendre. Le bq40z50 est un cours complet de gestion de batterie lithium, avec un manuel gratuit et une puce qu’on trouve dans les poubelles. Tout ce que fait un BMS de voiture électrique, il le fait en petit, et il se laisse regarder faire.

Une réserve : tout ceci suppose un pack ouvert (non scellé) ou dont on a les clés. Les fabricants de portables scellent ; les fabricants de packs pour robots, outils et jouets, souvent, oublient. Vérifiez avant de vous lancer — c’est la première lecture, et elle ne coûte rien.

Ce que ça raconte

Je ne crois pas que quelqu’un, chez Neato ou chez son fournisseur de batteries, ait décidé que ce robot mourrait en 2026. Je crois pire : personne n’a décidé qu’il vivrait.

Regardez les couches.

Le cloud. Le robot a été conçu pour ne rien faire sans un serveur. Quand le serveur s’éteint, il ne reste que le bouton. Sur les D3 à D7, une communauté a réussi à brancher un ESP32 sur le port série de la carte mère et à rendre aux robots leur autonomie (vacuula/fang, OpenNeato). Sur les D8 à D10, ce port est verrouillé par mot de passe. Une génération plus tard, la porte a été fermée à clé. Pas pour la sécurité de l’utilisateur — pour rien, apparemment, sinon pour qu’il n’y touche pas.

La batterie authentifiée. Le robot vérifie l’identité du pack. Les forums sont pleins de D5 bloqués après qu’on y a inséré une batterie compatible. Le fabricant appelle ça de la sécurité ; c’est aussi, très concrètement, un péage sur la pièce d’usure numéro un.

Le compteur. 1547 cycles, et une application qui dit « à remplacer ». Non pas parce que la batterie serait hors d’usage — la jauge elle-même la donnait chargée à 97 %, et les cellules d’origine, mesurées depuis, rendent encore 73 à 77 % de leur capacité neuve — mais parce qu’un nombre a franchi un seuil que personne ne vous montre. Le robot a été mis à l’arrêt pour un quart d’autonomie en moins.

Et l’absence de chemin. Une puce parfaitement documentée, laissée en accès total, dont le compteur se remet à zéro en une commande. Aucun chemin, dans le produit, ne mène à cette commande. Le diagnostic livré à l’utilisateur est « batterie déchargée », qui est faux, et la solution proposée est « acheter », qui est chère.

L’obsolescence, ici, n’est pas une bombe à retardement programmée par un ingénieur cynique. C’est une somme de non-décisions : personne n’a budgété la fonction « réinitialiser la batterie », personne n’a écrit le message d’erreur honnête, personne n’a laissé un port ouvert. Chaque choix se justifie individuellement. Leur somme fabrique un déchet de 600 € avec une batterie chargée dedans.

La bonne nouvelle, c’est que les mêmes non-décisions laissent des failles. La puce n’a pas été verrouillée. Le fabricant du pack a laissé ses pastilles de test. TI publie son manuel. Et un microcontrôleur à deux euros, plus une IA qui accepte de lire 17 000 lignes de documentation sans se plaindre, suffisent à s’engouffrer dedans.

À partir du 18 février 2027, l’article 11 du règlement européen sur les batteries (extrait local) imposera que les batteries portables des appareils soient « readily removable and replaceable by the end-user ». C’est un progrès. Mais cette histoire montre que « remplaçable » ne suffit pas : ma batterie était remplaçable, et c’est précisément le remplacement qu’on me vendait comme seule issue. Ce qu’il faudrait exiger, c’est que les objets disent la vérité sur leur état, et qu’ils laissent un chemin pour le corriger. Un bouton « réinitialiser la batterie » dans une application, ça coûte une après-midi de développement. Le silence, lui, coûte une batterie à chaque client.

Pour reproduire

Matériel : un ESP32-C3 Super Mini (ou n’importe quel ESP32/Arduino avec I²C), trois fils, un fer à souder, éventuellement deux résistances de 4,7 kΩ. Le pack doit être ouvert au niveau de sa carte électronique — la gaine est collée, un cutter la fend sans forcer.

Sécurité : les cellules restent connectées pendant toute l’opération. Pas d’outil métallique près des pastilles C+ et C−, qui portent 16 V et plusieurs dizaines d’ampères de court-circuit possible. Pas de bracelet, pas de bague. Les pastilles DA et CL, elles, sont à 3,3 V et ne risquent rien.

L’autre face de la carte : on n’y touche pas, mais elle montre que le fabricant a prévu bien plus de points de test que les deux qui nous intéressent.

Câblage :

Logiciel : bq40z50-reader.cpp et platformio.ini (PlatformIO est l’outil qui compile et téléverse le programme ; cadre Arduino, cible esp32-c3-devkitm-1). Moniteur série à 115200 bauds. Les registres essentiels, à l’adresse SMBus 0x0B :

Dans l’ordre : (1) brancher, lire, vérifier que DeviceType répond 0x4500 et que le niveau de sécurité est Full Access — sinon il faudra les clés du fabricant, et ce billet ne les a pas ; (2) sauvegarder la flash (le sketch le fait au démarrage) et mettre le fichier à l’abri ; (3) lire PFStatus et SafetyStatus — un défaut permanent est une autre histoire ; (4) lire les données de vie (0x4380…) et les comparer à la sauvegarde après quelques jours dans le robot : un compteur COV ou CUV qui grimpe désigne une cellule, pas un compteur ; (5) seulement alors, taper c — et attendre plusieurs jours avant de conclure.

Trois règles, si vous vous y mettez : lire d’abord, tout sauvegarder ensuite, n’écrire qu’en dernier. Une jauge en Full Access se laisse aussi bien réparer que détruire.

Questions fréquentes

Que signifie l’erreur 4202 sur un Neato ?

C’est l’erreur « batterie déchargée » des D8, D9, D10 et D800. L’application (quand elle fonctionnait) précisait que le compteur de charge de la batterie était dépassé et qu’il fallait la remplacer. Elle apparaît même avec des cellules en parfait état : ce qui la déclenche, c’est ce que la puce du pack raconte au robot — en particulier, d’après ce que nous avons observé, un compteur de cycles trop élevé.

Changer les cellules du pack règle-t-il l’erreur 4202 ?

Pas à lui seul. Le compteur de cycles et l’état de santé vivent dans la puce bq40z50 du pack, pas dans les cellules. Après recellage, l’erreur persistait chez moi avec des cellules à 4,1 V.

Faut-il un EV2300/EV2400 et bqStudio pour parler à la jauge ?

Non. Un ESP32 (ou un Arduino) avec deux broches I²C, trois fils et le manuel TI suffisent : la puce est documentée, et sur les packs Neato que j’ai vus elle est laissée en Full Access, sans mot de passe. bqStudio est plus confortable, pas nécessaire.

Une batterie compatible du commerce résout-elle le problème ?

Parfois, et parfois le robot la refuse — les forums documentent des D5 bloqués après l’insertion d’un pack compatible. Avant d’acheter, il coûte une soirée de vérifier que la batterie d’origine n’est pas simplement passée un seuil de cycles.

Est-ce dangereux ?

Les lignes DA et CL sont à 3,3 V et sans risque. Le danger est ailleurs : les pastilles C+/C− et B+/B− à 16 V, capables de dizaines d’ampères en court-circuit. Un seul outil métallique à la fois, pas de bijoux, et on ne touche à rien d’autre que DA, CL et le moins.

Pourquoi la jauge annonce-t-elle 0 mA de courant de charge ?

Parce qu’elle dort. Dès que le courant passe sous 10 mA pendant une trentaine de secondes, elle entre en veille et met ChargingCurrent et ChargingVoltage à zéro. Dans le robot, qui consomme en permanence, elle reste éveillée. Ce n’est pas une panne, et un redémarrage ne « répare » rien : il la réveille trente secondes.

Est-ce que ça marche sur un D3, D4, D5, D6 ou D7 ?

Les packs de ces générations utilisent une puce différente, verrouillée, et les recherches communautaires n’ont pas abouti. En revanche, leur port série est ouvert, et vacuula/fang ou OpenNeato rendent à ces robots leur autonomie sans le cloud.

Peut-on réutiliser la puce bq40z50 d’une vieille batterie dans un autre projet ?

Oui, si le pack n’est pas scellé ou si l’on a ses clés. Une carte BMS de récupération avec ses cellules remplacées fait une batterie intelligente 1S à 4S pour un robot, une radio ou un onduleur DIY ; un ESP32 branché dessus peut publier son état en MQTT vers la domotique. Voir la section « Focus : le bq40z50 ».

Qu’a fait l’IA exactement, et qu’a fait l’humain ?

Claude a lu le manuel de 250 pages, écrit le programme de lecture, décodé les registres, proposé le redémarrage puis l’expérience de comparaison qui a révélé le mode veille, et rédigé ce billet avec moi. J’ai soudé, mesuré, photographié, décidé de ne pas toucher à Qmax, et laissé le robot passer une nuit sur sa base — ce qui a démenti la première conclusion, la sienne comme la mienne.

Le robot est-il réparé ?

Pas encore de façon certaine. La remise à zéro du compteur (30 août) lui a rendu une journée, puis l’erreur 4202 est revenue : la cause réelle était une cellule de récupération plus faible qui déclenchait la protection de surtension à chaque charge. Correctif appliqué le 1er septembre (tension de charge 4100 mV par cellule, réapprentissage de la jauge), en observation. Toujours aucune pièce achetée. Voir Où on en est.

Petit glossaire

• Cellule : l’accumulateur élémentaire, ici au format 18650 (18 mm × 65 mm). Un pack en assemble plusieurs.
• BMS (battery management system) : la carte électronique du pack, qui protège, équilibre et jauge les cellules. Ici, elle est construite autour du bq40z50.
• Jauge (gas gauge) : la puce qui compte ce qui entre et sort de la batterie et en déduit l’état de charge.
• Puce / circuit intégré : un ordinateur ou un circuit complet gravé sur quelques millimètres de silicium.
• Microcontrôleur : un petit ordinateur complet sur une puce, programmable ; l’ESP32-C3 en est un.
• Bus série / SMBus / I²C : deux fils (données et horloge) sur lesquels des puces échangent des messages numériques ; SMBus est la variante utilisée par les batteries.
• Adresse, registre, commande : le numéro d’une puce sur le bus, une case de mémoire qu’on peut lire, le numéro qui la désigne. 0x… : nombre écrit en hexadécimal.
• Bit, octet : la case élémentaire (0 ou 1) et le groupe de huit ; un drapeau est un bit qui signale un état.
• Firmware : le programme gravé dans un appareil. Flash : la mémoire qui survit à l’extinction ; mémoire vive : celle de travail, effacée au redémarrage.
• Cycle : une décharge cumulée équivalant à 90 % de la capacité (seuil réglable). Le compteur ne fait qu’additionner.
• RSOC : état de charge relatif, le « pourcentage de batterie » ; FCC : capacité à pleine charge, telle que la jauge l’estime ; Qmax : capacité chimique apprise des cellules ; mAh : milliampère-heure, unité de quantité d’énergie stockée.
• Résistance interne : la « friction » électrique d’une cellule, en milliohms (mΩ). Plus elle est haute, plus la tension chute sous charge et plus la cellule chauffe ; elle monte avec l’âge et trahit une cellule fatiguée avant que sa capacité ne s’effondre.
• FET / transistor : interrupteur électronique par lequel la jauge autorise ou coupe la charge et la décharge.
• Pull-up : résistance qui maintient une ligne de bus à 3,3 V quand personne ne parle.
• PF (Permanent Failure) : un défaut que la jauge juge irrécupérable ; elle se condamne et rien ne l’efface. Il n’y en avait pas.
• COV / CUV (Cell Over-/Under-Voltage) : protections de surtension et de sous-tension par cellule. La jauge coupe la charge (COV) ou la décharge (CUV), rouvre quand la tension revient dans la plage, et compte chaque déclenchement dans ses données de vie.
• Impedance Track : l’algorithme de TI qui apprend la capacité et la résistance des cellules pour jauger précisément.
• Full Access / Unsealed / Sealed : les trois niveaux d’accès à la puce, du plus ouvert au plus fermé.

Références et copies locales

Pour que ce billet reste utile quand les liens auront disparu, les documents cités sont hébergés ici, avec leur source d’origine.

• TI bq40z50-R2 Technical Reference Manual, SLUUBK0B (juin 2017, rév. octobre 2018) — source · copie locale (PDF, 1,6 Mo).
• Carte de la data-flash du pack Neato, décodée — bq40z50-df-map-neato.md · sauvegarde brute du 29 août 2026 — bq40z50-df-backup-neato-blueway-20260829.txt.
• Le sketch et sa configuration — bq40z50-reader.cpp · platformio.ini.
• Neato Robotics, « Announcement – 6th Oct 2025 » (fin des services cloud) — source · copie texte.
• Règlement (UE) 2023/1542 sur les batteries, article 11 (applicable au 18 février 2027) — source EUR-Lex · extrait local.
• vacuula/fang (firmware ESP32 libérant les Neato D3–D7 du cloud) — source · README du 30 août 2026.
• renjfk/OpenNeato — source · README du 30 août 2026.
• Fil laptopu.ro sur les puces des packs Neato (accès Full Access via bqStudio) — source (pas de copie : le site refuse l’archivage).

Photos et mesures : les miennes. Lecture du manuel, code et rédaction : avec Claude. Ce billet est aussi disponible en Markdown brut.

Le premier billet racontait la construction de l’outil et se terminait sur son enseignement le plus inconfortable : le modèle ne prévoit pas ce que l’incendie va faire, il prévoit ce qu’il ferait si personne ne s’y opposait. L’écart entre les deux — un facteur 1,7 le jour où le feu courait librement, un facteur 12 le jour où les secours tenaient le front — c’est la lutte, et le modèle ne la représentait pas du tout.

Ce billet raconte quatre choses : ce que le feu a fait depuis, ce que le modèle a appris en essayant de représenter les secours, ce que la lutte réelle doit à une armée que personne ne budgète — les habitants et les agriculteurs —, et ce que ce modèle permet de dire — prudemment — sur une question politique qu’on m’a posée : si le programme de l’Avenir en commun avait été appliqué depuis deux mandats, qu’est-ce que ça aurait changé sur un épisode comme celui-là ?

Comment on note un modèle sur le passé — trois termes qui reviendront tout du long. Le rejeu rétrospectif : on se replace à un instant passé, on ne donne au modèle que ce qui était connu à ce moment-là, on simule vers l’avant, et on compare au réel. Le biais de surface : le rapport entre la surface prédite et la surface observée — un biais de 7,5 veut dire que le modèle fait brûler sept fois et demie trop. L’AUC : tirez au hasard une cellule qui a brûlé et une qui n’a pas brûlé ; l’AUC est la probabilité que le modèle ait donné un score plus élevé à la première. À 0,95, il se trompe rarement sur le où — même quand il se trompe lourdement sur le combien.

Six jours, quarante-cinq mille hectares

D’abord les faits, parce qu’ils donnent l’échelle. Le feu principal n’est pas parti de Biscarrosse : il est parti le 22 juillet à Saumos, en Gironde, d’un chantier de débroussaillage — 1 400 hectares le soir même. Celui de Biscarrosse, une camionnette en feu, a suivi le lendemain. À partir de là, les journées se comptent en dizaines de milliers d’hectares :

• 24 juillet — 19 000 ha en Gironde, 110 000 personnes évacuées, dont la presqu’île du Cap Ferret par la terre et par la mer ;
• 25 juillet — plus de 32 000 ha, 167 000 évacués, premier largage de retardant — un produit qui ne s’évapore pas comme l’eau mais tapisse la végétation pour la rendre ininflammable — par un A400M de l’armée de l’air ;
• 26 juillet — 42 000 ha, cinq communes aux portes de Bordeaux évacuées par FR-Alert : environ 220 000 personnes déplacées au total, une des plus grandes évacuations françaises en temps de paix ;
• 27-28 juillet — accalmie, pare-feux élargis au bulldozer, feu « contenu mais pas fixé », puis « stabilisé »… et une nouvelle vague de chaleur annoncée par Météo-France.

Cliquez sur les figures pour les ouvrir en grand.

Au dernier bilan que j’ai pu sourcer : 42 000 ha en Gironde, 3 500 dans les Landes, 88 sapeurs-pompiers blessés, plus de 2 750 pompiers et près de 3 000 gendarmes et militaires engagés, des renforts européens (Canadairs croates, Air Tractors portugais, hélicoptères lourds tchèque et slovaque), un drone Reaper pour la cartographie thermique. EDF a indiqué que le Blayais, à une cinquantaine de kilomètres des flammes, n’est pas menacé — la question qui avait lancé tout ce projet a donc, pour l’instant, une réponse rassurante. Le Laser Mégajoule du CEA, lui, a vu des pare-feux creusés en urgence autour de son site.

📡 Côté outil : la carte kokusho.ss2i.ca suit toujours les deux foyers. Ce matin, le modèle a fait passer la base aérienne de Cazaux en vigilance renforcée face au foyer secondaire — le front observé est à 7,3 km et un tiers des scénarios sans lutte atteignent la zone des 6 km sous 48 h. Précision d’honnêteté : aucune source de presse ne documente de menace sur Cazaux ; c’est une sortie de modèle, et une sortie contrefactuelle. C’est exactement la nuance que ce billet va passer son temps à faire.

Ce qui a marché dans le modèle

Depuis le premier billet, le modèle a passé deux épreuves et gagné un étage.

Première épreuve : l’hypothèse du manque de combustible. La sur-prédiction du 25 juillet (facteur 12) avait une explication concurrente de la lutte : le feu était peut-être simplement coincé entre l’océan, les étangs et sa propre cicatrice, sans plus rien à brûler. Le test est simple et je le recommande à tous les modélisateurs : regarder où le modèle fait brûler ses hectares excédentaires. Verdict sans appel — 94 % de la surface prédite tombe sur de la pinède intacte que le vrai feu n’a jamais touchée. Le combustible était là. Le feu ne l’a pas pris. Ce qui l’en a empêché, c’est bien la lutte, et il fallait la modéliser.

Deuxième épreuve : deux tentatives de modèle de lutte, deux échecs instructifs. La première tirait au sort, cellule par cellule, si les secours tenaient : il aurait fallu gagner 93 % des escarmouches, on en gagnait 15 %. La seconde tenait des tronçons de piste entiers — une trentaine de kilomètres tenus… que le feu contournait tranquillement. La leçon vaut la peine d’être écrite en gras : on ne contient pas un incendie en tenant beaucoup de ligne, on le contient en tenant une boucle fermée, ancrée sur des barrières que le feu ne franchit pas. Le confinement est un problème de topologie, pas de physique locale.

L’étage gagné : modéliser le raisonnement du commandant. Trouver la meilleure boucle fermée autour d’un feu, en s’appuyant au maximum sur l’eau, les zones déjà brûlées et les routes existantes, est un problème que les mathématiques savent résoudre exactement, et l’idée se raconte sans équation. Tout chemin qui mène du feu à l’extérieur doit traverser la ligne de défense — sinon la boucle n’est pas fermée, et le feu trouvera le trou. Chercher la meilleure boucle, c’est donc chercher l’ensemble de cellules le moins cher à tenir qui coupe tous les chemins : c’est ce qu’on appelle une coupe minimale. Un théorème classique — Ford et Fulkerson, 1956 — dit que cette coupe se calcule en résolvant un problème d’écoulement : imaginez qu’on essaie de pousser un fluide du feu vers l’extérieur, chaque cellule laissant passer un débit égal à son coût de défense ; le débit maximal qui parvient à s’écouler est exactement le prix de la meilleure barrière, et les cellules qui saturent sont la barrière. C’est ce que calcule l’algorithme de Dinitz, implémenté dans SciPy. L’eau est gratuite, une piste coûte moitié prix, la pinède ouverte coûte plein tarif — et chaque kilomètre est facturé selon la probabilité qu’une équipe puisse réellement le tenir, d’après les seuils opérationnels documentés : en dessous de 2 000 kW par mètre de front, l’attaque directe est possible ; au-delà de 10 000, rien ne tient, aérien compris.

Intensité de Byram (Byram, 1959) : la puissance dégagée par mètre linéaire de front, en kW/m — le produit du pouvoir calorifique du végétal, de la masse consumée par mètre carré et de la vitesse d’avancée du front. C’est la grandeur qui décide de tout : une pinède landaise qui court à 600 m/h dégage environ 6 000 kW/m — déjà hors de portée d’une attaque directe au sol. La hauteur des flammes s’en déduit presque directement (environ 4 m ici).

Deux détails de mise en œuvre, pour qui voudrait refaire le calcul. D’abord, les algorithmes de flot font porter les capacités par les liaisons entre cases, alors qu’ici c’est la case elle-même qu’on achète : on dédouble donc chaque case en une « entrée » et une « sortie » reliées par un arc interne au prix de la case — la technique dite du node splitting (Ahuja, Magnanti & Orlin, Network Flows, 1993, § 2.4). Ensuite, la coupe doit séparer les cases en comptant leurs huit voisines, diagonales comprises — le « voisinage de Moore » des automates cellulaires — parce que le feu se propage aussi en diagonale : une barrière qui ne bloque que les quatre voisines cardinales laisse le feu se faufiler entre deux cases posées en quinconce.

La boucle du commandant, en principe : chaque nature de terrain a son prix, et la coupe la moins chère qui ferme le tour est la stratégie.

La mise au point a été une leçon d’humilité par itérations, chacune payée d’un rejeu rétrospectif d’une vingtaine de minutes :

• sans prix de la surface concédée, la coupe « optimale » allait chercher les étangs à trente kilomètres et abandonnait 150 000 hectares — mathématiquement minimal, opérationnellement absurde ;
• une ligne tenue à 3 h du matin n’est pas tenue à 15 h : il a fallu ajouter le débordement, la ré-épreuve des lignes quand le front s’intensifie nettement — c’est le sursaut de mi-journée qui fait céder les lignes établies de nuit ;
• et les moyens sont finis : la défense est toujours tentée, mais les unités s’épuisent arc par arc, et les trous de financement deviennent les brèches par lesquelles les grands feux débordent.

Et la même boucle en vrai : le plan calculé par la coupe minimale sur le feu du 25 juillet, ancré sur l’océan, les étangs et la cicatrice. Chaque îlot orange à l’est ceinture un foyer secondaire repéré à l’écart du feu principal.

Le résultat, sur les deux journées de référence : le jour contenu, le biais tombe de 12 à 7,5 — mieux, pas bien ; le reste se partage entre les recoins de la cicatrice que le satellite n’a pas vus brûler, les sautes de feu que le modèle ne combat pas encore, et l’humidité des combustibles, toujours calculée par une formule instantanée sans mémoire (Simard, 1968) : elle ne regarde que la température et l’humidité de l’heure, si bien qu’un après-midi à 39,8 °C peut paraître plus humide que la veille. Le remède connu est l’indice forêt-météo canadien (Van Wagner, 1987) et ses composantes cumulatives DMC et DC — deux « réservoirs » qui se remplissent à chaque pluie et se vident jour après jour avec la chaleur, gardant ainsi la mémoire des semaines de sécheresse accumulée. C’est le prochain chantier. Le jour où le feu a échappé, en revanche, le modèle prédit désormais une surface moyenne à 14 % près de l’observé, en sachant pourquoi : les lignes tenues du matin cèdent au pic thermique. Dans les deux cas, l’AUC reste au-dessus de 0,95 — le modèle sait toujours où le feu va.

L’expérience qu’un modèle permet : faire varier les moyens

Et c’est ici que la modélisation devient un instrument politique — au sens noble. La v3 paramètre la lutte en « unités engagées », une unité tenant environ un kilomètre de ligne, l’effectif étant tiré au sort autour d’une moyenne calée sur les mobilisations réelles (2 000 à 2 750 pompiers sur les grands feux girondins de 2022 et 2026). Rien n’empêche alors de tourner le bouton : que se passe-t-il avec 30 % de moyens en moins ? Avec 50 % de plus ?

J’ai rejoué les deux journées de référence à trois niveaux d’engagement, vingt tirages chacun :

Rejeux rétrospectifs +12 h, 20 tirages par niveau d’engagement. « Médiane » : la moitié des tirages brûlent plus, l’autre moitié moins — plus robuste qu’une moyenne face aux tirages extrêmes. Observé : 1 645 ha le 25, 4 642 ha le 24. Ordres de grandeur d’un modèle expérimental, pas des prévisions.

Je m’attendais à une belle courbe décroissante — plus de moyens, moins d’hectares. Le modèle m’a répondu autre chose, et c’est le résultat le plus intéressant de la semaine : les moyens n’achètent pas des hectares, ils achètent une boucle. En dessous du seuil où la boucle cesse d’être finançable — ici, autour de −70 %, l’équivalent d’un dispositif dispersé sur trois mégafeux simultanés, ce qui est exactement la crainte des étés à venir — on perd des milliers d’hectares d’un coup. Au-dessus du seuil, le rendement marginal s’effondre : entre le nominal et +50 %, pas un hectare de différence. Et le 24 juillet, la colonne entière le dit : qu’on aligne 34 ou 168 unités, le feu passe — les lignes cèdent à l’intensité, pas au nombre.

La forme de la courbe est le résultat : un seuil, puis une saturation — et le 24 juillet, une courbe que les moyens ne font plus bouger.

Une réserve d’importance avant d’en tirer des conclusions politiques : ce tableau minore l’effet réel des moyens, parce que le modèle ne représente ni l’attaque des feux naissants — étouffer un départ dans la première heure, là où chaque Canadair disponible compte double — ni la rapidité des rotations aériennes, ni le partage du dispositif entre plusieurs feux. Ce qu’il établit, c’est la forme de la courbe : un seuil, puis une saturation. Pas l’inutilité des moyens.

L’autre armée : la logistique qui craque, et ceux qui la portent

Il y a une chose que ni le tableau ni la courbe ne montrent, et qui saute aux yeux dès qu’on lit les points de situation et la presse locale : la question n’était pas seulement combien d’unités, mais comment elles tenaient debout. La logistique — l’eau, les véhicules, les avions, le ravitaillement des hommes — a été le maillon faible de bout en bout, et elle craquait avant même l’épisode.

Les faits, datés. Pendant les feux, sept Canadairs sur douze étaient opérationnels, les autres immobilisés par la maintenance d’appareils trentenaires — et la commande de deux appareils supplémentaires avait été annulée en 2024, avant d’être repassée en juin 2026 pour livraison… en 2032. Le parc national de camions-citernes feux de forêts est passé de 5 117 en 2002 à 3 845 en 2020, avec un taux de vétusté monté de 51 à 61 % ; la fédération des sapeurs-pompiers estime qu’il en faudrait 10 000. Trois semaines avant l’épisode, le 6 juillet, un syndicat de pompiers professionnels alertait qu’il manquait plus de 300 véhicules pour couvrir les besoins d’une saison déjà à 7 000 départs de feux. Sur le terrain, un chef de bataillon demandait un camion de 13 000 litres pour « maintenir une permanence d’eau », les colonnes de renfort arrivaient d’Île-de-France, et un sapeur-pompier volontaire des Bouches-du-Rhône est mort sur la route — en mission de ravitaillement. Un adjudant-chef le dit sans détour dans la presse : « on n’a pas suffisamment de moyens, ni humains, ni matériels, pour répondre à des catastrophes d’une dimension si importante ». Ce ne sont pas des accidents : la Cour des comptes (2022) parlait de « défaut d’anticipation » sur la flotte aérienne, le Sénat (2022) de « sous-investissement chronique » dans les camions, et les fédérations de pompiers d’un « modèle à bout de souffle ». Quatre ans plus tard, l’épisode de 2026 s’est joué avec ces défaillances-là, connues, écrites, et non corrigées.

Et pourtant les lignes ont tenu les jours tenables. En partie parce qu’une seconde armée s’est levée, que personne ne budgète. Le 24 juillet à 7 h du matin, la préfecture des Landes lance officiellement « un appel à la solidarité auprès des agriculteurs pour apporter des tonnes à eau » — ces citernes de dizaines de milliers de litres qu’on remorque derrière un tracteur, et qui réalimentent les camions au plus près du front. En quelques heures, la chambre d’agriculture de la Gironde enregistre plus de 500 volontaires — vignerons du Médoc, négociants avec leurs camions-citernes, entreprises de travaux publics avec déchaumeurs, lames et bulldozers — dont une centaine interviendront effectivement sur le feu de Saumos, au point que l’appel est suspendu le 27, débordé par l’afflux. La filière bois a couché 22 kilomètres de pins en vingt-quatre heures pour ouvrir des pare-feux — 103 km de pare-feux et de pistes d’accès créés au total, dit le point préfectoral du 27. Derrière le front : des bénévoles qui tiennent les centres de ravitaillement des 2 750 pompiers, des restaurateurs qui préparent des milliers de repas, des vétérinaires qui soignent gratuitement les animaux évacués, le parc des expositions de Bordeaux-Lac ouvert pour 10 000 personnes. Rien de tout cela n’est improvisé de zéro : en 2022 déjà, à Landiras, les tonnes à lisier des agriculteurs avaient fait gagner « jusqu’à trois heures par jour » aux pompiers selon la chambre d’agriculture — et c’est précisément cette expérience que la Gironde avait commencé à formaliser, un mois avant l’épisode, en recensant le matériel agricole mobilisable.

Relisons cela avec les lunettes du modèle, parce que ça éclaire les deux. Le modèle compte des « unités qui tiennent un kilomètre » sans demander qui les arme : en réalité, une partie de ces unités-là étaient des tracteurs. La réalimentation en eau, les trois heures par jour de 2022, les pare-feux labourés — dans le vocabulaire du modèle, c’est de l’endurance : des arcs qui restent tenus au lieu de céder faute d’eau, des unités qui restent sur la ligne au lieu de faire la navette. Autrement dit, la marge sous le seuil, cette marge dont la courbe montre qu’elle décide de tout, a été en partie fournie par la société elle-même — au moment où l’État, qui avait sur son bureau depuis quatre ans les rapports chiffrant ce qui manquait, ne l’avait pas. Il faut dire les deux moitiés de cette phrase : l’entraide a été magnifique, et elle est le symptôme d’un manque. Une tonne à lisier ne remplace pas un Canadair en maintenance ; cinq cents volontaires en vingt-quatre heures ne se commandent pas, ne se planifient pas, et se suspendent quand l’afflux déborde la coordination ; et un système qui a structurellement besoin des tracteurs de ses voisins pour tenir ses lignes n’est pas un système dimensionné — c’est exactement ce que le rapport parlementaire sur la « valeur du sauvé », présenté dix jours avant l’épisode, essayait de dire en langage budgétaire.

Et si l’Avenir en commun avait été appliqué depuis deux mandats ?

Venons-y. La question m’a été posée ainsi : les mesures proposées par La France insoumise, appliquées depuis 2017, auraient-elles changé quelque chose à un épisode comme celui-ci ? L’exercice est un contrefactuel : il ne se vérifie pas, il s’argumente. Je vais donc commencer par ce que le programme contient vraiment, parce que la première surprise est là.

Ce que le programme contient — et ne contient pas. J’ai cherché. Ni l’édition 2017 ni l’édition 2022 de l’Avenir en commun ne comportent de chapitre sécurité civile. Pas de nombre de sapeurs-pompiers à recruter, pas de budget SDIS, pas de nombre de Canadairs. Les mesures qui touchent notre sujet sont ailleurs :

• la section 27 (« Défendre la forêt ») : renforcer les moyens et les effectifs de l’ONF, interdire les coupes rases — l’abattage d’une parcelle entière d’un seul coup —, promouvoir des forêts diversifiées en essences et en âges contre les monocultures, et « renforcer les moyens de prévention et de lutte contre les incendies » — formulation sans chiffre ;
• le livret thématique Forêt : doublement des effectifs de l’ONF (environ 8 400 agents aujourd’hui, 16 000 au milieu des années 1980), acquisition publique de 100 000 ha, moyens anti-incendie jugés « notoirement insuffisants » ;
• la section 79 : une force méditerranéenne d’intervention et de sécurité civile contre les incendies — la mesure la plus directement « feu » du programme ;
• la section 68 : une conscription citoyenne de neuf mois incluant des missions de sécurité civile, et une garde nationale sous commandement civil.

Au Parlement, en revanche, les chiffres existent. J’ai dépouillé les archives des deux dernières législatures (2022-2026), et le tableau est plus précis — et plus modeste — que ne le laisserait croire un slogan dans un sens ou dans l’autre :

Amendements et questions du groupe LFI, XVIᵉ et XVIIᵉ législatures. Liens en fin d’article. Le chiffre de 220 000 pompiers volontaires en 2027 qu’on croise parfois est un objectif gouvernemental, que LFI a soutenu et interrogé — pas une proposition LFI.

Deux observations d’honnêteté sur ce tableau. La première : la formule « LFI proposait tant de pompiers et tant de Canadairs » serait trompeuse — les archives montrent des mécanismes de financement (75 M€ d’investissement, ~+10 % de ressources pérennes, la « valeur du sauvé » du rapport Maudet–Pantel présenté dix jours avant l’épisode) et l’exigence de tenir des objectifs gouvernementaux existants, pas de cibles d’effectifs ou de flotte propres. La seconde : tout a été rejeté, retiré ou laissé sans suite, les budgets passant ensuite par 49.3. Face à cela, le réel : les effectifs de l’ONF ont fondu de 40 % en vingt ans, la flotte française compte douze Canadairs de plus de trente ans, la Cour des comptes dénonçait dès juillet 2022 un « défaut d’anticipation » de leur renouvellement — et les deux appareils commandés en juin 2026 seront livrés en 2032.

Maintenant, faisons travailler le modèle. Dans kokusho, une politique publique ne peut agir que par trois canaux, et ils n’ont pas du tout le même poids :

Canal 1 — les unités disponibles. Plus de pompiers, plus d’engins, une flotte aérienne à seize appareils au lieu de douze : dans le modèle, c’est la moyenne d’engagement qui monte. Et là, le rapprochement des deux tableaux de ce billet est instructif : les propositions parlementaires réelles — +10 % de budget des SDIS, 75 M€ d’investissement — sont d’un ordre de grandeur qui, rapporté à ma courbe de sensibilité, tombe dans la zone de saturation. Sur une journée tenable, avec tout le dispositif national massé sur un seul feu, +10 % n’aurait pas changé la surface brûlée. Leur valeur est ailleurs, et elle est double : de la marge sous le seuil pour le jour où les moyens sont dispersés — trois départs simultanés, une flotte à moitié clouée au sol, des colonnes à huit heures de route — et du matériel qui part plus vite sur les feux naissants, le canal que mon modèle ne représente pas encore et où chaque appareil disponible compte double. C’est très exactement le terrain des seize Canadairs et des avions de complément à 30 M€ : pas gagner la bataille du 24 juillet, faire qu’elle n’ait pas lieu.

Canal 2 — la largeur des coupures. La DFCI — défense de la forêt contre l’incendie — c’est ce réseau de pistes sablonneuses, de pare-feux et de points d’eau qui quadrille le massif landais précisément pour offrir aux secours des lignes d’appui toutes prêtes. Entretenue, débroussaillée, élargie — du travail d’ONF et de collectivités financées — c’est, dans le modèle, des coupures plus larges, donc des probabilités de tenue plus hautes à intensité égale. C’est le canal des 40 % d’effectifs ONF perdus : l’entretien du réseau est précisément le travail qui a été déshabillé. Difficile à chiffrer, mais le mécanisme est le bon.

Canal 3 — le combustible lui-même. Et c’est le canal décisif, parce que c’est le seul qui agit sur l’intensité. Le massif landais est une monoculture de pin maritime d’un million d’hectares — notre carte de combustible est monochrome, et cette monochromie est une politique publique vieille de cent soixante-dix ans. Une forêt diversifiée en essences et en âges, morcelée de feuillus moins inflammables, c’est une intensité de front plus basse ; et l’intensité est la seule grandeur qui décide si une ligne est tenable. En dessous de 2 000 kW/m, tout le monde tient. Au-dessus de 10 000, personne. Les mesures lentes sont les seules qui déplacent les seuils. Mais soyons honnêtes sur l’horizon : deux mandats ne transforment pas une pinède industrielle — dix ans de diversification, ce sont des lisières, des parcelles-test, des interfaces mieux tenues. L’effet en 2026 aurait été marginal ; l’effet en 2046 serait structurel.

Et le 24 juillet ? C’est la question qui départage l’honnêteté d’un contrefactuel. Réponse du modèle : ce jour-là, rien de ce qui précède ne suffisait. Avec 50 % de moyens en plus, la surface simulée du 24 ne bouge pas d’un hectare : les lignes cèdent à l’intensité, pas au nombre. Quand le front dépasse 10 000 kW/m, l’arithmétique des moyens ne s’applique plus — on ne bulldoze pas face à une tempête de feu. La seule victoire possible le 24 était en amont : que le feu n’ait jamais atteint cette taille. Attaque des feux naissants dans la première heure — ce que la flotte aérienne vieillissante fait de moins en moins vite — et prévention pour que le départ de feu accidentel d’un chantier de débroussaillage ne trouve pas 40 °C, un vent d’est et une pinède continue. Autrement dit : sur les journées extrêmes, seule la politique d’avant l’incendie existe. Et les journées extrêmes sont précisément celles qui fabriquent les mégafeux.

Les limites de l’exercice, sans lesquelles il ne vaut rien : le programme lui-même ne chiffre ni pompiers ni avions, et les chiffres parlementaires réels (75 M€, +10 %) sont bien plus modestes que les ±50 % de mon tableau, qui restent une hypothèse de lecture ; le modèle est expérimental et son biais résiduel est documenté ; la canicule, le vent et un siècle et demi de monoculture ne se gouvernent pas en deux mandats ; et un contrefactuel ne se vérifie jamais. Ce que l’exercice établit est plus modeste et plus solide : par quels canaux une politique agit sur un mégafeu, et lesquels de ces canaux étaient saturés le 24 juillet.

Ce que j’en retiens

Le premier billet se terminait sur une leçon de modélisation : le modèle ne répondait pas à la question que je croyais lui poser. Celui-ci se termine sur la leçon symétrique, côté politique : « plus de moyens » n’est pas une réponse unique, parce que « le feu » n’est pas un problème unique. Il y a les journées tenables, où chaque unité supplémentaire achète des hectares — là, les Canadairs de 2032 commandés en 2026 sont un scandale d’arithmétique budgétaire. Et il y a les journées intenables, où la seule politique qui existe encore s’est jouée dix ans plus tôt, dans la composition de la forêt, l’entretien des coupures, et la vitesse d’attaque des feux naissants.

Un programme politique qui veut peser sur les mégafeux se juge donc à l’aune de ces deux régimes à la fois. Sur le premier, le programme donne la direction et c’est au Parlement qu’on trouve les chiffres : modestes — 75 millions, +10 % —, systématiquement rejetés ou passés sous 49.3, mais posés aux deux endroits que le modèle désigne comme les vrais leviers du régime tenable, le financement pérenne des SDIS et la flotte d’attaque initiale. Sur le second — la forêt, ses effectifs, sa diversité — l’Avenir en commun pose le problème à l’endroit où les seuils se déplacent. Et il faut inscrire au bilan ce que ni les programmes ni mon modèle ne comptent : la marge fournie par la société elle-même — les tonnes à eau des agriculteurs, les bénévoles des centres de ravitaillement — qui a tenu cette fois encore, et qu’aucun État sérieusement dimensionné ne devrait inscrire à son budget comme un acquis.

Il faut finir en le disant sans détour : ce qui vient de se passer n’est pas une anomalie, c’est un aperçu. Le rapport sénatorial de 2022 — celui-là même qui chiffrait le sous-investissement — l’écrivait noir sur blanc : d’ici 2050, les surfaces brûlées pourraient augmenter de 80 %, et près de la moitié des landes et forêts métropolitaines être exposées à un risque incendie élevé. Quatre ans après Landiras, la même forêt a rebrûlé — plus grand, plus vite, plus près de Bordeaux. Deux « feux du siècle » en quatre ans ne font pas une exception : ils font un régime. C’est le nouveau normal, et sa signature est précisément la plus inquiétante des deux colonnes de ma courbe : les journées intenables du type 24 juillet, celles où l’arithmétique des moyens ne s’applique plus, seront chaque été plus nombreuses.

Vous connaissez la scène : le chat au bord de la table, la patte sur le verre, les yeux plantés dans les vôtres — et il pousse. On rit du chat. On devrait regarder l’observateur : celui qui voit le verre glisser et ne bouge pas n’est pas un témoin, il est coauteur de la casse. Voilà quatre ans que ce verre glisse sous nos yeux à tous. Les rapports étaient sur la table — la Cour des comptes en 2022, le Sénat en 2022, les fédérations de pompiers année après année. Les amendements étaient déposés — 75 millions pour les camions en 2022, rejetés ; les crédits Canadair, rejetés puis passés sous 49.3 ; la commande d’appareils, annulée en 2024 pour être repassée en 2026, livraison 2032. Les suppressions de postes à l’ONF continuent en 2026, l’été même où la forêt brûle. À ce stade, le mot « défaillances » est trop doux : ce sont des choix, faits en connaissance de cause, par des gens qui avaient les chiffres. Et ce billet a passé assez de temps à mesurer pour gagner le droit de le dire : je ne serai pas l’observateur qui ne dit rien au chat.

Et ne me croyez pas sur parole : au cœur de l’épisode, le média indépendant Bon Pote a refait le compte, scrutin par scrutin, des votes de l’Assemblée sur la lutte anti-incendie. Le tableau est sans ambiguïté : deux blocs. D’un côté communistes, insoumis, écologistes et socialistes, qui votent les moyens et la prévention ; de l’autre, du parti présidentiel au Rassemblement national, qui votent l’inverse — la taxe de séjour pour les SDIS, rejetée deux fois ; la contribution des assureurs, rejetée quand l’amendement en attendait « au moins 800 millions d’euros » ; le programme de recrutement de pompiers professionnels, voté par la seule gauche avec LIOT ; et le décret signé Gabriel Attal en 2024 qui annule 50 millions de crédits de sécurité civile, emportant la commande de deux Canadairs. La seule unanimité du dossier : 3 millions pour la DFCI — on mesure l’ordre de grandeur des consensus. Et la mesure qui ressemble trait pour trait au canal combustible de mon modèle — des pare-feux de feuillus entre les parcelles de résineux, pour casser la continuité de la pinède — n’a été votée que par les insoumis, les socialistes et les écologistes. Les seuils dont parle ce billet ont une couleur politique au Parlement, et elle est vérifiable vote par vote.

Alors oui, ce billet prend parti. De tout ce que j’ai lu et recoupé, l’Avenir en commun est aujourd’hui le seul programme national qui réponde aux deux régimes à la fois — et les scrutins ci-dessus montrent que lorsque ces mesures arrivent en séance, c’est la gauche entière qui les vote : le combustible et la forêt — diversification des essences, fin des coupes rases, effectifs de l’ONF doublés, là où se déplacent les seuils qui décident qu’une ligne est tenable — et le dimensionnement de la sécurité civile — financement pérenne des SDIS par la « valeur du sauvé », flotte d’attaque initiale maintenant et pas en 2033. Qu’on ne me réponde pas que ses chiffres manquent : ils ont été déposés, amendement après amendement, sous les numéros que cite ce billet — et c’est ceux qui les ont rejetés qui doivent aujourd’hui des comptes. Le reste de l’offre politique, quand elle parle du feu, ne parle que d’avions — le régime tenable — et jamais du combustible — le régime qui tue. Or les Canadairs de 2033 ne changeront rien aux journées où rien ne vole, et ces journées-là sont celles qui font les mégafeux. Un programme qui ne parle pas de la forêt ne parle pas du problème. Les tracteurs des agriculteurs ont tenu la ligne cette fois. La prochaine fois — et le nouveau normal garantit qu’il y en aura une — j’aimerais que la République y soit avant eux.

Le feu, lui, n’attend pas la fin du débat : Météo-France annonce une nouvelle vague de chaleur. La carte continue de tourner.

🔥 Voir l’outil en ligne — kokusho.ss2i.ca

Expérimental, sans valeur officielle. En cas d’incendie, la seule source qui fait foi est la préfecture : landes.gouv.fr · gironde.gouv.fr.

Sources

• Chronologie et bilan : Wikipédia, Feux de forêt de 2026 en Gironde et dans les Landes ; communiqués préfecture de la Gironde et préfecture des Landes ; points de situation franceinfo (27 juillet) et France 2 (28 juillet).
• Blayais : Montel News, 27 juillet 2026. Sites stratégiques : armees.com.
• Programme : l’Avenir en commun, section 27 ; livret Forêt ; sections 68 et 79 sur laec.fr.
• Les votes de l’Assemblée, scrutin par scrutin : Bon Pote, « Quels partis politiques ont voté pour la lutte anti-incendie ? », Sophie Kloetzli, 27 juillet 2026 — taxe de séjour SDIS (scrutins 302 et 4074, XVIIᵉ lég.), contribution des assureurs (4076), recrutement de pompiers professionnels (133, XVIᵉ lég.), plan d’adaptation de la forêt (1509), pare-feux de feuillus entre résineux (1556), décret d’annulation de 50 M€ de crédits de sécurité civile (2024).
• Parlement et budget : amendements II-CF1334 (PLF 2023, 75 M€ SDIS), I-CF594 (PLF 2025, TSCA ≈ +10 % SDIS), I-3166 (PLF 2026, taxe de séjour), CL265 (LOPMI 2022, Canadairs 100 % UE), II-CF2221 (PLF 2026, avions de complément ≈ 30 M€) ; questions écrites n° 2391 (F. Chauche, volontaires) et n° 9156 (C. Lejeune, seize Canadairs) ; nosparlementaires.fr, « Canadair : ce que le Parlement a voté » ; La Gazette des communes, rapport « valeur du sauvé ».
• Contexte : Basta!, effectifs de l’ONF ; Cour des comptes, référé du 26 juillet 2022 ; L’Usine nouvelle, commande de Canadairs (juin 2026) ; Sénat, rapport n° 856 (2022).
• Logistique et entraide, épisode 2026 : sept Canadairs sur douze opérationnels (Le Monde, via Wikipédia) ; appel préfectoral aux tonnes à eau (Landes, 24 juillet, 7 h) ; Vitisphere : 100 agriculteurs intervenus, 500 volontaires, appel suspendu ; coordination par la chambre d’agriculture de la Gironde ; point préfectoral du 27 juillet : bilan, 103 km de pare-feux ; franceinfo : le ravitaillement tenu par des bénévoles ; franceinfo : « on n’a pas suffisamment de moyens » ; France 3 : « Je voulais être utile » ; Bordeaux Métropole : accueil à Bordeaux-Lac, collecte de dons ; CNEWS : un pompier volontaire mort en mission de ravitaillement ; SNSPP-PATS, 6 juillet 2026 : plus de 300 véhicules manquants ; reportage : « on court après le feu », le camion de 13 000 litres ; la colonne de renfort francilienne, les 22 km de pins coupés en 24 h.
• Le précédent de 2022 et les constats structurels : Réussir : les tonnes à lisier de Landiras (50 000 litres apportés) ; Réussir : plus de 100 tracteurs et tonnes recensés en Gironde (août 2022) ; Pleinchamp : « jusqu’à trois heures par jour » gagnées, et la formalisation de 2026 ; ministère de l’Agriculture, 2022 ; Europe 1 : la population ravitaille les pompiers (La Teste, 2022) ; parc de camions-citernes : 5 117 (2002) → 3 845 (2020), vétusté 61 %, objectif FNSPF de 10 000 (données DGSCGC citées en annexe budgétaire) ; Sénat, PLF 2023 : « sous-investissement chronique », et les pactes capacitaires ; FO-SIS : « un modèle de sécurité civile à bout de souffle ».
• Physique du feu : Byram G.M. (1959), « Combustion of forest fuels », dans K.P. Davis (dir.), Forest Fire: Control and Use, McGraw-Hill — l’intensité de front I = H·w·R et la relation de longueur de flamme L = 0,0775·I^(0,46) ; Rothermel R.C. (1972), A Mathematical Model for Predicting Fire Spread in Wildland Fuels, USDA Forest Service INT-115 — l’amortissement par l’humidité des combustibles fins ; Simard A.J. (1968), The Estimation of Moisture Content of Fine Fuels, Forest Fire Research Institute, Ottawa, FF-X-14 — la formule d’humidité instantanée utilisée (et critiquée) ici ; Van Wagner C.E. (1987), Development and Structure of the Canadian Forest Fire Weather Index System, Service canadien des forêts, rapport technique 35 — les indices à mémoire DMC/DC.
• Seuils opérationnels de tenue : Hirsch K.G. & Martell D.L. (1996), « A Review of Initial Attack Fire Crew Productivity and Effectiveness », International Journal of Wildland Fire 6(4) ; Alexander M.E. & Cruz M.G. (2019), « Fireline Intensity », dans Encyclopedia of Wildfires and Wildland-Urban Interface (WUI) Fires, Springer — attaque directe possible sous 2 000 kW/m, engins jusqu’à ~4 000, rien ne tient au-delà de 10 000 ; la règle « une coupure tient à partir de deux longueurs de flamme » est une règle de l’art d’aménagement DFCI, traitée ici en transition douce plutôt qu’en seuil net.
• Algorithmique du confinement : Ford L.R. & Fulkerson D.R. (1956), « Maximal Flow Through a Network », Canadian Journal of Mathematics 8 — le théorème coupe-min/flot-max ; scipy.sparse.csgraph.maximum_flow (algorithme de Dinitz) ; le passage des capacités de nœuds aux capacités d’arêtes (node splitting) est décrit dans Ahuja R.K., Magnanti T.L. & Orlin J.B. (1993), Network Flows, Prentice Hall, § 2.4 ; panorama des modèles de propagation (automates cellulaires compris) : Sullivan A.L. (2009), « Wildland surface fire spread modelling, 1990–2007 », IJWF 18, trois parties.
• Scores de validation : Brier G.W. (1950), « Verification of Forecasts Expressed in Terms of Probability », Monthly Weather Review 78 ; AUC calculée par la statistique de Mann-Whitney ; diagrammes de fiabilité et scores spatiaux (Sørensen-Dice, Jaccard) : Wilks D.S. (2019), Statistical Methods in the Atmospheric Sciences, 4ᵉ éd., Elsevier. La comparaison à la persistance comme référence nulle est la garde-fou classique de la prévision.
• Données du modèle : NASA FIRMS, détections actives VIIRS 375 m (Schroeder W. et al. (2014), Remote Sensing of Environment 143) ; Open-Meteo (modèles Météo-France, et altimétrie Copernicus DEM GLO-90) ; occupation du sol et voirie : © contributeurs OpenStreetMap (ODbL) via l’API Overpass. Charges de combustible et vitesses de base par classe : ordres de grandeur assumés, documentés dans le code, pas un inventaire mesuré.

Jeudi 23 juillet, un fourgon prend feu sur une départementale à Biscarrosse. À 15 h 45 les flammes passent au massif forestier, et en trois jours 30 000 personnes sont évacuées. Comme tout le monde, je suis ça sur des cartes de points rouges, et une question s’installe — le genre de question qu’on n’ose pas vraiment formuler tant qu’on ne sait pas y répondre : et si ça allait vers le Blayais ?

Le Blayais, c’est la centrale nucléaire posée sur la rive droite de la Gironde, à une cinquantaine de kilomètres au nord de Bordeaux. Une carte de points rouges ne répond pas à cette question. Elle montre où le feu est. Jamais où il va.

Entre les deux, il faut un modèle. J’ai voulu voir jusqu’où on pouvait en bricoler un honnête en deux jours. Le résultat existe, il tourne, et il est consultable ici :

👉 kokusho.ss2i.ca — la carte est publique et se met à jour à chaque nouveau calcul.

Outil expérimental, sans aucune valeur officielle. En cas d’incendie, la seule source qui fait foi est la préfecture.

Mais ce n’est pas la partie intéressante de l’histoire. La partie intéressante, c’est la liste de tout ce qu’il a eu faux — et surtout, par quoi chaque erreur s’est fait attraper.

La première décision est morale, pas technique

Un outil comme celui-là peut afficher deux choses très différentes. La première :

« Le feu atteindra la centrale dans 17 heures. »

C’est net. C’est actionnable. Et c’est une escroquerie. Pour écrire une phrase pareille, il faudrait connaître la position exacte du front, le vent des dix-sept prochaines heures, la sécheresse réelle des combustibles et l’efficacité des secours. Je ne connais aucun de ces quatre éléments. Personne ne les connaît.

La seconde ressemble plutôt à ça :

« Sur 200 scénarios simulés, 6 amènent le feu dans la zone élargie autour de la centrale, au plus tôt dans 29 heures. Le vent prévu est transversal à l’axe du site. Confiance faible : dernière détection satellite il y a 5 heures. »

C’est nettement moins satisfaisant à lire. C’est vrai.

Tout le reste découle de ce choix. L’outil ne trace jamais une trajectoire ; il dessine des enveloppes — le terme consacré pour ces contours qui délimitent la zone atteignable — à 6, 12, 24 et 48 heures, en trois niveaux de plausibilité décroissante : la zone atteinte dans plus d’un scénario sur deux, celle atteinte dans un sur dix, et l’enveloppe extrême qui n’est franchie que dans un scénario sur cent, celui où tout va de travers en même temps.

Et il refuse de résumer la situation en un chiffre unique. Il en donne trois, séparément : le niveau de menace, la confiance qu’on peut accorder à ce jugement, et la fraîcheur de la dernière observation. Parce qu’un « vert » calculé sur des données de quatre heures d’âge n’est pas une bonne nouvelle : c’est un trou d’information. Un satellite qui ne voit rien ne prouve pas que le feu s’est arrêté — il prouve qu’il ne voit rien.

Les briques, et ce qu’elles font vraiment

Cliquez sur les figures pour les ouvrir en grand.

Voir le feu : FIRMS et VIIRS. La NASA diffuse gratuitement, presque en temps réel, les détections thermiques de ses satellites — le service s’appelle FIRMS, et les capteurs que j’utilise, VIIRS, découpent le sol en pixels de 375 mètres. Je les préfère à MODIS, plus ancien et quatre fois plus grossier.

Il faut bien comprendre ce qu’est une détection FIRMS : un pixel dont la température de surface est anormale. Pas un contour d’incendie. Avec du retard, des trous quand aucun satellite ne passe, et rien du tout quand la fumée ou les nuages bouchent la vue. Cette nuance gouverne tout le reste de l’article.

Savoir ce qui le pousse : AROME, OSM, MNT. Trois ingrédients font avancer un feu. Le vent d’abord, qui pèse bien plus que le reste : je le prends dans AROME, le modèle à maille fine de Météo-France, et pas en un point unique mais échantillonné sur tout le domaine — un incendie de cette taille traverse plusieurs mailles, et le vent peut tourner localement. La végétation ensuite, tirée d’OpenStreetMap : une pinède sèche brûle, un étang non, une vigne à peine. Le relief enfin, via un modèle numérique de terrain — un fichier d’altitudes, tout simplement — parce qu’un feu monte une pente bien plus vite qu’il ne la descend.

Le faire avancer : l’automate cellulaire. Le cœur du calcul porte un nom savant pour une idée simple.

Automate cellulaire — on découpe l’espace en cellules régulières, ici des carrés de 150 mètres, et on donne une règle qui dit comment l’état d’une cellule dépend de ses voisines. On applique la règle partout, on avance d’un pas de temps, on recommence. Le Jeu de la vie de Conway en est l’exemple le plus connu.

Ma règle : une cellule en feu tente d’allumer ses huit voisines, d’autant plus vite que la végétation y est inflammable, que la pente y monte, et que le vent pousse dans cette direction. Le front prend spontanément une forme elliptique allongée sous le vent — ce que les pompiers observent sur le terrain, et que les modèles reproduisent depuis les années 1980.

Accepter qu’on ne sait pas : Monte-Carlo. C’est le point qui change tout.

Méthode de Monte-Carlo — plutôt que de calculer une seule fois avec les meilleures valeurs possibles, on refait le calcul des centaines de fois en tirant au sort, à chaque fois, les paramètres qu’on connaît mal. On regarde ensuite la distribution des résultats. Le nom vient du casino, et la méthode de la bombe atomique — Ulam et von Neumann, 1946.

Je lance donc 200 tirages. À chaque fois je perturbe ce qui est réellement incertain : l’erreur de prévision du vent — qui croît avec l’échéance et reste corrélée dans le temps, parce qu’une prévision fausse l’est durablement plutôt qu’une heure sur deux — l’erreur de mon propre modèle de vitesse, la sécheresse réelle des combustibles, et l’occurrence des sautes de feu, ces braises projetées en avant du front qui franchissent une route ou un coupe-feu.

Ce qu’on affiche ensuite n’est plus une prévision mais un décompte : cette cellule a brûlé dans 150 de mes 200 mondes possibles, celle-là dans 3. C’est la même logique que le cône d’incertitude des trajectoires de cyclone.

Une précision qui compte : ces fréquences ne sont pas des probabilités au sens actuariel. Ce sont des fréquences conditionnelles à mes hypothèses. Si mes hypothèses sont mauvaises, mes pourcentages le sont aussi. Gardez ça en tête — la suite de l’article ne parle pratiquement que de ça.

Premier résultat : un feu parfaitement immobile

Premier lancement sur les données réelles. Le rapport tombe : surface nouvelle brûlée au bout de 6 heures, 103,5 hectares. Au bout de 12 heures : 103,5 hectares. Au dixième d’hectare près.

Un feu qui ne gagne pas un mètre en six heures sous 17 km/h de vent, c’est faux. Et mes 200 tirages, censés explorer des mondes différents, donnaient tous rigoureusement le même résultat — ce qui est encore plus louche.

La cause tenait à un choix d’indice. Quand je calculais la vitesse de passage d’une cellule à sa voisine, je prenais la vitesse de la cellule source, celle qui brûle déjà. Or je marque toute la surface déjà parcourue comme « cicatrice », avec une vitesse de propagation quasi nulle — ce qui est correct : une zone déjà brûlée ne rebrûle pas facilement.

Sauf que le feu part forcément de la surface déjà brûlée. Toutes mes cellules sources étaient des cicatrices, donc incapables de transmettre quoi que ce soit. Le feu était prisonnier de son propre périmètre.

La correction tient en un mot : prendre la vitesse de la cellule cible, celle dont le combustible est sur le point d’être consommé. C’est d’ailleurs plus juste physiquement — un feu avance à la vitesse que lui permet ce qu’il attaque, pas ce qu’il a déjà brûlé. Bonus inattendu : ça corrige aussi la traversée des plans d’eau, qu’une cellule source combustible pouvait franchir.

Puis j’ai regardé la carte de plus près

L’outil tournait, les enveloppes s’étalaient joliment, les chiffres semblaient plausibles. Je les ai regardés un moment avant de faire ce que j’aurais dû faire d’emblée : ouvrir la carte d’entrée, celle que le modèle utilise, et la regarder vraiment.

Il y avait un problème. Le modèle faisait brûler la mer.

Et c’était vrai. Voici la carte de combustible — l’image qui dit à l’automate, pour chaque cellule, à quelle vitesse le feu peut y avancer. À gauche ce que voyait mon programme, à droite la réalité :

Toute la masse vert foncé à gauche, c’est l’Atlantique. Classé pinède.

La raison est presque amusante. OpenStreetMap ne cartographie pas l’océan comme une surface. Il n’existe aucun polygone « Atlantique » : les contributeurs ont tracé le trait de côte — dans le jargon OSM, un chemin étiqueté natural=coastline — c’est-à-dire une ligne, pas une surface. Ma requête, elle, cherchait des surfaces. Elle récupérait consciencieusement les lacs, les étangs et les rivières, tous des polygones, et le large ne correspondait à rien.

Or hors polygone reconnu, mon programme suppose de la pinède. C’était un choix délibéré : dans le massif landais le pin maritime domine, et se tromper du côté « ça brûle » biaise le modèle du côté prudent. Sauf qu’appliquer cette prudence à 40 % du domaine de calcul, ça ne s’appelle plus de la prudence. Sur cette carte, l’eau passe de 3,4 % à 40,7 % une fois corrigé : plus du tiers de ma zone de travail était de l’océan inflammable.

Ma première correction récupérait le trait de côte et découpait le domaine avec — parfait sur mon test isolé. En conditions réelles, échec : trois requêtes sur douze au serveur OpenStreetMap sont revenues en erreur, le trait s’est retrouvé troué, et un trait troué ne découpe rien. La mer est redevenue combustible.

La bonne solution était ailleurs, et elle exploite une convention d’OpenStreetMap : quand on trace une côte, la terre est toujours à gauche du sens de tracé. Il suffit donc, pour chaque cellule, de trouver le segment de côte le plus proche et de regarder de quel côté on tombe — un simple produit vectoriel. À gauche la terre, à droite la mer. Un trou dans la donnée ne coûte plus que la précision locale autour du trou.

Je n’ai su que ma première correction avait échoué que parce que j’avais pris soin de faire crier le programme. Quand il n’arrivait pas à reconstituer la mer, il écrivait noir sur blanc dans son rapport : « trait de côte présent mais impossible d’en déduire l’emprise de la mer : le large risque d’être traité en combustible ». Un modèle qui échoue en silence ment. Un modèle qui échoue bruyamment se laisse réparer.

La question qui fâche : est-ce que ça marche ?

À ce stade, l’outil produisait de jolies cartes. Une jolie carte n’a jamais rien prouvé.

Et j’avais sous la main de quoi le prendre en défaut : l’incendie durait depuis plusieurs jours, donc son propre passé était disponible. Plutôt que d’attendre de voir si les prochaines prévisions tombaient juste, autant rejouer celles qu’on aurait pu faire l’avant-veille et regarder ce qu’elles valaient. C’est une méthode connue, elle porte un nom : la rétro-prévision.

Rétro-prévision (ou hindcast) — on se replace à un instant du passé, on ne garde que les données disponibles à cette date, on simule vers l’avant, puis on compare à ce qui s’est réellement produit. C’est la façon standard d’évaluer un modèle de prévision quand on ne peut pas se permettre d’attendre.

Je me replace donc au 24 juillet au matin, je jette tout ce qui a été observé après, je simule douze heures, je compare à ce qui a réellement brûlé. Puis je recommence le 25. Deux exécutions, une poignée de minutes de calcul — et de très loin le meilleur rapport entre l’effort fourni et ce que ça m’a appris.

Le 24 au matin, quand le feu courait librement, le modèle sur-prédit d’un facteur 1,7. Pour un modèle de propagation, c’est honorable — on est dans le bon ordre de grandeur. Le 25, alors que les secours reprenaient le front en main : facteur 12,3.

Ce qui est intéressant, ce n’est pas que le modèle se trompe. C’est où passe la différence entre les deux journées. Le modèle n’est pas devenu mauvais du jour au lendemain : même code, même vent, même forêt. Ce qui a changé entre le 24 et le 25, ce sont les moyens de lutte.

Mon programme ne les voit pas. Il ne sait rien des effectifs engagés, ni des lignes d’appui — ces coupures que les pompiers ouvrent au bulldozer pour arrêter le front — ni des largages. Il calcule donc, sans que je l’aie décidé explicitement, un contrefactuel sans lutte : ce que ferait l’incendie si personne ne s’y opposait. Le 25, la physique seule donnait 22 758 hectares ; le feu n’en a parcouru que 1 645, parce que des gens l’en ont empêché.

Il y a une consolation dans ces chiffres, et elle est importante. Elle tient dans une mesure qui s’appelle l’AUC.

AUC, pour aire sous la courbe ROC — mesure la qualité d’un classement, indépendamment des valeurs absolues. Si je prends au hasard une cellule qui a brûlé et une qui n’a pas brûlé, l’AUC est la probabilité que le modèle ait mieux classé la première. 0,5 = tirage à pile ou face, 1 = classement parfait.

Mon AUC vaut 0,96 à 0,98 dans les deux cas — pendant que le biais de surface, lui, varie d’un facteur sept. Autrement dit : le modèle sait très bien où le feu va, et se trompe lourdement sur combien. C’est le meilleur mode d’échec possible, parce qu’une erreur d’échelle se calibre, alors qu’une erreur de direction condamne l’outil.

Ce qui m’amène à la décision la moins intuitive de tout ce bricolage. J’avais un facteur de calage tout prêt : ralentir la propagation de ce qu’il fallait pour retomber sur le 25 juillet. Je ne l’ai pas appliqué. Ce serait graver dans le modèle l’hypothèse « la lutte réussit toujours » — précisément celle à laquelle il ne faut pas se fier devant une centrale nucléaire. L’outil refuse d’ailleurs de lui-même de publier un facteur global quand ses cas de validation sont trop hétérogènes, et explique pourquoi plutôt que de moyenner deux régimes incomparables.

Ce qu’il ne fait pas — et c’est le plus grave

La pire limite n’est aucune de celles que je viens de raconter. Elle tient en un mot : le couplage est à sens unique. La météo pilote le feu ; le feu ne modifie jamais l’atmosphère.

Or un grand incendie fabrique sa propre météo. C’est la pyroconvection : la colonne d’air surchauffé qu’il envoie vers le ciel peut monter à plusieurs kilomètres et former un pyrocumulonimbus, un véritable nuage d’orage né du feu lui-même. Il produit de la foudre sèche qui allume des départs à des dizaines de kilomètres, et il peut s’effondrer d’un coup en rabattant au sol une rafale violente, dans une direction quelconque.

C’est exactement ce qui fait échapper les feux qu’on croyait tenus, et c’est indépendant du vent synoptique — le vent de grande échelle, celui que prévoit AROME. Donc invisible pour mon modèle. Un vrai couplage feu-atmosphère existe, il porte des noms comme Meso-NH/ForeFire ou WRF-SFIRE, et il demande des moyens de calcul de laboratoire. Hors de portée.

Le compromis : ne pas simuler le phénomène, mais en évaluer le potentiel. Il existe pour ça un indicateur, l’indice de Haines continu, qui combine l’instabilité de l’air en altitude et sa sécheresse — en somme, il dit si le ciel « fait cheminée » ce jour-là. Croisé avec la puissance radiative du feu, il me donne un score. Une fraction de mes 200 tirages, égale à ce score, bascule alors en régime pyroconvectif : direction bien plus incertaine, propagation majorée, sautes de feu plus nombreuses et plus lointaines. Ces tirages-là nourrissent naturellement l’enveloppe extrême.

Un potentiel élevé se lit donc « les enveloppes larges deviennent crédibles », jamais « il va se produire ceci ».

Autre angle mort, découvert en regardant arriver la canicule de cette semaine. Mon humidité des combustibles fins vient d’une formule classique de danger météorologique, celle de Simard, qui ne regarde que la température et l’humidité relative instantanées. Elle n’a aucune mémoire. Or trois jours à 38 °C assèchent la litière en profondeur et le sol avec. D’où ce résultat absurde : mon modèle affiche une humidité des combustibles qui remonte le jour où il fera 39,8 °C. Il sous-estime donc l’effet d’une canicule. Il faudrait des indices à mémoire, du type DMC et DC de l’indice forêt-météo canadien, qui cumulent le déficit hydrique sur des jours et des semaines. C’est le prochain chantier.

Alors, le Blayais ?

Cliquez pour agrandir — ou allez voir la version vivante sur kokusho.ss2i.ca.

La réponse est restée la même du premier au dernier calcul : front observé à 36 kilomètres, aucun des 200 scénarios n’approchant à moins de 10 kilomètres, vent poussant à l’opposé. La centrale n’a jamais été menacée. Et l’outil le dit avec ses motifs, pas avec un verdict.

Le site réellement exposé était ailleurs : la base aérienne de Cazaux, à 7 kilomètres du foyer de Biscarrosse, avec jusqu’à 6,7 % des scénarios atteignant sa zone élargie.

Et puis il y a eu ce dernier matin où Cazaux est brusquement passé en orange, avec 96,7 % des scénarios atteignant cette même zone. Spectaculaire. Et faux.

Le satellite n’avait rien vu depuis quinze heures. Mon programme s’était rabattu sur son hypothèse de repli : faute de savoir où se trouve le front actif, considérer que tout le périmètre parcouru est actif. L’incendie se propageait donc dans toutes les directions à la fois, et mes 96,7 % ne mesuraient plus une convergence vers Cazaux — ils mesuraient mon ignorance. La vitesse de rapprochement réellement observée, elle, était nulle.

Désormais, dans ce cas précis, le niveau retombe sur « incertitude élevée, aucun rapprochement observé » au lieu de crier au feu — sauf si un rapprochement est réellement mesuré, auquel cas l’alerte tient. C’est peut-être la correction dont je suis le plus content : elle empêche l’outil de transformer une absence d’information en alerte.

Ce que j’en retiens

Tout ça a été bricolé en deux jours, et le code, je ne l’ai pas tapé : je l’ai fait écrire par une IA. Même méthode que pour le convertible tchèque il y a trois semaines, mais cette fois sur un sujet où se tromper n’est pas anodin.

Ce qui ne se délègue pas, en revanche, c’est le reste : décider qu’on afficherait des enveloppes et jamais une trajectoire, choisir les sources, exiger que le modèle soit éprouvé sur le passé de l’incendie plutôt que sur des tests de laboratoire, et rouvrir la carte d’entrée quand un résultat sentait le faux. La machine écrit vite et bien. Elle ne sait pas ce qu’il faut vérifier.

Cinq erreurs de fond ont été trouvées dans le modèle. Ce qui m’a le plus surpris, c’est de regarder par quoi :

• le feu prisonnier de sa cicatrice : par un chiffre invraisemblable dans un rapport ;
• la rastérisation qui s’enlisait : par un calcul qui ne rendait plus la main ;
• la mer combustible : parce que j’ai fini par regarder la carte d’entrée, celle que personne ne pense à ouvrir ;
• la reconstruction du littoral qui ne tenait pas en réel : par un avertissement que j’avais pris la peine d’écrire pour ce cas précis ;
• la fausse alerte orange : en confrontant ce que disait la simulation à ce que disait l’observation.

Aucune n’a été trouvée par les tests automatiques. J’en ai soixante-quatre, et chacun de ces bugs a désormais le sien — ils empêcheront la régression. Mais aucun test ne pouvait deviner qu’OpenStreetMap ne cartographie pas l’océan. Les tests vérifient ce à quoi on a déjà pensé. Ils sont muets sur le reste.

Ce qui a marché, c’est le frottement avec le réel : les vraies données, la vraie carte, le vrai passé de l’incendie. La rétro-prévision m’a appris davantage en deux exécutions que deux jours de développement.

Et son enseignement principal n’était pas « le modèle se trompe de tant ». C’était : le modèle ne répond pas à la question que je croyais lui poser. Je lui demandais ce que cet incendie allait faire. Il me répondait ce qu’il ferait si personne ne s’y opposait.

C’est une information utile — c’est même exactement celle qu’il faut pour savoir de quoi un incendie est capable. Mais ce n’est pas celle qu’on croit lire sur une carte.

🔥 Voir l’outil en ligne — kokusho.ss2i.ca

Expérimental, sans valeur officielle. En cas d’incendie, la seule source qui fait foi est la préfecture : landes.gouv.fr · gironde.gouv.fr.

Il est 16 h, il fait 37,7 °C dehors au plus chaud de ces dernières vingt-quatre heures, et ma salle de bain affiche 30 °C. Pas la salle de bain après une douche : la salle de bain à vide, volets tirés, personne dedans. C’est ce que fait une canicule à une maison — elle la remplit lentement, degré par degré, par le toit, par les murs, par chaque vitre, et le soir venu la maison est devenue un radiateur qui vous restitue la journée pendant que vous essayez de dormir.

Contre ça, on ne peut pas grand-chose sur le moment. Mais la canicule a un défaut : la nuit. Vers 4 h du matin, l’air extérieur descend à 20 °C, parfois moins. Pendant quelques heures, il y a dehors un stock de fraîcheur gratuit, immense, renouvelé chaque nuit — et la seule question qui vaille est : comment le faire entrer ?

Une VMC de salle de bain comme cheval de trait

La maison avait déjà tout ce qu’il fallait, en fait. Il suffisait de le regarder autrement.

En bas, une amenée d’air frais, installée à l’origine pour nourrir le poêle à bois. En haut, à l’étage, la salle de bain — le point le plus chaud de la maison, physique élémentaire. Et entre les deux, une modeste VMC qui, depuis des années, ne s’occupe que d’humidité : elle s’allume quand la douche embue, s’éteint quand c’est sec.

Or si l’on fait tourner cet extracteur la nuit, quelque chose de plus intéressant se produit : il aspire l’air chaud accumulé en haut, le jette dehors, et la dépression tire l’air frais de la nuit par l’amenée d’air du bas. Toute la maison devient un circuit : l’air frais entre par le rez-de-chaussée, traverse, monte, ressort par le haut en emportant la chaleur de la journée. Le bénéfice n’est pas local à la salle de bain — c’est un tirage thermique à l’échelle de la maison, avec un ventilateur de quelques dizaines de watts comme seul moteur.

Les anglophones appellent ça du free cooling. J’aime bien la version française : la nuit travaille pour nous.

La règle, et les pièges qu’elle évite

Restait à écrire la règle de décision. Le petit ordinateur qui pilote la VMC interroge désormais la météo et n’allume l’extraction que si quatre conditions sont réunies en même temps :

1. le maximum extérieur des dernières 24 heures dépasse 22 °C — on est bien en saison chaude ;
2. la salle de bain dépasse 24 °C — il fait réellement chaud en haut ;
3. le salon dépasse 20 °C — la maison n’est pas déjà rafraîchie ;
4. l’air extérieur est au moins 3 °C plus frais que l’intérieur — sinon on brasserait pour rien.

La subtilité, c’est la première condition. On pourrait croire qu’il suffit de comparer dedans et dehors. Erreur — et une erreur qui coûterait cher en janvier : une maison chauffée au poêle à 24 °C par 5 °C dehors montre un écart de 19 °C, largement de quoi déclencher une règle naïve… qui jetterait alors la chaleur du bois par la fenêtre, en aspirant de l’air glacial par l’amenée d’air. Celle-là même qui nourrit le poêle. Le système se saboterait lui-même.

D’où le critère de saison : le max extérieur sur 24 h glissantes. Mes relevés de janvier plafonnent à 14,6 °C ; ceux de l’été ne descendent jamais sous 22 °C. Entre les deux, un fossé — le garde-fou est infranchissable par accident. Et surtout, il ne regarde pas la température de l’instant : une nuit à 13 °C après une journée à 32 °C est précisément le moment d’extraire, et un seuil instantané l’aurait interdit.

Ce que disent les chiffres

Avant de brancher quoi que ce soit, j’ai rejoué la règle sur les données réelles de la semaine écoulée — la maison enregistre tout depuis des années, autant que ça serve.

La semaine en une image : l’extérieur (bleu) respire de 20 à 38 °C, la salle de bain (rose) encaisse et s’installe autour de 28-30 °C. Et tout à droite, ce trait qui monte : la commande du ventilateur qui passe à ON — le système vient d’être armé, à quelques heures de sa première nuit.

Verdict : sur la semaine du 6 au 13 juillet, la règle aurait déclenché 48 heures d’extraction. Écart moyen entre dedans et dehors au moment des déclenchements : 4,9 °C. Créneaux : concentrés entre 1 h et 9 h du matin, jamais l’après-midi — la règle a d’elle-même trouvé le rythme des nuits.

Et le chiffre qui m’a le plus amusé : pendant cette même semaine de canicule, la VMC n’a pas tourné une seule minute. L’air était si sec (29 à 37 % d’humidité dans la salle de bain, pour un seuil de déclenchement à 60 %) que sa mission historique ne l’a jamais réveillée. Un moteur parfaitement fonctionnel, installé, câblé, alimenté — et 100 % dormant, pile pendant la semaine où il avait le plus à offrir. C’est exactement le genre de gisement que j’aime : zéro matériel à acheter, juste une règle à écrire.

Cette nuit est la première en conditions réelles. L’inconnue est franche : l’amenée d’air a été dimensionnée pour la combustion d’un poêle, pas pour ventiler une maison. Si sa section est trop juste, le ventilateur tirera surtout sur les défauts d’étanchéité et le débit réel sera décevant. C’est la courbe de demain matin qui tranchera — si la salle de bain décroche nettement par rapport aux nuits précédentes, c’est gagné.

Événements remarquables : −7 °C et +41,7 °C, la même année

Une maison qui enregistre tout accumule sa petite mythologie. Le tableau des records extérieurs de 2026, lui, se passe presque de commentaire :

• 6 janvier 2026 : −7,0 °C. La journée la plus froide jamais consignée par la station. Le poêle a tourné sans discontinuer, l’amenée d’air du bas aspirait du gel.
• 23 juin 2026 : 41,7 °C. La plus chaude — avant même l’été officiel. Trois heures d’affilée au-dessus de 41 °C.

Le matin du record : la plaine sous la neige, ciel limpide — le même ciel dégagé qui, six mois plus tard, laissera le soleil pousser le thermomètre à 41,7 °C.

48,7 degrés d’amplitude en moins de six mois, au même endroit, mesurés par la même chaîne de capteurs. La moyenne, elle, glisse sans bruit — et c’est bien le piège.

Ça m’a rappelé Mélenchon, lors de sa première campagne présidentielle, qui s’agaçait déjà du mot « réchauffement » : un mot trop doux, presque une promesse de printemps précoce, deux degrés de plus sur une moyenne, qui s’en apercevrait ? Et qui lui préférait, avec insistance, « dérèglement climatique ». La nuance n’est pas cosmétique, elle est toute la question : ce qui abîme les maisons, les récoltes et les gens, ce n’est pas la moyenne qui glisse — ce sont les extrêmes qui s’écartent dans les deux sens. Les gelées plus mordantes et les canicules plus précoces. Une machine climatique qui n’a pas simplement pris un degré : qui a perdu son thermostat.

Le 13 juillet au fil des années, depuis 1970 (agrégats Open-Meteo pour chez moi). La moyenne monte de +0,32 °C par décennie — 19,5 °C dans les premières années de la série, 21,5 °C sur les dix dernières. Deux degrés en un demi-siècle : c’est le « réchauffement », et sur ce graphe il a l’air inoffensif. Ce qui ne se voit qu’en plissant les yeux, c’est la courbe rose des maximales qui se déchaîne — les pointes récentes crèvent le plafond des années 70. Le dérèglement, c’est elle.

Mes deux records de 2026 tiennent la démonstration à eux seuls. Et c’est exactement pour ça qu’on outille une maison : on ne se prépare pas à une moyenne, on se prépare à des extrêmes — dans les deux sens.

Sous le capot, pour ceux qui voudraient le construire

Tout ce qui précède tient avec du matériel de fond de tiroir — c’est le point important, et la raison d’être de ce billet : n’importe qui peut monter ça un dimanche.

• Dans la salle de bain : un Raspberry Pi Zero W (~15 €), un capteur température/humidité DHT11 à 2 € sur un GPIO, et un émetteur radio 433 MHz à 2 € sur un autre.
• La VMC n’est pas modifiée d’un fil. Elle est branchée sur une prise télécommandée 433 MHz de supermarché (~10 €) : le Pi rejoue simplement les codes ON/OFF de la télécommande d’origine (bibliothèque rpi-rf, protocole 1, pulse 350 µs — les valeurs se capturent en écoutant la télécommande avec un récepteur à 1 €). Aucun câblage 230 V, réversible en trente secondes.
• Un petit serveur quelque part — ici un VPS à quelques euros, mais un NAS ou un second Pi feraient exactement pareil : une page PHP, une base SQLite, et c’est tout.

Les ouvriers de la maison. En haut, le vétéran : un Raspberry Pi Model B de 2012 — 14 ans de service, il pilote le chauffage du salon en Ruby. Au milieu, le Pi Zero de la salle de bain, qui vient d’apprendre le free cooling. En bas, leurs yeux : le DHT11, le capteur température/humidité à 2 € — le petit boîtier bleu strié que tout bricoleur a déjà croisé. (Photos : Gareth Halfacree CC BY-SA 2.0 ; Evan-Amos, domaine public ; Crackopl CC BY-SA 3.0.)

La chasse aux watts fait partie du jeu, pour des machines qui tournent 24 h/24. Le Pi Zero consomme ~0,6 W. Le vieux Model B en tire ~2,5 — la faute à ses régulateurs linéaires de 2012, qui brûlent l’excédent de tension en chaleur pure, et à sa puce USB/Ethernet alimentée en permanence. On ne peut rien à l’architecture, mais on peut tailler dans le gras logiciel : en fouillant le vétéran cette semaine, j’y ai trouvé un MySQL et un Apache de 2017 qui tournaient pour rien depuis neuf ans, une sortie HDMI active en NTSC sans écran au bout, un Bluetooth jamais appairé, et un démon qui attendait les raccourcis d’un clavier fantôme. Tout coupé : deux degrés de moins au processeur en pleine canicule, 38 Mo de RAM rendus, et surtout plus d’écritures inutiles sur la carte SD — c’est elle, la vraie mortelle. À l’échelle de la facture c’est anecdotique (2,5 W ≈ 22 kWh/an ≈ 5 €), mais un système qu’on veut voir durer dix ans se doit d’être maigre.

Les choix d’architecture sont tous dictés par la même obsession : survivre aux pannes, aux reboots de box et aux années.

• Pas de démon, un cron. Le contrôleur se lance toutes les 5 minutes, vit vingt secondes, mesure, décide, envoie son code radio, s’éteint. Un process qui ne tourne pas ne peut ni fuir ni se bloquer — le Pi en est à 267 jours d’uptime sans y penser.
• C’est toujours le Pi qui tire, jamais le serveur qui pousse. Le Pi retélécharge sa configuration (un YAML) chaque minute d’un simple curl, et interroge la météo au moment de décider. Derrière n’importe quelle box, NAT ou changement d’IP, ça fonctionne — et la case « Activer » cochée sur la page web est effective sur le terrain la minute suivante.
• La météo vient d’Open-Meteo (open-meteo.com) : API gratuite, sans clé, avec l’historique. Un cron horaire l’archive côté serveur, et le Pi reçoit un JSON minimal : température actuelle, max sur 24 h glissantes, température du salon. Ne servir que de l’observé — jamais la prévision — a son importance : la ligne de 23 h annonçait 24 °C pendant qu’il en faisait 35 dehors, et une règle nourrie de prévisions aurait aspiré l’air de la fournaise.
• Une table unique pour tout : observations (source, metric, value, unit, metadata). Capteurs, consignes, commandes, météo — tout entre dans le même moule. Ajouter un capteur, c’est ajouter une source, zéro migration. C’est cette table qui a permis de rejouer la règle sur les archives avant de la brancher.
• Échec fermé. Serveur injoignable ou météo vieille de plus de deux heures → le Pi retombe sur sa logique humidité d’origine. Pas de max 24 h → pas d’extraction (le garde-fou de saison ne se contourne pas par accident). Le pire scénario d’une panne, c’est le comportement d’avant.
• Les courbes de la page sont tracées par uPlot, une bibliothèque de ~50 Ko qui encaisse des dizaines de milliers de points sans broncher.

Et un mot sur ce qui, à mes yeux, n’est pas négociable : ces données ne quittent jamais mon périmètre. Ce que mesurent ces capteurs, c’est l’intérieur d’une maison — quand on s’y douche, quand on la chauffe, quand elle est vide. Les Pis poussent leurs relevés en SSH vers un serveur que j’administre, la page qui les affiche demande un mot de passe, et la boucle s’arrête là. Pas de cloud constructeur, pas de « skill » Alexa, pas de SaaS domotique qui ferme dans trois ans en emportant l’historique, pas un octet dans les analytics de qui que ce soit. La seule dépendance extérieure est dans l’autre sens : la maison télécharge la météo publique d’Open-Meteo, elle n’envoie rien. Le jour où le serveur change — un NAS, un autre VPS, une boîte à chaussures — on déplace un fichier SQLite et tout repart.

Budget total par pièce instrumentée : moins de 30 €. Le luxe n’est pas dans le matériel — il est dans les années de données qu’on accumule, qu’on peut interroger le jour où on a une idée, et qui n’appartiennent qu’à vous.

La suite : entrer dans l’épaisseur des choses

Jusqu’ici, tous mes capteurs mesurent des pièces. La prochaine étape est plus intime : entrer dans l’isolant.

Le projet : une tige plantée verticalement dans l’isolant des combles, avec quatre sondes de température étagées — surface, un tiers, deux tiers, fond contre le placo. Au-dessus, une cinquième sonde dans l’air sous tuiles, qui monte à 60-70 °C en ce moment. En dessous, le thermostat du salon, déjà en place. Une colonne de mesure complète, du soleil à la pièce à vivre.

Ce que ça racontera, jour après jour :

• Le déphasage réel : combien d’heures met le pic de chaleur sous tuiles à traverser l’isolant ? Le fabricant annonce une valeur théorique ; l’isolant tassé et vieilli en fait ce qu’il veut. Je veux le chiffre vrai, chez moi.
• L’amortissement : de combien l’amplitude jour/nuit est-elle écrasée entre la surface et le fond ?
• L’effet des cheminées de tirage que j’ai posées sur le toit pour évacuer la chaleur sous tuiles : à météo comparable, la surface de l’isolant doit être plus fraîche si le tirage fait son travail. Deux colonnes de sondes — une proche des cheminées, une éloignée — et la réponse tombera d’elle-même.
• Et à long terme, un détecteur de vieillissement : un déphasage qui raccourcit d’année en année, c’est un isolant qui se dégrade. Autant le savoir avant que la facture de chauffage ne le dise.

Côté matériel, rien d’héroïque : des sondes étanches à quelques euros sur un bus une-paire-de-fils, un microcontrôleur qui dort 99,9 % du temps sur deux accus de récupération — de quoi tenir environ deux ans sans changer les piles. L’électronique reste au frais en bas des combles ; seules les sondes montent au front.

Et l’hiver, on inverse tout

La canicule finira. Et la même tuyauterie intellectuelle resservira, retournée comme un gant.

Le prochain chantier qui me trotte dans la tête : des panneaux thermiques à air sur la façade extérieure — des capteurs solaires tout bêtes, une boîte noire vitrée dans laquelle l’air se réchauffe au soleil d’hiver. Même par 5 °C dehors, un panneau bien exposé sort de l’air à 30 ou 40 °C en milieu de journée. Branché sur l’amenée d’air de la maison, ça devient du préchauffage gratuit : au lieu d’aspirer de l’air à 5 °C pour alimenter le poêle et compenser l’extraction, on aspire de l’air déjà tiédi par le soleil.

Et la boucle se referme élégamment : c’est la même logique de décision que le free cooling, inversée. L’été, on extrait la nuit quand dehors \< dedans. L’hiver, on injectera le jour quand panneau > dedans. Les mêmes capteurs, la même météo, la même règle à quatre conditions avec ses garde-fous — seul le signe change. Les sondes dans l’isolant diront même si le préchauffage se voit dans le gradient des combles.

Une maison, au fond, c’est un système thermique qui s’ignore. La mienne commence tout juste à se connaître — et cette nuit, pour la première fois, elle va essayer de se rafraîchir toute seule pendant que je dors. Je vous raconte demain si elle a réussi.

Post-scriptum, au matin du 14 juillet

La première nuit a eu lieu. Le ventilateur a extrait pendant près de douze heures, de 19 h à 8 h, avec une pause d’une heure vers 1 h du matin — l’écart était retombé sous le seuil d’arrêt, la règle a fait exactement ce qu’on lui a appris.

Résultat brut : salle de bain de 31 °C au coucher à 26 °C au lever. La meilleure nuit de la semaine. Mais le chiffre qui me plaît est ailleurs. Les nuits précédentes, l’extérieur descendait à 23-24 °C et la salle de bain restait scotchée à 28 : quatre à cinq degrés d’écart au lever, la signature d’une maison qui n’échange rien avec la nuit. Cette fois, le contrôleur a maintenu l’écart entre 1,4 et 2,4 °C jusqu’au matin — l’intérieur a suivi l’extérieur dans sa descente, heure après heure. Le renouvellement d’air est bien là, et l’inconnue de l’amenée d’air est levée : elle débite.

Transparence de rigueur : les fenêtres étaient ouvertes cette nuit-là, canicule oblige — impossible de séparer leur part de celle du ventilateur. La nuit prochaine se fera fenêtres fermées, VMC seule. Si la salle de bain colle encore l’extérieur à deux degrés près au matin, la démonstration sera complète. La science domestique avance une nuit à la fois.

Épisode suivant : les courbes de la première nuit fenêtres fermées, et ce que 48 heures de tirage nocturne changent (ou pas) à une canicule.

Illustration : réinterprétation façon manga d’une photo du vendeur — l’original est sur justchairs.eu.

J’ai croisé en ligne un canapé convertible tchécoslovaque des années 70, signé OPP Drevovyroba, en vente chez un revendeur de Budapest. Ligne basse, accoudoirs sculpturaux en contreplaqué de teck cintré, et un mécanisme annoncé d’une phrase : « le canapé se transforme en lit d’un seul geste ». 1 550 €, à 1 500 km de chez moi, et des dimensions qui ne collent pas à mon salon. La conclusion s’imposait : plutôt que de l’acheter, le redessiner — et en profiter pour le comprendre.

Ce billet raconte l’exercice, mené avec une IA (Claude) qui pilote Blender en direct. Spoiler : l’IA s’est trompée trois fois sur le mécanisme, et c’est précisément ce qui rend l’histoire intéressante.

Le dispositif

Côté outillage, c’est devenu presque banal : Blender, un petit addon qui ouvre un serveur sur la machine (BlenderMCP), et l’IA qui s’y connecte. Dix minutes d’installation. À partir de là, elle écrit du Python dans Blender, construit de la géométrie, prend des captures du viewport pour vérifier son travail, et recommence. Moi, je regarde le modèle tourner en direct sur mon écran et je commente.

Le parti pris dès le départ : un modèle paramétrique. Pas de la sculpture à la souris, mais un script avec un bloc de paramètres en tête — largeur, hauteur d’assise, épaisseur des coussins, inclinaison du dossier — et toute la géométrie, mécanisme compris, qui se recalcule quand on change une valeur. On verra que ce choix a sauvé la mise plusieurs fois.

Trois théories pour un mécanisme

Le vendeur fournit une quinzaine de photos, aucune du mécanisme en action. Il a donc fallu déduire.

Théorie n° 1 : la charnière simple. Première interprétation de l’IA : le dossier bascule vers l’arrière sur une charnière, comme un clic-clac. Modélisé, animé… et démoli en regardant mieux les photos : en position lit, la bande avant du couchage est devant l’assise, pas derrière. Le dossier passe donc par-dessus l’assise. Exit la charnière.

Théorie n° 2 : la cinématique à quatre barres. Si le dossier doit survoler l’assise sans la percuter, me disais-je, il faut qu’il tourne et se translate — donc deux pivots et des biellettes. L’IA a pris l’idée au sérieux, très au sérieux même : elle a écrit un solveur qui place les pivots par recherche numérique le long des médiatrices des deux poses, en maximisant la garde entre dossier et assise pendant la bascule. Résultat : un mécanisme à quatre barres parfaitement fonctionnel, garde de 17 mm vérifiée sur toute la course. Élégant. Et complètement faux.

Théorie n° 3 : le pivot unique. C’est un gros plan sur l’accoudoir qui a tranché : les vis qui attachent le bras au dossier sont une fixation rigide, pas un pivot. Le bras et le dossier ne forment qu’une seule pièce mobile, qui tourne autour du tourillon rond visible sur le flanc du caisson. Un seul pivot par côté. Et là, tout s’éclaire : comme le pivot est bas et central, l’arc de rotation monte au-dessus de l’assise. Il n’y a jamais eu de problème de collision à résoudre. Les concepteurs tchèques n’avaient pas besoin de biellettes — ils avaient juste bien placé un axe.

La leçon vaut d’être encadrée : quand l’IA comprend mal le réel, elle ne se trompe pas timidement — elle sur-ingénie. Le mécanisme à quatre barres était la réponse brillante à un problème qui n’existait pas.

Le beau geste mathématique a survécu au naufrage de la théorie n° 2 : deux poses d’un solide dans le plan déterminent un centre de rotation unique — l’intersection des médiatrices. Plus besoin de recherche numérique : le pivot se calcule, exactement. Et quand on lui donne la bonne géométrie d’entrée, il tombe à quelques millimètres de l’emplacement du tourillon d’origine. Une jolie validation croisée, cinquante ans plus tard.

L’accoudoir qui devient pied

Autre trouvaille des photos en position lit : le dossier déborde de 46 cm en porte-à-faux devant le caisson, et c’est l’accoudoir qui le soutient — en basculant, la branche d’accoudoir pointe vers le sol et son extrémité s’y pose, jambe de force improvisée. Le petit plateau où on posait son coude devient un patin.

Dans le modèle paramétrique, on a inversé la logique : plutôt que de dessiner l’accoudoir puis constater où il atterrit, l’IA calcule ses points d’appui par rotation inverse depuis leur cible au sol. La pointe de l’accoudoir est définie comme « le point qui, après une rotation de 110°, touche le sol à y = -47 cm ». Vérification à la frame finale : z = 0,0 mm. Du coup on comprend aussi pourquoi l’accoudoir original est si court et placé en retrait : sa position n’est pas un choix esthétique, c’est la contrainte d’atterrissage. La forme suit le mécanisme.

Là où on dépasse l’original

Comprendre, c’est bien ; améliorer, c’est mieux. Trois défauts du meuble d’origine sont passés à la moulinette.

Le couchage à deux fermetés. Sur l’original, assise épaisse et dossier plus mince donnent un lit à deux zones. Correction : épaisseur commune de 14,5 cm partout, couchage de 126 × 200 cm parfaitement uniforme.

L’assise de 65 cm de profondeur. Impossible de s’adosser en gardant les pieds au sol. En regardant mieux, l’original triche déjà : son dossier n’est pas au bord arrière mais avancé sur la plateforme, et la zone morte derrière lui devient du couchage au dépliage. On a paramétré ça proprement : prof_utile = 50 cm, et le pivot se recalcule tout seul.

La face moelleuse du mauvais côté. Le vrai casse-tête. La bascule avant expose le dos du dossier comme surface de couchage : si la face avant est moelleuse pour s’asseoir, on dort sur la face ferme. L’original a tranché et tant pis pour l’assise. Notre solution : un axe central qui traverse le dossier en son milieu. Pendant la bascule, le dossier fait un demi-tour sur lui-même — et la même face moelleuse sert au dossier le jour et au couchage la nuit. Conséquence en cascade : le bras s’arrête désormais à mi-hauteur du dossier pour porter ce palier… pile à la hauteur de l’accoudoir. L’accoudoir est le palier.

Restait à empêcher le dossier de tournicoter librement. Première idée : une targette. Deuxième idée, bien meilleure : un téton courant dans une gorge semi-circulaire de 180°, concentrique à l’axe, fraisée dans la face intérieure du bras. Les extrémités de la gorge sont les butées des deux positions — la course de la gorge est la course du demi-tour. Zéro verrou à manipuler, indexation automatique, et dans les deux poses les charges plaquent le téton contre sa butée. Vérifié dans le modèle : le téton est exactement en bout de gorge aux deux positions.

Ce que j’en retiens

Une photo vaut mille tokens. Les trois corrections décisives sont venues de gros plans que j’ai envoyés à l’IA : les vis rigides, l’accoudoir-pied, le dossier avancé. Elle raisonne remarquablement bien — mais sur ce qu’on lui montre.

L’IA sur-ingénie quand elle comprend mal. Le solveur à quatre barres était magnifique et inutile. Méfiez-vous des solutions brillantes : vérifiez d’abord le problème.

Le paramétrique rend les erreurs bon marché. Trois refontes complètes du mécanisme, et à chaque fois quelques minutes de recalcul plutôt que des heures de remodelage. Les points d’ancrage (pivot, appuis au sol, palier) étant calculés et non posés à la main, tout suit.

La collaboration a un sens. Elle calcule des intersections de médiatrices et vérifie des gardes au millimètre ; je vois qu’un dossier de 65 cm de profondeur est invivable et qu’une vis n’est pas un pivot. Aucun des deux n’aurait produit ce design seul.

La suite au prochain épisode : plans 2D cotés, détail du palier et de la gorge, et fabrication en contreplaqué de 18. Le script et le modèle tournent déjà — il ne manque que les dimensions de mon salon.

Les fichiers

Tout est téléchargeable, servez-vous :

• sofa_parametrique.py — le script complet : paramètres, calcul du pivot, construction, animation. À ouvrir dans Blender (onglet Scripting) et relancer après avoir changé les PARAMS.
• canape_convertible.blend — la scène Blender avec l’animation de bascule (frame 1 = canapé, frame 61 = lit).
• canape_convertible.glb — le modèle au format glTF, animation comprise, lisible partout (viewers 3D en ligne, moteurs de jeu, AR).

Photos du canapé original : justchairs.eu. Modèle 3D : Blender 5.1 + BlenderMCP.

Tout a commencé par une dispute idiote.

« Coupe, c’est l’heure. » Une phrase banale. Sauf que ce soir-là, la réponse n’a pas été un soupir d’ado normal. C’était sec, à fleur de peau, presque hostile — comme si je venais de lui arracher quelque chose. Dix minutes plus tard, il était de nouveau lui-même. Mais entre les deux, il y avait eu ce moment : un gamin que je ne reconnaissais pas, irritable, fermé, ailleurs.

Et ce n’était pas la première fois. Le motif revenait : il regardait des vidéos Roblox — un youtubeur nommé Kevko, du Steal a Brainrot, du Lucky Block — et quand je l’interrompais en plein milieu, ça partait en vrille. Pas après. En plein milieu.

J’aurais pu en rester là. Décréter « les écrans, c’est mal », poser une règle, et m’épuiser à la faire respecter. Mais j’avais une intuition plus précise, et un fils trop intelligent pour avaler une interdiction sans explication. Il me fallait comprendre exactement ce qui se passait dans sa tête. Et pour ça, il me fallait des données, pas des impressions.

Acte II — L’enquête

Première hypothèse, la plus inquiétante : et si le contenu lui-même était le problème ? Beaucoup de vidéos Roblox tournent autour de voler, battre, piéger, troller, gagner contre les autres. Est-ce que mon fils passait ses après-midi à intérioriser une logique de compétition et de domination ?

Le problème, c’est que je n’en savais rien. Je ressentais. Et le ressenti, en matière d’éducation, c’est le plus court chemin vers l’injustice.

Alors j’ai décidé de faire ce qu’un journaliste ferait : lire les sources. Pas regarder distraitement deux vidéos — récupérer les transcriptions complètes des plus grosses vidéos de la chaîne et les analyser, mot par mot.

J’ai identifié ses 10 vidéos les plus vues (de 426 000 à 786 000 vues), extrait les sous-titres automatiques français, nettoyé le tout : 48 437 mots de transcript. Puis j’ai compté. J’ai classé le vocabulaire en grandes familles — urgence, compétition, récompense, accumulation, conflit, moquerie — et mesuré leur fréquence pour 1 000 mots.

Là, les chiffres ont commencé à parler. Et ils n’ont pas dit ce que je croyais.

Le contenu agressif que je redoutais — la domination, la moquerie, le troll — était quasi inexistant : 0,4 et 0,5 pour 1 000 mots, en gros du bruit statistique. Mon fils n’apprenait pas à écraser les autres.

Ce qui dominait, c’était tout autre chose : l’accumulation et l’urgence. Toujours un objet de plus. Toujours plus vite. Les deux mots-thèmes les plus fréquents de toute la chaîne étaient « encore » et « vite ». Et en mesurant les interjections et les rires — un indice de l’intensité — certaines vidéos grimpaient à 23 marqueurs d’excitation pour 1 000 mots, sans le moindre temps mort.

Je m’étais trompé de coupable. Le danger n’était pas idéologique. Il était physiologique.

Acte III — Ce qu’on a trouvé

Restait à confronter mes chiffres à la science. Et là, tout s’est emboîté.

1. La machine à récompense imprévisible. Le cœur de Steal a Brainrot, c’est le hasard : le Lucky Block qui peut lâcher un brainrot rare, le revenu passif qui tourne en permanence et pousse à se reconnecter. C’est exactement le renforcement à ratio variable — le mécanisme que les casinos exploitent depuis un siècle parce que c’est le plus addictif qui soit. Le cerveau libère de la dopamine en anticipant la récompense, pas en la recevant. On reste en tension permanente : et si le prochain était le bon ?

2. Ce n’est pas la violence, c’est le rythme. La pièce maîtresse, je l’ai trouvée dans une étude publiée dans la revue Pediatrics en 2011. Des chercheuses ont montré à des enfants 9 minutes d’un dessin animé simplement rapide — des coupes toutes les onze secondes — sans aucune violence. Juste après, leur capacité de concentration et de patience était mesurablement dégradée, comparée à des enfants ayant regardé un dessin animé lent. Neuf minutes. Le format Kevko, c’est précisément ça : débit saturé, montage haché, zéro respiration. Ce n’est pas ce qu’il raconte qui agit sur mon fils. C’est la vitesse.

3. Et voilà pourquoi ça explosait à la maison. Quand je coupais en plein milieu, le cerveau de mon fils était encore « en haut ». Et l’Académie américaine de pédiatrie le dit explicitement : à l’arrêt de l’écran, la dopamine chute, et cette chute nous laisse grognons et irritables. L’irritabilité que je prenais en pleine figure n’était pas de l’insolence. C’était un état chimique prévisible — le contrecoup d’un état d’excitation qu’on n’avait pas laissé redescendre.

Le plus cruel, c’est l’effet relationnel. Le contenu le mettait dans un état où il repoussait, sans le vouloir, les gens présents dans la même pièce. Et le piège du « toujours un de plus », c’est qu’il n’y a jamais de bon moment pour s’arrêter — donc jamais vraiment de moment où il était présent avec nous. Le vrai coût n’était pas le temps d’écran. C’étaient les moments réels, avec des gens réels, qui disparaissaient.

La nuance, parce qu’il faut rester honnête. Non, le brainrot ne « fait pas pourrir le cerveau » au sens littéral — c’est devenu le mot de l’année du dictionnaire Oxford en 2024, mais c’est un marqueur culturel, pas un diagnostic. Non, la fameuse « détox dopamine » n’est pas un vrai concept scientifique : on ne « réinitialise » pas sa dopamine en coupant les écrans. Et oui, le brainrot, c’est aussi de l’humour de gamins, un langage de génération. Mon fils n’est pas en danger. Mais il est, par construction, manipulé — et ça, ça se règle.

Acte IV — Ce qu’on essaie d’y faire

J’ai décidé de faire un pari : celui de son intelligence.

Pas d’interdiction frontale — un gamin malin la contourne et t’en veut. À la place, j’ai changé de camp. Le message n’était plus « papa t’interdit » mais « des ingénieurs payés des millions sont en train de jouer avec ton cerveau, et moi je suis dans ton équipe contre eux ». Rien n’agace plus un ado que d’être manipulé. C’était mon meilleur levier.

Puis je lui ai proposé une expérience, parce qu’il aime la science :

« Pendant une semaine, observe juste ton humeur dans les 10 minutes après avoir coupé. Note-la sur 10. Et compare : quand on te coupe en plein milieu, vs quand toi tu choisis le moment d’arrêter. Si je me trompe, je le reconnaîtrai. Mais regarde les données toi-même. »

Lui rendre le contrôle, c’est précisément ce que la recherche identifie comme le facteur qui réduit le plus les crises de fin d’écran. Et transformer une dispute récurrente en enquête commune, c’est le sortir de la position défensive.

Enfin, on a regardé des vidéos ensemble — pas des sermons, des décryptages faits par des gens qu’un ado respecte :

• Série « Dopamine » — ARTE, épisode TikTok (~9 min) : décortique, technique par technique, l’application qu’il connaît. Ton clinique, zéro morale, le déclic « ils me manipulent ». → https://www.youtube.com/watch?v=-pOWdBpVR3s
• « Et tout le monde s’en fout » — #59 Les algorithmes (~7 min) : drôle, complice, jamais donneur de leçon. → https://www.youtube.com/watch?v=5NiVg4DBJrI
• Tracks ARTE — « Brainrot : est-ce qu’internet fait pourrir nos cerveaux ? » : traite frontalement son univers. (À prévisionner d’abord.) → https://www.youtube.com/watch?v=ubT8hS0lAlg
• Stupid Economics — « L’économie de l’attention » : l’angle « ton attention est le produit qu’on vend ». → https://www.youtube.com/watch?v=rMV1WaWGb3I
• Tristan Harris — TED Talk (sous-titres FR) : l’ex-ingénieur de Google qui a alerté le premier. Crédibilité maximale. → https://www.ted.com/talks/tristan_harris_how_a_handful_of_tech_companies_control_billions_of_minds_every_day?language=fr

Le plan : commencer par la première (9 minutes, il reconnaît son appli), le laisser commenter, ne pas conclure à sa place. Le format court et factuel fait le travail tout seul.

Épilogue

Je n’ai pas « gagné ». Ce n’est pas une bataille qui se gagne en un soir, et ce n’était jamais le but. Mais quelque chose a changé : mon fils a cessé de voir un père qui confisque, et a commencé à voir un mécanisme qui le manipule. Il a un vocabulaire pour le nommer, maintenant. Et entre nous, la conversation a remplacé la dispute.

Le contenu qu’il regarde n’est pas le mal. Ce n’est même pas idéologique — mes propres données me l’ont prouvé. C’est juste une machine, très bien conçue, pour maintenir un cerveau d’enfant en état d’excitation maximale et le faire revenir. Comprendre la machine, c’est déjà à moitié s’en libérer.

Et ça, c’est un pari que je suis prêt à faire sur l’intelligence de mon fils.

Sources & références

Sur la dopamine et l’irritabilité après l’écran - American Academy of Pediatrics — Screen Time and Temper Tantrums (la chute de dopamine à l’arrêt rend irritable) : https://www.healthychildren.org/English/family-life/Media/Pages/screen-time-and-temper-tantrums-helpful-tips-for-parents.aspx

Sur le rythme/montage qui dégrade l’attention - Lillard, A. S., & Peterson, J. (2011). The Immediate Impact of Different Types of Television on Young Children’s Executive Function. Pediatrics, 128(4), 644-649. (L’étude « SpongeBob ».) Résumé accessible (NPR) : https://www.npr.org/sections/health-shots/2011/09/12/140401099/spongebob-may-be-too-speedy-for-preschool-brains - Méta-analyse récente sur les effets à court terme des médias sur l’attention et les fonctions exécutives des enfants (PMC, 2024) : https://pmc.ncbi.nlm.nih.gov/articles/PMC12412071/

Sur les boucles de récompense et le design addictif - The Vegas Effect of Our Screens — Psychology Today (renforcement à ratio variable) : https://www.psychologytoday.com/us/blog/tech-happy-life/201901/the-vegas-effect-of-our-screens - Why We Can’t Stop — Communication Research / Taylor & Francis (éléments récompensants des jeux et jeu problématique chez les ados) : https://www.tandfonline.com/doi/full/10.1080/15213269.2023.2242260 - Debunking the Dopamine Detox Trend — The Scientist (la « détox dopamine » est un mythe) : https://www.the-scientist.com/debunking-the-dopamine-detox-trend-72036

Sur le « brainrot » et Steal a Brainrot - « Brain rot » named Oxford Word of the Year 2024 — Oxford University Press : https://corp.oup.com/news/brain-rot-named-oxford-word-of-the-year-2024/ - Steal a Brainrot — fiche encyclopédique (revenu passif, boucle de jeu, monétisation) : https://en.wikipedia.org/wiki/Steal_a_Brainrot

Sur l’usage des écrans comme régulateur émotionnel - Using screens to calm kids may hurt their emotional regulation — CNN (relai d’une étude parue dans JAMA Pediatrics) : https://edition.cnn.com/2022/12/12/health/tantrum-distraction-screens-parenting-wellness

Ressources vidéo de vulgarisation (citées dans l’article) - Série Dopamine — ARTE (playlist) : https://www.youtube.com/playlist?list=PL8Ax_z5vzflwdvoTnARE5FiYl42Sg-fYb - Et tout le monde s’en fout — #59 Les algorithmes : https://www.youtube.com/watch?v=5NiVg4DBJrI - Brainrot : est-ce qu’internet fait pourrir nos cerveaux ? — Tracks / ARTE : https://www.youtube.com/watch?v=ubT8hS0lAlg - L’économie de l’attention — Stupid Economics : https://www.youtube.com/watch?v=rMV1WaWGb3I - Tristan Harris — TED (sous-titres FR) : https://www.ted.com/talks/tristan_harris_how_a_handful_of_tech_companies_control_billions_of_minds_every_day?language=fr

Note méthodologique : l’analyse lexicale porte sur les transcriptions automatiques (sous-titres YouTube FR) des 10 vidéos les plus vues de la chaîne, soit ~48 000 mots. Limite assumée : un transcript mesure les mots, pas le volume sonore ni le rythme de montage — or c’est précisément ce rythme que la science identifie comme le facteur le plus déterminant. Les chiffres sont donc un indice convergent, pas une mesure directe de la surstimulation.