Comment choisir des outils d’IA pour le marketing

Une sélection solide ne commence pas par des noms de fournisseurs, mais par une tâche de test définie. Clarifiez d’abord quelle tâche doit être remplie, quelles données sont admissibles, quels droits doivent être réglés et quelles exigences sont obligatoires. Ce n’est qu’une fois les critères obligatoires et les règles d’acceptation fixés qu’une présélection vaut la peine.

Transformer le cas d’usage en tâche vérifiable

«Nous avons besoin d’un outil IA pour le marketing» n’est pas une exigence vérifiable. Formulez cette tâche comme un travail observable : «À partir d’un dossier produit approuvé, produire trois projets de texte au format demandé et rattacher chaque affirmation factuelle à une source.» Ou : «Rechercher les anomalies définies dans un tableau de données de campagne et marquer les occurrences, sans modifier le compte publicitaire.»

La tâche nomme les entrées, les sources autorisées, le format de sortie, les critères de qualité, les actions exclues et le rôle chargé de la vérification. Elle sépare l’obligatoire du souhaitable. Une intégration au CRM peut devenir importante plus tard, mais n’est peut-être pas indispensable pour un premier test hors ligne. En revanche, l’absence de suppression des données, des droits d’utilisation flous ou des droits d’écriture impossibles à limiter constituent déjà des motifs d’exclusion.

Comparer des catégories d’outils plutôt que des noms de produits

Un assistant général peut traiter de nombreux formats, mais exige des modèles de documents et des contrôles clairs. Un outil spécialisé couvre une tâche plus étroite, par exemple des variantes d’images, la transcription ou l’analyse. Une fonction IA intégrée se trouve déjà dans un système marketing ou publicitaire et reprend partiellement ses identités et ses autorisations. Une plateforme d’orchestration relie plusieurs étapes et systèmes. Un composant exploité en propre offre plus de contrôle technique, mais exige des connaissances internes en modèles, sécurité et exploitation.

Ces catégories ne sont pas automatiquement meilleures ou moins bonnes. Elles déplacent la responsabilité. Un outil intégré peut être accessible plus vite, mais reste lié au cadre de données et d’autorisations de la plateforme. Une API ouverte peut sembler flexible, mais l’intégration, le monitoring et le traitement des erreurs incombent alors à votre propre équipe. Inscrivez ce déplacement de responsabilité dans le document de décision.

Vérifier d’abord les exigences obligatoires

Une note globale ne doit pas masquer un défaut fondamental. Définissez d’abord les exigences obligatoires. Le fournisseur peut-il expliquer la finalité prévue des données et les sous-traitants impliqués ? La conservation, la suppression et l’export sont-ils vérifiables ? L’utilisation des entrées pour l’entraînement ou l’amélioration du produit peut-elle être configurée de manière appropriée ou clarifiée par contrat ? Les rôles et les droits peuvent-ils être limités à la tâche ? Existe-t-il une procédure traçable pour traiter les incidents et les changements de service ?

Pour les contenus et les visuels s’ajoutent des questions de droits. Quelles assurances le fournisseur donne-t-il sur les entrées et les sorties, et quelles clauses d’indemnisation propose-t-il ? Quelles obligations restent à votre charge ? L’IPI (Institut fédéral de la propriété intellectuelle) signale que, lors de l’usage de l’IA, différents processus techniques et d’éventuels droits sur l’entrée et la sortie doivent être appréciés séparément. Une validation marketing ne remplace pas un examen des droits.

Si un outil échoue sur une exigence indispensable à la tâche, une bonne ergonomie ne compense pas ce manquement. Le verdict est «inadapté à cette tâche» ; pour une autre tâche, moins sensible, l’appréciation peut être différente.

Vérifier la qualité avec un jeu de tests fixe

Les démos en direct sont utiles pour l’exploration, mais peu comparables. Créez un petit jeu de tests représentatif avec des données synthétiques ou approuvées. Il contient des cas simples, des cas limites, des indications manquantes, des sources contradictoires et une demande volontairement inadmissible. Tous les candidats reçoivent des entrées, des données et des exigences de qualité équivalentes ; des prompts identiques ne sont pas judicieux pour des outils différents. Consignez la configuration documentée et la version que vous pouvez réellement consulter. Les informations non consultables sont signalées comme telles et ne constituent pas un motif d’exclusion automatique.

N’évaluez pas seulement «j’aime bien». Pour le texte, les critères peuvent être l’exactitude factuelle, la référence aux sources, l’exhaustivité, le ton, le format et l’effort de correction. Pour l’analyse, vérifiez l’exactitude des constats, leur reproductibilité, le traitement des valeurs manquantes et la présentation des incertitudes. Pour les visuels s’ajoutent la conformité à la marque, les artefacts, les mentions de droits et les formats techniques. Une personne compétente évalue en aveugle dans la mesure du possible.

