Le packaging macOS d’Electron 44 nécessite-t-il un Mac ? Plan CI 2026

Le mot « build » recouvre plusieurs opérations qui ne présentent pas les mêmes contraintes. La vue d’ensemble officielle de la distribution Electron distingue notamment la création de l’application, son empaquetage, la signature et la distribution.

Pour une équipe multiplateforme, il faut séparer au minimum les étapes suivantes :

1. Préparer le code source : installation des dépendances, lint, tests unitaires et contrôles de licence.
2. Générer un paquet macOS : création de l’application .app, d’une archive ou d’un installateur.
3. Signer le code : application de l’identité de signature et des entitlements adaptés.
4. Soumettre à la notarisation : envoi du logiciel au service Apple et attente d’un résultat.
5. Agrafer puis vérifier le ticket : association du ticket de notarisation à l’artefact et contrôle local.
6. Tester l’installation : ouverture avec un compte utilisateur propre, vérification de Gatekeeper et test du mécanisme de mise à jour.

Un fichier généré depuis Windows ou Linux peut donc être utile pour un test interne, mais il ne prouve pas que la version sera distribuable. La question pertinente n’est pas seulement « le paquet existe-t-il ? ». Il faut demander s’il possède une signature vérifiable, s’il a obtenu un résultat de notarisation exploitable et s’il s’installe correctement sur une machine macOS qui ne contient pas les outils de développement.

Le risque est particulièrement visible pour une application destinée à l’audio, à la vidéo ou au design. Une interface Electron peut fonctionner pendant les tests, puis échouer lorsque l’application accède à un périphérique, à une extension, à un module natif ou à un composant auxiliaire qui n’a pas été correctement signé.

Un projet composé uniquement de JavaScript offre davantage de latitude pour une préparation hors macOS. Cette possibilité ne doit pourtant pas être généralisée à tous les projets Electron.

Les points de blocage les plus courants sont les suivants :

• module Node natif compilé pour une architecture différente ;
• binaire auxiliaire fourni uniquement pour darwin-x64 ou uniquement pour darwin-arm64 ;
• extension, helper ou ressource qui n’est pas incluse dans le paquet final ;
• dépendance installée sur un nœud, puis réutilisée sur un autre sans reconstruction ;
• différence entre une application Apple Silicon et une application Intel ;
• script de post-installation qui détecte l’OS ou l’architecture au moment de l’installation.

La documentation d’Electron sur les plateformes et architectures d’installation doit être rapprochée de la matrice réelle des dépendances du projet. Une ligne indiquant que l’application « supporte macOS » ne suffit pas à établir que chaque module natif possède bien une variante compatible.

Nous recommandons de consigner, pour chaque dépendance sensible, l’architecture fournie et l’étape qui la construit. Le nœud Mac ne doit pas simplement recevoir le répertoire node_modules produit ailleurs. Il doit pouvoir refaire une installation propre, reconstruire les modules requis et confirmer leur chargement dans l’application finale.

Cette vérification est importante pour les applications de montage, de capture, de traitement sonore ou de création visuelle. Un module peut se charger pendant un test superficiel, puis devenir indisponible lorsque l’utilisateur ouvre une fonction qui appelle réellement le binaire natif.

Preuve minimale à demander au pipeline

À chaque exécution de publication, conservez :

• l’identifiant exact du commit ;
• le fichier de verrouillage des dépendances ;
• l’empreinte de l’archive transmise au nœud Mac ;
• la liste des architectures ciblées ;
• le résultat du chargement des modules natifs ;
• les journaux de reconstruction et de packaging.

Le nœud Mac doit partir d’un espace de travail propre ou d’un état explicitement contrôlé. Si le pipeline réutilise des fichiers provenant d’un ancien build, un résultat positif peut masquer une dépendance absente du dépôt ou une version locale non reproductible.

La signature est le point où la chaîne revient nécessairement vers macOS. Electron recommande la signature des applications destinées à être distribuées, et sa documentation officielle sur le code signing décrit les éléments qui doivent être préparés pour cette étape.

Dans une chaîne Electron, il faut distinguer :

• le certificat Developer ID approprié au type de distribution ;
• la clé privée correspondante ;
• les entitlements demandés par l’application ;
• le Hardened Runtime lorsque le scénario de distribution l’exige ;
• le trousseau accessible par le compte qui exécute la CI ;
• les composants auxiliaires qui doivent être signés avec une cohérence suffisante.

Le guide Electron Forge consacré à la signature macOS et la configuration de @electron/osx-sign sont les références à consulter avant de transformer une commande locale en étape automatisée.

