Le formulaire comme filtre invisible
Chaque projet qui collecte des données sur des personnes passe par un moment discret mais déterminant: la spécification des champs de nom. Le chef de projet écrit “prénom (obligatoire), nom de famille (obligatoire), 30 caractères maximum, lettres uniquement” et passe à la suite. En trois lignes, il vient de définir qui pourra utiliser le système et qui en sera exclu.
Cette exclusion n’est jamais intentionnelle. Elle résulte d’une série d’hypothèses culturelles tellement ancrées qu’elles passent pour des évidences: tout le monde a un prénom et un nom de famille, les noms s’écrivent en lettres latines sans caractères spéciaux, un nom tient en 30 caractères et ne change pas au cours d’une vie, de sorte qu’aucune de ces hypothèses n’est universellement vraie.
Les noms du monde ne rentrent pas dans deux champs
Le W3C recense la diversité des conventions de nommage à travers le monde, et le constat est sans appel: la structure “prénom + nom de famille” est une convention occidentale, pas une norme universelle.
En Chine, au Japon, en Corée et en Hongrie, le nom de famille précède ce que nous appelons le prénom. En Indonésie, la majorité de la population javanaise porte un nom unique, sans patronyme (nom de famille transmis par filiation). En Éthiopie, ce que les formulaires occidentaux interprètent comme un “nom de famille” est en réalité le prénom du père, qui change donc à chaque génération. En Islande, le système patronymique fait que le “nom de famille” d’une personne n’est partagé par aucun autre membre de sa famille.
Les noms hispaniques comportent couramment deux noms de famille (paternel et maternel), ce qui fait dépasser les 30 caractères dans de nombreux cas. Des noms indiens comme Subramanian Chandrasekaran ou des noms africains composés atteignent facilement 35 caractères. Quant aux caractères dits “spéciaux” (apostrophes dans O’Brien ou N’Guessan, tirets dans Marie-Claire, diacritiques comme les accents, le tilde ou la cédille dans Ñoño ou Dušan), ils font partie intégrante de millions de noms parfaitement courants.
Ce que ces hypothèses coûtent au projet
Les conséquences d’exigences mal posées sur les noms ne sont pas abstraites. Elles se manifestent sous forme de dysfonctionnements concrets que le chef de projet devra gérer.
Un nom tronqué sur un billet d’avion, parce que le système a coupé à 25 caractères, provoque un refus d’embarquement si le nom ne correspond plus au passeport. L’Organisation de l’aviation civile internationale (ICAO) définit dans son Doc 9303 les normes de transcription des noms sur les documents de voyage, et les écarts entre ces normes et celles des systèmes internes sont une source récurrente de problèmes.
La translittération (conversion d’un nom écrit dans un alphabet non-latin vers l’alphabet latin) n’est pas bijective: le même caractère chinois peut donner Zhou, Chow ou Chou selon la convention utilisée. Un système qui dédoublonne par le nom créera des fiches multiples pour la même personne, ou fusionnera des personnes distinctes.
Un champ “nom de famille obligatoire” empêche purement et simplement une personne mononyme de créer un compte. Quand cette personne est un client, un partenaire ou un collaborateur, le coût n’est pas seulement technique: c’est une perte de relation commerciale. À l’échelle d’un projet international, ces exclusions se cumulent et génèrent un volume de tickets de support que personne n’avait anticipé dans le budget initial.
Où se situe la responsabilité du chef de projet
Ces défauts ne naissent pas dans le code: ils naissent dans les spécifications. Patrick McKenzie a publié en 2010 une liste de 40 hypothèses erronées sur les noms, devenue une référence dans le monde du développement. Mais le développeur implémente ce que les exigences décrivent. Si les exigences stipulent “prénom obligatoire, lettres uniquement, 25 caractères max”, le développeur livrera exactement cela.
Le moment critique se situe lors de l’élicitation des exigences. C’est à ce stade que le chef de projet doit poser une question rarement formulée: qui sont les utilisateurs de ce système, dans quels pays résident-ils, et quels formats de noms sont représentés dans cette population?
Cette question n’exige pas une expertise linguistique. Elle exige la même rigueur que celle appliquée aux exigences sur les adresses postales ou les numéros de téléphone internationaux: vérifier que les contraintes techniques correspondent à la réalité des données.
Spécifier autrement
Plusieurs pratiques permettent de cadrer les exigences sur les noms sans complexifier excessivement les systèmes, à condition de les intégrer dès la phase de spécification.
La première consiste à privilégier un champ unique “nom complet tel que fourni” chaque fois que la décomposition prénom/nom n’est pas nécessaire au traitement métier. Un système d’envoi de courrier a besoin du nom complet, pas d’une structure que le système interprètera mal dans la moitié des cas. Cette approche réduit à la fois la complexité technique et le risque d’exclusion.
La deuxième pratique porte sur l’ajout d’un champ “nom d’appel” ou “nom préféré”, distinct du nom légal. Ce champ couvre les cas d’usage quotidiens (affichage dans les interfaces, en-têtes d’emails, badges de conférence) sans toucher à l’identité légale. Il absorbe aussi les changements de nom liés au mariage, au divorce ou à d’autres événements de vie, ce qui évite de devoir modifier le nom légal dans le système pour des raisons purement pratiques.
La troisième pratique concerne la documentation explicite des contraintes de longueur et de jeu de caractères dans les exigences. Ces contraintes doivent être validées avec des exemples réels issus du public cible, et non avec les sempiternels “Jean Dupont” ou “John Smith”. Le W3C fournit des exemples de noms par pays qui permettent de tester les limites avant le développement.
Il est enfin essentiel de traiter le nom comme une donnée potentiellement évolutive. Un système qui utilise le nom comme clé d’identification unique, sans identifiant interne, deviendra dysfonctionnel au premier changement de nom. Cette contrainte technique doit figurer dans les exigences fonctionnelles, pas être découverte en production. Un formulaire qui rejette le nom d’un utilisateur légitime n’est pas un problème de diversité culturelle: c’est un défaut fonctionnel, au même titre qu’un formulaire qui refuse un code postal suisse à quatre chiffres parce qu’il attend cinq chiffres.