Récupérer 5 heures par semaine sur tes propositions commerciales

1. Ce que coûte vraiment une proposition commerciale

Ce document est un retour d'expérience. Le process raconté est le mien : la proposition commerciale envoyée après un premier échange, au rythme de quatre à cinq par semaine. Les chiffres sont ceux de ce process, arrondis.

Une proposition ne consiste pas à écrire un document. Elle demande de comprendre le besoin exprimé pendant l'échange, d'identifier les enjeux derrière la demande, de structurer une solution cohérente, de chiffrer correctement et d'adapter la forme au client. À ce rythme, la chaîne complète devient un goulot d'étranglement.

Le coût visible, c'est le temps de rédaction : au moins une heure gagnable par proposition, donc cinq heures par semaine à mon rythme. Le coût caché pèse davantage : la concentration fragmentée, le décalage entre l'échange et l'envoi qui casse l'élan commercial, et la dépendance à la seule personne capable de rédiger.

Ce n'était pas un problème de compétence, c'était un problème de friction. Avant de construire quoi que ce soit, pose ce coût sur le papier : la méthode pour le chiffrer est détaillée dans le calcul du retour sur investissement d'un projet IA.

2. Les trois fausses solutions

Je les ai essayées toutes les trois avant de comprendre où était le vrai problème.

Le point commun des trois : elles automatisent la surface, pas l'architecture. Elles génèrent du format, pas de la stratégie, et générer du texte n'a jamais structuré une proposition.

Le prompt n'est pas inutile pour autant, il est seulement insuffisant seul. Un bon prompt de rédaction existe déjà, prêt à copier, dans les 20 agents Claude pour la machine commerciale. Ce qui suit règle l'autre moitié du problème : décider quoi mettre dedans.

3. Découper le document en blocs

Le déclic est venu en changeant de question. La bonne question n'était pas d'écrire plus vite, elle était de savoir ce qui, dans une proposition, se refabrique inutilement à chaque fois.

La réponse tient en une phrase : une proposition n'est pas un document unique à produire, c'est un assemblage de blocs maîtrisés. La mienne se découpe en sept blocs : présentation de l'entreprise, méthode de travail, reformulation du besoin, solution proposée, planning, chiffrage, conditions.

4. Ce qui se répète, ce qui varie

Voici la grille appliquée à mes sept blocs. C'est le livrable central de ce document : refais l'exercice sur ta propre proposition, il prend moins d'une heure.

Deux tests simples pour classer un bloc. Si tu as écrit trois fois presque le même paragraphe dans trois propositions, il est répétable. Si une erreur dans ce bloc coûte de l'argent ou de la crédibilité, il reste humain.

La même grille se pose sur n'importe quel process avec quatre questions : qu'est-ce qui est identique d'une exécution à l'autre, qu'est-ce qui varie et d'où vient l'information, où se prend la décision humaine, et qu'est-ce qui existe déjà dans l'historique.

5. La base de connaissance à constituer

Le système repose sur trois piliers, et aucun des trois n'est technique.

Concrètement, ma base de connaissance est un dossier de fichiers texte. Un fichier par bloc répétable, une fiche par type de mission avec ses briques de solution et ses durées types, et les propositions signées gardées comme référence de ton. Rien d'autre.

Le plus long n'est pas la technique, c'est la première rédaction des blocs. C'est aussi le meilleur investissement du système : la cohérence ne repose pas sur un prompt, elle repose sur cette architecture.

6. Le skill Claude qui assemble les blocs

L'assemblage passe par un skill : une consigne enregistrée que Claude applique dès que je prépare une proposition. Le gabarit SKILL.md et son mécanisme de déclenchement sont expliqués pas à pas dans le guide des Skills Claude. Ce qui suit est le contenu de ma consigne d'assemblage, à adapter à tes blocs.

Utiliser quand je prépare une proposition commerciale après un échange avec un prospect.

1. Lis mes notes d'échange et repère le besoin exprimé, le contexte, le budget évoqué, le délai.
2. Choisis le type de mission correspondant dans le dossier typologies.
3. Reprends les blocs répétables tels quels : présentation, méthode, conditions. Ne les réécris pas.
4. Rédige la reformulation du besoin avec les mots du client, jamais les miens.
5. Assemble la solution depuis les briques du type de mission, en écartant celles qui ne servent pas ce projet.
6. Propose un planning depuis les durées types, marqué comme à confirmer.
7. Laisse le chiffrage vide, avec la fourchette du type de mission en commentaire : c'est moi qui décide.
8. Sors l'ensemble en texte brut, dans l'ordre du gabarit, sans mise en page.

