Backstage : le portail développeur qui accélère vos équipes

Dans une organisation où coexistent des dizaines, voire des centaines de développeuses et de développeurs, les questions du quotidien deviennent vite des frictions structurelles : où trouver le code d’un service ? qui le maintient ? quelle est sa documentation ? comment créer un nouveau projet conforme aux standards internes ? À mesure que le patrimoine logiciel grandit, la fragmentation des outils et la dispersion de la connaissance pèsent directement sur la productivité.

C’est précisément à ce besoin que répond un Internal Developer Portal (IDP). Et dans cet écosystème, Backstage, initialement développé par Spotify puis donné à la CNCF, s’est imposé comme la référence open source. Tour d’horizon de ce qu’il apporte, à qui il s’adresse, et pourquoi il est devenu un investissement stratégique pour les organisations soucieuses de leur expérience développeur et de leur vélocité.

1. Pourquoi un Internal Developer Portal ?

1.1 La fragmentation, ennemie de la vélocité

Dans une organisation qui a passé le cap des dizaines de services, le développeur passe une part importante de son temps à chercher : où est le code, qui maintient ce composant, où se trouve sa documentation, sur quel cluster il tourne, quel pipeline le déploie, où sont ses dashboards. L’information existe presque toujours, mais elle est dispersée entre Confluence, des README, des wikis GitLab, des canaux Slack et la mémoire de quelques personnes clés.

Cette fragmentation génère un coût direct et mesurable :

• Onboarding qui s’éternise : un nouvel arrivant met des semaines à se constituer une carte mentale du SI, et reste longtemps dépendant de l’équipe pour les questions de base.
• Dépendance à quelques sachants : la connaissance critique reste dans la tête de profils seniors, créant un risque de bus factor.
• Standards qui dérivent : sans chemin par défaut clairement balisé, chaque équipe finit par réinventer la roue.
• Duplication d’efforts : la même librairie est réécrite plusieurs fois faute de visibilité sur ce qui existe déjà.

Un IDP centralise tout cela dans une seule interface : un point d’entrée unique pour découvrir, comprendre, opérer et créer.

2. Backstage : un framework pour bâtir son portail

2.1 Un framework, pas un produit clé en main

Backstage a été créé par Spotify et libéré en open source en 2020. Il a rejoint la CNCF en sandbox dès septembre 2020 puis est passé au statut incubating en mars 2022, ce qui en fait aujourd’hui la référence open source pour bâtir un IDP, avec un écosystème mature et une communauté active.

Un point essentiel à comprendre dès le départ : Backstage est un framework, pas un produit clé en main. Il ne se “déploie” pas comme on installerait un SaaS. Une organisation construit son propre portail à partir des briques fournies, en sélectionnant les plugins qui correspondent à son écosystème et en l’adaptant à ses processus internes. C’est à la fois une force (extrême adaptabilité, contrôle total, aucun coût de licence) et une contrainte (il faut investir pour le construire et le maintenir).

Côté technique, Backstage est entièrement développé en TypeScript (frontend React, backend Node.js). Cela a deux conséquences directes : la personnalisation et le développement de plugins maison se font dans un langage largement maîtrisé par les équipes web modernes, et l’écosystème npm donne accès à un vivier de bibliothèques considérable. Pour une organisation qui veut adapter finement son portail à ses processus internes, c’est un atout majeur.

2.2 Le Software Catalog : la colonne vertébrale

Le Software Catalog est le cœur de Backstage. C’est l’inventaire de tout ce qui constitue le patrimoine logiciel de l’entreprise : services, librairies, sites web, ressources d’infrastructure, APIs, équipes, utilisateurs, domaines métier.

Chaque entité est décrite par un fichier catalog-info.yaml placé à la racine du dépôt qu’elle représente. Cette approche catalog-as-code a un avantage déterminant : la description du service vit avec son code, est versionnée avec lui, et reste la responsabilité de l’équipe qui le possède.

 1apiVersion: backstage.io/v1alpha1
 2kind: Component
 3metadata:
 4  name: order-service
 5  description: Service de gestion des commandes
 6  annotations:
 7    gitlab.com/project-slug: ecommerce/order-service
 8    backstage.io/techdocs-ref: dir:.
 9spec:
