Depuis la démocratisation des LLM en entreprise fin 2022, la question de la gouvernance de l'IA interne s'est déplacée du laboratoire de la DSI vers l'ordre du jour des comités exécutifs. Selon l'étude McKinsey State of AI 2024, plus de 70 % des organisations déclarent avoir lancé au moins un projet d'IA générative, mais Gartner estimait dans son Hype Cycle 2024 qu'une part significative de ces projets — souvent citée entre 60 et 70 % — restait bloquée au stade pilote, faute de cadre opérationnel clair.

Le problème n'est presque jamais technique. Les modèles fonctionnent, les API répondent, les POC démontrent des gains. Ce qui manque, c'est la gouvernance : qui autorise quel usage, sur quelles données, avec quelle traçabilité, et quelle responsabilité en cas d'erreur ? La DSI se retrouve en première ligne, sommée d'arbitrer entre la pression métier — qui veut aller vite — et un cadre réglementaire européen qui, avec le règlement (UE) 2024/1689 (AI Act), impose désormais des obligations mesurables et échelonnées jusqu'en 2027.

Cette FAQ s'adresse aux DSI, RSSI, DPO et directions métier qui construisent un cadre de gouvernance de l'IA interne, aux dirigeants de PME et ETI qui veulent structurer les usages sans tuer l'innovation, et aux responsables de programme IA qui doivent aligner leurs process sur les exigences 2026. Nous y traitons sept questions récurrentes, avec la nuance d'un praticien plutôt qu'avec l'enthousiasme d'un vendeur.

Q1 : Qu'entend-on exactement par gouvernance de l'IA interne côté DSI ?

La formule ia interne dsi gouvernance process recouvre trois périmètres distincts qu'il faut clarifier avant tout arbitrage. Le premier est le périmètre organisationnel : qui, dans l'entreprise, a le droit de décider qu'un cas d'usage IA sort du bac à sable et passe en production ? Le deuxième est le périmètre données : quelles catégories de documents, quelles bases, quels flux peuvent être exposés à un modèle, et à quel modèle précisément ? Le troisième est le périmètre technique : quelles briques (LLM, vector store, connecteurs, journalisation) sont validées, versionnées, monitorées, et selon quels critères.

Une gouvernance IA opérationnelle n'est pas un document PDF de quarante pages voté en comité RSE puis rangé dans un SharePoint. C'est un ensemble de procédures ancrées dans la vie quotidienne de la DSI : circuit de qualification d'un nouveau cas d'usage, revue de conformité RGPD avant toute mise en production, matrice de responsabilité entre métier, DSI, DPO et juridique, plan de journalisation des interactions, procédure de retrait en cas d'incident.

La difficulté, régulièrement remontée dans le baromètre du Cesin, tient au fait que la plupart des entreprises françaises abordent le sujet par le bas — un chatbot ici, un assistant support là — avant de découvrir qu'elles ont douze usages IA non recensés dispersés dans les métiers. La reconstruction a posteriori d'un cadre cohérent coûte alors bien plus cher, en temps DSI et en négociation avec les métiers, que la structuration en amont d'un cadre léger mais explicite.

Q2 : Quels process doit-on encadrer en priorité ?

Toutes les interactions avec un modèle de langage ne présentent pas le même niveau de risque, et vouloir tout encadrer avec la même intensité conduit à un blocage général. Une hiérarchisation par criticité s'impose. La grille suivante, éprouvée sur le terrain, donne un ordre de priorité raisonnable pour un cadre d'ia interne dsi gouvernance process.

Cette hiérarchie détermine le niveau de garde-fous : validation humaine obligatoire, journalisation exhaustive, revue trimestrielle, ou simple règle d'usage documentée. Sur les process à risque faible, il n'est pas nécessaire d'imposer un comité d'approbation ; sur les process à risque élevé, aucune économie de procédure ne peut être justifiée.

Pour les cas d'usage métier tels que la génération de fiches produit, la relance panier ou l'analyse de tickets support, il existe désormais des solutions packagées qui intègrent les garde-fous de base. À titre d'exemple, l'agent Nina, agent IA support client Praxia traite le premier niveau avec un ton humain et laisse la décision finale aux équipes lorsque le cas dépasse un seuil de complexité paramétré.

Q3 : Comment structurer un comité de gouvernance IA efficace ?

