Icônes Web en 2025 : Touch Icons, Adaptive Icons & manifest.json

Dans un web majoritairement utilisé sur mobile, les icônes affichées lorsqu’un site est ajouté à l’écran d’accueil prennent une importance majeure. Que ce soit sur iOS ou Android, une bonne gestion des icônes permet de préserver la cohérence visuelle, l'identité de marque et la qualité perçue du site. Ce guide s'adresse aux développeurs front-end, créateurs de PWA et concepteurs soucieux de l'expérience utilisateur mobile.

I. Définitions

Avec l’avènement des smartphones et des applications web, de nouveaux types d’icônes ont fait leur apparition pour s’adapter à des usages spécifiques : ajout à l’écran d’accueil, affichage plein écran, masques adaptatifs, etc. Résultat : entre Touch Icon, Adaptive Icon et manifest.json, il est facile de s’y perdre. Chacun de ces éléments a pourtant un rôle bien défini dans l’expérience mobile moderne. Avant d’aborder les formats et bonnes pratiques, commençons par clarifier ce que recouvrent ces différents termes.

1. Touch Icon (Apple)

Les Touch Icons sont les icônes utilisées lorsqu’un utilisateur ajoute un site à l’écran d’accueil depuis Safari sur iOS. Si aucune icône n'est spécifiée, iOS tente de générer une icône automatique (souvent de qualité moyenne).

2. Adaptive Icon (Android)

Les icônes adaptatives sont des icônes d’applications Android pouvant s’adapter à différents masques (ronds, carrés, en forme de goutte) selon le modèle de téléphone et le launcher utilisé. Elles sont utilisées lorsque le site est ajouté à l’écran d’accueil depuis Chrome ou un autre navigateur compatible PWA.

3. Web App Manifest

Le fichier *.webmanifest est un fichier JSON qui décrit les propriétés d'une Progressive Web App (nom, couleurs, affichage, icônes, etc.). Il est essentiel pour une PWA et contrôle quelles icônes seront utilisées sur Android.

II. Formats, dimensions et règles

1. Apple (iOS)

Sur les appareils iOS (iPhone, iPad), la Touch Icon est utilisée lorsque l’utilisateur choisit l’option "Ajouter à l’écran d’accueil" depuis Safari. Elle devient alors l’icône visuelle de votre site, affichée à côté des applications classiques, avec un comportement similaire (nom en dessous, ouverture en plein écran si configurée).

Cette icône est également utilisée dans certaines vues système, comme les suggestions Siri, la recherche Spotlight ou les aperçus de raccourcis. Elle contribue donc directement à la qualité perçue et à la cohérence visuelle de votre présence sur iOS. Une icône absente, floue ou mal formatée peut donner une impression de négligence, tandis qu'une Touch Icon nette et bien pensée donne à votre site une allure d'app native.

• Format : PNG
• Taille recommandée : 180×180 px
• Transparence : à éviter, si l’icône est transparente, iOS ajoute automatiquement un fond noir (sauf si l’image contient déjà un fond plein)
• Nombre de tailles : une seule suffit, contrairement aux pratiques anciennes où l’on spécifiait plusieurs tailles (76x76, 120x120, 152x152, etc.), iOS redimensionne désormais automatiquement une icône 180×180 px pour l’adapter à tous les appareils (iPhone, iPad, Retina…)

2. Android & Windows (Chrome, Edge, PWA)

Sur Android, l’icône d’un site est utilisée lorsqu’un utilisateur l’ajoute à l’écran d’accueil via Chrome, Edge ou un autre navigateur compatible PWA. Sur Windows, elle est utilisée lorsqu’un utilisateur installe la PWA via le navigateur (généralement Edge) : l’icône devient alors celle de l’application dans le menu Démarrer, la barre des tâches ou les résultats de recherche système.

Dans les deux cas, cette icône joue un rôle clé dans la reconnaissance de l’application par l’utilisateur, à l’image d’une app native.

