Bienvenue sur le podcast Artisan Developer, l'émission pour les programmeurs qui veulent
vivre une carrière épanouissante. Prêts à passer au niveau supérieur ? C'est parti !
Aujourd'hui je suis avec Thibault Barère, Thibault bonjour !
Bonjour !
Est-ce que tu peux te présenter en une minute pour les auditeurs ?
Je m'appelle Thibault Barère, je suis consultant indépendante depuis 2005. Mon
cœur de métier c'est vraiment l'ingénierie du code et tout ce qui est pipeline de données.
Je travaille avec différents technos en remote depuis H&M, principalement
Ruby et LexyR et plus récemment Rust.
Et je te propose que le thème de l'épisode soit ça tourne autour de Kiba, Kiba Hotel
qui est un peu comme ça que j'ai découvert et que j'ai découvert ton travail au moment
où j'ai l'impression d'être un peu un dinosaure en disant ça mais je m'intéressais à
la BI, la Business Intelligence. Aujourd'hui on parlerait d'intelligence artificielle ou
de Big Data. Bon à l'époque c'était de la BI. Et je trouvais intéressant tant retour
d'expérience autour du fait d'avoir animé une gemme en open source. Donc une gemme pour
la communauté Rails c'est une brique réutilisable, en fait c'est une bibliothèque, tu peux télécharger
facilement avec le Bindler, le gestionnaire de package. T'as fait cinq ans que tu fais ça,
c'est quoi un petit peu le regard que tu portes sur ce travail là et comment tu fais pour durer
sur un projet open source comme ça ? Pour avoir le détail de tout ça, j'ai designé la gemme
autour du fait d'avoir une maintenance minimale et une utilisabilité maximale.
Attends ça veut dire dire que tu intégrais vraiment dès la conception l'enjeu de
maintenabilité du système pour pouvoir le maintenir sur la durée facilement ?
Oui c'était un critère clé de départ, c'est une condition sinequennone. Alors ça pour aussi
tes auditeurs veulent plus d'informations, j'ai donné un tour le cas à Paris RB en 2020,
en février je crois, où je fais un récap détaillé de tout ça et du raisonnement qui a eu derrière
et qu'on va pouvoir voir ici aussi. Ça a été enregistré ou ? C'est enregistré,
c'est sur Youtube où on pourra passer le lien. Ah ouais, on mettra le lien carrément et je crois
que je dirais le voir d'ailleurs. Et du coup alors, qu'est-ce que tu en retiens de tout ça ?
Qu'est-ce que je retiens de tout ça ? Du coup j'ai bien fait parce que déjà j'ai pris soin de
mesurer le temps que je passais, de concevoir quelque chose qui avait une imitialité maximale avec
un temps de maintenance minimale en éliminant, il faut savoir qu'en fait qui bat ETA, c'est un DSL
qui permet d'écrire des tuyaux de données en rubis, de créer des connecteurs, des entrées,
des sorties, des choses comme ça. Ça sert à tout un tas de choses, des interconnections d'API,
des interropes en entreprise, des lecture de fichiers CSV, du travail avec des bases de données.
Et en fait, il y avait un precursor avant qui s'appelait ActiveWarehouse ETL dont j'avais
repris la maintenance et qui s'est avéré être trop lourd à maintenir et en même temps trop
restrictif en termes d'usage, pas assez léger, pas assez embédable. Et donc je me suis retrouvé à
être embêté, à devoir arrêter la maintenance, à décider d'arrêter pour pas le soutenir sans
revenu en face. Et donc j'ai reparti 2-0 en disant quelque chose dont je savais que je pourrais le
maintenir longue durée avec peu de temps, même si ça prend toujours du temps, et travailler du
coup davantage l'aspect doc autour et même concevoir un modèle open-core, c'est-à-dire qu'il y a une
petite extension, il y a une extension open-source gratuite et il y a une extension payante avec des
éléments de plus pour travailler avec les bases de données de façon efficiente. Donc tout ça,
je l'ai disanné avant le codage. Et concrètement, ça veut dire quoi ? C'est quoi le type de choix,
le type de décision que tu prends pour ramener à ça ?
C'est pas mal de feeling. Je voulais que ça soit pas du crippleware,
donc je voulais que la partie open-source soit réellement utile. Et au final, en faisant d'ailleurs
des sondages, je me suis rendu compte qu'elle s'était beaucoup plus utile que même ce que je
pouvais imaginer, ce qui a été témoigné sur la page où j'ai repris tout ça, sur la page de
Kibautel. Mais l'idée, c'était est-ce que cette feature va être coûteuse dans le temps à
maintenir en termes de documentation, de mise à jour, de suivi quand Ruby va évoluer,
de suivi quand tel Terps Composand va évoluer aussi, et d'essayer d'être assez rigoureux dessus.
Donc du coup, j'ai une sorte de trélot, une sorte de backlog où je trie agressivement les
choses pour décider que ça, ça doit aller dans l'open-source ou pas. Ça, ça doit aller dans de
la Presta ou pas. Et ça, ça doit aller dans, c'est assez régénérique pour être vendu en tant
que tel dans un composant réutilisable. Et il se passe parfois un an et demi avant que je décide
que ça, ça va aller dans l'open-source ou au contraire pas. Parce que je veux être sûr d'avoir
compris qu'est-ce que je dois mettre dans la version open-source pour que ça ne coûte pas à moi
même plus tard, même si ça va résoudre un problème en local. Donc j'essaie d'avoir
une perspective d'utiliser la gemme sur plusieurs prestations ou plusieurs cas d'usage avant de me
dire oui c'est bon, je peux l'intégrer, j'ai un retour d'expérience de la réalité qui est suffisamment fort.
Ok, donc ça, cette intuition, cette sensation, tu le nourris par l'expérimentation parce que tu
utilises toi-même ton hotel sur tes propres projets en fait.
Exactement. Ou pour des clients, même pour des juges à j'interne.
Oui, ce que je veux dire, c'est que comme tu es utilisateur toi-même, tu te fies à ton jeu,
tu n'as pas des feedbacks de contributeurs, tu n'as pas des pool requests qui t'inciteraient à
faire des choses, c'est vraiment ton usage qui te guide dans ces choix-là.
Oui, oui, c'est ça. C'est exactement ça.
Ok. Et du coup, quel conseil tu pourrais donner ? Parce que pendant la préparation
d'épisode, on discutait du risque majeur qui est, quand tu te lances dans un projet open-source,
qui est double, c'est soit le burn out, soit l'abandon pur et simple et les deux vont bien
ensemble d'ailleurs. Comment tu te prémunis de ce genre de pente glissant tout un moment donné ?
Pour peu qu'en plus, tu as de l'usage. Je crois que j'avais le témoignage d'un gars une fois sur
un truc qui disait, c'est juste dingue. Les gens ne réalisent pas que en fait, c'est du temps gratuit
et se comportent parfois de manière assez agressive comme des clients alors que c'est de l'open
source. On porte souvent même comme les pires clients possibles parce que les clients du gratuit,
tu as ce genre de feedback toi aussi ? J'ai pas eu ça parce que j'étais sur une niche qui fait
que je l'ai peu eu. Par contre, je ne me prie pas effectivement de dire non, je ne vais pas intégrer
ça. Une PR n'est pas forcément un cadeau pour moi parce que souvent, j'ai une vision de ce que
je veux faire après. Par contre, comment je le structure ? Je traque mon temps religieusement,
pourrais dire, à savoir que le temps que je passe sur mon open source est traqué comme un projet
commercial pour un client avec lequel habituellement je fais la facture en fonction de mon temps.
Je traque aussi dans le temps plus à la louche le fait que l'open source a amené de la prestation
et à quel pourcentage de mon chiffre d'affaires. Du coup, j'ai une vision tous les mois,
concrètement ou tous les ans de est-ce que c'est vraiment intéressant de passer 40 heures à récrire
la doc de la v3 au regard de ce que ça m'a rapporté sur les quatre ans passés. Donc ça me permet
d'objectiviser ce point-là et d'être sûr que ça glisse pas trop, même en étant religieusement
attentif à ça, d'ailleurs, on peut glisser quand même parce qu'il ne faut pas être trop dans
l'affect. Mais voilà, du coup, je fais du tracking et de l'analyse à post-héroïde pour vérifier
que je suis lucide par rapport à ce que je fais. C'est vachement important ce que tu dis, c'est
contrebalance, cet enjeu émotionnel et cette implication que tu peux avoir par une analyse
assez froide et rigoureuse des chiffres. Et tu te poses la question, en gros, est-ce que c'est
rentable d'investir ce temps-là au-delà du plaisir que j'y prends ? Est-ce que ça m'a rapporté
quelque chose ? Est-ce que j'ai finalement un circuit de financement dans le truc ? Parce que si
finalement 40 heures d'open source te ramènent x centaines de milliers d'euros sur plusieurs années,
tu peux te dire c'est mes frais de commerce. Et du coup, c'est rentable.
En fait, c'est exactement ça. C'est-à-dire que je recalcule une sorte de taux horaires
moyens qui intègrent par exemple ma R&D qui n'est pas financée, il y a de la R&D financée,
de la R&D pas financée. Le temps que je vais passer en quelques réponses que je fais à la
partie open source ou même le temps que je peux être amené à donner pour développer une partie
commerciale. J'ai travaillé avec des clients qui m'ont payé en prestation tout en autorisant le
fait que j'intègre ces composantes dans la version pro que je vends. Après, il y a toute notion de
propriété intellectuelle où je suis très clair avec les gens qui comprennent bien l'intérêt
collectif de la chose aussi. Mais oui, effectivement, je suis assez maitré parce que j'intègre ça dans
un taux horaire global. Pour moi, il est hors de question de finir en Burnout. Le Burnout,
c'est pas chez moi. C'est clair. Au-delà du Burnout, j'entends que c'est quand même une logique,
une intelligence économique dans le truc. Est-ce que c'est un bon Paris ? Ça dépend des années ?
Est-ce que ça a tendance avec le temps à grossir tout seul ? Ou est-ce qu'au contraire, il y a des
années, c'est bien, des années, c'est un peu le deal et un peu moins bon, mais globalement, tu
te retrouves ? C'est pas chaque année, mais l'objectif est atteint, qui était que je vende
un petit peu de licence. C'est pas mon gros objectif, mais j'en ai vendu quelques-unes. Et
que surtout, le tout le kit reste mis à jour pour que moi, je puisse m'en servir en prestation de
façon quasiment tous les mois. Il y a des années où Kibam m'a amené en termes de l'ID plus de 60,
70 % de mon chiffre d'affaires. Donc clairement, le retour sur investissement est bon, mais je
continuerai à l'observer dans le temps pour voir si ça a continué être le cas. Pour l'instant,
ça a l'air d'être bien. J'ai pas besoin aujourd'hui de passer une maintenance énorme dessus
pour que ça tourne bien. Par contre, il faut bien prendre en compte le fait que, il faut calculer
un peu le coût d'opportunité qu'on peut perdre. C'est-à-dire que pour moi, l'argent n'est pas
important du tout, mais si je passais trop de temps sur la pasti open source, ça veut dire que par
exemple, et que je ne suis pas rémunéré dessus et que je ne m'auto-rémunère pas, malheureusement,
c'est un coût d'opportunité pour du temps que je passerai sur des activités personnelles,
apprendre à mieux jouer du piano, etc., ou lancer d'autres produits ou passer du temps avec mes
enfants ou avoir de l'argent de côté pendant quelques années et pouvoir travailler un peu moins
si je le souhaitais. Donc il y a toujours un coût d'opportunité et quand on est passionné,
parce qu'on fait, on a envie d'être utile, le danger, c'est un peu qu'on s'oublie aussi
soi-même dans l'équation. Il faut au moins se mettre à niveau égal par rapport aux services
qu'on aura à tout le monde gratuitement. – Bah écoute, je pense que c'est hyper important
ce que tu viens de dire et je te propose que ce soit le mois de la fin. Si les auditeurs
veulent en savoir plus, ils peuvent venir t'écouter au Tibo. – Mais écoutez, je ne sais pas trop,
ils peuvent me sur Twitter. – Pas d'écouter, te lire. – J'ai un blog Tibo Barère qui explique
ce genre de choses. La vision générale, une fois de plus, ce sera le talk sur YouTube qu'on
mettra en lien. Je suis pas mal actif sur Twitter aussi, Tibo underscore barère. – Merci Tibo d'être
venu aujourd'hui. – Merci de ton invitation, Benoît. – Quant à toi, chère auditeur,
j'espère que tu as apprécié cet épisode. Si c'est le cas, je t'invite à mettre une super
évaluation dans ton outil d'écoute de podcasts favoris, que ce soit Apple Podcast, Google Podcast,
Spotify, Deezer, ce que tu veux. Mais met-nous une note d'enfer et ça permettra de faire connaître
le podcast auprès de d'autres développeurs. Je te remercie, je te souhaite une bonne journée,
je te dis à bientôt.