Alors, tous les jeunes veulent travailler dans la tech et rêvent d'être développeurs.
C'est pas étonnant parce que c'est le métier le plus représenté dans les médias et la
culture populaire.
Pourtant, il y a des tas d'autres métiers dans le numérique.
Et pour fêter le lancement justement de MW My Little Team, j'ai décidé de faire
une série d'interviews et d'entrevues avec des personnes pour parler des métiers de
la production, de l'exploitation ou de l'infrastructure.
Mais on reparlera de MW à la fin de la vidéo.
Donc, elle te vient jusqu'à la fin si tu cherches un taf.
Aujourd'hui, je suis avec Axel Desmontoux et ensemble, on va parler de son rôle en
fait d'administrateur Claude.
Et aussi, on va voir comment le DevOps et le cloud ont un impact sur les métiers de
la prod.
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'un dans la partie
l'émission je m'entretiens avec un invité sur un sujet particulier.
Alors 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.
On n'est déjà plus de mille à échanger, à partager et à s'entraider tous les jours.
Donc, ne reste plus seul face à tes questions et rejoins-nous.
C'est le premier lien en description pour t'inscrire.
Ou alors tu vas sur le site compagnons-devops.fr et tu seras pris en main et tu pourras t'inscrire.
Alors bonjour Axel, merci d'avoir répondu à mon appel à témoignage.
Est-ce que tu peux justement te présenter en quelques mots et nous dire ce que tu fais
dans la vie s'il te plaît ?
D'accord plus stuff.
Alors moi je suis Axel de Montau.
Je travaille dans l'IT plus précisément dans les métiers de l'infrastructure depuis
maintenant 6 ans et je suis actuellement consultant indépendant sur des métiers de
l'infrastructure.
Donc aujourd'hui je suis ce qu'on pourrait appeler un consultant DevOps et on en débattra.
Exactement.
Alors je vais te poser les questions traditionnelles que je pose dans ma partie.
La première c'est quelle est ta définition à toi du DevOps ?
Ma définition, j'ai rien préparé.
Donc là ça va être du live.
Pour moi c'est une culture, une organisation et des outils qui permettent de délivrer des
logiciels, des applications avec plus de fiabilité et de rapidité.
Parce que souvent on parle de rapidité quand on développe le DevOps.
Mais pour ma part, j'ai souvent vu la rapidité être privilégiée à la fiabilité alors
que je pense que c'est surtout la fiabilité qui a de l'intérêt dans tout ce processus
et dans tous ces outils.
Je suis assez d'accord avec toi là dessus.
Justement comment est-ce que toi tu as rencontré le DevOps ?
Et surtout est-ce que ça a changé quelque chose dans ta vie parce que je vois que tu
es plus jeune que moi.
Donc je sais pas si tu as rencontré ça au tout début de ta carrière ou si tu avais
déjà une première partie de la carrière quand tu as rencontré le DevOps ?
Alors c'est une bonne question.
La première expérience professionnelle à évoquer, c'était mon alternance de BAT
plus 3 en licence et donc j'avais un job d'ingénieur système Linux.
Je travaillais sur de la virtualisation et sur des projet si elle a déployé.
Et en fait à ce moment-là, ce que j'avais comme job c'était d'automatiser le déploiement
de ces livraisons parce que je crois même que c'était moi qui m'était donné ce job
là parce qu'on le faisait toutes les semaines.
On réinstallait la même appli avec des tonnes de copie et coller, des tonnes de changement
de droit par ci par là.
Et moi j'avais dit à l'époque je vais faire un script qui automatise le déploiement.
Et donc on était dans un système un peu artisanal, c'est-à-dire avec le data center dans la
pièce d'à côté avec 40 serveurs.
Et moi à ce moment-là, c'est là où j'ai commencé à m'intéresser à tout ce qui
était DevOps.
C'était déjà à l'époque, on commençait à l'avoir en buzzword DevOps.
Et donc ce que j'avais fait, c'est que j'avais fait un espèce de rapport visant à intégrer
des technologies DevOps, des technologies Cloud pour le data center.
L'idée c'était d'en faire une espèce de cloud interne avec un open shift, un Kubernetes
et des cloud interne.
Ce rapport-là, il a dû terminer sur une table et il n'a jamais dû être réouvert.
Et moi j'ai changé d'alternance parce que je m'intéressais à tout ce qui était
applicatif et là j'étais quand même dans l'interrence très système.
Et là je suis tombé justement sur un poste qui était à l'époque dit ingénieur de
production.
Et j'ai tombé en pile poil dans la mouvance DevOps.
C'est-à-dire que je suis arrivé chez un client qui avait déjà acheté tous les outils
et qui était dans la mise en place de DevOps au sein des Equip IT.
Et moi je me suis positionné très vite sur ces sujets-là, c'est-à-dire que j'étais
dans une équipe qui se créait.
On était tous nouveaux, j'étais interne moi alternant mais à côté de ça j'avais
eu des consultants autour de moi et donc il fallait que tout le monde trouve sa place
assez vite et moi j'ai très vite trouvé ma place sur la partie DevOps, à savoir
bon moi c'était Jenkins, Excel, Deploy, des choses comme ça.
Et voilà donc du coup très vite j'ai eu une spécialisation autour de moi, autour
de ça, ça m'a permis de bouger en interne et d'aller sur des postes où justement
cette spécialisation elle avait de l'intérêt.
Et à partir de là je me suis rendu compte que ma spécialisation pouvait écarcer en
freelance, c'est comme ça que j'ai changé de carrière entre l'hiver.
On va parler de ton côté freelance juste après.
Ça m'étonne pas que justement tu te sois intéressé vraiment à ça en étant ingénieur
de prod.
Moi je l'ai été, alors moi je n'avais pas le titre ingénieur de prod mais on faisait
de l'exploitation des logiciels.
Souvent ce terme là il est là pour dire qu'on a un métier, on exploite les applications,
on les installe et puis on s'assure qu'elle tourne bien.
Tu confirmes ça ?
Oui c'est ça, c'est ça.
Concrètement c'était ça le métier et enfin peut-être que je te coupe l'herbe
sous le pied là.
Ce que j'allais dire c'était ça le métier et puis à partir du moment où on a intégré
quelques outils DevOps, le métier est devenu un génére d'Evops.
Les nouvelles ordres d'emploi s'appelaient comme ça après.
Oui voilà c'est un peu là où je voulais en dire, c'est qu'en fait ce métier là
il est là dans les grosses structures, il n'existe pas dans les petites startups
ou les petites PMOs, c'est vraiment les grosses structures.
Moi j'ai fait ce métier là chez Casino, monoprix, enfin les grosses boîtes où il y a plusieurs
centaines de personnes à l'IT.
Et en fait c'est entre le développeur et l'ingénieur système, l'ingénieur stockage, etc.
Tant tu t'assures qu'au fait tout tourne bien en production sur des infrastructures
contre fournies et avec des applications contre fournies.
C'est ça.
Et c'est vrai que pour moi souvent ce qui n'est pas forcément le cas mais souvent
le terme d'ingénieur DevOps, en fait c'est le nouveau nom de l'ingénieur de production.
Alors qu'en fait le DevOps il ne s'arrête pas juste à ce métier là, on va justement
en parler.
Donc aujourd'hui tu te définis comme amministrateur cloud consultant de DevOps, finalement c'est
quoi ton quotidien et c'est quoi les tâches récurrentes que tu fais dans ce métier ?
Les tâches récurrentes, alors je dirais maintenant en condition opérationnelle les
applications et les systèmes, ça dépend du client mais quand on est beaucoup moins
en part on s'occupe aussi de la partie système quand on est sur des gros clients en général
c'est dissocié.
Mais voilà j'ai envie de dire en condition opérationnelle des applications et des systèmes,
développement de l'automatisation visant à déployer ces applications et développement
des moyens visant à déployer les infrastructures qui font de l'infrascode.
Je pense que j'ai donné les grandes lignes.
Est-ce que tu fais aussi de la gestion d'incidents du retour aux équipes de développement des
problèmes que vous trouvez en production aussi ?
Oui c'est ça j'ai envie de dire du support, je ne sais pas si ça fait partie de ça,
mais de support au développement.
Un traitement qui est censé tourner à 20h et qui se passe mal, c'est moi qui vais
faire le retour au développeur si la cause n'est pas directement liée aux infras.
Je vais travailler avec eux sur la remédiation et leur donner peut-être des pistes.
Ça marche.
Quand tu m'as contacté, c'est vrai qu'on en parlait en introduction, tu me disais que
tu voulais parler du consultant DevOps.
Moi je t'ai dit que ça m'a gêné un peu, t'as compris pourquoi ?
Ça me gênait un peu ce métier parce que je fais partie des gens qui pensent que DevOps
n'est pas un métier déjà, que c'est le plus un mouvement.
Et du coup on est un peu tombés d'accord tous les deux, c'est même toi qui l'a proposé
sur Admin Cloud.
Mais du coup pour toi, consultant DevOps, pourquoi c'est ça qui t'est venu en premier
en tête ?
C'est une question de SEO, de SEO job.
Quand on est en recherche d'une mission, ce qu'on va nous proposer, c'est que j'ai
un job aujourd'hui de DevOps à AWS.
J'ai un job de DevOps Azure.
J'ai même eu ça aussi, j'ai un job de DevOps Monitoring.
C'était au final un consultant qui va travailler sur la stack de monitoring qui n'existait
pas, quoi qu'il fallait mettre en place.
Donc là où je voulais en venir, c'est que pour être ciblé, c'est beaucoup plus facile
en portant cette casquette consultant DevOps.
Mais en soi, d'un job à l'autre, c'est totalement différent.
Il n'y a vraiment pas de règles.
Il y a des jobs où on va beaucoup plus être dans le build, d'autres un peu plus dans
le run.
Des jobs où on va être un peu plus sur des intraclabs, d'autres un peu plus sur des
intras en prime.
Il n'y a vraiment pas de règles.
Mais si ce nom de job, moi j'ai choisi de le mettre en profil, c'est pour être assez
générique et ouvrir la porte à toute demande, concrètement.
Aujourd'hui, je pense qu'on a beaucoup, beaucoup de techno et c'est difficile parce que nos
travail en tant qu'ingénieur de production, il est lié à beaucoup de techno.
J'imagine la difficulté à trouver un nom de poste pour chaque mission, je pense que
c'est pas évident.
Moi, ça m'arrange d'avoir quelque chose d'assez générique que tout le monde comprend.
C'est là où je voulais justement venir le SEO.
Moi, j'ai tendance à considérer DevOps comme un adjectif que je colle au titre du job,
comme administrateur système DevOps, administrateur réseau DevOps, DBA DevOps, ou autre parce
que ça montre la manière dont on fait le job.
C'est mon envie.
D'ailleurs, j'ai sorti un épisode de podcast.
Alors au moment où on enregistre celui-ci, il est sorti il y a deux semaines qui s'appelle
l'administrateur système DevOps et justement, on parle de ça.
Je ne sais pas si toi tu l'as écouté, comment tu l'as senti ?
Je ne sais pas si tu l'as écouté, mais je te suis dans la démarche parce qu'il fut
un temps, une de mes premières expériences principales, j'avais nommé ingénieur de production
DevOps.
C'était comme ça qu'il avait nommé.
À terme, ce qui s'est passé, c'est que les postes dans le Beauche, ils les ont renommés
ingénieurs DevOps.
Alors je me suis senti légitime de renommer mon poste ingénieur DevOps.
En soi, ce que tu sois comme non, je suis plutôt d'accord avec toi.
J'en parlais justement avec D'Iran aussi dans un autre épisode de podcast et le souci
d'avoir ce terme-là ingénieur DevOps, il devient tellement générique comme tu le
dis, que quand on regarde les oeuvres d'emploi, il y a tout et c'est son contraire.
Et du coup, même quand on se prétend être ingénieur DevOps, on ne sait plus vers quoi
aller.
Alors qu'à l'époque où il y avait encore, je vais cacher les recruteurs, administrateurs
systèmes, DBA, etc., tu pouvais au moins faire un premier tri.
Là, ça devient plus compliqué.
Et j'ai un peu l'impression qu'on va aller vers ce phénomène qu'on voit chez les
développeurs, le développeur full stack, tu sais, le développeur qui est censé tout
faire.
On va aller vers un poste d'Obs qui sait tout faire.
Et moi, ça m'agène un petit peu parce qu'en plus, c'est hyper complexe toutes les
technos comme tu l'as dit.
C'est clair.
C'est hyper complexe.
Et en fait, je ne sais pas à quoi, qui ou à quoi on doit la faute.
Mais j'ai l'impression qu'on a mis beaucoup d'automatisation.
Et par le fait qu'on automatise, on estime que tout est faisable facilement.
Mais par exemple, typiquement en termes de système, il y a des notions assez pointues,
c'est quand même une réelle spécialisation.
Mais comme sous prétexte qu'on peut en déployer avec un template maintenant et que c'est beaucoup
plus simple, eh bien, je ne sais pas si c'est quoi, vraiment le souhait, c'est de supprimer
la spécialisation système par exemple.
Pour moi, ça reste quand même une grosse spécialisation et quelqu'un qui est spécialisé
côté système et qui est dénommé DevOps et quelqu'un qui est spécialisé côté paplane
CICD et qui est dénommé DevOps, ce n'est pas le même métier.
Ah non, clairement.
Et puis même si l'un peut évoluer vers l'autre, puisque c'est ce que j'ai fait, ce n'est
pas le même métier.
Il y a un truc aussi, comme tu dis à l'automatisation, mais pour moi, en fait, on ne peut automatiser
que quelque chose qu'on comprend et qu'on arrive à faire manuellement.
Et l'automatisation facile, pour moi, c'est un alerte, notamment tous les gens qui vont
se faire couberner, si tu ne comprends pas ce qu'il y a derrière, si tu ne comprends
pas les conteneurs, les réseaux, le déploiement et tout ce qui se passe, tu vas à un moment
donné, dès qu'il y a un problème, buter et tu ne comprendras pas pourquoi.
Et tant que ça va bien, ça va, mais le moment où tu butes, je ne sais pas ce que tu en
penses de ça, tu seras pris au dépourvu et tu ne pourras plus rien régler.
Oui, je suis plutôt d'accord avec toi.
Après, ça dépend si tu veux t'occuper de la stack qui est en dessous.
C'est-à-dire que tu as des offres Kubernetes manager.
Alors, c'est bon et c'est mauvais côté, mais c'est clair que si tu prends la stack
Kubernetes manager et que tu veux développer des pipelines dessus, les notions quand même
sous-jacentes de système, elles sont quand même très cachées.
Alors, ça n'empêche qu'il en faut quand même des notions, mais est-ce qu'il est
nécessaire d'être très, très pointu, je ne sais pas.
Bah, vu que tu es dans un contexte microservice, à un moment donné, si tu as un problème,
il va falloir identifier l'origine du problème.
Donc, si c'est ton service hack, il y a un souci, mais si tu n'es pas capable d'aller
voir les logs ou de les trouver, tu vois.
Oui, oui, oui, oui, oui.
Bien sûr, bien sûr.
Si on parle de ce, oui, de ce niveau-là, c'est vrai.
Je ne parle pas de la couche base de Kubernetes.
Je parle vraiment de la couche applicative.
Ce n'est pas la même chose de déployer une application dans Kubernetes que de la déployer
sous un cloud, qui n'est pas encore la même chose que de la déployer sur du on-premise.
Et si tu ne comprends pas ces choses-là, même si tu automatises, tu vas avoir des soucis,
pas je poursuis.
Voilà.
Du coup, toi, tu nous as parlé un petit peu de tes études, mais finalement, tu as fait
quoi comme étude au final et selon toi, quelles autres études les personnes qui voudraient
faire ce métier auraient besoin ?
Moi, j'ai fait des études assez spécialisées.
C'est-à-dire que j'ai commencé par un DUT réseau et télécommunications.
Dans ce DUT-là, au début, j'étais assez accès à réseau et suite à mon stage de fin d'études
où il s'agissait d'installer un stack de monitories.
J'ai plutôt aimé.
Je me suis dit, bon, je vais installer Linux chez moi, etc.
Et à partir de là, du coup, au lieu de partir en école d'ingénieur, j'ai choisi une licence
pro qui était assez accès à ce système.
Et donc ça m'a bien plu.
Et puis j'ai enchaîné derrière avec un Master Pro.
Alors ce n'est pas un Master Pro, c'est un Master en école d'informatique.
Par l'école d'ingénieur, en école informatique.
Et donc voilà.
C'est comme ça que j'ai eu un Bac Plus 5.
Et assez spécialisé.
J'ai fait des études en soi où à partir de ma licence, j'ai fait beaucoup plus de pratique que théorie.
Beaucoup de projets à faire.
Et moi, mon conseil en termes d'études, c'est là où on en était.
Je sens que c'est conseiller, c'est ça.
Bon, je me lance dans mes conseils, ils sont peut-être bancals.
Je pense que c'est rien.
Mais moi, mon conseil principal, c'est d'aller vers des études le plus pratiques possible,
de commencer en alternance le plus rapide possible, plus rapidement possible.
Je pense que c'est un conseil qui n'y a rien d'extraordinaire, qui est connu.
Pourquoi ? Parce que j'ai eu l'impression de réellement apprendre le métier
qu'à partir du moment où j'étais en alternance sur des études qui étaient assez pratiques.
Avant, je donnais un exemple tout bête.
Avant, quand j'étais en dévité, je devais faire du code, typiquement du Bache, Java.
Ça me semblait tellement dur, tellement insurmontable.
Quand je suis arrivé en entreprise et qu'il fallait le faire, je l'ai fait.
Pourquoi ? Parce que tout de suite, c'est concret.
On te dit, tu dois faire 6 pour 6 pour ça.
C'est plus calculer le nombre de sacs Chanel que Tata Huguet a acheté.
Là, ça devient concret, il faut le faire.
Et puis, si on ne le fait pas, il y a un problème.
Donc on le fait.
Moi, personnellement, en tout cas, chacun sa manière d'apprendre,
moi, personnellement, j'ai un peu besoin d'être dans un cas concret, d'avoir une raison de faire les choses
pour surmonter un peu certaines difficultés.
Et voilà, chacun sa manière d'apprendre.
Moi, mon conseil, je pense qu'il est assez subjectif.
Je suis assez d'accord avec toi.
Nous n'avons que des alternants aussi en système.
Et je donne moi-même des cours dans deux écoles.
Une qui ne fait pas d'alternance et une qui en a alternance.
Je vois un petit peu la différence entre les étudiants.
Dans l'école généraliste, je donne des ingénieurs systèmes et réseaux.
Mais c'est plutôt des ingénieurs généralistes informatiques.
Et souvent, quand je vais reposer la question, ils ne savent même pas ce que c'est, les métiers.
Ils se posent même encore la question de savoir si vont être développeurs, administrateurs, systèmes.
Enfin, ils ne se posent pas la question, sauf après mon passage.
Ou chef de projet ou autre.
Et pourtant, ils sont en bac plus qu'à déjà.
Et ils n'ont pas cette vision-là des métiers.
Ça dépend qui on a en face aussi en termes d'enseignants.
Pour ma part, j'ai fait les deux.
J'ai eu un député ou des enseignants plutôt chercheurs en face de moi.
Et ensuite, j'ai eu des enseignants qui étaient des professionnels
qui avaient fini en master, entre 3 et 5 ans avant.
Des jeunes diplômés qui avaient déjà un entreprise, qui avaient déjà un cabinet de consulting,
des choses comme ça, qui nous ont donné des cours.
Là, ça change tout.
On a quelqu'un en face qui va avoir une approche totalement différente
et qui, à la pause qu'a fait, va nous parler de son client, qui veut aussi, qui veut ça.
Tandis que l'autre, il va nous parler potentiellement de sa dernière conférence
qu'il a faite, je ne sais où.
On n'est pas du tout dans le même profil en face.
Ça inspire indifférentment.
Clairement.
Encore que, oui, dans cette école-là, télécoms, ça se détient, il y a beaucoup de pros.
Il y a des enseignants chercheurs, mais ce n'est pas la totalité.
Il y a beaucoup de professionnels qui interviennent.
Mais ça reste quand même un diplôme d'ingénieur généraliste.
Mais je pense qu'en effet, l'alternant, c'est très bien.
Surtout quand on veut faire quelque chose de très poussé,
on peut trouver des boîtes qui cherchent des alternants.
Nous, clairement, on a deux alternants techs.
C'est quelque chose qu'on recrute et on est tout petit, en fait.
On est quatre, du coup.
Et du coup, les personnes qui travaillent avec nous, elles voient beaucoup de choses.
Est-ce que tu as un autre conseil à donner aux personnes
qui veulent se lancer dans le métier en dehors des études elles-mêmes ?
Un autre conseil ?
Je me réfléchis.
Mon conseil serait de s'intéresser à l'IT à 360°.
On peut facilement, pour bon nombre d'informaticiens,
tomber chez des grands clients,
être dans une équipe qui a un scope assez réduit.
Au-delà de la culture générale, c'est surtout dans le fait de comprendre ce qu'on fait.
C'est pratique d'avoir une vision à 360°, de savoir qui il fait quoi,
de comprendre comment le projet IT se déroule du métier jusqu'à nous.
Pour moi, ce serait un premier conseil.
Le deuxième conseil, je pense que tout le monde le connaît,
c'est de se tenir informé des dernières tendances, des normes d'évolution,
d'avoir une idée de la suite du prochain virage.
C'est un bon conseil, parce que c'est beaucoup plus facile qu'il y a quelques années.
Aujourd'hui, il y a des sites de partout, il y a même des chaînes YouTube qui font ça.
D'après toi, tu n'es pas encore arrivé à ce niveau-là,
mais qu'est-ce que tu imagines pour la suite ?
C'est quoi, selon toi, les évolutions de quelqu'un qui ferait ton métier ?
Qu'est-ce qu'on pourrait faire après plusieurs années d'expérience dans ce poste d'administrateur Cloud DevOps ?
Tu parles d'évolution du métier ou d'évolution de carrière ?
Évolution de carrière plutôt.
J'ai un évolution de carrière,
avoir une casquette peut-être un peu plus expert
ou l'idée, c'est de designer un peu plus que de construire ou d'exploiter,
donc avoir une casquette un peu plus design.
En soi, je ne suis pas sûr que c'est une évolution forcément verticale, mais c'est différent.
Moi, je le prendrai en tout cas pour ma part comme une évolution,
parce que je trouve ça très intéressant.
C'est un petit côté créatif, à designer des bras, des choses comme ça.
Pour ma part, j'ai déjà fait une démission de pure conseil et d'audite.
C'est quelque chose que j'ai bien aimé et qui est souvent réservé plutôt à des profils assez expérimentaux.
Les conseils et d'audite, c'est vachement bien.
En effet, ce dont tu parles, je pense qu'on peut dire que ça peut être un architecte cloud.
En plus, d'architecturer la phrase structure,
il va aider aussi l'équipe de développement à architecturer son code.
C'est un architecte, je ne sais pas si ça correspond à l'architecte solution.
Je ne sais pas, mais honnêtement, il doit travailler avec tout le monde.
MoS, c'est un truc que je trouve très bonne évolution.
Et après, les autres évolutions, c'est faire un autre métier à côté et toujours pousser vers l'expertise.
Justement, l'autre évolution, c'est de devenir freelance.
Aujourd'hui, tes frilances, tu me l'as dit, ça fait combien de temps que tu es freelance et qu'est-ce qui t'a poussé à devenir freelance toi ?
Ça fait un an et demi, je crois.
Bon, arrondissons un an.
Alors moi, ce qui m'a poussé à devenir freelance, c'est que j'arrivais à un moment où,
chez mon employeur, je commençais à connaître toutes les techno.
J'arrivais à un moment où, après avoir été reconnu, plus ou moins, à commencer à savoir sur les techno de la boîte, les techno DevOps,
j'arrivais à un moment où je pense qu'on était tous plus ou moins au courant de comment ça fonctionnait.
Il n'y avait plus trop de mystères.
Et en même temps, j'avais pas mal de propositions tout simplement.
J'avais pas mal de propositions de l'autre côté.
Beaucoup de collègues consultants aussi.
Beaucoup de collègues qui me disaient, voilà, moi, je suis freelance, je suis passé freelance,
j'ai démissionné, je suis passé freelance pour X telle raison que ce soit argent ou non,
il y avait de tout en termes de raison.
Et de là, ça initie quelque chose dans la tête.
Et le jour où j'ai senti que j'ai manuillé un petit peu dans mon tarfe, j'ai décidé de tenter le coup.
Et voilà, donc j'ai tenté le coup.
Et puis au final, c'est en tant que coup que je me suis rendu compte que ça permettait plein de choses.
Ça permettait notamment d'être plus libre géographiquement, d'entreprendre,
simplement d'avoir d'expérimenter ses idées un peu comme toi avec ce podcast.
Exactement.
Toi, tu as quel âge aujourd'hui ?
J'ai 27 ans.
T'as 27 ans ? Est-ce que tu as eu peur ?
Parce que finalement, tu t'es lancé à 26 ans, c'est finalement court comme carrière avant de te lancer en freelance.
Est-ce que tu as eu peur avant de te lancer en freelance ?
Ouais, j'ai eu peur un peu.
C'est pour ça que je suis parti en congé sabbatique.
Je n'ai pas des missions et tout de suite.
J'avais l'opportunité de faire un congé sabbatique.
J'avais assez de temps de boîte.
Et donc oui, j'ai forcément au début, j'ai eu un peu peur,
mais ça correspondait à ce que j'avais choisi dans la vie à ce moment-là.
Donc je l'ai fait, mais voilà, congé sabbatique, ça protégeait quand même un petit peu les arrières.
Et puis très vite, j'ai plus eu peur, en fait.
Très vite, j'ai plus eu peur parce qu'on se rend compte que plus on a des expériences freelance,
plus on peut retrouver un CDI rapidement.
Donc si la peur, c'est de ne pas avoir de CDI,
j'ai l'impression qu'on arrive à la vaincre assez rapidement en trouvant des missions en freelance.
Voilà.
C'est mon avis.
Après, c'est clair qu'on n'est plus dans le même mindset,
je ne suis pas sûr que c'est le bon mot,
on n'est plus dans le même mindset, pas le même confort que quand on est salarié.
Alors pour certains, c'est de la peur, mais pour d'autres, ce qu'on fait, c'est de la liberté.
Moi, je le prends un petit peu sur le tableau.
Je suis plus à ce côté, je le prends à la liberté que le côté peur.
C'est que ça fait peur de se lancer comme ça sans patron.
On est dans une société qui prône salarié aussi depuis longtemps.
Ça a tendance à changer, mais du coup, c'est vrai que ça peut faire peur.
Est-ce que tu conseilles aux jeunes qui sortent de l'école, qui ont envie de se lancer en finance,
de le faire tout de suite,
ou comme moi, je leur conseille, faites un ou deux ans d'abord dans une boîte,
puis après, lancez-vous en frilance.
Moi, mon conseil, il va aller clairement vers ce que tu leur conseilles.
Toi, tu dis deux ans, j'aurais dit même plus, parce que...
Alors moi, je le cas peut-être sur mon parcours,
j'ai fait sans compter les alternances, j'ai dû faire trois ans ensuite en CDI,
sachant que j'étais déjà deux ans dans la même boîte avant,
j'ai fait cinq ans dans la même boîte.
Et en fait, oui, alors oui, il y a le côté technique,
le côté technique que tu en as en un an, deux ans, je pense que tu vois pas mal de choses.
Après, moi, ce que j'ai appris aussi, c'est le côté...
je n'ai pas envie de dire politique, mais relationnel.
Là, savoir comment discute un terrain chef de pro,
comment discute l'architecte,
comment les choses fonctionnent globalement, même en dehors de l'aspect technique.
Et ça, se retrouver frilance tout de suite en s'enfin de l'école,
je pense que c'est pas correct.
Moi, j'ai quand même eu des sense, disons, des managers qui m'ont appris pas mal de choses.
Aujourd'hui, si je m'étais dit que j'étais juste à frilance, juste après les études,
je ne sais pas comment j'aurais appris ces choses-là,
parce que j'aurais été tout seul, je ne m'aurais pas guidé, quoi que ce soit.
C'est vrai, parce qu'en plus de venir frilance,
il y a l'aspect technique et l'expérience qu'on doit apprendre si on sort de l'école,
mais en plus, comme tu le dis, l'aspect commercial, l'aspect du service,
comment est-ce qu'on va traiter les gens avec qui on travaille et puis notre client.
Et puis, il y a ne pas se faire manger aussi par client,
et ça, je pense que tu peux l'avoir avec un petit peu de recul quand même,
quand tu as déjà eu un patron et un client frilance, pas très loin, on va dire.
Pour ça, maintenant, j'arrête de faire de la prestation
que je vais plus vers du consulting, du Montorra et autres.
Mais je pense qu'en effet, il faut avoir cette expérience-là du monde du travail
avant de se lancer en frilance, puis même pour avoir un peu d'assises, quoi.
On va dire, j'ai fait ça dans la vie avant.
Ouais, et puis souvent, mon avis après, tu me diras ce que t'en penses.
Souvent, quand t'es appelé sur des missions frilances,
t'es appelé pour un projet, une expertise.
Moi, en restant 4, 5 ans chez le même client, enfin, en interne, quoi.
J'ai pu bosser sur plein de projets différents, alors de près ou de loin,
mais j'ai bossé sur des applications micro-service, j'ai bossé sur AIS,
j'ai bossé sur AWS, j'ai bossé sur des projets d'applications vieilles
comme le monde, enfin, j'ai vraiment bossé sur pas mal de choses.
Et je trouve qu'en interne, c'est mon avis en tout cas,
j'ai l'impression qu'en interne, voilà, tu peux voir pas mal de choses,
la condition que tu le demandes, que tu te formes,
ça peut se faire assez facilement.
Alors qu'en frilance, on a quand même une idée de pourquoi tu viens.
Tu viens pour un but précis, je sais pas ce que t'en penses, mais je suis certain d'être avec toi.
Oui, je pense exactement en pareil.
Et puis, il faut bien voir aussi la différence entre le frilance
et le prestataire qui vient d'une boîte de prestations.
Le prestataire qui vient d'une boîte de prestations,
enfin, moi j'ai été prestataire longtemps, j'ai été embauché,
c'est un client final, puis un client final, c'est quelqu'un qui te fait travailler chez lui.
Et puis j'ai été en prestation, et le prestataire, il ne fait ni plus ni moins que vendre de la force de travail.
Et finalement, le prestat ou l'interne, il fait presque la même chose.
Alors que le frilance, tu vas le chercher parce qu'il sait faire quelque chose particulier
que toi tu sais pas forcément faire, il va te faire accélérer à un projet particulier.
Moi, c'est vrai que quand je prends encore des prestations aujourd'hui,
c'est des petites prestations courtes dans ma spécialité,
Guitlapse-Yay, mais je prends pas le reste, ou très très peu.
Et je reste sur mon expertise pour pas aller réapprendre,
comme je faisais au début de ma carre de frilance,
à chaque nouveau projet A, je vais apprendre C, A, je vais apprendre ça, etc.
On s'est trop écusants, et puis passer à un certain temps, il faut tout spécialiser, je pense.
Justement, moi j'ai fait beaucoup de l'administration cloud en frilance,
et j'ai vu qu'on était très peu à faire ça,
parce qu'il y a beaucoup de développeurs et développeuses frilances,
mais de ops, de manière globale, frilance, on est assez peu.
Est-ce que tu confirmes ça aujourd'hui, parce que moi ça date déjà 5 ans,
et est-ce que tu confirmes que tu manques pas de prospects ?
Alors je confirme déjà que sur certains que je manques pas de prospects,
sur des missions en plus, c'est très très varié,
il y en a qui demandent d'être sur place, d'autres totalement à distance,
il y a même des missions à l'étranger des fois.
Après la première question, c'était que je confirme qu'il y a plus de frilance en dev,
que les côtés ops, c'est ça ?
Est-ce qu'on n'a pas beaucoup de frilance en côté ops ?
J'ai l'impression que chez les ops, le côté frilance,
et indépendant, il passe un peu sous les radars,
et qu'on est tous embauchés sans boîte de prestations,
soit chez les clients finaux, et assez peu de frilance.
Mon avis doit être biaisé, parce que j'ai quand même croisé beaucoup d'ops frilance,
j'étais chez des gros clients, donc du coup il y avait quand même beaucoup de gens.
Mais par contre effectivement, j'ai aussi l'impression qu'il y a une culture frilance plus forte côté dev,
et pourtant, et pourtant, alors là encore une fois, c'est mon avis, je me dis à ce que t'en vends,
et pourtant je trouve que c'est plus simple peut-être d'être frilance côté ops,
parce que côté dev, il y en a beaucoup qui se plaignent d'avoir des projets, peut-être courts,
one shot, alors que quand on est ops en général, on reste chez un client à certains moments,
ça peut être court, mais pas de semaine quoi.
Pour résumer, je pense que ce que tu penses, c'est pas faux,
je pense qu'il y a à côté dev, il y a un peu plus cette culture frilance,
mais moi de mon côté, j'ai vu quand même beaucoup d'ops frilance passés par des boîtes de prestas,
donc tu ne le sais pas forcément qui sont en frilance, c'est parce qu'ils ne le disent pas,
on ne doit pas être ou le dire dans le chèque client, mais les sont là.
Les DBAs, oui, mais du coup, est-ce que justement, ils mettent en avant cette expertise,
parce que comme tu le dis, ils passent par des boîtes de prestas, j'en ai vu quelques-uns comme ça,
mais du coup, ils ne viennent pas pour une expertise particulière,
genre le DBAs expert dans l'optimisation des requêtes posées à SQL,
par exemple sur un gigantesque agréga au dispose, des frilences comme ça, je ne sais pas si on a beaucoup.
Non, il n'y en a pas beaucoup, et moi, j'en ai un en tête en fait que j'ai croisé,
que j'ai croisé, qui était frilance DBA, justement, ce que tu dis,
il fait des tests, des audits de parlement, SQL Server, des choses comme ça,
enfin, SQL Server, vraiment spécialisé SQL Server,
et ça m'a interpellé justement, parce que c'est vrai que c'est pas très commun,
les frilences ops dédiées à ce que tu fais au final.
Frilance, voilà, je fais de la CIA, tu m'appelles pour de la CIA.
Non, j'ai plutôt vu, oui, effectivement, des profils généralistes côté ops.
Ouais, voilà.
Je pense que ça vient aussi avec le temps, parce que tu ne peux pas avoir une expertise tout de suite au début de ta carrière,
mais au bout d'un moment, tu vas te spécialiser forcément dans un truc,
tu ne peux pas continuer à papillonner droite à gauche.
Par exemple, si on parle du cloud, tu vas te spécialiser dans un cloud provider,
ou alors dans un cas précis, c'est là où de disponibilité, enfin, je ne sais pas.
C'est difficile, c'est difficile de...
Tu entends dans des missions et le destin, tu rentres dans des missions,
des fois, tu ne t'attends pas à prendre autant de compétences sur une certaine techno.
Ouais, moi là-dessus, je suis un peu perplexe, je ne sais pas trop...
comment dire, si tu as une spécialisation à choisir, je me laisse un peu bercer par ce que les missions ne sont pas...
T'es encore jeune, tu as le temps de voir venir les choses.
Ecoute, on arrive vers la fin de ce podcast.
Est-ce que tu as un livre, un article, une conférence ou même un blog à conseiller ?
Ouais, Search IT Operations. Tu connais ?
Non, je ne connais pas, je vais le noter.
Search... Toi, je suis en train de le noter, pour voir si je le dis bien.
C'est Search IT Operations.
A l'époque, je cherchais pas mal de choses sur les chat-pops, et...
et je t'ai tombé dessus sur Search IT Operations.
Là, je ne trouve pas non plus.
Ah, si tu cherches...
Search IT Operations, en fait, c'est un site de Tech Target.
Ecoute, je mettrai en lien du podcast.
Ok.
Si tu l'as, tu l'enverras par LinkedIn, justement.
Où est-ce qu'on te retrouve ?
Ah bah voilà, parfait.
Où est-ce qu'on te retrouve ?
Est-ce qu'on te retrouve sur LinkedIn ? Ailleurs ?
Non, moi, je ne me retrouve que sur LinkedIn.
Du moins pour l'instant.
Est-ce que je laisse ton LinkedIn dans la description ou pas du tout ?
Ah, si, t'en vois pas.
Si, quand même.
Ecoute, merci en tout cas pour ce témoignage.
J'espère avoir... que ça va donner envie à nos auditeurs
de devenir administrateurs ou administratrices.
Claude, en sachant qu'il y a plein d'autres métiers de l'ops.
Et ça, vous le serez en suivant les autres épisodes de cette série sur l'ops.
Eh ben, merci à toi, Axel.
Et je vais te laisser le mot de la fin.
Oula.
Au revoir.
Je ne sais pas.
Allez, vive la CIA, c'est bon.
Vive la CIA, c'est très bien.
Eh ben, merci beaucoup.
Allez, merci Christophe.
Passer par mon job board, c'est aussi, pour toi,
l'assurance d'être accompagné par My Little Team dans ton parcours de recrutement.
Et en plus, tu me soutiens, car ce job board me permet de gagner de l'argent
et donc de financer les podcasts que tu aimes tant.
Donc, rendez-vous sur vu.fr slash jobboard-devops
mais sinon, tu trouveras le lien en description.
Attends, attends.
Si tu es manager, DSI ou directeur d'entreprise
et que tu cherches à recruter des personnes qui sont intéressées par le DevOps,
tu leur as compris puisque tu écoutes ce podcast, c'est l'endroit idéal.
N'hésite pas à déposer tes offres d'emploi sur mon job board.
C'est sur vu.fr slash jobboard-devops-recrutes
mais, c'est pas grave, le lien est aussi en description.
...