Les six plafonds du no-code — et ce qu'on construit au-dessus

La thèse est simple, et réfutable : chaque limite documentée d'un outil no-code désigne la couche d'architecture qui vient après lui, et la lire avant de construire coûte moins cher que la découvrir en production. Volumétrie, débit API, logique, droits, observabilité, réversibilité : les six plafonds qui suivent sont publiés par les éditeurs eux-mêmes, sur des pages datées. Aucun n'est un secret.

C'est une pratique d'ingénierie ordinaire : un fournisseur cloud publie ses quotas, une base de données ses limites de connexions. Les plateformes no-code font pareil. La différence : leurs utilisateurs, souvent des équipes métier, lisent rarement la page des limites avant de s'engager.

Ces limites no-code ne disent pas « n'utilisez pas l'outil ». Elles disent où l'outil s'arrête par design — et où commence la couche suivante. Sur la trentaine de projets que nous avons livrés, les points de départ récurrents — tableur utilisé comme base de données, dashboards en pièces jointes, six systèmes qui ne se parlent jamais — étaient tous écrits quelque part (données internes Ownward, 2026).

La volumétrie est le plafond le plus lisible. Airtable publie ses paliers : 1 000 enregistrements par base en Free, 50 000 en Team, 125 000 en Business ; au-delà, Enterprise Scale se négocie. Notion borne ses payloads API : 1 000 blocs et 500 Ko par requête, 2 000 caractères par rich text.

Le débit est moins visible mais plus tranchant, parce qu'il s'applique souvent quel que soit le plan.

Le signal observable : des erreurs 429, des synchronisations qui s'étirent sur des heures, des scénarios coupés en plein traitement. Le pattern n'est pas de tout réécrire : c'est de sortir les flux volumineux vers un moteur dédié. Nous opérons un moteur de synchronisation piloté par mapping — Python orchestré sur Trigger.dev, configuration stockée dans Airtable — qui relie 6 CRM/ERP à un référentiel unique ; une nouvelle source, c'est un nouveau mapping, pas du nouveau code (données internes Ownward, 2026). Les critères de bascule sont détaillés dans quand industrialiser une automatisation.

Chaque environnement d'exécution visuel borne ce qu'un traitement peut faire :

• Zapier fixe 100 étapes maximum par Zap, chemins compris ;
• l'action « Run a script » des automatisations Airtable s'exécute en 30 secondes maximum, avec 512 Mo de mémoire, 50 requêtes fetch et une sortie plafonnée à 6 Mo ;
• côté Softr, une table Airtable se connecte à un seul bloc à la fois.

Ces bornes protègent la plateforme et l'ensemble de ses clients ; elles dessinent aussi le périmètre naturel de l'outil. Le signal : des workflows découpés artificiellement pour tenir sous la limite, des scripts qui échouent par timeout sur les gros lots.

Le pattern n'oblige pas à quitter l'outil — c'est ce que ce plafond illustre le mieux. En un an, nous avons mis en production 17 extensions Airtable custom (React et Tailwind, directement dans la base), dont un CRM complet : téléphonie Aircall, emails templatés, SMS et WhatsApp, cartes interactives (données internes Ownward, 2026). L'équipe reste dans son outil ; la logique complexe vit dans du code déployé au-dessus. C'est le continuum no-code pro-code au sens propre : pas une frontière à franchir une fois pour toutes, mais des couches qui coexistent.

Le modèle de permissions d'un outil collaboratif est calibré pour la collaboration, pas pour la confidentialité fine. La documentation d'Airtable le formule clairement à propos des permissions par champ et par table : « these permissions don't control who can see data, only who can edit it ». Restreindre l'édition et restreindre la visibilité sont deux problèmes différents — et le second appartient à la couche du dessus.

Le même dessin de frontière se lit chez Notion : l'export PDF d'un espace de travail entier y est réservé aux plans Business et Enterprise — et l'éditeur en annonce le retrait au 31 août 2026. Chez tous les éditeurs, la gouvernance fine est une capacité graduée par plan, pas un réglage par défaut.

Le signal observable :

• des bases dupliquées « pour que chacun ne voie que sa partie » ;
• des exports filtrés à la main ;
• des dashboards qui circulent en pièces jointes email.

Deux patterns, vécus. Pour edorma, un dashboard hebdomadaire maintenu à la main chaque lundi est devenu un SaaS multi-tenant isolé par le row-level security de Postgres : la visibilité est garantie par la base, pas par la discipline des utilisateurs. Pour un portail CFO, des dashboards envoyés par email sont devenus un portail Next.js/Supabase avec SSO Google et visibilité par email ou par domaine (données internes Ownward, 2026). Quand la question devient « qui voit quoi, et comment le prouver ? », la réponse est une couche d'authentification et une base qui applique les règles.

Les deux derniers plafonds sont les moins connus, parce qu'ils ne bloquent rien au quotidien. L'observabilité d'abord :

• Zapier conserve l'historique des Zaps 29 à 69 jours par défaut sur tous les plans ;
• Make garde ses logs 7 jours en Free et 30 jours sur les plans payants affichés ;
• chez Airtable, les journaux d'audit sont réservés au plan Enterprise Scale, avec 180 jours de rétention. Le signal arrive toujours trop tard : un incident détecté après la fenêtre de rétention n'a plus de trace.

La réversibilité ensuite. L'export CSV d'Airtable se fait vue par vue : seules les valeurs visibles sortent ; commentaires, descriptions de champs et données d'extensions restent dans l'outil, et les URLs de pièces jointes exportées expirent en quelques heures. Notion exporte l'intégralité d'un espace sur tous les plans, mais l'opération peut prendre jusqu'à 30 heures et le lien expire après 7 jours.

Le pattern commun : un référentiel de données qui vit hors de l'outil d'usage, synchronisé en continu. Les outils restent des interfaces, le référentiel fait foi — c'est la parade structurelle aux cinq formes du vendor lock-in.

Ce que ça coûte de ne rien faire — Un incident découvert au-delà de la fenêtre de rétention se reconstruit sans journaux : 29 à 69 jours d'historique par défaut chez Zapier, 7 à 30 jours de logs chez Make (constaté le 12 août 2026). Une base Airtable Free qui atteint son quota de 1 000 appels API par mois met en attente tous les outils connectés jusqu'au 1er du mois suivant. Chaque plafond ignoré se paie au moment où l'on peut le moins choisir.

Un plafond no-code se gère comme toute contrainte d'architecture : un signal, un pattern.

Ces chiffres sont des pages vivantes : vérifiés le 12 août 2026, ils évoluent avec les éditeurs — toute décision d'architecture mérite une relecture des pages sources le jour J. Les plans Enterprise se négocient, et leurs plafonds réels ne sont pas publiés. Surtout, franchir un plafond par du code a un coût : construction, maintenance, compétences à réunir. Pour beaucoup d'équipes, un changement de plan repousse le mur de plusieurs années, et la couche supérieure serait prématurée. Enfin, six plafonds forment une grille de lecture, pas une taxonomie exhaustive : la conformité et le coût par siège en sont d'autres, traités séparément.