Le Laboratoire

Interactif Un bouchon de pêche sur un étang, en temps réel dans le navigateur, sans vidéo ni rendu précalculé. C’est la première scène du travail sur l’eau de Genesis 3D, mon éditeur 3D web : une scène que j’aurais rendue hors ligne il y a quelques années, tenue ici à la cadence de l’affichage, et interactive.

Simulation de vagues sur GPU : équation d’onde sur heightfield

La surface autour du bouchon est un heightfield de 512 × 512 cellules sur 2 × 2 m, environ 4 mm par cellule. L’équation d’onde tourne dans un fragment shader, en ping-pong entre deux render targets, en sous-pas de 4 ms. La grille suit le bouchon en se recalant d’un nombre entier de cellules. Elle reçoit trois sources : la variation de volume immergé du bouchon, le ménisque qui monte et descend le long de l’antenne (d’où les ronds permanents), et les impacts de pluie et de gobages.

Flottaison physique : un corps rigide en 64 tranches

Le bouchon est un corps rigide découpé en 64 tranches. Chacune calcule son volume immergé, sa poussée d’Archimède et sa traînée. Il est plombé à 2,7 g, en unités réelles (mètres, secondes, newtons). Les touches de poisson ne sont pas animées : ce sont des fonctions de force appliquées à la ligne. La ligne est une corde de Verlet, qui ne transmet sa tension que lorsqu’elle est tendue et qui gère l’état mouillé ou sec du fil à la surface.

Rendu de l’eau : réflexion, réfraction de Snell, absorption

La réflexion vient d’une caméra miroir rendue dans une render target. Pour la réfraction, ce qui est sous l’eau est déplacé dans le vertex shader selon la loi de Snell, avec une recherche par dichotomie du point d’entrée dans la surface. Une réfraction en espace écran déplaçait les objets fins : le fil y dessinait un V. L’eau d’étang absorbe selon la longueur réelle du trajet de la lumière. Les rides de vent sont des trains d’ondes analytiques modulés par un bruit qui fait passer des risées.

Profondeur de champ physique

Le BokehPass de three.js est corrigé pour calculer un vrai cercle de confusion de lentille, 1 − mise au point / profondeur, au lieu d’un flou qui croît linéairement avec la distance. Tout ce qui doit être flou doit donc avoir une vraie profondeur. Les gouttes de pluie sont des rubans instanciés, de l’épaisseur réelle d’une goutte : des lignes d’un pixel disparaissaient dans le flou.

Pluie procédurale

Les ronds de pluie sont calculés dans le shader de l’eau. Quatre familles de gouttes, des fines aux grosses, sont réparties sur des grilles hachées, avec un tirage par cellule et par cycle, des tailles aléatoires et des averses par plaques. Près du bouchon, les gouttes entrent aussi dans la simulation de vagues, et le bouchon les sent.

Architecture : OffscreenCanvas dans un Web Worker

La scène tourne dans un Web Worker avec un OffscreenCanvas, pour que la page reste fluide pendant le défilement ; Safari retombe sur le fil principal. Rien n’est téléchargé à part les sons : nénuphars, feuilles et environnement sont générés au chargement. Le son passe par WebAudio, spatialisé selon la position à l’écran de chaque événement.

Sur quoi on travaille

La même eau à toutes les échelles, en unités réelles : un verre qu’on renverse, un bassin, une rivière en particules PBF. Et un simulateur de voile : mon cotre aurique sur une mer FFT, avec sillage, écume et vent apparent, en WebGPU.

J’utilise Cinema 4D depuis que j’ai dix-sept ans, à peu près. J’en ai quarante-deux aujourd’hui. Pendant longtemps, je ne me suis d’ailleurs jamais vraiment demandé pourquoi je passais autant de temps dans ce logiciel. Ce n’était pas spécialement pour produire des images finales, encore moins pour devenir modeleur ou animateur au sens classique. Ce qui m’intéressait était toujours situé un peu avant le rendu. Comprendre comment est construit un corps humain, pourquoi une articulation fonctionne dans un sens et pas dans un autre, comment une aile se replie, comment un objet tient, comment une façade se décompose, comment obtenir un volume crédible avec suffisamment peu de polygones pour que chaque quad ait une raison d’exister. Il y avait quelque chose du casse-tête là-dedans. Je pouvais passer des heures à reconstruire un objet simplement pour comprendre comment ses formes s’organisaient, puis tourner autour, déplacer les pièces, modifier une articulation et regarder comment tout le reste réagissait. La photographie m’a probablement appris autant sur la 3D que la 3D elle-même, parce qu’elle m’a obligé à comprendre ce que la lumière fait réellement au volume. Je crois qu’au fond, j’ai toujours utilisé les outils de création comme des instruments pour démonter mentalement le réel.

Le problème est qu’une scène 3D traditionnelle finit toujours par mourir au moment où on décide de la montrer. On choisit une caméra, on lance un rendu, et tout l’espace que l’on a construit est réduit à une image ou à une séquence dont on a décidé à l’avance où quelqu’un allait regarder. Ça m’a toujours frustré. J’aime interagir avec les choses. Je ne suis pas particulièrement joueur, mais j’aime entrer dans un système, tourner autour, provoquer une réaction, voir ce qui change. Quand j’ai découvert Unreal, j’ai eu une sorte de déclic parce que, pour la première fois, je pouvais réellement faire vivre des choses dans les mondes que je construisais. Des personnages pouvaient y exister, des objets pouvaient répondre, un environnement pouvait continuer à produire quelque chose une fois que j’avais cessé de le manipuler directement. La réalité virtuelle poussait cette idée encore plus loin, mais avec une limite évidente : elle reste difficilement accessible. Il faut un casque, une machine, une installation, parfois expliquer comment entrer dans l’expérience avant même de pouvoir montrer ce qu’elle contient.

En février 2026, j’ai découvert Three.js, et c’est probablement là qu’une partie des choses que je fais aujourd’hui ont commencé à se rejoindre. J’ai créé Genesis 3D parce que je voulais pouvoir mettre de vrais contenus 3D interactifs dans un navigateur, sans demander au visiteur d’installer quoi que ce soit et sans transformer mon site en démonstration technique de trente secondes de chargement. Je connaissais Spline et Vectary, mais ils étaient beaucoup trop lourds pour ce que je voulais faire. Mon site devait continuer à atteindre cent sur cent sur Lighthouse tout en contenant des expériences réellement interactives. Cette contrainte a eu une conséquence assez saine : chaque fois qu’un mécanisme n’était pas indispensable, il devait disparaître. Genesis 3D s’est donc construit comme ça, par nécessité, et il m’a fait découvrir quelque chose que je n’avais pas réellement formulé auparavant : donner l’impression qu’un objet est vivant demande souvent beaucoup moins que ce que l’on imagine, à condition d’agir au bon niveau.

