Ce cours porte sur la vérification d’un système d’IA avant son acquisition, afin de permettre à l’acquéreur de prendre une décision d’achat justifiée. Il s’appuie principalement sur le règlement européen sur l’IA (EU AI Act) comme cadre juridique et considère les équipes chargées des achats et de la conformité comme les acteurs clés devant déterminer ce qu’il convient d’exiger ou de refuser. De nombreuses équipes abordent l’achat d’IA comme celui d’un logiciel classique, où la démonstration et l’évaluation de la sécurité semblent constituer les étapes les plus ardues. Or, la véritable difficulté réside dans l’évaluation du comportement du système en conditions réelles d’utilisation, car ses résultats peuvent varier en fonction des instructions (prompts), des données et du contexte. Cette variabilité peut passer inaperçue, le fournisseur étant en mesure de présenter un flux de travail parfaitement rodé. Il incombe alors à l’acheteur de déterminer quelles preuves sont suffisantes.
Dans le cadre de ce cours, un système d’IA désigne un logiciel capable de générer, à partir de données d’entrée, des résultats tels que des textes, des scores, des recommandations ou des décisions, susceptibles d’influencer les actions ultérieures des utilisateurs. Cet aspect est crucial pour le processus d’achat, car une même fonctionnalité peut avoir un impact faible dans un cas d’usage et un impact majeur dans un autre, selon les personnes concernées et les modalités d’utilisation. Ce travail s’inscrit dans des étapes courantes telles que l’examen du dossier fournisseur, la validation du cas d’usage et la définition des conditions de déploiement. La complexité survient lorsque la question ne se limite plus à savoir si le système fonctionne, mais porte également sur ce qu’il pourrait accomplir dans notre environnement spécifique, au-delà de ce que la démonstration a révélé. Il est utile d’avoir une vue d’ensemble du processus dès le départ, car chaque vérification correspond à une étape précise du parcours d’achat. Voici un aperçu de ce flux de travail.
Un logiciel classique produit généralement le même résultat pour une même entrée ; il suffit donc de le tester une fois et de figer le résultat dans le cahier des charges. Un système d’IA peut être fiable en termes de disponibilité tout en produisant des résultats variables, car il génère ou déduit ses sorties au lieu de suivre des règles fixes. Par conséquent, vous ne pouvez pas vous fier à un unique test de recette pour garantir le bon fonctionnement en conditions réelles, même si le fournisseur affirme que la solution est prête pour la production. Vous devez lier l’évaluation à l’usage précis envisagé, en tenant compte notamment de l’identité des destinataires des résultats et des actions que ces derniers peuvent déclencher.
Le piège, lors de l’achat, consiste à assimiler le modèle au produit, alors que le produit englobe l’ensemble du système qui l’entoure. Ce système comprend l’interface utilisateur, les invites (prompts), les mécanismes d’extraction de vos documents, les intégrations et toute étape de validation humaine. Ces éléments déterminent la circulation des données et les informations enregistrées. Ils conditionnent également la facilité avec laquelle les erreurs peuvent être détectées avant d’atteindre un client, un candidat ou un employé.
Les services Achats et Conformité n’ont pas besoin de piloter la mise en œuvre pour mener une diligence raisonnable efficace. La décision d’achat et la définition des conditions vous appartiennent ; vous pouvez donc exiger des documents justificatifs et des réponses claires avant de signer. Si les équipes Produit et Informatique gèrent généralement les détails de l’intégration et que le service Protection des données traite les aspects liés à la confidentialité, vous pouvez néanmoins demander à chacun d’eux un élément concret étayant la décision d’achat. L’essentiel est de poser des questions qui aboutissent à des documents plutôt qu’à de simples assurances verbales.
Une répartition utile des tâches consiste à distinguer les affirmations du fournisseur, les confirmations de vos équipes internes et les observations réalisées lors d’un essai. Les affirmations du fournisseur figurent dans des documents tels que les fiches techniques, les rapports de sécurité ou les notices d’utilisation. Les confirmations internes se trouvent dans des notes d’intégration, des projets de procédures opérationnelles ou des validations de risques. Enfin, les observations sont consignées dans les rapports de tests, les notes des équipes d’audit (red team) et les captures d’écran illustrant le comportement du système face à vos invites et vos données.
Cette vérification ne présente d’intérêt que si elle modifie les points sur lesquels vous porterez votre attention par la suite. Un même système peut sembler sûr lors d’une démonstration tout en soulevant des interrogations dès que l’on précise le cas d’usage et les personnes concernées. Identifiez la première préoccupation qui vous vient à l’esprit pour chaque scénario, car c’est elle qui déterminera votre prochaine demande auprès du fournisseur.