Évaluation bilingue des flux de travaux d’IA de l’administration publique canadienne

Le problème tient à la conception de l’évaluation, pas à la traduction, et il a une forme bien précise.

La Loi sur les langues officielles (LLO) oblige les institutions fédérales à servir le public et à communiquer avec lui dans les deux langues officielles, là où l’obligation s’applique. Dans DesRochers c. Canada (Industrie), 2009 CSC 8, arrêt rendu le 5 février 2009, la Cour suprême du Canada a interprété ce devoir comme une exigence d’égalité réelle. La simple disponibilité ne suffit pas. Elle y souligne l’importance d’offrir des services de qualité égale dans les deux langues officielles. L’ensemble des politiques fédérales sur les langues officielles reprend cette formulation jusque dans les obligations ministérielles. La norme n’est pas qu’une sortie en français existe.

Un flux de travaux d’intelligence artificielle peut satisfaire à la première exigence et échouer à la seconde d’au moins quatre façons. Un score global d’exactitude unique les masquera toutes les quatre.

Asymétrie de la récupération. Si le corpus interrogé par le système est anglais à 90 %, une question posée en français permettra de récupérer moins de documents pertinents. Le système peut aussi récupérer des documents anglais et y puiser sa réponse. La réponse peut être juste. Le service, lui, demeure différent.

Dérive terminologique. Le français de l’administration publique n’est pas le français courant. Prestation, allocation et indemnité ne sont pas interchangeables. Un modèle qui les traite comme des synonymes produit un texte qu’un agent de programme reconnaît tout de suite comme fautif, ce que le public ne remarque pas.

Effondrement du registre. La rédaction administrative française obéit à des conventions de formalité que l’anglais n’a pas. Un modèle entraîné majoritairement sur des schémas anglais tend à produire un français qui se lit comme une traduction. La compréhension survit. La confiance, non.

Asymétrie des refus. Les comportements de sûreté peuvent être réglés surtout sur l’anglais. Une même question peut recevoir une réponse dans une langue et un refus dans l’autre, ce qui crée une différence de service qu’aucune mesure d’exactitude ne vous révélera jamais.

La décision la plus lourde de conséquences se prend avant même le choix d’un modèle. Le jeu d’évaluation est-il rédigé d’origine dans les deux langues, ou rédigé dans une seule puis traduit ?

Les jeux d’évaluation traduits sous-estiment systématiquement les défaillances en français. Une question traduite conserve une structure de phrase anglaise, et la récupération y est plus facile qu’avec une question formulée d’origine en français. Si vos cas d’essai français viennent de la traduction de cas anglais, votre taux de réussite en français est optimiste, et vous ignorez de combien.

La règle pratique. Rédigez d’origine en français une portion appréciable du jeu d’évaluation, à partir de demandes réelles en français que votre institution reçoit déjà. Ne les retraduisez pas en anglais par souci de parité. Les deux jeux ont le droit de différer, parce que la population qui s’adresse à vous en français ne pose pas les mêmes questions.

Présentez chacune de ces mesures séparément, par langue. Ne présentez jamais un chiffre agrégé.

Couverture de la récupération. Pour un ensemble de questions dans chaque langue, quelle proportion des documents qu’un expert humain jugerait pertinents le système a-t-il effectivement récupérés ? C’est le premier endroit où chercher l’asymétrie.

Exactitude factuelle au regard d’une vérité de terrain en français. Notée par un spécialiste du domaine bilingue, et non d’après une traduction de la grille d’évaluation anglaise.

Fidélité terminologique. La sortie emploie-t-elle la terminologie française approuvée par l’institution elle-même ? La vérification est objective au moyen des glossaires existants, ce qui rend cette défaillance rapide à repérer et peu coûteuse à corriger.

Registre et lisibilité. Évalués par un réviseur francophone au regard des communications déjà publiées par l’institution, et non d’après un indice de lisibilité générique.

Parité des refus et des renvois aux niveaux supérieurs. Soumettez les mêmes requêtes sensibles ou hors périmètre dans les deux langues. Tout écart quant au fait que le système réponde, refuse ou renvoie aux niveaux supérieurs constitue une inéquité de service. Il doit être traité comme un défaut, non comme une curiosité.