10  type: service
11  lifecycle: production
12  owner: team-orders
13  system: ecommerce

La discovery automatique (via les plugins GitLab, GitHub ou Azure DevOps) scanne périodiquement les dépôts à la recherche de ces fichiers et les ajoute au catalogue sans intervention manuelle. Configurée à une fréquence de quelques dizaines de minutes, elle garantit que tout nouveau projet conforme apparaît automatiquement dans le portail.

Le catalogue répond à des questions de tous les jours : quels services dépendent de cette API ? qui maintient ce composant ? quelles ressources sont en lifecycle deprecated ? combien de services appartiennent à tel domaine ? Ces questions paraissent triviales, mais sans IDP elles demandent souvent une véritable enquête.

2.3 TechDocs : la documentation technique au plus près du code

TechDocs est l’approche docs-as-code de Backstage. La documentation est rédigée en Markdown, dans le même dépôt que le code, à l’aide de MkDocs. Backstage la compile (à la demande ou lors d’un build CI) et l’expose dans le portail.

Cela résout trois problèmes structurels :

• La documentation cesse de vieillir : elle est revue dans les mêmes Merge Requests que le code et bénéficie des mêmes process de relecture.
• Elle devient découvrable : indexée dans la recherche globale du portail, accessible depuis la fiche du composant qu’elle décrit.
• Elle reste portable : c’est du Markdown standard, qui survit à Backstage si l’outil change un jour.

Côté stockage, les artefacts générés (HTML, assets) sont typiquement déposés dans un bucket S3 (ou compatible) pour découpler la génération de la consultation.

2.4 Scaffolder : créer des projets standardisés en quelques clics

Le Scaffolder permet de définir des templates de projets paramétrables. Un développeur qui souhaite créer un nouveau microservice ne part plus d’une page blanche ou d’un dépôt à copier : il choisit un template, remplit un formulaire (nom du service, équipe propriétaire, base de données souhaitée, etc.), et Backstage génère pour lui :

• un dépôt Git initialisé avec la structure attendue,
• le catalog-info.yaml correctement renseigné,
• un Dockerfile, un chart Helm ou un manifeste Kubernetes conforme,
• le pipeline CI/CD préconfiguré,
• une documentation TechDocs vierge mais prête à être enrichie.

C’est sur cette brique que se cristallise une grande partie de la valeur d’un IDP. Elle transforme les bonnes pratiques de plateforme en chemin par défaut : il devient plus simple de respecter les standards que de les contourner. Un nouvel arrivant peut créer un service production-ready conforme à la gouvernance interne en quelques minutes, là où la même démarche manuelle prend habituellement plusieurs jours et passe souvent par une revue d’architecture.

2.5 Les plugins : l’écosystème qui fait la différence

Backstage dispose d’un écosystème de plusieurs centaines de plugins (officiels et communautaires), recensés notamment dans les répertoires Backstage et Roadie. Les plus utiles en pratique :

• Plugins SCM (GitLab, GitHub, Bitbucket) : afficher les Merge Requests, l’état des pipelines, les issues directement dans la fiche du composant.
• Plugin Kubernetes : visualiser les pods, les deployments, les services et logs depuis le portail, sans accès direct au cluster.
• Plugin ArgoCD : voir l’état de synchronisation et la santé applicative en GitOps.
• Plugins observabilité (Grafana, Prometheus, Datadog) : embarquer les dashboards et les alertes pertinents au sein de chaque composant.
• Plugin Tech Radar : publier la vision technologique de l’entreprise (à adopter, à essayer, à éviter).

C’est l’agrégation de ces plugins qui transforme Backstage d’un simple annuaire en tableau de bord opérationnel unifié. Le développeur n’a plus besoin de quitter le portail pour comprendre l’état d’un service ; l’opérateur retrouve en un endroit le code, les déploiements, les métriques et la documentation.

