Guideline 5.1.1 : comprendre et corriger un refus App Store

La guideline 5.1.1 est la règle d'Apple sur la collecte et le stockage des données. Sur mes trois refus de cette famille, la cause tenait à l'un de ces deux écarts : ce que l'app faisait avec les données ne correspondait pas à ce qui était déclaré, ou la demande d'autorisation poussait l'utilisateur à dire oui.

Cet article traite cette seule règle : ses alinéas, ce que je vérifie avant l'envoi et quoi corriger, avec trois refus que j'ai pris sur mes propres apps. Pour la vue d'ensemble de tous les motifs, lis plutôt pourquoi Apple refuse une app.

Qu'est-ce que la guideline 5.1.1 ?

La guideline 5.1.1, « Data Collection and Storage », fixe ce qu'une app doit respecter dès qu'elle touche à des données personnelles : une politique de confidentialité complète, un consentement avant la collecte, des demandes d'autorisation honnêtes et un compte que l'on peut supprimer. Elle s'applique à toutes les apps, même celles qui ne collectent presque rien.

Le texte officiel se trouve dans les App Review Guidelines, section 5 « Legal », partie 5.1 « Privacy ». Le message d'Apple cite souvent un alinéa précis, entre parenthèses : 5.1.1(i), 5.1.1(iv), 5.1.1(v). C'est cet alinéa qui te dit où chercher.

Les cinq alinéas de la 5.1.1 à connaître d'abord

Alinéa	Ce qu'Apple exige	Le refus typique
5.1.1(i) Privacy Policies	Politique complète et liée	Absente ou incomplète
5.1.1(ii) Permission	Consentement avant collecte	Texte d'autorisation vague
5.1.1(iii) Data Minimization	Seulement les données utiles	Accès complet aux photos
5.1.1(iv) Access	Ne pas pousser à accepter	Écran qui pousse à accepter
5.1.1(v) Account Sign-In	Pas de compte imposé	Connexion obligatoire

Trois précisions. La politique de confidentialité est liée dans App Store Connect et dans l'app. Elle dit quelles données sont collectées, comment et pour quoi, confirme que les tiers qui les reçoivent offrent la même protection, et explique comment retirer son accord ou faire supprimer ses données. Une fonction payante ne peut pas dépendre d'un accès aux données que l'utilisateur est libre de refuser. Et un compte créé dans l'app doit pouvoir être supprimé depuis l'app.

La règle compte d'autres alinéas, de (vi) à (x), sur des cas plus particuliers comme les domaines réglementés ou la compilation de données personnelles.

Les trois choses que je compare avant l'envoi

Je n'ai pas le mode d'emploi du reviewer. Voici ce que je compare moi‑même avant chaque envoi, parce que mes refus sont venus d'un écart entre ces éléments :

• ce que la politique en ligne dit, à l'URL déclarée dans App Store Connect ;
• ce que l'app fait réellement, écran par écran, y compris chaque demande d'autorisation ;
• ce qui est déclaré dans la fiche, dans la partie sur la confidentialité de l'app (App Privacy Details).

Je teste aussi chaque écran d'autorisation en fermant l'app puis en la relançant. C'est la cause que j'ai identifiée pour mon deuxième refus sur Nolera.

Trois refus 5.1.1 que j'ai pris, et leur vraie cause

Clic : la politique en ligne était l'ancienne version

Clic transforme un produit en slides prêtes à publier, avec l'IA. Le 16 septembre 2026, Apple refuse l'app en citant la 5.1.1(i) et la 5.1.2(i). L'écran de consentement à l'IA était bien dans l'app. Le problème était hors de l'app : la politique de confidentialité publiée sur le site était l'ancienne version. La nouvelle existait, mais elle n'avait pas été mise en ligne.

Le correctif : politique complète publiée, résumé en anglais ajouté pour le reviewer, notes de revue mises à jour. Je n'ai pas fait de nouveau build : j'ai renvoyé la même soumission.

La leçon : Apple lit ce qui est en ligne, pas ce qui est dans ton dépôt. Le jour de l'envoi, ouvre l'URL de ta politique et cherche le nom de chaque service tiers que ton app utilise.

