---
title: "Susan Kare dessinait déjà le code avant de toucher au Macintosh"
locale: "fr"
url: "https://irz.fr/fr/articles/susan-kare-macintosh-icons-fr"
markdown_url: "https://irz.fr/fr/articles/susan-kare-macintosh-icons-fr.md"
category: "craft"
tags: ["Susan-Kare", "Macintosh", "icones", "design", "interface"]
published_at: "2026-08-19T09:41:00.000Z"
author: "Arthur Lacoste"
translation: "https://irz.fr/en/articles/susan-kare-macintosh-icons-en.md"
---

# Susan Kare dessinait déjà le code avant de toucher au Macintosh

Papier quadrillé, grille 32 × 32, aperçu à taille réelle puis hexadécimal pour la ROM : les premières icônes du Macintosh sont nées d’une chaîne où dessin et contrainte technique ne faisaient qu’un.

Avant d’être une image sur l’écran du Macintosh, une icône pouvait être une poignée de carrés noircis sur du papier quadrillé.

Susan Kare raconte qu’Andy Hertzfeld, son ami depuis le lycée, lui avait expliqué le problème de manière presque matérielle : prendre du papier à carreaux, fabriquer de petites images avec ces cases, puis les transférer vers l’écran du Macintosh en développement.[1](https://web.stanford.edu/dept/SUL/sites/mac/primary/interviews/kare/mac.html) Kare n’avait alors aucune expérience en infographie. Elle avait étudié l’art, pratiqué le graphisme traditionnel et la sculpture, jusqu’à souder peu auparavant un sanglier grandeur nature pour un musée.[1](https://web.stanford.edu/dept/SUL/sites/mac/primary/interviews/kare/mac.html)

Le passage du sanglier au bitmap semble comique seulement si on imagine l’informatique comme un monde sans matière.

Kare, elle, décrit les bitmaps comme proches de la mosaïque, de la tapisserie ou du point de croix : des pratiques où une image apparaît à partir d’unités discrètes.[1](https://web.stanford.edu/dept/SUL/sites/mac/primary/interviews/kare/mac.html) Le carnet de 1982 conservé par le MoMA rend cette continuité visible. Sur le papier quadrillé, chaque case peut représenter un pixel.[2](https://www.moma.org/collection/works/188382)

Puis le processus change de support sans vraiment changer de logique. Un premier éditeur permet d’allumer ou éteindre des carrés. Andy Hertzfeld construit ensuite un outil 32 × 32 avec chaque pixel affiché huit fois plus grand, accompagné d’un aperçu à taille réelle.[3](https://folklore.org/Steve%2C_Icon.html) Une autre fenêtre transforme le dessin en valeurs hexadécimales prêtes à entrer dans les sources de la ROM.[4](https://folklore.org/Busy_Being_Born%2C_Part_2.html)

La chaîne complète tient presque dans une ligne : **métaphore, croquis, grille, bitmap, hexadécimal, ROM**.

C’est cette chaîne qui rend le travail de Kare toujours intéressant. Pas parce que les pixels noirs et blancs seraient revenus à la mode. Parce que la forme finale, la méthode de dessin et la machine qui doit l’afficher sont pensées ensemble.

> Chaîne de fabrication
> **L’icône ne passe jamais par un espace abstrait**
> - Chercher une métaphore ou un signe que l’utilisateur peut reconnaître.: 1
> - Le réduire à une grille où chaque carré correspond à une décision visible.: 2
> - Comparer en permanence le dessin agrandi et son rendu à taille réelle.: 3
> - Transformer le bitmap en données intégrables au logiciel et à la ROM.: 4
> Le graphisme est déjà contraint par son support d’exécution.

## Le papier quadrillé n’est pas une esthétique rétro

Il serait facile de regarder les carnets aujourd’hui comme des objets charmants, presque artisanaux, puis de conclure que les années 1980 avaient simplement une esthétique plus naïve.

Le quadrillage a une fonction beaucoup plus précise.

Le Macintosh est une machine bitmap. L’écran ne reçoit pas des courbes vectorielles idéales qu’il rasterise ensuite confortablement à toutes les tailles. Pour une petite icône monochrome, le designer décide directement quels pixels existent et lesquels restent blancs. Une diagonale, un œil ou la poignée d’une corbeille deviennent une suite de compromis discrets.

Le papier rend cette unité visible avant même que Kare dispose d’un outil confortable à l’écran.[1](https://web.stanford.edu/dept/SUL/sites/mac/primary/interviews/kare/mac.html)[2](https://www.moma.org/collection/works/188382)

Cette manière de travailler supprime une séparation qui existe souvent aujourd’hui entre dessin source et rendu final. Une icône moderne peut être construite avec des courbes de Bézier dans une immense zone de travail, puis réduite à 16 ou 20 pixels où certains détails deviennent mous, asymétriques ou tout simplement invisibles. Le designer corrige alors le résultat après réduction.

Kare commence presque de l’autre côté. Le rendu final est la surface de travail.

Ça ne signifie pas qu’elle choisit chaque pixel isolément sans vision d’ensemble. Au contraire : la grille oblige à décider quels pixels portent réellement la reconnaissance de la forme. Il n’y a pas assez d’espace pour sauver un dessin faible avec une texture subtile, une ombre élégante ou une variation de couleur.

Une paire de ciseaux doit rester une paire de ciseaux avec très peu d’information. Une feuille doit être distincte d’une application. Une bombe doit signaler l’erreur système sans réclamer un paragraphe explicatif.

Le résultat vient donc moins d’une simplification après coup que d’une conception directement dans le niveau de détail disponible.

## L’éditeur montre deux images du même dessin

En février 1983, Hertzfeld construit pour Kare un éditeur inspiré du mode « Fat Bits » de MacPaint. Une grande fenêtre montre une grille 32 × 32, chaque pixel huit fois plus grand ; une petite fenêtre affiche l’icône à sa vraie taille.[3](https://folklore.org/Steve%2C_Icon.html)

> Illustration: Éditeur d’icônes du Macintosh avec grille agrandie et aperçu à taille réelle. L’outil de 1983 affiche le pixel comme matière de travail tout en gardant le résultat final sous les yeux. Ici, Kare dessine un petit portrait de Steve Jobs. Credit: [Andy Hertzfeld / Folklore.org](https://folklore.org/Steve%2C_Icon.html).

Ce détail d’interface pourrait sembler banal. Il contient pourtant une règle de design très forte : **ne jamais confondre l’espace où l’on travaille avec l’espace où le résultat sera utilisé**.

Sur la grille agrandie, une ligne peut paraître régulière. À taille réelle, elle peut disparaître ou prendre trop de poids. Deux pixels séparés peuvent devenir un bruit. Un seul pixel déplacé peut modifier l’expression d’un visage.

L’outil ne demande pas au designer de mémoriser cette transformation. Il montre les deux versions en même temps.

Kare explique qu’elle a ensuite utilisé MacPaint, qui permettait lui aussi de travailler agrandi tout en voyant le résultat réel, avec des outils pour tracer, effacer ou dessiner des cercles.[1](https://web.stanford.edu/dept/SUL/sites/mac/primary/interviews/kare/mac.html) Le passage du papier au logiciel n’abandonne donc pas la grille : il l’équipe d’un retour immédiat.

On retrouve encore ce principe dans les bons outils de conception d’icônes contemporains. Un dessin à 400 % est trompeur s’il n’est jamais observé à 100 %. Une icône utilisée dans une barre de navigation doit être testée dans cette barre, avec les icônes voisines, pas seulement admirée seule au centre d’un canvas géant.

La technologie a changé. Le problème perceptif est resté presque intact.

## Le bitmap finit littéralement dans le code

Le premier workflow était encore plus direct que l’éditeur 32 × 32.

Kare explique qu’on lui montrait comment prendre son dessin et en calculer l’équivalent hexadécimal afin de le saisir dans la machine.[1](https://web.stanford.edu/dept/SUL/sites/mac/primary/interviews/kare/mac.html) Hertzfeld ajoute ensuite à son outil une « Hex Window » qui produit cette représentation automatiquement.[4](https://folklore.org/Busy_Being_Born%2C_Part_2.html)

Les captures d’époque conservées sur Folklore.org montrent cette étape pour des icônes comme la bombe ou le Happy Mac. La fenêtre d’édition contient le dessin ; une autre partie de l’outil expose les valeurs qui serviront à l’intégrer dans la ROM.[4](https://folklore.org/Busy_Being_Born%2C_Part_2.html)

> Illustration: Capture de l’éditeur d’icônes montrant l’icône bombe du Macintosh et sa représentation destinée à la ROM. Le même objet passe de la grille visuelle à une représentation exploitable dans le code de la ROM. Le design n’est pas livré comme une ressource extérieure abstraite : il entre dans le système logiciel. Credit: [Andy Hertzfeld / Folklore.org](https://folklore.org/Busy_Being_Born%2C_Part_2.html).

Ce passage mérite qu’on s’y attarde.

Aujourd’hui, le fichier d’une icône vit souvent loin de son exécution. Il passe par Figma, un export SVG, un package d’assets, un pipeline de build, un composant UI puis un moteur de rendu. Cette abstraction est extrêmement pratique. On peut ainsi changer un fichier sans penser au format mémoire du framebuffer.

Mais elle rend aussi facile l’oubli de ce qui arrive après l’export.

Les premières icônes du Mac n’offrent pas ce luxe. Le bitmap est déjà une forme directement exploitable par la machine. Le designer voit presque physiquement le coût d’un pixel et sa traduction en bits.

Cela ne signifie pas qu’un designer moderne devrait écrire ses SVG en hexadécimal, punition qui ne profiterait à personne. Cela rappelle plutôt qu’un asset d’interface reste une donnée exécutée dans un contexte technique : résolution, rendu, contraste, densité, mémoire, latence, accessibilité.

L’abstraction est utile tant qu’elle ne masque pas le comportement final.

## Une bonne métaphore n’a pas besoin d’être littérale

La contrainte du pixel n’explique pas toute la réussite des icônes de Kare. Une forme parfaitement nette peut rester incompréhensible.

Dans son entretien avec Stanford, elle décrit sa méthode comme peu scientifique au sens académique, mais très attentive aux réactions. Elle proposait plusieurs idées, les montrait autour d’elle, puis observait ce qui fonctionnait.[1](https://web.stanford.edu/dept/SUL/sites/mac/primary/interviews/kare/mac.html)

Pour l’outil de remplissage de MacPaint, elle teste notamment le rouleau de peinture avant de retenir le pot qui verse sa peinture, plus immédiatement compris par les personnes interrogées.[1](https://web.stanford.edu/dept/SUL/sites/mac/primary/interviews/kare/mac.html)

Sa définition d’une bonne icône reste exigeante : quelqu’un qui ne l’a jamais vue devrait idéalement pouvoir comprendre sa fonction, ou l’apprendre une fois puis s’en souvenir facilement.[1](https://web.stanford.edu/dept/SUL/sites/mac/primary/interviews/kare/mac.html)

C’est déjà une distinction importante entre **reconnaissance immédiate** et **mémorisation**.

Toutes les fonctions informatiques n’ont pas un équivalent visuel évident. « Couper » peut emprunter les ciseaux. « Supprimer » peut emprunter une corbeille. « Annuler », « synchroniser », « partager une branche Git » ou « basculer un état de confidentialité » deviennent beaucoup moins littéraux.

Kare ne prétend pas qu’un symbole mystérieux peut devenir universel par la seule qualité de son dessin. Elle cherche aussi dans des répertoires de signes existants.

Son choix pour la touche Command est l’exemple le plus célèbre.

## Le symbole Command vient d’un problème de densité visuelle

Au départ, les commandes clavier du Macintosh étaient signalées dans les menus par le logo Apple. Steve Jobs juge qu’il y en a trop à l’écran et demande un autre symbole.[5](https://folklore.org/Swedish_Campground.html)

La difficulté est amusante : comment dessiner « commande » ?

Kare se souvient avoir essayé plusieurs métaphores, dont des signes plus autoritaires comme un badge, avant de les trouver trop durs. Elle ouvre alors ses livres de symboles et tombe sur le signe aujourd’hui associé à ⌘, présenté comme un marqueur scandinave d’un lieu ou élément remarquable.[1](https://web.stanford.edu/dept/SUL/sites/mac/primary/interviews/kare/mac.html)[5](https://folklore.org/Swedish_Campground.html)

Elle le choisit justement parce qu’il est abstrait, distinctif, amical et facile à rendre en pixels.[1](https://web.stanford.edu/dept/SUL/sites/mac/primary/interviews/kare/mac.html)

Ce cas contredit une règle trop simple du design d’icônes : « toujours représenter l’action par un objet réel connu ».

Le symbole Command n’explique pas naturellement ce qu’est une commande informatique. Son avantage est ailleurs. Il est facile à reconnaître, facile à reproduire, suffisamment neutre pour apparaître à côté de dizaines d’actions différentes et assez rare pour ne pas être confondu avec une autre fonction.

Il devient compréhensible par apprentissage.

C’est exactement ce que Kare autorise dans sa propre définition : si le sens n’est pas immédiatement évident, une seule explication devrait idéalement suffire pour que le symbole reste en mémoire.[1](https://web.stanford.edu/dept/SUL/sites/mac/primary/interviews/kare/mac.html)

La bonne icône n’est donc pas toujours une phrase complète en miniature. Elle peut être un mot nouveau dans un vocabulaire cohérent.

## Les métaphores sont aussi choisies pour leurs différences entre elles

Le document et l’application posent un autre problème.

Kare raconte que la feuille avec son coin plié existait déjà et fonctionnait bien pour les documents. Elle veut en revanche que les applications paraissent plus « actives ». Elle dessine alors la main tenant un crayon contre une forme en losange, de manière à rendre applications et documents rapidement distincts.[1](https://web.stanford.edu/dept/SUL/sites/mac/primary/interviews/kare/mac.html)

À ce stade, « quelle image représente une application ? » devient une question trop petite.

La question devient « quelle image représente une application **sans pouvoir être confondue avec le document qui se trouve à côté** ? ».

Cette différence est cruciale dans un système d’icônes.

On juge facilement une icône isolée. Pourtant l’utilisateur rencontre un ensemble. Deux dessins individuellement très beaux peuvent produire une mauvaise interface s’ils possèdent la même silhouette, le même centre de masse ou des détails qui disparaissent à petite taille.

Kare travaille dans un environnement où peu de pixels forcent déjà cette discipline. La silhouette compte énormément. Les masses noires doivent se distribuer différemment. Le signe doit rester reconnaissable dans une famille.

Le graphisme devient syntaxe.

## La disquette, la bombe, le lapin : les objets ne sont pas tous du même registre

La grammaire du Macintosh mélange plusieurs types de références.

Certaines sont presque fonctionnelles. La disquette représente le support amovible. Le document ressemble à une feuille. La corbeille reçoit ce qu’on supprime.

D’autres sont plus expressives. La bombe signale une erreur système avec un humour noir très littéral. Le Happy Mac personnifie le démarrage. Dans le panneau de contrôle, le lapin et la tortue représentent des vitesses différentes.[1](https://web.stanford.edu/dept/SUL/sites/mac/primary/interviews/kare/mac.html)

Cette variété est importante parce qu’un système cohérent ne signifie pas nécessairement une collection de symboles construits avec la même métaphore.

La cohérence peut venir d’ailleurs : même grille, même poids visuel, même contraste, même logique de simplification, même ton.

C’est peut-être une des raisons pour lesquelles ces icônes gardent une personnalité collective malgré des sujets très différents. Elles ne sont pas dessinées comme les déclinaisons géométriques d’un logo. Elles partagent plutôt une méthode de réduction.

> Illustration: Capture du Finder ancien montrant une icône de disquette Macintosh. Dans le Finder, l’icône est vue avec les autres éléments de l’interface. Sa réussite dépend autant de sa silhouette et de son échelle que du dessin isolé. Credit: [Andy Hertzfeld / Folklore.org](https://folklore.org/Busy_Being_Born%2C_Part_2.html).

## Les polices viennent du même problème : dessiner pour une matrice

Le travail de Kare ne s’arrête pas aux pictogrammes. Elle dessine aussi les premières polices bitmap du Macintosh.

Dans un texte publié sur Folklore.org, elle raconte que le premier caractère système, surnommé provisoirement « Elefont », est conçu comme une police grasse évitant des diagonales trop dentelées. Les noms changent ensuite : Chicago, New York, Geneva, London, Toronto, Venice.[6](https://folklore.org/World_Class_Cities.html)

La police proportionnelle est elle-même une démonstration de la philosophie du Macintosh. Toutes les lettres n’occupent plus nécessairement la même largeur. Le `i` peut être étroit et le `m` plus large.[6](https://folklore.org/World_Class_Cities.html)

Mais là encore, le luxe typographique reste contenu par la matrice de pixels.

Il faut décider comment une courbe, une diagonale ou une différence d’épaisseur survit à petite taille. La lettre est une miniature fonctionnelle exactement comme l’icône.

Cette proximité entre typographie et iconographie est intéressante aujourd’hui parce que les design systems les ont souvent séparées en bibliothèques distinctes. D’un côté la fonte variable, de l’autre le package d’icônes SVG.

Pour Kare, elles appartiennent au même environnement perceptif. Elles doivent partager une densité, une échelle et un ton compatibles sur le même écran.

## MacPaint remplace progressivement le papier sans supprimer le feedback

Une fois MacPaint utilisable, Kare l’emploie beaucoup pour ses graphiques.[1](https://web.stanford.edu/dept/SUL/sites/mac/primary/interviews/kare/mac.html) Andy Hertzfeld raconte qu’elle en devient même l’une des premières utilisatrices expertes, testant les fonctions à mesure que Bill Atkinson les construit.[7](https://computerhistory.org/profile/susan-kare/)

Les archives montrent des documents MacPaint produits pendant que l’équipe termine le Macintosh en 1983. Le logiciel devient à la fois outil de production et objet testé par l’artiste qui en fabrique une partie du langage visuel.[7](https://computerhistory.org/profile/susan-kare/)

> Illustration: Capture ancienne de MacPaint pendant le développement du Macintosh. MacPaint devient progressivement l’atelier numérique de Kare : dessin agrandi, résultat visible à taille réelle et outils construits pendant que l’interface du Mac elle-même prend forme. Credit: [Andy Hertzfeld / Folklore.org](https://folklore.org/Busy_Being_Born%2C_Part_2.html).

Ce circuit est assez rare dans un produit mature.

Le logiciel de dessin est encore en construction. Son utilisatrice experte conçoit les symboles de l’ordinateur sur lequel il tourne. Les retours sur l’outil et les besoins du graphisme peuvent se rencontrer presque dans la même pièce.

L’histoire du Mac est remplie de ce genre de boucles courtes entre design et ingénierie. Il ne faut pas les romantiser : elles viennent aussi d’une petite équipe travaillant énormément sous pression. Mais elles expliquent pourquoi certains détails ne semblent pas avoir été déposés tardivement sur une architecture déjà figée.

Le design du bitmap et son outil d’édition évoluent ensemble.

## Le pixel unique impose une forme de responsabilité

Kare parle aussi des curseurs, pour lesquels un pixel précis doit servir de point actif.[1](https://web.stanford.edu/dept/SUL/sites/mac/primary/interviews/kare/mac.html)

Le problème est minuscule et très concret. Une flèche de souris peut sembler visuellement correcte tout en étant pénible à utiliser si le point réellement sélectionné par le système ne correspond pas à l’endroit où l’utilisateur pense viser.

Le dessin possède alors une conséquence opérationnelle pixel par pixel.

Cette idée existe encore partout, même si les écrans ont des millions de pixels de plus. Une zone cliquable trop petite, un centre optique mal placé ou un pictogramme ambigu transforme une décision graphique en friction fonctionnelle.

La haute résolution permet de masquer davantage ces relations. Elle ne les supprime pas.

Kare travaillait dans un environnement où la machine obligeait à les voir.

## Ce que les systèmes d’icônes modernes ont gagné

Un système d’icônes actuel dispose évidemment de possibilités que le Macintosh original n’avait pas.

Le vectoriel permet des échelles multiples. Les grilles peuvent être paramétriques. On gère des variantes de poids. La couleur participe au sens. Les interfaces s’adaptent à plusieurs densités d’écran, aux thèmes sombres, à l’accessibilité et à des dizaines de contextes.

Il serait absurde de revenir au monochrome 32 × 32 par principe moral.

La contrainte historique n’est pas une vertu en elle-même. Si Kare travaillait avec une grille rigide, c’est parce que le produit avait réellement cette limite. Transformer aujourd’hui cette limite en filtre esthétique nostalgique reviendrait à copier le symptôme plutôt que la méthode.

La méthode intéressante est ailleurs : **faire remonter les contraintes du rendu jusque dans l’outil de conception**.

Si une icône doit fonctionner à 16 pixels, la voir à 16 pixels pendant le travail. Si elle doit être comprise au milieu de vingt autres, la tester au milieu de vingt autres. Si elle existe en mode clair et sombre, les deux états doivent être présents avant l’export final. Si l’utilisateur peut l’interpréter de deux manières, la tester sur des humains avant de fabriquer une théorie élégante pour expliquer pourquoi elle aurait dû être évidente.

C’est exactement le mouvement que l’éditeur 32 × 32 réalisait avec des moyens minuscules.

## Ce que nous avons perdu : le coût visible de chaque détail

Les outils modernes rendent la production incroyablement rapide. Une bibliothèque peut contenir des milliers d’icônes. Un designer peut dupliquer, aligner et décliner des variantes en quelques secondes. Un modèle génératif peut proposer encore plus de formes avant même le premier café.

L’abondance crée un nouveau problème.

Quand une icône coûtait des heures ou des jours et devait tenir dans une petite quantité de mémoire, ajouter un symbole n’était pas anodin.[1](https://web.stanford.edu/dept/SUL/sites/mac/primary/interviews/kare/mac.html) Aujourd’hui, le coût marginal d’un SVG supplémentaire paraît presque nul.

Mais son coût cognitif n’est pas nul.

Chaque nouveau pictogramme doit être appris, distingué, traduit, documenté, rendu accessible et maintenu. Une bibliothèque de 1 500 icônes peut être excellente pour le designer et parfaitement incompréhensible pour l’utilisateur si l’application en utilise cinquante sans logique.

La rareté matérielle du Macintosh imposait indirectement une rareté éditoriale.

Nous n’avons aucune raison de reproduire sa limite mémoire. Nous avons peut-être intérêt à reproduire la question qu’elle forçait : **ce détail mérite-t-il vraiment d’exister ?**

## La grille de Kare n’est donc pas un style, mais une relation au produit

Le carnet quadrillé est devenu une image presque parfaite de la naissance de l’interface graphique moderne. C’est aussi un piège.

On peut le regarder comme la preuve que le pixel art est charmant, puis fabriquer des icônes rétro qui imitent une époque. Ce serait manquer l’essentiel.

Le papier est utile parce qu’il possède la même unité que l’écran. L’éditeur est utile parce qu’il montre le dessin agrandi et son usage réel. La fenêtre hexadécimale est utile parce qu’elle relie le bitmap à la ROM. Les tests informels sont utiles parce qu’ils confrontent la métaphore au cerveau de quelqu’un d’autre.

À chaque étape, la représentation se rapproche du produit au lieu de s’en éloigner.

C’est probablement la leçon la plus actuelle du travail de Susan Kare.

Une icône réussie n’est pas un petit dessin qu’on verse ensuite dans une interface. Elle est fabriquée à l’endroit où se rencontrent langage, perception, outil et machine.

En 1983, cet endroit faisait 32 pixels de côté.

## References

1. [Stanford, interview de Susan Kare, Working on the Macintosh](https://web.stanford.edu/dept/SUL/sites/mac/primary/interviews/kare/mac.html)
2. [MoMA, Apple Macintosh OS icon sketchbook, 1982](https://www.moma.org/collection/works/188382)
3. [Folklore.org, Steve Icon, Andy Hertzfeld](https://folklore.org/Steve%2C_Icon.html)
4. [Folklore.org, Busy Being Born, Part 2](https://folklore.org/Busy_Being_Born%2C_Part_2.html)
5. [Folklore.org, Swedish Campground](https://folklore.org/Swedish_Campground.html)
6. [Folklore.org, World Class Cities, Susan Kare](https://folklore.org/World_Class_Cities.html)
7. [Computer History Museum, Susan Kare](https://computerhistory.org/profile/susan-kare/)