Réponse en bref
Pour évaluer un service d’IA, faites-le tourner sur vos propres cas réels, face à des critères d’acceptation écrits à l’avance. Obtenez ensuite cinq réponses par écrit : où vos données sont conservées et combien de temps, ce que coûte une tâche aboutie, vérification humaine comprise, ce qui se passe quand le système se trompe ou tombe en panne, quelles preuves indépendantes étayent les affirmations de sécurité et comment vous partez. N’achetez qu’après un pilote court assorti d’une règle d’arrêt.
Une démo tourne sur les cas du fournisseur, et les vôtres diffèrent
Tout service d’IA paraît compétent en démonstration. Les données d’entrée ont été choisies par ceux qui le vendent, les cas gênants ont été écartés et personne n’a compté les tentatives ratées avant la réunion. Rien de malhonnête à cela. Ce n’est simplement pas une information sur la façon dont le service se comportera avec vos documents, vos clients et vos exceptions.
Le cadre volontaire de gestion des risques de l’IA du National Institute of Standards and Technology américain (NIST), l’AI Risk Management Framework, le dit en une phrase : les mesures d’exactitude doivent toujours être associées à des jeux de test clairement définis et réalistes, représentatifs des conditions d’utilisation prévues. Pour un acheteur, une performance annoncée ailleurs que sur ses propres documents reste une hypothèse.
Ce guide propose d’évaluer un service d’IA aux conditions de l’acheteur, en sept vérifications : un essai sur vos propres cas, le traitement des données, le coût d’une tâche aboutie, le comportement en cas de défaillance, les preuves de sécurité, la sortie et un pilote assorti d’une règle d’arrêt. La plupart sont des questions qui ne coûtent rien à poser, et la disposition du fournisseur à répondre par écrit est déjà un résultat.
Avant l’essai, écrivez le problème et ce qu’est un bon résultat
Commencez un cran avant le produit. L’autorité britannique de protection des données, l’Information Commissioner’s Office (ICO), indique que le déploiement d’un système d’IA traitant des données personnelles doit reposer sur la preuve qu’un problème existe et sur un argument raisonné montrant que l’IA en est une solution sensée, et non sur la simple disponibilité de la technologie. Le guide du gouvernement britannique Guidelines for AI procurement (lignes directrices pour l’achat d’IA), publié en 2020 pour les ministères, demande aux acheteurs un énoncé clair du problème plutôt qu’un cahier des charges détaillé.
Écrivez donc trois lignes avant de parler à qui que ce soit. Quelle tâche est accomplie aujourd’hui, par qui, et en combien de temps ? Qu’est-ce qui permettrait de dire qu’une machine la fait suffisamment bien ? Qu’est-ce qui ne doit jamais arriver ? La troisième ligne compte le plus : un outil de rédaction qui écrit parfois une phrase maladroite est un désagrément, un outil qui invente parfois une date de livraison engage votre responsabilité.
Les mêmes lignes directrices rangent « la définition d’une performance acceptable du modèle » parmi les pratiques à rechercher chez un fournisseur. Faites-le vous-même, à l’avance et en mots simples : une réponse est acceptable, par exemple, si un collègue expérimenté l’enverrait sans en changer les faits. Les critères rédigés après les résultats ont tendance à leur ressembler.
Faites tourner le service sur votre travail, cas difficiles compris
Rassemblez des exemples réels de la tâche : des cas ordinaires, des cas difficiles et quelques-uns où la bonne réponse consiste à refuser ou à transmettre le dossier à une personne. Retirez les données personnelles dont l’essai n’a pas besoin. Il n’existe pas de nombre standard de cas ; la bonne taille est celle à partir de laquelle un seul résultat étrange ne peut plus faire basculer le verdict.
Faites noter les résultats selon vos critères par les personnes qui accomplissent ce travail aujourd’hui, sans qu’elles sachent quel fournisseur a produit quoi si vous en comparez plusieurs. Comptez séparément trois issues : acceptable en l’état, utilisable après correction, faux. C’est dans la catégorie intermédiaire que se cache le coût réel du service, car chaque correction est du temps payé.
Les lignes directrices décrivent la preuve de concept comme un moyen de tester une technologie avant la mise en service de la solution, et citent « le test du modèle dans des conditions variées » comme marque d’un fournisseur sérieux. Demandez cette variété : soumettez les mêmes cas à des jours différents, essayez des textes plus longs et des numérisations de moins bonne qualité, et notez si les réponses restent stables.
Où vont vos données, combien de temps elles restent, qui s’en sert
Posez les questions sur les données avant celle du prix, car les réponses peuvent clore la discussion. Où les données sont-elles traitées et stockées ? Combien de temps les entrées, les sorties et les journaux sont-ils conservés ? Servent-ils à entraîner ou à améliorer des modèles, et le contrat peut-il l’exclure ? Quels sous-traitants reçoivent les données ? Qu’est-ce qui est supprimé à votre départ, et comment la suppression est-elle attestée ?
Le guide de l’ICO sur l’IA explique, dans les termes du droit britannique de la protection des données, pourquoi ces questions sont les vôtres et pas seulement celles du fournisseur. L’organisation qui décide quelles données personnelles sont traitées, dans quel but et pour quelle durée de conservation est responsable du traitement, quelle que soit la façon dont un contrat la désigne. Le guide demande aux acheteurs de préciser leurs exigences au stade de l’achat et indique que, s’il est impossible d’apprécier la conformité d’un système tiers, la bonne pratique est d’en choisir un autre.
Deux précautions pour rester honnête. Le guide de l’ICO porte sur le droit britannique de la protection des données, et ses pages affichent un avis indiquant qu’il est en cours de révision à la suite du Data (Use and Access) Act : lisez donc la version en ligne ; d’autres pays ont leurs propres règles. Si le service doit traiter des données de clients ou de salariés, soumettez les réponses écrites du fournisseur à votre conseil en protection des données avant de signer.
Chiffrez la tâche aboutie, pas le poste ni le millier de jetons
Les grilles tarifaires des services d’IA emploient des unités qui arrangent le vendeur : postes, crédits, requêtes, jetons (tokens). Votre unité à vous est la tâche aboutie, c’est-à-dire un résultat accepté et utilisé. Pour passer de l’une à l’autre, prenez les résultats de l’essai et ajoutez ce que la grille omet : les tentatives écartées, les minutes passées à vérifier et à corriger, le travail de mise en place et les heures mensuelles nécessaires pour maintenir le service en état de marche.
Un exemple avec des chiffres ronds inventés montre le calcul. Un mois d’utilisation coûte 300 en abonnement et produit 1 000 brouillons, dont 800 sont acceptés. Le personnel consacre 40 heures à vérifier et à corriger, à 25 de l’heure, soit 1 000. Le total atteint 1 300 pour 800 tâches abouties, environ 1,63 chacune, alors que l’abonnement seul laissait croire à 0,30. Ces chiffres sont un exemple et non des prix de marché ; la leçon tient à l’écart entre les deux.
Soumettez ensuite le processus manuel au même calcul, avec ses propres erreurs et reprises, et comparez ce qui est comparable. Les lignes directrices demandent aux acheteurs de prendre en compte les coûts sur l’ensemble du cycle de vie, y compris le support et la maintenance continus. Demandez au fournisseur comment ses prix et ses plafonds d’utilisation ont évolué depuis un an.
Faux, hésitant ou indisponible : le service un mauvais jour
Tout système tombe en défaut, et ce que vous achetez, c’est sa manière de le faire. Demandez à voir ce qui se passe quand le service ne sait pas : le dit-il, ou produit-il malgré tout une réponse pleine d’assurance ? Le cadre du NIST attend que les limites de connaissance d’un système soient documentées et que le système échoue sans danger lorsqu’on le fait fonctionner au-delà.
Vient ensuite le chemin vers une personne. Quand le système renonce ou qu’un client conteste, qui reçoit le dossier, avec quel contexte et dans quel délai ? Le cadre énumère des processus de supervision humaine, des canaux permettant aux utilisateurs de signaler des problèmes et de contester les résultats, et une responsabilité attribuée pour désactiver un système dont les résultats ne correspondent pas à l’usage prévu. Dans une petite entreprise, cela peut être une personne nommément désignée et un interrupteur.
Enfin, la panne. Le NIST demande des procédures de secours pour traiter les défaillances ou incidents touchant des systèmes d’IA tiers que l’organisation juge à haut risque. Décidez comment la tâche sera accomplie le jour où le service est à l’arrêt, et gardez cette voie manuelle en état de fonctionner. Demandez au fournisseur son historique de disponibilité et ses conditions de notification des incidents, et lisez ce que le contrat prévoit lorsqu’il ne les respecte pas.
Sécurité et conformité se prouvent par des documents, pas des adjectifs
« De niveau entreprise », « sécurisé dès la conception » et « pleinement conforme » sont des descriptions. Une preuve a un auteur, un périmètre et une date. Demandez le dernier rapport d’audit ou d’évaluation indépendant et lisez ce qu’il couvrait, la synthèse du dernier test d’intrusion, la liste des sous-traitants, l’historique des incidents et le document qui décrit les limites du système et les conditions dans lesquelles il a été testé.
Les cadres vont dans le même sens. Le NIST attend que la sécurité et la résilience soient évaluées et documentées, et que des évaluateurs indépendants, ou des experts internes qui n’ont pas été les développeurs directs du système, participent aux évaluations régulières. Les lignes directrices suggèrent aux acheteurs d’envisager d’exiger des audits indépendants et de rechercher des mesures de sécurité solides et proportionnées : un outil qui réécrit des descriptions publiques de produits appelle moins d’examen qu’un outil qui lit des dossiers clients.
Soyez précis sur ce que recouvre la référence à un cadre. Celui du NIST est volontaire, et son propre texte précise que ses actions ne constituent pas une liste de contrôle et que chaque organisation peut choisir parmi ses catégories. « Aligné sur le NIST » est donc une affirmation à détailler : demandez quelles pratiques sont en place et où elles sont consignées. Le NIST a publié la version 1.0 en janvier 2023 et, lors de la vérification de cet article en octobre 2026, son site indiquait que cette version était en cours de révision : confirmez l’édition en vigueur avant de citer ses sous-catégories numérotées.
Lisez d’abord la clause de sortie : la dépendance se signe le premier jour
La dépendance au fournisseur est rarement un piège. Elle s’accumule : des instructions ajustées à un produit, des documents convertis dans un format, du personnel formé à un écran. Les lignes directrices demandent aux acheteurs d’éviter les systèmes « boîte noire » et la dépendance au fournisseur, et citent les standards ouverts parmi les bonnes pratiques.
Demandez ce que vous pourrez emporter et sous quelle forme : vos documents, les instructions et les paramétrages rédigés pour vous, vos cas de test et leurs résultats, les journaux. Demandez à qui appartient ce qui a été créé pendant la prestation et ce que deviennent vos données dans les systèmes du fournisseur après la résiliation. Les lignes directrices conseillent de définir les rôles et les processus de fin de contrat pour les deux parties, et l’ICO indique qu’un acheteur doit pouvoir changer de prestataire si l’usage d’un service externalisé n’est plus conforme.
L’autre moitié de la sortie, c’est le changement. Le modèle sur lequel repose un service sera mis à jour, et le comportement que vous avez testé peut évoluer sans aucune action de votre part. Demandez quel préavis vous aurez avant un changement de modèle ou de prix, si vous pouvez rester un temps sur la version précédente et si vous pouvez rejouer vos propres cas de test avant que le changement n’atteigne vos clients.
Un pilote payant avec règle d’arrêt, puis une date pour le prochain test
Réunissez les vérifications dans un pilote court et payant. Inscrivez sur une page les critères d’acceptation, les cas de test, la durée et la date de décision, et convenez à l’avance du résultat qui signifie l’arrêt. Les lignes directrices recommandent des points de décision « on continue ou on arrête », et le NIST décrit ce même moment comme la détermination de savoir si le système atteint ses objectifs et si le déploiement doit se poursuivre. Un pilote sans règle d’arrêt est un achat payé en plusieurs fois.
Réussir le pilote ne clôt pas l’évaluation. Les lignes directrices le disent sans détour : il faut tester pendant toute la durée de vie, ce n’est pas une décision prise une fois pour toutes, et l’acheteur doit convenir avec le fournisseur de la manière dont le modèle sera surveillé une fois déployé. Conservez vos cas de test, ajoutez-y chaque défaillance réelle et rejouez l’ensemble à date fixe et après chaque changement de modèle annoncé.
Certaines réponses devraient mettre fin tôt à la discussion. Un fournisseur qui refuse un essai sur vos documents, ne sait pas dire où vos données sont conservées, ne propose aucun accès à une personne quand le système échoue ou n’a rien à dire sur la sortie vous indique ce que sera la relation. Un fournisseur qui répond par écrit aux sept vérifications, y compris les plus gênantes, a fait pour vous une bonne part de votre analyse de risques.
Checklist pratique
- Écrivez le problème, les critères d’acceptation et le seul résultat qui ne doit jamais se produire avant de contacter un fournisseur.
- Rassemblez des cas réels, y compris difficiles et sans réponse possible, et faites noter chaque résultat par ceux qui font le travail.
- Obtenez des réponses écrites sur le lieu de stockage, la conservation, l’usage pour l’entraînement, les sous-traitants et la suppression, puis montrez-les à votre conseil en protection des données.
- Calculez le coût d’une tâche acceptée, temps de vérification compris, et soumettez le processus manuel au même calcul.
- Convenez avant de signer de la solution de repli, du préavis en cas de changement de modèle ou de prix et de l’export de vos documents.
Questions et réponses
Combien de temps doit durer l’essai d’un service d’IA ?
Il n’existe pas de durée standard. L’essai doit être assez long pour faire passer au moins deux fois l’ensemble de vos cas et pour observer une semaine ordinaire d’utilisation réelle. La durée compte moins que la préparation : avec des critères et des cas prêts dès le premier jour, un pilote court donne une réponse plus nette qu’un long pilote qui commence par de l’exploration. Fixez la date de décision avant le début du pilote.
Que demander à un fournisseur d’IA au sujet de mes données ?
Cinq choses, par écrit : dans quels pays et quels systèmes les données sont traitées et stockées, la durée de conservation des entrées, des sorties et des journaux, si une partie sert à entraîner ou à améliorer des modèles, quels sous-traitants les reçoivent et ce qui est effacé à la fin du contrat. S’il s’agit de données personnelles, transmettez les réponses à votre conseil en protection des données. Un fournisseur incapable de répondre précisément vous a dit quelque chose d’important.
Le score d’un fournisseur à un benchmark est-il une raison d’acheter ?
C’est une raison de le présélectionner, pas d’acheter. Un benchmark mesure la performance sur le jeu de test de quelqu’un d’autre, dans les conditions de quelqu’un d’autre. Le cadre du NIST demande que la performance soit démontrée dans des conditions proches du contexte où le système sera utilisé, ce qui signifie pour un acheteur ses documents, les questions de ses clients et sa définition d’un résultat acceptable.
Une petite entreprise peut-elle le faire sans équipe technique ?
Oui. La plupart des vérifications tiennent en des questions et un tableur : une liste de cas réels, une colonne par fournisseur, trois notes possibles et le temps passé à corriger. Les collègues qui assurent la tâche aujourd’hui sont les meilleurs juges du résultat. Une aide extérieure mérite d’être payée à deux endroits : la lecture des clauses de protection des données et l’examen des preuves de sécurité.
Quels sont les signaux d’alerte lors de l’achat d’un service d’IA ?
Le refus d’un essai sur vos documents, des réponses vagues sur la conservation des données ou leur usage pour l’entraînement, aucune description de ce qui se passe quand le système échoue, des preuves faites d’adjectifs et un contrat sans clause d’export ni de résiliation. La pression pour signer avant la fin du pilote figure sur la même liste. Un seul de ces signaux est une question à creuser ; plusieurs réunis sont une raison de renoncer.