Trois jours, c'est une longue durée pour consacrer à un support qui est jugé en seulement quatre secondes à peine après qu’on l’a ouvert. Alors, quand votre supérieur ouvre le fichier sur son téléphone pendant un trajet ou une pause café et que chaque boîte de texte a glissé à moitié hors de sa forme, cela ne semble pas être un simple bug technique — cela donne l’impression d’un échec personnel. Ce n’est pas le cas. Et ce n’est pas non plus quelque chose que « concevoir mieux » aurait pu empêcher, car le problème ne se produit généralement pas sur votre écran. Il se produit sur le sien, dans un logiciel que vous n’avez jamais ouvert. --- **Le fichier que votre supérieur a vu n’était probablement ni PowerPoint ni Keynote** Voici la partie qui est souvent omise dans presque tous les articles sur les « conseils pour concevoir des présentations » : quand quelqu’un tape sur un fichier .pptx ou .key sur un téléphone — dans Mail, Slack, WhatsApp ou une application de fichiers — le téléphone ne lance pas fréquemment le logiciel de présentation complet pour l’afficher. Sur iPhone, la documentation d’Apple concernant le cadre Quick Look indique que les documents Microsoft Office et les fichiers iWork font partie des formats qu’il peut prévisualiser, en utilisant son propre générateur léger plutôt que le moteur de rendu réel de PowerPoint ou Keynote. Ce générateur dessine une approximation rapide de votre diapositive — texte, formes, mise en page de base — et ignore ou réinterprète silencieusement tout ce qui est plus complexe : polices intégrées, espacement de ligne précis, objets superposés, animations. Ainsi, la présentation que votre supérieur a « ouverte » n’a pas été rejetée par PowerPoint. Elle a été dessinée par un outil de prévisualisation conçu pour la vitesse, et non pour la fidélité, et cet outil n’a jamais vu votre modèle personnalisé avant. [Le même problème de forme défaillante apparaît également avec un vidéoprojecteur fatigué dans une salle de conférence](https://imaginelayout.com/blog/contrast-trick-bad-projector-presentation) — le contenu ne change pas, mais l’outil qui le rend a des capacités différentes de celles pour lesquelles vous avez conçu, et personne ne vous avertit des coins qu’il va couper. --- **Pourquoi le texte en particulier est ce qui se dégrade** Les boîtes de texte sont les objets les plus fragiles sur toute diapositive, car la plupart d’entre elles effectuent silencieusement des calculs en arrière-plan. La documentation d’assistance de Microsoft pour AutoFit confirme que, par défaut, un espace réservé est réglé sur « Redimensionner la forme pour s’adapter au texte » ou « Réduire le texte en cas de débordement » — ce qui signifie que la boîte que vous avez construite à une certaine taille n’est pas fixe, mais une formule qui recalcule en fonction de la police réellement disponible au moment du rendu. Changer le moteur de rendu revient à changer les entrées de cette formule. La substitution de polices aggrave encore le problème d’une manière que la plupart des gens ne remarquent jamais, car le logiciel ne vous avertit pas que cela se produit. Les fils de discussion de dépannage spécialisés PowerPoint et les forums de la communauté Microsoft décrivent à plusieurs reprises le même schéma : si la police exacte n’est pas disponible pour le logiciel qui ouvre le fichier, celui-ci remplace silencieusement une police similaire et indique toujours le nom de la police d’origine — rien dans l’interface ne vous informe d’un échange. Une police substituée avec des largeurs de caractères légèrement différentes suffit à faire déborder un titre sur deux lignes au lieu d’une, ce qui entraîne un décalage de toutes les boîtes en dessous. C’est exactement pourquoi [réduire le texte pour qu’il tienne est la mauvaise réaction](https://imaginelayout.com/blog/10-rules-designing-slides) en premier lieu — une boîte qui fonctionne déjà à la limite sur votre machine n’a aucune marge de manœuvre une fois que le prévisualiseur du téléphone effectue ses propres calculs de substitution par-dessus. --- **Le rapport d’aspect n’est pas le problème que les gens supposent** Il est tentant de blâmer directement l’écran en portrait du téléphone — assurément, une diapositive en 16:9 ne tient tout simplement pas sur un écran étroit et haut. En pratique, cela arrive rarement à faire échouer une présentation, car à la fois Quick Look et les lecteurs mobiles d’Office redimensionnent l’ensemble de la diapositive comme une seule unité d’image, sans la réorganiser, de la même manière qu’une photo est redimensionnée sans être coupée. La diapositive devient plus petite, mais pas déformée. Ce qui se brise réellement, c’est l’espacement interne qui était déjà serré avant le redimensionnement — un sous-titre situé à 2 pixels au-dessus du bord d’un graphique sur votre ordinateur n’a plus de place une fois que toute la diapositive se réduit et que tout élément à l’intérieur recalcule indépendamment. --- **Le contrôle qui prend moins de temps que de rouvrir le fichier** Tout cela ne signifie pas tester sur un téléphone réel avant chaque envoi — ce n’est pas réaliste sous une échéance. Ce qui est réaliste : exporter une version PDF en plus du fichier natif avant d’envoyer quoi que ce soit d’important. Un PDF fige chaque boîte de texte, chaque décision de substitution de police et chaque choix d’espacement exactement comme ils existaient au moment de l’exportation — il n’y a plus de recalcul possible pour qu’un prévisualiseur le fasse mal, car il n’y a plus de texte vivant à réorganiser. Si vous envoyez à quelqu’un susceptible d’ouvrir sur mobile — ce qui, pour tout ce qui atterrit dans une boîte de réception ou un fil de discussion plutôt qu’une invitation de réunion programmée, revient presque à une pièce sur deux — le PDF est la version qui arrive effectivement à lui avec l’apparence que vous avez construite. Deuxième vérification, moins coûteuse qu’elle n’en a l’air : ouvrez le fichier sur votre propre téléphone une fois avant de l’envoyer, même brièvement. Vous ne testez pas pour la perfection — vous testez pour le mode spécifique d’échec d’un titre qui passe à la ligne suivante ou d’une image qui chevauche un sous-titre, ce qui est visible en environ trois secondes et vous indique si la présentation nécessite une version PDF de secours ou non. --- **Où trois jours de travail auraient pu être mieux utilisés** La partie frustrante de ce mode d’échec est que rien de tout cela n’était une erreur de conception. La palette était bonne, la hiérarchie était bonne, le contenu était bon — trois jours ont été consacrés à des décisions qu’un prévisualiseur de téléphone n’évaluerait jamais sur ces termes. C’est là l’argument réel pour commencer une présentation à partir d’une structure déjà testée sous stress à travers les moteurs de rendu et les appareils, plutôt que de construire la tolérance d’espacement de chaque boîte de texte à partir de zéro sous la pression d’une échéance — [la plupart des heures d’un projet de présentation sont consacrées à ce genre de travail de mise en forme invisible](https://imaginelayout.com/blog/ready-made-business-presentations-save-20-hours), et non aux parties que quelqu’un se souvient avoir faites. Pour la prochaine présentation, avant qu’elle quitte votre boîte de sortie : exportez le PDF, jetez un œil dessus sur votre propre téléphone pendant trois secondes, et envoyez les deux fichiers. Le travail de conception que vous avez déjà effectué était bon. Assurez-vous simplement que la version qui atteint le pouce de votre supérieur est celle que vous avez réellement construite.