Modèle opérationnel de gouvernance de l'IA : les cinq éléments en action

Ce que fait notre modèle opérationnel de gouvernance de l'IA

Un modèle opérationnel de gouvernance de l'IA est un système de droits de décision, de responsables, d'escalade, de points de validation dans les workflows et de revues qui fixe ce que les agents IA font seuls et ce qui attend une personne. Le nôtre encadre des agents qui agissent : ils trient les demandes, écrivent du code, rédigent des guides et confient du travail à d'autres agents. Ce n'est ni une charte d'usage d'un chatbot pour les salariés, ni une liste d'outils autorisés.

La gouvernance des agents n'est pas un comité. Ce sont cinq éléments écrits là où l'agent les lit avant d'agir, et chacun est un objet concret que vous pouvez ouvrir :

Nous faisons tourner ces cinq éléments sur ConvOps(s’ouvre dans un nouvel onglet), qui contient les tâches, les responsables, les points de validation, les notes et les planifications. Ce guide fait partie de « Loops We Run » ; le guide pilier montre qui décide quoi dans toute l'entreprise.

Les exemples utilisent Copperfern, une boutique en ligne fictive d'articles pour la maison, et Maya, qui en dirige les opérations. Les noms et les chiffres sont inventés ; les noms de champs, les formats de notes, les règles et les seuils sont les vrais.

Cinq éléments, cinq objets : les droits de décision sont une liste d'exclusion, le responsable est un seul nom sur la tâche, l'escalade est une note typée, un point de validation est une approbation dans le workflow, la revue est une planification.

Pourquoi les règles vivent dans le workflow

Une charte encadre les personnes qui la lisent. Un agent n'obéit qu'à ce qui se trouve dans son workflow, et c'est donc là que chaque règle doit vivre.

Nos agents se sont mis à faire du vrai travail : aiguiller, développer, publier, répartir. Les règles vivaient dans un fil de discussion et dans la tête d'une seule personne. Un agent en pleine exécution ne relit pas une page de règles. Quand une tâche déraillait, personne ne pouvait dire quel agent avait pris la décision, pour quelle raison, ni où il aurait dû s'arrêter.

Nous avons donc déplacé chaque règle à l'endroit où l'agent agit. La liste de ce qu'un agent ne doit jamais prendre en charge est entrée dans l'étape qui choisit le travail. Chaque approbation est devenue un point de validation que l'exécution ne peut pas franchir sans un oui. Chaque décision d'agent laisse désormais une raison d'une ligne sur la tâche. La gouvernance n'est qu'une couche du parcours plus large vers un modèle opérationnel IA.

Découvrez comment ConvOps place le point de validation dans le workflow, et non dans un fichier de règles(s’ouvre dans un nouvel onglet).

Comment ça tourne

Le travail entre les points de validation se fait sans nous. Les points de validation sont l'endroit où nous mettons notre attention, et nulle part ailleurs.

Chaque règle a sa raison. L'agent de tri ne change jamais le type d'un travail vers ou depuis une initiative sans le oui de l'opérateur, car le périmètre relève d'une personne. Un lot de répartition contient de 1 à 10 tâches, 5 par défaut, car avec un petit lot, chaque revue reste sérieuse. La requête sur le vivier de candidats ramène jusqu'à trois fois ce maximum, pour que les exclusions laissent encore une liste complète.

Un agent ne s'arrête pour demander que lorsqu'il faut un vrai jugement : accès à la production ou données de production, valeurs secrètes ou rotation des identifiants, dépenses, publication publique, changements de périmètre, et choix entre plusieurs options de correction. Pour tout le reste, il décide, avec la raison écrite. Quand l'opérateur accorde l'autonomie pour une exécution, l'orchestrateur décide en tant que délégué de l'opérateur pour cette exécution seulement, et les notes le précisent.

Les revues suivent un calendrier, pas la mémoire de quelqu'un. Chez Copperfern : « Search check » chaque jour à 5 h UTC, « Product photo ideas » chaque jour à 6 h, « Social post » chaque jour à 16 h, « Weekly planning » chaque lundi à 6 h, et « Monthly research » le 2 de chaque mois à 7 h.

Le tri, l'aiguillage, la rédaction et les passes de relecture tournent seuls ; les exigences, le merge, la publication et la liste des candidats attendent une personne ; les données de production, les secrets, les dépenses et les vérifications sur le site en ligne ne sont jamais confiés à un agent.

