Cadrer un projet d'IA : Dans quel ordre poser les bonnes questions ?
Une séquence de cadrage peut être organisée en cinq étapes : définir le problème métier, préciser les cas d’usage, identifier le cadre juridique et réglementaire, analyser les écarts et les risques, puis déterminer les données nécessaires. Cette progression ne doit toutefois pas être comprise comme strictement linéaire : la faisabilité juridique, les risques et les données doivent être réexaminés tout au long du projet.
Étape 1 : pourquoi faut-il commencer par le problème métier, pas par l'outil ?
La première question à se poser n’est pas « quelle technologie utiliser ? » mais « quel problème concret cherchons-nous à résoudre ? ». Cette distinction paraît évidente, elle est pourtant l’écueil le plus fréquent. Un projet qui démarre par l’envie d’adopter l’IA, sans besoin clairement identifié, produit un système en quête d’un usage, coûteux et rarement adopté.
Formuler le problème en termes métier oblige à répondre à des questions simples mais structurantes : qu’est-ce qui ne fonctionne pas aujourd’hui, combien cela coûte, et à quoi ressemblerait une amélioration mesurable ? Si cette réponse n’est pas nette, la pertinence du futur système sera difficile à démontrer, et plus difficile encore à justifier devant une direction ou un financeur. Une évaluation honnête à ce stade peut d’ailleurs conclure qu’une IA n’est pas la meilleure réponse : parfois, un processus simplifié ou une meilleure formation des équipes résout le problème pour un coût et un risque bien moindres.
Étape 2 : comment traduire un problème métier en cas d'usage concrets ?
Une fois le problème posé, il faut le traduire en usages concrets. Que doit faire le système, exactement ? Pour quels utilisateurs ? Dans quelles situations ? Et surtout, quelles utilisations doivent être explicitement exclues ?
Cette dernière question est la plus négligée et la plus protectrice. Définir ce qu’un système ne doit pas faire borne son périmètre et prévient les dérives d’usage. C’est à cette étape que l’idée abstraite devient un périmètre opérationnel, c’est-à-dire quelque chose que l’on peut concevoir, tester et surveiller. Un périmètre flou, à l’inverse, transforme rapidement un outil utile en source de risque : on ne peut ni évaluer ni contrôler un système dont on n’a jamais défini les limites.
Étape 3 : quelles règles juridiques et réglementaires encadrent un projet d'IA ?
Vient ensuite la question des règles applicables. Elle ne se limite pas au RGPD et à l’AI Act, même si ces deux textes sont centraux. Selon le cas d’usage, entrent aussi en jeu le droit du travail, la propriété intellectuelle, la cybersécurité, le droit de la consommation, et surtout les règles sectorielles propres à la santé, à la finance, à l’assurance ou à l’éducation.
L’objectif de cette étape est d’identifier les obligations, mais aussi les restrictions et les interdictions qui encadrent l’usage envisagé. Certaines pratiques sont en effet purement interdites, indépendamment de toute mesure de transparence ou de consentement. Repérer ces limites tôt évite d’investir dans un projet voué à être bloqué.
Les questions à poser à cette étape
- Quelles données personnelles le système traitera-t-il, et sur quelle base légale ?
- Le cas d’usage relève-t-il d’une réglementation sectorielle spécifique ?
- Existe-t-il des pratiques d’IA interdites par l’AI Act qui pourraient s’appliquer ?
- Quelles obligations de transparence ou d’explicabilité sont imposées ?
Étape 4 : Comment identifier les écarts et les risques avant le déploiement ?
Le cadre posé, il faut examiner les failles.
Où le système peut-il produire des biais, au détriment de certains groupes ? Comment peut-il être attaqué ou détourné de son usage prévu ? Ses résultats sont-ils suffisamment transparents et contrôlables par un humain ? Peut-il porter atteinte aux droits des personnes concernées ?
Cette analyse ne sert pas seulement à documenter des risques : elle détermine les contrôles à mettre en place avant le déploiement. Un risque identifié en amont est généralement moins coûteux à traiter que le même risque découvert après le déploiement. Le même risque découvert en production se paie en incidents, en perte de confiance et parfois en non-conformité.
Étape 5 : Comment déterminer les données nécessaires au système d’IA ?
En dernier lieu seulement vient la question des données. Quelles données permettront au système de fonctionner ? D’où viennent-elles ? Sont-elles licitement utilisables, pertinentes, fiables et suffisamment représentatives de la réalité que le système devra traiter ?
Placer les données en fin de séquence ne signifie pas qu’elles sont secondaires, au contraire : un système ne vaut jamais mieux que les données qui l’alimentent. Mais on ne peut juger de la pertinence des données qu’une fois le problème, les cas d’usage, le cadre légal et les risques établis. Chercher les données avant d’avoir défini le besoin revient à collecter d’abord et à réfléchir ensuite, ce qui est précisément la source de nombreux problèmes de qualité, de représentativité et de conformité.
Pourquoi le cadrage d'un projet d'IA ne peut pas être linéaire
Cette séquence est pertinente parce qu’elle part du besoin métier et non de la technologie. Mais elle serait trompeuse si on la comprenait comme un processus strictement linéaire, où chaque étape se franchit une fois pour toutes.
Une dimension, en particulier, ne peut pas être traitée comme une case à cocher entre deux autres : le cadre juridique, réglementaire et éthique.
Placé en étape 3, il pourrait laisser croire que la conformité s’examine une fois, après avoir défini les cas d’usage. C’est une erreur. Certaines questions juridiques doivent remonter dès l’étape 1. Si le besoin métier suppose de traiter des données sensibles, de surveiller des personnes ou de mettre en œuvre une pratique interdite, sa faisabilité légale conditionne le projet avant même que l’on en précise les cas d’usage.
Découvrir en étape 3 qu’un usage est illicite, c’est avoir travaillé pour rien sur les étapes précédentes.
La bonne image n’est donc pas celle d’une étape juridique insérée dans une file. Le droit intervient d’abord comme un filtre de faisabilité, en amont, puis accompagne la conception, les tests, le déploiement et la surveillance du système tout au long de son cycle de vie. Lorsque le projet implique des données personnelles, cette logique traduit le principe de protection des données dès la conception et par défaut, prévu par l’article 25 du RGPD : la protection ne s’ajoute pas au projet, elle en fait partie dès l’origine.
Étape 5 : Comment déterminer les données nécessaires au système d’IA ?
Cadrer un projet d’IA ne consiste donc pas seulement à placer des étapes dans le bon ordre. C’est aussi identifier, dès le départ, quelles dimensions devront être réexaminées à chaque phase du cycle de vie. La séquence en cinq étapes donne une direction : partir du problème, pas de l’outil. Mais sa vraie valeur tient à ce qu’elle rappelle en creux : un projet d’IA solide n’est pas celui qui coche des cases, c’est celui dont on a compris, avant d’investir, à quelles questions il faudra continuer de répondre tout au long de sa vie.
La question à retenir, pour toute organisation qui s’engage dans un projet d’IA : le cadre juridique et réglementaire intervient-il dès la définition du besoin, ou seulement au moment du déploiement ? La réponse en dit long sur la solidité du projet.
Questions fréquentes sur le cadrage d'un projet d'IA
La majorité des échecs en matière de projets d'IA ne sont pas causés par des lacunes technologiques, mais par un cadrage défaillant. Les organisations qui partent de l'outil plutôt que du problème métier construisent des systèmes sans usage clairement défini, difficiles à justifier et rarement adoptés par les équipes.
La séquence générale peut être structurée ainsi : (1) définir le problème métier, (2) préciser les cas d’usage, (3) identifier le cadre juridique et réglementaire, (4) analyser les écarts et les risques, puis (5) déterminer les données nécessaires.
Cet ordre n’est toutefois pas strictement linéaire. Selon la nature du projet, certaines questions juridiques et réglementaires doivent être examinées dès l’étude de faisabilité. Si le besoin suppose, par exemple, de traiter des données sensibles, de surveiller des personnes ou de mettre en œuvre une pratique susceptible d’être interdite, l’analyse juridique peut conditionner la poursuite du projet avant même que le cas d’usage soit entièrement défini.
Cette approche permet d’éviter d’investir dans une solution techniquement irréalisable, susceptible d'être juridiquement interdite ou insuffisamment maîtrisée.
Les questions juridiques doivent être intégrées dès l’étape 1, et non uniquement lors d’une phase de conformité dédiée. Certaines interdictions légales, prévues notamment par l’AI Act ou le RGPD, peuvent remettre en cause la faisabilité du projet avant même que les cas d’usage soient précisés. Attendre l’étape 3 pour les examiner expose au risque de devoir reprendre tout ou partie du projet.
À l'étape de définition du problème métier, une évaluation honnête doit examiner les alternatives non-IA : processus simplifié, meilleure formation des équipes, ou outil existant. Si l'amélioration mesurable peut être obtenue à moindre coût et moindre risque sans IA, cette option mérite d'être sérieusement considérée.
L’évaluation des données en dernier ne signifie pas qu’elles sont moins importantes. Leur qualité reste déterminante pour la performance du système. Toutefois, leur pertinence, leur licéité et leur représentativité ne peuvent être pleinement appréciées qu’une fois le problème, les cas d’usage, le cadre légal et les risques clairement définis. Collecter des données avant d’avoir répondu à ces questions peut entraîner des problèmes de conformité et de qualité.
Le principe de protection des données dès la conception (privacy by design), prévu par l'article 25 du RGPD, impose d'intégrer la protection des données personnelles dans la conception même du système, et non de l'ajouter a posteriori. Appliqué à un projet d'IA, ce principe signifie que les choix architecturaux, les cas d'usage et les mesures de contrôle doivent être pensés en tenant compte des exigences de protection dès les premières étapes du cadrage.
