Génération propales par IA : RAG sur corpus gagnantes

"On met trois heures à rédiger une propale, et la moitié c'est du copier-coller de ce qu'on a déjà fait." C'est le verbatim le plus fréquent que nous entendons chez les directeurs commerciaux de PME et d'ETI. Trente propales par mois, trois commerciaux, et la sensation de réinventer la même roue à chaque nouveau brief client.

La réponse technique à ce problème n'est pas un outil SaaS de génération de texte. C'est un système RAG construit sur votre corpus de propales commerciales gagnées : vos meilleurs arguments, votre style, votre catalogue de prix réels, injectés dans un pipeline de génération qui produit un premier jet structuré en moins de dix minutes. Chez Tensoria, nous avons déployé cette architecture pour des ESN, des cabinets de conseil et des PME industrielles. Cet article documente exactement comment ça fonctionne, et où les pièges se cachent.

Une mise en garde préalable : une propale contient des engagements contractuels. Prix, délais, livrables, conditions de paiement. Aucune automatisation ne justifie d'envoyer un document généré sans validation humaine. Ce système est un accélérateur de rédaction, pas un rédacteur autonome.

Pourquoi rédiger une propale est non trivial

Un email de prospection tient en 150 mots. Un devis est un tableau de lignes et de prix. Une proposition commerciale est un document de persuasion structuré : elle doit démontrer que vous avez compris le problème du client, que votre approche est la bonne, que votre équipe est crédible, et que le prix est justifié par la valeur délivrée. C'est une pièce de rhétorique autant qu'un document contractuel.

C'est ce qui rend sa génération automatique difficile. Un LLM sans contexte produit du texte générique qui pourrait venir de n'importe quelle agence ou ESN. Le client le sent immédiatement. La propale ne ressemble pas à l'entreprise, elle ne reprend pas les termes du brief, elle ne valorise pas les bons arguments au bon endroit.

Le problème n'est pas le LLM : c'est l'absence de contexte pertinent. La solution n'est pas un meilleur prompt : c'est un corpus de vos propales gagnées, interrogé de manière sémantique pour injecter ce qui a fonctionné dans le passé.

Architecture RAG sur corpus de propales gagnées

Le système s'organise en cinq couches distinctes. Comprendre chaque couche avant de coder évite les erreurs d'architecture qui coûtent cher à corriger en cours de projet.

L'orchestration peut être assurée par Python pur (plus de contrôle, plus de code), par LangChain/LlamaIndex (boilerplate réduit, abstractions utiles), ou par n8n si votre équipe préfère un workflow visuel. Pour les équipes sans data engineer dédié, le choix n8n est pertinent. Notre article sur l'agent IA de réponse aux appels d'offres documente un workflow n8n comparable, applicable à ce cas d'usage en remplaçant le DCE par le brief commercial.

Ingestion et filtrage : won d'abord, pas tout le corpus

C'est la décision architecturale la plus importante, et la plus souvent ratée. La tentation naturelle est d'indexer toutes les propales disponibles pour maximiser la couverture. C'est une erreur.

Indexer les propales perdues introduit dans le corpus des arguments qui n'ont pas convaincu, des formulations qui n'ont pas résonné, des structures qui ont été rejetées. Le modèle va les retrouver et les reproduire. Le système amplifie alors vos échecs autant que vos succès.

La règle est simple : filtrer sur le statut CRM "won" (ou équivalent) avant toute ingestion. Dans HubSpot, c'est le champ deal.dealstage = "closedwon". Dans Salesforce, c'est Opportunity.StageName = "Closed Won". Dans Pipedrive, c'est le filtre sur les deals gagnés avec la date de clôture.

Après filtrage won, enrichir chaque document avec des métadonnées structurées stockées dans la base vectorielle :

• Secteur client (industrie, services, tech, santé...) — pour filtrer par secteur lors du retrieval
• Type de prestation (audit, développement, formation, conseil...) — pour cibler la section approche
• Taille du deal (tranche de montant) — pour calibrer le niveau de détail et le ton
• Date de la propale — pour déprioritiser les documents anciens dont les tarifs sont obsolètes
• Commercial rédacteur — utile si vous souhaitez générer dans le style d'un commercial spécifique

