Ce que signifie distribuer directement avec Developer ID

Il existe globalement deux façons de mettre une application macOS entre les mains des utilisateurs. La première passe par le Mac App Store (MAS) ; la seconde est la distribution directe — vous laissez les utilisateurs télécharger un fichier .dmg (ou .app) que vous avez vous-même construit depuis un site web, GitHub ou un emplacement similaire.

La distribution directe présente des avantages évidents. Vous n’avez pas à attendre la validation de l’App Store, il n’y a pas de commission sur les paiements, et vous pouvez publier des mises à jour quand et comme vous le souhaitez. En contrepartie, les tâches dont l’App Store s’occupait à votre place — signature du code, notarisation et mises à jour automatiques — sont désormais à votre charge.

Si vous ne les mettez pas en place, le mécanisme de sécurité de macOS, Gatekeeper, bloquera le lancement de l’application. Lorsqu’un utilisateur ouvre l’application pour la première fois, il voit un avertissement du type « Cette application ne peut pas être ouverte, car elle provient d’un développeur non identifié », et la plupart abandonnent l’installation à ce stade. Pour que l’application s’ouvre avec un simple double-clic comme n’importe quelle application correctement distribuée, vous devez signer l’application avec un certificat Developer ID et la faire notariser par Apple.

Cette série couvre ce processus de configuration initiale. Bonne nouvelle : la plupart des réglages abordés ici ne sont effectués qu’une seule fois et réutilisés pour chaque version publiée.

Ce que vous construirez dans cette série

En trois parties, vous mettrez en place les éléments suivants.

• (Partie 1, cet article) Un certificat Developer ID Application + des identifiants pour la notarisation
• (Partie 2) Une clé de signature EdDSA pour les mises à jour automatiques Sparkle
• (Partie 3) Un dépôt public pour héberger le flux de mises à jour + finalisation des paramètres de build

À la fin de la série, vous devriez avoir en main les éléments suivants. Pour l’instant, parcourez simplement la liste ; chaque partie remplira un élément à la fois.

• Un certificat Developer ID Application dans le trousseau macOS (Keychain)
• Un profil d’identifiants de notarisation stocké dans le trousseau
• Une paire de clés EdDSA pour signer les mises à jour Sparkle (clé publique + clé privée)
• Une sauvegarde de la clé privée dans un endroit sûr
• Un dépôt GitHub public + GitHub Pages pour héberger le flux de mises à jour (appcast)
• Le fichier de paramètres de build (ExportOptions.plist) et la configuration côté application

L’application exemple — FocusTimer

Cette série utilise une application macOS fictive, FocusTimer (une simple application de minuterie pour gérer les sessions de concentration), comme fil conducteur. Le nom FocusTimer, l’identifiant de bundle com.example.FocusTimer, le domaine example.com, le nom du certificat, le Team ID, et ainsi de suite, qui apparaissent dans les commandes et les chemins, sont tous des valeurs d’exemple. Lorsque vous suivrez réellement ces instructions, remplacez-les par le nom de votre propre application et les informations de votre compte.

Cet article est rédigé pour Xcode 26 et Sparkle 2.x (le framework de mise à jour automatique, qui apparaît en Partie 2). Apple modifie souvent la disposition de ses écrans et l’emplacement des menus, donc même si un nom de bouton est légèrement différent, supposez que le flux global est identique.

Prérequis — Outils en ligne de commande

Commencez par installer deux outils en ligne de commande nécessaires à l’automatisation du build et de la publication. Cela suppose que vous avez déjà installé le gestionnaire de paquets macOS Homebrew.

brew install gh create-dmg

• gh — L’interface en ligne de commande officielle de GitHub. Vous l’utiliserez plus tard pour créer des GitHub Releases.
• create-dmg — Un outil pour construire une image disque .dmg destinée à la distribution. Il génère également l’écran qui guide les utilisateurs pour faire glisser l’application dans le dossier Applications.

Vous n’en aurez pas besoin tout de suite, mais les scripts d’automatisation de publication sont souvent conçus pour vérifier la présence de ces outils en premier et s’arrêter immédiatement s’ils sont absents, il vaut donc mieux les installer à l’avance.

Étape 1 — Vérifier votre adhésion au Apple Developer Program

Pour émettre un certificat Developer ID et notariser une application, vous avez besoin d’une adhésion au Apple Developer Program. Pour un compte individuel, il s’agit d’un programme payant coûtant 99 $ par an.

