Évaluer les agents d’IA pour le marketing

Un agent d’IA n’est pas simplement un chatbot rebaptisé. Il reçoit un objectif, observe un état, choisit les étapes suivantes dans les limites fixées et peut utiliser des outils. Un workflow déterministe suit en revanche un chemin prédéfini. Et une agence est une entreprise de services. Qui confond ces trois notions achète facilement plus d’autonomie que le processus n’en supporte. Avant de recourir à un agent, il faut vérifier si un workflow déterministe ou une proposition d’IA avec validation humaine suffit.

Distinguer workflow, assistant, agent et agence

Un workflow exécute des étapes connues : si l’événement A se produit et que la condition B est remplie, l’action C suit. Un assistant d’IA produit, dans une seule étape, un résumé, une classification ou une ébauche. Un agent choisit dynamiquement les étapes intermédiaires et les outils qu’il utilise pour atteindre son objectif. Une agence marketing emploie des personnes et fournit des prestations convenues ; ce n’est pas un agent logiciel.

En pratique, le terme «agent» désigne des systèmes dans lesquels un modèle de langage pilote l’exécution et choisit dynamiquement les outils ; de simples chatbots ou des étapes isolées de grands modèles de langage (LLM) sans ce pilotage ne sont pas considérés comme des agents. Ces classements proviennent de guides de fournisseurs et ne constituent pas une norme. Il existe des formes hybrides. La question essentielle reste : le système peut-il seulement proposer un texte, ou peut-il décider lui-même quel système il interroge ensuite et quelle action suit ?

N’envisager l’autonomie que pour une véritable imprévisibilité

Un agent peut être judicieux lorsque le chemin de résolution ne peut pas être décrit entièrement à l’avance, que plusieurs sources d’information doivent être choisies selon la situation et qu’une suite limitée d’étapes est nécessaire. Un exemple utile est la préparation interne d’un briefing : l’agent vérifie quelles sources autorisées manquent pour répondre à une question claire, n’appelle que des outils de lecture et produit une synthèse étayée à des fins de vérification. De tels exemples ne contiennent aucune donnée client et ne promettent aucun résultat.

Lorsque toutes les ramifications sont connues, un workflow est plus facile à tester et à expliquer. Si seule une ébauche est nécessaire, un assistant suffit. La planification dynamique entraîne des coûts, une latence et des possibilités d’erreur supplémentaires. L’architecture la plus simple qui suffit réduit donc la complexité et les causes d’échec possibles. «Agentique» n’est pas en soi un gage de qualité.

Limiter le mandat à une phrase

Avant un pilote, l’agent a besoin d’un mandat : «Il peut, pour la tâche A et durant la période B, utiliser les outils de lecture C, traiter des informations issues des sources D, exécuter au maximum E étapes et produire une proposition pour le rôle F ; il ne peut déclencher aucune modification externe.» Cette phrase nomme l’objectif, la durée, les outils, les données, le nombre maximal d’étapes, le résultat et l’autorité.

Une mission ouverte comme «Optimise le marketing» est trop large pour un premier pilote. L’agent pourrait inventer de nouveaux objectifs, relier des données non vérifiées ou améliorer un indicateur qui contredit la finalité commerciale. L’objectif doit être observable et des indicateurs de protection doivent l’accompagner : des mesures qui ne doivent pas se dégrader. Un traitement plus rapide ne doit par exemple pas se payer par davantage d’affirmations non étayées ou par une vérification métier réduite.

Contrôler les outils au moyen d’une matrice d’autorisations

Chaque outil reçoit un niveau d’autorisation concret : lire, rechercher, proposer, enregistrer une ébauche ou modifier. Ces niveaux ne sont pas équivalents. Un accès en recherche peut déjà rendre visibles des informations confidentielles. Un accès en écriture peut modifier un enregistrement réel. Une publication externe ou une modification de budget a un effet immédiat. L’agent ne reçoit que l’autorisation la plus restreinte nécessaire au mandat.

Les identifiants d’accès sont conservés dans un gestionnaire sécurisé d’identifiants et jamais dans un prompt. Les réponses des outils sont traitées comme des entrées non fiables. Un site web, un document ou un champ CRM peut contenir un texte qui demande à l’agent d’exécuter une étape non autorisée. De telles tentatives d’injection de prompt ne doivent pas remplacer le mandat système ni les autorisations. Les listes d’autorisation techniques, la validation des entrées et une couche d’approbation des actions sont plus fiables que la consigne «Ignore les instructions dangereuses» dans le prompt.

