Qualifier une décision algorithmique avant de définir ses garanties

Suivre le traitement jusqu’à l’acte

La description commence par les données utilisées : informations déclarées, données récupérées, pièces et corrections. Elle suit les opérations : vérification, calcul, classement ou recommandation. Elle identifie ensuite ce qui est envoyé à l’usager et l’autorité qui le décide. Le projet peut comporter plusieurs étapes automatisées sans que chacune soit une décision ; leur effet cumulé doit cependant être examiné.

Un classement peut avoir une portée importante même s’il est nommé liste indicative. Si les agents ne traitent que les premiers dossiers et que les autres n’accèdent jamais à une place, l’ordre produit des conséquences réelles. La qualification doit donc regarder les usages, les délais et les marges de reprise. Une formule figurant dans le contrat ne démontre pas que la sortie serait sans influence.

L’article L. 311-3-1 du CRPA concerne une décision individuelle prise sur le fondement d’un traitement algorithmique. Il prévoit une mention explicite et la communication, sur demande, des règles définissant le traitement et de ses principales caractéristiques, sous les réserves prévues. Ce champ n’est pas limité aux modèles d’apprentissage. Un programme appliquant des règles déterministes peut également contribuer à une décision. ^[2]

La préparation décrit donc la part du traitement et celle de l’examen humain. Elle précise qui peut corriger une donnée, écarter une proposition et réexaminer le résultat. Le nom décision assistée n’est pas une preuve. Le service doit être capable de montrer les opérations réellement effectuées et les raisons de l’acte final.

Ne pas confondre les cadres juridiques

L’article 22 du RGPD vise les décisions fondées exclusivement sur un traitement automatisé, produisant des effets juridiques ou affectant une personne de manière similaire et significative. Il prévoit des exceptions et des garanties dans ses conditions. Cette qualification ne se confond pas avec celle du CRPA, qui peut concerner une contribution algorithmique sans exclusivité. L’examen doit donc traiter les deux questions séparément. ^[1]

La loi Informatique et libertés, en son article 47, encadre les décisions automatisées et prévoit notamment une exception pour certaines décisions administratives individuelles sous conditions. Elle impose la maîtrise du traitement et de ses évolutions afin d’expliquer de manière détaillée et intelligible son application à la personne. Le texte prévoit aussi qu’une décision sur un recours administratif ne peut être prise sur le seul fondement d’un traitement automatisé de données personnelles. ^[3]

Cette exception ne signifie pas que toute décision administrative automatique serait autorisée par principe. Le service doit vérifier les conditions relatives au CRPA, aux données concernées et aux garanties. Il doit notamment identifier la nature des données et le régime de la décision. Ces règles doivent être appliquées au service concerné : l’objectif de rapidité ne suffit pas à autoriser une décision automatisée.

Le règlement IA possède encore une autre qualification : système d’IA, destination et catégorie de risque. Les articles 6 et l’annexe III doivent être lus dans leur version actuelle, avec le calendrier modifié de l’article 113. La version consolidée du 27 juillet 2026 reporte les sections haut risque concernées à 2027 ou 2028 selon la catégorie. Ce calendrier ne suspend pas les obligations propres au RGPD et au droit administratif. ^[5]

L’arrêt SCHUFA du 7 décembre 2023 précise pourquoi l’interposition d’un autre décideur ne suffit pas à exclure l’article 22. Le score de solvabilité établi par une société était transmis aux banques et déterminait pratiquement l’octroi du crédit. La Cour qualifie alors l’établissement de cette valeur de décision automatisée. Elle renvoie au juge national l’examen d’une éventuelle exception légale et des autres conditions du RGPD. Cette solution concerne les faits bancaires étudiés, mais conduit à examiner, par analogie raisonnée, si un classement municipal détermine réellement la décision annoncée comme humaine. La signature finale ne démontre pas une appréciation autonome lorsque l’agent ne dispose ni des moyens ni de l’autorité de modifier le résultat. ^[6]

Trois fonctionnements dans une attribution de places

Le cas est fictif. Une commune attribue des places dans une activité disposant d’une capacité limitée. Son cadre local fixe des critères et prévoit l’examen de certaines situations particulières. Un logiciel calcule des points à partir des demandes. La note ne crée pas les critères légaux de cette activité ; elle utilise ce scénario pour analyser les effets de trois organisations possibles.

Dans le premier fonctionnement, le calcul repère les pièces manquantes et présente un score. Un agent vérifie les faits, traite les justificatifs équivalents et examine les situations prévues par le cadre applicable. L’autorité adopte ensuite une décision expliquée. Le traitement contribue à l’acte et doit être examiné au titre du CRPA. L’intervention humaine ne permet pas d’effacer cette contribution de la présentation faite à l’usager. ^[2]

