Test NocoDB 2026 : analyse complète de l’alternative open source à Airtable

Tôt ou tard, presque toutes les équipes se heurtent au même mur : les données vivent dans Google Sheets, le fichier gonfle jusqu’à cent onglets liés, les formules cassent à chaque ligne insérée et la moitié de l’équipe modifie la mauvaise colonne. Airtable a résolu le problème avec élégance — en apportant une facture par utilisateur et une question gênante : veut-on vraiment stocker les données clients dans le cloud d’un autre ?

NocoDB est la réponse la plus populaire aux deux questions à la fois. C’est une plateforme open source qui transforme une base SQL ordinaire en tableur intelligent avec formulaires, kanban, rôles et API REST. Le projet est né de l’idée « Airtable au-dessus de votre propre base de données » et totalise en 2026 plus de 50 000 étoiles GitHub, des dizaines de milliers d’installations auto-hébergées et un produit cloud commercial complet.

Dans ce test, nous regardons comment NocoDB fonctionne à l’intérieur, ce qu’il fait réellement bien, où ça coince, ce que coûte le cloud et ce qu’implique un serveur personnel — avec un verdict honnête à la fin : qui doit migrer, et qui a plutôt intérêt à rester sur Airtable ou à regarder Baserow.

Ce qu’est NocoDB et comment il est construit

L’idée architecturale centrale est simple, et c’est précisément pour cela qu’elle a de la valeur : NocoDB ne stocke pas vos données dans un format propriétaire. Il se connecte à une base relationnelle existante — PostgreSQL, MySQL/MariaDB, SQLite, et dans les versions récentes Microsoft SQL Server — et affiche par-dessus une interface web de type tableur.

Ce que cela signifie concrètement :

• Chaque table NocoDB est une vraie table dans votre base. Chaque colonne est une vraie colonne. Chaque ligne est un enregistrement ordinaire.
• Vous pouvez vous connecter à la même base avec psql, lancer du SQL, alimenter un outil de BI ou transmettre les données à une application existante à tout moment.
• Si NocoDB disparaissait demain (les projets open source sont mortels), vos données resteraient dans une base standard, pas dans un export fermé.

La pile technique n’est pas exotique non plus : backend Node.js, frontend Vue, le tout empaqueté en image Docker. Pour l’auto-hébergement, cela veut dire un docker run et quelques variables d’environnement — pas de cluster, pas de stockage objet obligatoire, pas de Redis imposé.

Il faut distinguer les deux formats de distribution, car la confusion est permanente ici :

1. NocoDB Open Source — la version gratuite que vous déployez vous-même. Fonctions de base : tables, vues, rôles, API, webhooks. Les limites concernent les sujets enterprise avancés : SSO, audit et permissions fines.
2. NocoDB Cloud — le service managé des développeurs, qui possèdent l’infrastructure. C’est là que vivent les offres payantes aux limites plus élevées.

La troisième option, la moins évidente, est la base externe : vous branchez une instance Postgres qui fait déjà tourner votre produit et obtenez une interface d’administration confortable sur des données de production. Pratique pour le support et l’analyse, mais attention : une interface web ne remplace pas les migrations.

À qui NocoDB s’adresse vraiment

D’après l’expérience terrain, NocoDB s’épanouit dans quatre scénarios.

Tables opérationnelles internes. CRM léger, base clients, suivi de tickets, inventaire, registre de contrats. Tout ce qui vivait dans Google Sheets et ne rentre plus dedans.

Remplacer un back-office bricolé. Si vous avez une base et besoin d’une interface pour opérateurs — formulaires, filtres, droits — NocoDB couvre 80 % du besoin sans une ligne de frontend.

Couche au-dessus d’une base héritée. Un vieux MySQL du système comptable auquel personne n’ose toucher. NocoDB lui donne une interface humaine sécurisée avec accès par rôles.

Prototype produit rapide. Quand il faut un backend CRUD fonctionnel avec API du jour au lendemain, et non un sprint Nest.js.

