Utilisateur:Marcel

Cette page va présenter un exemple d’application des principes d’une disposition de clavier trimodale, avec un paradigme de touche morte revisité, offrant une fonctionnalité compose telle qu’elle devrait faire partie intégrante des normes. Autrement dit, si la France ou un autre pays normalise des claviers, ces derniers devraient inclure une fonctionnalité compose.

Approche

Pour répondre au mieux aux attentes de la normalisation, mener de front le développement du bépo et de l’azerty semble être une bonne approche, qui efface les clivages, laisse à chacun la liberté de choix et réduit ainsi le stress lié au changement, à condition que la progression soit nette sur l’ensemble des critères. Le but reste toujours de faciliter l’utilisation du clavier dans tous les secteurs d’activité. Pour limiter les discussions autour des lettres particulières à la seule accessibilité, la solution est le support de l’intégralité des quelques 1 600 caractères latins d’Unicode 8.0.0.

Le résultat doit être une carte épurée, qui déconcerte au minimum les utilisateurs venant de l’azerty, adaptée aussi bien aux professionnels qu’aux enfants, et qui assure autant la cohérence des fonctionnalités de chaque touche, que l’ergonomie des commandes les plus fréquentes dans une utilisation mixte clavier-souris. Le tout dans le cadre de l’implémentation nationale d’une ISO/CEI 9995 révisée, dans le sillage du mode opératoire allemand mais débouchant sur une solution autrement performante dont l’impact sur l’expérience utilisateur devrait être meilleur.

Le but ultime doit être de refermer la boucle ouverte en France il y a trente ans, et de mettre en place cette fameuse solution transposable à l’international sur laquelle se cristallisèrent les ambitions à l’issue d’une phase de réchauffement et sous l’impact des premiers échecs aux débuts de cette épopée. Aujourd’hui il est politiquement impossible à la France de ne pas implémenter ISO/CEI 9995, mais l’AFNOR peut à son tour, comme le DIN l’a fait avant elle, demander une révision de cette norme qui de toute manière a déjà subi plusieurs modifications. Le dernier mot n’a pas été dit, et il faut éviter à tout prix que les premiers claviers normalisés de France deviennent la victime d’une ISO/CEI 9995 inaboutie, réductrice, et irresponsable.

Qu’est-ce qu’une disposition trimodale ?

Plus une langue utilise de diacritiques et de lettres précomposées, plus sa disposition de clavier devient pénible pour coder et même pour écrire des courriers commerciaux avec des chiffres ou des articles historiques avec beaucoup de dates, mais aussi pour écrire la langue elle-même si les chiffres sont en majuscule et donc qu’il manque les majuscules diacritées. Si ce dernier problème est résolu en plaçant les chiffres en AltGr comme sur le clavier vietnamien de Windows et sur un clavier lituanien, les utilisateurs se plaignent évidemment encore plus. Pendant que les claviers Windows pour les Inuits utilisent la bascule VerrCap avec la fonctionnalité capitales suisses-allemandes pour basculer entre deux écritures, la plupart des langues non-latines doivent changer constamment de disposition de clavier par exemple pour l’HTML. C’est pourquoi l’auteur de KbdEdit conseille d’utiliser la bascule Kana, qui permet de basculer entre deux dispositions avec quatre niveaux complets pour chacune, si l’une des deux écritures peut se passer de bascule VerrCap (inactive avec Kana).

Sur les claviers français on peut placer la bascule Kana sur la touche E00 ($ du bépo, ²⁠ de l’azerty), et lui soumettre au minimum les 10 touches suivantes, mais pas les lettres non diacritées, ni les ponctuations sauf éventuelles exceptions. Les chiffres seront en accès direct quand la bascule – qu’on pourra appeler “Pro” comme programmeurs – est active, et ce quelle que soit la place des chiffres en mode par défaut. Si la touche Alt droite fonctionne comme AltGr, on aura quatre niveaux sur les touches des chiffres à complètement redéfinir pour le mode Pro, en inversant juste les chiffres et les symboles ou en mettant complètement autre chose en AltGr. Si les chiffres sont en AltGr, on les aura en accès direct, et éventuellement en (Maj+)AltGr ce qui était en accès direct. Si par contre la touche Alt droite fonctionne comme modificatrice Kana (soit Pro), les chiffres devront être en Pro en mode par défaut pour être en accès direct en mode Pro. Dans l’exemple de l’azerty, cela permet d’avoir les majuscules diacritées en Maj, les chiffres en Pro, et les symboles pour la programmation en Maj+Pro, et donc en Maj une fois que Pro est verrouillé. En incluant quatre autres touches dans la bascule, on peut avoir presque tout ASCII sur deux niveaux en mode Pro – ou un qwerty presque complet (c’est-à-dire sans accent grave ni tilde espaçants, les deux caractères de la touche E00, qui devront être placés en AltGr) si toutes les touches d’une disposition non-latine sont soumises à la bascule.

