Interview avec Marc-Antoine Lacroix – CTO de Qonto

J’ai rencontré Marc-Antoine en 2016. La startup pour laquelle il exerçait alors en tant que CTO nous avait sollicité pour un coaching Lean pour les aider à grandir. J’avais noté son niveau d’attention très élevé lors de la visite terrain et de l’identification des potentiels d’amélioration.

Depuis Marc-Antoine a travaillé avec Régis Médina dans l’accompagnement Lean de dirigeants de startups pour les aider à grandir. Je l’ai recroisé au Lean Digital Summit 2019 où sa conférence a eu beaucoup de succès. Je n’ai vu cette intervention que plus tard, lors de sa publication en vidéo, intervention que j’ai trouvé admirable tant elle est proche de l’esprit lean et tant elle montre que le Lean est une stratégie adaptée pour une entreprise du numérique en hyper croissance.

Marc-Antoine est aujourd’hui CTO de Qonto, une néo-banque qui a fait l’actualité en janvier en levant plus de cent millions d’euros. C’est un CTO que l’on pourra difficilement qualifier de consensuel. Ses prises de positions sont affirmées et il a vivement regretté dans un de ses articles le manque de focus de l’agile sur les phases de conception technique.  Inutile de dire que tout cela a plus qu’éveillé notre curiosité. Marc-Antoine a eu la gentillesse de nous accorder de son temps précieux pour répondre à nos questions.

[Note : entretien mené avant les annonces du gouvernement en raison de la crise sanitaire]

o o o

Bonjour Marc, peux-tu nous présenter ton parcours et dans quelles conditions tu es devenu CTO de Qonto ?

Lorsque j’ai terminé mes études, j’ai monté une première entreprise puis je l’ai revendue. J’en ai remonté une seconde que j’ai quittée après quelques années. Puis j’en ai rejoint une troisième en tant que CTO. La question qui me passionne à ce moment là est la suivante : comment faire pour passer à l’échelle une équipe technique tout en étant efficace et en livrant de la qualité ? Lorsqu’on est deux c’est facile mais comment cela se passe-t-il quand on est 70 ?

À l’époque je pratiquais beaucoup les méthodes agiles. Mais je trouvais que leur passage à l’échelle impliquait beaucoup de bureaucratie. On peut en effet vite se retrouver avec une armée de coachs agiles pour forcer l’application des règles. Et on se retrouve avec des ingénieurs qui appliquent des règles sans les comprendre au lieu de traiter des problèmes complexes. Confronté à cette limite, j’ai voulu creuser et comprendre ce qu’il y avait à l’origine de l’agile et c’est là que j’ai découvert que ces méthodes étaient fortement influencées par le Lean. C’est encore peu développé dans le monde de la tech où on a du mal à voir la valeur de cette approche formalisée dans les années 50 par ce constructeur automobile singulier qu’est Toyota. Cette rencontre a été essentielle.

Dans le monde des start-ups on a souvent tendance à imaginer qu’on a tout réinventé. Ce n’est pas le cas : bon nombre des principes à l’oeuvre viennent du Lean. C’est quand j’ai réalisé cela que je m’y suis plongé.

Dans le monde des start-ups on a souvent tendance à imaginer qu’on a tout réinventé. Ce n’est pas le cas : bon nombre des principes à l’oeuvre viennent du Lean. C’est quand j’ai réalisé cela que je m’y suis plongé. Nous nous étions d’ailleurs rencontrés à l’époque. J’ai beaucoup travaillé avec Régis Médina, j’ai lu des livres sur le sujet, j’ai visité des usines en France mais aussi au Japon. Et la piste que j’ai creusée pour répondre à la question initiale sur le passage à l’échelle est comment peut-on apprendre dans le monde de l’IT à partir des choses faites dans le monde du Lean ? Je coachais des CTO et des CEO sur ce modèle et c’est alors que j’ai rencontré Steve, fondateur de Qonto qui m’a proposé de les rejoindre en tant que CTO.

Dans quelle mesure le positionnement spécifique de Qonto structure ton travail et ta perspective de CTO ?

Qonto est la néo-banque des entrepreneurs et des indépendants. Nous fournissons des cartes de crédit et des outils pour aider à gérer des activités de TPE, PME ou d’indépendants. Qonto grossit vite car tout le focus de l’entreprise est de faire un produit de qualité, rapide et sans frais cachés : voilà nos trois points clefs.

La Qualité est notre boussole : on préfère livrer 3 features dont nous sommes certains de la qualité plutôt que cinq pour lesquelles on a un doute. Nous travaillons la rapidité sur deux axes. Le premier est la rapidité d’utilisation, avec un produit facile et pratique, dont toutes les opérations sont beaucoup plus rapides qu’avec les autres banques. Le second axe est celui pour développer en interne et livrer ces produits le plus vite possible.

