Expiration du certificat Developer ID : comment migrer le Mac CI ? 2026

À retenir : vérifiez la sous-autorité avant de remplacer vos certificats

Apple a annoncé le 1 octobre 2026 que l’ancienne autorité Developer ID Certification Authority arrivera à expiration le 1 février 2027. Les paquets pkg signés avec les certificats concernés ne pourront alors plus être installés ; les logiciels macOS déjà notariés et munis d’un horodatage sécurisé continueront, eux, de fonctionner (annonce d’Apple sur l’expiration de l’ancienne sous-autorité). Pour préparer la migration du Mac CI, commencez par vérifier l’autorité émettrice des certificats Developer ID Application et Developer ID Installer, puis obtenez les remplaçants G2, validez-les sur un environnement isolé et basculez les tâches par étapes.

Cette procédure s’adresse aux responsables de publication qui signent des applications ou des paquets macOS et doivent établir le périmètre des certificats concernés.
Elle concerne aussi les responsables IT et plateforme chargés des nœuds Mac CI, ainsi que les personnes qui administrent les certificats et clés privées du compte Apple Developer.

Dernière mise à jour : 4 octobre 2026. Les dates et limites indiquées ici ont été vérifiées à partir de l’annonce Apple et du guide de remplacement des certificats Developer ID. Consultez ces pages avant le changement en production pour vérifier si les instructions ont évolué.

Première étape : dresser l’inventaire des identités et des tâches de signature

Une migration fiable commence par les références réellement utilisées dans les chaînes de publication, et non par la liste des certificats visibles dans un seul compte. Un certificat peut être installé dans le trousseau d’un nœud, référencé par un script, puis chargé par le compte de service qui exécute les travaux. Il faut donc rapprocher les certificats du système, des tâches de CI et des produits livrés.

Constituez un registre pour chaque nœud Mac CI, qu’il soit dédié à la production, aux validations ou aux travaux ponctuels. Pour chaque entrée, consignez :

• le type de certificat : Developer ID Application ou Developer ID Installer ;
• l’équipe Apple Developer à laquelle il est associé et les informations du certificat qui établissent son origine ;
• le nom du travail de CI, du dépôt ou du processus qui le sélectionne ;
• le produit signé : application, mise à jour ou paquet d’installation pkg ;
• le trousseau concerné, son emplacement et le compte de service autorisé à accéder à l’identité ;
• les étapes qui interviennent après la signature : notarisation, vérification du ticket, distribution ou installation de contrôle.

La distinction entre certificats est opérationnelle. Developer ID Application sert à signer une application Mac distribuée en dehors de l’App Store. Developer ID Installer sert à signer un paquet d’installation. Apple distingue ces usages dans sa présentation des types de certificats et dans sa documentation de création des certificats Developer ID. Ils ne sont pas interchangeables dans un script simplement parce que les deux identités apparaissent dans un même trousseau.

Pour éviter qu’un inventaire ne reste théorique, comparez le registre aux journaux de construction et aux paramètres réels des travaux. Un certificat inutilisé sur un nœud peut encore être sélectionné par un ancien script ; inversement, une identité annoncée comme active par une équipe peut ne jamais être accessible au compte qui exécute la CI.

Un nom affiché dans le trousseau ou une date d’expiration du certificat ne suffit pas à établir que celui-ci dépend de l’ancienne sous-autorité. La preuve à conserver est l’information d’autorité émettrice, rapprochée du certificat et du compte Apple Developer.

Deuxième étape : déterminer quels produits sont réellement concernés

Comment reconnaître un certificat issu de l’ancienne sous-autorité ?

Ouvrez les détails du certificat et vérifiez l’autorité qui l’a émis, puis confrontez cette information à la méthode de reconnaissance indiquée par Apple. La date d’expiration et le libellé de l’identité constituent des éléments de suivi, mais ne remplacent pas cette vérification. Le guide Apple de remplacement des certificats explique comment identifier les certificats relevant de l’ancienne autorité et obtenir les nouveaux certificats associés à G2.

Faites cette vérification séparément pour Developer ID Application et Developer ID Installer. Conservez les détails utiles dans un dossier de changement accessible aux personnes qui gèrent les publications : identité concernée, autorité émettrice, trousseau, tâches liées et résultats de contrôle. Si l’autorité ne peut pas être confirmée, classez le certificat comme « à vérifier » et bloquez toute conclusion fondée uniquement sur son nom.

Que deviennent une application notariée et un paquet déjà signé ?

