J’avais écrit les règles. Je n’avais pas encore vérifié leurs effets.

Je dirige seul Qognito, une entreprise de conseil et de formation. Pour réaliser certaines activités de mon cœur de métier, je coordonne plusieurs équipes d’agents IA, mes « squads ». C’est ma manière de faire fonctionner une firme minimale : déléguer une partie du travail tout en restant responsable des orientations, des livrables et des engagements pris auprès de mes clients.

La veille sur l’IA alimente ce travail. Une note peut m’aider à actualiser une formation, à examiner le besoin d’un prospect ou à préparer une proposition. Sa valeur tient à ce que je peux en faire ensuite.

Je conserve ces notes dans Obsidian, une application de gestion de connaissances. Des liens internes, les wikilinks, les relient entre elles : je peux retrouver une analyse et la rapprocher d’autres sujets. Ces liens facilitent l’exploration ; ils ne garantissent pas que plusieurs notes apportent des preuves indépendantes. Une erreur peut ainsi devenir un appui pour un raisonnement ultérieur.

J’avais organisé la production avec soin. Un agent prépare la source, un autre rédige l’analyse, un troisième évalue la note. Je décide de sa publication dans ma base. Voici le circuit attendu :

Ce schéma décrit les responsabilités prévues. Il reste à vérifier que les outils respectent ce circuit.

Dans ma formation SAGA-IA, je demande aux décideurs d’examiner ce qu’ils délèguent, les preuves disponibles et le coût du contrôle. J’ai soumis mon propre dispositif à ces exigences. L’audit a commencé par une découverte très simple.

Les règles pouvaient changer avec celui qui les appliquait

Les fichiers qui définissaient les consignes, les critères du juge et les contrôles étaient modifiables par les agents. Celui qui produisait une note avait donc techniquement la possibilité de changer les critères utilisés pour l’évaluer.

Je n’avais pas constaté qu’un agent l’avait fait. Mais la séparation des rôles reposait sur une consigne que les droits d’accès ne faisaient pas respecter.

J’ai fait protéger ces fichiers. Un agent peut proposer une modification ; sa mise en place exige une intervention humaine avec les droits d’administration. Dix tentatives de modification, par des voies différentes, ont ensuite été refusées. Les règles sont restées intactes.

Ces premières corrections précédaient la campagne consacrée aux protections, appelée « Phase A » dans mon audit. Elles avaient déplacé la question : les règles tenaient mieux, mais que pouvait-il encore arriver aux documents sur lesquels je m’appuyais ?

Publier une note ne suffisait pas à la préserver

Au départ, une note rejoignait la base dès sa rédaction, avant le verdict du juge. J’avais ensuite instauré une étape d’attente, puis une autorisation humaine de publication. Le premier cycle réel avait suivi ce circuit : neuf sources traitées, neuf notes examinées et publiées par mes soins.

Pourtant, une note déjà publiée pouvait encore être modifiée. Une source aussi. Le contrôle existant ne repérait pas ces changements. Une approbation donnée hier ne disait donc pas ce que je retrouverais demain.

La Phase A a traité ce problème. Sur une copie de travail, trois altérations volontaires — une note modifiée, une note ajoutée hors circuit et une transcription modifiée — ont été détectées par un nouveau contrôle comparant les documents à une référence conservée. Des verrous ont également été posés sur les notes publiées et les sources préparées.

J’ai accepté une discipline pour moi aussi : plus de retouche directe dans Obsidian. Les changements doivent passer par le circuit prévu et laisser une trace. Sinon, comment distinguer ma correction d’une modification anormale ?

Préserver le contenu ne suffit toutefois pas à le rendre juste. Lors des premiers essais, le juge avait relevé « usually » traduit par « toujours », alors que les contrôles automatiques n’avaient rien signalé. Une nuance devenue certitude peut changer une décision.

Le programme compare les documents ; le juge examine le sens ; je conserve la décision de publication. Cette répartition rend les responsabilités identifiables. Elle ne dispense pas de vérifier la qualité du jugement.

J’ai dû examiner mes propres examens

Un banc d’essai est une répétition sur des cas choisis, dont certains contiennent volontairement des pièges. J’en avais utilisé pour éprouver la veille. Deux constats m’ont obligé à revoir la confiance accordée à leurs résultats.

