Achats publics d’IA : ce que change le guide DINUM, et comment répondre sans survendre

Un guide qui change surtout une chose : fini l’IA “magique” dans les marchés publics

Tu vois passer des appels d’offres “IA” de mairies, d’EPCI, de départements, d’hôpitaux. Jusqu’ici, beaucoup de consultations restaient floues, et beaucoup de réponses aussi. Le guide DINUM achats IA change l’ambiance. Pas parce qu’il invente de nouvelles lois. Mais parce qu’il standardise les questions que les acheteurs publics vont poser, et donc les preuves qu’ils vont attendre.

Point important pour parler le même langage qu’un service achat ou un juriste : ce “guide DINUM” est en réalité le premier volet du guide pratique des achats d’IA publié par la Direction des affaires juridiques (DAJ), élaboré sous l’égide du Conseil national de la commande publique (CNCP), avec contribution de la DINUM, et destiné aux acheteurs publics. Source : numerique.gouv.fr, page “Guide pratique achats intelligence artificielle”.

Le message de fond est simple : si tu vends de l’IA au secteur public, tu dois prouver ce que tu fais. Traçabilité, risques, conformité, sécurité, maîtrise des données, réversibilité. Et de plus en plus, sobriété et impacts mesurables.

1) Ce qu’un acheteur public va demander (et comment il va le formuler)

Le guide vise à aider les acheteurs à mieux cadrer, mieux qualifier le besoin, et mieux sécuriser le marché. Donc toi, éditeur ou intégrateur à Lyon, tu dois anticiper un cahier des charges IA plus “contrôle de gestion + RSSI + DPO”, moins “slide deck”.

1.1 La traçabilité : “qui a fait quoi, quand, avec quel modèle, et sur quelles données”

Dans des consultations locales, on voit déjà des exigences explicites de sécurité, traçabilité, supervision humaine et maîtrise des risques. Exemple cité en région lyonnaise : un marché mentionne ces éléments noir sur blanc, ainsi qu’une conformité continue des traitements de données. Source : marches-publics.com (appel d’offre de Courzieu).

Traduction opérationnelle : on va te demander des logs exploitables. Pas “on logge”. Exploitables, c’est-à-dire :

• journal des requêtes et des réponses (au bon niveau de sensibilité, avec masquage si besoin),
• journal des actions automatiques si ton système exécute des tâches,
• traçabilité des changements de prompts, règles, modèles, paramètres, versions,
• traçabilité des données injectées (sources, dates, jeux, versions),
• capacité d’audit : export, recherche, rétention, horodatage.

Ce n’est pas un “bonus”. C’est ce qui permet à une collectivité de répondre à une contestation, un incident, ou un contrôle.

1.2 La supervision humaine : pas juste “human in the loop”, mais un processus

Les acheteurs publics veulent éviter deux pièges : l’automate qui décide seul, et le “pilotage par personne” (shadow IA). Résultat : la supervision humaine devient une exigence contractuelle, pas une promesse marketing.

Ils vont te demander :

• où intervient l’humain (validation avant action, revue après action, échantillonnage),
• qui est responsable (rôles nommés côté client, côté fournisseur),
• avec quels seuils (score de confiance, règles de blocage, listes rouges),
• comment on coupe (désactivation, retour arrière, mode dégradé).

Si tu ne sais pas le décrire, tu ne le maîtrises pas. Et tu vas te faire sortir au moment des questions.

1.3 La conformité données personnelles : RGPD “à tout moment”, pas à la fin

Dans l’exemple de marché local déjà cité, l’objectif inclut une conformité “à tout moment” des traitements. Source : marches-publics.com (Courzieu). C’est exactement ce qui remonte partout : l’acheteur veut éviter le scénario “on fait un POC, on verra plus tard”.

Concrètement, attends-toi à des questions sur :

• ton rôle RGPD (sous-traitant, responsable conjoint, etc.),
• la minimisation des données,
• la gestion des durées de conservation,
• les transferts hors UE,
• les sous-traitants en chaîne,
• les mécanismes de suppression et de rectification (quand applicable).

Et attention à un point très fréquent : les données “d’usage” finissent dans les logs. Si tu ne maîtrises pas ça, tu as un problème.

1.4 Maîtrise des données, souveraineté, et réversibilité : le trio qui revient tout le temps

Le rapport de l’Inspection générale des finances sur le déploiement de l’IA dans les administrations met en avant la nécessité de maîtriser les données et la réversibilité, dans un contexte où des usages publics pourraient relever de catégories à risque. Source : igf.gouv.fr.

Ce que ça donne dans un cahier des charges IA :

• où sont traitées les données (pays, prestataires, environnements),
• qui peut y accéder (support, admin, éditeur, infogérant),
• comment les données sont isolées (multi-tenant vs dédié),
• comment le client récupère ses données, ses paramétrages, ses journaux, ses modèles fine-tunés si applicable,
• en combien de temps, dans quels formats, avec quel accompagnement.

