DEV Community: Delivery Digital Nice

Site sur mesure vs no-code : comment choisir ?

Delivery Digital Nice — Sun, 17 May 2026 02:37:30 +0000

Site sur mesure ou no-code : quelles différences réelles pour votre projet ?

Vous hésitez entre faire développer un site sur mesure ou utiliser une plateforme no-code comme Webflow, Bubble ou Softr ? Le choix n'est pas anodin : il engage votre budget, votre vitesse d'exécution, votre capacité à évoluer et, à terme, la valeur même de votre actif numérique. Cet article décortique les vraies différences techniques, économiques et stratégiques entre ces deux approches, pour vous aider à trancher en connaissance de cause.

Définir clairement les deux approches

Avant de comparer, posons les bases. Les deux termes sont souvent mal utilisés et recouvrent des réalités très différentes.

Le développement sur mesure

Un site ou une application sur mesure est codé spécifiquement pour répondre à un cahier des charges. Le code source est écrit par des développeurs, généralement avec des technologies comme React, Next.js, Node.js, TypeScript ou PostgreSQL. Le résultat est un actif technique entièrement maîtrisé : architecture, base de données, hébergement, logique métier, tout est défini selon les besoins du projet.

Le no-code

Le no-code repose sur des plateformes propriétaires qui permettent de construire un site ou une application via des interfaces visuelles, sans écrire de code (ou très peu). Webflow pour les sites vitrines, Bubble pour les applications web, Softr ou Glide pour des outils internes, Airtable pour des bases de données légères. L'utilisateur assemble des blocs préconçus et configure la logique via des menus.

Dans les deux cas, on obtient un produit fonctionnel. Mais la nature de ce produit, et ce qu'on peut en faire, diffère profondément.

Coût initial et coût total de possession

C'est souvent le premier critère évoqué, et pourtant c'est aussi le plus mal compris.

Le coût d'entrée

Le no-code a un avantage clair sur le ticket d'entrée. Un site Webflow peut être livré pour quelques milliers d'euros. Une application Bubble simple peut tourner pour quelques centaines d'euros par mois en abonnement plateforme. Le sur mesure démarre généralement plus haut, car il implique conception technique, développement, tests et déploiement.

Le coût récurrent

C'est ici que la perspective change. Les plateformes no-code facturent à l'usage : nombre d'utilisateurs, volume de données, nombre de workflows, bande passante. Plus votre produit grossit, plus la facture grimpe, et de façon parfois exponentielle. Un projet Bubble qui passe de 100 à 10 000 utilisateurs actifs peut voir ses coûts plateforme multipliés par 20 ou 30.

Un site sur mesure, lui, est hébergé sur une infrastructure que vous contrôlez (AWS, OVH, Scaleway). Le coût d'hébergement reste modeste et linéaire, même à fort trafic.

À retenir

No-code : coût initial faible, coût récurrent croissant avec le succès.
Sur mesure : investissement initial plus élevé, coût d'exploitation maîtrisé sur la durée.

Performance, scalabilité et limites techniques

Les plateformes no-code sont des couches d'abstraction. Elles génèrent du code générique adapté au plus grand nombre, ce qui implique des compromis.

Performance

Un site Webflow bien construit est rapide pour une vitrine. En revanche, dès qu'on parle d'applications avec beaucoup d'interactions, de calculs côté serveur ou de requêtes complexes, les performances no-code chutent. Une application Bubble peut devenir lente avec des bases de données de quelques dizaines de milliers d'entrées.

Un développement sur mesure permet d'optimiser ce qui doit l'être : indexation de la base de données, mise en cache, server-side rendering, CDN, lazy loading. Les techniques sont nombreuses et précisément applicables au cas d'usage.

Limites fonctionnelles

Le no-code couvre 80 % des besoins classiques. Le problème, ce sont les 20 % restants. Quelques exemples concrets :

Intégration d'un algorithme métier propriétaire (scoring, recommandation, calcul tarifaire complexe).
Synchronisation temps réel avec un ERP existant via API non standard.
Application mobile native avec accès au Bluetooth, NFC ou capteurs spécifiques.
Volumes de données importants avec des requêtes analytiques en temps réel.
Exigences de conformité poussées (RGPD avancé, hébergement souverain, chiffrement de bout en bout).

