Who Run The Tech 2024

Who Run The Tech est une journée de conférences et d’ateliers qui se tient à Rennes, organisée par l’association ESTIMnumerique. Sa spécificité ? Un programme exclusivement porté par des conférencières, toutes expertes dans des sujets 100% tech. L’objectif : mettre en lumière l’expertise technique de femmes et minorités de genre, encore trop souvent sous-représentées dans le secteur du numérique.

Le 28 novembre dernier, la deuxième édition de cet événement s’est déroulée avec succès. En tant qu’intervenantes et participantes, nous (Khadija Abdelouali, Morgane Decugis, Thessalène Jean-Louis et Jacqueline Rwanyindo) avons eu l’opportunité de vivre cette journée de l’intérieur. Voici un retour sur les conférences qui nous ont marquées.

Sommaire :

• Keynote d’ouverture : Le court métrage Maybe Next Time
• Redécouvrir la coopération : Atelier de Mob Programming
• Faire du TDD en Front-End
• Améliorer l’implémentation du feature flip pour réussir à avoir du flow
• IA-404 : Explication not found
• Keynote de fermeture : Théâtre forum
• Conclusion

Keynote d’ouverture : Le court métrage Maybe Next Time

De Clara Leclerc-Petrášová

Pour ouvrir la journée, le public a découvert le court métrage Maybe Next Time. Ce film aborde, sur le ton de la comédie, les biais et stéréotypes auxquels les femmes peuvent être confrontées (notamment en entreprise).

Synopsis : Une codeuse se voit obligée de participer à une réunion de brainstorming avec le responsable marketing du groupe pour l'aider à construire la nouvelle campagne de recrutement de talents féminins dans cette entreprise de la Tech. Bourrés de clichés et d’idées préconçues, les propos du jeune homme sont challengés avec humour par sa collaboratrice qui va lui ouvrir les yeux sur le fait que la mixité est une solution et non une contrainte.

Après la diffusion, Clara Leclerc-Petrášová a relaté la genèse et le processus de création du court-métrage. La réalisatrice avait à cœur de traiter le sujet de l’égalité femmes-hommes à travers son premier projet.

Après avoir découvert la Silicon Valley et écouté des témoignages de leaders du secteur, elle est restée pantoise face aux agressions quotidiennes que les femmes peuvent encore subir. Elle a ensuite creusé le sujet en faisant un état des lieux en France via des interviews de femmes dans le tech.

Le processus d’écriture se base sur des témoignages de différents profils (étudiantes, professionnelles) et des analyses de données (voir image ci-dessus). Maybe Next Time pose aussi la question de la représentation des femmes scientifiques à travers les films et les séries. Le responsable marketing ne manque pas de tomber dans les travers de la sursexualisation.

Clara Leclerc-Petrášová met en scène des concepts féministes qu’elle définit comme suit :

• pink washing : Soutien du féminisme dans des objectifs purement cyniques et commerciaux
• boy’s club : L’entre-soi dans le monde du travail, très présent dans la Tech
• mansplaining : Explication non requise et infantilisation
• manspreading : Sur-occupation de l’espace public des hommes qui peut se manifester au travail
• mainterrupting : Interruption et délégitimation encore très fréquente

La protagoniste subit tout le long ces formes d’oppression en s’y opposant tant bien que mal.

La réalisatrice explique que les réactions après diffusion sont très différentes entre le public féminin et le public masculin. Quand les femmes peuvent se retrouver dans le film et s'identifier à la protagoniste, les hommes ont tendance à le trouver trop caricatural.

Lors de la partie questions/réponses, des retours démontrent que l'histoire “comique” n’est pas aussi tirée par les cheveux qu’on pourrait le croire puisqu'elle fait écho au sein de l’audience.

Redécouvrir la coopération : Atelier de Mob Programming

De Manon Carbonnel et Marjorie Aubert

Le Mob Programming (développement en équipe), aussi appelé Ensemble programming ou Software Teaming, est une méthode collaborative qui consiste à réunir plusieurs personnes dans un même espace pour travailler sur une même tâche. Ces personnes ne sont pas exclusivement des développeur·euse·s. Il s’agit des personnes pertinentes selon le problème abordé (dev, Product Owner, designer, comptable…).