Enfin “sans frais cachés” car nous ne souhaitons pas répercuter nos problèmes internes et nos inefficacités sur le prix que paient nos clients. Pour l’équipe technique cela a deux déclinaisons très pratiques : kaizen (amélioration continue) et automatisation des processus sans valeur ajoutée.

Nous travaillons la rapidité sur deux axes. Le premier est la rapidité d’utilisation, avec un produit facile et pratique, dont toutes les opérations sont beaucoup plus rapides qu’avec les autres banques. Le second axe est celui pour développer en interne et livrer ces produits le plus vite possible.

Peux-tu nous donner quelques exemples de nouveaux problèmes ou sujets que font apparaître cette croissance rapide dans votre quotidien ?

Toujours la même question liée à la qualité. Ma conviction est que la qualité du produit dépend de la qualité des personnes, qui dépend elle-même du temps qu’on peut leur consacrer dans la formation, sur le poste de travail, en faisant. C’est jouable si l’équilibre entre les personnes capables de former et celles à former est maintenu. La croissance rapide consiste à former les personnes à l’échelle. C’est pour cela que le Lean est clef pour nous car il s’agit d’un système de formation.

Comment parvenez-vous à recruter dans un contexte avec une si vive concurrence ? Quels sont selon toi les atouts de Qonto en général et de ton équipe technique en particulier ?

Le premier levier est celui d’une image forte de l’équipe. Elle est liée à la capacité à adresser un message qui parle aux développeurs et qui soit différenciant. Nous avons défini The Qonto Way qui est notre système de management et de production. On y explique pourquoi on fait du Lean et pas de l’agile.

Le second levier est une image technique forte elle aussi, que l’on développe en écrivant des articles (cf blog) et en étant présents sur les évènements tech : nous y assistons pour échanger avec la communauté, nous envoyons des intervenants, et nous en organisons.

Le dernier point, essentiel, est ce que les collaborateurs disent de ton entreprise, les références internes. Une équipe heureuse et fière de son travail est la meilleure stratégie de recrutement. Si elle est heureuse au jour le jour, si les collaborateurs peuvent constater qu’ils progressent quotidiennement et qu’on leur laisse l’espace pour s’engager, alors ils vont faire marcher le bouche-à-oreille.

Une équipe heureuse et fière de son travail est la meilleure stratégie de recrutement. Si elle est heureuse au jour le jour, si les collaborateurs peuvent constater qu’ils progressent quotidiennement et qu’on leur laisse l’espace pour s’engager, alors ils vont faire marcher le bouche-à-oreille.

Nous travaillons également beaucoup sur les questions de  télétravail. Notre postulat : nous avons une ambition européenne et donc voulons donc recruter partout sur ce territoire, parmi les meilleurs développeurs. Aujourd’hui nous avons 30% de l’effectif qui télé-travaille. La question que l’on se pose est comment on travaille en Remote tout en faisant du lean.

Et bien justement : c’est une bonne question : comment faites-vous car la distance induit souvent des relations asynchrones, une proximité moins forte et donc une collaboration moins fluide ?

Notre seul sujet dans le cadre des collaborateurs remote est de faciliter la collaboration. Remote ne signifie pas nécessairement asynchrone. C’est le cas si la différence entre les plages horaires est élevée. Mais s’il s’agit de collaborateurs à Belgrade ou au Portugal par exemple, il n’y a qu’une heure de décalage. Un exemple de question que nous nous posons sur le sujet du point quotidien : comment rendre cela agréable pour des personnes extérieures, qui ne sont pas sur place ? Nous avons digitalisé quelques visuels mais pas tous car c’est important d’en conserver un certain nombre en physique.

L’enjeu est lié à la clarté de la communication orale. Il est aussi important d’apprendre à bien converser à l’écrit, dire l’essentiel en peu de mots. Nous faisons aussi levier du pair-programming. Nous invitons à des changements fréquents de pair-programmers pour éviter le sentiment d’isolation et renforcer l’esprit de communauté de l’ensemble de l’équipe.

Enfin notre approche par one piece flow, nous impose d’avoir, dans la mesure du possible, un maximum de personnes qui travaille sur une même feature simultanément afin de la livrer au plus vite. Cela contribue aussi à créer des liens forts même pour les personnes à distance.

L’enjeu est lié à la clarté de la communication orale. Il est aussi important d’apprendre à bien converser à l’écrit, dire l’essentiel en peu de mots. Nous faisons aussi levier du pair-programming. Nous invitons à des changements fréquents de pair-programmers pour éviter le sentiment d’isolation et renforcer l’esprit de communauté de l’ensemble de l’équipe.

