La plupart des personnalisations Business Central n’auraient jamais dû être écrites

La plupart des demandes de personnalisation Business Central se règlent par un paramétrage, une modification de profil ou une conversation — pas par du code AL. La question n’est pas de savoir si le besoin est réel : il l’est presque toujours. La question est de savoir si la différence qu’il décrit fait partie des raisons pour lesquelles l’entreprise gagne. Tout le reste devient un engagement permanent, à honorer deux fois par an, aussi longtemps que le code existe.

Ce n’est pas un plaidoyer contre le spécifique. Nous avons construit l’une de nos plus grosses applications AL parce qu’aucun ERP standard ne savait modéliser le métier ; nous avons aussi livré Business Central avec quasiment zéro ligne de code, parce que le standard couvrait le besoin. Ce qui distingue ces deux projets n’est ni la taille ni le budget : c’est que quelqu’un a challengé la demande avant qu’elle devienne un ticket.

Qu’est-ce qui compte vraiment comme une personnalisation ?

Beaucoup moins de choses qu’on ne le croit — et c’est là que l’argent fuit en premier. Business Central propose quatre niveaux de modification, et seul le dernier relève du code.

La personnalisation utilisateur est individuelle : chacun ouvre une page, passe en mode personnalisation, déplace, masque, fige ou ajoute des champs. Cela n’affecte personne d’autre et ne coûte rien.

La personnalisation de profil (rôle) relève de l’administrateur. Elle s’applique à tous les utilisateurs du rôle, et elle permet quelque chose que la personnalisation individuelle ne permet pas : afficher des champs présents dans la table source de la page ou dans des tables d’extension, mais jamais déclarés sur l’objet page. Cette seule capacité répond à une large part des demandes formulées en « il nous faut ce champ sur la commande de vente ».

Designer est l’outil glisser-déposer dans le navigateur. Il ne demande aucune ligne de code, mais soyons précis : chaque fois que vous le lancez, vous créez de fait une nouvelle extension, déployée comme n’importe quelle app. Designer n’évite pas le modèle d’extension, c’est une porte d’entrée plus douce.

Les extensions AL sont le quatrième niveau, et le seul qui crée une obligation de maintenance permanente. Tout ce qui est au-dessus reste du paramétrage, défaisable un mardi après-midi.

Une contrainte vaut pour l’ensemble : on ne personnalise pas la production directement. Tout se construit et se teste en bac à sable, puis se déploie sous forme d’app. Aucun chemin supporté ne permet d’ajuster discrètement du code en production parce qu’un directeur l’a demandé gentiment.

Quelles demandes ne devraient jamais devenir du code ?

Quatre familles font l’essentiel des personnalisations que nous retirons pendant un sauvetage.

Les demandes de mise en forme. « Ce champ devrait être plus haut », « on n’utilise jamais ces trois colonnes », « nos acheteurs veulent un autre centre de rôle ». Tout cela relève de la personnalisation ou du profil. Rien n’est du code.

Les états qui sont en réalité des vues. Une demande de rapport spécifique est très souvent une liste filtrée et regroupée que l’utilisateur pourrait enregistrer lui-même. Un objet report se maintient ; une vue enregistrée, non.

Les champs qui existent déjà sous un autre nom. Business Central modélise bien plus que ce que la plupart des implémentations exploitent. Le « champ de priorité spécifique » est souvent un champ standard que personne n’a montré en formation. Le correctif le plus rapide n’est pas un développement, c’est deux heures avec ceux qui utilisent la page tous les jours.

Les processus conservés par habitude. C’est la famille la plus coûteuse. Une entreprise demande du code qui reproduit l’enchaînement imposé par son ancien système — souvent pour des raisons qui n’existent plus. Le reproduire fidèlement, c’est faire hériter à un ERP neuf, dès le premier jour, de dix ans de contraintes qui ne sont pas les siennes. Si un processus ne s’explique pas sans citer l’ancien logiciel, ce n’est pas encore un besoin.

