Best Buy développe l’IA de Google Cloud, mais les identifiants partagés devaient disparaître

Best Buy a remplacé un modèle d’accès lourd en identifiants alors qu’il prépare des dizaines de milliers d’utilisateurs à un usage accru de l’IA et de l’analytique sur Google Cloud. Jusqu’à présent, certains accès reposaient sur des comptes de service, des identités synchronisées et des clés renouvelées manuellement. Cette structure est devenue plus difficile à justifier à mesure que l’usage s’est étendu.

Le distributeur relie désormais directement Microsoft Entra ID à Google Cloud par l’intermédiaire de Workforce Identity Federation. Le système valide l’identité d’entreprise existante d’un développeur au moment de l’accès. Il ne nécessite pas que Google maintienne une copie synchronisée de chaque dossier des collaborateurs.

Ce changement peut ressembler à un projet de modernisation des identités. Son enjeu plus large est de savoir si Best Buy peut étendre son IA dans le cloud sans multiplier les identifiants, la charge administrative et les enregistrements d’audit ambigus. L’ancien modèle considérait l’accès comme un élément que les équipes devaient provisionner et maintenir. Le nouveau le traite comme une relation de confiance active.

Cette distinction met sous pression le modèle établi des comptes de service. Elle illustre également un affrontement plus large entre les annuaires cloud synchronisés et la fédération directe des identités. Best Buy parie que son système d’identité Microsoft peut rester le point de contrôle pendant que les employés utilisent les services de données et d’IA d’un autre fournisseur.

Best Buy a supprimé la couche d’identifiants qui freinait l’expansion

Le changement immédiat de Best Buy était simple, mais important : les développeurs accèdent désormais à Google Cloud en tant qu’employés identifiables, plutôt que de se dissimuler derrière des identifiants partagés de comptes de service.

Best Buy a décrit le projet dans une annonce du 28 juillet. Le distributeur a indiqué que l’essor de ses activités d’analytique et d’IA créait deux problèmes liés. Il devait réduire les risques liés aux identifiants tout en évitant les frictions administratives associées à la synchronisation de milliers d’utilisateurs backend.

L’entreprise exploitait historiquement des pipelines de synchronisation qui copiaient les identités backend depuis Microsoft Entra ID vers Google Cloud. Entra ID est le fournisseur d’identité d’entreprise existant de Best Buy ; il authentifie les employés et applique les politiques d’accès de l’entreprise.

Best Buy utilisait Cloud Identity sans déploiement de Google Workspace. Cette configuration obligeait l’organisation technologique à trouver un pont pratique entre sa main-d’œuvre gérée par Microsoft et sa collection croissante de ressources cloud.

L’accès à BigQuery depuis Power BI a révélé les limites de l’ancienne organisation. BigQuery est la plateforme de données gérée de Google pour les charges de travail d’analytique et d’IA. Les utilisateurs passant par Power BI s’appuyaient auparavant sur des identifiants de comptes de service pour s’y connecter.

Un compte de service représente une application ou un processus plutôt qu’un employé nommé. Il peut convenir à des charges de travail logicielles, mais il affaiblit la responsabilité individuelle lorsque plusieurs personnes utilisent sa clé pour un accès interactif.

Chaque clé à longue durée de vie devient également un élément que quelqu’un doit émettre, stocker, suivre, renouveler et, à terme, révoquer. Best Buy a indiqué que ses équipes de sécurité et de plateforme devaient savoir quels identifiants possédait chaque équipe. Elles devaient aussi tenir compte de la possibilité qu’une clé apparaisse dans un message de chat ou dans un autre emplacement non contrôlé.

Il ne s’agit pas de simples désagréments administratifs isolés. Chaque identifiant supplémentaire crée une nouvelle voie qui doit rester protégée tout au long de son cycle de vie. La croissance augmente à la fois le nombre de ces voies et les conséquences de la perte de suivi de l’une d’elles.

La nouvelle architecture de Best Buy retire cette clé intermédiaire du flux d’accès des employés. Un développeur se connecte avec une identité Entra ID existante. Workforce Identity Federation établit ensuite la relation de confiance entre le système d’identité de Microsoft et les contrôles de ressources de Google.

