WEBVTT

00:00:00.017 --> 00:00:05.497
Bonjour à tous, bienvenue au premier DevOps. Alors, c'est un podcast pour parler

00:00:05.497 --> 00:00:07.797
de la méthodologie DevOps. Donc, bienvenue à tous.

00:00:08.197 --> 00:00:11.977
Ça va se passer en plusieurs parties. On aura de l'actualité,

00:00:12.197 --> 00:00:15.677
on aura des chroniques. Donc, on espère que ça vous plaira.

00:00:15.797 --> 00:00:18.057
D'abord, je vais laisser un peu tout le monde se présenter.

00:00:18.237 --> 00:00:20.977
Donc, on est quatre à table. D'abord, Barthélémy.

00:00:21.177 --> 00:00:24.697
Donc oui, Barthélémy Vessemont, DevOps chez Criteo actuellement.

00:00:25.177 --> 00:00:28.437
Et j'ai un background Ops, tout simplement.

00:00:28.437 --> 00:00:34.057
Moi je suis Marc Falzon, j'ai 32 ans je suis Ops depuis un peu plus de 10 ans

00:00:34.057 --> 00:00:38.057
et je travaille actuellement chez D2SI où je suis consultant cloud et automatisation

00:00:38.057 --> 00:00:42.997
Et moi Victor de Monchy DevOps aussi avec un background Ops je travaille chez

00:00:42.997 --> 00:00:46.777
Criteo dans la même équipe que Barthélémy Et enfin moi Guillaume Letron,

00:00:46.997 --> 00:00:51.997
donc je suis DevOps ascendant Ops et je travaille à l'heure actuelle chez Vente Privée,

00:00:52.737 --> 00:00:56.497
Donc maintenant on va passer à une petite rubrique qu'on va essayer de garder

00:00:56.497 --> 00:00:59.137
à chacun de nos podcasts casse, en tout cas si ça plaît à tout le monde.

00:00:59.437 --> 00:01:03.177
On va demander à Marc de nous expliquer ce qu'est le DevOps pour lui.

00:01:04.037 --> 00:01:07.817
Alors, pour moi, le DevOps, c'est ce qui se passe lorsque les développeurs et

00:01:07.817 --> 00:01:10.897
les opérateurs, donc habituellement des sysadmins, travaillent en bonne intelligence

00:01:10.897 --> 00:01:13.457
et en ayant conscience de leurs contraintes respectives.

00:01:13.877 --> 00:01:16.857
Pour moi, le DevOps, c'est plus une approche, une façon de penser,

00:01:16.917 --> 00:01:21.177
plutôt qu'une organisation hiérarchique, qui consiste naïvement à mélanger des

00:01:21.177 --> 00:01:24.637
devs et des ops dans une même équipe et attendre que la magie opère.

00:01:24.837 --> 00:01:25.997
Sans faire de mauvais jeu de mots.

00:01:27.357 --> 00:01:30.957
Dans les faits, ça tient en fait à assez peu de choses, mais il faut quand même

00:01:30.957 --> 00:01:32.177
que les deux parties jouent le jeu.

00:01:32.697 --> 00:01:38.217
Selon moi, les développeurs doivent se responsabiliser vis-à-vis du code qu'ils

00:01:38.217 --> 00:01:41.037
produisent et prendre conscience que leur job ne s'arrête pas après avoir un

00:01:41.037 --> 00:01:44.977
comité dans Git, mais à le déployer et à le porter en production,

00:01:45.177 --> 00:01:48.697
se porter garant du bon fonctionnement et de ses performances en production.

00:01:49.317 --> 00:01:54.297
Et de leur côté, les Ops doivent être transparents quant à l'infrastructure

00:01:54.297 --> 00:01:57.937
qu'ils construisent et qu'ils opèrent et ils doivent contribuer à outiller les

00:01:57.937 --> 00:02:01.677
développeurs pour qu'ils puissent déployer en autonomie et superviser le comportement

00:02:01.677 --> 00:02:04.917
de leur application en production en leur fournissant des logs,

00:02:05.017 --> 00:02:07.097
des métriques et des alertes, par exemple.

00:02:07.757 --> 00:02:11.877
Moi, je suis convaincu que cette extension du domaine de responsabilité,

00:02:11.897 --> 00:02:15.597
j'ai pas trouvé mieux comme terme, est bénéfique pour les deux parties.

00:02:15.757 --> 00:02:19.517
Des développeurs qui sont plus infantilisés, mais plutôt responsabilisés,

00:02:20.157 --> 00:02:23.757
seront plus à même de faire ces quelques pas supplémentaires vers l'exploitation

00:02:23.757 --> 00:02:27.517
d'un service en production et même potentiellement proposer des changements

00:02:27.517 --> 00:02:32.117
d'infrastructures pertinents ou tout du moins d'ouvrir la discussion avec du

00:02:32.117 --> 00:02:35.137
recul et une perspective différente des Ops.

00:02:35.597 --> 00:02:39.797
Les sysadmins proactifs plutôt que réactifs à toujours régler les problèmes

00:02:39.797 --> 00:02:43.117
quand ils arrivent, capables de mettre la main à la pâte en termes de développement

00:02:43.117 --> 00:02:46.457
d'outils internes plutôt que du vulgaire scripting entre guillemets.

00:02:47.117 --> 00:02:50.937
Travailler sur les concepts de déploiement et d'observabilité offre aux devs

00:02:50.937 --> 00:02:55.277
de la visibilité sur leurs services et bénéficient de leur aide en cas d'incident

00:02:55.277 --> 00:02:57.797
ou même en simple cas d'optimisation de l'infrastructure.

00:02:58.851 --> 00:03:02.531
Super, très complet, je pense qu'on ne peut plus être d'accord tous.

00:03:02.791 --> 00:03:03.831
Très bien préparé en tout cas.

00:03:04.951 --> 00:03:07.231
Alors, on va passer maintenant à une petite phase d'actualité,

00:03:07.311 --> 00:03:10.351
donc bien sûr, on espère que ça changera un peu chaque semaine.

00:03:10.971 --> 00:03:14.711
Je vais demander à Victor peut-être de commencer une petite actu que tu as pu voir cette semaine.

00:03:14.951 --> 00:03:21.451
Alors, cette semaine, non. Par contre, c'était il y a deux ou trois semaines de ça.

00:03:21.451 --> 00:03:27.571
Du coup, je vais parler de SpaceX,

00:03:27.831 --> 00:03:34.251
qui a sorti une vidéo où ils ont parlé de tout ce qu'ils ont fait pour arriver

00:03:34.251 --> 00:03:38.211
jusqu'au succès qu'ils ont eu pour la roquette réutilisable.

00:03:38.791 --> 00:03:42.931
Et ça va bien servir mon propos pour la chronique après, parce que les mecs

00:03:42.931 --> 00:03:47.931
n'ont pas honte de montrer qu'ils ont échoué plein de fois avant de réussir

00:03:47.931 --> 00:03:50.951
à sortir quelque chose qui fonctionne.

00:03:51.451 --> 00:03:55.091
Donc c'est une vidéo YouTube que vous pouvez retrouver avec tous les échecs

00:03:55.091 --> 00:03:58.351
de Falcon 9. En l'occurrence, je l'avais vu sur Twitter, en fait. D'accord.

00:03:59.331 --> 00:04:02.811
Marc ? Eh bien, écoutez, moi, j'étais pas très inspiré pour ces actus,

00:04:02.891 --> 00:04:04.151
alors je vais parler un petit peu cloud.

00:04:04.311 --> 00:04:07.711
Il y a quelques jours, Google Cloud a annoncé un nouveau type d'instance qui

00:04:07.711 --> 00:04:11.331
peut monter jusqu'à 96 VCPU et 624 gigas de RAM.

00:04:11.771 --> 00:04:14.951
Donc voilà, c'est la bonne grosse bobasse. Donc du coup, on espère que maintenant,

00:04:15.091 --> 00:04:16.651
Java pourra enfin tourner convenablement.

00:04:17.731 --> 00:04:21.551
Désolé, c'est gratuit. Voilà, petit instant troll. Voilà. Barthes ?

00:04:21.551 --> 00:04:24.431
Pour ma part, ce n'est pas très lié au DevOps,

00:04:24.691 --> 00:04:27.911
mais c'est un petit anniversaire parce qu'il y a sept semaines,

00:04:27.991 --> 00:04:32.111
en fait, je crois que c'était lundi, c'était l'anniversaire des 10 ans d'ITER,

00:04:32.271 --> 00:04:37.551
qui est un projet international de travail autour de la fusion nucléaire et

00:04:37.551 --> 00:04:42.111
de l'exploitation de cette technologie, qui est quand même une technologie assez ancienne,

00:04:42.751 --> 00:04:47.811
en tout cas qui est connue, l'exploitation de manière industrielle de cette

00:04:47.811 --> 00:04:49.711
technologie pour générer de l'électricité.

00:04:49.911 --> 00:04:52.551
Donc, c'est ses 10 ans. Et voilà, le projet est toujours en marche.

00:04:52.691 --> 00:04:55.711
Il, on espère le voir aboutir de notre vivante.

00:04:56.571 --> 00:04:59.371
Très bien. Et alors, pour moi, la petite actu que j'ai pu trouver,

00:04:59.431 --> 00:05:03.851
c'est toutes les sociétés, notamment les GAFA, qui commencent à pas mal recruter en France.

00:05:03.991 --> 00:05:08.531
On voit pas mal de news en ce moment tomber avec Google qui va recruter en France.

