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.

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

Qui obtient quoi du portail et de la plateforme

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

Jusqu’à 5 000 développeurs

sur un seul portail, Commission européenne

Moins de 4 semaines

de la migration cloud à la mise en production complète, cloudXcelerate

Livraison 4x plus rapide

Orange Business

B Corp certification mark (transparent)

Certifié B Corp

ISO 27001 certification mark (transparent)

Certifié ISO 27001

Gartner wordmark (trimmed)

COOL VENDOR 2024

Cool Vendor 2024

Gartner wordmark (trimmed)

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

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.

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.

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.

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, une seule plateforme

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.