Le troisième mode offre un pavé numérique comme le neo2 allemand et tout ce que l’on voudra sur les touches restantes : double et triple zéro, lettres pour l’hexadécimal, opérateurs mathématiques, degré-minutes-secondes, préfixes comme U+ et &#x, espace fine insécable (et espace normale), ponctuations… Ce mode est actif le temps que l’utilisateur garde un doigt sur la bascule VerrMaj/VerrCap. Une fois le champ rempli et la bascule relâchée, il faut réappuyer pour déverrouiller les capitales.

Si la bascule VerrCap est indésirable, on peut utiliser cette touche pour la bascule Pro, et ajouter pareillement la modificatrice pour le pavé numérique du troisième mode, ce qui libère la touche E00. Mais de toute manière, sur le bépo, le $ et le croisillon sont jugés trop éloignés, donc autant prendre cette touche pour la bascule Pro et placer le symbole monétaire sur S, au même niveau que l’€ et les accolades, et le croisillon sur C, ou sur D comme dièse. Le eszett allemand est bien dans le groupe tréma qui est le diacritique de cette langue et qui n’existe pas avec S, et l’ed – tout comme le thorn dont on abuse tellement – ont leur place en compose uniquement, sur les claviers non-islandais, avec dh et th comme séquences. Pour le $ en accès direct, on a le choix entre quatre touches : É, È, Ç, À, toutes soumises à la bascule Pro, de même que la touche morte accent circonflexe éventuellement.

Sous Windows, la modificatrice du mode pavé numérique est Oyayubi droite, qui vient après Kana dans la liste, et qui est utilisée sur le clavier neo2. Si en plus d’appuyer sur VerrCap, on appuye sur Maj, on a un deuxième niveau dans ce mode, avec les opérateurs mathématiques à la place des opérateurs informatiques, par exemple. Ces deux niveaux doivent être doublés en Kana/Pro, pour que le pavé fonctionne quel que soit l’état de VerrPro. On dépasse ainsi facilement les 9 ou 10 niveaux auxquels le clavier semble être limité sous Windows, mais il suffit d’ajouter les définitions manquantes dans le header de la source du driver. (Je parle de Windows parce que je n’ai pas d’autre OS et que cela représente 91 % des PC du monde, et parce que les API clavier de Windows sont figées. contrairement à Linux où l’on peut sans doute ajouter tout ce que l’on souhaite pour toute nouvelle distribution.)

Oyayubi droite étant bien employée, il reste Oyayubi gauche à ajouter en doublure sur VerrPro pour écrire par exemple en grec monotonique ou même polytonique (à tester), à condition de garder un doigt sur VerrPro… au cas où c’est plus simple que de basculer entre les différentes dispositions. On peut même imaginer d’appuyer simultanément sur VerrCap et VerrPro afin d’avoir une troisième écriture, par exemple du cyrillique, ou du grec si le cyrillique est sur VerrPro seul. Là où cela devient un peu plus intéressant, c’est quand un de ces groupes de deux niveaux (avec Maj) est utilisé pour l’alphabet mathématique cursif, qui se trouve dans le plan multilingue supplémentaire et nécessite de ce fait deux unités de code par caractères. Sur les 2 % de PC sous Linux cela ne représente aucun problème puisque les touches mortes peuvent générer des séquences elles aussi, mais sous Windows, pour ces caractères, la seule solution c’est de les attribuer à des touches sur des niveaux (supplémentaires).

Touches mortes : Quoi de neuf ?

Ce que j’aimerais vous présenter, ce n’est pas le nouvel algorithme d’éditeur d’entrée qui fait la partie 11 d’ISO/CEI 9995, amplement discutée dans Wikipédia et qui est sans intérêt sous Linux qui peut générer par touche morte plus d’une unité de code. Ce qui est plus intéressant à mon avis, aussi (et peut-être surtout) sous Windows, c’est de changer la façon de choisir le caractère de touche morte. Le diacritique espaçant utilisé traditionnellement fait défaut pour plusieurs diacritiques de base (brève renversée, cornu, point souscrit, …), les appendices comme la crosse, et les combinaisons de deux diacritiques ; et aussi pour des touches mortes plus abstraites comme “tourné” ou “réfléchi”. À la place de tous les substituts mais aussi pour les touches mortes bien pourvues, on peut simplement faire appel à l’une des lettres diacritées, si possible la plus représentative ou la plus fréquente (qui n’en font souvent qu’une). Pour la crosse on a ainsi le c crosse (ƈ ), et pour le circonflexe le ê qui sous Windows fait économiser une frappe dans des mots tels que même (saisi comme m^me, le ^ représentant la touche morte), gêne (g^ne), tête (t^te), trêve (tr^ve), parce que les M, N, T, V n’existent pas avec accent circonflexe.

