Réponse courte. Un document n'est pas une vue qu'on imprime, c'est un objet émis : un événement le déclenche, un numéro lui est posé une fois dans une séquence sans trou par agence et par an, ses données sont figées à cet instant, un gabarit versionné le rend, et le fichier produit est archivé avec son empreinte ; une réimpression ressort le même fichier, marqué duplicata. Trois moteurs de rendu pour une seule source : le PDF/A avec polices embarquées pour ce qui doit être lisible dans dix ans, le flux de commandes thermique pour les tickets de 80 ou 58 millimètres où le texte latin part en texte et l'arabe en image, et le langage des étiqueteuses pour les étiquettes à code-barres. Le ticket attend dans une file locale et sort même sans réseau ; la facture part par WhatsApp et e-mail et dort dans un stockage versionné. Six semaines, dont la première sans un seul document généré.
Ce guide s'adresse au commerçant dont la caisse doit imprimer en deux secondes, au gérant dont le comptable réclame des numéros qui se suivent, et au fondateur installé en France qui reçoit la facture par WhatsApp et doit pouvoir la rouvrir dans cinq ans. Il ne redit pas comment la caisse encaisse, décrit dans le guide sur la caisse, ni comment l'interface parle les deux langues, décrit dans le guide sur l'application bilingue ; il décrit ce qui se construit entre la donnée et le papier, et il prolonge notre page sur l'ingénierie logicielle.
Ce que les référentiels disent
Un PDF qui doit être lu dans dix ans a une norme, et elle est précise. Le PDF/A, défini par la norme ISO 19005, est la version du format « spécialisée pour l'archivage et la conservation à long terme des documents électroniques » : « toutes les polices doivent être embarquées », « le chiffrement est interdit », « les références à des contenus externes sont interdites », les scripts aussi, et des métadonnées normalisées sont requises. Il existe en plusieurs parties, PDF/A-1 à PDF/A-4, et en niveaux de conformité, dont le niveau b pour la reproduction visuelle fidèle et le niveau u qui ajoute que tout texte a une correspondance Unicode. Ce que cela impose : une facture émise en PDF/A-2b ou 2u avec ses polices à deux écritures embarquées s'ouvrira telle quelle dans dix ans, sur une machine qui n'a jamais eu ces polices ; une facture en PDF ordinaire qui pointe vers une police du serveur affichera des carrés.
Les imprimantes de caisse parlent un langage de commandes textuel, pas un langage de pages. Le jeu de commandes ESC/POS d'Epson est décrit comme « une variante pour contrôler les imprimantes de tickets couramment utilisées au point de vente », et « beaucoup d'imprimantes thermiques actuelles continuent de l'utiliser » ; toutes les imprimantes de tickets Epson le supportent. Ce que cela impose, et que nous disons comme une observation sur les machines que nous rencontrons dans les magasins : la plupart comprennent ce jeu de commandes, mais presque aucune n'a de police arabe ni de façonnage des lettres arabes ; le texte latin part donc en texte, en quarante-huit caractères par ligne sur du 80 millimètres, et les lignes arabes partent en image, rendues par l'application avec sa propre police.
Ce que nous n'avons pas trouvé : une statistique publique sur les imprimantes de caisse installées en Algérie, ni sur la part des factures échangées en PDF ; ce que nous voyons, ce sont des imprimantes thermiques de 80 millimètres en Bluetooth ou en USB, des étiqueteuses de 50 par 30 millimètres dans les entrepôts, et des factures PDF envoyées par WhatsApp dans la majorité des cas, et nous le disons comme une observation. Les règles de contenu et de numérotation des factures dépendent de votre comptable ; ce guide décrit la mécanique qui les tient, pas les règles elles-mêmes.
Les documents d'une application, en cinq couches
Avant la facture, les cinq couches, et celle qui évite les deux pannes les plus fréquentes.
Les données du document : un instantané figé au moment de l'émission, lignes, prix, adresses, taux, et le numéro posé dans une séquence sans trou ; le document est une photographie, pas une vue sur des données qui bougent, et un prix modifié demain ne change pas la facture d'hier. Les gabarits : un par document, bilingue ou par langue, versionné dans le dépôt avec des polices qui couvrent les deux écritures ; chaque document dit quelle version l'a produit, et c'est cette couche qui évite le PDF différent à chaque clic et la version arabe en carrés. Le rendu : trois moteurs pour une source, le PDF/A pour ce qui se conserve, le flux de commandes pour les tickets, le langage d'étiquettes pour les étiqueteuses.
La sortie : impression locale par file d'attente, envoi WhatsApp et e-mail par les canaux décrits dans le guide sur les notifications, téléchargement, et archive versionnée avec empreinte ; le fichier envoyé est le fichier archivé, et une réimpression ne régénère rien. La supervision : la file d'impression et ses erreurs, les imprimantes présentes par site, les réimpressions et par qui, les lots de fin de mois, les écarts de numérotation ; le comptable lit les numéros, le gérant lit les réimpressions, selon les droits décrits dans le guide sur les rôles.
Une facture, de la commande validée au PDF archivé
La facture ne se comprend pas sur un gabarit mais sur son parcours, en sept stations.
La commande est validée : un événement, paiement confirmé selon le guide sur le paiement ou livraison, déclenche la facture ; jamais un clic « imprimer », parce qu'un clic peut être fait deux fois. Le numéro est attribué : SET-2027-000418, une séquence par agence et par an, sans trou, posé une fois et jamais réutilisé ; c'est la ligne que le comptable vérifie en premier. L'instantané est figé : lignes, prix, adresses, taux à cet instant, copiés dans le document et plus jamais relus depuis le catalogue. Le gabarit v3 bilingue la rend, avec ses polices à deux écritures, et la facture porte le numéro de version du gabarit.
Le PDF/A est produit avec les polices embarquées, et son empreinte est calculée avant tout envoi ; dix ans plus tard, le même fichier s'ouvre et la même empreinte prouve qu'il n'a pas changé. Il est envoyé et archivé : WhatsApp et e-mail au client, stockage versionné et verrouillé selon le guide sur les sauvegardes ; la facture envoyée et la facture archivée sont le même fichier. La réimpression ressort ce fichier avec un filigrane « duplicata », et le journal dit qui l'a demandée et quand ; elle n'est jamais régénérée, parce qu'une facture régénérée depuis des données qui ont bougé n'est plus la même facture. Les numéros et montants sont un exemple construit.
«Une facture n'est pas imprimée, elle est émise : un événement la déclenche, un numéro lui est posé une fois, ses données sont figées, et le fichier envoyé est le fichier archivé.»
Six documents, et la sortie que chacun demande
Six documents que nous construisons sur presque tous les projets, et pour chacun ce qu'il doit être et comment il sort.
La facture : bilingue, numérotée sans trou, figée, lisible dans dix ans ; PDF/A avec empreinte, envoyée par WhatsApp et e-mail, archivée, réimprimée en duplicata. Le ticket de caisse : il sort en deux secondes, avec ou sans réseau, sur l'imprimante de la caisse ; flux de commandes thermique, arabe en image, file locale, QR vers la facture, tiroir si espèces. Le bon de livraison : signé par le client à la porte avec la photo du colis ; PDF généré sur le téléphone du livreur, signature et photo embarquées, horodaté, synchronisé au retour du réseau selon le guide sur la synchronisation ; c'est la preuve de la plateforme de livraison.
L'étiquette : collée sur le colis ou le rayon, lue par un scanner, 50 par 30 millimètres ; langage de l'étiqueteuse, code-barres ou QR, texte court en deux écritures, lot d'étiquettes par préparation. Le devis : daté, avec une validité et des versions ; un PDF par version, v1 v2 v3 conservées, acceptation enregistrée, et le devis accepté devient la base de la facture. Le relevé mensuel : un document par client, généré en lot la nuit du premier du mois, PDF/A par client, envoi groupé, erreurs de lot lues à la supervision du matin ; c'est le document que le portail B2B envoie à chaque détaillant.
Le ticket, de la caisse à l'imprimante
Le ticket est le document le plus simple et celui qui bloque le plus de caisses ; six étapes le font sortir.
La vente est validée : le ticket est créé en base avec son numéro, même sans réseau, parce que la caisse travaille hors ligne. Il est rendu en commandes : texte latin en texte, lignes arabes en image, code QR, ordre de coupe. Il entre dans la file locale : une file sur la caisse elle-même, pas sur le serveur ; l'imprimante le prend quand elle est prête, un papier coincé ne perd pas la vente, et le ticket suivant attend derrière. Il part vers l'imprimante : Bluetooth, USB ou réseau, et l'état de l'imprimante est lu avant d'envoyer, papier, capot, erreur.
Coupe et tiroir : la coupe vient après le QR, jamais avant la dernière ligne, et le tiroir ne s'ouvre que si le paiement est en espèces, parce qu'un tiroir qui s'ouvre à chaque ticket est un tiroir qu'on ne surveille plus. Le statut est écrit : imprimé, échoué, réimprimé et par qui ; visible à la supervision, pour que le gérant sache combien de tickets ont été réimprimés ce mois-ci et pourquoi. Le choix entre une application native et une application web pour parler à l'imprimante en Bluetooth est décrit dans le guide dédié : l'imprimante est l'un des critères qui imposent le natif.
Le ticket de 80 millimètres, tel que l'imprimante le reçoit
Ce que l'imprimante reçoit n'est pas une page : c'est une suite de commandes et d'images, et chacune a une raison.
Initialiser l'imprimante à chaque ticket, pour partir d'un état connu quel que soit le ticket précédent. Centrer, mettre en gras, doubler la taille pour le nom du magasin et le total : le texte latin part en texte, parce que l'imprimante a la police et tient quarante-huit colonnes sur 80 millimètres, trente-deux sur 58. Envoyer les lignes arabes en image : la plupart des imprimantes n'ont ni police arabe ni façonnage des lettres, et une ligne arabe envoyée en texte sort en caractères inconnus ou en lettres séparées ; l'application la rend donc avec sa propre police, à la bonne largeur, et l'envoie en image monochrome.
Le code QR renvoie vers la facture PDF et le programme de fidélité ; le client le scanne, et le ticket devient une porte vers le document complet. La coupe partielle vient après le QR, jamais avant la dernière ligne, parce qu'une coupe trop tôt sépare le total du reste. L'ouverture du tiroir n'est envoyée que si le paiement est en espèces, et elle est journalisée. Le même flux de commandes, rejoué depuis la file locale, produit le même ticket à l'identique, même sans réseau ; c'est ce qui permet la réimpression sans régénération.
«Le texte latin part en texte, l'arabe part en image, et le même ticket se réimprime à l'identique depuis la file locale, même sans réseau.»
Vu ailleurs : la norme d’archivage et le jeu de commandes des imprimantes, et ce qui se transpose
Deux sources disent l'essentiel. La norme PDF/A dit qu'un document archivable embarque ses polices, n'a ni chiffrement ni référence externe ni script, et porte des métadonnées normalisées ; ce qui se transpose, c'est que la facture est produite en PDF/A avec les deux écritures embarquées, et que son empreinte est calculée avant l'envoi. Le jeu de commandes d'Epson dit comment on parle à une imprimante de tickets, en texte, en images et en ordres de coupe ; ce qui se transpose, c'est que le ticket est une suite de commandes rejouable depuis une file locale, et que l'arabe part en image parce que l'imprimante ne sait pas l'écrire.
Ce que ces sources ne disent pas : quels documents votre entreprise émet, qui les lit, dans quelle langue, et comment votre comptable veut qu'ils soient numérotés ; la première semaine du projet y répond, et c'est le comptable qui signe la liste avec le gérant.
Les règles d'un document qu'on peut émettre sans crainte
Six règles, écrites la première semaine. Un document est émis par un événement, jamais par un clic. Le numéro est posé une fois, dans une séquence sans trou par agence et par an. Les données sont figées à l'émission ; le document ne relit jamais le catalogue. Le gabarit est versionné avec ses polices à deux écritures, et le document dit quelle version l'a produit. Le fichier envoyé est le fichier archivé, avec son empreinte ; une réimpression est un duplicata marqué. Le ticket sort sans réseau, depuis une file locale, sur l'imprimante qui est là.
Une septième règle porte sur le devis : « génération de factures PDF et impression des tickets » n'est pas une exigence, c'est une phrase ; l'exigence s'écrit « liste des documents avec lecteur et langue ; émission par événement ; séquences de numérotation par agence et par an sans trou ; instantané figé ; gabarits versionnés bilingues avec polices embarquées ; PDF/A avec empreinte pour les documents conservés ; archive versionnée et verrouillée ; réimpression en duplicata journalisée ; tickets en flux de commandes thermique avec arabe en image, file locale, test sur chaque imprimante présente ; étiquettes dans le langage de l'étiqueteuse ; lots de fin de mois supervisés », et elle se vérifie comme le guide sur le cahier des charges le recommande. Un devis qui écrit « export PDF » a prévu un bouton, pas un document.
Six entreprises, et le document qui comptait
Six entreprises que nous équipons souvent, et pour chacune le document qui a décidé de l'architecture.
- Le commerce de détail, décrit dans le guide sur la caisse. Le ticket de 80 millimètres en deux secondes, avec ou sans réseau, sur les trois imprimantes différentes des trois magasins ; la file locale a réglé ce que le serveur ne pouvait pas.
- Le grossiste et son portail, décrit dans le guide dédié. Le relevé mensuel par détaillant, généré en lot la nuit du premier, bilingue, envoyé par WhatsApp ; trois cents PDF/A chaque mois sans une main.
- La plateforme de livraison, décrite dans le guide dédié. Le bon de livraison signé sur le téléphone du livreur avec la photo du colis, généré hors ligne et synchronisé au dépôt ; la preuve que le client réclame.
- Les commerciaux terrain, décrits dans le guide dédié. Le bon de commande imprimé chez le client sur une imprimante Bluetooth de 58 millimètres, trente-deux colonnes, arabe en image.
- Le promoteur immobilier, décrit dans le guide dédié. Les reçus d'acompte des acquéreurs en PDF/A bilingue, numérotés, archivés dix ans et verrouillés ; le document qu'un acquéreur en France rouvrira en 2036.
- L'entreprise qui migre, décrite dans le guide sur la migration. La liste des documents imprimés chaque jour par l'ancien logiciel est le premier inventaire de la première semaine ; le nouveau les produit tous avant la bascule, et le comptable compare les numéros.
Le calendrier 2027
Le calendrier est celui des documents d'une application livrés en six semaines, dont la première sans un seul document généré.
La semaine 0 à 1 fait l'inventaire et écrit la numérotation : la liste des documents, qui les lit, dans quelle langue ; les séquences par agence et par an ; les gabarits signés par le gérant et le comptable, parce que ces décisions ne se changent plus une fois la première facture émise. La semaine 1 à 2 construit le moteur PDF et la facture : instantané figé, gabarit bilingue versionné, polices embarquées, PDF/A, empreinte, et la première facture relue par le comptable. La semaine 2 à 3 traite les tickets : rendu en commandes, arabe en image, file locale, et un test sur chaque imprimante réellement présente dans les magasins, pas sur celle du bureau.
La semaine 3 à 4 traite les bons, les étiquettes et les devis : signature et photo sur le téléphone, étiqueteuses, versions. La semaine 4 à 5 installe l'archive versionnée, la réimpression marquée, l'envoi par WhatsApp et e-mail, et le lot de fin de mois. La semaine 5 à 6 est la recette sur place : chaque imprimante, chaque document, les deux langues, et le comptable qui valide les numéros ; c'est la recette que le guide sur la livraison décrit, faite devant les machines. Quand l'application doit aussi envoyer ses documents à la comptabilité, le guide sur l'intégration prend la suite.
Ce qui fait échouer les documents d’une application
Les documents que nous reprenons ont presque toujours échoué pour l'une de ces raisons.
- Le PDF regénéré à chaque clic. Le prix a changé entre-temps ; la facture du client et celle du comptable ne disent plus la même chose.
- Le numéro posé à l'impression. Deux clics, deux numéros ; un clic annulé, un trou.
- La police non embarquée. Des carrés à la place de l'arabe sur la machine du client.
- L'arabe envoyé en texte à l'imprimante. Des caractères inconnus ou des lettres séparées sur le ticket.
- Le ticket qui attend le serveur. Le réseau tombe, la caisse bloque, la file au comptoir grandit.
- Testé sur l'imprimante du bureau. Les trois magasins ont trois modèles, et deux ne coupent pas au même endroit.
- La réimpression invisible. Le même ticket imprimé cinq fois, et personne ne sait pourquoi.
Questions fréquentes
Les questions que nous recevons de commerçants, de gérants et de comptables.
- Pourquoi le ticket ne sort-il pas sur notre imprimante de caisse ?
- Le plus souvent parce que l'application parle à l'imprimante comme à une page, ou pas du tout : une imprimante de tickets attend une suite de commandes, texte, images, coupe, par Bluetooth, USB ou réseau, et elle n'a pas de police arabe. On construit le rendu en commandes, l'arabe en image, une file locale sur la caisse, et on teste sur chaque modèle réellement présent dans les magasins, pas sur celui du bureau.
- Pourquoi la facture PDF affiche-t-elle des carrés à la place de l’arabe ?
- Parce que la police arabe n'était pas embarquée dans le fichier : le PDF pointait vers une police du serveur, et la machine du client ne l'a pas. Une facture produite en PDF/A embarque toutes ses polices, les deux écritures comprises, et s'ouvre telle quelle dans dix ans sur n'importe quelle machine ; c'est la norme d'archivage, et c'est ce que nous produisons par défaut.
- Comment garantir une numérotation sans trou ?
- Le numéro est posé par le serveur au moment où l'événement émet le document, dans une séquence par agence et par an, une seule fois ; il n'est jamais attribué par un clic « imprimer », qui peut être fait deux fois ou annulé. Une annulation produit un document d'annulation numéroté, pas un trou. Le comptable voit la séquence et ses écarts dans la supervision.
- Que se passe-t-il quand on réimprime une facture ?
- Le même fichier archivé ressort, avec un filigrane « duplicata », et le journal dit qui l'a demandé et quand. Il n'est jamais régénéré depuis les données, parce que les prix ou l'adresse ont pu changer depuis : la facture est une photographie prise au moment de l'émission, et son empreinte prouve que le fichier n'a pas bougé.
- Le ticket sort-il si le réseau est coupé ?
- Oui. La vente est enregistrée sur la caisse, le ticket est rendu en commandes et entre dans une file locale sur la caisse elle-même, l'imprimante le prend quand elle est prête, par Bluetooth ou USB ; rien ne passe par le serveur. La synchronisation se fait au retour du réseau, et le numéro de ticket reste unique parce que la caisse a sa propre séquence.
- Combien de temps pour mettre en place les documents ?
- Six semaines : une pour l'inventaire et la numérotation avec le comptable, une pour le moteur PDF et la facture, une pour les tickets sur les imprimantes réelles, une pour les bons, étiquettes et devis, une pour l'archive, la réimpression et l'envoi, une pour la recette sur place. La première semaine se passe sans un document généré, parce que ses décisions ne se changent plus ensuite.