Les premiers travaux d’ingénierie fastidieuse de l’IA, à commencer par TikZ

Deux heures du matin, six heures avant la deadline de soumission du papier. Vous fixez la troisième illustration — un diagramme d’architecture de réseau de neurones — en ajustant pour la énième fois les coordonnées de \draw. De (4.5,3.2) à (4.6,3.1), vous compilez, regardez le PDF, non c’est pas ça, vous revenez en arrière, recompilez. Vous vous rappelez que votre directeur de thèse disait « les figures doivent être belles pour que les reviewers les lisent attentivement », alors vous continuez d’ajuster, l’aiguille pointe vers trois heures.

Tous ceux qui ont écrit un papier LaTeX ont vécu cette scène. TikZ est le standard de facto dans l’écosystème LaTeX pour dessiner des figures académiques, mais c’est un « langage graphique » plutôt qu’un « outil graphique » — l’auteur Till Tantau précise même dans la documentation : TikZ ist kein Zeichenprogramm (TikZ n’est pas un programme de dessin). Vous dessinez avec du code, et chaque ajustement de coordonnée exige une recompilation complète du document. Le monde académique a trimé avec ça pendant des décennies.

En juin 2026, un développeur nommé Dominik Peters a publié un projet sur HN : TikZ Editor — un éditeur graphique WYSIWYG pour TikZ, où vous pouvez glisser-déposer des nœuds comme dans Figma, avec le code source qui se met à jour en temps réel. 293 points, 58 commentaires. Ce qui rend ce projet vraiment digne d’intérêt, c’est comment il a été fabriqué.

« Ce qu’aucun humain ne voudrait faire »

Dans son post Show HN, Dominik Peters a une phrase qui livre pratiquement la thèse centrale du projet :

This approach essentially required reimplementing a large fraction of TikZ, which is the kind of task that no human would ever want to do.

Traduisons plus crûment : pour faire un éditeur TikZ par glisser-déposer, il faut réimplémenter la majeure partie des mécanismes sous-jacents de TikZ — parseur, moteur de rendu, système de mise en page, traitement des couleurs. C’est une tâche d’ingénierie au ROI absurdement bas, qu’aucune personne normale n’accepterait.

Mais Codex l’a acceptée. Le projet entier — l’interface frontend, l’application de bureau Tauri, le parseur de syntaxe TikZ, le pipeline de rendu SVG en JavaScript, plusieurs convertisseurs de formats (SVG/PPTX/IPE → TikZ), ainsi que ces « quêtes secondaires » proprement délirantes — a été presque entièrement généré par Codex. Dominik a commencé le projet en février 2026, a consommé environ 700 millions de tokens, soit environ 15 000 $ aux prix API — il n’a en réalité payé qu’environ 500 $ d’abonnement ChatGPT.

La chaîne logique est claire : quand le coût de développement tend vers zéro, les projets qui « ne valaient pas la peine » deviennent soudainement rentables. Cette proposition n’est pas neuve en soi. Mais TikZ Editor fournit un cas suffisamment précis pour que je puisse décortiquer ce que les outils de codage IA ont exactement pris en charge comme travail d’ingénierie — et ce qu’ils n’ont pas pris en charge.

Deux catégories de travail d’ingénierie externalisées

Le travail impliqué dans la réalisation de TikZ Editor peut se diviser en deux catégories, que je distingue ici.

Première catégorie : la conversion mécanique de formats. Cela inclut les convertisseurs SVG vers TikZ, PPTX vers TikZ, IPE vers TikZ, etc. La complexité logique de ces convertisseurs n’est pas négligeable — mapper les commandes de chemin SVG vers la syntaxe \draw de TikZ, traduire le modèle de formes de PowerPoint en nœuds et chemins TikZ — mais il s’agit essentiellement de règles de correspondance et de conditions aux limites. Les règles sont épuisables, les cas limites couvrables par des tests. Vous pouvez imaginer un ingénieur expérimenté y passer trois semaines, et une fois fini, ne pas avoir le sentiment d’avoir acquis une quelconque intuition profonde. Pour ce type de travail, les outils de codage IA sont relativement fiables, car la vérification est binaire : le TikZ converti compile-t-il ? Le résultat du rendu correspond-il au format d’origine ?

