Votre app a-t-elle besoin de conditions d'utilisation ?

On trouve en ligne beaucoup d’affirmations assurées selon lesquelles les deux stores exigent des conditions d’utilisation. Lisez les pages des stores eux-mêmes : ce n’est pas ce qu’elles disent — il vaut donc la peine de séparer les trois questions différentes cachées dans celle-ci.

Google Play l’exige-t-il ?

Non. La politique User Data de Play précise ce qui doit être lié et où : “All apps must post a privacy policy link in the designated field within Play Console, and a privacy policy link or text within the app itself.” (Traduction : toutes les apps doivent publier un lien vers la politique de confidentialité dans le champ prévu de la Play Console, ainsi qu’un lien ou le texte de la politique de confidentialité dans l’app elle-même.) Une politique de confidentialité, deux fois. Rien sur les conditions d’utilisation, et la console n’a aucun champ pour elles.

La section App content de la Play Console demande une URL de politique de confidentialité et, si votre app a des comptes, une URL de suppression des données. Les conditions n’en font pas partie.

Apple l’exige-t-il ?

Dans un seul cas, et il est courant : les apps qui proposent des abonnements à renouvellement automatique. La règle 3.1.2 exige des liens fonctionnels vers la politique de confidentialité et vers des Terms of Use (EULA) — dans l’app elle-même et dans les métadonnées.

Vous n’avez pas à rédiger cet EULA. Apple en publie un standard que vous pouvez lier à la place ; voir le guide Terms of Use (EULA) pour savoir où va chaque version.

Pour une app sans abonnement, Apple n’exige pas non plus de conditions.

Alors pourquoi presque toutes les apps en ont-elles ?

Parce que « pas exigé par un store » et « vous n’en avez pas besoin » sont deux affirmations différentes. Les conditions sont le document qui répond aux questions qu’aucune politique de confidentialité ne couvre :

• Qui peut utiliser l’app, et ce qui se passe quand quelqu’un en abuse. Sans conditions, vous n’avez aucune base déclarée pour fermer un compte.
• Ce que vous devez à l’utilisateur, et ce que vous ne lui devez pas. Les exclusions de garantie et les limitations de responsabilité se trouvent ici, et ce sont elles qui justifient l’existence des conditions.
• Ce que l’utilisateur vous doit — paiement, usage acceptable, contenus qu’il publie.
• Quel droit s’applique et où les litiges sont jugés.
• Comment les conditions évoluent, et ce qui se passe si une clause est inapplicable.

Si votre app a des comptes, encaisse de l’argent, héberge des contenus d’utilisateurs ou pratique la moindre modération, ce sont des questions auxquelles il vous faudra tôt ou tard une réponse. Les écrire avant le litige coûte moins cher qu’après.

Ce que doivent contenir les conditions d’une app

Un ensemble de sections réaliste, dans l’ordre où elles se lisent généralement le mieux :

Section	Ce qu’elle règle
Utilisation de l’app	Licence d’utilisation, usage acceptable, ce qui entraîne la fermeture d’un compte
Comptes	Qui peut s’inscrire, votre droit de suspendre, le droit de l’utilisateur de supprimer
Achats et abonnements	Facturation, renouvellement, remboursements — et le fait que c’est le store, pas vous, qui traite le paiement
Propriété intellectuelle	À qui appartient l’app, à qui appartient ce que l’utilisateur publie
Exclusion de garantie et limitation de responsabilité	Le cœur du document
Modifications	Comment vous mettez à jour les conditions et comment les utilisateurs en sont informés
Contact	Une adresse réelle

Remarquez ce qui n’y figure pas : le traitement des données. Il relève de la politique de confidentialité, et le dupliquer dans deux documents est la façon dont les deux finissent par se contredire.

Ce qu’il faut éviter

