Évaluer objectivement les partenaires d’implémentation pour intégrer l’IA au marketing

Un partenaire adapté n’est pas l’organisation qui affiche la liste d’outils la plus longue. Il sait traduire un problème marketing clairement délimité en un processus vérifiable, nomme les dépendances et les limites, intègre des contrôles et transmet le savoir ainsi que la capacité d’exploitation. Le choix commence donc par votre mandat, et non par le pitch du prestataire.

Avant la recherche : délimiter le mandat

Rédigez une description du problème d’une page avant de collecter des noms. Elle doit répondre aux questions suivantes :

• Quelle tâche marketing ou quelle décision doit s’améliorer ?
• Comment le processus fonctionne-t-il aujourd’hui, et quelle valeur initiale est connue ?
• Quels utilisateurs, clients ou collaborateurs sont concernés ?
• Quelles données seraient nécessaires et qui peut autoriser l’accès ?
• Quelles erreurs sont critiques, et qui arrête le processus ?
• Que doit-on pouvoir exploiter ou faire évoluer en interne au terme du projet ?

Un mandat comme «introduire l’IA dans le marketing» ne peut pas être mis en concurrence. «Élaborer, à partir de la documentation produit validée, un projet de briefing vérifié en interne et le tester face au processus actuel» est suffisamment délimité pour comparer les compétences, le prix et le risque.

Le portail PME du SECO renvoie au paysage suisse fragmenté de l’IA et à SAIROP comme repère pour les partenaires de recherche et les prestataires de services. SAIROP se décrit elle-même comme un hub de mise en réseau. La page des partenaires examinée ne présente toutefois aucune accréditation, aucun contrôle de qualité indépendant ni spécialisation marketing. Utilisez donc un annuaire pour la phase de cadrage, et non comme une liste restreinte déjà vérifiée.

Huit points de contrôle pour la liste élargie

1. Comprendre le problème plutôt que la démo

Un bon candidat s’enquiert de la situation initiale, des utilisateurs, des conséquences des erreurs et de l’alternative sans IA. Faites structurer le même cas anonymisé par tous les candidats. Comparez les questions et les hypothèses, pas la vitesse d’une démo préparée.

Signal d’alerte : le prestataire se fixe sur un produit avant que les données, l’intégration, le risque ou le critère de réussite soient clarifiés.

2. Des compétences marketing et métier démontrables

Demandez des exemples qui ressemblent au mandat par la tâche et la classe de risque. Un chatbot générique ne prouve aucune compétence en pilotage média, en personnalisation ou en mesure marketing. Lors des entretiens avec clients de référence, interrogez sur la valeur initiale, le rôle du partenaire, le rôle du client, la méthode de test, les erreurs et le statut d’exploitation.

Des références confidentielles ne peuvent pas être divulguées intégralement. Le prestataire devrait alors montrer au moins des documents précis et sa méthode : plans de test anonymisés, modèles de rôles, schémas d’évaluation ou plans de transfert. Un pourcentage sans méthodologie n’est pas une preuve.

3. Limites des données et des systèmes

Le partenaire doit pouvoir expliquer le flux de données : source, finalité, transmission, stockage, accès, conservation, suppression et utilisation possible par des sous-traitants ou des fournisseurs de modèles. Demandez quelles données sont explicitement exclues et comment les données de test sont produites.

Un schéma d’architecture n’est utile que lorsque les responsabilités sont visibles. Qui maintient les interfaces ? Que se passe-t-il en cas de panne ? Quels journaux l’équipe cliente reçoit-elle ? Comment les changements de modèle ou de prestataire sont-ils détectés ? Des réponses comme «tout est dans le cloud» ne suffisent pas.

4. Évaluation et preuves

Convenez de cas de test et de critères d’acceptation avant la mise en œuvre. Un partenaire devrait distinguer le fonctionnement technique, la qualité des résultats, l’effet sur le processus et l’impact commercial. Demandez aussi des contre-exemples et des cas difficiles. Des erreurs critiques rares ne doivent pas disparaître dans une note moyenne.

