Tous les jeunes qui veulent travailler dans l'attaque veulent être développeurs ou développeuses.
Ce n'est pas étonnant parce que c'est le métier qui est le plus représenté dans les médias.
Pourtant, il y a des tas de métiers dans le numérique.
C'est pour lancer justement mon jobboard avec My Little Team que j'ai décidé de faire une série d'autres vues
pour parler des métiers de la production, de l'exploitation ou de l'infrastructure.
Mais on reparlera de mon jobboard en fin de vidéo, donc reste bien jusqu'à la fin,
surtout si tu cherches un taff dans le milieu du numérique qui te plaît.
Aujourd'hui, je suis avec Nicolas Lédez et ensemble, on va parler du métier à la mode le DevOps Full Stack.
Bienvenue sur Radio DevOps, la balade aux diffusions des compagnons du DevOps.
Si c'est la première fois que tu nous écoutes, abonne-toi pour ne pas rater les futurs épisodes.
C'est parti !
Bonjour à toi chers compagnons, et bienvenue dans ce nouvel épisode d'En apparté,
l'émission où je m'entretiens avec un invité.
Avant de commencer, je te rappelle que j'ai créé et que j'anime une communauté en ligne francophone
dédiée au cloud et au DevOps qui s'appelle les compagnons du DevOps.
Mais je suis aussi formateur et si tu veux t'y retrouver et débuter dans le DevOps,
j'ai justement fait une formation pour toi pour que tu puisses te forger un état d'esprit DevOps.
La formation s'appelle DevOps Mindset.
C'est le premier lien en description pour t'inscrire,
ou alors tu peux aller justement sur le site des compagnons du DevOps et tu trouveras le lien.
Alors, bonjour Nicolas, bienvenue à nouveau dans En apparté.
Justement, tu étais déjà venu là et c'est pour ça que je vais peut-être pas te poser mes questions habituelles.
Salut Christophe, salut tout le monde.
Oui, alors si tu le sais pas, Nicolas est déjà passé,
donc je te renvoie à ce podcast-là pour toutes les questions du genre,
c'est quoi cette définition du DevOps, comment est-ce qu'il a rencontré le DevOps, etc.
Et donc là, on va pouvoir entrer justement dans le livre du sujet.
Quand justement, j'ai lancé ma série sur les métiers, tu me dis,
j'ai envie de parler du DevOps Full Stack et justement,
enfin je sais pas si tu trollais ou pas, si tu me trollais moins,
mais est-ce que tu peux nous en dire un peu plus sur ce fameux DevOps Full Stack
et pourquoi tu voudrais qu'on appelle cet épisode-là le DevOps Full Stack ?
Effectivement, alors, Régine, c'était parti un petit peu du troll,
mais c'était pas spécialement pour toi ou la série,
c'était plus que je vois de plus en plus passer des annonces machins Full Stack,
bidules Full Stack, back-end ou front-end Full Stack.
Des fois, ça devient un petit peu ridicule et je voulais pousser le ridicule un petit peu plus
en disant, voilà, je suis DevOps Full Stack.
Et en fait, au-delà du troll, c'est finalement,
quelques temps après mes styles une semaine ou deux,
j'ai vu des annonces passer sur LinkedIn DevOps Full Stack.
Alors du coup, je me suis dit que ma blague tombait totalement à l'eau, mais c'est pas grave.
En fait, c'est parce que je me suis rendu compte ces dernières années
que le monde du DevOps, c'est un petit peu cindé en deux, on va dire,
avec deux approches, on va dire, radicalement différentes pour simplifier les choses,
même s'il peut y avoir plein de nuances entre les deux,
entre des DevOps qui vont faire quasiment du Full Stack en utilisant
des gros cloud providers malheureusement trop souvent américains
qui fournissent plein de services sur étagères et ils vont mettre de la glu dans tout ça.
Et à l'extrême opposée, il y a des vieux comme moi, parce que oui, en plus je suis vieux.
Ça fait 20 ans que je travaille, donc ça fait déjà 10 ans que je suis senior, il paraît.
En fait, avec mon expérience, j'ai acquis des compétences dans beaucoup de domaines
et en fait, mon métier de DevOps aujourd'hui, c'est mettre de la glu entre tout ce que j'ai appris.
Donc tout ce que font les autres en prenant des bases de données, des serveurs d'applications, etc.
en mode SaaS, moi je vais les intégrer moi-même.
Et alors en plus de tout ça, moi quand j'ai commencé à travailler,
j'ai commencé comme N-Mil-6, mais j'ai toujours fait un petit peu de dev à côté.
Donc aujourd'hui, dans mon quotidien, je suis DevOps, mais je fais aussi du développement backend.
Ça m'arrive de faire un petit peu de front, même si là on atteint mes limites en développement.
Et j'ai choisi le fait de ne pas m'y consacrer beaucoup plus que ça.
Mais c'est aussi pour ça que je définis mon poste comme étant un petit peu full stack,
puisque je peux toucher du front jusqu'à l'infra, avec tous les domaines,
les domaines, les connects, les backups, les sécurité, etc.
Est-ce que tu es d'accord avec le fait de dire que finalement,
pour moi, d'après ce que tu décris, c'est grosso modo être un administrateur
ou un administratrice système cloud à la DevOps en fait.
C'est-à-dire qu'on fait notre métier avec le cloud, avec la philosophie DevOps,
en faisant du développement, parce qu'on est obligés de faire du développement
de code d'infrastructure, à la genre de choses.
Ou est-ce que c'est encore autre chose que tu veux évoquer ?
Je pense que c'est un petit peu des deux, parce que finalement,
on est des DevOps comme les autres où on applique la philosophie.
On est des DevOps dans le mauvais sens du terme, c'est-à-dire qu'on est à la fois dev et on est à la fois DevOps.
Et à la fois, on est des administrateurs système, des DevOps qui ont évolué,
où en fait, on a appris à développer.
Et là, je parle vraiment que pour mon métier d'administrateur système.
Maintenant, je me connecte encore à un SSH sur les serveurs,
mais c'est pour aller vérifier des trucs.
Mais toutes mes installations, je ne fais plus rien à la main, c'est fini.
J'écris plus des modes opératoires, j'écris des programmes qui vont faire des choses pour moi.
Je tekin gentiment les gens qui font des longues cibles ou des choses comme ça,
parce que c'est du YAML As-de-Service, enfin du YAML As-Code, pardon.
Je ne sais pas de l'infra à As-Code, c'est du YAML As-infra,
bref, vous avez compris.
En fait, c'est de la configuration management ou du management de la configuration,
si tu veux que je sois pointilleux, parce que moi, je fais du encive et du terraform.
On pourrait parler du HCL aussi, qui est habitable, mais ça a d'autres sujets.
En fait, ce n'est pas forcément le fait que l'angage soit habitable,
parce que le YAML a résolu aussi plein de problèmes avant de faire du YAML,
donc on ne peut pas dire que YAML, c'est pire que YAML.
Ce que je reproche un petit peu aux outils qui sont un petit peu trop YAML centrés,
c'est qu'ils implémentent un petit peu trop souvent une description de l'infrastructure,
de la configuration, mais de manière un petit peu trop statique.
Et je pense qu'arriver à une certaine échelle, comme je le fais depuis quelques années,
parce que je travaille dans des boîtes où on déploie des centaines de VM de manière assez régulière.
On en déploie pas 100 par jour, mais on en gère une centaine au quotidien.
Et en fait, avoir un langage un petit peu trop descriptif, c'est limitant.
Donc c'est là où le DevOps, le côté Dev dans le métier-Ops devient important,
parce qu'on va rajouter des structures conditionnelles en fonction des machines,
on va rajouter des boucles pour gérer des ensembles de VM,
on va rajouter des boucles pour aller chercher des adresses IP pour configurer des clusters de manière automatique.
Et en fait, tout ce qu'on faisait à la main avant, maintenant on le fait de manière entièrement automatique.
Et finalement, le but, c'est d'en arriver à un point où on a une plateforme de test,
on la détruit complètement, un terraforme destroy, il y a quel que soit l'outil que vous utilisez,
vous refaites un terraforme play, vous refaites tourner votre outil de gestion de conf,
que ce soit en cible, sal stack ou autre chose, et votre plateforme, elle est prête à tourner.
Donc, alors il n'y aura pas à les donner de vos clients et ainsi de suite,
parce que c'est encore une autre procédure, mais vous avez une plateforme qui est fonctionnelle.
– Mais justement, là tu parles de développement d'infrastructures
qui nécessite des connaissances et des compétences de connaissance de l'infrastructure.
Dans ce que tu as dit au tout début, tu parlais de DevOps backend et front-end.
Moi, à l'origine, je suis développeur, donc je suis développeur backend.
Aujourd'hui, je ne touche plus du tout au développement backend.
J'encadre un alternant en développement front, mais c'est tout en fait.
Par contre, je ne fais que du développement d'infrastructures, du code terraforme,
du code en cible, du bâche, de l'intégration continue.
Je ne me considère pas moi, en tout cas, comme un développeur full stack, comme tu le dis.
La question que je vais te poser, c'est est-ce que justement, en faisant ça,
tu ne considères pas que tu perds quelque chose dans tes connaissances et des spécialités,
en faisant du développement, parce que finalement, ce n'est pas ton taf.
Et est-ce que ce n'est pas le même travers quand les développeurs et développeuses font de l'ops
parce que ce n'est pas leur taf ?
C'est la première question et la deuxième question qui vient avec le fil,
c'est est-ce que justement, nos entreprises ne nous en demandent pas trop à nous,
qui ne sommes que des hommes et des femmes, avec des connaissances profondes, mais quand même limitées,
pour justement limiter les coûts, parce qu'on coûte trop cher pour elles.
On n'est que des êtres humains pour être encore un petit peu plus inclusifs.
Exactement, merci.
Mais oui, effectivement, pour répondre à la dernière question,
oui et non, en fait, j'ai 20 ans d'expérience, donc j'ai eu le temps d'apprendre énormément de choses.
Et quand il y a un junior qui arrive dans l'entreprise, je ne vais pas lui demander
d'en connaître autant sur l'intégralité de l'infrastructure, parce que,
maintenant, ce n'est pas possible de tout connaître.
Et moi-même, j'en arrive à un âge où je connais énormément de choses,
mais la meilleure chose que je connais, c'est tout ce que j'ignore,
parce que j'ignore encore plein de domaines.
Malheureusement, on n'a que 24 heures par jour, et là-dedans, il faut dormir, manger et se reposer,
parce que sinon, on sera encore moins efficace pour travailler.
Mais j'ai encore énormément de choses à apprendre, et je sais très bien
qu'une fois mort, je n'aurais pas appris tout ce que je voulais apprendre.
Mais ce n'est pas grave, c'est tout ça pour dire qu'il faut savoir apprendre les choses au bon moment.
En ce moment, je me coupange beaucoup sur les aspects sécurité,
mais au sens normalisation du terme, et à encore plus blinder les infrastructures,
parce que je commence à avoir des audites de sécurité de plus en plus péchues,
et j'ai des besoins de normalisation, ISO 27000, etc.
Donc ça, c'est des sujets sur lesquels je n'avais pas trop travaillé.
Mes infrastructures sont déjà bien sécurisées,
mais il y a encore des aspects améliorés.
Donc ça fait partie de mes sujets du moment,
mais ça ne m'empêche pas de continuer à travailler sur d'autres sujets.
Est-ce que ces sujets-là ne pourraient pas être traités par des personnes
qui soient des frélands, soit des personnes de votre entreprise,
qui seraient spécialisées là-dedans, plutôt qu'à chaque fois que je faisais de la prestation,
je disais oui à tout, parce que c'était il y a sept ans,
j'étais encore dans la force de l'âge.
Aujourd'hui, à 46 ans, je commence quand même à sentir l'âge,
et le fait que je ne suis plus aussi performant qu'il y a dix ans.
Est-ce que dire oui à tout et réapprendre tout le temps plein de nouvelles choses,
est-ce que c'est pas anti-productif pour toi et pour la société pour laquelle tu travailles ?
Je ne suis pas totalement sûr.
Je pense qu'au contraire, ça permet de bien maîtriser tout ce qui est faisable.
Là, par exemple, dernièrement, on a vu des datacenters qui brûlaient,
et des gens qui disaient, ah bah là là, vous êtes trop nuls parce que votre infra est tombé.
Bah oui, ok.
Mais en réalité, il y a des gens qui se sont appuyés sur des providers qui étaient censés être sérieux
et fournir des niveaux de disponibilité, etc.
Et le fait d'être spécialisé un petit peu dans tout,
ça me permet d'avoir suffisamment de recul sur l'intégralité du périmètre
et de me dire qu'il y a un problème de ce côté-là, il faut creuser,
ou alors avoir le recul nécessaire pour se dire, bon, bah là, ok, il y a un problème,
mais aujourd'hui, j'ai plus urgent, j'ai peut-être plus important à traiter.
Et comme tu le dis, on peut sous-traiter.
Après, aujourd'hui, je suis dans une petite start-up,
on n'a pas forcément les moyens d'embaucher du monde en plus,
alors on embauche régulièrement, mais il y a quand même un rythme à avoir.
On a le chiffre d'affaires qui grossit, on a le nombre de clients qui grossit
et donc les effectifs qui grossissent.
Mais on ne peut pas se permettre d'embaucher une personne par mois
pour adresser des différents sujets.
On pourrait aussi faire bosser des freelance, mais un freelance,
ça coûte aussi plus cher qu'un salarié.
Oui, pourquoi il coûte plus cher qu'un salarié ?
Tu peux nous le dire, parce que je sais que toi, t'es freelance à côté.
Oui, alors en fait, pourquoi un freelance, ça coûte plus cher ?
C'est parce que vous allez le payer sur une mission en one-shot,
mais il a une expertise et quand il va arriver dans l'entreprise,
il va être directement opérationnel, il va vous résoudre votre problème tout de suite.
Là où quand vous allez embaucher un salarié, ça va être du long terme.
Donc vous allez avoir une phase d'unboarding, vous allez le faire rentrer dans l'entreprise.
Et dans l'entreprise, c'est le côté technique, le côté humain, etc.
Et c'est un investissement long terme.
Donc vous allez lui donner les clés pour qu'il soit réellement opérationnel pour plus tard.
Un freelance, vous enfoutez, qui connaissent toute la boîte et comment fonctionne la boîte.
Enfin, vous enfoutez entre guillemets, on peut rester humain quand même avec les gens.
Mais si vous avez besoin de mettre un nouveau cluster de machin de trucs
en très haute disponibilité ultra sécurisée, il va venir pendant un mois,
vous allez le payer un mois et à la fin du mois, ça sera terminé,
le sujet sera clos, il aura formé les gens et ainsi de suite.
Et comme sa mère se naitre, il va aller faire la même chose dans une autre entreprise.
Mais il ne va jamais rester chez vous parce qu'une fois sa mission terminée, il va s'ennuyer.
Donc il ne va pas s'ennuyer au bout d'un mois, mais il va s'ennuyer au bout de deux.
Parce que lui, faire du run, ça n'intéresse pas.
Il va faire du build sur d'autres projets, ça n'intéresse pas.
Il est là pour faire une mission au OneShot.
Et c'est pour ça que vous le payez très cher.
C'est parce qu'il a une expertise hyper pointue sur le domaine qui vous intéresse.
Et là, c'est pareil.
Si j'avais un expert à faire venir, c'est ce que j'ai toujours entendu.
C'est sous-traiter les choses que vous savez faire.
C'est aujourd'hui, si j'avais quelque chose à sous-traiter,
j'embaucherais un prestataire pour me faire déployer une phrase sur la AWS,
sur du Scaleway, sur du machin.
C'est des choses, moi je sais les faire.
Par contre, c'est sécuriser toute mon infrastructure.
Je me ferai accompagner, mais je ferai les trucs moi-même
parce que c'est des choses où j'ai besoin d'apprendre.
Et si jamais...
Ça te permet en plus d'avoir un recul sur le travail que fait les prestataires
ou les personnes auxquelles tu délèques les choses.
Exactement.
Et en fait, il y a deux avantages.
Comme tu le dis, c'est d'avoir du recul.
Mais le deuxième truc, c'est que si jamais ton prestataire déconne,
alors tu t'en rends compte rapidement, et quand il t'en fume, tu te rends compte tout de suite.
Mais il y a une chose critique que tu sais, c'est que si jamais t'as une deadline
sur le projet et que ça dérive trop,
tu sais quand est-ce que toi, tu peux reprendre la main pour finir le truc à temps.
Et ça, c'est hyper critique.
Et quand vous prenez un prestataire sur un sujet que vous maîtrisiez moins,
le prestataire peut vous enfumer, parce qu'il y a aussi des gens malhonnêtes.
On n'est pas dans le pays des mise en orse.
Mais surtout, si vous dites qu'il y en a pour 6 mois et qu'en réalité, il y en a pour 3 ans,
vous allez vous retrouver la tête dans le mur.
Et vous ne pouvez rien faire pour rattraper le coup, puisque vous ne connaissez pas le domaine.
Oui, c'est hyper chaud.
En plus, les estimations, en plein dans la tête, dans un modi,
ils me demandent d'estimer de leur proposer un planning.
Mais c'est hyper dur, parce que tu ne sais pas comment l'équipe qui va traiter ça, elle est veloce.
Tu ne sais pas comment est-ce qu'ils sont coordonnés.
Tu ne sais pas quel est leur niveau technique.
C'est chaud et même à frilance, il peut avoir des surprises.
Surtout dans l'infrastructure, je trouve que c'est encore plus dur d'estimer
combien de temps on va prendre du code d'infrastructure que du code de DEV.
Parce que je trouve que le code de DEV, c'est relativement limité en termes d'impact.
Alors que le code d'infrastructure, tu as plein de trucs que tu ne maîtrises pas.
Alors là, on me met même le doigt sur un sujet où je suis assez mauvais, c'est les estimations.
Je ne m'en cache pas.
J'en ai un tout petit peu honte, donc le répéter à personne.
Mais c'est vrai que ça ne sortira pas d'Internet, ne vous inquiétez pas.
C'est vrai que sur les estimations, les estimations, c'est quelque chose qui est toujours compliqué.
Et autant sur le code pure métier, c'est quelque chose qui est peut-être un tout petit peu plus facile à borner.
Parce qu'on a des fois un petit peu de recul sur la complexité d'un algorithme, etc.
Et ce qui a d'un petit peu compliqué dans une infrastructure, c'est que, à un moment donné,
vous avez besoin de mettre tous vos trucs en haut de dispo, donc c'est facile.
Vous avez des docks dans les différents produits qui vous disent,
« Bah oui, bah tu mets en haut de dispo, machin, etc. ».
Et puis à un moment on me dit, « Ah bah oui, mais en fait c'est quand même vachement mieux
si tu as un DNS, un Revers Proxy, peu importe le truc. »
Puis tu dis, « Ah bah oui, oui, c'est vrai qu'on va gagner du temps en mettant ce truc-là. »
Puis en fait, tu mets ce truc-là, puis après, « Ah bah oui, mais en fait pour ça,
il faudrait ça, puis après ».
Et en fait, quand tu déroules la plot, tu te rends compte que le sujet sur lequel tu pensais passer
au début une semaine, tu vas y passer deux mois.
Et un sujet sur lequel tu pensais passer deux mois, tu vas passer trois ans.
Et en fait, c'est ça qui peut être compliqué pour un freelance.
On ne va pas demander à un freelance en lui disant,
« Tiens, montre-moi la plateforme pour le produit Intel sans qu'il connaisse le produit ».
Et quand je dis le produit, c'est le produit du métier de l'entreprise.
Ce n'est pas un post-grès SQL ou un chaproxy, c'est vraiment le métier de l'entreprise
sur une base de code qui ne connaît pas, sur une infrastructure où on lui dit,
« Bah oui, il y a besoin d'une base de données post-grès et puis d'un Redis et puis d'un
serveur d'application en Tomcat ».
Bon, globalement, ça, il sait le faire.
Mais toutes les implications qu'il peut y avoir derrière, et puis après, au fur et à mesure,
c'est « Ah oui, on a oublié de te dire, mais il faut que ça soit hébergé sur de l'HDS ».
Vous avez des contraintes techniques, mais des contraintes réglementaires.
Donc, il faut un hébergeur HDS et donc, il faut que tous les flux soient bien cloisonnés.
Enfin bref, c'est un enfer.
Et je trouve que côté infrastructure, c'est peut-être un tout petit peu plus compliqué
de faire des estimations là-dessus.
Et bon, tout ça pour dire, j'ai d'autres copains qui arrivent mieux que moi.
Donc, bah, si vous voulez avoir un planning hyper précis, j'ai des noms à vous donner.
Mais bon, après...
Attends, j'ai une question à te poser.
Si ces copains arrivent mieux que toi, est-ce que c'est pas justement parce qu'ils se spécialisent
dans certains types de stack et qu'ils n'en changent pas pour éviter la découverte aussi ?
Pas forcément. Je pense que pour en avoir beaucoup discuté avec eux.
Alors, je dis que j'ai du mal à le faire.
C'est parce qu'il y a quelques années, je me plantais toujours dans mes estimations.
Maintenant, j'y arrive mieux.
Pour en avoir beaucoup discuté avec eux.
Et si ils écoutent le podcast, ils se reconnaîtront tous.
En fait, je suis un éternel optimiste et j'ai toujours tendance à penser qu'il n'y aura pas de problème.
Alors qu'en fait, je sais qu'il y en aura des problèmes.
Donc, c'est juste qu'il faut que je me mette dans la tête, qu'on va avoir plein de problèmes et qu'il faut estimer.
Et pourtant, c'est un des premiers trucs que j'ai appris quand j'ai commencé à travailler.
J'ai demandé à mes collègues comment tu fais pour estimer toi.
Tu prends le temps que tu estimes nécessaire pour le faire, puis tu multiplies par deux.
Donc comme ça, ça va représenter à peu près ce que tu vas faire.
Et tu rajoutes 10% parce qu'il y a de l'allaire.
Je vais confirmer ce que tu viens de dire parce qu'on vient de faire une migration sur un produit.
On avait devisé un certain temps, 10 heures.
Et en fait, il s'est aperçu qu'après coup, on avait mis 20 heures, donc deux fois plus.
Et pourtant, je me rappelle qu'au moment du devis, j'avais dit à mon collègue que tu es sûr là.
Parce que c'est lui qui a dit que tu es sûr là.
Ça me paraît un peu ambitieux.
Il me dit oui, il n'y a pas de problème.
Je fais ça.
Et donc, je vais prendre ton truc parce que jusqu'à présent, j'étais plutôt du genre à rajouter 20%.
Mais je pense que multiplier par deux et rajouter 10% c'est bien.
Et après, on a les prospects qui vont nous dire mais c'est ultra cher.
On va leur dire oui, mais en fait il y a l'Alea et tout.
Si ça coûte moins cher, tant mieux pour vous et si ça coûte plus cher.
Voilà, je pense que c'est ça qu'il faut dire.
C'est voilà ce que ça peut coûter.
On signe là-dessus et on vous garantit que si on met deux fois moins de temps, vous payerez deux fois moins cher.
Mais si ça prend ce temps-là, vous payerez ce temps-là.
Et après, c'est pareil.
Ça dépend sur quelle base contractuelle tu te bases.
Mais si tu fais du forfait, tu vas dire voilà, c'est moi je m'engage à ce que vous payez ce prix-là, quoi qui se passe.
Et en fait, c'est une gestion du risque.
Tu peux aussi dire non, c'est ce prix-là et c'est tout.
Et si ça déborde fois deux, ça sera pour nous.
Mais si on va deux fois plus vite, c'est aussi pour nous parce qu'on a de l'expérience là-dedans.
Et puis voilà, comme tu le disais, je fais de la prestat aussi à côté.
Une fois, on m'a appelé pour mettre à jour un grub.
APT Get Upgrade Grub.
Tous ceux qui sont admin 6 se disent, ouais, bon, mais il sait.
J'ai dû faire payer la prestat.
Je ne sais plus si c'était 400 ou 700 euros, je ne sais plus.
Pour faire un truc qui normalement prend cinq minutes, vous vous dites, ah ouais, c'est quand même vachement bien payé.
Mais ce que j'avais garantie aussi, c'est que si ça se passait bien tant mieux, j'incluais toute la phase de préparation.
Donc la semaine d'avant, je leur ai demandé si vous avez bien tout sauvegardé.
Je leur ai demandé les accès au console.
Et je me suis connecté à la console pour vérifier que j'arrivais bien connecté en route.
Si jamais le reboute se passait mal pour que je puisse aller faire des actions, etc.
Et des problèmes de grub, j'en ai déjà eu un bon paquet.
Et quand je dis un bon paquet, ça se compte même plus sur les doigts d'une main tellement j'en ai eu.
Et j'ai réussi à récupérer des accesses sur des systèmes qu'on pensait perdu.
Parce qu'il faut rebouter sur un système temporaire.
Il faut remonter tous les fails systèmes qu'il faut bien dans un H route.
Il faut relancer le grub, etc.
C'est des opérations qui, quand vous l'avez jamais fait, ça prend du temps.
Et bien en fait, là où on revient à ce qu'on disait tout à l'heure, j'ai fait le mercenaire.
J'ai dit voilà, ça coûte de temps.
Alors oui, c'était cher.
Mais l'entreprise, elle m'a payé ce prix-là pour réduire son risque.
Et finalement, peut-être que pour un Nyanmin 6, c'était cher cette solution-là.
Mais mon client était très content de payer ce prix-là parce que du coup, ils ont dormi le jour où j'ai fait l'opération.
Ils ont dormi sur leurs deux oreilles.
Et en fait, c'est ça où quand on fait ces métiers-là, parce que je fais aussi l'administration de l'infogérance pour d'autres clients,
ils me payent pour pouvoir dormir sur leurs deux oreilles.
Alors du coup, c'est moi qui dors un peu moins, mais c'est pas grave.
Mais en fait, ils me payent pour superviser, sauvegarder, etc.
Parce que c'est mon métier et eux, c'est des développeurs et ils veulent se concentrer sur leur métier pour développer des produits
pour vendre des bonbons sur Internet ou je ne sais pas quoi.
Leur métier, c'est ça.
Leur métier, c'est pas de gérer une infrastructure.
Ok. Est-ce que justement...
Et je vais revenir à une première question, on n'a pas répondu tout à l'heure.
Le fait que je sois DevOps, c'est que je fasse de l'infra à SCOD, et que du coup, je fais moins de devs qu'avant.
En réalité, j'ai fait du devs au fur et à mesure.
Et en fait, j'ai recommencé à faire du vrai développement entre guillemets sur des couches hautes.
Donc je développais du Ruby on Race pour des petites applications pour me simplifier la vie.
Et en fait, je suis descendu dans les couches en même temps que je suis remonté sur l'admin 6,
juste qu'à un moment donné où tout ça, ça sert joint.
Et en fait, aujourd'hui, pour ma boîte CGWire et pour la boîte précédente Squarespace,
j'ai fait des produits qui, fonctionnellement pour les utilisateurs, sont radicalement opposés,
mais qui ont le même but à la fin, c'est qu'on transcrit des données métiers sur l'entreprise.
Donc on a tel client, il a tel type d'instance, il a une connexion, une base de données, patati, patata.
Tout ça, c'est décrit dans un modèle de base de données.
Il y en a eu pays-de-vent.
Et en fait, ça déclenche des trucs dans Terraform, dans Uncible, dans Salestack, tout ce qu'on veut.
Et là, l'infra, elle va tout se déployer de manière quasiment automatique.
Et en fait, cet API, c'est moi qui les construisent.
Donc il fallait les compétences en base de données pour modéliser la base,
même si maintenant avec les ORM et tous ces trucs-là, c'est un petit peu plus simple.
Il a fallu que je développe l'API.
Je sais parce que je connaissais, je fais pas mal de pitans,
et du coup, j'avais essayé Flask, mais c'est pour ça que j'ai su qu'il fallait que je fasse du Django,
alors que l'API de notre boîte, elle, elle est écrite en Flask.
Donc j'aurais pu le faire en Flask pour que tout le monde puisse la maintenir,
mais j'ai fait le choix de la faire en Django pour me simplifier la vie.
Et j'ai bien fait.
Donc tout ça pour dire que c'est aussi pour ça que je me définis comme full stack,
c'est que je fais du dev backend en restant, dans le côté backend,
je peux développer sur ma machine et pousser en prod,
comme je développe des trucs d'infrastructure, terraformes, machin, etc.
Des trucs qui vont tourner sur les machines pour relancer les trucs en automatique quand ça se casse la gueule.
Des scripts qui vont simplifier le redidimentionnement de volume,
parce que je fais beaucoup de LEM, des choses comme ça.
Merci.
Je vais te poser ma question suivante, parce que j'aimerais bien relancer le sujet à du freelance,
mais on n'est pas là pour ça.
Peut-être qu'on fasse une émission spéciale sur les frilances dans l'ops,
parce que c'est tellement rare que ça mériterait un podcast.
Je voudrais justement que tu approfondisses un peu ce truc de DevOps full stack.
C'est quoi ton quotidien, en tant qu'auto-proclamé, on va dire comme ça, DevOps full stack,
et tu peux compléter par qu'est-ce que tu penses que c'est le quotidien
des fameux ingénieurs DevOps full stack qu'on trouve partout et qui sont recrutés à tour de bras.
Alors pour les full stack, je ne peux pas forcément totalement parler à leur place,
mais on en a quand même quelques-uns dans ma boîte, parce que quand on est 5,
à un moment donné, tout le monde doit savoir un petit peu tout faire.
Et c'est ça aussi l'intérêt d'embaucher des full stack,
c'est quand vous êtes une startup,
à un moment donné, quand je me mets à la place du CEO qui n'a aucune compétence technique,
il va falloir commencer par recruter une personne.
Donc il va falloir bien choisir cette personne-là,
parce qu'il va falloir qu'elle sache faire à la fois du développement et à la fois d'éployer votre application.
Donc là, un petit conseil au passage,
c'est embaucher un bon développeur et déployer dans du pass type clévercloud et recoup tout ce que vous voulez.
Mais prenez pas...
Oui, je suis d'accord avec toi. Je plusvois.
Si vous commencez, faites ça. Ne faites pas votre chose.
Ou alors, vous avez les moyens de vous payer un prestataire comme moi,
qui va vous faire de l'infogérance pour pas trop cher,
parce que j'ai des tarifs qui sont extensibles en fonction de votre chiffre d'affaires,
parce que j'ai choisi de faire comme ça,
parce que quand on va commencer à travailler ensemble,
en réalité, vous avez avoir 10 clients sur votre plateforme,
donc la pression sur la disponibilité va pas être énorme.
On met ça sur un petit VPS, Poff-Poff, ça y est, c'est terminé, c'est déployé en 10 minutes.
Et les actions, c'est même pas du quotidien,
c'est à la rigueur du mensuel pour faire une petite mise à jour de temps en temps.
Par contre, quand l'infra va grossir, vous allez avoir 50 employés,
vous allez avoir quelques millions de chiffres d'affaires,
votre base de données va être énorme, elle est en cluster,
il faut avoir des backups, il faut chiffrer, il faut machin.
Donc là, ça prend plus de temps et donc vous payez plus cher.
Et à un moment donné, vous pourrez vous poser la question de changer de prestataire,
parce qu'à un moment donné, quand vous allez rentrer au CAC 40,
clairement vous n'allez plus travailler avec moi, vous allez embaucher quelqu'un,
et il se fera ça à temps complet,
ou alors vous allez embaucher une entreprise qui a plus de salariés,
parce que moi je suis tout seul, et pour l'instant, ça marche comme ça.
Mais par exemple, j'ai un de mes clients qui est parti chez Waze,
une entreprise dans laquelle un de nos hostre podcasteur est parti travailler,
donc Damir, coucou, si tu nous écoutes,
j'ai failli travailler à ta place, mais j'ai préféré continuer à travailler en start-up
et garder mon statut de freedom de sa côté.
Et d'ailleurs, du coup, j'ai oublié la question initiale.
C'est pas grave, je vais réagir un petit peu, je te la repose la question.
T'as préféré travailler en start-up et avoir ton statut de freelance à côté,
parce qu'en fait ton statut de freelance ne fait pas, comment dire,
il n'est pas concurrent à ton travail en start-up par contre,
si tu travailles chez Waze, comme tu fais de la prestation,
ton statut de freelance est clairement en concurrence avec la boîte qui t'embauche.
C'est bien ça ?
C'est une des raisons de pourquoi j'ai préféré rester à travailler en start-up,
pour plein de raisons, c'est aussi parce que j'aime bien le côté freelance,
parce que ça me permet de discuter avec plein de gens,
parce que je discute avec des prospects assez régulièrement,
on ne travaille pas forcément ensemble,
des fois je leur dis d'aller travailler avec des solutions concurrentes,
comme prendre du plate-forme à ce service,
ou aller chez Waze, parce que peut-être qu'ils ont déjà des contraintes tellement énormes
que ça sera mieux chez eux, ils payeront beaucoup plus cher,
mais ils ont des contraintes auxquelles je ne peux pas répondre.
Et aussi parce que j'aime bien travailler dans une start-up
où je participe à la vie du produit,
et le produit ce n'est pas de l'infrastructure,
c'est aujourd'hui je travaille dans une boîte,
on développe une solution pour les studios d'animation de D3D,
et l'infrastructure c'est un des composants,
alors ce n'est pas la première fois que je travaille dans une entreprise
qui fait de l'open source,
où le business model c'est de vendre de l'infrastructure,
mais une grande partie de notre chiffre d'affaires vient de là,
parce que c'est notre business model,
et c'est ça qui m'intéresse, c'est de réussir à prendre un truc open source,
de l'installer dans une infrastructure propre à l'entreprise,
et de faire en sorte que ça soit exactement le même produit que la solution open source,
mais en version plus plus,
où finalement tu peux très bien l'héberger en open source toi-même,
sauf que si tu veux être tranquille, il vaut mieux venir chez nous,
parce qu'on maîtrise cette infrastructure,
on maîtrise le produit,
et si tu trouves un bug,
tu peux très bien faire une issue sur le github,
sur le produit, tu peux même faire une PR,
tu peux avoir les mêmes types de réponses,
mais si tu nous payes, tu as du support supplémentaire,
parce que si tu ne sais pas où cliquer pour changer un truc,
là on va t'expliquer, on va te former, etc.
là où sur la partie communautaire, elle n'y est pas.
Et en fait, ce qui m'intéresse, c'est d'avoir un ensemble.
C'est super intéressant, parce qu'on a la même approche en fait,
je ne savais pas exactement ce que tu faisais,
on n'avait pas vraiment parlé,
on a la même approche nous avec nos SASS,
parce que nous aussi on se base sur des briques libres,
et on propose exactement le même service que tu viens de décrire,
et je trouve que c'est hyper vertueux,
parce que comme tu le dis,
si les clients veulent partir sur des briques libres,
qui veulent gérer eux-mêmes, ils peuvent partir avec leurs données.
Par contre, en effet, nous on a l'expertise,
et vous aussi vous avez l'expertise qui fait que,
a priori, ça marche mieux,
et ils n'ont pas besoin de s'en inquiéter.
C'est même un petit peu plus poussé que toi,
c'est que la solution Open Source est développée par ma boîte.
Ah oui, oui exactement.
Donc on n'en corpore à ce niveau-là,
mais on va y arriver je pense à jour.
Mais c'est super intéressant, parce qu'en fait,
tu t'es en compte au bout d'un moment,
ton plus gros concurrent c'est toi-même.
Et c'est là où c'est vraiment intéressant,
c'est qu'il faut que tu gardes une excellente qualité
sur le produit Open Source,
sur la qualité du code,
sur le fait qu'il soit facile à lire,
à maintenir, etc.
Parce que c'est du communautaire,
et si tu veux que ta communauté vive,
c'est la seule solution,
c'est de faire en sorte que les gens puissent contribuer.
Et en même temps, il faut réussir
à prendre cette brique-là,
qui est déjà très bien,
mais à la faire en mieux.
Donc c'est tout le travail qu'il y a
autour de l'infrastructure,
à faire en sorte que les VMs soient toujours à jour,
que les systèmes soient robustes, etc.
Même quand tu les déploies chez OVH,
qui de temps en temps brûle un petit data center,
et c'est pas gentil de se moquer des concurrents,
parce que cette semaine Google a fait la même chose,
donc ça arrive à tout le monde.
Vous pouvez continuer à taper sur OVH,
mais dans ce cas-là,
vous pouvez inviter Google au barbecue en même temps.
Et tout ça, pas.
Et en fait, c'est là
où ça met vraiment en évidence
la nécessité de maîtriser tout ce truc-là.
Parce que finalement,
en fait, à l'heure où on tourne cet épisode,
c'est le lendemain du data center de Google
qui a cramé, je crois que c'est à Paris.
Et en fait, il y a plein de gens qui sont refusqués.
Quoi ? Mais c'est sur 3 az,
et vous avez perdu toute une région.
Ben oui, et ben ça arrive.
Mais quand ça arrive,
il faut que les entreprises aient conscience
que c'était un choix stratégique.
Moi, si j'ai un data center qui brûle chez OVH,
je perds une partie de ma prod,
et j'en ai parfaitement conscience.
Par contre, j'ai fait en sorte que les données
soient dans un autre data center aussi.
Et que si jamais ça brûle,
je suis capable de tout remonter.
Alors, la question, c'est en combien de temps ?
Oui, je vais pas le faire en un claquement de doigt,
mais ça ne va pas me prendre 6 mois.
Donc c'est un entre-deux, etc.
C'est souvent ça le truc qu'on a fait,
c'est combien de temps ça prend
et combien de temps tu peux faire un PRA.
On a fait d'ailleurs un épisode
sur le PRA.
Si tu ne l'as pas
vu, je te mets une fiche
citée sur YouTube.
Je sais plus, jamais, je crois que c'est là-haut.
Cité dans le podcast, c'est en description.
Tu n'as pas d'apprendre plus sur les PRA,
les SLA, etc.
Je vais te reposer la question,
comme ça, tu pourras y répondre.
Mais t'as en partie répondu.
C'est quoi aujourd'hui ton quotidien
de

