« Je veux que chaque ingénieur soit fier, à juste titre, des systèmes dont il s’occupe. »

J’ai suivi une formation d’ingénieur parce que j’aimais bien les maths et parce le système éducatif français sélectionne les gens qui ont une bonne relation avec les chiffres pour en faire des ingénieurs.

Je me suis mis à la programmation pour analyser et résoudre des problèmes. À la fin de mes études, je me suis aperçu que je pouvais transformer ce loisir en un métier, juste en le renommant “ingénierie logicielle”.

Quinze ans plus tard, je prends toujours du plaisir contribuer à des projets open-source, quand j’ai le temps — c’est devenu plus difficile depuis que j’ai trois enfants.

Après un stage chez Zonbu, une start-up dans la Silicon Valley, je ressentais le besoin de mieux comprendre le business. J’ai rejoint Polyconseil, un cabinet de conseil en télécoms et médias qui avait une spin off réussie à son actif, Wifirst. Je n’ai pas fait de consulting et je n’ai pas fait de spin off. Par contre j’ai fait émerger une pratique d’ingénierie logicielle. Au passage, je suis devenu core developer de Django.

Cinq ans plus tard, je voulais élargir ma palette de compétences. J’ai pris la direction technique d’Oscaro, e-commerçant leader des pièces détachées de voiture en France.

Je me suis alors senti prêt pour lancer mon propre business. J’ai créé une activité de consulting sur Python et Django. Quand j’ai trouvé mon premier client par de l’inbound marketing sur Twitter et que ma première facture a été payée, cela a été un moment important pour moi : j’avais démarré une entreprise !

Peu après, j’ai co-fondé Otherwise, une start-up dans l’InsurTech. Nous rendions l’assurance plus simple, plus transparente, plus juste et plus humaine en créant des communautés et en re-distribuant les cotisations qui n’avait pas servi à indemniser des sinistres.

À ce moment là, mon premier patron m’a demandé si je pouvais rejoindre la direction technique de CANAL+. Le groupe était engagé dans une transformation majeure et il y avait eu quelques départs. Rien de tel qu’un défi managérial pour me motiver ! J’y ai passé trois ans à développer de nouvelles pratiques de management avec mon équipe. Nous avons optimisé nos méthodes de travail, entre nous et avec les équipes business.

Ensuite l’histoire se répète : quelqu’un que j’ai managé dans ma toute première équipe, qui travaille désormais chez Qonto, me demande si j’aurais envie de le manager à nouveau… 👀

Je n’ai pas eu trop de mal à me décider ! J’ai rejoint Qonto parce que Steve, Alex et d’autres Qontoers ont pensé que je serais capable de diriger l’équipe Tech. Ça n’aurait pas été malin de laisser passer une opportunité dans une des plus belles start-up en France actuellement. 🚀

Je me suis tout de suite senti bien avec la culture de Qonto. Quand Steve, Alex, et les autres managers parlent des valeurs de Qonto — Ambition, Teamwork, Mastery, Integrity — on sent tout de suite qu’ils les vivent et que cela explique leur réussite.

De plus, ils ont beaucoup de recul sur leur manière de travailler: ils appliquent des modèles pour comprendre et optimiser chaque aspect de leur activité. Comme j’ai appris sur le tas une grande partie de ce que je sais faire dans la vie professionnelle, j’ai tendance à m’appuyer davantage sur mon intuition que sur des modèles. Je me suis dit que j’avais beaucoup à gagner avec une approche plus structurée.

Enfin, dans mes expériences précédentes, j’ai alterné entre des créations d’activités propices à l’innovation et des équipes plus larges pour acquérir de l’expérience en management. Qonto, c’est l’opportunité idéale pour faire les deux en même temps. Exactement ce que je voulais !

Le processus de recrutement était incroyablement bien organisé, d’autant plus que Qonto n’embauche pas des CTOs très souvent — en tous cas pas avant un bout de temps, j’espère. 😅

Je me souviens de deux signes marquants de professionnalisme :

• Chaque interlocuteur savait ce dont j’avais parlé avec les précédents et ce qu’il devait tester. Belle démonstration d’organisation et de rigueur.
• Tout au long du processus, j’avais régulièrement des retours sur là où je m’en sortais bien, là où je m’en sortais moins bien, et sur les doutes qui restaient à lever.

J’avais clairement l’impression que Qonto voulait que je réussisse, si j’en étais capable.

Quand ton manager potentiel te fait des retours précieux avant même de t’embaucher, c’est bon signe. Maintenant que c’est moi qui fais passer des entretiens, j’espère que je pourrai faire aussi bien !

S’il faut raconter une anecdote… après les “Qontoer interviews” avec ma future équipe — quand nous recrutons un manager, il passe des entretiens avec son équipe prospective – Steve m’a expliqué qu’ils m’avaient trouvé plutôt directif. Ensuite, il a continué : “Tu dis ce que tu penses. C’est utile mais fais attention. Ceci dit, si l’équipe ne m’avait pas fait ce retour, on aurait arrêté le processus ici.”

