App Store Connect Missing Compliance : remplir l’export chiffré en 2026 ?

Symptôme — la construction est téléversée, mais TestFlight affiche « Missing Compliance » et bloque la distribution aux testeurs.

Solution la plus rapide — ne choisissez ni « aucune cryptographie » par réflexe ni un dossier réglementaire complexe sans vérification. Inventoriez le chiffrement présent dans le binaire complet : les API Apple, votre code, les bibliothèques liées et les SDK tiers. Les capacités cryptographiques fournies par le système Apple relèvent généralement d’un traitement exempt ; un algorithme standard intégré hors du système ou un protocole non standard exige une analyse dans le questionnaire App Store Connect et peut nécessiter des documents. Une fois l’exemption confirmée, configurez ITSAppUsesNonExemptEncryption dans l’Info.plist de la construction finale.

Cette page s’adresse à vous si vous avez envoyé une construction iOS ou macOS dans TestFlight et ne pouvez plus poursuivre sa distribution. Elle concerne aussi les mainteneurs qui utilisent HTTPS, Keychain, un SDK de connexion ou de paiement, ainsi que les petites équipes qui téléversent régulièrement depuis un Mac distant ou une chaîne d’intégration continue.

SECTION 01Pourquoi Missing Compliance ne signifie-t-il pas que la construction est invalide ?

« Missing Compliance » indique que les informations d’exportation liées à la construction ne sont pas encore fournies ou associées. Ce statut ne doit pas être confondu avec « Invalid Binary », un échec de signature, une erreur d’upload ou un traitement encore en cours. Apple distingue ces états dans sa documentation des statuts de construction App Store Connect.

Le point souvent oublié est l’objet réellement examiné : ce n’est pas seulement votre code source. La déclaration concerne la construction téléversée, donc l’ensemble formé par :

• votre code et vos propres protocoles ;
• les appels aux frameworks et services du système Apple ;
• les bibliothèques statiques ou dynamiques embarquées ;
• les SDK de connexion, paiement, analytique, synchronisation ou stockage sécurisé ;
• les fonctions réellement activées dans la version distribuée.

Un projet peut donc sembler dépourvu de cryptographie dans ses fichiers Swift ou Objective-C tout en embarquant une implémentation cryptographique dans une dépendance. À l’inverse, l’emploi de HTTPS pour communiquer avec une API ne suffit pas, à lui seul, à conclure que vous devez fournir un dossier complexe.

Le bon diagnostic commence par la source du chiffrement, pas par le message affiché dans l’interface.

SECTION 02Première vérification : quelles capacités cryptographiques sont réellement dans l’archive ?

Cas des API Apple uniquement

Une application utilitaire qui utilise les mécanismes réseau du système pour HTTPS, Keychain pour protéger des secrets ou d’autres capacités de sécurité fournies par Apple se situe souvent dans le scénario exempt. Cela peut concerner une application de notes, un outil professionnel, une application audio qui synchronise des projets, ou un logiciel de design qui récupère ses ressources depuis un serveur sécurisé.

« Souvent » ne signifie pas « automatiquement ». Vous devez confirmer que votre application n’ajoute pas une implémentation externe, même si elle n’appelle pas directement une fonction nommée « encrypt ». Vérifiez notamment les dépendances transitives, les frameworks précompilés et les options de compilation propres à une version de production.

Pour une revue interne, conservez :

• la liste des dépendances et leur version utilisée dans l’archive ;
• la description fonctionnelle de chaque flux sécurisé ;
• l’identification des API Apple employées ;
• la documentation du fournisseur lorsqu’un SDK est impliqué ;
• une capture anonymisée des réponses données dans App Store Connect ;
• le numéro interne de la construction et le résultat de la vérification de l’archive.

Ces éléments ne remplacent pas une décision réglementaire, mais ils rendent votre réponse reproductible lorsqu’une nouvelle construction réapparaît dans la file de conformité.

Cas d’un SDK de connexion ou de paiement

Un SDK de connexion peut protéger une session HTTPS sans embarquer lui-même un algorithme distinct ; un autre peut inclure une bibliothèque de chiffrement, une couche de transport propriétaire ou une fonction de stockage sécurisé. Même constat pour les paiements : le fait que l’utilisateur ne voie qu’un écran de paiement ne décrit pas l’implémentation présente dans votre binaire.

Demandez au fournisseur :

• quelles bibliothèques sont intégrées ;
• si l’algorithme est fourni par le système ou inclus dans le SDK ;
• quelles fonctions sont activées dans votre configuration ;
• si une documentation d’exportation ou une classification existe ;
• dans quelles régions la fonctionnalité est distribuée.