Un comité de gouvernance IA qui fonctionne réunit rarement plus de sept personnes. Au-delà, l'agenda se dilue, les décisions s'enlisent et les métiers perdent confiance dans sa capacité à trancher. La composition type observée dans les ETI françaises rassemble : le DSI (ou un délégué), le DPO, un référent RSSI, un représentant juridique, un sponsor métier — souvent tournant selon le cas d'usage examiné — et un chef de projet IA opérationnel qui prépare les dossiers.

Le rythme de réunion importe autant que la composition. Un comité mensuel qui examine trois à cinq dossiers de cas d'usage est structurellement plus efficace qu'un comité trimestriel qui doit avaler quinze dossiers en trois heures. Chaque dossier présente : le cas d'usage, la donnée exposée, le modèle envisagé (LLM public, LLM européen, LLM on-premise), la volumétrie estimée, le budget, les garde-fous prévus, et le plan de retrait en cas d'incident.

Le comité ne fait pas la conception technique — c'est le rôle de la DSI et de ses équipes projet. Il valide, refuse, ou renvoie pour compléments. Sa légitimité tient à sa capacité à trancher rapidement, en donnant à chaque cas d'usage un chemin clair vers la production ou vers un abandon documenté. Une bonne pratique consiste à publier chaque décision, avec sa justification, dans un registre interne consultable par les équipes, ce qui évite que les mêmes débats reviennent dossier après dossier et donne aux futurs porteurs de projet une jurisprudence interne utile.

Q4 : Quelles règles pour l'usage des LLM publics par les collaborateurs ?

La question la plus fréquente remontée par les DSI en 2025 concerne l'usage sauvage d'outils comme ChatGPT, Claude ou Gemini par les collaborateurs. L'interdiction pure, tentée par certaines organisations en 2023, s'est révélée à la fois inefficace — le shadow IT contourne l'interdiction — et contre-productive, les équipes se privant d'un outil que la concurrence utilise ouvertement. La bonne réponse est ailleurs : une charte d'usage claire, adossée à une alternative interne acceptable.

La charte d'usage précise typiquement les catégories de données qu'un salarié n'a jamais le droit d'envoyer à un LLM public : données personnelles clients, données financières non publiées, code source propriétaire, contrats en cours de négociation, informations couvertes par le secret des affaires. Elle liste ensuite les cas d'usage tolérés (rédaction générique, traduction de contenu déjà public, aide au débogage sur du code d'apprentissage) et les cas d'usage encouragés via un outil validé (résumé de documents internes via un RAG interne, recherche documentaire dans le SharePoint via un connecteur validé, synthèse de tickets internes).

L'alternative interne compte autant que la charte. Un collaborateur à qui on demande de ne pas coller un compte-rendu client dans ChatGPT doit disposer d'un équivalent interne acceptable. C'est le rôle d'un déploiement IA structuré, qu'il s'agisse d'une plateforme on-premise sur Mistral, d'un accès Azure OpenAI en zone européenne avec DPA signé, ou d'un ensemble d'agents packagés dédiés aux tâches courantes. Sans cette alternative, la charte reste lettre morte au bout de trois mois.

Q5 : Comment gérer la traçabilité et l'auditabilité des interactions IA ?

L'auditabilité est le pivot d'une ia interne dsi gouvernance process solide. En cas de contrôle de la CNIL, de litige commercial ou d'incident interne, l'entreprise doit pouvoir répondre à trois questions : qui a lancé quelle requête, sur quelles données, avec quelle réponse produite. Sans journalisation, aucune de ces questions ne trouve de réponse.

Concrètement, la journalisation d'un système IA en production comprend au minimum : l'identifiant utilisateur (pseudonymisé si nécessaire), la date et l'heure horodatées, le contenu de la requête (ou une empreinte si la donnée est sensible), les documents source injectés dans le contexte pour un RAG, le modèle appelé et sa version, la réponse renvoyée, l'action éventuellement déclenchée en aval, et la validation humaine si elle est requise. Chacun de ces éléments doit être stocké dans un journal séparé du système applicatif pour rester exploitable en cas de rejeu.

La rétention de ces logs se négocie avec le DPO : trop courte, l'auditabilité s'effondre ; trop longue, le stock de données personnelles devient un risque en lui-même. Un horizon de six à douze mois est un compromis courant, avec anonymisation au-delà. Pour l'analyse de ces logs, un agent d'analyse de données comme Noé, agent IA analyse de données Praxia permet de produire des tableaux de bord d'usage et de détecter les dérives (pics d'appels inhabituels, requêtes atypiques, coûts inattendus) sans mobiliser un data analyst à plein temps sur ce périmètre.

Q6 : Qu'est-ce qui peut mal tourner dans une gouvernance IA mal calibrée ?