Si vous êtes déjà inscrit, il vous suffit de confirmer que votre adhésion est active.

1. Rendez-vous sur developer.apple.com/account
2. Dans la section Membership details, confirmez que le statut est Active
3. Sur le même écran, notez votre Team ID (dans les exemples, ABCDE12345). Il est utilisé tout au long des étapes suivantes.

Si vous n’êtes pas encore inscrit, l’approbation de l’adhésion prend généralement environ un jour. Les certificats ne peuvent pas être émis avant l’approbation, il est donc préférable de s’en occuper en premier.

Étape 2 — Émettre un certificat Developer ID Application

Le certificat Developer ID Application est le certificat utilisé pour signer le .app et le .dmg que vous distribuez. macOS Gatekeeper reconnaît une application signée avec ce certificat comme « une application fabriquée par un développeur connu ».

Apple dispose également d’un certificat Developer ID Installer distinct pour signer les paquets d’installation .pkg. Cette série distribuant via .dmg, nous ne traitons que du certificat Application.

Procédure d’émission

La méthode la plus simple passe par Xcode.

1. Lancer Xcode → menu Xcode → Settings… (⌘,)
2. Sélectionner l’onglet Accounts → cliquer sur votre Apple ID dans la liste de gauche
3. Cliquer sur le bouton Manage Certificates… en bas à droite
4. Dans la nouvelle fenêtre qui s’ouvre, cliquer sur le bouton + en bas à gauche
5. Sélectionner Developer ID Application dans le menu
6. Après une seconde ou deux, un nouveau certificat apparaît dans la liste — cliquer sur Done

Un certificat émis de cette façon est automatiquement stocké dans le trousseau macOS (Keychain). Le certificat et sa clé privée correspondante sont stockés ensemble en paire, et c’est cette clé privée qui rend la signature possible.

Vérification de l’émission

Dans le terminal, exécutez la commande suivante pour confirmer que le certificat a été correctement installé.

security find-identity -v -p codesigning | grep "Developer ID Application"

Si une seule ligne comme la suivante apparaît, c’est que tout a fonctionné.

  1) A1B2C3D4E5F6...  "Developer ID Application: Gildong Hong (ABCDE12345)"

La chaîne entre guillemets est le nom officiel du certificat. Gildong Hong est le nom enregistré sur le compte Apple, et ABCDE12345 entre parenthèses est le Team ID que vous avez noté à l’Étape 1. Ce nom est utilisé tel quel plus tard lors de l’automatisation de la signature du code, vérifiez-le donc attentivement.

Renouvellement du certificat

Un certificat Developer ID est valide 5 ans. À l’approche de l’expiration, il sera marqué Expired dans la liste Manage Certificates de Xcode. À ce moment-là, il suffit d’émettre un nouveau certificat en suivant exactement la même procédure que ci-dessus.

La bonne nouvelle est que les applications déjà signées et distribuées avec l’ancien certificat ne sont pas invalidées au moment de son expiration. Seuls les nouveaux builds créés à l’avenir doivent être signés avec le nouveau certificat. Il n’y a donc pas lieu de trop s’inquiéter de l’expiration.

Étape 3 — Enregistrer un mot de passe spécifique à l’application pour la notarisation

Qu’est-ce que la notarisation ?

La notarisation est le processus qui consiste à téléverser votre application sur les serveurs d’Apple avant la distribution pour la faire analyser à la recherche de logiciels malveillants. Si elle passe l’analyse, Apple émet un « ticket de notarisation », et ce ticket doit être attaché à l’application pour que Gatekeeper l’ouvre sans avertissements. Si la signature prouve « qui l’a fabriquée », la notarisation est un processus distinct qui prouve qu’« Apple l’a analysée une fois ».

La soumission de notarisation utilise la commande notarytool d’Apple, qui demande votre mot de passe Apple ID à chaque soumission. Pour éviter de le saisir à chaque fois, vous créez un mot de passe spécifique à l’application (app-specific password) et le stockez dans le trousseau à l’avance.

3-1. Émettre un mot de passe spécifique à l’application

Un mot de passe spécifique à l’application est un mot de passe de 16 caractères utilisé uniquement à des fins spécifiques, à la place de votre mot de passe Apple ID principal.

