J'ai comparé huit alternatives à Convex. Je reste sur Convex

J’ai comparé huit alternatives à Convex en juillet 2026. Aucune n’offre un backend que mes agents d’IA modifient plus facilement. Appwrite est le meilleur concurrent établi et InsForge le nouveau venu le plus intéressant, mais Convex reste devant parce que le schéma, les fonctions, les tâches, la logique de stockage et la configuration de l’authentification sont réunis en TypeScript.

Mon classement : le nombre de systèmes compte plus que le prix

J’ai classé les plateformes selon le nombre de systèmes distincts qu’un agent doit comprendre pour terminer une modification du backend. Ce critère compte davantage que le prix, puisque cinq des neuf offres payantes les moins chères coûtent entre 25 et 30 $ par mois. Convex arrive en tête, devant InsForge et Appwrite.

Le facteur décisif n’était pas le nombre de fonctionnalités proposées. Je voulais savoir si un agent pouvait consulter et modifier toute une fonctionnalité du backend sans passer par plusieurs systèmes de configuration.

Pourquoi Convex fonctionne-t-il si bien avec le développement assisté par IA ?

Convex me paraît plus simple parce que tout le backend se trouve sous forme de code dans un seul dossier. Le schéma, les queries, les mutations, les tâches planifiées, le stockage des fichiers, les index vectoriels et la configuration de l’authentification sont regroupés dans des fichiers TypeScript. Un agent d’IA peut donc modifier une fonctionnalité comme n’importe quel autre module, sans étape distincte dans une interface d’administration.

convex/
  schema.ts       # tables, indexes, vector indexes
  users.ts        # queries and mutations
  billing.ts      # actions calling Stripe
  crons.ts        # scheduled jobs
  http.ts         # webhook endpoints
  auth.config.ts  # auth providers

Ce sont les fichiers qu’un agent doit réellement comprendre avant de livrer une fonctionnalité, et ils tiennent sur un écran. Dans mes projets, une fonctionnalité d’invitation soumise à une limite de fréquence touche généralement trois fichiers de ce dossier. Si le modèle définit mal les données, les types générés signalent une erreur. Il n’y a pas non plus de modification séparée dans une interface à oublier.

Convex donne aussi aux agents un accès direct au backend grâce à ses outils officiels. Le guide Claude Code du Convex Developer Hub explique comment installer le plugin avec /plugin install convex@claude-plugins-official. Celui-ci peut ensuite lire les données et les logs de développement, exécuter des fonctions et maintenir les types générés à jour [1]. Le guide Codex propose un accès similaire par MCP et ajoute les sous-agents convex-expert et convex-reviewer [2]. Mon agent peut examiner le véritable backend au lieu d’en deviner le fonctionnement.

La recherche vectorielle suit le même principe : je déclare un vectorIndex dans le schéma, je lui attribue 1 536 dimensions pour les embeddings d’OpenAI, puis je l’interroge depuis le code serveur [3]. Il n’y a ni seconde base de données ni processus de synchronisation distinct à gérer. On appelle parfois cette manière de développer le vibe coding, mais l’étiquette compte moins que son intérêt pratique. Moins il y a de composants, moins l’agent et moi risquons d’en oublier un.

Pourquoi j’ai choisi Convex plutôt que Supabase pour développer avec l’IA

Supabase m’a perdu parce qu’une seule modification du backend touchait souvent aux migrations SQL, aux politiques de sécurité au niveau des lignes, aux Edge Functions, aux règles de stockage et aux types générés. J’apprécie son écosystème Postgres, mais ces composants séparés donnaient à mes agents plus d’occasions de laisser le travail à moitié terminé dans mes projets en production.

Le guide de migration de Supabase décrit clairement la discipline requise. Sa règle principale consiste à « ne jamais modifier directement la base de données distante ». Chaque changement de schéma devient donc une migration SQL horodatée qu’il faut tester en local, enregistrer dans le dépôt, puis appliquer. Une modification dans l’interface peut désynchroniser les versions locale et distante [4].

