Un calendrier de livraison réaliste

Presque tous les retards de livraison en design suivent le même scénario. L’estimation a été faite en jours ouvrés, l’échéance a été acceptée comme une date calendaire, et personne n’a converti entre les deux avant la dernière semaine. Puis un jour férié apparaît, un cycle de validation prend quatre jours au lieu d’un, et un projet qui semblait confortable est soudain une semaine en retard.

Un calendrier réaliste n’est pas une estimation plus optimiste. C’est une courte routine de planification qui tient compte du calendrier, de la boucle de validation et des étapes qu’aucune estimation ne capture. Ce guide montre cette routine avec un exemple chiffré. L’arithmétique est assez simple pour être faite à la main ; l’essentiel est de la faire volontairement.

Partez du livrable, pas des heures

La première étape est d’écrire noir sur blanc ce que « livré » signifie concrètement. « Le design du site » n’est pas un livrable. « Cinq maquettes de pages dans un fichier partagé, plus les images exportées aux tailles convenues, plus un cycle de corrections de texte après validation » en est un. La différence compte parce que la seconde version révèle un travail que la première cache : l’export des images, le conditionnement des fichiers sources et un passage de validation consomment tous des jours.

Pour chaque livrable, listez les étapes qui doivent se dérouler dans l’ordre :

1. Les éléments reçus et vérifiés. Le brief, les fichiers sources, les textes, les éléments de marque. Un calendrier qui démarre avant que les éléments soient réellement exploitables est un calendrier construit sur une hypothèse.
2. La première version. L’essentiel du travail créatif.
3. La validation. L’attente des retours fait partie du temps écoulé, même si elle ne fait pas partie de votre temps de travail.
4. Les corrections. En général un cycle inclus, parfois deux. Décidez du nombre avant le début du projet.
5. La finalisation. Conditionnement, exports, nommage des fichiers, envoi.

Seules les étapes 2 et 4 relèvent surtout de votre temps de travail. L’étape 1 dépend du client, l’étape 3 dépend du client, et l’étape 5 est systématiquement sous-estimée.

Tout convertir en deux colonnes

Un calendrier exploitable est un tableau à deux colonnes : jours ouvrés et dates calendaires. Remplissez d’abord les jours ouvrés, puis convertissez-les en dates, jamais l’inverse.

Le calcul qui piège le plus de monde est celui-ci. Si nous sommes lundi et que l’estimation est de 10 jours ouvrés, le travail se termine à la fin du deuxième vendredi — à condition qu’aucun jour férié ne tombe dans ces deux semaines. Dix jours calendaires auraient terminé le mercredi suivant, en sautant silencieusement un week-end qui n’avait jamais été prévu dans le plan.

Deux outils rendent la conversion moins sujette aux erreurs :

• Le calculateur de jours entre deux dates donne le nombre de jours écoulés et inclusifs entre deux dates, exactement ce qu’il faut pour vérifier « est-ce toujours à deux semaines ? ».
• Le calculateur d’ajout et de retrait de jours répond à la question inverse : « la livraison est promise dans 15 jours ouvrés — quelle date cela fait-il ? ».

Aucun des deux outils ne connaît votre calendrier. Les jours fériés, vos propres congés et les disponibilités du client doivent toujours être appliqués à la main. Mais faire l’arithmétique en quelques secondes rend beaucoup plus probable que vous revérifiiez réellement le calendrier quand quelque chose bouge.

Comptez explicitement la boucle de validation

L’erreur de planification la plus fréquente n’est pas une mauvaise estimation du travail créatif. C’est de traiter la validation comme instantanée. Un cycle de validation réaliste ressemble à ceci :

• Vous envoyez la maquette lundi après-midi.
• Le client la lit mercredi.
• Les retours arrivent en deux messages, mercredi et jeudi.
• Vous clarifiez une question ouverte jeudi après-midi et recevez la réponse vendredi.
• Les corrections ont lieu le lundi suivant.

Cela fait une semaine entière entre « maquette envoyée » et « corrections commencées », et c’est parfaitement normal. Inscrivez-la dans le plan comme du temps calendaire écoulé, puis déduisez-la des jours ouvrés que vous avez promis.