Quel est le test qui tranche ?

Demandez si la différence fait partie des raisons pour lesquelles l’entreprise gagne.

Le standard existe parce que des milliers d’entreprises font la même chose à peu près de la même façon. Si la vôtre aussi, y rester n’est pas un compromis : c’est un chemin de mise à jour gratuit, à vie. Le spécifique se justifie quand la différence est structurelle : une obligation réglementaire que personne d’autre ne porte, une réalité physique ou métrologique absente du modèle de données standard, ou une manière d’opérer qui est réellement ce qui fait choisir l’entreprise.

C’est la ligne que nous tenons, et elle coupe dans les deux sens. L’une de nos plus grosses applications couvre une chaîne d’approvisionnement de matières en vrac où les livraisons sont valorisées à partir de mesures de laboratoire — un taux d’humidité converti en pouvoir calorifique, puis en unités d’énergie — et où la certification durable suit chaque chargement et chaque règlement. Aucun ERP standard ne modélise cela, aucun paramétrage n’y mène. Elle se met à jour proprement et reste maintenable, parce que la décision de la construire a été délibérée et non accumulée.

La même discipline a produit le résultat inverse ailleurs : un déploiement Business Central avec quasiment aucun code spécifique, parce que le standard répondait vraiment. Si votre partenaire de développement Business Central ne vous dit jamais « celle-là, il ne faut pas la construire », vous n’achetez pas du jugement d’ingénierie. Vous achetez de la capacité.

Que coûte réellement une personnalisation après la mise en production ?

Le prix de construction est le plus petit chiffre de l’équation, et personne ne chiffre le reste.

Business Central en ligne livre deux majeures par an, en avril et en octobre, avec des mineures les mois intermédiaires. Chaque extension doit suivre. Quand une majeure sort, les administrateurs ont cinq mois pour la planifier. Vient ensuite un mois de délai de grâce — septembre pour la vague d’avril, mars pour celle d’octobre — où la mise à jour ne peut plus être repoussée. Après quoi commence la période contrainte : toute extension qui fait échouer la mise à jour peut être désinstallée automatiquement. Ses données ne sont pas supprimées et se récupèrent en installant une version compatible, mais tant que personne ne le fait, le code ne tourne plus et les données qu’il devait capturer ne le sont pas. Si l’extension bloque une mise à jour de sécurité critique, la fenêtre est bien plus courte : la désinstallation peut intervenir sous 14 jours.

Deux précisions pour budgéter honnêtement. Microsoft annonce les changements cassants au moins un an à l’avance : c’est un problème de planification, pas une embuscade. Et les tests de compatibilité réalisés avant une majeure sont techniques : ils vérifient que le code compile et s’installe. La validation fonctionnelle et logique reste à la charge de celui qui publie l’extension. Du code spécifique peut passer tous les contrôles automatiques et se comporter faussement après une mise à jour, d’une façon que seul le métier remarquera, à la clôture.

Le prix honnête d’une personnalisation n’est pas le devis. C’est ce devis plus l’obligation récurrente de tester, ajuster et redéployer, deux fois par an, sur toute la vie du système. Dix petites personnalisations que personne n’a challengées ne coûtent pas dix petites sommes : elles coûtent un engagement permanent à honorer à chaque vague, budgété ou non. C’est l’une des causes racines les plus fréquentes quand un projet Business Central s’est discrètement arrêté de fonctionner — non pas une décision catastrophique, mais des dizaines de décisions raisonnables.

Pourquoi les intégrateurs disent-ils oui aussi souvent ?

Parce que dire oui est facturable et que challenger ne l’est pas.

Aucun complot, juste une incitation qui pointe dans une seule direction. Une demande arrive, elle est spécifiée, chiffrée, développée, facturée, puis génère de la maintenance. Challenger coûte une réunion difficile, retarde la signature et réduit le périmètre : un intégrateur qui le fait systématiquement choisit une facture plus petite.

