Mettre en place une gouvernance de l’IA en marketing

La gouvernance de l’IA en marketing réunit l’essentiel : inventaire, règles, rôles, preuves et moyens d’arrêter le système. Elle répond à cinq questions pour chaque cas d’usage : à quoi sert le système ? quelles données peut-il traiter ? quel résultat ou contenu produit et quelle action peut-il générer ? quelle personne décide ? que se passe-t-il en cas d’erreur ou de changement ? Une politique sans ces réponses opérationnelles reste lettre morte ; un outil sans règles reste non maîtrisé.

Pour les équipes suisses, la gouvernance commence par des responsabilités claires et des devoirs concrets en matière de données. Le Préposé fédéral à la protection des données et à la transparence (PFPDT) rappelle que la loi sur la protection des données, technologiquement neutre, s’applique au traitement de données personnelles assisté par IA. Selon le traitement, la transparence et, pour les décisions individuelles automatisées, leur vérification entrent en jeu ; en cas de risque élevé s’y ajoute une analyse d’impact relative à la protection des données. Savoir quelle obligation s’applique dans un cas marketing concret exige un examen métier et juridique.

1. Un inventaire qui permet de décider

Recensez chaque système d’IA utilisé ou testé en pilote, y compris les fonctions intégrées à des plateformes existantes. Chaque entrée doit au minimum contenir : la finalité, la personne responsable, les groupes d’utilisateurs, les personnes concernées, le fournisseur et la version, les sources de données, les intégrations, le type de sortie, l’action autorisée, la validation humaine, la conservation, le niveau de risque, le dernier test et la prochaine revue.

Un nom de produit ne suffit pas. La même application peut servir à générer des idées à partir d’informations publiques, à des briefings confidentiels ou à une approche client personnalisée. Ces usages impliquent d’autres données et d’autres conséquences. Tenez donc une entrée d’inventaire par cas d’usage, et non par licence.

L’inventaire fait aussi office de porte d’entrée. Une nouvelle finalité, une nouvelle source de données ou une nouvelle action automatisée constitue un changement qui doit être réexaminé. L’équipe évite ainsi qu’un pilote anodin ne se transforme insensiblement en processus de production non autorisé.

2. Usages autorisés, restreints et interdits

Une politique compréhensible décrit des activités concrètes. «Utiliser l’IA de manière responsable» n’est pas une consigne applicable. Mieux vaut trois catégories avec des exemples :

Autorisé : par exemple collecter des idées à partir d’informations publiques et validées, à condition que les résultats ou contenus produits soient traités comme des brouillons et vérifiés.

Uniquement après validation : résumer des documents internes, classer les retours clients, établir des prévisions, personnaliser des contenus ou intégrer des systèmes. Ici, la finalité, les données, le contrat, les tests et le contrôle humain doivent être clarifiés.

Interdit : saisir des mots de passe, des clés secrètes ou des données confidentielles, personnelles ou sensibles non validées dans un outil public et non maîtrisé ; publier des affirmations non vérifiées ; interpréter une possibilité d’accès technique comme une validation.

L’Office fédéral de la cybersécurité (OFCS) recommande de ne pas saisir de données personnelles, sensibles ou confidentielles de clients ou d’entreprise dans des applications d’IA, de lire les conditions d’utilisation et de remettre en question les réponses avec esprit critique. Cette règle de sécurité générale est une bonne base conservatrice, mais elle ne remplace pas une classification des données propre à votre entreprise.

3. Des règles de données sur l’ensemble du flux

Pour chaque cas, le flux de données doit être visible de la source à la suppression. Clarifiez les points suivants :

• D’où viennent les données et dans quelle finalité ont-elles été collectées ?
• Des données personnelles, des contenus confidentiels ou des œuvres protégées sont-ils traités ?
• Quels champs sont réellement nécessaires et lesquels peuvent être supprimés ou anonymisés ?
• Où les entrées, les métadonnées et les résultats ou contenus produits sont-ils transmis ?
• Un fournisseur utilise-t-il les entrées pour l’amélioration ou l’entraînement ?
• Qui obtient l’accès, combien de temps les données sont-elles conservées et comment sont-elles supprimées ?
• Quels sous-traitants et quels pays sont impliqués ?
• Comment les personnes concernées obtiennent-elles les informations nécessaires ou un réexamen ?

Les réponses n’ont pas leur place dans une présentation unique, mais dans une fiche de données versionnée. Contrats, configuration technique et comportement réel doivent concorder. Si une question reste ouverte, l’accès aux données réelles reste bloqué ou le pilote utilise des données synthétiques appropriées.