Ces besoins sont soit impossibles, soit acrobatiques en no-code.

Propriété, dépendance et risque plateforme

C'est l'un des points les plus sous-estimés.

Qui possède quoi ?

Avec un développement sur mesure, vous êtes propriétaire du code source, de la base de données, de l'infrastructure. Vous pouvez changer de prestataire, migrer d'hébergeur, faire évoluer le produit indépendamment.

Avec une solution no-code, vous louez l'usage d'une plateforme. Le code généré n'est généralement pas exportable de manière exploitable. Si Bubble change ses tarifs, modifie ses conditions ou disparaît, votre application est impactée directement. Webflow a déjà revu ses grilles tarifaires plusieurs fois ; certains clients ont vu leurs coûts doubler en quelques mois.

Vendor lock-in

Le vendor lock-in (dépendance fournisseur) est inhérent au no-code. Migrer une application Bubble vers du code natif revient en pratique à la réécrire entièrement. C'est un coût caché à anticiper si le projet décolle.

Cas d'usage : quand chaque approche fait sens

Il n'y a pas de bonne ou mauvaise approche dans l'absolu. Il y a des contextes.

Le no-code est pertinent pour

Un site vitrine sans logique métier complexe.
Un MVP destiné à valider une hypothèse avant un développement plus sérieux.
Un outil interne temporaire (formulaires, tableaux de bord simples).
Une landing page de campagne marketing.
Un prototype présenté à des investisseurs ou des utilisateurs pilotes.

Le sur mesure est pertinent pour

Un SaaS destiné à être vendu et à croître.
Une application métier centrale (CRM, ERP, plateforme B2B).
Un produit avec une logique métier différenciante.
Une application mobile native iOS/Android.
Un système devant s'intégrer profondément à un SI existant.
Tout projet où le code lui-même fait partie de la valeur de l'entreprise.

Le piège classique

Beaucoup de projets démarrent en no-code pour valider rapidement, ce qui est sain. Le piège, c'est de rester sur cette base au-delà de ce qu'elle peut porter. À un certain stade, il devient plus coûteux de maintenir et contourner les limites du no-code que de passer au sur mesure. Anticiper ce point de bascule est une décision stratégique.

Délais, maintenance et évolution

Délais de mise en route

Le no-code gagne sur les délais initiaux. Un site vitrine Webflow peut être en ligne en quelques semaines. Un MVP Bubble peut être prêt en un à deux mois. Le sur mesure demande davantage de temps initial, en raison de la phase de conception et de l'écriture du code.

Maintenance

Le no-code décharge une partie de la maintenance technique (mises à jour serveur, sécurité de base, certificats SSL). En contrepartie, vous subissez les mises à jour de la plateforme : changements d'interface, dépréciations de fonctionnalités, bugs introduits par les éditeurs.

Le sur mesure demande une maintenance active (mises à jour de dépendances, patches de sécurité, monitoring), mais vous gardez la main sur le calendrier et les priorités.

Évolutivité fonctionnelle

Ajouter une fonctionnalité en no-code est rapide tant qu'elle reste dans le cadre de la plateforme. Hors cadre, l'ajout devient impossible ou nécessite des bricolages fragiles. Le sur mesure n'a pas ce plafond : si c'est techniquement faisable, c'est faisable dans votre application.

Comment trancher pour votre projet

Quelques questions à se poser avant de choisir :

Le code et la donnée sont-ils centraux dans la valeur de mon entreprise ?
Combien d'utilisateurs ou de transactions est-ce que je vise à 2-3 ans ?
Ai-je des contraintes d'intégration avec des systèmes existants ?
Quel est mon budget initial, et quelle est ma capacité à porter des coûts récurrents croissants ?
Le projet doit-il pouvoir être revendu, audité ou cédé un jour ?

Si les réponses penchent vers de la valeur métier durable, de la scalabilité et de l'indépendance technique, le sur mesure est généralement le bon choix. Si le projet est exploratoire, temporaire ou strictement vitrine, le no-code fait parfaitement le travail.

En résumé

Le no-code et le sur mesure ne sont pas des concurrents directs : ce sont des outils adaptés à des moments et des ambitions différents. Le no-code est excellent pour aller vite et valider. Le sur mesure construit un actif technique durable, performant et évolutif. Le bon réflexe, c'est de choisir en fonction du projet, pas en fonction d'une mode.