Le développeur peut accéder à BigQuery via Power BI ou utiliser des appels API directs. Google Cloud enregistre l’activité sous l’identité individuelle plutôt que sous un compte de service partagé. Les équipes de sécurité obtiennent ainsi une réponse plus claire lorsqu’un audit demande qui a accédé à un jeu de données ou modifié une ressource.

Best Buy affirme que cette architecture peut prendre en charge des dizaines de milliers d’utilisateurs. L’entreprise étend désormais le modèle à une main-d’œuvre plus large, à mesure que les services cloud prennent davantage d’importance dans ses activités de distribution.

Cette affirmation d’expansion doit encore être étayée par des résultats mesurés. Best Buy n’a pas publié de taux d’adoption, de durée de migration, de réductions d’incidents ou d’économies administratives. Toutefois, le changement d’architecture supprime une contrainte évidente avant l’arrivée de ces utilisateurs.

Pour les responsables technologiques, cette séquence est importante. Best Buy n’a pas attendu que l’administration des identités devienne un goulot d’étranglement encore plus important. L’entreprise a modifié le modèle d’accès avant d’ajouter une nouvelle vague massive d’utilisateurs et de charges de travail.

Pourquoi l’IA de Google Cloud a rendu la dette d’identité plus difficile à ignorer

L’expansion de l’IA n’a pas créé la dette d’identité de Best Buy, mais elle a rendu cette dette beaucoup plus coûteuse à supporter.

L’analytique avancée dépend d’un accès étendu aux données, aux environnements de développement, aux modèles et aux API de support. Les projets d’IA ajoutent davantage d’équipes, d’expériences et d’automatisation à cet environnement. Un processus de gestion des identifiants qui fonctionne pour un petit groupe de données peut échouer lorsque la participation atteint l’échelle de l’entreprise.

La pression s’exerce d’abord sur les équipes de sécurité et de plateforme de Best Buy. Elles doivent permettre aux développeurs de travailler rapidement sans perdre le contrôle des données sensibles du distributeur. Elles doivent également conserver des preuves montrant quelle personne a effectué chaque action.

Les comptes de service partagés créent une tension entre ces exigences. Ils peuvent simplifier une connexion initiale parce qu’une équipe reçoit une identité technique unique. Pourtant, ce même raccourci réduit l’attribution individuelle et introduit un secret à longue durée de vie qui doit rester protégé.

Le renouvellement ne supprime pas ce problème. Il le transforme en processus opérationnel récurrent. Les équipes doivent distribuer les clés de remplacement, mettre à jour les outils dépendants, supprimer les anciennes copies et confirmer que les flux de production fonctionnent toujours.

Un identifiant expiré peut interrompre le travail. Un identifiant divulgué peut exposer des ressources. Un identifiant oublié peut rester utilisable après la disparition du besoin métier initial.

Google conseille aux organisations de choisir une alternative plus sûre lorsque cela est possible, car les clés de comptes de service exigent une protection rigoureuse. Ses conseils sur les identités de charge de travail présentent la fédération comme le modèle privilégié pour les charges de travail logicielles externes.

Le cas d’usage de Best Buy concerne des identités de collaborateurs plutôt que des charges de travail machines, mais le principe de sécurité est similaire. Les secrets à longue durée de vie déplacent la responsabilité vers le stockage et le renouvellement. L’accès fédéré repose sur des jetons de courte durée et une relation de confiance explicite.

Cette évolution devient plus importante à mesure que l’accès aux données s’étend au-delà d’une équipe cloud centrale. Les analystes peuvent interroger BigQuery via des outils de business intelligence familiers. Les développeurs peuvent accéder directement aux API. De futures applications d’IA peuvent faire entrer des équipes opérationnelles supplémentaires dans le même environnement.

La couche d’identité devient donc un élément de la planification des capacités d’IA. Davantage de puissance de calcul et de meilleurs modèles apportent peu si chaque nouvel utilisateur exige un enregistrement parallèle, un identifiant géré manuellement et une exception supplémentaire dans un processus d’audit.

La décision de Best Buy préserve également une expérience de main-d’œuvre centrée sur Microsoft. Les employés continuent de s’authentifier avec leurs identifiants d’entreprise familiers. Le distributeur n’a pas besoin de faire d’un second magasin d’identités la source de vérité quotidienne pour ces utilisateurs.