Comment définir une vision de CTO dans un contexte en telle croissance ? Si elle peut être rendue publique, quelle est celle que tu as donnée à tes équipes pour cette année ?

On aura réussi 2020 si on est capable de développer de nouvelles features et de nouveaux produits sans ajouter de la dette, qu’elle soit technique ou produit. De manière très spécifique, pour notre prochain trimestre : c’est orienter encore et encore les énergies sur les questions de qualité.

Dans ta vidéo du Lean Digital Summit, tu expliques qu’en limitant l’en cours des besoins métiers à réaliser tu es passé d’une quarantaine de jours à deux jours de Lead Time ? Peux-tu préciser ce lien mécanique entre cette contrainte et ce résultat ?

Il y a deux manières de voir. La première et la plus simple c’est juste de supprimer les attentes.

La seconde est plus spécifique et moins évidente. La réalité est qu’une spécification de feature a un taux d’obsolescence élevé. Après un mois, elle est déjà devenue obsolète lorsque l’on démarre le travail technique. Le développeur va constater qu’il manque des éléments pour être compatible avec les dernières évolutions. Il va donc renvoyer au designer qui va refaire et le renvoyer au développeur, qui va devoir attendre de terminer sur ce qu’il a démarré depuis. Avec le one piece flow, on est tous du début à la fin sur une feature spécifique, sans nous arrêter. Cela a nécessité que l’on travaille en amont : un travail de bacs rouges pour mieux comprendre ce dont on a besoin pour mieux développer ce qui développe la connaissance métier des développeurs, c’est très vertueux. En opérant ainsi, nous sommes parvenus à éliminer un volume significatif de retouches (reworks).

Tu parles beaucoup de l’approche Lean originelle dans cette présentation. Dans quelle mesure cette approche qui est parfois vue comme un système de production de produits manufacturés toujours identiques est applicable dans votre domaine de développement d’évolutions toutes différentes ?

Il faut revenir à la définition du Lean. Ce n’est pas un système de production mais un système d’apprentissage et de formation. Cela nous fait revenir à la question initiale : comment mettre les équipes dans un environnement dans lequel, lorsqu’elles identifient un problème, elles le voient comme une opportunité ? Comment créer le contexte sécurisé pour que les équipes puissent prendre le temps pour le comprendre et expérimenter des choses pour le résoudre.

Avec le one piece flow, on est tous du début à la fin sur une feature spécifique, sans nous arrêter. Cela a nécessité que l’on travaille en amont : un travail de bacs rouges pour mieux comprendre ce dont on a besoin pour mieux développer ce qui développe la connaissance métier des développeurs, c’est très vertueux. 

Comment les équipes perçoivent ce regard particulier, rigoureux et exigeant du Lean sur la production d’évolutions de votre système ? En particulier au sein de la communauté de programmeurs qui n’est pas réputée comme la plus rigoureuse (voir cet article de The Atlantic qui challenge le titre d’ingénieurs pour les programmeurs)

Il y a plusieurs choses : je comprends que l’on challenge le titre d’ingénieur. J’ai d’ailleurs rédigé un article sur ce sujet (Reintroducing engineering in web development).

Pour revenir au Lean, il y a deux choses. La première est de trouver des champions qui vont tirer le sujet et donner envie. Certaines personnes ont tout de suite accroché et d’autres moins. Enfin, certains ne s’y sont pas du tout retrouvé et sont partis.

La seconde est que tout le monde ne pratique pas le Lean au même niveau dans l’entreprise, et c’est ok. Certains sont moteurs et il faut capitaliser sur eux car ils montreront l’exemple et permettront de propager la pratique chez les autres. L’erreur que l’on peut faire dans ce type de démarche est de s’imaginer que tout le monde va devenir passionné par le sujet parce que nous le sommes. Il faut savoir travailler avec ces deux populations. Certaines sont moins passionnées mais elles avancent tout de même en créant de la valeur et en s’inscrivant dans l’amélioration. Ce qui est important est que l’ensemble des collaborateurs souhaite s’inscrire dans une démarche d’apprentissage et d’amélioration [NDLR avoir le Growth Mindset dont parle Carol Dweck]. D’ailleurs, s’ils ne l’ont pas, ils ne passent pas notre processus d’embauche.

Dernière question : que peut-on te souhaiter pour 2020 ?

Des clients très heureux !

Merci Marc-Antoine.

Voir ci-dessous la vidéo de l’intervention de Marc-Antoine au Lean Digital Summit 2019 à Paris.