Le Regulatory Thinking, nouvelle étape du design responsable 

L’AI Act est le règlement européen qui encadre le développement et l’utilisation des systèmes d’intelligence artificielle selon leur niveau de risque. Pour les équipes UX, ce texte marque un tournant; la conformité ne peut plus être ajoutée à la fin du projet. Transparence, supervision humaine, droits des personnes et traçabilité doivent désormais être pensés dès la conception. 

Après le Design Thinking, une nouvelle approche émerge donc, le Regulatory Thinking, qui transforme les exigences réglementaires en véritables principes de design.

Le Design Thinking ne suffit plus pour concevoir des produits responsables

Désirabilité, faisabilité, viabilité… et désormais conformité

Le Design Thinking repose traditionnellement sur l’équilibre entre trois dimensions; la désirabilité pour les utilisateurs, la faisabilité technique et la viabilité économique. Un produit pertinent doit répondre à un besoin réel, pouvoir être développé et s’inscrire dans un modèle économique durable.

Mais cet équilibre ne suffit plus. Les produits numériques collectent des données, automatisent certaines décisions et influencent des domaines aussi sensibles que le recrutement, la santé, l’éducation ou l’accès à des services essentiels. Une solution peut donc être utile, techniquement performante et rentable, tout en exposant ses utilisateurs à des risques juridiques, éthiques ou discriminatoires.

La conformité devient ainsi une quatrième dimension de la conception. Il ne s’agit plus de se demander si un produit peut être créé, mais dans quelles conditions il peut l’être, quelles limites doivent être respectées et quelles protections doivent être proposées aux personnes concernées.

Quand une décision de design devient aussi une décision réglementaire

La réglementation peut sembler éloignée du travail quotidien des UX designers. Pourtant, de nombreuses obligations se matérialisent directement dans l’expérience utilisateur.

Faut-il informer une personne qu’elle échange avec une intelligence artificielle ? Comment lui expliquer qu’une décision a été automatisée ? Peut-elle la contester, demander l’intervention d’un humain ou corriger une information erronée ? À quel moment recueillir son consentement ? Comment éviter qu’un bouton, un message ou un paramètre par défaut ne l’oriente vers un choix qu’elle ne comprend pas réellement ?

Ces questions ne relèvent pas uniquement du droit. Elles concernent le contenu des interfaces, l’architecture de l’information, les parcours, les mécanismes de contrôle et la manière dont le système présente ses décisions. Une obligation de transparence mal traduite peut produire une longue mention juridique que personne ne lit. Une supervision humaine mal conçue peut se limiter à un bouton inaccessible ou à un recours purement théorique.

Le designer participe donc à la façon dont les droits deviennent ( ou non ) réellement utilisables. Une décision d’interface peut faciliter la compréhension et la reprise de contrôle, mais elle peut aussi masquer un risque ou créer une illusion de choix.

L’AI Act, révélateur d’un changement plus profond dans la conception numérique

L’AI Act illustre particulièrement cette évolution. Le règlement européen adopte une approche fondée sur les risques : les obligations applicables dépendent notamment de l’usage du système d’intelligence artificielle et de ses conséquences potentielles sur les personnes.

Pour certains systèmes, notamment ceux considérés comme à haut risque, le texte prévoit des exigences relatives à la gestion des risques, à la documentation, à la transparence, à la traçabilité et à la supervision humaine. D’autres systèmes sont soumis à des obligations spécifiques d’information, par exemple lorsqu’un utilisateur interagit directement avec une IA.

Le règlement ne dicte pas la forme exacte d’un parcours ou d’une interface. Il crée cependant des obligations que les équipes doivent traduire en solutions concrètes. La conformité se joue alors dans des détails très opérationnels, le moment où une information apparaît, les mots employés, la visibilité d’un avertissement, la possibilité de revenir en arrière ou l’accès effectif à une intervention humaine.

L’AI Act révèle ainsi un changement plus large; la réglementation n’intervient plus seulement pour contrôler un produit terminé. Elle influence progressivement la manière même de le concevoir. 

Pour les équipes UX et produit, comprendre les règles applicables devient donc une condition pour imaginer des expériences à la fois utiles, responsables et dignes de confiance.

