Je suis Charlie

Autres trucs

Accueil

Seulement les RFC

Seulement les fiches de lecture

Mon livre « Cyberstructure »

Ève

RFC 7776: IETF Anti-Harassment Procedures

Date de publication du RFC : Mars 2016
Auteur(s) du RFC : P. Resnick (Qualcomm Technologies), A. Farrel (Juniper Networks)
Première rédaction de cet article le 13 mars 2016


La question du harcèlement dans le cadre des activités professionnelles (ou autres, d'ailleurs) est maintenant largement reconnue comme cruciale et toute organisation doit se demander « que dois-je faire ? » L'IETF décrit dans ce RFC ses procédures à ce sujet, avec notamment le rôle de l'ombudsteam, l'équipe de justice privée qui doit traiter les cas de harcèlement signalés.

Tout groupe humain est évidemment confronté au problème des comportements négatifs, les trolls, par exemple. L'IETF a eu sa dose, bien que mon impression soit que le problème est nettement moins grave que dans certains groupes, comme chez certains gamers. Mais c'est difficile à dire, c'est un domaine où on n'a pas facilement des statistiques précises. L'IETF a donc son « guide des bonnes manières » (RFC 7154), et les documents de cuisine procédurale interne (RFC 2418 et RFC 3934) prévoient la gestion des cas les plus sérieux. Ces documents se focalisent sur les comportements négatifs qui impactent directement le travail de l'IETF, et le mettent en péril (par exemple, un troll qui assomme le groupe de travail de longs messages répétés en quantité et n'apportant pas de contenu). Mais il y a aussi, et c'est le sujet de ce nouveau RFC, des pratiques négatives qui ne gênent pas directement l'IETF mais peuvent pourrir la vie des participant·e·s qui en sont victimes, par exemple du harcèlement sexuel lors d'une réunion physique. Ces pratiques sont évidemment interdites (déclaration de l'IESG) mais il restait à préciser quoi faire en cas de violation de cette règle.

Il faut noter (et c'est oublié dans la plupart des ces guides de bonnes manières d'origine états-unienne qui fleurissent dans beaucoup de conférences informatiques) que le harcèlement est déjà interdit par la loi dans la plupart des pays où l'IETF tient ses réunions. Comme le note le RFC, les règles de l'IETF ne remplacent pas la loi. Nul besoin d'une déclaration de l'IESG pour interdire, par exemple, les insultes racistes ou le harcèlement sexuel à une réunion IETF. C'est pour cela que la plupart de ces codes of conduct sont inutiles. Celui de l'IETF est très orienté par ses origines états-uniennes, mêlant la demande d'un comportement « professionnel » (comme si le harcèlement n'était fait que par des amateurs) et le puritanisme (« sexual imagery in public presentations », sachant qu'aux États-Unis, la vue d'un torse nu est déjà de la sexual imagery).

La déclaration de l'IESG citée plus haut donne une définition du harcèlement, définition forcément très large (il y a hélas bien des formes de harcèlement, et bien des raisons pour lesquelles un·e participant·e à l'IETF peut être pris·e pour cible). Le problème est-il fréquent à l'IETF ? Je n'ai jamais entendu parler d'un cas précis (contrairement aux cas documentés qui sont arrivés à DEFCON), mais, évidemment, toutes les victimes ne se signalent pas publiquement et le harcèlement est donc très difficile à mesurer scientifiquement.

En première ligne dans ce RFC est l'ombudsteam. Je n'ai pas essayé de traduire ce terme, d'origine suédoise (ombudsman, devenu en anglais ombudsperson pour éviter d'exclure les femmes, puis ombusteam pour marquer son caractère collectif). Disons que c'est une équipe chargée de gérer les cas d'accusation de harcèlement, et c'est la principale ligne de défense de l'IETF dans ces cas.

L'ombudsteam est composé d'au moins trois personnes. Elles sont désignées - pour deux ans, renouvelable - par le président de l'IETF (actuellement Jari Arkko), éventuellement après consultations. Il est recommandé de suivre une certaine diversité (éviter un ombudsteam qui serait uniquement composé d'hommes blancs d'âge mûr et issus des classes dominantes, comme l'est l'auteur de ces lignes...) et de faire en sorte qu'au moins un des membres soit un participant actif à l'IETF. Il n'est donc pas nécessaire, ni même souhaitable, que l'ombudsteam soit sélectionné uniquement en interne. L'idéal, demande le RFC, est que l'ombudsteam rassemble des compétences variées, par exemple des gens qui connaissent très bien l'IETF, des gens qui sont des experts en médiation et en gestion de conflits, etc.

Les membres de l'ombudsteam ne sont pas payés pour leur activité. (À mon humble avis, cela est en contradiction avec l'objectif d'avoir de la diversité : s'ils ne sont pas payés, on n'aura que des gens favorisés socialement.)

Si quelqu'un n'est pas content de la désignation de telle ou telle personne, il peut en appeler à l'IESG (section 6.5.4 du RFC 2026).

L'ombudsteam dispose d'une page Web officielle. La liste des membres du ombudsteam a été publiée deux semaines après le RFC.