Nolera : un bouton « Autoriser » avant la demande du système

Nolera est mon app de dressing. Le 17 septembre 2026, après une revue sur iPad Air, Apple cite la 5.1.1(iv). Avant la demande d'accès à la caméra, l'app affichait un écran d'explication avec un bouton « Allow the camera ».

Les règles de design d'Apple sont précises sur ce point. Un écran maison placé avant une demande du système ne doit avoir qu'un seul bouton, qui ouvre cette demande. Apple recommande un terme comme « Continuer » ou « Suivant », et pas « Autoriser » : un bouton qui ressemble à celui du système pousse à appuyer ensuite sur le vrai « Autoriser » sans l'avoir voulu.

Cette règle vise les écrans placés avant une demande du système : caméra, micro, position, contacts, calendrier, suivi. Elle laisse une exception, pour un consentement exigé par la loi.

Le correctif : le bouton s'appelle « Continuer », dans les 8 langues de l'app.

La leçon : un écran qui prépare une autorisation explique. Il ne décide pas à la place de l'utilisateur.

Nolera, deuxième refus : l'écran « caméra refusée » passait avant la demande

Renvoyée, Nolera est refusée une deuxième fois le 22 septembre 2026, toujours en 5.1.1(iv), cette fois sur iPad Pro 11 pouces. Apple relève deux points : un renvoi vers les Réglages avant la demande d'accès, et un écran que l'on pouvait quitter sans voir cette demande.

La cause que j'ai identifiée : un cas que je n'avais pas testé. L'écran de prise de vue affichait son panneau « caméra refusée », avec le lien vers les Réglages et une solution de repli, dès que l'accès n'était pas accordé. Y compris quand il n'avait jamais été demandé. Dans le parcours normal, l'écran d'explication passait avant et tout allait bien. Mais si l'on fermait l'app au milieu puis qu'on la relançait, on reprenait directement sur la prise de vue, sans avoir vu la demande du système.

Le correctif : tant qu'iOS peut encore poser la question, l'écran déclenche lui‑même la demande du système. Le panneau « caméra refusée » n'apparaît qu'après un vrai refus. Ce correctif a demandé un nouveau build, puisque le reviewer teste le code embarqué.

La leçon : « jamais demandé » et « refusé » sont deux états différents. Teste chaque écran d'autorisation en y revenant après avoir fermé l'app, pas seulement dans l'ordre du parcours.

5.1.1 et IA : ce que la 5.1.2(i) ajoute

Sur Clic, Apple a cité la 5.1.2(i) en plus de la 5.1.1. Cette règle demande d'indiquer clairement où les données personnelles sont partagées avec des tiers, et elle nomme expressément l'IA tierce (« third-party AI »). Elle demande aussi une permission explicite avant le partage.

Ma pratique depuis ce refus : trois choses cohérentes entre elles.

• Un écran de consentement dans l'app, avant le premier envoi, qui dit à quel service les données partent et lesquelles.
• La même information dans la politique de confidentialité en ligne.
• La même information dans les déclarations de confidentialité de la fiche.

Le détail de ce que la politique doit contenir est dans politique de confidentialité d'une application.

Que répondre à Apple après un refus 5.1.1

La conversation se tient dans la section App Review de ton app, dans App Store Connect. La procédure officielle pour répondre à App Review est la même que pour les autres règles. Écris en anglais, sobrement : ce qui posait problème, ce qui a changé, comment le vérifier. Voici le modèle que j'utilise (remplace le numéro de build et le correctif par les tiens) :

Hello,

Thank you for your review.

Issue: the custom screen shown before the camera permission
request used an "Allow" button, and the "camera denied" panel
could appear before the system alert had ever been shown.

Fix in build X:
- The custom screen now has a single "Continue" button that
  opens the system alert.
- The "camera denied" panel only appears after the user has
  actually denied access in the system alert.

How to verify: delete the app, install this build, launch it
and go to the photo step. The system alert appears first.

Best regards,

Deux cas se présentent :

