Un designer envoie un lien Figma. Le développeur l'ouvre, zoome sur chaque composant, note les espacements en pixels, copie les couleurs hexadécimales une à une, puis passe l'heure suivante à recréer dans du code ce qui existait déjà, sous une autre forme, à l'écran d'à côté. Ce rituel, presque personne ne l'aime, et pourtant il a survécu à trois générations d'outils censés l'abolir. Kombai est le dernier arrivé dans cette lignée : un agent qui prend une maquette et rend, en sortie, du code prêt à être intégré dans un projet réel. L'intérêt n'est pas l'outil lui-même, qui sera peut-être oublié dans quelques années, mais le problème qu'il révèle : pourquoi transformer une image en code a toujours été si difficile, alors que cela semble, sur le papier, trivial.
Un problème qu'on a mal nommé
Pendant longtemps, l'industrie a traité la conversion maquette-code comme un problème de rendu : il suffirait de mesurer assez précisément les pixels pour en déduire le balisage. C'est le raisonnement qui a produit des générations d'extensions « pixel to code », capables de recracher un HTML rigide et jetable, aussitôt abandonné par les équipes sérieuses. Le vrai obstacle n'a jamais été la précision de la mesure. C'est ce qu'on pourrait appeler le fossé sémantique entre deux représentations du même produit : une maquette décrit une disposition visuelle figée, un état parmi d'autres, tandis qu'un code de production décrit un comportement — ce qui doit s'adapter, se répéter, réagir à une donnée absente, se redimensionner sur un petit écran. Une image ne contient aucune de ces intentions. Elle ne dit pas qu'un bouton est un composant réutilisé ailleurs, ni qu'une liste de cartes doit boucler sur un tableau, ni que cette marge de seize pixels est en réalité une variable de design system utilisée dans quarante autres écrans.
C'est pourquoi les outils précédents, aussi soignés soient-ils sur le rendu visuel, produisaient un code que personne ne voulait garder : il fonctionnait à l'écran, mais il ne s'intégrait dans rien. Il fallait tout réécrire pour le faire vivre dans une base de code existante.
Ce que change une lecture contextuelle
La différence avec une approche agentique tient moins à la qualité de reconnaissance visuelle qu'à ce qu'elle regarde en plus de la maquette : les composants déjà présents dans le projet, les conventions de nommage, la bibliothèque de style utilisée, la manière dont l'équipe structure ses fichiers. Au lieu de générer un morceau de code isolé, l'agent tente de produire quelque chose qui ressemble à ce qu'un développeur du projet aurait écrit lui-même — en réutilisant un bouton existant plutôt qu'en en recréant un nouveau, en respectant les jetons de couleur déjà déclarés plutôt qu'en les redéfinissant.
Ce déplacement est révélateur d'une tendance plus large dans les usages actuels de l'intelligence artificielle appliquée au développement : la frontière utile ne se situe plus dans la capacité à générer quelque chose à partir de rien, ce que les modèles savent déjà bien faire, mais dans la capacité à s'insérer proprement dans un système qui existe déjà, avec son histoire, ses choix, ses irrégularités. Générer un composant de bouton est facile. Deviner qu'il devrait réutiliser celui qui existe déjà, avec les mêmes props, la même hiérarchie de dépendances, est une tâche d'un tout autre ordre : elle exige de lire un contexte plutôt que de suivre une instruction.
La difficulté n'a jamais été de dessiner un bouton. Elle a toujours été de savoir qu'il en existait déjà un.
Ce que cela déplace dans le travail à deux
Le duo designer-développeur s'est construit, depuis des décennies, sur une frontière assez nette : l'un imagine la forme, l'autre l'implémente, et l'espace entre les deux — le fameux dev mode, les specs, les allers-retours de relecture — a longtemps occupé une part disproportionnée du temps de projet par rapport à sa valeur réelle. Ce n'est pas un travail créatif, ni un travail vraiment technique : c'est un travail de traduction, pénible précisément parce qu'il n'ajoute rien à l'idée d'origine, il se contente de la faire survivre au passage d'un médium à un autre.
Automatiser cette traduction ne supprime pas le designer ni le développeur, mais cela réduit l'épaisseur de la couche qui les séparait, et donc le nombre d'occasions où l'intention se perd en chemin. Un changement de marge décidé en réunion, qui prenait auparavant un aller-retour de ticket, peut redevenir une modification immédiate. Cela ne rend pas les rôles obsolètes : cela rend visible, par contraste, ce qui dans chaque rôle n'était que de la logistique, et ce qui relevait réellement du jugement — le choix d'une hiérarchie visuelle d'un côté, celui d'une architecture de données de l'autre.
La partie qui résiste
Il existe une limite structurelle à ce genre d'outil, et elle est instructive en elle-même : une maquette ne contient que ce qui a été dessiné. Elle ne montre presque jamais les cas limites — le nom trop long qui déborde, la liste vide, l'erreur réseau, l'utilisateur qui n'a pas de photo de profil. Ce sont pourtant ces cas-là qui constituent l'essentiel du travail réel d'un produit en production. Un agent, aussi bon soit-il pour lire une intention visuelle, ne peut pas inventer ce que personne n'a représenté. Il ne fait qu'exposer, plus vite qu'avant, la question que l'équipe aurait dû se poser depuis le début : que se passe-t-il quand la réalité ne ressemble pas à la maquette.
Cette limite dessine assez bien la ligne de partage durable entre ce qu'une machine peut prendre en charge et ce qui reste, structurellement, un travail humain. Traduire une forme connue dans un langage connu, en respectant des règles déjà établies par un projet, est un travail de cohérence — répétitif, contraint, largement automatisable. Décider de ce qui doit exister quand la forme n'est pas connue, quand la règle n'a pas encore été écrite, reste un travail de jugement.
Un signal plus qu'un outil
On peut se demander si Kombai, comme ses prédécesseurs, restera dans cinq ans. La question a peu d'importance. Ce qui compte, c'est ce que ce type d'outil met en évidence sur la nature du travail numérique en général : une part immense de ce qui occupe les équipes n'est ni de la conception, ni de l'ingénierie, mais de la traduction contextuelle entre des représentations différentes d'une même idée — entre une maquette et un composant, entre un tableur et une base de données, entre une conversation et un cahier des charges. À mesure que les agents apprennent à lire le contexte d'un système plutôt qu'à produire des artefacts isolés, cette catégorie de travail invisible, qui n'a jamais été valorisée parce qu'elle ne se voyait pas, commence enfin à se dissoudre. Ce qui reste ensuite à faire, en revanche, devient beaucoup plus difficile à déléguer.
