Que faire si un certificat Apple Developer a expiré ? Réparer la publication iOS en 2026

Apple indique qu’un certificat Apple Distribution est valide pendant un an : la documentation officielle sur les certificats distingue aussi les certificats selon leur usage. Si une signature échoue, identifiez d’abord si le problème vient du certificat, du Provisioning Profile ou du compte, puis corrigez l’actif concerné et vérifiez une nouvelle archive sur le Mac qui réalise réellement la compilation.

Symptôme → solution rapide
Certificat expiré ou signature refusée → relevez le statut exact et le type de signature avant de créer ou révoquer un certificat.
Nouveau certificat visible dans le compte, mais compilation toujours en échec → vérifiez sa clé privée, le profil et le trousseau de la machine de construction.

Ce guide s’adresse aux développeurs indépendants qui préparent une mise à jour et aux responsables de petites équipes confrontés à un échec de signature après renouvellement.
Il est aussi destiné aux responsables de compilation distante lorsque la signature locale fonctionne, mais pas sur le Mac distant.

Certificat expiré, certificat révoqué ou compte inactif

Un message générique de signature ne suffit pas à établir la cause. Un certificat expiré, un certificat révoqué, un profil expiré et un abonnement développeur inactif sont des états différents, avec des réparations différentes. Évitez de supprimer des identités ou de créer des certificats au hasard : vous pourriez compliquer la gestion de l’équipe sans résoudre la panne.

Apple distingue les certificats de développement et de distribution, ainsi que d’autres catégories liées à des usages spécifiques. Consultez la page du compte développeur et relevez le type, l’état et la date d’expiration du certificat concerné. Dans Xcode, examinez aussi la destination de signature sélectionnée et les détails de l’archive ou du journal de compilation. Les termes « Apple Development » et « Apple Distribution » ne désignent pas des identités interchangeables.

Vérifiez séparément le compte de l’équipe. Une adhésion arrivée à échéance peut bloquer des opérations liées au compte, même si le symptôme ressemble à un problème de certificat. Apple documente le renouvellement et l’état de l’adhésion dans sa page officielle sur le renouvellement du compte développeur. Si le statut du compte ou les droits de l’utilisateur sont en cause, arrêtez la réparation des certificats : créer une nouvelle identité ne corrige pas un accès insuffisant.

Pour éviter les diagnostics fondés sur une seule ligne d’erreur, réunissez les éléments observables : l’identité de signature demandée par la cible, l’état du certificat dans le compte, le profil sélectionné et le compte macOS exécutant la compilation. Un échec qui survient à la création de l’archive ne se traite pas nécessairement comme un rejet au moment de l’envoi.

Type de certificat et effet sur la publication

Apple Development sert à signer les versions destinées au développement et aux tests. Apple Distribution correspond à la distribution de l’app. La différence est importante : une erreur de signature de développement n’indique pas automatiquement que l’identité de publication est invalide, et l’inverse est également vrai. Avant de toucher au compte, vérifiez quelle identité le schéma de compilation et le type d’export demandent réellement.

L’expiration d’un certificat de distribution utilisé pour préparer une nouvelle version peut empêcher de signer un nouvel artefact avec ce certificat. Elle ne signifie pas, à elle seule, que la version déjà distribuée cesse immédiatement de fonctionner. Ne déduisez donc pas de l’échec d’un nouvel envoi que toutes les installations existantes sont affectées ; les conséquences dépendent de l’état et de l’usage du certificat.

La révocation mérite un diagnostic distinct. Elle ne correspond pas simplement à une date de validité dépassée : elle peut invalider l’identité concernée avant son échéance. Apple indique les effets et les précautions associés dans ses informations sur la révocation et les privilèges. Si le certificat a été révoqué, identifiez qui l’a fait et pourquoi avant d’en créer un autre. Une révocation liée à une compromission ou à un changement de droits ne doit pas être traitée comme un renouvellement ordinaire.

Pour savoir si une mise à jour peut repartir, distinguez trois questions : le compte permet-il encore les opérations de publication ? Une identité valide est-elle disponible pour signer le nouvel artefact ? Le profil autorise-t-il cette identité et l’application concernée ? Une réponse négative à l’une de ces questions suffit à faire échouer la chaîne, mais chaque réponse demande une correction différente.

