Delphi, KAI et ExeWatchMCP : et si ton assistant IA lisait les erreurs de tes clients et les corrigeait ?

Lundi matin, tu ouvres ton projet dans Delphi ou C++Builder, tu écris à KAI une ligne sur l'erreur qu'a eue le client XYZ, et KAI va la lire tout seul. Je te raconte comment y arriver avec ExeWatchMCP, et pourquoi, pour qui programme dans RAD Studio, ça change la façon de travailler.

TL;DR : ExeWatch a un serveur MCP, ExeWatchMCP. Tu l’enregistres dans KAI, l’assistant IA de RAD Studio, et KAI lit tout seul les erreurs et les lenteurs que tes clients rencontrent en production. Tu ouvres le projet Delphi ou C++Builder, tu lui dis “corrige l’erreur du client XYZ” et il part de ce qui s’est vraiment passé : plus bas, tu trouves une vraie session. Ça marche aussi avec Claude Code, Codex et les autres agents MCP, à la fin de l’article.

Voilà la révolution

Un client te dit qu’il a vu une erreur. Tu écris une ligne à KAI, et KAI fait le reste : il lit la production, trouve l’endroit dans le code, le corrige, compile. Tout dans l’IDE, dans la même conversation.

C’est une vraie session sur un de mes projets Delphi 13 (RecommenderPro, un serveur REST). Les captures sont en anglais parce que KAI et ma session le sont. Je n’ai donné ni client ni version, seulement cette phrase : “A client told me they saw an error in this app this afternoon. Check ExeWatch.”

KAI appelle exewatch_guide, exewatch_apps et exewatch_groups (le premier appel à groups échoue et KAI le refait), et me dit que dans les dernières 24 heures il y a deux problèmes distincts : une licence non valide, quatre fois, et un échec à l’import d’un CSV, une fois. Il dit aussi ce qu’il ne sait pas : “I haven’t read any code yet”, et que pour savoir lequel des deux est celui du client, il lui faudrait l’heure locale du client. Il ne devine pas.

Je lui réponds : “OK, check it and fix it!”

KAI lit les logs de l’échec, cherche dans le projet, ouvre RPServices.BulkU.pas et trouve la cause : le séparateur attendu est le point-virgule et le fichier reçu était séparé par des virgules, donc le parser voyait une seule colonne et disait “1 value per row”, un message qui n’aide personne. Il change le message, qui nomme maintenant la ligne et le séparateur requis, et compile avec l’IDE.

De la phrase “un client a vu une erreur” au code modifié et compilé : une seule conversation, dans l’IDE, sans que j’aie copié une stack trace dans un prompt. Sur l’erreur de licence, KAI n’a pas touché au code : le log indique un fichier de licence non valide, c’est donc un problème de fichier et de configuration. Il a aussi remarqué qu’ExeWatch n’a pas de stack trace pour ces deux erreurs, parce que le projet n’est pas compilé avec le map file détaillé : c’est expliqué plus bas.

Le code n’est plus le centre

Jusqu’ici, le code était le centre et la production un endroit que tu visitais. Un client téléphonait, tu ouvrais le dashboard, tu copiais la stack, tu la collais dans le prompt de l’agent. L’agent connaissait le code source et rien d’autre : il trouvait trois endroits suspects, en choisissait un, et s’il se trompait, le crash restait et tu avais une modification de plus à relire.

Maintenant, le centre, c’est ce qui se passe en production, et le code s’adapte. L’agent lit l’erreur, la version, combien de fois c’est arrivé, chez quels clients, après quelles actions, et seulement ensuite il ouvre le fichier. Le flux est celui-ci : le code part en production, ExeWatch collecte ce qui se passe, l’agent le lit pendant qu’il modifie le code, la modification repart en production et ExeWatch te montre si l’erreur a disparu. Tu ne modifies plus à l’aveugle. C’est un game changer.

Ce que tu peux lui demander

Tu écris tes demandes comme tu les dirais à un collègue, en français ou en anglais. Par exemple :

Customer XYZ got an error last night on version 2.3.
Look it up in ExeWatch, find the spot in the code and fix it.

Check in ExeWatch where this program is slow
when opening the customer list, explain why and optimize it.

Dans le premier cas, KAI cherche l’erreur, lit la stack trace, remonte à l’unit et à la ligne, regarde les breadcrumbs pour comprendre ce que faisait l’utilisateur et te propose la correction sur ton code. Dans le second, il part des vrais timings, pas de son idée de l’endroit où pourrait se trouver le goulot d’étranglement. Souvent, ce sont deux endroits différents.

Pourquoi dans RAD Studio, c’est autre chose

Donner à un agent la visibilité sur ce qui se passe en production est un superpouvoir. Le bug fixing devient beaucoup plus rapide, parce que l’agent part de la vraie erreur et n’a pas à la chercher, et tu réagis à ce qui se passe chez les clients en une conversation, pas en un ticket.

KAI est là où tu es, dans l’IDE, avec le projet ouvert. Avec ExeWatchMCP, au même endroit où tu écris le code, tu demandes aussi ce qui s’est passé chez les clients, sans navigateur, sans copier-coller, sans changer d’outil. Delphi et C++Builder, avec KAI et la production sous les yeux, travaillent mieux, et c’est ce que je veux montrer à la communauté Embarcadero.

Qu’est-ce qu’ExeWatchMCP

C’est un paquet Python, ExeWatchMCP sur PyPI : pip install ExeWatchMCP et tu as le serveur (exewatch-mcp) plus la ligne de commande exewatch. MCP est le protocole par lequel un agent IA découvre et exécute des outils externes ; j’en ai parlé dans Not Just MCP. A Full AI Agent, Embedded in Your Delphi Application (article en anglais) et dans MCP Server for Delphi: Connect Your Applications to AI with DMVCFramework (article en anglais). Voici les outils que ton agent trouve à sa disposition :