La publication attend une personne, sauf si une personne en a déjà décidé autrement pour cette tâche. Le contenu courant, comme les actualités et les traductions, est mis en ligne après la relecture d'un agent distinct, parce que quelqu'un a choisi cette colonne pour la tâche avant même sa première exécution (quelles tâches attendent un oui).

Certaines règles n'ont besoin d'aucun point de validation, parce qu'un hook bloque purement et simplement l'action : voir comment nous empêchons Claude Code de supprimer des fichiers. Les points de validation servent aux décisions qui demandent une personne, et c'est le cœur des systèmes d'IA avec humain dans la boucle.

Un responsable par tâche, pas une matrice RACI

Une matrice RACI répartit une tâche entre quatre rôles. Pour une tâche d'agent, nous enregistrons deux noms : le responsable qui fait le travail, enregistré comme l'unique exécutant sur la tâche, et la personne qui approuve au point de validation. Une tâche refusée reste refusée : nous ne la relançons jamais sur un autre exécutant, et nous ne la répartissons jamais à nouveau tant qu'une exécution précédente peut encore être active. Faire circuler une tâche de main en main masque la raison du refus. Chaque agent a aussi sa ligne dans notre inventaire des agents IA, où la colonne du responsable se trouve à côté de l’interrupteur d’arrêt qui l’arrête.

Une exécution, étape par étape : une modification, deux oui

La partie utile d'une modification encadrée n'est pas le code. Ce sont les deux moments où une personne dit oui, et la ligne de raisonnement que l'agent laisse derrière lui.

Maya demande « une option d'emballage cadeau au moment du paiement ». Voici cette demande, du déclencheur au verdict :

Le gel de l'étape 5 est strict. Les étapes suivantes n'ajoutent, ne retirent ni ne réinterprètent jamais une exigence. Un changement de périmètre repart à l'étape des exigences pour une nouvelle approbation, si bien que les règles du jeu ne changent jamais après le oui.

La vérification rouge de l'étape 7 n'arrive jamais à Maya sous forme de question. Le workflow de correction s'exécute, et le verdict est surveillé à nouveau sur le nouveau pipeline. Un agent ne certifie jamais sa propre correction, et un pipeline rouge bloque le point de validation du merge.

À l'étape 9, le merge exige à la fois un pipeline vert et une approbation explicite. L'approbation vient de Maya, ou de sa délégation écrite quand elle a accordé l'autonomie pour cette exécution. Sans elle, la tâche reste bloquée au point de validation et le tableau la montre en attente d'une personne. Les verdicts d'acceptation qu'elle lit viennent d'une série de tests dans le navigateur, décrite dans notre guide des tests d'acceptation.

La tâche conserve la raison de l'aiguillage, les deux validations franchies et l'historique de la CI.

Une modification, deux oui : l'agent aiguille la tâche d'emballage cadeau, Maya approuve les exigences figées, une vérification rouge passe par une correction, puis Maya ou sa délégation écrite approuve le merge.

La liste d'exclusion et l'historique de la tâche

Écrivez la liste de ce qu'un agent ne doit jamais prendre en charge avant la liste de ce qu'il peut faire. C'est dans la liste d'exclusion que la gouvernance vit réellement.

La liste de répartition

Une exécution de répartition part d'une seule ligne de critères :

criteria: horizon=now; complexity=S; executor=coding-agent; max=5; project=shop; type=task,bug

L'agent construit ensuite deux tableaux. Les tâches retenues indiquent pourquoi chacune convient. Les tâches exclues indiquent la règle qui les a exclues. Une tâche est exclue quand :

• une exécution active ou déjà répartie existe pour elle
• elle attend un point de validation de l'opérateur
• elle a besoin de l'opérateur ou d'un accès direct à la production
• elle porte l'étiquette manual-qa, production-release, mr-review ou ui-review
• elle n'a pas de critère de fin concret
• elle est bloquée, ou enfant d'une tâche bloquée
• l'exécutant ne peut pas atteindre ce dont il a besoin

Chez Copperfern, « Rotate the payment provider key » (« renouveler la clé du prestataire de paiement ») est exclue pour valeurs secrètes, et « Check the Spanish checkout on the live site » (« vérifier le paiement en espagnol sur le site en ligne ») est exclue comme QA manuelle. Le message du point de validation indique « Approve the candidate list (or trim it) before anything is dispatched. » (« Approuvez la liste des candidats, ou réduisez-la, avant toute répartition. »). Un refus renvoie l'exécution aux critères.