00:05:08.711 --> 00:05:12.571
Et on voit donc une certaine attractivité quand même de Paris et même globalement

00:05:12.571 --> 00:05:17.831
la France pour les grands acteurs du web. Donc, plutôt cool.

00:05:18.251 --> 00:05:22.531
Voilà, n'hésitez pas à regarder. Ça veut dire que vraiment, on a une compétence,

00:05:22.531 --> 00:05:26.271
on a un écosystème qui est attractif et c'est plutôt une bonne chose.

00:05:26.371 --> 00:05:28.671
Et ça fait quelques années déjà que ça commence à l'être.

00:05:29.191 --> 00:05:32.871
On pourrait noter Docker qui a ouvert des bureaux à Paris, etc.

00:05:33.191 --> 00:05:36.511
Vraiment, il commence à y avoir pas mal de sociétés qui se mettent,

00:05:36.511 --> 00:05:37.611
Datadog aussi par exemple.

00:05:37.871 --> 00:05:42.191
Plein de sociétés qui s'installent à Paris et j'espère ailleurs aussi, en région.

00:05:43.034 --> 00:05:47.354
Alors maintenant on va passer à un petit instant chronique, donc chacun de nos

00:05:47.354 --> 00:05:49.754
intervenants a normalement préparé un peu un sujet.

00:05:50.374 --> 00:05:52.874
Donc on va commencer par Marc, on l'a fait au tirage au sort.

00:05:53.214 --> 00:05:57.834
Donc Marc va nous parler du Blue-Green Deployment et je le laisse parler.

00:05:58.094 --> 00:06:01.554
Voilà, donc effectivement on va parler aujourd'hui de la méthode de déploiement

00:06:01.554 --> 00:06:05.374
Blue-Green et de Canary Deployment.

00:06:05.554 --> 00:06:08.454
Donc qu'est-ce que c'est que le Blue-Green Deployment ? c'est une technique

00:06:08.454 --> 00:06:13.654
de déploiement sans coupure, sans downtime, qui permet un retour arrière rapide

00:06:13.654 --> 00:06:16.374
en cas de complications et instantané.

00:06:16.554 --> 00:06:21.374
Le principe, c'est de disposer de deux plateformes applicatives si possible

00:06:21.374 --> 00:06:25.054
identiques, dont une seule des deux sert le trafic à un instant T.

00:06:25.134 --> 00:06:29.334
La première, qu'on appelle Blue, fait tourner une version de l'application N,

00:06:29.454 --> 00:06:33.374
lorsque vient le moment de mettre à jour l'application, en version N plus 1.

00:06:34.114 --> 00:06:37.334
Celle-ci est déployée non pas sur la plateforme qui sert actuellement le trafic,

00:06:37.334 --> 00:06:39.234
mais sur la seconde plateforme, appelée Green.

00:06:39.714 --> 00:06:45.234
Et donc le trafic est ensuite aiguillé sur cette seconde plateforme au niveau du Load Balancer.

00:06:45.954 --> 00:06:48.914
Si un problème survient à la suite de la mise en production sur la nouvelle

00:06:48.914 --> 00:06:52.734
version, il est donc du coup possible de réaiguiller le trafic sur la plateforme

00:06:52.734 --> 00:06:57.414
précédente, la Blue, quasi instantanément, et donc ainsi de revenir au précédent

00:06:57.414 --> 00:06:58.474
état de fonctionnement connu.

00:06:58.614 --> 00:07:02.274
A l'inverse, si tout s'est bien passé et que tout tourne sur la plateforme Green,

00:07:02.474 --> 00:07:06.694
elle reste active jusqu'à la prochaine version à déployer, mettons version N

00:07:06.694 --> 00:07:10.734
plus 2, qui sera faite du coup sur la plateforme Blue, et ainsi de suite.

00:07:11.814 --> 00:07:14.334
Donc, il y a une variante de cette technique qui s'appelle le Canary,

00:07:14.934 --> 00:07:19.694
qui consiste à déployer la version N plus 1, non pas sur une nouvelle plateforme

00:07:19.694 --> 00:07:23.414
dédiée, qui peut être un petit peu problématique en fonction des infrastructures,

00:07:23.474 --> 00:07:27.434
tout le monde n'a pas les moyens de se payer un double lot de frontaux, par exemple,

00:07:27.874 --> 00:07:32.294
et donc du coup, de déployer la nouvelle version N plus 1 sur un seul des supports

00:07:32.294 --> 00:07:34.394
applicatifs, un serveur ou une instance de VM,

00:07:34.494 --> 00:07:38.454
par exemple, et donc qu'elles ne reçoivent qu'une fraction du trafic de production

00:07:38.454 --> 00:07:42.574
et donc analyser les potentiels effets de bord sur cette nouvelle version avec

00:07:42.574 --> 00:07:45.274
les outils d'observabilité classique, les métriques, les logs, etc.

00:07:45.774 --> 00:07:51.914
Et graduellement ensuite déployer la nouvelle version sur le reste des instances progressivement.

00:07:52.034 --> 00:07:56.794
Ce sont des techniques qui sont assez souples et pas forcément très complexes

00:07:56.794 --> 00:08:02.114
à mettre en œuvre avec les orchestrateurs qui commencent à devenir le nouveau

00:08:02.114 --> 00:08:06.234
standard maintenant dans le monde des containers, notamment Kubernetes, pour ne pas le citer,

00:08:06.894 --> 00:08:11.034
intègrent nativement ce genre de déploiement pour faciliter un petit peu les

00:08:11.034 --> 00:08:13.054
mises à jour de versions et transparents.

00:08:14.344 --> 00:08:17.764
J'ai terminé. Super. Donc là, on va commencer un petit débat maintenant,

00:08:17.964 --> 00:08:19.604
parce que je sens qu'on a plein de choses à dire.

00:08:19.844 --> 00:08:23.424
Déjà, j'ai peut-être une question. Est-ce que tu l'as déjà vu en place ou mis

00:08:23.424 --> 00:08:27.724
en place, ce type de déploiement ? J'ai joué avec, prototypé avec,

00:08:27.884 --> 00:08:31.624
mais je ne l'ai pas vu ou mis en production à grande échelle.

00:08:32.224 --> 00:08:36.104
Donc, j'ai fait des tests et j'ai procédé à des déploiements de prototypage.

00:08:36.144 --> 00:08:39.584
Et donc, du coup, on voyait qu'on pouvait monter de version sans qu'il y ait

00:08:39.584 --> 00:08:41.724
d'accro en termes de qualité de service.

00:08:42.444 --> 00:08:46.244
OK. Moi, j'ai une autre question. parce que j'ai déjà été confronté à ce genre

00:08:46.244 --> 00:08:49.464
de problème-là, c'est comment on fait avec une base de données.

00:08:50.304 --> 00:08:53.144
Genre MySQL, tout simple, toute bête, parce qu'on est quand même dans un cas

00:08:53.144 --> 00:08:56.964
d'usage quasiment majoritaire dans de petites applications, comment on fait

00:08:56.964 --> 00:09:02.404
pour assurer la pérennité de à la fois la version N plus 1 et la version N pendant

00:09:02.404 --> 00:09:04.624
cette phase de migration, en fait ?

00:09:04.624 --> 00:09:07.004
C'est une très bonne question, et en effet, c'est là que ça se complique.

00:09:07.144 --> 00:09:10.984
Ce n'est pas si simple que ça. Dans le cas où, en effet, cela implique des changements

00:09:10.984 --> 00:09:13.664
de schémas de base de données, notamment, c'est là que le bas blesse.

00:09:13.664 --> 00:09:16.084
Donc une des solutions de contournement

00:09:16.084 --> 00:09:18.824
ou plutôt de technique qui est invoquée dans ce genre de cas,

00:09:18.904 --> 00:09:23.464
c'est de faire les changements de structure de base de données réversibles,

00:09:23.524 --> 00:09:26.744
à savoir lorsqu'on veut par exemple changer le type de colonne,

00:09:26.764 --> 00:09:30.884
ce serait de créer une seconde colonne qu'on va peupler avec le nouveau type,

00:09:31.004 --> 00:09:36.364
qu'on va peupler à partir de la nouvelle version et ensuite dans un second temps

00:09:36.364 --> 00:09:40.864
vraiment faire le switch sur le nouveau schéma donc du coup une fois qu'on a

00:09:40.864 --> 00:09:43.964
validé que le bon fonctionnement le bon faussement de la nouvelle version.

00:09:44.064 --> 00:09:46.704
Ça ne demande pas plus de travail pour les développeurs ? Ce n'est pas plus

00:09:46.704 --> 00:09:50.264
complexe pour eux d'aborder, de tester ce genre de choses ?

00:09:50.264 --> 00:09:53.644
C'est possible, mais est-ce qu'on fait vraiment des changements de schéma de

00:09:53.644 --> 00:09:58.464
base de données vraiment souvent en production ? Au début du cycle de vie d'un

00:09:58.464 --> 00:10:03.924
logiciel, par exemple, on sera amené beaucoup plus facilement à faire ce genre de changements-là.

00:10:04.744 --> 00:10:07.304
Peut-être que ce n'est pas le moment aussi, on va vouloir utiliser à tout prix

00:10:07.304 --> 00:10:08.144
le Blueground Deployment.

00:10:08.464 --> 00:10:12.364
Oui, c'est pas un incontournable. Si jamais le projet est tout début,

00:10:12.564 --> 00:10:15.484
critique, etc., c'est qu'il y a peut-être un problème dans la définition.