Deuxième catégorie : réimplémenter des algorithmes classiques dans un domaine inconnu. C’est la catégorie la plus intéressante. Dominik mentionne plusieurs « quêtes secondaires » dans son post, dont deux méritent d’être développées :

1. Réimplémenter l’algorithme de césure de LaTeX (Knuth-Plass). Pour supporter les nœuds de texte multi-lignes, TikZ Editor doit implémenter une césure et une coupure de mots correctes côté navigateur (environnement JavaScript). Cela signifie reproduire l’algorithme de programmation dynamique de césure publié par Donald Knuth et Michael Plass en 1981 — un algorithme qui optimise globalement la « laideur » du paragraphe, pas un simple remplissage glouton de lignes. Le text-align: justify CSS du navigateur ne fait qu’une césure gloutonne ligne par ligne, au résultat grossier ; l’algorithme de TeX calcule l’optimum global, en traitant l’étirement et la contraction de la glue entre les mots, les pénalités de césure, et une fonction de score esthétique pour le paragraphe entier.

2. Implémenter le système de mélange de couleurs red!20!black. Dans les papiers LaTeX, les couleurs sont souvent spécifiées avec la syntaxe {couleur1}!{proportion}!{couleur2}, par exemple red!20!black signifie 20% de rouge mélangé à 80% de noir. Implémenter un sélecteur de couleur qui supporte cette syntaxe côté navigateur signifie rétro-concevoir le modèle de mélange exact à partir du package xcolor, gérer la conversion RGB/CMYK, le calcul de transparence, et l’imbrication de l’opérateur ! (par exemple red!20!blue!50!green).

Je range ces deux éléments dans la même catégorie parce qu’ils partagent une propriété : si vous ne le faites pas, la fonctionnalité est incomplète ; si vous le faites, votre compétence centrale n’en devient pas plus claire pour autant. C’est de l’« ingénierie fastidieuse » typique — pas parce que c’est sans importance, mais parce que le ROI est trop bas. La première réaction d’un ingénieur humain face à ce genre de tâche est « y a-t-il une bibliothèque existante pour contourner ça ? ». Si la réponse est non, la fonctionnalité est souvent marquée WONTFIX.

Et la performance des outils de codage IA dans ce type de scénario est assez éloquente. Dominik a partagé dans les commentaires HN son flux de travail concret : il utilise d’abord le moteur LaTeX (dvisvgm) et le moteur de rendu JavaScript pour traiter respectivement le même lot de figures TikZ, puis il compare manuellement les différences, signale à Codex ce qui ne va pas, et lui demande de corriger. Il a essayé de faire comparer automatiquement par un modèle multimodal, ça n’a pas bien marché — le modèle « est encore un peu aveugle, il considère que deux images manifestement différentes sont identiques ».

Il y a ici un détail subtil : le rôle de l’humain dans la boucle est de porter un jugement. Juger quelle différence de rendu est un bug, laquelle est un écart normal de rendu de police, laquelle est acceptable. L’humain n’a pas disparu, il est simplement passé d’implémenteur à arbitre de qualité.

La seconde moitié de la phrase d’Armin Ronacher

La veille de la publication de TikZ Editor, Armin Ronacher, auteur de Flask et Jinja2, écrivait sur son blog « The Coming Loop » un jugement qui forme un dialogue précis avec cette affaire :

I absolutely love loops already that take the boring parts out of my day to experiment and measure and to give me ideas.

Puis il change brusquement de ton :

On the other hand using that same looping methodology to write lasting code does not yet sit well with me.

La préoccupation centrale de Ronacher est la suivante : quand la boucle harness tourne en continu, que chaque itération ajoute une défense locale, que le code croît tout seul sans que personne ne le voie, le produit final devient un organisme qui a besoin de lui-même pour se maintenir. Il appelle ça « le logiciel qui passe de machine déterministe à organisme » — vous le surveillez, vous le stabilisez, mais vous ne le comprenez pas.