J'utilise Claude Code pour faire tourner l'ensemble, parce qu'il lit et écrit directement les fichiers de la base de connaissance. C'est mon choix d'outil au 30/08/2026, pas une condition : la logique fonctionne partout où un skill peut lire tes blocs.

Un conseil tiré de l'expérience : structure avant de développer. J'ai utilisé l'IA en amont pour challenger le découpage, simuler des cas concrets et repérer les frictions, avant d'automatiser quoi que ce soit. On ne construit pas un outil, on conçoit une architecture.

7. Séparer le contenu de la mise en page

Le skill sort du texte brut, jamais un document mis en page. La mise en page vit dans un gabarit à part, et le contenu validé y est injecté en dernier.

J'ai mélangé les deux au début, et c'est l'erreur qui m'a coûté le plus de corrections. Quand le fond et la forme vivent dans le même fichier, chaque correction de fond casse la mise en page, et chaque ajustement de forme fait relire tout le fond. Séparés, les allers-retours portent sur le contenu seul, et la mise en page n'est faite qu'une fois, sur la version finale.

8. Les gains mesurés, et leurs limites

Les chiffres de mon process, arrondis, après la mise en place du système.

Les quinze à vingt minutes incluent la relecture : la validation humaine n'a pas disparu, elle s'est déplacée en couche finale, là où elle a le plus de valeur.

Trois limites honnêtes. Le premier mois sert surtout à constituer les blocs, le gain vient après. Un projet qui ne rentre dans aucun type de mission repart en rédaction manuelle, et c'est très bien ainsi. Enfin, le système ne chiffre pas : le prix reste une décision, pas une génération.

Le vrai gain dépasse le temps. Une proposition envoyée le jour même arrive pendant que l'échange est encore chaud, et les cinq heures libérées se réinvestissent dans la relation et la conclusion des ventes. Ce n'est pas un gain de productivité, c'est un gain de capacité.

9. Appliquer la méthode à un autre process

La proposition commerciale n'est qu'un exemple. Le même découpage en blocs répétables et variables s'applique au reporting hebdomadaire, aux réponses aux appels d'offres ou aux comptes rendus d'intervention. Je ne redonne pas ici de grille pour choisir ton prochain process, elle existe déjà dans les tâches à automatiser en premier dans une PME.

Ce travail de découpage, décider ce qui se répète, ce qui varie et ce qui reste humain, est exactement le cœur d'un audit IA : on le fait sur tes process, avec tes chiffres, avant de construire quoi que ce soit.

10. Ce que je referais différemment

Le système fonctionne, mais j'ai perdu du temps à cinq endroits.

Le vrai levier de l'IA en entreprise n'est pas d'écrire plus vite. C'est de supprimer les pertes de temps structurelles sans dégrader la qualité. Cinq heures par semaine récupérées sur un process critique, ce n'est pas du confort : c'est de la capacité rendue à ce qui fait signer.

Questions fréquentes

Combien de temps demande la mise en place d'un système de propositions en blocs

Le découpage de ta proposition en blocs prend moins d'une heure avec la grille de la section 4. Le gros du travail est la première rédaction des blocs répétables et des fiches par type de mission. C'est un investissement de démarrage, le premier mois sert surtout à ça, et chaque proposition suivante le rentabilise.

Un bon prompt ne suffit-il pas pour rédiger une proposition commerciale

Non, et c'est le piège le plus courant. Un prompt rédige, il ne décide pas ce qui doit se trouver dans le document ni ce qui doit rester humain. Sans architecture de blocs derrière, le résultat reste instable d'une proposition à l'autre, et les allers-retours de correction mangent le temps gagné à la rédaction.

Faut-il savoir coder pour construire ce système

Non. La base de connaissance est un dossier de fichiers texte, la consigne d'assemblage s'écrit en français, et le gabarit de skill se copie tel quel. Claude Code est un outil en terminal, mais on lui parle en langage courant. La compétence qui compte, c'est la connaissance de ton métier, pas la technique.

Est-ce que ce système standardise les propositions

C'est l'inverse du modèle figé. Les blocs répétables sont les tiens, écrits dans ta voix, et la partie qui compte pour le client, la reformulation de son besoin et la solution, est produite à chaque fois depuis ses mots à lui. Le modèle figé force le besoin dans un cadre, l'assemblage adapte le cadre au besoin.

Que reste-t-il à faire à la main sur chaque proposition

Trois choses : la relecture de la reformulation du besoin, l'ajustement de la solution et du planning, et le chiffrage, qui reste une décision entièrement humaine. Le tout tient dans les quinze à vingt minutes annoncées. Si un projet ne rentre dans aucun type de mission, il repart en rédaction manuelle complète.