Didier Hilhorst (Qonto) : Comment le zéro bug structure votre growth

Le zéro bug n'est pas une contrainte, c'est une proposition de valeur

Chez Formance, la moindre faille dans la database financière peut créer un trou dans la comptabilité client. Le bug n'est pas un irritant, c'est un deal-breaker.

Anne-Sibylle Pradel, CEO de Formance, structure son produit autour de cette exigence absolue. La QA n'arrive pas en fin de cycle comme dans les produits non business-critical. Elle est intégrée dès la conception de chaque feature, à chaque étape du cycle de release.

Comme la solidité slash reliability du product est en fait une valeur et une propriété intrinsèque de notre produit, les clients viennent nous voir pour s'assurer qu'ils aient accès à une database où il y aura absolument aucun trou dans la raquette.

— Anne-Sibylle Pradel, CEO Formance

Trois piliers soutiennent cette approche : des tests internes systématiques à chaque étape, un partenariat avec Antithesis pour tester toutes les configurations produit dans des environnements variés, et la communauté open source qui inspecte, déploie et remonte les limitations en conditions réelles.

Responsabiliser les ingénieurs change tout

Chez Lago, Anne Tautzschwung va plus loin. Tous les ingénieurs qui développent une feature font ensuite le support client pour cette feature. Pas de délégation à une équipe dédiée.

L'approche paraît contre-intuitive. Ces ingénieurs pourraient développer d'autres fonctionnalités au lieu de répondre aux utilisateurs. Mais le cofondateur de Lago défend une conviction forte : voir les utilisateurs en action et résoudre leurs problèmes rend les ingénieurs meilleurs.

Les ingénieurs qui bossent sur une feature doivent voir les utilisateurs l'utiliser et doivent aussi savoir comment l'améliorer et comment éventuellement enlever des bugs ou des choses comme ça, ou mieux expliquer à l'utilisateur si ce n'était pas instinctif.

— Anne Tautzschwung, CEO Lago

Cette organisation crée une boucle de feedback directe. L'ingénieur ne code pas dans le vide. Il mesure l'impact réel de son travail et ajuste en temps réel.

Le changelog hebdomadaire comme levier marketing

Linear a bâti une partie de sa réputation sur un simple rituel : publier un changelog chaque mercredi ou jeudi. Adrien Griveaux, founding designer, explique que ce rythme transforme la correction de bugs en argument commercial.

La philosophie : célébrer les petites victoires. Un bouton qui ne marche pas bien peut sembler insignifiant. Mais c'est exactement ce type de détail qui pousse un utilisateur à tester un concurrent le jour où il en a marre.

Le petit bug en fait que tu vois toi tous les jours en tant qu'utilisateur d'un produit qui t'énerve, des fois c'est un truc con, c'est un bouton qui marche pas très bien ou un truc comme ça. En fait, le jour où le gars va tester un produit concurrent et que ce bouton-là par contre il marche super bien, et bah ça peut être une raison de switch.

— Adrien Griveaux, Founding Designer Linear

Le changelog devient aussi un outil de planification interne. Les équipes se demandent : est-ce qu'on va sortir ce fix avant mercredi pour l'inclure ? Cela crée un rythme, une micro-roadmap hebdomadaire qui structure le travail sans bureaucratie.

Quand 140 bugs valent mieux que 5

Arthur Waller, CEO de Pennylane, assume une approche radicalement opposée. Son backlog compte 140 bugs quand Qonto en tolère maximum 5. Pourtant, Pennylane continue de grandir à vitesse grand V.

L'ADN de Pennylane repose sur le build permanent, pas le polish. Sauf exception : l'offre TPE, jugée suffisamment mature, a bénéficié d'un an et demi de stabilisation. Partout ailleurs, la priorité reste l'innovation et la construction de nouvelles briques.

Waller cite même Booking, où l'absence de bugs était vue comme un signal d'alarme. Ils avaient instauré un "bug budget" : pas assez de bugs signifiait qu'on n'allait pas assez vite, qu'on ne cassait pas assez de choses.

Le choix n'est pas entre bon et mauvais. C'est un choix d'identité. Qonto attire des talents puristes qui ne supporteraient pas 140 bugs. Pennylane recrute des builders qui partiraient si on leur demandait de travailler au pixel près.

La mécanique derrière la philosophie

Pennylane compense sa tolérance aux bugs par une organisation spécifique : des firefighting squads dédiés en permanence à la résolution rapide, surtout en période fiscale. Quand un comptable a un bug à deux jours de la liasse fiscale, impossible d'attendre trois jours.

L'équipe reporte chaque semaine le nombre de tickets avec bugs et le temps de résolution. Pas de métrique sur le nombre de bugs total, mais une obsession sur la réactivité.

Qonto et Pennylane prouvent qu'il n'existe pas de vérité absolue sur la gestion des bugs. La vraie question : quelle religion produit choisissez-vous, et êtes-vous prêt à l'incarner à 100% dans votre recrutement, votre culture et votre exécution ?