Qu’est-ce que le Regulatory Thinking ?

Le Regulatory Thinking consiste à intégrer les exigences réglementaires dès les premières étapes de conception d’un produit ou d’un service numérique.

L’objectif n’est pas de transformer les designers en juristes. Il s’agit plutôt de considérer la réglementation comme une donnée du projet, au même titre que les besoins utilisateurs, les contraintes techniques ou les objectifs commerciaux.

Cette approche devient particulièrement importante avec des textes comme l’AI Act, qui impose aux entreprises de mieux anticiper les risques liés aux systèmes d’intelligence artificielle.

Intégrer les règles dès la conception, plutôt qu’après le lancement

Dans de nombreux projets, la conformité réglementaire est encore vérifiée à la fin du processus. Le produit est conçu, développé, puis transmis aux équipes juridiques avant son lancement.

Cette méthode peut entraîner :

• des modifications tardives ;
• des retards de mise en production ;
• des coûts supplémentaires ;
• des parcours utilisateurs incohérents ;
• des fonctionnalités impossibles à conserver.

Le Regulatory Thinking propose de renverser cette logique.

Les équipes UX, produit, techniques et juridiques collaborent dès le cadrage du projet. Elles identifient ensemble les risques, les obligations et les droits à prendre en compte.

La conformité ne devient donc plus une validation finale, mais un élément continu du processus de conception.

Transformer une réglementation en contraintes et opportunités de design

Une réglementation impose nécessairement certaines limites. Elle peut obliger une entreprise à informer les utilisateurs, à recueillir leur consentement, à documenter une décision ou à permettre une intervention humaine.

Mais ces obligations peuvent aussi devenir des opportunités de design.

Une exigence de transparence peut conduire à créer une interface plus compréhensible. Une obligation de supervision humaine peut permettre de concevoir un parcours de recours plus rassurant. Une contrainte liée aux données personnelles peut encourager les équipes à ne collecter que les informations réellement utiles.

Le Regulatory Thinking aide ainsi à traduire les textes juridiques en questions concrètes :

• Que doit comprendre l’utilisateur ?
• À quel moment doit-il recevoir cette information ?
• Comment peut-il refuser ou modifier son choix ?
• Peut-il demander l’intervention d’une personne ?
• Que se passe-t-il lorsqu’une erreur est détectée ?

La réglementation cesse alors d’être perçue comme un frein. Elle devient un cadre permettant de concevoir des produits plus clairs, plus sûrs et plus fiables.

Regulatory Thinking, conformité réglementaire et « compliance by design » : quelles différences ?

Ces trois notions sont proches, mais elles ne recouvrent pas exactement la même réalité.

La conformité réglementaire consiste à vérifier qu’un produit, une organisation ou un processus respecte les règles applicables. Elle se concentre principalement sur le résultat attendu.

La compliance by design vise à intégrer les obligations de conformité directement dans les systèmes, les procédures et les fonctionnalités. Elle cherche à éviter que le respect des règles dépende uniquement d’actions manuelles ou de contrôles réalisés après coup.

Le Regulatory Thinking désigne une démarche plus large. Il encourage les équipes à utiliser la réglementation comme un point de départ de la réflexion produit.

Il s’agit De se demander comment celle-ci influence :

• la recherche utilisateur ;
• les choix de conception ;
• les parcours UX ;
• les contenus d’interface ;
• les mécanismes de contrôle ;
• les décisions prises tout au long du projet.

Le Regulatory Thinking complète ainsi le Design Thinking. Il ajoute aux besoins de l’utilisateur une nouvelle notion essentielle : le produit imaginé est non seulement utile et simple à utiliser, mais aussi conforme, responsable et acceptable.

Ce que l’AI Act change concrètement pour les équipes UX

L’AI Act européen ne concerne pas uniquement les juristes, les développeurs ou les spécialistes de la donnée. Plusieurs de ses exigences doivent être traduites dans les interfaces et les parcours utilisateurs.

Pour les équipes UX, l’enjeu est de rendre la transparence, le contrôle humain et les droits des personnes réellement accessibles.

Le niveau de risque influence directement l’expérience à concevoir

L’AI Act repose sur une approche graduée : plus un système d’intelligence artificielle présente de risques pour la sécurité ou les droits fondamentaux, plus les obligations sont importantes.

