Bonjour à tous et bienvenue dans le dixième numéro de Dev Ops.
Bonjour à tous et bienvenue dans le dixième numéro de Dev Ops. Alors aujourd'hui nous
avons un petit nouveau avec nous, je vais laisser présenter Nicolas.
Bonjour Nicolas, je t'ai aimé, je suis consultant en SRD DevOps chez Serenité, une boîte que
j'ai créée depuis deux ans maintenant et ça doit faire 15 ans que je travaille un
truc comme ça. D'accord, de toute façon on va vous apprendre
à le connaître un peu plus durant le podcast. Et avec nous, nous avons deux anciens pour
le coup. Donc, on a mon Romain. Bonjour.
Moi Romain Soufflet, toujours indépendant, toujours au ministère. Bon, je vois peut-être
qu'ils ont reparlé de la mission plus tard, peut-être ou pas. On verra.
Super, et Bartelémy. Et donc Bartelémy, on est fait un vieux routard
du DevOps. Bon voilà, toujours fidèle au poste.
Super, bon voilà. De toute façon, vous allez prendre aussi un ou connaître si jamais vous
n'aviez pas vu avant. C'est la rentrée, même si on a fait déjà un numéro avant.
Donc, pas mal de petites nouveautés pour parler un peu tout autour de DevOps. Vous l'avez
peut-être vu, il y avait déjà les meet-ups qu'on a fait. Vous pouvez bien sûr participer
sur meetup.com et décider de rejoindre si jamais vous voulez parler.
Je mets toujours le nombre de places dans le meet-up qui correspond au nombre de micro
qu'on a avec lesquels vous pouvez participer. Ça, je pense que bon, si on est beaucoup plus,
on verra pour retrouver une solution. Donc, ça, c'est une première chose.
Donc, n'hésitez pas à regarder sur meetup.com pour pouvoir participer vraiment. C'est
tout à fait ouvert. On rappelle quand même qu'on est à Paris.
Voilà. On est à Paris et c'est vrai que pour l'instant, on ne fait pas de podcast à
distance là. Et c'est la deuxième news qui est à l'un de dans. On est à l'heure actuelle en
direct live sur YouTube. Vous n'avez pas le lien et nous sommes en... Nous sommes en différé.
Donc, voilà, le lien pour l'instant est privé. Mais plus tard, on va peut-être essayer de faire
en sorte d'être en live sur YouTube que vous puissiez commenter, nous voir en direct. Et voilà,
on pourrait peut-être prendre vos questions que vous avez en live sur ce qu'on dit et on
essaiera d'y répondre. Donc, je trouve ça assez intéressant. Voilà. Pour l'instant,
on est en expérimentation. N'hésitez pas à nous dire ce que vous en pensez pour le coup. Et on
verra. Donc, là, on a une jolie caméra 360 devant nous qui nous filme en permanence.
Donc, on va... En fait, beaucoup plus succé à l'écran que de regarder la caméra.
Oui. Oui. Ça prend un peu de temps à arriver. Il ne faut pas regarder.
Donc, vous le verrez. Voilà. On est en pleine expérimentation. Vous nous direz ce que vous
en pensez. On essaye et puis on voit ce qui se passe.
Donc, voilà un peu. Et enfin, un dernier point encore en termes de communauté pour justement
pouvoir peut-être nous discuter avec nous, enfin, discuter avec nous, nous faire part de vos remarques
ou même part de ce sujet que vous aimeriez aborder. On a ouvert un spectrum dont le lien est sur
meetup.com et de toute façon, je le donnerai un peu partout dans la description là du podcast.
C'est un spectrum pour la communauté PCT. L'intérieur, vous avez un sous-forum DevOps.
Et n'hésitez pas à contribuer pour dire ce que vous avez aimé, pas aimé, pour contribuer aussi
au sujet qu'on vient d'aborder. Il y a un topic ouvert pour quelqu'un des sujets dont on va
discuter. Donc, voilà. Si vous avez quoi que ce soit, n'hésitez pas à commenter un peu plus.
Et d'ailleurs, c'était comme ça que Nicolas nous a rejoint puisqu'il a aussi commenté le dernier
DevOps qu'on a fait sur l'observabilité. Et donc, voilà, plein de choses nouvelles. Donc,
n'hésitez pas à venir donner votre point de vue des choses différentes, des liens qui pourraient
agrémenter un peu pour les autres auditeurs le podcast. Voilà. Donc, c'est sur spectrum et vous
aurez le lien très vite dessus. Et place au sujet. Exactement, place au sujet. Et surtout, place d'abord
comme on a un nouvel inv... Ah oui, on va peut-être quand même dire de quoi on va parler un petit
signe. Donc, on va parler de formation, formation des équipes, formation comment atteindre de la
compétence en fait. On va parler des tests dans l'infrastructure AsCode. Ça, c'est Nicolas qui
nous apporte le sujet là en tout cas qui est intéressé par tout ça. Et j'espère qu'il est
intéressé par le reste. Et on a enfin l'innovation dans l'entreprise parce que dans le DevOps,
voilà, il y a forcément un lien à un moment ou un autre avec de l'innovation où en tout cas des
choses nouvelles. Mais je vois Romain qui prend sa titillette et voilà, et on aura un super débat
là-dessus. Donc, restez jusqu'à la fin. Et enfin, et enfin, et au début en tout cas, pour commencer,
on va demander à Nicolas une petite question qui est un peu traditionnelle quand on a un nouvel
invité qui est qu'est-ce que pour toi le DevOps ? Alors, le DevOps pour moi, donc on va retrouver
écheement des pratiques autour de tout ce qui est automatisation au sens large. Je ne vais pas rentrer
dans l'automatisation vers sur mécanisation. Mais c'est plutôt surtout un état d'esprit pour moi.
Et l'idée, enfin, l'idée, je trouve qu'elle est assez bien de la retransmise dans le bouquin The Phoenix
Project. Ça va être de vraiment d'aligner la boîte sur des enjeux métiers et de retrouver
vraiment la continuité que là, finalement, tous les services IT, soit au service du business et
face à progresser l'entreprise. Super, voilà. C'est très bien. Et bah voilà, on a une définition.
Et pour commencer, on peut voir pour une petite partie une news. Si jamais on en a un peu,
je vais commencer. Il y a une news, je ne sais pas, des news récentes comme ça, tout le monde sera
dedans. Moi, c'est la news d'aujourd'hui de Microsoft qui a décidé de libérer 60 000 brevets
et les données à la VINX. Oui, la OIL, je ne sais pas ce que c'est.
Ouais, c'est Open Initiative, je ne sais plus quoi. En tout cas, ils les ont donné.
En tout cas, ils ont libéré dans un organisme qui permet de mettre en commun des brevets pour
faire en sorte que les gens ne s'attaquent pas de noms. Et je trouvais être un pas de plus.
Encore, on en a déjà parlé dans d'autres DevOps sur l'ouverture de Microsoft sur l'Open
Source. Et on voit vraiment un mouvement. Enfin, quand on se rappelle le Steve Balmer qui disait
Linux, c'est un cancer pour l'informatique. Steve Balmer, c'est un bon souvenir quelque part.
Oui, mais en tout cas, c'est un souvenir. Et on voit vraiment une ouverture. Donc,
on le répète encore. Si jamais vous avez encore un état d'esprit sur Microsoft,
il y en a un truc qui était MS avec le dollar à la fin, comme on l'a tous fait,
je pense, dans un forum ou un autre, un IRC ou un Slack, ça tend à chaque fois.
Ouais, ça a beaucoup changé. Ils soignent énormément leur image. J'ai rencontré des gens
de chez Microsoft dans des Meetups qui faisaient des talks très intéressants sur des sujets
techniques. Ils libèrent les codes sourds s'ils vont sur GitHub. Je pense que la culture de l'entreprise
a pas mal changé en 20 ans. Il faut juste qu'on commence à se rendre compte qu'on arrête un
petit peu de bâcher. Ils ont toujours certains défauts, mais malgré tout, ils font quand même pas
mal d'efforts. Et je trouve ça intéressant à souligner quand même.
C'est même moins qu'en 20 ans, c'est sous leur nouveau PDG, alors qu'un nom imprenonsable,
l'ancien directeur, Bush Cloud, des Microsoft.
Qui a rencontré une evolution en je passe 5-10 ans, même moins, j'ai l'impression parfois.
C'est vrai que maintenant, c'est quand même intéressant de pouvoir suivre certains de
leurs projets qui vraiment pour le coup m'intéressent. Le dernier que j'ai en tête,
c'était sur la 3D dans le browser avec OpenGL. Vraiment, ils font un travail qui est formidable,
et sur vraiment tout un tas de sujets que je n'aurais pas forcément soupçonné venant de chez
eux. Mais bon, pourquoi pas, en final, autant accepter qu'ils fassent des choses bien,
parce que après tout, pourquoi pas ?
Parce que c'est vrai, tout simplement.
Ben oui, tout simplement.
Je trouve qu'il est fiemment revendiqué un peu, peut-être pas être la top, la première
boîte qui contribue à l'open source, mais en tout cas d'être dans les plus impactantes.
Alors après, peut-être avoir la limite à l'histoire de brevet, c'est éthiopement,
c'est pas tout ça fait donner, je pensais plus des garanties, l'usage,
en tout cas ils n'viendront pas attaquer les comptes.
Il y a eu un moment, il y a eu quelques tweets que j'ai vu ce matin, c'était « on allait
donner tous nos brevets, c'est déjà pas tous les brevets, c'est seulement 60 000 sur les
chipouins de centaines de milliers qu'ils ont ». Et après, c'est plus, c'est un droit
d'usage qui est donné, c'est pas complètement du brevet open source, c'est des précisions
d'usage, mais c'est effif, c'est déjà un grand passe.
C'est plutôt un consortium où tout le monde, mais c'est brevet dedans, et ça applique
de pas s'attaquer mutuellement parce que si jamais quelqu'un attaque, tout le monde se
retourne contre lui. En gros, c'est un zéro-sum game au sein d'un consortium, après ce que
j'ai cru comprendre l'un de l'autre.
Ce qui est plutôt pas mal, mais ça veut dire aussi, sans doute, on disait ça il y a pas
longtemps, je me souviens plus à quel moment ou quel article j'avais lu, donc il est soumis
à caution extrêmement forte là-dessus, mais qui était qu'à l'heure actuelle, Google,
Microsoft et Apple dépensaient plus en frais d'avocats dans les patent trolls et dans
même les attaques entre eux qu'en R&D. Donc, on arrivait à un truc complètement ignoble
où tout le monde arrivait, même si des fois ils gagnaient, les frais d'avocats qu'ils
avaient eu pour gagner et des fois ils perdaient, etc. Ce qui fait qu'infinés, tout le monde
dépensait énormément de fric juste dans les frais d'avocats sur les patent, enfin
c'était fin sur les brevets.
Donc, c'est pas si désintéressant que ça, c'est pour calmer le jeu entre les puissants
de l'IT.
Je pense que c'est ça qui est bien. En gros tout le monde met en commun son jeu de la
terreur ensemble en se disant qu'on a tous eu des armes nucléaires, mais si jamais
on les a toutes ensemble, personne n'y touche. En se disant quelque chose comme ça. Ça
pourrait ressembler à ça.
Moi, Man News d'aujourd'hui, est juste une révélateur de tout le reste. Je sais
pas, je pense qu'il y aura pas un impact sur notre vie comme ça là tout de suite. Je
pense pas qu'il y a un brevet dedans où d'un coup on a, ça hier on peut utiliser le clic
droit de la souris. Je crois qu'il y a un brevet là-dessus. Le clic droit de la souris
et un truc.
Il y a une trolle et une époque.
Oui, voilà. Je pense pas que ça révolutionnera notre vie en tout cas là à l'heure actuelle
dans les prochains mois et m'a venez à venir.
Autre news.
Autre news.
Non.
Moi, j'ai un truc éventuellement rapide.
Moi, j'ai deux news. Un truc sympathique qui va peut-être nous impacter plus au quotidien
que les brevets de Microsoft. Il n'y a pas forcément grand chose à voir avec le DevOps,
mais avec l'informatique. Oui, c'est quand même AMD qui revient en puissance sur le
hardware consumer. Ça, je trouve ça cool. Alors, c'est moins cool parce qu'une telle
des difficultés et blablabla. Mais de voir que la concurrence marche toujours et qu'il
y a un gars qui a été largué depuis plusieurs années, voire dizaines d'années qui revient
dans la game et qui pèse, ça fait plaisir. Et voilà, voir du nouveau matériel, du nouveau
hardware, des nouvelles choses qui arrivent, c'est toujours sympathique pour les Geeks que
nous sommes.
Et moi, là-dessus, la question que je me pose, c'est qu'en fait, la toute l'architecture
Zen qui a été apparue, elle a été faite par des gars qui sont tous partis de AMD.
Et ils sont partis chez Intel ou chez Nvidia ?
Enfin chez Intel, Apple pour créer leurs nouvelles plus, etc. chez Nvidia même.
Le gars qui est l'art de le lead architecte Zen, en effet, maintenant il est chez Intel.
Et on verra ce qui va sortir.
Oui, c'est-à-dire que demain AMD, c'est jamais… parce qu'on sait que les cycles
de développement de ce genre d'architecture-là, ils sont sur 4-5 ans.
Oui, au moins.
Donc dans 4-5 ans AMD, tu te cuises la question.
On verra.
C'est peut-être ça que je me dis. Mais non, par contre, il y a un point là-dessus
que tu relèves qui est que là, à l'heure actuelle, on a des technologies, on le voit
dans les architectures Zen et les architectures serveurs qui sont les épiques, qui sont des
bruts et m'équivont un comportement très différent de tous les autres.
Oui, justement, AMD, elles ont sorti une espèce de… je ne sais pas, c'est un tooling
ou un framework pour mieux utiliser les features de leur CPU épique.
Sur Microsoft.
Sur Windows.
Sur Windows.
Voilà.
Mais justement, c'est ça le point qui vient derrière.
C'est qu'en fait, on a des architectures maintenant qui sont différentes et donc peut-être
de traiter… enfin, est-ce que demain, on avait déjà eu ce point-là à un moment,
c'est est-ce que demain, on doit traiter le hardware comme faisant partie de notre software.
C'est-à-dire que là, pour l'instant, en fait, tout le monde est dépendant du GCC.
C'est-à-dire quand on télécharge un paquet de BIAN, CentOS, etc., il a été précompilé
pour une architecture X.
On nous dit AMD64, ça veut rien dire, puisqu'en fait, c'est quels sont les architectures,
est-ce qu'on utilise de l'SSE, quelle version de l'SSE, etc.
Et là, quand on est dans des architectures type, pas pulsent deux ZR, mais Zen maintenant,
on voit que c'est un impact vraiment fort.
Et donc, moi, j'ai toujours un petit problème maintenant à ce qu'on ne parle pas d'un
logiciel basé sur hardware et sa manière de fonctionner.
Enfin, je trouve qu'on a encore un degré de retard sur l'optimisation des logiciels
qu'on fait par rapport à la plateforme qu'on utilise.
Donc, on s'est mis dans l'esprit parce que c'était le cas pendant 15-20 ans qu'on
avait une architecture unique et une manière de construire et de compiler ses logiciels
uniques.
Mais en fait, ce sera peut-être de moins en moins le cas.
C'est un peu ça que je me dis.
Donc, ça va peut-être nécessiter un nouveau concept même de logiciel.
On voit aussi qu'il y a l'architecture MIPS qui arrive pas mal et parce que c'est open
source, etc.
Il y a la montée en force des azis aussi qui arrivent sur les calculs d'A.I.
Et les calculs de plein de choses.
Oui, c'est ça.
Il y a tout ce qui est le calcul des I.I.
Donc, ça veut dire avoir du matériel adapté à autres trucs.
Je trouve que là, à l'heure actuelle, on a justement une montée plus encore de l'architecture
customisée, l'architecture hardware.
Il y a une spécialisation du hardware, que ce soit pour du shredding, que ce soit pour
du GPU computing, que ce soit pour de l'asique, pour des applications hyper spécialisées.
Ça a toujours existé.
Mais on en parle et il y a un petit mouvement qui est en train de se faire.
Alors, est-ce que ça va se transformer et ça va se généraliser ou ça va rester
une niche ?
Je ne sais pas.
Mais bon, ça mérite d'exister.
Il y a d'une question.
C'est que ça peut très bien rester une niche parce que nous, en tant que DevOps, on n'arrive
pas à déployer sur ces architectures-là et on n'arrive pas avant un cycle.
Donc, ça restera une niche parce que juste, on ne sait pas, alors que ça serait très
performant.
Ou est-ce que ça va se développer ? Dans ces cas-là, qu'est-ce qu'on fait ? Est-ce
qu'on va continuer d'utiliser nos paquets AMD64 complètement compatibles avec toute
la Terre alors que…
On a des solutions.
On peut gérer différentes architectures.
Ça a toujours été prévu.
Mais ce n'est pas quelque chose encore une fois qui est généralisé.
Là, on a un avis.
Ça se trouve qu'on aura demain des nouvelles questions à se poser sur quels sont les conteneurs.
Ça veut dire peut-être faire… On a déjà la grosses compilations des conteneurs pour
ARM64, ARM32, pour le Raspberry Pi qui va bien, pour AMD64, pour Windows, etc.
Et là, il va y avoir plein de questions là-dessus sur les tests multiplatformes comme ça et
multi-architectures, comment on teste ça, comment ça se surpère que ça marche.
Sachant que maintenant, le conteneur va commencer à être dépendant, en tout cas, notre logiciel
de la plateforme sur le calitre.
Donc on aura plein de questions à se poser.
Je ne connais pas encore l'impact qu'il va y avoir sur les entreprises et l'aspect
business, mais moi en tout cas, ça me fait très plaisir de me plonger dans ces problématiques
là-bas.
Je pense que pour le challenge, j'adore ça.
Je pense qu'on aura des discussions là-dessus, en tout cas, dans les mois slash années à
venir.
Mais voilà, super news.
Je sais pas si quelqu'un en a une autre.
C'est bon ? Allez, vas-y.
On va commencer par le premier sujet sur la formation.
Alors ça, c'est un sujet qui me tient un peu un écœurant ce moment puisque justement,
c'est quelque chose que je commence à faire.
Donc des formations autour du DevOps, des outils qui vont autour, Kubernetes, Docker,
Git, même des fois, Jenkins.
Et c'est des formations à leur écœurant qui sont, on va dire traditionnelles.
C'est des formations de type, une journée, deux journées, soit au sein de l'entreprise,
soit dans un institut de formation.
Les gens viennent, viennent se former.
On fait des ateliers qui vont avec.
Et à la fin, ces ateliers sont très théoriques, même s'ils sont des fois pratiques, mais
ils sont dans un univers quand même très très cadré et très très édulcoré par rapport
aux contraintes qu'on va avoir directement en entreprise.
Et à la fin, on espère avoir une connaissance.
Je suis sûr que les gens sortent de là avec plus de connaissances qu'ils ne sont entrés.
La question que je me pose, c'est, c'est très bien, les gens sortent avec plus de connaissances,
mais est-ce qu'on peut pas trouver une meilleure façon d'apprendre ?
Quelle est la bonne façon d'apprendre et de transmettre du savoir dans une entreprise ?
Et c'est une question assez ouverte.
J'ai placé un peu le contexte, j'ai mes propres avis, bien sûr, mais j'aimerais
avoir le vôtre sur ce contexte du savoir et de la transmission du savoir en entreprise.
Dans le contexte DevOps ou dans le contexte global ?
Je pense que c'est bien de se mettre ce cadre-là.
C'est vrai que les formations que je fais sont les cadres DevOps.
Les formations, les outils qu'on utilise sont des fois des outils techniques,
mais une finée, en fait, il y a plein de bacs grands dans le savoir.
Donc en fait, on est plus dans une culture parce que chaque outil ne vient pas indépendamment.
Il vient dans une sphère d'influence.
On ne fait pas du Jenkins si on ne veut pas faire CIA,
il n'est pas juste un outil qu'on va utiliser pour avoir tout.
On ne va pas faire du guide si on ne veut pas faire des branches, etc.
Ça n'est rien d'utiliser guide pour avoir juste un master.
Et c'est tout.
Donc en fait, ça vient plutôt dans une philosophie.
Et souvent, quand on fait une formation sur un outil,
on fait aussi la formation de ce qui va autour.
Et donc en fait, il y a toujours cette transmission du savoir,
de la connaissance ou d'un état au sens très général.
Donc c'est pour ça que ça a très énormément au DevOps,
mais c'est vrai que ce n'est pas limité au DevOps.
Je pense là dans la formation et dans l'idée que je vais en faire
la transmission du savoir en entreprise, qu'on va appeler formation pour avoir un terme...
Dans le sens large.
Dans le sens très large.
Ce n'est pas le moment où on est en formation.
J'avoue que nous, on a des problématiques liées à la formation.
Quand on essaie de former des profils aux logiciels qu'on est en train de créer
là au ministère, par exemple, on parle souvent de pré-requis.
Et souvent, les pré-requis, par exemple, si on dit
en pré-requis pour utiliser notre forge, il faut connaître un minimum en cible.
Les gens arrivent en disant qu'on connaît en cible.
Et finalement, ils y connaissent très peu.
Ils y connaissent à peine, par exemple, le fonctionnement d'une clé SSH.
Et ça, ça limite réellement l'apprentissage derrière parce que nous,
on s'appuie fortement sur les mécanismes qui permettent à un cible de fonctionner.
Et du coup, on sort un peu à un mur.
Et on a vraiment des gros problèmes avec ça.
C'est les formations pour qui elles sont et par où on passe et jusqu'où on creuse le sujet.
Et ça, c'est des questions qu'on se pose énormément en ce moment.
Ça, là, je vais rebondir là-dessus.
Est-ce que c'est dû à un silottage ?
Parce que là, ce que tu es en train de dire, c'est que vous, vous avez développé une solution
avec des pré-requis que vous connaissiez, qui reposaient sur des bases,
qui n'étaient pas en fait partagés uniformément au sein de l'entreprise.
Oui, c'est ça.
Concrètement, la première fois que la formation a été donnée,
on s'attendait à ce que tout le monde connaisse Geat.
Parce que pour nous, c'était logique.
C'était ce qui était naturel pour nous.
On a des profils qui n'ont jamais utilisé un seul logiciel de gestion de version.
Mais jamais aucun, pas subversion, pas CVS, rien du tout.
Concrètement, on a passé une demi-heure à réexpliquer Geat.
Une demi-heure, ce n'était pas suffisant pour ces profils-là.
Et les autres profils, ils n'ont rien de mieux à faire, puisqu'ils connaissaient déjà.
Donc on avait vraiment une sorte de...
En fait, la formation a perdu son rythme concrètement.
Donc on a perdu pas mal de profils au niveau de leur attention.
On a perdu les profils moins capés techniquement,
parce que c'était trop technique.
Au final, ce sujet formation est vraiment un sujet très problématique.
Si on s'organise en session et qu'on essaye de former plusieurs personnes,
on a ce problème d'homogénité dans la classe.
Après, je sais que des formations individuelles sur des sujets très précis comme SSH,
comme Geat, ça marche très bien.
Mais à un niveau individuel, ça ne va pas très vite pour former une entreprise, par exemple.
Est-ce que ce n'est pas juste un problème de calibration ?
Parce que là, tu dis, il y avait différents types de profils, est-ce que ce n'est pas juste ?
Avant même la formation, le fait de vouloir faire participer
et de ne pas avoir serné les différentes personnes, les différentes aptitudes
et les différentes attentes qui aiment cette espèce de conflit au moment de la formation.
Oui, je pense que dans le cas où il y a eu un peu de ça,
le problème c'est que le contexte ne permettait pas de faire mieux.
On a un projet, ce n'est pas tellement qu'on l'impose,
mais il est très vivement encouragé au niveau du ministère.
Beaucoup de projets rejoignent le cloud du ministère au travers de notre forge.
Et donc par cet intermédiaire-là, ils sont obligés de se former aux outils qu'on utilise,
malgré le fait qu'ils viennent de plein de raisons différentes.
On n'a pas ce luxe de pouvoir mieux filtrer ou mieux calibrer le public qu'on a.
C'est plutôt à nous de nous adapter.
Et là, c'est la grande question, comment on fait pour s'adapter à des profils multiples ?
Là, la question, en fait, la Babar, c'était la division des profils au sein de la formation.
Moi là, c'est la question qui peut me venir.
Je ne pense pas qu'elle soit vraie, mais est-ce que votre outil n'était pas adapté par rapport au profil que vous aviez ?
Ou est-ce qu'il aurait fallu avoir plusieurs outils pour plusieurs profils différents ?
La question, c'est est-ce que le problème vient de la formation
ou est-ce qu'il vient du fait que l'outil n'était pas adapté ?
Et en fait, la formation n'est qu'un révélateur de l'inadaptation du logiciel au contexte voulu à la base.
C'est une question, je ne connais pas du tout ton contexte-là,
que je pose la question de manière très candide là-dessus.
C'est très difficile de répondre là-dessus parce qu'on a un produit qui est du coup complexe par nature
puisque on vise en fait, via cette solution, à encourager tous les bonnes pratiques du monde DevOps.
Donc, on est sur des architectures immutables, on est sur de l'infrascode,
on est sur des logiques de mise en production pour mettre en production plusieurs fois par jour,
même si concrètement, c'est impossible, on est dans un contexte ministériel,
donc on a quand même des contraintes.
Mais malgré tout, on met en place tous ces outils-là, ils ont une certaine complexité.
Je pense qu'on a fait au plus simple en tenant compte de nos contraintes.
Maintenant, comment faire les formations pour aider les différents profils à s'en servir ?
On a un petit peu bloqué.
Je ne vois pas comment faire plus simple de notre côté.
Et les profils qu'on a, c'est les profils qu'on a, c'est notre situation de base.
Donc maintenant, on a vraiment une carte à jouer.
Comment on fait ? C'est une vraie question.
Je n'ai pas de réponse actuellement.
Avant, si jamais on voulait avoir cette division des profils,
on avait le système des certifications.
Je sais que c'est quelque chose, toi, Romain, que tu as dit.
Avant, c'était comme ça qu'on faisait.
La formation était adaptée pour avoir le pré-requis.
C'était certification niveau 1.
On avait coché la case.
On passait à la certification niveau 2.
Et comme ça, on savait quand on faisait une formation,
on parle à des gens certifiés niveau temps sur tel technologiste.
Ça existe encore.
Et toi, Nicolas, je sais que tu avais...
Après, moi, j'ai eu joli.
Enfin, c'est pour ça qu'on a même la réponse.
Mais le client chez qui je suis actuellement,
c'est plus édite de distiller les savoirs en fait au fur et à mesure.
On a un nombre de créneaux qui sont un peu de meet-up interne,
soit plutôt aux réinactualités, quand on veut améliorer des pratiques,
où là, chacun peut venir sur un sujet donné,
et puis on essaie de faire avancer le sujet.
Là, typiquement, ils ont déployé Vault pour le...
C'est en gestion des secrets.
Donc, le but, c'est effectivement que la personne,
enfin, qui a pu mener le projet,
finalement aujourd'hui, elle fait une présentation pendant une heure en disant,
voilà, tout ce qui a été fait, voilà vos impacts sur les...
sur tout ce qui est mis en production
et surtout les process qui les concernent directement.
Et finalement, il y a des présentations,
il y a des infos en plus,
mais maintenant, le focus, il est sûr,
mais voilà ce que vous avez besoin de savoir.
Et le reste, t'en pise une attraction,
et ils ont pas besoin de savoir ce qui se passe en dessous.
Moi, je sais que le pareil,
j'ai refait toutes les plateformes de recette à base d'oeufs,
container de docker.
Ouais, docker a été mentionné,
mais ils envoient qu'un tout petit bout,
parce qu'eux, ce qu'ils voient, c'est juste des jobs d'un t-kins,
qui fait le boulot,
et donc, finalement, ce qu'ils voient, c'est les quelques pré-requis.
Et finalement, l'information,
elle se fait plus par diffusion un peu permanente,
ou pour réussir des savoirs,
que par des grosses sessions OneShot.
Et après, effectivement, il y a des choses
qui sont plus individualisées,
ce qui est que les gens va aller plus loin,
mais c'est peut-être aussi des choses plus...
C'est vrai qu'aujourd'hui, dans les grosses organisations,
c'est plus, bien, effectivement,
on met tout dans une salle,
et puis on essaie de mettre tout le monde au même niveau.
Là, c'est plus une approche un peu incrementale,
et c'est peut-être ça qu'il faut arriver à faire
par des petites sessions.
Après, effectivement,
et c'est vrai que mon niveau de la boîte aussi,
des BBL une fois, temps, temps,
c'est des choses comme ça,
donc c'est plus incrementale, c'est pas de ma glunge.
Là, pour le coup,
il y a une réelle inadaptation avec ce coffre le marché,
et ce qui est attendu par les entreprises,
parce que notamment quand on demande...
On en a fait l'expérience,
nous, je vais revenir sur le point,
mais on a fait une demande
de pas forcément avoir une formation,
comment dire, académique,
mais d'avoir le formateur qui était parmi nous
pendant une journée ou deux
avec lequel il allait voir ce qu'on allait faire,
on allait lui poser des questions,
il allait utiliser ses ressources documentaires
pour nous illustrer,
pour nous montrer, par exemple,
pour un produit sur lequel il est mandaté,
que je ne citerai pas,
qui, voilà, il...
Voilà, des choses, des...
Je vais pas citer.
Voilà, et on a une demande très précise
d'accompagnement un peu de type formatrice,
où il allait pouvoir nous illustrer,
nous montrer des documents,
nous montrer ses ressources,
nous montrer comment ça marchait,
nous montrer des exemples qu'il avait pu déployer
à gauche à droite,
ou qu'il avait donné à d'autres clients,
et c'est quelque chose qui était impossible,
parce qu'ils ont leur diapo,
ils ont leur rythme,
ils ont leur formation,
et quand on demande quelque chose qui sort un peu du cadre,
qui sort voire même complètement du cadre,
et qui est plus dans l'accompagnement
et la passation de connaissance,
on va dire, incrémentale, comme tu disais,
ben, il n'y a plus personne devant.
C'est ça, ça sort du lot, quoi.
Le problème, c'est que ça,
ça s'appelle pas de la formation,
ça s'appelle du conseil.
C'est pas du conseil, non ?
Et que le conseil, là-dessus,
moi, je suis indépendant,
et donc j'ai sorti un article justement là-dessus,
je l'expliquais clairement,
il y a plusieurs niveaux,
il y a la formation pleinière,
et toi, là, ce que tu demandes,
c'est du conseil.
C'est du conseil, mais alors...
Et le même, c'est que ce n'est pas le même budget,
c'est que le budget formation,
ce n'est pas le même budget que le budget conseil,
et personne ne peut payer,
personne ne peut plus se laisser conseiller.