La protection des données n’est pas le seul niveau de droits en jeu. L’Institut fédéral de la propriété intellectuelle (IPI) signale que du matériel manifestement protégé dans des résultats ou contenus produits par l’IA peut soulever des questions de droits et que la contribution créative humaine peut être pertinente pour une éventuelle protection du résultat. Un workflow marketing a donc besoin d’une vérification des sources, des licences et de l’originalité, en particulier pour le texte, l’image, l’audio et la vidéo.

4. Des rôles humains dotés d’une réelle autorité

Le «human in the loop» ne devient un contrôle que lorsque quatre points sont nommés : qui vérifie, ce que cette personne voit, quand elle décide et quel pouvoir elle détient. Une personne qui ne reçoit un résultat qu’après sa publication ou après la modification d’un budget ne constitue pas une validation en amont.

Une répartition allégée des rôles peut se présenter ainsi :

• Le responsable métier porte la finalité, le bénéfice et le risque résiduel.
• Le responsable du cas d’usage couvre le processus, la qualité et la revue.
• Le responsable des données valide les sources, les accès et la conservation.
• La protection des données, le droit et la sécurité disposent de points de contrôle définis et de la possibilité d’arrêter le système.
• Les utilisateurs respectent leurs obligations de saisie, de vérification et de signalement.
• Le responsable des incidents coordonne la limitation des conséquences, l’analyse et la communication.

Une même personne peut assumer plusieurs rôles, mais aucune responsabilité ne doit disparaître. Lorsque l’impact est plus élevé, la même personne ne devrait pas construire le système, l’évaluer seule et accepter le risque résiduel.

5. Des niveaux de risque internes comme outil d’exploitation

Les équipes marketing peuvent procéder à un triage interne simple. Celui-ci ne constitue pas une classification légale.

Niveau A – assistance avec un résultat interne facilement corrigeable : données publiques ou validées, aucune action automatique, vérification qualifiée avant utilisation.

Niveau B – influence sur des contenus publiés, des analyses ou des recommandations opérationnelles : vérification supplémentaire sur le plan métier, des droits et des sources ; tests documentés et monitoring.

Niveau C – données personnelles, traitement individuel, action sur le budget ou sur des clients, conséquences difficilement réversibles : examen formel de la protection des données, du droit, de la sécurité et de la direction ; périmètre restreint ; validations strictes ; plan d’incident et de repli.

Le niveau dépend de l’usage et de l’impact, pas du nom marketing de l’outil. Si l’action passe de «proposition» à «exécution automatique», une nouvelle classification s’impose.

6. Tester avant d’accorder de l’autorité

Un test conforme à la gouvernance dispose de données validées, de cas définis à l’avance et d’une référence. Il n’évalue pas seulement la qualité moyenne, mais aussi les erreurs critiques, les omissions, les biais, les questions de droits, les corrections nécessaires et le comportement hors du contexte prévu.

Documentez la version du modèle ou du produit, la configuration, les données de test, les personnes chargées de l’évaluation, le résultat et les écarts. Le principe de responsabilité (accountability) de l’OCDE souligne la traçabilité des jeux de données, des processus et des décisions. En marketing, cela donne une règle pratique : une validation doit pouvoir expliquer plus tard sur quelles preuves elle reposait.

L’autorité s’accorde par étapes. Un système peut d’abord fournir des brouillons, puis éventuellement des recommandations dans un périmètre plus restreint. Une action dans un système en production exige une autorisation technique distincte et une validation métier. L’autorisation d’installer et d’utiliser un système ne vaut pas, à elle seule, pour chaque changement qu’il peut apporter. Un mandat commercial documenté séparément peut couvrir des actions définies dans ses limites ; les actions déjà couvertes n’exigent pas une validation en double.

7. Transparence et contenus générés par l’IA

La transparence a plusieurs destinataires. Les collaborateurs doivent savoir quand ils utilisent l’IA et quelles limites s’appliquent. Les personnes qui vérifient ont besoin des sources, de la configuration et du degré d’incertitude. Les personnes concernées peuvent, selon le traitement, avoir besoin d’informations sur la finalité, le fonctionnement ou les décisions automatisées. Le public et les clients ont, dans certaines situations, besoin d’une indication reconnaissable qu’un contenu est généré par l’IA ou manipulé.

Aucune affirmation générale n’est possible en présence d’un lien avec l’UE. La Commission européenne indique que l’AI Act est en principe applicable depuis le 2 août 2026, avec des exceptions et des délais transitoires modifiés. Savoir si une entreprise suisse, un système ou un résultat ou contenu marketing concret entre dans le champ d’application doit être examiné sur le plan juridique.

Une mention volontaire de l’utilisation de l’IA peut en outre renforcer la confiance, mais elle ne doit pas remplacer un examen juridique. De même, une simple mention ne suffit pas si le traitement lui-même est illicite ou trompeur.

8. Contrôler les fournisseurs et les plateformes intégrées