3. Les bénéfices business : pour qui Backstage change la donne ?

3.1 Les grandes organisations de développement

Les entreprises qui maintiennent un patrimoine logiciel important (microservices, librairies internes, APIs partagées) sont les premières bénéficiaires d’un IDP. Au-delà d’un certain seuil (couramment situé autour de 15 à 20 services et plusieurs équipes), la coordination devient un sujet en soi. Les symptômes habituels :

• Personne ne dispose d’une vue exhaustive du patrimoine logiciel.
• Les standards techniques dérivent d’une équipe à l’autre.
• La même fonctionnalité est implémentée plusieurs fois faute de visibilité.
• Les responsabilités (ownership) sont floues, ce qui ralentit la résolution d’incidents.

Backstage adresse directement ces points en imposant une source de vérité unique du patrimoine, en rendant l’ownership explicite, et en exposant les standards via le Scaffolder. À l’échelle de plusieurs dizaines de développeurs, le gain devient mesurable dès les premiers mois.

3.2 Les organisations qui veulent réduire le temps d’onboarding

Pour les entreprises où les équipes évoluent (recrutements, mobilités internes, prestataires, équipes distribuées), le temps nécessaire pour qu’un nouveau développeur soit pleinement productif est un coût caché majeur. Les études du secteur (notamment le State of Platform Engineering Report publié par Humanitec) documentent cet enjeu d’onboarding dans les environnements complexes, où la montée en autonomie peut s’étendre sur plusieurs mois faute d’outillage adapté.

Backstage agit directement sur ce délai :

• Découverte autonome du SI : le nouvel arrivant explore le catalogue, identifie les services, comprend les dépendances et trouve la documentation sans solliciter ses collègues pour les questions de base.
• TechDocs centralisées : la documentation devient un réflexe et un guichet unique, plutôt qu’une chasse au trésor entre wikis, Confluence et README dispersés.
• Templates Scaffolder : un nouveau service est créé en respectant les standards dès la première ligne de code, sans nécessiter un accompagnement individuel à chaque démarrage de projet.
• Visibilité opérationnelle : pipelines, déploiements et runtime sont consultables depuis le portail, accélérant la prise en main des aspects DevOps.

Concrètement, un développeur qui rejoint une organisation équipée d’un IDP mature peut comprendre la cartographie applicative, lire la documentation pertinente et lancer son premier projet conforme aux standards en quelques heures, là où le même parcours prend habituellement plusieurs jours, voire plusieurs semaines.

3.3 Les organisations qui structurent une démarche platform engineering

Le platform engineering est devenu une discipline à part entière, identifiée par Gartner comme l’une des tendances stratégiques majeures des dernières années. Son principe : traiter la plateforme interne comme un produit, avec ses utilisateurs (les développeurs) et ses fonctionnalités. Backstage est l’outil naturel de cette démarche, parce qu’il matérialise la plateforme de manière tangible : ce que la plateforme offre devient visible, mesurable, consommable en self-service.

Pour une DSI qui souhaite professionnaliser sa Developer Experience, Backstage joue le rôle de vitrine et de point d’entrée de l’offre de services internes.

4. Architecture type d’un déploiement Backstage

Une architecture éprouvée pour un déploiement en production :

• Backstage déployé sur Kubernetes (via Helm), dans un namespace dédié.
• PostgreSQL managé comme base de données (mode pluginDivisionMode: schema pour isoler chaque plugin dans son propre schéma sans nécessiter de droit CREATE DATABASE).
• Stockage objet (S3 ou compatible) pour les artefacts TechDocs.
• Ingress exposé avec terminaison TLS, idéalement derrière un proxy ou WAF.
• SSO branché sur le fournisseur d’identité de l’entreprise (GitLab, GitHub, Azure AD, Okta, Keycloak).
• Secrets sourcés depuis un gestionnaire dédié (Vault, AWS Secrets Manager, Bitwarden Secrets Manager) plutôt que stockés en clair dans les manifestes.