Et là où il ne faut pas l’utiliser :

• Comme base principale d’un produit à forte charge avec des milliers d’utilisateurs simultanés.
• Comme stockage de fichiers ou médiathèque — les pièces jointes marchent, mais ce n’est pas S3.
• Comme remplacement d’un vrai BI : tableaux croisés et graphiques existent, l’analyse profonde non.
• Pour des équipes qui ont besoin du mode hors ligne et d’applis mobiles natives au niveau d’Airtable.

Points forts et points faibles

Points forts

• Open source avec un vrai auto-hébergement, sans réserve « cloud only ».
• Les données restent dans votre base SQL, accessibles en SQL et par n’importe quel client.
• La version gratuite est fonctionnellement complète pour des équipes de 10 à 20 personnes.
• API REST et GraphQL prêtes pour chaque table, documentées dans l’interface.
• Nombreuses vues : grille, formulaire, galerie, kanban, calendrier, carte.
• Rôles du propriétaire au lecteur seul et au commentateur.
• Webhooks et automatisations sur événements d’enregistrement.
• Communauté active et versions fréquentes ; le projet est vivant.

Points faibles

• L’interface peut peser : au-delà de 50 colonnes et de dizaines de milliers de lignes, le navigateur réfléchit.
• Les formules et rollups fonctionnent mais restent en retrait d’Airtable en profondeur et en débogage.
• Les automatisations sont modestes : branches complexes et déclencheurs externes demandent des contournements.
• Pas d’applis mobiles natives, seulement une version web adaptative.
• L’auto-hébergement exige des compétences : Docker, reverse proxy, sauvegardes et mises à jour sont à votre charge.
• Les montées de version majeures demandent parfois une migration manuelle du schéma.
• Certaines fonctions enterprise (SSO, audit, permissions granulaires) sont payantes.

Fonctionnalités : ce que NocoDB fait vraiment en 2026

Vues

Une table, plusieurs vues — et ce n’est pas une formule marketing. La grille est le mode de base avec filtres, tri, regroupement et colonnes figées. Le formulaire publie un lien public et collecte des données auprès de personnes extérieures sans accès à la base. La galerie affiche les enregistrements en cartes avec couvertures, pratique pour les catalogues. Le kanban regroupe par champ de statut avec glisser-déposer. Le calendrier lie les enregistrements aux dates, la carte aux coordonnées.

Chaque vue enregistre ses filtres et réglages séparément. Pour un opérateur, cela veut dire que le même jeu de données apparaît comme « tous les tickets », « mes tickets ouverts » et « en retard » sans dupliquer les tables.

Types de champs

L’éventail est large : texte, nombre, date et heure, case à cocher, sélection simple et multiple, e-mail, URL, téléphone, devise, pourcentage, note, formule, rollup, lookup, relations (un-à-un, un-à-plusieurs, plusieurs-à-plusieurs), pièces jointes, JSON, géodonnées, code-barres, texte long et champ utilisateur/assigné.

Les relations reposent sur de vraies clés étrangères, pas sur des identifiants texte — cela se remarque lors des migrations et du travail sur les données depuis l’extérieur.

API

Chaque table obtient automatiquement une API REST : liste des enregistrements avec filtres et pagination, création, mise à jour, suppression, opérations en masse. Plus un endpoint GraphQL pour les requêtes complexes et des jetons d’accès limités par table.

C’est le point qui distingue NocoDB d’« un joli tableur » : vous pouvez écrire un bot, un script Python ou une appli mobile sur la même base via une API documentée, pendant que l’équipe continue de saisir à la main dans le navigateur.

Rôles et accès

Niveaux : Owner, Creator, Editor, Commenter, Viewer. Les droits s’attribuent par base et par table. S’ajoutent des liens publics vers des vues — avec ou sans mot de passe, téléchargement des pièces jointes désactivable.