Chez DELIVERY Digital, nous concevons des sites et applications sur mesure pour des PME et des startups en France et à l'international. Si vous voulez en parler concrètement, notre équipe comprend votre besoin sur /discutons : décrivez votre projet, nous revenons vers vous avec une lecture claire et des pistes adaptées.

Délai de développement d'une application mobile

Delivery Digital Nice — Sun, 17 May 2026 02:37:25 +0000

Combien de temps pour développer une application mobile ? La réponse honnête en 2025

La question revient dans presque chaque premier échange avec un dirigeant ou un product owner : combien de temps pour développer une application mobile ? La réponse courte est frustrante : cela dépend. La réponse longue, elle, est utile, car elle permet de planifier un budget, des recrutements, une stratégie produit. Cet article détaille les fourchettes réalistes, les facteurs qui font basculer un projet de 3 à 9 mois, et les leviers concrets pour livrer plus vite sans sacrifier la qualité.

Les fourchettes réalistes par type d'application

Avant de plonger dans les détails, voici des ordres de grandeur observés sur le marché. Ces durées incluent la conception, le développement, les tests et la mise en production sur les stores. Elles supposent une équipe dédiée et un client réactif sur les validations.

MVP simple (1 à 3 écrans clés, une fonctionnalité centrale) : 6 à 12 semaines. Exemple : une application de prise de rendez-vous avec authentification, calendrier et notifications.
Application standard (10 à 20 écrans, backend custom, paiement) : 3 à 6 mois. Exemple : une marketplace de services, une application de fidélité avec scan QR et historique.
Application complexe (rôles multiples, temps réel, intégrations métier) : 6 à 12 mois. Exemple : une plateforme logistique avec tracking GPS, dashboard transporteur et back-office gestionnaire.
Application à très forte exigence (santé, banque, IoT) : 9 à 18 mois. Conformité, certifications, audits de sécurité et tests poussés allongent mécaniquement les délais.

Ces fourchettes restent indicatives. Un projet annoncé à 4 mois peut glisser à 7 mois si le périmètre n'est pas figé, ou au contraire être livré en 10 semaines si l'équipe utilise les bons outils et que les décisions sont rapides.

Les facteurs qui font varier le délai du simple au triple

Le périmètre fonctionnel

C'est le premier facteur. Une application qui se contente d'afficher du contenu issu d'un CMS prend quelques semaines. La même application avec un système de paiement, de la géolocalisation en temps réel, du chat intégré et un espace administrateur peut tripler de durée. Chaque fonctionnalité ajoutée n'est pas linéaire : elle interagit avec les autres, génère des cas limites, demande des tests supplémentaires.

Le choix technologique

Développer une application en natif (Swift pour iOS, Kotlin pour Android) signifie deux bases de code, deux équipes, deux cycles de tests. Une approche cross-platform avec React Native permet de partager 80 à 95 % du code entre iOS et Android, ce qui réduit significativement le délai. Chez DELIVERY Digital, nous privilégions React Native quand le besoin s'y prête, avec du natif sur les modules critiques (caméra avancée, capteurs spécifiques) si nécessaire.

La maturité du design

Un projet qui démarre avec des maquettes Figma validées, un design system clair et des parcours utilisateurs éprouvés gagne plusieurs semaines. À l'inverse, démarrer le développement avec des wireframes flous mène à des allers-retours coûteux. Compter 2 à 6 semaines de design en amont selon la complexité.

Le backend et les intégrations

Une application mobile sans backend, c'est rare. Il faut une API, une base de données, souvent une authentification, parfois des intégrations tierces (Stripe, services métier internes, ERP, CRM). Chaque intégration ajoute des jours ou des semaines, surtout si la documentation du système tiers est faible ou si l'API doit être créée de zéro.

La réactivité côté client

C'est le facteur invisible mais déterminant. Un projet où les décisions traînent une semaine à chaque étape de validation perd facilement un mois sur 4 mois prévus. Une bonne agence le dit dès le départ : la cadence du client conditionne la cadence de livraison.

Les grandes phases du développement et leur durée

Pour un projet de 4 à 5 mois en moyenne, voici comment se répartissent les phases :