Au cours de l’atelier animé par Manon Carbonnel et Marjorie Aubert, l’audience a pu vivre la dynamique du Mob Programming de manière ludique en jouant à Baba Is You. Ce jeu vidéo de réflexion repose sur la manipulation des règles. Ce qui en fait un très bon support pour expérimenter la collaboration et la communication en équipe.

Source : Site officiel de Baba Is You

À chaque étape, le driver (qui est au clavier et suit les instructions) et le navigator (qui donne les instructions) changent. Le reste des participant·e·s, la mob, conseillent le navigator sur la prise de décision.

Nous avons testé les règles du jeu, tenté des cas limites, fait des erreurs... Chaque itération a été l’occasion de tirer des leçons pour optimiser notre coopération. En voici quelques-unes :

• Adapter la précision des consignes
  De la première à la deuxième itération, le niveau de précision des consignes a évolué. Les indications sont passées de “Descendre, puis aller à gauche” à “Pousser le rocher jusqu’à tel point”. Dans le cadre d’un Mob Programming classique, il est utile d’adapter son discours selon le niveau et le contexte.

• S’accorder sur la prise de décision collective
  Lors de la troisième itération, le navigator a procédé à des votes de la mob pour décider. Trouver une manière de trancher est essentiel. Est-ce que le dernier mot revient à la personne qui a le plus d’ancienneté ? Au Product Owner ? Au vote majoritaire ? À chaque équipe de trouver le système qui lui convient le mieux.

• Optimiser l’installation
  Le navigator et le driver sont face à l’écran mais dos à la mob. Lors du quatrième tour, Marjorie nous propose de modifier la disposition afin de permettre une meilleure communication. Dès lors, le navigator n’a plus besoin de se tourner pour collecter les idées des autres. La manière dont on s'installe au quotidien peut avoir de l’impact sur notre capacité à communiquer, notre fatigue, etc. Veillons à l’adapter à la situation.

• Clarifier les termes
  Lors de la cinquième itération, un quiproquo a lieu. Lorsque l’on mentionne la lave, parle-t-on de la lave en tant que mot représentant une règle ou en tant qu’élément visuel ? Il est important d’être le plus précis possible dans son vocabulaire, éviter les raccourcis, pour se comprendre au mieux.

• Être à l’écoute
  Un participant compare la session à un escape game où nous devons prendre le temps de discuter de ce que tout le monde a compris. Mais s’exprimer face à ses pairs plus senior peut être intimidant. Une astuce pour favoriser la participation de chacun·e : faire intervenir les moins expérimenté·e·s en premier.

• Apprendre ensemble
  Nous avons appris les règles du jeu ensemble. Nous avions (plus ou moins) le même niveau de connaissance et sommes monté·e·s en compétence en même temps. Et quand une nouvelle personne arrive ? On s’adapte. Vulgariser sa pensée est un très bon exercice !

L'entraide, le partage de la parole, l’écoute active, le droit à l’erreur sont d’autant d'éléments qui favorisent la sécurité psychologique.

La sécurité psychologique est cruciale dans le bon déroulement d’un Mob Programming. D’ailleurs, l’article Quand sécurité psychologique rime avec performance, recommandé par les animatrices, constate qu’elle est un des facteurs principaux de la productivité.

Cet atelier ludique offre à tout type de profil l'opportunité d'explorer concrètement la puissance de l'intelligence collective et les bénéfices du Mob Programming.

Faire du TDD en front-end

De Faustine Godbillot

Le Test Driven Development (TDD), cette méthode de développement itérative où les tests servent de guide pour écrire du code, est souvent associée à des projets back-end ou des contextes où la rigueur est indispensable. Pourtant, appliquer cette pratique aux projets front-end, et en particulier aux composants visuels, peut apporter des bénéfices inattendus à condition de l’aborder avec méthode et pragmatisme.