Mais une autre de ses phrases est peut-être plus cruciale :

Porting code is one of them. There are already impressive examples of large automatic porting efforts, including the reported work around moving parts of Bun from Zig to Rust. I have used it with success myself to port MiniJinja to Go.

Ronacher considère que la boucle fonctionne déjà bien dans deux scénarios : la transformation de code (code transformation, incluant le portage, les benchmarks, le scan de sécurité) et le code qui n’a pas besoin de durer (preuve de concept, exploration expérimentale).

Une correspondance intéressante apparaît ici, que j’essaie de dessiner :

Catégorie	Tâche représentative	L’IA est-elle compétente	Raison
Transformation mécanique	Porter du code, conversion de formats	Compétente	Correspondances épuisables, vérification binaire
Ingénierie fastidieuse	Réimplémentation de Knuth-Plass, mélange de couleurs	Compétente	Logique déterminée, interfaces claires, ROI dissuadant les humains
Décision architecturale	Structure du projet, niveaux d’abstraction	Incertaine	Implique des arbitrages de valeurs
Décision de design	Quel graphique dessiner, comment mettre en page	Ne peut pas remplacer	Nécessite une intention et un jugement esthétique

TikZ Editor couvre précisément les deux premières lignes. La conversion de formats est dans la première ligne, la réimplémentation d’algorithmes dans la deuxième. Et l’architecture du projet — Dominik dit qu’il a « d’abord validé la faisabilité architecturale avec un parseur → rendu SVG + glisser-déposer basique le plus simple possible » — cette décision, il l’a prise lui-même. Codex ne lui demandait son avis que sous forme de QCM en mode plan.

Quel graphique dessiner, c’est la décision de l’utilisateur. L’éditeur fournit l’outil, pas l’esthétique.

« La boucle a besoin de clarté » — cette phrase tombe juste, appliquée à TikZ Editor

Ronacher écrit à la fin de son article une phrase que j’ai relue trois fois :

Adopting the idea of harness loops means that the harness decides when work is finished.

Dans le développement de TikZ Editor, « quand est-ce que c’est réparé » a toujours été jugé par Dominik. Il mettait côte à côte les sorties des deux moteurs de rendu, fixait les différences, disait à Codex ce qui n’allait pas encore. La condition d’arrêt de la boucle était définie par quelqu’un qui sait à quoi ressemble la sortie correcte. C’est ce que Ronacher appelle « la clarté comme prérequis de la boucle » — il faut d’abord être passé par suffisamment de versions médiocres pour savoir ce que « correct » signifie. L’agent peut vous aider à raccourcir la partie fastidieuse du processus d’essai-erreur, mais il ne peut pas définir « correct » à votre place.

Cette logique s’applique aussi côté utilisateur de TikZ Editor. Un chercheur ouvre l’éditeur, il veut dessiner une représentation de la sphère de Bloch d’un état quantique, ou un diagramme du mécanisme d’auto-attention d’un Transformer — à quoi ressemblent ces figures, c’est d’abord une intention qu’il a dans la tête. L’agent ne peut pas décider à sa place comment disposer l’illustration centrale de son papier, quel flux doit être accentué, si la couleur doit être verte ou grise. Il peut seulement lui permettre, une fois l’idée en tête, de ne pas avoir à écrire à la main des coordonnées comme \draw[->] (-0.866,-0.5) -- (0.866,0.5).

En d’autres termes : l’ingénierie fastidieuse peut être externalisée à la machine, le jugement de sens doit rester entre les mains de l’humain. C’est la projection précise, sur le cas concret de TikZ Editor, de la frontière actuelle des capacités des outils de codage IA.

La partie optimiste, et la partie incertaine

Je ne veux pas transformer cette analyse en un compromis bon marché — « l’IA a du bon et du mauvais ». TikZ Editor est un vrai bon produit. Il comble avec du code un problème insoluble depuis des décennies dans le monde académique, et il le fait en open source (licence MIT), multiplateforme (Web + desktop Linux/Windows/macOS), et peut même ouvrir un fichier .tex complet pour éditer directement les figures TikZ qu’il contient. L’un des commentaires les plus upvotés sur Hacker News vient d’un doctorant allemand : « Tous les étudiants et chercheurs en STEM te remercient. »

