Décryptage du règlement Play : AMA

Très bien.

Merci à tous de nous avoir rejoints pour cette table ronde sur le décodage du règlement de Google Play.

Je m'appelle Jan Kleinert et je suis ingénieur DevRel dans l'équipe Android for Cars.

Je serai le modérateur de la table ronde d'aujourd'hui.

Je vais laisser nos intervenants, Bohdan et Paul, se présenter.

Bohdan, commençons par vous.

Bonjour à tous.

Je m'appelle Bohdan et je travaille dans l'équipe Trust & Safety de Google Play.

Je travaille ici depuis plus de quatre ans et dans le secteur de la fiabilité et de la sécurité technologiques depuis plus de dix ans.

J'aime voir comment la technologie, l'industrie et la culture interagissent, et comment les événements encouragent le développement de nouvelles applications. J'aime aussi les événements comme celui-ci, où nous pouvons faire de notre mieux pour aider les développeurs comme vous à réussir.

Bonjour !

Je m'appelle Paul.

Je travaille dans la même équipe que Bohdan, et je travaille dans le domaine de la confiance et de la sécurité depuis à peu près la même période que lui, soit une dizaine d'années, dont la majeure partie avec l'équipe Trust & Safety de Google Play.

Je suis donc ravi d'être sur scène aujourd'hui. C'est parti !

D'accord, merci.

Pour planter le décor avant de commencer la table ronde, je vais laisser la parole à Paul.

Il va commencer par un bref aperçu des ressources sur les règles, des informations sur les bonnes pratiques et d'autres éléments de ce type pour vous aider à préparer votre application à une vérification du respect des règles plus fluide et plus efficace.

Oui.

Mais qu'entendons-nous par "règles Play" ?

Il s'agit des règles fondamentales que les développeurs doivent respecter lorsqu'ils publient et gèrent des applications mobiles sur le Google Play Store.

Nous avons fourni des liens courts à l'écran vers des ressources sur les règles Play.

Le premier lien vous redirige vers le centre d'informations sur les règles pour les développeurs.

Si vous cliquez sur "Mises à jour récentes" en haut de la page, vous pouvez consulter les détails des nouvelles règles, ainsi que les mises à jour ou les clarifications apportées aux règles existantes.

Si vous préférez les contenus visuels ou audio, le deuxième lien court vous redirigera vers une playlist de nos Policy Bytes.

Il s'agit de vidéos dans lesquelles nous expliquons les modifications apportées aux règles.

Enfin, le troisième lien vous redirigera vers une page où vous pourrez en savoir plus sur Play Policy Insights dans Android Studio, une fonctionnalité qui fournit des conseils utiles avant l'examen sous la forme de vérifications lint dans Android Studio.

Très bien.

Il existe également une compétence Android pour vous aider à auditer les applications Android par rapport à ces règlements de Google Play afin de vérifier la conformité des autorisations, de la suppression de compte et de la sécurité des données.

Vous pouvez installer cette compétence à l'aide de la CLI Android, comme n'importe quelle autre compétence.

android skills list
android skills add play-policy-insights

Enfin, avant de passer aux questions de Jan, nous voulions partager quelques bonnes pratiques pour respecter les règles de Play et les examens d'applications.

La première consiste à fournir des identifiants de connexion aux examinateurs.

Cela peut sembler évident, mais l'une des raisons les plus courantes de retard ou de refus est l'inaccessibilité du contenu.

Si votre application nécessite une connexion, ou si elle propose du contenu protégé, des crédits ou des abonnements, vous devez fournir des identifiants de test.

Pour certaines applications, cela signifie qu'il faut fournir des identifiants de connexion au tout début de l'application, tandis que pour d'autres, il peut y avoir différentes sections, comme le contenu payant que j'ai mentionné.

Pour ce faire, accédez à la Play Console, puis fournissez ces identifiants de connexion à nos examinateurs.

Elle s'appelait auparavant "Accès à l'application", mais elle s'appelle désormais "Informations de connexion" et se trouve dans la section "Contenu de l'application".

