Dev Ops Le magazine et observatoire du Dev Ops
Bonjour à tous et bienvenue dans le cinquième numéro de Dev Ops. Alors, nouvelle année,
qui dit nouvelle année, mais les vœux, de bonne année, donc en 2018, personnellement,
je lui souhaitais avant tout du bonheur, d'être en bonne santé et capable de faire ce qui est
important pour vous. Mais ce bonhonneur égoïste n'est rien sans empathie et bienveillance. Non,
pas ces valeurs que l'on affiche dans un classement best place to work, mais celle que l'on
porte profondément en soi. Je souhaite d'être ouvert, indulgent et compréhensif. Je vous souhaite
également du courage pour aller hors des sentiers battus, vous tromper et vous relever, mais également
réaliser tout ce que vous avez eu peur de faire les précédentes années. Ce ne sont pas de belles
résolutions, vides oubliés, c'est ce que nous essaierons de faire ensemble toute cette année.
N'oubliez pas, ici, personne n'attend. Nous essayons juste de faire ce qui est le mieux. Si nous nous
en gueulons, et cela va arriver, c'est toujours à cause d'expériences différentes, toujours
profitables. Dès aujourd'hui, j'aimerais aussi que l'on fixe des valeurs qui nous gouvernent.
Liberté de parole et d'avis, égalité d'écouter de débats, fraternité d'une communauté qui
sera plus forte ensemble et ouverte sur les autres. Maintenant, dans un registre plus
terre-à-terre, je souhaiterais attirer votre attention. Nous avons besoin d'intervenants pour avoir
du contenu toujours plus plaisant. Nous avons également besoin de lieux libres pour que l'on
puisse attirer encore plus de monde. Nous avons créé le groupe Meetup.com, comme nous l'avons
annoncé le DevOps dernier. N'hésitez pas à intervenir dessus, à proposer un lieu,
votre expérience, une date ou des suggestions. Maintenant, nous allons entrer dans le lit du
sujet avec nos intervenants. A ma gauche, nous avons Guy Tant.
Guy Tant, bonjour. Architecte, tu viens ?
Architecte des systèmes d'information pour ceux qui se demandent ce que je fais et pourquoi
je vais intervenir ici. Jantiment invité par Guilhem pour participer à leur débat,
en apportant pas à la touche DevOps parce que je ne me prétendrais jamais d'Evops,
mais mon côté touche à toux qui m'a fait devenir architecte des systèmes d'information,
donc qui a la fois la vision technique, mais aussi des fois la vision objective d'entreprise
et alignement des différents. Pour le reste, pour le Sondera, pour la suite.
Voilà, si tu veux. Après, nous avons Bartelémique, vous connaissez ?
Voilà, Bartelémique, toujours ici. Bon, cette fois-ci, j'ai une petite rubrique un peu technique
pour parler des API REST, donc ça va être sympa. Rester, venez nous écouter.
Bon, la partie technique. Après, nous avons De Nouveau encore, mais là, beaucoup de Nouveau à cette table.
Donc, nous avons Félix qui est un mignon.
Ouais, donc bonjour Félix. En ce moment, je suis SRE chez le Bancoing, donc 6 années,
je suis une ingloricier et voilà, ça fait 4-5 ans que je fais ça maintenant.
Mais dis-moi, t'aurais pas déjà interviewé dans un précédent numéro ?
Je pense que c'était quelqu'un d'autre sous un pionnolime.
Ah, c'est ma faute.
Vous pourrez voir, c'était le numéro hors série, vous pouvez voir, c'est la dernière intervention.
Et enfin, encore un nouveau, Mathieu.
Salut. Mathieu, et moi, je suis ingénieur SDN chez Claude Watt, donc du réseau,
comment on automatise tout ça et comment on fait en sorte que ça roule.

