L’IA dans le secteur public : entre opportunités et responsabilités

« Lorsque j’échange avec des responsables informatiques d’autorités publiques au sujet de l’intelligence artificielle, les cas d’usage potentiels sont généralement vite identifiés. Les questions qui se posent ensuite sont plus difficiles : comment intégrer l’IA en toute sécurité dans des applications métier existantes ? Quelles données peuvent être traitées ? Comment garantir la traçabilité des résultats ? Qui porte finalement la responsabilité ? Et comment éviter qu’une multitude de projets pilotes ne se transforme en un paysage d’outils difficile à contrôler ?

Ces questions nous occupent précisément de manière très intensive chez GLAUX GROUP. Notre ambition n’est pas d’intégrer le plus d’IA possible dans nos produits, mais de faire en sorte que l’IA crée une utilité concrète là où des personnes travaillent chaque jour avec nos solutions : de manière contrôlée, traçable et intégrée dans les processus existants.

Pour les processus métier assistés par l’IA, nous misons donc systématiquement sur le Human in the Loop : l’IA peut reconnaître, structurer, formuler ou faire des propositions. L’examen métier et la décision restent entre les mains de l’humain.

Je montre ce que nous avons appris sur les plans technique et organisationnel à l’aide d’exemples concrets.

L’IA doit être intégrée là où le travail s’effectue

De nombreuses autorités savent déjà très précisément comment l’IA pourrait soutenir leurs collaboratrices et collaborateurs. Pourtant, précisément là où le travail quotidien a lieu – dans les applications métier, les systèmes de gestion des cas et des dossiers –, les fonctions correspondantes font souvent défaut. Une analyse du réseau menée dans un canton suisse a montré la conséquence suivante : un nombre à cinq chiffres d’utilisateurs recourt à des services publics de chat IA sur le réseau administratif, parfois sans licence, sans directives et sans contrôle.

De notre point de vue, le plus grand bénéfice ne réside donc pas dans un outil d’IA supplémentaire à côté des systèmes existants. L’IA devrait être disponible là où le travail se fait déjà – sans devoir copier des données dans une fenêtre de chat, sans connexions supplémentaires et sans nouveaux processus parallèles.

Pour que cette intégration fonctionne dans le contexte des autorités publiques, quatre exigences sont essentielles : l’intégration dans la gestion des cas, le pouvoir de décision, la traçabilité, la sécurité et la souveraineté des données.

Le pouvoir de décision reste humain

En particulier dans les procédures administratives, la gestion des cas ou les décisions ayant des conséquences pour les personnes, il doit être clair qui est responsable. Un système d’IA peut apporter son soutien, mais il ne doit pas devenir, sans que l’on s’en aperçoive, le véritable décideur. Une autorité l’a formulé ainsi : que se passe-t-il après six mois d’exploitation si, par facilité, les collaboratrices et collaborateurs ne suivent plus que les recommandations de l’IA ?

Un simple avertissement ne suffit pas à l’empêcher. C’est pourquoi nous positionnons systématiquement les résultats de l’IA comme une proposition ou un second avis, jamais comme une décision, et nous concevons les fonctionnalités de manière à ce que les collaboratrices et collaborateurs vérifient et valident consciemment. Une expérience utilisateur qui inciterait simplement à cliquer rapidement sur « continuer, continuer, terminé » va à l’encontre de cette exigence.

La traçabilité doit être pensée dès le départ

À mesure que l’expérience de nos client·e·s progresse, les questions deviennent plus concrètes : quelles informations et quel contexte ont été transmis à l’IA ? Quel modèle et quels paramètres ont été utilisés ? Quelle réponse le système a-t-il générée ? La raison est simple : en cas de recours, une autorité doit pouvoir démontrer sur quelle base une décision a été prise.

Dans le même temps, il faut garder le sens de la mesure. Un protocole qui consigne les prompts et les contextes contient lui-même des données particulièrement sensibles ; son étendue relève d’un arbitrage conscient, et non d’une logique de « tout journaliser ». Comme les résultats produits par l’IA ne peuvent jamais être reproduits à l’identique, l’objectif réaliste est le suivant : rendre les entrées, la configuration et le résultat compréhensibles, et les documenter là où cela est pertinent pour le cas d’usage.

Où l’IA peut déjà apporter une aide concrète aujourd’hui

Trois exemples montrent où nous voyons actuellement un potentiel particulièrement important dans l’environnement Public IT.

1. Reconnaître et traiter automatiquement les documents

