Spoiler Alerte, j’adore participer à des conférences de dév, et j’ai aidé à en organiser. Le but n’est donc pas ici de cracher dans la soupe, mais bel et bien de proposer une prise de recul sur cette spécificité de notre métier. Ceci est le fruit de ma réflexion personnelle, et risque encore d’évoluer.

Points de départ

Le travail de sociologie s’accompagne d’un effort scientifique d’enquête et de statistiques pour prouver ce qu’on avance. Je n’ai pas du tout fait ce travail a priori, donc cet article est très loin d’être au niveau de la rigueur méthodologique qu’on attend d’une étude universitaire. C’est au mieux un vague instinct mais je le pose là, ça aura au moins le mérite de constituer un bon point de départ pour une conversation qui pourrait être saine.

Le public des conférences de dév est privilégié

L’individu type qui assiste à des conférences de dév est un individu qui

1. a compris l’intérêt de faire de la veille technique
2. a une entreprise qui l’autorise à poser une journée à assister à des conférences Encore mieux, une entreprise qui le paye et l’encourage à assister à ces conférences. Encore mieux une entreprise qui lui paye ses frais (billets/transport/hotel).
3. a une situation géographique qui aide (comprenez, on va plus facilement à devoxx quand votre entreprise est parisienne que quand elle est à Ajaccio)
4. n’a pas de grosse angoisse d’être dans une foule, avec des inconnus
5. est très souvent un homme blanc
6. est un speaker, auquel cas il est littéralement invité, parfois payé, pour venir assister et donner des conférences

Ce que j’observe, c’est que les techleads et CTO ont beaucoup plus souvent l’habitude de participer à ces évènements que des développeurs et développeuses lambda. Certains pourraient lire entre les lignes un lien de causalité, au choix :

• celles et ceux qui consacrent du temps et de l’énergie à la veille technique ont une meilleure carrière, et ont donc plus de chance d’être promu techlead
• celles et ceux qui sont importants pour l’entreprise (les managers, les tech leads) sont chouchoutés, et ont plus de chance de se faire envoyer en conférences

Finalement, la conférence n’est qu’un moyen de se distinguer de ceux qui n’y vont pas, c’est donc ce qu’on appelle un marqueur social. Je vais à des conférences de dév, donc j’appartiens à cette population, à ce sous-groupe, des dévs qui assistent à des conférences de dev. Avez-vous déjà rencontré un techlead Java qui faisait passer un entretien d’embauche et qui demandait au candidat s’il assistait à Devoxx ? Dans ce cas là le diagnostic est facile, il ne recherche pas n’importe qui, il recherche quelqu’un avec les mêmes habitudes, les mêmes comportements grégaires que les siens. La fonction sociale (indépendamment de l’apport technique qui y est important) est donc aussi de renforcer le sentiment d’appartenance au groupe, on s’y “sent développeur”, on porte fièrement nos tee-shirts StackOverflow, et on échange ses raccourcis IDEA préférés.

Si vous êtes habitué de ces conférences, vous savez que vous y reverrez sûrement les mêmes personnes qui étaient là l’année dernière, et que le public se renouvelle assez peu.

Le choix des sujets est un acte de censure

Une autre entité de ce système est l’équipe d’organisation de la conférence. Cette équipe n’a rien de magique, c’est elle qui choisit qui inviter à la keynote, ce que vont manger les gens, etc. La plupart de ces équipes d’orga sont aussi ouvertes à tous. Si le sujet vous intéresse je vous encourage à rejoindre une équipe pour vous faire votre propre idée. Si vous ne le savez pas, la plupart des organisateurs de conférences présentent eux-aussi des conférences, connaissent personnellement beaucoup de speakers et fréquentent d’autres organisateurs de confs. En effet il faut connaître la date de BDX.io pour pouvoir choisir la date de l’Agile Tour Bordeaux (et vice versa). C’est donc très pratique pour les orgas de connaître les autres évènements tech du coin, et les speakers potentiels pour remplacer au pied levé une absence.

