De Interface Builder aux LLM :
l’évolution de l’abstraction du code

— Jean-Marie Hullot · NeXT · 1988  —  Retour sur une continuité intellectuelle

I - Une rupture silencieuse

En 1988, Jean-Marie Hullot livrait avec Interface Builder une véritable rupture conceptuelle, dont la portée n’a pas encore été pleinement reconnue à sa juste valeur. Sur les machines NeXT de Steve Jobs, un développeur pouvait pour la première fois voir une interface graphique prendre forme, relier des boutons à du code par de simples fils, et observer le comportement de son application sans jamais relancer le compilateur. L’acte de programmer cessait d’être une affaire de texte solitaire pour devenir un dialogue visuel, immédiat, incarné.

L’enjeu dépassait largement le confort d’utilisation. Interface Builder portait deux idées d’une profonde cohérence intellectuelle : d’une part, la mutualisation du code comme mode de construction collectif ; d’autre part, l’interactivité comme mode de pensée du développement. Près de quarante ans plus tard, ces deux idées trouvent leur prolongement logique dans les grands modèles de langage appliqués à la programmation.

Le bon outil ne s’interpose pas entre l’intention et sa réalisation. Il les fait coïncider.

— Principe de conception, NeXT Software, années 1990

II. Premier paradigme : la mutualisation du code

L’idée n’est pas née chez NeXT. Elle est née à Xerox PARC, dans les années 1970, avec Smalltalk — le premier langage à pousser jusqu’à sa conclusion logique le principe de l’héritage orienté objet. Alan Kay et ses collègues avaient compris quelque chose de profond : si le code peut être organisé en objets qui s’appuient sur ceux qui les précèdent sans les réécrire, alors l’effort de programmation peut être mutualisé — écrit une fois, réutilisé partout, enrichi collectivement.

Smalltalk allait encore plus loin : son environnement n’était pas un programme qu’on compile et qu’on relance, mais une image vivante — un espace d’objets en fonctionnement permanent. Changer le code d’une méthode dans le navigateur de classes suffisait pour que tous les objets en cours d’exécution adoptent immédiatement le nouveau comportement, sans interrompre la machine. La résolution des envois de messages entre objets étant dynamique, le code modifié prenait effet au prochain envoi de message. On pouvait littéralement réparer un programme en train de tourner. Ce principe — le code comme matière vivante, immédiatement réactive — est l’intuition fondatrice de toute l’interactivité qui suivra.

Mais Smalltalk restait l’affaire de chercheurs et de spécialistes. C’est NeXT qui a professionnalisé ce paradigme en le cristallisant dans ses API, Foundation et AppKit : des frameworks stables, documentés, prêts pour la production industrielle. Le développeur n’avait plus à écrire lui-même les fondations de son application ; il héritait d’une infrastructure partagée et pouvait consacrer son énergie à ce qui la distinguait vraiment.

Interface Builder a accompli un pas supplémentaire, décisif : il a démocratisé cette mutualisation jusqu’au non-programmeur. En plaçant un objet NSButton sur un canvas, même quelqu’un qui ne lisait pas Objective-C instanciait des milliers de lignes de code écrites, testées, documentées par d’autres. Il ne créait pas un bouton ; il convoquait le bouton qu’une communauté avait construit avant lui, sans avoir à en connaître la mécanique interne.

Ce geste — appeler plutôt qu’écrire, agencer et combiner plutôt que construire — révèle une vérité économique simple : ce qui est mutualisé n’a plus à être réinventé. Ce que Smalltalk avait théorisé, ce que NeXT avait industrialisé, Interface Builder l’a rendu accessible.

III. Deuxième paradigme : l’interactivité comme mode de pensée

Le second apport d’Interface Builder est peut-être encore plus radical — ou plus précisément, c’est là qu’il accomplit sa contribution la plus originale. Car l’idée du code immédiatement réactif n’est pas née avec lui : Smalltalk l’avait déjà inscrite au cœur de son architecture, avec son image vivante et sa résolution dynamique des messages. Ce que Smalltalk avait inventé pour le développeur expert, Interface Builder allait le rendre visible et accessible.

Avant Interface Builder, programmer c’était écrire, compiler, exécuter, observer — un cycle linéaire, différé, où la pensée et le résultat étaient séparés par le temps de compilation. Interface Builder a cassé ce cycle d’une façon nouvelle : non pas seulement par la dynamique du runtime, mais par le geste visuel.

Grâce au runtime dynamique d’Objective-C — hérité directement de Smalltalk — et au mécanisme IBAction/IBOutlet le développeur reliait un bouton à une méthode par un simple tracé à la souris. L’effet était immédiat, visible, réversible. Le code et son incarnation graphique existaient simultanément, dans un même espace mental. On ne décrivait plus l’interface : on la modelait.

Cette idée — qu’on comprend mieux en manipulant qu’en lisant, qu’on pense mieux en interagissant qu’en décrivant — n’est pas propre au logiciel. C’est un mode de pensée dont les racines remontent à Dewey, à Papert, et que les chercheurs en sciences cognitives nomment aujourd’hui cognition incarnée.