La réversibilité n’est pas une phrase dans un contrat. C’est un plan de sortie testable.

1.5 Sécurité : architecture, chiffrement, contrôle d’accès, et gestion des incidents

Le guide outille les acheteurs pour poser des exigences sécurité plus cadrées. Et le terrain pousse pareil. Si tu proposes un assistant, un RAG, un agent, ou une chaîne d’automatisation, tu dois être clair sur :

• l’architecture (où passent les flux, où sont stockées les données),
• le chiffrement en transit et au repos,
• la gestion des identités et des accès (SSO, MFA, RBAC),
• la séparation des environnements (dev, test, prod),
• le traitement des vulnérabilités (process, délais),
• la détection et réponse incident (logs, alerting, procédures).

Ne vends pas “sécurisé”. Vends des mécanismes, et accepte de les faire auditer.

1.6 Achats responsables : sobriété, métriques, et clauses environnementales

Ça aussi, ça se structure. Une fiche opérationnelle co-produite par la DINUM, la DAE et l’Écolab vise à intégrer des exigences responsables, frugales et mesurables dès la conception et la passation du marché. Source : achats-durables.gouv.fr.

Le Sénat rapporte que cette fiche rappelle que l’acheteur peut intégrer au CCTP des exigences sur :

• la mesure de l’impact environnemental,
• la consommation d’eau et d’énergie,
• des indicateurs de performance d’hébergement,
• la maîtrise du nombre d’entraînements et réentraînements.

Source : senat.fr (rapport cité). Donc oui, on va te demander des chiffres, ou au minimum une méthode de mesure et des engagements réalistes.

2) Gabarit : le “dossier fournisseur IA” à fournir dans tes réponses

Si tu veux gagner du temps et arrêter de bricoler chaque réponse, construis un dossier standard, versionné, que tu adaptes ensuite au contexte. Objectif : répondre aux marchés publics intelligence artificielle sans survendre, en mettant des preuves à la place des promesses.

2.1 Bloc “conformité et risques”

• Note RGPD : rôle (sous-traitant ou autre), liste des sous-traitants, transferts, mesures, et ce que tu attends du client.
• Registre de traitement ou extrait pertinent (si applicable) et description des finalités.
• Supervision humaine : schéma de décision, étapes de validation, seuils, et responsabilités.
• Matrice de risques : sécurité, erreurs, biais, dérives, indisponibilité, et mesures de maîtrise (revue humaine, seuils, désactivation, fallback). Ces exigences existent déjà en consultation locale. Source : marches-publics.com (Courzieu).

2.2 Bloc “traçabilité et preuve”

• Politique de logs : quels événements sont loggés, où, combien de temps, qui y accède, comment on exporte.
• Auditabilité : capacité à reconstruire un incident (timeline), à prouver une action, à corriger.
• Traçabilité des versions : modèle, paramètres, prompt système, règles, connecteurs, base documentaire.
• Preuves de supervision : exemples de rapports de revue, workflow d’escalade, exemples de “cas bloqués”.

2.3 Bloc “données” (le morceau le plus scruté)

Le rapport IGF insiste sur la maîtrise des données et la réversibilité. Source : igf.gouv.fr. Donc tu dois cartographier précisément :

• données d’entrée (types, sources),
• données de sortie (où elles sont stockées, qui y accède),
• données d’apprentissage si tu entraînes,
• données de réentraînement si tu réentraînes,
• données présentes dans les logs,
• localisation de traitement et d’hébergement.

Ajoute un point clair : tes données client servent ou non à entraîner. Et si non, écris-le contractuellement.

2.4 Bloc “sécurité et hébergement”

• Schéma d’architecture : composants, flux, zones de confiance.
• Hébergement : localisation, options (UE, France), modalités d’exploitation.
• Contrôles d’accès : SSO, MFA, RBAC, comptes techniques, secrets.
• Chiffrement : en transit, au repos, gestion des clés.
• Gestion des vulnérabilités : politique, délais, preuve (bulletins, process).
• Gestion incident : procédure, délais de notification, points de contact, préservation des preuves.

2.5 Bloc “tests, performance, et limites”

Si tu veux éviter de survendre, documente tes limites. C’est paradoxalement ce qui rassure un acheteur public.

• Jeu de tests : méthode, cas typiques, cas limites, taux d’erreur.
• Critères d’acceptation : ce que tu garantis, ce que tu mesures, ce que tu ne garantis pas.
• Robustesse : tests de dérive, tests de données manquantes, tests de bruit.
• Fallback : mode “sans IA”, ou mode “règles”, ou redirection humaine.

2.6 Bloc “SLA, support, et réversibilité”

• SLA : disponibilité, délais de support, délais de correction.
• Plan de continuité : sauvegardes, redondance, dépendances critiques.
• Réversibilité : plan de sortie, formats d’export, délais, coûts, assistance. La réversibilité est un point structurant côté administrations. Source : igf.gouv.fr.

