Machikoba no Techo

Seul celui qui sait écrire le code en voit le danger.

Septembre. La saison de pêche nocturne au calmar pointe-épée (Kensaki) — l’un des signes de l’été chez nous — touche à sa fin. Ceux qui sortaient le bateau de nuit se tournent peu à peu vers ce que nous appelons le budouika, le « calmar raisin ». Nous vous remercions sincèrement de votre fidélité.

Et septembre, c’est aussi autre chose : la saison où les calmars maori (Aori) se rassemblent. À mesure que la température de l’eau redescend de son pic estival, les poissons fourrage s’animent d’un coup. Les calmars suivent le mouvement, et des bancs de jeunes calmars gagnent les petits fonds — le long des digues, les cannes plient dans les courtes fenêtres de l’aube et du crépuscule. C’est peut-être le moment le plus enthousiasmant de l’année. Pour qui songe à se mettre à l’eging, c’est aussi la saison la plus indulgente pour débuter.

Ce mois-ci, laissez-moi vous parler à nouveau des coulisses de l’atelier. Le mois dernier, j’écrivais que, même quand c’est l’IA qui écrit, s’arrêter pour vérifier reste un travail d’humain. Voici la suite. Depuis un an, à force d’utiliser intensivement le « vibe coding » sur le terrain, j’en ai ressenti la puissance et, exactement à la même mesure, le danger. Et je me suis heurté à la question que beaucoup, je crois, se posent aujourd’hui : peut-on amener sur le terrain du code produit par une IA comme une boîte noire, sans regarder à l’intérieur ?

■ On dit « je voudrais quelque chose comme ça », et ça marche

Le vibe coding consiste à faire l’impasse sur le cahier des charges détaillé : on décrit en langage ordinaire ce que l’on veut, on laisse l’IA l’écrire, et on récupère quelque chose qui fonctionne. Depuis un an, nous avons construit ainsi quantité de petits outils pour l’atelier. Ou plutôt : nous générons des outils comme nous respirons.

Disons-le d’emblée : c’est réellement puissant. Ce que l’on remisait en se disant « j’aimerais bien, mais je n’ai pas le temps de me pencher dessus » tourne désormais le jour même où l’idée vous vient. Ce qui aurait commencé par un devis d’une société extérieure prend forme pendant une pause déjeuner. Pour un petit atelier comme le nôtre, il n’y a pas de changement plus bienvenu.

■ Que ça tourne et que ce soit juste sont deux choses différentes

Et pourtant, le plus effrayant cette année, c’est justement que ça tourne. Ce qui sort fonctionne, la plupart du temps. L’écran est propre, les chiffres s’affichent. Comme ça tourne, on ne peut pas dire de l’extérieur si c’est sain ou dangereux.

Un arrondi légèrement différent à un endroit. Un comportement indéfini quand une valeur arrive hors de la plage attendue. Des erreurs avalées en silence, si bien que tout se poursuit comme si de rien n’était. Rien de tout cela ne se voit en fixant un écran qui fonctionne. Les seuls à le voir sont ceux qui ont écrit ce genre de code eux-mêmes et s’y sont brûlé les doigts.

Au bout du compte, on n’est tranquille qu’après avoir suivi la totalité du code produit. Le temps que l’on croyait gagner en déléguant revient tel quel sous forme de lecture. Le seuil pour construire s’est effondré ; celui pour repérer le danger, lui, n’a pas bougé. Cette asymétrie est ce que j’ai appris de plus clair cette année. Dans nos termes à nous, ce serait comme se tenir devant un centre d’usinage à 40 millions de yens et dire « ça a tourné, donc c’est bon ». Cela n’est jamais permis.

■ Dans un petit atelier, il n’y a pas de pièce idéale

Est-ce donc un outil inutilisable ? Pas du tout. Sur certaines parties de notre travail, il convient mieux que tout. Mais pour l’expliquer, il me faut faire un détour par la réalité d’un petit atelier.

Pour ma part, je fais couramment quelque chose d’un peu singulier : je génère du NC — le langage machine — par vibe coding. Pour écrire le code qui produit du NC, c’est Python qui est choisi automatiquement la plupart du temps ; dans la majorité des cas, je le remplace par Ruby. C’est ma manière de faire.

Les machines-outils NC modernes sont d’une précision extraordinaire. Donnez-leur une matière idéale, une forme idéale et des cotes idéales, elles vous sortiront une finition à couper le souffle. Mais dans notre atelier, ces conditions idéales ne sont presque jamais réunies. Il faut faire avec ce que l’on a sous la main. La matière est irrégulière ; la forme et la taille diffèrent à chaque fois. La prémisse même du « conforme au plan » n’est pas devant nous.

