Airtable, Notion ou application métier : comment choisir ?

Commencez par conserver Airtable ou Notion tant que le travail réel, les droits, les données, l’exploitation et la sortie restent prouvés. Si le produit convient mais dépend d’une personne, d’un compte ou d’une automatisation non surveillée, renforcez l’organisation. Une contrainte isolable peut partir dans un module hybride. Préparez une application métier seulement lorsque les tests confirment plusieurs limites propres à la plateforme, ou lorsque la contrainte centrale ne peut pas être isolée proprement.

Reconstruire dès que la base devient désordonnée ne résout pas le problème : le désordre suit la migration. À l’autre extrême, « l’écran s’ouvre encore » ne prouve pas que le processus est maîtrisé. Un outil peut sembler fonctionner tout en dépendant du compte d’un ancien salarié, en masquant des échecs d’automatisation ou en rendant sa sortie impossible à relire.

La décision n’est donc pas Airtable contre Notion contre code. Elle porte sur la charge organisationnelle : tout ce que l’équipe doit comprendre, contrôler, soutenir et reprendre pour que le service reste utile. Le sur-mesure peut supprimer certaines contorsions du produit standard. En contrepartie, votre organisation ou son prestataire doit prendre en charge le développement, la sécurité, la supervision, le support et les évolutions.

Une fois l’urgence écartée, comparez ce que chaque système organise naturellement. C’est le moyen le plus simple d’éviter de forcer un outil à jouer un rôle qui n’est pas le sien.

Airtable organise naturellement des enregistrements, des champs, des vues, des formulaires, des interfaces et des automatisations. Notion organise d’abord des pages, des blocs, des connaissances et leur collaboration, puis y ajoute des bases. Une application métier part du parcours et des règles que vous décidez de construire. Cette différence de centre de gravité est plus utile qu’une liste de fonctionnalités cochées.

Prenez une demande de recrutement. Airtable peut bien convenir si chaque candidature suit des statuts, responsables et vues claires. Notion peut être préférable si le besoin central est de réunir briefs, comptes rendus, modèles d’entretien et décisions argumentées. Une application dédiée devient envisageable si les droits fins, les intégrations de ressources humaines, les contraintes de conservation, l’expérience des candidats et les règles de décision ne tiennent plus dans une combinaison maîtrisable.

Forcer l’outil à devenir un autre système brouille les responsabilités. Une base Airtable couverte de champs techniques, de scripts et de synchronisations peut devenir un logiciel sans les disciplines d’un logiciel. Un espace Notion rempli de statuts et de formules peut devenir un système transactionnel sans contrôle d’intégrité suffisant. À l’inverse, une application dédiée peut répliquer des fonctions standard, à un coût plus élevé et avec davantage de maintenance.

Comparez un coût total, pas une licence à un devis

Un tarif mensuel public et un devis de construction ne couvrent pas le même périmètre. Choisissez un horizon identique et calculez, pour chaque option, les abonnements et services, la mise en place, l’administration, l’exploitation, les incidents, les évolutions et la sortie. Chaque montant doit avoir une quantité, une unité, une période et une source. Une ligne inconnue reste « à vérifier » ; elle ne vaut jamais zéro.

Ajoutez séparément le coût d’un arrêt et le temps métier perdu : ils dépendent de votre processus, pas du produit. Comparez ensuite des scénarios de volume et de charge documentés. Cette grille peut défendre le maintien d’un logiciel fourni comme un service en ligne (SaaS), mais aussi invalider un sur-mesure dont l’exploitation n’a pas été financée.

Pour renseigner ces coûts sans les deviner, partez maintenant d’une journée réelle et gardez un cas difficile dans le test.

Choisissez une période représentative : clôture mensuelle, arrivée d’un collaborateur, campagne commerciale, traitement d’un litige ou pic de commandes. Listez les personnes présentes, les objets manipulés, les écritures humaines et automatiques, les systèmes appelés et le coût d’un arrêt. Gardez au moins un dossier contenant une exception ; le scénario nominal favorise artificiellement toutes les solutions.

Rejouez ensuite les douze dimensions ci-dessous. « Contrôlé » exige une preuve datée : capture, export relu, journal d’erreur, compte de test, procédure jouée ou résultat signé par le métier.

