tous les jeunes qui veulent travailler dans la tech rêvent de développer.
Pourquoi ? Parce que inconsciemment, dans l'inconscient collectif,
c'est le métier le plus facile à reconnaître.
Pourtant, il y a des tas d'autres métiers dans le numérique.
Alors pour fêter le lancement de mon job-board en collaboration avec My Little Team,
j'ai décidé justement de faire une série d'entrevues sur les métiers
pour parler des métiers de la production, de l'exploitation et de l'infrastructure.
Mais on reparlera de mon job-board en fin de vidéo.
Donc, reste bien jusqu'à la fin,
surtout si tu cherches un taf dans le milieu de la tech.
Aujourd'hui, je suis avec Rama Sinyin.
Ensemble, on va parler de son post et son rôle d'administrateur système.
Et aussi, on va voir comment le DevOps et le Cloud et aussi la supervision,
on aura l'occasion d'en parler, a un gros impact sur son métier.
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 appartez l'émission où je m'entretiens avec un invité.
Et 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.
L'invité de l'aujourd'hui fait justement partie de cette communauté, peut-être qu'on m'en parlera.
Nous sommes déjà plus de 1000 à échanger et à partager tous les jours,
rejoint-nous pour ne plus être seul face à tes questions.
Tu pourras justement discuter, trouver peut-être un mentor ou pouvoir mentorer d'autres personnes,
parce qu'il y a des juniors qui nous rejoignent.
C'est le premier lien en description pour t'inscrire.
Ou alors tu vas sur le site compagnon-devops.fr.
Alors je précise, c'est complètement gratuit parce qu'il y a des personnes parfois qui peuvent se poser la question.
Alors, bonjour à moi.
Merci d'avoir répondu à mon appel à témoignage que j'ai fait sur LinkedIn et sur le forum justement.
Est-ce que tu peux te présenter en quelques mots et nous dire ce que tu fais dans la vie s'il te plaît ?
Bien sûr.
Alors bonjour à tous.
Rahma, j'ai 40 ans, bientôt 41.
Qu'est-ce que je fais dans la vie ?
Je suis ingénieur DevOps, ingénieur système et un peu casquette sécurité dans une startup qui s'appelle Kodok depuis quelques mois.
Dans la vie, moi-même personnellement, j'aime bien les jeux de société et jeux de tarte.
C'est d'ailleurs comme ça que tu as rencontré Christophe en me prenant une correction à je te perds.
C'est très rare.
Et puis, au jour le jour où je suis Kodok, hors d'où de travailler en pure DevOps et de travailler dans le domaine de la santé,
c'est ce que fait l'entreprise qui je travaille.
J'aime bien utiliser mes compétences de DevOps pour des projets personnels toujours dans le domaine ludique,
mais aussi soif d'apprents, je me considère toujours en mode bétain.
Voilà, papa d'une petite fille et bientôt d'une deuxième.
Félicitations apparemment cette partie t'as marqué.
Le joueur appelle bien de cette partie.
C'est un jeu qui malheureusement n'a pas eu le succès qu'il mérite et c'est bien dommage.
Alors je vais commencer.
Ouais, c'est vrai.
Alors pour ceux qui se posent la question, c'était Achize.
C'était très, très bon jeu, mais malheureusement, la communauté n'a pas pu se créer.
Je vais te poser quelques petites questions que je pose tout le temps,
ayant on va venir un peu après, un peu plus en détail dans ton métier.
D'abord, je vais te poser la question sur c'est quoi, à toi, la définition du DevOps?
La définition du DevOps, pour moi, c'est qu'il y a une méthode ou du moins un mindset,
plusieurs choses, c'est un ensemble.
Je savais même pas que j'étais un DevOps ces quelques années,
que j'avais en fait plutôt cette méthodologie.
Donc pour moi, un DevOps, c'est quelqu'un qui n'a pas peur du challenge,
qui résout des problèmes, qui teste, qui reteste, qui reteste,
qui détruit et qui reteste et qui, après, avance.
Et c'est quelqu'un qui, tout le long du cycle de vie d'un service ou d'une application ou d'une infrastructure,
prépare des étapes et met en place simplement des étapes de sécurité,
mais aussi fait des tests unis, des unités.
En fait, l'esprit des DevOps, c'est quelqu'un qui est sur le système,
sur le code, sur l'infrastructure, sur les frameworks,
à un large panel de connaissance, mais il n'est pas maître,
mais il touche un peu à tout.
C'est un peu, moi je disais souvent, on n'appelait pas le couteau suisse,
on n'appelait la machette suisse, parce que c'était énorme,
mais en même temps, je savais tout faire à un bon niveau.
Et je pense qu'un DevOps, c'est ça, il peut être très bon en SQ,
il peut être très bon en infra, il peut être très bon en réseau,
et un peu moins en code, un peu moins en debugging ou l'inverse.
Pour moi, d'ailleurs, c'est quelqu'un qui touche un large panel de Lighty,
et qui en plus a un pied dans le cloud et un pied dans l'un de la premise.
C'est quelqu'un qui doit bien gérer les hybrides.
Ce n'est pas quelqu'un qui ne fait que du full cloud,
c'est quelqu'un qui est capable de gérer les deux environnements.
Et donc tout ce qui va avec.
Et la finalité de cela, c'est que pour moi,
un DevOps, il prend soin de ses développeurs.
C'est ce que j'attache une nation particulière,
apprendre soin de développeurs qui soient back,
qui soient frontes ou même malithèque pour qui aujourd'hui,
et qui je travaille de concert,
et qui est capable aussi de communiquer de manière transverse
dans le périmètre avec les product managers
et surtout avec les équipes commercières.
Voilà, ça c'est l'argent pour moi.
C'est quelqu'un qui un peu va toucher à tout,
mais qui sait se rendre disponible et qui résout des problèmes.
Et puis après, c'est quelqu'un qui passe sa vie de son terminal à faire des conteneurs.
Ça c'est une réalité, il ne faut pas le nier.
Mais c'est pour ça qu'on aime ça.
Ouais, tout à fait.
On ne fait pas tous des conteneurs,
mais c'est vrai que ça a beaucoup changé ces dernières années.
Alors je me doute un peu d'une partie de la réponse que tu vas me donner,
mais comment est-ce que toi, tu as rencontré le DevOps
et qu'est-ce que ça a changé dans ta vie de faire cette rencontre ?
En fait, avant d'arriver dans le milieu du DevOps
ou même du Dev, j'ai travaillé dans les Apple Store.
Donc, long carrière dans les Apple Store,
je ne suis même pas allé se vertir de certains,
donc l'un des plus connus en France qui suait des Champs-Élysées.
Et en fait, dans sa magasin, j'étais ce qu'on m'appelait un technique à l'expert.
Ce sont les liens qui sont au genius bar qui n'auraient pas avocé le téléphone.
Sauf qu'en tout le temps, j'avais créé un projet sur la blockchain.
Rien à voir avec la finance.
La blockchain, c'est les Bitcoins, tout ça, c'est très intéressant.
Mais c'était plutôt sur les services décentralisés.
Donc, qu'est-ce que je faisais ?
Je déployais en fait des machines dans le cloud, des VPS, des Linux, très simplement.
Et je mettais à l'intérieur des wallets et ça faisait du staking
pour les gens, des choses-mêmes, pour générer les revenus.
Mais après, j'ai commencé directement à programmer des jetons
pour des clients ou des gens qui le voulaient.
Je ne sais pas ce qui m'intéressait, mais ce qui m'intéressait plus
c'était de déployer en fait leurs infrastructures
et de mettre directement soit chez Etner, sur OVH, avec les VPS OVH
ou avec Iono, des choses comme ça.
Et ça, c'était quelque chose que j'aimais bien.
Et après, j'ai commencé à découvrir qu'on pourrait faire ça sur l'infrastructure cloud,
comme GCP, enfin...
Bon, moi, c'était obscur encore, ces choses-là.
Mais je me dis, il fallait y aller.
Et je vais continuer à faire ça.
Et en fait, je me suis dit, mais qu'est-ce que c'est ?
Alors, regarde un peu ce que ça fait, tout ça.
Donc, j'ai un peu découvert l'univers de la containerisation un peu tard, en fait.
Je me suis dit, wow, c'est dingue.
C'est vraiment le truc que je me suis dit.
Je me suis dit que c'est partiellement force qu'on peut faire avec ça,
extrêmement modulable et tout.
Et je me suis dit, je vais mettre de côté la blockchain
et je vais me lancer plutôt dans vraiment faire de l'applicatif.
C'est là que je me suis rendu compte que le front n'était pas fait pour moi,
parce qu'en termes de front, je suis extrêmement mauvais.
Et donc, je regardais.
Pour moi, j'étais programmeur, back-end, c'est ce que je me disais.
Et on avait joué ensemble dans un jeu de cartes, toi et moi.
Et à l'époque, je n'avais pas entendu ce que tu faisais dans la vie,
mais on était en train de contacter toi et moi,
par rapport au jeu de cartes, genre.
Et je suivais un peu ce que tu faisais.
Et un jour, je vois un truc, tu dévopes un peu.
Je me souviens, c'était le lancement de Frogit.
Tu avais fait un live dessus.
J'avais regardé avec attention.
Et c'est là où j'avais, j'ai découvert en fait le versioning.
GitLab, conseil, GitHub, acheté par Microsoft, peut-être, j'ai GitLab.
Et là, ça m'a ouvert l'esprit sur, attendez,
t'es en train de me dire que je peux aider des gens à accélérer leur déploiement,
regarder leurs codes, agir sur le cycle vide d'une application.
C'est intéressant, ça.
C'est ça le dévopes.
Et c'est là, je me suis dit, je veux faire ça.
C'est là où je me suis dit, je veux faire ça.
Donc, ça fait vraiment, depuis 3 ans que je me considère dévopes.
Et c'est vraiment ce que tu avais produit ce jour-là,
plus bien sûr, la motivation personnelle qui m'en fait venir.
Et ce qui m'a fait vraiment motivé, c'est ce que j'ai remarqué, c'est beaucoup d'entreprises,
mais c'est en train de changer.
Ce que je veux dire, ça a changé même.
N'accue pas du dévopes, mais n'accue pas aussi à chaque étape
de la création de l'application, ou du service, ou des microservice,
ou des API, des choses comme ça, des principes de sécurité à ce standard.
Ou même assez avancé.
Et très peu travaillant version.
C'est souvent staging et puis poof prod.
C'est pourquoi, on n'a pas l'agilité, on n'a pas le temps,
on s'est trop lents, des choses comme ça.
Et c'est depuis une présidente Empire qui lui, en fait, compte,
m'a dit, on fait travail, tu es un pure dévopes,
on va te mettre dans la sécurité.
Et c'est là où j'ai déployé des infrastructures sur Azure,
et j'ai découverté Rafa, mais là, j'avoue, depuis 3 ans,
je le sais du bonheur.
Donc voilà, ça a commencé avec la blockchain,
et un éclair, ça va paraître assez simple,
pour être pour la plupart des gens,
mais c'est quand j'ai découvert le versioning un peu tard.
Le fait d'avoir découvert le guide,
le fait qu'on fait versioner son code, qu'on va faire des branches et tout,
ça paraît pas, mais même aujourd'hui,
je pense que c'est quelque chose qu'il n'avait pas besoin d'améthriser.
Et ça, quand j'ai commencé à découvert ça,
j'ai découvert qu'on pourrait faire beaucoup, beaucoup, beaucoup de choses
pour accélérer le développement de ma service,
ce qui m'a fait venir dans le dévopes.
C'est cool, alors si j'ai pu tout ouvrir la voix vers ce monde-là,
tu dis en effet que guide et le versioning,
ça devrait être connu par, tu dis dévopes,
on va se faire tous les ops, c'est vrai,
parce qu'en effet, on a à peu près
de la même âge, je suis un peu plus âgé,
mais moi j'ai beaucoup fait d'exploitation
et j'ai beaucoup rencontré d'ops
et j'ai remarqué aussi dans ma carrière
que le versioning, c'était un truc qui n'était pas inné chez les ops
et pourtant, ça nous aide au quotidien.
Nous, les ops qui sommes dans ce mouvement-là, justement.
Et bien justement, on va parler de ça,
on va parler de ce fait que tu te dis être dévopes
puisque en me contactant,
tu es en fait le troisième à me dire ça,
parce que j'ai enregistré d'autres interviews
qui sont probablement au moment
où celle-ci sera diffusée, qui sera sortie.
Et je te l'ai dit, je pense que ça me gênait
et je pense que tu le sais en suivant,
puisque je considère que le dévopes, c'est pas un métier,
c'est un mouvement plus qu'un métier.
C'est pour ça que je dis que c'est un adjectif
qu'on colle à un métier.
Et j'ai proposé de te présenter comme admin-6-devopes,
administrateur-système dévopes,
puisque la presse que tu m'as dit,
ça me paraçait plus logique.
Et en fait, avec les autres personnes,
je les présentais comme administrateur-cloud de dévopes,
parce qu'en fonction des spécialités que chacun fait,
c'est pas tout à fait le même métier.
Est-ce que tu peux nous dire pourquoi est-ce que ta boîte
t'a identifié comme un dévopes et pas comme un ops
qui fait du dévopes ?
C'était quelque chose qui ne l'avait pas.
Tout simplement, Kodok est une startup qui existe
depuis maintenant 2017.
Et c'est vraiment une startup qui a commencé
sans avoir justement les méthodes de dévopes,
c'est-à-dire les méthodes algées.
Il y avait, mais pas aussi avancée que ça l'était
à quelque temps et aussi poussée comme on en mène aujourd'hui.
Si je peux me permettre de faire une petite parenthèse
pour qui je travaille, Kodok, c'est une startup
qui crée des entrepôtes de santé, donc des ETS.
C'est des espaces qui auraient beaucoup avec les hôpitaux.
C'est dans le but de la recherche, c'est pour accélérer la recherche.
Donc les hôpitaux ne travaillent uniquement
en primaire.
Donc il fallait au bout d'un moment, ils commencent à avoir
beaucoup d'hôpitaux, ils commencent à avoir pas mal de patients,
pas mal de collaborateurs dans les HSU,
dans les HSU ou même dans divers groupes hospitaliers.
Et donc eux, ils disaient, il nous faut quelqu'un
qui est capable de nous aider à accélérer le déploiement
et quelqu'un qui peut nous aider surtout
à respecter les référentiels en fait de sécurité
que la CNIL propose, car les entrepôtes de santé
sont extrêmement réglementées.
Les données de santé sont aujourd'hui extrêmement sensibles
et ça va très loin, ça peut être de l'imagerie
comme des données génétiques, mais bon, tout ça, c'est un ensemble.
Donc Kodok a ce savoir-faire de déployer, de mettre en place,
mais il fallait aussi quelque chose qui permettait d'observer,
de monitorer, aussi d'accélérer le déploiement en primaire
dans des environnements extrêmement fermés et sécurisés
qui sont les hôpitaux.
Comme vous le voyez, dans la presse, on voit des hôpitaux,
notamment un hôpital à Corbeille et Sônes, c'est fait pirater.
Donc la sécurité à 100% n'existe pas.
Donc vaut mieux cibler ce qu'on appelle, moi je sais pas,
des assets critiques et les protéger.
Donc ils se sont dit, il nous faut quelqu'un qui est développe,
qui va nous dire qui va faire du conteneur, qui va faire du cloud,
parce qu'un jour, un cessament sous peu, Kodok va aller sur le cloud
avec tous les services et les produits qu'il propose.
Ce qu'on appelle des HDS, donc le clavier d'état d'HDS, tout ça.
Il y en a d'autres, Azure, ou même il y en a des très bons en France
qui sont indépendants et je pense que pour la souveraineté des données,
utiliser HDS français, c'est pas mauvais du tout.
Et il en fallait quelqu'un qui fasse des recherches en ce jeu-là
pour faire cette migration là-dessus.
Donc ils sont dit, ils font un DevOps.
Alors au début quand j'ai échangé avec eux,
je suis plutôt accès à sécurité, je suis plutôt accès aussi sur le système,
effectivement, mais que le DevOps, c'est tout au long des produits
et des services que nous avons déployés,
il faut que je participe au cycle de vie en fait,
et au même de renaissance et de déploiement, tout ça.
Et ça, au début, ça ne tombe pas que à ça.
Et aujourd'hui, après bientôt plus de trois mois dans l'entreprise,
c'est quelque chose qu'ils ont compris que le DevOps,
tout le monde l'est un petit peu en fait dans la boîte.
Et c'est là où ils ont compris que un DevOps,
ce n'est pas simplement une personne,
c'est quelqu'un qui a amène le credo et la philosophie DevOps
au sein de l'entreprise,
qui rend autonomes certains développeurs,
certaines personnes qui n'ont pas du tout l'habitude
de se connecter à un système et de regarder ce qui se passe.
Donc, le script DevOps, mon rôle, c'est de mettre à disponibilité des outils
pour que les clips soient à l'aise,
puis récupérer les informations qu'ils ont besoin,
vérifier les déploiements, vérifier que tout fonctionne bien.
Et puis surtout, remonter des informations aux divers autres équipes.
Ça peut être des équipes commerciales, ça peut être des équipes produits,
c'est peut-être des équipes marketing qui ont besoin un peu d'avoir des retours.
Et le DevOps, c'est un gage de confiance avec des partenaires.
Quand tu commences à dire à des partenaires
qui soient commerciaux ou là dans les services publics,
on utilise les méthodes agile DevOps pour déployer et maintenir.
Et donc, la haute disponibilité de votre service sera toujours.
C'est un argument de dire qu'il y a un esprit DevOps dans l'entreprise.
En fait, mes tâches, elles ne peuvent pas reposer uniquement sur mes épaules.
Je pense que pour toi, c'est pareil, on ne peut pas se dire que c'est moi qui va tout gérer
au niveau des déploiements, c'est pas moi qui va tout faire, c'est pas possible.
Comme ils ont début, on est des coûts de Suisse, il faut être disséminé.
Et donc, ça, ils ont rechargé, ils ne savaient pas un peu
ce que ça allait leur apporter.
D'ailleurs, mon précédent employer, lui, ne savait pas trop non plus.
Et c'est pour ça qu'aujourd'hui, la culture DevOps, je pense,
depuis un an et demi, est vraiment bien comprise
que ce n'est pas uniquement un poste, malgré qu'il y a une sorte de hype
sur ce qu'on fait, qui je trouve des fois n'est pas très positive.
On peut en discuter d'ailleurs.
Mais il faut comprendre qu'on n'est vraiment là
pas uniquement déployé des infrastructures,
on est là vraiment pour apporter un esprit, pour faire monter en compétence
aussi l'entreprise et aussi les employés, aussi les collaborateurs.
C'est pour moi, c'est essentiel que ce soit compris pour mon nouvel employeur
et ça se passe très bien aujourd'hui avec eux à ce niveau-là.
Un peu long comme explication.
C'est une bonne question.
Oui, mais c'est bien parce que c'est vrai qu'on a tendance à réduire
le DevOps à la phase de déploiement.
Alors en effet, c'est la phase où on gagne le plus en retour
sur investissement automatisant notamment.
Mais justement, il y a toute la partie transmission de culture
et change, partage justement entre les devs et les ops.
Le fait que les devs montent en compétence sur la partie ops
et vice-versa que l'ops montent en compétence sur la partie devs.
Moi en tout cas, depuis que j'évolue en tant qu'indépendant
dans le milieu du DevOps, j'ai toujours été dans des équipes
pure et disciplinaires où j'étais au milieu des devs.
J'étais souvent seul ops.
Donc ça aide justement à mélanger cette culture
et à avoir la collaboration.
Maintenant, j'essaie d'aider les grandes entreprises
à passer au DevOps, à apporter cette philosophie en interne.
Mais c'est compliqué parce que justement,
on en parle dans un autre épisode de podcast
que j'ai enregistré cette semaine.
Mais ce que tu me dis là-dessus,
ça m'amène à une autre question que je te poserai tout à l'heure
justement sur un autre des aspects du DevOps.
Donc, on parle assez peu.
Mais j'aimerais bien que justement,
tu nous décrives un tout petit peu ton quotidien,
tes tâches récurrentes dans ton métier.
Parce que l'objectif là, c'est de faire connaître ton métier.
Et quand tu nous as expliqué ce que tu faisais au début,
clairement, t'installes des systèmes et des serveurs.
C'est pour ça que je te présente comme administrateur système
même si c'est plus compliqué que ça, on le sait tous les deux.
Mon quotidien commence très tôt.
Je suis un lef tôt.
Si je dis un peu ma journée type,
les gens vont se dire, voilà, je me réveille toujours
entre 5h40 et 6h du matin.
Et je prends mon temps pour me dégourdir.
Ça paraît pas, mais avoir une bonne hygiène de vie
dans notre métier est extrêmement important.
Parce que l'on a un métier qui peut être stressant des fois.
Il ne faut pas l'oublier comme ça.
Et donc, je me lève très tôt et je fais les choses
du matin que tout le monde fait.
Et puis, je veux dire, vers 7h, je commence à attaquer.
Ma journée quotidienne, ça commence toujours par observer
sur ce qui s'est passé, la veille sur nos environnements
de dev, de préprod.
Donc, je regarde un petit peu sur une plateforme de monitoring
que j'ai déployée chez Kodok.
Et je vérifie que tout fonctionne bien.
Je prépare aussi un récap de ce que j'ai fait la veille.
Principe de méthode agile, de start-up.
Donc, on a un stand-up à 9h45, 2 heures plus tard.
Pendant tout seul œuvre de temps, je fais de la veille.
Beaucoup de veille.
Et je teste des nouvelles techniques sur mon ordinateur personnel.
Ça passe par le futur pseudo-petite concurrent de Kubernetes
qui est normal de la Chikor.
Je teste en ce moment.
Ça peut passer par voir mon vault, mon cluster personnel que j'ai.
Je fais des tests.
Je viens tester des environnements.
C'est ce que je fais pendant une heure.
Ça me permet de mettre dans le bain et un peu de déconnecter
vis-à-vis de ce que je fais de commission.
Ça, c'est un peu comme je démarre.
Mon quotidien chez Kodok commence vraiment à partir de 9h45
où là, suite à ce stand-up, on dit ce qu'on a fait la veille
et ce qu'on va faire aujourd'hui, j'attaque.
Généralement, je me prépare toujours la veille.
Ça commence toujours par améliorer en fin de compte
et peaufiner d'une manière de déployer.
Mais aussi, comme je le disais, sur nos machines
et sur les systèmes qu'on a et les environnements qu'on a,
qui sont extrêmement riches et complexes
parce que c'est des stacks assez impressionnantes
parce que c'est la data.
Il y a une équipe de dizaines de data ingénieurs
et des cliniquoles data ingénieurs dans l'équipe
qui travaillent beaucoup sur des ETL.
Je pense que c'est un ETL.
Mais pour les gens qui me regardent,
ils ne savent pas que ces technologies extraquent transforme l'eau.
Ça prend de la donnée avec des connecteurs.
Ça les transforme et ça les charge de manière lisible.
C'est ça le produit qu'on a Kodok.
C'est-à-dire qu'on accélère la recherche
pour les chirurgiens et les scientifiques dans les hôpitaux.
Ils ont un peu de données de santé.
Ils ont plein de données, sauf qu'elles sont élisibles.
On a créé un moteur de recherche interne pour eux.
Ce moteur de recherche leur permet de faire une recherche
beaucoup plus rapide.
Ils peuvent créer après des corps, des choses comme ça.
Ça s'appelle Dr. Warehouse, un petit jeu de mots sympa avec la série.
Il faut améliorer ce service
qui lui est connecté à une API.
En fait, mon travail, mon quotidien, depuis que je suis arrivé chez Kodok,
ça consiste à améliorer en fin et compte la API,
en fin et compte de tous les services et de tous les microservices.
Donc beaucoup de rivers proxy.
On utilise trafic par exemple, comme techno,
beaucoup d'engings.
Et puis trafic que j'ai découvert,
dans notre métier on découvre des techno tous les jouants.
Trafic que j'ai découvert avec Kodok.
Et tu en avais parlé une fois dans une vidéo,
j'avais noté dans un coin.
Et heureusement que je l'ai noté dans un coin,
que j'avais lu la doc.
Je trafic que j'y touche deux, trois fois par jour
et je découvre de plus en plus de choses à mettre.
Je trouve que c'est un très bon outil pour gérer en fin et compte
les conteneurs, c'est super.
Et donc je parsfais en fait les systèmes en fait
de surveillance, d'observation,
mais aussi comment rendre beaucoup plus simple
la récupération d'information,
mais aussi beaucoup plus simple pour nos équipes,
comme ces équipes d'ATA,
ils doivent créer des connecteurs.
Donc des fois c'était très lourd pour eux avant
pour créer ces connecteurs.
C'est-à-dire qu'ils devaient se connecter à l'hôpital
avec un VPN, demander un droit d'accès, tout ça.
C'était assez complexe et assez long pour eux.
Et pas tous n'étaient capables d'aller
faire des connexions et c'est ça.
Je le ferai pour les requêtes, c'était pas évident.
Donc l'objectif c'était de leur créer
une sorte de plateforme,
mais aussi qui leur permettait d'avoir des informations
pour qu'ils leur voulent se connecter.
Donc mon quotidien c'est
remonter des informations aux équipes
et tout en respectant les règles de sécurité
et de conformité qui sont imposées par les hôpitaux.
Chaque hôpital a sa structure,
a sa propre règle de sécurité
et leur propre infra.
Certains ont des parfaits extrêmement puissants,
qui ont des stampes chiés de par exemple,
c'est pas facile par exemple,
de se connecter sans profil de VPN,
donc faut pouvoir récupérer des informations.
Donc mon quotidien c'est aider mes équipes
à ce qu'ils reçoivent leurs rapports le matin correctement,
vérifier que ça fonctionne bien,
c'est quelque chose qu'on est en train de mettre en place.
Et aussi débugger et aider les équipes
lorsqu'elles ont des problèmes sur les sandbox,
qui sont sur le cloud.
Donc mon quotidien c'est pas mal de débugging,
beaucoup de monitoring
et en se prenant beaucoup de construction
parce que je suis en train de construire
que l'équipe BAC, un API Gateway,
qu'on va mettre à GCP en fin de compte
et qui va récupérer toutes nos APIs
et qui va nous permettre de déployer encore plus facilement.
C'est un peu mon quotidien.
Mon quotidien il est très en ce moment
dans la configuration de conteneurs
qui va permettre de créer des Gateway
et comme ces environnements on-premise,
c'est là où il y a le challenge,
on n'a pas le cloud.
On n'a pas une stack VMware
où on peut t'éraformer quelque chose
où il n'y a pas de Kubernetes.
Donc il faut trouver des méthodes
assez ingénieuses pour déployer.
Donc ils avaient déjà des outils très intéressants
chez Kodok,
donc je n'avais pas besoin d'inventer le show,
ils avaient déjà des choses prêtes.
Mais après il fallait observer.
Et donc j'ai mis des techno comme Portainer,
je ne sais pas si tu connais.
Portainer qui permet directement
et là ça a permis d'observer les conteneurs,
de pouvoir les redémarrer directement
à récupérer des informations.
Et puis beaucoup de reverse proxy
dans les hôpitaux,
beaucoup de proxy pour remonter des informations
dans notre serveur central de monitoring
qui est sur Google Cloud.
Donc comme techno on utilise Zabix
qui est un système de monitoring open source
qui quand on commence bien à le twequer,
bien aller au bout des choses,
on peut faire beaucoup beaucoup beaucoup beaucoup de choses.
Donc monitorer des conteneurs de cœur en live,
c'est à dire quand il s'arrête, quand il remonte.
Voilà.
Donc mon quotidien est exactement ce que fait un des ops.
C'est à dire que ma journée,
aucune de mes journées se ressemble.
Voilà hier par exemple,
j'ai beaucoup travaillé sur Portainer
pour pouvoir le mettre avec trafic.
Là aujourd'hui,
j'ai travaillé uniquement sur la pay-get-way
que je voudrais mettre en place
avec Edge Inc,
avec plusieurs routes.
Et donc j'ai fait des tests avec Kong,
avec Insomnia, des choses comme ça.
Et je sais que lundi,
quand je vais commencer,
ça va être totalement différent,
avec un audit de sécurité
sur ce qu'on a mis en production hier.
Parce que je dois vérifier des choses.
C'est très souvent dans mes journées,
ça ne se ressemble pas.
Mais mon quotidien est très accès
sur la récupération d'information,
résoudre des problèmes
qui peuvent être bloquants,
et rendre aussi autonome l'équipe.
Ça c'est bien un peu tout
dans mes journées en ce moment.
Ouais.
Ce qui est bien de rappeler,
c'est justement quand on avait fait
un épisode de podcast
sur la production et l'exploitation,
c'est quand on travaille
en mode DevOps,
comme on a automatisé beaucoup de choses,
il y a pas mal de choses
qu'on fait plus tout le temps,
et tous les jours.
Et donc ça nous laisse du temps
pour faire du projet.
Et on fait à la fois des choses récluantes,
et donc du maintien en condition opérationnelle,
et aussi du projet.
Est-ce que tu le vois,
cette répartition dans ton métier ?
Je dirais oui.
C'est vrai que justement,
du fait que j'ai pu automatiser
la récupération d'informations,
le monitoring,
mais aussi rendre autonome
l'équipe pour qu'ils aillent voir,
c'est vrai que je peux beaucoup plus me focaliser
sur le gros de la création
de cet API pour l'entreprise.
Et c'est vrai que si il n'y avait pas les autres idées DevOps,
je serais pas là,
par exemple, pour prendre ce temps,
pour te parler.
Ça peut jouer.
Et je suis plutôt d'accord avec toi.
L'automisation des choses,
créer une plateforme,
et même tout ce qui va avec.
C'est-à-dire que c'est ce que l'on prend soin de nos développeurs,
tout ce qui est CIercidi,
tout ce qui est image,
tout ce qui est récupération d'infos.
Si tout cela, c'est clair pour tout le monde,
ça rentre autonome les gens,
ça marche tout seul,
ça fonctionne,
il dit qu'on se bloque,
et ça peut bloquer,
et ça va bloquer,
là on va payer,
effectivement, c'est tout à fait normal.
Mais c'est clair qu'après,
ça me dégage beaucoup de temps
pour me focaliser sur les projets futurs
et anticiper,
notamment l'anticipation sur le cloud
pour les HDS,
quand Codoc va proposer ses services
sur le cloud
pour d'autres structures médicales,
et surtout améliorer en fréquente
encore et encore ce qu'on propose.
Parce qu'il y a des intérêts,
le service fin de Codoc,
c'est qu'en fait,
les chercheurs peuvent créer
des espaces sécurisés.
Donc il peut quand il créer une cohorte
avec des données,
ça va, c'est assez fort,
donc c'est Alitec qui a créé ça,
qui s'appelle Marie,
beaucoup,
donc en fait, il y a Dr. Warehouse,
le chercheur, le chérantien,
le professeur va faire une recherche
sur tel hôtel malasie,
et va faire une cohorte
avec la recherche,
avec Dr. Research,
donc il fait sa recherche,
et après, en fait,
il va dire,
voilà, je voudrais faire une recherche,
je voudrais faire une recherche
sur, par exemple,
sur l'aminos là-dessus,
il me faut telle personne,
et cetera, je ne sais pas si des détails,
et là, ça va lui créer un workspace.
Et ce workspace,
il va être automatiquement déployé
dans un conteneur
lorsqu'il en fera la demande.
Bon, il y a plein de choses administrativale
que je passe,
sinon ça serait trop long expliqué,
mais rien que ça,
rien que ça,
le fait que ça se passe bien,
il faut pouvoir,
il faut pouvoir,
on a cette petite phase de stress,
qui se dit, est-ce que ça va bien marcher?
Parce que,
comme c'est de l'un primise,
il ne faut pas oublier,
la machine,
la VM est extrêmement sollicité,