De plus, les touches mortes, surtout celles en accès direct, peuvent être redéfinies comme autant de sélecteurs de groupe, mais uniquement pour des raccourcis de saisie afin de ne pas compliquer le clavier pour les nouveaux utilisateurs. Au lieu de laisser vides les lettres qui ne comptent pas au nombre des caractères de base, on peut placer quelque cbose d’utile sur chaque touche sauf celles qui permettent d’abréger la saisie comme indiqué ci-dessus.

Ensuite on a la double frappe, qui peut être exploitée pour limiter le nombre de touches mortes. Je pense à <circonflexe circonflexe> pour l’háček, <tréma tréma> pour le macron (ou le point en chef), tandis qu’<aigu aigu> donne bien sûr accès au double accent aigu. Les diacritiques sur digramme qu’ISO/CEI 9995-11 affecte à ces doubles frappes intéressent une poignée de linguistes (dont l’auteur allemand des récentes révisions, qui est aussi linguiste), mais je doute que ce soit pertinent pour l’usage de base, qui inclut l’háček désormais (pour une marque automobile notamment). Après, il est vrai que sur le bépo, la touche morte háček est facile à retenir.

La touche morte compose permet d’économiser beaucoup de touches mortes, ce n’est pas un secret, mais elle permet aussi de faciliter l’apprentissage. Sur le bépo, la cédille et la virgule souscrite ne posent sans doute pas de problème, mais si leur présence se fait aux dépens des usages de base, on sera sûr de les retrouver en <compose virgule> et <compose point-virgule>. Après, sachant que l’intersection entre l’ensemble des lettres de base de l’ogonek et celui de la crosse est vide, on peut aussi bien ajouter toutes les lettres avec crosse sur la touche morte ogonek, que définir le crochet ouvrant pour les séquences compose, avec l’avantage mnémonique de pouvoir prendre le haut pour la crosse, et le bas pour l’ogonek. Reste à trancher si on veut garder le crochet en tant que tel dans la séquence, ou le convertir tout de suite en o ogonek, vu que la crosse n’a pas à ma connaissance de caractères détachés comme l’ogonek ((diacritique) ogonek U+02DB, U+0328). L’impartialité demandera sans doute de préconiser le caractère banalisé.

À propos justement, on dit en général que l’espace après une touche morte amène le diacritique espaçant. Depuis qu’Unicode a introduit les diacritiques combinants, il serait peut-être plus utile de préférer ces derniers pour cette facilité, et de produire le diacritique espaçant courant (^, ~) avec l’espace insécable, et celui qui est plus particulier (ˆ, ˜) avec l’espace fine insécable. C’est en tout cas ce qui ressort en gros de la disposition de clavier pour Mac OS X avec touche compose “uscustom” sur sourceforge. Il faudra modifier ISO/CEI 9995 en conséquence bien sûr. Parce qu’il ne peut s’agir d’implémenter une norme internationale pour implémenter une norme internationale. Le but de faire une norme de clavier internationale a toujours été de faire faire de bons claviers dans tous les pays, en fait. Il manque juste de s’en donner les moyens.

Faut-il tout mettre sur des touches ?

S’il est question de lettres particulières du plan multilingue de base comme le æ et le œ, le ij, le ß, le ð et le þ, le ŋ et le ɲ, le ɛ et le ɔ, le ʒ, le ə, le ʌ, cela dépend de la langue du clavier, dont l’écriture doit bien sûr être facilement accessible, idéalement en accès direct. Tous les caractères spéciaux doivent en tout cas être par défaut en compose, éventuellement aussi en touche morte. Mais celles qui sont fréquemment doublées, ce serait effectivement bien de les mettre sur des touches, parce que 4 ou 6 frappes pour une voyelle longue c’est beaucoup. Si les places nécessaires pour un usage de base le permettent, il reste toujours possible de doubler sur des touches tel caractère ou tel autre, surtout ceux qui servent aussi comme caractère de base avec des touches mortes, même s’ils sont aussi en compose. Exemple : le Ǯ (ezh háček), dont la lettre de base est en <compose, Z, h (ou H)>, et qui s’obtient alors par <háček, compose, Z, h> avec touche morte háček, et sans touche morte háček par <compose, >, compose, Z, h>. Mais les personnes qui utilisent cette lettre couramment doivent pouvoir l’entrer par exemple par <háček, Y>. Mais au cas où les positions en AltGr restent vides sur le Z, il faut bien sûr y placer le Ʒʒ (comme je l’ai encore sur mon clavier, mais bientôt plus, malheureusement). Avec une couverture par défaut de toute l’écriture latine, l’ajout de caractères latins n’est plus un sujet. À la limite, les discussions porteront sur l’accessibilité, mais s’agissant de langues vivantes étrangères, sur un clavier optimisé pour le français et les langues de France, cela risquera de rester sous-optimal.

