Chaque équipe d’ingénierie l’a déjà vécu : un développeur doit créer un nouveau namespace Kubernetes pour tester un service de manière isolée. Ou peut-être déployer une base de données PostgreSQL temporaire pour déboguer un problème en staging. Au lieu de le provisionner eux-mêmes, ils ouvrent un ticket à l’équipe DevOps. Puis ils attendent. Parfois des heures. Parfois des jours.
Cette attente n’est pas due à la lenteur de l’équipe DevOps. C’est parce qu’elle est déjà surchargée — à résoudre des problèmes de production, à examiner des pull requests d’infrastructure, à gérer les jobs CI/CD, à faire tourner les secrets et à répondre aux alertes. Une demande apparemment simple, comme configurer un namespace ou une base de données, se retrouve souvent en bas de la file d’attente.
À mesure que les équipes grandissent et livrent plus vite, cette friction s’aggrave. Les développeurs se retrouvent bloqués à attendre des ressources, et le DevOps devient un goulot d’étranglement. Tout le monde finit par contourner les délais plutôt que de les résoudre.
Un portail en libre-service résout ce problème en donnant aux développeurs un accès contrôlé à l’infrastructure dont ils ont besoin — sans passer par des tickets ou des fils Slack. Pour les équipes qui débutent, il est courant de se demander ce qu’est un portail en libre-service et comment il s’intègre dans leur workflow.
Dans cet article, nous verrons pourquoi le libre-service développeur est important, comment il s’intègre dans les workflows DevOps existants, et nous parcourrons un exemple de construction d’un portail en libre-service avec Backstage, puis avec la plateforme Cycloid.
Pourquoi les développeurs ont-ils besoin d’un portail en libre-service ?
Dans de nombreuses organisations, les développeurs dépendent des équipes plateforme ou DevOps pour provisionner l’infrastructure de base. Même les demandes simples — comme créer un environnement de test, lancer une instance PostgreSQL temporaire ou déployer un microservice derrière un load balancer — nécessitent souvent de soumettre un ticket et d’attendre son tour.
Ce ne sont pas des cas rares ; ce sont des actions courantes et répétables. Mais parce qu’elles dépendent de quelqu’un d’autre pour les approuver et les exécuter, elles ralentissent les équipes. Les équipes plateforme sont débordées, les files d’attente grossissent, et même les petits changements commencent à sembler lourds. Des erreurs se glissent également — comme des configurations de sécurité manquantes, un balisage incohérent ou des environnements mal alignés.
C’est là qu’un portail en libre-service fait une vraie différence. Au lieu de faire passer tout par une équipe centrale, les développeurs accèdent à des workflows pré-approuvés qu’ils peuvent exécuter eux-mêmes. Ils n’écrivent pas du Terraform ni ne naviguent dans la console AWS. Ils remplissent un court formulaire qui déclenche une automatisation en coulisses — utilisant de l’infrastructure-as-code qui suit déjà les bonnes pratiques de l’organisation.
Par exemple, un template peut automatiquement appliquer le chiffrement, la sélection de région, le placement de sous-réseau et le balisage pour chaque ressource qu’il provisionne. Les développeurs obtiennent rapidement les environnements dont ils ont besoin. Et l’équipe plateforme garde le contrôle — sans être dans la boucle pour chaque demande. Ce modèle de libre-service réduit la dépendance opérationnelle tout en maintenant la sécurité et l’auditabilité.
Des portails comme Backstage rendent ce modèle plus pratique. Backstage est un framework de plateforme en libre-service open source qui aide à exposer ces workflows aux développeurs via une interface cohérente. Des équipes comme Monday.com utilisent ce pattern pour permettre aux ingénieurs de lancer de nouveaux services, environnements et jobs en quelques minutes — tout en gardant tout gouverné et traçable.
Le libre-service ne signifie pas abandonner le contrôle. Il s’agit d’habiliter les développeurs — en leur donnant un accès sécurisé à une infrastructure reproductible pour qu’ils puissent avancer plus vite sans ouvrir de tickets pour chaque petite tâche.
Comment un portail en libre-service s’intègre-t-il dans les workflows DevOps ?
Un portail en libre-service ne se contente pas d’accélérer les demandes — il change la façon dont l’infrastructure est gérée dans toute l’organisation. Il s’intègre parfaitement dans les workflows DevOps modernes en transférant la charge d’exécution sans sacrifier les standards ni le contrôle. Les développeurs peuvent avancer de manière autonome, tandis que les équipes plateforme et DevOps gardent le contrôle sur ce qui est réellement provisionné.
Transformer les tâches manuelles en workflows réutilisables
Traditionnellement, les changements d’infrastructure impliquent une coordination manuelle — même si Terraform ou CloudFormation est utilisé. Un développeur écrit le code, ouvre une pull request, attend qu’un ingénieur DevOps la révise, puis quelqu’un approuve et exécute l’étape terraform apply. Chacune de ces étapes nécessite un humain dans la boucle, ce qui est la source des délais.
Avec une configuration en libre-service, ces tâches sont transformées en templates réutilisables. L’équipe DevOps encode toutes les règles nécessaires — configs de région, permissions IAM, tags de centre de coûts — dans des modules Terraform ou des scripts CLI. Ceux-ci sont ensuite enveloppés dans de simples formulaires auxquels les développeurs accèdent via un portail comme Backstage.
Désormais, quand un développeur a besoin d’une instance RDS ou d’un nouveau bucket S3, il n’ouvre pas de ticket — il remplit simplement un formulaire. En coulisses, le même code Terraform est appliqué, les mêmes permissions sont utilisées — mais cela se produit automatiquement.
Intégration avec les workflows CI/CD et GitOps existants
Cette configuration ne remplace pas vos workflows existants — elle s’y intègre. Que vous utilisiez GitHub Actions, GitLab CI ou tout autre outil CI/CD, un portail en libre-service peut se connecter directement dans votre pipeline et déclencher la même automatisation d’infrastructure que vous utilisez déjà.
Par exemple, une demande via le portail pourrait déclencher un workflow qui :
- Crée un dépôt GitHub
- Pousse les configs Terraform par défaut
- Exécute terraform apply
- Met à jour le catalogue de services
- Notifie le développeur quand c’est terminé
Ces étapes suivant les mêmes règles de pipeline que le reste de votre infrastructure, vous obtenez cohérence et auditabilité sans avoir besoin d’impliquer quelqu’un de votre équipe.
Gérer les permissions sans complications
La gestion des accès dans le cloud est souvent là où les choses commencent à se compliquer. Les équipes doivent savoir qui est autorisé à créer des ressources, qui en est propriétaire et quelles limites sont en place. Sans système clair, ces décisions se prennent informellement — peut-être via un message Slack, ou enfouies dans un vieux script que personne ne se souvient d’avoir écrit.
Un portail en libre-service résout cela en utilisant le contrôle d’accès basé sur les rôles. L’accès n’est pas décidé à la volée ; il est lié aux équipes et aux permissions définies par l’organisation. Par exemple, seuls les membres de l’équipe data peuvent créer des clusters Redshift. Les développeurs de l’équipe frontend n’ont accès qu’à certains buckets S3 ou fonctions Lambda.
Cette approche supprime les approximations. Tout le monde sait ce qu’il peut et ne peut pas faire. Elle rend également le système plus sécurisé et plus facile à gérer à mesure que l’entreprise grandit. Au lieu de s’appuyer sur la mémoire ou les approbations manuelles, l’accès est automatisé et clairement défini en un seul endroit.
Maintenir la gouvernance et le contrôle
Donner aux développeurs un accès direct ne signifie pas abandonner le contrôle. Tout ce qu’ils font via le portail est prédéfini et approuvé par l’équipe DevOps. Des conventions de nommage des ressources aux groupes de sécurité, chaque configuration est intégrée dans l’automatisation sous-jacente.
Au lieu de réviser chaque demande, l’équipe DevOps révise les templates. Une fois quelque chose encodé dans un template, cela devient la source de vérité. Ainsi, l’infrastructure reste conforme — même quand les développeurs la provisionnent eux-mêmes.
Un portail en libre-service apporte de la structure à la façon dont l’infrastructure est demandée et gérée. Les développeurs peuvent avancer plus vite parce qu’ils n’ont plus à attendre que quelqu’un crée des ressources pour eux. En même temps, les équipes DevOps gardent le contrôle en définissant les règles à l’avance.
Cette approche est bénéfique pour les deux parties. Les développeurs ne sont plus bloqués, et les équipes DevOps ne sont plus noyées sous des tickets de routine. Les portails en libre-service apportent clarté, cohérence et autonomie dans le provisionnement d’infrastructure entre les équipes.
Tout passe par une automatisation déjà approuvée, donc rien ne contrevient aux standards ou aux politiques.
À mesure que les entreprises évoluent, cette façon de travailler devient essentielle. Elle maintient l’organisation, réduit les erreurs et facilite la gestion des ressources cloud entre projets et environnements. Un bon portail en libre-service n’est pas seulement une commodité — c’est un élément clé pour faire évoluer votre processus de développement correctement.
Comment configurer un portail en libre-service avec Backstage
Nous avons vu comment les portails en libre-service suppriment les goulots d’étranglement en permettant aux développeurs de provisionner l’infrastructure sans attendre le DevOps. Voyons maintenant comment construire un exemple concret avec Backstage.
Nous allons créer un template Backstage qui permet aux développeurs de créer un bucket S3 avec quelques champs de saisie. Le processus déclenchera l’AWS CLI en coulisses, mais le développeur ne verra jamais cette complexité. À la fin, nous aurons une expérience de portail entièrement automatisée.
Étape 1 : Créer le répertoire du template
Commençons par créer un dossier dédié pour notre template :
mkdir -p packages/backend/templates/s3-bucket
Dans ce dossier, nous définirons le fichier template.yaml, et nous pourrons optionnellement inclure des fichiers supplémentaires comme README.md, des scripts réutilisables ou des actions personnalisées.
Étape 2 : Définir le YAML du template
Définissons maintenant notre template dans
packages/backend/templates/s3-bucket/template.yaml:
| apiVersion: scaffolder.backstage.io/v1beta3 kind: Template metadata: name: create-s3-bucket title: Create an S3 Bucket description: Provisions an S3 bucket using AWS CLI and applies basic settings spec: owner: cloud-team type: infrastructure parameters: – title: Bucket Configuration required: – bucketName – region – visibility properties: bucketName: type: string title: S3 Bucket Name region: type: string title: AWS Region default: us-east-1 visibility: type: string title: Visibility enum: – private – public steps: – id: validate name: Validate Inputs action: debug:log input: message: Creating bucket « ${{ parameters.bucketName }} » in region « ${{ parameters.region }} » with visibility « ${{ parameters.visibility }}« – id: create name: Create Bucket action: execute:script input: script: | aws s3api create-bucket \ –bucket ${{ parameters.bucketName }} \ –region ${{ parameters.region }} \ –create-bucket-configuration LocationConstraint=${{ parameters.region }} if [ « ${{ parameters.visibility }} » = « public » ]; then aws s3api put-bucket-acl \ –bucket ${{ parameters.bucketName }} \ –acl public-read fi aws s3api put-bucket-versioning \ –bucket ${{ parameters.bucketName }} \ –versioning-configuration Status=Enabled |
Ce template donne à votre portail en libre-service un titre, une description, des champs de formulaire et des étapes d’exécution. Les développeurs fournissent simplement un nom, une région et un niveau de visibilité — tout le reste est géré par le script backend.
Étape 3 : Enregistrer le template dans app-config.yaml
Dans votre fichier racine app-config.yaml, ajoutez ou mettez à jour la section des emplacements du catalogue comme suit :
| catalog: locations: – type: file target: ./packages/backend/templates/s3-bucket/template.yaml |
Puis redémarrez Backstage :
| yarn dev |
Vous verrez maintenant le template « Create an S3 Bucket » listé dans la section Create.
Étape 4 : Ajouter la prise en charge de scripts personnalisés
Au lieu d’intégrer de longs scripts shell dans le fichier template.yaml, nous pouvons extraire la logique dans un fichier de script.
Créez ce fichier :
| touch packages/backend/templates/s3-bucket/create-bucket.sh chmod +x packages/backend/templates/s3-bucket/create-bucket.sh |
| #!/bin/bash BUCKET_NAME=$1 REGION=$2 VISIBILITY=$3 aws s3api create-bucket \ –bucket « $BUCKET_NAME« \ –region « $REGION« \ –create-bucket-configuration LocationConstraint=« $REGION« if [ « $VISIBILITY« = « public » ]; then aws s3api put-bucket-acl \ –bucket « $BUCKET_NAME« \ –acl public-read fi aws s3api put-bucket-versioning \ –bucket « $BUCKET_NAME« \ –versioning-configuration Status=Enabled |
Mettez maintenant à jour l’étape execute:script dans template.yaml comme ceci :
| – id: create name: Run Script action: execute:script input: script: | ./packages/backend/templates/s3-bucket/create-bucket.sh \ « ${{ parameters.bucketName }} » \ « ${{ parameters.region }} » \ « ${{ parameters.visibility }} » |
Cela améliore la lisibilité et vous permet de réutiliser le script pour d’autres templates.
Étape 5 : Mettre à jour le Dockerfile pour inclure l’AWS CLI
Mettez à jour votre packages/backend/Dockerfile (ou là où votre backend est construit) :
| FROM node:18 # Install AWS CLI RUN apt-get update && \ apt-get install -y curl unzip && \ curl « https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip » -o « awscliv2.zip » && \ unzip awscliv2.zip && ./aws/install WORKDIR /app COPY . . RUN yarn install –frozen-lockfile CMD [« yarn », « start »] |
Vous pouvez vérifier la disponibilité du CLI en ajoutant ceci au script :
| aws –version |
Étape 6 : Configurer les credentials AWS
Utilisez l’une des options suivantes :
- Variables d’environnement (via fichier .env ou shell) :
| export AWS_ACCESS_KEY_ID=your-key export AWS_SECRET_ACCESS_KEY=your-secret |
- Monter les credentials AWS locaux en développement :
| docker run -v ~/.aws:/root/.aws … |
Étape 7 : Créer le bucket depuis Backstage
Depuis l’interface Backstage, les développeurs peuvent utiliser le portail en libre-service pour accéder à la page de création.
- Accédez à Create
- Sélectionnez le template « Create an S3 Bucket »
- Remplissez le formulaire : nom du bucket et région
- Cliquez sur Next → Review → Create
Nous venons de créer une configuration en libre-service fonctionnelle pour AWS S3 avec Backstage. Les développeurs disposent maintenant d’une interface où ils peuvent remplir un formulaire, cliquer sur « Create » et obtenir un bucket — automatisé, cohérent et sécurisé.
Le même pattern peut être étendu pour créer des instances EC2, des utilisateurs IAM, des fonctions Lambda, et même des applications complètes avec des pipelines CI/CD.
Comment Cycloid gère la gestion des actifs cloud sur plusieurs clouds
La configuration d’un portail en libre-service avec Backstage nous a donné flexibilité et contrôle, mais a également demandé beaucoup d’efforts. Chaque partie de l’expérience — structure du catalogue, templates, scripts, workflows — devait être assemblée pièce par pièce. Bien que cette modularité soit puissante, la responsabilité de maintenir l’ensemble repose entièrement sur l’équipe d’ingénierie.
Pour les organisations souhaitant avancer plus vite sans tout construire de zéro, Cycloid propose une approche très différente. Elle offre la même expérience de libre-service développeur et de gouvernance — mais sans vous demander d’héberger ou de construire le portail vous-même.
L’interface de Cycloid est prête à l’emploi dès votre connexion. Au lieu de câbler des plugins ou d’étendre des définitions YAML, vous accédez directement à un tableau de bord qui affiche déjà votre activité cloud, les métriques d’utilisation et les informations clés de vos projets. Elle est conçue pour les équipes qui veulent se concentrer sur la livraison d’infrastructure, pas sur la maintenance des outils autour.
Depuis ce tableau de bord, vous pouvez tout surveiller — de la santé des projets aux exécutions de pipelines et aux données FinOps. Pas besoin de connecter séparément un outil de métriques ou un tracker de coûts cloud ; tout est inclus.
Là où Backstage nous demandait de définir manuellement les workflows d’infrastructure via des templates et des scripts, Cycloid vous permet de définir des modules réutilisables via des Stacks. Chaque stack agit comme une unité d’infrastructure packagée — une VM, un cluster Kubernetes, un bucket S3 — que vos équipes peuvent provisionner via de simples formulaires. Celles-ci sont alimentées par votre logique Terraform ou Ansible existante, donc vous ne réécrivez rien. Vous l’abstraiez simplement d’une manière qui permet à d’autres équipes de l’utiliser en toute sécurité.
Toutes les stacks sont versionnées et stockées dans votre dépôt Git, vous offrant la même transparence et traçabilité que vous attendriez d’un workflow GitOps. Mais au lieu de tout câbler via des plugins Backstage, Cycloid gère pour vous l’interface et l’orchestration du cycle de vie. L’interface, les formulaires de saisie et même les vérifications de permissions sont déjà câblés. Vous n’avez qu’à définir quelles variables exposer et comment l’infrastructure doit être appliquée.
Une fois qu’une stack est déclenchée, Cycloid exécute automatiquement le pipeline associé et vous donne une visibilité sur sa progression. Cycloid gère la visibilité, l’automatisation et l’inventaire out of the box — sur AWS, GCP, Azure et les environnements hybrides. Vous n’avez pas besoin de gérer manuellement les pipelines ou les plugins.
Cette visibilité intégrée change la façon dont les équipes opèrent. Vous n’avez plus besoin de passer d’une console cloud à l’autre ou de demander des accès. Tout est visible en un seul endroit, et l’accès est contrôlé par des rôles et des mappings de groupes prédéfinis. Si quelqu’un crée une instance EC2 ou un workload Kubernetes, cela apparaît dans l’inventaire, mappé à la bonne équipe et au bon environnement.
Cycloid expose également cet inventaire via des APIs, permettant aux équipes d’extraire des données d’actifs dans leurs propres tableaux de bord, d’automatiser des tâches de nettoyage ou de le connecter à des moteurs de politique. Elle agit non seulement comme un portail, mais comme une couche de liaison entre l’infrastructure, l’automatisation et la gouvernance.
La différence clé réside dans ce que vous devez construire vous-même. Avec Backstage, vous mettez d’abord en place la fondation — catalogues, actions, plugins — et vous ajoutez des fonctionnalités par-dessus. Avec Cycloid, la fondation est déjà posée. Vous apportez votre Terraform, vos pipelines et vos credentials cloud — et tout le reste, de l’interface à l’inventaire, est déjà là qui vous attend.
Avec Backstage, vous construisez le portail et l’automatisation. Avec Cycloid, vous vous concentrez uniquement sur l’automatisation. Ce changement — passer de la construction du framework à simplement brancher votre propre logique — fait une énorme différence en termes de rapidité, d’effort et de retour sur investissement.
Conclusion
Les portails en libre-service aident les équipes à avancer plus vite en donnant aux développeurs les outils pour provisionner l’infrastructure eux-mêmes — de manière sécurisée et cohérente. Que vous construisiez votre propre configuration avec Backstage ou utilisiez une plateforme prête à l’emploi comme Cycloid, l’objectif reste le même : réduire les temps d’attente, éviter les goulots d’étranglement manuels et garder le contrôle entre les mains de votre équipe DevOps.
Si vous débutez, Backstage vous offre un contrôle total. Si vous voulez avancer vite avec moins de configuration, Cycloid vous donne tout out of the box. Choisissez le chemin qui convient à votre équipe — et commencez à libérer vos développeurs dès aujourd’hui.
Foire Aux Questions
Qu’est-ce qu’un portail en libre-service en DevOps ?
Un portail en libre-service permet aux développeurs de provisionner de l’infrastructure ou des services eux-mêmes en utilisant des templates pré-approuvés, réduisant la dépendance vis-à-vis des équipes DevOps.
Pourquoi utiliser Backstage pour construire un portail en libre-service ?
Backstage est open source, hautement extensible et s’intègre bien avec les outils CI/CD — ce qui en fait un choix idéal pour exposer l’automatisation d’infrastructure via une interface facile à utiliser.
Pourquoi utiliser Cycloid comme portail en libre-service ?
Cycloid offre l’expérience de libre-service développeur et la gouvernance, avec une interface prête à l’emploi dès la connexion. Il agit non seulement comme un portail, mais comme une couche de liaison entre l’infrastructure, l’automatisation et la gouvernance.
Est-il possible de faire évoluer un portail en libre-service pour une grande équipe ?
Oui, grâce au contrôle d’accès basé sur les rôles, aux templates réutilisables et aux pratiques GitOps, les portails en libre-service peuvent évoluer de manière sécurisée sur plusieurs équipes et environnements.
Quelle est la meilleure façon de mettre en œuvre un portail en libre-service en entreprise ?
Commencez par un cas d’usage simple comme le provisionnement S3, définissez des règles de gouvernance claires, et étendez progressivement avec des outils comme Backstage ou des plateformes comme Cycloid pour une adoption plus rapide.
