Une automatisation de devis commence par des règles de travail, pas par un outil. Si le prix dépend de paramètres que personne n’a clairement définis, un flux automatique peut seulement accélérer une erreur. L’objectif d’un premier pilote est de vérifier un processus limité et contrôlable.
Choisir un seul type de demande
Commencez par un produit et un cas répétitif : un panneau rectangulaire, un ensemble dans quelques finitions ou une prestation dont les options sont définies. Mettez de côté les formes et contraintes qui nécessitent une étude particulière.
Réunissez des exemples anonymisés. Repérez les paramètres qui reviennent, les questions manquantes et les exceptions. Le guide sur les demandes de produits sur mesure propose une méthode pour préparer ce travail.
Écrire la règle avant de construire le flux
Pour chaque donnée, précisez l’unité et les valeurs acceptées. Une largeur sans unité ne doit pas être interprétée au hasard. Un nom de finition peut correspondre à plusieurs traitements : il faut une table de référence approuvée.
Le calcul peut combiner surface, quantité, minimum de fabrication et suppléments. Les arrondis, seuils et frais de livraison doivent aussi être définis. Une personne valide ces règles avant leur intégration. Un modèle de langage n’a pas à inventer un tarif lorsqu’une donnée manque.
Séparer l’IA du calcul
L’IA peut aider à extraire les dimensions ou à classer un message. Une vérification contrôle ensuite que les champs nécessaires sont présents. Le calculateur applique des règles déterministes : mêmes données et mêmes règles, même résultat.
- Réception d’une demande dans le périmètre convenu.
- Organisation des informations et identification des incertitudes.
- Vérification des champs et des limites.
- Calcul si les données sont suffisantes.
- Préparation d’un brouillon pour validation humaine.
Si le cas sort du périmètre, le flux le signale. Il ne remplace pas une décision de fabrication. La démo à scénarios prédéfinis illustre cette logique sans analyser librement des messages ni envoyer d’e-mail.
Tester les cas difficiles
Un pilote doit être testé avec des informations manquantes, des unités différentes, une quantité inhabituelle, des valeurs hors limites et un texte ambigu. Vérifiez également ce qui se passe après un échec technique ou une demande déjà traitée.
Conservez les données et la version des règles utilisées pour pouvoir comprendre une estimation. Faites valider les résultats attendus sur des exemples avant de comparer le résultat automatique. Un test réussi sur une seule demande complète ne suffit pas.
Mesurer sans promettre
Avant le pilote, estimez le temps de lecture, le nombre de relances et le temps de préparation de la réponse. Après le test, comparez des cas similaires. Comptez aussi le temps de contrôle et de correction. Le bénéfice n’est pas acquis à l’avance.
Au départ, la réponse reste un brouillon. Aucune proposition commerciale n’est envoyée automatiquement. Cette étape permet de repérer les erreurs avant qu’elles atteignent un client.
Choisir l’outil et le périmètre des données
Un outil comme n8n peut être hébergé sur une infrastructure maîtrisée. Cela permet de choisir le stockage et les accès. Si le processus utilise un service d’IA externe, certaines données peuvent toutefois lui être transmises : il faut identifier ces échanges et limiter les informations utilisées.
Je construis et teste cette approche dans CopperAndCraft. L’offre Automatisations commence par un audit d’un processus ou un pilote de devis. Nous pouvons travailler sur vos exemples anonymisés ou une simulation. Le périmètre, les règles et les critères d’acceptation sont convenus avant le démarrage.