Votre IA a écrit une app qui fonctionne. Voici comment la mettre en ligne.

Le problème de l'app du vendredi soir

Un manager que nous connaissons a passé un vendredi soir avec un assistant IA et, à minuit, disposait d'un outil interne réellement utile : un suivi de tâches façonné exactement comme son équipe travaille, parce qu'il connaît le métier mieux que n'importe quel éditeur. L'app tournait à merveille — sur son laptop.

Les options du lundi étaient toutes mauvaises. Demander un serveur à la DSI et attendre des semaines qu'un ticket avance. Pousser les données de l'entreprise sur une plateforme amateur à l'étranger. Ou louer un VPS nu et devenir du jour au lendemain responsable du TLS, des sauvegardes, des correctifs et du pare-feu. Le code était bon. Ce qui manquait, c'était une route.

Pourquoi les chemins de déploiement habituels ne conviennent pas

Chaque chemin classique suppose quelque chose que ce créateur n'a pas. Les deploys basés sur git supposent un dépôt et un workflow de branches. Les deploys basés sur des images supposent un registry de conteneurs et la maîtrise de Docker pour l'alimenter. Les deux supposent que la personne qui publie est, au moins à mi-temps, un ingénieur de déploiement.

Ce que le créateur assisté par IA possède réellement est plus simple : un dossier avec du code qui fonctionne. C'est donc exactement de là que la route doit partir — du dossier. Voyez Déployer depuis Git si vous avez bien un dépôt ; les deux routes aboutissent à la même plateforme.

Le dossier suffit

Installez un petit CLI, lancez une commande dans le répertoire du projet, et cdnctl déduit le reste : le langage et le framework, le port, la présence d'un Dockerfile (il peut en générer un), et même quels agents de code IA sont configurés dans le projet — parce que l'agent qui a écrit l'app est en général celui qui continuera à la publier.

$ cdnctl init
Proje    : gorev-takip (node/express, port 3000)
Agent    : claude-code (claude on PATH), cursor
Paket    : ✓ Large (max 5 app)
Karne    : 2 HATA, 2 uyarı — ayrıntı: cdnctl check
Yazıldı  : cdnctl.yaml, AGENTS.md

→ Önce `cdnctl check` hatalarını düzeltin (deploy sonrası site açılmaz).

Un bulletin de notes avant que votre code ne quitte la machine

Les apps générées par IA échouent en production pour une poignée de raisons très répétitives, et chacune est visible dans le source avant le deploy. cdnctl check s'exécute entièrement sur votre machine — aucun code n'est envoyé — et il refuse de laisser partir une app connue pour être cassée. Les quatre constats ci-dessous ne sont pas hypothétiques : ce sont exactement les défauts avec lesquels notre propre app de test avait été écrite, attrapés au premier passage.

$ cdnctl check
[ERROR] bind-localhost (server.js:61)
        The app binds to 127.0.0.1 — unreachable inside a container.
        → Bind to 0.0.0.0 (just drop the host argument).
[ERROR] secret-in-code (server.js:10)
        A hard-coded secret (API key/token/password).
        → Move it to --secret KEY=VALUE; read it via process.env.
[WARNING] sqlite-single-pod
        SQLite loses data on restart / multiple replicas.
        → Mount a persistent disk or switch to a managed database.
[WARNING] no-healthcheck
        No /health route — the platform can’t tell your app is alive.

Une commande vers une URL en ligne

Une fois les corrections faites, le déploiement tient en une seule commande. Sous le capot, votre source est archivé, envoyé via TLS, transformé en image de conteneur dans un bac à sable isolé, poussé dans l'espace de registry privé de votre compte et démarré derrière un vrai sous-domaine HTTPS — mais rien de tout cela ne réclame votre attention. La première exécution prend environ une minute ; chaque release suivante est la même commande.

$ cdnctl deploy
→ archiving source (gorev-takip)
→ uploading (0.1 MB)
→ starting build (Kaniko, isolated sandbox)
   build: running
   build: success        (41 s)
→ creating the app
→ assigning a subdomain
→ first deploy
→ waiting for the app to come up

✓ LIVE: https://ca…….cdn.com.tr

Sécurité et durabilité sont des défauts, pas des corvées

Les parties qui rendaient la route du VPS effrayante sont ici le travail de la plateforme. Le TLS est émis et renouvelé pour vous. Les builds tournent en bac à sable, et les images vivent dans un espace de registry qui appartient à votre compte seul. Un healthcheck permet à la plateforme de redémarrer votre app dès qu'elle cesse de répondre. Et quand le bulletin repère une base de données fichier, il vous oriente vers les disques persistants et le MySQL/PostgreSQL managé — pour qu'un redémarrage de pod ne dévore jamais vos données.

Votre agent IA peut dérouler tout ce flux lui-même

cdnctl init écrit une section deploy dans AGENTS.md (et CLAUDE.md quand il existe), si bien que l'agent qui a construit l'app connaît les commandes exactes à son prochain tour. Les agents disposent d'une sortie lisible par machine avec --json, d'un serveur MCP via cdnctl mcp, et — c'est important — de leur propre token deploy-only : il peut envoyer, builder et publier, et il ne peut PAS toucher au DNS, à la facturation ni au reste de votre compte. Votre mot de passe du panel ne vous quitte jamais. Les détails vivent dans les pages d'aide cdnctl. Pour le modèle de sécurité complet — limites du token, configuration MCP et frontières testées — voyez donner à votre agent un accès deploy en toute sécurité.

Quelle route est la vôtre ?

Trois routes, une plateforme. Si vous gardez votre code dans un dépôt et voulez du push-to-deploy, prenez Déployer depuis Git. Si vous construisez déjà des images et lancez un fichier compose, voyez l'hébergement Docker. Si ce que vous avez est un dossier qui fonctionne — la situation du vendredi soir — cette route a été construite pour vous : installez cdnctl, lancez init, lancez deploy, envoyez l'URL à votre équipe.