Cette stack reste légère, comprise par les équipes infra existantes, et ne crée pas de dépendances exotiques difficiles à maintenir. Backstage peut également être déployé en SaaS via des offres commerciales (Spotify Portal, Roadie) pour les organisations qui souhaitent externaliser l’exploitation.

5. Quand Backstage est-il pertinent (et quand il ne l’est pas) ?

5.1 Les signaux qui justifient un IDP

Backstage prend tout son sens dès lors qu’au moins deux ou trois des signaux suivants sont présents :

• Plus de 15 à 20 services maintenus, ou une trajectoire qui y mène à court terme.
• Plusieurs équipes qui se partagent un patrimoine technique commun.
• Un onboarding long des nouveaux arrivants, parce que la connaissance est dispersée.
• Une plateforme interne ou une équipe DevEx en cours de structuration.
• Des standards qui dérivent : chaque équipe réinvente sa façon de faire un nouveau service.
• La nécessité de donner aux développeurs une autonomie en self-service sans relâcher les exigences de sécurité ou de conformité.

5.2 Quand Backstage est probablement prématuré

À l’inverse, certains contextes ne justifient pas l’investissement :

• Une équipe unique avec moins d’une dizaine de services : un bon README et une convention de nommage suffisent.
• Une organisation sans équipe plateforme, même embryonnaire, pour porter l’outil : il sera abandonné.
• Des organisations dont la priorité immédiate est ailleurs (livraison d’un produit en phase critique) : un IDP n’apporte pas de valeur à très court terme, son ROI s’inscrit dans la durée.

5.3 Les alternatives à considérer

Backstage n’est pas la seule réponse :

• Port et Cortex sont deux IDPs SaaS qui demandent moins de mise en place initiale, au prix d’un coût récurrent et d’un lock-in plus marqué.
• OpsLevel ou Configure8 se positionnent davantage sur la maturité opérationnelle (service ownership, scorecards).
• Des solutions internes plus légères (un Notion bien structuré, un site MkDocs central) peuvent suffire pour de petites organisations.

Le choix dépend du curseur entre contrôle / extensibilité (Backstage) et time-to-value / faible maintenance (SaaS). Pour les organisations qui prennent au sérieux leur expérience développeur et acceptent d’investir dans une équipe plateforme, Backstage offre le meilleur compromis grâce à son ouverture, son écosystème de plugins et l’absence de coût de licence.

6. Les limites et les pièges à connaître

Backstage est un outil puissant, mais il serait malhonnête d’en présenter une image entièrement lisse. Quelques réalités à garder en tête avant de se lancer.

6.1 Un coût de mise en place réel

Contrairement à un IDP SaaS, Backstage demande un investissement initial significatif : choix de l’hébergement, configuration des plugins, intégration avec le SSO, déploiement, sauvegardes, supervision. Un POC raisonnable mobilise quelques semaines / hommes ; une mise en production solide se compte en mois. Les organisations qui sous-estiment cette charge se retrouvent souvent avec un portail à moitié fini, abandonné en chemin.

6.2 Une dépendance forte à des compétences TypeScript / React

Personnaliser Backstage en profondeur (modifier l’UI, écrire un plugin maison, étendre une intégration existante) suppose des compétences en TypeScript, React et Node.js. Une équipe plateforme à dominante systèmes / infra sans renfort frontend aura du mal à dépasser le périmètre des plugins prêts à l’emploi.

6.3 Une documentation et des plugins inégaux

La documentation officielle a beaucoup progressé mais reste parfois lacunaire sur des cas avancés (multi-tenancy, RBAC fin, performance à grande échelle). Côté plugins communautaires, la qualité est variable : certains sont excellents et activement maintenus, d’autres sont abandonnés ou divergent rapidement des nouvelles versions de Backstage. Une partie de l’effort d’une équipe plateforme consistera à choisir, contribuer ou maintenir en interne certains plugins.

6.4 Des breaking changes fréquents