La difficulté ne vient pas uniquement de la commande de signature. Elle vient de l’identité d’exécution. Une clé privée importée dans le trousseau personnel d’un développeur ne constitue pas une configuration de publication reproductible. À l’inverse, déposer un certificat dans un compte partagé expose la chaîne de sortie à d’autres tâches et rend les audits difficiles.

Nous conseillons un compte de publication distinct, un trousseau dédié, des permissions minimales et une durée d’accès limitée aux secrets. Les noms de compte, de certificat, de trousseau, de dépôt et d’hôte doivent rester des variables de CI ou des valeurs masquées. Aucun identifiant réel ne doit apparaître dans les journaux.

Point de vigilance : le déverrouillage temporaire du trousseau doit être associé à la seule tâche de publication. Une session graphique permanente ou un trousseau ouvert pour tous les travaux du nœud transforme une machine de build en coffre-fort partagé.

La signature doit aussi être vérifiée dans le paquet final. Il ne suffit pas de constater que la commande de packaging s’est terminée sans erreur. Inspectez l’identité appliquée, les composants inclus et les entitlements réellement présents. Une correction locale non reportée dans le pipeline crée rapidement deux versions différentes de la même application.

La notarisation intervient après la signature. Apple décrit ce flux dans sa documentation sur la notarisation des logiciels macOS avant distribution et dans son guide consacré à la personnalisation du processus de notarisation.

La séquence CI doit traiter séparément les événements suivants :

1. création de l’archive signée ;
2. envoi au service de notarisation ;
3. réception d’un identifiant de soumission ;
4. attente et lecture du résultat ;
5. conservation du journal en cas de rejet ;
6. agrafage du ticket lorsque le résultat est accepté ;
7. validation locale de l’archive agrafée ;
8. installation sur un compte utilisateur propre.

Apple documente également l’intégration avec notarytool et la Notary API. Le choix de l’interface ne change pas l’obligation de conserver l’identifiant de soumission et la réponse complète du service.

Un téléversement réussi ne signifie pas que la notarisation est acceptée. Une notarisation acceptée ne signifie pas non plus que l’archive finale contient bien le ticket ni qu’elle s’ouvre correctement hors ligne. Ces états doivent donc produire des artefacts et des journaux distincts.

Les paramètres d’authentification, l’identifiant d’équipe, la clé, le Bundle ID et l’identifiant de soumission doivent rester des valeurs fictives dans les exemples de configuration, par exemple <TEAM_ID>, <BUNDLE_ID>, <API_KEY_PATH> et <SUBMISSION_ID>. Le pipeline réel les injecte depuis son gestionnaire de secrets.

Pour une application audio ou vidéo, ajoutez un test fonctionnel ciblé après l’installation : accès à un fichier média, chargement d’un module natif, ouverture d’un périphérique autorisé ou lancement d’un helper. Le but est de vérifier le logiciel tel qu’un utilisateur le reçoit, et non le dossier de travail du runner.

La documentation du cycle de build d’Electron Forge aide à découper la chaîne, mais elle ne décide pas à elle seule de l’emplacement de chaque tâche. Le découpage suivant limite l’occupation du nœud Mac :

• Windows ou Linux : lint, tests unitaires, analyse statique, tests de logique métier et préparation de l’archive source ;
• nœud Mac : installation propre, reconstruction des modules natifs, packaging macOS, signature, notarisation, agrafage et test d’installation ;
• étape de publication : conservation des journaux, dépôt de l’artefact, génération des métadonnées de version et validation du canal de mise à jour.

Le transfert doit porter sur une référence traçable. Transmettez soit un commit précis que le nœud Mac peut récupérer, soit une archive dont l’empreinte est vérifiée. Évitez de laisser le runner Mac refaire un pull depuis une branche mobile entre deux étapes : le code testé et le code publié pourraient alors diverger.

Une location courte auprès de MESHLAUNCH peut servir à valider la chaîne avant de décider d’acheter une machine. Pour une équipe qui compare plusieurs profils matériels, la page dédiée au Mac mini pour les charges de commande et de CI constitue un point de départ, sans remplacer l’essai avec le projet réel et ses dépendances.

Ne validez pas un nœud uniquement parce que le travail CI termine avec le statut « réussi ». Utilisez cette liste après chaque changement important du projet :