Dans ce talk, Faustine nous propose une exploration rafraîchissante du TDD, sans prétention d’expertise mais avec la curiosité et l’humilité d’une praticienne en quête de solutions adaptées à ses projets. À travers un cas concret — le développement d’un jeu de TIC TAC TOE en JavaScript — elle montre comment écrire des tests unitaires, de composants et end-to-end (E2E), et partage un retour d’expérience honnête : si les tests unitaires s’intègrent aisément dans un flux TDD, les tests plus complexes, comme les E2E, demandent plus de temps et de discernement dans leur mise en œuvre.

Ce talk va au-delà de la théorie en détaillant les avantages pratiques du TDD dans le front-end :

• Meilleure compréhension des attentes fonctionnelles.
• Réduction des régressions.
• Code plus robuste.

Mais il met également en lumière la nécessité de faire des choix pragmatiques, car tout ne se prête pas au TDD. Ce partage, à la fois pédagogique et nuancé, offre des clés pour s’approprier cette pratique de manière réaliste, selon les besoins spécifiques de vos projets.

Que vous soyez développeur·euse débutant·e ou confirmé·e, vous repartirez avec des pistes concrètes pour expérimenter le TDD à votre rythme et enrichir vos outils de développement.

Améliorer l'implémentation du feature flip pour réussir à avoir du flow

De Dorra Bartaguiz

Dans sa conférence, Dorra présente le feature flipping qui consiste à pouvoir activer ou désactiver des fonctionnalités en temps réel sans livraison de code.

Source : Slide de Dorra Bartaguiz

Une utilisation non adaptée des flippers peut facilement virer au “bazar” surtout si ces flippers ne sont pas supprimés une fois que la feature a été activée et testée en production. Cela implique donc un grand nombre de conditions if et donc un code pas très lisible, un grand nombre de configurations à gérer et par conséquent des coûts supplémentaires.

Il y a plusieurs cas où l’on ressent le besoin de mettre en place des feature flippers :

• Livraison partielle :
  Lorsque l’implémentation de la fonctionnalité n’est pas terminée pendant le sprint et qu’on a quand même besoin de livrer du code. Le besoin d’utiliser un flipper peut découler d’un problème dans l’écriture des User Stories.

• Activation selon le contexte :
  Dans ce cas, il faut peut-être créer une nouvelle fonctionnalité ou un nouveau sous-domaine (DDD) ou bien utiliser des design patterns.

• Dépendance externe :
  On souhaite pouvoir désactiver la fonctionnalité manuellement à cause d’un manque de confiance en la disponibilité du service externe. Dans ce cas, la technique du “Circuit Breaker” qui fait fonction d’un health check suivi d’un feature flipping automatique si jamais on a un souci.

• Trunk-based development :
  Le trunk-based development est une approche de développement où on n’utilise pas de branches. Elle facilite la collaboration entre les membres de l’équipe et réduit les conflits. Dans ce cas, le feature flipping consiste à désactiver une fonctionnalité donnée (dont une partie du code peut avoir été faite dans le cadre de la release) et de ne l’activer qu’à la fin du développement. Cela revient à une activation unique de la fonctionnalité à la fin de l’implémentation. Ce qui est contraire au principe du feature flipping. Ce serait plutôt du branch-based development “déguisé”.

• Produit en production et refonte en parallèle :
  Dans ce cas, on peut utiliser des patterns et techniques “Deal with legacy” telles que le Strangler Application Pattern ou le Branch By Abstraction plutôt qu’un feature flipper.

• Demande explicite du client :
  Dans ce cas, il faut essayer d’expliquer le principe du feature flipping pour être sûr d’en comprendre l’utilité et surtout les inconvénients.

En conclusion, Dorra rappelle que le feature flipping peut sembler une “solution de facilité” à court terme mais il faut surtout être conscient·e des inconvénients à long terme et surtout garder en tête qu’on a plusieurs alternatives possibles.

IA-404 : Explication not found

De Cécile Hannotte

Dans son talk, Cécile Hannotte (Data Scientist chez Onepoint) s’attaque à l’épineuse question :

