Résumé

  • Une simulation sur une table protégée par la sécurité au niveau des lignes renvoie zéro octet. Google précise que ce résultat ne permet pas d'estimer le coût de façon fiable.
  • Des statistiques restent masquées après exécution : les remplacer par des zéros peut fabriquer de fausses économies dans les comptes internes.

Le zéro a un talent administratif : il passe partout. Dans un tableau de bord, un budget ou une présentation au comité de direction, il demande rarement une explication. Celui que BigQuery affiche lors de certaines simulations en mérite une : il garde un secret.

Pour les tables protégées par la sécurité au niveau des lignes, Google fait systématiquement renvoyer zéro octet aux simulations, afin d'éviter qu'une estimation permette de déduire des informations sur les données cachées. Le guide d'exécution des requêtes précise qu'on ne peut pas s'appuyer sur ce résultat pour prévoir le coût. La simulation elle-même est gratuite et ne consomme pas de capacité d'exécution. La requête réelle relève ensuite de son propre régime de facturation.

Autrement dit, le chiffre affiché répond à une question de confidentialité que le service financier risque de prendre pour une question de prix. Voilà une petite erreur de traduction entre services, capable de survivre à beaucoup de réunions.

La facture et son commentaire ne circulent pas ensemble

La sécurité au niveau des lignes permet de partager une table tout en réservant à chaque utilisateur les enregistrements autorisés. Mais le contenu des lignes n'est pas la seule information utile. Les volumes traités, les étapes d'exécution et certaines données de facturation peuvent aussi renseigner sur ce qui reste invisible.

Les bonnes pratiques de Google expliquent donc que BigQuery masque plusieurs statistiques pour les requêtes portant sur ces tables : octets et partitions traités, octets facturés, étapes du plan de requête. Attendre la fin du traitement ne suffit pas à obtenir le détail manquant.

Dans la vue INFORMATION_SCHEMA.JOBS, les champs total_bytes_billed et total_bytes_processed sont vides lorsqu'une requête lit des tables dotées de règles d'accès aux lignes. La documentation de cette vue propose un calcul de coût qui dénombre les tâches potentiellement concernées, tout en reconnaissant qu'il n'accède pas à leur consommation facturable. Compter les enveloppes fermées ne révèle pas les montants à l'intérieur.

Imaginons maintenant un tableau de répartition des dépenses qui remplace systématiquement les valeurs absentes par zéro. Les équipes dont les statistiques sont cachées paraîtront plus économes. Ce classement récompense une absence d'information. Il ne mesure pas une meilleure utilisation du service. Le défaut appartient au tableau de bord, même si BigQuery protège exactement ce qu'il était chargé de protéger.

Le comptable n'est pas un utilisateur comme les autres

La réponse habituelle à une case vide consiste à demander davantage de droits. Ici, le détour mérite réflexion.

Un propriétaire de projet peut consulter des octets traités dans les journaux d'audit associés, explique Google. Il ne récupère pas pour autant ces métadonnées de facturation dans les détails des tâches ; aucun rôle ou droit spécifique ne les y rend disponibles. Le rôle Cloud Billing Viewer donne, lui, accès à des informations de facturation. Les deux chemins ne fournissent ni les mêmes détails ni les mêmes garanties.

Google déconseille justement d'accorder cet accès à la facturation aux utilisateurs qui ne devraient voir que les lignes filtrées : des informations sensibles peuvent se déduire des coûts. Le financier qui veut responsabiliser chacun par la transparence rencontre donc une limite concrète. Publier davantage de chiffres peut élargir l'accès aux données sans ajouter une seule colonne à la table partagée.

Une entreprise doit décider qui est autorisé à rapprocher les dépenses et quel retour chaque équipe peut recevoir. Ce travail ne disparaît pas dans un menu de permissions. Il se transforme en responsabilité d'organisation.

Une petite fenêtre n'offre pas une petite facture

Autre détail qui contrarie l'intuition : les filtres des règles d'accès aux lignes ne participent pas à l'élimination des partitions ou des blocs des tables organisées en clusters. Mentionner une colonne de partition dans une règle de sécurité n'apporte donc pas le bénéfice de ce mécanisme de réduction du travail. Les filtres de la requête elle-même sont une autre affaire.

La quantité de données visible par un salarié ne suffit ainsi pas à prédire la quantité traitée. Et le propriétaire des données n'est pas nécessairement celui qui paie : selon la tarification de BigQuery, une requête sur des données partagées est facturée au compte associé au projet qui l'exécute.

Il faut aussi distinguer le paiement à la demande, fondé sur les octets traités, du paiement par capacité de calcul. Un zéro produit pour préserver un secret ne constitue un budget dans aucun de ces deux modèles.

Google documente des contrôles de coûts, notamment les quotas quotidiens et le plafond d'octets facturés par requête pour le modèle à la demande. Les documents consultés ne décrivent pas toute l'interaction entre ce plafond et l'estimation masquée par les règles de lignes ; une validation autorisée sur le cas concerné doit établir son comportement. Le zéro ne permet de conclure ni à un passage gratuit ni à une protection automatique.

Nous disposons ici de règles produit, pas des comptes d'un client : chiffrer une mauvaise répartition exigerait ses relevés et ses méthodes internes. Le problème de gestion est déjà identifiable. La confidentialité retire certaines pièces justificatives de la vue de l'utilisateur, sans retirer la charge de l'entreprise.

Le premier geste consiste à conserver la valeur inconnue comme inconnue. Le suivant coûte davantage : organiser un rapprochement autorisé, assumer les dépenses qui ne se laissent pas attribuer exactement et offrir aux équipes un retour compatible avec leurs droits. Un budget sérieux sait reconnaître ce qu'il ne voit pas. C'est même préférable à un zéro très convaincant.