• Copier les conditions d’une autre app en changeant les noms. C’est un problème de droit d’auteur, en plus d’un document qui décrit l’activité de quelqu’un d’autre.
• Promettre ce que vous ne pouvez pas faire. Des conditions qui affirment que vous supprimez toutes les données instantanément, ou qui garantissent la disponibilité, sont pires que le silence.
• Choisir une juridiction au hasard. Le droit applicable est un vrai choix, avec de vraies conséquences.
• Les cacher. Si les conditions ne sont accessibles que par un lien que vous avez supprimé lors de la dernière refonte, elles ne vous défendront pas beaucoup.

Les rédiger avec un assistant IA

Un assistant rédigera volontiers des conditions, et l’échec habituel est le même qu’avec une politique de confidentialité : si on lui demande « des conditions d’utilisation pour mon app », il écrit la moyenne de toutes les conditions qu’il a lues — clauses d’arbitrage, un tribunal dans un État où vous n’avez jamais mis les pieds, des promesses de disponibilité. Le prompt ci-dessous le limite aux sections standard ci-dessus, lui fait vérifier ce que fait réellement votre app (connexion, achats, contenus d’utilisateurs) avant d’écrire, et lui fait marquer ce qu’il ne sait pas avec [confirm: …] au lieu de l’inventer. Si l’app encaisse des paiements sur iOS, il doit inclure le lien vers l’EULA standard d’Apple.

Copiez-le en entier. Remplacez les informations entre crochets en haut, ou laissez-les et laissez l’assistant vous les demander.

You are helping me write the terms of service for my mobile app. They will be published as a web page on AppFoyer, next to the app's privacy policy, and linked from the app and its store listings. They should be short, standard and true for this app.

## About the app

- App name: [app name]
- Developer / company: [developer or company name]
- Support email: [support email]
- Platforms: [Android, iOS or both]
- Store listings: [store listing URLs, or "not listed yet"]
- Where these terms will be published: [your AppFoyer site URL]/terms
- What the app collects, as I declared it: [what the app collects — e.g. account info, analytics, ads, crash reports, location, purchases, or nothing]
- Account deletion page: [your AppFoyer site URL]/account-deletion (only if the app has user accounts)
- Country whose law applies: [country, if you have one]

## Step 1 — find the facts

If you can read this app's source code, read only its build, manifest and store-metadata files — for example `build.gradle(.kts)`, `gradle/libs.versions.toml`, `AndroidManifest.xml`, `Podfile.lock`, `Package.swift`, `Info.plist`, `PrivacyInfo.xcprivacy`, `pubspec.yaml`, `package.json`, `app.json`. Do not open `.env` files, keystores, credentials or any other secrets, and do not change any file.

From them, work out only what changes the terms:

- whether users sign in or create accounts (Firebase Auth, Sign in with Apple, Google Sign-In and the like);
- whether the app sells in-app purchases or subscriptions (StoreKit, Google Play Billing, RevenueCat and the like);
- whether users can post, upload or send content that others see (chat, comments, photos, profiles);
- whether the app shows ads or links to third-party services.

Show me that short list with the file each fact came from and ask me to confirm it. If you cannot read the code, ask me these four questions instead.

## Step 2 — ask only what you cannot know

Then ask me, in one short numbered list, and wait for my answers:

1. The minimum age to use the app.
2. Whether the app is free to use for personal purposes only, or also for business use.
3. If users can post content: what is not allowed, and whether I may remove it or close accounts.
4. Anything else you could not determine.

Never guess. Where I do not know an answer, write `[confirm: …]` in the text instead of inventing one.

## Step 3 — write the terms

Sections, in this order, leaving out any that do not apply: Acceptance of these terms · Use of the App · Accounts · Purchases and subscriptions · User content · Intellectual property · Third-party services · Disclaimer and limitation of liability · Termination · Changes to these terms · Governing law (as the placeholder below) · Contact.

