Évaluer un outil d'IA avant
de l'adopter — biais, dérives, EFVP

Module 4 — Évaluer un outil d'IA avant son adoption

Une évaluation préalable n'est pas un exercice théorique — c'est ce qui rend visibles les risques avant qu'ils deviennent des incidents, et c'est l'obligation de l'article 3.3 de la Loi 25 pour tout traitement à risque de renseignements personnels.

Prérequis : avoir parcouru les Modules 1, 2 et 3 — vocabulaire, choix de l'architecture, politique d'usage. L'évaluation préalable s'applique au moment d'adopter un nouvel outil ou un nouveau cas d'usage significatif.

Étape 1 — Identifier les tâches candidates

Pour chaque tâche récurrente de l'entreprise, valider les huit signaux suivants :

• Répétitive — la tâche se fait au moins dix fois par semaine, avec une structure semblable (gabarit récurrent, étapes connues).
• Linguistique — elle implique du texte (lecture, rédaction, classification, extraction d'informations). Les grands modèles de langage sont avant tout des outils linguistiques.
• Chronophage pour le dirigeant ou un cadre — plus de trois heures par semaine d'une personne dont le temps est cher.
• Volume documentaire — recherche dans plus de cinquante documents internes (procédures, devis passés, fiches clients, codes techniques).
• Ambiguïté tolérée — la tâche admet des variations dans le résultat plutôt qu'une règle déterministe stricte. Si la réponse doit être exacte au caractère près, une macro ou un script est mieux qu'une IA.
• Échantillon disponible — vous avez au moins vingt à trente exemples passés (entrée + bonne sortie attendue) pour calibrer et valider les résultats de l'IA.
• Erreur récupérable — si l'IA se trompe, l'erreur est détectable et réparable avant qu'elle ne cause un dommage. Ce critère exclut les actes médicaux, les conseils légaux irréversibles, les décisions de prêt sans validation humaine.
• Pas de renseignements personnels sensibles non protégeables — ou bien on peut anonymiser, ou utiliser un modèle hébergé localement (Ollama + Open WebUI ou AnythingLLM sur serveur canadien).

Quatre signaux d'arrêt majeurs annulent la pertinence d'intégrer l'IA, peu importe les signaux d'opportunité : infrastructure manquante (processus non documentés, données éparpillées dans des fichiers personnels), décision irréversible automatique (article 12.1 de la Loi 25 — un humain doit valider une décision exclusivement automatisée), hallucination inacceptable (conseil légal, médical, fiscal sans validation experte), volumes trop faibles (deux à trois fois par mois — automatiser coûte plus que faire à la main).

Étape 2 — Prioriser avec les trois lentilles

Lentille Valeur — quel gain potentiel pour l'entreprise ?

• 1 — gain marginal (moins de dix heures économisées par année)
• 3 — gain significatif (cinquante à deux cents heures par année ou revenu nouveau de cinq à quinze mille dollars)
• 5 — transformation (plus de cinq cents heures par année ou revenu nouveau supérieur à vingt-cinq mille dollars)

Lentille Faisabilité — est-ce techniquement et organisationnellement réalisable ?

• 1 — technologie immature, équipe rebelle, processus à refondre avant toute intégration
• 3 — solution standard du marché, équipe ouverte, processus existant à ajuster
• 5 — solution clé en main (SaaS établi), équipe motivée, processus déjà documenté

Lentille Risque Loi 25 — quel niveau d'exposition réglementaire ?

• 1 — renseignements personnels sensibles touchés, décision automatisée et transfert hors Québec : arrêt, EFVP exhaustif requis
• 3 — renseignements personnels non sensibles touchés, fournisseur cloud avec entente de sous-traitance conforme à l'article 17
• 5 — aucun renseignement personnel touché, données publiques ou anonymisées : voie libre

Décision :

• Valeur ≥ 4, Faisabilité ≥ 3, Risque ≥ 3 — GO, prioriser le cas dans le plan d'action.
• Valeur ≥ 4, Faisabilité ≥ 3, Risque ≤ 2 — GO conditionnel après EFVP-IA exhaustive (voir étape 3).
• Valeur ≤ 2 — NO-GO, gain marginal, ne pas distraire l'entreprise.
• Faisabilité ≤ 2 — Attendre, refaire le diagnostic dans six mois après avoir levé les blocages.

Étape 3 — Évaluer l'impact : pourquoi évaluer avant d'adopter

Quatre familles de risques sont systématiquement présentes avec un système d'IA, à des degrés variables selon le cas d'usage :

• Biais dans les sorties. Le modèle reproduit ou amplifie des biais présents dans ses données d'entraînement. Effets : décisions discriminatoires, communications inappropriées, recommandations injustes.
• Hallucinations. Le modèle produit avec assurance des informations fausses, inventées ou trompeuses (citations inexistantes, articles de loi inventés, chiffres erronés). C'est intrinsèque à la technologie LLM.
• Dérive (drift). Quand le fournisseur met à jour le modèle, le comportement change. Une procédure validée en 2025 peut donner des résultats différents en 2026.
• Fuites de renseignements personnels. Les données saisies dans un outil mal encadré peuvent servir à entraîner les modèles ou être conservées plus longtemps que prévu.

Documenter ces risques avant l'adoption permet (a) de décider en connaissance de cause si le rapport bénéfice-risque est acceptable, (b) de mettre en place les mesures de mitigation appropriées, (c) de démontrer la diligence raisonnable en cas d'incident.

Cas concrets de biais documentés

Cas 1 — Apple Card (2019, persistant).

L'algorithme d'octroi de crédit de l'Apple Card a accordé à des femmes mariées des limites de crédit jusqu'à 20 fois plus basses qu'à leurs maris ayant le même profil de crédit, parfois avec des revenus identiques ou supérieurs. Le cas le plus médiatisé impliquait Steve Wozniak, cofondateur d'Apple, et sa femme. Le New York Department of Financial Services a ouvert une enquête. La leçon : un modèle entraîné sur des données historiques reproduit les biais historiques même si le sexe n'est pas une variable explicite — l'IA trouve des proxies (code postal, dépenses passées, profession).

Cas 2 — Workday (Mobley v. Workday, février 2023).

Derek Mobley, candidat noir de plus de 40 ans en situation de handicap, a poursuivi Workday — un des principaux fournisseurs d'outils RH automatisés — alléguant que son outil de tri de candidatures discriminait selon l'âge, la race et le handicap. Le cas est en cours, et un recours collectif a été certifié en 2024. La leçon : les outils d'IA RH sont en première ligne — pour une PME qui adopte un tel outil, l'évaluation préalable est non négociable.

Cas 3 — Étude Nature, octobre 2025 (LLM hiring bias).

Une étude publiée dans Nature en octobre 2025 a démontré que les grands modèles de langage (ChatGPT, Claude, Gemini) portent des biais profonds contre les femmes plus âgées en milieu de travail : à qualifications identiques, ils donnent des scores plus élevés aux hommes âgés qu'aux femmes âgées. Pour une PME qui utiliserait un LLM pour du tri de CV ou de l'évaluation de personnel, le risque légal et éthique est immédiat.

Cas 4 — Crédit, étude Berkeley 2018 + revue 2025.

Une étude de Berkeley (2018) a démontré que des systèmes de prêt automatisés facturaient des taux d'intérêt plus élevés aux emprunteurs noirs et latinos, à profil de crédit équivalent. Une revue académique de novembre 2025 montre que les femmes reçoivent en moyenne des scores de crédit 6 à 8 points plus bas que les hommes équivalents. La leçon : les outils financiers automatisés héritent des biais historiques, et la conformité ne peut pas se déduire de l'absence d'intention discriminatoire.

Cas 5 — Évaluation d'image, août 2025.

Un test publié en août 2025 a révélé que les coiffures noires naturelles (tresses, afros) reçoivent des scores d'« intelligence » et de « professionnalisme » plus bas dans les systèmes d'analyse d'image utilisés en RH. Pour une PME qui utiliserait un outil de présélection vidéo ou photo, le risque est documenté.

Ces cas ne signifient pas que l'IA est inutilisable — ils signifient que les biais sont la règle, pas l'exception. L'évaluation préalable doit examiner systématiquement quels biais sont susceptibles de se manifester dans le contexte d'usage envisagé.

Démarche EFVP-IA simplifiée — six questions

Question 1 — Quelles données entrent dans le système?

Cartographier les types de données qui seront saisies dans l'outil d'IA : données publiques (sans enjeu), données internes (notes, brouillons), renseignements personnels de clients ou d'employés (déclencheur de l'EFVP), données sensibles (santé, finance, judiciaire). La granularité importe — « nom et coordonnées du client » est différent de « numéro de RAMQ ».

