Personnaliser Business Central : du paramétrage au code AL

Un projet de développement Business Central réussi est un projet où l’on écrit le moins de code possible, et où chaque ligne écrite a une raison métier claire. Pour une PME ou une ETI belge, la personnalisation de Business Central n’est pas un but : c’est un moyen de couvrir ce que le standard ne fait pas, sans transformer l’ERP en logiciel que personne n’ose plus mettre à jour.

Cette page décrit les trois niveaux de personnalisation, ce que change un module sur mesure Business Central pour vos mises à jour, les bonnes pratiques à exiger et la manière d’évaluer un développeur ou un intégrateur.

Les trois niveaux de personnalisation

Avant de parler de code, il faut distinguer ce qui relève du réglage, de l’extension du marché et du développement spécifique. Le bon réflexe est de remonter ces niveaux dans l’ordre, et de ne passer au suivant que si le précédent ne suffit pas.

Le paramétrage : le plus rentable

Business Central offre déjà beaucoup de souplesse sans programmation : plans comptables, dimensions analytiques, modèles d’articles, flux d’approbation, rôles et profils. Le Designer, intégré au client, permet de concevoir des pages par glisser-déposer : on réorganise ou on ajoute des champs et on prévisualise le résultat sans quitter l’interface.

Beaucoup de demandes présentées comme « du développement » se règlent ainsi. Un dirigeant qui veut qu’un champ apparaisse plus haut dans la fiche client n’a pas besoin d’un projet de programmation. Pour savoir ce que le standard couvre déjà, parcourez les modules de Business Central avant d’écrire le moindre cahier des charges.

Les extensions existantes

En ligne, on étend Business Central par des applications, aussi appelées extensions, installées depuis Microsoft Marketplace. Des pages « Connectivity Apps » et « Banking Apps » proposent des applications de connexion à des services externes, par exemple pour importer des transactions bancaires.

Le connecteur Shopify illustre bien l’intérêt de cette voie. Il synchronise produits, stocks, clients, commandes, expéditions, transactions et versements, prend en charge plusieurs boutiques et importe les commandes des boutiques en ligne, de Shopify POS et du B2B. Sa synchronisation peut tourner en arrière-plan grâce à la file de travaux de Business Central, avec une journalisation détaillée pour le dépannage. Développer cela soi-même serait un chantier inutile.

Avant de commander un développement, demandez donc systématiquement : « existe-t-il une application qui fait déjà cela ? ». Les intégrations et connecteurs disponibles méritent d’être passés en revue en premier.

Le développement spécifique en AL

Quand le standard et le marché ne suffisent pas, on écrit une extension en langage AL, dans Visual Studio Code. On ajoute ou on modifie des tables, des pages, des codeunits et des rapports sans toucher au code de base ; le résultat est compilé en fichier .app.

Ce principe est ce qui distingue Business Central des anciennes générations d’ERP, où la personnalisation passait par la modification du code d’origine. Ici, le socle reste celui de Microsoft et votre logique métier vit à côté, dans une extension que l’on peut installer, mettre à jour ou retirer.

Quand le sur-mesure se justifie

Un développement spécifique est défendable dans quelques situations typiques :

• un processus propre à votre métier que le standard ne modélise pas, par exemple une règle de calcul de remise ou de ristourne propre à votre secteur ;
• un document ou un rapport réglementaire ou commercial précis, que le client ou l’administration exige dans un format particulier ;
• une intégration avec un logiciel interne ou un partenaire qui n’a pas de connecteur prêt à l’emploi ;
• un traitement automatique qui supprime une saisie répétitive coûteuse.

À l’inverse, adapter l’ERP pour reproduire à l’identique un ancien outil, ou pour contenter une habitude d’un service, est rarement un bon investissement. Un projet de mise en œuvre bien mené commence par interroger les processus, pas par les figer dans du code.

Le cas de la Belgique

Microsoft fournit directement la localisation de Business Central pour la Belgique. Le plan comptable, la TVA et les obligations locales de base ne sont donc pas un sujet de développement en soi. Ce qui reste spécifique chez vous, c’est ce qui dépasse ce socle : un schéma de facturation particulier, un format d’échange imposé par un grand donneur d’ordre, un lien avec la comptabilité de votre fiduciaire ou de votre comptable.

Pour la facturation électronique, commencez par vérifier ce qui est couvert par le standard et par les applications du marché avant d’envisager un développement ; notre page sur Peppol et la facturation électronique détaille ce cadre. Le détail belge du produit est repris sur la page Business Central en Belgique.

Impact sur les mises à jour

C’est la question que tout dirigeant devrait poser avant de signer : « que se passe-t-il quand Microsoft publie une nouvelle version ? ».

