NAVtoBC.de Demander un diagnostic initial

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 engagementDécouvrir les résultats

Le standard Business Central d'abord. Privilégier les modules certifiés.
Ne développer du spécifique que de façon ciblée.

Analyse & planification de la migration
VOTRE BASE DE DÉCISION

Le savoir devient perspective.

DÉMO
01 / PRIORITÉStandard Business CentralExploiter les fonctionnalités
02 / EXTENSIONModules
certifiésRemplacer le code spécifique
03 / ÉCART JUSTIFIÉSpécifique
et cibléDévelopper le nécessaire
Les liens sont préservésValeurs de substitution cohérentes
ClientP-7Q4X9
CommandeP-7Q4X9
FactureP-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
É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.

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.

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.

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

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.

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.

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.

EDILobster EDIDocuments, données de base
et informations de statut
BIQlikReporting, analyse
et mise à disposition des données
Navision / Dynamics NAVC/AL · SQL · logique métier
IMPORTDonnées articlesDonnées de base, variantes,
unités et prix
BOUTIQUEBoutiques en ligneArticles, prix, stocks
et commandes
CE SUR QUOI PORTE L'ANALYSE
Export de donnéesContenus, formats cibles
et destinataires
Rapprochement à l'importCorrespondance 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.

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

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

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.

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 & valeursSyntaxe 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éesType 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étierVALIDATE, 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 & calculsFiltres, 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énementsRecordRef, 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 & SQLCOMMIT, 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 standardFormat 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 & interfacesGé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
Sources de référence & contexte

Vérifié le à 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.

Comment nous combinons analyse de code et IA

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/AL480 000 lignes
CODEUNITSPrès de 1 000
SYSTÈMENAV 2009 R2
VOLUME DE DONNÉESenv. 1,5 To
HISTORIQUE DU SYSTÈME20 ans
SECTEURCommerce 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

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.

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

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.

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

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

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.

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érentes
Client.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étiquesValidation 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
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’exempleDémarche de vérificationÉtape suivanteStatut
Rattacher client et documentsStandard Business Central d’abordRapprocher déroulement et paramétrage avec le métierVérification du standard en attente
Exigence sectorielle supplémentaireModule certifié si le standard ne suffit pasVérifier adéquation, justificatifs, intégration et coûtsRevue des modules en attente
Règle spécifique restanteDéveloppement spécifique uniquement en cas d’écart confirméDocumenter la nécessité et les alternativesAucun 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
APERÇU DU PORTAIL DE CONNAISSANCESAnalyse 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.
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

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.

NavisionDynamics NAVMS Dynamics NAVBusiness 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ÉSULTATCartographie 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ÉSULTATVotre 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ÉSULTATPlan 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

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.

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

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 ↗
La pseudonymisation par l’exempleDONNÉ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.

Données d’exemple fixes : aucune suppression, aucun changement de valeur de substitution. Cette démo ne traite aucune donnée réelle et ne transmet rien.

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 · OpenAIClaude · AnthropicAutres 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
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érielMatériel en prêtDiffé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
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

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.

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.

Nos méthodes en détail8 méthodes d’analyse et de vérification
01COMPRENDRE 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.

02DÉ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.

03PROUVER 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.

04CONTRE-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. Ouvrir l’exemple en taille réelle
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.

05CONTRÔ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.

06APPRENDRE 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.

07CORRIGER 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.

08PRÉ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 ↗ · Anthropic : API Claude ↗

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

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
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 →

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.

Vérification du statut d'envoi en cours.
01Contact
VÉRIFICATION DE L'E-MAILPour la vérification, nous envoyons un code de confirmation à usage unique à l'adresse e-mail indiquée.
02Projet & cible
20 caractères minimum.0 / 5 000

Vos données sont utilisées exclusivement pour traiter votre demande. Vous trouverez des informations sur le traitement dans notre Politique de confidentialité. Aucun abonnement à une newsletter.

NAVtoBC.de n'a aucun lien avec NAVTOBC.com.