Développement application sur mesure : le vrai prix

Un développement d'application sur mesure ne commence pas par du code, il commence par un tableur Excel que plus personne n'ose ouvrir. Vous voyez lequel. Celui avec quatorze onglets, des cellules en jaune que seule la comptable comprend, et une macro écrite en 2017 par un stagiaire parti depuis longtemps. Chaque lundi, quelqu'un passe deux heures à recopier des chiffres d'un outil à l'autre, en pestant, en se trompant une ligne sur vingt, et en sachant très bien que tout ça pourrait se faire tout seul. Alors on se dit qu'il faudrait « faire une appli ». Facile à dire.

Bon. Avant de signer quoi que ce soit, voilà ce que les guides en ligne ne vous disent pas : combien de jours ça représente vraiment, à qui appartient le code une fois payé, et à partir de quel seuil ça vaut le coup.

La réponse courte : le développement d'application sur mesure consiste à concevoir un logiciel (web ou mobile) taillé pour vos processus, au lieu d'adapter vos processus à un outil du marché. Ça se justifie quand un outil existant vous coûte plus en temps perdu qu'il ne rapporte, et quand vous savez nommer précisément la tâche à remplacer.

Au sommaire :

• De quoi on parle vraiment
• Le test du tableur
• Ce que Google vous montre, et ce qu'il oublie
• Le volume de travail, en jours
• À qui appartient le code
• Six mois après la mise en ligne
• Questions fréquentes
• L'arbitrage quand le budget ne suit pas

Développement d'application sur mesure : de quoi on parle vraiment ? {#definition}

Le mot « application » recouvre trois réalités très différentes, et c'est la première source de malentendu avec un prestataire.

L'application métier interne

Un outil web utilisé par vos équipes : planning des chantiers, suivi des interventions, gestion des devis, stock. Personne d'extérieur ne la voit. C'est le cas le plus fréquent dans les TPE et PME, et souvent le plus rentable, parce qu'il remplace du temps humain mesurable.

L'application client

Un espace en ligne où vos clients passent commande, suivent un dossier, prennent rendez-vous. Ici, l'ergonomie compte énormément. Un client agacé ne revient pas. Un salarié agacé, lui, revient lundi.

L'application mobile publiée sur les stores

Celle qu'on télécharge sur l'App Store ou Google Play. La plus chère à produire et à maintenir, parce qu'il faut suivre les mises à jour d'Apple et de Google, valider les publications, gérer deux écosystèmes. D'expérience, la moitié des demandes « on veut une appli mobile » se règlent très bien avec une application web responsive, utilisable sur téléphone sans passer par un store.

Le truc, c'est que ces trois projets n'ont ni le même budget, ni le même calendrier, ni les mêmes risques, si bien que quand un devis dit juste « développement d'une application », sans préciser laquelle des trois, il manque déjà la moitié de l'information.