Ces métadonnées permettent des filtrages précis lors du retrieval : "remonte uniquement les propales gagnées dans le secteur industrie pour des missions de conseil opérationnel, depuis moins de 18 mois". Sans métadonnées, le retrieval est purement sémantique et peut remonter des documents inadaptés au contexte du brief en cours.

Embeddings et retrieval par similarité de brief

Une fois le corpus ingéré et segmenté par section (contexte client, approche, livrables, équipe, prix...), chaque chunk est transformé en vecteur dense par un modèle d'embeddings. Le choix du modèle influence directement la qualité du retrieval sur des textes commerciaux en français.

Nos tests sur des corpus de propales en français donnent les résultats suivants :

• text-embedding-3-large (OpenAI) : meilleure précision sur les textes longs et les nuances sémantiques. Recommandé si vous utilisez déjà l'API OpenAI en production.
• Mistral Embed : excellent sur le français, hébergement possible en Europe (conformité RGPD facilitée). Pertinent si vous souhaitez garder les données sur infrastructure française.
• Cohere Embed v3 : très performant avec le reranking natif Cohere, bonne cohérence retrieval + reranking dans la même API.

Le chunking doit respecter la structure sémantique des propales, pas une découpe mécanique par nombre de tokens. Une section "approche méthodologique" de 400 tokens doit rester en un seul chunk. Découper cette section au milieu d'un argument produit des vecteurs qui ne représentent rien de cohérent. Pour la sélection du modèle d'embeddings et du chunking adapté aux documents longs, notre guide sur l'architecture RAG complète couvre ces choix en détail.

Le retrieval s'effectue en deux temps :

1. Recherche vectorielle large (top-20) : le brief client est transformé en vecteur et comparé à l'ensemble du corpus. On remonte les 20 chunks les plus proches sémantiquement, sans filtres stricts.
2. Reranking + filtres métadonnées (top-5 à top-8) : un modèle de reranking (Cohere Rerank ou cross-encoder) réévalue la pertinence de chaque chunk par rapport à la requête réelle, en tenant compte des métadonnées (secteur, type de prestation). On conserve les 5 à 8 meilleurs.

Ce double passage retrieval + reranking est ce qui fait la différence entre un système qui remonte "quelque chose de proche" et un système qui remonte "exactement ce dont on a besoin". Le reranking seul, sans retrieval vectoriel large en amont, est trop lent sur de gros corpus.

Template fixe ou génération libre

C'est un choix structurant qui engage l'architecture entière. La génération libre laisse le LLM décider de la structure du document. Le template fixe contraint le LLM à remplir des zones prédéfinies dans un DOCX maison.

Dans le contexte d'une propale commerciale, le template fixe est presque toujours le bon choix. Voici pourquoi :

• Cohérence de marque garantie : couverture, logo, polices, couleurs, numérotation des sections restent identiques d'une propale à l'autre. Le LLM ne "dessine" pas, il remplit des zones de texte délimitées.
• Sections fixes non générées : la page de garde, les CGV, les mentions légales, la signature ne passent jamais par le LLM. Elles sont copiées telles quelles depuis le template.
• Sections variables générées section par section : le LLM reçoit un prompt spécifique pour chaque section (contexte client, compréhension du besoin, approche proposée, livrables, planning, équipe, prix, conditions). Chaque appel LLM est court et ciblé, ce qui améliore la qualité et réduit les coûts.
• Traçabilité : chaque section générée peut être auditée indépendamment. Si la section "approche" est mauvaise, on sait exactement quel prompt a produit quel résultat.

La génération libre n'est utile que si vos propales ont des structures très variables selon le type de client ou de mission. Dans ce cas, une variante est de disposer de plusieurs templates (un par type de prestation) et de sélectionner automatiquement le bon template en fonction des métadonnées du brief.

Préservation de la voix de marque

C'est le piège numéro un des propales générées. Un LLM sans calibration de style produit un texte qui "sonne IA" : phrases longues, constructions passives, formules de politesse génériques, arguments en bullet points sans fil directeur. Le client reçoit une propale qui ne ressemble pas à l'entreprise avec laquelle il a eu des échanges.

