Pourquoi je ne publie pas mes slides (seuls)

Après une conférence, les organisateurs ou des membres du public me demandent régulièrement où mes slides sont accessibles. Et je réponds que je ne publie pas mes slides.

Mais pourquoi ?

Je conçois mes slides comme un support à mon discours, pas pour qu’ils se suffisent à eux-même. Et, donc, mes slides (seuls) ne sont pas d’un grand intérêt.

Souvent, je crée un slide pour illustrer mes propos. J’inclus des animations et je les joue en même temps que je parle, pour aider le public à comprendre à la fois en m’écoutant et en disposant d’un support visuel.

Par exemple, voici un slide que j’ai utilisé pendant un talk sur des techniques d’amélioration de la résilience d’une application :

Avec mon discours, vous sauriez que je parlais de plusieurs personnes consommant du café et faisant la queue devant la machine. Et qu’en préparant des cafés en continu, y compris en anticipant l’arrivée des utilisateurs, nous les servons plus rapidement et améliorons leur satisfaction¹.

En écoutant ce que je disais quelques minutes plus tôt et ce qui suit quelques instant après, vous aurez compris que ce que je dis illustre une amélioration pour un mécanisme de queuing entre applications.

Mais si j’avais partagé ce slide (seul), vous n’auriez pas la moindre idée du message que je cherche à transmettre !

Cet exemple vous semble exagéré ?
OK, j’admets, j’ai fait exprès de choisir un schéma un peu éloigné du message que je voulais transmettre.

Voici donc un second exemple, avec deux schémas qui illustrent plus directement ce dont je parlais. Ce slide est extrait d’un autre talk sur les systèmes distribués et la résilience applicative.

Lors que je montre ce slide, c’est en plusieurs temps.

La moitié du haut apparait tout d’abord, en plusieurs étapes animées alors que mon discours ressemble à ceci :

Quand on parle de microservices, on voit souvent une architecture qui ressemble à celle-ci, en haut de l’écran : une application dépend d’un service A, qui appelle un service B, qui dépend d’une base de données.

Sauf qu’avec une architecture comme celle-ci, si la base de données tombe en panne, l’application B tombe en panne… Et comme l’application A dépend de B, elle s’écroule elle-aussi et notre plateforme entière est dans les choux et nos utilisateurs ne sont pas satisfaits.

Cette architecture, en haut de l’écran, ce n’est pas une architecture microservices.

Ce que vous avez construit là, c’est un monolithe distribué, avec des composants fortement couplés qui dépendent les uns des autres. À travers le réseau, en plus.

La moitié du bas suit, elle aussi en plus étapes animées alors que je continue à parler :

Une vraie architecture microservices, c’est celle-ci, en bas de l’écran :

• Le service A ne dépend plus du service B, il ne l’appelle plus en synchrone.
• À la place, lorsqu’une donnée est modifiée au niveau du service B, celui-ci pousse un message dans une file/queue.
• Et A écoute les messages qui arrivent dans cette file, pour mettre à jour la donnée de son côté.

Oui, ça demande du boulot, pour mettre en place ce mécanisme de communication asynchrone. Et cela demande une base de données du côté de A, pour que ce service puisse stocker sa représentation locale de la donnée.

Mais si B s’écroule, A, qui n’en dépend plus, continuera à fonctionner. Et nos utilisateurs resteront satisfaits.

Et bien ceci, l’architecture en bas de cet écran, c’est une vraie architecture microservices.

Est-ce que, si j’avais partagé ce slide (seul), vous auriez deviné le message qu’il illustre ?

Tous mes slides ne sont pas des schémas, OK.
Qu’est-ce que ça donne pour un slide avec du texte ?

Et bien, en voici un exemple – et j’en ai beaucoup des comme ça, avec une jolie image et quelques mots :

Au moment où je projette ce slide, mon discours est le suivant :

Oui, c’est du boulot, ça change des choses.

En fait, c’est une architecture différente de celle à laquelle nous sommes habitué, qui peut ou non répondre à nos besoins — et, comme pour beaucoup de choix d’architecture, c’est plus facile d’y penser avant de commencer un projet que lorsqu’il est en prod et ne tient pas la charge ou est instable.

Cette fois, je l’admets, le texte affiché pourrait suffire à comprendre le plus gros du message principal.

Mais je reste convaincu que ce texte ne suffit pas à deviner tout ce que souhaitais transmettre. En particulier, la nuance de la dernière phrase du discours n’est pas écrite.

Mais ne pas diffuser mes slides (seuls) ne signifie pas que je ne partage pas après une conférence. Je sais que des membres du public voudront suivre certaines des idées dont j’ai parlé. Et il serait dommage que les personnes qui n’ont pas pu aller à une conférence ne puissent pas bénéficier de ces idées.

Mes talks sont souvent enregistrés, reproduisant à la fois mon discours et les visuels. Quelques exemples :

• Une application résiliente, dans un monde partiellement dégradé (re:Invent 2020)
• Comment nous réduisons l’augmentation de nos coûts AWS, Pascal Martin (AWS Community Day 2021)
• Comprenez comment PHP fonctionne, vos applications marcheront mieux (Forum PHP 2022)

➡️ Pour en découvrir plus : mes interventions en conférences et meetups.

Parfois, je rédige un transcript – pour chacun de mes slides, j’écris le discours qui l’accompagnerait si je présentais. En voici quelques-uns :

• Transcript de ma conférence « Notre environnement de développement n’est plus un bizutage ! » au Forum PHP 2016 Paris
• Transcript de ma conférence « Migration de 6play vers Le Cloud, retour d’expérience » à MixIT 2019
• Transcript de ma conférence « Préparez et donnez votre premier talk » à Sunny Tech 2022
• Transcript de ma conférence « Comprenez comment PHP fonctionne, vos applications marcheront mieux » au Forum PHP 2022

J’aime beaucoup ce format, qui permet de lire rapidement, de scanner, bien plus facilement qu’en vidéo. Par contre, ça prend beaucoup de temps² à rédiger.

Et donc, non, je ne partage pas mes slides (seuls).

Je l’ai fait pas mal de fois par le passé, parce que je pensais que c’était obligatoire ou pour faire comme les autres speakers. Ou parce que mes slides étaient plus lourds et ressemblaient parfois un peu trop à des slidocuments…

Mais, aujourd’hui, mes slides ne sont qu’un support et ne suffisent pas pour transmettre mon message.

Je préfére partager un transcript, quand j’ai le temps d’en rédiger un, ou partager une vidéo d’une de mes interventions où les organisateurs avaient prévu une captation.

Et j’encourage, autant que possible, d’autres speakers à faire comme moi : partager des enregistrements vidéo, rédiger des transcripts ou des articles de blog qui traitent du même sujet. Je pense que c’est bien mieux pour nos publics et nos communautés que juste partager des slides.

📘 D’ailleurs, c’est aussi ce que je dis dans mon livre « Préparez et donnez votre première conférence (quand ce n’est pas votre métier) ».