Cas d’usage de l’IA en entreprise : méthode pour identifier, prioriser et déployer en partant des irritants

 

En un an, la part des entreprises françaises utilisant au moins une technologie d’IA a sensiblement progressé pour atteindre 18 %, selon l’enquête TIC entreprises de l’Insee (2025). Derrière cette accélération, des disparités considérables persistent : le taux atteint 58 % dans les entreprises de 250 salariés ou plus et reste nettement plus faible dans les petites structures. Surtout, le manque d’expertise coexiste avec l’adoption — y compris chez ceux qui ont déjà franchi le pas. Ce paradoxe est précisément ce qui justifie une démarche rigoureuse : identifier ses cas d’usage IA à partir des irritants réels des équipes, prioriser avec méthode, tester à périmètre limité, puis cadrer et passer à l’échelle.

Qu’est-ce qu’un cas d’usage de l’IA, et pourquoi partir des irritants des salariés ?

Avant d’engager tout recensement, il est utile de stabiliser le vocabulaire. La notion de cas d’usage IA est souvent confondue avec celle de projet, de solution ou de catalogue technologique — des glissements qui orientent les discussions vers la technologie avant même que le besoin soit formulé.

Ce que recouvre concrètement un cas d’usage de l’IA

Un cas d’usage IA n’est ni un outil, ni une ambition technologique. C’est l’association d’une tâche précise, d’un contexte métier identifié, de données effectivement disponibles et d’un résultat attendu que l’on est en mesure de vérifier. Rédiger une synthèse à partir de notes brutes, résumer un document long, classer automatiquement des courriels entrants, vérifier la cohérence formelle d’un document : ces formulations ont en commun d’être bornées, ancrées dans une réalité opérationnelle et contrôlables par un être humain.

La distinction avec un catalogue d’outils est de nature. Un catalogue liste des possibilités techniques, le plus souvent présentées du côté de l’offre. Un cas d’usage part d’une réalité opérationnelle — la tâche pénible, la vérification chronophage, le tri répétitif que les équipes gèrent actuellement sans support adapté. La distinction avec une stratégie IA est de grain : une stratégie fixe des orientations et une gouvernance ; un cas d’usage désigne quelque chose de testable en quelques semaines, sur un périmètre limité, sans mobiliser l’ensemble de l’organisation.

Pour gérer plusieurs initiatives en parallèle sans perdre la lisibilité, il est recommandé de constituer un portefeuille de cas d’usage : une liste vivante, structurée par entrées, avec pour chacune un statut (à étudier, en test, déployé, arrêté, à réévaluer), un responsable métier identifié et une date de réexamen. Ce format évite l’accumulation de pilotes sans suite et permet d’arbitrer les priorités à intervalles réguliers. C’est aussi la structure qui rend possible une gouvernance légère, sans comité permanent, en donnant à chaque cas d’usage une traçabilité minimale.

Un cas d’usage n’est pas figé : il évolue avec les données disponibles, les contraintes réglementaires et les retours des utilisateurs. L’intégrer dans un portefeuille structuré, plutôt que dans une liste informelle, est la condition pour qu’il soit effectivement réévalué — et non maintenu par inertie ou abandonné sans bilan.

La logique « irritants d’abord » : un point de départ recommandé par la CNIL

Partir des irritants, c’est inverser l’ordre habituel. Au lieu de lister les possibilités offertes par les outils disponibles pour ensuite chercher à les placer dans l’organisation, on commence par recenser ce qui pose problème : les tâches pénibles, répétitives, chronophages ou sources d’erreurs identifiées par les salariés et leurs managers de proximité. La technologie arrive en second, une fois le besoin formulé avec précision.

Cette logique n’est pas seulement pragmatique. Dans sa recommandation du 18 juillet 2024 sur le déploiement d’une IA générative, la CNIL préconise explicitement de partir d’un besoin concret avant toute autre étape. Elle recommande également d’établir une liste d’usages autorisés et interdits selon les risques, d’associer dès le départ le DPO, le RSSI et les responsables métiers, et de former les utilisateurs finaux — y compris sur les risques inhérents aux usages autorisés. L’encadrement des données personnelles et des droits des salariés fait partie intégrante de cette démarche ; notre article sur la charte d’usage IA et la protection des données en détaille les implications concrètes.

