Packaging et distribution d'applications Electron

Livrer une application Electron à de vrais utilisateurs repose sur un pipeline en quatre étapes : packager l’application dans un installateur natif à la plateforme, la signer et la notariser pour que les systèmes d’exploitation lui fassent confiance, la distribuer via un canal accessible aux utilisateurs, et configurer la mise à jour automatique pour qu’ils restent à jour. Le choix de l’outil qui orchestrera ce pipeline est la première décision à prendre, et en 2026, elle se résume à deux options : Electron Forge ou electron-builder. Ce guide parcourt l’intégralité du chemin avec des configurations prêtes à copier-coller, les règles de signature de code qui ont évolué en 2023 et 2024, et un workflow GitHub Actions fonctionnel qui compile les trois plateformes en parallèle — car il est impossible de tout cross-compiler depuis une seule machine.

Electron Forge vs electron-builder en 2026

Choisissez Electron Forge si vous souhaitez un pipeline tout-en-un bénéficiant d’un support officiel ; choisissez electron-builder si vous voulez le système de mise à jour automatique intégré le plus mature et la plus grande communauté. Les deux produisent des installateurs signés et mis à jour automatiquement pour macOS, Windows et Linux. La différence tient au modèle de support et à la philosophie, non aux capacités.

Electron Forge est l’outil recommandé par le projet. C’est une solution tout-en-un pour packager et distribuer des applications Electron, qui combine de nombreux packages à usage unique en un pipeline de build complet et fonctionnel dès l’installation, incluant la signature de code, les installateurs et la publication des artefacts. Forge a absorbé les anciens utilitaires @electron/packager et @electron/osx-sign dans son système de Makers et Publishers. Point essentiel : si vous ne souhaitez pas utiliser Electron Forge, les autres outils tiers sont maintenus par des membres de la communauté Electron et ne bénéficient pas du support officiel du projet Electron.

electron-builder est cette alternative communautaire — et la plus téléchargée, avec 2 à 3 millions d’installations hebdomadaires selon la source consultée. En juin 2026, la version stable actuelle est la 26.15.3, et de nouvelles versions sont publiées plusieurs fois par mois ; épinglez donc la version et vérifiez-la avant chaque cycle de release. La prochaine version majeure, v27, est en alpha en juin 2026 (la branche 27.0.0-alpha) : elle fait migrer electron-builder vers les modules ES natifs, élève la version minimale requise à Node.js 22.12, et supprime les API dépréciées depuis longtemps — prévoyez donc une vérification de votre configuration Node et de vos fichiers de config avant de l’adopter. Le canal stable reste néanmoins en 26.x pour l’instant. La raison pour laquelle de nombreuses équipes se tournent vers cet outil est son système de mise à jour intégré : electron-builder est une solution complète qui ajoute une seule dépendance, gère les prérequis en interne, et remplace certaines fonctionnalités utilisées par les mainteneurs d’Electron — comme le système de mise à jour automatique — par des implémentations personnalisées.

Cet article utilise electron-builder pour ses exemples de configuration, car son bloc déclaratif dans package.json s’adapte proprement à chaque cible de plateforme, et son compagnon electron-updater est la référence de facto pour les mises à jour auto-hébergées. Les concepts sont transposables à Forge si vous préférez la voie officielle.

Qu’en est-il de Tauri ?

Tauri 2.x est l’alternative crédible et plus légère à Electron lorsqu’un bundle d’environ 100 Mo est rédhibitoire. Il affiche votre interface via la WebView native du système d’exploitation plutôt que d’embarquer un runtime Chromium complet, ce qui produit des binaires nettement plus petits (d’un ordre de grandeur, pas exactement). La contrepartie est réelle : vous renoncez à la cohérence de rendu d’Electron entre les machines et à son vaste écosystème npm et de modules natifs, et vous acceptez la fragmentation des versions de WebView selon les OS des utilisateurs. Tauri est le bon choix pour un utilitaire léger et sensible à la sécurité ; Electron reste en tête lorsque la fidélité de l’interface et la profondeur de l’écosystème priment sur l’empreinte disque.

