Créer des tickets D365 F&O par IA dans Azure DevOps : comment faire

Une IA peut transformer une demande métier exprimée en langage naturel en ticket structuré (user story, bug, tâche) dans Azure DevOps : elle reformule le besoin, propose des critères d'acceptation, identifie les objets D365 F&O concernés, puis crée le work item. Techniquement, deux voies : l'API REST Work Items d'Azure DevOps, ou le serveur MCP Azure DevOps de Microsoft, qui donne à un agent IA des outils de lecture et d'écriture sur les work items.

L'intérêt n'est pas de supprimer la validation humaine : c'est d'obtenir des tickets complets dès le départ, que le responsable ERP ou le DSI valide avant développement.

Microsoft propose un serveur MCP Azure DevOps, en version distante hébergée (recommandée, authentification Microsoft Entra ID) ou locale. Ses outils de work items permettent notamment de lire un élément, d'exécuter une requête WIQL, de lister le backlog, et, en écriture, de créer un work item, de le mettre à jour ou d'ajouter des éléments enfants. Un en-tête de configuration permet de restreindre le serveur à la lecture seule, et on peut limiter les ensembles d'outils exposés.

Bonne pratique : commencer en lecture seule (l'agent analyse le backlog et propose), puis n'ouvrir l'écriture qu'à un périmètre et un projet définis.

Que l'IA ou un humain l'écrive, un ticket exploitable contient :

• le besoin métier et le processus concerné (module, formulaire, état) ;
• le comportement attendu et des critères d'acceptation vérifiables ;
• les données d'exemple et la société concernée ;
• les contraintes : sécurité (rôles), performances, intégrations touchées ;
• le type de développement pressenti (extension de table, Chain of Command, état, data entity, batch…) ;
• les liens vers les tickets ou le code existants.

Avec Azure DevOps, une stratégie de branche peut ensuite exiger qu'une pull request soit liée à un work item avant fusion : la traçabilité ticket → code est automatique.

• Laisser un agent créer des tickets sans validation : doublons et demandes floues se multiplient.
• Donner à l'agent des droits d'écriture sur toute l'organisation Azure DevOps.
• Accepter des critères d'acceptation non vérifiables (« doit être rapide »).
• Ne pas relier le ticket au code livré : on perd l'historique.
• Envoyer des données de production sensibles dans la description du ticket.

Chez Skalp AI, le chat et la qualification du besoin sont gratuits. À l'activation du smart contract, Skalp crée lui-même le work item dans le projet Azure DevOps du client : type Task, titre portant le numéro TK-<année>-<numéro>, description = spécification HTML structurée en F-xx (formulaires), REP-xx (états), DE-xx (data entities) et PARAM-xx (paramètres). Le code est ensuite livré par pull request, validée par votre architecte technique. Voir intégration Azure DevOps D365, le cadre général dans 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).

• Microsoft Learn, « Set up the remote Azure DevOps MCP Server », mise à jour du 21/09/2026, consultée le 18/10/2026.
• GitHub, Microsoft, « Azure DevOps MCP Server (README) », consultée le 11/10/2026.
• Microsoft Learn, « Set and manage branch policies », mise à jour du 15/07/2026, consultée le 18/10/2026.
• Microsoft Learn, « Work Items - Create (REST API) », consultée le 18/10/2026.