No-code ou développement sur mesure

Le no-code suffit pour un outil interne simple, utilisé par quelques personnes, dont les règles ressemblent à celles d'un tableur amélioré : suivi de demandes, petit annuaire, formulaire avec circuit de validation. Le développement sur mesure devient préférable quand l'outil porte des règles complexes, doit tenir avec beaucoup d'utilisateurs, s'ouvre à vos clients, ou quand vous voulez pouvoir l'emporter ailleurs un jour.

Le no-code désigne des plateformes où l'on construit une application en assemblant des blocs (écrans, tables, automatisations) dans une interface visuelle, sans écrire de code. Le low-code est une variante qui permet d'ajouter du code là où les blocs ne suffisent pas. Dans les deux cas, l'application vit en général sur la plateforme de l'éditeur.

Ce que le no-code fait très bien

• Aller vite. Un premier outil utilisable peut exister en quelques jours, ce qui permet de tester une idée avant d'y consacrer un budget de développement.
• Laisser la main au métier. Une personne à l'aise avec les tableurs peut ajouter un champ ou une vue sans attendre un prestataire.
• Coûter peu au départ. Les offres d'entrée sont gratuites ou facturées quelques dizaines de dollars par mois.
• Se passer de serveur. L'éditeur s'occupe de l'hébergement, des sauvegardes et des mises à jour de la plateforme.

Pour une PME qui sort d'un fichier Excel partagé, une base en ligne sans code est souvent le bon premier pas. Le guide pour remplacer Excel par un logiciel détaille cette option.

Le no-code sert aussi à relier des outils existants : envoyer une alerte quand un formulaire est rempli, créer une ligne dans un tableau quand une commande arrive, prévenir un responsable quand un stock baisse. Pour ces petites automatisations, un développement serait disproportionné.

Ce que coûtent les plateformes no-code

Les plateformes facturent par utilisateur, par volume d'usage, ou les deux. Voici ce qu'affichent deux plateformes connues : Bubble, qui sert à construire des applications web complètes, et Airtable, une base de données en ligne.

Sources : Bubble, page tarifs et Airtable, description des offres, consultés le 22 octobre 2026.

Deux remarques pour lire ce tableau. Les unités de charge de Bubble mesurent le travail effectué par le serveur de l'application : plus l'outil est utilisé, plus il en consomme, et au-delà du forfait il faut acheter un palier supérieur ou payer le dépassement. Chez Airtable, le prix suit le nombre de collaborateurs : avec trente collaborateurs sur l'offre Business, l'abonnement atteint 30 × 45 × 12 = 16 200 dollars par an (calcul fait à partir du prix affiché).

Les limites à connaître avant de bâtir dessus

La dépendance à la plateforme

Une application no-code ne fonctionne en général que chez l'éditeur qui l'héberge. Bubble l'écrit dans son aide : la plateforme ne permet ni l'export du code ni l'hébergement chez soi. Les données peuvent être exportées en fichiers CSV, mais la logique de l'application (écrans, règles, automatisations) devra être refaite si vous partez.

Source : Bubble, aide « Can I export my Bubble application? », consulté le 22 octobre 2026.

Si l'éditeur change ses prix, ses limites ou ses conditions, vous suivez. Ce risque est acceptable pour un outil secondaire. Il l'est moins pour l'outil qui fait tourner vos commandes ou votre facturation.

Les règles complexes

Un calcul de prix avec exceptions, un planning avec contraintes, des droits d'accès fins par client : le no-code sait le faire jusqu'à un certain point, puis les contournements s'empilent. L'outil devient difficile à comprendre, y compris pour la personne qui l'a construit.

Le volume et la vitesse

Les limites d'enregistrements par base et la facturation à l'usage obligent à surveiller la croissance. Un outil qui marche bien avec quelques milliers de lignes et cinq utilisateurs peut ralentir, ou coûter beaucoup plus, avec cent mille lignes et cinquante utilisateurs.