Le fournisseur doit indiquer quelles parties sont synthétiques, évaluées manuellement ou dérivées de données de production. Si un modèle n’est pas déterministe, le test exige des répétitions et des versions documentées.

5. Gouvernance et autorité humaine

Clarifiez qui valide les entrées, vérifie les résultats, approuve les modifications, traite les incidents et accepte le risque résiduel. «Human in the loop» est trop imprécis. Le contrat ou le plan d’exploitation doit nommer le rôle, le moment, les informations et de véritables droits d’arrêt.

Une structure de contrôle devrait couvrir l’inventaire, les rôles, les risques liés aux tiers, le monitoring, les incidents et la mise hors service. Il s’agit ici d’un modèle de cahier des charges à caractère rédactionnel, et non d’une norme de certification externe. Le principe de responsabilité de l’OCDE fournit à cet égard une idée directrice solide : les données, les processus et les décisions doivent rester traçables. Ne demandez donc pas au partenaire seulement des engagements, mais des documents précis et des rôles responsables.

6. Sécurité, protection des données et droits

Ne demandez pas seulement des réponses au service commercial, mais aux spécialistes compétents. Il faut notamment un concept de droits d’accès, un chiffrement, une journalisation, un processus de suppression, une procédure de signalement des incidents, une liste des sous-traitants, les droits sur les entrées et les sorties ainsi que des règles pour les données confidentielles.

Vos responsables de la protection des données, de la sécurité et du droit décident de la vérification concrètement nécessaire. Un certificat peut faire partie des preuves, mais il ne remplace pas l’examen du flux de données et du cas d’usage concrets.

7. Exploitation et changements

Une démo de pilote réussie ne répond pas à la question de savoir qui exploitera le système le lundi matin. Posez des questions sur la surveillance, les heures de support, les catégories d’erreurs, la restauration, le contrôle des coûts, les limites de capacité, les mises à jour de modèles et les tests de régression. Définissez quelle modification déclenche une nouvelle validation.

Un partenaire devrait aussi pouvoir expliquer quand une alternative manuelle est préférable et comment elle s’active. Qui ne montre que le cas normal n’a pas encore décrit l’exploitation.

8. Passation et sortie

L’équipe cliente a besoin de plus que des identifiants d’accès. Exigez une documentation sur la finalité, l’architecture, les données, les prompts ou les règles, les cas de test, les limites connues, les décisions, les fournisseurs, l’exploitation et les risques ouverts. Déterminez quels livrables se trouvent dans un système détenu par le client et dans quel format les données peuvent être exportées.

Le principe de responsabilité de l’OCDE permet d’en déduire une question concrète pour l’achat : quelles preuves relatives aux données, aux processus et aux décisions l’entreprise détient-elle elle-même à la fin du projet ?

Confier séparément la phase de cadrage, le pilote et l’exploitation

Un achat structuré divise le projet en phases de décision. La phase de cadrage fournit la définition du problème, l’état des données et des risques, les options et le plan de pilote. Elle ne valide aucune mise en production. Le pilote fournit une mise en œuvre limitée et des preuves confrontées à des critères définis au préalable. Un pilote réussi ne valide pas encore une exploitation permanente. L’exploitation comprend l’intégration, les responsabilités, le monitoring, le support, le contrôle des modifications et la sortie.

Cette séparation protège les deux parties. L’entreprise peut s’arrêter après chaque phase ou modifier le périmètre. Le partenaire n’a pas à dissimuler des incertitudes dans un engagement global apparemment ferme. Les offres de prix deviennent plus comparables lorsque chaque résultat et chaque hypothèse sont nommés.

Pour la phase de cadrage, un prix forfaitaire peut être judicieux si les livrables sont clairs. Un pilote a besoin d’une limite budgétaire et d’un point d’arrêt. En exploitation, les coûts variables d’infrastructure ou de modèle devraient être présentés séparément des prestations. Évitez une rémunération qui récompense le partenaire uniquement pour une utilisation accrue, si la qualité et le risque ne sont pas mesurés eux aussi.

Questions pour les entretiens de référence

