Quand la direction du texte devient un risque

Lorsqu’on parle de la prise en charge de l’hébreu dans un logiciel médical, la conversation tend à se réduire à une seule question : l’interface est-elle traduite. C’est la question la moins importante. Un système peut être parfaitement traduit et afficher malgré tout un chiffre erroné au médecin, car le problème ne réside pas dans la traduction des mots mais dans l’ordre selon lequel le navigateur dessine les chiffres à l’intérieur d’une phrase en hébreu.

Ce qui se passe concrètement

L’algorithme du texte bidirectionnel, qui fait partie de la norme Unicode, détermine comment ordonner à l’écran des séquences de caractères de directions différentes. Les lettres hébraïques s’écrivent de droite à gauche, les chiffres toujours de gauche à droite, et des signes comme l’espace, le point, la barre oblique, le tiret, le plus et le moins sont neutres : leur direction est déterminée par leur environnement. Lorsqu’on sépare deux nombres par un signe neutre, à l’intérieur d’un paragraphe en hébreu, le signe adopte la direction du paragraphe, et les deux nombres se retrouvent permutés dans l’ordre d’affichage.

Le résultat n’est pas théorique. Voici trois exemples relevés lors d’un examen systématique d’écrans en hébreu :

La donnée réelle	Ce qui est dessiné à l’écran	Le sens qui parvient au soignant
Tension artérielle 140.4 / 87.6	87.6 / 140.4, l’unité placée avant le nombre	Systolique et diastolique permutés : une hypertension se lit comme une hypotension
Intervalle de référence au laboratoire : supérieur à 60	Le signe est dessiné comme inférieur à	Une valeur dans l’intervalle se lit comme anormale, et une valeur anormale comme normale
Un avoir de 25 shekels avec un signe moins	Le signe saute de l’autre côté du montant	Un avoir au grand livre se lit comme un débit

Le cas des signes de comparaison est particulièrement dangereux

Dans les deux premiers exemples, le mécanisme est différent. Pour la tension, les caractères n’ont pas changé, ils ont seulement été réordonnés. Pour l’intervalle de référence, il se produit autre chose : les caractères « supérieur à » et « inférieur à » sont définis dans Unicode comme des caractères à image miroir. Lorsqu’ils se trouvent à un niveau d’imbrication impair, c’est-à-dire dans un contexte de droite à gauche, le moteur dessine le caractère inversé. Rien ne se déplace. Le caractère lui-même est remplacé par son opposé.

Il en va de même pour tout signe possédant une image miroir : les parenthèses de tout type, les guillemets chevrons, et parfois aussi la barre oblique, selon la police. Si une clinique utilise des codes de statut composés de signes de ponctuation — et c’est plus fréquent qu’on ne le croit dans les systèmes anciens — on peut aboutir à une situation où un statut s’affiche comme un tout autre statut.

Pourquoi les captures d’écran ne détectent pas le problème

C’est le point le plus important pour un gestionnaire de clinique qui évalue un système. Le test habituel de la prise en charge de l’hébreu consiste à ouvrir des écrans et à regarder. Mais un intervalle inversé ressemble encore à un intervalle. Deux nombres permutés ressemblent encore à une tension normale. L’œil voit une structure correcte, et passe donc à la suite. Seul un test qui compare l’ordre réel des caractères à la donnée d’origine révèle l’écart.

C’est pourquoi le test approprié n’est pas visuel mais métrologique : prendre une valeur dont on connaît le contenu, l’observer à l’écran en hébreu, et comparer caractère par caractère. On peut le faire manuellement au cours d’une démonstration. Voici cinq valeurs qu’il vaut la peine de demander à voir :

• Un indicateur vital composé, comme la tension artérielle ou un score de douleur sur une échelle.
• Un résultat de laboratoire assorti d’un intervalle de référence avec un signe de comparaison.
• Une ligne d’avoir au grand livre, c’est-à-dire un montant négatif.
• Une plage horaire de rendez-vous, par exemple une heure de début jusqu’à une heure de fin.
• Une posologie comportant un nombre, une unité et une fréquence sur la même ligne.

Pourquoi cela se produit dans presque tout système traduit

Parce que la prise en charge de la direction inverse est généralement construite après coup, comme une couche de correctifs par-dessus une conception pensée pour l’anglais. Dans un système open source ancien et reconnu du secteur, une mesure de la feuille de style montre que seulement 5 % environ des règles de style changent entre le mode normal et le mode droite à gauche, et que l’interface en hébreu est traduite à environ 61 % au décompte des chaînes de caractères. De tels chiffres produisent des écrans hybrides : une partie alignée correctement, une partie non, et des boutons restés au mauvais endroit.

Le problème est plus profond que ces pourcentages. Une correction fondée sur des rustines traite l’écran signalé, et non le mécanisme. Chaque nouvel écran construit ensuite naît avec le même défaut.

La règle pratique : l’unité d’isolement est la donnée telle que le clinicien la lit, et non le nombre isolé. Une tension artérielle est une seule donnée. Un intervalle de dates est une seule donnée. Un montant assorti d’un signe est une seule donnée. Isoler chaque nombre séparément, en laissant le séparateur exposé, reproduit exactement le défaut.

Comment résoudre le problème correctement

La solution n’est pas une liste de correctifs par écran mais trois décisions d’architecture :

1. Une couche de formatage typée. Chaque donnée numérique passe par une fonction qui connaît son type — indicateur, montant, intervalle, identifiant, date — et renvoie une seule séquence isolée. Le développeur qui écrit un écran n’a pas à en décider.
2. Une feuille de style unique à propriétés logiques. Au lieu de gauche et droite physiques, on utilise début et fin. Ainsi il n’y a pas deux feuilles à maintenir, et un nouvel écran naît correct dans les deux directions.
3. Des tests d’ordre des caractères en intégration continue. Non pas des captures d’écran, mais des assertions qui vérifient que la valeur affichée est identique, dans son ordre, à la valeur enregistrée. Un tel test échoue dès que quelqu’un ajoute un écran qui n’est pas passé par la couche de formatage.

Quelles questions poser à un fournisseur

Lors de l’évaluation d’un système, trois questions distinguent une prise en charge réelle d’une prise en charge déclarée. Premièrement, existe-t-il une seule feuille de style pour les deux directions, ou deux. Deuxièmement, le formatage des nombres est-il centralisé dans une seule couche, ou chaque écran s’en occupe-t-il lui-même. Troisièmement, existe-t-il des tests automatisés qui vérifient l’ordre des caractères, et si oui — peut-on voir un exemple de test qui a échoué puis été corrigé.

Un fournisseur qui a des réponses claires à ces trois questions a probablement pris le sujet au sérieux. Un fournisseur qui répond que le système est traduit en hébreu a répondu à une autre question.

Retour au blog