Décision automatisée et RGPD : 825 millions d'euros pour une validation humaine absente

Une décision automatisée qui prive un chauffeur de son compte, sans qu'un humain ne l'ait relue : l'autorité néerlandaise, en coopération avec la CNIL, a chiffré le manquement à 824 990 000 euros. La validation humaine tient dans un article du RGPD, et son absence se chiffre.

Le 24 août 2026, la CNIL a annoncé une sanction de 824 990 000 euros prononcée contre Uber par l'autorité néerlandaise de protection des données, en coopération avec elle. Le motif tient en une phrase : des désactivations de comptes de chauffeurs qualifiées de décisions individuelles automatisées, prises sans validation humaine, sur le fondement de l'article 22 du RGPD.

Ce que la décision reproche

Uber désactivait des comptes en cas de suspicion de fraude ou de notation basse. Un chauffeur désactivé perd son revenu du jour au lendemain, sans savoir quelle règle l'a fait basculer. L'autorité néerlandaise a estimé que ces décisions étaient prises par le traitement lui-même, sans qu'une personne les examine pour de bon. La même procédure avait déjà donné lieu à deux sanctions : 10 millions d'euros en décembre 2023 pour un défaut d'information des chauffeurs, 290 millions en juillet 2024 pour des transferts de données hors Union européenne, toujours selon la page de la CNIL du 24 août 2026.

Ce que dit l'article 22

L'article 22 du RGPD reconnaît à toute personne le droit de ne pas faire l'objet d'une décision fondée exclusivement sur un traitement automatisé, y compris le profilage, qui produit des effets juridiques la concernant ou l'affecte de façon significative. Trois portes de sortie existent : l'exécution d'un contrat, une autorisation prévue par le droit de l'Union ou d'un État membre, le consentement explicite. Aucune de ces portes ne dispense d'un examen sérieux de la décision quand la personne la conteste. Savoir si votre logiciel entre dans ce périmètre se tranche avec votre conseil, pas dans un article de journal : la frontière entre une aide à la décision et une décision automatisée dépend du détail de vos écrans.

Une case cochée ne fait pas une relecture

La CNIL, dans sa note de juillet 2026 sur l'IA agentique et la protection des données personnelles, rappelle la lecture retenue par la Cour de justice dans l'affaire SCHUFA du 7 décembre 2023 : l'intervention humaine doit être réelle, effective, et exercer une influence sur la décision finale. La note ajoute qu'« une validation purement formelle ou automatique est insuffisante ». Un salarié qui clique sur « valider » cinquante fois par heure, sur un écran qui affiche déjà la réponse et ne propose aucune autre issue, ne constitue pas la garantie que le texte exige. La même note observe que la multiplication des agents rend l'appréciation du degré réel de supervision délicate, ce qui vaut pour toute chaîne de traitements où personne ne sait plus qui a tranché.

Ce que cela change quand vous faites construire un logiciel

Si votre application décide seule de refuser un dossier, de suspendre un accès, de fixer un tarif personnalisé ou de classer un candidat, vous devez pouvoir montrer où un humain intervient, avec quelles informations sous les yeux, et ce qu'il peut changer. Cette exigence se traduit en écrans, en droits d'accès et en règles de recours, donc en lignes du cahier des charges, écrites avant la construction. La rajouter après coup revient à rouvrir le parcours entier de l'utilisateur, souvent la partie la plus chère d'un produit. C'est le genre de sujet que les questions qui fâchent font remonter en une heure de travail, quand elles sont posées au bon moment.

Un outil de génération à prompt ne pose aucune de ces questions. Vous décrivez un écran, il le produit, et rien dans la conversation ne vous demande qui tranche quand la machine se trompe. C'est vrai des générateurs les plus rapides du marché, y compris ceux dont nous détaillons les crédits ce matin, et ce n'est pas un défaut de leur part : ils vendent de la vitesse de prototypage. Chez Maestro, chaque document proposé par les agents s'arrête sur un « Ça me va » de votre part. Cette gate porte sur les documents du projet, pas sur les décisions que votre application prendra une fois en service. Les deux relectures sont distinctes, et la seconde reste à concevoir, produit par produit.

En pratique

Prenez la liste des actions que votre logiciel exécute sans qu'on le lui demande : refus, suspensions, relances, scores, priorités. Pour chacune, écrivez trois lignes. Qui peut la contester, par quel chemin. Qui la réexamine, avec quel délai. Quelles informations cette personne voit au moment de trancher, et ce qu'elle a le pouvoir de modifier. Si une ligne reste vide, le sujet est ouvert, et il vaut mieux le découvrir devant un document qu'après une réclamation. La relecture organisée comme une architecture coûte quelques heures au moment du cadrage ; l'autre chemin est celui qu'a pris Uber, et son montant figure en haut de cette page.