Louise Gazeau (Senior Product Designer) et Elise Naves (Product Manager) décryptent comment Pennylane a structuré son knowledge management dans un contexte d'hypercroissance. Ce live a été diffusé le 31 mars 2026 sur la chaîne TPC.
1. Contexte et enjeux
Pennylane en bref
Pennylane est l'OS financier des entreprises et des cabinets d'expertise comptable en France. La solution réunit la gestion financière, la tenue de la comptabilité et des services de paiement.
Trois tracks produit coexistent :
Le produit est profond sur trois axes : métier comptable, outils financiers, données sensibles. Les utilisateurs comptables utilisent l'outil 8 heures par jour.
Pourquoi le knowledge est critique
En 2024, Pennylane atteint le statut de licorne. L'équipe dépasse les 1 000 personnes. La connaissance est vitale pour toutes les équipes : product, support, sales.
Deux facteurs accentuent l'enjeu :
"Qui dit hypercroissance, dit également un enjeu fort d'accompagnement de nouveaux arrivants et être onboardés rapidement. Et on est remote first donc on propose du full remote partout en Europe. L'information asynchrone, ça doit être très très clair."
2. Le piège du knowledge en hypercroissance
Ce que Louise a trouvé en arrivant
Louise Gazeau rejoint Pennylane en juillet 2024. L'équipe compte environ 400 personnes. La structure est claire : méthodologie Shape Up, product documents, rituels établis. Mais en dehors de ce cadre, les problèmes s'accumulent.
Les symptômes identifiés
"J'avais des témoignages de PM, même de GPM, qui disaient qu'ils perdaient des semaines, même pas des heures, mais des semaines à chercher l'information. Ou des PM qui me disaient, je ne fais que cinquante pour cent de mon métier, parce que l'autre cinquante pour cent, je perds du temps."
La question à se poser avant tout
Est-ce que c'est vraiment un problème ? Louise insiste : poser la question est essentiel. Si personne n'assume que le désordre est accepté, il faut décider si on le règle.
"On sentait que ce n'était pas scalable. Le mot-clé, c'est vraiment la scalabilité aujourd'hui."
3. La micro-discovery
Construire le cas avant d'aller voir les execs
Louise mène une micro-discovery en parallèle de ses responsabilités squad. Objectif : construire un cas pour les execs. Elle pensait avoir deux ou trois pages à ranger. Ce n'était pas le cas.
La méthode
Le tip clé : s'entourer des bons sponsors
"Si je peux vous donner un premier tip, quand vous voulez mener ce genre d'initiative de knowledge, c'est de vous entourer vraiment de sponsors qui croient dur comme fer en votre projet."
Louise est dirigée vers les bonnes parties prenantes par sa manager Adèle. Adèle contacte Tancred, le CPO. La valeur Pennylane "trust is not earned, it's given" joue un rôle clé.
Le message aux execs
"Je leur ai dit, si on ferme les yeux sur les rôles transverses, les rôles ops, c'est de louper le coche et de générer beaucoup de frustration et surtout de ralentissement dans vos équipes."
Six mois s'écoulent entre la discovery et le recrutement de Luc, le knowledge manager. Ce délai inclut des initiatives de nettoyage et des automatisations Slack.
4. Le knowledge flywheel
Le postulat
La connaissance n'est pas un stock passif. Elle est devenue le moteur de l'infrastructure Pennylane. Tout part du terrain et alimente la conception jusqu'au lancement.
Le système comporte cinq grandes étapes.
Étape 1 : La capture des retours terrain
Les retours clients sont centralisés dans une base standardisée : les Qualitative Feedbacks.
Un système d'upvote évite les doublons. Des bots identifient si un sujet a déjà été remonté. Résultat : un feedback peut afficher 50 requêtes upvotées, signal immédiat de priorité.
Étape 2 : La squad homepage
Chaque squad dispose d'une page d'accueil qui centralise en un clic :
"En tant que PM ou Product Designer, on n'a plus vraiment à aller chercher l'information, elle est accessible en un clic."
Étape 3 : La phase Shape
Le product doc est nativement relié à la base de données fonctionnalités. Lors de la création du product doc, toute la documentation existante est automatiquement appelée.
Bonus : les qualitative feedbacks sont reliés à des fiches clients. Le PM dispose directement d'une liste d'utilisateurs qualifiés pour sa discovery.
Étape 4 : La phase Build et la communication
Passer un feedback en statut "Build" via un simple drag-and-drop notifie automatiquement toutes les personnes intéressées.
"Le knowledge, il est efficace quand il sert la communication qui est transparente et quelque part qui est un peu effortless."
Étape 5 : La release et les agents IA
À partir du product doc, le Product Announcement est généré directement. Il notifie les personnes intéressées et reboucle sur les channels Slack de release.
La documentation accumulée nourrit des agents conversationnels. Un bot analyse les questions posées dans Slack produit et répond avec précision.
"Le bot a été plus rapide que moi. Surtout, il a fait ma place aussi."
Les bots sont construits via Dust, en pivot avec la base de données Notion. Les outils IA changent en permanence.
5. Résultats concrets
Ce que mesure Luc après 6 mois de mission
Luc, le knowledge manager, récolte des réponses auprès de plus de 45 personnes. Le résultat le plus notable : le passage de "je ne fais pas confiance à Notion" à "documentation first thinking".
Plus de 12 bases de données ont été fusionnées. Les templates ont été nettoyés. Le change management a été mené squad par squad.
L'impact sur l'onboarding
Louise et Elise changent de scope. Le PM qui reprend une partie du scope arrive avec des questions précises sur les besoins comptables, après avoir parcouru seul la documentation.
"On est passé de passer des heures de product tours pour transmettre de l'information à aujourd'hui, deux fois une heure de Q&A. Et en général, on parle vision dans ces moments-là."
L'impact quotidien
Créer un ticket de feedback ne nécessite plus de savoir quelle squad est responsable. La fonctionnalité est renseignée, tout est automatiquement routé.
6. Les pièges à éviter
Outiller pour outiller
Pennylane a introduit les dashboards Notion lors d'une mise à jour. Implémentés dans les pages des squads, ils se sont révélés peu utiles.
"Il faut vraiment se poser la question comme bon product people du pourquoi d'une nouvelle feature et pourquoi on l'implémente et pour quels objectifs, parce que sinon ça fait partie du change, il peut y avoir un peu de résistance si on commence à tout modifier tout le temps."
Documenter pour documenter
L'équipe a voulu une base de données de testing scenarios, ultra détaillée. Résultat : non scalable, impossible à réutiliser en QA.
"On était rentrés dans un niveau de détail qui était beaucoup trop précis pour que ce soit actionnable quelque part."
Négliger la communication interne
Trop de changements trop rapidement perturbent les équipes. À chaque modification, se poser la question : est-ce qu'on communique ? Comment ? Dans quelle chaîne ?
Le knowledge council : ce qui a fonctionné
Luc a rassemblé les personnes qui croyaient dans le sujet. Engineering managers, data, product designers, PM anciens et nouveaux. Réunion chaque lundi, en mode squad.
La règle donnée à Luc : si tu fais quelque chose et qu'il n'y a aucun bruit, c'est qu'on te fait confiance. C'est quand les plaintes arrivent qu'il faut se poser les questions.
7. Replay du live
Live animé par TPC avec Louise Gazeau et Elise Naves (Pennylane) · 2026