J’appelle cela « l’esprit du faire avec ce que l’on a ». C’est la force d’un petit atelier et notre fierté, mais du point de vue de celui qui écrit un programme, c’est une vraie plaie. Comme les cotes changent chaque fois, on ne peut pas écrire une procédure avec des nombres codés en dur. Au lieu de « usiner cette forme à cette cote », il faut réécrire : « mesurer ce que l’on a devant soi et déduire l’usinage de cette valeur ». Autrement dit, il faut élever considérablement le niveau d’abstraction. C’est la partie la plus difficile de la programmation dans un petit atelier.

■ Idéal pour s’ajuster à la pièce, et pour la rétro-ingénierie

Et cette façon de travailler — s’ajuster à la pièce réelle — ressemble au vibe coding à un degré surprenant. Il n’y a pas de cahier des charges parfait au départ ; on se rapproche de l’objet que l’on a devant soi, on usine et on présente, on présente et on usine encore. Lui faire produire quelque chose qui tourne, montrer du doigt ce qui ne va pas, faire corriger, et réessayer. Comme on peut mettre les mains dans le cambouis avant que la spécification soit arrêtée, cela colle remarquablement bien à un atelier du « faire avec ce que l’on a ».

Surtout, le vibe coding complète bien la partie la plus difficile : élever le niveau d’abstraction. Montrez-lui une version aux valeurs codées en dur et demandez-lui quelque chose qui fonctionne encore quand les cotes changent : il repère ce qui doit devenir une variable. La part de la généralisation qui prenait des jours à un humain — trouver l’angle d’attaque — est balayée d’un coup. C’est exactement la capacité qui manquait à notre atelier du « faire avec ce que l’on a ».

L’autre bon terrain, c’est la rétro-ingénierie : sonder de l’extérieur un mécanisme que l’on ne comprend pas et reconstituer la logique qui le sous-tend. Pour lire des formats de données inconnus, ou du code long écrit il y a longtemps par quelqu’un d’autre, et comprendre ce qu’il fait, c’est étonnamment fiable. C’est un terrain que nous ne comprenions pas au départ : une erreur y coûte peu. Une fois l’angle trouvé, un humain peut vérifier le reste.

Un exemple proche de nous : les programmes NC que produisent les constructeurs de machines eux-mêmes. Honnêtement, je ne les aime guère. Pas d’indentation, des commentaires inutiles, aucun moyen de lire ce qu’ils font. Un programme que l’on ne peut pas lire est un programme que l’on ne peut pas arrêter pour vérifier. L’IA comble ce manque. Demandez-lui d’ajouter indentation et commentaires parce que le code est difficile à lire, et il revient exactement ainsi. Dites que l’abstraction est trop basse et demandez un découpage en sous-programmes, et elle divise le code en blocs qui ont un sens. Le même comportement, mis dans une forme lisible par un humain — c’est peut-être l’usage auquel nous recourons le plus souvent en ce moment.

Ce qui nous gêne le plus, c’est que nulle part n’est écrit sur quelles variables un sous-programme a des effets de bord. On l’appelle, et quelque chose change. Mais ce qui change reste inconnu tant que l’on n’a pas tout lu. Faites lire cela à l’IA et demandez-lui de lister, dans un commentaire en tête, les variables écrites à l’intérieur — elle les extrait. C’est un travail sur lequel un humain passait une demi-journée.

Un exemple concret. Nous faisons souvent retravailler par l’IA les programmes NC de notre machine d’électroérosion à fil. C’est si commode que j’en ai failli saigner du nez. Dans le monde du NC, même si tout le monde parle de « G-code », chaque constructeur a ses habitudes d’écriture — des dialectes, en somme. Ce modèle s’écrit de cette manière ; celui-là exige cette commande. Pour un humain, cela veut dire comparer les manuels et apprendre sur le terrain.

L’IA, elle, lit cela dans le style du programme qu’on lui remet. Elle sent à quelles conventions le code obéit, et écrit les ajouts dans les mêmes conventions. Donnez-lui en plus le manuel du constructeur, et elle se met à utiliser, sans qu’on le lui demande, des macros propres à ce modèle. Elle lit que « cette machine offre cette instruction » et l’écrit sans sourciller. Que ce savoir tacite, accumulé dans les ateliers pendant de longues années, puisse être extrait ainsi — franchement, cela m’a glacé.

