Mettre en place une communication efficace dans les équipes tech

0:15 Le meet-up d'aujourd'hui, ça va parler justement de la partie communication dans des équipes tech. On va parler de plusieurs sujets, du sujet au sein d'une équipe, comment est-ce qu'on peut communiquer, comment est-ce qu'on peut faire du mentoring, justement du mentoring technique, du coaching technique et même comment est-ce que les différents membres d'une équipe doivent communiquer entre eux. Un peu plus à l'échelle. Comment est-ce que cette communication doit se mettre en place au sein des différentes équipes et entre les différentes équipes? Évidemment, on va parler des communautés de pratique qui sont souvent mises en place, ou des chapters, ou des guides, et de tips qu'on va avoir un petit peu autour de ça. Et enfin, encore plus loin, pour élargir la communication, on parlera de la communication entre différentes entreprises et en dehors de notre entreprise, donc avec la mise en place de nouveaux postes comme des Tech Community Ambassadors qui vont pousser les équipes, les développeurs du coup à se partager des choses en dehors d'entreprise.

1:19 Pour ça, je vais inviter Dorra et Tanguy à monter sur scène avec moi, qui seront du coup les deux personnes qui vont pouvoir partager un petit peu leur ressource. retour d'expérience. Donc Dorra, Tanguy, vous pouvez monter dès que vous pouvez. Comme ça, on fera un petit tour de table pour se présenter un petit peu chacun d'entre nous. Et derrière, on en profitera pour partager un petit peu ces différents retours. Alors, on va attendre Tanguy qui va nous rejoindre également. Et après, on va pouvoir faire nos petits tours de table. À la limite, le temps que Tanguy nous rejoigne, je le vois qui est en train de monter sur scène. C'est toute une histoire pour monter sur scène. Et il est en train d'arriver. Il y a des marches. Ah, c'est ça. Salut Tanguy. Hello. Tu sais, les solutions techniques, c'est souvent un peu touchy. Super, merci de m'avoir rejoint.

2:20 On peut faire un petit tour de table pour se présenter. Je te laisse démarrer, Dorra. Avec plaisir. Merci déjà pour l'invitation à Tech.Rocks et puis à Arthur aussi. On va dire que je connais du monde déjà, donc je suis plutôt à l'aise, on va dire. Et je m'appelle, pour ceux qui ne me connaissent pas, je m'appelle Dorra Bartaguiz, je suis VP Tech d'Arolla, donc je fais partie de la direction technique. Arolla, c'est une USN parisienne qui prône un petit peu le craft, on va dire, et les bonnes pratiques de dev. Et je suis aussi, je fais partie des coachs. aroliens et aroliennes. Donc, j'accompagne les équipes en tant que coach craft pour monter en compétence sur les bonnes pratiques telles que TDD, BDD, DDD aussi. Et pour ceux qui n'ont pas vu le bouquin, je suis co-auteur aussi d'un bouquin qui s'appelle Software Craft. Qui est dans les éditions du Nau, qui est sorti cette année, en avril, de mémoire.

3:25 Enfin, l'année dernière, 2022. Et voilà. Tanguy, je t'en prie. Ok, bonjour à tous. Merci déjà d'être là. Je ne sais pas combien on est, mais j'ai l'impression qu'on est assez nombreux. Donc moi, je suis Tanguy Le Gall, je suis d'Allianz, enfin je travaille pour le groupe Allianz en fait, et je suis chez Allianz Technologies, donc on va dire la branche IT. De l'assureur. Alors, moi, perso, j'ai rejoint cette entreprise en 2003. Je suis manager d'un département IT aujourd'hui et j'ai une grande expérience de management, on va dire, depuis 2007 autour de tout ce qui est équipe web. Développement web et aussi alors pourquoi je suis là aujourd'hui et merci merci Arthur et à Tech.Rocks pour l'invitation en fait parce que j'ai largement contribué à lancer des communautés de pratiques en fait autour du craft en local France chez Allianz.

4:32 Et puis, je raconterai un petit peu l'histoire, mais en global maintenant au niveau Allianz Technologies Monde. J'ai pas mal d'activités aussi autour de la, bon c'est un peu d'actualité, tout ce qui est Sustainable IT dans l'entreprise et puis aussi pour la petite histoire, Je suis parrain d'école d'ingénieurs aussi dans la région parisienne, au nom d'Allianz. Voilà, voilà pour moi. Merci pour... Pour ces présentations, pour terminer le tour de table, moi je suis Arthur Magne, CTO et cofondateur d'une startup qui s'appelle Promyze. Depuis 2014, on travaille sur deux projets, ça vient du laboratoire de recherche de Bordeaux et on accompagne, on est éditeur de logiciels, en gros on propose des... Des plugins pour les IDE et des outils de revue de code qui aident des équipes et des communautés de pratique justement à se partager des expertises et à communiquer plus facilement sur des sujets tech, que ce soit un peu n'importe quel sujet, sustainability, architecture, clean code, test, etc.

5:35 Donc évidemment, on a depuis quelques années accompagné pas mal de clients plutôt grands comptes, ESN, dans différents secteurs, qui ont mis en place justement des communautés de pratiques et qui ont essayé justement de pousser au maximum la communication entre les équipes tech. Donc l'avantage, c'est que maintenant, d'un point de vue un peu neutre, on a pas mal de retours d'expérience aussi sur ce qui marche bien, sur ce qui marche. Ce qui marche moins bien, et les petits tips aussi à mettre en place autour de ça. Donc, pour repartager un petit peu la problématique de pourquoi est-ce qu'on vient raconter tout ça aujourd'hui et pourquoi est-ce qu'on met en place aussi ces communautés de pratique, évidemment, je pense que vous êtes tous au courant que notre métier dans la tech, qu'on soit... Dans les équipes de développement, qu'on soit sur la partie DevOps, sur la partie test, sur la partie data, ou n'importe quoi. On doit apprendre de plus en plus de choses aujourd'hui pour... que ce soit les différentes évolutions des langages, des frameworks, des technos, Aujourd'hui, quand on sort d'école, on a une base de connaissances.

