Respecter les nouvelles règles d'âge de Google Play pour les apps de rencontre avec l'eID

Depuis le 28 janvier 2026, Google Play demande aux applications de rencontre, tout comme aux applications de jeux d'argent en argent réel, d'activer le paramètre Restrict Declared Minors dans Play Console. Objectif : empêcher les utilisateurs déclarés comme ayant moins de 18 ans d'accéder à l'application. Cette exigence prolonge la politique Child Safety Standards de Google, en vigueur depuis 2025, qui oblige déjà les apps sociales et de rencontre à publier leurs standards de protection des mineurs et à désigner un point de contact dédié.

Si vous exploitez une application de rencontre, ce n'est pas une simple note de bas de page dans une politique de plateforme. C'est le moment où les app stores cessent de traiter l'âge comme une case à cocher et commencent à le traiter comme une obligation de conformité, avec des conséquences directes sur la distribution. Une app qui l'ignore s'expose à la sanction qu'aucune équipe de croissance ne peut absorber : le retrait du store.

Cet article explique ce que les règles demandent réellement, pourquoi l'âge « déclaré » n'est qu'un point de départ, et comment les plateformes européennes de rencontre peuvent prendre de l'avance avec la vérification d'âge par eID : une approche qui satisfait les régulateurs sans détruire votre tunnel d'inscription ni la vie privée de vos utilisateurs.

Ce que Google Play exige désormais

La mise à jour de janvier 2026 a deux implications concrètes pour les applications de rencontre :

1. Restrict Declared Minors. Votre app doit être configurée de façon à empêcher l'accès aux utilisateurs dont les signaux d'âge déclarés indiquent qu'ils ont moins de 18 ans. Google déduit cet âge « déclaré » à partir de signaux au niveau du compte ; votre rôle est d'activer la restriction et de vous assurer que votre propre onboarding ne la contourne pas.

2. Conformité aux Child Safety Standards. Standards de sécurité publiés, mécanisme de signalement dans l'app et point de contact dédié à la protection des mineurs : autant d'exigences que les applications de rencontre doivent respecter depuis la vague de politiques de 2025.

Le mot important est déclaré. Le mécanisme de Google repose aujourd'hui sur l'âge que l'utilisateur a indiqué dans son compte Google. C'est un plancher, pas un plafond, et c'est précisément là que l'histoire réglementaire dépasse le seul cadre de Google.

Pourquoi l'âge déclaré ne suffira pas longtemps

Un adolescent déterminé de 16 ans avec un âge de compte falsifié passe tout droit à travers un filtre fondé sur les mineurs « déclarés ». Les régulateurs le savent, et la tendance dans tous les grands marchés est claire : on passe de la déclaration à l'assurance.

• Au Royaume-Uni, l'Ofcom classe les applications de rencontre parmi les services utilisateur-utilisateur au sens de l'Online Safety Act, avec une attente d'assurance d'âge hautement efficace et des amendes pouvant aller jusqu'à 10 % du chiffre d'affaires mondial pour les services qui échouent.
• Aux États-Unis, les lois sur la responsabilité des app stores, emmenées par le Texas, ciblent de plus en plus explicitement les plateformes de rencontre au nom de la protection des mineurs en ligne.
• Dans l'UE, les lignes directrices de la Commission sur la protection des mineurs au titre du Digital Services Act, ses procédures d'exécution contre les grandes plateformes et sa nouvelle application de vérification d'âge en marque blanche pointent toutes dans la même direction : l'auto-déclaration touche à sa fin.

Pour les applications de rencontre, il existe aussi une raison purement commerciale de s'en préoccuper. Les arnaques sentimentales coûtent aux consommateurs plus d'un milliard de dollars par an rien que dans les pertes déclarées à la FTC, avec la perte médiane la plus élevée de toutes les fraudes par imposture. Les faux profils alimentent votre churn. La même vérification qui rassure Google et les régulateurs est aussi le signal de confiance le plus fort que vous puissiez afficher sur un profil.

L'approche eID : prouver « 18+, réel, unique » — et rien d'autre

La réponse traditionnelle à l'assurance d'âge est la vérification documentaire : téléverser une pièce d'identité, prendre un selfie, attendre. Cela fonctionne, mais cela place sur votre plateforme une masse de données biométriques et d'identité sensibles, avec toute l'exposition RGPD que cela implique, et cela casse la conversion au pire moment possible : l'inscription.

Les schémas eID européens offrent un compromis fondamentalement meilleur. Les utilisateurs s'authentifient via une identité qu'ils possèdent déjà et à laquelle ils font confiance :

• itsme en Belgique, utilisé par l'immense majorité des adultes belges.
• iDIN aux Pays-Bas, avec une confirmation d'âge via la connexion bancaire de l'utilisateur, le même geste qu'un paiement iDEAL. (itsme possède iDIN, une seule intégration couvre donc les deux marchés.)
• BankID, MitID, Smart-ID, Freja et d'autres schémas dans les pays nordiques et baltes.

La propriété de conception décisive est la divulgation sélective, et elle est plus puissante qu'on ne l'imagine souvent. Lorsqu'une app de rencontre demande une vérification 18+, l'attribut d'indicateur d'âge d'iDIN permet à la banque de ne partager que le fait que le client a plus de 18 ans ou non, sans date de naissance. Le service Qualify d'itsme confirme des seuils comme 18+ sans exposer la date de naissance ni aucun document d'identité. La réponse est calculée à la source, par la banque ou par itsme, et ce qui arrive à votre plateforme se limite à un oui ou un non signé.