« Échec » signifie seulement que le résultat attendu n’a pas été obtenu. Cherchez ensuite la cause : organisation et règles de fonctionnement à corriger — la gouvernance — ou limite de plateforme reproduite ? Tant que vous ne pouvez pas répondre, la décision reste suspendue. Un défaut de droits ou d’export peut appartenir à l’une comme à l’autre. Le diagnostic ne calcule pas une moyenne : un échec de droit d’accès ne peut pas être compensé par onze réponses confortables.

DOSSIER AIRTABLE / NOTION / APPLICATION MÉTIER
Recherche produit revalidée le 5 août 2026

Orientation : Décision suspendue
Conclusion : La prochaine décision est de produire les preuves manquantes, pas de choisir une marque.

CONTEXTE
Outil actuel : à vérifier
Forme du processus : à vérifier
Criticité : à vérifier
Frontière : à vérifier
Utilisateurs actifs : à vérifier
Objets actifs : à vérifier
Écritures mensuelles : à vérifier

DOUZE CONTRÔLES
1. Criticité et arrêt : À vérifier — aucune preuve datée
2. Rôles et droits : À vérifier — aucune preuve datée
3. Données et intégrité : À vérifier — aucune preuve datée
4. Écritures concurrentes : À vérifier — aucune preuve datée
5. Volume et archive : À vérifier — aucune preuve datée
6. Automatisations : À vérifier — aucune preuve datée
7. Intégrations et API : À vérifier — aucune preuve datée
8. Mobile et mode dégradé : À vérifier — aucune preuve datée
9. Audit et conformité : À vérifier — aucune preuve datée
10. Propriété et relève : À vérifier — aucune preuve datée
11. Export et sortie : À vérifier — aucune preuve datée
12. Support et restauration : À vérifier — aucune preuve datée

PREUVES MANQUANTES OU ERREURS
- outil actuel ou absence d’outil à préciser
- forme dominante du processus à observer
- criticité à qualifier avec un arrêt simulé
- Le nombre d’utilisateurs actifs à relever sur une période représentative
- Le nombre d’objets actifs à relever sur une période représentative
- Le nombre d’écritures mensuelles à relever sur une période représentative
- 1. Criticité et arrêt
- 2. Rôles et droits
- 3. Données et intégrité
- 4. Écritures concurrentes
- 5. Volume et archive
- 6. Automatisations
- 7. Intégrations et API
- 8. Mobile et mode dégradé
- 9. Audit et conformité
- 10. Propriété et relève
- 11. Export et sortie
- 12. Support et restauration

PROCHAINES ACTIONS
- Choisir une journée ou une semaine représentative.
- Rejouer les douze contrôles avec un responsable nommé.
- Laisser toute inconnue visible jusqu’à sa vérification.

GRILLE DE SORTIE
- Objets et périmètre : à renseigner
- Propriétaires et relève : à renseigner
- Données et formats d’export : à renseigner
- Pièces jointes et liens : à renseigner
- Identités, rôles et droits : à renseigner
- Automatisations, scripts et alertes : à renseigner
- Intégrations, secrets et quotas : à renseigner
- Règles métier et exceptions : à renseigner
- Historique, traces et archives : à renseigner
- Recette utilisateur et critères : à renseigner
- Coexistence et bascule : à renseigner
- Retour arrière et extinction : à renseigner

Examinez d’abord séparément les droits et les données. Vous verrez alors si l’écart vient de l’outil ou de son organisation avant de choisir une architecture.

Commencez par un tableau simple : rôle, objet, action, condition et preuve obtenue. Pour chaque profil — lecteur, opérateur, manager, administrateur, invité, intégration — testez lecture, création, modification, suppression, export et partage. Utilisez des comptes représentatifs. Un propriétaire de l’espace de travail (workspace) voit souvent davantage que l’utilisateur dont il prétend valider le parcours.

Dans Airtable, les permissions de champ et de table peuvent limiter qui modifie, crée ou supprime sur les plans Team, Business et Enterprise Scale. La documentation précise toutefois qu’elles ne changent pas à elles seules la visibilité des données et ne verrouillent pas la configuration du champ. Une donnée à ne pas montrer exige donc un test de lecture couvrant base, interface, vue partagée, synchronisation, API, copie et export — pas seulement un champ que l’on ne peut pas éditer.

