
Par Thomas Cohen, fondateur de Maestro
Alternatives à Airtable : choisir sans perdre les liens entre vos données
Baserow, NocoDB ou une base Airtable mieux organisée : un exercice commun pour comparer les relations, les formules, les pièces jointes et le travail de reprise.
Une alternative à Airtable doit conserver le sens de votre travail : quelle demande appartient à quel client, qui en est responsable et quelle règle déclenche la suite. Retrouver les mêmes lignes dans une nouvelle grille ne suffit pas. Commencez par un petit dossier complet, puis faites-lui subir les mêmes changements dans chaque solution envisagée.
Suivons le cas fictif d'Élise, qui organise les demandes d'un atelier de réparation. Sa base contient des clients, des demandes et des responsables. Elle souhaite comparer Baserow et NocoDB à son installation actuelle. Ce guide fournit le jeu d'essai et les contrôles ; il s'appuie sur les documentations consultées le 2 octobre 2026. Il ne rapporte pas un test comparatif réalisé dans trois comptes.
Choisir ce que le changement doit résoudre
Élise trouve sa base difficile à entretenir. Mais cette phrase mélange trois problèmes : elle ne sait plus quelles vues sont utilisées, une automatisation avertit la mauvaise personne et certains collègues peuvent modifier une formule. Changer d'outil peut déplacer ces difficultés sans les régler. Elle commence donc par nommer un résultat observable : un responsable doit retrouver ses demandes ouvertes et recevoir une seule alerte lorsqu'une nouvelle demande lui est attribuée.
Écrivez votre propre raison de changer. Il peut s'agir d'une limite rencontrée, d'un besoin d'hébergement, d'une difficulté de partage ou d'un coût devenu inadapté. Ajoutez la fréquence du problème, les personnes concernées et un exemple récent. Une gêne esthétique pèse différemment d'une relation client rompue pendant une importation.
Conservez Airtable comme option de comparaison. Réparer une vue ou une règle est parfois plus raisonnable que reprendre toute une base. Le choix final doit opposer des parcours de travail, avec leur entretien, et non trois pages de tarifs. Fixez aussi une condition éliminatoire : par exemple, refuser toute solution dans laquelle les demandes peuvent être attribuées au mauvais client sans avertissement.
Préparer un jeu qui révèle les pertes de relations
Le jeu proposé comporte trois clients, deux responsables et cinq demandes. Les clients portent les références C01, C02 et C03 ; deux ont volontairement le même nom commercial, « Atelier Martin ». La référence distingue les entreprises même si leur nom affiché est identique. Un nom seul constitue une mauvaise clé pour reconstituer les liens.
Les demandes D01 et D02 appartiennent à C01, D03 et D04 à C02, D05 à C03. Nora suit D01, D03 et D05 ; Sami suit D02 et D04. Chaque demande contient une quantité et un montant unitaire. Le montant attendu est leur produit, avec une convention d'arrondi écrite. Ce calcul est un exercice fictif, pas une règle de facturation professionnelle.
Ajoutez une pièce jointe texte à D01, une demande clôturée et une demande encore sans responsable. Cette dernière remplace temporairement l'attribution de D05 pour tester le cas incomplet. Gardez une copie du jeu initial : elle permet de recommencer sans comparer des versions différentes. La ressource à télécharger contient les données à recopier et les résultats attendus pour chaque opération.
Faire l'inventaire au-delà des colonnes visibles
Pour chaque table, notez les champs saisis et ceux qui sont calculés ou récupérés ailleurs. L'adresse affichée dans une demande peut venir du client lié. Si vous exportez seulement sa valeur actuelle, la nouvelle application affichera peut-être la bonne adresse le premier jour, puis une adresse périmée dès que le client déménagera.
Distinguez aussi une vue d'une permission. Une vue « mes demandes » peut simplement masquer les autres lignes dans un écran. Le besoin d'Élise est plus précis : Nora doit-elle pouvoir retrouver les dossiers de Sami par une autre vue, un export ou un lien direct ? La réponse détermine les droits à vérifier dans le futur outil et dans l'offre choisie.
L'inventaire doit couvrir les éléments qui continuent d'agir sans être affichés : alertes, formulaires partagés, intégrations, règles de calcul et anciens liens transmis aux collègues. Pour une automatisation, décrivez le déclencheur, l'action et la personne qui constate son échec. « Envoyer une alerte lors de l'attribution » est encore incomplet si une simple correction du téléphone renvoie la même alerte.
- Données : tables, références, champs obligatoires, valeurs vides et pièces jointes.
- Logique : relations, formules, règles de validation et automatisations.
- Usage : vues, formulaires, droits, liens partagés et personnes responsables.
Vérifier ce que l'export Airtable emporte réellement
Airtable documente l'export des vues en CSV. Le CSV est un fichier de lignes et de colonnes. Une vue filtrée peut exclure des enregistrements : choisissez donc une vue contenant toutes les lignes nécessaires et consignez le nombre obtenu pour chaque table.
L'aide sur les relations Airtable explique les liens entre enregistrements. Ne supposez pas qu'une suite de noms dans un export recrée ces relations ailleurs. Gardez une référence stable pour chaque client, demande et responsable, puis une colonne indiquant les références liées. Vous pourrez contrôler les correspondances sans vous fier à l'ordre des lignes.
Traitez les pièces jointes séparément. Une adresse de téléchargement dans un fichier exporté n'est pas une copie du document. Conservez les fichiers eux-mêmes avec leur demande d'origine, leur nom et leur taille. Dans notre exercice, la pièce de D01 doit pouvoir être ouverte après fermeture de l'ancienne session. Si cette opération échoue, la récupération est incomplète, même si la cellule affiche un lien bleu.
Examiner Baserow avec le même dossier
Baserow documente un import de base Airtable et un champ de liaison entre tables. Ce sont deux points d'entrée utiles pour l'essai. Un import automatisé reste à contrôler : la disponibilité d'une fonction ne prouve pas la reprise exacte de vos formules, de vos droits ou de vos automatisations.
Sur une copie du dossier, commencez par retrouver C01 et ses deux demandes. Modifiez ensuite uniquement son nom. D01 et D02 doivent continuer à pointer vers ce même client ; D03 et D04 doivent rester rattachées à C02, malgré leur ancien nom identique. Ouvrez enfin le client depuis une demande pour vérifier qu'il s'agit bien d'une relation utilisable.
Reprenez la formule avec les règles de Baserow plutôt que de recopier aveuglément sa syntaxe Airtable. Comparez le résultat sur une quantité entière, une quantité décimale et une valeur vide. Si le vide signifie « montant inconnu », ne le transformez pas sans décision en zéro. Élise préfère voir une demande à compléter qu'un total apparemment définitif mais faux.
Notez chaque correction nécessaire et qui l'a faite. Une étape résolue par un intervenant technique doit apparaître comme telle dans la comparaison, même si elle n'a demandé que quelques minutes.
Examiner NocoDB sans confondre interface et exploitation
NocoDB propose un champ Link to Another Record pour créer des relations entre tables. Faites-lui passer les mêmes opérations : retrouver les demandes d'un client, renommer ce client, changer un responsable, puis vérifier les résultats calculés. La ressemblance avec un tableur ne dispense pas de comprendre les liens créés.
Si vous envisagez une installation gérée par votre organisation, ajoutez des questions d'exploitation. Qui applique les mises à jour ? Qui récupère une sauvegarde ? Qui sait rétablir l'accès si la personne qui a installé l'outil part ? Si vous choisissez une offre hébergée, examinez ce que le service prend en charge et ce qui reste à votre équipe.
N'attribuez pas un avantage automatique à une solution parce qu'elle peut être installée ailleurs. Cette possibilité peut répondre à une contrainte réelle, mais elle ajoute aussi des responsabilités. Pour Élise, une interface satisfaisante avec une exploitation sans responsable identifié n'est pas un choix prêt à être adopté.
Terminez l'essai par un export depuis NocoDB et demandez à une autre personne de retrouver D01, son client et son document. Cette lecture indépendante révèle les conventions qui n'existaient que dans la tête de la personne ayant fait l'import.
Comparer une journée de travail et une modification
Une fois les données présentes, simulez la journée d'Élise. Elle reçoit une nouvelle demande, choisit le bon Atelier Martin, attribue Nora et ouvre le document fourni. Nora retrouve la demande dans sa liste. Sami ne reçoit pas d'alerte inutile. Élise clôture le dossier et le retrouve ensuite dans l'historique.
Réalisez ensuite une modification volontaire : une demande peut désormais avoir un responsable principal et un remplaçant. Écrivez ce qui change dans les vues, les alertes et les droits. Une solution peut être agréable pour la saisie quotidienne mais difficile à faire évoluer. Cette différence mérite davantage d'attention qu'un nombre de fonctionnalités annoncé.
Consignez quatre observations pour chaque outil : résultat obtenu, geste difficile, aide requise et point non vérifié. « Import réussi » n'est pas une observation suffisante. « Les cinq demandes sont présentes, les liens client sont contrôlés, l'alerte reste à reconstruire » permet de prendre une décision. Ne remplacez pas une case inconnue par une note moyenne.
Enfin, testez une erreur réversible sur la copie : retirez l'attribution d'une demande, puis rétablissez-la. Examinez la possibilité de comprendre qui a changé quoi selon les fonctions disponibles. Vous mesurez ici la capacité à corriger le travail, pas seulement à le saisir.
Organiser le passage sans mélanger deux vérités
Si une option convient, préparez une dernière copie et une période de bascule définie. Tant que l'ancienne et la nouvelle base acceptent des modifications indépendantes, une demande peut être clôturée d'un côté et rester ouverte de l'autre. Choisissez laquelle fait foi à chaque étape, et comment les changements intervenus pendant l'essai seront repris.
Pour Élise, le scénario à adapter consiste à arrêter temporairement la saisie, exporter les changements restants, vérifier les totaux et les liens, puis ouvrir le nouvel outil. L'ancienne base reste consultable selon les droits décidés. Le retour doit préciser comment récupérer les demandes créées dans le nouvel outil ; rouvrir simplement Airtable ferait perdre ces ajouts.
Les personnes concernées ont besoin d'une instruction courte : où saisir à partir de quelle date, comment signaler une erreur et qui décide d'un retour. Le guide sur la migration des données détaille la logique de copie et de contrôle ; ici, conservez une attention particulière aux relations, formules et documents qui donnaient sa valeur à la base Airtable.
Décider avec les preuves recueillies
Retenez une alternative si elle répond au problème de départ et si les opérations critiques réussissent dans votre contexte. Gardez Airtable si une correction ciblée suffit ou si la reprise présente encore des inconnues importantes. Reportez la décision si personne ne peut expliquer où vivent les documents, comment les liens sont conservés ou qui entretient les règles.
La comparaison financière vient alors sur un périmètre identique : personnes qui construisent, personnes qui utilisent, données, documents, automatisations, hébergement éventuel et aide nécessaire. Relevez les conditions actuelles de chaque offre. Un prix affiché ne constitue pas à lui seul le coût de remplacement d'une base utilisée chaque jour.
Notre intérêt commercial est explicite : nous éditons Maestro. Il n'est pas nécessaire d'adopter Maestro pour appliquer ce guide. Le bon résultat est une décision étayée et une base reprenable. Téléchargez la fiche d'essai Airtable, Baserow et NocoDB, remplissez les colonnes d'observation après vos essais et gardez les écarts non résolus visibles jusqu'à la décision.
Comparer les alternatives à Lovable : prix, code et travail en local