Des devis de rénovation générés par IA : la partie difficile n'était pas l'IA

Un devis de rénovation sérieux, en Suisse romande, c'est des heures de travail : relire la demande, analyser les photos, choisir les prestations, calculer les quantités, appliquer les bons tarifs, rédiger proprement, mettre en page. Une plateforme que nous avons construite — un SaaS de devis de rénovation pour le marché romand, dont nous tairons le nom — fait ce travail en quelques minutes, de bout en bout.

Et pourtant, elle n'est pas encore lancée commercialement. Depuis plusieurs mois, elle est entre les mains de son client zéro, en phase pilote. Ce décalage n'est ni un échec ni un secret : c'est la partie du projet la moins spectaculaire et la plus instructive. Cet article raconte les deux — ce que l'IA a fait à une vitesse déconcertante, et ce qu'aucune IA ne fera à notre place.

Ce que l'IA a fait vite

Deux choses, et la seconde surprend plus que la première.

La première : le logiciel. Un pipeline de huit agents spécialisés — qualification de la demande, profil du client, analyse des photos, résolution des matériaux, calcul, rédaction, contrôle qualité, génération du document final en PDF et Word. Il fonctionne aujourd'hui, de la demande libre du client jusqu'au document mis en page.

La seconde : les données de départ. Le catalogue d'environ 140 codes de prestations, les matériaux, les recettes qui les relient — ce socle a été construit avec l'aide de l'IA en quelques jours, là où le constituer à la main aurait pris des semaines. C'est un catalogue plausible, cohérent, complet.

C'est aussi, précisément, là que commence la vraie histoire : plausible n'est pas vrai. Nous y revenons plus bas — d'abord, voyons comment le système est construit, parce que ces choix d'architecture sont la condition de tout le reste.

La règle numéro un : le modèle ne fixe jamais les prix

La décision structurante du projet tient en une phrase : le modèle de langage décrit, un moteur déterministe calcule.

Le pipeline sépare strictement deux familles de composants. D'un côté, les agents « créatifs » — ceux qui interprètent la demande, analysent les photos, adaptent le ton, rédigent les textes du devis. Ce sont eux qui utilisent un grand modèle de langage (LLM). De l'autre, le moteur de prix : du code classique, documenté comme « 100 % reproductible : même entrée → toujours même sortie », qui travaille en arithmétique décimale avec des règles d'arrondi explicites.

Concrètement, le prix de vente part d'un prix de marché par prestation et lui applique des multiplicateurs configurés en base de données : segment de clientèle, état de la surface, accessibilité du chantier, urgence, ajustement régional par canton, taille du projet. En parallèle, un calcul de coût de revient (matériaux, heures de travail, frais généraux, contingence) produit la marge réelle de chaque devis, avec des seuils d'alerte qui signalent une marge critique avant l'envoi. Trois scénarios de prix — bas, moyen, haut — sortent de ce moteur.

Et le modèle dans tout ça ? Il a voix au chapitre, pas le dernier mot : un agent « conseiller de prix » recommande un des trois scénarios par ligne, avec sa justification et son niveau de confiance. La recommandation est affichée à l'humain. Le montant, lui, vient toujours du moteur.

Le format suisse n'est pas un détail : montants en CHF 8'450.00, dates au format DD.MM.YYYY, TVA à 8,1 %, vouvoiement systématique. Tout cela vit dans des prompts versionnés — nous y revenons.

Des garde-fous, pas de la confiance

Un LLM en production ment rarement par malice, mais il improvise volontiers. Le système part du principe que chaque sortie du modèle est suspecte jusqu'à preuve du contraire :

• La qualification est bornée par le catalogue. L'agent qui transforme la demande libre du client en lignes de devis ne peut choisir que parmi les codes de prestations existants. Sa sortie passe une validation déterministe : un code qui n'existe pas est rejeté — c'est notre anti-hallucination —, une quantité nulle ou négative est corrigée automatiquement, un doublon est fusionné.
• La réparation est bornée aussi. Si la validation échoue sur des erreurs non corrigeables mécaniquement, le modèle a droit à un appel de réparation. Un seul. Si la réparation n'améliore pas les choses, on garde la version auto-corrigée. Pas de boucle infinie qui brûle des tokens.
• Le parseur ne fait pas confiance au format. Les modèles renvoient du JSON… la plupart du temps. Le parseur tolère les enrobages markdown, extrait le bloc utile, puis valide la structure avec des schémas stricts. Une réponse tronquée (limite de tokens atteinte) est détectée et déclenche des valeurs par défaut prudentes plutôt qu'un parsing hasardeux.
• La panne est un cas nominal. Nouvelles tentatives avec recul exponentiel, disjoncteur par modèle (cinq échecs consécutifs ouvrent le circuit pendant cinq minutes), respect des consignes de limitation du fournisseur. Chaque invocation — réussie ou non — est persistée et auditée, avec une détection d'anomalie de coût qui alerte à 2× la moyenne des 30 derniers jours et s'alarme à 5×.

Indépendant du modèle, par construction

Deuxième décision structurante : aucun agent n'est marié à un modèle. L'assignation agent → modèle vit en base de données, pas dans le code. La plateforme parle à trois fournisseurs de modèles interchangeables, et changer le modèle d'un agent est une opération de configuration, pas un déploiement.

