C'est d'abord une culture. Quand on est en DevOps, on prend tout le monde.
DevOps et agile font effectivement partie de la même famille.
Sa virtualisation applicative, c'est très bien.
Aujourd'hui, ça nous prend 10 minutes et un café.
Ce n'est ni être dev, ni être DevOps. C'est avant tout de la communication.
Ce mouvement DevOps, c'est tout simplement drivé par la communauté et endorsé par les entreprises.
J'ai adopté une démarche DevOps.
Le développement agile, on a accéléré des poignements.
Ça amène une clarté sur le travail de...
Être dans une démarche d'amélioration contient votre trou face à des...
Ça, oui, naturellement ensemble, ça donne des résultats contrêts.
DevOps.
L'objectif individuel, ça s'atteint.
Alors qu'une ambition, ça se partage.
Bonjour à tous et à toutes et bienvenue dans un nouveau numéro de DevOps.
Alors aujourd'hui, nous allons parler de la dette technique.
Et pour ça, on accueille Julien.
Bonjour.
Alors, et Xavier également qui m'accompagne.
Alors Xavier, vous le connaissez un peu plus.
Bonjour.
Alors Julien, si tu peux te présenter un peu pour les auditeurs.
Oui, parce que déjà merci de me recevoir sur le podcast.
Donc en fait, je suis français.
Je vis aux États-Unis.
Je me suis expatrié maintenant depuis...
Je suis parti de France en 2010 pour aller vivre au Pays-Bas.
Avant, je suis originaire de Normandie.
J'ai fait une thèse à Telecom Paris.
Avant, ça s'est pris lieu en ST.
Et puis aussi à Paris-6.
J'ai travaillé à l'Agence spatiale européenne.
Ou justement, j'ai pu voir des systèmes qui étaient designés.
Enfin, ils ont pris depuis plusieurs dizaines d'années.
C'était très intéressant.
Ça m'a exposé d'abord à toute cette problématique de technique hold up,
de maintenir le logiciel pour des années.
Enfin, si on réfléchit, en fait, il y a quelque chose qui est assez amusant.
C'est que le logiciel qui est pris pour des avions en général,
les gens qui le maintiennent, ils n'étaient pas nés quand le logiciel était pris.
C'est quand même assez marrant comme fait quand même.
Et en général, on n'a pas cette perspective
quand on commence à écrire un logiciel
un samedi soir en ouvrant IntelliJ.
Et puis après, en fait, je suis allé à Carnegie Mellon,
bossé pour le Software Engineering Institute,
qui est un institut de recherche
pour tout ce qui est logiciel, pour le gouvernement américain.
Et là, j'étais aussi exposé à beaucoup de problématiques
sur le logiciel embarquée.
En fait, à l'époque, j'étais vraiment très spécialisé
en marqué et tout ce qui est le code, c'est plus, plus.
Après, en fait, j'étais embauché chez Amazon,
chez Amazon Web Services,
où je m'occupais de l'infrastructure chez EBS,
donc Electric Block Storage,
ce qui m'a vraiment exposé à tous ces problèmes
de toutes les problématiques de scale,
de déployer des services sur des milliers de serveurs,
voir beaucoup plus.
Puis, je suis parti en Californie et je suis allé chez Twitter.
Donc en fait, chez Twitter, c'est assez marrant,
parce que c'est une boîte qui maintenant est là
depuis à peu près entre 10 et 15 ans.
Et en fait, ils ont eu des énormes problématiques,
parce qu'au début, c'était une start-up.
Donc en fait, Twitter, à la bocke,
c'était une application Rubian Race.
Puis au niveau du scale, ça a plus marché.
Alors bon, je pourrais peut-être parler un peu de ça
pendant le podcast,
parce qu'en fait, il y a un historique de deep-technique
et comment ils ont réussi à changer le système,
de passer de Rubian Race et MySQL
à des micro-services en Scala et Java.
Mais en fait, tout cet âme-là, ce qui est intéressant,
c'est qu'en fait, à chaque fois, j'ai vu tous les problèmes,
et en fait, les gens qui se heurtaient,
surtout ce qui est deep-technique.
En fait, je me dis que c'était un problème
qui était assez important.
Et en fait, on voit que toutes les boîtes
dans la Silicon Valley, ils ont ces problèmes-là.
On voit Stripe en 2018, ils ont fait un rapport
en disant que 20% du temps de développeurs,
c'est consacré au mauvais code, au bad code.
En fait, 20% dans la Silicon Valley,
quand les gens, ils sont payés entre 300 000 et 500 000 $ par an,
ça coûte cher.
Donc je me suis dit, pourquoi pas proposer des solutions
pour résoudre ça.
Et puis j'ai commencé une startup,
donc une boîte qui s'appelle Core Inspector.
Et puis, en fait, j'ai décidé de me dédier
à plein temps sur cette startup-là.
J'ai été sélectionné pour Techstar Boulder,
qui est un accélérateur de startups assez connu aux États-Unis.
Donc voilà, maintenant, aujourd'hui,
sur quoi je me focalise,
essayer d'avoir des solutions pour aider les entreprises
à réduire leur date technique.
Donc les auditeurs pourront aller sur Core Inspector.com.
On est sur le GitHub Marketplace et le Bitbucket Marketplace,
et puis ça va choisir sur GitHub.
Donc n'hésitez pas à essayer.
Voilà pour l'introduction, que peut-être un peu longue.
Non mais qui est complète, on va dire.
Xavier, présente-toi, mais bon, là pour le coup,
on te connaît un peu plus
que ça t'a été dans beaucoup d'autres podcasts.
Oui, alors moi, beaucoup plus simplement,
je suis DevOps SRE pour une boîte qui s'appelle Virtuo.
Et en fait, c'est de la location de voiture
entièrement dématalisée avec votre mobile.
Location, ça, c'est classique,
mais ouverture, démarrage, tout à travers le mobile.
Et puis vous pouvez écouter les autres podcasts
pour savoir par où il est passé avant.
Il est passé par...
Beaucoup d'autres sociétés.
Voilà, et donc moi, Guillem,
toujours indépendant, DevOps SRE,
surtout spécialisé sur Kubernetes en ce moment,
mais bon, l'infra-en-règle général.
Et sur les logiques ordinationnelles, là-dessus,
je pense qu'on en discutera,
il y a beaucoup de choses cool à faire et à parler.
Bah, t'as commencé déjà un peu
en donnant des exemples en fait
de ce que toi, tu définissais comme des techniques, Julien.
Mais comment tu le définirais concrètement,
si jamais on te demandait
ce que c'était que la détechnique,
comment tu la définirais ?
Oui, je pense que la définition,
enfin, la définition de la base de World Cunningham,
elle est quand même assez bien.
C'est-à-dire qu'en fait,
la métaphore avec le monde de la finance est là,
c'est-à-dire que,
parfois, il faut chipper quelque chose assez rapidement.
Donc voilà, par exemple, on doit chipper Feature X,
on n'a pas le temps,
et en fait, on n'a pas le temps d'écrire les tests,
on n'a pas le temps de tester complètement.
Là, il faudrait mettre à jour la librairie.
Là, peut-être qu'il faudrait faire un process de CI-CD
qui soit bien et complet,
avec une bonne stack d'observabilité
pour voir qu'il n'y a pas de problème,
et parfois, on n'a pas le temps de faire ça.
Alors bon, quand on n'a pas le temps,
on se dit, bon, ok,
on ne va pas le faire,
et on va chipper la Feature,
mais derrière, on se dit que
on a cours circuitar un peu le bon process de la engineering,
et puis en fait, il faudrait plus tard
faire le travail qui manque.
Le problème, c'est qu'aujourd'hui,
d'une, on ne voit pas qu'on a introduit des problèmes.
On est aveugle sur ces problèmes-là.
Et puis, en général, on est assez paresseux,
et on ne va pas vraiment régler le problème.
En fait, ça s'accumule.
En fait, c'est comme la dette.
C'est-à-dire qu'en fait,
si on prend de l'argent encore et encore,
en fait, les intérêts vont s'accumuler.
Et à un moment, je ne peux même plus payer les intérêts.
Et en fait, la métaphore d'un point de vue technique,
c'est que j'ai pris tellement de raccourcis
qu'en fait, il y a tellement de problèmes qui vont arriver
que ça va me ralentir énormément,
parce que je vais avoir des problèmes.
Mon système va se déployer,
et puis malheureusement, il ne va pas se lancer.
Je vais avoir plus de latence.
Ah, cette nouvelle librairie,
qui me donne une nouvelle fonctionnalité.
Ah, je ne peux pas l'utiliser, cette nouvelle version,
parce que si je la mets à jour,
je dois remplacer des nouveaux appels de fonction.
Donc du coup, je vais prendre un raccourci
et je vais faire un hack
pour essayer de hacker la version actuelle de la librairie.
Il y a plein de choses qui arrivent aujourd'hui
et qui ralentissent les gens.
Et on le voit très bien.
Il y a des boîtes qui ont été impactées par ça.
L'exemple, c'était Twitter au début.
En fait, Twitter, quand ça arrivait au tout début,
c'était une application en race, mais ici, cool.
On sait très bien que ça se cale pas trop bien.
Et puis en fait, du coup, comme ça se cale pas trop bien,
il y avait quelque chose qui était la fail-away.
En fait, si vous vous rappelez vraiment au tout début de Twitter,
quand le service, il avait des problèmes,
on mettait une baleine qui était portée par des oiseaux.
Parce qu'en fait, le service, il n'avait pas la capacité
de supporter la charge.
La licorne de Github.
C'est ça.
J'ai jamais eu la licorne de Github.
Il y a un joueur.
Je vous en ai entière des fois, on donne.
Mais après, ce n'est pas pour des problèmes de détechnique.
Ça, pour le coup, on ne peut pas savoir.
Le point que tu as donné, c'est une question que je dois avoir.
Est-ce que la détechnique est forcément une volonté ?
Là, tu disais qu'on prend des raccourcis,
on fait des choses comme ça.
Est-ce que la création de détechnique est forcément due
à quelque chose de conscient ?
On sait qu'on crée de la détechnique,
et juste après, on n'arrive plus,
ou potentiellement, quelqu'un aurait l'addition une fois,
et après, elle est oubliée.
Ou est-ce que la détechnique est même cachée ?
Ce qui serait l'inverse
dans le contexte économique,
parce que dans le contexte économique, tu as un chiffre.
Une maîtrise qui te donne ta dette
à un moment d'être un pays, d'un foyer,
ou d'une entreprise.
C'est une très bonne question.
C'est une excellente question.
Parce qu'en fait,
il y a la dette dont tu es conscient.
C'est-à-dire, tu vas prendre un raccourci,
tu vas dire, je suis conscient de ça,
et je sais que je dois repayer ça plus tard.
Donc déjà, si tu as à ce niveau-là, t'es bien.
Parce que au moins, t'es conscient du problème.
Il y a des gens qui ne sont même pas conscients.
Ils ne savent même pas...
Ils ne vont même pas suivre,
ils ne vont même pas se dire,
plus tard, il faut que je la repaye.
Et puis tu as la dette
qui crée au fur et à mesure.
Un exemple,
c'est, je déploie toujours
mon logiciel
à la main
avec des scripts
sur ma machine.
On sait très bien que ça va créer des problèmes.
On sait très bien que ça,
ce n'est pas une manière de déployer ton logiciel.
Alors après, ça dépend
dans quel environnement tu peux utiliser
un peu pète
ou après, tu peux utiliser
des services dans le club pour déployer.
Mais ça, c'est une dette qui va se créer au fur et à mesure.
Parce que des nouvelles technologies
qui vont émerger et qui vont t'aider
à avoir un meilleur processus.
Donc il y a la dette que
justement, il y a une nouvelle technologie,
il faut que tu les adoptes.
On le sait très bien quand tu poses dans la formatique,
il faut que tu continues
à te former.
Et tu as cette dette qui va être créée au fur et à mesure.
Et là, il faut que les gens
soient... enfin, il faut que les gens
se forment et se concorrent.
Ce qu'on essaie de faire, alors, un des trucs
que je vais essayer de faire
sur la plateforme là qu'on a, c'est d'avoir un score.
C'est-à-dire, tu mets ton projet
et on va te dire, bon, là,
ton projet, il est bien ou il n'est pas bien.
Parce que tu as t'est l'erreur
ou t'es l'erreur ou t'es l'erreur.
Avec, ça dépend, tu vois,
tu as des sévérités sur les problèmes.
Par exemple, si tu mets une clé RSA
dans ton code source,
bon, normalement,
tu devrais pas faire ça. On est d'accord.
Et ça, c'est quelque chose
de très haute sévérité.
Si tu es oublié un point de verdu
à la fin
d'un langage qui,
du code, d'un langage qui ne te demande
pas d'avoir point en point de verdu,
ça, c'est même pas compté dans ta, comme date technique.
Donc, en fait, il y a vraiment plusieurs niveaux
de dette.
Mais encore une fois, si tu mets
ta clé RSA dans ton code source,
une des questions vraiment
qu'il faut se poser, c'est à ce que les gens, ils sont conscients du problème.
Une chose qui nous...
que je reviens par rapport à beaucoup de podcasts
qu'on a eus sur DevOps,
souvent, par exemple, on a...
Je prends d'un exemple précis, on a parlé
du 12-factor, donc le 12-factor app.
C'est donc une standardisation, on va dire,
assez très haut niveau des applications
en édictant des sortes de règles,
12 règles pour avoir
une application à peu près
claudifiable, on va dire.
Et en fait, moi, je me suis aperçu très souvent,
c'est que quand on... après, on parlait
d'Occure, quand on parlait
d'applications comme ça, c'était
extrêmement compliqué de passer des applications
à Docker, parce que ces applications-là
n'étaient même pas dès le début
en 12-factor, donc en fait, elles étaient déjà
difficilement déployables avec du chef et du pipette
et de l'automatisation, et etc.
Et en fait, comment ça
t'arriverait à modéliser, moi pour moi
en tout cas, je considère ça comme une dette,
c'est à dire que je n'avais pas fait l'effort
de passer en application à du 12-factor,
j'avais réussi en y allant très très fort
à le faire passer dans du pipette, mais après,
insentiellement, quand là, Docker arrive
et se base sur des pré-requites d'avant,
et bien tout peut être...
Est-ce que la dette, justement, elle est pas liée aussi
tu as un peu évoqué,
à la voie que l'informatique prend et que
c'est dur à dire, mais
moi, ce que je vois comme information, c'est que
la voie de l'informatique, elle est unique, il n'y a pas
d'endroit dans le monde où l'informatique
a pris une autre voie, il n'y a qu'une seule voie.
Tout le monde se bataille
à un moment donné pour essayer de forger
cette voie-là, mais il n'y a pas
un informatique inverse,
ou une informatique parallèle, ça a pu
exister au monde l'URSS, où les gars avaient
des processeurs à eux, des langages à eux,
mais à l'heure actuelle, ça n'existe pas.
Est-ce que justement, la dette, c'est pas de ne pas
aller vers cette voie-là, d'essayer de créer
celle-ci ? T'es vraiment d'accord qu'il n'y a qu'une seule voie ?
Alors actuellement,
il y a soit des voies qui sont restées
dans le passé,
c'est ce que tu parlais un peu dans
la vie unique, mais en fait,
ces gens-là essayent de basculer, moi par exemple,
j'ai travaillé avec des gens dans la vie unique
pour mettre des Kubernetes embarqués dans les avions
pour faire en sorte de gérer tout le logiciel
de bord, alors le logiciel
client, donc tout ce qui est
film, etc. Parce qu'en fait,
tous leurs informatiques, mais qui avaient
continué d'effaire évolué, vraiment, étaient
compliquées. On a au CEA par exemple,
où en fait, on va avoir des librairies
qui sont totalement en forteran,
ou dans des technologies comme ça, mais en fait,
ok, ils ont créé leur voie en forteran,
mais en fait, ils voient que c'est une dead-end,
c'est... En fait, justement,
est-ce que la dette, c'est pas le moment où tu essayes
de prendre une voie parallèle,
et en fait, t'as pas amené les gens avec toi ?
Non, je pense pas. Alors déjà,
je pense pas que tu es qu'une seule voie.
Je pense vraiment pas ça. Est-ce que tu as un exemple
de plusieurs voies différentes, vraiment,
des voies
qui ne se sont... Qui ne confèrent pas,
enfin, vraiment, qui sont
deux mondes complètement séparées ?
Ben, ça dépend. Avec des pratiques différentes
qui ont des impacts différents.
Oui, mais ça dépend quels sont les dimensions
des voies, comment tu caractérises une voie.
Je veux dire, t'as toujours des mondes, par exemple,
t'as toujours le monde Windows versus Linux,
malgré qu'en fait,
aujourd'hui, bon, aujourd'hui, on essaye
de mettre...
Oui, mais tu vois, justement, la voie Windows
était une voie de dette qui est maintenant
en train de revenir, et je pense que les gars du kernel,
il y avait comme ça des interviews, des gars qui bossaient
sur le kernel Windows, et qui disaient que le kernel Windows
est une dette. Les gars n'arrivent plus à faire
un système de fichiers. Il y avait WinFS
qui sont aussi créés pendant des années,
ils n'ont jamais réussi. Mais en fait, les gars savent
que leur kernel est une dette, et c'est pour ça qu'ils essayent
d'aller vers Linux, au fur et à mesure,
pour essayer d'amener les choses. Donc, non, justement,
il n'y avait qu'une voie, c'est la voie Linux, elle a mis du temps
à s'imposer, mais elle est là, et donc Windows
est devenu une dette. Ok, un autre exemple.
Les textes qui ont un logiciel qui est pour que ce soit Windows.
Un autre exemple, les langages. Est-ce qu'aujourd'hui,
il n'y a qu'un seul langage ? Est-ce qu'il n'y a qu'une seule voie
pour faire un logiciel ? Non.
Non, mais il y en a certains qui sont une
dette. Si jamais demain, tu te dis...
Voilà, c'est une question d'ailleurs que j'ai pour toi.
Est-ce que si jamais demain je me lance à faire un logiciel
en PHP, est-ce que j'ai fait de la dette ?
Je me lance aujourd'hui,
avec toutes les compétences du monde,
elle lancé à faire du PHP, est-ce que je fais de la dette ?
Non, ça dépend. Ça dépend
de ton... Ça va dépendre
de tes besoins, ça dépend
de ce que tu veux. Aujourd'hui, si tu déploies
sur AWS par rapport à GCP, est-ce que tu vas faire
de la dette, tu vas sur AWS ? Non.
Après, on sait très bien qu'il y a des méthodes qui sont
meilleures que d'autres. Par exemple, tu ne vas pas
faire un système de contrôle avionique avec du PHP.
Tu vois ? Par contre, tu vas faire un web service
avec du PHP. On est d'accord.
Enfin, ou...
ou... ou piton.
Je suis pas... enfin...
Je sais pas si je suis d'accord. Mais si PHP
c'est le serveur less avant l'heure, les gars. Non mais... Alors,
en effet, il y a un système de stress dans PHP
qui peut être assez cool quand on fait du serveur less.
Mais en vrai, non, parce qu'en fait, tout
l'écosystème, il est merdique. Tout le système de
packaging de PHP est merdique. Donc, en fait,
c'est en soi une dette, pas...
parce qu'en fait, juste cet écosystème-là n'a pas
évolué dans le même temps. Il n'y a pas de système
de packaging qui digne de ce nom. Il n'y a pas de
système d'installation. Il n'y a pas de système... Il y a beaucoup
chaud. Il n'y a pas de librairie HTTP dans le langage
qui marche bien. Ok. Le langage, il faut décourir
le langage du système de packaging.
Parce que tu peux... Bah, en fait, non. C'est justement
c'est ça, en fait. Tu parles d'écosystèmes, en fait.
Moi, je parle d'écosystèmes souvent, en fait. Et c'est vrai
que j'ai dit PHP et j'ai fait un abus de langage.
Et c'est bien que tu me le...
C'est un peu plus grand.
Mais c'est pas un peu plus grand.