Un simple moteur de recommandation et un outil utilisé pour sélectionner des candidats ne nécessitent donc pas les mêmes précautions. Les systèmes considérés comme à haut risque peuvent notamment concerner l’emploi, l’éducation, certains services essentiels ou l’accès aux soins.

Avant de concevoir un parcours, les équipes doivent ainsi déterminer :

• le rôle exact de l’IA ;
• les personnes affectées par ses résultats ;
• les conséquences possibles d’une erreur ;
• le niveau de contrôle laissé à l’utilisateur ;
• les obligations applicables au système.

Cette classification influence directement les informations à afficher, les possibilités de recours et les mécanismes de supervision à prévoir.

Informer clairement l’utilisateur lorsqu’il interagit avec une IA

Dans certaines situations, l’AI Act impose d’informer les personnes qu’elles interagissent avec un système d’intelligence artificielle, sauf lorsque cela est déjà évident.

Cette obligation concerne notamment les agents conversationnels. Le règlement prévoit également des règles de transparence pour la reconnaissance des émotions, la catégorisation biométrique et certains contenus générés ou manipulés par une IA.

Pour le designer, ajouter une mention « généré par une IA » ne suffit pas toujours. L’information doit être claire, visible, accessible et présentée au bon moment.

Plusieurs questions se posent alors :

• L’utilisateur comprend-il qu’il ne parle pas à un humain ?
• Sait-il quelles tâches sont réalisées par l’IA ?
• L’information apparaît-elle avant que son choix soit influencé ?
• Peut-il facilement obtenir de l’aide auprès d’une personne ?

La transparence devient ainsi un élément à part entière de l’expérience utilisateur, et non une simple mention ajoutée en bas de l’écran.

Rendre les décisions automatisées compréhensibles et contestables

Lorsqu’un système d’IA participe à une décision importante, l’utilisateur doit pouvoir comprendre le rôle joué par la technologie.

Pour certaines décisions fondées sur les résultats d’un système d’IA à haut risque et produisant des effets juridiques ou significatifs, l’AI Act prévoit un droit à obtenir des explications claires et pertinentes sur le rôle du système dans la procédure et sur les principaux éléments de la décision.

Du point de vue de l’UX, cela suppose de concevoir des explications adaptées :

• Quels facteurs ont influencé le résultat ?
• Quelles données ont été utilisées ?
• L’utilisateur peut-il signaler une information incorrecte ?
• Comment peut-il demander une révision ?
• À qui doit-il s’adresser en cas de désaccord ?

Une explication trop technique ne permet pas d’exercer réellement ses droits. À l’inverse, une formulation trop simplifiée peut donner une représentation trompeuse du fonctionnement du système.

Le défi consiste donc à trouver le bon niveau d’information : suffisamment précis pour être utile, sans rendre le parcours illisible.

Concevoir une supervision humaine qui ne soit pas seulement théorique

Pour les systèmes d’IA à haut risque, l’AI Act exige des mesures de supervision humaine adaptées aux risques et au contexte d’utilisation.

Les personnes chargées de ce contrôle doivent notamment être en mesure de comprendre les capacités et les limites du système, de détecter certaines anomalies et, lorsque cela est nécessaire, d’ignorer, de modifier ou d’interrompre son résultat.

La présence d’un humain ne suffit donc pas à garantir un véritable contrôle.

Encore faut-il que cette personne dispose :

• des informations nécessaires pour décider ;
• du temps suffisant pour examiner le résultat ;
• de l’autorité permettant de le remettre en question ;
• d’une interface facilitant la détection des erreurs ;
• d’une action claire pour suspendre ou corriger le système.

Les équipes UX doivent également éviter le biais d’automatisation, lorsqu’une interface présente une recommandation algorithmique comme certaine ou objective, l’opérateur humain peut être tenté de la valider sans recul.

Une supervision efficace doit donc encourager l’analyse critique plutôt que la validation automatique.

Prévoir la traçabilité des actions et des décisions du système

Les systèmes d’IA à haut risque doivent intégrer des fonctionnalités permettant l’enregistrement automatique des événements pertinents pendant leur fonctionnement. Ces journaux doivent notamment contribuer à identifier les situations à risque, faciliter le suivi après la mise sur le marché et surveiller le fonctionnement du système.