Ici, “compose” c’est la fonctionnalité intégrée du clavier et qui fait donc partie de la spécification. Elle permet d’accéder à l’intégralité des 1 600 caractères latins environ, et plus si prévu, comme le compose que l’on connaît, sauf que sous Windows c’est dans le pilote de clavier. En complément il faut bien sûr utiliser WinCompose, mais pour écrire son écriture – dans toutes les langues et translittérations qui l’utilisent, y compris l’IPA – on ne devrait avoir besoin ni de logiciels tiers, ni de dispositions bourrées de groupes et de niveaux avec 6 ou 9 caractères sur chaque touche.

Comment libérer la touche E00 pour en faire une bascule

On a ainsi les moyens de rendre disponible la touche E00 pour la bascule Verrouillage Pro par une cascade de déplacements de caractères. Le $ peut par exemple être sur AltGr+S, et quand Pro est verrouillé, en accès direct sur É par exemple. Le eszett (ß) est admis dans le groupe tréma, ce qui est très logique vu que c’est une lettre allemande, que l’allemand utilise le tréma, et que le S tréma n’existe pas. De plus, le ß est aussi en compose (aussi bien <compose s s> que <compose s z>). Le croisillon, alias “dièse”, pourrait être placé en AltGr sur C ou sur D, sachant que l’ed et les symboles ©, ® et ™ sont doublés en compose (<compose D  h> ou <compose D H> pour l’ed majuscule). Le tiret demi-cadratin serait quant à lui déplacé à la même position sur la touche à côté, et le tiret cadratin serait accessible par <circonflexe –> (la transformation du tiret demi-cadratin dans le groupe circonflexe). L’argument pour cette solution, c’est qu’en français on préfère le tiret demi-cadratin aussi bien pour les incises que pour les intervalles. Si en anglais on retrouve les mêmes préférences, la typographie soignée y emploie davantage le tiret cadratin, sans espaces. Ce tiret sert aussi en français mais plus pour marquer une longue pause, tandis que les dialogues ont leur propre barre U+2015. Pour qu’un clavier 104 ou 105 touches puisse produire cette diversité, il paraît indispensable de recourir aux groupes (compose, circonflexe, tréma, aigu, grave, tilde). Seuls les tirets les plus fréquents sont placés sur des touches. Le symbole paragraphe ¶ peut ainsi faire partie du groupe circonflexe, associé au symbole section (paragraphe) § comme caractère de base.

Dépasser les limites du clavier auto-explicatif

Il devient de plus en plus problématique de normaliser des claviers latins multilingues qui ne permettent pas d’écrire toutes les langues qui se servent de cette écriture. Il faut par conséquent se donner les moyens de dépasser les limites du concept traditionnel basé sur l’idée reçue fausse selon laquelle l’utilisateur doit pouvoir déduire de la seule gravure des touches la totalité des caractères disponibles. ISO/CEI 9995-1 autorise les modes d’emploi imprimés ou affichables. Il est ainsi déjà possible d’implémenter une fonctionnalité compose et d’étendre le concept de touche morte dans le sens d’une sélection de groupe. Le feu est vert et la voie est libre.

La tendance officielle, qui domine ISO/CEI 9995 jusqu’à nos jours, consiste à partir du principe que même une personne qui n’a pas encore eu l’opportunité d’apprendre à se servir d’un ordinateur, ni à écrire à dix doigts et au toucher, et qui se voit réduite à chercher les lettres sur le clavier et à actionner les touches avec deux doigts maximum, doit pouvoir entrer son nom pourvu qu’elle utilise l’écriture latine. Cette tendance conduit à normaliser des claviers où tout ce qui est dans la disposition doit être gravé sur les touches à l’exception des lettres diacritées entrées par touche morte, dont seul le diacritique doit être gravé sur la touche ; et tout ce qui n’est pas gravé sur les touches ne doit pas être dans la disposition (mis à part quelques exceptions, si bien que l’on peut se demander pourquoi ce principe n’a pas été étendu). Sauf bien sûr les minuscules ou les majuscules des lettres figurant sur les touches.