Ensuite, vous devez vous assurer que les identifiants contournent l'authentification à deux facteurs, les captchas, les paywalls, etc.

Oui, désactivez les anciens codes de version.

Les développeurs se retrouvent donc souvent dans ce que nous appelons familièrement des "boucles de refus". Ils importent une version de production propre et conforme, mais oublient souvent qu'une version plus ancienne et non conforme est toujours active dans la Play Console sur un autre canal, qu'il s'agisse d'un test ouvert, d'un test fermé, etc. Ainsi, même si un app bundle se trouve dans un ancien canal de test, il est soumis à la vérification du respect des règles de Google Play.

Par conséquent, si elle demande des autorisations restreintes ou utilise des SDK vulnérables obsolètes, elle sera toujours soumise à un examen.

Assurez-vous donc de remplacer ou de désactiver tous les codes de version obsolètes sur tous les canaux avant de cliquer sur le bouton d'envoi.

Troisièmement, prévoyez suffisamment de temps pour les examens et utilisez la publication gérée.

L'examen et la publication d'une application peuvent donc prendre sept jours, voire plus, en particulier s'il s'agit d'une nouvelle application ou d'une application demandant une autorisation sensible.

Vous devez donc prévoir un délai suffisant.

Si vous prévoyez un lancement majeur, veillez à envoyer la nouvelle application au moins deux semaines avant la date de lancement effective.

Vous pouvez ensuite associer cette fonctionnalité à la publication gérée.

La publication gérée est une fonctionnalité qui permet de mettre en attente les mises à jour approuvées jusqu'à ce que vous soyez prêt à les publier. Cela évite les retards inattendus lors des campagnes marketing ou d'autres lancements importants.

Ensuite, veillez à ne pas renvoyer l'application une fois qu'elle a déjà été envoyée pour examen.

En effet, si vous le faites, le compte à rebours recommence.

Je pense que les développeurs l'oublient parfois. Ils ont une application à moitié terminée et se disent : "Oh, je dois faire ce petit changement."

Il la renvoie, et elle retourne au début du processus d'examen.

Vérifiez vos déclarations.

