API de signature électronique en arabe : ce qu’il faut vérifier

Interface de droite à gauche, texte mixte, PDF arabes, e-mails, dates et preuves : la liste de contrôle d’une API de signature électronique en arabe.

Publié le 3 oct. 2026 · 8 min de lecture

Une API de signature électronique « en arabe » ne se résume pas à des libellés traduits. Pour un éditeur de logiciel qui sert des utilisateurs dans le Golfe ou au Maroc, il faut vérifier que le parcours du signataire est entièrement de droite à gauche, que les noms et montants mélangés à du texte latin s’affichent correctement, que les PDF arabes restent intacts et que chaque signataire reçoit son lien dans sa langue.

Ce guide liste les points à tester avant de choisir une solution, puis montre comment Khatm les traite : parcours natif en arabe, en français et en anglais, API REST v1 testable en sandbox, et passage en production préparé avec vous.

La liste de contrôle en un coup d’œil

Le moyen le plus fiable de vérifier ces points est d’envoyer un vrai document de votre produit, par exemple un contrat de travail rédigé en arabe dans votre SIRH ou un devis bilingue généré par votre CRM, à un signataire de test, puis de relire chaque écran et le PDF final.

Une interface de signature réellement de droite à gauche

En arabe, toute la page se lit de droite à gauche. La traduction des chaînes ne suffit pas : la structure de l’interface doit être inversée. Un signataire saoudien ou marocain remarque immédiatement une page dont le texte est arabe mais dont la logique visuelle reste occidentale.

• La page déclare la direction de droite à gauche (attribut dir="rtl") et la langue arabe, pour le navigateur comme pour les lecteurs d’écran.
• Les flèches « suivant » et « précédent », les barres de progression et les menus sont inversés.
• Les champs de saisie, les cases à cocher et les messages d’erreur sont alignés du bon côté.
• La police d’interface couvre l’arabe avec une taille lisible sur mobile, où la plupart des signatures ont lieu.
• Les éléments qui ne doivent pas s’inverser, comme le document PDF lui-même ou un logo, restent intacts.

Texte mixte arabe et latin

Dans un parcours de signature réel, l’arabe côtoie toujours du texte latin : une adresse e-mail, un numéro de contrat, un nom d’entreprise en anglais, un montant suivi de « SAR » ou « MAD ». L’algorithme bidirectionnel d’Unicode gère ces mélanges, mais seulement si l’interface isole correctement chaque fragment.

• Un nom arabe suivi d’un e-mail latin reste dans le bon ordre, sans parenthèse ni point qui saute à l’autre bout de la ligne.
• Les références comme « HR-2026-0042 » s’affichent telles qu’elles ont été saisies.
• Les montants gardent la devise du bon côté et les séparateurs attendus.
• Les noms de signataires saisis en arabe par votre produit sont conservés tels quels dans l’interface, les e-mails et les preuves.

Pour tester, préparez un jeu de données volontairement difficile : un nom arabe, un nom français, un e-mail, une référence avec tirets et un montant. Si ces cinq valeurs passent sur chaque écran, vous avez couvert l’essentiel des cas.

PDF en arabe : polices et placement des champs

C’est votre logiciel qui produit le PDF. Il revient donc à votre générateur de documents d’intégrer des polices arabes complètes et de gérer la forme contextuelle des lettres et les ligatures, comme lam-alif. Un PDF bien généré s’affiche de la même manière dans tous les lecteurs ; un PDF qui dépend d’une police absente du poste du signataire peut montrer des lettres isolées ou des carrés.

Le service de signature, lui, doit signer ce PDF sans le réécrire. Avec une signature PAdES, la moindre modification du contenu après signature invalide la signature : c’est une garantie, à condition que le service ne touche pas à votre mise en page. Comprendre un PDF signé en PAdES

Le placement des champs mérite aussi attention. Dans un contrat arabe, le bloc de signature et la mention de date ne sont pas toujours au même endroit que dans la version française. Vérifiez que vous pouvez placer les champs par coordonnées ou par modèle, et relisez toute suggestion automatique avant de la confirmer.

E-mails, liens et langue de chaque signataire

Une même demande réunit souvent des signataires de langues différentes : un salarié qui signe en arabe, un responsable RH qui préfère le français, un associé étranger en anglais. La langue doit donc se régler par signataire, pas pour toute la demande.

• La page de signature s’ouvre dans la langue choisie pour ce signataire, sans dépendre du hasard du navigateur.
• L’objet et le corps du message d’invitation sont dans cette même langue, avec une mise en page de droite à gauche pour l’arabe.
• Les relances suivent la même règle que l’invitation.
• Les e-mails portent votre marque : nom d’expéditeur, message personnalisé et logo, et précisent qu’ils sont envoyés de votre part.
• Si votre produit envoie lui-même les notifications, l’API vous rend le lien de signature pour que vous l’intégriez dans vos propres modèles.

