Vrais agents IA contre automatisation : les sept critères qui distinguent les deux en 2026

Le mot agent est devenu la pièce de marketing IA la plus dévaluée de 2025. À peu près tout ce qui combine un appel à un LLM et un connecteur SaaS est étiqueté agent. Cet abus de langage a un coût concret pour les acheteurs : confondre une automatisation augmentée d'IA et un vrai agent autonome conduit à acheter le mauvais outil pour le mauvais besoin, et à diagnostiquer mal les échecs en production.

Sept critères techniques distinguent les deux. Aucun ne fait l'agent à lui seul, mais l'absence de l'un d'eux suffit à exclure l'étiquette agent.

1. Comportement : déterministe ou adaptatif ?

Une automatisation exécute toujours la même chaîne de règles quand un déclencheur arrive. Si X alors Y, point. Un agent peut, face au même déclencheur, prendre des décisions différentes selon ce qu'il sait, ce qu'il a appris, et ce qu'il observe à l'instant T. C'est le critère le plus discriminant.

Test pratique : exécuter le même cas dix fois. Si le résultat est strictement identique à chaque fois, c'est probablement une automatisation. Si le résultat varie selon le contexte (et pas seulement à cause du non-déterminisme du LLM), il y a une dimension d'agent.

2. Mémoire : aucune ou structurée ?

Une automatisation n'a pas de mémoire au sens strict. Chaque exécution est isolée, les logs servent au debug, pas au comportement. Un agent a une mémoire structurée : il sait ce qu'il a fait dans le passé, peut s'en souvenir pour adapter sa décision présente, et son historique est rejouable.

Le test : peut-on demander à l'outil pourquoi il a pris telle décision il y a six mois et obtenir une réponse traçable, complète, déterministe ? Si non, il n'a pas de vraie mémoire.

3. Périmètre : ligne par ligne ou architectural ?

Le périmètre d'une automatisation est défini ligne par ligne dans le workflow. Pour empêcher un comportement, il faut le retirer du workflow. Le périmètre d'un agent autonome est défini par contrainte architecturale : l'agent ne peut techniquement pas sortir de son domaine, même s'il essaye.

Cette distinction est lourde de conséquences en sécurité. Une automatisation mal configurée peut être détournée par injection de prompt. Un agent bien architecturé ne peut pas l'être, parce que les actions hors périmètre sont mécaniquement bloquées au niveau infrastructure.

4. Décision : booléenne ou avec score de confiance ?

Une automatisation prend des décisions booléennes : la condition est vraie ou fausse, l'action s'exécute ou non. Un agent prend des décisions probabilistes : il évalue plusieurs alternatives, leur attribue des scores, choisit la meilleure et garde la trace de son raisonnement.

Cette différence est cruciale pour la gouvernance. Un score de confiance permet de calibrer des approval gates : si confiance inférieure à 0.7, escalader vers un humain. Sans score, on est dans le tout-ou-rien, ce qui ne marche pas en production sur des décisions ambiguës.

5. Apprentissage : aucun ou intégré ?

Une automatisation n'apprend pas. Si elle se trompe une fois, elle se trompera de la même manière la prochaine fois. Un agent dispose d'un mécanisme d'apprentissage : feedback humain, métriques de réversion, calibration des seuils. Il s'améliore avec le temps, ou au minimum, l'opérateur peut l'améliorer en lisant ses traces.

6. Audit : logs ou événements de domaine ?

Une automatisation produit des logs d'exécution, qui sont conservés un certain temps puis purgés, et qui sont écrits en format libre par les développeurs. Un agent produit des événements de domaine immuables, typés, horodatés, conservés indéfiniment, et structurés pour être interrogeables.

Cette différence sépare ce qui est auditable légalement de ce qui ne l'est pas. EU AI Act, DORA, MIF II exigent un audit trail traçable. Les logs ne suffisent pas. Il faut une mémoire événementielle structurée.

7. Coordination : pas applicable ou par événements typés ?

Une automatisation est mono-acteur : elle exécute son workflow dans son couloir, point. Un système d'agents nécessite des mécanismes de coordination : comment plusieurs agents collaborent sans se marcher dessus. Les bons systèmes d'agents communiquent par événements typés, pas par texte libre. Les mauvais systèmes utilisent la conversation libre, et accumulent les modes d'échec décrits par Cemri et al. (arXiv 2025).