Aujourd’hui, les grandes entreprises et administrations publiques hésitent entre continuer à utiliser des logiciels propriétaires ou basculer vers les Logiciels Libres. Pourtant, la plupart des logiciels libres sont capables de bien traiter les données issues des logiciels propriétaire, et parfois avec une meilleur compatibilité.
C’est alors la barrière de la prise en main qui fait peur, et pourtant...
Les logiciels libres
L’aspect « Logiciel Libre » permet une évolution rapide et une plus grande participation des utilisateurs. Les aides et tutoriels foisonnent sur Internet ou sont directement inclus dans le logiciel lui-même.
Enfin, les concepteurs sont plus proches des utilisateurs, ce qui rend les logiciels libres plus agréable à utiliser et conviviaux.
Grâce à la disponibilité des logiciels libres, vous trouverez facilement des services de support techniques et la licence n’est plus un frein à l’utilisation de ces logiciels par votre personnel.
Notre support technique concerne essentiellement les logiciels libres, que ce soit sous forme de services ponctuels ou de tutoriels.
Voici un nouveau RFC « bureaucratique » autour des processus
menant au choix et à la désignation des membres d'un certain nombre
d'organismes de la galaxie IETF, comme l'IAB ou l'IESG. Ce RFC remplace le
RFC 7437, mais il y a peu de changements ; les
principaux portent sur les conséquences de la nouvelle structure
administrative de l'IETF, « IASA 2 », décrite dans le RFC 8711.
Ce RFC
concerne la désignation des membres de l'IAB, de l'IESG et de certains membres
de la IETF LLC
(voir la section 6.1 du RFC 8711) et de
l'IETF
Trust. Il ne concerne pas l'IRTF
et ses comités propres. Il ne concerne pas non plus le
fonctionnement quotidien de ces comités, juste la désignation de
leurs membres.
Le processus tourne autour d'un comité nommé
NomCom (pour Nominating
Committee, comité
de nomination).Comme expliqué en section 2, il faut bien
différencier les nommés (nominee), les gens dont
les noms ont été soumis au NomCom pour occuper un poste à l'IAB,
l'IESG, à l'IETF LLC ou à l'IETF Trust, des
candidats (candidate) qui sont les gens retenus
par le NomCom. Le NomCom, comme son nom l'indique, n'a pas de
pouvoir de désignation lui-même, celle-ci est décidée (on dit
officiellement « confirmée ») par un organisme différent pour chaque
comité (l'IAB pour l'IESG, l'ISOC pour l'IAB, l'IESG pour l'IETF
Trust, etc). Une fois confirmé, le candidat
devient... candidat confirmé (confirmed
candidate). Et s'il n'est pas confirmé ? Dans ce cas, le
NomCom doit se remettre au travail et proposer un ou une autre
candidat·e.
La section 3 de notre RFC explique le processus général : il faut
désigner le NomCom, le NomCom doit choisir les candidats, et ceux-ci
doivent ensuite être confirmés. Cela peut sembler compliqué, mais le
but est d'éviter qu'une seule personne ou une seule organisation
puisse mettre la main sur l'IETF. Le processus oblige à travailler
ensemble.
À première vue, on pourrait penser que le NomCom a un vaste
pouvoir mais, en fait, au début du processus, il ne peut pas décider
des postes vacants, et, à sa fin, il n'a pas le pouvoir de
confirmation.
Un point important et souvent oublié est celui de la
confidentialité (section 3.6 du RFC). En
effet, l'IETF se vante souvent de sa transparence, tout doit être
public afin que chacun puisse vérifier que tout le processus se
déroule comme prévu. Mais le travail du NomCom fait
exception. Toutes ses délibérations, toutes les informations qu'il
manipule, sont confidentielles. Autrement, il serait difficile de
demander aux personnes nommées de fournir des informations
personnelles, et les personnes extérieures au NomCom qui sont
interrogées hésiteraient à s'exprimer franchement sur tel ou tel
candidat. Et la publicité des débats risquerait d'encourager des
campagnes de soutien extérieures au NomCom, et du lobbying, toutes
choses qui sont formellement interdites. La section 9, sur la sécurité, revient sur cette
importance de la confidentialité : puisque le NomCom enquête
littéralement sur les nommés, il peut récolter des informations
sensibles et il doit donc faire attention à les garder pour lui.
Le résultat est annoncé publiquement. Voici, par exemple, l'annonce
de la sélection des membres de l'IESG, début 2019.
Et le NomCom lui-même, comment est-il choisi (section 4) ? De
ses quatorze membres, seuls dix ont le droit de vote. D'abord, les
dix membres du NomCom votants doivent répondre à un certain nombre
de critères (section 4.14) : ils doivent avoir été physiquement
présents à trois des cinq précédentes réunions de l'IETF (c'est
une des exceptions au principe comme quoi la participation à l'IETF
n'impose pas de venir aux réunions physiques), et c'est vérifié par
le secrétariat de l'IETF (chaque participant peut facilement voir
sur sa page sur le Datatracker s'il est
éligible ou pas.) Et ils doivent (évidemment), être très familiers
avec les processus internes de l'IETF. Une fois qu'on a un ensemble
(pool) de volontaires qui acceptent de participer
au NomCom (voyez un appel
à volontaires typique), comment choisit-on les dix membres de
plein exercice ? Eh bien, c'est là que c'est amusant, ils sont
choisis au hasard... Il n'existe en effet pas
de critères consensuels sur la meilleure méthode de choix des
membres du NomCom (rappelez-vous qu'à l'IETF, on ne peut pas voter,
puisqu'il n'y a pas de notion de « membre » et donc pas de corps
électoral rigoureusement défini). Le tirage au sort se fait selon la
méthode, ouverte et publiquement vérifiable, spécifiée par le RFC 3797. Voici par exemple les
sources de données aléatoires pour 2018 et un
exemple de résultat.
Le président du NomCom, lui, est désigné par l'ISOC. La liste des membres du
NomCom est en
ligne.
Une fois sélectionnés, les membres du NomCom se mettent au
travail (section 5 du RFC). Ils ne sont bien sûr pas éligibles pour
les postes qu'il vont devoir pourvoir. Lorsqu'ils doivent prendre
une décision, le NomCom vote (une procédure rare à l'IETF). Les
nominations peuvent être faites par n'importe quel participant à
l'IETF, y compris le nommé lui-même. La décision de retenir tel ou
tel nommé comme candidat doit s'appuyer sur sa connaissance de
l'IETF et ses qualifications pour le poste (qui ne sont pas
forcément les mêmes pour tous les comités : par exemple, l'IETF LLC
nécessite des compétences administratives qui sont moins importantes
à l'IAB). L'IETF étant une organisation de grande taille, le NomCom
ne connait pas forcément tout le monde, et peut donc aller à la
« pêche aux informations » en consultant des gens extérieurs sur tel
ou tel nommé.
Le « mandat » typique dure deux ans (trois à l'IETF LLC et au
Trust). Il n'y a pas de limite au nombre de
« mandats » mais le NomCom peut évidemment décider de donner la
priorité aux nommés qui n'ont pas encore eu de mandat, ou pas encore
effectué beaucoup de mandats.
Les informations récoltées par le NomCom, et ses discussions sont
archivées (mais non publiques : voir plus haut au sujet de la
confidentialité). Ces archives sont directement utiles s'il faut,
par exemple, remplir un poste et qu'on ne veut pas recommencer le
processus de zéro pour certains nommés.
Les humains étant ce qu'ils sont, il y aura des désaccords en
interne. Comment le NomCom gère-t-il les contestations (section 6) ?
Idéalement, le NomCom doit essayer de les régler tout seul (ne
serait-ce que pour préserver la confidentialité déjà mentionnée). Si
cela ne marche pas, le problème est transmis à l'ISOC, qui nomme un arbitre, dont
les décisions sont définitives (pas d'appel).
J'ai parlé ici surtout de pourvoir des postes, mais il peut aussi
y avoir révocation (recall, section 7) d'un
membre d'un des comités concernés. Cette révocation peut être
demandé par au moins vingt participants à l'IETF, qui doivent être
éligibles au NomCom, à l'ISOC. Un Recall
Committee est alors créé, et peut décider à la majorité
des trois quarts d'une révocation, sur la base des griefs présentés
par les signataires de la demande de révocation.
Bien des choses au sujet du NomCom ne sont pas écrites, et la
tradition orale joue un rôle important dans son
fonctionnement. L'annexe C rassemble plusieurs grains de
sagesse issus de cette tradition. Par exemple, avoir été président
d'un groupe de travail IETF est considéré comme une bonne
préparation à l'IESG. Il y a aussi des considérations sur
l'équilibre global entre les membres d'un comité. Il ne s'agit pas
seulement que chaque membre soit individuellement bon, il faut aussi
que le comité rassemble des gens de perspectives différentes (âge,
expérience, région d'origine, monde académique vs. entreprises à but
lucratif, etc). La tradition orale recommande aussi d'éviter qu'une
même organisation n'occupe trop de postes dans un comité. Même si
les gens de cette organisation ne forment pas un bloc, l'impression
donnée serait mauvaise pour l'IETF.
L'annexe B de notre RFC contient les changements depuis le RFC 7437. Rien de crucial, mais on notera :
- L'IAOC n'existe plus depuis le RFC 8711 et a donc été remplacée par l'IETF LLC (et idem
pour l'IAD remplacé par l'IETF Executive
Director.)
- Et plein de petits détails, parfois incorporés depuis un
précédent RFC, comme les RFC 7776.