Aller au contenu
NEURIXIS

Secteur

L’IA dans le service public

Une administration n’achète pas un modèle, elle achète un service qu’elle devra pouvoir expliquer, auditer et reprendre. Cela oriente les choix techniques bien plus que la performance brute.

Le contexte

Le service public ne manque pas de données, il manque d’accès. Les bases métier sont anciennes, les référentiels sont multiples et parfois contradictoires, et la donnée a presque toujours été produite pour une finalité différente de celle qu’on veut lui donner. Obtenir un extrait réel, représentatif et documenté prend souvent plus de temps que tout le travail de modélisation qui suit.

L’erreur y est asymétrique. Se tromper sur le dossier d’un usager n’a pas le même coût qu’une erreur commerciale : elle touche un droit, elle se conteste, et elle se répare mal. Cette asymétrie déplace le curseur technique. On préfère un système qui trie, prépare et documente à un système qui décide, et on accepte de rester en deçà de l’optimum statistique pour rester au-dessus du seuil d’acceptabilité.

La commande publique impose de décrire ce que l’on achète avant de l’avoir construit. Or un projet d’IA se décrit mal en spécifications fermées : ce qui est faisable dépend de données que personne n’a encore regardées. Le découpage en phases, cadrage puis prototype qualifié puis industrialisation, sert autant la régularité de l’achat que la maîtrise du risque. Un marché qui ne prévoit pas l’arrêt après le prototype fabrique des projets qui ne peuvent plus s’arrêter.

La réversibilité n’est pas une clause de style. L’administration doit pouvoir reprendre le service ou le faire reprendre par un tiers : cela veut dire code source, poids des modèles, jeux d’entraînement, procédures d’exploitation et documentation livrés et à jour, pas un accès à une plateforme.

Hôtel de Ville de Paris, façade d’un bâtiment public.

Contraintes réglementaires

Le secteur public cumule les cadres. Aucun n’est optionnel, et plusieurs ferment des options techniques avant même l’étude de faisabilité.

  • AI Act, annexe III

    Les systèmes d’IA destinés à évaluer l’éligibilité à des prestations et services publics essentiels, ou à en accorder, réduire, révoquer ou récupérer le bénéfice, relèvent du haut risque. Point souvent mal compris : une administration qui met en service le système d’un tiers agit comme déployeur, avec des obligations propres, distinctes de celles du fournisseur : contrôle humain, surveillance en service, information des personnes concernées. Acheter un produit conforme ne suffit pas à être conforme.

  • RGPD et décision automatisée

    La base légale est le plus souvent la mission d’intérêt public. Une analyse d’impact relative à la protection des données est attendue pour les traitements susceptibles d’engendrer un risque élevé, ce qui est la règle pour un traitement de masse de données d’usagers. L’article 22 encadre les décisions fondées exclusivement sur un traitement automatisé produisant des effets juridiques : c’est le texte qui, en pratique, impose de concevoir en aide à l’instruction plutôt qu’en décision automatique.

  • Sécurité : référentiel général de sécurité

    Le référentiel général de sécurité encadre la sécurité des systèmes d’information des autorités administratives, et l’ANSSI publie les référentiels et qualifie prestataires et offres. Pour un projet d’IA, cela se traduit en exigences concrètes et vérifiables : cloisonnement des environnements, gestion des secrets, journalisation, homologation de sécurité du service avant mise en service. Ces travaux se planifient au début, ils ne se rattrapent pas.

  • Doctrine « cloud au centre » et qualification SecNumCloud

    La doctrine d’utilisation de l’informatique en nuage par l’État pose le cloud comme mode d’hébergement de référence et impose, pour les données les plus sensibles, une offre qualifiée SecNumCloud ou une solution interne à l’État. La conséquence pratique arrive tôt : elle ferme l’option d’un modèle propriétaire appelé via une interface hébergée hors de ce cadre, avant même l’étude technique. C’est aussi pour cela que nous savons faire tourner des modèles ouverts sur votre infrastructure.

  • Accessibilité et RGAA

    L’obligation d’accessibilité des services de communication au public en ligne s’applique aux interfaces que vous exposez, y compris à un assistant conversationnel ou à un écran de restitution destiné aux agents. Le RGAA en fournit le référentiel de contrôle, avec déclaration de conformité et schéma pluriannuel. Le contrôle porte sur des critères précis, de la navigation au clavier aux contrastes. Une interface d’IA testée pour l’accessibilité après la recette est une interface à refaire.

  • Commande publique

    Le code de la commande publique encadre l’achat, et la forme choisie décide de votre marge de manœuvre. Un allotissement ou des tranches qui permettent d’arrêter après un prototype non concluant protègent l’argent public bien mieux qu’un forfait global engagé sur des spécifications écrites avant d’avoir vu la donnée. La tranche optionnelle est ici l’outil le plus utile. Nous préférons les marchés qui prévoient explicitement l’arrêt, y compris quand ils nous concernent.

