The Timeline Section of a Proposal
Give the client a clear, credible picture of how the engagement unfolds — what happens when, how long each phase takes, and what they need to do to keep things on track.
Ce que fait la section calendrier d'une proposition
La section calendrier d'une proposition donne au client une image claire et crédible du déroulement de la mission — ce qui se passe à chaque phase, combien de temps cela prend, et ce qu'il doit faire pour rester dans les temps. Elle se situe après le cahier des charges et avant les conditions commerciales, faisant le pont entre « ce que nous ferons » et « ce que cela coûte » avec une réponse concrète à « quand y arriverons-nous ».
Contrairement à un plan de projet, un calendrier de proposition est écrit pour un décideur, pas un chef de projet. Il regroupe les tâches liées en phases nommées — généralement Découverte, Design, Construction, QA et Lancement — et décrit ce que chaque phase produit et quelle validation débloque la suivante. Cette structure rassure le client sur le fait que le travail est séquencé logiquement et que vous avez déjà livré ce type de mission.
Un calendrier bien rédigé définit aussi les conditions dont dépend le planning. Des durées relatives plutôt que des dates calendaires maintiennent la proposition valide quel que soit le moment de la signature. Des dépendances client explicites — éléments, délais de retour, approbations — créent un dossier écrit qui vous protège si un retard provient de leur côté. Des phases post-lancement comme la passation, la formation et une période de support complètent le tableau afin que rien ne paraisse inachevé.
Ce qu'il faut inclure dans la section calendrier
Structure en phases avec des groupes nommés
Organisez le travail en cinq à sept phases nommées — Découverte, Design, Construction, QA, Lancement — plutôt qu'une liste plate de tâches. Chaque nom de phase doit signaler un mode de travail distinct et un résultat clair.
Durées relatives par phase
Exprimez chaque phase en jours ou semaines ouvrés, pas en dates calendaires. Les durées relatives maintiennent la proposition exacte quel que soit le moment de la signature du contrat.
Livrable de phase et déclencheur de validation
Indiquez ce que chaque phase produit et quelle décision ou approbation est requise avant que la phase suivante ne commence. Cela évite que des phases ne se déroulent en parallèle quand elles ne devraient pas, et donne au client une idée claire de son rôle.
Dépendances client explicitement nommées
Nommez les éléments, accès ou décisions dont vous avez besoin du client dans chaque phase, et précisez le délai de retour. Des dépendances écrites créent une responsabilité et protègent le calendrier si les apports arrivent en retard.
Hypothèse de date de début
Ancrez tout le calendrier à un déclencheur unique — par exemple, « le calendrier suppose un lancement du projet dans les cinq jours ouvrés suivant la signature du contrat ». Sans cela, les clients supposent que le compteur démarre quand ils se sentent prêts.
Note d'imprévus
Ajoutez une ou deux phrases reconnaissant que les durées supposent des retours dans les délais et que les retards liés à des approbations tardives décaleront les phases suivantes d'une période équivalente. Cela protège les deux parties sans gonfler chaque estimation de phase.
Phases post-lancement
Incluez la passation, la formation et une période de support ou de garantie définie comme des phases nommées. Les clients qui ne voient pas cela en amont se sentent abandonnés après le lancement — les préciser comble le fossé émotionnel entre livraison et achèvement.
À faire et à éviter dans le calendrier de proposition
Do
- Exprimez chaque phase comme une durée relative — « trois semaines ouvrées » — afin que le calendrier reste valide quel que soit le moment de la signature du contrat.
- Nommez ce que chaque phase produit et énoncez la validation ou décision client qui déclenche le début de la phase suivante.
- Nommez explicitement les dépendances client — éléments de marque, identifiants, délais de retour — dans la phase qu'elles concernent, pas enterrées dans le contrat.
- Incluez des phases post-lancement comme la passation, la formation et une période de support définie afin que le client voie où se termine la mission.
- Ajoutez une courte note d'imprévus indiquant que les durées supposent des approbations dans les délais et que des apports client tardifs décaleront les phases suivantes d'une période équivalente.
Avoid
- Ne listez pas de dates calendaires — dès que la signature glisse d'un jour, chaque jalon de la proposition devient faux.
- Ne détaillez pas chaque tâche granulaire ; une liste de 40 lignes submerge les décideurs et donne à la proposition l'allure d'un plan de projet, pas d'un document commercial.
- N'omettez pas ce qui déclenche le début de chaque phase — les clients supposent que les phases s'enchaînent automatiquement plutôt que sur validation, ce qui mène à des litiges de dérive de périmètre.
- Ne gonflez pas secrètement chaque estimation de phase pour créer une marge cachée — cela érode la confiance quand le client remarque que le travail est achevé bien avant l'échéance annoncée.
- Ne rendez pas le calendrier irréaliste pour remporter le contrat ; le premier jalon manqué détruit une crédibilité que le reste du projet mettra du temps à reconstruire.
Comment Waxe génère la section calendrier
- 1
Extraire le périmètre et la structure des phases du contexte de la proposition
Waxe lit le cahier des charges déjà présent dans la proposition et identifie les phases logiques pour cette mission — Découverte, Design, Construction, QA, Lancement, et tout support post-lancement. Elle n'applique pas une séquence générique ; elle dérive les phases de ce que le projet implique réellement, afin que le calendrier corresponde au périmètre qui le précède.
- 2
Attribuer des durées relatives à chaque phase
Pour chaque phase, Waxe estime une durée en jours ou semaines ouvrés selon le périmètre et la complexité des livrables. Toutes les durées sont relatives — jamais des dates calendaires — et l'ensemble du calendrier est ancré à un déclencheur de lancement afin qu'il reste valide quel que soit le moment de la signature du contrat.
- 3
Identifier et nommer les dépendances client par phase
Waxe signale ce que le client doit fournir dans chaque phase — éléments, identifiants, validation des parties prenantes, retours dans un délai convenu — et l'énonce explicitement dans la description de la phase. Cela crée un dossier écrit des conditions dont dépend le calendrier, protégeant les deux parties si les apports arrivent en retard.
- 4
Rédiger les livrables de phase et les déclencheurs de validation
Chaque phase reçoit une description d'une à deux phrases de ce qu'elle produit et quelle décision ou approbation débloque la phase suivante. Waxe garde un langage direct et centré sur les livrables — pas une liste de tâches, mais une déclaration claire de ce que le client aura en main à chaque jalon.
- 5
Ajouter la note d'imprévus et les phases post-lancement
Waxe termine le calendrier par une courte note d'imprévus — une à deux phrases reconnaissant que les durées supposent des approbations dans les délais — et ajoute toute phase post-lancement comme la passation, la formation et une période de support définie. Le résultat est une section calendrier que le client peut lire en deux minutes et signer en toute confiance.
Ce que la section calendrier doit couvrir
- Des phases nommées qui regroupent le travail lié (par ex. Découverte, Design, Construction, QA, Lancement)
- Une durée relative pour chaque phase, en jours ou semaines ouvrés
- Une brève description de ce que chaque phase produit
- La validation ou décision qui déclenche chaque phase suivante
- Les dépendances client explicitement nommées dans chaque phase
- Une hypothèse unique de date de début liée à la signature du contrat
- Une courte note d'imprévus couvrant les approbations et retours tardifs
- Des phases post-lancement incluant passation, formation et une période de support définie
Construire la section calendrier : l'ancienne méthode face à waxTable
Frequently asked
Qu'est-ce que la section calendrier d'une proposition, et pourquoi est-elle importante ?
La section calendrier d'une proposition cartographie l'ensemble de la mission en phases distinctes — Découverte, Design, Construction, QA, Lancement — chacune avec une durée estimée, une description de son livrable, et la dépendance client qui débloque la phase suivante. Elle compte parce que les clients l'utilisent pour évaluer le risque : un calendrier vague ou absent signale que vous n'avez jamais livré ce type de projet. Un calendrier bien construit réduit l'anxiété, fixe des attentes réalistes, et vous donne une preuve écrite si le client cause un retard. Bien fait, c'est l'une des pages les plus persuasives d'une proposition.
Dois-je utiliser des dates calendaires ou des durées relatives dans un calendrier de proposition ?
Utilisez toujours des durées relatives — « deux semaines » plutôt que « du 10 au 24 mars ». Les dates calendaires font vieillir votre proposition dès que la signature glisse d'un seul jour, forçant une révision avant même le début du projet. Les durées relatives restent valides quel que soit le moment où le contrat est signé. Ancrez tout le calendrier à un déclencheur unique : par exemple, « le calendrier suppose un lancement du projet dans les cinq jours ouvrés suivant la signature du contrat ». Cette seule phrase préserve l'intégrité de toutes les phases qui suivent.
Comment les dépendances client doivent-elles apparaître dans le calendrier de la proposition ?
Nommez-les explicitement dans la phase qu'elles concernent — ne les enterrez pas dans le contrat et ne les laissez pas implicites. Pour chaque phase, indiquez ce dont vous avez besoin du client, sous quelle forme, et à quel moment par rapport au début de cette phase. Les dépendances courantes incluent les éléments de marque, les identifiants d'accès, la validation des parties prenantes sur le livrable précédent, et le délai de retour dans un nombre convenu de jours ouvrés. Nommer cela en amont déplace la responsabilité par écrit. Si un client manque une dépendance et que le calendrier glisse, votre proposition a déjà documenté que le planning était conditionné à ses apports.
Combien de phases un calendrier de proposition doit-il inclure ?
Cinq à sept phases couvrent la plupart des missions de service sans submerger le lecteur. Regroupez les tâches liées en une phase nommée plutôt que de lister chaque action granulaire — une liste de 40 lignes dans une proposition ressemble à un plan de projet, pas à un document commercial, et signale que vous transférez le risque au client plutôt que de le gérer vous-même. Chaque phase doit nommer ce qu'elle produit et quelle décision ou validation déclenche la suivante. Les phases post-lancement — passation, formation, une période de support définie — ont aussi leur place ici ; les clients se sentent abandonnés si cela n'est pas prévu dès le départ.
Quelle est une façon réaliste de gérer les imprévus dans un calendrier de proposition ?
Ajoutez une brève note d'imprévus à la fin du calendrier, pas cachée dans une phase. Une ou deux phrases suffisent : reconnaissez que les durées supposent des retours et approbations dans les délais convenus, et indiquez que les retards causés par des apports client tardifs décaleront les phases suivantes d'une période équivalente. Évitez la tentation de gonfler secrètement chaque phase à la place — cette approche obscurcit le vrai calendrier et érode la confiance quand le client s'en aperçoit. Une note d'imprévus honnête signale de la confiance, pas de la faiblesse, et protège les deux parties si les approbations tardent.
Skip the writing — generate the whole proposal
Waxe drafts it on your brand in about five minutes, then you refine it. From two days of work to a few cents.
Votre prochain proposition, en cinq minutes
Parlez de votre client à Waxe et obtenez un proposition complet, à votre image, prêt à relire — le travail de deux jours pour quelques centimes. Pas de page blanche, rien à mettre en forme à la main : vous répondez à un court brief, Waxe rédige, et vous gardez le contrôle total du document final dans l'éditeur.