- Le problème
- Novita Artifact Hosting : Un foyer pour ce que les agents construisent
- TiDB : La couche de base de données idéale pour les applications générées par IA
- Novita + TiDB : Ajouter une base de données avec un paramètre
- Ce que cela signifie pour les agents de codage IA
- Statut actuel
- Prochaines étapes
Novita Artifact Hosting et TiDB rassemblent le déploiement géré d’applications et une couche de base de données prête pour la production pour les applications générées par IA. Avec Novita qui gère l’exécution et TiDB fournissant une infrastructure de données compatible MySQL, un agent de codage IA peut passer du code généré à une application live, alimentée par des données, via un seul workflow de déploiement.
Le problème
Au cours de l’année écoulée, les agents de codage IA comme Cursor, Claude Code et Devin ont donné l’impression qu’il était possible de « construire une application à partir d’une seule invite ». Mais il y a encore une réalité gênante : la plupart du code généré par les agents n’arrive jamais en production.
Non pas parce que le code est nécessairement mauvais, mais parce que le déploiement est encore trop compliqué.
Une application générée par IA typique peut avoir besoin de :
- Un environnement d’exécution, comme un conteneur ou un sandbox
- Une base de données, comme PostgreSQL ou MySQL
- Un domaine et un certificat SSL
- La configuration de variables d’environnement
- Des scripts de migration de base de données
Ce ne sont pas des choses qu’un agent gère habituellement lorsqu’il écrit du code.

Novita Artifact Hosting : Un foyer pour ce que les agents construisent
Novita Artifact Hosting est une plateforme de déploiement entièrement gérée conçue pour les applications créées par des agents de codage IA. L’idée centrale est simple :
Les agents écrivent le code. Novita fait fonctionner le code.
Le workflow est simple :
- L’agent génère du code et un Dockerfile dans un sandbox.
- Un seul appel SDK,
project.deploy(sandbox_id, arti_dir), démarre le déploiement. - Novita construit l’image Docker.
- Le runtime léger met le déploiement en ligne.
- Les utilisateurs accèdent à l’application via un domaine tel que
https://my-app.novita.space.
Ce workflow est déjà opérationnel. Mais il ne résout que le côté calcul du problème. Les applications réelles ont aussi besoin de données.
TiDB : La couche de base de données idéale pour les applications générées par IA
Pour les applications web générées par IA, la couche de base de données a deux exigences strictes :
- Compatibilité MySQL. La plupart des frameworks compatibles IA, comme Next.js, Django et Laravel, fonctionnent bien avec l’écosystème MySQL. Le code généré par IA est également très susceptible d’utiliser un pilote MySQL.
- Zéro opération. Les développeurs d’agents ne veulent pas gérer les bases de données. Ils ne veulent pas configurer des pools de connexions, ajuster des paramètres ou gérer des sauvegardes.
TiDB répond aux deux exigences :
- Totalement compatible avec le protocole MySQL, donc le code généré par IA peut s’exécuter sans réécrire le SQL.
- Architecture distribuée avec mise à l’échelle automatique, sans besoin d’un DBA dédié.
- Support HTAP, permettant à la même base de données de gérer à la fois les transactions OLTP et les requêtes analytiques.
Novita + TiDB : Ajouter une base de données avec un paramètre
Avec Novita Artifact Hosting, activer une base de données gérée ne prend qu’un paramètre :
deployment = project.deploy(
sandbox_id="xxx",
arti_dir="./workspace/my-app",
database=True, # this line
migrations=[
Path("./migrations/0001_schema.sql").read_text(),
Path("./migrations/0002_seed.sql").read_text(),
],
http_port=3000,
)

Ce qui se passe automatiquement en coulisses :
- Créer ou réutiliser automatiquement une instance TiDB pour le projet.
- Exécuter les migrations dans l’ordre pour créer les tables, index et données initiales.
- Injecter
DATABASE_URLdans l’environnement de déploiement. L’application le lit directement depuisos.environ["DATABASE_URL"]. - Déployer l’application, se connecter à la base de données et commencer à servir les utilisateurs.
Pour les développeurs, cela signifie pas d’inscription à la base de données, pas de configuration de chaîne de connexion, et pas d’étapes de migration manuelles. Juste une ligne : database=True.
Ce que cela signifie pour les agents de codage IA
| Avant | Maintenant |
|---|---|
| L’agent écrit le code, puis un développeur déploie manuellement sur Vercel ou Railway. | L’agent écrit le code, puis un seul appel SDK déploie l’application. |
| Le développeur doit créer une base de données sur TiDB Cloud, PlanetScale ou une autre plateforme. | Une base de données gérée est créée automatiquement et les détails de connexion sont injectés automatiquement. |
| Les scripts de migration doivent être exécutés manuellement. | Les migrations s’exécutent automatiquement dans l’ordre. |
| Les variables d’environnement doivent être configurées à la main. | DATABASE_URL est injecté automatiquement. |
| Livrer une application nécessite une coordination sur trois plateformes. | Une plateforme et une API gèrent l’ensemble du flux. |
Statut actuel
- Artifact Hosting est en ligne et prend en charge les domaines personnalisés.
- Les bases de données gérées propulsées par TiDB sont actuellement en phase d’essai.
- Le SDK Python et le support CLI sont disponibles.
- Des exemples open-source sont disponibles sur GitHub :
ecomm-with-sql,ecomm-with-managed-dbetsnake-game-static.
Prochaines étapes
Une fois que la capacité de base de données gérée atteint la disponibilité générale (GA), la combinaison Novita + TiDB peut s’étendre encore plus loin :
- Déploiement multi-région : les capacités multi-centres de données de TiDB combinées aux nœuds de sandbox globaux de Novita.
- Souveraineté des données : les utilisateurs peuvent choisir où leurs données sont stockées.
- Workflows natifs pour agents : les agents peuvent créer des projets, déployer des applications et provisionner des bases de données directement via le SDK, rendant l’ensemble du processus entièrement automatisé.