La fonction achats n’examine pas seulement le fournisseur à la date du contrat. Elle définit les changements qui doivent être annoncés : changement de modèle, nouvel usage des données, sous-traitants, lieu de stockage, logique tarifaire, fonction de sécurité ou limite de prestation essentielle.

Exigez, pour le cas concret, le flux de données, les rôles, la suppression, le canal de signalement en cas de panne, les possibilités de test, les notes de version, l’export des données et les modalités de résiliation. Une fiche de sécurité générale est utile, mais elle ne dit pas automatiquement comment une intégration marketing fonctionne avec vos autorisations.

La même logique s’applique aux fonctions des plateformes publicitaires, CRM ou de contenu. Une fonction d’IA activée par défaut doit figurer à l’inventaire dès qu’elle traite des données pertinentes ou influence des décisions. Le confort d’une plateforme ne dispense pas de gouvernance.

9. Monitoring, incidents et droits d’arrêt

Surveillez des indicateurs adaptés aux conséquences d’une erreur : erreurs factuelles critiques, affirmations non étayées, violations de droits, accès non autorisés aux données, ciblages erronés, actions erronées, corrections nécessaires, coûts ou dérive après une mise à jour. Un simple compteur d’utilisation ne démontre aucun contrôle.

Le processus d’incident doit être connu avant d’en avoir besoin. Les utilisateurs savent qui contacter et comment arrêter le workflow concerné. La personne responsable des incidents peut bloquer des accès, arrêter des intégrations ou revenir au processus manuel. Les preuves et les journaux sont conservés de manière appropriée. Les rôles de la protection des données, de la sécurité, du droit et de la communication sont impliqués selon des critères définis.

Après un incident, la cause est identifiée et analysée, puis viennent la correction, un nouveau test et une décision explicite de redémarrage. Toute erreur n’est pas un incident soumis à déclaration, mais tout schéma critique mérite une réaction documentée.

10. Modification et mise hors service

Les systèmes d’IA évoluent. Définissez les changements qui déclenchent des tests de non-régression ou une nouvelle validation : version du modèle, prompt, source de données, groupe cible, canal, autorisation, seuil ou fournisseur. Comparez les nouveaux résultats avec un jeu de tests stable et les indicateurs de protection.

La gouvernance couvre aussi la fin. Le plan de sortie nomme l’export des données, le blocage du compte, la confirmation de suppression, l’archivage des justificatifs nécessaires, le processus de remplacement et la communication. Un système sans personne responsable, sans utilité ou sans fournisseur maîtrisable ne continue pas simplement d’être payé : il est mis hors service de manière ordonnée.

Le dossier de gouvernance minimal

Pour un petit pilote marketing, cent pages ne sont pas nécessaires, mais six documents devraient exister : la fiche de cas d’usage, la fiche de données, la matrice des rôles et des validations, le protocole de test et de preuves, la fiche d’exploitation et d’incident, ainsi que le plan de modification et de sortie. Chaque document a une personne responsable, une version et une date de revue.

Ce dossier rend la responsabilité visible sans bloquer toute idée par avance. Plus le volume de données, le degré d’automatisation et les conséquences d’une erreur augmentent, plus la vérification métier est approfondie. Une bonne gouvernance n’est donc pas l’opposé de l’expérimentation. Elle permet des expérimentations limitées dont les résultats sont évalués avec rigueur et évite qu’un test ne devienne, sans qu’on s’en aperçoive, un processus de décision durable.

Comment maitiq vous aide : des règles avec lesquelles l’équipe peut travailler

Classez les activités selon leur impact : un brouillon de texte interne, une publication et une modification de budget exigent des vérifications différentes. Pour chaque activité, consignez les données autorisées, la personne responsable et la marche à suivre en cas de doute. Un exemple court et compréhensible par activité aide davantage qu’une politique abstraite sans lien avec le travail réel.

Dans un projet convenu, maitiq traduit ces règles en modèles, en formation et en contrôles de processus. Les validations métier ou juridiques restent aux mains des personnes qui en sont responsables. Mesurez si les collaborateurs savent ce qu’ils ont le droit de faire et à qui signaler un cas problématique.

Comment débute un premier pilote avec maitiq

Dans un projet convenu, une phase de cadrage limitée montre quelle gouvernance est déjà suffisamment concrète et comment maitiq traduit les règles encore ouvertes en un processus opérationnel praticable. 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.

Sources et mise en perspective

Les sources des autorités éclairent le contexte : le PFPDT pour la protection des données, l’OFCS pour la sécurité et l’IPI pour le droit d’auteur. La Commission européenne documente l’application de l’AI Act et les délais transitoires. Le principe de responsabilité (accountability) de l’OCDE soutient la traçabilité des jeux de données, des processus et des décisions. Des informations sur la manière de travailler de maitiq sont disponibles sur maitiq.com.

Faites examiner votre cas concret par maitiq.