• La cause est en ligne (politique, page d'assistance, déclarations de la fiche) : tu corriges, tu réponds, et la même soumission peut repartir sans nouveau build.
• La cause est dans l'app (écran, bouton, ordre des demandes) : il faut un nouveau build. Une mise à jour à distance ne suffit pas, comme je l'explique dans le guide sur la guideline 2.1.

La checklist 5.1.1 avant soumission

• L'URL de ta politique de confidentialité s'ouvre, et la page en ligne est la dernière version.
• La politique nomme chaque service tiers qui reçoit des données, IA comprise. C'est ma règle, plus stricte que le texte d'Apple.
• Les déclarations de confidentialité de ta fiche disent la même chose que la politique.
• Chaque texte d'autorisation explique l'usage en une phrase précise.
• Aucune autorisation n'est demandée au lancement si l'app peut fonctionner sans.
• Un écran maison avant une demande n'a qu'un bouton, « Continuer », qui ouvre la demande du système.
• Celui qui refuse une autorisation peut continuer autrement, ou comprend ce qu'il perd.
• L'écran « accès refusé » n'apparaît qu'après un vrai refus. Tu l'as testé en fermant puis en relançant l'app.
• L'app s'utilise sans compte quand le compte n'est pas indispensable.
• Un compte créé dans l'app peut être supprimé depuis l'app : la recette est dans suppression de compte iOS.
• Tout est testé sur iPad aussi : mes deux refus 5.1.1 sur Nolera ont été relevés sur iPad.

Corriger ton refus avec quelqu'un qui a déjà pris celui-là

Si ton app vient d'être refusée en 5.1.1, on peut reprendre ton dossier ensemble dans Le Club : tu partages ton écran, on lit le message d'Apple et on cherche l'écart entre ta politique, ton app et ta fiche. La démarche complète est aussi sur la page application refusée par Apple.

Si tu prépares ta première sortie, fais ton diagnostic gratuit pour remettre les étapes dans l'ordre. Dans L'Accélérateur iOS, la semaine 4 est consacrée au dossier App Store et à l'envoi à Apple.

Personne ne peut garantir qu'Apple acceptera ton app. Ce que je peux faire, c'est t'aider à éviter les refus 5.1.1 que j'ai déjà payés d'un cycle de revue.

Questions fréquentes

Que veut dire « Guideline 5.1.1 - Legal - Privacy - Data Collection and Storage » ?

C'est l'intitulé complet de la règle dans le message d'Apple. Il signale un problème de données personnelles : politique de confidentialité incomplète, demande d'autorisation jugée insistante, ou compte impossible à supprimer. L'alinéa entre parenthèses, par exemple 5.1.1(iv), indique lequel.

Faut-il un nouveau build après un refus 5.1.1 ?

Pas toujours. Si la cause est en ligne, comme une politique de confidentialité qui n'est pas à jour, tu corriges la page, tu réponds à Apple et la soumission repart sans nouveau build. Si la cause est un écran ou un bouton de l'app, il faut un nouveau build.

Peut-on afficher un écran d'explication avant une demande d'autorisation ?

Oui, Apple l'autorise quand c'est vraiment utile. L'écran n'a alors qu'un bouton, qui ouvre la demande du système, avec un terme comme « Continuer » ou « Suivant ». Pas de bouton « Autoriser », pas de bouton pour fermer ou passer, sauf consentement exigé par la loi.

Mon app utilise une IA externe : que faut-il déclarer ?

La guideline 5.1.2(i) demande d'indiquer où les données sont partagées avec des tiers, IA comprise, et d'obtenir une permission explicite avant. Je l'applique en trois endroits : un écran de consentement dans l'app, la politique de confidentialité en ligne, et les déclarations de confidentialité de la fiche. Sur Clic, Apple a cité cette règle avec la 5.1.1.

Le compte est-il obligatoire pour respecter la 5.1.1 ?

Non, c'est l'inverse. Si ton app n'a pas de fonction qui repose vraiment sur un compte, Apple demande de la laisser utilisable sans connexion. Et si elle permet de créer un compte, elle doit aussi permettre de le supprimer depuis l'app.