Désolé, les gars — on n’a qu’une seule chance pour donner une première impression, c’était en visioconf et j’ai fait ce que je devais faire.

Tout le processus s’est déroulé durant le confinement. On me demande souvent ce que ça fait de signer pour un job dans une entreprise où on n’a rencontré personne dans la vraie vie. Eh bien, ça ne m’a pas marqué. Je me souviens juste m’être demandé quelle taille pouvaient bien faire les gens auxquels je parlais.

Je suppose que mon expérience dans les communautés open-source m’a aidé, du fait que la plupart des interactions s’y font par écrit avec des personnes que je ne rencontrerai jamais.

La première partie du job, c’est de déterminer en quoi consiste le job. 😀

En plus, il a toutes les chances de changer rapidement avec la croissance de Qonto.

Si on repart des fondamentaux, l’équipe Tech contribue à fournir un service de qualité aux clients de Qonto en concevant, en développant, en documentant, en testant et en exploitant des systèmes complexes avec un niveau de fiabilité et de sécurité élevé. Facile, non ?

Probablement plus facile à dire qu’à faire, mais j’ai une ligne directrice : si je fais grandir l’équipe, le reste suivra.

Quand je parle de faire grandir l’équipe, il ne s’agit pas juste de rajouter du monde — cela va beaucoup plus loin:

1. Booster les performances individuelles - Révéler le potentiel de chaque personne et lui faire franchir une marche. Ensuite, on trouve la marche suivante et on recommence. Le Qonto Way donne un cadre sur lequel les managers peuvent s’appuyer pour développer les compétences de leur équipe.
2. Catalyser la performance collective - Mettez un groupe de personnes intelligentes dans une pièce ; elles ne feront de grandes choses que si elles s’organisent bien pour se compléter. Comme Qonto et son équipe Tech grandissent vite, je dois m’assurer que notre organisation, nos processus et nos outils restent efficaces.
3. Construire l’équipe - Plus que d’ajouter du monde, il s’agit d’accueillir les bonnes personnes. Elles renforceront la culture, vivront les valeurs, et rendront leur équipe plus forte que la somme de ses membres. Cela explique notre processus de recrutement

Si nous faisons cela sérieusement, je suis sûr que l’équipe saura prendre les bonnes décisions et construire de la technologie robuste.

Ensuite je pourrai choisir où est-ce que je veux déplacer faire bouger le curseur, rentrer dans les détails et coacher l’équipe.

Grandir. Et aussi, grandir. J’ai parlé de grandir ? 😉

Nous avons la chance d’avoir des bases techniques solides. Nous ne passons pas notre temps à éteindre des incendies. Nos enjeux de croissance sont plus de l’ordre de l’excellence opérationnelle que de l’ordre de la résolution de problèmes techniques.

Actuellement, il y a une trentaine de systèmes dans la stack technique Qonto. Nous les découpons principalement par domaine métier. Au fur et à mesure que nous grandissons, nous sommes de plus en plus stricts sur la séparation des responsabilités entre domaines. Nous tenons aussi compte de contraintes techniques. Par exemple, le système d’autorisation des paiements par carte est un service dédié parce qu’il a un pré-requis de haute disponibilité spécifique.

Notre plus gros défi, c’est sans doute de faire évoluer notre architecture pour qu’elle soit de plus en plus durable et de plus en plus fiable. En effet, pour cela, il faut créer un consensus sur la cible et faire partager cette vision à une équipe de plus en plus large.

Par ailleurs, notre architecture technique va inévitablement refléter la structure de notre organisation — c’est la loi de Conway. Cela implique que nous ne pouvons pas décorréler la croissance de nos systèmes de celle de notre équipe. Chacun de ces deux sujets est intéressant en lui-même. Les deux à la fois, ça devient franchement marrant !

Nous avons aussi quelques enjeux autour de notre recours à des tiers pour certains volets de nos opérations. Par exemple, au départ, nous nous appuyions sur un core banking system tiers. En 2018, nous avons commencé à construire le nôtre. Un an plus tard, il était prêt et nous avons commencé à gérer nos comptes clients dessus. C’était un énorme projet.

D’autres projets de cette ampleur nous attendent. Nous devons choisir judicieusement le bon moment pour les lancer. Ensuite nous devons les mener à bien dans les temps, faute de quoi nous décalerons tout le reste.

Le dernier défi dont je voudrais parler, c’est la qualité. Nous sommes dans une situation assez paradoxale. D’un côté, tout le monde s’accorde pour trouver notre qualité plutôt bonne. De l’autre, les ingénieurs continuent à se montrer critiques sur la qualité de ce qu’ils produisent. En soi, c’est assez classique pour une jeune entreprise où les ingénieurs ont des standards élevés.

Cependant, nos processus lean prévoient que chacun assure la qualité à chaque étape, si bien que la qualité est une responsabilité diffuse. Personne n’est dédié à la qualité. Il n’y a pas de lieu unique pour en parler. Pour résoudre le paradoxe, il faut aligner les définitions et les attentes de tout le monde.

Si je te demandais de deviner, tu aurais de bonnes chances de tomber juste. Cela permet aux nouveaux arrivants de prendre leurs marques rapidement dans l’organisation.