Classement des systèmes d’IA du plus au moins encadré : risque inacceptable, haut risque, risque limité, risque minimal.Le plus encadréLe moins encadréRisque inacceptableInterdit dans l’UnionHaut risqueAnnexe III, obligations lourdesRisque limitéObligations de transparenceRisque minimalUsage libre

Cas d’usage

  • Orientation et pré-instruction des demandes

    Le problème
    Le flux entrant est en texte libre, avec des pièces jointes hétérogènes. Le tri initial est manuel, le délai de première réponse s’allonge, et les dossiers incomplets reviennent en boucle.
    L’approche
    Classification multi-label vers les services compétents, détection des pièces manquantes pour le type de demande, extraction des éléments d’identification. Aucune décision d’octroi, seulement du routage et de la préparation. En dessous d’un seuil de confiance, le dossier part en file humaine par défaut, et non l’inverse.

    Critère de succès

    Taux de routage correct sur un échantillon revu par les services, et surtout taux de mauvais routage résiduel catégorie par catégorie. Un taux moyen flatteur qui se trompe systématiquement sur une catégorie sensible n’est pas acceptable : la mesure agrégée seule masquerait exactement le problème qui compte.

  • Recherche assistée sur le corpus réglementaire interne

    Le problème
    Les agents cherchent une doctrine, une circulaire ou une note de service dans un corpus qui s’empile. Deux agents donnent deux réponses, et la version applicable n’est pas toujours celle qui remonte.
    L’approche
    RAG sur corpus versionné, recherche hybride lexicale et vectorielle, citation obligatoire du texte applicable avec sa date de version, refus explicite quand la base ne couvre pas la question, journalisation des questions et des réponses pour permettre l’audit et la révision du corpus.

    Critère de succès

    Taux de réponses correctement sourcées et taux d’affirmation sans source, évalués sur un jeu de questions écrit par les agents eux-mêmes et non par nous. Complété par le temps de recherche avant et après, chronométré sur les mêmes questions et les mêmes agents, à périmètre de corpus identique.

  • Lecture d’archives et de fonds numérisés

    Le problème
    Des fonds entiers sont numérisés mais inexploitables en recherche plein texte : registres manuscrits, formulaires anciens, typographies dégradées. Le lecteur doit connaître la cote à l’avance.
    L’approche
    OCR pour l’imprimé, HTR pour le manuscrit, avec des modèles adaptés à la main et à la période du fonds plutôt qu’un modèle générique, boucle de correction sur les cotes les plus consultées, puis indexation et recherche tolérante aux erreurs de transcription, avec un score de confiance par ligne.

    Critère de succès

    Taux d’erreur par caractère et par mot sur un échantillon transcrit manuellement, ventilé par type de main et par période. Et, du point de vue de l’usage, le rappel de la recherche sur des requêtes réelles de lecteurs : c’est ce dernier chiffre qui décide de l’intérêt du projet, pas le taux d’erreur brut.

  • Détection d’anomalies dans les données déclaratives

    Le problème
    Les volumes déclaratifs sont massifs et les contrôles peu nombreux. Le ciblage repose sur des critères fixes, connus, contournables, et peu discriminants sur les cas nouveaux.
    L’approche
    Détection d’anomalie non supervisée pour amorcer, puis apprentissage supervisé sur les résultats de contrôle réels. Modèles à contribution explicable, arbres ou gradient boosting avec attribution par variable, parce que le contrôleur doit pouvoir motiver sa sélection autrement que par un score.

    Critère de succès

    Précision en tête de file à charge de contrôle constante, et taux de contrôles aboutis comparé au ciblage actuel sur la même période. Avec un suivi séparé des taux de sélection par groupe, pour détecter une dérive discriminatoire avant qu’elle ne s’installe, et documentée à chaque version du modèle.

Matrice deux par deux croisant l’effort d’intégration et le gain annuel estimé, avec quatre quadrants nommés.Quick winGain fort, effort faibleChantier structurantGain fort, effort fortGadgetGain faible, effort faiblePiègeGain faible, effort fortGain annuel estiméfortfaibleEffort d’intégrationfaiblefort

Ce qui fait échouer les projets