6:39 En fait, on va passer toute notre vie dans les équipes tech à apprendre tout le temps des nouvelles choses. Pour autant, notre cœur de métier, ce n'est pas de passer notre vie à apprendre des choses, c'est aussi de produire des choses. Donc évidemment, c'est un peu compliqué tout seul de se faire notre propre chemin d'apprentissage, de regarder énormément de choses, etc. On a l'avantage de travailler en équipe dans l'IT la plupart du temps. Et l'intérêt de travailler en équipe, justement, c'est de pouvoir être capable de se partager des connaissances entre nous et de bénéficier de l'intelligence collective de tout le monde. Pourquoi? Parce qu'aujourd'hui, on a beaucoup d'hétérogénéité dans les équipes de développement. Donc ça, c'est des choses qu'on a pu voir depuis quelques années, mais c'est encore plus vrai depuis qu'il y a pas mal des codes de reconversion aussi qui arrivent. On a beaucoup d'écoles, que ce soit à Bordeaux, ici ou partout en France. Et ce qui est très bien, parce que du coup, ça amène des nouvelles personnes avec un regard neuf dans les équipes, mais ce qui amène aussi des problématiques de communication. Parce que quand quelqu'un arrive et n'avait pas fait d'informatique il y a quatre mois et arrive dans une équipe avec des gens qui ont 20 ans d'expérience et qui ont fait des écoles d'ingé avant, évidemment, il faut que la communication se passe bien, aille dans tous les sens

7:48 et qu'on arrive à bien accompagner ces personnes dans les équipes pour les faire monter en compétence. On a également toutes les problématiques liées au turnover, à l'onboarding, qui aujourd'hui sont très fortes dans le domaine de l'IT. Et donc, plus on a de turnover, plus on doit avoir une communication efficace pour accompagner et onboarder le plus rapidement possible des nouveaux arrivés. Donc du coup, la solution, c'est assez simple, c'est de travailler sur ce partage de connaissances et sur l'intelligence collective. Donc ça paraît simple, mais évidemment, c'est très compliqué. Il y a plein d'écueils, il y a plein de choses assez compliquées à mettre en place. Donc les vrais problèmes, on va en parler, mais ça va être l'humain. On peut avoir des problèmes d'ego, on peut avoir des problèmes de communication, des problèmes de transition, de mise en place, etc. Et l'idée, c'est de voir un petit peu justement ce que vous, vous avez comme retour d'expérience, Dorra et Tanguy, à ce niveau-là. Toi, Dorra, qui fais du coaching technique justement et qui est un petit peu mentor de l'équipe, comment ça se passe du coup quand tu rentres dans un nouveau contexte avec les nouvelles équipes?

8:53 Oui, effectivement, surtout quand on arrive en tant que coach, il y a justement cet aspect de, on est externe par rapport à l'équipe. Donc, le temps d'arriver, d'être onboardé, il faut qu'on arrive aussi avec, c'est vrai qu'il y a cette légitimité, on va dire, en tant que coach, mais on reste quand même externe par rapport à l'équipe. Et souvent on va être méfiant à l'égard du ou de la coach en question parce qu'on se pose la question comment ça va se passer Il y a cette peur ou cette crainte un petit peu de ce qui va se passer, de est-ce que ça va être une formation ou est-ce que ça va être, enfin, comment ça va se passer le coaching en général. Mais il y a aussi, par expérience, moi j'ai accompagné des petites équipes comme des grosses, et c'est souvent le même constat.

9:54 Donc quand j'arrive, effectivement il y a un accueil chaleureux au départ, mais il y a toujours cette petite crainte à côté. Et j'essaye de la casser via, par exemple, des icebreakers, en parlant de choses un petit peu qui sortent du cadre du boulot. Genre comme aujourd'hui, il y a grève des transports, mais je prends les transports quand même pour fuir la maison parce qu'il y a des petits à la maison. Donc voilà, c'est juste dire, quand on arrive, c'est vrai qu'il faut casser un petit peu cette barrière de personnes externes et l'équipe en face. Donc, j'essaye souvent de faire ça. Et puis après, il y a la partie aussi accompagnement au quotidien. Donc, avoir petit à petit gagné la confiance de l'équipe pour justement essayer de chercher qu'est-ce qui ne va pas. Parce que quand on arrive...

10:56 En tant que coach, souvent, ça veut dire qu'il y a des problématiques qu'on veut résoudre. Et on ne va pas venir avec une solution toute prête parce que de toute façon, ça ne sert à rien parce que les problématiques des équipes ne sont pas forcément les mêmes. Donc souvent, en tout cas chez Arolla, quand on arrive en coaching, on a toujours une phase, ce qu'on appelle du cadrage avant de démarrer le vrai coaching. C'est de dire qu'est-ce qu'on va essayer de récupérer un petit peu les infos du terrain des équipes. des différents membres des équipes. Et ça passe du coup par un établissement de cette confiance-là pour que les gens viennent nous chercher, du coup, viennent nous dire ce qui ne va pas réellement, parce qu'on a du mal à parler de ce qui ne va pas. On aimerait plutôt rendre une image positive des équipes et du coup, on va parler de tout ce qui va bien. Donc, il y a cette phase-là de...

11:57 Il faut qu'on brise cette glace, on va dire, et c'est la première étape pour que le coaching, en tout cas, passe dans les meilleures conditions. Donc effectivement, le premier obstacle ou le premier frein, ça reste humain, comme tu l'as dit Arthur. C'est vraiment la méfiance au début des personnes. Et du coup, pour casser cette barrière-là, on peut passer par des icebreakers, des discussions, beaucoup de discussions avec les personnes individuellement, souvent au début. Et après, on le fait par rapport au groupe. Je ne sais pas, Tanguy, peut-être que de ton côté, tu as d'autres expériences. Je t'ai passé en mute. Oui, alors nous, c'est vrai que moi, je suis côté client, du coup, je n'ai pas tout à fait le même prisme, mais on a effectivement aussi des difficultés.

13:03 Donc, juste pour réillustrer un peu, mais chez Allianz, on est passé en agile depuis 2018, à l'échelle de la France, en tout cas. Et on a 12 communautés de pratique en France et une vingtaine à l'international. Aujourd'hui, les communautés de pratique, étant en agile, juste pour revenir sur la partie agile, on a eu à un moment, je ne sais plus où on en est trop aujourd'hui, mais une centaine d'équipes agiles sur la défense. Ce qui pose quelques difficultés, parce que quelque part, ce mode un peu distribué, sans ajouter la pandémie en plus, qui a encore plus isolé les gens, mais ce mode agile avec des équipes distribuées a isolé un petit peu les gens de leur propre terre, en fait. Donc, les communautés de pratiques qu'on met en place permettent de réunir les personnes qui ont des pratiques communes, donc souvent les mêmes métiers, développeurs, mais pas que.

