Application métier sur mesure en PME : comment savoir si votre cas le justifie

Un fichier Excel partagé qui se bloque en écriture dès que deux personnes l'ouvrent. Une commande ressaisie trois fois, dans le devis, dans le logiciel de gestion, puis dans le tableau de suivi. Ou une pile d'abonnements mensuels dont plus personne ne sait exactement ce qu'ils couvrent. Trois situations ordinaires, et la même question au bout : faut-il faire développer une application métier sur mesure pour votre PME ?

Avant d'en parler à qui que ce soit, un dirigeant veut savoir deux choses : si son cas le justifie vraiment, et dans quel ordre de grandeur ça se chiffre. Cet article est une grille de décision, écrite pour un dirigeant de PME normande qui arbitre seul, sans direction informatique et sans référent outil dans l'équipe. Elle vous donne aussi le droit de ne pas développer.

Deux mots de vocabulaire, et on passe à la décision. Le SaaS générique, ce logiciel en ligne payé par utilisateur et par mois, vous demande de vous adapter à lui, ce qui convient très bien tant que votre processus ressemble à celui de tout le monde. Le progiciel ou l'ERP se paramètre dans un cadre déjà posé, et couvre la plus grande partie de vos besoins avec un outil qui en fait beaucoup plus que nécessaire. Le développement sur mesure épouse votre processus, ne traite que ce que vous faites vraiment, et vous en êtes propriétaire. La vraie question est de savoir si votre entreprise a besoin de son propre outil.

Application métier sur mesure en PME : ce qui change sans service informatique

Une PME normande n'a le plus souvent ni direction informatique, ni service dédié, ni même un salarié identifié comme le référent des outils. Recruter un profil technique en interne y est long, coûteux et rarement justifié pour un seul logiciel. Cette contrainte déplace complètement les critères de choix.

• Utilisable sans formation : si l'outil a besoin d'un manuel, il est déjà perdu. Personne ne sera là pour former le remplaçant ou le nouvel arrivant dans six mois.
• Capable de survivre au départ du prestataire : propriété du code, accès aux serveurs, documentation. Un outil que vous ne pouvez confier à personne d'autre a une durée de vie limitée.
• Capable de cohabiter avec l'existant : votre logiciel de gestion, de comptabilité ou de production reste en place. Un outil qui prétend tout remplacer d'un coup annonce surtout un projet qui n'aboutira pas.

Les signaux qu'Excel (ou votre SaaS) ne suffit plus

Reste à vérifier chacun de ces signaux sans se raconter d'histoire. Les points ci-dessous se testent cette semaine, avec un chiffre à la clé.

• Le fichier bloqué en écriture : comptez, sur la semaine qui vient, combien de fois quelqu'un a dû attendre qu'un collègue ferme le classeur, ou a travaillé sur une copie de son côté.
• Les versions concurrentes : cherchez dans votre dossier partagé combien de fichiers portent le même nom avec un suffixe : « final », « v2 », « vraiment final ». Dès qu'il y en a plusieurs, la donnée de référence n'existe plus.
• La ressaisie d'un outil à l'autre : listez les informations que quelqu'un tape deux fois, dans le logiciel de gestion puis dans le tableau de suivi. Comptez les occurrences sur une semaine réelle, jamais de mémoire.
• La dépendance à une seule personne : demandez-vous qui sait faire la manipulation hebdomadaire que personne d'autre ne touche, l'export de fin de semaine, la relance des impayés, le rapprochement. Si la réponse tient en un seul prénom, comptez les tâches que personne d'autre ne sait faire à sa place.
• L'abonnement payé pour trois champs : regardez votre facture mensuelle par utilisateur, puis comptez les écrans ou les fonctions réellement ouverts dans le mois. Le rapport entre les deux est souvent parlant.
• L'exigence d'un client ou d'un donneur d'ordre : traçabilité, numéro de lot, preuve de contrôle, délai d'accusé de réception. Un négoce qui perd des consultations sur ce motif tient là un problème d'outil. Comptez les consultations perdues ou déclinées sur ce motif dans les douze derniers mois.
• Le tableau de bord fabriqué à la main : chronométrez le temps passé chaque mois à assembler le reporting. Un bureau d'études qui y consacre une journée par mois y consacre douze journées par an.

