Adoption · Marchés publics · Services publics · Droits
AI Act pour l'administration publique et les achats d'IA
Une autorité publique n'est pas seulement cliente d'un vendeur. Lorsqu'elle utilise un système d'IA, elle est généralement déployeur, responsable de la finalité, des données, du contrôle, du suivi et des effets sur les personnes. Développer, modifier ou changer la marque du système peut changer son rôle.
01Commencer par la fonction du système
« Utiliser l'IA » ne suffit pas à déterminer le risque. Il faut examiner destination, procédure administrative, personnes concernées et effets des sorties. Un assistant de classement de documents n'équivaut pas à un système influençant prestations, emploi, santé, éducation ou activités de police.
- Quelle décision publique ou activité administrative soutient-il ?
- Ses sorties produisent-elles ou influencent-elles des effets juridiques ou l'accès à un service essentiel ?
- Quels groupes risquent des faux positifs, une exclusion ou un traitement inégal ?
- Existe-t-il une voie humaine réellement accessible, autorisée à corriger le résultat ?
02Un organisme public peut être déployeur ou fournisseur
| Situation | Première lecture | À vérifier |
|---|---|---|
| L'autorité achète et utilise un produit portant la marque du vendeur | Généralement déployeur | Finalité réelle, instructions, données d'entrée, contrôle attribué, journaux et suivi. |
| L'autorité commande un système et le met en service sous son nom | Elle peut être fournisseur | Qui définit la destination et les spécifications, sous quel nom le système est utilisé et qui porte les obligations de conformité. |
| L'autorité change la destination ou modifie substantiellement un système à haut risque | Elle peut devenir fournisseur | Portée du changement, nouvelle destination, classification résultante et documentation disponible. |
Le guide fournisseurs et déployeurs détaille le changement de rôle prévu à l'article 25.
Pour une entreprise privée, voir l'AI Act pour les entreprises.
03Questions pour l'achat d'IA
Un cahier des charges efficace va au-delà de l'exactitude. Il doit permettre de vérifier le système pendant tout le contrat et à l'organisme public d'exercer ses propres obligations.
| Finalité et risque | Quel problème public résout-il ? L'IA est-elle nécessaire ? L'usage est-il interdit, à haut risque, soumis à transparence ou hors de ces catégories ? |
|---|---|
| Données et performances | Sur quelles populations a-t-il été validé ? Quelles erreurs mesure-t-on ? Les données locales sont-elles pertinentes et représentatives de l'usage prévu ? |
| Explications et traces | L'autorité recevra-t-elle instructions, limites, documentation, journaux et informations suffisantes pour les audits, réclamations et contrôles contractuels ? |
| Contrôle humain | Qui peut écarter, corriger ou suspendre la sortie ? Dispose-t-il du temps, des compétences, de l'autorité et d'une interface permettant d'intervenir ? |
| Mises à jour et incidents | Comment les changements de modèle, performance, données ou destination sont-ils communiqués ? Qui signale un risque grave et qui peut arrêter le système ? |
| Sortie et portabilité | Comment exporter données et journaux ? Comment assurer continuité, réversibilité et maîtrise de la dépendance au fournisseur ? |
04Si le système est à haut risque
L'article 26 impose des obligations spécifiques aux déployeurs : respecter les instructions, confier le contrôle à des personnes compétentes et habilitées, maîtriser les données d'entrée relevant de leur responsabilité, surveiller le fonctionnement, conserver les journaux sous leur contrôle et signaler risques ou incidents.
- Une autorité publique ne doit pas utiliser un système à haut risque soumis à enregistrement s'il n'est pas enregistré dans la base européenne pertinente.
- Lorsqu'un système de l'annexe III prend ou aide à prendre des décisions concernant des personnes, des obligations d'information peuvent s'appliquer.
- Les organismes de droit public et les autres déployeurs visés à l'article 27 peuvent devoir réaliser une analyse d'impact sur les droits fondamentaux avant la première utilisation.
05Le contrôle humain exige une autorité réelle
Une signature humaine en fin de procédure ne suffit pas si la personne ne voit qu'un score, ignore les limites, manque d'informations ou ne peut pas contredire le système. Dans le jeu, de nombreux rapports deviennent contestables lorsque le contrôle existe sur le papier seulement.
06L'AI Act et les ressources de l'AgID italienne
Le règlement européen est la source juridique primaire de ce guide. L'agence numérique italienne AgID publie aussi des ressources pour le secteur public. La décision n° 43 du 10 mars 2026 documente l'ouverture de procédures de consultation et d'information sur les lignes directrices relatives au développement et à l'achat d'IA, avec les projets joints.
07Le cas « L'appel d'offres opaque »
Une plateforme d'attribution de marchés publics est achetée avec une documentation insuffisante. La leçon n'est pas que tout achat d'IA est interdit : une fonction sensible ne peut entrer dans un processus public sans comprendre sa validation, son contrôle et les possibilités de contester ses sorties.
08Sources officielles et limites
Consultez le règlement (UE) 2024/1689 sur EUR-Lex, notamment les articles 3, 25, 26 et 27, la FAQ de la Commission et les pages institutionnelles de l'AgID. Les obligations dépendent du système, de la destination et du droit sectoriel.