ces données,
même RAM,
CPU, tout,
et au bout,
et donc ces chercheurs,
il n'y en a pas qu'un dans un hôpital.
J'étais d'ailleurs impressionné que,
je ne savais pas que pour la recherche en France,
autant de gens étaient investis.
C'est d'ailleurs une des raisons
pourquoi je suis psychodocs,
c'est que j'ai l'impression que,
d'ailleurs chaque déploiement,
d'ailleurs chaque configuration que je fais,
j'ai l'impression de sauver une vie.
Et ce n'est pas des blagues.
C'est vraiment,
c'est vraiment un entreprise qui a du sens,
parce que c'est vraiment le but
d'étter les chercheurs de la même manière.
Donc, ces espaces de recherche,
en fait,
qui sont déployés,
ils demandent de la ressource,
et il faut s'assurer qu'ils ne cassent pas.
Il faut s'assurer surtout,
c'est là où on intervient,
qu'une fois que la recherche est terminée,
que ces données soient détruites,
parce qu'il y a des données de gens,
de patients.
Et donc ça,
le fait que c'est automatisé,
c'est que ça nous laisse beaucoup de temps
pour nous focaliser sur d'autres choses,
sur le futur qu'on peut faire.
Tout en gardant,
et ça c'est moi qui fais un peu le garde-fou là-dessus,
une observation sur l'environnement
que nous avons dans les hôpitaux,
et dire,
il faut peut-être améliorer ça.
Ça, il faut peut-être améliorer.
Il y a un correctif à faire.
Mais vous inquiétez pas,
on va se m'occuper,
on va corriger.
Donc, il y a des outils que j'ai mis en place,
notamment SNCC,
par exemple,
des choses comme ça,
beaucoup d'observation.
Et le but, c'est que,
allez, on se focalise maintenant
sur des nouveaux services
ou améliorer ce qu'on a.
Je suis d'accord.
L'automatisation des choses
aide beaucoup
à créer
une nouvelle feature,
une nouvelle projet.
Alors, t'as parlé, justement,
t'as parlé de la veille tout à l'heure.
Tu commençais ta journée
pour part de la veille.
Et du coup,
ça me permet de te poser la question.
La veille,
est-ce que c'est important pour toi?
J'ai compris.
Oui.
Est-ce que ça t'aide
dans ton métier,
est-ce que tu le sens?
Et est-ce que pour toi,
tu le comptes
dans ton temps de travail
ou pas?
Et color,
à l'air à ça,
est-ce que tu conseilles
aux novices qui commencent
de faire de la veille quotidienne
ou au moins hebdomadaire?
Ouais.
Oui, c'est ce qu'il y a hebdomadaire.
Alors,
ce n'engage que moi.
J'ai une maman
qui m'a toujours dit,
mon fils,
c'était responsable de tout développement.
C'est-à-dire,
moi, je considère que la veille,
c'est pendant les heures de travail
ou même en dehors.
On a tous aujourd'hui,
la chance d'avoir des produits immobiles,
c'est-à-dire des téléphones,
on les ouvre, on peut en avoir.
Donc, la veille, c'est important.
Ça touche pas mal de sujets.
En ce moment,
c'est beaucoup les sujets
qui touchent la santé,
notamment
sur tout ce qui est référencement,
surtout ce qui est HGH,
le LF Tata Hub,
des choses comme ça.
Mais aussi,
il y a un Reddit que j'aime bien,
le Reddit DevOps
que je vais bien regarder,
qui me donne souvent
des informations
très intéressantes,
très pertinentes.
Je regarde beaucoup de webinaires
ou de rapports de webinaires
qui y a eu
sur des technos.
Et enfin,
je parcours un peu
les médiums,
je parcours un peu
les blogs qu'il y a,
et quand je compte
sur des articles intéressants,
je me les bookmarque
pour le lendemain.
Donc, la veille,
j'en fais beaucoup.
C'est le matin,
c'est ce que j'aime bien faire au calme,
et je conseille à tous,
en fait,
de le faire.
Pour plusieurs raisons,
la première est évidente,
c'est pour se tenir informé
de ce qui se passe, en fait,
dans notre écosystème
et autour de nous.
On n'est pas à l'abri
d'une version,
je ne sais pas,
de Buntu qui change,
ou d'une faille de sécurité ici,
par exemple.
Ça peut être aussi
une nouvelle technologie
qui émerge,
il faudrait peut-être prendre le pas
et se tenir informé.
Je parlais de tout à l'heure
d'Onomad,
qu'aujourd'hui,
il y a des gens disques,
ça va concurrencer Kubernetes.
On sait qu'aujourd'hui,
que Kubernetes,
il faut s'accrocher
pour concurrencer,
parce qu'il est fortement ancré.
Mais il faut garder à l'œil,
c'est comme à l'époque,
pour Podman,
Podman,
pas trop de monde
y croyaient,
finalement,
il y a des gens qui demandent
Podman,
notamment chef, par exemple.
Tous ces outils d'automatisation,
le but,
ce n'est pas de les connaître
par cœur,
parce que, comme je dis au début,
le dévops,
la méthode du dévops,
ce n'est pas de connaître tout,
c'est de connaître un peu tout.
Mais, en fait,
les choses qui sont cœur dévops,
parfois, je navigue un peu
dans les choses qui ne le sont pas.
Des fois,
je vais regarder,
tiens,
en ce moment,
nos applications sont avec View,
avec Sellerie,
ce sont des choses
que je regarde beaucoup.
Et je regarde un peu
les projets qui tournent
autour de ça.
J'essaie de comprendre
comment ça fonctionne.
Oracle,
les bases de données Oracle,
que je n'ai pas touché
depuis très longtemps.
C'est pareil.
Donc, en fait,
je veille souvent
autour,
je dirais,
des environnements
que d'habitude,
ne le sont pas.
C'est-à-dire,
je me mets en situation
d'inconfort total.
Parce qu'on n'est pas
à l'abri demain
comme mes amis
ou même collègues
ou même
une personne sur un forum
ou sur X
dit,
tiens,
voilà,
j'ai des problèmes
sur ce sujet-là,
je n'arrive pas à avancer.
Peut-être que moi,
j'ai la réponse.
Parce qu'on a la méthode
pour aller chercher,
en fait, le problème.
Comme je disais,
des build-up,
c'est un peu des personnes
qui ont encapsé
des résoutes,
des problèmes.
Et c'est ça
qui est important.
Donc oui,
je pense que même
en dehors de son temps de travail,
il faut tout de même
prendre du temps
pour faire de la veille
et surtout,
s'intéresser pas
uniquement
aux technologies
et tout ce qui est technique.
Il faut aller un peu
dans le légal.
Il faut aller aussi
un peu s'intéresser
avec
qu'est-ce que font
les éditeurs
des logiciels
que nous utilisons.
J'ai bien aimé,
par exemple,
la vidéo que j'avais fait
sur Copilot
de GitHub.
Tu vois,
c'était intéressant
de s'interroger
sur
les licences libres,
comment ça s'appuie.
Oui,
ce genre d'interrogation,
ça permet de se dire
peut-être pas mettre
tout notre code
n'importe où,
etc.
Et ça permet de,
en cherchant encore une fois
de se dire,
mais quelle solution
je peux trouver à côté.
Et encore une fois,
on voit que d'autres personnes
pensent pareil
ou d'autres pas,
il faut un peu naviguer
en dehors de la boîte,
thinking out of the box.
Il faut des fois
pas rester.
Et donc,
c'est uniquement
pendant son temps libre
qu'on peut faire ça.
Je ne dis pas de faire tout le temps.
Il faut prendre du temps
comme je disais de tout à l'heure,
le work-life à l'ordre,
c'est important.
Mais je dirais,
pendant ce temps de travail,
c'est clair,
il ne faut pas hésiter
à être proactif
et à communiquer avec vos responsables
et dire, voilà,
là, je vais prendre une heure
ou deux de faire de la veille,
le mettre dans votre emploi
du temps.
Ça, encore, c'est une méthode,
c'est-à-dire,
c'est important d'avoir un positionnement
et d'être prévenant.
C'est-à-dire, voilà,
pendant une heure, là ou deux,
je fais des recherches là-dessus,
mais je ne suis pas sur ce sujet.
Mais on reste disponibles.
Mais, je veux dire,
rien ne vous empêche de prendre
une demi-heure
ou une dix minutes,
quinze minutes par là
pour prendre des informations.
Et enfin,
il ne faut pas hésiter aussi
un peu à se renseigner
sur ce que font les dévops
dans d'autres pays.
Moi, j'aime bien faire ça.
Je regarde les dévops
qui en Asie, par exemple,
qui ont une méthode de travail
extrêmement très axée
à WVS.
Vous avez les Américains,
qui eux,
qui ne jouent uniquement par Google,
qui terraforment des choses comme ça.
Et en fait,
de fil en aiguille,
on découvre qu'ils ont une autre méthode
de travail.
Et en fait,
on se rend compte que nous,
je me suis rendu compte
que je ne fais pas les fichiers
de trafic,
comme peut faire,
par exemple,
quelqu'un dans une autre zone géographique.
Je suis pas sûr,
c'est des fois,
on se rend compte que les gens
ont réussi à compacter
leur code
pour faire la même chose qu'on fait.
Et là, tu te dis,
oui.
Et donc, forcément,
s'en veille,
on ne peut pas avancer la chose.
Donc, c'est important de
se mettre en mode beta.
Je dirais qu'on n'est jamais
un DevOps,
ou un admin-system,
ou quelqu'un qui travaille
dans un domaine,
sans se mettre en mode beta tout le temps.
On n'est pas des experts.
Ça, c'est un truc qu'on entend souvent.
L'expert cloud DevOps,
je ne suis pas un expert.
Il faut être expert d'une chose,
il faut l'avoir créé
et aller au bout des choses.
Et dans notre métier,
comme on doit tout un peu connaître,
il faut aller au bout
dans le détail des choses,
mais c'est très large le panel.
Donc, la veille,
c'est super important.
Super important.


