Surveiller un système d'IA
dans la durée — détecter avant l'incident

Module 5 — Surveiller dans la durée plutôt qu'auditer une fois

L'évaluation avant adoption (Module 4) est une photo. La surveillance dans la durée est un film. Pour qu'un système d'IA reste utile, défendable et conforme dans le temps, il faut un processus continu, pas un audit ponctuel.

Prérequis : avoir parcouru les Modules 1 à 4 — vocabulaire, choix de l'architecture, politique d'usage, évaluation avant adoption. La surveillance dans la durée présuppose un déploiement en production avec EFVP préalable signée.

Pourquoi un système d'IA dérive — et pourquoi c'est invisible

Trois mécanismes provoquent la dérive d'un système d'IA en production :

• Évolution des données d'entrée. Les types de chantiers, les méthodes de tarification de la matière première, les profils de clientèle changent au fil des trimestres. Le modèle, lui, a été entraîné sur une distribution antérieure. L'écart se creuse.
• Mise à jour du modèle par le fournisseur. OpenAI, Anthropic, Microsoft mettent à jour leurs modèles tous les 3 à 12 mois. L'amélioration moyenne est positive, mais le comportement spécifique sur votre cas d'usage peut changer — parfois en pire.
• Évolution des usages internes. Les employés découvrent de nouvelles façons d'utiliser l'outil, élargissent le périmètre au-delà de ce qui était prévu lors de l'EFVP. La frontière du cas d'usage initial s'estompe.

La caractéristique commune des trois mécanismes : ils sont silencieux. Le système continue de produire des sorties, l'interface ne signale rien, les utilisateurs ne ressentent souvent pas immédiatement la baisse de qualité. Quand le problème devient visible, il est généralement déjà ancien — et un nombre significatif de sorties fautives a déjà été émis.

Trois types de dérive — distinctions utiles

Data drift (dérive des données).

La distribution des données qui entrent dans le système change. Exemple pour un entrepreneur électricien : un assistant IA utilisé pour rédiger des soumissions a été déployé alors que l'entreprise faisait surtout du résidentiel. Six mois plus tard, l'entreprise a remporté plusieurs contrats commerciaux importants — les soumissions sont structurellement différentes. Le modèle continue de fonctionner mais ses suggestions sont moins pertinentes pour ce nouveau contexte. Le problème vient des données, pas du modèle.

Concept drift (dérive de concept).

La relation entre les entrées et la bonne sortie change. Exemple : la matière première (cuivre, aluminium, fixations) connaît une hausse rapide des prix. Les soumissions générées par l'IA s'inspirent des marges historiques — elles sous-évaluent désormais les coûts. Le modèle n'est pas dégradé techniquement, mais la « vérité de référence » a changé. C'est le type de dérive le plus dangereux parce que les sorties paraissent normales jusqu'à ce qu'on compare avec la réalité.

Performance drift (dérive de performance).

La qualité des sorties se dégrade sans qu'on puisse identifier précisément la cause — souvent la combinaison de data drift, de concept drift, et de mises à jour du modèle. Exemple : le taux de demandes de clarification clients sur les soumissions générées par IA passe de 5 % à 15 % en six mois. L'origine exacte est difficile à déterminer, mais l'effet métier est mesurable.

Mitigation différenciée :