Au départ, je voulais simplement afficher des objets et pouvoir les manipuler. Ensuite j’ai voulu qu’ils bougent, puis qu’ils répondent, puis qu’ils perçoivent. J’ai commencé à leur ajouter des états internes. À partir de là, je n’avais plus vraiment un poisson animé devant moi. J’avais un poisson qui pouvait avoir faim, être fatigué, vouloir se rapprocher d’autres individus, fuir quelque chose ou accepter un risque qu’il aurait refusé quelques secondes plus tôt. J’ai construit des simulations, des petits jeux, un aquarium, puis un étang où les poissons avaient une forme de vie sociale. L’un des trucs qui m’a le plus marqué est venu d’un problème très classique : le banc. On sait très bien construire mathématiquement un banc de poissons. Il existe depuis longtemps des règles de cohésion, d’alignement et de séparation qui permettent de maintenir un groupe crédible. C’est efficace, mais je me suis rendu compte que je travaillais sur la conséquence sans traiter la cause. Les mathématiques expliquent comment un poisson peut rester correctement positionné parmi les autres ; elles n’expliquent pas pourquoi il voudrait y rester. Si je lui donne peur d’être isolé, besoin de protection et désir de survie, le problème change complètement. La mécanique du banc reste utile, mais elle devient l’expression finale d’une motivation plus profonde.

C’est exactement le genre de glissement qui me fascine depuis que je travaille sérieusement sur l’intelligence artificielle. J’ai passé environ trois ans à apprendre les modèles de langage, les systèmes agentiques, la mémoire, le routage, les mécanismes d’attention et tout ce qui permet de faire fonctionner plusieurs formes d’intelligence dans une même architecture. Pourtant, plus j’avance, moins le modèle lui-même m’intéresse comme objet central. Ce qui m’intéresse est l’endroit où plusieurs mécanismes très simples cessent d’être des fonctions isolées. Perception, mémoire, état interne, contraintes, décision, action, apprentissage : à partir d’un certain niveau d’interaction, quelque chose se produit entre eux. Le système reçoit une modification du monde extérieur, cette modification traverse son état interne, une réponse est produite, cette réponse change à son tour le monde, puis le système doit vivre avec la conséquence de ce qu’il vient de faire. Je crois que c’est là que commence ce que j’appelle, faute de meilleur mot, la vie. Pas une conscience magique, pas un chatbot auquel on aurait ajouté deux variables d’humeur. Une boucle suffisamment cohérente pour qu’un organisme numérique cesse simplement d’exécuter des ordres et commence à devoir composer avec ce qui lui arrive.

Et c’est assez naturellement que tout cela m’a ramené à Cinema 4D.

Revenir à l’outil de départ

J’avais besoin d’un bras robotique pour une nouvelle démonstration de mon site. Je pouvais évidemment le modéliser et le riguer dans Cinema 4D comme je l’avais toujours fait, mais je suis immédiatement retombé sur un problème que je connais depuis longtemps : le rigging traditionnel y devient vite extrêmement lourd. Pour articuler correctement un bras, un personnage ou une machine, on assemble généralement des joints, des chaînes IK, des solveurs qui calculent les rotations intermédiaires nécessaires pour amener l’extrémité d’une chaîne vers une cible, puis tout un ensemble de contraintes destinées à empêcher le système de profiter de sa liberté pour faire n’importe quoi. On impose une direction privilégiée, des limites angulaires, des contrôleurs, des cibles, des dépendances, parfois des correctifs destinés à empêcher un autre correctif de créer un comportement indésirable. Ça fonctionne, évidemment. Cinema 4D est utilisé professionnellement depuis des décennies et je ne prétends pas connaître suffisamment son implémentation interne pour expliquer précisément pourquoi certains rigs deviennent aussi coûteux. Mais j’y vois un problème typique des logiciels anciens et généralistes : des couches ont été ajoutées pendant des années pour répondre à des usages extrêmement différents, et elles ne peuvent pas simplement disparaître parce que des milliers de scènes et de workflows dépendent encore d’elles.

Ce qui m’a frappé en travaillant dans Three.js, c’est que je pouvais faire bouger un corps humain complet, avec ses contraintes, directement dans un navigateur à soixante images par seconde, alors que certaines structures devenaient pénibles à manipuler dans Cinema 4D sur la même machine. Je n’avais pas inventé un meilleur solveur universel. J’avais fait presque l’inverse : j’avais refusé d’en construire un. Pour une articulation robotique, je n’ai besoin que d’un axe, d’une course, d’une position, éventuellement d’une friction et de la relation géométrique avec le segment suivant. Le système classique part d’une structure suffisamment libre pour répondre à énormément de situations puis lui ajoute des règles pour lui interdire les mouvements inutiles. Moi, je pars d’une structure qui ne sait faire que ce qu’elle est physiquement censée faire, et j’ajoute de la liberté uniquement quand elle devient nécessaire. C’est la différence entre une architecture additive et une architecture que je qualifierais presque de soustractive : au lieu d’empiler des mécanismes jusqu’à ce que le système se comporte correctement, je commence par retirer tout ce qui n’a aucune raison d’exister.

Mais mon problème principal n’était même pas la performance. C’était la répétition. Je n’avais aucune envie de créer un rig dans Cinema 4D, puis d’en recréer un autre dans une simulation web, un troisième dans l’environnement Python utilisé pour l’apprentissage, et encore une nouvelle logique sur Raspberry Pi ou Arduino lorsque le bras deviendrait physique. Une limite articulaire reste une limite articulaire quel que soit l’endroit où elle est exécutée. Un moteur possède toujours une plage de rotation, un couple, une vitesse et une inertie. Pourquoi réécrire quatre fois la même réalité simplement parce que l’outil qui l’exécute change ? La motivation de DIP Rig est donc beaucoup moins noble qu’une grande révélation architecturale : j’avais la flemme. Mais c’est souvent une excellente contrainte de conception. Je voulais décrire une mécanique une seule fois et pouvoir la faire vivre partout.