Je vois aussi un côté “étalage ostentatoire” dans cette façon d’agencer le clavier, qui est propre à tous les claviers multilingues traditionnels, des plus anciens aux plus récents. Mais c’est juste une interprétation, la vraie cause étant l’idée que l’on ne doit pas demander aux utilisateurs d’apprendre une disposition des touches comme on apprend à se servir d’un logiciel : On apprend les raccourcis des commandes, mais pas la manière d’entrer des caractères spéciaux par le clavier.

En Allemagne par exemple, cela a conduit à normaliser un clavier multilingue, le T3, qui n’existe pas sous forme de clavier physique et pour lequel aucun driver n’est disponible (à vérifier), et un clavier multilingue réduit, le T2, qui est en vente auprès d’un fournisseur avec gravure conforme et pour lequel l’auteur de la norme propose un driver fait au MSKLC et qui ne fonctionne donc pas comme spécifié par la norme, mais qui contient toutes les lettres gravées sur les touches ou dont le diacritique figure sur une touche. Malgré tout cela, le T3 s’il existait autrement que sur le papier, permettrait d’écrire plusieurs langues africaines certes, mais pas toutes, notamment pas les plus importantes comme le bambara, et plusieurs langues américaines mais pas toutes. L’auteur de ce gâchis en est conscient, lui qui affirme noir sur blanc que cette norme supporte “aussi” plusieurs langues d’Afrique et d’Amérique. Pour ce faire, il a été nécessaire d’inclure dans ISO/CEI 10646 une liste de caractères d’un sous-ensemble qui devait s’appeler “jeu partiel international multilingue” et qui dans le groupe de travail d’ISO/CEI 10646 qui a voté son admission, a été vite renommé en “jeu partiel latin multilingue”, ce qui fait qu’après une série de protestations, l’ISO/CEI a été obligée d’ajouter une note comme quoi ce sous-jeu est celui auquel se réfère ISO/CEI 9995-3 (révisée de 2010) et qu’il ne permet pas d’écrire toutes les langues à écriture latine.

Ainsi la méthode d’agencement qui sépare les lettres en celles qui portent un ou plusieurs diacritiques “détachables” ou du moins pensés comme tels (barre, raie), et celles qui n’en portent pas mais qui ne sont pas “comme les autres” ou dont le “diacritique” se fond dans la forme (hameçon, crosse, rallonge, …), et qui place les premières dans le répertoire des touches mortes, les dernières sur des touches, conduit à créer des claviers assez complets pour perturber l’utilisateur non polyglotte et pour rendre la gravure des touches difficilement intelligible, mais toujours assez incomplets pour faire des déçus en laissant pour compte des langues et des communautés entières. Évidemment les responsables n’ont pas froid aux yeux pour argumenter par zones géographiques, se targuant qu’ISO/CEI 9995-3 permet d’écrire toutes les langues d’Europe à écriture latine plus le turc plus l’afrikaans plus le vietnamien, et avec cela plusieurs langues d’Amérique et d’Afrique…

Et ce alors qu’il suffirait de peu pour les écrire toutes : E ouvert, O ouvert, V tourné, lettres avec crosse… Mais il ne restait plus de place sur les touches pour le Ɛ, le Ɔ, le Ʌ, une touche morte “crosse”… sans compter qu’il aurait été compliqué de trouver – et normaliser ! – un graphisme représentant une crosse, parce que ce diacritique pointe tantôt vers l’avant, tantôt vers l’arrière. Ce n’est pas forcément de la méchanceté puisque, avant cela, l’auteur de la norme avait bien fait une disposition de clavier “extrême” comportant une touche morte “Afrique”. Difficile de savoir où se situait le blocage, si c’était le chef de projet au DIN, qui était d’origine turque, ou quelqu’un d’autre.