Le test du tableur : savoir si vous en avez vraiment besoin {#tableur}

Voilà la question qu'on pose en premier, avant toute discussion technique : quelle tâche précise cette application va-t-elle faire disparaître ?

Si la réponse est floue (« moderniser l'entreprise », « être plus digital »), on s'arrête là. Pas d'application. Sinon, c'est un jouet coûteux. Abandonné au bout de trois mois.

Si la réponse est précise, on peut chiffrer. Cas typique : une entreprise de rénovation à Créteil avec six techniciens. Chaque soir, le chef d'équipe ressaisit les bons d'intervention papier dans un tableur, puis la secrétaire les recopie dans le logiciel de facturation. Trente minutes pour l'un, quarante-cinq pour l'autre. Plus d'une heure par jour ouvré. Environ 250 heures par an, juste à recopier. Là, on a quelque chose à remplacer.

Trois signaux qui disent que l'outil du marché ne suffit plus :

• vous payez des abonnements à quatre logiciels qui ne se parlent pas, et quelqu'un fait le pont à la main
• un concurrent sérieux ou un client grand compte vous demande un portail que votre logiciel actuel ne sait pas produire
• votre façon de travailler est justement ce qui vous différencie, et l'outil standard vous oblige à travailler comme tout le monde

Avant d'aller plus loin, vérifiez quand même qu'un outil existant ne fait pas déjà le travail. Pour la relation client, par exemple, notre comparatif des CRM pour TPE couvre l'essentiel des besoins sans une ligne de code, et dans le bâtiment, le comparatif CRM BTP montre que beaucoup de métiers sont déjà bien servis par des outils qui existent depuis des années.

Perso, je trouve qu'on construit trop d'applications. La meilleure réponse est parfois un outil à 30 € par mois correctement paramétré.

Ce que Google vous montre sur cette requête, et ce qu'il oublie {#serp}

Tapez « développement application sur mesure » et regardez qui répond. Un éditeur de plateforme américain qui vous explique, sur 2 800 mots, pourquoi il faut… utiliser sa plateforme. Des agences qui publient des guides en cinq étapes (cadrage, design, développement, tests, maintenance). Des places de marché où un freelance propose de « développer votre application web » comme on commande une pizza.

Ces pages ne sont pas fausses. Elles sont vides là où ça compte.

Sur les guides les mieux placés que nous avons relus, aucun ne donne un seul prix, aucun ne présente de tableau, et aucun ne parle de la propriété du code. On vous explique longuement ce qu'est une application sur mesure (vous le saviez déjà, sinon vous n'auriez pas tapé la requête) et on s'arrête pile au moment où la question devient gênante : combien, combien de temps, et qu'est-ce qui m'appartient à la fin.

Pour être juste, la requête elle-même est peu disputée : environ 210 recherches par mois en France, une difficulté Semrush de 14 sur 100, et un coût par clic à zéro. Autrement dit, personne ne se bat pour cette page avec de la publicité. D'où des réponses aussi génériques. Elles n'ont jamais eu besoin d'être meilleures.

On va pas se mentir : un guide qui ne chiffre rien vous laisse seul face au premier devis, sans aucun moyen de savoir si les 60 jours qu'on vous annonce sont raisonnables ou si on vous facture le double de ce que le projet demande. Et c'est précisément là que les projets partent en vrille.

Combien de jours de travail pour une application sur mesure ? {#jours}

Un forfait cache tout. Des jours de travail, eux, se discutent. Voilà donc les ordres de grandeur qu'on retient, d'expérience, pour une application métier web de taille TPE/PME. Ce sont des fourchettes de jours, pas des promesses : chaque projet se recadre.

Poste	Application interne simple (3-5 écrans)	Application métier complète (10-20 écrans)
Cadrage, ateliers, maquettes	3 à 5 jours	8 à 15 jours
Design de l'interface	2 à 4 jours	6 à 12 jours
Développement	10 à 20 jours	40 à 80 jours
Connexions (facturation, CRM, comptabilité)	0 à 3 jours	5 à 15 jours
Tests et recette avec vos équipes	2 à 4 jours	8 à 15 jours
Mise en ligne, formation	1 à 2 jours	3 à 5 jours

Chaque jour se facture au tarif journalier. C'est là que la géographie pèse. En Île-de-France, les écarts sont nets :

• une agence de grande couronne (77, 78, 91, 95) facture 350 à 450 € HT la journée
• une agence de petite couronne (93, 94), 400 à 500 € HT
• une agence à Paris intra-muros ou dans le 92, 500 à 650 € HT
• un freelance confirmé, 400 à 600 € HT
• pour du mobile natif, un développeur mobile confirmé à Paris se situe entre 400 et 670 € HT, et un studio mobile parisien intégré entre 500 et 900 € HT

Multipliez vous-même les jours du tableau par le tarif du segment qui vous intéresse. C'est pas sorcier, et ça vous donne une base pour lire n'importe quel devis.

Ce qui fait exploser le nombre de jours

Rarement le développement lui-même. Le plus souvent, c'est le cadrage bâclé : on découvre en cours de route que le « bon d'intervention » existe en trois versions selon le type de client, que la comptabilité veut un export dans un format précis, que le patron veut signer sur tablette. Chaque découverte tardive coûte trois à cinq fois plus cher qu'au moment des maquettes.

Du coup, ce cadrage à 5 jours qui paraît cher ? Souvent l'économie la plus rentable du projet.

Le code vous appartient-il, une fois la facture payée ? {#propriete}

Non. Pas automatiquement.

C'est la section qu'aucun des guides en tête de Google ne traite, et pourtant c'est celle qui coûte le plus cher quand on l'ignore. En droit français, un logiciel développé par un prestataire extérieur (agence ou freelance) reste la propriété de son auteur tant qu'un contrat ne prévoit pas une cession de droits. Le Code de la propriété intellectuelle (article L131-3) exige que cette cession soit écrite et précise : quels droits, pour quel usage, sur quel territoire, pour quelle durée. La règle qui attribue le logiciel à l'employeur (article L113-9) ne joue que pour vos salariés, pas pour un prestataire.

Concrètement ? Vous pouvez avoir tout payé. Et ne pas avoir le droit de confier l'application à un autre développeur.

Le scénario qu'on voit revenir : une PME du Val-de-Marne fait développer son outil de planning par un freelance. Deux ans plus tard, le freelance change de métier. Le code est sur son serveur, les accès à l'hébergement sont à son nom, et le contrat tient sur une page sans un mot sur les droits. La PME doit soit négocier, soit tout refaire. Ça me rend dingue. Un paragraphe suffisait.

Ce que le contrat doit prévoir, noir sur blanc

• la cession des droits patrimoniaux sur le code spécifique développé pour vous, avec les mentions de l'article L131-3
• la livraison du code source dans un dépôt Git dont vous êtes propriétaire (pas seulement « accessible sur demande »)
• les accès administrateur à l'hébergement, au nom de domaine et aux comptes des stores, à votre nom
• la liste des briques open source ou propriétaires utilisées, et leurs licences
• une clause de réversibilité : comment on récupère tout si la collaboration s'arrête

On a détaillé la même logique pour les sites web dans notre article sur le contrat à vérifier avant de lancer un site. Pour une application, l'enjeu est simplement multiplié.

Et la question qui doit alerter ? Si vous demandez « est-ce que je récupère le code source ? » et qu'on vous répond « vous n'en aurez pas besoin », changez de prestataire. Ce n'est pas une question technique, c'est une question de dépendance.

Ce qui se passe six mois après la mise en ligne {#apres}

La plupart des projets ne meurent pas au lancement. Ils meurent doucement, entre le sixième et le dix-huitième mois.

Une application vit dans un environnement qui bouge : les navigateurs se mettent à jour, les bibliothèques de code publient des correctifs de sécurité, Apple et Google changent leurs règles de publication chaque année. Et vos équipes, en l'utilisant, découvrent ce qu'elles auraient aimé avoir dès le départ.

D'expérience, il faut prévoir chaque année un volume de maintenance et d'évolutions équivalent à 15 à 20 % des jours du projet initial. Une application métier de 80 jours réclame donc une douzaine de jours par an, rien que pour rester saine et absorber les petites demandes. Une application mobile publiée sur les stores se situe plutôt dans le haut de la fourchette.

Qui budgète ça au départ ? Presque personne.

Le cas de figure classique : une application livrée, payée, adoptée par l'équipe… et jamais mise à jour. Dix-huit mois plus tard, une faille dans une bibliothèque obsolète, un formulaire qui ne s'affiche plus sur les nouveaux iPhone, et l'équipe revient au tableur. Retour à la case départ, avec la facture en plus.

Petit point RGPD au passage : si votre application stocke des données clients, vous restez responsable de leur sécurité, même si c'est le prestataire qui héberge. La CNIL publie un guide de sécurité des données personnelles qui sert de bonne liste de contrôle.

Questions fréquentes sur le développement d'application sur mesure {#faq}

Quelle différence entre une application sur mesure et un logiciel du marché ?

Le logiciel du marché (SaaS) est conçu pour des milliers d'entreprises : vous adaptez votre fonctionnement à l'outil, et vous payez un abonnement. L'application sur mesure est conçue pour vos processus : vous payez la conception, puis la maintenance, et vous n'êtes plus limité par les choix d'un éditeur.

Combien de temps faut-il pour développer une application sur mesure ?

Application interne simple : quatre à huit semaines. Application métier complète : trois à six mois, parfois davantage quand les connexions avec vos logiciels existants réservent des surprises, ce qui arrive bien plus souvent qu'on ne l'imagine au moment du devis. Ce qui retarde le plus, ce n'est pas le développement, c'est la disponibilité de vos équipes pour les ateliers et la recette.

Faut-il une application mobile ou une application web ?

Dans la majorité des projets internes, une application web responsive suffit : elle fonctionne sur ordinateur, tablette et téléphone, sans passer par les stores. L'application mobile native se justifie si vous avez besoin du mode hors-ligne poussé, de notifications, de l'appareil photo ou du GPS de façon intensive.

Le no-code peut-il remplacer le développement sur mesure ?

Pour un premier prototype ou un outil interne simple, souvent oui. Le no-code montre ses limites quand le volume de données grossit, quand les règles métier se compliquent ou quand vous voulez changer de plateforme : vous restez dépendant de l'éditeur de l'outil no-code.

Qui possède le code d'une application développée par une agence ?

Son auteur, sauf cession de droits écrite dans le contrat. Exigez une clause de cession conforme à l'article L131-3 du Code de la propriété intellectuelle et la livraison du code source dans un dépôt à votre nom.

Faut-il choisir un prestataire à Paris pour une entreprise francilienne ?

Pas forcément. Un prestataire de grande couronne facture souvent moins cher à la journée qu'une agence parisienne, pour des compétences comparables. Ce qui compte, c'est la disponibilité pour des ateliers en présentiel pendant le cadrage, et ça, toute l'Île-de-France le permet.

Comment éviter que le projet dérape ?

Un cadrage écrit, des maquettes validées avant la première ligne de code, des livraisons toutes les deux à trois semaines que vos équipes testent vraiment. Et un seul interlocuteur côté entreprise qui a le pouvoir de trancher.

Si le budget ne suit pas : l'arbitrage à faire cette semaine {#arbitrage}

Vous avez lu le tableau des jours, multiplié par un tarif, et le total vous a refroidi. C'est normal. Voilà comment on arbitre, sans tout abandonner.

Reprenez votre chiffre d'heures perdues. Dans le cas de l'entreprise de rénovation plus haut, c'étaient environ 250 heures par an. Multipliez par le coût horaire chargé des personnes concernées : vous obtenez ce que le statu quo vous coûte chaque année. Si ce montant ne couvre pas les jours de développement en deux ou trois ans, maintenance comprise, l'application n'est pas encore justifiée. Dites-le-vous franchement.

Si le calcul tient mais que la trésorerie bloque, découpez. Une application ne se livre pas forcément d'un bloc. Commencez par l'écran qui supprime la tâche la plus pénible. Souvent, la saisie terrain. Mettez-le en production, mesurez, et laissez la suite se financer avec le temps gagné, mois après mois, plutôt que d'avancer tout le budget d'un coup sur des écrans dont personne ne se servira peut-être.

Si le calcul ne tient pas, rabattez-vous sur un outil existant bien paramétré, et gardez l'idée au chaud. Une application faite trop tôt, sur un processus que vous n'avez pas encore stabilisé, coûte deux fois : une fois pour la construire, une fois pour la refaire. D'ailleurs, c'est exactement la même logique que pour un site — notre article sur le coût réel d'une refonte de site montre ce que coûte le fait de reconstruire ce qu'on a lancé trop vite.

Ce soir, faites juste une chose : notez sur une feuille les trois tâches qui se répètent chaque semaine dans votre entreprise, et le temps qu'elles prennent. Si l'une dépasse cinq heures hebdomadaires, vous avez un vrai sujet. Si aucune ne le fait, gardez votre budget pour autre chose.

Chez Minyzia Agency, on préfère vous dire « pas maintenant » que vous vendre une application qui finira au placard.