InstantDB 1.0 : le backend pensé pour le code généré par l’IA

Si tu fais tourner un LLM sur une spec produit et que tu lui demandes de sortir une app complète, le premier truc qui coince c’est toujours le backend. Pas parce que l’IA ne sait pas écrire du SQL — elle le fait très bien. Mais parce qu’un backend correct implique des dizaines de décisions d’architecture que le modèle prend de manière incohérente d’une session à l’autre : structure de la base, règles d’autorisation, gestion de la concurrence, sync côté client. InstantDB 1.0 sort avec une réponse assez directe à ce problème.

Le pitch est simple : un backend clé en main, déclaratif, avec sync temps réel intégré, conçu pour que même du code généré par une IA produise quelque chose de cohérent sans avoir à prendre mille micro-décisions. C’est ambitieux. Et honnêtement, l’architecture décrite dans leur essay vaut le détour.

Ce qu’InstantDB fait vraiment sous le capot

InstantDB est une base de données client-side avec sync côté serveur — un peu comme Firebase, mais avec un modèle de données relationnel et une approche déclarative des permissions. Le client maintient un état local synchronisé en temps réel avec le serveur via des queries réactives. Quand les données changent côté serveur, les composants qui les écoutent se mettent à jour automatiquement, sans polling, sans websocket à gérer à la main.

Côté architecture, InstantDB s’appuie sur un triple store — autrement dit, les données sont stockées sous forme de triplets (entité, attribut, valeur), ce qui ressemble beaucoup à Datomic si tu connais l’écosystème Clojure. Ce choix n’est pas anodin : ça rend les requêtes très flexibles, les migrations de schéma moins douloureuses, et la gestion des relations entre entités beaucoup plus naturelle qu’avec un schéma relationnel classique rigide.

Le langage de query côté client s’appelle InstaQL. Il ressemble à du GraphQL simplifié, pensé pour être généré facilement par un LLM. Tu décris ce que tu veux, pas comment l’obtenir — le runtime s’occupe de traduire ça en opérations effectives sur le triple store et de maintenir la réactivité.

// Exemple de query InstaQL
const { data } = db.useQuery({
  todos: {
    $: { where: { done: false } },
    assignee: {}
  }
});

Pourquoi le « offline-first » change vraiment quelque chose

L’un des aspects les plus solides d’InstantDB, c’est son approche offline-first avec réconciliation optimiste. Quand tu écris une mutation côté client, elle s’applique immédiatement dans l’état local sans attendre la confirmation du serveur. Si le serveur rejette l’opération (permission refusée, conflit, erreur), l’état local est rollbacké proprement.

C’est un pattern connu — on l’appelle « optimistic updates » dans le monde React — mais la différence ici c’est qu’il est géré de manière systématique par le runtime, pas par toi. Dans une app classique, implémenter des optimistic updates propres avec gestion du rollback c’est facilement 50 lignes de code par feature, avec des edge cases désagréables. InstantDB le fait pour toi, à un niveau inférieur.

Pour une app générée par IA, c’est particulièrement précieux : le modèle n’a pas à gérer ces états intermédiaires manuellement. Il déclare des mutations, le SDK fait le reste. Le code généré est moins verbeux, plus lisible, et les bugs liés à la gestion d’état réseau disparaissent d’eux-mêmes.

Les permissions déclaratives : bonne idée, vraie contrainte

InstantDB propose un système de règles d’autorisation déclaratives, défini une fois côté serveur et appliqué automatiquement à toutes les queries et mutations. Tu décris qui peut lire ou écrire quoi, en fonction des attributs de l’utilisateur authentifié et des entités concernées. Le moteur de règles évalue ça avant d’exécuter quoi que ce soit.

C’est une approche proche de ce que fait Hasura avec ses row-level security rules, ou Firebase avec ses Security Rules. L’avantage : tu ne peux pas oublier de sécuriser un endpoint, parce qu’il n’y a pas d’endpoint à sécuriser. Tout passe par le même moteur.

La contrepartie, c’est que tu perds en flexibilité. Dès que tu as une logique métier complexe — un workflow multi-étapes, une règle conditionnelle qui dépend d’un calcul externe, une intégration avec un service tiers — tu vas vite te retrouver à contourner le système de permissions ou à ajouter une couche serverless par-dessus. C’est honnêtement le talon d’Achille de ce type d’approche, et InstantDB ne fait pas exception.