de DevOps full stack ?
Oui.
Justement, ça dépend
des jours et c'est ça qui est génial
d'être dans une start-up, parce que
ça peut très bien être
« Tiens, il y a une nouvelle faille qui vient de sortir,
donc il faut mettre à jour tout le parc ».
Donc,
ça va être
étudier la faille,
parce que
des fois, c'est plus ou moins critique.
Parce que entre une faille
où
c'est pour l'exploiter, il faut
ceci, il faut cela, etc.
Et finalement, la probabilité que ça arrive
sur votre infras, c'est quasi nul.
Donc, vous pouvez attendre une semaine
pour mettre la faille à jour.
Et puis, vous avez une faille
type log-forchelle
où la probabilité
que ça arrive,
c'est juste
qu'il y a un coeur qui s'intéresse
à vous, donc dans ce cas-là, vous patchez tout de suite
et vous patchez en pleine journée, quitte
à redémarrer toute l'infra.
Donc, il y a une partie du boulot, c'est ça.
Après, il y a une partie du boulot,
c'est travailler avec les développeurs,
parce que la philosophie de DevOps,
c'est ça, c'est travailler avec les développeurs
pour dire « Tiens, de quoi
t'as besoin ? Et moi, j'ai besoin de ça ».
Donc, c'est des échanges
très réguliers
sur la bâtiens.
Là, en ce moment, il y a un problème
en prod, ça pourrait être
résolu si tu rajoutais cette fonctionnalité.
Et
de la même manière,
c'est, il vient de me voir
en me disant « Tiens, on a un problème
sur le truc, est-ce qu'on pourrait
avoir un moteur qui fait si ?
Est-ce qu'on pourrait
installer ça ? » Là, en ce moment,
on est en train de regarder
pour tout ce qui est chiffrement,
pour chiffrer
tout en base de données
dans l'object storage, etc.
Parce que
encore une fois,
comme je suis en start-up, on fait
des choix techniques et fonctionnels,
jusqu'à présent, personne nous l'avait demandé,
donc on l'avait pas fait, mais là,
on a des clients qui commencent à s'y intéresser,
et bien on commence à étudier
comment on va faire ça.
Et c'est vraiment
des réflexions DevOps dans le
sens
le plus pur du terme,
c'est « Je propose des solutions
qui sont autant
infrastructure que développement ».
C'est « J'ai proposé
soit on installe un volt et on fait
tout chiffré par le volt et on envoie
la donnée en base,
etc. soit on utilise
une libre piton qui fait du chiffrement
AES, etc. et j'ai proposé
les avantages et les inconvénients
de toutes les solutions. C'est pas moi qui vais
implémenter la partie dans le code,
même si techniquement je pourrais le faire,
mais il y a des gens qui sont beaucoup plus
compétents que moi en piton
et qui feront ça beaucoup plus rapidement
que moi. Par contre, côté infrastructure,
c'est moi qui suis le plus efficace,
donc c'est moi qui vais le faire.
Après, bon, comme tout le monde
j'ai des réunions, donc dans ma boîte
on est aussi en full remote,
donc on a notre daily
tous les jours à 16h,
on a des weeklys,
on montre régulièrement à Paris
pour tous se voir, se faire
un petit resto
une après-midi de travail
sur où on est l'entreprise
ou va l'entreprise.
Quelques sujets techniques
ou humains, quand on a besoin
d'en parler. Et après,
comme on a une communauté,
on a aussi mis en place des meet-ups
pour échanger avec
le milieu de l'animation. Donc ça
permet aussi de rencontrer
nos clients, nos prospects
voir
des gens qui travaillent
avec des solutions totalement concurrentes
à la nôtre et dont
on a, entre guillemets, jamais entendu
parler comme clients
parce qu'ils utilisent
des solutions concurrentes à la nôtre.
Je pense même qu'on a des utilisateurs
de notre solution open source qui viennent
et en fait, on discute
avec tout le monde parce que
c'est cool aussi.
Et toute l'entreprise
est invitée à faire ça.
Après,
qu'est-ce qu'il y a d'autre ?
Il y a la gestion
du run. Vous avez
un fail system qui est plein,
une VM qui a cramé,
un hypervisor qui est dans le sac,
vous avez
votre backup qui marche plus,
votre ordonnanceur
qui est parti en kkwatsetmi,
votre système
de monitoring qui remonte plus,
votre système de monitoring qui vous envoie
trop d'alerte,
du run classique.
Et c'est d'ailleurs ça
que j'aime bien aussi
dans le milieu start-up, c'est qu'aujourd'hui
comme on est 4, 5,
je suis tout seul sur l'infra
et c'est moi qui fais tout.
Ce qui a de bien aussi, c'est que
quand il y a des trucs qui ne marchent pas
côté infra, c'est forcément de ma faute.
Je ne peux que me taper sur moi-même.
Et quand ça marche bien,
c'est de ma faute aussi et c'est gratifiant.
Oui, ça c'est important.
Dis-moi, il y a un truc qui m'a surpris,
t'as dit, vous avez un délit à 6h,
nous le notre, il a 9h du matin.
Il a 9h du matin pour plusieurs raisons.
La première, c'est pour démarrer la journée,
puisque on a
des novices dans notre équipe,
du coup, on a notre note de lit,
on demande à chacun de me dire, qu'est-ce qu'il a fait hier,
qu'est-ce qu'il a prévu de faire aujourd'hui
et surtout, est-ce qu'il est bloqué un endroit,
est-ce qu'il a besoin d'elle.
Et du coup, le faire à 2h du matin, c'est bien,
parce que ça permet, justement, de débloquer
les sujets qui sont bloquants.
Et aussi, comme on est complètement en remonte,
ça nous assure aussi que la personne,
elle est bien à son poste de travail
et qu'elle n'a pas eu un problème.
Parce que comme on n'est pas dans des bureaux,
on ne peut pas voir, tiens, moi je suis aussi employeur,
j'ai ma responsabilité d'employeur,
tiens, est-ce qu'il y a un problème
avec un de mes employés qui n'a pas pu venir
au travail ou qui a eu un accident
ou quoi que ce soit, c'est dans mon rôle d'employeur de le faire.
Donc, le délit 9h,
il est là aussi pour ça.
Si quelqu'un a le délit, ça veut dire
potentiellement qu'il lui arrive un truc,
c'est la première chose qui me vient à l'esprit,
c'est est-ce qu'il lui arrive un problème,
on l'appelle, on s'assure que tout va bien
et si tout va bien, c'est cool.
Et du coup, toi t'as dit que vous avez un délit à 16h,
c'est quoi ton retour, finalement, d'un délit à 16h,
est-ce que c'est bien, est-ce que c'est pas bien,
comment ça se passe,
est-ce que vous posez les mêmes questions
ou est-ce que c'est un peu différent ?
Alors, on se pose exactement les mêmes questions
parce qu'effectivement,
quand il y a une personne qui n'est pas là,
on s'en inquiète, mais en fait, on va s'en inquieter
plutôt dans la journée,
parce que des fois, on se pose des questions
sur Slack,
des choses comme ça, et puis,
on regarde, ah tiens, c'est bizarre,
je l'ai pas vu connecter aujourd'hui,
peut-être que ça va pas, etc.
Alors, après la question de quelle horaire,
j'en ai essayé plein,
parce que je suis passé dans plein de boîtes
en foule remote, et en fait,
16h, je trouve que c'est le bon compromis,
parce que ça coupe pas la journée en deux totalement,
parce que,
avant, je les ai fait vers 10h,
vers 11h,
mais ceux qui travaillent,
ceux qui commencent à travailler
le matin, du coup,
ça les coupe dans leur journée,
enfin, même dans leur demi-journée,
et c'est pénalisant pour eux.
Et pourquoi,
c'est à 16h chez nous, c'est parce qu'il y a beaucoup de
personnes qui ne sont pas du matin,
et ceux qui sont du matin,
sont toute la matinée pour travailler tranquille,
donc c'est-à-dire
que je suis quasiment le seul à
travailler sur tout le matin,
parce que c'est comme je suis vieux,
j'ai eu des enfants, donc il a fallu que je me lève
pour les emmener à l'école, donc j'ai pris un rythme
de
travail,
où finalement,
je me lève relativement tôt,
je travaille, je commence relativement tôt,
donc
j'ai mon petit rituel,
où je me lève en même temps que ma compagne
qui elle va travailler au bureau,
je regarde mes mails, mes messages dans cela,
que les alertes, et puis,
après, je prends mon petit déjeuner tranquille,
et puis, je viens chez moi pour travailler,
parce que comme ça, ça me permet
d'avoir un bureau à part,
comme ça, vous savez plus,
sur ma vie privée, j'ai 2 domiciles,
et le fait que ça soit à 16h,
c'est bien aussi, parce que ça permet
à tout le monde d'avoir des horaires
de travail comme il veut,
c'est...
16h, c'est l'heure du goûter, donc soit tu goûtes avant,
soit tu goûtes après, mais ça
permet d'avoir une petite pause en milieu de journée,
et ceux qui sont
vraiment pas du matin peuvent commencer
à 13h et finir à 3h du matin,
et ceux qui sont du matin
peuvent commencer à 6h du matin,
et terminer à 16h30,
et je trouve que c'est un excellent
compris, promis pour tout ça.
Et après, la question
du bien-être des employés,
en fait, nous c'est à l'inverse,
c'est quand on a un souci,
on va aller dire sur Slack,
bon, là j'ai eu un accident,
je pourrais pas être présent
demain, j'ai un rendez-vous
chez le médecin, je suis en retard,
c'est...
on n'hésite pas à se dire quand ça va pas.
C'est pareil,
je te rassure,
on a un chat matermost,
puisqu'on est sur Foguid, évidemment,
on n'hésite pas à se dire les choses,
c'est vraiment...
ma question c'était plus
est-ce que si tard,
ça te permet justement
de répondre aux questions, genre,
ta... ta t'escollec qui est bloquée,
euh...
et qui a peut-être pas forcément osé
avant de le dire, ça peut arriver,
c'est pour ça aussi que le délit est là,
et qui a pas osé le dire avant, est-ce que ces heures,
c'est pas un peu tard, pour justement
entamer
une réunion de correction avec cette personne-là ?
Alors,
plusieurs parties dans la réponse,
c'est déjà quand on fait passer des entretiens,
j'insiste toujours sur un fait que,
comme on est en full remote,
il faut que les gens soient autonomes,
mais il faut qu'ils soient autonomes,
il faut qu'ils sachent travailler tout seul,
mais il faut aussi qu'ils sachent appeler à l'aide,
c'est... on n'est pas sur leur dos toute la journée
pour voir qu'ils sont en train
d'lander sur internet,
ou en train de galérer,
ou en train de tourner autour de leur clavier,
parce qu'ils trouvent pas de solutions,
donc c'est de la responsabilité de chacun d'appeler à l'aide,
et c'est ce que je dis toujours,
c'est oser
déranger un collègue pendant 5 minutes,
si ça vous fait gagner, vous,
une heure, parce que une heure pour vous,
c'est une heure pour l'entreprise,
et si votre collègue vous résout votre problème
en 5-10 minutes,
ça va pas l'interrompre dans sa journée de travail,
il faut pas exagérer.
Après, il faut aussi accepter
que votre collègue vous dise,
ah non, là, j'ai pas le temps.
Par contre, bah, laisse-moi terminer mon truc,
dans 10 minutes, dans 1 heure,
je serai libre,
on se fait une réunion,
on discute très régulièrement
sur, on utilise discord
pour la partie vocal,
parce que beaucoup de nos utilisateurs
sont dessus, donc ça nous permet
d'avoir qu'un seul canal de communication.
Et après, est-ce que c'est tard
pour appeler à l'aide
après le délit, bah, comme
tout le monde
n'est pas spécialement du matin,
finalement, c'est plutôt l'inverse,
c'est tiens, j'ai galéré toute la journée,
on a des questions,
et il y a tout le monde qui est là
autour de la table pour dire,
bah tiens, moi je peux t'aider,
et finalement, je trouve que c'est peut-être mieux
dans ce sens-là, parce que
on est bien contents de terminer
sa journée de boulot sur quelque chose
de soit complice, soit on a
une piste, une solution,
plutôt que
si tu fais ton délit
à 9 heures, on va être aidés
à résoudre tes problèmes de la veille,
mais à la fin de la journée,
tu termines un petit peu frustrés,
parce que tu n'as pas terminé ce que tu voulais faire.
Après,
est-ce que c'est bien, est-ce que c'est pas bien,
je ne sais pas, je pense que ça
dépend vraiment des entreprises.
L'inconvénience
est que notre weekly est à 16h30
et il finit toujours très tard, donc
pour des gens qui ont eu
l'habitude de travailler comme moi dans des entreprises
où on avait tendance à finir
vers 16-17h,
bah là on finit plus tard le vendredi.
Mais voilà, après
on a eu aussi une grande liberté
dans notre manière
de gérer nos horaires
et de comment nous organiser
dans notre semaine de travail.
Donc je trouve que c'est
un bon horaire.
C'est ce que j'allais dire en fait, si c'est l'horaire qui vous convient
c'est que c'est le bon horaire pour vous en fait.
Alors, je vais avancer dans
mes petites questions.
Est-ce que tu peux nous parler un peu de tes études,
quelle étude t'as fait
et aujourd'hui quelle étude
tu conseillerais à quelqu'un qui voudrait faire ton métier ?
Ouais. Alors
déjà ça dépend
de quelle partie du métier on va parler
puisque en étant
des Vops Full Stack, je fais beaucoup de choses
plus sérieusement.
Moi j'ai eu un parcours un petit peu
chaotique. J'étais pas très bon
à l'école, voire j'étais le cancre
de la classe. Donc
j'ai fait un BEP
en maintenance des systèmes mécaniques automatisés
parce que j'avais compris que je pouvais à quel système
et
faire une première d'adaptation pour réussir
à avoir un bac.
Et ça a été très intéressant de faire
ce BEP là.
Pour deux raisons, la première c'est que ça m'a
permis de faire un stage en entreprise
et j'ai essayé un travail à l'usine.
J'ai pas du tout aimé.
Et à la fois les horaires
et le travail en tant que tel
je me suis rendu compte que je serais très vite
bridé. J'ai rencontré
des gens vraiment superbes
mais dont
la grande majorité faisait ce travail là
pour le côté alimentaire.
Et moi j'ai besoin d'avoir un métier
passionnant
pour avoir du goût au travail.
Et c'est pas un jugement pour les autres
et au contraire c'est peut-être même mieux
pour eux parce que leur boulot est moins prenant.
Et mon deuxième stage
ça a été dans une petite boîte
d'informatique où je pensais que
je m'ennuierais un petit peu parce que
il dépannait des ordinateurs
c'était
avant les années 2000 donc
il n'y avait pas de réseau, il n'y avait pas de machin etc.
Et en fait ça a été
hyper enrichissant, je me suis éclaté
dans ce stage
et ça m'a permis de me rendre compte
qu'il fallait que je fasse de la formatique.
Mais ce BEP
là m'a aussi appris un truc
c'est que comme c'était de la maintenance
donc
hormis tout le côté mécanique
où je me suis amusé à souder des trucs
et à tourner des trucs
j'ai appris une méthodologie
pour maintenir en production
des chaînes
de production
donc vous imaginez
PSA ou je ne sais quelle industrie
où vous avez une chaîne qui tourne
en 24-7
et une heure d'interruption c'est une heure
de chômage technique pour tout le monde
donc il faut que ça tourne en 24-7
et finalement c'est quand même assez similaire
ce qu'on fait dans nos métiers
et dans ce BEP
là j'ai appris
à faire deux types de maintenance
la maintenance
préventive
donc c'était
en gros telle pièce elle va tomber
en panne au bout de temps de temps donc on va la remplacer
de manière préventive
pendant une plage de maintenance
où c'est
le changement de shift
et le chef en profite
pour faire une réunion avec tout le monde
donc la chaîne de production et arrêter de toute façon
pendant une heure donc on change
les joints et les boulons qui doivent être changés
pour éviter qu'ils pètent
trois mois après
et le deuxième truc c'est
des fois il y a des pannes
et comme c'est tout le monde
des au chômage technique il faut résoudre cette panne
le plus vite possible
et en fait on fait des arbres
de diagnostique
où on pose plusieurs hypothèses
on teste toutes les hypothèses
et puis on part
de l'hypothèse la plus probable et la plus facile
à vérifier puis on redescend
on en avait parlé dans un épisode de Radio DevOps
aussi
sur la gestion des crises
ou un truc comme ça
et en fait je me suis rendu compte
que avec le temps ça m'avait donné un avantage
sur certains de mes concurrents
qui avaient fait des écoles
d'informatique un petit peu plus traditionnelles
bon après je vais passer rapidement
parce que j'ai fait
un autre BOP
électro-technique
parce que je pouvais pas les directement d'informatique
j'ai fait un bac STI génie
électronique et j'ai fait
un BTS Informatique Industrielle
et en fait
le BTS Informatique
et le BTS Informatique
et finalement
le BTS Informatique Industrielle
je l'ai fait dans le lycée où j'ai fait le reste de mes études
et je l'ai pas choisi
parce que je voulais faire de l'informatique
industrielle
parce qu'à l'époque il y avait le début
de l'informatique de gestion
et j'aurais pu aller là-dedans
j'aurais peut-être appris des trucs un petit peu plus
en relation avec mon métier
mais je l'ai fait dans un lycée où il y avait énormément d'informatique
c'était le lycée du Futuroscope
et il y avait déjà des réseaux
tous les ordinateurs de l'établissement
il y avait quasiment un ordinateur
pour deux étudiants
et un accès internet
à l'époque déjà un petit peu limité
mais c'était mieux dans certains lycées
où on avait le droit
une demi-heure d'internet par semaine
par étudiant
et en fait
ça m'a permis de
m'améliorer
encore plus en
administration
et en développement système
parce que du coup j'ai appris
à développer pour du très bas niveau
parce que
j'ai louper les cours d'assemblure
je suis désolé monsieur je sais plus quoi
mais c'était une période où j'ai
séché beaucoup de cours
mais j'ai aussi commencé à faire du Linux
un petit peu avant de rentrer dans le lycée là
en bac mais j'ai continué à en faire
et il y avait
un des profs qui s'occupait de l'informatique
qui était fan de Linux
fan d'open source
et en fait je discutais régulièrement avec
et il a bien compris
que j'étais très intéressé
là dessus et il nous aidait
un petit peu à nous donner accès
à des trucs et c'était super sympa
et je pense que ça a été le début
de mon expérience professionnelle
parce que quand je suis arrivé dans le monde
dans l'entreprise je connaissais déjà
très bien les réseaux
je connaissais déjà très bien les systèmes
et du coup ça a été facile pour moi
de commencer à travailler dans ce domaine
c'était en quelle année sans indiscration justement
alors j'ai eu
mon BTS
en 2001 donc j'ai dû
rentrer dans le lycée en
96
96, 97
non peut-être un petit peu plus
enfin bon j'ai eu mon diplôme en 2001
donc j'ai commencé le
BTS en 99
donc 97 le lycée
donc entre
entre 97 et 2001
j'ai fait beaucoup de réseaux d'informatique
j'ai fait du montage
vidéo parce qu'il y avait
accès du matériel qui était
totalement inaccessible à l'époque
j'ai gravé des cd
avant tout le monde
enfin bon j'ai fait plein de trucs super sympas
bon le côté personnel c'est que du coup
j'ai eu ma fille
à la fin de ma première année de BTS
donc ça m'a mis un petit coup de pied
au cul pour
absolument avoir un diplôme
à la fin du BTS
et de voir
avoir un travail très rapidement
donc j'étais le seul de ma promo
avoir déjà un boulot en cdi
signé
et voilà
avant d'avoir le diplôme
et la boîte me prenait diplôme
ou pas diplôme alors après c'était
j'ai compris aussi
après que c'était super intéressant
pour eux parce que j'avais un niveau ingénieur
sans en avoir le diplôme
donc sans en avoir le salaire
mais je me suis rattrapé
les années d'après et voilà
et je regrette rien du tout
je te pose une question
parce que
comme tu parles du réseau dans ton école
ça m'étonnait parce que moi
autant il y avait
on va faire une petite digression sur les écoles
autant moi il y avait
les ordinateurs et ce genre de choses
mais il y avait pas encore les réseaux
partout dans les classes
nous on avait internet mais en fait
moi j'ai eu mon bts en 98
donc je suis rentré en 95
en bts
et je sais pas toi
mais nous on avait pas de linux
en cours, avec le recul
ça me choque, on avait en effet du dose
avant d'avoir du windows
il y avait du dose
on avait des systèmes unics
on avait aussi
des ataris je crois
pour faire de l'assemblure je sais plus exactement
mais on avait pas linux
et en cours par contre
nous les élèves on était beaucoup à avoir du linux
parce que comme on travaille sur des systèmes unics
c'est le seul moyen pour nous
de pouvoir chez nous
travailler sur des choses qui ressemblaient
est-ce que vous aviez des linux
justement dans vos écoles
oui
alors déjà comme je te le disais
il y avait un gros réseau
donc il était du L-stack
il était
IpxSpx
donc nouvelle pour ceux
à qui ça rappelle quelques souvenirs
donc moi j'avais entendu
parler de nouvelles en arrivant dans l'école
mais j'en avais jamais fait donc là j'en ai vu
j'ai vu différentes
formes d'éternet
il n'y avait pas de tokenering
à l'époque mais il y en avait
à la fac de poitiers
donc j'ai vu ça
en vrai aussi
donc c'est des réseaux
qu'on ne voit plus du tout
j'ai vu des câbles coaxiaux
de 100 Mb
j'ai connu
le réseau
coaxial
où il y a une prise qui déconne
et tout le réseau saute pour tout le monde
et en fait il y avait
aussi du TCP-IP
sur certaines parties du réseau
et en fait quand je parlais d'accès internet
il y avait un espèce
de passerelle je sais plus quoi
où en fait il fallait
en fonction de la login de mot de passe
on avait accès internet
et en fait il y avait un espèce
de tunnel IPX
vers cette passerelle là et après on pouvait
sortir sur internet
mais en fait il y avait toute une partie
du réseau
où l'administrateur
système dont je parlais tout à l'heure
le prof qui s'est enchargé
monsieur Biyo
je garde un souvenir ému
qui
qui géré
toute
une partie du réseau
de l'école avec ça
entièrement sous Linux
moi qui en avait déjà commencé
en faire le premier jour où je suis allé
parce que bien sûr je suis rentré en première
alors que je pensais être en première d'adaptation
c'était une première normale
donc je suis allé
sur le jour des secondes et en fait on m'a dit
mais non mais toi tu rentres demain
je suis allé me balader dans le lycée quand même
et je passe devant une salle et je vois
des pètes terminées en noir et blanc
je me suis dit oh putain du Linux
et je passe la tête et je vois le prof
donc monsieur Biyo et je lui fais
c'est du Linux tu connais ça toi
ah bah ouais j'en ai installé ça chez moi
dis donc c'est pas courant ça
et du coup on a commencé
à discuter
et bon bah ils nous donnaient
quelques droits par-ci par là
pour qu'on puisse en faire mais on faisait
partie de quelques privilégiés
et par contre en BTS
on avait toute une partie unique
qui justement était sous Linux
parce que ça coûtait moins cher à l'époque
et c'était déjà bien fonctionnel
et j'ai
fait mon stage dans une entreprise
qui faisait
du développement et de l'hébergement
de sites internet mais à l'époque
c'était sous
2 IS, endothmete etc
et mon sujet de stage c'était
transformer l'entreprise
pour les aider à migrer sous Linux
donc mon stage
ça a été trouver des solutions
pour qu'eux puissent installer facilement
des nouveaux serveurs
qui aient des interfaces d'administration
facile pour qu'ils puissent
créer des nouveaux sites internet
les virtualhosts etc
créer les utilisateurs pour faire du FTP
facilement et ainsi de suite
et en fait ce stage là
a tellement bien marché que ça s'est transformé
en projet de fin d'année
où on a été une petite équipe
à travailler là dessus avec
mon entreprise de l'époque
donc on a bouffé encore un petit peu plus
de Linux l'année d'après et ça c'était cool
c'est bien que tu rappelles ça
parce qu'on entend ça l'oublier
aujourd'hui en 2023 mais à l'époque
dans les années 90, début des années 2000
Linux c'était
encore assez jeune puisque ça faisait moins
de 10 ans que ça avait été créé
à peu près 10 ans
et Linux ça coûtait vraiment très cher
puisqu'on avait des gros serveurs Linux
vraiment puissants pour l'époque évidemment
ils sont moins puissants que nos smartphones
mais ils étaient puissants pour l'époque
et les licences uniques coûtaient très très cher
parce que c'était du matériel
à destination des professionnels
l'open source et logiciel libre
nous a aidés à sortir de ça
merci parce que je pense que
sinon aujourd'hui on n'aurait pas internet
honnêtement je pense que
internet serait pas là
si on n'avait pas eu l'open source
pour nous aider et pour
pouvoir justement
comment dire
répondre
toutes ces systèmes
d'exploitation un peu partout
parce que si on était restés sur du système d'exploitation
unix, à mon avis aujourd'hui
on aurait les systèmes
comme on dirait
d'exploitation
je sais pas c'est entendu
ce que j'ai dit sur unix et linux
qui grâce à linux
je pense qu'aujourd'hui on a internet
sinon on serait pas aussi avancés technologiquement
à mon avis
je pense qu'on aurait internet
mais je pense qu'on n'aurait pas
un accès aussi facile
à tout ce qui est unix pour
des personnes lambda
j'avais essayé de convertir
mes parents à linux mais j'ai abandonné
ma mère a encore un windows
dans une version
qui me donne des cauchemars
dont elle veut pas faire la mise à jour
mais
oui après
moi ça...
je pense néanmoins
que le coût des licences unix
enfin le fait que linux
soit gratuit à implémenter
et tout l'open source qui a
suivi
pour moi ça a été un accélérateur d'internet
parce que sans ça je pense que internet
ressemblera pas à ce qu'il est aujourd'hui
et on aura probablement pas internet dans nos poches
c'est ça que...
parce que ça aura coûté tellement cher aux boîtes
que ce serait réservé à une élite
et pas à monsieur tout le monde
j'en suis pas totalement certain
parce que mon premier boulot
ça a été faire de l'outline
pour un opérateur internet
dans les années 2000
un des seuls en France
qui vous offrait des heures gratuites
donc tout ceux qui sont assez vieux
voient encore de quoi je parle
mes enfants connaissent le nom
parce que j'ai eu des poches cd pour ranger mes cd
pendant des années
mais
plus sérieusement
en fait cet opérateur
il y avait linux mais clairement il y avait
zéro linux
à l'époque c'est linux c'était pour les bricolos
dans leur garage
et pendant très longtemps
dans mon boulot
on a pris pour le petit bidouilleur
là de toute façon il fait des trucs
sous linux c'est un bidouilleur
et c'est une image
qui m'a suivi pendant longtemps
je pense que ça m'a suivi pendant
6, 7 premières années de boulot
parce que tout le monde était
sous solaris
on avait des stations sun ou boulot
en plus j'étais le seul de l'open space
ça n'a pas avoir une station sun et puis je leur ai dit
c'est pas grave, donnez moi un voie de pc windows pourrie
je garde mon pc portable de mon ancienne mission
au sein du même client
donc ça a été totalement
c'est passé totalement inaperçu
et j'étais le seul
pendant
je pense 5 ans
à avoir une station sous linux
dans le réseau d'admin
alors que tous les autres étaient sous solaris
donc moi j'avais accès à tous les outils que nous
donc tout marchait un petit peu mieux
que les trucs
sous solaris
donc je pense pas que ça ait changé
quelque chose sur le fait que tout le monde
ait accès
internet
et
en fait je pense que
je pense que les coufs
en fait
je vais approfondir ma pensée
mais en fait tu revives quelque chose chez moi
je pense que les coufs de support
de tous les services qu'on utilise
aujourd'hui, si ça tournait sur de linux
ce serait tellement élevé qu'en fait
il n'y aura pas toutes ces boîtes là
il n'y aura pas tous ces cycles là
et internet n'aura pas percé aussi vite
par contre c'est marrant ce que tu dis
parce que je l'avais oublié
j'avais oublié qu'à l'époque en effet
linux était vu comme un truc de bidouilleur
et un truc de nerd
alors que unix était un truc de pro
vous voyez c'est un peu comme
je ne sais pas d'équivalent aujourd'hui
mais vraiment ça
et pourtant c'est vrai que c'était là
à l'époque
c'est comme si aujourd'hui tu dis
que ton
idéo c'est un télégie
c'est un truc pour les professionnels
et puis toi t'es un bidouilleur
t'es sous vim, t'es sous
notepad plus plus ou je ne sais pas quoi d'autre
je caricature un petit peu
mais pour que les plus jeunes comprennent un petit peu
oui plus notepad plus plus
que vim parce que vim c'est
un vrai idéo ou tu peux faire des choses
enfin c'est pas un idéo c'est un éditeur
de code
ouais mais du coup
c'est un truc pour les nerds
qui en veulent
parce que c'est pas
clé en main machin etc
et linux c'était comme ça à l'époque
c'était pas un truc clé en main
on en chiait
pour avoir un linux
il fallait le mériter
je me souviens
et moi j'ai commencé sous linux
la machine que j'avais
il n'y avait pas la possibilité
de ma carte graphique
n'avait pas assez de mémoire donc j'ai eu
du terminal en noir et blanc pendant
trois ans donc je peux vous dire
que linux est by the hard way
quoi
en fait je pense
que c'est plus ça a démocratisé
la possibilité d'avoir
des unics pour des gens
comme nous qui avaient envie de bidouiller des trucs
et quand j'ai commencé
à travailler
j'étais celui qui avait le plus d'expérience
sous unics
quasiment de l'open space en termes de nombre d'années
parce que je faisais du linux
depuis 95
alors que les autres de l'open space
peut-être qu'ils ont commencé
en 95 aussi
mais ils ont commencé à la fac
et comme c'était à la fac ils n'y avaient pas
que c'est en permanence moi ça faisait déjà
quelques années que j'avais un serveur linux
qui tournait chez moi quasiment 24h sur 24
c'était ma passerai l'internet
qui lançait le modem
et puis qui partageait le réseau en interne
dans mon réseau
énorme de 3 machines
mais
je me suis fait les mains avec ça
j'ai fait du routage
sous linux, sous windows ou machin
j'ai fait des plans d'adressage
ce qui fait que quelques années après quand il a fallu que je
découpe un subnet
en
je sais plus en une cinquantaine de sous réseaux
bon je me suis arraché les cheveux pendant une semaine
mais c'était beaucoup plus
abordable pour moi parce que
je me suis imprégné de ça très rapidement
et je pense
qu'aujourd'hui les gens le font
peut-être plus de la même manière
et
je sais pas
si on peut avoir des équivalents
aujourd'hui
mais oui clairement
ça a changé les choses sur la manière
dont on pouvait apprendre les choses
mais c'est plus tout le monde
de l'open source en général qui a changé
l'informatique
c'est certain
tu me fais une transition parfaite pour
ma dernière question
après j'ai quelques questions de clôture
quel conseil aujourd'hui tu donnerais
à quelqu'un qui démarre
à novice on sait tous les deux très bien
qu'un novice ne pourra pas devenir un DevOps full stack
comme tu l'as décrit en claquant des doigts
très vite mais quel conseil tu lui donnerais
pour pouvoir un jour faire ce métier
je connais plus trop
les études qu'il y a aujourd'hui
mais je dirais
qu'il faut se renseigner sur des écoles
qui permettent de faire de l'administration
système
de faire un petit peu de développement
parce que pour moi ça devient
incontournable
d'être dans une école qui a des partenariats
avec
des boîtes qui font du cloud
et pas que de la WS
parce que si vous apprenez à faire de la WS
vous saurez faire que de la WS
regarder
à ce qu'il y ait aussi d'autres choses
et notamment de la WS
ça c'est peut-être une alternative
la comparaison qu'on avait tout à l'heure
c'est fait de l'OVH qu'entraînement
à de la WS
c'est l'unix propriétaire
et de Linux
aujourd'hui le Linux c'est plutôt VH
parce qu'il y a moins de fonctionnalité
et si vous mentez une infrance
sur de l'OVH
peut-être que vous ne méritez un petit peu plus
votre casquette d'expert
parce que de la WS
je ne dis pas qu'à WS c'est simple
c'est hyper complet
donc hyper complexe
mais vous avez beaucoup de cookbook
que vous trouvez sur internet
et il y a beaucoup de produits en 3 clics
qui s'est déployé
chez OVH c'est peut-être plus compliqué
il faut peut-être plus aller dans les détails
ainsi de suite
et au-delà de l'école
c'est
trouver des petits projets
sur lesquels vous allez pouvoir déployer
des trucs, déployer des infras
et faites-vous la main
sur des infras
moi, un des
stagiaires les plus péchus que j'ai eu
donc Brenda, si tu nous écoutes
maintenant il est développeur backend
mais à l'époque il connaissait bien l'infra
il avait un projet
donc il était président
d'une association où je faisais de la musique en ligne
je sais plus exactement
mais il avait monté une infra
qui permettait de diffuser des concerts en live
et quand je discutais avec lui
il savait de quoi il parlait
parce qu'il avait déployé
une infrastructure complète
il avait mis un petit peu de load balancing
il avait
plusieurs serveurs, il avait son réseau
tout le monde se parlait, il avait des security groupes etc
donc il avait déjà fait pas mal de choses
essayez de vous trouver un petit projet
sur lequel vous pouvez contribuer
pour déployer des choses
pour faire des choses
et si vous pouvez pas l'avoir chez vous
enfin en ligne
sur une infra un petit peu plus complète
essayez de monter
un petit lab
sur votre pc
sur un pc que vous allez récupérer
et transformer en hypervisor
montez-vous un lab
et expérimentez des trucs
et si c'est
entre guillemets c'est encore mieux
je parlais de mon serveur
que j'avais chez moi depuis des années
il s'est transformé au fil des années
et aujourd'hui
il existe toujours mais sous une autre forme
maintenant c'est un serveur qui est chez OVH
qui
gère mon DNS, ma messagerie
mon site internet et ainsi de suite
et je l'ai fait évoluer
il a été sur internet
il est revenu chez moi, il est retourné sur internet
et
comme ça
ça va vous apprendre à migrer
ça va vous apprendre à gérer plein de choses
je ne vous dis pas de vous auto-héberger l'émail
parce qu'aujourd'hui c'est devenu une plaie pas possible
moi je le fais parce que
j'ai une expertise là dedans
ça fait 25 ans que j'éberge mes mails
je crois j'en ai chier
aujourd'hui
c'est vraiment compliqué parce qu'il y a plein de trucs
pour que ça ne parte pas dans l'espame
d'EKIM, SPF etc
mais si ça vous intéresse
mettez le nez là dedans, vous allez prendre énormément de trucs
mais
le fait d'avoir
les doigts dans le cambouill
ça va vous
permettre de voir tout ce qui vous manque
à apprendre
par exemple, il y en a beaucoup de gens qui ne maîtrise pas le DNS
en fait c'est un truc tout bête
c'est une fois qu'on a compris comment ça marche
c'est génial
un autre protocole
à bien connaître c'est
ESSH
pour moi
on devrait
avoir des cours entiers de ESSH
et quand je parle de ESSH c'est y compris
toute la partie crypto, les clés privées
clés publiques
les chiffrements symétriques asymétriques
quand je vois le nombre de personnes
qui ne maîtrise pas ces aspects là
ça m'inquiète quand même sérieusement
je vais réagir
à ce que tu dis parce que c'est super intéressant
super important parce que mon premier alternant
ils aient des études en effet
techniciens, systèmes et réseaux
et en fait j'ai dû lui apprendre
l'ESSH comment ça marchait parce qu'il comprenait pas
et pourtant c'est essentiel
aujourd'hui on utilise tous
un server Git, GitLab
Framagit etc
et pour pousser
on utilise Git qui passe par le ESSH
entre autres et l'ESSH
ça sert aussi à des plagues des applications etc
l'ESSH est partout et c'est vraiment important
de le connaître et surtout quand ça marche pas
au moins quand on connaît ESSH
on peut essayer de trouver
les problèmes parce qu'il peut y avoir
beaucoup de problèmes
juste c'était la seule insiste que je voulais faire
je te laisse continuer
et puis je dirais même que c'est
le couteau suisse
de l'administrateur, système et réseau
parce que c'est ce qui va vous permettre
de vous affranchir de certaines règles
de sécurité
de firewall etc
parce que si votre infrastructure
est bien protégée vous avez pas
un accès direct à vos serveurs d'application
à vos bases de données etc
et quand votre application elle marche pas
il faut que vous sachiez
d'où vient le problème
et si vous êtes capable de vous mettre
à différents points pour tester
si de votre machine vous pouvez accéder
en direct à la base de données pour faire vos requêtes
SQL avec vos outils favoris
parce que des fois c'est bien d'avoir
des outils qui font du management visuel
moi je...
là récemment j'ai investi dans la suite
d'intelligie
donc j'ai data grip
j'ai un petit truc qui permet de
visualiser mes bases de données
de faire mes schémas de bases de données
en automatique
quand on n'a pas le temps d'aller tout fouiller
c'est bien d'avoir une vue
très rapide de l'existence
et ça ça serait totalement impossible
si je maîtrisais pas et c'est sache
parce qu'en fait mes bases de données ne sont pas
accessibles directement sur internet
d'ailleurs si vous faites ça
c'est une très mauvaise idée
j'ai gagné un client comme ça il s'en fait
cryptolotier leur MySQL
donc mettez vos bases de données derrière
des firewalls
et un autre outil
juste attend je précise parce que tu l'as pas dit
et que tout le monde n'est pas au courant mais c'est parce que tu utilises
un tunnel SSH et que tu passes
au travers de l'SSH pour accéder
aux autres machines de ton réseau
voilà par exemple et le fait
de maîtriser aussi les
différentes choses que l'on peut faire avec
vous pouvez avoir des bastions SSH qui vous permettent
de rebondir sur d'autres machines
enfin SSH c'est super puissant
on vous demande pas de tout maîtriser
surtout si vous êtes développeur
vous n'avez pas besoin de tout connaître
mais avoir un minimum
de savoir se connecter sur un serveur
de savoir utiliser une machine de rebond
utiliser un agent SSH
parce que
ça c'est peut-être le plus important dans SSH
c'est savoir utiliser un agent
parce que votre clé SSH ne doit pas être
pas de passe-phrase
je vais vous taper sur les doigts
et si vous tapez votre mot
passe de clé à chaque fois que vous en avez besoin
1 vous allez en avoir marre
et 2 c'est un trou de sécurité
parce que plus vous le tapez
plus on vous verra le taper
et plus on pourra le deviner
donc un agent SSH
c'est vraiment
super bien et pour moi
c'est la base
et il y a un autre outil aussi
à maîtriser
alors je veux pas
rentrer dans la guerre VIM
IMAX, machin etc
mais viaille et installé sur
toutes les machines et si vous savez
vous en servir vous allez pouvoir
manipuler des fichiers plus facilement
plus rapidement
et pour moi c'est super important
bon je vais me permettre de faire
mon petit appel à l'action
si tu fais partie d'une école
si en fait
tu gères une école
qui a des programmes d'administration
système ou administration cloud
moi ça m'intéresse de parler avec toi
de t'interroger, de te faire passer sur le podcast
pour que tu parles justement
de tes programmes
et pourquoi on en discute
parce que c'est vrai que c'est assez rare
de parler des programmes d'école
dans les médias
je trouve en tout cas des écoles
qui font de l'ops
donc administration système
administration cloud ou des voips
tu peux me contacter sur Twitter ou sur LinkedIn
c'est très facile, tu cherches Christophe Chaudier
dans l'un ou l'autre des réseaux
ou même tu peux taper dans ton temps
dans le cherche préféré Christophe Chaudier
tu devrais pas avoir de mal à me trouver
sinon il y a le forum des compagnons
il y a plein de moyens de me contacter
alors je ne sais pas Nicolas
si tu es de nouveau avec nous
oui désolé, j'arrête pas
d'être appelé en ce moment
c'est le seul moment de la semaine
rassure-toi, on a terminé
où est-ce qu'on peut te retrouver
si on veut discuter avec toi
à part évidemment sur le forum
des compagnons dont je parlais
donc effectivement sur le forum
vous pouvez me contacter
vous pouvez me retrouver sur beaucoup de réseaux sociaux
sous le pseudo nledez
donc j'ai un pseudo
extrêmement public
et si vous
vous souvenez pas
vous pouvez aller sur Nicolas.ledez.net
le.dez.net
vous aurez
mes réseaux sociaux
mon github, mon twitter
mon mastodon et puis mon blog
et de toute façon
sinon sur le forum
je le dis assez régulièrement
pas forcément tous les jours
mais en général toutes les semaines
si vous me pingez là dessus j'y répondrai
et bah merci à toi
pour ton temps et pour cette
longue interview
et je te dis à très bientôt
puisqu'on se voit régulièrement sur les podcasts
merci Christophe
et à bientôt pour les autres
Sous-titres par Sous-titres par Sous-titres par Sous-titres par Sous-titres par Sous-titres par Sous-titres par Sous-titres par Sous-titres par Sous-titres par Sous-titres par Sous-titres par Sous-titres par Sous-titres par Sous-titres par Sous-titres par Sous-titres par Sous-titres par Sous-titres par Sous-titres par Sous-titres par Sous-titres par Sous-titres par Sous-titres par Sous-titres par Sous-titres par Sous-titres par Sous-titres par Sous-titres par Sous-titres par Sous-titres par Sous-titres par Sous-titres par Sous-titres par Sous-titres par Sous-titres par Sous-titres