Réponse courte. Une application en deux langues se décide la première semaine, pas à la fin. On écrit d'abord où va chaque langue : l'interface en arabe et en français, les messages WhatsApp en darija écrite en lettres latines, les documents bilingues. Puis on construit cinq choses. Les textes : une clé par phrase, des variables nommées, et les six formes de pluriel de l'arabe là où le français en a deux ; jamais une phrase assemblée par morceaux. La mise en page : écrite en début et fin, jamais en gauche et droite, pour qu'elle se retourne seule ; une liste de ce qui se retourne, flèches et listes, et de ce qui ne se retourne pas, horloges et chiffres. Les données : la locale arabe d'Algérie écrit les mêmes chiffres qu'en français, avec une virgule décimale ; les dates suivent la locale ; la base et l'API restent toujours en chiffres occidentaux. Les valeurs insérées, noms et numéros, sont isolées pour que le + de +213 ne saute pas de côté. Et la relecture par une personne qui lit l'arabe, sur le téléphone, à chaque démonstration. Six semaines, et la version arabe est visible dès la troisième.
Ce guide s'adresse au gérant dont les employés lisent l'arabe et les fournisseurs le français, au fondateur installé en France qui parle à ses clients en darija sur WhatsApp et à sa banque en français, et au responsable qui doit comparer un devis « bilingue » avec un autre. Il ne redit pas comment une recherche comprend l'arabe et la darija, décrit dans le guide sur la recherche, ni comment un agent parle sur WhatsApp, décrit dans le guide dédié ; il décrit ce qui se construit pour que l'interface, les messages et les documents soient justes dans les deux langues, et il prolonge notre page sur les applications mobiles.
Ce que les référentiels disent
La locale a une définition publique, et elle surprend souvent. Le référentiel de données de locale de l'Unicode, celui que suivent les téléphones et les navigateurs, donne pour l'arabe d'Algérie un système de numération par défaut « latn », c'est-à-dire les chiffres 0 à 9 que vous lisez ici, et non les chiffres dits indiens utilisés au Machrek ; il donne la virgule comme séparateur décimal et le point comme séparateur de milliers, de sorte que douze mille quatre cents dinars s'écrivent « 12.400,00 » en arabe algérien. Ce que cela impose : une application réglée sur « arabe » générique affichera des chiffres que vos employés ne lisent pas au quotidien ; la locale doit être l'arabe d'Algérie, et les chiffres les mêmes dans les deux langues.
La mise en page qui se retourne a des règles écrites par les plateformes. La documentation d'Android demande de déclarer que l'application supporte le sens droite à gauche, de remplacer partout « gauche » et « droite » par « début » et « fin », et prévient que les icônes à retourner se déclarent une par une, parce que « si le fait de refléter votre image change son interprétation », il ne faut pas la refléter : une horloge, un lecteur, un logo ne se retournent pas. Elle décrit aussi le piège des valeurs insérées : un numéro qui commence par « + » ou une adresse qui commence par un chiffre, placés dans une phrase arabe, voient leur début sauter de l'autre côté, et la solution est d'envelopper chaque valeur insérée dans des marques de direction. Ce que cela impose : la liste de ce qui se retourne est écrite la première semaine, et chaque variable d'une phrase est isolée avant d'y entrer.
La même documentation signale un piège invisible : formater un nombre avec la locale de l'appareil pour le mettre dans une requête ou une adresse produit, sur un téléphone réglé en arabe du Machrek, des chiffres que la base ne comprend pas ; ce qui est lu par une machine se formate toujours en chiffres occidentaux. Et depuis Android 13, l'utilisateur peut choisir la langue de chaque application indépendamment de celle du téléphone, ce qui compte pour une entreprise où la caisse est en arabe et la comptabilité en français sur le même appareil. Ce que nous n'avons pas trouvé : une étude publique des langues préférées par les utilisateurs d'applications d'entreprise en Algérie ; ce que nous voyons sur nos projets, c'est l'arabe au comptoir et dans l'entrepôt, le français dans les bureaux et les documents, et la darija dans les messages, et nous le disons comme une observation.
Le même écran, en français et en arabe
La version arabe ne se comprend pas sur un principe mais sur un écran, dessiné deux fois.
Ce qui se retourne. La flèche de retour pointe vers la droite, parce que « revenir » en arabe est vers la droite. Les libellés de la liste passent du côté « début », qui est la droite, et les montants du côté « fin », qui est la gauche. La barre de progression se remplit depuis la droite. Tout cela se produit seul si la mise en page a été écrite en début et fin ; rien ne se produit, ou tout se retourne y compris ce qui ne devrait pas, si elle a été écrite en gauche et droite et « adaptée » après coup.
Ce qui ne se retourne pas. L'horloge, parce qu'une horloge retournée est fausse. Les chiffres, parce que la locale arabe d'Algérie utilise les mêmes que le français : 11.760,00 en arabe, 11 760,00 en français, la différence est dans les séparateurs, pas dans les chiffres. Le numéro de téléphone, isolé pour que « +213 » reste au début et que les groupes de chiffres gardent leur ordre. La date, 10/11/2026, identique dans les deux langues parce que c'est la locale qui le dit. Et le logo. La liste de ce qui se retourne et de ce qui ne se retourne pas tient sur une page, et elle est écrite la première semaine, avant la première maquette.
«La locale arabe d'Algérie écrit les mêmes chiffres que le français ; ce qui change, ce sont les séparateurs, le sens de la page, et l'ordre des mots.»
Une application en deux langues, en cinq couches
Derrière cet écran, cinq couches, et celle où l'on gagne ou perd la version arabe.
Les textes et traductions : une clé par phrase, des variables nommées, les pluriels de chaque langue, et trois fichiers, français, arabe, et darija pour les messages ; aucune phrase construite par morceaux dans le code, aucun texte en dur. La mise en page : tout est écrit en début et fin ; les flèches de navigation et les listes se retournent, les horloges, lecteurs et chiffres non ; les icônes qui se reflètent sont déclarées une par une ; une seule maquette, testée dans les deux sens dès la première semaine. Les données : chiffres, dates, monnaie et tri selon la locale ; une recherche qui comprend l'arabe sans points diacritiques et les deux écritures d'un nom, selon le guide sur la recherche ; ce que la base et l'API stockent ne change jamais de langue.
La saisie : clavier arabe et français, téléphone normalisé en +213 quelle que soit la façon dont il a été tapé, noms stockés dans les deux écritures quand il le faut, adresses et wilayas en deux langues ; un client saisi en arabe au comptoir doit être retrouvé en français depuis la France, et c'est la règle que le guide sur la reprise de données applique aux anciens fichiers. Le processus : chaque écran relu par une personne qui lit l'arabe, des captures dans les deux sens dans la recette, et les textes livrés au traducteur avec leur contexte ; la version arabe n'est pas « la traduction de la fin », elle est livrée à chaque démonstration, selon le guide sur la livraison.
Six pièges d'une application en deux langues
Six pièges que nous trouvons sur presque toutes les versions arabes que nous reprenons, et ce qu'on construit contre chacun.
La phrase construite par morceaux : « Commande » + n + « livrée » marche en français et donne en arabe un ordre de mots faux et un pluriel faux ; une clé par phrase, et les six formes de pluriel de l'arabe dans le fichier de langue. Le numéro de téléphone coupé : +213 661 23 45 67 dans une phrase arabe voit son + et ses groupes changer de place ; chaque valeur insérée est isolée avant d'entrer. Tout se retourne, ou rien : soit les boutons et l'horloge sont à l'envers, soit rien n'est retourné et l'arabe est aligné à gauche ; mise en page en début et fin, et liste écrite de ce qui se retourne.
Les chiffres qui changent : montants en chiffres indiens, ou point et virgule inversés entre les langues ; locale arabe d'Algérie, chiffres occidentaux, virgule décimale, point des milliers, et la base toujours en chiffres occidentaux. La date ambiguë : 03/11 lu « 3 novembre » par l'un et « 11 mars » par l'autre, et des noms de mois du Machrek que personne ne lit à Sétif ; format par locale, mois en toutes lettres dans les documents, noms de mois algériens en arabe. La police sans arabe : des carrés à la place des lettres sur un Android de 2019, ou une police arabe qui jure avec la française ; une famille qui couvre les deux écritures, embarquée dans l'application et les PDF, testée sur le téléphone ancien que le guide sur la vitesse impose déjà.
Une phrase, de la clé de traduction au téléphone du client
Une phrase traverse six étapes avant d'atteindre un téléphone, et chacune est une règle, pas un geste.
La clé : une phrase est une clé, order.delivered, avec des variables nommées, le nombre, le nom, la date ; jamais une concaténation. Les trois fichiers : français, arabe, et darija pour les messages WhatsApp ; le fichier arabe porte les six formes de pluriel, zéro, un, deux, peu, beaucoup, autre, parce que « 3 colis » et « 11 colis » ne se disent pas avec la même forme, et « 2 colis » a la sienne, le duel. La règle de pluriel est appliquée par la langue, pas par le développeur : pour trois, le français choisit sa forme « autre » et l'arabe sa forme « peu ».
Le formatage par la locale : chiffres occidentaux, virgule décimale, point des milliers en arabe d'Algérie, date au format local, et jamais « 11/10 » pour le 10 novembre. L'isolation : le nom et le numéro sont enveloppés avant d'entrer dans la phrase, sinon le + et les chiffres sautent de côté dans une phrase arabe. Le rendu dans trois registres : « 3 colis livrés à Karim Benali le 10/11/2026 » pour le gérant, la même en arabe pour l'employé, et « 3 colis wslou l Karim » en darija pour le client, écrite en lettres latines parce que c'est ainsi que vos clients l'écrivent, par les gabarits décrits dans le guide sur les notifications.
«Une phrase est une clé avec des variables, traduite trois fois, pluralisée par la langue, formatée par la locale, et isolée là où une valeur entre.»
Vu ailleurs : les référentiels de locale et des plateformes, et ce qui se transpose
Deux sources disent l'essentiel. Le référentiel de locale de l'Unicode dit que l'arabe d'Algérie s'écrit avec les chiffres occidentaux, une virgule décimale et un point des milliers ; ce qui se transpose, c'est que la locale est ar-DZ, pas « arabe », et que les chiffres sont les mêmes dans les deux langues de l'application. La documentation d'Android dit d'écrire la mise en page en début et fin, de déclarer les icônes à refléter une par une, d'isoler les valeurs insérées dans les phrases, et de ne jamais formater avec la locale ce qu'une machine lira ; ce qui se transpose, c'est la liste de ce qui se retourne, l'isolation systématique des variables, et la séparation entre ce que l'utilisateur voit et ce que la base stocke.
Ce que ces sources ne disent pas : quelle langue vos employés lisent au comptoir, quelle langue vos clients écrivent sur WhatsApp, et quels documents doivent être bilingues ; la première semaine du projet y répond, et c'est le gérant qui signe la liste.
Livrer la version arabe, en six étapes
La version arabe n'est pas une traduction qu'on ajoute : c'est un parcours de six étapes qui commence avant la première maquette.
Décider où va chaque langue : interface en arabe et en français, messages en darija, documents bilingues ; écrit et signé. Extraire les textes en clés : variables nommées, pluriels, et un contexte pour le traducteur ; il ne reste plus un texte en dur. Maquetter dans les deux sens : début et fin, liste de ce qui se retourne, polices à deux écritures ; c'est l'étape qui coûte une heure la première semaine et des semaines si on la saute.
Traduire avec le contexte : une capture par écran, pour que le traducteur voie où va la phrase et choisisse le bon mot. Relire sur le téléphone : par une personne qui lit l'arabe, avec des captures dans les deux sens dans la recette ; c'est l'étape qu'on saute toujours, et c'est pour cela que les boutons sont à l'envers. Livrer à chaque démonstration : les deux langues ensemble, jamais la française d'abord et l'arabe « après », quand plus personne n'a le temps.
Les règles d'une application qui marche dans les deux langues
Six règles, écrites la première semaine. Où va chaque langue est écrit : interface, messages, documents. Une clé par phrase, des variables nommées, les pluriels de chaque langue. La mise en page en début et fin, et la liste de ce qui se retourne. La locale arabe d'Algérie pour les chiffres et les dates ; la base en chiffres occidentaux. Chaque valeur insérée est isolée. La version arabe est relue sur le téléphone par une personne qui lit l'arabe, à chaque démonstration.
Une septième règle porte sur le devis : « application bilingue arabe-français » n'est pas une exigence, c'est une phrase ; l'exigence s'écrit « langues par usage écrites : interface, messages, documents ; textes en clés avec variables nommées et pluriels par langue, aucun texte en dur ; mise en page en début et fin avec liste des éléments reflétés ; locale ar-DZ pour chiffres, dates, monnaie, tri ; isolation bidirectionnelle des valeurs insérées ; polices couvrant les deux écritures dans l'application et les PDF ; relecture par un lecteur d'arabe et captures dans les deux sens à chaque recette ; messages WhatsApp en darija », et elle se vérifie comme le guide sur le cahier des charges le recommande. Un devis qui écrit « traduction en arabe incluse » a prévu de traduire à la fin, et c'est la version avec les boutons à l'envers.
Six applications, et leur question de langue
Six applications que nous construisons souvent, et pour chacune la décision de langue qui comptait le plus.
- La caisse en magasin, décrite dans le guide dédié. Interface en arabe pour les vendeurs, tickets bilingues, chiffres identiques dans les deux langues ; le total est le même que le client lise d'un côté ou de l'autre.
- Le portail de commande B2B, décrit dans le guide dédié. Les détaillants commandent en arabe, le grossiste lit en français ; les noms de produits sont stockés dans les deux écritures et la recherche comprend les deux.
- Le commerce piloté depuis la France, décrit dans le guide dédié. Le fondateur lit le tableau de bord en français, l'équipe à Alger travaille en arabe ; même application, même données, langue par utilisateur.
- La plateforme de cours, décrite dans le guide dédié. Le parent en France reçoit ses messages en français, l'élève en Algérie travaille en arabe, et le rappel WhatsApp part en darija.
- L'agence Omra, décrite dans le guide dédié. Les documents des pèlerins sont bilingues, avec les dates en toutes lettres dans les deux calendriers, parce qu'une date ambiguë sur un visa n'est pas une option.
- L'application mobile mise à jour, décrite dans le guide dédié. Un nouveau texte part par les fichiers de langue servis par l'API, sans passer par les stores, dans les trois registres à la fois.
Le calendrier 2027
Le calendrier est celui d'une application livrée dans les deux langues en six semaines, et la version arabe est visible dès la troisième.
La semaine 0 à 1 écrit les langues et les règles : quelle langue pour l'interface, les messages et les documents ; chiffres, dates et monnaie selon la locale arabe d'Algérie ; la liste de ce qui se retourne et de ce qui ne se retourne pas ; signé par le gérant. La semaine 1 à 2 extrait les textes en clés, avec variables nommées, pluriels et contexte ; il ne reste plus un texte en dur dans le code. La semaine 2 à 3 écrit la mise en page en début et fin, déclare les icônes à refléter, embarque les polices à deux écritures, et montre le premier écran en arabe : c'est la semaine où la version arabe devient réelle.
La semaine 3 à 4 traite les données et la saisie : formats par locale, tri et recherche arabes, téléphone normalisé, noms en deux écritures. La semaine 4 à 5 est la relecture : chaque écran relu sur le téléphone par un lecteur d'arabe, captures dans les deux sens dans la recette, corrections. La semaine 5 à 6 livre les documents PDF bilingues avec les deux écritures et les gabarits WhatsApp en darija, et met en production. Chaque lot est démontré dans les deux langues, comme le guide sur la livraison le décrit : la version arabe n'est jamais « après ».
Ce qui fait échouer une application en deux langues
Les versions arabes que nous reprenons ont presque toujours échoué pour l'une de ces raisons.
- Traduite à la fin. La mise en page est en gauche et droite, et la retourner coûte des semaines ; on livre « sans le miroir ».
- Des phrases assemblées par morceaux. L'ordre des mots arabes est faux, et personne ne l'a lu.
- L'arabe générique. Des chiffres indiens que les employés ne lisent pas, des noms de mois du Machrek.
- Les valeurs non isolées. Le + des numéros et les chiffres des adresses sautent de côté.
- Tout retourné. L'horloge, le lecteur et le logo aussi ; l'application a l'air cassée.
- Une police sans arabe. Des carrés sur les téléphones de 2019, que le développeur n'a pas.
- Personne ne lit l'arabe dans l'équipe. La version est livrée sans qu'un seul écran ait été relu.
Questions fréquentes
Les questions que nous recevons de gérants, de fondateurs et de responsables informatiques.
- Pourquoi la version arabe de notre application a-t-elle les boutons à l’envers ?
- Parce que la mise en page a été écrite en gauche et droite, puis traduite et « retournée » à la fin. Une mise en page écrite en début et fin se retourne seule et proprement ; et une liste écrite de ce qui se retourne, flèches et listes, et de ce qui ne se retourne pas, horloges, chiffres et logos, évite que tout soit retourné ou rien. Cela se décide la première semaine, avant la première maquette.
- Les chiffres doivent-ils être en chiffres arabes dans la version arabe ?
- En Algérie, non : la locale arabe d'Algérie du référentiel Unicode utilise les chiffres occidentaux, 0 à 9, avec une virgule décimale et un point des milliers. Une application réglée sur « arabe » générique afficherait les chiffres dits indiens, que vos employés ne lisent pas au quotidien. Les chiffres sont donc les mêmes dans les deux langues ; seuls les séparateurs changent.
- Pourquoi les numéros de téléphone sont-ils coupés dans les messages en arabe ?
- Parce qu'un numéro qui commence par « + », inséré dans une phrase écrite de droite à gauche, voit son début et ses groupes de chiffres changer de place : le texte ne sait pas où le numéro commence. La solution est d'envelopper chaque valeur insérée, numéro, nom, adresse, dans des marques de direction avant de la placer dans la phrase, systématiquement, dans le code qui rend les textes.
- Comment gère-t-on la darija ?
- Comme une troisième langue, pour les messages seulement : les gabarits WhatsApp et SMS ont une version en darija écrite en lettres latines, parce que c'est ainsi que vos clients l'écrivent, avec les mêmes variables et la même isolation que les autres. L'interface reste en arabe et en français ; la recherche, elle, comprend les trois, comme le guide sur la recherche le décrit.
- Faut-il tout traduire deux fois à chaque changement ?
- Chaque phrase nouvelle est une clé ajoutée aux trois fichiers de langue, avec son contexte pour le traducteur, et elle part par l'API sans passer par les stores. Une version qui ajoute dix phrases ajoute dix clés ; le traducteur les voit avec une capture de l'écran où elles vont, et un lecteur d'arabe relit l'écran avant la démonstration. C'est le même rythme que le reste de la livraison.
- Combien de temps pour une application dans les deux langues ?
- Six semaines quand les deux langues sont décidées au départ : une pour les langues et les règles, une pour les textes en clés, une pour la mise en page dans les deux sens, une pour les données et la saisie, une pour la relecture, une pour les documents et les messages. Ajouter l'arabe à une application construite en français seulement coûte plus que ces six semaines, parce qu'il faut réécrire la mise en page.