Par exemple, les déclarations de contenu de votre application (section Sécurité des données, règles de confidentialité ou autorisations d'accès aux photos/vidéos) doivent correspondre au fichier manifeste d'application des bundles ou codes de version actifs sur tous les canaux.

Par exemple, si le fichier manifeste de votre application demande l'accès à la position exacte, mais que votre formulaire de déclaration d'autorisations n'en indique pas l'objectif, l'application peut faire l'objet d'une mesure d'application, et c'est même très probable.

Assurez-vous donc que les SDK tiers n'exfiltrent pas de données que vous n'avez pas déclarées.

Même si votre application n'utilise pas une donnée spécifique, si vous choisissez d'intégrer un SDK qui l'utilise, cela peut entraîner une mesure d'application.

Consultez le Google Play SDK Index pour obtenir des insights sur plus de 100 SDK commerciaux parmi les plus utilisés.

Avant de continuer, j'aimerais vous poser une petite question.

Quand vous parlez de mesures d'application, à quoi faites-vous exactement référence ?

Qu'est-ce que cela signifie ?

Les mesures d'application peuvent être de toute nature, allant des avertissements aux refus, en passant par des mesures plus sévères telles que des suppressions, des suspensions, voire des exclusions de compte.

Lorsque je parle de mesures d'application, je fais référence à ces actions défavorables.

Parfait.

Merci.

Oui.

Enfin, utilisez les appels.

Ne vous contentez pas de renvoyer la même version après un refus.

De plus, des refus répétés pour le même problème sur une courte période peuvent déclencher un signalement algorithmique qui entraîne des mesures d'application plus sévères, comme celles mentionnées par Paul (suppressions ou suspensions).

Si une application est refusée, ne la renvoyez pas immédiatement sans apporter de modifications, sans deviner ou sans tenir compte des commentaires.

Vous recevrez des communications dans la boîte de réception de la console et par e-mail à l'adresse que vous avez fournie, avec des informations précises sur le cas de non-respect et des conseils.

Si vous n'êtes pas d'accord avec un refus, ou si vous ne le comprenez pas, vous pouvez faire appel.

Si vous pensez qu'il s'agit d'un faux positif, vous pouvez faire appel en cliquant sur le lien fourni dans la communication.

C'est une meilleure première étape que de se précipiter pour renvoyer l'application sans apporter de modifications.

De même, si vous recevez une communication qui ne vous semble pas tout à fait claire, qui est peut-être trop longue, qui comporte trop de paragraphes ou autre, vous pouvez tout à fait revenir vers l'équipe chargée des appels.

Vous pourrez ainsi échanger par e-mail avec une personne réelle.

Même si les informations qu'ils peuvent vous communiquer sont limitées, vous pouvez souvent obtenir des détails supplémentaires sur la cause du refus.

Dans d'autres cas, l'équipe chargée des appels comprend que les communications peuvent être assez longues.

Ils peuvent ainsi mettre en surbrillance ou en gras les sections qui s'appliquent spécifiquement à vous et à votre application.

Voilà.

Je laisse maintenant la parole à Jan.

Très bien.

Merci.

Nous avons donc recueilli des questions de développeurs provenant de différents canaux et sources.

Les questions que nous allons aborder aujourd'hui représentent certaines des difficultés que les développeurs rencontrent souvent concernant les règles.

Commençons par là.

Quelles sont les raisons courantes pour lesquelles une application peut être refusée en raison des autorisations ?

Et comment les développeurs peuvent-ils éviter les refus liés, par exemple, au non-respect des règles sur les autorisations ?

Très bien.

"Autorisations", je vais prendre celle-ci.

Les autorisations, en particulier les autorisations sensibles, doivent donc être essentielles à l'objectif principal de votre application.

Par exemple, si vous avez une fonctionnalité secondaire ou une fonctionnalité qui n'est même pas dans l'application et qui n'est même pas annoncée, il est très probable que l'application soit refusée.

Assurez-vous donc que la déclaration correspond au cas d'utilisation de l'application.

De plus, une application est souvent refusée, car les liens vidéo que vous fournissez dans les déclarations sont tout simplement inaccessibles.

Notre équipe d'examen doit pouvoir accéder à l'application, aux liens vidéo que vous fournissez et à tout ce qui se trouve dans l'application pour l'examiner dans son intégralité.

Assurez-vous donc que tout est accessible dans l'application, le fichier manifeste et la déclaration.

Assurez-vous donc que ces trois éléments sont bien en place. Cela devrait faciliter le processus.

Parfait.

Très bien.

De plus en plus de développeurs d'applications commencent donc à utiliser des plates-formes tierces pour le contenu généré par l'IA dans leurs applications, n'est-ce pas ?

Si ces plates-formes produisent du contenu inapproprié, factuellement incorrect ou autre, cela peut-il entraîner le refus de l'application du développeur ? Et qui est réellement responsable dans ce cas ?

Oui.

Oui, cela peut entraîner un refus.

Depuis le lancement du Play Store, notre position a toujours été la même : tout ce qu'un développeur propose dans son application ou tout ce à quoi un utilisateur peut accéder dans l'application relève de la responsabilité du développeur.

Même si l'IA générative est un nouveau domaine, cela s'applique également à elle.

Je pense que l'IA générative est comparable au contenu généré par l'utilisateur, car ces deux types de règles nécessitent de nombreux éléments similaires, comme le signalement, par exemple, si un contenu inapproprié apparaît.

Il doit y avoir un mécanisme de filtrage.

Je pense qu'il y a d'autres règles qui s'appliquent, bien sûr, mais j'aime voir les choses de la façon suivante : si vous avez du contenu d'IA générative, Google examine l'application, les utilisateurs cliquent sur "Signaler" s'ils voient quelque chose d'inapproprié, et vous avez vos mécanismes de filtrage.

En fait, Google, vous (le développeur) et les utilisateurs travaillez tous ensemble pour que l'application soit aussi sûre que possible pour tout le monde.

OK.

Parfait.

Mais en général, recommandons-nous, en plus de disposer de mécanismes permettant aux utilisateurs de signaler du contenu, que les développeurs mettent en place une sorte de... Est-ce ce que vous entendez par "mécanisme de filtrage" ?

Pour empêcher l'affichage de certains types de contenus aux utilisateurs ?

Bonne réponse.

Oui.

Ainsi, lors du processus d'examen, nos équipes ne vont pas essayer d'analyser votre code ni de faire de la rétro-ingénierie pour comprendre votre mécanisme de filtrage exact.

Ils vont simplement vérifier s'ils peuvent accéder à des contenus inappropriés.

Si c'est le cas, nous vous enverrons des communications, et votre équipe devra trouver un moyen de rendre ce mécanisme de filtrage plus robuste.

OK.

Super, merci.

Par exemple, il existe une règle sur l'usurpation d'identité ou l'imitation.

Si une application est refusée en vertu de ce règlement sur l'usurpation d'identité, mais que le développeur pense qu'il s'agit d'une erreur, pour une raison ou une autre, que doit-il faire ?

Comment peuvent-ils éviter de manière proactive ce type de refus ?

Faire appel.

Oui, c'était l'une des… Je crois que c'était la cinquième bonne pratique que nous avons listée : si votre demande est refusée, vous devez faire appel.

Ensuite, que devez-vous faire ? Eh bien, dans les scénarios les plus courants, la marque dont vous usurpez l'identité est peut-être la vôtre, n'est-ce pas ?

Ou vous créez une application pour le compte de quelqu'un d'autre. C'est probablement le cas le plus courant, où des développeurs en marque blanche créent des applications pour des salles de sport, des solutions SaaS, etc.

Mais il est plus facile de les publier sous votre propre compte de développeur, n'est-ce pas ?

Vous pouvez donc faire appel. Notre équipe recherchera alors ce que l'on appelle une preuve d'autorisation.

Imaginons que vous ayez un client appelé "Joe's Chicken", qui propose le meilleur poulet à l'ouest du Mississippi.

Il vous fournira une lettre d'autorisation sur papier à en-tête officiel de l'entreprise avec son logo, indiquant que Joe's Chicken autorise ABC Developer à utiliser ses images et son identité dans son application. Il est préférable d'indiquer le nom de l'application et le nom du package d'application.

Par exemple, "com.joeschicken.app". Vous pouvez ensuite répondre au développeur et lui fournir cette documentation.

OK.

Et puis, je pense que la deuxième partie était…

Y a-t-il quelque chose qu'ils pourraient faire de manière proactive pour éviter cela ?

Par exemple, est-il possible d'importer, je ne me rappelle plus du nom, une preuve de quelque chose, au moment où on effectue le premier envoi ?

Oui.

C'est vrai.

Dans la Play Console, vous pouvez envoyer un formulaire d'avis préalable et importer des documents qui associent votre compte à l'autre entité.

En procédant ainsi, vous pouvez protéger de manière préventive l'envoi de votre application contre ce type de mesures d'application défavorables.

Oui.

Parfait.

Très bien.

Vous avez brièvement évoqué l'utilisation de SDK tiers dans la section sur les bonnes pratiques, mais j'aimerais en savoir plus.

Donc, quand les applications utilisent des SDK tiers, il semble que les développeurs d'applications soient responsables de la façon dont ces SDK tiers utilisent des éléments tels que les données utilisateur.

Comment les développeurs peuvent-ils savoir si les SDK respectent les règles sur la sécurité des données et les données utilisateur ?

Comment peuvent-ils s'y retrouver ?

C'est une excellente question.

J'ai beaucoup travaillé avec les SDK chez Google au cours de mes deux premières années ici. Cela nous ramène un peu à la question précédente, où nous parlions de l'IA générative et du contenu généré par l'utilisateur, dans le sens où tout ce qui se trouve dans votre application relève en fin de compte de la responsabilité du développeur.

Je crois que Paul a brièvement mentionné dans l'introduction que nous avions un outil appelé Google Play SDK Index. Vous pouvez simplement le rechercher sur Google.

Il devrait s'agir du premier ou du deuxième résultat, Google Play SDK Index. Vous obtiendrez une page Web contenant plus d'une centaine, voire plusieurs centaines de SDK, répartis par catégorie : monétisation, annonces, santé, etc.

Cette page extrait simplement des données accessibles au public.

C'est un événement organisé par Google.

Mais vous remarquerez que certains de ces SDK sont accompagnés d'un badge indiquant qu'ils sont enregistrés dans la SDK Console.

Tout comme vous, en tant que développeurs, disposez d'une Play Console pour vos applications, les développeurs de SDK ont la possibilité d'accéder à une SDK Console.

et doivent suivre un processus d'examen similaire.

Ils nous envoient leur SDK.

Google effectue plusieurs vérifications. Si l'entreprise est conforme, elle obtient le badge.

Pour vous, en tant que développeurs, cela signifie que vous pouvez accéder à cet index et voir quels SDK ont passé ce processus.

Cela ne garantit pas que l'application sera approuvée ni que le SDK ne sera jamais non conforme, mais cela donne deux points de confiance.

Tout d'abord, il est beaucoup moins probable que l'application soit refusée si vous utilisez ce SDK.

Juste une probabilité.

Le deuxième point, et c'est quelque chose que j'apprécie vraiment dans tout ce processus, est que si nous constatons que le SDK contient un élément non conforme, nous adoptons une approche en deux temps.

Tout d'abord, nous contactons le développeur du SDK pour lui signaler que son SDK envoie des données utilisateur de manière non conforme.

Ils s'efforceront ensuite de rendre leur application ou leur SDK conforme.

Ensuite, à peu près au même moment, ou peut-être un peu plus tard, nos équipes envoient des notifications ou des avertissements aux développeurs.

La notification indiquera par exemple : "Nous avons remarqué que votre application envoie ces données de manière non conforme et que cela se produit dans le SDK ABC."

En tant que développeur, vous pouvez simplement mettre à jour le SDK vers la version conforme fournie.

Si vous voulez aller plus loin, vous pouvez supprimer le SDK ou le remplacer, mais je sais que cela demande beaucoup d'efforts et de travail.

Mais c'est ce que j'aime dans le Google Play SDK Index.

Oui.

L'index n'indique pas exactement quelles règles sont respectées ou non, mais vous obtenez ce badge, qui est un peu comme un vote de confiance.

OK.

Oui.

D'accord, ça me va.

Et si j'ai bien compris ce que vous avez dit, si nous envoyons un message aux développeurs pour leur dire "Vous utilisez ce SDK et il y a un problème",

Si les développeurs corrigent le problème, est-ce qu'on leur indique quelle version utiliser ? Par exemple, "Une meilleure version est disponible" ?

Ou doivent-ils faire un peu de recherche par eux-mêmes ?

Je pense qu'il contient effectivement le code de version.

Oui, je ne suis pas sûr, mais je crois que le code de version vers lequel ils peuvent effectuer la mise à jour y est indiqué.

En toute transparence, je ne suis pas développeur ni ingénieur, mais d'après ce que j'ai compris en discutant avec des développeurs, il suffit parfois de cliquer sur un ou deux boutons pour lancer le processus de mise à jour du SDK dans l'application.

Génial.

Parfait.

Merci.

Très bien.

Vous avez parlé des identifiants de connexion, un sujet que je connais un peu, et de l'importance d'inclure ces informations.

Vous avez mentionné le contournement de l'authentification à deux facteurs et la possibilité de contourner les paywalls ou d'accéder à des contenus payants.

Mais quelles autres situations courantes les développeurs doivent-ils prendre en compte ?

Par exemple, j'ai déjà vu des applications dont le contenu n'est accessible que dans certains pays ou certaines zones géographiques, ou des applications de chat qui nécessitent deux connexions pour pouvoir être testées.

Y a-t-il d'autres situations de ce type où, en plus de fournir une connexion, les développeurs doivent faire un petit effort supplémentaire ?

Oui.

Je pense que je commencerais et terminerais toujours par les identifiants de connexion que vous fournissez à l'équipe d'examen. Assurez-vous simplement qu'ils lui donnent accès à toutes les fonctionnalités de l'application.

Cette section de la Play Console s'appelait auparavant "Accès aux applications". Je pense qu'elle a été renommée "Informations de connexion" il y a environ un mois.

Il y a un endroit où vous pouvez saisir le nom d'utilisateur et le mot de passe, et je crois qu'en dessous, il y a un champ de texte libre.

Vous pouvez donc donner des instructions sur la façon de se connecter si ce n'est pas très simple.

Vous pouvez également fournir un deuxième, un troisième et un quatrième identifiant si vous le souhaitez.

Pour vous donner une idée, lorsque nos équipes examinent les applications, elles ne se contentent pas de cliquer sur "Approuver" ou "Refuser" après avoir jeté un coup d'œil rapide.

De nombreuses équipes examinent les différentes règles et workflows. Il est donc très probable que plusieurs personnes se connectent à votre application sur plusieurs appareils, parfois dans différentes régions.

Je comprends la difficulté, car de nombreux mécanismes de sécurité se disent : "Oh, si nous voyons un certain nombre de connexions", alors, pour la sécurité de l'utilisateur, ils arrêtent et remettent en place.

Mais quoi que vous choisissiez de faire, sachez que nous examinons l'application dans de nombreux workflows différents. Vous pourriez donc voir ce message.

Fournir plusieurs identifiants peut donc être utile.

Oui.

Parfait.

Oui, je dois souligner l'importance d'utiliser ce texte libre dans la déclaration.

Si votre compte de démonstration ne se limite pas à un nom d'utilisateur et un mot de passe, et qu'il implique d'autres étapes, vous devez vous assurer que notre équipe d'examen comprend comment accéder à votre application.

Vous pourriez peut-être fournir une vidéo pour montrer comment faire, juste pour vous assurer que notre équipe comprend comment faire si c'est plus complexe que, vous savez, un nom d'utilisateur et un mot de passe.

Oui.

Parfois, nous examinons nous-mêmes des applications, et certaines proposent des connexions assez sophistiquées.

J'en ai vu où, et je n'invente rien, il faut appuyer 17 fois sur un bouton, puis dessiner un X sur l'écran, puis le mode développeur s'affiche, et il faut suivre 11 autres étapes. S'il vous plaît, ne faites pas ça.

Parce que ça complique un peu les choses.

Par exemple, certaines applications ne vous permettent d'avoir que X connexions successives ou simultanées avant de vous demander d'en supprimer une.

Si votre application propose cette option, je pense qu'il est également utile d'inclure des informations sur la façon de trouver la page où l'utilisateur peut supprimer l'accès à des connexions précédentes, par exemple.

Oui.

Parfait.

Ainsi, lorsque nous mettons à jour des règles ou en publions de nouvelles, les développeurs doivent parfois modifier leur application, ce qui peut prendre un certain temps selon la nature des changements.

Parfois, ces demandes sont assorties d'une date limite.

Par exemple, "Vous devez avoir fait XYZ d'ici telle date pour respecter un nouveau règlement".

Si cette échéance approche, mais qu'un développeur sait qu'il aura besoin de plus de temps pour s'y conformer, quelles sont ses options ?

Oui, ça ressemble à un avertissement.

Oui, ça ressemble à un avertissement.

Oui.

Oui, donc, avec les avertissements, je veux dire, le plus simple est de demander plus de temps, n'est-ce pas ?

En général, nous publions de nouvelles règles, des mises à jour de règles existantes ou même de simples clarifications.

Ensuite, je pense que Google est généralement assez efficace pour donner des délais.

Cette règle peut être annoncée publiquement six mois avant que nous ne commencions à prendre des mesures.

Ensuite, nous envoyons des avertissements pour indiquer que l'application ne respecte pas une règle annoncée six ou douze mois auparavant.

Mais une chose que Paul et moi contestons parfois, c'est qu'ils peuvent vous dire que vous avez sept jours pour effectuer ce changement.

Le développement prend beaucoup de temps.

On a compris.

Dans ce cas, je me contenterais de répondre.

Vous devez faire appel et dire quelque chose comme : "Nous comprenons le règlement et en quoi notre application n'est pas conforme.

Nous y travaillons déjà, ou voici les mesures que nous allons prendre pour résoudre le problème lié aux règles, mais nous avons besoin de plus de temps."

Ils vous accorderont donc généralement un peu plus de temps.

Si vous n'avez toujours pas reçu le code au bout de sept jours, vous pouvez en demander un autre.

Bien sûr, elle n'est pas infinie.

Mais comme je l'ai dit, Paul et moi, nous nous opposons à cela, mais c'est à titre individuel, et aussi à un niveau plus élevé.

Par exemple, quand nous savons que de nouvelles règles vont être mises en place et que nous connaissons les personnes qui travaillent dessus, nous leur demandons : "Est-ce qu'on pourrait avoir un préavis de 28 jours au lieu de 7, ou au moins de 14 jours ?"

Oui.

C'est vrai.

Si vous montrez que vous êtes de bonne foi et que vous apportez des modifications pour vous mettre en conformité, Google Play collaborera avec vous pour fixer un nouveau délai.

Une chronologie plus adaptée à vos besoins.

OK.

Il semble donc que les appels soient un outil polyvalent permettant de résoudre un grand nombre de ces situations, à condition qu'ils soient utilisés de manière appropriée.

Par exemple, faire appel lorsque cela est pertinent, et fournir suffisamment de détails sur les raisons de votre appel peut être un bon moyen d'obtenir l'attention et l'aide dont vous avez besoin.

Très bien.

Si un développeur possède plusieurs applications sous un même compte de développeur, ce qui arrive tout le temps,

et que l'une d'elles est suspendue pour non-respect des règles, qu'est-ce que cela signifie pour l'ensemble de son compte de développeur ?

Cela met-il en danger le compte ou d'autres applications conformes ?

Comment cela fonctionne-t-il ?

C'est possible.

C'est comme vos développeurs sans étiquette.

Je parlais de Joe's Chicken tout à l'heure, n'est-ce pas ?

Peut-être que tous vos clients sont dans ce secteur.

C'est un peu comme si vous jouiez au baseball et que vous aviez des strikes, n'est-ce pas ?

Malheureusement, des acteurs malveillants tentent d'accéder au Play Store. C'est l'une des raisons pour lesquelles nous appliquons des mesures d'application allant de légères à plus strictes, comme des suppressions, des suspensions et même des interdictions de compte.

Si vous vous trouvez dans l'un de ces scénarios où vous avez une multitude d'applications similaires sur le Play Store et que l'une d'elles est suspendue, disons que…

Mm-hm.

Vous êtes un acteur malveillant, n'est-ce pas ?

Vous le corrigez, puis un mois plus tard, vous essayez de le réintégrer.

Nos équipes s'en rendent compte et vous êtes de nouveau suspendu.

Ensuite, vous la supprimez de votre application, puis vous la remettez un mois plus tard. Vous avez maintenant un comportement répétitif. Vous êtes au bâton, vous avez été éliminé trois fois, et vous êtes maintenant éliminé, n'est-ce pas ?

Mais imaginons que vous créez une application pour un restaurant de poulet. Il ne s'agit pas de contenu malveillant, vous essayez simplement de proposer de bons plats aux utilisateurs.

Imaginons que vous envoyiez toutes ces applications en même temps, par exemple avec un pipeline CI/CD, et que 10 applications soient refusées ou suspendues en même temps. Nous ne compterions qu'un seul avertissement, car nous comprenons que vous envoyez de nombreuses applications en même temps.

Mm-hm.

Intéressant.

Je pense que cela répond à la question.

Oui, c'est joli.

Merci.

En voici un autre.

La plupart de ces questions s'adressent plutôt aux développeurs établis, mais celle-ci concerne plutôt la configuration initiale dans la Play Console.

Imaginons que votre profil de paiement Google Play ait été validé.

Les erreurs de validation de l'identité ont disparu, et seule la vérification du numéro de téléphone reste.

Par exemple, que doit faire un développeur dans ce cas précis pour s'assurer que son compte de développeur est prêt à publier des applications ?

Parfois, on a l'impression de devoir assembler les pièces d'un puzzle. Si un utilisateur ne sait pas comment terminer le processus dans un cas comme celui-ci, que peut-il faire ?

Oui, on m'a posé une question similaire il n'y a pas si longtemps lors d'un autre événement. Je sais que c'est évidemment vrai pour les nouveaux développeurs, mais je pense que de nombreux développeurs existants ont dû effectuer à nouveau cette validation.

C'était il y a environ un an, n'est-ce pas ?

Je ne me rappelle plus très bien.

Beaucoup d'entre elles ont été validées automatiquement, mais certaines ont dû le faire manuellement.

OK.

Ou peut-être que l'adresse et le profil Dun & Bradstreet ne correspondaient pas…

C'est vrai.

C'est vrai.

Le profil Google.

OK.

Imaginons qu'il s'agisse du numéro de téléphone.

Je vais répondre à la question de deux manières.

OK.

Tout d'abord, lorsque vous suivez ces étapes, des notifications s'affichent souvent dans la Play Console.

Vous recevrez simplement une notification vous invitant à enregistrer votre numéro de téléphone.

C'est assez simple.

Vous le saisissez au format international, par exemple +1 408 XXX XXXX.

Vous devrez effectuer une validation par SMS ou par appel téléphonique, puis suivre les étapes indiquées.

Mais il arrive parfois que vous essayiez de le faire et que vous obteniez un message d'erreur ou autre, car nous avons eu des développeurs à qui cela est arrivé, ou qui ne recevaient pas le code par SMS.

Je vais vous indiquer les étapes à suivre pour contacter l'équipe chargée des appels.

C'est une équipe, mais il y en a en fait une demi-douzaine ou deux douzaines d'autres qui…

Will.

Répondez aux questions sur la Play Console auxquelles vous avez accès, via le menu d'aide.

L'interface utilisateur a légèrement changé.

Il se trouvait auparavant dans un menu situé à gauche de l'écran d'accueil.

En bas, vous aviez un bouton d'aide.

Il a disparu, mais si vous faites défiler n'importe quelle page jusqu'en bas, vous verrez ce bouton d'aide dans le pied de page.

Lorsque vous cliquez dessus, un petit bouton bleu en forme de pilule s'affiche avec le texte "Créer une demande d'assistance".

Je crois que c'est ce que ça dit.

Mm-hm.

Oui.

Vous obtenez ensuite des menus déroulants qui vous permettent de poser des questions.

Il existe en fait une série de menus déroulants qui vous mèneront directement au numéro de téléphone. Je pense que je m'en souviens presque par cœur, mais il s'agit de valider votre compte de développeur. Le deuxième menu déroulant est assez similaire, vous obtiendrez un certain nombre de cases d'option.

L'un d'eux est spécifiquement destiné à la vérification du numéro de téléphone.

Il se peut que vous receviez un code de validation par SMS ou qu'un bug s'affiche à l'écran lorsque vous essayez de suivre cette procédure.

Vous pouvez donc l'utiliser pour la validation du numéro de téléphone, mais aussi pour de nombreuses autres questions que vous pourriez avoir concernant votre compte de développeur Play.

La plupart du temps, la Play Console indique très clairement les étapes à suivre pour la validation. Il vous suffit donc de suivre les instructions.

Parfait.

Parfait.

Nous arrivons au terme de cette table ronde. Merci à tous d'y avoir participé.