Nous avons des équipes fonctionnelles transverses, que nous appelons CFTs (cross-functional teams), pour chaque grand domaine de notre activité. La plupart des CFTs sont pérennes parce qu’elles se concentrent sur un besoin fondamental de l’activité comme l’inscription, les virements, les cartes, ou le grand livre. Certaines CFTs sont constituées pour un projet en particulier et sont éphémères. Cependant, nous sommes attachés à la stabilité des équipes, donc nous préférons demander à une CFT existante de prendre en charge un projet plutôt que de créer une CFT pour moins de neuf mois. Chaque trimestre, nous ajustons la structure des CFT en fonction de notre feuille de route pour le produit.

Dans une CFT, il y a un ou deux product managers, une équipe de backend developers et un équipe de frontend developers. Les backend team leads sont rattachés à un head of backend; idem côté frontend. Cela nous aide à garder de la cohérence entre les CFTs.

Actuellement, le mobile est une équipe autonome parce que les dévs iOS et Android ne sont pas assez nombreux pour se répartir entre les CFTs. Nous envisagerons de les intégrer aux CFTs quand l’équipe mobile aura suffisamment grossi pour que cela puisse marcher.

L’infrastructure et la sécurité sont également des équipes séparées, vu que leur activité est le souvent plus transverse.

Pour commencer, nous prenons nos distances avec la doxa agile. Cela mérite quelques explications !

Quand nous regardons les pratiques agiles classiques — par exemple scrum ou similaire, que la plupart des entreprises tech mettent en œuvre à différents niveaux de discipline et de maturité — nous avons trois inquiétudes :

• Fondamentalement, les sprints sont un algorithme glouton. Cette technique amène à un optimum local. Il n’est pas évident qu’elle peut amener de manière fiable à un optimum global. Il est encore moins évident qu’elle permet de prendre le chemin le plus court pour y arriver.
• Les itérations génèrent souvent de la déviance. Elles permettent de masquer des erreurs et d’éviter des discussions difficiles. Plutôt que dire “itérer”, nous préférons dire “refaire”. Nous classons ça dans la catégorie du “gaspillage”. C’est plus difficile d’investir dans la planification en amont mais cela gagne beaucoup de temps en aval.
• L’agile marche moins bien quand il faut coordonner de nombreuses équipes. Nous avons constaté que les techniques pour “passer l’agile à l’échelle”, par exemple scrum of scrums ou SAFe, ont tendance à dégénérer en bureaucraties tenues par des armées de coaches agiles. La responsabilisation et la vélocité en sont les premières victimes.

Ne me faites pas dire ce que je n’ai pas dit — quand je parle de planification, je ne défends pas le cycle en V ; c’est un désastre. Évidemment, nous découpons le travail en petites unités et nous formalisons des points de rencontre fréquents entre produit et tech. Simplement, nous structurons ce processus de manière à maximiser l’efficacité et minimiser le gaspillage.

Nous aggravons notre cas en ne cherchant même pas le successeur de l’agile.Au contraire, nous revenons aux sources de l’agile, à savoir le lean.

Tu peux lire les articles du blog sur le Qonto Way pour en savoir plus.

Une autre particularité vient de ce que nous sommes une solution de gestion financière pour les TPE-PME. Les erreurs ont tendance à coûter un peu plus cher que dans pas mal d’autres activités. Quand on réfléchit aux conséquences potentielles de telle ou telle situation, l’échelle va jusqu’au milliard d’euros. Évidemment, on s’organise pour ne pas en arriver là. Nous avons de multiples garde-fous structurels, techniques et humains pour éviter les erreurs et aussi un régulateur qui veille.

Dans mon job précédent, j’ai découvert que le “teraoctet par seconde” pouvait être une unité raisonnable de débit réseau. Dans celui-ci, je vais m’habituer au “milliard d’euros” comme une unité raisonnable de responsabilité financière!

Nous cherchons des personnes qui partagent notre vision — créer la solution de gestion financière numéro 1 pour les PME en Europe et faciliter la vie à des millions d’entrepreneurs — et qui peuvent nous aider à y arriver.

Nous avons des postes ouverts dans tous les domaines : backend, frontend, mobile, opérations et sécurité.

Pour le prochain trimestre, je vais me concentrer sur :

• Les développeurs backend - notre candidat·e idéal·e connaît la FinTech, maîtrise l’un de nos deux principaux langages backend et est prêt·e à apprendre l’autre. Notre core banking system est écrit en Go. Les APIs exposées publiquement et divers systèmes internes sont en Ruby on Rails.
• Les managers - Au fur et à mesure que nous embauchons davantage de devs et que nous créons des CFTs, nous avons besoin de managers pour les diriger. Parfois nous avons de bons candidats internes et nous faisons des promotions. Sinon, nous cherchons la bonne personne en externe. Nous avons des postes de management ouverts dans presque tous les domaines.

Si tu cherches une équipe d’ingénieurs où on fait les choses bien, plus besoin de chercher.

Accroche ta ceinture et viens franchir une marche avec nous. 🙃