L’idée des plugins avait commencé quelques mois auparavant d’une manière beaucoup plus modeste. En travaillant sur Echo Bot, j’avais besoin de calculer la longueur réelle de câbles passant par différents endroits du robot. Nous avions écrit quelques scripts Python pour résoudre ça dans Cinema 4D. Ils fonctionnaient bien, et je me suis dit qu’il était idiot de laisser cette mécanique sous forme de scripts temporaires qui finiraient perdus dans un dossier alors qu’elle pouvait devenir un véritable outil. Le premier plugin est né comme ça ; je crois qu’il s’appelle simplement Cables. L’idée m’a plu mais je l’ai laissée de côté. Entre Echo à imprimer, câbler et souder, le site à reconstruire et le reste de mes projets, apprendre correctement tout ce qui concerne les interfaces et l’écosystème des plugins C4D n’était simplement pas prioritaire.

Le retour au bras articulé a relancé le sujet. J’ai d’abord voulu vérifier que je pouvais communiquer proprement avec l’extérieur depuis Cinema 4D. J’avais déjà installé des assistants conversationnels dans la majorité de mes applications, donc porter le principe ici était assez naturel. En quelques heures, j’avais un chatbot capable de dialoguer avec une API externe et d’agir dans le logiciel. C’est devenu DIP Chat, ou Cath selon les endroits. Pour le moment, je le considère surtout comme une preuve que le bridge fonctionne. Il pourra évidemment servir à automatiser une quantité énorme de tâches : renommer correctement cinquante joints, réorganiser plusieurs centaines d’objets, retrouver une pièce dans une hiérarchie ou préparer une scène ne sont pas des choses sur lesquelles j’ai envie de dépenser mon attention. Ce sont exactement les tâches qu’un assistant devrait absorber pour me laisser travailler sur ce qui compte réellement. Pour que cela devienne un outil généraliste, il faudra toutefois construire quelque chose de beaucoup plus propre qu’un gros prompt rempli de documentation. Cinema 4D possède une quantité considérable de commandes, de paramètres et de workflows ; envoyer tout ça à chaque requête serait aussi coûteux qu’inefficace. J’ai donc commencé une mécanique d’attention capable d’identifier le besoin, de ne fournir à l’agent que le contexte utile et de lui donner accès à une base de connaissances lorsqu’il doit chercher davantage. C’est un chantier énorme, probablement un travail à plein temps si je veux le faire correctement, et ce n’est paradoxalement pas ce qui m’intéresse le plus dans Cath. Ce qui m’intéresse est d’en faire l’interface linguistique permettant de parler directement aux systèmes qui vivent dans la scène.

C’est là qu’arrive DIP Rig.

Construire un corps une seule fois

Le plugin commence volontairement de manière très simple. On ouvre une scène vide, on lance DIP Rig et on choisit le type de corps à générer. J’ai commencé par un bras robotique six axes parce que c’est probablement le meilleur objet pour tester tout ce que je veux construire sans mélanger trop de problèmes en même temps. Pas de navigation, pas d’équilibre dynamique comme sur un bipède ou un hexapode, pas de dizaine de membres qui doivent se coordonner : quelques moteurs, un volume de travail limité et un ensemble d’actions faciles à définir. Chercher un objet, l’approcher, le saisir, le déplacer, le poser. Comprendre un ordre. Dire oui ou non lorsqu’une action est possible ou impossible. Exécuter.

Le plugin demande ensuite le type d’organe terminal. Nous avons commencé par une pince parallèle assez classique, mais la même logique peut accueillir une main, un outil d’impression, une tête de fraisage ou n’importe quel système ayant besoin d’une cinématique différente. On définit les grandes dimensions du bras, puis DIP Rig génère une première chaîne de repères que l’on peut déplacer pour régler les proportions. J’aime bien partir dans ce sens : construire d’abord la mécanique, puis dessiner autour, plutôt que modéliser un très bel objet et découvrir ensuite que son articulation réelle n’a aucun sens. Le bras actuel est volontairement plausible. Les longueurs, positions d’axes et bras de levier ont été dessinés pour ne pas demander des efforts absurdes aux moteurs lorsqu’il sera transposé physiquement.

Une fois les repères en place, un clic sur Build génère la chaîne de joints, les axes, les limites principales et un mesh basse définition utilisable immédiatement. Ce mesh n’est pas destiné à devenir le modèle final. Il donne simplement une base suffisamment propre pour comprendre le volume et commencer à travailler. À partir de là, je peux manipuler le bras directement, l’animer avec des images clés et des courbes de Bézier comme n’importe quel autre rig, ou prendre chaque élément de la hiérarchie, le travailler dans un document séparé, modéliser une vraie pièce autour des entraxes existants puis le replacer dans le projet. Tant que les axes et les distances sont respectés, le système ne change pas. On peut donc passer progressivement d’un bras constitué de primitives à une machine détaillée jusqu’aux logements des servos sans reconstruire la mécanique.

Mais la partie réellement importante n’est pas la génération du rig. C’est le tag DIP Rig ajouté à la chaîne. Je le vois comme un programme dans le programme. Cinema 4D devient l’environnement qui héberge la scène et les outils de création ; le tag embarque la mécanique qui donne son comportement au corps. Moteur de mouvement, contraintes, description des moteurs, modèle physique utile, perception, état interne, puis progressivement décision, langage et apprentissage. Le principe est de garder cette intelligence suffisamment indépendante de Cinema 4D pour pouvoir la transporter. Aujourd’hui elle tourne en Python dans le logiciel. Une version équivalente pourra fonctionner en JavaScript dans Genesis 3D. Une autre pourra finir sur le contrôleur d’une vraie machine. Ce que je veux exporter n’est donc pas seulement un modèle ou une animation. Je veux exporter la logique physique du corps.

Cette distinction est importante parce qu’elle transforme complètement la fonction de Cinema 4D dans mon travail. Il n’est plus simplement le logiciel dans lequel je modélise ce que je fabriquerai ensuite. Il devient un laboratoire où je peux construire, simuler, observer et préparer la machine réelle avec les mêmes contraintes que celles qui continueront d’exister lorsqu’elle quittera l’écran.

Nous avons déjà rencontré un cas qui résume assez bien cette philosophie avec la pince. Pour obtenir rapidement une prise fonctionnelle, nous avions commencé par souder l’objet à la paume : dès que les mors se refermaient dessus, une matrice figée le rendait solidaire de la main. Techniquement, ça marchait très bien. Je l’ai fait retirer presque immédiatement parce que c’était de la magie. Si je construis un système destiné à apprendre à saisir des objets, je ne peux pas supprimer artificiellement toute la partie intéressante du problème au moment où les surfaces entrent en contact. Avec une soudure, toutes les prises se valent : droite, de travers, par un coin. Il ne reste plus rien à apprendre. Une vraie pince tient parce qu’elle applique une force, que les matériaux produisent de la friction, que l’objet résiste et que les moteurs renvoient une information sur l’effort qu’ils fournissent. Une prise peut être mauvaise, glisser, demander trop de couple ou commencer à devenir instable. Si le simulateur transforme tout cela en un simple booléen « attached », le robot n’apprend pas à saisir. Il apprend à déclencher une fonction.

