Les bons critères pour évaluer une solution d’IA

Le risque lié à l’achat d’IA va au-delà des capacités du produit

Un outil marketing d’IA peut fonctionner comme promis et malgré tout constituer un mauvais achat. La question d’approvisionnement la plus difficile porte sur la quantité de travail d’implémentation, d’incertitude et de risque opérationnel que l’entreprise doit absorber avant que la valeur n’apparaisse. Le prix de l’abonnement et une démonstration convaincante ne couvrent qu’une partie de cet engagement. Les achats doivent évaluer ensemble le résultat métier, les preuves, la charge de travail interne, l’exposition des données et la répartition contractuelle du risque.

Cela change l’ordre des vérifications. Un produit en développement peut nécessiter de l’intégration, des tests, de la formation, du dépannage et des retours clients avant de s’insérer dans le workflow visé. Ces exigences consomment une capacité des employés qui pourrait être utilisée ailleurs. La maturité du produit compte, car elle aide à déterminer le niveau de preuve que l’acheteur doit exiger et le degré d’incertitude que l’entreprise doit accepter dans l’accord.

Commencez par le résultat métier

La première question utile à poser à un fournisseur d’IA est simple : quel problème métier le produit résout-il ? Une fonctionnalité compte lorsqu’elle modifie un résultat que l’entreprise valorise, par exemple en augmentant la production ou en identifiant des lacunes de tracking afin que les équipes puissent résoudre les problèmes plus rapidement. Les dirigeants marketing doivent relier le cas d’usage proposé à un problème que leur organisation reconnaît déjà. Des explications riches en fonctionnalités sans ce lien donnent aux acheteurs peu de base pour calculer la valeur.

Les gains de temps exigent la même rigueur. Si l’automatisation libère de la capacité dans les opérations de campagne, le reporting ou le dépannage, la direction doit décider comment l’utiliser. Les employés peuvent prendre en charge davantage de comptes, améliorer la qualité des campagnes, enquêter plus vite sur les problèmes de performance ou réaffecter leurs efforts à des tâches à plus forte valeur. L’acheteur peut alors identifier le workflow actuel, le changement attendu et la conséquence métier avant d’attribuer une valeur à l’outil.

Cette définition crée un test pour l’évaluation ultérieure. Les achats peuvent juger la performance à l’aune d’un résultat opérationnel ou commercial spécifié. Le résultat doit être suffisamment concret pour déterminer si l’implémentation a produit le changement attendu. Une fois le résultat défini, l’acheteur peut demander de quelles preuves le fournisseur dispose pour démontrer qu’il peut le délivrer.

La maturité du fournisseur détermine le niveau de preuve que vous devez exiger

Un fournisseur établi doit pouvoir fournir des études de cas précises et des résultats provenant d’annonceurs ayant un cas d’usage, un secteur ou une taille d’organisation similaires. Les acheteurs doivent examiner dans quelle mesure ces exemples correspondent à leurs workflows et à leurs contraintes avant de les utiliser pour estimer la valeur probable. Le fournisseur a intérêt à présenter ses preuves les plus solides ; les achats doivent donc tester la pertinence de chaque exemple et le degré de validation indépendante qu’il apporte.

Une entreprise en phase de démarrage pose un problème de vérification différent lorsqu’elle a une expérience limitée du cas d’usage ou du secteur de l’acheteur. Les achats doivent établir combien de déploiements pertinents le fournisseur peut étayer et ce que le client devra apporter pendant l’adoption. Des tests pratiques, l’accès à des collaborateurs compétents, des limites documentées et des exigences d’implémentation claires peuvent aider l’acheteur à évaluer l’incertitude avant de prendre un engagement plus important.

L’expertise métier mérite un test distinct. Un fournisseur qui conçoit un produit pour l’achat média doit être capable d’expliquer comment un acheteur média passe sa journée, où le workflow échoue et quelles contraintes influencent l’adoption. Si les fondateurs n’ont pas d’expérience directe, les acheteurs doivent demander comment l’entreprise a étudié ces workflows et intégré les conclusions dans les décisions produit. Une histoire de création convaincante peut éclairer cette évaluation, mais les achats ont toujours besoin de preuves que le produit peut produire le résultat défini.