La comparaison avec Firebase : ressemblances et différences concrètes

Firebase est l’éléphant dans la pièce. InstantDB assume la comparaison et l’explique dans son essay d’architecture. Les ressemblances sont réelles : sync temps réel, client SDK, permissions côté serveur, pas d’API REST à maintenir. Mais les différences comptent.

Firebase Realtime Database est un arbre JSON. Firestore est une collection de documents. Les deux modèles sont dénormalisés par nature, ce qui entraîne les problèmes classiques de duplication de données et de queries complexes impossibles à exprimer proprement. InstantDB avec son triple store permet des requêtes relationnelles traversant plusieurs entités sans avoir à dupliquer les données. C’est un vrai gain pour des apps avec un modèle de données non trivial.

L’autre différence notable : InstantDB est open source et peut être auto-hébergé. Firebase est un service Google avec les contraintes que ça implique — vendor lock-in, pricing qui peut dévisser si tu scales, opacité totale sur ce qui se passe sous le capot. Pour des projets sérieux, cette différence n’est pas négligeable.

Ce que ça change (ou pas) pour les devs qui codent encore eux-mêmes

Le positionnement « backend for AI-coded apps » est malin marketing, mais il ne faudrait pas passer à côté de ce qu’InstantDB offre aux devs qui codent manuellement. Le gain en productivité est réel : plus de routes API à écrire pour des opérations CRUD basiques, plus de gestion du cache côté client, plus de websocket à brancher pour du temps réel. Pour un projet solo ou une petite équipe qui veut aller vite, c’est un argument solide.

Là où ça se complique, c’est pour les apps qui sortent du pattern « utilisateur authentifié qui lit et écrit ses propres données ». Dès qu’on parle de transactions complexes, d’agrégations lourdes, d’intégrations avec des services externes qui ont leur propre source de vérité, le modèle d’InstantDB montre ses limites. Ce n’est pas un reproche — aucun outil ne fait tout — mais ça mérite d’être dit clairement avant de bâtir quelque chose dessus.

Il y a aussi la question de la maturité de l’écosystème. La 1.0 vient de sortir. Le triple store sous-jacent, les garanties de cohérence en cas de partition réseau, les performances à l’échelle avec des milliers de clients connectés simultanément — tout ça reste à éprouver en production sur des cas réels sur la durée. Les équipes qui l’adoptent aujourd’hui sont de facto des early adopters, avec ce que ça implique de risques et de contributions à la stabilisation.

Le contexte plus large : la course au « backend invisible »

InstantDB n’arrive pas seul. Il s’inscrit dans un mouvement plus large où plusieurs outils cherchent à rendre le backend aussi transparent que possible pour le développeur frontend — ou pour l’IA qui génère du code frontend. Convex, PowerSync, ElectricSQL, Triplit : tous ont des approches légèrement différentes du même problème. La sync locale avec réconciliation côté serveur est en train de devenir un pattern de référence pour les apps qui ont besoin de réactivité sans sacrifier la cohérence des données.

Ce qui distingue InstantDB dans ce lot, c’est la combinaison du triple store (qui donne une vraie flexibilité relationnelle), du SDK React intégré, et du positionnement explicite autour du code généré par IA. C’est une niche claire, avec une vraie cohérence entre l’architecture choisie et le cas d’usage annoncé.

---

Mon avis : InstantDB est techniquement sérieux. L’architecture triple store pour gérer les relations, la gestion automatique des optimistic updates, les permissions déclaratives — ce sont de vraies décisions d’ingénierie, pas du marketing repeint en outil. Pour prototyper rapidement une app collaborative avec de l’auth et du temps réel, c’est probablement l’une des options les plus cohérentes du moment.

Là où je reste plus prudent, c’est sur le positionnement « backend for AI-coded apps » comme argument principal. Le vrai problème du code généré par IA n’est pas le choix du backend — c’est la cohérence globale de l’architecture sur la durée, les tests, la gestion de la dette. InstantDB réduit la surface de décision, c’est réel. Mais si l’app est architecturalement bancale dès le départ, un backend élégant ne sauvera pas grand chose.

Le pari qui m’intéresse davantage : est-ce que le triple store va tenir sur des volumes sérieux ? C’est là que se jouera la vraie crédibilité d’InstantDB au-delà du cycle de hype des outils de vibe coding. La 1.0 est une bonne base. La 2.0 sera plus révélatrice.