Achats publics IA : le dossier manque encore

L’IA publique a longtemps ete racontee comme une question de strategie : quel pays aura son plan, son agence, ses laboratoires, ses cas d’usage, ses champions. En 2026, le sujet descend d’un cran. Il arrive dans le dossier d’achat.

C’est moins noble qu’une strategie nationale et beaucoup plus decisif. Une administration peut annoncer une IA responsable, signer une charte, publier une doctrine et former ses agents. Si l’appel d’offres ne demande pas les bonnes preuves, si le contrat laisse les donnees captives, si l’audit arrive trop tard, si le recours n’est pas prevu, le reste devient une decoration.

Les rapports recents de l’OCDE donnent le signal faible. L’IA est deja employee dans presque tous les gouvernements et les financements existent largement. Mais le soutien central a l’achat d’IA reste plus rare que les budgets, les formations ou les strategies. Autrement dit : les administrations veulent acheter, mais le muscle d’achat n’est pas encore au niveau de ce qu’elles veulent acheter.

Ce decalage est banal. Il est aussi dangereux. L’achat public a ete construit pour comparer des prestations, des prix, des delais, des garanties et des responsabilites. L’IA y ajoute des objets moins visibles : donnees d’entrainement, journaux d’usage, seuils d’erreur, droits d’audit, explicabilite suffisante, robustesse, supervision humaine, reprise de service, portabilite et degradation dans le temps.

Le vrai chantier n’est donc pas seulement de choisir un fournisseur. C’est de savoir ce que l’administration achete quand elle croit acheter de l’IA.

Le budget ne fait pas la capacite

Un financement peut lancer un pilote. Il ne sait pas rediger une clause. Il ne sait pas dire quelles donnees sortent du perimetre, quelle metrique prouve un gain, qui reprend la main quand la recommandation est contestee ou comment l’administration quitte le fournisseur sans perdre son historique.

C’est la partie peu spectaculaire de l’IA publique. Elle se joue dans les annexes, les grilles d’evaluation, les exigences de journalisation, les livrables de fin de marche, les droits de test et les obligations de cooperation. Elle n’a presque jamais la simplicite d’une demonstration.

L’OCDE observe que les gouvernements financent davantage l’IA qu’ils n’equipent leurs acheteurs publics pour la procurer. Ce n’est pas une nuance administrative. C’est le coeur du probleme. Un acheteur qui ne sait pas interroger un systeme probabiliste se retrouve a acheter des promesses de precision, des tableaux de bord proprietaires et des garanties vagues.

La question minimale devrait etre plus froide : que pourra verifier l’administration elle-meme dans douze mois ?

Si la reponse depend entierement du fournisseur, le marche a deja mal commence.

Les clauses types sont un debut, pas une politique

Les clauses contractuelles europeennes pour l’achat d’IA ont une vertu evidente : elles donnent aux acheteurs un langage commun. Elles obligent a parler de risque, de conformite, de documentation, de responsabilite et de versions. Elles evitent que chaque commune, ministere ou hopital reinvente seul un contrat face a un vendeur mieux equipe.

Mais une clause type ne connait pas le service. Elle ne sait pas si l’IA orientera des usagers, resumerera des dossiers, priorisera une file, detectera une fraude ou aidera un agent a rediger. Elle ne sait pas quel tort concret une erreur peut produire. Elle ne sait pas non plus quel compromis local est acceptable entre rapidite, cout, transparence et controle humain.

Le contrat doit donc etre alimente par un travail metier avant l’achat. Pas un grand manifeste. Un dossier simple : usage vise, donnees autorisees, decisions exclues, responsable humain, criteres d’arret, mesure avant/apres, cas limites, chemin de recours.

Sans ce dossier, les clauses deviennent une couverture juridique. Elles montrent que l’administration a demande quelque chose. Elles ne prouvent pas qu’elle saura tenir le systeme.

Acheter une IA, c’est acheter une sortie

L’enfermement fournisseur n’est pas nouveau dans le numerique public. L’IA l’aggrave parce qu’elle melange plusieurs dependances : modele, interface, donnees, prompts, traces, evaluations, connecteurs, ajustements locaux et habitudes des agents. Plus le systeme s’integre au travail, plus la sortie devient couteuse.

La Commission europeenne pousse les administrations vers des standards ouverts, des modeles ouverts et des ecosystemes interoperables. Ce n’est pas seulement une preference ideologique pour l’open source. C’est une maniere de remettre de la concurrence et du controle dans un marche qui peut vite devenir opaque.

Un appel d’offres IA devrait donc decrire la sortie avant meme l’entree. Quelles donnees seront exportables ? Dans quel format ? Quels journaux resteront lisibles ? Quelle documentation permettra a un autre prestataire de reprendre ? Quels composants sont substituables ? Combien coute la fin du contrat ?