Sur Android, les launchers modernes appliquent souvent un masque (circulaire, goutte, carré), ce qui rend indispensable l’utilisation d’une icône maskable bien centrée. Sur Windows, aucune transformation n’est appliquée, mais une icône bien dimensionnée reste essentielle pour garantir un affichage net.

• Format : PNG
• Tailles recommandées : 192×192 px minimum, 512×512 px pour l’icône haute résolution
• Transparence : acceptée, mais prévoir un fond ou respecter une safe zone pour éviter les rognages sur Android
• Purpose : fournir deux versions, une "any" (fallback universel) et une "maskable" (pour Android)
• Déclaration : via le fichier *.webmanifest, pris en charge par Android et Windows via Edge

3. Icônes classiques vs Icônes maskables

Android propose deux types d’icônes dans le fichier *.webmanifest : les icônes classiques (purpose: "any") et les icônes maskables (purpose: "maskable"). Ces deux variantes ont un rôle complémentaire, mais répondent à des usages légèrement différents selon la version du système et le launcher utilisé.

Icône classique (any)

• Utilisée par défaut si aucun purpose n’est précisé.
• Affichée telle quelle, sans masque appliqué.
• Peut être rognée ou déformée si le launcher impose une forme spécifique (rond, goutte, etc.).
• Compatible avec les versions d’Android plus anciennes ou certains launchers non standards.

Icône maskable (maskable)

Depuis Android Oreo (8.0), Google a introduit le concept d’icônes adaptatives via le format maskable. Cette évolution répond à la diversité des terminaux Android et des interfaces utilisateurs. Grâce à ce format, une même icône peut s’adapter aux différentes formes imposées par les launchers (ronds, carrés, goutte, etc.) tout en conservant une apparence cohérente et professionnelle.

Ce système permet à votre application web d’apparaître correctement sur l’ensemble des déclinaisons d’Android, sans subir de rognage visuel ou de rendu incohérent. Il complète les icônes classiques (any), qui restent utiles pour assurer une compatibilité universelle.

• Spécifiquement conçue pour être utilisée avec un masque de forme appliqué par le système.
• Affiche uniquement la zone de sécurité centrale (~72 % de l’image), le reste pouvant être masqué.
• Garantit un rendu propre et contrôlé sur les appareils modernes (Android 8+).
• Recommandée par Google pour toutes les PWA.

Bonnes pratiques

• Fournir les deux : any pour la compatibilité, maskable pour un rendu soigné sur Android moderne.
• Concevoir l’icône maskable avec un contenu centré et un fond plein pour éviter qu’elle paraisse rognée.
• Tester l’affichage réel sur différents launchers Android : certains imposent des masques plus agressifs que d'autres.

4. Lisibilité et niveaux de lecture selon la taille

Toutes les icônes ne sont pas égales face au redimensionnement. Une icône simple, avec une forme claire, peu de détails et un bon contraste, s’adaptera facilement à n’importe quelle taille, du petit raccourci 48×48 px jusqu’à une grande vignette 512×512 px.

Mais dès qu'une icône comporte plus de détails visuels, des éléments fins, du texte intégré ou des couches graphiques multiples, elle peut devenir difficile à lire à petite taille. Dans ce cas, il peut être judicieux de proposer plusieurs versions de l’icône selon la taille, chacune optimisée pour son usage :

• Une version simplifiée pour les petites tailles (ex. 48×48 ou 72×72 px), avec les détails secondaires supprimés ou stylisés.
• Une version complète pour les tailles plus grandes (192×192, 512×512 px), plus fidèle au design original.

Cette approche “multi-niveaux” est fréquente dans le design d’applications natives, notamment sur Android. Bien qu’elle augmente légèrement le nombre de fichiers à gérer, elle permet de garantir la lisibilité et de préserver la cohérence visuelle sur l’ensemble des supports.

Astuce : si vous appliquez cette logique, pensez à nommer vos fichiers de manière explicite (ex. icon-simple-48.png, icon-detailed-512.png) et à les déclarer correctement dans le manifest.webmanifest avec leur taille respective.

III. Appel des icônes : fichier *.webmanifest et balises <link">

