Combien de temps pour développer une application métier ?

Pour un outil métier de PME, il faut compter en général de quelques semaines à quelques mois entre la signature et la mise en service. Un studio spécialisé dans les premières versions au périmètre volontairement réduit affiche 4 à 6 semaines. Un outil qui remplace plusieurs fichiers, se branche sur votre comptabilité et reprend des années d'historique demande nettement plus. La durée dépend surtout de trois choses : le nombre de jours de travail réels, la vitesse à laquelle vous validez, et la reprise de vos données.

Cette page vous donne des repères publics, une méthode pour vérifier le planning d'un devis, et ce qui fait déraper les délais dans un sens ou dans l'autre.

Jours de travail et durée au calendrier

Un devis de développement se chiffre en jours de travail, souvent appelés jours-hommes : une journée d'une personne. Le délai que vous vivez, lui, se compte au calendrier. L'écart entre les deux explique la plupart des surprises.

Prenons 40 jours de développement. Avec une seule personne à plein temps, cela représente environ deux mois ouvrés. Avec deux personnes, on pourrait espérer un mois, mais ce n'est jamais aussi simple : il faut se répartir le travail, relire le code de l'autre et assembler les morceaux. Ajouter des développeurs à un projet raccourcit le délai, mais moins vite qu'on ne l'imagine, surtout sur un petit outil.

Viennent ensuite les temps morts, qui ne figurent dans aucun chiffrage : le temps de réponse à une question, la semaine où la personne qui connaît le métier est en congé, l'attente d'un accès à l'API d'un éditeur. Pour comprendre comment un prestataire arrive à son nombre de jours, voyez la page sur le chiffrage en jours-hommes.

Les repères publics disponibles

Il existe peu de statistiques fiables sur la durée des projets de PME. Les chiffres qui suivent sont ceux que des acteurs publient eux-mêmes. Ils donnent des ordres de grandeur, pas des moyennes constatées.

Sources : Zetos, présentation des premières versions ; beta.gouv.fr, l'approche ; Légifrance, arrêté du 30 mars 2021 approuvant le CCAG-TIC, consultés le 22 octobre 2026.

Deux enseignements à en tirer. D'abord, les délais les plus courts du marché concernent des premières versions dont le périmètre a été coupé exprès : quelques écrans, un seul type d'utilisateur, peu de connexions avec d'autres logiciels. Ensuite, l'État lui-même prévoit un à deux mois pour comprendre le besoin avant d'écrire du code, et les marchés publics réservent un mois entier pour vérifier que le logiciel tient la charge au quotidien. Ces deux phases existent aussi dans un projet de PME, même quand le devis ne les nomme pas.

Un exemple chiffré, inventé pour l'illustration

Prenons une entreprise de transport de 30 salariés qui veut remplacer son planning sur tableur par un outil en ligne. L'exemple est fictif et les durées sont des hypothèses, choisies pour montrer comment se construit un calendrier.

• Cadrage : deux semaines pour lister les règles (qui peut modifier un planning, comment se gèrent les absences, quels exports la paie attend).
• Développement : 45 jours de travail, découpés en trois étapes. À une personne principale, cela fait un peu plus de deux mois ouvrés.
• Reprise des données : une semaine pour importer les chauffeurs, les véhicules et les plannings en cours.
• Recette : deux à trois semaines où l'exploitant teste avec ses vrais cas, avec des allers-retours de corrections.
• Démarrage : une semaine en parallèle de l'ancien tableur, le temps de vérifier que rien ne manque.

Au total, environ quatre mois au calendrier pour 45 jours de développement. À titre de repère de prix, 45 jours au tarif journalier moyen d'un développeur indépendant confirmé affiché sur Malt (576 €, relevé le 14 septembre 2026) représentent 25 920 € hors taxes de développement seul. C'est un calcul, pas un devis.

Source : Malt, baromètre des tarifs tech, relevé le 14 septembre 2026.

Ce qui allonge un projet

La plupart des retards tiennent à ce qui entoure le code : les décisions, les données, les autres logiciels.

• Les validations qui traînent. Une maquette qui attend dix jours une réponse décale tout ce qui suit. Désigner une personne qui tranche, avec une heure par semaine réservée au projet, fait gagner des semaines.
• Les règles découvertes en route. « Ah, mais pour les clients export, c'est différent. » Chaque exception oubliée au cadrage se paie pendant le développement. Un cahier des charges même court évite la plupart d'entre elles.
• Les connexions avec d'autres logiciels. Obtenir un accès, comprendre une documentation incomplète, traiter les cas d'erreur de l'autre côté : une intégration prend souvent plus de temps que prévu, et dépend d'un tiers que personne ne maîtrise.
• Les données à reprendre. Des fichiers pleins de doublons et de champs remplis à la main demandent un nettoyage qui peut durer autant qu'une étape de développement. Voyez la page sur la reprise de données.
• Le périmètre qui grossit. Chaque « tant qu'on y est » ajouté en cours de route repousse la date. L'idée peut être bonne, mais elle trouve mieux sa place dans une étape suivante.

Raccourcir le délai sans sacrifier la qualité

Un délai court obtenu en supprimant les tests se paie après la mise en service, quand les erreurs apparaissent devant vos clients ou vos salariés. Il existe des façons plus saines d'aller vite.

• Livrer une première version utile. Le cœur du besoin d'abord, le reste ensuite. Une première version bien choisie se met en service en quelques semaines et commence à rendre service pendant que la suite se construit.
• Reprendre moins d'historique. Trois ans de données au lieu de dix, le reste archivé en lecture seule.
• Brancher l'existant. Signature électronique, paiement, envoi d'e-mails : des services du marché se connectent en quelques jours au lieu d'être redéveloppés.
• Préparer la recette en avance. Écrire vos cas de test pendant le développement, pas après. La page sur la recette d'un logiciel explique comment s'y prendre.

À l'inverse, un planning d'agence de cinq ou six mois pour un outil qui touche la comptabilité, la paie et plusieurs sites n'a rien d'excessif. Si le devis détaille le cadrage, la recette et la reprise de données, ce délai est souvent honnête. Le signal d'alerte est un délai très court pour un périmètre large, sans phase de test visible.

Vérifier le planning d'un devis

Quand vous recevez un devis, le planning mérite autant d'attention que le prix. Voici les points à contrôler avant de signer.

• Le planning distingue-t-il cadrage, développement, reprise des données, recette et mise en service ?
• Le nombre de jours de développement est-il indiqué, et combien de personnes y travaillent ?
• Le temps de recette de votre côté est-il prévu, avec une durée réaliste pour vos salariés ?
• Les dépendances extérieures sont-elles listées (accès à un logiciel tiers, données à fournir, validation d'un expert-comptable) ?
• Que se passe-t-il si le prestataire est en retard : pénalités, report sans frais, possibilité d'arrêter ?
• Que se passe-t-il si c'est vous qui êtes en retard pour valider ou fournir des données ?
• Chaque étape a-t-elle une date et un contenu vérifiable ?

Dans ma façon de travailler, le prix est fixe et découpé en étapes, chacune avec son contenu et sa date. Vous réglez une étape une fois livrée, testée et validée, et vous pouvez arrêter après n'importe laquelle. Si vous avez déjà un devis, je le lis et vous réponds sous 48 heures ouvrées avec un prix et un calendrier pour le même travail, ou avec les questions qui me manquent. Les repères de prix sont sur la page prix d'un logiciel métier sur mesure.