14:08 Ça peut être des communautés Scrum Master ou autres. Ça nous permet vraiment de mettre de la glue entre les personnes. d'Aliens. d'aligner les personnes sur, par exemple, des standards, bien sûr des bonnes pratiques, et globalement d'échanger. Mais ça a répondu en gros à cette problématique d'isolation, quelque part, des équipes, des personnes. Et encore, je parlais de la pandémie, la pandémie a un petit peu aggravé, les choses puisque non seulement on se retrouve dans une équipe agile mais en plus beaucoup chez soi en télétravail encore plus isolé. C'était un point qui était important dans ce que tu disais en gros le fait d'avoir fait des squads et des équipes sur le modèle de base de Spotify avec des tribes, des squads etc. Maintenant, on a des équipes pluridisciplinaires. On va avoir une à deux personnes qui ont le même profil un peu dans l'équipe, donc sur la partie back-end, sur la partie front-end, des gops, etc.

15:11 Ce qui fait qu'on va se retrouver à être encore plus isolé, entre guillemets, parce que si on n'a pas en place ces systèmes de communication, ces communautés, on se retrouve tout seul à faire du bac dans notre équipe. Et donc, pour tout ce qui est... Code évidemment c'est plus compliqué et on a l'impression de ne pas pouvoir vraiment progresser parce que on doit nous-mêmes aller faire des recherches et si jamais ça reste siloté on va avoir des vrais problèmes de silos de connaissances qui vont exister entre les équipes et on va avoir l'impression de réinventer la roue tout le temps en fait il y a quatre équipes tu disais qu'il y avait 100 équipes chez Allianz rien qu'à la défense donc dans le monde il y en a encore plus Et il faut imaginer que ces équipes, en fait, s'ils ne communiquent pas entre elles, elles vont passer leur temps à refaire un petit peu la même chose, à tomber sur la même problématique. Et elles ne vont pas du tout bénéficier d'un cerveau commun, on va dire, qui serait cette intelligence collective, qui leur permettrait de résoudre des problèmes plus rapidement. Oui, tout à fait. Donc, ça se repose bien sur créer, lancer des communautés de pratiques.

16:16 Donc ça, on peut être confronté à, on pourra en parler après, mais à certaines difficultés. Ce n'est pas forcément simple à lancer. Puis ça passe aussi par des outils comme Promyze, par exemple, qui apportent vraiment un support au partage des bonnes pratiques. Donc voilà. Oui, tout à fait. C'est vrai qu'en fait, la partie communauté de pratique, effectivement, on pourra en parler plus en détail sur comment les mettre en place juste après. C'est vrai que sur cette partie communication au sein d'une équipe, Le point important, je ne l'ai pas signalé, mais n'hésitez pas à poser des questions dans l'onglet Q&A directement. Le but, c'est qu'on les prenne en live et que ça puisse lancer aussi la discussion. L'idée, c'est qu'on puisse tous contribuer ensemble. Je vois qu'il y a une question déjà. À partir de quelle taille d'équipe trouvez-vous que cela vaut le coup d'avoir ces approches? Alors, si l'approche dont cette personne parle, c'est mes communautés de pratique, du coup, c'est vraiment ce qu'on voit dans la question.

17:25 Et si c'est ça, est-ce que vous avez une idée de la taille critique à partir de laquelle il faut qu'on investisse dans ces communautés de fait? Je dirais à partir de deux. Non, mais plus concrètement, en tout cas, pour ma part, par retour d'expérience, effectivement, quand on est deux, ça va. Quand on est trois, parfois, en fait, ça dépend de la proximité des personnes qui composent l'équipe. Et aussi la distance. Parce que si on est deux et finalement on n'est pas sur la même time zone ou la même ville en général, c'est vrai que la communication, elle est... Elle est réduite par rapport à s'il y en a côte à côte sur le bureau. Voilà, ce n'est pas tout à fait pareil. Mais en fait, dans tous les coachings, en tout cas, que je mène, souvent, je propose

18:30 d'appliquer un petit peu le pair programming full time parce que ça aide à briser cette... Cette isolation des personnes. Et ça permet d'anticiper, du coup, par exemple, les revues de code, d'anticiper des discussions, de potentiellement alimenter, effectivement, des bonnes pratiques. Et du coup, si on utilise, comme disait Tanguy, si on utilise encore des outils comme Promyze, ça permet de rajouter, d'enrichir un petit peu les pratiques de l'équipe. Mais en tout cas, je pense que... Pour répondre à la question, il n'y a pas de taille minimale. Ça dépend de la composition de l'équipe, ça dépend de l'affinité entre les membres. Tanguy, je ne sais pas si tu as envie de rajouter. Alors, la thématique d'aujourd'hui, la communication des équipes tech, la communication, je suis assez d'accord avec Dorra, c'est à partir du moment où on a deux personnes et qu'il y a des choses à partager pour avancer un petit peu dans le même sens, deux personnes suffisent.

19:35 Après, nous, je dirais, c'est même à l'échelle des personnes, mais à l'échelle des équipes, deux équipes, pareil, elles ont forcément des choses à échanger et tout ça, donc ça fait complètement sens quand on a deux équipes. Chez nous, les équipes, je dirais, que j'ai pu voir, il y a des équipes où il y a, alors c'est un peu triste, j'ai envie de dire, et ce n'est pas conseillé, mais il y a des équipes où il y a un seul développeur par exemple, mais il n'y en a pas trop heureusement, mais jusqu'à environ 10 développeurs. En moyenne, voilà, 2, 3, 5 développeurs. Je parle beaucoup des développeurs parce que je suis manager d'une équipe plutôt de devs, par le passé en tout cas. Donc à partir du moment où il y a deux équipes, il y a des standards sans doute à poser, il y a toujours des pratiques sur lesquelles on veut avancer ou à se partager, donc ça fait complètement sens. Tu parlais de pratiques aussi, c'était Dorra qui parlait de pair programming.

