Une responsable des achats prépare un circuit d’approbation pour des logiciels. Au-dessus d’un certain montant, la finance doit intervenir. Une demande contenant des données à protéger passe aussi par la sécurité. Le formulaire semble correct, mais que se passe-t-il si l’agent configure le seuil et oublie la seconde condition dans une autre page de l’outil ? Une démonstration fluide ne permet pas de répondre.
Dans une étude de recherche menée avec Ironclad, OpenAI décrit des tâches où un agent configure des accords, des circuits d’approbation et des clauses réutilisables dans un logiciel contractuel. Les équipes ont défini 11 tâches dans ce périmètre juridique, commercial et achats. OpenAI rapporte un progrès dans sa propre évaluation ; il ne s’agit pas d’un essai indépendant de fiabilité juridique en production.
Écrire la règle avant de lancer l’agent
Si Pulse devait assister une équipe sur ce type de parcours, ce serait d’abord un pilote à concevoir, et non une fonction contractuelle annoncée comme disponible. Une approche possible serait de préparer, à partir des seules règles fictives autorisées, une fiche de vérification : règle d’origine, écrans ou paramètres configurés, cas de contrôle, écarts et personne chargée de la revue. L’agent prépare une configuration dans un environnement de test ; il ne la valide ni ne l’active.
Exemple entièrement fictif — aucune donnée client ni action externe. Pour ses achats internes de logiciels, un cabinet de services veut tester un circuit de validation avant toute utilisation réelle. Les montants et demandes ci-dessous sont simulés ; aucun contrat réel n’entre dans le test.
Fiche de test : règles, cas et verdict
La fiche du test pourrait tenir en cinq lignes :
| Élément à consigner | Exemple de test, écrit avant l’exécution |
|---|---|
| Règle métier | Achat logiciel supérieur à 10 000 € : revue finance ; demande impliquant des données à protéger : revue sécurité, quel que soit le montant. Ce sont des règles fictives, pas des seuils recommandés. |
| Cas d’essai | Une demande fictive à 12 000 € avec données à protéger ; une autre à 8 000 € avec ces mêmes données ; une troisième à 8 000 € sans cette condition. |
| Résultat attendu | Premier cas : finance et sécurité ; deuxième : sécurité ; troisième : ni l’une ni l’autre selon ces seules règles. |
| Sortie de l’agent | Configuration proposée, chemins des paramètres et captures ou export de l’environnement de test ; aucun statut « approuvé » produit par l’agent. |
| Décision humaine | Responsable achats et personnes habilitées vérifient chaque branche, corrigent la règle ou arrêtent le test ; aucune activation sans leur décision explicite. |
Le deuxième cas est le piège utile : un agent qui ne conserve que la règle du montant aura l’air performant sur le premier cas et échouera sur celui-ci. Une règle absente, une branche ambiguë ou une preuve impossible à retrouver doit donner « à vérifier », jamais « conforme » par défaut. Conserver la version des règles, la configuration testée, les écarts et les corrections permet de rejouer le même contrôle ; le retour arrière consiste à désactiver la configuration d’essai et revenir à l’état initial du bac à sable.
Ce que l’étude permet — et ne permet pas — de conclure
Le signal intéressant est méthodologique : traduire des consignes métier en tâches observables et comparer la configuration obtenue à des critères écrits avant le test. Le résultat publié par OpenAI concerne son propre protocole sur un petit ensemble de tâches. Son estimation du temps par tentative ne constitue pas un gain mesuré dans le quotidien d’un service juridique. Ni l’étude ni une belle démonstration ne prouvent la fiabilité générale des agents juridiques, la conformité d’un contrat ou la sécurité d’une mise en production.
La décision prudente est donc à connaître, sans adoption automatique : suivre des évaluations indépendantes, puis essayer seulement des cas réversibles avec des données synthétiques, dans un environnement séparé. Pendant cette vérification, ne confier à l’agent ni vrais contrats, ni pouvoir de validation, ni activation du circuit. Une personne qualifiée confronte les sorties aux règles, accepte, corrige ou rejette ; les écarts et le temps de revue sont mesurés plutôt que présumés.
Cette fiche traite une question plus étroite que le guide général pour tester un employé IA avant production : une règle conditionnelle reste-t-elle vraie jusqu’au dernier écran ? Si votre équipe veut encadrer une première vérification entre documents et outils, demandez un Diagnostic Pulse en précisant la règle métier à tester et la personne qui peut arrêter le pilote.
Source principale : OpenAI, « Advancing computer use with Ironclad » — communication de recherche des partenaires, non évaluation indépendante.