Le calculateur Excel de devis dans Bitrix24 remplacé par une application créée par un agent IA

Excel vit dans les services commerciaux plus longtemps qu'on ne le voudrait. Tant qu'une seule personne utilise le tableur, tout va bien. À dix, chacun a sa propre copie : l'un travaille avec un ancien tarif, un autre a « légèrement corrigé » la formule, un troisième a accordé au client une remise supérieure au règlement. Le responsable ne l'apprend qu'à la lecture du contrat signé. Le rédacteur technique Igor Roslyakov, dans le cadre d'une série d'articles Bitrix24 DevRel, a vérifié à quelle vitesse un tel calculateur peut être remplacé par une application au sein du CRM, si l'essentiel du travail est fait par un agent IA.

Ce qui a été construit et pourquoi

Le scénario est simplifié mais reconnaissable : une entreprise vend du mobilier de bureau. Le commercial cherche des produits dans le catalogue, les ajoute à la commande, choisit l'entreprise et le contact, saisit la remise. L'application doit :

• prendre les prix à jour dans le catalogue CRM, et non dans des constantes du code ;
• calculer le montant selon des règles uniques ;
• plafonner la remise : jusqu'à 100 000 ₽, 5 % maximum ; de 100 000 à 300 000 ₽, 10 % ; à partir de 300 000 ₽, 15 % ;
• créer l'affaire et le devis directement dans Bitrix24.

Nuance importante : le seuil est déterminé par le montant de la commande avant remise. Si le commercial saisit une valeur excessive, l'application ne la réduit pas en silence : elle refuse et explique quel pourcentage est autorisé.

On a utilisé l'agent Bitrix24 Cowork/Code. Il a deux modes : « Cowork » pour travailler avec les données métier du portail et « Code » pour le développement. Dans le premier, l'agent a créé une section de catalogue de test avec six produits, trois entreprises et les contacts qui leur sont rattachés. Dans le second, il a construit l'application elle-même et l'a déployée sur la plateforme Bitrix24 Vibecode.

Comment le prompt est construit

La partie la plus utile du texte n'est pas le calculateur lui-même, mais la structure de la requête. L'auteur n'a pas rédigé le prompt à la main : il a d'abord demandé à l'agent de formuler un cahier des charges précis, puis a fait relire le rapport par ChatGPT, l'a corrigé plusieurs fois et l'a remis à l'agent. Cela économise aussi des tokens.

Le cahier des charges intègre des décisions que l'on oublie généralement de décrire :

• Le serveur est la source de vérité. Le montant envoyé par le client n'est pas accepté. Avant de créer l'affaire, le serveur relit les prix du catalogue et recalcule la limite. Falsifier les données dans le navigateur ne sert à rien.
• L'identité vient de la passerelle. Le responsable de l'affaire est l'employé connecté. Son ID provient de l'en-tête de la passerelle, et non du corps de la requête.
• Accès par service. Un employé hors du service autorisé reçoit un refus clair, et non un écran vide. Les actions dans le CRM s'exécutent avec ses droits, et non au nom de l'administrateur.
• Idempotence. La clé de commande est créée une seule fois par calcul. Un second clic renvoie l'affaire déjà créée, un doublon parallèle reçoit un 409.
• Limites strictes. Pas plus de 50 lignes, quantité de 1 à 999, remise de 0 à 50, aucun proxy universel vers le portail.
• Une liste de « ce qu'il ne faut pas faire ». Validations, TVA, marge et journal d'audit sont reportés à la version suivante. Cela évite que la tâche ne s'étende.

À noter aussi l'ordre de travail : d'abord les tests sur la partie financière (bornes 99 999,99 / 100 000 / 299 999,99 / 300 000), puis le serveur, puis l'interface, le contrôle de sécurité et la publication. L'agent ne crée l'affaire de test qu'après confirmation d'un humain.

Limites et ce qu'il faut en retenir

D'abord, les réserves. Il s'agit d'un texte issu de la série de l'équipe DevRel de Bitrix24 elle-même, qui présente donc l'outil du fournisseur sous un jour favorable. Le cas est un modèle : un catalogue de six produits et une seule règle de remise ne valent pas un vrai tarif de centaines de références avec des exceptions. Dans la partie accessible du texte, il n'y a pas de chiffres finaux sur le temps ni sur le nombre d'itérations, on ne peut donc pas évaluer l'économie. Restent aussi les questions que l'auteur soulève lui-même : est-il sûr de confier des calculs à une application écrite par une IA, et qui la maintiendra ?

La conclusion pratique pour le développeur et le product manager dépasse Bitrix24. Si vous confiez un outil interne à un agent IA, ce n'est pas le modèle qui détermine la qualité du résultat, mais le cahier des charges. Décrivez où réside la vérité (le serveur), ce qu'il est interdit d'accepter du client, comment se protéger des doublons et ce qui ne fait explicitement pas partie de la version. Vérifiez l'argent et les droits par des tests aux bornes des valeurs. Et ne créez pas d'entités de production dans le CRM sans confirmation humaine : l'auteur a aussi inscrit ce point dans le cahier des charges.