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.
Le groupe de
travail SLIM de l'IETF s'occupe de définir des mécanismes
pour le choix d'une langue lors de la
communication. Son premier RFC, le RFC 8255,
concernait le courrier
électronique. Ce nouveau RFC concerne, lui, les
communications « en temps réel », comme la téléphonie sur IP.
Un scénario d'usage typique est celui d'un client qui appelle
le support
d'une société internationale. Mettons que le client a pour langue
maternelle l'ourdou mais peut se
débrouiller en anglais. On veut qu'il
puisse préciser cet ordre de préférences, et, idéalement, que le
logiciel utilisé dans le call center le route
automatiquement vers un employé qui parle ourdou ou, si aucun
n'est disponible, vers un employé qui parle anglais. Plus vital,
le scénario d'un appel d'urgence où un touriste
danois en vacances en
Italie appelle le 112 et où il faut trouver
très vite quelqu'un qui peut parler une langue qu'il comprend
(sachant qu'en situation d'urgence, on est moins à l'aise avec les
langues étrangères). Comme le dit avec euphémisme le RFC « avoir
une langue en commun est utile pour la communication ». Pour gérer
tous ces scénarios, notre RFC va utiliser les attributs de
SDP (RFC 4566, SDP
est un format - pas un protocole, en dépit de son nom - déjà très
utilisé dans les protocoles de communication instantanée pour
transmettre des métadonnées au sujet d'une
communication).
Parfois, on a déjà l'information disponible (si on appelle une
personne qu'on connait et qui nous connait), et déjà choisi une
langue (par exemple une audioconférence dans une entreprise où la
règle est que tout se fasse en anglais). Notre RFC traite le cas où on n'a pas cette information,
et il faut donc une négociation au début de la communication. Cela
implique que le logiciel des deux côtés ait été configuré avec les
préférences et capacités linguistiques des deux parties (une
question d'interface utilisateur, non spécifiée par ce RFC).
Notez qu'il peut y avoir plusieurs langues différentes utilisées,
une pour chaque flux de données. Par exemple, l'appelant peut
parler dans une langue que son interlocuteur comprend, mais qu'il a
du mal à parler, et il utilisera donc une autre langue pour la
réponse. Notez aussi que la communication n'est pas uniquement
orale, elle peut être écrite, par exemple pour les
malentendants. Le RFC rappelle à juste
titre qu'un sourd n'est pas forcément muet et qu'il ou elle peut
donc choisir l'oral dans une direction et le texte dans une
autre. (Au passage, la synchronisation des lèvres, pour la lecture
sur les lèvres, est traitée dans le RFC 5888.)
La solution choisie est décrite en détail dans la section 5 de
notre RFC. Elle consiste en deux attributs SDP,
hlang-send
et
hlang-recv
(hlang
=
human language). Leur valeur est évidemment une
étiquette de langue, telles qu'elles sont
normalisées dans le RFC 5646. Dans une offre
SDP, hlang-send
est une liste (pas une langue
unique) de langues que l'offreur sait parler, séparées par des
espaces, donnée dans l'ordre de
préférence décroissante, et
hlang-recv
une liste de langues qu'elle ou
lui comprend. Notez qu'il est de la responsabilité de l'offreur
(typiquement celui ou celle qui appelle) de proposer des choix
réalistes (le RFC donne le contre-exemple d'un offreur qui demanderait à
parler en hongrois et à avoir la réponse en
portugais…) D'autre part, notre RFC
recommande de bien lire la section 4.1 du RFC 5646, qui indique d'étiqueter intelligement, et
notamment de ne pas être trop spécifique : si on est australien et qu'on comprend bien
l'anglais, indiquer comme langue en
est
suffisant, préciser (ce qui serait une étiquette légale)
en-AU
est inutile et même dangereux si le
répondant se dit « je ne sais pas parler avec l'accent australien,
tant pis, je raccroche ».
La langue choisie par le répondant est indiquée dans la
réponse. hlang-send
et
hlang-recv
sont cette fois des langues
uniques. Attention, ce qui est envoi pour l'une des parties est
réception pour l'autre : hlang-send
dans la
réponse est donc un choix parmi les
hlang-recv
de l'offre. L'offreur (l'appelant) est ainsi prévenu du choix qui a
été effectué et peut se préparer à parler la langue indiquée par
le hlang-recv
du répondant, et à comprendre
celle indiquée par le hlang-send
.
Voici un exemple simple d'un bloc SDP (on n'en montre qu'une
partie), où seul l'anglais est proposé ou accepté (cet exemple
peut être une requête ou une réponse) :
m=audio 49170 RTP/AVP 0
a=hlang-send:en
a=hlang-recv:en
Le cas où
hlang-send
et
hlang-recv
ont la même valeur sera sans doute
fréquent. Il avait même été envisagé de permettre un seul
attribut (par exemple
hlang
) dans ce cas
courant mais cela avait été écarté, au profit de la solution
actuelle, plus générale.
Un exemple un peu plus compliqué où la demande propose trois langues
(espagnol, basque et
anglais dans l'ordre des préférences décroissantes) :
m=audio 49250 RTP/AVP 20
a=hlang-send:es eu en
a=hlang-recv:es eu en
Avec une réponse où l'espagnol est utilisé :
m=audio 49250 RTP/AVP 20
a=hlang-send:es
a=hlang-recv:es
Et si ça rate ? S'il n'y a aucune langue en commun ? Deux choix
sont possibles, se résigner à utiliser une langue qu'on n'avait
pas choisi, ou bien raccrocher. Le RFC laisse aux deux parties la
liberté du choix. En cas de raccrochage, le code d'erreur SIP à
utiliser est 488 (Not acceptable here) ou bien
606 (Not acceptable), accompagné d'un en-tête
d'avertissement avec le code
308, par exemple :
Warning: 308 code proxy.example.com
"Incompatible language specification: Requested languages "fr
zh" not supported. Supported languages are: "es en".
Si la langue indiquée est une langue des
signes, elle peut être utilisée dans un canal
vidéo, mais évidemment pas dans un canal audio. (Le cas d'un canal
texte est laissé à l'imagination des lecteurs. Le cas des
sous-titres, ou autres textes affichés dans
une vidéo, n'est pas traité
par notre RFC.)
Voici un exemple bien plus riche, avec plusieurs médias. La
vidéo en langue des signes argentine, le
texte en espagnol (ou à la rigueur en
portugais), et un canal audio, mêmes
préférences que le texte :
m=video 51372 RTP/AVP 31 32
a=hlang-send:aed
m=text 45020 RTP/AVP 103 104
a=hlang-send:es pt
m=audio 49250 RTP/AVP 20
a=hlang-recv:es pt
Voici une réponse possible à cette requête, avec de l'espagnol
pour le canal texte et pour la voix. Aucune vidéo n'est proposée,
sans doute car aucune n'était disponible dans la langue demandée :
m=video 0 RTP/AVP 31 32
m=text 45020 RTP/AVP 103 104
a=hlang-recv:es
m=audio 49250 RTP/AVP 20
a=hlang-send:es
Notez que ce RFC ne fournit pas de mécanisme pour exprimer des
préférences entre les différents canaux (texte et audio, par
exempe), uniquement entre langues pour un même canal.
Les deux attributs hlang-recv
et
hlang-send
ont été ajoutés au registre
IANA des attributs SDP.
Notons que la section 8 du RFC, sur la protection de la
vie privée, rappelle qu'indiquer les
préférences linguistiques peut permettre d'apprendre des choses
sur l'utilisateur, par exemple sa nationalité. Une section
Privacy considerations, quoique non
obligatoire, est de plus en plus fréquente dans les RFC.
Enfin, question alternatives, le RFC note aussi (section 4) qu'on aurait pu utiliser
l'attribut existant lang
, qui existe déjà
dans SDP (RFC 4566, section 6). Mais il n'est pas
mentionné dans le RFC 3264, ne semble pas
utilisé à l'heure actuelle, et ne permet pas de spécifier une
langue différente par direction de communication.
À ma connaissance, il n'y a pas encore de mise en œuvre de ce
RFC mais comme il est cité dans des documents normatifs, par
exemple dans le NENA 08-01 de la North
American Emergency Number Association, il
est possible qu'elles apparaissent bientôt.