2.7 Bloc “achats responsables”

Prépare une annexe standard, parce que ça va revenir. La fiche DINUM, DAE, Écolab propose des questions de sourçage et des exemples de clauses. Source : achats-durables.gouv.fr (avec document téléchargeable).

• métriques suivies (énergie, hébergement, volumétrie),
• stratégies de sobriété (petits modèles quand possible, limitation des réentraînements, caching),
• engagements réalistes et vérifiables,
• reporting périodique au client.

3) Implications locales : collectivités AURA, éditeurs et ESN lyonnais, opportunités si tu cadres bien

À Lyon et en Auvergne-Rhône-Alpes, le marché potentiel est large : communes, Métropole, départements, Région, établissements de santé, syndicats, opérateurs publics. Ce qui change avec un guide d’achats IA, c’est la capacité des acheteurs à exiger des pièces standard. Donc les acteurs locaux qui industrialisent leur dossier vont prendre un avantage.

3.1 Pour les collectivités : moins de “solutionnisme”, plus de pilotage

Le guide s’inscrit dans un ensemble de ressources État sur l’IA dans le secteur public, dont un guide d’usage pour les agents publics (juin 2026). Source : ia.numerique.gouv.fr. Le mouvement est clair : l’administration veut des usages cadrés, traçables, défendables.

Conséquence : les marchés vont tendre vers :

• des périmètres plus précis,
• des phases pilotes avec critères de passage en production,
• des exigences de réversibilité et de maîtrise des données dès le départ,
• des clauses sécurité et environnement plus explicites.

3.2 Pour les éditeurs et intégrateurs lyonnais : le “dossier fournisseur IA” devient un produit

Dans beaucoup d’équipes locales, le savoir-faire existe. Ce qui manque souvent, c’est la preuve packagée. Si tu veux jouer sur les marchés publics intelligence artificielle, tu dois traiter ton dossier comme :

• un livrable versionné,
• un référentiel partagé entre commerce, tech, RSSI, DPO,
• un socle réutilisable d’un DCE à l’autre.

Ça évite le grand classique : une promesse commerciale trop large, puis un projet qui dérape au moment des audits, de la mise en production, ou des demandes juridiques.

3.3 Opportunité : gagner en crédibilité en disant “non” proprement

Le meilleur move, c’est de refuser les périmètres impossibles. Exemple typique : “IA qui détecte tout, explique tout, sans faux positifs, et décide automatiquement”. Dans le secteur public, c’est un carton rouge annoncé.

Ce que tu peux faire à la place :

• proposer un périmètre assistif (aide à la décision),
• documenter les limites,
• poser une supervision humaine contractuelle,
• donner des métriques de qualité et un protocole de test,
• prévoir un mode dégradé et une désactivation simple.

Tu perds peut-être un marché “buzz”. Tu gagnes une relation fournisseur long terme. Et dans le public, c’est ça qui paye.

3.4 Pour répondre à un cahier des charges IA sans se griller : 5 règles simples

• Remplacer les promesses par des preuves : docs, schémas, extraits de logs, exemples de rapports.
• Écrire noir sur blanc ce que tu ne fais pas : pas d’entraînement sur données client, pas d’autonomie d’action sans validation, etc.
• Cartographier les données : entrée, sortie, logs, apprentissage, réentraînement, localisation.
• Contractualiser la réversibilité : formats, délais, assistance, coût.
• Donner une méthode d’évaluation : jeu de tests, critères d’acceptation, mesure avant après.

Un plan d’attaque en 30 jours pour les fournisseurs lyonnais qui visent le public

Si tu es éditeur, intégrateur, ESN, ou cabinet à Lyon et que tu veux répondre proprement à des consultations IA, fais ça. Pas dans six mois. Maintenant.

• Semaine 1 : construire le sommaire du dossier fournisseur IA (les 7 blocs ci-dessus) et nommer un owner interne.
• Semaine 2 : produire la cartographie données + le schéma d’architecture + la politique de logs (même minimaliste, mais réelle).
• Semaine 3 : écrire la matrice de risques et le dispositif de supervision humaine, avec seuils et procédure de coupure.
• Semaine 4 : préparer un pack réversibilité + SLA + annexe achats responsables (métriques, méthode de mesure, engagements).

Après ça, tu peux répondre plus vite, plus propre, et sans survendre. Et tu matches ce que le guide DINUM achats IA pousse côté acheteurs, même si le portage est DAJ et CNCP avec contribution DINUM. Source : numerique.gouv.fr.

Si tu veux cadrer le fond avant même de parler “modèles”, garde une méthode simple : besoin, données, risques, exploitation. Pour une base utile côté cadrage projet, tu peux aussi t’appuyer sur ce guide publié sur Lyon IA : Rédiger un cahier des charges pour un prestataire IA.