Ne classez donc pas tous les SDK de connexion et de paiement dans la même catégorie. Le questionnaire doit refléter l’implémentation effective, les fonctions activées et votre distribution. Apple rappelle dans sa vue d’ensemble de la conformité à l’exportation que la réponse dépend de l’usage de la cryptographie dans l’application, et non d’un simple libellé marketing.

SECTION 03Quelle réponse selon la source du chiffrement ?

Le tableau suivant sert à choisir la prochaine vérification. Il ne constitue pas un avis juridique et ne transforme pas une hypothèse sur un SDK en exemption confirmée.

Pourquoi un algorithme standard tiers demande-t-il plus de vérifications ?

Un algorithme standard intégré dans une bibliothèque externe n’est pas nécessairement équivalent à l’utilisation d’une API cryptographique Apple. Le fournisseur peut avoir inclus son propre moteur, plusieurs modes de fonctionnement ou une fonction qui n’est pas active dans votre code actuel mais reste présente dans le binaire.

Vous devez alors comparer la documentation du SDK, sa composition binaire et la configuration livrée. Le questionnaire App Store Connect sert à déclarer les caractéristiques pertinentes de votre application ; il ne remplace pas les obligations qui peuvent dépendre du pays d’exportation, de la fonction du logiciel ou de sa classification.

Les ressources de l’administration américaine chargée des contrôles à l’exportation expliquent les questions générales liées aux produits de chiffrement, mais elles ne classent pas automatiquement votre application à votre place. Pour une distribution en France, une analyse distincte peut également être nécessaire : consultez les informations du service français chargé de la réglementation de la cryptographie. Ne présentez pas cet article comme une garantie juridique valable pour toutes les régions.

Cas d’un protocole non standard ou d’une application de sécurité

Un protocole conçu par votre équipe, un algorithme qui n’est pas adopté par un organisme de normalisation reconnu, ou une application principalement destinée à sécuriser des communications ou du stockage justifie une prudence accrue.

Dans ce cas, préparez une description de l’algorithme, de la fonction proposée, des données protégées, des utilisateurs concernés et des régions de distribution. Une classification de type CCATS, une déclaration française ou une autre formalité ne répond pas au même objectif qu’une réponse dans App Store Connect. Le premier ensemble concerne une procédure réglementaire ; le second décrit la conformité de la construction et son association dans le circuit de distribution.

Si l’enjeu commercial est important, faites relire le dossier par un professionnel connaissant les contrôles d’exportation. Modifier ITSAppUsesNonExemptEncryption pour faire disparaître un écran ne règle pas un problème de fond et peut rendre votre historique de conformité difficile à défendre.

SECTION 04Comment répondre dans TestFlight et dans l’Info.plist ?

Dans App Store Connect, ouvrez la fiche de la construction concernée puis recherchez l’action permettant de fournir les informations de conformité à l’exportation. Apple décrit ce parcours pour les versions bêta dans son guide de traitement de la conformité des constructions TestFlight.

Selon votre situation, vous pourrez :

• répondre au questionnaire associé à la construction ;
• fournir les informations demandées sur l’usage du chiffrement ;
• associer une approbation ou un document déjà accepté, lorsque le parcours le permet ;
• attendre le traitement avant de considérer la construction comme distribuable.

Le statut visible dans l’interface doit être contrôlé après l’enregistrement, et non immédiatement après l’envoi de la réponse. Pour éviter de confondre « réponse enregistrée » et « construction disponible », vérifiez ensuite la page de la construction et l’accès depuis le groupe de test.

ITSAppUsesNonExemptEncryption doit-il être défini sur YES ou NO ?

La clé ITSAppUsesNonExemptEncryption décrit si l’application utilise un chiffrement qui n’entre pas dans les exemptions déclarées. La documentation Apple de cette clé doit rester votre référence pour la sémantique exacte et la version de l’outil utilisée.

En pratique :

• NO indique que vous avez déterminé que l’application n’utilise pas de chiffrement non exempt ;
• YES indique qu’un tel chiffrement est présent ou doit être traité comme tel ;
• une clé absente ne prouve pas l’absence de chiffrement et peut conduire à une nouvelle demande dans App Store Connect.

Ne choisissez donc pas NO uniquement parce que votre application utilise HTTPS. Choisissez cette valeur après l’inventaire du binaire complet et la confirmation que le scénario relève bien d’une exemption. Si Apple ou votre classification vous attribue un code d’approbation, le champ ITSEncryptionExportComplianceCode peut être utilisé dans le flux prévu pour associer ce code à la construction. Conservez la preuve de son origine, mais ne l’insérez jamais dans un journal public.

Voici le second outil de décision à utiliser avant un nouvel envoi :

Le contrôle doit porter sur l’archive finale, pas seulement sur le panneau de réglages du projet. Une configuration modifiée après la création de l’archive n’a aucun effet rétroactif sur le binaire déjà téléversé. Apple fournit également ses consignes pour téléverser une construction ; utilisez-les pour confirmer que c’est bien le nouvel artefact qui apparaît dans App Store Connect.