Le premier concernait le corrigé : les réponses attendues restaient accessibles aux agents. Imaginez un examen dont les candidats pourraient ouvrir les solutions. Cela fragilise l’évaluation, même sans preuve qu’ils les aient consultées. L’accès au corrigé a été protégé, puis son refus éprouvé sur le poste.

Le second concernait les permissions. La copie utilisée pour certains essais était plus restrictive que l’environnement réel. Une action pouvait y demander un accord alors qu’elle passait librement au quotidien. Les résultats décrivaient bien les essais réalisés ; ils ne suffisaient pas à établir la même protection en usage réel.

La dernière étape de la Phase A devait donc réunir les protections dans une épreuve avec les permissions de production. Il fallait observer les tentatives, identifier ce qui les arrêtait et vérifier leurs effets sur les documents.

Vingt tentatives, et une limite qui reste visible

Le 19 octobre, vingt tentatives ont été exécutées et tracées dans les deux environnements d’agents utilisés. Les essais de modification de documents protégés et d’accès au corrigé ont rencontré des refus.

Deux créations de fichiers hors du circuit de publication ont toutefois réussi dans l’un des environnements. Le contrôle les a détectées ; elles ont ensuite été supprimées. La vérification finale a confirmé le retour de la base à son état initial.

Vingt tentatives documentées ne signifient donc pas vingt actions empêchées. Dans le fonctionnement courant, un ajout hors circuit peut rester présent jusqu’au contrôle déclenché par la prochaine publication. Cette limite reste ouverte.

La Phase A est close, avec une réserve précise : le prochain cycle réel doit encore montrer qu’une publication autorisée aboutit à une note effectivement verrouillée. Les refus constatés pendant les essais ne remplacent pas cette vérification de bout en bout.

L’évaluation de qualité menée en parallèle a donné sept cas réussis sur dix, avec une fausse alerte de fidélité et deux cas dont la portée restait à trancher. Protéger les documents n’établit pas que leur contenu s’est amélioré. Un examen rétrospectif des notes publiées reste prévu.

Le temps que le chronomètre ne voyait pas

Pour comprendre le coût de cette maîtrise, il faut revenir au premier cycle réel. L’outil avait enregistré une à trois secondes par publication. J’avais pourtant consacré neuf minutes à relire les neuf notes avant de l’ouvrir. Ce temps a dû être déclaré séparément.

Ces neuf minutes suffisaient à ma décision de publier ; elles ne constituaient pas une comparaison complète de chaque note avec sa source. Une validation humaine doit préciser ce qui a réellement été vérifié et avec quel temps disponible.

La même exigence vaut pour les corrections. Pendant les premiers travaux, j’ai accepté un défaut de recoupement compté deux fois : une seule occurrence avait été constatée, et le script envisagé pour la traiter aurait été coûteux et lui-même faillible. Chaque anomalie ne justifie pas une règle supplémentaire.

J’ai aussi fixé des critères d’arrêt, des responsables et des conditions de réexamen. Ces dispositions devront vivre dans l’usage. À ce stade, je n’ai démontré aucun gain global de rentabilité : la relecture, les reprises, la maintenance et l’audit font partie du coût à apprécier.

Ce que je peux désormais justifier

Le chemin parcouru tient en trois étapes :

Les protections testées apportent des preuves circonscrites. La dernière étape reste à observer.

Je peux mieux expliquer ce que je confie aux agents, ce qui résiste aux tentatives testées et ce qui demande encore un contrôle. Ma responsabilité de dirigeant consiste aussi à décider quelles incertitudes sont acceptables et lesquelles doivent limiter la délégation.

Si vous coordonnez vous aussi une activité avec des agents, mon livre blanc gratuit La facture fantôme de l’IA propose une première lecture sur la supervision, les coûts complets et l’usage du temps gagné.

Pour travailler ces décisions, SAGA-IA — Volume 1 réunit le diagnostic de délégation et l’évaluation de la viabilité économique, avec des cas et des exercices. C’est le prolongement de ce REX : apprendre à justifier ce que l’on engage, les preuves que l’on demande et les conditions auxquelles on poursuivra.