Pour un projet avec deux cycles de validation, le temps écoulé peut représenter la moitié de la durée calendaire alors que le temps de travail ne compte que quelques jours. Le calendrier doit afficher les deux nombres, sinon il sera faux d’une manière qui ressemble à de la malchance.

Décidez ce que la marge couvre

Une marge n’est pas un vague coussin de sécurité. Donnez-lui un rôle pour qu’elle puisse être argumentée :

• Marge d’entrée. Du temps pour les fichiers sources en retard, les logos manquants ou les textes qui arrivent dans le mauvais format. Elle protège la date de départ.
• Marge de validation. Absorbe un retour tardif ou fragmenté. Elle protège le milieu.
• Marge de livraison. Couvre les exports, les ré-exports après un changement de couleur de dernière minute et le conditionnement. Elle protège la date de livraison.

Un point de départ courant est d’un à deux jours ouvrés par marge sur un petit projet, ou environ 20 % du temps de travail estimé sur un projet plus gros. Le bon chiffre dépend du client et de la complexité de la chaîne de validation, mais inscrire la marge comme une ligne nommée change la conversation : elle cesse d’être du remplissage et devient une partie du plan.

Un exemple chiffré

Une maquette de page plus trois déclinaisons pour les réseaux sociaux, pour un nouveau client :

Étape	Jours ouvrés	Impact calendaire
Attente des textes définitifs et des fichiers de logo	0 travaillé, 3 écoulés	Départ décalé de 3 jours
Mise en place du document et construction de la maquette	3	—
Construction des trois déclinaisons sociales	2	—
Premier cycle de validation	0 travaillé, 5 écoulés	Souvent le poste le plus long
Corrections	2	—
Deuxième cycle de validation	0 travaillé, 3 écoulés	—
Exports finaux et livraison	1	—
Marges (entrée, validation, livraison)	2	—

Le total travaillé est de 10 jours. Le total écoulé est d’au moins 18 jours calendaires avant même de compter les week-ends. Promettre « environ deux semaines » est donc optimiste, et promettre « deux semaines de travail » sans date est ambigu. Un calendrier qui énonce les deux — 10 jours ouvrés, livraison à une date précise trois semaines plus loin, avec les cycles de validation affichés — est la version honnête.

C’est aussi là que le calculateur d’heures de travail trouve sa place. Si un projet est chiffré « environ une journée et demie » de travail, convertir l’estimation en heures et la comparer au temps de travail réellement disponible cette semaine est un contrôle utile. Un plan qui suppose huit heures ininterrompues par jour est un plan qui ignore les e-mails, les appels et le reste de vos projets.

Replanifiez quand quelque chose bouge, pas après

Un calendrier de livraison est un document vivant aussi longtemps que le projet dure. Quand un cycle de validation glisse de trois jours, refaites la conversion le jour même et annoncez la nouvelle date dans le même message. Cette seule habitude évite la plupart des conflits d’échéance : le client voit la date bouger tant qu’il est encore temps de décider, au lieu de la découvrir à la fin.

Deux règles gardent la replanification honnête :

1. Changez la date, jamais le périmètre en silence. Si la date ne peut pas bouger, le périmètre doit se réduire. Décidez lequel des deux change et écrivez-le.
2. Gardez les cycles de validation visibles. Un calendrier révisé qui cache le deuxième cycle de validation n’est pas une révision, c’est une nouvelle estimation optimiste.

Une courte checklist avant de promettre une date

1. Livrable défini comme une liste concrète, exports et conditionnement inclus.
2. Éléments listés, avec la date à laquelle chacun doit arriver.
3. Travail estimé en jours ouvrés, étape par étape.
4. Cycles de validation comptés en jours calendaires écoulés, avec un délai de réponse réaliste.
5. Marges nommées et dimensionnées, pas supposées.
6. Jours ouvrés convertis en date calendaire, week-ends et jours fériés vérifiés.
7. Date de livraison énoncée avec ses hypothèses : nombre de cycles de validation, ce qui compte comme une correction, et moment où le compte à rebours démarre.

Rien de tout cela n’est compliqué, et tout prend environ quinze minutes. C’est aussi la différence entre une date tenue et une date pour laquelle on s’excuse.