C’est là que Google Cloud subit sa propre pression. Les clients entreprises évoluent fréquemment dans des environnements technologiques mixtes. Un distributeur peut utiliser Microsoft pour l’identité de sa main-d’œuvre et la business intelligence tout en choisissant Google pour le traitement des données ou l’IA.

Les fournisseurs cloud ne peuvent pas supposer que remporter une charge de travail d’IA implique également de remplacer le fournisseur d’identité du client. Ils doivent accepter les identités externes sans affaiblir leurs propres systèmes d’autorisation et d’audit.

Google présente la fédération de main-d’œuvre comme ce pont. Elle prend en charge SAML et OpenID Connect, deux normes d’échange d’informations d’identité entre fournisseurs. Elle peut également mapper des attributs externes dans les politiques d’accès aux ressources.

Le résultat va au-delà de l’authentification unique. L’authentification unique rend l’expérience de connexion familière. La fédération doit aussi traduire une identité de confiance en autorisations que Google Cloud peut évaluer pour une ressource précise.

Pour Best Buy, le test pratique consiste à déterminer si ce modèle suit le rythme de l’adoption de l’IA. Chaque nouveau jeu de données, projet et application introduit une nouvelle décision d’autorisation. La fédération supprime les identifiants dupliqués, mais elle ne supprime pas la nécessité de prendre ces décisions avec soin.

La fédération Google Cloud remplace la synchronisation par une confiance en temps réel

Le mécanisme central est une validation sans état : Google vérifie un jeton Entra ID au moment de l’accès au lieu de maintenir un annuaire de main-d’œuvre en double.

Workforce Identity Federation crée une relation de confiance entre une organisation Google Cloud et un fournisseur d’identité externe. Entra ID authentifie l’employé. Google évalue ensuite le jeton obtenu et associe ses revendications à une identité reconnue par ses politiques d’accès.

Un jeton est une déclaration numérique signée contenant des informations d’identité et une durée de validité limitée. Google valide cette déclaration au moment de l’accès. Best Buy n’a plus besoin d’un enregistrement utilisateur synchronisé côté Google pour chaque employé fédéré.

C’est le renversement essentiel du projet. L’ancien système copiait des identités dans un autre environnement puis tentait de maintenir ces copies à jour. Le nouveau système demande des preuves au fournisseur faisant autorité chaque fois qu’une personne sollicite un accès.

La synchronisation introduit plusieurs problèmes de temporalité. Un nouvel employé peut attendre un cycle de provisionnement avant de recevoir un accès. Un changement de rôle peut ne pas apparaître immédiatement. L’enregistrement copié d’un employé parti peut persister jusqu’à ce qu’un autre système le supprime.

La fédération directe réduit ces écarts précis, car Entra ID reste responsable de l’authentification et du cycle de vie des utilisateurs. Si Best Buy révoque l’accès d’un employé dans ce système, l’entreprise n’a pas besoin de localiser et de renouveler une clé personnelle distincte dans Google Cloud.

Google continue de gouverner les autorisations au sein de sa plateforme. L’authentification répond à la question de savoir qui est la personne. L’autorisation détermine ce que cette personne peut faire après que Google a accepté son identité.

Best Buy peut mapper les attributs et groupes Entra ID dans les règles d’accès Google Cloud. Cette approche prend en charge des politiques fondées sur le contexte de l’entreprise plutôt que sur l’émission d’un identifiant distinct pour chaque connexion.

L’entreprise obtient également des enregistrements d’audit plus utiles. Au lieu de voir une action attribuée à une identité de service partagée, les administrateurs peuvent l’associer à l’employé qui l’a initiée. Cette distinction aide lors des enquêtes, des revues d’accès et du reporting de conformité.

Sans état ne signifie pas sans configuration. Best Buy a dû établir des pools d’identités, des fournisseurs, des mappages d’attributs et des politiques d’accès. Un pool d’identités de main-d’œuvre regroupe des identités externes afin que les administrateurs puissent contrôler leur accès aux ressources cloud.

Le distributeur a également fait deux choix d’implémentation qui révèlent la complexité opérationnelle du projet. Il a séparé le provisionnement et l’authentification unique dans des applications d’entreprise Entra ID distinctes. Cela évite que des changements apportés à une fonction n’affectent de manière inattendue l’autre.

