Pourquoi un devis met trois jours
Le temps de chiffrage lui-même est rarement le problème. Ce qui prend du temps, c’est tout ce qui l’entoure.
Retrouver un devis similaire. Il existe, il est dans un dossier, mais lequel ? On se souvient d’un chantier comparable il y a huit mois, sans se rappeler le nom du client.
Vérifier que les prix sont à jour. La dernière hausse fournisseur a-t-elle été répercutée ? Sur quelles lignes ?
Remettre en forme. Reprendre l’ancien devis, changer le client, changer les lignes, vérifier qu’aucune trace du précédent ne subsiste.
Trouver le moment. C’est souvent le facteur dominant : le devis se prépare le soir ou le week-end, parce que la journée est prise par la production. Un devis n’attend pas trois jours par difficulté, il attend trois jours par manque de plage disponible.
Ce dernier point explique pourquoi l’automatisation change réellement les choses ici. En ramenant la préparation à vingt minutes, elle la fait rentrer dans une journée normale.
Ce qu’on automatise
La bibliothèque de prestations. Libellés, unités, prix unitaires, temps de pose, coefficients, variantes. Constituée à partir de vos devis passés puis validée par vous.
La lecture de la demande. Extraction de ce qui est demandé, des quantités et des contraintes, à partir d’un message, d’un formulaire ou d’un compte rendu de visite.
La recherche de précédents. Les devis déjà réalisés les plus proches, avec ce qui a été retenu et ce qui ne l’a pas été.
La proposition de chiffrage. Lignes, quantités, prix, avec pour chacune la justification : d’où vient cette ligne, d’où vient cette quantité.
Les contrôles. Marge par ligne et globale, prix inférieur au coût de revient, oubli d’un poste habituellement associé — un poste qui accompagne la prestation dans quatre-vingts pour cent des devis passés et qui manque ici est signalé.
La mise en forme. Votre modèle, vos conditions générales, votre numérotation.
La suite. Envoi à signature, relances, transformation en commande.
Comment ça marche techniquement — pour qui veut le détail
La constitution de la bibliothèque. Extraction des lignes des devis passés — PDF texte lus avec pdfplumber, PDF scannés via Tesseract, tableurs lus directement. Puis regroupement des libellés désignant la même prestation : normalisation, puis classification non supervisée sur des plongements vectoriels de phrases. Un modèle d’embedding multilingue exécuté en local — famille E5 ou BGE via sentence-transformers — suffit largement et ne fait rien sortir. Les groupes obtenus sont présentés pour validation humaine : c’est la seule étape qui demande du temps, et elle est décisive.
La recherche de précédents. Recherche hybride, parce qu’aucune des deux approches ne suffit seule. Lexicale avec tsvector et la configuration française de PostgreSQL, qui excelle sur les références exactes et le vocabulaire métier précis. Vectorielle avec pgvector et un index HNSW, qui retrouve les formulations différentes du même besoin. Les deux classements sont fusionnés par Reciprocal Rank Fusion, méthode simple et robuste qui ne demande aucun réglage délicat.
Le RAG, correctement fait. Le modèle ne reçoit pas votre base : il reçoit les dix à vingt lignes de bibliothèque et les deux ou trois devis passés que la recherche a remontés, et il doit proposer un chiffrage en choisissant parmi ces lignes, par identifiant. Sa sortie est un tableau d’identifiants et de quantités, validé par schéma. Un identifiant qui n’existe pas dans le contexte fourni est rejeté avant tout affichage. C’est ce qui rend l’hallucination de prix structurellement impossible plutôt que simplement improbable.
Les quantités. Elles viennent de la demande quand elles y figurent — surfaces, linéaires, effectifs, extraits par motifs et confirmés par le modèle — et sinon restent à saisir. Une quantité inventée est aussi dangereuse qu’un prix inventé, et le système préfère un champ vide et visible.
La détection d’oubli. Analyse d’association sur vos devis passés : quelles lignes apparaissent ensemble, et à quelle fréquence. Une règle du type « quand la ligne A figure, la ligne B figure dans quatre-vingt-trois pour cent des cas » se calcule en SQL sur quelques centaines de devis. Appliquée au devis en cours, elle produit un signalement d’oubli probable — c’est l’une des fonctions les plus rentables du système, et elle ne demande aucun modèle.
Le contrôle de marge. Chaque ligne de bibliothèque porte un coût de revient en plus de son prix de vente. Le devis affiche la marge par ligne et globale, et bloque sur une ligne vendue en dessous du coût sans validation explicite. L’historique des coûts est daté : un devis chiffré il y a six mois ne se rejoue pas avec les coûts d’aujourd’hui.
La versionner. Un devis modifié produit une nouvelle version, l’ancienne reste consultable, et le lien entre les deux est explicite. Savoir quelle version a été envoyée et laquelle a été signée est le genre de question qui arrive toujours au mauvais moment.
La production du document. Même chaîne que pour tout document contractuel : modèle .docx ou gabarit HTML, données validées par schéma, rendu en PDF, empreinte SHA-256 stockée avec la version du modèle utilisée.
La mise à jour des prix. Les hausses fournisseurs se propagent à la bibliothèque par un flux d’import séparé, avec historisation : chaque prix a une période de validité. Un devis conserve les prix en vigueur au moment de son émission, ce qui est indispensable pour l’honorer et pour comprendre, plus tard, une marge qui semble anormale.