Mais nous n’envoyons jamais tel quel à la machine un programme produit de cette façon. Nous le déboguons. Cela passe toujours sur la machine réelle, ligne à ligne, avec les valeurs des variables et le déplacement du fil vérifiés à l’œil. C’est là que le M01 (arrêt optionnel) dont je parlais le mois dernier gagne son salaire. Aussi belle que paraisse la copie, si l’on n’a pas la capacité de déboguer sur la machine réelle, on ne peut pas utiliser cet outil. Ou plutôt : je crois qu’on ne le doit pas. Utilisé comme un outil à produire des bonnes réponses, il est dangereux ; utilisé comme un outil pour trouver l’angle d’attaque, il est redoutable. Mais confirmer cet angle est toujours du côté de l’humain.

■ Faut-il en faire une boîte noire ?

Ce qui nous ramène à la question du début. Peut-on amener sur le terrain du code produit par une IA sans regarder à l’intérieur ? Honnêtement, nous distinguons les cas où c’est permis de ceux où cela ne l’est pas. Pour l’instant, la ligne que nous traçons dépend de l’endroit où le code se trouve. Là où une erreur peut être repérée et corrigée après coup, là où l’on ne perd que du temps, nous l’utilisons sans tout relire. Là où une machine bouge, où des cotes sont fixées et où de la matière est consommée — là où il n’y a pas de seconde tentative — un humain lit tout, si long soit le détour.

Le point délicat, c’est que la boîte noire n’est pas seulement la part écrite par l’IA. Le logiciel d’aujourd’hui se construit en appelant un grand nombre de composants — des bibliothèques publiées par quelqu’un, quelque part, sur GitHub ou ailleurs. Il y a eu tout récemment un incident de grande ampleur dans le monde JavaScript. (De fait, les portes dérobées semblent revenir presque chaque jour.) Une bibliothèque sur laquelle repose quantité de logiciels a été détournée et s’est vu greffer un mécanisme qui s’exécutait à l’installation et se propageait de lui-même au paquet suivant. Des centaines de paquets semblent avoir été contaminés en quelques heures. Peu de temps auparavant, il y avait eu des cas d’interception en cours de route pour substituer une destination de paiement — autrement dit, une falsification de la partie qui manipule l’argent.

Demandez à une IA « quelque chose comme ça » et elle choisira et intégrera naturellement des composants commodes. Si elle est rapide, c’est en partie parce qu’elle n’écrit pas ces composants elle-même. Ce que nous recevons a donc une double structure : à l’intérieur de la boîte écrite par l’IA, elle appelle la boîte de quelqu’un d’autre. Aucun artisan n’usine une matière sans savoir ce qui y est mélangé. Je pense qu’il en va de même pour le logiciel.

Cette question — peut-on faire confiance à la boîte d’autrui ? — n’est pas nouvelle. Au milieu des années 1990, D. J. Bernstein, l’auteur du programme de transfert de courrier qmail (nous l’avons nous-mêmes fait tourner il y a plus de dix ans), ne faisait même pas confiance à la bibliothèque standard du C — ces composants livrés avec le langage, que tout le monde utilise sans se poser de question. Il a expliqué dans ses notes de conception qu’il avait largement renoncé à la bibliothèque standard, et remplacé les parties où les accidents arrivent le plus facilement, comme la manipulation des chaînes et la gestion de la mémoire, par de petits composants à lui, développés au fil des années. Il n’est pas allé jusqu’à reconstruire le système d’exploitation, mais sur un point il a été intraitable : mettre les parties dangereuses sous son propre contrôle.

Ce qui traverse qmail, c’est l’idée de réduire autant que possible ce à quoi il faut faire confiance. Au-delà d’écrire ses propres composants, il a divisé l’intérieur du programme en petites parties selon leur rôle, conçues de sorte que même ses propres parties ne se font pas confiance entre elles. Si l’une d’elles est détournée, elle ne peut pas aller plus loin. Quelqu’un avait pensé cela il y a trente ans. Bien sûr, nous ne pouvons pas l’imiter en écrivant nous-mêmes toutes les bibliothèques. Mais l’idée — tracer ses frontières en partant du principe que des choses non fiables vont s’y mêler — se transpose telle quelle à aujourd’hui.

Et ce qui fait peur, c’est que si la boîte est trop grosse, il n’y a plus de retour possible. Prenez comme un seul gros bloc quelque chose dont vous ne comprenez pas le fond, et vous ne pourrez plus l’isoler le jour où il arrivera quelque chose. La parade doit donc être prise dès la conception : garder une forme que l’on peut toujours remplacer. Cette partie-ci peut être échangée contre une autre ; retirez ce composant et l’ensemble tourne encore. Construisez ainsi et, le jour où il arrive quelque chose, vous pourrez ne jeter que cette boîte-là.