Sur le plan organisationnel, l’approche bottom-up présente trois avantages distincts. Elle associe les salariés dès la phase d’identification, ce qui réduit les résistances à l’adoption ultérieure. Elle produit des cas d’usage directement utiles aux équipes concernées, plutôt que des démonstrations de faisabilité technique sans ancrage terrain. Elle facilite enfin le cadrage réglementaire : lorsqu’on sait précisément quelle tâche est concernée, quelles données sont manipulées et qui valide le résultat, l’analyse des risques liés aux données personnelles et la question de la validation humaine peuvent être traitées dès le départ — et non découvertes lors du déploiement.

Où en sont les entreprises françaises sur les cas d’usage de l’IA en 2025 ?

Les données disponibles permettent de dépasser les discours sur l’enthousiasme ou la frilosité supposés des entreprises françaises. L’enquête TIC entreprises de l’INSEE offre un état des lieux précis, qui nuance la dynamique d’ensemble.

Adoption, écarts selon la taille et freins persistants

18 % des entreprises françaises de 10 salariés ou plus utilisaient au moins une technologie d’IA en 2025, selon l’INSEE (Insee Première n° 2120). C’est huit points de plus qu’en 2024, et le taux a été multiplié par trois depuis 2023. La moyenne européenne s’établit à 20 %, situant la France légèrement en deçà de ses voisins, mais dans une dynamique comparable.

Les disparités selon la taille restent considérables. Le taux atteint 58 % dans les entreprises de 250 salariés ou plus, tandis que l’INSEE le décrit comme nettement plus faible dans les petites structures. Pour une PME, cette réalité a une implication directe : une démarche progressive, fondée sur des irritants précis et des pilotes à périmètre restreint, est structurellement plus adaptée qu’un programme global calqué sur les pratiques des grandes organisations.

Du côté des freins, le plus souvent cité parmi les entreprises non utilisatrices est l’absence d’utilité perçue : 71 % déclarent ne pas voir l’intérêt de recourir à l’IA. Ce chiffre mérite attention : il ne signifie pas nécessairement une hostilité à la technologie, mais pointe vers un déficit de formulation des besoins. Lorsque les cas d’usage proposés restent abstraits ou génériques, l’utilité concrète n’apparaît pas. C’est précisément ce que la démarche « irritants d’abord » cherche à corriger. Le manque d’expertise est cité par 54 % des non-utilisateurs.

Ce qui est analytiquement plus notable, c’est que ce déficit d’expertise touche également les entreprises qui ont déjà adopté l’IA : 53 % des utilisateurs le citent comme frein persistant. Adoption et maîtrise avancent donc à des rythmes différents. Ce décalage est précisément ce qui légitime une méthode rigoureuse : sans cadre pour identifier, qualifier et tester les cas d’usage IA, le risque est de déployer des outils dont les équipes ne savent pas encore se servir efficacement, ni de manière sécurisée. La formation, l’appui du DPO et du RSSI, et la capitalisation sur les retours des utilisateurs doivent accompagner tout le cycle du cas d’usage — pas seulement son lancement.

Comment recenser les irritants : questionnaire, ateliers et fiche d’irritant

Recenser les irritants ne se résume pas à diffuser un sondage. La méthode combine trois outils complémentaires — un questionnaire court, des ateliers par équipe et une fiche d’irritant standardisée — dont la valeur tient autant à leur séquençage qu’à leur contenu. L’enjeu est de recueillir des symptômes opérationnels, pas des prescriptions technologiques.

Le questionnaire court : sept questions pour identifier les tâches qui posent problème

La première étape est un questionnaire court, diffusé à toutes les équipes sans exception. Son objectif n’est pas de savoir quels outils d’IA les salariés souhaiteraient utiliser — cette question produirait des prescriptions technologiques prématurées. Il s’agit de recueillir des symptômes : les tâches qui posent problème, le moment où elles surviennent, les conséquences concrètes des erreurs ou des reprises.

Sept questions structurent ce recueil :

1. Quelle tâche vous pose régulièrement problème ou vous prend un temps disproportionné ?
2. À quel moment de votre activité cette tâche se présente-t-elle ?
3. À quelle fréquence — quotidienne, hebdomadaire, mensuelle ?
4. Quelles informations utilisez-vous pour la réaliser (documents, bases de données, échanges écrits) ?
5. Quelles erreurs ou reprises surviennent, et pour quelles raisons ?
6. Quel résultat vous serait utile — un brouillon, un tri, un résumé, une alerte ?
7. Qui doit valider ce résultat avant qu’il soit utilisé ?

La septième question est souvent négligée. Elle est pourtant déterminante : elle révèle d’emblée si le cas d’usage impliquera une décision humaine formelle, ce qui conditionne à la fois le cadrage réglementaire et la conception du test. Il est essentiel d’inclure aussi les fonctions peu numérisées — logistique, comptabilité, terrain, RH opérationnel : elles ont leurs propres tâches pénibles, que le questionnaire doit faire remonter.