La mauvaise question est : ce fournisseur a-t-il la meilleure demo ? La bonne question est : que reste-t-il a l’administration si ce fournisseur disparait, augmente ses prix ou change ses conditions ?

La confiance se joue dans les recours

Les enquetes de confiance de l’OCDE montrent une tension simple : les citoyens peuvent croire que l’IA ameliorera l’efficacite des services publics tout en doutant de son equite, de sa transparence ou de la protection des donnees. Cette hesitation est rationnelle. Un service plus rapide n’est pas automatiquement un service plus juste.

Le contrat doit donc acheter des recours, pas seulement des fonctions. Si un usager conteste une reponse, qui peut reconstruire le chemin ? Si un agent signale une erreur, qui la corrige ? Si le modele degrade un groupe de cas, qui le voit ? Si une mise a jour change le comportement, qui l’autorise ?

Ces questions paraissent lourdes avant de deployer. Elles sont legeres comparees a un systeme public impossible a expliquer apres coup.

L’IA administrative doit accepter un principe simple : toute automatisation qui touche un droit, une priorite, une orientation ou une decision doit laisser une trace contestable. Pas forcement une explication mathematique complete. Au minimum une trace exploitable : source, version, entree, sortie, validation, responsable, date.

Sans cela, l’administration n’a pas modernise le service. Elle a privatise une partie de sa memoire.

Le pilote gratuit coute souvent plus tard

Beaucoup de projets publics commencent par un pilote rassurant. Perimetre limite, faible engagement, calendrier court, promesse de “tester avant de generaliser”. C’est parfois une bonne prudence. C’est aussi parfois la maniere la plus douce d’entrer dans une dependance.

Un pilote IA produit vite des habitudes. Les agents apprennent une interface. Les donnees sont branchees. Les responsables voient une demonstration utile. Les tableaux de bord commencent a circuler. Au moment de transformer l’essai en marche durable, l’administration ne compare plus un besoin abstrait. Elle compare le fournisseur deja installe avec tous les autres qui arrivent trop tard.

Le dossier d’achat devrait donc cadrer le pilote comme un achat miniature, pas comme une parenthese hors regles. Les donnees de test doivent etre definies. Les traces doivent rester recuperables. Les resultats doivent etre evaluables par l’administration. Les criteres de generalisation doivent etre ecrits avant la demonstration. Sinon le pilote devient une preuve fabriquee par celui qui veut vendre la suite.

La phrase “ce n’est qu’un test” est dangereuse quand le test touche une organisation publique. Il faut deja savoir ce qui sera mesure, ce qui sera refuse et ce qui devra etre rendu si l’experience s’arrete.

Les acheteurs doivent devenir des gardiens du temps long

Un projet IA vieillit mal s’il n’est pas surveille. Les donnees changent, les usages changent, les textes changent, les modeles changent, les interfaces changent. Un achat public qui ne regarde que la mise en service rate la moitie du sujet.

Le dossier devrait donc imposer des rendez-vous de preuve. Avant deploiement : test sur cas locaux. Apres trois mois : mesure des erreurs et reprises humaines. Apres six mois : revue des couts complets. A chaque mise a jour : journal des changements. En fin de contrat : restitution des donnees et des traces.

Ce calendrier n’est pas une lourdeur de plus. C’est l’equivalent administratif de la maintenance. On n’achete pas un pont sans inspection. On ne devrait pas acheter une IA publique sans calendrier de verification.

Cette discipline protege aussi les fournisseurs serieux contre les promesses intenables.

La prochaine maturite de l’IA publique ne viendra peut-etre pas du meilleur modele. Elle viendra d’acheteurs capables de dire non a une demo brillante mais invendable dans le temps long.

Le vrai appel d’offres commence par une phrase courte

Une administration qui veut acheter de l’IA devrait pouvoir terminer cette phrase : “Nous saurons que ce systeme fonctionne si…”

Si la suite parle seulement d’adoption, de satisfaction generale ou de modernisation, le besoin n’est pas pret. Si elle parle de delai reduit, d’erreur diminuee, de recours plus clair, de charge agent mesuree, de decision mieux documentee ou de sortie fournisseur possible, le dossier commence a tenir.

L’IA publique n’a pas besoin de moins d’ambition. Elle a besoin d’achats plus adultes. Les budgets existent. Les strategies existent. Les clauses commencent a exister. Il manque encore, souvent, le dossier qui relie l’achat a la preuve.

Ce dossier ne fera pas une annonce spectaculaire. Il evitera seulement que l’administration decouvre trop tard qu’elle n’a pas achete un service, mais une dependance.