ERP sur mesure vs SaaS : que choisir pour une PME en NC ?

À Nouméa, on entend la même histoire toutes les semaines : un dirigeant a essayé un ERP SaaS « tout-en-un », ça a tenu six mois, puis l’outil a commencé à craquer sur des cas métier locaux. Réglementation Cafat, paie spécifique NC, intégration avec une banque locale, gestion des devises CFP/EUR/USD, fournisseurs métropolitains et asiatiques en parallèle… À un moment, le SaaS générique ne peut plus suivre, ou alors il devient si tordu qu’il coûte plus cher qu’un dev custom dès le départ.

L’inverse est aussi vrai. On voit des entreprises lancer un grand projet d’ERP sur mesure par défaut, alors qu’un SaaS aurait fait le job pour 80 % de leur besoin, à 5 fois moins cher. La vraie question n’est donc pas « custom ou pas custom », mais : où passe la ligne entre les deux, et comment la voir avant de signer un devis ?

Cet article propose un cadre de décision basé sur ce qu’on observe depuis 2010 sur le marché calédonien — chez des cabinets médicaux, des grossistes, des entreprises industrielles, des compagnies de transport, des gestionnaires de parc hôtelier.

Pourquoi la question se pose différemment en NC qu’à Paris

Avant d’arbitrer, il faut comprendre pourquoi le débat ERP-NC n’est pas une copie du débat ERP-métropole.

Marché plus étroit, contraintes plus précises

Une PME calédonienne de 30-80 salariés a souvent un mix d’activités qu’une PME française de même taille n’aurait pas. C’est typique du Pacifique : on couvre plusieurs métiers parce que le marché est petit et qu’il faut diversifier. Résultat : un éditeur SaaS conçu pour un métier précis (négoce, retail, BTP) se retrouve à gérer une activité « hors-périmètre » pour 30 % du chiffre d’affaires de l’entreprise. Le SaaS plie, on sort du standard, on fait du paramétrage avancé… et on commence à payer le prix d’un custom pour un résultat moins propre.

Réglementations locales mal couvertes

La Cafat (régime de protection sociale NC), les déclarations DAS-NC, le bordereau Caisse de retraite, les taxes spécifiques (TGC, taxes sur l’environnement, droits de douane locaux), la gestion paie en CFP avec règles d’arrondi spécifiques : tout cela est rarement supporté nativement par un SaaS européen ou nord-américain. On en voit qui font « SaaS + plugin local + module de redressement Excel » — c’est le pire des mondes.

Connectivité et latence

Hostinger, OVH et AWS ont tous des datacenters loin de Nouméa. La latence vers l’Europe oscille entre 270 et 320 ms. Pour un ERP très interactif (saisie comptable rapide, scan en temps réel), cette latence peut casser l’UX. Un déploiement avec un cache local ou un mode offline-first résout le problème — mais ce n’est pas natif chez la plupart des SaaS.

Souveraineté des données et continuité

Pour une institution publique, un cabinet médical ou une entreprise traitant des données sensibles (RH, santé, défense), garder la main sur l’hébergement est de plus en plus critique. La loi de pays NC sur la protection des données de 2019 commence à être appliquée sérieusement. Un SaaS hébergé en Irlande ou en Californie demande des engagements DPA solides. Un déploiement on-premise ou dans un datacenter régional élimine la question.

Le cadre de décision en 4 critères

Voici le filtre qu’on applique avec nos clients pour orienter le choix. Aucun de ces critères n’est éliminatoire à lui seul ; c’est le cumul qui décide.

Critère 1 — Spécificité du process métier

Si vos process sont standards à 80 % ou plus (négoce simple, comptabilité française, RH classique sans paie atypique), un SaaS généraliste fera très bien le job. NetSuite, Odoo, Sage 100, Pennylane, Lucca, Sellsy — selon le segment.

Si vos process ont une partie idiosyncratique forte (gestion de chantier multi-île, planification d’équipes décalées, suivi qualité ISO sectoriel, tracking de production particulier), le SaaS générique va vous forcer à des contournements. Dès qu’on entend « on a fait un Excel à côté pour gérer X », c’est le signal qu’un module custom serait pertinent — soit sur un SaaS extensible, soit en dev intégral.

Critère 2 — Volume d’utilisateurs et fréquence d’usage

Un SaaS coûte typiquement 30-80 €/user/mois. Pour 50 utilisateurs sur 5 ans, ça fait 90-240 k€ rien qu’en abonnements, sans les modules complémentaires. Au-delà de 80-100 utilisateurs, le ROI d’un développement custom (qui s’amortit sur la durée) devient intéressant — surtout s’il y a peu de churn de poste.

À l’inverse, pour 10-15 utilisateurs avec des sessions ponctuelles, le SaaS reste imbattable.

Critère 3 — Intégrations critiques

Si votre activité dépend de 3+ intégrations critiques avec des outils existants (banque NC, ERP interne, outil de planification, plateforme e-commerce, système de caisse), un SaaS générique vous oblige souvent à payer des intégrations payantes ou à utiliser un middleware (Zapier, n8n, Make) qui devient vite une boîte noire.

Un dev custom peut mutualiser toutes ces intégrations dans un seul système cohérent, monitoré, documenté. C’est plus cher au démarrage, plus stable sur 5 ans.

Critère 4 — Maturité du besoin