Chiffrez le coût de votre situation actuelle avant de demander le moindre devis

Cette étape prend deux semaines, ne demande aucun outil particulier, et sert ensuite à juger n'importe quel devis.

1. Listez les tâches de rattrapage

   Tout ce qui n'est ni de la vente, ni de la production : ressaisie, vérification, correction d'erreur, relance interne, fabrication de tableau.

2. Mesurez le temps réel sur deux semaines

   En le notant au fil de l'eau, jamais de mémoire à la fin. Le temps estimé de tête reste très en dessous du temps réellement mesuré, parfois dans des proportions qui surprennent.

3. Valorisez au coût employeur

   Le brut annuel plus les charges patronales, dont le total figure sur le bulletin de paie ou chez votre expert-comptable, divisé par le nombre d'heures travaillées dans l'année. Pour vous-même, prenez votre rémunération totale rapportée à vos heures réelles. Si le dirigeant et une assistante sont concernés, chaque heure vaut son propre taux.

4. Additionnez, puis projetez le statu quo sur trois ans

   Le temps valorisé plus les abonnements mensuels, multipliés par trente-six mois. Vous tenez le coût de ne rien changer.

5. Projetez le sur-mesure sur les mêmes trois ans

   Tant que vous n'avez pas de devis, posez-y le haut de la fourchette publique donnée plus bas, 30 000 €, plus 36 mois de maintenance au tarif d'entrée, plus quelques jours de votre temps et de celui de vos équipes pour le cadrage et les tests. Vous remplacerez ces chiffres par ceux du devis quand vous l'aurez. Comparez ce total au précédent.

Deux précautions avant de conclure. Un outil ne fait pas disparaître tout le temps que vous venez de mesurer : une part subsiste, entre la saisie initiale, les contrôles et les cas particuliers. Faites donc le calcul deux fois, une fois en supposant que l'outil récupère la moitié du temps mesuré, une fois les trois quarts.

Ces deux hypothèses sont arbitraires et assumées comme telles : si la décision est la même dans les deux cas, elle est solide ; si elle bascule de l'une à l'autre, c'est que le projet est trop juste et qu'il faut réduire le périmètre avant d'aller plus loin. Donnez-vous enfin une règle avant de regarder les chiffres : si le sur-mesure ne s'équilibre pas sur trois ans, la réponse est non et vous venez d'économiser un projet ; s'il s'équilibre juste sur trois ans, réduisez le périmètre ou renoncez ; s'il s'équilibre nettement avant, la discussion mérite d'être ouverte.

Cette comparaison sur trois ans vaut au-delà des applications métier. C'est le même calcul de coût total sur trois ans que pour une automatisation ou un agent IA : coût initial plus cumul des récurrents, face à la valeur du temps récupéré.

Les quatre cas où il ne faut justement pas développer

Peu de guides disent quand s'abstenir. C'est pourtant la moitié de la réponse.

• Le volume est trop faible : si la tâche revient cinq fois par mois et prend dix minutes, le temps gagné ne remboursera jamais le développement, quel que soit l'agacement qu'elle provoque. Un artisan qui édite quinze devis par mois a surtout un problème de modèle de devis.
• Le processus est encore instable : on ne fige pas dans du code une façon de travailler qui change tous les mois. Stabilisez d'abord, sur papier ou dans un tableur, avec un repère simple : un processus écrit et tenu tel quel pendant trois mois est prêt.
• Une seule personne est concernée : le sur-mesure prend son sens quand plusieurs personnes doivent partager la même donnée au même moment. Pour un poste isolé, un meilleur usage de l'outil existant suffit généralement.
• Le domaine impose un logiciel réglementé ou certifié : la facturation en premier lieu, où le passage par une plateforme agréée n'est pas négociable, et l'encaissement de particuliers, qui suppose un logiciel de caisse certifié. La paie et la comptabilité relèvent, elles, de formats et d'obligations déclaratives qu'un outil maison n'a aucun intérêt à réécrire.

