Comment configurer Apple notarytool en CI d’entreprise ? Guide de déploiement 2026

Cette semaine, ajoutez à votre CI des étapes distinctes pour construire et signer, soumettre, vérifier le statut, traiter le ticket et contrôler le paquet final. Si la chaîne dépend de Xcode ou de stapler, validez ces opérations sur macOS ; Notary API peut remplacer certaines opérations de soumission et de consultation, pas l’ensemble de la construction Apple. C’est le cadre à appliquer à Apple notarytool en CI d’entreprise.

À lire si vous distribuez des applications macOS hors du Mac App Store et devez automatiser la signature Developer ID et la notarisation.
Utile également aux responsables de plateforme qui encadrent les identifiants, les secrets et les droits de pipeline.
Les personnes chargées de la publication y trouveront des contrôles pour vérifier le résultat et le paquet effectivement livré.

Préparer la chaîne Apple notarytool en CI d’entreprise

Commencez par déterminer ce que vous distribuez : une application macOS, un installateur ou une image disque. Ce choix détermine le fichier que vous soumettrez, puis celui sur lequel vous devrez effectuer les contrôles finaux. Une soumission d’archive réussie ne prouve pas, à elle seule, que le contenu déployé correspond à la version approuvée.

La notarisation concerne notamment les logiciels distribués hors du Mac App Store avec Developer ID. Elle ne remplace ni la signature du code ni l’examen d’une application par une boutique. Apple décrit les exigences applicables à la notarisation d’un logiciel macOS avant sa distribution ; pour une distribution Developer ID, vérifiez aussi les consignes Apple relatives à cet identifiant. Le parcours de publication du Mac App Store ne doit donc pas être traité comme une variante identique de cette chaîne.

Avant de modifier le pipeline, consignez le format remis à l’utilisateur, la commande ou le mécanisme de construction, le certificat utilisé et la personne responsable de la publication. Vous éviterez ainsi de comparer des étapes qui ne portent pas sur le même objet : l’application construite, son archive de soumission et le fichier distribué peuvent être différents.

Ce tableau décrit des choix de mise en œuvre, pas un classement universel. Pour une chaîne automatisée, notarytool fournit une interface en ligne de commande ; l’API peut remplacer une partie des échanges de notarisation, mais ne fait pas disparaître les dépendances à l’environnement macOS lorsque votre construction ou le traitement du paquet en a besoin. Apple décrit les possibilités de personnalisation du flux de notarisation et documente séparément la soumission à Notary API.

Construire un artefact signé et traçable

Faites porter les contrôles sur le candidat réel à la publication, et non sur un artefact intermédiaire que le pipeline abandonne ensuite. Pour chaque exécution, reliez le commit, l’identifiant du travail CI, les paramètres de construction, l’identité de signature et le fichier transmis. Ces éléments aident à établir si le paquet inspecté après la notarisation est bien celui que vous aviez prévu de publier.

Pour une distribution Developer ID, vérifiez les conditions de signature applicables, notamment le Hardened Runtime et l’horodatage lorsque ceux-ci sont requis par votre configuration. Apple documente les réglages du Hardened Runtime. Ne transformez pas cette liste de contrôles en règle générique déconnectée du type de logiciel : examinez les exigences propres à votre cible et aux entitlements dont elle a besoin.

Une compilation réussie n’est pas une preuve de conformité du paquet. Ajoutez une vérification de signature au fichier exporté et archivez son résultat avec les métadonnées de construction. Si une modification de signature, d’entitlements ou d’exportation intervient après la construction, traitez le fichier modifié comme un nouvel artefact à vérifier, plutôt que de réutiliser sans contrôle l’état précédent.

Pour un développement interne ou un test, une signature de développement peut convenir à l’usage prévu ; ne la confondez pas avec l’identité et les exigences de distribution hors du Mac App Store. Si vous utilisez Xcode Organizer pour certaines publications, comparez ses entrées et ses sorties au parcours automatisé : l’interface ne dispense pas l’équipe de décider quel fichier est la référence, ni de conserver des preuves de validation.

Isoler les identifiants et les droits de pipeline

