Héberger NocoDB : votre alternative à Airtable, en base de données

Le confort d’Airtable tient à une idée simple : manipuler des données structurées avec une interface aussi accessible qu’un tableur. Mais cette simplicité implique souvent d’envoyer les données, les pièces jointes et les processus métier vers un service SaaS externe.

NocoDB propose une autre approche. Cette plateforme open source transforme une base PostgreSQL ou MySQL en espace de travail collaboratif. Les équipes disposent de tables, de vues et de formulaires, tandis que la base SQL et son API restent sur leur propre infrastructure. NocoDB peut créer une nouvelle base ou se connecter à une base existante, ce qui convient autant à un nouveau projet qu’à la modernisation d’un outil interne.

Ce que fait NocoDB

NocoDB ajoute une interface visuelle au-dessus de données structurées. Les utilisateurs travaillent sans écrire directement de requêtes SQL, mais les informations restent enregistrées dans une véritable base de données.

Plusieurs présentations sont disponibles :

• La vue grille pour saisir, filtrer, trier et regrouper les enregistrements
• La vue kanban pour organiser un pipeline commercial, éditorial ou opérationnel
• La galerie pour afficher des fiches illustrées ou des catalogues
• Les formulaires pour collecter des données sans donner accès aux tables
• Les vues personnalisées pour montrer uniquement les champs et lignes utiles

NocoDB gère également les relations entre tables, les rôles, la collaboration et les webhooks. Une API REST est générée à partir des tables, ce qui permet de connecter une application, un site ou un scénario d’automatisation. Selon la version et les fonctionnalités retenues, il faut vérifier la disponibilité des interfaces complémentaires comme GraphQL avant de concevoir une intégration autour d’elles.

L’intérêt principal ne consiste donc pas seulement à remplacer une feuille Airtable. Il s’agit de conserver une base SQL exploitable par d’autres logiciels, tout en donnant aux équipes une interface no-code.

Prérequis pour auto-héberger NocoDB

Pour un déploiement destiné à plusieurs utilisateurs, prévoyez :

• Un VPS Linux
• Docker et le plugin Docker Compose (voir installer Docker sur un VPS)
• Un nom de domaine ou un sous-domaine
• Un enregistrement DNS pointant vers le VPS
• Une base PostgreSQL persistante
• Un reverse proxy pour publier le service en HTTPS
• Une stratégie de sauvegarde hors du serveur

Sans variable NC_DB, NocoDB utilise SQLite. Ce fonctionnement est pratique pour découvrir le produit sur une machine locale, mais il ne convient pas à une production multi-utilisateurs. PostgreSQL apporte une meilleure base pour les accès concurrents, les sauvegardes et la restauration.

Les VPS TalCloud démarrent à 4,99 € par mois. L’offre s’inscrit dans une infrastructure française avec stockage NVMe, protection Anti-DDoS Netrix, prise en compte du RGPD et support humain. Pour NocoDB, dimensionnez le VPS selon le volume de données, le nombre d’utilisateurs, les pièces jointes et la charge des intégrations.

Déployer NocoDB avec Docker Compose

Créez un répertoire de travail sur le VPS, puis placez-y un fichier .env. Générez deux secrets hexadécimaux, l’un pour PostgreSQL et l’autre pour la signature des jetons JWT :

openssl rand -hex 32
openssl rand -hex 32

Enregistrez les valeurs sans guillemets :

POSTGRES_PASSWORD=remplacer_par_le_premier_secret
NC_AUTH_JWT_SECRET=remplacer_par_le_second_secret

Le secret NC_AUTH_JWT_SECRET doit être long, aléatoire et distinct du mot de passe PostgreSQL. Ne stockez pas ce fichier dans un dépôt Git.

Ajoutez ensuite un fichier compose.yml :

services:
  postgres:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      POSTGRES_DB: nocodb
      POSTGRES_USER: nocodb
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
    volumes:
      - postgres_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U nocodb -d nocodb"]
      interval: 10s
      timeout: 5s
      retries: 10

  nocodb:
    image: nocodb/nocodb
    restart: unless-stopped
    depends_on:
      postgres:
        condition: service_healthy
    environment:
      NC_DB: "pg://postgres:5432?u=nocodb&p=${POSTGRES_PASSWORD}&d=nocodb"
      NC_AUTH_JWT_SECRET: ${NC_AUTH_JWT_SECRET}
    ports:
      - "127.0.0.1:8080:8080"
    volumes:
      - nocodb_data:/usr/app/data

volumes:
  postgres_data:
    name: nocodb_postgres_data
  nocodb_data:
    name: nocodb_app_data

La valeur NC_DB désigne le service PostgreSQL interne au réseau Docker. Le mot de passe hexadécimal évite les difficultés d’encodage de caractères spéciaux dans la chaîne de connexion.

Le port 8080 est ici lié à 127.0.0.1. NocoDB reste donc inaccessible directement depuis Internet et devra passer par le reverse proxy.

Démarrez les conteneurs :

docker compose up -d
docker compose ps
docker compose logs --tail=100 nocodb

En production, remplacez idéalement l’image non versionnée par une balise NocoDB précise et testée. Cela évite qu’un redéploiement récupère silencieusement une version différente.

Premier accès et compte administrateur

Une fois le reverse proxy configuré, ouvrez l’adresse HTTPS de NocoDB. Lors d’une nouvelle installation, le premier compte créé devient le super administrateur de l’instance.

