Comment j'ai fait respecter la Loi 96 par Business Central : l'extension AL

Si vous vendez à des clients au Québec, vos factures doivent être en français. Depuis que la Loi 96 (la réforme de 2022 de la Charte de la langue française) est pleinement en vigueur, le 1er juin 2025, les règles sont plus strictes et l'Office est plus occupé que jamais.

Business Central a déjà ce qu'il faut pour produire des documents en français. Ce qu'il n'a pas, c'est quelque chose qui vérifie. Rien n'empêche quelqu'un de reporter une facture en anglais à un client de Montréal.

J'ai donc construit une extension qui le fait. Cet article couvre ce qu'elle fait et comment elle est montée : la conception, les événements sur lesquels elle se branche, et les deux pièges où je suis tombé. Si vous avez un développeur AL, ça devrait suffire pour le lancer.

Il s'agit d'aider à la conformité, pas d'un avis juridique. Pour vos obligations réelles, voyez l'Office québécois de la langue française.

Ce que la loi demande à votre ERP

La Charte couvre beaucoup de choses : l'affichage, les sites web, la langue du travail. Trois articles tombent directement dans vos documents de vente :

Article de la Charte	Ce qu'il couvre	Où ça paraît dans Business Central
art. 57	Bons de commande, factures, reçus	La langue des soumissions, commandes, factures et notes de crédit
art. 51	Inscriptions sur les produits, y compris les documents qui les accompagnent	Les descriptions d'articles sur les lignes
art. 55	Contrats d'adhésion (conditions standard)	Les modalités de paiement et les méthodes de livraison

Les autres langues sont permises. Une facture bilingue est correcte, tant que le français n'est pas moins en évidence.

Est-ce vraiment appliqué?

Oui, mais pas comme le disent les articles alarmistes. L'OQLF a reçu un record de 11 125 plaintes entre avril 2025 et mars 2026, et les inspections sont en hausse d'environ 40 % (CTV News). Pourtant, la liste des condamnations de 2025 de l'OQLF n'en compte que six, avec des amendes de 700 $ à 3 000 $.

Le vrai processus : plainte, inspection, mise en demeure, vous corrigez. Les vrais risques, c'est la plainte elle-même (ça prend une minute à déposer), les recours des clients eux-mêmes avec la Loi 96, la perte d'accès aux contrats publics, et la mauvaise presse. Le but n'est donc pas d'éviter des amendes. C'est de faire du français la valeur par défaut.

Les trous du Business Central standard

Avec la localisation canadienne, vous avez déjà le code de langue FRC (français, Canada), les traductions d'articles, les traductions des unités de mesure, des modalités de paiement et des méthodes de livraison, et l'application gratuite French language (Canada) pour les libellés des rapports. Rien ne les relie :

1. Un client du Québec sans code de langue reçoit des factures en anglais.
2. Un article sans traduction française s'imprime en anglais.
3. Un article traduit après la création de la ligne garde sa description anglaise sur cette ligne.
4. Sans l'application de langue française, les données sont en français mais la facture dit encore « Invoice » et « Total ».

Ce que j'ai construit

Vérifier la conformité linguistique, sur n'importe quel document de vente, liste tout ce qui n'est pas en français, avec une correction suggérée pour chaque problème.

Deux erreurs et deux avertissements sur une commande pour un client de Montréal.

Corriger répare ce qu'il peut en un clic : il fixe la langue du document et copie les descriptions françaises sur les lignes.

De quatre problèmes à Conforme : corriger la langue, ajouter la traduction manquante, c'est fait.

À la libération et au report, un document qui a des problèmes est arrêté. L'utilisateur peut voir les problèmes, ou passer outre en donnant une raison. Chaque dérogation est journalisée, et le résultat (Conforme ou Dérogation) est gardé sur la facture reportée.

La libération est arrêtée, les problèmes à un clic.

Une feuille Écarts de conformité passe toute la compagnie en revue avant que quoi que ce soit se rende sur une facture : clients du Québec pas en français, articles sans description française, conditions non traduites, et l'application de langue manquante.

Dans la compagnie de démo : 109 articles sans description française.

Et l'extension elle-même est en français du Québec, avec le vocabulaire fr-CA de Business Central.

Comment je l'ai construite

Environ 45 objets AL : tables, pages, codeunits et extensions des pages de vente standard. Voici la recette.

1. Définir ce qu'est « un document du Québec »

Un document est visé quand l'adresse de facturation ou de livraison est au Canada et que son champ County (province) dit Québec. Les vraies données sont désordonnées, alors je garde une petite table d'alias (QC, PQ, QUEBEC, QUÉBEC) et je compare les valeurs sans espaces et en majuscules. Rendez-le configurable ; les données de chaque compagnie sont différentes.

