Le développement SAP Business One est un sujet que les dirigeants et les DSI abordent souvent trop tard, quand le standard semble ne pas suffire. Pourtant, la plupart des adaptations ne demandent pas une ligne de code. Cette page vous aide à distinguer ce qui relève du paramétrage, de l’extension existante et du développement spécifique, à mesurer l’effet sur vos mises à jour et à évaluer le prestataire à qui vous confiez le travail.
Personnaliser SAP Business One : les trois niveaux
La personnalisation SAP Business One s’organise en niveaux, du moins intrusif au plus lourd. Le bon réflexe consiste à n’aller au niveau suivant que lorsque le précédent est épuisé.
| Niveau | Ce que c’est | Maintenance | Quand l’envisager |
|---|---|---|---|
| Paramétrage | Outils intégrés à l’ERP, sans code | Faible | Toujours en premier |
| Extension existante | Add-on du catalogue SAP ou d’un éditeur partenaire | Portée par l’éditeur de l’extension | Besoin sectoriel ou fonctionnel déjà couvert |
| Développement spécifique | Code écrit pour votre cas | À votre charge ou celle de l’intégrateur | Processus unique qu’aucune option ne couvre |
Cette hiérarchie n’est pas une règle de prudence abstraite : plus vous descendez dans le tableau, plus vous devenez propriétaire d’un morceau de logiciel, avec ses tests, sa documentation et sa maintenance.
Le paramétrage : ce qu’on peut faire sans développer
Le cours d’implémentation de SAP Learning présente comme outils de personnalisation de SAP Business One les champs, tables, objets et valeurs définis par l’utilisateur (UDF, UDT, UDO et UDV), ainsi que les requêtes SQL, les alertes et les workflows d’approbation. C’est une boîte à outils étendue, qui couvre une grande part des demandes courantes.
Champs, tables et objets définis par l’utilisateur
- Champs (UDF) : ajouter une information propre à votre activité sur un document ou une fiche, par exemple une référence interne sur une commande client ou une caractéristique sur un article.
- Tables (UDT) : stocker des données qui n’ont pas leur place dans les tables standard, comme une grille de conditions spécifiques à un client.
- Objets (UDO) : créer un véritable objet métier, avec ses propres écrans, qui se comporte comme un document de l’ERP.
- Valeurs (UDV) : proposer des listes de valeurs ou des valeurs par défaut pour fiabiliser la saisie.
Requêtes, alertes et workflows
Les requêtes SQL servent à interroger les données et à alimenter des listes de choix ou des états. Les alertes préviennent un utilisateur lorsqu’une condition est remplie, par exemple un seuil de stock ou une échéance. Les workflows d’approbation encadrent les validations : un achat au-delà d’un certain niveau, une remise exceptionnelle, une création de tiers.
Avant de lancer un chantier de code, demandez toujours à votre intégrateur de démontrer pourquoi ces outils ne suffisent pas. Si la réponse est solide, le développement est justifié. Sinon, vous économisez du budget et de la complexité. Pour situer ces choix dans l’ensemble du projet, consultez la page mise en place de SAP Business One.
Les extensions existantes avant le sur-mesure
SAP présente SAP Business One comme un cœur ERP conçu pour être étendu. L’éditeur indique une distribution via 850 partenaires et plus de 500 extensions sectorielles et pays (SAP, décembre 2025). Autrement dit, un besoin propre à votre métier a de bonnes chances d’avoir déjà été traité par une solution du catalogue.
Une extension du marché présente plusieurs avantages sur un développement spécifique :
- elle a été éprouvée chez d’autres clients ;
- sa maintenance et ses évolutions sont assurées par son éditeur ;
- son coût est connu d’avance, ce qui facilite l’arbitrage ;
- elle se retire plus facilement si votre besoin change.
Cela ne la rend pas neutre. Vérifiez sa compatibilité avec votre version, la fréquence de ses mises à jour et la réactivité de son éditeur. Pour comprendre ce que le cœur couvre déjà, parcourez les modules de SAP Business One et la page dédiée aux versions et éditions.
Le développement spécifique : outils et interfaces
Quand le paramétrage et le catalogue ne répondent pas, le développement sur mesure passe par les interfaces que SAP met à disposition.
SDK, add-ons et licences
Selon le guide de licences de SAP, les licences utilisateur de SAP Business One incluent automatiquement, sans demande séparée, le Software Development Kit (version d’implémentation), les SDK Tools, les SAP AddOns, la licence de compatibilité pour add-ons et le Workflow, chacun avec 99 999 utilisateurs. L’accès aux outils de développement n’est donc pas un poste de licence à négocier à part.
Le Service Layer
Le Service Layer est une API d’extension REST fondée sur HTTP et OData, avec des échanges en JSON. D’après le guide de SAP du 27 juillet 2026, il accepte OData v3 via /b1s/v1/$metadata et OData v4 via /b1s/v2/$metadata. Il fonctionne sur SUSE Linux Enterprise et sur Microsoft Windows, s’appuie sur le serveur Apache comme répartiteur de charge, peut être déployé en mode intégré ou distribué, et partage avec la DI API les mêmes définitions d’objets grâce au composant DI Core.
SAP Learning précise qu’il met en œuvre les schémas d’authentification Basic et OAuth, et qu’il vise à faciliter le développement d’applications web et mobiles pour SAP Business One. C’est la voie naturelle pour un portail client, une application de terrain ou un site e-commerce qui doit lire et écrire dans l’ERP.
L’Integration Framework
Présenté par SAP comme partie intégrante de SAP Business One, utilisable sur site comme dans le cloud, l’Integration Framework sert d’environnement de développement et d’exécution de scénarios d’intégration. SAP cite parmi ses usages les tableaux de bord, les applications mobiles, la paie externalisée, la demande de prix automatisée, SAP Customer Checkout, les services web et les applications SAP et non SAP. Pour les échanges avec d’autres logiciels, voyez aussi la page sur les connecteurs et intégrations.
Les services cloud de SAP
SAP Learning décrit le cœur ERP comme enrichi par l’IA, l’apprentissage automatique et les services cloud de SAP Business Technology Platform (BTP), avec des modèles d’automatisation intelligente accessibles via le Business Accelerator Hub et SAP Build. Ces briques permettent d’ajouter des automatisations autour de l’ERP sans toucher à son cœur, ce qui est précisément l’esprit d’une extension saine.
Impact sur les mises à jour : où se situe le risque
La question que posent tous les décideurs est la même : « Si je personnalise, pourrai-je toujours monter de version ? » La réponse dépend de la manière dont la personnalisation est construite.
| Pratique | Effet sur les montées de version |
|---|---|
| Champs et objets définis par l’utilisateur | Mécanismes prévus par l’éditeur, risque généralement faible |
| Développement via Service Layer ou DI API | Interfaces officielles, à retester à chaque version |
| Add-on d’un partenaire | Dépend de la compatibilité annoncée par son éditeur |
| Contournement du standard (écriture directe en base, par exemple) | Risque élevé, à éviter |
Le principe est simple : plus votre développement passe par des interfaces officielles, plus il résiste aux évolutions. À l’inverse, tout ce qui modifie directement les données sans passer par les objets de l’ERP peut contourner des contrôles et casser sans prévenir. La montée de version doit être préparée comme un mini-projet, avec un environnement de test et la liste de vos développements à revalider. Le sujet est détaillé dans la page migration vers SAP Business One.
Bonnes pratiques pour un projet sur mesure
Rester au standard autant que possible
Chaque écart au standard a un coût qui dure : il faut le tester, le documenter, le faire évoluer. Avant d’écrire du code, interrogez votre processus. Parfois, adapter légèrement l’organisation est plus rentable que d’adapter l’outil. Un bon intégrateur sait vous dire non lorsque l’écart ne se justifie pas.
Écrire un cahier des charges précis
Un développement spécifique se décrit comme un livrable : objectif métier, données concernées, utilisateurs, cas limites, critères d’acceptation. Plus le besoin est écrit tôt, moins le périmètre dérive. Notre guide sur le cahier des charges ERP donne une trame utilisable.
Documenter
Un développement non documenté devient dépendant d’une seule personne. Exigez au minimum une description fonctionnelle, une description technique, la liste des objets de l’ERP touchés et la procédure de déploiement. Cette documentation vous appartient, au même titre que le code livré.
Tester dans un environnement séparé
Tout développement passe par un environnement de test avant la production, avec des données représentatives et des scénarios écrits. Ces mêmes scénarios serviront à chaque montée de version. Faites valider par les utilisateurs concernés, pas seulement par le développeur.
Prévoir la maintenance dès le départ
Qui corrige une anomalie dans un an ? Qui adapte le développement à la version suivante ? Ces points se négocient avant la livraison. La page sur le support et la maintenance vous aide à cadrer ce volet, et la formation évite que les équipes détournent l’outil faute de le maîtriser.
Comment évaluer un développeur ou un intégrateur SAP Business One
Le choix du prestataire pèse davantage que celui de la technologie. Quelques critères permettent de distinguer un intégrateur solide d’un simple exécutant.
- Méthode : il commence par le standard et le paramétrage, puis justifie chaque développement par écrit.
- Références comparables : des projets proches du vôtre par le secteur et la complexité, que vous pouvez faire confirmer par des clients.
- Maîtrise des interfaces : il sait expliquer pourquoi il choisit le Service Layer, la DI API ou l’Integration Framework pour votre cas.
- Qualité de livraison : documentation, jeux de tests, environnement séparé, procédure de déploiement.
- Reprise possible : le code et la documentation vous sont remis, de sorte qu’un autre prestataire puisse prendre le relais.
- Maintenance : engagement clair sur les corrections et sur la compatibilité avec les versions futures.
Posez aussi des questions concrètes : « Que se passe-t-il à la prochaine montée de version ? », « Comment testez-vous ? », « Qui détient le code source ? ». Des réponses précises sont un bon signe, des réponses vagues un avertissement. Pour une grille complète, voyez comment choisir un intégrateur SAP Business One et le guide plus général sur le choix d’un intégrateur ERP.
Si vous héritez d’un existant mal documenté ou d’un projet qui dérive, un audit ou une reprise de projet SAP Business One permet d’inventorier les développements en place avant toute nouvelle décision.
Budget : ce qu’il faut savoir
Le coût d’un développement spécifique dépend du périmètre, de la complexité des règles métier, du nombre d’interfaces à connecter et du niveau de test attendu. Aucun chiffre sérieux ne peut être avancé sans analyse. Demandez un chiffrage détaillé par lot, avec les hypothèses, et comparez plusieurs propositions. Pour replacer ces dépenses dans l’ensemble de votre projet, consultez la page prix de SAP Business One.
Trouver un intégrateur pour votre projet
Notre service est gratuit et neutre entre les éditeurs : nous ne réalisons pas les projets, nous vous mettons en relation avec un intégrateur ERP adapté à votre besoin, qui analyse votre demande et vous répond. Décrivez votre contexte, vos contraintes et ce que vous attendez du sur-mesure, et comparez les propositions reçues avant de vous engager.
Questions fréquentes
Quelle est la différence entre paramétrage et développement sur SAP Business One ?
Le paramétrage utilise les outils fournis avec l’ERP : champs, tables et objets définis par l’utilisateur, requêtes, alertes, workflows d’approbation. Le développement ajoute du code, par exemple un add-on ou un service qui dialogue avec l’ERP par le Service Layer. Le premier est généralement plus simple à maintenir, le second répond aux besoins que le standard ne couvre pas.
Quels outils permettent de développer un module sur mesure SAP Business One ?
SAP met à disposition le Software Development Kit, la DI API et le Service Layer, une API REST fondée sur HTTP et OData. L’Integration Framework sert à construire des scénarios d’intégration. Le choix dépend du besoin : extension intégrée à l’interface, échange avec une application tierce, application web ou mobile.
Une personnalisation empêche-t-elle de mettre à jour SAP Business One ?
Pas si elle respecte les mécanismes prévus par l’éditeur. Les champs définis par l’utilisateur et les extensions passant par les interfaces officielles sont conçus pour traverser les évolutions de version. Le risque vient du développement mal documenté ou qui contourne le standard : il se teste alors à chaque montée de version.
Faut-il payer une licence pour développer sur SAP Business One ?
D’après le guide de licences de SAP, les licences utilisateur incluent automatiquement le SDK, les SDK Tools, les SAP AddOns, la licence de compatibilité pour add-ons et le Workflow. Il n’y a donc pas de demande séparée pour ces briques. Le coût d’un projet tient surtout au temps d’analyse, de développement et de test de l’intégrateur.
Comment choisir un développeur ou un intégrateur pour un projet sur mesure ?
Demandez des références comparables à votre besoin, la manière dont il documente et teste ses livrables, et sa capacité à vous expliquer ce qui peut se faire au standard avant d’écrire du code. Vérifiez aussi qui assure la maintenance après la livraison. Notre service gratuit vous met en relation avec des intégrateurs adaptés à votre projet.
Sources
- SAP News — Global success of SAP Business One (décembre 2025)
- SAP Learning — Introducing SAP Business One
- SAP Help Portal — SAP Business One License Guide
- SAP Help Portal — Working with SAP Business One Service Layer
- SAP Learning — Service Layer : architecture et capacités
- SAP Help Portal — Integration Framework for SAP Business One
- SAP Learning — Implementing SAP Business One
Les noms de logiciels cités sont des marques de leurs éditeurs respectifs, mentionnées à titre d’information. Ce site est indépendant et n’est affilié à aucun éditeur.