France Travail : quand l'IA opaque profile 6 millions de chômeurs

Le 20 juillet 2026, La Quadrature du Net et Radio France révèlent ce que France Travail n'avait pas jugé utile de rendre public : depuis au moins le 1er janvier 2026, un algorithme classe chaque mois plus de 6 millions de demandeurs d'emploi — dont les allocataires du RSA désormais obligatoirement inscrits — en deux catégories : 'suspect' ou 'non suspect'. Son nom ? Le Ciblage du Contrôle de la Recherche d'Emploi (CRE). Son fonctionnement ? Entraîné sur 60 000 contrôles passés, il évalue chaque profil sur 26 variables. Son code source ? Inaccessible. Ses biais ? Incontrôlables.

Derrière l'indignation légitime se cache une leçon architecturale que les directeurs juridiques, DSI et associés gérants de cabinets d'avocats auraient tort d'ignorer. Non pas parce que leurs outils IA font la même chose — mais parce que rien, dans un déploiement SaaS standard ou une IA mal gouvernée, ne garantit qu'ils ne le pourraient pas.

CRE : une radiographie de ce que l'IA sans gouvernance produit

26 variables, 60 000 contrôles, zéro transparence

L'algorithme CRE n'est pas une bizarrerie bureaucratique. C'est un système de scoring automatisé de population à grande échelle, déployé sur l'une des bases de données administratives les plus sensibles de France. Ses caractéristiques techniques méritent d'être examinées précisément, car elles constituent une liste de contrôle en creux de tout ce qu'un déploiement IA responsable doit éviter.

Ce que l'on sait sur CRE :

Le problème central n'est pas que France Travail utilise un algorithme. C'est qu'elle utilise un algorithme à haut risque — au sens exact de l'AI Act, qui classe explicitement les systèmes d'évaluation et de scoring des personnes physiques dans le cadre de l'emploi comme systèmes à haut risque (Annexe III) — sans respecter les obligations qui en découlent.

L'AI Act : une échéance symboliquement dépassée

L'article 50 de l'AI Act impose des obligations de transparence renforcées pour les systèmes à haut risque. L'échéance pour la mise en conformité de ces systèmes était fixée au 2 août 2026 — soit treize jours après la révélation de l'affaire. France Travail se retrouve donc dans la position inconfortable d'avoir été exposée publiquement à la veille même de l'entrée en vigueur pleine des obligations qu'elle violait structurellement.

Ce timing n'est pas une coïncidence éditoriale. Il signale que la période de grâce réglementaire accordée aux acteurs publics comme privés pour se mettre en conformité est terminée. L'heure des audits est arrivée — qu'on les ait préparés ou non.

Le biais algorithmique entraîné sur des biais historiques

La nature même des données d'entraînement pose un problème épistémique fondamental. Un modèle entraîné sur 60 000 contrôles passés apprend, par construction, à reproduire les patterns de ciblage des contrôleurs humains précédents. Si ces contrôleurs ciblaient davantage certains profils démographiques, géographiques ou socio-économiques — qu'il s'agisse d'un biais conscient ou systémique — l'algorithme amplifie et automatise ce biais à l'échelle de millions de personnes.

C'est ce que les chercheurs en fairness ML appellent le feedback loop bias : le modèle prédit qui sera contrôlé en se basant sur qui a été contrôlé, renforçant les inégalités de traitement existantes tout en leur conférant l'apparence d'une objectivité mathématique. Sans accès au code source, sans documentation des features engineering, sans test d'équité publié, il est rigoureusement impossible de savoir si CRE discrimine — et dans quelle mesure.

Pourquoi cela vous concerne directement

L'opacité algorithmique n'est pas réservée au secteur public

Il serait confortable de traiter l'affaire France Travail comme une pathologie propre aux institutions publiques lourdes, imperméables à la modernité réglementaire. Ce serait une erreur d'analyse.