Best Buy a également placé le compte de service d’approvisionnement Entra ID dans une unité organisationnelle distincte et désactivé l’authentification unique pour cette unité. Sans cette exception, l’application globale de l’authentification unique pourrait bloquer le compte nécessaire à la configuration de l’approvisionnement.

Ce problème d’amorçage est facile à négliger. Une politique d’identité peut empêcher l’automatisation même requise pour établir l’environnement qui soutient cette politique. Best Buy a évité cette boucle en isolant l’identité d’automatisation.

Les développeurs voient beaucoup moins cette mécanique. Ils s’authentifient une seule fois avec leurs identifiants Microsoft, puis utilisent Power BI ou des API directes. La valeur du système vient en partie du fait qu’il masque cette frontière cloud supplémentaire dans leur flux de travail quotidien.

Cette invisibilité ne doit pas être confondue avec un contrôle réduit. La couche d’accès de Google décide toujours si le principal fédéré peut utiliser BigQuery ou un autre service pris en charge. Les journaux d’audit cloud peuvent enregistrer l’activité de la personne sous ce principal.

La conception sépare également l’accès utilisateur de l’identité logicielle. Les développeurs humains devraient accéder aux systèmes en leur propre nom chaque fois que cela est possible. Les applications et les charges de travail automatisées nécessitent toujours leurs propres identités, autorisations et contrôles de cycle de vie.

Cette distinction aura son importance à mesure que Best Buy déploiera davantage de systèmes d’IA. Un employé qui interroge des données via Power BI n’est pas le même acteur qu’un processus autonome appelant une API. Tous deux ont besoin d’identités responsables, mais leurs schémas d’accès et leurs garde-fous diffèrent.

La fédération des effectifs résout une partie de ce problème de gouvernance. Elle offre au détaillant une base plus claire pour attribuer la responsabilité humaine avant que l’accès automatisé ne se développe davantage.

Le véritable débat oppose la fédération aux annuaires dupliqués

Best Buy a choisi la fédération directe plutôt que des enregistrements d’identité dupliqués, mais le marché cloud dans son ensemble prend toujours en charge les deux modèles.

La synchronisation d’annuaire copie les utilisateurs et les groupes d’un système faisant autorité vers un annuaire de destination. Elle donne à la destination une représentation locale de chaque identité. De nombreuses plateformes d’entreprise utilisent ce modèle, car les enregistrements locaux simplifient les attributions et l’intégration des applications.

La faiblesse apparaît à grande échelle et lors des changements. Les copies doivent rester alignées sur leur source. Les retards d’approvisionnement, les mises à jour échouées, les attributs modifiés et les comptes obsolètes créent une charge de travail ayant peu de lien avec la valeur métier d’une application d’IA.

Best Buy avait déjà connu cette friction administrative. Les équipes technologiques de l’entreprise maintenaient des pipelines pour déplacer les identités backend d’Entra ID vers Google Cloud. Son nouveau modèle évite de maintenir ces enregistrements dans Cloud Identity pour les utilisateurs fédérés.

La fédération directe déplace la dépendance. Au lieu de dépendre d’un pipeline de synchronisation, l’accès dépend d’Entra ID, de l’échange de jetons, de la configuration du fournisseur et du chemin de validation de Google.

Il ne s’agit pas d’éliminer la complexité. C’est une décision sur l’endroit où cette complexité doit résider. Best Buy préfère une frontière de confiance en temps réel à des milliers d’identités dupliquées et à des clés de comptes de service destinées aux employés.

D’autres fournisseurs cloud font des compromis comparables. AWS recommande la fédération pour l’accès humain, mais sa documentation IAM Identity Center indique que les utilisateurs et groupes externes doivent généralement être approvisionnés avant que les administrateurs ne réalisent des attributions.

AWS peut se connecter à Microsoft Entra ID via SAML, tandis que System for Cross-Domain Identity Management gère l’approvisionnement. Son modèle d’identité externe permet aux employés d’utiliser leurs identifiants d’entreprise, mais conserve une connaissance synchronisée des utilisateurs et groupes au sein d’IAM Identity Center.

Cela crée un contraste utile avec l’implémentation Google de Best Buy. Les deux approches évitent d’attribuer à chaque employé un mot de passe cloud natif permanent. Elles diffèrent toutefois par la quantité d’état d’identité que la plateforme cloud maintient.