La liste de répartition garde trois tâches avec la raison de chacune et en exclut deux avec leurs raisons ; Maya approuve la liste avant qu'un agent ne démarre.

L'historique de la tâche

Chaque événement encadré est une ligne typée sur la tâche :

Lisez l'historique de haut en bas. Le relecteur lit l'objet produit, pas le résumé de l'exécutant : chaque bloc du diff, avec les tests concernés relancés. Une ligne changes requested arrête l'exécution, et la même session reprend avec le constat. Un refus dont la raison n'est pas connue, comme une erreur inconnue, devient une tâche de bug : l'escalade aboutit ainsi à une tâche suivie plutôt qu'à un message dans un chat.

Quatre lignes de notes sur une tâche : répartie, modifications demandées, approuvée, terminée avec la merge request 14.

Ce qui tourne mal

Les échecs qui méritent d'être racontés sont les échecs silencieux. Une tâche qui cesse de tourner et un filtre qui ne renvoie rien ressemblent tous deux à « tout va bien ».

Une tâche quotidienne qui ne se déclenchait plus

L'une de nos tâches quotidiennes a cessé de se déclencher. Son historique d'exécution ne montrait que des succès, car une exécution qui ne démarre jamais ne peut pas échouer.

La couche de planification l'a repérée. Une planification est signalée missed, avec la raison « No run for too long » (« aucune exécution depuis trop longtemps »), quand le temps écoulé depuis sa dernière exécution dépasse 1,5 fois l’intervalle normal le plus long de sa règle. Pour une tâche quotidienne, cela fait 36 heures. Un déclenchement sauté ne compte pas comme une exécution. Le signalement indique la date du début du silence et un lien « Open schedule » (« ouvrir la planification ») vers la correction. Le rythme de revue signale ainsi son propre trou au lieu de se taire.

La page des planifications de ConvOps signale Product photo ideas avec « No run for too long » alors que la section Up next l'affiche encore pour aujourd'hui.

Un filtre qui ne renvoyait rien

Lors de notre première exécution de répartition, la requête des candidats cherchait les tâches pas encore réparties en niant un champ de statut. Ce champ est vide sur toute tâche qui n'a jamais été répartie. Un filtre négatif sur un champ vide écarte la ligne : la requête renvoyait donc une liste vide alors que des tâches correspondantes attendaient dans le backlog. Aucune erreur, et une liste vide se lit exactement comme « rien à faire ».

La règle qui en est sortie : ne jamais nier un champ qui peut être vide ; filtrer sur ce que l'on veut, pas sur ce que l'on ne veut pas. Elle est écrite dans l'étape qui choisit les candidats : « Ne jamais filtrer sur execution_status, executor ni aucun autre champ nullable avec ne / nin / NOT. » Le défaut lui-même a été enregistré comme tâche de bug. La règle vit dans l'étape, elle tient donc quel que soit le comportement du moteur de requêtes. C'est ainsi qu'un échec devient une règle dans toutes nos boucles.

Construisez le vôtre

La gouvernance des agents IA d'une petite entreprise commence par une page et un point de validation. Une petite entreprise n'a pas besoin d'un comité. Elle a besoin d'un responsable sur chaque tâche.

La version d'une page à copier :

AI governance operating model: <company>
Reviewed: <date>    Page owner: <name>

1. Decision rights
   Runs alone:          triage, routing with a one-line reason, drafting, review passes
   Waits for a person:  frozen requirements, merge, publish, the dispatch list
   Never delegated:     production data, secret values, spend, live-site checks
   Stop and ask:        production, secrets, spend, publishing, scope, a choice of fixes

2. Owners
   <job>   owner: <one agent or person>   approver: <person>

3. Escalation
   refused: <job>: <message, verbatim>    unknown reason: open a bug task
   stalled: <job>: <reason>               tell <person>; never dispatch again while alive

4. Gates
   Requirements: <person> approves, list frozen
   Merge or publish: green check AND <person> or their written delegation

5. Reviews
   <job>   <cadence>   missed after 1.5 times the longest normal gap

Remplissez-la pour les tâches que vos agents font déjà. Le premier point de validation à ajouter est celui qui précède toute mise en ligne.

Placez votre premier point de validation dans un workflow avec un compte ConvOps gratuit(s’ouvre dans un nouvel onglet). Vous voulez le mettre en place dans votre entreprise ? Réservez une séance de découverte gratuite.