Personnaliser SAP Business One sans fragiliser votre ERP

Le développement SAP Business One est un sujet où l’on dépense vite plus qu’il ne faut. Une PME belge qui découvre l’ERP veut souvent y reproduire à l’identique ses habitudes : le formulaire de devis maison, la règle de remise de tel client, l’écran que le comptable utilisait dans l’ancien outil. Or l’essentiel de ces demandes se règle sans une ligne de code, et ce qui exige vraiment du développement doit être écrit de façon à ne pas coincer la prochaine montée de version.

Cette page décrit les niveaux de personnalisation, de la configuration au module sur mesure, leurs effets sur les mises à jour, et les critères pour évaluer la personne ou la société à qui vous confierez le travail.

Les trois niveaux de personnalisation de SAP Business One

Raisonnez toujours du moins intrusif au plus intrusif. Chaque niveau franchi ajoute de la maintenance.

Le paramétrage d’abord

Avant de parler de personnalisation SAP Business One, vérifiez que le standard ne couvre pas déjà le besoin. Conditions de paiement, listes de prix, groupes d’articles, circuits de validation, droits par profil : tout cela relève de la configuration. Dans les projets de mise en place de SAP Business One, c’est l’atelier de cadrage qui sépare ce qui est un vrai manque de ce qui est une habitude à réexaminer.

Les outils sans code

Le cours d’implémentation de SAP Learning présente comme outils de personnalisation les champs (UDF), tables (UDT), objets (UDO) et valeurs (UDV) définis par l’utilisateur, ainsi que les requêtes SQL, les alertes et les workflows d’approbation. Concrètement :

• un champ utilisateur ajoute une information à une fiche existante, par exemple une référence de dossier ou une catégorie propre à votre activité ;
• une table utilisateur stocke des données qui n’existent pas dans le standard, comme une grille de coefficients ;
• un objet utilisateur regroupe tables et champs en un véritable document avec son propre écran ;
• une requête alimente une liste de choix, un contrôle ou un état sur mesure ;
• une alerte prévient la bonne personne quand une condition est remplie, et un workflow d’approbation fait valider une commande ou un achat au-delà d’un seuil que vous fixez.

Pour une PME flamande, wallonne ou bruxelloise qui facture en plusieurs langues et gère des conditions commerciales variées selon les clients, ce niveau suffit très souvent. Il s’apprend, se documente facilement et reste dans le cadre prévu par l’éditeur.

Quand une extension existante vaut mieux qu’un développement

SAP annonce plus de 500 extensions sectorielles et pays, distribuées via un réseau de 850 partenaires. Ce chiffre dit surtout une chose : le besoin que vous croyez unique a de bonnes chances d’avoir déjà été traité par quelqu’un d’autre.

Une extension éprouvée présente trois avantages sur un développement spécifique : elle est maintenue par un éditeur, elle évolue avec les versions, et son coût se répartit entre ses utilisateurs. Elle a aussi un défaut : vous adoptez la logique de l’éditeur, pas la vôtre. À comparer au cas par cas, en regardant la couverture réelle de votre processus, pas la plaquette. Les besoins par métier sont détaillés dans la page SAP Business One par secteur.

Le développement spécifique : outils et architecture

Quand ni le paramétrage ni une extension ne suffisent, on écrit du code. SAP Business One est présenté par SAP Learning comme un cœur ERP conçu pour être étendu, avec l’appui des services cloud de SAP Business Technology Platform, de l’IA et de l’apprentissage automatique, et de modèles d’automatisation accessibles via le Business Accelerator Hub et SAP Build.

Le SDK et les add-ons

Les licences utilisateur incluent le Software Development Kit en 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, sans demande séparée. L’outillage de développement ne se négocie donc pas à part : ce qui coûte, c’est le temps passé à spécifier, écrire, tester et documenter.

Le Service Layer

Le Service Layer est l’API d’extension REST de SAP Business One. Elle repose sur HTTP et OData, avec des échanges en JSON, et gère les schémas d’authentification Basic et OAuth. Son but affiché est de faciliter le développement d’applications web et mobiles.

Côté technique, il fonctionne sur SUSE Linux Enterprise et sur Microsoft Windows, s’appuie sur le serveur Apache comme répartiteur de charge, et peut être déployé en mode intégré ou distribué. Il partage avec la DI API les mêmes définitions d’objets grâce au composant DI Core : un objet métier, par exemple un document de vente, se comporte donc de la même manière quel que soit le canal d’accès.

Pour vous, l’intérêt est simple : un portail client, une boutique en ligne ou une application de tournée peuvent lire et écrire dans l’ERP par une porte officielle, au lieu d’aller toucher directement les tables. Ce point est capital pour la stabilité, nous y revenons plus bas.

L’Integration Framework

SAP décrit l’Integration Framework comme une partie intégrante de SAP Business One, utilisable sur site comme dans le cloud, qui sert d’environnement de développement et d’exécution de scénarios d’intégration : tableaux de bord, applications mobiles, paie externalisée, demande de prix automatisée, SAP Customer Checkout, services web, applications SAP et non SAP. Si votre besoin est surtout d’échanger des données entre l’ERP et un autre logiciel, lisez la page connecteurs et intégrations SAP Business One avant de commander un développement.

Intégrations bureautiques déjà disponibles

