Le slide que personne n’a su lire
En janvier 2003, un bloc de mousse isolante percute l’aile gauche de la navette Columbia lors du lancement. L’impact est observé par les caméras de la NASA. Des ingénieurs de Boeing sont chargés d’évaluer les dégâts potentiels. Ils produisent 28 slides PowerPoint sur le sujet. Sur l’un d’entre eux, le plus important, le titre suggère que les dommages sont gérables, les puces s’empilent sur six niveaux de profondeur et l’information critique, à savoir que les conditions réelles dépassent les paramètres de test par un facteur 640, se trouve enfouie au dernier niveau, en petits caractères, noyée dans un vocabulaire volontairement imprécis.
Les managers de la NASA lisent ces slides et concluent que la navette peut revenir sans risque. Le 1er février 2003, Columbia se désintègre lors de la rentrée atmosphérique. Sept astronautes perdent la vie.
Edward Tufte, professeur émérite à Yale et praticien reconnu de l’information design (la discipline qui étudie la mise en forme des données pour en faciliter la compréhension), a disséqué ce slide dans un essai devenu référence. La CAIB (Columbia Accident Investigation Board, la commission d’enquête indépendante) a conclu que «l’usage endémique de slides PowerPoint à la place de rapports techniques illustre les méthodes problématiques de communication chez NASA». Le slide n’a pas causé l’accident, mais il a contribué à la décision qui l’a rendu fatal.
Un problème structurel, pas cosmétique
Il serait tentant de réduire le problème à un slide mal fait. Mieux formater les puces, choisir des mots plus précis, mettre le chiffre critique en gras, et le problème disparaît. Cette lecture est insuffisante.
Le problème identifié par Tufte est structurel. Le format slide impose des contraintes cognitives qui affectent la qualité du raisonnement: espace limité qui pousse à la compression, hiérarchie en puces qui crée une fausse taxonomie, absence de syntaxe complète qui autorise l’ambiguïté. Un slide n’est pas un document dégradé: c’est un format différent, adapté à certains usages et inadapté à d’autres.
L’usage auquel il est le moins adapté est précisément celui que la NASA en faisait: servir de document d’analyse technique autonome, lu sans présentation orale, sur lequel des décisions à haut enjeu sont prises. En gestion de projet, cette situation a un nom: le comité de pilotage (copil) qui reçoit un deck de slides par email la veille de la réunion et prend ses décisions sur cette base.
Le copil et le deck: un rituel à interroger
La plupart des organisations fonctionnent sur un modèle implicite: le chef de projet prépare un jeu de slides, le présente en copil, les décideurs valident ou arbitrent. Ce modèle pose deux problèmes rarement questionnés.
Le premier est que le slide devient souvent le compte rendu de fait. Après la réunion, c’est le deck qui circule, pas un procès-verbal structuré. Les décisions prises oralement sur la base d’un contexte partagé en réunion sont ensuite relues à travers des puces qui ne capturent pas ce contexte. Le PMI insiste sur le fait que la communication des risques aux parties prenantes nécessite une attention spécifique à la clarté du message transmis.
Le second problème est que le format slide favorise la posture plutôt que l’analyse. Un chef de projet sous pression a structurellement intérêt à présenter un slide «propre» avec des indicateurs au vert plutôt qu’un document textuel qui expose les tensions, les incertitudes et les arbitrages nécessaires. Le slide, par sa concision forcée, permet de passer sous silence ce qui demanderait une explication détaillée.
Ce n’est pas de la malhonnêteté: c’est un effet du format. Les ingénieurs Boeing n’ont pas cherché à tromper la NASA. Ils ont produit un livrable dans le format attendu, et ce format a mécaniquement atténué la gravité de leur message.
Qu’est-ce qu’une escalade fidèle?
L’escalade (escalation) est le mécanisme par lequel un chef de projet remonte un risque ou une décision à un niveau hiérarchique supérieur. C’est un acte de gouvernance fondamental. Mais la littérature en gestion de projet traite abondamment du «quand escalader» et du «quoi escalader» sans s’attarder sur le «comment».
Le «comment» inclut le choix du format. Un risque critique présenté dans une puce de troisième niveau au milieu de 15 slides de suivi d’avancement n’a pas le même impact qu’un paragraphe dédié dans un mémo d’une page. Le contenu est identique; la probabilité que le décideur saisisse la gravité de la situation ne l’est pas.
L’exception report (rapport d’exception) offre un modèle utile. Utilisé dans les référentiels PRINCE2 et PM², ce document est déclenché quand une tolérance de projet est dépassée. Il décrit l’écart constaté, son impact sur les objectifs du projet et les options de réponse, le tout en phrases complètes qui imposent un raisonnement explicite. Sa vertu principale est qu’il sépare l’information critique du bruit quotidien: un exception report signale par son existence même que quelque chose d’important se passe.
Repenser le format selon l’enjeu
La proposition n’est pas de bannir les présentations visuelles des projets. Elles restent adaptées pour une revue d’avancement de routine, un point d’équipe ou une présentation de cadrage. La proposition est d’appliquer un principe simple: plus l’enjeu de la décision est élevé, plus le format doit imposer la rigueur du raisonnement écrit.
Pour une revue d’avancement standard, un dashboard visuel avec quelques slides de commentaire suffit. Pour un risque majeur qui nécessite un arbitrage du sponsor, un document textuel d’une à deux pages, rédigé en phrases complètes, avec les données en contexte, est plus approprié. Pour une situation d’exception où les tolérances sont dépassées, un exception report formel s’impose.
Amazon a institutionnalisé ce principe avec le mémo de six pages: toute réunion de décision commence par la lecture silencieuse d’un document rédigé en prose. L’idée sous-jacente est que l’effort de rédaction force l’effort de pensée, et qu’un auteur qui doit formuler son raisonnement en phrases complètes ne peut pas se cacher derrière l’ambiguïté d’une puce. Le chef de projet qui choisit le format dans lequel il transmet une information critique prend une décision de gestion des risques, qu’il en ait conscience ou non, et traiter ce choix avec le même sérieux que l’analyse du risque elle-même relève de la rigueur professionnelle.