Packaging par plateforme avec electron-builder

electron-builder génère des installateurs natifs à partir d’un seul bloc build dans package.json. Définissez une configuration de niveau supérieur ainsi que des clés mac, win et linux nommant les cibles souhaitées. Une configuration multi-plateforme minimale ressemble à ceci :

{
  "build": {
    "appId": "com.example.myapp",
    "productName": "MyApp",
    "directories": { "output": "dist" },
    "files": ["dist-app/**/*", "package.json"],
    "mac": {
      "category": "public.app-category.productivity",
      "target": ["dmg", "zip"],
      "hardenedRuntime": true,
      "notarize": true
    },
    "win": {
      "target": ["nsis"]
    },
    "linux": {
      "target": ["AppImage", "deb", "rpm"],
      "category": "Utility"
    },
    "publish": [{ "provider": "github" }]
  }
}

Chaque cible correspond à un format d’installateur concret :

Deux détails concernant les cibles electron-builder piègent souvent les développeurs. La cible zip sur macOS n’est pas optionnelle si vous utilisez les mises à jour automatiques : la cible zip pour macOS est requise par Squirrel.Mac ; sans elle, le fichier latest-mac.yml ne peut pas être créé, ce qui provoque une erreur de l’autoUpdater — et comme la cible macOS par défaut est dmg+zip, il n’est généralement pas nécessaire de la spécifier explicitement. Pour les mises à jour automatiques spécifiquement, l’application macOS doit être signée, et les cibles par défaut supportées sont DMG (macOS), AppImage/DEB/Pacman/RPM (Linux) et NSIS (Windows). Lancez un build avec npx electron-builder --mac --win --linux, mais notez que vous ne pouvez compiler des installateurs signés pour une plateforme donnée que sur (ou pour) cette plateforme — d’où l’importance de la CI abordée plus loin.

Concernant la sécurité de base : cet article suppose que votre application fonctionne déjà avec la posture de sécurité recommandée par Electron — un script preload avec contextIsolation activé et nodeIntegration désactivé. Ne livrez jamais l’inverse ; le packaging ne corrige pas un renderer non sécurisé.

Signature de code et notarisation : la chaîne de dépendances

Voici la règle qui fait échouer plus de releases macOS que toute autre : une application macOS non signée peut notifier l’utilisateur qu’une mise à jour est disponible, mais ne peut pas l’installer silencieusement. La signature de code est un prérequis à la notarisation, et la notarisation est un prérequis au bon fonctionnement des mises à jour automatiques sur macOS. Votre application doit être signée pour que les mises à jour automatiques fonctionnent sur macOS — c’est une exigence de Squirrel.Mac. Ignorez la signature et toute la chaîne en aval s’effondre.

macOS : signer, puis notariser

Vous avez besoin d’un certificat Apple Developer ID, qui nécessite une adhésion. L’Apple Developer Program coûte 99 USD par an d’adhésion, avec les prix affichés en devise locale lors de l’inscription — et non « 99 EUR » — et la notarisation est incluse : une fois membre de l’Apple Developer Program, vous pouvez notariser des applications Mac sans frais supplémentaires. La notarisation (l’analyse automatisée de malwares d’Apple) est obligatoire pour les applications signées avec un Developer ID distribuées en dehors du Mac App Store depuis macOS 10.15 Catalina.

Dans electron-builder, définissez hardenedRuntime: true et notarize: true dans le bloc mac (comme indiqué ci-dessus), puis fournissez les identifiants via des variables d’environnement au moment du build — jamais dans le dépôt :