Dans Notion, le droit réel dépend de plusieurs niveaux : la page, l’espace d’équipe, l’espace de travail, le statut d’invité et les règles appliquées aux pages d’une base. L’accès le plus large peut rendre une restriction locale inopérante. Les règles d’accès au niveau des pages d’une base sont disponibles uniquement sur les plans Business et Enterprise.

Elles peuvent, par exemple, s’appuyer sur une propriété de personne ou de créateur. Testez-les lorsqu’un utilisateur change d’équipe, lorsqu’une page est déplacée, lorsqu’un modèle crée un contenu ou lorsqu’une connexion agit avec ses propres autorisations.

Testez aussi les écritures simultanées. Deux personnes peuvent modifier la même fiche ; une automatisation peut écrire entre leur lecture et leur validation ; une synchronisation peut arriver en retard. Notez la règle attendue : rejet, fusion, dernière écriture, version ou intervention humaine. Si personne ne peut expliquer ce qui se passe, ne cochez pas « contrôlé » même si vous n’avez encore observé aucune perte.

Distinguez aussi volume total et charge active. Comptez les objets utilisés, les archives, les pièces jointes, les écritures mensuelles, les lectures API et les pics. Airtable publie des limites de lignes et de stockage par plan ; ces nombres ne prédisent pas à eux seuls l’ergonomie ni la fiabilité. Notion et une application dédiée ont eux aussi des limites pratiques. Seul un essai représentatif mesure votre parcours.

Testez aussi le réseau réellement disponible. Airtable indique qu’une connexion internet est nécessaire et ne prend pas en charge un fonctionnement hors ligne.

Notion permet de télécharger des pages dans ses applications de bureau et mobiles, mais pas dans le navigateur. Les sous-pages ne suivent pas automatiquement ; pour une base, seules les 50 premières lignes de la première vue sont téléchargées par défaut. Certaines actions restent indisponibles et des modifications non textuelles concurrentes peuvent demander une résolution. Le mot « hors-ligne » ne remplace donc pas un essai sur le terrain.

Après les accès et les données, provoquez un échec d’automatisation. Sans journal ni alerte, il peut durer avant que quelqu’un ne s’en aperçoive.

Pour chaque automatisation, relevez ce qui la déclenche et ce qu’elle exécute. Notez aussi le compte et la clé d’accès utilisés, les limites de volume et de délai, l’endroit où les erreurs sont enregistrées, l’alerte prévue, la procédure de reprise et son responsable. Ajoutez les flux natifs, scripts, notifications automatiques entre services (webhooks), connecteurs, outils d’intégration et tâches manuelles qui prennent le relais.

Disposer d’une API ne suffit pas. Le point critique est de détecter un échec et de savoir le rejouer sans créer de doublon.

Au 5 août 2026, Airtable documente cinq requêtes par seconde et par base, ainsi que cinquante requêtes par seconde pour tout le trafic utilisant les jetons d’accès personnels d’un même utilisateur ou compte de service. Les plans Free et Team ont aussi des quotas mensuels, distincts de ces limites de débit ; Business et Enterprise Scale restent soumis au débit même sans plafond mensuel annoncé. Après dépassement du débit, Airtable indique qu’une réponse 429 impose d’attendre trente secondes avant qu’une nouvelle requête puisse réussir.

Pour les automatisations natives, un déclenchement compte comme exécution même lorsque les actions échouent. Dimensionnez sur les déclenchements et les reprises, pas seulement sur les succès.

L’API Notion annonce une moyenne de trois requêtes par seconde et par connexion. Une seconde limite s’applique à l’espace de travail : elle est partagée entre toutes ses connexions et ajustée à son plan, sans plafond chiffré publié sur la page consultée.

Après une réponse 429 ou 529, les connexions doivent respecter le délai indiqué par le service dans l’instruction Retry-After et borner leurs tentatives. Elles doivent aussi allonger progressivement cette attente et lui ajouter un léger décalage pour éviter que toutes les reprises aient lieu simultanément.

Les erreurs 5xx ne doivent pas provoquer le rejeu aveugle d’une écriture sans protection contre les doublons. Une charge utile est en outre limitée à 1 000 éléments de bloc et 500 Ko au total.

Les automatisations de bases Notion ont leurs propres règles : elles sont liées aux plans payants, ne se déclenchent pas mutuellement et peuvent ignorer des pages auxquelles l’automatisation n’a pas accès.