Choisissez une méthode d’authentification documentée pour l’usage retenu. Les options ne sont pas interchangeables : la configuration d’une clé d’API App Store Connect implique les informations et les autorisations correspondant à cette clé, tandis qu’un parcours fondé sur un compte Apple repose sur ses propres éléments d’identification. Consultez les instructions Apple pour créer une clé d’API App Store Connect, puis vérifiez que les droits accordés sont adaptés aux opérations réellement exécutées.

Évitez d’inscrire un secret dans le dépôt, dans une commande versionnée ou dans un fichier de configuration partagé. Le pipeline doit recevoir les éléments sensibles depuis un stockage de secrets contrôlé, et seuls les travaux qui en ont besoin doivent pouvoir les lire. Définissez aussi qui peut modifier la configuration, qui est responsable de son renouvellement et comment retirer un accès lorsqu’un rôle change.

Les journaux CI méritent un contrôle spécifique. Vérifiez si les commandes affichent des arguments sensibles, si des traces de débogage pourraient les révéler et si les artefacts de diagnostic contiennent des fichiers d’authentification. Une valeur masquée à l’affichage n’est pas une raison pour l’imprimer volontairement : construisez le test de pipeline de manière à ne pas inclure le secret dans les sorties.

Dans une chaîne de publication, la portée du secret est aussi importante que son emplacement : si une tâche de compilation générale peut lire l’identifiant de notarisation, un changement sans rapport avec une publication peut élargir inutilement le nombre de travaux exposés. Séparez donc les étapes qui construisent du code de celles qui publient, et associez à ces dernières des permissions correspondant à leur rôle.

Soumettre le paquet et conserver la preuve d’état

La question à résoudre n’est pas seulement « le téléversement a-t-il abouti ? », mais « quelle soumission Apple a-t-elle traitée et quel est son résultat ? ». Avec notarytool, votre tâche de CI doit soumettre le fichier choisi, récupérer l’identifiant retourné et le conserver avec le journal de publication. Apple permet de personnaliser ce flux avec notarytool, notamment pour consulter l’état et les journaux de soumission ; le guide officiel du flux de notarisation décrit ces opérations.

Une séquence de commandes peut prendre cette forme, à adapter à votre authentification et à votre format d’archive :

xcrun notarytool submit Produit.zip --keychain-profile profil-ci --wait
xcrun notarytool log IDENTIFIANT_DE_SOUMISSION --keychain-profile profil-ci

Ne copiez pas ces lignes comme configuration complète : le nom du profil, le fichier soumis et la méthode d’authentification dépendent de votre environnement. Le point essentiel est de conserver l’identifiant de soumission et de récupérer le journal associé si le traitement signale un problème. Un transfert achevé ne vaut pas validation finale ; le pipeline doit attendre un résultat exploitable et faire échouer la porte de publication si le statut ne satisfait pas la politique définie par votre équipe.

Notary API peut être retenue lorsque vous voulez intégrer les échanges de soumission ou de suivi à votre propre orchestration. Apple documente son fonctionnement et les étapes de soumission d’un logiciel via Notary API. Ne déduisez pas de cette possibilité que l’API fournit Xcode, construit l’application, signe le binaire ou effectue automatiquement les opérations de stapler. Confirmez séparément l’authentification et les capacités nécessaires à chaque étape.

Quand le statut est Invalid, le journal est le point de départ du diagnostic, pas une raison de relancer aveuglément le même fichier. Rattachez le message à l’artefact exact, puis examinez la signature, les entitlements, le Hardened Runtime, l’archive et les modifications intervenues lors de l’exportation. Corrigez le défaut, reconstruisez ou réexportez le candidat concerné, et conservez le journal et la nouvelle référence de soumission pour rendre l’écart compréhensible lors d’une revue ultérieure.

Traiter le ticket et vérifier le livrable

Une notarisation acceptée n’est pas la fin de l’acceptation interne. Il reste à vérifier que le fichier donné aux utilisateurs est celui qui a été soumis, qu’il n’a pas été altéré ensuite et qu’il satisfait votre mode de distribution. Gardez des contrôles distincts pour le résultat retourné par Apple et pour l’intégrité de l’artefact de sortie : ils répondent à des questions différentes.

