Dynamics NAV ou Business Central : la décision, pas la fiche produit
Dynamics NAV et Business Central sont la même lignée de produit : comparer leurs listes de fonctionnalités ne tranchera rien. La décision est forcée par trois choses qui n’ont rien à voir avec les fonctions : le calendrier de support, le fait que vos développements devront être réécrits dans un autre langage quelle que soit la destination, et les parties de votre code qu’un service cloud refusera d’exécuter. Tout le reste, Copilot compris, peut attendre.
Nous écrivons depuis une position précise. Nous déployons Business Central, et nous avons fait passer une base de code Dynamics NAV d’environ 660 objets sur Business Central SaaS, puis vécu avec elle pendant deux ans de mises à jour. Les chiffres ci-dessous viennent de l’historique de ce dépôt, pas d’une plaquette.
Business Central est-il vraiment un autre produit que Dynamics NAV ?
Non. Business Central est le nom que NAV a pris en 2018. La version 14 de Business Central, la sortie du printemps 2019, est la dernière qui exécutait encore C/AL, le langage de développement de NAV. À partir de la version 15, la seule façon de personnaliser le produit est AL, et la seule façon de livrer de l’AL est une extension posée à côté de l’application de base, sans la modifier.
Cette phrase contient tout le comparatif. L’application de base est la même famille. Ce qui a changé, c’est la manière de la personnaliser, l’endroit où elle tourne, et le rythme auquel elle bouge. Business Central en ligne reçoit une mise à jour majeure chaque avril et chaque octobre, avec une mineure les mois intermédiaires ; chaque majeure arrive avec une préversion environ un mois avant et une fenêtre de cinq mois pour la planifier. NAV bougeait quand vous décidiez de monter de version. Business Central en ligne bouge, que vous l’ayez décidé ou non.
La question n’est donc jamais « NAV ou Business Central ». C’est « quelle version de NAV faisons-nous tourner aujourd’hui, et que faudrait-il pour faire tourner le Business Central actuel à la place ».
Qu’est-ce qui force vraiment la décision ?
Trois choses, et une seule est une date.
Le calendrier de support. Dynamics NAV 2018 est la dernière version de NAV qui existera jamais. Son support standard s’est terminé le 10 janvier 2023. Le support étendu se termine le 11 janvier 2028. Support étendu veut dire correctifs de sécurité et support payant hors sécurité ; Microsoft n’accepte aucune modification de conception ni nouvelle fonctionnalité pendant cette phase. NAV 2017 suit le 11 janvier 2027 ; toutes les versions antérieures ont déjà dépassé la leur. Si vous êtes sur NAV 2018 ou NAV 2017 aujourd’hui, vous avez une date de fin fixe. Si vous êtes sur plus ancien, vous l’avez déjà dépassée.
Le langage. Tous vos développements sont écrits en C/AL. Business Central exécute de l’AL. L’outil qui convertit C/AL en AL, Txt2Al, n’est livré qu’avec la version 14 de Business Central et n’est plus fourni depuis la version 21. Le chemin de conversion passe donc toujours par un environnement en version 14, quelle que soit la version visée. Il n’existe aucune route qui permette de garder C/AL, Business Central on-premises compris. C’est la partie de la décision qui n’en est pas une : si vous quittez NAV, votre code est converti.
La frontière du cloud. Celle-là est un choix. Business Central on-premises exécute encore l’interopérabilité .NET et lit encore des fichiers sur le disque d’un serveur. Business Central en ligne ne fait ni l’un ni l’autre. Le guide de migration de Microsoft est sans détour : l’interopérabilité .NET n’est pas disponible en ligne, et ces parties doivent être reconçues. Si votre code NAV s’appuie sur des assemblies .NET, un partage de fichiers, une file de messages ou un lien vers une base externe, l’édition en ligne refusera le code tel qu’il est écrit. C’est la frontière entre une montée de version et une réécriture.
Qu’a réellement changé le passage d’un vrai code NAV sur Business Central SaaS ?
Voici ce que dit l’historique du dépôt, dans l’ordre.
La conversion de syntaxe a pris une journée. Le premier commit après le dépôt vide est la sortie de Txt2Al : environ 660 fichiers et 190 000 lignes qui arrivent d’un coup. 257 pages, 180 tables, 69 codeunits, 4 états, un XMLport. Le manifeste déclarait un runtime 3.0 et une application en version 14. Deux ans plus tard, le même manifeste déclare un runtime 15.1 sur une application 26. La distance entre ces deux chiffres, c’est le projet.
Le nettoyage a touché presque tous les fichiers. Les commits suivants sont mécaniques : retirer les instructions with, dépréciées pour le cloud, remplacer les identifiants d’objets par des noms, supprimer les variables inutilisées. Le seul retrait des with a réécrit 618 fichiers. Rien n’est difficile ; tout doit être fait avant de compiler.
Le bloc .NET a été supprimé en entier. Le code converti portait un fichier déclarant 144 types .NET répartis sur 26 assemblies : flux de fichiers, répertoires, requêtes HTTP, objets JSON, une table de données, un client de file de messages d’entreprise, et quatorze add-ins client. Aujourd’hui il ne reste plus une seule référence .NET. Ce qui les a remplacés, c’est ce que Business Central fournit nativement : HttpClient dans 6 fichiers, les types JSON dans 37, les blobs temporaires dans 55, le stockage isolé dans 5. Les téléversements de fichiers sont devenus des téléversements de flux ; l’import Excel qui écrivait un fichier sur le serveur ouvre désormais le classeur depuis un flux.
Une chose que le cloud a refusée, et la solution. NAV utilisait l’évaluateur d’expressions d’une table de données .NET comme moteur de calcul gratuit. Rien de tel n’existe dans le cloud. La cible du manifeste est passée d’on-premises à cloud un mardi, est revenue en arrière le même jour quand cette dépendance a fait surface, puis est passée en cloud pour de bon trois jours plus tard, une fois qu’un petit analyseur d’expressions avait été écrit en AL : environ 160 lignes et une table de pile. C’est la forme de chaque problème de frontière cloud que nous avons rencontré depuis. Petit, invisible dans la liste des objets, et bloquant tant qu’il n’est pas résolu.
Les modifications d’objets de base sont devenues des événements. NAV permettait de modifier les objets de Microsoft eux-mêmes. La conversion a transformé ces modifications en 95 extensions de page et 51 extensions de table, garées dans un dossier de quarantaine. Aujourd’hui l’application compte 118 extensions de page, 72 extensions de table, et environ 210 abonnés à des événements. Les abonnés sont plus nombreux que les extensions. Voilà à quoi ressemble « personnaliser sans modifier » en pratique : l’essentiel de ce qui était du code inséré dans une codeunit Microsoft est devenu une méthode qui écoute le moment où cette codeunit publie.
La bascule SaaS a supprimé plus qu’elle n’a ajouté. Dix-sept mois après la conversion, le commit qui a posé l’application sur son socle SaaS a modifié 317 fichiers, en ajoutant 4 000 lignes et en retirant 20 000. Une app d’export et une app de support avaient déjà été détachées du monolithe avant la bascule ; deux semaines après, une app API et une app d’intégration ont suivi. Rien de ce découpage ne faisait partie de la migration elle-même. La migration consistait à faire tourner le code. L’architecture s’est construite autour, avant et après.
Ce qu’elle a laissé derrière elle. L’application porte 128 déclarations d’obsolescence dans ses objets, parce que dans un tenant SaaS en production on ne supprime jamais une colonne : on la marque obsolète et on attend une vague. Et son app de test contient 17 tests, non branchés sur la chaîne de build. C’est le coût honnête d’une conversion où le budget part dans le fait de compiler. Nous n’en commencerions plus une aujourd’hui sans appliquer dès le premier commit la discipline de mise à jour de nos extensions AL.
Qu’est-ce qui peut attendre ?
Les fonctionnalités. L’écart fonctionnel entre NAV 2018 et le Business Central actuel est réel, et ce n’est pas la raison de migrer. Copilot, le client moderne, les connecteurs Power Platform, le flux d’améliorations deux fois par an : tout cela arrive tout seul une fois que vous êtes sur la plateforme, et rien de tout cela n’est accessible tant que vous n’y êtes pas. Décider sur les fonctionnalités, c’est décider sur des choses que vous obtiendrez de toute façon.
L’autre sujet qui peut attendre, c’est la question cloud ou on-premises, mais seulement un temps. Business Central on-premises vous donne AL, les extensions et l’application de base actuelle tout en vous laissant garder .NET et l’accès aux fichiers. C’est un point d’atterrissage légitime pour un code qui porte de lourdes dépendances de frontière cloud. Ce n’est pas un endroit où rester. Les montées de version vous appartiennent, et la frontière que vous avez repoussée est toujours là.
Que coûte l’attente ?
Chaque développement que vous écrivez en C/AL d’ici au passage sera écrit deux fois. Les 660 objets ci-dessus étaient le compte le jour de la conversion. Une équipe qui continue à construire sur NAV pendant trois ans convertit une base plus grosse avec le même outillage, sur la même passerelle en version 14, avec moins de gens qui lisent encore C/AL.
Le support étendu est un second coût qui a l’air gratuit. Les correctifs de sécurité continuent jusqu’en janvier 2028. Les évolutions de conception et les nouvelles fonctionnalités s’arrêtent, et la loi de votre pays, elle, ne s’arrête pas. Si les règles de facturation ou de déclaration bougent là où vous opérez, la fonctionnalité qui les suit est quelque chose que vous construisez vous-même, en C/AL, puis une seconde fois en AL.
Le troisième coût est celui que personne ne budgète : l’inventaire de ce dont votre code dépend. Chaque mois passé sur NAV ajoute un état, une intégration, un appel .NET. Chacun est une ligne dans l’inventaire qu’une équipe de migration devra produire avant de pouvoir vous chiffrer. Cet inventaire coûte moins cher maintenant que plus tard, et c’est le même inventaire dans tous les cas.
Comment menons-nous cette décision chez Asio Services ?
Nous ne commençons pas par une démo. Nous commençons par trois comptages, et une base NAV les donne en une journée.
Combien d’objets Microsoft avez-vous modifiés ? Pas combien d’objets spécifiques vous possédez. Ce sont les modifications d’objets de base qui doivent devenir des extensions et des événements, et ce sont elles qui fixent la taille du projet. Les tables et pages spécifiques se convertissent presque telles quelles.
Vers quoi le code sort-il de la base de données ? Assemblies .NET, partages de fichiers, imprimantes, automation COM, files de messages, SQL direct. Chaque élément de cette liste est une reconception, pas une conversion. La longueur de la liste décide si Business Central en ligne est une destination ou une seconde étape après l’on-premises.
Quels développements ne faut-il pas réécrire du tout ? Une large part de ce que porte un code NAV couvre des manques que le Business Central actuel a comblés depuis. Nous avons écrit à part sur les personnalisations Business Central qui n’auraient jamais dû être écrites. La conversion est le seul moment où supprimer ne coûte rien.
Avec ces trois comptages, la décision cesse d’être NAV contre Business Central et devient un plan daté : quelle passerelle en version 14, quelle édition d’atterrissage, quel trimestre. Les sept phases d’une migration NAV vers Business Central en découlent, et notre service de migration Dynamics NAV vers Business Central les exécute. Si vous voulez les trois comptages avant de vous engager, demandez-nous un diagnostic de clarté.
FAQ
Peut-on rester sur Dynamics NAV après janvier 2028 ? Techniquement, oui. Le logiciel continue de tourner. Ce qui s’arrête, c’est toute forme de support de Microsoft, correctifs de sécurité compris. À partir de cette date, chaque risque du système est le vôtre, et un partenaire qui accepte de le maintenir prend ce risque avec vous.
Business Central on-premises permet-il d’éviter de réécrire notre code ? Non. Business Central on-premises exécute, depuis la version 15, uniquement de l’AL et des extensions, exactement comme l’édition en ligne. Ce qu’il vous laisse garder, c’est l’interopérabilité .NET et l’accès aux fichiers du serveur. La conversion C/AL est identique. Seule la reconception de la frontière cloud est repoussée.
Combien de temps a pris la conversion décrite ci-dessus ? La conversion C/AL vers AL a été livrée en une journée. Le nettoyage qui l’a fait compiler a pris environ deux semaines de travail module par module. Retirer les dépendances .NET et rendre l’application conforme au cloud a pris cinq mois de plus. La bascule SaaS est venue dix-sept mois après la conversion, le découpage en applications satellites s’étalant de part et d’autre.
L’écart fonctionnel entre NAV 2018 et Business Central compte-t-il ? Pas pour la décision. L’écart est large, et il se comble tout seul une fois que vous êtes sur la plateforme. Décider sur les fonctionnalités mène à un comparatif de produits, et ceci n’est pas un comparatif de produits. C’est une date, un langage, et une liste de dépendances.