Pourquoi le deck récurrent est la pire demi-journée du cycle
Chaque rituel d'entreprise a son deck. La revue de pipeline a le sien, le QBR a le sien, le comité mensuel a le sien. Et à chaque cycle, quelqu'un rejoue exactement la même séquence : exporter les chiffres, les recopier dans les slides, refaire les graphiques, vérifier que rien n'a bougé entre l'export et la réunion.
Cette production n'a aucune valeur. Personne n'a jamais été félicité pour avoir bien recopié un pipeline dans un tableau. Mais elle a un coût réel : elle se fait souvent la veille, dans l'urgence, et c'est précisément dans ce geste de recopie que naissent le chiffre périmé et la coquille qu'on découvre en pleine réunion.
Le réflexe courant consiste à demander à un chat de « faire le deck ». Vous obtenez des slides plausibles, avec des chiffres que le modèle n'a jamais vus, donc inventés ou approximatifs. C'est du niveau 1 : un coup de main ponctuel, rien qui tourne, et un risque réel de présenter un chiffre faux à une direction.
Séparer les données du narratif : la règle qui rend le deck automatisable
Un deck récurrent contient toujours deux choses de nature différente, et c'est en les séparant qu'on peut l'automatiser proprement. C'est la même logique que pour le reporting commercial récurrent, dont le deck est souvent la partie visible.
Les données : à tirer de la source, jamais à recopier
Les chiffres du deck existent déjà quelque part : dans le CRM, dans l'outil de ticketing, dans la base analytics. Toute recopie manuelle entre cette source et la slide est une étape de dégradation : elle coûte du temps et elle introduit des erreurs. Un système bien monté va chercher les chiffres à la source au moment de la génération, les met en forme, et les pose dans la slide. Si le chiffre est faux, il est faux dans la source, et c'est là qu'on le corrige.
Le narratif : ce que l'humain doit garder
L'analyse, la lecture des écarts, les décisions à proposer : c'est la partie du deck qui justifie la réunion. Elle ne s'automatise pas de la même façon. Un modèle peut préparer un premier commentaire à partir des chiffres, signaler qu'un indicateur décroche, formuler une hypothèse. Mais la validation de ce narratif reste humaine, parce qu'une erreur d'interprétation passerait inaperçue jusqu'à la réunion, au pire moment.
le test reste le même : si une erreur du modèle passerait inaperçue, ne lui confiez pas cette étape
Le gabarit stable : la condition que tout le monde saute
L'automatisation d'un deck ne casse presque jamais sur la technique. Elle casse sur le gabarit. Si la structure des slides change à chaque cycle, une slide ajoutée ici, un graphique déplacé là, le système passe son temps à courir après le format, et quelqu'un finit par reprendre la main « juste pour cette fois ».
Un deck récurrent automatisable, c'est un contrat : les slides de données ont une structure fixe, écrite une fois pour toutes, et cette structure ne bouge qu'en changeant le gabarit lui-même, pas en retouchant le deck du mois. Cette discipline est le vrai coût d'entrée, et elle a un bénéfice caché : un format stable rend les cycles comparables entre eux, ce qu'un deck refait à la main ne garantit jamais.
Comment monter la chaîne, concrètement
- Prenez un seul deck, le plus douloureux, celui qui revient le plus souvent. Pas trois.
- Listez slide par slide ce qui est donnée (à automatiser) et ce qui est narratif (à garder humain). Chez moi, cette cartographie prend une heure, et elle décide de tout le reste.
- Figez le gabarit des slides de données avec les personnes qui présentent. C'est une décision d'équipe, pas un détail technique.
- Branchez la génération : un script planifié tire les chiffres de la source, les pose dans le gabarit, et produit le deck du cycle. Google Slides et PowerPoint s'y prêtent bien, les deux se pilotent par programme.
- Ajoutez le pré-commentaire par l'IA en aval, clairement marqué comme brouillon à valider : un premier jet de lecture des écarts, que le présentateur corrige ou remplace.
- Écrivez le mémo : ce que la chaîne fait, où elle tourne, quoi faire quand elle casse. Un système que seul son auteur comprend meurt à son premier départ.
Un exemple qui tourne : le deck de suivi commercial généré depuis le CRM
J'ai monté ce système dans mon propre métier, pour le deck de suivi commercial récurrent. Avant : une demi-journée estimée par cycle à exporter, recopier, remettre en page. Après : les chiffres viennent du CRM, les gabarits sont écrits une fois, le deck se régénère à la demande, à jour au moment où on l'ouvre.
Ce qui m'a le plus surpris n'est pas le temps récupéré, c'est le changement de posture. Quand le deck se fabrique seul, le temps de préparation part dans l'analyse au lieu de la mise en page. Chez moi, la réunion a changé de nature : on n'y vérifie plus des chiffres, on y prend des décisions.
Ce que ça change pour un QBR ou une revue de compte
Le QBR est le cas d'école, côté customer success cette fois : un deck par client, une structure identique, des données qui existent toutes dans les outils. C'est exactement le profil du candidat idéal : récurrent, stable, descriptible. Une équipe CS qui prépare ses QBR à la main rejoue cette fabrication pour chaque compte, chaque trimestre, et c'est du temps pris sur la relation client elle-même.
La version automatisée inverse le rapport : chaque deck arrive pré-rempli avec les données du compte, et le CSM y ajoute ce que personne d'autre ne peut écrire, la connaissance du client, les signaux faibles, la recommandation. Le deck redevient un support de conversation au lieu d'être une corvée de fabrication.