--- title: "Analyse NAV avec l'IA | Business Central | NAVtoBC.de" description: "Analyser Navision avec l'IA : comprendre le code C/AL, le schéma SQL et les processus métier. Planifier la migration vers Business Central et AL." url: https://navtobc.de/fr language: fr --- ANALYSE NAVISION AVEC L'IA # Comprendre Navision. Préparer la migration vers Business Central. Nous analysons Navision et Microsoft Dynamics NAV grâce à l'intelligence artificielle (IA) et à l'analyse automatisée du code C/AL. Des années d'expérience Navision font le lien entre la connaissance de vos processus, construite au fil du temps, et une vision cible claire pour Business Central. [Demander un diagnostic initial sans engagement](https://navtobc.de/fr/kontakt) [Découvrir les résultats](https://navtobc.de/fr/beispiel-ergebnisse) Le standard Business Central d'abord. Privilégier les modules certifiés. Ne développer du spécifique que de façon ciblée. NAVtoBC.de Analyse & planification de la migration VOTRE BASE DE DÉCISION ## Le savoir devient perspective. DÉMO 01 / PRIORITÉ **Standard Business Central** Exploiter les fonctionnalités 02 / EXTENSION **Modules certifiés** Remplacer le code spécifique 03 / ÉCART JUSTIFIÉ **Spécifique et ciblé** Développer le nécessaire **Les liens sont préservés** Valeurs de substitution cohérentes **Client** P-7Q4X9 **Commande** P-7Q4X9 **Facture** P-7Q4X9 **Chaque recommandation est traçable.** Avec sources, statut de vérification et décisions en suspens. **Un savoir accumulé. Un plan clair.** Analyser · documenter · prioriser Format de résultat illustratif, avec des données synthétiques. DES RÉSULTATS QUI VOUS FONT AVANCER ## Quatre résultats. Une direction claire. Pas une simple reprise du code. Vous obtenez une base documentée pour vos décisions – avec sources, statut de vérification et points ouverts. 01 / EXISTANT ### État des lieux technique Comprendre les adaptations, les interfaces et les dépendances. Vue d'ensemble des objets & graphes de références 02 / PROCESSUS ### Processus métier documentés Vérifier les déroulements, les règles et les exceptions avec vos services métier. Cartographie des processus & référentiel de règles JSON 03 / SAVOIR ### Base de connaissances structurée Préserver le savoir système accumulé, avec son origine et son statut de vérification. Articles de connaissance & références aux sources 04 / CIBLE ### Proposition de migration priorisée pour Business Central Arbitrer entre standard, modules certifiés et développements nécessaires. Matrice de décision & feuille de route LES RÉSULTATS DE L'ANALYSE EN VIDÉO ### Quatre résultats. Une direction claire. 1 min 30 · Full HD · Avec son ![Les quatre résultats de l'analyse NAVtoBC](https://navtobc.de/film/ergebnisse-v1/fr/poster.webp) [Les quatre résultats de l'analyse NAVtoBC](https://navtobc.de/film/ergebnisse-v1/fr/index.m3u8) État des lieux technique, processus métier, base de connaissances et proposition de migration – les quatre résultats en 90 secondes. Lecture en 1080p à 30 images par seconde. POURQUOI MAINTENANT ? ### Clarifier tôt. Planifier la migration avec précision. Quelles adaptations sont encore nécessaires ? Quelles interfaces doivent être conservées ? Et quelles règles métier se cachent dans le code C/AL accumulé au fil des années ? **Les détenteurs du savoir ont quitté l'entreprise.** Nous récupérons ce savoir : - par l'analyse du code source - par des ateliers avec les services métier Une analyse précoce rend ces liens compréhensibles avant que vous ne fixiez le budget, le calendrier et la mise en œuvre. Vous pouvez ainsi évaluer les exigences de manière fondée avec vos services métier et votre partenaire d'intégration. Le savoir acquis vous aide dès aujourd'hui pour le diagnostic des erreurs, la documentation et l'évolution de votre système NAV existant. [Demander un diagnostic initial sans engagement](https://navtobc.de/fr/kontakt) Quelles échéances de support s'appliquent à votre système ? [Voir les versions NAV et leurs durées de support](https://navtobc.de/fr/nav-versionen) LES 3 RISQUES MAJEURS ## Pourquoi certains projets échouent. Une migration change bien plus que le logiciel. Elle touche des processus établis de longue date, des responsabilités et le savoir de vos collaborateurs. Ces trois risques doivent donc être mis sur la table très tôt. 1. ### L'obsession du 1:1 Vouloir reproduire à l'identique dans Business Central un environnement Navision historique et fortement modifié, c'est aussi en reprendre l'ancienne complexité. Le calendrier et le budget peuvent alors exploser. #### Ce qui aide Séparer les exigences métier du code existant. Examiner d'abord le standard Business Central et les modules adaptés, puis planifier les développements spécifiques nécessaires. 2. ### Analyse préalable insuffisante Sans analyse du code et des processus, on traîne des fonctions spéciales coûteuses qui ne sont plus utilisées ou que le standard moderne couvre depuis longtemps. Dans le même temps, des dépendances importantes peuvent passer inaperçues. #### Ce qui aide Confronter le code, les interfaces et l'utilisation réelle avec les services métier. Décider de façon motivée pour chaque adaptation : reprendre, remplacer ou mettre hors service. 3. ### Conduite du changement insuffisante Si les services métier ne sont impliqués que peu avant la mise en production, les anciennes façons de travailler persistent souvent. Les nouveaux processus sont alors en place techniquement, mais pas encore ancrés dans le quotidien. #### Ce qui aide Impliquer tôt les services métier, désigner des responsables et prévoir du temps pour les formations. Tester ensemble les nouveaux processus sur des cas métier réalistes. ### Toutes les adaptations ne doivent pas suivre. Mais chaque règle critique pour l'activité doit être comprise. L'IA rend le savoir système accumulé plus accessible. Les services métier expliquent pourquoi une règle est nécessaire. Ensemble, vous construisez une base solide pour vos décisions. [Clarifier tôt les risques de migration](https://navtobc.de/fr/kontakt?thema=nav-analyse) DE L'OBJET INDIVIDUEL AU SYSTÈME COMPLET ## Analyse détaillée de Navision avec l'IA. **Comprendre votre système. Identifier les liens. Rendre le savoir durablement exploitable.** Nous analysons votre **système Navision, Dynamics NAV ou MS Dynamics NAV** jusqu'au niveau des objets. L'analyse automatisée du code C/AL, l'analyse du schéma et l'intelligence artificielle (**IA**) relient code source, données et interfaces en une base de connaissances traçable. **Analyse C/AL automatique avec notre propre outil d'analyse. Nous exploitons les exports d'objets au format TXT.** Les fichiers FOB natifs ne sont pas traités directement. Les résultats constituent la base de vos décisions de migration. Le code spécifique nécessaire est réécrit en AL, et non converti automatiquement. ![Analyse détaillée de Navision avec l'IA.](https://navtobc.de/film/analyseumfang-v1/fr/poster.webp) [Analyse détaillée de Navision avec l'IA.](https://navtobc.de/film/analyseumfang-v1/fr/index.m3u8) NAVtoBC.de · VIDÉO EN ALLEMAND ### Analyse détaillée de Navision avec l'IA. Le périmètre d'analyse expliqué en vidéo. ### Tous les composants en vue L'analyse couvre les types d'objets de votre système NAV : - Codeunit - Dataport - Form - MenuSuite - Page - Report - Table - XMLPort **Données SQL – pseudonymisées sur demande.** Les données existantes sont elles aussi prises en compte. On peut ainsi examiner non seulement des fonctions isolées, mais aussi leurs dépendances et leurs flux de données. ### Documenter les résultats objet par objet Les résultats de l'analyse sont **consignés pour chaque objet, classés de façon structurée et rendus consultables**. Fonctions, règles métier et liens restent faciles à retrouver. Le code source accumulé au fil des années devient une base de connaissances pour l'analyse des erreurs et les décisions de migration. ### Intégrer les interfaces et les systèmes tiers Votre NAV ne s'arrête pas à sa propre base de données. C'est pourquoi nous intégrons les **interfaces externes et les outils de fournisseurs tiers** – par exemple les **systèmes EDI et les connexions aux boutiques en ligne**. D'autres bases de données SQL liées à Navision peuvent également être lues et examinées dans le périmètre d'analyse convenu. Les flux de données deviennent ainsi traçables au-delà des frontières entre systèmes. [Importations, exportations et flux de données en détail](https://navtobc.de/fr/schnittstellen) ### Retracer chaque étape d'analyse Toutes les étapes d'analyse sont **consignées en détail, transcriptions comprises**. Les résultats sont rattachés aux objets examinés et aux étapes d'analyse documentées. Il reste ainsi possible de retracer **ce qui a été examiné, quels liens ont été identifiés et sur quoi repose une conclusion**. CAP SUR L'AVENIR ### Votre cible : Business Central D'un système NAV construit au fil des années à une base clairement documentée pour votre migration. [![Exemple de page d'accueil Business Central avec navigation, tâches et indicateurs clés.](https://navtobc.de/business-central-beispiel.png) Ouvrir la vue d'exemple](https://navtobc.de/business-central-beispiel.png) **Vue d'exemple de Microsoft Dynamics 365 Business Central.** L'illustration montre l'interface cible ; elle ne présente aucun résultat de notre analyse NAV. 1. **Comprendre Navision** Objets, données et interfaces 2. **Préserver le savoir** Structuré et consultable 3. **Préparer Business Central** Le standard d'abord, des extensions ciblées COMPRENDRE LES FLUX DE DONNÉES. PRÉPARER LES INTERFACES DE FAÇON CIBLÉE. ### Interfaces et systèmes connectés. **Analyser de façon structurée les échanges de données dans Navision. Les évaluer avec rigueur grâce à l'IA.** Solutions EDI, systèmes BI, boutiques en ligne et processus d'import et d'export spécifiques font souvent partie de l'environnement NAV construit au fil des années. **Nous analysons ces connexions et rendons traçables les flux de données, les correspondances de champs et les dépendances fonctionnelles.** Il en découle des propositions concrètes pour votre migration vers Business Central. #### Systèmes dans le périmètre d'analyse Flux de données EDI et analyses BI en lien avec votre système Navision. ![Lobster](https://navtobc.de/images/lobster-logo.svg) Flux de données EDI ![Qlik](https://navtobc.de/images/qlik-logo.svg) Analyses BI ![Analyse IA des interfaces Navision.](https://navtobc.de/film/schnittstellen-v1/fr/poster.webp) [Analyse IA des interfaces Navision.](https://navtobc.de/film/schnittstellen-v1/fr/index.m3u8) NAVtoBC.de · VIDÉO EN ALLEMAND #### Analyse IA des interfaces Navision. Flux de données et systèmes connectés en vidéo. #### Échange de données Navision Recenser les sources de données, les destinations, les formats et les points de transfert. L'analyse montre quelles informations circulent entre Navision et les systèmes connectés. #### Import de données Navision Examiner les processus d'import des articles, prix, clients, stocks et données de mouvements : origine, structure, renseignement des champs et logique de validation existante. #### Transfert de données Navision Retracer les canaux de transfert techniques, les déclencheurs et les ordres de traitement. Les sources d'erreur et les dépendances sont documentées pour servir de base aux améliorations. #### Export de données Navision Analyser la logique d'export, les contenus, les formats cibles et les destinataires. La signification métier des données reste visible pour les systèmes connectés, les rapports et les traitements en aval. #### Export de données vers les boutiques en ligne Vérifier la transmission des données d'articles, de prix, de stocks et de commandes. Les règles et dépendances existantes sont préparées pour la future cible Business Central. #### Import de données articles Intégrer les données fournisseurs, les catalogues et les systèmes amont. Champs obligatoires, variantes, unités, prix et règles de contrôle spécifiques sont examinés systématiquement. #### Analyse des champs pour le rapprochement à l'import **Comprendre les champs clés, la logique de correspondance et la détection des doublons.** Nous vérifions comment les enregistrements sont identifiés et rapprochés, et quelles règles métier sont nécessaires pour Business Central. #### Intégrer les systèmes connectés **Systèmes EDI :** par exemple Lobster EDI, Anvaigo EDI Connect (anciennement Anveo), SEEBURGER BIS, ecosio et Softzoll. **Analyse et reporting :** par exemple Qlik, Microsoft Power BI et Jet Reports. Dans le périmètre d'analyse convenu, nous examinons les connexions et les bases de données SQL associées liées à Navision. DÉMO SCHÉMATIQUE #### Échanges de données autour de Navision Exemples de connexions, de flux de données et de points d'entrée pour l'analyse. EDI **Lobster EDI** Documents, données de base et informations de statut BI **Qlik** Reporting, analyse et mise à disposition des données **Navision / Dynamics NAV** C/AL · SQL · logique métier IMPORT **Données articles** Données de base, variantes, unités et prix BOUTIQUE **Boutiques en ligne** Articles, prix, stocks et commandes CE SUR QUOI PORTE L'ANALYSE **Export de données** Contenus, formats cibles et destinataires **Rapprochement à l'import** Correspondance des champs, clés et détection des doublons **Représentation illustrative, pas un projet client.** Les flèches indiquent des sens de flux donnés à titre d'exemple, et non des flux de données mesurés en direct. Les interfaces et correspondances de champs réelles sont vérifiées pour chaque projet. Les noms de produits servent à situer le propos ; aucun partenariat avec les fournisseurs cités n'est revendiqué. **Flux de données de la démo sous forme de texte** - Lobster EDI ↔ Navision : échange de documents, de données de base et d'informations de statut. - Navision → Qlik : mise à disposition de données pour le reporting et l'analyse. - Sources d'articles externes → Navision : import avec correspondance des champs et validation. - Navision ↔ boutiques en ligne : export des articles, prix et stocks ; retour des commandes. - L'export de données et le rapprochement à l'import sont des domaines d'analyse, et non des systèmes tiers supplémentaires. NAVISION ET POWER BI #### Vos rapports Power BI. Prêts pour Business Central. De nombreux systèmes Navision alimentent Microsoft Power BI en indicateurs. La façon dont les données y parviennent dépend de la version de NAV. Et c'est de cela que dépend le sort de vos rapports lors de la migration. - **Services web OData, à partir de NAV 2013 :** NAV publie des pages et des requêtes sous forme de service web, que Power BI lit comme flux OData. NAV évalue lui-même les FlowFields et les autorisations. - **Accès SQL direct, y compris sous NAV 2009 R2 :** Power BI lit les tables de chaque société directement dans la base de données. Les FlowFields n'y figurent pas en tant que colonnes, et les autorisations NAV ne s'appliquent pas. - **Power BI dans le tableau de bord, à partir de NAV 2017 :** les rapports s'affichent directement dans le client NAV. Dans Business Central online, la voie prise en charge vers Power BI passe par les pages et requêtes API ; il n'y existe pas d'accès direct à la base de données. Pour la finance et les ventes, Microsoft fournit des applications modèles prêtes à l'emploi. Les rapports qui reposent sur des tables NAV ou des pages NAV publiées doivent donc être reconnectés. **L'analyse NAVtoBC recense les tables, champs et services web qu'utilisent aujourd'hui vos rapports Power BI,** et montre ce qui doit être reconnecté dans Business Central. Vous planifiez ainsi la refonte de vos rapports avant le démarrage de la migration. Sources : [Microsoft : Power BI avec Dynamics NAV](https://learn.microsoft.com/fr-fr/dynamics-nav-app/across-how-use-financials-data-source-powerbi) · [Microsoft : extraire des données de Business Central](https://learn.microsoft.com/fr-fr/dynamics365/business-central/dev-itpro/developer/devenv-extract-data) VOTRE RÉSULTAT #### Pas de boîte noire dans les flux de données. Vous obtenez une cartographie documentée des interfaces, des correspondances de champs traçables et des **propositions assistées par IA** pour la suite de la mise en œuvre : conserver, simplifier ou remplacer de façon ciblée les connexions nécessaires. **Business Central online évalué à part :** selon Microsoft, l'accès direct aux fichiers sur le serveur n'y est pas possible. Les interfaces basées sur des fichiers, par exemple des fichiers CSV dans des dossiers d'échange, nécessitent donc une nouvelle voie via des services web, des API ou un téléversement de fichier dans le navigateur. **Le standard Business Central d'abord, des modules ISV adaptés ensuite.** Les exigences spécifiques nécessaires sont réimplémentées en AL. Les propositions et les points ouverts sont validés avec vos services métier, votre équipe informatique interne et le partenaire de votre choix. [Demander une analyse des interfaces](https://navtobc.de/fr/kontakt?thema=schnittstellen) RENDRE LE TRAITEMENT VISIBLE ### Vos flux de données. Votre logique métier. Traçables sous forme de graphe. **La base de données orientée graphe visualise les liens au sein de votre NAV.** Elle montre comment les données sont traitées, quelles fonctions s'imbriquent et quelle logique métier est appliquée. Objets liés, chaînes d'appels et flux de données rendent traçable le traitement à travers votre système Navision – y compris les interfaces examinées et les systèmes connectés. Le tout repose sur les sources analysées et les résultats documentés. ### Cinq analyses issues du graphe. Chaque chemin étayé. Chaque objet de votre NAV devient un nœud : Tables, Forms, Reports, Codeunits, Dataports et MenuSuites. Chaque appel, chaque référence de table et chaque entrée de menu devient une arête. Le réseau peut ainsi être interrogé, et pas seulement observé. **Accessibilité démontrée** À partir d'ancres validées avec les services métier – entrées de MenuSuite, rapports, files d'attente des travaux –, le graphe détermine pour chaque objet s'il est accessible et par quel chemin. Résultat par objet : accessible oui/non, distance à l'ancre et chaîne par laquelle il est atteint. **Dépendances par table** Quels objets lisent ou écrivent dans une table ? Un coup d'œil sur « Sales Header » montre tous les Forms, Reports et Codeunits qui en dépendent – la base pour évaluer l'impact d'une modification ou d'un passage à BC. **Dépendances externes : .NET, COM, DLL** Pour chaque objet, le graphe recense les endroits où C/AL sort du périmètre de NAV : variables et appels DotNet (analyse DotNet), CREATEAUTOMATION, objets COM, serveurs Automation et dépendances DLL. L'interopérabilité .NET n'est disponible dans Business Central qu'en On-Premises, pas online. Les appels COM et Automation ne peuvent pas être repris tels quels en AL. Chaque référence figure donc dans le résultat comme constat distinct, avec l'objet concerné – la base pour planifier leur remplacement en AL. **Objets dont l'accessibilité n'est pas démontrée** Les objets sans chemin depuis une ancre sont regroupés et signalés comme à vérifier – et non comme une liste de suppression. Seule la vérification métier décide d'une mise hors service. **Lacunes dans l'export** Les objets référencés absents de l'export, les objets non compilés et les appels non résolus sont consignés comme constats distincts. Ce que l'analyse ne couvre pas reste ainsi visible. La base, ce sont des exports d'objets nettoyés, sans connexion à la base de données. Le graphe montre les relations statiques présentes dans l'export. Les appels dynamiques, les objets manquants et les limites du parseur sont signalés comme tels, et non présentés comme analysés avec certitude. Fiche d'objet issue du graphe DONNÉES SYNTHÉTIQUES **Créer un retour** *:Form* *:Objet* **Identifiant** FRM-50710 **Accessible** oui · distance à l'ancre 1 **Atteint via** MenuSuite → Saisie des retours → FRM-50710 **Utilise** Table 36 « Sales Header » (lecture, écriture) **Externe** aucune dépendance .NET, COM ou DLL **État** Export du 02/03/2018 · compilé · présent dans l'export PREUVE PAR OBJET **accessible, distance 1 depuis la MenuSuite – chemin avec source pour chaque arête** Représentation d'exemple avec des noms d'objets fictifs et figés. Pas d'analyse en direct ni de connexion à une base de données orientée graphe. UN SAVOIR UTILE AU QUOTIDIEN ### Votre gain immédiat : un diagnostic des erreurs plus rapide – avant même la migration. L'analyse ne pose pas seulement les bases de votre migration vers Business Central. **Elle apporte un avantage immédiat dès votre système NAV actuel :** les erreurs peuvent être circonscrites plus rapidement et de façon plus ciblée grâce au savoir système documenté. Les résultats d'objets consultables, les règles métier documentées et les flux de données visualisés montrent comment fonctions et processus s'articulent. Au lieu de réexaminer ces liens à chaque incident, vous vous appuyez sur la base de connaissances déjà constituée. **Des heures de recherche peuvent ainsi se réduire à un diagnostic ciblé en quelques minutes – un gain supplémentaire pour votre exploitation courante, avant même votre passage à Business Central.** *La durée réelle dépend de la nature de l'erreur et du périmètre d'analyse documenté.* [Discuter du périmètre d'analyse](https://navtobc.de/fr/kontakt) LES PARTICULARITÉS DE C/AL ## Peu de code. Beaucoup d'impact. Dans Navision, la logique métier ne se trouve pas seulement dans les fonctions. Les propriétés des champs, les déclencheurs, les filtres et le contexte d'exécution déterminent eux aussi ce qui se passe réellement. Qui analyse C/AL de façon automatisée doit lire ces éléments ensemble. Voici les principales particularités pour une analyse et une planification de migration solides. BIEN SITUER C/AL ### De Navision à Business Central 14. **C/AL signifie Client/server Application Language.** Ce langage était utilisé dans Navision et Dynamics NAV et restait disponible jusqu'à Business Central 14 (Spring 2019, On-Premises). À partir de Business Central 15, C/AL a été remplacé par AL. NOTRE BASE D'ANALYSE ### Exports d'objets TXT. Nous lisons les **objets NAV exportés au format TXT**, avec leur code C/AL et leurs propriétés. **Les fichiers FOB natifs ne sont pas traités directement.** Si seuls des fichiers FOB sont disponibles, les objets sont d'abord importés dans un environnement de développement NAV adapté, puis exportés au format TXT. Il faut pour cela une version adéquate et la licence développeur requise. Renommer l'extension du fichier ne suffit pas. UNE PETITE DIFFÉRENCE AUX GRANDES CONSÉQUENCES ### Affecter ou valider ? Les deux lignes définissent une valeur dans le tampon d'enregistrement. `VALIDATE` exécute en plus la validation du champ, y compris `OnValidate`. Ce déclencheur peut modifier d'autres champs, déclencher de la logique métier et effectuer lui-même des modifications en base de données. Affectation directe ``` Customer.Name := 'Beispiel'; ``` Avec validation du champ ``` Customer.VALIDATE(Name, 'Beispiel'); ``` ### Ce qui va ensemble dans l'analyse. Dépliez les thèmes pour découvrir les détails techniques. ****Langage & valeurs** Syntaxe Pascal, Code, options et types de données métier** - **Syntaxe inspirée de Pascal :** `BEGIN … END`, `:=` pour les affectations, ainsi que `//` et `{ … }` pour les commentaires. Les identificateurs et mots-clés ne sont pas sensibles à la casse. Les variables sont déclarées globalement dans l'objet ou localement dans les fonctions et déclencheurs. Les paramètres `VAR` peuvent modifier la valeur chez l'appelant. - **Code est un type de données à part entière :** il convertit le texte en majuscules et supprime les espaces de début et de fin. La longueur définie de `Code` et `Text` fait partie de l'évaluation. Les chaînes de caractères et les tableaux sont adressés à partir de la position 1. - **Les options ont un ordre :** `OptionString` définit les membres ; leurs valeurs numériques commencent à 0. Il faut distinguer le nom, la position et la légende traduite. Une conversion vers les enums AL doit tenir compte des valeurs existantes. AL prend toujours en charge `Option` ; le passage aux enums n'est pas automatiquement obligatoire. - **Des valeurs métier plutôt que de simples nombres :** `0D`, les dates de clôture, `WORKDATE` et les formules de date ont une signification propre. Les règles d'arrondi ainsi que les conversions dépendantes de la langue avec `FORMAT` et `EVALUATE` peuvent influer sur les résultats et les interfaces. **Pour l'analyse :** des valeurs visuellement identiques peuvent être traitées différemment sur le plan technique. Le type de données, la longueur, la langue et le passage des paramètres font donc partie du constat. ****Objets & métadonnées** Type et ID, numéros de champs et propriétés** - **Des objets plutôt que des fichiers sources isolés :** selon la version de NAV, on y trouve Table, Page, Report, Codeunit, Query, XMLport et MenuSuite ; les générations plus anciennes connaissent aussi Form et Dataport. C'est la combinaison **type d'objet et ID** qui est unique. La plage 50000–99999 est traditionnellement réservée aux adaptations client ; les plages partenaires et leur utilisation dépendent aussi de la licence. - **Les propriétés portent de la logique métier :** `TableRelation`, `CalcFormula`, `SourceTableView`, `RunObject` et `RunPageLink` créent des relations, des filtres et des appels en dehors du code C/AL proprement dit. Les numéros de champs, les clés, les DataItems des Reports et les structures des XMLports font également partie du modèle. - **Les identificateurs ne sont pas des libellés :** `CaptionML` et `OptionCaptionML` fournissent des affichages multilingues, par exemple en allemand et en anglais. Ils ne remplacent ni l'identité des objets ni celle des champs. La langue et l'encodage des caractères de l'export TXT doivent être préservés. **Pour l'analyse :** un export d'objets complet contient plus de savoir que des fonctions copiées isolément. Les métadonnées font partie du programme. ****Déclencheurs & logique métier** VALIDATE, RunTrigger et actions consécutives cachées** - **Déclencheurs et fonctions :** C/AL offre des fonctions globales et locales. S'y ajoutent des déclencheurs de table comme `OnInsert`, `OnModify`, `OnDelete` et `OnRename`, des déclencheurs de champ comme `OnValidate` et `OnLookup`, ainsi que des déclencheurs de Page et de Report. L'ordre et le contexte d'appel sont déterminants. - **Un paramètre change le déroulement :** pour `INSERT`, `MODIFY` et `DELETE`, `RunTrigger` détermine si le déclencheur de table associé est exécuté. Sans indication, il vaut `FALSE`. `MODIFY(TRUE)` exécute `OnModify`, mais ne valide pas automatiquement chaque champ. Les opérations de masse doivent être examinées séparément. - **Contrôler, transférer et valider sont trois choses distinctes :** `TESTFIELD` contrôle la valeur d'un champ. `TRANSFERFIELDS` affecte les valeurs d'après les numéros de champ et n'exécute aucun trigger `OnValidate`. Une affectation directe à un champ contourne elle aussi cette validation. - **Contexte implicite :** `Rec`, `xRec` et `WITH` déterminent à quoi une expression fait référence. Les variables locales et globales ont des portées différentes. Les variables globales peuvent conserver un état au sein d'une instance d'objet ; les codeunits `SingleInstance` partagent leur instance au sein d'une session. **Pour l'analyse :** le nom d'une fonction ne suffit pas à expliquer le déroulement. Il faut aussi retracer les paramètres d'activation des triggers, le contexte des variables et les actions déclenchées en aval. ****État des Records & calculs** Filtres, FlowFields, données temporaires et sociétés** - **Un Record mémorise plus que des valeurs de champ :** filtres, groupes de filtres, clés et enregistrement courant influencent les accès. `SETRANGE`, `SETFILTER`, `FILTERGROUP`, `RESET`, `FINDSET`, `FINDFIRST` et `NEXT` doivent être lus dans leur contexte. `GET` utilise la clé primaire et ignore les filtres ordinaires ; les filtres de sécurité doivent être pris en compte séparément. - **FlowField n'est pas FlowFilter :** un FlowField ne stocke pas durablement son résultat calculé dans la table. `CalcFormula` décrit le calcul, par exemple une somme ou une recherche (lookup). `CALCFIELDS` calcule la valeur ; selon l'intégration du champ, l'interface utilisateur s'en charge également. Un FlowFilter fournit des conditions de filtre pour ces calculs et ne calcule lui-même aucune valeur de résultat. - **Même table, autre contexte :** les variables Record temporaires traitent les données en mémoire. `CHANGECOMPANY` change la société sur laquelle portent les accès aux données ; les triggers continuent de s'exécuter dans le contexte de la société courante. `DataPerCompany` distingue les tables propres à chaque société des tables communes. **Pour l'analyse :** le nom de la table et la valeur du champ ne suffisent pas. Filtres, définition du calcul, état temporaire et société déterminent ce que la donnée exprime. ****Dépendances dynamiques & événements** RecordRef, FieldRef, appels et subscribers** - **Réutilisation sans modèle de classes :** C/AL ne propose ni espaces de noms ni définitions d'interface natives. Un véritable modèle de classes avec héritage ne fait pas non plus partie du langage. Les codeunits mettent à disposition des fonctions globales ; `CODEUNIT.RUN` lance leur trigger `OnRun`. Les références peuvent être résolues par nom, par sous-type d'objet déclaré ou par numéro. - **Les cibles peuvent n'être connues qu'à l'exécution :** `RecordRef`, `FieldRef`, `Variant` et des ID d'objet transmis dynamiquement permettent un traitement générique. Des tables de configuration peuvent aussi déterminer quel code est réellement appelé. - **Les événements font déjà partie de C/AL :** depuis NAV 2016, publishers et subscribers peuvent créer des relations d'appel supplémentaires. L'analyse doit tenir compte de ces liaisons ; une recherche des appels de fonction directs ne les recense pas entièrement. **Pour l'analyse :** les dépendances attestées statiquement et les relations qui ne peuvent être résolues qu'à l'aide de la configuration ou d'informations d'exécution sont présentées séparément. ****Transactions & SQL** COMMIT, gestion des erreurs, clés et verrous** - **Les transactions sont en partie implicites :** C/AL ouvre et clôt automatiquement les transactions de base de données. `COMMIT` fixe une limite explicite. Une erreur ultérieure n'annule pas les modifications déjà validées. - **La gestion des erreurs fait partie de la logique :** les valeurs de retour des fonctions de base de données, la valeur de retour booléenne évaluée de `CODEUNIT.RUN` et `TryFunction` modifient le déroulement des erreurs et des transactions. Les modifications de base de données effectuées dans une TryFunction ne sont pas automatiquement annulées lorsqu'une erreur est interceptée ; les écritures autorisées dépendent de la version et de la configuration du serveur. - **C/AL agit sur SQL sans montrer de SQL :** `SETCURRENTKEY`, les filtres, `LOCKTABLE`, `FINDSET`, les clés et les agrégats SIFT influent sur les accès et le comportement de verrouillage. Une clé définie ne garantit pas un plan d'exécution SQL précis. Les schémas atypiques fournissent des pistes ; leurs performances réelles sont mesurées. **Pour l'analyse :** la cohérence des données et les performances ne peuvent être évaluées qu'en tenant compte des limites de transaction, des chemins d'erreur et de l'exploitation concrète de la base de données. ****Historique & comparaison au standard** Format TXT, Version List, versions pays et personnalisations** - **Un format d'export propre et documenté :** C/SIDE gère les objets dans la base de données et les exporte au format FOB ou TXT. Le TXT contient le code source et des métadonnées telles que Version List, date, heure et indicateur Modified. Ces exports peuvent être gérés avec Git ; les métadonnées techniques peuvent toutefois ajouter des différences supplémentaires aux comparaisons. Microsoft fournit lui-même des outils de comparaison et de conversion. - **Des personnalisations peuvent se cacher dans le standard :** dans les projets NAV classiques, le code Microsoft était souvent modifié directement. La `Version List` est un indice, pas une preuve exhaustive des modifications. Le classement devient fiable grâce à une comparaison avec la version d'origine non modifiée correspondante et à la documentation de projet existante. - **La bonne base est déterminante :** version NAV, build ou mise à jour cumulative, version pays et solutions partenaires doivent concorder. Les localisations allemande, autrichienne ou suisse peuvent contenir d'autres objets standard et d'autres règles métier. **Pour l'analyse :** seule la bonne version de référence montre quelle logique relève du standard, de la localisation, d'un add-on ou d'une personnalisation spécifique. ****Exécution, droits & interfaces** Générations de clients, autorisations et points d'entrée externes** - **La génération de NAV change l'environnement :** le Classic Client, le RoleTailored Client à partir de NAV 2009, les Forms et Pages ainsi que les Dataports et XMLports relèvent de stades de développement différents. L'interopérabilité .NET a été introduite dès **NAV 2009 R2**. Automation/COM, les composants .NET et l'exécution côté client ou côté serveur doivent être examinés version par version. - **Les droits ne sont que partiellement visibles dans l'export :** la propriété d'objet `Permissions` fait partie des sources. Les ensembles d'autorisations (permission sets) attribués, les droits des utilisateurs, les filtres de sécurité et le périmètre de licence doivent être recensés en plus. Les autorisations indirectes peuvent déterminer par quel traitement les données peuvent être modifiées. - **L'utilisation ne passe pas seulement par le code :** files d'attente des travaux, services web publiés, chemins de fichiers, composants externes et systèmes SQL, EDI ou e-commerce connectés peuvent démarrer ou piloter des traitements. `GUIALLOWED` et les fonctions dépendantes du client sont déterminants pour les traitements en arrière-plan. L'absence d'appels statiques ne prouve donc pas l'absence d'utilisation. **Pour l'analyse :** l'export TXT est complété par la configuration que vous mettez à disposition, la connaissance des interfaces et des preuves d'utilisation appropriées. Les dépendances non résolues sont clarifiées de manière ciblée avec l'équipe informatique et les services métier. CE QUE VOUS Y GAGNEZ ### Comprendre les règles métier. Planifier la migration sur des bases solides. Une analyse fiable relie le code C/AL, les métadonnées des objets et l'exploitation réelle. Règles, dépendances et questions ouvertes deviennent ainsi traçables – comme base pour le standard Business Central, des modules adaptés et un développement AL ciblé. [Demander une analyse C/AL](https://navtobc.de/fr/kontakt?thema=nav-analyse) **Sources de référence & contexte** Vérifié le 09/10/2026 à partir de la documentation Microsoft. Cette synthèse rassemble les particularités essentielles pour l'analyse ; le détail dépend de la version NAV, de l'état des objets et de l'environnement d'exploitation. - [C/AL jusqu'à Business Central 14 et exports d'objets TXT](https://learn.microsoft.com/fr-fr/dynamics365/business-central/dev-itpro/developer/devenv-txt2al-tool) - [FOB/TXT : exporter et importer des objets](https://learn.microsoft.com/fr-fr/dynamics365/business-central/dev-itpro/cside/cside-import-objects) - [Interopérabilité .NET dans NAV 2009 R2](https://www.microsoft.com/en-us/dynamics-365/blog/no-audience/2010/10/27/net-interoperability-in-nav-2009-r2/) - [Événements en C/AL depuis NAV 2016](https://www.microsoft.com/en-us/dynamics-365/blog/business-leader/2015/10/15/integration-events-in-microsoft-dynamics-nav-2016/) - [Fonctions, variables et VALIDATE en C/AL](https://www.microsoft.com/en-us/dynamics-365/blog/no-audience/2012/12/03/writing-unit-tests-in-cal/) - [FlowFields dans NAV 2018](https://learn.microsoft.com/fr-fr/previous-versions/dynamicsnav-2018-developer/FlowFields) - [Objets TXT, métadonnées et comparaison au standard](https://learn.microsoft.com/fr-fr/dynamics365/business-central/dev-itpro/upgrade/comparing-and-merging-application-object-source-files) - [TryFunctions et gestion des erreurs en C/AL](https://www.microsoft.com/en-us/dynamics-365/blog/business-leader/2015/10/28/nav-design-pattern-tryfunction-net-exception-handling-in-cal/) - [SingleInstance, date de travail et effets de bord](https://www.microsoft.com/en-us/dynamics-365/blog/it-professional/2015/10/19/test-isolation-in-the-application-test-automation-suite/) - [Comparaison des langages : les options existent aussi en AL](https://learn.microsoft.com/fr-fr/dynamics365/business-central/dev-itpro/developer/methods-auto/option/option-data-type) - [CHANGECOMPANY et contexte des triggers (référence AL)](https://learn.microsoft.com/fr-fr/dynamics365/business-central/dev-itpro/developer/methods-auto/record/record-changecompany-method) - [Permissions et droits indirects (référence AL)](https://learn.microsoft.com/fr-fr/dynamics365/business-central/dev-itpro/developer/properties/devenv-permissions-property) [Comment nous combinons analyse de code et IA](https://navtobc.de/fr/methoden) VERSION DE DÉPART & ARCHITECTURE CIBLE ## Votre version NAV. Le chemin vers Business Central. De Microsoft Navision 4.0 à Microsoft Dynamics NAV 2018 : nous clarifions la version installée, les sources disponibles et les personnalisations. Nous en tirons votre plan d'analyse et de migration sur mesure. ![De Navision à Business Central.](https://navtobc.de/film/business-central-v1/fr/poster.webp) [De Navision à Business Central.](https://navtobc.de/film/business-central-v1/fr/index.m3u8) NAVtoBC.de · VIDÉO EN ALLEMAND ### De Navision à Business Central. Échéances du support, mise à niveau ou réimplémentation, et ce qui doit être réévalué avant la transition : la vidéo explicative en six minutes. APERÇU DU SUPPORT MICROSOFT Statut au 05/11/2026. Rouge : expiré · Vert : support étendu. **Dates de fin de support par famille de produits.** Pour les versions initiales et service packs plus anciens, des dates antérieures s'appliquent parfois. Vous les trouverez directement dans la ligne correspondante, sous « Fin du support par version ». Navision et Dynamics NAV avant Business Central – à partir de la version 4.0 | Génération de produit | Versions et releases | Support standard jusqu'au | Support étendu jusqu'au | Statut actuel | Source | | --- | --- | --- | --- | --- | --- | | Microsoft Navision / Dynamics NAV 4.0 | 4.0 · 4.0 SP1 · 4.0 SP2 · 4.0 SP3 **Fin du support par version** 4.0 (version initiale) 12/01/2010; 4.0 SP1 10/07/2007; 4.0 SP2 08/01/2008; 4.0 SP3 12/01/2010 | 12.01.2010 | Non indiqué\* | × Expiré | [Microsoft](https://learn.microsoft.com/fr-fr/lifecycle/products/dynamics-nav-40) | | Microsoft Dynamics NAV 5.0 | 5.0 · 5.0 SP1 **Fin du support par version** 5.0 (version initiale) 13/04/2010; 5.0 SP1 11/04/2017 | 10.04.2012 | 11.04.2017 | × Expiré | [Microsoft](https://learn.microsoft.com/fr-fr/lifecycle/products/dynamics-nav-50) | | Microsoft Dynamics NAV 2009 | NAV 2009 · NAV 2009 SP1 · NAV 2009 R2 **Fin du support par version** NAV 2009 (version initiale) 11/10/2011; NAV 2009 SP1 14/01/2020; NAV 2009 R2 14/01/2020 | 13.01.2015 | 14.01.2020 | × Expiré | [Microsoft](https://learn.microsoft.com/fr-fr/lifecycle/products/dynamics-nav-2009) | | Microsoft Dynamics NAV 2013 | NAV 2013 | 09.01.2018 | 10.01.2023 | × Expiré | [Microsoft](https://learn.microsoft.com/fr-fr/lifecycle/products/dynamics-nav-2013) | | Microsoft Dynamics NAV 2013 R2 | NAV 2013 R2 | 09.01.2018 | 10.01.2023 | × Expiré | [Microsoft](https://learn.microsoft.com/fr-fr/lifecycle/products/dynamics-nav-2013-r2) | | Microsoft Dynamics NAV 2015 | NAV 2015 | 14.01.2020 | 14.01.2025 | × Expiré | [Microsoft](https://learn.microsoft.com/fr-fr/lifecycle/products/dynamics-nav-2015) | | Microsoft Dynamics NAV 2016 | NAV 2016 | 13.04.2021 | 14.04.2026 | × Expiré | [Microsoft](https://learn.microsoft.com/fr-fr/lifecycle/products/dynamics-nav-2016) | | Microsoft Dynamics NAV 2017 | NAV 2017 | 11.01.2022 | 11.01.2027 | ✓ Support étendu | [Microsoft](https://learn.microsoft.com/fr-fr/lifecycle/products/dynamics-nav-2017) | | Microsoft Dynamics NAV 2018 | NAV 2018 | 10.01.2023 | 11.01.2028 | ✓ Support étendu | [Microsoft](https://learn.microsoft.com/fr-fr/lifecycle/products/dynamics-nav-2018) | **Pas de date d'arrêt automatique :** la fin du support désigne la fin de la phase de support Microsoft concernée, et non la fin automatique de l'utilisation du logiciel. Pour bénéficier du support, le niveau de mise à jour ou de service pack pris en charge est requis. Les contrats individuels conclus avec des partenaires ne font pas partie de cette synthèse. **\* Version 4.0 :** Microsoft indique le 12/01/2010 comme fin du support standard, mais aucune date de fin distincte pour le support étendu. Sources consultées le 24/09/2026 . Jours calendaires selon Microsoft Lifecycle (heure du Pacifique), sans conversion à l'heure allemande. Sources complémentaires : [NAV 2009 R2](https://learn.microsoft.com/fr-fr/lifecycle/products/dynamics-nav-2009-r2) · [Politique Microsoft de support et de service packs](https://learn.microsoft.com/fr-fr/lifecycle/policies/fixed). Cette synthèse répertorie les versions principales ainsi que les service packs et versions R2 mentionnés. Versions pays, mises à jour cumulatives, modules sectoriels et personnalisations spécifiques sont recensés séparément lors du diagnostic initial. La mention d'une version ne constitue pas une promesse générale de migration directe automatisée. DE C/AL À AL ### Comprendre C/AL. Planifier le passage à AL de façon ciblée. Toutes les personnalisations n'ont pas vocation à devenir une extension AL. Nous examinons d'abord le standard Business Central, puis les modules ISV certifiés adaptés, et seulement ensuite le développement spécifique nécessaire. 01 / CODE SOURCE ### Analyse du code C/AL Le code source C/AL et les exports d'objets TXT issus de C/SIDE sont examinés sous l'angle des fonctions, des règles métier, des appels et des dépendances. L'analyse automatisée du code fournit les éléments probants sur lesquels s'appuie l'évaluation assistée par IA. **Résultat : une logique NAV documentée.** 02 / MODÈLE DE DONNÉES ### Analyse du schéma & SQL Tables, champs, clés et relations entre les données sont examinés conjointement avec les interfaces EDI, e-commerce et autres. Les données SQL complètent l'analyse du schéma dans le périmètre convenu – pseudonymisées sur demande. **Résultat : des flux de données traçables.** 03 / VISION CIBLE ### Standard, ISV ou extension AL ? Nous affectons chaque exigence nécessaire au standard Business Central, à un module ISV adapté ou à une extension AL spécifique justifiée. La mise en œuvre technique fait l'objet d'un accord séparé. **Résultat : une proposition de migration argumentée.** NAV 2009 R2 ET SP1 ### Mise à niveau ou réimplémentation ? Selon Microsoft, une mise à niveau technique depuis NAV 2009 R2 ou SP1 passe par NAV 2013 ou 2015, NAV 2018 et Business Central 14 avant d'atteindre la version actuelle. C'est pourquoi de nombreuses entreprises optent pour une réimplémentation de Business Central. On reprend alors généralement les données de base, le paramétrage, les écritures ouvertes et les soldes d'ouverture. L'historique des écritures est archivé sous une forme consultable pour respecter les durées de conservation. L'analyse des écarts (fit-gap) détermine quelles personnalisations restent nécessaires. Le code spécifique indispensable est réécrit en AL. **C'est là qu'intervient l'analyse NAVtoBC :** elle montre quelles logiques, données et interfaces recèle un système construit au fil des années, et de quoi elles dépendent. Source : [Microsoft : migrer Dynamics NAV vers Business Central](https://learn.microsoft.com/fr-fr/dynamics365/business-central/dev-itpro/administration/migrate-nav) **Votre version est difficile à identifier ?** Nous déterminons avec vous l'état réel des objets, de l'application et de la base de données. [Parler de votre version NAV](https://navtobc.de/fr/kontakt) Contexte technique : [Microsoft : programmer en AL](https://learn.microsoft.com/fr-fr/dynamics365/business-central/dev-itpro/developer/devenv-programming-in-al) RÉFÉRENCE ISSUE DU TERRAIN ## 480 000 lignes de C/AL. Près de 1 000 codeunits. **Un savoir au service de l'exploitation quotidienne.** Dans ce projet client, le code source Navision ainsi que la base de données SQL Navision et toutes les autres bases SQL connectées ont été intégrés à l'analyse. L'exploitation des données a été réalisée sous forme pseudonymisée. CODE C/AL **480 000 lignes** CODEUNITS **Près de 1 000** SYSTÈME **NAV 2009 R2** VOLUME DE DONNÉES **env. 1,5 To** HISTORIQUE DU SYSTÈME **20 ans** SECTEUR **Commerce de gros & B2C** PROJET DE RÉFÉRENCE ### Comprendre le système. Décider en connaissance de cause. Code source, logique métier, fonctions et flux de données ont été systématiquement recensés, structurés et confrontés au standard Business Central ainsi qu'à des modules ISV adaptés. LE SAVOIR ACQUIS EN PRATIQUE ### Trouver les erreurs. Documenter le savoir. Préparer les évolutions. 01 ### Faciliter le diagnostic des erreurs. Examiner les interdépendances avec l'IA et cerner les causes possibles d'une erreur. 02 ### Produire la documentation. Documenter de façon ciblée certains domaines, par exemple les flux de données EDI. 03 ### Préparer les évolutions. Élaborer des propositions concrètes pour Navision, par exemple pour la prise en charge de ZUGFeRD. TÉMOIGNAGE CLIENT ### Ce savoir nous aide aujourd'hui très concrètement. > « Dans notre système Navision, 480 000 lignes de code C/AL réparties dans près de 1 000 codeunits ont été analysées. Outre notre base de données SQL Navision, toutes les autres bases SQL connectées ont également été intégrées. L'exploitation des données a été réalisée sous forme pseudonymisée. > > Nous utilisons aujourd'hui très concrètement le savoir acquis : l'IA nous aide à rechercher les erreurs et à comprendre les interdépendances au sein du système. Nous pouvons faire générer en un clic la documentation de certains domaines – par exemple de nos flux de données EDI. > > Nous recevons en outre des propositions concrètes de modifications et d'extensions dans Navision, par exemple pour la prise en charge de ZUGFeRD. L'analyse nous aide ainsi dès l'exploitation courante, tout en posant des bases solides pour l'évolution future de notre système. » Témoignage client issu d'un projet d'analyse NAV RÉSULTAT **Une base de connaissances structurée, des interdépendances visualisées et une proposition de migration vers Business Central claire et étayée.** [Demander un projet d'analyse similaire](https://navtobc.de/fr/kontakt?thema=nav-analyse) LE STANDARD AVANT LE SPÉCIFIQUE ## Le standard Business Central d'abord. Moins de code spécifique. Toutes les personnalisations NAV accumulées au fil des années ne doivent pas forcément être reprises. Nous examinons chaque exigence nécessaire dans cet ordre – avec vos services métier. ![Le standard Business Central d'abord.](https://navtobc.de/film/standard-zuerst-v1/fr/poster.webp) [Le standard Business Central d'abord.](https://navtobc.de/film/standard-zuerst-v1/fr/index.m3u8) NAVtoBC.de · VIDÉO EN ALLEMAND ### Le standard Business Central d'abord. Code spécifique remplacé par un module ISV. 1. 01 D'ABORD ### Utiliser le standard. Les fonctionnalités et le paramétrage de Business Central sont prioritaires. Nous examinons comment aligner vos processus sur le standard sans renoncer aux exigences métier indispensables. **Le standard Business Central est privilégié.** 2. 02 ENSUITE ### Modules certifiés. Si le standard ne suffit pas, nous examinons les modules sectoriels et fonctionnels certifiés adaptés. Les développements spécifiques sont autant que possible remplacés par ces extensions. **Des modules adaptés plutôt que de nouveaux développements.** 3. 03 SEULEMENT SI NÉCESSAIRE ### Développer de façon ciblée. Le développement spécifique est réservé aux exigences indispensables à l'activité que ni le standard ni des modules adaptés ne couvrent. Les écarts restants sont documentés et justifiés. **Chaque développement spécifique est justifié.** **Comment nous sélectionnons les modules** Nous examinons l'adéquation fonctionnelle, les intégrations, les coûts de licence et de maintenance, le support de l'éditeur ainsi que la compatibilité avec la version cible, le pays et le mode d'exploitation. Les attestations de certification ou de validation sont vérifiées pour le module concerné et la version en question. Une validation Marketplace ne constitue pas une garantie générale pour votre processus métier. L'adéquation est évaluée séparément dans le cadre du projet. [Microsoft : validation technique des apps](https://learn.microsoft.com/fr-fr/dynamics365/business-central/dev-itpro/developer/devenv-checklist-submission) EXEMPLE CONCRET / INTÉGRATION AMAZON ### Code spécifique remplacé par un module ISV. **Comprendre la logique métier historique. Remplacer de façon ciblée les interfaces spécifiques.** Une intégration Amazon développée sur mesure dans Navision contenait sa propre logique C/AL pour traiter les informations de commande et d'expédition. Le code source tient notamment compte des lignes déjà expédiées, des affectations existantes à des commandes Navision et des différents centres de distribution (fulfillment centers). **Dans cet exemple, le développement spécifique existant a été remplacé par un module ISV d'intégration Amazon.** DE LA PERSONNALISATION AU MODULE AVANT **Intégration Amazon spécifique** Logique C/AL maison dans Navision REMPLACEMENT **Module ISV pour Amazon** Développement spécifique existant remplacé Préserver la logique métier – **ne pas reprendre le code spécifique les yeux fermés.** Pour planifier la migration, l'essentiel est de connaître les règles métier existantes et de vérifier leur couverture dans la nouvelle solution. Ce n'est pas l'ancien code qui doit être conservé tel quel, mais la fonction nécessaire sur le plan métier. **Notre analyse assistée par IA facilite la préparation de votre migration de Navision vers Business Central :** elle rend lisibles la logique métier, les dépendances et les interfaces. Vous pouvez ainsi décider en connaissance de cause ce que couvre le standard, où un module ISV adapté convient et quel développement AL spécifique reste réellement nécessaire. **Voir le code source C/AL et les règles métier identifiées** **Extrait de code source C/AL fourni par l'exploitant du site.** L'extrait est reproduit sans modification et s'arrête au milieu d'une section de traitement. Il ne constitue pas un programme complet et exécutable. C/AL · Extrait de l'ancienne intégration Amazon ``` CLEAR(l_HoldOpen); l_SalesLineAmazon.RESET; l_SalesLineAmazon.SETRANGE("Amazon Document Type",p_SalesHeaderAmazon."Amazon Document Type"); l_SalesLineAmazon.SETRANGE("Amazon-Order-Id",p_SalesHeaderAmazon."Amazon-Order-Id"); l_SalesLineAmazon.SETFILTER("Navision Order No.",'=%1',''); l_SalesLineAmazon.SETFILTER("Quantity-Shipped",'>%1',0); // AKT#032 IF NOT l_SalesLineAmazon.FIND('-') THEN BEGIN EXIT; END ELSE BEGIN // AKT#038 BEG l_FulfillmentCenterId := l_SalesLineAmazon."Fulfillment-Center-Id"; IF l_FulfillmentCenterId<>'' THEN BEGIN p_SalesHeaderAmazon."Fulfillment-Center-Id" := l_FulfillmentCenterId; p_SalesHeaderAmazon."Shipment-Date" := l_SalesLineAmazon."Shipment-Date" END; REPEAT IF l_FulfillmentCenterId <> l_SalesLineAmazon."Fulfillment-Center-Id" THEN l_HoldOpen := TRUE; UNTIL l_SalesLineAmazon.NEXT=0; // AKT#038 END END; // Funktion für Navision Auftragserstellung CLEAR(WarningMessageOrder); CLEAR(ShippingCost); IF (p_SalesHeaderAmazon."Order No." = '') AND (p_SalesHeaderAmazon."Amazon-Order-Id" <>'') THEN BEGIN //(p_SalesHeaderAmazon."Error Message"='') THEN BEGIN //Fehlerprüfung?? ``` #### Ce que l'on peut déduire de cet extrait **01 / Cibler la commande correspondante** Les lignes sont filtrées par type de document Amazon et par numéro de commande Amazon. **02 / Sélectionner les lignes d'expédition non encore affectées** Le numéro de commande Navision doit être vide et la quantité expédiée supérieure à zéro. Si aucune ligne correspondante n'est trouvée, cet appel de fonction se termine par `EXIT`. **03 / Reprendre les informations d'expédition** Si l'ID de centre de distribution de la première ligne trouvée est renseigné, cet ID et la date d'expédition sont repris dans la variable d'en-tête de document. L'extrait ne montre pas d'enregistrement de cette modification. **04 / Détecter des centres de distribution différents** Si l'une des lignes trouvées présente un ID de centre différent de celui déterminé en premier, `l_HoldOpen` est mis à `TRUE`. **05 / Préparer la suite du traitement de la commande** La section suivante suppose un numéro de commande vide et un numéro de commande Amazon renseigné dans l'en-tête. La vérification du message d'erreur placée en dessous est mise en commentaire et donc inactive. **Limites de l'extrait :** la création effective de la commande, l'effet ultérieur de `l_HoldOpen` et le processus complet de commande et d'expédition n'y figurent pas. Le remplacement effectué est une indication de terrain de l'exploitant du site ; le code seul ne prouve ni la couverture fonctionnelle du module ni une mise en production Business Central achevée. Lesquelles de vos personnalisations NAV peuvent être utilement remplacées ? [Évaluer le potentiel de vos personnalisations NAV](https://navtobc.de/fr/kontakt?thema=standard-module) **Votre résultat :** une matrice de décision par personnalisation – remplacer par le standard, examiner un module certifié ou développer en spécifique de façon justifiée. Les exigences encore non clarifiées restent visibles. ENSEMBLE VERS BUSINESS CENTRAL ## Votre intégrateur reste votre partenaire. Nous y ajoutons l'analyse. **Collaborer plutôt que changer de partenaire – pour une migration vers Business Central efficace et allégée.** Nous épaulons votre intégrateur Navision actuel et votre équipe informatique interne avec des données d'analyse structurées, des règles métier documentées et une base de décision solide. **Il ne s'agit pas de remplacer votre partenaire actuel, mais de compléter de façon ciblée son savoir-faire et les connaissances de vos propres collaborateurs.** Indépendants de tout intégrateur, nous travaillons avec les partenaires de votre choix. La migration technique peut toujours être réalisée par votre partenaire actuel, par votre service de développement interne ou conjointement. 01 / INTÉGRATEUR ### Pour votre intégrateur Navision **Plus de transparence pour la planification et la mise en œuvre.** Votre partenaire connaît votre entreprise et accompagne votre solution. Nous complétons ce savoir par une analyse systématique du code C/AL, des objets, des flux de données et des interfaces. Les résultats structurés aident à évaluer les personnalisations, à identifier les dépendances et à préparer de façon ciblée la migration vers Business Central : **utiliser les fonctionnalités standard, recourir à des modules ISV adaptés et ne réécrire en AL que le développement spécifique nécessaire.** 02 / INFORMATIQUE INTERNE ### Pour votre équipe informatique interne **Préserver le savoir accumulé. Soulager votre équipe.** Nous accompagnons aussi directement votre service Navision interne dans la préparation de la migration. Des documentations d'objets consultables, des règles métier extraites et une base de données orientée graphe rendent les interdépendances compréhensibles et facilitent la coordination entre l'informatique, les services métier et les partenaires d'intégration. **Les connaissances de vos collaborateurs restent déterminantes. Notre analyse y ajoute une base structurée et vérifiable.** 03 / EN AUTONOMIE ### Même sans intervention d'un intégrateur **L'analyse peut être menée de façon autonome.** Vous pouvez aussi commander l'analyse Navision indépendamment d'un projet de migration et sans participation active d'un partenaire externe. Nous convenons directement avec vous des accès et des sources d'analyse nécessaires. Les résultats sont ensuite à votre disposition pour l'exploitation courante, votre planification interne et la collaboration avec le partenaire de votre choix. ### Trois questions à poser à votre partenaire d'intégration 1. **Quelles données reprenons-nous, et comment sont-elles mises en correspondance ?** De nombreuses tables standard comme Client, Article ou En-tête vente existent toujours. Ce qui compte, ce sont les champs spécifiques, les valeurs d'option et les souches de numéros. 2. **Quelles personnalisations seront redéveloppées en AL, et avec quel effort ?** Le convertisseur Txt2Al de Microsoft n'existait qu'avec Business Central 14. Il ne traite pas les Forms et Dataports de NAV 2009 R2. 3. **Comment reprenons-nous les axes analytiques comme le centre de coûts et l'objet de coût ?** Aujourd'hui, les écritures renvoient à leurs axes analytiques via un ensemble de dimensions. Lors d'une réimplémentation, ce sont surtout les axes par défaut, les écritures ouvertes et le code qui traite les axes analytiques qui comptent. **L'analyse NAVtoBC fournit la base pour ces trois questions :** tables et champs avec preuve d'utilisation, personnalisations avec leurs dépendances, et endroits où le code lit ou écrit des axes analytiques. **Votre avantage :** tous les intervenants travaillent avec une base de connaissances commune et traçable – au lieu de devoir sans cesse redécouvrir les mêmes interdépendances. [Discuter d'une collaboration](https://navtobc.de/fr/kontakt) DES RÉSULTATS À VOIR, PAS SEULEMENT À LIRE ## De la connaissance des processus à la vision cible pour Business Central. Un exemple cohérent : client, commande et facture. Passez d’un onglet à l’autre : Analyse, Processus, Connaissances et Roadmap. Exemple illustratif à partir de données synthétiques – pas un projet client. NAV → Business Central EXEMPLE SYNTHÉTIQUE EXEMPLE DE RÉSULTAT ## Vue d’ensemble. En un coup d’œil. EXEMPLE D’ANALYSE SYNTHÉTIQUE .txt`// Valeurs de substitution cohérentesClient.Nom: "P-7Q4X9"Client.ID: "K-7Q4X9"Commande.Client: "K-7Q4X9"Facture.Client: "K-7Q4X9"` **Retracer les liens** Même client dans la commande et la facture Source : données d’exemple synthétiques Validation métier Uniquement des artefacts d’analyse validés, avec des valeurs de substitution cohérentes TRAÇABLE DE BOUT EN BOUT ### Même client. Documents liés. Décisions vérifiables. 1. **Identifier les liens** « P-7Q4X9 » reste lié à la commande et à la facture via l’identifiant client K-7Q4X9. 2. **Documenter le savoir** L’article de connaissance consigne ce lien avec le champ source et le statut de vérification métier. 3. **Évaluer la cible Business Central** Vérifier d’abord la couverture par le standard. Seules les exigences restantes conduisent à l’examen de modules ou à un développement spécifique. [Voir la pseudonymisation dans l’exemple](https://navtobc.de/fr/pseudonymisierung) **Voir un exemple de matrice de décision** Format de décision synthétique – ni recommandation de module vérifiée, ni recommandation client. | Exigence de l’exemple | Démarche de vérification | Étape suivante | Statut | | --- | --- | --- | --- | | Rattacher client et documents | Standard Business Central d’abord | Rapprocher déroulement et paramétrage avec le métier | Vérification du standard en attente | | Exigence sectorielle supplémentaire | Module certifié si le standard ne suffit pas | Vérifier adéquation, justificatifs, intégration et coûts | Revue des modules en attente | | Règle spécifique restante | Développement spécifique uniquement en cas d’écart confirmé | Documenter la nécessité et les alternatives | Aucun développement validé | DU RÉSULTAT D’ANALYSE AU PORTAIL DE CONNAISSANCES ## Votre savoir NAV.En dialogue direct. Posez vos questions sur votre système Navision – aussi simplement que dans une interface de chat inspirée de ChatGPT. Le portail web met à votre disposition les connaissances documentées par l’IA : règles métier, processus, interfaces et interdépendances techniques deviennent accessibles par le dialogue. En arrière-plan, une IA connectée par API traite vos requêtes et s’appuie sur la base de connaissances constituée localement. Si nécessaire, le portail peut également intégrer des données actuelles issues de la base de données Navision et d’autres ressources, via des interfaces validées en lecture seule. [Ouvrir la vue du portail en taille réelle](https://navtobc.de/images/nav-wissensportal.png) APERÇU DU PORTAIL DE CONNAISSANCES Analyse de projet NAV [![Portail de connaissances « Analyse de projet NAV » : champ de chat pour poser des questions sur le projet, ainsi que des points d’entrée vers la vue d’ensemble, les interdépendances et les points ouverts.](https://navtobc.de/images/nav-wissensportal.png)](https://navtobc.de/images/nav-wissensportal.png) Exploiter les résultats d’analyse et les sources de données validées via une interface de chat commune. **Connexion utilisateur locale** L’accès se fait via des comptes utilisateurs locaux. Chaque utilisation est ainsi rattachée à un utilisateur connecté. **Droits attribués de façon ciblée** La gestion des droits définit quelles informations et ressources validées un utilisateur peut interroger. **Accès en lecture seule** Les sources de données connectées sont uniquement lues. Le portail ne modifie aucune donnée NAV ni aucune autre source. **Requêtes journalisées** Toutes les requêtes sont journalisées. L’utilisation du portail reste ainsi traçable. Nous définissons ensemble, pour votre projet, quels fonds de connaissances, sources de données en direct et autorisations sont intégrés. [Découvrir le portail de connaissances](https://navtobc.de/fr/kontakt?thema=wissensportal) L’EXPÉRIENCE RENCONTRE LA MÉTHODE ## Des années d’expérience Navision. Exploitées systématiquement grâce à l’IA. Nous associons une connaissance pratique de Navision à l’analyse automatisée du code et à une exploitation assistée par IA. Il en résulte des interdépendances documentées et des propositions concrètes pour votre système actuel et pour le passage à Business Central. Navision Dynamics NAV MS Dynamics NAV Business Central L’APPROCHE NAVtoBC ## D’abord comprendre. Puis changer de façon ciblée. Des années d’adaptations ne sont pas forcément un obstacle. L’essentiel est d’identifier la logique dont votre activité a réellement besoin aujourd’hui. 01 Analyse par IA ### Comprendre votre NAV actuel. Exploiter les exports d’objets TXT validés avec notre propre parseur C/AL : recenser la logique spécifique, les appels, les références et les interfaces, avec renvoi aux sources. VOTRE RÉSULTAT **État des lieux technique** 02 Processus métier ### Déduire les processus de la logique. Extraire des hypothèses de processus et des règles métier à partir des sources, les documenter sous forme de référentiel de règles JSON et de graphes, puis les faire valider par le métier. VOTRE RÉSULTAT **Cartographie des processus documentée** 03 Base de connaissances ### Rendre le savoir durablement exploitable. Consigner les enseignements de façon structurée – avec renvoi aux sources, contexte métier et statut de vérification traçable. VOTRE RÉSULTAT **Votre base de connaissances centrale** 04 Proposition de migration vers Business Central ### Préparer la voie adaptée. Privilégier le standard Business Central, examiner les modules certifiés et n’inscrire dans une feuille de route priorisée que le développement spécifique nécessaire. VOTRE RÉSULTAT **Plan de migration solide** L’IA assiste l’analyse. Les services métier valident les résultats et décident des processus cibles. UN PÉRIMÈTRE CLAIR ## Une base claire. Une prochaine étape concertée. Notre offre décrite ici comprend l’analyse de votre système NAV, la documentation de votre savoir sur les processus et une proposition de migration solide vers Business Central. **Mise en œuvre, tests et mise en production à convenir séparément.** Les résultats servent de base à votre équipe interne, à votre partenaire actuel ou à une mise en œuvre convenue par la suite. [Discuter du périmètre de votre projet](https://navtobc.de/fr/kontakt) LA PROTECTION DES DONNÉES COMMENCE AVANT L’ANALYSE ## Ce qui compte : votre savoir métier. Pas vos données sensibles. L’analyse nécessite un accès SQL – mais pas directement par l’IA. Un serveur de pseudonymisation placé en amont accède à la base de données de manière contrôlée et remplace les valeurs identifiantes « à la volée », avant que les résultats validés ne soient transmis à l’analyse. VOTRE CODE SOURCE RESTE VOTRE SAVOIR ### Votre code source n’est pas utilisé pour entraîner des modèles d’IA. C’est une condition préalable à toute analyse : seuls sont utilisés des modes d’exploitation qui excluent l’utilisation de votre code source à des fins d’entraînement. Pour les services cloud, ce point est vérifié au regard des conditions et des paramètres convenus ; en local, l’analyse s’effectue sans utilisation de votre code source pour l’entraînement de modèles. 01 / ACCÈS SQL CONTRÔLÉ ### Accès SQL avec protection en amont. Le serveur de pseudonymisation placé en amont reçoit l’accès SQL convenu. Il traite les données, les statistiques d’utilisation et les indicateurs de volumétrie avant leur transmission. Les identifiants d’accès SQL et les sauvegardes de la base de données ne parviennent ni à l’IA ni au site web. Des exports d’objets et de métadonnées complètent l’analyse. 02 / À LA VOLÉE ### Remplacer les valeurs. Pas les supprimer. Les valeurs identifiantes sont remplacées dès la lecture par des valeurs de substitution durablement cohérentes. Le client d’exemple « Müller » reçoit le pseudonyme « P-7Q4X9 » – y compris lors de requêtes ultérieures sur le même périmètre d’analyse. Les enregistrements et les relations nécessaires sur le plan métier sont conservés. 03 / TRAÇABLE ### Les liens sont préservés. Des règles de substitution convenues garantissent la correspondance entre clients, commandes et factures. Après vérification et validation, les résultats sont analysés localement ou avec une IA dans le cloud convenue. Les règles métier sont déduites du code et des interdépendances du système. DANS VOTRE ENVIRONNEMENT **NAV / SQL & exports d’objets TXT** → **Serveur de protection : remplacer les valeurs** → **Vérifier & valider** ANALYSE : LOCALE OU CLOUD **Analyse assistée par IA** → **Savoir & feuille de route Business Central** L’environnement d’analyse peut être entièrement local. En mode cloud, seuls les artefacts validés à cet effet, avec des valeurs de substitution cohérentes, quittent votre environnement. Aucun basculement automatique du local vers le cloud. Aucun accès SQL direct par l’IA [Définir la protection des données de votre projet](https://navtobc.de/fr/kontakt?thema=datenschutz) REMPLACER LES DONNÉES. PRÉSERVER LES LIENS. ## Müller devient P-7Q4X9. Le lien demeure. Avant tout traitement par l’IA, les valeurs identifiantes sont remplacées par des pseudonymes stables. Au sein du périmètre d’analyse convenu, un même client identifié sans ambiguïté reçoit la même valeur de substitution, y compris lors de requêtes ultérieures. Des clients différents portant le même nom de famille reçoivent des pseudonymes différents. Les relations entre clients, commandes et factures restent traçables. Il est ainsi possible d’analyser les processus métier, les dépendances et les règles de programme sans avoir besoin des noms d’origine. La pseudonymisation concerne les données d’analyse ; les données NAV de production ne sont pas réécrites. La correspondance avec les valeurs d’origine est conservée séparément, avec un accès protégé, et n’est pas transmise à l’IA. Pour le responsable du traitement, les données restent des données à caractère personnel. [Pseudonymisation : art. 4, point 5) du RGPD ↗](https://eur-lex.europa.eu/legal-content/FR/TXT/?uri=CELEX%3A32016R0679) La pseudonymisation par l’exemple DONNÉES SYNTHÉTIQUES **Nom** P-7Q4X9 **N° client** K-7Q4X9 **E-mail** p-7q4x9@example.invalid **Client dans la commande** P-7Q4X9 · K-7Q4X9 **Client dans la facture** P-7Q4X9 · K-7Q4X9 MÊME CLIENT. MÊME VALEUR DE SUBSTITUTION. **P-7Q4X9 reste P-7Q4X9 – dans la commande comme dans la facture.** VOTRE INFRASTRUCTURE. VOTRE STRATÉGIE IA. ## IA dans le cloud ou IA locale. À vous de choisir. ChatGPT, Claude ou toute autre IA dans le cloud peuvent être retenus comme option d’exploitation. Vous pouvez aussi utiliser différents modèles locaux : sur votre matériel ou sur du matériel que nous vous prêtons pour la durée du projet. Nous convenons avec vous de l’intégration concrète. IA DANS LE CLOUD ### ChatGPT, Claude. Et votre IA dans le cloud. Vous n’êtes lié à aucun fournisseur en particulier. ChatGPT, Claude et d’autres IA dans le cloud prennent en charge les étapes d’analyse validées. Nous convenons du fournisseur, du modèle et des interfaces disponibles en fonction de chaque projet. ChatGPT · OpenAI Claude · Anthropic Autres IA dans le cloud **Détails du mode d’exploitation** **Flux de données** Avant le traitement par l’IA, remplacer de façon cohérente les valeurs identifiantes, puis les vérifier et les valider. **Intégration** Connecter le fournisseur choisi via des interfaces adaptées, mises en place séparément. **Cadrage** Vérifier au préalable les conditions contractuelles, le traitement des données et leur conservation. [Discuter de l’IA dans le cloud](https://navtobc.de/fr/kontakt) IA LOCALE ### Votre matériel. Ou le nôtre, en prêt. Différents modèles d’IA locaux fonctionnent sur votre propre matériel. Nous pouvons aussi vous prêter du matériel adapté pour la durée du projet. Le choix des modèles et l’équipement dépendent de vos tâches d’analyse. Votre matériel Matériel en prêt Différents modèles **Détails du mode d’exploitation** **Flux de données** En local aussi : valeurs de substitution cohérentes et validation avant le traitement par l’IA. **Exploitation** Analyse locale sur votre propre matériel ou sur du matériel prêté, dans votre environnement. **Limites** Aucune transmission automatique vers des services cloud. Contrôler les connexions sortantes. [Discuter de l’IA locale](https://navtobc.de/fr/kontakt) COMBINABLE EN OPTION ### Local et cloud. Une combinaison ciblée. Certaines tâches d’IA en local, d’autres dans le cloud – avec une validation propre à chaque étape de traitement. **Aucun repli automatique vers le cloud.** Les mêmes critères de qualité s’appliquent à tous les modes d’exploitation. [Clarifier le mode d’exploitation](https://navtobc.de/fr/kontakt) Les modèles et intégrations concrets sont convenus dans le cadre du projet. Le mode d’exploitation de l’IA est indépendant du fait que Business Central soit ensuite exploité en ligne ou sur site. AUTRES ANALYSES PAR IA ### Analyser Active Directory avec l’IA. Rendez-vous sur KI4AD.de pour en savoir plus sur l’analyse de votre Active Directory assistée par IA. [Visiter KI4AD.de](https://ki4ad.de/) TECHNIQUES & MÉTHODES ASSISTÉES PAR IA ## Analyser le C/AL en profondeur. Des résultats traçables. Un parseur maison, une assistance IA ciblée et des chaînes de vérification contraignantes : notre approche d’analyse relie constats techniques et compréhension métier. ### À propos de la fiabilité de l’analyse **L’IA fait des erreurs.** L’exhaustivité et l’absence d’erreurs ne peuvent pas être garanties dans une analyse – pas même avec un travail entièrement manuel. L’objectif est une **base de travail suffisamment solide pour votre migration**. C’est pourquoi nous rendons visibles les incertitudes et les points ouverts, et vérifions les résultats avec vos services métier. LE PARCOURS D’ANALYSE EN FILM 3D ### Du flux de données à l’analyse par IA. 60 secondes ![Film 3D sur les données, les interfaces et l’analyse par IA](https://navtobc.de/fr/film/datenfluss-v1.webp) [Film 3D sur les données, les interfaces et l’analyse par IA](https://navtobc.de/fr/film/navtobc-datenfluss-v1.mp4) Connecter les interfaces, structurer le patrimoine NAV, valider les données, puis analyser les constats par IA et les contre-vérifier. Une représentation schématique avec des données d’exemple, sans son. [Ouvrir le lecteur 3D interactif](https://navtobc.de/fr/film/index.html) [Télécharger le film en MP4](https://navtobc.de/fr/film/navtobc-datenfluss-v1.mp4) **Les cinq scènes du film en texte** 1. **00:00 · Interfaces.** Les données issues de l’EDI, de la boutique en ligne, de SQL et du C/AL alimentent le patrimoine NAV. 2. **00:12 · Traitement NAV.** Code source, tables et références sont recensés de façon structurée. 3. **00:24 · Validation des données.** Des valeurs de substitution cohérentes préservent les relations entre les informations validées. 4. **00:34 · Analyse par IA.** Des rôles distincts analysent et vérifient preuves, contradictions et questions ouvertes. 5. **00:48 · Résultats.** Règles métier, base de connaissances et cible BC deviennent traçables, avec sources et statut de vérification. **Nos méthodes en détail 8 méthodes d’analyse et de vérification** 01 COMPRENDRE LE CODE ### Analyse statique du code C/AL Un parseur C/AL maison recense les appels et les références dans le code source Navision fourni. Il en résulte un graphe des appels et des références, précis à la fonction et à la ligne près, qui sert de base à l’interprétation assistée par IA. **La méthode en détail** Chaque constat renvoie à l’objet, à la fonction et à la ligne dans l’export validé. Les appels dynamiques impossibles à résoudre, les objets manquants et les limites du parseur sont signalés de façon visible – et non présentés comme analysés avec certitude. 02 DÉTERMINER LA PERTINENCE ### Atteignabilité depuis une liste d’ancres Analyse d’atteignabilité à partir d’une liste d’ancres définie avec le métier, plutôt qu’une élimination itérative. Les dépendances sont suivies à partir de points d’entrée connus. **La méthode en détail** La liste d’ancres comprend par exemple les états exécutés, les files d’attente des travaux et les appels externes. « Non atteignable depuis les ancres recensées » ne signifie pas automatiquement « inutilisé ». Les chemins incertains restent à vérifier. 03 PROUVER L’UTILISATION ### Preuve d’utilisation par table Les statistiques d’accès SQL et des indicateurs de volumétrie agrégés complètent l’analyse du code. Le serveur de pseudonymisation placé en amont fournit les résultats validés – à jour au jour près en cas de collecte et de traitement quotidiens. **La méthode en détail** La date de collecte, la période d’observation et les indices de réinitialisation des statistiques sont consignés. L’accès SQL passe par le serveur placé en amont ; l’IA ne reçoit que des résultats validés. L’absence d’accès ne prouve pas la non-utilisation ; le volume de données et le contexte métier sont évalués séparément. En cas de réimplémentation, la preuve d’utilisation montre quelles tables et données peuvent être reprises. Les anciennes versions de NAV exportent le texte dans le jeu de caractères MS-DOS ; les caractères accentués sont donc vérifiés avant la reprise. 04 CONTRE-VÉRIFIER LES RÉSULTATS ### Chaînes de vérification multi-agents Des rôles d’agents distincts pour l’analyse, la contre-vérification et la consolidation. Les affirmations sont rattachées aux sources ; contradictions et questions ouvertes restent traçables. [![Claude Code affiche une chaîne de vérification en cours avec trois agents IA travaillant en parallèle et les phases Verify et Critique.](https://navtobc.de/claude-code-pruefkette.png) Ouvrir l’exemple en taille réelle](https://navtobc.de/claude-code-pruefkette.png) **Exemple tiré de Claude Code.** Trois agents IA examinent en parallèle un inventaire d’outils. Une contre-vérification critique est ensuite prévue. **La méthode en détail** La contre-vérification évalue les preuves, la couverture et les explications alternatives. La concordance de plusieurs agents ne prouve pas à elle seule l’exactitude. Les validations métier et les garde-fous techniques restent indispensables. 05 CONTRÔLER LA QUALITÉ ### Autotests, tests de mutation, sommes de contrôle Les autotests vérifient les résultats attendus. Les tests de mutation modifient délibérément des cas de test. Les sommes de contrôle associent sans ambiguïté les constats aux versions d’artefacts vérifiées. **La méthode en détail** Les tests de mutation vérifient si des erreurs introduites volontairement sont détectées. Les sommes de contrôle servent au contrôle de version et d’intégrité ; elles ne prouvent ni l’exactitude métier ni la protection des données personnelles. Des vérifications en échec bloquent la validation des résultats. 06 APPRENDRE DE SES ERREURS ### Processus contraignant d’apprentissage par l’erreur Chaque erreur confirmée donne lieu à une analyse des causes, à un test de non-régression et à une règle versionnée. Les règles ancrées mécaniquement sont vérifiées automatiquement – et pas seulement formulées sous forme de consignes. **La méthode en détail** Un cas d’erreur n’est clos qu’après une preuve reproductible, une correction et un test de non-régression réussi. Des garde-fous empêchent la validation en cas de violation des règles. L’état des règles et les responsabilités sont documentés. 07 CORRIGER LES FAIBLESSES ### Tables SQL, CU & ports Les faiblesses identifiées dans les tables SQL, les Codeunits (CU) ainsi que les Dataports/XMLports sont traduites en propositions d’amélioration concrètes – avec constat, priorité et étape de vérification. **La méthode en détail** Sont examinés par exemple les schémas d’accès inhabituels, la logique redondante et les contrôles d’import insuffisants. Les suppositions sur les performances restent des hypothèses jusqu’à leur mesure. Aucune modification n’est apportée automatiquement au système de production. 08 PRÉSERVER LE SAVOIR MÉTIER ### Extraction des règles métier Les règles métier sous forme de référentiel JSON lisible par machine et de graphes : avec conditions, actions, dépendances, références aux sources et statut de vérification métier. **La méthode en détail** Les règles reçoivent des identifiants stables et des références à la fonction et à la ligne dans l’export validé. Les règles confirmées alimentent la base de connaissances et l’analyse des écarts (fit-gap) pour Business Central. Les informations manquantes et les hypothèses non étayées restent signalées. ### Pour aller plus loin **Comment obtient-on une preuve d’utilisation à jour au quotidien ? +** Le serveur placé en amont lit les statistiques d’accès SQL et les indicateurs de volumétrie convenus. Avant transmission, les valeurs identifiantes sont remplacées par des valeurs de substitution cohérentes. Une actualisation quotidienne suppose une collecte quotidienne et un traitement réussi ; la date des données et la fenêtre d’observation sont indiquées. Les compteurs d’utilisation SQL peuvent par exemple être réinitialisés après un redémarrage du serveur. L’absence de signaux d’accès ne prouve donc pas la non-utilisation ; inversement, la seule présence de données ne prouve pas l’existence d’un processus métier actif. **Pourquoi analysez-vous l’atteignabilité à partir d’une liste d’ancres ?+** Nous partons de points d’entrée définis avec le métier et suivons, à partir de là, les relations d’appel et de référence. Cela remplace une élimination purement itérative d’objets apparemment inutilisés. Les listes d’ancres incomplètes, les appels dynamiques et les exports manquants sont explicitement signalés comme limites. L’analyse ne supprime aucun objet et ne remplace pas une décision métier de mise hors service. **Quelles règles métier obtenons-nous en JSON et sous forme de graphes ?+** Le résultat prévu contient, pour chaque règle métier extraite, un identifiant, des conditions, des actions, des dépendances ainsi que des références aux sources (objet, fonction et ligne). Un graphe des règles montre les relations. Le statut de vérification et les hypothèses ouvertes sont conservés ; seule la confirmation par le métier transforme une ébauche de règle en base de connaissances validée. **Que signifie un processus d’apprentissage par l’erreur ancré mécaniquement ?+** Les erreurs confirmées sont documentées sous forme de cas reproductibles et sécurisées par des tests de non-régression et des règles de vérification versionnées. Ces règles sont contrôlées automatiquement et peuvent bloquer une validation. Une simple consigne supplémentaire adressée à un agent IA ne suffit pas. **Comment Claude et ChatGPT sont-ils intégrés dans des processus automatisés ?+** L’utilisation de ChatGPT et une intégration via l’API OpenAI sont à considérer séparément. Pour les chaînes de vérification automatisées, une connexion via l’API OpenAI ou l’API Claude est mise en place spécifiquement pour chaque projet. Un abonnement ChatGPT ne remplace pas une facturation API distincte. [OpenAI : ChatGPT et API sont distincts ↗](https://help.openai.com/en/articles/8156019-how-can-i-move-my-chatgpt-subscription-to-the-api) · [Anthropic : API Claude ↗](https://platform.claude.com/docs/en/api/overview) NOTRE EXIGENCE DE QUALITÉ Chaque affirmation étayée. **Chaque incertitude visible.** L’analyse déterministe du code et l’IA se complètent. Ce que les sources n’étayent pas est signalé comme ouvert et clarifié avec vos services métier. [Discuter de l’analyse](https://navtobc.de/fr/kontakt) Nos méthodes associent constats techniques, vérification métier et documentation traçable. BON À SAVOIR ## Les questions essentielles. Avant la première étape. Toutes les adaptations n’ont pas à être reprises. Mais chaque règle critique pour votre activité mérite de l’attention. [Discuter de votre situation](https://navtobc.de/fr/kontakt) **Le C/AL est-il analysé automatiquement ?** **Oui.** Notre outil d’analyse maison examine automatiquement le code source C/AL de votre système Navision ou Dynamics NAV. Les résultats sont documentés de façon structurée, objet par objet, et archivés de manière consultable. **Disposez-vous d’un outil d’analyse maison ?** **Oui.** Nous utilisons notre propre outil d’analyse pour l’analyse NAV automatisée. **Les FOB NAV sont-ils exploités directement ?** **Non.** Notre outil d’analyse lit des exports d’objets TXT contenant le code C/AL et les propriétés des objets. Si les objets sont disponibles au format FOB, ils sont d’abord importés dans un environnement de développement NAV adapté, puis exportés au format TXT avec la licence développeur requise. Les fichiers FOB natifs ne sont pas traités directement. [Particularités du C/AL et base d’analyse en détail →](https://navtobc.de/fr/cal-besonderheiten) **Existe-t-il une transformation automatique du code en AL ?** **Non.** Le code C/AL existant n’est pas converti automatiquement en code AL. Nous examinons d’abord le standard Business Central et les modules ISV adaptés. Seul le développement spécifique encore nécessaire est **réécrit en AL** sur la base de la logique métier requise – au lieu de transposer l’ancien code à l’identique. **Quelles versions cibles de Business Central sont prises en charge ?** **Toutes les versions cibles de Business Central à partir de 2025.** La version cible précise est définie pour chaque projet de migration. **Comment l’IA accompagne-t-elle la migration NAV ?** IA signifie intelligence artificielle. Nous associons l’analyse du code C/AL de votre système Navision ou Dynamics NAV à une exploitation assistée par IA. Vous obtenez des règles métier documentées, une base de connaissances consultable et une proposition de migration vers Business Central. L’analyse constitue la base de la migration technique ; les validations métier relèvent de vos services métier. Sur demande, nous convenons ensuite séparément de la mise en œuvre, ou votre partenaire s’en charge. **Que signifie le passage de C/AL à AL lors de la migration ?** C/AL désigne la logique de programme existante de nombreuses adaptations NAV ; AL est utilisé pour les extensions Business Central. Lors d’une migration C/AL vers AL, nous vérifions d’abord si le standard Business Central répond déjà à l’exigence ou si des modules ISV certifiés adaptés sont disponibles. Seuls les écarts justifiés sont planifiés sous forme d’extensions AL spécifiques – pas de simple reprise à l’identique de l’ancien code. **Une migration vers le cloud est-elle obligatoire ?** Non. La cible Business Central – en ligne ou sur site (on-premises) – est définie indépendamment du mode d’exploitation de l’IA. Pour une migration vers le cloud, nous examinons en particulier les interfaces, les structures de données et les extensions. L’analyse NAV peut être réalisée avec une IA dans le cloud ou avec des modèles d’IA locaux, sur votre matériel ou sur du matériel prêté par nos soins. La voie de mise en œuvre concrète est convenue dans le cadre du projet. **L’analyse nécessite-t-elle un accès à notre base de données SQL ? +** Oui. L’accès SQL nécessaire passe par un serveur de pseudonymisation placé en amont, doté d’autorisations convenues. Celui-ci remplace les valeurs identifiantes avant que les résultats validés ne parviennent à l’IA. Ni l’IA ni ce site web ne reçoivent d’accès direct à la base de données, d’identifiants SQL ou de sauvegardes de la base. Des exports d’objets et de métadonnées peuvent être fournis en complément. **L’analyse par IA peut-elle se faire dans le cloud ou entièrement en local ? +** Oui. ChatGPT, Claude ou toute autre IA dans le cloud peuvent être retenus comme option d’exploitation ; les interfaces adaptées, les conditions contractuelles et les validations de données sont convenues au préalable. Nous pouvons aussi utiliser différents modèles locaux sur votre matériel ou sur du matériel que nous vous prêtons. Une combinaison expressément convenue est également possible. Dans toutes les variantes, le remplacement des valeurs identifiantes et la validation interviennent avant le traitement par l’IA. **De quel matériel avons-nous besoin pour une IA locale ? +** Différents modèles locaux peuvent prendre en charge l’analyse, l’extraction de règles et la contre-vérification. Ils fonctionnent sur votre matériel existant ou sur du matériel que nous vous prêtons pour la durée du projet. Nous définissons l’équipement, la durée du prêt et les licences des modèles en fonction des tâches d’analyse. En exploitation purement locale, les embeddings, la base de connaissances, les journaux et les services auxiliaires restent eux aussi locaux. Les fonctions cloud et les solutions de repli automatiques vers le cloud ne sont pas activées sans votre accord. **L'IA peut-elle identifier automatiquement tous les processus métier ?+** À partir des artefacts disponibles, l'analyse vise à déduire des hypothèses de processus et des règles métier. Les étapes manuelles, les exceptions non documentées et les processus qui se déroulent en dehors de NAV doivent être complétés lors d'ateliers. Les résultats restent signalés comme provisoires jusqu'à leur validation par les services métier. **Les adaptations sont-elles reprises telles quelles dans Business Central ?** Non. Nous privilégions le standard Business Central. S'il ne suffit pas, les programmes spécifiques doivent, dans la mesure du possible, être remplacés par des modules certifiés adaptés. Le développement spécifique n'entre en ligne de compte que pour les exigences nécessaires dont il est démontré qu'elles subsistent. Les décisions, les alternatives et les vérifications en suspens sont documentées. **L'analyse constitue-t-elle déjà la migration technique ?** L'analyse fournit la base de décision. La mise en œuvre technique, la reprise des données, les tests de migration et la mise en production font l'objet d'un accord distinct – avec votre équipe interne, votre partenaire actuel ou dans le cadre d'une mise en œuvre convenue par la suite. **Nos rapports Power BI fonctionneront-ils encore après la migration ?** Pas sans modification s'ils accèdent directement aux tables NAV ou à des pages NAV publiées. Business Central met les données à la disposition de Power BI via des pages et des requêtes API ; dans Business Central online, c'est la seule méthode prise en charge. Pour la finance et les ventes, il existe des applications modèles prêtes à l'emploi. Nous recensons les sources de données utilisées par vos rapports et indiquons ce qui doit être reconnecté. **Quelles informations sont utiles pour le premier entretien ?** Votre version de NAV, les principaux services métier, les adaptations connues et votre objectif pour Business Central. Nous clarifions ensuite ensemble les sources d'analyse et le modèle d'exploitation de l'IA adapté. LA PREMIÈRE ÉTAPE, C'EST LA CLARTÉ ## Que cache votre NAV ? Parlez-nous de votre situation de départ. Ensemble, nous déterminons quelle analyse est pertinente pour votre migration. LES PROCHAINES ÉTAPES **01** Faire le point sur la situation de départ et la cible **02** Convenir de l'accès SQL et de la protection des données **03** Définir la démarche d'analyse et le modèle d'exploitation de l'IA DIAGNOSTIC INITIAL SANS ENGAGEMENT ### Diagnostic initial sans engagement Quelques données clés suffisent pour une première estimation de l'effort et de la démarche. \* Champ obligatoire COÛTS & DÉLAIS #### Quels coûts et quels délais ? Les coûts et la durée dépendent de la version de NAV, du degré d'adaptation, des interfaces, du volume de données et de la cible visée. Après un bref diagnostic initial, vous recevez une enveloppe budgétaire concrète et une estimation réaliste des délais – avant que d'autres étapes ne soient convenues. NAVtoBC.de n'a aucun lien avec NAVTOBC.com.