c'est mon deuxième point,
c'est que la formation,
entre guillemets pleinière académique,
ça marche bien pour des débutants,
voir des personnes avec des connaissances intermédiaires,
mais nous, qui avons...
voilà, ça fait 8-10 ans qu'on bêne dans le métier,
ou peut-être plus, pour certains,
qui rigolent,
mais voilà, ça fait 8-10 ans.
Même quand on va dans des conférences,
des fois, on s'emmerde.
Enfin, on n'apprend rien.
On y va pour boire, tout de suite.
On y va pour boire,
on y va pour rencontrer des gens,
on y va pour discuter,
on y va pour...
On apprend des choses.
Mais c'est vrai que le retour principal,
lorsqu'on fait des vrais,
enfin, des vrais, entre guillemets,
formation, des formations,
soit certifiantes,
même si on...
ça fait longtemps que j'en ai pu faire.
J'essaie même plus, soit des formations,
on va dire, commerciales,
je vais l'appeler ça comme ça.
Bah, c'est que...
Enfin, voilà, au bout d'une demi-journée,
on s'emmerde, et on regarde le slack,
et on n'apprend plus rien,
on est décroché,
enfin, il y a une inadaptation,
avec des profils, entre guillemets, avancés,
en tout cas, qui ont déjà
un certain niveau de connaissance,
et avec ce genre de...
comment dire, de montage,
de formation.
Je dois avouer que c'est...
En fait, c'est ça,
c'est la plupart des formations
qui fonctionnent bien,
en tout cas, dans mon expérience,
où j'ai pu prendre avec moi
10 personnes,
et je leur ai dit, bon, bah,
on va revoir les bases de guite,
ça, ça marche très bien.
Mais c'est pour une formation,
on va dire un peu débutante,
et ils ne connaissent pas bien guite,
et je vais leur apprendre les bases,
bon, comment on fait un merge,
comment on fait un rebase,
c'est quoi les différences,
pourquoi et ainsi de suite.
Mais c'est effectivement
un peu une introduction à guite
pour aller plus loin
sur des concepts avancés.
Le format, formation,
un peu court magistral,
bah, il marche moins bien.
Voir, il marche pas, en fait.
J'ai jamais vu une formation
type expert avancé,
où juste, ça se passe bien,
et je suis vraiment content
d'y aller, en fait.
Je veux dire,
je n'ai pas ce genre de formation
à ma disposition.
En effet, guillemt soulevé
le problème économique,
parce qu'il y a des budgets
formation, il y a des crédits
formation, et pour avoir,
pour débloquer ces crédits,
et pouvoir les utiliser,
il faut avoir des formations
un petit peu, je ne sais pas,
qui font partie d'un catalogue,
qui sont enregistrés,
ou je suis en train de réfléchir,
enregistrés, catalogue,
ou qui sont certifiantes.
C'est-à-dire, à la fin,
on a un bout de papier
qui nous dit, voilà,
qu'on peut présenter
à sa comptabilité,
en disant, il y a eu une formation.
Et c'est vrai que des formations,
je vais dire, exotiques,
mais qui pourraient peut-être
s'apparenter, en effet,
à du conseil,
ou en tout cas, quelque chose
de plus, comment dire,
de plus interactif,
et bah, ça ne rentre pas
forcément dans ce cadre-là,
et c'est très difficile à faire passer.
Ça ne rentre pas parce que la définition du don,
enfin, la définition du réaliser,
n'est pas possible, en fait,
n'existe pas, et c'est la définition même du conseil.
La définition du conseil,
c'est que tu prends quelqu'un
pour ses capacités,
de manière, genre, quasiment,
dans la croyance de IVAT-ED,
sans savoir à l'avance.
C'est...
C'est...
Et c'est vraiment ça, la chose,
mais en même temps,
moi là, je suis devenu indépendant
pour justement pouvoir ramener ça,
c'est que je vais voir des entreprises
qui n'ont pas ces capacités-là,
et c'est...
Enfin, ces capacités-là, non,
pas plutôt les compétences,
pas les tous les capacités,
c'est les compétences,
l'envie,
l'expérience.
Le temps.
Et le temps, effectivement, voilà.
Les indépendances sont justement
là pour faire ce genre de choses-là.
C'est...
Enfin, après voilà,
tu es un peu, genre,
le seul CDI autour de nous,
tant d'un...
Ouais, j'en crois,
mais la minorité,
c'est la...
Voilà, tu es la minorité,
mais on est tous passés par là,
donc, à mon avis.
Donc, on sait,
on sait très bien
ce qu'il en est à ce niveau-là.
Mais justement,
c'est...
C'est vraiment un point important,
là-dessus,
c'est qu'il faut repenser
la chose d'un an.
Le problème aussi,
qui va se passer quand il y a quelqu'un
qui vient dans ton infrastructure
quelqu'un d'extérieur,
c'est que cette personne-là,
il va avoir un avis,
elle va avoir une opinion,
et globalement,
des fois, elle va pas être d'accord
avec ce que tu dis.
Donc, le formateur,
tu es d'accord,
tu es pas d'accord,
quand tu rentres chez toi,
tu fais ce que tu veux.
Si jamais derrière,
cette personne-là arrive chez toi
et te dit,
bon, bah là,
tu as fait du popo,
là, tu as fait du caca,
là, il va falloir tout changer.
Là,
il va falloir repeindre
toute la maison en mauve,
vers, etc.
Non, il va dire,
enfin, les bonnes pratiques,
ce qu'on enseigne,
c'est ça.
Mais nous, ce que vous faites,
c'est ça.
Mais nous, ce qu'on enseigne,
c'est ça,
parce que le logiciel
ou le...
voilà,
ça fonctionne comme ça.
Donc, il va nous exposer
son point de vue
qu'il aurait très bien pu
exposer de manière
académique et pleinière,
et voilà.
Et en mode,
je m'adresse à vous,
en tant que maître
et vous élève,
ça pourrait être,
c'est-à-dire qu'il va pas
nous enseigner
les 80% de choses,
donc, on s'en fout,
voire qu'on connaît déjà.
Par contre,
il va se concentrer
et il va peut-être
passer plus de temps
sur les 20% de choses
qui nous sont critiques,
intéressantes
et sur lesquelles
on a un besoin réel.
Il chante à mon accord,
le problème maintenant,
c'est,
est-ce que les équipes
sont prêtes à assumer ça ?
Je sais pas.
Pour moi,
le principal problème,
c'est de montrer,
enfin, ce que j'ai vu
en direct, c'est...
les peu...
enfin,
quand je faisais des formations
autour de la messagerie,
c'était...
bah oui,
mais quand il faut montrer
quelque chose
au formateur
pour lui illustrer
notre problématique,
il faut lui montrer la prod,
quoi.
Et de quel droit
qu'elle est cette personne-là,
qu'elle est son gros,
enfin,
il n'a pas le droit
de voir la prod.
Même moi,
en tant que formateur,
si jamais on fait ça,
je pense qu'on sort
du cadre de la formation
et je dis d'arrêter,
parce que ça
paye en tant que conseiller.
Ce n'est pas du tout
les mêmes...
moi, les mêmes TGM,
même etc.
Ouais, mais...
Non, mais c'est...
C'est un truc, enfin.
Oui,
il faut être clair
sur l'étendue de chacun.