Parlez, si possible, à des personnes métier et techniques du côté du client. Ne demandez pas seulement «avez-vous été satisfait ?», mais :

• Quel problème était mesurable avant le début ?
• Quelle hypothèse s’est révélée fausse ?
• Combien de travail de reprise est resté après le pilote ?
• Qui exploite et surveille la solution aujourd’hui ?
• Quelle documentation et quels cas de test ont été transmis ?
• Comment le partenaire a-t-il réagi à une erreur ou à un changement de périmètre ?
• Quelle dépendance négocieriez-vous différemment la prochaine fois ?

Les réponses dépendent du contexte. Une bonne référence n’est pas une garantie, mais elle montre si le prestataire parle de l’exploitation et de l’apprentissage avec autant de précision que du démarrage.

Évaluer sans fausse précision

Ne compensez pas des critères obligatoires par de séduisants points supplémentaires. Une utilisation des données non clarifiée, l’absence de droit d’arrêt, des sous-traitants non nommés ou une passation non organisée peuvent être des motifs d’exclusion. Ce n’est que parmi les candidats qui remplissent tous les critères obligatoires que la compétence métier, l’approche, l’équipe, les coûts et la collaboration sont évalués.

Demandez à chaque personne qui évalue de consigner sa justification avant la discussion de groupe. Ainsi, la meilleure présentation ne l’emporte pas automatiquement. Marquez visiblement les hypothèses et les éléments encore à fournir. Un «partiellement» n’est pas un «oui» silencieux.

Ce qu’un partenaire ne devrait pas promettre

La méfiance est de mise face à un ROI garanti sans base de référence, une absence totale d’erreurs, une conformité juridique automatique, une intégration immédiate dans «chaque» système ou une boîte noire qui ne fournit aucun document de test et d’exploitation. Tout aussi problématique est l’affirmation qu’un projet d’IA généraliste prouve une compétence marketing.

Le bon partenaire ne doit pas tout fournir lui-même. Il doit rendre les limites transparentes, nommer les spécialistes nécessaires et accepter une matrice des responsabilités claire. Pour une équipe suisse, c’est plus solide que l’idée d’un fournisseur d’IA unique et universel.

Comment maitiq aide : une épreuve pratique est plus parlante que la liste d’outils

Donnez aux partenaires potentiels le même cas de processus anonymisé : un lead arrive avec des informations incomplètes et doit être attribué à la bonne personne. Exigez le déroulement proposé, un résultat visible, le traitement des données manquantes ainsi qu’un plan de passation et d’exploitation. Une bonne offre précise aussi quelle interface ou quelle qualité de données manque au départ.

Dans un projet convenu, maitiq accompagne la mise en place technique, l’analyse des processus existants, la formation et le démarrage de l’exploitation. Évaluez le partenaire sur la capacité de votre équipe à expliquer le processus après la passation, à l’utiliser et à le piloter en cas d’exception. Le périmètre concret des prestations a sa place dans l’offre ; une démonstration convaincante ne le remplace pas.

Une preuve d’expérience n’est solide que si elle est comparable : la tâche, la classe de risque, le rôle du partenaire, la méthode de mesure et le statut d’exploitation doivent correspondre à votre propre mandat. Des engagements généraux ne remplacent pas cet examen.

Comment débute un premier pilote avec maitiq

Une phase de cadrage limitée montre comment maitiq délimiterait votre cas d’usage, le mettrait en œuvre et le transformerait avec votre équipe en une exploitation mesurable. 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 d’une exploitation ultérieure.

Sources et mise en perspective

Les sources liées sont identifiées précisément : le portail PME du SECO décrit dans un entretien comment les PME suisses utilisent l’intelligence artificielle avec succès. La page des partenaires de SAIROP décrit le réseau et quatre types de partenariat, mais aucune accréditation. Le principe de responsabilité de l’OCDE (P9) donne des repères de gouvernance et de traçabilité. Des informations sur la manière de travailler de maitiq sont disponibles sur maitiq.com.

Faites examiner votre cas concret par maitiq.