Le commercial n’a pas besoin de détenir personnellement toute cette expertise. Les prospects sérieux doivent toutefois pouvoir accéder à des personnes capables de répondre à des questions détaillées sur la technologie, le workflow, les limites et l’implémentation. Le fournisseur a un intérêt commercial à faire paraître l’adoption simple. Les acheteurs ont besoin d’un accès suffisant pour tester ces affirmations avant d’engager leurs propres équipes et systèmes.

Calculez le coût interne de l’adoption

Le calcul économique inclut l’abonnement et la capacité interne nécessaire pour faire fonctionner le produit dans l’environnement visé. Ce travail peut inclure la connexion des systèmes, la configuration des accès, la formation des employés, l’évaluation des résultats, la modification des workflows et le dépannage des défaillances. Les acheteurs doivent identifier ces exigences pendant la vérification et estimer quelles équipes fourniront le travail. Chaque heure consacrée à l’implémentation a un coût d’opportunité ailleurs dans l’organisation.

Les tests et l’assurance qualité peuvent consommer une capacité importante lorsque les résultats de l’IA affectent l’exécution des campagnes, la mesure ou les travaux orientés client. L’acheteur a besoin de personnes qui savent à quoi ressemble un résultat acceptable et qui peuvent évaluer la performance dans le cas d’usage visé. Les achats doivent demander quel volume de revue humaine initiale et récurrente le workflow proposé exige. Une démonstration peut établir la capacité, mais la charge de travail en production détermine si cette capacité est réellement pratique pour l’organisation.

La formation et l’adoption créent une autre exigence. Les employés doivent comprendre où l’outil s’insère dans leur travail, comment évaluer ses résultats et comment gérer les exceptions. Les achats doivent examiner ces exigences dans le cadre du plan d’adoption. Si la formation, les contournements et la revue humaine absorbent la capacité que l’automatisation était censée libérer, le business case doit inclure ce coût.

Un produit en développement peut aussi exiger que les clients participent à son amélioration. Les équipes peuvent devoir signaler des bugs, expliquer des cas limites, reproduire des défaillances, fournir des retours et retester les correctifs. Cet échange peut valoir l’effort si le bénéfice métier attendu le justifie, mais ce travail doit tout de même entrer dans le calcul de l’investissement. Les achats doivent établir quel niveau de support au développement produit le fournisseur attend du client et quels spécialistes le fourniront.

Cette charge peut se répartir entre des équipes déjà rares. Les opérations marketing peuvent identifier un problème de workflow, l’analytics peut valider les données, les équipes techniques peuvent diagnostiquer une intégration et les utilisateurs finaux peuvent tester la correction. Les acheteurs doivent cartographier ces dépendances avant d’accepter un essai ou une implémentation. Une entreprise disposant de peu de capacité disponible peut rejeter un outil prometteur si le travail d’adoption dépasse ce que l’organisation peut supporter à ce moment-là.

La même logique s’applique à un essai gratuit. Un test sans frais fournisseur peut tout de même nécessiter une intégration, une préparation des données, une revue de sécurité et du temps employé. Les acheteurs doivent définir l’effort interne maximal qu’ils sont prêts à consacrer et les preuves requises pour justifier un engagement plus important. Cela évite qu’une évaluation ne se transforme en projet d’implémentation à durée indéterminée avant que le business case soit établi.

Inscrivez les promesses sur les données dans le contrat

La charge opérationnelle devient visible pendant l’implémentation, tandis que l’exposition des données exige une vérification avant que des informations sensibles n’entrent dans le système. Les acheteurs doivent établir quelles informations le fournisseur reçoit, où elles sont stockées, combien de temps elles sont conservées, si elles sont utilisées pour l’entraînement du modèle, si des modèles partagés ou tiers les reçoivent, et ce qu’il advient lorsque la relation prend fin. Les équipes juridiques, sécurité et techniques peuvent alors évaluer ce parcours des données au regard des exigences de l’entreprise.

Les déclarations sur « vos données » exigent de la précision, car les droits pertinents peuvent dépendre du type de données, du contrat, du droit applicable et de la juridiction. Les équipes achats doivent établir les droits et obligations applicables à leurs données et à leur cas d’usage spécifiques. Elles doivent savoir ce que le fournisseur peut faire, ce que le client peut exiger et quelles obligations contractuelles continuent après la résiliation. Les assurances générales doivent devenir des clauses que les équipes internes responsables peuvent évaluer.