Une moyenne seule ne suffit pas. Montrez les types d’erreurs et la dispersion. Un outil qui résout bien neuf cas anodins mais publie une affirmation non étayée sur le dixième cas critique a besoin d’un dispositif de vérification plus strict. Notez aussi quand le système refuse correctement ou rend l’incertitude visible. Une escalade maîtrisée peut avoir plus de valeur qu’une réponse trop assurée.

Vérifier la protection des données et la sécurité sur le flux réel

Le PFPDT rappelle que la LPD suisse s’applique directement au traitement assisté par IA de données personnelles. L’examen ne suit donc pas l’étiquette «IA», mais la finalité, les données, les destinataires, la transparence et le risque du traitement concret. Établissez une carte des flux de données pour chaque candidat au test : quels champs quittent quel système ? Dans quelle région sont-ils traités ? Comment les demandes d’accès, de rectification et de suppression sont-elles transmises et exécutées chez les sous-traitants qui traitent les données pour le fournisseur ?

Évitez les données personnelles réelles dans le premier pilote. Les identifiants d’accès, les jetons et les secrets internes n’ont pas leur place dans les prompts. OWASP souligne qu’un prompt système ne doit pas être traité comme un secret ou un contrôle d’autorisation. Vérifiez les rôles réels, les identifiants de courte durée, la journalisation et la séparation des droits de lecture et d’écriture. Vérifiez si les contrôles recommandés sont réellement mis en œuvre pour chaque intégration.

Même un connecteur «en lecture seule» peut exposer des données étendues. Les objets, champs, comptes et périodes peuvent-ils être limités ? Une validation humaine peut-elle être techniquement imposée avant un effet externe ? Que se passe-t-il en cas d’injection de prompt depuis un document ou un site web ? Ces questions relèvent d’un examen de sécurité et, le cas échéant, d’un test technique ; un questionnaire seul ne prouve aucune sécurité. Les autorisations relèvent de règles déterministes hors du modèle, pas du prompt.

Intégration et exploitation : deux postes de coûts distincts

Le prix de licence ne montre pas le coût d’exploitation complet. S’y ajoutent la configuration, les interfaces, la gestion des identités, les tests, les vérifications métier, le monitoring, la formation, le traitement des incidents et la sortie. Cet article ne cite volontairement aucun prix de marché : chaque offre devrait en revanche présenter le même périmètre, afin que les différences apparaissent. Suivez deux indicateurs distincts, sur la même période et pour la même population de test : d’une part le coût total en CHF par résultat accepté, d’autre part le temps de vérification humaine en minutes par résultat accepté. Si vous monétisez ce temps, indiquez le tarif horaire retenu et comptez-le une seule fois dans le coût total : n’additionnez jamais des heures et des francs et ne comptez pas deux fois cette main-d’œuvre. Sans résultat accepté, aucun des deux ratios n’est calculable. Une donnée manquante reste manquante : elle n’est pas additionnée comme un zéro, ne se confond pas avec un coût connu nul et ne bloque que l’indicateur qui en dépend.

Ne vérifiez pas la documentation API seulement par sa présence. Les points de terminaison, limites, webhooks, versions et messages d’erreur nécessaires sont-ils documentés ? Existe-t-il un bac à sable ? Les données et configurations peuvent-elles être exportées ? Qui informe des changements de modèle ou de produit ? Un outil qui donne de bons résultats sur des cas isolés peut ne pas convenir si son exploitation ne s’intègre pas à l’organisation.

Désignez en outre une personne responsable de l’exploitation. Elle ne répond pas du modèle au sens abstrait, mais de l’usage concret : utilisateurs, modèles de documents, sources, taux de vérification, incidents et décision d’arrêt. Service métier, IT, sécurité, protection des données et achats ont des rôles de vérification différents. Une matrice RACI rend visible qui décide, qui contribue et qui est seulement informé.

Tester la sortie avant la conclusion du contrat

Une sortie crédible répond : vos propres données, vos modèles de documents, vos cas d’évaluation, vos journaux et vos configurations peuvent-ils être exportés ? Dans quel format ? Comment les données stockées sont-elles supprimées et comment cela est-il documenté ? Quels workflows s’arrêtent si le service cesse ? Existe-t-il un repli manuel ? Quelles dépendances de modèle ou d’API doivent être remplacées ? Un tel test relève d’un pilote convenu et isolé ; ce n’est pas une invitation à désactiver un système en production. De nouveaux usages, données ou actions nécessitent un examen propre du périmètre concerné.

Les lignes directrices officielles britanniques actuelles pour le développement, la livraison et l’acquisition d’outils d’IA générative traitent l’introduction comme une tâche organisationnelle, avec formation, support, gestion des risques et monitoring. Pour le pilote décrit ici, testez également la procédure de sortie avant de signer le contrat. Réalisez au moins un export et une désactivation pendant le pilote. Un export promis seulement sur le papier n’a encore rien d’un retour arrière testé.