Liste de décision avant toute modification

Cochez les vérifications dans l’ordre. La première condition confirmée détermine l’action à entreprendre ; ne passez à la création d’un certificat que si les contrôles précédents ne révèlent pas un problème de compte ou d’accès.

• [ ] Le compte et les droits sont valides. Si l’adhésion est inactive ou si votre rôle ne permet pas de gérer les certificats, suspendez les créations et révocations. Demandez au responsable de rétablir l’accès ou de confirmer l’état du compte ; remplacer un certificat ne corrige pas un droit manquant.
• [ ] Le certificat est expiré, et non révoqué. Si l’état indique une révocation, cherchez-en la raison et identifiez qui l’a effectuée. Ne traitez pas une révocation comme une simple expiration ; si elle est confirmée et que l’équipe autorise le remplacement, créez une identité adaptée et contrôlez ensuite le profil.
• [ ] Le certificat correspond à l’usage demandé. Si la cible réclame une identité Apple Development, ne tentez pas de réparer l’échec en sélectionnant une identité Apple Distribution, ou l’inverse. Vérifiez le mode de compilation et d’export avant de changer la signature.
• [ ] Le Mac de compilation dispose de l’identité complète. Si le certificat est valide dans le compte mais absent du trousseau du Mac, ou si sa clé privée est indisponible, corrigez la synchronisation ou l’installation de l’identité sur le compte d’exécution. Ne créez pas un certificat supplémentaire pour contourner une identité manquante.
• [ ] Le Provisioning Profile autorise le certificat choisi. Si le profil est expiré, ne correspond pas à l’identifiant de l’app ou n’autorise pas le nouveau certificat, modifiez-le ou régénérez-le, puis installez la version actualisée dans l’environnement de compilation.
• [ ] La cible sélectionne les bons éléments. Si certificat, clé privée et profil semblent valides, mais que l’archive échoue, vérifiez l’équipe, la cible, le mode de signature et le profil réellement choisis par Xcode ou par le script.
• [ ] L’échec survient bien pendant la signature. Si l’archive et l’export réussissent, mais que l’envoi échoue, conservez le certificat et le profil tant qu’aucun élément ne les met en cause. Examinez séparément l’étape d’envoi et l’état du compte.

Décision à appliquer : si le compte est bloqué, traitez le compte avant les certificats ; si l’identité est expirée, remplacez-la après confirmation de son usage ; si l’identité manque sur le Mac, réparez l’environnement ; si le profil n’autorise pas le certificat, actualisez le profil. Si aucune de ces conditions n’est confirmée et que les journaux désignent les droits ou un service Apple, arrêtez les manipulations de signature et traitez le blocage identifié.

Cette liste s’appuie sur des éléments contrôlables : état du compte, identité sélectionnée, disponibilité de la clé privée, contenu du profil et étape précise où la chaîne échoue. Elle évite de renouveler tous les actifs à l’aveugle et impose un nouveau contrôle après chaque correction.

Provisioning Profile et identité de signature

Un Provisioning Profile relie des éléments qui doivent correspondre : l’application, la signature autorisée et les capacités requises par le projet. Pour une distribution, un certificat valide ne garantit donc pas à lui seul que l’export réussira. Un ancien profil peut ne pas autoriser le nouveau certificat, être arrivé à échéance ou ne pas correspondre à l’identifiant d’application utilisé par la configuration de publication.

Commencez par relever le profil sélectionné pour la cible et le type de distribution. Vérifiez son état, son identifiant d’application, les capacités requises et le certificat autorisé. Ne remplacez pas tous les profils du compte par réflexe : les cibles de développement, de distribution et les variantes de l’application peuvent dépendre de profils distincts.

Si le profil doit être actualisé, Apple décrit les opérations de modification, de téléchargement et de suppression dans son guide de gestion des profils d’approvisionnement. La documentation explique aussi les changements qui peuvent rendre un profil obsolète dans ses informations sur les mises à jour de profil. Après modification ou régénération, récupérez la nouvelle version sur le Mac qui réalise la compilation. Mettre à jour le compte sans remplacer la copie effectivement utilisée ne répare pas la chaîne.