Une solution à ce problème consiste à normaliser des séquences compose et à utiliser la fonctionnalité d’enchaînement des touches mortes, présente sous Windows mais méconnue parce qu’elle n’est pas mise en avant, les utilisateurs étant censés ne pas aimer le fait d’appuyer sur plus de deux touches sans qu’il ne se passe rien après la deuxième… Je ne crois pas à ce stéréotype, et à mon avis, une personne en train d’apprendre une langue peut tout aussi bien apprendre quelques séquences compose. On sait que sur les claviers multilingues, les “autres” langues c’est plus du dépannage. Pour l’islandais par exemple, il faut le clavier islandais avec l’ö, l’ed, le thorn et le e dans le a en accès direct, et des touches mortes accents aigu, grave, circonflexe et rond en chef. Sauf que c’est un mélange entre un qwerty et un qwertz. Sur une disposition de clavier francophone, s’il reste de la place on peut bien sûr placer toutes ces lettres sur des touches, mais le thorn je préférerais ne pas, et l’ed non plus parce que sa majuscule (Ð) peut prêter à confusion avec le D barré (Đ) et le D africain (Ɖ ; minuscule ɖ) ; et il ne faudrait pas que ce soit au détriment de ce dont les Français se servent souvent, dont aussi le croisillon, le symbole dollar. Mais sur le R et le C en AltGr, j’avoue que je mettrais bien le Ɛ et le Ɔ, deux lettres qui servent en bambara et qui sont doublées pour des voyelles longues, plutôt que ces symboles commerciaux (©, ®, ™) qui ne sont jamais répétés et que l’on attendrait plutôt en compose, comme cela a été dit sur la ML. Le mouvement “compose” initié par DEC doit enfin entrer dans les mœurs.

Une solution pour écrire son nom (ce qui est l’objectif déclaré des nouveaux claviers allemands et donc de la dernière révision d’ISO/CEI 9995-3), c’est de normaliser une aide à la saisie à interface graphique qui permet de choisir voire de diacriter les lettres. Apple en a déjà une : Un appui long sur une touche alphabétique, au lieu de répéter la lettre, affiche une bulle avec des variantes. Il paraît que l’on oublie encore trop souvent que le clavier d’ordinateur s’utilise la plupart du temps avec un écran, qui peut afficher “aussi” une disposition de clavier, l’état du clavier après l’appui sur une touche s’il ne se passe rien par ailleurs, ainsi que toutes informations utiles. Ce fait figure jusque dans la norme ISO/CEI 9995 elle-même, où la clause 6.2 de la première partie stipule que les symboles graphiques affectés aux touches doivent être indiqués sur les touches, mais (!) qu’au lieu de cela ils peuvent étre indiqués dans un guide de l’utilisateur imprimé, ou être affichés à l’écran à partir d’un fichier fourni avec le clavier.

La normalisation devrait (à mon avis) se concentrer sur le clavier en tant qu’outil de travail, et sur la manière de transformer tout clavier existant en clavier multilingue complet, latin si c’est pour la France, ou non-latin plus latin (pour l’HTML).

Faut-il réviser ISO/CEI 9995 ?

Et si la France avait attendu si longtemps pour être en mesure d’apprendre des échecs des autres ?

Prenons le clavier Canadien multilingue standard, implémentation précoce de la norme internationale ISO/CEI 9995, laquelle rappelons-le a été développée depuis 1985 et publiée en 1994, soit deux ans après le clavier ACNOR. Or l’auteur du clavier canadien standard, Alain LaBonté, « a été dès 1988 (peu après donc l’adoption d’ISO Latin-1) expert-délégué canadien officiel au groupe de travail 3 du SC2 (sur le codage de l’information) », et il aura été le rédacteur d’une révision d’ISO/CEI 9995 au début ne notre millénaire. Dans cette norme, le sélecteur de groupe n’est pas du tout Contrôle droite. Il est :

― soit un appui simultané sur Maj et AltGr (appelés sélecteur de niveau 2 et 3 respectivement) dans un ordre quelconque [ce qui explique au passage pourquoi il n’y a pas de niveau 4] pour fonctionner comme un sélecteur de groupe rémanent, du même effet qu’une touche morte – et qui a effectivement été implémenté comme telle dans la disposition de clavier allemande T2 faite à l’aide du MSKLC par son auteur lui-même, où le sélecteur de groupe est actuellement (V1.05) AltGr+^ (symbole multiplication, touche E00), ce pourquoi cette implémentation est dite juste « compatible gravure » (par opposition à « conforme ») ; tandis que sur une autre variante antérieure mais toujours existante – le clavier Europe – il est AltGr+d (symbole diamètre) ;

― soit optionnellement une touche supplémentaire adjacente à AltGr, à penser entre AltGr et Windows droite. – Ajouter des touches physiques a été l’idée d’ISO/CEI 9995 depuis les origines, et je pense que c’est l’une des raisons principales de son échec. Que cette touche coïncide avec Contrôle droite est dû à l’implémentation de la norme par Microsoft et plus précisément par son développeur de dispositions de clavier Ian James.