Selon le format livré, vous pouvez devoir agrafer, ou « stapler », le ticket à l’élément de distribution adapté. Apple documente les formats et les limites de traitement dans son guide du flux de notarisation. En particulier, ne supposez pas qu’un fichier ZIP peut recevoir directement un ticket avec stapler : examinez le contenu et choisissez le composant pris en charge que vous remettez réellement aux utilisateurs. Le ZIP peut être le conteneur soumis ; cela ne signifie pas que ce conteneur soit lui-même l’objet à agrafer.

xcrun stapler staple Produit.dmg
xcrun stapler validate Produit.dmg

Ces exemples illustrent un contrôle sur une image disque ; ils ne constituent pas une prescription pour tous les formats. Adaptez l’opération au paquet distribué et aux indications Apple, puis validez le ticket sur le candidat final. Archivez les résultats de validation, le journal de notarisation et l’empreinte ou autre référence interne permettant de rattacher le livrable à son exécution de CI.

Si la notarisation est acceptée mais que le contrôle final échoue, bloquez la publication jusqu’à clarification. Examinez si le paquet a été transformé après soumission, si l’étape de traitement concernait le bon objet et si le contrôle a été effectué sur la même version que celle destinée aux utilisateurs. Pour un échec, conservez aussi les paramètres pertinents de construction et de signature : sans eux, le journal seul peut ne pas suffire à reconstituer la cause.

Décider quel environnement peut porter la publication

Effectuez une exécution complète avant de déclarer la chaîne prête : construction, signature, authentification, soumission, contrôle de statut, traitement du ticket lorsqu’il s’applique et validation du fichier livré. Pour chacune de ces opérations, indiquez l’entrée, la sortie attendue, la preuve conservée et la responsabilité de l’équipe. Une tâche verte sans ces éléments ne donne pas au responsable de publication assez d’information pour autoriser une diffusion reproductible.

Utilisez ensuite les conditions de décision suivantes :

• Si la construction ou la signature requiert Xcode, ou si le format livré doit être traité par stapler, exécutez et validez ces étapes sur un environnement macOS adapté ; ne remplacez pas cette vérification par le seul fait que l’API accepte une soumission.
• Si vous voulez simplifier l’orchestration de la soumission ou du suivi, évaluez Notary API pour ces opérations précises, après avoir confirmé son authentification et ses réponses dans la documentation Apple.
• Si les versions arrivent à la publication sans association fiable entre commit, signature, soumission et livrable, bloquez la mise en production et améliorez d’abord la traçabilité.
• Si la publication dépend d’un poste disponible en continu ou de droits d’accès trop larges, séparez les responsabilités et testez la chaîne avec les permissions minimales nécessaires avant d’augmenter sa portée.

Pour vérifier le portage d’une tâche CI vers un Mac distant, examinez d’abord les contraintes de votre propre pipeline : disponibilité des outils, accès réseau, gestion des secrets, sessions nécessaires et contrôle de l’environnement. Vous pouvez consulter les informations disponibles sur les nœuds Mac proposés par VPSMAC, mais ne déduisez pas d’une page de nœuds que votre procédure de sécurité, vos accès ou votre cadence de publication sont pris en charge sans vérification. Le choix de l’environnement ne remplace ni la gouvernance des certificats ni les contrôles de votre organisation.

Un poste Mac acheté peut être cohérent si votre charge est continue, si vous avez besoin d’interfaces physiques ou si vous devez maîtriser directement le matériel ; il vous laisse toutefois gérer l’achat, la maintenance et la disponibilité. Un environnement CI partagé peut limiter la gestion d’équipements dédiés, mais ne convient pas si votre tâche exige un accès local ou une configuration que vous ne pouvez pas valider. Pour des essais temporaires ou une capacité Mac à ajouter à la demande, la location d’un Mac distant via VPSMAC peut être plus simple à évaluer qu’un achat immédiat ; vérifiez d’abord les modalités réelles et exécutez votre chaîne complète avant de lui confier une publication. Si votre équipe ne peut pas tester l’isolation des secrets, la reprise après échec et le contrôle du livrable, gardez la publication sur un environnement déjà validé.