Votre plateforme apprend trois choses : cet utilisateur a plus de 18 ans, c'est une personne réelle, et c'est un individu unique. Elle ne stocke aucune donnée d'identité sous-jacente. Avec ces schémas, la date de naissance ne vous parvient même jamais, ni à nous.

Ce simple oui/non débloque trois gains à la fois :

1. Conformité app store et réglementaire : un contrôle d'âge vérifiable, bien au-delà de l'âge déclaré, avec une piste d'audit que vous pouvez présenter à Google, à l'Ofcom ou à un régulateur DSA.
2. Confiance et sécurité : un badge « Vérifié » adossé à un contrôle de niveau bancaire est le signal le plus difficile à falsifier pour un fraudeur, et les utilisateurs le comprennent.
3. Privacy by design : pas de téléversement de pièce d'identité, pas de base biométrique, une surface RGPD minimale. C'est le même modèle de divulgation sélective que le portefeuille européen d'identité numérique généralisera à partir de fin 2026 ; vous construisez donc vers l'avenir, pas à contre-courant. (Nous expliquons cette transition dans Pourquoi nous intégrons l'eID.)

Une architecture en couches — et une politique que vous maîtrisez

L'eID est la première et meilleure couche, mais tous les utilisateurs n'en possèdent pas : nouveau résident, visiteur étranger, cas de bord. Une plateforme respectueuse de la vie privée traite cela avec une vérification en couches, dans un ordre volontaire :

1. eID d'abord (itsme, iDIN ou le schéma de votre marché) : le parcours optimal pour la vie privée, et le parcours par défaut.
2. Estimation d'âge ensuite, facultative : une estimation faciale de l'âge qui estime l'âge à partir d'un selfie sans identifier la personne et supprime immédiatement l'image. Assurance d'âge, pas identification.
3. Scan documentaire en dernier recours, facultatif : l'option la plus lourde en données, à réserver aux cas extrêmes.

Les couches que vous activez relèvent de votre politique, et le comportement par défaut est strict. Chaque solution de repli est optionnelle, et le flux est fermé en cas d'échec : si un utilisateur ne peut pas réussir une couche que vous avez autorisée, la vérification est refusée. Elle n'est jamais discrètement rétrogradée vers un contrôle plus invasif pour forcer un résultat. Une plateforme de rencontre configurée en eID uniquement ne peut littéralement pas collecter de document ou de biométrie, même en principe.

Et lorsque vous activez une estimation d'âge ou un repli documentaire, le selfie ou la pièce d'identité est capturé par le SDK du fournisseur spécialisé et envoyé directement à ce fournisseur. L'image ne transite pas par nos serveurs et n'y repose jamais. eIDAS Pro n'enregistre aucune donnée personnelle ou sensible de vos utilisateurs. Nous ne conservons ni noms, ni dates de naissance, ni images de documents, ni biométrie : seulement un enregistrement non identifiant indiquant qu'un contrôle a eu lieu, et quand.

Implémentation : où placer le contrôle dans votre parcours

Un modèle fonctionne particulièrement bien en pratique :

L'inscription reste fluide. Laissez les utilisateurs créer un compte et construire leur profil comme aujourd'hui. Ne bloquez pas la porte d'entrée.

Vérifiez avant l'interaction. Placez le contrôle eID au moment de déclencher le matching ou la messagerie : le point où un mineur pourrait réellement subir un préjudice et où votre obligation de conformité devient concrète. À ce stade, les utilisateurs sont déjà investis, et les taux de complétion sont nettement meilleurs qu'à l'inscription.

Faites de la vérification une récompense, pas un péage. Les utilisateurs vérifiés obtiennent un badge, et les profils non vérifiés ont moins de visibilité. Vous transformez un coût de conformité en levier produit : les utilisateurs se vérifient parce que cela leur apporte plus de matchs.

Conservez la piste d'audit. Journalisez le fait et l'horodatage de chaque vérification, jamais les données d'identité, afin de démontrer une assurance d'âge systématique à toute plateforme ou autorité qui vous le demanderait.

Checklist de conformité en cinq points

1. Activez Restrict Declared Minors dans Play Console et vérifiez que votre page Child Safety Standards et votre point de contact sont en place.
2. Cartographiez les endroits où des utilisateurs de moins de 18 ans pourraient réalistement passer à travers votre onboarding actuel.
3. Ajoutez un contrôle eID 18+ (itsme, iDIN ou le schéma de votre marché) avant le matching ou la messagerie.
4. Décidez volontairement votre politique de repli : eID uniquement, ou eID plus estimation d'âge optionnelle, et gardez un flux fermé en cas d'échec.
5. Transformez la vérification en fonctionnalité produit : badge, boost de visibilité, messages de confiance.

En résumé

Les règles de Google Play de janvier 2026 sont le premier domino, pas le dernier. Les plateformes qui traitent l'assurance d'âge comme une case à cocher devront la bricoler dans l'urgence lorsque la prochaine réglementation arrivera ; celles qui la traitent comme une fonctionnalité de confiance en feront un moteur de croissance. La vérification eID est l'une des rares mesures de conformité qui améliore le produit : plus de vraies personnes, moins d'arnaqueurs, et pas le moindre document d'identité sur vos serveurs.

eIDAS Pro fournit aux plateformes européennes une vérification d'âge et d'identité fondée sur l'eID : une API unique couvrant itsme, iDIN et d'autres schémas nationaux, avec des solutions de repli optionnelles et respectueuses de la vie privée, alignées avec le futur portefeuille européen d'identité numérique. Prendre rendez-vous →

Cet article fournit des informations générales et ne constitue pas un conseil juridique. Vérifiez les textes de politique en vigueur auprès de la documentation officielle de Google Play et de votre conseil.