La gestion automatique par Xcode et la gestion manuelle dans le compte développeur ne se vérifient pas de la même manière. Si Xcode gère le profil, confirmez que la bonne équipe et la bonne cible sont sélectionnées et que l’environnement peut accéder aux ressources nécessaires. Si vous gérez les profils manuellement, vérifiez que la compilation ne pointe pas encore vers un ancien fichier ou vers un chemin conservé dans un script d’export.

La clé privée mérite un contrôle séparé. Le certificat public visible dans le compte ne suffit pas pour signer : le Mac doit disposer de l’identité associée avec sa clé privée accessible au compte qui lance Xcode ou la commande de compilation. La documentation Apple sur le partage des certificats de signature d’équipe explique comment partager ces identités au sein d’une équipe. Si l’identité est présente dans le compte mais absente du trousseau du Mac, recréer le profil ne rétablira pas la clé privée manquante.

Contrôles sur le Mac distant

Une compilation distante peut échouer alors que le poste local semble correctement configuré. Le renouvellement du certificat dans le compte ne prouve pas que la machine appelée par votre chaîne d’intégration possède la nouvelle identité. Il faut vérifier l’environnement réel : hôte distant, utilisateur macOS, trousseau consulté, version de la configuration de signature et profil chargé par la cible.

Procédez dans cet ordre :

• Relevez dans les journaux le nom de la machine et le compte d’exécution qui ont lancé la compilation. Ne partez pas du principe que la tâche utilise le Mac que vous avez ouvert en session interactive.
• Sur cette machine, vérifiez que l’identité attendue apparaît comme utilisable dans le trousseau du compte concerné. La présence du seul certificat public ne démontre pas que la clé privée est disponible.
• Contrôlez la cible, l’équipe et le mode de signature effectivement choisis par Xcode ou par la commande de compilation. Un réglage différent entre compilation locale et distante peut sélectionner une autre identité.
• Confirmez que le Provisioning Profile chargé est celui mis à jour et qu’il autorise le certificat utilisé. Vérifiez aussi son association à l’identifiant d’application et aux capacités requises.
• Relancez une archive avec la configuration de distribution visée, puis conservez les journaux et le résultat d’export. Si l’archive échoue encore, utilisez le premier message de signature exploitable pour choisir la prochaine vérification, plutôt que de renouveler à nouveau les certificats.

Si l’équipe utilise fastlane match, limitez le diagnostic à la cohérence du dépôt de certificats avec l’environnement qui compile : confirmez que l’identité attendue a été synchronisée et que le processus d’exécution peut l’utiliser. La documentation officielle de match décrit son rôle de synchronisation des certificats et profils. Ne réinitialisez pas le dépôt uniquement parce qu’un Mac distant échoue : vérifiez d’abord si la machine a récupéré les bons éléments et si une compilation en lecture seule utilise effectivement cette version.

Une autre erreur fréquente consiste à mettre à jour un trousseau interactif, puis à lancer la publication sous un compte de service différent. Dans ce cas, la session visible et le processus automatisé ne consultent pas forcément les mêmes identités. Assurez-vous que la correction a atteint le compte qui exécute l’étape de signature, et consignez ce compte dans les journaux de déploiement.

Parcours de validation avant reprise

Appliquez les contrôles dans cet ordre afin de distinguer un problème de compte d’un problème de signature :

