Checklist d'achat d'IA pour les équipes gouvernementales et de santé

Les acheteurs du secteur public et de la santé devraient évaluer les fournisseurs d'IA sur leur capacité d'audit, la résidence des données, les dispositifs de supervision humaine et les conditions de sortie — avant de se laisser séduire par la qualité d'une démonstration. Inscrivez ces exigences dans l'appel d'offres lui-même, car les intégrer après qu'un système touche déjà des données de citoyens ou de patients est plus long, plus coûteux, et parfois impossible sans refonte complète.

La plupart des équipes d'achat conduisent encore la sélection d'un fournisseur d'IA comme un appel d'offres logiciel classique : fonctionnalités, prix, références, démonstration. Cette démarche passe à côté des modes de défaillance qui causent réellement des problèmes dans les déploiements du secteur public et de la santé : un système d'IA incapable de justifier une décision, des données hébergées dans le mauvais pays, ou une relation fournisseur dont il est impossible de sortir sans perdre ses propres données. Voici une checklist construite autour des questions qui comptent vraiment.

Commencez par l'auditabilité, pas par la précision

Une démonstration fournisseur vous montrera toujours le scénario idéal. Ce que vous devez voir, c'est ce qui se passe quand le système se trompe, et si vous pouvez reconstituer pourquoi.

• Demandez un cas d'échec journalisé. Pas un exemple théorique — une vraie transcription du système commettant une erreur, accompagnée de la piste d'audit qui a permis de la détecter.
• Vérifiez ce qui est réellement journalisé. À minima : les entrées, les sorties, la version du modèle et l'horodatage. Si le fournisseur ne consigne que la réponse finale, vous serez dans l'impossibilité d'instruire une réclamation six mois plus tard.
• Confirmez que les journaux sont exportables, et non enfermés dans le tableau de bord du fournisseur. Si votre équipe juridique ou de conformité a un jour besoin des enregistrements pour un audit, vous devez pouvoir les extraire sans dépendre de la coopération du fournisseur.

C'est aussi là qu'l'architecture du système joue discrètement un rôle déterminant. Dans nos propres travaux sur les agents, nous avons constaé qu'un appel de modèle bien délimité est beaucoup plus facile à auditer qu'une chaîne de cinq étapes, car il y a une seule entrée, une seule sortie, et un seul endroit où chercher en cas de problème. Un fournisseur qui enchaîne de nombreux appels d'outils et sous-agents pour répondre à une question simple ne fait pas forcément quelque chose de problématique, mais il multiplie les points à expliquer ultérieurement — et vous devriez lui demander comment il journalise les étapes intermédiaires, pas seulement les résultats finaux. Si vous évaluez des fournisseurs précisément sur cet axe, appel unique vs chaînes d'agents vaut la peine d'être lu avant que l'appel d'offres ne soit publié.

La résidence et l'accès aux données sont des clauses contractuelles, pas des détails techniques

Où vivent les données, qui peut y accéder et ce qu'il en advient à la fin du contrat : ce sont des questions d'achat, pas des questions IT à régler plus tard.

• Obtenez des réponses précises sur l'endroit où les données sont traitées et stockées, y compris chez les sous-traitants (le fournisseur LLM du prestataire, l'hébergeur cloud ou les outils d'analyse).
• Demandez si vos données servent à entraîner les modèles du fournisseur, et si oui, au profit de qui. De nombreux produits d'IA via API n'entraînent pas leurs modèles sur les données clients par défaut, mais certaines offres managées ou de fine-tuning le font parfois — cela doit être un opt-in explicite, pas une clause enfouie dans une mise à jour des conditions d'utilisation.
• Pour la santé spécifiquement, confirmez que le fournisseur signera un Business Associate Agreement si des données PHI sont impliquées ; un fournisseur qui hésite sur ce point vous en dit long sur le sérieux avec lequel il traite le reste de la checklist.
• Pour tout ce qui concerne des citoyens de l'UE, comprenez vos obligations au titre de l'EU AI Act. Bon nombre de ses obligations incombent à l'organisation qui déploie le système, pas seulement au fournisseur — votre contrat doit donc préciser qui fait quoi : qui mène l'évaluation des risques, qui maintient la documentation technique, qui traite une demande d'un régulateur.