Dans le deuxième fonctionnement, la liste est envoyée à un agent qui accepte toutes les propositions en quelques secondes. Le projet affirme que la présence de cet agent exclut toute décision automatisée. Cette conclusion est insuffisamment démontrée : le service doit examiner la substance de la revue, les moyens disponibles et la capacité réelle de changer le résultat. Une signature finale peut masquer un fonctionnement dans lequel le score détermine entièrement l’issue.

Dans le troisième fonctionnement, le système envoie automatiquement les réponses selon le classement. Le service doit alors examiner la décision exclusivement automatisée et ses effets, les exceptions pertinentes et leurs garanties. La contrainte de capacité ne fournit pas à elle seule une justification juridique. La transparence, la maîtrise du traitement et la possibilité de recours doivent être organisées pour le régime applicable. ^{[1] [3]}

Une erreur apparaît dans les trois scénarios : une donnée relative à la situation familiale est mal enregistrée. Le logiciel applique correctement sa règle à une donnée inexacte. Ce cas montre pourquoi l’audit ne peut se limiter à vérifier le code du calcul. Il doit relier la qualité des données, les corrections et l’acte. Une formule exacte peut produire une réponse injustifiée lorsqu’elle repose sur un fait faux ou sur une règle mal qualifiée.

Le service reconstitue enfin le résultat individuel. Il identifie la version des critères, les données utilisées, le score et les interventions effectuées. L’article R. 311-3-1-2 prévoit notamment la communication du degré et du mode de contribution, des données et sources, des paramètres et de leur éventuelle pondération appliqués à la situation, ainsi que des opérations. Une description générale du logiciel ne répond pas à cette exigence individualisée. ^[4]

La qualification est revue lorsqu’une fonctionnalité change. Un contrôle de complétude peut devenir un classement de priorité si le service utilise désormais ses résultats pour ordonner les dossiers. Une rédaction de courrier peut devenir déterminante si la conclusion générée est reprise sans examen. La fiche de changement doit donc demander quel effet nouveau la sortie produit sur la personne. Cette vérification porte sur l’usage décidé par le service, pas seulement sur la mise à jour technique annoncée par le fournisseur. Elle empêche de conserver une ancienne qualification lorsque la chaîne de décision a évolué.

Examiner les limites du contrôle et de l’explication

La capacité de corriger doit être concrète. L’agent doit avoir accès aux informations utiles, disposer d’un mandat et savoir comment reprendre une sortie. Si toute modification exige une intervention du fournisseur impossible à obtenir pendant le traitement, le contrôle est limité. Le projet doit distinguer une correction de donnée, une application d’exception et une modification de règle ; ces opérations peuvent relever de compétences différentes.

L’explication doit correspondre au fonctionnement utilisé. Un texte rédigé après coup pour rendre le résultat plausible n’est pas nécessairement la description des opérations ayant conduit à la décision. Le service conserve donc les éléments déterminants et les versions pertinentes. La trace ne doit pas devenir une conservation illimitée de toutes les données : le besoin d’explication doit être articulé avec les règles de protection et de durée applicables.

L’objection à cette documentation est le volume des décisions. Un service qui traite de nombreuses demandes peut difficilement produire une analyse narrative complète pour chacune. Il peut concevoir un relevé structuré des faits, paramètres et interventions, puis une présentation intelligible adaptée aux demandes. L’organisation doit cependant démontrer que ces éléments existent et peuvent être reliés à la personne, plutôt que promettre une explication qu’il faudrait reconstruire sans trace.

Une autre objection consiste à opposer automatiquement déterminisme et opacité. Un traitement déterministe peut être compliqué et difficile à expliquer ; un outil d’IA peut être limité à une tâche non décisionnelle. Les garanties se construisent à partir des opérations, de la destination et des effets. La seule famille technique ne remplace pas la qualification juridique de la décision ni l’examen du circuit humain.

Une qualification ouvre un régime de garanties

Le dossier de qualification décrit l’acte, les effets, les données, la contribution du traitement et les interventions humaines. Il examine séparément le CRPA, le RGPD, la loi Informatique et libertés et, si le système relève de son champ, le règlement IA. Cette séparation rend les conclusions lisibles : une absence de décision exclusivement automatisée n’efface pas nécessairement les obligations de transparence administrative.

Dans le cas fictif, le score et sa version doivent être traçables, la correction d’une donnée doit pouvoir conduire à un réexamen et le traitement du recours doit rester distinct de l’automatisation initiale. Ces garanties répondent à des problèmes précis. Elles ne consistent pas à ajouter un message général indiquant qu’un humain reste responsable sans lui donner les moyens d’exercer ce rôle.

La réponse à la question initiale est de qualifier le fonctionnement réel avant de choisir les garanties. Le service suit la donnée jusqu’à l’acte et examine les effets sur la personne. Il peut alors distinguer un calcul préparatoire d’une contribution déterminante et d’une décision exclusivement automatisée. Cette méthode permet d’expliquer ce que le système fait, ce que l’autorité décide et comment l’usager peut faire corriger une erreur.