Internal Developer Platform

L'expérience d'un PaaS — dépôt, pipeline, déploiement, logs — sur votre propre Kubernetes. Vos données ne quittent jamais votre infrastructure.

Découvrir Kybers
01ce que c'est

Une Internal Developer Platform (IDP) : le chemin balisé qui va du dépôt à la production, sans que chaque équipe réinvente ses YAML. La différence avec les autres, c'est où tourne le résultat.

Un portail type Backstage

catalogue
Référence vos services et centralise la documentation, mais ne déploie rien lui-même. Il faut construire les plugins et brancher la chaîne derrière.
ne déploie pas

Un PaaS type Vercel ou Heroku

déploiement
L'expérience développeur est excellente, mais vos applications tournent sur l'infrastructure du fournisseur — et vos données avec elles.
vos données sortent

Kybers : les deux, chez vous

idp souveraine
L'expérience d'un PaaS — dépôt, pipeline, déploiement, logs — sur votre propre cluster Kubernetes. Le plan de contrôle orchestre ; l'exécution ne quitte jamais votre infrastructure.
rien ne sort

Vos données restent entre vos mains.

souveraineté

Kybers n'est pas un intermédiaire par lequel transitent vos applications. Le plan de contrôle enregistre des intentions — « déployer cette image », « scaler à 3 replicas ». C'est l'agent, chez vous, qui les exécute.

RGPD, hébergement de données de santé, secteur défense : la question « où sont mes données » a une seule réponse — chez vous, elles n'en sont jamais parties.

Ne quitte jamais votre infrastructure

périmètre
  • Le code de vos applications
  • Le contenu de vos bases de données
  • Le trafic de vos utilisateurs
  • Vos volumes et vos sauvegardes
  • Votre kubeconfig
  • Vos secrets en clair
02du dépôt au running

Kybers crée le dépôt GitHub ou GitLab, y pousse le squelette et le workflow, dépose les secrets côté CI, puis déclenche le premier déploiement. Vos conventions cessent d'être un document que personne ne lit.

Créer une application

Cinq étapes guidées, puis le déploiement part tout seul. Abandonner en cours de route ne laisse ni dépôt vide ni namespace orphelin.

  1. Type d'applicationgolden path · Service Node
  2. Identitébilling-api · port 8080
  3. Dépôt Gitacme/billing-api · créé
  4. Configuration7 variables · 3 secrets
  5. Fichiers poussésDockerfile · deploy.yml · .env.example
  6. runningrév. 1 · 2/2 replicas prêts

Service Node · 4 fichiers

  • .github/workflows
dockerDockerfile

Image multi-étapes, utilisateur non privilégié.

1FROM node:22-alpine AS build
2WORKDIR /app
3COPY package*.json ./
4RUN npm ci --omit=dev
5COPY . .
6
7FROM node:22-alpine
8USER node
9COPY --from=build /app /app
10EXPOSE 8080
11CMD ["node", "server.js"]

Types d'application

Node, Python, Go — un dépôt complet, prêt à déployer.

Fichiers libres

Un Dockerfile ou un workflow à greffer sur l'existant.

Golden Paths

Le chemin recommandé, installé en un clic.

03l'application

Le workflow déposé dans le dépôt appelle l'API Kybers à chaque tag. Rien à câbler à la main : le jeton, l'identifiant de l'application et l'URL sont déjà écrits.

acme/billing-api — .github/workflows/deploy.yml
# .github/workflows/deploy.ymlon: push: tags: ['v*']jobs: deploy: runs-on: ubuntu-latest steps: - run: | curl -X POST \ $KYBERS_URL/api/v1/apps/$APP/deploy \ -H "Authorization: Bearer $KYBERS_TOKEN"

Le jeton est déjà en place

Kybers dépose KYBERS_TOKEN dans les secrets du dépôt à la création. Aucun identifiant humain ne circule dans un runner, et le jeton se révoque seul.

N'importe quel CI convient

GitHub Actions, GitLab CI, Jenkins — c'est un appel HTTP authentifié. Le workflow fourni est un point de départ, pas une dépendance.

Kybers ne construit pas vos images

La plateforme déploie une image déjà publiée sur votre registry. C'est un périmètre assumé : votre chaîne de build reste la vôtre.

04l'agent

L'agent installé chez vous ouvre la connexion vers Kybers et va y prendre ses ordres. Le SaaS n'a aucun moyen de joindre votre cluster : il attend qu'on vienne le solliciter.

Kybers — votre SaaS

API RESTgRPC :9090DispatcherPostgreSQL
connexion ouverte par l'agent · TLS

Votre cluster Kubernetes

Agent Kybers
NamespaceConfigMapSecretDeploymentServiceIngress TLS
0 port entrant · 0 IP publique · 0 kubeconfig partagé

