Une société industrielle de la région nous demande d'expliquer une ligne de facturation Google qu'elle paie chaque mois depuis 2022. En remontant la piste, nous trouvons un projet Google Cloud créé pour une étude de données, à l'époque d'un contrat avec un cabinet extérieur. Le projet existe toujours, il contient un entrepôt de données et deux machines allumées, et il a été créé avec l'adresse personnelle d'une personne qui ne travaille plus dans l'entreprise. Personne n'ouvre plus cette console, mais la facture continue.
Ce scénario dit deux choses. La première est qu'un projet cloud sans propriétaire désigné devient une dépense invisible. La seconde est qu'une confusion très répandue subsiste entre les services Google destinés au travail quotidien et la plateforme d'infrastructure. Google Workspace fournit la messagerie, les documents partagés et le stockage des utilisateurs, comme nous le décrivons dans notre article sur Google Workspace pour une PME. Google Cloud est autre chose : c'est de l'infrastructure et des services de données que vous assemblez, dans des projets qui vous appartiennent, avec une facture à l'usage. Utiliser Gmail professionnel ne signifie pas que votre entreprise exploite Google Cloud.
L'organisation en projets, la première notion à comprendre
Google Cloud structure tout en projets. Un projet regroupe des ressources, ses propres droits et son propre rattachement à un compte de facturation. Cette organisation est claire et elle constitue un vrai avantage quand elle est utilisée volontairement : vous séparez la production de la recette, vous supprimez un projet entier en fin d'expérimentation, et vous savez lire ce que chaque projet coûte sans démêler des ressources mélangées.
Le même mécanisme devient un piège quand les projets naissent au fil des besoins, avec des comptes personnels et sans rattachement à une organisation d'entreprise. Vous obtenez alors une collection de projets dont personne ne connaît le contenu, avec des droits de propriétaire attribués à des adresses privées. Nous plaçons donc les projets sous une organisation liée à votre domaine, avec un compte de facturation au nom de l'entreprise, et nous appliquons les mêmes règles que sur les autres plateformes concernant les comptes à privilèges élevés, décrites dans notre article sur le compte root d'un environnement cloud.
Les comptes de service, un sujet propre à surveiller
Un compte de service est une identité destinée à une application, pas à une personne : votre script de sauvegarde ou votre application web s'authentifie avec cette identité pour accéder à une base ou à un espace de stockage. Le mécanisme est indispensable, et c'est aussi la source de fuite la plus fréquente que nous rencontrons dans cet écosystème, parce que la clé de ce compte se présente sous la forme d'un simple fichier.
Ce fichier finit régulièrement dans un dépôt de code, dans une pièce jointe ou sur le poste d'un prestataire. Nous limitons donc chaque compte de service à un rôle précis plutôt qu'à un droit large, nous préférons les mécanismes d'authentification qui évitent de créer un fichier de clé, et nous imposons une rotation quand un fichier reste nécessaire. Nous inventorions également les clés existantes lors d'une reprise en main, car il en traîne presque toujours plus que prévu.
Quand Google Cloud se justifie, et quand un autre choix est plus sage
Google Cloud se discute sérieusement quand vous avez un besoin de données écrit et mesurable : consolider des exports de plusieurs logiciels métier pour produire des analyses, traiter un volume que votre base de données actuelle ne suit plus, ou faire tourner un traitement lourd quelques heures par semaine. Les services d'entrepôt de données de la plateforme sont facturés selon le volume traité et le stockage conservé, ce qui convient bien à un usage irrégulier et convient mal à un usage mal maîtrisé : une requête écrite sans filtre sur un gros jeu de données peut coûter beaucoup plus que prévu. Nous mettons donc en place des limites et des alertes avant d'ouvrir l'accès aux utilisateurs, dans l'esprit de notre article sur la facture cloud qui augmente.
La plateforme se justifie également quand votre équipe ou votre prestataire la connaît déjà. Une compétence disponible vaut mieux qu'une préférence théorique, et ce critère décide plus souvent que les caractéristiques comparées des catalogues.
En revanche, un site vitrine n'a rien à faire sur une infrastructure de ce type : un hébergement professionnel coûte moins cher et sera mieux tenu. Un parc de dix postes ne relève pas davantage du cloud mais de l'infogérance, à partir de 120 HT / mois. Quant à Kubernetes, disponible ici sous forme de service managé, il ajoute une couche d'exploitation dont peu de PME ont réellement besoin. Nous expliquons pourquoi dans notre article sur Kubernetes trop tôt, et nous montrons dans notre article sur Docker sans orchestrateur qu'une pile de conteneurs documentée rend souvent plus de services qu'un cluster que personne ne surveille. Un service qui exécute un conteneur à la demande, ou une machine virtuelle correctement sauvegardée, suffit à la plupart des applications d'entreprise.
Ranger un projet Google Cloud hérité, sans tout éteindre au hasard
Quand nous reprenons un environnement existant, nous procédons dans un ordre précis, car couper une ressource dont un traitement dépend encore crée plus de problèmes qu'elle n'en résout.
- Nous identifions le compte de facturation, la personne qui en est responsable et la liste complète des projets qui y sont rattachés.
- Nous relevons pour chaque projet les ressources actives et leur consommation réelle, ce qui distingue immédiatement les projets vivants des projets dormants.
- Nous vérifions les propriétaires et les comptes de service, puis nous retirons les droits des personnes qui ne travaillent plus avec vous.
- Nous exportons ce qui doit être conservé avant toute suppression, dans un emplacement indépendant du projet concerné.
- Nous arrêtons ensuite les ressources inutiles par étapes, avec une période d'observation, plutôt qu'en une seule opération.
La localisation des données se traite au même moment. Si un contrat client vous impose une région donnée, cette exigence doit être écrite, et la disponibilité de la région comme celle des services que vous comptez y utiliser se vérifient dans la documentation du fournisseur au moment du projet, car tous les services ne sont pas ouverts dans toutes les régions. La qualification juridique de l'obligation relève d'un conseil spécialisé, et nous en tirons les conséquences techniques.
Notre façon de conduire une mission Google Cloud
Nous commençons par un cadrage court portant sur trois questions : quel usage précis justifie la plateforme, qui paie et qui détient les droits, et qui exploitera l'ensemble dans un an. Nous posons ensuite les fondations, à savoir une organisation rattachée à votre domaine, des droits nominatifs, un réseau fermé par défaut, des sauvegardes séparées des projets qu'elles protègent, des étiquettes de coût et des alertes de budget. Le service métier vient après ces fondations.
Nos missions Google Cloud se facturent 1000 HT / jour, à distance, pour des clients de toute la France et de Suisse, au même montant hors taxes en euros et en francs. Nous proposons ensuite une maintenance cloud régulière ou un transfert de compétences, selon ce que votre entreprise peut tenir. Le choix entre les grands fournisseurs, lui, fait l'objet de notre article sur les critères qui décident pour une PME.
Si vous payez une ligne Google Cloud sans savoir à quoi elle correspond, transmettez-nous vos factures et un accès en lecture. Nous vous dirons ce qu'il faut arrêter, ce qu'il faut conserver et ce qu'il faut déplacer, avec les conséquences de chaque option.