Résumé

  • Le transfert d’un projet Google Cloud vers une autre organisation conserve son compte de facturation d’origine ; les droits hérités, eux, changent.
  • Le transfert de commandes actives achetées directement sur Cloud Marketplace réclame l’accord du client et de l’éditeur, puis un traitement par Google.
  • Pendant cette procédure, acheter un produit du même fournisseur sur le compte destinataire rend le transfert impossible. La passation doit aussi organiser les achats.

La facture a parfois davantage de fidélité que l’organigramme. Chez Google Cloud, un projet peut rejoindre une nouvelle organisation sans quitter le compte qui finançait son fonctionnement. La direction informatique dispose alors d’une preuve impeccable du transfert administratif. La direction financière de l’ancienne maison continue de recevoir les dépenses.

Ce décalage est inscrit dans le produit. Le guide de migration des projets précise que le déplacement modifie les métadonnées désignant le parent du projet. Son identifiant, son numéro, ses données et ses ressources restent les mêmes. Les rôles IAM attribués directement au projet restent également en place, tout comme le compte de facturation. Les comptes Cloud Billing peuvent financer des projets appartenant à différentes organisations.

Une cession d’activité rencontre ainsi un problème plus fin que le déplacement de machines : plusieurs personnes peuvent avoir terminé leur travail sans que l’activité soit autonome. Le nouvel administrateur a reçu le projet. Le nouveau payeur n’a pas forcément accepté la dépense. L’éditeur du logiciel peut encore devoir accepter le transfert de la commande. Chaque métier possède une pièce du dossier ; aucun écran ne les réunit magiquement.

La commande attend une réponse, pas un administrateur plus puissant

Le passage le plus révélateur se trouve dans les règles de changement de compte des commandes Marketplace. Pour un produit acheté directement sur Cloud Marketplace, le client, doté du rôle Billing Account Administrator, contacte l’éditeur. Si celui-ci accepte, il transmet la demande à Google. Google la traite et adresse les courriels d’approbation ; les parties concernées doivent répondre favorablement avant la finalisation et sa notification.

L’opération peut prendre une semaine ou davantage. Une semaine constitue donc une indication de délai possible, pas une promesse de livraison. Il faut aussi que le transfert soit réalisable. Le travail a quitté le domaine où un administrateur pourrait tout régler en obtenant un rôle supplémentaire.

La consigne destinée aux achats mérite sa place dans le calendrier de séparation : durant le transfert, un achat de produit auprès du même fournisseur sur le compte destinataire rend l’opération impossible. Le périmètre porte sur le fournisseur, pas seulement sur le produit déjà acheté.

Voilà une curieuse façon de rater une passation : équiper trop vite la nouvelle société. Le service achats peut vouloir lui donner ses propres contrats tandis qu’une autre équipe tente de lui transmettre les anciens. Chacune avance ; ensemble, elles changent les conditions de faisabilité. Le coût d’une mauvaise coordination se loge ici dans l’ordre des décisions, bien avant de figurer dans une facture.

Le guide de gestion de la facturation Marketplace exige que le compte destinataire ait acheté les ressources nécessaires au projet et prévoit des avertissements dans la console lorsqu’il manque des achats. Le guide de facturation des projets demande, lui, de transférer les achats associés avant de changer le compte du projet. Un projet n’est lié qu’à un compte de facturation à la fois. Le montage commercial doit donc être préparé, pas découvert au moment du basculement.

Le payeur conserve une fonction vitale

Le déplacement administratif a ses propres effets sur les accès. Les droits IAM hérités de l’ancienne organisation disparaissent ; les politiques de la nouvelle s’appliquent. Les rôles attribués directement au projet survivent au déplacement. Conserver les ressources ne dispense donc pas d’examiner les permissions et les dépendances qui permettent aux applications de fonctionner.

Le guide des rôles nécessaires à la migration distingue les autorisations permettant de déplacer le projet de celles nécessaires au changement de facturation. Pour ce dernier, il mentionne notamment Billing Account User sur le compte destinataire et Project Billing Manager sur le projet. La documentation spécialisée détaille aussi les droits de consultation, de dissociation et d’association. Pouvoir déplacer un projet n’équivaut pas à pouvoir engager le nouveau compte.

Surtout, le financement n’est pas une étiquette décorative. Selon la documentation de facturation des projets, le compte lié doit être actif et en règle pour que la facturation soit activée. S’il est fermé ou suspendu, les services activés deviennent inutilisables, y compris ceux qui remplissent les conditions de gratuité.

L’ancienne maison peut donc rester un maillon du fonctionnement alors que le projet figure déjà chez la nouvelle. Son rôle financier ne lui confère pas, à lui seul, des permissions IAM. C’est précisément cette dissociation qui compte : l’autorité administrative et la condition de financement peuvent être situées de part et d’autre de la séparation.

Les avantages commerciaux ne suivent pas tous le panneau de sortie

Changer ensuite le compte de facturation ne produit pas une coupure comptable sans queue. Les dépenses engagées avant le changement restent imputées à l’ancien compte, même si elles n’ont pas encore été déclarées. Selon le service, la remontée peut prendre jusqu’à deux jours. Il s’agit du retard de déclaration de consommations anciennes, pas de deux jours supplémentaires de consommation nouvelle facturés à l’ancien payeur.

D’autres coûts appartiennent au compte plutôt qu’à un projet, notamment Support. Une liste de projets vide ne suffit donc pas à prouver la disparition de toutes les dépenses du compte.

Le déplacement peut aussi toucher ceux qui restent. Pour les engagements Compute Engine fondés sur les ressources présents dans le projet dont on change la facturation, les remises s’appliquent au compte destinataire et cessent de bénéficier aux projets de l’ancien compte. Le partage des remises dans le nouvel ensemble dépend de ses paramètres. Une économie intégrée au budget d’une activité conservée peut ainsi partir avec une autre activité.

Le cas de Cloud Armor Enterprise Annual est tout aussi concret : si le compte destinataire ne dispose pas de cet abonnement annuel, le projet revient à Standard. Les ressources ont conservé leur identité ; les conditions commerciales ont changé de niveau.

Google avait déjà exposé cette logique dans son analyse des architectures de séparation d’activités du 2 mai 2023. Avec les sociétés fictives RemainCo et NewCo, le texte envisage de conserver le financement par le compte initial afin de respecter un engagement contractuel existant. Crédits promotionnels et offres de support ne s’étendent pas automatiquement à la nouvelle société ou au nouveau compte.

Garder l’ancien payeur peut donc constituer une décision économique parfaitement délibérée. L’essentiel est de savoir si cette dépendance a été négociée. Pour trancher le cas d’une entreprise précise, il faudrait ses droits IAM, ses associations de facturation, ses achats et ses approbations ; ces pièces ne figurent pas dans les règles publiques.

Le bon acte de passation fait accepter les relations qui subsistent. Une capture de l’organigramme montre où se trouve le projet. Elle ne dit ni qui finance son prochain mois, ni qui a consenti à lui transmettre le logiciel dont il dépend. Pour ces réponses-là, il faut encore parler aux gens qui peuvent dire oui.