La thèse en une phrase : une politique qu’on ne peut pas exécuter n’est pas une politique, c’est une décharge de responsabilité. Elle sert à être montrée en audit et ne sert pas à changer ce que le système fait mardi après-midi. La différence entre les deux ne tient pas à la rigueur de l’écriture : elle tient à savoir si quelqu’un a traduit chaque phrase en une condition qu’une machine peut vérifier avant de laisser sortir une action.
Une politique d’usage de l’IA en entreprise qu’on ne peut pas exécuter n’est pas une politique
Le schéma se répète dans toutes les boîtes qui ont dépassé la phase enthousiasme. Quelqu’un rédige la politique d’usage de l’IA en entreprise — six pages, bien écrites, relues par le juridique —, on la met sur l’intranet, on l’annonce par mail et on considère le sujet clos. Trois mois plus tard des agents écrivent à des clients, engagent des montants et publient des affirmations sur le produit, et aucune de ces actions ne passe par quoi que ce soit qui ressemble à ce que dit le document. Pas parce que quelqu’un l’enfreint exprès : parce que le document n’a jamais été branché à rien.
Le genre est saturé de la partie facile. Il y a des modèles, des checklists et des guides sur ce qu’il faut documenter : périmètre, rôles, usages interdits, classification du risque, responsable. Tout ça est nécessaire et aucun de ces textes n’explique la partie qui coûte, la voici : comment cette phrase écrite en français devient une vérification qui tourne en production et qui peut arrêter une action. Ce saut, c’est le vrai travail, et c’est celui qu’on ne fait presque jamais.
Autant le dire sans détour, parce qu’il y a de l’argent en jeu : une politique qui n’existe qu’en PDF ne te protège de rien, sauf, avec de la chance, d’une partie de la responsabilité. Elle n’évite pas l’erreur, ne la détecte pas et ne laisse aucune trace qu’on a essayé de l’éviter. Si tu veux que l’IA se tienne, il faut descendre le document de trois crans : du principe à la règle, de la règle à la condition vérifiable, et de la condition à la preuve.
Étape 1 : décomposer l’obligation en conditions vérifiables
Prends chaque phrase de la politique et pose-lui une seule question : qu’est-ce qui devrait être vrai, dans une action concrète, pour que cette phrase soit respectée ? Si la réponse est longue, ambiguë ou dépend du jugement de celui qui regarde, la phrase n’est pas encore une règle : c’est une intention. Il faut la couper jusqu’à ce que chaque morceau se vérifie par oui ou par non.
Un exemple classique. « L’IA sera utilisée de façon transparente avec les clients » ne se vérifie pas. Décomposée, elle devient trois conditions qui, elles, se vérifient : dans toute conversation lancée par un système automatique, le premier message déclare que c’est un système automatique ; sur tout canal où le client peut demander une personne, il existe un chemin visible pour le faire ; et aucun message n’affirme ni ne laisse croire qu’il est écrit par une personne précise de l’équipe. Trois conditions, trois vérifications possibles. Le principe d’origine est toujours là, mais on peut maintenant le câbler.
Deux avertissements sur cette étape. Le premier : la décomposition, c’est là que se prennent les décisions difficiles, pas dans la rédaction du principe. « Transparent » donne l’impression qu’on est tous d’accord ; « le premier message déclare que c’est un système automatique » ouvre une vraie discussion sur le marketing, la conversion et le ton. Cette discussion, il faut l’avoir, et l’avoir ici coûte beaucoup moins cher que de l’avoir après un incident. Le second : si une obligation ne se décompose pas en conditions vérifiables, écris-le aussi. Certaines obligations ne se tiennent qu’avec du jugement humain, et les marquer comme telles est une information utile, pas un échec.
Étape 2 : décider avec quelle preuve on vérifie chaque condition
Une condition sans preuve assignée est une condition que personne ne vérifie. Et c’est là qu’apparaît le biais qui ruine la plupart des tentatives : si la preuve est choisie par celui qui doit l’implémenter, il prendra celle qui est facile à obtenir, pas celle qui démontre vraiment la conformité. C’est humain et c’est prévisible, donc ça se corrige par la conception.
Pour chaque condition il faut fixer trois choses : quelle donnée la démontre, à quel moment on regarde et qui répond si elle manque. La preuve peut être très simple — le texte du premier message envoyé, le montant du champ de l’opération, la liste des sources que le système a utilisées pour rédiger —, et plus c’est simple, mieux c’est : une vérification qui ne marche que si tout le pipeline est sain n’est pas une vérification, c’est un espoir.
Le moment compte autant que la donnée. Vérifier avant d’exécuter — le système s’arrête et il ne se passe rien — n’a rien à voir avec vérifier après — le système agit et tu l’apprends. Les deux sont valables et ne coûtent pas la même chose. La règle pratique : tout ce qui est irréversible ou visible par le client se vérifie avant ; le reste peut se vérifier après, à condition qu’il y ait quelqu’un qui regarde le registre et un délai écrit pour le regarder. Les mécanismes qui rendent ça possible — registre, permissions à périmètre, frein de secours et audit — sont développés dans la gouvernance et le contrôle de l’automatisation par IA ; ce qu’on ajoute ici, c’est l’étage du dessus : quoi vérifier et pourquoi, pas avec quoi.
Étape 3 : définir ce qui se passe quand ça échoue
C’est l’étape que presque personne n’écrit et la seule qui décide si le contrôle existe pour de vrai. Une vérification sans conséquence définie finit toujours au même endroit : une alerte sur un tableau de bord que personne n’ouvre. Pour chaque condition il faut décider, à l’avance, une réponse parmi quatre : on bloque l’action, on escalade vers une personne avec le dossier déjà monté, on enregistre et on laisse passer, ou on dégrade vers une version plus prudente de la même action.
Choisir « bloquer » pour tout est aussi mal conçu que choisir « enregistrer » pour tout. Tout bloquer rend le système inutile et l’organisation apprend très vite à le contourner ; tout enregistrer produit une archive parfaite de manquements que personne n’a lue. La question qui ordonne le choix est toujours la même : combien coûte l’erreur et en combien de temps elle se voit. Erreur chère et visible, escalader. Erreur chère et invisible, bloquer. Erreur pas chère et visible, enregistrer. Et une condition en plus qu’on oublie : la réponse « escalader » n’est légitime que s’il existe une vraie capacité humaine pour absorber ce volume. Si tu escalades plus de cas que ton équipe ne peut en regarder, la file s’approuve en bloc sans lecture, ce qui est pire que de ne pas avoir de contrôle, parce qu’en plus ça fabrique une fausse trace de relecture. C’est exactement le problème qu’on traite dans la supervision humaine de l’IA à l’échelle.
Trois exemples concrets et pas chers pour commencer
Pas besoin de câbler toute la politique pour que l’exercice paye. Trois contrôles bien choisis couvrent l’essentiel du risque réel d’une boîte qui démarre, et les trois s’implémentent en jours, pas en trimestres.
- Prévenir que c’est une IA. Condition : toute conversation lancée ou tenue par un système automatique déclare qu’elle l’est dès le premier message. Preuve : le texte envoyé. Moment : avant l’envoi. Échec : on bloque l’envoi. En plus d’être la bonne chose à faire, depuis le 2 août 2026 il existe une obligation de transparence européenne applicable aux systèmes destinés à interagir directement avec des personnes, qui doivent être conçus de façon que la personne sache qu’elle interagit avec une IA, sauf si c’est évident. Source : Commission européenne, Transparency obligations under Article 50 of the AI Act (règlement (UE) 2024/1689), consulté le 14 septembre 2026. À regarder avec ton conseil : le périmètre et la qualification qui te concerne — fournisseur ou déployeur — dépendent de ton cas, et ceci n’est pas un conseil juridique.
- Plafond de montant qu’un agent peut engager. Condition : aucune action qui engage de l’argent ne dépasse le seuil fixé par opération et par jour. Preuve : le montant du champ, plus un cumul quotidien. Moment : avant d’exécuter. Échec : escalade vers une personne avec le dossier monté. C’est le contrôle le moins cher de tous et celui que le plus de monde découvre tard, en général après la première frayeur.
- Affirmations qui exigent une source approuvée. Condition : tout message au client qui contient une donnée de produit, un prix, un délai ou une condition s’appuie sur une source d’une liste approuvée. Preuve : les sources que le système a récupérées pour rédiger. Moment : avant l’envoi. Échec : on dégrade — le système envoie une réponse sans cette donnée et propose un transfert — au lieu de bloquer, ce qui serait ici exagéré.
Regarde ce qu’ils ont en commun : les trois tiennent en une ligne, les trois ont une preuve évidente et les trois ont une conséquence différente. Cette asymétrie est le signe que l’exercice a été bien fait. Si les trois finissaient sur « bloquer », c’est que personne ne s’est arrêté pour penser au coût de chaque erreur. Le périmètre de ce que l’agent peut toucher pour commencer est une autre décision du même exercice, et elle est dans quelles permissions donner à un agent IA.
L’erreur chère : laisser l’ingénierie écrire la politique toute seule
Quand la traduction de la politique en contrôles est déléguée entièrement à l’équipe technique, il se passe quelque chose de parfaitement raisonnable et de parfaitement faux : on finit par vérifier ce qui est facile à vérifier, pas ce que la politique impose. Le résultat a bonne allure — il y a des règles, des registres, des tableaux de bord — et laisse dehors précisément ce qui compte le plus, parce que ce qui compte le plus n’est presque jamais le plus mesurable.
Ça se voit dans les petits détails. On vérifie que le message ne dépasse pas une longueur, pas qu’il ne promet pas un délai que tu ne peux pas tenir. On vérifie que la réponse cite une source, pas que la source est approuvée. On vérifie que l’opération a un montant, pas que ce montant respecte la limite décidée un jour en comité. Chacune de ces vérifications est correcte et aucune n’est celle que la politique demandait.
L’antidote est un antidote de process, pas de technologie : la décomposition de l’étape 1 est faite par le propriétaire de l’obligation — métier, juridique, opérations — et la preuve de l’étape 2 se négocie entre cette personne et celui qui va l’implémenter. L’ingénierie a un droit de veto sur l’impossible, pas sur l’inconfortable. Et le document final se signe des deux côtés, avec une date. Sans cette signature croisée, ce que tu as n’est pas une politique exécutable : c’est la liste de ce qu’il a été confortable de mesurer.
Il y a aussi une nuance d’ordre à respecter, et elle va contre ce qui paraît évident : la politique ne s’écrit pas en premier. Elle s’écrit quand tu sais déjà ce que tu régules, et ça tu le découvres en regardant ce que tes gens font déjà avec l’IA sans demander la permission — l’argument complet est dans pourquoi interdire le shadow AI ne marche pas. Une politique rédigée avant cet inventaire régule une entreprise imaginaire.
À quoi ressemble une politique exécutable quand elle est finie
Ça ne ressemble pas à un document juridique. Ça ressemble à un tableau, et ça tient sur une page par domaine. Chaque ligne a six colonnes : l’obligation dont elle sort, la condition vérifiable, la preuve, le moment où on regarde, ce qui se passe si ça échoue, et qui répond. En dessous, une liste à part avec les obligations que tu as décidé de ne pas automatiser et qui dépendent donc d’une personne, avec son nom et sa cadence de relecture.
Ce tableau a une propriété que le PDF n’a pas : il s’audite contre la réalité. Tu prends une ligne, tu prends un cas de la semaine dernière et tu vérifies si la condition a été évaluée, avec quelle preuve et ce qui s’est passé. Soit le registre sort, soit la ligne est un mensonge. C’est un test de cinq minutes et c’est la seule façon honnête de savoir si ta politique d’usage de l’IA en entreprise est vivante ou décorative.
Et il en a une autre : il vieillit de façon visible. Quand une obligation change, une ligne change et on voit quels contrôles il faut toucher. Quand le PDF change, rien ne change, parce qu’il n’était branché à rien. C’est pour ça que le livrable qu’on laisse dans Adoption IA pour les équipes n’est pas le document : c’est ce tableau, avec un propriétaire et une date de révision, et les contrôles du premier tronçon déjà montés. Le document reste nécessaire — il faut pouvoir le montrer —, mais c’est la conséquence du travail, pas le travail.