Un collaborateur colle un contrat dans un assistant grand public. Une équipe automatise des remboursements avec un agent. Un fournisseur ajoute discrètement une fonction générative à un logiciel déjà déployé. Un modèle de scoring change de version sans nouvelle validation.
Ces quatre événements relèvent de la gouvernance IA. Aucun ne sera résolu par une charte générale seule.
L’enjeu est de transformer des principes — loyauté, sécurité, contrôle humain, souveraineté — en décisions vérifiables. Qui autorise ? Qui exploite ? Quel seuil déclenche un arrêt ? Quelle preuve peut être montrée à un client, un régulateur ou une personne concernée ?
1. Chiffres clés : l’adoption progresse plus vite que la maîtrise
Eurostat estime que 20 % des entreprises de l’Union européenne d’au moins dix salariés utilisaient une technologie d’IA en 2025, soit 6,5 points de plus qu’en 2024. Le taux atteignait 17 % dans les petites entreprises, 30,36 % dans les moyennes et 55,03 % dans les grandes. La gouvernance ne concerne donc plus quelques laboratoires.
En France, l’Insee mesurait 10 % d’entreprises utilisatrices en 2024 : 9 % des petites, 15 % des moyennes et 33 % des grandes. Parmi les utilisatrices, 69 % recouraient à des logiciels disponibles dans le commerce. Cette donnée est importante. Une entreprise peut être responsable d’un usage sans avoir développé le modèle ni maîtriser son entraînement.
France Num observait en 2025 que 26 % des TPE-PME utilisaient l’IA : 22 % pour l’IA générative, 14 % pour les chatbots, mais seulement 5 % pour l’automatisation de tâches et 5 % pour l’analyse de données. L’écart entre usage individuel et intégration opérationnelle invite à prévoir deux régimes : règles simples pour les assistants, contrôles renforcés pour les systèmes qui agissent.
Les signaux de risque augmentent en parallèle. L’AI Index 2026 de Stanford recensait 362 incidents liés à l’IA en 2025, contre 233 en 2024. Son indice de transparence des modèles fondationnels a chuté d’une moyenne de 58 sur 100 en 2024 à 40 en 2025. Les entreprises doivent donc demander davantage de preuves au moment même où les capacités s’intègrent plus profondément.
La sécurité agentique reste difficile. Dans une évaluation du NIST publiée en 2025, les attaques de détournement réussissaient dans 57 % des cas avec une tentative et dans 80 % après 25 tentatives selon le protocole testé. Une protection qui bloque neuf formulations sur dix peut échouer lorsqu’un attaquant peut recommencer.
2. Le plan de contrôle : huit registres reliés
La gouvernance devient praticable lorsqu’elle s’organise autour de huit registres. Ils peuvent commencer dans un outil simple. Leur valeur vient de leur cohérence et de leur mise à jour.
2.1. Le registre des systèmes
Il recense les produits achetés, modèles, automatisations, assistants internes, expérimentations et fonctions IA intégrées à des logiciels tiers. Chaque entrée possèd'un propriétaire métier et un propriétaire technique.
Le registre répond au minimum à ces questions :
- quel objectif le système poursuit-il ?
- quelles personnes ou opérations affecte-t-il ?
- quelles données reçoit-il et produit-il ?
- quel modèle ou fournisseur utilise-t-il ?
- dans quels pays les données sont-elles traitées ?
- quelles actions peut-il déclencher ?
- quel niveau de supervision humaine s’applique ?
- quelles évaluations et versions sont actives ?
- quel contrat, quelle durée de conservation et quelle procédure d’arrêt ?
Il doit couvrir le shadow AI sans chercher à punir chaque expérimentation. Un canal de déclaration rapide, accompagné de solutions autorisées, obtient plus de visibilité qu’une interdiction impossible à faire respecter.
2.2. Le registre des risques
Chaque système est classé selon son impact, pas selon l’enthousiasme technologique. Une matrice simple combine la gravité d’une erreur, la probabilité, le volume, l’autonomie, la vulnérabilité des personnes et la difficulté de détection.
Logiks recommande quatre niveaux internes.
| Niveau | Exemple | Contrôle minimal |
|---|---|---|
| Assisté | rédaction d’un brouillon interne | règles d’usage, confidentialité, vérification |
| Conseillé | recommandation commerciale ou juridique | sources, évaluation, revue humaine documentée |
| Décisionnel | score influençant un accès ou une priorité | validation indépendante, recours, suivi des biais |
| Autonome | action externe ou financière | permissions minimales, confirmation, plafonds, arrêt d’urgence |
Cette classification interne ne remplace pas les catégories juridiques de l’AI Act. Elle guide les opérations au quotidien et peut être plus stricte lorsque le contexte l’exige.
2.3. Le registre des données
On documente les sources, finalités, bases légales, catégories sensibles, durées, destinataires, transferts, qualité et droits. Les données utilisées pour évaluer le système sont distinguées de celles utilisées pour l’entraîner ou l’exploiter.
La CNIL insiste sur la détermination du régime juridique, la définition d’une finalité, la qualification des responsabilités, la base légale, les tests et la sécurité. Ces travaux ne doivent pas commencer la veille du déploiement. Un choix d’architecture — journaliser les conversations, réutiliser les entrées, héberger hors UE — peut rendre la correction tardive coûteuse.
2.4. Le registre des modèles et fournisseurs
Pour chaque modèle, l’entreprise conserve la version, les conditions d’usage, la région, les sous-traitants, les limitations connues, les résultats internes, les dates de changement et le plan de remplacement. Les fiches commerciales ne suffisent pas.
La diligence porte sur les données utilisées, la propriété intellectuelle, la sécurité, la notification d’incident, les engagements de disponibilité, la conservation, l’audit, l’export et la fin de contrat. Lorsqu’une information n’est pas fournie, elle est notée « inconnue », pas supposée favorable.
2.5. Le registre des évaluations
Il relie chaque version à un jeu de tests, des seuils et une décision de mise en production. Les métriques couvrent la qualité, les groupes affectés, la robustesse, la sécurité, la latence et le coût.
Les tests sont proportionnés à l’usage. Un générateur de variantes publicitaires n’exige pas le même niveau de preuve qu’un système de recrutement. Mais tout système possèd'une définition de l’échec et un propriétaire capable d’intervenir.
2.6. Le registre des accès et actions
Il décrit qui peut utiliser le système, lire quelles données, appeler quels outils et valider quelles actions. Les permissions sont attachées à l’identité de l’utilisateur et du service. Elles ne sont jamais accordées parce qu’un modèle le demande dans son texte.
Une action est décomposée : proposer, préparer, simuler, exécuter, annuler. Un agent peut préparer un remboursement sans pouvoir l’envoyer. Cette granularité réduit le rayon d’impact d’une erreur ou d’une injection.
2.7. Le registre des incidents
Les erreurs critiques, fuites, discriminations, contournements, violations de droits et actions inattendues suivent un processus commun : détection, confinement, analyse, notification, correction et retour d’expérience.
Le signal faible compte. Vingt corrections manuelles similaires peuvent annoncer un incident avant qu’un dommage ne soit déclaré. La gouvernance relie donc les retours utilisateurs à la gestion des risques.
2.8. Le registre des décisions
Il conserve les arbitrages : pourquoi ce fournisseur, pourquoi ce seuil, pourquoi une exception, qui l’a approuvée et jusqu’à quand. Cette mémoire évite de rouvrir le même débat et montre que la décision a été prise avec les informations disponibles.
Une gouvernance sans décisions datées devient une collection de documents. Une décision sans preuve devient une opinion.
3. AI Act : situation au 13 juillet 2026
Le règlement européen sur l’intelligence artificielle, règlement (UE) 2024/1689, suit une application progressive. Il faut distinguer le texte publié, les obligations déjà applicables et les modifications encore en cours de finalisation.
Depuis le 2 février 2025, les interdictions concernant certaines pratiques d’IA et les dispositions relatives à la maîtrise de l’IA, souvent appelée « AI literacy », s’appliquent. Depuis le 2 août 2025, les règles de gouvernance et les obligations relatives aux modèles d’IA à usage général ont commencé à s’appliquer, avec les dispositions prévues par le règlement.
Le calendrier initial prévoyait l’application générale de la majorité des dispositions le 2 août 2026, puis certaines obligations liées aux systèmes à haut risque intégrés à des produits réglementés le 2 août 2027.
La Commission européenne indique toutefois qu’un accord politique provisoire a été trouvé le 7 mai 2026 sur des modifications ciblées. Selon sa page réglementaire à la date de ce guide, l’accord prévoit notamment un décalage des règles sur certains systèmes à haut risque : 2 décembre 2027 pour les systèmes de l’annexe III et 2 août 2028 pour ceux intégrés à des produits réglementés. Tant que la procédure législative et la publication correspondante ne sont pas achevées, une entreprise prudente ne traite pas ces dates comme une dispense acquise.
Trois conséquences pratiques en découlent.
Premièrement, l’obligation de développer un niveau suffisant de maîtrise de l’IA est déjà un sujet opérationnel. Une formation générique annuelle ne suffit pas nécessairement. Les compétences doivent correspondre aux systèmes, aux contextes d’usage et aux personnes concernées.
Deuxièmement, l’entreprise doit qualifier son rôle : fournisseur, déployeur, importateur, distributeur ou fabricant d’un produit. Une intégration ou une modification substantielle peut changer cette position. Le contrat ne décide pas seul de la qualification.
Troisièmement, attendre le dernier acte d’exécution serait risqué. Inventaire, gestion des risques, documentation, qualité des données, journaux, contrôle humain et surveillance après déploiement exigent du temps. Ces capacités sont utiles même lorsqu’un système ne relève finalement pas du haut risque.
Ce guide ne remplace pas une analyse juridique du cas précis. Il fournit le système de preuves qui rend cette analyse possible.
4. Sécurité : concevoir pour l’échec partiel
Les applications classiques exécutent un code écrit à l’avance. Les systèmes génératifs interprètent des instructions, du contexte et parfois des contenus externes. Cette flexibilité crée des frontières nouvelles.
4.1. Traiter le contenu comme non fiable
Un e-mail, une page web ou un PDF peut contenir des instructions destinées à détourner l’agent. Le texte récupéré ne doit jamais modifier les règles du système ni acquérir des permissions. Les instructions, les données et les outils restent séparés techniquement.
4.2. Réduire les permissions
Chaque agent utilise une identité propre et des droits temporaires. L’accès en lecture est séparé de l’écriture. Les montants, volumes, domaines destinataires et fréquences possèdent des plafonds. Les opérations irréversibles exigent une confirmation hors du canal contrôlé par le modèle.
4.3. Valider les entrées et les sorties
Les fichiers sont analysés, les formats limités et les secrets détectés. Les appels d’outils respectent un schéma strict. Une sortie de modèle ne devient jamais directement du SQL, du code shell ou du HTML actif sans validation et isolation.
4.4. Cloisonner l’exécution
Le code généré s’exécute dans un environnement jetable, sans réseau par défaut, avec des quotas de temps, mémoire et stockage. L’agent ne partage pas les secrets de l’application. Un comportement inattendu reste contenu.
4.5. Tester de façon adversariale
Les red teams simulent injection, exfiltration, contournement de politique, abus d’outil, répétition d’attaque et collusion entre contenus. Les tests sont réexécutés à chaque changement de modèle, prompt, outil ou source. Un résultat obtenu sur une version ne vaut pas pour la suivante.
4.6. Préparer l’arrêt
Un kill switch désactive un outil, un agent ou un fournisseur sans arrêter toute l’entreprise. Les équipes connaissent le mode dégradé manuel. La restauration et la révocation des secrets sont exercées, pas seulement documentées.
L’OWASP Top 10 for Agentic Applications, publié avec la contribution de plus de 100 experts, constitue un référentiel utile pour structurer ces scénarios. Le NIST complète cette approche par son AI Risk Management Framework et ses travaux consacrés à la sécurité des agents.
5. Contrôle humain : une fonction, pas un bouton
Ajouter « Valider » dans une interface ne crée pas un contrôle humain efficace. La personne doit disposer du temps, de l’information, de la compétence et de l’autorité nécessaires pour contester la sortie.
Un bon contrôle répond à cinq conditions :
- l’utilisateur sait ce que le système a fait ;
- il voit les preuves et les incertitudes utiles ;
- il peut corriger ou refuser sans pénalité excessive ;
- son action est enregistrée et analysée ;
- l’organisation ne fixe pas un volume qui rend la vérification fictive.
L’automatisation peut déplacer le risque vers l’humain. Si un analyste doit relire 300 décisions par heure, la validation devient un rituel. La métrique ne doit donc pas être « pourcentage avec humain dans la boucle », mais taux de détection des erreurs, temps disponible et effet réel de l’intervention.
6. Maîtrise de l’IA : former par responsabilités
Les collaborateurs n’ont pas tous besoin du même cursus. Logiks distingue quatre niveaux.
Utilisateur. Comprendre les limites, protéger les données, vérifier les résultats, citer l’usage lorsque nécessaire et signaler un incident.
Propriétaire métier. Définir la finalité, les erreurs critiques, le contrôle humain, les seuils et les résultats attendus.
Constructeur. Maîtriser les données, évaluations, sécurité, versionnement, observabilité et documentation.
Contrôleur. Savoir auditer les preuves, challenger une métrique, qualifier un rôle juridique et arrêter un système.
Chaque formation se termine par un exercice lié au poste. Côté achats : comparer deux clauses fournisseur. Pour un développeur : bloquer une injection indirecte. Pour un manager : décider d’un déploiement à partir d’un rapport d’évaluation.
La formation est reliée au registre. Une personne accède à un système sensible lorsqu’elle a suivi le module correspondant, puis renouvelle la compétence après un changement majeur.
7. Souveraineté : mesurer la capacité de décider et de sortir
La souveraineté n’est pas synonyme d’hébergement en France. Elle concerne la capacité à contrôler les données, l’exploitation, les clés, les fournisseurs, les composants et la continuité.
Une grille de décision peut couvrir sept axes.
Juridiction. Quelles entités contractent, administrent et sous-traitent ? Quels droits peuvent s’appliquer ?
Localisation. Où se trouvent stockage, sauvegardes, inférence, journaux et support ?
Technologie. Les modèles, bibliothèques, accélérateurs et formats peuvent-ils être remplacés ?
Données. L’entreprise peut-elle exporter les sources, embeddings, annotations, traces et tests dans un format exploitable ?
Opérations. Qui possèdes compétences pour diagnostiquer, restaurer et faire évoluer ?
Économie. Quelle variation de prix ou de volume rendrait le service non viable ?
Sortie. Combien de jours faut-il pour migrer, à partir d’une sauvegarde vérifiée ?
On attribue un niveau de maîtrise et une preuve à chaque axe. Une promesse « cloud souverain » sans clause, architecture ni exercice n’obtient pas de point.
Le choix peut être différencié. Une aide à la rédaction publique peut utiliser un service externe. Un corpus de recherche stratégique peut exiger un environnement dédié. Les fonctions critiques disposent d’une voie de repli et d’un mode manuel.
8. Diligence fournisseur : vingt questions qui comptent
La sélection ne doit pas se limiter à la performance. Voici les questions structurantes :
- Quelle entité fournit le service et quels sous-traitants interviennent ?
- Où les données sont-elles stockées, traitées et sauvegardées ?
- Les entrées et sorties servent-elles à entraîner ou améliorer le service ?
- Quelle durée de conservation s’applique par défaut et après résiliation ?
- Qui contrôle les clés de chiffrement ?
- Quels journaux sont accessibles au client ?
- Comment les incidents sont-ils détectés et notifiés ?
- Quelles certifications couvrent réellement le service utilisé ?
- Quelle version du modèle est active et comment les changements sont-ils annoncés ?
- Peut-on geler une version ou tester avant migration ?
- Quelles évaluations de sécurité et de biais sont publiées ?
- Quelles données d’entraînement et limitations sont documentées ?
- Quels droits de propriété s’appliquent aux sorties et adaptations ?
- Comment une demande de suppression est-elle propagée ?
- Le fournisseur accepte-t-il des audits ou fournit-il des rapports indépendants ?
- Quelles limites de disponibilité, latence et capacité sont contractuelles ?
- Comment les abus et demandes gouvernementales sont-ils traités ?
- Quels actifs peuvent être exportés, dans quels formats et à quel coût ?
- Quelle assistance est prévue pour la migration ?
- Quel est le mode dégradé si le service s’arrête demain ?
Les réponses sont notées avec les pièces contractuelles. Une réponse orale peut guider la discussion, mais elle ne constitue pas une garantie.
9. Tableau de bord du comité IA
Un comité utile suit peu d’indicateurs, mais les relie à des décisions.
- couverture de l’inventaire et systèmes sans propriétaire ;
- répartition par niveau de risque et exceptions expirées ;
- taux de systèmes avec évaluation récente ;
- erreurs critiques, quasi-incidents et délai de correction ;
- actions autonomes, confirmations et refus ;
- taux de collaborateurs formés selon leur rôle ;
- concentration des coûts par fournisseur ;
- pourcentage d’actifs exportables et dernier test de sortie ;
- valeur métier mesurée et usages sans bénéfice démontré.
Le comité ne relit pas toutes les fiches. Il arbitre les exceptions, les risques résiduels, les investissements communs et les arrêts. Les propriétaires de produit restent responsables du quotidien.
10. Plan d’action en 90 jours
Jours 1 à 15 — Rendre visible. Lancer l’inventaire, ouvrir un canal de déclaration, recenser contrats et outils, nommer les propriétaires. Bloquer seulement les usages manifestement dangereux.
Jours 16 à 30 — Classer. Définir les quatre niveaux internes, qualifier les données, identifier les systèmes potentiellement concernés par l’AI Act et prioriser les dix usages les plus exposés.
Jours 31 à 50 — Contrôler. Mettre en place l’accès, la journalisation, les évaluations minimales, les règles de conservation et le processus d’incident. Séparer lecture, préparation et exécution.
Jours 51 à 70 — Prouver. Constituer les dossiers de preuves, tester les fournisseurs, réaliser un exercice d’injection et un arrêt contrôlé. Corriger les écarts qui empêchent la maîtrise.
Jours 71 à 90 — Pérenniser. Former par rôle, installer le tableau de bord, dater les exceptions et planifier un test de réversibilité. Le comité prend ses premières décisions de poursuite, limitation ou arrêt.
Le résultat attendu n’est pas « conformité terminée ». C’est une capacité récurrente à savoir, décider, démontrer et corriger.
11. Le contrôle en dix minutes
Prenez un système. Nommez son propriétaire. Montrez sa finalité. Ouvrez son évaluation. Retrouvez sa version. Identifiez ses données. Coupez un outil. Révoquez un accès. Exportez ses actifs. Expliquez enfin une erreur récente.
Chaque réponse doit pointer vers une preuve actuelle, et non vers le souvenir d’une réunion. Si trois maillons manquent, l’organisation possède peut-être de bons principes mais pas encore une maîtrise opérationnelle complète, car une gouvernance ne devient crédible que lorsque les équipes savent exécuter rapidement ces gestes sous contrainte, pendant un incident ou face à une demande externe.
12. Questions fréquentes
12.1. Une entreprise qui utilise une API est-elle concernée par l’AI Act ?
Potentiellement oui. Son rôle et ses obligations dépendent du système, de l’usage et de la chaîne de valeur. Être client d’un fournisseur ne supprime pas les responsabilités du déployeur. Une qualification juridique au cas par cas reste nécessaire.
12.2. Peut-on interdire les outils publics et régler le shadow AI ?
L’interdiction réduit certains usages, mais ne crée pas d’alternative ni de visibilité. Une démarche efficace combine outils autorisés, règles compréhensibles, sensibilisation, contrôles techniques proportionnés et déclaration sans friction.
12.3. La certification du fournisseur suffit-elle ?
Non. Il faut vérifier son périmètre, sa date et sa correspondance avec le service. Une certification de sécurité ne prouve pas la qualité métier, l’absence de biais ou la conformité de l’usage réalisé par le client.
12.4. Comment gouverner un modèle qui change sans prévenir ?
Contractualiser les notifications lorsque possible, surveiller les versions et exécuter des tests sentinelles. Pour un cas critique, utiliser une version contrôlée ou prévoir un arrêt si le comportement sort des seuils.
12.5. Quel est le premier livrable ?
Un inventaire exploitable avec un propriétaire, une finalité et un niveau de risque. Sans lui, les politiques et formations restent abstraites.
13. Ce que Logiks recommande
Ne cherchez pas d’abord la politique parfaite. Rendez les systèmes visibles, reliez chaque usage à un propriétaire et à une preuve, puis proportionnez les contrôles à l’impact et à l’autonomie. La sécurité limite le rayon d’action. La souveraineté se démontre par la capacité à interrompre, restaurer et remplacer. La conformité devient alors un produit du pilotage, pas un dossier séparé.
14. Sources principales
- Commission européenne, cadre réglementaire de l’IA et calendrier, consulté le 13 juillet 2026 : https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai
- EUR-Lex, règlement (UE) 2024/1689 : https://eur-lex.europa.eu/eli/reg/2024/1689/oj
- CNIL, recommandations pour le développement des systèmes d’IA : https://www.cnil.fr/fr/developpement-des-systemes-dia-les-recommandations-de-la-cnil-pour-respecter-le-rgpd
- Eurostat, usage de l’IA dans les entreprises en 2025 : https://ec.europa.eu/eurostat/web/products-eurostat-news/w/ddn-20251211-2
- Insee, Utilisation de l’intelligence artificielle par les entreprises en 2024 : https://www.insee.fr/fr/statistiques/8616837
- France Num, Baromètre France Num 2025 : https://www.francenum.gouv.fr/guides-et-conseils/strategie-numerique/comprendre-le-numerique/barometre-france-num-2025-le
- Stanford Institute for Human-Centered AI, AI Index Report 2026, Responsible AI : https://hai.stanford.edu/ai-index/2026-ai-index-report/responsible-ai
- NIST, Strengthening AI Agent Hijacking Evaluations : https://www.nist.gov/news-events/news/2025/01/technical-blog-strengthening-ai-agent-hijacking-evaluations
- NIST, AI Risk Management Framework : https://airc.nist.gov/airmf-resources/airmf/5-sec-core/
- OWASP, Top 10 for Agentic Applications : https://genai.owasp.org/2025/12/09/owasp-top-10-for-agentic-applications-the-benchmark-for-agentic-security-in-the-age-of-autonomous-ai/