Podcast Le SAV de la Tech


En s'appuyant sur leur expérience et une bonne couche d'autodérision, Jérémie et Adrien répondent aux questions non techniques mais compliquées des gens de la tech: dévs, tech leads et managers. Au programme: conflits entre collÚgues, soft skills pour les désamorcer, négociations salariales, développement de carriÚre... Nous répondons à VOS questions, alors: à vos claviers !
Cette semaine, le SAV de la Tech rĂ©pond Ă la question de Gwendoline:"Bonjour Adrien, Bonjour JĂ©rĂ©mie,J'ai un question "onboarding" Ă vous soumettre.Je viens de connaĂźtre une trĂšs mauvaise expĂ©rience Ă ce niveau qui m'a amenĂ©e Ă rompre ma pĂ©riode d'essai et malheureusement Ă quitter la boĂźte.DĂšs le dĂ©part les flags Ă©taient au red :Personne pour nous accueillir le premier matin du premier jour, on a dĂ» attendre une heure Ă l'accueil que les responsables arrivent đ¶.Je me suis retrouvĂ©e seule toute la premiĂšre semaine car la personne chargĂ©e de m'accueillir Ă©tait soit malade soit en tĂ©lĂ©travail et personne ne l'a remplacĂ©e.Peu de senior disponibles pour l'encadrement et pas trĂšs Ă l'aise avec l'idĂ©e.Plusieurs personnes intĂ©grĂ©es en mĂȘme temps (3 juniors et 1 stagiaire) dans une Ă©quipe accueillant dĂ©jĂ 3 alternants, qui ont fait l'essentiel de l'accueil des nouveaux comme ils pouvaient.1 manager trĂšs dĂ©sordonnĂ©, donnant l'impression de ne pas savoir quoi faire de moi et qui a essayĂ© de m'introduire trĂšs maladroitement sur le code du projet avec des cours particuliers d'architecture trĂšs gĂ©nĂ©raux sans lien avec mes tĂąches du moment. Un 1-1 a Ă©tĂ© mis en place au bout de 3 semaines mais arrĂȘtĂ© dĂšs que j'ai pu dire que c'Ă©tait trĂšs aidant đ¶.Et pour couronner le tout un changement radical sur la mission principale dont j'aurais dĂ» m'occuper. Je devais migrer des composants d'angular.js vers vue3 et finalement en arrivant on m'a dit qu'on Ă©tait pas prĂȘts Ă m'accueillir, pas prĂȘt Ă partir sur ce projet (qui en fait se discute depuis 2 ans đ±) et qu'en attendant on allait me faire faire du design system.Moi qui m'Ă©tait assurĂ©e que c'Ă©tait un poste oĂč je pourrais rapidement Ă©voluer du front au fullstack je me retrouvais Ă ne faire que de l'intĂ©gration.Si on ajoute Ă cela un management trĂšs Ă l'ancienne empreint de paternalisme et de surveillance....je ne m'y suis pas retrouvĂ©e du tout.Du coup j'aimerais savoir quoi attendre d'un bon onboarding, dans l'Ă©quipe mais aussi sur le projet lui-mĂȘme ? Comment c'est censĂ© s'organiser dans l'idĂ©al ? Et comment se positionner soi-mĂȘme pour que ça se passe au mieux, voire rectifier le tir si ça part en cacahuĂšte ?"Ăpisode enregistrĂ© pendant l'Ă©tĂ© 2025.Mastering audio automatisĂ© par auphonic.com.CrĂ©dits musique: "Guess Again", provided by https://slip.stream
Cette semaine, le SAV de la Tech rĂ©pond Ă la question de Philippe:"comment convaincre mes devs Ă complĂ©ter la documentation de notre produit au fur et Ă mesure des Ă©volutions ? Non seulement câest important pour les utilisateurs du produit, pour le support mais aussi pour que les devs trouvent rapidement des rĂ©ponses aux questions quâils se posent pendant leurs taches.Par exemple, un dev Ă bloquĂ© une semaine sur sa tache parce que le collĂšgue qui Ă©tait expert sur une partie du produit Ă©tait en vacances. Si son expertise avait Ă©tĂ© documentĂ©e, on aurait pu Ă©conomiser cette semaine.Parfois mĂȘme, les dĂ©veloppeurs se contentent de laisser un commentaire sur une page de documentation, pour proposer dâeffectuer un ajout ou une modification, au lieu de faire la-dite modification directement !Certes la documentation est centralisĂ©e dans un outil dĂ©diĂ© dont lâergonomie nâest pas top, mais il reste possible de faire un copier-coller depuis Word par exemple.Bref, je suis preneur de vos conseils si vous en avez !"Ăpisode enregistrĂ© pendant l'Ă©tĂ© 2025.Mastering audio automatisĂ© par auphonic.com.CrĂ©dits musique: "Guess Again", provided by https://slip.stream
Cette semaine, le SAV de la Tech rĂ©pond Ă la question de Gilbert:"J'ai 13 ans de carriĂšre, j'ai suivi beaucoup d'entreprises, parfois malheureuses. J'ai beau avoir managĂ© plusieurs Ă©quipes et toujours avoir eu de bons retours de ma direction et de mes Ă©quipes, je n'arrive pas Ă me vendre maintenant que je suis Ă nouveau sur le marchĂ© de l'emploi. Ma carriĂšre ne m'a pas incitĂ© Ă suivre la derniĂšre mode, mĂȘme si je sais que je peux prendre en main n'importe quel outil, mon CV dĂ©tonne. Comment aborder les recruteurs en commençant Ă ĂȘtre un dinosaure alors que le web change tous les 4 jours ?"Ăpisode enregistrĂ© pendant l'Ă©tĂ© 2025.Mastering audio automatisĂ© par auphonic.com.CrĂ©dits musique: "Guess Again", provided by https://slip.stream
Cette semaine, le SAV de la Tech rĂ©pond Ă la question de RĂ©mi:"Salut salut salut ! Je suis tombĂ© sur votre podcast et je m'y accroche comme Ă une bouĂ©e dans un tsunami de podcast vides gĂ©nĂ©rĂ©s par LLM đ , alors merci !Petite question carriĂšre : comment dĂ©finiriez-vous les rĂŽles de "staff" ou "principal" engineer ? J'ai l'impression d'en repĂ©rer de plus en plus dans la tech en France, mais la dĂ©finition semble assez floue.Exemple: j'ai Ă©voluĂ© de fil en aiguille comme un rĂ©fĂ©rent clean code, observabilitĂ© et architecture de systĂšmes dans une startup, en proposant notamment des librairies/package pour faciliter certaines bonnes pratiques, est-ce que ça fait de moi un bon candidat Ă un poste de staff dans une autre boĂźte ?La question me semble intĂ©ressante si ce chemin de carriĂšre s'offre comme alternative Ă "monter en management", sans perdre en influence. Mais certains jours je me demande si ce n'est pas juste ĂȘtre senior++ đ .Bonne semaine Ă vous deux !"Ăpisode enregistrĂ© en Mai 2025.Mastering audio automatisĂ© par auphonic.com.CrĂ©dits musique: "Guess Again", provided by https://slip.stream
Cette semaine, le SAV de la Tech rĂ©pond Ă la question de Kevin:"Bonjour,Je suis dev depuis presque 4 ans. DĂšs les premiers mois dans ma premiĂšre entreprise, une agence web de 6 personnes, je me suis rendu compte des problĂšmes que posaient du code legacy. On utilisait un CMS maison, plein de code mort, mes 4-6 premiers mois ont Ă©tĂ© Ă 80% de debug la codebase. Dans l'entreprises suivants, mĂȘme soucis, du code legacy trĂšs vieux, du gatekeeping, un rejet du changement, ou forcĂ© par les managers qui expliquent comment coder. Dans mon entreprise actuelle j'ai plus de marge de manĆuvre mais les tĂąches Ă faire rĂ©duisent les possibilitĂ©s, crĂ©ation de back office avec seulement du CRUD, sans rĂšgle mĂ©tier.J'ai vite compris que je recherchais plus que juste faire du code, qui marche plus ou moins, et aprĂšs des recherches je suis tombĂ© sur BenoĂźt Gantaume avec son podcast artisan dĂ©veloppeur et il y a eu un dĂ©clic.Je suis tombĂ© dans le craft, appris le TDD, clean code, DDD, design pattern et d'autres outils par la lecture, les vidĂ©os, podcast etc.Et pendant cet apprentissage j'ai aussi cherchĂ© un nouveau poste oĂč la qualitĂ© logiciel Ă©tait prĂ©sente, ou Ă minima recherchĂ©.Mais les boĂźtes qui pratiquent ce genre de mĂ©thodologie sont inexistante dans ma rĂ©gion (Nice), ou trĂšs bien cachĂ©, et celles que je trouvais, mĂȘme lors d'annonce pour des juniors, avaient des exigences trĂšs hautes, des expĂ©riences professionnel avec une mise en place de clean architecture, DDD etc.J'ai fait plusieurs entretiens, plusieurs tests techniques, avec des feedbacks positif, mais Ă chaque fois ça finissait par un refus par choix d'un candidat avec plus d'expĂ©rience, ou dans quelques rare cas, avec une proposition de salaire vraiment basse.Je fais des projets personnels oĂč je met en place ces outils, je fais des katas, mais je ne suis toujours pas au niveau des attentes des entreprises.J'ai vĂ©cu un soucis similaire avec le monde startup, oĂč ils demandent de l'expĂ©rience en startup, sans laisser de chance Ă ceux qui n'en ont pas encore.Je me doute que le climat actuel du recrutement n'est pas le plus propice pour les dĂ©v peu expĂ©rimentĂ©.AprĂšs ce monologue, la question est, comment faire pour rejoindre une boĂźte comme Shodo, ou une autre qui pratique le craft, quand le contexte de l'entreprise ne permet pas de mettre en place ces pratiques, que l'on apprend de nous mĂȘme ces pratiques ?Comment rĂ©ussir Ă sortir du lot ?"Ăpisode enregistrĂ© en Mai 2025.Mastering audio automatisĂ© par auphonic.com.CrĂ©dits musique: "Guess Again", provided by https://slip.stream
Cette semaine, le SAV de la Tech rĂ©pond Ă la question d'Arno Nimousse:Dans notre Ă©quipe, nous avons des personnes (en plus des tech lead) pour amener un maximum de bonnes pratiques orientĂ©es (Pair programming, TDD, DDD etc). Ca fonctionne plutĂŽt bien mais rĂ©guliĂšrement nous voyons reculer certaines pratiques que l'on pensait acquises et intĂ©grĂ©es dans le quotidien des devs.Typiquement, tous les 3-4 mois, il faut rappeler que les dĂ©marrages de chantiers (fonctionnels ou techniques) ne doivent jamais se faire seuls, mais au moins en Pair programming (voire en mob/ensemble quand c'est possible). Il faut aussi souvent rappeler la nĂ©cessitĂ© d'un code bien testĂ© (et testable).Cette rĂ©pĂ©tition est-elle vraiment une fatalitĂ© ? Est-ce que l'Ă©quipe ne le fait que pour faire plaisir puis oublie rapidement les bienfaits de ces approches ?On a parfois l'impression de n'ĂȘtre lĂ que pour redire ce qu'on a dĂ©jĂ dit plusieurs fois en ayant l'impression d'ĂȘtre devenus les pĂ©nibles de serviceâŠĂpisode enregistrĂ© en Mars 2025.Mastering audio automatisĂ© par auphonic.com.CrĂ©dits musique: Guess Again, provided by https://slip.stream
Cette semaine, le SAV de la Tech rĂ©pond Ă la question d'Alexandre:"Salut le SAV et merci pour lâĂ©mission, câest sympa de vous entendre. Avez-vous des conseils sur comment se faire des amis en confĂ©rence tech ?Jâaime bien aller Ă ce genre dâĂ©vĂ©nement. Jâadore voir dâautres devs. Les 3 fois, jây suis allĂ© seul , mais jâai du mal Ă aller vers les gens. Je repars souvent en Ă©tant déçu de ne pas avoir Ă©changĂ© avec plus de personnes.Avez-vous des tactiques, des stratĂ©gies, des Ă©lĂ©ments dâĂ©tat dâesprit pour vous faire des amis en confĂ©rence ?"Ăpisode enregistrĂ© en Mars 2025.Mastering audio automatisĂ© par auphonic.com.CrĂ©dits musique: "Guess Again", provided by https://slip.stream
Cette semaine, le SAV de la Tech rĂ©pond Ă la question de Fabien:"Hello le SAV,De nouveau ; merci pour ce podcast. C'est trĂšs intĂ©ressant d'entendre vos rĂ©flexions sur les questions qu'on se pose, et ce serait dommage de ne pas en profiter.Dans mon contexte, je suis positionnĂ© en transverse sur plusieurs Ă©quipes pour les aider et les accompagner Ă progresser sur leurs problĂ©matiques techniques. Dans ce cadre j'organise des conversations en tĂȘte-Ă -tĂȘte (parfois appelĂ©es one-to-one ou bilatĂ©rale) avec les diffĂ©rentes personnes des l'Ă©quipes.Le contexte a changĂ©, et le management m'a positionnĂ© en tant que lead des Ă©quipes, plutĂŽt que soutien, et a demandĂ© que j'arrĂȘte les conversation avec les personnes. Ces conversations ne faisaient pas partir du pĂ©rimĂštre du rĂŽle que j'endossais, et un nouveau manager Ă©tait attendu pour prendre le suivi des personnes, par des one-to-one rĂ©guliers.Les personnes concernĂ©es et moi, avons trouvĂ© cela dommage : ces conversations permettaient de dĂ©loquer des situations humaine et techniques, notamment sur des code review, et on percevais une montĂ©e de compĂ©tence de chacun/chacune.Ma question :Quelle est le rĂŽle du Lead Dev dans le management ? Doit il ou ne doit il pas avoir des conversations dĂ©diĂ©es avec les membres de son Ă©quipe ?Merci d'avance pour le temps que vous allez prendre Ă me lire et (peut-ĂȘtre) Ă me rĂ©pondre."Ăpisode enregistrĂ© en Mars 2025.CrĂ©dits musique: "Guess Again", provided by https://slip.stream
Cette semaine, le SAV de la Tech rĂ©pond Ă la question d'Arthur:"J'ai 2 collĂšgues, Scrum master et PO, qui ne sont pas a la hauteur. Il y en a 1 qui n'est pas impliquĂ© et l'autre qui est junior et pas trĂšs perspicace. L'organisation de l'entreprise ne les challenge pas. Ăa crĂ©er des tensions et ça me fait ruminer chez moi. Je leur ai dĂ©jĂ dit les choses ouvertement lors des rĂ©trospectives sans rĂ©sultats. Comment gĂ©rer cette situation de personnes incompĂ©tents qui ne sont pas challengĂ©s par la hiĂ©rarchie?"Ăpisode enregistrĂ© en Janvier 2025.CrĂ©dits musique: "Guess Again", provided by https://slip.stream
Cette semaine, le SAV de la Tech rĂ©pond Ă la question que se posent secrĂštement les devs, designers, QA et managers: Est-ce que ChatGPT va me voler mon job ? ... avec un invitĂ© spĂ©cial ! Ăpisode enregistrĂ© en DĂ©cembre 2024. CrĂ©dits musique: Guess Again, provided by https://slip.stream
Cette semaine, le SAV de la Tech rĂ©pond Ă la question de Fabien: Hello le Sav, Tout d'abord, merci de produire ce podcast ; il est trĂšs chouette tant sur le fond que la forme. Dans des Ă©pisodes prĂ©cĂ©dents, vous avez parlĂ© Ă plusieurs reprises de guidelines de code et des bonnes pratiques. D'oĂč proviennent ces guidelines que vous mentionnez, et comment vous en servez vous ? Pourquoi cette question : Dans mon contexte, nous avons mis en place une solution pour expliciter nos pratiques et en discuter. Je cherche Ă confronter cette solution Ă d'autres pour l'affiner et la faire Ă©voluer. Mon contexte ; en tant que consultant externe, j'endosse un rĂŽle de lead sur plusieurs Ă©quipes. Ces Ă©quipes doivent respecter des guidelines provenant de diffĂ©rences sources: Des normes technologies (langages, outils, frameworks) venant d'une Ă©quipe d'architectes Des bonnes pratiques (structure des projets java, indentation, convention de nommage, workflow git) venant d'un responsable des dĂ©veloppeurs (Ă la fois manager et responsable du parc applicatif). Des nommages d'objets mĂ©tiers, venant d'un catalogue de donnĂ©e, qui homogĂ©nĂ©ise du lexique au travers de la DSI Les bonnes pratiques issues des Ă©quipes elles-mĂȘmes Ă titre personnel, je ne suis pas en accord avec certaines de ces pratiques (les bonnes pratiques n'existent pas (sans contexte)), car je trouve qu'elles empĂȘchent les Ă©quipes d'apprendre et de progresser. La solution mise en place : discuter en Ă©quipe et tracer nos dĂ©cisions. Lors d'une instance de partage rĂ©guliĂšre entre dĂ©veloppeur·euses, chaque personne met sur la table les difficultĂ©s rencontrĂ©es lors de la production du code ou les dĂ©saccords exprimĂ©s lors des Code-Reviews. Nous prenons le temps de formaliser la pratique, avec son contexte et ce que nous voulons faire (Ă la maniĂšre d'un ADR), avant de voter par consensus sur l'exigence collective de celle-ci (un peu Ă la maniĂšre de cataloguer des technologies avec un Tech Radar). Pour le moment, cela fonctionne bien. On a un artefact qui nous permet d'onboarder explicitement les nouvelles personnes ; il sert de source unique de guidelines pour notre contexte d'Ă©quipes. Cet artefact nous permet de dĂ©sobĂ©ir Ă certaines guidelines imposĂ©es (ex: structure des package java, indentation du code), car nous avons argumentĂ©, dans notre contexte, les raisons de notre dĂ©sobĂ©issance ; cela permet d'entamer une discussion pour (Ă©ventuellement) revoir les guildelines globales Ă la DSI, mais aussi cela permet d'ouvrir une expĂ©rimentation. VoilĂ :) Je suis preneur de vos lumiĂšres pour affiner cette solution. Ăpisode enregistrĂ© en DĂ©cembre 2024. CrĂ©dits musique: Guess Again, provided by https://slip.stream
Cette semaine, dans le SAV de la Tech, on rĂ©pond Ă la question de Louis: On a un sujet qui pop en rĂ©trospective sur l'Ă©quilibre entre temps de dev et review qui fonctionne pas trĂšs bien chez nous. L'Ă©quipe est relativement jeune, composĂ©e de 5-6 devs et 1 super PO arrivĂ© il y a peu. ConcrĂštement les tickets restent ouverts trop longtemps et trop de tickets ouverts en parallĂšle⊠Avez-vous des pistes Ă proposer pour nous aider Ă trouver le bon Ă©quilibre ? Ăpisode enregistrĂ© en Octobre 2024. CrĂ©dits musique: Guess Again, provided by https://slip.stream
Cette semaine, dans le SAV de la Tech, on rĂ©pond Ă la question de Joseph: Je dois faire un dossier Ă chaque fois pour obtenir la promotion dâun membre de mon Ă©quipe. Ce dossier est soumis Ă un comitĂ© qui va dĂ©terminer quels sont les personnes qui vont ĂȘtre promues ou non. Un membre de mon Ă©quipe opĂšre dĂ©jĂ au niveau supĂ©rieur mais sâest vu refuser une promotion car les Ă©lĂ©ments du dossier ne sont pas assez dĂ©monstratifs de sa valeur. En particulier câest un solide contributeur individuel mais le comitĂ© sâattend Ă ce quâun dĂ©veloppeur aie un impact multiplicateur (oui le 10x engineerâŠ) sur les autres membres de lâĂ©quipe, et mĂȘme dâautres Ă©quipes. Dâune part câest assez compliquĂ© de trouver un projet sur lequel illustrer ces compĂ©tences du fait du scope de notre Ă©quipe mais aussi la personne a du mal Ă tracker son travail (rĂ©sout des taches sans passer par jira, skip la phase de doc, etc) ce qui rend la tĂąche de dĂ©montrer sa valeur complexe. Par ailleurs jâai vu des gens briller dans la maniĂšre de dĂ©montrer leur impact malgrĂ© des contributions particuliĂšrement limitĂ©es. Jâen viens Ă penser que dĂ©montrer sa valeur est une compĂ©tence - et radicalement differente que celle de gĂ©nĂ©rer de la valeur - mais pourtant essentielle pour la progression de carriĂšre. Que me recommandez-vous pour 1- identifier les sujets sur lesquels se mettre en avant, et 2- comment prĂ©senter ses achievements sans avoir lâair de brag de lâair (comme jâai pu aussi le voir par ailleurs). Ăpisode enregistrĂ© en Octobre 2024. CrĂ©dits musique: Guess Again, provided by https://slip.stream
Cette semaine, dans le SAV de la Tech, on rĂ©pond Ă la question de Pierre: Hello, Je suis tech lead / manager d'une petite Ă©quipe (1 dev senior, 3 devs juniors + moi-mĂȘme) qui travaille sur un projet qui fait appel Ă de nombreuses nouvelles technologies. Les besoins du projet nous obligent souvent Ă nous pencher sur des sujets dont les solutions ne sont pas Ă©videntes ni directes, et nĂ©cessitent souvent un travail de R&D pour rechercher la meilleure solution, et parfois mĂȘme tout simplement pour vĂ©rifier la faisabilitĂ© ou non d'une fonctionnalitĂ©. Il arrive donc rĂ©guliĂšrement qu'un travail de plusieurs jours soit stoppĂ© car la piste explorĂ©e s'avĂšre ĂȘtre une mauvaise piste et il faut alors rĂ©orienter les recherches. L'Ă©quipe a grossi trĂšs rĂ©cemment, et est devenue trĂšs jeune, tous les juniors ont Ă©tĂ© recrutĂ©s en sortie d'Ă©cole. J'ai justement Ă©normĂ©ment de mal Ă piloter ces juniors : j'ai remarquĂ© qu'ils me vouent une confiance presqu'aveugle et ont tendance Ă assez peu remettre en question les choix techniques ou Ă appliquer les suggestions proposĂ©es lors des revues de code sans rĂ©flĂ©chir Ă leur pertinence. Ils ont Ă©galement du mal Ă accepter que je nâai moi-mĂȘme pas la solution en tĂȘte et que leur boulot est justement dâexplorer pour la trouver. De plus, au moindre Ă©chec (tentative d'utilisation d'une technologie qui ne rĂ©pond finalement pas au besoin, difficultĂ©s Ă trouver une solution technique, etc.), la dĂ©motivation se fait rapidement sentir et l'effort pour remotiver l'Ă©quipe est considĂ©rable. Cela pose pas mal de problĂšmes car Ă cause de cela, ils ont du mal Ă aller expĂ©rimenter et chercher des solutions d'eux-mĂȘme. Les daily meetings aident un peu dans le sens oĂč ils peuvent rapidement exposer leurs points de blocage, mais jâai remarquĂ© que cela avait introduit un effet secondaire : plutĂŽt que de passer un peu plus de temps Ă rechercher une solution, ils peuvent attendre le daily meeting suivant pour appeler Ă lâaide, et cela finit par induire Ă©normĂ©ment de temps d'accompagnement pour mon senior et moi, qui sommes impactĂ©s sur nos propres tĂąches, et cela peut entraĂźner des retards de shipping. Pourtant, j'essaye de leur enseigner au maximum l'autonomie, et je m'assure que les objectifs sont clairs pour tout le monde et que les tĂąches sont les moins ambigĂŒes possibles. Ma question est donc la suivante : comment puis-je aider au maximum la prise d'autonomie de mes dĂ©veloppeurs juniors, qu'ils montent en compĂ©tence et surtout qu'ils gardent la motivation mĂȘme aprĂšs des « Ă©checs », qui sont inhĂ©rents Ă notre projet ? Ăpisode enregistrĂ© en Octobre 2024. CrĂ©dits musique: Guess Again, provided by https://slip.stream
Cette semaine, dans le SAV de la Tech, on rĂ©pond Ă la question de Robert, a.k.a. Dark Nounours: "Comment faire comprendre aux gens que les architectes ne sont pas lĂ pour nous dire comment coder ? Jâai lâimpression que câest flou le mĂ©tier dâarchitecte. Perso jâaime bien la comparaison avec lâarchitecte dâurbanisation. Il est lĂ pour que ta maison sâinsĂšre correctement dans le paysage pas pour te dire comment dĂ©corer ton intĂ©rieur. Mais je me trompe peut ĂȘtre? Sinon bravo pour votre podcast il est fun (et intĂ©ressant)" Ăpisode enregistrĂ© en Septembre 2024. CrĂ©dits musique: "Guess Again", provided by https://slip.stream