L’atelier par équipe : faire émerger les irritants collectifs

Le questionnaire individuel laisse une part de la réalité dans l’ombre. Certaines tâches problématiques ne sont pas formulées spontanément parce qu’elles semblent anodines, parce qu’elles sont partagées entre plusieurs personnes sans qu’aucune en soit clairement responsable, ou parce qu’elles ne font pas l’objet d’une demande explicite. L’atelier par équipe vient compléter ce recueil en faisant émerger les irritants collectifs que le questionnaire individuel ne capte pas.

Le format recommandé est restreint : un groupe limité à une même équipe ou une même famille de tâches, une durée d’une à deux heures, un animateur interne ou RH dont le rôle est d’écouter et de reformuler, non de proposer des solutions. Les managers de proximité jouent un rôle clé : ils connaissent les tâches dont la charge réelle est sous-estimée dans les questionnaires individuels, et leur participation ancre les résultats dans la réalité opérationnelle.

La complémentarité des deux formats est réelle. Le questionnaire produit une vue large sur l’ensemble des équipes ; l’atelier approfondit les cas complexes et permet de préciser des besoins formulés de manière trop générale. Il n’est pas nécessaire de recourir à une méthode propriétaire ou à un prestataire externe : la valeur vient de la qualité de l’écoute et de la rigueur du recueil, non de la sophistication de l’outillage.

La fiche d’irritant : un format standard pour documenter chaque cas

Chaque irritant identifié — qu’il provienne du questionnaire ou de l’atelier — doit faire l’objet d’une fiche standardisée. Sans ce format commun, les cas ne peuvent pas être comparés ni priorisés : des descriptions textuelles libres produisent des entrées hétérogènes, impossibles à traiter collectivement lors de la phase d’arbitrage.

La fiche d’irritant comprend neuf champs :

• Métier concerné : fonction et équipe, sans identifier un individu
• Description de la tâche : en une phrase concrète, sans jargon interne
• Fréquence : quotidienne, hebdomadaire, mensuelle ou ponctuelle
• Temps actuellement consacré : documenté tel quel, sans le convertir en promesse de gain
• Données manipulées : nature des informations traitées (documents internes, données clients, données RH, etc.)
• Personnes concernées : nombre et profil des salariés impliqués
• Résultat attendu : ce que devrait produire ou faciliter une solution
• Conséquences possibles d’une erreur : pour le salarié, le client ou l’entreprise
• Validation humaine nécessaire : qui, à quelle étape, selon quel critère

Ce format standardisé remplit deux fonctions. Il permet la comparaison objective entre cas lors de la phase de priorisation — sans lui, les arbitrages reposent sur la visibilité de ceux qui portent le cas plutôt que sur sa pertinence réelle. Il alimente aussi directement le portefeuille de cas d’usage : chaque fiche devient une entrée dans la liste vivante, avec un statut initial « à étudier » et une date de première revue. C’est à ce stade que les cas d’usage IA passent du recueil informel à un processus structuré, comparable et gouvernable.

Prioriser les cas d’usage de l’IA : une grille en cinq critères

Recenser les irritants est une première étape ; arbitrer entre eux en est une autre. Sans méthode commune, les arbitrages se font sur la visibilité des porteurs de cas, la réactivité des équipes techniques ou l’écho médiatique d’une solution — rarement sur la pertinence réelle. La grille présentée ici est une proposition éditoriale de la rédaction, sans valeur normative. Elle peut être adaptée librement. Son utilité principale tient à la comparabilité qu’elle introduit entre des cas de nature très différente.

Les cinq critères de la grille de priorisation

La grille repose sur cinq critères, chacun noté de 1 à 3. Il n’existe pas de pondération imposée entre eux : certains contextes justifieront de traiter la sensibilité des données comme un filtre éliminatoire avant même de calculer un score global. Ce qui importe, c’est la justification écrite associée à chaque note. En séance d’arbitrage, c’est l’argumentation qui emporte la décision — non le chiffre.

Bénéfice pour le salarié. Ce critère évalue le gain concret attendu sur une tâche perçue comme pénible, répétitive ou chronophage. L’IA réduit-elle une ressaisie ? Simplifie-t-elle l’accès à une information dispersée ? Améliore-t-elle la préparation d’une tâche ou facilite-t-elle un contrôle de cohérence ? Le gain reste qualitatif à ce stade : toute quantification avant expérimentation relève de la projection, non de la mesure.