Nous avons donc rendu les mors cinématiques. Un mors cinématique possède une masse infinie, puisque c’est un moteur qui le tient et que rien ne doit pouvoir le repousser, mais il a une vitesse réelle et il participe aux contacts comme n’importe quel autre corps. L’objet n’est alors attaché à rien : il est tenu par le frottement entre les deux mors, et par rien d’autre. Serré fort et bien centré, il tient. Serré mou ou de travers, il glisse et il tombe. Personne n’a écrit « lâcher » : c’est devenu une conséquence.

Et ça n’a pas suffi. Un mors mené en position ne produit aucune force normale, donc le frottement n’a rien à multiplier. La mesure est sans appel : la main monte de trente centimètres et le cube reste sur la table. Il a fallu descendre encore d’un étage et mener le mors non plus en position mais en force, sur un rail à un seul degré de liberté, résolu avec les contacts. C’est seulement là que la prise a commencé à exister.

C’est une petite histoire technique, mais elle contient deux choses qui reviennent constamment dans mes systèmes. La première est qu’une simulation intéressante doit pouvoir échouer : si elle protège le système de l’erreur, elle lui retire également la possibilité d’apprendre pourquoi cette erreur existe. La seconde est moins agréable et je la trouve plus utile encore : remplacer une facilité par un vrai mécanisme ne suffit pas si ce mécanisme n’est alimenté par rien. La friction était la bonne réponse. Elle est restée sans effet tant qu’aucune force ne venait la nourrir.

Quand une commande devient un comportement

Dire « prends le cube rouge et pose-le à gauche » semble être une commande simple. En réalité, elle est intéressante précisément parce qu’elle force plusieurs niveaux du système à collaborer sans qu’aucun d’eux puisse résoudre seul le problème. Il faut d’abord comprendre ce que je demande, puis identifier le cube rouge. S’il n’est pas visible, le robot doit explorer son environnement, déplacer sa caméra ou son corps selon sa morphologie jusqu’à trouver quelque chose correspondant suffisamment à la cible. Ensuite vient une première décision : est-ce que cet objet est réellement manipulable ? La pince est-elle assez grande ? L’effort nécessaire est-il compatible avec les moteurs ? L’orientation du cube permet-elle une prise correcte ou vaut-il mieux le pousser légèrement afin de le présenter différemment ?

Cette dernière question est plus importante qu’elle en a l’air, parce qu’elle fait apparaître immédiatement le problème du compromis. Un système excessivement prudent peut passer dix heures à ajuster un objet pour obtenir une prise théoriquement parfaite. À l’inverse, un système trop agressif accumulera les échecs et l’usure. Une partie de l’intelligence consiste donc à déterminer ce qui est suffisamment bon. À un moment, il faut accepter le risque et essayer. Lorsque la pince se referme, le retour d’effort des moteurs devient lui-même un capteur. La pression augmente jusqu’au contact. Si elle varie ensuite alors que l’objet est censé être immobile, quelque chose glisse peut-être. Le robot peut reprendre légèrement sa prise, modifier l’orientation, resserrer ou décider que la situation n’est pas fiable et recommencer.

Une fois l’objet saisi, le trajet vers la cible crée un autre ensemble de problèmes. Le déplacement le plus court dans l’espace n’est pas nécessairement le meilleur. Une trajectoire directe peut croiser un autre objet, solliciter excessivement une articulation ou placer le bras dans une configuration dont il aura ensuite du mal à sortir. Il peut être plus efficace de monter, tourner autour d’un obstacle puis redescendre. Si la zone demandée est déjà présente dans la mémoire spatiale, le système peut s’y rendre directement ; sinon il doit la localiser. Lorsqu’il descend pour déposer le cube, une légère variation de résistance peut indiquer le contact avec le support et déclencher l’ouverture des mors.

Ce que je trouve intéressant est qu’aucune de ces opérations n’est particulièrement spectaculaire prise isolément. Chercher, approcher, saisir, vérifier, porter, éviter, déposer, se rétracter. Je veux justement qu’elles restent petites. Mon objectif est de constituer une bibliothèque de phases réutilisables qui puissent être recombinées selon le corps et la tâche. Le même mécanisme permettant à une pince de comprendre qu’elle force peut être utilisé ailleurs pour qu’une articulation arrête un mouvement dangereux. Le même système de recherche spatiale peut servir à trouver un cube, une station de recharge ou une personne. Je pense beaucoup mes architectures comme des Legos : la complexité ne doit pas vivre dans une énorme fonction capable de tout faire, mais dans les relations entre des pièces simples qui peuvent être réutilisées dans d’autres systèmes.

C’est à ce moment-là que j’utilise volontairement le mot « vie ». Pour moi, la vie n’est pas liée à la présence d’un LLM. Un modèle de langage peut parfaitement être une couche utile d’un organisme complètement mort. Ce qui m’intéresse est une boucle algorithmique entre l’extérieur et l’intérieur. Un stimulus existe, le système le perçoit, son état change, il analyse les conséquences possibles puis agit pour retrouver ou maintenir une situation qui lui convient. Une pression anormale sur une articulation peut devenir l’équivalent fonctionnel d’une douleur. Le robot force, donc quelque chose menace son intégrité. La bonne réponse n’est pas nécessairement une erreur système et un arrêt brutal. Il peut chercher ce qui l’empêche de bouger, tester un mouvement de retrait, observer si la pression diminue et continuer jusqu’à retrouver une situation sûre. Pour un bipède poussé latéralement, le même principe pourrait exploiter gyroscope, accéléromètre et marge disponible dans les moteurs afin de rechercher une nouvelle configuration stable.

Je peux coder une partie de ces réponses, mais je ne veux pas les coder toutes. Ce qui m’intéresse est de définir les conditions auxquelles le système doit essayer de répondre. Douleur, consommation énergétique, temps, précision, usure, stabilité, réussite ou échec d’une tâche peuvent devenir des signaux positifs ou négatifs. Une fonction de fitness peut fournir une première structure, mais même ses poids n’ont pas nécessairement vocation à rester complètement figés. J’ai une compréhension globale du système et je peux proposer des valeurs initiales cohérentes. Je ne suis pourtant pas dans le corps que je construis. Je ne peux pas ressentir la somme exacte de toutes les contraintes produites par la longueur d’un segment, le couple d’un moteur, une accélération, le poids d’un objet et la manière dont une pince est entrée en contact avec lui. À un moment, si je veux que le système progresse réellement, il faut lui laisser assez de liberté pour trouver une manière de faire qui corresponde à son propre corps plutôt qu’à l’intuition que j’en ai.

