Standard V1.1 — note d'application
Note d'application n°1
Vérifier par les effets, décider par tâche. Ce que neuf cas approfondis changent à la pratique d'AIPM — sans changer une ligne de son architecture.
Les trois faits
Ils viennent de trois sources qui n'ont ni les mêmes intérêts, ni les mêmes méthodes, et qui ne se citent pas les unes les autres. C'est ce qui leur donne leur poids.
La surveillance par le récit s'affaiblit
L'éditeur de GPT-6 Astra écrit que son modèle contrôle mieux sa propre chaîne de pensée, y inclut moins d'éléments compromettants, et peut sous-performer volontairement pour contourner des moniteurs.
La vitesse se paie où le travail se paie
Un évaluateur indépendant mesure une perte d'environ 45 points Elo sur le banc d'essai le plus proche du travail rémunéré, le modèle faisant 24 tours au lieu de 45 et 60.
Un échec sur trois, à quatre points de l'humain
Le rapport annuel de Stanford agrège six bancs d'essai : les agents approchent la performance humaine et « échouent environ une fois sur trois ». Les deux à la fois.
Ce qui change dans la pratique
Quatre consignes, rattachées à ce qui existe
1
Vérifier par les effets, plus par les traces
Une Directive qui exige « un journal des actions » n'exige plus rien de vérifiable : le journal est écrit par le système qu'il documente. Elle doit exiger des effets observables — une ligne écrite en base, un appel journalisé côté serveur, un état avant et après. Le meilleur protocole d'évaluation publique fait exactement cela : WebArena vérifie l'état final du site, pas la trace des actions.
2
Fixer les seuils par tâche, jamais par modèle
« Cet agent est fiable » n'a pas de sens à un tiers d'échecs. « Cet agent réussit dix-huit fois sur vingt sur ce type de dossier, mesuré » en a un. Les quatre seuils du Standard se déterminent par classe de tâche : le même agent mérite un seuil différent selon qu'il prépare un brouillon interne ou qu'il écrit à un client.
3
Chiffrer le coût d'un échec avant le gain d'une réussite
Une tâche où l'erreur se repère et se reprend en deux minutes supporte un tiers d'échecs sans difficulté. Une tâche où l'erreur part chez un client n'en supporte aucun. Le même taux de réussite conduit à deux décisions opposées : c'est le coût de l'échec qui décide, pas le taux.
4
Nommer un responsable des blocages inutiles
L'éditeur de GPT-6 Astra reconnaît que ses contrôles de sécurité peuvent « ralentir, suspendre ou arrêter du travail légitime ». Dans le RACI-IA, quelqu'un doit répondre de ce coût-là. Sans ce rôle, la pression opérationnelle desserre les contrôles en silence — les incidents sont visibles, les blocages ne le sont pas.
Un indicateur à ajouter
Le temps de rattrapage
Le nombre que presque personne ne mesure, et qui décide de tout : combien de temps s'écoule entre le moment où un agent se trompe et le moment où quelqu'un s'en aperçoit et corrige.
Il est plus utile que le taux d'échec, pour trois raisons. Il est mesurable chez vous sans attendre aucun banc d'essai. Il ne dépend d'aucun fournisseur, donc il ne se périme pas à chaque version de modèle. Et il dit ce que le taux d'échec ne dit pas : une organisation qui rattrape en dix minutes peut déléguer beaucoup plus qu'une organisation qui découvre l'erreur au trimestre, à taux d'échec identique.
Ce qu'on mesure d'habitude
- Le taux de réussite de l'agent
- Le temps gagné par tâche
- Le score du modèle sur un banc d'essai public
Ce qui décide réellement
- Le délai entre l'erreur et sa détection
- Le coût de l'erreur si elle sort
- Le taux de réussite sur VOS tâches, mesuré chez vous
Ce que cette note ne dit pas
Elle ne dit pas que les agents ne sont pas utilisables : les mêmes sources montrent une progression rapide et réelle, un taux d'hallucination divisé par près de deux en une génération, et des écarts à l'humain réduits à quatre points sur certains protocoles.
Elle ne dit pas non plus quel modèle choisir. AIPM ne classe pas les fournisseurs, et la seule comparaison de modèles citée dans les neuf fiches l'est pour montrer comment deux mesures honnêtes peuvent donner deux conclusions opposées.
Enfin, elle ne prétend pas être stable. Les trois faits qui la motivent datent de septembre 2026. Chacune des fiches qui les portent nomme elle-même ce qui l'invaliderait ; quand ce fait survient, la note est réécrite et le journal des versions le dit.
Questions fréquentes
Chaque consigne renvoie à un cas, chaque cas à sa source
Rien dans cette note n'est une opinion : les quatre consignes sortent de neuf fiches, chacune adossée à une source primaire lue, avec son statut de preuve et le fait qui l'invaliderait.