Deux approches existent pour calibrer le style :

Fine-tuning vs prompt engineering : quel choix ?

Le fine-tuning sur un corpus de propales de votre entreprise est théoriquement la solution la plus puissante. En pratique, il présente trois obstacles sur ce cas d'usage :

• Il nécessite un corpus d'au moins 100 à 200 exemples (paires instruction/réponse) pour produire un résultat stable.
• Il coûte entre 2 000 et 8 000 euros de compute selon le modèle et la taille du corpus.
• Il se dégrade dans le temps si le style de l'entreprise évolue, et doit être réentraîné périodiquement.

Pour la majorité des PME avec 30 à 100 propales gagnées, le few-shot dans le prompt système est nettement plus efficace et moins coûteux. La méthode concrète :

1. Sélectionner 5 à 10 paragraphes emblématiques de vos meilleures propales gagnées, représentatifs de votre style rédactionnel.
2. Les inclure dans le prompt système sous la forme "Voici des exemples du style de rédaction attendu" — sans les baliser comme exemples à copier mot pour mot, mais comme références de ton et de densité argumentaire.
3. Ajouter des instructions négatives précises : ce que vous ne voulez pas ("ne jamais ouvrir une section par 'Dans un contexte où...'", "éviter les énumérations sans phrase de synthèse").
4. Tester sur 10 propales réelles en comparant avec des propales humaines de même type.

Cette technique donne des résultats mesurables en quelques jours. Elle est aussi beaucoup plus facile à mettre à jour : si votre style évolue, vous changez les exemples, pas le modèle.

Grounding sur la base produits et prix

La section prix est celle qui engage le plus directement votre entreprise. C'est aussi celle où le risque d'hallucination est le plus élevé : un LLM peut interpoler des montants vraisemblables à partir du contexte sans qu'ils correspondent à votre catalogue réel.

La règle est non négociable : le modèle ne génère jamais un tarif. Il l'injecte depuis votre catalogue services.

En pratique, le catalogue services est un fichier structuré (Google Sheet, base SQL, ou Notion database) contenant :

• Prestation : nom exact, description courte, conditions d'application
• Tarif unitaire : jour/homme, forfait, abonnement mensuel
• Durée estimée : fourchette basse et haute selon la complexité
• Livrables inclus : liste exhaustive de ce qui est compris
• Date de dernière mise à jour : pour alerter si le catalogue est obsolète

Le pipeline récupère les lignes du catalogue correspondant aux prestations identifiées dans le brief, les injecte dans le prompt de la section prix, et le LLM rédige uniquement le texte d'habillage (présentation du montant, justification de la valeur) sans jamais générer les chiffres eux-mêmes.

Une vérification post-génération complète ce dispositif : un script extrait tous les montants présents dans le document généré et vérifie que chacun figure dans les inputs (catalogue ou brief). Tout montant non sourcé déclenche un flag avant la validation humaine. Cette vérification s'implémente en une vingtaine de lignes de Python.

Garde-fous obligatoires

Au-delà du grounding sur les prix, plusieurs garde-fous architecturaux doivent être présents dans tout déploiement de production.

Validation humaine systématique avant tout envoi externe

C'est une contrainte de conception, pas une étape optionnelle. Une propale contient des engagements contractuels : délais, livrables, prix, conditions de paiement. Aucun système IA ne devrait être en mesure d'envoyer un tel document sans validation explicite d'un signataire habilité.

Dans le workflow, cette contrainte se matérialise physiquement : le document généré est déposé dans un espace de travail (SharePoint, Notion, Google Drive) avec un statut "en attente de validation". L'envoi n'est possible qu'après approbation dans le CRM. Il n'existe pas de chemin technique permettant de contourner cette étape.

Signalement des sections à faible contexte RAG

Quand le retrieval ne trouve pas de passages suffisamment pertinents pour une section donnée, le document généré doit l'indiquer explicitement plutôt que d'halluciner un contenu vraisemblable. Un commentaire Word visible en rouge "section à compléter manuellement — aucun contexte pertinent trouvé dans le corpus" est plus utile qu'un paragraphe généré qui semble plausible mais ne correspond à rien.