Oui, c'est d'accord.
Moi, j'ai tendance à considérer
qu'il y a deux types de veille,
comme tu le dis,
il y a la veille que tu dois faire
pour ton métier,
pour ton employeur,
celle pour laquelle tu es payée.
Elle,
il faut l'incluer dans ton temps de travail,
c'est obligatoire.
Et puis, quitte en plus
à partager la veille
avec tes collègues
et chacun va explorer
un bout ou un domaine.
Et après,
vous échangez les meilleurs trouvailles.
Ça, en plus,
ça peut être partager la veille.
Mais tout ce qui est autour,
ce qui n'aide pas forcément
ton travail au quotidien,
mais qui t'intéresse
autour de la tech,
ça, en effet,
peut-être qu'il faut le faire à côté.
Et moi,
à un moment,
c'est plus facile
parce que je suis freelance,

j'ai compté rendre à personne.
Je me donnais une heure par jour,
en fait,
je commençais tous mes après-midi
par une heure de formation
ou de veille.
Donc, là,
j'ai dû arrêter
à cause de Frogit,
qui est un gros projet
qui me prend beaucoup de temps.
Mais l'idée,
c'est d'avoir
une hygiène quotidienne
ou hebdomadaire de veille.
Pas mensuelle.
Mensuelle,
c'est trop large.
C'est aussi pour ça
qu'on sort un épisode de podcast
tous les mois
pour vous aider aussi
à faire votre veille.
Tu nous as parlé
de gros projets,
là,
que tu mets dans ce moment.
Est-ce que tu veux nous en dire
un petit peu plus,
quelques mots,
rentrer un petit peu plus
dans le détail ?
Alors, comme j'expliquais,
je fais très vite.
Un codec
crée un panel de services
pour accélérer la recherche
au sein des hôpitaux.
Donc,
vous avez des produits
et des services
qui s'appellent le Dr. Keur,
le Dr. Warehouse,
le Dr. Arnault,
le Dr. Risser,
le Dr. Risser,
et à Anonymous.
Il y a plein de services.
La base,
c'est que
un chercheur,
un professeur
ou un médecin
peut lancer
un projet de recherche.
L'objectif,
c'est d'arrêter
un peu les rangs de diagnostic,
donc accélérer les diagnostics,
accélérer la recherche.
Pour moi,
c'est ce
que j'entends.
Quand j'entends ça,
j'entends du ça,
je trouve ça incroyable.
Et après,
les données restent
totalement anonymes,
des choses comme ça.
C'est-à-dire que
il y a vraiment des services
qui ont été créés,
notamment Anonymous,
ça s'appelle le Dr. Anonymous,
c'est pour complètement anonomiser
les données en fait
de compte des patients.
Et à côté de ça,
on a créé un autre service
qui s'appelle Arnault,
qui est connecteur francs connect,
qui permet en fait
de demander en fin de compte
les droits,
consentement des patients
et qui est un des services