Les autorités traitent chaque jour de grands volumes de documents dans des formats très variés : les informations doivent être reconnues, saisies et attribuées au bon dossier ou au bon processus.

C’est précisément là qu’intervient Iris, notre module d’IA de reconnaissance automatique de documents dans evidence. Le système identifie les types de documents, extrait les informations pertinentes et oriente les documents vers le processus prévu. Chaque résultat est assorti d’un niveau de confiance : ce qui est clair peut être traité automatiquement, tandis que les cas incertains sont soumis de manière ciblée à une vérification.

Ce qui est décisif pour nous, c’est que la fonction d’IA ne se présente pas comme un outil distinct à côté de l’application métier, mais qu’elle fasse partie d’un processus numérique continu : cela réduit les efforts manuels et évite de nouvelles ruptures de média ainsi que des solutions isolées.

2. Utiliser aussi l’IA pour un développement logiciel sécurisé

L’IA ne transforme pas seulement les fonctions que les utilisatrices et utilisateurs exploitent dans les logiciels. Elle transforme aussi le développement logiciel lui-même, et donc les exigences en matière de sécurité des applications.

Cela devient particulièrement évident avec les agents d’IA autonomes, qui interagissent de manière indépendante avec des applications et des interfaces et déclenchent des actions : si les autorisations, les API ou les logiques métier ne sont pas suffisamment sécurisées, de nouveaux risques apparaissent.

Pour les éditeurs de logiciels, cela signifie que le security-by-design doit, au-delà des attaques classiques et des utilisateurs humains, prendre de plus en plus en compte les systèmes automatisés et autonomes. Car les mêmes outils sont également à la disposition des attaquants : les attaques deviennent moins coûteuses et plus sophistiquées.

C’est pourquoi nous utilisons systématiquement l’IA dans notre propre développement — en requirements engineering, pour les revues de code, le refactoring et la documentation — et nous analysons la base de code de nos produits de manière systématique à l’aide d’une analyse statique assistée par l’IA : pas seulement le nouveau code, mais aussi les composants développés au fil des années, car c’est précisément dans leur interaction que naissent les vulnérabilités.

3. Assistance à la rédaction pour les journaux, les rapports et la correspondance

Un autre domaine d’application concerne les tâches basées sur le texte : aujourd’hui, les rapports, les entrées de journal ou les correspondances sont souvent élaborés à partir de conversations, de notes et des connaissances déjà disponibles sur le dossier, puis réunis manuellement.

Pour socialweb et evidence, nous développons des fonctions d’IA qui soutiennent les spécialistes dans ce travail : à partir de mots-clés ou du contenu d’un échange, un projet structuré d’entrée de journal est généré ; des textes existants sont résumés, retravaillés sur le plan linguistique ou rassemblés dans un rapport. Ici aussi, le principe reste le même : l’IA produit une proposition ; le contrôle, la correction et la validation sont assurés par la personne compétente.

Nous poursuivons également cette approche, par exemple vers une recherche capable de trouver, dans son propre fonds de dossiers, des cas similaires et des formulations éprouvées. L’échange avec les utilisatrices et utilisateurs est central pour nous, car des fonctions techniquement possibles ne sont pas automatiquement des fonctions pertinentes sur le plan métier.

La gouvernance n’est pas un frein – c’est une condition préalable

Pour éviter que de telles applications ne se développent de manière isolée, nous avons mis en place un AI Board : cet organe interne évalue les initiatives en matière d’IA, fait évoluer les directives et crée des conditions-cadres contraignantes pour leur utilisation.

Des règles claires et de solides compétences issues de tous les domaines permettent à notre Board de classer plus rapidement les nouvelles idées et de les poursuivre de manière ciblée.

Dans le cadre d’une initiative d’IA, nous nous posons notamment les questions suivantes :

• Quel problème concret faut-il résoudre ?

• Quelles données sont traitées, et parmi elles, y en a-t-il qui sont particulièrement sensibles ou délicates sur le plan métier ?

• Où le traitement a-t-il lieu ?

• Quel fournisseur et quel modèle sont utilisés, et les entrées ou les résultats alimentent-ils son entraînement ?

• Quelle instance de contrôle humain est prévue, et comment l’utilisation est-elle documentée ?

• Que se passe-t-il si le modèle ou le fournisseur doit être remplacé ?