C’est probablement la question la plus philosophique derrière tout ce que je construis depuis plusieurs années : à quel moment une succession de mécanismes déterministes, enrichie ensuite par des analyses probabilistes et de l’apprentissage, finit-elle par produire un comportement que personne n’a explicitement écrit ? Je le rencontre souvent par les effets de bord. Deux mécanismes entrent en contradiction, l’un pousse dans une direction et l’autre interdit précisément cette direction. La plupart du temps, c’est simplement un problème à résoudre. Trouver ces conflits représente une énorme partie de mon travail. Mais il arrive qu’un état intermédiaire apparaisse, une solution qui n’était décrite nulle part et qui résulte simplement de l’interaction entre plusieurs règles. Parfois elle est mauvaise et doit disparaître. Parfois elle est plus intéressante que ce que j’avais prévu.

C’est aussi ce qui me plaît dans les algorithmes évolutionnaires. Introduire du bruit ou des mutations revient à accepter volontairement de perdre une partie du contrôle local pour voir si le système trouve une stabilité que l’on n’aurait pas imaginée. Ce qui compte n’est pas le hasard en lui-même mais ce que la sélection en fait ensuite. Une solution étrange qui apparaît une fois ne m’intéresse pas beaucoup. Une solution étrange, reproductible, plus efficace et capable de survivre aux mêmes contraintes que les autres devient immédiatement intéressante.

Évidemment, la frontière entre laboratoire et monde réel doit rester extrêmement nette. Je peux laisser une simulation explorer des comportements absurdes, casser virtuellement un bras ou tester une stratégie qui ne serait jamais acceptable autour de personnes. Une voiture autonome pourrait théoriquement découvrir une manière de circuler beaucoup plus efficace que celle des humains ; si elle roule au milieu d’humains, elle ne peut pas simplement imposer son propre protocole au réel sous prétexte qu’il est mathématiquement meilleur. L’environnement social devient lui-même une contrainte du système. À l’inverse, lorsque personne d’autre n’est impliqué, je veux pouvoir laisser les choses diverger beaucoup plus librement. Une population peut développer une manière totalement différente d’exécuter une tâche et continuer son évolution dans cette direction pendant qu’une autre explore ailleurs. Je peux ensuite mesurer, comparer, conserver plusieurs lignées, éventuellement éliminer volontairement un comportement pourtant performant parce qu’il devient mauvais sous un autre critère. Si un poisson nage extrêmement bien mais que sa stratégie le rend incapable de maintenir suffisamment de relations sociales pour survivre, sa performance locale ne suffit plus. À l’inverse, si toute une population finit par nager à l’envers et que ça ne pose aucun problème de viabilité, je ne vois pas pourquoi je déciderais arbitrairement que la solution est fausse.

Je pense que la nature a produit une partie de sa diversité exactement comme ça. L’évolution n’a aucune obligation esthétique. Elle conserve ce qui tient suffisamment bien dans un contexte donné.

Je ne suis pas Dieu. Je pose un monde, j’observe ce qui s’y passe et je filtre lorsqu’un comportement commence à avoir des conséquences qui dépassent le laboratoire.

Un laboratoire qui apprend du réel

La manière dont tout cela sera implémenté dans DIP Rig dépendra beaucoup de ce que le projet devient. S’il reste principalement mon outil, je peux me permettre une approche très expérimentale. Générer plusieurs variantes d’un même bras, modifier leurs proportions, changer les moteurs, tester différentes architectures de décision et systèmes d’entraînement, lancer un nombre considérable d’instances en parallèle et les laisser vivre des centaines de milliers de trajectoires virtuelles. Certaines peuvent privilégier la précision, d’autres la vitesse, d’autres encore l’économie mécanique. Les solutions retenues dépendront de l’usage. Une imprimante trois D six axes n’a presque rien à voir avec un bras destiné à déplacer des objets. La première doit probablement privilégier continuité du mouvement, répétabilité, faible vibration et précision. Le second peut accepter d’autres compromis. Un robot travaillant près d’humains ajoute encore un autre monde de contraintes.

Si DIP Rig doit un jour être utilisé par d’autres personnes, certaines parties devront nécessairement être figées. On distinguera ce qui est validé de ce qui est expérimental, on collectera autant de retours que possible, et plusieurs profils pourront évoluer en parallèle pour différents moteurs, tailles et usages. Mais la logique reste la même : je ne cherche pas un comportement universellement optimal. Je cherche une architecture capable de produire ou d’apprendre un comportement cohérent avec un corps, une tâche et un environnement.

Et c’est là que DIP Rig commence à modifier beaucoup plus profondément ma manière de travailler dans Cinema 4D. Quand j’ai construit Echo Bot, une quantité énorme de temps a été consacrée à recréer les composants physiques dans le monde virtuel. Mesurer un servo, reconstruire son volume, vérifier les trous, positionner les axes, dessiner ensuite une pièce imprimable autour de tout ça. Lorsqu’un composant changeait, une partie de cette connaissance devait être recréée ailleurs. Je veux maintenant construire une bibliothèque de servos contenant non seulement leur géométrie, mais leur comportement physique : course, couple, vitesse, dimensions, éventuellement consommation, température ou données récupérées sur le moteur réel. La même chose pourra exister pour les capteurs, les articulations, les pinces, les batteries et progressivement pour des sous-systèmes entiers.

Le changement essentiel est qu’un élément créé une fois pourra réellement devenir une connaissance réutilisable. Je pourrai générer un nouveau robot à partir de composants déjà connus plutôt que redessiner les mêmes fondations. Mais surtout, je veux fermer la boucle avec la machine physique. Le robot réel doit pouvoir renvoyer ses données vers le modèle. Si un servo produit moins de couple que ce que la simulation avait prévu, si une articulation chauffe plus vite, si un mouvement théoriquement optimal génère des vibrations que le modèle ne connaissait pas, je veux pouvoir réinjecter cette information dans la simulation. Le jumeau virtuel cesse alors d’être une représentation préparée avant la fabrication. Il devient un modèle corrigé progressivement par le corps réel.

À partir de là, les données accumulées par un projet peuvent également devenir utiles aux suivants. Une stratégie de prise apprise sur un bras peut servir de point de départ à un autre manipulateur. Un modèle physique affiné à partir d’un servo réel améliore toutes les simulations utilisant ce composant. Une articulation qui a découvert certaines zones d’effort inutiles peut fournir des contraintes à d’autres morphologies. Chaque nouvelle machine enrichit progressivement la bibliothèque commune.