20:38 C'est vrai qu'aujourd'hui, dans la plupart des entreprises qu'on accompagne, sans même parler de pair programming au début, on peut parler peut-être de revue de code en premier, qui sont aujourd'hui des pratiques qui sont appliquées dans quasiment toutes les entreprises dans lesquelles on a pu accompagner les équipes. Et c'est vrai que les gens voient la revue de code comme la solution miracle au partage de connaissances. J'ai dit ça, c'est complètement un regard perso que j'ai eu avec le retour des gens. Mais les gens se disent, en fait, on va mettre en place des revues de code. Donc, c'est bon, on va résoudre un peu nos problèmes de communication et de partage de connaissances parce qu'il y a quelqu'un qui va relire le code de quelqu'un d'autre, etc. Mais on a eu beaucoup de problèmes aussi, on a identifié beaucoup de problèmes avec ces revues de code, des problèmes très simples du type, en termes de communication, quand quelqu'un vient d'arriver dans l'équipe et se prend 40 commentaires sur de la synthèse, taxe dans le code qu'il a écrit, tout de suite, ça va frustrer. On a des règles d'un peu de dégoût de programming qui peuvent arriver. Il y a plein de choses autour de la revue de code que ça ferait l'objet d'un webinar de 4 heures.

21:42 Mais effectivement, il y a plein d'écueils parce que la revue de code aujourd'hui ne va plus servir, j'ai l'impression, comme un outil de partage de connaissances. Mais plutôt comme un filet de sécurité. On va se dire, en fait, on va sécuriser le code qui va passer en prod. Donc, on rajoute une couche de QA qui est justement de la revue. Et en fait, la QA se transforme en quelqu'un qui va essayer d'être un linter humain et d'aller identifier des problèmes. Et souvent, Les gens vont identifier des choses qui sont des problèmes de syntaxe, des problèmes qui sont entre guillemets des plus simples à identifier, des méthodes trop grandes, des trucs qui ne sont pas respectés en termes de nommage, etc. En fait, on passe souvent à côté des problèmes de fond ou des pratiques, des gestes à appliquer sur c'est quoi, comment on doit rédiger nos tests, c'est quoi un test pertinent, C'est comment on doit instancier des composants, comment on log des erreurs, etc. Et je ne sais pas si Dorra, par exemple, tu as eu ce même retour parce que tu as dû accompagner des équipes sur cette partie revue de code, j'imagine. Oui, et justement, un des travers aussi de la revue de code, c'est finalement, ça devient la même personne qui revule le code de toute l'équipe.

22:48 À un moment donné, à force d'avoir des retours différents de tout le monde, finalement, c'est la personne qui a la casquette Tech Lead qui fait la revue de code de tous les... Et ça, ça réduit encore plus la communication parce que même si on a un lien, on va dire, naturel avec la personne, Souvent, le tech lead s'est pris, en tout cas, la personne est considérée comme un manager au final, donc comme une sorte de hiérarchie, et donc on ne va pas forcément critiquer, entre guillemets. C'est un petit peu le travers de la revue de code, et c'est pour ça que nous, en termes de coaching, on essaye de... De montrer justement ces points d'amélioration et dire, OK, vous avez ce pain point-là, sachant que potentiellement, certains ou certaines devs de l'équipe ont un avis peut-être qui peut être constructif, mais qui n'osent pas justement le donner,

24:00 ou à cause de cette création de hiérarchie. Implicite. Et du coup, ce qui fait que souvent, ce qu'on va plutôt amener, c'est soit, si la revue de code, on veut qu'elle soit la plus constructive possible, c'est autant la faire en groupe et ne pas forcément avoir une personne qui est derrière son écran qui est revue. Ou alors mieux, c'est d'adapter. d'avancer cette revue de code et la faire en live en faisant du pair ou du mob programming. Là, tout de suite, il y a tout le monde qui en profite. Et souvent, pareil, quand on fait du pair, finalement, on arrive à trouver la personne avec qui on est en phase et du coup, on fait du pair programming avec... Tout le temps la même personne. Et c'est là où nous, en tout cas, moi, en tant que coach, je vais conseiller plutôt de changer les paires pour justement, même si... on n'est pas d'accord avec la personne avec qui on va faire du pair, c'est là où il y aura des discussions enrichissantes et c'est là où on va améliorer justement la communication dans l'équipe.

25:10 Parce que si on reste tout le temps en train de travailler avec les mêmes personnes, avec qui on a l'habitude de travailler, en fait, on revient à s'isoler naturellement. C'est ça, en fait, tu fais des groupes de plus d'une personne, mais deux ou trois personnes, et en fait, tu reproduis le même problème, parce qu'en fait, on a des petits groupes isolés qui ne communiquent pas entre eux. Et effectivement, c'est un retour qu'on a eu pas mal d'équipes qui nous disaient, dans des scale-up ou des boîtes, il y avait beaucoup de... Beaucoup d'équipes, des gens me disaient non mais on est très très bon sur le DDD, on est très très bon sur l'architecture hexagonale, il n'y a pas de soucis, je ne vois pas où est le problème, on n'a pas besoin de coaching ou quoi que ce soit. Et en fait, quand on est voir l'équipe d'à côté qui était dans le même open space, l'équipe découvrait complètement le DDD et ses concepts, avait énormément de mal à l'appliquer. Et en fait, justement, il y avait une hétérogénéité qui était très forte entre ces différentes équipes. On se rendait compte à ce moment-là qu'il n'y avait pas de partage et que ça ne communiquait pas entre les différentes équipes.

26:11 Donc, c'est vrai que le pair programming, le mob programming et la revue de code, si c'est appliqué juste dans le cadre d'une équipe, en fait, on résout une partie du problème, on commence à démarrer la communication. Mais en fait, on ne résout pas le problème global du partage de connaissances et de la capitalisation surtout. Et ça peut poser problème. Je ne sais pas, Tanguy, si tu as un regard un peu différent. Oui, je peux partager un petit peu ce qu'on fait ou ce qu'on aimerait faire autour de ça. Déjà, la revue de code, dans le temps, il a fallu les mettre en place. Il y a quand même quelques objections un peu naturelles. Et de montrer son code, son savoir-faire, de l'exposer et de se, entre guillemets, décomplexer par rapport à ça, parce que ça, c'est déjà une étape qui n'est pas évidente pour chacun. Après, quand on y arrive et qu'on voit que finalement, ça peut se faire en toute bienveillance et qu'on n'est pas là, on va dire, pour critiquer négativement ce qui a été fait, On a tous un certain niveau et le besoin de progresser.

