La notarisation d’apps macOS peut être intégrée à un CI Mac distant : préparez d’abord une application signée avec Developer ID, soumettez-la avec notarytool, puis vérifiez le résultat, le ticket et le paquet réellement distribué. Cette procédure concerne la distribution en dehors du Mac App Store ; elle ne remplace ni l’examen d’une app ni la validation de votre livraison.
Cet article s’adresse aux développeurs indépendants qui automatisent une publication Developer ID, aux ingénieurs qui maintiennent les étapes Archive et export, et aux équipes DevOps responsables des certificats, des secrets et des journaux de publication.
Action à mener cette semaine : faites passer une publication réelle, mais isolée, dans toute la chaîne avant d’autoriser une mise en ligne automatique.
Avant la soumission : délimiter la livraison et préparer les artefacts
La notarisation s’insère dans une chaîne de publication, et non dans un raccourci qui transformerait un build quelconque en application prête à distribuer. Le périmètre présenté ici est celui d’une app macOS signée pour une distribution Developer ID hors du Mac App Store. La soumission à Apple, son traitement et la remise du logiciel à l’utilisateur sont des étapes distinctes. Le flux du Mac App Store suit un autre parcours.
Pour chaque publication, la chaîne doit relier les éléments suivants : le code source et sa révision, l’artefact signé envoyé à la notarisation, l’identifiant de soumission, le résultat de traitement, l’éventuelle opération de fixation du ticket et le fichier final destiné au téléchargement. La documentation Apple décrit la notarisation avant distribution et les conditions générales de préparation dans son guide sur la notarisation des logiciels macOS.
Il faut notamment distinguer l’archive produite par Xcode, l’application exportée et le paquet finalement transmis aux utilisateurs. Ces objets peuvent se ressembler sans être identiques. Si l’archive est notarée, mais qu’un script reconstruit ou modifie ensuite l’application exportée, le résultat contrôlé n’est plus nécessairement celui qui sera distribué.
Quel état doit avoir l’application avant la notarisation ?
L’étape de signature doit être qualifiée avant d’ajouter la soumission au CI. Vérifiez que la cible est signée pour le type de distribution visé, que Hardened Runtime est configuré lorsque requis, que l’horodatage est présent et que les composants de code inclus sont cohérents avec l’application. Les exigences applicables et la manière de préparer le code sont détaillées dans la documentation Apple sur la signature de code destinée à la distribution sur Mac.
Évitez de copier des valeurs de certificat, d’équipe ou de configuration depuis un exemple générique : elles dépendent du compte, du projet et de la méthode de signature. Le CI doit plutôt consigner, pour chaque artefact, le nom du fichier, son empreinte, les résultats des contrôles de signature disponibles et la révision source associée. Cette association permet de déterminer si un échec vient d’un artefact différent, d’une signature incorrecte ou du traitement de la soumission.
Pour établir une première base reproductible, conservez les résultats de contrôle immédiatement après l’export, avant la notarisation. Si l’équipe ne peut pas retrouver avec certitude quel fichier a été envoyé, elle ne pourra pas prouver que le fichier remis au public correspond au fichier accepté.
Comment réaliser la notarisation d’une app macOS dans un CI distant ?
Sur le Mac qui exécute le travail, vérifiez d’abord que la version sélectionnée de Xcode ou des outils de ligne de commande donne accès à notarytool. Apple indique que cet outil est destiné aux flux de notarisation automatisés. La migration documentée par Apple précise également qu’à compter du 1er novembre 2023, les envois de notarisation via altool ou Xcode 13 et les versions antérieures ne sont plus acceptés ; consultez la note de migration vers l’outil de notarisation actuel avant de maintenir un ancien script.
Insérez la soumission après la signature et l’export, avec un profil d’identifiants préconfiguré sur le Mac d’exécution. L’exemple ci-dessous utilise des valeurs fictives : il ne contient ni identifiant de compte ni secret.
xcrun notarytool submit "<CHEMIN_DE_L_ARTEFACT>" \
--keychain-profile "<PROFIL_DE_NOTARISATION>" \
--wait
Le profil désigne une configuration d’authentification disponible pour le processus CI ; ce n’est pas une raison pour placer ses identifiants dans la commande ou le dépôt. Vérifiez les options prises en charge par l’outil sélectionné dans la documentation Apple consacrée à la personnalisation d’un flux de notarisation. Le résultat attendu n’est pas un simple code de retour : le pipeline doit aussi conserver l’identifiant de soumission et le statut rapporté.
Comment le CI distant peut-il conserver et utiliser les identifiants de notarisation ?
Un profil du trousseau et un gestionnaire de secrets de CI remplissent des rôles différents. Le gestionnaire de secrets contrôle l’accès et l’injection de données sensibles au démarrage du travail ; le profil du trousseau permet à l’outil de notarisation de retrouver localement les informations d’authentification configurées. L’équipe doit décider comment ces deux mécanismes s’articulent sur son nœud, plutôt que de supposer que l’un remplace automatiquement l’autre.
Sur un exécuteur partagé, les secrets ne doivent pas être accessibles à des travaux sans rapport avec la publication. Limitez l’accès au travail de mise en production, évitez de les imprimer dans les journaux et ne les transmettez pas comme arguments visibles de commande. Un processus éphémère ou un compte macOS réservé aux publications peut limiter la portée d’un incident, mais il faut vérifier le comportement du trousseau et les permissions avec le mode d’exécution réel du CI.
Apple documente plusieurs possibilités dans ses pages sur les flux personnalisés de notarisation et l’API Notary. Les paramètres d’authentification et les choix d’API doivent être vérifiés dans ces références au moment de la mise en œuvre ; cet article ne fournit pas de valeur de compte, de nom d’équipe ni de secret à réutiliser.
Point de contrôle : si un journal de CI contient une commande développée avec un secret, considérez ce secret comme exposé. Supprimez l’accès au journal selon la procédure de l’équipe, faites tourner l’identifiant concerné et relancez la publication avec une configuration assainie.
Après l’envoi : suivre le traitement et interpréter les preuves
Un envoi terminé n’établit pas, à lui seul, que le logiciel peut être distribué. Le pipeline doit conserver le statut associé à la soumission et savoir récupérer le journal détaillé lorsqu’un résultat est négatif ou qu’un avertissement demande une analyse. La page Apple sur la résolution des problèmes courants de notarisation aide à interpréter les indications retournées sans réduire tous les échecs à une cause unique.
Que vérifier après une soumission notarytool réussie ?
Il faut séparer le fait que le service a reçu la demande, le résultat de traitement et l’état du livrable. Une réponse de réception ou un identifiant de soumission sert à retrouver le dossier ; le statut final et le journal associé indiquent ce qui a été traité. Le mot « Accepted » ne démontre pas, à lui seul, que le fichier qui sera téléchargé est bien celui qui a été soumis, qu’il porte une signature valide ou qu’il se lance correctement sur une machine de test.
Lorsque le statut ou les avertissements nécessitent un diagnostic, récupérez le journal lié à l’identifiant conservé par le pipeline. La forme d’appel ci-dessous est un exemple à confronter à la documentation de la version utilisée ; le profil reste un nom de configuration, pas une donnée secrète à inscrire en clair.
xcrun notarytool log "<IDENTIFIANT_DE_SOUMISSION>" \
--keychain-profile "<PROFIL_DE_NOTARISATION>" \
"<CHEMIN_DU_JOURNAL>"
Classez ensuite les preuves avant d’agir :
- Signature : vérifiez l’identité de signature attendue et les composants de code présents dans l’artefact exporté.
- Droits et configuration : examinez les indications du journal et la configuration des entitlements, sans conclure à une cause qui n’y figure pas.
- Format de l’artefact : confirmez que le fichier soumis correspond au format et au contenu attendus pour cette étape.
- Réponse du service : conservez le statut, l’identifiant de soumission et les messages retournés afin de pouvoir distinguer un problème de traitement d’une erreur de préparation.
- Exécution du CI : examinez les journaux locaux, les permissions et la connectivité seulement si les éléments disponibles orientent vers cette piste.
Une erreur unique ne suffit donc pas à conclure que le nœud distant ou le réseau est en panne. Le journal de notarisation, le log du travail et les contrôles de signature répondent à des questions différentes ; les rapprocher est plus fiable que relancer aveuglément la soumission.
Après acceptation : traiter le ticket selon le format livré
La soumission, l’acceptation du traitement, la fixation du ticket et l’installation par un utilisateur ne sont pas des synonymes. Selon le format réellement distribué — application, archive compressée, image disque ou paquet d’installation — la suite du traitement peut varier. Consultez les règles actuelles de prise en charge et de conditionnement dans la documentation Apple sur la préparation d’un logiciel Mac à la distribution avant d’ajouter une commande de fixation au pipeline.
Lorsque le format s’y prête et que la procédure l’exige, stapler peut servir à fixer le ticket et à valider l’opération. Les commandes ci-dessous sont des exemples : leur emploi et le type d’artefact à leur fournir doivent être confirmés dans la documentation Apple correspondant au format livré.
xcrun stapler staple "<CHEMIN_DE_L_ARTEFACT>"
xcrun stapler validate "<CHEMIN_DE_L_ARTEFACT>"
Conservez le résultat de la validation comme preuve distincte du statut de soumission. La validation du ticket ne remplace pas l’inspection de la signature et ne prouve pas non plus que le paquet téléchargé par l’utilisateur est intact. Si le fichier livré est une archive contenant l’application, contrôlez le contenu obtenu après extraction ; si l’équipe distribue un autre format, vérifiez le paquet effectivement publié et non une copie antérieure.
Comment vérifier qu’un ticket est bien fixé après la notarisation ?
Le contrôle doit porter sur l’artefact final qui sera remis au public. Enregistrez le résultat de stapler validate lorsque cette opération est pertinente pour le format, contrôlez à nouveau la signature du contenu distribué et effectuez un essai d’installation ou de lancement dans un environnement de test adapté. L’acceptation du service, la présence d’un ticket exploitable, l’intégrité de la signature et le démarrage réel sont des preuves complémentaires, non interchangeables.
Pour éviter une fausse validation, ne remplacez pas le fichier après ces contrôles sans recommencer les vérifications sur la nouvelle version. Une compression, une copie vers un répertoire de publication ou une étape de packaging peut modifier l’objet transmis ou sélectionner un artefact différent. Le manifeste du travail devrait donc désigner explicitement le fichier contrôlé et le fichier publié.
Avant la mise en ligne : choisir le niveau d’automatisation à partir des preuves
La première publication automatisée doit utiliser une tâche isolée, avec un artefact représentatif et une destination de test. Suivez la chaîne depuis la révision source jusqu’au paquet obtenu après téléchargement, en conservant les journaux de compilation, le résultat de signature, l’identifiant de soumission, le statut, le journal d’analyse en cas d’échec et les contrôles de l’artefact final.
La mise en production ne doit être automatisée que si les éléments suivants sont retrouvables sans interprétation manuelle : la révision source, l’artefact signé soumis, la réponse de notarisation et le paquet contrôlé après packaging. En cas d’écart entre ces éléments, gardez une validation humaine ou suspendez la publication. Documentez également qui peut renouveler les identifiants, qui traite un échec de soumission et comment reprendre un travail interrompu sans publier un fichier dont la provenance est incertaine.
La décision peut être prise avec les conditions suivantes :
- Si le fichier livré est identique à l’artefact contrôlé, que les journaux relient la soumission au code source et que les vérifications de signature et de ticket sont concluantes, alors autorisez l’automatisation pour ce parcours de distribution.
- Si le traitement est accepté mais que le fichier final n’a pas été validé, alors conservez une étape de validation avant mise en ligne.
- Si les journaux ne permettent pas de relier le paquet à une révision et à une soumission, alors bloquez la publication et corrigez la traçabilité.
- Si un format ou une étape de packaging n’est pas couvert par la procédure vérifiée, alors revenez à une validation manuelle documentée jusqu’à qualification du cas.
Le tableau suivant aide à distinguer les preuves au lieu de traiter le statut de notarisation comme un verdict global.
| Preuve disponible | Ce qu’elle permet de conclure | Ce qu’elle ne démontre pas |
|---|---|---|
| Identifiant et statut de soumission | Le dossier de traitement peut être suivi et son résultat examiné | Que le fichier finalement distribué est celui qui a été soumis |
| Journal de notarisation | Les messages de traitement peuvent orienter le diagnostic | Que la configuration de signature ou le paquet final est correct |
| Résultat de validation du ticket | Le ticket a été contrôlé sur l’artefact visé, selon le format pris en charge | Que la signature est valide ou que l’installation réussira |
| Contrôle du paquet téléchargé | Le fichier publié a été vérifié après packaging ou transfert | Que les prochaines publications suivront automatiquement le même chemin |
| Essai d’installation ou de lancement | Le scénario de vérification choisi fonctionne dans l’environnement testé | Que toutes les configurations de postes utilisateurs ont été couvertes |
Les options opérationnelles dépendent ensuite du niveau de preuve disponible :
| Situation de l’équipe | Décision de publication | Action de repli |
|---|---|---|
| Chaîne complète et artefact final vérifié | Automatiser le parcours qualifié | Bloquer si le manifeste ou le fichier change |
| Résultat de notarisation connu, paquet final non contrôlé | Maintenir une validation avant publication | Ajouter le contrôle après packaging |
| Identifiants ou journaux accessibles trop largement | Suspendre l’automatisation | Restreindre les permissions et renouveler les secrets exposés |
| Échec dont la cause n’est pas établie | Ne pas relancer à l’aveugle | Examiner les journaux du service, de signature et du CI |
| Besoin de Mac ponctuel pour qualifier la chaîne | Tester sur un environnement Mac disponible | Comparer le coût d’un Mac local avec un accès distant temporaire |
Un Mac local peut être préférable si le poste doit rester disponible en permanence ou si la chaîne dépend d’interfaces physiques. Un exécuteur Linux ne remplace pas le Mac pour les étapes qui exigent les outils macOS. À l’inverse, acheter une machine uniquement pour qualifier une publication ponctuelle immobilise un budget matériel et impose de gérer son entretien et ses accès. Lorsque l’environnement manque, il est possible d’examiner les conditions d’accès à un Mac mini distant avec NodeMini et de les confronter aux exigences réelles du projet ; les modalités disponibles doivent être vérifiées sur la page de service.
La notarisation d’apps macOS dans un CI Mac distant est donc un choix raisonnable si le processus conserve une trace complète entre la signature et le fichier remis aux utilisateurs. Avant toute automatisation générale, faites passer une publication réelle dans ce parcours et confirmez que les outils, les actifs de signature et le contrôle des secrets conviennent à l’équipe. Si aucun Mac n’est disponible pour ce test, les options Mac proposées par NodeMini peuvent être examinées comme environnement temporaire ; pour un besoin permanent ou dépendant de matériel local, l’achat d’un Mac peut rester plus adapté.