00:10:15.644 --> 00:10:18.904
Je pense que pour tout ce qui est StateLight Web Service, ça ne pose pas de problème.

00:10:19.044 --> 00:10:22.384
Par contre, et là, on est tous d'accord là-dessus, par contre,

00:10:22.384 --> 00:10:25.684
pour ce qui est base de données, moi, j'aurais tendance à ne pas trop utiliser ce genre de système.

00:10:25.844 --> 00:10:31.424
Alors peut-être, comme dit Marc, on peut prévoir des procédures de migration,

00:10:31.584 --> 00:10:33.644
mais je trouve que ça rend le truc un peu trop compliqué.

00:10:34.581 --> 00:10:39.421
Peut-être qu'ils n'aient pas la bonne méthode de déploiement. Je vous... Pardon.

00:10:39.661 --> 00:10:43.321
Non, mais vas-y. Je vous recommande, juste pour terminer, un très bon article

00:10:43.321 --> 00:10:46.041
écrit par Octo, l'entreprise Octo, sur le sujet-là.

00:10:46.121 --> 00:10:51.561
Je posterai le lien soit sur le Twitter ou sur le blog du podcast.

00:10:51.921 --> 00:10:55.861
Super. Moi, j'ai par contre aussi un autre commentaire.

00:10:55.861 --> 00:10:58.961
C'est que si jamais le Blueground Development n'est pas forcément fait pour

00:10:58.961 --> 00:11:01.821
vous, il y a une autre technique. Sinon, c'est le feature flapping ou le feature

00:11:01.821 --> 00:11:05.601
switching qui est donc d'intégrer dans l'application directement l'activation

00:11:05.601 --> 00:11:09.681
ou non des codes, qui permet comme ça de déployer avec une autre configuration.

00:11:10.141 --> 00:11:13.901
Donc là, ça veut dire par contre que l'application doit vraiment être pensée,

00:11:13.901 --> 00:11:15.701
développée avec cette idée-là en tête.

00:11:16.081 --> 00:11:19.781
Là, pour le coup, j'aurais tendance à dire que c'est intrusif au niveau du code,

00:11:19.861 --> 00:11:22.921
et donc du coup, ça peut générer potentiellement beaucoup de déchets en termes

00:11:22.921 --> 00:11:28.141
de développement et un peu de salir, entre guillemets, son code avec beaucoup

00:11:28.141 --> 00:11:29.161
de switches, de ifs partout.

00:11:29.821 --> 00:11:33.061
Et ça, les développeurs, en effet, seraient peut-être pas forcément enclin à le faire.

00:11:33.101 --> 00:11:36.741
C'est une philosophie et ce que ça peut amener, ça peut apporter en plus,

00:11:36.741 --> 00:11:42.021
c'est une finesse dans le choix que l'A-B testing ou le Canary deployment ou

00:11:42.021 --> 00:11:43.921
le Blue Green deployment ne permettent pas.

00:11:44.001 --> 00:11:47.501
Par exemple, on va pouvoir cibler des utilisateurs précis, par exemple d'un

00:11:47.501 --> 00:11:51.801
OS ou les utilisateurs d'un Android ou de Mac ou peu importe.

00:11:51.961 --> 00:11:56.461
Et le feature... Le switching. Le switching, oui. Toggling. Le feature flag.

00:11:56.881 --> 00:11:59.441
Le feature flag. Le feature flipping aussi. Voilà.

00:12:00.641 --> 00:12:06.721
Et en fait, Cette méthodologie-là va permettre une granularité beaucoup plus

00:12:06.721 --> 00:12:09.221
importante et qui peut être intéressante pour les développeurs.

00:12:09.281 --> 00:12:12.361
Je suis d'accord avec toi. Dans un autre contexte, c'est technique intéressante,

00:12:12.381 --> 00:12:16.381
par exemple pour faire un mode dégradé de son application, pour pouvoir désactiver

00:12:16.381 --> 00:12:19.801
certaines fonctionnalités lors d'un incident, par exemple désactiver des fonctionnalités

00:12:19.801 --> 00:12:22.901
coûteuses sans avoir à pénaliser tout le reste du service.

00:12:23.779 --> 00:12:26.979
Super. Alors maintenant, on va passer à la deuxième chronique.

00:12:27.039 --> 00:12:29.979
On va demander à Victor qui va nous parler de la culture de l'échec.

00:12:30.519 --> 00:12:33.959
Juste pour vous teaser, après on aura quelque chose qui s'appelle mécanisation

00:12:33.959 --> 00:12:35.299
contre automatisation.

00:12:35.739 --> 00:12:39.019
Et enfin, les armes du DevOps. Voilà pour le petit teasing qui vient ensuite.

00:12:39.539 --> 00:12:43.559
Donc Victor, culture de l'échec. Oui, alors bon, c'est beaucoup moins technique

00:12:43.559 --> 00:12:46.199
que le Blue Green Deployment. C'est quelque chose de plus général,

00:12:46.259 --> 00:12:47.199
mais dont j'avais envie de parler.

00:12:47.739 --> 00:12:51.799
Donc la culture de l'échec. Et donc, avant de commencer, je voulais un peu définir

00:12:51.799 --> 00:12:54.119
les termes culture et chèque pour qu'on soit bien d'accord sur la définition.

00:12:54.879 --> 00:12:59.479
Donc, il faut savoir que la culture, au sens large, on peut la définir de plein de façons différentes.

00:13:00.319 --> 00:13:04.919
Mais une des définitions que j'ai cherchée, forcément, quand j'ai préparé cette

00:13:04.919 --> 00:13:07.759
chronique, et que j'ai trouvée, qui me semble plutôt bien servir le propos,

00:13:07.959 --> 00:13:12.179
c'est selon un sociologue québécois, qui s'appelle Guérocher.

00:13:13.079 --> 00:13:17.279
Donc, la culture est un ensemble lié de manières de penser, de sentir et d'agir

00:13:17.279 --> 00:13:20.979
plus ou moins formalisées, qui, étant apprises et partagées par une pluralité de personnes.

00:13:21.939 --> 00:13:25.459
Servent d'une manière à la fois objective et symbolique à constituer ces personnes

00:13:25.459 --> 00:13:28.239
en une collectivité particulière et distincte.

00:13:28.459 --> 00:13:31.619
J'espère que je ne vous ai pas perdu. C'est complètement, mais on va suivre

00:13:31.619 --> 00:13:33.699
le reste. Ok, c'était un peu l'instant culture.

00:13:33.979 --> 00:13:36.359
Ça sera un peu moins abstrait après. Maintenant, on passe à l'échec.

00:13:38.599 --> 00:13:42.199
En gros, ça veut dire que c'est un ensemble de personnes qui pensent de la même

00:13:42.199 --> 00:13:43.399
manière. Tout ça pour dire ça.

00:13:45.259 --> 00:13:48.719
Et donc, ça c'est pour l'aspect culture. Pour la partie culture.

00:13:48.839 --> 00:13:52.579
Et donc l'échec, bon, je pense que c'est assez simple à définir,

00:13:52.579 --> 00:13:54.939
mais juste pour être d'accord, encore une fois, je vais le définir.

00:13:55.319 --> 00:13:58.979
Donc l'échec, c'est une situation qui résulte d'une action n'ayant pas abouti

00:13:58.979 --> 00:14:00.439
au résultat escompté. Voilà.

00:14:00.859 --> 00:14:04.159
C'est tout simple. C'est clair. C'est clair. Et moins long.

00:14:04.919 --> 00:14:08.879
Et donc, dans un monde où on valorise de plus en plus la performance individuelle,

00:14:09.759 --> 00:14:11.179
plutôt que la performance collective,

00:14:11.719 --> 00:14:15.619
je pense qu'il peut être difficile de concevoir d'échouer par peur de laisser

00:14:15.619 --> 00:14:19.159
un avantage décisif à ses concurrents, par exemple si on parle au niveau business,

00:14:19.759 --> 00:14:25.999
ou même par peur de d'avoir une mauvaise note à sa,

00:14:27.919 --> 00:14:33.219
notation biannuelle s'il y a ce système en place dans son entreprise ou de ne

00:14:33.219 --> 00:14:34.179
pas avoir sa promotion, etc.

00:14:35.719 --> 00:14:39.619
Et donc, ce qui peut être intéressant, c'est plutôt que de redouter l'échec,

00:14:39.619 --> 00:14:43.939
de l'intégrer en quotidien dans le travail pour qu'il n'apparaisse plus comme

00:14:43.939 --> 00:14:45.979
une démonstration du manque de réussite,

00:14:46.719 --> 00:14:51.199
mais comme le corollaire de l'innovation et de l'action et donc en gros ça revient

00:14:51.199 --> 00:14:52.359
à dire qu'il faut banaliser l'échec.

00:14:53.451 --> 00:14:57.171
Comme on sait tous, c'est difficile de prévoir toutes les issues possibles d'un

00:14:57.171 --> 00:15:01.471
projet quand on le démarre, sauf si on veut essayer de faire du bon gros waterfall, des familles.

00:15:02.531 --> 00:15:05.051
Mais plutôt que de faire ça, on peut se dire, à un moment donné,

00:15:05.171 --> 00:15:09.791
on définit la direction générale vers laquelle on veut aller quand on démarre un projet.

00:15:10.291 --> 00:15:15.831
Et plutôt que de prévoir toutes les issues possibles, on favorise l'action et

00:15:15.831 --> 00:15:20.791
on réagit quand c'est nécessaire, en fonction du retour d'expérience de chacun.