• Data drift → ajuster les prompts pour mieux refléter le nouveau contexte, ou ré-entraîner si on contrôle le modèle (rare en PME — les LLM sont externalisés).
• Concept drift → revoir les hypothèses du cas d'usage, mettre à jour les références (par exemple, taux de marge actualisés), parfois reconcevoir le système.
• Performance drift → diagnostic combiné, parfois changement de modèle (passer de GPT-4 à GPT-5 si GPT-4 dérive sur votre cas d'usage).

Quatre méthodes de détection accessibles aux PME

Méthode 1 — Vérification périodique avec cas-tests connus.

Constituer une banque de 5 à 10 cas-tests représentatifs, dont la bonne réponse est documentée et stable. Une fois par mois, soumettre les cas au système d'IA et comparer les sorties à la référence. Si la qualité chute ou que le ton change significativement, signal de dérive.

Exemple pour un entrepreneur électricien : 5 demandes de soumission anonymisées (résidentiel simple, résidentiel avec rénovation majeure, commercial léger, commercial avec automatisation, industriel léger). Pour chacune, une soumission de référence validée par le chargé. Comparaison mensuelle.

Méthode 2 — Revue humaine d'un échantillon des sorties.

Chaque mois, prendre 10 % des sorties produites par le système (ou 10 sorties si le volume est faible) et les revoir manuellement avec une grille de qualité (exactitude factuelle, ton, absence de biais). Documenter le taux de sorties acceptables vs problématiques. Une chute du taux signale une dérive.

Méthode 3 — Indicateurs métiers.

Surveiller des indicateurs métier qui répercutent indirectement la qualité du système d'IA : taux de demandes de clarification clients sur les soumissions, taux de retour ou de plainte, écart entre soumission et coût final, satisfaction utilisateur interne (sondage trimestriel court). C'est la méthode la plus fiable pour détecter le concept drift, parce qu'elle mesure l'effet sur la réalité métier.

Méthode 4 — Revue trimestrielle structurée.

Une fois par trimestre (ou semestriellement pour les usages à faible enjeu), revue formelle de chaque système d'IA déployé : performance observée, incidents survenus, mises à jour du fournisseur, évolution du cas d'usage, mise à jour de l'EFVP si nécessaire. Document court (1-2 pages) signé par le responsable de la politique IA et le RPRP s'il y en a un.

Pour la majorité des PME, ces quatre méthodes ensemble représentent quelques heures par mois et permettent de détecter les dérives 6 à 12 mois plus tôt qu'une organisation qui ne surveille pas. Les outils techniques sophistiqués (Evidently AI, WhyLabs) deviennent pertinents pour les organisations qui ont plusieurs systèmes d'IA en production avec un volume élevé d'inférences — pas pour la PME qui utilise Copilot ou ChatGPT Team.

Articulation avec ISO/IEC 42001:2023 et la Loi 25

ISO/IEC 42001:2023 — Système de management de l'IA (AIMS).

Publiée en décembre 2023, c'est la première norme certifiable consacrée à la gestion de l'IA dans une organisation. Elle suit la structure des autres systèmes de management ISO (27001 pour la sécurité, 9001 pour la qualité) avec un cycle Plan-Do-Check-Act. La phase « Check » (surveillance et mesure) est centrale. Pour une PME qui ne vise pas la certification, les exigences pertinentes sont :

• Définir des indicateurs de performance pour chaque système d'IA déployé.
• Mesurer ces indicateurs périodiquement.
• Réagir aux écarts de manière documentée.
• Réviser le système (politique, EFVP, formation) à intervalles réguliers.

C'est exactement la structure des quatre méthodes du module précédent — la sophistication s'arrête au niveau approprié pour une PME, sans formaliser un système complet.

Loi 25 (LPRPSP) — Maintien des EFVP et registre des incidents.

• Article 3.3 — EFVP à jour. L'EFVP n'est pas un document figé au moment de l'adoption. Si le système, son usage, ou le contexte changent significativement, l'EFVP doit être révisée. La surveillance fournit la preuve que ces changements sont effectivement détectés et traités.
• Article 3.5 — Registre des incidents. Tout incident significatif (output IA fautif communiqué, fuite de RP via outil non autorisé, dérive avec impact client) doit être consigné. Le registre est aussi la matière première de la révision trimestrielle.
• Article 12.1 — Information sur les décisions automatisées. Si la nature des décisions évolue (par exemple si l'usage de l'IA s'étend de l'aide à la rédaction à la suggestion de tarification), l'information aux personnes doit être mise à jour. La surveillance détecte ces dérives d'usage.

La cohérence est claire : ce que la Loi 25 demande (maintien à jour, traçabilité, information) suppose une surveillance. Ce qu'ISO 42001 structure (cycle de management, indicateurs, revue) en fournit la méthode. Une PME qui suit la routine du module précédent répond aux deux à la fois sans dédoubler les efforts.

Routine de surveillance — exemple appliqué entrepreneur électricien

Routine mensuelle (1 heure par mois — chargé des soumissions).

1. Cas-tests. Soumettre les 5 cas-tests de référence à Copilot. Comparer aux sorties de référence. Noter les écarts dans un tableau de suivi (date, cas, qualité, observations). 15 minutes.
2. Échantillonnage. Prendre 5 soumissions produites avec Copilot dans le mois. Les revoir avec une grille (exactitude technique, libellé, structure, ton). Calculer le taux de sorties acceptables sans correction. 30 minutes.
3. Indicateurs. Mettre à jour le tableau des indicateurs : taux de demandes de clarification clients, écart soumission/coût final, sondage employé bref (un email avec 3 questions). 15 minutes.

Routine trimestrielle (2 heures par trimestre — dirigeant + chargé des soumissions).

1. Synthèse des routines mensuelles. Lire les 3 tableaux mensuels. Identifier les tendances (stabilité, amélioration, dégradation). 30 minutes.
2. Revue des incidents. Parcourir le registre des incidents Loi 25 article 3.5. Examiner ceux liés à Copilot. Analyser les causes. 30 minutes.
3. Mises à jour fournisseur. Vérifier le journal des changements de Microsoft Copilot publié. Identifier les changements pertinents pour le cas d'usage. 30 minutes.
4. Décisions et documentation. Décider des ajustements (mise à jour des prompts, formation employés, révision EFVP, escalade au RPRP). Documenter dans un compte-rendu d'une page signé par le dirigeant. 30 minutes.

Routine annuelle (1 demi-journée — dirigeant et responsable politique IA).

1. Revue complète de la politique d'usage de l'IA — toujours à jour vs les outils approuvés actuels.
2. Révision de l'EFVP — réécriture si la nature de l'usage a significativement évolué.
3. Mise à jour des cas-tests — refléter les nouveaux types de chantier ou de soumission.
4. Formation continue des employés — courte session sur les évolutions des outils et les nouveaux risques observés.

Au total : environ 12 heures par an pour la surveillance d'un système d'IA en production en PME. C'est l'investissement minimal pour transformer un déploiement risqué en déploiement défendable et durable.

À titre de comparaison : sur l'exemple ci-dessus, l'usage de Copilot pour la rédaction de soumissions seul fait économiser environ 35 heures par mois (passage de 90 à 20 minutes par soumission × 30 soumissions par mois), soit près de 420 heures par an. Les 12 heures de surveillance représentent ainsi moins de 3 % du temps gagné — un ratio négligeable au regard de la défendabilité légale et de la qualité durable du système. Et c'est en ne comptant que les soumissions : ajouter le triage des courriels, les FAQ internes, la rédaction marketing étend largement le gain réel.

Erreurs fréquentes et pièges à éviter

• ❌ Aucune surveillance prévue à l'adoption. Une EFVP qui ne mentionne pas la surveillance laisse l'organisation sans réflexe ensuite. La surveillance doit être planifiée avant le déploiement, pas après.
• ❌ Surveillance technique sophistiquée mais non appliquée. Mettre en place Evidently AI ou WhyLabs sans avoir personne pour interpréter les tableaux de bord équivaut à pas de surveillance. Préférer des méthodes simples effectivement appliquées.
• ❌ Aucune révision quand le fournisseur met à jour le modèle. Microsoft fait évoluer Copilot — l'organisation continue comme si rien n'avait changé. Les performances peuvent se dégrader silencieusement sur des cas d'usage spécifiques.
• ❌ Pas de cas-tests stables. Sans référence fixe pour comparer, on perd la capacité de détecter une dérive. La banque de cas-tests doit être constituée à l'adoption et maintenue.
• ❌ EFVP figée au moment de l'adoption. Une EFVP qui n'est jamais révisée devient un document de papier. Les autorités (Commission d'accès à l'information du Québec) attendent une EFVP qui reflète l'usage réel courant.
• ❌ Confondre incident et dérive. Un incident est un événement. Une dérive est une tendance. Surveiller uniquement les incidents fait rater les dérives. Surveiller les indicateurs fait détecter les dérives avant qu'elles deviennent des incidents.

L'erreur structurelle la plus coûteuse : voir la surveillance comme un fardeau administratif plutôt que comme un système d'alerte précoce. Une organisation qui surveille bien détecte les problèmes 6 à 12 mois plus tôt et résout dans le calme. Une organisation qui ne surveille pas découvre les problèmes par les plaintes clients et les résout dans la crise.