Ingénierie de plateforme : tirez parti de l’expérience Google

Comment abordez-vous le développement logiciel ? Chez Google, nous nous efforçons constamment de créer de meilleurs services, plus rapidement. Pour y parvenir, notre équipe Developer Platform et Google Cloud ont noué un partenariat stratégique et se mobilisent autour d’une vision commune : capitaliser sur nos solutions internes et nos outils d’ingénierie pour les mettre à disposition des clients Google Cloud.

Le premier défi du développement logiciel consiste à bien comprendre comment les équipes, petites ou grandes, peuvent trouver le juste équilibre entre efficacité, qualité et coûts, tout en créant de la valeur. À l’occasion de notre récente intervention lors de PlatformCon 2025, nous avons présenté les éléments clés de notre approche de l’ingénierie de plateforme, une approche que nous avons baptisée « shift down ».

Le shift down consiste à intégrer les décisions et les responsabilités directement au sein des plateformes internes de développement (IDP), afin de réduire la charge opérationnelle qui pèse sur les développeurs. Elle se distingue de la tendance DevOps du shift left, qui vise à déplacer davantage d’efforts en amont du cycle de développement, une méthode qui montre ses limites à grande échelle face à l’ampleur et au rythme des évolutions des besoins.
Là où le shift left tend à alourdir la charge des équipes lorsqu’il est appliqué à grande échelle, le shift down cherche au contraire à tirer le maximum de valeur des ressources existantes. Cette approche permet aux entreprises d’innover rapidement tout en maintenant un niveau de qualité, de risque et de coûts soutenables, quels que soient leurs modèles économiques.

Lors de notre intervention, nous avons partagé plusieurs enseignements qui se sont révélés particulièrement utiles dans notre démarche en matière de développement logiciel et d’ingénierie de plateforme :

1. Partir du modèle économique. En prenant le modèle économique comme point de départ, les organisations peuvent orienter l’évolution de leur plateforme et de leurs investissements en fonction de leurs objectifs de marge, de leur tolérance au risque et de leurs exigences de qualité. Chez Google, notre plateforme centrale doit répondre à une grande diversité de modèles économiques, ce qui impose un travail constant de raffinement stratégique et d’adaptation..
2. Se concentrer sur les critères de qualité pour un pilotage centralisé. Les critères de qualité — fiabilité, sécurité, efficacité et performance — sont des caractéristiques transverses émergentes (ou emergent properties) des systèmes logiciels. Elles jouent un rôle essentiel pour créer de la valeur métier et maîtriser les risques. On les qualifie souvent « d’exigences non fonctionnelles » car ils décrivent la manière dont le logiciel se comporte, et non ce qu’il fait fonctionnellement. Avec une stratégie shift down, la responsabilité de ces critères de qualité peut être intégrée directement au sein des systèmes et de l’infrastructure de la plateforme, réduisant ainsi considérablement la charge opérationnelle qui pèse sur chaque développeur.
3. Abstractions et couplage, deux leviers essentiels pour maîtriser les critères de qualité. Notre approche de la conception de plateformes repose sur deux leviers techniques essentiels pour maîtriser les critères de qualité : les abstractions et le couplage. Dans une stratégie shift down, les abstractions permettent de rendre les systèmes plus compréhensibles, de mieux gérer les risques, de clarifier les responsabilités et de contrôler les coûts en encapsulant la complexité. Le couplage, quant à lui, indique le degré d’interconnexion et d’interdépendance entre les composants d’un système ou d’un écosystème de développement. Pour réussir une stratégie shift down, le bon niveau de couplage est déterminant, car il permet à la plateforme et à l’écosystème de développement d’intégrer et d’influencer directement les critères de qualité. Concrètement, c’est grâce au couplage que nous pouvons proposer des solutions complètes d’infrastructure et de plateforme sous forme de services cohérents, comme Google Kubernetes Engine (GKE).
4. Responsabilités partagées, formation et règles communes sont des leviers « sociaux » essentiels. À grande échelle, la responsabilité partagée constitue un levier organisationnel déterminant. Elle repose d’abord sur la formation, par exemple en sensibilisant les ingénieurs à l’usage des plateformes et de l’IA. Elle s’appuie aussi sur la promotion d’une culture one team (« une seule équipe ») afin d’encourager les profils centrés sur un livrable ou un composant donné à s’ouvrir à la mission globale et à l’engagement envers les clients. Par ailleurs, des règles explicites, comme des guides de style appliqués de manière centralisée ou des API conçues dès l’origine pour être sécurisées (secure by design), permettent d’intégrer des garanties de qualité directement dans la plateforme et l’infrastructure, réduisant ainsi considérablement la charge opérationnelle des développeurs tout en assurant la cohérence et l’automatisation des contrôles à grande échelle.
5. Utiliser une cartographie. Gérer les besoins de nombreuses entités métiers avec une seule plateforme est un problème vaste et complexe : il vous faut donc une cartographie. Chez Google, nous utilisons ce que nous appelons le modèle d’écosystème, un framework conceptuel qui fait office de cartographie et qui permet de classer les différents environnements de développement logiciel, allant de systèmes très flexibles, sous contrôle direct des développeurs, à des environnements fortement intégrés et normés, où c’est l’écosystème lui-même qui garantit les critères de qualité. Le rôle essentiel de ce framework est de fournir un outil visuel et conceptuel permettant d’évaluer dans quelle mesure les mécanismes de contrôle de l’écosystème sont alignés avec les risques métier. Autrement dit, il sert à vérifier que le niveau de supervision et de garantie des critères de qualité est proportionné au coût potentiel des erreurs. L’objectif est de rester dans la « zone d’efficacité de l’écosystème » : un équilibre où les contrôles suffisent à limiter les risques majeurs liés aux erreurs humaines, sans pour autant imposer de contraintes excessives qui ralentiraient l’innovation et démotiveraient les développeurs.