Sans un tel processus, des solutions parallèles, des responsabilités floues et des dépendances à l’égard de fournisseurs individuels apparaissent rapidement. Cela est particulièrement problématique dans le secteur public, où des décisions de grande portée sont prises sur la base de données personnelles et de dossiers.

La question « Où vont mes données ? » n’est donc pas une question de détail technique, mais une condition fondamentale à l’utilisation de l’IA.

De la gouvernance à l’architecture logicielle

La gouvernance ne doit toutefois pas s’arrêter à un document de directives. Elle doit également se refléter dans l’architecture et dans l’interface utilisateur d’une application.

Ce sont de plus en plus les autorités elles-mêmes qui fixent les critères : dans de nombreux endroits, un projet d’IA doit passer un contrôle préalable de l’autorité de protection des données avant d’être autorisé à travailler avec de vraies données – avec à l’appui des mesures documentées, allant de la sécurisation Human in the Loop à la journalisation. Ce travail de justification n’est pas un sujet de conformité traité a posteriori, mais fait partie intégrante de la fonctionnalité elle-même, et il est au moins aussi important pour l’acceptation que la technologie.

En parallèle, l’interface utilisateur doit clairement indiquer quand un contenu a été généré ou modifié par une IA.

C’est précisément là que nous voyons une mission essentielle en tant qu’éditeur de logiciels : non pas simplement fournir des fonctions d’IA, mais créer les conditions dans lesquelles les autorités peuvent les utiliser de manière contrôlée. 

La souveraineté des données vaut aussi pour l’IA

La souveraineté des données fait l’objet de discussions depuis des années dans le domaine des infrastructures cloud. Dès lors que les applications d’IA traitent les mêmes données, les mêmes questions se posent à nouveau, parfois de manière encore plus aiguë : où les données sont-elles traitées, où sont-elles stockées ? Les contenus alimentent-ils l’entraînement d’un modèle ? Quels sous-traitants interviennent, de quel droit relèvent-ils ? Et dans quelle mesure est-il facile de remplacer ultérieurement un modèle ou un fournisseur ?

Nous travaillons donc sur un modèle d’exploitation dans lequel les services d’IA fonctionnent sur une infrastructure contrôlée, par exemple dans les centres de données de notre partenaire de fusion CONVOTIS, disponibles sous forme de Model as a Service. L’architecture est conçue selon un principe de Zero Retention : les contenus ne doivent être ni stockés durablement ni repris pour l’entraînement du modèle sous-jacent.

D’autres organisations souhaitent exploiter entièrement elles-mêmes leur infrastructure d’IA : dans le cadre de l’approche Bring your own AI, nous connectons leur infrastructure à nos solutions – et y apportons notre expérience en matière de matériel IA, de modèles, d’exploitation et d’intégration.

Cela est rendu possible par un principe d’architecture simple : aucune de nos fonctions d’IA ne repose sur un service câblé en dur. Grâce à des endpoints configurables, chaque organisation choisit elle-même l’infrastructure adaptée à chaque cas d’usage, jusqu’à l’instance dédiée pour les données particulièrement sensibles.

Pour les autorités, il ne s’agit pas de questions secondaires : c’est là que se décide si un projet d’IA techniquement intéressant devient une solution durablement viable.

L’essentiel n’est pas de savoir si l’IA est utilisée, mais comment

L’intelligence artificielle occupera une place durable dans les applications métier et les processus administratifs. À mes yeux, la question la plus décisive n’est donc pas tant de savoir si les autorités utiliseront l’IA, mais dans quelles conditions.

Celles et ceux qui intègrent dès le départ l’intégration, le pouvoir de décision humain, la traçabilité, la sécurité et la souveraineté des données peuvent utiliser l’IA là où elle crée réellement de la valeur – sans transférer la responsabilité métier à un modèle.

C’est précisément là que nous voyons notre mission : ne pas positionner l’IA comme un outil supplémentaire à côté des processus existants, mais l’intégrer de manière responsable là où elle soutient concrètement les personnes dans leur travail quotidien. Le bénéfice : moins de routine – et plus de temps pour le travail qui exige le discernement humain.

Nous évoquerons également ces questions, nos développements actuels et les expériences issues des projets en cours lors de nos événements clients en septembre (en allemand). »

À propos de l’auteur

Felix Leimbach dirige les innovations en IA au sein de GLAUX GROUP. Il travaille sur l’intégration technique et organisationnelle de l’intelligence artificielle dans les applications métier, ainsi que sur les questions liées à la gouvernance, à la sécurité et à la souveraineté des données dans le secteur public.