Mémoire conversationnelle pour les itérations

Le commercial qui reçoit le premier jet doit pouvoir demander des ajustements en langage naturel : "allonge la section approche", "reformule le contexte en insistant sur notre expérience dans le secteur pharmaceutique", "adapte le planning en intégrant un jalon de revue à mi-parcours". Ces itérations nécessitent que le système conserve l'historique de conversation — pas un appel API stateless à chaque modification.

Corpus à jour obligatoire

Un corpus de propales gagnées qui ne s'actualise pas devient un handicap après 12 à 18 mois : les tarifs sont obsolètes, les prestations ont évolué, les arguments ne reflètent plus la posture commerciale actuelle. Prévoir une mise à jour trimestrielle du corpus (nouvelles propales gagnées, suppression des documents trop anciens) dès le design du système.

Intégrations CRM

L'intégration CRM est ce qui fait passer le système d'un outil annexe à un copilote commercial intégré dans le quotidien des équipes. Les trois CRM les plus fréquents en PME/ETI en France ont des approches d'intégration différentes.

HubSpot

HubSpot expose une API REST complète. Le déclencheur naturel est un webhook sur le changement de statut d'une deal (par exemple : deal passé en "proposition envoyée"). Le pipeline récupère automatiquement les données de la fiche entreprise, les contacts associés, l'historique des interactions et les notes commerciales. HubSpot Breeze (l'IA native) peut coexister avec le système RAG custom : Breeze pour les tâches légères (résumés d'emails, suggestions de relance), le RAG sur corpus pour la génération de propales. Les fonctionnalités IA HubSpot 2026 sont documentées sur le portail IA officiel HubSpot.

Salesforce

L'intégration Salesforce passe par les Flows ou par l'API Apex. Einstein GPT est la solution native de Salesforce pour la génération de contenu commercial. Sur les grands comptes déjà équipés Salesforce, Einstein couvre les besoins de base sans développement custom. Le RAG sur corpus propales gagnées prend tout son sens sur Salesforce quand Einstein produit du contenu trop générique et que l'équipe commerciale souhaite injecter son capital de propales historiques — ce qu'Einstein ne fait pas nativement.

Pipedrive

Pipedrive dispose d'une API REST et de webhooks natifs sur les événements de deals. L'intégration est plus légère que Salesforce mais suffisante pour déclencher le pipeline RAG sur un changement de statut ou sur la création d'une activité "propale à rédiger". Pour les PME sous Pipedrive avec un volume de 10 à 30 propales par mois, c'est souvent la combinaison la plus rapide à déployer.

Pour les PME qui souhaitent orchestrer ces intégrations sans développement custom lourd, notre article sur la préparation automatique des rendez-vous commerciaux par IA présente comment n8n peut servir de couche d'orchestration entre le CRM et les services IA, avec des patterns directement réutilisables pour la génération de propales.

Métriques et résultats mesurés

Un système de génération de propales se pilote avec quatre métriques principales. Aucune n'est parfaite seule : c'est leur combinaison qui donne une image fidèle de la valeur réelle.