Voilà.
Donc, alors aujourd'hui, on va essayer d'encore avoir un nouveau concept d'émission.
Donc, d'abord, on va pouvoir avoir toujours la rubrique classique, c'est quoi le DevOps ?
Après, on va pouvoir parler de la gouvernance IT avec Gaëtan et on pourra réagir tous ensemble.
Et après, donc, Bart vous l'a dit, ça chronique, mais également quelques news dont on va pouvoir
parler, offrir un mesure et réagir autour.
Donc, on va commencer avec toi Gaëtan.
C'est quoi le DevOps pour toi ?
DevOps pour moi.
Bon, j'ai travaillé avec toi, donc j'ai été un peu infusé par tes pensées hautes,
mais qui rejoignaient l'argent dans les mêmes.
Pour moi, DevOps, c'est un peu comme toute chose, on va dire, dans l'IT, style, tout
ce qui est métalologie, il y a tout.
C'est avant tout une philosophie et des grandes idées qui après sont, on va dire, appliquées
à des postes particuliers.
En l'occurrence, pour DevOps, j'irai pas faire la fronde de séparer le mot en deux pour
dire, oui, il y a des devs et des hops, mais c'est quand même la base, mais c'est surtout
pour dire que les gens doivent travailler ensemble, couper les espèces de silos dans
lequel on existe tous et arriver à faire en reçois justement que, alors là, c'est
pour boucler un peu avec la gouvernance IT.
Le but quand même des différentes équipes, c'est de tenir un objectif.
Et après, quand même, le but de l'informatique, c'est d'avoir un outil qui permet de faire
les choses simplement et dans le but de l'objectif, pas juste de faire de la technique pour la
technique et de se dire, wow, c'est magnifique, on a fait de la super technique, mais ça
sert à rien.
Pour moi, la philosophie des hops, c'est vraiment industrialisé, automatisé, faire
en sorte que finalement, ça soit fruit des différentes équipes.
Et les DevOps sont entre eux, justement, ces personnes qui sont interfaces, entre
les purs devs qui eux, on va dire, sont dans leur membre de bisous nos tous-tits les
beaux, tous-tits les magiques, tout-tits les parfaits et cool, on utilise la dernière
livre.
Le monde des six admins qui eux, on débase, on va dire, des fondations techniques à mettre
en place et à consolider.
Puis il y a un moment, il faut quand même arriver avec les deux causes et que les deux
causent bien et rapidement parce que c'est cool d'avoir des super technos, mais si tu
mets deux ans à les mettre en prod, bah c'est plus de la super technique.
Donc pour moi, le DevOps, justement, c'est cette partie de travailler ensemble, d'industrialiser
ensemble et de faire le seul plus fruit possible en ayant en plus la gestion de risque parce
que l'avantage c'est que quand tout le monde travaille ensemble, bah s'il y a un truc
qui pète, bah généralement, ça se répare beaucoup plus vite.
D'accord.
Bon, c'était très très large, peut être d'accord ou pas, on verra par la suite.
Et justement, on va aborder le sujet de la gouvernance parce que c'est quelque chose
même dont on avait déjà parlé même entre nous, on avait parlé, il t-il, même dans
un précédent numéro quand on est parlé de la ISELE ?
Moi, j'aimerais donc avoir ton avis parce que la gouvernance est un espèce de gros
mot même parfois quand on parle DevOps.
J'aimerais donc avoir selon toi, ta vision de la gouvernance et comment...
Donc sans parler DevOps, purement la gouvernance, qu'est-ce que ça a comme définition pour
toi pour l'instant ? Et après, on rentrera plus en détail.
Pour moi, la définition de gouvernance, en fait, c'est vraiment le côté...
L'entreprise a des objectifs, le SI doit répondre à ses objectifs et c'est ça la
gouvernance, c'est de se dire au sec le système d'information doit aller pour couvrir
les objectifs de l'entreprise.
Et quand on se dit l'objectif, ce n'est pas des objectifs techniques, c'est des
objectifs de résultats, des objectifs d'évolution.
Typiquement, je prends un exemple un peu bateau, mais une entreprise qui voudrait s'ouvrir
à l'international, son SI, elle sait qu'elle va devoir l'ouvrir à l'international et
on connaît tous les contraintes d'internationalisation, que ce soit sur la gestion des langues, des
caractères à la noice, il le ruise, le chinois et autres, etc.
Et c'est des détails ou même simplement les fuseaux horaires.
Là où on va dire que quand on est dans des sociétés franco-francaise, on va avoir
des systèmes qui généralement sont à l'heure de Paris.
Quand tu commences à travailler avec les US ou la Chine, tu te rends compte que ton UTC
c'est une amie et que tu ne peux pas tout faire en mode n'importe quoi.
Donc la gouvernance, c'est vraiment...
Souvent, on entend parler de schéma directeur informatique, c'est un peu aussi un mot qui
fait part à tout le monde et autres.
Fort que le schéma directeur, c'est l'objectif sur 3 à 5 ans du système informatique de
l'entreprise avec des points de passage.
Après, sur son schéma directeur, c'est un peu une discussion qu'on avait en rough
avant, c'est que tu as peut-être des urgences à chérer, tu as peut-être un super produit
à lancer qui n'était pas prévu, il faut arriver à le gérer là-dedans.
Et c'est là aussi que la gouvernance est importante parce que la gouvernance donne
un cadre, mais elle doit aussi s'adapter au quotidien.
C'est-à-dire, typiquement, dans un dépan qu'on a reboardera certainement tout à l'heure
du belledome ou du spectre.
Normalement, dans un schéma directeur, la gestion de ce type d'incident qui peut se
produire, elle a été planifiée.
On sait comment déclencher la communication, on sait qui déclencher à quel moment et comment
faire.
On ne sait pas quelle est la cause nécessairement du problème, on ne sait pas combien de temps
il va passer à être résolu, mais on sait comment on doit y aller.
Ça donne un cadre.
Après, c'est de la spécifique, c'est quels sont les bonnes personnes, les bons interlocuteurs,
mais là, j'ai envie de dire, c'est plus au niveau de la gouvernance, c'est au niveau
finalement de la DSI ou de la gestion de la DSI.
C'est pour ça que le mot gouvernance fait souvent peur en disant « c'est très
obscure ».
C'est vrai que souvent, les gens opposent gouvernance et agilité, ce qui n'est pas
franchement le même domaine.
En grosso modo, la gouvernance, si tu parlais dans tes vœux de mots « bullshit », « mal
utilisé », etc., s'il est bienveillant, c'est autre.
La gouvernance, elle va donner ces mots-là finalement.
Mais après, la réalisation, c'est bien les équipes techniques et les fonctionnels
qui l'agissent et qui l'adaptent.
Le lien avec par exemple l'architecteur, parce que là, tu as parlé de chez ma directeur,
des choses comme ça.
Ça va être quoi ? Ce lien entre des architectes qu'on peut avoir, qui sont beaucoup plus
pour le coup techniques.
Comment ça va s'interfacer avec eux en termes de purement de logiciels ?
Déjà, architecte informatique, c'est un peu un mot « bullshit » en français qui
est beaucoup mieux traduit en anglais parce qu'il existe sous ces différentes déclinaisons,
parce que tu as l'architecte d'entreprise qui lui va vraiment avoir la liaison entre
le besoin fonctionnel dans l'entreprise et l'IT.
Après, tu as l'architecte technique qui lui va plus assurer la cohérence technique
des briques logiciels.
Tu as l'architecte fonctionnel.
Alors lui, ça dépend comment il est défini, mais généralement, c'est la personne qui
gère les produits, comme on entend au sens produit, cartographie, produit, qui portent
des besoins au métier, qui portent des OKR, qui portent tout un tas de trucs, on va dire,
très non IT, qui est vraiment dans la gouvernance pour le coup, mais même pas dans la gouvernance
ici, mais dans la gouverse globale de l'entreprise.
Combien te coûte une brique ?
Et cette chose-là, et donc sur ces différents niveaux d'architectes, en fait, c'est là
où on voit les différents métiers.
C'est que l'architecte d'entreprise, lui, il doit avoir vraiment la conduite globale
par rapport au schéma directeur.
Il sait où on va.
Il doit pouvoir faire des choix sur, on va prioritiser tel développement, tel brique
pour avoir ses socles et bâtir dessus ou se dire, ben là, on fait du jetable, on va
sortir un truc rapidement, mais on sait que dans un an, on est publié.
Mais en faisant ça, il a la gestion du coup et du risque, parce que c'est ce qu'on lui
demande.
Là où l'architecte technique, lui, il doit plus avoir la vision, on va dire, cadrage
à la fois des DevOps, à la fois des Devs pour assurer la cohérence du S.I.
et répondre aux besoins d'évolution du S.I.
Parce que c'est le grand risque quand on oppose, on va dire, la pure technique à
la gouvernance de l'entreprise, c'est que l'entreprise a peut-être des visions fonctionnelles
ou certes, elle a du one shot sur certains sujets, mais elle a une vision très long-termiste
quant à des investissements, ils sont calculés sur 3 ans, sur 5 ans, etc.
Alors que quand même dans l'informatique, on peut quand même dire qu'on a une fâcheuse
tendance à faire du long terme en informatique, vous allez le donner à combien ? 6 mois ?
Parce qu'on ne sait pas ce qui va sortir dans les 6 mois.
Ça dépend, long terme logiciel, si moi ça peut déjà paraître long.
En infrastructure, ça sera beaucoup plus long,
et en infrastructure, tu vas la monter pour 3 ans de base quasiment sur le contrat,
quand on a des licences.
Après ça dépend si tu parles de réalisation ou de conception ?
C'est justement là où la question est intéressante, c'est comment ta ligne est différente,
parce que tu peux très bien avoir une R&D qui est en mode freestyle et c'est normal,
elle fait de la R&D.
Par contre, sur ta production, généralement, ta production,
tu as des coûts d'amortissement sur l'infra, etc.
Et là, tu dois garantir par rapport aux autres corps de l'entreprise que tu respectes tes budgets.
Donc c'est là où il y a un curseur assez difficile et où la communication est très importante,
que ça soit entre les équipes de R&D ou d'exploitation, les architectes pour voir ce qui peut être fait
dans les cadres budgétaires notamment.
Parce que le vrai problème, il y a des budgétaires sur ces points-là,
il est rarement technique et autre.
Parce que péter une enfra pour passer sur mieux,
c'est n'importe qui est capable de le défendre.
Péter une enfra pour x million d'euros,
mais qui ne va rien apporter de plus,
ça peut être cool techniquement,
mais en face, ils vont te dire « oui, mais pourquoi on prend ce risque-là ? »
Donc justement, c'est un point dans ce que tu as dit,
c'est que moi malheureusement, dans ce que je vois,
c'est qu'en fait, il y a plein de signes un poids of decision.
C'est-à-dire que tu as cité des exemples d'architectes qui vont prendre cette décision.
Et là, dans l'exemple dont tu viens de donner,
quand on le fait en chantier de transformation,
si quelqu'un est capable de donner dans le cadre d'une innovation combien ça va coûter,
c'est que ce n'est pas une innovation.
Ah bon, sans sens en tout cas.
C'est-à-dire que quand on fait de la nouveauté,
on ne sait pas vers où on va.
C'est-à-dire que là, d'un seul coup, on se retrouve devant quelque chose.
En fait, c'est justement le contraire.
C'est-à-dire que l'explavance, c'est extrêmement dur d'apporter de l'innovation,
en tout cas d'aller la convaincre pour des gens qui ne l'incomprènent pas.
Et donc là, comment tu arrives à m'étanger cette gouvernance avec des gens
qui sont au cœur de décisions et qui font au mieux, clairement.
Je pense vraiment qu'ils essaient de faire au mieux et de faire des décisions qui sont condhérées
face en fait à des gens en face qui ont eux la connaissance.
C'est-à-dire que par exemple, en cas d'une infrastructure,
changer toute l'infrastructure et passer à quelque chose de nouveau,
c'est extrêmement dur de coup dire
Alors combien ça va coûter et combien ça va être entabilisé.
Pourtant, la plupart de temps, il faut le faire.
C'est là où les rôles d'architectes qui sont en France,
la culture d'avoir l'architecte de système d'information,
elle n'est pas très développée, contrairement notamment aux États-Unis autres.
C'est le rôle de l'architecte et pour ça,
les architectes des systèmes d'information,
ils ont tout un tas d'outils typiquement le Togaf,
permettre de faire ça ou le Togaf.
Dans la gestion de cycle de vie d'une évolution, en fait, il y a un moment, il y a un coup.
Sauf que, comme tu dis sur l'IRD, c'est dur d'estimer le coup de l'évolution.
Mais en fait, le coup est calculé par rapport à un risque.
Et le risque, c'est les équipes techniques qui l'évaluent.
Donc ça veut dire que par rapport à des décideurs,
après, tu peux arriver avec ta brique en disant voilà.
Je sais, par exemple, que peut-être, pendant un moment,
mon essi va être dégradé par rapport à l'actuel,
mais c'est normal, c'est dans le cycle d'évolution du produit.
Et par rapport à ce cycle d'évolution,
je serre que je dégrade mon produit à un instant T,
mais au fin de cycle, quand l'autre brique dont je dépends,
aura elle-même évolué, je suis capable de vous dire et j'aurai les indicateurs
pour vous prouver que ça a été amélioré.
Et là, c'est le vrai rôle de l'architecte,
et notamment de l'architecte d'entreprise,
c'est d'être capable d'avoir la confiance des décideurs non-techniques
pour dire, voilà, moi je m'engage, je suis capable,
je fais confiance aux équipes techniques et vous, vous pouvez me faire confiance.
Moi, je connais vos besoins métiers et je connais la fonction technique.
Moi, je suis capable de parler aux techniques, vous, vous en êtes incapable.
Par contre, quand je vous dis que moi,
je m'engage sur ces résultats-là ou avec ces variables-là,
faites-moi confiance.
Et c'est pour ça que c'est vrai que c'est assez compliqué en imaginant sur l'IRD,
parce que oui, c'est prendre un risque,
virtualiser une infrastructure complète,
à part vous se dire, OK, on a virtualisé, cool,
on paye plus nos data centers, même si c'est faux, vu que tu payes autre chose,
c'est...
je sais pas ce que ça nous apporte.
Tout passer en mode cube, etc.,
l'intégration continue, tu prends ça à un...
C'est vrai qu'il dit ça.
Tu dis ça à un non-comptient,
il va te regarder en disant, je m'en fous en fait.
Est-ce que...
Ouais, est-ce que j'allais dire, c'était...
OK, on parle de changement, on parle de...
on a dit virtualisation d'IRDC,
on a dit pass-à-en-cubanetesse ou pas.
Tout ça, au final, comme tu l'as dit, c'est au final, on crée de l'IT,
on crée un service aromatique, c'est pour répondre à un besoin business, au final.
C'est ça, c'est juste de l'animement d'indicateur en fait.
Pour ça que l'IRDC, c'est là où, pour moi,
dans une entreprise qui fonctionne, on va dire, de manière...
où elle fait confiance à son IT,
le coût de l'IRDC, si quelqu'un vient proposer une évolution,
j'ai rarement vu un ingénieur ou n'importe qui proposer une évolution qui fait moins bien.
Après, la vraie question de l'évolution, c'est son évaluation dans le VSI global.
Et là, c'est là le boulot de tous les architectes, techniques et autres,
c'est d'être capable de voir est-ce que cette évolution, à long terme,
elle va apporter quelque chose à l'entreprise, niveau performance,
niveau temps de réponse, niveau coût,
ou est-ce que c'est vraiment de l'évolution que j'appellerais cosmétique ?
C'est OK, on est passé sur du Node.js, juste pour sortir un serveur web.
C'est quoi l'intérêt quand tu as des trucs qui marchaient déjà ?
Peut-être la vitesse de diplomat ?
Voilà, non mais c'est ça.
C'est ce qu'il y a dans les fragments orthographe,
c'est ce qui est clairement vendu comme indicateur de changement.
Il faut définir les KPIs qui permettent d'évoluer
que la brique fait quelque chose à un avantage.
OK, mais enfin, en gros, là, il ferait moins que tu parles,
ou même globalement, le rôle que tu définis pour ces gens-là,
c'est des architectes qui sont à l'échelle de l'entreprise,
ça a l'air extrêmement quantitatif.
Enfin, je pense que là où vous voulez en revenir Guilhem à la base,
c'est que t'as certaines démarches d'innovation,
ou tu ne peux pas a priori faire des calculs de rentabilité.
Tu peux éventuellement designer des frameworks pour mesurer à la fin
les éventuels retours sur l'investissement et l'éventuelle amélioration.
Mais c'est très dur de te projeter.
Donc à un moment, t'es obligé de faire des raisonnements
qui sont basés simplement sur des principes fondamentaux,
qui sont vraiment purement du raisonnement et pas du calcul,
qui est de dire « on va faire ça parce que si on découpe la façon de ton boss,
ou si on analyse la façon de ton travail aujourd'hui,
on sait que qualitativement, c'est plus logique de faire comme ça que comme ça,
même si on n'a pas forcément le moyen de modéliser ça et de calculer ».
C'est là où pour moi les architectes des systèmes d'information ont un rôle important,
c'est que ce que tu décris là, c'est totalement vrai,
sauf que ça, tu ne pourras jamais l'expliquer un fonctionnel.
Par contre, l'architecte lui sera capable de l'expliquer
en lui disant « là-dessus, je ne vais pas avoir des KPIs techniques maîtrisées ».
Par contre, je peux vous affirmer que sur du temps de déploiement,
sur de la PCA, sur de la PRA, de la récupération, de la mise à jour,
on va y gagner quelque chose.
Et là aussi où l'architecte après a un vrai rôle politique,
c'est d'être capable de dire « sauf que je ne peux pas vous le garantir maintenant,
on va le passer ». Et le rôle de l'architecte, c'est aussi de gérer justement cette contrainte,
à se dire « quand ça sera en vie, on doit pouvoir éventuellement faire de la réversibilité
pour revenir à l'ancien système ». C'est très rare les cas où on ne peut absolument
jamais revenir, ça existe, mais il faut qu'il soit capable de le vendre.
En gros, il faut qu'il donne des garanties au fonctionnel par rapport à la technique.
Et c'est là où j'ai envie de dire que c'est le grand avantage de l'architecte
en vision comme ça par rapport à ce que vous dites,
c'est qu'il peut très bien valider une décision de péter,
faire de la R&D en disant « oui clairement, c'est dans le bon sens,
et ça va nous avoir peint de perspective en justifiant sur le fonctionnel,
en juste, on a de l'évolution interne, mais en fait,
ça ne vous impactera pas sur vos capteurs PII, même s'il ne l'on sert rien ».
C'est juste la confiance après.
Donc là, là-dessus, tu es sur un appel, un argument d'autorité en fait ?
C'est totalement le but de l'architecte d'entreprise.
Comment est-ce que tu vois le rôle de cette personne-là par rapport à un...
la structure dans laquelle je suis, elle n'a pas forcément cette position,
mais du coup, comment tu vois le rôle de cette personne-là par rapport à un CTO ?
Alors, typiquement, un architecte, normalement, il est sous le CTO,
il répond à ce que j'ai eu le titre là où le CTO a une gestion, on va dire,
hiérarchique et organique d'une DSI.
L'architecte, c'est lui qui a vraiment la connaissance des besoins en métier
avec son allinguement fonctionnel sur le SI.
Parce qu'on n'a pas, entre guillemets, un architecte.
Normalement, il ne gère pas une DSI derrière, donc il n'a pas à gérer des gens,
il n'a pas à gérer des prestataires, il n'a pas à gérer des coûts,
lui, son boulot, c'est d'avoir sa cartographie, c'est d'avoir d'un côté les besoins métiers,
de le côté les besoins techniques, d'avoir le coup des besoins techniques
pour répondre à ses besoins métiers et d'être capable de répondre au métier sur les demandes.
C'est là où je différencie son rôle par rapport au CTO,
le CTO a quand même cette vision hiérarchique.
Là, dans des entreprises où il n'y a pas d'architecte,
c'est là où le rôle du CTO devient un peu bancable,
parce qu'il a à la fois la gestion hiérarchique des gens
et à la fois cette gestion, comme tu disais, de l'évolution et autre,
ce qui est super compliqué.
Parce qu'aller gérer une équipe de R&D en leur disant,
vous pouvez vous planter.
Alors oui, quand t'es sur Facebook, que t'as mis l'équipe qui bosse en même temps,
tu peux te permettre d'en avoir 500 kilos,
tu t'en fiches, t'en as 500 qui vont réussir.
Mais quand t'es dans un casque des entreprises,
en plus structurez à la France, j'ai envie de dire,
ça va tout de suite demander des comptes.
Bonjour, j'ai une R&D, vous n'avez pas produit.
Bah oui, mais en fait, la R&D, en même temps,
c'est normal qu'on ait des taux de perte.
Alors que justement, quand t'es dans la gestion avec l'architecte qui est libéré de tout ça,
finalement, c'est lui qui a la responsabilité de rendre compte aux fonctionnaires.
Lui, lui, lui, il a des comptes à rendre au CTO,
parce que forcément, le CTO, qu'est-ce que t'allais leur vendre comme rêve,
ou pourquoi t'as pas défendu notre super idée de la mort qui tue.
Mais c'est vraiment deux strates différentes.
Il y en a un qui, pour moi, est vraiment très hiérarchique,
alors que l'autre, il est vraiment dans l'entreprise en global.
J'ai juste une toute petite question pour refiner,
et je jette le pavé dans la marre,
mais là, on a l'impression qu'il y a des batailles entre le CTO,
la gouvernance, le board, l'architecte.
Mais comment on peut générer,
enfin, comment le DevOps est de la culture,
comment on va générer, on va fédérer les personnes,
et on va générer une culture autour de cette gouvernance-là.
Parce que j'ai l'impression un peu que c'est du top-down,
quand ça nous arrive dessus, et qu'on dit,
« OK, les objectifs, c'est ça, ça, ça, parce que l'entreprise a décidé que c'était bien. »
Et débrouillez-vous, donc comment tu fais en sorte que les gens, ils se l'approprient,
ils s'identifient à cette gouvernance, et ils soient d'accord.
J'ai l'impression que c'est juste à sens unique, et moi, je ne suis absolument pas d'accord.
Justement, c'est là où ce n'est pas à sens unique,
et c'est là où l'architecte a vraiment son rôle,
et que c'est vraiment un rôle important pour moi,
ce qui est souvent oublié en France,
c'est que, comme ma définition du DevOps se disait,
c'est un but où il n'y a pas de silos,
donc où il y a vraiment, normalement, l'échange entre les différentes équipes qui exploitent,
qui mettent en place, qui développent, etc.
L'architecte, lui, il va être là pour garantir,
quand même, que les objectifs du produit soient en tête de tout le monde.
Après, j'ai envie de dire, il est juste là pour vérifier que sa cadre,
avec les petites cases,
c'est vraiment dans le sens où, voilà, l'objectif,
tu ne vas pas laisser tes DevOps faire un truc,
alors que ça va l'opposer de l'objectif de l'entreprise.
Par contre, si sa cadre ou si quelqu'un a des bonnes idées dans l'entreprise,
là, ça va être aussi à l'architecte de les présenter aux fonctionnaires en disant,
au fait, on a ces idées-là,
ça pourrait vous ouvrir de nouvelles fonctionnalités, de nouvelles visions,
voilà ce que ça vous permet.
C'est-à-dire transformer là où, comme tu dis, dans une vision très top-bottom,
tu as la vision du fonctionnel vers le technique,
pas aussi d'ouvrir que la technique, elle peut ouvrir de nouvelles perspectives au fonctionnel.
C'est un médiateur plus qu'un architecte.
Moi, ça fait comme ça que l'on l'appelle.
Je pense que tout le monde se fera son avis là-dessus,
et on pourra vraiment encore avoir des débats plus tard.
Moi, juste pour avoir ouvrir un peu le débat,
et aussi le finir, être un peu les deux,
et d'être un peu plus prosaïque pour le coup,
c'est tout à fait avec Toghaf.
On nous a posé une question justement sur meetup.com,
sur le lien entre etil et DevOps.
J'aimerais que tu me fasses un peu,
enfin, ce que tu connais des frames morts comme ça,
et qu'est-ce qu'ils veulent dire, qu'est-ce qu'ils veulent faire,
juste même pour de la culture,
voilà, une certaine définition là-dedans,
Toghaf, etil,
et tout ce que tu connais peut-être pour que les gens,
puis après aller chercher même sur Wikipedia et autres.
Non, il y en a d'étonnes, il y a Kobith, etc.
Non, je connais très bien Toghaf,
parce que c'est vraiment, on va dire,
ce qui est dans l'air du temps depuis 20 ans
sur l'architecture d'entreprise, de AC, etc.
Et justement, ils ont pris en compte les retours des différentes,
on va dire, façons d'organisation,
et notamment la méthodologie agile appliquée sur le développement.
Pour ça que c'est...
Et comment tu le définirais concrètement ?
Toghaf, il faut le voir.
Là où etil, on peut dire que c'est des méthodes,
et que finalement, quand on lit les méthodes, on se dit,
en fait c'est con, c'est juste qu'on fait naturellement
si on réfléchit pas et qu'on est un peu cohérent.
Toghaf, c'est vraiment une structure de raisonnement
et une structure de gestion du AC
qui permet d'avoir de la lisibilité par rapport à quelqu'un
qui est non technique,
c'est-à-dire être capable de lui apporter,
voilà comment on va faire, voilà comment ça a été fait,
voilà comment on va le mesurer, quel coup ça a,
voilà on fait une itération, ça nous permet...
Et c'est concrètement, il y a déjà toutes les métriques
qui sont faites et c'est sur étagère ou c'est vraiment...
Non, non, c'est vraiment du framework à s'approprier après
et qu'il faut adapter à chacun des contextes d'entreprise
parce que c'est...
Et il est très cher à quelqu'un...
Et payer très cher à quelqu'un ou ne pas payer quelqu'un
et essayer de faire ça en disant, c'est bien les autres le font
et on n'a rien compris à ce qu'ils font, mais c'est pas grave.
C'est vraiment un framework de façon...
Oui, c'est vraiment du...
C'est le mot interdit, c'est vraiment du process,
de la documentation, du référentiel et comment le faire.
Et le par rapport à Itil...
Et l'Ontario...
Itil pour moi c'est vraiment de la méthodologie.
Alors vous allez dire c'est quoi la différence
entre la méthodologie et du process ?
Itil ils ont quand même cadré les choses,
on a les RFC quand on a des changements à faire,
on a tout ce qui est méthodologie de support,
tout ce qui est méthodologie de change en évolution, etc.
Et on va dire que c'est beaucoup plus concret
qu'à appliquer au quotidien que Togaf
ou quand vous lisez un document Togaf,
au début vous vous dites
mais les mecs ils ont fait de la filo.
Puis après il faut regarder les cas pratiques
et les cas d'exemple, on comprend ce qu'ils veulent dire.
Donc mon produit dépend d'eux.
Donc si je fais des évolutions,
tout le monde que je marque dans les évolutions
qui impactent les évolutions de l'autre,
c'est beaucoup moins...
Attends, du coup, tout ça c'est pas genre
vachement à l'opposé
d'autres logiques du style...
Les logiques où tu vas créer des équipes indépendantes
type feature team
avec des équipes plus biodisciplinaires
avec des gens qui représentent le produit
et donc même l'équipe en elle-même
qui porte sa propre vision de son produit
une équipe qui est indépendante
du reste de l'organisation
et qui peut y térer vachement plus rapidement.
Non, parce qu'en fait c'est comme je dis
c'est juste...
En fait quand on prend que ce soit itil et etc.
ce qui c'est quoi le principe
c'est d'avoir un référentiel
c'est d'avoir des docs qui décrivent le produit
et comment le faire évoluer
quels sont ces risques,
quels sont ces inconvénients
quels sont ces incidents
et ça même si tu fais une feature team
ou tu l'appareils
normalement elle peut fonctionner
sans documentation
Non mais c'est pas tant qu'elle peut fonctionner
sans documentation que le principe
d'indépendance des feature team
il doit être amené aussi sur le process
c'est à dire que pour moi
le but de ça c'est aussi que
chacune des équipes
pas forcément c'est peut-être pas à l'échelle de l'équipe
mais t'as des sous-organisations
qui décident
de fonctionner
en dépendamment
et donc qui peuvent faire évoluer
leur propre process indépendamment des autres
Mais c'est pas gênant parce que
typiquement Togas
c'est du process global sur le produit en global
si dedans toi t'as défini que ton produit
il était constitué de 25 feature team
etc
tant que ces trucs ressortent un élément
qui répondent à la capitale au final
elles font comme elles veulent
c'est là où il y a les différences
des fois après entre les framoires d'entreprise
Tiltogas
les méthodologies stylitiles
c'est que c'est pas
tu l'appliques pas en mode brut, dur
c'est assez souple pour pouvoir l'appliquer
finalement à chaque philosophie de fonctionnement
Ouais j'ai encore un petit peu de mal
sur la définition du Togas, tu mettrais ça
est-ce que tu commences
à construire une entreprise
t'as un business que tu veux monter
tu sais que t'as réussi à développer
tu commences à le bulle d'un
par du Togas
ou tu commences
je n'ai du mal à le voir
je repense au product management
je pense au product honneur
je vais être un peu un peu
enfoiré
et que tu peux commencer à parler de Togas
tu as une vision de ton évolution
de ton système d'information
si tu veux faire du mode start-up
à la rache
tu produis et tu sortes très rapidement
jamais tu feras du Togas
on sait tous que la première chose qu'on sacrifie
quand on veut faire vite c'est la documentation
c'est les perspectives d'évolution
tu veux sortir ta fonctionnalité
tu veux pas forcément prévoir le coup d'avance
de dire je la sors là, je vais avoir apprête à l'évolution
parce que là on a tué 2-3 lean manager
dans la discussion
je pense qu'on va en rester là
déjà sur le sens débarré
les gens ont déjà vu un peu plus
que c'était le gouvernement
si jamais ça vous plait on reviendra dessus
parce qu'on a vu que Togas,
Ethyl, etc. c'est toujours des points
un peu les pain points
par contre par rapport à la question
d'Ethyl versus notamment DevOps
c'est pas incompatible
la seule subtilité c'est que là
où en Ethyl il y a une question de temps
de deadline
pour reprendre ton grand ami
c'est pas forcément compatible de base
on va dire avec des sprints
mais en étant assez agile
et assez Ethyl
c'est capable de se fondre
faut juste arriver à se définir
on va dire des transformations
sur ces questions de temps
ok
tu nous as un petit zé la suite
de ce dont on allait parler
et je pense que l'actualité du moment
où vous l'attendez tous
tout le monde a parlé cette dernière semaine
ça a fait peur dans les chômiers
ça a fait fleurer des gens
ça...
allez vas-y
et donc on va parler de Meldon Spectre
et donc je pense que c'est l'ex-il nous en parler
parce qu'il est chaud bouillant
sur ce sujet là
ok, tellement ok
en fait en gros
je pense que tout le monde est à peu près au courant
mais il y a 3 d'une narrabilité
3 cvues
qui devaient être publiées le 9 janvier
qu'on fuitait un petit peu avant
qu'on était trouvés indépendamment
par nos amis de Google
du projet 0 et des chercheurs allemands
je crois
et qui globalement affectent
la plupart des cpu dans le monde
donc Meldon en particulier
ça touche surtout Intel
mais les autres
peuvent aussi impacter
donc AMD
donc ça touche carrément x86
et tous les processeurs x86
ou l'immense majorité
mais aussi des trucs vachement plus
comment dire
Sucs
donc ARM 64 beaucoup
mais même PowerPC
même le Z-System de IBM impacté
donc globalement
c'est une défaillance
dans des optimisations
qui ont été mis en oeuvre
début des années 90
sur
du prefetching
quand on fait
la prédiction de branche
donc c'était des choses qui avaient été
toujours envisagées comme étant un peu
perchées à la base
qu'on a fait fin des années 90
pour des raisons de
performance
qu'on a mis dans tous les cpu à partir des années 2000
parce que c'était vraiment trop bien
sauf la résilier-répid
parce que lui il est vraiment roulé sous les SEL
et donc
en fait ça fait super longtemps qu'il y a des gens qui supposaient
qu'on pouvait exploiter ces machins là
et pour faire des choses plus ou moins graves
et donc
nos amis de Google ont réussi à trouver
3 mauvaises façons de les utiliser
globalement
il y a 2 familles de venirabilité
Meldon c'est celle qui a fait peur à tout le monde
et qui en fait la moins grave
ça faisait peur à tout le monde
parce qu'en fait ça permet à des
process en userland de toucher
à de la mémoire qui est dans le kernel
donc c'est pour ça que les gens ont flippé
sauf qu'en fait c'est super facile à
protéger
donc il y a des patchs qui ont été fait
notamment dans Linux mais dans tous les OS
donc dans Linux le patch c'est
maintenant KPTY
kernel page table isolation
et donc le principe c'est de protéger
contre cet exploit
pour
récupérer
le principe de l'exploit c'était de lire
dans le cache du cpu
des pages qui appartiennent au kernel
alors que nous on est dans userland
donc ça c'est facile à protéger, suffit de patcher
son kernel, normalement aujourd'hui
tout le monde a publié des kernels qui vont bien
pour en parler
oui, il y a des gens qui ont mis un peu plus
de temps que d'autres, il y a des gens
qui ont publié des trucs et en fait ça
marchait pas, on en parlera pas
parce que sinon on va avoir des procès
et après il y avait spectre
spectre ça c'est beaucoup beaucoup plus
embêtant, donc il y a 2 venirabilités
qui sont des variations sur un même thème
concrètement c'est plutôt
des histoires d'une application A
qui lit la mémoire d'une application B
ou du JavaScript dans votre
navigateur qui lit de la mémoire
que le navigateur voulait protéger
et ça c'est
assez embêtant parce que
globalement c'est plus difficile
à protéger juste en upgradeant son kernel
donc la plupart des applications ont publié
des patches pour se protéger
notamment toutes les applications qui exécutent
du code qui est arbitraire, donc typiquement
Firefox, Chrome, un browser chez vous
faut comprendre que c'est
une machine virtuelle qui tourne sur votre CPU
et qui exécute du code qui a été écrit par d'autres gens
principalement
de tonnes de JavaScript qui ont été écrits
par des trackers de pubs
si mon regard
quand on meurt va être pire à mon voisin de droite
non mais principalement c'est ça
votre problème aujourd'hui quand vous allez sur un navigateur
sur n'importe quelle page web vous avez absolument aucune idée
de tout le code qui va être exécuté
et l'immense majorité du code qui va être exécuté
n'a pas été écrit par les gens que vous allez visiter
donc voilà c'est ça le souci
ça aussi tu t'appelles Richard Stallman
oui voilà ça aussi tu t'appelles Richard Stallman
et que tu désactives le JavaScript
mais du coup c'est vachement pas pratique sur un trajet d'aujourd'hui
et donc bref
globalement il y a 2 ou 3
façon de se protéger en upgradeant le microcode
des CPU Intel
notamment
et il y a des mitigations
dans le kernel qui sont possibles pour certaines classes d'attaque
il y en a d'autres qui sont plus difficiles à faire
et ce que Google a réussi à faire
et qui va probablement arriver upstream
assez rapidement
parce qu'ils ont open sourcé tout ça
c'est une mitigation qui s'appelle RedPolin
concrètement
l'idée c'est de fixer les compilots
pour que
plutôt que de jumper
de manière arbitraire
dans des espaces mémoires
on remplace des instructions de Jum
par un savant exercice
qui nous appelle Trompolin
avec un return
et donc on se protégerait
d'aller lire des espaces mémoires qu'on a pour l'heure d'aller lire
donc ça devrait arriver
ça commence à arriver
il y a 2-3 distros
qui ont publié ça par exemple
pour Linux, les patchs RedPolin
mais ça pour le coup c'est pas encore mitigé partout
donc les applications peuvent même se protéger
mais une vraie protection de système
c'est plus compliqué
il y a RedApp qui offre un truc
mais c'est assez compliqué
ce qu'on voit dans cette classe d'attaque
et encore on peut même en citer
plein d'autres qui arrivent
on a par exemple une file hier
sur Intel
en composant Intel de surveillance
Intel M.O tu veux dire
on a même des files
il y a l'intérieur de Linux
c'est ça qui est à l'intérieur de...
le truc c'est plutôt que
le management de système de Intel
que tu as sur tous les serveurs et la plupart des laptops
dedans il y a un OS
et dedans il y a un Minix
qui tourne avec un niveau de privilège
qui est supérieur à celui de ton route
de ton OS en gros
ce qu'ils appellent
prosaiquement le ring-2
le carnet il est écouté dans le ring 0
et c'est assez fun
que ce soit un Minix
parce que c'est un truc qu'on pensait que personne utilisait
en fait c'est dans 100% de tous les serveurs du monde
enfin tous les serveurs Intel
genre 99% des serveurs du monde
donc c'est fou quoi
c'est probablement le truc le plus déployé dans le monde
en fait, Minix
OS le plus déployé
ce qui est assez rigolo à l'avenir
mais en fait
ce que je veux dire c'est qu'on commence
à avoir des espèces de classes d'attaque
on a une symbiose entre
hard, psoft
là où avant on avait mis
une séparation, on avait des ingés hard
des ingés soft
le hard n'avait pas de faillite de sécu
ou alors si
il fallait avoir un accès physique
ou alors il était bugué
on pouvait être bugué mais personne n'en visageait
que le hard avait des trous de sécu
les gens utilisés de la sécurité
mais le commande des mortels comme nous
n'avaient pas prené personne à tenter
maintenant c'est vraiment un lien fort
entre hard et soft plus qu'on pensait avant
et donc peut-être cette différenciation hard soft
elle est presque plus
est-ce que c'est pas lié aussi
à l'avenu
à l'avenu des technologies de virtualisation
parce qu'on s'est mis à utiliser
des fonctionnalités hardware
et on a
on a intégré des
fonctionnalités
pour aider le software à l'intérieur du hardware
comme à l'époque avec des co-processeurs
ce genre de choses là
clairement si tu regardes
x86
qui est l'instruction set de Intel
ça veut pas dire
grand chose
à travers le temps
c'est-à-dire que c'est un truc qui est très vieux
sur les 25 dernières années
le nombre d'instructions
qui sont apparus
il a été
il est monstrueux déjà
et même sans parler du nombre d'instructions
parce que l'instruction c'est une chose mais c'est pas forcément le plus grave
c'est que les processeurs
ont énormément évolué
et en fait à l'intérieur d'un processeur
Intel standard que t'as même dans ton laptop
il y a une quantité d'intelligence
qui est complètement démentielle
donc typiquement la problématique
ici
c'est
ton OS il n'exécute pas directement des instructions
sur le CPU
il faut des instructions dans un pipeline à exécuter
et du coup à ce moment là
on a voulu tirer parti de ça
il y a des
calculateurs dans le CPU
des co-processeurs
quasiment des bouts du CPU qui sont dédiés
à analyser le pipeline en question
et à préfetcher du cache
dans le CPU
depuis la RA
pour qu'à chaque instruction
qui s'exécute
on ait toujours la bonne donnée dans le cache
et c'est globalement cette mécanique
extrêmement complexe
particulièrement quand tu dois faire
de la prédiction de branche
parce que quand tu as un if
tu peux peut-être pas avoir besoin
des mêmes data d'un côté et de l'autre de la branche
qui a amené toutes ces attaques là
il se trouve que tout ce système là
même s'il est gravé dans du silicone
si tu devais l'écrire
en software déjà
il serait hyper compliqué
et en fait dans le hard actuel
il y a une complexité qui est supérieure
à celle qu'il y avait dans le soft d'il y a 40 ans
c'est assez marrant
alors là je peux vous tromper
si jamais quelqu'un s'y connaît mieux
il pourra me bâcher
mais je crois justement c'était un peu ce qu'il avait essayé de faire initial avec
l'Itanium 64
c'est à dire qu'ils avaient justement
créé un processeur beaucoup plus simple
où la logique avait été déportée dans le compilateur
et où justement il y avait
c'était du inorder
mais un peu modifié pour faire en sorte d'avoir
plus de pipeline etc
et justement en fait toute la logique
c'était de se dire au lieu de mettre
beaucoup de choses dans le silicone
et prendre énormément de place sur le dye
on va plutôt essayer d'avoir
une logique logicielle
parce que c'est plus simple à patcher
c'est plus simple à modifier
c'est moi quand j'ai commencé l'électronique
j'avais les processeurs risques
et les processeurs disques
et la particularité
d'Apple à l'époque c'était de fonctionner
sur du risque donc reduce instruction set
et d'une telle c'était de fonctionner
sur du complete
du full instruction set
et c'est vrai qu'on est passé sur du complexe
et là j'ai l'impression que tu es en train de décrire
c'est du reduce
c'est même un tout petit peu plus fort que ça
parce qu'en fait
effectivement
il y a des processeurs risques
qui ne sont pas affectés
il y a aussi des processeurs
qui sont catégorisés et risques
qui sont affectés en fait
donc ce n'est pas que l'instruction set
c'est aussi effectivement
ce que tu mets comme logique dans le CPU
qui n'a pas vraiment à voir
avec quelle instruction tu exécutes
parce que par exemple une instruction compliquée
c'est une instruction qui décolle une string
il y a plein d'instructions
spécifiques pour les strings
pour faire des dit delta entre deux strings
par exemple il y a des instructions dans x86 et stringtel
ça dans un ARM V6
que tu as dans ton bras de BMP
il n'y a rien pour faire ça
mais ça c'est qu'une instruction
ça aurait pu être une addition de 64 bits
ça ne change pas grand chose
alors que là c'est carrément
des d'autres mécaniques
d'optimisation qui sont rajoutées
et qui ne sont pas complètement perpendiculaires
mais un petit peu différentes
de combien d'instructions tu as
ça n'empêche qu'efectivement
itanium il me semble qu'effectivement
c'était plus ou moins orienté là-dessus
il y a d'autres CPU qui sont orientés là-dessus
je pense que vraiment ce qui s'est passé
pendant un temps c'est que les
processeurs voyant des systèmes
au dessus qui n'étaient peut-être pas très intelligents
difficile à bouger
il fallait pour itanium
il fallait complètement avoir un OS repensé pour itanium
et pour ça ils n'ont pas réussi à l'imposer
c'est qu'en face il y a des Windows qui ont sans doute
vraiment voulu changer
et en fait ils ont injuté la logique dedans
c'est passé avec des temps en même chose pour les SSD
ou quand les SSD sont arrivés le problème c'était
XP ne gérer pas les SSD
et en fait il a fallu que les firmware
à l'intérieur des disques SSD
émule un disque pour pas faire en sorte
qu'on brûle toujours les mêmes cellules
et donc en fait on ne s'approvaient pas d'avoir des bugs logiciels
à l'intérieur d'un SSD qui faisait qu'on pouvait perdre de la donnée
alors même que normalement le F5
avait été fait
et en fait je trouve que c'est un peu le lien
c'est le principe du KISS appliqué à du hardware
après par rapport à ce que vous disiez ce qui est
ce qui est très vrai c'est
ce qu'on paye finalement aujourd'hui c'est
les délières des fins des années 90
ou ceux qui n'étaient pas trop vieux
à l'époque sans souvienne
Intel ils ont eu un problème
c'est qu'ils avaient sorti le Pentium 2
qui était super performant
puis après ils ont commencé à partir dans leur dealer
de pipeline et ils se sont crachés la tronche
sur l'architecture des sonores
voilà sur toutes ces architectures là
vouloir ressentir
sauf que les OS en dessus ils n'étaient pas très intelligents
Microsoft traînaient toujours son vieux noyau
d'un côté NT et de l'autre côté
Nuffix qui avaient du mal à faire évoluer
petit à petit
et donc comme tu dis certainement
le plus simple à l'époque c'était de
rajouter de l'intelligence dans le CPU
que d'attendre que l'OS en dessus évolue
sauf qu'en même temps c'est
vrai que votre pensée sur les processeurs
Sysc et RISC est intéressant c'est que typiquement
Sysco ils ont continué à mettre du risk
dans leurs
équipements réseau et il n'y a que très récemment
où ils sont passés sur du Sysc en faisant
de l'AVM par dessus
et là
on se rend compte que
des choix qui étaient des choix c'était plus simple
de développer parce que le Sysco là
où il était obligé d'avoir du matériel
pour développer le iOS dessus etc
ils tournaient dans l'AVM pour développer le iOS
et des fonctionnalités
il y a un temps pour eux sauf que là tout le monde
se retrouve exposé
et sans trop savoir
pourquoi et autre on parle pas que
ton Raspberry
pour enfants là
forcément je pense que mon convertisseur
franc-euro lui n'est pas touché et encore
on n'est pas élabré
et là où vous avez noté un point
c'est qu'il y avait plein de défauts dans le hard
moi je me souviens quand j'étais à Superfo
j'avais fait le système d'évaluation
j'avais dû faire un système de détection d'AVM
pour pas que les étudiants exécutent le soft
dans une VM pour pouvoir tricher
et j'utilisais le
code d'eBM
RedPiceBloopice pour détecter
sauf qu'à l'époque à Superfo
il y avait un partenariat avec FUE
IBM SyncPad
et on était tombés sur une classe de centrino
ça devait être les premiers cordus
ou je ne sais plus lesquels
qui étaient bugués
et donc le test de VM
sur un OS non virtualisé répondait toujours vrai
et donc les étudiants je me suis retrouvé
avec une promo complète qui avait le dernier laptop
fendu par l'école
qui passent leurs premiers révals
et qui ne peuvent pas passer leurs premiers révals
parce que le test était faillant
et là tu es comme un con
et là tu commences à faire d'en monter
et t'as IBM qui te sort un firmware patché
qui fait qu'après en fait ils répondaient toujours non
je ne suis pas une VM
même quand j'étais une VM
mais c'est là que tu rejoins le point
c'est qu'il y avait plein de bugs dans le hard
sauf que ça se voyait pas trop
et que les firmwares on les passait de temps en temps
à l'art de rien
on disait amélioration
et fixait 43 bugs
sauf qu'aujourd'hui tu prends n'importe quel laptop
quand tu les fais les mises à jour
quasiment toutes les 15 jours
t'es mis à jour du BIOS
il y a ça
il y a aussi une nouvelle type d'attaque
dans le sens où les timings
et ce genre de choses là
c'est quelque chose qui était sorti
effectivement dans la bo Google
et je ne sais plus qu'il y a une chercheuse
qui a fait un papier au stick
qui avait commencé à en parler
et à mon avis
c'est le début d'une longue histoire d'amour
qui va commencer entre les CPU
et les faits de sécurité par timing à attaque
ça a déjà été des problématiques
qui ont été vues en partie de la crypto
ou les crypto-analystes avaient commencé
à étudier les problèmes de ok
comment je fais pour savoir si mon CPU chauffe
si j'arrive à pouvoir
et c'est quelque chose qui est sur la partie système
et la partie CPU
n'a jamais été
étudiée
parce que simplement personne n'y avait pensé
je pense qu'on va pouvoir s'arrêter là
on aura encore deux sujets
parce que si jamais tes prédictions sont justes
et on ne les perd pas
on va le pacher pour ses prédictions
et on va le penser pour ses prédictions
en fait j'ai quand même un truc à rajouter
juste pour conclure
l'idée que tu avais
que le software
était trop lent dans l'évolution
et que l'évolution hardware était plus rapide
et que c'était plus simple
de faire évoluer le hard
je pense que ce n'est pas exactement que ça à l'histoire
parce que mettre des trucs dans le hard
a aussi plein d'intérêts d'un point de performance
mais n'empêche que ce n'est pas du tout un truc nouveau
cette idée là
et c'est même un truc qui a 40 ans
c'est une des raisons
pour laquelle on a fait de la virtualisation
que le software n'a jamais évolué aussi vite que le hard
c'est jamais arrivé dans l'histoire de l'informatique
le software a toujours été le truc qui était le plus lent
et c'est les premiers à avoir fait cette expérience
c'était IBM dans les années 60
quand ils ont sorti une toute nouvelle
architecture top move qui était le IBM 360
qu'ils ont demandé à tous leurs clients
de l'acheter pour porter tous leurs software
que tous leurs clients leur ont dit qu'ils ne pouvaient pas
qu'ils n'allaient pas réécrire leur software
et que IBM a dû inventer la virtualisation
pour garder des clients
si je vais sur mon diatue et vraiment c'est à toute fin
on voit que là Windows
pour sortir un Windows ARM
a dû sortir une compatibilité x86 sur ARM
pour faire tourner les applications
que tout se sont, ils savaient que personne n'allait réécrire
il revient d'une boucle temporelle de 60 ans
c'est assez dingue
donc peut-être l'état à l'esprit
de la plupart des développeurs qui pensent
qu'ils sont tout le temps au top par rapport au hard
c'est genre
pas totalement bullshit, c'est en même temps les deux
à la fois
vivement qu'on ait les failles dans les GPU
ça va pouvoir faire des trucs sympas aussi
c'est très rigolo
il faut les trouver c'est tout
et même dans les cartes réseaux
ça y en a déjà
plein de choses en perspective géniales
maintenant on va passer à un sujet toujours un peu hard
on va parler de Docker
et Docker Inc plus exactement
ça c'est un blog post
qui a été fait
on vous filera tous les liens
des articles
c'est un article sur Docker Inc
qui est dead
donc ça ne s'attache pas trop
à la technologie Docker en elle même
qui à l'heure actuelle justement a réussi
à être découplée
peut-être ça à franchir un peu aussi
de la tutelle de Docker Inc
mais c'est vraiment qu'à l'heure actuelle
l'entreprise en elle même
a commencé à pérécliter
c'est la vie du blog post
les raisons évoquées
c'était des fois des choix technologiques
qui n'étaient pas forcément les bons
on peut citer la swarme
par rapport à la Kubernetes
on peut pouvoir débattre là dessus
mais aussi des choses internes
on va penser
tout ce qui est harcèlement au sein de l'entreprise
on va penser à des choses comme ça
on va penser à une culture
peut-être d'avoir cherché trop d'investisseurs
et c'est vraiment
là sur l'incapression on va peut-être pas
essayer de parler trop longtemps
mais votre avis là dessus
sur Docker Inc ce qu'ils ont fait
et où est-ce qu'ils en sont maintenant
alors
moi j'étais à la DockerCon cette année
je pense pas
que Docker Inc va mourir
très rapidement
je n'en doute très fortement
ils ont clairement fait un énorme virage
vers
l'entreprise
et vers la migration
de systèmes qu'ils qualifient de l'égassi
vers des trucs
contenérisés
donc c'est leur gros gros focus
aujourd'hui
évidemment du coup ils sont devenus
vachement moins cool globalement
le cool factor de Docker
dans l'infrastructure
il a pris un gros plomb en elle
mais
peut-être qu'ils vont réussir à gagner
de l'argent avec ça
peut-être que ça va leur filer suffisamment d'argent
pour se retourner parce qu'en parallèle de ça
on sent qu'il y a clairement une guerre interne
dans Docker
entre l'absence révélateur
entre les gens qui poussent le business
actuel
tu vas voir les banques
et tu leur dis les mecs coucou un salé Docker
sur vos machines mettez toutes vos applications pourries
qui sont existantes dans du Docker
et pouf vous n'avez plus besoin de faire de migration IT
effectivement
il est probablement un business model hyper rentable
pourvu que tu arrives à le vendre
et d'un autre côté
les gens qui sont là à dire ok on sait peut-être
gofrer sur Swarm
c'est un problème stratégique qui comme une terre
pas technologique mais
on sait gofrer sur Swarm
faut vite qu'on aille sur Kubernetes
faut qu'on tienne une distro Kubernetes
et je pense que le seul truc
qui est vraiment inquiétant sur Docker
c'est qu'il s'est parti
moi je pense qu'ils ont quand même
l'avantage d'avoir laissé une marque
et d'avoir encore une marque présente
Docker
ils ont quand même
ils ont un poids dans la communauté
et c'est vraiment pas rien
donc je pense qu'il y a encore du capital
il y a certes ils ont perdu en cool factor
mais il y a du capital communautaire
encore présent
et il y a moyen en effet de faire quelque chose
c'est vrai qu'aujourd'hui en termes de lisibilité
de l'offre
il y a une grosse lacune, on sait pas vers quoi il va
ils vont pardon
le passage à Docker E, Docker CE
c'est fait un peu dans la douleur
il y a beaucoup de personnes même au sein de la communauté
qui étaient des gros fanboys qui ont dit
non, je passe pas la version
je reste sur une vieille version
je suis malé sur le site de Kubernetes
et ils conseillent d'être sur la version
mais ça c'est du sabotage
ça n'a pas de la stratégie
c'est du sabotage
moi ce que je trouve hallucinant
c'est pour ça que j'ai dit
il y a perdu cool factor
je pense qu'ils ont un énorme crédit
dans la communauté des développeurs
monstrueux, hallucinant
et ils continuent à être incroyables
parce que maintenant quand t'es sous Mac
le truc le plus simple pour avoir un Kubernetes
c'est d'installer Docker
mais genre ultra loin
tu fais clic clic ça marche
donc du coup
ils ont une énorme aura là
à mon avis ils ont une aura moyen
auprès des 6 admins
mais bon c'est peut-être pas très grave
et par contre ils ont un problème
c'est que je sais pas comment Google se démerde
mais concrètement
dans cette espèce de combat entre Kubernetes
et Docker
Docker a réussi à sortir comme étant le méchant
ou ce qui faisait pas bien
alors que globalement
ils ont fait genre tout pour Kubernetes
y compris sortir RunC et containerD
de leur textac
donc extraire les composants
les plus fondamentaux
pour que ça colle mieux avec
les besoins de Kubernetes
et y compris très récemment
globalement fixer
tous les problèmes de CQ
qui avaient dans Kubernetes
au niveau de l'authentification
des nœuds entre eux etc
qui avait été fait
enfin qui avait pas été adressé
qui était pas dans le MVP
et qui aujourd'hui
sont quand même largement meilleurs
et typiquement
tout le système qui permet maintenant
de faire des cubes Ctl
de lancer un cublette avec un token
pour lui dire de join un cluster
ou des choses comme ça
ça c'est 100% pomper
sur la user expérience
que Swarm a apporté
et c'est là où je voulais dire
que Swarm je sais pas si ça marchait vraiment très bien
au Run
mais en tout cas ça présentait une UX
qui était exactement ce qu'il fallait
ça ils l'ont inventé
donc en fait Docker
c'est un peu le Windows
de l'open source des containers
c'est peut-être la Windows
un terme un peu spécial
c'est à dire que c'est un truc
qui est une absence qu'en 2018
c'est vrai que si t'avais dit ça il y a quatre ans
ça me voulait rien dire
mais maintenant oui
Windows, open source et containers
n'avaient pas rien à foutre dans la même
en fait je pense que c'est vrai
que c'est une bonne vision
c'est que Docker ils ont la marque
ils étaient là ils l'ont su l'imposer
et ils auront toujours la fiction
que tout le monde a pu avoir avec eux
ça je crois qu'on parlera toujours et autres
sur la lisibilité clairement ils n'en ont pas
et c'est clairement un défaut
parce que quand t'as pas de lisibilité
par rapport au sujet de la gouvernance
qui ira appuyer un truc fait par une boîte
qui n'arrive pas à lever
si ils arrivent à lever de l'argent mais ils n'arrivent pas à en gagner
comment dire c'est chaud quand même
alors qu'un Google en face
bon bah c'est Google quoi
pas trop peur quoi
et là au par contre t'as raison c'est
qu'ils sont un peu fait bouffer à être trop gentil
c'est qu'ils ont
fait le nécessaire pour que leur brick
soit consommé par les autres
que ce soit Kubernetes
Enco
mais on les a...
il y a une guerre avec Core-S qui est gigantesque
on le bouille un peu
il passe pour les méchants
alors là c'est vrai que c'est intéressant
de comprendre pourquoi ils passent pour les méchants
mais...
ils sont les méchants
ils passent pour les méchants parce que
les autres protagonistes
sont Red Hat
Google
Core-S éventuellement
et qu'en fait
ils sont tous ensemble
et moi c'est une impression
mais j'ai l'impression qu'en fait qu'il y a du vautour qui tourne là
et qu'ils attendent qu'une chose
que les mecs qui jettent les ponches pour récupérer le lot du bain avec le gamin
à l'intérieur
et c'est pas forcément Google
et c'est pas forcément Red Hat
non peut-être que Microsoft rachètera de l'air
mais c'est pas forcément un...
un bâchette
parce qu'ils sont quand même très ouverts
sur ce système là
et ils ont pas la techno
quand tu vois les recrutements qu'ils font chez Microsoft
en termes de...
ils ont toute la Stack Linux maintenant
qui marche même sous Windows 10
sous Windows 10 quand ils installent l'Own Boot Tool OpenSUSE
pour faire tourner des conteneurs
ils te font installer le conteneur
en disant c'est bon, on s'est le gérénativement etc
ça devient une user expérience qui est plutôt sympathique
et ce qui leur manque
en fait c'est juste de racheter les mecs en entier
oui, je sais pas
ça fait peut-être du sens, je suis pas sûr que...
c'est le plus logique, mais c'est pas très logique non plus
non, on verra
l'avenir nous le dirait et on aurait qui aurait pu parier là-dessus
il y a encore
deux ans, trois ans
et rien de deux ans c'était l'initialité
c'est un tout autre sujet maintenant
encore technique, donc Bartelémy
comme il l'a utilisé tout à l'heure, on lui parlait des API REST
des API REST
on est beaucoup là-dedans
donc ça y vit
alors
petit préambule malgré tout
ce genre de choses
alors on tamise les lumières
on lance les regards
attention, message au DevOps
les plus sensibles
cette rubrique ne va pas aborder les différences subtiles
entre web service, interface protocolaire
et interface programmatique
cependant, ces notions
pourront être débattues à la fin de cette intervention
ceci n'est pas un exercice
sur ce, on me prête le micro
aujourd'hui
pour que je vous parle d'APREST
en effet
et comme on est nombreux, on va aller vite
l'idée comme d'habitude
c'est de poser quelques bases historiques et techniques
et ensuite de vous donner un maximum de recommandations
et d'astuces
pour enfin vous aider à construire de belles API REST
ou du moins
vous conforter dans vos habitudes
si vous êtes déjà parfait
voilà
donc parlons histoire
REST c'est un petit peu le petit frère
de HTTP
c'est le même auteur, c'est Roy Fielding
il a écrit en l'an 2000
lors de sa thèse
ça doit être sa présentation de thèse
donc 10 ans après HTTP
contrairement HTTP
REST n'est pas un protocole
c'est pas un standard
et c'est pas non plus une interface en tant que telle
non, REST c'est avant tout des règles d'architecture
qui imposent des contraintes sur les méthodes
qu'un serveur et un client auront pour dialoguer
l'un avec l'autre
cela va même plus loin
que des règles
c'est
contrairement à d'autres modèles d'architecture
qui sont proposés SOAP
des trucs qui ont pu exister avant
REST propose par nature
de modéliser directement les fonctions
demandées par des utilisateurs
et se place alors dans un contexte
plus haut niveau
en pratique on va quand même retrouver beaucoup
d'interface type CRUD
c'est à dire
une espèce d'application par dessus
une base de données
type update, create, delete
mais c'est quand même important de préciser
que
depuis le début
REST a quand même une vocation
à modéliser des choses au niveau
et de modéliser
un parcours utilisateur, une expérience utilisateur
une action de l'utilisateur au complet
c'est bien la force de la PIREST
c'est avant tout d'être une interface
comme toute interface
on va prendre l'exemple d'une interface graphique
c'est destiné, par exemple l'interface graphique
elle est destinée à un utilisateur devant son écran
l'interface REST
elle est destinée
à un utilisateur aussi
sauf que cet utilisateur là c'est le programmeur
malgré les différences
complètement évidentes entre ces 2 types d'interface
et on va retrouver quand même
des principes
qui sont assez similaires
c'est à dire qu'on va demander à
cette interface REST d'être simple
extensible, fiable et performante
donc la simplicité
c'est notamment de définir
des interactions qui sont
de manière stricte
et stateless
il faut essayer de trouver une traduction française
sans état
il y a la notion d'état
de toute façon on viendra juste après
tout est formalisé
dans les requêtes et dans les réponses
voilà c'est simple
l'extensibilité
le concept de REST est de supporter
plusieurs formats d'entrée et de sortie
et différents formats de représentation
de la donnée
on peut aussi parler dans l'extensibilité
de supporter plusieurs versions
on y reviendra
la fiabilité c'est la séparation
des actions
on veut qu'une action n'aie
des faits que sur la ressource et qu'il n'y ait pas des faits de bord
qui n'est pas des faits collatéraux
ou de choses implicites
tout ce qu'on va faire ne va faire que ce qu'on lui demandait pas plus
une même requête on demande aussi en termes de fiabilité
qu'une même requête exécutée 2 fois de suite
produise le même résultat
en termes d'état
on veut que quand on exécute une action
l'état final soit le même
et si on réexécute l'action après
l'action, le résultat
c'est l'idempotence
moi j'appelle ça la condition de rejeu
mais c'est en effet c'est l'idempotence
la performance
donc pour le reste
on oublie un peu dans ce cadre là
l'interface graphique parce que ça n'a vraiment rien à voir
le reste c'est avant tout la possibilité
et la facilité de mettre en cache
simplement les réponses en proposant
une méthode standard
et des
des petites choses pratiques qu'on verra plus tard
voilà donc on a parlé de ressources
on a parlé d'action
on a parlé d'état
mais au final on sait toujours pas ce que c'est crest
à ce moment
donc ça serait bien quand même de redéfinir
la définition de l'acronyme
qu'est-ce que ça veut dire
donc on va y aller toujours au pad course
donc crest ça veut dire
representation state transfer
donc c'est
des transferts d'état
sur des représentations
si on franglige un petit peu
donc il y a toujours
on a déjà le mot état qui apparaît
donc globalement ça veut dire qu'on va définir
des actions sur des ressources
et ces actions auront pour effet de
passer ces mêmes ressources d'un état à un autre
c'est pas plus bête que ça
il y a des ressources, on fait des actions dessus
et les ressources passent d'un état à un autre
on a défini tous les termes de
reste
l'utilisateur final
ne manipule donc jamais la globalité
des ressources
mais il va travailler systématiquement
sur une représentation
c'est là le terme un petit peu compliqué
le terme représentationnel
il travaille sur une représentation limitée
d'une ou plusieurs ressources
sur laquelle il veut agir
c'est un peu compliqué
en pratique
chaque ressource sera associé à un nom
et chaque action sera associé à un verbe
c'est une manière standard de définir les choses
on essaiera de faire en sorte
que si on utilise un pluriel
pour le nom on l'utilise partout
si on fait du snake case
on essaie de garder un standard
il y en a quelques-uns qui existent
et les verbes on les définit bien comme il faut
si on fait du français on le fait partout
et si on fait de l'anglais on le fait partout
petite astuce, éviter de mélanger les choux et les carottes
et puis comme
Roy Fielding il a bien pensé les choses
il s'est arrangé pour que le modèle reste
il s'intègre parfaitement avec le protocole HTTP
donc vous allez pouvoir mâper
chaque action sur des ressources
avec un couple
méthode HTTP URL
et la boucle est bouclée
il a écrit sa 10 ans après
mais il a pensé à réutiliser ses travaux
il est pas bête
donc nous voilà avec un modèle reste ultra basique
faut quand même noter que derrière on a des états
donc qui veut dire état
d'y venir stockage
et bon
pas toujours mais il y a du
il peut y avoir du stockage
mais reste ne donne pas de directive particulière
quant à la manière de stocker
et de persister ces états là
et ses ressources
donc c'est libre à vous de faire ce que vous voulez
d'utiliser n'importe quelle technologie
n'importe quel mode MongoDB
PostgreSQL
du Fichier Texte
vous vous débrouillez
il n'y a pas de règles en la matière
tout ça ça paraît un peu obscure
les gens je les ai perdu
on va utiliser un petit exemple
très bête
vous allez voir
donc
imaginez vous avez la charge de la gestion d'un parking
tout bête
vous avez quoi ?
votre parking souterrain
il est là
vous voulez exploiter au maximum
vous vous dites je vais coder une API de gestion
et une réservation de ce parking là
ok
j'imagine
mes ressources qu'est ce que ça peut être
ça va être
des réservations
je voudrais optimiser ça
savoir que les gens peuvent venir à telle heure
et faire un peu
du management d'occupation
ok donc ça c'est pour mes ressources
mes actions ça va être
certainement listé, occupé, libéré les places
listé, créé, modifié, annulé
expiré les réservations
j'ai déjà un petit modèle
d'utilisation de mes ressources
je les ai modélisés de manière humaine
tout ça je pourrais le faire à la main
avec un stylo, un papier, un téléphone
et j'ai défini un modèle
donc il est quand même centré sur des actions humaines
l'idée est quand même de raffiner un peu tout ça
avant de vous lancer
et de venir les prochains parkings
il y a du travail
donc on a compris les bases
on va attaquer le lourd, les recommandations
et les astuces restent
que j'ai appris pour certaines
que je connaissais pas exactement
par coeur
je vous donne ça
une remarque
non
parfait
donc on l'a dit, la force de reste
c'est d'avoir été construite avec l'idée
de coller le plus possible au protocole HTTP
et d'utiliser de manière intelligente
tout ce que propose ce protocole là
donc on va par exemple
pouvoir utiliser les codes de retour
de manière complètement évidente
proposé par HTTP pour fournir
une information détaillée en cas de défaillant
de l'application
c'est super important
parce qu'on travaille quand même avec des développeurs
c'est quand même notre cible
et notre utilisateur
et un développeur informé de ce qui se passe
c'est quand même un développeur content
et qui code vachement mieux
donc on va pouvoir aussi utiliser
ces mêmes codes de retour
mais cette fois-ci pour informer quand tout se passe bien
et c'est cool
parce qu'il n'y a pas que le code de retour
HTTP 200
il y en a d'autres
et si vous regardez bien, par exemple
I'm a te pot
je suis un petit pote
par exemple il y a le 201
pour dire created
par exemple je crée une réservation
dans mon application de parking
et mon API va me retourner
201, j'ai bien créé
ta réservation, elle a été enregistrée
plutôt qu'à un simple et bête 200
ok tout va bien
l'idée
on l'a dit tout à l'heure
c'est de gérer aussi l'idempotence
et donc par exemple
on veut qu'une réservation
sur laquelle on a exécuté
deux fois l'opération de réservation
ça pose pas de problème
la première fois il n'a pas reçu le retour
parce qu'il y avait un problème réseau
il était avec son mobile et il n'a pas bien capté
ça n'a pas été reçu
il va appuyer une deuxième fois sur le bouton
on va lui dire ok c'est bon ta réservation
elle a déjà été créée
et pour cela, pour utiliser un autre code de retour
que je n'ai pas regardé
alors cela pour les lectures c'est facile
on ne touche pas aux ressources
pour les écrits, ça peut amener
à des problèmes de
de codes
je ne suis pas un grand spécialiste du code
mais il va falloir triquer un peu
et faire des choses intelligentes
voilà
on verra ça juste après
au niveau de la gestion de l'authentification
c'est important l'authentification
si on veut rester state-less
on ne va pas pouvoir
utiliser certaines méthodologies d'authentification
donc il y a 2
il y a 3 écoles qui vont exister
vous êtes sur un réseau privé
vous n'avez pas besoin de vous embêter plus que ça
vous faites de l'HTTP
de la simple authentification au vers Http
le gain de mode passe passée dans les Header
en codé en base 64
je ne suis pas exact
non
c'est du bien
pas un HTTPS
HTTPS
c'est un HTTPS
si tu décides que sur ton réseau perso
tu fais ce que tu veux
il y a d'authentification simple
ça reste peu possible
cela dit, quand on est sur un réseau public
on va préférer 2 autres solutions
qui vont être
l'authentification sur token
c'est à dire qu'on va
introduire dans notre API
une nouvelle action
qui va être s'authentifiée
et cette action là va prendre
comme paramètres
tout ce qu'il faut pour l'authentification
ça peut être plein de choses
la biometrie, des clés physiques
on s'en fiche
et va retourner
en réponse un token qui va pouvoir être réutilisé
l'avantage c'est que ce token là peut être expiré
il peut être annulé
on peut faire plein de choses avec
sans avoir besoin de manipuler le login
et le mode passé
pour les réseaux publics c'est ce qu'on va choisir
les autres trucs c'est du haut haute
donc là si vous vous managé des réseaux
par exemple les réseaux sociaux
Twitter, Google, Facebook et compagnie
GitHub aussi
vous allez devoir manipuler de l'autre
et là c'est très bien documenté à gauche à droite
c'est des choses qui sont possibles
petite recommandation ne recodez pas ça vous même
évidemment on est en 2018
on arrête de faire ce genre d'horreur
les petites astuces
le caching c'est très important
en général on se dit
on va se contenter de mettre du caching
tout bête, HTTP et ça va faire l'affaire
en fait non
reste propose
dans ces concepts
directement du caching sur la pays
pour éviter de faire du popo
avec ses clients
notamment on va utiliser
les headers HTTP qui sont cache control et itag
qui sont des headers standards
et ils sont faits pour ça
et ça marche vachement bien
par exemple en utilisant itag
ce qu'on va faire c'est qu'on va mettre
à l'intérieur quand le serveur
va répondre une ressource
il va mettre dans itag
une signature cryptographique
du contenu de cette réponse
et le client si jamais un jour
ou quelques minutes ou quelques heures
il a besoin de redemander cette ressource là
pour une raison X ou Y
il va dans sa requête
fournir l'itag de sa précédente version
et si le serveur
voit que la ressource n'a pas changé
il va simplement pas lui renvoyer la réponse
il va juste lui renvoyer un petit code de retour
qui est exactement fait pour ça
que j'ai dû noter qui est le A412
non c'est pas ça c'est la 304
note modified
et voilà et vous avez géré du caching
sans implémenter une brique de cache
et là c'est quand même magique
c'est du caching que t'es client
caching
bah non c'est le serveur
du caching dans la perte
c'est le serveur qui dit que t'as donné
oui mais d'accord
mais c'est le client qui a encore l'information
c'est le client qui stop l'état
en effet
donc ça c'est une méthode
ça marche vachement bien
donc toujours en prenant l'exemple
de notre parking
si on veut pas qu'il y ait
par exemple dans le même problème
si on
si on veut
je m'enbrouille un petit peu
je l'ai mis en cache la requête
ça purit rien à voir avec le cache
on va parler de locking
et d'opération
toujours dans l'exemple de notre parking
il reste plus qu'une place dans le parking
et on est deux à la vouloir
et on appuie en même temps
sur le bouton de notre petit téléphone
on dit comment
le téléphone multifonction
on a arrêté le malin phone
c'est fini
non multifonction
dire que c'était ordifon à 5 ans
l'ordifon
j'avais jamais entendu
donc au note parking
les deux personnes appuient en même temps
qu'est ce qui va se passer
on voudrait pas dire un l'un
tu vas l'avoir et un autre
et se retrouver bien embêté
qu'est ce qu'on fait
on va utiliser
toujours de l'optimistic locking
toujours basé sur ce
header itag
c'est à dire qu'avant
de réserver la ressource
on va la récupérer
sans hash
sa signature
et au moment de faire une modification
sur cette paix de ressources
on fournit la signature
le serveur va vérifier
que la signature correspond à la version actuelle
de la ressource
et si c'est pas le cas
il nous renvoie un 412
precondition failed
tu veux modifier une ressource
mais entre temps elle a changé
tout fait scamite
c'est ça
habile
c'est une espèce d'optimistic locking
tu te retrouves sans place de parking
et tu te retrouves sans place de parking
mais au moins tu le sais
et il y en a un des deux qui l'aura eu
forcément si la ressource a été modifiée
ça c'est pas mal
enfin on arrive au bout
pour moi l'ultime force du couple
rest plus http
c'est l'utilisation des media types
et du modèle hate os
ça veut dire
hypertexte
as the engine
for over
application service
il va pouvoir chercher
en gros c'est l'insertion
on parle plus de model gizon
on parle plus de ça
c'est vraiment à côté
en parallèle du body
on va insérer des liens hypertexte
pseudo hypertexte
pour fournir
des fonctionnalités supplémentaires
sur l'API
notamment on va
l'exemple le plus typique c'est la pagination
on se dit aujourd'hui j'ai un super exemple
avec consul
on liste les services ou le catalogue consul
il nous renvoie absolument tout
c'est bien c'est cool quand on a 200 services
quand on en a 20 000 ou plus
l'API elle morfle beaucoup
parce qu'en plus il y a des milliards de clients
qui tapent dedans donc c'est chiant
donc on voudrait bien la paginer
et typiquement
quand on a une vraie interface reste
ce qu'on va faire c'est qu'on va pas demander
aux clients de faire une liste
et de paginer lui-même comme un grand
c'est le serveur c'est l'API
qui va elle-même proposer les fonctionnalités de pagination
à l'intérieur de ses réponses
en fournissant des
de l'hypertexte et ça j'avoue
je le connaissais pas avant de commencer cette brique là
et je trouve ça vraiment sympa
le problème
c'est que ça break un petit peu la compatibilité
avec les parser gizons
standard et tout parce que
ou alors ça oblige de triquer sur le contenu du body
en insérant
des métadonnées
qui vont contenir les liens
et tout le contenu hyper média
et ensuite les résultats
qui sont attendus
tu peux pas utiliser des Header HTTP
parce que le contenu
peut être assez costaud
et je sais pas
à chercher, honnêtement
j'ai pas trouvé ça dans les exemples
généralement
donc grâce à ce choix d'architecture là
ça va permettre de remplir
des fonctionnalités qui normalement
sont gérées côté client
ou côté serveur
de manière un peu sale
en faisant des choses sales en listant tout
puis en faisant des re-roquettes
ou en implémentant des endpoints
de l'API
avec un page 2, page 3
enfin en gérant ça côté serveur
c'est pas très dangereux
et ça permet
de le faire
de manière assez élégante
et de gérer sans bombarder le serveur
de requêtes inutiles et sans aller coder
tout ça soit en côté client
soit côté API vous-même
donc on n'a plus d'opération inutile à faire
c'est moins coûteux
en termes de performance côté serveur
et il n'y a plus de code spécifique coté client
toujours un petit peu mais beaucoup moins
que si on avait à recoder une fonction de pagination
donc pour moi c'est ces nombreux traits là
qui permet de distinguer les bonnes APIs
et les moins bonnes
et puis voilà moi ce que je pense au final
c'est qu'une bonne API
c'est une API qui permet
naturellement de guider
les utilisateurs
d'une structure humainement compréhensible
tout simplement
Super
on va pas trop revenir dessus
juste peut-être pour ouvrir le cas
parce qu'il y en a quelqu'un qui a marré
qu'on le dise c'est clair
c'est que reste et plus maintenant
la seule API
mais regardez GraphQL
si jamais notamment vous avez des problèmes
de pagination ou des choses comme ça
regardez dans des contextes
ça peut être vraiment génial
beaucoup d'appellés
notamment quand on gère beaucoup de données
passent à du GraphQL
c'est QIP non plus parce qu'aujourd'hui
il y a GRPC et les similos
GRPC qui
qui prétendent
remplir ce nouveau format là
mais moi je...
c'est pas ta famille même d'applications
pour moi
GRPC c'est un truc qui est
un RPC
avec un interface
de definition language
donc en fait le principe c'est que tu définis
ton service dans un fichier
par exemple Protobuf pour GRPC
et tu génères du code
serveur et client pour encoder
décoder les messages que tu veux envoyer
via ce service là donc tu as un truc qui est très statique
et donc c'est généralement
applicable à de la communication
entre des services par exemple dans ton data center
ou dans ton infrastructure club
des services qui sont à toi
t'en as n différents ou alors des interfaces
genre container v, des trucs spécifiés etc
et c'est généralement pas des interfaces publics
alors qu'aujourd'hui
HTTP plus
ou moins reste ça dépend des gens
mais HTTP plus JSON
c'est la lingua franca du web
des applications
enfin des interfaces publics pardon je vais y arriver
GraphQL ça commence à remplacer
quelques interfaces publics
web
et ça remplacera pas reste non c'est ça
ça remplacera probablement pas reste
mais ça va fournir des autres moyens de récupérer des données
dans des cas où tu veux faire
probablement moins de
RPC à travers reste
et plus de lecture de données
vous avez défini 3 cas
c'est reste on va dire c'est à l'ancienne
quand il n'y avait pas de connexion
c'est de la petite donnée légère échanger
et c'est pour ça qu'ils utilisent les codes HTTP
pour éviter aussi que
de rebalancer la réponse complète aux clients
parce que pensez à votre téléphone en edge
vous serez content de récupérer la place de parking
sans avoir à la recharger entièrement si il y a d'autres infos
comme tu dis
GraphQL ça devient intéressant quand il y a beaucoup de données
à échanger
ce que reste fait très mal dans le sens où
reste c'est quand même de l'HTTP de base
donc ton server web il a une limite
et après il a tendance à
être crâde sur sa réponse quand ça devient trop gros
alors reste n'est pas complètement
oui mais normalement c'est sûr
TIKI HTTP
normalement c'est très lié
et après j'ai RPC et tout ce qui est
à une pointe à l'ancienne
je vais dire à l'ancienne mais c'est du lourd
tu fais ce que tu veux
là tu balanges la quantité de données
mais tu es sûr du très tippé
au Windows Communication Foundation
tous ces trucs là qu'on a tous connu
donc c'est des besoins différents
et là où une API REST
elle est très simple à mettre en place
très légère, très standardisée vu qu'elle
se passe sur HTTP
c'est en tout ce que disait Bart
et on va arrêter là c'est que
ok c'est très standardisé
ok c'est très simple
pourtant d'expérience
j'ai quasiment jamais vu une API REST
à chaque fois les codes
sont tout pourris
à chaque fois le versioning
à chaque fois
il y a toujours un regard et compte en plus
on dit non l'API REST ça devrait faire ainsi
parce que c'est comme ça que c'était défini en vrai
très souvent les API REST ne sont pas cachables
elles sont pas tout ça etc
faut le redire parce qu'on a des exemples
quotidien de gens qui font de l'open API
voilà les définitions
de la description d'API REST
et au final c'est inexploitable
au possible, on ne peut pas générer
du code avec, la description
elle est malment enlée
le temps va me passer
le boulot reste à boulot
j'ai bien décoté obscur du GRPC
voilà
faut le redire parce qu'il n'y a pas juste
faire une URL et obtenir un JSON
l'API REST ça va beaucoup plus loin
et tout ce qui font du reste les invite
vraiment à ce procédé
la fondation de sa chronique c'est ça que j'attendais
pourquoi il l'achète
maintenant on va passer à quelque chose de complètement différent
on passe dans l'instant
WTF de la fin du podcast
on va parler de choses un peu moins techniques
mais toujours dans le sujet
on va en débattre parce que c'est toujours dans le sujet
on va parler de SpaceX
qui a été annoncé comme étant
la première entreprise d'aéronautique
en ce moment
pas tant en termes de chiffres d'affaires
mais surtout en termes de nombre de lancements
en 2017 SpaceX a fait un nombre de lancements
qui est au-dessus d'Arienespace
qui était le leader précédemment
moi pourquoi j'ai choisi ce sujet là
c'est avant tout parce que
SpaceX est une société ultra récente
qui date de 2002
qui est venue avec des principes
assez novateurs dans ce secteur
c'est que quand on parlait à Agile
et j'en ai encore entendu parler
encore dans une boîte pas très longtemps
Agile c'est bien pour certains projets
mais quand c'est du lourd
on va en sortir la bonne vie ici
clenvé où on ne fait pas d'erreur
et on sort quelque chose à la fin
avec des jolies roadmap
SpaceX arrive avec un modèle
on a déjà parlé dans ce podcast là
avec une culture de l'échec
beaucoup plus importante
une culture de l'erreur
et moi donc ça on en a déjà parlé
donc je ne vais pas envie de plus revenir là-dessus
ce qui est mon point surtout
c'est que surtout elle est venue avec
ce qui a fait en tout cas à mon sens
le fait qu'il y a ce deuxième leader maintenant
c'est qu'elle est venue en révolution son secteur
c'est à dire que SpaceX
arrive en prenant
aussi bien ils ont pris des ingénieurs
venant d'un peu partout de la NASA
et de l'autre société
mais ils sont venus avec des concepts révolutionnaires
en tout cas pas tant révolutionnaires
mais différents de tout ce qu'ils avaient eu l'habitude de faire précédemment
nous par exemple
ils ont leur moteur qui sont en multifaisseau
comme on peut trouver sur des moteurs russes
comme ceux du lance Soyuz
on a une construction à plat
de la fusée
et montée sur le patir
alors que traditionnellement
aussi bien à la nasa que le SA
on fait toujours
des fusées en l'air
et on les pousse
et je trouve que en tout cas
SpaceX c'est un bon exemple
personnellement
de l'innovation qu'on peut mettre dans un secteur
on pensait pourtant que ça existait pas
et je pense à très prometteur
pour le reste de notre industrie
qui pourtant
sont cette plus agile
organisé finalement
je sais pas quel point ils sont
novateurs
probablement beaucoup
pour avoir fait autant
en si peu de temps
après d'un point de vue technologique
il a l'impression que globalement
ils ont
recrit beaucoup de choses
que d'autres gens avaient fait
ils ont simplement combiné les meilleurs
de pas mal de choses
avec quand même deux grosses innovations
qui leur permettent d'avoir
leurs lanceurs qui reviennent
sur des pas de
pas de tir
mais sur une plateforme en mer
pour leur récupérer
c'est assez impressionnant
mais
j'ai l'impression que
tu achètes un petit peu
le
département marketing
de Elon
Elon Musk
il va voyager en fait
non tu vas voyager ça je comprends
disons que je suis pas sûr que ce soit
non plus
de l'agilité
à proprement parler
ou alors peut-être oui alors échelle
je sais pas je vais le rejoindre
un petit peu sur les deux points
c'est à dire qu'en effet il y a une énorme réussite
ils sont
voilà ils sont pas là
ils ont pas le résultat en 2017 pour rien
cela dit il n'y a rien d'hyper innovant
d'un point de vue technologique sur le lanceur
sur deux points
je vais revenir dessus
mais la technologie du moteur
les ergols ils sont connus
les mélanges il n'y en a pas tant que ça
la technologie
il n'y a pas d'innovation d'un point de vue moteur
d'un point de vue des réservoirs
il n'y a pas d'innovation
le système d'étage il n'y a pas d'innovation
la distribution des statistiques
il n'y a pas d'innovation majeure
sauf le pilotage
en effet
le code qui est derrière
qui permet d'automatically atterrir
c'est du reste du GRPC
je ne sais pas du tout
le pilotage est énorme et l'autre innovation
c'est le marketing
c'est dingue la puissance de l'image
de la retransmission directe
du cool factor
qui arrive à générer au tour de ça
sachant que nous à chaque lanceur
on était jeunes on regardait le lanceur d'Aryan 5
à la télé sur France 2
ça arrivait une fois tous les 3 ans
c'était entre la foire du saucisson
il y a cette puissance marketing là
qui
je pense
est la distinction la plus grande
entre une entreprise privée
et une entreprise étatique
ou multi-étatique
le lancement des navettes spatiales
c'était encore plus que maintenant
avant le massacre
de Challenger
parce que je vais mettre massacre
parce qu'il faut lire un boutquin sur les erreurs raptures qui t'expliquent
très bien pourquoi ça a explosé
mais c'était encore plus que ça
c'était une boîte étatique
mais c'était il y a 40 ans
donc ça veut dire
que nous dans notre donut vivant
on a vu Arjen 5 qui explosait
en fin de vol
ils ont annulé le lancement
et tu vois sur le cool factor et c'est ça
j'ai l'impression de voir les mêmes débats
qu'on a eu sur Docker
où on disait les conteneurs ça existe déjà
mais n'ont rien
au final ils sont juste à
ils avaient le droit d'atterrir la fusée
ils amènent des trucs
ils amènent un produit
ils ont un produit
ils font du cinéma
ils font d'innovations
mais c'est très bien
ce qu'ils font c'est exactement ce que les entreprises privées
sont capables de faire en termes d'innovation
c'est-à-dire prendre des trucs
qui ne sont pas forcément mûres d'un point de vue industriel
en fabriquer un truc industriel
avec un risque qui est pseudo calculable
effectivement
pour l'industrie de l'espace
c'est là où c'est
la frontière entre
l'innovation publique et l'innovation privée la plus ténue
parce que ce fait ici qu'ils ont quand même
jeté du pognon
dans un potentiel gouffre
qui là ils vont en gagner c'est très bien pour eux
mais ils ont pris des normes de risque
mais ils ont quand même pris des risques calculables
ce que je veux dire c'est que tu vois ça
avec des yeux émerveillés de la Nouveau NASA des années 60
ça n'a rien à voir
quand ils ont lancé
en 1960 on va sur la Lune dans 10 ans
il n'y avait
rien
ils n'avaient pas
de capacité
à calculer
quoi que ce soit en termes de retour sur investissement
ou de machine
moi ce que je veux juste dire là
c'est pas une innovation
par exemple si on parle du concorde
c'était encore une innovation
purement publique
et qui était pourtant un gouffre financier
et pourtant ils savaient à peu près qu'ils allaient y arriver
en fait moi ce que je veux juste dire là
c'est qu'il y a un certain moment
d'histoire
mais qu'il y a soit de privé public pour moi
c'est pas tant le... parce qu'il y a plein de boîtes privées
et de grosses boîtes privées qui font rien
et qui ont pourtant... ils sont assis sur une mine d'or
et qui auraient pu faire une tonne de choses
je pense que on fait partie dans cette salle
tous 8 des boîtes qui sont comme ça
pour citer des grandes télécom
des grandes laventes en ligne
et des grandes lafubes
ils sont assis sur une mine d'or
mais une forme de maman
c'est même pas une question de privé public
c'était juste une question de vision
c'est qu'à un moment qu'on soit privé au public
il y avait des choses qui se faisaient
que ce soit le concor, challenger, etc
pendant 20 ans, suite à
on peut partir en politique, etc
mais suite à plein de mouvements philosophiques
néolibéraux
basés uniquement sur la prophétabilité
et sur la mesure de la profitabilité
on fait que on n'a rien fait
parce qu'en fait c'était beaucoup plus simple
d'avoir des entreprises
faiblesse, sans personne, sans humain
parce que c'est chiant agir des humains, ça fait grève
là, enfin avec Elon Musk
depuis tout petit
je rêvais de pouvoir aller
à Baïkonur, travailler sur le lance Soyuz
en fait c'est juste
une entreprise de gens émerveillés
et là je vais revenir à pourquoi l'iPhone
c'était une chose très importante
de ce qu'a dit Steve Jobs aux gens
qui ont fait l'iPhone
c'est fait un téléphone que tu voulais avoir dans la poche
et je pense que c'est ça surtout
ils ont pas fait une navette
qui pouvait avoir dans la poche
la navette, le truc on t'y serait fier
non, la navette c'était de la philanthropie au départ
c'était clairement de la philanthropie
le mec il avait de la tuine, l'espace elle faisait rêver
comme je dis, il avait un point
oui, il avait un point
il voulait gagner de l'argent, c'était 0 de la philanthropie
comme Tesla d'ailleurs
juste, enfin
je ne parle pas de la technologie
je ne parle pas de la technologie
je travaille chez Tesla
ou chez...
on peut prendre les retours
qu'il y a eu sur les employés de Tesla
c'est pas un manager bienvé
il n'y a pas ces écoles là
donc je n'irais pas dire que c'est une super boîte
c'est éthique, c'est super innovant
je pense qu'ils ont une vision
il y a la vision
qui est de foutre du rêve
dans l'espace et balancer des trucs à pas cher
mais derrière les mecs
je pense pas que...
je n'ai jamais parlé justement de management
j'ai juste dit que c'était possible
de faire une innovation là où on pensait
qu'on en ferait jamais
depuis qu'on est tout, il n'y avait pas quand même
si on pensait qu'on en ferait jamais
au contraire c'était même l'inverse
ce qui s'est passé c'est que quand la NASA
a massivement divest
l'espace globalement
et le développement de nouvelles fusées
typiquement de nouveaux lanceurs
c'est parce qu'en gros
effectivement c'est dans un dogme
où on s'est dit il faut que l'État arrête de faire des trucs
ce qui est aux États-Unis
pesait hyper loin dans l'année 80 et l'année 90
mais globalement
le plan c'était très clairement
la NASA arrête de faire ça
et des boîtes privées
vont se mettre à faire ça
parce que maintenant on n'est plus dans une zone
où c'est un moonshot
à soit 10 ans, soit 50 ans
personne peut le savoir
est-ce que ça coûtera 200 trillions
ou 20 milliards
ce qui était le cas en 1950
où il y avait
quand même
7 ou 8% du PIB américain
du budget fédéral américain
qui partait directement à fabriquer des fusées
aujourd'hui c'est 0,2%
donc
maintenant dans une ère où des boîtes privées
peuvent faire des calculs sur 5-10 ans
de rentabilité, de développement, de produit
pour l'espace
donc c'est logique que ce soit des entreprises privées
qui fassent ça aujourd'hui
et SpaceX
est la boîte
la plus normale qui soit
c'est pas les mêmes contextes
quand tu parles de la course à l'espace
qui a été, c'était un contexte de guerre
il faut pas oublier
il y avait deux mecs qui se tiraient de la bourre
les américains et les russes
et c'était à qui aurait le premier
pour avoir l'avantage stratégique
vous n'avez pas du tout le temps
moi je vais revenir sur ce qu'est-ce que la force de SpaceX
on s'en fout qu'il lance la fusée
c'est pas ça qui nous fait rêver
moi je peux vous dire, je pense que vous avez tous la même réaction
c'est quand vous voyez cette fusée rebondir
faire son petit retour là
pour se poser sur une plateforme au milieu de la mer
et tu dis le mec il y a un temps venu une fusée
dans l'espace, si on fait ça depuis 50 ans
là il vient de te la poser sur une plateforme
elle fait quoi, 10 mètres par 10 mètres
je lui bêtise, 20 mètres par 20 mètres
et le mec il te pose ça au milieu d'un point au milieu
sur la mer ça bouge
et c'est pareil, après c'est là où j'ai la différence
ceci entre la NASA, un espace et SpaceX
c'est la réalisation du lancement
il n'y a rien à voir entre le lancer et surtout le retour
je me rappelle, j'en ai vu un récemment
ça doit être début décembre ou autre
où il y a une rupture de faisceau et il y a un truc qui s'est mal passé
t'as l'avouce qui s'est mal passé
et tu entends la scène qui réagit en stress
et là tu vois la fusée d'un coup qui réapparaît à l'écran
et qui se pose tranquille comme une grande au milieu
où elle a juste 2 cm d'écart par rapport à sa cible
et là t'as des explosions de joie
où les mecs ils se sont dit on l'a peut-être perdu
et j'ai envie de dire c'est juste de l'émotion
et c'est ça aussi que SpaceX apporte
par rapport à l'espace
depuis ces 2 crashs au début
à rien de ça que tu regardes un lancement
tu les as tous vu
là t'as jamais le même lancement
t'as jamais l'améritage
c'est un film
le dernier sujet dont je vais parler
c'est clairement le complotisme
c'est un énorme truc
un complot là
non
je suis très à l'accord la terre est plate
SpaceX l'a montré
là en fait
à mon sens
je vais introduire ce sujet et je vais rebondir sur ce qui a été dit
donc c'est
pourquoi les théories du complot sont-elles attractives
c'est un article qui est sorti très récemment là dessus
parce qu'on s'aperçoit dans les dernières enquêtes
que au moins 80% des français
croient en une théorie du complot
je sais pas exactement ça
la meilleure c'est que
si on fait référence à l'enquête qui a été posée
c'est que ça a été titré effectivement
dans le type 80% des français
pense à au moins une croix
à au moins une théorie du complot
mais c'est que
il y a eu des études
des découpes d'articles
ce qui se veut dire que c'est la manière dont ça a été pensé
c'est qu'on soumet la possibilité
que une théorie complotiste
soit possible
et ça n'a pas eu tout la même valeur
non c'est vrai
mais ça veut quand même dire
que la théorie du complot
peut être possible, c'est à dire qu'elle est attirante
même intellectuellement
elle n'est pas complètement répulsante
c'est ça en fait le truc
c'est que quelque chose qui induit
un facteur externe
une explication simple à un problème
est très attirante pour le cerveau
et c'est justement ça après tout le reste de l'article
parle de ça
des raisons qui amènent à ce jugement là
là, je vais aller très vite
par exemple là sur le cas de SpaceX
ça va être
en fait c'est le marketing
c'est tellement simple
non c'est pas une théorie du complot
il y a un énorme effort fait sur le niveau de la vie
sans parler de savoir si c'est vrai ou pas
une théorie du complot c'est par exemple
on n'est pas allé sur la lune, ils ont fait un film là-dessus
genre SpaceX c'est du marketing
c'est pas une théorie du complot
parce qu'une théorie du complot
il y a une grande histoire
avec un grand H qui est vendu par les méchants
et moi qui suis un mec illuminé
j'ai eu la petite histoire H
petit H qui est la vraie histoire
en fait et qui est cachée par la grande histoire
des méchants
là quand moi je te dis
SpaceX c'est du marketing
je ne te dis pas
que quel contenant
je te dis
les étoiles que tu as dans les yeux
elles sont fabriquées de la même façon que tu as des étoiles dans les yeux
quand tu regardes Armageddon peut-être
j'en sais rien
je te fais de la psychologie pas de la théorie
mais justement, cette article là
parle un peu de ça
c'est quelque chose qui est très important
et là on va rebondir plus sur le milieu de devop
c'est le fait que
le cerveau humain a besoin de se sentir
unique
on a besoin d'avoir une explication simple
et aussi d'avoir
tu te sens comme
porteur d'une vérité
que les autres n'ont pas
les autres se laissent embrigader pas toi
et en fait c'est ça surtout
cette espionnicité et ça on l'a vu dans nos sociétés
très souvent on est passés
c'est arrivé au moment de Docker
c'est pour ça que j'ai rejoint Docker
quand il y avait une hype dans la Silicon Valley pour Docker
et bien combien de fois
on a entendu dans des conférences
dans des meet-ups
jamais en production et ça n'arrivera jamais
et je ne vise pas mon ancien directeur
de SRE
quand on dit ça
et donc c'est vraiment
ça qu'on a entendu tellement de fois
la volonté de se sentir unique
par rapport
au reste du monde
j'ai porte une valeur mais c'est quand même par exemple
nous qui sommes sur Android pendant très longtemps on a du bitcher sur Apple
on sait en Apple ils vendent des choses très chères
pour rien et je ne dis pas que
c'est pour ça que je reviens sur les 80%
c'est qu'en fait
Infinacy 80% on va dire les web paraîtos
à la rage c'est quasiment 100%
en fait nous tous
et nous tous même dans les entreprises
il y a un moment ou un autre on applique cette espèce
de théorie du complot facile
c'est en fait c'est pas exactement
c'est pas exactement ça
on peut avoir des raisonnements
qui sont qu'on les même ressort psychologique
que les théories du complot
c'est plutôt ça que tu veux dire
on a un besoin d'une idée
c'est pour ça que je revenais vers ça
donc effectivement là je suis d'accord avec toi
qu'on peut tirer d'à peu près de cette étude
qui encore une fois c'est
on demande aux gens est ce que d'après vous
il est possible que certaines théories du complot soient vraies
et il y en a 80% qui répondent oui
sans dire lesquelles
donc c'est juste globalement leur demander
est ce que vous pensez que c'est possible
que dans certains cas on vous mente comme ça
effectivement peut-être que ça sous-tend
enfin c'est ce que l'histoire raconte
que ça sous-tend un besoin d'unicité
et ce mécanisme là de besoin d'unicité
oui effectivement il y a l'œuvre
dans pas mal de choses
notamment les gens qui sont très réfractaires
à des hype technologiques
par exemple parce qu'ils disent chez nous
on fait pas comme ça
nous on fait pas du web
on fait du cloud
des choses dans genre là
ce n'est pas un acteur du cloud français
d'énergie cloud
c'est moi vous balancez des pics
depuis 5 minutes
on fait pas ce genre de trucs
pas chez le bon bref
mais voilà, faites attention à ça
et là c'est un point que j'avais retiré de mes vœux
mais que maintenant j'ai envie de vous dire
très souvent en fait quand on se voie
vous voyez qu'en plo ou malhonnêteté
souvent c'est qu'il n'y a qu'ignorance
l'ignorance aussi bien sur les gens en face
que de vous même
n'oubliez quasiment jamais ça
quand vous voyez qu'en plo il y a ignorance
et par contre
et là je porte un t-shirt qui le dit très bien
et voilà
c'est l'ignorance et la pierre des choses
à combattre
c'est une galgie
enfin c'est tellement compliqué
qu'on pourrait en faire une émission complète une prochaine fois
si tu veux
cet homme fait de la voix et parle de son t-shirt
c'est ça
théorie du complot jusqu'au bout
voilà
on va en finir là
on va peut-être faire un dernier tournoitage
juste pour ce que vous avez une actualité
tout en chacun
est-ce que vous avez quelque chose très vite
c'est vos derniers mots
rejoignez-nous sur Meetup
on essaiera de communiquer un peu plus
on est gentils
si vous êtes à côté
n'hésitez pas
à venir nous voir
et vous envoyez les messages
on pourra peut-être réorganiser
un enregistrement
chez le Mont-Coin
on aura de la place
tu travailles chez le Mont-Coin
et ça serait toi qui nous invite
moi ou Victor
dans un futur proche
merci beaucoup à tous
et on vous souhaite un bon début d'année
bon skis
si vous allez au ski
je vais au ski la semaine prochaine
je vais faire les placements
de réveiller vacances
on se retrouve la prochaine fois
commenter
réagissez
on a aussi besoin d'aide
des fois techniquement
on a un tout un sujet de flu-rss
pour la diffusion des podcasts
pour aller sur iTunes, Deezer
on aimerait faire un truc assez hype
si jamais vous n'avez pas envie d'intervenir
mais juste travailler techniquement
on a même des sujets techniques
si tu sais gérer des API qui nous intéressent
bisous
à bientôt