Microsoft applique le même principe de réduction des secrets aux identités machine. Ses conseils sur les identifiants fédérés recommandent la fédération ou les certificats plutôt que les secrets clients pour les charges de travail externes.

Ces exemples montrent que l’orientation du secteur reste cohérente même lorsque les implémentations diffèrent. Les fournisseurs cloud encouragent de plus en plus les identifiants temporaires et fédérés. Ils font néanmoins des choix différents en matière d’approvisionnement, d’annuaires locaux, de mappage d’attributs et de couverture des services.

Pour les acheteurs d’entreprise, la comparaison pertinente n’est pas de savoir quel fournisseur propose une fonctionnalité de fédération. Tous les grands fournisseurs en proposent plusieurs formes. Les questions importantes concernent la façon dont l’état d’identité circule, l’emplacement des politiques et ce qui se passe lorsqu’une dépendance échoue.

Un annuaire synchronisé peut préserver des informations utilisateur locales lors de certaines perturbations externes. Il peut également laisser subsister des informations obsolètes. Une conception fédérée sans état évite ces copies, mais dépend plus directement du fournisseur source lors de l’authentification.

Aucune architecture ne supprime le besoin d’accès d’urgence. Les administrateurs ont toujours besoin d’un chemin étroitement contrôlé pour les incidents impliquant un fournisseur d’identité indisponible, une configuration de fédération endommagée ou des modifications de politique erronées.

Le cas Best Buy concerne donc moins Google qui vainc Microsoft. Microsoft reste l’autorité qui authentifie les effectifs du détaillant. Google devient plus utilisable parce qu’il accepte cette autorité sans exiger un autre magasin d’utilisateurs.

Cette configuration reflète la manière dont les grandes organisations achètent réellement la technologie. Elles assemblent des services cloud, d’identité, d’analytique et de productivité provenant de plusieurs fournisseurs. Une conception d’accès qui exige qu’un fournisseur possède chaque couche introduit un travail de migration et des résistances.

Google y gagne lorsque des employés gérés par Microsoft peuvent accéder à BigQuery sans adopter une autre identité quotidienne. Microsoft conserve sa place dans le cycle de vie des employés. Best Buy réduit le nombre d’identifiants que ses équipes doivent gouverner.

Le compte de service perd son rôle inapproprié de substitut à un accès humain nominatif. C’est le principal adversaire de cette histoire, et non un autre fournisseur cloud.

Pour les développeurs, cette frontière améliore également la documentation opérationnelle. Lorsqu’un rapport d’incident identifie la personne, le projet et la ressource affectée, les équipes peuvent créer une base de connaissances techniques plus utile. Les identités partagées rendent cet historique plus difficile à interpréter.

Moins de clés ne signifie pas une sécurité automatique

La fédération élimine un risque de gestion des identifiants, mais sa configuration de confiance devient un plan de contrôle à haute valeur que Best Buy doit tester en continu.

Google et Best Buy présentent le nouveau modèle comme une réduction de la surface d’attaque associée aux clés. Cette affirmation est raisonnable sur le plan architectural. Un identifiant qui n’existe plus ne peut pas être copié depuis un ordinateur portable, collé dans une conversation ou oublié dans un dépôt.

Toutefois, l’étude de cas publique n’établit pas une réduction mesurée des incidents de sécurité. Elle ne fournit aucun décompte avant/après des clés exposées, requêtes non autorisées, audits échoués ou délais de rétablissement.

L’article ne divulgue pas non plus le nombre d’utilisateurs déjà migrés. Il indique que l’architecture vise des dizaines de milliers de personnes et que Best Buy étend l’accès à un effectif plus large. Ces déclarations décrivent une capacité et une orientation, non une adoption achevée.

La fédération concentre l’attention sur la validation des jetons et le mappage des politiques. Si les administrateurs font confiance à une revendication trop large, configurent mal une audience ou mappent incorrectement un groupe, un employé valide pourrait recevoir davantage d’accès que prévu.

L’accès fondé sur les attributs peut réduire le travail administratif parce que les politiques suivent les caractéristiques des effectifs. Il peut aussi répartir le risque dans la qualité de ces attributs. Une appartenance erronée à un groupe dans Entra ID peut devenir une erreur d’autorisation dans Google Cloud.

