C’est la question qui revient à presque chaque premier rendez-vous, souvent formulée comme ça : « On nous a proposé un logiciel tout fait, beaucoup moins cher. Pourquoi on développerait quelque chose ? ». C’est une bonne question. Et la réponse honnête, ce n’est pas celle qui nous arrange le mieux commercialement : dans la majorité des cas, la solution du marché suffit. Le sur-mesure ne se justifie que sur un nombre limité de situations, et ces situations se reconnaissent avant d’écrire la première ligne de code. On va vous expliquer comment les repérer.
Ce que « sur mesure » veut dire, et ce que ça ne veut pas dire
Un développement sur mesure, c’est du code écrit pour vos règles de gestion, dont vous êtes propriétaire, et qui ne se facture pas au nombre d’utilisateurs. La définition s’arrête là.
Ce n’est pas un outil sans maintenance : le sur-mesure ne supprime pas l’entretien technique, il vous en transfère la charge. C’est vous, ou votre prestataire, qui suivez les montées de version au lieu de l’éditeur.
Ce n’est pas non plus un correctif à un processus mal défini : un flux de travail flou reste flou une fois codé, simplement il coûte plus cher à modifier. Et ce n’est jamais l’option la plus rapide à mettre en service.
Les trois options en présence
La solution du marché. SaaS ou progiciel, disponible immédiatement, coût d’entrée bas, mises à jour et conformité portées par l’éditeur. En contrepartie, vous adaptez vos processus à l’outil et la facture suit le nombre de postes.
Le sur-mesure. L’outil épouse vos règles au lieu de l’inverse, le code vous appartient, il n’y a ni coût par siège ni dépendance à la feuille de route d’un éditeur. En contrepartie, vous portez le cycle de vie technique de bout en bout et le point d’entrée est plus élevé.
L’assemblage. Un socle du marché — WordPress, WooCommerce, un ERP — plus des développements spécifiques sur les seules zones qui le méritent. C’est de loin le montage qu’on met en place le plus souvent : il concentre l’investissement là où il y a une vraie différence métier et laisse le reste au standard. C’est le cas typique des projets de site vitrine et e-commerce, où seuls le tunnel de commande et les intégrations comptables demandent du spécifique.
Pour un projet en Nouvelle-Calédonie, qu’est-ce qui change ?
La disponibilité de l’intégrateur. Un progiciel métropolitain suppose presque toujours un intégrateur certifié pour le paramétrer et le maintenir. Sur le territoire, il n’existe pas toujours, ou il est seul. Une solution excellente dont personne ici ne sait faire l’entretien est un risque, pas une économie.
Le décalage horaire avec l’éditeur. Neuf à dix heures séparent Nouméa de la métropole selon la saison : un support qui travaille aux heures françaises vous accorde un aller-retour par jour ouvré. Pour un outil au cœur de la facturation ou de la production, c’est une contrainte à inscrire au contrat.
La taille des équipes. L’arbitrage financier classique — « à partir de tant d’utilisateurs, le sur-mesure devient rentable » — se déclenche rarement ici : les effectifs sont plus petits qu’en métropole. Sur ce marché, ce n’est presque jamais le nombre de postes qui justifie le développement, c’est la spécificité du métier.
La fiscalité et les intégrations locales. La plupart des solutions du marché sont conçues autour d’une TVA, d’un plan comptable et de moyens de paiement métropolitains. La TGC, le RIDET, les passerelles de paiement locales et les ERP installés sur le territoire tombent dans la zone où le standard s’arrête. C’est généralement là que se situe le vrai périmètre du développement — le même raisonnement que sur les projets d’automatisation de processus métier.
Le cycle de vie technique. Il s’applique aux deux options, et il ne se négocie pas. PHP 8.2 ne recevra plus de correctifs de sécurité après le 31 décembre 2026, et PHP 8.3 s’arrête au 31 décembre 2027 (calendrier de fin de support PHP). Côté CMS, WordPress 7.1 est sorti le 19 août 2026, et la branche 6.9 n’est plus la version maintenue depuis le 20 mai 2026. Que vous achetiez ou que vous fassiez développer, un budget d’entretien récurrent est déjà engagé par ce calendrier.
Comment on tranche avec nos clients
Votre règle de gestion est-elle réellement spécifique, ou seulement habituelle ? La plupart des « on fait comme ça chez nous » sont des habitudes, pas des contraintes, et elles ne valent pas un développement. Les vraies spécificités tiennent en trois ou quatre règles qu’on peut écrire noir sur blanc.
Combien de personnes utiliseront l’outil dans trois ans ? Si la réponse est « à peu près autant qu’aujourd’hui », le coût par utilisateur ne dérapera pas et l’argument financier du sur-mesure tombe.
Que se passe-t-il si l’éditeur disparaît ou change de tarif ? Si la réponse est « on perd nos données » ou « on paie », vous avez identifié une dépendance. Elle peut être acceptable, mais elle doit être décidée, pas subie.
Qui porte l’outil en interne ? Un développement sur mesure a besoin d’un interlocuteur côté client capable d’arbitrer. Sans ce rôle, le projet dérive quel que soit le prestataire.
Les cas où la solution du marché est clairement le bon choix
- Comptabilité, paie, gestion commerciale standard : le métier est normé, l’éditeur porte la conformité.
- Site vitrine, blog, e-commerce classique : le socle existe, il est mature et bien documenté.
- Besoin urgent, périmètre incertain : un abonnement se résilie, un développement ne se rembourse pas.
- Équipe réduite sans référent technique interne pour arbitrer et suivre le produit.
- Processus que vous êtes prêt à adapter à l’outil plutôt que l’inverse.
Les cas où il faut passer au sur-mesure
- Votre avantage concurrentiel tient dans la règle de gestion elle-même, pas dans son exécution.
- Aucune solution du marché ne gère votre contrainte locale sans contournement manuel quotidien.
- Le coût par utilisateur devient structurellement supérieur au coût d’un outil possédé.
- Vous devez interconnecter plusieurs systèmes existants qu’aucun éditeur ne relie nativement.
- La dépendance à un éditeur unique fait peser un risque réel sur l’activité.
Le budget, sans tarif ferme
Sans rentrer dans des tarifs fixes qui dépendent toujours du périmètre, voilà les ordres de grandeur qui comptent. Une solution du marché combine un coût d’entrée faible et une dépense récurrente qui croît avec les usages. Le sur-mesure inverse la courbe : point d’entrée nettement plus élevé, dépense récurrente plus basse et surtout maîtrisée. L’assemblage se situe entre les deux.
La ligne qu’on oublie systématiquement de budgéter, c’est la maintenance annuelle. Elle existe dans les trois cas. Sur une solution du marché elle est incluse dans l’abonnement, donc invisible ; sur un développement possédé elle est explicite, donc perçue comme un surcoût alors qu’elle a toujours été là. Un projet développé sur mesure sans ligne d’entretien annuel dans le budget initial n’est pas budgété correctement — le calendrier de fin de support cité plus haut suffit à le démontrer. Le même raisonnement vaut pour une application mobile, où les magasins d’applications imposent leur propre rythme de mise à jour.
Questions fréquentes
Quand faut-il développer un logiciel sur mesure plutôt qu’acheter une solution du marché ?
Le développement sur mesure se justifie quand la règle de gestion constitue l’avantage concurrentiel, quand aucune solution du marché ne traite une contrainte locale sans contournement manuel quotidien, ou quand la dépendance à un éditeur unique fait peser un risque sur l’activité. Dans les autres cas — comptabilité, paie, gestion commerciale, site vitrine ou e-commerce classique — la solution du marché reste le choix économiquement rationnel.
Combien coûte la maintenance d’un logiciel sur mesure ?
Le montant dépend du périmètre, mais la charge est certaine et son rythme est connu à l’avance. Elle est imposée par le cycle de vie des socles techniques : PHP 8.2 perd son support de sécurité le 31 décembre 2026, PHP 8.3 le 31 décembre 2027. Un budget de développement établi sans ligne d’entretien annuel est incomplet, que le logiciel soit possédé ou loué.
Les solutions du marché gèrent-elles la TGC et la comptabilité calédonienne ?
Rarement en standard. La plupart des progiciels et des plateformes SaaS sont construits autour d’une TVA, d’un plan comptable et de moyens de paiement métropolitains. En pratique, la fiscalité locale, le RIDET et les passerelles de paiement du territoire demandent presque toujours un développement d’interface ou un paramétrage spécifique, dont le coût doit être chiffré avant de comparer les offres.
Peut-on commencer avec une solution du marché et passer au sur-mesure ensuite ?
Oui, et c’est souvent la bonne séquence. Démarrer sur un outil du marché permet de stabiliser le processus avant de le figer dans du code, et de vérifier que la spécificité supposée en est vraiment une. La condition, c’est de pouvoir récupérer ses données : vérifiez ce point au moment de la souscription, pas au moment de partir.
La conclusion, directe comme on aime
Il n’y a pas de réponse universelle à cet arbitrage, et méfiez-vous de celui qui vous en donne une en dix minutes. La solution du marché gagne plus souvent qu’on ne le dit, et l’assemblage gagne encore plus souvent que les deux options pures.
Ce qu’on fait avant chaque projet est toujours la même chose : on écrit les règles de gestion réellement spécifiques — il y en a rarement plus de quatre —, on regarde ce que le marché couvre déjà, et on chiffre le reste. Si ce reste est petit, on vous le dit et on vous déconseille le développement.
Si vous êtes sur cet arbitrage en ce moment, même avec un besoin encore flou, parlons-en. Si vous démarrez plus en amont, notre article sur la création de site internet en Nouvelle-Calédonie pose les bases du même raisonnement.