Aucun port entrant à ouvrir

Pas de règle de pare-feu entrante, pas d'adresse IP publique, pas de kubeconfig confié à un tiers. C'est ce qui rend l'installation acceptable dans un environnement verrouillé.

La coupure n'est pas un incident

Si le lien tombe, l'agent revient de lui-même et reprend les déploiements restés en attente. Rien ne se perd pendant l'interruption.

Plusieurs Control Planes, aucun doublon

Les déploiements en attente sont réclamés avec FOR UPDATE SKIP LOCKED : plusieurs instances peuvent tourner ensemble sans traiter deux fois le même ordre.

ClaimPendingDeployments

Ce qui se passe ensuite

pending

L'API répond en 202 et crée une révision. Sans agent connecté, la demande attend ici — rien n'est perdu.

dispatched

L'ordre est déposé sur le canal ouvert par l'agent. Un échec d'envoi le remet en file plutôt que de l'abandonner.

provisioning

L'agent applique les ressources dans l'ordre, de façon idempotente. Rejouer le même ordre ne crée jamais de doublon.

● running

Le rollout est confirmé pod par pod. Une image qui ne démarre pas bascule en failed, même si l'ancienne version sert encore.

05le produit

Applications, modèles, infrastructure et gouvernance. Les valeurs remontées par l'agent en direct : nœuds, consommation, activité — sans quitter le dashboard.

Infrastructure
0/2Clusters connectés
0Nœuds
0%CPU utilisé
0%Mémoire utilisée

Plan de contrôle

Les briques dont dépend le pilotage de vos clusters.

Base de données

connectée

Agents connectés

2 agent(s)

URL automatiques

acme.io (TLS)

Authentification API

active

prod-eu-west

connecté

Plateforme

K3s

Version

v1.35.5+k3s1

Nœuds

3/3 prêts

Capacité

12 vCPU · 48 Gi

Agent

0.3.0

Stockage

local-path

Ingress

traefik

Applications

14 pod(s) · 6 env.

relevé à l'instant

06observabilité

Les logs remontent en continu, y compris pour les pods créés après coup. Les causes d'échec sont nommées explicitement plutôt que laissées à l'interprétation.

logs — billing-api / prod · suivi en continu

ImagePullBackOff

Image introuvable ou identifiants de registry invalides.

CrashLoopBackOff

Le conteneur démarre puis meurt en boucle.

OOMKilled

Limite mémoire dépassée, le pod a été tué.

Unschedulable

Aucun nœud ne satisfait les requests demandées.

Détection fiable du rollout

rollout
Un déploiement dont la nouvelle image ne démarre pas est marqué failed, même si l'ancienne version continue de répondre. Vous ne croyez pas à tort que la mise en production a réussi.
07gouvernance

Organisations cloisonnées, rôles par membre, jetons révocables et journal d'audit. La souveraineté ne vaut que si l'on peut aussi retracer ce qui s'est passé à l'intérieur.

organisations

Un périmètre par organisation

Chaque organisation a ses applications, ses modèles et ses clusters. Le Control Plane refuse toute requête sortant de l'organisation active — la séparation est appliquée côté serveur, pas seulement masquée dans l'interface.

Cloisonnementcôté API
rôles

Qui peut déployer, qui peut lire

Les droits suivent le membre, pas l'application. Ajouter quelqu'un à une équipe lui ouvre exactement le périmètre prévu, sans configuration par application.

Portéepar membre
jetons d'API

Des jetons dédiés aux pipelines

Vos CI déploient avec leurs propres jetons, révocables un par un. Aucun identifiant humain ne circule dans un runner, et retirer un jeton n'interrompt rien d'autre.

Révocationunitaire
audit

Qui a déployé quoi, et quand

Chaque action sensible est journalisée avec son auteur, son horodatage et son environnement. Le journal est consultable dans l'interface, sans accès à la base.

Traçabilitéintégrale
chiffrement

Les secrets chiffrés au repos, jamais relus

Secrets applicatifs et mots de passe de registry sont chiffrés en AES-256-GCM. La lecture ne renvoie que les noms des clés : même le dashboard ne peut pas réafficher une valeur enregistrée.

AlgorithmeAES-256-GCM

Isolation par namespace

Un namespace par couple application/environnement. Les variables de staging ne peuvent pas fuiter en prod.

Sondes de santé

Liveness, readiness et startup — en HTTP, TCP ou exec, avec requests et limits par application.

Autoscaling horizontal

HPA sur CPU, retiré automatiquement si vous le désactivez. Quotas et NetworkPolicy par environnement.

Durcissement opt-in

runAsNonRoot, runAsUser, readOnlyRootFilesystem — activés quand vous en avez besoin.