Explorez les idées clés d’Alan Kay autour de Smalltalk et des premières interfaces graphiques — et comment elles ont façonné la vision moderne du logiciel comme système d’objets en interaction.
Alan Kay n’est pas qu’un nom de l’histoire de la programmation. Beaucoup d’hypothèses que nous tenons pour acquises sur les ordinateurs—ce qu’est une « fenêtre », pourquoi le logiciel doit être interactif, comment on peut construire des programmes à partir de pièces coopérantes—ont été façonnées par des idées qu’il a promues (souvent avec des équipes au Xerox PARC).
Ce billet parle de concepts, pas d’anecdotes. Vous n’avez pas besoin de savoir coder pour le suivre, et il n’y a pas de visite guidée de détails techniques obscurs. Nous allons plutôt nous concentrer sur quelques modèles mentaux qui apparaissent encore dans les outils et produits que nous utilisons : comment le logiciel peut être compris, modifié et appris.
D’abord, Smalltalk : pas seulement un langage, mais tout un environnement de travail qui encourageait l’exploration et l’apprentissage.
Ensuite, les interfaces graphiques (GUI) : fenêtres, icônes, menus—du logiciel interactif qu’on manipule directement, pas seulement des instructions à donner.
Enfin, la pensée systémique : voir le logiciel comme un ensemble de parties qui interagissent avec des boucles de rétroaction, plutôt que comme un tas de fichiers source.
Il ne traitera pas Kay comme un génie solitaire, et ne prétendra pas qu’un « paradigme juste » résout tout. Certaines idées ont très bien marché, d’autres ont été mal comprises, et d’autres encore ne se sont pas propagées autant qu’elles auraient pu.
L’objectif est pratique : à la fin, vous devriez pouvoir regarder des applications et des bases de code modernes avec une meilleure idée de pourquoi elles fonctionnent comme elles fonctionnent—et de ce que vous pouvez emprunter pour votre prochain projet.
Alan Kay est arrivé dans une culture informatique puissante, coûteuse et pour l’essentiel indifférente aux gens ordinaires. Les ordinateurs étaient traités comme une infrastructure partagée : on réservait du temps, on soumettait des travaux, on attendait des résultats. Ce modèle façonnait tout—à quoi ressemblaient les programmes, qui les utilisait et ce que signifiait « réussir ».
Pour beaucoup d’utilisateurs, l’informatique signifiait confier un travail à la machine (souvent via des cartes ou des terminaux en file d’attente) et recevoir la sortie plus tard. Si quelque chose ratissait, on ne « tatonnait » pas pour apprendre—on soumettait à nouveau et on attendait. L’exploration était lente, et l’ordinateur ressemblait plus à un service distant qu’à un outil avec lequel on pense.
La cible de Kay n’était pas simplement « des ordinateurs plus petits ». C’était une relation différente : un ordinateur comme médium personnel pour apprendre, écrire, simuler, dessiner et faire émerger des idées—surtout pour les enfants et les non-spécialistes. Cela exigeait de l’immédiateté. Il fallait voir ce que faisaient nos actions, réviser rapidement et rester dans un flux créatif.
Pour poursuivre ce type de changement, il fallait de l’espace pour expérimenter matériel, logiciel et conception d’interaction ensemble. Des laboratoires de recherche comme Xerox PARC finançaient des paris de long terme : nouveaux écrans, nouveaux dispositifs d’entrée, nouveaux modèles de programmation et nouvelles façons de les assembler en une expérience cohérente. Le but n’était pas de livrer une fonctionnalité—c’était d’inventer une nouvelle manière d’utiliser l’ordinateur.
Si l’ordinateur devait être une machine d’apprentissage et de création, l’utilisabilité ne pouvait pas être une réflexion après coup. L’interface devait soutenir la découverte, le feedback et des actions compréhensibles. Cette priorité a poussé Kay vers des systèmes où le « ressenti » de l’interaction—ce qui arrive quand on clique, édite ou explore—était étroitement lié à la structure même du logiciel.
Alan Kay ne commençait pas par « comment accélérer le travail de bureau ? » Il se demandait : et si un enfant pouvait porter un ordinateur personnel comme un livre, et l’utiliser pour explorer des idées, fabriquer des choses et apprendre en faisant ? Cette pensée est devenue le Dynabook—moins une spécification produit qu’un phare pour l’informatique personnelle.
Le Dynabook était imaginé comme léger, alimenté par batterie et toujours disponible. Mais le mot le plus important n’était pas « portable ». C’était « personnel ». Cet ordinateur appartiendrait à son utilisateur comme un carnet ou un instrument—quelque chose que l’on façonne avec le temps, pas seulement un appareil que l’on opère.
Tout aussi important : il devait être apprenable. L’objectif de Kay n’était pas de cacher l’informatique derrière un mur de menus ; c’était de laisser les gens devenir progressivement des auteurs, pas seulement des consommateurs.
Les « killer apps » du Dynabook étaient la lecture, l’écriture, le dessin, la composition musicale, la simulation d’expériences scientifiques et la construction d’histoires interactives. Il considérait la programmation comme une littératie—une manière d’exprimer des idées—plutôt que comme un métier spécialisé réservé aux professionnels.
Cette orientation change la notion de « bon logiciel ». Un outil d’apprentissage doit inciter au bidouillage, fournir un feedback rapide et rendre sûr le fait de recommencer.
C’est là que Smalltalk et les premières interfaces graphiques entrent en jeu. Si vous voulez que des personnes créent, il faut la manipulation directe, des résultats immédiats et un environnement où expérimenter est naturel. Le système vivant et interactif de Smalltalk et les métaphores visuelles de la GUI soutenaient le même objectif : raccourcir la distance entre une idée et un artefact fonctionnel.
Le Dynabook ne « prédisait » pas la tablette. Il proposait une nouvelle relation avec l’informatique : un médium pour la pensée et la création. Beaucoup d’appareils peuvent s’en approcher, mais la vision porte sur l’autonomisation des utilisateurs—surtout des apprenants—plutôt que sur une taille d’écran ou un design matériel particulier.
Quand on entend « Smalltalk », on imagine souvent un langage de programmation. L’équipe de Kay le considérait comme quelque chose de plus vaste : un système de travail complet où langage, outils et expérience utilisateur étaient conçus comme un tout.
En termes simples, Smalltalk est un système où tout est un objet. Les fenêtres à l’écran, le texte que vous tapez, les boutons sur lesquels vous cliquez, les nombres que vous calculez—chacun est un objet à qui vous pouvez demander de faire des choses.
Smalltalk a été conçu pour apprendre en faisant. Plutôt que d’écrire du code, compiler et espérer que ça marche, vous pouviez inspecter des objets pendant que le système tournait, voir leur état actuel, les modifier et essayer immédiatement une idée nouvelle.
Cette vivacité comptait parce qu’elle transformait la programmation en exploration. Vous ne produisiez pas seulement des fichiers ; vous façonniez un monde en cours d’exécution. Cela encourageait la curiosité : « Qu’est-ce que cet objet ? » « Que contient-il ? » « Que se passe-t-il si je le modifie ? »
Les outils de développement de Smalltalk n’étaient pas des ajouts séparés. Navigateurs, inspecteurs, débogueurs et éditeurs faisaient partie du même univers objet. Les outils comprenaient le système de l’intérieur, parce qu’ils étaient construits dans le même medium.
Cette intégration serrée changeait la manière de travailler sur le logiciel : moins comme la gestion d’un code distant, plus comme une interaction directe avec le système que vous construisez.
Pensez à éditer un document alors qu’il est ouvert et réactif—les modifications de mise en forme apparaissent instantanément, vous pouvez chercher, réagencer et annuler sans « reconstruire » le document. Smalltalk visait ce type d’immédiateté, mais pour les programmes : vous éditez la chose en cours d’exécution, voyez le résultat tout de suite et continuez.
L’idée la plus utile de Kay n’est pas « classes et héritage ». C’est que l’objet est un petit ordinateur autonome : il garde son état (ce qu’il sait), et il décide comment répondre quand vous lui demandez quelque chose.
Pensez à chaque objet comme ayant :
Cette formulation est pratique parce qu’elle déplace l’attention de « où sont stockées les données ? » vers « qui est responsable de gérer cela ? »
Une confusion courante est de traiter les objets comme de simples enregistrements de données : un paquet de champs avec quelques fonctions utilitaires. Dans cette vision, d’autres parties du programme fouillent librement à l’intérieur et manipulent les internes.
La vision de Kay se rapproche davantage des acteurs. Vous n’ouvrez pas un objet pour réarranger ses tiroirs. Vous lui envoyez une requête et lui laissez gérer son état. Cette séparation est l’essentiel.
Le passage de messages est simplement une relation requête/réponse.
Imaginez un café : vous n’entrez pas dans la cuisine pour cuisiner. Vous commandez (« faites-moi un sandwich »), et vous obtenez un résultat (« voici votre sandwich » ou « nous n’avons plus de pain »). Le café décide comment satisfaire la commande.
Les objets logiciels fonctionnent de la même manière : vous envoyez un message (« calcule le total », « enregistre », « rends-toi visible »), et l’objet répond.
Quand les autres parties du système ne dépendent que des messages, vous pouvez changer l’implémentation interne d’un objet—remplacer des algorithmes, modifier le stockage, ajouter du cache—sans forcer une réécriture générale. Ainsi les systèmes grandissent sans tout casser : des accords stables aux frontières, et liberté à l’intérieur des composants.
On traite souvent « orienté objet » comme synonyme de « utilisation des classes ». C’est compréhensible—la plupart des langages enseignent l’OOP via des diagrammes de classes et des arbres d’héritage. Mais l’emphase originelle de Kay était différente : penser en termes de pièces communicantes.
Une classe est un plan : elle décrit ce que quelque chose sait et ce qu’il peut faire.
Une instance (ou objet) est une chose concrète issue de ce plan—votre « un exemplaire ».
Une méthode est une opération que l’objet peut exécuter lorsqu’on la lui demande.
L’état est les données courantes de l’objet : ce qu’il se rappelle maintenant, et qui peut changer.
Smalltalk a popularisé un modèle objet uniforme : tout est objet, et on interagit avec les objets de façon cohérente. Il s’appuyait aussi fortement sur le passage de messages—on ne cherche pas dans l’intérieur d’un autre objet ; on lui envoie un message et on le laisse faire.
Ce style s’accorde naturellement avec le liaison tardive (via le dispatch dynamique) : le programme peut décider au moment de l’exécution quelle méthode traite un message, selon l’objet récepteur. Le bénéfice pratique est la flexibilité : on peut remplacer des comportements sans réécrire l’appelant.
Une règle empirique utile : concevez autour des interactions. Demandez « Quels messages devraient exister ? » et « Qui doit posséder cet état ? ». Si les objets collaborent proprement, la structure de classes devient souvent plus simple—et plus facile à faire évoluer—presque comme un effet secondaire.
Une interface graphique a changé le ressenti d’« utiliser un logiciel ». Plutôt que de mémoriser des commandes, vous pointez, déplacez, ouvrez et voyez des résultats immédiatement. Fenêtres, menus, contrôles et glisser-déposer rendent l’informatique plus proche de la manipulation d’objets physiques—une manipulation directe plutôt qu’une instruction abstraite.
Cette « choséité » se transpose naturellement en modèle objet. Dans une GUI bien conçue, presque tout ce que vous voyez et manipulez peut être traité comme un objet :
Ce n’est pas seulement une commodité de programmation ; c’est un pont conceptuel. L’utilisateur raisonne en termes d’objets (« déplace cette fenêtre », « clique ce bouton »), et le logiciel est construit d’objets capables d’accomplir ces actions.
Quand vous cliquez, tapez ou glissez, le système génère un événement. Dans une vision orientée objet, un événement est essentiellement un message envoyé à un objet :
Les objets peuvent alors rediriger les messages vers d’autres objets (« demande au document de sauvegarder », « dis à la fenêtre de se redessiner »), créant une chaîne d’interactions compréhensible.
Parce que l’UI est composée d’objets persistants avec un état visible, on a l’impression d’entrer dans un espace de travail plutôt que d’exécuter une commande ponctuelle. On peut laisser des fenêtres ouvertes, organiser des outils, revenir à un document et reprendre là où on s’est arrêté. L’interface devient un environnement cohérent—un endroit où les actions sont des conversations entre objets que l’on voit.
Une des idées les plus marquantes de Smalltalk n’était pas une caractéristique syntaxique, mais l’image. Plutôt que de voir un programme comme « du code source compilé en application », Smalltalk traitait le système comme un monde en cours d’exécution d’objets. Quand vous sauviez, vous pouviez enregistrer tout l’environnement vivant : objets en mémoire, outils ouverts, état de l’UI et l’état courant de votre travail.
Un système basé sur une image revient à mettre sur pause un film et à sauvegarder non seulement le script, mais la scène exacte et la position de chaque acteur. Quand vous reprenez, vous êtes revenu(e) là où vous étiez—with vos outils encore ouverts, vos objets toujours présents et vos changements déjà en mouvement.
Cela supportait des boucles de rétroaction serrées. Vous pouviez changer un comportement, l’essayer immédiatement, observer ce qui se passait et affiner—sans la remise à zéro mentale de « reconstruire, relancer, recharger les données, naviguer jusqu’à l’écran ».
Ce même principe réapparaît dans des flux de travail modernes axés sur la « vibe-coding » : quand on peut décrire un changement en langage naturel, le voir appliqué tout de suite et itérer, on apprend plus vite et on garde l’élan. Des plateformes comme Koder.ai misent là-dessus en transformant la construction d’apps en une boucle conversationnelle—planifier, ajuster, prévisualiser—tout en produisant du code réel exportable et maintenable.
On retrouve des échos de l’idée d’image dans des fonctionnalités actuelles appréciées :
Ce ne sont pas des images Smalltalk identiques, mais elles partagent l’objectif : réduire la distance entre une idée et son résultat.
Sauvegarder un monde en cours d’exécution pose des questions difficiles. La reproductibilité peut pâtir si « la vérité » vit dans un état mutable plutôt que dans un processus de build propre. Le déploiement devient plus délicat : livrer une image peut brouiller la frontière entre appli, données et environnement. Le débogage peut aussi se complexifier quand des bugs dépendent d’une séquence d’interactions et d’un état accumulé.
Le pari de Smalltalk était que l’apprentissage et l’itération rapides valaient ces complications—et ce pari influence encore la façon dont beaucoup d’équipes pensent l’expérience développeur.
Quand Alan Kay parlait de logiciel, il le considérait souvent moins comme un tas de code que comme un système : de nombreuses parties interagissant au fil du temps pour produire le comportement attendu.
Un système n’est pas défini par un composant unique, mais par des relations—qui parle à qui, ce qu’on peut demander et ce qui se produit quand ces conversations se répètent.
Quelques composants simples peuvent générer des comportements complexes une fois qu’on ajoute la répétition et la rétroaction. Un minuteur qui tic-tac, un modèle qui met à jour l’état et une UI qui redessine sont chacun simples. Assemblés, ils produisent animations, undo/redo, autosave, alertes et moments du type « pourquoi ça a changé ? ».
C’est pourquoi la pensée systémique est pratique : elle vous pousse à chercher des boucles (« quand A change, B réagit, ce qui déclenche C… ») et à prendre en compte le temps (« que se passe-t-il après 10 minutes d’utilisation ? »), pas seulement des appels de fonction isolés.
Dans un système, les interfaces importent plus que l’implémentation. Si une partie n’interagit avec une autre que par des messages clairs (« incrémente le compteur », « rende », « enregistre l’événement »), on peut remplacer l’intérieur sans tout réécrire.
C’est proche de l’emphase de Kay sur le passage de messages : vous ne contrôlez pas directement les autres parties ; vous demandez, elles répondent.
Imaginez trois objets :
Flux dans le temps :
clicked.increment à CounterModel.changed(newValue).changed et se rerend.record("increment", newValue).Aucun composant n’a besoin de fouiller dans un autre. Le comportement émerge de la conversation.
Alan Kay portait une idée simple mais encore surprenante : le logiciel doit être facile à apprendre, pas seulement puissant. Une conception « ingénieuse » optimise souvent la satisfaction du créateur—raccourcis, astuces cachées, abstractions denses—au détriment des utilisateurs qui se retrouvent à mémoriser des rituels.
Kay tenait à la simplicité parce qu’elle scale : un concept qu’un débutant saisit vite est un concept que des équipes peuvent enseigner, partager et utiliser.
Beaucoup de logiciels traitent l’utilisateur comme un opérateur : appuie sur les bons boutons, obtiens la sortie. L’objectif de Kay était plus proche d’un outil de pensée—quelque chose qui invite à l’exploration, soutient l’essai-erreur et laisse les gens construire des modèles mentaux.
C’est pourquoi il valorisait les systèmes interactifs où l’on voit ce qui se passe et où l’on peut ajuster en continu. Quand le système répond immédiatement et de façon pertinente, apprendre devient partie intégrante de l’usage.
Kay utilisait souvent l’apprentissage—imaginant parfois les enfants comme utilisateurs—comme une fonction de contrainte pour la clarté. Si un concept peut être manipulé directement, inspecté et expliqué sans abstraction, il a plus de chances de fonctionner pour tout le monde.
Ce n’est pas « concevoir uniquement pour les enfants ». C’est utiliser la capacité d’enseignement comme test de qualité : le système peut-il révéler sa propre logique ?
L’apprenabilité est une fonctionnalité produit. On peut la concevoir en :
Le gain n’est pas seulement des débutants heureux. C’est un onboarding plus rapide, moins de tickets support et un produit que les gens se sentent capables d’étendre—exactement le type d’« autonomie utilisateur » que Kay voulait amplifier.
Le travail de Kay n’a pas « inventé tout ce que nous utilisons maintenant », mais il a fortement influencé la manière de penser la construction du logiciel—surtout lorsqu’il s’agit de logiciels destinés à des humains, pas seulement aux machines.
Beaucoup de pratiques modernes font écho à des idées que Smalltalk et la culture du PARC ont concrétisées et popularisées :
Certains aspects de la vision originale ne se sont pas transmis intégralement :
Si on plisse les yeux, beaucoup de patterns actuels riment avec le passage de messages : les UIs par composants (React/Vue), les apps pilotées par événements et même les microservices qui communiquent par HTTP ou files. Ce ne sont pas les mêmes choses, mais elles montrent comment l’idée centrale de Kay (le logiciel comme parties qui interagissent) continue d’être réinterprétée sous des contraintes modernes.
Si vous voulez un pont pratique entre l’histoire et la pratique, la dernière section (voir /blog/practical-takeaways) transforme ces influences en habitudes de conception utilisables immédiatement.
Le travail de Kay peut sembler philosophique, mais il se traduit en habitudes très pratiques. Vous n’avez pas besoin d’utiliser Smalltalk—ni même de « faire de l’OOP »—pour en tirer parti. L’objectif est de construire un logiciel qui reste compréhensible en grandissant.
Quand vous démarrez (ou refactorez), essayez de décrire le système comme un ensemble de rôles qui collaborent :
Cela vous garde focalisé sur les responsabilités, pas sur « des classes parce qu’il faut des classes ».
Avant de débattre des tables de base ou des hiérarchies de classes, définissez les messages—ce que l’une des parties demande à une autre de faire.
Un exercice utile : écrivez une courte « conversation » pour une action utilisateur :
Ce n’est qu’après qu’il faut décider comment ces rôles sont implémentés (classes, modules, services). C’est fidèle à l’emphase de Kay sur le passage de messages : comportement d’abord, structure ensuite.
Kay tenait aux systèmes vivants où l’on voit vite l’effet des changements. Dans une équipe moderne, cela se traduit souvent par :
Si vous ne pouvez pas dire ce qui a changé—ou si cela a aidé—vous volez à l’aveugle.
Si vous construisez avec un flux piloté par chat (par exemple Koder.ai), le même conseil s’applique : traitez les prompts et la sortie générée comme un moyen d’itérer plus vite, mais gardez des frontières explicites et des sauvegardes comme snapshots/rollback et export du code source pour que le système reste compréhensible sur le long terme.
Si cela vous a parlé, explorez :
Ces sujets ne sont pas de la nostalgie : ce sont des manières de développer le goût et le sens : construire des logiciels apprenables, adaptables et cohérents en tant que système.
Alan Kay défendait une relation différente avec l’ordinateur : pas des tâches en lot, mais un médium personnel et interactif pour apprendre et créer.
Cette façon de voir a façonné des attentes que nous tenons pour acquises aujourd’hui : retour immédiat, interfaces manipulables et logiciels qu’on peut explorer et modifier pendant qu’on travaille.
Le Dynabook était la vision d’un ordinateur portable et personnel pensé principalement pour l’apprentissage et la créativité (lecture, écriture, dessin, simulation).
Ce n’est pas tant « il a prédit les tablettes » que « il a défini ce que devrait ressentir une informatique qui autonomise » : des utilisateurs comme auteurs, pas seulement comme opérateurs.
Dans Smalltalk, le langage, les outils et l’interface formaient un environnement cohérent.
Concrètement, cela signifie qu’on peut inspecter des objets en cours d’exécution, modifier leur comportement, déboguer de façon interactive et continuer à travailler sans reconstruire et relancer sans cesse—ce qui réduit drastiquement la distance entre une idée et son résultat.
L’idée clé d’Alan Kay n’était pas « classes et héritage », mais des objets comme agents indépendants qui communiquent en s’envoyant des messages.
Sur le plan de la conception, cela vous pousse à définir des frontières claires : les appelants s’appuient sur les messages qu’un objet accepte, pas sur la manière dont il stocke ses données internes.
Une erreur fréquente est de réduire l’OOP à une taxonomie de types : beaucoup de classes, d’héritages profonds et de données mutables partagées.
La règle pratique, selon Kay :
Les interfaces graphiques donnent l’impression de manipuler des choses (fenêtres, boutons, icônes). Cela se prête naturellement à un modèle objet où chaque élément d’UI a un état et un comportement.
Les actions de l’utilisateur (clics, glisser-déposer, frappes) deviennent des événements qui sont, en pratique, des messages adressés aux objets, qui peuvent alors transmettre des requêtes dans le système.
Une image Smalltalk sauvegarde le monde en cours d’exécution : les objets en mémoire, les outils ouverts, l’état de l’UI et votre travail actuel.
Avantages :
Inconvénients :
La pensée systémique met l’accent sur le comportement au fil du temps : boucles de rétroaction, réactions en chaîne et qui communique avec qui.
Concrètement, cela mène à des interfaces plus claires (messages) et à moins de dépendances cachées, parce qu’on conçoit l’application comme des parties qui interagissent plutôt que comme des fonctions isolées.
Adoptez une conception message-first pour un flux :
getTotal, isAvailable, authorize).Ce n’est qu’après que vous choisissez les implémentations (classes, modules, services). Le billet et sa checklist dans /blog/practical-takeaways sont un bon point de départ.
Des parallèles modernes résonnent avec les objectifs de Kay, même s’ils diffèrent techniquement :
Ce ne sont pas des images Smalltalk, mais ils poursuivent la même finalité pratique : rendre le changement et l’apprentissage peu coûteux.