DevOps n'est pas un métier, on a beau le répéter, ça ne me rendra pas.
Alors comment le DevOps impacte les métiers dans les boîtes ?
C'est quoi finalement la différence des métiers dits DevOps dans un contexte de start-up ou de grandes entreprises ?
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 !
Bienvenue à toi chers compagnons, dans ce nouvel épisode de Radio DevOps, tu sais,
l'émission qui discute d'un sujet particulier.
Et aujourd'hui on va parler du DevOps, des métiers DevOps ou DevOps dans des contextes DevOps,
dans des petites ou des grosses boîtes, celles qui ont fait ou pas leur transition DevOps.
Là on va quand même parler de celles qui se disent DevOps.
On est dans un format un peu à la cool, on est trois, on va discuter,
on est dans un format tableau ronde et on va te parler de tout ça.
Et donc justement pour parler avec moi de métiers dits DevOps, il y a R1, bonsoir R1.
Bonsoir !
Et toujours fidélopost, au poste renez, bonsoir renez.
Bonsoir !
Alors j'en profite pour te rappeler chers auditeurs ou auditrices, que si tu veux connaître les podcasteurs,
tu as nos podcasts de présentation qui sont toujours dans les liens en description.
Donc si jamais tu vas en savoir plus sur un des podcasteurs, tu peux aller voir les liens en
description et aller écouter les épisodes qu'on a enregistrés justement sur chacun d'entre nous.
Et on va commencer par présenter nos expériences.
Et donc je propose un truc, c'est que chacun on va dire par quel type de boîte on est passé,
la taille à peu près et puis s'il y avait un contexte DevOps avancé ou plutôt baby DevOps,
voire pas DevOps du tout s'il y avait de l'exploitation par exemple.
R1, est-ce que tu veux bien commencer ? Je vois qu'en plus t'as mis pas mal de notes dans l'épisode.
Oui, oui, je peux commencer.
Du coup, moi j'ai eu la chance de connaître pas mal de contexte assez différent.
J'ai travaillé pas mal en startup, en scale-up.
J'ai travaillé dans les startups que j'ai rejoint.
J'ai eu la chance d'arriver en début de projet, donc vraiment il n'y avait pas grand chose.
Et j'ai eu la chance de travailler dans des scale-ups qui cherchaient un peu plus de maturité
autour des sujets dit DevOps.
Et globalement, du coup, j'ai surtout évolué dans des petites entreprises.
Bon, j'allais dire moyenne et grosse, mais en discutant un peu avant le podcast avec vous deux,
je me rends compte que la notion de grosse entreprise pour moi, elle était vraiment très loin,
mais je vous laisserai en dire plus.
Et donc, dans les boîtes que j'ai connues, j'ai travaillé chez 10h à un moment où on était assez petit.
J'ai travaillé chez Weborama.
Plus récemment, j'ai travaillé quasi 6 ans chez Toukantoko, qui est aussi petit.
Et aujourd'hui, je suis chez Scaleway.
Voilà, pour moi.
René, est-ce que tu veux bien prendre la suite ?
Oui, alors moi, je suis un peu jaloux d'erreur,
parce que j'ai pas connu de petites structures et ça a un peu en regret.
Et donc, je travaille que pour des grands groupes,
principalement un grand constructeur informatique,
à l'époque, je voulais de pacar, pas le nommer.
Et donc, plusieurs centaines de milliers de personnes.
Et ensuite, dans le service pour CGI.
Et voilà, 70 000 personnes, je crois.
Voilà, donc pour apporter du service auprès du client autour du DevOps.
Et puis maintenant, je fais plus tout à fait ça,
vu que je suis chez Red Hat et je fais plutôt du logiciel, c'est un peu différent.
Alors, à mon tour, moi, je suis passé,
j'oublie toute la partie où j'étais développeur,
mais quand j'ai commencé a faire de l'exploitation,
j'ai commencé par casino monoprix,
donc, à l'heure d'une multinationale, une très grosse boîte.
On n'était pas en DevOps du tout.
Puis, c'est là où je me suis vraiment commencé a m'intéresser au DevOps.
Je suis parti, je me suis fait embaucher par une startup,
donc on était trois à l'informatique dans une équipe de moins de dix personnes.
Donc, on peut dire que c'était une petite boîte.
Ensuite, je suis devenu indépendant,
mais j'ai eu comme client, des très gros clients comme l'ABPI
où tu peux avoir 1 200 personnes à l'informatique
ou à nouveau, à nouveau, casino, où il y a plein de gens,
puisque casino, à l'époque où moi, j'y étais, c'était 600 personnes à l'informatique,
aujourd'hui, c'est un peu moins, mais ça reste de très grosses boîtes.
J'ai vu les deux, en fait, les deux côtés.
J'ai peu travaillé dans des PME.
Je précise, du coup, pour toi, chers auditeurs,
qu'on a fait une différence entre les petites entreprises
et on a décidé que c'était moins de 50 personnes.
Ensuite, les PME, entre 50 et 500 personnes,
et les très grandes entreprises, à plus de 500 personnes.
Ah oui, et puis je précise qu'aujourd'hui, ce que je fais,
en plus de Montorra et d'accompagner les organisations,
je suis situé au Product Owner d'une petite start-up coopérative
où on est 6, donc je vois le DevOps et je le mets en place dans notre entreprise.
Voilà pour ma part.
Du coup, on va parler de petites structures
et qui veulent commencer à nous parler des petites structures.
Alors, si j'ai bien compris, c'est plutôt R1 et moi qui avons discuté
de petites structures R1 et R2.
Tu vas peut-être me poser des questions.
R1, est-ce que tu veux bien commencer justement ?
Oui, oui.
Je peux dire un peu la façon dont moi, je l'ai vécu.
La façon dont j'ai vécu, c'est les roles d'id DevOps
que j'ai eus dans ces structures.
Globalement, ce que je retiens, c'est que dans les petites structures
et surtout que, typiquement, à tout Quantoco,
j'étais la première personne qui faisait de l'infra.
Quand tu arrives, ton scope devient très vite hyper large.
Ça touche à tout, à l'infra, au backup, au monitoring, à la sécurité.
J'ai fait de la vend vente, j'ai fait d'informations de clients,
mis en place du PRA, faire du recrutement, les astreintes, le support, etc.
Et en fait, je pense que le sentiment que j'avais chez tout Quant,
après, c'est peut-être galvodé, mais j'ai quand même le sentiment
que c'était un peu la même chose dans les autres expériences que j'ai eues,
c'est que quand comme ça, tu es le seul à l'infra,
ou quoi que ce soit, tu deviens souvent le mec de l'informatique par défaut
pour à peu près tout et n'importe quoi.
Et donc, un des sujets qui est sûr, c'est que dans les petites structures,
très souvent, ton scope, il est beaucoup plus large,
que dans des structures un peu plus grandes et organisées.
Et ça, je crois que c'est quand même un premier point.
Donc typiquement, moi je dirais que c'est très bien de commencer sa carrière
en toute petite structure, parce que du coup, on est confrontés directement
à plein de choses très vite, mais il faut accepter peut-être la charge mentale
et le dépassement de fonctions, qui sans être des grands mots,
mais c'est juste, moi clairement, quand je suis arrivé chez tout Quant
et que trois semaines après, j'allais chez un client pour faire de la vendante,
je m'y attendais pas.
Donc voilà, mais je faisais de la vendante pas parce qu'à un moment,
le client, il a besoin de parler à un mec qui a des lunettes de l'informatique
et que j'étais le mec par défaut.
Je vais rebondir là-dessus, si ça t'ennuie pas, parce que moi aussi,
comme je disais, j'ai travaillé dans des petites startups
et il y a comme des startups qui viennent nous voir chez Lidra
pour les aider et les accompagner.
Les startups, souvent quand elles commencent, elles ont une équipe de développement,
une équipe business-développement, alors peut-être pas le terme qu'on devrait utiliser,
marketing, etc., communication et pas d'ops, parce que souvent,
ils installent tout à la main, ils font tout eux-mêmes, ils vont chez des passes, etc.
Puis il arrive un moment où ils ont du succès et ils viennent nous voir,
nous, les ops, donc toi, il t'embauche, moi, il vient de me voir en tant que consultant,
et ils nous disent, ben voilà, on a ça, qu'est-ce qu'on peut faire?
Et en fait, ils se rendent pas compte qu'ils te demandent à toi tout seul
d'être l'équipe informatique, l'équipe d'infrastructure à toi tout seul.
Et en effet, c'est, comme tu l'as dit, on fait tout.
Et on fait tout seul dans la boîte, et moi je trouve que c'est épuisant.
Moi, je le déconseille aux jeunes qui démarrent, aux jeunes administrateurs systèmes.
Quand j'ai commencé à faire ça, j'avais déjà 35 ans, j'avais déjà de la bouteille.
Et heureusement, parce que si j'étais parti comme ça à 20 ans,
je pense qu'en fait, j'aurais juste fait un burn-out plus tôt,
et j'aurais claqué la porte de la pharmatique.
Honnêtement, la quantité de trucs que tu dois aggurgiter quand tu es tout seul
dans une start-up où tu dois t'occuper seul de l'infra.
Et qu'en face de toi, t'as cinq ou six développeurs qui te demandent
« Est-ce que tu peux nous faire l'ACI? Est-ce que tu peux nous programmer les tests?
Est-ce que tu peux nous mettre en place les serveurs, l'automatisation?
Ah, le déploiement continue, on voudrait bien l'avoir.
Ah, au fait, c'est super visé, c'est Backepé.
C'est quoi le SLA? Et est-ce qu'on fait des astrates?
Non, mais les gars, je suis tout seul, je peux pas faire les astrates, arrêtez.
Bon, voilà, je voudrais dire que quand on est dans des petites boîtes,
il faut avoir les reins solides parce qu'en effet, on est seul,
et il faut bien s'attendre à ça.
Alors on est seul dans la boîte, et justement, c'est là où le réseau
peut avoir son importance, et il faut s'entourer de personnes autour de nous.
Je sais pas ce que t'en penses, toi, Erwan, de ça.
Je veux juste te rebondir.
Moi, quand j'ai commencé ma carrière chez Weborama,
et en fait, il y avait qu'une personne à l'infra, à l'époque,
qui était le CTO et un des fondateurs, d'ailleurs,
et du coup, j'étais pas seul, mais on n'était quand même pas beaucoup,
et le fait de commencer chez Weborama a été assez intéressant,
et formateur pour moi, parce que justement, je bénéficiais de l'expérience du CTO,
et en même temps, j'avais tout de suite pas mal de responsabilités.
Donc ça, c'est quand même pas mal, ce genre de responsabilités et tout
que tu obtiens plus facilement, du coup, dans des plus petites structures que dans des grandes.
Et c'est sûr qu'il faut les accepter, enfin, il faut pouvoir les assumer quelque part,
mais si on est prêt à assumer ça, franchement, c'est des super expériences.
Et je voulais juste rebondir sur un dernier truc.
Effectivement, moi, quand je suis arrivé chez Toukantoko,
il n'y avait pas grand chose, il y avait des « les balbuciments » d'une approche des Vops.
Et par contre, la charge mentale que tu décrivais,
moi, je ne l'ai pas vécu vraiment comme ça,
parce qu'ils étaient conscients qu'il y avait plein de choses à faire.
Et en gros, moi, la façon dont je l'ai vécu, c'est fait de ton mieux pour qu'on aille dans le bon chemin.
Donc effectivement, CIID, automatisation des déploiements des stacks, etc.
Puis après, passage truc de coeur, plein de trucs comme ça, de façon littérative.
Et en fait, même si j'étais tout seul, même si des fois,
il y a des sujets qui ont mis plus de temps ou quoi à sortir,
moi, j'ai trouvé que j'avais toujours pas mal de soutien,
parce que les gens étaient assez conscients du travail que ça représentait.
Et encore une fois, dans les plus petites structures,
le fait qu'il y ait quelque chose de clair là-dessus,
sur les attentes, sur le délivrie et tout,
c'est ce qui fait que l'expérience se passe bien ou pas.
Et ça, en vrai, c'est la même chose dans des plus grandes structures.
Mais disons que, comme dans une petite structure, tu peux moins te cacher,
c'est quand même important de bien être clair là-dessus.
Tu veux que je continue ?
– Vas-y, vas-y, continue. – Et moi, j'allais...
– Oui, excuse-moi, pardon. – Peut-être que je vais faire un tout petit pendant
un petit peu juste pour illustrer dans les grands groupes comment ça se passe, en fait.
En fait, quand on est dans un grand groupe aussi,
on est aussi dans une équipe qui, elle, est plus quand même petite,
et on ne peut pas parler à tout le monde dans un grand groupe.
Par contre, c'est évident que le scope, entre guillemets,
ce sur quoi on intervient est beaucoup plus réduit.
Et en l'occurrence, par exemple, moi, j'ai commencé...
Je parlais plutôt côté ops, mais...
Voilà, on n'avait pas le réseau parce qu'il y avait une équipe réseau
qui gérait tout ce qui était réseau.
Donc voilà, le réseau, au début,
on ne l'a jamais touché, en fait, réellement.
Et alors, on est touchés, nous, on est...
on est du stockage et du système.
Et aussi les backups parce que ça, c'est parti du stockage,
mais même ça, au bout d'un moment,
parfois, ça a été découpé, c'est-à-dire qu'à un moment,
on faisait plus que du système.
Donc des fois, ça découpe presque à outrance.
Alors je pense que le... peut-être le plus,
c'est qu'on peut aller creuser un peu plus en profondeur sur le sujet,
mais par contre, c'est...
effectivement, ça donne moins ce... je pense, ce côté...
un peu à tout faire.
Et je pense que c'est sympa,
et ça met un bon coup d'accélérature sur ce qu'on apprend.
Bon, effectivement, après, tu...
tu peux peut-être un peu moins creuser parce que t'es pris pas le temps, quoi.
Pour moi, l'analogie, en fait,
si j'avais une analogie à faire, c'est qu'en start-up,
on a un peu le généraliste, le médecin généraliste,
puisqu'on est censé tout balayer.
On peut pas aller en profondeur, c'est pas possible,
on n'a pas le temps. Et dans les très grosses boîtes,
comme tu le dis, René, il y a vraiment des spécialisations,
on va vraiment en espécialiser.
On a le médecin spécialiste du système Linux,
du stockage, etc., etc.
Ce qu'il y a aussi, après, ce qui se passe,
c'est que même ensuite, c'est même découper en niveau de support.
Donc, ben, suivant dans quel niveau de support on est,
voilà, on peut plus ou moins avancer sur la partie technique.
Et voilà, mais effectivement, c'est beaucoup...
C'est beaucoup dilué par rapport à ce que quelqu'un fait
dans une petite structure.
C'est clair.
Ça me permet de rebondir directement sur le truc
sur lequel je voulais enchaîner,
qui est que, malgré ce genre de différence,
qui peut être très marqué, justement entre, on va dire,
plus généraliste versus spécialisation,
qui peut paraître cliché, mais qui est quand même assez réel,
l'enjeu de ces métiers reste toujours le même.
Il faut produire des choses qui fonctionnent.
Souvent, enfin, souvent, on espère en tout cas
avec le maximum d'automatisation, de tests, etc.,
associés et qui soient documentés.
Alors, encore une fois, suivant le contexte,
l'un de ces points peut être plus ou moins prononcé.
Mais ça, je pense que quelle que soit...
En fait, la structure ne change pas le coeur de la mission
qui est associée derrière.
C'est juste le scope qui peut être plus ou moins large.
Et ça, je pense que c'est important de bien garder en tête
que ça reste les mêmes métiers.
C'est avec les mêmes objectifs de fin.
Je ne sais pas si vous êtes d'accord.
Oui, il y a une base commune, le fait de faire de la prod,
quand même, parce qu'on parle d'ops, la base est là.
On a des méthodes qui sont...
En fait, c'est la stack technique qui va changer un petit peu,
le périmètre, mais la base du métier est là.
Le type de métier est globalement même, en association.
Moi, ce que je peux dire dans les petites structures,
c'est que si on parle de DevOps,
c'est plus facile à mettre en place la coopération
entre les devs et les ops.
C'est encore plus facile quand elle se l'op,
c'est que tu as une équipe de quatre devs.
C'est là où tu as les meilleurs résultats
inhérents à la culture et au partage,
parce que tu n'as pas le choix, en fait.
Tu es obligé de te serrer les coudes.
Tu ne peux pas aller chercher, typiquement,
la culture du blam dans les toutes petites structures.
Tu ne vas pas le faire, parce que si jamais tu en ops,
il a mis par terre ton serveur, tu lui vires,
demain, tu n'as plus d'ops.
Donc, la culture DevOps, elle est plus facile
à mettre en place dans ce genre de structures,
et ça va beaucoup plus vite que dans les grandes structures.
C'est pour ça aussi que la plupart des startups
passent plus facilement au DevOps, à l'agilité,
à ce genre de choses, parce qu'en plus,
elles démarrent comme ça,
ou elles deviennent très vite,
parce qu'elles n'ont pas le choix,
elles ont besoin de s'adapter.
On en parlera plus tard de la différence
avec les grands groupes, mais il y a un vrai truc là-dessus.
On pourra parler de ça, justement,
pour les grands groupes, quand on abordera peut-être
les grands groupes, mais...
Enfin, quand on abordera les grands groupes.
Erwin, tu voulais continuer ?
Oui, oui, je peux continuer.
Moi, un truc aussi qui m'avait...
qui m'a frappé
dans les plus petites structures que je rejoignais,
c'était souvent que les gens
qui étaient non tech,
n'accomprenaient pas forcément
le métier,
ou ce que fait quelqu'un
qui travaille sur tous les sujets
d'ID DevOps.
Et du coup, je me souviens
qu'une présentation que j'ai faite plusieurs fois
chez Toucan,
c'est d'expliquer ce que fait,
quel était mon rôle, mon scope,
quand est-ce que...
comment dire-je...
Quand est-ce qu'on peut faire appel à moi, etc.
C'était pas pour me décharger de travail,
mais juste pour que les gens comprennent bien
ce que je sais faire, ce que je sais pas faire, etc.
Et je me souviens vraiment,
ça m'avait marqué,
lors de mes entretiens chez Toucan,
j'avais rencontré différents membres de l'équipe,
et je me souviens d'un échange avec Coralie,
donc si tu nous écoutes coucou,
qui m'avait dit, mais je comprends pas,
si tu ne développes pas sur le backend,
qu'est-ce que tu vas faire dans l'équipe Tech?
Du coup, c'était marrant de lui dire,
oui, mais tu vois,
ton backend n'y tourne pas, n'y part,
c'est pas magique que ça soit sur internet, etc.
Donc il faut du taf,
et moi, mon taf, c'est de faire ça à grande échelle,
et de faire en sorte qu'on puisse être plus ambitieux,
en termes de business et tout.
Mais vraiment, c'était rigolo ce décalage,
et c'est quelque chose que j'ai jamais trop ressenti
dans les structures un petit peu plus...
un petit peu plus grandes,
parce que pas forcément que les gens
étaient plus renseignés de ce que fait
des gens qui travaillent sur ces problématiques-là,
mais juste parce que ça faisait partie du tout
de l'informatique qui faisait que ça marche,
et voilà, alors que dans les plus petites structures,
en fait, on identifie bien celui
qui fait le front-end, le backend,
qui fait les tests, etc.
Du coup, toi, je comprends pas à quoi tu serres.
Et c'était un peu... je me souviens que c'est quelque chose
que je devais expliquer, donc à faire pas mal de pédagogie
auprès des autres membres, des équipes.
Parce que j'imagine, René, que toi, dans ton contexte,
tu dois pas expliquer aux gens de la compta
ce que tu fais dans la boîte.
En fait, ce qui se passe, c'est que les gens de la compta,
tu les vois même pas, en fait.
Dans une très grosse structure,
même les harages, tu les vois pas réellement,
tu ne sais pas, tu veux leur faire intiquer
quand tu veux discuter avec eux.
Et voilà, sauf si tu as un problème un petit peu particulier,
tu vas peut-être rencontrer quelqu'un,
mais de ce point de vue-là,
ça ne va pas du tout les mêmes...
Tu as des rapports professionnels avec les gens de ton équipe,
donc du coup, ils font un peu la même chose que toi,
mais justement, tu ne discutes pas forcément trop
avec des personnes qui sont dans d'autres domaines,
parce qu'ils ne sont juste éventuellement
pas dans le même bâtiment, voire pas dans le même pays.
Ce qui me vient, ce que tu expliques,
il y a le sujet du...
Quand un développeur ou une développeuse développe un truc,
surtout si c'est du front, ça se voit.
Donc les gens peuvent se projeter, ils peuvent voir,
ah oui, alors il a fait ça, il a fait ça, il a fait ça.
Quand tu parles des développeurs backend,
c'est un peu plus obscur, mais voilà.
Et puis aussi, il y a le fait que les développeurs,
il y a une imaginaire collective inhérent à la culture,
et on a déjà parlé, mais nous les ops,
on a très peu été présentés dans la culture populaire,
à part peut-être dans Mr Robot,
mais du coup, les gens ne connaissent pas notre pétier.
Donc je pense qu'en effet, il faut faire ce genre d'explications,
parce qu'amé, tu n'es pas développeur,
mais qu'est-ce que tu fais dans la vie ?
Quand je discute avec les gens,
que je leur dis, je passe dans la tech,
je passe dans un startup, ah, tu es développeur, ah non.
En fait, je gère les infrastructures.
Donc il faut expliquer, parce qu'en effet,
notre métier est inconnue du grand public,
ce qui explique aussi pas mal de choses,
de pourquoi les gens ne se dirigent pas forcément
vers l'infrastructure tout de suite.
Quand ça fonctionne, on ne parle pas de nous,
c'est plutôt, on va dire, exposer quand il y a des problèmes.
Ce qui a amélioré, c'est mon image aussi.
On est là pour résoudre les problèmes aussi.
Je veux dire que tu es vu souvent,
plutôt quand il y a des problématiques.
Oui, c'est vrai qu'on ne voit pas comme des producteurs de valeur
à l'origine, avant le mouvement DevOps,
on ne voyait pas comme des producteurs de valeur,
c'est ce que j'enseigne dans mes cours.
Maintenant, aujourd'hui, comme on crée du code aussi,
du code informatique, on crée de la valeur pour l'entreprise,
donc ça c'est bien.
Mère Joie Carwine, tu as encore noté des trucs
sur les petites entreprises, je te laisse continuer.
Oui, je disais aussi un truc qui est assez marquant,
qu'on le veut ou non, c'est les annonces,
les annonces pendant du TAF.
Je trouve qu'on voit vite la différence
entre une annonce d'une petite structure
et une annonce de quelque chose de plus établie.
Souvent dans la petite structure,
en plus surtout avec toute l'ambiguïté
qui peut y avoir derrière le terme DevOps,
globalement on va chercher des gens qui touchent à tout,
qui codent un petit peu,
qui savent manipuler des outils
comme terraformes, decibels, etc.
qu'on connaisse un système et tout.
Et du coup, dans des plus grosses structures
qui sont encore plus marquées
quand ces grosses structures sont au fond de la IT,
on ne retrouvera jamais une annonce comme ça.
Souvent c'est bien plus pointu,
on revient un petit peu à l'idée
de ce qu'on disait un peu plus tôt
sur un peu touch à tout dans une petite structure
et plus spécialisée dans une grosse boîte.
En vrai, dans les annonces, ça se voit vachement.
J'ai rarement vu une petite annonce
d'une petite structure
qui mettait un scope hyper clair
et hyper borné sur un rôle d'idée DevOps.
Ça, ça reste quelque chose assez pointu.
Encore une fois,
ça ne veut pas dire que le scope est un peu flou
et que la boîte va vous faire faire n'importe quoi.
Mais bon, c'est quand même quelque chose
à garder en tête
parce que du coup, souvent,
ça va avoir un impact sur les attentes
qui vont être derrière aussi le rôle.
Je ne sais pas si vous avez fait ce genre de remarque.
On avait parlé des annonces
de la recherche de traf pour des métiers.
On avait évoqué ce sujet.
Je ne sais pas si vous voulez rebondir là-dessus.
Oui, je vais te contredire un peu
parce que justement, j'ai réagi une photo
qui a publié exactement ce qu'on a fait.
Je vais vous montrer les affquilles sur Twitter.
Ça dépend des grosses boîtes.
Il y a certaines grosses boîtes
si c'est les RH ou les managers
qui connaissent moins la tech qui font les annonces.
Ils ont tendance à mettre la stack de la boîte.
Dans une grosse boîte, la stack de la boîte est énorme.
Je vous mets le tweet.
Vous verrez, il y a des tonnes de trucs.
Vous voyez que c'est une grosse boîte.
Il y a trop de trucs pour une petite boîte.
Il y a trop de trucs pour une grosse boîte.
Ils recrutent quelqu'un dans un service
qui fait tout ça, mais ils n'ont pas su
écrire l'annonce pour trouver la personne
qui a des faits particuliers.
Je ne sais pas, ils espèrent le mouton à 36 pattes.
Je ne sais pas.
Ça dépend des boîtes.
Il y a des boîtes qui savent faire les annonces
qui arrivent à bien spécialiser l'annonce
et à trouver une bonne personne.
Ou il y a des boîtes, même des startups,
qui n'arrivent pas à faire des annonces.
J'avoue qu'il y aura le lien
dans les descriptions de tout ça.
Le screenshot est assez édifiant.
Clairement, ça va à l'encontre de ce que je viens de dire,
mais je pense que ça reste assez exceptionnel.
J'en ai vu pas mal des annonces comme ça.
Soit dans les SS2Z,
clairement, les SS2Z recrutent,
elles balancent leurs offres et en fait,
elles ont la même offre et ils espèrent que les gens
postulent, soit dans les très grosses boîtes
qui n'arrivent pas à qualifier,
et du coup, qui ont du mal à recruter.
C'est aussi du fait.
Ça dépend aussi de l'objectif.
Je disais que ça dépend aussi de l'objectif.
Je crois qu'on l'avait un peu évoqué.
Parfois, c'est aussi présenter ta stack technique
pour dire un peu qu'on a ça
et susciter potentiellement de l'intérêt
pour les personnes.
Ça dépend dans quel sens tu vois le truc,
ou comment c'est présenté.
Si tu veux répondre à tout,
c'est un service informatique.
Dans le dernier truc,
je voulais évoquer pour parler des petites structures.
Souvent, ce pose la question de l'évolution.
Parce que travailler dans une petite structure,
il faut évoluer avec la structure.
Ce que moi,
j'ai remarqué,
dans toutes les petites structures que j'ai faites,
mon évolution s'est orientée
exclusivement vers une évolution de type managerial.
Donc, à construire une équipe,
à encadrer des gens,
et comment dirais-je ?
Alors que,
là aujourd'hui, je suis dans une autre botte beaucoup plus grande,
qui te propose clairement de tracues différentes,
soit une tracue manageriale.
Mais il valorise aussi
l'expertise pointue.
En fait, je pense que
c'est pas que la petite structure ne va pas valoriser de l'expertise,
mais c'est juste que le contexte
de la petite structure qui fait que
souvent, il faut que tu sois touché à tout,
donc on revient à ce qu'on a dit un peu plus tôt,
tu ne vas pas encourager la personne
à se perfectionner dans un truc hyper pointu.
Bien sûr, encore une fois,
il n'y a pas de règles ou quoi que ce soit, mais de façon générale,
on peut comprendre la démarche de ne pas pousser vers ça.
Et donc,
c'est pour ça que, souvent,
dans les petites structures qui, on va dire,
qui, en fait, ne font pas
de 100 personnes à 500 en 3 ans,
et bien,
l'évolution assez naturelle
des gens qui sont là depuis longtemps,
ça reste quand même souvent, en tout cas, sur les parties infras et tout,
ça reste quand même souvent du management et d'accrasation d'équipes,
en cas d'endroit, etc.
Et donc, du coup, c'est aussi pour ça que
il n'arrive que dans les petites structures,
voyons un petit peu le plafond de verre,
qui soit, on va dire, professionnel en termes de carrière
ou plafond de verre en termes de
compétences à aller creuser,
les gens partent pour chercher
un autre défi.
Je ne sais pas si vous avez un point de vue différent sur la question.
Non, mais je vais compléter ton point de vue.
C'est pas étonnant que dans une petite structure,
on ne te demande pas d'être spécialiste, parce que
de toute façon, tu ne peux pas devenir spécialiste dans
une petite structure, je m'explique.
Tu n'as pas la quantité de travail et la diversité
de travail suffisante pour devenir un spécialiste
de ta thématique ou de ton métier, puisque ton métier
est divers. C'est pour ça d'ailleurs que tout un tas
de petites boîtes et de petites start-ups font appel à des frilances
qui sont spécialisées pour certains projets précis.
Pour moi, la voie
qui serait idéale
ce serait quand tu arrives à ce plafond de verre
et que tu veux justement évoluer,
ce serait soit de réduire ton temps de travail avec la
Corte, cette entreprise, de devenir associé de l'entreprise
et d'aller faire un temps partiel ailleurs pour
améliorer tes compétences, soit devenir frilance,
continuer à intervenir dans cette entreprise tout le temps
étant associé. Je tiens
de côté associé, c'est mon côté entrepreneur, mais bon
évoluer dans l'entreprise
et d'avoir des parts, ça peut être important et le fait
de voir plusieurs contextes, ce que tu peux voir
dans une grande boîte mais que tu ne peux pas voir dans une petite structure
c'est important pour devenir spécialiste. Moi je n'ai jamais
autant progressé que depuis que je suis frilance et que je vois
plein de contextes différents, des problématiques différentes,
des organisations différentes. Et donc ce n'est pas étonnant
en fait que dans les petites boîtes, tu ne peux pas devenir
spécialiste. La structure fait que ce n'est pas possible en fait
et donc malheureusement il faut soit quitter la boîte, soit réduire
ton temps de travail pour ça.
Après le côté managerial, Montora,
pour moi il y a ces deux sujets différents
mais en effet Montora technique
et organisationnelle, il peut être là
dans les petites boîtes mais qui deviennent grosses
du coup et qui grandissent.
Mais pour moi la seule évolution possible
dans les petites structures c'est de devenir associé
et que la boîte nous appartienne.
Ma vision c'est pour ça que je veux faire
une start-up coopérative pour que la start-up
puisse appartenir aux salariés qui le veulent aussi.
Je ne sais pas ce que vous en pensez de ça.
Je ne suis un peu mal pas là c'est pour juger parce que je ne connais pas les petites structures
donc voilà.
Je peux dire que par contre dans les grandes structures
où on est censé peut-être être un peu plus spécialisé
je ne suis pas sûr non plus
qu'il y a toujours
comment dire.
On peut être expert mais pas forcément
non plus sur les toutes dernières technologies parce que ce qui se passe
c'est qu'une grosse structure ça a beaucoup d'inertie, ça n'a pas l'agilité
de plus petites structures du coup on se retrouve parfois aussi avec des technologies
qui peuvent être pas forcément complètement rajouts.
Donc ce n'est pas non plus
ce que je voudrais dire c'est que
ce n'est pas parce qu'on est je pense dans une petite structure
que techniquement ça ne peut pas être
à la page
et puis pointue aussi à avoir des connaissances pointues
sur des sujets et voilà je pense
qu'on a plus peut-être
la possibilité de le faire dans une grande structure mais c'est pas
quelque chose qui est obligatoire.
Je ne sais pas si c'est très clair ce que j'ai dit mais
C'est un peu clair
mais du coup ça me fait dire que peut-être
c'est nous qui avons pas été très clair auparavant
mais c'est que quand on parle de spécialisation c'est plus
avec un scope plus borné
dans les plus grandes structures que dans les petites
où le scope est souvent, enfin les frontières
et les limites
de ton taf
peuvent très facilement être dits
pourreuses pour que tu ailles faire autre chose
et c'est plus là dessus je pense qu'il faut
J'ai eu l'huistre ça
typiquement dans la première start-up
dans laquelle j'étais, j'étais l'administrateur
système, l'ops, le devops etc.
J'ai compris la base de données donc c'est moi qui m'étais en place la base de données
post-grève QL etc.
Mais j'administrais aussi le cloud
je faisais tout avec terraforme avec Ansible
je devais connaître Amazon Web Services, je devais connaître les paquets
et installer sur les systèmes donc je ne connaissais pas, je devais tout faire
c'est pas pour ça que j'étais DBA en fait
c'est pas parce que j'administrais la base de données que j'étais DBA et que je savais comment
la tuner, comment bien configurer
les tables space, comment tu vois
alors que chez Casino sur lequel j'ai eu des contacts
avec les DBA, les DBA que j'avais en face de moi
ils savaient ce que c'était un table space
ils savaient aussi comment les tuner
ils savaient comment administrer les bases
ils connaissaient les différences entre les bases Auraq, PostgreSQL
qu'est ce qu'on peut demander à l'une à l'autre etc.
comment faire des snapshot, des snapshot
comment faire du data recovery facilement avec la gestion de logs
enfin plein de trucs que moi je serais incapable de faire aujourd'hui
et c'est pas parce qu'ils travaillaient avec PostgreSQL 10
qu'ils n'étaient pas spécialisés
alors qu'aujourd'hui on va lancer PostgreSQL 16
bon bref, l'idée est là
c'est qu'ils ont une connaissance de l'armé-tier plus pointue
parce qu'en effet ils passent leur temps à faire ça
que nous on start up ou on fait tout le reste
tu vois ce qu'on veut dire René ?
oui bien sûr, c'est aussi un peu pour
parce que je veux dire c'est aussi parfois dans une grande société
ça dépend où tu vas te trouver
parce qu'il y a des... tu vas avoir par exemple si t'es dans le DBA
niveau je n'en sais rien de trop
ce qu'on va te demander justement c'est de creuser cette expertise
mais par contre si par exemple tu te retrouves dans des nouveaux supports plus
plus... enfin moins éloi
ce qui va te demander c'est peut-être plus de
je ne sais peut-être pas le très bon terme mais de la bataille
c'est-à-dire de fixer des problèmes et
c'est quand tu n'y arrives plus tu passes à la suite donc
alors on est d'accord René mais ce que disait Erwan
justement c'est que dans une petite entreprise à un moment donné
tu ne peux plus évoluer dans une grande entreprise
même si on te demande ça à un moment donné tu peux changer de service
c'est ça en fait qu'on veut dire je ne sais pas si tu le vois
voilà donc c'est pour ça que moi je dis
la structure d'une petite entreprise fait que tu ne peux pas devenir spécialiste
à un moment donné tu peux demander une mutation interne
tu vois c'est plus facile
c'est plus facile d'ailleurs
puisque c'est plus facile et qu'on a abordé les petites entreprises
parlons des moyennes entreprises, les entreprises de
grosso modo entre 50 et 500 personnes
Erwan, tu vas ouvrir le bal
tu as inondé les notes de plein de trucs
oui et puis en fait je vais commencer par
par la note qui est écrite en première
mais moins un truc qui m'avait frappé
et c'est une question que
que je ne m'étais jamais posé dans des plus petites structures
c'est le fameux débat entre une équipe plateforme
et le fait que les squads de dev
et un équivalent de DevOps s'est serré
dans leur team pour les aider
et j'ai remarqué alors c'est pas le cas là où je suis aujourd'hui
puisque c'est pas vraiment un sujet
mais dans plusieurs boîtes dont je ne citerai pas le nom
ce débat faisait hyper rage
et en fait moi je ne sais pas dire
quel est le meilleur truc
j'imagine que bien sûr tout dépend du contexte
etc, de la maturité et tout
mais c'est un débat que je voyais
sans cesse
quand j'étais chez Diza il y avait un peu ce débat
mais qui n'avait jamais trop abouti
mais je ne sais pas trop d'ailleurs ce que c'est devenu par la suite
mais ce côté de est-ce qu'il faut une équipe transverse
de DevOps on demande
ou est-ce qu'on les intègre directement dans les squads
et donc du coup j'imagine que ça change vachement
aussi le travail au quotidien
suivant que la boîte choisisse une organisation plutôt qu'une autre
puisque du coup très vite
tu peux peut-être te retrouver avec des scopes plus ou moins larges
justement peut-être que une équipe plateforme
te pousse à avoir une vision la plus large possible
alors que si tu es inclus dans une équipe
tu te concentres sur elle
peut-être que d'ailleurs, vous n'êtes pas connu
ce genre d'organisation et de débat
tu pourras nous en parler
mais moi je me souviens que du coup
ce qui m'avait frappé dans les moyennes
ce qu'on a appelé les moyennes boîtes
c'était en partie ce sujet autour de l'organisation
qui est quelque chose qui existe pas
dans les plus petites structures
parce que tu n'as pas à t'organiser comme ça
donc tu ne réfléchis même pas ce sujet
René tu veux répondre ou je réponds ?
Vas-y je te dis
Pour moi dans les petites boîtes
tu n'as pas cette question-là parce que la team plateforme
déjà tu ne l'intégras pas c'est ton plan de provider
Pour moi ce sujet-là
j'ai envie de répondre
si tu as les moyens tu fais les deux
c'est-à-dire que tu as des équipes d'infrastructures
qui proposent des outils aux équipes de dev
des outils type Kubernetes, Azure Service, Cloud Azure Service etc
Par contre dans ton équipe de dev tu intègres un Ops
qui va aider les devs à bien penser
à bien penser l'application, à se faire qu'elle est bien cloud native
qu'elle respecte bien les bonnes pratiques
et que tu puisses en plus parler avec les gens des équipes plateformes
parce que tu es un Ops et que tu comprends les problématiques
mais par contre tu es intégré à l'équipe de dev
c'est-à-dire que ton seul objectif c'est que l'application que vous développez
elle soit bien envoyée sur les plateformes de production
et qu'elle respecte bien tout et qu'elle soit la plus clean possible
Pour moi idéalement il faudrait faire les deux
Je vais peut-être un peu caricatural mais je pense que c'est un petit structure
tu as peut-être un produit phare, tu as un appli un peu phare
ou quelques applis, dans des grosses structures et même des problématiques
c'est quand tu commences à avoir par exemple l'Amazon
de casser 150 microservices pour ces pages, ça doit faire 150 équipes
tu es obligé forcément de trouver comment tu t'organises
c'est tout de suite beaucoup plus compliqué
je vais juste prendre un exemple, je vais parler de Kubernetes
ça fait longtemps que je n'en ai pas parlé en plus
Dans Kubernetes il y a plusieurs niveaux
il y a Textplot, la solution, tu administres ton Kubernetes
tu installes les couches Kubernetes, tu gères le réseau, le stockage etc
la deuxième couche c'est tu installes dans ton Kubernetes
les applications dont tu as besoin pour faire tourner l'infrastructure de Kubernetes
tu installes Prometheus, tu installes Argo CD, Spinecker, whatever
ça c'est encore un métier d'Obs mais c'est pas tout à fait le même
et tu as encore un autre métier d'Obs qui est
tu vas définir les applications, c'est quoi les ressources qui vont définir ton application
est-ce que tu vas avoir un, deux, dix pods, plusieurs microservices, plusieurs pods dans ton application
est-ce que tu vas avoir un, plusieurs namespace, est-ce que tu vas avoir besoin de stockage etc
ça en théorie c'est pas forcément les devs qui vont définir ça
c'est un OBS plutôt qu'il est intégré à l'équipe de devs qui va en discutant avec les devs
savoir, bah voilà, moi il me faut un endpoint externe ou alors il me faut une base de données interne au Kubernetes etc
et donc tu vois que tu peux avoir plusieurs couches d'Obs dans des grosses structures dans ton Kubernetes
dont un qui peut être intégré dans l'équipe de développement
En fait le point que je voulais mettre en avant c'est que autant les méthodes et organisations de devs
je pense que globalement on retrouve la même chose dans des petites et moyennes grosses entreprises
autant justement le sujet, les sujets d'e-devops, bah voilà, il y a des bases sur les organisations les plus,
sur l'organisation la plus idouane à avoir suivant justement le nombre de services que tu gères,
la taille de tes équipes, la quantité de run cutouts etc
Pardon excuse moi je t'interrompue
Non non non vas-y je t'écoute
Après ce qui peut aussi se passer c'est que tu as des problèmes de masse critique c'est à dire pour certaines équipes genre type sécurité
tu peux, l'idéal c'est peut-être d'avoir un expert sécurité par équipe de devs et par produit
sauf que peut-être que ça reviendra beaucoup teux du coup faut aussi trouver des compromis
Voilà c'est pas un sujet simple en fait
Moi je dis souvent que finalement l'organisation et l'e-devops c'est quand même un chemin personnel de l'entreprise
et l'entreprise doit trouver son organisation
elle doit faire des tests, aussi les personnes de l'entreprise doivent faire des tests
mais bien sûr cette test là elle doit être guidée par la culture de devs et la culture de l'entreprise
et en fonction de tout ça tu arrives à trouver ton organisation
mais il faut tester et parfois les moyennes et les grosses boîtes elles font pas ce genre de tests
et elles s'arrêtent juste à l'automatisation mais peut-être qu'on en parlera
Vas-y Yarouen justement il y a encore quelques petits points que tu voulais aborder
Non bah enfin pour les moyennes je pense en tout cas ce qui me paraissait le plus marquant
on vient de l'évoquer mais après on revient à cette histoire que effectivement souvent
dans les plus grosses structures les équipes qui s'occupent de l'infra et c'est-à-dire elles sont quand même bien identifiées
et du coup ça leur donne je pense une légitimité qui est un peu plus
et une légitimité à un scope qui est un peu plus facile en tout cas
à identifier, à parler et à être reconnu dans la boîte donc on en revient
en opposition à ce que dans les plus petites structures
où je devais expliquer ce que je faisais en gros
je pense que c'est un peu ça et puis oui le fait que dans les plus grandes structures
les scopes sont forcément plus réduits donc on revient à cette histoire
de on peut probablement creuser plus facilement les sujets
je pense par exemple à une équipe qui est dans la boîte où je suis là
il y a une équipe qui gère tout un tas de services à destination des devs
du coup ils sont devenus experts en GitLab je sais pas quoi
et ça c'est clairement quelque chose qui ont développé de par cette activité
avec ce scope plus réduit
donc du coup ça reprend une partie des choses qu'on a évoquées
du coup je pense qu'on peut passer au vrai sujet qui est les vraies fat boîte
je veux rajouter quelque chose
je pense inérent au PME, au Moyen boîte
c'est que la plupart des moyennes boîtes à leur quelle phase de la tech
si c'est des PME qui ne font pas de la tech donc le service informatique est plutôt réduit
il peut y avoir 50 sènes de personnes
en fait les PME, j'ai l'impression
ont du mal à passer au DevOps parce qu'elles n'ont pas la masse critique
qui fait qu'elles peuvent engager une transition qui est coûteuse pour leur taille
je veux dire tu fais une transition à 5
ça n'a pas le même coup que si tu fais une transition à 100, 200, 300 personnes
sauf que ces moyennes boîtes peut-être qu'elles ont moins les moyens
et je sais pas, c'est une sensation que j'ai que les grandes boîtes
je sais pas dans quelle mesure les PME arrivent à se transformer
et elles ne font pas encore les choses à l'ancienne
en tout cas moi j'ai eu des prospects
qui ont des sitios, voulaient passer au DevOps
mais dont les directeurs et directrices disaient
maintenant ça a toujours bien marché comme on fait
pourquoi est-ce qu'on irait dans le DevOps parce que ça nous coûte cher
en tout cas c'est un discours que j'ai souvent entendu auprès des prospects
je sais pas pourquoi, moi je m'inquiète pour les PME
parce que soit les PME qui ne passent pas au DevOps
elles vont se faire bouffer par les startups qui arrivent
soit elles vont se faire écraser par les grandes structures
qui ont la capacité financière de faire de l'automatisation
pas forcément faire du DevOps mais de faire de l'automatisation
qui va leur donner encore un avantage concurrentiel
je sais pas, je pose ça là et je dis que peut-être il y a ça
et ouais, là on va pouvoir passer aux grandes structures
mais avant il est temps de rappeler à notre chère auditeur et auditrice
qu'il faut qu'il s'abonne au podcast pour justement être notifié
quand il y a des épisodes qui sortent ou mieux
ou mieux ou aussi s'abonner à la chaîne YouTube pour être notifié
soit quand il y a des épisodes qui sortent soit quand je prévois des live
parce que des fois je prévois des live de manière impromptue
où je sors des vidéos comme ça
donc c'est important de s'abonner pour avoir les notifications
et maintenant on va pouvoir parler des grands groupes
des grosses structures, les boîtes qui ont plus de 500 personnes
les mastodontes, n'est-ce pas René ?
tu connais ça, des boîtes qui ont plusieurs milliers d'employés
avec des services informatiques de plusieurs centaines de personnes
avec des services de services
est-ce que tu ouvres le bal René ?
oui je peux
ce qui est pas tout heureux en fait
ce n'est pas si évident que ça en fait
je suis pas sûr que ce soit finalement plus facile
pour ces grosses entreprises de faire des transitions de l'opse
pour plusieurs raisons et je pense une des premières
c'est que souvent ces entreprises
elles sont là depuis un petit moment
elles ne sont pas à parier une manière spontanée
avec plein d'employés
et du coup elles existent là depuis un certain temps
du coup elles ont un historique je pense qui est conséquent
elles ont souvent appliqué beaucoup de méthodes
donc les fameuses méthodes et tout
où justement ça a une tendance à beaucoup siloter
je pense les équipes
et du coup quand on arrive avec
l'aspect des voips
on cherche justement à casser ces silos
c'est pas évident
on a forcément une grosse résistance
je pense aux changements
forcément il y a beaucoup de monde
il faut convaincre plus de monde
alors forcément dans le lot
il y a des gens qui vont être hyper moteurs
il y en a d'autres qui vont être neutres
et puis il y en a aussi qui vont être en résistance
voilà donc le nombre
le nombre apporte pas forcément
de la facilité je pense
pour dans le cadre de transition des voips
je te laisse te donner un peu ton avis
vu que tu connais ce contexte
oui oui je suis d'accord
les très grosses boîtes
on parle des boîtes qui ont plusieurs centaines de personnes en informatique
c'est très dur à les faire bouger
parce que déjà il y a beaucoup de monde à faire bouger
et ensuite parce que tu as plein de managers
partout dans tous les sens
il faut que ces gens là ils se mettent d'accord
et comme tu le dis
elle pratique l'itile
c'est un sujet qui m'intéresse depuis longtemps
parce que moi je suis certifié itile aussi
et le fait de allier itile et de la développe
je pense que c'est possible
je me suis juste pas penché
sur le comment faire
parce que dans l'itile pour toi qui connaît peut-être pas
tu as des demandes qui passent
qui passent entre services en fait tout doit être tracé
sauf qu'en fait itile ne dit pas comment ça doit être tracé
donc aujourd'hui ils utilisent des logiciels
dits, tsm pour tracer toutes ces demandes
mais une demande elle pourrait être tracée dans un comit de guide
ça marcherait parfaitement bien je pense
mais par contre en effet il y a de fortes résistances
à faire évoluer les choses
et pour moi il y a peut-être un sujet
je vois que tu l'as noté
moi en tout cas quand j'ai ce genre de
de grands prospects je leur dis
écoutez on va faire une transition
on va commencer par un projet pilote
prenez une équipe
une application qui est peut-être pas forcément la plus critique
mais on la prend
on monte l'équipe
et on la fait passer elle au DevOps
c'est à dire qu'on fait le test
vous montrez que ça marche
avec une équipe de 5-10 personnes
vous montrez que ça marche
et une fois que l'équipe elle est passée au DevOps
que vous avez mis des devs et des ops
puisque moi je promets les équipes pure disciplinelles
vous mettez des devs et des ops dans l'équipe
vous montrez que ça marche, vous montez que vous arrivez à déployer régulièrement
facilement et qu'il n'y a pas de problème
vous réduisez votre coût de maintenance parce que vous avez un moins de problème aussi
ça c'est un sujet dont on parle
une fois que vous avez prouvé ça
ce sera plus facile de faire
de répandre le mouvement dans l'entreprise
parce que déjà il y aura la première équipe
qui pourra répandre ses bonnes pratiques autour d'elle
et puis surtout il y aura un précédent dans l'entreprise
moi c'est comme ça que j'essaye d'aborder ça
j'ai pas encore réussi à convaincre une entreprise de le faire vraiment
parce que la plupart des grosses entreprises ont un autre problème
c'est qu'elles ont une idée préconcule d'idée DevOps
et elles pensent que c'est l'automatisation
ça c'est un autre vrai sujet dont j'aimerais qu'on parle
c'est que pour elles le DevOps c'est le déploiement
continue et c'est tout, ça s'arrête là
on va faire du encembre, on va faire du terra-fort
non mais je caricature un peu mais
non non mais je pense que c'est pas si caractérique que ça
c'est qu'en fait je pense que tout le volet
est organisationnel
et un petit peu aussi la philosophie parce qu'il faut la communiquer
etc donc bah t'as beaucoup de gens à convaincre
expliquer, former etc donc ça c'est pas forcément évident
enfin ça prend déjà du temps
je pense que c'est quasiment si déjà le top management
est pas convaincu ça va être, je pense que c'est mort
mais bon on pourrait discuter
mais voilà et souvent je pense que
ça c'est tellement difficile de changer
éventuellement les organisations aussi parce que quelque part
tu l'as dit il y a plein de managers donc du coup ça veut aussi
peut-être vouloir dire que certains vont être mis en cause
du coup volet organisationnel à changer
et mon avis est pas évident et du coup
la solution peut-être un peu de facilité
enfin c'est facile de dire ça mais c'est de faire
ce qui est relativement le plus simple c'est de mettre des outils
en place sans forcément trop changer
comment ça fonctionne et voilà moi
c'est un peu mon sentiment et pour moi
je pense que dans des plus petits structures on est plus proches
de l'état de l'art de ce que devrait être le DevOps
que dans des grandes structures parce que bah voilà il y a toutes ces
tinerries et le fait que ce soit pas flexible
qui fait que c'est je pense c'est assez difficile
à mettre en place
est-ce que tu es d'accord avec moi ou...
Ah ouais complètement et je pense que tu as tout à fait raison
que les boîtes elles voient la facilité de API
alors c'est pas étonnant de
passer par l'automatisation en premier parce qu'en effet
c'est plus facile c'est technique mais en plus ça le retour sur investissement
le plus important
et même moi si j'avais à proposer un truc
à faire une entreprise c'est commencer par l'automatisation
par contre mettez un
verniculture avant quand même un petit verniculture et puis après
travailler là la culture, faire la diffusie etc
Pardon excusez-moi
je pense que par exemple ça c'est ce que tu dis c'est enfin je trouve ça très important
parce que tu peux mettre je sais pas un GitLab si on veut
mais si personne va dessus et l'utilise
bah voilà t'as un peu perdu après
c'est mieux que rien de
démarrer par les outils etc je pense
mais pour moi voilà
il manque un bout quoi et un bout un peu majeur
Ouais il manque un bout et je vois que tu l'as noté parce que moi je l'ai vu
beaucoup dans les grandes boîtes mais énormément
c'est euh... et je parle
dans mes formations je dis le DevOps n'est pas une équipe
le DevOps n'est pas une équipe c'est pas un métier c'est pas une équipe
tu l'as mis, anti-pattern, équipe DevOps
parce que si t'as des problèmes avec
tes équipes de développement et tes équipes d'ops
alors oui dans les grands structures
comme ça t'as pas juste un service d'ops
t'as plusieurs services d'ops t'as le service des administrateurs
système Linux, le service des administrateurs système Windows
René nous en a parlé le service des gars qui font du réseau
du stockage etc etc t'as des tonnes
de service t'as des silos entre les devs et lesops
t'as des silos entre les devs et les devs et t'as des silos entre lesops et lesops
et donc si tu viens rajouter une équipe DevOps
l'équipe qui va mettre en place des outils dit DevOps
au milieu de tout ça bah je crois que tu l'as dit
René dans les notes vas-y je te laisse les lancer
qu'est-ce que ça fait, qu'est-ce que ça donne ? Ah bah pour moi t'as juste créé un
enfin si tu le fais comme ça brussellement t'as juste créé un silo de plus
et pour moi tu t'achètes plus de problèmes que de
enfin que de fluidité en fait mais après
après c'est peut-être
enfin parfois je sais pas si c'est un mal nécessaire
ou pas mais je peux apercevoir
Moi tu vois typiquement l'équipe DevOps
que je vois dans les entreprises parce que clairement
des fois je vais dans les entreprises ils m'ont dit ah bah voilà l'équipe DevOps
pour moi c'est l'équipe plateforme dont on parlait tout à l'heure
c'est l'équipe qui va outiller les devs et lesops
qui va leur proposer des plateformes pour moi elles devraient être nommées comme ça
l'équipe plateforme et on devrait pas la nommer équipe DevOps
on devrait la nommer équipe plateforme et on devrait infuser le DevOps
dans l'entreprise en leur expliquant bah voilà lesops et les devs
ils vont travailler ensemble
avec ces nouveaux outils qu'on va vous mettre à disposition
et pendant qu'on met à disposition ces nouveaux outils pour quelques nouvelles équipes
les anciennes équipes on va les former ils vont changer
etc etc alors bien sûr
c'est plus long et plus coûteux de faire ça
par contre tu vas avoir beaucoup de
enfin selon moi tu vas avoir beaucoup de résultats
parce qu'on le sait
là du coup je vais renvoyer au rapport d'ORA
dont j'ai parlé dans un autre épisode
d'actu DevOps il y a quelques mois mais
ce rapport là
il nous prouve par des chiffres que
quand tu mets en place de la culture et des outils
et des pratiques tu y arrives et
tu accélères tes déploiements
tu réduis le temps
de récouverts, le temps de
de remises après incident, tu réduis ton monde d'accident
il y a plein de trucs que tu vas gagner
en faisant ça moi je suis désolé je suis parti dans un long vlog
Ronny je te remets la parole
il n'y a pas de soucis et juste peut-être
petite anecdote juste pour montrer à
Airwan qu'il a eu du mal parfois à faire passer
à ses collègues qu'il a été son rôle
mais je pense que tu peux aussi avoir des problèmes
de communication dans les grandes structures
ou de mal compréhension de ce qu'elle développe
parce que moi on m'a déjà dit bah ouais elle développe c'est super on va plus avoir besoin d'ops
du coup il y a eu un problème je pense quelque part
dans la compréhension de ce que c'était bon ça c'est une petite anecdote
mais voilà c'est pas forcément plus clair
dans les grands groupes que dans les petits
enfin dans des petites structures
et après j'avais un autre point
ça c'est quelque chose que j'avais
qui avait été évoqué par Quentin Adam à un moment
et je pense qu'il a pas forcément tort
c'est que ce qui peut se passer aussi je pense dans des grands groupes c'est que
les lignes budgétaires sont pas forcément les mêmes
il y a une ligne budgétaire pour le dev
une ligne budgétaire pour l'exploitation
et du coup le fait si c'est le cas
du coup ça devient extrêmement compliqué de trouver je pense de la synergie
parce que bah ce qui va se passer c'est que
certaines choses qui vont être faits côté dev
ne n'ont pas que des budgets côté run on va dire
une production et du coup ça va pas
son point c'était de dire bah ça va pas aider
à faire en sorte que ça fonctionne
et pour lui je pense qu'il a pas tort
et à un moment si on veut que les deux
travaillent bien ensemble
je pense qu'il faut que bah voilà ce soit
un budget un peu commun et que ce soit vu
voilà que entre guillemets on sache
que quand on fait une action côté dev si ça impacte
financièrement côté hop c'est normal ou vice versa
et voilà et pas chercher à optimiser
les deux côtés à tout prix parce que sinon
bah on va vite se tirer dans les pattes
je vais aller plus loin parce qu'en fait
je le mets dans ma formation
soit mon cours que je donne soit la formation
des webs mindset donc du coup je vais en parler un peu
en fait ça va même encore plus loin que ça
c'est que il y a
alors là faut que je fasse un peu de comptabilité
dans la comptabilité il y a une notion de ce qu'on appelle investissement
c'est quand on crée
de la valeur et quand on
paye pour un développement informatique on crée de la valeur
et on va investir
et donc comptablement on va amortir sur les années
à venir c'est à dire que le salaire
de ton équipe de développement elle va pas être
très partie juste sur une seule année mais sur plusieurs années
donc potentiellement pour ta société
ça va coûter comptablement moins cher ça c'est que du comptable
bref je rentre pas là dedans mais grosso modo
comptablement tu vas avoir tendance à avoir
les équipes de développement et les devs
comme une plus-value pour ton entreprise
comme de la création de la valeur
historiquement les ops ils maintiennent
les infrastructures en condition opérationnelle
c'est juste des coûts il ne crée rien
c'est juste au même titre que ta ramette de papier
que ton... non je vais pas prendre la prime entre
que je sais pas
l'électricité etc c'est un coût
pour ton entreprise
il est évident qu'une entreprise qui veut améliorer sa
rentabilité qu'est ce qu'elle fait elle va soit
essayer de gagner du chiffre d'affaires soit réduire les coûts
donc qu'est ce qui se passe dans ce cas là et bah tu vas avoir tendance
à faire réduire les budgets d'ops et dans ce cas là
tu vas avoir les ops comme vraiment un poids pour ton entreprise
quand tu mets en place le devops
et que tu crées du code informatique
que tu crées du code d'infrastructure
que tu améliores ton... on continue ton infrastructure
là tu crées de la valeur pour ton entreprise
et là tu peux aussi amortir
les budgets en très grande partie
de tes équipes d'ops qui font du devops parce que
il y a cette partie automatisation qui crée de la valeur pour ton entreprise
parce que tu crées un...
comment dire... comme tu crées du code
tu crées un bien immatériel pour ton entreprise et donc là
tu vas rejoindre la partie développement
ou tu vas créer de la valeur et donc budgetairement
historiquement quand tu sépales les deux
tu crées un silo de plus en fait
qui se voit de partout alors que là avec le devops
c'est comme ça que je l'explique si tu changes ton paradigme
de penser en tant que chef d'entreprise tu vas avoir tendance à dire
ouais ok mais je crée de la valeur aussi pour l'entreprise
je sais pas si c'est aussi
ce que tu as vu en tête
ouais ouais c'est... oui oui c'est ça
ce coup de centre de profil
c'est pas...
ça c'est pas très bon coup je pense
je mettrai le lien de la conf de compta
dans les notes de la description
mais si vous voulez mieux comprendre aussi cette partie là
vous pouvez justement aller suivre ma formation
devops mindset j'ai une grande partie sur ce point là
entre autres choses
justement sur l'état d'esprit de devops qu'on peut travailler
voilà donc après pour conclure
enfin voilà pour...
après il y a d'autres aspects
il y a l'aspect quand même je pense aussi politique
il y a beaucoup de monde il y a des gens qui...
je pense que c'est aussi peut-être plus difficile de faire corps comme...
alors je connais pas les petites structures
mais j'ai l'impression que les gens ce que tu disais
ils sont animés ils ont envie d'avancer tous ensemble
dans une petite structure et il y a moins de prise de tête
des différents égaux du mec qui veut
se faire briller auprès du chef etc
enfin voilà et du coup
voilà je pense que ça existe moins dans les petites structures
et...
voilà je pense après je les connais pas assez
ça existe quand même
ouais j'imagine mais...
mais c'est quand même moins...
enfin voilà je pense c'est moins prononcé
ça existe quand même mais en fait
quand tu es dans une petite boîte c'est plus facile
de voir la destination
que va prendre la boîte parce que c'est plus facile à 10
de faire transiter l'information et de dire
bah voilà on va dans ce sens là
que quand t'es 30 000 100 000
et donc quand t'es 30 000 ou 100 000
ça doit passer par la culture de l'entreprise
et donc la culture de l'entreprise tu dois avoir
une culture de transparence très importante
où tu dois dire
bah l'objectif de la boîte c'est ça
et tu dois partager en fait
les devs et les ops
et tout le monde dans l'entreprise doit partager
ce chemin
que trace la boîte
et on doit sortir du chemin des services en fait
c'est souvent aussi l'autre truc qu'on voit
c'est que les services ils ont des objectifs
complètement différents alors qu'en fait
on devrait voir les objectifs de la boîte
c'est la boîte qui est importante
pas le service je veux dire
ah bah...
il faut qu'on fasse
une discussion autour du concept des ochers
parce que c'est censé être ça
c'est t'as des objectifs à l'échelle de la boîte
qui redescendent et qui sont adaptés
du coup pour chaque équipe
mais qui du coup
découlent directement de ce que la boîte
s'est fixée comme cap
donc c'est...
après effectivement c'est probablement plus facile
de faire ça dans des plus petites structures
c'est un autre sujet
c'est plus facile mais la coopération
je suis en coopérative on est
deux cents dans la coopérative
dans une coopérative d'entrepreneurs
on est pas deux cents chez Lydra
on est six, bientôt sept
ça c'est un autre sujet
on apprend à coopérer
c'est pas une érin
on doit se former à ça
la culture, la transparence et la communication
c'est quelque chose qui doit être travaillé
si tu la travailles pas
t'as les grosses boîtes avec ces silos etc
pour ça que l'état d'esprit développe
pour moi il doit transcender
les équipes IT
et il doit aller de partout
la culture du partage
la transparence et la meilleureation continue
ça doit être dans toute l'entreprise pour moi
mais bon c'est ma convection profonde
voilà, après j'étais peut-être
voilà un peu critique
après il y a aussi
des bons points
c'est pas pour ça qu'on peut quand même
y trouver son compte
moi personnellement si j'y ai trouvé mon compte
je me suis beau
et les avantages c'est effectivement
que par exemple sur les équipes d'infra
on peut avoir du matériel
à top
voilà il y a des moyens
pour les licences
voilà on va accéder à des choses
qui sont peut-être
après
il y a la taille
parce qu'il y a des moyens financiers
qui ne sont pas possibles dans les petites structures
voilà et puis comme vous le disiez
peut-être plus de perspectives
d'évolution de carrière par moment
effectivement
c'est clair que chaque taille
a ses avantages et ses inconvénients
parce que dans une grosse structure
en théorie
tu ressens moins la pression
alors
je sentais la pression parce que j'étais dans une équipe
qui gérait les applications
mais honnêtement entre la pression que j'avais
chez Casino Monopri
et la pression que j'avais dans ma petite start-up
honnêtement j'avais plus de pression dans ma petite start-up
j'étais seul à gérer tout
toute l'infrastructure
c'est plus confortable dans les grandes entreprises
c'est plus lent aussi
parce que mine de rien en 8 ans
chez Casino Monopri
j'ai fait peut-être moins de choses
diversifiées que dans une petite start-up
les deux sont bien
en fait ça dépend ce qu'on cherche
mais par contre c'est vrai que le DevOps
si on peut
si on peut tirer le fil
le DevOps en fait dépend des structures
et comment elles le mettent en place
et je pense que les grandes entreprises
ont encore du chemin à faire pour la mise en place
du DevOps mais en même temps
on sait en France la mise en place du DevOps
elle n'est pas encore là
et on pourrait parler un jour je pense
de la mort du DevOps qui à mon avis
n'est pas près d'arriver
mais bon ça c'est mon avis profond
et après conclusion un peu personnelle
c'est que voilà moi je suis toujours
un petit peu... enfin de ce que j'ai vu
je suis loin d'avoir tout vu
voilà c'est un peu
c'est un...
voilà je pense qu'on cherche aussi peut-être
ce qu'on connaît pas et je me dis
mais des fois ça me paraît bien compliqué
et on se prend des fois un peu la tête
pour pas grand chose ça doit être beaucoup plus simple
on est plus petit structure
et ouais c'est parfois un peu décevant
mais voilà
c'est ça reste personnel
ben on a bien fait le tour
finalement du sujet
on a bien... on a bien
discuté
on a bien présenté tout
tout ce qu'on a vu
on est pas évidemment on n'a pas tout vu donc
hésite pas en description
en commentaire de nous dire ce que toi t'as remarqué
moi j'ai un truc à te dire
c'est que si tu cherches un emploi
tu peux
aller voir mon jobboard
My Little Team m'a proposé de créer
un jobboard 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 jobboard 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
passé par mon jobboard
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 jobboard me permet de gagner de l'argent
et donc de financer les podcasts
que tu aimes tant
donc rendez vous sur
vue.fr
slash jobboard-devops
mais sinon
tu trouveras le lien en description
attends
si t'es manager
dsi ou directeur d'entreprise
et que tu cherches à recruter
des personnes qui sont intéressées par le DevOps
tu l'auras compris puisque t'écoutes ce podcast
c'est l'endroit idéal
n'hésite pas à déposer tes offres d'emploi
sur mon jobboard
c'est sur vue.fr
slash jobboard-devops-recrutes
mais c'est pas grave
le lien est aussi en description
je vous remercie à tous les deux de cette co-animation
de cette table ronde
et puis je vais, comme d'habitude
vous laisser le mot de la fin
et pour ne pas commencer par renais
je vais commencer par Juan
qu'est ce que tu voudrais dire à notre cher auditeur
pour que tu ré-émissions
non mais c'est intéressant
et j'avoue qu'il y a un truc
où j'ai été plus en écoute
que participant
les histoires de budget
j'avoue que j'avais jamais trop pensé
parce que justement de par mes expériences
on est assez loin de ce genre de considération
et du coup je comprend
je comprend les problématiques
que ça génère que vous avez évoqué
et je pense que j'irai chercher
le...
comment dire... le talk
de quand à l'avant
sur le sujet parce que c'est...
du coup ça a utilisé ma curiosité
et j'espère qu'il en sera de même pour les auditeurs
et ben merci de toute façon
je le mettrai en description
et ben renais tu as le mot
de la fin de la fin
le mot de la fin de la fin
et ben...
quoi que je pourrais dire
ben n'hésitez pas je pense peut-être
à partager vos expériences
sur les différents moyens
de communication mis à disposition
parce que ben je pense que
c'est aussi
intéressant pour nous de savoir
un peu ce que vous en pensez
et quel est votre ressenti par rapport
à ce qu'on a pu discuter
et si... voilà
ce que vous pensez des grosses entreprises
si vous les connaissez
des plus petites
et voilà j'espère que...
cet épisode vous a plu
et je vous remercie pour un prochain épisode
de DevOps
à bientôt