Nous pensons que la répartition des rôles est l’inverse. Le travail du client, c’est d’exprimer un besoin clair, avec des mots simples, sans pré-écrire la solution. Le nôtre, c’est de le challenger — le clarifier, l’affiner, le mettre en forme — avant que quiconque ouvre un éditeur de code. Un client qui arrive avec la spécification de ce qu’il faut construire a le plus souvent sauté la seule étape qui détermine si cela doit exister. Au moment de choisir un partenaire, la question utile n’est pas « savez-vous construire ça ? », c’est « quand avez-vous dissuadé un client pour la dernière fois ? ».

Que faire d’un système déjà saturé de spécifique ?

On l’inventorie avant d’y toucher, et on le trie en quatre paniers.

Ce qui sert réellement — la télémétrie et une semaine d’observation le disent, et c’est couramment une fraction de ce qui existe. Ce qui double une fonction standard rattrapée depuis, car Business Central absorbe des capacités à chaque vague : la personnalisation justifiée d’hier devient redondante. Ce qui est structurel et doit rester. Et ce qui n’a jamais été justifié mais porte des données : catégorie difficile, on ne la supprime pas, on la remigre dans le standard.

Retirer du code est plus lent que d’en écrire et personne n’en tire de gloire : voilà pourquoi cela n’arrive jamais tout seul. C’est pourtant le levier le plus efficace pour réduire le coût des deux prochaines montées de version. Quand une app du marché peut remplacer quelque chose que vous maintenez vous-même, prenez l’échange : certaines des extensions AL qui valent le détour existent précisément pour supprimer toute une catégorie de code spécifique de votre parc.

L’approche Asio Services

Nous ne portons pas le « zéro spécifique » comme une décoration. Chaque ligne doit mériter sa place, et continuer à la mériter deux fois par an. Parfois cela donne une application volumineuse et sur mesure, parce que l’entreprise opère d’une façon qu’aucun produit standard ne modélise. Plus souvent, un paramétrage, une formation, ou une conversation qui se termine par le retrait de la demande — parce que c’était une vraie frustration avec une fausse solution.

Si vous arbitrez une liste de personnalisations, ou si vous vivez avec un système qui en porte trop, commencez par notre formulaire de clarté. La clarté avant le code n’est pas un slogan : c’est l’ordre dans lequel le travail doit se faire.

FAQ

Personnaliser Business Central est-il une mauvaise idée ?

Non. La mauvaise idée, c’est de personnaliser sans filtre sur la légitimité de la demande. Le modèle d’extension est conçu pour ajouter des fonctions en sécurité : le risque n’est pas le mécanisme, c’est ce qu’on y laisse passer.

Comment savoir si une demande relève du code ou du paramétrage ?

Remontez les niveaux avant de chiffrer : un utilisateur peut-il le faire en personnalisation, un administrateur en profil, est-ce faisable dans Designer, et seulement ensuite faut-il de l’AL. Une part surprenante des demandes formulées comme du développement s’arrête à la deuxième.

À quelle fréquence faut-il maintenir une personnalisation ?

Au minimum deux fois par an, sur les majeures d’avril et d’octobre. Une extension qui bloque une majeure peut être désinstallée automatiquement dès l’ouverture de la période contrainte, et sous 14 jours si elle bloque une mise à jour de sécurité critique.

Microsoft teste-t-il mes développements avant une mise à jour ?

Techniquement seulement. Microsoft vérifie la compatibilité pour que la mise à jour puisse se dérouler, mais la validation fonctionnelle et logique reste à la charge de celui qui a publié l’extension. Du code qui s’installe proprement peut malgré tout se comporter faussement.

Peut-on retirer des personnalisations devenues inutiles ?

Oui, et cela en vaut la peine — mais pas par simple suppression. Tout ce qui porte des données exige de les remigrer d’abord dans le standard. Commencez par mesurer ce qui sert réellement : c’est bien moins que ce qui existe.