Le chaînon manquant de la documentation GCP : cartographier la toile invisible des dépendances d'API

Naviguer dans l'écosystème Google Cloud Platform peut parfois s'apparenter à l'exploration d'une métropole tentaculaire. Des centaines de services, chacun doté de sa propre puissance, offrent des possibilités quasi infinies. Mais comme dans toute grande ville, des réseaux souterrains et invisibles connectent chaque quartier. Dans GCP, ces réseaux sont les dépendances entre les services d'API, des liens cruciaux mais étonnamment absents des cartes officielles.

Constat

Quand on travaille avec Google Cloud Platform (GCP), on finit toujours par passer par la case gcloud services enable. Que ce soit pour Cloud Functions, BigQuery, ou l’incontournable IAM, chaque service repose sur un ensemble parfois obscur d’APIs qu’il faut activer dans un ordre souvent flou. Et pourtant, la documentation officielle ne fournit aucune carte des dépendances entre ces services. Impossible de savoir à l’avance si désactiver anthos.googleapis.com va faire tomber dix autres services — jusqu’à ce que cela vous arrive.

Le résultat obtenu

C'est face à cette opacité que l'idée a germé : pourquoi ne pas construire la carte nous-mêmes ? C'est ainsi qu'est née l'application web que j'ai développée, disponible sur gcp.garçon.fr. L'objectif était simple : offrir une vue claire, interactive et intuitive de la toile des dépendances entre les services de Google Cloud.

L'application se présente comme une page unique, sobre, inspirée du design de Google pour ne pas dépayser les habitués. Elle s'articule autour de trois composants essentiels. Au centre, un graphe dynamique représente l'ensemble des services sous forme de nœuds. Lorsqu'une dépendance existe, une arête les relie, matérialisant enfin ces connexions invisibles. Sur la droite, une liste exhaustive de tous les services permet une recherche et une identification rapide.

La véritable valeur ajoutée se révèle à l'interaction. En sélectionnant un service, que ce soit dans la liste ou directement sur le graphe, l'interface s'anime. Le graphe zoome sur le nœud choisi et met en évidence ses relations. Les dépendances que le service consomme (ce dont il a besoin pour fonctionner) s'affichent en rouge, tandis que les services qui, à l'inverse, dépendent de lui, se colorent en vert. Simultanément, le panneau de droite se transforme pour afficher un résumé détaillé, listant clairement ces deux catégories : "Depends On" et "Dependency Of". La complexité se démêle sous nos yeux.

L'application elle-même est bâtie sur des technologies web standards, s'appuyant sur la puissante bibliothèque JavaScript Vis.js pour la partie la plus complexe : le rendu et la physique du graphe. Le résultat est un outil léger, rapide et ne nécessitant aucune installation.

Cartographier les dépendances entre APIs GCP : là où la doc s'arrête, le code commence

Le défi principal n'était pas tant technique que informationnel. Il a fallu patiemment compiler et croiser les informations pour établir cette cartographie. La méthode repose sur un test systématique des APIs. On commence par créer un projet GCP vierge. Ensuite, on active toutes les APIs disponibles (oui, ça fait beaucoup de trafic réseau), puis on les désactive une par une. À chaque tentative de désactivation, si une erreur apparaît mentionnant qu’un service est « depended on by the following active service(s) », on enregistre la relation. En réactivant ensuite l’API désactivée, on revient à l’état initial pour recommencer avec la suivante. C’est fastidieux, long (très long), mais redoutablement efficace.

Les résultats sont ensuite collectés dans un simple fichier texte de type serviceA=>serviceB, signifiant que serviceB dépend de serviceA. Ce fichier brut a été transformé en graphe interactif sur le site. Il est possible de cliquer sur une API et de voir en temps réel quelles autres APIs en dépendent, ou inversement, lesquelles elle requiert pour fonctionner.

L’enjeu dépasse la simple curiosité. Dans une logique DevSecOps ou de gouvernance fine du cloud, il est essentiel de savoir ce que l’on expose, ce qui est actif, et surtout ce que l’on pourrait désactiver sans effet de bord. Google fournit bien des descriptions d’API, mais reste silencieux sur leurs dépendances techniques. Ce manque de transparence, sans doute volontaire pour des raisons d’évolution interne, peut poser problème dans des environnements contraints.

L'application n’a pas la prétention d’être exhaustive ni parfaite. Elle se base sur des expérimentations dans un contexte contrôlé, sur un seul projet vierge. Mais elle a déjà mis en lumière des dépendances inattendues — comme le fait que certains services de réseau ou de machine learning sont étroitement liés à des APIs que l’on aurait pensé optionnelles.

Au-delà de la simple curiosité intellectuelle, cet outil apporte une valeur tangible. Pour un architecte cloud, il permet d'anticiper les besoins et de concevoir des infrastructures plus robustes. Pour un développeur, il accélère le diagnostic des erreurs de configuration. Pour un responsable FinOps, il offre une meilleure visibilité sur les coûts indirects qu'un service peut engendrer en sollicitant d'autres API facturables.

Conclusion

En résumé, quand la documentation ne suffit plus, il faut expérimenter. Et si ce travail peut servir à d'autres, tant mieux. La cartographie est disponible publiquement, sans inscription ni tracking. C’est un outil de plus pour comprendre un peu mieux cette immense boîte noire qu’est parfois GCP. Cette application ne prétend pas remplacer la documentation officielle, mais plutôt la compléter là où elle est silencieuse. Elle est une invitation à explorer, à comprendre et à maîtriser la mécanique interne de Google Cloud. La complexité n'est pas une fatalité lorsqu'on dispose des bons outils pour la visualiser. Je vous invite à l'explorer sur gcp.garçon.fr et à voir par vous-même la structure cachée de la plateforme que nous utilisons chaque jour.