# Certificat développeur iOS : provisioning profile et Expo > Le certificat prouve qui signe ton app, le provisioning profile dit quelle app et sur quels iPhone. Avec Expo, EAS crée et renouvelle les deux pour toi. Page originale : [Certificat développeur iOS : provisioning profile et Expo](https://devoria.fr/blog/certificat-provisioning-profile-ios) Auteur : [Mehdi Azizi](https://devoria.fr/mehdi-azizi) Publication : 2026-11-04 Dernière révision du contenu : 2026-11-04 Un certificat développeur iOS prouve qui a signé ton app. Le provisioning profile, ou profil d'approvisionnement, relie ce certificat à une app précise et dit où elle a le droit de tourner. **Avec Expo, tu n'as presque jamais à les fabriquer à la main : EAS les crée, les stocke et les renouvelle quand tu lances un build.** Comprendre ce que fait chaque fichier reste utile. Le jour où un build refuse de s'installer ou qu'un envoi bloque, c'est ce savoir qui te fait gagner une journée. Ce guide passe en revue les quatre éléments, leur durée de vie, les limites d'Apple et les erreurs typiques, avec la solution pour chacune. Je publie mes apps iOS avec Expo et EAS, dont Solys et TradaZen. Le parcours complet est dans [publier une app iOS sans Mac](https://devoria.fr/blog/publier-une-app-ios-sans-mac). Ici, on ouvre le capot de la signature. ## Pourquoi Apple exige une signature Une app iOS doit être signée pour s'installer sur un iPhone ou partir vers App Store Connect. La signature garantit que l'app vient d'un développeur connu d'Apple et que personne ne l'a modifiée depuis. Pour l'App Store, un détail rassure. D'après [la note technique TN3161 d'Apple](https://developer.apple.com/documentation/technotes/tn3161-inside-code-signing-certificates), l'App Store vérifie que ton certificat de distribution est valide à l'envoi, puis re-signe l'app, qui ne dépend alors plus de la date d'expiration de ton certificat. **Tes certificats doivent donc être valides au moment de l'envoi, pas pendant toute la vie de l'app.** ## Les quatre éléments à connaître [La documentation d'Expo sur les identifiants](https://docs.expo.dev/app-signing/app-credentials/) en compte trois pour iOS : le certificat de distribution, les profils et la clé de notifications push. J'ajoute l'identifiant d'app, sans lequel aucun profil n'existe. ### Le certificat de distribution C'est ta signature de développeur. [L'aide d'Apple sur les certificats](https://developer.apple.com/help/account/certificates/certificates-overview) distingue deux familles : - **Apple Development** sert à lancer ton app sur tes appareils pendant le développement. Il appartient à une personne. - **Apple Distribution** sert à distribuer sur des appareils de test désignés ou à envoyer à App Store Connect. Il appartient à l'équipe, et seuls le titulaire du compte ou un admin peuvent le créer. Le certificat de distribution ne concerne aucune app en particulier : le même signe toutes tes apps. Il va avec une clé privée, et c'est elle qui permet de signer. D'après TN3161, un certificat Apple est valable en général un an à partir de sa création. ### L'identifiant d'app (App ID) L'App ID identifie ton app dans un profil. Il reprend ton identifiant de bundle, par exemple `com.exemple.monapp` (exemple fictif). Selon [l'aide d'Apple](https://developer.apple.com/help/account/identifiers/register-an-app-id), il porte aussi la liste des capacités autorisées : notifications push, App Groups, Sign in with Apple… Avec Expo, c'est le champ `ios.bundleIdentifier` de ta configuration. **Choisis-le une fois pour toutes** : il doit être identique partout, dans ta configuration comme dans App Store Connect. L'App ID n'expire pas. Et selon [la doc Expo sur les capacités iOS](https://docs.expo.dev/build-reference/ios-capabilities/), EAS synchronise ses capacités avec ta configuration à chaque build. ### Le profil d'approvisionnement Le profil fait le lien. Il contient un App ID, un certificat et, selon son type, une liste d'appareils autorisés. Trois types te concernent : - **Développement** : ton app de test sur tes appareils enregistrés. - **Ad hoc** : un build installable sur une liste précise d'appareils, chacun identifié par son UDID. C'est la « distribution interne » d'EAS. - **App Store** : pour App Store Connect et TestFlight. Il ne contient aucune liste d'appareils, explique [la note TN3125](https://developer.apple.com/documentation/technotes/tn3125-inside-code-signing-provisioning-profiles). Chaque profil a une date d'expiration : pas plus d'un an en général selon Apple, 12 mois selon Expo. ### La clé de notifications push (APNs) La clé APNs autorise ton serveur, ou celui d'Expo, à envoyer des notifications à ton app. C'est un fichier .p8 qui ne se télécharge qu'une fois : [Apple ne le conserve pas](https://developer.apple.com/help/account/keys/create-a-private-key) dans ton compte. Une même clé sert à toutes tes apps, et [elle n'expire jamais](https://developer.apple.com/support/expiration/). ## Le tableau récapitulatif | Élément | Sert à | Durée | Qui le gère avec Expo | | -------------------------- | ------------------------- | ---------------- | --------------------- | | Certificat de distribution | Signer tes builds | Un an en général | EAS, après connexion | | App ID | Identifier ton app | Pas d'expiration | Toi, puis EAS | | Profil App Store | Envoyer à Apple | Jusqu'à 12 mois | EAS | | Profil ad hoc | Installer sur tes iPhone | Jusqu'à 12 mois | EAS et tes appareils | | Clé push APNs | Envoyer des notifications | Pas d'expiration | EAS ou toi | | Profil compte gratuit | Tester via Xcode | 7 jours | Xcode, pas EAS | « Toi, puis EAS » : tu choisis l'identifiant de bundle, EAS s'occupe des capacités. « EAS et tes appareils » : tu enregistres chaque iPhone de test, EAS fabrique le profil. La dernière ligne concerne le compte Apple gratuit : selon [l'aide d'Apple sur les comptes](https://developer.apple.com/help/account/basics/about-your-developer-account), ses profils expirent 7 jours après leur création. ## Les limites d'Apple à connaître - **Certificats de distribution** : très peu par compte. L'aide d'Apple parle d'un seul par type de distribution et par équipe, le tableau d'Expo d'une limite de 2. Retiens la règle : **ne crée pas un nouveau certificat à chaque build ou sur chaque ordinateur.** - **Clés APNs** : 2 par compte au maximum, selon Expo. - **Profils** : pas de limite, selon Expo. - **Appareils** : jusqu'à 100 par famille de produits et par année d'adhésion, d'après [l'aide d'Apple sur les appareils](https://developer.apple.com/help/account/devices/devices-overview). Désactiver un appareil ne libère pas de place. Le compteur se remet à 100 au début de l'année d'adhésion suivante, si tu retires les appareils. ## Ce qu'EAS fait pour toi D'après [la page d'Expo sur les identifiants gérés](https://docs.expo.dev/app-signing/managed-credentials/), ton premier build iOS te propose de générer ce qui manque. Tu te connectes à ton compte Apple Developer, EAS crée le certificat de distribution, le profil et la clé push, puis les stocke sur ses serveurs. Les builds suivants les réutilisent. Trois points utiles : - **Ton mot de passe Apple reste sur ta machine.** [La page sécurité d'Expo](https://docs.expo.dev/app-signing/security/) précise qu'il n'est pas envoyé à ses serveurs, et que les identifiants stockés sont chiffrés. - **`eas credentials` te montre tout** : certificat, profils, clé push. La commande permet aussi de les remplacer ou de les retirer. - **Supprimer dans EAS ne supprime pas chez Apple.** Pour libérer une place, il faut révoquer dans le portail Apple. Tu peux aussi garder la main avec les identifiants locaux : un fichier `credentials.json` pointe vers ton certificat (.p12) et ton profil (.mobileprovision). Expo demande d'ajouter ces fichiers au `.gitignore`. C'est la même règle que pour [les clés API d'une app Expo](https://devoria.fr/blog/cle-api-secrete-app-expo) : un secret ne part jamais dans le dépôt. ## Les erreurs typiques et comment les résoudre ### Profil expiré Un build ad hoc embarque son profil : à son expiration, l'app ne s'ouvre plus sur tes iPhone de test. Sur l'App Store, en revanche, Expo confirme que l'expiration n'a aucun effet sur l'app en production. **La solution : relance un build.** EAS génère un nouveau profil, ou tu le fais toi-même avec `eas credentials`. Réinstalle ensuite le nouveau build sur tes appareils. Ne confonds pas avec TestFlight : un build TestFlight expire après 90 jours, quel que soit ton certificat. Le détail est dans [TestFlight pour tester ton app iPhone](https://devoria.fr/blog/testflight-tester-son-app-iphone). ### Certificat expiré ou révoqué Apple est clair : si ton adhésion est valide, tes apps déjà sur l'App Store ne sont pas touchées. En revanche, tu ne peux plus envoyer de build signé avec ce certificat. Un build envoyé mais pas encore soumis peut être marqué Invalid Binary si son certificat a été révoqué. Et [les profils qui contiennent un certificat révoqué deviennent invalides](https://developer.apple.com/help/account/certificates/revoke-a-certificate). **La solution : crée un nouveau certificat depuis `eas credentials` ou au prochain build**, puis laisse EAS refaire les profils. Et ne révoque jamais par réflexe un certificat qui fonctionne. ### Appareil absent du profil ad hoc Le lien d'installation fonctionne chez toi, mais pas sur l'iPhone d'un testeur. Cause : [la doc Expo sur la distribution interne](https://docs.expo.dev/build/internal-distribution/) explique que seuls les appareils présents dans le profil au moment du build peuvent installer l'app. La solution : 1. Enregistre l'appareil avec `eas device:create`. 2. Relance un build en mode interactif, connecté à ton compte Apple, pour qu'EAS mette le profil à jour. Ou re-signe le build existant avec `eas build:resign`, sans tout recompiler. 3. En intégration continue, le mode non interactif réutilise le profil sans mettre sa liste à jour. Ajoute l'option `--refresh-ad-hoc-provisioning-profile`. Sur un compte neuf ou tout juste renouvelé, Apple peut mettre 24 à 72 heures à traiter un nouvel appareil. Le premier build qui l'inclut peut donc échouer : attends, puis relance. ### Limite de certificats atteinte Apple refuse de créer un nouveau certificat de distribution. Souvent, d'anciens certificats traînent : créés depuis Xcode sur un autre Mac ou par un autre service de build. **Réutilise le certificat existant si tu as son fichier .p12. Sinon, révoque celui qui ne sert plus** dans le portail Apple. Une révocation n'affecte pas tes apps déjà en ligne, mais elle invalide les profils qui le contenaient. ### « Provisioning profile doesn't include signing certificate » Ce message de Xcode veut dire que le profil ne contient pas le certificat dont la clé privée est sur ta machine. Cause typique : mélanger la signature automatique de Xcode et les identifiants d'EAS. **Choisis une seule source de vérité** : builds EAS avec identifiants gérés, ou identifiants locaux, mais pas les deux. ### Notifications coupées après une révocation de clé Si tu révoques ta clé APNs, Expo prévient que toutes les apps qui l'utilisent ne reçoivent plus de notifications. Crée une nouvelle clé et envoie-la avec `eas credentials`. Les jetons Expo Push de tes utilisateurs ne changent pas. ### Capacité ajoutée, profil invalide Activer un service comme les notifications push ou App Groups [rend le profil invalide](https://developer.apple.com/help/account/provisioning-profiles/edit-download-or-delete-profiles) : il faut le régénérer. Avec EAS, la synchronisation des capacités se fait à chaque build. Si le profil reste refusé, `eas credentials` permet d'en générer un nouveau. ## La suite après la signature Un build signé n'est qu'une étape. La fiche, les captures, la confidentialité et l'envoi en revue sont réunis dans [publier une application sur l'App Store](https://devoria.fr/expertise/publier-une-application-sur-app-store). Si tu n'as pas encore ton adhésion, commence par [le compte développeur Apple](https://devoria.fr/blog/compte-developpeur-apple-prix-inscription). Et pour comprendre pourquoi je conseille Expo aux débutants, lis [React Native et Expo pour une app mobile](https://devoria.fr/expertise/application-mobile-react-native-expo). ## Si tu prépares ta première publication Avant ton premier envoi, fais le [diagnostic gratuit](https://devoria.fr/diagnostic) : il te dit ce qui bloque vraiment dans ton projet et t'envoie ma checklist anti-refus Apple. Pour construire l'app, brancher les abonnements et la publier sans te battre avec la signature, le [Kit iOS](https://devoria.fr/kits/ios) suit le parcours en quatre étapes avec le code de départ de mes apps, à ton rythme. ## Questions fréquentes ### Qu'est-ce qu'un provisioning profile ? C'est le fichier qui autorise ton app à tourner ou à partir chez Apple. Il relie un identifiant d'app, un certificat et, selon son type, une liste d'appareils. Un profil App Store ne contient aucun appareil, un profil ad hoc en liste quelques-uns. ### Le certificat développeur iOS est-il gratuit ? Il n'a pas de prix à part : le certificat de distribution est inclus dans l'Apple Developer Program, à 99 $ par an. Avec un compte Apple gratuit, Xcode te laisse tester sur 3 appareils au plus, mais les profils expirent au bout de 7 jours et la publication est impossible. ### Combien de temps dure un certificat de distribution Apple ? En général un an à partir de sa création, selon Apple. Les profils d'approvisionnement durent aussi 12 mois au plus. La clé de notifications push, elle, n'expire jamais. ### Que se passe-t-il si mon certificat de distribution expire ? Rien pour tes apps déjà sur l'App Store, tant que ton adhésion est valide. Tu ne peux simplement plus envoyer de nouveau build signé avec ce certificat. Avec EAS, un nouveau certificat se crée au prochain build ou avec `eas credentials`. ### Faut-il un Mac pour créer un certificat iOS ? Non, si tu passes par EAS. Tu te connectes à ton compte Apple depuis la ligne de commande, et EAS génère le certificat et le profil, sous Windows comme sous Linux. Sans EAS, la méthode classique passe par Xcode ou le trousseau d'accès d'un Mac. ### Combien d'appareils peut contenir un profil ad hoc ? Ton compte peut enregistrer jusqu'à 100 iPhone par année d'adhésion, et autant pour chaque autre famille d'appareils. Un appareil désactivé compte toujours. Pour tester avec plus de monde, passe par TestFlight. ## Ton projet [Kit Review](https://devoria.fr/kits/review-apple) : Tout ce que je vérifie avant d'envoyer une app à Apple, la même vérification pour Google Play, et trois skills qui font la relecture avec Claude Code. 49 €, paiement unique. Inclus : La checklist avant l'envoi ; Les refus que j'ai pris, et ce que j'ai corrigé ; Les notes pour le testeur ; Les skills de vérification. Prérequis : une app iPhone ou Android presque prête, et Claude Code ou Cursor. Téléchargement immédiat après le paiement. [Kit iOS & Android Devoria](https://devoria.fr/kits/ios) : Le code de départ de mes apps, le parcours jusqu'à l'App Store et Google Play avec les messages à donner à Claude, et tous les kits. Claude part d'une app qui tourne déjà. 99 €, paiement unique. Inclus : Le code de départ de ton app ; Les styles visuels ; Le parcours pas à pas ; Kit Review ; Kit Captures ; Kit ASO ; Mises à jour à vie ; Bonus : la séance 1:1 à moitié prix. Prérequis : pour l'iPhone, un Mac avec Xcode 26 ou plus et un compte Apple Developer (99 $ par an) pour publier. Pour Android, Android Studio sur un Mac, un PC Windows ou Linux, et un compte Google Play Console (25 $, une fois). Et Claude Code (abonnement payant) ou Cursor. Téléchargement immédiat après le paiement. [Diagnostic gratuit](https://devoria.fr/diagnostic) : quelques questions sur ton projet. Il dit ce qui te bloque vraiment, l'ordre des quatre étapes et le kit qui correspond. En laissant ton e-mail, tu reçois la checklist anti-refus Apple : les points vérifiés avant chaque envoi, tirés des refus reçus par les apps du studio. [Une heure avec moi](https://devoria.fr/coaching) : On regarde ton app ou ton projet Claude, écran partagé : ce qui bloque, ce que je change en premier, et dans quel ordre. 100 € la séance d'une heure, en visio, paiement en une fois. Sujets : L'audit de ton app ; Ton travail avec Claude ; Ta fiche et ton paywall ; Un refus d'Apple.