Générateur de manifest PWA et d’icônes apple-touch
Page mise à jour le 21 août 2026
Le membre name : affiché sur l’invite d’installation et l’écran de démarrage.
Le membre short_name : le texte sous l’icône, tronqué au-delà d’une douzaine de caractères.
Le membre start_url : la page ouverte au lancement depuis l’icône.
Ce générateur assemble les trois pièces qui manquent à la plupart des sites pour devenir une application installable : le fichier manifest.json complet d’une Progressive Web App, le bloc de balises <link> et <meta> à coller dans le <head> de vos pages, et les icônes aux tailles attendues par Android comme par iOS, produites depuis votre visuel. Vous remplissez un formulaire, vous téléversez une image carrée, et vous repartez avec un pack cohérent, prêt à déposer à la racine de votre site.
Tout se passe dans votre navigateur. Le manifest est construit localement et votre icône est redimensionnée par le moteur de rendu de la page : aucun fichier, aucun texte, aucune couleur n’est envoyé sur un serveur. Vous pouvez préparer le pack d’une application interne confidentielle sans que le visuel ne quitte votre machine, recommencer autant de fois que nécessaire, et tout cela sans compte, sans quota et sans inscription.
Mode d’emploi : du formulaire au pack prêt à déployer
Le formulaire suit l’ordre logique du manifest lui-même. Remplissez-le de haut en bas :
- Renseignez le champ « Nom de l’application ». C’est le membre name du manifest : le nom complet, tel qu’il apparaîtra sur l’invite d’installation et sur l’écran de démarrage. Restez lisible : un intitulé à rallonge sera coupé sur les petits écrans.
- Renseignez le champ « Nom court (12 caractères conseillés) ». Ce texte devient short_name, celui qui s’affiche sous l’icône sur l’écran d’accueil. Une douzaine de caractères évite la troncature : « Mon Espace » passe sans encombre, « Portail des ressources humaines » finira en pointillés.
- Complétez « Description » et « URL de départ ». La description accompagne certaines invites d’installation et documente le projet ; l’URL de départ (membre start_url) est la page qui s’ouvre quand on lance l’application depuis son icône, le plus souvent la racine du site ou le tableau de bord de l’utilisateur connecté.
- Choisissez « Couleur du thème » et « Couleur de fond ». La première alimente theme_color et la balise <meta name= »theme-color »>, qui colore la barre du navigateur ; la seconde alimente background_color, la couleur affichée pendant le chargement, avant le premier rendu de vos pages.
- Réglez le sélecteur « Mode d’affichage » : standalone, fullscreen, minimal-ui ou browser. Puis le sélecteur « Orientation » : libre, portrait ou paysage. Pour obtenir un rendu d’application, standalone est le choix de référence : il masque l’interface du navigateur.
- Déposez votre visuel dans la zone « Votre icône (PNG carré, 512×512 ou plus) ». L’étape est facultative : sans image, vous obtenez le manifest et les balises seuls. Avec une image, l’outil découpe toutes les tailles d’icônes du pack à partir de votre fichier.
- Cliquez sur « Générer le manifest ». Trois sorties vous attendent : « Copier le manifest » place le JSON dans le presse-papiers, « Copier les balises » copie le bloc complet à coller dans le <head>, et « Télécharger le pack (manifest + icônes) » livre un ZIP contenant manifest.json, icon-192.png, icon-512.png, apple-touch-icon-180.png ainsi que les déclinaisons 167, 152 et 120 pixels.
Une fois le pack déposé à la racine de votre site, la déclaration tient en une ligne : <link rel= »manifest » href= »/manifest.json »> dans le <head> de chaque page. Le bloc fourni par « Copier les balises » l’inclut déjà, accompagné des balises apple-touch-icon et de la meta theme-color. Contrôlez ensuite le résultat dans les outils de développement de votre navigateur : le panneau consacré aux applications y affiche le manifest tel qu’il est réellement interprété, icônes comprises. Ce que le navigateur y montre fait foi, pas ce que vous pensez avoir mis en ligne.
PWA ou application native : ce que l’installation change vraiment
Une Progressive Web App reste un site web : mêmes pages, même hébergement, même code. Ce que le manifest y ajoute est un contrat de présentation : une icône sur l’écran d’accueil, un lancement sans barre d’adresse, une couleur d’interface, une orientation maîtrisée. Associée à un service worker qui met les ressources en cache, elle démarre vite et encaisse les coupures de réseau. Sur les usages courants (consulter un catalogue, suivre une commande, saisir des données, réserver un créneau), la différence perçue avec une application native devient très mince.
La PWA suffit donc dans bien des cas : espace client, outil métier interne, service de réservation, média, back-office mobile. Elle évite la double soumission aux boutiques, leurs délais de validation et le développement de deux applications distinctes ; notre guide des prix d’une application mobile chiffre précisément l’écart de budget entre ces approches. L’application native garde l’avantage dès que le projet dépend fortement du matériel (Bluetooth, capteurs, traitements graphiques lourds), d’une présence sur les boutiques comme canal d’acquisition, ou d’une intégration profonde au système d’exploitation. Le bon réflexe consiste à partir de l’usage réel de vos utilisateurs, pas de la technologie : si votre application se résume à des écrans, des listes et des formulaires, le manifest que vous êtes en train de générer couvre l’essentiel du besoin.
Le manifest membre par membre
Le fichier produit est un document JSON dont chaque membre pilote un aspect précis de l’installation et du lancement. Voici le rôle de chacun :
| Membre | Rôle | Point de vigilance |
|---|---|---|
| name | Nom complet, affiché à l’installation et sur l’écran de démarrage | Clair, sans slogan ni mention superflue |
| short_name | Nom affiché sous l’icône sur l’écran d’accueil | Une douzaine de caractères pour éviter la coupe |
| description | Texte de présentation repris par certaines invites d’installation | Une phrase utile qui dit ce que fait l’application |
| start_url | Page ouverte au lancement depuis l’icône | Une adresse stable, qui ne dépend pas d’une session |
| display | Quantité d’interface du navigateur conservée à l’écran | standalone pour un rendu d’application |
| background_color | Couleur affichée pendant le chargement initial | Identique au fond réel de la première page |
| theme_color | Couleur de la barre du navigateur et des surfaces système | Cohérente avec la balise meta theme-color |
| orientation | Orientation libre ou verrouillée (portrait, paysage) | Ne verrouiller que si l’usage l’exige vraiment |
| icons | Tableau des icônes avec taille, format et purpose | Au minimum 192×192 et 512×512 en PNG |
Deux membres méritent une lecture attentive. Le premier est display, car les quatre valeurs ne racontent pas la même histoire : standalone masque l’interface du navigateur et donne le rendu d’une application autonome ; fullscreen va plus loin en occupant la totalité de l’écran, un choix pertinent pour un jeu ou une borne ; minimal-ui conserve quelques commandes de navigation réduites ; browser ouvre simplement un onglet classique, ce qui revient à renoncer à l’effet application. Le second est start_url : choisissez une adresse qui accueille correctement un utilisateur qui revient, pas une page de campagne temporaire. Si cette page exige une connexion, prévoyez une redirection propre vers l’écran d’identification plutôt qu’une erreur.
Les icônes : 192, 512, maskable et le cas Safari
Côté manifest, les navigateurs attendent deux tailles précises, toutes deux en PNG : 192×192 pixels pour l’écran d’accueil et 512×512 pixels pour l’écran de démarrage et les affichages haute densité. C’est exactement ce que le pack contient. Ne fournir qu’une seule des deux tailles est l’un des oublis les plus fréquents, et il suffit à faire échouer le contrôle d’installabilité.
S’y ajoute la question du purpose maskable. Android peut recadrer l’icône dans des formes variées selon les fabricants : cercle, carré arrondi, formes plus fantaisistes. La zone de sécurité est un cercle central couvrant environ 80 % de l’image : tout ce qui compte (le motif, le monogramme, le symbole) doit tenir dans ce cercle, et les bords doivent être remplis d’une couleur pleine qui supporte d’être rognée. Un logo qui touche les angles de l’image sera amputé sur une partie du parc Android, sans message d’erreur nulle part.
Safari sur iOS fait bande à part : il n’exploite qu’en partie le manifest et s’appuie sur la balise <link rel= »apple-touch-icon »> pour l’icône posée sur l’écran d’accueil. Le format de référence est 180×180 pixels pour l’iPhone ; le pack ajoute les déclinaisons 167×167 pour l’iPad Pro, 152×152 pour l’iPad et 120×120 pour les anciens iPhone, afin de couvrir tout le parc. Préférez pour cette icône un fond plein plutôt qu’une transparence : le résultat sera identique partout et sans surprise. Si votre visuel de départ n’est pas encore prêt (marges hasardeuses, fond transparent, déclinaisons manquantes), notre générateur d’icônes d’application produit un jeu complet et propre à partir d’un seul fichier maître : c’est le compagnon naturel de cette page.
Les critères d’installabilité : ce que Chrome vérifie
Le manifest ne déclenche pas l’installation à lui seul. Chrome, avant de proposer l’ajout à l’écran d’accueil, contrôle une liste précise de conditions :
- Le site est servi en HTTPS. Aucune exception : sans certificat valide, rien ne se passe.
- Le manifest est présent et déclaré, avec les membres name ou short_name renseignés.
- Le tableau icons contient les deux tailles attendues : 192×192 et 512×512 pixels.
- start_url est défini et mène à une page qui répond.
- display vaut standalone, fullscreen ou minimal-ui. La valeur browser exclut l’installation.
- Un service worker est enregistré avec un gestionnaire fetch. C’est lui qui rend l’application capable de répondre, y compris quand le réseau fait défaut.
Soyons honnêtes sur le périmètre de l’outil : il génère le manifest, les balises et les icônes, c’est-à-dire tout ce qui se déclare. Le service worker, lui, est du code JavaScript propre à votre site : stratégie de cache, page hors connexion, mise à jour des ressources. Aucun formulaire ne peut l’écrire à votre place, et un manifest parfait n’affichera jamais d’invite d’installation si ce fichier manque. Comptez cette brique dans votre développement, au même titre que l’hébergement HTTPS. Et puisque le service worker mettra vos ressources en cache sur l’appareil de chaque utilisateur, autant qu’elles soient légères : passez vos visuels par le compresseur d’images d’application avant la mise en ligne, le cache et le premier chargement s’en porteront mieux.
Les erreurs qui empêchent une PWA de s’installer
Quand l’invite d’installation ne vient pas, la cause se trouve presque toujours dans cette courte liste :
- Le manifest n’est pas servi comme du JSON. Un serveur mal configuré renvoie parfois le fichier avec un mauvais type de contenu, ou pire, une page d’erreur HTML à sa place (redirection, protection par mot de passe, 404 habillée). Le navigateur lit alors un document invalide et abandonne sans bruit. Ouvrez l’URL du manifest directement dans un onglet : vous devez voir votre JSON, rien d’autre.
- Un chemin relatif cassé. Les adresses contenues dans le manifest se résolvent par rapport à l’emplacement du fichier lui-même. Un manifest rangé dans un sous-dossier qui référence icon-192.png sans préfixe cherchera l’icône dans ce même sous-dossier. Le plus sûr reste la racine du site et des chemins absolus, comme dans le pack généré.
- Une icône unique de 512 pixels, sans la 192. Le contrôle d’installabilité exige les deux tailles ; l’une sans l’autre ne suffit pas, même si la grande image semble couvrir tous les besoins.
- Un short_name trop long. Le nom passe la validation, mais il s’affiche coupé sous l’icône, ce qui fait négligé pour un défaut si simple à éviter.
- L’absence de service worker. L’erreur la plus fréquente et la plus mal comprise : tout le reste est en place, mais aucun gestionnaire fetch n’est enregistré, donc aucune invite n’apparaît.
- Les balises apple-touch oubliées. Le site s’installe très bien sur Android, et l’équipe découvre des semaines plus tard que l’ajout à l’écran d’accueil sur iPhone produit une icône dégradée. Les quatre balises du pack règlent le sujet une fois pour toutes.
Questions fréquentes
Le manifest suffit-il à rendre mon site installable ?
Non, et c’est la confusion la plus répandue. L’installation exige trois conditions réunies : un site servi en HTTPS, un manifest valide avec ses icônes, et un service worker enregistré avec un gestionnaire fetch. Cet outil fournit le manifest, les balises et les icônes ; le service worker reste un développement à part, propre à votre site, qui définit la stratégie de cache et le comportement hors connexion.
Où déposer le fichier manifest.json sur mon site ?
À la racine du site, c’est l’emplacement le plus sûr : les chemins d’icônes du manifest se résolvent par rapport à l’adresse du fichier, et une racine évite toute ambiguïté. Déclarez-le ensuite sur chaque page avec la balise <link rel= »manifest » href= »/manifest.json »> dans le <head> ; le bouton « Copier les balises » vous donne ce bloc prêt à coller, balises apple-touch et meta theme-color comprises.
Quelle différence entre « Nom de l’application » et « Nom court » ?
Le nom complet (membre name) apparaît sur l’invite d’installation et sur l’écran de démarrage, où la place ne manque pas. Le nom court (membre short_name) s’affiche sous l’icône sur l’écran d’accueil, un espace très restreint : une douzaine de caractères évite la troncature en pointillés. Si votre marque est longue, cherchez une forme abrégée naturelle plutôt que de laisser le système couper au hasard.
Qu’est-ce qu’une icône maskable et dois-je m’en soucier ?
Android recadre les icônes dans des formes qui varient selon les fabricants : cercle, carré arrondi, et d’autres encore. Une icône marquée purpose maskable annonce qu’elle supporte ce recadrage. La règle de composition est simple : le motif essentiel doit tenir dans un cercle central couvrant environ 80 % de l’image, et les bords doivent être une couleur pleine qui peut disparaître sans dommage. Si votre logo touche les angles, il sera rogné sur une partie des téléphones.
Pourquoi des icônes apple-touch en plus des icônes du manifest ?
Parce que Safari sur iOS n’exploite qu’en partie le manifest : pour l’icône ajoutée à l’écran d’accueil, il s’appuie sur la balise <link rel= »apple-touch-icon »>. Le pack fournit le format de référence de 180×180 pixels pour l’iPhone, plus les déclinaisons 167×167 (iPad Pro), 152×152 (iPad) et 120×120 (anciens iPhone). Sans ces balises, votre PWA s’installera proprement sur Android et présentera une icône dégradée sur iOS.
Quel « Mode d’affichage » choisir ?
standalone dans l’immense majorité des cas : il masque l’interface du navigateur et donne à votre site l’apparence d’une application autonome, tout en restant compatible avec les critères d’installation. fullscreen se justifie pour un jeu ou une borne interactive qui doit occuper chaque pixel. minimal-ui conserve quelques commandes de navigation, un compromis rarement décisif. browser, enfin, ouvre un simple onglet et exclut l’installation : ne le choisissez que si vous ne voulez pas d’effet application.
Mon icône téléversée doit-elle vraiment faire 512×512 pixels ?
Oui, au minimum, et c’est pour cela que la zone d’envoi précise « PNG carré, 512×512 ou plus ». La plus grande icône du pack fait 512 pixels de côté : partir d’un fichier plus petit obligerait à l’agrandir, ce qui produit un rendu flou sur l’écran de démarrage. Un visuel plus grand ne pose aucun problème, l’outil le réduit proprement à chaque taille. Carré obligatoire : un rectangle serait déformé ou tronqué.
Une PWA peut-elle remplacer une application native ?
Pour beaucoup de projets, oui : un espace client, un outil métier, un catalogue ou un service de réservation vivent très bien en PWA, avec un seul développement au lieu de deux et aucune validation de boutique à attendre. La native reste préférable quand le projet repose sur le matériel (Bluetooth, capteurs, 3D exigeante) ou sur la visibilité des boutiques. Le sujet est avant tout budgétaire et stratégique : notre guide des prix d’une application mobile pose les ordres de grandeur pour arbitrer sereinement.