XXI.INSTITUT

XXI Institut · Recherche et doctrine

Choisir un usage d’IA à partir de ses effets sur les usagers

Note de recherche · Références examinées le 15 octobre 2026

1 644 mots · 4 références · Note juridique

Un service public peut utiliser un même outil d’intelligence artificielle pour reformuler une réponse, orienter une demande ou suggérer le refus d’une prestation. Ces usages ne produisent pas les mêmes effets, même lorsque l’interface semble identique. Comment choisir un premier usage sans confondre simplicité apparente, utilité opérationnelle et maîtrise des conséquences juridiques ?

La sélection doit partir de la tâche, des données nécessaires et de la place de la sortie dans la décision. Les règles de protection des données et de transparence des décisions administratives fournissent des points d’appui précis. Le cas fictif d’un service d’aide municipale montre comment retenir un usage limité et écarter un usage dont les garanties ne sont pas démontrées.

Décrire une tâche plutôt qu’acheter une promesse

La formule assistant intelligent ne décrit ni une activité ni un résultat contrôlable. Une fiche d’usage doit indiquer ce qui entre dans le système, ce qu’il produit, qui utilise cette sortie et ce qui se passe lorsqu’elle est incorrecte. Reformuler une information déjà vérifiée diffère de rechercher la règle applicable à un dossier. Classer des courriels diffère de déterminer une priorité lorsque cette priorité affecte l’accès au service. La précision du verbe est donc un premier instrument de qualification.

Le bénéfice attendu doit être lié à un problème observé. Si les agents perdent du temps à retrouver des informations publiques stables, un outil de recherche peut être pertinent. Si les délais proviennent surtout de pièces manquantes, la génération de réponses peut augmenter la quantité de messages sans résoudre le blocage. La sélection compare l’IA avec des alternatives ordinaires : formulaire simplifié, base documentaire mieux organisée ou changement du circuit de validation.

Une tâche comprend également ses exceptions. Une réponse standard peut convenir à une demande générale, mais devenir dangereuse lorsqu’un usager décrit une urgence, une situation de handicap ou une difficulté de compréhension. La fiche indique donc les conditions de retrait de l’outil et de transfert vers un professionnel. Cette règle ne doit pas dépendre uniquement de la capacité du modèle à reconnaître lui-même ses erreurs.

La démonstration d’utilité doit rester séparée de la démonstration de conformité. Un gain de temps ne fournit pas une base juridique pour traiter des données personnelles. L’article 6 du RGPD oblige à identifier un fondement approprié ; pour une mission d’intérêt public, son paragraphe 3 renvoie au droit de l’Union ou de l’État membre. L’invocation abstraite du service public ne suffit donc pas à établir que toute réutilisation de dossiers est autorisée. [1]

Mesurer la place de l’outil dans la décision

Il faut suivre la sortie jusqu’à ses effets. Une suggestion utilisée pour préparer une lettre peut devenir déterminante si l’agent la reprend sans examen. Un classement présenté comme indicatif peut fixer de fait l’ordre de traitement lorsque les dossiers situés en bas ne sont jamais revus. L’analyse porte donc sur le fonctionnement réel, y compris les contraintes de temps et les incitations à accepter les propositions du système.

L’article 22 du RGPD encadre les décisions fondées exclusivement sur un traitement automatisé qui produisent des effets juridiques ou affectent de manière similaire et significative une personne. Il prévoit des exceptions et des garanties dans les conditions du texte. La présence d’un bouton de validation ne permet pas, à elle seule, de conclure qu’une décision échappe à cette qualification. Il faut examiner si l’intervention humaine possède une substance et si l’agent peut réellement réexaminer le dossier. [2]

Pour une décision individuelle prise sur le fondement d’un traitement algorithmique, l’article L. 311-3-1 du code des relations entre le public et l’administration prévoit une mention explicite et la communication, sur demande, des règles définissant le traitement et de ses principales caractéristiques, sous réserve des limites prévues par le code. Cette obligation ne se confond pas avec une notice générale sur l’utilisation d’un outil dans le service. Elle rattache la transparence à la décision concernée. [4]

Le choix du premier usage doit donc intégrer la capacité d’expliquer la sortie. Si le service ne peut distinguer les informations issues du dossier, les règles applicables et les éléments générés, il ne maîtrise pas suffisamment le raisonnement. Un usage documentaire limité à un corpus identifié peut être plus facile à contrôler qu’une production ouverte. Cette préférence est méthodologique : elle ne garantit pas, par elle-même, la conformité d’un produit particulier.

Trois usages envisagés dans une aide municipale

Le cas est fictif. Une commune examine des demandes d’aide facultative dans un cadre local déjà défini. Son service envisage trois usages : rédiger des réponses aux questions générales, vérifier la présence des pièces et proposer un avis sur l’éligibilité. Les mêmes agents interviennent dans ces tâches, mais les informations nécessaires et les conséquences des erreurs sont différentes. Les règles substantielles de l’aide ne sont pas déterminées par cette note.

Pour les questions générales, le service dispose d’une documentation publique validée. L’outil peut préparer une réponse à partir de ce corpus, sans accès aux dossiers individuels. Un agent vérifie la source, la date et l’adéquation à la question avant envoi. Les réponses concernant une situation personnelle sont retirées de ce périmètre. Le bénéfice attendu est limité : accélérer la préparation d’une information générale, sans annoncer un droit à une prestation.