Si je cherche à comprendre ce que fait mon IA et pourquoi elle le fait, aurai-je une réponse ?

Source : 404 not found, image de Draguth Leon, Pixabay

Déjà, qu'est-ce que l'IA ?

Très simplement, sans données, il n’y a pas d’IA. On la modélise avec un neurone qui prend en entrée un ou plusieurs paramètres et on va plus ou moins “jouer au juste prix”. Le but est de s’entraîner pour minimiser l’erreur, ce que l’on appelle l’apprentissage automatique.

On pourrait penser, à tort, que l’IA ne s’accélère que depuis un an… Mais c’est faux ! Cécile nous explique qu’en réalité, l’IA a toujours été très rapide.
Mais puisque cela va si vite, on ne comprend pas toujours ce qu’on fait… Ce qui peut devenir très problématique avec l’utilisation de modèles de plus en plus complexes en entreprise.

Et l’IA explicable alors ?

L’IA explicable, ou XAI, permet de répondre à deux questions :

• Comment l’IA a trouvé ce résultat ?
• Pourquoi l’IA a pris cette décision ?

On peut qualifier cela selon deux critères :

• L’interprétabilité : ce que le modèle a fait.
• L’explicabilité : pourquoi le modèle a pris cette décision.

Cela permet alors de lever le flou sur cette “boîte noire”, surtout car parfois on ne connaît même pas les paramètres d’entrée ! L’exemple parfait pour illustrer l’utilité de l’XAI est la mauvaise classification d’une image à partir d’un tag de copyright et non pas du contenu réel de l’image. Sans ces explications, on aurait pu croire que le modèle était bon !

L’IA explicable vient évidemment répondre à la question initiale, mais pas que ! Cela vient aussi d’adresser des enjeux de taille :

• Enjeux éthiques :
  Ces questionnements poussent à la transparence des algorithmes, avec ou sans IA. En 2021, le règlement européen AI Act est né. Et avec cela, la volonté d’assurer une égalité de traitement de tous les acteurs utilisant l’IA. En outre, la CNIL met en avant les principes de vigilance et de loyauté.
• Enjeux stratégiques :
  Cependant, on le sait bien, il ne s’agit pas que d’éthique ! Il ne faut pas négliger la partie stratégique. Prenons le cas de l’algorithme d’IBM Watson qui, en 2011, a pour but de détecter les tumeurs. Jusque là, on peut se dire que c’est une prouesse ! Oui, mais. L’algorithme est rejeté en bloc car il n’y a aucune explication ! Cela met ainsi en évidence l’importance de l’adoption. Et qui dit meilleure adoption, dit aussi plus de confiance dans l’outil. Avec ce constat, il n’est pas difficile de percevoir l’avantage concurrentiel représenté par l’IA explicable. Enfin, le fait d’en comprendre le fonctionnement va mécaniquement permettre d’optimiser les coûts !
• Enjeux techniques :
  Il semble impensable de parler d’IA explicable sans aborder les enjeux techniques. Déjà, cela peut être très pratique pour toute la partie débug, mais aussi concernant la maîtrise des données utilisées pour entraîner les modèles (cf. l’exemple du tag). Sans oublier qu’avec une meilleure compréhension, il est possible de faire baisser la complexité de l’outil.

Comment mettre tout ceci en place ?

Il y a deux catégories à prendre en compte : le périmètre de la méthode et la dépendance au modèle.
Pour l’un, on va regarder si l'explication est globale ou locale. C’est-à-dire si l’explication sera toujours la même peu importe la donnée en entrée ou si elle est vraiment locale à cette donnée-là.
Pour l'autre, il s’agit d’évaluer si on est agnostique ou dépendant du modèle.

Cécile nous détaille par la suite plusieurs modèles tels que LIME (2016), SHAP (2017), PDP (2000). Elle met en lumière que le “Saint Graal” de l’XAI est d’avoir une explication globale couplée au fait d’être agnostique du modèle.
Seul hic, dans la réalité c’est bien plus compliqué. Les exemples donnés en début du talk ne prennent en compte qu’un nombre limité de paramètres. Or, les modèles utilisés aujourd’hui ont des milliers de milliards d’entrées ! En effet, on ne peut pas échapper à la mention du Deep Learning, qui est la base des grands modèles de langages (autrement connus sous le nom de LLM).