Le propriétaire d’une automatisation doit pouvoir répondre à quatre questions sans enquête improvisée : qu’est-ce qui n’a pas été traité, depuis quand, avec quel impact et comment le rejouer ? Si la réponse exige d’ouvrir plusieurs comptes personnels ou de demander au créateur absent, le défaut est d’abord organisationnel. Corrigez comptes techniques, alertes, journal et relève avant d’attribuer le problème à la plateforme.

Quand ce mode de reprise est maîtrisé, vérifiez encore que vous savez récupérer les données, restaurer le service et faire appliquer les bons contrats.

Une sortie réussie ne se résume pas à récupérer des lignes. Elle exige les objets, identifiants, relations, pièces jointes, règles, commentaires utiles, historiques requis, automatisations, intégrations, secrets, rôles, procédures et critères d’acceptation. Construisez cet inventaire pendant que l’outil fonctionne : en cas de crise ou de fin de contrat, vous n’aurez ni le temps ni les mêmes accès.

Dans Airtable, l’export en fichier tabulaire de données brutes (CSV) se fait table par table. Les pièces jointes se récupèrent séparément et plusieurs éléments — commentaires, extensions, descriptions de champs ou guide de base — ne sont pas compris dans un simple CSV. Les copies instantanées (snapshots) couvrent davantage la base, mais leur restauration crée une nouvelle base avec un nouvel identifiant d’application, et la base restaurée n’emporte pas son historique de révision.

Au 5 août 2026, la vue d’ensemble des plans et la page détaillée des copies instantanées divergent sur la durée Business : l’une indique un an, l’autre deux. Inscrivez « à vérifier sur notre espace de travail et notre contrat » au lieu de choisir la valeur favorable.

Notion permet d’exporter en HTML, PDF, Markdown et CSV selon le contenu et les droits. Une relation de base peut devenir une URL textuelle dans l’export et ne pas se recréer automatiquement à la réimportation. La restauration a aussi ses limites : restaurer une base ne restaure pas automatiquement le contenu de toutes les pages qu’elle contient. Testez donc l’import vers un environnement distinct et faites valider le résultat par un utilisateur métier.

Résidence des données : vérifier le périmètre, pas le drapeau

Airtable et Notion documentent des options de résidence pour certains plans Enterprise. Leur périmètre n’est pas « toutes les données et tous les traitements en Europe ». Authentification, compte, usage, support, métadonnées ou sous-traitants peuvent suivre d’autres circuits selon le service. Demandez la région, les catégories couvertes, les exclusions, les transferts, la chaîne de sous-traitance et la procédure de sortie applicables à votre contrat.

Pour des données personnelles, l’article 28 du règlement général sur la protection des données (RGPD) exige notamment un contrat écrit, des garanties suffisantes, des instructions documentées, un encadrement des sous-traitants ultérieurs, une aide au responsable de traitement et le retour ou la suppression des données en fin de prestation. La CNIL rappelle aussi que le client garde un rôle actif : analyse de risque, contrôle des accès, sauvegardes, localisation, continuité et réversibilité ne sont pas délégués par le seul achat d’un SaaS.

Un addendum contractuel de traitement des données (Data Processing Addendum, ou DPA) public n’est pas encore votre preuve contractuelle

Ouvrez la version réellement applicable du contrat et de son addendum de traitement. Le DPA public d’Airtable, mis à jour le 5 décembre 2025, précise qu’il ne devient opposable qu’après exécution valable par les parties.

Notion publie aussi un addendum et une liste de sous-traitants ; vérifiez la version incorporée à votre accord, les services activés et les données confiées. Archivez la preuve d’acceptation, les rôles, instructions, transferts, sous-traitants ultérieurs, préavis, mesures de sécurité, assistance, audit, retour ou suppression et sort des sauvegardes. Une page publique prouve des conditions proposées, pas celles que votre organisation a effectivement acceptées.

Séparez aussi sauvegarde fournisseur et capacité de reprise métier. Une copie interne chez l’éditeur protège son service ; elle ne prouve pas que vous saurez restaurer le bon état, dans le bon délai, avec les bonnes identités et les intégrations compatibles. Exportez, isolez une copie, contrôlez son intégrité et rejouez une restauration à une fréquence proportionnée au coût de perte.

Ces vérifications peuvent conduire au maintien comme à la sortie. Les cinq situations suivantes montrent pourquoi des symptômes proches ne suffisent pas à annoncer la même décision.

