# Guideline 1.2 User-Generated Content : ce qu'Apple exige

> Guideline 1.2 : si tes utilisateurs publient, prévois un filtre, un signalement, un blocage, un contact et des CGU acceptées. Check-list Expo et Supabase.

Page originale : [Guideline 1.2 User-Generated Content : ce qu'Apple exige](https://devoria.fr/blog/guideline-1-2-contenu-genere-utilisateurs)
Auteur : [Mehdi Azizi](https://devoria.fr/mehdi-azizi)
Publication : 2026-11-04
Dernière révision du contenu : 2026-11-04


La guideline 1.2 s'applique dès que des utilisateurs publient quelque chose que d'autres voient : un message, une photo, un avis, et selon moi un simple pseudo dans un classement. Le texte d'Apple exige alors un filtre, un signalement suivi d'une réponse rapide, un blocage et un contact publié. **Les messages de refus ajoutent une cinquième exigence : des conditions d'utilisation acceptées, qui ne tolèrent ni contenu choquant ni utilisateur abusif.**

Ce guide ne raconte pas un refus. Il montre ce que j'ai mis en place dans TradaZen, mon app d'entraînement au trading, quand ses classements ont commencé à afficher des pseudos choisis par les joueurs. Pour la vue d'ensemble des motifs de refus, lis plutôt [pourquoi Apple refuse une app](https://devoria.fr/blog/pourquoi-apple-refuse-votre-app).

## Que dit la guideline 1.2 ?

La 1.2, « User-Generated Content », se trouve dans la section 1, « Safety », des [App Review Guidelines](https://developer.apple.com/app-store/review/guidelines/#user-generated-content). Elle vise les apps avec du contenu d'utilisateurs ou un service de réseau social. Pour éviter les abus, ces apps « must include » quatre protections :

- « A method for filtering objectionable material from being posted to the app » : **un filtre qui bloque le contenu choquant avant sa publication**.
- « A mechanism to report offensive content and timely responses to concerns » : un moyen de signaler un contenu, et une réponse rapide aux signalements.
- « The ability to block abusive users from the service » : la possibilité de bloquer un utilisateur abusif.
- « Published contact information so users can easily reach you » : un contact publié, facile à trouver.

La version actuelle du texte, mise à jour le 8 juin 2026, va plus loin. Elle rappelle qu'il est de ta responsabilité de retirer le contenu qui enfreint la règle, tes conditions d'utilisation ou tes règles de communauté. Si Apple en trouve, il te demande de le retirer et de fournir un plan d'amélioration, et peut retirer l'app en attendant.

Le texte liste aussi les apps qui n'ont pas leur place sur l'App Store : celles qui servent surtout à la pornographie, au chat aléatoire ou anonyme façon Chatroulette, à noter le physique de vraies personnes, aux menaces ou au harcèlement. **Pour ces usages, les quatre protections ne suffisent pas.** La 1.2.1 ajoute des règles pour les apps de créateurs, notamment un contrôle de l'âge pour le contenu qui dépasse la classification de l'app.

## Ton app est-elle concernée ?

Le questionnaire de classification par âge d'App Store Connect donne une bonne définition. Il parle de [contenu généré par les utilisateurs](https://developer.apple.com/help/app-store-connect/reference/app-information/age-ratings-values-and-definitions) quand du contenu créé par des utilisateurs est largement diffusé dans l'app : vidéos, photos, textes ou audio. Il traite à part la messagerie entre utilisateurs.

| Ce que voient les autres  | Concerné ?      |
| ------------------------- | --------------- |
| Messages entre membres    | Oui             |
| Photos ou avis publics    | Oui             |
| Pseudo dans un classement | Oui, à mon avis |
| Notes privées             | Non             |
| Contenu écrit par toi     | Non             |

Apple ne cite pas les pseudos. Je les traite pourtant comme du contenu d'utilisateur : n'importe qui peut en choisir un insultant, et d'autres joueurs le voient. C'est le choix que j'ai fait pour les classements de TradaZen.

## Les 5 mécanismes à coder, avec Expo et Supabase

Le message de refus 1.2, tel qu'un développeur l'a publié sur les [forums d'Apple](https://developer.apple.com/forums/thread/807358) fin 2025, liste les mesures attendues. Il commence par « Require that users agree to terms (EULA) » et se termine par une exigence de délai : agir sur les signalements « within 24 hours », en retirant le contenu et en excluant son auteur.

| Mécanisme      | Où le coder              |
| -------------- | ------------------------ |
| CGU acceptées  | Écran et profil          |
| Filtre         | Serveur, avant affichage |
| Signalement    | Bouton et table          |
| Blocage        | Table et règle d'accès   |
| Contact publié | App et fiche App Store   |

Les exemples SQL ci-dessous sont à adapter à ton schéma. Ils s'appuient sur les [règles d'accès par ligne de Supabase](https://supabase.com/docs/guides/database/postgres/row-level-security), qui s'appliquent même si quelqu'un contourne ton app.

### 1. Des CGU acceptées, sans tolérance pour les abus

Tes conditions d'utilisation doivent dire noir sur blanc qu'aucun contenu choquant ni utilisateur abusif n'est toléré. Exemple de clause, à faire relire, pas un avis juridique : « Aucun contenu offensant, haineux, sexuel ou harcelant n'est toléré. Un contenu signalé peut être retiré et son auteur exclu, sans préavis. »

**Une phrase passive sous un bouton d'inscription ne prouve pas l'accord : demande un geste explicite.** Un écran avec un lien vers les CGU et un bouton « J'accepte », avant la première publication. Enregistre la date et la version acceptées dans le profil, puis interdis la publication tant qu'elles manquent :

```sql
create policy "publier après les CGU" on public.posts
for insert to authenticated
with check (
  auth.uid() = author_id
  and exists (
    select 1 from public.profiles p
    where p.id = auth.uid() and p.cgu_acceptees_le is not null
  )
);
```

### 2. Un filtre avant que les autres voient le contenu

Le filtre vit sur le serveur, parce que le code de l'app peut être contourné. Une copie dans l'app sert seulement à prévenir l'utilisateur tout de suite.

Dans TradaZen, une fonction en base vérifie chaque pseudo, et l'app applique la même liste pour prévenir le joueur. Je garde les deux identiques. Côté serveur, un pseudo offensant n'est pas refusé à l'écriture : **il est remplacé par un pseudo neutre à l'affichage, ce qui évite de bloquer quelqu'un sur un faux positif**.

Les faux positifs arrivent vite. Dans TradaZen, une première version du filtre censurait des prénoms comme Dominique, Monique ou Véronique, parce qu'ils contiennent un morceau de mot grossier. La correction : chercher des mots entiers, pas des morceaux de mots. Et l'app étant vendue en japonais et en chinois, le filtre couvre aussi ces langues.

### 3. Un signalement, traité sous 24 heures

Chaque contenu publié porte un bouton « Signaler ». Dans TradaZen, un pseudo signalé dans le classement de la ligue s'affiche tout de suite sous un libellé neutre, sur le téléphone de la personne qui signale. Le signalement part ensuite au serveur, et il est renvoyé plus tard si le téléphone est hors ligne.

Côté base, une table de signalements, un seul par personne et par contenu :

```sql
create table public.reports (
  id uuid primary key default gen_random_uuid(),
  reporter_id uuid not null references auth.users (id) on delete cascade,
  target_id uuid not null,
  reason text,
  created_at timestamptz not null default now(),
  unique (reporter_id, target_id)
);
alter table public.reports enable row level security;
create policy "mes signalements" on public.reports
for insert to authenticated
with check (auth.uid() = reporter_id);
```

Dans TradaZen, **un pseudo signalé par plusieurs joueurs est remplacé par un pseudo neutre**, et les signalements ne sont jamais montrés à la personne signalée. Une précaution générale : l'identifiant qui sert au signalement ne doit pas être modifiable par l'auteur du contenu, sinon il peut échapper au masquage.

Le masquage automatique ne remplace pas ta décision. Pour tenir les 24 heures, fais-toi prévenir à chaque signalement : un [webhook de base de données Supabase](https://supabase.com/docs/guides/database/webhooks) peut appeler une fonction serveur qui t'envoie un message. La clé qui permet de retirer le contenu reste sur le serveur, comme je l'explique dans [clé API secrète dans une app Expo](https://devoria.fr/blog/cle-api-secrete-app-expo).

### 4. Un blocage qui agit immédiatement

Une table de blocages, puis une règle d'accès qui retire le contenu des personnes bloquées du fil de celle qui bloque :

```sql
create policy "sans les bloqués" on public.posts
for select to authenticated
using (
  not exists (
    select 1 from public.blocks b
    where b.blocker_id = auth.uid() and b.blocked_id = posts.author_id
  )
);
```

Dans TradaZen, on ajoute un ami par un code, et on peut le retirer et le bloquer. **Un ami bloqué disparaît de la liste, même s'il renvoie une demande.**

### 5. Un contact publié, facile à trouver

Mets une adresse de contact dans les réglages de l'app, et une URL d'assistance qui répond vraiment dans App Store Connect. Dans TradaZen, l'adresse de support figure dans la politique de confidentialité et dans les conditions d'utilisation. Le contenu attendu de ces pages est dans [politique de confidentialité d'une application](https://devoria.fr/blog/politique-confidentialite-app-ios).

Dernier point : décide ce que deviennent les contenus d'une personne qui supprime son compte. Le `on delete cascade` ci-dessus supprime ses signalements avec son compte. La recette complète est dans [suppression de compte iOS](https://devoria.fr/blog/suppression-compte-app-ios).

## Ce que TradaZen affiche dans sa politique

Ces mécanismes sont décrits publiquement dans la politique de confidentialité de TradaZen, complétée en septembre 2026 avec l'arrivée des ligues et des amis : « Les pseudos passent par un filtre automatique ; tu peux signaler un pseudo inapproprié dans le classement, et retirer et bloquer un ami. » La même politique précise que l'e-mail et le journal ne sont jamais montrés aux autres joueurs. Le contexte de l'app est dans l'[étude de cas TradaZen](https://devoria.fr/blog/etude-de-cas-tradazen-app-iphone).

## Que répondre à Apple après un refus 1.2

Dis au reviewer où trouver chaque mécanisme, dans ta réponse et dans les notes de revue. Ces fonctions vivent dans l'app : le reviewer teste le code embarqué dans la build, prévois donc un nouveau build. La procédure pour [répondre à App Review](https://developer.apple.com/help/app-store-connect/manage-submissions-to-app-review/reply-to-app-review-messages/) est la même que pour les autres règles. Voici un modèle en anglais, à adapter, en ne gardant que ce qui est vrai dans ton app :

```text
Hello,

Thank you for your review. Build X includes the precautions
listed in Guideline 1.2:

- Terms: users accept our terms, with zero tolerance for
  objectionable content and abusive users, before posting.
- Filter: posts and usernames are checked on our server
  before other users can see them.
- Report: tap "..." on any post, then "Report".
- Block: tap "..." on any post, then "Block user". Their
  content disappears immediately.
- Reports notify us instantly; we act on them within 24 hours.
- Contact: Settings > Contact us, and our support URL.

Best regards,
```

Si un mécanisme manque dans la build, une réponse ne suffira pas. Comme pour la [guideline 2.1](https://devoria.fr/blog/guideline-2-1-app-store-refus), Apple juge la build qu'il a entre les mains.

## La check-list 1.2 avant l'envoi

- Tu as listé tout ce qu'un utilisateur publie et que d'autres voient, pseudos compris.
- Tes CGU interdisent le contenu choquant et les abus, et l'app demande un « J'accepte » explicite.
- Le filtre tourne sur le serveur, cherche des mots entiers et couvre les langues de ta fiche.
- Chaque contenu a un bouton « Signaler », et chaque signalement te prévient tout de suite.
- Tu sais retirer un contenu et exclure son auteur en moins de 24 heures.
- Bloquer un utilisateur retire son contenu immédiatement.
- Une adresse de contact est visible dans l'app, et l'URL d'assistance répond.
- Le questionnaire de classification par âge déclare le contenu d'utilisateurs, et la messagerie si ton app en a une.
- Les notes de revue disent où trouver chaque mécanisme, avec un compte de démonstration.

## Corriger ton refus avant de renvoyer l'app

Si ton app vient d'être refusée en 1.2, le [Kit Review Apple](https://devoria.fr/kits/review-apple) rassemble ce que je vérifie avant chaque envoi, avec deux skills qui relisent ton projet dans Claude Code et préparent ta réponse si Apple refuse. Pour un regard humain, [réserve une heure avec moi](https://devoria.fr/coaching) : on lit le message ensemble et on regarde ton parcours de modération. La démarche complète après un refus est sur la page [application refusée par Apple](https://devoria.fr/expertise/application-refusee-par-apple).

Si tu prépares ta première sortie, [fais ton diagnostic gratuit](https://devoria.fr/diagnostic) : il te dit quelle étape attaquer d'abord et t'envoie ma checklist anti-refus Apple.

Personne ne peut garantir qu'Apple acceptera ton app. Ces cinq mécanismes, bien visibles, retirent au moins ce motif de la liste.

## Questions fréquentes

### Que veut dire « Guideline 1.2 - Safety - User-Generated Content » ?

C'est l'intitulé du refus dans le message d'Apple. Il signifie que ton app affiche du contenu créé par des utilisateurs sans toutes les protections attendues : filtre, signalement traité vite, blocage, contact publié et conditions d'utilisation acceptées.

### Un pseudo dans un classement compte-t-il comme contenu d'utilisateur ?

Le texte d'Apple ne le dit pas. Je le traite comme tel, parce qu'un pseudo est choisi librement et vu par d'autres joueurs. Dans TradaZen, les pseudos des classements passent par un filtre, peuvent être signalés et sont remplacés par un pseudo neutre s'ils posent problème.

### Faut-il vraiment traiter les signalements sous 24 heures ?

C'est ce que demande le message de refus d'Apple. Le texte de la règle parle de réponses rapides. Un filtre automatique ne suffit donc pas : il faut quelqu'un qui retire le contenu et exclut son auteur. Le masquage automatique après plusieurs signalements t'aide à tenir en attendant.

### Les conditions d'utilisation doivent-elles être acceptées dans l'app ?

C'est la façon la plus sûre. Le message de refus demande que les utilisateurs acceptent des conditions qui ne tolèrent ni contenu choquant ni utilisateur abusif. Un lien en bas d'une page ne prouve pas l'accord. Un écran avec un bouton « J'accepte », avant la première publication, ne laisse pas de doute.

### Une app de chat anonyme peut-elle passer la guideline 1.2 ?

Le texte actuel cite le chat aléatoire ou anonyme parmi les usages qui n'ont pas leur place sur l'App Store. Une app qui sert surtout à cela peut être retirée sans préavis, même avec un filtre, un signalement et un blocage.


## 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.