La licorne française a ouvert ses portes au Ticket pour lever le voile sur son étonnante philosophie managériale inspirée des principes développés par Toyota dans les années 1960. Reportage au sein de cette machine de production radicale qui mise sur l’apprentissage plutôt que sur les process pour passer à l’échelle.
⌛ 20 min de lecture en flux tendu
✉️ Article issu du Ticket n°053
| Le Ticket, c’est le média spécialisé du Product Management. Abonne-toi à la newsletter gratuite envoyée tous les 15 jours ! |
Sommaire de l’article :
- Principe 1. Le Jidoka (ou Right first time) : l’auto-qualité
- Principe 2. Le juste-à-temps (ou flux tirés) : une organisation sans roadmap ni backlog
- Principe 3. Le challenge permanent : la gestion par les échéances
- Principe 4. Les Gemba : des managers sur le terrain
- Principe 5. Le Dojo : une organisation auto-apprenante
Il y est question de “pièce”, de “supermarché”, de “bac rouge”. Mais aussi de “Gemba”, de “Kaizen” ou de “Andon”. Nous ne sommes pas dans une usine japonaise mais bien dans les bureaux flambant neuf d’une entreprise numérique bien connue de l’écosystème tech : Qonto.
Le silence règne dans les vastes open space de la licorne française (créée en 2016 et valorisée 4,4 Mds € en janvier 2022), situés dans un WeWork à quelques pas de Pigalle, dans le 9e arrondissement de Paris. Bien loin de l’ambiance sonore d’une chaîne de fabrication du constructeur automobile Toyota. Pourtant, les principes de production y sont quasiment les mêmes.
Le spécialiste de la gestion financière des entreprises s’est en effet inspiré des grands principes du toyotisme pour répondre aux deux enjeux majeurs qu’une scale-up vit dans sa phase de passage à l’échelle : grandir tout en continuant de produire rapidement et avec le même niveau de qualité. Et ce, jusque dans le vocabulaire employé.
“Une fonctionnalité, c’est une pièce. Une pièce défaillante, elle se retrouve dans un bac rouge. Et ainsi de suite. C’est sûr que ça fait bizarre au début mais ça vient assez vite”, sourit Marc-Antoine Lacroix, dit “Marco”, son Chief Product Officer.
Avant de détailler concrètement 5 grands principes de cette organisation qui fait la part belle à l’amélioration continue et à l’apprentissage des équipes, faisons une petite marche arrière. Jetons un œil au rétroviseur afin de comprendre d’où vient ce modèle atypique (jamais vu ?) dans la tech.
Retour aux sources japonaises
Pour ce faire, reprenons le cheminement de Marc-Antoine, l’un de ses grands instigateurs. Après ses études, il lance et revend une boîte, en foire une autre puis en rejoint une troisième en tant que CTO, avant d’être embauché par une société de coaching spécialisée dans le lean (Keenly).
“Dans mon parcours, je me suis toujours intéressé aux façons de réussir à scaler une équipe tech et produit tout en restant efficace. À chaque discussion avec des autres CTO ou fondateurs, les mêmes éléments revenaient sans cesse : on a triplé la taille de l’équipe et on shippe deux fois moins qu’auparavant…”, confie-t-il, avec son débit mitraillette.
Les méthodos agiles ? Pas mal… mais ça ne scale pas selon lui. “Tu dois mettre de plus en plus de force pour faire respecter la méthode, avec l’embauche de Scrum masters ou de coachs agiles, les équipes appliquent les règles sans forcément les comprendre et cela se termine toujours en bureaucratie. Peu importe le type d’organisation, on reproduit naturellement toujours ce modèle”, estime-t-il.
Il se lance alors dans une quête : retrouver l’origine même du Scrum ou du Kanban, afin d’en comprendre les raisons d’être originelles. Il découvre alors qu’il ne s’agit en réalité que d’une version “rebrandée” du TPS, le Toyota Production System. Un modèle formalisé à partir des années 1950 par Taiichi Ohno, un ingénieur du constructeur japonais. Marco (oui, on se la joue intime) commence alors à lire des bouquins industriels et à visiter des usines de médicaments, de frigos ou de montres en France et en Suisse. Et va même au Japon rencontrer des fournisseurs de Toyota, avec son “Sensei” (= son maître Jedi), Régis Médina, cofondateur de Keenly et pionnier du lean IT en France.
“Certes, la tech n’est pas une usine. Mais on produit aussi quelque chose. Il faut donc faire la gymnastique intellectuelle entre les deux mondes pour voir ce qu’on a à apprendre d’eux et ce qui n’est pas réplicable. Sachant que les règles d’un système de production avec des personnes, au final, ce sont les mêmes, quel que soit ce que tu produis”, retient-il.
Passionné du sujet, il coach alors des dirigeants en les sensibilisant à ces principes. L’un d’eux, Clément Ravouna, CEO de Tanker, startup rachetée en janvier 2022 par Doctolib, le met en relation avec Steve Anavi, le cofondateur de Qonto (qui a, pour l’anecdote, étudié au Japon). Une rencontre qui va changer leur destin et celui de la boîte. “Je vois que cela fit bien et surtout que l’entreprise a un potentiel bien largement supérieur à la norme…”, commente Marco.
Après quelques mois de travail ensemble, Steve lui propose de rejoindre l’aventure en tant que CTO. Nous sommes en 2018, la boîte compte à peine une cinquantaine de personnes.
“Ce n’était pas prévu au départ… mais c’était une chance d’inventer et de mettre en pratique à l’échelle un système différent dans la tech avec un fondateur qui soutenait pleinement la démarche”, affirme-t-il.
Qonto rassemble aujourd’hui 1 000 employés (dont 300 à la tech et 150 au produit), plus de 300 000 clients en Europe (France, Allemagne, Italie et Espagne) et a signé l’an passé (quand c’était un peu plus la fête du slip chez les investisseurs) une levée de fonds record de près de 500 M€.
Un système d’apprentissage plutôt qu’une méthode
Février 2019. Dans un article Medium diffusé sur le blog de l’entreprise, Steve Anavi fait pour la première fois officiellement référence à l’inspiration toyotiste. Voici ses premiers mots :
“Aux débuts de Qonto, nous passions 80 % de notre temps à créer de la valeur pour les clients. Jusqu’à progressivement passer 80 % de notre temps à retravailler ce que l’on sort et à gaspiller notre énergie pour faire en sorte que les choses soient faites. Nous appelons cela lutter contre le système. Il y a environ 10 mois, nous avons commencé à réfléchir à la manière dont nous devrions résoudre ces problèmes en changeant notre style et nos pratiques de gestion, avec une question à un milliard de dollars : comment livrer rapidement de la qualité à mesure que nous nous développons tout en créant un environnement de travail stimulant et bienveillant ? La réponse tient en deux mots simples : Le développement des équipes (People development). C’est la voie secrète et c’est devenu la recette secrète de Qonto”.
Avant de conclure, après une petite description du TPS : “Pour Taiichi Ohno, le TPS ne pouvait fonctionner que si l’entreprise était prête à impliquer chaque membre de l’équipe dans une réflexion sur la façon dont il travaille. Sans cela, le TPS ne serait juste qu’un énième framework supplémentaire de productivité.”
On le verra plus tard mais, contrairement à ce que l’on nous a enseigné à l’école, le toyotisme est en effet moins une méthode qu’un système d’apprentissage. C’est un investissement sur les personnes plutôt que sur les process.
Un mois plus tôt, Marco, qui deviendra Chief Product Officer l’année suivante, avait allumé la mèche avec un article sur le Kaizen (改善) spirit. C’est à cette occasion qu’on voit apparaître pour la première fois la mention The Qonto Way, en hommage à The Toyota Way, l’ouvrage managérial de référence sur le sujet.
De l’équipe Tech & Product, la philosophie lean se répand progressivement à toute l’entreprise. Qonto embauche même un ancien de Toyota en tant que Chief Operating Officer et des lean masters d’usine pour concevoir leurs systèmes de formations internes !
Thomas Vuchot, 1er PM de la boîte en 2017 (tu te rappelles de notre article sur le sujet ?) se souvient de ce basculement : “The Qonto Way n’a pas été décrété du jour au lendemain. C’est progressivement devenu un élément de la culture d’entreprise”.
5 principes qui font de Qonto une organisation si différente des autres
Voilà pour la mise en contexte historique. Intéressons-nous désormais aux fondamentaux concrets de l’orga de Qonto. Comme nous n’avons pas vocation à écrire un livre sur le sujet (on vient à peine de finir notre 1er Roadbook 😅), on va se concentrer sur 5 grands principes.
Principe 1. Le Jidoka (ou Right first time) : l’auto-qualité
Commençons par l’un des deux piliers du système de production de Toyota (avec le juste-à-temps), que l’on pourrait résumer trivialement en “produire vite et bien”.
Aussi appelé autonomisation, le Jidoka consiste à arrêter le travail dès qu’un problème survient, afin d’éviter de produire des éléments défectueux (stop-and-fix). Dans une usine, cela se traduit par exemple par la présence d’une cordelette, appelée Andon, que doit activer chaque ouvrier pour alerter d’un dysfonctionnement. Le ou la responsable d’équipe intervient alors pour essayer de résoudre le problème. Si cette personne n’y arrive pas et en dernier recours, c’est toute l’usine qui est arrêtée le temps de trouver la solution !
Une extrémité qui n’est pas encore arrivée chez Qonto.
“On n’est pas aussi radical car on n’est pas aussi bon !”, sourit Marco. “Mais on a des Andon. Moi, si quelqu’un m’écrit “Andon”, je vais l’aider tout de suite, même si je suis en réunion !”
Steve Anavi évoquait cette pratique dès février 2019 dans cet article. “En plus de bâtir une équipe plus efficace, le Andon permet de développer un lien fort avec le management, qui s’engage à réagir vite et à aider. Cela s’appelle la confiance avec un C majuscule”, écrivait-il.
Conséquence : il n’y a pas de testeur QA (assurance qualité) chez Qonto. “Chacun·e est responsable de sa propre qualité. Pour éviter de passer par des phases de rework, on veut que les pièces soient bien faites dès le premier coup”, assure Marco.
“C’est un concept qui est hyper important mais très dur à assimiler. Surtout quand tu arrives dans la boîte : tu veux montrer que tu es fort·e donc tu ne veux pas appeler à l’aide,” témoigne Thomas Vuchot. Avant de poursuivre : “3 Andon valent mieux que 1 Red bin.”
Traduction : ce “bac rouge”, c’est le réceptacle des pièces défectueuses dans une usine. Loin de n’être qu’une simple poubelle, c’est l’endroit où l’on analyse scrupuleusement ce qu’il s’est mal passé… et comment ne plus avoir ce type de problème à l’avenir. Une spec’ qui n’est pas au niveau de qualité ou qui ne marche pas ? Red bin ! Un gâchis que cherche sans cesse à éliminer la philosophie toyotiste.
“Un des principes clés du lean, c’est de faire ressortir les problèmes. Vouloir tout le temps regarder ce qui ne va pas. Certes, ça peut piquer, mais il faut plutôt le voir comme une manière de s’améliorer en continu”, atteste Marco. Taiichi Ohno avait coutume de dire que le plus grand des problèmes, c’est de ne pas avoir de problème !
Principe 2. Le juste-à-temps (ou flux tirés) : une organisation sans roadmap ni backlog
Voici le deuxième pilier du TPS, sûrement le plus connu. On parle aussi de “flux tendu”.
C’est le premier principe que Marc-Antoine a mis en place en arrivant chez Qonto (et dont il parle dans cet article). Il repose d’une part sur le concept de “1-piece-flow” : aucune personne ne travaille sur deux tâches à la fois. Et d’autre part sur les flux tirés. Explications.
Disons que nous sommes dans une usine de téléphones. Une personne s’occupe des coques et une autre des vitres. En flux poussés, la première va fabriquer dans son coin, sans se soucier du rythme de l’autre. Si elle est plus rapide, elle va donc constituer un stock… ce qui est mal !
“C’est comme chez Mcdo, quand les racks de burgers sont pleins, les salariés arrêtent d’en faire, sinon, ils ne seront plus bons lorsqu’ils seront distribués. On a l’impression de créer de la valeur car on travaille, alors qu’en réalité, on en détruit. Cela peut paraître contre-intuitif mais tu crées plus de valeur en t’arrêtant de travailler”, illustre Marco.
Application concrète chez Qonto : quand une fonctionnalité est prête à être développée, le ou la PM ne se lance pas sur la suivante et arrête de travailler. Autrement dit, pas plus d’une fonctionnalité en stock ! Interdiction de commencer autre chose, c’est-à-dire de faire les specs de la prochaine fonctionnalité… tant que le “supermarché” n’est pas rempli. Le supermarché, ce sont les équipes disponibles pour travailler sur une fonctionnalité.
Voilà comment cela se passe : les dev’ disent, grâce à un management visuel efficace, qu’ils vont être disponibles, disons, le 8 janvier. Le temps de finir de développer leur précédente fonctionnalité voire de nettoyer un peu leur code avant de repartir sur un autre sujet. Si tout le reste de l’équipe est dispo le 8 janvier, alors une réunion de kick-off est organisée pour commencer le travail de la prochaine fonctionnalité. Et si des personnes sont dispo avant ? Elles peuvent faire ce qu’elles veulent (dans le cas des PM : entrevues utilisateurs, analyse de succès, formation etc.) sauf avancer sur ladite fonctionnalité !
Pourquoi ? Pour 3 raisons selon Marc-Antoine :
1) L’obsolescence
“On est dans un environnement tellement évolutif, avec 400 personnes qui bossent sur le système, que tu peux être sûr que des specs restées dans un backlog plus de deux mois sont entièrement bonnes à refaire”.
2) La déperdition d’informations
“De la même façon, si tu vas voir la personne qui a fait la discovery d’un sujet il y a plus de 3 mois, elle ne s’en rappellera plus donc tu casses la possibilité d’apprentissage”.
3) La pression latente sur les épaules des devs
“La plupart du temps, les devs sont en train de bosser sur une fonctionnalité, il y en a trois autres qui les attendent dans le backlog, et les PM leur posent des questions sur la 4e en préparation, alors qu’ils sont déjà en retard. On marche sur la tête !”
“Cela apporte de la stabilité à l’équipe”, indique Steve Anavi dans cet article. “À un moment, on n’avait pas assez d’UX Writers dans l’équipe, j’ai attendu une semaine pour démarrer une nouvelle fonctionnalité !”, confirme Eduardo (Dudu) Rocha, Lead PM, arrivé du Brésil en 2021.
Pour l’anecdote, c’est de là que vient le terme de Kanban, qui veut dire petite fiche cartonnée en japonais. Tu prends une pièce pour la produire et tu la remplaces par cette fiche qui va être le signal aux équipes en amont de la chaîne qu’elles peuvent s’y remettre.
“C’est souvent assez dur à comprendre quand tu ne l’as pas vu, mais, avec les flux tirés, tu as tout qui va aller deux fois plus vite. Car, en général, on a tendance à se focaliser juste sur ce qui est produit mais pas sur le gaspillage généré autour, affirme Marco. Tes équipes vont arrêter de surproduire et construire juste ce qui est nécessaire”.
Conséquence logique : plus de backlog chez Qonto. Les équipes travaillent en flux tendu “comme les cuistots dans un restaurant”, écrit Marc-Antoine dans l’article “Shipping fast is your product strategy” (qui n’a pas laissé indifférent dans l’écosystème, loin de là).
Ni backlog ni roadmap ! “Elle ne sert à rien tellement les choses évoluent vite, si ce n’est à apporter de la sérénité aux autres équipes. Ma roadmap du dernier trimestre, je l’ai faite juste en 15 minutes en indiquant les grosses pièces sur lesquelles on était en train de travailler”, souffle Marco. Qui, dans l’article ci-dessus, disait : “Beaucoup d’équipes produit réfléchissent trop à leur roadmap et se retrouvent dans un cycle de réflexion sans fin pour savoir si elles travaillent sur le bon sujet ou non, passant des jours à dé-prioriser et re-prioriser les sujets, au lieu de les shipper”.
Là encore, ce principe permet de se rendre compte rapidement et facilement des retards et donc des problèmes.
“Si tu vois cela comme juste quelque chose qui génère de la productivité, tu te plantes ! La vraie valeur du flux tiré, ce sont les pistes d’apprentissage que cela fait émerger. Tu crées les conditions pour que les équipes voient les problèmes et utilisent leur cerveau pour les résoudre. On n’a pas plus de problèmes que les autres, c’est juste qu’on fait tout pour qu’ils remontent à la surface », ajoute-t-il.
Principe 3. Le challenge permanent : la gestion par les échéances
Spoiler : ce principe va faire réagir.
On l’a vu, un des maîtres mots de cette philosophie, c’est l’amélioration continue. Continue… et infinie ! “Si tu ne te dis pas que c’est une utopie, tu es perdu. Mais si tu ne te dis pas que c’est un objectif, tu es perdu aussi !”, déclare Marco. Subtil équilibre.
Illustration. “C’est incroyable à quel point ils ont décortiqué finement le métier de PM pour le processer et l’inscrire dans un système”, remarque un PM croisé dans les bureaux de l’entreprise. Exemple : la phase de discovery d’une nouvelle fonctionnalité, c’est 5 jours ! Pas plus, pas moins. Peu importe la fonctionnalité en question, c’est le standard défini chez Qonto. Il y a certes des exceptions (nouveau produit ou grosse fonctionnalité) mais à la marge.
“Cela oblige les gens à utiliser leur cerveau. Au début, les PM venaient me voir en me disant : “Mais les utilisateurs ne sont pas disponibles cette semaine…”. Ma réponse : il faut donc trouver un moyen de les joindre en 5 min”, révèle Marco. Avant d’apporter une nuance toutefois : “Si tu n’y arrives pas en 5 jours, ce n’est pas grave. C’est juste un standard fait pour se poser la question : si on a pris plus de 5 jours, sait-on l’expliquer ? Qu’est ce qu’on a à apprendre ? Et peut être que la réponse c’est : on n’a rien à apprendre, c’était juste une pièce trop grosse”.
Comme l’explique Thomas Vuchot dans cet article, Qonto a ainsi développé ses propres standards pour aider ses équipes à apprendre à devenir plus efficaces, et respecter les échéances (standardisées, elles aussi). Voici par exemple leur standard pour écrire une bonne spec.
“Tous les jours, je commence ma journée en regardant les échéances du Kanban. Dès qu’il y a un retard, on essaie de comprendre pourquoi pour apprendre et s’améliorer”, partage Eduardo. Qui se rappelle qu’à son arrivée, la discovery se faisait en une vingtaine de jours. “Un jour, Marco nous a dit : maintenant, on va la faire en 5 jours. On s’est tous regardé étonné. Et il a poursuivi : et quand vous réussirez, on le fera en 4 jours !”
Des propos que Marc-Antoine a repris lors de sa conférence au Web2Day, à Nantes, le 2 juin 2022 :
“Si tout le monde arrive à tenir ses échéances, on pourrait se dire : cool, on livre à temps. Non ! À ce moment, en tant que manager, il faut dire : on va diviser l’échéance par deux désormais”. Avant de préciser devant une salle médusée : “Il ne faut pas le voir comme un outil pour aller plus vite. L’idée, c’est de créer un environnement de challenge pour voir les problèmes et apprendre à la personne à aller plus vite et être meilleur dans son travail”.
En gardant à l’esprit que, chez Qonto, une pièce n’est pas finie quand elle est produite mais quand elle atteint ses indicateurs de succès définis au préalable. L’outcome plutôt que l’output. Même si Marc-Antoine n’est pas un grand admirateur de cette distinction :
“C’est une complexification marketing inutile. Si tu as shippé une fonctionnalité qui n’a pas atteint le succès, tu n’as pas shippé une fonctionnalité. Si tu as shippé une voiture qui n’a pas de roues, tu n’as pas shippé une voiture. Point. Pas la peine d’en faire des tartines dessus. La question n’est pas quand tu as commencé mais plutôt quand est-ce que tu as fini au bon niveau de qualité”.
Et si l’objectif semble inatteignable après les premières itérations ? “On ne s’acharne pas, bien entendu. Il ne faut pas être dogmatique”, relativise-t-il.
Principe 4. Les Gemba : des managers sur le terrain
Le Gemba a été inventé par Taiichi Ohno. Un jour, ce dernier prend les managers d’une usine pour les emmener sur la chaîne de production et délimite à la craie des ronds derrière les ouvriers. Il leur dit : “vous les regardez et vous ne sortez pas de ce cercle tant que vous n’avez pas trouvé comment les aider”.
Chez Qonto, les cercles ont disparu mais pas la pratique. Chaque manager consacre ainsi plusieurs heures par semaine au Gemba.
“J’ai 5 sessions individuelles d’une heure toutes les semaines avec des PM de mon équipe, note Eduardo. C’est différent des réunions “one on one” où l’on parle RH et carrière. L’objectif ici, c’est de regarder une pièce et de résoudre une difficulté ensemble”.
“L’oeil gauche sur le problème, l’oeil droit sur la personne : l’idée, c’est de faire ensemble et de lui apprendre le bon geste, explique Marco, qui en fait lui-même une quinzaine d’heures hebdomadaires. Pour scaler, il ne faut pas penser au scale, il faut résoudre tous les jours des problèmes sur le terrain”.
Ce jour-là, un PM montre à Eduardo le message envoyé aux utilisateurs dont la carte bancaire arrive à expiration bientôt. Son sujet de mail ? “Votre carte expire bientôt”. Eduardo tique. “Hum, on n’a pas de sentiment d’urgence. Il faut leur indiquer qu’ils doivent faire une action en ouvrant ce mail”. Idem pour le bouton dans le mail, qui est alors “voir mes cartes”. “Il faudrait plutôt indiquer “Mettre à jour ma carte”, conseille Eduardo.
Ce dernier rigole encore de son premier Gemba, à son arrivée chez Qonto :
“Mon manager me dit : pourquoi tu ne ferais pas ça ? Je lui réponds : Ah oui, super idée ! Puis, il y a un blanc… avant qu’il reprenne la parole : bè vas-y, on le fait maintenant ! J’étais habitué à l’approche traditionnelle où les gens te donnent comme des devoirs à faire et s’en vont.”
Toutefois, cette pratique n’est pas suffisante en soi et doit être accompagnée par un vrai système d’apprentissage structuré, objet du 5e et dernier principe que l’on va aborder dans cette plongée au sein du Qonto Way.
Principe 5. Le Dojo : une organisation auto-apprenante
Ce principe est un peu la conclusion des précédents. On l’a dit et répété, chez Qonto, tout est mis en place pour faire émerger des problèmes. Mais le modèle ne s’équilibre que parce qu’un système de formations existe en parallèle pour les résoudre et apprendre les bons gestes aux salarié·es.
Concrètement, au sein de la licorne, deux personnes au produit dédient 80 % de leur temps à la formation. Thomas Vuchot est l’un d’eux. Déjà, il dispose de 2 heures de libre par jour pour des office hours avec des PM. “Ils savent qu’il n’y aura pas de jugement car il n’y a pas de notion hiérarchique entre nous”, rassure-t-il.
Ensuite, tous les lundis, il publie la liste de la dizaine de formations disponibles par semaine. Par exemple, mardi à 11h, la semaine de notre reportage, c’est “Product Teardown”, c’est-à-dire apprendre à analyser un produit concurrent. Un enseignement basé sur la standardisation de ce processus, effectuée par les PM de Qonto eux-mêmes. Un exercice qui implique de réussir à conscientiser leurs gestes pour en faire profiter le reste de l’entreprise.
“Ce document évolue en permanence en fonction de l’usage et de ce que nous construisons avec le temps. Le piège, c’est de prendre ces standards pour des checklists. On ne cherche pas à capturer le geste parfait mais l’intention derrière”, précise Thomas.
Pour l’aider dans sa tâche, la licorne a même créé un rôle de Qonto Way Manager : une personne qui aide les formateurs à créer leurs formations. Il vient du secteur automobile, cela te surprend ?
Et là où le système s’auto-entretient, c’est que ces formations sont directement inspirées par les besoins du moment.
“Beaucoup d’inscriptions aux formations viennent de recommandations des managers lors de Gemba. Cette vision terrain permet d’avoir un aperçu assez clair sur les besoins du moment”, constate Thomas.
“Les red bins ne servent pas à blâmer les personnes, au contraire. Elles nous indiquent les gestes qu’ils ne savent pas faire”, poursuit Marco, dont les enjeux d’apprentissage du moment sont, par exemple, la définition du succès d’une fonctionnalité, l’analyse du comportement des clients sur un produit ou les entretiens utilisateurs.
“Good Products come from Good Thinkers” (les bons produits viennent des gens qui pensent bien – ou Yo shinai, Yo kangai en nippon), résume Steve Anavi dans cet article, paraphrasant une antienne de Toyota. “Ils ne produisent pas des voitures, ils produisent des gens qui font des voitures”, ajoute Marco, auteur l’an passé d’une publication intitulée “Process doesn’t scale. Knowledge does”.
“Une culture qui ne fait pas partir des gens, ce n’est pas une culture”
Voilà pour la vue globale. Ces principes sont valables pour tous les “pipes” (l’appellation des “squads” produit chez Qonto) mais également pour l’ensemble de l’entreprise. RH, finance, support client etc.
Une philosophie atypique et parfois contre-intuitive qui, tu peux t’en douter, n’a pas plu à tout le monde.
“Cela ne marche que si tu es hyper radical. Forcément, il y a des gens qui n’ont pas adhéré et qui sont partis. Mais si tu fais des concessions et que ton objectif, c’est de limiter les départs, c’est mort. Une culture qui ne fait pas partir des gens, ce n’est pas une culture !”, lance sans ambages Marco.
Avant de poursuivre : “Au début, certains ont quitté la boîte sous prétexte que nous ne sommes pas une usine. Je trouve cela dommage de ne pas laisser la chance de voir quelque chose qui vient de l’extérieur. Et de ne pas avoir l’humilité d’apprendre d’une entreprise, Toyota, qui éclate tout le monde dans son secteur en termes de ventes ou de valorisation, qui n’était personne dans les années 1950 et qui a forcé les Américains à venir s’en inspirer, ce qui a donné naissance au lean au passage”.
Thomas Vuchot se rappelle bien de cette période au début.
“Quand ça a commencé à parler de chaîne de production, de pièces et de TPS, il y a eu une réaction épidermique de tout le monde ! C’était très perturbant alors qu’aujourd’hui, c’est entré dans notre vocabulaire quotidien…”
Ce qui l’a convaincu ? Un atelier de deux jours avec Régis Médina (le grand maître de Marc-Antoine). “Le matin du 1er jour, on a dû faire des cocottes en papier à la chaîne. Il s’est servi de cet exemple très basique pour décortiquer tous les concepts du lean et, à la fin de l’atelier, on était capable d’en faire dix fois plus qu’au départ. Tu te rends compte que si ça s’applique à une voiture ou à une cocotte en papier, cela peut s’appliquer à tout !”.
Le travail de pédagogie est, selon lui, ce qui s’est avéré le plus difficile au début mais également le plus déterminant : “Si on ne t’explique pas bien les choses, tu peux vite prendre ce modèle pour du flicage. Or, c’est précisément l’inverse”. D’où l’attention portée aujourd’hui à la sensibilisation au cours de l’onboarding voire lors des recrutements, avec l’envoi d’articles à lire sur le Qonto Way.
“Je m’attendais à quelque chose de très poussé et c’est un peu ce que je cherchais en postulant à Qonto”, relate ce PM croisé dans les couloirs. “Quand j’ai demandé au recruteur si c’était vraie cette histoire de Qonto Way, il m’a raconté son processus RH avec des pièces. J’étais impressionné”, témoigne pour sa part Eduardo.
“On voit très vite si on a affaire à des gens qui ont envie d’apprendre ou des candidats qu’on n’arrivera pas à convertir car ils sont obsédés par des années intensives de Scrum”, sourit Thomas.
Radicalité assumée
Curiosité, discipline, rigueur, ouverture d’esprit… Autant de qualités nécessaires pour intégrer ce type d’organisation. D’autant que la radicalité ne s’arrête pas là. Contrairement à la grande majorité des boîtes de l’écosystème, la discovery est loin de faire partie des prérogatives des PM chez Qonto.
“Je vais dire un truc provoquant : ce n’est pas le taf des PM de savoir quelle est la prochaine pièce à construire”, indique Marco.
Il s’explique : “Aujourd’hui, trop de PM de l’écosystème pensent que leur travail, c’est de prioriser. Alors qu’ils ne savent juste pas faire une bonne spec, un bon design ou qu’ils n’ont encore jamais shippé une bonne fonctionnalité dans leur vie. Mais ce n’est pas de leur faute, c’est juste que c’est super dur et que personne ne leur a jamais appris. On leur a juste montré des règles à respecter”.
Pour lui, une personne qui a beaucoup d’expérience sur le marché et qui connaît ses utilisateurs sur le bout des doigts, cela s’appelle un fondateur ou une personne C-Level. Le CEO de Toyota ne demandera ainsi jamais à une jeune personne sortie d’école de lui dire la prochaine voiture qu’il doit faire !
“Quand je suis arrivé, je proposais plein de nouvelles idées et on me répondait : non, fais déjà bien ce que tu as à faire. C’était dur car au Brésil, j’étais Group PM… mais j’ai réalisé que j’étais dans une boîte où il n’était pas nécessaire d’être un bon PM pour devenir manager”, se souvient Eduardo.
“Le travail du PM, c’est de faire la meilleure fonctionnalité possible et de la sortir à temps”, avance Marco. Ce dernier cite le documentaire “Jiro Dreams of Sushi”, sur Netflix, qui dresse le portrait du 1er maître sushi triplement étoilé. On y voit un apprenti qui est dédié depuis des mois juste aux œufs. Il espère qu’il pourra commencer à apprendre l’année prochaine… la préparation du riz !
“A priori, il est plus simple de faire une omelette qu’une fonctionnalité bancaire qui marche pour 300 000 clients. Pourtant, il y a des gens qui sortent d’école et qui t’expliquent que leur métier, c’est de comprendre les problèmes des utilisateurs. Sauf que la liste des fonctionnalités à faire, elle existe déjà. Il ne faut pas perdre de vue la beauté dans une très bonne exécution », insiste-t-il.
Un plaidoyer pour la réhabilitation de la delivery qui n’est pas sans rappeler celui de Rémi Guyot récemment (qui lui a valu au passage un clin d’oeil sarcastique de Tech Trash).
On ne s’aventurera pas dans ce niveau de détails mais, chez Qonto, on ne parle d’ailleurs pas de discovery. Le parcours produit se matérialise plutôt par une Value Analysis (VA), un concept paper, une Value Engineering, la rédaction de spec puis une delivery.
À en croire les différentes personnes rencontrées pour les besoins de cet article, le Qonto Way a clairement eu une influence dans le développement de la boîte ces dernières années.
“Je suis profondément convaincu qu’on n’en serait pas là si on n’avait pas fait cela. Je suis d’autant plus à l’aise de le dire que je faisais partie des détracteurs au tout début”, concède Thomas.
“Je n’ai aucun exemple de choses qu’on a shippé avec de gros bugs en effet”, remarque Eduardo.
“C’est une remarquable machine de delivery”, confirme cet autre PM dans l’open space. “Même si cela demande beaucoup d’énergie et que, mal employé, ça peut être douloureux, nuance Marco. Il faut accepter que ton manager te dise en permanence “Ouais, c’est bien… et comment on peut faire mieux ?”. Ce que confirme ce PM qui, lors de ses premiers pas, avait l’impression de se faire constamment défoncer pendant ses Gemba. “Ce n’est que bien plus tard que j’ai compris l’importance de faire ressortir les problèmes pour les régler”, ajoute-t-il.
“Un jour, j’ai demandé à Marco pourquoi d’autres entreprises ne se mettaient pas au TPS. Il m’a répondu… parce que c’est super dur !”, rigole Eduardo. “L’agile, tu peux le mettre en place. Mais le TPS, ce n’est pas possible. C’est culturel, tout est une question de posture”, répond Marc-Antoine. Qui lance toutefois : “Mais je reste persuadé que ce qu’on est en train de faire, c’est le futur”.
