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 Arnaud Lemaire, bonjour.
Est-ce que tu prêts à te présenter en quelques mots pour ceux qui ne te connaîtraient pas ?
Alors moi je m'appelle Arnaud, on me connaît un petit peu plus sous l'île au base,
un petit peu partout sur internet. Aujourd'hui je travaille sur tout ce qui est conception logistielle
dans une start-up, ou alors ce qu'on peut qualifier de skylog qui s'appelle Sunbeck,
qui propose des solutions de cléments, notamment dans le domaine de la restauration.
Et si j'ai bien compris, vous avez fait une belle poussée de croissance là puisque tu me disais
que vous avez passé de 2 à 100 à l'équipe tech, on laisse pas de quoi, 10 mois.
Oui voilà, c'est ça.
Comment tu fais d'abord pour dormir et ensuite pour, tu me disais, il y a un gros challenge,
c'est de garder une culture cohérente, une certaine cohérente dans la culture tech.
Comment tu fais ? Parce que avec un tel volume, tu es obligé d'enborder des gens de culture,
je veux dire technique, différentes. J'ai du mal à croire que tu arrives à recruter
que des gens déjà au niveau sur tous les points qui sont importants pour toi.
Comment est-ce que tu fais pour garder ça ? Moi j'ai cette expérience dans une ancienne vie d'une boîte
où on avait recruté, recruté, alors moins que toi, tu en étais déjà qu'une quinzaine.
Et puis d'un jour, me retourner et de plus reconnaître l'entreprise et l'équipe que j'avais construite.
Là en fait, tu dis déjà en premieru qui est très vrai, c'est qu'il faut pas espérer reconnaître
la merde.
Moi, sincèrement, depuis que je suis chez Sunday, j'ai déjà vu en fait trois, quatre entreprises
différentes. Mais c'est normal. Il y a un très bon bouquin qui s'appelle Blitz Kaling qui explique
justement qu'est-ce que c'est le process de ces boîtes qui soudainement prennent une croissance
très soudaine et très forte. Et ce qu'il explique, c'est que même d'un point de vue humain,
il utilise justement les différentes structures sociales qu'on peut connaître.
En fait, il y a au début la boîte qui est un petit peu la famille, puis ensuite,
en fait, tu as la boîte qui est la tribu, puis ensuite tu arrives à une taille de villages,
puis il y a une taille de villes, enfin à une taille presque l'équivalent d'une nation.
Et en fait, à chacun de ces différentes étapes, forcément, la boîte va changer.
Et effectivement, comme tu le disais, la vraie problématique, c'est comment est-ce que tu t'assures
au fur et à mesure que tu montes sur ces différents étages, que ta culture prend quand
même la bonne direction, même si forcément, l'entreprise, elle ne ressemblera plus à ce
qu'on n'a plus connait quand on était encore une vingtaine de personnes et qu'on était un petit peu
dans cet aspect tribu. C'est génial. Je viens de mettre, pendant qu'on discute, ce bouquin
Bleed Scaling dans ma liste de lecture d'Amazon. Du coup, ce que tu... Première étape, tu dis,
il ne faut pas s'attendre à reconnaître l'entreprise parce qu'elle va changer. Malgré tout, tu essayes
de garder justement des valeurs, une certaine culture, une certaine manière d'approcher les choses.
Ça, tu essayes quand même de le conserver ou pas, alors ? Est-ce que c'est peine perdu ?
Oui, oui. En fait, c'est-à-dire que forcément, il faudra évoluer pour s'adapter à la croissance.
Maintenant, il faut qu'il y ait un ensemble qui c'est un petit peu de fondation qui va quand même
permettre, parce que les gens, ils ont quand même rejoint une entreprise. Alors bien sûr,
il y a sur ce que proposent l'entreprise, sur un petit peu les défis, la culture de l'entreprise
en tant que tel. Et donc, il faut quand même s'assurer qu'au fur et à mesure que la croissance
est là, que ces différents éléments restent alignés pour quand même que les gens s'y retrouvent.
Voilà, la boîte va changer de forme. Maintenant, toute l'idée, c'est quand même d'avoir une
continuité dans ce que l'on pourrait qualifier effectivement de la culture interne propre à la boîte.
Par exemple, toi chez Cender, c'est quoi les points sur lesquels tu as été particulièrement
vigilant ? Est-ce que c'est sur certaines pratiques, sur un certain état d'esprit, sur certaines
valeurs, comment tu tiens pris ? C'était quoi les points cardinaux pour toi qui fallaient absolument
respecter et arriver à conserver au cours de cette croissance ?
Alors, je vais en fait là, tu vois, t'as associé deux termes que j'aime beaucoup, en fait,
c'est les pratiques et la culture. Et ça, c'est le premier point à vraiment comprendre.
C'est que quand on parle de culture, et notamment de culture technique, ça sert à rien de faire
des posters ou des grands articles pour dire, voilà, qu'elle va être notre culture, parce qu'on a beau
marquer quelque part, on a une culture de la livraison continue et du code de qualité. Si,
derrière, il n'y a pas des pratiques concrètes pour justement atteindre ces objectifs-là,
on aura beau marquer ça, ça restera en fait d'être mort. Et c'est le cas de beaucoup d'entreprises.
Il y a des entreprises qui se présentent avec des cultures absolument géniales, et en fait,
quand on voit dans le concret comment ça se passe, on est très, très loin de ça,
parce que justement, il n'y a pas des pratiques pour soutenir ces aspects de culture. Et c'est
pour ça que j'aime beaucoup cette citation, je ne sais plus du tout de qui c'est, mais c'est de dire
que la culture émerge des pratiques et non l'inverse. On ne peut pas donner en fait une culture
et espérer que par elle-même, elle prenne forme. On va toujours chercher à se dire quelles sont
les pratiques qui soutendent la culture par laquelle je sois allée. Et donc, ce que tu veux dire,
c'est que tu gardes la culture et les valeurs comme une espèce de juge de paix et de quelque chose
qui t'aide à décider la suite, enfin l'orientation du projet, mais par contre, tu vas être très sensible
aux pratiques parce que c'est ça qui va forger la culture.
Exactement. En fait, c'est les pratiques qui vont avant tout influencer l'évolution de la culture.
Par exemple, chez Sunday, dans les pratiques qu'on a, on a pris beaucoup de pratiques qui viennent
de l'extrême programming parce que pour moi, pour nous, c'est un ensemble de pratiques qui
vont dans la direction de la culture technique qu'on souhaite avoir, qui est à la fois comment
est-ce qu'on arrive à fournir un service qui doit être extrêmement fiable, extrêmement simple
d'usage parce qu'on est dans le domicile du paiement. Comment est-ce qu'on arrive aussi à avoir une
capacité à adresser le marché rapidement parce qu'on est justement dans une phase de croissance
où il y a des besoins marchés qui évoluent ou on doit pouvoir ajouter du fonctionnel à l'applicatif,
tout en faisant en sorte effectivement qu'on maintienne quand même une problématique de
qualité parce que comme Jean-Baptiste Dussault a déjà intervé ici le dit très souvent,
la qualité d'aujourd'hui est la productivité de demain. Donc n'est pas tout que d'avoir une
productivité du quotidien, mais c'est aussi comment est-ce qu'on s'assure que cette productivité ne
s'effondre pas d'ici quelques semaines. Surtout que quand tu es dans des corbes de croissance telles
que tu as décrite, le risque devient exponentiel en fait. Si tu n'as pas une base extrêmement
saine et que tu fais rentrer par wagon de dizaines de développeurs, tu es quasiment
assuré dans les dents de mur. C'est pour ça que c'est intéressant de se reposer à la déficitation
de scale scaling parce qu'il a aussi souvent quand on parle de une boîte scale, on attend
ça à l'avoir sous un nom et un peu business, c'est à dire que la boîte scale, d'un point de vue,
il y a de plus en plus d'utilisateurs, il y a de plus en plus de fruits financiers, la boîte,
on va dire, elle brasse de plus en plus d'argent avec de plus en plus de monde, etc.
Alors le scale, en fait, moi souvent je le présente comme étant quelque chose de tridimensionnel,
c'est à dire qu'il y a cet aspect business qui est l'aspect évident, qui est nom d'utilisateur,
chiffre d'affaires, volumétrie d'affaires si tu veux. Mais à côté de ça, il y a un angle,
en fait, celui que tu as donné qui est l'angle humain, c'est qu'en fait le scale,
ça veut aussi dire qu'on amène de plus en plus de personnes dans l'organisation. Et enfin,
le troisième élément du scale, c'est un élément en termes de complexification,
en fait, de l'ensemble fonctionnel. Parce que au fur et à mesure que tu adresses un marché qui
est plus en plus large, eh bien tu as de plus en plus de complexité qui s'installe dans ton
fonctionnel. Donc c'est à la fois réussir à adresser comment est-ce que tu t'assures que tu
es en capacité de répondre aux besoins de plus en plus d'utilisateurs, tout en amenant de nouvelles
personnes, tout en faisant en sorte de justement réussir à garder sous contrôle la complexité
qui vient s'additionner. Le truc qui me vient en tête tout de suite, c'est dans certains projets,
je voyais des porteurs de projets qui voulaient accélérer très très très fort. Et je sentais
l'équipe pas prête en fait. En termes de produits, donc moi il y a eu des moments,
je freinais des cas de fer parce qu'on avait déjà fait de 1 à 8 dans l'équipe tech. Mais après sur
le recueil des besoins, sur l'analyse, enfin tu vois surtout ce qui est à mon design et compagnie,
je sentais qu'on n'était pas quoi, donc il y a des moments où il fallait que je freine en fait.
Ça t'est déjà arrivé ça ? Alors justement, en fait là tu arrives sur un point que je trouve
assez intéressant et parce que pour ceux qui ont eu l'opposition peut-être de certaines de mes
conférences, j'étais en souvent à dire en fait, en gros, grandir ou produire, il faut choisir.
C'est à dire qu'en fait soit on est dans une phase où on cherche à recruter, à amener de nouvelles
personnes et à justement en fait augmenter un peu la taille des équipes. Mais ça veut dire
qu'on ne peut pas avoir comme objectif d'avoir un délivrerie très conséquent ou alors effectivement
on va plutôt se focusser sur le délivrerie. Mais dans ce cas là, c'est un moment où il faut généralement
éviter de chambouler les équipes etc. Le problème, c'est que ça c'est très vrai quand on parle de
start-up un peu classique ou des projets plus classiques. C'est à dire que sur beaucoup de projets,
ce qui se passe c'est que la croissance est souvent s'est donnée par la phrase de ne recruter
qu'en que quand ça fait mal. C'est à dire qu'il faut qu'il y ait un sentiment, on va dire de douleur,
qui soit ressenti par les équipes pour se dire ok, détendre recruter quelqu'un. Et en fait c'est une
croissance qui repose sur les individus. En fait, qu'est-ce qui se passe ? C'est qu'en fait tu
demandes aux gens de en gros travailler à 110%, 120%, 130% de leur capacité. Là ça commence à
faire mal. Tu rajoutes 2-3 personnes, les gens peuvent redescendre à 90%, ensuite ça va remonter à
110%, 120%, 120% et puis tu ramènes des gens. Et ça fait un petit peu comme ça d'accordéon dans
les équipes, dans l'organisation pour accompagner la croissance. Le problème, c'est que quand tu es
dans une situation de scale-up, tu ne peux pas faire ça parce qu'en fait d'un côté tu as ton business qui est censé faire foilice.
Et donc si jamais en fait tu utilises les humains, les personnes pour justement accompagner ta croissance,
qu'est-ce qui se passe ? Tu vas leur demander en fait de m'intéresser à 110%, 120%, 130%, 140%,
150%. Ce qui fait qu'à la fin tu récupères en fait des équipes qui sont épuisées, qui sont lessivées.
Et en même temps, toi tu n'as fait que 1,5% de croissance. Donc la boîte a perdu.
Donc tu ne peux pas jouer sur les faits à coordonnées classiques, il est obligé de revoir complètement ton modèle.
Et c'est pour ça que dans ce genre de moments, tu es obligé d'avoir une stratégie de recrutement
qui correspond au fait que tu fais scale-up l'organisation. Et tu fais scale-up l'organisation et non
pas seulement les équipes, c'est qu'en fait tu te dis ok, il faut qu'on réussisse à avoir suffisamment
de monde pour pouvoir absorber la croissance telle qu'elle est requise par la boîte.
Et donc c'est là effectivement où ça devient un jeu d'équilibrisse extrêmement compliqué.
Parce que comme tu l'as dit, en fait c'est souvent des moments où ça peut être difficile d'avoir les
bonnes ressources pour tacler les bons problèmes au bon moment.
Alors je me rends compte qu'on est parti sur une autre voie, mais tu n'as pas répondu à la question
que je t'avais posée et après je pense malheureusement la fin de notre time-book dans le registrement.
Mais quelles sont les pratiques sur lesquelles tu as été particulièrement sensible lors de cette
phase de croissance de t'assurer que c'était bien maintenu ? Parce qu'on a vu que les pratiques
c'était le socle de la culture. Est-ce que tu peux nous donner quelques pratiques où vraiment
pour toi on ne déroge pas et il a fallu qu'ils reviennent par moment parce que tu voyais que ça
pouvait glisser ?
Alors on a eu la chance justement d'avoir un recrutement où il n'a pu récupérer pas mal de
personnes qui étaient déjà bien capées. Donc j'ai pas eu besoin de trop revenir dessus et pour la
plupart des gens c'était des pratiques qui faisaient juste sens. Mais donc pour les donner
effectivement mécaniquement tout ce qui est continuous integration et continuous delivery
c'est super important dans ce genre de contexte parce qu'encore une fois on ne peut pas attendre
même deux semaines en fait pour pour coucher une nouvelle future en prod. Il faut que si jamais
effectivement il y a un besoin criant qui a été exprimé quelques jours après et puis ça va
être envoyé en prod et donc de là attendre en plus trois ou six mois c'est même envisageable.
Donc ça c'est vraiment le premier point. Ensuite par exemple sur les process de
développement c'est de dire ok en fait on fait de l'incrémentale. Encore une fois ça paraît
super évident mais il y a plein de boîtes qui n'arrivent pas à faire de l'incrémentale
proprement et de faire de l'incrémentale horizontalement parlant. C'est en fait on
fait pas de l'incrémentale où on essaye en fait de découper verticalement le future site.
Par exemple il y a beaucoup de boîtes où on va implémenter toutes les méthodes d'authentification
on va mettre l'authentification de la Facebook, Twitter, Google, Apple etc et puis en fait ça
fait le premier incrément. Le problème c'est qu'au moment où on livre cet incrément
il n'y a pas d'alerte. Il n'y a pas de valeur business. Il n'y a aucune valeur business.
Et donc c'est de dire en fait on va faire plutôt un incrément qui est horizontal.
C'est à dire en fait on va se dire ok mettons une première méthode d'authentification super
simple c'est à travers le téléphone voilà et on construit le reste et ensuite dans un
deuxième incrément on viendra rajouter des choses qui vont permettre d'un petit peu augmenter ce
future site. Donc ça c'est aussi un autre élément. Pareillement le per programming c'est
quelque chose qu'on a énormément poussé parce que tout simplement c'est quelque chose notamment
pour l'unboarding on a autant de monde qui arrive etc de brasser les individus, de faire en sorte qu'ils
se connaissent, de faire en sorte qu'ils travaillent ensemble. On ne pas oublier que le développement
c'est un travail d'équipe. C'est pas un travail de personnes qui sont chacune dans leur coin donc
réussir à créer cet élément d'équipe, réussir à faire en sorte que les gens se partagent de l'information
qu'elle soit technique ou business ça a aussi été super important. Un autre élément comme ça de
tête c'est toute la partie ce qu'on appelle la sécurité psychologique c'est de faire en sorte
que toute personne se senta l'aise de pouvoir dire bah là en fait je sais pas ou je ne sais pas ce
que j'ai en train de faire j'ai besoin d'aide. Il y a beaucoup de boîtes où on n'ose pas dire ça
parce qu'on a peur des conséquences en termes d'image ou en termes de carrière. Nous on a fait
attention depuis le début parce que tout le monde comprennait qu'il n'y a pas de conséquences à
demander de l'aide. Ça c'est un point super important donc ça aussi c'est quelque chose sur
lequel on a beaucoup beaucoup appuyé. On a aussi utilisé tout ce qui est des tests juivain
de développement ça c'est presque on va dire une nécessité pour pouvoir justement en fait
continuer à fournir du fonctionnel en vérifiant qu'il n'y a pas de régression, pouvoir continuer à
déployer en continue etc. On utilise en ce qu'on pourrait qualifier de l'architecture
hexagonale ou en tout cas on essaie de séparer les aspects vraiment métier, domaine, des aspects
plus techniques là aussi pour pour s'apporter des capacités à pouvoir changer nos implementations
si on a besoin. Un autre élément par exemple aussi que je répète souvent c'est de dire optimiser
pour le remplacement et non pas pour l'extensibilité c'est à dire que dans beaucoup de cas quand on
code on essaie de coder en se disant comment est-ce que je vais pouvoir faire évoluer ce code
dans le futur afin qu'il accède plus de business case. En fait c'est de dire vous savez quoi,
faisons un truc simple mais par contre assurons-nous que le jour où ce machin devient plus compliqué
on peut le jeter et le remplacer par un nouveau système. Ça me fait penser une fois un gars qui
disait le jour où je me suis mis à coder en me disant que j'allais jeter mon code ça a changé
ma manière de coder le truc parce que justement un partenariat où tu réfléchis en code jetable
et remplaçable tu veux dire que tu cherches au maximum à limiter toutes les dépendances fortes
en fait. Exactement. Et c'est extrêmement vertu. Voilà donc ça tu vois c'est pour te donner un
petit peu un ensemble c'est un petit peu toutes ces pratiques qu'on essaie de mettre derrière la
culture technique chez ça. Eh bah écoute Arnaud on est arrivé à la fin de notre time box. Merci
beaucoup pour ton temps si les auditeurs veulent te suivre et en savoir plus sur ce que tu fais ils
peuvent te suivre. Twitter, LiloBase et alors même si je ne suis plus très très active dessus je le
suis de ton temps. Merci beaucoup Arnaud. Merci encore pour l'invitation. Je t'en prie. Quand
t'as touché à l'auditeur j'espère que t'as kiffé cet épisode si tu as envie de former à
écrire du code durable si tu as envie d'en apprendre un petit peu plus sur le TDD sur comment découpler
du code et le design correctement. Je t'invite à venir découvrir le cursus artisan developer ça
doit être dans la maison des compagnons ou sur compagnons.artisandeveloper.fr dans la rubrique
formation. Je te remercie je te dis à bientôt.