 Ok, je vais m'exprimer en français. Est-ce que ça dérange quelqu'un ou pas ? Alors, pour ceux qui ont du mal à comprendre le français, j'ai fait un petit résumé sur mon site. Donc n'hésitez pas à y aller si vous comprenez pas un seul mot de ce que je dis. Peut-être qu'une prochaine fois, j'arriverai à le faire en anglais. Et le résumé est en anglais et les slides ce soir sont en anglais aussi. Donc voilà pour l'introduction. Alors, quand j'ai voulu parler ici, je me suis rendu compte que ça faisait 12 ans que je faisais des pitons. Et ça m'a un petit coup de vieux quand même. Mais au-delà de ça, je me suis rendu compte qu'est-ce que j'ai pu apprendre pendant ces 12 dernières années ? Est-ce que c'est vraiment le temps qui compte ? Et il se trouve que je me suis rendu compte au fil des années que finalement, une bonne partie des amis et collègues que je fréquentais, même s'ils faisaient aussi du piton, ils finissaient souvent pas faire des burn-outs et souvent parce qu'ils restaient plutôt seuls dans leurs coins à faire leurs codes. Donc la présentation de ce soir, c'est pour essayer de sortir de ça. Pour essayer de voir un peu ce que je mets derrière inclusif comme définition. Donc la définition sur l'objectionnerie, c'est un que je suis à peu près tout dans l'espace. Et pour ce soir, c'est essayer d'inclure le plus de monde possible. Comment est-ce qu'on essaie de faire du piton en essayant d'avoir le plus de monde possible ? Et au fil des années, je suis considéré que coder c'est un acte à la fois social et politique. Ce soir, je vais me concentrer sur le social, peut-être dans notre contexte sur le politique. Alors la première chose, c'est d'essayer de ne pas s'exclure soi-même. Je ne sais pas si vous avez des projets comme ça. Moi, il se trouve que j'en ai au moins un qui fait un peu mal. C'est un projet sur lequel on a du code qui tourne en production. On ne sait pas trop comment il est arrivé en production. Au début, il était juste un proof of concept et puis il a été en production et puis on a fait page sur page là-dessus et puis il n'y a pas vraiment de budget pour essayer de refactoriser tout ça. Et puis au bout d'un moment, il y a tellement d'aides techniques dessus qu'on n'a plus l'envie d'aller dessus. C'est-à-dire qu'au bout d'un moment, il n'y a pas vraiment de tests et puis on ne sait plus trop comment on déploie, on se sert de l'historique du chel pour aller remettre en prod. C'est assez terrible. Et au bout d'un moment, c'est même pas la difficulté technique, c'est juste l'envie. On se dit qu'il va me falloir une semaine pour le faire parce qu'il va falloir 6 jours de procrastination et le dernier jour, on va se dire, il faut vraiment le faire quand même là, ça craint. Donc ça, c'est la première chose, n'hésitez pas à vous exclure vous-même. J'ai appris assez difficilement sur certains projets et j'en ai encore un, je sais qui tourne en production comme ça. Donc voilà, enfin là-dessus, je ne vais pas parler beaucoup de piton au niveau technique mais là-dessus, les tests et les documentations, ça peut vous aider à avoir des fixtures des compagnies. Mais des fois, selon les cas, vous n'allez peut-être pas être dans ces situations. Oui, là-dessus, je voulais dire, avant d'essayer de tout changer, des fois, il faut essayer de se changer soi-même. Donc là, c'est un peu un voyage introspectif pour essayer de se dire, OK, je vois bien qu'il y a des projets qui foirent et je suis le principal acteur là-dessus. Comment est-ce que je vais faire pour essayer de m'améliorer finalement pour pouvoir atteindre ce genre de situation ? C'est aussi l'objet d'avoir de l'empathie, non pas uniquement pour les autres, mais aussi pour soi des fois. Alors je commence, c'est très centré après je vais ouvrir. Donc voilà, dis-vous que quand vous documentez, même si ça ne va pas forcément être pour quelqu'un d'autre, ça va potentiellement être pour vous dans 6 mois, voire 2 ans, à un moment où vous n'aurez plus du tout les mêmes outils et vous allez retourner dessus, vous allez vous dire mais je ne sais même plus comment lancer les tests à l'époque. Deuxième sujet que je voudrais aborder, c'est d'inclure ses collègues, bien sûr. Alors ça, c'est déjà essayé d'arriver à avoir une équipe. Je vous parlais un peu de mon parcours, j'ai été pas mal à mon compte pendant quelques années et au bout d'un moment, je me suis rendu compte que c'était plus intéressant finalement d'avoir des collègues. C'est pour ça qu'on a co-créé une coopérative de développement et aujourd'hui j'essaie d'intégrer des équipes aussi via cette coopérative pour avoir plus de monde autour parce que si vous restez tout seul dans votre coin, c'est sûr que au bout d'un moment, ça va être de plus en plus difficile. Donc avoir des collègues pour se serrer un peu l'écoute, des fois ça aide. Avant ça. Avant ça, donc vos collègues, c'est pas uniquement pour aller boire des bières à la fin de Montréal-Piton. C'est aussi pour les incur dans les décisions stratégiques peut-être du code que vous allez produire. Donc en amont même du code, essayez de les incur, qu'est-ce qu'on va, chacun fait quoi, etc. Ensuite, je ne sais pas s'il y en a qui font du Pair Programming parmi vous. Pas qu'en monde, ok. Donc moi ça fait 9 mois que je suis ici, donc je suis en Pair Programming à distance quelque part. Et enfin ici, vous aurez compris avec mon accent que je suis plutôt de français. Et donc ça fait 9 mois que je le fais avec du WebRTC et ça fonctionne plutôt bien. Ce qui se trouve, c'est que quand vous faites du Pair Programming, vous partagez la connaissance sur le code. Et en plus de l'expérience que va avoir l'autre, ça va vous permettre le jour où vous passez pas sous un bus, mais où vous êtes embauché par quelqu'un d'autre par exemple, d'avoir une connaissance partagée du code. Et ça c'est vraiment quelque chose de très important. Je ne sais pas si vous êtes dans des équipes où il y a une personne, par exemple quand elle n'est pas là, ça fait très très mal à l'équipe. Mais ça arrive. Et ensuite, une partie où vous pouvez travailler ensemble et une partie où après il se fait plus en asynchronous qui est sur des revues de code. Il y en a qui pratiquent les revues de code parmi vous. Ok, ça c'est un peu plus employé. Donc je ne veux pas trop décrire ce que c'est, mais c'est plus de revoir le code des autres qui permet aussi d'avoir un partage finalement de la connaissance sur le code et surtout de lever des questions. Les questions, ce n'est pas forcément essayer de modifier le code derrière, c'est aussi peut-être mieux documenter ce qu'on a fait à la fois dans les release notes ou les choses comme ça. Voilà dessus. Et je voudrais attirer un point particulier sur les personnes qui arrivent dans votre équipe. C'est vraiment l'occasion de challenger un peu ce que vous avez produit et de voir si la documentation actuelle est compréhensible et si quelqu'un sans aucune connaissance du projet va réussir à l'installer, ne serait-ce que ça, des fois c'est compliqué. Ou va comprendre dans quel environnement est-ce qu'il a besoin de faire ça. Donc là par exemple, on est en train de recruter et ce que j'essaie de faire c'est d'avoir une session avec chaque personne qui va arriver dans l'équipe ou je les laisse installer le projet. Moi je suis juste en visioconférence, je vois juste leur écran, ils me décrivent un peu ce qu'ils font et quelque part je les laisse un peu, aller au plus loin d'où est-ce qu'ils peuvent pour après ensuite on fait un petit récapitulatif de ce qu'il s'est passé ou est-ce qu'on peut améliorer la documentation ou est-ce qu'il y a des dépendances qui ne sont pas les bonnes etc. Donc ça c'est quelque chose qui peut vous arriver qu'une seule fois quand une personne arrive dans l'équipe. Donc n'hésitez pas à l'exploiter, ça permet d'avoir un feedback énorme sur la capacité d'installer votre outil. Alors essayer d'inclure aussi vos réutilisateurs. Alors là je suis peut-être dans un cas particulier je vais vous expliquer un peu le contexte. Ça fait deux ans que je travaille sur un portail qui s'appelle data.gov.fr qui est le portail des données ouvertes du gouvernement français à l'échelle nationale donc c'est tout fait en piton et ça permet de déposer des données et d'en indexer et que tout un chacun à la fois administration et citoyen puisse réutiliser ces données. Il se trouve que le portail lui-même est en open source et il se trouve également que ce portail a été réutilisé par d'autres pays. Donc c'est pour vous expliquer un peu le contexte. Quand vous avez ce contexte les gens qui vont venir réutiliser votre produit ça peut être à la fois des citoyens ou des développeurs d'autres pays ou même des développeurs qui vont vouloir intégrer l'équipe ou autre. Donc c'est quelque chose d'intéressant parce que ça met dans une position où on va avoir envie d'inclure d'autres personnes qui ne sont pas forcément officiellement dans l'équipe. Je ne sais pas s'il y en a beaucoup qui font de l'open source ici. C'est un cas peut-être un peu particulier mais dans ces situations-là ce qui va être intéressant c'est d'essayer d'avoir une bonne réactivité à la fois on utilise GitHub d'avoir une bonne réactivité dans les issues qui sont déclarés ou une bonne réactivité on utilise d'autres outils aussi comme GitHub des choses qui sont autour du code et qui permettent d'échanger. Donc la réactivité est vraiment clé à ce niveau-là parce que des fois vu le contexte ce sont des personnes qui ont même créé un compte sur GitHub juste pour nous soumettre une issue donc ils sont quelque part en attente. Ce n'est pas forcément des développeurs. Ils ne vont pas forcément non plus comprendre que nous on héberge juste la plateforme et que les données qui sont dessus sont toutes de notre ressort, même très peu. C'est-à-dire que des fois ça va être des bugs liés aux données alors qu'on n'a pas forcément la main dessus. Donc voilà, il y a tout un travail d'éducation autour de ça qui est intéressant. Une des choses qui a été documentée par quelques blog posts ah oui, je n'ai pas toujours mis les liens etc pour l'instant sur le support mais sur le résumé vous les trouverez je mettrai le résumé sur Meetup et autres. Une chose qui peut être intéressante c'est d'identifier certains problèmes qui vont être faciles à résoudre et se dire c'est pas critique, on peut les laisser un petit peu on peut les laisser une durée de vie d'un mois ou deux et s'il y a quelqu'un qui passe et qui veut rentrer sur le projet ça va être beaucoup plus simple de passer par là parce que si c'est 3 lignes de CSS ou 2 lignes de Python le faire comme ça sur une pôde request ça peut passer et ça peut être pour quelqu'un qui va prendre confiance et se dire ok c'est intéressant de bosser avec eux, ils sont réactifs mon code il est déjà en prod et c'est génial donc voilà un exemple ça les labels c'est sur les issues GitHub j'imagine que vous connaissez alors, inclure aussi les maintenaires c'est à dire que quand on a un projet avec beaucoup de dépendance on dépend aussi de tout ce qui est upstream c'est à dire tout ce qu'on tire et d'autres choses ne pas oublier que à chaque fois que vous contribuez à un projet vous donnez de la dette technique à quelqu'un d'autre en lui disant débrouille toi donc ne pas hésitez à ajouter test, documentation, pourquoi est-ce que vous faites ça etc et en retour quand c'est à vous de contribuer faire demander ces choses-là quand on vous soumet des pôles request sinon c'est vous qui allez devant entretenir des choses qui ne sont pas testées alors quelque chose sur lequel j'essaye de travailler personnellement c'est essayer aussi d'inclure plus de monde dans la gouvernance du projet finalement parce que là comme je vous expliquais c'est un projet qui a été réutilisé par d'autres pays donc comment est-ce qu'on décide de telle fonctionnalité on va l'ajouter qui décide comment les fonctionnalités sont ajoutées etc c'est quelque chose qui à la base était juste lié à notre équipe et c'était plutôt plus ou moins facile mais quand ça prend une ampleur un peu plus internationale, ça devient compliqué de se dire ah oui mais attendez est-ce que Luxembourg est d'accord pour qu'on ajoute cette fonctionnalité et sur quoi est-ce qu'ils sont en train de bosser etc donc ça demande beaucoup plus de communication et c'est un aspect aussi intéressant des projets de voir comment est-ce qu'ils peuvent évoluer à ce niveau-là Ne pas oublier d'inclure les personnes qui y arrivent pour la première fois sur du code piton aussi ça arrive et pour ça ce qui est bien dans la communauté piton c'est qu'on a pas mal d'outils il ne serait-ce que le pay-puit qui permet d'avoir certaines structures et certaines conventions et qui aident pas mal il y a iSort je ne sais pas si vous connaissez qui permet d'ordonner les imports il y a plein de choses comme ça qui vont vous permettre d'aimer une bonne partie de ce que vous allez faire comme review sur une poulrée code de débutant mais il y a d'autres choses aussi qui sont plus inérentes aux codes, c'est-à-dire essayer d'écrire un code qui soit suffisamment simple pour qu'il soit compréhensible quelque part avant d'imbriquer des meta-classes etc, demandez-vous ah oui mais quelqu'un qui ne connaît pas piton va comprendre ce qui se passe là pour ça un bon test c'est d'essayer peut-être de demander de l'équipe d'à côté qui font du rubis ou autre de leur dire bah attends viens faire un code review viens essayer de comprendre ce qui se passe ça peut vous apporter quelque chose d'avoir leur avis même s'ils n'ont jamais fait de piton au moins s'ils comprennent un peu les structures de code alors bien sûr ok je ne l'ai pas dit on aime tous un piton qui est idiomatique qui utilise bien les structures du langage parce que je vous dis c'est pas de mettre ça à la poubelle c'est juste de réfléchir à chaque fois est-ce que quelqu'un qui qui comprend pas trop qui est plutôt débutant va réussir à relire votre code et la dernière étape c'est d'inclure les citoyens alors ça c'est encore très ouvert parce que je pense qu'on n'a pas encore trouvé comment le faire donc c'est pour ça que je le mets en guise de questions comment comment faire en sorte que les citoyens s'emparent d'un produit et se rendent compte qu'ils aient la possibilité d'influer là-dessus sachant que finalement c'est un produit qui est construit un peu avec leur taxe donc pourquoi pas est-ce qu'ils aient un droit de regard dessus et pourquoi pas est-ce qu'ils pourraient prioriser certaines fonctionnalités il y a beaucoup de travail qui a été fait en amont des projets je pense à tout ce qui est l'in startup pour aller au-devant des utilisateurs il y a un peu du feedback avant de créer quelque chose mais je trouve qu'il manque peut-être un peu des outils pour avoir un ligne maintenance pour aller vers comment est-ce qu'on maintient un produit avec ces utilisateurs comment est-ce qu'on décide telle fonctionnalité finalement elle ne serve pas grand monde on peut les enlever ça c'est quelque chose qui est très difficile à faire sur un produit ou telle fonctionnalité elle est demandée par suffisamment de monde pour qu'on se dise voilà dessus je vais conclure je suis large ça va si vous voulez re-retenir 2 choses la première c'est que votre code n'est pas un livre mais plutôt un processus itératif donc n'hésitez pas à discuter, à vous améliorer etc je trouve que Python est très bon là dessus pour itérer sur du code pour essayer de le simplifier pour essayer de le modulariser etc c'est un langage qui a une certaine force la deuxième chose c'est que si vous êtes loin de ce que je vous ai expliqué aujourd'hui c'est pas grave c'est tout à fait possible je pense que je suis même loin moi-même et ce que je vous décris c'est juste quelque chose aussi où je veux aller sachant que c'est un chemin à suivre n'hésitez pas à suivre le vôtre et à me faire vos retours merci