Nombre de directions juridiques et de cabinets d'avocats déploient aujourd'hui des outils IA — pour la recherche jurisprudentielle, la rédaction contractuelle, l'analyse de risques, la due diligence — dans des conditions architecturales qui rendent impossible tout audit réel de leur comportement. La question n'est pas philosophique : elle est pratique et réglementaire.

Concrètement, posez-vous ces questions sur vos outils IA actuels :

• Savez-vous exactement quelles données alimentent le modèle utilisé pour une analyse de jurisprudence ou une évaluation de risque contractuel ?
• Pouvez-vous produire un log complet de la chaîne de raisonnement d'une décision assistée par IA, si un client ou une juridiction vous le demande ?
• Un auditeur tiers peut-il inspecter l'orchestration, les index et les paramètres de votre système sans passer par votre fournisseur SaaS ?
• Les données complètes de vos clients — leurs dossiers, leurs échanges, leurs stratégies — transitent-elles par des serveurs dont vous n'êtes pas l'opérateur ?

Si la réponse à l'une de ces questions est 'non' ou 'je ne sais pas', vous avez un angle mort de conformité.

Le secteur juridique sous AI Act : systèmes à haut risque par défaut

L'AI Act ne se limite pas aux algorithmes de ciblage des chômeurs. Tout système IA utilisé pour assister des décisions juridiques substantielles — évaluation des chances de succès d'un litige, scoring de risque contractuel, analyse de position dans une négociation — entre potentiellement dans la catégorie haut risque au sens de l'Annexe III (accès à la justice, administration de la loi).

Cela implique des obligations concrètes pour les cabinets déployant ces outils :

• Documentation technique du système et de ses limites
• Évaluation de conformité avant déploiement
• Mécanisme de supervision humaine documenté
• Traçabilité des outputs permettant un audit a posteriori
• Déclaration si le système est fourni dans un contexte B2B par un fournisseur tiers

Un cabinet qui utilise un outil SaaS de recherche juridique ou d'analyse contractuelle sans avoir vérifié que son fournisseur satisfait ces obligations n'est pas simplement dans une zone grise réglementaire. Il est potentiellement co-responsable au sens de l'AI Act, en tant que déployeur.

L'architecture comme réponse, pas comme marketing

Ce que 'souveraineté' signifie vraiment (et ce que ça ne signifie pas)

L'affaire France Travail a relancé le débat sur la souveraineté des données avec une intensité compréhensible. Mais il faut être précis sur ce que ce terme recouvre dans le contexte d'une IA déployée dans un cabinet d'avocats — sous peine de confondre un argument marketing avec une garantie technique.

La souveraineté ne signifie pas : que le cabinet n'utilise jamais un fournisseur LLM externe. La réalité des architectures modernes est plus nuancée. Des outils comme RAGbase Legal peuvent tout à fait envoyer des requêtes à un modèle de langage externe (OpenAI, Anthropic, Mistral, ou autre) selon les conditions API négociées par le cabinet.

La souveraineté signifie : que ce qui quitte l'infrastructure du cabinet se limite à des extraits minimaux — les chunks strictement nécessaires à la réponse de la requête en cours — et non à la totalité des documents, aux index vectoriels, aux logs de conversation ou aux métadonnées de la relation client.

Voici la distinction architecturale qui compte :

Cette architecture répond précisément à ce que France Travail ne fait pas : elle rend l'audit possible, la traçabilité native, et la gouvernance effective — non comme promesse commerciale, mais comme contrainte d'infrastructure.

L'explicabilité n'est pas une option

L'un des angles morts de la plupart des déploiements IA dans les cabinets est l'explicabilité des outputs. Lorsqu'un outil indique que les chances de succès d'un recours sont 'élevées' ou qu'une clause contractuelle présente un 'risque modéré', sur quelle base ? Quels documents ont été consultés ? Quels passages ont pesé dans la réponse ? Avec quel niveau de certitude ?

Pour la recherche de jurisprudence IA, cette question est critique : si l'outil hallucine une décision ou sélectionne des précédents de manière biaisée, l'avocat doit pouvoir tracer l'origine de l'erreur. L'étude Stanford sur Harvey a documenté un taux d'hallucination de l'ordre d'1 cas sur 6 — un chiffre qui suffit à illustrer que même les outils les plus sophistiqués du marché ne sont pas exempts de ce risque.

