Convex : la plateforme backend temps réel et typée qui réinvente le développement TypeScript en 2026

Base de données réactive, fonctions serveur en TypeScript, requêtes qui se mettent à jour automatiquement côté client, planification de tâches et stockage de fichiers intégrés : Convex propose en 2026 une rupture conceptuelle face aux backends classiques. Là où Supabase mise sur PostgreSQL et Firebase sur un modèle propriétaire, Convex assemble une plateforme entièrement typée de bout en bout, conçue dès le départ pour le temps réel et l'expérience développeur TypeScript.

Une plateforme backend complète et typée de bout en bout

Convex regroupe en un seul produit ce que la plupart des architectures modernes assemblent à la main : base de données documentaire transactionnelle, fonctions serverless, schéma typé, planification de jobs, file d'attente, stockage de fichiers, recherche full-text et authentification. Chaque fonction Convex est écrite en TypeScript, déployée d'une seule commande, et appelée depuis le client avec une inférence de types complète : pas de génération de SDK, pas de schéma OpenAPI, pas de couche tRPC à brancher. Le client React, Vue, Svelte ou React Native consomme directement les types du backend, et toute modification de signature côté serveur se propage instantanément dans l'IDE. Pour les équipes full-stack TypeScript, ce niveau de cohérence transforme radicalement la productivité quotidienne.

La réactivité native : des requêtes qui se mettent à jour toutes seules

La promesse fondatrice de Convex tient en une phrase : toute requête côté client est réactive par défaut. Lorsqu'un composant appelle useQuery(api.messages.list), Convex enregistre les dépendances de la requête (tables, documents, filtres) et pousse automatiquement les résultats actualisés à chaque mutation impactante. Plus besoin de WebSocket à orchestrer, de pub/sub Redis, ni d'invalider manuellement un cache TanStack Query. Le moteur Convex s'appuie sur un journal de transactions et un système de réactivité fin pour rejouer uniquement les requêtes affectées, ce qui rend les expériences collaboratives type Notion, Linear ou Figma accessibles en quelques heures de développement plutôt qu'en plusieurs sprints d'architecture.

Mutations, actions et tâches planifiées : un modèle d'exécution unifié

Convex distingue trois types de fonctions serveur, chacune avec des garanties précises. Les queries sont déterministes, sans effet de bord, et déclenchent la réactivité. Les mutations s'exécutent dans une transaction ACID complète sur la base, garantissant cohérence et idempotence. Les actions, plus permissives, peuvent appeler des APIs externes, lancer des jobs IA ou envoyer des emails, et orchestrent ensuite des mutations pour persister leurs résultats. À cela s'ajoutent les scheduled functions et les cron jobs typés, qui suppriment le besoin d'une infrastructure séparée type BullMQ ou Inngest pour les workflows asynchrones simples. Un seul mental model gouverne donc tout le backend, et les frontières entre couches synchrone, transactionnelle et asynchrone deviennent explicites dès la signature de la fonction.

Schéma typé, recherche full-text et stockage de fichiers intégrés

Le fichier schema.ts de Convex décrit les tables, leurs champs, leurs index et leurs relations dans une syntaxe Zod-like, et sert de source de vérité unique pour la base, les types côté client et la validation des mutations. La recherche full-text est intégrée nativement avec une syntaxe d'index dédiée, sans plugin Postgres ni cluster Elasticsearch à provisionner. Le stockage de fichiers fonctionne en S3-compatible mais s'utilise via les mêmes fonctions typées que le reste du backend, et les uploads peuvent se déclencher directement depuis le navigateur via des URLs signées générées par une mutation. Côté authentification, Convex s'intègre nativement avec Clerk, Auth0 et Better Auth, et expose le contexte utilisateur dans chaque fonction serveur de façon typée.