Les accès extérieurs

Ouvrir l'outil à vos clients ou à vos partenaires pose des questions de sécurité, de présentation et de prix par utilisateur que les plateformes traitent inégalement. C'est souvent à ce moment que le sur mesure redevient compétitif.

La personne qui construit

Un outil no-code monté par un salarié motivé dépend de lui. S'il change de poste, plus personne ne sait pourquoi telle automatisation existe ni ce qui casse si on la retire. Monté par une agence, il dépend du compte et de la documentation qu'elle laisse. Dans les deux cas, demandez une description écrite des tables, des règles et des automatisations, et faites-la tenir à jour.

Ce que le développement sur mesure apporte en échange

Un développement coûte plus cher au départ. Pour une application web, un SaaS ou un extranet, La Fabrique du Net affiche 10 000 à 25 000 € chez un freelance, 30 000 à 80 000 € dans une agence standard et 90 000 à 300 000 € ou plus dans une agence haut de gamme (consulté le 22 octobre 2026). Le guide sur le prix d'une application web sur mesure et la page prix d'un logiciel métier sur mesure donnent les autres repères publics. En échange :

• le code peut vous appartenir et tourner chez l'hébergeur de votre choix, si le contrat le prévoit (voir la propriété du code source) ;
• le coût courant ne dépend plus du nombre d'utilisateurs ni d'unités de charge, seulement de l'hébergement et de la maintenance (voir l'hébergement d'une application métier) ;
• les règles complexes s'écrivent proprement, et peuvent être vérifiées par des tests automatiques ;
• un autre développeur peut reprendre le projet, à condition d'avoir le code et la documentation.

La contrepartie : il faut un prestataire compétent, un besoin bien décrit, et un budget de maintenance chaque année. Un outil développé puis laissé sans entretien vieillit.

Commencer en no-code, passer au sur mesure ensuite

Ce chemin est souvent raisonnable. Une première version en no-code permet de vérifier que l'outil sert, de découvrir les règles oubliées, et de mesurer l'usage réel. Si l'outil devient central, on le redéveloppe sur mesure avec un cahier des charges nourri par l'expérience, ce qui réduit les surprises.

Prenons une entreprise de maintenance de 40 salariés, exemple inventé pour l'illustration. Elle suit ses interventions dans un fichier partagé, passe sur une base en ligne utilisée par cinq personnes au bureau, et découvre en quelques mois que les techniciens doivent saisir depuis leur téléphone et que les clients réclament leurs rapports en ligne. À ce stade, le no-code lui a servi à préciser son besoin. Le développement qui suit part d'usages vérifiés, avec des données déjà structurées, et son chiffrage en devient plus fiable.

Deux précautions rendent ce passage moins coûteux : garder les données dans une structure propre (une table par type d'information, pas de colonnes fourre-tout), et noter les règles au fur et à mesure qu'on les ajoute. Le guide sur la première version d'un logiciel pour une PME traite de cette approche par étapes.

Quand on me transmet un devis d'agence no-code, ou un outil déjà construit sur une plateforme, je réponds franchement : si la plateforme convient à votre usage, je vous le dis, et je ne propose pas de redévelopper ce qui marche. Si un développement se justifie, je le chiffre à prix fixe, découpé en étapes payées une fois livrées et validées.

Les questions à poser avant de choisir

• Combien d'utilisateurs dans un an et dans trois ans, et combien coûtera l'abonnement à ce moment-là ?
• Qui est titulaire du compte de la plateforme : vous ou le prestataire qui construit l'outil ?
• Peut-on exporter toutes les données, fichiers joints compris, dans un format lisible ?
• Que se passe-t-il si l'éditeur augmente ses prix ou change ses limites ?
• Quelles règles de gestion seront difficiles à exprimer avec les blocs de la plateforme ?
• L'outil devra-t-il être ouvert à des clients ou partenaires extérieurs ?
• Qui saura modifier l'application si la personne qui l'a construite s'en va ?