S’il y a le moindre retard dans cette boucle de rétroaction, entre le moment où l’on pense à quelque chose, celui où on le visualise et celui où on le concrétise, alors tout un univers d’idées ne verra tout simplement jamais le jour. Ce sont des pensées que nous ne pourrions pas avoir.

— Bret Victor, Inventing on Principle (2012)

IV. Perspective personnelle — Trente ans à construire des interfaces pour penser

J’ai découvert NeXT en 1988, et exploité Interface Builder dès 1989 comme un outil qui allait me libérer des contraintes répétitives de la construction d’interfaces graphiques. En tant qu’ingénieur en calcul scientifique aux côtés des physiciens Pierre Coullet puis Jean-René Chazottes, j’en ai pleinement pris la mesure. Nous cherchions ensemble une réponse à une question qui n’était pas de nature informatique : comment rendre les équations et les mathématiques vivantes, accessibles, intuitives ? Comment, au moins dans un premier temps, s’affranchir du formalisme pour leur donner cette immédiateté ?

Ma réponse, construite sur trois décennies au CNRS, a toujours été la même : par l’interactivité. Pas l’interactivité comme agrément pédagogique, mais comme mode de production de connaissance.

Modifier un paramètre, changer une condition initiale, passer d’une représentation à une autre : chacun de ces gestes fait apparaître un aspect différent du même modèle. Ce n’est pas une démonstration, mais ce n’est pas non plus une simple illustration. C’est un espace d’exploration où l’intuition se forme au contact du phénomène. On comprend autrement une bifurcation de Hopf lorsqu’on la voit se préparer, puis advenir sous ses doigts : l’équilibre perd sa stabilité, une oscillation naît, le système change de régime. Le théorème établit les conditions de cette transition ; l’outil interactif en fait éprouver la dynamique interne.

Des simulations visuelles interactives comme instruments de pensée
Ce que j’ai développé — des 70 simulations de l’eBook Dynamical Systems de Chazottes et Monticelli à celles pour le MOOC sur les probabilités de l’X, des visualisations interactives d’Images des maths à l’Experimentarium Digitale — procède d’un même principe : l’outil numérique ne doit pas illustrer la mathématique, il doit la rendre praticable. Il doit en réduire le coût intellectuel d’accès sans en trahir la rigueur.

Un chercheur qui interroge un système de Lorenz avec de tels outils ne regarde pas l’équation mise en image : il met le système à l’épreuve. Il modifie un paramètre, relance la trajectoire depuis une condition initiale voisine, observe l’attracteur se déformer, change de projection, revient en arrière, compare deux régimes. Chaque manipulation n’est pas seulement un changement d’affichage ; c’est une question posée au modèle. Là où l’article expose un résultat déjà stabilisé, l’outil interactif rend perceptible le chemin par lequel une intuition se forme : repérer une transition, soupçonner une bifurcation, distinguer ce qui relève du phénomène et ce qui relève de la représentation. Le chercheur ne reçoit pas une démonstration ; il construit un rapport actif au système. Ce moment n’est pas encore la preuve, ni la publication, ni même nécessairement un résultat. Mais il appartient pleinement au travail de recherche : c’est le moment exploratoire où les hypothèses deviennent pensables.

Ce parallèle n’est pas rhétorique. Dans les deux cas, ce qui est en jeu est une réduction de la latence cognitive : le délai entre l’intention et l’observation de son effet. Plus ce délai est court, plus la pensée peut se déployer librement. L’interactivité n’est pas un luxe pédagogique — c’est une condition de la créativité.

Quand les LLM renversent la perspective
Pendant trente ans, j’ai construit des outils pour que d’autres — chercheurs, étudiants, élèves — puissent faire des mathématiques sans maîtriser la programmation. Je me suis fait l’artisan de l’interactivité pour autrui. Je savais coder ; mes outils affranchissaient ceux qui ne savaient pas.

Les LLM appliqués à la programmation ont renversé cette asymétrie.

Lorsque je développe aujourd’hui avec Claude Code — que je décris en langage naturel une simulation d’un modèle mathématique, que j’observe le code généré, que je le corrige par une phrase, que je vois l’animation évoluer — je vis exactement l’expérience que j’ai cherchée à offrir à mes utilisateurs depuis le début. Je suis devenu l’utilisateur de mon propre paradigme.

Je construisais des interfaces pour que les mathématiciens modélisent et explorent leurs équations intuitivement. Les LLM me permettent désormais de programmer intuitivement moi-même.

La boucle de rétroaction est identique : décrire une intention → observer un résultat → affiner par conversation → observer à nouveau. Ce n’est pas du développement logiciel traditionnel. C’est de l’exploration — la même exploration que je cherchais à rendre possible pour des équations différentielles ou des processus stochastiques, désormais appliquée au code lui-même.