Utilisez une adresse contrôlée par l’organisation et un mot de passe unique. Conservez les moyens de récupération dans le gestionnaire de secrets de l’équipe. Le super administrateur peut gérer les espaces, les utilisateurs et les paramètres globaux : ce compte ne doit pas servir aux opérations quotidiennes d’un utilisateur standard.

Avant d’inviter toute l’équipe, vérifiez également que NocoDB utilise bien PostgreSQL. Une installation SQLite créée pendant un test ne doit pas devenir la production par simple prolongement de son usage.

Créer une base, des tables et des vues

NocoDB peut servir de point de départ à une nouvelle base. Créez les tables, définissez les types de champs, puis ajoutez les relations nécessaires. Par exemple, une agence peut relier des tables Clients, Projets, Contacts et Tâches.

Il est aussi possible de connecter NocoDB à une base SQL existante. Dans ce cas, commencez avec une copie ou un environnement de préproduction. Inspectez les clés primaires, les relations et les contraintes avant d’autoriser des modifications depuis l’interface.

Pour reprendre des données venant d’un tableur, utilisez les fonctions d’import CSV ou Excel disponibles dans l’interface. Nettoyez auparavant les intitulés de colonnes, les dates, les doublons et les valeurs ambiguës. Une colonne mélangeant nombres et texte donnera rarement un schéma satisfaisant sans préparation.

Une fois les données importées, créez plusieurs vues à partir de la même table :

• Une grille complète pour l’équipe opérationnelle
• Un kanban regroupé par statut
• Un formulaire pour les demandes entrantes
• Une vue filtrée pour un client ou un service

Les vues facilitent le travail, mais elles ne remplacent pas les permissions. Une colonne masquée visuellement peut rester présente dans la table ou accessible par une intégration autorisée.

Exploiter l’API REST et les webhooks

NocoDB expose une API REST liée aux tables et à leurs enregistrements. La documentation générée dans l’instance fournit les routes, les paramètres et des exemples adaptés au schéma réel.

Pour une intégration serveur à serveur, utilisez un token API dédié plutôt que les identifiants d’un utilisateur. Stockez-le dans une variable d’environnement ou un gestionnaire de secrets. Limitez ses droits et remplacez-le immédiatement en cas d’exposition.

Les webhooks permettent de prévenir un autre service après un événement, par exemple la création ou la modification d’un enregistrement. Ils peuvent déclencher une notification, une synchronisation ou une automatisation légère. Le service destinataire doit vérifier la requête, gérer les doublons et répondre rapidement. Les traitements longs doivent être placés dans une file ou exécutés en arrière-plan. Un outil comme n8n se connecte facilement à ces webhooks pour orchestrer des automatisations.

Collaboration, rôles et partage

NocoDB permet d’inviter plusieurs utilisateurs et d’attribuer des rôles selon leurs responsabilités. Appliquez le principe du moindre privilège : administration pour quelques responsables, modification pour les contributeurs et lecture pour les personnes qui consultent uniquement.

Les vues et formulaires partagés publiquement demandent une attention particulière. Une URL publique peut être transmise, indexée ou conservée dans un historique. Vérifiez les champs exposés, supprimez les informations internes et désactivez les partages devenus inutiles.

Pour transmettre des données sensibles à un partenaire, préférez un compte authentifié avec des droits limités à un simple lien public.

Publier NocoDB en HTTPS

Le sous-domaine, par exemple base.example.fr, doit pointer vers l’adresse IP du VPS. Un reverse proxy comme Caddy, Nginx Proxy Manager ou Traefik termine la connexion TLS et relaie les requêtes vers 127.0.0.1:8080.

Une configuration Caddy minimale ressemble à ceci :

base.example.fr {
    reverse_proxy 127.0.0.1:8080
}

Ouvrez uniquement les ports nécessaires, généralement 80 et 443 pour le proxy ainsi que le port SSH d’administration. Le port 8080 et PostgreSQL ne doivent pas être exposés publiquement.

Après activation, contrôlez la redirection HTTP vers HTTPS, le certificat, les connexions persistantes et le comportement de l’application derrière le proxy.

Sécurité, mises à jour et sauvegardes

Installez les mises à jour du système et de Docker, surveillez les journaux et activez une protection adaptée pour SSH avec le pare-feu. N’exécutez pas de mise à jour NocoDB importante sans sauvegarde préalable ni lecture des notes de version.

Pour mettre à jour les images après validation :

docker compose pull
docker compose up -d
docker compose ps

Sauvegardez PostgreSQL avec pg_dump :

mkdir -p backups
docker compose exec -T postgres pg_dump -U nocodb -d nocodb -Fc > backups/nocodb.dump

Le volume applicatif doit aussi être archivé, notamment pour les fichiers persistants :

docker compose stop nocodb
docker run --rm -v nocodb_app_data:/data:ro -v "$PWD/backups:/backup" alpine:3.20 sh -c 'tar -czf /backup/nocodb-data.tar.gz -C /data .'
docker compose start nocodb

Copiez ensuite les sauvegardes vers un stockage séparé du VPS, chiffrez-les si elles contiennent des données sensibles et testez régulièrement une restauration. Notre guide sur la stratégie de sauvegarde d’un serveur détaille cette approche. Le contrôle final doit couvrir le dump PostgreSQL, le volume nocodb_app_data, le fichier Compose, les secrets nécessaires et la configuration du reverse proxy.