/
Cycloid vs Port
Un apply Terraform s’exécute proprement dans le CI ; sans erreurs, sans avertissements, tout au vert. Deux ingénieurs lancent un cluster proof-of-concept pour un test de performance, oublient de le tagger et le laissent tourner pendant trois semaines. La facture arrive. Personne ne l’a vu venir parce que rien ne le leur a montré.
vs
Rédigé par
L’équipe Cycloid
Platform engineering
Mis à jour
Octobre 2026
Temps de lecture
11 min
Où doit se situer le contrôle de la plateforme ?
Ce scénario illustre la différence entre avoir de la visibilité sur votre infrastructure et avoir le contrôle de celle-ci. Les deux problèmes se ressemblent depuis le tableau de bord d’un manager, mais nécessitent des outils fondamentalement différents pour être résolus.
Cependant, Port a été conçu pour le second camp. Il centralise la connaissance des actifs logiciels et d’infrastructure dans un catalogue qui se met à jour en temps réel via des intégrations, puis permet aux équipes de construire des scorecards, des actions libre-service et des workflows d’approbation sur ce catalogue. La plateforme n’exécute pas de Terraform et ne gère pas d’état directement — elle expose ce que font vos systèmes existants.
Le compromis fondamental
Port
Les équipes de plateforme abordent généralement cette question après un incident spécifique plutôt que dans le cadre d’un exercice stratégique. Un espace de travail Terraform applique un changement que personne n’a revu. Un cluster proof-of-concept reste actif pendant des semaines parce qu’aucun workflow de décommissionnement n’existe. Un ingénieurs déploie en production depuis la mauvaise branche parce que les protections de branche n’ont pas rattrapé la configuration CI.
La plateforme unique
Cycloid est conçu pour les équipes qui traitent la livraison d’infrastructure comme un système de production à part entière. Les plans Terraform, les approbations, les vérifications de politiques et la gestion de l’état vivent à l’intérieur de la plateforme, et non dans une collection de scripts CI assemblés au fil du temps.
Matrice de décision
Comparatif des fonctionnalités : Cycloid vs Port
Cette comparaison est rédigée pour les ingénieurs de plateforme et les responsables DevOps qui prennent une décision concrète. L’accent est mis sur l’endroit où l’application se produit, ce que la plateforme possède réellement et ce que vous devez encore construire ou gérer vous-même.
01
Déploiement, architecture et périmètre des données
Port aborde le déploiement depuis une prémisse différente. Comme Port n’exécute pas de changements d’infrastructure ni Terraform directement, il ne détient jamais de credentials de fournisseur cloud. Ce que Port ingère, ce sont des métadonnées : définitions de ressources Kubernetes, détails de dépôts GitHub, enregistrements de propriété de services PagerDuty, états des moniteurs Datadog, résultats d’exécution de pipelines CI/CD. Les intégrations Ocean, la couche de synchronisation de données de Port, peuvent s’exécuter en tant qu’agents dans le réseau d’un client pour extraire ces métadonnées sans exposer les systèmes internes, tandis que le catalogue et le portail restent sur l’infrastructure cloud de Port. Les clients entreprise peuvent demander une connectivité Private Link ou discuter d’une location dédiée, mais le runtime reste SaaS.
La frontière pratique ici concerne ce que chaque plateforme touche. Une équipe réglementée utilisant Cycloid en auto-hébergé conserve chaque credential, chaque fichier d’état et chaque enregistrement d’approbation dans son propre périmètre. Une équipe utilisant Port ne conserve que les métadonnées du catalogue dans le cloud de Port : noms de services, enregistrements de propriété, résultats de scorecards et propriétés issues des intégrations. Aucun modèle n’est faux. La question est de savoir si vos exigences de conformité s’étendent à l’exécution IaC et à la gestion des credentials, ou uniquement à la couche de métadonnées organisationnelles.
Conclusion : Cycloid est le bon choix lorsque les exigences de déploiement et d’hébergement s’étendent à l’exécution IaC, à la gestion des credentials et à l’application des politiques au sein d’un réseau contrôlé. Port convient lorsque le besoin est un portail développeur SaaS qui fait remonter la connaissance de l’organisation sans posséder le chemin d’exécution de l’infrastructure.
FONCTIONNALITÉ
PORT
Modèles de déploiement
SaaS mutualisé, instance dédiée managée ou entièrement auto-hébergé, y compris les réseaux privés isolés et les environnements air-gapped
SaaS uniquement ; les clients entreprise peuvent demander une location dédiée et une connectivité Private Link
Contrôle de la résidence des données
Contrôle total en mode auto-hébergé ; les fichiers d’état, journaux d’exécution, credentials et enregistrements d’approbation restent entièrement dans l’infrastructure contrôlée par le client
Données stockées dans des bases dédiées au client sur AWS ; les agents Ocean peuvent s’exécuter dans le réseau du client, mais le portail et le catalogue restent dans le cloud de Port
Propriété du runtime de la plateforme
Le client ou Cycloid gère l’intégralité du plan de contrôle selon le modèle de déploiement choisi
Port opère le runtime hébergé sur AWS ; les clients contrôlent la configuration mais n’ont pas accès à l’infrastructure sous-jacente
Gestion des credentials d’infrastructure
Les clés d’accès AWS, les comptes de service GCP et les service principals Azure sont stockés et délimités dans la plateforme, et utilisés au moment de l’exécution
Port ne stocke pas les credentials des clients ; tous les accès cloud s’effectuent dans des systèmes externes à Port
Adaptation aux environnements réglementés
Adapté lorsque l’exécution IaC, la gestion des credentials, l’application des politiques et le stockage des états doivent rester dans un réseau privé ou isolé
Adapté lorsque les exigences de conformité concernent les métadonnées du catalogue et les données organisationnelles, mais pas l’exécution IaC ni la gestion des credentials cloud
02
Livraison d’infrastructure et gestion de l’état
C’est là que les produits cessent de se recouper. Les ingénieurs plateforme publient des Blueprints : un template, un Form et les actions qui créent et modifient une ressource. Les développeurs font leurs demandes sur ces Blueprints, Cycloid vérifie la demande, et l’exécution a lieu sur le Native Runner ou dans votre CI. L’état Terraform et OpenTofu est lu pour inventorier ce qui est géré et montrer la couverture IaC.
Port n’exécute pas d’infrastructure ; il ingère des données des outils qui le font. Grâce à son framework d’intégration Ocean ou à des connexions API directes, Port peut extraire des données d’état Terraform, des données de ressources Kubernetes, des métadonnées de ressources AWS/GCP/Azure, des résultats d’exécution CI/CD et des dizaines d’autres sources dans son catalogue logiciel. Les entrées du catalogue se mettent à jour en temps réel, et vous pouvez construire des dashboards et des scorecards sur ces données. Mais Port n’a pas de notion de workspace Terraform qu’il posséderait, ni de mécanisme pour déclencher un plan, ni de mécanisme pour bloquer un apply. Ces responsabilités incombent aux outils CI/CD ou IaC déjà en place.
Conclusion : Cycloid maîtrise le chemin de livraison et utilise cette maîtrise pour vérifier chaque demande avant son exécution. Port ingère des données des outils qui font ces choses et les rend interrogeables, mais il n’en possède aucune.
FONCTIONNALITÉ
PORT
Exécution IaC
Exécute Terraform et OpenTofu, Ansible et Helm sur le Native Runner, ou déclenche votre CI
N’exécute pas l’IaC ; remonte les données des outils IaC externes via des intégrations
État Terraform
Lit l’état Terraform et OpenTofu pour inventorier ce qui est géré et montrer la couverture IaC
Peut ingérer des données d’état via des intégrations, mais ne possède ni ne gère les états
Cycle de vie des environnements
Crée, met à jour et décommissionne les environnements via les actions des Blueprints
Cycle de vie des environnements géré entièrement dans les systèmes CI/CD et IaC externes
Topologie de l’infrastructure
Graphe des relations entre ressources et services par environnement
Le catalogue affiche les métadonnées et relations des ressources à partir des données ingérées
03
Libre-service et modèle d’interaction développeur
Les deux plateformes offrent du libre-service, mais le modèle sous-jacent diffère significativement.
Le libre-service de Cycloid passe par les Forms : des saisies qui présentent aux développeurs un ensemble restreint d’options, région, type d’instance, niveau d’environnement, etc., toutes délimitées par ce que l’équipe plateforme a autorisé. Un développeur qui remplit un Form n’écrit pas de Terraform et ne modifie pas de module ; il choisit parmi des valeurs approuvées qui alimentent l’action de création du Blueprint. La plateforme valide les saisies, exécute les contrôles d’autorisation, déclenche l’approbation éventuelle et exécute le changement. La gouvernance n’est pas quelque chose qu’un développeur peut contourner en choisissant une autre saisie.
Le libre-service de Port est conçu différemment : les ingénieurs plateforme définissent des actions libre-service liées à des blueprints, l’unité de modélisation centrale de Port. Une action peut déclencher un webhook, un workflow GitHub Actions, un pipeline Jenkins ou toute automatisation externe. Port gère la saisie du formulaire, l’approbation manuelle optionnelle et l’événement d’audit. Le travail réel s’effectue en dehors de Port, dans le système CI ou IaC que l’action pointe. Cela signifie que le libre-service de Port est aussi robuste que le système externe qu’il appelle. Si ce système manque de garde-fous propres, Port n’en ajoute pas.
Le couplage plus étroit de Cycloid vous donne plus de contrôle sur ce qui s’exécute. Le couplage plus lâche de Port vous offre plus de flexibilité pour vous brancher à un outillage existant sans le déplacer.
Conclusion : Cycloid réduit la charge de tickets en standardisant la façon dont l’infrastructure est demandée et ce qu’elle peut produire. Port réduit la charge cognitive en centralisant l’endroit où vivent les actions, tout en laissant l’exécution aux systèmes que l’équipe plateforme gère déjà.
FONCTIONNALITÉ
PORT
Mécanisme de libre-service
Forms aux saisies bornées alimentant les actions des Blueprints ; gouvernance intégrée au workflow
Formulaires d’action déclenchant des automatisations externes via webhooks, GitHub Actions, Jenkins, etc.
Garde-fous sur les entrées
Options d’entrée prédéfinies par l’équipe plateforme ; les combinaisons invalides sont bloquées avant l’exécution
Validation des entrées au niveau du formulaire ; l’application dépend de ce que l’automatisation externe implémente
Flux d’approbation
Étapes d’approbation intégrées avant l’exécution (Enterprise)
Bascules d’approbation manuelle configurables par action ; notification d’approbation par e-mail, webhook Slack ou API
Que se passe-t-il en cas d’échec de politique
La demande est refusée avant toute exécution
Dépend de ce que fait le système externe déclenché lorsqu’il reçoit la charge utile
Couplage d’exécution
Fortement couplé ; la plateforme maîtrise le chemin d’exécution
Faiblement couplé ; la plateforme délègue l’exécution aux outils externes
04
Contrôle d’accès, gouvernance et auditabilité
Les deux plateformes disposent d’un RBAC et de journaux d’audit, mais ils gouvernent des choses différentes.
Cycloid contrôle chaque action à travers quatre couches : ce que vous pouvez voir, votre rôle (Admin, Lead, Member ou Viewer), les conditions sur la demande, et l’approbation là où elle est nécessaire. Quand une demande est refusée, elle l’est au niveau de la plateforme, que le dépôt Git sous-jacent l’ait autorisée ou non et quelle que soit la souplesse de configuration du pipeline CI, et le refus est lui aussi journalisé.
Le RBAC de Port contrôle qui peut consulter, créer ou modifier des entités du catalogue et qui peut invoquer des actions libre-service. Les permissions peuvent être définies par rôle (admin, modérateur, membre), par appartenance à une équipe, ou par des règles dynamiques utilisant des expressions JQ sur les données du catalogue. Par exemple, vous pouvez écrire une politique qui n’autorise que l’ingénieur d’astreinte à déclencher une action de rollback sur un service donné. Port tient également un journal d’audit qui enregistre chaque modification du catalogue, invocation d’action et événement automatisé, incluant quel utilisateur ou compte de service l’a déclenché.
La distinction porte sur l’endroit où l’application est réellement effective. Le RBAC de Port empêche les utilisateurs non autorisés d’invoquer des actions via Port. Il n’empêche pas ces mêmes utilisateurs de déclencher le même pipeline directement depuis leur système CI, de pousser vers le dépôt Git ou d’exécuter Terraform depuis leur poste. L’application de Cycloid s’exécute dans le chemin de livraison lui-même, de sorte que le contourner nécessite de contourner la plateforme.
Conclusion : Cycloid applique la gouvernance avant que les changements n’atteignent la production. Port décrit la conformité via des scorecards et une propriété qui doit déjà être appliquée dans les systèmes avec lesquels Port s’intègre.
FONCTIONNALITÉ
PORT
Périmètre du RBAC
Rôles prédéfinis, délimités par équipe, Resource Group et environnement, qui contrôlent qui peut demander, approuver ou exécuter. Appliqués par la plateforme, pas seulement par le portail
Niveau catalogue et action ; les rôles admin, modérateur et membre contrôlent qui peut consulter ou modifier les entités et invoquer des actions. Les permissions dynamiques via des expressions JQ permettent un accès contextuel — par exemple en limitant les déploiements en production aux ingénieurs senior uniquement
Application des politiques
La validation des Forms et les conditions refusent les demandes non conformes avant l’exécution, quoi que permettent le dépôt Git ou le pipeline CI
Les automatisations Port utilisent des règles de condition basées sur JQ pour appliquer des politiques sur les exécutions d’actions : bloquer les déploiements présentant des vulnérabilités critiques détectées par des scanners tels que Trivy ou Wiz, approuver automatiquement les requêtes à faible risque et escalader les requêtes à risque élevé. Cette logique de politique s’exécute dans Port, mais agit sur les exécutions d’actions gérées par Port, pas directement sur l’exécution Terraform ou IaC
Workflows d’approbation
Étapes d’approbation natives par action de Blueprint et par environnement ; rien ne s’exécute tant que les approbateurs requis n’ont pas agi
Champ requiredApproval par action défini sur ANY (un seul approbateur suffit) ou ALL (tous les approbateurs désignés doivent agir). Lorsqu’une action est déclenchée, elle passe au statut WAITING_FOR_APPROVAL et envoie une notification par e-mail aux approbateurs. Les approbateurs agissent depuis l’interface Port ou via l’API. Les notifications Slack nécessitent une automatisation séparée
Journalisation des audits
Un seul enregistrement de la demande, de l’approbateur, des contrôles, des refus et du changement produit, lié à la ressource et à l’environnement
Port tient un journal d’audit de chaque modification du catalogue, invocation d’action, décision d’approbation et déclenchement d’automatisation, incluant l’utilisateur ou le compte de service à l’initiative de chaque événement. Les journaux d’exécution du système CI/CD ou IaC en aval restent en dehors de Port
Posture de conformité
Les changements d’infrastructure non conformes sont bloqués avant leur exécution, parce que Cycloid possède le chemin d’exécution. Un contrôle en échec arrête l’exécution, quoi qu’un système en amont ait pu autoriser
La conformité est suivie via des scorecards mesurant des critères tels que la protection des branches, l’hygiène IAM, la gestion des dépendances et les standards de chiffrement. Les politiques s’appliquent aux exécutions d’actions gérées par Port. L’application de la conformité sur l’exécution IaC brute nécessite que le système CI/CD en aval la prenne en charge
05
Modèle de données et flexibilité du catalogue
Les blueprints de Port sont des types d’entités : vous pouvez modéliser n’importe quoi, un microservice, un environnement, un cluster, une équipe, avec des propriétés, des relations et des propriétés miroir. Cette flexibilité convient aux équipes qui cataloguent de nombreux types d’actifs à travers l’ingénierie, la sécurité et le SRE.
Les Blueprints de Cycloid font plus que décrire. Chacun est un template, un Form et les actions qui créent et modifient une ressource, et ce qu’il crée atterrit dans le catalogue logiciel avec son responsable, ses relations et son niveau de scorecard. Les Blueprints suivis et l’inventaire des actifs ramènent ce qui n’a pas été créé via Cycloid.
Les équipes qui ont surtout besoin d’un modèle de métadonnées flexible retrouveront leurs repères dans l’approche de Port. Celles qui veulent le catalogue et le changement gouverné sur le même référentiel le trouveront dans Cycloid.
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 !
Comment choisir
Cycloid ou Port : comment choisir la bonne plateforme pour votre équipe
Les équipes plateforme choisissent le bon outil pour le mauvais problème, le déploient, le présentent lors d’une réunion d’équipe, puis se demandent six mois plus tard pourquoi les incidents d’origine se produisent toujours.
Si vos incidents récurrents remontent au chemin d’exécution, plans non revus, environnements qui diffèrent d’une étape à l’autre sans que personne ne sache l’expliquer, ou approbations données dans un fil Slack, il vous faut une plateforme qui se place dans ce chemin.
Si votre friction tient à savoir ce qui existe et qui en est responsable, les deux produits le cataloguent. La différence est dans ce qui se passe ensuite : dans Port, vous construisez une action qui appelle un autre système ; dans Cycloid, le Blueprint qui a listé la ressource est celui qui la modifie.
