6.1 Gouverner l'IA
La classification des risques de l'AI Act range un système d'IA dans une classe selon l'usage auquel il est destiné: pratique interdite, haut risque, obligation de transparence ou risque minimal. La classe fixe les obligations du fournisseur et celles du déployeur. Une organisation suisse y est soumise quand elle met un système sur le marché de l'Union ou quand la sortie de son système y est utilisée. L'analyste pose les questions dans un ordre fixe: le champ d'application, le rôle, puis chaque classe de la plus stricte à la plus légère.
La classe de risque suit l'usage prévu du système. La page «Du modèle au produit» montre un même modèle intégré dans trois systèmes de classes différentes. L'analyste classe donc un cas d'usage.
L'article 2 du règlement (UE) 2024/1689 (AI Act) vise le fournisseur qui met un système d'IA sur le marché de l'Union ou en service dans l'Union. Il le vise même quand ce fournisseur est établi hors de l'Union. Il vise aussi le fournisseur ou le déployeur d'un pays tiers quand la sortie du système est utilisée dans l'Union.
Un éditeur suisse qui vend un logiciel de tri des candidatures à des entreprises de l'Union entre dans le champ comme fournisseur. Une banque suisse dont le chatbot répond à des résidents de l'Union y entre par la sortie. Le texte publicitaire que l'IA rédige pour des prospects de l'Union y entre de la même façon. Un outil qui trie les candidatures au siège suisse pour des postes en Suisse reste hors du champ.
Le règlement ne s'applique ni à la recherche et aux essais menés avant la mise sur le marché ni à l'usage personnel non professionnel. Un système publié sous licence libre et ouverte lui échappe aussi sauf s'il relève de l'article 5, du haut risque ou de l'article 50.
La Suisse n'a pas de loi équivalente. Le 12 février 2025, le Conseil fédéral a décidé de ratifier la convention du Conseil de l'Europe sur l'intelligence artificielle. Il prévoit d'adapter le droit suisse secteur par secteur et a chargé l'administration de préparer un projet de consultation pour la fin de 2026. Aucun texte suisse ne fixe de classe de risque. Un usage purement suisse relève du droit suisse. S'il traite des données personnelles, il relève aussi de la loi fédérale sur la protection des données (LPD), que la page «La LPD et les données confidentielles» traite.
Le rôle décide des obligations. Selon l'article 3, le fournisseur développe un système d'IA ou le fait développer. Il le met sur le marché ou en service sous son nom ou sa marque, contre paiement ou gratuitement. Le déployeur utilise un système d'IA sous son autorité dans un cadre professionnel. Une organisation qui bâtit un assistant sur l'API d'un modèle à usage général et le met en service sous son nom est le fournisseur de cet assistant.
L'article 25 fait d'un déployeur le fournisseur d'un système à haut risque quand il:
Le dernier cas surprend l'acheteur. Une entreprise qui configure un assistant acheté pour trier des candidatures change sa destination. Elle devient le fournisseur d'un système à haut risque.
L'analyste examine les classes de la plus stricte à la plus légère. Une pratique interdite arrête l'examen. Après un haut risque, l'examen continue: un système à haut risque qui dialogue avec des personnes porte aussi les obligations de l'article 50.
Pratique interdite. Parmi les pratiques que l'article 5 interdit figurent la manipulation préjudiciable, la notation sociale et certains usages biométriques. La modification de 2026 y ajoute les systèmes qui produisent des contenus intimes sans consentement ou d'abus sexuels sur des enfants. Les lignes directrices de la Commission du 4 février 2025 commentent les pratiques interdites. L'organisation abandonne un cas d'usage interdit.
Haut risque. L'article 6 ouvre deux voies. La première vise un produit que régit une législation de l'annexe I et qu'un tiers doit évaluer avant sa mise sur le marché. Elle vise aussi le composant de sécurité d'un tel produit. L'annexe I couvre par exemple les jouets, les ascenseurs et les dispositifs médicaux. Depuis la modification de 2026, une fonction d'assistance, d'optimisation, de confort ou de contrôle qualité ne compte comme composant de sécurité que si sa défaillance met en danger la santé ou la sécurité.
La seconde voie vise les usages que liste l'annexe III: biométrie, infrastructures critiques, éducation, emploi et gestion du personnel, accès aux services essentiels, répression, migration et contrôle aux frontières, justice et processus démocratiques. Les services essentiels comprennent l'évaluation de la solvabilité des personnes et la tarification de l'assurance vie et maladie.
Un usage de l'annexe III échappe au haut risque s'il ne présente pas de risque important pour la santé, la sécurité ou les droits fondamentaux. Il doit en plus remplir l'une des conditions de l'article 6, paragraphe 3:
Un système qui profile des personnes physiques reste à haut risque. Le fournisseur qui invoque l'exception documente son évaluation avant la mise sur le marché. Il enregistre le système dans la base de données de l'Union (art. 6, par. 4 et art. 49, par. 2).
Obligation de transparence. L'article 50 vise les systèmes qui dialoguent avec des personnes ou qui génèrent des contenus. Il vise aussi la reconnaissance des émotions et la catégorisation biométrique.
Risque minimal. Un cas d'usage qui ne relève d'aucune de ces classes est à risque minimal. Le fournisseur d'un modèle d'IA à usage général porte ses propres obligations depuis le 2 août 2025. L'organisation qui intègre ce modèle dans un système porte les obligations de la classe de ce système.
| Classe | Fournisseur | Déployeur | Date d'application |
|---|---|---|---|
| Pratique interdite | Ne met pas le système sur le marché (art. 5). | N'utilise pas le système (art. 5). | 2 février 2025. 2 décembre 2026 pour les contenus intimes sans consentement et les abus sexuels sur des enfants. |
| Haut risque | Gestion des risques, qualité des données, documentation technique, journalisation, contrôle humain, évaluation de la conformité et enregistrement (art. 8 à 21, 43 et 49). Le fournisseur établi hors de l'Union désigne par mandat écrit un mandataire dans l'Union avant de mettre le système à disposition sur le marché de l'Union (art. 22). | Usage conforme à la notice, contrôle humain confié à du personnel formé, contrôle des données d'entrée qu'il maîtrise, surveillance et signalement des incidents, journaux conservés six mois au moins, information des travailleurs et des personnes concernées (art. 26). Analyse d'impact sur les droits fondamentaux: organismes publics, entités privées qui fournissent un service public, solvabilité, assurance vie et maladie (art. 27). | 2 décembre 2027 pour l'annexe III. 2 août 2028 pour l'annexe I. |
| Transparence | Informer de l'interaction avec une IA quand le contexte ne la rend pas évidente (art. 50, par. 1). Marquer le son, les images, les vidéos et le texte générés dans un format lisible par machine (art. 50, par. 2). | Informer les personnes exposées à la reconnaissance des émotions ou à la catégorisation biométrique (art. 50, par. 3). Signaler les hypertrucages (deepfakes). Signaler le texte généré sur une question d'intérêt public que personne n'a relu sous sa responsabilité éditoriale (art. 50, par. 4). | 2 août 2026. 2 décembre 2026 pour le marquage des systèmes mis sur le marché avant le 2 août 2026. |
| Risque minimal | Aucune obligation propre au règlement. | Aucune obligation propre au règlement. | Sans objet. |
L'article 4 s'applique dans toutes les classes depuis le 2 février 2025. Le fournisseur et le déployeur prennent des mesures pour soutenir la maîtrise de l'IA de leur personnel. Ces mesures visent aussi les personnes qui utilisent le système pour leur compte.
Le règlement (UE) 2026/1744 modifie l'AI Act depuis le 27 juillet 2026. Il a reporté le haut risque de seize mois pour l'annexe III et d'un an pour l'annexe I. Une source antérieure à cette modification donne les anciennes dates. L'analyste lit les dates dans le texte en vigueur qui intègre ces modifications.
Tu aides à classer un cas d'usage d'IA selon le règlement (UE) 2024/1689 (AI Act) dans la version fournie dans <textes>. <cas_d_usage> [DESCRIPTION DU CAS D'USAGE] </cas_d_usage> <organisation> [ORGANISATION ET ORIGINE DU SYSTÈME] </organisation> <textes> [ARTICLES ET ANNEXES DU RÈGLEMENT] </textes> <consignes> 1. Appuie chaque réponse sur les seuls textes de <textes>. Ignore ce que tu sais du règlement. 2. Réponds aux questions dans cet ordre: a. Champ d'application (art. 2): le système est-il mis sur le marché ou en service dans l'Union? Sa sortie y est-elle utilisée? b. Rôle (art. 3 et 25): l'organisation est-elle fournisseur, déployeur ou les deux? L'article 25 la rend-il fournisseur? c. Pratique interdite (art. 5): le cas d'usage en relève-t-il? d. Haut risque (art. 6, annexes I et III): le cas d'usage en relève-t-il? Si l'article 6, paragraphe 3 peut s'appliquer, nomme la condition et dis si le système profile des personnes. e. Transparence (art. 50): quel paragraphe s'applique à quel rôle? 3. Pour chaque question, donne la réponse (oui, non ou indéterminé), l'article et le paragraphe, puis le passage de la description qui fonde la réponse. 4. Si la description ne permet pas de répondre, réponds «indéterminé» et formule la question à poser au métier. 5. Si le système n'entre pas dans le champ, réponds «hors champ» et arrête-toi après la question a. 6. Si le cas d'usage relève de l'article 5, arrête-toi après la question c. 7. Après un haut risque, passe quand même à la question e. 8. Termine par un tableau: question, réponse, article, obligation du fournisseur, obligation du déployeur. Tire les obligations des articles 16, 22, 26, 27 et 50. 9. Ne donne aucune date d'application. </consignes>
[DESCRIPTION DU CAS D'USAGE] décrit la finalité, les utilisateurs, les personnes que la sortie touche et les pays où elle sert. Elle ne contient aucune donnée de client.[ORGANISATION ET ORIGINE DU SYSTÈME] dit où l'organisation est établie et si elle a développé, acheté ou configuré le système. Elle nomme le nom ou la marque sous lesquels le système est mis en service.[ARTICLES ET ANNEXES DU RÈGLEMENT] reçoit les articles 2, 3, 5, 6, 16, 22, 25 à 27 et 50 ainsi que les annexes I et III. L'analyste les copie du texte en vigueur.La consigne 9 écarte les dates que le modèle tire de sa mémoire. L'analyste reprend les dates du texte en vigueur.
Une société de crédit à la consommation de Lausanne prête à des clients domiciliés en Suisse et en France voisine. Son analyste inscrit ses cas d'usage au registre.
| Cas d'usage | Sortie utilisée dans l'Union | Rôle | Classe | Base |
|---|---|---|---|---|
| 1 Score de solvabilité développé en interne | Oui (clients domiciliés en France) | Fournisseur et déployeur | Haut risque. L'exception est exclue: le score profile les demandeurs. | Annexe III, point 5 b. Art. 6, par. 3. |
| 2 Assistant du site bâti sur l'API d'un modèle à usage général | Oui (prospects français) | Fournisseur | Transparence | Art. 50, par. 1 et 2 |
| 3 Outil acheté de détection de fraude sur les paiements | Oui | Déployeur | Risque minimal | Annexe III, point 5 b, qui exclut la détection de fraude financière |
| 4 Outil acheté qui résume les séances de direction à Lausanne | Non | Déployeur | Hors champ | Art. 2 |
La société a développé le score de solvabilité et le met en service sous son nom. Elle en est donc le fournisseur. Elle prépare la documentation technique, l'évaluation de la conformité et l'enregistrement. Ses analystes de crédit utilisent le score. Elle en est donc aussi le déployeur: contrôle humain, journaux et analyse d'impact sur les droits fondamentaux. Ces obligations s'appliquent dès le 2 décembre 2027. L'analyste a posé au juriste une question ouverte: l'article 22 oblige-t-il la société à désigner un mandataire dans l'Union?
L'assistant du site relève de l'article 50 depuis le 2 août 2026. La société l'a bâti sur une API et le présente sous son nom. Elle en est donc le fournisseur. Il annonce dès le premier message qu'il est une IA. La société marque ses réponses dans un format lisible par machine. L'éditeur du modèle porte les obligations du modèle à usage général.
Le modèle avait classé la détection de fraude à haut risque. Il avait lu «crédit» dans la description. L'analyste a relu le point 5 b de l'annexe III, qui exclut la détection de fraude financière. Pour le résumé des séances, le modèle avait répondu «risque minimal». L'analyste a inscrit «hors champ»: la sortie ne sert qu'à Lausanne. Si la direction ouvre une filiale en France et y diffuse les résumés, le cas d'usage revient au registre.
Le EU AI Act Compliance Checker de la Commission pose en anglais les questions du rôle et de la classe. Il ne demande pas de compte. La Commission le publie en version bêta sans valeur de conseil juridique. Passez-y le score de solvabilité de l'exemple, puis l'un de vos cas d'usage. Comparez chaque résultat avec votre registre.
La classe légale ne mesure pas tout le risque. Un système à risque minimal peut tromper un client, exclure un groupe ou divulguer des données. L'analyste évalue chaque cas d'usage au-delà de sa classe. La page «Évaluer les risques de l'IA» traite cette évaluation.
La description part chez le fournisseur du modèle. Elle peut contenir des secrets d'affaires ou des données de clients. La classification n'a besoin que de la finalité, des rôles et des pays. L'analyste retire le reste avant l'envoi et utilise le service que son organisation a évalué. La page «La LPD et les données confidentielles» traite ce cadre.
Le contrôle humain reste à concevoir. Les articles 14 et 26 exigent un contrôle humain sur un système à haut risque. La page «Humain dans la boucle» montre comment le concevoir.
Le texte change. La Commission a publié un projet de lignes directrices sur le haut risque le 19 mai 2026. Ces lignes directrices n'ont pas de force obligatoire. Leur version finale peut changer la lecture de l'article 6, paragraphe 3. À sa parution, l'analyste réexamine chaque cas d'usage qui invoque cette exception.
Les amendes se calculent sur le chiffre d'affaires mondial. Une pratique interdite expose à 35 millions d'euros ou à 7 % du chiffre d'affaires annuel mondial. Le montant le plus élevé s'applique. Les autres obligations exposent à 15 millions d'euros ou à 3 %. Pour une PME, le montant le plus bas s'applique (art. 99).
La responsabilité reste à l'organisation. Le modèle et le Compliance Checker proposent une classe. Le juriste la valide. L'organisation répond de la classification devant les autorités de surveillance du marché des États membres.
Fondamentaux et techniques de la Business Analyse
Le cours pratique les techniques de spécification, dont les cas d'utilisation et scénarios, pour documenter les exigences d'un projet. L'analyste y apprend à décrire un cas d'usage avec la précision que la classification exige.
Les fondamentaux en gestion de projet
Le programme traite la gestion du risque en trois temps: identification, analyse et traitement. La classe légale d'un système d'IA entre dans cette analyse comme un risque du projet.