Un développeur apprend à Claude Code et Codex à corriger les processus métier de Bitrix24 via .bpt

Un processus métier dans Bitrix24 vit plus longtemps que la mémoire de ses auteurs. Une demande doit toujours être approuvée, un responsable désigné, une notification envoyée. Mais au fil des ans, le schéma devient un arbre dont les blocs s'appellent « Condition » et « Notification », et pour changer un parcours, il faut deviner les intentions de quelqu'un d'autre. Les réseaux de neurones analysent depuis longtemps des dépôts de code, alors qu'ici tout se fait à la main. L'auteur du projet a décidé de corriger cela et a donné aux agents IA de vrais outils.

Ce que reçoit l'agent

Demander « corrige le processus métier » n'apporte rien au modèle : il ignore comment Bitrix stocke un modèle. Une capture d'écran du schéma n'aide pas non plus, car on n'y voit ni les propriétés des blocs, ni les expressions, ni les liens entre les actions.

C'est pourquoi le dépôt contient un seul skill : un fichier décrivant la marche à suivre, quatre références (structure du modèle, expressions, types d'actions, passerelle) et des scripts Python. Ils décompressent le fichier, affichent l'arbre, recherchent les nœuds et vérifient les liens. Un .bpt exporté est une sérialisation PHP sur zlib, et non du XML ou du JSON. On ne peut pas remplacer directement un libellé russe dans le texte : la longueur de la chaîne est enregistrée en octets, et le fichier serait corrompu. La modification passe par la structure : on charge, on change la propriété, on reconstruit.

Il existe deux modes. En mode fichier, l'agent travaille sur l'export et l'import vers le portail reste une étape distincte ; cela convient aussi au cloud, si le portail autorise l'export et l'import. Dans le second mode, un module payant pour la version boîte fournit une passerelle : via le client bpagent.py, l'agent lit le processus, trouve la branche et envoie la correction. MCP n'est pas utilisé ici, et le module n'embarque aucun modèle.

Le travail en pratique

Le validateur est d'abord lancé sur le modèle d'origine, afin que les anciens défauts ne soient pas imputés à l'agent. Vient ensuite la recherche : par type de nœud, par sous-chaîne, par exemple un ancien domaine, et la lecture d'un sous-arbre. Par défaut, le client ne renvoie pas un grand arbre en entier s'il compte plus de 150 nœuds. Une bonne pratique : séparer la recherche et le remplacement, car un même domaine peut figurer dans le texte d'un e-mail, dans une condition ou dans du code exécutable.

En pratique, l'agent a trouvé des URL incorrectes et des problèmes d'employés assignés. L'auteur précise honnêtement qu'il n'a pas de mesures précises du temps gagné et qu'il n'a pas créé de processus de zéro avec cette méthode.

Sécurité de l'écriture

La lecture renvoie l'arbre et un hash de version. L'écriture exige ce hash dans l'en-tête If-Match, faute de quoi le serveur refuse. Avant l'enregistrement, la passerelle vérifie les types, les droits et les tailles, lance le validateur et crée un instantané. L'écriture passe par la méthode native CBPWorkflowTemplateLoader::update(), sans SQL direct. La clé d'accès peut être limitée aux droits de lecture, d'écriture, de création et de lancement, ainsi qu'à des modèles précis. La modification du PHP intégré (CodeActivity) nécessite un droit distinct, templates:write_code, car il s'agit de code exécuté sur le serveur du portail.

Limites

Le validateur ne contrôle que la structure. Un lien existant vers une constante existante peut être formellement correct et pourtant erroné sur le fond. L'écriture est fermée pour NodeWorkflowActivity. La version 0.3.1 n'offre pas de verrouillage atomique face à un enregistrement parallèle depuis l'éditeur visuel ; mieux vaut donc se coordonner pour savoir qui modifie le processus. Autre point : même avec Bitrix installé sur votre propre serveur, le contenu des modèles est transmis à un agent externe et relève des conditions de votre outil d'IA. Le module est pour l'instant en cours de modération sur le Marketplace de 1C-Bitrix.

Que faire

Si vous avez des dizaines de processus accumulés, commencez par le mode fichier sur une copie de l'export : demandez à l'agent uniquement de trouver et d'expliquer, sans rien modifier. Après validation, vérifiez la correction dans le designer et testez-la sur une entité de test. Ce schéma est utile au-delà de Bitrix : donnez à l'agent un format, des outils et l'ordre « étudier, modifier, vérifier », plutôt qu'un simple JSON gigantesque.