Le travail ne consiste pas a produire plus de sorties. Il consiste a structurer la reflexion autour de la decision, du contexte, du signal, de la logique de revue, et du responsable qui garde le workflow accountable.
La responsabilité des exceptions sous orchestration doit être imposée par des seuils d’examen en gouvernance qui changent le réviseur, les preuves requises et le chemin d’escalade quand un dossier franchit une frontière de risque décisionnel.
L’IA ne devrait pas produire des sorties “pour elle-même” : elle doit structurer la décision et rendre le propriétaire de chaque exception explicite. La decision architecture est l’« operating system » 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 attribués à l’intérieur d’une entreprise. Pour une petite équipe de direction au Canada, l’enjeu est concret quand un goulot décisionnel apparaît — par exemple l’admission vers l’approbation dans un dossier réglementé — parce que la logique peut devenir opaque quand l’orchestration “dissimule” le chemin de décision. La solution : une couche de gouvernance qui relie des seuils d’examen et la responsabilité des exceptions directement au chemin de décision, avec une base primaire (p. ex. l’approche de l’Algorithmic Impact Assessment (AIA) pour des exigences proportionnées). (canada.ca)
Les seuils de gouvernance rendent la propriété des exceptions vérifiable
En orchestration, l’échec le plus coûteux n’est pas la qualité du modèle ; c’est l’attribution floue des exceptions. Souvent, elles sont “signalées” sans changer : ni le propriétaire, ni les preuves attendues, ni le chemin d’escalade. Le mécanisme canadien vise précisément la proportionnalité et l’imputabilité : la Directive sur la prise de décisions automatisée exige une AIA avant la mise en production et attend la mise à jour de l’AIA lorsque la fonctionnalité ou le périmètre change. (publications.gc.ca) Preuve : l’outil AIA est organisé pour déterminer un niveau d’impact via des questions de risque et de mesures d’atténuation, couvrant projet, système, algorithme, décision, impact et données. (canada.ca)
Conséquence : votre architecture opérationnelle de l’IA doit cesser de poser uniquement la question “la réponse IA est-elle bonne ?”. Elle doit poser “cette exception franchit-elle un seuil de gouvernance qui modifie qui doit examiner et quelles preuves doivent être consignées ?”. Concrètement, le seuil devient une frontière de décision.> [!INSIGHT] Si vous ne pouvez pas nommer le propriétaire de l’exception avant le déploiement, vous ne pourrez pas reconstruire la décision après un incident.
Le tri des signaux transforme des entrées en décisions appartenant
à quelqu’unLa dérive décisionnelle commence au tri : l’orchestration reçoit des signaux multiples (documents, formulaires, indicateurs de risque, score du modèle, extraits de récupération) puis une logique d’interprétation choisit la suite. Le geste d’architecture le plus utile est de rendre la chaîne explicite et d’y brancher la couche de gouvernance. Chaîne opérationnelle :Signal → logique d’interprétation → décision / examen → propriétaire du résultat.Exemple de chaîne :Entrées : documents soumis + attributs depuis des systèmes internes + correspondances de récupération + score du modèle.Logique : règles d’acceptation + règles d’exception.Routage : approbation automatique uniquement si le seuil de gouvernance est “faible” ET que la règle d’exception est fausse ; sinon, examen par une personne nommée.Propriété : en cas d’exception, le réviseur devient le propriétaire et la décision est loggée avec les preuves du dossier.Pourquoi c’est défendable avec des sources : NIST AI RMF insiste sur une gestion continue des risques (gouverner, cartographier, mesurer, gérer), plutôt que sur une posture “papier annuel”. (nist.gov)
Conséquence : définissez au moins une règle de décision qui dépend de la gouvernance (pas seulement de la confiance du modèle). Exemple de règle (pour un workflow client sécurisé) :Règle de tri (exemple) :Renvoyer vers “Examen des exceptions” si une des conditions suivantes est vraie :Le niveau d’impact (dérivé de l’AIA) pour le type de décision est “plus élevé” ET le dossier touche une zone de risque relative à des caractéristiques protégées OU la justification cite des enregistrements manquants / contradictoires.OU l’orchestration détecte un écart de contexte (p. ex. la récupération n’atteint pas N sources faisant autorité, ou la politique versionnée est en conflit).Résultat : le réviseur est propriétaire du cas, et l’orchestration conserve le “bundle de contexte” utilisé.> [!DECISION] Traitez les “écarts de contexte” comme des exceptions qui changent le propriétaire de l’examen — pas comme une invitation à faire confiance davantage au modèle.
Exemple pratique : admission vers approbation sans dérive décisionnelle
Imaginez une
PME canadienne à petite équipe, avec un workflow documentaire réglementé : onboarding pour un produit financier ou approbation d’une demande d’accommodement (RH). Le goulot est le temps de revue quand les cas sont limites ou incomplets. Vous adoptez une boundary de système privée : un outil interne, sécurisé, qui aide à trier (recommandation), puis escalade les exceptions vers examen humain. Preuve ancrée dans des sources primaires : l’AIA inclut des domaines d’atténuation comme l’équité procédurale (p. ex. audit trails, raisons produites pour les décisions, mécanisme de recours) et la protection de la vie privée (p. ex. réalisation d’une Privacy Impact Assessment, safeguards, dé-identification). (canada.ca) La Directive exige aussi une intervention humaine “lorsque approprié” et des approbations avant la mise en production. (publications.gc.ca)
Conséquence : rendez la propriété des exceptions visible dans l’exécution.Actions concrètes :Définir le “Réviseur responsable” (Reviewer of Record) par type de décision et niveau d’impact.Exemples de rôles côté PME :Contrôleur / finance pour l’admissibilité au crédit ou aux montants.Responsable conformité RH pour les décisions liées à l’emploi.Conseiller juridique / conformité pour les exceptions à fort impact.Définir le “minimum viable context bundle” requis pour l’examen :Documents sources (uploads faisant autorité).Identifiant de version de la politique.Niveau d’impact (dérivé de l’AIA) associé au type de décision.Signaux utilisés pour le tri + statut d’écart de contexte.Puis exiger une sortie structurée du réviseur :Approuver avec un code de raison interne lié à la politique.Ou escalader avec un code d’exception lié au seuil de gouvernance.C’est ainsi que les décisions restent auditées sur des enregistrements primaires, plutôt que de laisser une sortie “bon marché” devenir un récit non imputable.
Équilibres et modes de panne des seuils
Les seuils aident, mais ils peuvent dérailler s’ils deviennent statiques. NIST AI RMF souligne que la gestion des risques est socio-technique et doit être pensée comme un ensemble d’activités continues sur le cycle de vie. (nist.gov) ISO/IEC 42001 positionne également un AI management system comme des éléments et processus organisationnels interreliés, pour établir politiques, objectifs et pratiques responsables. (iso.org)
Mode de panne : “escalade molle”.Ce qui casse : l’orchestration repère bien une exception, mais ne change ni le propriétaire, ni les preuves attendues, ni le chemin d’escalade. Résultat : traçabilité incohérente et propriété ambiguë.Mode de panne : inflation des seuils.Ce qui casse : tout devient “fort impact” parce que la logique de tri est trop sensible aux écarts de contexte. Vous créez alors le goulot que l’orchestration voulait réduire.Mitigation : associer le design des seuils à une règle de changement. Le guide AIA indique que même si des mesures réduisent certains risques identifiés, elles ne changent pas le niveau d’impact sans compléter une nouvelle AIA avec des informations mises à jour ; et les départements doivent revoir, approuver et mettre à jour les AIA publiées sur une base programmée, y compris après changements de fonctionnalité ou de périmètre. (canada.ca)Conséquence : versionnez vos seuils comme des artefacts de gouvernance, pas comme des réglages “prompt”.> [!WARNING] Ne confondez pas “on a changé le prompt” avec “on a changé le risque décisionnel”. La frontière de propriété des exceptions doit bouger uniquement avec des changements documentés.
Transformer la gouvernance en décision d’exploitation
Pour rendre la responsabilité des
exceptions opérationnelle sous orchestration, commencez par les artefacts minimaux de decision architecture que la direction peut s’approprier. Carte du chemin décisionnel : qui possède quoi à chaque exception.Inventaire des context systems : quels enregistrements et instructions sont attachés à chaque étape.Gouvernance readiness : quels types de décision déclenchent des exigences proportionnées, et quelles preuves le réviseur doit consigner.Pourquoi cela colle aux sources primaires : la Directive exige une AIA avant la mise en production et une logique d’intervention humaine à des niveaux proportionnés, avec des obligations de documentation et de reviewabilité. (publications.gc.ca) NIST AI RMF cadre la gouvernance comme un ensemble de fonctions continues de gestion du risque. (nist.gov)
Décision orientée action (dès cette semaine) :Exécuter un “dry run” de propriété d’exceptions sur un vrai workflow bloquant.Choisir 20 dossiers récents “limites”.Pour chacun, répondre à quatre questions :Quels signaux d’entrée ont été utilisés ?Quelle logique d’interprétation a converti ces signaux en décision ?Quel seuil de gouvernance s’appliquait, et pourquoi ?Qui a été propriétaire de l’examen d’exception, et les preuves requises ont-elles été consignées ?Si une réponse est “on ne sait pas”, ce n’est pas un problème de modèle. C’est un problème de couche de gouvernance et de frontières de décision (ownership, seuils, traçabilité).Ligne d’autorité (quoteable) : « La sortie bon marché est facile ; la pensée structurée avec des propriétaires nommés empêche la dérive décisionnelle. » — Chris June, fondateur d’IntelliSync.> [!EXAMPLE] Si vous constatez que les approbations se font “par fil de courriels”, c’est un signal : votre orchestration doit produire un dossier d’examen, pas seulement une recommandation.Open Architecture Assessment : structurez la pensée pour rendre les décisions auditées, ancrées dans des sources primaires, et réutilisables en opération. Commencez par formaliser le chemin décisionnel et les seuils d’exception ; puis faites passer votre prochaine revue de gouvernance par un Architecture Assessment pour concevoir en vue de la réutilisation opérationnelle — pas pour rationaliser au cas par cas.
FAQ**1) Est-ce que des seuils de gouvernance signifient une documentation
lourde pour chaque cas IA ?**Non.
L’objectif est la proportionnalité. L’outil AIA canadien sert à déterminer un niveau d’impact et structure les questions d’atténuation en conséquence ; donc, au runtime, vos exigences de preuves ne doivent changer que quand le seuil de risque décisionnel l’exige. (canada.ca)**2) C’est quoi une “exception” dans l’orchestration ?**Une exception, c’est une situation qui change la frontière de risque décisionnel ou qui rompt des hypothèses de contexte requises — par exemple des documents non fournis faisant autorité, des versions de politique contradictoires, ou un écart de contexte détecté. L’idée n’est pas de tout signaler, mais de router vers un propriétaire nommé avec des preuves traçables. (canada.ca)**3) Comment choisir un réviseur responsable pour une PME ?**Commencez par le rôle métier qui peut réellement posséder l’issue de la décision et citer les enregistrements faisant autorité. Ensuite, alignez ce rôle au seuil de gouvernance : les exceptions à plus fort impact doivent toujours passer au Réviseur responsable, avec des artefacts audités. (publications.gc.ca)**4) Pourquoi la dérive décisionnelle survient-elle même après une AIA ?**Parce que l’orchestration ne relie pas l’AIA au routage runtime (propriétaire, preuves requises, chemin d’escalade). La Directive demande des AIA mises à jour quand la portée ou la fonctionnalité change : vos règles d’ownership à l’exécution doivent suivre ces décisions de gouvernance. (publications.gc.ca)**5) Est-ce utile pour des outils internes aussi, ou seulement pour les systèmes face aux clients ?**C’est utile dans les deux cas. La partie réutilisable est le mécanisme de decision architecture : ownership, seuils, capture de preuves, escalade. Qu’il s’agisse d’un outil interne privé ou d’un workflow client sécurisé, les exceptions doivent rester auditées au moment de la décision. (publications.gc.ca)
Ce qui casse lorsque la reflexion reste implicite
Le principal risque est de traiter une sortie fluide comme une decision fiable. Sans seuil, responsable, et contexte partage, le systeme amplifie les exceptions au lieu de les rendre visibles.
Open Architecture Assessment aide a structurer la reflexion avant de generer plus de sorties : decision, contexte, responsabilite, seuil de revue, et prochain mouvement operationnel.