C’est un processus d’ingénierie cohérent, mais il multiplie les endroits où un agent peut effectuer une modification incomplète. Dans mes projets, les agents mettaient régulièrement quatre éléments à jour et oubliaient le cinquième. Convex évite ce problème précis, car ce cinquième endroit n’existe pas.

Les changements de schéma Convex peuvent toujours demander une mise à jour des données existantes. Le code correspondant reste toutefois à côté du reste du backend, au lieu de rejoindre une chaîne parallèle de fichiers et d’outils.

Pourquoi les autres alternatives à Convex n’ont-elles pas suffi ?

Il manque à chacune des autres alternatives une partie différente du fonctionnement que je recherche. Appwrite est capable, mais répartit le backend entre plusieurs ressources. InstantDB demande une autre plateforme pour la logique serveur, tandis que Cloudflare m’oblige à assembler moi-même le backend. Firebase, Nhost et Encore.ts imposent des compromis comparables.

Appwrite est l’alternative établie la plus solide

Appwrite est le tout-en-un établi le plus convaincant, surtout si la capacité d’authentification importe davantage que le regroupement du backend dans une seule base de code. Son offre à 25 $ par mois couvre toute l’organisation et comprend 200 000 utilisateurs actifs mensuels, 150 Go de stockage, 2 To de bande passante, 3,5 millions d’exécutions de fonctions et des sauvegardes quotidiennes [5].

Appwrite propose également des skills pour agents couvrant neuf SDK dans Claude Code, Codex et Cursor [6]. Ses serveurs MCP peuvent gérer directement les bases de données, les utilisateurs et les fichiers [7]. La plateforme prend donc le travail des agents au sérieux. Si vous travaillez dans Cursor, j’ai expliqué pourquoi l’Agents Window peut s’ouvrir en premier et comment retrouver l’IDE.

Je classe malgré tout Appwrite en troisième position parce que son backend reste un ensemble de ressources, notamment des buckets, des permissions et des tâches planifiées, plutôt qu’une base de code unique que je peux lire. La recherche vectorielle ajoute une autre dépendance : le propre guide d’Appwrite relie une Function à OpenAI pour les embeddings et utilise un index Pinecone externe pour la recherche [8]. C’est exactement le service supplémentaire que je voulais éviter.

InstantDB exige une seconde plateforme pour la logique serveur

InstantDB propose le fonctionnement qui ressemble le plus à Convex, mais ne couvre qu’une partie du backend dont j’ai besoin. Son schéma et ses permissions sont du code, et les agents peuvent utiliser un serveur MCP pour créer des applications et modifier ces deux éléments. InstantDB fournit aussi des fichiers d’instructions pour Claude Code et Codex [9].

L’offre gratuite comprend 1 Go, un nombre illimité de requêtes API et aucune mise en pause automatique. L’offre Pro à 30 $ porte le stockage à 10 Go, puis ajoute dix membres d’équipe et des sauvegardes quotidiennes [10]. Ces conditions sont intéressantes, mais ne compensent pas l’absence des fonctionnalités côté serveur.

Le problème vient du fait qu’InstantDB est un moteur de synchronisation avec authentification et stockage, et non un endroit où exécuter la logique serveur. Sa documentation couvre la présence, les curseurs, les permissions et une API HTTP d’administration, mais pas les fonctions hébergées, les tâches cron ou la recherche vectorielle [11]. Il me faudrait toujours une seconde plateforme pour la partie serveur du produit. InstantDB ne répond donc pas à mes besoins.

Cloudflare est peu cher, mais ce n’est pas un backend unique

Cloudflare affiche le prix de départ le plus bas, mais atteindre les mêmes fonctions demande plusieurs produits distincts. Son offre à 5 $ par mois comprend 10 millions de requêtes et 30 millions de millisecondes de CPU [12], tandis que Vectorize fournit une base de données vectorielle directement reliée aux Workers [13].

