Cloudflare Ask AI : quelle est vraiment la qualité d’Agent Lee ?

Cloudflare Ask AI est le bouton situé en haut à droite du tableau de bord. Derrière lui se trouve Agent Lee, un agent qui lit les informations de votre compte, répond aux questions en langage courant et, depuis avril 2026, modifie également votre configuration une fois que vous avez approuvé le changement.

Ce n’est pas un simple chatbot de documentation. C’est un agent qui détient des identifiants au sein d’un plan de contrôle placé devant une grande partie d’Internet. Cela mérite un examen plus attentif qu’un simple article de lancement.

Tout ce qui suit provient de la documentation et du blog de Cloudflare, ainsi que de rapports publics d’incidents rédigés par des personnes qui y ont été confrontées. Je ne l’ai pas utilisé sur un compte de production et, après avoir lu ces rapports, je ne suis pas pressé de le faire. C’est précisément le sujet de cet article.

Ce qui se trouve derrière le bouton Cloudflare Ask AI

Agent Lee repose sur la propre stack de Cloudflare : l’Agents SDK, Workers AI pour l’inférence, Durable Objects pour le stockage des conversations par utilisateur et le mécanisme d’approbation des écritures, ainsi que le serveur MCP de Cloudflare pour les définitions des outils de l’API.

La partie intéressante concerne la manière dont il appelle les outils. Au lieu d’émettre les appels d’outils un par un, le modèle écrit du TypeScript contre une API générée, puis ce code s’exécute dans un environnement isolé via un Durable Object qui agit comme proxy détenant les identifiants. Cloudflare appelle cela Codemode. Les clés d’API n’apparaissent jamais dans le code généré : elles sont injectées côté serveur. Les opérations de lecture s’exécutent directement. Les opérations d’écriture s’arrêtent à ce que Cloudflare appelle une étape d’elicitation et, dans son article de lancement, l’entreprise précise que l’invite de confirmation constitue elle-même le mécanisme de contrôle, et non une simple commodité d’UX.

Cloudflare affirme qu’Agent Lee gère environ 250 000 appels d’outils par jour pour DNS, Workers, SSL/TLS, R2, Registrar, Cache, Tunnel et API Shield.

Sur le plan architectural, il s’agit d’une véritable conception, plus prudente que celle de la plupart des copilotes de fournisseurs que j’ai examinés. Les défaillances ne se situent pas dans l’architecture.

Ce que Cloudflare Ask AI fait bien

La promesse tient dans le cas d’usage restreint. Demandez-lui où se trouve un paramètre et il vous évitera de parcourir huit onglets. Demandez-lui d’effectuer une recherche DNS ou une vérification de certificat et vous obtiendrez une réponse sans quitter la page. Demandez un graphique du trafic et il en générera un à partir de vos analytics grâce à une UI générative.

La connaissance du compte constitue la véritable amélioration par rapport à une recherche dans la documentation. Il répond au sujet de votre zone, et non d’une zone hypothétique décrite dans la documentation. Pour quiconque ne touche au tableau de bord Cloudflare que deux fois par an et ne se souvient plus si une règle se trouve sous Rules, Caching ou Configuration, c’est déjà utile.

Là où Cloudflare Ask AI se trompe

Trois défaillances ont été documentées publiquement, et elles ne relèvent pas du même type de problème.

Le token que personne n’a demandé

Fin février 2026, des utilisateurs de Cloudflare ont commencé à découvrir dans leur compte un token d’API nommé « Agent Lee (auto-generated) », qu’ils n’avaient jamais créé. Le supprimer ne résolvait rien. Il réapparaissait après actualisation. Un fil de discussion a permis d’identifier la cause : un paramètre appelé « Let AI view your account », dissimulé derrière un petit contrôle dans le panneau Ask AI, avait été livré activé. Le désactiver supprimait définitivement le token.

Un utilisateur de ce fil a déclaré ne jamais l’avoir activé et n’avoir reçu aucune notification. Un ancien membre du personnel de Cloudflare qui répondait dans le même fil a reconnu que la fonctionnalité avait été déployée sans notification et a signalé un point encore plus préoccupant : l’agent ne connaissait pas l’existence de son propre token. L’équipe a ensuite publié une documentation beta et corrigé le problème du token.

Puis, en mai, un développeur qui auditait ses identifiants a trouvé un token similaire sur son compte, créé le 28 avril et découvert trois semaines plus tard. Son article, Cloudflare's Ask AI created an API token with read access to my entire account, décrit un accès en lecture couvrant tous les comptes, toutes les zones et tous les utilisateurs, avec plus de 160 permissions et aucune date d’expiration. Son argument est convaincant : « Un assistant qui répond à une question a besoin d’un accès en lecture limité à cette question. »

La documentation actuelle de Cloudflare répertorie les tokens d’API parmi les éléments auxquels Agent Lee ne peut pas accéder. Les deux affirmations peuvent être vraies simultanément si l’identifiant provisionné pour l’agent est plus large que l’usage prévu de celui-ci. C’est tout le problème d’un token permanent, à portée étendue et sans expiration.

Allez vérifier : dash.cloudflare.com/profile/api-tokens.

Des non-réponses silencieuses

