Ce cours porte sur les décisions relatives à la création d’une IA responsable, destinées aux ingénieurs qui déploient des systèmes d’IA, en s’appuyant sur l’IA Act de l’UE (Règlement (UE) 2024/1689). Il se concentre sur le travail du fournisseur, c’est-à-dire les choix qui transforment un modèle ou un pipeline en un produit défendable. Dans ce cours, l’IA responsable implique de concevoir, documenter, gouverner et déployer le système de manière à ce que ses limites soient claires et son comportement contrôlable. L’erreur commise par les équipes consiste à traiter les obligations du fournisseur comme une simple formalité administrative ajoutée au moment du lancement. Bien que ce travail puisse donner l’impression d’une documentation tardive, il est en réalité déterminé bien plus tôt par les choix de conception et de données. C’est pourquoi le cours revient constamment sur des éléments concrets (artefacts) que l’on peut nommer et versionner. Nous établissons d’abord une vue d’ensemble avant d’entrer dans les détails, afin que vous puissiez situer chaque obligation à sa juste place.
Une équipe de fournisseurs effectue déjà la majeure partie de ce travail de manière éparpillée : document d’architecture, fiche de modèle (model card), notebook d’évaluation, liste de contrôle pour la mise en production et tableau de bord de surveillance. Le problème est que ces éléments ne sont pas toujours alignés sur un objectif unique, ce qui laisse place à des lacunes entre les équipes. Une fois ces lacunes présentes, les utilisateurs en aval (déployeurs) ne peuvent pas exploiter le système en toute sécurité, car ils ignorent sa finalité initiale ou son comportement en conditions critiques. Le cours aborde les obligations du fournisseur selon un modèle structuré en trois phases : conception et données ; jalons de mise en production et preuves ; surveillance après mise sur le marché et gestion des incidents. C’est cette structure qui rend les leçons ultérieures concrètes et applicables. Voici un aperçu de ce modèle :
Dans le cadre de ce cours, un système d’IA est défini comme un système informatique conçu pour fonctionner avec divers niveaux d’autonomie et capable, à partir des données d’entrée qu’il reçoit, de déduire la manière de générer des résultats tels que des prédictions, du contenu, des recommandations ou des décisions. Un fournisseur est la personne ou l’organisation qui développe un système d’IA (ou le fait développer) et le met sur le marché ou en service sous son propre nom ou sa propre marque, que ce soit à titre onéreux ou gratuit. Cette définition est importante pour les ingénieurs, car il est possible de devenir fournisseur sans avoir entraîné les poids de base du modèle, simplement en étant responsable du système déployé et de sa finalité prévue. Vous franchissez ce cap lorsque les utilisateurs perçoivent votre système comme le produit lui-même et que votre équipe en contrôle le fonctionnement.
L’utilisation d’un modèle tiers ne fait pas automatiquement de ce tiers le fournisseur de l’ensemble de ce que vous déployez. Votre équipe reste maître des données d’entrée, de la signification des résultats et des garde-fous intégrés à l’interface. Ces choix définissent concrètement la finalité prévue, même si le service marketing n’utilise jamais cette expression. Lorsqu’un partenaire demande « Qui est le fournisseur ici ? », il cherche à savoir qui est en mesure de produire la piste d’audit probante, et non qui a écrit la première ligne de code du modèle.
Les ingénieurs prennent en charge les aspects du rôle de fournisseur qui ne peuvent se concrétiser que par la réalisation technique (le « build »). Les services de conformité et le service juridique peuvent aider à interpréter l’AI Act, mais ils ne peuvent pas ajouter a posteriori des mécanismes de journalisation, des points de contrôle ou une couverture d’évaluation une fois le système déployé. La difficulté récurrente consiste à traduire une obligation légale en éléments concrets identifiables dans un dépôt de code, une série de tests ou une étape de validation avant mise en production. C’est à cette étape de traduction que les projets dévient généralement, car elle implique plusieurs équipes et calendriers. Lorsque le processus est bien mené, le résultat technique est sans surprise et facilement vérifiable.
Une équipe qui maîtrise ce processus adopte systématiquement la même approche : elle définit la finalité prévue très tôt, puis y associe les choix de conception et la documentation. Elle considère la documentation comme le reflet fidèle de la réalisation technique, et non comme un récit rédigé ultérieurement ; elle est ainsi versionnée en même temps que le système. Elle distingue également les exigences devant être satisfaites avant la mise sur le marché de celles devant être maintenues après le lancement, car le déploiement modifie les possibilités de correction à moindre coût. Si vous pouvez identifier l’artefact correspondant à une obligation, vous pouvez lui assigner un responsable et une date d’échéance.