Créer des devis avec l’IA : d’où viennent les prix ?

La demande paraît simple : repeindre deux pièces, avec quelques photos et une date souhaitée. Une IA peut rédiger une offre convaincante à partir de ces éléments. Il manque pourtant la surface, l’état des murs et la question du déplacement des meubles. Ce sont ces détails qui déterminent le travail à chiffrer. Une préparation fiable les garde visibles au lieu de les remplacer par des hypothèses discrètes.

Pour une PME, automatiser les offres peut commencer très modestement : classer les informations reçues, proposer des prestations connues, reprendre les prix autorisés et préparer un document facile à vérifier. L’équipe évite les recherches répétitives. Elle conserve les décisions commerciales et techniques. Demander un montant vraisemblable à un modèle de langage produit parfois un joli courrier, mais aucune base sérieuse pour engager votre entreprise.

Commencer par une prestation que vous savez déjà chiffrer

Choisissez une famille de travaux récurrents dont les composants sont bien décrits. Un entretien défini ou une pose standard se prête mieux au premier essai qu’une rénovation estimée sur deux photos sombres. Vous devez pouvoir relier la prestation demandée à une quantité et aux conditions du prix. La fluidité du texte ne crée pas ce lien.

Prenez quelques offres terminées et surlignez les décisions qui exigeaient un spécialiste. Fallait-il mesurer sur place ? L’accès imposait-il un équipement particulier ? Le client bénéficiait-il de conditions négociées ? Quand presque chaque ligne dépend d’une réponse encore inconnue, la première aide utile consiste à préparer les bonnes questions. Le document commercial complet peut attendre que les informations nécessaires soient disponibles.

Regardez aussi ce que votre logiciel sait déjà organiser. La documentation bexio sur les types de positions distingue notamment les positions libres et celles liées au catalogue de produits. Cette structure peut servir de base. Elle ne prouve pas que votre compte possède une intégration IA prête à fonctionner. Vérifiez l’édition utilisée, les interfaces disponibles et les droits nécessaires avant de promettre un raccordement.

Définir les informations obligatoires de chaque ligne

Le responsable des offres devrait pouvoir comprendre les règles sans lire de code. Écrivez une petite fiche décrivant ce qui doit être connu pour qu’une position figure dans une version envoyable. Notre point de départ recommandé comprend les éléments suivants :

• Une référence de prestation et un descriptif approuvé.
• Une quantité, son unité et l’origine de cette quantité.
• La source du prix, sa version et sa période d’application.
• Les suppléments, rabais et conditions particulières autorisés.
• Les travaux inclus, les exclusions et les prérequis encore ouverts.
• La personne habilitée à décider lorsqu’un cas sort du cadre.

L’origine de la donnée change son poids. Une mesure confirmée sur place ne vaut pas une estimation du client ni une quantité récupérée dans une ancienne offre. Gardez cette différence dans l’espace de contrôle. Une valeur ne doit pas devenir « confirmée » simplement parce que le système a réussi à remplir une case qui attendait un nombre.

Prévoyez également une vérification des unités. Douze mètres carrés de mur et douze mètres de plinthe peuvent apparaître dans la même demande. Le calcul doit appliquer une règle explicite à chaque prestation. Le modèle peut aider à comprendre la phrase ; les conversions permises doivent être déterminées à part. Une addition exacte avec des unités mal choisies reste une offre incorrecte.

Un exemple de calcul qu’on peut reprendre à la main

Voici un cas d’entretien entièrement inventé, destiné uniquement à expliquer le contrôle. Ces montants ne sont ni des tarifs AlpenAgent ni des prix moyens du marché : trois heures de travail à CHF 95, deux unités de matériel à CHF 42 et un forfait de déplacement de CHF 35. Le sous-total atteint CHF 404 hors taxes. Votre logique comptable doit ensuite appliquer le traitement fiscal et l’arrondi correspondant au cas réel.

Supposons qu’un rabais approuvé de dix pour cent concerne seulement le travail. Il retire CHF 28.50 ; le nouveau sous-total est de CHF 375.50. Un rabais sur l’ensemble du document produirait un autre résultat. Faites apparaître sa base de calcul. Une phrase annonçant que « votre rabais fidélité a été pris en compte » ne permet pas au responsable de comprendre ce qui a réellement changé.

Retirons maintenant la quantité confirmée de matériel. Le système devrait ouvrir une question ou présenter une hypothèse expressément soumise à validation. Reprendre deux unités parce que le dernier chantier en utilisait deux serait trompeur. Inscrire zéro donnerait aussi un faux sentiment de complétude. Cette variation fournit un bon test : le processus doit reconnaître quand les informations ne suffisent pas pour établir le montant.

