Les obligations liées à la phase de conception et de développement, telles que définies par le règlement européen sur l’IA (EU AI Act), se traduisent par un travail d’ingénierie bien avant la rédaction de toute note juridique. Ce cours se concentre sur les obligations des fournisseurs — c’est-à-dire les responsabilités incombant à l’équipe qui met en service un système d’IA — car ce sont les ingénieurs et les data scientists qui produisent la majeure partie des preuves nécessaires au respect de ces obligations. Les équipes négligent souvent cet aspect, car elles perçoivent leur travail comme le simple développement de fonctionnalités, alors que la validation finale dépend de ce qui a été enregistré, testé et maintenu de manière cohérente au fil des versions. Le problème ne vient généralement pas d’une mauvaise intention, mais d’un décalage entre ce que le système fait réellement et ce que l’équipe est en mesure de prouver qu’il fait.
Un fournisseur ne peut justifier la mise en service d’un système que si celui-ci repose sur une structure claire dès le départ. Cette structure englobe la nature du système, sa finalité, ainsi que ses capacités et ses limites dans l’environnement réel où il sera exploité. Elle inclut également les données d’entrée, les mécanismes de contrôle intégrés, les journaux d’activité (logs) disponibles et les actions qu’un humain peut entreprendre lorsque les résultats semblent erronés. Il est crucial d’appréhender ces différents éléments dans leur ensemble, car l’absence d’un composant n’est souvent découverte qu’une fois les étapes d’entraînement, d’intégration et de déploiement déjà franchies. Le schéma ci-dessous présente une vue d’ensemble du sujet avant d’aborder chaque volet en détail.
Dans ce cours, un système d’IA ne se résume pas à un fichier de modèle ou à une instruction (prompt) ingénieuse. Il s’agit de l’ensemble du dispositif qui reçoit des données issues d’un processus métier, produit des résultats sur lesquels les utilisateurs s’appuient, et adopte des comportements façonnés par le code, les données, la configuration et l’interface qui l’entoure. C’est pourquoi une modification mineure dans le pipeline peut changer l’impact du système dans le monde réel, même si les poids du modèle restent inchangés.
Une équipe peut penser qu’elle se contente d’« intégrer un modèle », mais l’objet soumis à réglementation est le système complet, dès lors qu’il intègre des décisions, des recommandations ou du contenu généré dans un flux de travail. La tâche d’entraînement, le magasin de caractéristiques (feature store), l’index de recherche, les garde-fous, les règles de surveillance et les textes de l’interface déterminent conjointement ce que l’utilisateur voit et les actions qu’il peut entreprendre ensuite. Si ces éléments ne sont pas associés à une version et à un objectif précis, les tests et la documentation ultérieurs ne correspondront pas à ce qui a réellement été mis en production.
Les ingénieurs et les data scientists sont généralement responsables des choix définissant l’objectif, les données d’entrée et les limites du système, car ces décisions se concrétisent dans les tickets, les jeux de données, les plans d’évaluation et les revues de code. Les équipes juridiques et de conformité peuvent interpréter la réglementation, mais elles ne peuvent pas reconstituer ce que le modèle a « vu » lors de l’entraînement ni ce que l’interface permettait au moment de la décision. L’équipe produit peut fixer des objectifs, mais elle ne peut ni remplacer des journaux (logs) manquants ni relancer une expérience dont les données n’ont pas été conservées.
La transition vers les équipes chargées du déploiement s’amorce également dès la phase de conception. Ces équipes ont besoin d’instructions claires, d’une transparence exploitable au sein de l’interface et de mécanismes de supervision efficaces même en situation de tension ; en effet, un document de politique ne saurait compenser un système qui dissimule sa propre incertitude ou empêche toute intervention humaine. Lorsque les concepteurs relèguent ces aspects à une simple « formalité administrative ultérieure », ils finissent généralement par devoir bricoler l’interface et réécrire la documentation pour qu’elles reflètent la réalité, une démarche plus lente qu’une conception initiale bien pensée.
Avant d’aller plus loin, il est utile d’identifier les modes de défaillance qui vous sont déjà familiers.