La traçabilité influence également les outils conçus pour les opérateurs et les équipes de contrôle.

Il peut être nécessaire de retrouver :

• la version du système utilisée ;
• les données prises en compte ;
• le résultat produit par l’IA ;
• les modifications réalisées par un humain ;
• la date et le contexte d’une décision ;
• les erreurs ou incidents signalés.

Pour les designers, l’enjeu est de rendre ces informations consultables sans créer des tableaux de bord trop complexes. Une bonne interface de traçabilité doit permettre de comprendre rapidement ce qui s’est passé, qui est intervenu et comment la décision finale a été prise.

L’AI Act ne définit pas précisément la forme des écrans à concevoir. Il fixe cependant des exigences que les équipes UX doivent transformer en expériences concrètes, compréhensibles et réellement utilisables.

Comment intégrer le Regulatory Thinking dans une démarche UX ?

Le Regulatory Thinking ne nécessite pas de remplacer les méthodes UX existantes. Il consiste à enrichir chaque étape du projet avec une lecture réglementaire : droits des personnes, risques potentiels, transparence et mécanismes de contrôle.

Cette réflexion doit commencer avant la création des premières interfaces et se poursuivre après la mise en ligne du produit.

En phase de recherche : identifier les utilisateurs, les personnes affectées et leurs droits

L’UX research s’intéresse généralement aux personnes qui utilisent directement le produit. Avec un système d’intelligence artificielle, ce périmètre doit être élargi.

Certaines personnes peuvent subir les conséquences d’un algorithme sans utiliser elles-mêmes l’interface. Un candidat évalué par un outil de recrutement, par exemple, est affecté par le système même si celui-ci est principalement utilisé par le recruteur.

La recherche doit donc permettre d’identifier :

• les utilisateurs directs du produit ;
• les personnes concernées par ses résultats ;
• les catégories potentiellement vulnérables ;
• les droits applicables à chaque profil ;
• les conséquences possibles d’une erreur.

Cette approche évite de concevoir uniquement pour l’entreprise qui utilise l’outil, au détriment des personnes sur lesquelles il produit des effets.

En phase de cadrage : cartographier les risques liés au cas d’usage

Le niveau de risque ne dépend pas uniquement de la technologie utilisée. Il dépend aussi du contexte, de la finalité du système et de l’importance de ses résultats.

Un outil qui recommande une musique et un système qui classe des candidatures peuvent utiliser des technologies proches, mais leurs conséquences sont très différentes.

La cartographie des risques peut notamment prendre en compte :

• la gravité d’une erreur ;
• la fréquence d’utilisation du système ;
• le degré d’automatisation de la décision ;
• la qualité des données disponibles ;
• les risques de discrimination ;
• la possibilité de corriger le résultat ;
• les personnes les plus exposées.

Ce travail permet de définir les protections nécessaires avant de commencer la conception détaillée du parcours.

En phase d’idéation : concevoir les mécanismes de transparence et de contrôle

La transparence ne doit pas être ajoutée une fois que le fonctionnement du produit a déjà été décidé. Elle doit faire partie des solutions explorées pendant l’idéation.

Les équipes peuvent travailler sur plusieurs niveaux d’information. Une première explication courte aide l’utilisateur à comprendre immédiatement le rôle de l’IA. Des contenus plus détaillés restent ensuite accessibles pour les personnes qui souhaitent approfondir.

Les idées produites peuvent porter sur :

• l’identification claire des fonctionnalités utilisant une IA ;
• l’explication des données prises en compte ;
• l’affichage du degré de confiance d’un résultat ;
• la correction d’une information erronée ;
• la demande d’une révision humaine ;
• le signalement d’une réponse problématique.

Le contrôle ne doit pas être limité à un bouton symbolique. Il doit conduire à une action identifiable et produire un résultat compréhensible.

En phase de prototypage : tester la compréhension, le consentement et la possibilité de reprendre la main

Un parcours peut être juridiquement complet tout en restant incompréhensible pour l’utilisateur. Les tests UX permettent de vérifier si les protections prévues fonctionnent dans la pratique.

Il faut notamment observer si les participants comprennent :

