Concevoir des formulaires multilingues pour la santé mondiale : un formulaire en plusieurs langues

Introduction

Les systèmes de santé fonctionnent rarement dans une seule langue.

Dans de nombreuses régions du monde, il ne s'agit pas seulement d'une préférence, mais d'une exigence. Dans des pays comme la Suisse, le système de santé doit fonctionner de manière fluide en allemand, en français et en italien. Au Canada, l'anglais et le français sont tous deux utilisés dans les contextes cliniques et administratifs. En Inde, les applications doivent souvent prendre en charge plusieurs langues régionales en plus de l'anglais, tandis qu'en Afrique du Sud, les systèmes de santé évoluent dans un environnement comptant plus de dix langues officielles. Même dans les régions qui semblent plus homogènes sur le plan linguistique, les besoins multilingues surgissent rapidement lorsque les produits de santé numérique s'étendent au-delà des frontières ou desservent des populations de patients diversifiées.

Et pourtant, en ce qui concerne les formulaires, la solution la plus courante reste étonnamment inefficace : créer le même formulaire plusieurs fois — une version par langue.

À première vue, cette approche semble simple. Mais dès que les formulaires évoluent — de nouveaux champs sont ajoutés, la logique est mise à jour, les règles de validation changent — le coût de la duplication devient évident. Chaque version doit être maintenue séparément, les traductions divergent avec le temps, et des incohérences commencent à apparaître.

Ce qui commence comme un simple contournement se transforme rapidement en un problème de maintenance.

Le problème des formulaires dupliqués

Une configuration multilingue classique repose sur le maintien de versions distinctes du même formulaire pour chaque langue. Bien que cette approche puisse fonctionner au départ, elle engendre une fragmentation structurelle.

Chaque version du formulaire devient une entité à part entière. La logique peut évoluer différemment, les règles de validation peuvent diverger, et les mises à jour peuvent être appliquées de façon incohérente. Avec le temps, des formulaires censés représenter le même modèle de données ne se comportent plus de la même manière.

Il ne s'agit pas seulement d'un problème d'expérience utilisateur — cela affecte directement la qualité des données.

Lorsque les formulaires sont dupliqués, la structure qui les sous-tend l'est également. Dans les systèmes qui s'appuient sur des données structurées, tels que les architectures fondées sur FHIR, cela crée des incohérences difficiles à réconcilier par la suite. Les données collectées par différentes versions linguistiques peuvent ne plus s'aligner proprement, ce qui rend l'agrégation, l'analytique et l'interopérabilité plus complexes.

Une meilleure approche : un seul formulaire, plusieurs langues

Une approche plus évolutive consiste à définir le formulaire une seule fois et à l'enrichir de traductions.

Plutôt que de créer plusieurs formulaires, une définition unique du formulaire devient la source de vérité. Toutes les langues sont ajoutées dans le cadre de cette définition, généralement par l'intermédiaire d'extensions.

Cela introduit une séparation fondamentale entre la structure et la présentation. La structure du formulaire demeure stable, tandis que la couche de présentation s'adapte à la langue de l'utilisateur. Chaque question, étiquette et instruction peut avoir plusieurs représentations linguistiques, mais elles pointent toutes vers le même modèle de données sous-jacent. La logique, la validation et les correspondances restent cohérentes dans toutes les langues.

Dans les questionnaires FHIR, les traductions sont attachées à chaque élément à l'aide de l'extension standard translation. Une seule question porte son texte par défaut ainsi qu'une entrée par langue :

{
  "linkId": "chief-complaint",
  "type": "string",
  "text": "Chief complaint",
  "_text": {
    "extension": [
      {
        "url": "http://hl7.org/fhir/StructureDefinition/translation",
        "extension": [
          { "url": "lang", "valueCode": "de" },
          { "url": "content", "valueString": "Hauptbeschwerde" }
        ]
      },
      {
        "url": "http://hl7.org/fhir/StructureDefinition/translation",
        "extension": [
          { "url": "lang", "valueCode": "fr" },
          { "url": "content", "valueString": "Motif de consultation" }
        ]
      }
    ]
  }
}

Cette approche élimine la duplication et garantit que tous les utilisateurs, quelle que soit leur langue, interagissent avec la même structure de formulaire.

Le fonctionnement des formulaires multilingues en pratique

Un formulaire multilingue possède généralement une langue par défaut et un ensemble de traductions attachées à chaque élément. Lors du rendu du formulaire, le système détermine quelle langue afficher. Cela peut se produire de deux façons principales.

Dans certains cas, le formulaire est lancé directement dans une langue prédéfinie. C'est courant lorsque l'application connaît déjà la préférence linguistique de l'utilisateur — par exemple, à partir des paramètres de profil ou de la configuration du système.

