/
Backstage vs. Cycloid : Comparatif IDP 2026
À mesure que les équipes plateforme grandissent, les problèmes du quotidien apparaissent là où les ingénieurs mettent les mains : un changement Terraform s’applique sans revue, un cluster éphémère continue de tourner après le sprint, ou personne ne sait qui est responsable d’un service quand il tombe en panne.
vs
Rédigé par
L’équipe Cycloid
Platform engineering
Mis à jour
Octobre 2026
Temps de lecture
10 min
Backstage vs. Cycloid
Le compromis fondamental
Backstage
Backstage est un framework open source de portail développeur, créé à l’origine par Spotify et aujourd’hui projet CNCF. Il vous donne un Software Catalog, TechDocs et des templates Scaffolder sur lesquels construire. Backstage n’exécute pas l’infrastructure : il la décrit, et tout ce qui dépasse le noyau est un ensemble de plugins que votre équipe assemble et maintient.
La plateforme unique
Cycloid est un portail et une plateforme de développement interne en un seul produit. Le catalogue, les responsables et les scorecards vivent sur le même référentiel que les Blueprints qui créent et modifient les ressources : la page qui affiche un service est celle depuis laquelle vous agissez. Les Forms valident les saisies, l’autorisation en quatre couches contrôle chaque action, et les exécutions passent par le Native Runner ou par la CI que vous avez déjà.
FLEXIBILITÉ vs. DÉLAI DE DÉPLOIEMENT
Matrice de décision
Matrice de décision : Backstage vs. Cycloid
Comparer Backstage et Cycloid revient à un seul compromis : flexibilité vs. délai de déploiement. Backstage est open source et très personnalisable, mais quelqu’un doit le construire et le faire tourner : deux ingénieurs plateforme au minimum est un point de départ courant, pour un salaire moyen européen de 118 028$ chacun (State of Platform Engineering, 2024). Cycloid est un produit que votre équipe plateforme configure, en production en quelques semaines : cloudXcelerate est passé de la migration cloud à la production complète en moins de quatre semaines.
01
Où s’exécute Terraform et où résident les identifiants
Le modèle de déploiement est important car il détermine où vivent les credentials, les fichiers d’état et les logs d’audit. Pour les équipes soumises aux exigences de résidence des données ou opérant dans des environnements isolés, c’est souvent un critère éliminatoire.
La plupart des équipes hébergent Backstage elles-mêmes : elles construisent et déploient leur propre instance, généralement sur Kubernetes, avec une base PostgreSQL et une image Docker sur mesure qui embarque les plugins qu’elles utilisent. Des options gérées et supportées existent : Spotify Portal for Backstage et Roadie en SaaS, et Red Hat Developer Hub comme distribution supportée sur OpenShift.
FONCTIONNALITÉ
BACKSTAGE
Modèle de déploiement
SaaS, géré dédié, ou entièrement auto-hébergé y compris les environnements isolés
Principalement auto-hébergé ; options gérées chez Spotify Portal et Roadie, distribution supportée chez Red Hat
Contrôle de la résidence des données
L’état, les logs d’exécution et les credentials peuvent rester dans des réseaux contrôlés par le client
Les équipes contrôlent les données en opérant la plateforme elles-mêmes, ou acceptent l’hébergement d’un éditeur
Propriété du runtime de la plateforme
Cycloid opère le SaaS et les instances dédiées gérées ; les instances auto-hébergées tournent sur votre infrastructure et se mettent à niveau à chaque version
Les équipes possèdent le runtime complet : builds d’images, mises à jour de plugins, base de données et mises à niveau
Gestion des credentials d’infrastructure
Credentials cloud stockés et délimités dans la plateforme, utilisés au moment de l’exécution
Pas de stockage de credentials ; l’accès à l’infrastructure se fait dans des systèmes CI externes
Adéquation aux environnements réglementés
Adapté aux cas où l’exécution d’infrastructure et les approbations doivent rester dans des réseaux privés ou isolés
Adapté aux équipes capables d’absorber la charge d’ingénierie liée à l’exploitation du portail
02
Qui exécute les plan et apply Terraform
Le Scaffolder de Backstage peut déclencher des workflows externes, y compris ceux qui exécutent Terraform. Un modèle peut créer un dépôt, pousser des fichiers de configuration et déclencher un pipeline — mais l’exécution réelle se produit en dehors de Backstage. Cela signifie que la logique de politique, la gestion de l’état et les approbations vivent dans des systèmes séparés, non dans Backstage lui-même. Cycloid n’a pas ce découplage. Lorsqu’un développeur soumet une demande, Cycloid génère la configuration sauvegardée dans Git, exécute le plan, attend les approbations requises, puis applique. La politique et l’état vivent dans la plateforme, et non dans un webhook ou un pipeline qui pourrait être modifié indépendamment.
FONCTIONNALITÉ
BACKSTAGE
Exécution de l’Infrastructure-as-Code
Exécute Terraform et OpenTofu, Ansible et Helm sur le Native Runner, ou déclenche votre CI
N’exécute pas d’IaC ; le Scaffolder peut déclencher des pipelines externes qui le font
Connaissance de l’état Terraform
Lit l’état Terraform et OpenTofu pour inventorier ce qui est géré et montrer la couverture IaC
Pas de gestion d’état ; liens vers des dépôts ou des outils externes
Contrôle du cycle de vie des environnements
Crée, met à jour et décommissionne les environnements via les actions des Blueprints, avec les actions Day 2 sur le même référentiel
Le cycle de vie des environnements est géré dans des pipelines CI externes ou des outils IaC
Visualisation de l’infrastructure
Graphe des relations entre ressources et services par environnement, construit à partir de l’inventaire, de l’IaC et des relations déclarées
Affiche les métadonnées des services, les liens vers les dépôts et l’état de la CI, sans topologie d’infrastructure
03
Comment les changements d’environnement sont demandés et appliqués
Le modèle de libre-service de Backstage est centré sur des modèles standardisés pour créer des services et des composants. Le Scaffolder permet aux équipes de plateforme de publier des modèles que les développeurs peuvent exécuter pour créer de nouveaux composants, déclencher des pipelines ou configurer des dépôts. Mais les changements continus aux environnements existants — mise à l’échelle, mise à jour, décommissionnement — ne font généralement pas partie de Backstage. Ces opérations vivent dans CI/CD et IaC.
Le libre-service de Cycloid couvre le premier déploiement et tout ce qui suit. Les développeurs demandent ou modifient des environnements via des Forms qui n’exposent que les champs choisis par l’équipe plateforme, puis les promeuvent et lancent des actions Day 2 depuis la page de la ressource. Les approbations interviennent avant toute exécution lorsqu’une demande exige une validation.
FONCTIONNALITÉ
BACKSTAGE
Ce qu’un développeur peut faire dans la plateforme
Créer ou modifier des environnements à partir de Blueprints approuvés, les promouvoir et lancer des actions Day 2
Exécuter des modèles Scaffolder pour créer de nouveaux composants ; parcourir et mettre à jour les entrées du catalogue de services
Comment la création d’environnement se produit
La plateforme exécute l’action de création du Blueprint, sur le Native Runner ou votre CI, et enregistre le résultat
Le Scaffolder déclenche des pipelines externes ; le provisionnement réel se produit en dehors de Backstage
Garde-fous sur les entrées
Champs de Form limités aux valeurs approuvées et validés avant l’envoi
Les entrées de modèles peuvent être validées dans un modèle, mais il n’y a pas d’application sur les paramètres de pipeline externes
Flux d’approbation
Étapes d’approbation avant l’exécution, acheminées vers le bon approbateur (Enterprise)
Pas de flux d’approbation d’infrastructure natif ; approbations gérées dans le contrôle de sources ou le CI externe
Que se passe-t-il si la politique échoue
La demande est refusée avant que quoi que ce soit ne soit créé
L’application des politiques doit exister dans la CI ou l’outillage IaC externes
04
Où s’appliquent les contrôles de politique et les approbations
La gouvernance échoue lorsqu’elle repose sur la convention plutôt que sur l’application. Si votre règle de protection de branche est le principal contrôle empêchant les changements Terraform non revus d’atteindre la production, vous avez une dépendance fragile à une configuration qui peut être contournée.
Le framework de permissions de Backstage, introduit progressivement depuis 2022, permet aux équipes de plateforme de contrôler qui peut déclencher des modèles Scaffolder, voir les entrées du catalogue ou accéder à des plugins spécifiques. Mais ces permissions contrôlent l’accès aux fonctionnalités du portail, et non l’exécution de l’infrastructure. Si un utilisateur a accès à GitHub Actions ou peut déclencher un pipeline CI directement, les permissions du portail Backstage ne bloquent pas ce chemin.
FONCTIONNALITÉ
BACKSTAGE
Contrôle d’accès basé sur les rôles
Rôles prédéfinis, délimités par équipe et par Resource Group, qui contrôlent qui peut demander, approuver ou exécuter
Contrôle l’accès aux métadonnées du catalogue et aux modèles Scaffolder ; hérite du fournisseur Git et du CI pour l’infrastructure
Application des politiques
La validation des Forms et les conditions s’exécutent avant l’exécution et refusent les demandes non conformes
Pas d’évaluation de politique sur les déploiements externes ; Backstage n’intercepte pas le CI ou l’exécution IaC
Workflows d’approbation
Étapes d’approbation natives, requises avant que l’exécution ne se poursuive
Les approbations se produisent dans des systèmes externes ; Backstage s’y lie mais ne les applique pas
Journalisation des audits
Un seul journal des demandes, approbations, refus et changements, pour les personnes comme pour les assistants
Les données d’audit réparties entre les commits Git, les logs CI et Jira ; Backstage affiche des références mais ne les consolide pas
Posture de conformité
Empêche les changements non conformes en appliquant les contrôles dans le chemin de livraison
Documente l’état de conformité via des scorecards et des métadonnées de responsabilité, sans bloquer l’exécution
05
Où résident responsabilités, documentation et standards
C’est là que Backstage est le plus fort, et là que Cycloid le rejoint de front.
Le Software Catalog de Backstage suit les composants, les API, les systèmes et leurs responsables à partir de fichiers catalog-info.yaml. TechDocs affiche la documentation à côté de chaque entité, et les scorecards viennent de plugins comme Soundcheck de Spotify. Tout cela demande des plugins configurés et maintenus à jour par votre équipe.
Le catalogue logiciel de Cycloid liste chaque service, API et ressource avec son responsable, ses dépendances et son niveau de scorecard, sur le même référentiel que le Blueprint qui l’a créé. La documentation et les spécifications d’API (OpenAPI, AsyncAPI, GraphQL) se trouvent sur la page de la ressource. Les scorecards classent chaque service par rapport à vos standards et disent au responsable ce qui manque, et celui-ci le corrige par une action Day 2 ou une mise à jour de propriété.
FONCTIONNALITÉ
BACKSTAGE
Catalogue logiciel
Services, API, ressources et responsables, avec recherche à facettes, intégrés
Software Catalog à partir de catalog-info.yaml, étendu par des plugins
Responsabilité
Champs de responsabilité configurables sur chaque ressource
Champ owner par entité
Scorecards
Moteur de règles intégré, avec niveaux, tendances et exemptions
Via des plugins comme Soundcheck (commercial) ou des plugins communautaires
Documentation et spécifications d’API
Documentation, plus spécifications OpenAPI, AsyncAPI et GraphQL, sur la page de la ressource
Plugin TechDocs pour la documentation ; le plugin API docs affiche OpenAPI, AsyncAPI et GraphQL
Agir sur ce que vous voyez
Déployer, promouvoir et lancer des actions Day 2 depuis la même page
Renvoie vers des outils et des pipelines externes
Si les informations ci-dessus sont inexactes ou obsolètes, veuillez nous contacter à marketing@cycloid.io et nous les corrigerons dans les plus brefs délais !
Migration
Migrer depuis Backstage
Pas besoin de réécrire vos descripteurs pour essayer Cycloid. Connectez vos dépôts GitHub ou GitLab et Cycloid découvre les fichiers catalog-info.yaml que Backstage lit déjà. Chaque entité est proposée à la revue avant import, associée à une ressource Cycloid avec son responsable et ses relations, et son identifiant Backstage est conservé comme identifiant externe : les deux peuvent tourner côte à côte le temps de comparer. Les templates, eux, ne se transfèrent pas : votre équipe plateforme les reconstruit en Blueprints.
Comment décider
Comment décider
Les équipes plateforme des grandes entreprises font rarement face à un seul problème isolé. Exécution, responsabilité et standards se dégradent ensemble, et l’équipe qui les corrige reste petite.
Backstage convient aux équipes qui veulent construire leur propre portail et disposent d’ingénieurs pour continuer à le construire : un framework, des plugins et la maîtrise totale de chaque écran.
Cycloid convient aux équipes qui veulent le portail et la plateforme en un seul produit : un catalogue avec responsables et scorecards, et des parcours gouvernés pour agir dessus, en production en quelques semaines et non après un an d’assemblage.
Les deux peuvent tourner côte à côte le temps de comparer. La différence se voit quand un développeur repère un problème dans le catalogue : dans Backstage, il suit un lien vers un autre outil ; dans Cycloid, il le corrige depuis la même page.
Questions fréquentes
Backstage est un framework open source de portail, créé par Spotify : vous obtenez un catalogue et un système de plugins, et votre équipe construit et maintient le reste. Cycloid est un portail et une plateforme de développement interne en un, avec le catalogue, la responsabilité, les scorecards, les Blueprints, les Forms et la gouvernance livrés comme produit, en production en quelques semaines. Le compromis : plafond de personnalisation contre délai de mise en production et coût de fonctionnement.
Backstage est gratuit sous licence Apache 2.0. Le coût est humain : le construire et le faire tourner demande en général au moins deux ingénieurs plateforme, et le salaire moyen européen de l’un d’eux est de 118 028$ par an (State of Platform Engineering, 2024).
Un déploiement Backstage prêt pour la production prend généralement 6 à 12 mois. La première installation est rapide, mais la configuration des plugins, de l’authentification et des intégrations avec les systèmes internes allonge le délai. Cycloid est en production en quelques semaines : cloudXcelerate est passé de la migration cloud à la production complète en moins de quatre semaines.
Pour les équipes qui n’ont pas d’ingénieurs à dédier au développement d’un portail, un produit comme Cycloid apporte le catalogue logiciel, les Blueprints et les Forms pour le libre-service, et la gouvernance, prêts à l’emploi.
Cycloid coûte en général moins cher à posséder pour les équipes qui n’ont pas déjà une équipe dédiée à la maintenance de Backstage. La licence de Backstage est gratuite, mais deux ingénieurs au salaire moyen européen représentent environ 236 000$ par an avant même que le portail n’atteigne la production. Cycloid démarre à 39€ par utilisateur et par mois en Advanced.
Oui. Connectez vos dépôts et Cycloid découvre vos fichiers catalog-info.yaml, propose chaque entité à la revue et conserve son identifiant Backstage comme identifiant externe, de sorte que les deux peuvent tourner côte à côte le temps de basculer.
Voyez Cycloid à côté du Backstage que vous exploitez aujourd’hui
Découvrez le catalogue logiciel, les Blueprints et la gouvernance de Cycloid en action, côte à côte avec ce que vous exploitez aujourd’hui.