Laissez l’IA lire la demande. Confiez le calcul aux règles validées.

Imaginons ce message d’un client : « Deux cartons sont arrivés abîmés. Pouvez-vous nous faire un avoir en conservant la remise convenue le mois dernier ? »

Une personne en comptabilité doit identifier la commande, vérifier les dommages et retrouver l’accord. Vient ensuite le calcul. L’avoir doit aussi être validé par quelqu’un qui a l’autorité nécessaire.

Ce sont des tâches différentes. Les réunir dans un seul prompt rend plus difficile la localisation d’une erreur.

Une conception plus utile rend chaque étape visible. L’IA aide à interpréter le message. Les documents vérifiés fournissent les faits. Des règles de calcul approuvées produisent le montant. Une personne valide l’avoir avant son émission.

Transformer le message en demande vérifiable

L’assistant peut extraire le client, la référence de facture, la quantité réclamée et le motif de l’avoir. Gardez le message original à côté de ces champs pour que la personne chargée du contrôle puisse vérifier les interprétations.

« Deux cartons » reste ambigu si la commande est enregistrée en unités. Il faut connaître le conditionnement de cette livraison. Le système ne doit pas reprendre la conversion d’un autre produit au motif que les descriptions se ressemblent.

Même problème avec « la remise convenue ». Cette phrase rapporte une affirmation du client. Retrouvez l’accord et vérifiez son périmètre avant de l’appliquer. Une remise accordée sur une autre commande ne couvre pas nécessairement celle-ci.

Une information absente ou contradictoire doit laisser la demande en attente. Un formulaire rempli avec des valeurs supposées donne à l’étape suivante une certitude injustifiée.

Calculer à partir de données vérifiées

Lorsque les quantités et les conditions applicables sont confirmées, transmettez-les à une fonction de calcul. Elle doit appliquer les règles approuvées pour cette transaction, notamment les arrondis et l’ordre des remises ou autres ajustements.

Pour un exemple illustratif, prenons une quantité confirmée de 20 unités à créditer, un prix unitaire de 15 € et une remise applicable de 10 %. Avant taxes ou autres ajustements, le montant est :

20 × 15 € × 0,90 = 270 €.

Ces chiffres sont hypothétiques. L’intérêt est de pouvoir reproduire le calcul à partir de données identifiées et d’une version connue des règles.

Conservez le lien entre le résultat et ces données. Si quelqu’un modifie la quantité ou l’accord, recalculez et montrez le changement. Ne demandez pas au modèle de langage d’inventer la politique manquante.

Un calcul déterministe peut néanmoins être faux. Il peut utiliser un prix erroné, une règle périmée ou contenir un défaut logiciel. Testez les résultats attendus avec la comptabilité, y compris les cas limites, et conservez la version utilisée pour chaque décision.

Placer la validation avant l’action

La personne qui valide doit voir ensemble la demande initiale, les faits vérifiés et le calcul, avec les points non résolus apparents. Elle ne devrait pas avoir à reconstituer toute la chaîne dans un autre tableur.

La validation doit porter sur le montant et la version à émettre. Si l’un change, l’accord précédent ne doit plus autoriser la transaction. Après transmission de l’avoir approuvé au logiciel financier, vérifiez l’enregistrement obtenu avant d’annoncer que l’opération est terminée.

Prévoyez aussi le cas d’un délai de réponse dépassé. Une requête restée sans réponse ne prouve pas qu’aucun avoir n’a été créé. Recherchez le résultat à partir d’une référence stable avant de réessayer, pour éviter une double émission.

Demander une démonstration avec des cas difficiles

Avant d’accepter une solution, testez une demande dont l’unité est ambiguë, une remise expirée et une facture déjà associée à un avoir. Utilisez un environnement sans conséquence réelle et convenez d’abord du résultat attendu pour chaque cas.

Vous devez pouvoir voir où le traitement s’arrête et pourquoi. Rejouez aussi les mêmes données vérifiées avec la même version du calcul. Le résultat doit être identique ; ce contrôle seul ne prouve pas que la règle appliquée est correcte.

Solve IT construit ces connexions autour des systèmes existants, avec les contrôles et les autorisations convenus pour le processus. Un premier périmètre utile peut s’arrêter à un brouillon vérifié, en laissant l’émission dans l’application habituelle de la comptabilité tant que la suite n’a pas été testée.

Demandez une Strategy Session avec la personne qui traite les avoirs. Apportez une demande où « la remise habituelle » a nécessité un appel.