Travailler avec l'IA : j'ai commencé par écrire qui décide de quelle règle
10 octobre 2026 · Aliocha Iordanoff
Je dirige Sémawé, une société d’accompagnement des organisations, et Heterostasia, sa société sœur, qui accompagne les organisations dans leur transition vers l’intelligence artificielle. J’ai aussi écrit un livre sur l’Holacratie, un mode de gouvernance où l’autorité est répartie entre des rôles écrits, chacun avec son périmètre. Je travaille chaque jour avec des agents d’IA, pour la gestion de nos entreprises, nos propositions commerciales, nos outils internes et l’écriture. Ce texte raconte comment j’organise ce travail, et pourquoi j’ai fini par l’organiser comme on organise une gouvernance.
Des consignes accumulées que l’IA appliquait parfois dans une version périmée
Au début, je faisais comme la plupart des utilisateurs que je rencontre. Chaque fois que l’IA se trompait, j’ajoutais une consigne (ne pas employer tel mot, vérifier tel chiffre avant d’écrire, demander avant d’envoyer un message). Ces consignes s’ajoutaient dans des fichiers de contexte, dans les instructions de chaque projet, dans les outils eux-mêmes.
Avec le temps, j’ai eu de plus en plus de mal à m’assurer que nos règles étaient appliquées. J’étais persuadé d’avoir mis une règle en place, et je constatais qu’elle était appliquée de façon inégale selon les projets et les outils. J’avais la sensation, assez énervante, de devoir répéter sans cesse les mêmes consignes. En cherchant pourquoi, j’ai compris que les consignes elles-mêmes avaient divergé. Une même règle existait à plusieurs endroits sous des formulations différentes, certaines versions avaient évolué pendant que d’autres restaient figées, et l’IA appliquait la version qu’elle avait lue, avec la même assurance, qu’il s’agisse de la bonne ou de l’ancienne. Une règle de facturation que j’avais corrigée dans notre référentiel continuait ainsi d’être appliquée sous sa forme précédente par un outil qui en gardait une copie, parce que rien ne reliait la copie à l’original.
Il y avait aussi un coût invisible. Tout ce qui entre dans le contexte d’une IA au début d’une session se paie, en temps de calcul et en attention du modèle, donc en tokens. À force d’ajouter des consignes, chaque session commençait par la lecture d’un long document dont la plupart des consignes ne concernaient pas la tâche du moment. Les modèles traitent mieux un contexte concis et pertinent qu’un contexte long où l’utile se perd dans le reste. Or la méthode intuitive incrémentale que j’ai utilisée pendant des mois a produit cet effet négatif.
Pour chaque règle, le rôle qui en décide et la règle qui prime sur elle
Un article précédent de ce blog, Qui gouverne l’IA quand elle agit à votre place ?, posait la question de savoir qui, dans une organisation, peut affirmer quoi et avec quelle autorité. Dans cet article, je vous raconte comment j’ai transposé ce questionnement à l’ensemble de mes référentiels et des consignes que je donne pour mes idées, et pas uniquement à titre personnel, mais pour que ces référentiels s’appliquent à tout un travail d’équipe.
L’Holacratie m’a donné le cadre qui a rendu ce travail particulièrement simple à réaliser. Dans une organisation holacratique, une décision appartient au rôle dont c’est la fonction, et si cette décision est soumise à un contrôle de qui que ce soit, c’est le domaine d’un rôle qui est écrit quelque part. J’ai appliqué le même principe aux règles données à une IA. Une règle de facturation relève du rôle responsable de la gestion financière, une règle de style du rôle responsable de la ligne éditoriale, une règle de sécurité de celui qui en répond juridiquement. Quand deux règles se contredisent, leur rang dans cette hiérarchie décide de qui a le droit de modifier quel référentiel, quelle que soit la règle la plus récente.
Pour établir cette hiérarchie des contextes d’IA, j’ai réuni mes associés un après-midi autour d’une grande feuille de papier. Chaque règle y était un carré, chaque outil un rond, et une flèche signifiait « est soumis à ». La question qui a servi de test pendant tout l’atelier était celle-ci : si je confie cette tâche à une automatisation, quelles règles dois-je lui demander de respecter, et qui a le droit de les changer ? Plusieurs liens que nous avions tracés par habitude ne passaient pas ce test, et de nouvelles prises de conscience ont émergé. Une convention de formation, par exemple, n’a pas à vérifier que le client correspond à notre profil de client idéal, parce que cette vérification a eu lieu plus tôt, au moment de la proposition commerciale.
L’atelier a aussi fait apparaître des règles que l’IA appliquait sans qu’elles soient écrites nulle part. Une associée a formulé une demande qui résume l’intention de tout ce travail, en souhaitant que l’IA, quand elle refuse de faire quelque chose, dise quelle règle l’en empêche et quel rôle en est responsable. L’IA ne peut répondre à cela que si la règle a une source et un responsable identifiés.
Une seule source par règle, et des renvois partout ailleurs
La première conséquence pratique est une discipline d’écriture. Chaque règle ne doit être écrite qu’à un seul endroit, choisi en fonction de son autorité sur l’ensemble du système de l’entreprise. Par exemple, le référentiel tarifaire pour un prix, la doctrine fiscale pour la TVA, la charte éditoriale pour le vocabulaire. Partout ailleurs, on ne recopie pas la règle, on indique où aller la lire. Le fichier d’instructions d’un projet dit « pour les prix, lire le référentiel tarifaire, section 3 », et il ne contient plus aucun prix.
Cette règle paraît évidente, et pourtant, avec un usage intuitif où chacun donne des consignes à sa propre IA, ça n’est pas du tout ce que les IA ont construit. On avait des réplications multiples d’informations très dispersées. Recopier une consigne va plus vite qu’écrire un renvoi, et la copie fonctionne le jour où on la fait. Donc, sur le moment, c’est souvent la méthode la plus facile et la plus intuitive. Le problème, c’est qu’elle diverge ensuite silencieusement, dès la première modification de l’original. Quand nous avons recensé nos règles, une même consigne de typographie apparaissait par exemple dans des fichiers que plus personne ne relisait, et chacun en donnait une version un peu différente.
C’est cette mécanique qui explique que l’IA peut parfois vous apporter des réponses complètement absurdes, ou vous faire faire des choses d’une manière particulièrement bureaucratique, qui perd de vue l’objectif que vous vous étiez donné en travaillant.
Des règles unitaires que chaque tâche charge selon ses besoins
La deuxième conséquence concerne la taille des documents. Un référentiel de trente pages contient des dizaines de règles qui n’ont pas le même champ d’application, puisque certaines valent partout, d’autres pour un seul type de document, d’autres encore pour une seule étape d’un travail. Le charger en entier pour chaque tâche revient à faire relire tout le règlement intérieur avant chaque réunion.
J’ai donc découpé les référentiels en règles unitaires. Chaque règle a un identifiant, un endroit unique où elle est écrite et un mode de chargement, qui peut être systématique, limité à un projet, déclenché par une tâche précise ou laissé à la demande. Elle est contrôlée par un rôle qui en assume la responsabilité. L’ensemble forme une sorte de nuage de règles dans lequel chaque tâche prend ce qui la concerne. Quand l’IA rédige une fiche de mon prochain livre, elle charge les règles de style et de structure de la charte du livre, désignées par leurs identifiants, et ignore les règles de facturation ou de l’organisme de formation.
Ce découpage a eu un effet inattendu. En le faisant, j’ai vu qu’une grande partie des consignes du contexte commun à toute l’équipe étaient déjà écrites ailleurs, dans un référentiel ou dans un outil. Ce contexte commun, chargé dans chaque session de chaque associé, s’est finalement réduit à l’identité de l’entreprise, à quelques règles absolues et aux renvois vers les sources. Les sessions démarrent plus vite et coûtent moins cher en tokens. Je n’ai pas de mesure rigoureuse des erreurs évitées, mais celles qui venaient d’une consigne mal placée ou périmée deviennent plus rares.
Des étapes séparées par un fichier que je relis et corrige
Pour les travaux longs, je découpe le travail en étapes courtes, et chaque étape se termine par un fichier lisible. Le livre que j’écris en ce moment, un recueil de fiches pratiques sur l’Holacratie, en donne un exemple. Chaque fiche passe par quatre étapes, un cadrage (l’angle, les passages de mes sources à mobiliser, ma position d’auteur), une rédaction, un contrôle, puis une reprise de la voix. Entre deux étapes, le fichier produit m’appartient. Je le relis, je le corrige, je raye ce qui ne me ressemble pas, et l’étape suivante repart de ma version corrigée.
Cette organisation rend la répartition des responsabilités lisible. Je garde la voix et les décisions, c’est-à-dire l’angle, ce que je pense et ce que je refuse d’écrire. L’IA exécute, contrôle et me signale ce qui s’écarte des règles. Le même découpage sert pour une proposition commerciale ou pour une investigation de fond. Il me semble utile dès qu’un travail est séquentiel, relu par une personne et répété avec des entrées différentes.
D’autres arrivent à des intuitions voisines par un autre chemin. La méthode Interpretable Context Methodology, publiée par Jake Van Clief, organise elle aussi le travail d’un agent en étapes reliées par des fichiers que l’humain peut corriger. Sa limite, cependant, est qu’elle ne dit pas qui a autorité sur une règle ni laquelle prime, ce qui est pour moi le point de départ. C’est le défaut de beaucoup de systèmes très ingénieux qui ont été conçus sur l’IA par des gens qui travaillent de manière individuelle. La limite, c’est que ces systèmes sont très difficiles à transposer dans un travail d’équipe.
Les vérifications mesurables confiées à un script
Une partie des règles se vérifie mécaniquement, comme la présence de chaque section prévue par le gabarit d’une proposition commerciale, la longueur d’un texte, l’absence de certains mots ou d’un tiret cadratin dans un texte public. Pour ces règles, j’ai arrêté d’ajouter des consignes. Un script les contrôle et refuse de laisser passer le texte tant qu’un écart subsiste.
Au premier passage du script de contrôle sur les fiches du livre déjà rédigées, il a trouvé deux fiches hors gabarit. Elles avaient été relues plusieurs fois, par moi et par l’IA, sans que personne le remarque, et notamment pas moi en tant que rédacteur. Un relecteur humain s’habitue à ce qu’il voit, et une IA à qui l’on demande de vérifier le gabarit le fait avec la même attention variable que pour le reste. Un script vérifie la même chose à chaque passage. Il ne remplace pas la relecture pour autant, car la densité d’un texte, la justesse d’un exemple et la voix restent à juger par moi.
Le principe s’applique au-delà du livre. Plusieurs de mes outils refusent une action contraire à une règle, qu’il s’agisse d’écrire un texte public qui contient un tiret cadratin, de publier dans notre messagerie interne un message sans la mention indiquant qu’il a été rédigé avec une IA, ou de demander un code d’accès à une personne au lieu de le lire dans le coffre prévu pour cela. Chacun de ces verrous est né d’une erreur qui s’était répétée malgré la consigne. Quand une erreur revient alors que la règle est écrite, j’en déduis qu’il faut un verrou plutôt qu’une consigne de plus.
Une décision devient une tâche suivie, une question se règle tout de suite
Une dernière règle concerne ce qui reste à faire. Dans un travail avec l’IA, il est facile de laisser des intentions dans un texte, sous la forme d’un « à vérifier plus tard » ou d’une « décision à prendre ». Ces lignes se perdent dans des documents que personne ne rouvre. Chez nous, une action décidée devient une tâche dans notre outil de gestion, avec un responsable et un projet de rattachement, et l’IA la crée elle-même au moment où la décision est prise.
Les questions suivent une règle similaire. Quand l’IA rencontre un choix qui m’appartient, elle me le présente sous la forme d’une question fermée, avec sa recommandation, et j’y réponds tout de suite. Une question mise de côté dans une note devient une décision que personne ne prend, et le travail qui en dépend attend sans que personne le sache. Pour les décisions que je n’ai pas le temps de prendre tout de suite ou qui sont trop complexes, elles sont notées dans notre système de gestion, dans une rubrique qui inventorie en permanence toutes les décisions qui sont en attente.
Une organisation exigeante à construire et à maintenir
Cette organisation a un coût. Écrire qui décide de chaque règle oblige à poser des questions que l’on préférait laisser dans le flou, et certaines restent ouvertes, puisqu’une partie de nos règles attend encore que soit désigné le rôle qui en sera responsable. Maintenir une source unique demande de la vigilance à chaque modification, parce que la tentation de recopier revient à chaque fois. L’exercice ne se fait pas seul non plus, et l’atelier avec mes associés a montré des règles que je croyais claires et que chacun comprenait différemment.
Je crois pourtant que c’est la condition pour travailler avec des agents d’IA sans passer ses journées à relire leurs productions. Une organisation qui a rendu ses règles explicites, avec leur source et leur autorité, donne à ses IA un contexte plus court et plus juste, et permet à chacun de comprendre pourquoi une IA a agi comme elle l’a fait. J’ai d’abord fait ce travail d’explicitation chez nous. C’est celui que je mène désormais avec les dirigeants qui veulent l’entreprendre dans leur organisation, en commençant par un diagnostic IA et contextes organisationnels.