• Établissez l’état du compte. Confirmez que l’adhésion est active et que l’utilisateur dispose des droits requis. Si l’accès ou l’adhésion bloque l’opération, arrêtez les manipulations de certificats.
• Identifiez l’identité attendue. Comparez l’usage réel — développement, distribution ou autre — avec le certificat sélectionné par la cible et par le processus d’export.
• Vérifiez l’identité complète sur le Mac de compilation. Confirmez la présence de la clé privée dans le trousseau du compte d’exécution, et non uniquement la présence d’un certificat dans le portail.
• Contrôlez le profil. Vérifiez son état, son application, ses capacités et les certificats qu’il autorise. Téléchargez la version actualisée dans l’environnement qui construit l’archive si un changement est nécessaire.
• Produisez une archive représentative. Utilisez la configuration et le type de distribution prévus pour la publication. Examinez le résultat d’archive et d’export ; un réglage qui fonctionne pour les tests ne prouve pas que l’export de distribution est prêt.
• Vérifiez l’envoi séparément. Si l’archive et l’export sont valides mais que l’envoi échoue, examinez alors l’étape d’envoi et l’état du compte. Ne modifiez pas de nouveau le certificat sans élément qui désigne la signature comme cause.

Le critère de reprise n’est pas simplement « le certificat apparaît dans le compte ». Il faut pouvoir rattacher la signature de l’archive à l’identité attendue, confirmer que le profil correspondant est utilisé et obtenir un résultat exploitable à l’étape d’envoi. Si les preuves pointent vers des droits insuffisants, une adhésion échue ou un incident de service Apple, arrêtez les révocations et créations répétées : elles n’apportent pas de preuve supplémentaire et peuvent rendre le diagnostic plus difficile.

Questions fréquentes

Un certificat Apple Distribution expiré bloque-t-il une mise à jour déjà publiée ?

L’expiration d’un certificat utilisé pour distribuer une nouvelle version ne signifie pas, à elle seule, que la version déjà publiée cesse de fonctionner. Elle peut en revanche empêcher la création ou l’envoi d’un nouvel artefact signé avec cette identité. Vérifiez la situation exacte du certificat et de votre compte, puis validez une nouvelle archive avant de relancer la publication.

Faut-il recréer le Provisioning Profile après le renouvellement du certificat de distribution ?

Vérifiez d’abord le contenu du profil. Il doit autoriser le certificat de signature choisi, correspondre à l’identifiant de l’app et inclure les capacités nécessaires. Si le nouveau certificat n’y figure pas, modifiez ou régénérez le profil, puis téléchargez-le dans l’environnement de compilation. Un profil géré par Xcode et un profil géré manuellement ne se mettent pas forcément à jour de la même façon.

Pourquoi la signature échoue-t-elle encore sur un Mac distant après le renouvellement ?

Le renouvellement dans le compte développeur ne copie pas automatiquement la clé privée vers chaque machine. La compilation distante peut encore utiliser un autre compte macOS, un trousseau différent, un ancien profil ou une autre configuration de signature. Vérifiez la machine réellement appelée, l’identité disponible dans son trousseau et le profil utilisé par la cible avant de modifier à nouveau les certificats.

Quelle différence entre l’expiration d’un certificat Apple Development et Apple Distribution ?

Apple Development sert à signer des versions destinées au développement et aux tests, tandis qu’Apple Distribution sert à distribuer une app, notamment via l’App Store. L’expiration affecte donc des opérations différentes. Identifiez l’usage de la signature qui échoue avant de renouveler quoi que ce soit, puis vérifiez séparément le profil correspondant et le statut du compte développeur.

Choix de l’environnement de publication

Un Mac local reste pertinent si vous publiez régulièrement, si vous devez brancher des appareils ou si votre charge de compilation est continue et prévisible. En revanche, l’achat et la maintenance d’une machine dédiée immobilisent un budget, son disque peut devenir un point de tension avec les archives et les simulateurs, et une chaîne distante mal documentée peut continuer à signer avec un ancien trousseau. Ces limites doivent être mises en balance avec le besoin réel : une machine réservée au build n’est pas nécessaire pour chaque projet.

Si vous avez surtout besoin d’un environnement macOS temporaire pour valider une archive ou reprendre une publication, la location d’un Mac distant peut éviter l’achat d’un poste supplémentaire, tout en donnant accès à une machine dédiée à la compilation. Vous pouvez comparer les modalités dans le guide des tarifs Mac mini M4 et consulter les options d’accès à un Mac distant. Avec MacDate, choisissez cette voie si votre objectif est un test ou une campagne de publication ponctuelle ; pour une charge soutenue ou un besoin de connexion physique à des appareils, privilégiez plutôt une machine locale maîtrisée.