SECTION 05TestFlight et la résolution de Missing Compliance

Ne supposez pas qu’une construction affichant Missing Compliance sera installable par tous les testeurs. Tant que les informations d’exportation ne sont pas fournies ou validées, la distribution peut rester bloquée ou limitée par l’état de la construction. Contrôlez la disponibilité depuis le groupe de test concerné après la résolution, plutôt que de vous fier uniquement à la réussite du téléversement.

Une séquence fiable consiste à :

• relever l’identifiant anonymisé de la construction et son état initial ;
• répondre au questionnaire ou associer le document demandé ;
• attendre la mise à jour de l’état dans App Store Connect ;
• vérifier l’accès avec un compte de test autorisé ;
• confirmer que la version installée correspond à la nouvelle construction.

Si la construction est destinée à une application audio ou vidéo, testez aussi le flux qui active réellement la synchronisation, le téléchargement ou la protection des médias. Pour une application de design, contrôlez les bibliothèques de rendu et de stockage qui peuvent différer entre la version de développement et la version distribuée.

SECTION 06Intégration du contrôle dans un Mac distant de publication

Un Mac distant est utile pour exécuter Xcode, créer l’archive et automatiser l’envoi, mais il ne transforme pas une décision réglementaire en simple étape technique. Votre procédure doit séparer la vérification de conformité, la signature, l’envoi et l’activation TestFlight.

Avant chaque publication, appliquez cette séquence :

• comparez la liste des dépendances de la version avec celle qui a été analysée ;
• inspectez l’Info.plist réellement inclus dans l’archive ;
• contrôlez la valeur de ITSAppUsesNonExemptEncryption et, si nécessaire, le code d’approbation ;
• examinez le journal d’upload sans exposer de secrets ;
• vérifiez le statut de la construction dans App Store Connect ;
• confirmez la disponibilité dans le groupe TestFlight ;
• répétez avec une nouvelle construction lorsque le fichier a été modifié.

Vous pouvez classer le résultat dans trois catégories opérationnelles :

• Questionnaire suffisant : la réponse est enregistrée et la construction devient disponible ;
• Configuration à stabiliser : la réponse est correcte, mais le projet doit intégrer la clé afin d’éviter une demande répétée sur les prochaines constructions ;
• Dossier en attente : une classification, une déclaration ou une validation est nécessaire avant de poursuivre la distribution.

Sur une machine accessible à distance, ne laissez pas apparaître dans les captures ou les journaux le compte Apple, le Bundle ID complet, une clé d’API, un code d’approbation, un certificat ou le nom privé d’un SDK. Utilisez des valeurs masquées avant de partager un rapport avec un prestataire ou un collaborateur.

Si votre chaîne de publication nécessite un Mac disponible sans achat immédiat de matériel, vous pouvez comparer les options dans la page des formules Mac de MACNOX. Pour une mission ponctuelle de validation d’archive et de distribution, la commande d’un environnement Mac distant MACNOX peut également être examinée, à condition de vérifier auparavant les exigences d’accès, les secrets et les responsabilités de votre équipe.

SECTION 07Choisir entre votre environnement actuel et un Mac distant

Un poste Windows ou Linux peut très bien conserver le code, lancer les tests non spécifiques à Apple et préparer les artefacts. En revanche, il ne remplace pas une session macOS pour Xcode, l’archivage final et le contrôle de la distribution iOS. Une machine locale dédiée peut convenir si vous avez besoin d’une charge lourde permanente, d’interfaces physiques ou d’un accès matériel particulier.

L’environnement actuel devient moins adapté lorsque vous devez partager un Mac de bureau entre plusieurs tâches, conserver une machine allumée pour chaque envoi, ou reproduire exactement une archive après une modification de conformité. Il ajoute aussi des risques concrets : dépendances différentes selon le poste, certificats copiés sans séparation, journaux contenant des secrets et impossibilité de reprendre rapidement après un incident local.

Un Mac distant ne supprime pas ces risques ; il les rend contrôlables si vous imposez une procédure d’accès, une rotation des secrets et une vérification de l’archive. Après avoir fixé vos réponses App Store Connect et votre configuration Info.plist, utilisez-le pour rejouer une publication complète : archive, téléversement, traitement de la conformité et disponibilité TestFlight. Cette validation réelle est plus fiable qu’une simple capture du réglage dans Xcode.

SECTION 08Pour aller plus loin

• Automatiser l’archive, la signature et l’envoi d’une application iOS
• Valider une chaîne de publication iOS : archive, certificats et retour arrière
• Séparer compilation, signature et publication dans une CI iOS