Les cinq scénarios ci-dessous sont entièrement fictifs et ne décrivent aucun client de Hagnéré Code. Leurs volumes et faits servent uniquement à montrer la méthode ; aucun gain, délai ou résultat commercial n’en est déduit.

Vous pouvez défendre une architecture hybride si sa frontière se nomme sans ambiguïté. « Notion garde la connaissance et l’application gère les commandes » est testable. « Les deux systèmes contiennent un peu tout et se synchronisent dans les deux sens » ne l’est pas. Pour chaque objet, écrivez qui crée, qui modifie, qui fait foi — autrement dit, quel système porte la donnée de référence —, qui corrige et qui répond lors d’un échec.

Construisez ensuite la grille de sortie en douze lignes : objets, propriétaires, données, pièces jointes, droits, automatisations, intégrations, règles, historique, tests d’acceptation par les utilisateurs — la « recette » —, coexistence et retour arrière. Chaque ligne doit contenir un responsable, un format ou un mécanisme, une preuve et une date. Vous pouvez continuer à explorer avec une case vide. Si cette inconnue peut changer la décision, ne rendez pas encore la bascule irréversible.

Répétez la migration avant de lui faire confiance

Un script exécuté une fois sur une copie n’est pas une migration maîtrisée. Écrivez la migration pour que les mêmes données d’entrée produisent le même résultat à chaque essai. Gardez aussi la trace des rejets et la correspondance des identifiants, puis comparez la source et la cible. Répétez sur une copie instantanée plus récente. Mesurez durée, indisponibilité et charge humaine. Une bascule n’est prête que si l’équipe sait aussi l’arrêter et revenir au point de départ sans improviser. La méthode complète, avec ses fenêtres de bascule et son plan de retour arrière, est détaillée dans le guide sur la migration sans interruption de service.

Les tests d’acceptation par les utilisateurs — souvent appelés « recette » — doivent couvrir des tâches, pas seulement des écrans. Demandez à des profils représentatifs de créer, corriger, rechercher, partager, exporter, travailler en réseau dégradé et reprendre après erreur. Incluez l’exception rare qui a motivé le projet. Une nouvelle interface agréable ne compense pas une règle métier perdue ou un historique devenu inutilisable. Pour construire ces scénarios et leurs critères d’acceptation, appuyez-vous sur le plan de recette d’une application métier.

1. Choisissez un dossier difficile. Prenez une exception réelle, pas une démonstration propre créée pour la réunion.
2. Réunissez trois points de vue. Le métier exécute, la personne qui administre explique, et une relève tente de reprendre sans aide.
3. Mesurez la charge. Relevez utilisateurs actifs, objets actifs, écritures humaines et automatiques, pièces jointes, pics et coût d’arrêt.
4. Rejouez les douze contrôles. Conservez les preuves, les échecs et les inconnues au même endroit.
5. Provoquez une erreur. Coupez un droit, dépassez une limite dans un environnement sûr ou simulez un service tiers indisponible ; observez alerte et reprise.
6. Exportez puis relisez. Vérifiez relations, fichiers, règles, historiques et identités dans un espace distinct.
7. Consignez une seule issue. STOP, conserver, renforcer, hybride ou sortir progressivement, avec la prochaine preuve et son responsable.

Selon ce que votre inventaire révèle, la suite du parcours n’est pas la même. Si le doute porte encore sur l’opportunité même d’un outil dédié, reprenez le diagnostic en trois situations avant toute comparaison. Si la contrainte vient de l’écosystème Microsoft de votre entreprise, la comparaison utile est celle entre Power Apps et une application sur mesure; si elle vient d’une base Access héritée, lisez plutôt comment remplacer Microsoft Access par une application web.

Trois vérifications conditionnent la suite. Le calcul du retour sur investissement dit si l’écart de coût total justifie une reconstruction. La gestion des droits d’accès met à l’épreuve ce que votre base partagée autorise réellement. Les contrôles de sécurité d’une application métier précisent ce qu’un plan gratuit ou intermédiaire ne couvre pas.

Si vous souhaitez un regard extérieur, transmettez le dossier sans donnée personnelle ni secret via la page démarrer un projet. Le premier échange doit pouvoir conclure que l’outil actuel reste préférable. Demandez une proposition de développement seulement lorsque la limite, la valeur attendue, les responsabilités et la sortie sont suffisamment précises pour être contestées.