La cartographie de l’intelligence opérationnelle pour les exceptions détenues consiste à transformer « on a vu quelque chose » en une chaîne de décision prête pour la gouvernance : signal → logique d’interprétation → décision/revue → résultat détenu.Pour les dirigeants et leaders techniques au Canada (PME et petites équipes), la conséquence opérationnelle est directe : lorsque la gestion des exceptions reste non structurée, on obtient des goulots d’étranglement décisionnels, des approbations incohérentes et des lacunes d’audit—particulièrement quand l’IA intervient.Decision architecture (architecture de la décision) est le système d’exploitation qui détermine comment le contexte circule, comment les décisions sont prises, comment les approbations sont déclenchées et comment les résultats sont détenus à l’intérieur d’une entreprise. (nvlpubs.nist.gov)Dans cet article, nous structurons la réflexion que vous pouvez réutiliser pour concevoir une architecture opérationnelle d’IA autour des exceptions détenues—celles pour lesquelles l’entreprise doit rester responsable, assurer une revue humaine et conserver une traçabilité vers des registres primaires.> [!INSIGHT]> La ressource rare n’est pas la sortie de l’IA. C’est la réflexion structurée : la frontière de décision, la piste de preuves et le responsable qui signe.
Cartographier d’abord les exceptions que vous détenez avant de choisir
un modèleOn ne peut pas gouverner ce qui n’est pas cartographié. Premier geste pratique : traiter les « exceptions détenues » comme une frontière de décision, pas comme un comportement libre de l’agent ou du modèle. Preuve : le NIST (AI Risk Management Framework 1.0) traite la gouvernance comme une exigence continue et intrinsèque à la gestion du risque lié à l’IA, avec des rôles, des politiques et des contrôles sur le cycle de vie—pas un simple formulaire. (nvlpubs.nist.gov)
Implication : commencez par distinguer ce que l’agent peut exécuter sans revue (« agent peut procéder ») et ce qui doit être routé vers un réviseur nommé (« agent doit demander une revue »). Si vous faites cela après avoir choisi des outils, vous finissez souvent par réécrire des workflows au lieu d’améliorer les décisions.
Une chaîne réutilisable à dessiner en atelier
Signal ou entrée → logique d’interprétation → décision ou revue → résultat d’affaires (avec propriétaire).Appliquez-la explicitement aux cas d’exception.Exemple (PME, opérations) :Signal ou entrée : une ligne de facture sans document justificatif requis.Logique d’interprétation : déterminer si l’absence de document est « requise par la politique » selon le type de client, le type de service et les conditions contractuelles.Décision ou revue : si requis, routage vers l’approbateur Finance ; sinon, demande de document au fournisseur via un workflow sécurisé.Résultat d’affaires : traitement des paiements conforme, avec preuves traçables.Cette approche rejoint l’idée que la fonction « MAP » attend la documentation des parcours décisionnels et des exigences d’encadrement humain. (airc.nist.gov)
Attacher des preuves primaires à chaque route d’exception
Les exceptions détenues
échouent quand le système ne peut pas prouver ce qu’il a vu, quelle règle il a appliquée, et quels enregistrements ont été consultés. Preuve : la norme ISO/IEC 42001 exige un système de gestion de l’IA avec des attentes de traçabilité, transparence et fiabilité, en ancrant la documentation et la gouvernance dans le fonctionnement organisationnel. (iso.org)
Implication : pour chaque type d’exception, définissez le « paquet de preuves » minimum que vos systèmes de contexte doivent transporter—afin que la revue ne soit pas « faites confiance à l’IA ».
Ce que le paquet de preuves doit permettre de répondre
Au
moment de la revue, vous devez pouvoir répondre à Quel était le signal ? (entrée exacte, horodatage, système source)
Quelle a été la logique d’interprétation ? (version de la règle, référence à la politique, seuil/confiance si applicable)Quelles sources primaires ont été consultées ? (identifiants d’articles de contrat, identifiants de politiques internes, notes de cas antérieurs)Quelle règle de décision a déclenché la route d’exception détenue ? (critère ou seuil)Qui a approuvé ou escaladé ? (rôle nommé + décision de revue)Cela correspond à l’accent du NIST AI RMF sur l’encadrement humain (human oversight) et la documentation des contrôles à travers le cycle de vie de l’IA. (airc.nist.gov)
Orchestrer les revues avec des seuils et des responsables nommés
Une
orchestration « prête pour la gouvernance » empêche les exceptions de devenir « un autre fil Slack ». Preuve : le NIST AI RMF playbook décrit l’établissement de contrôles de risque et la documentation des configurations human-AI teaming dans la fonction « Manage », incluant des règles métier et des mécanismes de revue humaine pour limiter les sorties et garder une traçabilité opérationnelle. (airc.nist.gov)
Implication : décidez maintenant comment la couche d’orchestration routage les exceptions.
Une règle de décision concrète (exemple AP)
Pour une validation de factures / paiements :Si policy_requires_evidence == true ET evidence_missing == true ET vendor_risk_category dans {« high », « contract_disputed »} → routage vers l’approbateur Finance dans un délai d’1 jour ouvrable.Sinon → routage vers le traitement AP pour relance fournisseur, en journalisant la demande de preuve.C’est un geste d’architecture de décision : l’orchestration doit imposer la règle de routage et livrer au réviseur le paquet de preuves.
Nommer le réviseur (et la voie d’escalade)
Un patron typique en PME :Propriétaire : contrôleur Finance (approbation des décisions de conformité liées au paiement).Réviseur : superviseur AR/AP (vérifie l’exhaustivité des preuves).Escalade : COO ou contact Legal/Conformité si l’interprétation de la politique entre en conflit avec le langage contractuel.Pourquoi : les attentes canadiennes en matière de décision automatisée mettent en avant transparence, responsabilité et possibilité d’un encadrement humain pour les décisions pouvant affecter des droits ou des intérêts. (statcan.gc.ca)
Les compromis quand on cartographie trop tard ou trop large
La
cartographie a un coût. Le compromis est entre vitesse opérationnelle et préparation à la gouvernance. Preuve : l’outil d’Algorithmic Impact Assessment (AIA) du Gouvernement du Canada est conçu comme un mécanisme d’évaluation des risques pour soutenir la Directive sur la décision automatisée, en reliant l’évaluation au type de décision et à l’impact. (canada.ca)
Implication : si vous cartographiez trop tard, vous devrez faire une « correction de conformité » après coup. Si vous cartographiez trop large, vous ralentissez l’opération en sur-routant.
Mode d’échec : exceptions sans propriétaire
Ce qui casse quand la pensée reste non structurée :L’IA signale un problème, mais l’organisation ne peut pas dire quelle politique elle a utilisée.Les preuves ne sont pas attachées : les réviseurs doivent rouvrir les systèmes sources.Les approbations deviennent non répétables : « prête pour la gouvernance » devient « connaissance tribale ».C’est précisément ce que les fonctions « govern » et « map » du NIST AI RMF cherchent à empêcher en forçant la documentation des rôles, parcours décisionnels et attentes d’encadrement humain. (airc.nist.gov)> [!WARNING]> Si chaque exception devient « à haut risque », vous entraînez l’organisation à ignorer l’escalade—et vous perdez la traçabilité au moment critique.
Traduire cette thèse en votre prochaine évaluation d’architecture
Vous n’avez pas
besoin d’un programme d’entreprise. Vous avez besoin d’un « funnel » d’évaluation qui rend les décisions auditables et réutilisables. Preuve : le NIST AI RMF est conçu pour intégrer des considérations de fiabilité (« trustworthiness ») dans la conception, le développement, le déploiement et l’utilisation des systèmes d’IA. (nist.gov)
Implication : conduisez l’évaluation d’architecture comme un exercice de structuration des décisions pour une seule famille d’exceptions détenues.
Le funnel d’architecture_assessment_funnel pour exceptions détenues
Étapes d’évaluation de l’architecture de
décision Étape 1 : inventorier les types d’exceptions sur un workflow ciblé (ex. validation de factures AP).Étape 2 : pour chaque exception, cartographier signal → logique → décision/revue → propriétaire du résultat.Étape 3 : définir les minimums du paquet de preuves pour la revue.Étape 4 : définir les règles de routage (seuils/critères) et nommer le réviseur + la voie d’escalade.Étape 5 : valider la préparation à la gouvernance : pouvez-vous produire une « fiche de cas » traçable pour un échantillon aléatoire en quelques heures ?Contexte canadien : si votre workflow fait (ou assiste) des décisions administratives ayant un impact sur des droits, privilèges ou intérêts en dehors du gouvernement, les directives canadiennes traitent l’AIA comme un mécanisme d’évaluation des risques pour les systèmes de décision automatisée. (canada.ca)
Ligne d’autorité (citation) : « La gouvernance n’est pas un document. C’est la logique de routage, le paquet de preuves et le réviseur responsable—qui fonctionne de la même façon après l’incident. »— Chris June, fondateur d’IntelliSync> [!DECISION]> « Open Architecture Assessment » veut dire : cartographier les exceptions détenues d’abord, puis concevoir les systèmes de contexte et l’orchestration d’agents pour rendre les décisions auditables et réutilisables en opération.
Appel à l’action
Open Architecture Assessment : planifiez une évaluation d’architecture avec IntelliSync pour cartographier vos exceptions détenues, définir des seuils d’orchestration prêts pour la gouvernance et construire les paquets de preuves dont vos réviseurs ont besoin—sans ralentir vos opérations quotidiennes.