• qu’une intelligence artificielle intervient ;
• le rôle qu’elle joue dans le résultat ;
• les limites de son fonctionnement ;
• les conséquences de leur consentement ;
• les moyens de modifier leur choix ;
• la procédure permettant de contacter un humain.

Les tests doivent porter sur des situations normales, mais aussi sur les cas d’erreur, de refus ou de désaccord. Un parcours responsable ne se mesure pas uniquement lorsque tout fonctionne correctement.

Après le lancement : surveiller les incidents et les effets réels du produit

Le Regulatory Thinking ne s’arrête pas à la mise en production. Les comportements réels peuvent révéler des risques qui n’étaient pas visibles pendant la conception.

L’AI Act prévoit notamment un suivi après la mise sur le marché pour les systèmes d’IA à haut risque. Les fournisseurs doivent organiser une collecte et une analyse continues des données pertinentes sur les performances du système. Les organisations qui les déploient doivent également surveiller leur fonctionnement et signaler certaines situations à risque ou certains incidents.

Du côté des équipes UX, ce suivi peut s’appuyer sur :

• les signalements des utilisateurs ;
• les demandes de recours ;
• les erreurs fréquemment corrigées ;
• les abandons dans les parcours sensibles ;
• les écarts entre différents groupes de personnes ;
• les validations systématiques des recommandations de l’IA.

Ces données permettent d’améliorer le produit tout en vérifiant que les mécanismes de protection restent efficaces dans la durée.

Les livrables du designer à l’ère du Regulatory Thinking

Le Regulatory Thinking élargit les livrables traditionnels de l’UX design. Aux personas, parcours utilisateurs et prototypes peuvent s’ajouter des documents consacrés aux risques, aux droits et aux décisions prises pendant le projet.

Ces livrables n’ont pas vocation à créer une couche documentaire supplémentaire. Ils permettent de rendre les arbitrages visibles et de faciliter la collaboration entre les métiers.

La cartographie des risques et des droits

La cartographie des risques et des droits relie chaque fonctionnalité aux personnes qu’elle peut affecter.

Elle présente de manière synthétique :

• la fonction du système d’IA ;
• les utilisateurs et les personnes concernées ;
• les risques identifiés ;
• les droits à préserver ;
• les mesures de réduction du risque ;
• le niveau de gravité résiduel.

Ce document aide les équipes à prioriser leurs efforts. Une fonctionnalité pouvant influencer une décision importante nécessite davantage de contrôle qu’une recommandation facilement réversible.

Le parcours des personnes affectées par l’algorithme

Un parcours UX classique décrit ce que fait l’utilisateur dans l’interface. Le parcours des personnes affectées s’intéresse également à ce qui se passe avant et après la décision algorithmique.

Il peut représenter l’ensemble de l’expérience :

1. la collecte des informations ;
2. leur analyse par le système ;
3. la production d’un résultat ;
4. l’intervention éventuelle d’un opérateur ;
5. la communication de la décision ;
6. la demande d’explication ou de révision ;
7. la correction finale.

Cette représentation met en évidence les moments où une personne risque de perdre le contrôle ou de ne pas comprendre ce qui lui arrive.

La matrice de transparence

Toutes les informations ne doivent pas être affichées au même moment ni avec le même niveau de détail. La matrice de transparence organise les contenus en fonction du profil de l’utilisateur et de l’étape du parcours.

Elle peut préciser :

• l’information à communiquer ;
• son destinataire ;
• le moment de son affichage ;
• son niveau de détail ;
• le format utilisé ;
• l’action disponible après sa lecture.

Une mention courte peut apparaître dans l’interface, tandis qu’une explication plus complète est proposée dans un espace secondaire. Cette hiérarchie permet d’informer sans surcharger chaque écran.

Le scénario de supervision humaine

La supervision humaine doit être décrite comme un véritable parcours opérationnel.

Le scénario précise le moment où une intervention est nécessaire, la personne responsable et les informations dont elle dispose. Il indique également ce que cette personne peut faire : confirmer, corriger, ignorer ou interrompre le résultat du système.

L’AI Act prévoit que la supervision des systèmes à haut risque soit adaptée au niveau d’autonomie, au contexte et aux risques. Elle doit notamment permettre aux personnes compétentes de comprendre les limites du système et d’intervenir lorsque cela est nécessaire.