Trois échecs récurrents se rencontrent sur le terrain. Le premier est la gouvernance-forteresse : un cadre si contraignant qu'aucun cas d'usage ne passe le filtre. Résultat, les métiers contournent la DSI et utilisent des outils grand public sans encadrement. La gouvernance est morte, remplacée par du shadow IT généralisé, et le RSSI l'apprend en général six mois trop tard.

Le deuxième échec est la gouvernance-formalité : un document ratifié en comité RSE mais que personne n'applique. Les cas d'usage se multiplient sans qualification, la journalisation est inexistante, et le jour d'un incident personne ne peut retrouver ce qui s'est passé. Ce cas est le plus fréquent dans les PME qui ont pris le sujet par le haut sans moyens d'exécution alloués, et il conduit souvent à des réveils désagréables lors du premier contrôle DPO ou de la première question client sur une décision automatisée.

Le troisième échec, plus subtil, est la sur-délégation à un prestataire. La DSI signe avec un intégrateur qui promet de gérer toute la gouvernance ; six mois plus tard, l'entreprise découvre qu'elle ne sait ni comment sont journalisées les interactions, ni où sont stockées les données, ni comment récupérer la main en cas de rupture contractuelle. Le contrat n'a pas prévu de clause de réversibilité claire, et la migration devient un chantier hors budget.

Pour éviter ces écueils, la règle terrain la plus utile est de commencer petit, de documenter chaque décision, et de traiter l'ia interne dsi gouvernance process comme un livrable itératif — pas comme un projet unique à livrer en V1 définitive. Le cadre juridique lui-même bouge : les obligations de l'AI Act s'appliquent par vagues jusqu'en 2027, et la jurisprudence RGPD sur les traitements IA s'écrit en temps réel.

Q7 : Comment articuler cette gouvernance avec l'AI Act et le RGPD ?

Le règlement (UE) 2024/1689 (AI Act) et le RGPD ne se substituent pas l'un à l'autre : ils se cumulent. Le RGPD encadre le traitement des données personnelles quel que soit l'outil ; l'AI Act encadre les systèmes IA quel que soit le type de données traitées. Un système qui traite des données personnelles avec un modèle de langage relève donc des deux textes, avec un cumul d'obligations documentaires qu'il faut anticiper.

En pratique, la mise en conformité passe par une articulation de trois documents. D'abord le registre des traitements RGPD, qui doit désormais intégrer les traitements IA avec leurs finalités, leurs bases légales et leurs destinataires. Ensuite l'analyse d'impact (AIPD) pour les traitements à risque élevé, obligatoire dès qu'un système IA prend des décisions produisant des effets juridiques ou similaires sur une personne. Enfin la documentation technique exigée par l'AI Act pour les systèmes classés à risque élevé (annexe IV du règlement), qui couvre l'architecture, les données d'entraînement, les mesures de gestion du risque, et les tests de robustesse.

Pour les PME qui ne disposent pas d'un juriste dédié à temps plein, un juriste IA outillé peut préparer une première version des documents contractuels avec les prestataires (DPA, clauses IA, engagements sur les sous-traitants ultérieurs), à charge pour un avocat de valider les points délicats. L'agent Justine, juriste IA Praxia couvre notamment la rédaction de CGV et de clauses RGPD, avec renvoi explicite vers un réseau d'avocats partenaires lorsqu'un litige ou une négociation complexe l'exige.

En conclusion

La gouvernance de l'ia interne dsi gouvernance process n'est ni une case à cocher réglementaire, ni un frein à l'innovation. C'est la condition de sortie du bac à sable : le passage du POC à la mise en production ne se joue pas sur la performance du modèle, mais sur la solidité du cadre qui l'entoure.

Trois recommandations à priorité décroissante pour construire ce cadre. Premièrement, cartographier l'existant avant d'écrire la moindre règle : combien de cas d'usage IA sont déjà en cours, avec quels outils, sur quelles données, avec quel niveau de journalisation. Deuxièmement, structurer un comité mensuel de sept personnes maximum, avec pouvoir de décision et registre public de ses arbitrages. Troisièmement, imposer la journalisation dès le premier cas d'usage en production — la reconstruction a posteriori des logs est un chantier long, coûteux et parfois impossible.

Pour explorer des solutions packagées qui intègrent nativement les garde-fous de journalisation, de validation humaine et de conformité RGPD, la gamme d'agents Praxia AI propose une approche self-service adaptée aux structures qui veulent avancer sans mobiliser un intégrateur à cinq chiffres.