La partie incertaine est : jusqu’où ce paradigme peut-il aller.

Dominik a consommé 700 millions de tokens pour ce projet. Ronacher s’inquiète que la qualité du code produit par les modèles régresse — trop défensif, raisonnement local, évitement des invariants. Mais sur le cas TikZ Editor, un observateur sur Github estime que « la structure du code semble très bonne ». D’où vient cet écart ?

Mon hypothèse : le degré de clarté des frontières de la tâche détermine la qualité de la production. L’algorithme de Knuth-Plass a pour entrée du texte et une largeur de ligne, pour sortie des positions de césure — la correction se vérifie intuitivement dans le résultat du rendu. Le mélange de couleurs a pour entrée deux couleurs et une proportion, pour sortie une couleur — le vrai du faux se voit au premier coup d’œil. Le parseur TikZ a pour entrée du texte, pour sortie un AST — tant que le rendu ne plante pas et que les coordonnées correspondent, c’est correct.

Quand le critère de vérification est visualisable, la boucle est plus fiable. Quand le critère de vérification exige un jugement d’expérience, la boucle a besoin de l’humain.

Ce n’est pas une question de « croire » ou « ne pas croire » en l’IA. C’est une question d’ingénierie : quel type de tâche peut être vérifié automatiquement ? Si la réponse est « vérifiable automatiquement », l’agent est adapté pour la prendre en charge. Si la réponse est « nécessite un jugement humain », la valeur de l’agent est d’accélérer chaque tour de boucle, mais pas de mettre le point final à votre place.

De « l’ingénierie fastidieuse » à « l’ingénierie qui vaut la peine »

Revenons à la phrase de Dominik — « c’est une tâche qu’aucun humain ne voudrait faire ». Le sous-texte le plus intéressant de cette phrase est : pas parce que c’est infaisable, mais parce que personne n’a envie de le faire.

L’algorithme de césure de TeX existe depuis 1981, sa description est complète dans la littérature publique, et il existe plus d’une implémentation JavaScript. Le modèle de mélange de couleurs red!20!black est écrit noir sur blanc dans le code source de xcolor. Le problème n’est pas que « personne ne peut l’implémenter », le problème est que « personne n’a envie de passer quatre semaines là-dessus pour une contribution de seulement 2% à la valeur centrale du produit final ».

Les outils de codage IA sont en train de changer ce calcul. Quand le temps nécessaire pour ces 2% de valeur marginale passe de quatre semaines à quatre heures, voire quatre minutes, la tâche passe de « ça ne vaut pas la peine » à « je le fais en passant ». Cela ne signifie pas que le rôle de l’humain dans le développement logiciel disparaît — cela signifie que l’humain peut se concentrer davantage sur la décision de quoi faire, et confier à la machine la partie fastidieuse du comment faire.

La dernière phrase de Ronacher dit en un sens la même chose, côté négatif : quand le « quoi faire » est lui aussi confié à la machine, nous risquons de perdre la capacité de comprendre le système. Ces deux phrases mises ensemble sont plus proches de la vérité que chacune prise isolément.

La page Github de TikZ Editor continue d’être mise à jour. Dominik dit que la prochaine étape pourrait être le support de pgfplots. Je ne dirai pas que « le codage IA est en train de remodeler le développement logiciel » — cette formulation est trop vague. Mais ce que je peux dire, c’est : quand un algorithme de césure TeX qu’aucun humain ne voulait réécrire est implémenté par un agent en quelques conversations et qu’il rend correctement des nœuds multi-lignes dans le navigateur, un certain seuil a été franchi. Ce qui mérite maintenant l’attention, ce n’est plus « l’IA sait-elle coder », mais « quelles décisions d’ingénierie l’humain ne doit-il pas externaliser, et lesquelles sont sans importance ».

Cette distinction elle-même est peut-être la question la plus importante à méditer dans le génie logiciel des années à venir.