C’est le critère le plus sous-estimé. Si vous ne savez pas encore exactement ce que vous voulez (process en cours de définition, organisation qui change, marché qui bouge), un SaaS modulaire vous laisse de la marge pour pivoter. Un dev custom à ce stade prend le risque d’être sur-spécifié sur un besoin qui va évoluer dans les 12 mois.

Inversement, si vos process sont stabilisés depuis des années et que vous savez précisément ce qui marche et ce qui manque, un dev custom permet de modéliser exactement ce niveau de finesse — ce qu’un SaaS ne saura pas faire.

Trois scénarios concrets vus en NC

Pour rendre ça moins théorique, voici trois cas réels (anonymisés) sur lesquels on a aidé à arbitrer.

Scénario A — Cabinet médical multi-sites, 25 utilisateurs

Besoin : gestion patients, prise de RDV, compte-rendu, facturation Cafat, télétransmission, dossier médical partagé entre 3 cabinets.

Notre recommandation : mix SaaS + custom léger. On a pris un SaaS médical existant (français, certifié HDS) pour la gestion patient et la télétransmission. On a développé une couche custom pour la facturation Cafat (non gérée nativement) et un connecteur pour le partage des dossiers entre cabinets. Coût total : ~6 millions XPF contre 18-22 millions pour un dev intégral, et 90 % de la valeur d’un dev custom complet.

Scénario B — Grossiste agroalimentaire, 75 utilisateurs, 4 entrepôts

Besoin : gestion commerciale, achats import (Australie, NZ, métropole), stock multi-sites, traçabilité produits frais, comptabilité.

Notre recommandation : dev custom intégral. Trop de spécificités : les délais Pacifique (2-3 semaines en bateau), les ruptures fréquentes de chaîne du froid, la gestion multi-devises avec couverture de change, les rétro-cessions clients institutionnels. Aucun SaaS ne couvrait ça correctement, et le paramétrage des plus grands ERP (Sage X3, Microsoft Business Central) revenait à 80 % du prix d’un dev custom, avec moins de souplesse. Budget réel : 22 millions XPF, déployé en 9 mois en mode itératif.

Scénario C — Société de service BTP, 12 utilisateurs

Besoin : facturation chantier, suivi heures équipes, marges par chantier, déclarations sociales.

Notre recommandation : SaaS pur. Pennylane + Lucca + un module de suivi de chantier SaaS (BatiManager). Pas de dev custom. Coût annuel : 1,2 million XPF. Recommander un dev ici aurait été malhonnête.

Les pièges à éviter dans les deux directions

Côté « tout SaaS »

• Empiler 6-7 SaaS qui ne se parlent pas. Au bout de 18 mois, vos équipes passent plus de temps à recopier qu’à travailler. Posez la question avant de signer : qui parle à qui, et comment ?
• Croire qu’un SaaS « suffit » sans avoir testé sur 2-3 cas métier extrêmes. La démo commerciale est faite sur les cas faciles. Demandez à tester sur vos cas atypiques.
• Se laisser embarquer dans le « tout-en-un » d’un seul éditeur. Le verrouillage est total : si on veut changer un module dans 3 ans, c’est tout l’écosystème qu’il faut migrer.

Côté « tout custom »

• Démarrer un projet sans benchmark. On voit régulièrement des entreprises lancer un dev custom alors qu’un Odoo bien paramétré aurait fait 80 % du job. Toujours faire l’exercice du benchmark avant.
• Sous-estimer la maintenance. Un dev custom, c’est une responsabilité long terme. Prévoyez 15-25 % du coût initial par an en maintenance évolutive.
• Confondre dev custom et dev sans cadre. Un projet custom doit être livré documenté, testé, transférable. Sans ça, c’est juste de la dette technique facturée.

Notre approche chez logiciel.nc

On part toujours du plus simple qui marche. La première session de cadrage gratuite vise à répondre à une seule question : « est-ce qu’un SaaS existant couvre votre besoin à un coût raisonnable ? ». Si la réponse est oui, on vous oriente vers le SaaS — même si ça veut dire qu’on ne signe pas de contrat. Notre intérêt long terme est dans la confiance, pas dans la facturation forcée.

Si la réponse est non, ou si elle est « partiellement », on construit. Mais avec un parti-pris fort : livrer le code source, la documentation, les droits d’usage. Vous restez propriétaire. Si dans 3 ans vous voulez reprendre le projet en interne ou changer de prestataire, c’est faisable sans rétro-engineering coûteux.

En résumé

Le débat ERP custom vs SaaS n’a pas de réponse universelle. Il a une réponse précise pour chaque entreprise, qui dépend de la spécificité du métier, du volume d’utilisateurs, des intégrations critiques et de la maturité du besoin. En Nouvelle-Calédonie, les contraintes locales (Cafat, monnaies, latence, souveraineté) déplacent souvent le curseur vers du custom — ou au moins du custom-augmenté — par rapport à des contextes métropolitains.

La règle d’or : ne vous décidez pas avant d’avoir testé un SaaS sérieusement sur vos cas extrêmes, et avant d’avoir chiffré honnêtement un dev custom. Si vous voulez un avis indépendant sur votre cas, on en discute volontiers — première session gratuite, et on vous dit franchement de quel côté on penche.

---

Cet article fait partie d’une série sur les choix techniques pour entreprises calédoniennes. À lire aussi : Intégrer une IA dans son entreprise NC : 5 cas d’usage concrets et PWA, app native ou hybride pour une application mobile en NC.