1. Rendez-vous sur appleid.apple.com → connectez-vous avec l’Apple ID inscrit au Apple Developer Program (dans les exemples, [email protected])
2. Allez dans Sign-In and Security → sélectionnez App-Specific Passwords
3. Cliquez sur le bouton + → entrez un nom pour le mot de passe (par ex., focustimer-notarize)
4. Cliquez sur Create → entrez votre mot de passe Apple ID une fois de plus
5. Un mot de passe de 16 caractères au format abcd-efgh-ijkl-mnop apparaît à l’écran.

Une fois que vous fermez cet écran, vous ne pouvez plus consulter le mot de passe. Avant de passer à l’étape suivante, copiez-le brièvement dans un gestionnaire de mots de passe ou équivalent.

3-2. Le stocker dans un profil notarytool

Enregistrez le mot de passe reçu en tant que profil dans le trousseau. Dans la commande ci-dessous, remplacez la valeur --password par le mot de passe réel que vous venez de recevoir avant de l’exécuter.

xcrun notarytool store-credentials "focustimer-notarize" \
  --apple-id "[email protected]" \
  --team-id "ABCDE12345" \
  --password "abcd-efgh-ijkl-mnop"

• Premier argument "focustimer-notarize" — le nom à donner à ce profil. Dorénavant, vous chargerez les identifiants par ce nom lors de la notarisation.
• --apple-id — l’email du compte Apple Developer Program
• --team-id — le Team ID de l’Étape 1
• --password — le mot de passe spécifique à l’application émis en 3-1

Si la sortie suivante apparaît, c’est que tout a fonctionné.

Credentials saved to Keychain.

Maintenant que les identifiants sont stockés dans le trousseau, vous n’avez plus besoin du mot de passe spécifique à l’application original. (Cela dit, si vous prévoyez de builder sur d’autres ordinateurs, il est pratique de le conserver dans un gestionnaire de mots de passe.)

3-3. Vérification

Vérifiez que le profil enregistré fonctionne réellement.

xcrun notarytool history --keychain-profile "focustimer-notarize"

Si le message Successfully received submission history. apparaît, tout est en ordre. L’historique des soumissions en dessous peut être vide (ce qui est normal, puisque vous n’avez encore rien notarisé) ou contenir des enregistrements antérieurs.

Un piège courant — Votre Apple ID et votre compte GitHub sont différents

C’est l’endroit où les personnes qui configurent la distribution directe pour la première fois se retrouvent bloquées le plus souvent.

• Compte Apple Developer Program — utilisé pour émettre des certificats et pour la notarisation (exemple : [email protected])
• Compte GitHub — utilisé en Partie 3 pour héberger les fichiers de mise à jour (exemple : [email protected])

Dans de nombreux cas, ce sont deux emails différents. En particulier, la valeur --apple-id de notarytool store-credentials doit être l’email du compte Apple Developer. Si vous entrez l’email du compte GitHub, l’authentification échoue — et le message d’erreur n’est pas explicite, ce qui rend la cause difficile à identifier.

Si les emails des deux comptes sont faciles à confondre, nous vous recommandons de noter lequel est pour Apple et lequel est pour GitHub. Cette distinction revient régulièrement tout au long de la série.

Récapitulatif de la Partie 1

Si vous avez suivi jusqu’ici, vous disposez maintenant des éléments suivants.

• ✅ Outils en ligne de commande pour l’automatisation des publications (gh, create-dmg)
• ✅ Une adhésion active au Apple Developer Program
• ✅ Un certificat Developer ID Application stocké dans le trousseau
• ✅ Un profil d’identifiants de notarisation stocké dans le trousseau (focustimer-notarize)

Avec cela, vous êtes prêt à signer et notariser l’application. Mais presque aucune application n’est livrée aux utilisateurs une seule fois, puis terminée. Vous devez continuer à publier de nouvelles versions qui corrigent des bugs et ajoutent des fonctionnalités. Sur l’App Store, les mises à jour automatiques sont gérées pour vous, mais avec la distribution directe, c’est aussi quelque chose que vous devez mettre en place vous-même.

Dans la prochaine partie, nous créerons la clé de signature EdDSA pour Sparkle, le framework de mise à jour automatique standard de facto pour les applications macOS. C’est un mécanisme de vérification dédié aux fichiers de mise à jour — une couche supplémentaire, distincte du certificat.