Une partie essentielle de leur travail est de sélectionner les conférences, et de les programmer. Par ce choix d’élection, l’équipe fait aussi un choix de censure. Le mot est certes violent, mais c’est le terme pour désigner l’action d’un collectif qui décidera arbitrairement de qui aura la parole. L’action n’est pas anodine, vu que l’équipe choisira effectivement qui aura un podium, une tribune.

On pourrait dire “si c’est dans le programme, c’est un sujet qui mérite d’être entendu”, mais en disant ça on arrête de dire que la sélection des programme est un processus humain, et on y retire toute subjectivité. Je pense qu’il y a des sujets qui sont abordés dans des conférences qui sont jugés intéressants parce qu’ils sont dans des conférences, mais qui sont en toute objectivité inintéressants.

Une preuve de ça, c’est la relativité historique totale des sujets abordés dans les conférences de dév. Des sujets qui a une époque étaient jugés intrinsèquement intéressants, intrinsèquement nécessaires sont dorénavant ignorés, voire volontairement écartés. Par exemple, le sujet de l’agilité qui est devenu très vite en l’espace de 3/4 ans un sujet qu’on évite de placer dans le programme. Et dans le même temps, les conférences qui se focalisent sur l’Agilité se mettent à éviter de parler de développement logiciel.

On a donc une équipe d’organisation qui décide, avec ses propres biais et ses connaissances limités, quels seront les sujets dont on va parler cette année. Et donc mécaniquement censurent les autres sujets.

Et côté spectateurs et spectatrices ?

De l’autre côté, la naïveté règne.

Je vais à des confs pour faire ma veille. Ces technos qu’on me présente sont des importantes pour ma veille. Donc ce ne sont pas des technos “mortes”.

C’est littéralement quelque chose que j’ai déjà entendu : “Docker Swarm c’est mort, personne n’en a parlé à devoxx cette année”. D’une programmation subjective et éclectique, le spectateur tire des conclusions sur les grands vainqueurs des guerres de paroisse.

Et côté speaker ?

Un autre aspect de cette élection, c’est que l’équipe d’organisation joue fortement sur la production de conférences.

Aujourd’hui, si je veux parler à Devoxx, je sais quels sujets je vais essayer de proposer au call-for-paper, et je sais pertinemment quels sujets il est inutile que je propose. Cette connaissance là va donc jouer sur la production elle-même, car chaque conférence a des attentes différentes. Le fait d’être organisateur d’une conférence vers chez moi, de connaître d’autres speakers, d’autres organisateurs et organisatrices fait que l’on partage la même culture et une vision de notre métier similaire. Cette connaissance et cette appartenance au même groupe social à la base est une difficulté de plus pour accéder à une scène, quoi que vous vouliez dire.

Si mon but est de parler à Sunny-Tech, je vais donc travailler et étudier un sujet que je sais aura une chance d’être sélectionné, c’est à dire qu’avant-même que mon sujet soit accepté ou validé, la conférence m’a déjà indirectement incité à apprendre des choses à propos d’un sujet précis au détriment d’un autre.

Et on met à l’index les sujets qui ne seront pas acceptés, alors même qu’ils peuvent être plus pertinent pour notre communauté.

La fonction d’archive

Par le fait de la sélection des programmes, les conférences ont fonction de conservation, parce qu’elles solennisent un sujet dans le temps et l’espace.

En 2017 à bdx.io, on a beaucoup parlé microservices et Docker, donc c’est à ce moment là que le sujet s’est réellement démocratisé dans cette région.

Cette fonction d’archive a deux vecteurs principaux :

• La captation vidéo, permet de garder une trace des différentes interventions, permet de diffuser un discours plus largement, etc.
• Le programme en tant que tel est un merveilleux outil pour un historien

