Bruno:
Apprendre à coder, c'est souvent un chemin sinueux. Certains passent par des bootcamps, d'autres par des formations classiques, ou même des tutoriels en ligne. Mais il y a une voie un peu plus radicale à prendre en construisant quelque chose de réel, en créant un service et parfois même en créant une entreprise. C'est apprendre le code par nécessité, là où chaque ligne écrite compte et où chaque bug coûte du temps. De l'argent et parfois même quelques nuits blanches. Mais ça, c'est quelque chose que nous connaissons tous. Mais alors, comment se lancer sans expérience préalable ? Faut-il choisir entre apprendre à coder et développer son entreprise ? Et surtout, est-ce que comme dans Ratatouille, tout le monde peut apprendre à coder ? Pour répondre à ces questions ambitieuses, je ne reçois pas Elon Musk, mais il s'y connaît en apprentissage. Alex, bonjour.
Alex:
Salut Bruno.
Bruno:
Alors Alex, excusez-moi te présenter pour les quelques personnes qui ne te connaîtraient peut-être.
Alex:
Oui, je suis Alex Delivier. Je suis le fondateur d'une solution SaaS qui s'appelle Collect. Donc usecollect.com ce qu'on fait chez Collect c'est on fait une plateforme, qui permet de récupérer des documents et des informations auprès de ses clients donc les principaux cas d'usage ça va être dans l'immobilier, dans la finance donc par exemple dans l'immobilier un agent immobilier ou un courtier en prêt immobilier il a besoin de récupérer des documents auprès de ses clients que ce soit pour une transaction ou une location, donc je ne sais pas, des documents financiers d'identité, des choses comme ça, il va tout lister sur Collect partager un lien avec le client et en fait le client va remplir tout son dossier et derrière on facilite les allers-retours si ça ne va pas l'export, l'intégration avec les CRM on fait pas mal de choses on bosse avec des métiers de l'immobilier, des fintechs pour faire du kibou ici je travaille aussi avec des cabinets d'avocats qui font de l'immigration des SaaS qui font de l'onboarding c'est assez large et assez horizontal.
Bruno:
KYC au cas où quelqu'un ne le connaitrait pas donc.
Alex:
C'est Know Your Customer exactement, donc c'est ce qu'on vit de plus en plus depuis quelques années c'est à dire que ce soit, la banque, enfin en fait il y a plein de on va dire plein d'organismes qui à un moment donné vont vous dire on a besoin de vérifier qui vous êtes donc une pièce d'identité injustificative de domicile pour des entreprises un KBIS ou autre pour vérifier qui on est quoi.
Bruno:
Et t'ajoutes à ça des services de tu prenais l'exemple effectivement des pièces d'identité de vérification ?
Alex:
Non, je n'ai pas de vérification à proprement parler. Je ne suis pas un pur player du KYC. Il y a des boîtes qui font vraiment du KYC pur et dur. Moi, je ne suis pas un pur player du KYC. En revanche, je viens... Remplacer ceux qui font du KYC à la main, enfin toi t'as le droit de faire du KYC à la main ou même du KYC physique tu vois, si tu vas dans ta banque tu vois, il y a de fortes chances que ta banque t'ait fait un KYC physique à un moment donné t'as rencontré ton conseiller, t'as dit passez moi votre pièce d'identité tu vois, moi je viens remplacer en fait toute cette partie là qui se faisait un peu par mail et qui se fait encore beaucoup par mail tu vois, en fonction des boîtes, où ils te disent est-ce que vous pouvez nous envoyer ça ça ça par mail, tu vois le moyen le moins sécure du monde je viens le remplacer en le digitalisant.
Bruno:
Et qui permet du coup aussi de faire des systèmes d'alerte de rappel.
Alex:
Ou ce genre de choses en revanche pour revenir sur ta question à défaut d'avoir de la vérification d'identité ou là pour le coup je pense c'est vraiment un autre métier et une autre responsabilité, je m'intègre quand même avec des services qui font de l'OCR pour faire de l'extraction de data automatisée donc je bosse avec une boîte qui s'appelle Mindy en fait et aujourd'hui tu vois sur Collect ce que tu peux faire c'est tu viens déposer des pièces et tu vas dire tiens ça j'ai besoin que tu m'extrais la data qui est dans ces pièces là et ça on va le faire du coup en utilisant l'API de Mindy.
Bruno:
Et donc cas un peu particulier c'est que tu as lancé ce projet là en ne sachant pas coder.
Alex:
C'est un peu c'est un peu clickbait, mais pour revenir alors effectivement quand je l'ai lancé en tout cas je ne savais pas codé comme aujourd'hui c'est sûr, j'avais déjà codé quand j'étais plus jeune moi j'ai commencé à coder comme beaucoup à 16-18 ans en PHP à faire des sites web au début pour des copains de mes parents, tu fais un peu ton petit réseau comme ça, tu fais des petits sites web très très basiques puis un peu plus compliqué à l'époque et après j'arrêtais de coder pendant, une grosse dizaine d'années et en 2015, j'étais chez E-Founders j'ai décidé de partir de chez E-Founders pour monter un projet et là je me suis dit le prochain projet que je monte, je suis pas sûr de trouver un associé technique et j'avais pas envie d'être dans un mood lever de fond, essayer de construire une grosse équipe et ainsi de suite donc fallait que je trouve sinon quelqu'un genre en mode juste être deux sur un projet, et je m'étais dit en tout cas j'ai pas envie que ça me freine donc en attendant je vais me mettre à coder, donc je me suis remis à coder à ce moment là à réapprendre vraiment tous les basiques parce qu'en fait en disant, t'oublies quand même pas mal de choses, c'est comme les vélos et puis ça a changé aussi, ça a changé de ouf, en fait. Il y a plein de choses qui ont changé qui ne se faisaient pas de la même façon tu vois à l'époque, déjà niveau front ça n'a rien à voir en disant ça a vraiment complètement changé, et niveau back pareil même sur les déploiements il y a plein de choses qui ont changé et c'est vrai ce côté maintenant on n'en parle plus c'est devenu un peu une banalité de dire ça mais d'un côté on a gagné énormément parce que tout devient plus simple, enfin devient plus simple en tout cas on a l'impression que c'est plus simple tu peux faire un déploiement en deux secondes, aujourd'hui je sais pas sur un Vercel ou whatever mais d'un autre côté le niveau que tu dois avoir dans un certain nombre de domaines il est quand même plus violent qu'avant, avant je sais pas quand on faisait du PHP il y a 20 ans tu te connectais en FTP tu changeais ton fichier et ça marchait, aujourd'hui ce serait une hérésie de faire ça mais, donc tu vois je sais pas ça a changé.
Bruno:
C'est effectivement une discussion que j'avais en plus hier parce que j'étais en train de préparer un épisode avec, le créateur de Symphonie on a parlé effectivement un petit peu de ce sujet là, sur le fait que on a un métier qui est de plus en plus complexe mais que la complexité qu'on avait il y a 20 ans est devenue hyper simple.
Alex:
D'une certaine façon mais.
Bruno:
Ça s'est quand même complexifié malgré tout.
Alex:
Et puis tu vois quand tu redébarques et quand tu vois le nombre de concepts qu'il faut que t'appréhendes en fait c'est un peu c'est assez violent mais bon ça se fait quoi après.
Bruno:
Il y a aussi le fait que tes premiers contacts avec le code c'était quand t'étais, plus jeune on va dire collège, lycée, ou aussi tu le fais pas avec les mêmes contraintes, avec les mêmes problématiques c'est à dire que tu fais des choses forcément un peu plus crades, de manière un peu plus, bricolée là où quand tu le fais pour ta boîte j'imagine que t'as quand même des envies de faire quelque chose.
Alex:
De propre alors après il se trouve que j'ai au final la chance d'avoir démarré sur le mauvais projet tu vois c'est à dire que quand je pars de chez eFounders fin 2015. Pendant deux ans alors pendant deux ans je suis un peu on and off dans le sens, j'apprends, je code sur un projet mais en fait ce projet là je le mets en comment dire, enfin je fais pas mal de freelance en parallèle donc tu vois t'as des moments où je bosse beaucoup dessus t'as des moments où je bosse pas beaucoup dessus un peu comme beaucoup je pense de nos auditeurs tu vois qui font ça tu vois par exemple en mode side project donc en fonction du temps qu'ils ont dispo ils peuvent bosser dessus ou pas. Du coup le premier projet sur lequel je bosse c'est un CRM pour les VC je connais pas mal le monde du VC je connais beaucoup de VC et je m'aperçois qu'en fait, à cette époque-là, il n'y a aucun outil qui est dédié, tu vois, au VC. Et du coup, ils se retrouvent en fait à gérer leur... C'est pas tant leur portfolio c'est vraiment plus tu vois les VC rencontrent beaucoup beaucoup de boîtes et ils prennent beaucoup de notes et tout et en fait je me dis, on peut leur faciliter des choses c'est des API qui à l'époque sont ouvertes qui maintenant sont un peu plus fermées, comme Crunchbase ou autre où donc tu peux apporter en fait genre le mec il a un rendez-vous et en fait tout de suite tu vas lui faire une fiche avec tu vois, tout l'historique de la boîte ainsi de suite tu peux éventuellement dans ce que moi j'avais prévu mettre un système d'alerte du coup genre à chaque nouvelle version, tu vois qu'il a un petit truc pour que je rejette un oeil six mois plus tard ou autre, parce que ça faisait un peu partie de ce qu'ils font. Et ça ne matchait pas trop mal, en tout cas j'avais l'impression, avec mon côté d'envie de faire quelque chose de bootstrap, parce que les VCs ont un peu. La crainte d'avoir un outil, d'utiliser un outil qui était financé par un autre VCs. Ce qui est normal, c'est qu'à un moment donné tu te dis, attends si c'était financé par un autre VCs, est-ce que les mecs n'ont pas accès à de la data en particulier et tout. Et donc, je commence à bosser sur cet outil en faisant plein d'erreurs, en interviewant des VC, mais peut-être pas assez et tout. Et puis, en fait, rapidement, je m'aperçois que pour signer mon premier client, ça allait être un, le marché petit. Et pour signer mon premier client, en fait, t'as quand même un niveau d'attente qui est hyper élevé. Les mecs, ils veulent tous une appli mobile. Ça évolue vite. Ils voient quand même des interfaces qui, pareil, ils sont en contact avec des produits et ils ont une exigence qui, du coup, est assez importante. Donc en fait je m'aperçois vite que ça va être compliqué peut-être que je vais réussir à signer quelques clients mais pas de quoi en vivre, et en fait je me dis il faut que je reparte sur quelque chose et puis de plus simple en tout cas j'avais l'impression et donc c'est là où ce projet que j'avais de collègue que j'avais en tête depuis longtemps me revient je me dis vas-y hop je me focus dessus et je le sors en quelques mois.
Bruno:
T'avais commencé à coder sur ce projet avec les Vici ?
Alex:
Oui carrément en fait c'est pour ça que je dis la chance c'est que je me suis fait les dons sur ce projet euh, et je l'ai déployé donc en fait j'ai quand même été sur une version quasi live de ce projet, donc en ayant des contraintes de, ah tiens comment je fais pour déployer, comment est-ce que je fais pour le mettre à jour et que ça pète pas tout et ainsi de suite mais j'ai jamais eu de client payant sur ce projet là.
Bruno:
Et est-ce que sorti de ce premier test de projet, tu t'es dit ok en fait je suis suffisamment solide ou confiant pour coder celui d'après ou t'étais encore un peu.
Alex:
Non j'étais j'étais assez confiant.
Bruno:
Et en lançant ce projet sur les vici aussi tu te disais au final c'est qu'un métier ça peut s'apprendre comme un autre quoi aussi, mais donc c'était pas tant que tu trouvais pas un associé technique c'était aussi que t'avais l'envie carrément.
Alex:
Non j'avais l'envie j'avais l'envie et l'envie aussi elle vient en étant au contact de personnes qui le font, enfin je trouve, et il se trouve que moi en 2014-2015 j'étais en contact avec Vianney et François qui sont les cofondateurs de l'Aimlist, qui à l'époque avait monté une boîte qui s'appelait Talkus, donc c'était un chat un peu comme Crisp mais qui était synchronisé directement avec Slack et un autre pote Moritz qui lui avait monté, Mail Parser puis Doc Parser c'est dans ce sens là, je sais plus ouais c'est ça, qui est en fait un parseur d'email et de documents qu'il a revendu derrière un fond un espèce de petit fond de PE et tu vois et du coup ce côté, solopreneur ou en tout cas petite équipe tu vois et avoir comment dire un SaaS qui génère tu vois quelques milliers ou dizaines de milliers de MRR tu vois ça m'excitait pas mal quoi.
Bruno:
Est-ce que tu as fait un... Et tu t'es fait un planning, tu t'es fait une roadmap, tu t'es dit ok il faut que j'apprenne à coller donc on va se faire des tutos, on va se faire des formations ou t'es dit ok en fait je vais faire une première feature et puis on avance.
Alex:
Je suis un peu comme ça moi je suis un peu comme ça sur les tutos et ainsi de suite, quand j'étais chez donc en 2014 je me suis remis en fait à faire des tutos à l'époque j'avais je sais pas si il existe encore une plateforme qui s'appelait Treehouse, qui en fait est une plateforme qui permet d'apprendre à coder donc en gros t'as des espèces de tutos avec un IDE qui est intégré donc en fait derrière ils te posent des questions et dedans t'avais des formations, tu avais des formations front t'avais un peu de JS je pensais un peu de Python t'avais un certain nombre de programmes, t'as un peu de gamification en plus dedans donc tu vois il y a plein de modules que tu peux faire en 10 à 20 minutes, donc en fait t'en fais un peu tous les jours et tu vois en quelques mois ça m'avait un peu redonné confiance genre en mode ah bah tiens ok tu peux te lancer et puis après, je suis un peu en mode ok tu vois genre j'ai des idées et j'essaie d'avancer par contre je pense qu'un réflexe que j'ai eu. C'était d'essayer de bien organiser même si je suis pas en mode planifié faire des specs je suis plutôt doueur que thinker, néanmoins j'essaie quand même de le penser en me disant faut pas faire n'importe quoi, tu vois t'as des t'as des principes de base de don't repeat yourself tu vois d'essayer de faire des choses qui soient modulaires que j'ai quand même assez en tête et du coup pour essayer de bien cadrer tu vois ce que je fais quoi Alors.
Bruno:
Cette méthode dry du coup elle te vient d'où ? Parce que t'as pas eu de formation de développeur t'as pas suivi une formation technique le principe dry c'est un très bon principe bon il y a déjà des gens qui sont venus à un micro pour en débattre de est-ce que c'est utile ou pas, mais la question toute bête comment t'en as entendu parler d'où ça devient en fait cette...
Alex:
Je sais pas après tu sais ça fait partie de ta culture tu vois ce que je veux dire, on est quand même moi perso ça fait depuis 2009 que je suis à fond dans cet univers et c'est comme ça qu'on s'est connus, dans cet univers start-up et tout du coup, même si je connais pas, j'étais quand même, tu vois, genre, vraiment imprégné, j'ai bouffé, entre guillemets, des, tu vois, des plug posts, enfin, voilà, plein de choses, et même, je pense, même avant, déjà, j'avais déjà un peu ce côté, tu vois, ce côté-là. Donc, c'est quelque chose que j'ai appris, et après, après, tu vois, L'avantage ou l'inconvénient de ma formation, c'est que justement, t'as ce côté dry, tu vois, et en même temps, j'essaye d'être pragmatique. Là, si ça se trouve, je vais pas me faire de potes en disant ça.
Bruno:
Pour le moment, le pragmatisme.
Alex:
On adore. c'est que tu vois par exemple, quand j'ai fait la première version de l'API de collecte je me suis dit il faut que tu sois capable enfin il faut que nos clients soient capables en un call d'API d'envoyer une requête, j'ai horreur et je prends l'exemple de Stripe sur Stripe tu peux, créer finalement tu vois une subscription je pense, enfin créer genre le client la subscription et ainsi de suite quasiment en un call d'API. Et en fait, je trouve ça horrible quand t'es sur des API genre en CRUD, genre en mode, maintenant, un objet égal. Tu vois, une route d'API. Donc en fait, tu vas déclarer ton client. Une fois que t'as déclaré ton client, tu récupères l'ID. Une fois que t'as récupéré l'ID, tu vas pouvoir faire un look-up dans la liste de tous les abonnements que t'as et ainsi de suite. Et à la fin, en fait, t'as écrit, tu vois, 350 lignes pour faire un truc que tu aurais pu faire en un call d'API et du coup, alors moi tu vois c'est un peu l'approche que j'essaie d'avoir c'est parfois c'est peut-être pas entre guillemets pixel perfect, au sens où des puristes du code pourraient on va dire le voir mais je me dis en tant qu'utilisateur je kifferais avoir ça.
Bruno:
Ce que je te propose c'est qu'on essaye de se faire un peu, ton parcours d'apprentissage du code et la vie du scolette. Et après, parce que j'ai plein de questions, pas philosophiques, mais sur tout ça. Donc, j'imagine la première question à se poser aussi quand tu commences ton projet, c'est quel stack utiliser ? Je sens que tu es imprégné de beaucoup de choses, mais encore une fois, c'est pas ta formation. Comment tu as choisi ta stack de démarrage ?
Alex:
C'est une bonne question. Alors, ma stack de démarrage, je l'ai choisi donc je te redonne le contexte je suis chez eFounders, je suis sur le point de partir d'eFounders je veux monter ce projet là et donc chez eFounders je traîne beaucoup avec François et Vianney qui sont à l'époque en résidence, en résidence chez eFounders donc multi-projets et soutien technique et puis qui développent aussi des outils pour eFounders. Eux à l'époque utilisent MeteorJS et du coup je me dis bon, de toute façon il faut que je choisisse quelque chose j'ai qu'à démarrer sur Météor je suis au contact de comment dire je suis au contact de deux ils vont pouvoir m'aider et du coup je démarre en fait comme ça et je sais pas si t'es la bonne ou pas la bonne raison. Et aussi t'as le côté un peu ce qu'on disait tout à l'heure le côté doer, finalement je préfère démarrer avec quelque chose plutôt que de me poser la question et de faire un benchmark pendant je sais pas combien de temps au final en fait tu vois les limites de météores enfin sur certains points je les vois aujourd'hui, je les ai jamais vues avant, donc c'est pas tu vois genre pour de vrai je pense que c'était pas vraiment un sujet et puis de façon, tu vois la question s'est reposée quelques années après donc comme je t'ai dit j'ai eu ce premier projet sur le comment dire sur la partie, VC et après donc j'ai décidé de monter Collect à ce moment là j'aurais pu changer de techno et je me suis dit en fait je me suis bien fait les dents sur Meteor je commence à être à l'aise je ne vais pas dire à maîtriser mais être à l'aise avec Meteor, et à l'époque Vianney et François je pense qu'ils avaient déjà commencé l'Aimlist et l'Aimlist tu vois en termes de revenus ça commençait déjà à bien marcher, et du coup en fait tu te dis, si ça peut marcher pour eux sur cette stack là c'est que c'est pas forcément une mauvaise une mauvaise stack.
Bruno:
Le choix de se dire que tu as accès à de la compétence de ce côté-là, pour moi, c'est un excellent choix. La meilleure techno, c'est celle que tu maîtrises. De toute façon, de manière générale.
Alex:
Complètement.
Bruno:
Donc, tu commences à te lancer sur Météor pour ton projet. Il y aura une question qui rejoint un peu la question de Nicolas sur le live. C'est qu'il y a un delta entre ce que tu peux trouver comme ressource pour apprendre sur internet, versus ce dont tu as besoin en entreprise parce que tu as quand même des besoins très spécifiques en entreprise que ce soit en termes d'architecture mais que ce soit aussi en termes de performance en termes de, maintenabilité et autres qui sont pas forcément des choses qu'on trouve beaucoup, en tout cas à ma connaissance sur internet t'étais en plus aussi dans un monde très orienté startup où on parle de millions de users, de centaines de millions de users et donc tu te, est-ce que t'as réussi à te, protéger de ces faux problèmes techniques, de comment je vais faire, tu vois, comment je fais par une architecture qui va supporter un million d'users simultanés.
Alex:
Complètement. En fait, tu vois, mais ça, là-dessus, typiquement, si je reparle avec Vianney et François, tu vois, Vianney et François, là-dessus, ils sont très, on va dire, très simples, tu vois, genre, est-ce que t'as le problème aujourd'hui ? Non ? Bon, bah ok, reviens me voir quand t'as le problème. Point. Tu vois. Et en fait, il y a des choses où t'apprends au fur et à mesure et là dessus je suis d'accord avec la question de Nicolas, les premiers stress de la plateforme j'ai dû les avoir 2 ou 3 ans après l'avoir lancé, en mode où tu t'aperçois qu'effectivement ton code quand tu le relis et en plus c'est sur des parties, je vais pas dire legacy mais tu vois que t'as fait à un moment donné tu t'es pas posé vraiment la question de est-ce que c'était bien pensé ou autre, tu vois que t'as un problème de perf tu te dis tiens qu'est-ce qu'il se passe, tu regardes ton code et tu comprends tout de suite quand tu as dit ah oui effectivement ça fait beaucoup de boucles genre des boucles dans des boucles et là tu dis, effectivement je comprends que tu vois que ce soit mal que ce soit mal foutu et voilà et du coup, tes clients ils s'en sont presque pas rendus compte, c'était peut-être un peu lent à ce moment-là tu offris une réflecto et puis entre guillemets tu passes à la suite et.
Bruno:
Ça c'est aussi le c'est le côté inhérent en fait de tout développeur ou développeuse c'est cette création entre guillemets naturelle de des techniques où en fait quand tu fais un choix d'implémentation, à un instant T tu le fais en connaissance de cause de l'instant T, mais effectivement comme tu le dis deux ans après il se passe des choses qui font que ton choix d'implémentation il est remis en cause c'est pas pour autant que ton choix était mauvais.
Alex:
À ce moment là c'était le bon mais dans.
Bruno:
Le nouveau contexte c'est plus.
Alex:
Forcément adapté on est d'accord et alors après t'as des, aussi c'est un peu un trade off à un moment donné de se dire quand t'implémentes quelque chose quel est le coût marginal pour faire quelque chose qui scale ou pas tu vois, c'est vrai que par exemple moi j'ai une approche où j'ai du météor mais je me repose aussi pas mal sur des microservices, et tu vois et en fait, ces microservices ils me permettent typiquement d'avoir un côté beaucoup plus scalable sur certains points parce que tout ce qui va être consommateur de... Pas tout, mais tu vois, un certain nombre de choses qui peuvent être consommateurs de ressources au niveau du service vont être, entre guillemets, outsourcées auprès des microservices. Et en fait, à l'époque, la chance que j'ai, c'est que Meteor, donc c'est un framework qui finalement est basé sur du node, et en fait, sur du lambda, tu fais tourner soit du Python, soit du node, donc si tu veux, c'est assez facile, en fait, d'externaliser certains services sur lambda.
Bruno:
Donc tu es parti sur un environnement lambda, du coup, en serverless, complètement ?
Alex:
Enfin, complètement. J'ai une dizaine de microservices qui tournent.
Bruno:
Ok. Pas mal.
Alex:
Je te donne un exemple. Aujourd'hui, tu fais un export de tes requêtes où tu génères un zip. Ça, c'est des choses qui sont outsourcées auprès de Lambda. Parce qu'en fait, générer un zip, c'est quelque chose qui peut être consommateur de ressources. Et du coup, si t'as un mec, c'est con de faire tomber ton service pour générer un zip.
Bruno:
Sur cette démarche d'apprentissage en contexte réel de production, c'était quoi ta mécanique est-ce que je pense que si je faisais ça aujourd'hui, alors après c'est difficile à dire mais moi je pense que ma façon de faire serait été ok je veux faire une fonctionnalité ou un truc je le fais et une fois que ça marche j'essaie de voir comment je peux le refaire pour le rendre, adaptable à un contexte professionnel tu vois genre je me dis ok je teste un premier truc qui va être un peu crade je veux juste que ça marche et après je repasse dessus pour faire un truc propre toi t'as moi j'y vais direct ok ça marche on met en prod et on se pose ouais après.
Alex:
Tu vois je teste il y a beaucoup de flags en fait dans le produit qui permettent tu vois d'avoir de la modularité que ce soit d'un point de vue négatif, pricing, mais aussi pour bêta tester certains modules donc en fait j'ai eu cette approche là assez tôt et tu vois j'hésite pas, par exemple il y a quelques mois j'ai shippé, en fait sur un portail collect t'as un certain nombre d'éléments que tu peux venir afficher, donc toi t'as des éléments de récupération de documents t'as des formulaires, et il y a quelques mois j'ai rajouté un élément, tâches à effectuer et tu vois donc ce côté tâches en fait où tu vas décrire tiens crée-toi un compte à tel endroit, regarde cette vidéo fais ce genre de choses et derrière pour chaque tâche tu peux mettre des actions tu vois dessus, et ça tu vois depuis ça a dû être lancé je sais pas il y a 3-4 mois t'as un petit bandeau bêta et en fait bah s'il y a un problème contacte enfin entre guillemets c'est assumer je.
Bruno:
Vois il y a, dans ce métier de dev, il y a un truc qu'on connaît tous c'est une sensation de frustration quand on essaye de faire un truc pendant un certain temps et puis quand ça marche, il y a une espèce de, relâchement d'endorphine une espèce de kiff assez fort, qui parfois va jusqu'à un mode, ok putain je suis trop fort j'ai réussi à faire ce truc là. Est-ce que toi tu te souviens de ce premier kiff que t'as eu, où t'as passé un temps fou à te prendre la tête sur un truc et puis d'un coup tu fais en fait je suis balèze.
Alex:
Le projet peut-être qui me fait le plus penser à ça, je sais pas si c'était le premier en tout cas celui où j'ai le plus ressenti ça, c'était la mise en place d'un d'un service en serverless, pour faire de la détection de malware en gros une demande de certains clients c'était de dire on a besoin que vous checkier qu'il n'y ait pas de malware sur les fichiers qui sont uploadés, et du coup en fait comment tu le fais et un gros principe que j'ai c'est de dire tout ce qui concerne la data des clients j'essaye d'éviter d'exposer une API tiers, parce que tout devient plus galère ça veut dire que quand tu fais. Tout ce qui est RGPD et ainsi de suite si tu commences à balancer tes fichiers dans un service tiers tu complexifies d'un seul coup ton cycle de vente de malades, donc quid de comment est-ce que je fais pour les checker alors maintenant Amazon a une solution à l'époque il n'y avait pas, et du coup je me dis il faut que je trouve une sorte d'anti-malware que je puisse installer avec la problématique qu'il faut que, je vais dire une bêtise parce que je pense que ce n'est pas le bon terme que ce n'est pas ta librairie mais que ton référentiel si tu veux de malware soit toujours à jour parce que tu vois s'il n'est pas à jour en fait si t'as un nouveau malware qui sort et que la dernière mise à jour date d'il y a 6 mois ça marche pas, donc en fait j'avais cette problématique là de comment est-ce que je peux monter, un service en lambda pour vérifier, pour faire tourner un anti-malware, open source qui vienne vérifier les fichiers qui sont uploadés et me renvoyer la data auprès de collègues pour que je puisse les flaguer si c'est le cas, et ça j'ai passé quelques, nuits dessus trouver la bonne architecture le bon mode de fonctionnement et ouais et là ce jour là je me suis dit ok je crois que j'ai, passé un step et quand je repense tu vois au quelques années avant mince je fais comment pour déployer et ainsi de suite il y a eu la.
Bruno:
Sensation que t'avais franchi un gap.
Alex:
Ouais bah je pense que j'ai un niveau maintenant technique qui est pas trop mal.
Bruno:
Et pour terminer t'as accueilli un développeur dans ton équipe comment ça s'est passé ce moment là où tu fais venir un professionnel qui a un diplôme certifiant sur ce métier là, et où tu lui donnes un peu les clés du camion.
Alex:
Écoute déjà j'avais été un peu réfractaire Il y a.
Bruno:
Un peu de peur, un peu d'appréhension.
Alex:
Ouais t'as vachement de peur parce que tu bah déjà, Moi, j'avais la peur, et c'est pour ça que je ne l'ai pas fait tout de suite, de qui je vais accueillir, est-ce que je peux avoir confiance dans quelqu'un. J'avais eu des potes qui s'étaient fait tirer leur code base d'un projet en l'outourissant, et du coup, qui s'étaient retrouvés à avoir un concurrent qui était sorti avec leur code base, pour faire simple. Donc, tu te dis « Merde, je n'ai pas envie que ça, ça m'arrive. » Et donc, je me suis dit comment je peux faire, pour ne pas que ça m'arrive la bonne nouvelle c'est que comme je te le disais j'ai un certain nombre de choses par exemple qui sont en serverless donc tu vois par exemple de ce point de vue là je m'étais dit je vais lui donner accès à l'app météor mais pas à cette partie là, ensuite il a un environnement de dev qui est complètement différent de la prod donc tu vois il a accès à aucun des services qui sont en prod, tu vois il n'a pas accès à aucune clé d'API en prod alors ça complexifie un peu sur le moment où tu vois où tu donnes les clés pour qu'il puisse, jouer avec mais bon ça te sécurise sur le...
Bruno:
Mais donc du coup c'était pas une appréhension sur le fait que quelqu'un à l'autre allait voir.
Alex:
Donc ça c'est la première partie et ensuite t'as la partie le jour où tu le rajoutes sur github et tout là tu dis bon qu'est-ce qu'il va en penser alors, c'est assez marrant parce que, le seul point qu'il a dit et qui va revenir à la question à ta dernière question du podcast, c'est qu'à l'époque moi je faisais des tables et lui il voulait à tout prix que des espaces et donc en fait franchement sur plein de choses il n'y a pas eu trop de soucis, mais il y a 2-3 trucs sur lesquels on n'est pas mais c'est plus des questions de mise en forme en fait c'est pas vraiment sur le code c'est plus sur. La façon dont on va structurer le code typiquement, espace ou table où lui par exemple tous les arguments il va les mettre en ligne donc tu vois genre si t'as 15 arguments qui sont passés dans une fonction en fait il va les passer sur 15 lignes, moi j'ai un écran de 34 pouces donc en fait ça m'arrange que ce soit sur une ligne. Et de ne pas les avoir comme ça lui je ne sais pas ce qu'il y a comme écran mais du coup il a ce côté de ce truc là donc moi quand je reprends son code c'est relou, je suis obligé de passer mon temps à scroller, c'est des choses comme ça mais sinon après honnêtement ça s'est bien passé ce que je lui ai fait par contre comme onboarding, alors j'ai la chance c'est qu'il était tout seul donc c'est pas la même chose que quand t'onboardes, un développeur tous les X jours sur un projet ? Ce que j'avais préparé quand il arrivait, c'est un certain nombre de cartes. Alors moi, j'utilise Trello. Je suis un peu à l'ancienne là-dessus, mais c'est comme ta stack technique, tant que ça marche. Ce qui est important, c'est avec quoi tu es à l'aise. J'ai préparé un certain nombre de cartes de plein de petites améliorations, mais qui se retrouvent à plein d'endroits de l'interface et du code. Et du coup, ça a fait un peu une piscine, mais tu vois, genre en mode, bah en fait du coup t'es obligé de te lancer et c'est pas genre je vais pas demander de faire, un nouveau module complètement standalone qui soit pas du tout intégré avec le reste du code et auquel cas tu vois je pense c'est compliqué tu vois d'appréhender le reste de la code base là l'avantage c'est qu'il y en avait un peu partout donc il était obligé tu vois de comprendre comment j'avais organisé le projet, et de suggérer des choses dessus.
Bruno:
Mais du coup j'imagine une certaine satisfaction de pas avoir un dev qui arrive et qui.
Alex:
Lève les.
Bruno:
Yeux au ciel en mode, mais c'est n'importe quoi en fait ouais.
Alex:
Déjà et puis aussi de toute façon il y a autre chose, effectivement une satisfaction mais limite je suis un peu caricaturé mais satisfaction je m'en fous, je sais pas trop comment dire, ce qui était important pour moi c'était plutôt que cette décision d'onborder un dev soit la bonne et que derrière en fait on puisse bosser ensemble parce que tu vois s'il m'avait dit, ta code base c'est de la merde et il faut tout refacto en fait je pense que la réponse aurait été bon bah ok on arrête de bosser ensemble parce que pour de vrai, au moment où il est arrivé j'avais déjà pas mal de clients et ça tournait donc tu vois genre, je l'aurais pas pris tu vois genre en mode ah ouais ok tiens on va passer 6 mois à tout refacto et je vais te payer entre guillemets à rendre le code comme t'as envie qu'il soit donc tu vois genre et je pense malgré tout enfin pour revenir là dessus, c'est pas non plus un effort qu'il a fait tu vois genre en mode de toute façon on a pas le choix il va rien entendre tu vois genre c'est voilà ça marchait quoi.
Bruno:
Et donc le choix d'embarquer quelqu'un sur cette partie là en fait c'était juste pour te donner toi les moyens de faire autre chose dans la boîte ou il y avait aussi un côté de te dire bon bah j'ai peut-être besoin d'avoir, un nouveau regard, quelqu'un dont c'est le métier qui peut apporter quelque chose sur certains...
Alex:
C'est vraiment le côté me libérer du temps pour pouvoir faire plus de marketing et de sales. Parce que j'en fais vraiment pas assez. En fait, aujourd'hui, j'ai un produit qui pourrait faire on va dire 5 à 10 fois plus de revenus en ayant le même produit. Donc, il y a un vrai problème. J'espère que ma femme n'écoute pas ça. Il y a un vrai problème de marketing, de faire plus de marketing pour le faire connaître et tout. Et à côté de ça. Je ne lui délègue pas que les trucs qui sont à faible valeur ajoutée, mais le côté architecture, je continue de le garder. L'architecture, c'est moi qui continue de le faire. Et je pense en toute sincérité être plus fort là-dessus que ce qu'il peut me proposer. En revanche, ce qui est sûr c'est qu'en termes d'exécution si tu veux, en fait lui il est dédié à ça donc tu vois moi si j'ai des calls clients si j'ai quoi que ce soit, où je peux très très vite perdre une semaine enfin tu vois, ça tu connais mais en fait ça peut arriver tu commences, t'es dans le rush, t'as bossé mais en fait à la fin de la semaine tu sais pas trop sur quoi t'as bossé, et en fait si pendant cette semaine là j'avais dû coder, à la fin de la semaine en fait tu regardes ton github et t'as 5 commits et pas beaucoup de choses dedans donc tu peux vite perdre des semaines là l'avantage c'est qu'en fait j'ai quelqu'un qui maintient le rythme qui est obligé, qui va commit tous les jours et qui avance tous les jours donc ça c'est un énorme avantage pour garder du je vais prendre un anglicisme enfin si je pourrais dire du rythme mais j'aime bien le terme pace en anglais tu vois le côté rythme mais, vraiment de délivrer tout le temps ok.
Bruno:
Canon et d'un dernier aspect sur cette construction, est-ce qu'il y a eu beaucoup de réécritures nécessaires c'est souvent le cas, tu le disais tout à l'heure tu rouvres ton code 2 ans après tu fais ah ouais en fait, parce que tu progresses quand même drastiquement de mois en mois est-ce que tu t'es astreint à souvent réécrire des choses ou au final tant que ça tourne.
Alex:
C'est une bonne question. Aujourd'hui ça fait pas partie des tâches qui sont programmées de dire tiens il faut refacto ça ou ça, en plus je suis pas convaincu aujourd'hui j'ai l'impression que l'IA peut nous aider et en tout cas moi m'aide beaucoup par exemple pour faire de la refacto je trouve qu'en fait, si tu restes au scope par exemple d'une fonction tu prends ta fonction, tu lui dis, optimise-la moi et en fait tu vas avoir un output qui en deux secondes t'as fait une refacto ou t'as proposé deux trois trucs qui peuvent être pertinents, j'aurais plus tendance à avoir cette approche là que de dire tiens on va refacto ça ou ça, après là où on fait des refactos c'est quand t'as des problèmes soit de perf ou autre ou tout simplement parce que, on est en train de faire bouger une partie du produit et du coup il faut faire... Il y a une réflecto quand même qu'on a faite, enfin qu'il a faite pour le coup c'était tous les settings tu vois en fait, Et je ne sais pas comment les auditeurs fonctionnent sur leur projet, mais je trouve que souvent, on a tendance, d'un point de vue produit, à bien penser l'aspect, on va dire, produit principal. Mais il y a souvent le corrélaire de produit principal qui est toute une partie settings que tu vas rendre modulable, ou en tout cas que des clients vont te demander de rendre modulable. Et donc tu te retrouves en fait avec des settings qui deviennent un peu un Frankenstein parce qu'à un moment donné t'as eu besoin de mettre quelques champs pour rendre ton app modulable et du coup ça tu le fais, t'as pas de spec dessus, t'as pas de design, tu te dis c'est bon on va le faire à l'arrache et en fait au bout de quelques mois ou quelques années t'as des settings qui sont dégueulasses, qui ressemblent à rien et à un moment donné on s'est dit attends on va rendre le truc clean mais ne serait-ce que d'un point de vue, lisibilité et tout et du coup on a refait ces parties là.
Bruno:
Est-ce qu'il y a eu des moments aussi où tu étais en train de coder une nouvelle fonctionnalité qui t'a, comme t'as progressé qui t'a amené à faire des changements plus ou moins structurants qui t'ont obligé à retravailler.
Alex:
D'autres fonctionnalités.
Bruno:
Qui tournaient bien jusque là.
Alex:
Ouais ça arrive souvent Ouais ça arrive souvent faut pas, hésiter effectivement si tu vois des choses tu vois à les améliorer après je reprends ce que je disais sur le dry tout à l'heure, tu vois j'essaye de faire en sorte d'avoir un certain nombre de dans la code base en fait d'avoir des des composants alors pas au sens pas comme react ou autre mais tu vois par exemple je sais pas sur, le check de features la sécurité, des choses comme ça qui soient très réutilisables et du coup d'avoir une approche assez pragmatique enfin vraiment dessus et en fait du coup ça rend aussi le truc plus simple parce qu'en fait le jour où tu veux, le changer, t'as juste ton composant à changer t'as besoin de le faire qu'une fois donc ça aide un petit peu après je suis pas non plus un ayatollah comme ce que tu peux avoir en React, tu fais tout nickel même en TypeScript j'en suis pas encore à ce point là top.
Bruno:
Pour passer aux questions un peu plus philosophiques est-ce qu'après cette expérience, ta perception du métier de dev a changé et c'est quoi pour toi être dev, on verra après est-ce que toi tu te sens dev mais j'aimerais déjà savoir, toi ta vision de ce métier là est-ce que ça a changé grâce à cette expérience et pour toi c'est quoi les composantes d'un développeur ou d'une développeuse.
Alex:
Ouais ça a changé forcément ça change parce que quand t'es vraiment les mains dedans tu réalises différemment après ce qui me manque un peu c'est ce côté tu vois je serais curieux, un jour, enfin non, c'est pas une volonté du tout, mais tu vois, si j'avais pu être dev dans une autre équipe, de voir si j'aurais été un bon dev ou pas, tu vois, et ça du coup, c'est quelque chose que je connaîtrais pas, en fait, tu vois ce côté, est-ce que finalement, enfin ou alors t'es encore jeune.
Bruno:
On sait pas oui.
Alex:
Je suis encore jeune, mais tu vois, même si demain, je sais pas, j'intégrais une autre équipe tu vois, avec Collect, je suis pas aujourd'hui, je me, je sais pas si on me donnerait tu vois, une casquette technique ou plus business ou autre tu vois, maintenant, j'ai eu toute une période où je me sentais quand même, un peu trop dev justement parce qu'en fait je passais 80 ou 90% de mon temps à faire du produit, et donc un jour je me suis retrouvé à un dîner et je me suis présenté comme un dev et là ma femme m'a fusillé de regard, elle m'a dit mais en fait t'es pas dev, t'es entrepreneur, il se trouve que tu fais du code mais tu vois elle m'a un peu repris comment dire, elle m'a un peu repris là dessus, donc ouais ma première casquette tu vois c'est d'être entrepreneur d'avoir ce business là et après il se trouve que je sais coder.
Bruno:
Et donc c'est quoi pour toi aujourd'hui les composantes pour être.
Alex:
Un bon dev.
Bruno:
Ou une bonne développeuse.
Alex:
C'est une bonne question. Je pense qu'aujourd'hui... J'aurais tendance à dire... Ça va te paraître... J'ai peur de dire une bêtise. En fait, je pense qu'aujourd'hui, un bon dev ou une bonne développeuse, c'est quelqu'un d'humble parce que tout le knowledge, qu'on a accumulé pendant des années ne sert plus à rien. Enfin, tout le knowledge. Le fait de savoir écrire du code ne sert plus à rien. Honnêtement, ça ne sert plus à rien. Maintenant, je pense qu'il faut être très humble. Et en fait, c'est un fait. Et en fait, il faut l'admettre et travailler avec. Après, je pense que du coup, partant de ce principe-là, ton... On va dire ton boulot, à partir de là, c'est de dire ok maintenant que je sais ça comment est-ce que je peux on va dire levrager tout ce qu'on a autour pour mieux coder, et du coup c'est quand il le faut faire appel à une IA pour coder ou faire des recherches mais en tout cas je trouve plus qu'il y ait vraiment de. De savoir le savoir c'est plus vraiment quelque chose c'est devenu une commodité, en revanche là où il y a une valeur aussi c'est le côté tu vois Enterprise comment il s'appelait l'auditeur tout à l'heure ? Nicolas tu vas parler tout à l'heure c'est qu'en fait il y a plein de best practices, sur des projets qui ne sont pas des, qui ne sont pas de la technique en fait mais qui sont des réflexes que tu vas avoir d'architecture, d'organisation, qu'en fait t'apprends sur le tas en entreprise j'ai essayé de trouver un jour, un ouvrage de référence mais en fait je ne l'ai jamais trouvé, qui en fait sont pleins de savoir faire et ça je pense qu'effectivement c'est aussi une valeur et que là où tu vois je ne sais pas un cloud va être très bon pour coder, sur le côté vraiment tu vois, syntaxe par contre il va pas forcément tu vas avoir la logique métier que toi tu vas pouvoir avoir derrière tu vois, et je trouve que ouais t'as des trucs mais tu vois moi je m'étais dit mais c'est quand même bizarre qu'un jour y'a pas un mec qui fait une librairie enfin une librairie, un bouquin sur voilà tous les, composants entre guillemets tu vois une toolbox tous les composants dont tu pourrais avoir besoin le jour où tu montes un SaaS, et voilà comment tu peux les articuler. Toi, je te donne un exemple tout con, mais...
Bruno:
Alors, je pense qu'il y en a qui ont essayé, mais on est face à une contrainte, et c'est ce que t'évoques un peu en parlant de toute cette notion d'expérience, c'est qu'en fait, les contextes sont tellement différents, et en fait nécessitent très souvent des réponses hyper adaptées. C'est-à-dire que tu peux pas... C'est ce qui est en train de... Il y a une discussion entre Nico et, Pironel qui est effectivement la personne à qui tu pensais tout à l'heure qui est en train d'en parler dans le chat, et du coup il le dit si tu fais un outil bancaire B2C il y a un contexte à prendre en compte tu ne fais pas de la même façon, que pour faire un Airbnb ou pour faire un Uber Eats ou faire un truc pour commander des Nike et donc le, Le one size fits all n'existe pas.
Alex:
Mais néanmoins, tu vois, t'as des best practices. Alors maintenant, tu vas me dire, oui, les frameworks le font, mais tu vois, je sais pas si tu prends l'exemple d'un reset password, tu vois, des trucs tout bêtes comme ça, tu vois. En fait, à un moment donné, tu vois...
Bruno:
Eh ben, pareil, c'est pas si simple que ça. Parce qu'en fait, il y a des contextes différents et on prend encore, tu vois, t'as l'exemple de la banque. J'en discutais, je crois, c'était avec Frédéric de Dashlane. Je lui disais, moi je ne comprends pas que sur beaucoup de banques ton code, le code secret qu'on te demande de définir, c'est un code à 6 chiffres, en termes de sécurité c'est une tannée et il me dit, oui mais en fait le problème de ta banque c'est qu'elle doit s'adresser aussi bien à des gens comme toi et moi qui sont hyper taxavis ou tous nos auditeurs et auditrices qui sont des gens hyper taxavis et qui peuvent avoir un gestion de password qui leur fait un mot de passe de 25 caractères de long, avec tous les types de caractères possibles et imaginables, mais il faut aussi s'adresser à une mamie, ou un papy qui est au fin fond de la France et qui n'a jamais spécialement travaillé avec les technologies donc il faut que tu sois utilisable par tout le monde et donc t'as des contraintes, t'as un contexte qui fait que bah en fait, même un truc de reset de password bah tu peux pas le faire de manière universelle parce que t'as des clients qui sont, tu sais que moi j'ai un exemple assez fou, j'ai travaillé une des boîtes que j'avais donc auction.fr qui était un site de vente aux enchères d'objets d'art. Il y a un truc que je raconte souvent c'est que moi j'avais refait complètement le front, j'avais refait la page, de description de chaque objet et j'avais passé une semaine entière à refaire le CSS pour que quand t'imprimes la page sur une feuille A4, ça se fasse une jolie mise en page pour une page A4 et pas juste une impression de la page web c'est pas le même contexte, donc tu fais une impression différente, je mets ça en prod et il y a quelqu'un qui débarque dans mon bureau en panique en me disant Bruno on a un problème, on peut plus imprimer, Et donc moi je ne comprenais pas, je dis « Attends, je teste, je joue un objet, je l'imprime, ça marche ». Elle me dit « Mais comment t'as fait ? » Je dis « Bah j'ai fait pomper en fait ». Elle me dit « Ah mais je ne savais pas qu'on pouvait faire ça ». C'est parce qu'en fait dans ma nouvelle conception de la page, j'avais retiré le bouton « Imprimer » sur la page. Et en fait, il y a des gens qui m'ont appelé en disant « On ne peut plus imprimer votre site ». Parce que les gens savent pas.
Alex:
En fait.
Bruno:
Tu vois ce que je veux dire ? On n'est pas tous égaux face à ces trucs-là. Donc, il n'y a vraiment pas de one size fits all. Est-ce que... Tu nous as dit qu'aujourd'hui, tu ne te sens pas forcément développeur, tu te sens avant tout entrepreneur.
Alex:
Déjà, maintenant, je code moins. Je code moins, donc déjà, ça aide à me ressentir un peu plus entrepreneur et un peu moins développeur, non il y a quelques mois je t'aurais dit développeur donc ça, j'échange mes casquettes, mais effectivement j'essaie de mettre plus en ce moment ma casquette entrepreneur, et faire plus la promotion de collecte et tu vois de vraiment tout faire pour trouver plus de clients et tout que d'avoir ce côté tu vois, avoir une super features mais dont personne se sert parce que il n'en a pas entendu parler.
Bruno:
Si tu devais recréer une boîte demain, est-ce que tu te remettrais à coder ou est-ce que tu ferais des choix différents ?
Alex:
Non, je pense que j'essayerais... Enfin, je pourrais coder. T'as aussi un... D'ailleurs, je fais une parenthèse là-dessus, mais... Il y a aussi un côté, tu vois... On parle souvent de product market fit. Mais tu vois, t'as aussi le côté product entrepreneur fit, tu vois. Enfin, où t'as un côté fit avec la personne, tu vois. Il faut que tu kiffes ce que t'es en train de faire et coder fait aussi partie des choses que je kiffe donc je pense que je kifferais peut-être au début contribuer si je devais monter une boîte peut-être faire les débuts du projet par contre effectivement je pense qu'à travers l'expérience que là j'ai en ce moment avec mon développeur, je pense que j'essayerais de monter, soit de le faire avec lui ou avec d'autres personnes, proches de lui parce que ça marche bien avec sa mode de fonctionnement qui me va bien et je pense qu'il me permettrait d'aller plus vite sur un prochain projet Ok.
Bruno:
Canon Merci beaucoup Alex pour cette discussion Avec un plaisir Pour terminer j'aurais deux dernières questions pour toi qui sont les questions rituelles du podcast La première c'est est-ce qu'il y a un contenu que tu souhaiterais partager avec l'ensemble des auditeurs ici ?
Alex:
Alors oui, parce que j'ai travaillé j'ai anticipé ta question sinon je ne sais pas d'ailleurs s'il me serait venu tout de suite c'est un article je te l'enverrai, c'est un article médium, qui explique comment Canva a économisé je crois 22 millions de dollars, sur de l'optimisation S3, et article que j'ai trouvé super intéressant en gros pour faire un peu l'historique donc Canva ils utilisent S3 pour stocker tous les assets qui sont utilisés sur leur plateforme et en fait la problématique qu'ils ont c'est que, cette ligne de coût elle fait qu'augmenter parce que tu vois en plus Canva ils ont un plan gratuit donc tu vois les assets ils font que s'accumuler il n'y a pas vraiment tu vois de côté bah tiens on en a plus besoin, on les enlève, et donc en fait ils ont au début, et ça rebondit avec ce que tu disais tout à l'heure dans un contexte donné c'était la bonne décision à prendre les mecs au début ils ne se sont pas trop posé la question, t'as un upload, tu l'envoies sur le bucket le plus proche ou je sais pas quoi, le plus adapté et puis voilà, la facture monte la facture monte, puis à un moment donné t'as un mec. Chez eux qui se dit comment est-ce qu'on pourrait faire pour optimiser la facture, et donc là ils se rendent compte que dans l'offre AWS t'as, un type de S3 c'est les glaciers donc en gros c'est des assets dont t'as plus besoin ou moins besoin donc tu les conserves sur S3 mais ils sont moins accessibles donc je pense que c'est plus lent il y a beaucoup plus de l'avance donc en fait ils se posent la question de migrer tous les assets qui ont été uploadés depuis plus de 6 mois et qui n'ont pas été consultés dessus, et puis en fait ils font ça à petite échelle et là ils se rendent compte que, genre il y a un coût de t'as un coût de transfert en fait de la donnée et t'as, forcément le coût de stockage tu vois qui va diminuer, en fait ce qui est hyper intéressant dans cet article là c'est qu'à un moment donné t'as quelqu'un qui a un peu réfléchi qui s'aperçut que genre si c'est un asset qui fait 3 kilobits ton coût de transfert en fait ça va être l'équivalent de 3 ans de stockage, sur S3, donc en fait tu vois, tu as un moment donné, tu as un espèce de truc où tu peux te dire, attends, ça se trouve celui-là en fait, il ne faut pas le transférer, parce que, en fait, il nous coûte moins cher de le conserver sur S3 que de le conserver, tu vois, sur, le glacier, et donc en fait, ils ont fait c'est là où c'est intéressant ils ont commencé à vraiment se poser la question de ok, comment est-ce qu'on définit vraiment la bonne règle, tu vois, d'archivage des assets pour que, ce soit intéressant, tu vois, de les transférer et à quel moment on a le payback dessus.
Bruno:
Quoi. avant de passer à la dernière question rituelle on a une question qui a apparu dans le chat qui est intéressante que je vais te poser est-ce qu'il y a un moment où t'as senti, des limites où tu t'es senti freiné ou bloqué parce que justement c'était pas ta formation d'origine c'était pas ton métier.
Alex:
Ça m'est arrivé, alors pas beaucoup j'ai de la chance, j'ai touché du bois alors déjà jusqu'à présent on a réussi, récemment on mais en tout cas j'ai réussi à shipper tout ce que je voulais shipper, donc il n'y a jamais eu de côté ah tiens on a un projet mais en fait on n'y arrive pas tu vois genre on est bloqué et tout, après c'est plus là où, je vais pas dire j'ai atteint mon seuil d'incompétence mais là où c'est un peu plus je trouve, flippant, c'est sur le côté RevOps. Mais d'ailleurs qui n'est pas que pour moi, c'est la même chose pour plein de devs. Quand tu n'as pas de RevOps dédié, c'est quand même un autre métier. Et tu as des moments où tu peux te dire « Attends, Là, tu vois, si ma CI, elle est cassée, je fais comment pour déployer ? Et où, en plus, c'est des choses qui n'arrivent pas très souvent, mais où, du coup, tu as du mal à accumuler du knowledge dessus. Je sais pas ce que je veux dire en fait ça va être j'ai eu le cas une fois. Ce que j'utilisais pour déployer c'était j'avais un problème dessus et j'arrivais plus à déployer j'avais un bug qui était fixé je pouvais pas le fixer je pouvais pas le déployer en prod et là tu te sens quand même vraiment très très con et, en fait donc là tu te dis merde mais en fait je fais concrètement tu vois je fais, comment tu vois et donc après tu le fixes mais pour de vrai ça arrive pas très souvent donc en plus, ouais tu vas le mettre dans une knowledge base mais ouais c'est vraiment c'est plus sur cette partie là où parfois je me dis ouais j'aimerais bien tu vois maîtriser un peu plus cette partie là quoi.
Bruno:
Top et donc la dernière question la question riche du podcast est-ce que tu es plutôt espace ou tabulation.
Alex:
? Maintenant je fais espace très bien merci beaucoup Alex Merci Bruno.
Bruno:
Et merci à tous d'avoir participé à cette discussion voilà ça montre qu'effectivement le dev est un métier accessible à toutes et à tous ça montre peut-être aussi qu'au final Alex il avait peut-être quand même déjà un peu cette fibre derrière lui que c'était juste le moment de l'exprimer, en tout cas voilà on fait un métier formidable et je trouve ça super qu'il y ait des tas de gens qui s'y frottent, parce que c'est effectivement quelque chose qui est génial à faire, je vous remercie à tous, je vous souhaite une très bonne année 2025 parce que normalement on devrait à peu près en janvier. Donc, c'est le moment de vous souhaiter une très bonne année. Je vous remercie, comme toujours, de partager ce podcast autour de vous. Je vous souhaite une très bonne fin de semaine. Je vous dis à la semaine prochaine. Et d'ici là, codez bien !