Backstage évolue vite. Les montées de version (en particulier les changements majeurs comme la migration vers le nouveau backend system) peuvent demander un travail d’adaptation non négligeable, surtout pour les déploiements qui ont accumulé du code custom. Prévoir un budget récurrent de maintenance est indispensable.

6.5 Le risque du portail à moitié vide

Un Backstage qui n’expose qu’un catalogue incomplet, sans TechDocs ni Scaffolder, sans plugins métier, devient rapidement une vitrine vide que personne ne consulte. Le risque n’est pas seulement de perdre l’investissement : un portail décrédibilisé est très difficile à relancer ensuite. D’où l’importance de viser un périmètre fonctionnel minimal mais réel dès la première mise à disposition.

6.6 Pas une solution magique à la gouvernance

Backstage matérialise et expose la gouvernance, il ne la crée pas. Si l’ownership des services n’est pas clarifié dans l’organisation, le catalogue affichera des trous. Si les standards techniques n’existent pas, le Scaffolder n’aura rien à templater. L’outil amplifie ce qui existe déjà : il accélère une organisation mature, mais ne se substitue pas au travail de fond de structuration interne.

7. Les conditions de succès

Au-delà de la technologie, la réussite d’un déploiement Backstage repose sur quelques fondamentaux :

• Un ownership clair du portail. Sans équipe (même réduite) responsable de la plateforme, l’outil dérive. Backstage doit être traité comme un produit interne, avec sa roadmap, ses utilisateurs et ses retours.
• Une discovery automatique activée tôt. Un catalogue rempli manuellement ne tient pas dans la durée. La discovery branchée sur le SCM dès le départ rend l’adoption naturelle.
• Une montée en charge progressive des fonctionnalités. Le Scaffolder demande des templates de qualité, eux-mêmes adossés à des standards stabilisés. Activer les briques dans le bon ordre évite de livrer un outil incomplet.
• Une mesure d’adoption. Nombre de composants catalogués, taux de couverture TechDocs, nombre de projets créés via Scaffolder, fréquentation du portail : ces métriques pilotent l’évolution du produit.
• Un alignement avec la sécurité et la conformité. Le portail centralisant l’accès à de nombreuses sources (clusters, CI/CD, monitoring), les questions d’authentification, d’autorisation et d’audit doivent être traitées dès la conception.

8. Conclusion : un IDP, c’est d’abord un projet produit

Backstage est un outil remarquable, mais c’est l’organisation qui s’en empare qui en fait un succès ou un échec. La vraie question à se poser avant de se lancer n’est pas “quels plugins allons-nous installer ?” mais “qui sera responsable du portail, comment allons-nous mesurer son adoption, et comment allons-nous le faire évoluer dans la durée ?”

Pour les organisations qui passent ce cap, le retour sur investissement est tangible : onboarding optimisé, moins de duplication d’efforts, standards mieux respectés, expérience développeur transformée. À l’échelle d’une plateforme avec plusieurs dizaines de services et plusieurs équipes, l’absence d’IDP devient progressivement une dette opérationnelle qui se paye chaque jour, sans toujours qu’on la voie.

Si la fragmentation de votre outillage interne commence à peser sur la vélocité de vos équipes, ou si la durée d’onboarding de vos nouveaux développeurs devient un sujet stratégique, Backstage est probablement à étudier sérieusement.

Vous souhaitez évaluer la pertinence d’un IDP pour votre organisation, lancer un POC Backstage ou structurer votre équipe plateforme ? Contactez-nous.

Sources

• Backstage : Documentation officielle
• CNCF : Page projet Backstage (statut, maturité, gouvernance)
• Spotify Engineering : What the Heck is Backstage Anyway?
• CNCF : Platform Engineering Maturity Model
• Gartner : What Is Platform Engineering?
• Humanitec : State of Platform Engineering Report Volume 3
• Backstage : Software Catalog Overview
• Backstage : TechDocs Architecture
• Backstage : Software Templates (Scaffolder)
• Backstage : Plugin Marketplace

• Précédent
  Stratégie IA : vos fondations DevOps et cloud-native décideront du résultat