Un platform engineer Backstage construit le portail interne où les développeurs trouvent chaque service, son équipe propriétaire, sa documentation et les modèles pour en créer un nouveau. Les offres françaises l'associent à Kubernetes, Argo CD, GitLab CI et Terraform, et aussi à TypeScript et React, parce que le portail se code. Les questions d'entretien utiles couvrent donc l'intégration d'outils d'infrastructure et le développement d'une application web.
Beaucoup de CV citent Backstage après un POC de quelques semaines. Un portail tenu en production se reconnaît à d'autres détails : un catalogue alimenté depuis les dépôts et l'annuaire, des propriétaires à jour, des templates qui créent en une fois le dépôt, le pipeline et l'application Argo CD, des montées de version régulières. Le nombre d'entités du catalogue et d'équipes qui s'en servaient chaque semaine compte.
Dix minutes restent pour du code. Un extrait de plugin backend ou un template YAML à commenter montre vite qui a écrit ses propres actions et qui a seulement installé celles de la communauté. Le PDF contient l'entretien complet : 30 questions sur six axes, un cas de 20 minutes et une grille de 1 à 4.
Backstage et les outils que le portail relie
Catalogue logiciel
Le registre des services, API, bases et équipes, décrit par un fichier catalog-info.yaml dans chaque dépôt. Chaque entité a un type (Component, API, Resource, System, Domain, Group, User) et des relations : son propriétaire, ses dépendances, les API qu'elle expose. Un catalogue sans propriétaires fiables perd vite la confiance des équipes.
Software Templates (scaffolder)
Les formulaires qui créent un nouveau service selon les standards de l'entreprise : squelette de code, dépôt, pipeline, déclaration dans le catalogue. Chaque template enchaîne des actions, dont certaines sont écrites en TypeScript par l'équipe plateforme. C'est la partie du portail que les développeurs utilisent le plus directement.
TechDocs
La documentation écrite en Markdown dans chaque dépôt et affichée dans la fiche du composant. Elle repose sur MkDocs. En production, la CI la génère et la dépose dans un stockage objet. Backstage propose désormais un moteur expérimental, Zensical, face à Material for MkDocs, en simple maintenance depuis novembre 2025 et dont l'arrêt est annoncé.
Plugins et backend system
Tout ce que le portail affiche passe par des plugins : une partie frontend en React, souvent une partie backend en Node.js. Le nouveau backend system injecte les services communs (base, journaux, planification, authentification), et le nouveau frontend system décrit l'interface par extensions. Un candidat qui code des plugins connaît les deux.
Authentification et permissions
La connexion passe par un fournisseur d'identité (Entra ID, Okta, Keycloak, GitHub) et un sign-in resolver qui relie la personne à une entité User. Le framework de permissions décide ensuite qui lit une entité ou lance un template. La politique par défaut autorise tout, il faut la remplacer.
Scorecards : Tech Insights, Soundcheck
Des contrôles automatiques sur chaque composant : documentation présente, version de bibliothèque à jour, alertes déclarées. Tech Insights est un plugin open source, Soundcheck un module payant de Spotify, et les portails du marché ont leur équivalent. Reste à savoir quels contrôles la personne a écrits et comment les faits étaient collectés.
Intégrations : GitLab, GitHub, Kubernetes, Argo CD
Le portail lit les dépôts, les pipelines, les pods et l'état des déploiements de chaque composant. Chaque intégration demande des identifiants à droits limités et une annotation dans le catalogue pour faire le lien. Les offres citent surtout GitLab CI, Argo CD et Kubernetes.
Distributions et alternatives
Red Hat Developer Hub est une distribution de Backstage avec plugins dynamiques, Roadie et Spotify Portal le proposent en service hébergé. Port et Cortex sont des portails commerciaux qui ne reposent pas sur Backstage. Le choix change la part de code TypeScript à maintenir, donc le profil à chercher.
Le poste apparaît quand plusieurs dizaines d'équipes de développement partagent la même infrastructure et que créer un service demande encore une série de tickets. Le platform engineer Backstage vient soit du DevOps et a appris TypeScript, soit du développement web et a appris Kubernetes et la CI. Les offres françaises le rangent dans une équipe plateforme, à côté des profils Kubernetes et GitOps, et citent Backstage avec Argo CD, GitLab CI, Terraform et parfois Crossplane. La Linux Foundation propose la Certified Backstage Associate (CBA), un QCM de 90 minutes qui atteste des bases du framework. Le niveau se vérifie sur un catalogue réellement tenu, des templates utilisés et des plugins écrits.
Backstage en entretien : compétences à couvrir
- Modélisation du catalogue logiciel
- Software Templates et actions sur mesure
- Plugins TypeScript et backend Backstage
- Authentification, permissions et intégrations
- TechDocs, recherche et scorecards
- Exploitation et montées de version du portail
Les cinq premières questions d'entretien sur Backstage
Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.
Question 1 · confirmé
Le catalogue compte 800 composants, dont un tiers pointe vers un propriétaire qui n'existe plus. Comment le remettez-vous en état, et comment l'empêchez-vous de se dégrader à nouveau ?
Une bonne réponseD'abord la source des équipes : les entités Group et User doivent venir de l'annuaire (fournisseur d'organisation Microsoft Graph, LDAP ou GitHub), sinon chaque réorganisation casse les références. Ensuite une liste des entités dont spec.owner ne résout vers aucun groupe, envoyée aux équipes concernées. Pour la suite : un contrôle en CI qui valide le fichier catalog-info.yaml et refuse un propriétaire inconnu, et une découverte automatique des dépôts plutôt que des enregistrements à la main.
Signal d'alerteCorriger les 270 fichiers à la main une fois, sans toucher à la cause. Un propriétaire écrit en adresse e-mail libre, ou des groupes créés à la main dans un fichier YAML que personne ne maintient.
Question 2 · confirmé
Un template de création de microservice sert depuis un an à quarante équipes. Il faut changer la bibliothèque de logs dans tous les services qu'il a générés. Que permet le template, et que ne permet-il pas ?
Une bonne réponseLe scaffolder génère le code une seule fois : les dépôts créés ne gardent aucun lien avec le template. Modifier le template ne change que les prochains services. Pour l'existant, il faut un autre mécanisme : des merge requests automatiques (Renovate ou un script), une image de base ou une bibliothèque partagée, des modèles de CI inclus plutôt que copiés. Un bon profil en tire une règle de conception : le dépôt généré reste mince et le reste vit dans des briques versionnées.
Signal d'alerte« On met à jour le template et c'est réglé. » Ou l'idée que les dépôts générés se resynchronisent tout seuls.
Question 3 · confirmé
La fiche d'un composant doit afficher l'état de ses déploiements, lu dans une API interne qui demande un jeton. Comment construisez-vous le plugin ?
Une bonne réponseDeux parties. Un plugin backend, écrit avec le nouveau backend system (createBackendPlugin et ses services injectés : httpRouter, logger, rootConfig, httpAuth), appelle l'API interne avec un jeton lu dans la configuration côté serveur et met les réponses en cache. Un plugin frontend ajoute une carte ou un onglet à la page de l'entité et appelle ce backend. Le lien entre composant et déploiement passe par une annotation dans catalog-info.yaml. Le jeton ne quitte jamais le serveur.
Signal d'alerteAppeler l'API depuis le code React avec le jeton dans la configuration envoyée au navigateur. Ou modifier le code du cœur de Backstage au lieu d'écrire un plugin.
Question 4 · confirmé
Une développeuse se connecte avec son compte Entra ID et Backstage refuse l'accès : aucune entité User ne correspond. D'où vient le problème ?
Une bonne réponseDu sign-in resolver, qui relie l'identité reçue du fournisseur à une entité User du catalogue, par exemple par l'adresse e-mail ou une annotation. Il vérifie que l'utilisateur a bien été importé par le fournisseur d'organisation (filtre de groupes, utilisateur récent pas encore synchronisé), que le champ comparé correspond (UPN et adresse mail diffèrent souvent dans Entra ID) et que le résolveur configuré est le bon. Il sait que ce lien fournit aussi les groupes de la personne, qui servent ensuite à la propriété des composants.
Signal d'alerteActiver le fournisseur invité en production, ou un résolveur qui laisse entrer tout le monde sans correspondance dans le catalogue.
Question 5 · confirmé
On vous demande de vérifier que chaque service a une documentation, un runbook et des alertes. Comment l'automatisez-vous dans le portail ?
Une bonne réponseDes scorecards : avec Tech Insights (open source), Soundcheck (module commercial de Spotify) ou l'équivalent d'un portail du marché. Des collecteurs lisent des faits dans les dépôts et les outils (présence d'un mkdocs.yml, lien de runbook, règles d'alerte déclarées dans la supervision), des contrôles les comparent à un seuil, le résultat s'affiche par composant et par équipe. Les contrôles portent sur des faits vérifiables, et le template standard crée d'emblée ce qui est demandé.
Signal d'alerteUn tableur rempli par les équipes. Ou un contrôle qui ne regarde que la présence d'une annotation, alors qu'elle peut pointer vers une page vide.
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
Poste Backstage : les questions fréquentes
Quelle part de TypeScript le poste demande-t-il vraiment ?
Plus que ce que suggère le titre. Les templates s'écrivent en YAML, mais les actions sur mesure, les plugins et l'application elle-même sont en TypeScript, avec React pour l'interface. Un profil qui ne lit pas ce code dépendra des plugins existants. Un test technique court suffit à le voir : un plugin backend à compléter ou une action de scaffolder à écrire, commentés à voix haute pendant trente minutes.
Backstage, Port ou Cortex : quel profil pour quel outil ?
Le profil suit l'outil. Avec Backstage assemblé par l'équipe, il faut quelqu'un qui code et maintient un monorepo TypeScript, en plus de l'infrastructure. Avec Red Hat Developer Hub, la part de code baisse grâce aux plugins dynamiques, mais l'exploitation sur OpenShift entre en jeu. Avec Port ou Cortex, le travail porte surtout sur le modèle de données, les intégrations et les scorecards. L'outil se précise dans l'offre.
Comment savoir si un candidat a fait vivre un portail ou seulement installé Backstage ?
Les chiffres et les noms le disent. Combien d'entités au catalogue, d'où venaient les équipes, quel template était le plus utilisé, quel plugin a été écrit en interne et pourquoi. Le récit d'une montée de version qui a cassé quelque chose aussi. Un profil qui n'a connu qu'un POC répond par les fonctionnalités de Backstage, sans données d'usage ni incident.
Quelle expérience de Backstage attendre d'un ingénieur DevOps qui postule ?
Aucune, s'il code. Un ingénieur DevOps qui connaît Kubernetes, Argo CD et la CI apporte la moitié du poste, à savoir les intégrations et ce que les templates doivent créer. Il lui reste le modèle du catalogue et le développement de plugins. Son aisance en TypeScript ou dans un langage proche compte, et il faut prévoir quelques semaines sur le framework lui-même.
Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.