Une bonne gestion des icônes passe non seulement par le choix des bons formats et dimensions, mais aussi par leur intégration correcte dans le code du site. Cette étape repose sur deux mécanismes complémentaires :

• les balises <link> dans le <head> du document HTML, utilisées principalement pour iOS (et comme fallback général),
• et le fichier *.webmanifest, qui structure les métadonnées des Progressive Web Apps, notamment sur Android et Windows.

Dans cette section, nous allons voir comment construire correctement ce fichier *.webmanifest et comment déclarer les icônes dans votre HTML pour assurer une compatibilité optimale sur tous les terminaux.

1. Structure du fichier *.webmanifest

Le fichier manifest.webmanifest est un fichier JSON placé à la racine de votre projet (ou dans un dossier accessible publiquement) et lié dans le HTML. Il permet de déclarer les propriétés essentielles d’une PWA, comme son nom, sa couleur de thème, son comportement à l’ouverture, et bien sûr, ses icônes.

Les navigateurs Android (et Windows via Edge) utilisent ce fichier pour déterminer quelle icône afficher lorsqu’un utilisateur installe ou ajoute le site à l’écran d’accueil. Une structure claire et complète est donc essentielle.

Le fichier *.webmanifest peut être nommé librement. Exemple : app.webmanifest.

{
    "name": "",
    "short_name": "",
    "description": "",
    "start_url": "/?utm_source=homescreen",
    "display": "standalone",
    "background_color": "",
    "theme_color": "",
    "icons": [
        {
            "src": "assets/icons/icon-192.png",
            "type": "image/png",
            "sizes": "192x192",
            "purpose": "any"
        },
        {
            "src": "assets/icons/icon-maskable-192.png",
            "type": "image/png",
            "sizes": "192x192",
            "purpose": "maskable"
        },
        {
            "src": "assets/icons/icon-512.png",
            "type": "image/png",
            "sizes": "512x512",
            "purpose": "any"
        },
        {
            "src": "assets/icons/icon-maskable-512.png",
            "type": "image/png",
            "sizes": "512x512",
            "purpose": "maskable"
        }
    ]
}

Clé icons (tableau d’icônes)

Définit les icônes utilisées sur les écrans d’accueil Android, Windows, et certains launchers. Ici, quatre icônes sont définies pour 192×192 et 512×512 px, en deux versions : any et maskable.

2. Insertion des balises <link> dans le <head> du HTML

Pour que les navigateurs détectent et utilisent correctement les icônes d’un site web, il est indispensable de les déclarer dans l’en-tête HTML à l’aide de balises <link>. Ces balises permettent de définir explicitement quelles icônes doivent être utilisées dans différents contextes : écran d’accueil, favoris, systèmes Apple, etc.

<!-- Touch Icon pour iOS -->
<link rel="apple-touch-icon" href="/apple-touch-icon.png">

<!-- Manifest pour Android et Windows -->
<link rel="manifest" href="/app.webmanifest">

Détails importants :

• Pour iOS, la balise apple-touch-icon est le seul moyen reconnu pour spécifier l’icône affichée sur l’écran d’accueil. Si elle est absente, Safari tentera de générer une icône par défaut (souvent peu flatteuse).
• Pour Android et Edge (Windows), le manifeste (manifest.webmanifest) est requis pour définir le comportement de la PWA (icônes, couleurs, nom, etc.).

Bonnes pratiques

• N’utilisez qu’une seule balise apple-touch-icon avec une image 180×180 px. Inutile de multiplier les tailles comme autrefois (sauf si vous proposez plusieurs niveaux de lecture).
• Vérifiez que les chemins pointent bien vers des fichiers accessibles publiquement (et pas bloqués par des règles de cache ou sécurité).
• Pensez à tester le comportement sur iOS et Android après ajout.

IV. Conclusion

Les icônes mobiles participent activement à la qualité perçue de votre site sur smartphone ou tablette. En 2025, une bonne gestion passe par des images bien dimensionnées, bien placées et adaptées aux contraintes de chaque plateforme. Avec un manifest.json bien structuré et quelques balises clés, vous assurez une expérience cohérente et professionnelle, quel que soit le support.