Sur ce dernier point, la réforme en cours ne laisse aucune marge d'interprétation : le passage par une plateforme agréée est obligatoire, et développer sa propre chaîne d'émission en dehors de ces plateformes serait une impasse. Connecter votre outil interne à cette plateforme reste en revanche tout à fait possible.

Dans ces quatre situations, la bonne réponse est ailleurs : mieux utiliser ce que vous avez déjà payé, réorganiser une étape, ou poser une automatisation légère. Un prestataire qui le voit et ne vous le dit pas ne vous rend pas service.

Sur mesure, progiciel du marché, ou couche autour de l'existant ?

Cette question explique aussi la largeur des fourchettes de prix : elles mesurent des périmètres, rien d'autre. Et le cas que nous rencontrons le plus souvent en PME consiste à laisser le logiciel métier en place et à développer la couche qui manque autour : saisie unique, tableau de bord, portail client.

Votre logiciel actuel expose-t-il une API, ou seulement des exports ?

C'est la question qui décide du périmètre, du budget et du confort d'usage, et elle se pose sans être technicien. Une API, c'est une porte d'entrée officielle par laquelle deux logiciels échangent automatiquement, dans les deux sens, en temps réel. Un export, c'est un fichier que quelqu'un télécharge, à un rythme choisi, avec une reprise manuelle dès qu'une ligne pose problème. Le premier cas permet la saisie unique, le second impose un décalage et une surveillance.

La difficulté d'un outil interne se loge dans ce qu'il faut connecter proprement aux logiciels déjà en place : messagerie, logiciel de gestion, comptabilité.

ERP ou logiciel sur mesure pour une PME : comment trancher

Regardez d'abord votre façon de travailler. Si elle ressemble à celle de vos concurrents, le progiciel l'emporte sans discussion : il a été amorti par tous ses autres clients et vous ne paierez jamais son développement. Si elle est au contraire ce qui vous différencie, chaque écart au standard se paie en paramétrage, en licences et en contorsions quotidiennes, jusqu'au moment où l'addition dépasse celle d'un développement ciblé. Ce basculement se mesure, en additionnant les heures perdues à contourner l'outil. Pendant la démonstration du progiciel, comptez les étapes de votre processus que le vendeur a contournées ou renvoyées à un paramétrage ultérieur. Au-delà de deux ou trois, vous êtes hors standard.

Reste le cas du besoin partiel. Beaucoup de dirigeants découvrent, une fois la démonstration terminée, qu'ils n'ont besoin que d'un coin de l'ERP qu'on leur propose. Ils en paieront pourtant la totalité, licences comprises, et hériteront de sa complexité entière, y compris pour les modules que personne n'ouvrira. Dans cette situation, garder le logiciel métier existant et développer seulement la couche manquante coûte moins cher, s'installe plus vite et se décide sans avoir à convaincre toute l'entreprise.

Commencer par une automatisation no-code, et savoir quand on en sort

Une automatisation Make ou n8n bien posée est très souvent la bonne première marche, pour quelques dizaines d'euros par mois et quelques jours de mise en place. Une bonne partie des PME que nous croisons n'a jamais eu besoin d'aller plus loin. Cet article commence là où celui-là s'arrête.

Vous en êtes sorti quand empiler un scénario de plus coûte plus cher que de développer. Les symptômes se repèrent facilement.

• Le nombre de scénarios est devenu ingérable : plus personne ne sait ce qui tourne, ni ce qui casse ailleurs quand on modifie une étape.
• Les données manipulées sont devenues sensibles : coordonnées de clients, éléments de paie, informations contractuelles. Elles transitent alors par des plateformes tierces dont il faut vérifier l'hébergement et le contrat, et cette vérification devient plus lourde que l'outil.
• Le cumul des abonnements dépasse l'amortissement d'un développement : additionnez la plateforme d'automatisation et les SaaS qu'elle relie, projetez sur trois ans, et comparez.