SAP Learning cite l’export vers Microsoft 365 OneDrive (Excel, Word), la collaboration avec Microsoft Teams et l’intégration avec Outlook 365. Si votre demande est « sortir cette liste dans Excel » ou « envoyer ce document par courriel », elle ne justifie pas un module sur mesure.

Exemples de développements courants en Belgique

Ces cas reviennent régulièrement dans les entreprises belges, sans qu’aucune n’exige forcément du code lourd :

• Facturation électronique via Peppol : l’obligation du B2B belge pousse à connecter l’ERP à un point d’accès. Avant de développer, vérifiez ce que propose le marché ; la page sur la facturation électronique Peppol détaille les enjeux.
• TVA et listings clients : la déclaration de TVA belge repose sur des états à produire depuis la comptabilité. Un état sur mesure est parfois utile ; le contexte est expliqué dans le guide TVA belge et ERP.
• Échanges avec le comptable externe : beaucoup de PME confient leur comptabilité à un cabinet. Un export structuré, planifié, remplace avantageusement un traitement manuel.
• Boutique ou portail : lecture des stocks, création de commandes, suivi de livraison via le Service Layer, comme présenté dans le guide ERP et e-commerce.
• Calculs métier propres : tarification à la formule, commissions d’agents, règles de surstockage.

Pour la comptabilité, voyez aussi la page comptabilité et finance dans SAP Business One : plusieurs « manques » apparents s’y résolvent par le paramétrage.

Impact sur les mises à jour

C’est la question que personne ne pose avant la signature et que tout le monde regrette à la première montée de version. Un développement n’est pas dangereux en soi ; il le devient par la manière dont il est écrit.

Ce qui garde une mise à jour sereine

• passer par les interfaces officielles (SDK, Service Layer) plutôt que par des accès directs à la base de données ;
• ne jamais modifier les objets standard, mais les compléter par des champs et objets utilisateur ;
• isoler le code spécifique dans un add-on identifié, installable et désinstallable ;
• livrer une spécification, un jeu de tests et un journal des modifications ;
• tester chaque nouvelle version sur une copie de la société avant de toucher à la production.

Ce qui la rend pénible

• une requête qui écrit directement dans les tables, car la structure interne peut évoluer ;
• un développeur unique, seul à comprendre ses choix, qui part ;
• des règles métier enfouies dans plusieurs scripts sans trace écrite ;
• une personnalisation qui duplique une fonction que le standard a introduite depuis.

Le cycle des versions et les différences entre éditions sont abordés dans la page versions et éditions de SAP Business One. Si vous reprenez un système déjà truffé de développements non documentés, un audit et une reprise de projet permettent de faire le tri avant de migrer.

Bonnes pratiques pour un projet sur mesure

1. Rester au standard autant que possible. Chaque écart se paie à la mise en place, puis à chaque mise à jour. Posez la question : « que se passe-t-il si nous ne développons pas ? »
2. Écrire la spécification en langage métier. Un document que le responsable comptable ou le chef d’entrepôt peut relire et signer, avec des cas concrets, pas un jargon technique.
3. Documenter pendant, pas après. Schéma des données touchées, objets créés, droits requis, procédure de retour arrière.
4. Tester dans un environnement séparé. Jamais directement sur la société de production. Faites valider par les utilisateurs, pas seulement par le développeur.
5. Définir qui maintient. Le contrat de support et maintenance doit mentionner explicitement les développements spécifiques, sinon personne n’en répond.
6. Prévoir la formation. Un nouvel écran non expliqué est un écran non utilisé ; la page sur la formation SAP Business One donne les repères.

Comment évaluer un développeur ou un intégrateur SAP Business One

Nous ne sommes affiliés à aucun éditeur ni à aucun intégrateur : nous mettons en relation, et le projet est mené par le prestataire que vous retenez. Voici les questions qui séparent un bon candidat d’un candidat seulement disponible.

Demandez à parler à un client dont un développement spécifique a traversé une mise à jour : la réponse vaut mieux que n’importe quelle présentation. La page choisir un intégrateur SAP Business One et le guide général choisir un intégrateur ERP complètent cette grille.

Enfin, méfiez-vous du prestataire qui répond oui à tout. Un bon interlocuteur vous dissuade d’abord d’au moins un développement : celui dont le standard, une extension ou un simple champ utilisateur fait déjà le travail.

Et si le besoin est trop spécifique pour SAP Business One ?

Il arrive que la somme des écarts devienne le vrai sujet. Si le cahier des charges exige des dizaines de développements pour reproduire un fonctionnement, c’est peut-être le signe que l’ERP n’est pas le bon, ou que le processus mérite d’être repensé. Comparez avec d’autres options sur la page alternatives à SAP Business One, ou consultez la vue d’ensemble des logiciels ERP disponibles sur le marché belge.

Pour les entreprises qui veulent comparer l’effort de personnalisation entre solutions, le comparatif Odoo ou SAP Business One éclaire la question de l’ouverture et de l’outillage.

Préparer votre demande

Avant de contacter un prestataire, listez vos besoins en trois colonnes : ce que vous voulez absolument, ce qui est confortable, ce qui est une habitude. Pour chaque ligne de la première colonne, notez le processus concerné, la personne qui l’utilise et le résultat attendu. Cette liste fait gagner un temps considérable au premier rendez-vous, et elle sert directement de base à la mise en relation avec un intégrateur adapté à votre taille, à votre secteur et à votre région. Le service est gratuit : vous décrivez votre projet, et nous vous orientons vers un intégrateur qui connaît SAP Business One et le contexte belge.

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.