Les projets d’IA publics échouent peu souvent pour des raisons techniques. Voici les raisons réelles.

  • La promesse d’automatiser la décision est mise en avant alors que ni le droit ni les agents ne l’acceptent. Le projet se heurte à un refus interne parfaitement légitime, alors qu’il aurait suffi de le cadrer en aide à l’instruction dès le départ.
  • L’accès aux données réelles arrive au bout de neuf mois. Le prototype a été construit sur un jeu synthétique qui ne ressemble pas à la production, et tout est à refaire au moment où le budget est déjà consommé.
  • Le marché est passé au forfait sur un périmètre décrit avant la première exploration des données. Il n’y a plus moyen ni d’arrêter, ni de réorienter, et tout le monde continue en sachant que la cible est mauvaise.
  • Le sponsor change et la priorité avec lui. Un projet d’IA public a besoin d’un porteur métier qui reste, pas seulement d’une direction des systèmes d’information qui exécute.
  • L’interface est livrée sans test d’accessibilité. Elle est inutilisable pour une partie des agents et des usagers, et elle expose l’administration sur une obligation qu’elle connaissait.
  • La question de la localisation des traitements est reportée à plus tard. Elle revient au moment de l’homologation et invalide une architecture déjà construite.
Cycle fermé du MLOps : entraîner, déployer, superviser, détecter la dérive, réentraîner.EntraînerDéployerSuperviserDétecter la dériveRéentraîner

Ce que nous faisons, et ce que nous ne faisons pas

Ce que nous faisons

  • Nous cadrons avec les agents qui instruisent les dossiers, pas seulement avec la direction des systèmes d’information.
  • Nous concevons sur votre infrastructure ou sur une offre qualifiée, et nous savons faire tourner des modèles ouverts quand la souveraineté l’exige.
  • Nous produisons les éléments techniques de l’analyse d’impact et du dossier AI Act, y compris pour votre rôle de déployeur.
  • Nous livrons le code, les poids, les jeux d’évaluation et les procédures d’exploitation, pour que la reprise soit réellement possible.
  • Nous testons l’accessibilité des interfaces que nous produisons pendant le développement, pas à la recette.
  • Nous formons vos agents et vos équipes techniques, avec l’objectif explicite que vous n’ayez plus besoin de nous.

Ce que nous ne faisons pas

  • Nous ne construisons pas de système qui prend une décision individuelle défavorable sans intervention humaine réelle. Ce n’est pas une position commerciale, c’est une limite.
  • Nous ne sommes titulaires d’aucun accord-cadre national et nous ne répondons pas aux très grands marchés multi-lots. Nous intervenons en direct ou en cotraitance sur un lot précis.
  • Nous n’hébergeons pas et nous n’exploitons pas votre infrastructure : nous concevons pour la vôtre ou pour celle de votre hébergeur qualifié.
  • Nous ne fournissons pas de conseil juridique. Nous préparons les éléments techniques, votre conseil et votre DPO les qualifient.
  • Nous sommes deux ingénieurs. Nous prenons un projet à la fois, et nous le terminons avant d’en prendre un autre.

Les autres secteurs

Questions fréquentes

  • Vos traitements tournent-ils sur une infrastructure souveraine ?

    Oui, et c’est parfois une obligation avant même l’étude technique. La doctrine d’utilisation de l’informatique en nuage par l’État impose, pour les données les plus sensibles, une offre qualifiée SecNumCloud ou une solution interne à l’État. Cela ferme l’option d’un modèle propriétaire appelé via une interface hébergée hors de ce cadre. Nous savons faire tourner des modèles ouverts sur votre infrastructure, ce qui est souvent le chemin le plus court pour rester dans le cadre.

  • L’IA va-t-elle décider à la place de nos agents ?

    Non, et nous ne construisons pas de système qui prend une décision individuelle défavorable sans intervention humaine réelle. L’article 22 du RGPD encadre les décisions fondées exclusivement sur un traitement automatisé : en pratique, il impose de concevoir en aide à l’instruction plutôt qu’en décision automatique. Nos systèmes trient, préparent et documentent, l’agent décide. C’est une limite, pas une position de négociation.

  • L’interface sera-t-elle accessible ?

    Oui, et l’accessibilité se conçoit pendant le développement, pas à la recette. L’obligation d’accessibilité des services de communication au public en ligne s’applique aux interfaces que vous exposez, y compris à un assistant conversationnel ou à un écran destiné aux agents, et le RGAA en fournit le référentiel de contrôle. Une interface d’IA testée pour l’accessibilité après la recette est une interface à refaire : nous la testons pendant que nous la construisons.

  • Pourrons-nous reprendre le service sans vous ?

    Oui, c’est ce que veut dire la réversibilité, et ce n’est pas une clause de style. Nous livrons le code source, les poids des modèles, les jeux d’entraînement, les procédures d’exploitation et la documentation, à jour, pas un accès à une plateforme. L’administration doit pouvoir reprendre le service ou le faire reprendre par un tiers. Nous ne facturons pas de licence, et nous formons vos agents et vos équipes techniques avec l’objectif explicite que vous n’ayez plus besoin de nous.

Parlons de votre cas d’usage.

Une heure suffit pour savoir si votre sujet tient debout. Si ce n’est pas le cas, nous vous le dirons à ce moment-là, pas après trois mois de projet.

Nous contacterRéserver un Workshop Quick Wins IA