Cadrer un projet IA en entreprise : cas d'usage, risques, conformité

Un projet d'intelligence artificielle ne rate presque jamais à cause du modèle. Il rate parce qu'il a été mal cadré : un cas d'usage flou, des données que personne n'a le droit d'utiliser, un risque réglementaire découvert trop tard. Le cadrage est le moment où l'on décide si l'on peut dire oui, et à quelles conditions.

01Cas d'usageChoisi par la valeur et la faisabilité.

02Données et droitsInventaire, propriétaires, autorisations.

03Données personnellesAnalyse d'impact si nécessaire.

04Niveau de risquePositionnement au sens de l'AI Act.

05Limites explicitesCe que l'IA n'a pas le droit de faire.

06Arrêt, sponsor, équipeCritères d'arrêt et budget qualité des données.

Choisir le cas d'usage par la valeur et la faisabilité

La première erreur consiste à partir de la technologie. Un assistant conversationnel, un agent, un système de génération augmentée par recherche (RAG) sont des moyens, pas des objectifs. Le bon point de départ est un problème métier concret et coûteux.

Sur le terrain, les candidats sérieux se ressemblent : un technicien de maintenance qui passe du temps à retrouver la bonne procédure, un service finance qui rapproche des factures à la main, un bureau d'études qui cherche dans des années de rapports d'essais, une équipe supply qui anticipe mal les ruptures.

Pour chaque candidat, deux questions suffisent au premier tri.

• Quelle est la valeur si cela fonctionne ? Temps gagné, erreurs évitées, décisions plus rapides, risque réduit.
• Est-ce faisable avec les données et les compétences dont nous disposons dans les six prochains mois ?

Un cas d'usage à forte valeur mais infaisable est un projet de recherche. Un cas d'usage faisable mais sans valeur est une démonstration. Le premier projet doit se situer là où les deux se rencontrent, avec un utilisateur final identifié qui a envie d'en bénéficier.

Inventorier les données et leurs droits

Une fois le cas d'usage choisi, il faut lister les données nécessaires. Pas en termes vagues comme « les données de production », mais table par table, document par document, capteur par capteur.

Pour chaque source, quatre informations sont indispensables :

• Où est-elle stockée et qui en est le propriétaire métier ?
• Quelle est sa qualité réelle : complétude, fraîcheur, cohérence entre systèmes ?
• Avons-nous le droit de l'utiliser pour cet usage ? Un contrat fournisseur ou un accord client peuvent l'interdire.
• Peut-elle sortir de l'entreprise ? Si le modèle est hébergé chez un tiers, cette question devient centrale.

Dans un contexte industriel, cette étape révèle souvent des surprises : des plans soumis au secret industriel mélangés à de la documentation générale, des historiques de maintenance en trois versions contradictoires.

C'est ici que la gouvernance des données montre son utilité. Un catalogue à jour, des propriétaires identifiés et des règles de classification ne freinent pas le projet. Ils lui font gagner des semaines.

Données personnelles et analyse d'impact

Dès qu'une donnée permet d'identifier une personne, directement ou indirectement, le Règlement général sur la protection des données (RGPD) s'applique. Les projets IA en sont rarement exempts : noms d'opérateurs dans les rapports d'incident, adresses électroniques dans les tickets, badges d'accès, données de véhicules rattachées à un conducteur.

Trois réflexes à adopter dès le cadrage :

1. Définir la finalité précise du traitement et vérifier qu'elle est compatible avec celle pour laquelle les données ont été collectées.
2. Appliquer la minimisation : n'utiliser que les données réellement nécessaires. Souvent, la pseudonymisation permet de conserver la valeur sans conserver le risque.
3. Vérifier si une analyse d'impact relative à la protection des données (AIPD) est requise. C'est le cas lorsque le traitement présente un risque élevé pour les personnes. La Commission nationale de l'informatique et des libertés (CNIL) publie des critères et des outils pour la conduire.

Associer le délégué à la protection des données (DPO) dès la première semaine coûte quelques heures. L'associer à la veille du déploiement coûte le projet.

Positionner le projet au sens de l'AI Act