2. Écrire la vérification comme une fonction qui n'écrit rien

Un codeunit prend un en-tête de vente (Sales Header) et remplit une table temporaire de problèmes, chacun avec une source, une gravité et une correction suggérée :

• La langue du document n'est pas FRC : erreur
• La langue du client n'est pas FRC : avertissement, puisque les prochains documents seront aussi en anglais
• Article sans Item Translation FRC (on essaie la variante d'abord, puis l'article) : erreur
• La description de la ligne ne correspond pas à la traduction : avertissement. C'est le plus sournois. BC copie la description à la création de la ligne et ne la regarde plus jamais.
• Unité de mesure, modalité de paiement ou méthode de livraison sans traduction FRC : avertissement
• Lignes de compte général, de ressource et de commentaire : info seulement, puisqu'il n'y a rien à comparer

Comme elle n'écrit rien, la même fonction sert à la vérification manuelle, au FactBox, à la libération, au report et aux tests.

3. Se brancher sur la libération et le report

Deux abonnés aux événements suffisent :

• Release Sales Document : OnBeforeReleaseSalesDoc
• Sales-Post : OnBeforePostSalesDoc

Ignorez PreviewMode, ignorez les enregistrements temporaires, et rappelez-vous que reporter une commande ouverte la libère aussi : la vérification roule deux fois. C'est correct tant qu'elle est rapide et donne la même réponse les deux fois.

4. Pas de dialogue en plein report (piège 1)

Ma première version demandait « continuer quand même? » avec une page. Business Central a refusé : RunModal n'est pas permis dans une transaction d'écriture, et la libération et le report en sont.

La solution : un ErrorInfo avec des actions. L'erreur annule tout, et les actions roulent ensuite, dans un contexte propre où ouvrir des pages est permis :

BlockedError.Message := StrSubstNo(BlockedSingleMsg, SalesHeader."Document Type", SalesHeader."No.", FirstIssue);
BlockedError.RecordId := SalesHeader.RecordId();
BlockedError.AddAction(ShowIssuesActionTxt, Codeunit::"BQC Enforcement", 'ShowIssues', ShowIssuesActionDescTxt);
if CanOverride() then
    BlockedError.AddAction(OverrideActionTxt, Codeunit::"BQC Enforcement", 'OverrideIssues', OverrideActionDescTxt);
Error(BlockedError);

5. Ne pas modifier l'enregistrement affiché à l'écran (piège 2)

Ma première dérogation écrivait « Dérogation » sur l'en-tête de vente. La base de données était juste, mais la page de la commande gardait son ancienne copie, et la libération suivante ne voyait pas la dérogation. Laissé tel quel, BC finit par dire que « l'information sur la page n'est pas à jour ».

La solution : ne jamais écrire dans l'en-tête dans le dos de la page. Les dérogations vont dans leur propre table de journal avec une empreinte SHA-256 des problèmes exacts, et la libération et le report vont les chercher là. Si quelqu'un modifie la commande après la dérogation et qu'un nouveau problème apparaît, l'empreinte ne correspond plus et le document est arrêté de nouveau.

6. Garder la preuve sans effort

Donnez aux champs de statut les mêmes numéros de champ sur Sales Header, Sales Invoice Header et Sales Cr.Memo Header. Le report utilise TransferFields : le statut suit jusqu'à la facture reportée sans code de plus.

7. Tester, même sur un Mac

J'ai construit ça sur un MacBook. Les conteneurs BC ne roulent pas sur Mac, et mon environnement d'essai était en Production, qui refuse F5 et même Download Symbols. Ce qui a marché :

• « AL: Download symbols from global sources », dans les versions récentes d'AL, va chercher les symboles de Microsoft dans leur flux public. Mettez "al.symbolsCountryRegion": "ca" et vous avez la Base Application canadienne sans aucun environnement.
• Le compilateur AL roule sur macOS, analyseurs compris.
• Un environnement sandbox pour publier avec F5, cliquer partout et prendre des captures d'écran.
• Une petite application de test (20 tests) pour la logique : détection du Québec, chaque vérification, libération et report, dérogations.

Les deux pièges plus haut, c'est le genre qu'un test avec un clic « OK » simulé attrape en quelques secondes. Écrivez ces tests.

La suite possible

La partie lente de la mise en conformité, c'est de traduire le catalogue, et c'est là qu'un modèle est bon. Prochaine étape envisagée : un assistant IA dans Business Central qui suggère des descriptions françaises pour tout ce que la feuille des écarts trouve.

Vous utilisez Business Central au Québec et voulez ça dans votre compagnie, adapté à vos documents et à vos données? Parlons-en.