Fréquence de la tâche. Plus une tâche est fréquente, plus le bénéfice s’accumule et justifie l’effort de mise en œuvre. Une tâche quotidienne ou pluriquotidienne génère un rendement bien supérieur à une tâche mensuelle, à bénéfice unitaire équivalent.

Faisabilité technique. Ce critère regroupe plusieurs dimensions : disponibilité et qualité des données nécessaires, compatibilité avec les outils et systèmes existants, complexité d’intégration, compétences requises, niveau de sécurité à mettre en place et capacité à tester sur un périmètre limité avant toute généralisation. La question du niveau de contrôle humain est centrale ici — pilote, copilote ou autopilote — car elle conditionne à la fois la sécurité du test et son acceptabilité par les équipes. Cette méthode est présentée en détail dans un article dédié de la rédaction.

Sensibilité des données. La nature des informations manipulées dans le périmètre de la tâche détermine l’ensemble du cadrage juridique. Données personnelles au sens du RGPD, données médicales, financières ou confidentielles : il convient d’identifier leur catégorie, de vérifier les conditions contractuelles du prestataire, les modalités d’hébergement, les droits d’accès, les durées de conservation et les éventuels transferts hors Union européenne.

Risque d’erreur. Les conséquences d’une erreur ou d’une hallucination de l’IA peuvent aller de la simple gêne opérationnelle — un compte rendu inexact que le salarié corrige en quelques minutes — à l’atteinte aux droits d’une personne. Plus les conséquences sont sérieuses, plus la validation humaine doit être renforcée, documentée et non contournable dans le processus.

Critère	Ce qu’il mesure	Notation (1 = faible · 3 = élevé)	Signal d’alerte
Bénéfice pour le salarié	Gain concret sur une tâche pénible, répétitive ou chronophage	1 = gain marginal / 2 = gain notable / 3 = gain important	Score < 2 : cas à reporter ou à écarter
Fréquence de la tâche	Nombre de fois que la tâche est réalisée par semaine ou par mois	1 = rare / 2 = hebdomadaire / 3 = quotidienne ou pluriquotidienne	Score < 2 : retour sur investissement limité
Faisabilité technique	Disponibilité des données, compatibilité avec les outils existants, complexité d’intégration	1 = complexe / 2 = faisable avec accompagnement / 3 = simple et immédiate	Score 1 : risque de pilote coûteux et décourageant
Sensibilité des données	Présence de données personnelles, médicales, financières ou confidentielles dans le périmètre de la tâche	1 = très sensibles / 2 = partiellement sensibles / 3 = non sensibles	Score 1 ou 2 : AIPD à envisager, avis du DPO à solliciter avant tout test
Risque d’erreur	Conséquences d’une erreur ou d’une hallucination sur le salarié, le client ou l’entreprise	1 = conséquences graves / 2 = limitées et corrigeables / 3 = négligeables	Score 1 : décision humaine obligatoire, l’IA ne doit pas décider seule

Repérer les cas à tester en priorité

Le profil type d’un cas d’usage IA prioritaire combine plusieurs conditions favorables : tâche fréquente, bénéfice identifiable pour le salarié directement concerné, données non sensibles ou facilement anonymisables, risque d’erreur limité à une reprise manuelle, intégrable sans refonte du processus existant. Ce profil ne garantit pas le succès — il réduit le risque d’un premier test coûteux ou décourageant.

La notion de gain rapide mérite d’être précisée pour éviter les malentendus. Elle ne désigne pas des gains spectaculaires : elle désigne des cas où la charge de mise en œuvre est faible et l’irritant fort au quotidien. Rédiger un premier jet de compte rendu à partir d’une transcription, standardiser une réponse à une question récurrente, préparer une synthèse à partir de notes éparses — ces usages peuvent être testés rapidement, sur un périmètre limité, sans mobiliser une infrastructure lourde. Leur valeur tient à leur récurrence et à leur intégration naturelle dans le travail réel, non à leur caractère innovant.

La distinction avec les cas nécessitant un cadrage approfondi préalable est nette. Dès qu’un cas d’usage implique des données personnelles non anonymisées, une validation humaine critique ou un impact sur des décisions individuelles concernant un salarié, l’expérimentation ne peut pas être lancée à titre informel. Le manque d’expertise est fréquemment cité par les entreprises utilisatrices dans l’enquête TIC 2025 de l’Insee. Un DPO, un RSSI et les responsables métiers concernés doivent être associés dès l’étape de qualification, non en aval d’un test déjà lancé.

