Design de systèmes d'icônes : bâtir une iconographie qui tient au-delà de 50 symboles
Le guide d'un designer en activité sur les systèmes d'icônes. Grille, graisse, correction optique, nommage, gouvernance, et les règles qui évitent qu'une bibliothèque d'icônes pourrisse dès le troisième designer.
La plupart des bibliothèques d'icônes de produit pourrissent. Le premier designer livre un jeu propre de quarante symboles. Le deuxième en a besoin de trois de plus et les décalque à main levée avec la mauvaise épaisseur de trait. Le troisième télécharge un pack gratuit pour livrer une fonctionnalité un vendredi. À la deuxième année du produit, la colonne d'icônes de chaque écran ressemble à quatre marques différentes cousues dans une seule navigation.
Ce papier est la version de terrain. Grille, graisse, correction optique, nommage, gouvernance, et le petit ensemble de règles qui garde un système d'icônes cohérent au-delà de 50 symboles. Pas de vitrines d'icônes de la semaine, pas de templates qui se prennent pour des systèmes, juste les décisions qui permettent à une vraie bibliothèque de survivre à une vraie équipe.
Ce qu'est vraiment un système d'icônes
Un système d'icônes est un ensemble cohérent de pictogrammes régi par des règles partagées. Taille de grille, épaisseur de trait, rayon des coins, alignement optique, nommage, et processus pour ajouter de nouvelles icônes. Le but n'est pas un dossier de SVG. Le but est un système que n'importe quel designer ou ingénieur peut étendre sans casser le rythme visuel du produit.
Un tas d'icônes n'est pas un système. Un fichier Figma avec 200 symboles et aucune règle n'est pas un système. Un système a des contraintes, des décisions nommées et un processus écrit pour le moment où quelqu'un a besoin d'une icône qui n'existe pas encore.
Le guide des design systems couvre le système plus large dans lequel vivent les icônes. Ce papier creuse spécifiquement la couche iconographique.
Pourquoi les icônes comptent plus qu'elles n'en ont l'air
Les icônes sont l'élément d'UI le plus dense de tout produit. Une seule icône de 24x24 pixels porte plus de sens par centimètre carré que n'importe quel autre élément de l'écran. Soignez le système et le produit se lit comme un tout. Ratez-le et chaque écran sonne faux, d'une façon que les utilisateurs ne savent pas formuler.
Les icônes se comportent aussi bizarrement à l'échelle. Une dérive typographique entre deux écrans se repère facilement. Une dérive d'icônes est plus difficile à nommer mais plus bruyante à l'œil. Le cerveau traite les pictogrammes plus vite que le texte, donc il repère l'incohérence des icônes plus vite que celle du texte.
Le produit qui livre ses icônes comme un système cohérent paraît soigné même quand le reste est brut. Le produit qui les livre en roue libre paraît cheap même quand le reste est affûté.
La grille est le système
Chaque bibliothèque d'icônes cohérente commence par une grille. La grille est l'échafaudage invisible sur lequel chaque icône s'aimante. Sans elle, les icônes dérivent en taille, en graisse et en équilibre optique, et il n'y a aucun moyen d'imposer la cohérence en revue de code.
La grille de base
Choisissez une taille de grille de base et vivez dedans. Les deux standards qui fonctionnent en 2026 :
- Grille de 24 pixels pour les icônes d'UI produit. Taille standard de la plupart des interfaces modernes.
- Grille de 20 pixels pour les interfaces de données denses, les dashboards et les outils d'administration.
Une grille, ce n'est pas seulement la taille du canevas. C'est aussi la zone utile à l'intérieur du canevas où l'icône se place réellement. Une grille de 24 pixels a une zone utile de 20 pixels, avec 2 pixels de marge de chaque côté. Cette marge laisse l'icône respirer et évite qu'elle paraisse à l'étroit contre les éléments voisins.
Les lignes-guides dans la grille
La zone utile contient des lignes-guides internes qui régissent les formes. Une zone utile de 20 pixels reçoit quatre formes de référence :
| Forme | Taille | Usage |
|---|---|---|
| Carré | 18x18 px | La plupart des icônes rectangulaires (dossier, document) |
| Cercle | 20x20 px | Icônes rondes (soleil, info, avatar) |
| Rectangle vertical | 16x20 px | Icônes verticales (batterie, téléphone) |
| Rectangle horizontal | 20x16 px | Icônes horizontales (recherche, message) |
Chaque ligne-guide produit une icône visuellement équilibrée à la même taille. Un cercle dessiné à 18 pixels paraît plus petit qu'un carré à 18 pixels parce que l'œil humain lit les cercles comme plus petits. Les lignes-guides compensent cette bizarrerie perceptive.
L'épaisseur de trait comme token
Choisissez une épaisseur de trait et tenez-vous-y. La plupart des systèmes d'icônes produit utilisent des traits de 1,5 ou 2 pixels sur la grille de 24 pixels. Choisissez selon la voix de marque.
Un trait de 1,5 pixel se lit léger, technique et moderne. Un trait de 2 pixels se lit assuré, amical et accessible. Un trait de 3 pixels se lit gras, enfantin ou façon imprimé. Choisissez-en un. Documentez-le comme un token. Rejetez toute contribution qui utilise une autre épaisseur.
Le glossaire des design tokens explique comment l'épaisseur de trait s'insère dans l'architecture de tokens plus large.
La correction optique fait la différence
L'alignement mathématique n'est pas l'alignement visuel. Des icônes parfaitement alignées sur la grille paraissent souvent fausses, parce que l'œil humain ne mesure pas des pixels : il mesure le poids et l'équilibre perçus.
Pourquoi la correction optique existe
Un cercle de 20x20 pixels et un carré de 20x20 pixels ne se lisent pas comme de la même taille. Le carré a plus de masse visuelle parce qu'il remplit entièrement sa boîte englobante. Le cercle a du vide dans les coins, que l'œil enregistre comme un objet plus petit.
La solution est de dessiner le cercle légèrement plus grand que la boîte englobante, parfois de 1 à 2 pixels. Les maths disent faux, l'œil dit juste. Faites toujours confiance à l'œil.
Les corrections optiques courantes
Cinq corrections couvrent l'essentiel du travail d'icônes :
- Les cercles paraissent plus grands que les carrés. Augmentez les lignes-guides des cercles de 1 à 2 pixels.
- Les triangles paraissent plus petits que les carrés. Augmentez les lignes-guides des triangles de 2 à 3 pixels.
- Les diagonales paraissent plus fines que les horizontales. Ajoutez 0,25 à 0,5 pixel d'épaisseur aux diagonales.
- Le centre des icônes asymétriques dérive. Centrez optiquement les boutons play, les flèches et les chevrons à l'œil, jamais selon la boîte englobante.
- Les angles vifs paraissent plus petits. Arrondissez légèrement les angles intérieurs pour égaler le poids perçu des angles extérieurs.
Ces corrections ne sont pas une opinion. Testez n'importe quelle icône avec une version parfaite mathématiquement et une version corrigée optiquement, côte à côte, à petite taille. La version corrigée optiquement gagne. Toujours.
Des choix de style qui se cumulent
Une fois la grille et les épaisseurs fixées, chaque autre décision de style doit être prise une fois et appliquée partout. L'incohérence sur l'un de ces points donne l'impression que la bibliothèque a été touchée par trop de mains.
Rayon des coins
Choisissez un rayon de coin extérieur et un rayon de coin intérieur. Les deux fonctionnent en paire.
Un rayon extérieur de 1 pixel et un rayon intérieur de 0,5 pixel se lisent nets et modernes. Un rayon extérieur de 2 pixels et un rayon intérieur de 1 pixel se lisent amicaux et arrondis. Un jeu à angles droits sans rayon se lit architectural et sérieux.
L'erreur est de mélanger les rayons dans une même bibliothèque. Même une seule icône aux angles plus vifs que les autres a l'air empruntée à un autre jeu.
Terminaisons et jointures
Les traits ont des extrémités. Les terminaisons peuvent être carrées, rondes ou saillantes. Les jointures entre traits peuvent être en onglet (vives), rondes ou biseautées (coupées). Choisissez-en une de chaque et appliquez-la dans tout le système.
Des terminaisons rondes et des jointures rondes donnent un jeu d'icônes amical et accessible. Des terminaisons carrées et des jointures en onglet donnent un jeu précis et technique. Des terminaisons mélangées dans la même bibliothèque donnent un jeu qui a l'air à moitié fini.
Plein ou contour
La plupart des systèmes d'icônes modernes livrent deux variantes de chaque icône : une version contour pour les états inactifs et une version pleine pour les états actifs. La version contour utilise le trait. La version pleine utilise la même forme avec l'intérieur rempli.
Les deux variantes doivent être visuellement équilibrées. Une version pleine à la même taille se lit souvent plus lourde et plus dominante que le contour. La solution est de réduire légèrement l'empreinte de la version pleine de 1 à 2 pixels pour que le poids visuel corresponde à celui du contour à la même échelle.
Le glossaire de l'état de focus explique comment le passage de contour à plein s'intègre dans la conception plus large des états d'interaction.
Nommer les icônes, c'est la moitié du système
Une bibliothèque de 200 icônes bien dessinées que personne ne retrouve est une bibliothèque que personne n'utilise. Le nommage est la couche de découvrabilité, et un mauvais nommage tue l'adoption plus vite qu'un mauvais dessin.
Des conventions de nommage qui passent à l'échelle
Nommez d'abord par objet, pas par métaphore. L'icône de la loupe s'appelle search ou magnifier, jamais find ou look. L'objet est stable. La métaphore change selon le contexte.
Utilisez le kebab-case pour les icônes à plusieurs mots : arrow-left, chevron-down, cloud-upload. La cohérence de casse permet aux ingénieurs de faire un grep dans la bibliothèque, de l'autocompléter dans les IDE et de livrer sans fautes de frappe.
N'utilisez des suffixes directionnels que si nécessaire. arrow ne suffit pas. arrow-left, arrow-right, arrow-up, arrow-down est le jeu minimum. Idem pour les chevrons, les carets et tout autre pictogramme directionnel.
Nommage des variantes
Quand une icône a plusieurs variantes (contour, pleine, bicolore), ajoutez la variante en suffixe :
search(contour par défaut)search-filledsearch-duotone
Ce schéma permet à l'ingénieur de tirer search-filled dans un bouton sans fouiller un dossier séparé. Un nommage prévisible vaut mieux qu'une organisation parfaite.
Cartes de synonymes
Le plus gros échec de nommage, c'est l'icône qu'un designer ne trouve pas parce qu'il a cherché le mauvais mot. Construisez une carte de synonymes à côté de la bibliothèque. cart correspond aussi à bag, shopping. home correspond aussi à house, dashboard. delete correspond aussi à trash, remove, bin.
La plupart des outils modernes de recherche d'icônes (Iconify, Lucide, Phosphor) intègrent des cartes de synonymes dans leur interface de recherche. Faites pareil dans la bibliothèque interne, ou acceptez que les designers continueront à ajouter des icônes en double parce qu'ils n'ont pas trouvé l'existante.
La gouvernance garde le système en vie
Les décisions techniques ci-dessus sont reproductibles par n'importe quel designer compétent. Ce sont les décisions de gouvernance qui séparent un système qui vit d'un système qui meurt en année deux.
La source unique de vérité
Choisissez un seul endroit où vivent les icônes. Une bibliothèque Figma, un dépôt de code avec des SVG, ou un service hébergé comme Iconify. Un seul. La bibliothèque vit là. Chaque designer y puise. Chaque ingénieur y puise.
Un système avec deux sources de vérité a zéro source de vérité. La bibliothèque Figma et la bibliothèque de code vont dériver dès la troisième semaine, et dès lors chaque écran livre des icônes qui ne correspondent pas au système.
Le processus de contribution
Documentez le processus d'ajout d'une nouvelle icône. Il doit inclure :
- Chercher d'abord. Vérifiez que l'icône n'existe pas déjà sous un autre nom.
- Justifier l'ajout. Écrivez une phrase sur ce que représente l'icône et où elle sera utilisée.
- Dessiner selon la spec. Respectez la grille, l'épaisseur de trait, le rayon des coins, les terminaisons et les jointures de la bibliothèque existante.
- Revue optique. Un second designer vérifie l'équilibre visuel de l'icône aux tailles de 16, 20 et 24 pixels.
- Nommer et livrer. Le nom suit la convention de nommage. Livrez à la fois dans Figma et dans le code, dans la même PR.
Un système sans processus de contribution est un système qu'on contourne. La première fois qu'un designer a besoin d'une icône en urgence, il la télécharge depuis un pack gratuit et la livre sans demander. Dès lors, la bibliothèque a un fork.
Le processus de dépréciation
Les icônes sont dépréciées. Une refonte retire un ancien style, une fonctionnalité est supprimée, un rafraîchissement de marque change le langage visuel. Documentez comment les icônes quittent la bibliothèque, pas seulement comment elles y entrent.
Marquez les icônes dépréciées dans la bibliothèque avec une étiquette visible. Gardez-les disponibles 90 jours pour que les écrans existants aient le temps de migrer. Puis supprimez-les. Une bibliothèque qui ne retire jamais d'icônes devient un musée, et les musées, on les ignore.
Comment les icônes arrivent dans le code
Le passage de relais entre design et code est l'endroit où la plupart des systèmes d'icônes cassent. La bibliothèque Figma est impeccable, la bibliothèque de code est un cimetière de SVG incohérents, et les ingénieurs ne font plus confiance à aucune des deux.
Le SVG est le format
Livrez les icônes en SVG. Pas en PNG, pas en polices d'icônes. Le SVG est vectoriel, se met à l'échelle sans perte, supporte l'héritage de la couleur courante pour un theming facile, et reste assez léger pour être inliné dans les composants.
Chaque SVG a une viewBox correspondant à la grille (24x24 ou 20x20), utilise currentColor pour le trait et le remplissage, et exclut les transformations ou styles redondants. Un SVG propre pèse moins de 1 Ko. La plupart des bibliothèques livrent des icônes de 3 à 5 Ko parce qu'elles ont été exportées avec les réglages par défaut, qui embarquent métadonnées, transformations et styles inline dont personne n'a besoin.
L'optimisation n'est pas négociable
Passez chaque SVG dans SVGO avant qu'il n'atterrisse dans le dépôt de code. SVGO supprime les métadonnées, simplifie les tracés, retire les attributs redondants et réduit la taille du fichier de 60 à 80 % en moyenne.
Pour une bibliothèque de 200 icônes, la différence entre non optimisé et optimisé représente généralement 400 Ko à chaque chargement de page. C'est un coup sur Lighthouse, une régression des core web vitals et une expérience mobile plus lente sans aucune raison.
Les composants enveloppes
Enveloppez chaque SVG dans un composant typé (React, Vue, Svelte). Le composant prend des props de taille, de couleur et d'accessibilité. L'ingénieur n'importe jamais un SVG brut. Il importe un <Icon name="search" size={20} /> et le système gère le reste.
Ce schéma permet à la bibliothèque d'icônes de changer son format d'export sous-jacent (SVG, sprite, police d'icônes) sans toucher au code consommateur. Le composant est l'API, le SVG est l'implémentation.
Le glossaire du design handoff couvre la discipline de passage de relais au sens large. Les icônes sont l'un des rares cas où designers et ingénieurs partagent vraiment la propriété.
Les échecs courants des systèmes d'icônes
Chaque audit d'icônes relève les mêmes échecs. Si le système en livre un seul, la bibliothèque est à une refonte d'une réécriture complète.
Trois épaisseurs de trait dans une bibliothèque. Signifie presque toujours que la bibliothèque a été assemblée à partir de plusieurs packs gratuits. La solution est de redessiner de force tout le jeu avec une seule épaisseur.
Variantes pleines et contour à des échelles différentes. La version pleine paraît plus grande que le contour parce que personne n'a compensé le poids perçu. La solution est de réduire la version pleine de 1 à 2 pixels jusqu'à ce que les deux se lisent comme de la même taille.
Rayon de coin incohérent. La moitié des icônes a des angles arrondis, l'autre moitié des angles droits. Presque toujours parce que deux designers différents ont contribué sans règle écrite. La solution est de définir un rayon et de refactorer.
Nommage par métaphore. Des icônes nommées find, look, discover au lieu de l'objet qu'elles représentent. Les designers ne les trouvent pas. La solution est de renommer selon des conventions orientées objet.
Aucun processus de dépréciation. La bibliothèque compte 350 icônes, dont 80 inutilisées ou remplacées. Le surpoids ralentit la recherche et déroute les nouveaux designers. La solution est un audit trimestriel et un cycle de dépréciation de 90 jours.
Les systèmes d'icônes dans les conditions de 2026
Trois changements ont modifié la façon de construire les systèmes d'icônes. Le système doit leur survivre.
Les polices d'icônes variables sont réelles. De nouveaux formats permettent à un seul fichier d'icône de porter plusieurs graisses, remplissages et tailles optiques qui s'interpolent en douceur. L'avantage technique est énorme, le risque de design est que les équipes livrent chaque variante sur chaque écran parce qu'elles le peuvent. Choisissez les variantes qui sont livrées. Coupez le reste.
Les outils d'IA génèrent des icônes en quelques secondes. Midjourney, DALL-E et ChatGPT peuvent produire une icône passable en un seul prompt. Le risque est que les designers cessent de dessiner les icônes et se mettent à les prompter, ce qui tue la cohérence du système parce que chaque prompt produit un style légèrement différent. Utilisez l'IA pour les premiers jets. Refactorez chaque résultat pour qu'il colle au système.
Lucide, Phosphor et Heroicons fixent la base. Ces bibliothèques ouvertes livrent plus de 1500 icônes avec une grille, une graisse et un nommage cohérents. Pour la plupart des produits, partir de l'une d'elles et la personnaliser est plus rapide et meilleur que de construire de zéro. Les icônes sur mesure ne se dessinent que pour les concepts propres au produit que les bibliothèques ouvertes ne couvrent pas.
Le glossaire wcag couvre les bases d'accessibilité qui régissent le contraste et l'étiquetage des icônes. Les icônes dans les éléments interactifs ont besoin de noms accessibles, pas seulement de libellés visuels.
FAQ
Quelle taille de grille un système d'icônes doit-il utiliser ?
Grille de 24 pixels pour l'UI produit générale, grille de 20 pixels pour les interfaces de données denses. La grille a une marge de 2 pixels de chaque côté, laissant une zone utile de 20 ou 16 pixels où l'icône se place réellement. Choisissez-en une et vivez dedans pour toute la bibliothèque.
Quelle épaisseur pour les traits d'icônes ?
1,5 à 2 pixels sur une grille de 24 pixels. 1,5 pixel se lit léger et technique, 2 pixels se lit assuré et amical. Choisissez une épaisseur, documentez-la comme un token et rejetez toute contribution qui en utilise une autre.
Qu'est-ce que la correction optique en design d'icônes ?
La pratique qui consiste à ajuster les icônes pour qu'elles paraissent équilibrées même quand les maths disent qu'elles sont alignées. Les cercles paraissent plus grands que les carrés, les triangles plus petits, les diagonales plus fines que les horizontales. La correction optique compense ces bizarreries perceptives. Faites toujours confiance à l'œil plutôt qu'à la boîte englobante.
Les icônes doivent-elles être pleines ou en contour ?
La plupart des systèmes modernes livrent les deux. Contour pour les états inactifs, plein pour les états actifs. Les deux variantes doivent être visuellement équilibrées, ce qui signifie généralement que la version pleine est 1 à 2 pixels plus petite que le contour pour que le poids perçu corresponde.
Comment nommer les icônes dans un design system ?
D'abord l'objet, en kebab-case, avec des suffixes directionnels si nécessaire. Search, pas find. Arrow-left, pas back. Utilisez des cartes de synonymes pour que les designers puissent chercher avec des mots alternatifs. Ajoutez des suffixes de variante (filled, duotone) pour que les ingénieurs récupèrent la bonne variante en un seul import.
Quand créer des icônes sur mesure plutôt que d'utiliser une bibliothèque ouverte ?
Partez d'une bibliothèque ouverte (Lucide, Phosphor, Heroicons). Ne dessinez sur mesure que les concepts propres au produit que ces bibliothèques ne couvrent pas. Construire un jeu de 300 icônes de zéro en 2026 est presque toujours un effort gaspillé. Personnalisez la base ouverte, documentez les ajouts, livrez.
Le système se rembourse tout seul
Une bibliothèque d'icônes cohérente est le moyen le moins cher de rendre un produit soigné. Une bibliothèque qui dérive est le moyen le plus rapide de le rendre cheap. Le coût de construction du système, c'est une à deux semaines de travail rigoureux. Le coût de ne pas le construire, c'est une taxe visuelle permanente sur chaque écran que le produit livre, pour toujours.
Choisissez une grille. Choisissez une épaisseur. Choisissez un rayon de coin. Choisissez une convention de nommage. Écrivez le processus de contribution et de dépréciation. Optimisez les SVG. Enveloppez-les dans un composant typé. Puis imposez tout cela en revue de code.
La colonne d'icônes de chaque écran est l'un des signaux de qualité produit les plus denses. Réussissez-la une fois et elle porte le reste du design.
Si vous voulez une équipe qui construit des systèmes d'icônes dans le cadre du passage de relais plus large d'un design system, engagez Brainy. Grille, gouvernance et code dans un seul projet, jamais greffés à la fin.
Lectures associées
- Guide des design systems
- Design de la hiérarchie visuelle
- Design handoff de Figma au dev
- Checklist d'accessibilité web
Want an icon library that holds up across 200 screens and four designers? Brainy ships icon systems built into the design system, with grid, governance, and code in one handoff.
Get Started
