Guides Politique de confidentialité
Envoyer les données de vos utilisateurs à une API d'IA — ce qu'exige Google Play
Ajouter un appel à un LLM dans une app, c'est partager des données, et la politique User Data de Play le dit explicitement. Quoi déclarer, où, et à quoi doit ressembler la divulgation dans l'app.
La politique User Data de Google Play s'applique aux intégrations d'IA tierces, et vous restez responsable de la divulgation et du consentement. Si votre app envoie du contenu utilisateur à une API d'IA, c'est un partage de données avec un tiers : nommez-le dans votre politique de confidentialité, déclarez-le dans le formulaire Data safety, et affichez une divulgation bien visible dans l'app avant que cela ne se produise.
Faites-le plutôt en quelques minutes
AppFoyer héberge les pages dont parle ce guide — politique de confidentialité, conditions, support, suppression de compte et app-ads.txt — sur leur propre sous-domaine, sans domaine ni serveur à vous. Une app est gratuite, et rien de ce qu'exige un store n'est jamais payant.
Vérifié le 19 septembre 2026. Les règles des stores changent, parfois sans préavis. Tout ce qui suit renvoie à la documentation officielle, et c'est elle — pas cette page — qui fait autorité. Si les deux se contredisent, c'est le store qui a raison. Ce guide est traduit de l'anglais ; les citations de la documentation des stores restent en anglais, dans leur version originale.
Ajouter une fonctionnalité « résume ceci », « interroge tes notes » ou « génère une légende », c’est trois lignes de code réseau, et c’est précisément pour cela qu’elle échappe en général complètement à la discussion sur la conformité. Du point de vue du store, vous venez de commencer à envoyer le contenu de vos utilisateurs à une entreprise dont ils n’ont jamais entendu parler.
Google Play a levé l’ambiguïté dans sa politique User Data : « These requirements also apply to third-party AI integrations (such as products, services, code) and you remain responsible for ensuring compliance with this policy, including limited use, disclosure and consent. » (Ces exigences s’appliquent également aux intégrations d’IA tierces — produits, services, code — et vous restez responsable du respect de cette politique, y compris l’usage limité, la divulgation et le consentement.)
Il n’y a pas ici de régime spécial pour l’IA. C’est la règle ordinaire du partage de données, formulée de sorte que personne ne puisse soutenir que l’appel d’API était différent.
Ce qui compte
Si des données utilisateur quittent l’appareil et atteignent un fournisseur de modèle, cela compte — que vous l’appeliez directement ou via une surcouche :
- les prompts contenant quoi que ce soit que l’utilisateur a tapé, dicté, photographié ou téléversé ;
- les documents, images et fichiers audio envoyés pour traitement ;
- les identifiants de compte ou d’appareil joints à la requête ;
- l’historique de conversation que vous stockez et renvoyez.
Un modèle sur l’appareil qui n’envoie jamais rien à un serveur est un autre cas. Si vous n’êtes pas certain de celui que vous avez, lisez la documentation du SDK plutôt que de supposer — plusieurs bibliothèques « sur l’appareil » se rabattent sur un appel serveur.
Les trois endroits où cela doit apparaître
1. Votre politique de confidentialité. Play exige que la politique, avec les éventuelles divulgations dans l’app, « comprehensively disclose how your app accesses, collects, uses, and shares user data » (divulgue de manière exhaustive comment votre app accède aux données utilisateur, les collecte, les utilise et les partage). Nommez le fournisseur et dites ce qui est envoyé, à quoi cela sert et combien de temps c’est conservé. « Nous pouvons utiliser des services tiers pour améliorer votre expérience » n’est pas une divulgation ; c’est une manière de ne pas en faire.
2. Votre formulaire Data safety. Envoyer du contenu utilisateur à une API externe, c’est un partage avec un tiers, et le formulaire pose précisément cette question. La position de Google Play sur un écart entre les deux est claire : « When Google becomes aware of a discrepancy between your app behavior and your declaration, we may take appropriate action, including enforcement action. » (Lorsque Google constate un écart entre le comportement de votre app et votre déclaration, nous pouvons prendre les mesures appropriées, y compris des mesures coercitives.) Du trafic vers un endpoint d’IA que votre formulaire ne mentionne pas est exactement un tel écart.
3. Une divulgation dans l’app, avant que cela se produise. C’est l’exigence que les développeurs sautent, parce que c’est la seule qui demande du travail d’interface. Les règles de Play à ce sujet sont précises : la divulgation « must be within the app itself, not only in the app description or on a website » (doit se trouver dans l’app elle-même, pas seulement dans la description de l’app ou sur un site web), et elle « must be displayed in the normal usage of the app and not require the user to navigate into a menu or settings » (doit s’afficher lors de l’utilisation normale de l’app sans obliger l’utilisateur à naviguer dans un menu ou dans les paramètres). Lorsque le consentement est requis, la boîte de dialogue doit être « clear and unambiguous » (claire et sans ambiguïté) et exiger une « affirmative user action (for example, tap to accept, tick a check-box) » (action positive de l’utilisateur, par exemple appuyer pour accepter, cocher une case).
Un lien vers votre politique de confidentialité dans un écran de paramètres n’est pas une divulgation dans l’app. Une phrase sur l’écran où la fonctionnalité est utilisée pour la première fois, avant la première requête, en est une.
Les questions à trancher avant de livrer la fonctionnalité
- Que contient exactement le prompt ? Les développeurs sont régulièrement surpris par la quantité de contexte que leur propre code y joint.
- Le fournisseur s’en sert-il pour l’entraînement ? Les offres grand public et entreprise d’une même API diffèrent souvent sur ce point, et c’est quelque chose que votre politique affirme comme un fait.
- Combien de temps le fournisseur le conserve-t-il ? Indiquez la durée, ou dites que vous ne la maîtrisez pas.
- L’utilisateur peut-il éviter la fonctionnalité ? Une fonctionnalité qui envoie tout en silence est plus difficile à justifier qu’une fonctionnalité que l’utilisateur active lui-même.
- Et les mineurs ? Si votre app touche des enfants, c’est le moment de s’arrêter et de demander conseil.
Répondez à ces questions par écrit avant de livrer la fonctionnalité. Chacune correspond à une phrase de la politique, et si vous ne pouvez pas y répondre, vous ne pouvez pas rédiger honnêtement la politique.
Si votre app génère aussi du contenu
Indépendamment du partage de données, les politiques de Play traitent du contenu généré par IA — son étiquetage, et l’obligation d’empêcher l’app de produire du contenu interdit. C’est une question de politique de contenu plutôt que de confidentialité, et il vaut la peine de lire directement le texte actuel de la politique avant le lancement ; nous ne l’avons pas résumé ici parce qu’il évolue.
Ce que fait AppFoyer
Nous rédigeons votre politique de confidentialité à partir de ce que contiennent réellement vos fichiers de build, si bien qu’un SDK d’IA dans votre liste de dépendances apparaît comme un tiers nommé au lieu d’être discrètement omis. La checklist continue de signaler la page tant que la section des tiers est encore un texte provisoire.
Ce que nous ne pouvons pas faire, c’est la divulgation dans l’app — c’est un écran de votre app, et la politique dit explicitement qu’un site web ne peut pas la remplacer. Et comme toujours, les modèles sont un point de départ, pas un conseil juridique. Tout ce qui touche aux mineurs ou à des données sensibles mérite une heure d’avocat.
Les sources de référence
- User Data policy — Aide Google Play. Toutes les citations ci-dessus proviennent de cette page ; c’est ce texte qui fait foi.
- Provide information for Google Play’s Data safety section — Aide Google Play Console
- App privacy details on the App Store — Apple