Pourquoi sh0 intègre l'IA -- et aucune autre plateforme d'hébergement ne le fait

Ouvrez le tableau de bord de Vercel. Ouvrez celui de Heroku. Ouvrez n'importe quelle plateforme d'hébergement que vous utilisez. Vous trouverez les mêmes choses : une liste d'applications, des logs de déploiement, des variables d'environnement, des domaines et une page de paramètres. Peut-être un CLI. Peut-être une API correcte.

Aucune d'entre elles n'a un assistant IA qui comprend votre infrastructure.

sh0 en a un. Et ce n'est pas un chatbot collé par-dessus -- c'est une fonctionnalité de premier plan avec sa propre facturation, son propre moteur d'exécution d'outils, son propre modèle de sécurité, et son propre serveur de protocole. Nous avons construit toute la pile en 48 heures, sur 14 sessions d'ingénierie, et c'est la deuxième icône dans la barre de navigation.

Voici pourquoi et comment.

Le problème que personne ne résout

Les plateformes d'hébergement vous donnent des outils puissants et puis vous laissent seul avec. Quand votre déploiement échoue à 2 heures du matin, vous :

1. Ouvrez le tableau de bord
2. Naviguez vers l'application
3. Vérifiez les logs de déploiement
4. Lisez la sortie du build
5. Vérifiez peut-être les logs du conteneur
6. Vérifiez peut-être l'utilisation des ressources
7. Formulez une hypothèse
8. Tentez une correction
9. Attendez la reconstruction
10. Répétez

Chaque étape exige que vous sachiez où chercher, quoi chercher et comment interpréter ce que vous voyez. C'est acceptable pour des ingénieurs DevOps expérimentés. C'est terrible pour le fondateur solo qui déploie sa première application Node.js, ou l'agence qui gère 40 sites clients, ou la startup qui ne peut pas se permettre une équipe ops.

Et si l'étape 1 était : « Hey sh0, mon application est en panne -- que s'est-il passé ? »

Et si l'étape 2 était : sh0 lit les logs, vérifie l'utilisation des ressources, identifie l'erreur, et soit la corrige, soit vous dit exactement quoi faire ?

C'est ce que nous avons construit.

Ce que nous avons réellement construit

Couche 1 : le chat IA

