L’intelligence artificielle est de plus en plus présente dans les entreprises. Beaucoup testent déjà des assistants, des outils de génération de contenu ou des solutions capables d’automatiser certaines tâches.
Mais passer d’un test ponctuel à une solution réellement intégrée dans l’entreprise change la nature du projet.
C’est notamment dans ce contexte que l’Union européenne a adopté l’AI Act, un règlement qui établit un cadre commun pour le développement et l’utilisation de l’intelligence artificielle au sein de l’UE. Entré en vigueur en août 2024, il s’applique progressivement selon un calendrier qui s’étend sur plusieurs années.
Dès qu’une IA intervient dans un processus métier, accède à des données internes, échange avec des clients ou déclenche des actions, de nouvelles questions apparaissent. Avec l’AI Act, ces questions prennent aussi une dimension réglementaire.
L’objectif n’est pourtant pas de freiner les projets IA. L’enjeu est surtout de mieux les cadrer dès le départ.
L’AI Act repose sur une logique simple : les exigences dépendent du niveau de risque lié à l’utilisation de l’IA.
Ce niveau de risque ne dépend pas uniquement de la technologie utilisée, mais surtout du cas d’usage et de son contexte. Un assistant interne qui recherche des informations dans une documentation peut, par exemple, avoir des implications très différentes selon la nature des données consultées, les collaborateurs qui l’utilisent et les conséquences que peuvent avoir ses réponses.
Avant de parler de technologie, il faut donc commencer par préciser le cas d’usage :
Cette étape est essentielle. Dire « nous voulons utiliser l’IA dans le recrutement » ou « nous voulons un agent IA pour le service client » reste trop vague.
La conception du projet dépend de ce que le système fait concrètement.
Une IA peut avoir différents niveaux de responsabilité.
Elle peut simplement assister un utilisateur, par exemple en synthétisant un document ou en préparant une réponse. Elle peut également recommander une action, produire du contenu ou aller jusqu’à déclencher elle-même certaines opérations.
Cette distinction a un impact direct sur la manière de concevoir la solution.
Prenons un agent de service client. Lui permettre de suggérer une réponse à un collaborateur est très différent de lui permettre d’accorder automatiquement un remboursement ou de modifier une commande.
Plus l’IA dispose d’autonomie, plus il faut réfléchir aux limites à lui imposer.
Certaines questions deviennent alors centrales : dans quelles situations un humain doit-il intervenir ? Quelles actions peuvent être automatisées ? Quels cas doivent être bloqués ou transférés à un collaborateur ?
Pour certains systèmes à haut risque, l’AI Act prévoit explicitement des exigences de supervision humaine. Mais même en dehors de ces cas, définir clairement le rôle de l’humain reste une bonne pratique de conception.
La transparence est un autre sujet concret.
Lorsqu’un utilisateur échange directement avec un système d’IA, il doit, dans certaines situations prévues par l’AI Act, être informé qu’il interagit avec une IA.
Pour une entreprise qui développe un chatbot ou un agent conversationnel, cela influence directement l’expérience utilisateur.
Il faut notamment se demander comment présenter l’assistant, comment expliquer ses limites et à quel moment permettre à l’utilisateur de passer à un humain.
Un chatbot qui répond à des questions générales n’a pas le même impact qu’un agent qui traite une réclamation, un problème contractuel ou une situation complexe.
La transparence ne doit donc pas être considérée comme une simple mention à ajouter dans l’interface. Elle fait partie de la conception du parcours utilisateur.
Une solution IA devient réellement utile lorsqu’elle peut travailler avec le contexte de l’entreprise : documents internes, CRM, ERP, base de connaissances ou outils métiers.
Mais ces connexions nécessitent de poser des limites claires.
À quelles données l’IA peut-elle accéder ? Peut-elle uniquement lire des informations ou également les modifier ? Peut-elle envoyer un e-mail, créer un ticket ou mettre à jour une fiche client ? Certaines actions doivent-elles être validées ?
Il faut également pouvoir comprendre ce que le système a fait lorsqu’un problème survient.
Selon le type de système et son niveau de risque, l’AI Act peut imposer des exigences spécifiques en matière de gestion des risques, de documentation, de journalisation ou de sécurité.
Mais indépendamment de la réglementation, ces sujets sont surtout des choix d’architecture importants.
Limiter les accès, contrôler les permissions ou conserver une trace de certaines actions permet de construire une solution plus fiable et plus facile à exploiter.
Le risque serait de considérer que toutes ces questions imposent de concevoir immédiatement une solution complète.
Pour beaucoup de projets IA, une approche progressive reste la plus efficace : cadrer → développer un POC → tester → mesurer → sécuriser → déployer.
Un POC permet de vérifier rapidement si l’idée fonctionne réellement.
Prenons une entreprise qui souhaite développer un assistant capable de répondre aux questions de ses collaborateurs à partir de documents internes.
Avant de déployer l’outil auprès de toute l’organisation, un POC permet de répondre à quelques questions essentielles : les réponses sont-elles suffisamment fiables ? L’outil retrouve-t-il les bonnes informations ? Quels sont ses principaux cas d’échec ? Les utilisateurs gagnent-ils réellement du temps ?
Cette phase permet également d’identifier plus tôt les contraintes liées aux données, à la sécurité ou à l’intégration technique.
L’objectif n’est pas simplement de vérifier que l’IA « fonctionne ». Il faut surtout déterminer si elle apporte suffisamment de valeur dans le contexte réel de l’entreprise.
La réussite d’un projet IA ne dépend pas uniquement du modèle choisi. Elle dépend surtout de la manière dont la solution est pensée et intégrée dans son contexte réel d’utilisation.
Quel problème voulons-nous résoudre ? Quel rôle donnons-nous à l’IA ? Quelles données peut-elle utiliser ? Jusqu’où peut-elle agir seule ? Quand un humain doit-il intervenir ? Comment mesurer la qualité des résultats ?
L’AI Act renforce l’importance de ces questions, sans pour autant empêcher l’expérimentation.
Pour une entreprise, l’enjeu est donc moins de commencer par la réglementation que de commencer par un cas d’usage bien défini et une conception adaptée à son niveau de risque.
C’est dans cette logique que DJM lab accompagne les entreprises, du cadrage du besoin au développement de POC, MVP et solutions IA intégrées aux outils et processus existants.
Chez DJM Lab, nous ne construisons pas seulement des produits. Nous construisons des success stories.