À mon avis Ian James a dû faire au mieux face au fait que les normalisateurs conçoivent des claviers à un niveau d’abstraction trop élevé pour être efficace, qu’ils ne se préoccupent pas de prendre connaissance des fonctionnalités que les éditeurs d’OS ont déjà prévues pour les claviers. Cette méthode de travail explique à la fois le décalage entre les normes de clavier et les moyens techniques, et le manque d’idées sur comment faire des claviers performants et faciles à utiliser. Les sanctions ne se font pas attendre, tant du côté des utilisateurs sous forme de rejet, que de la part des éditeurs qui doivent en avoir marre de se voir demander la lune alors que les richesses de la terre sont à portée (en filant la métaphore), et je suis convaincu qu’ils savent très bien comment on pourrait faire de bons claviers, mais soit ils attendent en vain que les normalisateurs leur demandent conseil, soit cʼest aux informaticiens dans les pays bénéficiaires de s’en occuper à fond, car autrement Microsoft se verrait face à une masse de travail énorme difficile à gérer puisqu’ils rentreraient dans le rôle des normalisateurs.

C’est pour cela que moi je dis que les normalisateurs doivent mettre la main à la pâte en normalisant des claviers qu’ils savent faire, et en faisant les claviers qu’ils normalisent. En commençant par les faire pour Windows (91 % des PC, API figées), puis en les portant ou faisant porter vers les autres OS. Mais cela ne signifie nullement qu’il faudrait se borner à ce que le MSKLC gère par son interface graphique, notoirement limitée – non parce que Microsoft voudrait qu’on en reste là, mais juste pour dépanner la NSA, qui n’est pas payée par l’État pour programmer des claviers en C, mais pour faire des transcriptions dans des langues exotiques sans faire fuiter lesquelles exactement. Le MSKLC ne représente nullement les dernières volontés de Microsoft pour tous les claviers du monde. C’est une facilité pour se dépanner, et c’est comme telle que Karl Pentzlin l’a utilisé. Au delà, Microsoft apprécie l’enthousiasme de ceux qui développent des concepts de clavier plus performants, et on vous souhaite personnellement du succès avec votre projet.

À bon entendeur…

L’AFNOR a tout à fait conscience des risques inhérents à une implémentation d’ISO/CEI 9995, du moins si cette norme est prise à l’état où elle se trouve – certes déjà meilleur qu’au début grâce aux travaux d’Alain LaBonté et de Karl Pentzlin, mais encore si loin de l’optimum que toute implémentation nationale conduit toujours inévitablement à l’échec. Face à cette situation, l’AFNOR a promis de ne pas aller jusqu’à la relative complexité du clavier canadien, grâce notamment à des options dégagées en coopération avec Karl Pentzlin.

Des options, il y en a un paquet sous Windows, et cela donne des claviers assez sympas. Windows reste probablement le facteur limitatif, car Linux peut générer par touche morte plus d’une unité de code. Mais Windows gère les touches mortes chaînées – et avec elles, l’émulation compose – contrairement à ce que pensait Karl Pentzlin et moi-même au début. Moi aussi je m’en suis plaint amèrement et pour rien puisque ça ne manque pas du tout !

Et il y a encore un certain nombre d’autres options très utiles sous Windows (et les autres OS). Je ne suis pas sûr que le rédacteur (et concepteur !) des normes allemande et internationale actuelles ait pareillement indiqué ces options. Le principal obstacle qui empêche de les utiliser, reste sans doute que ces options ne sont pas (pas encore !) prévues dans ISO/CEI 9995… qui en maigre compensation prévoit d’autres “options”. Jusqu’à présent, ces dernières ont tout l’air d’être soit irréalisables, soit pas assez séduisantes.

On espère que la France saura prendre son destin en main, et mener à son terme la démarche qu’elle avait engagée il y a plus de trente ans : se doter, et doter le monde, d’un schéma de disposition de clavier intelligible, efficace et performant.

À mon avis la réussite est à portée, mais logiquement elle conduirait l’Allemagne à re-réviser sa norme nationale. J’espère que le blocage ne viendra pas de là. Ce serait la énième fois qu’un pays d’Europe fasse tourner les autres en bourrique (bien que maintenant ce soit à un niveau plus subtil).

Conclusion : Faut-il modifier le bépo ?

La tendance générale est à la complétion non-invasive qui ne remet pas en cause la carte simplifiée et la gravure des Typematrix™ 2030 existants. Mais on peut aussi envisager une stratégie tournée vers l’avenir et qui ne reproduise pas les erreurs commises dans les années 1970 et 1980, quand un faible nombre de professionnels s’opposait farouchement à la clairvoyance de ceux qui recommandaient une optimisation ergonomique aussi de la disposition alphabétique juste avant la démocratisation des ordinateurs. L’optimisation que représente le bépo est considérable, mais quant à savoir si elle est suffisante, les avis sont partagés. Poursuivre son développement in extremis avant sa normalisation ne relève nullement de l’acharnement, ni forcément de la gageure. C’est une démarche incontournable dans le respect des Français. Démonter et remonter quelques touches sur un certain nombre d’unités déià produites et vendues n’est rien face à cette responsabilité.

