Le développement Business Central est rarement le premier levier à actionner. Dans la plupart des projets, l’essentiel du besoin se couvre par le paramétrage et par des applications existantes ; le code ne vient qu’en dernier recours, pour le processus que le standard ne sait pas porter. Cette page vous aide à situer chaque demande au bon niveau, à mesurer l’effet sur les mises à jour et à choisir le bon interlocuteur.
Si vous ne connaissez pas encore le produit, commencez par la présentation de Business Central et la liste des modules disponibles.
Les trois niveaux de personnalisation de Business Central
Personnaliser Business Central ne veut pas dire coder. On distingue trois niveaux, du plus léger au plus lourd, et la règle est de ne monter d’un niveau que lorsque le précédent a échoué.
| Niveau | Ce que c’est | Compétence requise | Effet sur les mises à jour |
|---|---|---|---|
| Paramétrage | Réglages, plan comptable, flux de validation, rôles, vues | Consultant fonctionnel | Aucun |
| Extension existante | Application installée depuis Microsoft Marketplace | Consultant, parfois administrateur | Dépend de l’éditeur de l’application |
| Développement spécifique | Extension écrite en AL pour votre besoin | Développeur Business Central | À tester à chaque évolution |
Niveau 1 : le paramétrage
Avant toute extension, vérifiez ce que le standard sait déjà faire. Un grand nombre de demandes tiennent en un réglage : une dimension analytique de plus, un circuit d’approbation, une présentation de page adaptée à un rôle, un état personnalisé. Le paramétrage est le seul niveau qui ne crée aucune dépendance technique : il suit la solution à chaque mise à jour.
Le Designer, intégré au client, va un peu plus loin sans code : il permet de réorganiser ou d’ajouter des champs sur une page par glisser-déposer et de prévisualiser le résultat. C’est adapté aux ajustements d’ergonomie, pas aux règles métier.
Niveau 2 : les extensions existantes
En ligne, on étend Business Central par des applications, appelées extensions, installées depuis Microsoft Marketplace. Des pages dédiées aux applications de connectivité et aux applications bancaires proposent par exemple des connexions à des services externes, comme l’import de transactions bancaires.
Un autre exemple parlant : le connecteur Shopify synchronise produits, stocks, clients, commandes, expéditions, transactions et versements entre la boutique et l’ERP, prend en charge plusieurs boutiques et peut s’automatiser en arrière-plan grâce à la file de travaux. Reconstruire cela à la main serait un chantier inutile. Pour les autres connexions, consultez la page sur les intégrations et connecteurs.
Une application du catalogue n’est toutefois pas gratuite en maintenance : vérifiez qui la maintient, si elle suit les évolutions de la version en ligne et si sa licence convient à votre volume d’utilisateurs.
Niveau 3 : le développement spécifique en AL
Quand ni le paramétrage ni le catalogue ne répondent, on écrit une extension. Business Central se personnalise par des extensions rédigées en langage AL dans Visual Studio Code : le développeur ajoute ou modifie des tables, des pages, des codeunits et des rapports sans toucher au code de base. Le résultat est compilé en fichiers .app, que l’on installe dans un environnement.
Cette architecture est la garantie principale de votre capacité à mettre à jour : votre code vit à côté du standard, pas dedans. C’est ce qui distingue Business Central d’anciens ERP où la personnalisation modifiait directement le cœur du logiciel.
Quand un module sur mesure Business Central se justifie
Un module sur mesure Business Central est légitime dans quelques situations bien identifiées :
- un processus métier qui constitue votre avantage concurrentiel et que le standard ne couvre pas ;
- un état réglementaire ou client très spécifique à votre activité ;
- une règle de calcul propre à votre secteur, par exemple dans la production ou les stocks et achats ;
- une interface avec un système interne ancien qu’aucun connecteur ne dessert.
À l’inverse, méfiez-vous des demandes qui visent à reproduire à l’identique l’ancien ERP. Un cahier des charges qui décalque l’existant produit presque toujours du code évitable. Le guide du cahier des charges ERP explique comment exprimer un besoin en objectifs plutôt qu’en écrans à copier.
Les API et les intégrations sur mesure
Beaucoup de développements sur mesure concernent en réalité la connexion avec d’autres outils. Business Central expose une API REST (v2.0) pour relier l’ERP à des solutions tierces, activée par défaut en ligne. Deux contraintes doivent entrer dans le chiffrage :
- l’ajout de champs à une API standard n’est pas possible : il faut copier le code AL et créer une API personnalisée ;
- les limites d’appels OData V4 s’appliquent par utilisateur : 5 requêtes simultanées, 100 connexions et une fenêtre glissante de 6 000 requêtes sur 5 minutes. Au-delà, le service répond par un code HTTP 429.
Microsoft recommande d’utiliser l’API ou OData plutôt que SOAP, appelé à être déprécié. Une intégration conçue aujourd’hui sur SOAP est donc une dette technique annoncée. Un flux qui envoie une requête par ligne de commande peut aussi heurter ces limites : un bon développeur conçoit des échanges groupés et gère les relances.
L’impact sur les mises à jour
C’est la question que les dirigeants et les DSI posent le plus : « si on développe, pourra-t-on encore mettre à jour ? ». La réponse honnête est : oui, à condition de respecter quelques principes.
- Rester dans le cadre des extensions. Aucune modification du code de base : tout passe par l’extension.
- Tester avant chaque évolution. Les mises à jour de la version en ligne sont gérées côté éditeur ; il faut donc vérifier vos extensions dans un environnement de test avant qu’elles n’atteignent la production. Pour comprendre les rythmes et les éditions, voyez la page versions et éditions.
- Limiter le périmètre. Chaque extension est une surface de test en plus. Peu d’extensions, bien ciblées, valent mieux qu’un empilement.
- Prévoir la maintenance. Un développement sans contrat de support et maintenance devient un risque le jour où son auteur n’est plus disponible.
Utiliser le bac à sable pour développer et tester
Les environnements bac à sable 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 y sont bloqués tant qu’ils ne sont pas autorisés extension par extension. Ce dernier point surprend souvent : un test d’intégration qui échoue en bac à sable n’est pas forcément un bogue, c’est parfois une autorisation à accorder.
Un environnement Business Central peut en outre ê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 pour les intégrations avec Power Platform et d’autres produits Dynamics 365. Il faut le décider tôt, car il conditionne l’architecture des automatisations.
Les bonnes pratiques pour un développement durable
Un projet de personnalisation réussi ressemble à un projet logiciel sérieux, pas à une série de dépannages.
Rester au plus près du standard
Chaque écart au standard a un coût : de conception, de test, de formation et de maintenance. Posez la question « que se passe-t-il si nous adaptons notre processus plutôt que le logiciel ? ». Dans beaucoup de cas, le processus gagne à être simplifié, et le standard de Business Central, déjà riche en comptabilité et finance comme en ventes et CRM, suffit.
Documenter
Exigez pour chaque extension :
- une spécification fonctionnelle qui explique le besoin et la règle métier ;
- une description technique : objets créés, événements utilisés, dépendances ;
- un jeu de scénarios de test ;
- le code source, qui vous appartient et doit vous être remis.
Sans cela, vous dépendez d’une seule personne. C’est la cause la plus fréquente de reprise de projet difficile ; si vous en êtes là, un audit de projet Business Central permet d’évaluer l’état réel du code.
Tester sérieusement
Un développement se teste à trois niveaux : le développeur vérifie son code, l’intégrateur contrôle la cohérence avec le reste du paramétrage, et vos utilisateurs clés valident le scénario réel avec des données représentatives. Ne signez jamais la recette sur la seule démonstration d’un cas nominal : testez les cas limites, les erreurs de saisie et les volumes.
Penser aux utilisateurs
Un module qui complique la saisie sera contourné. Impliquez vos utilisateurs dès la conception, et prévoyez une formation sur le nouveau fonctionnement.
Comment évaluer un développeur ou un intégrateur Business Central
Le développement spécifique est un métier à part entière. Un bon consultant fonctionnel n’est pas forcément un bon développeur AL, et inversement. Voici les critères à vérifier.
| Critère | Ce qu’il faut demander |
|---|---|
| Méthode | Comment les besoins sont-ils spécifiés, validés et priorisés ? |
| Qualité | Comment le code est-il relu et testé ? Utilise-t-il un bac à sable ? |
| Documentation | Que recevez-vous à la livraison, et le code source vous est-il remis ? |
| Mises à jour | Qui teste vos extensions lors d’une évolution, et dans quel délai ? |
| Maintenance | Qui corrige un défaut après la livraison, et sous quel engagement ? |
| Références | Des projets comparables, dans votre secteur, que vous pouvez faire vérifier ? |
| Conseil | Sait-il vous orienter vers le standard ou une application plutôt que du code ? |
Méfiez-vous de deux profils opposés : celui qui répond « oui, c’est faisable » à toute demande sans discuter de l’alternative, et celui qui refuse toute adaptation. Le bon partenaire pèse chaque demande. Pour structurer votre sélection, lisez le guide pour choisir un intégrateur ERP et la page dédiée à l’intégrateur Business Central.
Précisons notre rôle : nous ne développons pas et ne sommes affiliés à aucun éditeur. Nous vous mettons en relation avec un intégrateur adapté à votre projet, et c’est lui qui réalise et assume le travail. Le fonctionnement est détaillé sur la page comment ça marche.
Budget : ce qu’il faut savoir avant de chiffrer
Le coût d’un développement dépend du périmètre, de la complexité des règles métier, du nombre d’intégrations et du niveau de test exigé. Aucun chiffre sérieux ne peut être avancé sans cadrage. Demandez systématiquement un chiffrage séparé pour la réalisation et pour la maintenance annuelle de chaque extension : le second poste est celui que l’on oublie. Les principes généraux du budget sont décrits sur la page prix de Business Central.
Pour une mise en œuvre complète, où le sur mesure n’est qu’un volet, la page sur la mise en place de Business Central détaille les étapes du projet.
Questions fréquentes
Dans quel langage fait-on le développement Business Central ?
Business Central se personnalise par des extensions écrites en langage AL, dans Visual Studio Code. Elles ajoutent ou modifient des tables, des pages, des codeunits et des rapports sans toucher au code de base, et sont compilées en fichiers .app. Le Designer intégré au client permet aussi d’ajuster des pages par glisser-déposer.
Une personnalisation Business Central bloque-t-elle les mises à jour ?
Une extension bien conçue reste séparée du code de base, ce qui limite les conflits lors des mises à jour de la version en ligne. Le risque vient plutôt d’une extension qui dépend de comportements non documentés ou qui n’est pas testée avant chaque évolution. Un bac à sable de test et une documentation à jour réduisent ce risque.
Peut-on ajouter un champ à une API standard de Business Central ?
Non : l’ajout de champs à une API standard n’est pas possible. Il faut copier le code AL de l’API et créer une API personnalisée qui expose les champs voulus. C’est un exemple de besoin courant qui relève du développement spécifique, à chiffrer et à maintenir comme tel.
Faut-il développer sur mesure ou chercher une application du catalogue ?
Commencez par le paramétrage, puis par les applications proposées sur Microsoft Marketplace, qui étendent Business Central sans développement. Le sur mesure se justifie quand un processus qui vous différencie n’est couvert ni par le standard ni par une application existante. Comparez toujours le coût de maintenance dans la durée, pas seulement le coût de départ.
Comment évaluer un développeur ou un intégrateur Business Central ?
Demandez comment il documente et teste ses extensions, comment il travaille en bac à sable, comment il gère les mises à jour et qui assure la maintenance après la livraison. Exigez des références vérifiables dans votre secteur et la remise du code source de vos extensions. Un bon prestataire sait aussi vous dissuader d’un développement inutile.
Sources
- Microsoft Learn — Développer pour Business Central
- Microsoft Learn — API Business Central v2.0
- Microsoft Learn — Limites opérationnelles en ligne
- Microsoft Learn — Environnements Business Central
- Microsoft Learn — Extensions et applications
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.