La supervision humaine est une exigence de conception, pas un bonus

Pour tout ce qui touche à l'éligibilité à des prestations, à un diagnostic ou à un résultat juridique, une personne réelle doit pouvoir intervenir avant que le préjudice survienne, pas après.

• Demandez au fournisseur de vous montrer l'interface de supervision réelle, pas de vous la décrire. À quel endroit un agent de terrain ou un clinicien voit-il le niveau de confiance du système, et comment rejette-t-il ou escalade-t-il une décision ?
• Confirmez que le circuit de supervision est suffisamment rapide pour être utile. Un processus de révision de trois jours n'aide pas quelqu'un à qui une prestation est refusée aujourd'hui.
• Comprenez le comportement par défaut en cas de défaillance. Le système échoue-t-il de façon fermée (signalement pour révision humaine) ou ouverte (poursuite sur la base d'une meilleure estimation) ? Pour les décisions à fort enjeu, vous souhaitez que l'échec fermé soit le comportement par défaut, pas une option de configuration que quelqu'un a oublié d'activer.

Cela rejoint directement la façon dont le système sous-jacent est conçu. Si vous construisez ou spécifiez ce système en interne plutôt que de l'acheter clé en main, court-ready architecture for healthcare AI explique à quoi ressemble concrètement un système auditable et défendable au niveau de l'infrastructure.

Les clauses contractuelles qui vous protègent après la signature

L'achat ne s'arrête pas à la signature du contrat. Les clauses qui comptent le plus sont celles que vous espérez ne jamais avoir à invoquer.

• Droits d'export des données et du modèle. Si vous quittez le fournisseur, conservez-vous vos données historiques et les poids du modèle éventuellement affiné, ou repart-on de zéro ?
• Notification préalable des mises à jour de modèle. Les systèmes basés sur un LLM changent de comportement quand le modèle sous-jacent évolue. Vous voulez un préavis et, idéalement, une fenêtre de validation avant qu'une nouvelle version du modèle ne soit déployée en production.
• SLA de réponse aux incidents, spécifiquement pour le système d'IA, et pas seulement pour la disponibilité générale. Un diagnostic erroné ou une prestation refusée à tort relèvent d'une classe de gravité différente d'un temps de chargement lent, et le contrat doit le refléter.
• Clauses de responsabilité et d'indemnisation qui nomment explicitement les modes de défaillance propres à l'IA (hallucination, biais, fuite de données) plutôt que de s'en remettre à un langage générique sur les défauts logiciels, rédigé avant l'existence des LLM.

Si vous souhaitez un cadre plus général pour évaluer les fournisseurs au-delà de cette checklist, notre checklist d'évaluation des fournisseurs d'agents IA couvre les critères plus larges (structure de coûts, latence, modèle de support) qui s'appliquent également en dehors des secteurs très réglementés. Et si les evals font partie — ou devraient faire partie — de votre processus d'évaluation, intégrer les evals dans le contrat lui-même vaut la peine d'être lu avant de finaliser les termes.

Ce que cela donne en pratique

Rien de tout cela n'exige un spécialiste de l'IA dans votre équipe d'achat. Cela exige de demander des preuves plutôt que des promesses : un vrai cas d'échec plutôt qu'une démonstration sans accroc, un export réel des journaux plutôt qu'une description de ce qui est enregistré, une présentation en direct de l'écran de supervision plutôt qu'une diapositive sur l'« humain dans la boucle ». Les fournisseurs qui ont réellement conçu des systèmes défendables auront tout cela prêt. Ceux qui ne l'ont pas fait auront besoin de semaines pour le produire — ce qui est en soi une information précieuse avant de signer quoi que ce soit.

Si vous définissez le périmètre d'un système d'IA pour un contexte gouvernemental ou de santé et souhaitez un regard extérieur sur l'appel d'offres ou la présélection de fournisseurs, parlons-en.