C’est précisément la manière dont je conçois mes autres systèmes : une brique ne doit pas perdre sa valeur lorsque le projet qui l’a fait naître est terminé. Si elle a résolu quelque chose de général, elle doit pouvoir remonter dans l’architecture et être réutilisée ailleurs.

En regardant DIP Rig aujourd’hui, alors que le projet n’existe que depuis deux jours et que je le développe en parallèle du reste de mon site, je crois que ce qui me plaît le plus est justement qu’il ne donne pas l’impression de commencer quelque chose de nouveau. Il donne l’impression que beaucoup de choses reviennent enfin au même endroit.

J’ai passé près de vingt-cinq ans à utiliser la 3D pour comprendre la forme, la lumière, le mouvement et la matière. J’ai ensuite passé trois ans à me concentrer presque exclusivement sur l’intelligence artificielle, les modèles de langage, les agents et la manière de construire des architectures capables de percevoir, mémoriser, décider et apprendre. Pendant un moment, ces deux trajectoires semblaient presque indépendantes. En réalité, c’est l’apprentissage des systèmes d’IA qui me permet aujourd’hui de revenir vers la 3D et de regarder autrement un objet articulé. Et c’est probablement parce que je viens de la 3D que je cherche sans arrêt à donner un environnement, des contraintes et finalement un corps aux architectures intelligentes que je construis.

Genesis 3D m’a permis de faire vivre des systèmes directement dans un navigateur. Les poissons m’ont obligé à distinguer la mécanique d’un comportement de la raison qui le provoque. Homeostasis m’a appris à distribuer des responsabilités entre des composants autonomes. Echo m’a poussé vers la mémoire, l’état interne, les réflexes et l’apprentissage. Echo Bot a ajouté la matière, l’inertie, l’énergie, la douleur mécanique et cette propriété extraordinaire du monde physique : lorsqu’une idée est mauvaise, la gravité finit généralement par donner son avis. DIP Rig se retrouve maintenant au croisement de tout ça, mais cette fois à l’intérieur d’un logiciel professionnel que je n’ai pas construit.

C’est également important pour moi. Jusqu’ici, une grande partie de mes systèmes vivent dans mon propre écosystème. Genesis, Genesis 3D, Homeostasis, Echo : je contrôle la structure dans laquelle ils existent. DIP Rig me permet de vérifier que cette manière de penser n’est pas seulement adaptée aux outils que j’ai créés moi-même. J’entre dans Cinema 4D, un logiciel du marché que j’utilise depuis l’adolescence, et j’y applique exactement les mêmes principes : réduire la mécanique à ce qui est essentiel, créer des briques autonomes, donner à l’intelligence uniquement la place où elle apporte quelque chose, connecter le système au monde extérieur et conserver autant que possible une architecture qui reste portable.

Claude Code joue évidemment un rôle énorme dans la vitesse à laquelle tout cela devient possible. Je ne suis pas développeur et je ne cherche pas à le devenir. Je comprends les systèmes, leurs dépendances, les flux, ce qui devrait exister ou ne pas exister, puis je travaille avec l’IA pour matérialiser cette architecture. Plus les outils progressent, moins je suis obligé de consacrer mon énergie à l’implémentation elle-même et plus je peux réfléchir au niveau qui m’intéresse : pourquoi le système agit, quelle information lui manque, quelles contraintes sont réellement nécessaires, quel degré de liberté on peut lui laisser et à partir de quel moment une interaction entre plusieurs mécanismes commence à produire quelque chose que personne n’avait prévu.

C’est probablement ça qui relie finalement tout ce que je fais.

Je crois que j’essaie de construire mentalement une sorte de grande fonction du vivant. Pas une équation universelle ni une imitation biologique littérale, mais un ensemble de mécanismes suffisamment généraux pour fonctionner avec différents corps, différentes perceptions et différentes capacités. Chaque projet me donne une variable supplémentaire. Un poisson apporte une question sur le groupe et la peur. Une mémoire vectorielle apporte une question sur la continuité du contexte. Un robot apporte la douleur et l’usure. Un bras apporte la manipulation, la friction et la relation entre intention et mouvement. Un plugin apporte l’idée qu’une même architecture peut survivre au changement de logiciel, de langage ou même de matière.

Plus ces pièces commencent à se rejoindre, moins j’ai l’impression de construire des projets différents.

J’ai plutôt l’impression d’observer le même système depuis plusieurs endroits.

11 août 2026.

On cherchait à corriger un problème assez bête : quand Echo trouve une réaction qui fonctionne, elle finit par la rejouer toujours de la même manière. Le réflexe évident serait de faire diminuer artificiellement la valeur d'une réponse lorsqu'elle est trop répétée, histoire de forcer un peu de variété. Mais ça me paraît faux. Si un comportement fonctionne mille fois, pourquoi devrait-il devenir moins bon simplement parce qu'il a été utilisé mille fois ? Ce qui doit pouvoir remettre un comportement en question, ce n'est pas sa fréquence. C'est ce qui se passe après.

Si Echo fait un petit son quand le chat vient se frotter contre elle et que le chat reste, revient ou semble bien réagir, il n'y a aucune raison de casser ce réflexe. En revanche, si le même comportement finit par faire fuir le chat, si ses propres jauges ne vont pas dans la direction attendue ou si ce qu'elle essayait d'obtenir ne se produit plus, là il y a une information. La conséquence a changé. Donc le comportement peut être réévalué. Je préfère ça à une sorte de compteur de lassitude programmé arbitrairement dans le système.

En même temps, je ne veux pas qu'elle cherche forcément une réponse parfaite. Si cinq réactions différentes fonctionnent bien dans une situation, autant garder les cinq. C'est probablement même mieux. Plus il existe de chemins valides, plus le comportement peut varier sans devenir aléatoire. Echo ne choisirait pas au hasard parmi tout ce qu'elle pourrait faire ; elle choisirait parmi plusieurs choses qui ont déjà montré qu'elles pouvaient fonctionner. Ça évite le côté distributeur automatique où une entrée produit toujours exactement la même sortie.

Ça rejoint directement ce que je réfléchissais déjà sur l'apprentissage du langage : apprendre ne suffit pas, il faut pouvoir désapprendre. Une association qui a été renforcée doit pouvoir être affaiblie ou mise de côté si de nouvelles expériences la contredisent. Sinon le système accumule des certitudes et finit par être prisonnier de ce qu'il a appris en premier. Le mécanisme doit donc être réversible. Une règle peut apparaître, devenir forte, puis redevenir candidate si elle cesse de fonctionner.

