Freelance, no-code ou agence : qui doit construire votre application ?
13 min de lecture
À retenir
- Le no-code est la bonne réponse pour valider un besoin, outiller une petite équipe ou lancer un premier produit à faible volume.
- Les générateurs d’IA livrent du vrai code que vous pouvez récupérer, mais quelqu’un doit pouvoir le relire, le sécuriser et le maintenir.
- Avant de choisir, vérifiez cinq points : propriété du code, montée en charge, publication sur les stores, hébergement des données et compétences disponibles.
- Migrer du no-code vers le sur-mesure, c’est presque toujours réécrire : préparez-le dès le premier jour en gardant vos données, vos parcours et vos règles métier documentés.
Il y a cinq ans, la question était simple : sans développeur, pas d’application. Aujourd’hui, un fondateur peut assembler une app dans Bubble en quelques semaines, ou décrire son idée à un générateur d’IA et obtenir un prototype cliquable dans l’après-midi. C’est un vrai progrès, et nous le recommandons régulièrement.
Mais ces trois options n’achètent pas la même chose. Le no-code achète de la vitesse d’apprentissage. L’IA achète de la vitesse d’écriture. Le sur-mesure achète du contrôle. Le bon choix dépend de ce dont votre projet a besoin dans dix-huit mois, pas de ce qui va le plus vite cette semaine.
Notre article freelance, no-code ou agence compare qui construit l’application. Celui-ci compare avec quoi on la construit, et ce que chaque choix vous coûte plus tard.
Trois façons de construire, en une phrase chacune
Le no-code. Vous assemblez l’application dans un éditeur visuel (Bubble, FlutterFlow, Adalo, Glide…) et l’éditeur l’héberge. Vous ne voyez pas le code, ou très peu.
Les générateurs d’IA. Vous décrivez ce que vous voulez en langage naturel, un outil comme Lovable écrit le code, vous corrigez par la conversation. Le résultat est du code réel, que vous pouvez en général exporter.
Le développement sur mesure. Une équipe conçoit l’architecture et écrit le code, avec React Native, Flutter ou en natif, sur une infrastructure que vous choisissez. Les assistants d’IA font désormais partie de ses outils, mais un humain décide et relit.
Le comparatif
| No-code | Générateur d’IA | Sur mesure | |
|---|---|---|---|
| Premier prototype | Quelques jours à quelques semaines | Quelques heures à quelques jours | 4 à 8 semaines pour un MVP mobile |
| Propriété du code | Absente à partielle selon l’outil | Code exportable le plus souvent | Totale, si le contrat le prévoit |
| Coût récurrent | Abonnement qui monte avec l’usage | Abonnement et crédits | Hébergement et maintenance (15 à 20 % du coût initial par an) |
| Logique métier complexe | Vite illisible | Possible, fragile sans relecture | Prévue pour |
| Fonctions natives (Bluetooth, hors ligne, arrière-plan) | Limitées aux extensions de l’outil | Variable | Sans limite |
| Hébergement des données | Choisi par l’éditeur | Souvent choisi par l’éditeur | Choisi par vous |
| Compétence requise | Logique, pas de code | Savoir relire du code | Une équipe |
Aucune colonne ne gagne partout. C’est le profil de votre projet qui décide de la ligne qui compte.
Le no-code : quand c’est le bon choix
Nous conseillons le no-code sans hésiter dans trois situations.
Vous testez une hypothèse. Vous ne savez pas encore si quelqu’un utilisera ou paiera le service. Dépenser 30 à 60 jours-homme de développement pour le découvrir n’a pas de sens si un outil visuel vous donne la réponse en trois semaines.
C’est un outil interne. Un suivi de demandes, un annuaire, un formulaire d’inspection pour une petite équipe. Les volumes sont faibles, les utilisateurs sont vos collègues, et la tolérance à une interface standard est élevée.
Le produit est surtout du contenu et des formulaires. Catalogue, réservation simple, espace membre. Les outils no-code sont très bons pour ça, et l’écart avec du sur-mesure ne justifie pas le budget.
Les outils ont aussi progressé sur le mobile. Bubble indique que ses applications natives tournent sur React Native et peuvent être publiées sur l’App Store et Google Play, avec un plan payant pour passer en production. FlutterFlow propose le déploiement vers les deux stores et le téléchargement du code source dès son plan Basic. Adalo inclut la publication sur les stores dès son plan Builder.
Le bon usage du no-code : fixer dès le départ la question à laquelle l’outil doit répondre (« les gens réservent-ils ? », « l’équipe abandonne-t-elle le papier ? ») et la date à laquelle vous la regarderez. Un prototype sans question devient un produit par accident.
Les générateurs d’IA : du vrai code, mais qui le relit ?
Les générateurs d’IA changent un point important par rapport au no-code classique : ils produisent du code que vous pouvez emporter. Lovable, par exemple, propose une synchronisation bidirectionnelle avec GitHub, dans un dépôt privé par défaut, et un téléchargement du code sur les plans payants. Sa page tarifs précise que vous possédez le code de vos projets.
C’est un vrai avantage pour la migration. Mais posséder du code ne veut pas dire pouvoir le faire évoluer. Trois limites reviennent presque toujours.
Le code fonctionne en démonstration, pas forcément en production. Le parcours principal marche ; les cas d’erreur, les sessions expirées, les accès concurrents et les droits par rôle sont souvent traités de façon superficielle. Ce sont précisément les points qu’un utilisateur réel rencontre en premier.
La sécurité n’est pas vérifiée par défaut. Un générateur peut exposer une base de données avec des règles d’accès trop larges sans que rien ne le signale à l’écran. Si l’application manipule des données personnelles, une relecture par quelqu’un qui sait ce qu’il cherche n’est pas optionnelle.
Chaque correction par prompt ajoute une couche. Au bout de quelques centaines d’itérations, la structure du projet reflète l’historique de la conversation plutôt qu’une architecture. Le reprendre coûte alors presque autant que de le réécrire.
Notre position est simple : l’IA est excellente pour produire un prototype qui sert de spécification vivante, et très utile entre les mains d’un développeur. Elle ne remplace pas encore la personne qui répond de ce qui part en production.
Les cinq limites à vérifier avant de choisir
1. La propriété du code et la dépendance à l’éditeur
C’est la question la plus importante et la moins posée. Le manuel de Bubble est clair : vous possédez le design et les données de votre application, Bubble possède le code sous-jacent, et une application Bubble ne peut tourner que sur Bubble. Vous pouvez exporter vos données en CSV, mais la logique est à reconstruire ailleurs. FlutterFlow, à l’inverse, pousse un projet Flutter sur GitHub, que vous pouvez reprendre.
Concrètement : si l’éditeur double ses prix, change ses conditions ou retire une fonctionnalité, quelle est votre porte de sortie, et combien de temps prend-elle ?
2. La montée en charge et les performances
Les plateformes facturent de plus en plus à l’usage. Bubble compte en « workload units » : 175 000 par mois sur le plan Starter, 250 000 sur Growth, avec des paliers supplémentaires payants. Un produit qui marche consomme plus, et la facture suit votre succès. Les leviers d’optimisation, eux, restent ceux que l’éditeur expose.
3. La publication sur les stores
Être techniquement publiable ne garantit pas d’être accepté. Les règles d’Apple refusent les applications qui ne sont qu’un site web reconditionné (règle 4.2) et celles créées à partir d’un service de génération d’applications, sauf si c’est le propriétaire du contenu qui les soumet (règle 4.2.6). Prévoyez aussi les comptes développeur : 99 dollars par an chez Apple, 25 dollars une fois chez Google. Nous détaillons les autres motifs de refus dans notre article sur l’App Store et Google Play.
4. Les données et le RGPD
Avec un outil hébergé, c’est l’éditeur qui choisit où vivent vos données. Le manuel de Bubble indique que des serveurs dédiés en Europe relèvent du plan Enterprise, et que les transferts hors UE reposent sur des clauses contractuelles types. Ce n’est pas un obstacle pour tous les projets, mais un client grand compte, une collectivité ou une application de santé peut l’exiger. Notre guide RGPD et application mobile détaille ce qu’il faut vérifier.
5. Les compétences disponibles
Le no-code demande de la rigueur logique, pas du code. L’IA demande de savoir relire du code. Le sur-mesure demande une équipe, interne ou externe. Choisir une option sans avoir la compétence qu’elle suppose est la source d’échec la plus fréquente.
Le coût sur trois ans, pas sur trois mois
Les abonnements no-code paraissent dérisoires face à un devis de développement. Au 15 novembre 2026, d’après leurs pages tarifs : Bubble à 32, 119 ou 349 dollars par mois en annuel, FlutterFlow à 29, 60 ou 113 dollars par mois en annuel, Adalo à 65 ou 200 dollars par mois en mensuel.
En face, la médiane relevée par La Fabrique du Net pour une application réalisée par une agence est de 30 000 €, et d’environ 15 000 € pour un MVP. La maintenance d’une app sur mesure représente ensuite 15 à 20 % du coût initial par an.
1 428 $Un an de Bubble Growth au tarif annuel affiché (119 $ × 12)
≈ 15 000 €Médiane d’un MVP réalisé par une agence (La Fabrique du Net)
15–20 %Coût annuel de maintenance d’une app sur mesure
Sur le papier, le no-code gagne largement. Le calcul change sur trois points :
- Le temps passé. Si vous construisez vous-même, vos soirées et vos week-ends ont un coût. Si vous payez un spécialiste no-code, la facture se rapproche d’un développement classique.
- L’usage. Les paliers de charge et de crédits d’IA s’ajoutent quand le produit décolle, au moment où vous êtes le moins en position de négocier.
- La réécriture. Si le produit marche, elle arrive presque toujours. Elle n’est pas un échec, mais elle doit figurer dans le plan dès le départ.
Le vrai coût du no-code n’est donc pas l’abonnement. C’est la réécriture que vous n’aviez pas budgétée. Pour situer un budget sur mesure, notre article combien coûte une application mobile détaille les paliers.
Migrer du no-code vers le sur-mesure sans tout perdre
Soyons honnêtes : avec un outil comme Bubble, on ne migre pas, on réécrit. Avec FlutterFlow ou un générateur d’IA, le code récupéré peut servir de base, mais il faut en général le restructurer. Dans les deux cas, ce que vous gardez a énormément de valeur, à condition de l’avoir préparé.
Ce qui se récupère : les données (export CSV ou API), les parcours validés par de vrais utilisateurs, les écrans qui fonctionnent, les chiffres d’usage, et surtout la liste de ce qui n’a pas marché.
Ce qui se perd : la logique métier enfouie dans les blocs visuels ou les prompts, si personne ne l’a écrite ailleurs.
Quatre habitudes, dès le premier jour, réduisent fortement le coût de la réécriture :
- Documenter chaque règle métier en une phrase dans un document partagé : tarifs, calculs, statuts, droits. C’est votre futur cahier des charges.
- Garder un modèle de données propre : des tables nommées clairement, sans champs « temporaires » qui durent un an.
- Mesurer l’usage avec un outil d’analytics indépendant de la plateforme, pour que l’historique survive à la migration.
- Fixer les signaux de sortie à l’avance : un volume d’utilisateurs, un coût mensuel, une fonctionnalité impossible. Quand deux signaux sont atteints, on cadre la réécriture.
Bien préparée, la réécriture d’un MVP validé tient dans le calendrier habituel : 4 à 8 semaines pour un MVP mobile sur une plateforme, 3 à 4 mois pour une application complète iOS et Android. Elle part de données réelles, ce qui la rend beaucoup plus sûre qu’un premier projet. Le choix de la technologie cible est traité dans React Native, Flutter ou natif.
Notre grille de décision
Choisissez l’outil qui répond à votre question actuelle, et écrivez dès aujourd’hui ce que vous ferez quand il ne suffira plus.
- Vous ne savez pas encore si le besoin existe : no-code ou prototype généré par IA, avec une question et une date.
- Outil interne pour une petite équipe, faible volume : no-code, durablement.
- Vous voulez montrer quelque chose à des investisseurs ou des utilisateurs la semaine prochaine : générateur d’IA, en assumant que c’est une maquette.
- Données sensibles, intégrations lourdes, fonctions natives, ou produit qui doit tenir plusieurs années : sur mesure dès le départ, en limitant le premier périmètre comme expliqué dans notre méthode de MVP.
- Votre version no-code marche et commence à coincer : réécriture sur mesure, en partant de vos données et de vos parcours validés.
Pour aller plus loin : notre page création d’application mobile explique comment nous reprenons un prototype no-code ou IA pour en faire une application de production, du cadrage à la publication sur les stores.
Sources
- Bubble, page tarifs (consultée le 15/11/2026)
- Bubble, manuel : propriété de l’application et des données
- Bubble, manuel : RGPD
- FlutterFlow, page tarifs (consultée le 15/11/2026)
- FlutterFlow, documentation : Push to GitHub
- Adalo, page tarifs (consultée le 15/11/2026)
- Lovable, page tarifs
- Lovable, documentation : intégration GitHub
- Apple, App Store Review Guidelines (règles 4.2 et 4.2.6)
- La Fabrique du Net, tarifs des agences d’application mobile (novembre 2026)