Les cas d’usage à écarter ou à traiter avec des garde-fous renforcés

La grille de priorisation permet aussi d’identifier les cas d’usage IA qui ne devraient pas être lancés sans conditions particulières — voire pas du tout dans leur configuration initiale. Cette section ne dresse pas une liste exhaustive d’interdits absolus : les situations varient selon les contextes, et la charte d’usage interne ainsi que les recommandations de la CNIL constituent les références opérationnelles premières. Les implications réglementaires sont détaillées dans l’article de la rédaction sur IA et RGPD pour l’employeur et les salariés.

Première catégorie à conditionner fortement : les cas dans lesquels l’IA déciderait seule d’une mesure concernant un salarié. Notation automatisée, affectation, décision disciplinaire, refus de recrutement sans intervention humaine réelle — ces usages vont à l’encontre de la recommandation de la CNIL, qui cite en exemple d’usage à interdire le fait de confier une décision au système, et peuvent relever des règles du RGPD sur les décisions fondées uniquement sur un traitement automatisé (article 22), à apprécier au cas par cas. La règle opérationnelle est simple : l’IA prépare et propose, l’humain décide et documente.

Deuxième catégorie : les cas impliquant des données sensibles — médicales, financières, relatives à la vie privée — sans garanties contractuelles vérifiées auprès du prestataire. La CNIL cite parmi les exemples d’usages à interdire, selon les risques, le fait de fournir des données personnelles au système, et recommande de vérifier si le prestataire peut réutiliser les données fournies. Selon le niveau de risque, une analyse d’impact relative à la protection des données (AIPD) peut s’imposer : le DPO aide à l’apprécier.

Troisième catégorie : les cas où une erreur ou une hallucination aurait des conséquences directes sur les droits d’une personne — salaire incorrect, exclusion d’un processus de promotion, communication erronée à un organisme public ou à un prestataire. Ces cas ne sont pas systématiquement à exclure, mais ils requièrent une validation humaine explicite à chaque étape critique, une traçabilité documentée et un dispositif de correction accessible à toute personne concernée.

Tester un cas d’usage de l’IA à périmètre limité avant de généraliser

Le pilote n’est pas une démonstration à réussir. C’est un dispositif de connaissance : il vise à produire les données sur lesquelles fonder une décision d’arrêt ou d’extension. Cette nuance change la manière de le conduire. Un pilote bien cadré commence toujours par la définition d’un indicateur de succès — avant même d’installer l’outil —, s’inscrit dans un périmètre délibérément limité et prévoit dès le cadrage les conditions dans lesquelles l’expérimentation sera arrêtée.

Définir l’indicateur de succès et les critères d’arrêt avant de démarrer

Définir l’indicateur après le test revient à ouvrir la voie au biais de confirmation : les équipes retiennent ce qui va dans le sens attendu et minimisent ce qui le contredit. L’indicateur doit être fixé avant toute mise en œuvre, directement relié à l’irritant d’origine et mesurable sans effort interprétatif excessif.

Les indicateurs les plus utiles en contexte RH ou administratif incluent : le taux de résultats acceptés sans reprise après contrôle humain, le nombre moyen de reprises nécessaires avant validation, la satisfaction déclarée des utilisateurs sur la tâche concernée, la qualité documentaire évaluée par un référent métier et la diminution des erreurs observées sur un échantillon comparable.

Les critères d’arrêt doivent être définis avec la même rigueur, au moment du cadrage, non rétrospectivement. Cinq situations justifient d’interrompre le pilote : qualité insuffisante après un nombre de reprises prédéfini ; erreurs difficiles à détecter sans expertise spécifique ; absence d’utilité réelle perçue par les utilisateurs directs ; données disponibles inadéquates ou insuffisamment structurées ; risque juridique ou de sécurité non maîtrisé révélé en cours de test. Un pilote arrêté n’est pas un échec à dissimuler : il produit des données capitalisables sur les limites de l’outil et les conditions réelles d’utilisation, aussi précieuses pour les décisions futures que les pilotes concluants.

En additionnant les cinq notes de la grille de priorisation, un score total entre 12 et 15 signale un cas d’usage à tester en priorité. Entre 8 et 11, le cas mérite une étude plus approfondie — notamment sur les critères inférieurs à 2. En dessous de 8, les conditions ne sont pas réunies : soit l’irritant est insuffisant pour justifier un investissement, soit les contraintes techniques ou juridiques imposent un travail préalable.