Délai d’obtention d’une réponse juste, mesuré de la question à la réponse, toute étape de révision humaine comprise. Si le cheminement français aboutit à un bassin de réviseurs plus restreint, le service est plus lent même lorsque le modèle se comporte de façon identique. C’est ce chiffre-là que le public éprouve.

La Directive sur la prise de décisions automatisée exige une évaluation de l’incidence algorithmique (EIA) avant la mise en production d’un système. Elle fait varier le pouvoir d’approbation selon le niveau d’incidence. Les orientations du Secrétariat sur l’Outil d’évaluation de l’incidence algorithmique prévoient la publication dans les deux langues officielles sur le Portail du gouvernement ouvert. Rien de ce que nous trouvons dans ces instruments ne vous demande de ventiler votre évaluation par langue officielle. Rien n’y interdit non plus de le faire. Une évaluation qui rapporte un seul chiffre d’exactitude agrégé pour un service bilingue destiné au public n’a pas évalué ce service.

Le Secrétariat du Conseil du Trésor du Canada (SCT) a publié un Guide sur l’utilisation de l’intelligence artificielle agentive, modifié pour la dernière fois le 22 mai 2026. Le guide demande : « Conservez les journaux des outils utilisés, des opérations exécutées, des autorisations accordées et des données d’entrée et de sortie clé ». La langue est un champ de journalisation. Si vos journaux ne consignent pas la langue d’une demande à son arrivée, vous ne pourrez pas produire de preuves ventilées plus tard. Il faudra les reconstituer à partir de rien, au pire moment possible.

Le cadre de gestion des risques liés à l’intelligence artificielle du National Institute of Standards and Technology organise ce travail sous les rubriques gouverner, cartographier, mesurer et gérer. L’évaluation bilingue relève sans ambiguïté de la mesure, et l’insistance du cadre pour que la mesure soit rattachée au contexte est précisément ce qui compte ici. Le contexte, en l’occurrence, est une obligation légale, et non une préférence.

Semaines un et deux. Recueillez des demandes réelles dans les deux langues à partir des canaux existants. Faites rédiger le jeu français d’origine par un expert bilingue. Visez un minimum de 100 cas par langue, pondérés en faveur des types de demandes qui dominent votre volume. Un flux de travaux unilingue se dimensionne de 100 à 300 cas selon la méthode d’évaluation. Un flux bilingue exige ce plancher en double. Un jeu français constitué comme une part d’un total calibré pour l’anglais est trop petit pour faire bouger un seuil.

Les six semaines ci-dessous constituent le volet évaluation, et non un mandat distinct. Dans le projet pilote d’agent de connaissance de six semaines, ce travail avance en parallèle de la construction plutôt qu’après elle. Voilà pourquoi les cas français doivent exister dès la première semaine.

Semaine trois. Constituez la vérité de terrain. Pour chaque cas, consignez la bonne réponse, les documents qu’un humain citerait et la terminologie approuvée. Cette pièce justificative survit à tout modèle que vous choisirez, ce qui en fait l’élément le plus durable que produise le projet pilote.

Semaine quatre. Établissez la base de référence. Présentez les six mesures par langue. Attendez-vous à un écart. L’écart est le constat, pas l’échec.

Semaine cinq. Attaquez-vous au plus grand écart seulement. S’il s’agit de la couverture de la récupération, le correctif porte sur le corpus plutôt que sur le modèle. Il faut retrouver les documents sources en français qui existent, mais qui n’ont jamais été indexés.

Semaine six. Reprenez les essais et consignez les résultats. Le livrable n’est pas un score. C’est un document qui indique ce qui a été mesuré, dans quelle langue, par qui, au regard de quelle norme, et ce qui reste en suspens.

Dites-le, par écrit, avant le lancement. Une décision documentée de lancer avec un écart de service connu et quantifié, assortie d’un plan de correction et d’une date, constitue une position de gouvernance défendable. Un écart non documenté découvert par un membre du public, non.

Bien s’en tirer dépend moins du modèle que de deux décisions. La première : traiter dès le départ le français comme une condition d’essai à part entière plutôt que comme une tâche de localisation. La seconde : consigner vos constats dans un cas comme dans l’autre.

Précédemment : une liste de vérification pratique pour une architecture d’IA Protégé B. Prochain article de la série : de la démonstration au service en exploitation.