00:15:20.791 --> 00:15:25.871
Et finalement, on arrive à un processus qu'on pourrait qualifier d'agile,

00:15:25.891 --> 00:15:33.171
plus ou moins, où on a une boucle d'itération assez rapide, en théorie efficace,

00:15:33.191 --> 00:15:34.531
entre les différentes équipes.

00:15:35.091 --> 00:15:40.051
Et donc, comment on pourrait appliquer ça concrètement dans le DevOps, justement ?

00:15:40.851 --> 00:15:43.711
Ce que je viens de dire, c'est travailler en étroite collaboration,

00:15:44.131 --> 00:15:47.431
voire même en immersion dans les équipes concernées par un même projet.

00:15:47.931 --> 00:15:52.951
On pourrait notamment appliquer le concept des feature teams.

00:15:53.851 --> 00:15:58.231
Prendre les décisions qui s'imposent quand il le faut, même si elles sont difficiles

00:15:58.231 --> 00:16:01.111
c'est à dire que si à un moment on va dans une direction qui ne fonctionne pas, plutôt que,

00:16:01.771 --> 00:16:06.731
d'essayer à tout prix de mettre des rustines et de faire en sorte que ça marche,

00:16:06.931 --> 00:16:10.371
alors qu'on sait que ça ne va au final pas marcher ou ça va aboutir à un truc

00:16:10.371 --> 00:16:14.091
tellement compliqué que ça ne va pas être exploitable, il vaut mieux dire stop,

00:16:14.171 --> 00:16:16.331
on arrête et on commence dans une autre direction,

00:16:17.071 --> 00:16:21.151
il faut valoriser capitaliser sur ce qui n'a pas fonctionné quand l'échec survient,

00:16:21.191 --> 00:16:24.431
ça c'est super important pour moi, c'est à dire il faut à tout prix,

00:16:25.231 --> 00:16:29.991
quand on prend la décision d'arrêter ou que ça va pas comme on voulait il faut

00:16:29.991 --> 00:16:37.351
ensuite débattre ensemble de ce qui n'a pas marché et en tirer des leçons pour

00:16:37.351 --> 00:16:38.251
pas reproduire les mêmes

00:16:38.671 --> 00:16:41.671
échecs plus tard et surtout quelque chose.

00:16:42.591 --> 00:16:46.531
Peut-être d'encore plus important c'est de ne pas essayer de rejeter la faute

00:16:46.531 --> 00:16:48.271
sur une équipe ou une personne.

00:16:48.831 --> 00:16:52.171
Parce que quand on est dans une boîte, quand on est dans une équipe,

00:16:52.191 --> 00:16:56.811
quand on est sur un projet, on est finalement tous dans le même bateau.

00:16:57.351 --> 00:17:01.851
Et l'échec peut affecter tout le monde de la même manière.

00:17:02.811 --> 00:17:08.351
Il ne faut pas le rejeter sur quelqu'un qui prend très mal le livre.

00:17:09.439 --> 00:17:13.999
Donc, ce que je veux dire, c'est que ça coûte moins cher d'accepter l'échec

00:17:13.999 --> 00:17:19.319
qu'on signe dans une voie, plutôt que de... Voilà, que de...

00:17:19.319 --> 00:17:20.699
Enfin, ce sera ma conclusion.

00:17:21.139 --> 00:17:24.479
D'accord. Plutôt que d'une voie sans issue. Alors, je vais te reposer la même

00:17:24.479 --> 00:17:26.359
question, c'est que j'ai pu poser tout à l'heure à Marc.

00:17:26.799 --> 00:17:30.219
Est-ce que tu as pu déjà vivre ce type de condition de travail,

00:17:30.519 --> 00:17:32.319
cette philosophie en tout cas ?

00:17:32.719 --> 00:17:38.619
Ouais, j'ai déjà pu vivre ça. C'est quand on arrive dans une boîte,

00:17:38.659 --> 00:17:43.159
par exemple, et qu'on nous donne un projet sur lequel on a un regard nouveau,

00:17:43.239 --> 00:17:47.039
parce qu'on ne faisait pas partie de cette boîte avant.

00:17:47.159 --> 00:17:50.439
Donc, on arrive avec un regard nouveau, on voit le truc, on se dit,

00:17:50.539 --> 00:17:53.179
mais ça ne peut pas marcher, pourquoi vous faites ça ?

00:17:53.699 --> 00:17:57.159
Il faut tout refaire, ça ne va pas du tout. On dit, non, mais ça marche comme

00:17:57.159 --> 00:17:58.299
ça depuis des années et tout.

00:17:58.879 --> 00:18:01.779
Mais là, on a plein de demandes des clients.

00:18:01.779 --> 00:18:05.659
Il faut qu'on modifie le truc pour que ça fonctionne on n'a pas le temps de

00:18:05.659 --> 00:18:11.079
tout redévelopper et même quand on dit ça prendrait moins de temps de repartir

00:18:11.079 --> 00:18:16.079
de zéro et de faire autre chose c'est pas forcément évident de convaincre en face

00:18:16.519 --> 00:18:18.499
quand on a ce genre de réaction.

00:18:19.503 --> 00:18:25.063
Moi, j'ai remarqué depuis quelques années cette tendance des grands du web à

00:18:25.063 --> 00:18:29.083
faire ce qu'ils appellent le blameless post-mortem, que j'aime beaucoup.

00:18:29.223 --> 00:18:32.303
J'aime beaucoup cette démarche-là, en effet, de faire l'introspection sur quelque

00:18:32.303 --> 00:18:34.563
chose qui a merdé. Il y a eu un fail.

00:18:35.183 --> 00:18:38.103
Du coup, on analyse les causes vraiment sans pointer du doigt,

00:18:38.223 --> 00:18:42.063
sans essayer de rejeter la faute les uns sur les autres. Et on va de l'avant.

00:18:42.183 --> 00:18:44.403
Et c'est vraiment quelque chose qui me plaît beaucoup. J'aime beaucoup cette approche.

00:18:45.163 --> 00:18:49.863
Moi je rajouterais aussi que peut-être pour des fois atténuer ce type de problème,

00:18:49.983 --> 00:18:52.603
c'est de mettre toute l'équipe, t'as parlé de la feature sim c'est même aussi

00:18:52.603 --> 00:18:56.083
la notation d'équipe c'est quelque chose qui permet aussi d'un seul coup d'embarquer

00:18:56.083 --> 00:19:00.103
tout le monde dans le même bateau de pas avoir forcément quelqu'un qui va être

00:19:00.103 --> 00:19:02.103
chargé du déploiement et si le déploiement se passe pas,

00:19:02.183 --> 00:19:05.783
et bien ça se passe mal c'est forcément de sa faute, ou en tout cas c'est lui qui va être pénalisé,

00:19:05.883 --> 00:19:10.043
mais en ayant une notation d'équipe en prenant tout le monde encore,

00:19:10.143 --> 00:19:15.023
mais il peut y avoir toujours une notation individuelle, mais vraiment dans l'aspect RH,

00:19:15.163 --> 00:19:18.643
quelque chose qui peut faire changer c'est vraiment aussi cette notation d'équipe,

00:19:18.683 --> 00:19:23.483
quelque chose que je vois in fine assez peu le manager est noté pour l'équipe

00:19:23.483 --> 00:19:29.063
mais c'est rare de mettre une notation c'est vrai qu'en général on dit que les résultats de l'équipe,

00:19:29.663 --> 00:19:31.683
ou de l'entreprise sont déjà.

00:19:33.483 --> 00:19:37.263
Pondérés dans la note finale pour des raisons x ou y mais c'est vrai que,

00:19:38.323 --> 00:19:43.643
on note en général que sur des objectifs personnels et on voit rarement les

00:19:43.643 --> 00:19:48.523
objectifs d'équipe ou les objectifs biannuels qui sont reflétés sur nos résultats.

00:19:48.863 --> 00:19:52.463
Alors qu'on est demandeur. Je pense qu'on a tous vu des gens avoir des résultats

00:19:52.463 --> 00:19:56.743
au final très bons dans une équipe qui faisait n'importe quoi ou en tout cas

00:19:56.743 --> 00:19:57.743
dont le résultat n'était pas là.

00:19:58.243 --> 00:20:01.203
Je pense que ça m'a toujours choqué cette vision ce qui fait même des fois que

00:20:01.203 --> 00:20:04.103
ça peut arriver à quelque chose où les gens se mettent en avant de manière extrêmement

00:20:04.103 --> 00:20:09.503
forte au-delà même du projet pour que eux, leur visibilité se le soit quand ils sont dans un projet.

00:20:09.503 --> 00:20:12.283
Au lieu de fixer le projet, il vaut mieux avoir une visibilité sur d'autres

00:20:12.283 --> 00:20:15.263
choses plutôt que de vraiment s'attaquer aux vrais problèmes.

00:20:16.326 --> 00:20:21.126
Je ne sais pas, Mathieu ? En tout cas, on sent qu'il l'a écrit avec le cœur

00:20:21.126 --> 00:20:24.206
et qu'il était attaché à ces problématiques-là.

00:20:25.046 --> 00:20:28.506
Non, c'est sûr que c'est un problème. J'espère que ce n'était pas trop abstrait, en tout cas.

00:20:28.846 --> 00:20:32.026
Peut-être un petit peu, pour une première chronique, je pense que ce n'est pas

00:20:32.026 --> 00:20:34.266
forcément très concret. On réécoutera.

00:20:35.626 --> 00:20:38.766
Alors, moi, je vais vous parler de mécanisation contre automatisation.