# Certificat de signature macOS (fichier .p12 encodé en base64) et son mot de passe
export CSC_LINK="$(base64 -i developer-id.p12)"
export CSC_KEY_PASSWORD="••••••"
# Identifiants de notarisation (API App Store Connect ou mot de passe spécifique à l'app Apple ID)
export APPLE_ID="you@example.com"
export APPLE_APP_SPECIFIC_PASSWORD="abcd-efgh-ijkl-mnop"
export APPLE_TEAM_ID="XXXXXXXXXX"

Windows : la remise à zéro de SmartScreen en 2024

Commencez votre réflexion sur Windows par le changement que presque tous les guides plus anciens ignorent. Les certificats EV ne contournent plus SmartScreen : autrefois, signer avec un certificat Extended Validation conférait automatiquement une réputation positive auprès de SmartScreen, mais ce comportement n’existe plus, et payer un supplément pour un certificat EV uniquement pour éviter les avertissements SmartScreen n’est plus justifié. Un installateur signé avec un certificat EV construit désormais sa réputation de téléchargement exactement comme un certificat Organization Validated (OV) moins coûteux.

L’autre évolution concerne l’emplacement de stockage des clés. Depuis le 1er juin 2023, les clés privées de signature de code doivent être stockées sur du matériel certifié — c’est précisément pourquoi un certificat OV sur clé USB ne fonctionne pas en CI sans intervention humaine. La documentation de signature Windows de Tauri marque la même frontière : leur guide standard s’applique uniquement aux certificats OV acquis avant le 1er juin 2023, et pour les certificats obtenus après cette date, ils renvoient vers le processus de token matériel de l’émetteur.

La solution par défaut la plus propre en 2026 contourne entièrement le token. Azure Artifact Signing — anciennement Trusted Signing — est un service de signature de code entièrement géré, de bout en bout, intégré à Azure. Il signe depuis le cloud sans token USB, s’exécute nativement dans les pipelines CI/CD, et stocke les clés dans des HSM gérés par Microsoft. Voici l’ordre de décision recommandé :

1. Azure Artifact Signing en premier. Il est natif pour la CI et peu coûteux (Microsoft documente des plans à la consommation de l’ordre de ~10 $/mois pour les petits projets). La disponibilité est limitée aux organisations situées aux États-Unis, au Canada, dans l’UE et au Royaume-Uni, tandis que les développeurs individuels sont actuellement limités aux États-Unis et au Canada.
2. Certificat OV de DigiCert, Sectigo ou GlobalSign si vous êtes en dehors de ces régions. Les certificats OV sont fonctionnellement équivalents à Azure Artifact Signing pour SmartScreen.
3. Conservez un certificat EV existant jusqu’à son expiration — mais si vous en possédez déjà un, il reste valide et fonctionnel pour la signature ; ne payez simplement pas le supplément EV uniquement pour éviter SmartScreen. N’en achetez pas un nouveau dans ce seul but.

Signé vs non signé

Les builds non signés sont acceptables pour un public de développeurs à l’aise avec les étapes de contournement. Pour les utilisateurs non techniques — et pour toute application qui se met à jour automatiquement sur macOS — la signature est non négociable.

Mises à jour automatiques avec electron-updater

electron-updater (le compagnon d’electron-builder) vous offre des mises à jour auto-hébergées multiplateformes avec un minimum de code. Il prend en charge GitHub Releases, Amazon S3, DigitalOcean Spaces, Keygen et un serveur HTTP(S) générique dès l’installation, et ne nécessite que deux lignes de code pour fonctionner. Le cas d’usage courant :

const { autoUpdater } = require("electron-updater");

app.whenReady().then(() => {
  createWindow();
  autoUpdater.checkForUpdatesAndNotify();
});