Mais c'est pas un peu plus grand.

Mais c'est pas un peu plus grand.



Mais c'est pas un peu plus grand.
Mais c'est pas un peu plus grand.
Mais c'est pas un peu plus grand.
Mais c'est pas un peu plus grand.
Mais c'est pas un peu plus grand.
Mais c'est vrai, les gens me disent que le site est génial.
C'est juste que si il peut pas tourner sur un truc qui est déployable...
Ouais, mais...-Ce qui fera...-Mais j'étais en mode...
Ouais. Mais le truc, c'est que le software que tu vas faire aujourd'hui
va potentiellement être une dette demain.
Après, le truc que tu vas faire, c'est que tu vas essayer
de regarder les différentes écosystèmes et se dire
que ça, ça fait sens ou pas.
Par exemple, aujourd'hui
si...
Si je commence à faire un web service,
je suis pas un spécialiste PHP.
Pour être vraiment honnête.
J'ai fait du PHP dans...
Il y a peut-être 20 ans.
En scolarité, il y a très longtemps.
Il y a très longtemps quand PHP MySQL était vraiment connu.
Mais aujourd'hui, je prendrai sûrement Python.
Enfin, je suis un gros fan de tout ce qui est functional programming.
Donc peut-être que je prendrai Scala parce que vraiment, j'adore Scala.
Mais je prendrai Python.
Pourquoi Python ?
Parce que Python, aujourd'hui, tu as un support énorme.
Tu as des librais qui sont très bien faites, très bien codés.
Tu as un écosystème open source qui est génial.
C'est très facile d'aider et de donner ton application via Docker en Python.
Donc je choisirai Python.
Après, peut-être que le choix de Python, ce sera un mauvais choix pour demain.
Je ne sais pas.
Mais par contre, il faut que je reste conscient de ce choix-là.
Il faut que je regarde les dépendances, si elles sont mises à jour,
si les bugs de sécurité sont corrigées, c'est plus simple.
C'est ça en fait que j'essayais d'amener un temps un peu trop l'esqu'.
Enfin, encore je ne fais tout trop l'esqu' je le pense vraiment.
C'est la notion de dette multifactorielle,
qui est que la chose bien d'un et peut-être la dette d'un autre dans une entreprise.
Alors quand tu es tout seul et que tu fais tout, c'est choi-là que tu peux les faire.
Tu te rends compte qu'en fait, tu commences à faire ton petit bout de code,
tu le déploies et tu t'aperçois qu'il n'y a rien qui marche, que tu n'y arrives pas du tout.
Là où dans des boîtes, moi, ça m'est déjà arrivé d'avoir des développeurs
qui étaient sur leur visuel studio à faire du .NET parce qu'ils n'avaient fait que du .NET en école.
Et puis le jour de déployer, il me faut en tenir, voilà le soft.
Et eux, le chef, il est génial, ils avaient du test unitaire partout.
Partout leur test unitaire, il était couverture de test, gigantesque.
Toutes les livrées étaient à jour, toutes les livrées étaient bien.
Mais alors justement, dans le bouquin qu'on est pris,
alors ouais, j'en ai pas trop parlé en fait,
j'ai parlé beaucoup de la startup que je fais, pas du bouquin.
On a écrit un bouquin qui s'appelle Technical Depth in Practice
avec deux anciens collègues de Cardin Guimelan.
Et en fait, on est pris qu'une des facteurs majeurs de depth, c'est le management.
Parce qu'en fait là, là en fait, enfin, de toute façon,
un des messages, peut-être le message principal du bouquin,
c'est la manière, la meilleure manière de gérer de la dette,
c'est la culture de la boîte.
En fait, si t'as pas, si le CTO, même le CEO, ils sont pas au courant,
ils sont pas conscients de ce problème-là, t'es mort.
Parce qu'en fait là, ce que tu m'expliques, c'est que t'avais aucune communication,
t'avais un silo de communication entre les devs et les ops.
Mais comment ça peut marcher ?
Enfin, moi, il faut m'expliquer quoi.
C'est, je veux dire, c'est exactement comme si quelqu'un aujourd'hui,
il produit une voiture et puis il met la voiture dans le showroom
et puis Dieu se vise à un volant et quatre roues.
Non, t'as besoin de plus, t'as besoin de savoir,
bah, la voiture, elle est électrique.
Ouais, elle a de l'autopilot.
Ouais, elle fait 0 à 100 en deux secondes.
C'est enfin, il faut que tu aies de la communication
entre les différents éléments de la boîte.
Et là, ça semble un mage, enfin,
toi, ce manque de communication,
nous, on appelle ça le management depth dans le bouquin
et t'as plusieurs aspects par rapport à ça.
Le silo aussi bien entre équipe de développement
ou entre les ops et développeurs.
Après, t'as un grand débat.
Alors, t'as un grand débat dans la communauté des logiciels
où en fait, je ne sais pas, je pense que c'est un peu un non-débat.
Le débat, c'est, est-ce qu'on doit avoir des gens ?
Est-ce qu'on doit avoir une équipe ops et une équipe dev
ou est-ce qu'on doit avoir un job qui s'appelle DevOps ?
Ah, le fameux.
Alors, mais ça, si tu veux, je pense que c'est un non-débat, en fait.
Parce qu'en fait, tu peux, ça, c'est un non-débat,
parce qu'en fait, tu peux régler le problème de plein de manière
que ce soit, mais peu importe ce qui arrive,
il faut que tu aies une communication entre ces personnes-là.
Si tu n'as pas de communication, c'est mort.
Parce que, par exemple, un cas très simple.
Aujourd'hui, le développeur, il veut déployer son application.
Si jamais l'ops, enfin, la personne qui déploie
et qui opère l'infrastructure ne sait pas les limites du soft,
si tu as une application Java, par exemple,
tu dois monitor et t'as de GVM, qu'est-ce que tu dois attendre ?
Quelles sont les latences que tu as ?
Si tu communiques pas ça, tu vas dans le mur.
Enfin, tu vois.
Concrètement, enfin, complètement.
Et là, dans les causes de dette,
donc là, on a évoqué un peu des causes techniques,
en fait, de choix, de rapidité, comme ça.
Justement, quand t'analyse les causes,
donc il y a des causes originationnelles, des causes de rapidité,
c'est quoi un peu les grands thèmes que tu as réussi à sortir là-dedans
de causes de dette ou ce que tu as pu voir ?
Les causes de dette.
Donc en fait, nous, on a catégorisé, dans le bouquin,
on a catégorisé les dettes en plusieurs catégories.
Donc en fait, il y a,
alors déjà, il y a une catégorie de dette qui est les réquis amènes, les exigences.
Tu sais, tu sais, quelqu'un veut dire,
ah, le logiciel doit faire A.
Alors tu fais A, tu implementes A,
puis après, il revient, il fait,
ah non, mais ça doit aussi faire B.
Puis tu te dis, attends, tu te moques de moi là,
donc tu reviens et puis tu dois modifier le sauvage.
Donc ça, c'est,
en France, on appelle ça le KADCharge, le truc comme ça.
Bon, nous, on a appelé ça le Requirement Dept.
Après, tu as l'implémentation, c'est le code.
Alors là, on est tous familier avec ça.
Tu vois, tu as le code, bon, alors tu dois faire de la bonne qualité et tout,
mais aussi, tu as les dépendances.
Tu regardes les dépendances que tu vas avoir
et puis les problèmes de sécurité que tu vas avoir.
Si tu déploies ton système avec un OS qui est de vieux de deux ans
et puis si tu as des failles sur le SPA OpenSSL ou quelque chose comme ça, bon,
ben c'est un problème.
Ça, c'est l'implémentation.
Après, il y a le déploiement.
Alors le déploiement, c'est si tu déploies encore à la main,
si tu n'as pas de stack observabilité, si tu n'utilises pas le CIHCD.
Alors bon, après, je ne sais pas, tu as des gens qui sont allergiques à Docker.
Moi, je n'ai pas vraiment d'opinion, vraiment,
je n'ai vraiment pas d'opinion sur le truc.
Je pense que Docker, c'est très bien parce que ça permet de te filer,
ça te permet de mettre clairement un scope.
Ça te permet de dire, cette application à la 7 boîtes,
tu déploies cette boîte avec tel paramètre et ça, ça doit tourner.
Et ça, j'adore Docker pour ça.
Mais donc, t'as cet aspect-là, il était les aspects management,
les aspects management et sociaux et qui, moi, je pense, sont les plus importants.
Parce qu'en fait, en général,
ces aspects-là, ils vont vraiment influencer ton développement de l'houlishiel.
Combien de fois t'as vu des équipes qui, par exemple, ne parlent pas à d'autres équipes ?
Donc ça, on en parlait, c'était les silos.
Mais combien de fois aussi tu as vu des gens qui, en fait,
vont développer du code tout seul,
sans jamais vraiment parler avec d'autres personnes ?
Ça arrive très fréquemment.
Tu sais, c'est un peu le mythe du 10X engineer.
Ouais, cet ingénieur, il est tellement bon.
Et puis, le code qui fait, ça se trouve,
c'est une grosse pile de technical debt.
Et puis personne comprend comment ça fonctionne.
En fait, ça, c'est un des problèmes.
Tu as aussi un manque de formation, par exemple.
Un des problèmes qu'on voit assez régulièrement,
et en fait, dans le bouquin, on en parle,
on a fait des interviews sur pas mal de boîtes.
Tu as des nouveaux développeurs qui arrivent,
et puis, en fait, ils ne sont pas mentorés correctement.
Et en fait, ils vont faire du code qui n'est pas optimal.
Et en fait, là, tu as un besoin d'expliquer aux jeunes.
Et c'est d'autant plus vrai qu'en fait, aujourd'hui,
les technologies sont de plus en plus complexes.
On le voit aujourd'hui, comment tu dépoches ton application,
les différentes librairies, les trucs comme ça,
ça prend énormément de temps.
Puis de deux, les gens sont sous la formation.
Aujourd'hui, en fait, tu as plus de demande d'ingénieur que d'offre.
C'est les chiffres.
En fait, le problème, c'est que les bootcamps ils règle.
Le problème des bootcamps, c'est très simple.
Le problème du bootcamp, c'est en trois mois,
je vais te faire quelqu'un qui connaît à peu près JavaScript ou Python.
Et puis, je vais te le faire embaucher par une boîte.
Et puis, en fait, cette personne-là,
on va le mettre en tant que développeur,
mais en trois mois ou six mois, tu ne peux pas former un développeur.
C'est faux.
Donc, en fait, ces personnes-là, tu vas devoir les encadrer
par des personnes plus compétentes des signeurs développeurs.
Et souvent, les boîtes,
souvent, en fait, c'est quelque chose qui n'est pas considéré correctement.
On ne va pas m'entourer les gens.
Alors après, la réponse, c'est comment tu fais pour régler le problème.
Mais là, pour répondre à la question initiale,
d'un point de vue organisationnel,
c'est juste que tu vas voir des gens qui ne vont pas être correctement formés
et qui vont créer du code qui va avoir de la dette.
Moi, je vais me permettre d'intervenir
et de remonder exactement sur ce que tu viens de dire.
Et je ne sais pas comment je vais essayer de le former
pour être politiquement correct et blesser personne, mais...
Mais vas-y, on s'en fout.
Non, mais tout ça pour dire que tu venais de dire,
tu vois, il y a une demande d'ingénieur qui est très forte.
Et là, au défi, honnêtement,
c'est ce qu'on partage avec Guillaume et d'autres collègues et anciens collègues,
c'est qu'il y a une tromperie un peu, je trouve moi, sur le mot ingénieur.
Parce que très souvent, je me retrouve avec des gens
avec qui j'ai dû travailler et collaborer.
Et je me dis, mais en fait, vous n'avez pas une démarche d'ingénierie
parce qu'il ne réfléchissait pas au problème
et a essayé d'émerger une solution pour corriger un problème dans sa globalité
ou alors prendre d'abord un scope de problème.
Mais c'était très en zone.
Il y a un truc qui ne faut pas, ce qu'on nous demande, il faut qu'on fasse.
Et même dans la manière...
Ce qu'on essaie souvent de dire, c'est la différence entre technicien et ingénieur
qui est extrêmement peu différenciant.
Et c'est dommage parce qu'en fait, un technicien,
à toute sa valeur en informatique,
il connaît extrêmement de manière pointue un logiciel,
une manière déployée, être un technicien...
Enfin, je ne sais pas, j'ai bossé dans des usines,
des usines d'aéronautique, tu vois, on revient à l'aéronautique,
on revient toujours à l'aéronautique.
J'ai bossé à la snack mart à l'époque sur des moteurs d'avion,
sur des pièces de moteurs d'avion et il y avait vraiment une discussion.
Donc les ingénieurs étaient en blanc, en haut de l'usine,
regardaient l'usine, faisaient les méthodes de construction,
mais derrière, les techniciens, ECE, qui connaissaient la machine
et il la connaissait mieux que l'ingénieur qui l'avait fait.
Et il y avait toujours une discussion qui se faisait entre ça.
Moi, les techniciens, ils venaient, ils allaient dans le programme de la machine,
dans du machine outil et ils changeaient les paramètres de côte, etc.
Mais tout le temps, à la fin, moi, j'avais les outils pour tester si,
à la fin, la qualité était là, parce que c'était ça le principal.
Il fallait tester la qualité.
Quelle que soit la façon dont on y était arrivé,
il fallait à la fin avoir la qualité.
On avait toujours ce processus qualité à la fin.
Moi là où, déjà ça, c'est un problème,
on sort un peu de la technique, c'est peut-être une cause de cette technique.
Mais moi, je peux vous intéresser sur le fait que c'est dans le management
ou des fois, t'as des gestions qui sont un peu mal faites.
Et là, là-dessus, surtout ce qui est management,
on pourra y revenir des milliers de fois pour trouver des raisons.
Mais ce que j'arrivais, enfin, mon point à la fin,
c'est que des fois, pour traiter un problème,
tu donnais pratiquement le même problème à n'importe qui,
alors que tu n'avais pas les mêmes profils pour aborder certains problématiques.
Moi maintenant, si tu connais bien ton équipe,
tu sais, pour moi, si tu es un manager qui sait bien gérer une équipe,
tu dis, OK, ce genre de problème, je vais le donner plutôt à tel type de personnes à y étaient.
Parce que tu ne peux pas donner des problèmes à tout le monde,
parce que tout le monde n'a pas sa compétence propre pour régler des choses.
Mais alors, c'est un des trucs, tu vois, où justement,
dans le bouquin, on parle d'un syndrome qu'on appelle le développement de cookbook.
Les gens qui ont un livre de recettes, ils connaissent que ces recettes-là.
Et du coup, à chaque fois que tu vois un problème,
tu vois, quand tu es un marteau, tous les problèmes sont des clubs.
Exactement. Et en fait, le problème, c'est qu'en fait, ils n'ont pas d'ouverture d'esprit.
D'où un des trucs.
Alors, tu vois, on est beaucoup, sûrement dans la tech aujourd'hui,
on met beaucoup en valeur les efforts diversités.
Et c'est là, en fait, d'un point de vue de diversité au niveau embauche,
il faut avoir une diversité de compétence qui est très importante.
Prendre des personnes qui ne viennent pas du même moule
et qui vont arriver avec des technologies différentes et être ouvert à se dire, bon,
ce qu'on a fait il y a cinq ans, c'était cool, c'était bien.
Mais peut-être que maintenant, on peut le faire différemment.
Ouais, c'était sympa, tu vois, il y a cinq ans, on a déployé avec Puppet et Chef.
Mais peut-être qu'aujourd'hui, si on prend des conteneurs,
Kubernetes ou quoi que ce soit, peut-être que ce sera mieux, en fait.
Et c'est quelque chose que je vois, je vois ça énormément.
Tu sais, le non, on a toujours fait ça comme ça.
Bah ouais, mais tu vois, le monde, il a changé.
Mais justement, je vais me faire un peu l'avocat du dia,
parce que c'était un peu ce que je voulais te dire aussi avant.
C'est qu'en fait, on peut aussi le voir dans l'autre sens.
C'est qu'en fait, les gens, par exemple, moi, ça m'arrive souvent, on me dit,
non, mais justement, toi, tes focus cookbook, tu connais Kubernetes,
c'est un envie de donner Kubernetes.
C'est-à-dire que le même argument que moi, je vais dire dans un sens pour dire,
non, mais votre truc avec des VPC que vous gérerez à la main comme des cons.
Tu en fait, le problème, en fait, de ces choses-là, on voit très bien de quoi on parle.
Mais en fait, les gens peuvent le voir exactement à l'opposé.
Moi, on va me dire, non, mais voilà, t'es pro Kubernetes, donc tu ne vois rien d'autre.
Oui, mais en fait, personne sait qu'avant, j'ai fait comme eux.
Et j'ai compris pourquoi je suis parti de ce monde-là.
Moi, chef, je l'ai roncé, j'avais 120 cookbooks, etc.
à mon nom sur le Play Store, le truc de chef.
Et c'est ça, en fait, l'argumentaire, il marche toujours dans les deux sens.
Et un autre exemple, c'est, tu as parlé, par exemple, du mentoring des gens et des nouveaux.
Et bien, nous, en fait, ils nous arrivaient la même chose, on a des boîtes où on est arrivés,
et où des gens ont commencé à nous expliquer ce qu'il fallait qu'on bosse.
Sauf que ces gars-là, ils étaient stagiaires dans la boîte avant.
Et en fait, ils nous ont expliqué comment ça marchait en entreprise,
alors que nous, on s'était tapés avant cette entreprise,
et que lui, il était stagiaire dans la boîte, était rentré parce que papa connaissait bien un dégât de la boîte.
Et il nous expliquait, il essayait de nous mentorer pour savoir comment marche la boîte.
Et il est toujours là, en fait, le problème, l'enfer n'avait pas de bonnes intentions.
Et c'est très compliqué, justement, d'avoir des gens qui veulent résoudre la dette,
peuvent très bien se mettre en fait en créé.
Et nous, on avait ça, en fait, on avait des gens qui voulaient absolument ne pas avoir de dette,
et en fait, en faisant ça, ils en ont créé partout.
Parce que justement, ils ont envé à diversité le mentoring et l'expérience,
moi je l'appelle ça souvent une épée à double tranchant.
En même temps, elle te permet d'aller vite, elle te permet d'amener beaucoup de choses,
elle permet de voir les problèmes que peut-être tu n'aurais pas vu et qu'il n'y aurait pas beaucoup plus.
Mais en même temps, comme tu dis, aspect cookbook, il te fait voir toujours la même chose.
Donc si jamais tu te mets à faire beaucoup de mentoring,
mais que c'est toujours les mêmes personnes qui font le mentoring,
ben à la fin, tu as l'armée déclone.
Ah mais ça, c'est un problème, enfin, je ne connais pas le contexte exact dont tu me parles.
Moi, ça me semble être un problème de management.
Encore une fois, de culture qui est énorme et qui va au sein de la dette.
Je suis entièrement d'accord avec ça.
Le truc, en fait, c'est que ces gens-là, et je l'ai vu beaucoup de fois,
peuvent en fait exprimer les mêmes raisons qui se battent pour ne pas avoir de dette.
On l'a parlé en off tout à l'heure et je pense justement, on va transitionner là-dessus.
C'est comment on règle ces problèmes-là.
Certains vont dire, il faut faire du rewrite.
On refait tout et de zéro.
Et beaucoup vont arriver, et je sais que c'est le cas, vont dire,
non, il ne faut pas faire de rewrite.
C'est genre faire un gros refacto, ça ne marche jamais.
Et ben en fait, on s'est retrouvé en déboite avec des gens qui ont pris ce discours-là,
en disant, ben non, mais nous, ok, on m'a écouté la littérature, on a écouté ça, pas de rewrite.
Et ben, de dette technique à fond.
Mais attends, donc car il y a...
Il y en a aussi, pardon, et moi, j'ai essayé aussi de dire que toi, dans la notion de dette,
ce qui était trop drôle, c'est que pour cette personne-là,
et l'exemple qu'on a en train de mentionné, c'est que pour eux, la dette,
c'était genre un problème technique connu, mais remis à plus tard.
Et eux, ils se disent, du coup, on ne va pas le rebettre à plus tard, on va le corriger maintenant.
Mais c'était un code sur mode pour moi, upon lonely, tu vois.
Et je me dis, mais ça, tu n'as pas résolu ta dette, en fait.
Tu as juste mis un pansement en plus.
Tu as mis une rustine en plus sur le nouveau trou, mais tu n'as pas résolu la dette globale.
Tu as mis une jolie métrique sur un truc qui ne marche pas.
Non mais, par exemple.
En fait, donc il y a plusieurs aspects, en fait.
Vas-y, on te laisse, oui.
Non, non, mais il n'y a pas de problème.
Sur le coup, alors déjà, juste un truc sur l'exemple avec les boîtes,
où justement, tu as un problème de culture.
Ces boîtes-là, à la fin, ça va...
Tu as deux solutions pour ces boîtes-là.
Soit les boîtes, elles vont lentement mourir.
Soit tu as besoin d'un changement drastique de culture, un jour.
Je vais donner un exemple de boîtes qui était en train de mourir
et qui a changé sa culture radicalement et qui est en train de revenir.
L'exemple parfait, c'est Microsoft.
On est passé de Linux à un cancer.
L'open source, c'est le problème.
À l'open source, c'est la solution.
À jachet GitHub, qui est là où t'as tout l'open source.
Je mets en open source VS Code, qui est l'éditeur le plus utilisé.
Je vais le mettre en disponible sur GitHub.
Et là, en fait, ce qui ont changé, c'est la culture de l'entreprise.
C'est radical.
Et aujourd'hui, on commence même à faire tourner Linux dans Windows
ou Windows dans Linux.
Enfin, t'as ces conversations-là qui arrivent,
alors qu'à avance, c'est une isolation totale.
Donc en fait, tu as quand même des boîtes
qui, quand ils changent de leur culture,
tout d'un coup, ça change.
Et là, les boîtes reviennent.
Sinon, elles vont mourir petit à petit,
parce qu'elles vont couler sous la dêpe,
tu vois les problèmes, les mecs.
Les ingénieurs, ils vont être déprimés,
parce qu'ils ne vont pas chipper un truc,
ça va mettre un mois, chipper quelque chose,
parce que tu ne vas pas pouvoir tester.
Tu vas être complètement déprimé.
Et on revient à mon discours de base.
On a un problème.
On n'a pas assez d'ingénieurs aujourd'hui.
Donc si tu as des ingénieurs compétents
et qui sont m****, ils vont aller chez le voisin.
Et du coup, qu'est-ce que tu vas te taper à la fin,
tous les gens qui ne peuvent pas trouver un boulot ?
Enfin, c'est clair et net.
Donc c'est comme ça que ça vient.
Sur le rewrite.
En fait, le rewrite aujourd'hui,
quand on dit qu'il ne faut pas faire de rewrite,
c'est à semifaux.
En fait, ce que je veux dire derrière,
c'est qu'en fait, ce que tu dois faire,
si tu es assez gros et que tu vois que ça te pose un problème,
tu dois décomposer.
Et en fait, j'ai deux exemples là-dessus.
Un exemple d'un monolithe, c'était Twitter.
À la grande époque de Twitter.
Donc en fait, je vais rentrer.
Alors ça a peut-être duré cinq minutes.
Je vais expliquer un peu comment Twitter, ça marchait.
En fait, Twitter, c'était un gros monolithe Rubian Race.
C'était ce que c'était que Twitter.
Comment à l'époque, tu squelais Twitter ?
En fait, ces informations-là,
c'était les publics, on en parle dans le bouquin.
On a un bouquin,
donc le bouquin a publié par Mikey.
On a interview des gens qui bossaient à Twitter à la grande époque de Twitter.
À l'époque, comment tu squelais Twitter,
tu regardais le nombre de connexions que tu avais,
tu regardais combien ton monolithe,
il pouvait en prendre et tu déployais ton monolithe.
Donc en fait, tu n'avais pas de squelais par service,
par rapport au service de pub ou compagnie.
Donc en fait, assez rapidement,
l'application Rubian Race, elle avait des problèmes.
Alors qu'est-ce qu'ils ont fait ?
Ils ont créé leur propre runtime Ruby,
qui s'appelait Kidgey à l'époque.
Mais le problème, c'est qu'en fait,
comme tu rééterais ta propre time Kidgey avec Rubian Race,
tu devais backporter tous les fixes.
Parfois, les circuits fixes, ils n'allaient pas.
Donc après toutes les nouvelles avancées de la communauté Ruby,
tu les n'allaies pas.
Donc Kidgey, assez rapidement, c'est un peu parti en suicide.
Puis, s'en arriver, ils sont dit qu'il faut quand même qu'on casse le monorail,
parce que ça scale pas.
Parce qu'on a aussi des problèmes, c'est que Rubian,
même si vous adorez sûrement les langages dynamiques,
il y a un petit problème, c'est que si tu n'as pas correctement testé,
l'application va cracher.
Donc ça arrivait à un moment où, en fait,
tu devais aller dans des meetings pour dire quel code t'allais merger.
Parce qu'en fait, tu ne voulais pas que tout le monde merge le son code,
il fallait que tu te s'imprendises.
Donc en fait, il me semble.
Je sais plus qu'on a interviewé Kevin Lingerfeld,
qui était un ingénieur à l'époque.
Je sais plus, c'était deux fois ou trois fois par semaine,
mais c'était quelque chose comme ça.
Qu'est-ce que Twitter, ils ont fait ?
La Twitter, ils sont dit, on va décomposer le monohit
en plusieurs petits services.
Donc en fait, à l'époque, tu sais,
les gens commencent à parler de micro-service et compagnie, machin.
Et c'est ce qu'ils ont fait.
Mais ils n'ont pas réécrit from scratch le truc de Rubi à Java,
à Scala, ou si, ou si plus, plus, ou n'importe quel langage que tu veux.
Ils ont décomposé les services avant et après.
Là, les services pouvaient être récrits.
Comme tu veux, je pourrais montrer.
Il y a un poste qui montre, par exemple,
quand ils ont réimplémenté le service de recherche en Rubi à Java.
La latence a été divisée par trois, par exemple.
C'est une information qui a été postée sur le blog d'un générique Twitter.
Donc en fait, ce que je veux dire,
c'est ne pas réécrir from scratch application A et application B.
Décomposer d'abord.
Et c'est pour ça que les micro-services sont là.
Voilà, on a tous ces trucs là.
Décomposer d'abord.
Et après, ils commencent à réimplémenter ce service.
Parce qu'en fait, encore une fois, tu vas donner un contexte,
tu vas donner un scope très spécifique à ces services.
Il doit faire un truc.
Tu as des interfaces qui sont très claires.
Tu as des RPC qui vont être faits entre les services.
Et là, les gens peuvent faire ce qu'ils veulent.
Et après, tu déploies ça, tu déploies ça sur ce que tu veux,
un contenaire, un docker, machin, des compagnies.
Mais c'est ça qui est important, je me semble.
En fait, au final, j'ai réfléchi un peu en tant que tu parlais.
C'est en fait, il faut changer l'organisation de ton code.
En fait, encore, il y a des organisations humaines.
Il y a des organisations techniques.
Et en fait, oui, faire un rewrite,
un, un, ça veut dire avec exactement la même API, le même truc.
Globalement, les mêmes causes créent les mêmes effets.
Si jamais tu avais un problème.
Alors, sauf si vraiment, vraiment, vraiment,
tu étais parti dans une solution complètement indagène.
Mais oui, si jamais tu ne change pas,
les mêmes causes créent les mêmes effets.
Si il y avait des problèmes en input ou le contexte ou n'importe quoi,
il y aura les mêmes effets.
Donc, au final, ce que tu es en train de dire,
c'est changer vos organisations techniques.
Il faut, il faut.
Et sa France.
Alors, dans le cas de Twitter, tu avais déjà plusieurs équipes.
Mais chacun, chaque équipe avait fait une partie du monorail,
du gros machin, du gros blob rubi qui déployait.
Mais en fait, ces équipes-là, on s'est dit,
bon, là, toi, au lieu de faire une hybré,
tu vas faire un service, on va t'appeler par D-RPC.
Et puis après, tu peux, tu peux implémenter ça comme tu veux.
Mais tu as, tu, tu, tu dois clairement définir les unités
que tu vas avoir.
Tu dois clairement définir les services que tu dois avoir.
Et en fait, ça, c'est marrant.
Il y a ce bouquin qui a été publié, qui s'appelle,
dans les années 70 ou 80, je ne sais plus trop, People Wear.
Et en fait, la,
le, le, le, la thèse de People Wear, c'est qu'en fait,
et c'est un bouquin qui est vraiment génial.
Je le recommande, je le recommande vraiment à tous les auditeurs.
En fait, une des thèses de bouquins, c'est de dire,
aucun projet informatique n'a fail à cause de prèmes techniques.
C'est toujours des problèmes humains.
Et en fait, souvent, ton organisation,
l'organisation de ton entreprise va modeler l'organisation teologicielle.
Oui, principe de cause.
Donc, la loi de Conway, ce qu'on dit souvent, être la loi de Conway.
Ouais. Et donc, en fait, c'est, tu le regardes,
il parle d'un système d'exploitation,
tu avais cinq modules dans le système d'exploitation,
mais il y avait cinq, il y avait cinq équipes.
Tu vois, c'est, mais, mais, mais quand tu vas,
et c'est pour ça que je ne parle pas de rewrite,
parce que quand on parle de rewrite, c'est souvent des gens qui disent,
ah, on va réécrire service de Java,
c'est pas Python, prends ton langage, quoi.
En général, ces trucs-là ne marchent pas,
ce qui marche, c'est une transition et avoir un plan.
Et en général, c'est quelque chose qui prend,
toi, le mythe du bon, en deux mois, on a réécrivé le truc,
et puis ça marche mieux.
J'y crois pas.
J'y crois pas.
Justement, tu viens du coup, pour rebondir là-dessus,
j'avais te posé une question.
Imaginons, t'as une organisation, le principe de la dette au début,
c'est que tu remets à plus tard ce que tu dois faire,
parce que t'as pas le temps.
C'est ce qu'on a exposé au début.
J'ai pas le temps, j'ai pas le temps, j'ai pas le temps.
Bon, il se trouve qu'en en donnant, tu hit les problèmes,
et puis, en donnant, tu dis, bon,
je ferais quand même commencer à aborder cette histoire de TechDate,
mais comment je peux faire ?
Je peux pas déboucher, enfin, en fonction de la taille de tes boîtes.
Tu peux pas dire, tiens, je peux déboucher X au ressource,
et puis ils vont bosser sur le sujet, et puis voilà.
Comment est-ce que tu pourrais, est-ce que tu as des tips
pour des boîtes petites moyennes, pour dire, OK,
comment est-ce que vous pouvez essayer d'aborder
cette notion de TechDate au quotidien par des pratiques ?
Parce que des fois, on parle, tu vois, du 10%,
tout ce genre de trucs, ou X au jour par mois,
tu fais des sanity checks et tu fais ça proprement.
Alors, en fait, c'est assez marrant dans les boîtes dans lesquelles j'ai été,
par exemple, dans...
assez souvent, les équipes dédiées une semaine par mois,
c'était vraiment dans les équipes qui prenaient beaucoup de temps,
parce que là, c'est 25%,
ou deux semaines par trimestre à fixer la dette.
Donc ça, c'est quelque chose qui disait,
et le manager a été clair,
vous devez prendre deux semaines par trimestre pour régler les problèmes.
Après, il y a un problème, dont tu parles, c'est comment tu vas
avoir une priorité sur les problèmes ?
Tu vois, comment tu...
Parce qu'en fait, il y a aussi, il y a plusieurs aspects,
il y a ce que tu sais et ce que tu ne sais pas.
Alors, en fait, la réponse, si vraiment je voudrais faire le vendeur
de voitures d'occasions, je dirais, prenez un inspector et ça va vous aider,
parce qu'en fait, on a un module qui espèce de...
qui essaie de donner une priorité à tous les problèmes.
Par exemple, si tu éclairer ça dans ton code,
je pense que c'est quand même très prioritaire d'enlever ça tout de suite,
et de le mettre dans une variable d'environnement,
dans un service de secrets, ce que tu veux.
Mais ça, c'est quelque chose que tu devrais arrêter.
Et en fait, il faut regarder, il faut essayer d'avoir une vue
sur les problèmes que tu as, d'avoir une priorité sur ça et puis après,
de les attaquer. Mais alors, il y a deux aspects.
Enfin, il y a deux choses.
Il y a régaler la dette que tu as aujourd'hui et il n'y a plus en rajouter.
Parce qu'aujourd'hui, tu as quand même des gens qui en rajoutent.
Alors, en fait, comment tu n'en rajoutes pas ?
En général, ça vient avec deux choses.
D'une, quand tu vas designer un système,
bon, avoir une revue de ton système, tu vois, encore une fois,
pas laisser quelqu'un écrire le truc de A à Z tout seul,
avoir un processus, on en revient encore une fois
cette notion de culture que tu dois avoir,
une culture de qualité que tu dois avoir dans ta boîte.
Par exemple, quand tu designs un nouveau système,
qu'est-ce que tu vas faire ? Tu vas faire un design document.
Ce design document, il va être revu par d'autres ingénieurs.
Ce design document, il va aussi être revu par les ops.
Parce que les ops, ils doivent savoir comment le truc doit tourner.
Enfin, comment tu vas observer et observer tout ça.
Et à ce moment-là, tu commences à implémenter.
Et après, tu vas avoir, en plus de ça,
tu vas avoir des processus de code review.
Donc, la code review, tu vas automatiser
une partie de la code review,
ce qui est un système aussi conformé avec Connspector.
Mais tu vas aussi avoir des personnes qui vont revoir le code.
Parce qu'aujourd'hui, des outils comme Connspector, par exemple,
où on a des compétiteurs,
il va te vérifier, par exemple, que tu ne vas pas me mettre de secret
dans ton code ou que tu ne vas pas avoir des patrons de code
qui sont foireux ou par exemple, que ta fonction n'est pas trop longue
ou la complexité n'est pas trop longue.
Mais après, il y a un autre problème, c'est est-ce que le code,
il fait exactement ce dont on avait besoin ?
Et ça, c'est une question qu'aujourd'hui, la machine ne peut pas répondre.
Moi, aujourd'hui, je peux automatiser beaucoup de qualités de check sur ton code,
mais je ne peux pas te dire si ton code
il implémentent correctement les exigences.
Ça, ça semble un peu logique au bout d'un moment.
C'est toi qui doit vraiment coder ta test métier, en fait.
Alors, ça, oui et non.
Parce qu'en fait, quand tu dis que c'est à toi de coder ton test métier,
comment tu vérifies que le test, il implément correctement ce qui doit être testé ?
C'est quelque chose.
En fait, si tu regardes dans le domaine avionique ou aérospatial,
par exemple, tu as des gens, tu as une tâche,
dans comment tu vérifies ton système effet,
tu as une tâche qui dit, on vérifie que les tests implémentent ce qui est demandé.
Donc en fait, et là, c'est aussi quelque chose qui est très complexe,
parce qu'en fait, tu vas transférer le langage naturel,
français, anglais, ce que tu veux, en langage informatique.
Et là, tu peux avoir une perte de connaissance aussi,
parce qu'en fait, la sémantique que tu vas avoir en français ou en anglais
et comment tu vas te transmettre en code, c'est pas si simple.
Alors après, tu vois, tu as beaucoup de gens qui bossent sur justement ces problèmes d'exigences.
Et justement, c'est là où tu vas commencer à mettre du machine learning et compagnie
pour essayer de détecter ça.
Voilà, tu as parlé un moment de diversité dans les profils, comprenez.
Est-ce que...
Il n'y a pas aussi une diversité d'organisation à avoir, en fait, là-dedans ?
Parce qu'en fait, le problème qu'on a eu dans plein de cas,
c'est qu'il y a aussi des différences au niveau des types de projets.
Des fois, partir from scratch et en créant de la dette,
c'est voulu et c'est souhaitable.
Tu l'as dit même au tout début, c'est on veut aller vite.
Et en fait, on s'est retrouvé des fois dans des projets
qui avaient comme but de tester quelque chose.
Et en fait, sous prétexte qu'il ne fallait pas ajouter de dette,
en fait, on ne sait jamais l'encercer dedans.
Et donc, il y a forcément des points de vue de savoir, en fait,
de savoir à quel moment on en est, de savoir que là, on est dans une phase de poc.
On sait très bien qu'il y a beaucoup de choses qui partent en près d'un moment
parce qu'en fait, on va avoir du mal à le recoder.
Mais il faut qu'on le sache.
Vous voyez, c'était encore ça, quand tu parles de la métrique.
La question peut-être l'un d'entre nous, c'est...
Et même pour enlever le système de l'onely wolf,
le problème des l'onely wolf, des gars qui partent tout seul dans leur direction.
Et ça pourrait être quelqu'un, quelqu'un qui part sur un poc, qui part après en production.
En fait, personne n'a eu le temps d'aller revenir
parce qu'en fait, ce gars-là était dans une autre équipe, il a fait un truc.
Et juste dans l'organisation, personne n'était chargé de le monitorer, en fait.
Est-ce que le binomiage aussi bien personnel, c'est-à-dire le pire,
c'est-à-dire de se dire que personne à droite bossait tout seul,
tout le monde doit travailler à deux en permanence, tout le temps.
Il n'y a pas déjà un moyen de limiter un peu la dette.
Il n'y a que deux personnes, même si elles ont fait la même école,
même si elles ont eu à peu près la même expérience, sont quand même deux.
Donc on a limité un peu ça.
Voir même, moi j'aime bien le binomiage d'équipe.
C'est-à-dire de se dire typiquement, vous vous faites le code et eux, ils font les tests.
Ouais, alors ça y a...
Alors...
Et c'est pas une équipe qui fait des tests, c'est pas une équipe dédiée aux tests.
Parce que ça, c'est encore un nouveau silo de gens qui sont dédiés à faire des tests
et dont ils ont leur pied de testeurs.
C'est très intéressant.
Non, c'est très intéressant ce que tu dis parce qu'en fait,
en fait, avoir des tests faits par d'autres personnes,
ça t'aide à vérifier que le code implémente vraiment ce qui est fait.
Parce qu'en fait, si les tests y foire,
bah tout d'un coup, tu peux avoir une conversation et dire,
« Bah non, nos tests, je pense vraiment qu'ils sont corrects.
Alors bon, c'est quoi le problème ?
C'est les tests ou c'est le code ? »
Et là, tu vas commencer à avoir une conversation.
J'ai eu même plein de gens qui, à chaque fois qu'ils changeaient le code,
changeaient les tests afférents, en fait.
Ouais, ouais.
Alors après...
Donc en fait, on ne savait jamais ce qu'on testait puisque...
Ouais, mais après, ça peut être logique.
Si ton programme et ta logique métier changent,
dans ce cas, tu dois changer les tests.
Après, si tu te changes les tests à chaque fois pour que tu passes le API Case,
c'est un problème.
Ouais, mais ça, c'est une métrique, en fait.
Si à chaque fois que tu...
Enfin, le nombre de fois que tu changes les tests,
ça doit être une métrique, ça, en fait.
Et j'ai jamais vu.
Le nombre de fois que tu changes les tests, c'est une métrique qu'il y a.
Changer le test, hein.
J'ai pas dit rajouter les tests.
Alors justement, je voudrais m'en dire sur le sujet où, en fait,
on travaille en binôme.
En fait, ce qui est recommandé, en général,
c'est quand même de travailler et de demander d'avoir au moins deux codes revus
par tes binômes pour chiper le code.
Pour que ces gens-là soient au moins au courant de ce que tu fais.
Code pas.
Mais ils savent au courant au moins ce que tu fais.
Et en fait, pour garantir que ça s'est fait, il y a un outil.
Alors en fait, c'est quelqu'un, c'est un pote qui était avec moi à l'étui du Havre,
qui a fait un outil qui s'appelle Merjify, peut-être que vous en êtes en train de parler.
Cet outil-là, en fait, il garantit qu'au moins il y a une personne dans ton équipe
qui est donné un chip qui accepte le code avant même qu'il soit mergé dans ton kit.
Et ça, ça me semble quelque chose, enfin, ça me semble d'être la base, quoi, tu vois.
Ouais, c'est la base.
Mais en fait, pour l'avoir un peu vécu dans plein de boîtes, ça a plein d'effets pervers.
Que les gens, pourquoi le code ?
En fait, nous, on a bossé beaucoup avec Gérite parce qu'il fallait ressembler à Google le plus possible.
Et ça devient un enfer. L'enfer du plus 2, c'est un enfer.
C'est vraiment...
En fait, ça dépend toujours de l'organisation.
C'est que typiquement, quand on avait des teams qui étaient dépendantes les unes des autres,
tu vas devoir faire des pousses sur une autre équipe.
Et en fait, elles n'ont pas forcément envie.
Donc, en fait, elles n'ont aucun incentive à te laisser faire un changement massif sur leur code
parce que justement, elles vont le voir comme une dette.
C'est quelqu'un d'autre qui a fait quelque chose sur leur code et ne pas vouloir mettre...
Tu sembles, tu sembles.
Je ne connais pas l'entreprise en particulier, mais tu sembles avoir souffert.
Parce que là, il me semble que le problème, ce n'est pas un problème de process,
mais un process d'organisation et ça sent vraiment...
Non, non, mais en fait, en fait, je fermais ça pour dire,
je suis entièrement d'accord qu'il faut des merdes, des reviews.
Le problème, en fait, c'est que vraiment, l'enfer est dans ces petits détails-là
qui font qu'en fait, on peut très bien suivre à la lettre, tout ce truc-là.
On peut très bien cocher toutes les cases.
Ça veut dire avoir du peer review, avoir des reviews,
avoir des choses où on mentore les gens, etc.
Et pourtant, à la fin, faire de la merde.
Et c'est pour ça, d'ailleurs, que avant ça,
je t'avais conseillé le livre Les décisions absurdes,
qui est vraiment ça, c'est qu'en fait, c'est des gens,
des ingénieurs extrêmement doués, extrêmement intelligents,
des gens de toute bonne volonté qui veulent bien faire les choses
et qui pourtant, à la fin, font l'exact opposé de ce qu'ils avaient voulu au début.
Et c'est pour ça que c'est absurde.
Une des questions que j'ai, c'est est-ce que ces gens-là,
ils monitorent, est-ce que, disons, des métriques sur le nombre de problèmes
qui est, par exemple, il y a plusieurs métriques.
Donc, par exemple, les métriques dont je parle avec Unespector,
où tu as le nombre d'erreurs dans ton code,
mais il y a d'autres métriques qu'on implémentera,
mais qu'on n'a pas implémenté aujourd'hui,
c'est par exemple le temps avant de chipper le code.
C'est une métrique qui est super importante.
Est-ce que ça, c'est monitorer ?
Euh...
Qui fait des reviews sur quoi ?
Parce qu'en fait, aujourd'hui,
une des métriques principales qu'ils ont utilisé pour voir la productivité des ingénieurs,
c'est la quantité de codes chippés,
ce qui est une hérésie.
C'est une connerie sans nom de faire ça.
Mais il y a d'autres métriques qui sont assez intéressantes.
C'est le temps moyen pour chipper par équipe.
Parce qu'en fait, ben...
Si tu mets trois semaines à chipper un code change,
il y a clairement un problème.
Il y a d'autres métriques qui sont...
que j'aime beaucoup à voir,
c'est le nombre d'incidents par semaine.
Et là...
Et là, la résolution aussi, c'est intéressant à voir.
Ouais.
Et ça, c'est des métriques...
Que...
Ben, je sais pas quels sont la cultures que vous avez,
mais moi, toutes les équipes dans lesquelles...
Enfin, où j'étais TechLead,
toutes les semaines, je regardais ces métriques-là.
Parce qu'en fait, ça te montre si il y a un problème au niveau opération.
Et parfois, ça peut dire que...
Tu sais, parfois, la métrique, elle peut être complètement irrelevant.
Ça se trouve, tu as des incidents.
Et puis, ce sont des non-incidents.
T'as été pégé par pêche du rizutis,
et en fait, tu devais pas être pégé.
Et ça, c'est important parce qu'en fait,
la santé de l'équipe va être impactée par ça.
Si tu mets trois semaines à chipper un code change,
je pense qu'au bout de six mois,
tu vas vouloir changer de boîte.
Ben, en fait, on avait un autre truc,
c'est qu'à la fin, il y avait plus de problèmes.
C'est parce qu'on ne les faisait pas.
Et donc, en fait, on avait triqué la métrique.
C'est-à-dire que, comme on savait que c'était tellement long
d'aller chipper quelque chose à notre équipe, on ne le faisait pas.
Et en fait, tout le monde était dans son coin.
Genre, en fait, tout pouvait s'écrouler.
Personne n'allait rien changer,
parce qu'en fait, c'était une culture qui était devenue ainsi.
Alors là, on arrive vraiment dans des cas complètement extrêmes.
Mais ils sont assez révélateurs.
Moi, c'est juste pour dire...
Tu vois, on parlait même des métriques avant le podcast,
en disant, attention, les métriques,
elles influencent la vision qu'on a des problèmes.
Typiquement, si jamais tu commences à monitorer le nombre d'incidents,
tu pourrais très bien te retrouver un moment
où en fait, les gens, ils n'ont pas envie de riporter l'incident.
Parce qu'ils n'ont pas d'intérêt,
parce que leur équipe va être mal vu par...
Enfin, mal vu.
Ouais, ils veulent plus chipper parce qu'ils disent qu'il y aura un nombre d'incidents.
Et c'est génialissime.
C'est qu'en fait, les bonnes idées qu'on peut avoir à un moment,
moi, c'est ça que j'adore analyser.
Bien sûr.
Les meilleures idées qu'on peut avoir,
elles peuvent avoir un effet pervers invisible et complètement délétère.
Non, non, non, non.
L'effet comme ça.
Et il est très marrant à savoir comment on trouve un moyen,
à chaque fois qu'on a une bonne idée et qu'on le met en place,
de faire toujours attention à minimiser l'effet délétère qu'il va apporter.
Bien sûr.
Mais après...
Et ça, c'est quelque chose qui est assez...
Après, il n'y a pas de solution magique.
Encore une fois, tu as un problème de culture.
Si on en aurait déjà parlé, on aurait déjà fini le podcast.
Il y a deux heures. Merci, au revoir.
Comme on dit, tu as un problème de culture qui doit vraiment être là.
Après, sur les incidents en général, c'est marrant,
parce que les incidents, dans tous les cas que j'ai eu,
ce n'est pas des incidents qui sont reportés.
Ce sont des incidents qui sont détectés automatiquement.
Par exemple, tout d'un coup, ma latence, mon P-99 sur ma latence est trop importante.
Et j'ai un ticket qui est...
Enfin, dans mon cas, par exemple, quand je bossais dans d'autres boîtes,
tu avais un ticket automatiquement chez Gira, mis sur Gira, et puis avec un tag.
Donc après, sur Gira, tu avais un dashboard.
Ils ont eu combien de tickets avec tel tag.
Et puis, tu regardais.
Ce n'était pas quelque chose qui était fait manuellement.
Mais cette sonde-là, elle a été mise...
Tu peux très bien te retrouver à avoir des équipes qui mettent énormément de son.
Ils ont un problème.
Il y a beaucoup de problèmes avec la mesure.
C'est quelque chose de...
Ah non, mais après, j'ai vu des équipes littéralement,
ils ont eu des alarmes, ils arrivaient le lundi, et puis ils ont enlevé l'alarme.
Et c'est simple, tu sais.
Mais encore une fois, là, dans ce cas-là, c'est au manager d'arriver,
dire attendez les gars, pourquoi n'a plus l'alarme ?
Là, il y a un problème.
C'est-à-dire, si tu veux faire ça,
clairement, c'est aller dans une bagnole,
retirer le voyant que t'as plu d'huile dans la voiture,
et puis qu'il y a un moment...
Mais presque que je suis pour pas le voir.
Et à un moment, la voiture, elle va arrêter d'avancer.
Et pour revenir sur ce point-là, ces boîtes-là,
elles vont doucement couler.
D'expérience, justement, pour changer ça,
on en avait parlé dans d'autres podcasts.
Ce qu'on s'est aperçu souvent, c'est que pour changer le management,
en fait, le middle management surtout ne peut pas changer de lui-même.
Parce que le middle management a été mis là par d'autres hotus
qui avaient cette culture-là, qui avaient cette culture-là,
qui avaient cette culture-là, et donc, en fait,
tout le monde se tient par les couilles avec les mêmes idées.
Parce que, globalement, tu promues les incapables,
parce qu'ils sont comme toi, en fait.
Tu fails le poire.
Tu fails le poire.
C'est assez commun, ouais.
Et donc, pour changer ça,
d'expérience qu'on s'est aperçu,
et ça, on en a parlé dans d'autres podcasts avant,
c'est souvent en enlant voir les gens du business,
les gens du business, voire mieux,
non, les gens de la finance.
Les gens de la finance sont un moyen de changer les organisations
qui est démesurée.
Et sans doute là,
en fait, tu l'as dit au début, c'est qu'il y a une notion de dette financière.
Est-ce qu'un moyen de changer ça,
c'est peut-être pas d'avoir sur tes indicateurs un prix,
au lieu d'avoir un score.
Tu mets un prix en dollar, en dollar.
Tu veux vraiment faire la promotion de mon outil,
parce qu'en fait, c'est ce qu'on fait.
On donne un prix en dollar à la dette technique.
Et en fait, la raison pour laquelle on fait ça,
c'est exactement pour ce que tu dis,
que ça résonne en dollar.
Parce qu'en fait,
certaines compagnies ne peuvent raisonner qu'avec ça.
En fait, un des problèmes qu'aujourd'hui,
beaucoup de personnes ne voient pas,
c'est que souvent,
beaucoup de boîtes sont dirigées par des financiers.
Et en fait, ils voient le logiciel comme,
ils achètent un logiciel comme,
comme ils achètent un sandwich chez Savoy.
C'est un coup, et puis ils le mangent, et puis c'est fini.
Mais en fait, le coup,
le vrai logiciel, le vrai coup de logiciel,
c'est le coup de maintenance et le coup d'opération.
C'est ça, le vrai coup.
Et ça, ils ne le voient pas.
Donc en fait, l'idée qu'on a eu derrière ce truc-là
est de mettre un coup sur la dette technique.
C'était, c'est l'idée qu'on a eu.
Après, le problème, c'est qu'en fait,
il y a des choses,
tu peux mettre un coup sur certains aspects de la dette technique.
Le code, le déploiement, c'est des choses comme ça.
Tu sais, grosso modo que passer à Dockers,
bon, tu vas devoir, après,
ça dépend comment les gens qui t'attendent, ton équipe.
Mais tu sais grosso modo combien de semaines ça va te prendre.
Tu sais grosso modo combien fixer tel problème de code,
ça va te prendre.
Par contre, le problème de changer
ton organisation et ton management,
c'est quelque chose qui est complètement différent.
Et pour revenir,
pour revenir, c'est le facteur qui va t'adjouter de la dette demain.
En fait, ton management, si tu le changes pas,
complètement, c'est quelque chose qui va te re rajouter là-bas.
Fodoncellement, c'est un facteur comme ça.
Je veux revenir avec mon meilleur exemple.
Mon meilleur exemple, Microsoft.
Je veux dire, Microsoft a changé la tête.
Et en changeant la tête,
t'as complètement changé la philosophie de la boîte.
Je veux dire, Microsoft aujourd'hui, c'est l'exemple énorme au niveau culture
qui te montre que si tu changes la tête de la boîte
et tu as vraiment une volonté de changer la politique de la boîte,
c'est possible.
Je veux dire, c'est impressionnant.
Je veux dire, en combien, regarde,
en combien d'années Microsoft, ils ont changé ?
10 ans, même pas ?
Même pas, même pas.
C'est un peu moins de 10 ans.
C'est un peu moins de 10 ans.
On avait eu, d'ailleurs,
alors, c'était pas dans un casque, c'était dans un meet-up avant,
je fais le petit apparté là-dessus,
de comment ça s'est passé en interne,
pourquoi Microsoft a changé ?
Alors, en effet, la tête a changé,
mais c'était donc le directeur d'Azure,
qui est devenu directeur de Microsoft.
Donc, il y a eu clairement un changement.
Mais avant ça, il y a eu des balbus ciment.
Et on nous avait raconté, c'était déjà en interne chez Microsoft,
dans le labo d'expérimentation qu'ils ont à Paris,
qui nous avait fait un meet-up là-dessus,
dans un meet-up DevOps à Paris.
On nous avait raconté qu'en fait,
le logiciel qui a fait tout changer,
parce que c'était le premier à être fait différemment,
c'était Visual Studio Online.
C'est-à-dire que, historiquement, Microsoft,
c'est des gars, ils font du bundle,
ils font, ils chippent du CD.
Et ils chippent du CD, donc ça veut dire que tu développes
pendant un an, et quasiment, tu testes pendant un an.
Et après, tu as une TMA qui est au milieu de l'année,
tu sors un service pack.
Voilà.
Ça a toujours été comme ça, c'était toujours fait comme ça.
Et Visual Studio Online, le concept, c'était de se dire,
non, mais en fait, on va prendre notre logiciel,
alors déjà, on va utiliser Azure,
parce que ce n'est pas le reste de Microsoft.
Et on va chipper toutes les deux semaines.
Et en fait, vraiment dans la boîte personne n'y croyait.
C'est impossible, culture, on est habitué à faire du bundle,
il faut avoir une équipe de testeurs,
plutôt une grosse équipe de testers,
et plus ton logiciel, il sera bien.
Et en fait, ils ont réussi à faire marcher le truc,
et ils ont réussi à prouver en interne,
par l'exemple que c'était possible de le faire.
En plus, ils ont utilisé Azure,
donc ils ont fait Iture on Duck Food,
ils ont pu ramener pas mal d'expériences au cas d'Azure.
Et ça a été ça, en fait, le premier projet,
en tout cas de ce qu'on nous avait dit,
vraiment différentiant de la manière de voir les choses,
de ne pas avoir peur de chipper régulièrement.
Et en fait, ça a énormément influencé, même Windows 10,
on se dit que, en fait, ça ne s'appelle pas Windows 10,
ça s'appelle Windows, on devrait même...
Voilà.
Il vivra sa vie avec des mises à jour régulières par mois,
des mises à jour mensuelles,
enfin, je connais très mal le mono Windows,
donc je ne peux pas trop dire.
Mais voilà, en fait, ça a complètement changé la culture,
et il y a eu vraiment une tissue avec des gens qui disaient,
non, mais on fait un vrai logiciel,
il nous faut des batteries de testers avec notre cycle.
Mais en plus, ça voulait dire chiper des machines,
enfin, chiper des CDs, donc avoir un réseau de revendeurs, etc.
Qu'est-ce qui se passe quand t'arrêtes de vendre des CDs,
quand ta licence, ça devient quasiment une licence à vie,
comment tu fais ?
Enfin, c'était vraiment extrêmement problématique.
En fait, c'est pour ça que ça ne pouvait être que quelqu'un du cloud,
qui se dit, voilà, on gagne beaucoup plus de fric que vous,
grâce à la vente des matérialisés et la vente de ressources.
Imagine, imagine, après, tu vois, on peut faire des plans sur la comète,
mais imagine à Microsoft,
où tu aurais toujours un balmeur à sa tête,
où ils vendent du CD,
où on te dit, où il te dit,
en 2008, en 2010,
l'iPhone, c'est qu'un effet de mode.
Il a dit ça, hein !
Tu vois, imagine ce que serait Microsoft aujourd'hui.
Mon point pour revenir à ça, tu vois,
c'est que tu peux avoir des faits dans ta boîte qui te montrent quelque chose.
Si à la tête, t'as pas une dynamique qui arrive,
et un mec comme Nadella, qui aujourd'hui prend des initiatives sur Office 365,
après, je ne vais pas faire la biologie de Microsoft,
c'est pas mon but !
Mais c'est un très bon exemple,
je pense que tout le monde est d'accord là,
tu peux aller actuellement,
on peut ne pas aimer tous les produits qu'ils font,
on peut ne pas aimer les choses,
mais on voit un changement.
Après, il est bon ou il n'est pas bon,
en tout cas, une boîte qui était sûre de mourir,
qui vient maintenant,
et une possibilité de réussite,
et à des réussites,
et à l'inverse,
qu'on aime ou pas.
A l'inverse, si on reprend cette tendance,
je pense que Google est plus sur la pente descendante,
d'un point de vue culture,
d'un point de vue produit,
toi, si tu regardes,
enfin, j'ai essayé d'utiliser Google Cloud,
putain, c'est super dur à utiliser, quoi.
Et t'as l'impression qu'en fait,
quand j'utilise aujourd'hui des interfaces
comme Gmail et Compagnie,
j'ai l'impression de me retrouver sur Windows 95.
Toi, t'as tellement de menus, c'est super dur à utiliser,
et en fait, c'est complètement blotted.
Plus j'utilise Gmail,
et plus c'est blotted par exemple dans Firefox,
parce que j'utilise Firefox toujours
pour des raisons de privacy et compagnie,
c'est toujours plus lent d'utiliser Gmail.
J'ai l'impression qu'en fait,
Google est le nouveau Microsoft.
Enfin, c'est...
Non mais sans doute.
C'est...
Et ils ont un peu cette culture-là,
ils ont un peu, en effet, cette culture-là,
et du coup, le fait qu'ils aient peu de diversité
et peu de nouveaux produits,
et on voit que la plupart de leurs produits
ont un peu de différenciants,
ils les ont tués,
et ça veut...
Ça veut dire quelque chose
dans une certaine idée de culture, en tout cas.
Après, on verra l'avenir,
l'avenir est-ce que ça change, justement,
et ce serait d'ailleurs bien de voir
est-ce qu'il y a eu des boîtes
qu'on pourrait connaître
qui ont essayé à tout prix de changer leur dette
et ça les a tués ?
Je n'ai pas d'exemple de ça.
De moi, je connais des boîtes
qui n'ont rien fait et qui sont mortes,
de leur petite mort,
ou sont faits racheter, etc.
Donc, finalement, les créateurs ont gagné du fric,
donc peut-être ça s'est vu par certains
comme une success story.
Non, je connais des boîtes qui sont mortes,
je connais des boîtes qui sont mortes
à cause de ne pas avoir réglé la dette.
Ça, on en connaît tous.
Je n'ai pas d'exemple de boîtes qui ont...
Je connais des gens qui ont essayé
de fixer la dette et qui ont fail.
Oui, ça, j'en ai connu.
Mais je ne connais pas d'exemple de boîtes
qui sont mortes à cause de ces efforts-là.
Ouais.
Moi, c'est souvent ça, en fait,
les exemples que je donne,
c'est que oui, vous pouvez rater en le faisant,
c'est juste que si jamais ça arrive,
vous seriez dans un cas minoritaire
par rapport à si jamais vous n'avez pas fait...
Oui, exactement.
Mais je ne connais pas de boîtes
qui ont vraiment eu des problèmes là-dessus.
En général, le cas d'école,
c'est vraiment des boîtes qui arrivent.
J'ai eu ça plusieurs fois,
des managers ou des sitios qui arrivent
et qui font « punaises »,
une simple feature, ça prend deux mois à chipper.
Je ne comprends pas.
Et là, tu commences à dire,
« regarde, mec, combien de temps ça prend.
Regarde le pipeline du design à chipper la feature.
Regarde le pipeline.
Regarde où tu as des bottlenecks.
Est-ce que c'est le code review ?
Est-ce que c'est le design ?
Est-ce que c'est le déploiement ? »
Et là, tu commences à agir.
Ouais.
Le problème que tu as par rapport à ça,
c'est que est-ce qu'il n'y a pas peur
de justement en essayant de régler les problèmes,
dans moi, c'est que j'ai fait souvent,
en essayant de rajouter des nouvelles étapes justement,
bah, on rajoute juste de nouvelles étapes.
Et en fait,
en fait, chacune des étapes est normalement là
pour régler un problème.
En fait, non, c'est juste une nouvelle étape.
Ouais, avant...
Un peu comme on parlait des DevOps
qui étaient là pour régler des problèmes.
En fait, hop, on a créé un nouveau silo.
Ouais, mais tu as quand même des étapes majeures
dans le développement de l'Ouciel.
C'est toi, le software Life's Recall,
tu as quand même une phase de design requirement,
enfin, requirement après design,
après implementation, après test,
et après, tu déploies.
C'est quand même des étapes majeures
qui sont reconnues jusqu'à présent.
Après, tu sais,
encore une fois, je...
Ouais, mais si jamais tu rajoutes une étape,
par exemple, de validation par les pères,
tu vois, c'est encore une nouvelle étape
qui te permettait de ne pas avoir de dette.
Mais est-ce qu'en fait, à la fin,
en imaginant quelque chose d'assez,
on a mis en place toutes les bonnes étapes
pour régler la dette technique,
et en fait, d'avoir mis en place
toutes ces éléments-là, c'est de la dette.
Ouais, je n'ai pas...
Je n'ai pas...
Je...
J'essaye vraiment de la pour tenir un peu...
Non, mais ça, c'est un truc, je pense, d'organisation, tu vois.
Et encore une fois,
je pense que ça n'a pas grand-chose à voir
avec la dette technique.
C'est plus encore un problème d'organisation.
Je vais donner un exemple.
Combien de fois tu es dans des boîtes
et t'arrives,
et on te dit, ah non, mais là, il nous faut un nouveau meeting.
Puis t'arrives,
puis tu regardes ton calendrier,
et puis putain,
t'as 6 heures de meeting par jour.
Au bout de 2 mois.
Bon, il y a un moment,
il faut se dire,
si ce meeting-là n'est pas utile important,
bon, bah, tu le supprimes.
Puis, en général, tu sais,
personne ne doit se dire ça.
Mais par contre,
quand tu le dis,
tout le monde te dit, ah ouais, c'est une bonne idée !
Non, mais ça, je suis d'accord.
Après, toujours le même exemple.
Et alors là, pour le coup,
c'est genre, en vrai, j'étais dans une boîte
où il y avait 0 meetings.
Ouais, mais...
En fait, quand il y a 0 meetings,
c'est pas qu'il n'y a pas de meetings, en fait.
C'est qu'on ne t'a pas mis dedans.
Euh, qu'on n'a pas mis.
Et en fait, les gens, justement, se disaient,
bah non, mais en fait,
justement, pour limiter le nombre de meetings des équipes
et pour qu'elles continuaient de bosser,
bah en fait, on fait des meetings entre nous.

