Agence, freelance ou no-code : qui doit développer votre application ?

Il n'y a pas de bonne réponse universelle : le no-code convient à un outil simple pour une petite équipe, un freelance à un projet bien cadré dont vous pouvez piloter la technique, une agence ou un studio à une application dont l'entreprise va dépendre plusieurs années. Le bon critère n'est pas le prix de départ, mais ce qui se passe le jour où l'application doit évoluer, être corrigée ou survivre au départ de celui qui l'a construite.

Voici ce que chaque option garantit vraiment, quand elle est la bonne, et comment trancher sans se tromper.

Quatre façons de faire construire une application

Le no-code. Des plateformes comme Glide, Softr, Bubble ou Airtable permettent d'assembler une application sans écrire de code, à partir de briques prêtes à l'emploi. C'est rapide, souvent faisable en interne, et facturé par abonnement, généralement en fonction du nombre d'utilisateurs ou de l'usage.

Le freelance. Un développeur indépendant construit l'application, en général sur devis ou au temps passé. La qualité dépend entièrement de la personne, et la continuité aussi.

L'agence ou l'ESN en régie. Une société met des développeurs à disposition et facture le temps passé. Vous pilotez, elle fournit les compétences. Nous avons détaillé ce modèle dans notre comparaison forfait ou régie.

Le studio au forfait. Une équipe s'engage sur un résultat à prix fixe : le périmètre est cadré, chiffré, puis livré et maintenu. C'est le modèle de LPR Studio, qui ne vend ni heures ni personnel. Nous le précisons parce que la suite de cet article compare des approches, pas des prestataires, et qu'elle dit aussi quand la nôtre n'est pas la bonne.

Le comparatif

Aucune colonne ne gagne partout. Le no-code gagne en vitesse et en coût de départ, le freelance en souplesse, la régie en contrôle, le forfait en prévisibilité.

Quand le no-code est le bon choix

Le no-code a mauvaise réputation chez certains développeurs, à tort quand il est bien employé. Il est le bon choix quand :

• l'outil sert une équipe réduite, avec un processus simple ;
• les données sont peu sensibles et le volume modeste ;
• vous voulez tester un besoin avant d'investir, ou remplacer un tableur qui déborde ;
• quelqu'un en interne a le temps et le goût de construire et d'entretenir l'outil.

Ses limites apparaissent avec les règles métier nombreuses, les droits différenciés par profil, les intégrations profondes et la montée en charge. Deux points se calculent sur la durée : le coût des abonnements quand le nombre d'utilisateurs grandit, et la dépendance à une plateforme dont vous ne maîtrisez ni les prix ni la feuille de route. Passer ensuite au code est une reconstruction, pas une conversion. Notre article sur remplacer Excel par une application métier aide à situer le moment où un outil bricolé ne suffit plus.

Quand un freelance est le bon choix

Un bon freelance peut livrer un excellent logiciel. C'est le bon choix quand :

• le projet est bien cadré, de taille raisonnable ;
• vous avez en interne quelqu'un capable de piloter la technique : relire les choix, vérifier les livraisons, organiser la reprise si besoin ;
• vous acceptez un risque de continuité : maladie, autre mission, arrêt d'activité.

Ce risque se réduit par le contrat et l'organisation : code versionné dans un dépôt dont vous êtes titulaire, hébergement à votre nom, documentation exigée à chaque livraison, et propriété du code clarifiée par écrit. Notre article sur la propriété du code source détaille ce qu'il faut prévoir.

Quand une agence ou un studio est le bon choix

Une équipe constituée se justifie quand l'application devient un outil dont l'entreprise dépend : plusieurs services, des données critiques, des intégrations, une durée de vie de plusieurs années. Ce que vous achetez alors, au-delà du code, c'est la continuité : quelqu'un qui répond dans cinq ans, qui applique les correctifs de sécurité et qui fait évoluer l'outil.

Entre régie et forfait, la différence est la répartition du risque : en régie, vous payez le temps passé et portez le risque de dépassement ; au forfait, le prix est fixé avant le développement et le prestataire porte ce risque. Le forfait suppose en contrepartie un périmètre visible avant de signer, d'où l'intérêt d'un prototype.

Les signaux d'alerte, quelle que soit l'option

Certains signaux valent pour les quatre approches, et ils se repèrent avant de signer :

• personne ne demande à voir vos processus réels : un chiffrage fait sans comprendre le travail quotidien sera revu en cours de route ;
• le prix tombe au premier appel, sans cadrage ni périmètre écrit ;
• les accès restent chez le prestataire : dépôt de code, hébergement, nom de domaine, comptes des services tiers. Ils devraient être à votre nom, ou leur transfert prévu par écrit ;
• la maintenance n'apparaît nulle part, ni incluse ni chiffrée ;
• aucune démonstration n'est possible avant l'engagement, ni maquette, ni prototype, ni outil comparable déjà en production.

Un seul de ces signaux ne disqualifie pas forcément une offre. Plusieurs à la fois annoncent presque toujours un projet qui coûtera plus cher et durera plus longtemps que prévu.

Quatre questions pour trancher

1. Que se passe-t-il si la personne ou l'outil disparaît demain ? Si la réponse est « on recommence tout », le choix est trop risqué pour un outil central.
2. Qui maintient l'application, et c'est écrit où ? Hébergement, sauvegardes, correctifs, évolutions : chaque poste doit avoir un responsable. Notre article sur la maintenance d'une application métier liste ce qu'elle recouvre.
3. Combien l'outil coûtera-t-il sur trois ans, pas sur trois mois ? Abonnements par utilisateur, maintenance, évolutions : le prix de départ dit peu de chose.
4. Pouvez-vous voir le résultat avant de vous engager ? Un prototype, une démonstration ou une première version courte valent mieux qu'une promesse.

Pour aller plus loin dans la sélection d'un prestataire, notre guide choisir une agence de développement d'application propose douze questions à poser, et comparer des devis explique comment lire deux propositions côte à côte.

Par où commencer

Si votre projet ressemble au dernier cas, une application dont l'entreprise va dépendre, décrivez votre besoin en quelques lignes. Nous revenons vers vous sous 24 h ouvrées, puis nous vous présentons en visio, sous 5 jours ouvrés, un prototype visuel gratuit. S'il apparaît qu'un outil no-code suffit, nous vous le dirons : c'est aussi une bonne réponse.