Dans l’édition open source, les permissions granulaires (au niveau ligne et colonne) sont limitées — l’une des principales raisons d’acheter une licence.

Webhooks et automatisations

Les webhooks se déclenchent à la création, la mise à jour et la suppression d’enregistrements et envoient du JSON à votre endpoint. Le constructeur d’automatisations intégré gère des chaînes simples : « au changement de statut — envoyer un e-mail », « selon un planning — créer un enregistrement », « à l’arrivée d’un enregistrement — appeler une API externe ».

Cela ne suffit pas pour une vraie orchestration — en général NocoDB sert de source de données et la logique vit dans n8n, Make ou un service maison.

Tarifs : cloud contre serveur personnel

La clarté s’impose ici, car la grille tarifaire de NocoDB a changé plusieurs fois et les montants exacts sont à vérifier sur le site officiel au moment de la lecture.

Open Source (auto-hébergé) — gratuit. L’image Docker complète, sans limite d’enregistrements, de tables ni d’utilisateurs. Vous payez seulement le serveur.

Cloud Free — une offre gratuite pour petite équipe : utile pour découvrir le produit, mais plafonnée en utilisateurs et en lignes.

Offres Cloud payantes — par siège en facturation annuelle. Les plans hauts lèvent les limites de sièges : on trouve des propositions « utilisateurs illimités pour un forfait mensuel fixe » — pour 15 à 30 personnes, c’est mathématiquement moins cher qu’Airtable Team.

Business/Enterprise auto-hébergé — licence payante pour votre propre installation, facturée par éditeur (pas par lecteur). Apporte SSO, audit, permissions étendues et support prioritaire.

L’arithmétique simple à garder en tête : un VPS capable de faire tourner NocoDB avec une base de 5 à 10 Go coûte moins que dix sièges cloud. C’est exactement pourquoi l’auto-hébergement est le scénario principal de ce produit.

Test pratique : déployer NocoDB sur un VPS

Nous avons déployé NocoDB deux fois : avec Docker Compose et PostgreSQL sur un VPS, puis en « SQLite dans le conteneur » pour comparer.

Besoins en ressources

• Minimum : 2 vCPU, 2 Go de RAM, 20 Go SSD — pour une équipe jusqu’à 10 personnes et des centaines de milliers d’enregistrements.
• Confortable : 4 vCPU, 4 à 8 Go de RAM, NVMe — pour 20 à 50 utilisateurs actifs et des millions de lignes.
• PostgreSQL, pas SQLite — au-delà de quelques gigaoctets de données ou de cinq utilisateurs. SQLite convient pour un test, mais les verrous d’écriture se font sentir.

Un Compose de deux services (nocodb + postgres) démarre en cinq minutes. Seul le port 8080 doit être exposé, derrière un reverse proxy avec TLS — Nginx ou Caddy, ce dernier étant plus simple pour les certificats.

Où l’héberger

Choisissez un hébergeur avec du matériel local et un vrai contrôle. Nous avons fait tourner l’installation sur Timeweb Cloud — images prêtes pour Docker et réseau privé, pratique si vous déplacez Postgres sur une autre machine plus tard. Pour un budget minimal, FirstVDS a fait l’affaire : configurations plus simples, mais KVM honnête sans surcoût de panneau. Le domaine a été enregistré chez REG.RU, qui offre aussi une gestion DNS gratuite.

Ce que nous avons testé à la main

Vitesse de l’interface. Une table de 60 000 lignes et 25 colonnes s’ouvre en 1,5 à 2 secondes, le filtrage est instantané, la pagination fonctionne. À 500 000 lignes, la grille commence à ramer nettement : NocoDB pagine les données, mais un tri sur un champ non indexé impose l’attente. Conclusion : les index en base restent indispensables, et les ajouter est plus simple en SQL que via l’interface.

Import CSV. Un fichier de 40 Mo avec 200 000 lignes est monté en une minute environ, avec une inférence de types correcte. Les accents et caractères non ASCII ont survécu intacts — important pour les projets localisés.