27:14 Donc, on a passé cette étape-là. Globalement, chez nous, c'est à peu près en pair programming avec des pull requests, tout ça. Il y a du partage sans trop de problèmes. Juste pour illustrer aussi, Et c'est là où les communautés peuvent amener de l'intérêt. On a des événements qu'on appelle chez nous les code surgery et qui permettent aussi de partager son code. L'idée, c'est de venir lors de cet événement avec une problématique sur le code de son application et de l'exposer justement à la communauté pour essayer de résoudre. Les problèmes ensemble. Donc, on n'en a pas fait des centaines comme ça, mais ça a eu un certain succès. Et après, ce qu'on va... Bon, là, c'est plus le manager qui parle, mais on aimerait quand même travailler aussi sur des... Des revues de code croisées, mais c'est pareil, le but n'étant pas d'être retombé dans quelque chose de type contrôle ou je ne sais pas quoi, le but est de sécuriser un petit peu plus les applis, mais

28:21 les revues de code croisées, ce serait plus d'une équipe sur une autre, c'est-à-dire un tech lead d'une équipe qui aurait certaines bonnes pratiques, irait revoir le code de l'équipe d'à côté et vice versa. Et encore une fois, tout ça en toute bienveillance et sans intervention du management. On n'est pas, encore une fois, dans du contrôle. On est juste pour sécuriser et partager les bonnes pratiques. C'est un autre format. C'est vrai que le code surgery, c'est un exemple. Il y a une question de Baptiste sur, pouvez-vous donner un exemple concret d'une mise en place pour faciliter cette communication? En fait, c'est vrai que l'objectif, c'est de faciliter le travail pour les équipes de dev, pour que ce ne soit pas vu comme quelque chose de complémentaire, de supplémentaire, qui va être chronophage. On peut prendre l'exemple avec les ateliers de revue de pratique qui sont complémentaires aux revues de code. En fait, on a la revue de code classique où on va aller identifier des problèmes lors des code reviews, lors des merge requests, etc.

29:26 Qui peut se faire de manière synchrone avec du pair ou du mob programming. Maintenant, quand on va parler de nos pratiques, de la manière de faire dans le code, on s'est rendu compte que les revues de code, ce n'était pas forcément le bon format. Ou même le pair programming ou le mob programming. Pourquoi? Parce que souvent, il faut que toute équipe soit là, ou carrément toute une communauté soit là, pour valider aussi des nouvelles manières de faire, et même pour partager un retour d'expérience sur, tiens, j'ai trouvé telle solution pour le logger, etc. Là, c'est bien que toute équipe soit là et qu'on ne soit pas juste en train de mettre un commentaire à une seule personne. Le problème des revues de code, c'est que souvent, c'est un pour un, un peu comme quand on fait du pair. Mais l'objectif, c'est que ça permette de capitaliser, de partager ça à toute l'équipe en entière, pas uniquement à une seule personne. En plus, c'est très volatile quand on fait du mob programming ou du pair programming. Ça va être souvent des échanges à l'oral et on va avoir souvent tendance à... À dire des choses, à ne pas les enregistrer, on ne va pas capitaliser là-dessus. Et dès qu'il y a du temps, dès qu'il y a des gens qui changent d'équipe, c'est pareil, on va tout faire.

30:29 Donc, c'est important de pouvoir valider des choses sous la forme. Nous, ce qu'on a mis en place, c'est de manière asynchrone, de se réunir avec toute l'équipe ou toute une communauté de pratiques, toutes les semaines ou toutes les deux semaines, pour discuter justement des différentes pratiques qu'on a mis en place. Donc là, ça sort du cadre des revues de code et ça permet de remonter des choses pendant les revues de code, justement qui sont plutôt des pratiques. Comme ça, on n'en parle pas dans les revues de code, ça ne bloque pas, ça ne ralentit pas le lead time pour ceux qui suivent un petit peu Accelerate. Dans les forks qui métriques, il y a le lead time, le temps qu'il faut pour du code à partir en production. Le problème des revues de code, c'est que souvent des équipes nous disent en fait, c'est un bottleneck. Les revues de code, ça nous bloque, ça bloque la chaîne de production. Et l'objectif, c'est de les fluidifier au maximum. Et pour les fluidifier, il faut sortir des sujets qui ne devraient pas être vus en revue de code dans d'autres formats, donc des formats, comme tu disais, des code surgery, des points de guide ou des points d'équipe où on va discuter vraiment de tout ça. Et l'objectif, c'est de...

31:30 capitaliser un petit peu là-dessus. Il y a une autre question qui arrive derrière, qui est encore sur le pair mob programming, c'est quelle stratégie ou bonne pratique on peut mettre en place pour encourager ce pair et mob programming? Et dans la question d'ailleurs, la personne dit, on se heurte parfois à un refus de la part des devs. C'est marrant parce que moi, de retour d'expérience, j'aurais plutôt dit que c'était un refus de la part des managers qui ont l'impression que quand on est à deux devant un ordi, On brasse de l'air. Mais je ne sais pas, est-ce que Dorra, toi, dans ton coaching, tu fais beaucoup de paires? Exactement. En fait, je ne suis pas étonnée de la remarque de la question, dans le sens où, effectivement, on s'attend à ce que le ou la manager en question qui... Qui est le frein par rapport au programming, mais parfois, c'est les devs même qui sont ce frein-là, alors que même parfois les managers sont convaincus.

32:32 Et ça rejoint le côté, le frein humain, au final, de ce qu'on s'est dit au début. C'est qu'on n'a pas... En fait, le code qu'on produit, souvent, est considéré comme si c'était nous-mêmes. Et en fait, c'est ça l'effort qu'il faudra, en tout cas le travail qu'il faut faire sur soi, c'est de dire ce que je produis ne représente pas ma personnalité. Et le... code, ce n'est pas la personne qui a fait le code. Et c'est ça le problème quand on fait des revues de code ou du pair. Certaines personnes ont peur d'être jugées par rapport à ce qu'elles produisent. Et en fait, l'idée, c'est de dire, au lieu de penser plutôt à l'inconvénient de cette pratique, plutôt... Pensez à ce que ça va vous apporter en termes de connaissances, en termes de discussions, en termes d'autres façons de faire.