Le périmètre du pilote doit être délibérément restreint : une équipe, un site, un type de document. Ce resserrement n’est pas un compromis provisoire, c’est une condition de validité du test. Sur un périmètre large, les variables se multiplient, les comparaisons deviennent difficiles et la décision finale s’appuie sur des données hétérogènes. Un pilote limité produit des résultats attribuables à l’outil plutôt qu’à des facteurs organisationnels diffus.

La collecte structurée des retours utilisateurs constitue la matière première de la décision finale. Un questionnaire court, passé à mi-parcours, permet d’identifier les difficultés d’appropriation, les cas limites non anticipés et les usages émergents que le cahier des charges n’avait pas prévus. Les retours qualitatifs ont ici autant de valeur que les indicateurs quantitatifs : ils éclairent les conditions réelles d’usage là où les chiffres n’indiquent que les résultats.

À l’issue du pilote, la décision d’arrêt ou d’extension doit être collégiale : direction, RH, responsables métiers et RSSI. Cette collégialité garantit que la décision intègre simultanément les dimensions technique, organisationnelle et de sécurité. Si les critères d’arrêt définis au départ sont atteints, la décision s’impose. Si les résultats sont mitigés, la délibération porte sur les conditions d’une extension partielle ou d’un recadrage du périmètre du cas d’usage.

Cadrer l’usage de l’IA : données personnelles, gouvernance et consultation du CSE

Déployer un outil d’IA sans cadre formel n’est pas seulement un risque juridique. C’est une source de confusion opérationnelle qui finit par éroder la confiance des utilisateurs et compliquer les arbitrages futurs. Le cadrage recouvre trois dimensions indissociables : la conformité au regard du droit des données personnelles, la gouvernance interne, et les obligations d’information ou de consultation des représentants du personnel. Les traiter en parallèle plutôt qu’en séquence évite de découvrir un blocage après le déploiement.

Ce que recommande la CNIL : gouvernance, données et formation des utilisateurs

Dans ses recommandations du 18 juillet 2024 sur le déploiement d’une IA générative, la CNIL formule une série de préconisations opérationnelles. Il est important de les présenter pour ce qu’elles sont : des recommandations, non des obligations légales autonomes. Leur valeur pratique n’en est pas moins réelle, notamment parce qu’elles articulent des principes du RGPD dans le contexte spécifique des systèmes d’IA.

Première préconisation : partir d’un besoin concret et dresser une liste d’usages autorisés et interdits selon les risques. Cette liste, construite en tenant compte du contexte métier, des données manipulées et des effets possibles des erreurs, constitue le socle de la charte d’usage interne. Elle précède l’installation de tout outil.

Deuxième préconisation : encadrer les usages à risque, la CNIL citant en exemple l’interdiction de fournir des données personnelles au système ou de lui confier une décision. La CNIL rappelle également que les systèmes d’IA générative peuvent produire des résultats inexacts d’apparence plausible. Cette information doit figurer dans la formation des utilisateurs — pas dans une note de bas de page contractuelle que personne ne lit avant qu’un incident survienne.

Troisième préconisation : si un prestataire est impliqué, vérifier s’il peut réutiliser les données fournies. Cette vérification se fait dans le contrat ou les conditions du prestataire, avant tout usage avec des données de l’entreprise.

Sur la gouvernance, la CNIL préconise d’associer dès le départ le DPO, les responsables des systèmes d’information et de la sécurité (RSSI) ainsi que les responsables métiers. Associer le DPO avant le premier test évite de devoir corriger des pratiques déjà installées. Pour une mise en perspective du cadre réglementaire dans lequel s’inscrit l’usage de l’IA en entreprise, la rédaction a publié une analyse approfondie du cadre réglementaire applicable aux entreprises et à leurs équipes RH.

La formation des utilisateurs est sans doute la préconisation la plus sous-estimée. Elle doit être adaptée au cas d’usage et au métier — pas une présentation générale de l’IA. Quatre points doivent être couverts : les usages interdits dans le contexte de l’entreprise ; les risques des usages autorisés, notamment la plausibilité des erreurs ; les méthodes de vérification des résultats produits ; les modalités de signalement d’un incident ou d’un doute.

La charte ou règles internes d’usage formalise ces éléments dans un document de référence. Elle précise les usages autorisés et interdits, les catégories de données à ne pas saisir sans cadre validé, les outils autorisés par l’entreprise, les responsabilités en cas d’erreur et les procédures de signalement. Ce document n’est pas un texte de communication interne : c’est un outil de gouvernance opérationnelle, destiné à évoluer à mesure que les pratiques changent et que le portefeuille de cas d’usage s’élargit.

Information et consultation du CSE : ce que dit le code du travail