Comment le relier à KAI

La clé API, tu la crées dans ExeWatch et elle est en lecture seule. Dans RAD Studio, va dans Tools > Options > Kai > Chat > MCP Servers > Custom, ajoute un serveur et remplis quatre champs : le nom (exewatch-mcp), le type (Local), la commande de lancement (exewatch-mcp) et une variable d’environnement EXEWATCH_API_KEY avec ta clé. La clé reste là, pas dans le prompt.

Si l’IDE ne trouve pas exewatch-mcp dans le PATH, écris le chemin complet de la commande, ou utilise python -m exewatch_cli mcp.

Un point pour qui travaille en Delphi : la stack trace n’arrive que si tu compiles le programme avec le map file détaillé et les stack frames activés. Si tu utilises déjà madExcept ou EurekaLog, tu peux donner à ExeWatch leur stack trace avec une petite unit de liaison : je l’ai expliqué dans Integrating ExeWatch into Delphi Projects That Already Use madExcept (article en anglais), et le même schéma vaut pour EurekaLog.

Ce qu’il peut faire et ce qu’il ne peut pas

• Lecture seule. La clé est en lecture seule : l’agent n’écrit rien sur ExeWatch.
• Clé avec périmètre. Quand tu crées la clé, tu choisis ce qu’elle peut lire : une seule application, un groupe d’applications, ou toutes. Un consultant externe reçoit une clé pour la seule app sur laquelle il travaille et ne voit pas les autres.
• Plans PRO et BUSINESS. Les clés API sont disponibles dans les plans PRO et BUSINESS, en cloud comme on-premises. Si ExeWatch te demande de passer à un plan supérieur quand tu crées la clé, ton plan ne les inclut pas.
• Le texte qui vient du terrain n’est pas à toi. Messages et stack traces sont écrits par le logiciel des clients, et en théorie par quiconque arrive à le faire parler. C’est pourquoi chaque réponse porte "untrusted_content": true, et l’agent la traite comme des données à lire, jamais comme des instructions à exécuter.
• Fenêtres de temps. Sans filtre, une requête couvre jusqu’à 90 jours (24 heures si tu ne dis rien). En filtrant par texte, tag, version ou session, le maximum est de 7 jours, et il en va de même pour les timings.
• La version est un texte exact. 2.3 ne trouve pas 2.3.0.145. Si rien n’est trouvé, l’agent relance sans filtre et lit la version dans les résultats.
• Le code, c’est toi qui le relis. Comme le veut la bonne pratique, l’agent propose la modification du code, et tu fais la review comme pour n’importe quelle autre modification.

Ça marche aussi avec Claude Code, Codex et les autres

ExeWatchMCP est un serveur MCP standard, il n’est donc pas lié à KAI. Avec Claude Code :

claude mcp add exewatch --env EXEWATCH_API_KEY=<your key> -- exewatch-mcp

Avec Codex, c’est pareil avec codex mcp add, ou bien une entrée [mcp_servers.exewatch] dans ~/.codex/config.toml. Tout autre agent ou assistant qui parle MCP se configure de la même façon. À toi de choisir.

Dans cet article, j’ai parlé de Delphi et de C++Builder parce que c’est là qu’ExeWatch est né et que l’intégration avec KAI a le plus de sens. Les SDK d’ExeWatch couvrent aussi .NET, Python et JavaScript, et le serveur est le même.

Tu veux le voir en direct ?

Je le montre en direct à l’ITDevCon, Rome, les 19 et 20 novembre 2026 : KAI ouvert sur un projet Delphi, une vraie erreur arrivée d’ExeWatch, et l’agent qui la résout devant toi. Ensuite, j’en parlerai dans quelques webinaires et dans d’autres conférences, dont Ekon. Je mettrai les dates ici au fur et à mesure que je les confirme.

Pour comprendre ce qu’ExeWatch collecte aujourd’hui, lis ExeWatch 1.35: Nested Timing Traces for Delphi & .NET (article en anglais) et ExeWatch: Proactive Software Monitoring from Passive Security to Observability (article en anglais). Le reste est sur exewatch.com.

Questions fréquentes

Qu’est-ce qu’ExeWatchMCP ? C’est le serveur MCP d’ExeWatch. Il permet à un agent de coding de lire erreurs, stack traces, breadcrumbs, versions et timings des applications surveillées, pendant qu’il travaille sur ton code.

Avec quels agents fonctionne-t-il ? Avec KAI, l’assistant IA de RAD Studio pour Delphi et C++Builder, et avec tout autre environnement qui supporte le Model Context Protocol, comme Claude Code et Codex.

Comment l’installer ? pip install ExeWatchMCP (Python 3.9 ou supérieur), puis tu enregistres exewatch-mcp dans ton agent avec la clé API dans l’environnement.

L’agent peut-il modifier les données sur ExeWatch ? Non. La clé est en lecture seule.

Faut-il un plan payant ? Oui. Les clés API sont disponibles dans les plans PRO et BUSINESS, cloud et on-premises.

Puis-je donner accès à un consultant sur une seule app ? Oui. La clé se limite à une application, à un groupe d’applications ou à toutes.

Ça ne marche qu’avec Delphi et KAI ? Non, mais cet article part de là. ExeWatch a des SDK pour Delphi, C++Builder, .NET, Python et JavaScript, et le serveur MCP est le même pour tous.

Où le voir en action ? À l’ITDevCon à Rome, les 19 et 20 novembre 2026.