Appelez autoUpdater.checkForUpdatesAndNotify() — et n’appelez pas setFeedURL, car electron-builder crée automatiquement un fichier app-update.yml interne lors du build. L’hébergement des releases est défini par le bloc publish dans votre configuration de build ; en le pointant vers { "provider": "github" }, un tag poussé déclenche la CI, téléverse les artefacts vers une GitHub Release, et le système de mise à jour les trouve automatiquement. Sur macOS, cette ligne unique ne sert à rien si le build n’est pas signé et notarisé — la même chaîne que dans la section précédente. Linux ne dispose pas de mécanisme universel de mise à jour automatique ; les mises à jour AppImage fonctionnent via electron-updater, mais les utilisateurs de deb/rpm mettent à jour via leur gestionnaire de paquets.

Canaux de distribution

Choisissez vos canaux en fonction de l’audience visée et du niveau de contrôle et de revenus que vous souhaitez conserver :

• Votre propre site web. Contrôle total, signé ou non, sans commission, et s’intègre directement avec electron-updater via GitHub Releases ou S3.
• GitHub Releases. Hébergement gratuit, historique des versions, et la voie de moindre résistance pour l’intégration des mises à jour automatiques.
• Mac App Store. Apporte de la visibilité mais exige le sandboxing et une revue, et prélève la commission standard d’Apple de 30% — réduite à 15% dans le cadre du programme App Store Small Business pour les développeurs dont les revenus annuels sont inférieurs à 1 million USD.
• Microsoft Store. Vaut la peine pour l’avantage SmartScreen à lui seul : publier un package MSIX via le Microsoft Store signifie que Microsoft re-signe automatiquement votre package, de sorte que les utilisateurs ne voient jamais d’avertissement SmartScreen et que vous n’avez jamais besoin d’acheter ou de renouveler un certificat.
• Homebrew Cask. Distribution gratuite et conviviale pour les développeurs sur macOS via une pull request vers le dépôt des casks — idéal pour toucher les utilisateurs techniques avec brew install.

Une remarque pratique à garder à l’esprit : comme un renderer Electron est une fenêtre Chromium, l’instrumentation de session replay navigateur fonctionne sans modification dans un build desktop packagé, ce qui constitue l’un des rares moyens pratiques d’observer des régressions d’interface qui n’apparaissent qu’après le packaging ou une mise à jour automatique sur la machine d’un utilisateur — chemins de menus natifs et de la barre système, flux de dialogues de fichiers, différences de CSP liées aux builds signés — et jamais lors du développement avec electron ..

Compilation des trois plateformes en CI avec GitHub Actions

Il est impossible de tout cross-compiler localement : la notarisation DMG nécessite macOS, et les installateurs Windows signés nécessitent les outils Windows. La solution réaliste en 2026 est une matrice GitHub Actions exécutant macos-latest, windows-latest et ubuntu-latest en parallèle, avec les secrets de signature injectés sous forme de variables d’environnement chiffrées. Un fichier release.yml complet qui compile et publie lors d’un tag :

name: Release
on:
  push:
    tags: ["v*"]

jobs:
  release:
    runs-on: ${{ matrix.os }}
    strategy:
      matrix:
        os: [macos-latest, windows-latest, ubuntu-latest]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npm ci
      - name: Build, sign, and publish
        run: npx electron-builder --publish always
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          # Signature + notarisation macOS (lues uniquement sur macos-latest)
          CSC_LINK: ${{ secrets.MAC_CSC_LINK }}
          CSC_KEY_PASSWORD: ${{ secrets.MAC_CSC_KEY_PASSWORD }}
          APPLE_ID: ${{ secrets.APPLE_ID }}
          APPLE_APP_SPECIFIC_PASSWORD: ${{ secrets.APPLE_APP_PASSWORD }}
          APPLE_TEAM_ID: ${{ secrets.APPLE_TEAM_ID }}
          # Windows : identifiants Azure Artifact Signing (lus uniquement sur windows-latest)
          AZURE_TENANT_ID: ${{ secrets.AZURE_TENANT_ID }}
          AZURE_CLIENT_ID: ${{ secrets.AZURE_CLIENT_ID }}
          AZURE_CLIENT_SECRET: ${{ secrets.AZURE_CLIENT_SECRET }}