Le Code du travail fixe le seuil d’existence du CSE : il est mis en place dans les entreprises d’au moins 11 salariés dès lors que cet effectif est atteint pendant la durée prévue par les textes. Ce seuil ne doit pas être confondu avec les attributions renforcées applicables dans les entreprises d’au moins 50 salariés, qui ouvrent un périmètre de compétences sensiblement plus étendu.

Dans ces entreprises d’au moins 50 salariés, l’article L2312-8 II 4° prévoit que le CSE est informé et consulté sur les questions intéressant l’organisation, la gestion et la marche générale de l’entreprise, notamment l’introduction de nouvelles technologies et tout aménagement important modifiant les conditions de santé, de sécurité ou de travail. Le déploiement d’un outil d’IA peut relever de cette disposition selon ses caractéristiques et ses effets concrets sur les conditions de travail des salariés concernés.

Ce « peut » mérite d’être pesé. Des décisions de première instance ont qualifié des outils d’IA de nouvelle technologie au sens de cette disposition, mais l’étendue exacte de l’obligation — selon la nature de l’outil, son périmètre d’utilisation et ses effets sur l’organisation du travail — reste débattue. La démarche recommandée est d’associer le CSE en amont du déploiement et de consulter un juriste en cas de doute sur l’obligation de consultation formelle.

Informer le CSE sans le consulter formellement expose à un désaccord ultérieur sur la qualification retenue : l’associer en amont est à la fois une précaution et un facteur d’appropriation collective.

Le contenu de l’information utile au CSE doit couvrir au minimum : l’objectif du déploiement et les tâches concernées, les données manipulées par l’outil, les effets attendus sur l’organisation du travail, et les contrôles humains prévus sur les résultats produits par l’IA. Cette information permet aux représentants du personnel d’exercer leur rôle de manière éclairée ; elle facilite aussi, dans les faits, l’appropriation de l’outil par les salariés directement concernés.

Passer à l’échelle : partager les retours, former et réévaluer le portefeuille de cas d’usage

L’extension d’un pilote concluant n’est pas automatique. Elle suppose un examen explicite des résultats au regard de l’indicateur défini au départ, la formalisation du processus de traitement, la sécurisation des données dans le nouveau périmètre, la formation des nouvelles équipes concernées, la définition d’un dispositif de support et la clarification des responsabilités en cas d’erreur. Chacun de ces points peut sembler secondaire pris isolément ; ensemble, ils déterminent si le déploiement élargi sera maîtrisé ou subi.

Le partage interne des retours est l’une des étapes les moins formalisées dans les organisations, et l’une des plus structurantes pour la suite. Les ateliers de retour d’expérience dans lesquels les équipes ayant conduit le pilote présentent à la fois les résultats positifs et les limites rencontrées permettent aux autres équipes de calibrer leurs propres attentes et d’éviter de reproduire les mêmes erreurs. La capitalisation sur les pilotes arrêtés est au moins aussi utile que la diffusion des réussites. Partager ce qui n’a pas fonctionné, et pourquoi, est un acte de gouvernance — pas un aveu de faiblesse.

Le manque d’expertise demeure un frein persistant, y compris après l’adoption. L’enquête TIC de l’Insee montre que 53 % des entreprises utilisatrices citent le manque d’expertise parmi leurs freins — chiffre quasi identique à celui des non-utilisateurs (54 %). Cela confirme que la formation n’est pas un sujet à traiter une seule fois au lancement : elle doit accompagner chaque extension du périmètre, chaque évolution de l’outil et chaque arrivée de nouveaux utilisateurs dans le périmètre déployé.

La mise à jour périodique du portefeuille de cas d’usage est la discipline la moins visible, et l’une des plus importantes pour la durabilité de la démarche. Chaque cas d’usage doit disposer d’un statut actualisé : à étudier, en pilote, déployé, arrêté, à réévaluer. Un cas d’usage déployé il y a un an peut avoir évolué — l’outil a changé de version, le cadre réglementaire a bougé, les pratiques des utilisateurs ont dérivé ou le contexte métier a été modifié. Sans revue périodique, le portefeuille se fige et ne reflète plus la réalité des usages effectifs.

La charte interne d’usage doit suivre le même rythme d’actualisation. Ce n’est pas un document définitif mais un référentiel vivant, mis à jour à mesure que de nouveaux outils sont intégrés, que des cas d’usage sont déployés ou arrêtés et que la compréhension collective des risques s’affine. Les usages que l’organisation interdit aujourd’hui ne seront pas nécessairement les mêmes dans dix-huit mois ; réciproquement, de nouveaux risques peuvent apparaître sur des usages initialement considérés comme anodins.

