IA générative souveraine pour l’administration : les leçons de la DILA

Que signifie une IA générative souveraine pour une administration ?

Dans le contexte du service public, souveraine veut dire que l’institution garde la maîtrise de l’endroit où vivent ses données, de qui peut y accéder, de la façon dont le système est sécurisé et de la possibilité de remonter de chaque réponse à sa source. C’est une question de contrôle et de responsabilité, pas de nationalité d’une technologie.

À la DILA, qui relève des services du Premier ministre, ces exigences ont façonné la plateforme dès le premier jour au lieu d’être ajoutées à la fin.

Pourquoi l’IA générative est-elle plus difficile à déployer dans le secteur public ?

Les institutions publiques doivent déployer l’IA générative tout en respectant des exigences strictes de souveraineté des données, de sécurité, de traçabilité et de conformité réglementaire. Ces exigences s’appliquent à chaque application, et c’est précisément là que les difficultés commencent.

Quand chaque application est construite isolément, l’ingestion de documents, les embeddings, la récupération, l’orchestration, les contrôles de sécurité, l’évaluation et l’observabilité sont reconstruits pour chaque projet. La duplication coûte cher, mais le risque principal est l’incohérence : chaque copie de la couche de sécurité est un objet distinct à auditer, et chaque projet finit avec sa propre idée de la qualité.

C’est pourquoi je soutiens que la question pour une administration est rarement de choisir un modèle. Elle est d’éviter de résoudre une cinquième fois le même problème de conformité.

Quel défi la DILA cherchait-elle à relever ?

L’objectif était de dépasser les preuves de concept isolées et d’établir un socle d’IA souverain et réutilisable, capable d’accélérer le développement d’applications RAG et agentiques prêtes pour la production. Le RAG, ou génération augmentée par récupération, consiste à faire répondre le modèle à partir des documents de l’institution plutôt que de sa seule mémoire.

Ma contribution a été de diriger une équipe de 9 personnes sur l’approche produit et de livraison de la plateforme, avec un accent fort sur l’architecture modulaire, la réutilisation des composants et une livraison d’IA qui passe à l’échelle. Je ne décris mon rôle que dans la mesure où l’étude de cas le fait : la plateforme est le travail de toute l’équipe.

En quoi une approche par plateforme change-t-elle la livraison de l’IA ?

Le changement a consisté à passer de la construction indépendante de chaque application à l’assemblage de composants d’IA standardisés et gouvernés. L’approche combinait plusieurs éléments, dont chacun répond à l’un des coûts dupliqués évoqués plus haut.

• Une architecture souveraine compatible avec des exigences strictes d’hébergement, de sécurité et de souveraineté des données, notamment SecNumCloud.
• Des briques réutilisables : ingestion de documents, découpage, embeddings, récupération hybride, reranking, gestion des prompts et intégration des LLM.
• Une orchestration agentique : des workflows réutilisables pour l’appel d’outils, le raisonnement en plusieurs étapes et l’exécution de tâches par des agents.
• Une usine à RAG : des assistants documentaires créés à partir de chaînes de récupération configurables plutôt que d’implémentations propres à chaque projet.
• Un cadre d’évaluation qui mesure la qualité du RAG de façon systématique.
• Une gouvernance dès la conception : gestion des accès, traçabilité, auditabilité et exigences de souveraineté intégrées aux composants eux-mêmes.
• Des modèles d’implémentation reproductibles qui réduisent l’effort de développement et améliorent la cohérence entre projets.

Comment les exigences de souveraineté se traduisent-elles en fonctions de plateforme ?

Le tableau ci-dessous est ma lecture de la façon dont chaque exigence citée dans l’étude de cas se traduit en comportement de plateforme. C’est un cadre de discussion, pas une description de la conception interne, que je ne détaille pas ici.

Comment la qualité des réponses a-t-elle été évaluée ?

Une administration ne peut pas livrer un assistant sur la foi d’une bonne démonstration. La plateforme a introduit des mesures systématiques de la qualité du RAG, qui donnent à chaque application le même étalon.

Quatre mesures méritent d’être connues, car ce sont celles que les gens recherchent. La fidélité demande si la réponse est étayée par les documents récupérés. La pertinence de la réponse demande si elle traite la question. La précision du contexte demande si les passages récupérés étaient les bons, et le rappel du contexte demande si les bons passages ont bien été trouvés.

Les scores rapportés sont de 0,94 pour la fidélité, 0,91 pour la pertinence de la réponse, 0,89 pour la précision du contexte et 0,92 pour le rappel du contexte. L’évaluation couvrait 85 % des scénarios RAG prioritaires. Je donne ces chiffres tels que rapportés pour cette plateforme, pas comme une référence pour d’autres contextes.

Qu’a changé concrètement la plateforme ?

Les nouvelles applications RAG ont pu réutiliser les capacités partagées de traitement de documents, de récupération, d’évaluation et de sécurité, et les applications agentiques ont pu s’appuyer sur des modèles d’orchestration et des intégrations d’outils existants. Cela a réduit le travail d’ingénierie dupliqué, accéléré l’expérimentation et instauré une approche plus cohérente de la qualité et de la gouvernance. Les résultats rapportés :

• La création de contenu est devenue 70 % plus rapide.
• Le délai de livraison d’une application RAG a baissé de 60 %, de 10 semaines à 4.
• 75 % des capacités techniques communes ont été réutilisées.
• Le coût par requête d’IA a baissé de 30 %, grâce à l’optimisation des chaînes et à la réutilisation.
• Le temps de mise en œuvre du prototypage de workflows agentiques a baissé de 50 %.

Que peuvent retenir les autres administrations de l’expérience DILA ?

La page de l’étude de cas formule la leçon simplement : la valeur d’une plateforme d’IA d’entreprise n’est pas seulement l’intelligence qu’elle apporte, mais la rapidité et la fiabilité avec lesquelles elle permet de construire l’application suivante. Voici ce que je transmettrais à une autre administration.

• Traiter les chaînes RAG, les workflows agentiques, l’évaluation et la gouvernance comme des capacités de plateforme, pas comme des fonctions d’un projet.
• Inscrire les exigences de souveraineté et de sécurité dans les composants réutilisables, pour que la conformité soit héritée plutôt que répétée.
• Convenir des mesures de qualité avant la première version, et garder les mêmes pour toutes les applications.
• Mesurer la plateforme à la vitesse à laquelle l’application suivante peut être construite, pas à l’effet produit par la première.
• Garder l’équipe réduite et les composants partagés : une équipe de 9 personnes ne peut servir plusieurs applications que si chacune ne repart pas de zéro.