Combien coûte une application métier sur mesure, et combien de temps ça prend

Les fourchettes que vous lisez d'un site à l'autre traduisent des périmètres sans commune mesure : un outil qui traite un seul processus n'a rien à voir avec un système de gestion complet refait sur mesure. Tant que le périmètre n'est pas écrit, aucun chiffre n'a de sens.

Notre repère public, le même que celui affiché sur nos pages de services : une application web ou un espace client se situe entre 8 000 € et 30 000 € selon le périmètre. Une première version utilisable, volontairement étroite, qui sert réellement tous les jours, entre dans le bas de cette fourchette. Le détail des fourchettes par type de projet, du site vitrine à la boutique en ligne, est dans notre article sur le prix d'un site internet pour une PME. Quatre éléments font ensuite bouger le curseur.

• Le nombre de processus couverts : un seul, bien délimité, ou toute la chaîne du devis à la facture.
• Le nombre de profils d'utilisateurs : un usage interne homogène, ou un portail ouvert à vos clients avec ses règles d'accès et ses messages automatiques.
• Les connexions aux outils existants : aucune, une API propre, ou des reprises de fichiers avec tous leurs cas particuliers.
• La reprise de l'historique : repartir de zéro ne coûte pas la même chose que récupérer dix ans de données hétérogènes, avec leurs doublons et leurs formats improbables.

Une remarque au passage sur les chiffres d'impact que vous croiserez ailleurs, du type moins 40 % de temps administratif : aucun de ceux que nous avons vus n'est sourcé. Le seul chiffre solide sur votre projet reste celui que vous mesurerez vous-même, avec la méthode donnée plus haut.

Côté délais, voici une fourchette qualifiée. Un prototype cliquable, qui sert à se mettre d'accord sur des écrans plutôt que sur un document, se produit en quelques semaines. Une première version réellement utilisable au quotidien va de quelques semaines pour un périmètre étroit à quelques mois dès qu'il y a des connexions et plusieurs profils d'utilisateurs.

Si vous voulez simplement un ordre de grandeur avant d'en parler à quiconque, notre estimateur de budget permet de se situer en quelques minutes, sans adresse e-mail à laisser.

Ce qu'il faut exiger par écrit dans le devis

Voici la question que peu de dirigeants posent avant de signer, et qui devient urgente trois ans plus tard : que se passe-t-il si le prestataire disparaît, arrête son activité, ou devient simplement injoignable ? Pour un site vitrine, c'est ennuyeux. Pour l'outil qui porte votre travail quotidien, c'est un risque d'entreprise.

Les quatre points de réversibilité à faire écrire noir sur blanc

• La propriété du code, cédée à votre société, et non une simple licence d'utilisation. Symptôme d'un contrat qui ne le prévoit pas : on vous refuse l'accès au code, ou on vous le facture, au moment précis où vous voulez partir.
• Le dépôt du code sur un compte qui vous appartient, avec vos accès administrateur. Symptôme : le code vit uniquement chez le prestataire et personne chez vous n'a jamais vu à quoi ressemble ce dépôt.
• Les accès aux serveurs et à la base de données à votre nom. Symptôme : changer de prestataire obligerait à tout réinstaller ailleurs.
• Une documentation d'installation et de reprise, suffisante pour qu'un autre développeur reprenne sans avoir besoin du premier. Symptôme : toute la connaissance du projet tient dans la tête d'une seule personne.

Sur ce premier point, la formulation compte autant que l'accord de principe. Demandez une clause de cession explicite plutôt qu'une phrase générale sur la propriété de l'application, et faites-la relire par un avocat avant de signer : c'est le bon interlocuteur sur une clause de propriété intellectuelle, et cet article ne remplace pas un conseil juridique.