Les équipes de sécurité doivent donc tester les deux côtés de la relation. Elles doivent s’assurer qu’Entra ID émet les revendications attendues. Elles doivent également s’assurer que Google interprète ces revendications exactement comme prévu.

Le principe du moindre privilège reste essentiel. Ce principe n’accorde à chaque identité que les autorisations nécessaires à son travail. La fédération ne détermine pas à elle seule le bon niveau d’autorisation.

Best Buy doit aussi séparer les employés des charges de travail automatisées. L’entreprise a supprimé les clés de comptes de service du flux d’accès développeur décrit. Elle n’a pas affirmé que les comptes de service avaient disparu de chaque application ou processus backend.

Les systèmes d’IA compliquent cette frontière. Un développeur peut lancer une expérimentation, tandis que des pipelines et agents planifiés continuent de fonctionner sans la session active de cette personne. Ces processus nécessitent des identités machine dotées d’autorisations limitées et d’une propriété traçable.

La documentation de Google répertorie les produits qui prennent en charge les identités fédérées et mentionne les limitations propres aux services. Best Buy doit confirmer la compatibilité avant d’étendre cette conception à chaque service cloud impliqué dans ses activités de vente au détail.

La disponibilité présente un autre compromis. Une connexion fédérée dépend de plusieurs composants opérationnels, dont Entra ID, la connectivité réseau, l’échange de jetons de Google et une configuration correcte du fournisseur.

Une perturbation dans cette chaîne peut empêcher l’ouverture de nouvelles sessions. Les organisations ont besoin de comptes d’urgence soigneusement limités ou d’un autre mécanisme de récupération. Ces exceptions nécessitent une surveillance particulièrement stricte, car elles se situent en dehors du chemin d’identité normal.

Le comportement des sessions mérite également un examen attentif. Révoquer une personne dans l’annuaire source devrait bloquer les futures authentifications, mais les jetons ou sessions existants peuvent rester utilisables jusqu’à la fin de leur durée de vie configurée. Des sessions plus courtes réduisent l’exposition, mais exigent des renouvellements plus fréquents.

L’auditabilité s’améliore lorsque les actions sont associées à des identités nominatives. Pourtant, les journaux ne sont utiles que si les équipes les conservent, les surveillent et les examinent. Best Buy a toujours besoin d’alertes qui distinguent l’activité analytique normale des exportations inhabituelles, des modifications d’autorisations ou des schémas d’accès atypiques.

Il existe aussi une question de gouvernance concernant l’accès aux données d’IA. L’identité peut prouver quel employé a accédé à un jeu de données. Elle ne peut pas décider si ce jeu de données était approprié pour un modèle, un prompt ou une expérimentation donnés.

La classification des données, la gouvernance des modèles et les contrôles de confidentialité restent des responsabilités distinctes. La fédération rend l’application des règles plus attribuable, mais elle ne crée pas les règles sous-jacentes.

L’étude de cas provient de Google Cloud et d’un responsable de l’ingénierie cloud de Best Buy. Elle doit être lue comme un témoignage officiel de client, et non comme une évaluation indépendante de la sécurité.

La conclusion la plus solide est donc plus nuancée que le message marketing. Best Buy a supprimé les identifiants partagés de longue durée d’un important modèle d’accès. Cela donne à son organisation de sécurité moins de secrets à gérer et une attribution utilisateur plus claire.

La maîtrise du résultat à pleine échelle dépendra des revues d’accès, de la qualité des politiques, de la couverture des services et des performances lors des incidents. Ces résultats n’ont pas encore été publiés.

Trois signaux montreront si le modèle passe à l’échelle

Le prochain test sera constitué de preuves opérationnelles : une adoption plus large doit préserver la responsabilité individuelle sans recréer ailleurs la charge administrative.

Le premier signal est le pourcentage des effectifs visés par Best Buy qui utilisent la fédération pour un accès cloud actif. L’entreprise indique qu’elle étend l’architecture, mais n’a fourni ni calendrier de migration ni indicateur d’achèvement.

Un déploiement large avec peu d’exceptions renforcerait l’argument en faveur d’une identité des effectifs sans état à l’échelle du commerce de détail. Une collection croissante d’exceptions de comptes de service suggérerait que la compatibilité des outils ou la conception des flux de travail demeure une contrainte.

