Google rend les passkeys obligatoires lors de la création de nouveaux jetons d’actualisation OAuth 2.0 via Google Ads API. Le déploiement commence le 5 août et s’étendra progressivement. Les jetons existants continueront de fonctionner et les comptes de service ne sont pas concernés. Mais cette apparente continuité masque un risque opérationnel : au premier ajout d’utilisateur, remplacement d’identifiant ou rétablissement d’une intégration, un modèle d’accès mal préparé peut retarder une livraison.
Il ne s’agit pas seulement d’une mise à jour pour développeurs. C’est un test de gouvernance pour les agences, les équipes internes et les éditeurs SaaS. Une passkey est un identifiant personnel lié à un appareil ; elle ne se transmet pas comme un mot de passe ou un code temporaire. C’est son avantage de sécurité, mais cette propriété révèle aussi les processus encore dépendants d’un compte Google partagé, du téléphone d’une seule personne ou d’un ancien collaborateur.
Ce qui change et ce qui ne change pas
Les utilisateurs qui suivent le parcours d’authentification de Google Ads API devront employer une passkey pour générer un nouveau jeton d’actualisation. Selon Google, le mot de passe, le SMS ou le code temporaire d’une application ne suffiront plus à cette étape. Un utilisateur non équipé sera invité à créer sa passkey.
Les jetons actuels doivent rester valides, sans reconnexion générale immédiate. Les comptes de service échappent également à cette exigence. En revanche, une passkey nouvellement créée peut subir un délai de sécurité avant d’être pleinement reconnue. Suivant le parcours, ce délai peut durer plusieurs jours. Une intégration réalisée au dernier moment devient donc un risque de projet.
Pourquoi le compte partagé devient un passif opérationnel
Un compte partagé ne permet pas de savoir qui a approuvé l’accès, généré le jeton ou conservé le moyen de récupération. Les passkeys rendent volontairement ce modèle plus difficile, car chaque identifiant appartient à une personne. Les agences doivent attribuer des accès nominatifs, exploiter les rôles du compte administrateur et documenter le propriétaire de chaque intégration.
Installer une passkey sur un appareil commun ne ferait que conserver l’ancien problème sous une nouvelle forme. Un modèle robuste sépare l’authentification personnelle de la continuité de l’organisation : les personnes s’authentifient, l’agence contrôle les rôles et au moins deux administrateurs formés peuvent restaurer l’accès sans emprunter l’identité d’un collègue.
Une checklist de préparation en cinq volets
1. Inventorier les parcours qui produisent des jetons
Recensez les scripts internes, chaînes de reporting, plateformes d’enchères, entrepôts de données, Google Ads Editor, Ads Scripts, Looker Studio et transferts BigQuery. Pour chaque connexion, notez l’identité Google utilisée, le responsable métier, le responsable technique et l’effet d’une panne.
2. Remplacer les identités communes par des utilisateurs nominatifs
Invitez chaque collaborateur avec son adresse professionnelle et accordez le rôle minimal nécessaire. Ne supprimez un ancien accès qu’après avoir vérifié qu’aucune intégration n’en dépend. Conservez deux administrateurs pour la continuité, sans distribuer des droits excessifs par simple commodité.
3. Créer les passkeys avant l’urgence
Toute personne susceptible d’autoriser un nouveau jeton doit créer une passkey sur un appareil compatible et tester le parcours entre appareils. Google prend en charge les versions récentes de Windows, macOS, ChromeOS, Android et iOS ainsi que les clés matérielles FIDO2. Sur un parc géré, vérifiez avec l’équipe informatique la compatibilité du navigateur, du Bluetooth et des règles de sécurité.
4. Prévoir la récupération et le départ d’un collaborateur
Documentez la perte d’un téléphone, l’échec d’une passkey ou le départ d’un salarié. La réponse ne doit pas dépendre de la personne qui a effectué le premier réglage. Le registre des intégrations doit identifier les propriétaires, des administrateurs de secours doivent être formés et les dépendances aux jetons doivent figurer dans la procédure de départ.
5. Tester l’intégration sur un compte peu risqué
Avant le 5 août, exécutez le parcours complet sur un compte de test ou secondaire. Mesurez le temps nécessaire à la création de la passkey, au délai de confiance, à l’approbation et à la connexion de l’application. Une connexion réussie ne suffit pas : confirmez le périmètre obtenu et l’identité visible dans les journaux.
Les questions à poser à chaque fournisseur martech
- La connexion utilise-t-elle OAuth utilisateur ou un compte de service ?
- Qui génère le jeton et quelles autorisations sont demandées ?
- Un second administrateur peut-il restaurer l’intégration sans l’utilisateur initial ?
- Où le jeton est-il stocké, chiffré et renouvelé ?
- Quelle alerte signale une perte d’autorisation ?
- En combien de temps la collecte historique reprend-elle après reconnexion ?
La conclusion managériale
L’obligation de passkey n’améliorera pas directement une campagne. Elle réduira une catégorie de risques liés au phishing et aux prises de contrôle, tout en rendant la propriété des accès visible. Les organisations les mieux préparées traiteront le 5 août comme une échéance pour nettoyer la couche d’identité qui soutient leur reporting et leur automatisation.
Réalisez l’inventaire, passez aux accès nominatifs et testez la récupération. Cela représente quelques heures d’opérations. L’alternative consiste à découvrir, lors d’un lancement ou de l’arrivée d’un client, que la seule personne capable d’autoriser la connexion est absente et que le nouvel identifiant n’est pas encore reconnu.
Sources
- Search Engine Land : Google impose les passkeys aux utilisateurs de Google Ads API
- Aide Google Ads : utiliser une passkey pour les actions sensibles
- Google Ads API : exigences de sécurité
