Mettre en ligne une appli ASP.NET Core depuis votre agent IA, par MCP
Votre API ou votre appli ASP.NET Core est prête. Branché à while par MCP, votre agent IA la met en ligne en France, avec un Dockerfile .NET tout prêt et sa base PostgreSQL sauvegardée chaque jour.
Par Aloïs Oddon, cofondateur de Nextmap. Faits relevés le 2 novembre 2026.
Prérequis
- Une appli ASP.NET Core, avec son fichier .csproj à la racine du dépôt.
- Un agent IA qui travaille dans un terminal : Claude Code, Codex, Cursor ou Gemini CLI.
Étape 1 : Donnez ces instructions à votre agent
Ouvrez votre agent dans le dossier de votre appli, et collez-lui ces instructions :
Connecte-toi à while avec mon compte (while.sh/agents), puis mets mon appli en ligne.Sans compte, votre agent met votre appli en ligne à l’essai, en une demande. Pour la garder, ouvrez le lien qu’il vous donne et créez votre compte.
Avec votre compte, votre agent ajoute lui-même le serveur MCP de while. S’il vous le demande, relancez-le. Au premier appel à while, une page s’ouvre dans votre navigateur. Dans Claude Code, si elle ne s’ouvre pas, tapez /mcp, choisissez while, puis Authenticate. Sur cette page, choisissez votre appli, ou « Une nouvelle appli », puis cliquez sur Autoriser.
Étape 2 : Ouvrez votre appli
Votre agent vous donne l’adresse de votre appli, par exemple https://mon-appli.while.cloud, en HTTPS.
Ce que fait votre agent
Il écrit while.yaml à la racine de votre appli :
apiVersion: while/v1
project: mon-appli
services:
- name: web
port: 8080
health:
path: /health
databases:
- name: mainASP.NET Core est reconnu à son .csproj, et votre agent reçoit un Dockerfile prêt à construire : dotnet publish, la version de .NET de votre projet, et le port de while passé à Kestrel. Votre agent l’ajoute à votre appli, avec une vérification de santé en deux lignes1 :
builder.Services.AddHealthChecks();
var app = builder.Build();
app.MapHealthChecks("/health");Lire votre base en SQL
Vous, à votre agent : Combien d’inscrits aujourd’hui ?
Votre agent lit votre base en SQL par le serveur MCP de while, avec vos droits sur les données, sans pouvoir y écrire.
Lancer un travail chaque nuit
Vous, à votre agent : Lance l’import des données chaque nuit à 3 h.
Votre agent déclare une tâche planifiée, qui part à l’heure dite avec le même code et les mêmes variables. Si elle échoue, votre agent est prévenu.
Réserver votre appli à vos collègues
Vous, à votre agent : Réserve l’appli aux personnes de l’entreprise.
Votre agent ajoute deux lignes au service :
access: internal
email_domains: [acme.fr]Une fois votre Google Workspace ou Microsoft 365 relié à while, avec l’offre Pro, vos collègues l’ouvrent avec leur compte habituel, et votre code reçoit leur nom et leur adresse électronique, sans page de connexion à écrire.
Passer sur votre propre domaine
Vous, à votre agent : Mets l’appli sur app.acme.fr.
Votre agent déclare le domaine, vous ajoutez les enregistrements DNS qu’il vous donne, et le certificat HTTPS suit.
Corriger une faille dans vos dépendances
Vous, à votre agent : Corrige les failles de nos dépendances.
Les dépendances de votre appli sont comparées aux failles connues à chaque mise en ligne, puis chaque jour. Votre agent est prévenu d’une faille grave, et met à jour le paquet en cause.
Revenir à la version d’avant
Vous, à votre agent : Reviens à la version d’avant.
Dans les 30 minutes qui suivent une mise en ligne, la version d’avant revient en une seconde. Ensuite, en quelques secondes. Une fois la version d’avant revenue, votre agent lit ce qui a cassé dans les journaux de while, corrige et remet en ligne.
Dans la doc : Bases PostgreSQL, Tâches planifiées, Accès interne, Domaine personnalisé, Versions et retour arrière et Failles des dépendances.
Prochaines étapes
Sources
- Microsoft, les vérifications de santé d’ASP.NET Core, consulté le 2 novembre 2026