- ▸ Quand l'apprenti laisse filer le balai
- ▸ La thèse : un outil utile, un risque intime
- ▸ D'où vient l'« apprenti sorcier » : généalogie d'un avertissement
- ▸ _hyperscript : un parseur à contre-courant, terrain d'essai idéal
Un développeur greffe un assistant logiciel à son flux de travail, puis perd peu à peu la capacité de réparer ce qu’il construit : c’est le scénario que Carson Gross, créateur de htmx, dissèque dans un essai publié le 29 juin 2026. Tout tient en une question — où finit l’outil, où commence l’atrophie ? Méthode : une anomalie réelle, disséquée pas à pas.
Points clés 1. Ambivalence assumée : selon Carson Gross, l’assistant logiciel est un outil utile mais porteur d’un « ternissement intellectuel » lent côté développeur, et de coûts environnementaux côté collectif. 2. Le motif de l’« apprenti sorcier » sert d’avertissement central : déléguer la compréhension, c’est risquer de ne plus savoir réparer les systèmes que l’on bâtit. 3. Le terrain d’essai n’est pas anodin : _hyperscript est un langage interprété expérimental dont le parseur colocalise sa logique sur les éléments grammaticaux, avec une grammaire définie dynamiquement. 4. L’incident pivot : après la version 0.9.91, l’expression
fetch ... as JSONcesse de se parser correctement, le mot-cléas JSONse liant trop étroitement à l’expression d’URL. 5. La leçon : sur un bug de précédence syntaxique, l’assistance automatisée éclaire sans trancher — c’est le développeur qui doit garder la main sur l’arbre de décision.
Quand l’apprenti laisse filer le balai
L’histoire commence par un message d’utilisateur, presque banal dans la vie d’un mainteneur de projet open source. Après une mise à jour, un développeur signale que son code, jusque-là fonctionnel, ne s’exécute plus comme prévu. L’expression incriminée, reproduite dans l’essai publié sur htmx.org, mêle un gabarit d’URL côté serveur et une conversion de réponse : fetch ` as JSON`. Avant la version 0.9.91, elle récupérait des données et les convertissait. Après, plus rien. Le récit de Carson Gross part de ce signal faible — un rapport de régression — pour interroger non pas la machine, mais la posture du développeur face à l’assistance automatisée. La scène est minuscule. Sa portée, beaucoup moins.}?symbol=${symbol
La thèse : un outil utile, un risque intime
De cette anecdote, Carson Gross tire une position qui refuse les deux camps habituels. L’assistant logiciel n’est ni une calamité ni un sauveur ; il est un instrument dont l’usage non critique érode, lentement, la compétence de celui qui s’y appuie. L’auteur se décrit lui-même comme « généralement ambivalent » envers ces outils : il en reconnaît la puissance tout en pointant un double risque, individuel — le ternissement intellectuel — et collectif, notamment environnemental. Sa thèse n’oppose donc pas l’humain à la machine. Elle interroge le point de bascule où l’aide devient dépendance, où l’on cesse de comprendre ce que l’on déploie. Le bug de _hyperscript devient alors un cas d’école, choisi précisément parce qu’il résiste aux réponses faciles.
D’où vient l’« apprenti sorcier » : généalogie d’un avertissement
Pour saisir la mise en garde, il faut remonter au motif que Carson Gross convoque : celui de l’apprenti sorcier. La référence n’a rien d’anecdotique ; elle structure tout l’essai. Le personnage naît en 1797 sous la plume de Goethe, dans la ballade Der Zauberlehrling : un apprenti, en l’absence de son maître, anime un balai pour porter l’eau à sa place, puis se révèle incapable d’arrêter le sortilège qu’il a déclenché. Le compositeur Paul Dukas en tire en 1897 un poème symphonique, popularisé pour le grand public en 1940 par le segment de Fantasia où Mickey Mouse incarne l’apprenti débordé. Trois œuvres, un siècle et demi, une seule leçon : maîtriser le déclenchement d’un processus n’équivaut pas à en maîtriser l’arrêt ni les conséquences.
Transposé au développement logiciel, le motif change de cible. L’eau qui déborde, ce ne sont plus des seaux, mais des lignes de code générées sans que le développeur sache, au juste, ce qu’elles font. Le danger pointé par Carson Gross n’est pas que l’outil produise un système défaillant ; c’est que l’ingénieur, ayant délégué la compréhension, se retrouve incapable de traiter correctement les problèmes des systèmes qu’il a pourtant signés. La compétence ne s’évapore pas d’un coup. Elle s’effrite, à chaque délégation non interrogée, jusqu’au jour où un bug exige une connaissance que l’on n’a plus.
Ce cadrage historique éclaire le choix du terrain d’expérimentation. Car pour mettre l’avertissement à l’épreuve, encore faut-il un système suffisamment singulier pour que l’assistance automatisée ne puisse pas se contenter de recracher des schémas appris ailleurs. C’est tout l’intérêt de _hyperscript.
_hyperscript : un parseur à contre-courant, terrain d’essai idéal
_hyperscript, projet jumeau de htmx également porté par Carson Gross, est un langage de script interprété, alternatif aux approches dominantes. Sa syntaxe se veut proche de l’anglais parlé, comme l’illustre une instruction citée dans l’essai : « when $x or $y changes put it into me ». Là où la plupart des langages affichent une grammaire dense et symbolique, _hyperscript assume une lisibilité quasi narrative, pensée pour être embarquée directement dans le balisage. Ce parti pris a un coût : il éloigne le langage des conventions sur lesquelles un assistant automatisé a été massivement entraîné. Et c’est précisément ce décalage qui en fait un banc d’essai pertinent pour mesurer les forces et faiblesses de l’aide automatisée.
L’originalité tient surtout à l’architecture du parseur. D’après la description de l’auteur, _hyperscript colocalise la logique d’analyse syntaxique directement sur les éléments grammaticaux, plutôt que de la centraliser dans une grammaire monolithique. La grammaire elle-même est définie dynamiquement, au fil de l’enregistrement de ces éléments. Cette approche, peu orthodoxe, donne un code de parsing qui se lit comme une succession de petites unités autonomes — chacune sachant comment se reconnaître et quoi exiger ensuite.
Les fragments de code reproduits dans l’essai en donnent la texture. On y croise des appels comme ) || this.requireElement(, où un élément grammatical impose la présence d’un sous-élément obligatoire. On y voit aussi un schéma classique de descente récursive doublé d’une gestion fine des ensembles de suivi : ); try { var url = parser.parseURLOrExpression(); } finally { parser.popFollow(); } if (parser.matchToken(. Cette mécanique — empiler puis dépiler un « follow set » autour d’une analyse d’URL — révèle un parseur qui raisonne explicitement sur ce qu’il a le droit de rencontrer après chaque construction. C’est exactement le genre de subtilité où une précédence mal réglée peut tout faire dérailler.
Le tableau ci-dessous résume pourquoi un tel environnement complique la tâche d’un assistant entraîné sur des langages mainstream.
| Caractéristique | Langage mainstream typique | _hyperscript |
|---|---|---|
| Syntaxe | dense, symbolique | proche de l’anglais parlé |
| Définition de la grammaire | centralisée, statique | dynamique, distribuée |
| Logique de parsing | séparée des éléments | colocalisée sur les éléments grammaticaux |
| Densité dans les corpus d’entraînement | élevée | faible |
| Prévisibilité pour un assistant automatisé | forte | réduite |
Cette singularité posée, reste à examiner ce qui s’est réellement cassé entre deux versions — et comment l’aide automatisée s’est comportée face au problème.
L’incident, disséqué : la version 0.9.91 et le piège de la précédence
Reprenons le fil de l’anomalie. Un utilisateur signale une régression apparue après la version 0.9.91 de _hyperscript : une expression qui combinait une requête réseau et une conversion de format ne fonctionne plus. Le code en cause, tel que rapporté dans l’essai du 29 juin 2026, est fetch ` as JSON`. L’intention du développeur est limpide : aller chercher des données à une URL construite dynamiquement, puis interpréter la réponse comme du JSON. C’est un usage courant, le genre de ligne que l’on écrit sans y penser.}?symbol=${symbol
Le diagnostic posé par l’auteur tient en une nuance de précédence syntaxique. Le mot-clé as JSON, qui demande la conversion du résultat, se lie désormais trop étroitement. Au lieu de s’appliquer à l’ensemble de l’opération de récupération, il s’accroche à un fragment plus restreint de l’expression — vraisemblablement l’expression d’URL ou le gabarit qui la précède. Autrement dit : l’arbre syntaxique produit par le parseur ne correspond plus à la structure mentale du développeur. La machine fait quelque chose de cohérent de son point de vue, mais d’inattendu du point de vue humain. Le code ne « plante » pas par hasard ; il exécute une interprétation valide mais erronée de l’intention.
Tout le problème est là. L’attente de l’utilisateur était une conversion appliquée au résultat de la récupération. Le comportement effectif du parseur, après le changement de la version 0.9.91, était une liaison de as JSON à une portée trop locale. Entre les deux, un fossé de précédence — l’une des classes de bugs les plus retorses du métier, parce qu’elle ne produit aucune erreur franche, seulement un résultat silencieusement faux.
| Aspect | Attente du développeur | Comportement du parseur après 0.9.91 |
|---|---|---|
Portée de as JSON | toute l’opération fetch | fragment restreint (expression d’URL) |
| Effet attendu | conversion de la réponse en JSON | conversion mal positionnée |
| Symptôme | aucun (échec silencieux) | expression non fonctionnelle |
| Cause racine | — | liaison de précédence trop serrée |
C’est dans ce contexte que l’assistance automatisée entre en scène — non pour résoudre seule, mais pour assister un humain qui, lui, garde la responsabilité du verdict. Et l’enseignement principal de l’essai porte précisément sur ce partage des rôles.
Ce que l’incident révèle des limites de l’assistance automatisée
La portée terrain de l’épisode dépasse le seul projet _hyperscript. Un bug de précédence dans un parseur à grammaire dynamique cumule deux propriétés hostiles à l’aide automatisée. D’abord, il exige une compréhension globale de l’arbre syntaxique, pas une retouche locale : corriger la liaison de as JSON sans casser les autres usages de as suppose de raisonner sur l’ensemble des règles de précédence. Ensuite, il s’appuie sur une architecture peu représentée dans les corpus d’entraînement — la colocalisation de la logique de parsing et la définition dynamique de la grammaire éloignent le code des motifs habituels.
Sur ce type de tâche, l’assistant excelle à proposer des pistes, à reformuler une hypothèse, à pointer la portion de code suspecte. Mais il ne peut pas garantir que sa correction respecte l’invariant global du langage, car cet invariant n’est pas écrit quelque part : il vit dans la tête du concepteur et dans l’entrelacs des règles. C’est là que le risque de l’apprenti sorcier devient concret. Un développeur qui accepterait la première suggestion plausible, sans reconstruire mentalement l’arbre syntaxique, déplacerait peut-être le bug ailleurs — en introduisant une régression invisible jusqu’au prochain rapport d’utilisateur.
L’enseignement de Carson Gross n’est donc pas que l’outil échoue. C’est que la valeur de l’échange dépend entièrement de la compétence conservée par l’humain. L’assistant accélère un développeur qui sait déjà lire un parseur ; il égare celui qui a délégué cette lecture. Sur un bug silencieux, où aucune exception ne vient signaler l’erreur, cette différence sépare la correction durable du colmatage hasardeux. Le terrain — un langage de niche, un bug de précédence — agit comme un révélateur : il rend visible ce qui, sur un code banal, resterait masqué par la facilité.
Reste que cadrer l’épisode comme un simple échec de l’outil serait une lecture binaire, exactement celle que l’auteur refuse. Il faut donc tenir les contrepoints.
Contrepoints : ce que l’assistance apporte réellement
Honnêteté de méthode oblige : l’essai n’a pas pour but de disqualifier l’aide automatisée, mais d’en montrer les forces et les faiblesses générales, à partir d’un cas qui penche du côté de la difficulté. Plusieurs arguments sérieux plaident en faveur de l’outil, et il serait malhonnête de les escamoter.
Premier contrepoint : la vitesse d’exploration. Face à un parseur inconnu, un assistant peut résumer une mécanique de descente récursive, expliquer le rôle d’un popFollow ou d’un requireElement, et faire gagner au développeur les minutes d’orientation qui précèdent tout diagnostic. Sur un système que l’on connaît déjà, ce gain est net et sans danger, car la vérification reste à portée.
Deuxième contrepoint : la documentation et la reformulation. L’aide automatisée transforme volontiers une intention floue en hypothèse testable, ou un message d’erreur opaque en piste de recherche. Pour un mainteneur seul devant des dizaines de rapports d’utilisateurs, cette capacité de tri allège une charge cognitive bien réelle.
Troisième contrepoint, plus fondamental : l’outil n’impose pas la dépendance. Dans le cas relaté, Carson Gross indique avoir évité le piège de l’apprenti sorcier au cours de l’interaction — c’est-à-dire avoir gardé la maîtrise de la décision finale. La preuve par l’exemple que l’instrument et l’atrophie ne sont pas synonymes : c’est l’usage non critique, pas l’outil en soi, qui produit le ternissement. Le danger n’est pas technique, il est comportemental. Cette distinction, loin d’être un détail, ouvre la seule voie de sortie praticable.
Perspectives : tenir l’outil sans lui céder le balai
Comment, dès lors, naviguer entre assistance et autonomie technique ? L’essai ne propose pas de protocole rigide, mais sa démonstration trace une ligne de conduite. La première règle découle directement du cas : ne jamais valider une correction que l’on ne pourrait pas reconstruire soi-même. Sur un bug de précédence, cela signifie redessiner l’arbre syntaxique avant d’accepter la moindre modification — l’assistant éclaire le chemin, l’humain reste cartographe.
La seconde règle est une hygiène de la compétence. Puisque le ternissement est lent et silencieux, à l’image du bug lui-même, il appelle une vigilance continue plutôt qu’une décision ponctuelle. Conserver la capacité de réparer suppose de continuer à pratiquer les tâches que l’outil sait faire à notre place — non par nostalgie, mais pour garder la main quand l’assistant atteindra sa limite, comme il l’a fait ici. La question, posée par Carson Gross dès 1797 via Goethe, reste ouverte : saurons-nous toujours arrêter le balai que nous animons ? L’épisode _hyperscript suggère que la réponse ne dépend pas de la machine, mais de ce que nous refuserons de désapprendre.
FAQ : ce que cet exemple change pour les développeurs
L’assistance automatisée est-elle vraiment dangereuse pour les développeurs ?
Le risque principal identifié par Carson Gross n’est pas la panne, mais le « ternissement intellectuel » : une érosion lente de la compétence due à une dépendance non critique. L’outil reste utile ; le danger naît quand on accepte ses propositions sans pouvoir les reconstruire soi-même, jusqu’à ne plus savoir réparer les systèmes que l’on a déployés.
Qu’est-ce qui rend _hyperscript techniquement particulier ?
C’est un langage interprété à syntaxe proche de l’anglais parlé, comme « when $x or $y changes put it into me ». Son parseur colocalise la logique d’analyse sur les éléments grammaticaux, et la grammaire est définie dynamiquement. Cette architecture, peu présente dans les corpus d’entraînement, en fait un terrain exigeant pour toute assistance automatisée.
Pourquoi la version 0.9.91 a-t-elle cassé une expression existante ?
Après cette version, le mot-clé as JSON se liait trop étroitement, s’appliquant à un fragment restreint de l’expression plutôt qu’à toute l’opération fetch. Résultat : un bug de précédence silencieux, sans message d’erreur, où le parseur produisait une interprétation valide mais contraire à l’intention du développeur.
Comment éviter le syndrome de l’apprenti sorcier au quotidien ?
En ne validant aucune correction que l’on ne saurait reconstruire seul, et en continuant à pratiquer les tâches déléguées à l’outil. L’assistant peut orienter le diagnostic ; la décision finale et la compréhension de l’arbre syntaxique doivent rester du ressort de l’humain, sous peine de déplacer les bugs au lieu de les résoudre.
Sources – Carson Gross, « Working With AI: A Concrete Example », htmx.org, 29 juin 2026. – Johann Wolfgang von Goethe, Der Zauberlehrling (ballade), 1797. – Paul Dukas, L’Apprenti sorcier (poème symphonique), 1897. – Walt Disney, Fantasia (segment « The Sorcerer’s Apprentice »), 1940. – Documentation et code source du langage _hyperscript (projet open source porté par Carson Gross). – Pour approfondir : Anthropic et la course aux assistants de code, Comprendre les parseurs à descente récursive, htmx face aux frameworks JavaScript.