qui ne veulent pas,
c'est un droit d'opposition
qui sont retirés de la recherche.
C'est extrêmement carré
et réglementé
et vraiment,
ça a de très, très bon retour
au sein des LHU de travail.
Là aujourd'hui,
comme je disais,
on a de plus en plus
d'hôpitaux en fait
de compte avec qui on est partenaire.
On nous a envoyé des hôpitaux
comme Foch,
vous avez aussi d'autres hôpitaux
que nous travaillons
dans le fonds-sur-la-de-Saint-Anne,
qui est récent.
Donc il y a l'esthétie psychiatrique.
Donc il y a pas mal
et en fait les hôpitaux sont,
je dirais,
il commence à avoir pas mal
qu'on déploie.
Vu que là,
j'en ai mis en monitoring
3 en l'espace de 2 mois,
ça montre que les déploiements
offerent une mesure avance.
Donc au bout de l'an moment,
il va y en avoir beaucoup trop
et surtout,
on va avoir besoin
de pouvoir,
comme je disais tout à l'heure,
il est quitte data.
Elle va avoir besoin
de enrichir les données,
il va avoir besoin de créer
des nouveaux connecteurs
et de voir lesquels fonctionnent
ne fonctionnent pas.
C'est ce qu'on appelle
des DAG.
Donc c'est une technologie
qui s'appelle Airflow.
Donc c'est des conteneurs
qui sont complètement connectés
avec une API.
Et donc,
ils créent des DAG.
Et donc vous avez des
plans NLP
qui sont balancés
et qui enrichissent les données,
qui est extrême,
qui récupèrent.
Donc il y a beaucoup,
c'est très sollicité.
Et donc la complication,
c'est que si on l'a pour l'instant
avec 3 hôpitaux,
ça génère des heures
et des heures
le matin pour que chacun
de l'équipe data,
chaque data ingénieur,
qui est normalement payé
pour créer des connecteurs
et non pas les récupérer
l'information de la veille
si son connecteur a fonctionné.
Donc,
je suis dans le travail
sur ce qu'on appelle
Codec API.
Et l'objectif,
ça va être d'aider l'équipe data
à pouvoir récupérer
cette information
avec une API
qui a été faite
par l'équipe app
Codec
et à côté,
l'équipe de data,
elle,
utilise Airflow.
Donc je dois,
je crée une gateway
qui va récupérer
les informations de la pays
de nos services
et cette Airflow.
Sauf que,
sous le niveau,
les hôpitaux
se sont les environnements
extrêmement sécurisés.
Normalement.
Et là,
avec ce qu'on travaille,
je peux vous garantir,
ça l'est.
Et donc,
nous,
on est obligés
de se soumettre
à leur,
si on veut,
leur règle de sécurité.
On ne peut pas se permettre
de faire des requêtes
dans leur infrastructure.
On ne peut pas.
Ça se fait pas,
tout simplement.
Donc,
il a fallu travailler
sur quelque chose de différent.
Donc aujourd'hui,
je travaille sur un service
avec,
pas trop,
trop,
trop, trop,
trop,
trop,