Ce que cela demande, c’est une compétence de conception au sens objet. Qu’est-ce que l’on traite comme une unité, qu’expose-t-on vers l’extérieur, quelle part de l’intérieur cache-t-on ? Où trace-t-on la frontière ? Ce que l’on tenait naguère pour « écrire proprement » est devenu une nécessité pratique pour ne pas faire entrer chez soi des choses dangereuses. C’est précisément parce que l’IA écrit le contenu que la capacité de décider la frontière est ce dont on a besoin.

Et cette ligne se déplace si on la laisse faire. Après une série de réussites, on veut inévitablement agrandir la boîte. Pire : la capacité à repérer le danger s’émousse exactement en proportion de ce que l’on écrit soi-même en moins. Cet outil a cette propriété : plus on l’utilise, moins on voit à travers. La ligne doit donc être retracée du côté de l’humain, pas du côté de l’outil.

■ L’ingénierie des systèmes, plus que le codage

En repensant à cette année, c’est là que mon impression a le plus changé : ce qui sera vraiment indispensable désormais, ce n’est pas le codage lui-même, mais l’ingénierie des systèmes.

Décider ce que l’on construit et ce que l’on ne construit pas. Tracer la ligne entre ce que l’on délègue à la machine et l’endroit où le jugement humain reprend la main. Préparer, avant de construire, la façon dont on reviendra en arrière quand cela cessera de fonctionner. Décider où résident les données et qui en est responsable. Si maligne qu’elle devienne, l’IA ne décidera pas cela à votre place — parce que décider cela suppose de connaître le travail de l’atelier.

À mesure que le temps passé à écrire du code diminuait, nous avons commencé à en consacrer à la conception, à l’exploitation, et au jugement du moment où il faut s’arrêter. Ironiquement, la disparition de l’effort d’écriture a rendu bien plus visible le poids du travail qui précède l’écriture.

■ Tous les procédés en interne, à Arita

Dans une petite entreprise, celui qui a construit l’outil s’en sert, et quand il tombe en panne, c’est le même qui le répare. Alors « sait-on le construire ? » compte bien moins que « est-ce dans les limites de ce que nous pouvons entretenir nous-mêmes ? » S’en tenir à une échelle que l’on peut rétablir par ses propres moyens le jour où cela s’arrête. Ce n’est pas spectaculaire, mais je crois que c’est cela, la DX à sa propre mesure.

C’est exactement la même histoire que la fabrication des egi. Les prototypes se montent bien plus vite qu’avant. Mais l’étape qui consiste à les confirmer en mer ne peut être raccourcie par aucun moyen. Ce qui décide du bon et du mauvais, au bout du compte, c’est toujours la mer. Plus nous construisons vite, plus nous mettons de temps dans la confirmation — c’est l’usage que nous avons choisi.

Dans une petite ville de province — Arita, dans la préfecture de Saga, au Japon — nous continuons de fabriquer nos egi en interne à tous les stades : conception, usinage des moules, production en série et vente. Voilà ce à quoi le mois d’août m’a fait réfléchir. Des composants écrits par quelqu’un, quelque part dans le monde, tournent à l’intérieur de notre propre atelier, et une IA lit les dialectes de nos machines. Au milieu de tout cela, qu’est-ce qui doit rester entre des mains humaines ? La réponse n’est pas même à moitié trouvée, mais je compte bien ne pas cesser d’y penser.

■ Prendre la mer ce mois-ci

Septembre nous apporte une série de nouveaux coloris et de nouveaux produits. Akazamurai Meteor Glow Orange est un orange qui change de visage entre la lueur phosphorescente et l’éclairage UV ; sa sortie est prévue ce mois-ci. Le JetChaser Purple Edition, destiné au tip-run du bord, sort également ce mois-ci. S’y ajoutent le JetChaser size 3.0 et size 3.1, qui passent en vente générale, avec des expéditions prévues fin septembre.

Cette année marque aussi la quinzième année depuis la naissance du coloris « Akazamurai » de l’EgiSharp. À la fin du mois dernier, nous avons diffusé les images d’un coloris commémorant ce quinzième anniversaire. Qu’il continue d’être choisi depuis quinze ans n’est pas notre propre assurance — c’est la réponse donnée par ceux qui l’ont utilisé.

Si intelligents que deviennent les outils, celui qui juge à la fin est un humain, et ce qui décide du bon et du mauvais, c’est la mer. Nous garderons cela en tête et continuerons de fabriquer, un pas après l’autre. Merci encore de votre soutien ce mois-ci.

Septembre 2026
KeyStone Corporation
Nobuhide Kanagawa, Président-directeur général