En mai, un utilisateur a signalé sur le forum de la communauté Cloudflare qu’Ask AI restait bloqué sur « thinking about it » pendant plusieurs questions d’analyse du trafic, avant de ne rien renvoyer. Aucune erreur, aucune réponse partielle, aucun signal indiquant qu’une opération avait échoué. Un répondant de Cloudflare a reproduit le problème et indiqué que l’équipe déployait des changements pour mettre fin à ces non-réponses.

Il s’agit d’un bug de beta qui sera corrigé. Je le mentionne parce qu’il révèle quelque chose sur l’interface. Un panneau de chat sans retour système ne vous permet pas de distinguer une question difficile d’un pipeline défaillant.

Une règle de cache cassée par une écriture approuvée

Le rapport de juillet est celui qui mérite votre attention. Un utilisateur qui cherchait à résoudre un problème de mise en cache a travaillé avec Ask AI, l’a regardé enregistrer la modification avec succès, puis a constaté que le problème était réapparu le lendemain matin. En examinant la situation, il a découvert que l’agent avait défini browser_ttl sur 0 avec override_origin via l’API Rulesets. L’API avait accepté la valeur. Le tableau de bord l’a ensuite signalée comme invalide lorsque la règle a été ouverte en mode édition. La règle avait déjà été déployée dans un état défectueux, et le contournement du cache ne faisait silencieusement rien.

Relisez cette séquence, car le garde-fou a fonctionné exactement comme prévu et le résultat était malgré tout une règle de production défectueuse.

La lacune que l’étape d’approbation ne couvre pas

L’étape d’elicitation répond à une question : autorisez-vous cette écriture ? Elle ne peut pas répondre à la question qui a réellement posé problème à cet utilisateur : cette valeur est-elle correcte ?

Approuver « définir le TTL du navigateur sur cette règle de cache » ne revient pas à savoir que 0 combiné à override_origin produit une règle que l’API accepte mais que le tableau de bord rejette. Pour détecter cela au moment de l’approbation, il faudrait déjà connaître la contrainte ; et si vous la connaissiez, vous ne demanderiez pas l’aide d’un agent.

C’est la limite structurelle de la confirmation avant écriture dans l’infrastructure. L’autorisation n’est pas la validation. Un humain qui approuve une modification qu’il ne peut pas évaluer ne fait qu’apposer un tampon avec quelques étapes supplémentaires, et le mode d’échec est pire qu’un refus, car une mauvaise configuration silencieuse ressemble à une réussite jusqu’à ce que le trafic vous prouve le contraire.

Si vous construisez des systèmes d’agents, voici la leçon transposable. Je me suis heurté au même mur en créant des workflows de publication et de CMS pilotés par des agents : l’étape d’approbation ne vous protège que si l’humain qui se trouve derrière le contrôle est réellement capable d’évaluer la charge utile. Sinon, vous avez besoin d’une validation dans l’outil, et non d’un consentement dans l’UI.

Le paradoxe du plan Free

Agent Lee est toujours en beta et reste limité aux comptes du plan Free en septembre 2026.

Réfléchissez à ce que cela implique pour le groupe de test. Les comptes présentant une réelle complexité, avec plusieurs zones, des règles Enterprise WAF et des revenus dépendant du comportement du cache, ne peuvent pas l’utiliser. Les comptes qui le peuvent sont ceux qui ont le moins de chances de repérer qu’un browser_ttl de 0 est incorrect avant que cela ne leur coûte quelque chose.

Je comprends la logique liée au rayon d’impact. Cela signifie également que la boucle de feedback fonctionne précisément sur la mauvaise population, et que l’incident de cache de juillet montre concrètement ce que cela donne.

Comment j’utiliserais Cloudflare Ask AI aujourd’hui

Pour une reconnaissance en lecture seule, oui. Demander où se trouve un paramètre, ce que fait actuellement une zone, si un certificat est valide ou obtenir rapidement un graphique du trafic. Risque faible, gain de temps réel.

Pour les écritures, non. Pas sur quoi que ce soit qui transporte un trafic auquel je tiens. Laissez-le vous indiquer ce qu’il modifierait, puis effectuez vous-même la modification à l’endroit où le tableau de bord valide votre saisie.

Voici trois choses qui valent la peine d’être faites cette semaine, que vous l’utilisiez ou non :

Rien de tout cela n’est anti-Cloudflare. Je construis sur leur stack, notamment avec Workers et D1 pour des listes d’attente en production. Le point important est qu’un agent intégré à votre plan de contrôle mérite un niveau d’examen différent de celui d’un agent intégré à votre éditeur.

Verdict

Agent Lee est le copilote de fournisseur dont j’ai examiné les composants internes et qui présente l’architecture la plus sérieuse. Codemode, un proxy détenant les identifiants, une véritable étape d’approbation, le tout construit sur leurs propres primitives. Cloudflare a correctement réalisé la partie difficile.

L’évaluation, en septembre 2026 :

L’écart entre l’architecture et le déploiement constitue toute l’histoire. Cloudflare a conçu avec soin le chemin des identifiants, puis l’a activé par défaut sans en informer personne, annulant en une seule décision une grande partie de cette prudence.

Utile pour les questions. Pas encore digne de confiance pour les modifications.

Sources

Vérifiées le 18 septembre 2026.