Maintenir un agent IA : qui s'en occupe dans six mois ?
Dans six mois, quelqu'un devra s'occuper de votre agent IA, car tout bouge autour de lui : le modèle chez le fournisseur, vos règles commerciales, votre catalogue, votre boutique et les bibliothèques sur lesquelles il repose. Le commerçant peut tenir lui-même ses règles et surveiller les alertes ; un développeur doit gérer le code, les modèles et les mises à jour. Ce qui rend la maintenance possible, ce sont des tests rejoués à chaque changement, des traces lisibles et un code qui vous appartient.
Je suis développeur Sylius et Symfony indépendant et j'intègre des agents IA dans des boutiques en ligne. La question de la maintenance se pose rarement au moment du devis. Elle se pose le jour où l'agent répond de travers sans que personne ne sache pourquoi. Voici comment je la prépare dès la construction d'un agent IA pour l'e-commerce.
Qu'est-ce qui change autour d'un agent IA ?
Un agent ne vieillit pas comme un site web. Son code ne change pas tout seul, mais il dépend de beaucoup d'éléments qui, eux, bougent.
| Ce qui change | Le signe | Qui agit |
|---|---|---|
| Le modèle chez le fournisseur | Nouvelle version, ancien modèle remplacé | Le développeur, tests à l'appui |
| Vos règles commerciales | Nouvelle politique de retour, nouveau transporteur | Le commerçant écrit, le développeur versionne et teste |
| Votre catalogue | Nouvelles gammes, nouveaux attributs | Le commerçant, avec mise à jour des documents |
| Votre boutique | Mise à jour de Sylius, correctif de sécurité | Le développeur |
| Les bibliothèques IA | Nouvelle version d'une brique encore jeune | Le développeur |
| Le coût | Alerte de plafond, facture qui grimpe | Les deux, à partir des traces |
Les bibliothèques méritent une attention particulière, car l'écosystème est jeune. Symfony AI, sur lequel on peut construire un agent en PHP, vient de sortir en version 1.0.0-BETA1, et la promesse de compatibilité ne commencera qu'à la version 1.0 finale. Les plugins IA officiels de Sylius sont tous en version 0.x. La spécification MCP elle-même évolue par révisions datées. Ce sont de bonnes briques, mais chaque mise à jour peut changer une interface.
Comment savoir que l'agent répond encore juste ?
Par des tests, pas par l'impression. Sur l'agent de service client que je construis en ce moment pour une boutique sous Sylius 2, entre 40 et 60 cas réels anonymisés seront rejoués avant chaque changement : nouvelle version du modèle, nouvelle règle, mise à jour de la boutique. Si une réponse attendue change, on le voit avant que le client ne le voie. La méthode est détaillée dans l'article sur les cas de référence.
Entre deux changements, ce sont les traces qui servent de tableau de bord. Chaque passage de cet agent sera tracé : ce qu'il a lu, ce qu'il a proposé, les règles citées, la version des règles, le modèle et le coût. Un plafond de dépense par jour déclenche une alerte, et les messages attendent. Quand une réponse surprend, on sait immédiatement avec quelle version des règles et quel modèle elle a été produite.
Ce que l'agent ne fait jamais seul : changer ses propres règles. C'est la condition pour que la maintenance reste possible. Un agent qui réécrit ses instructions devient impossible à suivre, et c'est souvent ce qui fait échouer les assistants montés à la main, comme je l'explique dans l'article sur les GPT maison.
Le coût, enfin, se surveille lui aussi dans le temps. Un nouveau type de message, une campagne qui fait affluer les questions, un modèle plus cher choisi par défaut : la facture peut glisser sans que personne ne le remarque. Le cache et l'alerte de plafond quotidien évitent les mauvaises surprises, et les traces disent quelle tâche coûte quoi. Le sujet est développé dans l'article sur la facture d'un jour de pic.
Et si un agent le faisait pour vous ?
Laissez votre numéro : je vous rappelle sous 24 heures ouvrées et je regarde avec vous ce qu'un agent peut prendre en charge dans votre boutique, dans votre budget.
Qui fait quoi, concrètement ?
Le commerçant tient ses règles à jour, dans un document qu'il comprend. Il lit les alertes et signale les réponses qui le surprennent. Il n'a pas besoin de toucher au code.
Le développeur versionne les règles, rejoue les tests, change de modèle quand c'est utile, applique les mises à jour de la boutique et des bibliothèques. Le routeur de modèles rend un changement de modèle moins risqué, car il se fait à un seul endroit.
Avec moi, le commerçant parle directement au développeur qui a écrit le code : pas de ticket qui passe de main en main. Et parce que le code lui appartient, il reste libre de confier la maintenance à quelqu'un d'autre.
Et la boutique Sylius elle-même ?
Un agent qui lit la boutique par son API dépend de la sécurité de cette API. Sylius publie régulièrement des correctifs : la version 2.3.2 en corrige six, dont une faille qui permettait d'accéder aux données d'autres clients par l'API boutique. Exposer l'API à un agent impose donc de garder Sylius à jour. Sur une boutique encore en Sylius 1, la question de la migration vers Sylius 2 se pose aussi, car les briques IA officielles exigent Sylius 2.1 ou plus.
Comment préparer la maintenance dès le départ ?
Quatre choses, posées à la construction, rendent un agent maintenable : des règles écrites hors du code et versionnées, des cas de test réels rejoués à chaque changement, des traces lisibles par un humain, et un code documenté qui vous appartient. Sans elles, la maintenance devient de l'archéologie.
Pour savoir si votre agent, existant ou en projet, tiendra dans six mois, je propose un diagnostic IA offert : je vous rappelle sous 24 heures ouvrées, je passe votre boutique au crible des 8 couches et je vous propose une solution durable dans votre budget.