enfin,
surprendre d'en réaliser
une formation,
ce qui est clair,
ça n'a pas être rentable,
de faire du sur-mesure...
enfin,
c'est beaucoup trop d'efforts,
pas pour le rentabiliser.
Donc,
physiquement,
ils vont plutôt viser
des trucs plus simples,
mais qui peuvent dupliquer
à l'infini.
Et après,
le souci
que tu peux avoir aussi,
c'est que dans une
formation,
physiquement,
toi tu viens
avec un outil
et bonne pratique, etc.
Mais là où toi,
t'attends plus de gens,
finalement, c'est sur du
spécifique,
qui est complètement spécifique
à ton compte avec ces salles.
Le problème,
c'est que ton formateur,
on arrive en juste 2 jours
ou 3 jours,
ou peu importe.
Pour l'appréhender,
c'est bien compliqué.
Donc,
il faut arriver à faire
converger les deux mondes.
Vraiment,
tu peux dire,
tu peux avoir le mode,
effectivement,
plutôt que de dire,
bah tiens,
le savoir qu'il y a du mix et ça,
et puis,
j'en fais ce que je veux
quand je reviens.
Tu peux espérer
avoir un mode
où si on a mis au jour tout le
monde dans la même salle,
le formateur va t'amener
les bonnes pratiques,
il va aussi te faire
un converger
pour un truc qui
accepte peut-être
de deux côtés.
Je pense que...
Mais c'est vrai que tu sors
du monde formation pure.
Un bon formateur,
c'est un formateur
qui justement ne suit pas
de plan.
C'est un formateur
qui connaît toutes ces
thématiques,
tous ces chapitres,
si vous voulez,
tous ces diapos
sur le bout des doigts,
et qui est capable de sortir
la diapo 227
au un moment,
et la question d'après,
parce qu'il y a une discussion
qui est en cours,
de sortir la diapo 45,
parce qu'elle correspond
à la thématique...

à la thématique...
C'est dans le cas
de une équipe,
mais moi, par exemple,
si jamais je fais ça,
la dernière formation
que j'ai faite,
il y avait 3 personnes,
c'est pas très gros,
3 personnes,
et 3 personnes avaient
3 profils complètement
différents.
C'est-à-dire qu'en fait,
si jamais je parlais
d'un sujet,
je perdais les deux autres
tiers,
et si jamais j'allais
dans un autre sujet,
je perdais les...
etc.
Donc, en fait,
là, tu es dans un cas
où tu utilises la formation
comme une...
ou une boîte des fois différente
qui se réunissent
pour écouter la bonne parole
de quelqu'un
qui leur dit quelque chose
qui ne savait pas.
D'accord.
Toi, tu es dans le cas
où tu as toujours fait
des formations
d'un formateur
pour une seule équipe.
Tu vois bien que ton truc,
il est dit...
l'attente que toi,
tu vas avoir d'une formation,
elle sera différente
en fonction des personnes
qui sont autour de la table.
Et donc,
dans une formation tradit,
on va dire vraiment,
le pur tradit,
tu as des gens différents
autour de la table.
Peut-être que vous,
vous faites un peu de différences,
à-dire que vous achetez
en masse,
et vous dites, voilà,
j'envoie toute mon équipe
à faire la formation.
Ou c'est des fois,
c'était moi qui étais le formateur
et je formais, en effet,
une équipe de la mairie,
de machin.
Voilà.
Mais ce contexte-là,
il existe,
mais il n'est pas...
Il n'est pas toujours le cas.
Mais là, en fait,
justement,
quand tu formes une équipe,
machin,
ça devient compliqué.
Tes bordes or langues,
vraiment,
entre...
Vraiment,
j'ai été confronté,
tes bordes or langues,
entre le conseil
et la formation.
Ouais.
Mais c'est bordeur.
So what.
So what.
Bah so what,
c'est pas...
C'est pas égato en le même TGM,
c'est pas égato en la même compétence,
c'est pas égato en le même truc comme ça.
Enfin,
c'est un peu ça.
Et puis,
est-ce que c'est vraiment
ce qu'on attendait
de toi dans la formation?
C'est un peu ça la question.
Et donc,
enfin, là,
pour en revenir,
donc là, on arrive dans un cas
ultra précis,
des gens qui sont déjà ultra capés.
Et là,
enfin,
tu donnes bien l'inadaptation
des formations comme ça.
Fais-toi ce que tu veux,
c'est du conseil.
Tu veux quelqu'un qui est plus de compétence
que toi,
qui te vienne pour te former.
En fait,
ce que tu veux,
c'est une...
C'est une formation par les pères.
Tu veux un père un peu plus...
un peu plus capé que toi,
qui vient de te donner du savoir.
C'est censé être le cas.
Enfin,
quand il y a un enseignant,
si on prend les termes génériques,
si il y a un enseignant,
c'est qu'il a le savoir.
Enfin,
s'il transmet le savoir,
c'est qu'il a le savoir.
On s'attend pas à avoir...
Tu vois la différence,
même dans les professeurs,
entre un cours à l'école
et un cours individualisé.
Et en fait,
c'est la même chose.
C'est...
Est-ce que tu es dans une classe de 30 personnes,
ou est-ce que tu as à ton prof
que tu payes très cher
à la fin de la journée
pour qu'ils viennent t'apprendre
à ton mioche
exactement les choses ?
On est exactement
dans cette différence.
C'est peut-être qu'en fait,
le problème,
c'est l'inadaptation
à partir d'un certain niveau,
parce qu'on est bien d'accord.
Moi,
je n'ai pas du tout...
J'ai rien à redire
sur le fait que des formations
spécifiques,
pointues,
sur des domaines techniques
particuliers,
sont très adaptées
pour des profils débutants.
Mais,
le principal problème
que nous,
on rencontre
et qui...
qui existe
pour que je pense
beaucoup de DevOps,
qui sont en général
les gens un petit peu
plus expérimentés,
c'est que...
c'est qu'on s'y retrouve pas.
Comme les conférences,
aujourd'hui,
finalement,
tu ne retrouves pas mal de conférences
qui te servent juste
à t'amener une veille
ou à te confirmer
que t'as bien,
que t'as pas raté de gros trucs,
et que t'es à jour
sur l'état de l'art
en la matière,
alors que,
éventuellement,
tu peux aller
aux mêmes conférences
quelques années plus tôt,
tu ressortais,
t'avais l'impression
d'avoir pris plein de choses,
sauf que,
bah toi,
t'as mieux rien entre-temps.
Et c'est vrai qu'aujourd'hui,
et faire...
pas les conférences,
aujourd'hui,
les gens qui donnent les conférences,
c'est des gens
qu'on t'en a,
finalement,
qu'on n'a pas
près la même expérience.
Donc,
finalement,
t'apporter plus,
ça devient compliqué,
on est vraiment...
t'arrive sur des niches,
sur des profils très particuliers.
Et...
Donc,
effectivement,
aujourd'hui,
même les conférences,
je vois,
c'est plus chiant
pour des gens
qu'on entre-quoi zéro
et 10 ans d'expérience,
peut-être,
ou peut-être moins.
Ou c'est bien,
ça donne des sujets...
Enfin,
voilà,
ça complète,
etc.
T'apprends plein de choses.
Au bout d'un moment,
bah plus tu vas
à mon temps d'expérience,
moins tu vas apprendre
de choses.
Après,
ça a juste confirmé,
chier,
que t'es à jour,
sur ta veille,
ainsi de suite.
En fait,
je me suis dit,
je sais que tu connais pas,
tu vas apprendre des choses,
mais bon...
Est-ce que je te le vois ?
Mais ça,
aujourd'hui,

je le vois,
sur plein de conférences,
on est quelques-uns
à se poser des questions,
sur...
Oui,
j'ai envie de continuer
à des conférences.
Maintenant,
je veux...
je veux avoir quelque chose
en face,
et ça,
ça devient
plus en plus compliqué.
Oui,
même pour les gens
qui organisent des conférences,
trouver des profils,
des thématiques,
des...
Voilà, tout simplement,
des gens qui sont capables
d'amener
ce genre de contenu.
Oui.
C'est galère.
Enfin, je pense qu'il galère
déjà à trouver des gens
capables d'amener du contenu
intéressant.
Ah non...
Oui,
il faut accepter,
je sais pas si tu vas
dévoxer,
ça te confiande juste
ton état de veille général.
Oui, oui.
Et c'est déjà pas mal,
finalement,

Je pense que c'est
le consensus actuel.
Il faut pas avoir une attente
excessive, finalement.
D'aller voir d'autres conférences
dans d'autres secteurs.
D'aller voir...
Moi, si je mets demain,
je vais aux Dott CSS,
aux Dott JIS,
enfin, je comprendrai pas
la moitié de ce qui est dit.
Et j'apprendrai
l'autre moitié.
Non, c'est aussi ça.
Oui, non, voilà,
ça soit fait dans le mode
d'opportunité,
je découvre de nouveaux sujets,
même qui n'ont rien à voir
avec mon sujet habituel.
Et après,
sur des sujets plus pointus,
soit tu vises peut-être
des conférences très
dans les produits,
parce que c'est genre la dockercon,
une cubecon, etc.
Tu vas te dire,
tiens, mais il y aura des tracts
un peu avancés.
Et là, j'espère en avoir
des choses,
ou alors ma tant pis,
et ça reste généraliste,
et sans aucun
un peu géoratique dans l'histoire,
mais ça donne juste
une tendance,
où on était...

