Vous administrez un tenant Microsoft 365, Copilot Cowork vient de passer en GA, et vous voulez faire les choses bien : poser une spending policy pour cadrer la dépense avant d’ouvrir les vannes. Sauf que votre tenant est onboardé dans le programme CSP, et là, sur la page Cost management, votre compte Global Admin se prend une bannière « managed by your solution provider » en pleine figure.

On part d’un Global Admin permanent qui devrait tout pouvoir, et on déroule, capture après capture, pourquoi il est bloqué, pourquoi un License Admin se mange un 403, et pourquoi (c’est le clou) un Global Admin activé en just-in-time via PIM, lui, passe. Et tant qu’à parler d’incohérences, j’en ai relevé une seconde, côté licence, que je partage en fin d’article.

Pour vous guider plus facilement dans cet article, voici des liens rapides :

• 1. Le contexte en deux lignes
• 2. Le symptôme : avant et après l’onboarding CSP
• 3. Ce n’est pas un problème de rôle
• 4. Le License Administrator : l’assistant va au bout, puis 403
• 5. Le contournement qui marche : Global Admin en JIT via PIM
• 6. Première incohérence : Global Admin permanent contre JIT
• 7. Seconde incohérence : Cowork sans licence Microsoft 365 Copilot
• 8. Mes questions ouvertes à Microsoft
• 9. Récap : la checklist si vous êtes en CSP

Si vous débarquez sur le sujet des Copilot Credits et des spending policies, je vous renvoie d’abord à mon article précédent qui pose tout le décor de la facturation à l’usage de Cowork : Copilot Cowork passe en PAYG. Ici, on attaque un cas plus tordu, observé sur des tenants CSP.

1. Le contexte en deux lignes

Pour rappel, depuis la GA du 16 juin 2026, l’usage de Copilot Cowork se facture à la consommation en Copilot Credits, et tout se pilote depuis le centre d’administration Microsoft 365, menu Copilot puis Cost management. Le geste fondateur côté admin, c’est la création d’une spending policy : c’est elle qui décide qui peut dépenser des crédits, combien, et sur quelle méthode de facturation. Sans elle, rien ne s’active. J’ai détaillé toute cette mécanique dans l’article cité plus haut.

Le problème que je vous décris ici n’apparaît que sur les tenants passés sous gestion CSP (Cloud Solution Provider). Toutes les captures qui suivent ont été anonymisées : le tenant est nommé contoso, et le second compte d’administration admin2. La logique observée, elle, est strictement celle de mon lab.

2. Le symptôme : avant et après l’onboarding CSP

Commençons par l’état sain. Connecté avec mon compte Global Admin, j’ouvre Copilot puis Cost management. Tout est normal : l’expérience de facturation à l’usage est disponible, le bouton Get started m’est proposé, aucune restriction à l’horizon.

Maintenant, le tenant est onboardé dans le programme CSP. Même compte, même page, même navigateur. Et la page a changé de visage : une bannière s’affiche pour me dire que mon organisation est gérée par un solution provider, et que la gestion des Copilot Credits doit être configurée par ce provider. Plus de Get started, plus de configuration possible de mon côté.

La seule variable qui a changé entre les deux captures, c’est l’onboarding CSP. Pas le compte, pas le rôle, pas la page. C’est donc bien le CSP qui déclenche le blocage.

3. Ce n’est pas un problème de rôle

Premier réflexe quand un admin se fait jeter : vérifier le rôle. Direction le centre d’administration Microsoft Entra. Et c’est sans appel : mon compte porte bien le rôle Global Administrator, en assignation active, directe et permanente. Le plus haut niveau de privilège du tenant.

Le blocage de l’étape 2 n’est donc pas une histoire de droits insuffisants. Un Global Admin permanent reste bloqué. On tient là le premier vrai mystère.

4. Le License Administrator : l’assistant va au bout, puis 403