Évaluer aussi la capacité de l’équipe à travailler avec l’outil

Un pilote peut convaincre techniquement et échouer malgré tout sur le plan organisationnel. Vérifiez si les personnes responsables comprennent les résultats, reconnaissent les erreurs et peuvent utiliser le processus sans démo du fournisseur. Une journée de test dans des conditions idéales dit peu de chose sur la suppléance, les congés, les conflits de priorité ou un incident. Simulez donc une question de suivi, un résultat erroné, un utilisateur bloqué et une désactivation avec un très court préavis.

La documentation est vérifiée sur une tâche concrète : une personne nouvelle dans l’équipe peut-elle suivre le cas d’usage approuvé, les sources de données, les critères de vérification et la procédure d’arrêt ? L’IT peut-elle retirer des droits sans bloquer d’autres systèmes ? La fonction achats peut-elle reconnaître une modification importante du produit et réexaminer le contrat ? Un bon article d’aide ne remplace pas une instruction d’exploitation propre à l’organisation.

Intégrez aussi la courbe d’apprentissage dans la décision. Consignez les besoins de formation, les questions de support récurrentes et les types de correction, sans en tirer un chiffre de productivité inventé. Si une seule personne maîtrise l’outil en sécurité, il existe un risque d’exploitation. Si l’équipe doit recréer entièrement chaque résultat, c’est probablement que le besoin est mal défini ou que l’outil est inadapté. Ces constats peuvent mener à un périmètre plus étroit plutôt qu’à un déploiement précipité.

Avant toute extension, le jeu de tests fixe est exécuté à nouveau. Les changements de modèle, de politique ou d’interface font l’objet d’une nouvelle évaluation. La note d’acquisition initiale n’est pas un label de qualité permanent.

Décider : écarter, piloter de manière limitée ou approfondir

À la fin, il n’y a pas seulement «acheter» ou «ne pas acheter». Un candidat peut être écarté en raison d’une exigence obligatoire. Il peut réussir un pilote hors ligne limité, mais nécessiter encore des clarifications de sécurité ou de contrat. Ou il peut être approuvé pour une seule tâche, tandis que les intégrations et les actions dans les systèmes en production restent bloquées. Consignez explicitement le périmètre.

Comment maitiq peut vous aider : tester le même lot de travail avec tous les candidats

Pour la sélection, utilisez un briefing approuvé, les mêmes données sources et la même sortie attendue. Consignez les erreurs métier, la reprise manuelle, l’exportabilité ainsi que les deux indicateurs du chapitre sur l’intégration et l’exploitation : le coût en CHF par résultat accepté et le temps de vérification humaine par résultat accepté. Toutes ces valeurs se rapportent à la même période et à la même population de test. Un abonnement bon marché coûte cher si l’équipe doit reconstruire chaque résultat.

Dans le cadre d’un pilote convenu, maitiq intervient sur le processus : quelle tâche doit s’améliorer ou être automatisée, quelle responsabilité reste de votre côté et comment la solution s’insère dans vos systèmes. Un comparatif d’outils devient ainsi une décision applicable. Seule une mise à l’épreuve réussie justifie une introduction plus large.

Comment démarrer un premier pilote avec maitiq

Une étude de cadrage limitée permet de définir le cas d’usage, les questions à résoudre et le protocole du pilote ; elle indique aussi quelle catégorie d’outil convient à la tâche, quelles exigences obligatoires restent ouvertes et comment mettre sur pied un pilote restreint. maitiq peut mener cette étude avec vous. Vous recevez une tâche clairement délimitée, les questions encore ouvertes sur les données et les contrôles, un plan de pilote et les critères pour décider si l’outil est prêt pour l’exploitation.

Règle de décision : Définissez d’abord la tâche et les motifs d’exclusion ; comparez ensuite la qualité, l’intégration, les coûts d’exploitation et le temps de vérification par résultat accepté, ainsi que la sortie testée.

Sources et repères d’interprétation

Ces quatre sources couvrent différents champs de vérification : le PFPDT explique comment la LPD suisse s’applique au traitement de données personnelles assisté par IA, l’IPI (Institut fédéral de la propriété intellectuelle) situe les questions de droit d’auteur liées à l’entraînement et à l’usage de l’IA, la ligne directrice britannique décrit l’introduction d’outils d’IA générative comme une tâche organisationnelle, et OWASP nomme la fuite de prompt système, un risque dont découle la vérification des rôles et des secrets. Les deux premières publications sont en allemand, les deux autres en anglais. Lisez ces sources comme la base des étapes de vérification décrites ici, non comme une promesse pour un outil ou un résultat donné.

Faites examiner votre cas concret par maitiq.