Finalement, est-ce que c’est possible d’expliquer l’IA ?

Réponse courte : oui mais non. On progresse, car cela est en train de se formaliser notamment via l’AI Act, mais dans les faits ce n’est pas si simple que ça ! Parfois, on n’a pas du tout d’explication, de même pour l’interprétabilité. Alors pour essayer de ne pas faire n’importe quoi, il y a tout de même quelques bonnes pratiques à suivre, résumées en un schéma :

Schéma des bonnes pratiques de l’IA selon la criticité de la décision et la complexité de l’algorithme

Merci à Cécile pour ce talk très instructif, qui donne un autre regard sur l’IA et ses usages. Dans une ère où c’est le mot qu’on a tou.te.s à la bouche, cela fait du bien de savoir de quoi on parle, vraiment !

Keynote de fermeture : Théâtre forum

De Céline Allain

Pour conclure la journée, une session de théâtre forum est donnée avec une note engagée. Céline Allain, psychologue et comédienne, met en scène deux situations qui posent la question du sexisme au travail, avec la complicité d’un autre comédien.

Après chaque scénette, le public réagit pour proposer des solutions ou partager un témoignage. Moment interactif : une personne de l’audience est invitée à monter sur scène pour expérimenter une alternative plus positive à la première situation jouée.

Une proposition de solution face à la minimisation du sexisme : le questionnement. Questionner peut pousser l’autre à se tenir au factuel, au détriment du jugement. Céline Allain souligne que le code du travail prend en compte le sexisme et que les managers doivent être formé·e·s à cette problématique.

Des réactions du public mettent en avant l’importance de ne pas faire porter toute la charge de l’éducation sur le sexisme sur les épaules des personnes qui le subissent.

Conclusion

Cette deuxième édition de Who Run The Tech a brillamment mis en lumière l’expertise des femmes et des minorités de genre dans la tech, tout en offrant des échanges riches sur les défis, solutions et perspectives de notre secteur.

Nous avons eu le plaisir d’y contribuer à travers nos interventions : quatre développeuses, quatre approches, avec des formats allant du quickie à l’atelier, en passant par la conférence. Nos sujets ? Les Progressive Web Apps (PWA), le Test Driven Development (TDD), et la gestion du cache. Si ces thèmes vous intriguent, leurs abstracts sont disponibles aux liens suivants :

• Révolutionnez votre expérience utilisateur avec les Progressive Web Apps (par Khadija Abdelouali).
• TDD, décortiqué, pratiqué, démystifié (par Jacqueline Rwanyindo).
• Parlons cache ! 💸 (par Thessalène Jean-Louis et Morgane Decugis).

Les replays seront bientôt disponibles pour revivre ces moments.

La journée s’est prolongée dans une ambiance conviviale avec un afterwork en non-mixité choisie. Cet espace a offert une belle opportunité d’échanger autour des conférences, de nos métiers et des expériences partagées, tout en clôturant la journée sur une note chaleureuse.

Bravo à ESTIMnumérique et leurs partenaires pour leur engagement et la qualité de l’organisation. En créant un espace où les talents trop souvent invisibilisés peuvent s’exprimer et se valoriser, Who Run The Tech contribue activement à construire une tech plus diverse et inclusive. Un événement inspirant, nécessaire et porteur d’espoir pour l’avenir du secteur !

Références

• Who Run The Tech
• ESTIMnumérique
• Maybe Next Time de Clara Leclerc-Petrášová (bande annonce du court métrage, bonus)
• How to: Mob Programming d’Anthony Rey et Colin Damon
• Baba Is You (site officiel)
• Quand sécurité psychologique rime avec performance d’Olivier Laborde
• Améliorer l’implémentation du feature flipping de Dorra Bartaguiz (slides)
• Les groupes non-mixtes avec Marcy Ericka Charollois, Julien Topçu et Magali Milbergue - WeLoveDevs