Ces quatre points se vérifient avant de signer, et ils pèsent autant que le prix dans le choix du prestataire qui développera l'outil. Test immédiat, à poser dès le premier rendez-vous : demandez à quel nom sera ouvert le compte d'hébergement. Si la réponse est le nom du prestataire, vous savez déjà où vous en êtes.

Chez Digiblock, la propriété du code et des données revient au client, sur les sites comme sur les applications métier et SaaS sur-mesure. C'est notre position de départ, écrite dans le devis.

Où vivent vos données et qui y a accès

Un outil interne contient des données de clients et de salariés. C'est donc un sujet de dirigeant, et un sujet RGPD, qu'on ne délègue pas sans regarder. Commencez par demander où les données sont hébergées, en exigeant le nom de l'hébergeur et le pays du centre de données plutôt que le mot cloud, qui ne veut rien dire tout seul. Une réponse dans l'Union européenne vous évite la question des transferts de données hors UE. Demandez ensuite qui, chez le prestataire, peut techniquement lire la base, avec quelle traçabilité, et ce qui se passe quand l'une de ces personnes quitte l'entreprise.

La troisième question est celle qu'on oublie et qui coûte le plus cher : les sauvegardes ont-elles déjà été restaurées pour de vrai ? Une sauvegarde jamais restaurée reste une hypothèse. Faites préciser la fréquence, la durée de rétention et la date du dernier test de restauration réel, et notez la réponse : elle vous en dira plus long sur le sérieux du prestataire que n'importe quelle page de références.

Ces questions relèvent de l'infrastructure, c'est-à-dire de là où vit l'application une fois livrée : hébergement, nom de domaine, certificats, sauvegardes et supervision. C'est le poste qu'on oublie au moment du devis et qu'on découvre au premier incident.

Le risque principal : que l'équipe ne s'en serve pas

Ce qui fait échouer un outil interne, bien plus souvent que le bug, c'est l'abandon. Le budget est dépensé, l'outil existe, et six mois plus tard le tableur est revenu par la fenêtre parce qu'il allait plus vite pour le cas du jour. Tout se joue au cadrage.

• Associez deux utilisateurs réels dès le cadrage, pas seulement le dirigeant. Celui qui saisit tous les jours connaît les exceptions dont personne ne parle en réunion.
• Livrez une première version volontairement étroite, mais réellement utilisée tous les jours, plutôt qu'un outil complet livré d'un bloc six mois plus tard.
• Gardez une porte de sortie vers l'ancien fichier pendant quelques semaines. Interdire l'ancien outil du jour au lendemain produit du contournement.

Quand votre outil s'appuie sur un service que vous ne contrôlez pas

Un outil interne repose souvent sur un service extérieur : une messagerie, une plateforme d'envoi, un service de paiement, l'API de votre logiciel de gestion. Vous héritez alors de ses règles, de ses tarifs et de son calendrier, sans prise dessus. La question se pose au cadrage, jamais au moment de l'incident : que devient votre outil si ce service change ses conditions, ses prix, ou la façon dont il valide ce que vous lui envoyez ?

Deux réflexes limitent la casse. Demandez à votre prestataire d'isoler cette dépendance dans une seule partie de l'application, pour pouvoir la remplacer sans tout réécrire, et vérifiez que vos données restent stockées dans votre base plutôt que seulement chez le service en question : c'est ce qui vous laisse le choix le jour où il faudra changer.

Notre propre cas : les demandes clients qui nous arrivent par WhatsApp vivaient dans un seul téléphone. Nous avons développé, pour notre usage interne, le back-office qui les centralise et depuis lequel nous répondons. Le plus coûteux n'a pas été d'écrire l'outil, mais de suivre les règles de la plateforme : pour garder un accès automatisé au même numéro, il a fallu renoncer à l'application mobile que nous utilisions jusque-là et réorganiser la façon de répondre.

Par où commencer, concrètement

Dans cet ordre, et sans brûler d'étape. Les deux premiers mouvements ne nécessitent aucun prestataire, et ils suffisent souvent à conclure.