33:35 C'est ça ce qu'on cherche et on cherche à grandir ensemble. Et en fait, le but, c'est de comment évoluer et comment s'enrichir en termes de discussion. Et ça, ça passe par justement du père, du mob ou autre. Alors, chez Arolla, il y a un cas particulier parce que comme c'est une ESN, souvent, on n'est pas dans les mêmes équipes. On est chez des clients. En tout cas, c'est rare de trouver une équipe arolienne directement chez un client. Et du coup, chez nous, on a créé un système de guildes qui ressemble un petit peu à ce que disait Tanguy par rapport à la code surgery. C'est que pour ces guildes, on essaye de grandir ensemble. Donc, on a des réunions, par exemple, toutes les deux semaines. Et c'est des retours d'expérience de ce qu'on a fait côté… côté quotidien. Et du coup, comment on s'améliore ensemble, même si on n'est pas dans les mêmes écosystèmes.

34:41 Et c'est justement ça l'avantage, c'est que comme on n'est pas dans les mêmes écosystèmes, et donc là, je pense... Au sein d'un même client, c'est des équipes différentes. Là où on apprend beaucoup de choses. Et justement, un de mes clients où j'avais proposé de faire des revues de code inter, enfin cross, équipes, donc des équipes qui font potentiellement des revues de code ou même des pairs programming avec d'autres équipes. Et en fait, on se rend compte qu'on apprend plus rapidement parce que du coup, ah oui, on n'a pas vu comme ça. Ah oui, vous utilisez tel outil ou tel techno ou tel lib. Ah, comment ça se passe? Comment ça se fait? On va créer directement une session de formation, peut-être d'une heure ou deux heures ou une presse sur cet outil-là. Et puis, du coup, comme ça, toutes les équipes commencent à utiliser probablement la libre en question. Donc ça, c'est l'avantage aussi de... De faire cross-équipe.

35:44 Oui, et puis c'est assez lié aux valeurs poussées par le software craftmanship, par exemple, qui sont le mentoring, l'échange et la création de communautés, justement, le partage, pour rentrer dans une démarche d'amélioration continue dans l'équipe. C'est vrai qu'on a eu le cas rarement de... De personnes qui ne voyaient pas vraiment l'intérêt de partager avec les autres, mais c'est quand même assez minoritaire. De notre point de vue, on se rend compte que si les tech leads rentrent dans cette position de mentor et encouragent ces pratiques-là, par mimétisme, en général, le reste de l'équipe a tendance à suivre. Et quand il y a des personnes qui peuvent guider comme ça, en général, ça se passe assez bien. Je vais faire le timekeeper, je vois le temps qui avance. Je vois qu'il y a pas mal de questions qui se stackent. On va pouvoir rentrer dans le vif du sujet, parce qu'il y a pas mal de questions autour de ça, qui sont justement la mise en place des communautés de pratiques. Juste avant, je vais prendre une dernière question qui est encore sur ces pratiques. Greg qui demande comment est-ce que vous formalisez les pratiques? Alors, c'est une très bonne question sur laquelle je vais me jeter dessus.

36:48 De notre côté, avec Promyze, on a créé des plugins justement pour les IDE et les outils de route code qui permettent aux équipes de remonter en sélectionnant du code directement depuis leur IDE, par exemple, des pratiques ou des sujets de discussion. Et ces pratiques, après, en fait, sont formalisées sous la forme d'un nom, d'une petite description et des exemples de code associés avec l'air factoring. Et tout ça, c'est stocké et c'est directement disponible dans les IDE. L'objectif, ce serait d'éviter pour nous de les mettre dans des outils comme Confluence ou Notion qui sortent des équipes de leur environnement. Il faut que ça reste dans l'IDE ou dans la petite revue de code. J'en parlais hier aussi avec Sébastien Legade, peut-être un lien avec toi Tanguy, qui est Engineering Director chez Mythique. Et chez Mythique, ils ont mis en place justement ces communautés. Ils font un petit peu ce qu'on explique en termes de revue de pratiques. Et eux, ils enregistrent sous la forme d'ADR, Architecture Decision Record. Donc ça peut être aussi un format. Pour certaines pratiques enregistrées de cette manière-là.

37:49 Mais voilà, il faut les formaliser pour capitaliser dessus, c'est important. Justement, vas-y. J'avais une autre réponse pour compléter. Par exemple, Quelque part, nous, l'enregistrement des bonnes pratiques, c'est notamment celles qui sont partagées dans nos événements, donc nos événements de type BBL, donc un peu mini-conférence. Et juste pour info, nous, on les enregistre tous. Donc, on en est à plus de 140. En fait, on commence à avoir, on va dire, un petit YouTube interne. Des bonnes pratiques partagées dans des vidéos pour tous ceux qui auraient manqué ou qui voudraient revenir sur une thématique passée. Oui, je voulais rebondir aussi par rapport à tout ça. C'est que souvent, on va essayer de chercher des solutions justement pour améliorer les connaissances. Et on se dit, en créant justement peut-être de la doc, en créant des manuels d'utilisation, potentiellement des wikis type Confluence, etc.

38:58 Et en fait, il y a... Il y a ce qu'on appelle aussi, c'est un bouquin qu'a écrit Cyril Martraire sur la Living Duck, où c'est là où il explique des techniques et des façons de faire pour que justement on apporte cette connaissance de telle sorte qu'elle soit directement lisible dans le code. On va enrichir le code avec ce qu'on appelle des marqueurs. justement enrichir le code et de telle sorte qu'il soit aussi auto-porteur de formation, auto-formateur. Il y a plusieurs manières, effectivement, comme tu dis, de partager un petit peu cette connaissance. Dans le doc directement, c'est une bonne manière, quand c'est des trucs spécifiques au code, de les rentrer de cette manière-là. Parfait. Et pour rentrer vraiment dans la partie communauté de pratique, est-ce que, par exemple, Tanguy, vu que tu as contribué fortement à la...

40:00 mise en place de ces communautés chez Allianz. Tu peux nous donner justement un retour de comment ça s'est passé, qu'est-ce qui a bien fonctionné, qu'est-ce qui a peut-être moins bien fonctionné? Oui, alors déjà, comme je l'ai expliqué, on a lancé 12 communautés en France. Je vais parler plutôt de la communauté Craft, sur laquelle... C'était le plus actif. Donc nous, on l'a lancé en fin 2019, l'émergence de l'idée de faire ça. Et puis le lancement en juillet 2020. Et comme je le disais, on est à peu près à 140 événements à date. Donc, ce n'est pas évident de lancer une communauté de pratique comme ça quand il s'agit de mobiliser quand même quelques personnes. Donc, nous, le premier conseil, c'est peut-être de se faire accompagner par des coachs, justement des coachs craft qui auraient un peu d'expérience, qui l'auraient déjà fait dans d'autres entreprises éventuellement.

