Rédiger la politique de confidentialité de votre app avec un assistant IA — un prompt qui fonctionne

Un assistant IA rédigera une politique de confidentialité en dix secondes. Le problème, c’est ce à partir de quoi il la rédige. Si on lui demande « écris une politique de confidentialité pour mon app de fitness », il n’a rien d’autre que le mot « fitness », et il produit la moyenne de toutes les politiques de confidentialité qu’il a lues : des clauses sur des cookies que votre app ne dépose pas, des identifiants publicitaires pour une app sans publicité, une durée de conservation « aussi longue que nécessaire », et aucun des SDK que vous embarquez réellement. Ça se lit bien. C’est aussi la partie qu’un reviewer du store compare à votre formulaire Data safety et à vos réponses App Privacy, et c’est dans cette comparaison qu’elle échoue.

Pourquoi le prompt d’une ligne échoue

• Il invente. Un modèle à qui l’on demande de remplir une section la remplit. Une durée de conservation, une base légale, une adresse de société — chacune plausible, chacune une affirmation sur votre activité que vous n’avez pas faite.
• Il est générique là où il doit être précis. La section qui compte le plus est la liste des services tiers, et un modèle qui n’a pas vu votre fichier de dépendances ne peut pas les nommer.
• Il déclare trop. Lister des données que vous ne collectez pas n’est pas « prudent ». C’est un écart avec vos propres déclarations aux stores, soit le même problème dans l’autre sens.
• Il met en forme pour la fenêtre de chat. Tableaux, notes de bas de page et HTML inline s’affichent bien dans la réponse et arrivent cassés partout où vous les collez.

Ce qu’un prompt doit lui faire faire

1. Lire les preuves d’abord. Un agent de code ouvert dans votre dépôt — Claude Code, Cursor, Codex et consorts — peut lire build.gradle, Podfile.lock, Info.plist et le manifest, et lister chaque SDK et chaque permission avec le fichier d’où ils proviennent. Cette liste est la substance de la politique. Un assistant conversationnel sans accès aux fichiers doit recevoir la consigne de vous demander de coller ces fichiers.
2. Ne pas toucher au reste. Les fichiers de build et le manifest suffisent. Il n’a aucune raison d’ouvrir des fichiers .env, des keystores ou le code source, et un prompt qui le dit est un souci de moins.
3. Ne demander que ce qui ne peut pas être lu. Combien de temps vous conservez les données, s’il y a un backend, si l’app s’adresse aux enfants, si vous partagez des données avec un partenaire qui ne laisse aucune trace dans le build. Rien d’autre n’a besoin d’être demandé.
4. Refuser de deviner. Là où vous ne savez pas, il écrit [confirm: …] au lieu d’une phrase. Un trou visible se corrige ; une clause inventée est une affirmation publiée.
5. Écrire pour l’endroit où ce sera publié. Du Markdown simple, des liens uniquement là où ils sont utiles — les pages de confidentialité des fournisseurs eux-mêmes, votre adresse de support — et la mention indiquant que le texte n’est pas un conseil juridique.

Le prompt

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 privacy policy for my mobile app. It will be published as a web page on AppFoyer and its URL goes into the "Privacy policy" field of Google Play and App Store Connect, where reviewers compare it with what the app actually does. Accuracy matters more than length.

## 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 this policy will be published: [your AppFoyer site URL]/privacy
- 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, list:

- every third-party SDK or service that collects or receives user data (analytics, ads, crash reporting, sign-in, payments, push notifications, backend, AI APIs) and what it receives;
- every permission the app requests and the feature that uses it;
- whether the app sells in-app purchases or subscriptions (StoreKit, Google Play Billing, RevenueCat and the like).

Show me that list with the file each fact came from, point out anything that contradicts what I declared above, and ask me to confirm it.

If you cannot read the code, ask me to paste the dependency files (for example `app/build.gradle` and `Podfile`) or to list the SDKs and permissions myself.

