La transmission de la culture DevOps est un enjeu essentiel dans une entreprise.
Comment transmettons une culture aux nouveaux arrivants ?
Toutes ces questions-là, je vais les aborder avec mon invité du jour.
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 A Parté.
Aujourd'hui, j'ai le plaisir d'accueillir Daniel Castronovo.
Daniel est membre de la communauté des compagnons du DevOps et fidèle auditeur du podcast.
C'est même lui qui me l'a dit et qui m'a contactant pour me faire part de son
invité d'être co-animateur de Radio DevOps.
Du coup, je lui ai demandé si il pouvait nous rejoindre dans cette interview d'En A Parté.
Et puis, on va pouvoir l'écouter.
D'ailleurs, toi aussi, tu peux nous rejoindre.
Il tout suffit pour cela de me contacter directement sur le forum des compagnons.
Si tu écoutes ce podcast, comme tu le sais, il est en licence libre.
Il est en CC Baies.
Tu peux l'utiliser, tu peux découper des bouts, tu peux en faire ce que tu veux.
Du temps qu'en fait, tu sites la source et que tu nous préviennes.
Tu nous envoies un petit message et puis n'hésite pas à le partager parce que tu sais à quel point
c'est difficile de faire connaître un podcast.
Bonjour Daniel, bienvenue.
Bonjour Christophe.
Alors justement, la première question que je vais te poser,
c'est que les gens ne te connaissent pas encore.
C'est aussi l'objet de l'interview.
Est-ce que tu peux te présenter en quelques mots ?
Bien sûr.
Donc Daniel, j'ai 34 ans, ça fait 23 ans que je fais de l'informatique,
dont 11 ans en milieu professionnel.
À la base, je suis un ops avec un mindset DevOps depuis environ 5 ans.
Donc j'ai une expertise vraiment en observabilité, en conduite au changement,
en usine de dev, en durcissement au niveau cq.
J'ai un passif de formateur aussi.
J'ai formé plus de 50 ans deux fois, un nombre de pannelles assez incalculables
de personnes, notamment pour les ESN, mais pas que.
Et mon lettre motif, c'est que j'adore transmettre.
Et faciliter les équipes, le soutien des équipes, pardon.
Donc je suis très orienté, outil, processus,
mais avant tout, est-à-d'esprit, transmission de l'information.
Eh ben merci.
Du coup, vu que tu parles de ça, c'est quoi ta définition du DevOps ?
Alors, c'est très personnel, mais moi, j'adore discuter avec les devs,
j'adore discuter avec le produit.
Et ma définition à moi, elle est très simple.
En fait, c'est comme tout le monde le dit, c'est de casser un petit peu
les barrières qu'on a entre ces différents types de personnalités,
différents types d'état d'esprit.
L'Obsil est beaucoup plus orienté, on va dire, stabilité, automatisation,
sur au niveau de l'infrastructure.
Le développeur, lui, quant à lui, il voit l'accès à son code base,
sa stabilité aussi, son maintien en temps.
Et il y a des notions qui viennent un petit peu casser les murs,
les notions de performance, les notions d'observabilité,
les notions de coordination.
Et le but du jeu, c'est de créer le plus de valeur possible.
Voilà, c'est quelque chose de très simple.
Donc en plus des outils, évidemment, ça, je n'en parle pas,
mais c'est vraiment les fondations, il y a l'outil, l'état d'esprit.
Et derrière, l'objectif, en moindre tant que Coops qui fait du DevOps,
c'est d'aider notamment les développeurs au niveau de leurs propres expériences,
c'est-à-dire de leur mettre à disposition des plateformes les plus simples possible,
les plus stables possibles, et de créer des guidelines autour de tout ça.
Donc le but du jeu, voilà, c'est de se parler au quotidien.
Bon, ben, je pense que j'aurai des questions après, justement, à ce niveau-là.
Vu que tu nous dis que ça fait cinq ans que tu as finalement rencontré DevOps,
ça s'est passé comment, en fait, c'est quoi qui a été le moment déclencheur
et comment tu as rencontré ce mouvement-là ?
Alors, assez tôt, notamment dans des missions d'audits de conseils,
de réalisation, lorsque j'étais freelance, dès 2011,
j'ai tout de suite vu que ça avait un certain intérêt.
Et moi, je l'ai vu très facilement dans le sens où, dans une mission,
je devais mettre en place un autre truc qui s'appelle Jenkins,
que tout le monde connaît aujourd'hui, mais qui à l'époque s'appelait Hudson.
Je voyais bien qu'il y avait une problématique de culture,
justement entre les DevOps et DevOps, et je m'étais documenté,
je me rappelle très, très bien de ça, sur les bonnes pratiques,
justement adoptées.
C'était encore assez jeune à cette époque-là,
mais j'ai tout de suite vu qu'il y avait un réel intérêt,
et que c'était très, très vite partagé avec les développeurs.
Notamment dans le cadre de cette mission-là,
où je devais mettre en place une usine de devs et ainsi que des tests automatisés
pour cette structure qui était à l'époque une petite PM.
Et du coup, finalement, qu'est-ce qui a changé dans ta vie de passer à ça ?
Alors ça,
Oh non, je voulais parler de ma vie perso aussi.
Moi, ça a tout changé.
Ça a absolument tout changé.
Ça m'a permis de m'élever, d'avoir beaucoup plus de compétences techniques,
d'avoir un petit peu plus de soft-kill aussi,
c'est-à-dire de trouver des bons éléments de langage
pour parler avec les développeurs.
Il faut utiliser un dédictionnaire de synonyme quelques fois.
Mais voilà, ça m'a beaucoup apporté sur ça,
et évidemment une vision transverse.
Que j'ai eu au fur et à mesure de mes expériences professionnelles.
Mais vraiment, sans le mindset de DevOps,
je ne pense pas que je serais arrivé aussi rapidement.
Et ça fait le lien avec notre de mes métiers.
Aujourd'hui, je suis serreux chez Usine,
et je pense qu'on va en parler dans l'entretien.
Tout à fait, on va en parler justement.
Tout à l'heure, tu me parlais, tu aimais bien discuter avec les devs.
Moi, c'est vrai aussi que j'aime beaucoup discuter avec les devs,
mais moi, je suis un dev à l'origine.
J'ai un développeur bac.
Enfin, ça ne s'appelait pas comme ça à l'époque,
mais c'est comme ça que ça l'est.
Développeur bacaine dans ces procès.
Et du coup, je ne suis pas là pour raconter ma vie.
Mais du coup, quand tu parles avec les devs,
que ce soit dans ton entreprise ou dans l'entreprise que tu as cité avant,
comment ils percevent le DevOps ?
Est-ce que ça change quelque chose aussi à leur quotidien ?
Ou est-ce qu'ils sont moins sensibles que nous, les ops ?
À ça, parce qu'on sait que c'est un moment qui vient des ops,
mais est-ce que ça rend chez les devs que tu as côtoyé ?
Alors oui, ça rentre chez les devs.
Alors pourquoi ?
Parce qu'en fait, côté SRE et niveau ops, on va dire, de manière générale,
on essaie de mettre en place des processus, un maximum.
Dans les processus, c'est aussi des méthodologies.
Typiquement, comme j'ai dit tout à l'heure, la performance, la sécurité,
l'observabilité, etc.
Et donc, le monde du DevOps a permis largement, en fait,
de casser ces barrières-là et au quotidien,
ce que ça change pour les développeurs,
c'est d'avoir une personne à qui parler.
Ça peut être un petit peu ridicule dit comme ça,
mais ça changera absolument tout.
C'est-à-dire que la porte n'est pas fermée
lorsqu'on peut faire une discussion avec un développeur et nous-mêmes.
Donc ça, c'est plutôt très cool.
Et ça fait aussi le lien avec une chose dont on parle assez peu.
On parle souvent des devs et des ops, mais on oublie souvent le métier.
Et en fait, ce mouvement de DevOps, il est vraiment très inclusif.
Et le but du jeu aussi, c'est de vraiment donner des éléments de langage,
de parler là encore et toujours de performance, de maintenabilité,
de disponibilité, d'éléments hautement disponibles, etc.
au quotidien pour les acculturer.
Donc c'est quelque chose de très long, en général,
à mettre en place dans une structure.
Ça peut prendre minimum, je dirais, 6 mois dans une structure
pour avoir les prémices de mouvement DevOps.
Ça peut jamais s'arrêter.
C'est vraiment dans des examens de la construction continue.
Donc en fonction des typologies de population,
là aussi, si on a des juniors, si on a des intermédiaires, si on a des seniors,
on met en place un certain nombre d'éléments, de cérémonies.
Et au fur et à mesure, de manière assez naturelle,
on arrive à s'élever les uns les autres.
Ouais, c'est bien que tu en parles parce que pour moi,
le DevOps, c'est vrai que c'est un mouvement qui nous concerne
nous les métiers de la tech, mais typiquement pour moi,
c'est un mouvement qui doit déborder, qui doit aller dans toute l'entreprise,
si on parle de l'amélioration continue, même de l'automatisation,
c'est-à-dire automatiser nos tâches, ça peut toucher tous les métiers.
Et la coopération, ça doit vraiment tous nous toucher.
Parce qu'en plus, on a un truc dans le DevOps, on en parle assez peu,
mais moi, ça me porte beaucoup.
Surtout moi qui suis entrepreneur, c'est le retour sur investissement.
On doit toujours se poser des questions sur est-ce qu'on va automatiser ça
et est-ce qu'il va y avoir un retour sur investissement.
Sur ce qu'on va faire, est-ce que toi, tu te poses ces questions-là,
justement, quand t'automatises des choses ?
Alors tout le temps, moi, je suis à très, très, très au fait de tout ça.
J'ai été moi-même aussi entrepreneur, donc je comprends tout à fait les
problématiques pour avoir une entreprise de manière générale.
Le but du jeu, c'est de le mesurer très, très tôt.
Donc moi, je suis entrepreneur du fait d'utiliser un maximum de MVP,
c'est-à-dire d'avoir un produit le plus simple possible au départ, éditerré.
Si possible, automatiser dès le départ.
Là aussi, c'est appuyer des outils, des France Socials à Scode, mais pas que.
Je pense à mes collègues, qui sont aussi grosses engineers, etc.
Et eux-mêmes aussi, ont des outils.
Et le but du jeu, c'est d'acculture les personnes, d'amener de l'automatisation.
Et pour automatiser, ça fait le lien avec un autre métier qui est l'observabilité.
Si on ne mesure pas une progression, on ne peut pas s'améliorer,
en tout cas, de mon point de vue.
Donc le lien est très, très fort entre l'automatisation et l'observabilité.
Et de manière générale, aujourd'hui, on a tous les outils à disposition
pour automatiser quasiment dès le départ.
Que ce soit avec des outils en relation à l'infrastructure à Scode,
soit avec les différents cloud providers,
il est possible d'automatiser un très grand nombre de choses.
Et notamment avec d'autres outils annexes, typiquement Zappure et autres,
qui permettent là aussi d'automatiser une très grande panouplie d'action quotidien.
Justement, ça pourrait être intéressant quand on parle de nos codes,
peut-être sur cette chaîne.
J'en ai parlé avec quelqu'un, mais sur mon autre chaîne YouTube,
la chaîne entrepreneurial.
Mais bon, on est malade pour ça aujourd'hui.
Et la question que je vais te poser, c'est comment ça se passe chez YouSine.
Comment est-ce que vous vile des Vops ?
Comment est-ce que vous le mettez en place dans votre entreprise ?
Parce que c'est grand, il y a combien de textes justement chez vous ?
Alors aujourd'hui, on est une soixantaine,
et le but du jeu, c'est qu'en fin de cette année, on soye le double.
Donc on est en pleine période de recrutement de manière générale.
Effectivement, dans ce contexte-là, assez précis,
pour enborder les personnes sur du mindset DevOps,
il y a plusieurs outils à disposition.
Grosièrement, dès que la personne est embauchée chez nous,
il y a une onboarding qui est métier la première semaine.
La personne découvre absolument tous les métiers au sein de YouSine.
Technique et non-technique, évidemment.
C'est vraiment pour lui donner un socle de base.
Peut-être pour rappeler un petit peu,
donc YouSine, on fait de la signature électronique,
et l'objectif, c'est d'être leader européen.
Et donc pour se faire, on fait de la signature électronique,
mais pas que.
On est en train de développer des plateformes
pour la gestion documentaire.
Et en ce sens, on onboarde encore des personnes
sur des métiers relativement différents.
Ça peut être des personnes qui sont en relation
avec le développement pur, développeurs back, front.
Ça peut être avec des personnes qui sont là pour l'automatisation,
là aussi avec du no-code.
Donc c'est très intéressant.
Et cette période onboarding-là,
en fait, elle est complétée par un onboarding,
cette fois-ci métier.
Donc chacune des squads onboardent les personnes
dans leur squad au quotidien pendant un certain nombre de temps.
Il y a plusieurs temporalités.
En général, la première semaine,
ça va être toute la partie création des comptes.
Vérifie que la personne arrive à bien accéder aux outils.
Qu'elle arrive à accéder à notre ressource documentaire
qui aujourd'hui se trouve sur Notion.
Pour vous donner une petite idée,
on a plusieurs milliers de pages,
aujourd'hui, de documents.
Sans parler du fait qu'on développe un maximum aussi de vidéos,
là aussi.
Ça fait écho avec la transmission,
le savoir, il se transmet par l'écrit,
mais se transmet aussi beaucoup par l'oral.
Et on mémorise dans ce que j'ai pu voir,
dans mes expériences, beaucoup plus
de part des médias en relation avec de la vidéo
ou de l'audio, plutôt que par l'écrit.
Et ça s'explique pour tout un tas de raisons.
On encourage les personnes à prendre des notes
et à améliorer la documentation au fur et à mesure.
Donc là, pour vous donner une petite idée,
une documentation, des fois,
elle peut être édité par une dizaine de personnes.
C'est le but, en fait, il faut que ce soit très collaboratif.
Donc une fois que tout ça est fait,
on va dire que ça peut prendre là aussi plusieurs mois.
Et pourquoi ça peut prendre plusieurs mois ?
On fait énormément de cérémonies autour du Père Programming,
ceci pour les devs ou pour les ops.
Donc la personne, par exemple,
aujourd'hui, qu'on onboard au sein de l'équipe SRE,
qui s'appelle Rémi, qui nous a rejoint
il y a environ un mois maintenant.
On onboard de cette façon-là,
je vais rentrer un petit peu plus dans les détails,
ça va parler à tout le monde.
La première semaine, on a créé les comptes,
on a accédé avec lui un ensemble des outils
pour vérifier si il fonctionnait bien de son point de vue.
Et ensuite, on onboardait sur le run,
comment gérer les incidents,
comment communiquer avec les développeurs,
sachant que les développeurs chez nous
s'occupent des incidents en partie sur la no-production,
on les onboard aussi sur la production.
Et donc pour ce faire, quand on onboard d'une personne,
on vérifie en fait l'état de ces connaissances.
Typiquement, on lui donne accès à un certain nombre de ressources documentaires,
on lui fait des sessions de ce formes de workshops.
Typiquement, dans le cadre du métier des séries
qu'on fait pour troubleshoot un incident,
puisqu'il y a des outils,
quels sont notre politique liées à nos SLA,
à nos SLO, etc.
Et ensuite, on vérifie l'acquisition de ces compétences au fur et à mesure.
On n'hésite pas là aussi, et c'est très utile,
notamment du côté de la série,
c'est de répéter les incidents.
Donc là, on peut très bien le faire du même côté,
mes côtés développeurs.
Typiquement, on se met du côté du développeur.
On voit qu'il y a eu un bug, on essaie de reprocesser le bug,
de retrouver pourquoi il s'est créé.
Et aussi de la façon dont on pouvait les corriger.
Donc ça, c'est assez intéressant.
Ça fait appel à d'autres techniques derrière.
On peut noter aussi le coding dojo
dans certains entreprises on en fait,
je sais où ça ne me dit pas encore.
Mais voilà, il y a beaucoup de cérémonies
à créer autour de l'onboarding.
Et bien sûr, la culture documentaire,
la transmission des compétences se fait,
comme je l'ai dit, sur du très long terme.
Aujourd'hui, on ne bordait personne.
Et grossièrement, il leur faut entre 3 mois et 6 mois
pour être opérationnel sur le métier.
Et ça s'explique pour différentes raisons là aussi.
Ça s'explique parce que nous avons déjà beaucoup d'outils.
On a une plateforme qui est aujourd'hui très performante.
Et elle a besoin de beaucoup de soins au quotidien,
notamment pour la maintenir.
Ce qui est assez logique.
On a une bonne partie de notre référence structure
qui est en France.
Donc ça s'explique aussi par différents thématiques
autour de la gestion du stockage,
autour de l'observabilité, autour de la performance, etc.
Donc sur chacun de ces éléments-là,
on essaie de lui donner des guidelines.
On essaie là aussi de le sonder.
Typiquement dès lors qu'il a fait une session de formation,
on lui demande son feedback, s'il y a des axes d'amélioration.
Voilà, je synthétise très rapidement.
Mais tout ça pour dire que ça prend aujourd'hui des mois,
voire des années en fait, pour monter en compétence sur un domaine
et encore plus pour des juniors.
C'est bien de synthétiser, ça blesse le temps de te poser des questions
ou de réagir à ce que tu dis.
En plus, tu me coupes mes futures questions.
Mais c'est pas grave.
En fait, je me posais la question.
T'as parlé de la source documentaire et autres.
Nous aussi, on fait ça, mais on est moins qu'aux que vous.
Vous utilisez un type d'outil justement pour partager cette source documentaire
et que tout le monde puisse le modifier.
Est-ce que vous utilisez des wiki ou autre chose ?
Des wiki, essentiellement notion, qui est pas un outil open source.
Mais aujourd'hui, on a testé un peu tout.
On a testé Confluence, on a testé Slite.
Anciennement, il y avait même des outils open source,
typiquement que Dooku, Lucky, etc. qu'on utilisait.
Mais notion a l'avantage indéniable,
c'est d'avoir accès à ce qu'on appelle des database.
On peut coroller des données, des pages avec d'autres,
trouver des gestions de tags, etc.
Et tout ça, ça participe vraiment à ce que tout le monde puisse collaborer.
Il y a une gestion des commentaires, évidemment.
Ça va très loin.
On peut automatiser, on peut faire des templates.
Nous, on est très fan de templates.
Aujourd'hui, on essaie de templatiser tout un tas de ressources.
Et ensuite, comme tu me l'as demandé, effectivement,
on n'a pas que des wiki.
On a aussi la vidéo, donc on a un petit catalogue de vidéos,
sur lesquelles tout un chacun peut y participer.
Il veut présenter un produit, il s'enregistre.
Il peut répondre à des questions en live ou autre.
Et le but du jour, c'est tout simplement de collaborer sur la culture documentaire.
La culture documentaire, en mon sens,
elle ne peut pas fonctionner si il n'y a aucun qui écrit.
Ça ne fonctionne pas.
Il faut vraiment que les personnes y participent au quotidien.
Donc il y a tout un tas de formes.
Et peut-être dans le futur, on essaiera peut-être de créer des podcasts en interne.
Pourquoi pas ?
Je vous le souhaite.
En tout cas, je crois beaucoup, comme tu le dis, à la puissance de la vidéo.
Depuis que j'avais des vidéos, j'ai remarqué qu'il y a beaucoup de choses
que je pouvais faire en vidéo pour nous.
Mais ça prend du temps, mais de rien.
Et puis, nous, on est tout petit.
Alors, nous, on est quatre.
Donc dès qu'il y en a un qui fait de la vidéo pour quatre, tout de suite,
tu prends 25% des ressources comme ça.
Ça commence à se voir pas mal.
Mais bon, il y est là.
Je ne fais pas si beaucoup justement l'unboarding aussi chez nous.
Parce que nous, on a un process d'unboarding qui est moins long.
Alors, tu disais trois, six mois, c'est long,
mais pour être efficace, mais ce n'est pas si long que ça.
Parce que dans toutes les boîtes, pour être vraiment efficace,
dans les boîtes tech, il faut quand même du temps.
Il faut que l'être le métier, etc.
Et donc, moi, je suis en train de penser à un truc.
Je ne sais pas ce que tu vas en penser.
Je ne sais pas comment vous faites chez vous, mais j'ai bien envie chez nous.
Alors, nous, on utilise Froggy Tocotilla, maintenant, on utilise notre logiciel.
Et tous les gens qui travaillent chez Lidra, même les non-tech ou un compte.
Et je pensais justement à faire un dépôt d'unboarding avec des issues.
Et tu passes les issues petit à petit sur chaque sujet.
Et tu as des vidéos du texte, à dire en fonction des issues.
Tu peux comme ça cloner ton dépôt quand tu arrives.
Et tu fais avec le board de GitLab, tu fais ton onboarding semi-autonomes.
Je dis semi-autonomes parce qu'évidemment, il y a des rendez-vous et des discussions.
Parce que nous, on colle des discussions.
Je ne sais pas ce que vous faites chez vous, si ça peut se rapprocher de ça.
C'est une...
Si, il y a à peu près ça qui est fait côté justement développeur.
En fait, ils clonent le code base.
Et ensuite, ils regardent un petit peu les issues les plus marquants de l'année.
Ils essayent de reprocesser un petit peu tout ça dans leur tête.
Et en fait, il n'y a rien de mieux qu'un incident et des postmortems.
Parce que je n'en ai pas parlé aussi, mais on a une culture de postmortems assez haute chez nous.
On l'a mis en place depuis environ deux ans.
Il y a des articles de blog qui vont parler dans les jours à venir d'ailleurs en ce propos.
Mais tout ça pour dire qu'on apprend des autres,
mais on apprend aussi beaucoup des erreurs qui ont été faites par le passé.
Et donc, c'est une très bonne initiative, comme tu l'expliques.
Moi, j'ai déjà vécu ça aussi dans d'autres entreprises, notamment chez Orange.
Ou quand j'étais arrivé en poste dans une équipe,
là aussi, une squad de 8 personnes avec DPM, avec des développeurs et des intégrateurs.
Et moi-même.
J'ai du cloner un certain nombre de repos,
déployer un certain nombre de stacks en local,
déployer la stack même de l'entreprise en fait, quasiment avec un certain nombre d'applications
derrière, essayer de voir comment elle était monitorée, la performance associée, etc.
Et ça, je trouve ça très bien d'ailleurs au quotidien.
C'est très intéressant comme méthodologie pour on de bordé quelqu'un.
Par la pratique, c'est encore mieux que la théorie.
La théorie, c'est très bien, mais la pratique, c'est beaucoup mieux pour retenir.
On s'en aperçoit très bien lorsqu'on anime des formations.
Moi-même, quand je faisais des formations, c'est ce que je disais tout le temps aux personnes avec qui
je pouvais échanger au quotidien, donc des stagiaires essentiellement, des adultes évidemment.
De leur dire que si on n'est pas en pratique quasiment tout de suite après la formation,
sachant que dans la formation, on contient déjà une partie pratique, on oublie très,
très vite. Et c'est déjà le cas en fait très, très rapidement, on va dire dans les 48 heures
à venir si on pratique pas, on oublie. Donc on ne bording, c'est très bien.
Il ne faut vraiment pas oublier, comme tu le dis, de passer sur la pratique. C'est vraiment essentiel.
Oui, mais justement, on va parler des formations juste après.
Est-ce que tu sens que, enfin toi ou est-ce que la boîte sent,
est-ce que vous avez des métriques là-dessus sur est-ce que tout ce process que vous avez
mis en place, est-ce que ça limite le turnover ? Alors oui, alors pourquoi ? Déjà nous,
le turnover, c'est assez historique, mais Yussein, ça existe depuis 8 ans. Il y a eu très,
mais vraiment très, très peu de turnover. Moi, je suis chez Yussein depuis un peu plus d'un an,
et il y a eu même pas 1% de turnover pour expliquer un petit peu. Néanmoins, pourquoi on a moins
turnover que certaines d'autres entreprises ? Bien sûr, on n'est pas les seuls à voir ce taux-là.
Ça s'explique, et notamment par la transmission du savoir, l'on-boarding,
et les conditions d'accès à des contenus techniques. Donc là, ça va être très intéressant,
parce qu'on est en train de mettre, justement, pour faire et quoi avec ce que tu dis,
des cursus de formation interne avec une personne qui s'appelle 360 learning,
et un autre cursus de formation, plutôt de formation, je dirais, continue,
avec des partenaires privilégiés, notamment, par exemple, on peut citer une plateforme avec
Udemy, par exemple, c'est ce qu'on a un visage de faire. Pour vraiment donner une ressource,
c'est une culture de la compétence technique, ou les soft skills d'ailleurs, parce qu'on parle
beaucoup des compétences techniques, mais un petit peu moins des soft skills, mais la bonne
communication, sainte d'une équipe, comment gérer des conflits, etc., c'est très important.
Et là aussi, je pense aussi que ces types de ressources-là sont clairement utiles pour garder
le savoir en maximum de temps dans sa tête. Et pour se faire, il faut donner des cérémonies,
c'est-à-dire, d'avoir très souvent dans l'année des périodes où on monte en compétence,
par soi-même ou avec l'aide des autres.
Et parce que là, tu cites des acteurs un peu implantés, est-ce que vous faites parfois appel
à des formateurs indépendants pour vous concevoir des formations ou pas du tout ?
Alors pas encore à ce jour, en toute transparence, on est en train de revoir justement ce catalogue
de formations-là. On est largement aidés sur ça. On a des personnes en interne qui sont, on va dire,
très à même et très au fait de gérer tout ça. Mais on a quelques sessions de présentation plus
que de la formation au cours de l'année, notamment dans nos sessions de tech-meeting qui se font
aujourd'hui tous les trois mois et dans lequel il y a des intervenants qui viennent, que ce soit pour
la technique ou pas d'ailleurs. Essentiellement, les derniers qu'on a eu, c'était pas pour de la
technique, c'était plus pour de la présentation, notamment sur des domaines divers et variés.
Ça peut être sur l'écologie, ça peut être sur la performance, ça peut être sur tout un tas de
domaines. Donc pour l'instant, on fait que ça. Mais l'objectif là aussi, c'est de faire venir
des intervenants parce que c'est très bien d'avoir un recul avec les personnes. Nous, on est en interne,
donc on arrive à transmettre un certain niveau d'information, mais quelqu'un de l'extérieur
peut voir certaines choses qui pourraient être améliorées et c'est très utile. Et notamment,
j'irai revient au fait que même si moi-même j'ai été formateur par le passé, j'adore passer des
formations vraiment. Et là aussi, c'est comme un coach de sport, il a besoin d'un coach. Voilà,
donc tout ça pour dire que la formation, en fait, elle ne s'arrête jamais, c'est vraiment une
formation qui est continue. Surtout quand on est dans ce mouvement là, le mouvement des Vapes,
où on s'améliore en continu, ça fait partie des choses, le finalement, de se former et d'apprendre
de nouvelles choses ou d'apprendre de nouvelles façons de voir des choses qu'on connaît déjà.
Est-ce que vous faites justement des broke back lunch ? Excusez mon anglais, mais des déjeuners,
vous vous invitez justement, peut-être apparaître des recontextes, mais vous vous invitez un expert
pour discuter autour de la déjeuner ? Alors ça, pas encore, mais je pense que cette année, on va le
faire. Il y a déjà des initiatives qui sont en cours de réflexion à ce niveau-là. C'est très
intéressant de faire venir des acteurs extérieurs pour la tech ou pas d'ailleurs. Nous, on est très
au fait de certaines méthodologies, notamment on fait du PLG, ça parlera à ceux qui font un petit
peu plus de produits, on met en place évidemment des cérémonies agiles, on aime bien, on va dire,
démocratiser et revenir sur des notions de culture du feedback et pour se faire en fait,
faire appel à des formateurs extérieurs, notamment pour être plus performance au ces domaines-là,
pour discuter autour de quelque chose de très simple, typiquement, pour faire venir des personnes
qui ont écrit un certain livre, fasciner les autographes mais pas que, voir derrière ce qui
se cache derrière le livre, ça peut être aussi intéressant. Je l'ai déjà vécu, non pas chez U.S.N.,
mais dans d'autres entreprises beaucoup plus grosses, parce que pour faire venir un certain nombre
d'acteurs de manière régulière, surtout cette notion de régularité qui est importante,
il faut un certain nombre de personnes pour gérer ça au quotidien, sélectionner des personnes
pour parler évidemment, il faut les accueillir, il faut avoir un emplacement pour les accueillir
correctement, etc. Oui en plus, ça doit à certains coups non seulement humains pour vous,
mais aussi pour faire dire les jours, parce que la plupart des gens dont tu parles, ils doivent
être très sollicités, donc à un moment donné ils ne peuvent plus faire ça de manière bénévole.
Un jour on n'arrête pas de me demander plein de trucs, mais à un moment donné,
nous nous journée il faut 24 heures et puis on n'a que 365 jours, donc il faut faire des choix,
donc ça doit être compliqué. Justement, tu nous parles formation et d'apprentissage,
et toi cher auditeur, tu sais à quel point je crois l'apprentissage grâce au Montorat.
J'en ai d'ailleurs parlé dans un épisode qui s'appelle « En solo numéro 6, apprenez plus
grâce à un Montor », je ne sais pas si tu l'as écouté, toi Daniel celui-là.
Oui, tout à fait.
On va en parler justement, et moi je te mets le lien en description à toi qui écoute le podcast,
et Daniel. D'ailleurs, est-ce que tu as écouté cet épisode, qu'en as-tu pensé,
mais surtout ce qui m'intéresse est chez vous, est-ce que vous avez du Montorat interne,
et si c'est développé, comment ça se passe ?
Alors, très simplement, moi ce que j'en ai pensé, c'est déjà un épisode assez complet,
il fait appel à différentes notions, le transfert de compétences, le mentoring,
la formation, tout ça c'est un certain nombre de cycles, et après ce que ça veut dire derrière,
c'est des différentes formes et différents niveaux de transfert de compétences,
c'est-à-dire, il y a une notion de temporalité, et ça tu l'abords du coup dans le podcast,
et ce qui est très intéressant aussi, justement sur ce podcast précis,
c'est qu'on a vraiment un lien assez fort, du coup avec la communauté que tu as créée,
et ça je trouve ça très très important, aujourd'hui d'avoir une communauté francophone,
pour justement s'échanger un certain nombre de tips, pour se rencontrer aussi en physique,
bon avec le Covid c'est assez compliqué, mais sinon je pense qu'on pourra faire ça après par la suite.
Oui j'ai des idées là dessus pour des similaires, je crois que j'en ai déjà parlé,
mais justement, et dans votre boîte, plus particulièrement, est-ce que vous avez un,
est-ce que vous avez instauré le Montorat, est-ce que ça se fait, est-ce que ça se fait pas,
est-ce que c'est de manière informelle, est-ce que c'est de manière formelle ?
Alors aujourd'hui on est au début de ça, il y a des personnes qui sont très motivées pour le faire,
bien sûr je suis pas le seul très motivé à le faire, il faut s'appuyer de personnes qui sont
relativement seniors, mais pas que, donc pour l'instant on va dire dans cette année vu qu'on va
en border énormément de personnes, comme j'ai dit tout à l'heure, on va doubler notre effectif,
on va avoir un certain nombre on va dire de temps de travail associé à cette on-bording-là,
on ne le aura pas encore pour du mentoring tel qu'on pourrait le penser, et moi mon sens
le mentoring là aussi il y a différentes formes, on pourrait avoir tout simplement des personnes qui
sont là en termes de, on va dire ce qu'on appelle aujourd'hui, il y a un terme pour ça, on appelle ça
un budgist, c'est à dire une personne qui va forcément relire le code, qui va donner des axes
d'amélioration, d'ailleurs c'est un peu globalement l'automatisé parce que nous chez U-SAN on est
très fans des bots, donc certains développeurs ont développé des codes, des bots pardon,
pour améliorer la code review notamment, les passages de relise etc, et donc pour ce faire le
mentorat on va dire que ça va être une des certaine des pistes sur lesquelles on pourra s'améliorer
sur l'année 2023. Sans aller vers du mentorat pur et dur, moi c'est vrai que le mentorat fait partie
du compagnonnage, mais le compagnonnage il y a une notion un peu moins formelle que le mentorat c'est
d'avoir quelqu'un à qui tu peux poser des questions et qui t'accompagne en fait. Moi j'essaie de
mettre ça en place dans ma coopérative d'entrepreneur, un compagnonnage entrepreneurial du coup,
mais je crois beaucoup à cet aspect compagnonnage, évidemment si j'ai créé des compagnons d'evops
c'est aussi pour ça, le nous cachons pas, je crois qu'il y a beaucoup à apprendre justement
des compagnons du devoir parce que vous vous en doutez tous, mais c'est pour ça que ça s'appelle
comme ça, et cet aspect mentor, élève, enfin bon voilà je ne sais pas si t'es Star Wars mais tout
le monde là en tête aussi, il y a cette logique là où je pense qu'on peut apprendre et on a tous
besoin d'un mentor et d'un mentoré de manière globale, je crois que tu es d'accord avec moi.
Tout à fait, absolument.
Ben du coup est-ce que t'as un dernier truc à nous dire sur la transmission et justement,
tu as tout à l'heure parlé de la culture du feedback, j'aimerais bien qu'on y revienne,
la culture du feedback et la culture de l'échec, est-ce que vous l'avez chez vous,
alors déjà est-ce que c'est une boîte française, est-ce que justement vous avez les travers de
boîte française ou est-ce que vous avez justement cette culture du feedback et cette culture de
l'échec qui fait qu'on apprend de ces échecs et c'est pas si grave si on fait un échec et on doit
apprendre de ces échecs. Alors oui, tout à fait, on est très très friands de ça, ça s'explique
parce que notre sitio a très très tôt mis en place finalement ce genre de pratique au
centre de l'entreprise. Pour ce faire, on a différents inputs, on va dire au quotidien,
pour gérer tout ça. On a comme j'ai dit les postmortems, donc les postmortems pour rappel,
dès lors qu'on a un incident qui touche à un certain nombre de personnes en
occuance nos clients, on communique à l'ensemble de nos clients les éléments qui ont permis de
détecter, troubleshooter, la panne et nous en interne, on documente ça de manière beaucoup plus
précise et complète, ça permet à la personne d'avoir une timeline de se dire, bien l'incident
n'y arrive à telle heure, telle personne l'a prêt en charge, la criticité, c'est telle criticité,
les moyens d'action permettant de s'améliorer. Donc après on a un mécanisme qui fait qu'on
se revoit avec les personnes qui sont responsables justement de ce périmètre applicatif.
Là aussi je mets un point d'honneur, on met un point d'honneur à ce qu'on ne blâme pas les
personnes en fait, donc c'est ce qu'on appelle le blameless postmortem, on ne blâme pas les
personnes, par contre le but du jeu c'est de s'améliorer. Donc le but c'est de ne pas avoir le
même incident le lendemain ou l'année d'après. Et donc pour se faire on a un véritable suivi, ça
ça fait partie on va dire d'un sous-ensemble qui est la gestion des incidents et pour s'améliorer
là aussi tu parlais de culture de l'échec etc. Nous on est relativement bienveillant,
le but du jeu en fait c'est qu'on s'améliore. Donc en fait on n'est pas là à se dire c'était
de personne, c'était de l'équipe etc. qui a fait une erreur, les erreurs ça arrive à tout le monde.
Et le but du jeu c'est de faire le lien encore avec les différents processus de la série qui sont
les postmortems, qui sont les SLO, c'est à dire de s'engager sur un délai de réponses, s'engager
sur une rapidité d'implémentation, ce genre de choses. Et donc voilà c'est la culture du
feedback, elle est très profonde. Je vais donner un exemple précis. Moi j'avais fait une vidéo sur
la présentation de Datado qui est un outil d'observabilité qu'on dit chez USIGN. Je mets en place un
micro cursus de formation plutôt du discovery, c'est à dire de la présentation de l'outil,
c'est pas encore quelque chose de très précis, on essaye de le faire au fur et à mesure parce que
c'est assez récent, le passage à Datadox c'est fait il y a quelques mois à peine. Et derrière ce
qu'on fait c'est que nous on envoie une taille forme à l'ensemble des équipes pour leur dire est-ce
que ça vous suffit en termes de ressources documentaires, est-ce que ça vous convient, est-ce qu'il
y a des choses qu'on n'est pas sur à côté pour lesquelles on va devoir s'améliorer. Donc la
culture du feedback elle est omniprésente, elle est omniprésente aussi au niveau d'une équipe
qui s'appelle le customerker, qui sont on va dire en bien direct avec nos clients, ils prennent
les feedbacks des clients, ils remontent au produit, c'est un feedback positif ou négatif là aussi,
on est très à même de gérer ça au sein de USIGN et voilà tout simplement pour dire qu'on a
la culture de feedback aussi bien dans la tech qu'au niveau du produit et même bien au dos de
là de ça on a une culture très très importante au niveau du people, typiquement s'il y a de la
communication à faire sur un élément différent, typiquement on veut mettre en place un
nouvel outil, un nouveau processus etc. On mesure le taux de satisfaction, ce qu'on appelle le NPS,
nous on le fait de manière très interne, c'est à dire que notre employeur tous les trois mois de
mémoire nous envoie une enquête pour savoir si tout se passe bien au sein du SIGN, si il y a des
choses à améliorer, si il y a des choses sur lesquelles on est très content. Donc là aussi en
le feedback il est quasi sur toute la chaîne et c'est en mon sens très important, il ne faut pas
qu'il ne soit que sur la tech ni que sur du produit ni que sur du people de côté employeur.
Ça a l'air super cool de travailler chez vous, je pense que si je n'étais pas entrepreneur,
j'envisagerais peut-être de vous rejoindre. Du coup t'as dit que vous vouliez doubler vos
effectifs alors j'imagine que vous avez plein de postes ouverts, normalement ce n'est pas l'objet
du podcast mais si t'as un note board ou quoi tu peux me passer je le mettrai dans les notes
de l'épisode. Bien sûr les gens qui seraient intéressés pourrez vous rejoindre, j'imagine
que vous avez plein de postes tech. Tout à fait, tout à fait énormément de postes,
que ce soit sur du développement, que ce soit sur la partie produit, que ce soit sur la partie
marketing etc. Donc voilà je t'enverrai évidemment le lien avec très très grand plaisir. Je pense
qu'on peut encore discuter pendant longtemps mais le podcast avance du coup je vais te poser ma
dernière question avant de te curer mais est-ce que justement t'as envie de partager quelque
chose, un livre, un article, une conférence ou une vidéo ou quoi que ce soit à nos auditeurs et
auditrices ? Alors oui moi j'ai essayé de m'améliorer sur ma communication depuis des années,
c'est quelque chose qui ne sera jamais terminé évidemment. Donc moi je veux conseiller un
livre que je dois voir là d'ailleurs qui s'appelle Maîtriser l'art de la communication,
c'est des caillers de Hardware Business Review qui sont très intéressants et pourquoi ce livre
là tout simplement parce que ça fait un lien avec la communication, la transmission du savoir,
comment essayer de transmettre au quotidien de manière efficace. Voilà et peut-être un autre
second livre plutôt orienté, j'allais dire Tech, moi je conseillerais très très largement le
livre de Google sur les SRE qui est disponible d'ailleurs en version non pas Open Source mais
disponible sur la toile de manière gratuite donc c'est un freinium. Voilà ça permettra on va dire
à tes auditeurs de comprendre un petit peu mieux ce que c'est que les SRE et de voir les mécanismes
associés. Et bien écoute si tu as un lien pour ces deux références je suis preneur et je te
remercie en tout cas je te dis à très bientôt dans un podcast, il n'y a plus qu'à prendre la place
maintenant comment ça va être nombreux mais c'est bien du coup on va pouvoir être régulier,
ce qui nous permet d'être régulier depuis plus d'un an en tout cas. Et quant à toi chers auditeurs et
auditrices si tu as apprécié cet épisode de podcast et si tu veux approfondir tes softkiss
puisqu'on en a parlé et obtenir justement un état d'esprit DevOps, sache que j'ai une formation,
j'en fais pas beaucoup la promo qui s'appelle DevOps Mindset, tu trouveras le lien en description,
c'est le premier lien et tu pourras aller t'inscrire, l'acheter s'il te intéresse et puis la suivre.
Et bien merci et puis à bientôt. Merci beaucoup Christophe, à bientôt.
Merci pour votre soutien, si tu as envie de discuter du mouvement alors rejoins-nous dans la communauté
des compagnons du DevOps, à bientôt. La balade aux diffusions des compagnons du DevOps est produite par l'Hydrat.