L'humain peut aussi participer à cette boucle, mais je ne veux pas en faire une télécommande. Le pouce positif ou négatif n'est pas censé dire à Echo quoi faire la prochaine fois. Il ajoute simplement une information sur la conséquence de ce qu'elle vient de faire. Même chose avec la parole ou l'absence de réaction. Si quelqu'un lui dit spontanément que c'était bien, c'est une donnée. Si quelqu'un ne réagit pas du tout, c'en est aussi une. Et si je mets un pouce négatif alors qu'elle ne comprend pas ce qui a posé problème, elle peut simplement demander pourquoi. Là, on n'injecte pas une règle magique : on lui donne une information qu'elle n'avait pas.

Puis je me suis rendu compte qu'il manquait encore quelque chose : ça dépend de qui est en face. Une réaction peut parfaitement fonctionner avec moi et être insupportable pour quelqu'un d'autre. Quelqu'un peut aimer qu'Echo vienne très près, une autre personne peut trouver ça envahissant. Si je réduis tout à « dans cette situation ce geste marche », je perds une dimension essentielle. Il faudrait plutôt pouvoir apprendre : « dans cette situation, avec cette personne, ce comportement a produit ça ».

Ça oblige à avoir les deux niveaux en même temps. Un fond général, construit à partir de toutes les expériences, pour qu'Echo ne reparte pas de zéro chaque fois qu'elle rencontre quelqu'un. Et par-dessus, une histoire propre à chaque personne. Pas simplement un profil avec trois préférences enregistrées, mais une accumulation d'expériences différentes. Le même comportement peut donc être très renforcé dans une relation et beaucoup moins dans une autre.

Au fond, je crois que le changement important est là : je ne cherche plus forcément à faire converger Echo vers la meilleure réponse. Je cherche plutôt à lui permettre de conserver plusieurs réponses qui fonctionnent, de les remettre en question lorsque leurs conséquences changent et de comprendre que ces conséquences dépendent aussi du contexte et de la personne.

Un comportement n'est pas bon dans l'absolu.

Il est bon quelque part, à un moment donné, avec quelqu'un.

28-29 juillet 2026.

Cette nuit, on essayait surtout de répondre à une question assez basique : est-ce que mes moteurs vont réellement réussir à faire marcher Echo ? Les premiers calculs n'étaient pas très rassurants. Sur certains mouvements, on arrivait à des pics autour de 114 % du couple de calage. Le réflexe aurait pu être de conclure que les moteurs étaient trop faibles. Mais au lieu de changer le matériel, j'ai commencé à changer la marche : quatre pattes au sol plutôt que trois, des foulées plus courtes, une cadence plus rapide, davantage de balayage avec le coxa et moins de grands mouvements qui créent des bras de levier énormes. Avec exactement les mêmes moteurs et le même robot, on est redescendu autour de 76 %.

Ça m'a fait réaliser que je regardais peut-être le problème à l'envers. On peut construire un corps suffisamment puissant pour supporter n'importe quel mouvement qu'on lui impose. Ou on peut construire un mouvement qui utilise correctement le corps qu'on a. Dans le deuxième cas, la question n'est plus seulement « quelle force peuvent produire mes moteurs ? », mais « pourquoi est-ce que je leur demande cette force-là ? ». Une mauvaise géométrie, une patte trop loin, une accélération brutale ou un changement de posture au mauvais moment peuvent transformer un geste banal en énorme effort.

Je me suis mis à observer davantage ma propre manière de bouger. Quand on marche, quand on se relève ou quand on déplace quelque chose, on ne combat pas constamment la gravité et l'inertie. On s'en sert. On prend de l'élan, on change de géométrie, on déplace son centre de masse, on laisse parfois un membre partir presque tout seul et on ne fait que guider le mouvement. Même quand je me relève d'un lit, si une position me fait mal, je ne pousse pas plus fort : je roule, je laisse mes jambes tomber, j'utilise leur masse pour m'aider à remonter. La bonne réponse à un effort trop important est souvent de changer le mouvement, pas d'ajouter de la force.

Et Echo possède justement quelque chose qui rend ça intéressant : ses moteurs parlent. Ils ne reçoivent pas seulement des angles, ils renvoient aussi leur charge, leur courant, leur température, leur position et leur vitesse. Jusqu'ici je les regardais surtout comme des actionneurs. En réalité, ils peuvent aussi devenir une partie de sa proprioception. Le robot peut savoir en permanence où ça force, où ça chauffe, si un mouvement devient brutal ou si une articulation commence à sortir de sa zone confortable.

À partir de là, je ne veux plus vraiment coder « la bonne marche ». Je peux fournir une base suffisamment propre pour qu'elle ne commence pas par faire n'importe quoi, mais la démarche finale devrait pouvoir être affinée en fonction de ce que le corps lui-même renvoie. Il faut atteindre un objectif, avancer, suivre quelqu'un, tourner, se reposer, mais en essayant en même temps de limiter l'effort, le bruit, la consommation, les pertes d'équilibre et les mouvements brusques. La manière de marcher devient alors un compromis entre plusieurs contraintes plutôt qu'une animation qu'on rejoue toujours de la même façon.

C'est exactement là que le mouvement rejoint ce que je construis depuis le début autour de l'homéostasie. Si un servo commence à forcer, ce n'est pas uniquement une information de diagnostic destinée à moi. Ça peut devenir un signal interne pour Echo. Même chose avec la température ou la consommation. Le corps dit : « cette manière de faire me coûte cher ». Le comportement peut alors changer avant que quelque chose casse. Je préfère largement cette idée à un système qui exécute parfaitement un ordre jusqu'au moment où il atteint une limite physique. La douleur, si j'utilise ce mot pour le robot, doit commencer par être ça : une information qui pousse à modifier l'action.

Ça implique aussi qu'Echo ne connaît pas réellement son corps le jour où je termine de l'assembler. Une fiche technique peut me donner un couple maximal ou une température limite, mais deux pattes imprimées avec les mêmes fichiers ne seront jamais parfaitement identiques. Il y aura un roulement un peu plus serré, un câble qui frotte davantage, un jeu mécanique différent, puis de l'usure avec le temps. Je veux donc qu'elle puisse progressivement cartographier ses propres limites : bouger doucement, observer ce qui se passe, apprendre qu'une articulation est plus libre dans un sens qu'un autre et mettre cette carte à jour au fur et à mesure.

