ITSAppUsesNonExemptEncryption : en avez-vous besoin, et quelle valeur mettre ?

Chaque build iOS tombe sur une question de contrôle des exportations américain, et rien dans Xcode ne vous prévient qu'elle arrive. Elle apparaît sous la forme d'un statut « Missing Compliance » qui bloque TestFlight et fige votre soumission. Cette page répond aux deux seules questions qui comptent : en avez-vous seulement besoin, et quelle valeur fait cesser la question à chaque build.

Dernière vérification le 24 juillet 2026.

Ce que demande réellement App Store Connect

Les apps distribuées via l'App Store sont juridiquement « exportées » depuis les États-Unis : elles relèvent donc des Export Administration Regulations (EAR). Quand votre build utilise du chiffrement, App Store Connect doit savoir s'il s'agit du type ordinaire (exempté) ou de celui qui demande des formalités (non exempté). C'est tout le sens de la question.

Le piège : presque toutes les apps utilisent du chiffrement aujourd'hui, puisque le moindre appel HTTPS en fait. « Votre app utilise-t-elle du chiffrement ? » est donc presque toujours oui — mais la réponse qui vous débloque porte sur le caractère exempté de ce chiffrement, et pour l'immense majorité des apps il l'est.

Arbre de décision : utilisez-vous du chiffrement non exempté ?

Parcourez-les dans l'ordre. Le premier qui correspond décide de votre réponse.

Votre app n'utilise aucun chiffrement, ou rien au-delà de ce que fournit iOS ? → Exemptée. Répondez NON (ITSAppUsesNonExemptEncryption = false).
Tout votre chiffrement se limite-t-il à HTTPS/TLS ou aux API cryptographiques standard livrées par Apple dans iOS/macOS (CryptoKit, Keychain, Secure Enclave, etc.) ? → Exemptée. Répondez NON. Cela couvre l'écrasante majorité des apps.
N'utilisez-vous le chiffrement que pour l'authentification — hachage de mots de passe, signature de jetons — et pas pour chiffrer du contenu utilisateur ? → Exemptée. Répondez NON.
Livrez-vous VOTRE PROPRE algorithme de chiffrement, ou utilisez-vous la crypto pour protéger des données utilisateur au-delà de ce qui précède (schéma bout-en-bout maison, chiffrement sur mesure, fichiers chiffrés avec votre propre gestion de clés) ? → Potentiellement non exempté. Répondez OUI et faites l'auto-classification (voir plus bas).

Réutiliser de la crypto standard à travers votre propre surcouche pratique ne la rend pas non exemptée — ce qui compte est l'algorithme sous-jacent, pas l'emballage. C'est inventer ou embarquer un algorithme non standard qui vous fait basculer dans le non exempté.

Les deux façons de répondre — et pourquoi le plist gagne

Il y a exactement deux endroits pour répondre. Ils ne sont pas équivalents : l'un vous interroge à chaque version, l'autre répond une fois et reste répondu.

Où	À quelle fréquence la question revient	Idéal pour
L'invite d'App Store Connect	À chaque build. Chaque envoi TestFlight ou App Store affiche « Missing Compliance » tant que vous n'avez pas repassé les questions.	Un cas ponctuel, ou quand vous ne pouvez pas livrer un nouveau binaire tout de suite.
ITSAppUsesNonExemptEncryption dans l'Info.plist	Plus jamais. La valeur voyage dans le binaire ; App Store Connect la lit et saute la question pour ce build et tous les suivants qui portent la clé.	Toute app qui ne livre pas de chiffrement maison — réglez-le une fois et oubliez.

Les deux satisfont la même exigence américaine de conformité à l'export ; la clé du plist se contente d'y répondre définitivement.

L'extrait de plist exact

Ajoutez ceci à l'Info.plist de la cible de votre app (ou via l'onglet Info / un xcconfig). C'est un booléen :

<key>ITSAppUsesNonExemptEncryption</key>
<false/>

Puis Clean Build Folder (⇧⌘K), archivez à nouveau et envoyez. Mettre false n'est correct que si votre app est exemptée selon l'arbre ci-dessus — c'est une déclaration juridique, pas un bouton « couper le son ». Une subtilité : un build déjà déposé dans App Store Connect ne récupère pas la clé rétroactivement. Répondez manuellement à la question de ce build-là pour le débloquer maintenant, et livrez la clé dans votre prochain archivage pour ne plus jamais être interrogé.