Chaque runner compile uniquement les cibles de sa propre plateforme, electron-builder signe en utilisant les identifiants présents dans l’environnement de ce runner, et --publish always téléverse chaque artefact ainsi que les métadonnées de mise à jour latest*.yml vers une seule GitHub Release. Stockez chaque secret dans les secrets du dépôt ou de l’environnement — jamais dans le fichier de workflow. Comme Azure Artifact Signing fonctionne avec GitHub Actions et Azure DevOps via de simples variables d’environnement, le job Windows ne nécessite ni token USB ni runner auto-hébergé.

Livrer une application Electron tient moins d’une commande magique que du respect d’une chaîne : signer pour pouvoir notariser, notariser pour que les mises à jour automatiques macOS fonctionnent, et exécuter l’ensemble dans une matrice CI car aucune machine ne peut compiler les trois plateformes à elle seule. Configurez le bloc build, ajoutez electron-updater, committez un release.yml, et votre prochain git tag v1.0.0 && git push --tags produira des installateurs signés et mis à jour automatiquement pour chaque plateforme en une seule opération.

FAQ

Puis-je compiler des installateurs signés pour macOS, Windows et Linux sur une seule machine ?

Non. La notarisation DMG nécessite les outils macOS, et les installateurs Windows signés nécessitent les outils Windows ; aucune machine ne peut donc produire des builds signés pour les trois plateformes. Vous pouvez compiler pour la plateforme sur laquelle vous travaillez, et electron-builder supporte un certain cross-targeting, mais la signature et la notarisation sont liées à la plateforme. La solution réaliste en 2026 est une matrice GitHub Actions exécutant macos-latest, windows-latest et ubuntu-latest en parallèle, où chaque runner compile et signe uniquement les cibles de sa propre plateforme.

Le Microsoft Store supprime-t-il les avertissements SmartScreen sans certificat de signature de code ?

Oui. Publier un package MSIX via le Microsoft Store signifie que Microsoft re-signe automatiquement votre package, de sorte que les utilisateurs ne voient jamais d'avertissement SmartScreen et que vous n'avez jamais besoin d'acheter ou de renouveler un certificat. Le Microsoft Store constitue ainsi un moyen efficace de s'affranchir à la fois des coûts de certificat et de la construction de réputation. La contrepartie est la soumission au store, la revue, et le packaging de votre application en MSIX plutôt que la distribution directe d'un installateur NSIS ou MSI depuis votre propre site.

Pourquoi mon application macOS notifie-t-elle les utilisateurs des mises à jour mais ne les installe-t-elle jamais automatiquement ?

Le build n'est presque certainement pas signé. Sur macOS, une application doit être signée pour que les mises à jour automatiques fonctionnent, car Squirrel.Mac l'exige. Une application non signée peut détecter et notifier l'utilisateur qu'une nouvelle version est disponible, mais elle ne peut pas remplacer silencieusement le binaire. La solution est la chaîne complète : obtenir un certificat Apple Developer ID, signer l'application, puis la notariser. La signature de code est un prérequis à la notarisation, et la notarisation est un prérequis au bon fonctionnement des mises à jour silencieuses sur macOS.

Vaut-il encore la peine de payer pour un certificat EV afin d'éviter les avertissements SmartScreen sur Windows ?

Non. Les certificats EV contournaient auparavant SmartScreen dès le premier téléchargement, mais Microsoft a supprimé ce comportement de réputation instantanée en 2024. Un installateur signé avec un certificat EV construit désormais sa réputation de téléchargement exactement comme un certificat Organization Validated moins coûteux ; payer le supplément EV uniquement pour éviter SmartScreen n'est donc plus justifié. Pour la plupart des équipes en 2026, la solution par défaut la plus propre est Azure Artifact Signing, qui signe depuis le cloud sans token USB, ou un certificat OV si vous êtes en dehors des régions éligibles.