- Standard, plain-language terms for a mobile app. Keep each section to a few sentences; this is not a contract negotiation.
- Purchases and subscriptions: payments are processed by the app store, prices are shown before purchase, subscriptions renew automatically until cancelled in the store account settings, refunds follow the store's policy.
- Disclaimer and limitation of liability: the app is provided "as is", and liability is limited "to the extent permitted by law".
- Do not describe how personal data is handled; that is the privacy policy's job.
- Do not promise what I cannot guarantee — uptime, instant deletion, error-free operation.
- Do not invent a company address, a court, arbitration or a jurisdiction — use `[confirm: …]`.
- Do not copy another app's terms.
- Start with `# Terms of Service`, then the line `_Last updated: [today's date]_`.
- Write these placeholders exactly as shown, never the values — they are filled in from my settings when the page is published: `{{app_name}}`, `{{developer_name}}`, `{{support_email}}`, `{{public_url}}`.
- In the Contact section, write the address as `[{{support_email}}](mailto:{{support_email}})`.
- Refer to the privacy policy as `[Privacy Policy]({{public_url}}/privacy)` instead of describing data handling here.
- If the app has user accounts, say in the Accounts section that users can request account deletion at `[{{public_url}}/account-deletion]({{public_url}}/account-deletion)`.
- Mandatory if the app is on iOS and has any in-app purchase or subscription — declared above, found in the build files or confirmed by me: in the Purchases and subscriptions section, include this sentence unchanged: For the iOS version, Apple's standard [Licensed Application End User License Agreement](https://www.apple.com/legal/internet-services/itunes/dev/stdeula/) applies to your use of the App. Never leave it out when the app takes payments.
- For governing law, write the line `{{governing_law}}` on its own and nothing else — it becomes the governing-law section when a country is set in my settings, and disappears when none is.
- End with this paragraph, unchanged:

  _This page was generated from a template provided by the hosting platform and completed by the app developer. It is not legal advice. The developer named above is solely responsible for its accuracy and for complying with the laws that apply to them._

## Format — this is pasted into a Markdown editor

- Reply with the finished terms only, as Markdown inside one ```markdown code block, with nothing before or after it.
- CommonMark only: headings, paragraphs, lists, bold, italics and links. No tables, no HTML, no images, no footnotes.
- Links only to `{{public_url}}` (for example the privacy policy), to Apple's EULA as above and to the support email. Any other link is shown as plain text on the published page, so leave it out. No link shorteners, no download links.

Il est écrit pour des pages publiées sur AppFoyer, c’est pourquoi il demande des espaces réservés du type {{app_name}} et se termine par notre avertissement. Si vous publiez ailleurs, supprimez ces lignes à l’étape 3 et demandez plutôt les valeurs. Pour la politique de confidentialité, voir Rédiger votre politique de confidentialité avec un assistant IA.

Ce que fait AppFoyer ici

Les conditions font partie des cinq pages que nous générons, avec la politique de confidentialité, la page de support et la page de suppression de compte. Le modèle couvre les sections ci-dessus, renseigne le nom de votre app, le nom du développeur, l’adresse de support et les liens vers les stores, et ajoute les sections sur les abonnements — y compris le lien vers l’EULA standard d’Apple — quand vous lui indiquez que l’app vend des abonnements sur iOS.

L’éditeur de conditions du tableau de bord comporte aussi un panneau Write it with your own AI : le prompt ci-dessus, déjà rempli avec les informations de votre app. Lancez-le dans n’importe quel assistant, recollez la réponse, lisez l’aperçu, publiez.

La checklist de conformité continue de signaler la page tant qu’elle n’est pas publiée et, pour une app à abonnement, tant que le lien vers l’EULA n’y figure pas réellement.

Comme toute page générée, c’est un modèle que vous complétez et dont vous êtes responsable, pas un conseil juridique. Si votre app touche à l’argent, aux données de santé ou aux enfants, faites-la relire par un avocat.

Les sources qui font foi

• Politique User Data — Aide Google Play. La citation ci-dessus provient de cette page.
• App Store Review Guidelines — Apple. La section 3.1.2 est la règle sur les abonnements.
• Licensed Application End User License Agreement — l’EULA standard d’Apple.