No-code, Airtable, Notion : jusqu'où aller avant de développer ?

Entre le tableur et l'application développée existe un terrain devenu très solide : Airtable, Notion, Baserow, et les plateformes d'automatisation qui les accompagnent. Pour beaucoup d'entreprises, c'est la bonne réponse — et la reconnaître évite un développement inutile.

Encore faut-il connaître la frontière.

Ce que le no-code fait très bien

• Structurer des données jusqu'ici éparpillées. Des enregistrements typés, des relations entre tables, des champs contraints. C'est déjà un saut énorme par rapport à un tableur.
• Donner à chacun sa vue. Le commercial voit ses affaires, le responsable voit le pipeline — sans dupliquer les données.
• Conserver un historique. Qui a modifié quoi et quand, nativement.
• Automatiser les tâches simples. Une notification quand un statut change, un récapitulatif hebdomadaire, une ligne créée depuis un formulaire.
• Évoluer en quelques minutes. Ajouter un champ ne demande ni développeur ni mise en production.

Si votre besoin tient dans cette liste, n'allez pas plus loin : le no-code sera plus rapide et moins cher que tout développement.

Où il atteint ses limites

Les règles de calcul complexes

Un calcul de commission à paliers, avec exceptions par contrat, prorata et régularisations rétroactives, se code mal dans des formules de champ. On finit par empiler des champs intermédiaires que plus personne ne comprend — on a recréé le tableau croisé illisible, avec une facture mensuelle en plus.

Les droits fins

« Ce commercial voit ses clients mais pas leurs marges, sauf ceux dont il est responsable de secteur. » Ce niveau de granularité est rarement atteignable sans contorsions, ou nécessite les offres les plus chères.

Le volume

Les plateformes no-code imposent des plafonds d'enregistrements par base, et les performances se dégradent bien avant. Au-delà de quelques dizaines de milliers de lignes actives, la question se pose sérieusement.

Le coût par utilisateur

C'est le point de bascule le plus fréquent, et le plus facile à calculer. À vingt ou trente euros par personne et par mois, une équipe de quarante personnes représente un budget annuel qui finance largement un développement — et l'abonnement, lui, ne s'arrête jamais.

L'expérience utilisateur

Un outil no-code ressemble à une base de données. Pour une équipe administrative, parfait. Pour un technicien sur le terrain avec des gants et une connexion instable, ou pour un écran destiné à un client, cela ne convient pas.

La dépendance

Vos process vivent chez un éditeur qui peut changer ses tarifs, ses limites ou ses conditions. Vérifiez dès le départ que vos données sont exportables dans un format exploitable — le sujet rejoint la question de la réversibilité de vos données.

Les cinq critères de bascule

Passez au développement si vous cochez trois de ces cinq cases :

• l'abonnement annuel dépasse le coût d'une adaptation sur base existante ;
• vos règles métier ne tiennent plus dans des formules de champ ;
• vous avez besoin de droits plus fins que « lecture / écriture » ;
• des utilisateurs externes — clients, fournisseurs — doivent accéder à l'outil ;
• vous approchez des plafonds techniques de la plateforme.

La bonne stratégie : le no-code comme prototype

Le meilleur usage du no-code, quand on sait qu'on développera un jour, est de s'en servir comme maquette grandeur nature. Pendant six mois, vos équipes précisent leurs besoins en les vivant, et non en les imaginant.

Le jour où vous développez, vous ne partez pas d'un document théorique : vous partez d'un outil utilisé, dont les champs, les statuts et les règles ont été validés par l'usage. C'est la meilleure spécification possible — bien meilleure qu'un cahier des charges.