trop,

















trop,









trop,
trop,
la première,
c'est que...
déjà,
ă le datat
brehu,
ễ r
cl
tout ça, ça c'est la première chose. Et enfin c'est l'hôpital. C'est l'hôpital
qui ont travaillé. Eux, ils n'ont pas continuement sur leur recherche et ils ne savent pas quand
c'est cassé. Pour eux, ça continue à fonctionner. Ils ont pas un retour 400K, ils n'ont pas une
erreur 500 ou une bête des touais, quelque chose comme ça. C'est nous qui avons cette
réponse, ça va. Et à fait, on ne peut pas se rendre compte quelques heures plus tard
ou un lendemain ou même des jours plus tard qu'il y a des connecteurs qui n'ont pas
fonctionné ou pire. Des connecteurs qui ont pris des heures et des heures et des heures
à traiter des données. Donc là aujourd'hui, l'objectif c'est vraiment récupérer, vu
qu'on va avoir plein de sites, c'est récupérer dans un endroit centralisé des informations
pour nos équipes d'ATA. Donc ça passe, ça passe. Je pense que nous les évoires sont
travaillées beaucoup sur les API grâce aux get-away. Donc j'avais déployé une API
get-away avec un % employeur sur Amazon dans le domaine de la data mais pour des tickets
et des caisses, j'utilise un peu le même mindset, c'est-à-dire je vais récupérer
les API et puis je vais les mettre s'ingisons, truiscuels dans une base de données et puis
c'est aux équipes directement de regarder ce qui a fonctionné ou pas. Donc il y a pas
mal de techno dans cette architecture. Je dirais le service de client, il est HCP. La VM
de déploiement est dans l'hôpital, il y a un tunnel qui est entre la VM de déploiement
et la VM qui est HCP. L'écosystème qui est au sein de l'hôpital, lui, il communique
tout entre une environnement fermée. Et donc on ne veut pas récupérer les informations
des recherches. Ce n'est pas ça qu'on a besoin. Ce qu'on a vraiment besoin, c'est
de savoir est-ce que nos connecteurs ont fonctionné. Ceux qui ont fonctionné, est-ce
qu'ils ont créé quelque chose ? Parce que des fois dans les ETA, des fois, oh ben tiens
j'ai lancé un truc là mais il n'y a rien au bout. Si il n'y a rien au bout, ça veut
dire que peut-être le DAG n'est pas bon, donc il faut le revoir. Donc ça a amélioré
en fait contre les microservices et les produits que nous avons. Et ça a l'air toujours
la recherche. Il faudra attendre les prochaines communications. Moi je ne cuse pas de ça chez
Kodok mais il y a eu deux, trois effets wow et notamment un hier que ça fonctionne.
En plus, c'est vraiment ça qui est intéressant. Et si on arrive à mettre ça en place, on
peut aller encore plus loin sur des pathologies ou des maladies rares qui sont beaucoup plus
dures à diagnostiquer, éviter les arronces de diagnostic et je trouve que ça réunit
en nom du sens. Non seulement on fait un métier passionnant dans le domaine de l'analyse
système du DevOps et si en plus on peut à côté sauver des vies, c'est top. Ce
quoi je travaille, Kodok API, c'est vraiment le nerf de la guerre. Je ne suis pas tout seul
à le faire. Il y a la lead tech qui travaille avec moi ainsi que le lead backend de développeur.
Moi je me charge plutôt du déploiement de la chose, de la sécurité. Après tout ce
qui est gestion des jetons, tout ça, entre les deux je vais mettre un volt parce que
moi les modifications c'est quelque chose qui m'est en panique. La sécurité c'est
très important. Et en fait compte, le backend se prend des bases de données, il a fait le
format de données, des choses comme ça. Et la lead tech, elle se tue un peu de piloté.
Quelqu'un d'extrêmement motivant et engagé dans ce type de service. Donc c'est le gros
bébé qu'on doit sortir, j'espère fin novembre ou fin décembre.
Alors c'est marrant parce que ça me fait penser à plein de choses. J'ai l'impression
qu'il y a une partie de votre infra qui est dans cloud, celle que tu as décrit dans GCP.
Il y a une partie qui peut être un peu considérée en tout cas, moi que je vois comme du edge computing,
c'est à dire une partie déportée qui est dans les hôpitaux. C'est ça que j'ai compris,
j'ai peut-être pas compris, mais qui est dans les hôpitaux et les deux communiquent.
Est-ce que j'ai bien compris ? Alors la seule chose oui c'est bien ça. C'est à
dire que les hôpitaux sont en environnement fermé. Mais on a une machine de rebond qui
elle ne remonte uniquement les informations de monitoring qu'on a besoin pour déployer et avancer
qui les remonte à notre machine centrale qui est sur GCP. Et en fait, sur cette machine là,
en fait, on ne fait que du monitoring et on en récupère les informations. Mais les hôpitaux,
eux, ont l'environnement bien à eux. Et il n'y a que cette machine de rebond là qui est connectée via
uniquement un seul port. C'est à dire il n'y a pas assez filtré, c'est extrêmement filtré. Des fois
même, malheureusement, voilà pareil, ce qui est bien avec Xavic, j'en parlais tout à l'heure,
on peut monitorer lorsqu'un port, lorsqu'un protocole ne fonctionne plus. Bon des fois,
je ne sais pas quand je reçois une alerte que le port en question ne fonctionne pas. Et
ben je sais que c'est à l'hôpital, il y a peut-être eu un problème de firewalling ou alors la
machine de rebond ne marche pas. Il y a pas mal de choses. Donc aucune des informations des hôpitaux
liées à leur recherche ne remonte. C'est vraiment que l'information des VM et des services,
des fréquentes des applications qui remontent.
Merci. Je pense qu'il y a beaucoup de choses à faire avec des infras comme ça. Nous on y pense
pour rendre nos sas dans le futur, avoir une infrastructure centralisée dans le cloud et
puis un serveur, un petit serveur ARM chez les clients directement dans leur locaux qui
communiquent pas forcément tout le temps avec les serveurs centralisés mais au moins qu'on puisse
mettre à jour régulièrement. Ça me fait penser à ça. Je trouve ça super malin. Et l'autre
question que je voulais te poser, est-ce que t'as regardé du côté du produit qui s'appelle Boondari
chez Hickor? Parce que tout ce que tu m'as expliqué tout à l'heure sur les notions d'authentification
d'appli, etc. Moi ça me fait penser à Boondari. Bon, Boondari, j'ai pas vraiment suivi le sujet.
L'authentification c'est quelque chose qui est important, c'est clair. C'est pour ça que tout ce
qui est gestion des tokens plus d'identification, parce qu'on sait un token, un login, voilà. Et
j'avoue que le vault, une fois qu'on est allé au bout des choses, c'est déjà costaud, très costaud
à mettre en place. Mais en même temps c'est un gage de sécurité. Encore une fois, lorsqu'on
est allé au bout des tokens, on se dit qu'il y a une entreprise ou un partenaire. Vous inquiétez pas,
au niveau de l'authentification, on a ce qu'on appelle une technologie qui s'appelle vault et si
on arrive à l'expliquer correctement, c'est là où encore l'agilité DevOps aide vraiment lorsqu'on
parle avec des DSI ou avec une directrice financière ou un directeur financier, pardon,
X personnes qui ne connaît pas forcément techniquement. C'est-à-dire vulgariser la
technologie. Ça c'est un atout qu'on a, parce qu'on sait exactement comment ça fonctionne. Donc
il faut vraiment trouver des analogies pour que ça fonctionne. Bonne nari, je ne vais pas regarder
d'ailleurs, je suis un peu passé à côté. J'ai vu qu'il y a eu l'HC Corp con fréquemment. Je ne
suis pas suivi. Je pourrais me dire en plus, c'est quoi le topo ? Je pense que ça pourrait t'aider
en plus. Donc c'est un produit HC Corp qui est sorti il y a deux ans, parce qu'on en avait déjà
parlé dans Radio DevOps il y a deux ans. Je ne l'ai pas essayé, mais c'est un produit qui promet
de faciliter les accès au service sans SSH, sans VPN, parce que c'est une bonne nari qui s'occupe
justement d'autoriser l'accès ou pas à un service. C'est un logiciel comme tout ce que fait HC Corp,
il y a une partie libre, une partie sous licence. Donc peut-être que tu devrais aller voir, ça pourrait
peut-être accélérer des choses pour vous. J'ai une autre question pour toi. C'est les études
que tu as fait. Quelles études tu as fait justement et selon toi, quelles études pourraient faire les
personnes qui voudraient faire le métier que tu fais aujourd'hui ? Crochet haut. Je suis né en France,
mais j'ai grandi à l'île de la réunion. Mon père est indien et ma mère est perse.
Et, qu'est-ce que j'ai fait ? On va dire que j'ai arrêté l'école à 16 ans et j'ai travaillé dans un
magasin de jeux vidéo et informatique qui s'appelait Game City à la réunion. Et je réparais et je
construisais des consoles et des machines d'arcade. J'adorais l'électronique à la base. Mon patron
de l'époque, qui est aujourd'hui un mentor pour moi, Eric, m'a dit qu'il faut un diplôme. C'est
difficile aujourd'hui, s'en diplôme d'aller loin. J'ai fait un cursus scolaire qui peut paraître assez
atypique. J'ai fait un bac très simple, science-commodique sociale. J'ai fait un candidat libre.
Ce n'est pas facile pour moi que j'ai eu au deuxième coup. Et après, j'ai fait l'électro-technique.
Technique, système automatisé. Et à la fin de compte, j'ai toujours à regarder à côté, toujours
passionné par le code et par les machines. C'est pour ça qu'aujourd'hui, avec beaucoup de recue,
je m'étais dit à quelques temps que c'est normal que je suis arrivé dans ce métier,
c'est que j'aime beaucoup les machines. J'aime les retro-machines. Mon premier ordinateur est un
Commodore 64 qui est branché dans mon noix de salle là-bas d'ailleurs pour que ma fille puisse
s'amuser de temps en temps. C'est là-dessus où j'ai fait mes premières armes et offert à mesure de
les faire en émise. Donc mes études, je les ai arrêtées au profit de tout de me jeter dans
l'expérience. Je dirais que le temps de ma jeunesse a été un voyage aux États-Unis.
Là où j'ai vu que c'est vraiment les compétences qui jouent. Et toujours dans le domaine de l'électronique
et de l'informatique. J'ai fait un peu de tout dans ma vie. À ce moment-là, je n'ai toujours pas de
validation en termes de développeur aux ingénuries. J'aime toujours ça. Je suis passé par de la
vendance dans le domaine de l'informatique, par de la formation. J'ai été conception de la formation
chez Microsoft à une époque. J'étais ce qu'on appelait un Windows Guru. Et après, je serais
chez Apple pendant du temps. Mais lorsque j'étais, comme j'ai expliqué, lorsque j'étais chez Apple,
j'avais commencé à faire de la blockchain, j'avais commencé à toucher des development,
tout ça. J'ai tout de même fait une formation certifiante en tant que développeur iOS. À la
base, je voulais faire des applications pour iPhone. J'en ai fait quelques-unes. Mais très rapidement,
je me suis rendu compte que j'ai du mal en tant que designer. Je vous que le design,
je ne suis pas très bon. Et juste après, j'ai fait une VAE en fin de compte dans le domaine du
cloud computing, en fait, l'ingenieur cloud. C'est ce que j'ai marqué. Et je dirais que je me suis
beaucoup certifié. C'est pour ça que je disais au début, je citais ma mère, c'est qu'à quatre,
elle me disait, elle me dit toujours, t'es responsable de ton développement. C'est-à-dire qu'en fait,
c'est bien d'aller à l'école, il faut apprendre, il faut y aller à fond, tout ça. Mais à côté de ça,
au niveau du monqueursus scolaire, j'avais toujours, je dirais, il ne faut pas être super
intelligent, mais il faut être passionné, il ne faut rien lâcher. Et la passion était là. Mais je
savais que je fallait que je comprenne comment ça fonctionne. Donc, je n'ai pas hésité à me
certifier. Donc, certification en iOS, je me suis certifié dans tous les domaines Apple. Donc,
les certifications sont finies. Mais je connais très bien l'écosystème Apple,
parce que j'y ai travaillé pendant très longtemps. Et juste après, je me suis lancé dans des certifs
que propose en fait compte aujourd'hui nos providers. Donc, là récemment, il y a juste AWS,
c'est relativement, je dirais, pas simple, mais je dirais un peu très demandé. Azure,
j'ai une certification Azure DevOps. Et en fait compte, lorsqu'on commence à engranger en fait compte
ce genre d'informations, c'est là, on se met ça. Je dirais qu'aujourd'hui, si vous voulez vous
lancer dans ce métier, il faut tout de même des bases informatiques très fortes. Il faut bien
s'y connaître en système, que ce soit Windows, Linux et Mac. Mais Linux quand même, unix,
mais surtout Linux, très important, je trouve, pour du DevOps. Il faut connaître ces systèmes,
c'est là-dessus qu'on fait les images, il a su que c'est déployé, aujourd'hui dans l'industrie,
que c'est utilisé. Et donc après, il faut peut-être aller dans un cursus scolaire qui est très
axé développement. Je pense que aujourd'hui, on est dans un très beau pays où il y a énormément
d'établissements de formation où on peut y aller. Il faut vraiment payer les coins. Mais il faut bien
les choisir. Il faut avoir la tête bien sur les épaules et dire bon, parce qu'on va émettre de
l'argent, donc il faut y aller. Et après, une fois qu'on a un diplôme, moi j'ai l'équivalent d'un Mac
Plus 3. C'est pas hyper diplômant, ce que j'ai. Mais par contre, j'ai un panel de certification
et j'ai un panel aussi d'expérience. C'est-à-dire que dans mon précédent employeur et avant,
je travaillais beaucoup dans la cyber sécurité. J'ai déployé des socs, j'ai mis en place des
siemes, j'ai même précaudé un siem, j'ai travaillé sur des technologies Kafka, des choses comme ça.
Et donc tout ça, ça va permettre, en fait, je dirais, lors d'entretien ou lors de recherche,
d'être légitime en fin de compte. Mais ça passe forcément par se documenter. Et au bout
de mon, c'est bien de se documenter, mais il faut passer le pas de la certification. J'encourage
vraiment les jeunes et les moins jeunes lorsqu'on touche à une technose d'aller se certifier
quand vous avez le temps. Et en prenant votre temps, slow down, tout go fast, ça ne veut pas dire que
ça, c'est un truc que j'aimerais dire. C'est pas en ponçant une documentation pendant trois mois et
vous disant tiens, je passe ma certif sous la jambe, qu'une fois qu'on l'a passé, c'est en expert,
j'ai plus besoin. Je pense qu'il faut vraiment aller au bout des choses, maîtriser vraiment la
technique jusqu'au bout. Et moi, je parlais non exemple propre. C'était l'été, j'ai essayé ma
certification VOLT, VOLT associé, et je l'ai raté de quelques pour cent. Donc ça m'avait un peu
surpris. Et en fait, ils vous font un récap. Ils vous font un récap et vous disent où est-ce que vous
avez pêché. Et moi, en fait, ça m'a surpris, mais j'ai pêché en fin de compte sur l'architecture.
Et je me suis dit, il faut que je grotte. Donc je me suis dit, je vais là, je vais repenser la dog,
je vais retravailler, je vais le refaire sérieusement et je me dirais l'année prochaine, je vais refaire
l'entrée. Il faut prendre son temps. Rien ne sert de pressivité. Donc je pense que au niveau
bagage scolaire, il faut tenir un bagage scolaire, je dirais assez large, on peut venir des économies
sociales ou moi je connais quelqu'un qui est dans le littéraire qui le fait, etc. Il n'y a pas de
règles, mais quand même, il faut aller après dans un cursus technique assez rapidement et de
développement, toucher un peu à des langages et même se trouver un langage. Moi, personnellement,
j'aime beaucoup go et je suis en train d'aller vers le ruste par exemple, mais je conseille vraiment,
on se lance dans le DevOps, on se lance dans l'ingénieur système ou on se lance dans plein de trucs ou
dans le cloud. Il faut tout de même aller dans une école ou une sorte de cursus scolaire où on vous
apprend en fait ces méthodes. Et après, se certifier, c'est super important et se certifier directement
avec le provider. Ça ne mange pas de pain, pas besoin de passer par un tiers, tout ça, etc. Les tiers
pour vous aider à monter. Moi, j'avais utilisé Treehouse, un truc américain, c'est un tiers qui m'avait
aidé à monter sur Java script par exemple et ça donne un mindset. Donc, je pense qu'il n'y a pas de
règles, s'il y a de l'envie, de résoudre de problèmes, il faut forcément un peu de passion dans notre
métier quand même parce que c'est ça. Mais en tout cas, des hautes études d'ingénierie, ça va vous aider.
Ça, c'est un micro-regré que j'ai, c'est de ne pas avoir fait de grandes écoles à ce sujet-là,
là, toujours rien. Parce que je le vois aujourd'hui dans mon équipe chez Kodok, ils viennent tous de
lutter cette compagnie. Ils ont moins de 30 ans parce que je suis le plus âgé de l'entreprise. Et
j'en pense à un là dans ma tête, il s'appelle Andrea. Ils sont bons, pourquoi ? Parce qu'ils ont
eu des excellents profs, qu'ils ont rendonné des bons outils et après, en fin de compte, ils n'ont plus
qu'à les appliquer sur ce que je disais, sur la documentation et sur les certifications. Et donc,
c'est des personnes qui sont déjà prêtes dans les prochaines années sur les technologies de demain.
Et ça me combat encore plus que oui, si vous avez la capsaie de faire des grandes études, faites-le.
Parce qu'après une fois que vous l'en plongez, en fin de compte, dans le domaine des nouvelles
technologies et puis dans le digital, ça marche pas plein. Et à côté de ça, il y a deux profils
dans Kodok, notamment le développeuse Front qui est pareil, qui est un peu le même pur
que moi, qui au début faisait des études de vétérinaires. Aujourd'hui, c'est Aline Front et
elle a fait deux ans d'études. Vous voyez, c'est une question de motivation, mais c'est une question
aussi de se certifier au bout d'un moment. Donc rien ne vous en plaît, je te le pivoter.
Vous voyez, moi, je suis passé de vendeur informatique, dans l'électro-technique,
où je voulais réparer des ascenseurs, etc. Et pivoter, je m'en trouve. Donc je pense qu'on est dans
une époque, aujourd'hui, on peut le faire si on prend vraiment son temps déjà et qu'on est
acteur de son développement, qu'on n'attend pas les choses à faire. Il ne faut pas attendre les
choses à faire, parce que ça invite dans notre domaine. Et si on attend que ça passe,
c'est en 11 démotives et finalement on n'avance pas.
Oui, je suis assez d'accord. Sauf pour la partie certification,
mais je vais expliquer pourquoi. Moi, j'ai un BTS. Je trouve que j'ai un BTS qui date de 22 ans.
Le truc, en fait, c'est que moi, je ne suis pas très certif, parce que je trouve que la certif a une
certaine façon de faire des certifications. Et c'est le chemin de l'apprentissage.
Et je trouve que lui, il est plus important que la certification, parce qu'en effet,
tu apprends quelque chose et tu as un objectif. Alors la certif, du coup, c'est comme l'objectif
d'apprendre un diplôme. Et c'est bien. Moi, j'ai pris une autre voie,
j'ai pris la voie de la création de contenu et de montrer ce que je savais faire. C'est une autre
voie qui est différente. Plutôt que d'avoir des certifs et de passer mon temps à faire des
certifs, j'apprends des trucs et j'essaye de les transmettre. Alors c'est vrai que je transmets un peu
moins de trucs techniques parce que je suis un peu plus sur la culture et tout, parce que je trouve
que c'est ce qui manque aussi dans l'écosystème de contenu. Mais à titre personnel, j'apprends des
trucs et j'essaye de les transmettre. Alors je crée des logiciels libres. Mais le chemin d'apprentissage
est toujours le même que tu passes une certif ou que tu essayes de l'apprendre à quelqu'un.
C'est ce chemin-là qui est selon moi le plus important. Et c'est vrai qu'on en parlait tout à l'heure
de la veille. Il faut continuer tout au long de notre carrière parce que ça évolue extrêmement vite.
Moi je sais que quand j'ai commencé à devenir freelance, c'était Balbus Simon de Docker. On voit
aujourd'hui où est Docker. Il y a Kubernetes qui est passée par là. Docker a été abandonné par
Kubernetes. Il y a plein de trucs. Donc on voit que ça passe vite et pourtant ça fait que,
je sais pas moi, je regarde, ça fait que sept ans que j'ai commencé à m'intéresser à ça.
Donc ça va très vite. C'est ce que je disais au début. Il faut se considérer en mode bêta. Si
vous lancez dans ce métier, si il y a des jeunes et des moins jeunes qui m'écoutent, il faut avoir
une soif de connaissance. Mais surtout, il ne faut pas rester tout pour acquis. C'est impossible.
Et des fois, on se molle et doit quand on pense, je maîtrise ça, je ne vais pas aller plus loin.
C'est dommage. On se tagne un peu. Surtout que c'est passionnant dans le environnement. On travaille
des techno aujourd'hui qu'on découvre et qui sont vraiment, vraiment, vraiment intéressantes.
Il ne faut pas hésiter à ta raison, cheminement qui amène à l'instant. L'instituction n'est pas
obligatoire. Tu as raison. Moi, je trouve que c'est important dans mon cas parce que je n'ai pas de
grand diplôme. Moi, j'ai un peu la même chose. Tu vois, la BTS Electrotechnique,
donc ce n'est pas quelque chose qui m'a pourtant de mention. La RE m'a beaucoup aidé. Mais les
certifications apportent un gage aux employeurs. J'avais hésité à mettre en freelance, mais je me
sens pas prêt. Faut être freelance quand même. C'est beaucoup de gestion. J'en suis sûr. Je le
vois avec mes amis qui le sont. Mais oui, cheminement, c'est d'apprendre. L'instituction
n'est pas obligatoire. Mais il peut être un plus quand même pour des employeurs qui le
demandent. Notamment récemment, j'ai eu une offre d'emploi totale. Ça me demandait des
certifications à droite à gauche. Il y a un peu des recruteurs qui demandent parce qu'ils veulent
vérifier si vraiment on maîtrise la technique. C'est un sujet que j'avais parlé au début.
C'est que notre métier est dans la hype et tout le monde va un peu rebondiquer qu'il veut faire
ce métier parce que ça peut être relativement bien payé. Nous mal payer des fois. Ça, on peut
le payer très cher dans le domaine de la blockchain. C'est ce qui se passe en ce moment. Les gens sont
blockchain ingénieurs et sont payés de misère et des véritables blockchain ingénieurs en
du mal autre du goulot. Je pense que beaucoup d'employeurs ne veulent aujourd'hui comme ils
savent que c'est un investissement quand même. Avoir quelqu'un qui amène la culture de leur
besoin d'entreprise, c'est un investissement. Et avoir un retour sur l'investissement,
il faut s'assurer que la personne ne maîtrise. Et je pense que c'est pour ça que les frances
sont demandées. Exactement. C'est pour ça que c'est demandé. C'est vrai que je ne suis pas dans
cette optique de trouver un futur employeur. Je suis mon propre employeur. Je cherche à trouver
des clients. C'est pour ça que je montre ce que je sais faire. Mais finalement, c'est pareil.
Et à un moment, tu montres quelque chose. D'ailleurs, tu parlais de freelance. Je ne sais pas
ce que c'est, mais j'ai une deuxième chaîne YouTube où je parle d'entrepreneurais et de
freelance cinéa. Je ne le regarderai. Je ne savais pas. Tu peux chercher. Elle est dans les liens de
celle-ci. Tu m'as parlé de ton amour de la supervision. Et ça tombe bien parce que c'est
souvent un sujet qu'on oublie ou qu'on fait à la fin d'un projet. Ce qui est vraiment très dommage.
Est-ce que tu peux nous dire pourquoi tu es motant la supervision et le monitoring ?
Je pense que ça vient de mon côté gamer. Alors, pas gamer, je vis des eaux. Ça vient de mon côté
joueur de jacquard. Je joue au jacquard depuis que je suis, depuis que ma mère m'a acheté
une boîte d'un display d'un jeu de cartes. Et elle m'a mis dans les mains qui m'a dit tu vas voir,
ça va t'aimer. Tu vas aimer. Je n'ai jamais lâché. Et ça a aussi mon côté de résoudre des
énigmes. Ça, c'est le côté joueur donjon et dragon. Donc je suis relis ces jours de cartes. Au moins,
ça s'est dit. Et je pense qu'il y a beaucoup de gens dans la communauté qui le sont. Ça,
j'ai remarqué. Quand tu sors un deck de magic, il y a des gens qui te regardent et tu fais quoi dans la
vie ? Je suis dans l'informatique. Moi, je fais ça. C'est vrai. C'est vérisique. La plupart de mes amies
jouent au jacquard, ils sont tous dans le digital, dans l'informatique ou dans les arts,
peintre ou dans le théâtre. Et donc pourquoi j'aime bien se superviser lors du succès
du jeu d'une application ? Ça vient un peu de ce côté-là où j'ai envie d'optimiser. Et j'ai
envie que ça se passe bien. C'est-à-dire, je veux que ça se passe bien et on veut que ça se
passe bien. Et surtout, il y a quelque chose. Il y a un produit ou il y a un service à délivrer en
fin de compte à un client ou un partenaire. Il faut que ça fonctionne. Mais il faut que ça fonctionne
pendant un moment. Parce que si on délivre et qu'au bout d'une semaine, il a déjà des bugs qui
arrivent là, et là, on s'amuse à faire des fixes alors que c'est en prod. Ça, c'est une première
chose, faire des fixes en prod, c'est tout à fait possible. Si mieux, je vais le faire un peu avant.
Mais ce que j'aime aussi, c'est surtout tout simplement pointer du doigt quelque chose qui n'est
pas dans une baisse practice. Ça permet aussi de monter en compétence les collaborateurs qui
travaillent. Je vais prendre l'exemple que j'ai eu une fois. Ça ne s'est pas produit chez Doigt, mais je
suis un précédent employeur. C'était par exemple des clés. La clé carrément pour du rôle IM pour AWS,
qui donnait des droits de lecture et écriture sur le cluster Kubernetes. Elle était en clair.
Pas de variable d'environnement. Heureusement que j'ai pointé que j'ai vu. J'ai vu. J'ai dit à oublié ça.
Ah, mais voilà. Et le collaborateur, il ne savait pas le faire. C'est un oublie. Donc, en fait,
c'est un c'est ce que j'aime. C'est tout au long de dire. Je n'aurais pas besoin de me répéter pour
les prochaines fois. Garas, ça, qu'est-ce que vous pensez de ça? Je trouve qu'il faut vraiment
mettre une autotoxification ici. Je ne trouve pas ça normal que l'application, par exemple, là,
elle prend quasiment 90% du CPU. Et puis, on commence à faire des recherches et on se rend compte
que c'est le I.O. C'est-à-dire la lecture et écriture sur le CPU. Donc, c'est ce petit détail là.
Ça permet, en fin de compte, comme on dit en le jacquant du jeu de cartes, de tweaker son deck.
Et bien là, non, on va tweaker son application. C'est qu'on va l'améliorer. Et donc, c'est ça.
C'est ça que j'aime bien. C'est se dire au bout d'un moment, on a quelque chose de stable. C'est le but de
notre métier. Le but, c'est quelque chose de stable, de disponible et de scalable. Donc, après, ça veut dire
qu'il faut honorer, en fin de compte, cette promesse. Et ça que j'aime bien. Et donc, il y a l'après.
C'est-à-dire qu'à mon déploie, maintenant, on va observer. Et il y a toujours ce côté-là. On va
garder un œil dessus. Et ce qui est intéressant, c'est de voir comment les utilisateurs vont aller
sur nos services. Et là, on va voir comment on réagit vraiment en fin de compte de notre bébé,
en fait. Et là, c'est ça qui est assez agréable. Et là, on se dit, là, il y a un truc et on va
être proactif. Et proactif, il n'y a rien de mieux. Toujours pour déjà pour les collaborateurs,
mais aussi pour l'entreprise ou le partenaire à qui on a délivré le service. C'est-à-dire,
c'est pas lui qui va se rendre compte que ça ne marche pas. C'est nous qui allons nous dire,
écoutez, nous avons remarqué une consommation ici du CPU sur notre service. C'est ce qui fait
que des fois, vous avez déjà observé des ralentissements. Ah oui, en effet, très bien,
nous allons faire un fixe au weekend. Je peux vous garantir lorsqu'un partenaire, il entend ça,
il fait, attends, c'est vous qui m'éveillent à nous quand il y a des problèmes, ce n'est pas nous.
Il y a une perception différente. Et en fait, il y a cette satisfaction client, on peut le dire,
qui est là, mais aussi de nous-mêmes de se dire, on a trouvé quelque chose. Donc, on est tous là,
se frotter les mains, un problème, on va le résoudre. Moi, j'adore résoudre des problèmes,
donc ça, c'est une première chose. Et une fois que plus on en résoud et plus on fait compte,
on a une raison de bosser. Et en fait, c'est tous les outils qu'on met en place. C'est-à-dire,
toutes les lignes de commandes qu'on connaît, tout ça. C'est-à-dire, ce qu'on a appris,
et on le fait. Et puis, au bout d'un moment, on arrive plus à le trouver. Et donc là, je te parle
par exemple de ce problème qu'on a eu vraiment sur la consommation de CPU, de VIEW, qui utilisait
trop le high-weight du CPU, c'est que j'ai découvert des commandes pour vérifier tout ça.
Donc, c'est là où j'ai découvert le high-o-stable, le high-o-top, des choses comme ça, et que je
pouvais faire des scripts à côté pour vérifier quand ça ne marchait pas. J'ai fait des scripts de
monitoring qui m'envoyaient des alertes au cas où, si ça dépassait un seul, qu'est-ce qui provoquait
ça, et on se rend du compte qu'il y avait une mise à jour très précise à faire sur le kernel de la
machine HGCP, qu'il n'était pas possible à cause d'un agent qui était installé par GCP. C'est-à-dire
que ils ont un observateur qui était installé, on peut même cliquer pour dire installé pour le
monitoring, et on l'a désinstallé, ce qui a permis, en fait, de gagner un peu en high-o-stable, et
apprendre à découvrir qu'il fallait que l'on demande des choses, etc. C'est ça qui est intéressant.
C'est-à-dire en débuggant et en faisant de la recherche sur un problème, on monte en compétences.
C'est inévitable. Et c'est pareil dans le domaine de la sécurité, c'est là où on arrive aussi dans l'étape
d'après. C'est tout ce qui est flattening, c'est tout ce qui est recherche de faille, et donc un outil
automatique qui vous donne les failles, c'est très bien. Super, mais après vous devez falloir
chercher vraiment. Donc c'est vraiment chercher c'est quoi la faille, et comment on rend tout
compatible pour qu'on mise les dangers sur le service qu'on propose. Et donc c'est ça de la merde.
C'est stimulant de se dire là il y a un problème que je vais te résoudre. Pas plus tard que ce matin,
c'était des histoires sur la préprod et la prode. Il y avait un souci de version sur la pays,
on a trouvé que c'était tout le monde un bug d'affichage sur le tag, mais que c'était la bonne
API. Et on s'en rend du compte de ça en une heure, mais au moins ça n'a pas pris une journée pour le
faire, parce qu'en amont on avait mis les outils qui le permettaient. Donc ça qui est assez agréable,
que je dis bien le mot agréable, c'est que pendant le cycle de création, la genèse depuis la
genèse, c'est-à-dire depuis la DAT, la document d'achetiture technique jusqu'à la delivery,
si la culture développe ce qui est du début à la fin, on va pouvoir intervenir sur la sécurité,
sur la supervision de la chose, sur comment on backup, sur toutes les problématiques qu'il peut
avoir, surtout les worst case scénarios qu'il peut avoir, parce que c'est un peu non boulot de
se dire et qu'est-ce qui se passe ici ? C'est what if, tu vois, c'est ça. Et là on fait compte,
on se rend compte qu'on rend sensible l'équipe à ça, ce qui fait qu'après au fur et à mesure,
on va partir sur d'autres sujets et eux ils sont beaucoup plus autonomes, ou même ils vont se dire
là il y a un truc là, on n'est pas sûr, on va aller voir Rama, on va en discuter. C'est ça qui
tient d'interressant.
Oui, c'est bien que tu en parles parce que justement moi quand j'apprends de DevOps à mes élèves,
je leur dis à chaque fois c'est une culture de la meilleuration continue. Et si tu veux améliorer
quelque chose, il te faut de la mesure, il faut mesurer déjà pourquoi ça va pas bien,
et puis il faut mesurer pour voir si ça a été amélioré. Et donc c'est pour ça que les outils
de supervision sont là et nous aident déjà pour collecter des informations pour savoir où
est le problème. Et puis pour voir dans plusieurs semaines, plusieurs mois, est-ce que notre solution
elle a vraiment amélioré les choses. Et la supervision c'est génial pour ça, c'est vraiment
bien.
Très important.
Bon on arrive vers la fin de l'émission, on a déjà dépassé l'heure largement. Je vais te poser
deux petites questions. La première c'est est-ce que tu as un conseil de lecture, un article,
une conférence, même à voir ou un livre à lire à notre auditeur ou notre auditrice ?
Oui, moi j'ai plutôt un podcast conseiller que je viens écouter. Le tiens aussi. Si vous parlez
anglais, je vous conseille de écouter Serverless, très intéressant comme podcast. C'est un podcast
sur un américain et une américaine qui discute, qui invite des gens qui sont dans le domaine,
en fin de compte du delivery ou de toutes les nouvelles technologies que soit cloud on premise.
C'est très intéressant. Il y a quelqu'un récemment de Spotify, c'était franchement Serverless,
simple podcast gratuit. Donc ça c'est pour les anglophones. En termes de lecture, je consérais
vraiment de lire, sur HumbleMumble, il y a eu un livre que j'aime bien qui s'appelle The Black
Ad Playbook. Pourquoi je vous dis de lire un livre là dessus sur Black Ad Playbook avec
Python ? C'est parce qu'à l'interesse de ce livre, on apprend énormément de choses. Déjà,
il y a quelques codes Python à l'intérieur, mais surtout on apprend énormément de choses sur
la manière que travaille un pirate informatique. Et je dis bien un pirate informatique. Il y a une
différence entre un hacker et un pirate. Et en passif de White Hat, je peux vous garantir que quand
on est des hackers, d'ailleurs les ingénieurs, on transforme quelque chose pour faire autre
chose. Donc ça s'appelle Black Hat Books for Python Programmer. Il se trouve très facilement
sur HumbleMumble. D'ailleurs, il y a un gros panel, je me souviens plus de l'auteur. Je l'ai envoyé
un message pour que tu me mets dans la description si tu veux. Et dans ce bouquin, ça m'a beaucoup
apporté parce que ça donne des bonnes commandes, ça donne des bons scripts. Ça vous apprend à
faire des crons de jobs. Ce n'est pas pareil pas, mais des petites bases de faire un petit
cron des fois pour avoir les retours, c'est très intéressant. Donc je considérerai ce petit bouquin.
Merci, j'essaye de toujours mettre des liens en description. Je ne sais pas si tu as remarqué dans
les podcasts, il y a toujours plein de liens. Et où est-ce qu'on retrouve, à part évidemment sur
le forum des compagnons, mais où est-ce qu'on retrouve, est-ce qu'on peut retrouver, est-ce
que tu as envie d'être contacté par les auditeurs ou les litrices qui nous écoutent ?
Vous pouvez me contacter via LinkedIn si vous le souhaitez pour discuter, pour échanger, pas pour
me recruter. Je suis très bien que je suis aujourd'hui. Ça c'est quelque chose que je dis.
Ou alors si vous voulez taper le carton, viens une chaîne YouTube qui s'appelle Cinesio Savantur TV.
Ça fait très longtemps que je n'ai pas mis les choses dessus parce que je suis un gamer de
chaque carte comme je le disais et vous pouvez me contacter via direct pour ma chaîne YouTube si
vous le souhaitez. Ou via LinkedIn ou via le forum des compagnons. Il n'y a pas de problème.
Je vais prendre votre message. Et bien merci à toi pour tout ça. Je mettrai les liens
sur LinkedIn et sur la chaîne YouTube aussi que je suivais, même alors que tu me dis qu'il n'y a plus rien.
Je suis encore abonné. Je crois que YouTube ne m'a pas accepté. Je crois que il y a 6 mois, j'ai mis une
vidéo sur Dune, le vieux jeu de cartes. Mais le boulot plus déménagement, j'ai quitté Paris pour
venir habiter à la campagne, plus déménagement, plus d'enfants qui arrivent. C'est dur de trouver
du temps pour faire du contenu ludique. C'est vrai. C'est vrai. J'ai du mal à faire du contenu tout court
pour les chaînes YouTube. Je voulais ouvrir aussi une chaîne de jeux, mais du coup j'ai abandonné
l'idée parce que sinon je ne le dormais plus. Mais c'est un projet dans le pipe de créer
un fétiment du contenu. Je ne sais pas comment je voulais le faire, mais du contenu où je
montrerais un peu plus les bases, un peu une sorte de vlog de comment je vivais. Mais je vais
attendre 2023 pour ça, le temps que ça se tasse. C'est un truc que je voudrais faire. Ce que tu fais,
c'est intéressant et je pense que t'as raison. Je vois beaucoup de gens sur YouTube qui reposent
beaucoup de contenus, mais trop hards, trop techniques. Ils oublient un peu cet aspect
philosophique, même limite, ou d'idées que peut avoir notre métier. C'est important.
Exact. Je trouve qu'on est un peu trop enfermé dans l'atec et on ne prend pas le
pas de côté pour regarder un peu ce qu'on fait. C'est peut-être ça, tu me diras. Et c'est peut-être
aussi le fait que moi je ne suis pas ingénieur et que je m'intéresse à énormément de choses,
la politique, l'économie, la monnaie, le jaune. Et ça foisonne dans ma tête et du
coup je ne suis pas à fond à fond dans l'atec. Et je trouve que quand t'es à fond à fond dans
l'atec, tu ne mets pas de réflexion citoyenne dans ce que tu fais. Et tu te dis que ce que
tu fais, c'est forcément bien, alors qu'en fait tu ne te poses pas les questions sur l'usage que
va avoir ce que tu crées. Exactement. C'est pour ça que je travaille chez Kodak d'ailleurs.
Comme je le disais avant, il y a eu Total, j'ai eu d'autres groupes et j'ai choisi vraiment
cette startup parce que c'est quelque chose qui m'a touché sur certains détails personnels.
L'érance de diagnostics, c'est quelque chose qui peut arriver à des gens. Et je veux dire que si
je participe à ça, ça a du sens. C'est important. Je suis d'accord avec toi.
C'est important d'avoir du sens. C'est aussi pour ça que moi j'ai créé Frogit parce que ça a
des concurrents américains qui existent, mais l'idée derrière, c'est de proposer autre chose.
Et bien merci à toi. Merci à toi. Et puis ben à très bientôt en tout cas sur le forum.
A très bientôt sur le forum. Merci beaucoup. Bye bye.
My Little Team m'a proposé de créer un job board avec eux. Et comme j'aime leur façon de
faire, je leur ai dit oui. Alors si tu cherches un job, fais très attention à ce que je vais te dire.
Ce job board me permet de te proposer des équipes que j'ai présélectionnées sur
recommandations de My Little Team. En effet, elles ont une culture qui te permettra de t'épanouir.
Et tu sais à quel point la culture est importante pour moi. 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, 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 t'é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.