Attribuer un responsable aux prix

Décidez où se trouve la source commerciale de référence. Cela peut être votre ERP, un catalogue entretenu ou un tableau contrôlé pour un essai limité. Les anciens PDF peuvent aider à retrouver une formulation. Ils constituent une mauvaise liste de prix courants : l’offre précédente pouvait inclure une remise exceptionnelle, un périmètre différent ou un coût d’achat devenu obsolète.

Chaque nouvelle version des prix demande une date d’application et une règle pour les brouillons en cours. Faut-il recalculer une offre non validée juste avant son envoi ? Une promesse de prix reste-t-elle valable ? Qui peut déroger aux conditions habituelles ? Ces questions relèvent de votre gestion commerciale. Un modèle ne devrait pas les trancher à partir d’un message disant « comme la dernière fois ».

Affichez la version des prix dans l’espace interne de vérification. Un exemple logiciel concret figure dans le guide bexio pour créer une offre depuis un projet : des temps estimés et un tarif configuré peuvent alimenter les positions. Il reste à vérifier si ces informations sont correctement tenues chez vous. L’existence d’un champ ne garantit pas la qualité de son contenu.

Faire porter la validation sur la bonne version

Une personne approuve le document, puis une quantité est modifiée ou un nouveau prix de matériel est importé. Lorsque cette modification touche le contenu approuvé, la nouvelle version doit repasser par la vérification prévue. Autrement, une autorisation donnée pour un document sert à en envoyer un autre. Un courriel contenant simplement « validé » protège mal contre cette confusion.

Reliez la décision à un identifiant et à une version. Le destinataire, les prestations, le total, les inconnues et les principales conditions doivent être visibles ensemble. Le bouton de validation mérite un écran compréhensible. Perdu au milieu de messages techniques, il devient facilement une formalité. Les corrections et le motif d’une exception doivent rester consultables par la personne qui engage l’entreprise.

Le mécanisme général est décrit dans notre article sur le brouillon, la validation et l’exécution. Pour une offre, il faut préciser les pouvoirs commerciaux : qui peut accorder un rabais, confirmer un délai ou modifier une exclusion ? Une consigne vague indiquant qu’un humain contrôle à la fin ne définit aucun de ces droits.

Préparer des demandes qui devraient poser problème

Une demande complète permet de vérifier le parcours normal. Ajoutez volontairement des cas incomplets : quantité absente, dimensions contradictoires, tarif périmé, rabais non autorisé et prestation inconnue. Testez aussi une mauvaise attribution au client et une position modifiée après validation. Notez le comportement attendu avant de lancer l’essai. La production d’un PDF ne constitue pas à elle seule un résultat acceptable.

Présentez deux fois la même demande. Une nouvelle livraison technique du formulaire ne devrait pas créer deux offres et deux envois. Une référence stable du dossier permet de reconnaître l’opération. Après une réponse technique incertaine, consultez l’état du logiciel cible avant de relancer. Notre article sur la prévention des actions en double explique cette logique.

Faites examiner les résultats par la personne qui chiffre habituellement les travaux. La prestation proposée est-elle juste ? Les mesures manquantes sautent-elles aux yeux ? Peut-on retrouver le prix et retirer une ligne inadaptée rapidement ? Mesurez le temps total, contrôle et corrections compris. Un brouillon instantané peut coûter cher si chaque ligne exige ensuite une enquête pour être digne de confiance.

Organiser un essai qui reste utile après la démonstration

Limitez le premier essai à une famille de prestations, une source de prix et un responsable de validation. Les brouillons accompagnent votre méthode actuelle. L’envoi passe par le circuit contrôlé convenu, et le traitement manuel reste disponible pour les exceptions. Vous pourrez améliorer la correspondance entre demandes et prestations sans exposer le client à un document non vérifié.

Consignez les changements de descriptifs, de tarifs et d’informations demandées pendant l’essai. Vous pourrez ainsi distinguer l’effet d’un autre modèle de celui d’un catalogue mieux rangé. Désignez aussi la personne qui tiendra les prix à jour ensuite. Une base abandonnée se dégrade à chaque modification des achats ou du contenu d’une prestation, même si le texte généré reste très propre.

Après l’envoi, les rappels et les échanges avec le client appartiennent à un autre fonctionnement, traité dans notre article sur le suivi des offres ouvertes. Ici, l’essai doit répondre à une question précise : vos vraies demandes produisent-elles un brouillon commercial contrôlable avec moins de travail global ? Pour discuter de l’automatisation de vos processus, apportez des exemples anonymisés et votre structure de prix. Les dossiers qui obligent encore à téléphoner sont souvent les plus instructifs.