Agent IA marketing : ce que c'est, ce que ça coûte, et ce qui casse en production

La réponse, tout de suite

Un agent IA marketing est un programme qui reçoit un objectif, choisit lui-même les étapes pour l'atteindre, appelle des outils (votre CRM, votre outil d'emailing, une base de données, un moteur de recherche) et rend un résultat, sans qu'un humain valide chaque étape.

Ce n'est ni un chatbot, qui répond et s'arrête, ni une automatisation classique, qui exécute une suite d'étapes fixée à l'avance. La différence tient en un mot : la décision. Un scénario d'automatisation fait toujours la même chose. Un agent décide, donc il peut se tromper.

Le budget se compose de trois postes très inégaux, et le premier est presque toujours celui qu'on surestime. Le coût des appels au modèle est faible. Ce qui coûte, c'est l'orchestration, puis la surveillance une fois le système en production.

Ce qu'un agent fait qu'une automatisation ne fait pas

La question utile n'est pas « faut-il un agent », mais « ai-je une décision à déléguer ». Tant que la réponse est non, une automatisation classique fera le travail pour un dixième du coût et sans les modes de panne décrits plus bas.

Trois exemples permettent de trancher rapidement, du plus simple au plus discutable.

• Envoyer une relance trois jours après un devis sans réponse : aucune décision, c'est une règle. Une automatisation suffit.
• Classer un email entrant dans l'une de vos dix catégories : une décision, mais toujours la même. Un appel à un modèle suffit, sans agent.
• Qualifier une demande entrante, chercher l'entreprise, croiser avec votre CRM, décider si le sujet mérite un rendez-vous et rédiger la réponse : plusieurs décisions enchaînées, dont le nombre d'étapes varie selon les cas. C'est le seul des trois qui justifie un agent.

Ce test évite l'erreur la plus courante en PME : payer la complexité d'un agent pour un besoin qu'un scénario de quinze lignes couvrait déjà.

Ce que ça coûte réellement

Les trois postes ci-dessous sont ceux que nous constatons sur nos propres systèmes en production. Les ordres de grandeur valent pour un agent qui traite quelques centaines à quelques milliers d'opérations par mois, ce qui est le cas courant dans une PME.

Un agent coûte donc peu à faire fonctionner et cher à faire tenir. C'est l'inverse de l'intuition que vend le marché, et c'est ce qui explique la section suivante.

Ce qui casse en production, et que personne ne raconte

Nous exploitons nos propres agents au quotidien, pas seulement pour des clients. Les trois pannes qui suivent nous sont arrivées, elles sont datées, et elles ont trois points communs : aucune n'était visible dans un tableau de bord, chacune a été aggravée par un dispositif censé protéger, et toutes se seraient reproduites si nous n'avions traité que le symptôme.

Le garde-fou qui amplifie la panne

Un agent qui publie du contenu s'est mis à produire des doublons. Nous avions posé un dispositif de reprise automatique : quand une exécution semblait échouer, elle était relancée. Ce garde-fou a transformé un incident en avalanche, parce que le processus n'était pas rejouable sans effet de bord. Une journée a produit douze publications pour trois entrées attendues.

Le même mécanisme s'est reproduit ailleurs, sur un service de messagerie : un surveillant l'a redémarré cent cinq fois en huit heures, parce que chaque redémarrage recréait la condition qui déclenchait le suivant. Le service, lui, n'avait jamais cessé de fonctionner.

La leçon tient en une phrase : sur un système qui n'est pas rejouable sans conséquence, une reprise automatique est un amplificateur de panne, pas une protection. Et tout dispositif qui redémarre doit savoir s'arrêter au bout de N tentatives, puis alerter un humain.

La clé d'unicité qui ne peut jamais entrer en conflit

Après le premier incident, nous avons fait ce que tout le monde fait : ajouter une clé d'unicité pour qu'une même opération ne puisse pas être enregistrée deux fois. La contrainte existait bien en base, la requête la déclarait correctement, et la documentation affirmait que le problème était réglé.