Le livrable peut donc documenter :

• les alertes déclenchant une vérification ;
• les compétences requises ;
• les données visibles par l’opérateur ;
• les actions disponibles ;
• la procédure d’escalade ;
• la conservation de la décision finale.

Le journal des décisions de conception

Le journal des décisions conserve la trace des principaux arbitrages réalisés pendant le projet.

Il explique, par exemple, pourquoi une information apparaît à une étape précise, pourquoi une fonctionnalité a été limitée ou pourquoi une validation humaine a été ajoutée.

Pour chaque décision, le document peut indiquer :

• le risque identifié ;
• les options envisagées ;
• la solution retenue ;
• les métiers consultés ;
• les résultats des tests ;
• les éventuelles limites restantes.

Cette documentation facilite les audits, les évolutions futures et l’arrivée de nouveaux membres dans l’équipe. Elle évite également de perdre la logique qui se cache derrière une interface.

Regulatory Thinking en pratique : l’exemple d’un système de recrutement par IA

Le recrutement constitue un exemple particulièrement parlant. L’IA peut aider à trier des candidatures, rapprocher des profils d’une offre ou assister les recruteurs pendant l’évaluation.

Cette efficacité apparente s’accompagne néanmoins de risques importants pour les candidats. Les systèmes destinés au recrutement, à la sélection ou à l’évaluation des personnes dans le cadre professionnel font partie des usages considérés comme à haut risque par l’AI Act, sous réserve des critères prévus par le règlement.

Ce que voit le candidat dans un parcours classique

Dans un parcours classique, le candidat consulte une offre, dépose son CV et répond à quelques questions. Il reçoit ensuite une confirmation, puis éventuellement une réponse positive ou négative.

L’intervention de l’intelligence artificielle reste souvent invisible. Le candidat ne sait pas nécessairement que son profil a été classé, comparé ou filtré automatiquement.

L’interface peut paraître simple et fluide, alors que plusieurs opérations se déroulent en arrière-plan :

• extraction des informations du CV ;
• analyse des expériences ;
• recherche de mots-clés ;
• attribution d’un score ;
• classement des candidatures ;
• recommandation transmise au recruteur.

L’absence d’explication crée une asymétrie importante entre l’entreprise, qui connaît le fonctionnement général du système, et le candidat, qui en subit les effets.

Les risques invisibles derrière l’expérience utilisateur

Une interface fluide ne garantit pas que le système soit équitable. Les risques peuvent provenir des données d’entraînement, des critères retenus ou de la manière dont les résultats sont présentés au recruteur.

Un parcours de recrutement automatisé peut notamment entraîner :

• la reproduction de biais historiques ;
• l’exclusion de profils atypiques ;
• une mauvaise interprétation des interruptions de carrière ;
• la pénalisation de certaines formulations ;
• une confiance excessive dans le score produit ;
• l’impossibilité de corriger une donnée mal extraite.

Le design de l’outil destiné au recruteur joue également un rôle. Un score affiché en grand, sans explication ni niveau d’incertitude, peut être perçu comme une vérité objective.

Comment repenser le parcours avec une logique de transparence et de recours ?

Le Regulatory Thinking conduit à rendre le fonctionnement essentiel du parcours plus visible, sans exposer inutilement les secrets techniques du système.

Dès le dépôt de la candidature, une information claire peut préciser que l’IA participe à l’analyse du dossier. Le candidat peut ensuite vérifier les données extraites de son CV et corriger les erreurs avant l’évaluation.

Le parcours peut également prévoir :

• une explication générale des critères utilisés ;
• la distinction entre recommandation et décision finale ;
• un accès aux principales informations ayant influencé le résultat ;
• une procédure simple de contestation ;
• la possibilité de fournir un contexte complémentaire ;
• un canal de contact humain clairement identifié.

Du côté du recruteur, l’interface doit présenter le résultat comme une aide à la décision. Elle peut afficher les limites de l’analyse et encourager la consultation directe du dossier.

Ce que le Regulatory Thinking change pour le candidat, le recruteur et l’entreprise