Avec une extension écrite dans les règles, le socle se met à jour et votre extension continue de fonctionner, sous réserve de compatibilité. Le risque ne vient pas du principe, il vient de l’exécution :

• une extension qui s’appuie sur des comportements non prévus pour être étendus ;
• une absence de tests, qui fait découvrir la panne en production ;
• un développeur unique, parti sans documentation ;
• une extension abandonnée, qui retarde toute la mise à niveau de l’ERP.

Le choix de l’édition et du mode d’hébergement joue aussi. Selon que vous êtes en ligne ou non, le rythme et la maîtrise des mises à jour diffèrent : voyez à ce sujet les versions et éditions ainsi que l’hébergement cloud.

Les limites techniques à connaître

Quelques contraintes de la plateforme influencent directement ce qu’un développement peut promettre.

Les API et l’intégration

Business Central expose une API REST (v2.0) pour relier l’ERP à des solutions tierces ; en ligne, les API sont activées par défaut. Un point à retenir : on ne peut pas ajouter de champs à une API standard. Il faut copier le code AL et créer une API personnalisée. Un prestataire qui affirme « on ajoute un champ à l’API standard » se trompe, ou n’a pas compris la plateforme.

Les appels OData V4 sont par ailleurs limités par utilisateur : cinq requêtes simultanées, cent connexions et une fenêtre glissante de six mille requêtes sur cinq minutes. Au-delà, le service répond par un code HTTP 429. Microsoft recommande l’API ou OData plutôt que SOAP, appelé à être déprécié. Pour un site de vente en ligne ou un outil qui interroge massivement l’ERP, ces limites doivent être prises en compte dès la conception.

Les environnements

Un environnement Business Central peut être lié à un environnement Power Platform de même type, production ou bac à sable ; ce lien est exclusif et sert de cible par défaut aux intégrations avec Power Platform et d’autres produits Dynamics 365. Ce détail compte si vous prévoyez des automatisations autour de l’ERP.

Les bacs à sable, eux, sont conçus pour le développement : le point de débogage y est ouvert par défaut, on publie depuis Visual Studio Code, et les appels HTTP sortants des extensions sont bloqués tant qu’ils ne sont pas autorisés extension par extension.

Bonnes pratiques à exiger

Quel que soit le prestataire, ces règles protègent votre investissement.

1. Rester au plus près du standard. Chaque écart est une dette : il faudra le tester, le maintenir et parfois le réécrire.
2. Documenter. Chaque extension doit être décrite : à quoi elle sert, qui l’a demandée, quels objets elle touche, comment la désactiver.
3. Tester en bac à sable. Jamais de première publication en production ; un jeu de scénarios d’essai doit accompagner la livraison.
4. Posséder son code. Le contrat doit préciser qui détient le code source de l’extension et où il est conservé.
5. Prévoir la maintenance. Un développement sans suivi se périme. Le support et la maintenance doivent couvrir vos extensions, pas seulement le standard.
6. Chiffrer le coût de possession. Le prix d’un développement ne s’arrête pas à sa livraison. Pour situer l’ensemble des postes, consultez la page sur le prix de Business Central.

Comment évaluer un développeur ou un intégrateur

Un bon profil se reconnaît à ses questions autant qu’à ses réponses. Voici ce que vous pouvez vérifier lors des premiers échanges.

Demandez aussi à voir un exemple d’extension livrée, avec sa documentation, et faites expliquer comment le prestataire traite une mise à jour de version. Si vous reprenez un existant dont personne ne maîtrise plus le code, un audit de projet Business Central permet de faire l’inventaire des extensions avant toute décision.

Pour comparer des profils, notre page choisir un intégrateur Business Central détaille les critères, et le guide général pour choisir un intégrateur ERP vaut pour tous les éditeurs. Notre service est gratuit : nous vous mettons en relation avec un intégrateur adapté à votre projet, c’est lui qui réalise ensuite le développement et en répond.

En pratique : préparer votre demande

Pour obtenir des propositions comparables, formulez votre besoin sans présumer de la solution :

• décrivez le processus actuel, ses étapes et ses irritants ;
• indiquez ce qui est obligatoire (réglementation belge, exigence d’un client) et ce qui est confortable ;
• précisez les logiciels à relier à l’ERP ;
• demandez, pour chaque écart, une alternative en paramétrage ou en application du marché.

Cette discipline évite les surprises et donne à l’intégrateur les éléments pour proposer le niveau de personnalisation juste. Le développement est un outil au service de votre organisation : bien dosé, il fait de Business Central un ERP adapté à votre métier ; mal dosé, il le rend coûteux à faire vivre.

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.