La plupart des « listes de vérification pour présentations » sont les mêmes douze points réenchaînés : vérifiez vos polices, arrivez à l’heure, prévoyez un fichier de secours. Aucun de ces points n’est exactement faux. Simplement, ils sont inutiles sans savoir **quand** chaque vérification compte et **en quoi elle doit précisément** détecter un problème. Une vérification des polices trois jours avant ne fait pas le même travail qu’une vérification cinq minutes avant la présentation — l’une détecte une typographie incorrecte, l’autre repère une police non intégrée qui bascule silencieusement vers Calibri sur la machine d’un client. J’ai revu des présentations qui ont échoué à chaque étape de ces vérifications, c’est pourquoi j’ai divisé la liste en fonction du moment où la vérification doit effectivement être effectuée, et non simplement de ce qu’elle couvre.

Avant d’ouvrir l’éditeur de diapositives

Les vérifications les plus importantes ont lieu avant même qu’un contenu n’existe, et ce sont celles que les gens sautent parce qu’elles semblent retarder le « vrai » travail.

  • Une phrase, un objectif. Pouvez-vous dire en une phrase ce que vous voulez que le public fasse ou décide après cette présentation ? Si cela prend deux phrases, vous avez probablement combiné deux présentations, et le nombre de diapositives va gonfler pour servir les deux.
  • Connaître précisément qui sera dans la salle. Pas « les cadres » — les trois ou quatre personnes spécifiques, et ce que chacune est susceptible de contester. Une diapositive budgétaire qui satisfait un directeur financier peut sembler trop légère pour un responsable technique, et vice versa. Cela influence les diapositives que vous construisez, et non seulement comment vous les formulez.
  • Définir tôt les contraintes de format. Présentation en direct dans la salle, partage d’écran à distance, ou « envoyée en document de rappel à lire sans vous ». Ce sont trois documents différents portant la même extension de fichier. Un document de rappel nécessite plus de texte sur les diapositives qu’une présentation que vous commentez ; un deck à distance nécessite des marges plus larges car la compression du partage d’écran réduit les détails aux bords.

Pendant la construction du deck

C’est ici que les vérifications de structure prennent place — pas encore le polissage visuel, car polir une diapositive que vous supprimerez plus tard est un effort perdu.

  • Chaque diapositive mérite sa place. Posez-vous pour chaque diapositive : si je la supprimais, l’argument tiendrait-il toujours ? Si oui, supprimez-la ou intégrez-la à une autre diapositive. Cela permet de détecter les « diapositives de contexte » qui existent parce que le présentateur voulait paraître complet, et non parce que le public en a besoin.
  • Les diapositives de données ont un message clair, et non seulement un graphique. Si votre titre est « Résultats du T3 » et que le graphique oblige le public à en déduire la conclusion, vous avez externalisé votre argument auprès d’eux. Je ne recommande pas de laisser l’interprétation comme exercice — placez la conclusion dans le titre et laissez le graphique la soutenir.
  • Les schémas sont conçus pour être lus d’un coup d’œil, et non décodés. Un schéma de processus avec neuf boîtes et des flèches entrecroisées fonctionne bien quand vous êtes celui qui l’a construit et connaissez déjà le flux — il cesse de fonctionner dès qu’une personne inconnue le regarde pendant quatre secondes. Si vous construisez des visuels de flux ou de hiérarchie depuis zéro à chaque fois, un modèle de schéma structuré, comme ceux disponibles dans les modèles de schémas PowerPoint, impose au moins une mise en page lisible comme point de départ.

Consistance visuelle — la veille, pas le jour J

Faites cela la veille, pas le matin même, car corriger des incohérences visuelles sous pression est la manière dont de nouvelles incohérences apparaissent.

  • Une famille de polices, deux poids maximum. Pas « vérifier que vos polices ont l’air bien » — comptez littéralement le nombre de polices distinctes dans le deck. Les diapositives copiées-collées depuis d’autres decks sont généralement responsables ; elles apportent leur ancien formatage même si le texte semble correct à l’œil.
  • Les couleurs utilisées pour signifier, et non décorer. Si le rouge signifie « dépassement de budget » sur la diapositive 4, il ne doit pas aussi être la couleur d’accent de la marque mettant en valeur une statistique neutre sur la diapositive 9. Les publics associent rapidement les couleurs ; une utilisation incohérente les amène à douter d’un graphique qui était pourtant correct.
  • Chaque image est en résolution native ou plus grande, jamais étirée. Un logo prélevé depuis une favicon de site web et agrandi pour remplir une diapositive de titre est l’une des pannes visuelles en dernière minute les plus courantes, et il est invisible sur un écran d’ordinateur portable mais évident sur un vidéoprojecteur. Si vous assemblez un deck à partir d’une base de modèle, un thème Keynote ou un thème PowerPoint thématisé maintient au moins les placeholders d’images à des dimensions cohérentes et testées.

Vérifications techniques — la veille au soir

Celles-ci sont ennuyeuses, et c’est exactement pourquoi elles sont souvent sautées. Ce sont aussi les vérifications les plus susceptibles de provoquer une défaillance visible devant le public.

  • Les polices sont intégrées, et non seulement installées sur votre machine. Si vous présentez depuis un appareil différent de celui sur lequel vous avez travaillé — le laptop d’une autre personne, un PC de salle de conférence — une police personnalisée non intégrée est silencieusement remplacée, et le texte se réorganise ou dépasse sa boîte. Exportez une version PDF en sauvegarde spécifiquement parce que les PDFs intègrent les polices.
  • Les fichiers vidéo et audio sont testés sur l’appareil de lecture réel. Une vidéo intégrée qui fonctionne bien en mode édition peut parfois échouer en mode présentateur à cause d’une incompatibilité de codec — c’est une défaillance réelle et courante, et non un cas marginal. Testez en mode exact dans lequel vous présenterez, et non en mode édition.
  • Le fichier s’ouvre proprement sur une machine que vous ne contrôlez pas. Envoyez-le à un collègue ou ouvrez-le sur un autre ordinateur. Cela permet de détecter les polices manquantes, les liens brisés et les images liées mais non intégrées qui apparaissent comme des cases grises.

Quelques minutes avant la présentation

Liste courte volontairement — tout ce qui est plus long et vous faites du travail de la veille sous pression du jour J.

  • Le nombre de diapositives correspond à votre temps de parole réel, vérifié contre un essai réel, et non une estimation. Un deck de 20 diapositives à « environ une minute par diapositive » semble bien sur papier et dure 34 minutes en pratique une fois que l’on compte les questions en cours de route.
  • Les notes du présentateur sont visibles uniquement pour vous, confirmé sur la configuration d’affichage réelle, et non supposé. Le mode double écran échoue silencieusement plus souvent que les gens ne le pensent, surtout via des commutateurs HDMI dans les salles de réunion partagées.

Aucune de ces vérifications ne remplace le fait d’avoir quelque chose de valable à dire — une liste de vérification ne peut pas corriger un argument faible, et je serais sceptique face à toute conseil pour présentation qui implique le contraire. Ce qu’elle fait, c’est empêcher un argument solide d’être sapé par une substitution de police ou un graphique que personne ne peut lire depuis le fond de la salle. Si vous reconstruisez votre système visuel depuis zéro à chaque fois, commencer à partir d’une base cohérente — même simplement en parcourant ce qui est disponible dans les fonctionnalités des modèles de présentation — permet de consacrer le temps de polissage au contenu plutôt qu’au formatage.