Les conséquences dépendent du type de produit et de son état de publication. Selon Apple, une application Mac déjà notariée et munie d’un horodatage sécurisé continuera à fonctionner après l’échéance annoncée. Cette continuité concerne l’application déjà distribuée ; elle ne dispense pas de préparer les futures mises à jour avec le nouveau certificat et l’horodatage sécurisé requis (annonce Apple sur les logiciels déjà notariés et les prochaines mises à jour).

La situation est différente pour un paquet pkg signé avec un certificat Developer ID Installer concerné : Apple indique qu’après le 1 février 2027, ce paquet ne pourra plus être installé. Ne transposez donc pas la règle applicable aux applications déjà notariées aux installateurs. Pour établir le risque, reliez chaque certificat Installer aux paquets encore distribués, aux dépôts d’artefacts, aux procédures de réinstallation et aux systèmes qui pourraient conserver une ancienne version.

Une conséquence pratique est souvent négligée : remplacer l’identité de signature dans le travail de construction ne modifie pas automatiquement les paquets déjà stockés ou publiés. Si une équipe doit continuer à proposer une ancienne version, elle doit examiner explicitement ce paquet et son parcours d’installation, plutôt que de considérer que la seule mise à jour de la CI a corrigé tous les artefacts.

Troisième étape : préparer les remplaçants sans exposer les clés privées

Suivez la procédure Apple correspondant au type de certificat à remplacer. Le remplaçant doit correspondre à l’usage prévu : Developer ID Application pour les applications, Developer ID Installer pour les paquets. Avant toute demande, vérifiez les conditions de rôle dans le compte, les exigences des outils employés et les règles en vigueur concernant les certificats ; ces informations peuvent dépendre de l’état du compte et des consignes Apple. Le guide de remplacement doit faire foi pour le parcours applicable au moment de l’opération.

Pendant la préparation, distinguez clairement les objets souvent confondus :

• Le certificat associe une identité de signature à une clé publique et à des informations d’émission.
• La clé privée permet de produire la signature et doit rester protégée selon les règles de gestion des secrets de l’entreprise.
• La signature atteste l’identité associée au logiciel ; elle ne remplace pas la notarisation.
• La notarisation correspond au contrôle du logiciel soumis à Apple et à l’émission d’un ticket.
• L’horodatage sécurisé établit le moment de la signature et participe aux conditions de validation du logiciel après l’échéance.

Générez et conservez la clé privée selon les procédures déjà approuvées par l’organisation. L’accès doit être accordé aux seuls comptes et opérateurs qui en ont besoin pour le travail de signature. Un export de trousseau copié sur plusieurs nœuds pour accélérer la migration peut élargir inutilement le périmètre d’exposition ; préférez un transfert contrôlé, documenté et conforme aux pratiques de gestion des justificatifs de l’entreprise.

Au moment d’installer le remplaçant, vérifiez que l’identité complète est disponible dans le trousseau utilisé par le processus de CI, pas seulement dans une session graphique ouverte par un administrateur. Un test réalisé dans une session interactive ne prouve pas que le compte de service peut signer. Comparez le certificat installé avec celui prévu dans le registre, puis consignez l’identité sélectionnée et le résultat obtenu.

Quatrième étape : valider en parallèle sur un Mac CI isolé

N’écrasez pas d’emblée le certificat de production. Préparez un nœud isolé ou une tâche de CI non bloquante qui reproduit les conditions de la chaîne de publication : même compte de service, mêmes scripts de signature, même accès au trousseau et mêmes étapes de notarisation ou d’installation. L’objectif est de vérifier le trajet réellement emprunté par les versions destinées aux utilisateurs, et non de réussir une commande lancée manuellement avec des droits différents.

Exécutez des validations distinctes pour l’application et pour le paquet d’installation.

Pour l’application, signez un artefact représentatif avec Developer ID Application, contrôlez la signature, soumettez le logiciel à la notarisation et vérifiez le parcours de distribution retenu. Apple recommande de préparer le logiciel en amont de la notarisation et documente les points à contrôler dans son guide de notarisation des logiciels macOS avant distribution. Conservez les journaux de construction, le résultat de la soumission et la preuve que l’artefact validé correspond bien au candidat publié.

Pour le paquet, signez un pkg avec Developer ID Installer, puis vérifiez sa signature et son installation dans un environnement de test adapté. Un paquet qui se construit sans erreur n’a pas encore démontré que le programme d’installation fonctionne correctement sur le système cible. Si la notarisation est prévue dans votre processus de publication, vérifiez aussi cette étape et le résultat final. En cas d’échec, utilisez les indications Apple sur les problèmes courants de notarisation avant d’attribuer le problème au certificat.