Le tableau de bord a un assistant IA complet, accessible depuis la deuxième position dans la barre de navigation latérale. Il supporte trois modèles Claude (Haiku pour la vitesse, Sonnet pour l'équilibre, Opus pour les problèmes complexes), diffuse les réponses en temps réel et persiste l'historique des conversations.

Mais une interface de chat n'est qu'une zone de texte. La vraie valeur est ce qui se passe derrière.

Couche 2 : l'appel d'outils -- l'IA qui peut agir

Quand vous demandez « Qu'est-ce qui ne va pas avec mon application ? », l'assistant ne devine pas. Il appelle des outils :

• list_apps -- lit votre inventaire d'applications avec statut, stack et replicas
• get_app_details -- récupère la configuration complète, les domaines et l'environnement
• get_deployment_logs -- récupère les déploiements récents et la sortie du build
• get_server_status -- vérifie le CPU, la mémoire, le disque, l'état de Docker et l'uptime
• list_databases -- inventorie les instances de base de données
• list_backups -- vérifie les planifications de sauvegarde et l'état des sauvegardes récentes

Ce ne sont pas des hypothèses. Chaque outil correspond à un vrai endpoint API de sh0. Quand l'IA appelle get_deployment_logs, elle reçoit la vraie sortie du build de votre dernier déploiement. Quand elle appelle get_server_status, elle lit les vraies métriques CPU et mémoire de votre serveur.

L'IA peut aussi agir :

• restart_app -- redémarrer un conteneur
• deploy_app -- déclencher un nouveau déploiement
• scale_app -- ajuster le nombre de replicas
• trigger_backup -- lancer une sauvegarde immédiatement
• trigger_cron_job -- exécuter une tâche planifiée

Et elle peut générer des fichiers :

• generate_config_file -- produire un sh0.yaml, docker-compose.yml, ou Dockerfile basé sur votre conversation

Après chaque réponse, elle suggère des actions de suivi sous forme de pastilles cliquables, pour que vous n'ayez jamais à réfléchir à quoi demander ensuite.

Couche 3 : le serveur MCP -- pour les clients IA au-delà du tableau de bord

Le chat du tableau de bord est une interface. Mais que faire si vous voulez gérer votre serveur sh0 depuis Claude Desktop ? Depuis Cursor ? Depuis n'importe quel client IA compatible MCP ?

sh0-core inclut un serveur MCP (Model Context Protocol) complet, implémentant le transport Streamable HTTP selon la spécification du 26 mars 2025. Il expose 20 outils -- 12 en lecture seule, 7 opérations d'écriture, et 1 méta-outil de confirmation -- tous auto-générés depuis la même spécification OpenAPI qui alimente l'API REST.

Cela signifie :

• Ouvrez Claude Desktop, pointez-le vers https://votre-serveur.com/api/v1/mcp
• Claude découvre automatiquement tous les outils disponibles
• Vous pouvez gérer votre infrastructure depuis n'importe quel client MCP, pas seulement le tableau de bord de sh0

Aucune autre plateforme d'hébergement n'a cela. Ni Vercel. Ni Railway. Ni Render. Ni Fly.io. Personne.

Couche 4 : le modèle de sécurité -- parce que IA + production = danger

Donner à une IA la capacité de redémarrer des applications et supprimer des bases de données est puissant. C'est aussi terrifiant. Notre modèle de sécurité a trois couches :

Clés API à portée limitée. Chaque connexion MCP s'authentifie avec une clé qui porte une portée : read, standard ou admin. Les clés en lecture ne peuvent appeler que les outils de lecture. Les clés standard peuvent lire et écrire. Les clés admin peuvent tout faire -- mais les opérations destructives nécessitent une étape supplémentaire.

Classification des risques. Chaque outil est classifié comme read, write ou destructive. Le niveau de risque est appliqué au moment de l'exécution. Une clé à portée standard qui appelle delete_app reçoit un 403 immédiatement, avant l'exécution de tout code.

Jetons de confirmation. Les opérations destructives (supprimer une application, supprimer une base de données) ne s'exécutent jamais directement. Au lieu de cela, elles renvoient un jeton de confirmation -- un jeton à usage unique, lié à l'utilisateur, avec un TTL de 5 minutes, que le client doit soumettre explicitement via confirm_action. Cela empêche une IA de cascader accidentellement des opérations destructives. Même avec une clé admin, vous ne pouvez rien supprimer sans une étape de confirmation délibérée.

Chaque opération d'écriture est journalisée avec un préfixe d'action mcp:*, pour que vous puissiez tracer exactement ce que l'IA a fait et quand.

L'architecture : double exécution

La décision architecturale la plus intéressante est le modèle de double exécution :

Voie A : exécution côté client (tableau de bord). Quand vous utilisez le chat dans le tableau de bord, les appels d'outils sont exécutés dans votre navigateur. La passerelle IA définit les outils, Claude décide lesquels appeler, mais les requêtes API réelles vont de votre navigateur vers votre serveur sh0. La passerelle ne voit jamais les données de votre serveur -- elle ne voit que les noms d'outils et les résultats qui sont renvoyés à Claude.

Voie B : exécution côté serveur (MCP). Quand vous utilisez Claude Desktop ou un autre client MCP, les appels d'outils s'exécutent directement sur votre serveur sh0. Claude se connecte à l'endpoint MCP, découvre les outils et les appelle côté serveur. Aucun navigateur impliqué.

Voie C : hybride (MCP Connector de la passerelle). Quand la passerelle IA détecte que votre instance sh0 a MCP activé, elle utilise le MCP Connector d'Anthropic pour laisser Claude appeler les outils de votre serveur directement -- tout en gérant les outils exclusifs à la passerelle (comme suggest_actions et generate_config_file) localement. Si le MCP échoue (problème réseau, instance hors ligne), elle bascule vers la voie du tableau de bord de manière transparente.

Cette architecture signifie que les fonctionnalités IA fonctionnent dans trois contextes : 1. Dans le tableau de bord (navigateur) 2. Dans n'importe quel client MCP (Claude Desktop, Cursor, etc.) 3. Via l'API (accès programmatique)

Les trois utilisent les mêmes outils, le même modèle de sécurité et la même journalisation d'audit.

Le modèle de facturation : portefeuille prépayé

Les fonctionnalités IA coûtent de l'argent à exécuter. Nous avons choisi un modèle de portefeuille prépayé :

• Achetez des packs de crédits (5 $, 20 $, 50 $, 100 $) avec des bonus de volume
• 20 % de marge au-dessus des tarifs d'Anthropic
• Trois modèles avec des niveaux de prix différents (Haiku : rapide et économique, Sonnet : équilibré, Opus : puissant)
• Comptabilité au niveau du token -- vous voyez exactement ce que chaque conversation coûte
• Les utilisateurs du plan Business peuvent apporter leur propre clé Anthropic ou OpenRouter (BYOK), chiffrée au repos avec AES-256-GCM

Le solde du portefeuille est visible dans l'en-tête supérieur sur chaque page, avec un lien direct pour acheter plus de crédits. Nous voulons que l'utilisation de l'IA soit naturelle, pas rationnée.

Pourquoi maintenant, pourquoi nous

Trois raisons pour lesquelles nous avons pu construire cela et les plateformes établies ne l'ont pas fait :

1. Avantage architectural. sh0 est un binaire Rust unique avec un tableau de bord Svelte intégré. Ajouter un serveur MCP revient à ajouter un handler de route à une application Axum -- pas à coordonner entre 15 microservices, 3 équipes et un planning de 6 mois. Nous sommes passés de « ajoutons l'IA » à « 20 outils en production » en 48 heures.

2. Nous utilisons notre propre produit. sh0 est déployé sur sh0. Quand nous ajoutons des fonctionnalités IA, nous les utilisons immédiatement pour gérer notre propre infrastructure. Les définitions d'outils ne sont pas hypothétiques -- elles correspondent à des opérations réelles que nous effectuons quotidiennement. « Redémarrer l'application » n'est pas une fonctionnalité de démo. C'est ainsi que nous récupérons d'un déploiement échoué.

3. L'IA n'est pas un ajout pour nous. C'est un différenciateur. Les plateformes établies optimisent pour les ventes entreprise, la compatibilité Kubernetes et le edge computing. Nous optimisons pour le fondateur solo, la petite équipe, la startup africaine qui ne peut pas se permettre un DevOps. Pour ces utilisateurs, une IA capable de diagnostiquer et corriger des problèmes de déploiement n'est pas un luxe -- c'est la différence entre livrer et abandonner.

Ce que cela signifie pour les utilisateurs

Si vous déployez sur sh0, vous obtenez :

• Gestion d'infrastructure en langage naturel. Posez des questions, obtenez des réponses avec de vraies données.
• Diagnostics proactifs. L'IA lit vos logs, pas seulement votre description du problème.
• Automatisation sécurisée. Redémarrez des applications, déclenchez des sauvegardes, mettez à l'échelle des services -- avec des portes de confirmation sur tout ce qui est destructif.
• Accès multi-clients. Utilisez le tableau de bord, Claude Desktop, Cursor ou n'importe quel client MCP.
• Tarification transparente. Voyez vos coûts par conversation, par modèle, par token.

Et parce que les fonctionnalités IA sont en deuxième position dans la navigation -- pas enfouies dans une page de paramètres ni cachées derrière un feature flag -- elles font partie du workflow quotidien, pas une réflexion après coup.

La chronologie de 48 heures

Pour ceux que l'ingénierie intéresse :

14 sessions. ~50 nouveaux fichiers. ~10 000 lignes de code. 20 outils MCP. Plus de 488 tests réussis. Prêt pour la production.

Ce qui arrive ensuite

Ce que nous avons livré en 48 heures est la fondation. Les prochaines sessions pousseront l'assistant IA bien au-delà de ce que n'importe quelle plateforme d'hébergement -- ou même la plupart des produits IA autonomes -- peut faire. Voici la feuille de route :

Génération de fichiers

L'IA générera de vrais fichiers, pas seulement du texte. Demandez-lui de créer un docker-compose.yml, une configuration Nginx, une demande de certificat SSL, un script de migration -- et elle produira un fichier téléchargeable avec aperçu en direct, coloration syntaxique et éditeur intégré. Nous portons un moteur de génération de fichiers éprouvé qui supporte XLSX, PDF, PPTX, DOCX, HTML et Markdown, tous générés côté serveur à partir de la sortie structurée du LLM.

Le canevas de fichiers vous permettra d'éditer les fichiers générés dans une vue en panneau divisé : chat à gauche, éditeur riche à droite. Éditez un Dockerfile généré, sauvegardez-le et déployez-le -- sans quitter la conversation.

Recherche web et navigation d'URL

L'assistant pourra chercher sur Internet et lire des URL. Quand vous demandez « Comment configurer Redis pour mon application Next.js ? », il cherchera la documentation la plus récente, lira les pages pertinentes et vous donnera une réponse fondée sur des sources réelles et actuelles -- avec des citations.

Cela transforme l'assistant de sh0 d'un chatbot aux connaissances limitées en un agent capable de recherche qui peut récupérer n'importe quelle information dont il a besoin pour vous aider.

Bac à sable d'exécution de code

Un environnement bash sandboxé où l'IA peut exécuter des commandes de manière isolée. Besoin de tester un script de build ? Déboguer un problème de dépendance ? Valider une configuration ? L'IA exécutera les commandes dans un bac à sable basé sur Docker, vous montrera stdout/stderr, et itérera sur la solution.

Ce n'est pas hypothétique. Nous avons une implémentation fonctionnelle d'un autre produit ZeroSuite (Deblo Pro) qui exécute des commandes plafonnées à 30 secondes avec capture complète de la sortie. Le portage vers le backend Rust de sh0 signifie que chaque exécution s'effectue dans un conteneur isolé via l'API Docker -- la même API que sh0 utilise déjà pour les déploiements.

Pipeline RAG -- vos docs, votre contexte

Les utilisateurs pourront télécharger de la documentation, des fichiers de configuration, des runbooks et des diagrammes d'architecture. L'IA les indexera en utilisant un chunking sémantique, des embeddings BGE-M3 et pgvector -- puis récupérera le contexte pertinent en répondant aux questions.

Demandez « Quel est notre processus de déploiement ? » et l'IA puisera dans votre runbook téléchargé. Demandez « Pourquoi avons-nous choisi PostgreSQL plutôt que MySQL ? » et elle trouvera l'enregistrement de décision architecturale que vous avez téléchargé le mois dernier. Votre savoir infrastructure, toujours disponible, toujours cherchable.

Génération en arrière-plan

Les tâches IA de longue durée (génération de fichiers complexes, recherche multi-outils, analyse de gros documents) s'exécuteront en tâches de fond. Si votre navigateur se déconnecte, la tâche continue. Quand vous revenez, les résultats vous attendent. Cela utilise une architecture à file de messages avec des tâches tokio et des canaux mpsc -- de l'asynchrone de qualité production qui ne perd jamais de travail.

Agents spécialistes

Au lieu d'un assistant générique, vous pourrez basculer entre des personas spécialistes : un expert DevOps, un auditeur de sécurité, un administrateur de base de données, un spécialiste Dockerfile, un consultant CI/CD. Chaque agent a un prompt système sur mesure qui concentre ses connaissances et son comportement sur son domaine.

Besoin d'une revue de sécurité ? Basculez vers l'agent auditeur de sécurité. Besoin d'aide pour optimiser vos requêtes PostgreSQL ? Basculez vers l'agent base de données. Chaque agent sait ce qu'il sait et reste dans son domaine.

Outils d'e-mail et de notification

L'IA pourra envoyer des e-mails et des notifications en votre nom : rapports de déploiement, résumés d'incidents, mises à jour de statut. Elle rédigera l'e-mail dans une carte interactive, vous laissera l'éditer, et l'enverra quand vous approuverez. Avec rate limiting, journalisation d'audit, et toujours sous votre contrôle.

Diagnostics interactifs

Des quiz et évaluations qui vous aident à comprendre votre infrastructure. L'IA testera vos connaissances de votre propre installation : « Savez-vous sur quel port tourne votre application ? Que se passe-t-il si votre base de données manque d'espace disque ? Quand était votre dernière sauvegarde ? » Pas pour bloquer l'accès -- pour l'éducation. Une plateforme d'hébergement qui vous rend meilleur en opérations.

La vision : une infrastructure IA-native

Ces fonctionnalités ne sont pas des ajouts aléatoires. Elles forment une vision cohérente : une plateforme d'hébergement IA-native.

Chaque fonctionnalité suit le même schéma : l'IA lit l'état de votre infrastructure, raisonne dessus, agit dessus (avec des portes de sécurité), et communique les résultats. Les outils sont les mêmes que vous utilisiez le chat du tableau de bord, Claude Desktop ou l'API. Le modèle de sécurité est le même. La facturation est la même.

Quand tout cela sera livré, sh0 ne sera pas simplement une plateforme d'hébergement avec de l'IA boulonnée par-dessus. Ce sera une plateforme IA qui héberge aussi vos applications. L'hébergement est le substrat. L'intelligence est le produit.

Aucune autre plateforme ne construit cela. Non pas parce qu'elle ne le peut pas -- mais parce qu'elle optimise pour les cycles d'achat entreprise, pas pour le fondateur solo qui a besoin d'une équipe ops à 2 heures du matin.

Nous construisons cette équipe ops.

La ligne dans le sable

Chaque plateforme d'hébergement finira par ajouter des fonctionnalités IA. Elles l'annonceront à une conférence, livreront une bêta 6 mois plus tard, et passeront en disponibilité générale un an après.

Nous avons livré les fondations en 48 heures. Les fonctionnalités listées ci-dessus seront livrées dans les 2-3 prochaines semaines. Le temps que les plateformes établies tiennent leurs keynotes, sh0 aura 6 mois d'avance et un ensemble de fonctionnalités qu'elles mettront un an à rattraper.

L'assistant IA n'est pas une case à cocher sur une matrice de fonctionnalités. C'est la réponse à une question que chaque développeur solo s'est posée à 2 heures du matin : « Pourquoi mon application est en panne, et comment je la répare ? »

sh0 répond à cette question. Personne d'autre ne le fait. Pour l'instant.

Cet article documente l'ensemble des fonctionnalités IA construites pour sh0.dev entre le 23 et le 25 mars 2026, sur 14 sessions d'ingénierie, avec une feuille de route pour la phase suivante. Tout le code est en production dans les dépôts zerosuite-inc/sh0-core et zerosuite-inc/sh0-website.