41:05 Nous, c'est ce qu'on a finalement fait. Alors, pour la petite histoire, parce qu'il faut les financer, donc quand on part de zéro, que personne n'a de conviction sur l'intérêt des communautés de pratique, ce n'est pas évident. Alors, la petite astuce que les gens autour de la table, des tables pourront peut-être reproduire, mais nous, on a financé ces coachs pendant... Pendant six mois sur le budget de formation de l'ARH. Quelque part, c'est un peu ça aussi, les COP, c'est on sub-skill, on monte en compétences, donc il y a une partie un peu formation, donc ce n'est pas complètement illogique d'utiliser ce budget. Qui normalement sert à envoyer les gens individuellement dans des organismes extérieurs pour être formés, là on en prend une partie, puis on finance le lancement de cette communauté qui est censée quelque part répondre à cette problématique de formation. Qu'est-ce que je peux dire d'autre? Aujourd'hui, nous, la Craft Community, c'est 120 personnes, juste pour donner un peu de personnes. C'est un événement, enfin, un à deux événements par semaine qui regroupent, voilà, pour ceux où on ne mobilise pas les foules, 30 personnes, mais ça monte à 100 aussi, ou un petit peu au-dessus.

42:13 Pour le maximum. Des tips, j'avais pensé... Alors, il faut forcément identifier dans la population de la communauté, nous, ce qu'on appelle des ambassadeurs, c'est-à-dire les gens les plus motivés pour l'organiser. Donc, il faut... Nous, ça représente à peu près 10% des 120, le nombre d'ambassadeurs. Mais parmi ces ambassadeurs, les plus, encore plus motivés, c'est peut-être encore la moitié, quoi, ou un tiers, qui sont hyperactifs. De la communauté qui sont toujours dans l'anticipation du prochain événement. Après, il y a bien sûr tout un cadre de fonctionnement à mettre en place, c'est-à-dire un rendez-vous d'eau où on anticipe les événements, on trouve les speakers. Un autre petit tips pour… pour la communauté, pour qu'elle soit un peu active. C'est lorsque vous êtes un peu en manque de speakers, de sujets en interne, n'hésitez pas à ouvrir la communauté à l'externe et à aller chercher des gens chez Arolla, par exemple.

43:15 Comme je mettais dans les commentaires, Cyril est intervenu d'ailleurs pour le premier BBL. historiquement, avant même que la Craft Community soit créée. Ça devait être en janvier 2019. Donc, n'hésitez pas à faire appel à votre réseau. Vous trouverez toujours des volontaires pour parler de tout un tas de sujets techniques et intervenir dans vos communautés. Donc, alternez, interne-externe. Interne plus sur les sujets qui concernent votre société et puis les standards, ce genre de choses, les sujets dont un externe pourra difficilement parler. Et puis, ouvrez un peu les chakras des fois sur des choses que vous ne faites pas en interne avec de l'externe. Voilà, après, moi, j'avais comme tip aussi, la com, elle est la com d'une communauté, donc la partie communication est hyper importante en interne, parce qu'il faut, si vous voulez mobiliser un petit peu les foules, il faut bien communiquer. Donc, pour ça, un petit tip, nous, c'est qu'on s'est entouré de community managers.

44:17 Donc, c'est un peu un nouveau, c'est bizarre dans des équipes de l'EV ou des départements plutôt... À IT, on s'est un peu musclé avec des community managers qui nous aident dans l'organisation des événements, l'anime. l'enregistrement des événements, tout ce qui est fait là, la gestion des questions, tout ça, nous on utilise, on fait un peu de pub Slido, qui n'est pas trop mal aussi. Mais voilà, tout ça, il faut l'animer. Et nous, nos tech leads, nos devs, ils n'ont pas forcément le temps pour faire toute cette partie-là. Donc, se faire aider de community manager, ça peut être une bonne idée. Voilà, après, il y en a plein. Je pourrais m'étendre, je ne sais pas, peut-être Dorra. C'est déjà pas mal. Oui, pas tant. On a évoqué pas mal. Et en fait, moi, ça fait partie. En fait, plus on accompagne les équipes d'Ève, peu importe, on va dire, la casquette d'Ève, PO, biais, parce que les autres aussi ont besoin aussi de grandir, c'est de proposer tout simplement...

45:24 d'encourager, on va dire, ces mouvements ou ces communautés. Et un des tips, on va dire, d'encouragement, c'est aussi de réserver du temps pour le faire. Parce que souvent, les managers, si vous avez envie de grandir, prenez du temps sur la pause-déj ou autre. Mais j'invite vraiment tous les managers de dire, OK, on réserve, par exemple, je ne sais pas, une demi-journée minimum par quinzaine pour cette communauté, peut-être via des incentives autres, mais en tout cas... probablement, c'est une forme aussi d'encouragement pour garder cette communication, parce que si on a du temps pour pouvoir animer, pour pouvoir organiser ces mini, on va dire, meet-up, conférences internes, du coup, on sera...

46:26 Par nous-mêmes encouragés pour aller chercher justement des... des personnes d'autres équipes. Et comme ça, ça crée une communauté plus grande au sein de l'entreprise. Ça dépend de la taille, mais voilà. C'est vrai qu'on a eu aussi, nous, on a vu plusieurs échecs de la mise en place de ces communautés dans différentes entreprises. Où en fait ça marche au début pendant quelques mois, et au bout d'un moment on ne trouve plus de sujet de discussion, ou alors les personnes qui animaient en fait sont parties ailleurs. Et c'est vrai qu'on en parlait avec des personnes chez Ubisoft qui avaient un regard sur l'Inner Source aussi, qui est assez proche, et qui disaient... La communication, ça a un coût et ça se gère. Et donc, toute cette collaboration qu'on va avoir en interne, on ne peut pas avoir le regard utopique de se dire, on va laisser les équipes se débrouiller, puis il y a bien des gens qui vont prendre le sujet, etc. En fait, c'est bien d'identifier les personnes, comme tu disais Tanguy, les champions ou les ambassadeurs ou n'importe quel terme qui pourrait...

