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 Stéphane Rétton, Stéphane bonjour.
Bonjour.
Est-ce que tu peux te présenter en quelques mots pour ceux qui ne te connaitrait pas ?
Bonjour.
Je travaille pour la grosse FSM qui s'appelle ITS Group et je travaille surtout dans la
practice à la fois développement logiciel, ITS Général et la practice sécurité Bluetooth
aussi.
Moi mon parcours, c'est un parcours de, j'aime bien m'appeler Full Stack Debugger, je ne
suis pas un développeur comme...
Full Stack Debugger, ça c'est bon ça !
Voilà, ça évidemment c'est un petit troll ou un petit clin d'œil à ceux qui sont
Full Stack Developer, je ne me prête pas du tout développeur et je ne le suis pas.
Je viens plutôt de l'infra, moi j'ai commencé au réseau au siècle dernier et puis petit
à petit, j'essaye de monter les étages, réseau, système, sécurité et donc j'ai
une vision globale mais plutôt côté infras et j'ai suivi tout le mouvement de HoQ,
l'architecture claremnative qui a eu sur ces dernières années et je me rends compte
qu'on fait de plus en plus de devs à la fois parce que dans les équipes did devops
en fait, moi j'interviens pour former, pour faire des ateliers, pour expertiser, pour
accompagner sur la partie sécurité du code mais non pas dans des powerpoint, vraiment
en changeant les deux trois lignes, c'est quelque chose qui est à peu près à mon
niveau, où donner une idée générale et le respect des RGPD, le respect des normes
et standards qu'il peut y avoir dans les grosses sociétés et donc la compréhension
de ces sujets là, donc à la fois apporter de la connaissance infras au sein des équipes
de devs qui sont finalement orientées à par application et également sur la partie
pure sécurité qu'on pourrait appeler cyber sécurité, ça qui a de plus en plus de
développement d'outillages qui sont réalisés par les équipes de cyber sécurité qui consomment
donc du dev pour justement traiter les événements, les alarmes, tout ces sujets là. Voilà.
C'est cool, ça nous donne une bonne thématique parce qu'il y a plusieurs choses qu'on peut...
Moi je viens à la sécurité donc ça sera intéressant qu'on en parle. Je viens en travaillant
sur la blockchain, je me spécialise là-dedans, c'est à dire que j'ai commencé en tant
que développeur blockchain et ensuite là je suis en train de bouger sur la partie sécurité
parce qu'en fait quand tu développes sur la blockchain, il y a un enjeu énorme vu que
les codes que tu fais va facilement embrasser des centaines de milliers de dollars, voire des dollars,
des millions de dollars. Là il n'y a pas longtemps j'ai trouvé une faille critique qui a un cheveu
prêt, pouvait bloquer 500 000 dollars de fond. Je peux te dire que le porteur du projet quand on a
identifié la faille avant de se rendre compte que s'il y avait des moyens de mitiger ça,
il était devenu tout lent. C'est quelque chose qui m'excite pas mal, je trouve un côté hacker
que je découre et que j'aime bien. C'est mon chemin, c'est rigolo parce que toi tu me dis
que tu viens au dev, moi je viens à la SQ et du coup je suis intéressé par ton point de vue,
on peut peut-être commencer par le côté web 2 parce que moi je t'avoue que tout ce courant,
d'abord j'ai pris une baffe, quand t'as dit que j'ai commencé le siècle dernier parce que moi aussi,
ça fait genre un peu les dinosaures qui sortent de leur cave, je commence à 99 donc sur la limite,
un an près je pouvais pas le dire mais voilà et c'est vrai que j'ai vu les choses pas mal évoluer.
Moi je suis parti d'une culture dans l'extrême programmée des origines, on se posait pas
ces questions là, c'est l'équipe de dev qui gérait sa plateforme et point barre. Et de part
ma formation, de part aussi mes premières expériences, j'ai mis les mains dans l'admine,
je géré mes serveurs, je développais l'appli dessus et c'est tout, je me posais pas de questions.
Et du coup quand effectivement j'ai vu ce courant DevOps apparaître,
je me suis un peu intéressé, je me suis dit bon ok, les mecs ils ont juste pris la partie dev de
l'XP qui était un peu trop ops, ils en ont fait un truc à part quoi.
Ouais alors absolument, le mouvement DevOps il y en a partout, chez tous les clients,
chez lesquels j'interviens, qui sont gros, du client de tout taille en France principalement.
Et alors c'est vrai qu'au début ils arrivent, ils font assez rapidement des choses spectaculaires
parce qu'en fait ils arrivent à s'abstraire des éventuels contraintes et des lenteurs de
l'infrastructure, c'est vrai, il y a aussi que l'infrastructure des fois ça peut être long,
obtenir une VM, obtenir un load balancer, obtenir un firewall, changer un record DNS,
ça peut être très très très long. Et donc ils arrivent à satisfaire le product honneur très très
rapidement et donc ils sont vus un peu comme les bons élèves. Et puis au bout de deux,
trois ans en fait les problèmes commencent à arriver, commencer à avoir des problèmes de
maintenance, de vulnérabité dans les librairies et donc il y a énormément de travail en fait à
faire de maintenance qui est un travail qui est un peu caché et donc finalement le développeur qui
allait très très vite, on impacte sa velocité là pour utiliser un terme un peu pédant.
Ah non mais c'est clair pour moi les admins c'est les chers de services, l'image que j'ai,
non mais sérieux, mais c'est les chers de services mais en même temps c'est eux qui se réveillent la
nuit. Donc ils sont tous légitimes pour dire t'es gentil mais en fait ta libe tu vas pas la mettre.
Et tu vois que c'est là quasiment là aujourd'hui dans les dernières nouveautés ou déroulements
qui peut y avoir sur la SQ et le DEV, il y a suite à la fameuse file de l'Occforkie qui est vieux,
il y a un peu plus d'un an maintenant, à Noël de l'année dernière.
Vas-y raconte parce que tu vois même ça j'ai réussi à passer à travers, qu'est-ce qui s'est passé ?
Grosso modo donc c'est pas Noël 2022, c'est Noël 2021 donc 10 jours avant de Noël 2021 on
se rendait compte qu'il y avait une énorme faille dans l'Occforkie, c'est très intéressant
à ce sujet, en fait on se rendait compte qu'il y avait une faille dans l'Occforkie, en gros il fallait
patcher l'Occforkie, le problème c'est que personne ne sait même dans les plus grosses sociétés
s'il y avait du Locforkie sur des centaines, des milliers d'applications.
Parce que l'Occforkie je pense qu'il est partout en fait, je pense qu'il y a à peu près dans
tous les applis Java de tout le monde.
En fait il était même pas utilisé, donc ça c'est fini.
La bague d'or qui fait mal quoi.
Voilà exactement, alors ça permet grosso modo, en gros il pouvait y avoir un attaquant qui se connecte
sur le serveur, il fait un appel et en gros on peut télécharger du code malveillant à l'extérieur
et le ramener sur le serveur pour l'exécution, pour simplifier.
Si c'est bien archélecturé, on a des firewalls qui bloquent, les flux sortant,
les flux entrant donc ça peut être mitigé, ça n'a pas non plus été l'apocalypse mais ça a
réveillé tout le monde et donc tout d'un coup les développeurs sont mis à faire de la maintenance
parce que finalement on les a rappelés, les seuls qui savaient exactement ce qu'il y avait dans le
code c'était les développeurs donc ils se sont pris vraiment une grosse faille de séq, enfin
du travail à faire sur une remédiation sur une faille de sécu et en fait on avait des outils qui
étaient redimentaires, les gens ont fait du grep sur le code pour voir s'il n'y avait pas l'ocforgy
et puis ils ont recompilé, ils ont ré-envoyé ça en prod, ça a été plus ou moins rapide
d'être déployé et donc on a quand même énormément progressé en l'espace d'un an
parce que maintenant donc des vieux concepts qu'on appelle S-BOM software bill of material
c'est en fait tout simplement la liste de tous les composants, tous les packages,
est généré automatiquement par les outils tel que Docker, les outils dans les CI-CD, enfin
automatiquement il faut quand même le faire bien sûr mais de plus en plus en fait maintenant on
peut faire on peut générer la recette au moment de la compilation ou de la génération du build
et éventuellement signer cette recette, c'est à dire qu'en fait il suffit pas d'avoir la recette
parce que la recette peut être modifiée je pourrais enlever des choses, rajouter des
choses, changer les versions et donc la signer, voilà et donc la question c'est c'est un sujet
dev ça ou c'est un sujet sécurité, probablement un peu des deux, est-ce qu'on peut dire au dev
bah ça tombe bien, t'avais du temps, on va te rajouter deux heures par semaine pour signer
tes builds pour rechercher les libres, probablement il n'a pas de temps et puis il y a probablement
je ne dis pas qu'il a mieux à faire mais il y a d'autres... Non mais tout ça ça se automatise pas ça ?
Bah il faut quand même quelqu'un l'automatise et puis après il faut le traiter quand même,
c'est à dire qu'après une fois qu'on se rend compte que dans la liste il y a des choses à faire évoluer
alors on peut l'automatiser maintenant de plus en plus il y a des outils si tu veux qui te proposent
une progression donc par exemple on voit que tel libres est en v1 on dit ah bah tiens il y a la v1
est-ce qu'on le fait mais en fait la question c'est est-ce que c'est un cas qui s'applique à mon sujet
est-ce qu'il faut vraiment que je le patch, qu'elle va être la régression et enfin voilà il y a comme
des humains... La tiens quand même oui mais tiens quand même en compte non mais je te parlais du process
de fabrication de signature tout ça, ah oui du S20, oui tout à fait, là tu as une analyse à faire
qui est humaine et qui est de quelqu'un qui s'y connaît en cq quoi, voilà disons que c'est voilà
pour reprendre une image c'est à dire que voilà on a enlevé les pelles et les pioches et on a mis
une pelle mécanique donc c'est beaucoup plus agréable c'est plus rapide mais il faut quand même
quelqu'un qui pilote le truc faut pas rêver donc et donc tout ça ça fait de la charge cognitive
et donc ça le dev au lieu de développer il va faire autre chose et donc ça paraît évident
qu'il faut absolument qu'il y ait des gens de la sécurité donc tout à fait qu'il y ait une sensibilité
sécurité qui soit intégrée dans cette équipe de dev et pas juste dire attention il y a une librairie
faite gaffe qu'elles ne sont pas utilisées il faut vraiment venir corriger, patcher, vérifier qu'il
y a pas de régression donc en fait finalement c'est un dev avec les tickets de sécu c'est ça qu'il
faut enfin moi c'est comme ça que je le vois tous les cas mais tu sais ce que tu es en train d'écrire
je suis en train de me poser la question pourquoi ça m'a jamais traversé pourquoi c'est des questions
que j'ai jamais eu parce que ça faisait partie des choses à faire on le faisait quoi c'est tout
plus ou moins bien d'ailleurs mais ouais d'accord donc tu faisais de la surqualité quasiment
là parce que c'est aujourd'hui dans l'industrie c'était préféré, c'était préféré, bien
tu vois typiquement je pense à check dans ma team alors quand je faisais du rails
parce que c'était avant je faisais du c++ embarqué donc t'avais beaucoup moins de
enjeux là c'était des trucs desktop embarqué tout ça donc t'avais pas de connectivité
là quand je faisais du rails je me suis rendu compte qu'il y avait quelques règles
qui fallait connaître dans la manière designée pour éviter de transformer ton app en gros
et puis après surtout ce que tu viens d'écrire là le suivi des paquets, les mises à jour les
machins autant moi je n'étais pas trop sensible à ça autant un dégât de mon équipe l'autre benoît
lui il était il suivait ça quoi d'accord mais donc il a chaque fois il suivait il intégré dans sa veille
le suivi des paquets des machins et et en temps il me disait bon là il faut faire une grosse mise à jour
souvent ça portait sur rails et on suivait les évols de rails et puis dans un temps il y avait
un truc qui sortait sur une libre et puis on a d'été et puis on poussait et puis c'était réglé
quoi. Oui ben vous étiez déjà en avance alors ce n'est vraiment pas ce que je constate
partout il y a un suivi qui est souvent délégué à des équipes transverses sur les librairies
mais parce qu'en fait moi mon analyse hein mon analyse des choses c'est qu'on a corrompu
et c'est souvent les grosses bois d'ailleurs c'est facile de les recasser du sucre sur le dos
parce que parce qu'ils sont gros et qu'ils ont des challenges et qu'ils ont qu'ils ont réglé à la serre
on va dire voir l'appel mécanique comme tu disais
c'est à partir du moment où tu enlèves la prod des mains du dev
tiens c'est un peu le péché originel quoi. Ouais c'est ça du dev je veux dire de l'équipe
du même moment où tu déresponses à l'utilise l'équipe qui produit le code des conséquences
qui va avoir et du run ben pourquoi ils s'en soucirez ça fait plus partie de la radar en fait
exactement ça a été en voyant pas. Et si tu compiles à ça le fait que moi j'ai été choqué de la
carance qu'il y avait de connaissance et de formation sur ces couches là tu vois c'est pas
parce que alors aujourd'hui avec les passes les sas les machins tout est tellement abstrait
tellement virtualisé qu'on ne s'en rend plus compte si tu veux te fermer les yeux sur tout ça tu peux
parce que le jour où tu n'as un pépin moi j'ai le souvenir je t'en parlais là en préparation de l'épisode
une fois dans dev qui était coincé sur un truc qui bloque au niveau du DNS et j'ai dit mais tu sais
ce que c'est un DNS et qui me regarde avec des grands urons je me suis dit mais où est-ce qu'on a
où est-ce qu'on a raté un truc mec tes développeurs et tu connais pas tes couches réseaux c'est
il y a un problème en fait et ben non en fait c'est pas un problème il y a plein d'endroits où ce gars il
n'est pas il n'a pas de soucis et c'est ça le soucis oui ça que toi en plus tu t'inscrits dans le
mouvement craftmanship qui est un mouvement d'excellence mais il n'y a pas que tout le monde n'est pas
excellent tout le monde n'a pas énormément d'expérience tout le monde n'a pas nécessairement du
temps enfin du temps ou en tout cas ce soit le temps pour livrer un produit parfait je vais gommer
parfait tout de suite parce que c'est pas le but mais en tout cas pour moi la démarche d'excellence
elle est vis-à-vis de soi et de ce qu'on fait et de la manière de faire son travail le but n'est pas
de faire quelque chose de parfait sinon tu livres jamais rien le but est quelque chose de faire de bon
mais surtout de s'améliorer en permanence dans une logique d'amélioration continue donc le
après tu as raison si les gens je remarque il n'y a pas forcément l'appétit pour ces choses là chez
certains devs et puis en plus ouais le product owner qui a un petit budget de x jourum de
tèvres on refile la patate chaude mec d'à côté pour gérer l'expo et moi j'ai de la feature à
livrer mec donc qu'est ce que tu viens me parler t'as secure et de me gonfler quoi et exactement
c'est exactement et puis de plus en plus tu parlais du voie du passe et du sas donc les archis sont
plus enfin c'est étonnant parce qu'avec la virtualisation les machines étaient dédiées donc ça limitait
quand même les impacts d'une application qui se fait qui se faisait hacker là de plus en plus avec
kubernetes ou le passe ben on est de plus en plus dans du mutualisé donc une application qui se fait
hacker va va potentiellement fuir et donc mettre en danger tout un tas d'autres applications qui sont
hébergés sur les mêmes serveurs ou dans les mêmes zones et donc il apparaît autre exemple tu vois
c'est mettre en place du cloisonnement réseau des c'est des sujets qui sont pas toujours très marrants
pour les devs qui quelque part finalement en raison eux ils voient que midi à leur porte ils livrent
une application ils sont pas garant de la sécurité de toute la de toute la boîte et donc c'est
voilà mon nique enfin c'est pas mon idée mais c'est moi je pense que la bonne façon de faire c'est
d'injecter des opérationnels des développeurs opérationnels un peu de tag et cq de la même
façon qu'il devrait y avoir des spécialistes un peu de base de données des spécialistes d'architecture
qui sont peut-être pas des gens qui vont développer de message que wing enfin de tout ça dans
ces équipes applicatives et de les rendre fonctionnelles et qu'elles puissent avancer à la fois assez vite
en utilisant des produits en self service qui sont fournis par l'entreprise du stockage du réseau du
bansign du firewall tout ce qu'on veut de la vm donc un peu une équipe plateforme qui serait
standard qui est standard en fait enfin pas bon transversal et puis des spécialistes qui sont
positionnés dans les équipes alors souvent ce qu'on me dit c'est oui mais alors le gars cq il va un peu
s'embêter parce que en fait il est là cinq jours par semaine c'est long cinq jours par semaine est-ce
qu'il pourrait pas venir seulement le jeudi après-midi et là moi je pense à mon niveau que ça peut
pas marcher parce qu'il a loupé le meetup du lundi matin et donc il est un peu largué il vient il
prend pas trop ce qui se passe tout le monde est passé à autre chose et donc c'est fort ça si on est
vraiment sérieux sur la sécurité parce qu'on a fait une analyse on se rend compte cette appli c'est
une appli qui nécessite de la sécurité tu parlais du bitcoin enfin enfin pas du bitcoin je veux
dire des cloutons pardon mais voilà des traitements il y a des gros gros enjeux sécurité financier de
santé enfin bon peu importe bah il faut pas nécessairement mettre le paquet mais en tous les cas
il faut qu'il y ait une c'est pas du ponctuel c'est en il y a un suivi longitudinal on peut
dire de la sécurité avec quelqu'un qui est là tout le temps et qui pourrait d'ailleurs faire
à la fois en même temps je sais pas moi c'est que plus réseau c'est plus un petit peu de dev
c'est plus un petit peu de stockage enfin c'est ça l'idée quoi bah c'est clair que c'est tout là
l'antagonie qu'il y a se spécialiser pour te spécialiser il faut que tu te tu réduises ton
ton champ d'intervention pour pouvoir creuser le plus profondément possible pour devenir vraiment
un expert du sujet mais se faisant tu es de moins en moins capable d'intervenir sur un spectre large
de ton projet et donc tu as un équilibre à trouver pour que pour que le gars il puisse avoir de
quoi s'occuper toute la semaine parce qu'en fait la partie pure expertise peut-être qu'elle va
durer qu'un jour ou deux de la semaine et qu'en même temps il faut qu'il puisse intervenir sur assez
chose mais qui reste en même temps assez focus pour être pointu dans ce qu'il fait tu vois par
avant de moi sur la blockchain je parle bien là de développer ce qu'on appelle des smart contracts
donc le code qui est exécuté sur la blockchain c'est vraiment ma zone de spécialité aujourd'hui
je ne fais plus du tout de web 2 ça a été mon choix pourtant sur les projets les développeurs on
attendus qui soient capables de faire en gros 80% de web 2 sur les projets web 3 80% de web 2 et un
peu de solidité 10 20% de son temps mais moi je crois pas du tout à cette approche parce que plus je le
creuse et plus je me rends compte à quel point c'est pointu et plus tu as des failles de sécurité
parfois énorme qui se quitte qui t'attendent au coin de la rue et ça pour moi c'est qu'une expertise
poussée une veille poussée qui permet de l'entretenir donc tout le monde par exemple j'ai fait le choix de
de me spécialiser que dans la partie blockchain neve m et plus de faire de web 2 mais du coup ça me
coupe les ports de plein de projets si j'étais expert sqn dépendant ben pareil je pourrais pas être
en permanence dans une équipe parce qu'à un moment donné ben t'as plus de travail en fait c'est aussi
basique que ça tu vois moins les projets où il y a du travail en continu sur cette partie blockchain
il n'y a pas il n'y a pas des masses et la partie audit en plus cq c'est souvent des choses très
ponctuels tu viens quelques jours une semaine ou deux grand maximum et puis faut que tu passes
au client d'après quoi enfin faut que tu passes au projet d'après alors que pourtant en tant que
développeur parce que j'ai c'est côté développeur aussi je fais les deux l'audit et du dev c'est
plus sécuritaire aussi je peux pas me dire ok t'as sens pas grave il y a un auditeur qui va passer
derrière et je m'en fous un peu comme les devs c'est bon il y a un admin qui va passer derrière et
c'est pas grave et c'est lui qui gérera le caca non souvent dans les projets c'est moi qui doit tout
gérer quoi non mais je veux dire en plus ça marche pas tellement parce que l'audit tout arrive à la
fin du projet c'est un peu un peu trop tard il faut quasiment réagir de façon ouais c'est un peu le
problème chez moi c'est ça dans la blockchain c'est un peu le souci à la différence de l'infra
ou si t'y as pas un peu je le ferais je m'amuserai pas à faire intervenir un auditeur d'infra à la fin
parce que si ça se trouve le mec il va dire hein vous êtes gentil mais il faut tout refaire alors
l'auditeur blockchain c'est pourquoi pas mais on est condamné à en est obligé de travailler sur
pièce en fait donc on est obligé on est condamné à attendre la fin du dev et vu que la fin du dev est
souvent contrainte par des timelines débiles tu on est souvent pris en sandwich entre la mise en
prode qui doit avoir lu dans trois jours et le dev qui vient de se finir mais bon ça c'est le c'est
inhérent à cette partie la très spécifique du coup si on fait l'analogique un développeur qui
nous écoute se dit ouais enfin finalement c'est pas si con si je m'intéressais un peu de devops
histoire de gagner un peu là dedans ça me plaît tout ce qui est un petit peu admis une système
tu lui conseillerais de commencer par quoi de démarrer comment je pense qu'à la base c'est
du développeur donc c'est les connaissances système voilà les libres tu les conseilles de se
monter un niveau si tu l'admises c'est bah oui de savoir faire un peu d'admins sur un serveur
linus positionner des droits installer des logiciels faire des upgrades de logiciels c'est
vraiment la base et puis après rapidement enfin rapidement il va se rendre compte qu'il y a
plein plein de de finesse en fait sur un kernel linux incroyable en fait tu tu peux aller sur les
droits enfin toi par exemple il y a plein de gens qui croient que si tu es route en fait
au fin route il ya un truc secret ou si tu es le user id numéro zéro tu es route tu as tous les
droits en fait pas du tout il y a des ce qu'on appelle des capabilities c'est en fait à des droits
vraiment granulaires il y a celui qui peut rembouter la machine celui qui peut changer des
droits il y a celui qui peut changer l'honneur celui qui voilà donc si tu commences à gratter rien
que linux c'est déjà énorme sachant qu'il y a déjà tout le réseau là donc en fait oui
moi mon conseil c'est les attractions les abstractions c'est super tout ce qu'est le sas
le serveur l'est c'est génial mais en fait il faut pas perdre de vue de comprendre comment ça a
été fait parce qu'en fait les abstractions elles fuient en fait et donc à un moment donné il faut
comprendre comment l'os qui est finalement au coeur de tout là moi je le vois de plus en plus
on parle de la sécu comment la sécu finalement rentre dans le dev mais la sécu est rentrée depuis
des années dans l'os et t'as ça aussi avec le réseau c'est à dire que quand tu fais par exemple du
bien-intesse du docker tu fais du protocole réseau type bgp avec le reste du réseau les gens du
réseau ils avaient l'habitude d'être juste avec eux avec leurs propres équipants qui étaient en hardware
et maintenant les machines les nus font partie du réseau voire même sont le réseau donc je pense
que le voilà le coeur du système c'est linux voilà pour pour simplifier et donc il faut quand même
à mon avis avoir des bonnes connaissances alors c'est un peu compliqué parce que c'est je pense
que tout connaît dans du réseau pendant toutes les couches c'est un peu il use au arre ça va
quand même très très vite mais avoir être un bon admin système je pense que c'est la base pour
beaucoup de choses bah écoute ça je te propose que ce soit le mot de la fin est-ce que tu veux nous
dire un dernier mot de la fin non j'ai pas de la fin plus là dessus alors si le mot de la fin ça
pourrait être de façon générale mais je pense que ça rend vraiment dans la partie craft
manchift c'est vraiment quelque chose auquel moi même je souscris mais même si on a bien compris
j'étais pas un développeur mais cette excellence cette auto formation et donc c'est pareil il n'y a
rien de pire que dire bah je sais pas j'ai pas compris donc je pense que pour que ce soit des
développeurs ou des gens de l'infra et si progresser en vous autoformant formant lisant des blogs
des tweets enfin il ya tous les formats aujourd'hui qu'il existe on n'est pas obligé de dire des gros
bouquins sans images donc on peut vraiment progresser c'est la seule chose qui à mon avis permettra
qui nous permettra de tirer un peu notre épingle du jeu puisque c'est un ça avance en permanence
et puis également essayer d'établir des ponts alors voilà lancer des mains allé manger à la
cantine avec les développeurs ils sont peut-être sympas après tout si vous êtes de l'infra et
donc je pense que aussi toutes les incompréhensions qu'il pouvait y avoir c'est qu'on est à des étages
différents on se parle pas trop il y a eu des histoires des ranceurs et donc je pense que
rencontrer les gens et toi ça va vraiment complètement à l'encontre quelque part du
full remote qui aujourd'hui trop ça super d'être full remote mais il y a plein de choses qu'on se dit
pas dans une réunion ouais c'est ça parce que tu veux dire c'est que le remote a enlevé le l'informal
qui avait avance et ça ouais exactement tu peux rester en full remote enfin en gros tu peux avoir
des conversations profondes avec des gens que tu connaissais déjà d'avant physiquement mais des
gens que tu connais pas que tu as juste connu en visio c'est compliqué d'aller d'aller noire
un mien avec eux et se dire ah salut les gars je reconnais c'est pas faux mais donc voilà alors
après je sais que c'est un espoir c'est une aspiration de beaucoup de monde aussi d'être un peu dans
sa bulle de confiance mais ça s'arvient à sa bulle de confort mais c'est un peu c'est la même histoire
c'est mettez vous un peu en danger allez sur des sujets que vous ne maîtrisez pas trop progresser
et aussi bah parler avec tous les informaticiens de votre entreprise bah c'est cool stéphane merci
d'être venu aujourd'hui c'est un plaisir merci benoît quant à toi cher auditeur bah voilà j'espère
que cet épisode a donné envie d'intéresser un petit peu à ces sujets là tu l'as compris moi je
s'imgne que ça fait complètement partie de notre travail de s'intéresser à ces sujets là d'avoir
au moins le bagage technique pour comprendre ce qui se passe pour comprendre les décisions comprends
quand tu choisis du kfk plutôt que du rabit mq ça serait bien que tu comprennes la différence
qui est entre les deux et bah je te dis à bientôt je te donne rendez-vous dans un prochain épisode