Pourquoi une démo ne peut pas répondre à la question d'achat
Avant de vous engager auprès d'une plateforme de stratégie IA, soumettez-la à un back-test : rejouez une mission que votre équipe a déjà achevée, avec le brief et les documents d'origine, puis notez le résultat par rapport au deck que le conseil a réellement vu. Ce guide présente le protocole, une grille d'évaluation à six dimensions, les éléments à demander au fournisseur, et ce à quoi ressemblent une réussite et un échec.
Comment évaluer une plateforme de stratégie IA avant de vous engager, et que devrait réellement tester un pilote ? La réponse directe est la suivante : testez la plateforme sur un travail que votre équipe a déjà achevé, avec le même brief et les mêmes documents dont elle disposait à l'époque, et notez le résultat par rapport au deck que votre conseil ou votre comité d'investissement a réellement vu. Un pilote fondé sur ce principe vous apprend ce qu'aucune démonstration ne peut montrer, parce que vous connaissez déjà la bonne réponse et l'emplacement des difficultés. Tout le reste de cet article est un protocole pour faire exactement cela.
Si la charge repose sur l'acheteur, c'est qu'une démonstration de fournisseur est conçue pour prouver la fluidité, pas le jugement. Le fournisseur choisit les données d'exemple, formule la question et contrôle le récit autour du résultat. Sur un matériau soigneusement sélectionné, un modèle de langage paraîtra presque toujours impressionnant, parce que les conditions du test ont éliminé les deux éléments qui font réellement échouer le travail de stratégie : des documents désordonnés et incomplets, et une question plus difficile qu'elle n'y paraît. La fluidité en conditions contrôlées est une propriété de la technologie ; la justesse sur votre problème est une propriété du système précis appliqué à vos documents, et vous seul pouvez mesurer la seconde.
Les régulateurs et les organismes de normalisation vont dans le même sens. En septembre 2024, la Federal Trade Commission des États-Unis a annoncé l'Operation AI Comply, une vague coordonnée de cinq actions coercitives contre des opérateurs qui s'appuyaient sur le battage autour de l'IA ou formulaient des promesses de performance sans preuve, dont une entreprise qui n'avait pas vérifié si le résultat de son IA égalait l'expertise des professionnels qu'elle prétendait remplacer[1]. La position de la commission : il n'existe aucune exemption IA au droit existant sur les allégations trompeuses[1]. Un acheteur qui accepte le récit de performance d'un fournisseur sans preuve s'expose exactement à la faille que la FTC a poursuivie : une allégation que personne n'a testée.
Le cadre de mesure a lui aussi une place établie dans le travail de normalisation. Le National Institute of Standards and Technology des États-Unis a publié son Artificial Intelligence Risk Management Framework en janvier 2023, destiné à un usage volontaire par les organisations qui développent, déploient ou utilisent des systèmes d'IA, et l'a construit autour de quatre fonctions : gouverner, cartographier, mesurer et gérer[2]. Le cadre décrit un processus flexible, structuré et mesurable pour traiter le risque lié à l'IA, et considère la mesure et le suivi comme des préalables à la confiance plutôt que comme des options[2]. Un back-test, c'est cette fonction de mesure appliquée à une décision d'achat concrète.
Les sections qui suivent vous donnent le protocole dans son intégralité : comment sélectionner et mener la mission de back-test, la grille à six dimensions pour noter le résultat, les éléments à exiger du fournisseur, qui doit mener et valider le pilote, et les deux conceptions de pilote qui produisent de manière fiable une mauvaise réponse. L'objectif, tout du long, est que la décision d'adoption repose sur des preuves que vous avez générées, et non sur un récit fourni par le fournisseur.
Le back-test : rejouer une mission déjà réalisée
Un back-test rejoue un travail de stratégie que votre équipe a déjà mené à bien et note la plateforme par rapport à un résultat connu. Il emprunte sa logique à la finance quantitative, où une stratégie est testée sur des données historiques avant d'engager du capital. Le protocole comporte quatre étapes.
- Sélectionnez une mission achevée et figez les données d'entrée. Récupérez le brief d'origine exactement tel qu'il a été formulé, ainsi que l'ensemble documentaire dont l'équipe disposait réellement à l'époque. Rien d'ultérieur : pas de données finales, pas de retours du conseil, pas de documents produits après la recommandation. Le test n'est valable que si la plateforme voit précisément ce que l'équipe a vu.
- Faites tourner la plateforme jusqu'à un deck achevé et consignez les conditions d'exécution. Notez la configuration de modèle utilisée, la durée de l'exécution, les prompts ou les données de cadrage nécessaires, et les points où des humains sont intervenus. Ces conditions font partie des preuves : un résultat qui ne tient qu'après de lourdes corrections manuelles est un produit différent d'un résultat qui tient sur une exécution propre.
- Notez le résultat par rapport au deck humain final, à l'aide de la grille fixe à six dimensions présentée dans la section suivante. Notez toutes les dimensions, y compris celles où la plateforme est bonne, afin que le profil soit comparable entre fournisseurs et dans le temps.
- Comparez et décidez. Là où le résultat de la plateforme diffère du deck humain, demandez-vous quelle version le conseil aurait préférée, et où la plateforme a trouvé ce que l'équipe avait manqué. Ce sont ces différences, et non le poli général, qui constituent la conclusion.
La valeur du protocole tient à la vérité de référence qu'il donne à l'évaluateur : vous savez déjà quels points de données étaient des pièges et quelles diapositives le conseil a contestées, de sorte que chaque affirmation peut être vérifiée par rapport à un résultat que le fournisseur ne contrôle pas. C'est ce qui empêche de faire passer pour une analyse un résultat fluide mais creux.
Une mise en garde sur le périmètre. Un seul back-test est un point de données sur une seule classe de problèmes. Si le budget du pilote le permet, menez deux missions de types différents, par exemple une analyse d'entrée sur un marché et une revue de portefeuille, afin de vérifier si la performance tient sur le type de travail que vous commandez réellement. Le protocole est assez peu coûteux pour être répété, puisque les données d'entrée existent déjà.
La grille d'évaluation à six dimensions
Notez le résultat du back-test sur six dimensions fixes. Les fixer à l'avance compte : cela empêche l'évaluation de dériver vers ce que la plateforme réussit par hasard, et cela rend les résultats comparables si vous testez plusieurs fournisseurs. La grille a aussi un écho réglementaire. Le règlement européen sur l'IA exige que la notice d'utilisation des systèmes d'IA à haut risque indique le niveau d'exactitude, y compris ses métriques, au regard duquel le système a été testé et validé, afin que les déployeurs puissent interpréter les résultats et les utiliser de manière appropriée[3]. Un acheteur qui applique cette grille fait, en miniature, ce que cette disposition attend du déployeur : tester selon des métriques déclarées avant l'usage.
| Dimension | Ce que vous testez | À quoi ressemble un bon résultat |
|---|---|---|
| 1. Cadrage du problème | La plateforme a-t-elle défini la même question que l'équipe, ou une meilleure ? | La question centrale est énoncée avec précision, avec un périmètre et un décideur clairs ; tout recadrage est une amélioration que l'équipe accepterait, non une esquive |
| 2. Structure | Le fil narratif est-il MECE et conclusion d'abord, avec un message par diapositive ? | L'arbre des problèmes ne compte rien en double et ne laisse aucun vide ; chaque titre de diapositive énonce la conclusion ; le fil narratif se lit comme un argument, de la page de titre à la recommandation |
| 3. Vérifiabilité des sources | Les sources citées affirment-elles réellement ce que disent les diapositives ? | Ouvrez un échantillon d'au moins dix affirmations citées ; chacune renvoie à une source qui étaye l'affirmation telle qu'elle est écrite |
| 4. Implication (so-what) | Chaque visuel porte-t-il une implication pour la décision ? | Aucun graphique ni tableau n'est présenté sans conséquence énoncée ; les implications correspondent aux preuves, non à des commentaires génériques |
| 5. Omissions | Que contenait le deck d'origine que le résultat ne contient pas ? | Les lacunes se limitent à ce que l'ensemble documentaire figé ne permettait pas d'étayer ; rien de ce sur quoi le conseil s'est appuyé ne manque sans raison traçable |
| 6. Erreurs | Y a-t-il des affirmations que la source ne soutient pas ? | Aucun chiffre sans source, aucun dépassement des preuves, aucune affirmation assurée là où les documents sont muets |
Deux dimensions méritent d'être soulignées, car ce sont celles où les systèmes fluides échouent. La vérifiabilité des sources est la dimension qui distingue un outil d'analyse d'un générateur de textes bien rédigés. Les omissions sont la dimension que les acheteurs oublient le plus souvent de noter : une plateforme peut produire un deck correct et bien sourcé qui passe à côté du point qui importait réellement au conseil, et seule une comparaison avec le vrai deck le révèle. Notez les six dimensions à chaque fois et consignez les preuves de chaque note, car la grille de notation est elle-même l'élément sur lequel repose la validation.
Choisir la bonne mission à back-tester
La mission que vous choisissez détermine ce que le back-test peut vous apprendre. Trois critères régissent la sélection, et ils se contrarient mutuellement : attendez-vous à un compromis plutôt qu'à un cas parfait.
- Assez récente pour être reconstituée. Le brief d'origine, l'ensemble documentaire tel qu'il se présentait à l'époque et le deck final doivent tous exister encore et être récupérables. Cela fait écho au principe de limitation de la conservation du RGPD britannique, article 5(1)(e), selon lequel les données personnelles ne doivent pas être conservées sous une forme identifiable plus longtemps que nécessaire aux fins du traitement[4]. Si votre politique de conservation a déjà fait son œuvre, les documents ont disparu et la mission ne peut pas être back-testée, aussi bonne candidate soit-elle par ailleurs.
- Assez contestée pour être instructive. Choisissez une mission où le conseil ou le comité d'investissement a émis des réserves : une hypothèse clé remise en question, un visuel interrogé, une recommandation retravaillée. Une mission sans friction ne teste rien, puisqu'il n'y avait aucun piège. Une mission contestée montre comment la plateforme gère l'ambiguïté, les preuves fragiles et une question qui a changé de forme en cours de route, précisément là où le travail de stratégie généré par l'IA a tendance à échouer.
- Pas plus confidentielle que ne l'autorisent les conditions de données du pilote. L'ensemble documentaire est transmis au fournisseur dans le cadre de l'accord de traitement des données du pilote ; la mission doit donc être une mission que vous êtes autorisé à traiter sur une infrastructure externe. Tout ce qui touche à des données personnelles, à des transactions en cours ou à des éléments de transaction restreints est hors du champ d'un premier pilote, sauf si l'accord le couvre explicitement.
Une présélection pratique ressemble à ceci : une analyse de marché ou de concurrence des un à deux dernières années, une décision de faire ou d'acheter ou de portefeuille passée par au moins deux itérations en conseil, ou un examen de due diligence où l'équipe a appris après coup quelle aurait dû être la réponse. Évitez la mission la plus récente si ses enseignements sont encore politiquement sensibles, et évitez la plus facile, car un back-test qui n'exige rien n'apprend rien.
La liste des éléments à demander au fournisseur
Avant que l'un de vos documents ne soit partagé, le fournisseur devrait être en mesure de produire un ensemble d'éléments qui vous permettent d'examiner le comportement de la plateforme et le traitement qui serait réservé à vos données. Demandez-les par écrit au début du pilote, et considérez tout refus ou tout retard sur l'un d'eux comme une conclusion en soi.
- Un deck d'exemple avec des sources cliquables. C'est l'élément le plus révélateur de tous, et il ne requiert aucune donnée de votre part. Ouvrez les sources d'un échantillon d'affirmations et vérifiez si chaque source dit bien ce que la diapositive affirme. Si le deck d'exemple du fournisseur lui-même ne résiste pas à cet examen, la dimension de vérifiabilité du pilote est déjà tranchée.
- L'accord de traitement des données. En vertu de l'article 28(3) du RGPD britannique, un contrat entre responsable du traitement et sous-traitant doit contenir huit clauses minimales : traitement uniquement sur instructions documentées du responsable, obligation de confidentialité, mesures de sécurité appropriées, conditions régissant les sous-traitants ultérieurs, assistance pour les droits des personnes concernées, assistance pour les obligations de sécurité et de notification des violations du responsable, suppression ou restitution des données en fin de contrat, et audits et inspections[5]. Vérifiez le projet du fournisseur par rapport à cette liste plutôt que de le supposer complet.
- La liste nominative des sous-traitants ultérieurs. Un sous-traitant ne peut recourir à un sous-traitant ultérieur sans l'autorisation écrite préalable, spécifique ou générale, du responsable, et demeure responsable de la conformité de celui-ci[5]. Vous devez savoir, nommément, quels fournisseurs de modèles, hébergeurs et autres tiers toucheraient vos documents, avant le début du pilote.
- La déclaration de localisation des données. Où vos documents sont stockés et traités, dans quelles juridictions, et selon quels mécanismes de transfert. Pour une entreprise européenne, c'est souvent un critère bloquant, et il doit être énoncé avec assez de précision pour être vérifiable, non comme une formule marketing.
- La politique de conservation et de suppression. Ce qui est conservé, pendant combien de temps, et ce qui se passe à la fin du contrat. L'article 28(3) exige qu'au choix du responsable, le sous-traitant supprime ou restitue toutes les données personnelles à la fin du contrat et supprime les copies existantes, sauf obligation légale de conservation[5]. Posez la même question pour vos documents d'entreprise confidentiels, et pas seulement pour les données personnelles.
- Un export de la piste d'audit. Le registre de ce que la plateforme a fait : quels documents ont été lus, ce qui a été produit, ce qui a été modifié et par qui. Demandez un export d'exemple pendant le pilote et confirmez qu'il est assez complet pour qu'un relecteur puisse reconstituer la façon dont une conclusion a été atteinte.
Deux de ces éléments jouent un double rôle. Le deck d'exemple avec sources cliquables donne un aperçu de la vérifiabilité de la plateforme avant que vous n'ayez rien partagé, et l'export de la piste d'audit montre si le fonctionnement de la plateforme peut seulement être examiné. Un fournisseur qui produit les deux sans difficulté vous dit quelque chose sur la manière dont la plateforme a été conçue ; un fournisseur qui n'y parvient pas a répondu par la négative à votre question d'achat.
Qui mène le pilote, qui valide, et à quoi ressemblent la réussite et l'échec
Un pilote sans gouvernance produit une opinion, pas une décision. Trois rôles doivent être fixés avant que le back-test ne soit lancé.
- L'évaluateur doit être une personne ayant travaillé sur la mission d'origine, car elle seule peut fournir la vérité de référence dont dépend la notation : quelle hypothèse le conseil a contestée, et quelle diapositive a demandé trois réécritures à l'équipe. Sans cette connaissance de première main, la notation des omissions et des erreurs se réduit à des conjectures, ce qui est précisément le mode de défaillance qu'un back-test vise à prévenir.
- Un second relecteur doit noter le résultat de manière indépendante avant que les notes ne soient comparées. Rien d'élaboré : deux évaluateurs, la même grille, et une courte séance de réconciliation où les notes divergentes sont débattues à partir des preuves. Cela évite que le résultat ne repose sur le souvenir d'une seule personne.
- La validation revient au détenteur du budget ou, dans un cabinet de conseil, à l'associé gérant. La personne qui porte la décision d'achat doit voir la grille de notation, les conditions d'exécution et les vérifications de sources échantillonnées, et doit pouvoir expliquer le résultat à un conseil ou à un comité d'investissement sans que l'évaluateur soit présent.
Définissez la réussite et l'échec avant l'exécution, par écrit, afin que les critères ne puissent pas être renégociés une fois le résultat connu. Une réussite signifie que le résultat obtient une note acceptable sur les six dimensions de la grille, chaque source échantillonnée ayant été vérifiée : le cadrage est solide ou meilleur, la structure survivrait à une lecture par le conseil, l'implication est présente sur les visuels qui comptent, et les omissions et erreurs restent dans la tolérance fixée à l'avance. Les résultats partiels doivent être consignés comme tels, car une plateforme qui réussit cinq dimensions et en échoue une donne lieu à une conversation d'achat différente de celle qui réussit les six.
Le cas d'échec le plus important à nommer explicitement est l'échec fluide : le résultat se lit bien, le fil narratif est propre, et les sources ne tiennent pas. Lorsque vous ouvrez les documents cités et constatez qu'ils ne disent pas ce que les diapositives affirment, c'est un échec sur la vérifiabilité et les erreurs, quel que soit le degré de finition du deck, et c'est disqualifiant plutôt qu'une simple pénalité. Les autres cas d'échec comprennent un résultat qui a nécessité d'importantes corrections humaines non documentées pour atteindre son état final, et une piste d'audit trop mince pour reconstituer la manière dont les conclusions ont été atteintes.
Deux conceptions de pilote à éviter, et à quoi ressemble une plateforme back-testable
La plupart des pilotes qui échouent échouent dès la phase de conception, avant que la plateforme n'ait rien fait. Deux conceptions expliquent l'essentiel du gaspillage.
- Juger sur une démonstration du fournisseur. Une démonstration n'est utile qu'à une chose : décider si la plateforme mérite un back-test.
- Juger uniquement sur la vitesse. Le délai jusqu'au deck est la métrique la plus facile à mesurer et la moins informative, car la vitesse mesure le débit, pas la justesse de l'analyse. Une plateforme qui produit un deck fluide en un après-midi a résolu la moitié facile du problème ; la moitié qui compte, c'est de savoir si chaque affirmation survit au contact de sa source. Mesurez la vitesse seulement après que la vérifiabilité a été validée, et jamais à sa place.
Ce que le pilote doit vous laisser, c'est une plateforme qui puisse seulement être back-testée. Cela signifie un système qui accepte votre brief et vos documents, produit un deck prêt pour le conseil, et expose ses preuves : chaque affirmation traçable jusqu'à la source sur laquelle elle repose, afin que la grille à six dimensions puisse réellement être appliquée.
Decisity est une plateforme de conseil en stratégie native IA qui transforme un brief et des documents en decks prêts pour le conseil, chaque affirmation étant traçable jusqu'à sa source. Elle est conçue pour être évaluée selon exactement ce protocole : exécutez-la sur une mission achevée, notez le résultat par rapport au deck que le conseil a vu, et inspectez les sources derrière chaque affirmation. Si vous souhaitez voir ce flux de travail de bout en bout, la page comment ça marche décrit le processus en trois étapes, de l'ingestion des documents au deck final, et vous pouvez demander une démo comme première étape vers un back-test sur votre propre matériau.
À lire aussi :
Sources
- FTC: FTC Announces Crackdown on Deceptive AI Claims and Schemes (25 September 2024)
- NIST: NIST Risk Management Framework Aims to Improve Trustworthiness of Artificial Intelligence (26 January 2023)
- EU AI Act Service Desk: Article 13, Transparency and provision of information to deployers
- ICO: Principle (e): Storage limitation (UK GDPR guidance)
- ICO: What needs to be included in the contract (contracts between controllers and processors, UK GDPR Article 28(3))