Quand vous avez vraiment besoin de l'exemption / de l'auto-classification

Si l'étape 4 de l'arbre correspond — vous livrez du chiffrement non standard ou maison — répondre OUI n'est pas la fin. Vous assumez de vraies obligations au titre des EAR :

Auto-classification : déterminez l'ECCN de votre app (typiquement 5D002) et confirmez qu'elle relève de la License Exception ENC au sens de l'EAR §740.17.
Rapport annuel d'auto-classification : pour la plupart des apps de chiffrement grand public, vous devez envoyer une fois par an un rapport par e-mail au BIS et au coordinateur des demandes de chiffrement ENC/NSA (le rapport de fin d'année).
CCATS : certains produits nécessitent une classification formelle (CCATS) du Bureau of Industry and Security avant d'être éligibles — App Store Connect vous demandera alors cette autorisation.
Documentation dans App Store Connect : vous fournissez la base de votre exemption ou vos références CCATS/ERN dans la section chiffrement, version par version, sauf si vous avez déposé un code de conformité.

C'est vraiment rare pour une app grand public. Si vous utilisez CryptoKit, Keychain, TLS et rien d'exotique, vous êtes exempté et rien de tout ceci ne s'applique — répondez NON et passez à la suite.

Pas sûr que votre crypto soit exemptée ? Apple renvoie vers le Bureau of Industry and Security américain ; le test pratique est « ai-je implémenté un algorithme de chiffrement, ou est-ce que j'appelle juste celui d'Apple / j'utilise HTTPS ? ». Le second cas est exempté.

La panne classique : la clé totalement absente

Le plus souvent, ce n'est pas une mauvaise valeur qui pique, c'est l'absence de valeur. Sans la clé :

Chaque build TestFlight atterrit en « Missing Compliance » et vos testeurs ne peuvent pas l'installer tant que vous n'avez pas répondu dans App Store Connect — les invitations n'arrivent tout simplement pas.
Un build soumis à l'App Store n'avance pas vers l'examen tant que la conformité n'est pas réglée : il reste immobile pendant que vous le croyez en file d'attente.
Comme l'invite revient à chaque envoi, un pipeline CI/CD qui soumet automatiquement se bloque à chaque exécution — le classique « pourquoi TestFlight est bloqué ».

La correction est la même que plus haut : réglez ITSAppUsesNonExemptEncryption une fois dans l'Info.plist (si vous êtes exempté) pour qu'aucun build ne retombe jamais en Missing Compliance.

Questions fréquentes

Mon app ne fait que des appels HTTPS. Est-elle exemptée ?

Oui. HTTPS/TLS et la cryptographie standard intégrée à iOS sont du chiffrement exempté. Mettez ITSAppUsesNonExemptEncryption à NO. C'est le cas de la grande majorité des apps.

Mettre la clé à NO débloque-t-il à la fois TestFlight et l'App Store ?

Oui — la même valeur d'Info.plist satisfait la question de conformité à l'export pour la distribution TestFlight et pour l'App Store en même temps : vous tranchez une fois au lieu de canal par canal.

J'ai mis la clé mais App Store Connect affiche toujours Missing Compliance. Pourquoi ?

Un build envoyé avant l'ajout de la clé ne la récupère pas rétroactivement. Répondez manuellement à la question de ce build dans App Store Connect pour le débloquer, puis livrez la clé dans votre prochain archivage — les builds suivants ne demanderont plus.

Répondre NON est-il parfois le mauvais choix ?

Oui, si vous livrez réellement du chiffrement non exempté — un algorithme maison ou de la crypto qui protège des données utilisateur au-delà d'HTTPS et de la crypto du système. Il faut alors répondre OUI et faire l'auto-classification (ECCN, License Exception ENC, et éventuellement le rapport annuel ou un CCATS). C'est une déclaration juridique : répondez honnêtement.

Qu'est-ce que le rapport annuel (de fin d'année) sur le chiffrement ?

Pour les apps grand public utilisant du chiffrement non exempté sous License Exception ENC, la réglementation américaine impose un rapport annuel d'auto-classification envoyé par e-mail au BIS et au coordinateur ENC. Les apps exemptées (HTTPS uniquement) n'ont pas à le déposer.

Sources

Vérifiez votre build avant de soumettre

Passez votre .ipa ou .apk dans App Review Checker et détectez ces problèmes en quelques secondes.

Analyser une app