• [ ] Le dépôt est cloné dans un espace de travail propre.
• [ ] Le commit et l’empreinte de l’archive sont enregistrés.
• [ ] Les dépendances sont installées depuis le fichier de verrouillage.
• [ ] Chaque module natif est reconstruit pour l’architecture cible.
• [ ] L’application Electron démarre avec les modules réellement utilisés.
• [ ] Le paquet macOS est généré par la même définition de pipeline que la production.
• [ ] La signature est vérifiée sur l’application et ses composants auxiliaires.
• [ ] Les entitlements attendus sont présents et documentés.
• [ ] La soumission à la notarisation possède un identifiant conservé dans les artefacts.
• [ ] Le journal de notarisation est archivé, y compris en cas d’échec.
• [ ] Le ticket est agrafé puis vérifié localement.
• [ ] L’installation est testée avec un compte utilisateur propre.
• [ ] L’ouverture après redémarrage est contrôlée.
• [ ] Le mécanisme de mise à jour est testé avec la version précédente.
• [ ] Le trousseau fonctionne après redémarrage sans ouvrir les secrets à toutes les tâches.
• [ ] Un artefact publiable précédent est conservé pour le retour arrière.

Cette liste couvre également les coûts cachés d’un nœud permanent : maintenance du compte, restauration du trousseau, réinstallation des outils, contrôle des tâches résiduelles et reprise après redémarrage. Un environnement distant n’est pas seulement une adresse SSH ; c’est une dépendance de publication qui doit avoir une procédure de remplacement.

Pour les équipes qui souhaitent comparer une machine locale à une infrastructure distante, un Mac mini dédié aux workflows de commande peut être évalué selon cette même grille. La décision doit partir de la fréquence des publications, du niveau d’isolement des secrets et du besoin d’accès physique, pas d’un simple succès de compilation.

Limites du packaging depuis Windows

Une application Electron peut être empaquetée depuis Windows dans certains projets, surtout lorsque les dépendances sont purement JavaScript. Pour une version publique, le nœud Mac reste recommandé pour reconstruire les modules natifs, signer le paquet, traiter les entitlements, lancer la notarisation et vérifier l’installation réelle. Le fichier généré n’est donc pas la preuve finale de conformité.

Dépendance à la signature macOS

Le besoin d’un Mac vient de la chaîne d’identité et du trousseau, pas d’une exigence liée à l’éditeur de code. Le compte de CI doit accéder à la clé privée et aux outils macOS sans exposer ces éléments aux tâches ordinaires. Une machine distante est acceptable si son compte de publication, son trousseau et ses journaux sont isolés.

Electron Forge dans une CI

Electron Forge peut orchestrer la construction et la signature, mais la CI doit encore gérer les secrets, l’attente du résultat de notarisation, l’archivage du journal et la vérification du ticket. La configuration ne doit pas contenir directement une clé ou un mot de passe. Les variables protégées sont injectées uniquement sur le nœud Mac et uniquement durant la publication.

Publication depuis un environnement Windows

Le poste Windows peut rester le centre du développement quotidien. Il exécute les tests indépendants de macOS, prépare une référence de code immuable et déclenche ensuite le nœud Mac. Cette méthode est préférable à une copie manuelle du dossier de sortie, car elle permet de relier le paquet publié au commit, au verrouillage des dépendances et aux contrôles déjà exécutés.

Durée de fonctionnement du nœud

Un nœud doit rester allumé en permanence seulement si la fréquence, la latence de déclenchement ou la continuité de service le justifie. Pour une version occasionnelle, un nœud distant loué à court terme suffit si l’environnement est vérifié depuis un état propre. Pour une publication récurrente, un nœud dédié simplifie la restauration du trousseau et la surveillance, mais impose une vraie procédure d’exploitation.

Si votre solution actuelle repose uniquement sur Windows ou Linux, elle conserve un avantage pour les tests génériques et le développement quotidien. Elle laisse toutefois trois lacunes concrètes : absence de vérification native de la signature, dépendance à un poste personnel pour les clés privées et risque de découvrir trop tard un problème de notarisation ou d’installation. Une machine virtuelle ou un poste partagé peut ajouter des écarts d’architecture, des états persistants difficiles à auditer et une reprise incertaine après redémarrage.

Pour une première publication Electron 44, nous recommandons donc de louer un Mac distant auprès de MESHLAUNCH pendant une période courte, de repartir d’un espace propre et de valider toute la chaîne : installation des dépendances, packaging, signature, notarisation, agrafage, installation et mise à jour. Cette approche permet de mesurer le travail réel avant d’immobiliser un budget dans un nœud permanent. Si les publications deviennent fréquentes et critiques, conservez ensuite un nœud dédié ainsi qu’un chemin de secours documenté.