## Step 2 — ask only what you cannot know

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

1. How long each kind of data is kept, and whether there is a backend (where it runs, what it stores).
2. Whether the app is directed at children under 13.
3. Whether any data is shared with or sold to anyone beyond the services above.
4. Whether the app takes any payments, if the files did not settle it.
5. 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 policy

Sections, in this order, leaving out any that do not apply: Data we collect · How we use it · Third-party services · Purchases and subscriptions · Permissions · Data retention and deletion · Children · Your choices and rights · Changes to this policy · Contact.

- Plain language, short sentences. Describe what this app does; no clauses about things it does not do.
- Under Third-party services, name each provider, say what it receives and why, and link its own privacy policy page.
- Do not invent retention periods, legal bases, company addresses or a data protection officer — use `[confirm: …]`.
- Start with `# Privacy Policy`, 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}})`.
- If the app has user accounts, link account deletion as `[{{public_url}}/account-deletion]({{public_url}}/account-deletion)` in the retention and deletion section.
- 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.
- 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 policy 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 the providers' own privacy policy pages, to `{{public_url}}`, 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 variables du type {{app_name}} et se termine par notre mention. Si vous publiez ailleurs, supprimez les lignes de Step 3 concernant les variables, le lien de suppression et le paragraphe final, et demandez plutôt les valeurs.

Avant de publier ce qu’il a écrit

L’assistant a rédigé ; c’est vous qui publiez. Vérifiez, dans cet ordre :

• Chaque SDK de votre fichier de dépendances figure dans la politique, et rien n’y figure qui ne soit pas dans ce fichier. C’est le test mécanique, et celui que les reviewers effectuent en pratique.
• Chaque [confirm: …] est remplacé par une vraie réponse, ou la phrase est supprimée.
• La section sur les tiers correspond à votre formulaire Data safety et à vos réponses App Privacy. S’ils divergent, l’un des deux est faux — corrigez-le, quel qu’il soit.
• Si l’app accepte des paiements, le lien vers l’EULA d’Apple est présent. Une app iOS avec des achats intégrés ou des abonnements renvoie, depuis sa politique de confidentialité, vers le Licensed Application End User License Agreement standard d’Apple ; le prompt le demande, vérifiez donc qu’il est bien resté.
• Les durées de conservation sont les vôtres. Vous seul savez ce que votre backend conserve et pendant combien de temps.
• Tout ce qui sort de l’ordinaire passe par un avocat. Données de santé, finance, enfants, ou données partagées avec un partenaire — un prompt ne change rien à ce qu’un modèle ne peut pas couvrir.

Ce que fait AppFoyer

L’éditeur de la page de confidentialité dans le tableau de bord comporte un panneau Write it with your own AI (Rédigez-la avec votre propre IA) : le même prompt, déjà rempli avec le nom de votre app, le développeur, l’adresse de support, les plateformes, les liens vers les stores et les données que vous avez déclarées. Copiez-le, exécutez-le dans l’assistant que vous utilisez, et collez la réponse dans le panneau — le Markdown est extrait de son bloc de code et placé dans l’éditeur, où l’aperçu montre exactement ce qui sera publié. Rien n’est rendu public avant que vous ne cliquiez sur publier, et le texte passe les mêmes contrôles automatiques que n’importe quelle autre modification.

La page des conditions a le même panneau avec son propre prompt — reproduit dans Votre app a-t-elle besoin de conditions d’utilisation ?. Si vous utilisez Claude Code, le plugin AppFoyer fait le même travail pour les cinq pages sans copier-coller, et lui non plus ne peut pas publier. Aucune de ces deux voies n’est un conseil juridique, et chaque page le dit.

Les sources de référence

• Privacy policy requirements — Aide Google Play
• Provide information for Google Play’s Data safety section — Aide Google Play Console, sur le fait que les données des SDK sont à déclarer par vous
• App privacy details on the App Store — Apple