Adapté aux équipes qui publient des applications macOS et doivent identifier le stade exact d’un échec de notarisation avant d’intervenir. Moins adapté à une simple validation d’application dans l’App Store : la notarisation et l’examen de l’App Store sont des processus distincts.
En cas d’échec de notarisation Apple en CI, ne relancez pas immédiatement toute la chaîne et ne signez pas de nouveau à l’aveugle. Vérifiez d’abord l’identifiant et l’état de la soumission, puis le journal Apple ; corrigez ensuite le domaine concerné — signature, droits, paquet, authentification, réseau ou agrafage du ticket. L’enregistrement de ces preuves évite notamment de confondre un téléversement réussi avec une publication autorisée.
Cet article s’adresse aux ingénieurs de publication qui maintiennent une chaîne de distribution macOS, aux équipes IT et sécurité responsables des certificats et des identifiants, ainsi qu’aux responsables des nœuds Mac CI qui définissent leurs critères d’acceptation.
00Interpréter l’état avant de relancer la CI
Le message affiché par une étape de téléversement ne suffit pas pour autoriser la distribution. La notarisation comprend des événements différents : la requête est transmise, Apple la traite, le résultat est communiqué, puis le ticket peut être agrafé au fichier et vérifié localement. La documentation Apple décrit la soumission et le suivi de l’état comme des opérations distinctes ; un code de sortie positif à l’étape d’envoi n’établit donc pas, à lui seul, que l’application est acceptée (processus officiel de notarisation macOS et état et journal d’une soumission dans l’API Notary).
Commencez par retrouver l’identifiant de soumission associé au fichier produit. Vérifiez ensuite l’état de cette soumission et récupérez son journal si Apple a rendu le résultat disponible. Enfin, identifiez l’étape exacte qui a échoué dans la CI : préparation du paquet, signature, authentification de la requête, attente du résultat ou agrafage. Il faut préserver ce contexte avant tout nouvel essai ; sans lui, une relance peut créer une seconde soumission sans expliquer la première.
| Signal observé dans la CI | Ce qu’il établit réellement | Vérification suivante |
|---|---|---|
| Le téléversement se termine sans erreur | La requête a été envoyée, pas nécessairement acceptée | Retrouver l’identifiant et interroger l’état |
| L’état est encore en cours de traitement | Aucun verdict final ne peut être déduit de ce seul état | Conserver l’identifiant et attendre un résultat consultable |
| Le résultat est un refus ou une invalidité | Le traitement a produit un résultat négatif à examiner | Télécharger le journal et traiter les remarques |
| L’état est accepté, mais l’agrafage échoue | L’acceptation n’a pas validé l’opération locale d’agrafage | Contrôler le fichier, son format et la sortie de stapler |
Les libellés exacts et les éléments disponibles dépendent de la réponse de la soumission. Utilisez l’état renvoyé par Apple plutôt qu’un résumé générique du système CI ; l’API Notary documente le suivi des soumissions et la récupération des informations de résultat (documentation de l’API Notary).
01Distinguer signature, identifiants et responsabilités
Une erreur de notarisation n’est pas automatiquement une erreur de certificat, et une erreur de certificat ne prouve pas que le nœud Mac est défectueux. La signature du code, l’authentification de la soumission et le traitement du service sont des responsabilités distinctes. Pour diagnostiquer un refus, comparez le journal Apple aux contrôles locaux du fichier et examinez séparément les identifiants utilisés par l’étape de soumission.
Apple distingue les certificats Developer ID selon leur usage, notamment la signature d’applications et celle de paquets d’installation. Vérifiez que le type d’identité correspond au livrable concerné et que la signature examinée est celle du fichier destiné à être distribué, non celle d’un composant intermédiaire (services de signature de code Apple). Pour les erreurs courantes, appuyez-vous sur les indications de résolution publiées par Apple ; ne transformez pas une mention dans un journal en diagnostic plus large que ce qu’elle établit (résolution des problèmes courants de notarisation).
| Domaine de panne | Indices à rapprocher | Équipe généralement responsable de l’analyse |
|---|---|---|
| Signature du code | Identité utilisée, intégrité de la signature, éléments du paquet cités par le journal | Équipe de construction et de signature |
| Authentification de soumission | Identifiants configurés pour l’outil et erreur retournée lors de la requête | Responsable CI et équipe de gestion des secrets |
| Traitement de la soumission | État Apple, identifiant de soumission et remarques du journal | Responsable de publication, avec escalade si nécessaire |
| Environnement du nœud | Accès au trousseau, compte de service, connexion et contexte d’exécution | Équipe plateforme Mac CI |
Cette séparation évite une correction risquée, comme changer des certificats alors que l’erreur concerne l’accès aux identifiants de soumission, ou reconstruire un nœud quand le journal désigne le paquet. En cas de problème d’authentification, vérifiez quelle identité la tâche CI utilise réellement et si son accès au trousseau est disponible dans le contexte d’exécution. Ne placez pas de clé privée dans les journaux ni dans un artefact accessible à des tâches non autorisées ; consignez plutôt la méthode d’accès et les contrôles effectués.
02Examiner le paquet réellement distribué
Les journaux de notarisation doivent être confrontés au livrable final. Une compilation peut produire un composant intermédiaire correct, puis l’étape d’assemblage ou de signature modifier le paquet qui part en soumission. Contrôlez donc le fichier complet préparé pour la distribution : son format, sa structure, sa signature et les droits intégrés. Apple décrit les formats et les étapes de préparation dans ses recommandations de conditionnement des logiciels Mac (conditionnement d’un logiciel Mac pour distribution).
Lorsque le journal mentionne une signature ou une structure invalide, vérifiez les composants inclus et les droits effectivement embarqués dans la version soumise. N’inférez pas qu’un droit est nécessaire ou incorrect uniquement parce qu’il paraît inhabituel : rapprochez l’élément signalé des capacités réellement requises par l’application et des règles de signature Apple. Si le journal indique une pièce du paquet, inspectez cette pièce et remontez à l’étape qui l’a créée ou modifiée.
| Format de distribution | Points de contrôle avant d’interpréter l’échec | Contrôle après acceptation |
|---|---|---|
| Application ou archive destinée à livrer une application | Signature du contenu final, structure des composants et droits intégrés | Vérification de la signature et, si le flux le prévoit, agrafage du ticket |
| Image disque | Contenu réellement distribué et identité de la version soumise | Agrafage sur le format concerné puis vérification du fichier livré |
| Paquet d’installation | Signature appropriée au paquet et cohérence avec les éléments inclus | Vérification du paquet final et de son ticket, selon le flux Apple |
Ce tableau sert à localiser les éléments à inspecter, pas à remplacer les instructions propres à chaque format. Apple présente les exigences de préparation et de distribution dans ses documents de notarisation et de conditionnement. Si le paquet a été transformé après la soumission, l’acceptation d’une version précédente ne justifie pas la distribution de cette nouvelle version : il faut établir quel fichier correspond à l’identifiant et au résultat conservés.
03Conserver le contexte lorsque le journal ne suffit pas
Un résultat absent ou peu explicite ne justifie pas une succession de soumissions identiques. Avant toute nouvelle tentative, consignez l’identifiant de soumission, la réponse d’état, le journal disponible, le nom et l’empreinte du fichier examiné, ainsi que la tâche CI qui a initié la requête. Cette trace aide à distinguer une soumission encore en traitement, un résultat refusé et une difficulté à récupérer le journal.
Si aucun résultat consultable n’est disponible, vérifiez d’abord si la CI a conservé l’identifiant et si l’étape de suivi a interrogé la bonne soumission. Recherchez également une interruption réseau entre l’envoi et la collecte du résultat : elle peut laisser le pipeline sans contexte, sans démontrer que la soumission n’existe pas. Vérifiez l’état des services de développement Apple si les symptômes concernent la disponibilité ; l’état des systèmes Apple destinés aux développeurs permet de vérifier les incidents publiés, sans prédire le délai de traitement d’une demande.
La règle opérationnelle est simple : ne soumettez de nouveau qu’après avoir confirmé l’état de la demande existante, ou après avoir corrigé un défaut identifié du fichier ou de l’authentification. Ne présumez pas d’un délai fixe de traitement. Quand le journal nomme un défaut, la priorité est de le reproduire et de le corriger ; quand il manque, préservez les éléments utiles et séparez le problème de collecte du problème de notarisation lui-même.
04Réponses aux questions de diagnostic fréquentes
Après un envoi notarytool réussi, mais un état négatif, que faut-il examiner ?
Retrouvez l’identifiant de soumission et consultez l’état puis le journal associés. Un envoi réussi ne vaut pas décision favorable. Le journal est le point de départ pour déterminer si le problème concerne le fichier, la signature ou un autre aspect du traitement. Ne relancez pas une requête identique tant que l’état existant n’est pas établi.
Quels éléments du journal orientent vers un défaut de signature ?
Une remarque qui concerne la signature ou un composant particulier doit être rapprochée du contrôle local du paquet final. Vérifiez l’identité employée et l’intégrité du contenu distribué. Distinguez ces éléments d’une erreur d’identifiants de soumission : ce sont deux domaines différents et ils ne justifient pas les mêmes changements dans la CI.
Une application acceptée nécessite-t-elle encore stapler ?
L’acceptation par Apple et l’agrafage local du ticket ne sont pas une seule et même validation. Selon le format et le mode de distribution, l’étape d’agrafage peut faire partie du flux. Contrôlez les consignes Apple applicables au livrable, exécutez l’agrafage prévu, puis vérifiez le fichier final plutôt que de vous arrêter à l’état d’acceptation.
Faut-il signer de nouveau ou téléverser le paquet une seconde fois ?
Choisissez l’action d’après le défaut prouvé. Un problème de signature ou de structure appelle une correction de la construction du paquet final ; un problème d’identifiants ou de réseau appelle une vérification de l’étape de soumission. Si le traitement est toujours en cours, conservez son identifiant et vérifiez son état avant de créer une autre demande.
05Vérifier le ticket et le fichier remis
L’acceptation confirme un résultat de notarisation ; elle ne prouve pas que l’étape locale d’agrafage a réussi ni que le fichier effectivement remis est celui qui a été accepté. Apple fournit stapler pour les flux d’agrafage et des méthodes de validation associées. Utilisez les commandes adaptées au format concerné et conservez les sorties dans les preuves de publication, en suivant la documentation Apple sur la notarisation et la distribution (notarisation des logiciels macOS).
| Résultat recherché | Preuve à archiver | Critère d’acceptation CI |
|---|---|---|
| Signature cohérente | Sortie du contrôle de signature sur le livrable final | L’identité et le fichier contrôlé correspondent aux éléments publiés |
| Soumission traçable | Identifiant de soumission et réponse d’état Apple | Le résultat est consultable et associé au fichier conservé |
| Ticket traité | Sortie de l’agrafage et validation du ticket | La vérification porte sur la version destinée à la distribution |
| Publication reproductible | Référence de version, tâche exécutée et journal correspondant | Une personne habilitée peut relier le fichier aux preuves sans exposer de secret |
Pour un fichier modifié après son acceptation, reprenez les vérifications sur la nouvelle version ; ne réutilisez pas la preuve d’un autre paquet. Si l’agrafage échoue malgré un résultat accepté, vérifiez d’abord le format et le chemin exacts transmis à l’outil, puis examinez la sortie complète. Un contrôle fait sur un artefact temporaire n’est pas une validation du fichier copié vers le stockage de publication.
06Transformer le diagnostic en barrière de publication
La liste suivante constitue la preuve minimale à relier à une décision de mise en production. Chaque élément doit référencer le même livrable et la même exécution ; une collection de journaux provenant de builds différents ne forme pas une preuve cohérente.
- [ ] La CI conserve la sortie de vérification de la signature du paquet distribué.
- [ ] L’identifiant de soumission est associé à la version et au fichier concernés.
- [ ] L’état Apple est enregistré ; si un journal est disponible, il est conservé avec la réponse qui lui correspond.
- [ ] La sortie d’agrafage est conservée lorsque le format et le flux de distribution le requièrent.
- [ ] La validation finale porte sur le fichier réellement transmis aux utilisateurs.
- [ ] L’exécution identifie le compte de service et la méthode d’accès aux identifiants sans enregistrer de clé privée ou de secret.
- [ ] Les étapes échouées restent visibles comme telles ; une réussite de téléversement ne peut pas être interprétée comme un verdict final.
Appliquez ensuite cette branche de décision :
- Si le journal désigne la signature, le contenu ou les droits, corrigez la construction du livrable, puis contrôlez à nouveau le fichier final ; ne changez pas les identifiants CI sans indice les concernant.
- Si l’erreur intervient avant la soumission ou concerne l’authentification, vérifiez le compte de service, l’accès au trousseau et la configuration des identifiants ; ne reconstruisez pas le paquet tant que rien ne met sa signature en cause.
- Si la requête a été envoyée mais que le résultat manque, retrouvez l’identifiant, l’état et les informations de suivi avant toute nouvelle tentative ; examinez aussi le réseau de sortie et la collecte de résultat.
- Si Apple a accepté le fichier mais que l’agrafage ou sa vérification échoue, traitez cette opération séparément et vérifiez le format ainsi que le chemin du fichier remis.
- Si l’état Apple indique un problème de service, consultez l’état des systèmes et préservez les éléments du pipeline ; ne modifiez pas un artefact sain pour compenser un incident de service.
Cette séparation détermine aussi quand escalader. Un défaut reproductible dans le paquet relève de l’équipe qui le construit et le signe ; un accès au trousseau ou un compte de service indisponible relève de l’exploitation CI et de la gestion des secrets ; une soumission dont le résultat ne peut pas être récupéré nécessite d’examiner la réponse Apple, le réseau et le suivi de la requête. La présence du nœud en ligne ne remplace aucun de ces contrôles.
Pour une publication régulière, ces critères peuvent être intégrés au contrôle de sortie de la chaîne afin que l’équipe ne dépende pas d’une lecture manuelle du seul résumé CI. Ils sont également utiles lorsque la compilation s’exécute sur un Mac distant : la validation doit porter sur les identifiants réellement disponibles au processus, le fichier final et les preuves de notarisation, pas seulement sur la disponibilité de la machine.
Quand le diagnostic révèle un manque temporaire de capacité Mac CI, une location peut éviter l’achat immédiat d’un poste supplémentaire ; elle ne résout toutefois ni une mauvaise configuration de signature ni un accès réseau ou trousseau mal défini. L’achat reste pertinent pour une charge soutenue et un contrôle matériel permanent, tandis qu’un nœud distant implique de vérifier les accès, les règles de conservation des fichiers et les conditions d’exploitation. Pour comparer ce modèle à votre besoin, consultez les informations sur le service de Mac distant de NUKCLOUD et ses informations d’aide, puis validez le flux avec un vrai livrable avant d’en faire un critère de publication.