00:20:39.066 --> 00:20:43.026
C'est un sujet, pour ceux qui me connaissent, que j'ai à cœur depuis un petit moment.

00:20:43.666 --> 00:20:46.386
En fait, dans le cadre de mon expérience, je me suis, enfin,

00:20:46.486 --> 00:20:50.726
je connais très bien le logiciel chef d'automatisation et en fait je me suis

00:20:50.726 --> 00:20:53.566
aperçu très souvent en travaillant aussi bien avec la communauté que dans les

00:20:53.566 --> 00:20:56.986
sociétés où j'étais, que les gens avaient tendance à faire

00:20:57.406 --> 00:21:01.106
comme ils avaient l'habitude de faire à la main c'est-à-dire que si jamais ils

00:21:01.106 --> 00:21:03.426
lançaient la commande CCTL pour aller,

00:21:04.006 --> 00:21:08.286
mettre un paramètre du kernel si jamais ils utilisaient quand ils étaient sur

00:21:08.286 --> 00:21:11.666
un serveur plein de méthodes souvent ils avaient tendance à aller réutiliser

00:21:11.666 --> 00:21:15.506
la même chose dans le logiciel d'automatisation, ça veut dire à exécuter la

00:21:15.506 --> 00:21:17.886
même commande, si c'était elle, avec un execute,

00:21:18.126 --> 00:21:20.106
ça va dépendre de votre logiciel d'automatisation.

00:21:20.786 --> 00:21:24.146
Et donc on s'aperçoit très vite que ça pose des problèmes. Ces commandes-là

00:21:24.146 --> 00:21:28.546
sont rarement immutables, par exemple. Elles peuvent poser des soucis.

00:21:28.986 --> 00:21:32.946
Et en fait, en ayant vu tout ça, parce que c'est vraiment quelque chose qu'on

00:21:32.946 --> 00:21:37.206
voit très souvent, des commandes mises, c'est l'exemple aussi du bash.

00:21:37.366 --> 00:21:41.386
Quand des gens font des scripts bash, c'est vraiment l'exemple de commandes

00:21:41.386 --> 00:21:42.086
qu'on aurait fait à la main.

00:21:42.326 --> 00:21:46.266
On va tweaker quelques petits if, quelques petits for autour et encore quand

00:21:46.266 --> 00:21:49.726
on sait les faire en bâche et au final on arrive à quelque chose qui essaye

00:21:49.726 --> 00:21:52.346
d'arriver à un résultat en tout cas. Mais c'est vraiment les mêmes commandes

00:21:52.346 --> 00:21:52.886
qu'on aurait fait à la main.

00:21:53.586 --> 00:21:57.866
Ce que j'en conclue de ça c'est que vraiment en fait il y a une différence entre

00:21:57.866 --> 00:22:01.646
faire ce qu'on aurait fait à la main la mécanisation, c'est-à-dire vraiment

00:22:01.646 --> 00:22:05.526
avoir un automate qui fait des choses un automate humain comme on le faisait

00:22:05.966 --> 00:22:09.726
avant, donc même pour reprendre l'histoire, les premiers automates c'était par

00:22:09.726 --> 00:22:12.626
exemple des personnes qui jouaient sur des pianos donc c'était des automates

00:22:12.626 --> 00:22:16.006
qui allaient vraiment pianoter sur un piano existant,

00:22:16.006 --> 00:22:21.186
mais qui faisaient exactement toujours la même séquence de manière indifférenciée.

00:22:21.836 --> 00:22:26.636
Et en fait, le problème de ce type de solution, c'est que très vite,

00:22:26.636 --> 00:22:28.296
même dans l'histoire, ça ne se cahit pas.

00:22:28.676 --> 00:22:31.276
Ce qu'on a aperçu au moment de l'industrialisation, par exemple,

00:22:31.336 --> 00:22:35.596
et quand il a fallu produire des voitures en masse, ou vraiment même avoir une

00:22:35.596 --> 00:22:39.736
production en masse de quels que soient les objets, il a fallu repenser entièrement

00:22:39.736 --> 00:22:42.016
la façon dont on faisait les choses.

00:22:42.316 --> 00:22:46.636
L'exemple que je donne souvent, c'est celui des pommes de terre.

00:22:46.756 --> 00:22:50.796
Et comment on fait des frites ? à la main, si vous allez chez votre grand-mère

00:22:50.796 --> 00:22:55.656
le week-end, vous savez qu'elle va éplucher de manière consciencieuse les pommes

00:22:55.656 --> 00:23:01.216
de terre, elle va les couper en lamelles ou en frites,

00:23:01.776 --> 00:23:04.516
les mettre dans une friteuse, les faire cuire, et ça sera très bien.

00:23:05.056 --> 00:23:08.136
Maintenant, pour montrer vraiment la différence, qu'est-ce que ça voudrait dire

00:23:08.136 --> 00:23:11.096
de mécaniser ce processus-là ? Par exemple, ça existe déjà.

00:23:11.176 --> 00:23:16.056
Si jamais vous voulez couper en frites vos patates, il existe des moules que

00:23:16.056 --> 00:23:19.616
vous allez mettre, vous mettez la pomme de terre, vous appuyez très fort et ça vous sort des frites.

00:23:19.956 --> 00:23:22.176
Voilà une mécanisation, un exemple de mécanisation. C'est-à-dire qu'au final,

00:23:22.216 --> 00:23:27.196
c'est la même chose qu'un couteau, c'est juste qu'on l'a fait un peu à la main, un peu mieux.

00:23:27.776 --> 00:23:31.416
Si jamais vous avez envie d'éplucher, il existe des épluches légumes.

00:23:31.436 --> 00:23:34.876
On enfonce le légume ou la pomme de terre dans quelque chose,

00:23:34.896 --> 00:23:36.656
on tourne et il y a une espèce de petit.

00:23:38.676 --> 00:23:42.496
Éplucheur qui vient enlever. Le problème, si vous le voyez très vite,

00:23:42.536 --> 00:23:45.696
c'est comment on fait ça à l'échelle, comment on fait ça vraiment quand on a

00:23:45.696 --> 00:23:46.876
beaucoup de pommes de terre à faire.

00:23:47.116 --> 00:23:50.436
On a des risques que ça ne marche pas, il faut des bras robotiques,

00:23:50.456 --> 00:23:52.696
il y a une compréhension de l'outil qui doit être là.

00:23:53.116 --> 00:23:56.076
Donc en fait, qu'est-ce qu'on fait les ingénieurs pour faire des frites,

00:23:56.096 --> 00:23:58.456
toujours dans mon exemple, pour éplucher ?

00:23:58.979 --> 00:24:02.119
Pour éplucher la pomme de terre. En fait, ce qu'ils vont faire,

00:24:02.199 --> 00:24:04.659
ils vont utiliser le principe que la pomme de terre cuite devient plus molle.

00:24:04.819 --> 00:24:08.679
Donc, il suffit de cuire très vite, très fort, en brûlant un peu la surface

00:24:08.679 --> 00:24:12.359
pour faire en sorte que juste l'épiderme de la pomme de terre soit cuit.

00:24:12.599 --> 00:24:17.799
Après, un soufflet, et la partie dure reste, le cœur de la pomme de terre,

00:24:17.919 --> 00:24:19.899
et la partie molle part, la croûte.

00:24:20.159 --> 00:24:22.559
Tant mieux, on voulait enlever cette partie.

00:24:22.919 --> 00:24:25.559
Après, pour faire des frites, bon, simple, on prend une patate,

00:24:25.599 --> 00:24:28.159
on la lance dans un filet, et puis ça fait des frites.

00:24:28.159 --> 00:24:31.299
Il y a juste un quadrillage, et voilà, on a la sortie on a de jolis frites,

00:24:31.339 --> 00:24:35.199
et enfin pour les cuire, il suffit de mettre les frites pour les cuire le bon

00:24:35.199 --> 00:24:38.179
temps, de les mettre dans un bain d'huile qui reste là, mais les frites elles

00:24:38.179 --> 00:24:39.479
avancent au fur et à mesure, elles,

00:24:40.039 --> 00:24:43.639
arrivent dans le bain d'huile froide et pas cuite, elles sortent à la fin,

00:24:43.739 --> 00:24:47.159
toutes cuites exactement le même temps, parce que toutes les frites sont parties à la même vitesse.

00:24:47.499 --> 00:24:51.979
Voilà par exemple un exemple de vraiment, de repenser le processus dans le cadre.

00:24:52.799 --> 00:24:56.259
Industriel. Appliquer en informatique souvent ça revient à peu près à la même

00:24:56.259 --> 00:24:57.419
chose, des fois c'est repenser.

00:24:57.539 --> 00:25:01.219
Si je donne l'exemple de CCTL tout à l'heure, très souvent exécuter la commande

00:25:01.219 --> 00:25:04.939
CCTL c'est pas forcément un choix judicieux en fonction de la distribution sur

00:25:04.939 --> 00:25:07.519
laquelle vous allez être ou même vraiment, oui, le,

00:25:08.119 --> 00:25:11.239
contexte, la commande CCTL peut ne pas être présente, elle peut aussi avoir

00:25:11.239 --> 00:25:14.099
évolué de version les options que vous allez utiliser ne vont plus être là est-ce

00:25:14.099 --> 00:25:16.159
que vous utilisez les options courtes, les options longues etc.

00:25:16.859 --> 00:25:19.739
Donc souvent il vaut mieux aller directement, se tracasser peut-être un peu