La mémoire est un stockage de données, pas de la magie

Un agent peut mémoriser du contexte pendant l’exécution en cours, entre les étapes ou sur plusieurs exécutions. Chaque forme présente des risques différents. Le contexte à court terme peut contenir des données personnelles inutiles. La mémoire à long terme peut conserver des hypothèses périmées et influencer des tâches ultérieures. C’est pourquoi le contenu, la finalité, le lieu de stockage, la durée de validité, l’accès et la règle de suppression sont documentés pour chaque type de mémoire.

Un réglage par défaut utile est «aucune mémoire persistante» tant qu’un besoin clair n’est pas établi. Lorsque la mémorisation devient nécessaire, le système enregistre des faits structurés et vérifiés plutôt que des conversations entières. Les utilisateurs doivent pouvoir déclencher des corrections. Un enregistrement supprimé ou révoqué ne doit pas survivre sous forme de résumé caché.

Le droit suisse de la protection des données s’applique directement lorsque des données personnelles sont traitées avec de l’IA. Le Préposé fédéral à la protection des données et à la transparence (PFPDT) insiste sur la transparence des finalités, l’information sur le fonctionnement et les sources de données ainsi que sur des mesures de protection proportionnées au risque. Déterminer s’il y a profilage, décision individuelle automatisée pertinente ou risque élevé exige un examen concret. Une étiquette «agent» ne change rien à ces obligations.

Placer la validation humaine avant une action dans un système externe

«Human in the loop» n’est utile que si une personne voit l’information déterminante, dispose de suffisamment de temps et peut arrêter l’action. Une validation unique au début du projet ne suffit pas pour des actions imprévues ou étendues. Un mandat permanent peut en revanche couvrir des actions bien définies dans ses limites ; il reste valable tant que l’objectif, le périmètre et les conditions ne changent pas. Avant un effet externe, l’écran de validation montre l’objectif, les sources utilisées, l’action prévue, l’élément concerné, la version du modèle et du prompt ainsi que les incertitudes identifiées. La validation porte précisément sur cette version.

Si un projet individuellement validé est modifié par la suite, sa validation devient caduque ; une modification en dehors du mandat permanent exige une nouvelle décision. Les actions à fort impact ne sont pas regroupées derrière un unique bouton «Tout confirmer». Pour les premiers pilotes, l’autorisation la plus élevée reste «créer une proposition». Une action en production ultérieure exige une décision de risque distincte et une autorisation technique traçable et strictement limitée.

Limiter la durée d’exécution, les coûts et les boucles

Un agent dynamique peut entrer dans une boucle, interroger la même source de façon répétée ou interpréter sa mission de manière toujours plus large. Fixez un nombre maximal d’étapes, une durée d’exécution, un nombre d’appels d’outils et un coût maximal par mission. Définissez quelles opérations peuvent être retentées une fois après une erreur et lesquelles imposent un arrêt immédiat. Une requête ne doit pas être répétée automatiquement si elle pouvait produire un double effet externe.

L’agent a besoin d’états finaux explicites : objectif atteint, preuves insuffisantes, clarification humaine nécessaire, limite technique atteinte ou arrêt. Un «best effort» sans statut visible fait apparaître des résultats incomplets comme un travail achevé. Une source manquante doit apparaître comme une lacune, et non disparaître derrière une plausibilité inventée.

Tenir des journaux pour l’explication et la reconstitution

Une exécution auditable consigne la mission, l’autorité, les sources d’entrée, les appels d’outils, les décisions, les sorties, les validations, l’autorisation, les erreurs et l’état final. Les secrets et les données personnelles inutiles n’ont pas leur place dans le journal. Les contenus sensibles exigent un contrôle d’accès et des durées de conservation. Un journal n’est pas une fin en soi ; un rôle désigné doit pouvoir retrouver une exécution problématique, l’expliquer et l’arrêter. Il documente les actions, les preuves et les validations – et non le processus de réflexion interne d’un modèle.

Les guides des fournisseurs citent le modèle, les outils et les instructions comme éléments de base et décrivent des garde-fous ainsi que des conditions d’arrêt claires. L’initiative «Agentic AI Security» de l’OWASP signale en complément des questions de sécurité propres aux systèmes agentiques connectés à des outils. Ces deux apports constituent une orientation technique : ni loi suisse, ni certification, ni preuve de sécurité. Les responsabilités, les dommages possibles, les tests et la gestion continue des risques doivent être définis pour le système concret ; ces sources ne remplacent pas un modèle de menaces propre au système.