47:27 Pour expliquer un petit peu qui sont ces personnes-là. Et il y a une question aussi dans le chat qui dit, est-ce que c'est au Scrum Master qui est le mieux placé pour mettre en place ces ateliers, ces communications, ou plutôt les TL? Alors, de mon point de vue, ce sera plutôt des personnes sur la partie tech lead, vraiment technique. Qui ont une volonté de faire monter tout le monde en compétences. C'est assez lié au craft et on va dire au profit, par exemple, des gens qu'on peut trouver chez Arolla. Mais il faut vraiment les identifier, il faut vraiment leur dire presque sur leur fiche de poste. On l'a vu avec différentes entreprises, c'est carrément inscrit dans les fiches de poste sur l'année ou dans les objectifs de créer ces communautés, de faire monter tout le monde en compétence. Et du coup, on doit rendre des comptes presque sur, on a animé ça, on a communiqué là-dessus, etc. C'est important que ce ne soit pas juste un truc annexe pour les équipes où si on le fait, c'est bien. Si jamais on est sous pression, on ne le fait pas. Parce qu'évidemment, là, c'est quasiment toujours raté. Donc, il faut que ça fasse partie de l'entreprise et il faut que le manager, les personnes en charge du management soient conscientes de ça.

48:32 Donc là, on retombe sur la communication, mais pas juste au niveau d'équipe technique, mais entre les équipes techniques et les personnes qui ne sont pas techniques pour leur expliquer à quel point c'est important dans notre métier de rentrer dans cette phase de communication. Et si jamais on ne le fait pas, on va droit dans le mur, on ne va pas évoluer. Et dans six mois, on sera tous à ce bin et on utilisera des technos qui sont obsolètes. On n'aura pas de faille de sécurité. Enfin bref, ce qui va en bas. Juste pour réagir à la question. Vas-y, vas-y. Non, pour réagir vite fait à la question, en fait, en théorie, Il n'y a pas vraiment un Scrum Master qui doit donner l'aval si le développeur peut aller rejoindre ses pairs. En théorie, il ne faudrait pas que ça se passe comme ça. Je dirais qu'il faudrait plutôt que le Scrum Master lui-même, de son fait, aille rejoindre de temps en temps la communauté des Scrum Masters, parce qu'on peut parfaitement avoir une communauté des Scrum Masters. Il y a quand même pas mal de choses à partager. Et il y a des maturités très disparates. en termes d'application de l'agilité, même au sein d'une même entreprise.

49:34 Donc, la question, c'est, oui, quand est-ce que le Scrum Master va dans sa communauté? Si elle n'existe pas, quand est-ce qu'il la lance? Et après, le développeur, en fait, comme tu l'as dit, Arthur, c'est que, en tout cas chez nous, aujourd'hui, ça fait partie, quelque part du quotidien et des missions, c'est écrit dans les fiches de poste, le fait de contribuer aux communautés. Et c'est effectivement même mis pour un certain nombre de personnes. On essaie de les embarquer aussi au travers de l'objectivation de ça. Parce qu'en fait, ce n'est pas vraiment une option, les communautés, finalement. Si elles sont dans des frameworks agiles, si on en parle dans les manifestes et autres, c'est bien qu'elles font complètement sens, sinon il n'y a pas de partage, chacun bosse dans son coin. C'est pour ça que je disais, il faut allouer du temps justement pour ça. Et moi, je prends l'exemple chez Arolla où justement pour les animations de ces guildes-là, on a besoin de temps pour le faire.

50:42 Et dans le cadre de ce qu'on appelle chez nous le Cirrus, donc c'est un ensemble d'incentives où on dit tout animateur ou animatrice de guildes, elle a six jours pour justement animer ces guildes-là. Donc, six jours de destaffing pour justement pouvoir animer sereinement, en tout cas, ces guildes et pouvoir organiser, faire un petit peu le job de community manager d'un côté et puis travailler avec l'équipe communication. Justement travailler sur la partie animation et communication externe. C'est vrai que ça va être le mot de la fin, c'est parfait, il nous reste une minute. De ce que je retiens un petit peu d'échange, c'est ce que vous disiez, ça ne doit pas être une option. En gros, ce n'est pas, OK, si les équipes veulent communiquer entre elles et organiser des événements, c'est bien, mais si elles ne le font pas, c'est dommage.

51:45 Si jamais on veut rentrer dans cette démarche-là et on pense, du moins, je pense, les personnes autour de la table ici, on pense que c'est essentiel et obligatoire. Si on doit faire ça, ça doit rentrer vraiment dans le cadre de ce que l'entreprise doit pousser. Il y a une question de Hubert qui dit justement, combien de temps est-ce qu'on doit adouer par semaine aux communautés de pratique? Comme tu disais, Dorra, ça va dépendre des contextes. Je ne pense pas qu'il y ait de normes ou quoi que ce soit. Mais en gros, il faut allouer du temps à ça. Il faut adouer du temps à ces échanges. Et on doit plus se retrouver dans le cadre d'équipes qui vont dire, en fait, on a un sprint et on n'a pas une heure à dégager pour communiquer entre nous sur les meilleures manières de faire. C'est vrai que ça fait longtemps qu'on n'a pas vu de contexte comme ça, mais c'est important de vraiment intégrer ça dans les démarches pour que ça puisse permettre à tout le monde de progresser. Super, je vois qu'il y a d'autres questions sur lesquelles on n'a pas forcément eu le temps de répondre. Ce qu'on va faire, c'est qu'on va arrêter la présentation live avec tout le monde, mais on va se retrouver sur des tables de networking qui sont juste en dessous de la scène.

52:51 On va pouvoir se dispatcher même Tanguy, Dorra et moi. Donc n'hésitez pas, si vous avez encore un peu de temps, jusqu'à maximum 13h30, le temps que... qu'on puisse aller quand même manger. N'hésitez pas à rester sur la table de networking pour nous poser des questions, etc. Puis là, on va se voir en direct. Merci à tous. Merci Tanguy. Merci Dorra pour tous ces conseils et toutes ces infos. Merci aussi à toi, Arthur. Merci pour l'animation, Arthur. Merci à tous. Avec plaisir, on se croirait sur Twitch, c'est parfait. Merci tout le monde. Et puis, on se retrouve sur les tables de networking dans quelques instants. À tout de suite. A tout de suite.