Achats d’IA : l’acheteur public vous sonde avant d’écrire le marché
Le Conseil national de la commande publique publie le premier volet de son guide des achats d'IA. Il décrit ce que l'acheteur doit savoir de votre solution avant même de rédiger le dossier de consultation.
Le Conseil national de la commande publique (CNCP) a mis en ligne le premier volet de son guide pratique des achats d’intelligence artificielle, intitulé « Fondamentaux de l’IA ». Le document est destiné aux acheteurs publics, pas à leurs fournisseurs. C’est précisément ce qui devrait vous intéresser : il détaille, étape par étape, ce que votre interlocuteur est désormais invité à savoir de votre solution avant d’avoir rédigé la première ligne du dossier de consultation.
Pour les éditeurs, intégrateurs et cabinets qui vendent de l’IA au secteur public, la conséquence est simple : le calendrier de la décision se déplace vers l’amont.
Un guide d’acculturation, pas un cahier des charges type
Le volet publié n’impose rien. Il a été conçu, selon la présentation qu’en fait l’éditeur juridique Weka, dans :
une logique d’acculturation des acheteurs à l’écosystème IA
Le texte a été élaboré sous l’égide du CNCP, avec les contributions de la direction des affaires juridiques, de la DINUM, de la direction des achats de l’État et de fédérations professionnelles. Il s’organise en fiches :
- la première distingue le modèle d’IA du système d’IA (SIA) — une distinction qui finira dans votre dossier de consultation, et qui détermine ce que l’acheteur croit acheter ;
- la deuxième traite du sourcing et de la définition du besoin ;
- une annexe fournit un questionnaire destiné à structurer le besoin, couvrant la protection des données, la sécurité des systèmes d’information et les contraintes techniques.
Un guide non prescriptif reste un guide que l’acheteur ouvrira devant vous. Les questions de l’annexe deviendront ses questions.
Le sourcing devient le moment où tout se joue
La méthode décrite demande que le besoin soit cadré avec l’ensemble des parties prenantes internes, en identifiant séparément les exigences fonctionnelles, les contraintes techniques et les contraintes réglementaires. Concrètement :
- le service demandeur définit le processus métier concerné, les tâches que le système exécutera, la performance attendue et les contraintes opérationnelles ;
- le responsable de la sécurité des systèmes d’information (RSSI) identifie les jeux de données et les systèmes touchés, et fixe les niveaux de sécurité exigés ;
- le sourcing proprement dit intervient ensuite : repérer les acteurs du marché, évaluer leur capacité, estimer les coûts et les ressources — formation des agents, budget, montée en charge.
Autrement dit : quand l’avis de marché paraît, l’acheteur a déjà une représentation du marché, une estimation de coût complet et un niveau de performance en tête. Se présenter à la publication, c’est se présenter en retard. Le phénomène n’est pas propre à l’IA : il est simplement mécanique sous les seuils, où le relèvement des seuils de dispense validé par le Conseil d’État fait du sourcing la procédure elle-même.
Il y a un corollaire moins confortable. Le cadre fonctionnel fixé en amont décide de ce que vous pourrez encore proposer ensuite : une architecture différente de celle qu’imaginait l’acheteur deviendra une variante, avec le régime d’autorisation que l’on sait.
La cartographie des données, et la série de questions qui en découle
C’est la partie la plus exigeante du guide, et celle qui aura le plus d’effet sur vos réponses. L’acheteur doit cartographier et classifier les données qu’utilise le système, leur qualité et leur représentativité conditionnant la performance et la fiabilité. Le guide insiste sur un point souvent oublié : l’usage du système produit lui-même des données — métadonnées, journaux techniques, invites (prompts), données des utilisateurs — susceptibles d’influer sur son évolution.
La cartographie doit couvrir les flux, les conditions d’accès, les mesures de protection, les flux de retour des résultats vers l’administration et la localisation géographique des composants. L’objectif est explicite : identifier l’exposition à des fournisseurs soumis à des lois extraterritoriales. Elle doit enfin se traduire en exigences précises dans les pièces du marché et dans le contrat.
| Ce que l’acheteur doit cartographier | Ce que vous devrez pouvoir répondre, par écrit |
|---|---|
| Flux de données et conditions d’accès | Qui accède à quoi, depuis où, avec quelle traçabilité |
| Données produites par l’usage (journaux, invites, métadonnées) | Si elles alimentent l’amélioration du modèle, et comment s’y opposer |
| Localisation géographique des composants | Pays d’hébergement de chaque brique, sous-traitants inclus |
| Exposition aux lois extraterritoriales | Votre structure capitalistique et vos dépendances techniques |
| Usages autorisés et restrictions de réutilisation | Ce que vos conditions générales permettent — et ce qu’elles interdisent déjà |
| Règles de conservation et de suppression | Durées, mécanisme de purge, réversibilité en fin de contrat |
Aucune de ces questions n’est nouvelle pour un acheteur aguerri. Ce qui change, c’est qu’elles arrivent groupées, sous forme de questionnaire, et avant la mise en concurrence. Un fournisseur qui improvise sur la localisation de ses composants ou sur le sort de ses journaux d’invites se disqualifie à un stade où aucun recours n’existe, puisqu’aucune procédure n’est encore ouverte.
Le second volet, fin novembre, portera sur les clauses
Un deuxième volume consacré aux clauses contractuelles applicables aux fournisseurs de solutions d’IA est annoncé pour la fin novembre 2026. C’est celui qu’il faudra lire ligne à ligne : il déterminera la répartition des responsabilités sur des sujets que le marché privé n’a pas tranchés non plus.
Deux d’entre eux reviendront à coup sûr. Celui de la responsabilité de paramétrage d’abord : dès lors qu’un agent est configuré par l’acheteur, la frontière se brouille, et celui qui paramètre un agent conversationnel en devient le fournisseur au sens du règlement européen. Celui de la facturation ensuite : les modèles à la consommation s’accordent mal avec les engagements de prix ferme, et l’on a déjà vu que la facture des agents IA se règle à l’exécution, pas à la signature.
Quatre réponses à écrire avant qu’on vous les demande
- Une fiche de localisation de chaque composant de votre chaîne, sous-traitants et hébergeurs compris, tenue à jour.
- Une position écrite sur les données d’usage : journaux, invites et métadonnées alimentent-ils l’entraînement, et par quel mécanisme un client peut-il l’exclure.
- Un scénario de réversibilité chiffré : format d’export, délai, coût, preuve de suppression.
- Une définition de la performance attendue que vous pouvez défendre : sur quel échantillon, mesurée comment, et ce que vous refusez de garantir.
Le dernier point est le plus délicat, et le plus rentable. Le guide invite l’acheteur à exiger une performance attendue dès la définition du besoin. Le fournisseur qui arrive avec sa propre métrique, documentée et bornée, cadre la discussion. Celui qui attend la grille d’évaluation la subit.
Le premier volet du guide est consultable sur le site de la direction des affaires juridiques, et l’analyse détaillée de son contenu a été publiée par Weka.