Sur les déploiements que nous accompagnons, le gain le plus immédiatement visible est le délai. Des équipes qui répondaient à un brief en 3 à 5 jours ouvrés (entre la réunion de qualification et l'envoi de la propale) passent à 24 à 48 heures. Cette réactivité est elle-même un argument commercial : le client perçoit une organisation sérieuse avant même d'avoir lu le document.

Le taux de gain évolue plus lentement. L'amélioration vient d'un double effet : les commerciaux investissent le temps libéré sur la personnalisation fine et la relation client, et la cohérence des propales d'un commercial à l'autre monte, ce qui renforce la perception de marque. Sur 12 mois, les structures que nous accompagnons observent une progression de 5 à 15 points de win rate.

Coûts POC, MVP et TCO

Les fourchettes ci-dessous sont issues de nos déploiements réels. Elles supposent un corpus de 30 à 100 propales gagnées, un CRM existant (HubSpot, Salesforce ou Pipedrive), et un volume de 10 à 50 propales générées par mois. Pour un comparatif complet des coûts d'un projet RAG en entreprise, notre article dédié au budget RAG en entreprise couvre tous les postes en détail.

Le facteur principal qui fait varier le coût du POC est la qualité et la diversité des formats sources. Un corpus de 50 propales en DOCX bien structurés s'ingère en quelques heures. Un corpus de 80 fichiers mêlant PDF scannés, Google Docs et présentations PowerPoint nécessite un pipeline de parsing nettement plus robuste — et donc plus long à développer.

Pièges à éviter

Corpus non maintenu après le déploiement

Le piège le plus fréquent et le plus dommageable sur la durée. Le corpus de propales gagnées doit s'enrichir des nouvelles victoires et se nettoyer des documents obsolètes. Un corpus figé au jour du déploiement sera périmé en 12 à 18 mois : les tarifs auront changé, les prestations auront évolué, les arguments les plus récents n'y figureront pas. Prévoir dès le design un process de mise à jour trimestrielle, idéalement automatisé depuis le CRM (déclenchement de l'ingestion sur changement de statut "won").

Voix de marque perdue

Un système sans calibration de style produit des propales qui ressemblent à des documents génériques. Les clients qui reçoivent régulièrement des propales de votre entreprise le remarquent. Les nouveaux clients ne sentent pas la personnalité de l'entreprise. Le few-shot dans le prompt système n'est pas une option : c'est un prérequis à tout déploiement. Tester la qualité du style sur au moins 10 propales réelles avant de déployer en production.

Prix hallucinés

Sans grounding explicite sur le catalogue services, le modèle peut générer des montants vraisemblables mais incorrects. Ce risque est particulièrement élevé quand le brief client mentionne des montants ("notre budget est d'environ 80 000 euros") : le modèle peut ancrer sa génération sur ce chiffre plutôt que sur votre catalogue. La vérification post-génération des montants est obligatoire, pas optionnelle.

Confusion avec les appels d'offres publics

Le RAG sur corpus de propales commerciales gagnées est un cas d'usage distinct de la réponse aux appels d'offres publics. Les propales commerciales opèrent dans un cadre libre : pas de CCAP, pas de CCAG, pas de DC1/DC2, pas de dépôt dématérialisé sur profil acheteur. Les délais sont négociables, les formats sont libres, la validation humaine ne porte pas les mêmes enjeux juridiques. Si vous cherchez à automatiser les AO publics, notre article sur l'agent IA de réponse aux appels d'offres traite ce cas spécifique.

Adoption bloquée par une interface mal pensée

Le meilleur système RAG échoue si les commerciaux ne l'utilisent pas. La friction à l'entrée (remplir un brief long et complexe) est le premier frein à l'adoption. Le formulaire de brief doit être court (10 à 15 champs maximum), pré-rempli depuis le CRM pour les données disponibles, et accessible depuis l'interface CRM habituelle — pas depuis un outil externe que les commerciaux doivent mémoriser d'ouvrir.

Questions fréquentes

Pour aller plus loin

• Architecture RAG complète : les fondamentaux du Retrieval-Augmented Generation, du chunking aux stratégies de retrieval avancées, pour maîtriser les choix techniques avant de déployer.
• Coût d'un projet RAG en entreprise : fourchettes réelles du POC à la production, TCO sur 1 an, comparatif cloud vs souverain.
• Agent IA de réponse aux appels d'offres : le cas voisin — mais distinct — de la réponse aux AO publics avec contraintes CCAG, DC1/DC2 et dépôt dématérialisé.
• Préparation automatique des rendez-vous commerciaux : l'étape amont — préparer le brief client depuis le CRM avant même que la propale soit commandée.
• Automatiser la génération de rapports par IA : patterns de génération documentaire applicables à la propale (template fixe, injection de données structurées, validation humaine).

Ressources externes de référence :

• Guide RAG pour les entreprises (Direction générale des entreprises) : le cadre institutionnel français sur l'usage du RAG en contexte professionnel.
• HubSpot IA et Breeze (HubSpot officiel) : documentation des fonctionnalités IA natives HubSpot, utile pour comprendre ce que le RAG custom apporte au-delà des outils natifs.
• RAG et données internes d'entreprise (France Num) : guide gouvernemental sur l'exploitation des données documentaires d'entreprise par IA générative.