Portail vs plateforme de développement interne
Portail ou plateforme ? L’union fait la force.
Un portail affiche. Cycloid agit. Votre équipe plateforme livre le portail dont vos équipes ont besoin sans partir de zéro, et les développeurs disposent du catalogue et des parcours gouvernés pour passer à l’action, au même endroit.
Ils nous font confiance
L’écueil du portail seul
Un portail posé sur du travail manuel, c’est toujours du travail manuel
La plupart des équipes commencent par un portail. Il indique à un développeur qui est responsable d’un service, où il tourne et de quoi il dépend. Puis il lui faut un nouvel environnement, et le portail lui tend un formulaire de ticket. Un ticket déposé via un portail, ce n’est pas du libre-service. C’est une commande automatisée.
L’écueil du portail seul
Un portail posé sur du travail manuel, c’est toujours du travail manuel
La plupart des équipes commencent par un portail. Il indique à un développeur qui est responsable d’un service, où il tourne et de quoi il dépend. Puis il lui faut un nouvel environnement, et le portail lui tend un formulaire de ticket. Un ticket déposé via un portail, ce n’est pas du libre-service. C’est une commande automatisée.
Portail seul
Ce que c’est
Le front-end que consultent les développeurs
Ce qu’il contient
Le catalogue, les responsables, le graphe de dépendances, les scorecards
Pour qui
Les développeurs qui cherchent
Gouvernance
Montre qui est responsable de quoi
Où il s’arrête
Au formulaire de ticket
+
Plateforme seule
Ce que c’est
L’automatisation et les règles en coulisses
Ce qu’il contient
Blueprints, Forms, runners, promotion, actions Day-2
Pour qui
Les équipes plateforme qui construisent les parcours
Gouvernance
Applique les règles à l’exécution
Où il s’arrête
À un pipeline que seule l’équipe plateforme sait trouver
=
Ce que c’est
Les deux, sur un référentiel unique
Ce qu’il contient
Les deux, avec l’action à côté de la vue
Pour qui
Les deux, plus les dirigeants qui suivent l’adoption et l’audit
Gouvernance
Autorisation en quatre couches avant toute création, journalisée dans tous les cas
Où il s’arrête
Dans les garde-fous que vous fixez
Qui y gagne quoi
Ce que portail et plateforme changent pour votre équipe
Un même référentiel, trois raisons de s’y intéresser.
Construisez la plateforme, pas la glue
Le problème
Vous gérez un portail, une pile de scripts derrière, et vous maintenez les deux.
Avec Cycloid
Publiez des Blueprints, définissez une fois les types d’environnement, les règles de nommage et les approbations. Exécutez le tout sur le Native Runner ou sur la CI que vous avez déjà.
Le résultat
Vous fixez les garde-fous. Votre équipe n’aura pas moins de travail. Elle aura un meilleur travail.
Voir, puis agir
Le problème
Vous voyez votre application. Souvent, vous ne voyez pas ce sur quoi elle tourne, et la modifier implique un ticket.
Avec Cycloid
Choisissez un Golden Path ou un Form, déployez, puis promouvez et lancez des actions Day-2 depuis la même page.
Le résultat
Pas de file de tickets sur les parcours structurés. Des approbations seulement là où le risque l’exige.
Un seul endroit pour savoir si ça marche
Le problème
Deux outils à financer, et toujours aucune vue unique de l’adoption ou de la conformité.
Avec Cycloid
Une seule plateforme avec analyse de l’adoption, tableaux de bord et journal d’audit. SaaS, auto-hébergée ou air-gapped.
Le résultat
Une adoption mesurable, et des contrôles qui s’exécutent avant le déploiement.
Comment ça fonctionne
Du catalogue à la production, sur un référentiel unique
1Catalogue et Golden Paths
Le catalogue liste les services, les landing zones et les environnements, chacun avec son responsable. À côté de chacun se trouve le Blueprint qui le construit, versionné et publié par votre équipe plateforme, avec synchronisation Git si vous le souhaitez.
2Des Forms qui vérifient avant de créer
Votre équipe plateforme choisit les questions. Le formulaire les pose. Un Form transforme les entrées d’un Blueprint en listes déroulantes, champs conditionnels et sélecteurs alimentés par l’inventaire des ressources. Chaque soumission est validée, et une demande non conforme est refusée avant que la ressource n’existe. Vous travaillez en GitOps ? Le plugin Git commite les fichiers générés dans votre dépôt.
3Native Runner ou votre CI
Les exécutions passent par le Native Runner, sous votre contrôle, ou par la CI que vous avez déjà. Les développeurs suivent l’état et les logs depuis le portail, et les étapes en échec peuvent être relancées, et vous rétablissez le service en redéployant une nouvelle version.
4Garde-fous et audit
L’autorisation en quatre couches contrôle chaque action, qu’elle soit lancée par une personne ou par un assistant. Les types d’environnement et les règles de nommage s’appliquent dès la création, les approbations interviennent là où le risque ou la responsabilité l’exigent, et le journal d’audit consigne chaque oui et chaque non. Les garde-fous d’abord. Un humain seulement là où il apporte quelque chose.
5Promouvoir et exécuter
Les chemins de promotion font passer les builds de dev à QA, staging puis prod selon vos règles, y compris avec un seuil de scorecard, par exemple Silver ou mieux. Les actions Day-2 se trouvent dans le Blueprint, à côté du déploiement, et s’affichent sur la page de la ressource.
Un portail seul vous dit ce qui existe. Une plateforme seule exécute des choses que personne ne voit. Cycloid réunit les deux sur un référentiel unique : la page qui affiche un service est celle depuis laquelle vous le modifiez, et chaque changement passe les mêmes contrôles, humain ou assistant.
Par quoi commencer ?
La plupart des équipes n’ont pas besoin d’un portail d’abord. Elles ont besoin qu’il exécute quelque chose.
Le portail n’est pas la partie difficile. Ce sont les parcours derrière lui. Le rapport DORA 2025 a constaté que 90 % des organisations ont adopté au moins une plateforme, et a relié les plateformes de qualité à la capacité de tirer parti de l’IA. Partez donc des frictions réelles de vos développeurs, l’environnement qui prend une semaine ou le changement qui mobilise trois personnes, et construisez d’abord le Blueprint correspondant. Le catalogue se remplit à mesure que ces parcours sont mis en service, car ce que vous déployez via Cycloid y est référencé avec son équipe. Vous utilisez déjà Backstage ? Les deux peuvent coexister le temps de comparer, et vos modules IaC et votre CI restent où ils sont.
Ce que livrent les équipes
Portail et plateforme réunis, en production
Moins de 4 semaines
de la migration cloud à la mise en production complète, cloudXcelerate
Certifié B Corp
Certifié ISO 27001
COOL VENDOR 2024
Cool Vendor 2024
HYPE CYCLE 2026
Platform Engineering
Travailler avec votre assistant
Demandez ce qui existe, puis agissez
Demandez à votre assistant qui est responsable d’un service et de quoi il dépend, puis demandez-lui une copie en staging. La réponse vient du catalogue, et la demande revient sous la forme du même Form que celui du portail, règles de nommage comprises.
Rien de conséquent ne s’exécute tant que vous n’avez pas confirmé. Le journal d’audit enregistre la session de l’assistant et la personne pour laquelle il a agi.
L’assistant a-t-il ses propres droits ?
Non. Il n’y a ni compte de service ni rôle d’assistant aux droits étendus. Si vous ne pouvez pas déployer en production, l’assistant avec lequel vous échangez ne le peut pas non plus, que ce soit l’assistant de Cycloid ou n’importe quel hôte MCP compatible.
Qui est responsable d’orders-api ? Puis créez une copie en staging.
C’est l’équipe Orders. Voici le formulaire.
Form · orders-api, Blueprint v3.1
Type d’environnement
staging
Nom
orders-api-stg
Règle de nommage
Validée
Questions fréquentes
Quelle différence entre un portail et une plateforme de développement interne ?
Le portail est le front-end : le catalogue, les responsables, la documentation et les scorecards que consultent les développeurs. La plateforme est ce qui tourne derrière : le provisionnement, les pipelines et les politiques. Cycloid vous donne les deux sur un référentiel unique, pour agir sur ce que vous voyez.
Faut-il à la fois un portail et une plateforme ?
Si vos développeurs voient un service mais doivent encore ouvrir un ticket pour le modifier, oui. Un portail seul déplace la file d’attente. Avec les deux, les demandes structurées passent en libre-service, et les approbations ne s’appliquent que là où le risque l’exige.
Peut-on conserver notre CI et nos workflows Git ?
Oui. Cycloid s’appuie sur l’IaC et la CI que vous avez déjà, sans les remplacer. Les exécutions passent par le Native Runner, sous votre contrôle, ou par votre propre CI, et Git est facultatif : synchronisez les Blueprints depuis un dépôt, ou commitez la sortie des Forms si vous travaillez en GitOps.
Nous utilisons déjà Backstage. Faut-il choisir ?
Non. Backstage vous donne un framework, et tout ce qui est construit dessus reste à développer et à maintenir par vous. Cycloid vous fournit le catalogue et la plateforme qui le sous-tend sous forme de produit. Les deux peuvent coexister le temps de comparer.
Vue d’ensemble
Trois piliers, un seul portail de développement interne
Tout ce que fait Cycloid relève de l’un de ces trois piliers. Commencez par celui qui vous freine.
Pilier 01
Un libre-service qui ne s’arrête pas au déploiement : exécutez, promouvez et composez dans un seul portail.
Pilier 02
Chaque service, chaque responsable, chaque dépendance, au même endroit.
Pilier 03
Les garde-fous dont votre plateforme a besoin, sans partir de zéro.
Apportez la demande qui reste toujours dans la file
Réservez 20 minutes. Nous vous montrons le portail et la plateforme sur un référentiel unique, à l’œuvre sur une demande comme la vôtre.