Une fois l'ombudsteam constitué, que se passe-t-il en cas de plainte (section 4) ? La victime, ou un témoin du harcèlement, contacte l'ombudsteam, en présentiel ou bien par courrier (ombuds@ietf.org). Tout participant·e à l'IETF peut contacter l'ombudsteam, soit pour une plainte formelle, soit pour solliciter un avis.

Les pratiques de l'ombudsteam seront en grande partie définies par l'ombudsteam, qui est supposé en discuter avec l'IESG puis publier ses principes de fonctionnement. Au minimum, le RFC demande à l'ombudsteam que :

  • Les membres de l'ombudsteam soient présents aux réunions physiques de l'IETF, pour permettre des prises de contact AFK.
  • L'ombudsteam travaille dans la plus stricte confidentialité. Il s'agit de protéger aussi bien le ou la signaleur d'un harcèlement (qui peut hésiter à se plaindre, par exemple par crainte de représailles) que celui ou celle qui en est accusé, peut-être à tort (la section 8 revient en détail sur cette exigence de confidentialité). C'est une exception à la règle habituelle de l'IETF comme quoi tout doit se dérouler en public (une autre exception est le NomCom, cf. RFC 7437).
  • L'ombudsteam ne doit évidemment prendre aucune décision sans avoir entendu les deux parties - pas seulement celle qui signale le harcèlement.
  • Si les accusations s'avèrent infondées, aucune sanction ne doit être prise contre celui ou celle qui a signalé à tort, mais de bonne foi. Autrement, les problèmes ne seraient jamais remontés.
  • L'ombudsteam doit garder des traces écrites de toute son activité, ce qui n'est pas techniquement trivial, vues les exigences de confidentialité.

Bon, donc, des gens signalent des problèmes à l'ombudsteam, l'ombudsteam investigue, se réunit, discute et à la fin, il peut décider quoi ? La section 5 décrit les solutions disponibles pour l'ombudsteam :

  • Dans certains cas, les processus existants avant ce RFC peuvent être utilisés (voir par exemple les RFC 2418 et RFC 3934).
  • Dans les autres cas, l'ombudsteam doit chercher si une médiation entre les parties est possible, débouchant sur un accord qui empêchera la répétition des faits.
  • Dans les cas les plus graves, l'ombudsteam peut décider de sanctions, comme l'exclusion de tout ou partie des activités de l'IETF. Par exemple, le participant convaincu de harcèlement peut être banni d'une réunion et/ou des futures réunions.

Ces sanctions les plus sérieuses peuvent provoquer des problèmes délicats si le harceleur occupait une position de responsabilité à l'IETF. Bien sûr, ces personnes en position de responsabilité (président d'un groupe de travail, par exemple) n'ont pas d'immunité. Mais il ne faut pas non plus que l'ombudsteam puisse empêcher, de facto, un responsable de tenir son rôle. Une possibilité est, dans ce cas, que l'ombudsteam fasse jouer les procédures de révocation normales de l'IETF (RFC 7437, notamment la section 7). Dans le cas d'un poste qui passe par le NomCom (Nominating Commitee), l'ombudsteam demande alors le lancement de la procédure de révocation, et n'a pas besoin pour cela d'une pétition de 20 participants (RFC 7437, section 7.1). Dans le cas de poste pourvus par l'ISOC, l'IAB ou un autre organisme, l'ombudsteam peut demander à cet organisme la révocation du harceleur. Idem si le poste a été pourvu via un directeur de zone (AD, Area Director) ou un président de groupe de travail.

On le voit, l'ombudsteam dispose d'un large pouvoir, sans contrôle (en raison de l'obligation de confidentialité) et la section 5.1 du RFC dit bien que les organismes à qui l'ombudsteam demande une révocation doivent, sauf raison très sérieuse, donner suite à cette demande. Mais que se passe-t-il si quelqu'un est en désaccord avec l'ombudsteam ? La section 6 traite ce problème.

Après discussion avec l'ombudsteam la question doit être remontée au président de l'IETF. Si celui-ci préfère ne pas être impliqué (voir par exemple la section 7, sur les conflits d'intérêt), il peut demander à l'IESG de désigner un de ses membres pour jouer son rôle (les protocoles réseaux, c'est compliqué, mais la bureaucratie interne de l'IETF, c'est pire). Si la discussion entre le président et l'ombudsteam ne débouche pas sur une solution, un mécanisme formel d'appel est prévu. Le groupe qui étudiera l'appel est composé du président de l'IETF et de deux membres de l'IESG qu'il·elle a choisi. Ce groupe peut évaluer la question sur le fond. S'il y a un problème de forme, il existe un dernier mécanisme d'appel auprès de l'ISOC. Notez que les procédures ont été légèrement mises à jour par le RFC 8716.

Le RFC se termine par une jolie citation d'Aung San Suu Kyi : « Human beings the world over need freedom and security that they may be able to realize their full potential. »


Téléchargez le RFC 7776

Version PDF de cette page (mais vous pouvez aussi imprimer depuis votre navigateur, il y a une feuille de style prévue pour cela)

Source XML de cette page (cette page est distribuée sous les termes de la licence GFDL)