Pour la présence des pièces, l’outil devrait accéder aux documents déposés. Cette tâche paraît simple, mais une erreur peut provoquer une demande de pièce inutile ou retarder un dossier complet. Le service compare l’IA avec une liste de contrôle structurée. Il découvre que plusieurs pièces peuvent être remplacées par des justificatifs équivalents. Un système qui recherche un intitulé exact risquerait de déclarer incomplets des dossiers recevables. Le scénario est conservé uniquement comme expérimentation hors décision réelle.

Pour l’éligibilité, le modèle devrait interpréter des faits, appliquer des critères et traiter les situations exceptionnelles. Une proposition de refus aurait un effet direct sur l’usager si elle était reprise automatiquement. Le service écarte ce premier usage parce que sa capacité à expliquer les suggestions et à garantir un examen réel n’est pas démontrée. Cette décision n’affirme pas que toute aide algorithmique est interdite ; elle constate que le projet décrit ne possède pas encore les garanties nécessaires. [2] [4]

La fiche du premier usage précise les données exclues : noms, adresses, justificatifs financiers et informations de santé. Les agents utilisent des questions générales ou des exemples fabriqués. Si une question contient une situation personnelle, elle est traitée dans le circuit habituel. La minimisation prévue par l’article 5 du RGPD devient ainsi une contrainte de conception concrète : l’outil ne reçoit pas des données simplement parce qu’elles existent dans le service. [1]

Le pilote mesure la pertinence de la réponse, la présence d’une source exacte, le temps de correction et la capacité à reconnaître une question hors périmètre. Un texte bien rédigé mais fondé sur une règle périmée est classé comme échec. Le service ne calcule donc pas seulement le nombre de messages produits. Il vérifie si la préparation assistée améliore réellement le travail d’information sans créer une nouvelle charge de rectification.

Comparer les erreurs et leurs conséquences

Une grille de risques doit distinguer la probabilité d’erreur de sa gravité. Une erreur de formulation dans une réponse générale peut être corrigée avant envoi. Une erreur de priorité peut prolonger l’attente d’une personne vulnérable. Une erreur d’éligibilité peut produire un refus injustifié. Même si les fréquences semblaient proches dans un test, la décision d’usage pourrait différer parce que les effets sur les personnes ne sont pas comparables.

Le contrôle humain n’est pas un remède universel. Il exige du temps, une compétence et l’accès aux éléments nécessaires. Un agent ne peut vérifier une règle dont la source n’est pas fournie, ni corriger une erreur discrète dans un domaine qu’il ne connaît pas. Le projet doit donc calculer le coût du contrôle et définir qui peut arrêter l’utilisation. Une organisation qui mesure seulement le temps de génération sous-estime le travail indispensable à une sortie fiable.

L’objection consiste à dire qu’un périmètre trop étroit réduit le bénéfice de l’IA. C’est possible. Un premier usage limité permet toutefois de vérifier des capacités précises : recherche dans le corpus, refus de répondre hors périmètre et traçabilité des corrections. Si ces capacités ne sont pas démontrées sur une tâche modeste, élargir immédiatement le système à une décision individuelle augmente l’exposition sans apporter de preuve supplémentaire.

La qualification au titre du règlement européen sur l’intelligence artificielle doit faire l’objet d’un examen distinct du système et de sa destination. Tout usage public n’est pas automatiquement à haut risque. Le RGPD et le CRPA s’appliquent selon leurs conditions propres ; les autres obligations, dont celles du règlement sur l’IA, exigent une qualification distincte du système et de sa destination.

L’article 25 du RGPD oblige à intégrer la protection des données dès la conception et par défaut. Dans le cas décrit, exclure les dossiers individuels du premier usage est donc plus solide qu’une consigne demandant aux agents de faire attention après l’ouverture générale des accès. Le périmètre autorisé doit être porté par les réglages, les habilitations et le contrat, autant que par une instruction écrite. [3]

Retenir le périmètre que le service peut contrôler

La décision de sélection prend la forme d’une fiche courte : tâche retenue, corpus autorisé, données exclues, utilisateur responsable, contrôle avant envoi et critères d’arrêt. Les usages écartés sont décrits avec le motif de l’écart, afin d’éviter qu’ils réapparaissent discrètement au cours du pilote. Dans le cas municipal, la rédaction d’informations générales est retenue ; l’éligibilité demeure dans le circuit habituel.

La réponse à la question initiale est de choisir un usage dont les conséquences et les contrôles sont compris. Le bénéfice doit être démontré sur une tâche définie, et la conformité examinée pour les données et les décisions réellement concernées. Cette démarche permet de tester une aide utile sans confondre un résultat linguistique convaincant avec une décision juridiquement fondée. L’élargissement éventuel doit reposer sur de nouvelles preuves, pas sur la seule satisfaction des premiers utilisateurs.

Notes et références

  1. Parlement européen et Conseil de l’Union européenne. Règlement (UE) 2016/679 — principes et licéité. 2016-04-27. Articles 5, 6 et 9. Retour au texte ↩
  2. Parlement européen et Conseil de l’Union européenne. Règlement (UE) 2016/679 — droits des personnes. 2016-04-27. Articles 12 à 22. Retour au texte ↩
  3. Parlement européen et Conseil de l’Union européenne. Règlement (UE) 2016/679 — responsabilités et sécurité. 2016-04-27. Articles 24 à 39. Retour au texte ↩
  4. Législateur français — Légifrance. Code des relations entre le public et l’administration, article L. 311-3-1. 2016-10-09. Article L. 311-3-1. Retour au texte ↩