La mesure utile n’est pas simplement le nombre d’utilisateurs inscrits. Best Buy devrait examiner combien de connexions interactives dépendent encore d’identifiants de longue durée. L’entreprise devrait également suivre la rapidité avec laquelle les nouveaux employés, les transferts et les départs reçoivent les droits d’accès appropriés.

Le deuxième signal concerne la qualité des résultats en matière d’autorisation et d’audit. Les accès nominatifs devraient réduire les entrées de journal ambiguës et accélérer les enquêtes. Best Buy n’a pas publié d’éléments montrant si ces améliorations se sont concrétisées.

Les équipes de sécurité devraient surveiller les mappages d’attributs incorrects, les autorisations inattendues, les échanges de jetons échoués et les accès qui subsistent après des changements d’emploi. Une diminution du travail manuel de rotation des clés confirmerait que la fédération a supprimé une dette opérationnelle plutôt que de la déplacer.

Une hausse des erreurs d’autorisation affaiblirait la promesse centrale du déploiement. Ce résultat pourrait indiquer que la synchronisation des identités a été remplacée par une maintenance des politiques tout aussi difficile.

Le troisième signal concerne la manière dont le distributeur gère les accès IA non humains. La fédération de l’identité des employés concerne les salariés et les autres utilisateurs humains. Les agents IA, pipelines, notebooks et tâches planifiées ont toujours besoin d’identités machine distinctes.

Une extension mature maintiendrait ces identités machine séparées de celles des employés, tout en reliant chacune à un propriétaire, un objectif et un périmètre d’autorisations. Elle éviterait de revenir aux clés téléchargeables simplement parce que les systèmes automatisés ont besoin d’un accès sans surveillance.

C’est là que le projet de Best Buy peut influencer d’autres entreprises. Le précédent important n’est pas que les employés bénéficient d’une authentification unique. Les entreprises proposent cette expérience depuis des années.

Le précédent est qu’une entreprise peut conserver son autorité d’identité Microsoft existante tout en étendant ses capacités d’analytique et d’IA sur la plateforme de Google. Elle peut le faire sans interposer un autre identifiant de longue durée entre l’employé et la ressource cloud.

Si le déploiement réussit, la fédération d’identités devient une couche facilitatrice de l’adoption de l’IA multicloud. Les responsables technologiques peuvent choisir des services de données et de modèles sans créer un nouveau répertoire d’employés pour chaque plateforme.

S’il rencontre des difficultés, les problèmes les plus probables apparaîtront dans les exceptions, les mappages de politiques, les limites des services et les procédures de reprise. Ces détails déterminent si l’architecture fonctionne au-delà d’un cas d’usage BigQuery soigneusement sélectionné.

Pour les développeurs, le résultat immédiat est plus facile à percevoir. Ils conservent leur connexion d’entreprise habituelle, tandis que les journaux d’audit peuvent identifier leurs actions. Ils n’ont plus besoin de considérer une clé partagée comme le prix à payer pour accéder aux données cloud.

Pour les équipes de sécurité, le travail change plutôt qu’il ne disparaît. Elles gèrent les relations de confiance, les attributs d’accès, les règles de session, les voies d’urgence et les identités machine. Ces contrôles sont plus centralisés, mais les erreurs peuvent toucher une population plus large.

Pour les acheteurs en entreprise, la décision de Best Buy offre une question d’évaluation concrète : une plateforme cloud accepte-t-elle les identités qui régissent déjà votre personnel, ou exige-t-elle un autre répertoire et un autre processus de gestion du cycle de vie ?

Best Buy a choisi la première voie pour son expansion sur Google Cloud. L’architecture supprime un obstacle connu avant que l’usage de l’analytique et de l’IA ne s’étende à un plus grand nombre d’employés. Les prochains mois devraient révéler si l’adoption, la qualité des audits et les contrôles des identités machine justifient cette confiance.

Les organisations envisageant la même évolution devraient commencer par examiner leurs propres données d’accès. Identifiez les endroits où les humains utilisent encore des clés de comptes de service, déterminez quels services cloud acceptent les identités fédérées et mesurez la rapidité avec laquelle la révocation atteint les sessions actives. La fédération Google Cloud devient précieuse lorsque ces résultats s’améliorent, et pas seulement lorsque l’écran de connexion change.