1. Mesurez pendant deux semaines

   La méthode de chiffrage vue plus haut, notée au fil de l'eau. Sans ce chiffre, vous ne saurez pas juger un devis, quel qu'il soit.

2. Écrivez le processus en une page

   Tel qu'il se passe vraiment aujourd'hui, exceptions comprises. Ce sont les exceptions qui font le prix, et elles n'apparaissent jamais dans la version idéalisée.

3. Faites chiffrer ce périmètre précis par deux prestataires

   Le même document pour les deux. Deux devis établis sur un périmètre écrit se comparent ligne à ligne.

Un dernier repère sur le choix de l'interlocuteur : le bon prestataire doit être capable de vous dire de ne pas développer. Digiblock travaille à distance sur toute la Normandie et au-delà ; le devis est gratuit, et vous l'avez sous 24 heures une fois votre page de processus reçue et l'échange de cadrage fait. Si la mesure des deux semaines montre que le jeu n'en vaut pas la chandelle, nous vous le dirons aussi clairement que dans cet article. Nos réalisations publiées montrent le reste.

Questions fréquentes

Qu'est-ce qu'une application métier sur mesure, par rapport à un logiciel du marché ?

Avec un logiciel du marché, SaaS ou progiciel, votre entreprise s'adapte à l'outil et à sa logique. Avec une application sur mesure, l'outil est écrit pour votre processus et ne traite que ce que vous faites réellement, cas particuliers compris. La contrepartie est simple : vous êtes seul à l'amortir, donc le sur-mesure ne se justifie qu'à partir d'un certain volume de temps perdu, ce que la méthode de chiffrage de cet article permet de vérifier.

Comment chiffrer ce que me coûte ma situation actuelle ?

En mesurant plutôt qu'en estimant. Listez les tâches de rattrapage, notez le temps passé au fil de l'eau pendant deux semaines, valorisez chaque heure au coût employeur de la personne concernée, ajoutez les abonnements, puis projetez sur trois ans. Vous obtenez le coût de ne rien changer, à comparer au coût total du sur-mesure sur la même période.

Dans quels cas ne faut-il pas développer d'application métier ?

Quatre situations doivent vous arrêter net : un volume trop faible pour rembourser le développement, un processus qui change encore tous les mois, un besoin qui ne concerne qu'une seule personne, et un domaine où la réglementation impose un logiciel agréé ou certifié, la facturation et l'encaissement en tête. Dans chacune d'elles, la bonne réponse est ailleurs : mieux utiliser ce que vous avez déjà payé, réorganiser une étape, ou poser une automatisation légère.

Comment éviter que l'équipe abandonne l'outil au bout de six mois ?

En associant au cadrage les personnes qui saisissent tous les jours, pas seulement le dirigeant, en livrant une première version étroite mais réellement utilisée, et en laissant l'ancien fichier accessible quelques semaines au lieu de l'interdire du jour au lendemain. L'indicateur à suivre les trois premiers mois : le nombre de jours où l'ancien fichier n'a pas été rouvert.

Que coûte l'application une fois livrée, en hébergement et en maintenance ?

L'hébergement d'une application interne va de quelques euros à quelques dizaines d'euros par mois selon le nombre d'utilisateurs et le volume de données. Chez nous, la maintenance et les évolutions démarrent à 79 € par mois, avec un périmètre discuté projet par projet. Le point à retenir : ce poste doit figurer dans le devis initial et entrer dans votre calcul sur trois ans, sinon il arrivera en surprise.

Peut-on faire développer une application métier avec une agence qui travaille à distance ?

Oui. Les ateliers de cadrage se tiennent en visio avec les personnes concernées, les retours se font sur une version en ligne que chacun ouvre de son poste, et les corrections se voient en quelques jours. Ce qui compte : la réactivité, la clarté du périmètre écrit et la propriété du code. Digiblock intervient à distance sur toute la Normandie et au-delà.