Pour construire un backend complet, je dois réunir Workers, D1, R2, Queues et Vectorize, avec une configuration propre à chacun, puis ajouter séparément l’authentification des utilisateurs. La gestion des données dans l’UE demande aussi de l’attention : D1 peut conserver une base dans une juridiction européenne, mais les Workers peuvent toujours y accéder depuis n’importe où, car la restriction géographique s’applique à la base de données, pas au calcul [14].

Firebase reste un ensemble de produits séparés

Firebase reste compétitif et offre l’authentification jusqu’à 50 000 utilisateurs actifs mensuels avant l’application des tarifs de Google Cloud Identity Platform [15]. Il demeure cependant un ensemble de produits Google Cloud avec des interfaces et une tarification séparées. Il ne répond donc pas à mon besoin d’une seule base de code pour le backend.

Nhost ramène un processus de migration en plusieurs parties

Nhost réunit Postgres, GraphQL, l’authentification et le stockage à partir de 25 $, dont 15 $ de crédits de calcul, avec un nombre illimité d’utilisateurs [16]. Un changement de schéma produit à la fois une migration SQL et des métadonnées Hasura en YAML. Le guide de développement local de Nhost demande de les enregistrer et de les déployer ensemble [17]. Ce processus ressemble à celui de Supabase qui a posé problème dans mes projets.

Encore.ts commence à 148 $ avant la facture du cloud

Encore.ts résout un autre problème : je déclare l’infrastructure en TypeScript, puis Encore la crée dans mon propre compte AWS ou GCP. En production, le prix commence à 49 $ par membre, plus 99 $ par environnement cloud. Il faut ensuite ajouter 2,50 $ par ressource et la facture AWS [18]. Le tarif minimal de la plateforme atteint donc 148 $ par mois.

Ce modèle peut convenir à une équipe qui gère déjà un compte cloud, et les outils d’Encore consacrés au développement avec l’IA sont utiles. Il ne correspond pas à ma façon de lancer rapidement de petits produits.

InsForge est l’alternative à Convex que je surveille

InsForge se rapproche le plus du fonctionnement que je recherche, car c’est la seule alternative de la liste conçue spécialement pour les agents d’IA. Son orientation convient à ma manière de travailler, mais son âge et son financement me dissuadent encore d’y transférer les données de mes clients.

Lors du lancement de sa version 2.0, le 9 mars 2026, InsForge s’est présenté comme un backend destiné au développement avec des agents. L’entreprise affirmait que les agents réalisaient déjà 99 % des opérations sur la plateforme [19]. OpenAI aborde l’infrastructure pour agents par l’autre bout, et je détaille ce que son Agents API héberge et ce qui reste à votre charge.

Cette affirmation s’appuie sur un produit qui réunit Postgres et pgvector, l’authentification, le stockage, des edge functions, le temps réel et une passerelle compatible avec OpenAI pour les modèles de plusieurs fournisseurs [19]. InsForge prend en charge les fonctions déclenchées par cron grâce à pg_cron [20], et son code sous licence Apache 2.0 peut être auto-hébergé avec Docker [21]. L’offre Pro à 25 $ comprend 100 000 utilisateurs actifs mensuels, une base de données de 8 Go et 10 $ de crédits de calcul. Les petites instances toujours actives commencent à 5 $ [22].

J’ai placé InsForge en deuxième position, et non en première, notamment parce que Postgres réintroduit les migrations et la sécurité au niveau des lignes, même lorsque les agents s’en chargent. Mon inquiétude principale concerne toutefois l’âge de l’entreprise. Crunchbase recense un tour de pré-seed de 1,5 million de dollars auprès de MindWorks Capital et Baidu Ventures [23], tandis que MindWorks indique que l’entreprise date de 2025 [24].