Une architecture où les logs de raisonnement, les sources consultées et les chunks sélectionnés sont enregistrés localement transforme ce risque gérable en risque auditable. C'est la différence entre une responsabilité diffuse et une responsabilité traçable.

Ce que les cabinets devraient faire — maintenant

Un cadre d'évaluation en quatre dimensions

L'affaire CRE offre un cadre d'évaluation involontaire pour tout déploiement IA en contexte sensible. Appliquez-le à vos outils actuels :

1. Transparence du modèle Pouvez-vous décrire précisément quel modèle traite vos données, avec quels paramètres, et comment les outputs sont générés ? Si vous dépendez exclusivement des déclarations du fournisseur sans pouvoir les vérifier, vous êtes dans la situation de France Travail — confiance sans vérification.

2. Auditabilité indépendante Un expert tiers mandaté par votre cabinet (ou par une autorité de contrôle) pourrait-il, aujourd'hui, examiner votre système sans passer par votre fournisseur ? Si la réponse nécessite l'accord du fournisseur, votre audit est structurellement compromis.

3. Portée des données exposées Quel est le périmètre exact des données qui quittent votre infrastructure ? La distinction entre 'extraits minimaux pour la réponse' et 'corpus complet du cabinet' représente une différence de risque d'un à plusieurs ordres de grandeur.

4. Recours et responsabilité En cas d'output problématique — une analyse erronée, une recommandation biaisée, une fuite de données — qui est responsable, comment le prouvez-vous, et avec quelles données de log ?

Pour aller plus loin dans cette évaluation, le guide IA pour cabinets détaille les critères de sélection et les questions à poser aux fournisseurs avant signature.

La fenêtre de conformité se ferme

La révélation de l'affaire France Travail à treize jours de l'échéance AI Act n'est pas qu'une coïncidence malheureuse pour l'opérateur public. C'est un signal de marché : les systèmes IA à haut risque déployés sans documentation, sans audit et sans traçabilité sont désormais exposés, que ce soit par des journalistes, des associations de défense des droits numériques, ou des autorités de contrôle.

Les cabinets d'avocats — qui traitent des données parmi les plus sensibles de l'économie française, souvent sous secret professionnel — ont un intérêt direct à ne pas se retrouver dans la même position. Non pas parce qu'ils ciblaient des chômeurs, mais parce que la structure du risque est identique : IA déployée sur données sensibles, biais non contrôlables, traçabilité insuffisante, responsabilité diffuse.

Les outils comme Harvey (valorisé à 8 milliards de dollars fin 2025, utilisé par environ 100 000 avocats) ou CoCounsel ont une proposition de valeur réelle et documentée. Mais leur modèle de déploiement SaaS, même hébergé en Europe, ne répond pas structurellement aux questions d'auditabilité indépendante et de contrôle de l'orchestration que l'AI Act commence à rendre incontournables.

Une architecture on-premise comme RAGbase Legal — avec un investissement de l'ordre de 20 à 50 000 dollars en one-time — n'est pas la réponse universelle à tous les besoins d'un cabinet. Mais elle est la réponse pertinente pour les charges de travail critiques : dossiers stratégiques, données sous secret professionnel renforcé, analyses où la traçabilité de la décision est elle-même un élément de la prestation.

L'affaire France Travail restera probablement dans les annales de l'IA publique française comme l'exemple canonique de ce qu'il ne faut pas faire : déployer à grande échelle, refuser la transparence, ignorer les échéances réglementaires, et laisser des biais historiques s'automatiser. Pour les cabinets d'avocats, la leçon n'est pas de se féliciter de ne pas être France Travail. C'est d'évaluer honnêtement si leur propre déploiement IA passerait l'examen que France Travail a échoué : un audit technique indépendant, une documentation des biais, une traçabilité complète des décisions, et une gouvernance des données qui reste sous leur contrôle effectif — pas sous celui de leur fournisseur.