Une décision assistée par algorithme doit pouvoir être expliquée à la personne concernée, pas seulement à une équipe technique. L’article distingue documentation, explicabilité, traçabilité et supervision humaine.
La transparence des algorithmes n'est plus une option depuis que l'AI Act européen est entré en application. En 2026, les entreprises qui utilisent des systèmes d'IA doivent pouvoir expliquer leurs décisions automatisées — et prouver qu'elles le font. Voici ce que ça implique concrètement.
Ce que la transparence des algorithmes signifie en pratique
La transparence des algorithmes, c'est la capacité d'une organisation à expliquer pourquoi un système automatisé a pris une décision donnée. Pas en termes techniques réservés aux data scientists. En termes compréhensibles par la personne concernée.
Un algorithme de scoring refuse un prêt. Un outil de recrutement filtre un CV. Un système de recommandation médicale oriente un traitement. Dans chacun de ces cas, la personne touchée a le droit de savoir sur quelle base la décision a été faite — et de la contester si elle l'estime injuste.
En pratique, ça suppose deux choses distinctes. D'abord, que le système soit techniquement auditable : les données utilisées, les pondérations, les critères d'exclusion doivent être documentés et reconstituables. Ensuite, que l'organisation soit capable de traduire ce fonctionnement en langage accessible — pour un service juridique, un représentant du personnel, ou un client qui conteste une décision.
Ces deux dimensions ne vont pas de soi. Beaucoup d'entreprises maîtrisent la première et négligent la seconde. C'est précisément là que les régulateurs attendent des progrès.
L'AI Act en vigueur : les obligations concrètes pour les systèmes à haut risque
Le Règlement (UE) sur l'intelligence artificielle — l'AI Act — est entré en vigueur en août 2024. Ses obligations s'appliquent progressivement : les premières interdictions étaient effectives dès février 2025, les exigences sur les systèmes à haut risque s'étendent jusqu'en 2027.
Pour les systèmes classés à haut risque — recrutement, crédit, éducation, administration de la justice, gestion des travailleurs — les obligations sont précises :
- Documentation technique continue : tenir à jour un dossier décrivant le fonctionnement du système, les données d'entraînement, les mesures de performance et les limites connues.
- Traçabilité des décisions : enregistrer les événements significatifs pendant le fonctionnement, de façon à reconstituer le raisonnement ayant conduit à un résultat donné.
- Information des opérateurs : indiquer clairement qu'un système d'IA est utilisé et expliquer ses capacités et ses limites aux personnes qui l'opèrent au quotidien.
- Surveillance humaine effective : mettre en place des mécanismes permettant à un humain d'intervenir, de corriger ou de désactiver le système en cas de dérive.
- Gestion des risques documentée : identifier, analyser et atténuer les risques tout au long du cycle de vie du système — pas uniquement à la mise en production.
Si votre organisation développe ou déploie un tel système, ces exigences vous concernent directement. L'AI Act distingue les fournisseurs (qui conçoivent le système) des déployeurs (qui l'utilisent dans leurs processus). En tant que déployeur, vous avez des obligations propres, indépendamment de ce que fait votre prestataire technique.
L'explicabilité IA : trois niveaux à distinguer
L'explicabilité IA est souvent traitée comme un bloc homogène. En réalité, trois niveaux coexistent — et les obligations comme les méthodes ne sont pas les mêmes.
L'explication globale du modèle
Elle décrit comment le modèle fonctionne dans l'ensemble : quelles variables ont le plus de poids, quel type de relation il a appris entre les entrées et les sorties. C'est le niveau attendu dans la documentation technique pour les autorités de contrôle et les auditeurs internes.
L'explication locale d'une décision
Elle répond à : pourquoi ce modèle a-t-il pris cette décision pour cette personne précise ? C'est ce que le RGPD exige quand une décision automatisée a un effet significatif sur un individu. Des outils comme LIME ou SHAP produisent ce type d'explication de façon standardisée et auditée.
L'explication contrefactuelle
Elle répond à : qu'est-ce qui aurait changé pour que la décision soit différente ? C'est le niveau le plus utile pour la personne concernée — "si votre ancienneté avait été de X années, le résultat aurait été différent". C'est aussi le plus exigeant à produire, et celui que les régulateurs considèrent comme l'horizon à atteindre pour les systèmes à fort impact.
RGPD article 22 : le droit à l'explication existe depuis 2018
Avant même l'AI Act, le RGPD posait un principe clair : toute personne a le droit de ne pas faire l'objet d'une décision fondée exclusivement sur un traitement automatisé, quand cette décision produit des effets juridiques ou des effets significatifs comparables.
Trois exceptions existent à ce droit : le consentement explicite, la nécessité contractuelle, ou une autorisation légale spécifique. Dans les deux premiers cas, l'organisation doit permettre à la personne d'obtenir une intervention humaine, d'exprimer son point de vue et de contester la décision.
En pratique, beaucoup d'entreprises sont en infraction sur ce point sans le savoir. Les algorithmes de scoring client, de filtrage de candidatures ou de pilotage de la charge de travail tombent souvent dans ce champ — et aucune procédure de contestation humaine n'a été prévue au moment du déploiement.
Un contrôle CNIL ne commence pas forcément par un audit technique. Il peut commencer par la question : "Montrez-moi comment un employé peut contester la décision de votre outil de planification." Si la réponse est "ça n'existe pas encore", le risque est réel.
Quatre erreurs fréquentes dans la mise en conformité
- Confondre documentation et explicabilité. Un cahier des charges technique ne suffit pas. L'explicabilité implique de pouvoir répondre à une personne non technicienne, pas seulement à un auditeur spécialisé.
- Sous-estimer le périmètre concerné. L'AI Act ne couvre pas uniquement les LLM grand public. Tout système d'aide à la décision dans les domaines listés comme à haut risque est concerné, y compris un outil interne de planification des équipes ou de notation des sous-traitants.
- Supposer que la conformité incombe au seul prestataire. Si vous achetez ou louez un système d'IA, vous êtes déployeur — et vous avez des obligations propres. Votre contrat avec le fournisseur ne vous en exonère pas.
- Traiter la conformité comme un projet ponctuel. La documentation, la traçabilité et la surveillance humaine sont des obligations continues. Un rapport produit une fois pour une certification ne constitue pas une démarche de conformité pérenne.
Ce que ça implique pour votre organisation dès maintenant
La première étape est une cartographie : quels systèmes d'IA utilisez-vous actuellement — recrutement, service client, analyse de risques, personnalisation, gestion opérationnelle — et lesquels tombent dans les catégories à haut risque définies par l'AI Act.
La deuxième étape est d'identifier qui est responsable de l'explicabilité dans votre structure. Ce n'est pas une question purement technique. Elle touche simultanément les équipes juridiques, les RH, les directions métier et les équipes data. Sans propriétaire clairement désigné, la conformité reste un angle mort.
La troisième étape est la formation. Pas sur le code des modèles, mais sur ce que signifient les obligations en termes opérationnels : comment répondre à une demande d'explication d'une personne concernée, comment documenter une décision automatisée, comment construire une procédure de contestation humaine qui fonctionne vraiment.
C'est exactement le type de compétences couvertes dans nos formations IA, certifiées Qualiopi et finançables via le CPF. Elles s'adressent aux équipes qui déploient et utilisent des outils d'IA — pas uniquement aux développeurs. Disponibles à Marseille et en distanciel.
Pour évaluer votre situation et voir quelle formation correspond à votre contexte, contactez-nous directement.
À lire aussi :