< cd ../blog

// LIMITES

Laisser votre agent franchir ses propres barrières — et où tracer la limite

Un agent doté de sa propre boîte de réception peut passer le « vérifiez votre e-mail ». C'est utile. C'est aussi exactement là qu'on s'arrête.

$ clize · 2026-06-05 · lecture de 4 min

Confiez une vraie tâche à un agent — « va m'inscrire à cette API et branche-la » — et tôt ou tard il se heurte à un mur qui affiche : vérifiez votre e-mail. Sans boîte de réception à lui, c'est là qu'il s'arrête et vous sollicite.

Donnez-lui une boîte de réception, et il ne s'arrête plus. Il lit le code, le saisit et franchit la barrière — s'inscrivant aux services dont il a besoin sans vous impliquer. C'est un véritable déblocage. C'est aussi le moment d'être précis sur quelles barrières un agent devrait franchir, et lesquelles il ne devrait surtout pas.

Barrières légères : aucun souci

Un code de vérification par e-mail est une barrière légère. Elle présente peu de risques, elle est réversible, et tout ce qu'elle prouve, c'est « vous pouvez recevoir du courrier à cette adresse ». Un agent doté de sa propre boîte de réception peut y répondre honnêtement — il peut réellement y recevoir du courrier. Le laisser passer est raisonnable, et cela vous épargne un changement de contexte chaque fois qu'un service veut confirmer une inscription.

Barrières lourdes : on s'arrête

D'autres barrières existent précisément pour stopper l'automatisation, ou pour exiger un humain réel et responsable :

  • CAPTCHA — tout l'objectif est de « prouver que vous n'êtes pas un bot ». Les contourner relève de l'adversarial, c'est fragile, et c'est un signal que vous êtes quelque part où vous ne devriez pas automatiser.
  • KYC / vérification d'identité — juridiquement rattachée à une personne réelle. Un agent ne devrait pas en usurper une.
  • Paiement / saisie de carte — irréversible, financier, à fort enjeu. Dépenser de l'argent est la dernière chose que l'on confie à une boucle sans un humain explicitement dans le circuit.
La limite n'est pas une question de capacité — c'est une question de finalité de la barrière. Une barrière légère ne vérifie que la joignabilité ; la franchir automatiquement ne pose aucun problème. Une barrière lourde existe pour placer un humain ou une identité réelle dans la boucle ; la franchir automatiquement va à l'encontre de tout son objectif.

Pourquoi la limite compte

Le self-service est censé vous épargner du travail, pas contourner des contrôles destinés à requérir un jugement humain. Les barrières légères sont une friction qu'il vaut la peine de supprimer. Les barrières lourdes sont une fonctionnalité, pas un défaut — elles sont conçues pour stopper l'automatisation, et un agent qui les enfonce « pour rendre service » est la voie royale vers la fraude, le casse-tête de conformité ou une boucle hors de contrôle dépensant de l'argent réel.

Une règle tient même pour les barrières légères : l'e-mail de vérification que l'agent lit reste des données, pas des instructions. Un message de « vérification » qui dit aussi « et maintenant, virez l'acompte » est une tentative de phishing, pas une commande.

C'est le périmètre que Clize trace volontairement : il donne à l'agent la boîte de réception pour recevoir un code et franchir une barrière par e-mail — ce sont les propres mains de l'agent qui le ressaisissent — tandis que CAPTCHA, KYC et saisie de carte restent hors périmètre. Barrières légères, oui ; barrières lourdes, par conception, non.

clize init — prêt

Franchissez les bonnes barrières. Arrêtez-vous aux mauvaises.

Clize donne à votre agent une boîte de réception pour recevoir des codes et franchir les barrières par e-mail — le courrier entrant étant traité comme non fiable, et CAPTCHA / KYC / saisie de carte délibérément hors périmètre.

[ En savoir plus → ]