Huit mois de NAV à Business Central SaaS. Trois ans pour pouvoir y toucher sans peur.

Ce qu’on vous vend est la partie qui prend une journée

Microsoft livre un convertisseur. Vous le pointez sur du C/AL, il sort de l’AL. Sur ce projet, cette étape tient dans une seule journée de travail : tout le code spécifique, ressorti en AL qui compile.

Si la migration se résumait à la conversion, le projet aurait été fini cette semaine-là.

Lisez les messages de commit du même jour et vous voyez ce que le convertisseur a réellement rendu. remove with and fix identifiers. remove unused vars. convert obj ids to names. remove empty sections. L’outil a produit de l’AL correct et inmaintenable : références d’objets encore numériques, blocs with qui cachent encore à quel enregistrement appartient un champ, variables mortes abandonnées des années plus tôt et que personne n’avait jamais été obligé de regarder.

Ce n’est pas un défaut de l’outil. Le travail d’un convertisseur est de préserver le comportement, et il l’a fait. Mais sa sortie est une traduction, pas une conception. Se l’approprier est un chantier à part, et personne ne le chiffre parce que personne ne le voit sur la démo.

Les tests sont passés avant le comportement, pas après

Trois semaines après la conversion, une app de test dédiée apparaît dans le dépôt avec son propre manifeste, à côté de l’app principale.

L’ordre est ce qui compte. À ce moment-là, le code converti était encore la traduction fidèle d’un système dont le comportement était documenté surtout dans la tête des gens qui l’utilisaient. Le moindre nettoyage, le moindre refactor, la moindre tentative de rendre le code lisible aurait été une modification d’un système dont personne ne pouvait prouver qu’il marchait toujours.

Le harnais est donc passé en premier. Pas pour atteindre un taux de couverture, mais pour rendre prouvables les trois années d’évolutions suivantes. Tout ce que cette page affirme sur le système d’aujourd’hui repose sur cette décision, et chaque montée de version silencieuse depuis aussi. C’est le seul enchaînement qu’on ne négocie pas sur une migration Dynamics NAV vers Business Central, quoi qu’en dise la date de mise en production.

On n’est pas allés au SaaS directement, et c’est ce qui a fait tenir la date

Le système est passé sur la version majeure de Business Central le mois même de sa sortie, mais en on-premise. Il y est resté cinq mois. La bascule dans le SaaS a eu lieu la veille de la vague majeure suivante.

Ce détour a l’air d’un délai. C’est l’inverse. Rester on-premise sépare deux chantiers qui, menés ensemble, se contaminent : est-ce que le code converti se comporte comme l’ancien système, et est-ce que ce code est seulement admissible dans le cloud. Deux questions, deux réponses, deux moments où l’on peut revenir en arrière sans tout redéfaire.

Parce que la seconde question a une réponse dure. Le cloud interdit l’interop .NET, et un NAV de cette génération en est truffé. Le dépôt garde la trace exacte du mur : en quatre jours, la cible du manifeste bascule trois fois. target onprem to handle dotnet. Puis revert back to use dotnet DataTable. Puis target cloud, et ce dernier commit ne change pas qu’un réglage, il remplace le code .NET par de l’AL écrit pour l’occasion.

Quatre jours sur un seul point, et ce point n’apparaît sur aucune démo de convertisseur. Si votre spécifique appelle du .NET, le convertisseur vous rendra de l’AL qui compile et qui ne sera jamais publiable en SaaS. Vous le découvrirez au déploiement, pas au chiffrage.

Le monolithe est resté un monolithe pendant dix-huit mois

Voilà le fait qui surprend, et celui qui vaut la peine d’être volé.

Le code converti est parti en production sous forme d’une seule app. Il l’est resté un an et demi, SaaS compris. Puis un premier module a été détaché, trois autres ont suivi ensemble six mois plus tard. Le même code, aujourd’hui, c’est treize manifestes.

Découper tôt un monolithe converti est une erreur tentante. Vous ne savez pas encore où sont ses vraies coutures, parce que celles que vous voyez sont celles qu’imposaient les limites techniques de l’ancien système, pas celles que le métier a réellement. Découpez là-dessus et vous obtenez treize apps qu’il faut toutes livrer ensemble : le coût de la modularité, sans aucun de ses bénéfices.

Ce sont dix-huit mois d’exploitation réelle qui ont révélé quelles pièces bougeaient à leur propre rythme. Ce sont les coutures. Couper là, c’est ce qui transforme une livraison de « on reteste tout » en « on livre la seule pièce qui a changé ».

Ce que les trois ans ont vraiment acheté

Pas des fonctionnalités. Elles étaient déjà là, encodées dans des années de logique spécifique qu’aucun module standard ne pouvait absorber. C’est précisément pour ça qu’une réimplémentation à blanc n’a jamais été sur la table.

Pas non plus la date de mise en production : elle était tenue au bout de huit mois.

Ce que ces trois ans ont acheté, c’est la capacité à changer le système. Un harnais de tests qui rend une modification prouvable. Des modules livrables un par un. Une chaîne d’intégration qui compile et teste à chaque commit au lieu de le faire sur le poste d’un développeur. Des noms d’objets au lieu de numéros, pour qu’un nouveau développeur puisse lire une référence de table et comprendre ce qu’elle désigne. Et, depuis le passage dans le SaaS, des montées de version majeures qui arrivent d’elles-mêmes au lieu d’être des projets.

Trois ans après, ça livre toujours. Le dernier correctif en date porte sur une notification qui ne se déclenchait jamais. De la maintenance ordinaire, par qui est de service. C’est ça, une migration finie : pas une date de mise en production, mais un système qu’une équipe normale peut continuer à faire évoluer sans peur.

Si on vous chiffre une conversion

Demandez ce qui se passe le jour deux.

Un devis qui s’arrête à « le code compile en AL » vous chiffre la journée la moins chère et la moins risquée du projet. Les questions qui décident de vos trois prochaines années viennent après : ce qui prouve que le comportement a survécu, ce que devient votre code .NET une fois dans le cloud, quand les modules sont découpés et sur quelle base, et qui peut modifier le système sans danger une fois l’équipe de migration partie.

La liste complète des questions est dans notre checklist de migration Dynamics NAV vers Business Central. Si vous avez déjà un code converti et que personne ne sait vous dire dans quel état il est, c’est précisément à ça que sert le bilan de clarté Business Central.