6. Segmenter le problème en identifiant les différents types de plateformes et d’écosystèmes. L’expérience développeur et l’infrastructure de la plateforme évoluent en fonction de l’échelle et du degré de shift down. Il ne suffit donc pas de savoir où se situe la « zone d’efficacité de l’écosystème » : il faut aussi identifier le type d’écosystème auquel on a affaire. Nous distinguons les écosystèmes en fonction du niveau de supervision et de garantie appliqué aux critères de qualité. Plus un écosystème devient intégré verticalement — comme l’écosystème fortement optimisé « Assured » de Google (Type 4) — plus la plateforme prend nativement en charge des critères de qualité essentiels. Cela permet aux spécialistes, tels que les site reliability engineers (SRE) ou les équipes de sécurité, d’assumer pleinement leur rôle grâce à une observabilité à grande échelle et à des capacités intégrées. À l’inverse, dans des écosystèmes moins homogènes comme « YOLO », « AdHoc » ou « Guided » (Types 0 à 2), les développeurs gèrent une part plus importante de la responsabilité en matière de qualité, tandis que les équipes spécialisées disposent de moins de leviers de contrôle direct et de mécanismes d’application moins étendus. Précisons toutefois : les modèles précités (Assured, YOLO, AdHoc et Guided) ne sont pas des indicateurs de maturité. Le meilleur type d’écosystème et de plateforme est simplement celui qui correspond le mieux aux besoins de votre entreprise (cf. point n°1 ci-dessus !).

Faire les bons choix en matière d’ingénierie de plateforme

En résumé, la leçon la plus importante à retenir, c’est qu’il faut bien peser ses choix et prendre des décisions éclairées. L’ingénierie de plateforme doit être adaptée à chaque entité métier et à chaque application afin d’obtenir les meilleurs résultats. Elle doit avant tout s’attacher à repérer les problèmes récurrents, qui reviennent systématiquement dans différents domaines métier, pour les résoudre une bonne fois pour toutes avec des solutions robustes et réutilisables. Cette approche est au cœur de notre stratégie de shift down. Elle vise à aller vers des plateformes composables, capables d’intégrer directement dans l’infrastructure les décisions et les responsabilités liées à la qualité logicielle. Concrètement, cela signifie que la plateforme prend en charge directement les choix et les responsabilités liés à la qualité logicielle (sécurité, fiabilité, performance, etc.), au lieu de les laisser reposer uniquement sur les développeurs. Dit autrement, avec l’approche shift down, vous renforcez votre capacité à maximiser la valeur métier en mobilisant les bonnes ressources, au niveau de qualité requis, et avec des coûts maîtrisés dans la durée.

Pour aller plus loin, n’hésitez pas à consulter l’intégralité de notre intervention à PlatformCon 2025 sur le sujet.