Recherche. La recherche plein texte fonctionne au niveau du ILIKE de la base, donc sans racinisation. Pour une recherche sérieuse, il faut ajouter pg_trgm ou un index externe.

Rôles. Nous avons testé « l’opérateur ne voit que ses tickets » : dans l’édition open source, c’est un filtre de vue plus un compte séparé, pas une vraie sécurité au niveau ligne. Le vrai RLS est payant ou passe par des vues dans la base.

Sauvegardes. Pas de planificateur intégré. Le schéma qui marche : pg_dump en cron vers du stockage objet, plus une sauvegarde séparée du volume des pièces jointes. C’est la première chose à faire après l’installation : restaurer une interface sans sa base ne sert à rien.

Mises à jour. Changer le tag de l’image et lancer docker compose up -d. Les versions mineures se sont bien passées ; une montée majeure a exigé une migration manuelle — lisez les notes de version avant de sauter.

Pièces jointes. Les fichiers sont stockés dans un volume du conteneur ou dans un stockage compatible S3. Si l’équipe téléverse des contrats scannés, S3 est obligatoire, sinon la sauvegarde du volume grossit sans contrôle.

Ce qui a manqué

• Un vrai journal d’audit par enregistrement — absent de l’édition gratuite.
• L’édition en masse de formules depuis l’interface.
• Un diagnostic clair des requêtes lentes : on finit dans les logs Postgres.

NocoDB face à la concurrence

Airtable. Airtable reste plus agréable dans les détails : interfaces, automatisations, applis mobiles, écosystème. Mais les données restent chez l’éditeur et le prix par siège pour 20 personnes devient désagréable. NocoDB gagne sur le contrôle et le coût de possession, Airtable sur le poli.

Baserow. Le concurrent open source le plus proche. Baserow mise sur la simplicité et un format de données propre (même s’il gère désormais les bases externes). Son interface est plus agréable et rapide ; NocoDB va plus loin sur la connexion aux bases SQL existantes et sur la couche API.

SeaTable. Solide sur les formules et la logique tableur, plus proche d’Excel. Projet allemand avec un bon auto-hébergement, mais une communauté plus petite.

Teable. Jeune projet à l’interface moderne et axé performance ; prometteur pour les très grandes tables, mais écosystème et documentation encore plus fins.

Google Sheets. Gratuit et familier, mais sans rôles, sans relations et sans discipline d’API. Dès qu’il y a plus de deux éditeurs et des entités liées, il est temps de bouger.

Verdict

NocoDB est le meilleur choix en 2026 si vous avez besoin d’une couche façon Airtable au-dessus de votre propre base SQL et acceptez de consacrer une soirée à Docker, au domaine et aux sauvegardes. En échange : contrôle total des données, usage gratuit pour une équipe de n’importe quelle taille et une API à laquelle tout peut se brancher.

N’allez pas vers NocoDB si toute l’équipe est non technique et que personne n’assumera le serveur ; s’il faut des automatisations au niveau d’Airtable ; si les applis mobiles natives sont critiques ; ou si un audit strict et une sécurité au niveau ligne sont exigés sans acheter de licence.

Idéal pour : équipes produit et ops de 5 à 30 personnes, agences, petits projets SaaS déjà sur Postgres et tous ceux qui en ont assez de payer au siège pour des tableurs cloud.

Conseil de déploiement : commencez par la version auto-hébergée sur un VPS avec 4 Go de RAM et PostgreSQL — suffisant pour la première année. Traitez NocoDB comme une couche au-dessus de la base, pas comme le seul endroit où vivent les données, mettez pg_dump en place dès le premier jour et déplacez les pièces jointes vers S3. Si après un mois l’équipe l’utilise activement, regardez une licence pour SSO et audit — pas l’inverse.

Et chez vous, comment sont organisées les tables internes : encore Google Sheets, ou déjà quelque chose comme NocoDB ?