Ce sujet est plutôt laissé de côté par nos historiens et nos collègues, à l’exception de Laurent Bossavit qui parle passionnément de l’histoire de l’informatique. Si on se projette dans 50 ans, quand un historien fera sa thèse sur l’histoire des architectures logicielles, ces grilles de programmation de conférences seront une ressource très importante, grâce à laquelle on pourra facilement tirer des tendances, des modes, et des conclusions sur l’histoire de notre métier.

Il y a donc fonction de consécration, par le seul fait de la conservation.

Pour vous donner une idée, regardez ces programmes, et demandez-vous ce qu’un historien pourra conclure :
Grille de programme des conférences à Devoxx France en 2019
Grille de programme des conférences à SunnyTech en 2019

On voit donc que la question de la définition d’un sujet intéressant est plus complexe qu’elle en a l’air.

Petite précision : le même type d’analyse peut s’appliquer à l’écriture d’articles de blog. Ma démarche est personnellement d’ancrer mon savoir dans une chronologie. A telle date, j’avais telle opinion sur tel sujet. A telle date, je m’intéressais à tel sujet, à telle date, j’ai édité tel article, donc mon opinion sur le sujet a évolué. Un article intéressant devrait rester toujours dynamique car votre opinion sur ces sujets évoluera sans cesse. Et Git vous permettra de connaître l’évolution de votre avis sur un sujet.

Un grand pouvoir n’implique pas une grande responsabilité

Spiderman a tort. Il y a des cas de grands pouvoirs sans grande responsabilités.

En terme de puissance, il est dur d’imaginer plus grande puissance que celle de l’écriture d’un logiciel qui impactera des millions de personnes. Or les développeurs ont rarement l’impression ou le sentiment de puissance.
Donc non, un grand pouvoir n’implique pas une grande responsabilité. Idéalement, ce serait le cas. Idéalement, les développeurs se rendront compte qu’ils peuvent utiliser leur puissance pour faire autre chose que jouer les divas sur Linkedin parce que leurs profils sont demandés par beaucoup de grosses entreprises. Idéalement, un développeur ou une développeuse refuserait de développer une application ou une fonctionnalité qui serait contraire à ses valeurs morales. Idéalement, un développeur chez Doctolib se rendrait compte qu’en automatisant le travail d’une secrétaire médicale il participe à précariser ce métier. Idéalement une développeuse chez Betclic se rendrait compte qu’en travaillant sur une application mobile de pari en ligne, elle contribue à développer l’addiction aux jeux d’argent et aux paris sportifs chez les plus défavorisés.

On l’a vu, la sélection du programme joue un grand rôle dans notre communauté. Or ce pouvoir n’est pas souvent perçu par les organisateurs eux-mêmes. Ce sentiment de responsabilité est au mieux diffus.

Conclusion numéro 1

Ces mécanismes s’ils sont parfois compris ne sont pas toujours évidents pour tout le monde. Ça vaut peut-être le coup d’en discuter entre nous :

• si lors du recrutement je recherche quelqu’un qui va dans des confs de dév, qu’est-ce que ça dit sur moi, qu’est-ce que ça dit sur le candidat ou la candidate ?
• si personne ne parle d’ASP.Net, c’est mort ? Si personne parle de SQL Server, c’est donc un mauvais choix technologique ?

Le premier pas pour se prévenir de ses biais est de les connaître, donc d’en discuter entre nous.

Conclusion numéro 2: qui sont les élites de l’informatique ?

Dans son article Tyranny of Structurelessness (https://www.jofreeman.com/joreen/tyranny.htm) Jo Freeman étudie les groupes militants féministes du 20ème siècle aux états-unis, elle définit les élites d’un groupe comme étant un sous-groupe possédant beaucoup de pouvoir mais pas de responsabilité, sans que la connaissance de ce pouvoir soit partagé, et sans que le consentement y soit donné.

Correctly, an elite refers to a small group of people who have power over a larger group of which they are part, usually without direct responsibility to that larger group, and often without their knowledge or consent.

Si on utilise cette définition, les élites de notre communauté du développement logicielle sont donc les individus qui donnent des conférences, et au-dessus d’eux, ceux qui choisissent les programmes des conférences de dév.