--- title: "Méthodes d'analyse et IA | NAVtoBC.de" description: "Allier analyse de code déterministe et IA : des constats étayés par des sources, avec statut de vérification et incertitudes rendues visibles." url: https://navtobc.de/fr/methoden language: fr --- # Méthodes d'analyse et IA 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.