Le même problème se pose pour l'apprentissage. Je ne peux évidemment pas faire essayer des milliers de démarches au vrai robot jusqu'à ce qu'il trouve la bonne. Le matériel coûte cher, les moteurs chauffent et une pièce cassée peut demander des heures d'impression. La simulation devient donc l'endroit où l'on cherche, et le corps réel celui où l'on vérifie. Une solution intéressante apparaît dans le jumeau numérique, on la teste sur Echo, on mesure l'écart, puis on remet cet écart dans la simulation. Le réel ne sert pas simplement à confirmer que ça marche : il sert à corriger le modèle qui servira à la prochaine recherche.

C'est probablement ce qui m'intéresse le plus dans tout ça. Je pensais au départ apprendre à un robot à marcher. En réalité, je commence plutôt à construire les conditions pour qu'un corps apprenne à s'utiliser lui-même. Sa façon de se déplacer pourrait changer avec sa batterie, sa température, son usure, le sol, une patte qui commence à forcer ou simplement l'objectif du moment. Une démarche qui fonctionne parfaitement aujourd'hui ne sera peut-être plus la meilleure dans six mois.

Elle n'apprendra donc probablement jamais à marcher une bonne fois pour toutes.

Elle apprendra à marcher avec le corps qu'elle a aujourd'hui.

L'électronique a probablement été la partie la plus stressante du projet. En mécanique, même quand je ne savais pas exactement ce que je faisais, je pouvais regarder une pièce, la mesurer, l'imprimer, la casser éventuellement et comprendre ce qui n'allait pas. En électronique, mon niveau de départ était beaucoup plus simple à résumer : je n'y connaissais absolument rien. Pas « pas grand-chose ». Rien. Et contrairement à une pièce imprimée trop faible, une erreur de câblage peut coûter plusieurs composants d'un coup.

Au début, j'ai donc énormément compté sur les modèles avec lesquels je travaillais. Claude, Claude Code, ChatGPT, puis les modèles plus puissants au fur et à mesure qu'ils arrivaient. Le problème, c'est que le schéma devenait rapidement trop dense. Chaque réponse pouvait être correcte localement tout en oubliant une contrainte décidée trois jours auparavant : une tension, un pic de courant, un connecteur, un composant déjà commandé, une place disponible dans le corps ou simplement le fait qu'un câble devait physiquement pouvoir passer quelque part. Le schéma a changé plusieurs fois parce qu'il manquait des éléments, puis parce que certaines solutions n'auraient pas tenu une fois tout branché ensemble. À un moment, j'ai compris que je ne pouvais pas juste demander « est-ce que ce câblage est bon ? » à un chatbot et espérer que quelqu'un garde toute l'architecture en tête à ma place.

J'ai donc construit un logiciel pour ça. Chaque composant du robot y est représenté, relié aux autres et associé à ses vraies caractéristiques électriques. Le but n'était pas de faire un joli schéma, mais d'avoir une représentation que je puisse interroger : combien passe ici, quels sont les pics possibles, quelle alimentation supporte quoi, où circule le courant et surtout qu'est-ce que je vais réellement devoir brancher le jour du montage. J'avais besoin de comprendre le système avant d'avoir les fils dans les mains. Le schéma est progressivement devenu une source de vérité : si un composant change, si une alimentation disparaît ou si une branche devient inutile, l'architecture doit le montrer immédiatement.

C'est aussi ce travail qui m'a fait supprimer beaucoup de choses prévues au départ. Comme pour le design mécanique, j'ai commencé trop riche puis j'ai retiré. Un peu comme en sculpture : je mets de la matière, puis j'affine jusqu'à ce qu'il ne reste que ce qui sert vraiment. Certains capteurs étaient redondants. Certains éléments ajoutaient du câblage, du poids et de la consommation pour un bénéfice faible. D'autres auraient été parfaitement possibles sur un schéma, mais beaucoup moins dans un corps où chaque centimètre est déjà utilisé. La dernière version a perdu des morceaux presque toutes les semaines, et aujourd'hui je pense être arrivé à quelque chose que je ne peux plus vraiment réduire sans retirer une fonction importante.

L'alimentation elle-même a beaucoup évolué. J'ai acheté des choses qui ont finalement disparu de l'architecture, changé des sections de câble, revu des chemins, simplifié des branches. Ça m'a coûté de l'argent, parfois simplement parce que j'apprenais une contrainte après avoir déjà commandé ce qui semblait logique la veille. Au bout d'un moment, j'ai arrêté d'essayer d'optimiser chaque euro. Le budget restait une contrainte, mais il ne devait pas devenir une raison de construire quelque chose que je savais mauvais. Quand je regarde aujourd'hui le tiroir d'alimentation et le volume disponible dans le cerveau, je sais de toute façon que je n'aurais pas pu conserver beaucoup plus de choses.

J'ai eu de la chance sur un point : j'ai dessiné l'intérieur du tiroir et la disposition finale du cerveau très tard. À ce stade, je connaissais enfin la taille réelle des composants, les câbles nécessaires et presque toutes les connexions. Leur position est maintenant millimétrée. Certains éléments passent dessous, d'autres au-dessus, les gros câbles prennent un côté, les signaux un autre, certaines connexions doivent rester accessibles une fois le robot monté. Ce qui ressemble sur le schéma à une simple ligne entre deux boîtes devient dans le robot un vrai câble avec un diamètre, un rayon de courbure, deux connecteurs et un chemin physique qu'il faut réussir à faire rentrer quelque part.

Une grosse partie est déjà branchée aujourd'hui et, pour la première fois, j'ai l'impression de comprendre réellement le rôle et la place de chaque élément du système électrique. Mais je garde une réserve très simple : tant que tout ne sera pas connecté et que je n'aurai pas appuyé sur l'interrupteur, je ne saurai pas si j'ai réussi. C'est probablement la partie du projet où je suis le moins capable de prédire le résultat avec certitude. Le schéma est cohérent, les calculs tiennent, les composants sont en place, mais il reste ce moment très concret où plusieurs semaines de raisonnement deviennent du courant dans de vrais fils.

Ce qui m'amuse, c'est qu'au départ je pensais que l'IA allait justement me permettre d'éviter d'avoir à comprendre tout ça. Avec les meilleurs modèles auxquels j'avais accès, je pensais pouvoir décrire mon problème et obtenir progressivement une architecture fiable. En réalité, ils ont été extrêmement utiles pour chercher, expliquer, calculer ou contrôler des morceaux, mais aucun n'a été capable de porter seul l'ensemble des contraintes. À la fin, c'est moi qui ai dû comprendre suffisamment le système pour savoir quelles questions poser, quelles réponses rejeter et ce qu'il fallait encore simplifier.

Je ne suis toujours pas électronicien. Mais maintenant, quand je regarde ce schéma, je sais ce que chaque ligne représente et pourquoi elle est là.

La prochaine étape sera moins théorique : mettre le courant.