Cadrage et spécifications (2 à 4 semaines) : ateliers, user stories, parcours, choix techniques, planning détaillé.
Design UX/UI (3 à 6 semaines) : wireframes, maquettes haute fidélité, prototype interactif, design system.
Développement (8 à 16 semaines) : sprints de 2 semaines, démos régulières, intégration continue. Cette phase chevauche souvent la fin du design.
Tests et recette (2 à 4 semaines) : tests fonctionnels, tests sur appareils réels, correction des bugs, tests de performance et de sécurité.
Publication sur les stores (1 à 3 semaines) : préparation des fiches App Store et Google Play, soumission, gestion des retours des reviewers Apple (qui peuvent demander des modifications).

La publication est souvent sous-estimée. Apple peut refuser une première soumission pour des raisons mineures (description de la politique de confidentialité, mention d'un abonnement), et chaque resoumission ajoute 24 à 72 heures.

Comment réduire le délai sans sacrifier la qualité

Découper en MVP puis itérations

La pire erreur consiste à vouloir tout livrer d'un coup. Un MVP livré en 3 mois et enrichi par itérations mensuelles apporte plus de valeur qu'une version complète livrée en 9 mois, parce qu'il génère des retours utilisateurs réels que vous intégrez ensuite.

Utiliser des briques éprouvées

Il est rarement utile de recoder une authentification, un système de paiement ou des notifications push de zéro. Firebase, Supabase, Stripe, OneSignal, Auth0 : ces services accélèrent le développement de plusieurs semaines. Une bonne équipe sait quand utiliser une brique existante et quand développer sur mesure.

Mettre en place une CI/CD dès le début

Une intégration continue avec déploiement automatique vers TestFlight et la piste interne Google Play permet de livrer une nouvelle version testable à chaque sprint, sans perdre une journée à compiler et distribuer manuellement.

Avoir un seul interlocuteur décisionnaire

Les projets qui avancent vite ont un product owner côté client qui peut trancher rapidement. Les projets qui s'enlisent ont des comités de validation à 5 personnes pour chaque écran.

Un exemple concret

Nous avons accompagné une PME B2B sur une application de gestion d'interventions terrain : authentification, planning, formulaires de rapport avec photos, signature client, synchronisation hors ligne, back-office web pour les gestionnaires. Périmètre intermédiaire avec une vraie contrainte technique (mode offline).

Cadrage : 3 semaines.
Design : 4 semaines, partiellement en parallèle du cadrage.
Développement React Native + backend Node.js + PostgreSQL : 14 semaines.
Tests, recette, publication : 4 semaines.

Total : environ 5 mois entre la signature et la disponibilité sur les stores, avec une équipe de 3 personnes côté DELIVERY Digital et un product owner client réactif. Le client a ensuite bénéficié du Crédit Impôt Innovation, dispositif officiel pour lequel nous sommes certifiés CII, permettant aux PME françaises éligibles de récupérer 20 % des dépenses d'innovation engagées (dans la limite de 400 000 € de dépenses éligibles par an, soit jusqu'à 80 000 € de crédit annuel maximum).

Les pièges qui rallongent silencieusement les projets

Le périmètre qui gonfle en cours de route : chaque nouvelle idée doit être arbitrée, soit elle remplace une autre fonctionnalité, soit elle décale la livraison.
Les validations en plusieurs vagues : valider l'écran d'accueil trois fois à un mois d'intervalle coûte plus cher que de bloquer 2 heures pour le valider en une fois.
L'absence de jeu de données de test réaliste : tester avec 3 utilisateurs fictifs ne révèle pas les bugs qui apparaissent avec 10 000 enregistrements.
Le sous-investissement sur les tests : économiser 2 semaines de tests pour les passer en correctifs post-lancement coûte généralement le double.

Conclusion

Compter entre 3 et 9 mois pour une application mobile professionnelle, avec une médiane autour de 4 à 5 mois pour un projet correctement cadré. Le délai réel dépendra surtout du périmètre, de la maturité du design en entrée, et de la réactivité des décisions. La meilleure manière d'obtenir une estimation fiable sur votre projet est de décrire votre besoin précisément : /discutons comprend votre besoin sur /discutons et vous renvoie une première estimation de durée et de budget en quelques minutes.