Alain Hélaïli

Bonjour à tous, je m'appelle Alain El Haïdi, comme vous avez pu le voir et comme c'est écrit, je bosse chez GitHub. Et aujourd'hui, en essayant de rattraper un petit peu notre retard, je vais vous raconter comment on fonctionne. Comment on fonctionne, vu les quelques particularités qu'on a. A savoir qu'on est une boîte qui a 9 ans maintenant d'existence. On est un peu plus de 730 maintenant. Ça grandit un peu tous les jours. Donc ce slide, il y a quelques semaines. Et on est 730 et comme vous pouvez le voir, on est très, très, très distribué à travers la planète. Et donc ça engendre pas mal de complexité sur notre organisation et sur notre manière de travailler.
En fait, est-ce que vous parlez français un peu?
Oui? Est-ce que vous êtes une personne non-française? Non? Donc si vous comprenez le français, je vais le garder. Sinon, je pourrais le changer. D'accord. Donc on a pas mal de gens un peu partout sur la planète. Et ces gens-là, c'est notamment des ingénieurs, donc c'est notamment des gens qui produisent du code. Et donc, il a fallu trouver ensemble une manière de travailler, une manière de travailler efficace, qui nous permette néanmoins, en tant que société qui travaille majoritairement sur le web et en mode SaaS, trouver un moyen de fonctionner qui nous permette de déployer très, très fréquemment. Donc quand je dis très fréquemment, là vous avez ici le nombre de déploiements en production sur GitHub.com sur une semaine. Donc en moyenne, ça fait à peu près entre 80 et 90 déploiements en prod par jour. GitHub.com, pour ceux qui connaissent moins bien, c'est à peu près 25 millions d'utilisateurs enregistrés, c'est 60 millions de visiteurs uniques par mois.
En ce moment, avec le Black Friday, on a reculé un peu parce que c'est plutôt les sites d'e-commerce qui remontent, mais on navigue entre la 50e et la 60e place des sites mondiaux sur le web. Pour un site de développeur, c'est quand même pas mal. Et vous imaginez que l'infrastructure pour gérer ça derrière est assez conséquente. On parle de plusieurs milliers de serveurs en prod sur GitHub.com. Donc il y a ces deux aspects-là, déployer très rapidement, déployer en permanence, et on verra pourquoi on veut déployer en permanence, et puis tout ça avec une organisation complètement décentralisée et distribuée à travers la planète. Donc comment est-ce qu'on fonctionne? Comment est-ce qu'on fonctionne pour que cette machine à création de software fonctionne bien? Le premier truc déjà, c'est que, surprise, on utilise énormément GitHub. Mais on l'utilise pas que pour les développements, on l'utilise pour plein de choses qui ne sont pas forcément de l'ordre du développement. Chez GitHub, les juristes utilisent GitHub, les commerciaux utilisent GitHub, le marketing utilise GitHub, tout le monde utilise GitHub. La première chose qu'on a faite, c'est qu'on a arrêté de s'envoyer des emails. Donc chez GitHub, si vous voulez parler à quelqu'un, si vous voulez communiquer avec un de vos collègues, dans quelque division que ce soit, vous ne lui envoyez pas un mail, vous allez dans un repo et vous créez une issue. Notre moyen de communication, c'est une issue. Il y a plein d'avantages. Ce qui veut dire, au passage, c'est que le marketing a un repository, le département des legal et des juristes ont leur repository, tout le monde, toute équipe a son repository, pour certains du code, mais pour d'autres, pas de code, en fait, ça sera du markdown, ça sera des fichiers, des textes, à la sauce GitHub, on va dire. Donc quand je veux dialoguer avec un juriste, par exemple, je vais dans le repo des juristes et je crée une issue dedans. Avantage c'est indexé par github c'est visible pour tout le monde donc on est en communication ouverte et puis une issue c'est quelque part c'est un email mais en mieux parce que comme un email j'ai un titre comme un email j'ai un contenu mais contrairement à un email j'ai des métadonnées je peux mettre des labels dessus je peux dire de quel type de discussion il s'agit Je peux dire à qui est responsable de la discussion. Il y a la notion de la CNI. Je peux dire que ces personnes-là sont responsables de gérer cette discussion-là et potentiellement de faire un résumé de la discussion à la fin et de synthétiser. toutes les opinions et de sortir une décision là-dessus. Je peux mettre des milestones, je peux voir la liste des participants. Je suis sûr que cette discussion-là est la seule discussion qui existe. Si vous avez un email, ça peut partir dans tous les sens. Je peux faire des forwards à deux personnes qui eux-mêmes font des forwards à trois autres personnes, qui replyent pas à tout le monde mais qui ont une sous-liste, etc. Donc ça peut partir dans tous les sens et je ne suis pas sûr d'avoir la vue complète de tous les échanges qui ont eu lieu autour de ça. Et en plus, quand vous mentionnez cette discussion, cette issue dans une autre issue, il y a automatiquement un lien qui se crée et je peux naviguer de proche en proche comme ça pour aller voir les sujets connexes à cette discussion-là. Et en plus, je peux avoir quelqu'un qui va loquer la conversation à la fin en disant« c'est fini, maintenant on n'en parle plus, on est arrivé à la fin du sujet et on passe à l'étape suivante». Donc ça, c'est super intéressant pour nous. Et une des valeurs de ça, si vous n'êtes pas forcément convaincu par l'approche, une des valeurs de ça, c'est que je peux être un nouvel employé chez BitHub et accéder à toutes les conversations qu'on a pu avoir dans les 9 années d'existence de la société. Je ne suis pas, quand j'arrive en tant que nouvel employé chez GitHub, je ne suis pas dans un tunnel où je n'ai absolument pas de vision sur l'historique de la boîte. Et je vais pouvoir comprendre comment des décisions ont été prises dans le passé, quelles étaient les opinions qui ont été changées, quelle était la situation à l'époque. Et je vais être... Je vais avoir une meilleure empathie, on va dire, envers mes collègues qui ont pris cette décision-là à l'époque avec un contexte donné que je ne connais pas. Ce n'est pas aujourd'hui, qui peut être complètement différent. Mais des fois, des décisions peuvent paraître mauvaises aujourd'hui, alors que le jour où elles ont été prises, elles étaient plutôt bonnes. Donc ça, c'est un des éléments fondamentaux. Et c'est vraiment la pierre angulaire de notre système. Parce qu'en étant complètement décentralisé chez GitHub, On ne peut pas se baser sur la culture orale pour prendre des décisions. Quand j'ai un ingénieur qui est en Australie, qui est dans la même équipe que deux autres personnes qui sont en Écosse et puis l'autre sur la côte ouest des États-Unis, la culture orale, d'un coup d'un seul, elle n'est pas effective. On ne peut pas avoir un call entre ces différentes personnes-là. Elles ne peuvent pas se rencontrer, évidemment. On ne peut pas faire un scrum meeting. Ce n'est pas possible. Même un call, ce n'est pas possible, puisqu'ils sont dans des fuseaux horaires complètement différents. Donc cette partie complètement écrite, elle est super importante. Et on est arrivé jusqu'à se dire chez GitHub que si une discussion n'est pas écrite quelque part, c'est qu'elle n'a jamais eu lieu. Si une discussion n'a pas d'URL que je peux partager avec quelqu'un, elle n'a jamais eu lieu. Et évidemment, une issue, c'est l'endroit de nos discussions et ça porte forcément une URL que je peux transmettre à quelqu'un pour qu'il puisse comprendre ce qui s'est passé. Et encore une fois, c'est historisé, ça reste là pour toujours. Donc ça, c'est super important pour nous. Évidemment, ces discussions, on peut les organiser à travers nos projets dans GitHub, avec ces boards qui nous permettent de hiérarchiser et de suivre l'état d'avancement des choses.
Après, quand on va travailler sur du code, on a aussi cet outil qui est super intéressant pour nous et qui l'est aussi pour vous, j'espère. C'est la notion de pull request. Donc la pull request, pour ceux qui connaissent moins bien GitHub, c'est une discussion, un peu comme les issues, c'est une discussion qu'on va attacher à des fichiers qu'on est en train de modifier. Traditionnellement, ces fichiers-là, c'est du code. Mais ça peut être aussi du markdown. Donc encore une fois, nos juristes, quand ils travaillent sur un document, quand ils travaillent sur un contrat, quand ils font des choses comme ça, potentiellement, ils vont le faire à travers du markdown. Et puis, ils vont discuter de ce fichier-là à travers la pull request. Ils vont voir les différentes révisions. Ils vont voir comment ça évolue. Si vous voulez, vous pourriez le faire avec un Google Doc ou d'autres choses comme ça. Mais là, vous avez vraiment tout l'historique de tout ce qui s'est passé, de qui a modifié quelle ligne, quand, pourquoi, etc. Donc c'est une traçabilité qui va bien plus loin que ce que vous pouvez avoir dans Google Docs. Alors ça demande un niveau de formation un petit peu plus élevé qu'un Google Doc. Ce n'est pas tout de suite appréhendable par n'importe qui, mais tous nos juristes ont toujours réussi à le faire, tous nos nouveaux commerciaux ont toujours réussi à le faire. Le ticket d'entrée n'est pas si élevé que ça au final. Donc on travaille là-dessus. Et donc, ça marche bien dans le cadre non-dev, on va dire. Et dans le cadre dev, c'est super intéressant aussi. Donc, pour ceux qui connaissent moins bien tout ce système-là, l'idée, c'est d'avoir des discussions autour du code qu'on est en train de créer, d'avoir des discussions le plus tôt possible, et d'avoir des discussions à la fin sur le produit fini. La discussion sur le plus tôt possible, ça j'insiste là-dessus, très souvent les gens ouvrent une pull request parce qu'à la fin de la pull request, on a du code qui a été créé et nos développeurs vont aller faire ce qu'on appelle une code review. Donc ils vont aller lire le code des autres et dire ce que tu as écrit c'est bien, ce n'est pas bien, il faut que tu changes ça, etc. Et généralement, ils ouvrent la pull request à la fin, une fois que le travail a été fait. Donc nous, on encourage à l'ouvrir très tôt pour discuter avec le reste de l'équipe de ce qu'on va faire et comment on va le faire et quels sont les impacts qui vont être impliqués. Par cette ouverture de pull request. En partageant très tôt ce qu'on va vouloir faire, on va pouvoir avoir un consensus sur la roadmap de ce qu'on va développer. Donc sur une feature en particulier, on va pouvoir dire voilà comment je vais la faire, voilà ce que je vais modifier, est-ce que vous êtes d'accord avec moi? Si les gens sont d'accord avec moi, je vais pouvoir commencer à travailler. Et derrière, quand mes collègues vont aller regarder mon code, quand ils vont faire une code review, ils sauront exactement de quoi on parle. Ils savent à quoi s'attendre, ils ne sont pas surpris. Donc ils vont pouvoir m'amener un feedback qui sera positif, constructif, et on ne va pas perdre notre temps dans des débats idéologiques sur des concepts de code, parce qu'on était d'accord
d'entrée de jeu sur la direction dans laquelle on allait aller. Et ce processus de code review, si ce n'est pas... quelque chose de très répandu dans vos équipes, moi je vous encourage vraiment à le mettre en œuvre. Parce que la code review, c'est déjà ce qui nous permet de capturer un maximum de bugs, mais c'est aussi quelque chose qui permet aux gens d'apprendre. Et cette notion d'apprentissage du code et des techniques de développement est super intéressante. Parce qu'en étant un reviewer, en relisant le code de quelqu'un, je vais apprendre, je vais découvrir ses techniques de programmation, son style de programmation, c'est un peu comme le style d'un écrivain, et je vais découvrir des nouvelles choses. Et puis je vais aussi apprendre, je vais aussi éduquer les autres avec mes idées à moi, avec mes manières de faire, etc. Donc c'est vraiment un échange bidirectionnel. Et très souvent, les équipes se disent, on va prendre notre meilleur développeur et c'est lui qui va revoir le code de tout le monde. Et puis c'est lui qui va un peu diffuser ses pratiques à lui. Alors qu'en faisant ça, on se prive d'une grande richesse d'échanges entre les différentes personnes et d'apports mutuels d'informations. Et encore une fois, un junior peut revoir le code d'un senior parce qu'il y apprend énormément de choses.
Il y a le cas par exemple de Noroto dans le nord de la France. Ils avaient décidé d'aller sur des nouveaux langages, sur du Scala par exemple. Et il n'y avait que très peu de développeurs qui connaissaient du Scala. Ils ont forcé tous les autres développeurs à relire le code Scala des autres. Ils n'y comprenaient rien au début. Mais à force de le relire, ils ont commencé à comprendre non seulement le langage, mais aussi la philosophie qui allait derrière. Et après, ils sont devenus des développeurs scolarés. Donc en effet... forçant à faire des relectures comme ça, ils ont petit à petit bien compris ce qui se passait dans le code et ils ont été capables de monter en compétence. Aussi, en faisant ça, en distribuant comme ça les revues dans l'équipe, on réduit d'autant ce qu'on appelle le truck factor. Ça vous dit quelque chose, le truck factor? Le truck factor, c'est l'impact qu'aura sur votre projet le passage sous un camion d'un de vos collègues. Donc plus mon truck factor est élevé, plus je suis, on va dire, résistant à la disparition d'un de mes employés sur mon projet. Donc j'ai diffusé la connaissance de mon code à travers toute mon équipe. Et donc je vais pouvoir être plus résilient on va dire. Donc ça c'est la pull request, c'est super intéressant et encore une fois pour du code mais aussi pour du markdown, pour du texte, des choses comme ça, vous pouvez l'utiliser, c'est super intéressant. Et ensuite, bon alors, je vais passer vite là-dessus, on a plein d'outils qui nous remontent de l'information, qui regardent notre code et qui nous disent ce qui se passe. Et ça c'est sur une pull request également, on a une vingtaine de jobs en fait qui nous remontent à chaque fois qu'on pousse du code, qui nous remontent de l'information sur l'état de notre code. Donc un développeur sait par exemple que sur la première partie, la partie de l'int, par exemple, là il a une erreur sur son truc et il doit revoir son code. Et vous voyez qu'ici, on utilise de l'intégration continue, on utilise ces concepts-là. Très fréquemment, l'intégration continue, c'est une ligne et ça vous dit... tout s'est bien passé ou alors un truc ne s'est pas bien passé. Après, c'est au développeur d'aller chercher dans ce système-là la raison pour laquelle quelque chose, dont on ne sait pas encore ce que c'est, ne s'est pas bien passé. Et là, l'idée, c'est de lui remonter plus d'informations possibles pour qu'à la rigueur, l'intégration continue soit quelque chose dont il connaisse l'existence, mais n'ait pas besoin de se soucier de ce qui se passe dedans et comment ça fonctionne. On lui remonte une information de plus haut niveau et on lui met sous les yeux, donc il n'a pas besoin d'aller chercher l'information. L'information lui est prémâchée et lui remonte directement. En plus, vous voyez que certains éléments, certains checks sont obligatoires, d'autres sont optionnels. Donc il sait également quel est le niveau minimum de qualité qu'il est obligé. Toirement attendu de sa part en fait. Et en plus, après, on lui remonte aussi de l'information sur tous les déploiements qui ont eu lieu. Donc ça, c'est pour la plomberie.
Et si je résume ça, c'est ce qu'on appelle le GitHub Flow chez nous. L'idée, c'est qu'un développeur crée une branche de fonctionnalité, ce qu'on appelle une feature branch. Il y a beaucoup de débats autour du concept de feature branch. Certains ont des feature branch qui durent des mois. Une feature branch, chez nous, ça dure entre quelques minutes et quelques jours, voire quelques semaines, mais jamais beaucoup plus que ça. Donc il crée une feature branch, il rajoute des commits, il ouvre très tôt une pull request, il discute de son code avec les autres développeurs. Et puis très rapidement, il livre. Donc très très rapidement, cette feature branch, Et en plus, après, on lui remonte aussi de l'information sur tous les déploiements qui ont eu lieu. Donc ça, c'est pour la plomberie.
Et si je résume ça, c'est ce qu'on appelle le GitHub Flow chez nous. L'idée, c'est qu'un développeur crée une branche de fonctionnalité, ce qu'on appelle une feature branch. Il y a beaucoup de débats autour du concept de feature branch. Certains ont des feature branch qui durent des mois. Une feature branch, chez nous, ça dure entre quelques minutes et quelques jours, voire quelques semaines, mais jamais beaucoup plus que ça. Donc il crée une feature branch, il rajoute des commits, il ouvre très tôt une pull request, il discute de son code avec les autres développeurs. Et puis très rapidement, il livre. Donc très très rapidement, cette feature branche, cette petite fonctionnalité sur laquelle il a travaillé, il va la livrer. Il va la livrer sur des environnements de test, sur des environnements de pré-prod, mais il va également la livrer en prod. Parce que chez nous, on a décidé qu'une feature ou un bout de code n'était valide que s'il était déjà passé en production. Donc pour mettre le tampon production ready sur un bout de code, il faut qu'il soit passé en production. Seule la production peut nous dire qu'un bout de code est compatible avec la production ou pas. Ça, je reviendrai dessus. Mais l'idée, c'est que, et on le reverra plus tard, c'est que dire qu'une tâche est terminée alors qu'elle n'est pas encore en production, c'est se mentir à soi-même. Parce que comment vous pouvez savoir qu'elle est terminée à partir du moment où vous ne savez pas si elle fonctionne en production? Potentiellement, vous allez devoir la refaire. revoir parce qu'elle ne peut pas se déployer par exemple. Donc elle n'est pas terminée. Donc tous nos développeurs sont amenés à pousser leur code en production. Après, la notion de ce qu'on pousse en production est de facto assez différente de ce que vous avez l'habitude de pousser. Généralement, vous ne poussez que des fonctionnalités qui sont terminées. Nous, on a la particularité de pousser des choses qui ne sont pas terminées, qui sont en cours de développement. À partir du moment où je peux l'exécuter en production, d'une manière ou d'une autre, je vais vouloir le pousser. Je vais vouloir le pousser le plus rapidement possible. Donc dès que j'ai un bout de code que je peux activer d'une manière ou d'une autre, et on verra ce que j'appelle d'une manière ou d'une autre plus tard, comment je peux les activer, mais dès que j'ai un bout de code qui peut fonctionner en production, à ce moment-là, je le pousserai rapidement.
Ce qui fait qu'on a ce nombre de déploiements de 80-90 en production par jour. Et donc comment est-ce qu'on fait ça avec une équipe complètement distribuée sur la planète pour le faire le plus rapidement possible? Et l'idée étant d'avoir un feedback le plus rapidement possible également. Sachant qu'encore une fois, on a des milliers de serveurs.
Pour faire ça, on a créé un robot.
C'est quelque chose qui remonte à 5-6 ans maintenant, un robot qui s'appelle Ubot. C'est ce qu'on appelle un robot de chat ops. C'est un terme qu'on a créé. Chat ops, ça veut dire faire des ops à travers un client de chat. Donc Ubot, il se connecte sur notre chat. Donc on l'utilisait avant comme Fire, maintenant on l'utilise Slack, mais vous pouvez utiliser ce que vous voulez. C'est un projet open source, donc vous pouvez l'utiliser demain. Il se connecte à plein d'outils de chat différents. Et Ubot se connecte à ce chat et on lui envoie des commandes. Et c'est Ubot qui fait tout notre job. Donc c'est devenu, il y a même eu un article dans Wired sur Ubot, et puis dedans il disait que c'était l'employé de GitHub qui faisait le plus de boulot. Mais c'est vraiment la pierre angulaire de tout ce qu'on fait. D'ailleurs on a fait des cartoons, si vous allez sur notre chaîne YouTube, vous allez voir qu'on a fait des films d'animation sur Ubot. Au passage, on est une des seules boîtes d'IT à avoir trois personnes dans un studio d'animation et deux personnes dans un studio vidéo. On crée nos propres dessins animés, on crée nos propres vidéos nous-mêmes également. Donc on fait plein de trucs un peu délirants. On a fait des sculptures du bot géante en ballon dans nos événements. C'est assez important. Et puis, il nous permet de faire plein de choses. Donc là, c'est notre interface Slack. Et puis, je peux lui demander de me récupérer la carte d'un terrain de foot, par exemple. Je peux lui demander de me lister tous les food trucks qui sont à côté du bureau. Je peux lui demander de me trouver des images, des gifs animés, etc. Donc, ça sert à faire plein de trucs inutiles, mais aussi à faire des trucs utiles. D'accord? Donc, par exemple, du bot. Il est en permanence en train d'écouter ce qui se passe dans nos repositories, puisque c'est là que tout se fait, et il va dans les Slackroom qui sont linkés à ces repositories-là, donc par exemple la Slackroom des commerciaux, il va regarder tout ce qui se passe dans les repos des commerciaux, et dès qu'il se passe quelque chose, dans la Slackroom, il va afficher, tiens, il y a telle personne a commité tel truc, telle personne a ouvert tel truc. Et puis dans l'autre sens, il va regarder ce qui se passe dans Slack et il va détecter qu'on est en train de discuter d'une issue, d'une pull request. Et donc s'il détecte ça, il va aller dans l'issue, dans la pull request, créer un commentaire avec un lien, ce qui fait que les gens qui regardent l'issue vont dire« Tiens, il y a quelqu'un qui a parlé de cette issue-là dans une discussion Slack, je peux cliquer là-dessus et je peux aller voir cette discussion Slack qui a été archivée et puis suivre le fil des discussions qui ont pu avoir lieu dans un outil ou dans un autre. » Donc tout est connecté. Donc ça nous aide vraiment au quotidien et vraiment tous les systèmes qu'on manipule au quotidien sont interfacés via Ubot. Et c'est Ubot qui a toutes les clés de tout notre système. Nous, on n'a pas besoin d'avoir de login sur aucun des systèmes, puisque la plupart du temps, il y a un script Ubot qui, lui, sait se connecter à ce système-là et nous ramener l'information. Par exemple, Salesforce, je n'ai pas besoin de me connecter à Salesforce pour aller voir l'état de mes clients ou des choses comme ça. Je peux demander à Ubot d'aller me récupérer toutes les informations qu'on a dans Salesforce sur un client donné et les afficher directement. Mais bon, le premier cas d'usage de Ubot, c'était vraiment tout ce qui était déploiement en production. Donc quand un ingénieur veut déployer quelque chose en production, qu'est-ce qu'il fait? Il va dans Slack, il y a une chatroom spécifique pour ça, et puis il peut taper une commande, c'est WCID, c'est un shortcut pour dire« where can I deploy? » Et Ubot va lui donner tous nos... environnement de déploiement, donc les environnements de qualif, de pré-prod, etc. Et tous sont listés là. Donc certains sont virtuels, certains sont physiques.
Donc certains, les physiques évidemment, il y en a qu'un qui peut les utiliser à la fois, donc il y a une notion de lock, et la production évidemment, il y a une notion de lock dessus. Donc quand il va vouloir déployer sur la prod par exemple, Dans Slack, il va dire« je veux me mettre dans la queue de déploiement». Ubot va gérer une queue et un développeur à la fois peut déployer son code en prod. Nous, on appelle ça« tester en prod».
Il va se mettre dans la queue et Ubot va lui dire par exemple ici, il y en a déjà un qui est en train de travailler dans la prod, il y en a un autre qui est dans la queue, donc toi tu seras après. Potentiellement, tu pourras être après. Le développeur va taper une autre commande, il va dire« queue me to deploy». La queue me paraît gérable en termes de temps d'attente. Donc je vais me mettre dans la queue et puis préviens-moi quand c'est mon tour. Et puis quelques minutes plus tard, le développeur va pouvoir dire« Ok, moi je veux déployer ma fonctionnalité, donc .deploy, ma fonctionnalité dans l'environnement de production. »
Et c'est tout. C'est que ça à faire pour déployer du code en production stylitable. Donc vous voyez, c'est très facile de faire ça 80 fois par jour, c'est très facile de le distribuer partout sur la planète, puisqu'il n'y a aucun développeur qui peut se tromper là-dedans. J'ai aucun moyen de mettre en danger la prod, sauf si évidemment j'écris du code complètement pourri.
Mais c'est très, très, très difficile de me planter. Je ne peux pas. Je ne vais pas faire une mauvaise opération, une mauvaise manipulation sur un serveur de prod, puisque je n'y touche pas, le serveur de prod. C'est complètement automatisé et c'est complètement abstrait. Et là, l'idée aussi, c'est qu'un nouvel employé chez GitHub, au bout de 10 minutes, il peut déployer en prod. Il ne peut pas casser quoi que ce soit. C'est très facile. C'est impressionnant au début. On se dit, je l'ai grisé ici, mais grosso modo, vous voyez, la quantité de serveurs qui a été impactée sur un déploiement comme ça, c'est à peu près 900. Aujourd'hui, on a à peu près 900 serveurs déployés 80 fois par jour à peu près avec ce système-là.
Donc, c'est impressionnant, mais au final, une fois qu'on l'a fait, on se dit« Ah bah tiens, c'est que ça, et donc je peux le faire autant de fois que je veux au final. » Alors, Ubot fait pas mal de vérifications. Ubot s'assure que ça compile, que l'intégration continue est bien passée, que... Je ne suis pas en retard, je ne suis pas en train d'enlever des fonctionnalités. Il y a plein de vérifications qui sont faites pour sécuriser ça. Mais au final, c'est assez simple. Et en plus, après, ce qu'on donne au développeur, c'est qu'on lui dit, maintenant que tu as déployé quelque chose en prod, pour les quelques minutes qui suivent, tu vas être en charge du monitoring de ce que tu viens de déployer. Parce que l'idée aussi, c'est que c'est le développeur qui vient de pousser quelque chose, qui est le plus à même de détecter qu'il y a un problème dans son code avec les informations de la production. Donc on lui donne accès à cette application-là qui s'appelle A-Stack, donc c'est la boîte de foin, et c'est à lui de trouver les aiguilles dans la boîte de foin en fait. Donc on lui remonte toutes les aiguilles, donc toutes les aiguilles, Toutes les exceptions qui sont en prod sont ce qu'on appelle des aiguilles. Donc c'est à lui de les analyser. Et puis ce que vous voyez en haut, encore une fois avec la résolution on ne voit pas bien, mais il y a une timeline. Là on voit à peu près deux heures d'élapse de gauche à droite. Et toutes les photos correspondent en fait à des pull requests qui viennent d'être déployés. Donc toutes les photos ce sont les développeurs qui ont déployé leur travail en production. Et ce que je peux faire, si je vois des erreurs sur ces deux heures-là, c'est que je peux cliquer sur la photo de quelqu'un, ça va m'isoler la période de temps entre deux photos, et puis ça va m'isoler aussi l'app request qui est en jeu sur ce déploiement-là. Et donc je suis capable, sur une exception, d'aller très très rapidement à l'app request qui contient que le bootcode qui vient d'être déployé. Je n'ai pas deux mois de déploiement, j'ai deux minutes, deux semaines, deux jours, je ne sais pas quelle était la durée de la pull request, mais en fait je peux avoir un lien très rapide entre le code qui a été développé et puis l'exception qui a été générée.
Ma durée d'investigation est très très courte en fait, si jamais j'ai un problème. Et en plus, comme j'ai des déploiements qui sont très rapides, je peux choisir soit de revenir en arrière, revenir en arrière c'est redéployer une autre branche, ou alors de changer directement le code et de fixer l'erreur. Parce que, encore une fois, j'ai un temps de résolution qui est assez court, parce que j'ai une quantité de code à analyser qui est très très faible. Donc ça me donne énormément d'agilité sur la manière de corriger d'éventuels... Et on verra aussi que la durée, a priori, d'un problème en production va être très très courte. Parce que j'ai un monitoring qui est très focus sur ce que je viens de développer. Et sur un petit morceau. Donc les impacts sont très faibles. On reviendra là-dessus. Donc, Ubot me fait quelques autres choses aussi. Ubot, c'est lui qui reçoit tous les messages du monitoring et qui nous les affiche aussi dans Slack directement. Et puis, quand il y a un incident qui est généré, Ce qui se passe, une équipe de prod, quand il y a un incident, elle fait toujours à peu près les mêmes choses. Pour ce type d'incident-là, je vais vérifier tel indicateur, telle machine, tel service, etc. Et c'est un processus qui est assez répétitif. Donc nous, notre philosophie, c'est qu'à partir du moment où quelque chose est répétitif, on ne le fait pas. On demande à Ubot de le faire, on le code. Et donc, quand il y a un incident donné, c'est Ubot qui va ouvrir le ticket, et puis c'est Ubot qui va aller chercher les informations qu'on va généralement voir. Donc l'état des services, les graphes de production, les graphes de monitoring, tout ça, il le met directement dans l'issue. Et donc l'ingénieur de production, il n'a pas besoin d'aller faire ce premier niveau d'analyse. Il a tout sous les yeux et il peut travailler directement à partir de là et il peut aller plus loin. Et ce qui est super intéressant, c'est que comme tous nos systèmes, à la fois de monitoring, d'analyse de log, on utilise Plug par exemple, tous ces outils-là sont interfacés via Ubot. Donc quand j'ai mes ingénieurs qui sont dans une situation de crise, ils vont dans une Slackroom et puis ils se montrent les graphes qu'ils ont été chercher via Ubot. Ils disent, tiens, le graphe de la CPU. Et tout le monde, tous ceux qui sont dans la Slackroom, voient ce graph. Et donc on n'est pas en train de dire, tu devrais aller voir tel graphe dans tel dashboard, etc. On dit, tiens, regarde ce graphe-là, qu'est-ce que tu en penses? Et la discussion, de manière complètement décentralisée, se fait dans cette Slackroom, via des commandes qui sont envoyées à Ubot, et toutes les informations remontent là, et l'analyse se fait de manière concertée et commune. Et là, encore une fois, c'est un peu comme l'impul request, vous avez des ingénieurs qui vont juste regarder, qui vont apprendre les mécanismes et les réflexes des autres, plus expérimentés, et c'est quasiment un film
ou un reportage en temps réel qu'on suit, parce qu'on a des ingénieurs qui sont super costauds, et donc vous apprenez énormément juste par l'observation de ce qui se passe dans la Slackroom, parce que vous avez tous les échanges, vous voyez tout ce qu'eux voient, vous ne perdez rien, et vous pouvez vraiment apprendre beaucoup en travaillant de cette manière-là. Donc, on a déployé notre branche en prod, et si tout s'est bien passé, on peut merger avec Master. D'accord? Donc, on a déployé notre feature branche en production, on a regardé ce qui se passait, si on est content, s'il n'y a pas eu d'incident, on va dire qu'on merge avec Master. Si j'avais eu un problème, on redéploie Master. Master, c'était la version précédente de notre site, et puis si on merge avec Master, Master devient la nouvelle version officiellement validée de notre site en production. Tout simplement. Donc c'est vraiment tout simple, le déploiement, c'est soit ma feature branch, soit master, et avec avec ça, soit je vais en avant, soit je vais en arrière, mais j'ai jamais de cas plus compliqué que ça, j'ai les gros sous-moutons. D'accord? Donc généralement, quand j'explique ça, les gens se disent« voilà, c'est super, c'est génial». Et puis après, très rapidement, ils se posent plein de questions sur les détails, parce que là, je suis passé un peu vite, je vous ai dépeint un truc qui était tout rose, mais... On a souvent des...
Le mien, il ne bouge pas sur mon écran. Et on a souvent des questions, et surtout, quand je vous parle de ça, vous avez vu que je ne vous ai pas parlé de sprint. On n'a pas de notion de sprint. On n'a pas vraiment de notion de Kanban. On n'a pas vraiment de notion de Scrum. On ne sait pas faire de Scrum. On est dispersé à travers toute la planète, donc c'est impossible à faire.
On a une équipe de QA, une équipe d'acceptance, etc. Et encore, on n'a pas de personne en charge de l'acceptance. On a une équipe de QM qui travaille de manière très différente des équipes de QA traditionnelles. Et puis, on n'a pas vraiment de notion de release. puisqu'on déploie en permanence. On a quand même la notion de release, parce qu'il y a aussi une version de GitHub qui s'appelle GitHub Enterprise que vous pouvez hoster sur vos serveurs, donc pas en mode SaaS, mais en mode on-premise, mais c'est un peu différent, c'est à part. Mais notre manière principale de travailler, c'est assez simple.
Et puis, on n'utilise pas ce truc-là. Je ne sais pas si vos équipes ont déjà travaillé avec Git. Généralement, les gens vont sur Internet, ils tapent Git, ils tapent Workflow. Ils se retrouvent avec ce truc-là et se disent, tiens, c'est le truc à utiliser.
Et moi, je me suis repris à 12 fois pour comprendre le fonctionnement de ce truc-là. Donc, je me suis dit, à partir du moment où je n'arrive pas à le comprendre, ou je ne le comprends pas immédiatement, c'est qu'il y a un truc qui ne va pas avec. Donc, je ne sais pas si vous utilisez ça. Ça vous dit quelque chose, ça, ou pas? Ouais? Utilisez? Non? Oui? Non? T'as arrêté? Il y en a beaucoup qui essayent et qui arrêtent. Il y en a qui continuent à s'obstiner en se disant« Mais non, ça doit marcher normalement. » Mais non, ça ne marche pas. C'est trop compliqué. C'est trop compliqué et surtout, il y a trop de manipulations à faire.
Et il y a un dessin de comic strip qui résume ça. Je vous fais court. Le mec explique tous les processus, toutes les étapes par lesquelles il doit passer pour passer en production. Et au final, c'est tellement compliqué, c'est tellement peu répétable, il y a tellement d'interventions manuelles et de... Ils se retrouvent avec ce truc-là et se disent « tiens, c'est le truc à utiliser ».
Et moi, je me suis repris à 12 fois pour comprendre le fonctionnement de ce truc-là. Donc je me suis dit, à partir du moment où je n'arrive pas à le comprendre, ou je ne le comprends pas immédiatement, c'est qu'il y a un truc qui ne va pas avec. Donc je ne sais pas si vous utilisez ça. Ça vous dit quelque chose, ça, ou pas? Ouais? Utilisez? Non? Oui? Non? T'as arrêté? Il y en a beaucoup qui essayent et qui arrêtent. Il y en a qui continuent à s'obstiner en se disant« Mais non, ça doit marcher normalement. » Mais non, ça ne marche pas. C'est trop compliqué. C'est trop compliqué et surtout, il y a trop de manipulations à faire.
Et il y a un dessin de comic strip qui résume ça. Je vous fais court. Le mec explique tous les processus, toutes les étapes par lesquelles il doit passer pour passer en production. Et au final, c'est tellement compliqué, c'est tellement peu répétable, il y a tellement d'interventions manuelles et de...
De skills à avoir pour faire ça correctement, que sa copine résume à ça, nous aussi on fait des tests en prod. Parce qu'au final, si tu n'as pas un processus qui est répétable, qui est industrialisé, qui est automatisé, et qui s'exécute tout le temps de la même manière, c'est forcément une sorte de test à chaque fois, puisque c'est une nouvelle expérience à chaque fois. Chaque mise en production est une nouvelle expérience. Si vous faites des interventions manuelles pour faire des mises en production, c'est forcément une nouvelle expérience. Donc quelque part, c'est un test en prod. Donc quitte à faire du test en prod, autant le faire directement, mais ce n'est pas la peine de se trimballer ce niveau de complexité-là qui n'amène au final pas grand-chose. Ce truc-là, si on revient là-dessus, ce truc-là, il vient de notre manière de travailler fondamentalement.
Tous les gens, toutes les boîtes avec qui je parle aujourd'hui, c'est mon boulot d'aller aider les clients qui veulent passer à GitHub, qui veulent passer à Git, qui veulent changer leur manière de travailler. Tout le monde me dit qu'ils font de l'agile aujourd'hui. Il n'y a pas un mec qui me dit« Non, non, nous on fait encore du waterfall et des trucs à l'ancienne. » Donc ils me disent tous« Ouais, on fait de l'agile, on fait des sprints. » On fait des sprints de deux semaines.
J'en dis« Ouais, cool. » Et vous mettez en prod au bout de deux semaines? Ah ben non. On met en prod au bout d'un mois, au bout de deux mois, au bout de trois mois. Donc le fait de décaler cette mise en production, de faire plein d'allers-retours comme ça et de décaler la mise en production, fait que derrière, si on remonte la chaîne, on s'introduit plein de complexités pour pouvoir faire cette mise en production. On se complexifie la vie à cause de ça. Je vais revenir là-dessus. L'idée au final, et ça, je pense que tout le monde a lu le Phoenix Project ici, l'idée c'est que notre manière de travailler aujourd'hui fait que notre temps entre une idée et la mise en production, elle est super longue. Entre le temps où on a une idée et le temps où on la met devant un client, elle est super longue. Alors, on a cette... Cette fausse compréhension du mécanisme agile où on se dit on va faire une démo devant un PO et ça va suffire. Mais un PO, ce n'est pas un client. Ce n'est pas un utilisateur final. Ce n'est pas mes 2 000, mes 10 000, mes 100 000, mes 25 millions d'utilisateurs finaux. une personne, c'est deux personnes, et ce n'est pas forcément les vrais clients. Ce sont des gens qui ont normalement une meilleure compréhension du métier, mais ce n'est pas le client final. Ce n'est pas cette personne imprédictible, surtout si je suis dans le e-commerce, dans le B2C, ce n'est pas eux qui sont la vraie vérité. Donc ce n'est pas eux qui vont m'amener du feedback sur ce que je suis en train de faire, à la fois d'une manière business et à la fois d'une manière technique.
Donc, ce n'est pas intéressant. Ce qui est intéressant, c'est le vrai retour de la production et des vrais utilisateurs. Donc, si on résume ça, ce qui se passe aujourd'hui, c'est que tout le monde a son backlog avec ses to-do, ils ont leur work in progress. Puis après, ils font la QA, ils font l'acceptance, etc. Et ça, ça dure du temps. C'est pour ça qu'on ne met pas en production aussi très rapidement. Parce qu'on attend le retour du business. On attend cette démo, puis on attend potentiellement d'autres gens qui vont valider le truc, etc. Et donc, on a ces ninjas du Git qui arrivent, qui font du cherry picking, qui font crafter release, qui font des trucs super compliqués. Pour au final déployer. Et encore une fois, comme je vous le disais tout à l'heure, on a dit que c'était fini, mais on le déploie après. On n'est pas sûr que ce soit fini puisqu'on ne l'a pas encore déployé. On n'est pas sûr que ce soit fini puisqu'on n'a pas le feedback des utilisateurs. On ne sait pas comment c'est utilisé, on ne sait pas ce que ça remonte comme information, on ne sait pas tout ça. Donc nous, ce qu'on fait, si je remets en perspective la manière dont on travaille chez GitHub,
on a cette notion de to do, etc.
Clean Progress, mais on fait le déploiement tout de suite. On fait le déploiement tout de suite, et donc on n'a pas des ninjas du guide, mais on a des développeurs qui vont boire de la bière, parce qu'ils mettent en prod, ils regardent si ça fonctionne, et puis ils vont boire de la bière, et puis après, je schématise évidemment, mais en fait... À partir du moment où ils ont mis en prod, tout ce qui est QA, acceptance, etc., on peut le faire plus tard. On peut se donner le temps de le faire. Le code, il est en prod, ça ne veut pas dire que le client final le voit. Ça ne veut pas dire que vous le voyez. De toute façon, la fonctionnalité, d'un point de vue utilisateur, n'est pas forcément finie encore. Mais j'ai mon bout de code qui est potentiellement activé par tous les utilisateurs et sur lequel je suis en train de logger des événements, je suis en train d'apprendre sur son fonctionnement, je suis en train de voir s'il y a des erreurs ou pas quand on l'active, mais ça n'impacte pas mes utilisateurs. Donc c'est une manière un peu sécurisée, entre guillemets, de mettre du code en production et de voir s'il fonctionne réellement et d'itérer avec des choses qui sont déjà en prod. Et donc mes collègues, qui eux vont redéployer du code en production derrière, vont embarquer mon expérimentation. Donc on n'aura pas besoin de faire de la gymnastique avec des guides, des merges, etc. Plus tard, puisque tout le monde construit sur les expérimentations des autres et tout le monde embarque le code des autres. Donc on n'a pas besoin de faire de machine arrière, d'intégration compliquée, etc. Puisqu'on a livré à la fois en production mais dans le code partagé l'ensemble de ce qui a été fait.
La QA, l'acceptance, la QA, j'en parlais tout à l'heure, la QA, on en a. On a des gens qui font de la QA chez GitHub, mais les gens qui font de la QA, ils ne le font pas sur les fonctionnalités qui vont être mises en production. Ils le font sur ce qui est déjà en production. Ils font la QA sur le système qui existe déjà. Et ils sont plus en recherche d'optimisation qu'en qualification des fonctionnalités. Et encore une fois, on ne livre que des petits morceaux. Que des petits morceaux à chaque fois. Donc on est en incrémental. Planter complètement un système quand vous êtes en incrémental et sur des petites livraisons, c'est assez compliqué. Je l'ai fait quand même. J'ai réussi à planter le système. Je pourrais vous en parler. Mais c'est très rare, c'est très compliqué. Et en plus, mon plantage était... Plantage de mon point de vue, mais d'un point de vue utilisateur, c'était un vice. Néanmoins, c'est vrai que la première fois, quand on vous dit tu vas déployer en prod sur github.com, on a l'impression d'appuyer sur une télécommande qui va faire tout exploser, et puis ce qu'on veut, c'est éviter justement de se faire griller et d'exploser avec le système. Et comme je vous le disais, j'ai réussi une fois, vous voyez, c'était ce qu'on voyait tout à l'heure, et puis là c'est ma photo, on ne voit pas bien, mais j'ai réussi à déclencher à peu près 3500 descriptions à la seconde sur github.com en prod. Alors c'était des erreurs JavaScript dans vos navigateurs d'ailleurs.
Mais comme vous voyez ici, ça a duré 25 minutes. Comme c'est du JavaScript, il y a eu un temps de latence assez important, le temps que les gens rafraîchissent leur navigateur, rechargent la nouvelle librairie JavaScript, etc.
On n'est pas à 100% de taux de réussite. On a toujours de l'échec. Il y a toujours des erreurs qui arrivent en production. Mais avec les systèmes traditionnels, les systèmes anciens de déploiement, il n'y a jamais eu 100% de réussite. Il n'y a personne ici, avec toutes ces équipes de QA, toutes ces équipes de test, tous ces workflows, tous ces process d'approbation, etc. Personne n'a 100% de réussite. Néanmoins, avec vos systèmes compliqués, le temps que vous allez mettre pour identifier, corriger, relivrer une application en production va être beaucoup plus important que ce que j'ai ici. 25 minutes pour revenir à un fonctionnement optimal. C'est rien du tout. Montant de détection, montant de résolution, et là en plus, on n'est pas revenu en arrière. On a eu le temps de corriger la fonctionnalité, donc de garder la fonctionnalité, mais d'avoir un fonctionnement normal. On n'a pas perdu de fonctionnalité. Il n'y a pas eu de retour arrière, il y a eu relivraison du fixe sur cette fonctionnalité-là. Vous voyez, avec ce système, Au final, on ne prend pas plus de risques que ce que vous avez aujourd'hui. Et je dirais qu'on en prend même moins. Encore une fois, on peut quand même arriver à des problèmes, mais on y arrive beaucoup moins et les impacts d'un côté business sont beaucoup plus faibles. Je n'ai pas des indisponibilités qui durent des jours et des jours. Donc comment est-ce qu'on fait derrière pour aussi se permettre de sécuriser tout ce système-là? On a quelques frameworks. Tous ces frameworks-là sont open source, donc vous pouvez les utiliser. Ils sont a priori plutôt développés pour notre stack technique, mais il y a toujours des équivalents dans d'autres stacks techniques. Nous, pour info, on est sur Rails, Ruby on Rails, mais vous avez les équivalents qui ont été recréés derrière pour du JavaScript, pour du Java, du .NET, etc. La première chose qu'on utilise, et ça, si vous ne faites qu'une seule chose, à la rigueur, pour moi, c'est celui-là qui est le plus intéressant. C'est un framework qui s'appelle Scientist. Scientist, l'idée, c'est d'apprendre... D'apprendre le comportement, d'en apprendre plus sur le comportement d'un nouveau bout de code en production, en étant complètement sécurisé. L'idée de Scientist, c'est de se dire, ok, j'ai une version V1 aujourd'hui de mon code, J'ai envie de faire une version V2 parce qu'il y a plein d'avantages, parce que j'ai trouvé une nouvelle idée, une nouvelle manière de faire les choses. Mais je veux faire ça en étant sûr de mon coût. Et avec ça, je vais pouvoir avoir une requête utilisateur qui va être dispatchée sur les deux implémentations en production en parallèle. Et je vais pouvoir, sur le long terme, comparer les résultats de ces deux versions-là.
Ce qui fait que je vais laisser tourner en prod pendant une semaine, et au bout d'une semaine, je sais exactement dire si ma nouvelle manière de travailler fonctionne bien, fonctionne mieux, produit les mêmes résultats, produit des résultats qui sont cohérents, parce que ce ne sont pas forcément les meilleurs résultats que j'attends, mais au moins produit des résultats cohérents. Et si ça se plante, ce n'est pas grave parce que c'est Scientist qui me protège de ce plantage. Et c'est ce qui fait qu'on peut pousser comme ça en production des bouts de code pas finis ou des fonctionnalités à moitié développées. Parce qu'on les exécute à travers Scientist. Scientist, ça devient notre point d'entrée pour ce mini morceau de code. Et derrière, on apprend énormément. Et nous, chez nous, sur le site.com, des expérimentations, aujourd'hui, à l'instant T, dans Scientist, on en a à peu près 200 ou 300 qui fonctionnent en parallèle.
Tout passe par une expérimentation à un moment donné. Mon développement va commencer par ça. Et ce que je vais livrer, à la rigueur, c'est une expérimentation. Cette expérimentation, potentiellement, va être plus grosse, plus grande, plus ambitieuse. Mais je vais passer par des expérimentations et je vais regarder comment ça fonctionne. Et j'apprends. J'apprends très rapidement. C'est ça aussi, tout notre système d'agilité, c'est d'avoir une feedback loop la plus rapide possible et la plus intelligente possible. Donc on a ces hantises qui nous permettent de faire ça. Ensuite, on utilise du feature toggle ou du feature flipper, comme vous voulez. Donc on a un framework pour ça qui s'appelle Flipper, mais il y a plein d'autres frameworks qui sont disponibles. Et donc, notre cycle de release d'une fonctionnalité terminée passe par du feature flipping.
On va créer quelque chose et à un instant T, ça va être disponible que pour un certain nombre de personnes. Deux, trois développeurs, l'équipe de dev de cette partie-là du site. Après, ça va être tous les employés de GitHub qui vont pouvoir y avoir accès et donner du feedback. Et puis après, on va pouvoir décider de l'ouvrir au reste du monde, si vous voulez. Mais après, on peut décider aussi de l'ouvrir que pour la région parisienne, à la rigueur. On a cette possibilité d'ouvrir le robinet progressivement et de décider qui voit cette fonctionnalité-là. Donc dans cette philosophie d'apprendre progressivement et de ne pas prendre de risques, mais d'avoir des choses très rapidement en prod, ça nous permet aussi d'avoir pas mal d'agilité. Et c'est ce qui nous permet aussi de dire qu'on a fait la QR, on a fait l'acceptance, mais on l'a fait sur la prod, et on peut ouvrir une fonctionnalité au public sans avoir besoin de refaire un événement de déploiement. La mise à disposition d'une fonctionnalité aux utilisateurs finaux n'est pas corrélée à un événement de déploiement. Je peux déployer un mardi et donner la fonctionnalité à mes utilisateurs le lundi d'après. J'ai pu en attendant vérifier que ça fonctionnait bien en prod, j'ai pu avoir le feedback de l'ensemble de mes employés chez GitHub. Chez GitHub c'est bien parce qu'on est à la fois client et fournisseur, puisqu'on fait des outils de dev pour les devs. Donc on est à la fois le business et puis l'équipe de dev.
On a ce luxe, on va dire. Donc ça, ça nous permet de travailler sur notre code de manière assez sympa. Et puis, il y a toujours la problématique des données. On dit, si je change mon schéma de base de données, comment ça se passe? Pour ça, on a créé aussi un outil. Celui-là, il marche avec MySQL. Si vous n'êtes pas utilisateur de MySQL, ça ne va pas vous servir à grand-chose. Mais avec cet outil-là, on est capable de faire des migrations de schémas à la volée en produit.
Donc on est capable de dire voilà mes tables aujourd'hui, voilà mes tables demain, et bien migre-moi toutes les données et fais-le à la vitesse de X transactions par seconde, parce qu'on peut régler ça pour ne pas mettre à genoux la production. Et puis on peut complètement régler la cadence et puis on peut décider du moment où on va faire la bascule. Mais on peut aussi faire ça sur des tables temporaires. Et donc on peut remonter d'un cran en disant, tiens, je vais avoir une expérimentation où la V1 va taper sur la prod existante, sur RSIQOL, puis la V2 sur laquelle je fais une expérimentation, ça va travailler sur un nouveau schéma que j'ai dans l'étape temporaire, et après je peux comparer au niveau des bases, à la rigueur, voir que mon système est bien positionné. Puis après, si vous mettez Flipper par-dessus, le feature toggle, je peux aussi me dire, tiens, à un instant T, je vais à la fois utiliser la nouvelle version du code, plus la nouvelle version du schéma qui va avec, et j'ai ma bascule qui se fait immédiatement. Et donc j'ai synchronisé à la fois tout ça. Tout ça pour dire que ce qu'on fait, si vous y repensez bien, Ce qu'on fait, c'est un peu... Alors, on a beaucoup parlé, il y a beaucoup eu une fois, on a parlé de Camban, de Toyota, etc. Mais il y a un truc qui a été fait dans l'industrie automobile il y a quelques années. C'est qu'avant, ce qu'ils faisaient, c'est qu'ils designaient la voiture et après, ils pensaient à la manière dont ils allaient la produire. Et donc, ils avaient des cycles. Entre la décision de lancer un nouveau modèle et son lancement effectif, vous avez des cycles de 7 ans. Jusqu'au jour où ils se sont dit, en designant la voiture, on va aussi designer le prochain. 16 de fabrication. On va faire les deux en même temps. Et on va itérer là-dessus. Et ils sont arrivés à des cycles de production de 3 ans.
Et c'est exactement ce qu'on fait, nous. Jusqu'à présent, très souvent dans l'IT, vous avez des gens qui développent et puis vous avez les gens qui mettent en prod. Et c'est deux processus séparés. La personne qui fait une fonctionnalité ne pense pas à la manière dont elle va arriver en production. Il fait sa fonctionnalité. Après, on la met en prod. Et nous, ce qu'on fait, c'est vraiment qu'on mélange les deux. Le développeur qui développe quelque chose, Il se dit, il la découpe en fonction des étapes de mise en production de cette fonctionnalité-là. Et il réfléchit à son cycle de mise en production. Il réfléchit à quelles sont les informations que je vais récupérer à tel moment de la production pour savoir comment je vais développer l'itération suivante. L'itération suivante, elle est basée sur un retour de la production. Et j'ai cette information-là. Et j'y ai pensé quand j'ai développé ma fonctionnalité. Donc je ne suis pas que sur un point de vue business, mais j'ai aussi la connaissance de mon processus de mise en production et de ce que je peux récupérer comme information de ma production. Ça, ça nous permet d'avoir des développeurs qui sont beaucoup plus précis dans leur travail, qui sont beaucoup plus autonomes, et puis qui prennent moins de risques et qui sont mieux informés sur ce qui se passe. Et donc ça nous permet d'avoir beaucoup d'amour avec notre robot et d'avoir des développeurs très heureux. Voilà, j'ai presque rattrapé le retard. Si vous avez des questions, je suis disponible. Merci.

Transcription