Pour le candidat, cette approche améliore la compréhension du processus et facilite la correction d’une erreur. Elle réduit le sentiment de subir une décision opaque.

Pour le recruteur, elle crée un cadre plus clair pour utiliser la recommandation algorithmique. L’outil ne remplace pas son jugement et l’interface l’aide à repérer les situations nécessitant une vérification.

Pour l’entreprise, les bénéfices sont multiples :

• une meilleure maîtrise des risques ;
• des décisions plus faciles à expliquer ;
• une documentation plus solide ;
• une expérience candidat plus rassurante ;
• une utilisation plus cohérente de l’outil ;
• une confiance renforcée dans le processus.

Le Regulatory Thinking ne consiste donc pas à ajouter quelques mentions au formulaire. Il transforme l’ensemble du parcours, depuis la collecte des données jusqu’au recours.

Les pièges d’une conformité mal conçue

Une entreprise peut respecter formellement certaines obligations tout en proposant une expérience confuse ou décourageante. Lorsque la conformité est traitée comme une couche ajoutée au produit, elle risque de créer de nouvelles difficultés.

Le rôle du design est de rendre les protections visibles, compréhensibles et réellement utilisables.

Ajouter des mentions légales que personne ne comprend

Le premier réflexe consiste souvent à ajouter un long texte juridique dans une fenêtre, une bannière ou des conditions d’utilisation.

Cette solution protège rarement l’utilisateur. Elle transfère l’information sans garantir sa compréhension.

Une meilleure approche repose sur plusieurs niveaux :

• une information essentielle dans le parcours ;
• un vocabulaire simple ;
• des exemples adaptés au contexte ;
• un contenu détaillé accessible en complément ;
• une mise à jour visible lorsque le fonctionnement évolue.

La clarté ne signifie pas supprimer les précisions importantes. Elle consiste à les organiser pour permettre une lecture progressive.

Transformer la conformité en friction permanente

Certaines étapes supplémentaires sont nécessaires pour protéger l’utilisateur. Mais toutes les obligations ne doivent pas devenir des fenêtres bloquantes ou des cases à cocher.

Une accumulation de demandes peut produire de la fatigue et conduire à une validation automatique.

La bonne solution dépend du niveau de risque. Une décision sensible peut justifier une confirmation explicite, tandis qu’une information secondaire peut être intégrée de manière plus discrète dans le parcours.

Le Regulatory Thinking recherche ainsi une friction proportionnée : suffisamment forte pour protéger, sans empêcher inutilement l’usage.

Utiliser la transparence comme simple élément décoratif

Afficher un pictogramme « IA » ou une mention générique ne suffit pas à rendre un système transparent.

L’information doit aider l’utilisateur à comprendre le rôle réel de la technologie. Une interface affirmant simplement que le produit est « alimenté par l’intelligence artificielle » peut même servir davantage le marketing que la compréhension.

Une transparence utile précise :

• la tâche réalisée par l’IA ;
• les principales données utilisées ;
• la place de l’humain dans la décision ;
• les limites connues ;
• les actions disponibles en cas de problème.

Elle doit être reliée à un moyen de contrôle. Sans possibilité d’agir, l’information reste largement théorique.

Confier les décisions réglementaires uniquement aux juristes

Les juristes interprètent les règles et sécurisent les choix de l’organisation. Ils ne peuvent cependant pas décider seuls de leur traduction dans l’expérience utilisateur.

Une exigence réglementaire peut avoir plusieurs réponses possibles en matière de design. Le choix dépend du contexte, des comportements observés et des contraintes techniques.

La collaboration doit associer :

• les juristes pour l’interprétation des obligations ;
• les designers pour leur traduction dans le parcours ;
• les équipes techniques pour leur mise en œuvre ;
• les experts métier pour le contexte d’usage ;
• les responsables produit pour les arbitrages.

La conformité devient plus solide lorsqu’elle est construite collectivement plutôt que transmise sous la forme d’une validation finale.

Bloquer l’innovation par peur de prendre des risques

Le Regulatory Thinking ne cherche pas à supprimer tous les risques, ce qui serait souvent impossible. Il aide à les identifier, à les réduire et à documenter les décisions.

Une lecture trop défensive de la réglementation peut conduire à abandonner des fonctionnalités utiles ou à multiplier les procédures sans bénéfice réel.