Dans d'autres cas, les utilisateurs peuvent changer de langue en cours de remplissage du formulaire. Cela est particulièrement utile dans les scénarios cliniques réels, où un clinicien et un patient peuvent ne pas partager la même langue. Un clinicien peut commencer à remplir un formulaire dans une langue et passer à une autre pour confirmer des informations avec le patient.

Dans les deux cas, le formulaire sous-jacent reste inchangé. Seul le texte visible est mis à jour.

Le rôle de la Terminology et des ensembles de valeurs

La prise en charge multilingue ne concerne pas uniquement la traduction des étiquettes. Il s'agit également de s'assurer que les options de réponse sont correctement localisées tout en préservant leur signification.

C'est là que les liaisons terminologiques et les ensembles de valeurs deviennent essentiels.

Lorsque les options de réponse sont définies à l'aide de codes normalisés — tels que SNOMED CT ou LOINC —, le système peut récupérer les valeurs d'affichage appropriées dans différentes langues. Le même concept codé peut être présenté différemment selon la langue sélectionnée, tout en représentant la même signification sous-jacente.

Cela crée une séparation nette entre ce que l'utilisateur voit et ce que le système stocke. Les utilisateurs interagissent avec un texte localisé et familier, tandis que le système travaille avec des valeurs codées stables. Cela garantit que les données restent cohérentes, interopérables et adaptées à l'analytique, quelle que soit la langue.

En pratique, lors du rendu d'un formulaire, la langue courante — soit la langue par défaut, soit la langue sélectionnée par l'utilisateur — est transmise au paramètre displayLanguage de l'opération ValueSet/$expand :

GET /fhir/ValueSet/$expand?url=http://example.org/fhir/ValueSet/symptoms&displayLanguage=fr

Le serveur de terminologie utilise ce paramètre pour rechercher les traductions appropriées et retourne l'ensemble de valeurs dans la langue demandée. Si une traduction pour un concept donné n'est pas disponible, le serveur de terminologie revient à la langue par défaut.

Ce mécanisme permet aux formulaires multilingues d'afficher dynamiquement des options de réponse localisées tout en préservant la même structure codée sous-jacente dans toutes les langues. Sans cette couche, les formulaires multilingues risquent de se fragmenter à nouveau — non pas au niveau de la structure des données, mais au niveau sémantique.

Ce qui se passe lors de la soumission du formulaire

La langue joue également un rôle au moment de la soumission.

L'utilisateur interagit avec le formulaire dans la langue sélectionnée, et ce contexte se reflète dans la réponse. La réponse enregistrée correspond à la langue utilisée au moment du remplissage.

En même temps, les données structurées qui sous-tendent la réponse restent stables. Les codes, les correspondances et les données extraites ne dépendent pas de la langue de l'interface.

Cela permet aux systèmes de préserver à la fois :

• la représentation orientée utilisateur des données
• la structure normalisée requise pour l'interopérabilité

En conséquence, les données restent à la fois lisibles par les humains et lisibles par les machines.

Pourquoi cela est important pour les applications de santé modernes

Les formulaires multilingues ne sont pas simplement une fonctionnalité de commodité. Ils constituent une exigence pour les systèmes de santé modernes.

Les applications d'aujourd'hui sont rarement limitées à une seule région ou langue. Elles doivent prendre en charge des groupes d'utilisateurs diversifiés, des flux de travail transfrontaliers et des déploiements à l'échelle mondiale.

Dans le contexte d'initiatives d'interopérabilité comme l'EHDS, cela devient encore plus crucial. Les données doivent circuler entre les pays et être comprises par différents systèmes, quelle que soit la langue dans laquelle elles ont été saisies.

En séparant la structure de la présentation, les formulaires multilingues rendent cela possible. Ils permettent aux utilisateurs d'interagir avec les données dans leur propre langue, tout en garantissant que les données elles-mêmes restent cohérentes, normalisées et réutilisables.

Conclusion

L'approche traditionnelle des formulaires multilingues — dupliquer les formulaires pour chaque langue — n'est pas évolutive et introduit une complexité inutile.

Un modèle plus efficace consiste à définir le formulaire une seule fois et à l'enrichir de traductions. En combinant une définition de formulaire structuré unique avec des extensions de traduction et des ensembles de valeurs fondés sur la terminologie, il est possible de créer des formulaires à la fois conviviaux et interopérables.

Cette approche réduit la charge de maintenance, améliore la cohérence et s'aligne sur les normes modernes telles que FHIR.

Dans un écosystème de santé interconnecté, la prise en charge multilingue n'est pas une fonctionnalité supplémentaire. C'est une capacité fondamentale. Et lorsqu'elle est mise en œuvre correctement, elle ne complique pas les formulaires — elle les rend plus simples, plus robustes et prêts pour une utilisation dans des contextes réels.

Pour voir comment les formulaires multilingues fonctionnent en pratique, regardez une courte démonstration :

Ou commencez à créer et à tester vos propres formulaires multilingues dans le Aidbox Form Builder.