Quelqu’un vous envoie un message : *« Hey, peux-tu juste ajuster les couleurs du graphique en un clin d’œil ? »* Vous répondez oui, en estimant quinze minutes, vingt au maximum. Quatre heures plus tard, vous êtes coincé·e sur un maître de diapositive qui vous résiste, une police qui n’a mis à jour que la moitié du deck, et un doute grandissant : *« rapide »* n’était peut-être jamais le bon mot pour tout cela. Si cette séquence vous parle, vous n’êtes pas mauvais·se pour estimer. Vous décrivez simplement ce qu’est vraiment une « petite modification » une fois le fichier ouvert.

La demande de cinq minutes qui n’en est pas une

J’ai eu cette conversation exacte plus de fois que je ne peux compter, et elle commence presque toujours de la même manière : la personne qui demande a une idée de la modification bien plus réduite que la réalité. *« Juste déplace-le un peu »* suppose que l’objet se déplace en isolation. Ce n’est généralement pas le cas. Déplacer un graphique de deux centimètres, et vous déséquilibrez la grille d’alignement sur laquelle le reste de la diapositive était construite, ce qui signifie que la boîte de titre n’est plus alignée, ce qui implique que vous devez maintenant vérifier chaque autre diapositive qui réutilisait cette mise en page. La demande était une phrase. Le graphe de dépendances derrière elle ne l’était pas.

Ce qui rend cela difficile à expliquer pour un non-designer, c’est que rien de tout cela n’apparaît dans la demande. Personne ne dit *« veuillez aussi corriger les quatre éléments que ce changement va silencieusement casser »*. Ils voient simplement l’édition de surface et supposent que le reste du fichier est aussi flexible que la phrase qui le décrit.

Où passent réellement les quatre heures

Ce n’est pas qu’une impression — c’est mesurable, et les chiffres sont pires que ce que la plupart des gens imaginent. Une étude commandée par GfK sur l’utilisation de PowerPoint, citée par PresentationLoad, a révélé que sur environ 20 heures passées par mois à travailler dans cet outil, environ 8 heures sont consacrées à des étapes de mise en forme récurrentes plutôt qu’à la création de nouveaux contenus — mettre à jour des diapositives existantes, chercher le bon modèle, ajuster les graphiques et les diagrammes pour qu’ils correspondent à une charte graphique. Ce n’est pas de la création de contenu. C’est de l’entretien. Et l’entretien, c’est exactement la catégorie à laquelle appartient une « petite modification », ce qui explique pourquoi elle prend plus de temps qu’elle n’en a l’air.

D’après mon expérience, les quatre heures se répartissent environ comme suit : vingt minutes pour la modification visible elle-même, et le reste pour des choses que personne n’a demandées mais que la modification rend désormais nécessaires — vérifier l’héritage du maître de diapositives, rechercher parmi six variables de couleur presque identiques laquelle contrôle réellement cet élément, et confirmer que la correction n’a pas silencieusement brisé une diapositive trois sections plus loin qui partage la même mise en page. Aucune de ces étapes n’est optionnelle une fois commencé. Vous ne pouvez pas ignorer un désalignement sur la diapositive 14 simplement parce qu’il n’était pas mentionné dans le brief.

Le piège du « juste déplace-le de 2px »

Voici la partie qui surprend réellement les gens une fois que vous leur expliquez : plus la modification demandée est petite, plus cela tend à empirer, et non à s’améliorer. Une grande refonte est planifiée, discutée et budgétisée correctement — tout le monde s’attend déjà à ce qu’elle prenne du temps. Une petite touche, elle, n’a aucune de ces protections, donc quand il s’avère qu’elle touche cinq autres éléments, il n’y a aucun tampon prévu. Le problème n’est pas entre les changements « petits » et « grands ». C’est entre les changements qui ont été planifiés et ceux qui ne l’ont pas été, et les petites demandes sont presque jamais planifiées.

C’est là que cela fait le plus mal : les fichiers hérités — une présentation créée par quelqu’un d’autre, dans un modèle que vous n’avez pas conçu, utilisant un système de couleurs non documenté. Un léger ajustement de deux pixels dans votre propre fichier est effectivement rapide. Le même ajustement dans un fichier où trois personnes ont apporté des modifications locales non documentées au cours de la dernière année devient une enquête avant même d’être une correction.

Quand ce n’est pas vraiment un problème de design

Il est tentant de présenter tout cela comme un problème de compétences en design — de meilleurs raccourcis, de meilleurs plugins, d’une meilleure hygiène des fichiers — et les quatre heures se réduisent à vingt minutes. Cela reste vrai jusqu’à un certain point, puis cela ne l’est plus, car une partie significative du temps n’est pas passée à corriger le design — elle est passée à comprendre ce que *« corriger le design »* devait vraiment signifier. Une demande vague vous force à prendre plusieurs petites décisions avant même de commencer à éditer, et chacune de ces décisions est un endroit où vous pourriez être en train de construire la mauvaise chose pendant une heure avant que quelqu’un ne vérifie. Une structure de fichier plus rigide ne vous en sauvera pas. Seule une demande plus claire le fera, et c’est un problème de communication déguisé en problème de design.

Ce qui raccourcit réellement une « petite modification »

Aucune de ces difficultés ne signifie que les « petites modifications » sont un mythe — certaines le sont vraiment, et il est honnête d’être transparent sur lesquelles. Une correction reste rapide quand le fichier a une structure propre et cohérente dès le départ : un ensemble de maîtres unique, un système de couleurs unique, sans modifications locales abandonnées depuis six mois. C’est la condition réelle, et non *« si vous êtes suffisamment compétent »* ou *« si vous travaillez suffisamment vite »*. Je ne recommande pas de promettre un délai de livraison rapide sur un fichier que vous n’avez pas encore ouvert, peu importe à quel point la demande semble simple par message — ouvrez-le d’abord, puis donnez une estimation.

C’est aussi, pratiquement, là que commencer avec un modèle préconstruit plutôt qu’un fichier libre se justifie — une structure de maître cohérente signifie qu’une « petite modification » a plus de chances de rester vraiment rapide. C’est en partie pour cela que, lorsqu’une demande s’avère être une reconstruction d’un diagramme plutôt qu’un simple ajustement, utiliser un modèle de diagramme existant est souvent plus rapide que de le corriger manuellement. Et quand la conversation sur la « petite modification » se répète en permanence parce que la présentation de base n’a jamais été construite sur un système stable, c’est généralement le signal pour arrêter les patchs et la reconstruire correctement.

La prochaine fois que quelqu’un demande une « petite modification », la réponse honnête n’est pas *« oui, cinq minutes »* ou *« non, cela prendra une éternité »*. C’est *« laissez-moi ouvrir le fichier d’abord »* — parce qu’avant de savoir à quoi ressemble le fichier en dessous, vous n’estimez pas la modification, vous la devinez.