Et après,
l'autre question
aussi que j'avais,
c'est vraiment
sur la transmission générale
des bonnes pratiques.
Là,
et c'était un exemple
que tu avais au ministère,
mais qui était,
est-ce que
est-ce qu'une finée,
tout le monde doit rester
un peu dans son carcan,
on va dire,
et d'être très spécialisé
là-dedans,
et que ça se passe
très bien ainsi,
et que les gens,
bon, bon normalement,
arrivent à travailler
ensemble avec des outils différents,
assez hétérogènes,
et puis, voilà.
Ou est-ce qu'il faut
avoir cette transmission,
du savoir,
via les BBL,
et je te demande
quels sont les...
Et là, c'est plus...
Parce que je crois bien
sur la deuxième solution,
qui est plutôt la transmission.
Et dans ces cas-là,
quels sont les outils
à mettre en place,
donc on a parlé des BBL,
donc déjà,
quelqu'un veut...
Romain, je sais
que t'en as fait un,
il n'y a pas très longtemps.
Oui, j'en ai fait un,
mercredi, c'était indépendant. Mais c'était hier en fait mercredi.
Ah ouais c'était hier. J'ai du mal avec les jours, c'est fou.
Il y a un jour et demi puisqu'on est le soir.
Oui, voilà. Puis en plus il y a eu le cinéma et tout. Du coup pour moi c'est deux soirées
en fait. Donc j'ai fait un BBL qui était plus sur la thématique DevOps au sens très
large. C'est un petit peu genre c'est quoi mon métier ?
Est-ce que tu peux rappeler ce que c'est BBL pour ceux qui ne connaissent pas ?
C'est écrit, il décrit ce que tu as dû faire.
Le concept du BBL c'est Buon Back Lunch. On apporte à manger, on mange ensemble et c'est
un peu comme un meet up, un talk sauf qu'on mange en même temps.
Donc ce qui est un peu désagréable pour le speaker c'est qu'on ne mange pas beaucoup.
Désolé. Par contre en fin et à l'avantage de ce format c'est qu'il y a beaucoup plus
de discussions. On est beaucoup plus encouragé. On était moins nombreux, on était vingtaines
on va dire, entre quinze et vingt je ne vais pas compter.
Et très rapidement ça fait orienter pas sur moi qui parle et des gens qui écoutent mais
plus des discussions entre les personnes qui étaient présentes.
Et je pense que c'est vraiment tout l'intérêt du format BBL par rapport à un format meet
up classique où on parle devant différentes personnes.
Et donc là typiquement j'avais un sujet très large donc comment on fait la transition
des Vops, comment on aborde le sujet de la transition vers la culture des Vops.
Et j'étais bien content que ce soit sur le format BBL puisqu'il y a beaucoup trop
d'aspect à cette question à traiter pour que je puisse le traiter de manière séquentielle.
J'en oublie forcément une partie, j'oublie forcément des approches.
Et donc là par la discussion via les questions que les différents participants ont pu me
poser, j'ai pu aborder les aspects qui intéressaient mon audience.
Donc en fait c'est vraiment le taux que j'adapte complètement mon discours à l'audience
qui est autour de moi.
Et ça rejoint un peu ce que tu disais sur la formation qui s'adapte dans l'équipe,
c'est-à-dire que l'équipe a des questions très spécialisées sur l'orcas d'usage.
Et même si moi je ne fais pas partie des entreprises, desquelles font partie des participants
qui m'ont posé des questions, mais j'avais quand même des conseils de manière un peu
générique, des guidelines, des bonnes pratiques un peu génériques qui pouvaient les orienter.
Et j'ai trouvé le format très intéressant d'un point de vue formation.
Donc là bon c'était mon premier BBL, j'étais un petit peu plus dans l'impro, je veux dire
je ne vais pas le cacher, j'étais un petit peu en mode découverte.
Mais c'est vrai que là sur le sujet formation, je pense que c'est un très bon format BBL
pour partager ses connaissances et justement avoir des questions en direct pour pouvoir
adapter son discours, je trouve que c'est vraiment un bon format.
Après en termes de volume, on est quand même sur quelque chose de très très court parce
que si tu passes 21h de Bronman Lunch, ça n'a rien à voir avec deux ou trois jours
de formation en termes de…
Oui non, ça n'a rien à voir.
Mais ça arrive peut-être plus souvent.
Ce qu'on avait fait dans une précédente entreprise avec Bart et d'autres, on avait
justement essayé d'étendre un peu le système du BBL en se disant justement, je pense
que ça rejoint beaucoup ce que tu as fait et ce que tu as dit, mais on l'institutionalisait
en fait, c'est-à-dire qu'on avait décidé de faire ce qu'on appelait donc les FTL,
les Fast Tech Lunch, qui était en fait de se dire ce qu'on veut, c'est que ce soit
le midi et que ce soit rapide et que justement, il y ait cet apprentissage rapide, enfin
et multifactorial.
Et en fait, ce qu'on s'était défini, c'était de se dire 30 minutes au début sur une présentation
sur un sujet qui permet de donner une thématique, mais c'est qu'une thématique tout à fait
où on peut aller à côté.
Voilà, c'était une conférence, c'était une technologie, c'était n'importe quoi comme ça.
Ça reste très très court, donc vraiment 20-30 minutes sachant qu'on compte le temps
de s'installer, le temps de faire brancher le vidéo proche, etc.
Donc très vite, ça réduit énormément.
Et le but après, c'est d'aller tout de suite sur une session d'Open Space.
Donc les Open Space, c'est une division dans le temps et dans l'espace des réunions et les
gens viennent proposer les sujets, votent pour ce lequel ils veulent parler et les traite.
Et dans des Open Space, très très court, je crois qu'on était à 5-10 minutes grand max par
temps.
Ce qui fait que ça permettait comme ça de traiter très vite beaucoup de sujets.
Tout le monde pouvait pas bien sûr aller à tous les sujets en même temps, mais c'est
pas un tel de parler très vite de certains sujets et que même certains puissent revenir.
En fait, on en a parlé la semaine dernière, on en revenait, c'est pas les mêmes personnes
autour de la table.
En fait, ça fait vivre un peu le sujet, le débat.
Et en fait, là dans ces cas-là, c'est que les gens viennent très souvent avec des cas
concrets.
Ils viennent avec, bon, voilà, je sais qu'on a parlé de tels sujets, la formation par
exemple, mais bon, moi, j'ai un problème avec Cassandra en prod.
Hop, je pose ça, quoi qu'on fait.
Et ça permet comme ça que les gens puissent amener les sujets quotidiens de manière très
facile.
C'est une petite bête de machine à café, institutionnalisée et organisée.

