Portes qualité pour du code D365 F&O généré par IA
Les contrôles à enchaîner avant de fusionner du code X++ généré par IA : compilation, BP check, tests, pull request, stratégies de branche, recette.
La réponse courte
Un code généré par IA doit franchir les mêmes portes qu'un code écrit à la main, dans cet ordre : compilation et bonnes pratiques (BP check), tests unitaires, revue par pull request protégée par des stratégies de branche Azure DevOps (relecteurs minimum, build de validation, work item lié, commentaires résolus), puis build du package et recette sur un environnement de test. Chaque porte arrête ce que la précédente ne peut pas voir.
Porte 1 : compilation et BP check
Le compilateur X++ exécute les règles de bonnes pratiques ; l'outil xppbp.exe peut produire le Customization Analysis Report d'un modèle. Cette porte attrape boucles imbriquées, insert en boucle, try mal géré dans une transaction, méthodes display non mises en cache… Voir avertissements BP check et corrections.
Porte 2 : tests unitaires
Des tests SysTest vérifient le comportement demandé. Attention : ils nécessitent le runtime. Le build sur agents hébergés par Microsoft ne les exécute pas ; il faut un environnement (UDE, environnement de build) où le code de test est déployé. Voir premier test unitaire SysTest et UDE.
Porte 3 : pull request et stratégies de branche
Dans Azure Repos, les stratégies de branche rendent la revue obligatoire : nombre minimum de relecteurs, work items liés, résolution des commentaires, types de fusion autorisés, build de validation (un pipeline doit réussir avant la fusion) et contrôles de statut externes. Pour un code généré, c'est la porte décisive : une personne qui connaît votre système relit avec une grille. Voir la checklist en 10 points.
Porte 4 : package et recette
Le pipeline compile la branche fusionnée et produit le package déployable (voir pipeline de build Azure DevOps). Le package est d'abord installé sur un environnement de test, où le métier valide le comportement réel avec ses données, avant toute mise en production.
Et chez Skalp AI ?
Chez Skalp AI, l'agent génère le code X++ et ses tests unitaires, compile en contrôlant les bonnes pratiques, puis pousse une pull request dans le projet Azure DevOps du client avec les captures d'écran des tests. Rien n'arrive sur la branche de travail sans la relecture et la validation de la pull request par l'architecte technique du client. Les portes 1 et 2 sont donc franchies avant la livraison ; les portes 3 et 4 restent chez vous. Voir intégration Azure DevOps, développer en X++ sans consultant en 2026 et les offres Basic, Pro et Max (1 crédit, ≈ 400 € en Basic, 200 € en Pro, consommé seulement à la génération du code).
À lire aussi : créer des tickets D365 F&O par IA dans Azure DevOps.
Sources
- Microsoft Learn, « Set and manage branch policies », mise à jour du 15/07/2026, consultée le 18/10/2026.
- Microsoft Learn, « Customization Analysis Report (CAR) », mise à jour du 26/02/2026, consultée le 18/10/2026.
- Microsoft Learn, « Build automation that uses Microsoft-hosted agents and Azure Pipelines », mise à jour du 05/03/2026, consultée le 18/10/2026.
- Microsoft Learn, « Testing and validations », mise à jour du 29/04/2026, consultée le 18/10/2026.
Questions fréquentes
Quelle stratégie de branche activer en premier ?
Un nombre minimum de relecteurs et un build de validation : la revue humaine et la compilation automatique avant chaque fusion.
Les tests SysTest peuvent-ils tourner dans le pipeline hébergé ?
Non. Le build hébergé compile et package seulement ; les tests demandent un environnement avec le runtime.
Un code généré par IA demande-t-il des portes supplémentaires ?
Les mêmes portes, appliquées sans exception. La relecture par pull request mérite simplement une grille explicite, car l'IA ne connaît pas votre contexte comme vos développeurs.
Prêt à transformer votre D365 ?
Rejoignez les DSI qui développent leurs tickets D365 en 2 à 4 h pour 1 crédit (≈ 400 € en Basic, 200 € en Pro).