Toi, t'es pas dedans.
Ah oui, ou ça, c'est dit à la machine à café.
Ouais, mais même, mais non,
mais juste les meetings, en fait,
et j'en ai même des boîtes,
alors toujours la même, en fait,
parce que c'est vraiment un cas d'école,
qui ont dit 60% des meetings ne servent à rien.
Donc, ils ont pris 60% des meetings au pif
et ils ont les enlevé.
Ouais, bon, là, là, là, je veux dire,
c'est, y a un problème de compétence au niveau management.
C'est différent, tu vois.
Ouais, mais c'est pour dire,
toujours l'exemple,
j'adore cet exemple-là,
parce qu'en fait, ils ont essayé de l'appliquer à la lettre
toutes les bonnes choses
et ils ont réussi à toutes les chier.
Donc, à ce niveau-là, c'est de la compétence,
de chier autant,
c'est une compétence en soi.
Mais c'est juste pour dire que,
faire attention justement,
parce que toi, en fait, dans ta tête, c'est clair.
Tu vois vraiment toutes les petites choses
qui peuvent foirer.
Et donc, en fait, instantanément,
potentiellement, tu ne les dis pas.
Mais en fait, moi, je fais l'attention
à tous ceux qui vont écouter là
et qui se trouvent vont arriver demain en disant,
« Allez, moi, je pense que c'est par moi
que tu vas passer toutes les nouvelles choses
et ils vont devenir les « by the book ».
Oui, non, non, non.
Pourtant, qu'on a mentionné un peu plus tôt,
nous en disons « Attention, les cookbooks,
si tu les suis à la lettre, tu vas de votre place ».
Et des gens, on pourrait utiliser la même chose,
en fait, et devenir les nouveaux cookbooks
en l'appliquance qu'on dit « by the book ».
Non, non.
Moi, tu vois, si j'ai appris un truc
dans mes défendres années, justement,
c'est que au début, t'es nouveau,
enfin moi, c'est ça, j'étais jeune et tout,
tu vois les trucs en mode « infrascode »,
« Ah, les bonnes pratiques, putain, c'est ça qu'il faut faire ».
Et puis d'un coup, j'étais devenu ultra exigeant envers moi-même,
moi aussi envers les autres.
Et puis après, j'ai appris tout ça,
tu sais, on parlait un peu plus tôt,
on disait « OK, là, on va mettre de la dette ».
On est conscient, mais c'est pas la plus grave,
parce qu'au moins, en faisant ça,
on va solutionner l'autre dette.
Et bref, mais moi, ce que j'ai appris avec le temps,
c'est que vraiment être un peu plus indulgent,
c'est ça le mot.
Me dire « OK, c'est pas grave ».
Il y a des trucs, on a des bonnes intentions,
on va faire des choses.
Est-ce que tout le monde est page
et est-ce qu'on a une direction commune ?
Tout début Xavier, qui raisonne beaucoup en fait,
avec à mon avis,
il y a un truc que les gens doivent avoir,
c'est quand tu ingénieurs, normalement,
tu dois commencer à avoir vraiment du bon sens.
Tu as des trucs de basse, quoi.
Quand tu arrives dans un meeting,
tu te dis « Est-ce que ça a du sens d'avoir ça ? ».
Quand tu as un process, tu as assez régulièrement,
tu as un checkpoint tous les six mois,
tu vas te dire « Est-ce que ça a du sens d'avoir ça ? ».
C'est les solutions qui marchent hier,
vont peut-être pas fonctionner demain et vice-versa.
Et donc en fait, avoir du bon sens,
enfin, c'est quelque chose qui...
C'est plus la remise en cause, en fait, que tu dis.
C'était toujours dans une remise en cause de soi et des...
Tu dois, c'est de soi et de soi.
Et surtout de soi, tu vois, c'est là où j'insisterai,
parce qu'on en a croisé des certaines personnes
qui veulent faire la remise en cause,
mais absolument pas de ce qu'ils font eux,
parce qu'eux sont déjà convaincus d'être dans le bon.
Et c'est là le piège, tu vois, c'est de se dire,
c'est réussir à se dire « Ok, on fait une remise en cause,
mais moi compris, est-ce que moi aussi je fais des trucs bien ? ».
C'est ça aussi une clé ?
Non, c'est très important, tu sais.
Enfin, maintenant, tu sais, j'étais...
C'est marrant parce qu'en fait, tu sais,
tu as cette citation qui dit « Plus tu deviens,
plus tu vieillis et moins tu es sûr de tout ».
Enfin, toi, tu es sûr de rien.
Et en fait, je vois ça de plus en plus,
c'est-à-dire qu'en fait, tu vois,
j'ai quand même bossé dans des boîtes avec un gros scale,
tout à Twitter et compagnie.
Mais en fait, assez souvent, parfois, je me dis « Est-ce que je fais la bonne chose ? ».
Et en fait, tu arrives à en parler,
même parfois, j'arrive à voir des développeurs juniors,
et je leur fais « Ouais, tu penses quoi de ça ? ».
Et puis vraiment avoir une opinion honnête.
Alors en fait, ce qui est très important dans ces processus-là,
et c'est quelque chose que j'ai dans toutes les équipes que j'ai,
enfin dans laquelle j'étais à la tête,
c'est surtout ne jamais...
Enfin, ça, c'est ce que j'ai pratiqué après,
ça dépend des gens.
Mais ne jamais s'acharner,
ne jamais prendre les choses de manière personnelle.
En fait, en anglais, on appelle ça la « blème les sculptures ».
T'es pas là pour blâmer les gens.
En fait, t'es pas là pour dire « Oh, la faute, ça cause de toi ».
Non, en fait, si il y a un problème,
c'est parce que tu n'avais pas d'observabilité,
tu n'avais pas de métrique, tu n'avais pas un truc.
Et là, tu t'adresses le problème.
Par contre, si après avoir adressé le problème,
les gens ne prennent pas action, là, il y a un problème.
Là, il y a clairement un problème de performance et de compétences.
Mais quand ça arrive les premières fois,
ne pas blâmer les gens,
essayer de comprendre la route cause,
diagnostiquer, ne pas être dans le pointage de doigt,
« Ah, c'est toi, ça cause de toi ».
Et ça, c'est quelque chose qui est très important.
Êtes vraiment ouvert à ça,
je pense que c'est vraiment quelque chose qui est très important.
Je suis entouré d'accord.
Bon, je pense que là, ça fait déjà une heure qu'on discute.
C'était vraiment super intéressant.
Merci.
On le savait en préparant un peu le podcast, que ce serait cool.
Merci beaucoup Julien.
Je pense qu'il y a déjà encore beaucoup d'autres choses à parler de dette.
Et je pense qu'on refrafe un sujet un peu récurrent
qu'on a dans nos podcasts.
Donc ça reviendra forcément.
Donc même si tu as hâte à envie de reparticiper sur un autre sujet,
sur quoi que ce soit, tu es bien sûr là bienvenue.
Comme tous ceux qui écoutent d'ailleurs en ce moment,
n'hésitez pas à venir, n'hésitez pas à nous rejoindre sur Discord,
n'hésitez pas à envoyer un email,
nous pinguer sur Twitter, soit personnellement sur DevOps.
Vraiment, là, vous voyez par exemple,
c'est Julien qui m'a envoyé un email en proposant le sujet.
En plus, c'était vraiment très sympa,
parce que Julien était là en me demandant
est-ce que ça pourrait aller,
enfin vraiment, l'email était vraiment...
On sentait que tous les mots étaient pesés, etc.
Et moi, j'ai juste reproduit en mode,
bah oui, ça paraît tellement évident,
évident de suivre le nombre de fois au jeudi.
N'hésitez surtout pas l'un de dans,
on en avait pas fait depuis longtemps,
parce qu'on n'avait pas de sujet à qui parler,
parce qu'on ne voulait pas parler, c'est justement...
On veut avoir des expériences comme les tiennes,
Julien qui nous parle de ce qu'il a fait, de ce qu'il a vu.
C'est beaucoup plus intéressant que si on reste...
On voulait pas rester plus entre groupes,
d'être toujours les mêmes.
C'est ça, sinon on va devenir débateur CNews du DevOps,
et ça sera juste nul.
D'ailleurs, appellent à Témo, le Pascal Pro du DevOps.
Appellent à Témoin s'il y a des gens,
on l'a dit lors du dernier,
l'interne de la mission,
mais s'il y a des gens qui pratiquent,
et qu'on est retour d'expérience sur le feature Tuggle,
ou le service Mesh,
on prend, on prend, on prend.
Oui, voilà, par exemple, très, très, très important.
Et même plein d'autres trucs,
donc on part par rapport à...
Oui, bien sûr.
Mais voilà, dans le monde de l'embarquer aussi,
j'aimerais bien faire des choses aussi,
dans le monde de l'embarquer.
Tiens, sujet que j'aime beaucoup en ce moment,
et voilà, et notre là même,
tu pourrais participer Julien là-dessus,
parce que c'est cool, le monde de l'embarquer.
Et il y a plein de choses...
Je pense que c'est un des sujets
qui à l'heure actuelle va s'en occuper,
le plus bouger, et voilà.
Bien sûr.
On peut en pouvoir discuter.
Avec Claudia.
Super, ben merci beaucoup,
merci à tous les deux d'être là,
d'avoir participé,
et puis à tous et à une prochaine,
commenter, partager.
Le pouce bleu,
je n'ai pas dit de choisir ça,
alors on peut entrer,
et voilà, partager.
Merci.