Deuxième piste : et si je tentais avec un rôle moins privilégié, par bonne hygiène de moindre privilège ? Je crée un second compte, admin2, à qui j’attribue uniquement le rôle License Administrator, en permanent.

Bonne surprise au premier abord : connecté en License Admin, l’onglet Configuration de Cost management se charge, et le bouton Add spending policy est bien là :

Un message transitoire passe au chargement, « We couldn’t load your latest policies from the admin service », mais l’assistant s’ouvre :

Je remplis le wizard de bout en bout : nom de la policy, périmètre All users, services Copilot Cowork et Work IQ API, méthode de facturation pay-as-you-go sur une souscription Azure dédiée, plafond mensuel et alertes. Tout passe, écran après écran. Puis je clique sur Create spending policy, et là, le couperet :

Le message est explicite : « Failed to create Copilot Credits billing plan: Request failed with status 403 ». L’assistant m’a laissé tout remplir pour échouer à la toute dernière étape. Frustrant, mais en fait, la documentation Microsoft éclaire ce point précis.

La page Microsoft Learn sur la gestion de la facturation à l’usage distingue deux familles de rôles. Les rôles AI Administrator et License Administrator peuvent créer des spending policies, gérer les limites et les alertes, et consulter le tableau de bord. Mais pour la méthode de facturation, c’est une autre histoire :

They can’t set or modify the billing method.

Source : Managing AI experiences enabled by usage-based billing, Microsoft Learn

Définir ou modifier la méthode de facturation est réservé aux rôles Global Administrator et Billing Administrator. Or créer une policy en pay-as-you-go, c’est précisément rattacher une méthode de facturation. D’où le 403 à l’étape finale : le License Admin pouvait dérouler le wizard, mais pas poser le billing plan.

5. Le contournement qui marche : Global Admin en JIT via PIM

Le 403 du License Admin s’explique. Mais souvenez-vous : mon compte principal, lui, est Global Admin permanent, et il reste bloqué par la bannière CSP. Alors j’ai tenté autre chose sur le second compte. En plus de son License Administrator permanent, admin2 dispose du rôle Global Administrator en éligible via Privileged Identity Management (PIM).

J’active donc Global Administrator en just-in-time pour admin2, de façon limitée dans le temps via PIM :

Le rôle passe à Activated, à côté de l’assignation License Administrator permanente :

Je relance le même assistant Add spending policy, avec exactement les mêmes choix qu’à l’étape précédente. Et cette fois :

« Spending policy created ». La policy s’affiche dans la liste Configuration et s’applique immédiatement aux utilisateurs ciblés. De retour sur mon compte Global Admin principal, je la vois bien active, pour tous les utilisateurs, facturée en pay-as-you-go.

6. Première incohérence : Global Admin permanent contre JIT

Récapitulons le paradoxe, parce que c’est lui le cœur du sujet. Sur le même tenant, contre le même backend, à quelques minutes d’intervalle :

• un Global Administrator permanent est bloqué en amont par la bannière CSP, il ne peut même pas lancer la configuration :

• un License Administrator atteint la dernière étape puis échoue en 403, ce qui s’explique par la frontière de privilège sur le billing :

• un Global Administrator activé en just-in-time via PIM, sur un autre compte, réussit la création de bout en bout :

Le rôle effectif est pourtant le même entre le compte bloqué (Global Admin permanent) et le compte qui réussit (Global Admin JIT). La différence tient au contexte d’activation : permanent contre just-in-time. Mon hypothèse, et je le présente bien comme une hypothèse, c’est que le blocage CSP se joue au niveau du contexte de session ou d’autorisation, pas au niveau du rôle effectif. Comme si les deux chemins ne touchaient pas exactement la même condition côté backend.

7. Seconde incohérence : Cowork sans licence Microsoft 365 Copilot