La gouvernance pluridisciplinaire ne s’allège pas au passage à l’échelle : elle se structure et se formalise. Direction, RH, responsables métiers, RSSI et DPO ont tous un rôle à tenir dans la durée, pas seulement au moment du lancement. Les arbitrages sur les nouveaux cas d’usage, la gestion des incidents, les évolutions de la charte et les décisions de décommissionnement supposent des modalités de décision collective définies — comité dédié, intégration dans les instances existantes ou revue semestrielle formalisée. L’improvisation qui peut fonctionner en phase pilote ne tient plus lorsque le périmètre s’élargit.

Le passage à l’échelle n’est pas un état stable auquel on parvient après une série d’étapes réussies. C’est un processus de réévaluation continue dans lequel les pratiques, les outils et le cadre réglementaire évoluent simultanément. C’est précisément ce qui distingue une démarche structurée d’un déploiement par mimétisme — où l’on adopte parce que d’autres adoptent, sans critères ni gouvernance. Les organisations qui traitent leur portefeuille de cas d’usage comme un processus itératif sont mieux équipées pour tirer un bénéfice durable de l’IA, et mieux protégées lorsque les premières difficultés apparaissent.

Conclusion

La vraie question n’est plus de savoir si l’IA doit entrer dans l’organisation, mais dans quelles conditions elle y entre utilement. Les données de l’enquête TIC de l’Insee indiquent que l’adoption s’accélère — 18 % des entreprises françaises de 10 salariés ou plus en 2025, contre un taux trois fois inférieur en 2023 — sans que les dispositifs de gouvernance suivent nécessairement le même rythme. Les organisations qui auront cadré leurs cas d’usage dès la phase pilote, associé les bons acteurs et formalisé une gouvernance évolutive disposeront d’une base solide pour décider ce qu’elles étendent, ce qu’elles arrêtent et ce qu’elles n’auraient pas dû commencer.

Questions fréquentes sur les cas d’usage de l’IA en entreprise

Qu’est-ce qu’un cas d’usage de l’IA en entreprise ?

Un cas d’usage IA désigne une application concrète et délimitée de l’intelligence artificielle à un problème métier identifié — automatisation d’un traitement documentaire, aide à la rédaction, analyse de données RH. Il se distingue d’un usage ponctuel individuel par son caractère organisé et encadré par l’entreprise.

Comment identifier les bons cas d’usage de l’IA dans une PME ou une ETI ?

La CNIL recommande de partir d’un besoin concret plutôt que d’un outil. Concrètement, on recense les tâches pénibles ou répétitives avec les salariés, on les décrit sur une fiche commune, puis on les priorise. L’Insee note que l’usage de l’IA est nettement plus faible dans les petites structures que dans les entreprises de 250 salariés ou plus (58 %) : une démarche progressive, par petits pilotes, est donc adaptée.

Quels critères utiliser pour prioriser les cas d’usage de l’IA ?

La rédaction propose cinq critères notés de 1 à 3 : bénéfice pour le salarié, fréquence de la tâche, faisabilité technique, sensibilité des données et risque d’erreur. Cette grille n’a pas de valeur normative. Le manque d’expertise est cité par 54 % des entreprises non utilisatrices, ce qui plaide pour des cas d’usage à périmètre limité et à résultat vérifiable.

Faut-il consulter le CSE avant de déployer un outil d’IA dans l’entreprise ?

Dans les entreprises d’au moins 50 salariés, le CSE est informé et consulté sur l’introduction de nouvelles technologies (article L2312-8 du Code du travail). Des décisions de première instance ont qualifié des outils d’IA de nouvelle technologie, mais l’étendue exacte de l’obligation reste débattue : en cas de doute, associer le CSE en amont et consulter un juriste.

Peut-on transmettre des données de salariés à un assistant d’IA générative ?

Pas sans précautions : dès que les données permettent d’identifier un salarié, le RGPD s’applique. La CNIL cite, parmi les exemples d’usages à interdire selon les risques, le fait de fournir des données personnelles au système, et recommande de vérifier si le prestataire peut réutiliser les données fournies. Le DPO doit être associé avant tout test.

Sources

• Insee, « Les technologies de l’information et de la communication dans les entreprises en 2025 », Insee Première n° 2120
• CNIL, « Comment déployer une IA générative ? », 18 juillet 2024
• Code du travail, article L2312-8 (consultation du CSE)
• Code du travail, article L2311-2 (seuil de mise en place du CSE)