Tester les comportements indésirables

Les tests du cas normal ne suffisent pas. Un jeu de tests doit au minimum contenir : des sources contradictoires, une autorisation manquante, une réponse d’outil manipulée, une injection de prompt dans un document, une mémoire périmée, un outil inaccessible, une limite d’étapes et un arrêt humain. Pour chaque cas, l’état final sûr attendu est défini à l’avance.

Testez également le glissement d’objectif. L’agent tente-t-il de contourner un indicateur de protection parce qu’il atteint ainsi plus vite l’objectif principal ? Demande-t-il des autorisations supplémentaires ? Cache-t-il des preuves manquantes ? En cas d’autorisation manquante, l’action est interrompue : le pilote s’arrête et transmet le problème à la personne responsable au lieu d’interpréter lui-même les règles de manière plus généreuse.

Ne pas confondre succès et autonomie

Les indicateurs comprennent les états finaux corrects, les erreurs d’outils, les propositions refusées, les corrections humaines, les boucles, les coûts et le temps. Ces valeurs d’exploitation montrent que le système reste maîtrisable. Elles ne prouvent aucun effet marketing supplémentaire. Un agent qui nécessite moins d’interventions humaines n’est pas automatiquement meilleur ; peut-être que les erreurs sont simplement découvertes plus tard.

La qualité métier du résultat exige une vérification distincte, définie à l’avance. Ce n’est que si une comparaison contrôlée montre une amélioration pertinente et que les indicateurs de protection restent stables qu’une extension peut être discutée. Même dans ce cas, l’autorité ou l’accès aux données ne sont pas élargis automatiquement.

La décision concernant le pilote

Un pilote d’agent n’est prêt que lorsqu’un workflow ne devrait vraisemblablement pas remplir la finalité de manière suffisante et que le mandat, les autorisations d’accès aux outils, les données, la mémoire, les validations, les journaux, les budgets, les tests et les signaux d’arrêt sont entièrement décrits. Sinon, un workflow déterministe ou un assistant est la solution la plus facile à contrôler.

Comment maitiq aide : du signal à la tâche accomplie

Un agent utile peut lire un rapport autorisé, détecter un écart et préparer une tâche avec la campagne concernée, les données de base et une proposition d’action. Qu’il crée cette tâche sous forme d’ébauche ou qu’il l’écrive directement dans un système relève d’une décision distincte. Pour une mise à jour de budget, la capacité d’analyse de texte ne suffit pas.

Mesurez les tâches correctement accomplies, les corrections nécessaires et les exceptions passées inaperçues. maitiq accompagne la conception de ce processus et son intégration dans votre équipe. Dans le produit Google Ads, les propositions sont traçables et leur mise en œuvre reste dans le cadre de l’autorisation enregistrée ; une automatisation configurée peut valider et appliquer dans les limites de ses contrôles. Les décisions humaines restent importantes sans que chaque mise en œuvre soit validée manuellement. Les fonctions d’agent supplémentaires sont convenues concrètement dans le cadre du projet.

Comment débute un premier pilote avec maitiq

Une étude de cadrage limitée montre quelle tâche d’agent est réellement nécessaire, où un workflow normal suffit et quels contrôles sont requis pour un pilote. Vous recevez un cas d’usage clairement délimité, les questions ouvertes sur les données et les contrôles, un plan de pilote et les critères pour une exploitation ultérieure.

Règle de décision : Commencez en lecture seule ; n’autorisez ensuite qu’une action strictement limitée, avec sa propre autorisation et une vérification observable.

Sources et mise en perspective

Les quatre sources ont des rôles différents : le guide pratique d’OpenAI décrit la construction d’un agent – modèle, outils et instructions –, le rôle des outils, la fin d’une exécution et les contrôles que l’on peut superposer. L’annonce d’OpenAI «New tools for building agents» (11 mars 2025) étaye la définition de l’agent telle qu’elle prévalait alors, et non les spécifications d’API ou les prix actuels. L’initiative «Agentic AI Security» de l’OWASP apporte une mise en perspective de sécurité ciblée sur les systèmes agentiques connectés à des outils. Le PFPDT précise le cadre de la protection des données pour le traitement de données personnelles avec l’IA. Des informations sur la manière de travailler de maitiq sont disponibles sur maitiq.com.

Faites examiner votre cas concret par maitiq.