00:25:19.739 --> 00:25:23.259
plus mais aller directement taper dans les appels système qui doivent être faits

00:25:23.259 --> 00:25:27.359
et d'avoir quelque chose qu'on peut programmatiquement simplement faire en allant,

00:25:27.859 --> 00:25:29.199
changer les appels au bon endroit.

00:25:29.339 --> 00:25:32.179
C'est peut-être pas le meilleur exemple si c'était elle, mais la philosophie

00:25:32.179 --> 00:25:35.079
est là, c'est-à-dire que vous pouvez toujours redécouper votre problème d'une

00:25:35.079 --> 00:25:39.519
autre façon pour arriver à quelque chose qui a le but d'être industriel et qui

00:25:39.519 --> 00:25:40.159
va marcher tout le temps.

00:25:40.399 --> 00:25:45.479
C'est le cas de l'échec, c'est-à-dire que vraiment si jamais vous avez 1% de

00:25:45.479 --> 00:25:49.079
chance que ça foire, mis à l'échelle, ce 1% va devenir votre quotidien.

00:25:49.119 --> 00:25:50.979
Le but vraiment, c'est d'aller changer ça.

00:25:51.219 --> 00:25:55.339
C'est là où on passe à l'automatisation, c'est vraiment de vraiment avoir quelque

00:25:55.339 --> 00:25:57.539
chose qui va fonctionner. D'ailleurs, Sous-titrage ST' 501

00:25:57.899 --> 00:26:03.199
Petit aparté, dans le livre SREbook de Google, il y a même cette distinction-là.

00:26:03.299 --> 00:26:05.719
C'est-à-dire qu'en fait, ils ne parlent pas de mécanisation et d'automatisation,

00:26:05.879 --> 00:26:08.739
mais ils vont faire une différence entre automatisation et automatique.

00:26:09.099 --> 00:26:13.239
Le but d'un SRE n'est pas d'automatiser, le but est de rendre le système automatique,

00:26:13.279 --> 00:26:18.059
c'est-à-dire qu'il va réussir à se réparer tout seul, par exemple.

00:26:18.339 --> 00:26:20.339
Ça va être encore ça la distinction qu'on va pouvoir faire. Moi,

00:26:20.399 --> 00:26:23.119
je ne vais pas parler d'automatique, mais de mécanisation versus automatisation.

00:26:23.619 --> 00:26:27.479
Voilà, j'espère que j'ai été assez précis. Tout à fait, très clair.

00:26:27.899 --> 00:26:29.539
Pas de questions autour ?

00:26:58.359 --> 00:27:01.239
Cette composante humaine de l'outil complètement,

00:27:01.699 --> 00:27:06.159
et de faire en sorte que ça soit la machine pour la machine et en cela il faut

00:27:06.159 --> 00:27:10.619
sortir du contexte humain et c'est ce que tu essayes de dire en fait c'est sortir

00:27:10.619 --> 00:27:14.759
l'humain de la machine pour faire en sorte que la machine s'assume On n'est plus d'accord,

00:27:14.959 --> 00:27:17.779
c'est vrai, c'est quelque chose que je n'ai pas abordé mais c'est vrai que souvent

00:27:17.779 --> 00:27:21.339
il est difficile d'appréhender certains problèmes à l'aune de ce qu'on fait

00:27:21.339 --> 00:27:24.039
au quotidien c'est pour ça que par exemple quand on parle d'orchestrateur ou

00:27:24.039 --> 00:27:26.739
de choses comme ça, les opérations faites par un orchestrateur peuvent paraître

00:27:26.739 --> 00:27:27.759
complètement démentielles,

00:27:28.259 --> 00:27:29.899
quand un humain essaie d'y réfléchir.

00:27:29.899 --> 00:27:33.779
C'est-à-dire qu'il faut aller faire énormément de checks, faire des vérifications,

00:27:34.079 --> 00:27:35.919
avoir des implications, etc.

00:27:36.379 --> 00:27:39.719
En plus, la plupart des checks vont être valides. C'est-à-dire qu'un humain

00:27:39.719 --> 00:27:41.839
ne les ferait pas parce qu'il sait que ça va marcher.

00:27:42.179 --> 00:27:46.659
Quand on parle d'un ordinateur, et là, dans l'automatisation,

00:27:46.879 --> 00:27:50.259
il va y avoir énormément d'actions qui vont être du bruit, de l'action qui n'a

00:27:50.259 --> 00:27:54.259
pas de but, qui n'a pas de sens, mais elle n'est pas grave dans le cadre d'une...

00:27:55.469 --> 00:27:58.689
D'un ordinateur. Et c'est là vraiment où il faut repenser les choses et arrêter

00:27:58.689 --> 00:28:02.349
de penser, comme tu le disais, à l'outil et à cette chose liée à l'humain,

00:28:02.369 --> 00:28:04.169
mais repenser ça de manière très différente.

00:28:04.669 --> 00:28:07.729
Je suis vraiment très d'accord. Est-ce que ce ne serait pas lié à des questions

00:28:07.729 --> 00:28:13.829
de biais, que l'humain est biaisé de nombreuses manières et que l'ordinateur ne l'est pas,

00:28:13.929 --> 00:28:17.989
et donc du coup faire confiance à l'ordinateur pour qu'il fasse ce qu'il doit

00:28:17.989 --> 00:28:20.069
faire de la manière dont on lui a dit de le faire,

00:28:20.209 --> 00:28:24.849
du coup de ne pas avoir d'idées préconçues, d'historique et d'inertie dans la

00:28:24.849 --> 00:28:29.369
réflexion, mais vraiment qu'il se concentre vraiment sur un script à exécuter,

00:28:29.409 --> 00:28:32.069
sur une liste de tâches, et vraiment,

00:28:32.209 --> 00:28:35.209
désolé je ne sais pas comment finir cette question. Non, mais ça en fait partie, en effet.

00:28:35.329 --> 00:28:38.469
C'est quelque chose, notamment quand on déploie des logiciels qui peuvent être assez compliqués.

00:28:38.689 --> 00:28:43.629
On a des fois ce biais-là, où pour déployer des clés, par exemple, de sécurité,

00:28:43.769 --> 00:28:47.209
c'est toujours problématique quand on essaie de faire les choses qu'on aurait

00:28:47.209 --> 00:28:50.529
fait à la main en utilisant les mêmes outils, parce que quand on est un humain,

00:28:50.589 --> 00:28:53.569
il y a plein d'implications qu'on arrive à comprendre immédiatement et qu'une

00:28:53.569 --> 00:28:57.789
machine automatique type chef ou un orchestrateur quelconque ne peut pas faire.

00:28:58.009 --> 00:29:00.949
Et donc, souvent, il faut repenser le problème, décentraliser les clés,

00:29:00.969 --> 00:29:03.889
avoir un autre outil, créer des outils, en fait. Et c'est là où d'un coup on

00:29:03.889 --> 00:29:08.189
arrive dans le DevOps et dans la partie où des fois il faut créer des outils pour permettre ça.

00:29:08.269 --> 00:29:11.969
Un exemple que je vais te donner, par exemple, dans une de mes précédentes sociétés,

00:29:11.969 --> 00:29:16.309
on avait le souci de configurer le réseau sur des machines qu'on envoyait chez les clients.

00:29:16.549 --> 00:29:19.209
La configuration se faisait dans une interface web codée en Django.

00:29:20.069 --> 00:29:23.029
Le problème, c'est que les machines étaient du Debian, un développeur,

00:29:23.029 --> 00:29:26.029
pour mettre du réseau, qu'est-ce qu'il fait ? Il va toucher dans ETC Network Interfaces.

00:29:26.832 --> 00:29:31.832
Et il met les configurations et il fait un joli networking restart.

00:29:32.312 --> 00:29:34.952
Dans le cadre du quelque chose d'automatique, qu'est-ce que ça implique ?

00:29:34.952 --> 00:29:37.132
Ça implique énormément de choses, c'est-à-dire déjà Django doit tourner en route

00:29:37.132 --> 00:29:39.532
pour pouvoir aller modifier ses network interfaces.

00:29:40.232 --> 00:29:44.912
En plus, derrière, ça a configuré vraiment le réseau. Le réseau,

00:29:44.932 --> 00:29:45.912
c'est vraiment quelque chose de très compliqué.

00:29:46.172 --> 00:29:48.632
Faire de manière basique, ça va, mais quand il commence à y avoir plusieurs

00:29:48.632 --> 00:29:52.912
interfaces, etc., le network interface c'est vraiment une interface de gestion

00:29:52.912 --> 00:29:55.752
du réseau qui est vraiment basique, humainement très compréhensible,

00:29:55.752 --> 00:29:58.992
mais pour une machine, déjà il y a un niveau d'abstraction en script bash,

00:29:59.152 --> 00:30:00.672
perl, etc qui est vraiment très fort.

00:30:01.152 --> 00:30:05.832
En fait au final ce que j'ai fait, c'est que j'ai créé un petit blob qui écoutait sur un,

00:30:06.432 --> 00:30:09.972
socket Unix donc ça veut dire que la communication pouvait se faire en HTTP

00:30:09.972 --> 00:30:15.532
REST mais liée à la machine avec les droits qui vont bien le blob lui était

00:30:15.532 --> 00:30:18.652
root pouvait faire des opérations réseau,

00:30:18.652 --> 00:30:21.672
mais surtout il n'allait pas toucher à OTC Network Services mais il allait directement

00:30:21.672 --> 00:30:27.172
aller à PlanetLink et aller taper dans la librairie réseau de Linux et directement faire les actions,