Les quatre intentions de validation doivent figurer dans le compte rendu : reconnaître l’autorité d’émission, établir le traitement des paquets déjà signés, confirmer la continuité des applications existantes et démontrer que la CI peut signer puis publier avec les nouveaux certificats. Une exécution réussie isolée ne vaut pas autorisation de production si les journaux, l’identité utilisée ou le résultat d’installation ne sont pas vérifiables.

Cinquième étape : basculer les travaux par vagues et définir le repli

Avant la bascule, associez chaque travail touché à un responsable, à une fenêtre de changement et à une preuve de validation. Commencez par les travaux non critiques qui reproduisent fidèlement le chemin de signature ; passez ensuite aux tâches de production selon les règles de changement de l’entreprise. Lorsqu’une chaîne signe à la fois une application et un installateur, traitez les deux identités et les deux sorties comme des contrôles distincts.

Le retour arrière doit restaurer un état de pipeline maîtrisé, et non dépendre de la poursuite de signatures avec un certificat qui ne fonctionne plus. Définissez à l’avance quelles tâches peuvent être suspendues, comment conserver les artefacts déjà validés et qui peut autoriser la reprise. Si un problème apparaît, la reprise peut consister à revenir au travail de CI précédent tout en maintenant la publication en attente ; elle ne doit pas conduire à distribuer un produit dont la signature ou l’installation n’a pas été contrôlée.

Décider si la vague peut avancer

• Si l’autorité émettrice du certificat est confirmée et le remplaçant G2 correspond au même usage, passez à la validation isolée ; sinon, gardez le travail en attente et complétez l’inventaire.
• Si le compte réel de CI accède à la bonne identité et que les journaux permettent de vérifier la signature, autorisez la validation de l’artefact ; sinon, corrigez l’accès au trousseau avant la bascule.
• Si l’application suit le parcours de signature et de notarisation attendu, validez séparément sa distribution ; ne déduisez pas le succès d’un pkg de ce résultat.
• Si le paquet s’installe correctement dans le test prévu et que son identité Installer est tracée, examinez le lot suivant ; sinon, bloquez sa publication et conservez les éléments de diagnostic.
• Si les responsables, les preuves et le repli sont consignés, ouvrez la vague de production ; sinon, maintenez la CI en parallèle jusqu’à ce que les conditions manquantes soient satisfaites.

Sixième étape : prononcer l’admission de publication avec des preuves traçables

La décision finale doit être vérifiable par une autre personne que celle qui a effectué le changement. Réunissez le registre des certificats, les informations d’autorité émettrice, les associations entre certificats et travaux, les résultats de signature, les preuves de notarisation pertinentes et les essais d’installation. Ajoutez les autorisations d’accès au trousseau et les références du changement de production. Cette documentation permet de différencier un certificat simplement créé d’un certificat effectivement utilisé et validé dans le processus de livraison.

Le contrôle des anciens artefacts doit rester dans le dossier de migration. Les applications déjà notariées avec horodatage sécurisé bénéficient de la continuité décrite par Apple ; les paquets concernés, eux, exigent une analyse particulière au regard de leur installation après l’échéance. L’équipe doit donc consigner le sort des versions archivées, des installateurs encore proposés au téléchargement et des mécanismes de réinstallation, sans confondre ces cas avec les nouveaux builds.

Cette migration concerne un changement d’autorité et de chaîne de publication, pas seulement le renouvellement d’une entrée dans un trousseau. Si les travaux de signature sont répartis sur des Mac partagés, les accès communs, la visibilité des clés privées et la difficulté à attribuer une exécution à un opérateur peuvent compliquer l’audit. Un Mac dédié peut apporter une frontière opérationnelle plus lisible, mais il implique aussi la gestion du matériel, des mises à jour, de la disponibilité et des accès ; un environnement distant peut éviter certains achats initiaux, sans dispenser de vérifier l’isolation, les droits, le mode de remise des accès et les preuves réellement fournies.

Une fois le périmètre et les exigences établis, les équipes qui envisagent un environnement Mac distant peuvent consulter les tarifs de RUVCLOUD puis examiner les options de commande RUVCLOUD. Ces pages doivent être vérifiées pour les modalités et capacités effectivement proposées avant toute décision : aucune configuration, garantie d’isolation ni condition de livraison ne doit être supposée à partir de ce guide. Pour une équipe qui a déjà des Mac administrés et des charges stables, conserver son infrastructure peut rester plus pertinent ; pour un besoin temporaire de validation ou un environnement supplémentaire, la location d’un Mac ne mérite d’être retenue qu’après examen des exigences de contrôle et de sécurité.