Convex en est à un stade bien plus avancé. L’entreprise a levé 24 millions de dollars en novembre 2025 lors d’un tour mené par a16z et co-mené par Spark Capital [25], puis a annoncé près de 10 000 équipes payantes en avril 2026 [26].

Convex, dernier tour

24 M$

mené par a16z, novembre 2025

équipes payantes chez Convex

10 000

chiffre de l'entreprise, « près de 10 000 », avril 2026

InsForge, pré-seed

1,5 M$

MindWorks Capital et Baidu Ventures, 2025

L’écart de maturité explique pourquoi je testerais InsForge sans encore lui confier les données de mes clients. Sa licence Apache 2.0 et la possibilité de l’auto-héberger rendent un futur essai moins risqué.

Combien coûte Convex dans l’UE ? 30 % de plus, sans les quotas américains

Un déploiement Convex payant dans l’UE coûte 30 % de plus que son équivalent américain et ne bénéficie pas des quotas d’utilisation inclus dans les offres payantes aux États-Unis. La page de prix principale de Convex accorde 25 millions d’appels de fonctions aux déploiements Pro américains [27]. L’annonce de la région européenne précise que ses ressources payantes coûtent 30 % de plus et sont facturées à la demande [28].

La région européenne fonctionne dans AWS eu-west-1, en Irlande, et est proposée avec toutes les offres, y compris la formule gratuite. Pour un produit européen avec beaucoup de trafic, cette différence doit entrer dans le calcul des coûts avant de choisir la région.

Le surcoût européen n’est pas ma seule réserve. Les déploiements Free et Starter utilisent la classe S16, avec 16 queries et 16 mutations simultanées, tandis que la formule Professional passe à S256 [29]. Le trafic peut donc suffire à imposer le passage à l’offre à 25 $ par développeur [27].

Convex Auth présente une autre limite. Le produit reste en bêta, et sa documentation indique qu’il « n’est pas complet et peut changer d’une façon incompatible avec les versions antérieures ». Pour l’authentification en production, Convex recommande Clerk, Auth0 ou WorkOS, ce dernier étant gratuit jusqu’à un million d’utilisateurs [30].

La simplicité du backend regroupé dans un dossier crée également un lock-in. Mon backend utilise les queries et les mutations de Convex avec un modèle documentaire, pas du SQL que je peux relier directement à un outil de reporting courant.

Malgré ces réserves, le prix d’entrée reste raisonnable. L’offre Starter gratuite accepte des applications en production pour six développeurs au maximum et comprend un million d’appels de fonctions sur les déploiements américains [27]. Je continue d’accepter les coûts de Convex parce que toutes les alternatives que j’ai trouvées demandent plus de temps de développement. Ce temps me coûte plus cher que la facture de la plateforme.

Quelle alternative à Convex devriez-vous choisir ?

Pour livrer rapidement un produit avec l’aide de l’IA, je choisirais Convex. Je testerais Appwrite si l’authentification de centaines de milliers d’utilisateurs devenait la principale contrainte, car son tarif fixe de 25 $ par organisation devient plus intéressant que la facture de Convex par développeur à mesure que l’équipe grandit [5].

Je réexaminerais InsForge à la mi-2027. Un nouveau tour de financement et des clients en production publiquement identifiés pourraient changer ma réponse, tandis que sa licence autorisant l’auto-hébergement réduit déjà le risque d’un futur essai.

Le test pratique est simple : ouvrez le dépôt après une semaine d’absence et regardez si un seul dossier vous indique où se trouve la logique du backend. Si c’est le cas, un agent d’IA aura plus de chances de terminer une modification sans oublier une étape de configuration distincte. Pour tout ce qui se trouve hors du dossier backend, je m’appuie sur une carte en quatre couches qui guide mes agents vers les faits à jour.

Dans mon article précédent, j’examinais jusqu’où laisser décider un modèle d’IA. Le choix du backend pose une question proche : combien de composants distincts ce modèle doit-il comprendre ? Convex reste mon choix parce qu’il réduit ce nombre au minimum.