00:30:27.272 --> 00:30:30.532
au lieu de passer par Yet Another Abstraction qui est faite pour un être humain.

00:30:31.392 --> 00:30:36.272
Voilà. On va passer à la suite. Une dernière petite remarque parce qu'il a quand

00:30:36.272 --> 00:30:38.452
même soulevé la question des algorithmes.

00:30:38.612 --> 00:30:40.812
En gros, il faut faire attention.

00:30:41.252 --> 00:30:44.012
Aujourd'hui, on parle de technique pour la technique, pour l'infrastructure

00:30:44.012 --> 00:30:47.172
ou du développement, mais se faire diriger par des algorithmes,

00:30:47.192 --> 00:30:50.732
ça soulève de nouvelles questions qui pourront être abordées,

00:30:50.752 --> 00:30:52.292
je pense, dans d'autres techniques.

00:30:53.452 --> 00:30:58.392
Donc, c'est juste, il y a un petit warning. Attention à l'algorithme qui gouverne

00:30:58.392 --> 00:31:01.672
et qui prend des choix à notre place, tout simplement.

00:31:02.338 --> 00:31:08.718
Bon, Barc est anti-Google Home, alors on va finir les chroniques avec les armes du DevOps.

00:31:09.238 --> 00:31:14.258
Alors, en effet, pour ce numéro d'ouverture, je vous propose d'aborder un sujet

00:31:14.258 --> 00:31:18.558
léger, fort sympathique qui a été teasé de multiples reprises juste avant.

00:31:18.938 --> 00:31:24.078
C'est donc une chronique qui vous parlera d'armes, de conflits et plus généralement

00:31:24.078 --> 00:31:29.218
de résistance. Car oui, notre activité quotidienne dans l'Haïti est riche de

00:31:29.218 --> 00:31:33.518
passions, de batailles, voire parfois de petites luttes clandestines.

00:31:33.738 --> 00:31:36.838
Et si de temps en temps ces passes d'armes nous échappent ou si nous les fuyons

00:31:36.838 --> 00:31:41.278
telles des anguilles, elles forment malgré tout la richesse et le sel de nos journées.

00:31:41.778 --> 00:31:44.918
Il y a des regards qui s'échangent, qu'est-ce qu'il est en train de dire ?

00:31:45.518 --> 00:31:49.238
Dans ces situations, les plus conciliants chercheront le compromis avant tout,

00:31:49.338 --> 00:31:53.518
alors que d'autres iront lutter pour leurs idées et accuseront les coups jusqu'à en jeter l'éponge.

00:31:53.518 --> 00:32:03.478
On voit même les plus téméraires d'entre nous, à m'en donner tout espoir et

00:32:03.478 --> 00:32:05.598
déserter pour de meilleurs horizons.

00:32:05.898 --> 00:32:09.698
C'est donc au travers de cette thématique que je voulais vous parler de nous,

00:32:09.758 --> 00:32:13.798
du DevOps, et de ce que peut nous offrir en pratique ce modèle de collaboration

00:32:13.798 --> 00:32:17.598
face à des cas tendus. Attention.

00:32:18.638 --> 00:32:21.738
Chante déesse la colère d'Achille, fils de Pellé.

00:32:22.418 --> 00:32:26.698
Détestable colère qui, aux Achaéens, valut des souffrances sans nombre.

00:32:27.378 --> 00:32:32.718
L'Iliade d'Homère, dès ses premiers vers, place la colère au centre de son propos.

00:32:33.178 --> 00:32:36.478
Ce n'est pas un hasard si les philosophes se sont très tôt intéressés à cette

00:32:36.478 --> 00:32:39.198
émotion, car il s'agit bien d'un trait humain ancestral.

00:32:39.878 --> 00:32:43.338
Et pour le résumer grossièrement, il fallait, selon ces mêmes penseurs,

00:32:43.418 --> 00:32:47.838
la dompter, l'apprivoiser, la bannir, ou simplement, par sagesse, l'éviter.

00:32:48.654 --> 00:32:51.814
On peut très simplement retrouver ce même thème dans nos mythes modernes.

00:32:51.814 --> 00:32:56.994
Par exemple, dans l'illustre saga Star Wars, c'est bien la colère qui mène au côté obscur.

00:32:57.154 --> 00:33:04.154
Elle permet alors l'accès à une puissance immense, mais tout autant corruptrice et destructrice.

00:33:04.494 --> 00:33:08.214
Dans le comics américain Hulk, c'est également le déclencheur de la transformation

00:33:08.214 --> 00:33:10.394
d'un homme en colosse herculéen.

00:33:10.654 --> 00:33:14.894
Ces légendes populaires n'ont donc jamais cessé d'illustrer cette tempête qui

00:33:14.894 --> 00:33:16.934
anime nos cœurs et nos actes.

00:33:17.514 --> 00:33:22.254
Symbole de l'affirmation de soi, processus de défense ou encore marqueur d'une

00:33:22.254 --> 00:33:29.574
volonté altruiste, on ne peut nier que la colère est un moteur ou un vice universel.

00:33:30.314 --> 00:33:34.314
Et c'est bien ce processus qui nous motive au quotidien. La rage de voir se

00:33:34.314 --> 00:33:35.494
répéter les mêmes problèmes.

00:33:36.354 --> 00:33:39.934
La colère d'entendre proposer des solutions identiques pour tous les besoins,

00:33:40.034 --> 00:33:44.594
le désespoir de voir les équipes produits se défausser de leurs responsabilités

00:33:44.594 --> 00:33:46.654
via d'habiles manœuvres d'évitement,

00:33:47.254 --> 00:33:52.914
ou enfin la déception de subir le maintien de force des modes de fonctionnement du passé.

00:33:53.594 --> 00:33:57.554
Je pense qu'on a chacun pu assister au désamorçage de tentatives de changement

00:33:57.554 --> 00:34:01.874
ou de projets jugés trop disruptifs lors de nos carrières.

00:34:02.874 --> 00:34:08.014
Fondémoinant. Il s'agit donc dans des moments comme ceux-là de répondre en bon DevOps.

00:34:08.374 --> 00:34:12.214
Avant même d'aller plus loin, il faut être conscient que la chose la plus simple

00:34:12.214 --> 00:34:16.634
au quotidien et d'opérer un changement des esprits et gagner la bataille de la culture.

00:34:17.754 --> 00:34:23.154
Le réflexe est simple. Il s'agit d'être inclusif. On l'a répété au cours de cette émission.

00:34:23.794 --> 00:34:28.874
De donner une confiance absolue à ses collaborateurs et de corriger systématiquement

00:34:28.874 --> 00:34:32.654
les marqueurs de dédain ou de supériorité que l'on entend souvent au quotidien.

00:34:33.014 --> 00:34:36.634
Il faut donc se placer du côté du bien, celui de l'indiscutable.

00:34:37.054 --> 00:34:41.554
Cesser d'opposer les « eux » au « nous ». et par cela infuser les idées DevOps

00:34:41.554 --> 00:34:43.954
au sein même des esprits de votre entourage.

00:34:45.054 --> 00:34:50.694
Confucius lui-même écrivait « Si j'avais le pouvoir, je commencerais par donner du sens aux mots.

00:34:50.814 --> 00:34:56.134
» Et c'est en cela que se battre sur le terrain du langage va permettre de donner

00:34:56.134 --> 00:35:03.214
corps aux problèmes sous-jacents, de les identifier et de mettre au clair les

00:35:03.214 --> 00:35:05.394
non-dits qui polluent les projets et les relations.

00:35:05.394 --> 00:35:09.854
C'est en mettant les équipes en défaut face au concept DevOps et en se plaçant

00:35:09.854 --> 00:35:14.254
comme héros de la collaboration que vous pourrez aller plus loin dans ces concepts.

00:35:15.094 --> 00:35:18.294
Par la même occasion, il vous sera possible d'identifier les conservateurs acharnés

00:35:18.294 --> 00:35:23.354
qui barreront la route à toute évolution, les sortant alors de leur zone de confort.

00:35:23.794 --> 00:35:27.114
C'est donc ici une guerre psychologique, une guerre des mots,

00:35:27.194 --> 00:35:31.734
celle qui oriente les esprits par le martèlement des mêmes vérités pour,

00:35:31.874 --> 00:35:35.574
au final, transmettre aux gens le réflexe et la logique des votes.

00:35:36.826 --> 00:35:40.086
Je crois qu'on me fait signe de l'autre côté de la table. Tout cela,

00:35:40.166 --> 00:35:42.306
c'est bien beau, mais je suis censé être DevOps.

00:35:42.646 --> 00:35:45.686
J'ai l'impression d'être toujours coincé dans un gros silo. Donc,

00:35:45.706 --> 00:35:49.546
même en changeant les mots, ma structure n'accorde visiblement pas de place au DevOps.

00:35:50.286 --> 00:35:51.886
Qu'est-ce que je fais ici ?

00:35:53.186 --> 00:35:56.886
Bien, disons-le une bonne fois pour toutes, vous êtes une victime du DevOps

00:35:56.886 --> 00:36:00.566
bashing. DevOps washing, sorry, pour mon anglais.

00:36:01.066 --> 00:36:05.046
Et ce, comme beaucoup d'autres. C'est peut-être le contre-coup d'une direction

00:36:05.046 --> 00:36:08.346
ou d'une politique managériale qui ne sait absolument pas comment amorcer un

00:36:08.346 --> 00:36:11.686
changement et qui se rassure avec des modèles connus.