Ce que Jean-Marie Hullot avait accompli pour l’interface graphique — rendre le code manipulable sans en effacer la structure — les LLM l’accomplissent pour la programmation dans son ensemble. Et pour moi, il y a dans cette convergence quelque chose qui ressemble à une cohérence : les mêmes principes qui m’ont guidé dans la construction de mes outils guident, à plus grande échelle, l’évolution de l’acte de programmer.

V. Les LLM comme aboutissement des deux paradigmes

L’usage des LLM pour la programmation apparaît aujourd’hui comme le prolongement cohérent de ce que Smalltalk et Interface Builder avaient initié. Dans ce domaine précis, les grands modèles de langage ne sont pas une rupture avec le passé informatique — ils en sont l’extension naturelle, conduite jusqu’à sa conséquence ultime.

La mutualisation portée à l’échelle du corpus mondial de code
Smalltalk mutualisait le code d’une poignée de chercheurs à Xerox PARC. Les API de NeXT l’étendaient à une communauté professionnelle. Interface Builder l’ouvrait aux non-programmeurs, capables d’assembler des composants sans en lire le code. Les LLM spécialisés dans la programmation franchissent la dernière frontière : ils mutualisent l’intégralité du savoir collectif en matière de code — des décennies de dépôts publics, de documentation technique, de discussions entre développeurs, d’articles algorithmiques — et l’ouvrent à quiconque peut formuler une intention en langue naturelle.

Quand je demande à Claude d’écrire un programme informatique qui simule l’évolution d’un système de Lotka-Volterra en utilisant la méthode numérique dite RK4, c’est-à-dire Runge-Kutta d’ordre 4, ma démarche est de même nature que celle du développeur NeXT qui instanciait un NSButton, ou celle de l’utilisateur d’Interface Builder qui le glissait sur un canvas. Je convoque un effort de programmation collectif mutualisé, sans en maîtriser tous les mécanismes internes. Ce qui change, c’est l’échelle : planétaire plutôt que communautaire, diachronique plutôt que synchronique. Et ce qui change aussi, c’est la barrière d’entrée : une phrase en français plutôt qu’un geste de câblage.

L’interactivité portée au langage naturel
Interface Builder avait substitué le câblage graphique au cycle compile-run-debug. Les LLM substituent la conversation en langue naturelle à l’acte d’écriture syntaxique. La latence change de nature : ce n’est plus le temps de la compilation ni celui du débogage — c’est le temps de la formulation. L’obstacle n’est plus technique ; il est sémantique.

Et ce qui est remarquable, c’est que cette interactivité ne sacrifie pas la structure. Comme Interface Builder permettait d’assembler visuellement des composants sans renoncer à leur richesse interne, les LLM permettent de décrire une intention en langage naturel sans renoncer à la précision du code qui en résulte. La surface est naturelle ; la profondeur reste rigoureuse.

VI. La continuité d’une idée

Jean-Marie Hullot n’avait pas prédit les LLM. Mais les deux principes qu’il a incarnés dans Interface Builder — rendre accessible la mutualisation du code et rendre le code immédiatement interactif — traversent l’histoire de l’informatique comme un fil conducteur. Ce fil remonte plus loin encore : jusqu’à Alan Kay et Smalltalk, qui avaient compris les premiers que l’héritage objet était une forme d’organisation collective de l’intelligence humaine.

Ce que l’on observe sur cinquante ans, c’est une démocratisation continue de l’acte de programmer : Smalltalk réservait le paradigme aux chercheurs, NeXT l’ouvrait aux développeurs experts, Interface Builder l’étendait aux non-programmeurs, les LLM l’offrent à quiconque peut formuler une intention en langage naturel. À chaque étape, la puissance est préservée — ou amplifiée. Seule la barrière d’entrée s’abaisse.

Pour ceux qui, comme moi, ont construit leur pratique sur l’idée que la compréhension passe par la manipulation, que l’exploration prépare la démonstration, que la latence entre intention et observation est l’ennemi de la pensée, l’usage des LLM pour programmer est une heureuse surprise, mais aussi une confirmation.

Elle confirme que l’interactivité n’était pas un détail de confort dans le développement logiciel, mais un mode de pensée dont la portée dépasse de loin le génie logiciel. Elle s’applique aux mathématiques, à la physique, et désormais à la programmation elle-même.

Ce que j’ai cherché à offrir aux utilisateurs scientifiques depuis trente ans, les LLM me le rendent aujourd’hui : la possibilité de penser en faisant, de comprendre en explorant, de créer en conversant — mais appliquée cette fois au code lui-même.

Interface Builder avait ouvert cette voie pour les interfaces graphiques. Les LLM l’ouvrent pour la programmation.

Cet essai a été rédigé dans le cadre d’une réflexion sur la médiation des mathématiques et du calcul scientifique, à partir d’une pratique de trente ans de développement d’outils numériques interactifs à l’INLN puis au LJAD (CNRS, Université Côte d’Azur).

Merci à Jean-René Chazottes pour sa relecture minutieuse et ses précieuses suggestions de reformulation, qui ont contribué à améliorer la clarté de ce texte.