C'est ça qu'on avait mis en place qui me paraît être très intéressant à faire.
On peut vous appeler Eftiel parce que vous avez la référence pour ceux qui connaissent.
Videoludique.
Non, vidéo ludique.
D'abord, c'est Battle Star Galactica.
Tata, videoludique.
Le jeu Eftiel est génialissime.
Oui, mais avant, il est Battle Star Galactica.
Et je reviens dessus.
Après, t'as aussi l'avantage que tu crées du lien.
Moi, je suis chez J.C. Decaux.
Je t'ai dit avant, j'ai monté ça, c'est justement faire des meet-up internes au niveau
de la DC Group.
Et c'est évidemment une occasion, c'était entre une fois par mois, une fois par trimestre,
suivant les sujets qu'on arrivait à traiter puis les gens qu'on avait à regrouper.
Mais donc, l'idée, c'est d'avoir, ça serait une réunion, deux heures, je me suis
un plus, d'avoir une première conf, d'avoir le temps de manger puis d'avoir une deuxième
conf après.
Et l'idée, au-delà du partage du savoir, t'as aussi toute la dimension.
Je crée du lien entre les gens qui ne bossent pas forcément tous les jours ensemble.
Et c'est vrai que ça, pour ça, c'est aussi un effet qui se coule assez sympa.
Parce que du coup, des gens qui, finalement, on tombe tous un peu sur le même problématique
dans nos projets.
Et donc, on est arrivé finalement, on a eu quelques petits quick wins parce que, bien
on a chance, ça permet de le réimplementer ailleurs facilement et ainsi de suite.
Et juste par curiosité, c'est des équipes de combien ? Pour en arriver au stade où les
gens ne se connaissent pas, ne travaillent pas forcément ensemble ?
Ah, c'est pas mal, je ne sais pas, peut-être, c'est moins d'ailleurs une dizaine d'équipes.
80 personnes contre 80.
Les décis, bref, et juste les interne, c'est une certaine de personnes avec les prestats,
t'en as plus.
Et donc, l'idée, c'est de faire des gens qui n'étaient pas forcément dans les mêmes
locaux en plus.
Donc, les décisions, ça va être parmi les gens qui sont sur des sujets très différents,
quoi, du SAP, du vélo en libre et service, du machin, du bidule.
Et finalement, on a trouvé, on a réussi à trouver quelques sujets un peu transverses,
ce qui est pas mal, puisque puis c'est gagnant même pour l'entreprise.
On a fait le tour, de toute façon, on y reviendra.
La transmission du savoir, c'est un sujet sans fin.
La culture, le sharing, ça fait partie.
Grand pilier, on en parle tout le temps.
Quand vous avez donné quelques solutions à mettre chez vous, si jamais vous voulez,
n'hésitez pas à revenir, même si vous en avez d'autres qui ont bien marché.
Parce que c'est quelque chose qu'on a, voilà, on connaît les BBL, on connaît les meet-ups,
on connaît les beer and take qu'on a déjà eu.
Donc, c'est des meet-ups de 17h à 18h avec de la bière en entreprise.
Il y a plein de formats qui existent.
Voyez ceux qui sont peut-être les plus adaptés à vos contextes.
Et si vous avez une solution magique qui permet aux gens expérimentés d'apprendre
avec plaisir et de passer des journées à partager avec quelqu'un d'expérimenté.
On en dépelle.
Vous connaissez un des temps, mais partez-là.
Si vous avez vraiment une solution magique.
Vous avez compris la solution, voilà, c'est bon, ouais.
Solution magique, regardez.
Je préfère des deux billes.
Les gens, ils veulent tous se demander.
Donc voilà, pour le premier sujet sur la formation,
et on va passer un sujet sur le test et l'infrastructure AsCode.
En fait, c'était un message sur le spectrum de Nicolas un peu en mode...
Boutier la mer.
Oui, sur les tests dans l'infrastructure.
Donc, je vais te laisser Nicolas remettre le contexte
et puis, en débatant un peu après.
Donc, mon sujet du moment, c'est effectivement,
enfin, un des sujets du moment, c'est pilotage d'infrastructure avec Antibol,
qui est très bien par plein de côtés, mais qui...
Mais pour moi, le souci, c'est...
Enfin, le point un peu embêtant, c'est de se dire que, effectivement,
aujourd'hui, il n'y a pas de solution...
Enfin, il y a vraiment de solution, en dehors de...
Ben, tu fais ton playbook, tu le run,
tu espères que ça ne casse pas trop,
et tu fixes et tu le run jusqu'à ce que ça fonctionne.
Ce qui n'est pas forcément super satisfaisant,
surtout quand tu n'as pas forcément des environnements de non-prod
à ta disposition pour exécuter tes playbooks.
Donc, du coup, philharmonie, je commence un peu à chercher,
à voir, ben, tiens, comment est-ce qu'on peut tester,
parce que, bon, c'est vrai qu'aujourd'hui,
dans le milieu des développements, on a toute la partie,
ben, si-il y a un peu qui fait un peu ce boulot-là,
de dire, ben, tiens, je pousse du code,
ça a fallu des tests et c'est génial, et ça marchait bien.
L'état de l'art dans notre joli domaine n'est quand même pas ouf.
Souvent, ça...
Il y a un, il n'y a pas forcément beaucoup d'outils.
Quand il y en a, c'est souvent, il faut responner des infrastructures
de bout en bout.
Donc, il peut y avoir quand même un petit coup d'infra non négligeable.
Et plus, éventuellement, des playbooks qui ne le permettent pas forcément,
surtout quand on gère une couche réseau,
ou voilà, si on gère des plaintes d'IP dans tous les sens,
ça n'a pas bien marché.
Donc, du coup, ça a été un peu la misère.
Donc, j'ai fait échantement un tweet, il n'y a pas longtemps,
sur les gens qui font du anti-bull, comment ils font,
et j'ai les gens de redhat qui m'ont attrapé
qui m'ont rien vendu, ça, c'était plutôt cool.
Et en plus, qui m'ont proposé dans le...
le... le... l'outil qui est moléculen,
qui a alors, qui n'est pas un outil fait par redhat,
mais par meta-cloud ou un truc, un monde dans un lard,
qui veut justement tester les playbooks en cible de bout en bout.
Donc, il faut quand même provisioner des choses
soit via Docker, Vagrant, VirtualBox,
et ce que vous voulez, ou des provider cloud, si vous voulez,
mais qui inclut déjà une notion de,
vous avez dit des linters, ça vérifie les dents potenses.
Enfin, pour l'instant, c'est un peu le truc qui m'a mis plein d'étoiles dans les yeux
ces derniers jours.
J'ai testé cet après-midi, c'est pas encore tout à fait ça.
Pour redécrir en plus la target, une fois que tu la décris une première fois dans
le film.
L'idée, c'est que l'expérience à Spoon.NVM, ça joue ton playbook debout en bout et ça
vérifie que tout va bien.
Donc là, effectivement, la limite de l'usage, pour l'instant, je découvre molécules, j'ai
joué un peu cet après-midi avec.
C'est déjà les accès aux variables de groupe ou de host.
Il n'existe pas forcément toujours.
Donc il y a des bouts de contexte en Cible qui ne sont pas forcément communiqués quand
tu exécutes tes tests.
Ils sont un peu moches.
Et du coup, tu parles d'être testé des choses simples.
Et en fait, ce qu'il faut voir, c'est que les molécules, en fait, s'il fait l'intégration
entre en Cible, entre test infra, donc qui a un framework de test en Python qui permet
de tester pas mal de choses.
Je crois qu'il y a une intégration de InSpec, ça, c'est du rubis, le format de chef.
Il y a un autre framework qui est utilisé.
Mais l'idée, si on s'est testé, ça va valider que d'un point de vue déjà, syntaxe, yaml,
tu es tout bon.
Ça va valider ton idempotent.
Ça va créer une VM, exécuter ton playbook, détruire la VM à la fin et faire différentes
tests.
Tu peux faire pas mal de choses.
Donc il y a des côtés qui sont un peu prometteurs, mais on sent que c'est encore très jeune.
C'est pour l'instant des assemblages de différents outils et que du coup, il y a des choses qui
manquent ou en tout cas qu'il faut retravailler pour réussir à pouvoir vraiment tester le
playbook de bout en bout.
Et ça, ce que je connais pour l'instant, il n'y a pas forcément énormément d'outils
qui le permettent.
Même si on prend terraformes, aujourd'hui, quand on fait terraformes, le plan, il va
montrer un édif entre un état de départ et un état final.
Mais pour autant, est-ce qu'on peut vraiment faire du div dessus et bien voir ?
Ce n'est pas forcément simple.
Donc on sent que c'est un peu un sujet qui est encore très jeune et qui aujourd'hui,
effectivement, enfin pareil, puis dire, je fais un playbook un peu en mode virtuel et
je teste si mes variables sont bonnes et ainsi de suite.
Il y a des choses qu'on pourrait tester, mais qui ne s'exécute pas.
Il y a des choses qui ne marchent pas bien.
Même la check run de Danciboil, il y a des fois, il ne marche pas très bien non plus.
Donc ça, c'est...
Il y a vite des écueils.
Et voilà.
Alors, sans vouloir troller, après, je laisserai Bart, en ma vie, nous exposer un peu plus.
Mais Antibel n'a pas du tout été fait pour ça.
Ah oui, là, c'est un outil.
Enfin, ça a été fait par des outils d'ops et des ops qui l'ont fait en se disant, moi,
je fais confiance qu'en SSH et puis je mette un truc et moi, le code, j'aime pas ça.
Je fais que du piton et je fais du piton 2 parce que je fais que du piton 2 parce que
de toute façon, il y a que du piton 2.
Et clairement, il n'a pas du tout été conçu dans ce cadre-là.
Je connaissais, enfin, moi, je fais beaucoup de chefs avant et Bart aussi.
Et chef pour le coup, a été fait par des développeurs.
C'était Dev qui l'ont fait.
Et donc, tout l'outil est de base parti que sur le test.
C'est-à-dire que si c'est pas testé, c'est pas prouvé.
Et donc, c'est quelque chose où, dès le début, il y a une différence fondamentale
dans la philosophie des deux outils.
Donc, en fait, qu'il n'y ait pas de test dans Antibel,
j'ai l'impression de dire, c'est une feature.
Mais ça n'a pas été fait dans les mêmes logiques de début.
Et je pense que, sur Bart, tu peux nous dire un peu à vous l'état de l'art
que vous avez du test chez vous, qui sont ce qu'ils sont.
Mais il y en a quand même pas mal.
Et il y a deux logiques de test.
Enfin, je pense que c'est toi qui, à l'heure actuelle, l'expérience en termes de test
l'a plus poussé à ce niveau-là.
Alors, je suis en train de réfléchir à comment je vais articuler ma réponse.
Et que je passe ?
Oui, je vais revenir.
Ok, alors, je vais venir.
En fait, il y a deux types.
Non, en tout cas, dans Chef, il y a deux types de tests qui sont deux types de tests
complètement différents.
Il y a les types de tests inutaires, ce qu'on va trouver souvent dans les
développants, où on va tester le comportement attendu de la ressource qu'on
est en train de créer.
Je veux modifier IPTables.
Je teste en mettant tel paramètre.
Est-ce que IPTables, la fonction que je viens de créer, le playbook,
enfin, la logique que je viens de faire, fait ce que j'attends.
C'est déjà le niveau zéro du test qui est au moins ce que je code fait
à peu près ce que j'attends que ça fasse.
Et par rapport à des cas de test, ça fait ce que ça doit faire.
Ça paraît très con quand on parle de l'infrastructure parce que
enfin, on comprend pas trop ça.
Mais souvent, en fait, au bout d'un moment, les ressources de base qu'on a dans un
petit type, un petit bell chef, Pepe, ne sont pas suffisantes.
Et il faut coder ses propres ressources liées à ce qu'on fait.
En général, c'est à partir de là qu'on a perdu.
C'est à partir de là où on commence à faire du custom et on a
nécessairement besoin d'arriver à faire du custom.
Au bout d'un moment, on va créer ses propres ressources.
Mais les propres ressources peuvent être aussi assez génériques.
Tu utilises, tu vois, la ressource n'existe pas dans la communauté.
Tu la crées.
Enfin, moi, tu connais mon truc, tu détestes le custom custom.
Ouais, enfin, là, ça va être du custom dynamique, du custom.
On peut arriver à du custom compliqué.
On va avoir des trucs qui vont exécuter du code ruby derrière,
qui vont appeler des librairies qui ne seront jamais testés.
Beau vais code de chef.
Si c'est pas testé.
C'est ça.
Et donc, le problème, c'est que ces outils-là sont suffisamment permissifs
pour ouvrir l'accès à des développeurs ou à des ops ou des DevOps.
On s'en fout.
Mais ouvrir l'accès aux utilisateurs pour arriver très profond dans le code,
c'est très flexible, c'est très facile, c'est ouvert.
Et puis, on exécute du shell, on exécute du shell, on tire la rigot, etc.
On peut mettre du code ruby, tire la rigot dans le slashlib de chef ou je suppose que...
Dans piton, tu mets ta lit.
Dans piton aussi, on peut mettre de la lit piton, bien dégueu qui tache.
Et une fois qu'on est arrivé là, on a perdu parce qu'on fait des fonctionnalités
qui sont avancées, qui apportent de la valeur, qui sont pas testés, voire pas testables du tout.
Chef justement, les ressources de base qui te donnent et celles de la communauté ne sont pas dans ce cadre à espérer.
Est-ce que la réponse, c'est n'utiliser que la STDL, en gros, de chef ou de Nantes Syblle,
n'utiliser que les ressources officielles de base.
Et contentez-vous de ça.
Si vous cherchez à faire autre chose et aller plus loin, c'est que vous utilisez mal l'outil.
Alors ça, ça peut être la réponse 1.
Ou est-ce que la réponse 2, c'est engager des gros développeurs, des bons développeurs et...
Ou laisser les faire bien sûr.
Et voilà.
Et quand si vous faites quelque chose de custom, par pitié, testez-le, pour vous.
Mais ça, c'est un premier niveau de test.
C'est-à-dire, on teste le code qu'on a généré et qu'on a créé.
Après, quand il y a des choses plus compliquées qui sont des tests end-to-end,
qui sont là, en fait, les tests que tu veux, en fait, c'est testé.
Bah même, déjà, juste tester.
Enfin, le côté, ce qui est chiant dans Nantes Syblle,
mais ça, tout le monde l'a vécu, c'est d'exécuter mon playbook,
et le truc qui est chaud au bout d'un quart d'heure,
parce que la variable bidule n'est pas définie.
Et juste déjà attraper ça partout.
Ah, peut-être très mal Nantes Syblle, mais ça fait que qu'on ne revient pas.
Donc, il y a déjà des petites choses comme ça qui sont un peu ragentes.
Ou en se disant juste, il pourrait effectivement avoir un premier niveau de test,
où il arrive à charger un peu tous ses templates en mémoire,
et ensuite, il y a Sapet-Port.
Le chef.
Voilà, pour le coup, je suis en vie de dire chef.
Chef, il a une phase de compilation où il te fait le truc et il te fait à l'avance.
Genre, qu'est-ce qu'il va faire ?
Parce qu'en fait, il te fait un diff Terraform, en fait, il te le fait,
il te dit tout ce qu'il va faire, il y a un mode dry run,
où il va te dire exactement quelles sont les actions qu'il va faire,
quelles sont les implications que ça a, etc.
Encore une fois, le mode dry run, quand on fait quelque chose de custom,
je...
Je...
J'ai codé du cookbook communautaire,
et déjà, pour...
On s'astraignait et c'était compliqué de gérer le mode dry run.
Donc, je pense qu'il y a plus de 90% des cookbooks communautaires
qui ne gèrent pas le mode dry run,
et en interne, dans les compagnies,
ce n'est jamais fait.
Oui, ça, c'est le problème de la compagnie.
Nous, on a réussi à le faire dans nos autres compagnies avant, on était en...
C'est...
Non, c'est compliqué.
C'est compliqué.
Encore une fois, toutes ces bonnes pratiques-là,
on sait que...
Un petit qui ne le fait pas.
Enfin, nous, on n'avait pas tout, mais on en avait une partie.
Ouais, ouais.
Il y a une quand même une différence, tu vois, on peut...
Bon, il y a une tête-unie d'adaptation.
Non, ouais, ouais.
Non, mais voilà, il y a un 2 et pas...
Enfin, en cybole, ça a des avantages, on peut pas non plus...
Oui, une prise dans main qui est très rapide,
ça a très peu de tout prérequis,
ça a effectivement...
Mais est-ce que la contrepartie,
c'est de s'astreindre à n'utiliser que les ressources de base ?
Oui, mais même en faisant que ça,
ce que là, pour un son, on n'a rien de fantasme agorique hallucinant, quoi.
Et même en faisant ça, tu tombes quand même sur des écueils de...
Bah tiens, variable undefined, et blabla, blabla, quoi.
Et ça quand même moche quand on bout de...
Toi, dans un playbook, il y a un quart d'heure à s'exécuter,
et puis bien tu ne repars après pour un quart d'heure à nouveau, quoi.
Alors, tu peux toujours tricher, limiter,
pour que ce soit que ce bout de playbook s'exécute,
il y a des moyens, mais...
Mais ça, c'est...
C'est l'outil fermé, ça, c'est un petit doigt.
Si jamais l'outil peut failer lamentablement au milieu du truc,
ça sera genre, pourquoi vous l'utilisez ?
C'est simple, mais...
Enfin, ça...
En bref, là, c'est...
La vente, justement, elle a coïnant ses vente, je crois.
Après, ça part un peu dans le troll,
en genre, en fait, cet outil est quand même vraiment très bien.
Il y a plein de bonnes qualités, je sais que nous, c'est ce qu'on utilise.
Après, le fait qu'on l'utilise, c'est aussi parce que,
ça fait 2 ans ou 3 ans que le projet existe.
Je ne connais pas exactement tout l'historique du projet,
je ne suis pas là depuis le début.
Tout réécrire, c'est juste pas possible.
Enfin, on n'a pas assez de ressources,
on n'a pas assez de temps pour tout réécrire.
Et donc, cet outil, on n'est pas...
Je ne sais pas dire qu'on est piégés dedans,
mais c'est l'outil qu'on a et qu'on doit accepter,
donc avec ces qualités et avec ces défis.
C'est peut-être ça, en fait, que disait Bart,
tout à l'heure, on en restait en des ressources standard.
C'est que, personnellement, je pense que passer de...
Antibole à Peupet, à Chef, à Dockerfile,
ça doit être Simless.
C'est-à-dire que si jamais vous avez mis trop de logique
dans un truc, il ne devait pas en avoir.
C'est-à-dire loin de l'application,
parce que c'est rare, en plus,
que les ressources soient proches de l'application.
Rire, je n'ai pas dit que c'était pas le cas.
Mais dès que tu as deux repo-guits,
un avec ton Antibole et un autre plus loin
avec ton application,
tu as perdu si jamais les deux sont liés ensemble
avec une logique interne pour déployer l'application
qui est dépendante de la version de l'application, etc.
Tu as perdu.
Moi, je pense que chaque fois que j'ai essayé de créer
des ressources d'installation,
c'était fait pour faire le boulot que de l'installation.
Et quelqu'un pouvait le recoder derrière en n'importe quoi,
dans n'importe quelle langage, ça se faisait.
Et je pense que justement, on a mis trop de logique.
En fait, on a un outil qui est trop performant.
On peut faire facilement trop de choses.
Et cette facilité,
elle a un biais extrêmement fort
qui est qu'on s'y piège assez vite.
Elle est tentante, elle est alléchante.
J'ai l'impression que souvent, on arrive dans ce cas-là.
Le logiciel, en lui-même, aurait dû être testé.
Justement, je ne suis pas vraiment d'accord.
La solution qu'on a,
notre logique de déploiement est complètement décorée
du cycle de développement des développeurs.
Ils peuvent aller à leur rythme et déployer quand ils veulent.
Et ce ne sera absolument pas dépendant du code de déploiement
que nous, on utilise.
Alors, c'est quoi qui est compliqué ?
Quelles sont les points que tu dis que tu n'arriveras pas à redevlocuer ?
Ce qui est compliqué, c'est que nous,
la forge, ce qui sert à déployer pour tous les projets,
en fait, on a avec ce logiciel un catalogue de services,
un catalogue de choses qui sont prêtes pour les différents projets.
Puis qu'en gros, quand un projet vient nous voir et nous disent,
on a deux back-ends, des trois frontaines, je dis ça au pif.
Sauf que nous, derrière, on rajoute du skydns,
on rajoute un note ECD, on rajoute de l'ULK,
on rajoute tout un tas de services qui sont,
enfin, c'est notre sur-couche qu'on propose.
Et ça, on leur donne en mode, en fait,
c'est notre capsule qui va enrober le logiciel
qu'on nous prête de tous ces services.
Et donc, le déploiement est complètement indépendant
du cycle de développement logiciel.
Et moi, je pense que la logique n'est pas mauvaise, en fait.
Mais c'est juste que réécrire tout notre catalogue
avec quelque chose d'autre,
ça va nous coûter des mois de développement.
Et actuellement, on n'a pas les ressources pour le faire.
On n'a juste pas la...
C'était un choix, enfin, là, ça vient du choix de base,
qui est-ce que l'outil était adapté pour ça.
En fait, je n'ai rien contre Antibol, en fait, de base.
Mais je pense qu'à l'heure actuelle,
on l'a utilisé pour la mauvaise raison.
C'est-à-dire qu'en fait, Antibol, il n'est pas fait pour déployer,
il n'est pas fait pour s'exécuter sur la machine.
C'est un très, très bon orchestrateur.
C'est un excellent orchestrateur même d'ailleurs.
C'est-à-dire que utiliser Antibol pour aller après
exécuter des ressources d'un autre logiciel
qui est beaucoup plus adapté pour tourner en local,
me paraissait et me paraît être une meilleure idée.
Et les deux, en plus, enfin, Antibol peut très bien exécuter.
Tout le monde a des options à rajouter dans la ligne de commande.
Et en fait, on a voulu un outil homogène,
standard, enfin, et unique pour faire deux choses
qui étaient complètement différentes.
L'orchestration et l'installation qui sont,
mais vraiment aux antipodes les uns les autres.
Et il y a même le provisioning,
là, Xavier n'est pas là, mais il aurait parlé.
Il y a même trois boulots.
L'orchestration, le provisioning et l'installation
et le déploiement qui sont trois choses complètement différentes.
Et on pourrait très bien avoir…
T'en es d'y quattre.
T'en es d'y quattre, je dis quoi ?
Je le pourrais…
Non, je dis ça dans l'installation.
Au visionnier.
Au déploiement impliquétique.
Après, c'est déploiement impliquétique.
Déploiement impliquétique.
Le provisioning, en fait,
le provisioning, c'est créer l'ecosystem
pour que l'application tout rende.
Ça va être configuré des règles de base.
Et on a le déploiement après concret de l'application
qui peut être fait d'un autre point.
Et il y a l'orchestration que j'ai dit.
Donc, trois, après le déploiement.
Oui, je t'emmène.
Je t'emmène.
Je t'emmène.
Ouais, voilà.
C'est pour ça que là, j'ai aidé un peu définie.
Mais donc, c'est pour ça que…
Là, je le vois un peu comme ça.
Ça ne veut pas dire que c'est pas bien.
Mais donc là, on en revient au point que tu disais
qu'il y a donc le test end-to-end de logiciel
en infrastructure SCOD,
qui est un point extrêmement compliqué.
Enfin, dans le monde chef, on a…
Quel outil j'ai déjà ?
Inspec.
Enfin, Inspec, qui est plus général,
mais maintenant, on a…
Inspec ?
Chefs.
Kitchen, tu sais.
Kitchen, ouais.
Voilà, Kitchen, je ne sais plus quoi dedans.
Ça fait un peu trop longtemps que je n'y ai pas touché.
Test Kitchen.
Test Kitchen, voilà.
Enfin, oui, oui, oui.
Mais il appelle un…
Non, il appelle Inspec des serveurs specs.
Non, en fait, non.
Ils ont recodé entièrement
pour avoir touché…
Non, non.
Et donc, en fait, ils ont des outils en interne
ou à l'intérieur même des cookbooks,
on crée les ressources à tester
pour qu'au moment quand la CIA y passe
avec le bon outil,
en fait, ça installe tout ce dont on a besoin
et on teste ce qui se passe.
Donc, et dans l'outil,
est intégré la notion même de test.
C'est dans l'outil, c'est building,
dans les effets pour ça.
Voilà, c'est été fait pour ça.
Ils donnent un chef d'hiket
qu'on installe sur tous les posts, normalement,
qui est donc le chef development kit,
où il y a tous les outils
pour pouvoir lancer ces tests-là.
Donc, en fait, l'outil a été complètement basé
autour des tests, que ce soit des tests…
Ah oui, on a aussi des tests syntaxiques,
parce qu'on écrit du code, en fait.
Donc, la syntaxe du code qu'on écrit,
on a bien envie d'avoir une syntaxe…
Il parlait du LinkedIn aussi,
qui peut poser problème.
Oui, c'est ça.
Oui, mais là, tu as dans l'absence de molécules de fournis.
C'est quand même le…
Il vrai que par les fois, tu l'as pas, quoi.
Voilà.
Alors que dans le chef,
le tigre est fait par chef.
Ça dépend.
Ça dépend.
C'est pas quelqu'un d'autre qui le fait.
C'est vraiment l'outil.
Et built-in dans l'équipe chef, en tout cas,
il le propose…
Je ne pense pas qu'il y ait une bataille d'école
entre chef et ante-sibel,
parce qu'au final, ils ont tous des qualités,
tous des défauts.
On peut faire des trucs à frais avec chef,
on peut faire des trucs à frais avec ante-sibel,
et on peut rester simple dans les deux solutions.
C'est ce que je disais, mais en fait,
quand je compte la problématique de tests à pareil,
c'est là où on s'aperçoit que l'outil qu'on a choisi
n'était peut-être pas forcément le plus adapté.
Et en fait, c'est ce que je dis juste, c'est que…
Et en plus, je vais arriver à mon dernier point,
c'est que je ne crois absolument plus
dans ces outils-là pour faire ce dont on a envie.
C'est qu'en fait, même là,
quand on arrive au test end-to-end,
même avec du server spec, etc.,
on arrive à un problème que tu as un peu évoqué,
qui est la mutabilité.
C'est-à-dire qu'on teste une machine from scratch,
on teste si ça marche,
et une machine qui existe déjà à notre run,
qui tournait très bien sur une machine vierge,
il marche plus sur la machine normale,
et puis il a laissé plein de popos.
En fait, on s'aperçut qu'on pensait avoir créé un nouveau fichier,
et en fait, il en a laissé d'autres
parce qu'on a changé quelque chose.
Et ce n'est même pas forcément dû à des actions manuelles,
c'est peut-être parce qu'en un moment,
on a poussé en prod une version qui était un peu buguée,
je ne sais pas, d'une update d'un repo sur une centOS.
Et ce truc-là, il a été déployé sur 50 machines
avant qu'on rollback.
On n'a pas tout corrigé,
et il se trouve que ça a laissé un reliquat de fichiers
dans les sources RPM,
et ça nique tout après parce que ça frise des versions,
par exemple, et donc on a pu aimer les versions.
On peut arriver à des trucs complètement UBS qui n'ont plus aucun sens.
Je dirais que tu ne penses pas dire,
tiens, je fais d'abord « Ah merde, j'ai le mauvais fichier,
je fais tourner un playbook avec, je supprime le fichier,
je mets le nouveau ».
C'est même pas ça parce que ça, c'est des cases simples,
mais il y a des cases.
Oui, mais juste même ça, tu ne te fais pas,
tu fais juste en général « Tiens, mon fichier,
je mets juste la nouvelle valeur, et puis ça en crée un nouveau ».
Oui, dans des cas par exemple,
tous les dossiers en point dix,
où le logiciel part,
tous les fichiers qui sont dans le dossier pour créer sa configuration,
avoir plusieurs fichiers qui n'ont pas le même nom,
mais qui ont les mêmes valeurs dedans,
ou un peu différentes, etc.
Enfin, j'ai déjà eu des problèmes comme ça.
Et donc c'est pour ça que la discussion qu'on a eue,
elle m'a fait penser, mais…
enfin, limité beul quoi.
J'ai l'impression que ça fait des années et des années que ça existe,
mais que personne ne le connaît.
Même immutable ou pas,
là on parle de cas simples.
Même si on peut arriver à des edge cases,
tous les edge cases du monde,
on arrive à des cas simples qui sont « Je veux déployer mon application ».
Alors certes, elle a besoin de logging,
elle a besoin d'importe quoi, de discovery,
elle a besoin de tout un écosystème autour d'elle,
mais ça risque l'application.
Mais le jour où tu veux approvinuer ton hardware,
enfin nous on a le cas chez nous,
tester le end-to-end de installer une machine,
quand tu dois gérer, je sais pas, la version du firmware,
la version le RAID,
les configurations et les cartes RAID,
les configurations du network et tout,
enfin du network dans le sens « Est-ce que c'est bien routé ? »
« Est-ce qu'on a bien fait le bonding des deux liens côté network ? »
Enfin côté interface network sur le router.
Bah ouais, comment on fait ?
Et ça, nos équipes d'infra, on a beau râler sur elles,
respect parce que c'est super compliqué,
enfin ils sont face à un mur, c'est galère.
Aujourd'hui les outils non seulement,
ils sont pas forcément très bien adaptés pour le software,
mais quand on parle hardware, il n'y a plus rien,
c'est le désert absolu.
– Tu sais pas pourquoi tu peux pas le tester réellement,
ça passe tout à cas, c'est quoi.
Il faut éventuellement un pool de machines
que tu vas réinstaller tout le temps et avec les différents machins,
mais ça t'enlève pas les edge cases que tu peux avoir de la même manière que les...
– Arrête d'acheter du matos que tu peux pas tester,
enfin c'est pas comme s'il y avait plein d'alternatives à l'heure actuelle,
enfin 10 ans, l'open hardware, etc.
Les gars ils ont fait plein de firmware,
enfin Google a fait plein de top récemment là-dessus,
ou même d'autres des boîtes plus petites que ça,
qui font tout leur firmware en go,
enfin voilà, maintenant il y a des outils,
on aurait dit ça il y a 10 ans, je suis d'accord,
mais bordel, pas en 2018.
– Il y a pas beaucoup, beaucoup à notre connaissance
sur la place parisienne d'entreprises, même des grosses...
– Mais vous avez la taille pour...
En fait quand tu commences à avoir des problèmes de RAID et de firmware,
tu as la taille pour pouvoir le faire.
Moi, enfin moi j'ai des machines chez OVH, etc.
Il y a plein de problèmes de firmware, etc.
J'ai quatre machines, j'arrive à les gérer tout seul.
Quand t'atteins une taille très importante,
j'espère que tu as les ingénieurs pour les gérer
et pour faire des choix d'architecture à ce moment-là.
– Je suis d'accord, mais le hardware c'est comme un level above du software.
– Oui, mais il y a des solutions qui existent à leur étui,
et il y en a qui l'ont fait et on peut essayer de les traiter.
Et ça, le problème là, c'est qu'on arrive dans ce qu'on appelle
l'optimisation locale,
qui est que chacun fait sa petite optimisation dans son coin
sans avoir une optimisation globale.
Et donc racheter des machines différentes,
et bien oui, auquel les achats vont être pas contents,
mais peut-être que ça va y améliorer à l'autre bout de la chaîne.
Mais si jamais tout le monde fait une optimisation locale
avec les achats qui essaient de négocier les prix, au moins cher, etc.
– C'est hypothétique, mais...
– Oui, mais en fait, ça c'est le truc que j'ai envie de dire.
C'est que, enfin moi, il y a un truc ultra important,
c'est que si tu ne peux pas tester, tu ne fais pas.
– C'est un truc qu'on devrait mettre institutionnalisé
avec des règles partout au-dessus des murs,
au fronton des entreprises quand on rentre.
Si tu ne peux pas tester, tu ne fais pas.
– Alors, je veux dire, je peux juste rajouter,
moi, sur le principe, je suis assez d'accord.
Par contre, si jamais tu arrives à convaincre ta boîte,
de changer le matos pour avoir des trucs testables,
j'irai gérer une statue en ta faveur.
Parce que je pense que plus la boîte est grosse,
plus c'est difficile à faire bouger.
Et je pense que ça va être très, très, très compliqué
d'un point de vue humain, il va falloir se battre
pour plusieurs années.
Moi, je pense que vraiment, c'est une grosse partie du travail,
donc c'est aussi pour ça que j'en parle.
Mais essayer de faire bouger les entreprises,
plus c'est gros, plus c'est dur, en fait.
Et du coup, plus il y a de gens à faire bouger,
– C'est l'expérience que tu es en train de nous dire là.
– Non, je ne vais pas l'établir.
Non, ce que je voulais dire, c'est plus il y a de gens à faire bouger,
plus il y a de personnes à former, à essayer de convertir,
donc à cette culture de DevOps, à ces bonnes pratiques.
Et plus c'est compliqué, plus on se rete à des murs,
plus on a de la résistance.
Et du coup, il faut gagner en persévérance
et continuer à faire de l'évangélisation.
Mais c'est compliqué, c'est long et ça prend de l'énergie.
– Est-ce que j'ai le droit de faire une transition
ou est-ce que tu as quelque chose d'autre à faire,
parce que j'ai une transition géniale ?
– Ah, je vais te dire comment tu t'essais de Dockerfile aujourd'hui.
– Ah, bon allez, vas-y, on va continuer.
– Allez, allez, allez.
– Garde la transition, j'avais une super transition, on me lève.
– Je l'ai, je la garde là.
– Ouais, c'est extrêmement un problème.
En fait, ce que je pense, c'est que tu ne dois pas tester un Dockerfile.
Je vais être, c'est-à-dire que, en fait,
tu t'en fous ce que tu veux, c'est le résultat final et tu t'as le résultat final.
– Mais donc c'est pas une mode Run, Break fix, quoi.
– Hum ?
– Une mode Run, Break et fix, c'est juste qu'est-ce que ça passe, quoi.
– Ouais, non, oui, mais l'avantage, c'est que quand c'est Break,
c'est Break sur ma machine seulement,
et en fait, je ne pousse en prod que la version que je veux,
et surtout, je peux le rollback.
C'est-à-dire qu'un container, un artefact de container,
je peux le rollback sans effet de bord,
c'est-à-dire que la chose est repartie, etc.
Et c'est ça qu'on doit créer.
Donc en fait, il ne faut pas tester la façon dont on fait,
il faut tester le résultat,
et en fait, ce qu'on veut à l'heure actuelle,
moi, je m'en fous si les gens mettent n'importe quoi dedans.
Enfin, vraiment, ça sera chiant pour eux,
et je viendrai les aider, etc.
Ce que je veux à la fin, c'est juste que les gars,
ils puissent bien développer et avoir ce dont ils ont envie,
et ce dont ils ont besoin.
Donc en fait, tester le Dockerfile,
ils pourraient même le faire avec plein d'autres outils.
Ce que je veux tester à la fin, c'est un contrat,
c'est est-ce que le conteneur qui est spawné
répond à ce qu'il devait faire à la base ?
Mais dans un tiball, c'est le même niveau, finalement.
Enfin, ton résultat...
Mais le problème, c'est que l'outil n'est pas...
La finalité.
L'outil n'est pas la finalité.
Donc, tu test quelque chose qui va tester quelque chose.
Enfin, en fait, il y a deux niveaux d'abstraction
qui deviennent extrêmement durs à faire.
C'est le homme qui a dit qu'il y avait le loup,
qui avait le loup.
C'est un peu ça le problème.
Alors que quand on test un Dockerfile,
comme on est application-centrique,
on teste l'application.
On teste si le contexte de l'application fonctionne.
Et ce contexte-là, il marchera sur quasiment tous les Linux.
Donc, on a directement un test qui est, en plus,
au Dockerfile, il est proche du code.
Donc, il est inscrit dans le déploiement dedans.
Ce n'est pas une autre équipe qui le gère.
Enfin, j'espère pour vous, en tout cas.
Donc, ça va être vraiment dans l'application.
C'est un artefact.
Avant, on avait un artefact qui était notre code,
notre bâche.
Et voilà, on espérait que ça marche.
Ça ne marche pas tout le temps, parce qu'en plus,
on nous fait des shellouts avec la moitié de la planète.
Et puis un jour, on s'est dit,
« On va quand même faire le piton avec des…
avec des…
avec des librairies.
Voilà, c'est un peu mieux.
Mais bon, on a quand même tout le contexte qui va autour,
le OpenSSL, etc. »
Et ensuite, on s'est dit, allez, on va faire des blobs géants
du type JAR ou SuperJAR, UberJAR,
ou YAA tout dedans, la moitié de la planète, etc.
Mais on a quand même un problème avec l'exécuteur.
Et puis à la fin, on arrive sur les conteneurs.
Enfin, et c'est juste la transition logique
de plein d'années de développement
qui arrive à ce concept-là.
Et allez-y, on joue, on joue.
C'est plus ça, en fait, moi, la finalité,
enfin, de ce que je vois, de ce que je vois à l'heure actuelle.
Et je reviens sur ma transition,
et je le fais très, très vite, et c'est à vous d'en parler.
Tu parlais donc justement de la difficulté
d'amener ces choses-là en entreprise.
Je pense justement, donc voilà, c'est le sujet de l'innovation
qui est comment on amène justement ces sujets de disruption
là-dessus. Et t'as un sujet,
t'as un truc très fort sur l'innovation,
et je vais te laisser.
Oui, en fait, c'est ce qu'on disait avant de commencer
l'enregistrement, c'est que pour moi,
enfin, rien que le mot innovation,
ça fait un petit peu buzzword,
j'ai un peu du mal à l'entendre.
Le problème que j'ai avec ça, en fait,
c'est que j'entends beaucoup, beaucoup parler d'innovation,
je lis pas mal d'articles sur le sujet.
Et en fait, j'ai pas tellement l'impression
d'amener l'innovation
dans l'entreprise où je suis,
où je suis mes clients.
J'ai plus l'impression du coup de
faire une veille techno, de le rapporter
des bonnes pratiques. Mais en général,
j'arrive pas à aller sur le point où je
pourrais innover et faire des choses
vraiment qui m'intéressent à
approfondir un sujet. Puisqu'en fait,
amener l'entreprise jusqu'à déjà,
je vais pas dire l'état de l'art,
mais sur déjà ce qui se fait de mieux au niveau
du secteur dans lequel on se trouve,
déjà ça, c'est très compliqué.
Donc, innover, j'en parle même pas, en fait.
Pour eux, c'est une innovation.
Pour toi, ça peut être frustrant,
parce que tu n'as pas à exemple pris un nouveau,
je sais pas quoi, mais eux,
les amener déjà l'état de l'art, pour eux,
ça peut être quasiment une révolution.
Pour toi, c'est pas forcément, t'as pas
les faits ou à ou, mais pour eux, ils l'ont.
Et quelque part, c'est le débat en fin, quand t'es prestat.
Est-ce que tu satisfais tes clients
ou c'est tout à fait plaisir ?
Non.
En caricaturent le truc, mais...
Un central innovation,
si on prend l'itimologie,
innovationner,
Monsieur Capello.
Innovarer, rendre nouveau,
renouveler, faire, c'est l'action.
C'est introduire quelque chose de nouveau,
en termes d'usage, de coutume, de croyance,
ou de système scientifique. Mais de nouveau,
enfin, ça dépend,
tu as les tons dents, ça peut être nouveau
pour l'entreprise.
Pour ton client, c'est nouveau.
Oui, c'est nouveau.
Pour ton client, c'est nouveau.
Pourtant, ça reste innové au sein de l'entreprise.
Ce que disait, je pense,
c'était compliqué, justement, d'amener ça.
Alors même qu'ils sont loin,
même si c'est innové un peu,
ou pas arrivé à l'état de l'art de nous,
c'est compliqué d'amener ça.
Donc là, apparemment, c'est la complexité
de l'innovation en entreprise.
Parce que, là,
la question que je vais poser, c'est
1, pourquoi c'est compliqué.
2, c'est
est-ce que ces gens ont déjà
innové ? La question, c'est
est-ce que
cette innovation-là, qui est compliquée,
ou est-ce que c'est toutes les innovations qui sont compliquées ?
Et on va déjà...
Typiquement, moi,
il y a un dessin que j'aime énormément,
où il y a deux personnes qui sont très occupées
à tirer une charrue qui a des roues carrées.
Et derrière, il y en a un qui arrive avec des roues qui disent
« Hey, vous ne voulez pas innover ? »
Et donc, les deux personnes qui tirent leurs chariotes, elles disent
« Non, non, on est trop occupés ».
Et pour moi, c'est l'un des principaux problèmes,
c'est
les employés, les équipes de manière
générale chez les clients.
Ils sont dans un quotidien, ils ne sont pas
dans une logique de remise en question,