Pour nous motiver je vais commencer par secouer quelques vieux marronniers, espérant qu’au lieu d’être en fleurs – ou en pleurs ? – ils produisent maintenant leurs fruits, et qu’on ne va pas mal le prendre.

Par rapport au regroupement des voyelles, qui fut un postulat de départ inspiré du clavier Dvorak, on relève qu’il a chassé la plupart des consonnes, dont le C et le V, vers la moitié droite, et on pourrait s’interroger sur le pourquoi de la volonté de faciliter l’apprentissage au détriment de la valeur d’usage. N’est-on pas ainsi dans une même logique qu’en plaçant les lettres dans l’ordre alphabétique ? À mes yeux ce présupposé a été une erreur méthodologique, car cela ne sert presque à rien. August Dvorak a pu recourir à cette astuce aussi pour augmenter les chances de trouver la bonne disposition, parce qu’il ne pouvait pas faire calculer grand-chose à son époque.

Dans un souci d’efficacité, commencer par faire table rase n’est pas une condition de réussite. Tout ce qu’August Dvorak a repris du qwerty – le A, le M, les onze premières touches de la rangée des chiffres, les paires minuscule-majuscule aussi pour les ponctuations (pour maîtriser les coûts de fabrication et de formation peut-être aussi) – nous encourage aujourd’hui à ne pas hésiter à garder ce qu’il y a de bon dans l’azerty, surtout le bloc des ponctuations, déjà toutes groupées. Sur un clavier d’ordinateur cela ne vaut pas la peine non plus de déplacer les X, C et V, vu les fréquences de ces lettres (le C vient en 12ᵉ position, le V en 16ᵉ). C’est déjà bien d’avoir repris le A du Dvorak et du qwerty, et d’avoir gardé le X à portée de main gauche lui aussi. Reste à rapprocher aussi le C et le V. L’impact sur l’ergonomie en écriture est quasiment nul voire positif (digramme CH), alors que pour les droitiers c’est un grand plus quand la souris est en action. Au moins les claviers latins – et quasiment eux seuls – ont la particularité de faire correspondre les identifiants de touches (Virtual Keys), qui comptent pour les raccourcis, avec les lettres produites par les touches. C’est une contrainte à bien garder en vue quand le but est de normaliser une disposition qui sera utilisée par l’Éducation nationale.

Si j’ai bien compris, le bépo est un mélange entre une disposition prédéfinie et une disposition calculée. Je pense que le secret de la formule est là, de mélanger plusieurs méthodes. Comme dans toute recette, la réussite dépend alors du choix de ces ingrédients, de leur dosage et de leur priorisation. La reprise de l’approche d’August Dvorak et la conception assistée par ordinateur sont à mon avis deux bons éléments. Il semblerait que tous les deux aient été légèrement surdosés, mais les concepteurs du bépo savaient faire preuve de discernement. Le regroupement sur la rangée de repos a ainsi subi des entorses en fonction de la carte d’accessibilité actuelle, contrairement au clavier Dvorak optimisé pour les machines mécaniques. Curieusement, le regroupement des voyelles sur un même côté, quant à lui, n’a pas été sacrifié à l’optimisation.

Le résultat de ce que j’appelle la CAO de la disposition a lui aussi bénéficié d’ajustements humains, même si cela a pu être perçu comme une hérésie alors que c’était une intervention aussi humaine que le regroupement préconçu des voyelles. Une explication possible de cette perception est que la valeur attribuée à un principe de conception dépassait la valeur due à son utilité. Or contrairement à ce qui est vrai dans d’autres domaines, se concentrer sur l’utilité réelle n’est probablement pas mauvais en soi en matière de dispositions de clavier. Il en résulte une interrogation quant à une éventuelle instrumentalisation pour la contestation. Une telle attitude oblige en effet à commencer par tout casser afin de construire de l’entièrement neuf. Toute reprise d’éléments de l’azerty, fussent-ils bons, serait perçue comme une perpétuation de reliquats du passé, engendrant quotidiennement de douloureuses réminiscences. Ce n’était en tout cas pas la démarche d’August Dvorak. “Menacer le monde avec des dispositions de clavier clivantes et controversées” était certainement la dernière chose à laquelle ce bienfaiteur de l’humanité aurait pu penser. Peut-être pourra-t-on ainsi refermer la parenthèse philosophique que d’aucuns ont ouverte, ce qui était leur bon droit mais ne doit pas nuire à la normalisation d’une disposition de clavier ergonomique pour une nation entière.

__________