Bienvenue sur le podcast Artisan Developer, l'émission pour les programmeurs qui veulent vivre une carrière épanouissante.
Prêt à passer au niveau supérieur ? C'est parti !
Aujourd'hui je suis avec Luca Bertola, Luca bonjour.
Bonjour Bernard.
Est-ce que tu peux te présenter rapidement en une minute ?
Oui bien sûr.
Du coup moi je suis Luca, je suis le site CIO d'AJCAP, je suis aussi co-fondateur.
AJCAP c'est un logiciel SAS de gestion trésorerie.
On est actuellement en pleine croissance.
C'est-à-dire qu'on arrive à avoir une croissance de 20% par mois.
Ce qui est plutôt énorme pour donner une ordre d'idée,
ça veut dire qu'en un an on est passé de 10 employés à 100 employés par exemple.
Oui c'est bien les uns.
Et du coup c'est dans ce cadre que j'ai vraiment voulu mettre en place chez AJCAP toute une culture de qualité.
Ok et concrètement ça veut dire quoi pour vous ?
Concrètement ça veut dire qu'avec la croissance qu'on a,
on peut juste pas en fait se permettre de se retrouver à dans deux ans,
avoir un logiciel tout pourri, tout bugué,
avec les clients satisfaits où on peut plus grossir.
Pour nous c'est ultra important de se dire qu'on soit serein dans un an, deux ans, cinq ans,
qu'on est toujours un logiciel top qualité qui va pouvoir grossir,
avec des techs qui soient ultra contents de faire les features bien comme il faut,
avec une TMA qui soit minuscule,
le but c'est qu'on passe pas tout le temps à les des bugs,
c'est vraiment cet ensemble qui est pour nous très important.
Alors là tu vois dans ce que tu viens de dire,
j'ai des milliards de questions qui arrivent,
mais il y a deux axes principaux.
D'abord je suis que de savoir un petit peu concrètement ça veut dire quoi pour toi
à développer ces pratiques de qualité, comment tu peux illustrer ça.
Puis j'ai une deuxième question,
je sais pas si on aura le temps de la traiter,
ce sera peut-être l'objet dans notre épisode,
c'est comment tu maintiens cette culture là malgré la croissance.
Quand tu dis de 10 à 100 personnes,
c'est pas dans l'équipe de dev, c'est la boîte en tout je suppose.
Total oui.
Combien il y a des développeurs dans la boutique ?
Le but c'est que tech plus producte,
ça fasse 33% de la boîte,
donc il y a à peu près 15 techs, 15, 20 techs.
Ok.
Et du coup par exemple concrètement ça veut dire quoi pour toi à leur faire de la qualité ?
Faites faire de la qualité pour moi,
ça va vraiment s'accès sur deux axes,
deux axes très importants,
la première ça va être vraiment celle de la TMA,
c'est qu'on se retrouve pas,
c'est qu'on puisse faire des rajoutés continuellement
des nouvelles features,
sans qu'en fait on casse des choses,
sans que les clients soient insatisfaits
parce que ça marchait plus etc.
Et le deuxième ça va vraiment être au quotidien du développeur,
ok les choses sont pas cassées,
donc on ne repasse pas du test,
mais aussi si en fait je passe mon temps à les réparer des tests avant la mise en production,
c'est que ce n'est pas en plus de qualité,
c'est que vraiment aussi d'avoir ce sentiment,
d'avoir gardé une bonne productivité dans tes développements
et que le tech,
ça se ressent aussi au niveau du moral du tech,
c'est que quand il va devoir,
enfin le journée, quand il va push la features,
il sera vraiment fier de son travail,
il va se dire là j'ai passé une bonne journée,
j'ai pas eu une pression de malade du produit
parce que le client il le voulait tout de suite,
là je sais que ma feature c'est les faits,
c'est les bienfaits,
et je suis content de mon travail.
Et concrètement ça passe par quelle pratique,
tu parlais des tests,
c'est ce que vous faites,
vous êtes sur du TDD,
vous faites autrement comment vous travaillez ?
Donc on est effectivement sur du test,
mais je pense que le test est bien entendu ultra important,
mais que ce n'est pas le plus important ironiquement
pour arriver à ce résultat là,
je pense que le plus important c'est que
tout le monde soit sensibilisé
à cette culture de qualité,
c'est à dire que typiquement quand on commence une feature,
quand le produit nous annonce une feature,
il n'y a pas ce moment un peu gênant
où on se pose la question,
est-ce qu'on va faire ça bien ?
Je vais aller négocier avec le produit,
est-ce que je ne peux pas prendre un peu plus de temps
ou ce genre de choses ?
Non, ça c'est une évidence pour tout le monde,
la question c'est pas,
est-ce que je vais faire ça bien ?
La question c'est comment je vais faire ça bien ?
Vraiment pour moi ça c'est le plus important,
et le deuxième chose la plus importante
c'est de faire confiance à ces équipes engineering,
c'est-à-dire que par exemple tu parles de tests,
est-ce qu'il faut mettre en place des tests ou non ?
Ce n'est pas à moi, CTO,
qui n'est pas au quotidien des développements des features
qui doit imposer les tests,
qui doit imposer leur pourcentage de coverage,
c'est vraiment au texte de dire
ok je vous mets la responsabilité tous ensemble
de comment on va faire le meilleur produit possible,
et c'est à eux de dire ok,
moi je connais super bien mes features au quotidien,
je sais que les tests c'est super important,
donc on va les mettre en place,
je sais que telle partie du code mérite une refacto,
donc on va prendre le temps pour le faire,
en fait vraiment redonner ce pouvoir au tech,
c'est un énorme impact.
C'est un énorme impact du coup,
et tout ça moi je suis clairement favorable,
tu me parles de notions de qualité,
la qualité intrinsèque qui est vraiment actée,
visiblement on ne se pose pas des questions là-dessus,
du coup dans ce genre de climat,
moi j'ai envie de te demander,
comment est-ce que tu modères ça,
par exemple si tu es un développeur ou une équipe,
parce que tu vas recruter,
je crois que c'est bon,
vous cherchez à recruter,
imagine que tu recrutes,
et puis tu te rends compte que finalement,
certains des devs n'ont pas forcément encore
toute cette logique, tout ce truc,
et tu dis en tant que situaux,
je ne vais pas imposer l'échange,
je veux que ça vienne deux,
mais comment tu fais si à un moment donné,
tu vois que ça ne vient pas,
c'est-à-dire que si la personne,
elle n'a pas acquis cette culture,
alors est-ce que c'est un filtre à l'entrée,
ou est-ce que tu vas lui donner une chance,
tu vas la laisser splonter pour pouvoir appuyer un peu dessus,
comment tu vas gérer ça,
parce que c'est quand même frustrant,
parfois tu vois tes gars qui parlent dans la mauvaise direction,
tu sais qu'ils vont se planter,
et tu fais quoi là ?
Ouais, c'est une bonne question.
Il y a déjà effectivement un filtre à l'entrée,
c'est que quel que soit le niveau de la personne
qu'on va prendre, junior, intermédiaire, senior,
quelque chose qui pour nous est super important,
c'est cette motivation à faire les choses bien,
et on veut vraiment que la personne,
soit convaincue qu'il faut faire les choses bien,
même si ce n'est pas forcément comment les faire,
il faut que ce soit clair et net pour elle,
c'est comme ça qu'on a envie de travailler.
C'est d'ailleurs vraiment, c'est partie de la culture,
on n'instorte pas une culture avec des gens
qui ont des opinions radicalement différentes.
Il y a près au quotidien,
je pense qu'en fait, les gens seront très vite compte de leurs erreurs,
avec notamment le Déploiement Continu,
très vite, si tu parles dans la mauvaise direction,
il y a le terrain qui te rattrape,
il y a le terrain qui dit « ah c'est bizarre,
c'est la seule équipe qui a dû de la TMA,
comment c'est possible ? »
Et en fait, du fait que les gens sont responsabilisés,
par eux-mêmes, ils se rendent compte que c'est des bonnes choses à faire.
C'est justement l'intérêt à la responsabilisation,
c'est que quand c'est juste un grand manitou,
responsable technique qui va te dire quoi faire,
que ça marche, que ça marche pas, tu t'en fous au final,
là c'est pas le cas.
Oui, j'entends.
Du coup, s'il y a une culture qui est assez forte, assez prégnante,
ce que tu dis, c'est que la réalité va rattraper
ceux qui ne rendent pas dans l'état d'esprit,
qui ne font pas comme les autres,
en tout cas, qui obtiennent des résultats moindres,
et là, à ce moment-là, ça va se voir,
normalement, la personne, elle fait ce qu'il faut pour corriger.
Tout à fait.
En plus, il y a aussi un autre point,
c'est que chaque équipe a des contraintes différentes,
puisqu'ils ont un projet différent.
Donc, si je commence à imposer aux équipes
une façon de faire de la qualité,
elle ne sera pas forcément adaptée à leur projet.
Donc, c'est aussi cet esprit de vraiment avoir
la meilleure façon de faire pour son projet.
Ok.
Du coup, à l'inverse,
comment est-ce que tu t'empares aussi les excès ?
Parce qu'il y a un gros risque dans notre métier,
et si à un moment donné,
justement, tu cherches à faire de la qualité,
c'est de faire de la sûre qualité,
et de prévoir des trucs qui n'ont pas lieu d'être,
ou de chercher à anticiper,
ou de...
Enfin bref, le truc qui pourrait prendre une semaine,
il en met deux.
Comment est-ce que tu t'assures de ne pas tomber
dans ce travers-là,
qui est aussi préjudiciable,
en mon sens, que le manque de qualité ?
Donc, nous, chaque équipe,
ils ont un, ce qu'on appelle un team leader.
Dans l'idée,
je n'ai pas pu pas avoir le temps
de expliquer ce post-lab,
mais dans l'idée, c'est un tech lead.
Et cette personne-là,
à l'époque que les entreprises étaient plus petites,
on a pu passer énormément de temps ensemble
à savoir exactement
qu'est-ce que nous, on attendait chez HGCAP,
qu'elle est où mettre la barre de la qualité,
et pourquoi, etc.
Et cette personne-là,
du coup, n'a un par équipe.
Et c'est elle qui va, du coup,
passer du temps avec chaque tech,
vraiment essayer de comprendre
pourquoi, comment tu fais comme ça.
Elle va pas lui dire,
non, chez nous, on fait comme ça,
descend ta barre, augmente ta barre.
Elle va juste faire une discussion avec elle.
Et en fait, chaque personne est raisonnée.
Si elle a une bonne raison de faire les choses,
on va la laisser.
Si en fait, on se rend compte en fouillant
qu'elle a une mauvaise raison,
la personne sera cohérente
et elle réussira à baisser sa barre.
Ok, donc là, on revient sur cette idée
que tu as déjà formé des gens,
il y avait déjà un noyau dur
que tu avais pu, j'imagine,
mener l'idée toi-même
et que cette connaissance-là, elle est diffuse.
Elle est déjà actée,
elle est déjà présente chez les Techlead.
Si on se retrouvait dans une situation
où il n'y avait pas de culture du tout
et que là, on voulait mettre en place,
ce serait beaucoup plus compliqué.
Mais du fait que la culture est déjà présente,
ça s'entretient très facilement.
Ça s'entretient, oui, parce qu'elle est dominante.
Cette culture-là est dominante
et chaque nouvelle entraîne.
Mais du coup, c'est un vrai talent.
Du coup, surtout dans des phases
de d'hyper-croissance,
de garder une cohérence sur ça.
Ah, j'ai plein de questions qui viendraient,
mais je vois que la voix de temps arrive à son échéance.
Si les gens veulent en savoir plus
sur ce que tu fais, sur AgiCap,
ils peuvent venir où ?
On a une magnifique page sur Reckham to Jungle.
Au-dessus, on vous verra toute la description
de tous les posts qu'on a à pourvoir.
On est extrêmement friands de nouvelles têtes
et de nouveaux cerveaux pour la partie engineering.
Donc vraiment, n'hésite pas à postuler,
ce sera un grand plaisir qu'on recevra.
Ça marche ? Merci, Lucas, d'être venu aujourd'hui.
Merci à toi, Benoît.
Quant à toi, chère auditeur,
j'espère que tu as apprécié cet épisode.
Si c'est le cas,
est-ce que c'est un épisode qui se prête à une écoute partagée ?
Je crois bien ça,
parce que justement, on revient sur ces idées
de qualité intrinsèque,
de pas vraiment négociable.
Peut-être que si tu organises une écoute avec ton équipe,
ça pourra susciter des idées ou donner des envies.
Je pense que c'est une bonne idée.
Et fait-nous ton retour,
dis-nous ce que tu en as pensé,
ce que tes teammates en ont pensé.
Je me remercie,
à Benoît, en rebase artisan-developpeur.fr.
Je te remercie, je te dis à bientôt.