Il ne l'était pas, et il ne l'a pas été pendant deux mois. La valeur utilisée comme clé était régénérée à chaque exécution : deux enregistrements du même contenu portaient donc deux clés différentes, et le conflit qui aurait dû les bloquer ne pouvait jamais se produire.

La question à poser à quiconque vous vend un agent tient en une ligne : si ce traitement rejouait exactement la même journée, cette clé serait-elle identique ? Si la réponse est non, la protection est décorative.

Le capteur qui se déclare en bonne santé

C'est le mode de panne le plus coûteux, parce qu'il retire la capacité même de voir les autres. Un de nos contrôles quotidiens lisait des journaux pour repérer les tâches en échec. Le format de ces journaux était invalide, la lecture ne rendait donc jamais rien, et le contrôle affichait « aucune tâche en échec » quoi qu'il arrive. Six tâches étaient en échec, dont cinq depuis des mois.

Une variante plus subtile touche les indicateurs agrégés. Notre relevé d'espace disque n'a bougé que de trois points le jour où dix-neuf gigaoctets sont apparus, parce que neuf gigaoctets avaient été libérés dans le même intervalle. Deux mouvements opposés dans la même fenêtre de mesure produisent un indicateur parfaitement calme.

Un capteur doit donc distinguer trois états, et non deux : tout va bien, quelque chose ne va pas, et je n'ai pas su lire. Confondre le premier et le troisième revient à débrancher la surveillance en croyant l'avoir installée.

Ce qu'il faut poser en face

Ces trois pannes appellent des réponses qui ne coûtent presque rien si elles sont posées au départ, et très cher si elles sont ajoutées après un incident.

• Rendre chaque opération rejouable sans effet de bord, avec une clé stable qui ne dépend ni de la date ni du hasard.
• Mesurer poste par poste plutôt qu'en agrégé, avec un seuil calibré sur la taille normale de chaque poste.
• Nommer l'état « je n'ai pas su lire » partout où un contrôle interprète une donnée.
• Plafonner toute reprise automatique, et alerter un humain quand le plafond est atteint.
• Vérifier le résultat réel, jamais le code de retour : une publication peut répondre « succès » et n'exister nulle part.

Ce dernier point mérite d'être insisté. Un agent qui rapporte ses propres succès est juge et partie. La seule vérification qui vaut consiste à aller regarder l'artefact produit, dans l'outil de destination.

Quand ne pas déployer d'agent

Il y a trois situations où nous déconseillons un agent, même quand le cas d'usage semble s'y prêter.

• Quand personne, chez vous, ne sera responsable de le regarder chaque semaine. Un agent sans propriétaire dérive en silence.
• Quand la tâche produit un effet irréversible vers l'extérieur, sans étape de validation humaine possible.
• Quand la règle métier n'est pas stabilisée : un agent apprend mal une règle que vous êtes en train d'écrire, et vous paierez deux fois.

Dans ces trois cas, une automatisation classique avec validation humaine rend le même service, coûte moins cher et ne vous expose pas aux pannes décrites plus haut.

Notre façon de faire

Nous concevons ces systèmes et nous les exploitons, ce qui n'est pas la même chose que les livrer. Cette différence est la raison d'être de cet article : les trois pannes racontées ici viennent de nos propres agents, pas d'une veille technologique.

Ce mode de panne n'est pas propre à nos systèmes. Sur le pipeline de prospection d'Overpipe, que nous supervisons, les trois incidents les plus coûteux n'ont produit aucune erreur : le système répondait, et il ne produisait rien.

C'est ce que recouvre la supervision opérationnelle, surveiller un système qui ne se plaint jamais. Le détail de cette mission est publié dans notre étude de cas Overpipe.

Concrètement, tout changement passe par cinq contrôles avant d'atteindre la production : reproduire le défaut avant de le corriger, vérifier le résultat réel et non le code de retour, ne changer qu'une chose à la fois avec un retour arrière prêt, observer au moins une exécution réelle, et préférer une opération rejouable à un dispositif de reprise.

Si votre sujet est plus large que l'automatisation et touche au pilotage de vos opérations, la question du bon niveau d'intervention se pose avant celle de l'outillage. Nous l'avons traitée en détail dans notre article sur la direction marketing externalisée.