Le blocage CSP n’est pas la seule bizarrerie que j’ai relevée. En creusant sur plusieurs tenants, je suis tombé sur une seconde incohérence, cette fois côté licence. Dans mon premier article, je posais la licence Microsoft 365 Copilot comme le ticket d’entrée obligatoire de Cowork. C’est d’ailleurs la lecture que Microsoft met en avant dans sa documentation, où la licence sert de point d’entrée vers les services facturés à l’usage :

(…) licenses act as an entry point enabling access to AI services (…)

Source : Usage-Based Billing and Cost Management for Copilot Credits, Microsoft Learn

Sauf que sur le terrain, le tableau est plus flou. Sur plusieurs tenants, j’ai vu Cowork consommer des crédits sans qu’aucune licence Microsoft 365 Copilot ne soit assignée à l’utilisateur. Les crédits étaient tirés soit du pack de capacité apporté par une licence Copilot Studio, soit directement de la souscription Azure en pay-as-you-go. Dans les deux cas, pas de licence Microsoft 365 Copilot sur le compte, et Cowork fonctionne quand même.

J’avais déjà effleuré le sujet dans mon premier article, avec un utilisateur sans licence Microsoft 365 Copilot qui avait quand même pu utiliser Cowork pendant la période de grâce. Ce que je constate maintenant va plus loin : ce n’est pas un simple effet de la période de grâce, et ça se répète sur plusieurs tenants, avec des sources de crédits différentes.

8. Mes questions ouvertes à Microsoft

À ce stade, j’ai des observations solides, captures à l’appui, mais pas toutes les réponses. Voici les cinq questions que je porte à Microsoft, dans l’ordre d’importance :

1. La bannière « managed by your solution provider » est-elle le comportement attendu pour un tenant CSP ? Si oui, quel est le chemin supporté et documenté pour qu’un client CSP (ou son provider) crée et gère ses spending policies Copilot Credits ?
2. Pourquoi un Global Administrator permanent est-il bloqué, alors qu’un Global Administrator activé en just-in-time via PIM sur un second compte réussit, contre le même backend ?
3. Le 403 renvoyé au License Administrator est-il bien le comportement attendu vu la frontière de privilège sur le billing, et le rôle Billing Administrator suffit-il pour la partie méthode de facturation sur un tenant CSP ?
4. La licence Microsoft 365 Copilot est-elle un prérequis strict pour utiliser Cowork, ou un simple point d’entrée parmi d’autres ? J’observe Cowork consommer des crédits, via un pack Copilot Studio ou la souscription Azure, sans aucune licence Microsoft 365 Copilot assignée.
5. Le message « couldn’t load your latest policies from the admin service » était-il une condition transitoire du rollout des 16 et 17 juin, ou est-il lié au blocage CSP ?

9. Récap : la checklist si vous êtes en CSP

Voilà, en quelques étapes, ce qu’il faut avoir en tête si votre tenant Copilot est sous gestion CSP et que vous butez sur la création d’une spending policy.

Concrètement, ça donne quoi ? Sur un tenant CSP, la création d’une spending policy Copilot Credits ne se comporte pas comme sur un tenant classique, et les garde-fous de rôle de Microsoft (moindre privilège côté policy, billing réservé à Global ou Billing Admin) se doublent d’une couche CSP qui, elle, n’est pas documentée à ce jour. Les deux pièges côté CSP : un Global Admin permanent ne vous garantit pas de pouvoir configurer les crédits sur un tenant managé, et le bon rôle pour la facturation reste Billing Administrator, pas Global Admin par défaut. À ça s’ajoute la surprise côté licence : Cowork peut tourner sans licence Microsoft 365 Copilot, en tirant sur des crédits Copilot Studio ou sur le pay-as-you-go Azure, ce qui mérite d’être vérifié de près avant de bâtir votre modèle de coût.

Foncez tester en lab si vous gérez des tenants CSP, et documentez ce que vous voyez : c’est exactement le genre de cas limite qui se précise à mesure que la GA se déploie.

Je complèterai dès que Microsoft me répond.