L'AI Act européen classe les systèmes d'IA par niveau de risque. Certaines pratiques sont interdites. D'autres sont dites à haut risque et entraînent des obligations lourdes de documentation, de supervision humaine et de gestion de la qualité. D'autres encore relèvent d'obligations de transparence, comme informer une personne qu'elle interagit avec une IA. Le reste est à risque minimal.

Au cadrage, il ne s'agit pas de produire un dossier juridique complet, mais de répondre honnêtement à une question : dans quelle catégorie ce système risque-t-il de tomber ?

Un assistant qui aide un technicien à retrouver une procédure n'a pas le même profil qu'un système qui trie des candidatures ou évalue la performance d'un salarié. Un outil qui influence la sécurité d'un équipement critique, dans le ferroviaire ou l'énergie, mérite un examen particulier.

Cette classification précoce détermine le niveau d'effort à prévoir et protège le sponsor de mauvaises surprises en comité de direction. La norme ISO 42001, qui décrit un système de management de l'IA, offre un cadre utile pour structurer cette réflexion dans la durée.

Définir ce que l'IA n'a pas le droit de faire

Un projet bien cadré précise les limites avant de préciser les fonctionnalités. Ces interdits doivent être écrits, validés et testés. Quelques exemples issus de contextes industriels :

• L'assistant ne prend aucune décision seule sur un équipement de sécurité ; il propose, un humain valide.
• Le système ne répond jamais sur la base d'un document dont l'utilisateur n'a pas le droit de lecture.
• Aucune donnée personnelle de salarié n'est envoyée à un modèle hébergé hors de l'Union européenne.
• Le modèle ne produit pas de réponse sans citer sa source lorsqu'il s'agit d'une procédure réglementaire.

Ces règles s'appliquent quel que soit le fournisseur, que l'on travaille avec Claude, GPT, Mistral ou un modèle ouvert hébergé en interne. Elles traduisent une conviction : la gouvernance ne freine pas l'IA, elle est ce qui permet de lui dire oui, en sachant précisément à quoi l'on dit oui.

Critères d'arrêt, sponsor et équipe

Un projet sans critère d'arrêt ne s'arrête jamais. Dès le cadrage, définissez le seuil de qualité en dessous duquel le projet est suspendu, le délai au bout duquel, sans usage réel, on arrête, et l'événement qui déclenche une réévaluation immédiate : incident de sécurité, fuite de données, changement réglementaire.

Côté organisation, trois rôles ne sont pas négociables. Un sponsor de direction qui arbitre et débloque. Un responsable métier qui possède le cas d'usage et juge de son utilité. Un responsable des données qui garantit l'accès, la qualité et la conformité.

Budgéter la qualité des données avant le modèle

Dernier point, souvent le plus sous-estimé. La majorité de l'effort se situe en amont du modèle : collecter, nettoyer, documenter, contrôler les droits, mettre en place les flux. Un modèle, quel que soit son éditeur, ne corrige pas une documentation obsolète ni un référentiel d'équipements incohérent.

Prévoyez donc une ligne budgétaire explicite pour la qualité des données, avec ses propres livrables : dictionnaire des données, règles de qualité, tests automatisés, traçabilité des sources. Cette dépense n'est pas perdue si le projet IA s'arrête : elle sert tous les usages suivants.

À retenir

• Partez d'un problème métier concret, pas d'une technologie.
• Inventoriez les données source par source, avec leur propriétaire, leur qualité et leurs droits d'usage.
• Impliquez le DPO dès le premier jour et tranchez la question de l'analyse d'impact.
• Positionnez le système dans les niveaux de risque de l'AI Act et écrivez ce qu'il n'a pas le droit de faire.
• Financez la qualité des données comme un chantier à part entière.

Checklist

• Le cas d'usage a un utilisateur final nommé et une valeur décrite en termes métier.
• Chaque source de données a un propriétaire, une évaluation de qualité et un droit d'usage vérifié.
• Les données personnelles sont identifiées, minimisées, et la nécessité d'une AIPD est tranchée.
• Le niveau de risque au sens de l'AI Act a été estimé et documenté.
• Les interdits du système sont écrits et validés par le métier, le DPO et la sécurité.
• Les critères d'arrêt, le sponsor et l'équipe sont fixés.