00:36:12.026 --> 00:36:15.786
D'une entreprise qui veut rester dans l'air du temps sans connaître le modèle à suivre.

00:36:16.306 --> 00:36:19.926
Peut-être même s'agit-il simplement d'une question de recrutement ou est-ce

00:36:19.926 --> 00:36:22.946
encore la résultante d'une transformation échouée, que sais-je.

00:36:23.146 --> 00:36:27.886
Là n'est pas la question. L'important à retenir ici, c'est que tout n'est pas

00:36:27.886 --> 00:36:30.766
perdu. Vous avez le principal, le titre DevOps.

00:36:31.406 --> 00:36:36.186
Vous pouvez dès à présent prendre ce badge qui vous est dû, l'accrocher à votre

00:36:36.186 --> 00:36:38.706
t-shirt Docker préféré et foncer.

00:36:39.146 --> 00:36:43.466
Quand on se sait dans son droit, on entre plus facilement en résistance et cela

00:36:43.466 --> 00:36:45.586
donne à ses propos un écho supplémentaire.

00:36:46.066 --> 00:36:50.046
Grâce à cela, il est légitime d'aller voir, seul s'il le faut,

00:36:50.206 --> 00:36:54.846
les équipes clients, s'intégrer, voire même s'immerger dans leur univers.

00:36:55.246 --> 00:37:00.006
Faire partie de leur quotidien pour capter leurs besoins avant même leur formalisation concrète.

00:37:00.966 --> 00:37:05.186
Logiquement, vous devrez délaisser quelques précédentes tâches et en cela vous

00:37:05.186 --> 00:37:06.566
serez peut-être coupable.

00:37:06.726 --> 00:37:12.586
Mais rappelez-vous que votre ligne défensive est le DevOps et qu'il ne vous

00:37:12.586 --> 00:37:14.366
est pas opposable en l'état.

00:37:15.346 --> 00:37:19.606
Finalement, vos meilleures armes seront vos résultats. Vous pourrez facilement

00:37:19.606 --> 00:37:22.966
mettre en avant le bien fondé de cette démarche, la valeur ajoutée pour votre produit.

00:37:23.266 --> 00:37:27.046
L'identification, la classification des nouveaux besoins émergents.

00:37:27.166 --> 00:37:31.886
Plus que tout, vous pourrez également ériger la collaboration et la confiance

00:37:31.886 --> 00:37:34.366
mutuelle en tant que valeur fondamentale.

00:37:34.866 --> 00:37:39.386
Enfin, vous brandirez fièrement la satisfaction et la confiance de vos utilisateurs.

00:37:40.246 --> 00:37:43.406
La rapidité de mise en place des changements, des tests, des facultés nouvelles

00:37:43.406 --> 00:37:45.526
de déploiement seront vos étendards.

00:37:45.766 --> 00:37:49.826
En mesurant et comparant factuellement l'évolution de chacun de ces points,

00:37:49.826 --> 00:37:55.226
vous achèverez simplement vos détracteurs, souvent armés de mauvaise foi ou d'a priori.

00:37:56.066 --> 00:37:59.806
Alors, certes, ce n'est pas simple. Pour toujours aller vers le mieux,

00:37:59.846 --> 00:38:03.606
le plus adapté, il faudra jongler avec les contraintes des différents intervenants,

00:38:04.266 --> 00:38:07.006
parfois se conformer à des process issus d'un autre temps.

00:38:07.486 --> 00:38:11.586
Mais dites-vous que si le bilan n'est pas concluant sur le plan professionnel,

00:38:11.726 --> 00:38:16.046
il vous restera au moins la satisfaction d'avoir personnellement avancé et de

00:38:16.046 --> 00:38:18.006
vous être engagé sur un modèle que vous savez juste.

00:38:18.466 --> 00:38:20.766
Après tout, La force est avec vous.

00:38:21.603 --> 00:38:25.903
Je pense qu'on peut rajouter des applaudissements. C'est beau. C'est très beau.

00:38:26.723 --> 00:38:31.363
Vous pouvez discuter. C'est un petit peu long, j'admets. Non, non, vraiment bien.

00:38:32.263 --> 00:38:35.083
Moi, il y a juste quelque chose. Je vais rebondir sur ce que tu as dit.

00:38:35.343 --> 00:38:38.563
Ce n'est pas la colère qui mène à la souffrance, c'est la peur. C'est la peur.

00:38:38.743 --> 00:38:41.223
C'est la peur. Et je pense que ça, c'est aussi quelque chose qu'on peut rajouter.

00:38:41.323 --> 00:38:46.803
Il y a aussi ce côté peur chez les autres, même chez tous, qui existe. La peur du changement.

00:38:47.103 --> 00:38:50.643
La peur du changement, la peur de perdre sa place, la peur de plein de choses,

00:38:50.723 --> 00:38:53.623
en fait. Tout simplement, c'est le changement qui n'a pas forcément le bon sens.

00:38:53.903 --> 00:38:57.163
C'est la peur qui mène à la colère. Tout à fait.

00:38:58.303 --> 00:38:59.643
Je ne sais pas si vous avez...

00:39:00.843 --> 00:39:06.083
Vas-y, vas-y. J'avais une remarque. Est-ce que tu dis, il faut, en gros...

00:39:06.643 --> 00:39:12.283
En tout cas, est-ce que tu as quelques conseils à donner pour réussir à convaincre

00:39:12.283 --> 00:39:17.703
le management qui pourrait opposer de la résistance au changement ?

00:39:17.703 --> 00:39:22.203
Les conseils de... peut-être pas d'Aristote ou de ma grand-mère.

00:39:22.343 --> 00:39:24.763
C'est toujours compliqué de donner des conseils universels, mais est-ce que

00:39:24.763 --> 00:39:29.203
tu aurais quelques tips ? Des quick wins ? Des quick wins, peut-être.

00:39:29.483 --> 00:39:33.283
C'est difficile. C'est très difficile si vous n'avez pas un management,

00:39:33.623 --> 00:39:37.043
alors que ce soit un management de la direction ou un management de proximité

00:39:37.043 --> 00:39:41.303
qui vous est favorable, vous partez avec un énorme malus.

00:39:41.403 --> 00:39:46.323
Vous le savez, vous allez évoluer avec cet énorme malus.

00:39:46.643 --> 00:39:49.903
En revanche, vous allez pouvoir, comment dire, lancer un mouvement,

00:39:50.103 --> 00:39:55.123
éventuellement rassembler des gens autour de vous et essayer de donner des exemples,

00:39:55.743 --> 00:39:59.943
pas des quick wins, mais des win stories, je ne sais pas comment on pourrait dire ça,

00:40:00.683 --> 00:40:05.643
mais des cas d'usage où vous avez appliqué certaines choses,

00:40:05.783 --> 00:40:10.643
vous êtes allé voir les gens, vous avez outrepassé certains process pour appliquer,

00:40:10.663 --> 00:40:14.283
je ne sais pas, pour nous, un processus de déploiement nouveau ?

00:40:15.455 --> 00:40:22.075
Et ça a marché. Vous avez aidé les gens et vous êtes allé vite parce que c'est ça qui compte.

00:40:22.375 --> 00:40:26.115
A partir de là, vous avez coché une grande majorité des cases DevOps.

00:40:27.455 --> 00:40:35.155
Après, s'il n'y a aucune réception à ces points bonus, il y a d'autres solutions.

00:40:35.375 --> 00:40:38.475
Il y a d'autres solutions. Par exemple, appliquer la loi des deux pieds. C'est ça.

00:40:39.155 --> 00:40:41.275
C'est-à-dire, si ça ne vous plaît pas, si vous n'apprenez rien,

00:40:41.535 --> 00:40:43.435
barrez-vous. Comme je l'ai dit tout à l'heure en actu,

00:40:43.535 --> 00:40:46.455
je vous rappelle que beaucoup de sociétés très intéressantes commencent à venir

00:40:46.455 --> 00:40:49.735
à Paris et vous recherchent et si jamais vous avez ces sociétés-là à Paris ou

00:40:49.735 --> 00:40:51.355
d'autres réglementations et même à

00:40:51.355 --> 00:40:54.795
d'autres réglementations et même à l'international si vous parlez étranger,

00:40:55.315 --> 00:40:59.535
voilà l'étranger l'étranger l'étranger l'étranger bien.

00:41:00.895 --> 00:41:04.975
Mais non très instructif c'est pas marre que c'était non j'ai pas grand chose

00:41:04.975 --> 00:41:08.835
à ajouter je pense que tout a été dit je pense que tout a été dit donc je vais

00:41:08.835 --> 00:41:10.515
d'abord remercier tous les participants

00:41:10.515 --> 00:41:14.095
ce soir pour leur travail leur intervention et leur motivation.

00:41:14.695 --> 00:41:19.155
Et puis, on va vous laisser là-dessus. J'espère déjà que ça vous a plu,

00:41:19.255 --> 00:41:23.035
que vous nous ferez des retours aussi bien en live, en meet-up,

00:41:24.015 --> 00:41:25.975
sur Internet, les endroits où vous les écouterez.

00:41:26.055 --> 00:41:31.075
On espère avoir vos commentaires parce qu'on est aussi agiles là-dessus et qu'on

00:41:31.075 --> 00:41:33.255
va aussi adapter en fonction de tous les retours.

00:41:33.575 --> 00:41:37.095
Donc, merci à vous aussi d'avoir écouté et on vous dit au revoir.

00:41:37.175 --> 00:41:39.375
À la prochaine surtout. Au revoir. À la prochaine.