d'amélioration continue. Ils sont dans
une logique de « Bah, c'est comme ça,
il faut bien qu'on fasse progresser
l'entreprise, donc il faut qu'on travaille,
et qu'on travaille dur. Et ils ne se rendent pas compte
que l'innovation est apportée,
l'innovation au sens que eux, pourront
faire quelque chose de nouveau, parce que pour moi,
ce n'est pas une innovation, mais on pourra
en débattre encore.
Et ça, c'est déjà une première difficulté
en fait, arriver à freiner
l'ardeur, en fait, l'ardeur
des équipes qui sont en entreprise, qui travaillent
dur, ils travaillent beaucoup, mais pas
efficacement, selon moi,
moi de mon point de vue extérieur, ils pourraient
faire mieux. Et du coup, amener
déjà cette logique d'amélioration continue, c'est
déjà un premier frein à faire bouger les choses.
C'est déjà quelque chose de difficile,
et encore une fois, plus il y a de personnes à
faire bouger, plus c'est compliqué
à faire bouger.
Pour prendre du recul en gros, sur son propre travail,
c'est quoi la stratégie ? C'est de travailler
moins, c'est de se définir
des... enfin,
qu'est-ce que tu pourrais conseiller, typiquement, dans ton
activité de conseil ? Alors,
moi je sais que je suis très...
Il y a quelqu'un qui est venu dans le guidon et qui a envie
d'avancer... Alors moi, je sais que je suis vraiment
partisan des postes café,
de la discussion un peu informelle entre collègues.
Je me suis aperçu de ça
il y a maintenant
5, 6 ans
que les journées où je passais
toute la journée devant mon écran et les journées
que je passais avec beaucoup de postes café,
j'étais plus efficace quand je faisais beaucoup de postes café.
C'est-à-dire que le peu de fois où je retournais sur mon PC,
je codais vraiment beaucoup plus vite.
Enfin, ou du moins, je retouchais beaucoup moins mon café.
C'est le café, ça.
C'est le café, l'idée.
Non, en fait, je ne vais pas forcément plus du café, mais
en fait, c'est vraiment la discussion.
C'est aérer son cerveau et justement,
re-refléchir à son problème avec un point de vue différent.
Et moi, je dis que moi, ça m'aide énormément
personnellement. Et donc, je trouve
que c'est une bonne manière d'aller discuter
avec les gens et de leur faire un peu changer
leurs opinions.
Est-ce que tu n'es pas un adepte de la méthode pomodoro ?
C'est le genre de truc là. Alors j'ai essayé,
mais j'aime pas le pomodoro, ça fait un bruit infernal
et j'aime pas trop le bruit.
Désolé.
Je change le bruit.
Là, ce que tu dis un peu, en fait,
c'est un sujet
qu'on avait pas mal ces derniers temps.
C'est la différence entre
les doers
et les sinkers.
Enfin, ça n'a pas vraiment, j'ai pas de mot pour le deuxième,
en fait, là, je viens de l'inventer à la rache.
Mais c'est opposé aux doers
qui va être que souvent, en entreprise,
en fait, on va privilégier les gens qui font,
qui font, qui défoncent, qui refoncent,
qui défoncent, qui ont refait et qui ont fait hier soir.
Et on a
toute une logique comme ça,
des fois, ou ce qu'on appelait
les pompiers pyromanes, et on en a vu plein,
beaucoup.
Ces gens qui étaient félicités pour
la caca qu'ils avaient réparé,
mais qu'ils avaient mis aussi eux-mêmes la veille.
Et donc là, en fait, ce que tu dis,
c'est qu'il faut s'arrêter
pour la pause café, il faut donc avoir du temps
pour discuter. Toutes ces choses qui sont
parfois, je ne l'ai pas dit tout le temps,
mais parfois, déconsidérées.
Est-ce que là, tu mettrais une corrélation
entre ces
deux faits-là, ça veut dire
à un moment où on va privilégier
le faire, et donc
l'entreprise ne va plus innover ?
Il y avait
une citation, en fait, c'est un peu le même sujet
que j'avais trouvé ça génial. C'était
des semaines de code, ça peut vous épargner
deux heures de réunions. Et
je trouve ça génial, en fait, c'est vraiment le côté
où on est partis à fond de balles
sur le code, sans réfléchir,
et plus tard, on s'est rendu compte que notre problème
n'était pas si compliqué que ça, et que, au final, avec deux heures
de réunions, on aurait peut-être pu résoudre le problème
avec juste trois heures de code
derrière, en fait.
Tu as des bonnes questions, tu as des bonnes règles, c'est tout.
Moi, je pense réellement que
prendre le temps de réellement réfléchir
à quelle est la solution qu'on veut
implémenter, de quelle manière
et du coup de le faire propre du premier coup
fait gagner énormément de temps.
C'est pas quelque chose...
Moi, j'essaie qu'à l'école, on m'a plutôt appris
que t'as un compilateur qui compile vite,
du coup, tu fais du code, tu test,
ça marche pas, tu recommences.
En fait, avec l'expérience, je m'apprêtais que c'est pas ça
le plus efficace.
Le plus efficace, je l'ai appris avec quelqu'un
qui était beaucoup plus expérimenté, il va avoir
une cinquantaine d'années, beaucoup d'années de code,
dans ses cinquante ans.
Et lui, il me disait que quand il était à les codes,
il n'avait que le droit à une compilation par jour,
c'était leur maximum.
Et donc, en fait,
lui, son grand secret, c'est de dire,
avant de compiler mon code,
j'essaye de m'assuiver
qu'il va fonctionner.
Et j'ai beaucoup appris de cette personne-là,
concrètement, c'est un peu ce que j'essaye d'appliquer.
Je préfère passer du temps,
encore une fois à la machine à café,
ou aussi parce que j'aime le café,
à discuter et à être vraiment certain d'avoir compris
pour pouvoir écrire le code une seule fois.
En général, je l'écris quand même 2-3 fois
parce que bon, c'est du code, je veux dire,
soyons honnêtes.
Mais ça, pour moi, c'est un peu le grand secret
de l'efficacité de nos jours,
vraiment planifier, comprendre ce qu'on veut faire,
où on veut aller, et ensuite coder.
Et ça, tu l'appellerais innovation ou pas ?
Ben moi, non, parce que je considère
que pour moi, faire l'innovation,
faire quelque chose de nouveau, faire quelque chose que personne n'a fait.
Je suis assez fan de l'exploration spatiale et de la NASA,
donc pour moi, innovation, c'est aller sur la Lune
quand personne n'y a jamais été.
Mais bon, en fait, c'est...
A part citer, on va aller sur Mars,
si vous voulez que qu'on plait.
J'allais avoir.
Donc pour moi, le mot innovation,
c'est vraiment ce concept d'aller vraiment là
où personne n'a jamais allé.
Mais si je me calme un petit peu
et que je me dis l'innovation dans l'entreprise,
c'est ce que l'entreprise n'a jamais fait,
là, du coup, oui, ça fait partie de l'innovation
de se poser les bonnes questions
et d'aller là où c'est efficace d'aller,
et là où il y a de la plus-value pour l'entreprise.
Moi, la question que j'avais,
c'est...
On peut élarger un peu, qui est...
Est-ce que les entreprises
n'ont pas perdu le goût d'innover ?
Parce qu'en fait, elles sont pas arrivées de nulle part.
C'est bien qu'il y a un moment, il y a un gars au début,
même juste qui a créé, qui a innové, qui a fait quelque chose.
Il y a forcément eu une innovation
essentielle au début.
Il n'y a pas eu de générations spontanées
de ces entreprises telles qu'elles sont à un moment donné.
Est-ce que...
il y a eu de l'innovation et elle s'est arrêtée ?
Est-ce que nous, on ne la voit pas avancer ?
Pas assez vite, parce qu'on a un goût
pour une transformation plus rapide.
Et donc, comme on va
très très vite d'un côté, on a l'impression
que les autres sont arrêtés alors qu'en fait,
non, ils avancent mais à un certain rythme.
C'est plus ça la question que j'ai,
dans quel serait votre ressenti là-dessus ?
Après, j'arrive, tu as
plusieurs aspects un peu culturels
où je pense en France, particulièrement,
on ne le risque pas forcément d'échec.
Donc, tu as quand même des freins à l'innovation
qui, ça peut être
poussé par exemple à des attitudes
assez immobilistes.
Tu peux avoir des vœux aussi,
les projets en général d'innovation,
c'est un peu des gros projets big bang,
donc c'est un projet big bang,
donc c'est avec tous les problèmes que ça peut poser.
C'est beaucoup de ressources, avec des gros impacts
d'institut, donc c'est compliqué à mener,
on n'a pas envie de déçuer les plâtre
20 fois.
Et c'est vrai que du coup, je répète
la seule solution, c'est un peu d'innovation
de toute façon un peu serène, c'est plus
de se dire, on fait de l'amélioration continue.
Alors, c'est plein de petites batailles au quotidien,
mais au moins on avance et on fait des choses,
mais ça, c'est pas forcément en réculture.
Et
des petites choses comme ça, un peu sous le radar,
enfin, on limite de visibilité
en tout cas, des échelons supérieures,
c'est vrai que c'est ce qui marche,
au moins tu es content de la faire,
tu es enlevé des épines du pied,
tu n'es pas forcément félicité pour,
bon c'est pas grave, mais je crois que c'est plus
des problèmes d'organisation, de budget,
de gestion de projets,
plutôt de faire des petits incrementaux,
et ça, aujourd'hui on n'a pas encore
cette culture là, que ça soit du convent
ou autre,
de faire de la ménagération continue simple
et au fur et à mesure.
Alors, c'est...
Il va réagir, parce que
j'en connais un qui boue quand on dit
qu'il y a un craint incremental.
Non mais c'est vrai que c'est une solution
d'amélioration, c'est sûr, mais
l'incrémentale, ça fait pas tout.
Non, je ne sais pas que c'est forcément tout,
mais déjà, moi, c'est des petites avancées,
c'est... Le Shadow Hitis, souvent,
c'est pas de l'incrémentale. Souvent, le Shadow Hitis,
c'est... C'est juste... Enfin, après,
ça dépend comment on définit l'incrémentale.
L'incrémentale, je vais le voir, en mode
on change une ligne de code par ci par là, et c'est
l'incrémentale. Introduire une nouvelle technologie,
pour moi, c'est... C'est...
une innovation. Et là, en fait, à utiliser
le terme de Big Bang, et c'est vrai que, tu vois,
je n'aime pas l'innovation qu'un incremental,
mais je n'aime pas l'innovation Big Bang.
Et je pense qu'en fait, il y en a une autre,
je ne suis pas du tout dans un tiers exclu là-dessus,
c'est que, en fait, il y en a une autre qui est
la coexistence de plusieurs techniques,
de plusieurs solutions en même temps.
Et ce Darwinisme des solutions, qui est
j'aime bien... Je vous donne des exemples,
j'aime bien EULK et j'aime bien Prometheus,
ou pas Prometheus, et ou...
whatever solution, là, non, voilà, enfin...
On va mettre deux solutions,
l'une à côté de l'autre.
Il y en a bien une qui est arrivée avant l'autre,
la plupart du temps.
Mais la deuxième qui est arrivée peut très bien
disparaître par manque d'usage,
parce que pas adapté à ce moment-là,
parce que voilà,
personne n'y a vu l'intérêt pour revenir plus tard.
Et donc je trouve que, en fait,
justement, on oppose ces trucs-là en mode
soit je suis Big Bang, soit je suis incrementale,
et en fait, on fait un espèce de
vaivien comme ça entre les deux,
alors qu'on peut faire un peu des deux.
J'ai l'impression que...
Ouais, moi, ton incrementale, les dire, enfin,
je me tonge un cerf EULK dans ma boîte,
et j'en fais un premier envirage,
enfin, ça me va comme incrementale, quoi.
Enfin, ça me ferait une taille d'incréments,
en fin, mon link de code, voilà, mais...
Mais...
Et après, il fait un mental...
Quand elle dit récocher, oui, je pense que...
Partiement, tu as un truc qui est entre quelque part,
tu espères que ça s'affuse, quoi.
Le jour où tu remplaces ton EULK,
voilà, pardon.
Le jour où tu remplaces ton EULK par la solution
x ou y,
tu vas la faire cohabiter pendant x temps,
on va dire un an, deux ans, trois ans,
et au bout d'un moment, mon faute d'usage,
tu vas dire, ou de support des équipes,
tu vas dire, on va l'arrêter.
Pas de bol, t'as encore des utilisateurs qui les utilisent.
Je suis un utilisateur d'INBOX.
Oui, bah...
Je suis INBOX, tu vois ce que je veux dire,
c'est pas grave, je passerai à l'autre chose.
Je sais, je fais partie des très rares qui ont utilisé
la nouvelle solution, elle n'a pas marché,
on revient à l'autre.
Sachant que l'autre, en fait, c'est...
Dans le cas de Gmail, par exemple, c'est inspiré
de pas mal de fonctionnalités qui avaient été dans INBOX,
elles sont ennées dedans.
Je te donne un exemple que tout le monde
connaît et a vu et a fait.
Donc, en fait, il y a une polinisation,
je l'adore ce mot là maintenant,
des solutions entre elles, c'est-à-dire que,
de la concurrence,
n'est aussi de l'entraide entre les solutions,
il faut pas opposer les deux, c'est pas parce qu'on a
une solution et une autre, le fait qu'elles existent
ensemble font qu'elles s'améliorent ensemble.
Et même si à la fin on en a vu,
parce que les utilisateurs sont dedans,
et bah là, tu fais du support, tu leur dis,
tu ne fais pas un arrêt brutal, tu dis pas, genre,
regardez, je vous avais dit que la solution n'était pas bien,
et regardez, je l'ai fait tomber en arrachant les câbles,
et je vous avais dit que c'était pas bien.
C'est pas non plus ça qu'il faut faire.
Mais de dire une dépréquestion de date,
de laisser aux gens le soin de
passer, de migrer progressivement à autre chose,
je pense, j'ai pas encore migré de INBOX,
je suis toujours dessus.
Je verrai quand je change.
Je raccroche les neurones, comme d'accord.
Je rebondis
sur le fait de l'innovation et de la
entreprise au début qui faisait quelque chose
et puis pourquoi elle ne serait plus capable
de faire encore quelque chose des années après.
Je pense que, bah comme
dans la vie d'un individu, il y a une vie
de la société.
La société au début, elle a, voilà,
son mission statement, c'est de faire un produit,
de faire un service, et bah
de partout les moyens d'y arriver. Donc elle va y arriver,
elle va construire, elle va
innover, donc si son service marche, c'est forcément qu'il apporte
quelque chose de nouveau à l'utilisateur.
Donc on peut estimer que c'est une innovation, on ne serait
ce que de créer, de faire fonctionner son entreprise.
Il peut y avoir une innovation dans le design,
une innovation dans lui-exe, une innovation
technique, on s'en fout.
Mais si ça marche, c'est qu'il y a une innovation
une fois qu'on a fait ça,
il faut solidifier ces marchés
et conquérir d'autres marchés, mais après,
ce what ? Une fois que
l'objectif de son entreprise, c'est de proposer
ce service-là, qu'est-ce que fait l'entreprise ?
Est-ce qu'elle trouve un autre service ?
Est-ce qu'elle change de, est-ce qu'elle se dit
bon, bah maintenant, je ne sais pas, je vendais
des petits pains, je vais mettre avant de
faire des cornichons.
Ou, ou qu'est-ce qu'elle fait ?
Est-ce que, est-ce que, donc le réflexe
comme tu disais culturel, peut-être en France
et je pense partout ailleurs, Google a le même
problème. J'estime, bon sauf qu'ils
ont une force de développement qui est autrement
à des échelles supérieures,
qu'ils arrivent à s'en sortir, c'est, on
solidifie, on concentre,
on rationalise
et on, en gros, on augmente les marches
quoi, on fait la même chose en mieux.
Et ça correspond à l'état d'esprit
incrémental, non-révolutionnaire.
Donc, pour moi, ça paraît
logique, enfin logique, pas
étonnant, en tout cas, c'est assez expliquable
qu'une entreprise arriver à un certain
degré de maturité, bah, soit
beaucoup plus réticente a une innovation,
ou a la nouveauté, a de la révolution
même, parce qu'elle, en fait,
ça ne répond plus
aux besoins de l'entreprise, en un point
de vue business.
Dile ? Ouais. Dile, si jamais tu as
SLA et complètement, et complètement
respecté, etc.
C'est ça, c'est pourquoi faire, enfin, pourquoi
faire mieux, ça tourne.
J'ai, voilà, cette réponse là,
si jamais on est
à peu près, à peu près
sur de soi, enfin, même pas sur de soi,
que les faits sont là et que la chose tourne.
En plus, on a les, enfin, on a
des graphiques de marché, on a des marquetteux
qui sont là pour faire des études du marché,
en termes de prix, on est dans le normal.
Dile, et qu'est-ce que tu fais maintenant de tout égat ?
Tu les vires ?
Tu vas dans un nouveau marché, sachant que tu avais déjà un
qui t'est déjà acquis.
C'est vrai que l'idée, ça pourrait être
on libère, on fait mieux, on libère du temps
et on utilise nos ingénieurs pour retrouver une nouvelle idée.
Donc au final, tu fais de la nouvelle innovation.
Mais c'est pas ça qui est fait, techniquement.
Enfin...
En même temps, des ingénieurs qui ont plus de travail
sur le produit, j'ai jamais vu ça.
On s'est déjà arrivé.
Attention. Non, non, non, mais ça m'est
déjà arrivé, d'arriver à un truc
où, en fait, le produit
est là, il n'a pas de problème,
il n'y a pas d'utilisateur, donc
il n'y a pas grand chose à faire.
Mais là, il n'y avait pas d'utilisateur.
C'est un problème et que
les ingénieurs ne peuvent pas forcément résoudre
instantanément la dessus.
Un produit avec des clients
et où les ingénieurs ne font plus rien,
moi, je pense que non.
C'est vrai que ton circuit technique, il va bouger,
tu as quand même un minimum de maintenance,
minimum d'activité.
Ça ne va pas faire sans d'innovation, mais ça va être
du la MCO.
C'est chiant.
Oui, mais il en faut.
Oui, mais là-dessus,
j'accepterais pour moi de ne pas avoir d'innovation
sur une MCO quand t'as SLA.
Tu continues de résoudre
les quelques pourcentages
qui sont derrière la virgule,
jusqu'au 100%, qui a des gens
pour régler ça.
Je suis d'accord.
Moi, je n'ai pas l'impression, et comme le disait Romain,
tout le monde a du boulot,
j'ai pas l'impression que quelqu'un en soit là.
C'est-à-dire que je ne connais aucune boîte
dont une semi-SLA
à peu près bonne soit respectée.
Et voilà. Donc, en fin de compte, il y a encore du boulot,
il y a encore d'innovation. Et en fait, je pense,
la différence aussi dont je voulais venir,
c'était quand on parle d'un crémental,
souvent, en tout cas tel que je le vois,
et c'est peut-être un biais
de gens qui vont parler de ça,
c'est on le voit en mode, bon,
on y est presque à notre SLA,
mais voilà, on met encore un petit coup de boost.
Là, un peu de temps, on fait rentrer
le chausse-pied, etc.
Et puis vous allez voir,
la technologie qu'on avait choisie, elle était bonne.
Et en fait, il n'y a pas de remise en cause
de la technologie ou de la solution
de l'architecture qui avait été faite
pour justifier le proème
de SLA en fait. C'est en se disant,
avec un petit peu d'huile de coude
et un petit peu de polish, on arrivera
à arriver dans notre SLA. Vous allez voir,
c'est prévu. On fera mieux.
On va vous installer des machines physiques en 15 secondes.
Et bah non. Non, non, c'est pas possible
parce que la technologie qui a été empruntée
techniquement, bon, je prends un exemple,
on va peut-être arriver à 20 minutes
ou une demi-heure, mais on passera jamais
sous les 5 minutes parce que
ce techniquement
ne sera pas possible.
Mais qui en a vraiment, après, il y a pas de temps
d'abusant ? Qui a besoin d'une machine en moins de 30 minutes ?
N'importe qui, c'est peut-être intéressant.
Après, je sais plus,
aujourd'hui, je viens d'un société
qui a un peu un dictat de l'innovation
ou si tu fais pas de l'innovation,
tu es de TTS bin,
et justement, jusqu'au bout,
tu as vraiment besoin de l'innovation.
Si ton produit à un moment correspond à plus personne,
tu vas mourir. Donc, si tu veux perdurer,
il faut que tu y auras 9 sur autre chose.
Il y a un peu, au côté, il y a un peu de buzzword
où il faut occuper le terrain,
il faut occuper l'espace, il faut faire de l'innovation
qui t'a valorisé un peu tout et n'importe quoi.
Un peu. Un peu.
Mais c'est un problème de recrutement,
il y a le problème de attirer les talents.
Donc, il n'y a pas 36 000 manières
d'attirer, merci.
Ça devient dur.
On arrête.
C'est la fin.
D'attirer des gens techniques,
c'est avec de la technique.
Il faut avoir quelque chose de vendeur
d'un point de vue technique.
Les questions, c'est
est-ce qu'on en a vraiment besoin ?
Est-ce qu'on peut prendre un peu d'un porte-quitte technique ?
On s'en fout d'avoir des talents.
Faites du peu que je peux, et puis roulez jeunesse,
roulez sous les aisselles,
comme qui va bien, et ça passera.
Et on a des problèmes.
C'est vraiment un point.
La réponse que j'ai à ça,
c'est le fait que
quand on n'a pas les bons pônes personnes techniques,
quand on n'a pas tout ça,
ça marche tant que ça marche.
Ça marche tant que ça marche.
C'est le plus dur, c'est pas la chute.
C'est-à-dire, quand on est en chute libre,
dans un référentiel,
dans les lois,
dans les lois de la dynamique,
bref, j'ai... c'est trop tard.
Mais en gros, quand on est dans un mouvement
rectiligne uniforme,
on est comme si on était à l'arrêt.
L'arrêt n'est qu'un mouvement rectiligne uniforme.
Le problème, c'est le jour où quelqu'un
doit changer et qu'on doit changer cette route-là.
Et en fait, c'est ce qui se passe quand un concurrent arrive
sur le marché à un moment donné,
ou c'était pas prévu.
Et il se passe quelque chose où on se fait bouffer
en deux temps, trois mouvements, et des cas comme ça
dans notre industrie de personnes qui a été
quasiment toutes puissantes
sur leur marché
et qui se sont fait défoncer.
Mais il y en a plein. Enfin, je le dis, il y en a.
Nokia était le premier vendeur
de smartphones au monde, mais genre avec une part
de marché de plus de 90%.
De GSM, quand même. Non, non, non.
De smartphones, ils avaient les Tels, leurs marques...
Les Palmes, et tout. Non, pas les Palmes, les Lumianes.
Les Vsans. Non, les NG.
Les Trucs, ils ont sorti avec les jeux vidéo.
Mais non, non, non. Ils avaient leur truc.
Les Simbianes, c'est ça. Tous les Simbianes.
Tous les Simbianes, ils avaient 98% du marché avec les Simbianes,
pas trop en France, mais partout ailleurs.
Ils avaient 98% du marché des smartphones,
enfin des smartphones à l'époque, on n'appelait pas ça comme ça,
mais des téléphones intelligents.
Des assistants. Voilà, des assistants téléphoniques.
Et ils avaient 98% du marché.
Ils se sont fait défoncer
en l'échelle pas longtemps, et même plus que ça,
après, c'est qu'ils sont morts. Ils sont complètement morts
par faute d'innovation, en ayant viré
toutes les équipes d'innovation, en ayant fait le N900
et de l'avoir vendu, d'avoir fait toutes
ces tentatives d'innovation. C'est pas vrai.
Ils étaient, c'était une boîte de télécommunications,
donc de radio, voilà, de radio,
techniquement, parce que c'est là
où ils avaient leur histoire, c'est là où ils avaient leur brevet.
Et au final,
comment dire, le terrain de l'innovation
s'est déplacé, c'était plus sur
qui ira le plus vite sur le réseau, qui fera la meilleure
la meilleure modulation, c'est celui
qui fera le meilleur design, et qui fera la meilleure
expérience. Ils avaient eu une première innovation
sur les Simbianes. Il y a bien un gars, un jour
qui a fait un grand...
Il posait les boules, ses couilles sur la table, et qui a dit
« on va faire un téléphone intelligent » et il a gagné.
Sauf que après toutes les tentatives
qui ont été faites après type N800,
N900, je crois que c'est ça...
Engage.
Après t'as les usages, je t'ai pas compris.
Non mais les lumières, c'est bien ça.
On n'est plus, je n'en ai pas non plus là.
Oui mais qu'on éviterait qu'elles avaient...
Mais d'autres ont réussi. Ce que je veux juste dire,
c'est que eux étaient très avancés technologiquement,
ont arrêté. C'était les leaders.
C'était les leaders, se sont reposés sur leurs acquis en disant
« Ouais, un Android, vous êtes bien mis en place.
On va stabiliser Simian.
On va vous rajouter 3, 4 fonctions.
Ok, vous voulez du touch, on va vous rajouter du touch en Simian.
Et c'est ça qui s'est passé.
Mais vraiment, c'est ça qui s'est passé. Ils ont été complètement wipés.
Le cas de Microsoft est un peu différent.
Attention, en mot que j'ai fait,
Microsoft était multidisciplinaire
dès le début.
Ce qui fait que là où dans certaines parties,
ils se sont fait laminé, c'est-à-dire qu'il n'y a plus un seul serveur
Microsoft, Windows
dans le top 100 des supercalculateurs.
Ouais, bon, la belle affaire. Ils s'en foutent, ils avaient plein d'autres marchés
pour gagner de l'argent et donc ils ont réussi à se refaire.
Mais dans un certain secteur,
une boîte qui se fait complètement wiper de la carte
alors qu'elle était leader, il y en a plein.
Et toute notre histoire est faite ça.
Souvent, on dit que c'est la faute de, je sais pas quoi, etc.
Pour voir un peu l'intérieur
de certaines boîtes, on voit que des fois, c'est la technique.
C'est la technique qui était plus capable d'innover, plus capable de délivrer,
plus capable de faire plein de choses comme ça.
Quand on peut plus délivrer, le marketing peut faire ce qu'il veut.
Si on délivre puant, on délivre puant.
Donc on est en retard et on ne peut pas rattraper.
On a pris trop tant d'insences.
Je pense que l'innovation est vraiment au coeur, même des fois.
On ne s'en rend pas compte tant que ça n'arrive pas.
Et c'est vrai qu'il y a des marchés où sans doute,
tu n'auras jamais de concurrents parce que c'est des marchés d'ultraniches
où il faut connaître le marché,
où on a ce qu'on appelle un unfair advantage
dans le marché, qui est qu'on le connaît,
qui est qu'on a une réputation énorme.
Je vais prendre le bon coin par exemple,
qui était un site mais moche comme c'est pas permis.
N'importe qui aurait pu les détrôner.
eBay par exemple, n'a pas été attendu, etc.
Bon, il y a eu d'autres aspects autres que techniques
qui ont fait qu'ils sont restés.
Mais ils sont quand même en train de se remettre en cause à leur actuel.
Ils sont en train de tout refaire pour justement pouvoir innover
et intégrer d'une nouvelle technologie.
Et on le voit à leur actuel dans le site Le Bon Coin.
On a plein de nouvelles choses qui apparaissent.
Un rythme effréné par rapport au 10 ans qu'on a connu avant.
Rien n'a bougé.
Rien n'a bougé, même pas la page d'accueil, mais pas la couleur.
C'était fait exprès.
Oui, mais en fait...
Au bout d'un moment, ça marche plus.
Mais c'est vrai que c'était identitaire.
Oui, mais maintenant ça marche plus.
Et demain...
C'était identitaire.
C'est un mot.
Je me souviens que le poids, c'était moche quand même.
Oui, mais ça chaisait.
Non, ça dépend des marchés extens.
Mais là, ils s'en ont bien compte qu'il faut changer.
Et donc à leur actuel, je pense que si on est dans...
Je n'en ai pas oublié qu'ils écoutent ça,
savent qu'il y a des offres d'emploi chez Le Bon Coin.
Je pense qu'on a été appelés, vu des offres d'emploi là-dessus.
Moi, ils ne m'ont pas appelé moi.
Ah...
Moi, je suis plutôt d'atadoque.
Oui, c'est vrai que toi, ils vont toucher la bague.
Ils vont toucher la bague.
Le néo.
Bon voilà, je pense qu'on a fait déjà,
on a fait un bon tour.
Je pense qu'on est bien, on va avoir la voix,
on va se reposer pendant 2 jours à la voix
suite à ce podcast.
Donc, est-ce que vous avez tous un dernier mot,
quelque chose qui vous est revenu,
parce que le premier sujet est main, j'ai pas eu le temps de dire ça.
Non, je me refais ce podcast là pour le coup.
Ah, c'est le but, c'est bien de se réécouter là-dessus.
Bon, je pense qu'on...
Non, non, c'est bon.
Après, en fait, il y a des trucs qui pourraient revenir,
mais je pense qu'il faut faire partie à un prochain numéro.
Voilà, de toute façon, voilà.
J'ai plein d'autres choses que j'ai regardées dans les sujets
qu'on a abordés, notamment sur l'innovation.
On a déjà fait un épisode sur le recrutement.
Vous voyez, j'ode, je sais pas combien.
Saison.
J'ai pas mis de saison, dessus.
On ne refais pas assez pour faire des saisons.
139.
C'est pas mal aussi.
Voilà, c'est ce que je me suis dit.
Vous pouvez ne pas être d'accord, je m'en fous en fait.
Non, pour le coup, on verra peut-être plus tard.
Au début, j'en avais mis.
Bon, bref, on va arrêter là.
Merci à tous de nous avoir écoutés.
Vous pouvez donc retrouver, j'espère...
Donc là, je suis en train d'appréhender cette magie
qui est la vidéo.
Ce truc un peu magique qu'on voit apparaître en 2018
sur certaines plateformes.
Des choses comme...
Ça n'a pas été très passionnant, très animé.
Le son est mieux, on était autour d'une table.
On nous a dit que le son était très bon.
Il paraît.
Il paraît parce qu'on a des gens qui l'ont vu en direct.
Il y avait des privilégiés.
En tout cas, les prochaines fois, je vais peut-être...
Si vous êtes abonnés à la chaîne YouTube,
peut-être qu'on fera des événements comme ça
avec une diffusion en direct
où vous pourrez commenter en live via YouTube.
Et la semaine prochaine,
nous avons le DevOpsRex.
La semaine prochaine, nous allons au DevOpsRex.
Donc, si jamais vous voulez nous rencontrer,
allez sur la vidéo, voyez notre tête.
Alpaguenou dans le DevOpsRex.
La semaine prochaine pour...
pour DevOpsRex.
On verra.
On va voir si c'est dans le cas
de la conférence dont on parlait tout à l'heure.
Je pense que là, des retours d'expérience,
ils sont tous normalement différents.
J'espère qu'ils n'ont pas eu tous les mêmes problèmes tout le temps.
En tout cas, on essaiera de faire un truc.
J'ai toujours voulu faire un vlog.
Voilà, un petit truc. On interviewe les gens
directement dedans. On verra ce qu'on fait.
C'est la surprise.
Si vous avez des suggestions, des idées,
n'hésitez pas à nous en parler.
Et voilà.
Si vous êtes arrivés jusqu'ici, bravo.
Donc voilà, on vous dit au revoir.
Et puis à une prochaine dans le DevOps.