L’entraînement du modèle exige un traitement tout aussi précis. Les acheteurs doivent établir si les informations soumises sont utilisées pour améliorer un système spécifique au client, si elles contribuent à un modèle partagé ou si elles sont transmises à un modèle tiers, ainsi que le consentement et les conditions contractuelles qui encadrent ces usages. Le fournisseur a un intérêt commercial à conclure la transaction ; les déclarations importantes sur la conservation, la suppression, le stockage, l’entraînement et le partage des données doivent donc être vérifiées par rapport au contrat avant le déploiement.

L’incertitude produit rend cette vérification encore plus importante. Un acheteur peut décider qu’un accès anticipé à une capacité justifie une incertitude sur la performance, mais les obligations liées aux données doivent tout de même être explicites pendant toute la relation et après sa fin. Lorsque le traitement des données influence de manière significative la décision d’achat, les achats doivent résoudre les écarts entre les déclarations commerciales et le langage contractuel avant que l’entreprise ne fournisse les informations concernées.

Faites en sorte que l’accord reflète l’incertitude du produit

Un fournisseur en phase de démarrage peut être un choix rationnel lorsque l’opportunité attendue justifie l’incertitude. Un client peut obtenir un accès anticipé à une capacité utile, influencer la manière dont le produit répond à son cas d’usage ou négocier des conditions commerciales adaptées au risque. Il peut aussi consacrer du temps de ses équipes aux bugs, aux cas limites et à l’amélioration du produit avant de savoir si le résultat attendu se matérialisera. Les achats doivent intégrer cette incertitude dans la décision.

La structure de l’accord doit refléter les preuves disponibles. Lorsqu’un fournisseur dispose de peu de preuves pour le cas d’usage de l’acheteur, les achats doivent rechercher de la transparence sur cette limite, des possibilités concrètes de tester le produit lorsque c’est faisable, des attentes d’implémentation définies et des engagements proportionnés aux preuves. Les conditions contractuelles doivent traiter les risques identifiables liés au traitement des données et à la livraison. Comme le fournisseur bénéficie de la conclusion de la vente, les achats doivent tester sa caractérisation de l’état de préparation du produit par une vérification rigoureuse et traduire les déclarations importantes en clauses opposables.

Les produits établis doivent être soumis au même test de résultat. Leur historique opérationnel et leurs études de cas pertinentes peuvent étayer la vérification lorsque les exemples correspondent à l’usage prévu par l’acheteur, mais la maturité ne suffit pas à elle seule à établir la valeur pour une organisation donnée. La décision dépend toujours des résultats métier attendus, des exigences d’implémentation, de la capacité interne et de l’exposition contractuelle. La maturité du produit est surtout utile pour décider du niveau d’incertitude que l’acheteur doit accepter et des preuves que l’accord doit exiger.

Points clés

• Définissez d’abord le résultat métier : Les équipes achats doivent rattacher chaque achat d’IA à un résultat opérationnel ou commercial précis. Utilisez ce résultat pour évaluer les preuves du fournisseur, la valeur attendue et le succès de l’implémentation.
• Adaptez le niveau de preuve à la maturité du fournisseur : Les acheteurs qui évaluent des fournisseurs établis doivent exiger des résultats clients pertinents, tandis que les fournisseurs en phase de démarrage nécessitent des tests plus poussés de l’état de préparation du produit, de l’expertise métier et des exigences d’implémentation.
• Intégrez le travail interne d’adoption dans le coût : Les équipes achats doivent inclure l’intégration, la formation, les tests, le dépannage, la revue humaine et les retours des employés dans le business case de l’investissement. Les essais gratuits consomment eux aussi de la capacité des équipes et doivent avoir des limites définies.
• Inscrivez les engagements sur les données dans le contrat : Les équipes juridiques, sécurité et techniques doivent vérifier comment les fournisseurs stockent, conservent, partagent, utilisent pour l’entraînement et suppriment les données de l’entreprise. Les promesses commerciales importantes doivent figurer dans des clauses contractuelles opposables.
• Structurez l’accord autour de l’incertitude : Les acheteurs qui assument un risque produit plus élevé doivent rechercher des possibilités de test, des attentes d’implémentation claires, des engagements appropriés et des protections contractuelles reflétant les preuves disponibles.