Pourquoi cette mesure ?
La mesure 9.03 visait initialement la création d’une plateforme publique multi-modèles. En 2026, ce point doit être actualisé : Albert API existe déjà et fournit précisément une interface mutualisée vers plusieurs modèles, avec des fonctions de RAG, OCR, classification et vectorisation. La bonne question n’est donc plus de « créer une plateforme », mais de décider jusqu’où l’industrialiser : capacité de calcul, engagements de service, gouvernance des modèles, financement, support et capacité à servir des administrations de tailles très différentes. Cette actualisation évite de vendre comme réforme future une infrastructure qui a déjà commencé à exister.
État des lieux en 2026 : partir de ce qui existe vraiment
Albert API est présenté par la DINUM comme une plateforme interministérielle d’inférence. Elle peut exposer plusieurs modèles depuis un point d’accès unique et utilise une interface compatible avec les conventions OpenAI, ce qui facilite le remplacement des modèles côté application. La documentation 2026 indique aussi un hébergement souverain et des services avancés. Cette situation change le chiffrage : les investissements déjà réalisés appartiennent au socle existant ; le Plan ne doit compter que le coût marginal de montée en charge, de redondance, d’extension à de nouveaux niveaux de sensibilité ou de support de production.
Source au point d’usage : Albert API ↗
Concevoir, financer et sécuriser la mise en œuvre
Architecture, fonctionnement et conditions techniques
L’architecture proposée sépare le plan de contrôle — catalogue de modèles, quotas, authentification, observabilité, coûts — du plan d’exécution où se trouvent les accélérateurs et modèles. Les applications ne doivent pas coder en dur un fournisseur ou un modèle. Elles appellent une interface stable et déclarent leurs besoins : confidentialité, latence, coût, taille de contexte, multimodalité, licence. Un routeur peut ensuite sélectionner un modèle autorisé. Les modèles propriétaires peuvent être admis lorsqu’un besoin le justifie, mais la plateforme doit conserver des solutions open-weight afin de garantir un niveau minimal d’indépendance et de continuité.
Démonstration financière : séparer coût, capacité et économie
Le coût de la plateforme doit être publié en euros par million de tokens, par heure d’accélérateur, par volume de stockage et par niveau de service, autant que ces unités ont un sens. On distingue investissement initial, exploitation, énergie, licences, sécurité, support et renouvellement matériel. Les gains de productivité ne sont pas comptés ici : ils appartiennent aux applications qui consomment la plateforme. En revanche, la mutualisation peut produire un coût évité si elle remplace plusieurs infrastructures ministérielles identiques ; ce coût évité n’est reconnu qu’après identification des dépenses effectivement abandonnées.
Droit applicable et limites à ne pas franchir
La plateforme traite des données appartenant à de nombreuses administrations. Elle doit donc organiser clairement les rôles de responsable de traitement, sous-traitant, hébergeur et opérateur technique selon les usages. Chaque administration reste responsable de la légalité du cas d’usage qu’elle déploie. Les licences des modèles et composants doivent être inventoriées ; une interface ouverte ne dispense pas de respecter la propriété intellectuelle. Pour les données sensibles, la plateforme doit publier les niveaux d’homologation disponibles et interdire les cas d’usage non couverts.
Plans A, B et C : l’objectif survit au blocage d’une voie
industrialiser Albert API comme socle commun avec financement pluriannuel et niveaux de service.
si la capacité centrale ne suffit pas, autoriser des nœuds sectoriels ou ministériels compatibles avec la même interface et les mêmes règles de journalisation.
maintenir un catalogue de fournisseurs externes autorisés pour les besoins que le socle public ne sait pas traiter, avec clauses de sécurité et de réversibilité. Ainsi la souveraineté vient de l’interopérabilité et du contrôle, pas d’un dogme consistant à tout exécuter dans un unique centre de calcul.
Risques, objections et garde-fous
Le risque principal est le point de défaillance unique. Une plateforme trop centralisée peut ralentir l’innovation ou devenir un goulot d’étranglement. Il faut donc des architectures redondantes et une gouvernance transparente des priorités. Autre risque : afficher un prix artificiellement bas en faisant supporter l’infrastructure par un autre budget. Le coût complet doit inclure personnel, sécurité, renouvellement et énergie. Enfin, la disponibilité d’un modèle performant ne constitue jamais une autorisation automatique de traiter n’importe quelle donnée.
Indicateurs, audit et preuve de réussite
Indicateurs : disponibilité ; latence par type de service ; coût par unité d’usage ; nombre de modèles et fournisseurs substituables ; délai d’intégration d’un nouveau modèle ; part des applications utilisant l’interface commune ; incidents ; coûts de capacité inutilisée ; saturation ; économies de mutualisation réellement documentées ; part des usages relevant d’un environnement homologué. Un tableau mensuel doit permettre au Parlement et aux administrations clientes de comparer qualité, coût et dépendance.
Pourquoi une plateforme multi-modèles plutôt qu’un modèle national unique
Aucun modèle n’est le meilleur pour toutes les tâches. Certains sont performants pour résumer, d’autres pour coder, traduire, rechercher ou fonctionner sur une infrastructure modeste. Les performances et prix évoluent rapidement.
Une plateforme d’inférence publique doit donc permettre à une application métier de demander une capacité sans être enfermée dans un modèle unique. Un routeur peut sélectionner un modèle autorisé selon le niveau de sensibilité, le coût, la latence et l’évaluation métier. Cette architecture préserve également la concurrence : un nouveau modèle peut être ajouté et comparé sans réécrire toutes les applications. La souveraineté ne consiste pas à baptiser un modèle « national » puis à le conserver par principe ; elle consiste à garder la capacité de choisir, tester, remplacer et auditer les modèles utilisés par l’État.
Évaluer les modèles avec des jeux de tests propres au service public
Les classements généralistes ne suffisent pas pour choisir un modèle administratif. Chaque famille d’usage doit disposer d’un jeu de tests : compréhension de textes réglementaires, extraction de champs, rédaction neutre, respect d’instructions, résistance aux documents malveillants, langue française, hallucinations et refus appropriés. Les résultats doivent être enregistrés par version de modèle et par paramètres.
Une mise à jour ne passe en production qu’après comparaison. Les jeux de test peuvent combiner données publiques, données synthétiques et échantillons protégés traités dans un environnement autorisé. Cette discipline permet de transformer les débats sur « le meilleur modèle » en décisions mesurées. Elle protège également contre une régression silencieuse lorsqu’un fournisseur remplace une version derrière une même API.
Facturer et plafonner pour rendre les coûts visibles
Une API commune peut facilement provoquer une explosion de consommation si chaque application perçoit l’inférence comme gratuite. Le système doit donc comptabiliser les unités consommées, publier un coût par service et permettre des plafonds. Cette comptabilité n’implique pas nécessairement une facturation budgétaire complexe entre ministères ; elle sert d’abord à rendre les arbitrages visibles.
Une application qui envoie des documents gigantesques ou répète inutilement des requêtes doit pouvoir être identifiée. Les coûts doivent être rapprochés d’indicateurs métier : minutes d’agent réellement gagnées, dossiers préparés, taux de correction et satisfaction. Un service dont le coût technique augmente peut rester rationnel s’il améliore fortement la qualité, mais cette décision doit être consciente et documentée.
Continuité de service et fonctionnement dégradé
Une plateforme interministérielle devient critique dès que des centaines d’applications en dépendent. Elle doit donc prévoir redondance, quotas, priorisation et modes de secours. Les fonctions régaliennes ne doivent pas s’arrêter parce qu’un modèle est indisponible.
Certaines applications peuvent basculer vers un modèle de secours ; d’autres doivent continuer sans IA grâce au processus humain existant. Les priorités de trafic doivent être explicites : un assistant de rédaction non critique ne peut pas saturer les ressources nécessaires à une application de traitement urgent. Des exercices de panne permettent de mesurer le temps de bascule. La résilience de 9.03 est donc un objectif aussi important que la performance brute des modèles et doit apparaître dans les critères d’acceptation technique.
Gouvernance des modèles et des fournisseurs
Chaque modèle disponible doit posséder une fiche : fournisseur, version, licence, lieu d’exécution, données de test, limites connues, coût, fenêtre de contexte, incidents et date de réévaluation. La décision d’autoriser ou retirer un modèle doit être traçable.
Les applications métiers restent responsables de leur usage : l’inscription d’un modèle au catalogue ne signifie pas qu’il est adapté à une décision fiscale ou juridique. Le catalogue fournit une base technique commune, tandis que le responsable métier décide si les performances sont suffisantes pour son cas. Cette séparation évite que la DINUM ou un fournisseur prenne implicitement des décisions de politique publique par le simple choix de la technologie proposée aux administrations.
Approfondissement opérationnel et conditions de réussite
Gouverner le changement de modèle sans reconstruire chaque application
La plateforme d’inférence publique doit permettre de remplacer un modèle sans modifier toutes les applications qui l’utilisent. Les services métiers appellent une interface stable ; la plateforme associe ensuite chaque usage à un modèle autorisé, une version, des paramètres et des limites. Avant tout changement de version, un jeu d’essai métier mesure précision, taux de refus, hallucinations, temps de réponse et coût. Si le nouveau modèle améliore un critère mais dégrade fortement un autre, le basculement n’est pas automatique. La configuration précédente reste disponible pendant une période définie. Ce mécanisme transforme la diversité des modèles en avantage : l’État peut choisir le modèle adapté à la tâche au lieu de se retrouver enfermé dans un produit unique.
Organiser une capacité partagée sans créer un monopole informatique interne
Une plateforme commune ne doit pas devenir un passage obligé lent et centralisateur. Les administrations conservent la maîtrise de leurs cas d’usage, de leurs données et de leurs critères de qualité. La plateforme mutualise ce qui gagne à l’être : accès aux modèles, sécurité, métriques, quotas, facturation interne, observabilité et mécanismes de secours. Des interfaces documentées permettent aussi à un ministère de maintenir une capacité locale lorsqu’une contrainte technique ou de sécurité le justifie. La gouvernance publie ses délais d’intégration et ses coûts unitaires afin qu’une solution mutualisée puisse être comparée à une alternative. Le but n’est pas de créer un nouveau fournisseur captif de l’État, mais d’éviter que chaque administration reconstruise la même couche technique.
Définir une politique de routage selon l’usage, le coût et le niveau de risque
La plateforme ne choisit pas simplement le modèle le plus puissant. Chaque cas d’usage déclare ses besoins : type de tâche, langue, volume, sensibilité des données, temps de réponse et niveau d’erreur acceptable. Une politique de routage associe ces critères à une famille de modèles et peut préférer un modèle plus léger lorsque sa qualité suffit. Les usages sensibles peuvent être limités à des modèles ou environnements spécifiques. Les changements de routage sont versionnés afin de pouvoir expliquer pourquoi une même application a utilisé un modèle différent à deux dates. Cette logique réduit les coûts et la dépendance à un seul fournisseur tout en permettant des essais comparatifs. Elle évite aussi que chaque équipe contourne la plateforme pour sélectionner directement son fournisseur favori sans évaluation commune.
Construire des jeux d’évaluation représentatifs des tâches administratives
Un classement général de modèles ne dit pas si un système sait résumer correctement une circulaire, extraire une information d’un dossier ou répondre en français administratif sans inventer de référence. Chaque grande famille de tâches dispose donc d’un jeu d’évaluation contrôlé, composé de cas réalistes et suffisamment renouvelé pour éviter l’optimisation artificielle. Les résultats mesurent exactitude, refus approprié, robustesse, coût et temps de réponse. Lorsque l’erreur peut porter atteinte à un droit, l’évaluation inclut des cas difficiles et des scénarios de contestation. Les jeux contenant des informations sensibles restent protégés, mais la méthode et les indicateurs peuvent être publiés. La sélection d’un modèle devient ainsi une décision fondée sur les besoins publics et non sur la réputation commerciale du moment.
Mettre en place des quotas et un suivi des coûts sans bloquer l’expérimentation
L’accès mutualisé peut provoquer une consommation difficile à anticiper. La plateforme attribue donc des quotas souples par projet, avec alertes avant dépassement et procédure simple d’augmentation lorsqu’un usage prouve son intérêt. Les expérimentations disposent d’un niveau gratuit ou limité ; la production importante doit connaître son coût réel. Les équipes voient le nombre de requêtes, les volumes, le coût par unité et l’évolution mensuelle. Un projet qui multiplie les appels sans gain métier est réexaminé. Cette transparence ne vise pas à facturer bureaucratiquement chaque ministère, mais à empêcher que le caractère partagé de l’infrastructure rende les coûts invisibles. Elle facilite aussi la négociation avec les fournisseurs et l’arbitrage entre modèles plus ou moins coûteux.
Prévoir les incidents de modèle comme des incidents de service
Une mise à jour peut modifier le comportement d’un modèle sans panne matérielle. La plateforme traite donc comme événements de production les dégradations de qualité, hausses de refus, changement inattendu de format ou dérives de coût. Les applications critiques disposent d’une version de secours ou d’un mode dégradé. Les équipes sont informées des changements planifiés et peuvent tester une nouvelle version avant bascule. Les incidents importants sont enregistrés avec leur impact et la mesure corrective. Cette discipline rapproche l’IA des pratiques d’exploitation des systèmes d’information : on ne suppose pas qu’un modèle restera identique parce que l’interface technique n’a pas changé. La continuité de service inclut désormais la continuité du comportement attendu.
Sources primaires et institutionnelles
Les affirmations de droit ou d’état de l’art ci-dessus sont rattachées à des sources publiques. Les hypothèses propres au Plan Delta-Sierra sont signalées comme propositions et ne sont pas présentées comme des chiffres officiels.
- Albert API ↗
- DINUM — inférence mutualisée ↗
- Infrastructure sécurisée ↗
- Cour des comptes — stratégie nationale IA ↗
Date de vérification : 12 août 2026. Le cadre de l’IA évolue rapidement ; les dates d’application du règlement européen sont vérifiées contre le règlement (UE) 2026/1744.