Question 2 — Quelles décisions le système influence-t-il?

Trois niveaux à distinguer : information (l'IA fournit un contexte, l'humain décide librement), suggestion (l'IA propose une option, l'humain accepte ou refuse), décision automatisée (l'IA décide directement). L'article 12.1 de la Loi 25 ne s'applique qu'au troisième niveau, mais les deux premiers comportent aussi des risques (effet de halo, biais d'ancrage sur la suggestion IA).

Question 3 — Y a-t-il un humain dans la boucle avant action irréversible?

Pour les décisions à fort enjeu (refus de service, communication officielle, choix de fournisseur, évaluation de personnel), une validation humaine systématique est nécessaire avant action. Documenter qui valide, selon quels critères, dans quel délai. Sans validation humaine, l'organisation est exposée à l'article 12.1 et à la responsabilité directe des outputs IA.

Question 4 — Les biais documentés du modèle sont-ils acceptables pour le cas d'usage?

Consulter la fiche modèle (« model card ») fournie par le fournisseur si elle existe, et la littérature publique sur les biais connus du modèle. Pour les LLM grand public, les biais de genre, d'âge et d'origine ethnique sont documentés. Évaluer si ces biais ont des conséquences dans le cas d'usage envisagé (ils en ont presque toujours pour les décisions sur les personnes, rarement pour la rédaction de soumissions techniques).

Question 5 — Que se passe-t-il si le système se trompe?

Documenter le scénario d'erreur : qui le détecte, qui le corrige, qui informe le client si c'est nécessaire, qui assume la responsabilité financière, comment l'incident est consigné. Aligné sur la procédure d'incident de la politique d'usage (Module 3) et le registre des incidents Loi 25 article 3.5.

Question 6 — Comment l'erreur sera-t-elle détectée?

L'IA peut produire des erreurs silencieuses pendant longtemps avant qu'on s'en aperçoive. Définir comment elles seront repérées : revue humaine systématique de tout output, échantillonnage périodique, indicateur de qualité (taux de plainte, taux de retour, satisfaction utilisateur). Sans détection, on hérite des erreurs sans le savoir. Le Module 5 développe la surveillance dans la durée.

Articulation avec ISO 23894, ISO 42005 et la Loi 25

ISO/IEC 23894:2023 — Gestion des risques de l'IA.

Publiée en 2023, cette norme transpose le cadre ISO 31000 (gestion des risques) au domaine de l'IA. Elle définit comment identifier, évaluer et traiter les risques propres aux systèmes d'IA : biais, robustesse, transparence, sécurité des données, dérives. Pour une PME, on s'inspire de la structure (identification, évaluation, traitement, surveillance) sans formaliser un système de management complet.

ISO/IEC 42005:2025 — Évaluation d'impact des systèmes d'IA.

Publiée en 2025, cette norme est la version IA spécifique des évaluations d'impact. Elle structure la démarche en sections (description du système, parties prenantes affectées, risques identifiés, mesures de mitigation, surveillance). Les six questions du module précédent s'inspirent directement de cette structure, simplifiée pour une PME.

Loi 25 (LPRPSP) — Article 3.3 EFVP.

La Loi 25 impose une évaluation des facteurs relatifs à la vie privée pour tout traitement de renseignements personnels qui présente un risque pour les personnes concernées. Pour un système d'IA, ce risque est presque toujours présent. L'EFVP doit être faite avant l'adoption, pas après. Une EFVP IA bien menée selon les six questions du module précédent répond à cette obligation et fournit la documentation attendue par la Commission d'accès à l'information du Québec en cas d'enquête.

Articulation pratique pour une PME :

• L'EFVP article 3.3 est l'obligation québécoise — c'est cette obligation qu'il faut remplir pour être conforme.
• ISO 23894 et 42005 sont des sources d'inspiration — leur structure aide à organiser l'EFVP de manière défendable.
• La sophistication s'adapte au cas d'usage — un outil de rédaction de soumissions internes ne demande pas la même profondeur qu'un outil de tri de CV ou d'octroi de crédit.

Exemple appliqué — entrepreneur électricien adopte un assistant IA pour soumissions

Q1 — Données entrantes.

Notes de chantier (mesures, observations techniques), description du client (nom, adresse, type de bâtiment), historique des soumissions précédentes. Présence de renseignements personnels (nom du client particulier, adresse résidentielle). EFVP article 3.3 déclenchée.

Q2 — Décisions influencées.

L'IA suggère un brouillon de soumission. Le chargé des soumissions valide, ajuste le contenu technique, vérifie la tarification. Niveau de décision : suggestion, pas décision automatisée. Article 12.1 non applicable directement, mais effet de halo possible (le chargé peut accepter passivement la suggestion sans la critiquer).

Q3 — Humain dans la boucle.

Validation systématique du chargé des soumissions avant envoi. Pour les soumissions au-dessus de 25 000 $, seconde validation par le dirigeant. Documentation : la politique d'usage Module 3 prévoit déjà ce point.

Q4 — Biais.

Pour la rédaction de soumissions techniques, les biais documentés des LLM (genre, âge, origine) sont peu pertinents — il n'y a pas de décision sur une personne. Risque réel : l'IA peut sous-évaluer ou sur-évaluer la complexité technique en s'inspirant de soumissions passées qui ne sont pas représentatives. Mitigation : revue humaine systématique du contenu technique, pas seulement de la forme.

Q5 — Erreur.

Scénario : l'IA suggère un libellé technique inexact qui passe la validation et arrive au client. Détection : le client signale la divergence ou l'écart se révèle pendant l'exécution du chantier. Correction : le chargé contacte le client, fournit un avenant clarifiant. Coût absorbé par l'entreprise. Documentation dans le registre d'incidents si l'écart a entraîné une exposition financière supérieure à 5 000 $.

Q6 — Détection.

Indicateur principal : taux de demandes de clarification clients sur les soumissions générées avec assistance IA, comparé au taux historique. Indicateur secondaire : écart entre soumission et coût final du chantier. Revue trimestrielle des deux indicateurs par le chargé des soumissions et le dirigeant.

Conclusion EFVP :

Risque résiduel acceptable. Adoption autorisée sous condition de mise en place des mesures de mitigation (revue humaine systématique, indicateurs de qualité, revue trimestrielle). DPA Microsoft signé et vérifié. Politique d'usage du Module 3 mise à jour pour mentionner explicitement Copilot et le cas d'usage soumissions. Document EFVP signé par le dirigeant et archivé dans le registre des EFVP de l'entreprise.

Erreurs fréquentes et pièges à éviter

• ❌ Sauter l'évaluation pour gagner du temps. « C'est juste un outil de rédaction, pas besoin d'EFVP. » Si des renseignements personnels sont saisis, l'EFVP article 3.3 est déclenchée — peu importe la taille du projet.
• ❌ Faire l'évaluation après l'adoption. L'obligation Loi 25 est avant. Une EFVP rétroactive ne corrige pas une non-conformité.
• ❌ Confondre l'évaluation avec un audit complet. L'EFVP IA est une évaluation préalable, pas un audit de production. Pour un outil simple, six questions suffisent.
• ❌ Faire confiance aveugle à la documentation du fournisseur. Les fiches modèles (« model cards ») omettent souvent les biais les plus connus. Vérifier dans la littérature publique en plus.
• ❌ Ignorer les biais sous prétexte que le cas d'usage « ne touche pas les personnes ». Beaucoup de cas d'usage indirects (allocation de ressources, priorisation de tâches, choix de sous-traitants) finissent par toucher des personnes — l'évaluation doit creuser.
• ❌ Documenter une fois et oublier. Les LLM évoluent — le modèle adopté aujourd'hui n'est pas le même dans 12 mois. Réviser l'EFVP à chaque mise à jour majeure du fournisseur ou changement de cas d'usage.

L'erreur structurelle la plus coûteuse : voir l'EFVP comme un obstacle à l'adoption plutôt que comme l'outil qui permet d'adopter avec sérénité. Une EFVP bien menée donne au dirigeant la confiance pour avancer, pas une raison de freiner.