Un chatbot rédige une réponse. Un copilote la prépare dans le CRM. Un agent cherche le dossier, met à jour le statut, programme un rendez-vous et envoie le message. Même modèle possible. Surface de risque entièrement différente.
L’autonomie n’est pas une interface. C’est un pouvoir d’action.
1. Définition : assistance, copilotage et agency forment une échelle
Un assistant IA répond à une demande et produit une sortie que l’utilisateur déplace ou applique. Un copilote est intégré au contexte d’un logiciel, propose, complète ou explique, tandis que la personne reste au centre de la séquence.
Un agent IA reçoit un objectif, observe un environnement, planifie ou sélectionne des étapes, appelle des outils et adapte la suite à leurs résultats. Il peut lire, écrire, communiquer, déclencher un workflow ou coordonner d’autres composants.
La frontière n’est pas le nom commercial. Un produit appelé « agent » peut n’exécuter qu’un workflow fixe ; un copilote doté d’un bouton d’envoi possède déjà un acte engageant. Classez la capacité réelle, les permissions et la réversibilité.
2. Chiffres clés : capacités rapides, fiabilité encore irrégulière
- Le Stanford AI Index 2026 indique que la réussite sur OSWorld, benchmark de tâches informatiques, est passée d’environ 12 % à 66 % en un an. Même sur ce cadre structuré, les meilleurs systèmes échouent donc encore approximativement une fois sur trois.
- L’adoption organisationnelle déclarée de l’IA atteignait 88 % dans l’enquête reprise par Stanford, mais le déploiement d’agents restait à un chiffre dans presque toutes les fonctions métier. Usage de l’IA et délégation autonome ne sont pas équivalents.
- METR mesure le « time horizon » : durée d’une tâche de logiciel qu’un agent frontalier réussit avec un niveau de fiabilité donné. Sa tendance historique a doublé environ tous les sept mois, mais METR souligne que le résultat dépend des tâches, des humains de référence et de la configuration.
- Dans EnterpriseBench, article accepté à EMNLP 2025 et disponible en prépublication, 500 tâches de RH, finance, administration et ingénierie étaient simulées ; les agents les plus performants atteignaient 41,8 % de complétion. Cette étude émergente doit être lue comme un signal, pas comme une norme de production.
- Le NIST a répété cinq attaques d’injection indirecte 25 fois contre des agents : le taux moyen de succès d’attaque est passé de 57 % à 80 %. Un test unique sous-estime le risque lorsque l’attaquant peut réessayer.
- En décembre 2025, l’OWASP a publié un Top 10 spécifique aux applications agentiques issu de contributions de plus de 100 chercheurs et praticiens, couvrant détournement de comportement, usage abusif d’outils, abus d’identité et de privilèges.
La trajectoire invite à construire maintenant, mais dans des périmètres où une erreur est visible, contenue et récupérable.
3. L’échelle d’autonomie : six niveaux pour choisir sans marketing
Chaque niveau hérite des contrôles du précédent. On ne monte que lorsque le gain justifie la liberté supplémentaire.
4. Niveau 0 — Réponse sans contexte privilégié
À ce stade, le modèle transforme un texte fourni : reformulation, résumé, idéation ou extraction légère. Il n’accède pas aux données internes ni aux outils.
La valeur vient de la vitesse et de la forme. Les risques concernent confidentialité de l’entrée, exactitude, droits et usage de la sortie. Une charte, un environnement approuvé et une validation humaine suffisent souvent pour les cas faibles.
Exemple sans contexte : préparer trois variantes d’un message à partir d’informations non sensibles et vérifiées.
5. Niveau 1 — Réponse ancrée dans un corpus
La réponse recherche dans des documents autorisés et revient avec des sources. Elle possède davantage de contexte, mais aucun droit d’écriture.
Évaluez retrieval, fidélité, version, droits et abstention. Une permission doit filtrer avant la récupération : masquer la citation après que le modèle a lu le document ne protège pas le secret.
Exemple documentaire : répondre à une question de procédure avec lien vers la page exacte et date de validité.
6. Niveau 2 — Copilote dans une application
Le copilote connaît l’objet courant et propose une action que l’utilisateur valide : champ CRM, réponse, requête, code ou analyse. Il raccourcit le flux sans choisir seul la prochaine étape.
L’interface montre proposition, sources, modifications et conséquence. Le bouton « accepter tout » ne doit pas rendre la vérification plus coûteuse que l’exécution manuelle.
Exemple de copilotage : préremplir un compte rendu et suggérer les tâches, avec confirmation explicite.
7. Niveau 3 — Agent en lecture et simulation
L’agent choisit plusieurs recherches, appelle des outils sans effet externe et prépare un plan ou une simulation. Il peut explorer, mais pas modifier la production.
Ce niveau révèle sa capacité réelle à planifier, gérer les erreurs d’outil et rester dans le périmètre. Il permet de comparer décision proposée et décision humaine sur des historiques sans exposer l’entreprise.
Exemple en simulation : analyser un incident, rassembler journaux et documentation, puis proposer les étapes de diagnostic.
8. Niveau 4 — Agent d’écriture réversible
L’agent crée un brouillon, un ticket, une étiquette, une réservation annulable ou une mise à jour bornée. L’action possède identité dédiée, permissions minimales, budget et journal.
Les modifications sont idempotentes, versionnées et réconciliées. Un contrôle humain peut être systématique au départ, puis ciblé selon la preuve et la conséquence.
Exemple réversible : créer et prioriser des tickets à partir de demandes entrantes, sans les fermer ni engager une dépense.
9. Niveau 5 — Agent engageant sous supervision
L’agent peut communiquer à l’extérieur, modifier un droit, lancer un paiement ou prendre une décision importante. Le dossier exige séparation des rôles, approbations, seuils, sandbox, red teaming, mode dégradé et recours.
Certains usages doivent rester interdits ou soumis à des règles sectorielles. La possibilité technique ne constitue jamais une autorisation juridique ou managériale.
Exemple engageant avec contrôle : préparer un ordre fournisseur puis demander une double approbation avant envoi.
Le niveau 5 n’est pas une médaille. Beaucoup de processus sont meilleurs au niveau 2 ou 4.
10. Le dossier de sûreté : neuf preuves avant production
Tout agent professionnel arrive avec un safety case : ensemble structuré d’arguments et de preuves montrant que le service est suffisamment maîtrisé dans son contexte. Ce cadre Logiks s’inspire des pratiques de systèmes critiques sans prétendre à une certification.
11. Preuve 1 — Une tâche bornée
Définissez déclencheur, objectif, outils, données, population, sortie, durée, budget et interdits. « Gérer la relation client » n’est pas un périmètre ; « préparer une proposition de rendez-vous à partir d’une demande qualifiée, sans envoi » en est un.
Listez les états terminalement acceptables : succès, besoin d’information, transmission, refus et échec. Continuer jusqu’à produire quelque chose peut inventer une solution lorsque l’abstention était correcte.
12. Preuve 2 — Une identité et des permissions propres
L’agent ne réutilise pas le compte d’un humain ou un secret administrateur. Son identité est authentifiée, limitée par outil, action, ressource, environnement, montant et durée.
Les tokens sont courts, les secrets hors contexte du modèle et la délégation vérifiable. Une approbation humaine crée une autorisation étroite pour l’acte, pas un accès général permanent.
NIST travaille en 2026 sur l’identité et l’autorisation des agents précisément parce que leurs actions traversent plusieurs systèmes. Les principes IAM classiques restent la base, adaptés à des acteurs logiciels plus dynamiques.
13. Preuve 3 — Des outils comme contrats
Chaque outil possède schéma d’entrée, sortie, erreurs, timeout, idempotence et effet. L’agent ne génère pas librement une requête destructive quand une fonction bornée « proposer_annulation » suffit.
Validez la sortie du modèle avant l’appel et la réponse de l’outil avant sa réutilisation. Un site, un courriel ou un fichier externe reste non fiable, même si son texte ressemble à une instruction interne.
14. Preuve 4 — Un environnement hostile testé
L’injection indirecte place des instructions malveillantes dans les données que l’agent consulte. NIST décrit le détournement comme une difficulté persistante, notamment lorsque les instructions et données partagent le même canal.
Construisez des scénarios : page demandant d’exfiltrer un secret, pièce jointe modifiant le bénéficiaire, ticket invitant à ignorer la politique, chaîne encodée, conflit entre outils et attaque répétée. Mesurez tâche légitime réussie, attaque réussie et dégradation provoquée par les défenses.
Une défense qui bloque tout est sûre mais inutile. L’évaluation doit couvrir sécurité et capacité simultanément.
15. Preuve 5 — Une évaluation multi-exécution
Les modèles sont probabilistes. Rejouez chaque cas plusieurs fois, avec variations de contexte, latence, ordre et erreurs d’outil. Rapportez taux de succès complet, succès partiel, coût, durée et cohérence.
Si une tâche comporte cinq étapes réussies chacune à 95 % et que leurs erreurs sont indépendantes, la réussite théorique de bout en bout n’est que 0,95^5 ≈ 77,4 %. L’orchestration longue amplifie les fragilités.
Utilisez une validation de l’état final, pas le récit de l’agent. Un message « terminé » ne prouve pas que le ticket, le paiement ou l’agenda correspond à la consigne.
16. Preuve 6 — Une supervision effective
Décidez ce que l’humain voit et quand. Avant action : plan, données et conséquence. Pendant : étapes inhabituelles ou dépassement. Après : résultat, écart et possibilité d’annuler.
La supervision doit disposer du temps, de l’information et de l’autorité. Demander cent validations identiques par heure transforme la personne en bouton biologique et augmente le biais d’automatisation.
17. Preuve 7 — Une observabilité sans surveillance excessive
Tracez objectif, version, outils, arguments contrôlés, latence, coûts, erreurs, approbations et état final. Protégez les données, limitez la conservation et séparez l’analyse du service de l’évaluation individuelle des salariés.
Les traces doivent répondre à trois questions : que s’est-il passé, pourquoi le système a-t-il pu agir et comment réparer ? Les raisonnements internes détaillés ne sont ni toujours disponibles ni nécessaires ; décisions et preuves externes comptent davantage.
18. Preuve 8 — Un mode dégradé et une reprise
Définissez arrêt automatique, kill switch, file persistante, fallback déterministe, retour humain et réconciliation. Simulez panne d’outil, modèle indisponible, coût explosif, boucle, données incohérentes et réponse partielle.
Une limite de pas, de temps, de tokens et d’argent empêche l’agent de poursuivre indéfiniment. Un état suspendu conserve le dossier pour reprise sans rejouer les actes réussis.
19. Preuve 9 — Une économie de l’autonomie
Le coût inclut modèle, appels multiples, outils, latence, revue, observabilité, incidents et maintenance des évaluations. Comparez au copilote ou workflow moins autonome.
Dans cet exemple, l’automate économise vingt minutes sur 5 000 tâches, mais coûte 1,20 € d’inférence, 0,80 € d’outils et cinq minutes de revue à 40 €/heure. Le coût direct par tâche atteint 5,33 € ; la valeur du temps brut gagné est 13,33 €, soit 8 € avant intégration, erreurs et support.
Si un copilote économise douze minutes pour 1 €, sans risque d’écriture, son économie nette peut être supérieure. L’autonomie doit gagner sa complexité.
20. Cas de conception : agent de rendez-vous B2B
Le besoin paraît simple : recevoir une demande, proposer des créneaux et mettre à jour le CRM. Le parcours réel inclut fuseaux, agendas privés, commerciaux spécialisés, clients existants, doublons, consentement, délais et messages de marque.
20.1. Version copilote
Le système résume la demande, identifie le secteur, suggère trois créneaux disponibles et prépare le message. Le commercial valide destinataire, texte et horaire. Cette version mesure qualité de qualification et taux de correction sans envoi autonome.
20.2. Version agent réversible
Après preuve, l’agent peut poser une option temporaire dans l’agenda et créer une tâche CRM. Il ne contacte pas le prospect. Les options expirent, les conflits sont vérifiés à l’écriture et l’identité ne peut lire que les disponibilités nécessaires.
20.3. Version avec communication
L’envoi est ouvert uniquement aux demandes conformes, avec modèles approuvés, domaine vérifié, fréquence limitée et exclusions. Un nouveau type de client, une information contradictoire ou un créneau hors politique retourne au commercial.
Le test final contrôle état des deux agendas, CRM, destinataire, langue, contenu et absence de double message. Le taux de « rendez-vous proposé » ne suffit pas si 3 % des invitations sont envoyées à la mauvaise personne.
L’équipe s’arrête au niveau 4 si la valeur additionnelle de l’envoi autonome ne couvre pas son contrôle. Cette décision est un signe de maturité.
21. Ce que l’agent peut casser : construire un budget d’erreur avant le budget de tokens
Le budget d’erreur décrit le nombre et la gravité d’échecs acceptables pendant une période, ainsi que la réaction déclenchée quand le seuil est franchi. Il complète le coût technique : une exécution bon marché n’est pas économique si sa correction mobilise plusieurs équipes ou atteint un client.
Pour un agent qui crée des tickets internes, l’entreprise peut accepter vingt erreurs de catégorie sur dix mille objets, à condition qu’aucune ne ferme un incident critique et que chaque erreur reste corrigeable avant le SLA. Pour un changement de coordonnées bancaires, le budget de faux positif autonome doit en pratique être nul : toute proposition passe par une vérification indépendante et une autorité habilitée.
Construisez une taxonomie avec quatre classes : nuisance, interruption, engagement erroné et atteinte grave. Chaque classe reçoit détectabilité, délai de récupération, coût, personne touchée et plafond, ce qui empêche un bon taux moyen de masquer une erreur rare dont la conséquence domine tout le portefeuille.
Le suivi distingue les échecs détectés par le service, par l’opérateur, par le client et par hasard. Une baisse apparente peut provenir d’une perte d’observabilité, surtout si l’équipe réduit la revue au même moment qu’elle augmente l’autonomie.
Ajoutez un budget de quasi-incidents. Une tentative d’appel interdit correctement bloquée, une boucle arrêtée avant écriture ou une attaque sans exfiltration ne crée pas de dommage, mais révèle une pression qui doit nourrir les contrôles et les nouveaux scénarios.
La règle d’escalade est écrite à l’avance : un incident grave suspend immédiatement l’action concernée ; trois engagements erronés sur une semaine rétablissent l’approbation systématique ; une hausse des nuisances au-dessus du seuil déclenche analyse sans interrompre tout le service.
Ce mécanisme évite deux extrêmes. L’équipe ne coupe pas un agent utile au premier classement imparfait, et elle ne maintient pas une action dangereuse au motif que 99 % des tâches restent correctes.
Enfin, le comité compare coût de prévention, coût de détection et coût de récupération. Parfois, limiter une permission supprime une classe entière de dommage pour presque rien ; ailleurs, une double approbation sur chaque cas détruit le bénéfice et justifie de rester au niveau copilote.
Le budget d’erreur rend la tolérance explicite. Il transforme une discussion abstraite sur la confiance en décisions de service, de supervision et d’investissement.
Sans ce cadre, une direction peut accepter silencieusement des milliers de petites erreurs parce que le taux global reste flatteur, puis découvrir trop tard qu’une seule catégorie rare — le mauvais destinataire, le droit excessif ou le paiement non récupérable — concentrait presque toute la perte économique et réputationnelle.
Avec lui, les équipes métier, sécurité et produit discutent du même objet : non pas de savoir si le modèle paraît intelligent pendant une démonstration, mais de déterminer quelles conséquences restent possibles, comment elles seront détectées, qui possède l’autorité de suspendre et quelle preuve autorisera un retour contrôlé.
22. Architecture minimale d’un agent exploitable
- Entrée authentifiée et classification du besoin.
- Policy engine extérieur au modèle pour droits et interdits.
- Orchestrateur avec limites de pas, temps et coût.
- Modèle(s) routés selon tâche et risque.
- Outils bornés avec schémas, identité et idempotence.
- Mémoire contrôlée par portée, source et durée.
- Validation des entrées, sorties et états.
- Approbation humaine aux frontières engageantes.
- Observabilité technique, métier, coût et sécurité.
- Reprise par file, rollback et mode manuel.
Le modèle n’est qu’un composant. Changer de modèle ne répare pas une permission excessive ou un outil non idempotent.
23. Programme Logiks en quatre paliers
23.1. Palier A — 100 tâches historiques
Rejouer sans outil d’écriture. Établir baseline humaine, réussite, coût et taxonomie d’erreurs. Construire les attaques.
23.2. Palier B — Simulation en temps réel
Observer les entrées réelles, proposer des actions et comparer aux décisions, sans effet. Mesurer distribution et dérive.
23.3. Palier C — Écriture réversible sous validation
Ouvrir un outil borné, journaliser, approuver chaque acte et tester la reprise. Augmenter le volume par lots.
23.4. Palier D — Supervision ciblée
Automatiser les cas verts après preuve, conserver échantillonnage et seuils, puis réévaluer périodiquement. Les actes rouges restent approuvés.
Le passage dépend de critères préenregistrés. Il ne dépend pas de la date du comité de lancement.
24. Conseils Logiks : douze questions avant d’appeler un système « agent »
- Peut-il agir ou seulement répondre ?
- Qui définit son objectif exact ?
- Quels outils et droits possède-t-il ?
- Quelle donnée externe peut l’influencer ?
- Comment refuse-t-il une tâche ?
- L’état final est-il vérifié indépendamment ?
- Combien d’exécutions ont été testées ?
- Quel acte est irréversible ?
- Qui peut arrêter immédiatement ?
- Comment reprendre sans dupliquer ?
- Quel coût par tâche complète ?
- Pourquoi un copilote ne suffit-il pas ?
Si les réponses restent vagues, l’autonomie est prématurée.
25. FAQ
25.1. Quelle différence entre copilote et agent IA ?
Le copilote propose dans un flux dirigé par l’humain. L’agent poursuit un objectif, choisit des étapes et utilise des outils. Les produits hybrides se classent par capacité réelle.
25.2. Faut-il commencer par un agent autonome ?
Non. Commencez par lecture, simulation ou écriture réversible. L’autonomie augmente seulement quand sa valeur dépasse le coût de contrôle.
25.3. Comment mesurer un agent ?
Succès de bout en bout vérifié dans l’environnement, cohérence sur plusieurs exécutions, coût, durée, sécurité, intervention humaine, état final et dommages évités.
25.4. Un agent peut-il lire les courriels ?
Techniquement oui, mais les courriels sont des données non fiables et sensibles. Limitez la boîte, les droits, les actions et testez l’injection indirecte.
25.5. Le human-in-the-loop suffit-il ?
Seulement si l’humain possède information, temps, compétence, autorité et voie de recours. Sinon, la validation devient mécanique.
25.6. Comment éviter les boucles et surcoûts ?
Limites de pas, tokens, temps, budget, appels d’outil et tentatives ; détection de répétition ; arrêt et file de reprise.
26. Conclusion
L’agent n’est pas plus avancé parce qu’il agit davantage. Il est plus exigeant parce que ses erreurs franchissent les frontières des systèmes.
Choisissez le niveau minimal utile. Bornez la tâche. Donnez une identité étroite. Testez plusieurs exécutions et des données hostiles. Vérifiez l’état final. Préparez l’arrêt avant l’autonomie.
Le contrôle rend l’action possible.
27. Sources principales
- Stanford HAI, AI Index Report 2026 — Technical Performance : https://hai.stanford.edu/ai-index/2026-ai-index-report/technical-performance
- Stanford HAI, AI Index Report 2026 — Economy : https://hai.stanford.edu/ai-index/2026-ai-index-report/economy
- METR, Task-Completion Time Horizons of Frontier AI Models, mise à jour du 8 mai 2026 : https://metr.org/time-horizons/
- Vishwakarma et al., EnterpriseBench, article accepté à EMNLP 2025, prépublication d’octobre 2025 : https://arxiv.org/abs/2510.27287
- NIST CAISI, Strengthening AI Agent Hijacking Evaluations, mis à jour le 19 décembre 2025 : https://www.nist.gov/news-events/news/2025/01/technical-blog-strengthening-ai-agent-hijacking-evaluations
- NIST, Security Considerations for AI Agents, NIST AI 800-5, mai 2026 : https://www.nist.gov/publications/summary-analysis-responses-request-information-regarding-security-considerations-ai
- NIST, Lessons Learned: Tool Use in Agent Systems, 5 août 2025 : https://www.nist.gov/news-events/news/2025/08/lessons-learned-consortium-tool-use-agent-systems
- OWASP GenAI Security Project, Top 10 for Agentic Applications, décembre 2025 : https://genai.owasp.org/2025/12/09/owasp-top-10-for-agentic-applications-the-benchmark-for-agentic-security-in-the-age-of-autonomous-ai/