Cette liberté sert d'abord l'économie du système : les tâches simples tournent sur des modèles économiques, la qualification complexe sur un modèle puissant — l'écart de prix entre les deux extrêmes de notre grille est de deux ordres de grandeur, le choisir par tâche n'est donc pas un raffinement, c'est le budget. Elle permet ensuite de comparer les fournisseurs en conditions réelles (tests A/B pondérés) au lieu de croire les benchmarks publics sur parole. Une leçon concrète au passage : les modèles de raisonnement les plus puissants peuvent dépasser la minute sur un prompt long ; nous avons découpé la qualification en deux phases plus courtes précisément pour ça.

Les prompts suivent la même discipline que le code : stockés en base, versionnés par migrations, avec cache et échec explicite si un prompt manque — jamais de valeur par défaut silencieuse. Le catalogue injecté dans le contexte est assaini et plafonné en taille, et les champs saisis par l'utilisateur passent par une détection de motifs d'injection avant d'atteindre le modèle.

L'humain aux deux endroits qui comptent

Le pipeline peut tourner en mode automatique de bout en bout. En phase pilote, il s'arrête par défaut à deux endroits :

1. Après le calcul : revue du prix. L'artisan voit les trois scénarios, la recommandation du conseiller et les alertes de marge — et tranche.
2. Après la rédaction : revue du contenu. Le texte est relu avant de devenir un document destiné à un client final.

Ce n'est pas de la défiance décorative. C'est un principe : l'IA prépare, le professionnel signe. Retenez-le — il est sur le point de changer d'échelle.

Le vrai goulot : rendre le catalogue vrai

Voici donc un système qui génère des devis complets, avec un catalogue que l'IA a construit en quelques jours. Pourquoi n'est-il pas lancé ?

Parce qu'un catalogue généré par IA est générique. Il dit qu'un mètre carré de peinture vaut tel prix, qu'une réfection de mur suit telle recette, qu'une heure de pose couvre telle surface. C'est plausible — c'est même du solide travail de synthèse. Mais un devis qui part chez un client final n'engage pas une moyenne du marché : il engage cet artisan-là, ses prix, ses fournisseurs, sa façon de travailler, ses marges. Chaque code de prestation, chaque recette, chaque taux de productivité doit être confronté à la réalité de l'entreprise — validé, ajusté ou remplacé.

Et cette validation, aucune IA ne peut la faire : la vérité terrain n'est écrite nulle part. Elle est dans la tête de l'expert métier. Or les heures de cet expert sont la ressource la plus rare du projet — son travail est sur les chantiers, pas dans un tableur. La curation avance donc au rythme que le métier lui laisse : par à-coups, depuis des mois. C'était prévisible, et c'est à nous de le planifier — pas à lui de s'en excuser.

Vous reconnaissez le motif : c'est le même principe que les deux revues du pipeline, à une échelle différente. Au runtime, l'IA prépare un devis et le professionnel le signe. Au niveau du projet, l'IA prépare un catalogue — et il attend la signature de l'expert pour devenir vrai. L'IA compresse la construction ; elle ne compresse pas la validation. Le chemin critique d'un projet d'IA d'entreprise n'est pas dans le code : il est dans les heures d'expertise nécessaires pour ancrer le système dans le réel.

Les chiffres

Ce qui se mesure	Valeur
Génération d'un devis complet (mesuré en pilote)	Quelques minutes, contre plusieurs heures à la main
Construction du catalogue initial avec l'IA	Quelques jours
Validation du catalogue par l'expert métier	En cours depuis plusieurs mois — le chemin critique
Agents spécialisés dans le pipeline	8
Codes de prestations au catalogue	~140
Appels de réparation autorisés par qualification	1
Disjoncteur par modèle	5 échecs → circuit ouvert 300 s
Alerte d'anomalie de coût LLM	2× la moyenne sur 30 jours (critique à 5×)
Tests automatisés côté backend	Plus de 2 600
Langues de l'interface	6

Ce que nous ferions autrement

La transparence est notre marque de fabrique, alors voici les cicatrices — en commençant par la plus importante :

• Traiter la validation experte comme un livrable contractuel, dès le premier jour. Nous avons planifié le développement avec soin et laissé la curation du catalogue en phase ouverte, comme si elle allait se faire toute seule. Elle est devenue le chemin critique. La prochaine fois : des heures d'expert engagées au contrat, des sessions de validation cadencées, et un produit qui rend cette validation aussi peu coûteuse que possible pour quelqu'un dont la journée se passe sur un chantier.
• Les paramètres métier étaient codés en dur. TVA, règles d'arrondi, seuils de marge vivaient dans le code du moteur de prix. Ils sont aujourd'hui configurables par locataire, mais la migration a coûté un chantier complet. Tout nombre qu'un client pourrait vouloir changer un jour naît en configuration, pas en constante.
• Le premier orchestrateur faisait trop de choses. Il exécutait la logique des agents au lieu de la déléguer. Nous l'avons refondu en chaînes de tâches asynchrones — c'est documenté dans une décision d'architecture — et le pipeline y a gagné la reprise sur erreur et les pauses de revue humaine.
• Les déconnexions client nous ont appris le streaming. Un client qui ferme son onglet pendant un flux d'événements peut, selon la pile HTTP, interrompre des opérations en cours et faire fuir des connexions à la base. Le correctif touche aux entrailles du framework — la leçon, elle, est simple : testez la déconnexion brutale du client aussi tôt que le chemin heureux.

Construire un produit d'IA qui prépare des documents commerciaux réels, en français, avec des montants en francs suisses, ne ressemble pas aux démos. Ce qui rendra ce système digne de confiance le jour du lancement, ce n'est pas le modèle : c'est la séparation des responsabilités, les validations, les bornes, l'audit — et les signatures humaines, du devis individuel jusqu'au catalogue entier. C'est exactement ce que nous construisons pour nos clients.