À l’inverse, une prise de risque non maîtrisée peut exposer les utilisateurs et obliger l’entreprise à reconstruire son produit tardivement.

L’objectif est de trouver un équilibre entre :

• la valeur apportée par l’innovation ;
• la gravité des conséquences possibles ;
• les mesures de protection disponibles ;
• la capacité de superviser le système ;
• la réversibilité des décisions.

La réglementation devient alors un cadre de conception plutôt qu’une interdiction systématique d’expérimenter.

Le Regulatory Thinking impose une nouvelle organisation du travail

Intégrer la réglementation dès la conception modifie la manière dont les équipes collaborent. Les obligations ne peuvent plus être gérées dans un circuit parallèle, séparé des décisions produit.

Le Regulatory Thinking crée des points de rencontre réguliers entre les expertises, tout au long du cycle de vie du service.

Faire collaborer designers, juristes, équipes produit et data analyst

Chaque métier possède une partie des informations nécessaires.

Le juriste connaît les obligations. Le designer comprend les usages. Le spécialiste de la donnée maîtrise le fonctionnement du système. L’équipe produit connaît les objectifs commerciaux et les contraintes de livraison.

Une collaboration efficace permet de relier ces perspectives :

• le juriste identifie les droits à protéger ;
• le designer les transforme en parcours accessibles ;
• l’équipe data explique les capacités et les limites du modèle ;
• les développeurs évaluent la faisabilité ;
• le product manager organise les arbitrages.

Cette organisation réduit les incompréhensions et limite les modifications tardives.

Introduire des points de contrôle réglementaires dans les rituels produit

La conformité n’a pas besoin de créer un processus entièrement séparé. Elle peut être intégrée aux rituels déjà utilisés par les équipes.

Un contrôle peut être ajouté :

• pendant le cadrage du projet ;
• avant la validation d’une fonctionnalité sensible ;
• lors des design reviews ;
• avant un test utilisateur ;
• au moment de la mise en production ;
• après l’analyse d’un incident.

Ces points de contrôle doivent rester proportionnés au niveau de risque. Une fonctionnalité mineure ne nécessite pas le même examen qu’un système influençant l’accès à un emploi ou à un service essentiel.

Documenter les arbitrages sans alourdir inutilement les projets

La documentation est indispensable pour conserver la trace des décisions, mais elle ne doit pas devenir un exercice administratif déconnecté du produit.

Des formats simples peuvent suffire :

• une fiche de risque par fonctionnalité ;
• une ligne ajoutée dans le backlog ;
• un journal partagé des décisions ;
• une checklist intégrée à la design review ;
• un lien entre l’obligation et l’écran concerné.

La documentation doit être mise à jour au fil du projet, plutôt que reconstituée juste avant un audit. Elle devient alors un outil de pilotage et non une archive créée après coup.

Faire de la conformité une responsabilité collective

Le respect des règles ne repose pas uniquement sur le service juridique ou sur une personne chargée de la conformité.

Les designers doivent comprendre les conséquences de leurs choix. Les développeurs doivent signaler les limites techniques. Les équipes data doivent documenter le fonctionnement du système. Les responsables produit doivent intégrer les risques dans leurs arbitrages.

Cette responsabilité collective repose sur trois piliers :

• une culture réglementaire partagée ;
• des rôles clairement définis ;
• des procédures simples pour signaler un risque.

Le Regulatory Thinking ne transforme pas chaque collaborateur en expert du droit. Il donne à chacun les connaissances nécessaires pour reconnaître une décision sensible et solliciter les bonnes compétences au bon moment.

Après l’expérience utilisateur, concevoir l’expérience de confiance

Le Regulatory Thinking ne remplace pas le Design Thinking, il le complète. Concevoir une bonne expérience ne consiste plus seulement à rendre un produit utile, simple et agréable, mais aussi compréhensible, responsable et digne de confiance. 

Pour notre agence UX basée à Paris, cette évolution ouvre un nouveau champ de conception, où la réglementation devient un levier d’innovation. L’enjeu est désormais clair; créer des expériences qui répondent aux besoins des utilisateurs tout en protégeant leurs droits et leur capacité à garder le contrôle.