Dates, chiffres et formats

Les conventions varient d’un pays à l’autre. Au Maroc, les chiffres occidentaux (0 à 9) sont la norme ; dans le Golfe, les chiffres arabes orientaux (٠ à ٩) restent courants dans certains contextes. Le calendrier hégirien est utilisé dans des documents administratifs en Arabie saoudite. Avant de choisir un service, vérifiez donc :

• le format des dates affichées au signataire et inscrites dans le PDF et dans les preuves ;
• le fuseau horaire utilisé pour l’horodatage des événements ;
• les chiffres utilisés dans l’interface arabe ;
• la façon dont vos propres documents présentent les dates hégiriennes, si votre activité en a besoin, puisque ces dates relèvent du contenu de votre PDF.

Des preuves lisibles par vos équipes

Le jour où un contrat est contesté, ce sont vos équipes juridiques ou support, souvent arabophones, qui ouvrent le dossier. Vérifiez que le rapport de preuves se lit dans leur langue, que les noms arabes y apparaissent correctement et que les données structurées sont exploitables par vos outils.

Comment cela fonctionne avec Khatm

Khatm intègre la signature PDF à votre logiciel, sous votre marque, en arabe, en français et en anglais. Le parcours du signataire est conçu nativement dans ces trois langues, avec une interface de droite à gauche pour l’arabe. Le même moteur est accessible par la plateforme web, sans développement, et par l’API REST v1.

Avec l’API, vous créez une demande en envoyant le PDF et un objet JSON. Le champ client_reference rend la création idempotente ; chaque signataire porte une référence, un nom, un e-mail, un ordre et, en option, une langue (fr, en ou ar) qui règle sa page de signature et ses e-mails. L’objet email facultatif applique votre marque aux invitations et aux relances : sender_name, message et logo_url.

REQUEST_JSON='{
  "client_reference": "hr-contract-2026-0042",
  "signers": [
    {
      "reference": "employee",
      "name": "سارة العتيبي",
      "email": "sara@example.com",
      "order": 1,
      "locale": "ar"
    }
  ],
  "email": {
    "sender_name": "Acme HR",
    "message": "يرجى توقيع عقد العمل قبل يوم الخميس.",
    "logo_url": "https://example.com/logo.png"
  }
}'

curl --fail-with-body -sS \
  -H "Authorization: Bearer $KHATM_API_KEY" \
  -F "document=@contrat-ar.pdf;type=application/pdf" \
  -F "request=$REQUEST_JSON" \
  "$KHATM_BASE_URL/v1/signature-requests"

1. Placez les champs dans la requête, depuis un modèle, ou demandez des suggestions avec detect-fields puis confirmez-les.
2. Activez la demande. Avec send_emails, Khatm envoie à chaque signataire une invitation dans sa langue, à votre marque ; link_expiry_days règle la validité du lien (1 à 30 jours, 7 par défaut). Vous pouvez aussi récupérer le lien de signature et l’envoyer dans vos propres e-mails.
3. Recevez les webhooks signés en HMAC-SHA256 : signature_request.completed, signature_request.declined ou signature_request.cancelled.
4. Téléchargez le PDF signé, le rapport de preuves PDF et les preuves JSON.

Une demande accepte jusqu’à 10 signataires et 100 champs, pour un PDF de 8 Mio au maximum. Les PDF sont chiffrés au repos et chaque document est identifié par une empreinte SHA-256. Documentation de l’API Page développeurs

De la sandbox à la production

La sandbox est en libre-service : créez un compte, générez une clé khatm_test_… et un secret de webhook whsec_…, puis envoyez vos vrais modèles arabes à des signataires de test. Les PDF sont signés avec un certificat de test autosigné, et le contenu est supprimé 10 jours après le téléversement du PDF.

La production se prépare avec Khatm : adaptation du parcours et de votre marque, intégration avec vos développeurs, connexion de l’identité des signataires via votre fournisseur d’identité, certificat de votre PKI, de votre HSM ou de votre prestataire de confiance, et horodatage RFC 3161 lorsque ce prestataire le fournit. Khatm n’émet pas de certificats et n’est pas un prestataire de confiance qualifié. Les identités nationales comme Nafath ou UAE Pass ne sont pas incluses par défaut. Préparer la production

Pour commencer, testez la démo sans compte, puis obtenez une clé sandbox et lisez la documentation. Quand le parcours arabe vous convient, nous vous accompagnons jusqu’à la production. Tester la démo Obtenir une clé sandbox

Informations générales, sans valeur de conseil juridique. Vérifiez les exigences applicables à votre opération.