Le secteur public a besoin d'un approvisionnement capable de dire non.

Une autorité publique ne devient pas responsable en signant pour un système d'IA. Elle le devient lorsque ses exigences, ses preuves, son autorité humaine,...

Le secteur public a besoin d'un approvisionnement capable de dire non.

Le document qui peut mettre fin à un achat

Un dossier de marché public commence souvent par une demande qui semble anodine : trouver un système capable d’aider à accomplir une tâche. La demande chemine ensuite à travers un énoncé du problème, une consultation du marché, un ensemble d’exigences, une évaluation, un contrat et, si le processus est sain, une décision qui peut encore arrêter le travail. Cette dernière possibilité est facile à perdre de vue. Une fois que l’argent, les calendriers et l’attention politique se sont concentrés sur un achat, le mot « non » commence à ressembler à un échec de livraison. Dans le travail public, il peut s’agir de la décision la plus utile du dossier.

Le droit européen des marchés publics considère déjà une offre comme plus qu’un concours de promesses séduisantes. La directive 2014/24/UE dispose que les critères d’attribution doivent permettre une concurrence effective et équitable et doivent être accompagnés de dispositions permettant au pouvoir adjudicateur de vérifier les informations fournies par les soumissionnaires. La directive précise également que les critères ne doivent pas conférer au pouvoir adjudicateur une liberté de choix illimitée. Un acheteur public doit décrire ce qui importe, expliquer comment cela sera pondéré et vérifier si l’offre y répond réellement. Ce n’est pas une note administrative en bas de page. C’est la forme juridique d’une décision que d’autres personnes doivent pouvoir comprendre et contester.

L’IA rend la discipline ancienne plus difficile, car un fournisseur peut proposer un système dont le comportement dépend des données, des mises à jour du modèle, des invites, des seuils, des intégrations, des personnes et d’un service qui peut évoluer pendant que le contrat est encore chaud. La brochure peut rester la même pendant que la réalité qui se cache derrière bouge. Une équipe d’achat doit donc acheter plus qu’une interface. Elle doit acheter une capacité délimitée, la preuve que cette capacité est adaptée, l’autorité pour la superviser et un moyen crédible de l’arrêter ou de la remplacer.

Le secteur public a besoin de marchés publics capables de dire non, car le secteur public ne peut pas externaliser son jugement. Un fournisseur peut fournir un modèle, un flux de travail, un service hébergé ou un ensemble d’outils. Il ne peut pas fournir la légitimité de la décision prise avec eux. L’autorité doit toujours savoir quel problème elle résout, quels intérêts peuvent être affectés, quelles preuves soutiennent le système, quelle personne peut intervenir et comment le service se poursuivra si le fournisseur change de cap. Une signature n’est pas un transfert de responsabilité. C’est un enregistrement attestant que la responsabilité a été organisée.

Cet article suit cette organisation depuis la première phrase d’une exigence jusqu’à la dernière ligne d’un registre de sortie. Il s’appuie sur des orientations publiques européennes et des documents relatifs aux marchés publics comme preuves. Les modèles pratiques sont des recommandations, et non des affirmations selon lesquelles chaque autorité doit utiliser une seule forme. Toute situation inventée est signalée comme hypothétique. Un bureau plausible, un appel d’offres soigné et un échec dramatique ne sont pas des preuves simplement parce qu’ils correspondent à un récit familier.

Un acheteur public achète une promesse deux fois

Chaque achat public comporte deux promesses. La première est la promesse du fournisseur concernant un produit ou un service. La seconde est la promesse de l’autorité envers les personnes qui dépendent du travail : que l’argent a été dépensé pour un objectif public défini, que la décision peut être expliquée, que les droits pertinents ont été pris en compte et que quelqu’un reste responsable lorsque le système se trompe. La deuxième promesse est celle qui survit à l’événement de lancement.

Les marchés publics liés à l’IA rendent souvent la première promesse vivante et la seconde vague. Une démonstration peut montrer un résumé fluide, une liste classée ou une réponse rapide. Elle montre rarement qui peut rejeter le résultat, ce qui se passe lorsqu’une source est manquante, comment un changement est approuvé, si les enregistrements peuvent être exportés, ou quelle personne peut suspendre le service sans négocier sa propre autorité en plein incident. Ces questions sont moins cinématographiques. Ce sont aussi les questions qui déterminent si un organisme public peut rester aux commandes.

The European Commission’s Public Buyers Community describes its updated EU model contractual AI clauses in three parts: a full version for high-risk AI aligned with the AI Act, a light version that can be customised for non-high-risk AI, and commentary on how to use and adapt the clauses. The distinction matters. A model clause is not a magic stamp that makes a procurement suitable. It is a starting point for allocating obligations between a public organisation and a supplier, in a contract whose scope, purpose and evidence still have to be decided by the buyer.

A buyer should therefore ask what it is actually promising to the public before it asks what a vendor can demonstrate. Is the authority promising a faster route through a backlog, a more consistent first review, a safer inspection, a better use of scarce expertise, or simply an experiment whose limits are visible? Each purpose creates different evidence and different reasons to stop. A system that drafts internal notes may need a different authority boundary from one that ranks applications for a service that people cannot avoid.

Consider a hypothetical evaluation team reviewing a tool that summarises supplier submissions. The team may decide that the task is suitable for assistance, but only if the summary preserves exclusions, conditions and dates and points reviewers back to the source passages. If the supplier cannot show how those requirements will be tested, the team should be able to decline the tool or narrow the contract. That is not an accusation about the supplier. It is a conclusion about the evidence available for the defined purpose.

The same reasoning applies when the problem is attractive but poorly bounded. A public body may want to predict demand, prioritise inspections or route correspondence. Those verbs conceal the decisions underneath. What counts as demand. What does priority change. Which correspondence can be safely routed without a human reading it. The first no may be to the scope of the problem, not to the use of software. Refusing an unclear purchase is often how an authority protects the useful part of the work from an untestable part.

Write the problem before the solution

Procurement becomes fragile when a product category arrives before a public problem has been named. Artificial intelligence is especially good at creating this order because the same model can be presented as a writing assistant, a classifier, a search layer or an agent depending on the slide. The authority needs to describe the work in terms that remain meaningful when the supplier, model family and interface are removed.

The Dutch Algoritmekader, maintained for public organisations, puts this work among its recommended measures. It asks organisations to describe the intended purpose and the data used, determine the applicable risk group, establish the impact if the algorithm does not work as intended and decide whether a solution should be developed or bought. It also points to a project start architecture for developing or procuring algorithms. These are not procurement decorations. They are ways of making the problem legible before an answer is offered.

A good requirement begins with the decision or service that must improve, the people who perform or receive it, the information the system may use, the information it must not use and the human authority that remains. It states the conditions under which the system is useful and the conditions under which it must not be used. It names the records that need to exist when the output is accepted, rejected, corrected or escalated. It does not need to predict the supplier’s internal design. It needs to define the public capability that can be inspected.

Voici le point où les exigences fonctionnelles et de performance comptent. La directive 2014/24/UE exige que les spécifications techniques soient suffisamment précises pour que les soumissionnaires comprennent l'objet du marché et que les pouvoirs adjudicateurs puissent évaluer la manière dont les offres répondent aux critères. Une exigence telle que « fournir une solution intelligente » ne constitue pas un test utile. Une exigence telle que « conserver les passages sources utilisés dans un projet, afficher la date de consultation, permettre à un évaluateur de rejeter le projet et exporter le dossier résultant » se rapproche davantage d'un besoin public vérifiable. Elle décrit un comportement et un parcours de preuve plutôt qu'un effet de mode.

Les exigences doivent également délimiter le périmètre de la tâche. Un pouvoir adjudicateur peut indiquer qu'un système peut suggérer un itinéraire mais ne peut pas prendre la décision finale. Il peut préciser qu'une recommandation ne doit pas être utilisée lorsqu'une source spécifiée est absente ou contradictoire. Il peut exiger une voie humaine pour une personne concernée qui souhaite contester le résultat. Ces contraintes ne sont pas hostiles. Ce sont les conditions dans lesquelles l'achat reste un service public plutôt qu'un processus privé arborant un logo gouvernemental.

Un énoncé de problème restreint n'est pas un manque d'ambition. C'est une manière de rendre l'ambition responsable. Si le pouvoir adjudicateur ne peut pas expliquer quelle étape le système modifie, qui en bénéficie, ce qui peut mal tourner et ce qu'une personne peut faire ensuite, il n'est pas prêt à comparer les fournisseurs. La bonne action peut être une phase de découverte supplémentaire, une solution sans IA, un petit projet pilote contrôlé ou aucun achat du tout. Le dossier de marché doit laisser de la place à chacune de ces réponses.

Transformer les exigences en preuves

Le mot « preuve » est utilisé de manière vague dans les marchés publics technologiques. Une présentation du fournisseur, une démonstration du produit et une déclaration selon laquelle le système est digne de confiance peuvent toutes être des apports utiles. Aucune n'est automatiquement une preuve qu'une exigence est satisfaite. Une preuve doit être liée à une affirmation, un test, un périmètre et une personne qui peut l'examiner. Sans ce lien, l'évaluation devient une compétition où la phrase la plus soignée gagne.

La directive sur les marchés publics est claire sur la relation fondamentale : les critères d'attribution doivent être accompagnés de dispositions permettant de vérifier efficacement les informations fournies par les soumissionnaires. Ce principe est particulièrement important pour l'IA, car un résultat peut sembler convaincant alors que les conditions qui l'ont produit restent cachées. L'acheteur doit demander ce qui sera montré, dans quelles conditions de données et de tâches, avec quelle référence, et comment un évaluateur peut reproduire ou contester le résultat.

L'Algoritmekader néerlandais formule la même exigence en termes pratiques. Ses mesures en matière de marchés publics comprennent l'intégration des exigences relatives aux algorithmes dans les documents de marché et le contrat, l'obligation pour les fournisseurs de fournir des preuves que les exigences sont satisfaites dans le cadre de l'évaluation, l'évaluation des conditions de responsabilité des fournisseurs, l'exigence d'une capacité d'audit dans le contrat, l'accord sur le sort des données et des artefacts, et la demande d'un plan d'arrêt de l'algorithme. Cette liste est une orientation, pas une liste de contrôle juridique universelle. Sa valeur réside dans le fait qu'elle traite la preuve comme un objet de marché.

Un acheteur peut répartir les preuves en trois catégories utiles. La preuve démontrée est ce que le fournisseur présente lors d'une évaluation contrôlée : l'entrée, la sortie, la gestion des erreurs, l'utilisation des sources et la voie humaine peuvent être observées. La preuve inspectable est ce que le pouvoir adjudicateur peut examiner sans dépendre d'une démonstration : documentation, résultats de tests, journaux, interfaces, registres de modifications, descriptions des données et capacité à exécuter un contrôle convenu. La preuve contractuelle est ce que le fournisseur doit continuer à fournir : notifications de changement substantiel, informations sur les incidents, accès pour un audit, registres de service, facilités d'exportation et soutien à une sortie contrôlée. Ces catégories se chevauchent, mais elles empêchent qu'une seule session impressionnante porte l'ensemble du contrat.

Les preuves doivent aussi avoir un périmètre. Un fournisseur peut montrer qu’un système fonctionne bien sur un ensemble d’exemples. L’acheteur doit encore savoir si les exemples représentent la langue visée, la qualité des documents, la répartition des cas, les besoins d’accessibilité et les contraintes opérationnelles. Une affirmation sur un modèle en laboratoire n’est pas automatiquement une affirmation sur un service public. C’est une affirmation sur l’expérience qui a été menée. L’équipe d’achat doit conserver la tâche, les conditions des données, la version et le résultat afin que la décision ultérieure ne soit pas déconnectée du test.

Imaginons, à titre d’hypothèse, qu’un soumissionnaire fournisse un échantillon de résumés générés et une déclaration générale de précision. L’autorité peut demander les documents sources, la règle de sélection, la version utilisée, le traitement des éléments manquants, la procédure d’examen et l’artefact qui restera après l’acceptation. Si la réponse est que les détails sont confidentiels et ne peuvent pas être inspectés, l’équipe a appris quelque chose d’important. Elle n’a pas appris que le système est mauvais. Elle a appris que le périmètre de preuve proposé est peut-être trop faible pour la finalité publique.

Les preuves doivent être proportionnées. Un petit outil interne d’aide à la rédaction n’exige pas le même niveau d’inspection qu’un système qui influence l’accès à un service public. La proportionnalité ne signifie pas accepter un slogan à faible risque. Elle signifie adapter la profondeur de la preuve aux conséquences, à la réversibilité, aux personnes concernées et à la capacité de détecter et de corriger une erreur. Le fournisseur doit connaître les preuves requises avant le dépôt de l’offre. Sinon, l’autorité modifie le concours après la course, ce qui est une façon bien connue de produire une surprise coûteuse.

Une exigence doit mener à une preuve, et la preuve doit pouvoir modifier la décision d’attribution.

L’acheteur doit pouvoir être en désaccord

La responsabilité publique n’est pas la même chose que la transparence du fournisseur. Un fournisseur peut expliquer son service tandis que l’autorité ne dispose toujours d’aucun moyen pour un résident, un travailleur, une entreprise ou un professionnel de contester la manière dont le service a été utilisé. Le dossier d’achat doit donc demander comment fonctionne le désaccord, et pas seulement comment le système produit une réponse.

L’Algoritmekader place le contrôle humain, les droits fondamentaux, la transparence et les voies de réclamation parmi ses sujets du secteur public. Ses mesures recommandées incluent une intervention humaine significative dans la prise de décision, un processus par lequel les citoyens ou d’autres parties prenantes peuvent soumettre une plainte, une objection ou un recours, une décision publique sur l’utilisation de l’algorithme et un moyen de publier les algorithmes à impact dans le registre néerlandais des algorithmes. Ces mesures ne transforment pas chaque algorithme en spectacle public. Elles rendent la responsabilité de l’autorité suffisamment visible pour être remise en question.

Une exigence d’achat relative au contrôle humain doit nommer l’action humaine. Le relecteur peut-il voir les informations qui ont façonné la recommandation. Peut-il corriger le dossier. Peut-il rejeter le résultat sans avoir d’abord obtenu l’autorisation du système. Peut-il demander une seconde voie lorsqu’une source manque. Peut-il arrêter un lot, isoler une version ou remonter une préoccupation à une personne habilitée. Si la réponse est seulement qu’une personne est présente quelque part dans le processus, l’exigence décrit du mobilier, pas un contrôle.

Le désaccord a aussi besoin de temps. Un relecteur censé vérifier chaque sortie tout en conservant sa charge de travail initiale peut être techniquement dans la boucle et pratiquement en dehors. L’achat peut exiger une formation, un soutien, des preuves utilisables et une hypothèse de charge de travail pour la relecture. Il peut définir quels cas nécessitent une approbation préalable à l’action et quelles actions réversibles à faible conséquence peuvent se poursuivre avec journalisation et échantillonnage ultérieur. Il peut demander au fournisseur de soutenir la voie plutôt que de la cacher derrière une interface de programmation d’applications.

L’autorité doit aussi être en désaccord avec son propre enthousiasme. Un pilote réussi peut créer une pression pour étendre un outil à une population ou à une décision qui n’a jamais fait partie du test. Le contrat doit préserver l’objectif initial et exiger une nouvelle décision lorsque l’objectif, les données, les personnes concernées ou les conséquences changent. Une mise à jour n’est pas automatiquement inoffensive parce qu’elle est fournie comme un service. Un nouvel usage n’est pas automatiquement couvert parce que le même logo apparaît en haut de l’écran.

Lorsqu’un fournisseur affirme que le modèle est seulement consultatif, l’autorité doit examiner ce que le travail fait réellement. Si le personnel est invité à accepter le classement, s’il n’a pas le temps de le relire ou si le système contrôle quels cas parviennent à une personne, l’avis peut être devenu une décision en pratique. L’équipe d’achat n’a pas besoin de débattre de l’étiquette parfaite. Elle doit documenter le chemin de la sortie à la conséquence et conserver l’autorité de modifier ce chemin.

Les limites du fournisseur font partie du contrat

L’achat d’IA est souvent décrit comme un choix entre construire et acheter. Le choix le plus difficile est de répartir la frontière entre le fournisseur et l’organisation publique. Le fournisseur peut contrôler un modèle, un service, un chemin de mise à jour, une infrastructure, une équipe de soutien et une partie du traitement des données. L’autorité contrôle l’objectif public, la décision, la population concernée et le devoir de fournir un service licite et utilisable. Un contrat doit relier ces responsabilités plutôt que de les laisser sous forme de deux diagrammes polis.

Les clauses contractuelles types de l’UE pour l’IA, mises à jour, sont utiles car elles reconnaissent que les acheteurs publics ont besoin d’approches distinctes pour l’IA à haut risque et l’IA non à haut risque, et de conseils pour personnaliser les clauses en pratique. Elles ne remplacent pas une stratégie d’achat ni un examen juridique. Elles constituent un vocabulaire commun pour rendre les responsabilités explicites. L’acheteur doit encore décider quelles preuves, droits sur les données, accès aux audits, préavis de modification, soutien, responsabilité et conditions de sortie sont proportionnés au système acheté.

Les données et les artefacts méritent une attention particulière. Un système peut toucher aux documents sources, aux étiquettes, aux invites, aux intégrations, aux brouillons générés, aux corrections humaines, aux ensembles d’évaluation, aux journaux et aux enregistrements finaux. Le contrat doit distinguer ce que l’autorité fournit, ce que le fournisseur crée, ce que chaque partie peut utiliser, ce qui doit être restitué, ce qui doit être supprimé et quelle preuve de suppression ou de conservation est requise. Dire que l’autorité possède ses données ne répond pas à la question de savoir où vivent les artefacts dérivés ni comment l’autorité peut récupérer les enregistrements qui expliquent un résultat.

Les droits d’audit doivent prendre une forme concrète. L’acheteur doit savoir quels enregistrements peuvent être inspectés, comment l’accès est demandé, quel préavis est raisonnable, quelles protections de confidentialité s’appliquent et ce qui se passe lorsqu’un audit révèle une lacune. Une clause d’audit sans voie d’accès utilisable est une phrase qui attend un litige. Il en va de même pour une clause d’incident qui stipule que le fournisseur coopérera sans préciser les informations, les délais et le responsable nécessaires à cette coopération.

Le contrôle des changements ne doit pas être laissé aux notes de version. L’autorité peut exiger un préavis en cas de changement matériel concernant le modèle, les sources de données, le lieu de traitement, les sous-traitants, les interfaces, les seuils, la méthode d’évaluation ou la voie humaine. Elle peut définir les preuves nécessaires avant qu’une version modifiée ne soit utilisée pour la mission publique. Elle peut exiger un droit de suspendre, de rejeter ou de revenir en arrière lorsque le service modifié ne répond plus à une exigence matérielle. Ce sont des recommandations pour rendre le contrat opérationnel. Ce ne sont pas des affirmations selon lesquelles une seule clause peut résoudre toutes les relations avec les fournisseurs.

La responsabilité inclut également ce que le fournisseur ne peut pas fournir. Un service peut dépendre d’un modèle ou d’une infrastructure tiers dont les changements échappent au contrôle direct du fournisseur immédiat. L’acheteur doit être informé de cette dépendance et savoir quelles obligations lui sont transmises. Une organisation publique ne peut pas évaluer une chaîne en inspectant uniquement la porte d’entrée. Le contrat doit préserver une voie d’accès aux preuves pertinentes, ou l’acheteur doit reconnaître que l’incertitude est une raison de restreindre ou de refuser l’achat.

De bonnes limites protègent aussi les fournisseurs. Un acheteur public qui demande tous les documents possibles, tous les détails du code source et un support illimité sans objectif défini peut réduire la concurrence et rendre le contrat peu attrayant pour les petits fournisseurs européens. La proportionnalité, la clarté et un périmètre de preuves crédible permettent au fournisseur de dire ce qu’il peut faire et à l’acheteur de dire ce dont il a besoin. Les marchés publics doivent être exigeants sans être théâtraux. Un mur d’exigences impossibles écarte les mauvais systèmes et les bons avec une efficacité égale.

Le changement après l’attribution reste un marché public

L’attribution n’est pas la fin de la décision. C’est le moment où le service entre dans un autre type de contrôle. Pendant l’exploitation, les données évoluent, les politiques changent, les interfaces sont remplacées, le personnel apprend des raccourcis, les fournisseurs révisent leurs modèles et un système peut être utilisé dans des situations que l’équipe d’origine n’avait pas imaginées. L’autorité a besoin d’un moyen de remarquer ces changements avant qu’ils ne deviennent accidentellement une nouvelle mission publique.

L’Algoritmekader recommande des contrôles réguliers pour vérifier qu’un algorithme fonctionne comme prévu, le suivi des changements dans les données et l’évaluation des performances et des résultats lorsque les données changent, ainsi que le maintien d’un plan de surveillance continue. Il comprend également une mesure pour un plan d’urgence visant à arrêter l’algorithme. Ces recommandations intègrent le temps dans le modèle de gouvernance. Un marché public qui ne capture que la spécification initiale a acheté une photographie d’un service en mouvement.

Toutes les mises à jour ne doivent pas déclencher la même procédure. Un correctif de sécurité qui laisse le modèle, le périmètre des données et le rôle décisionnel inchangés peut suivre un chemin différent d’une nouvelle famille de modèles, d’une source de récupération modifiée ou d’un nouveau seuil. Le contrat peut définir le caractère matériel en termes opérationnels : un changement est matériel lorsqu’il modifie la mission, les personnes concernées, la voie de preuve, la conséquence décisionnelle, la juridiction de déploiement, le sous-traitant, l’utilisation des données ou la capacité d’intervention. La définition exacte nécessite un jugement juridique et technique. Le principe est simple : le changement fait partie de la capacité achetée.

La surveillance doit préserver les informations nécessaires à la prise de décision. Un tableau de bord peut montrer qu’un service est occupé ; il peut ne pas montrer qu’une source est devenue obsolète ou que des examinateurs contournent la même recommandation. L’autorité doit conserver la version pertinente, le périmètre de la tâche, les conditions de preuve, l’action humaine et le motif d’un changement. Elle doit savoir quels changements ont été acceptés, lesquels ont été annulés, lesquels ont été restreints et lesquels ont soulevé une nouvelle question de passation de marché.

Un fournisseur peut être incapable de signaler à l’avance chaque changement interne. Le contrat peut néanmoins exiger une notification utilisable et un dossier de preuve avant que le comportement modifié ne soit utilisé comme référence. L’autorité peut choisir un déploiement progressif, une évaluation contrôlée ou une suspension temporaire. La capacité de suspendre n’est pas une sanction. C’est ce qui permet à un service public de rester redevable pendant que les faits sont établis.

Un registre des changements protège aussi contre une fausse certitude. Si l’autorité ne peut pas déterminer si une différence provient d’un nouveau modèle, d’un changement de données, d’une invite, d’un contournement humain ou d’une dépendance externe, elle ne doit pas affirmer que le système s’est comporté de manière cohérente. La réponse appropriée peut consister à restreindre l’utilisation, à recueillir de meilleures preuves ou à interrompre la voie concernée. L’argent public ne devient pas plus sûr parce que l’explication est soignée.

L’interopérabilité est le mot poli pour dire partir

On parle souvent de l’interopérabilité comme s’il s’agissait d’une courtoisie technique entre systèmes. Dans la passation de marchés publics, c’est aussi un contrôle de continuité. Si un service public ne peut pas transférer ses dossiers, ses configurations, ses preuves, ses interfaces et ses connaissances opérationnelles vers une autre voie, l’autorité peut être juridiquement libre de partir et pratiquement incapable de le faire. Le contrat a créé une dépendance que le dossier de passation n’avait pas nommée.

Le rapport du CCR de la Commission sur l’accélération de l’adoption de l’IA dans les administrations publiques de l’UE qualifie la passation de marché de rôle habilitant crucial et affirme que l’interopérabilité doit être intégrée dès le départ. Il présente également la passation stratégique comme un moyen de réduire la dépendance à l’égard des fournisseurs non européens et de soutenir les start-ups européennes de l’IA, les solutions open source et GovTech. Il ne s’agit pas d’un argument pour acheter européen par slogan ni pour considérer l’open source comme une garantie automatique. Il s’agit d’un argument pour faire de la capacité technique et institutionnelle à changer de cap une partie de la valeur achetée.

La sortie commence par une liste de ce qui doit survivre. Cela peut inclure les enregistrements sources, les identifiants, les étiquettes, les invites, les versions de modèles et de configurations, les ensembles d’évaluation, les registres d’audit, les correspondances d’utilisateurs et de rôles, les contrats d’intégration, le statut de conservation, le matériel de sécurité et la signification des champs. La liste dépend du service. Un fichier portable sans contexte peut être moins utile qu’un enregistrement plus petit dont la sémantique et les autorisations sont intactes. L’exportation est une capacité à tester, pas une case à cocher.

L’interopérabilité signifie aussi que l’autorité peut effectuer une comparaison significative. Une destination peut-elle traiter les enregistrements sans en modifier silencieusement le sens. Les examinateurs peuvent-ils comparer une ancienne et une nouvelle sortie dans les mêmes conditions de tâche. Le service public peut-il continuer en mode réduit si une dépendance est indisponible. Les preuves peuvent-elles rester lisibles une fois l’interface disparue. Ces questions doivent figurer dans les exigences, l’évaluation et le contrat, car une sortie découverte en situation d’urgence est généralement une fouille archéologique.

La portabilité ne signifie pas nécessairement que le fournisseur doive remettre chaque détail d’implémentation interne. Elle signifie que l’autorité peut préserver la fonction publique et les documents dont elle est responsable, sous réserve des droits légitimes et des contraintes de sécurité. La limite doit être énoncée avant la signature. Si le modèle du fournisseur est inaccessible, l’autorité peut tout de même exiger des entrées, des sorties, des registres de décision, des évaluations, une configuration portables et une voie pour reconstituer les obligations publiques du service. Si elle ne peut pas obtenir cette voie, elle doit chiffrer honnêtement la dépendance ou la refuser.

Une répétition de sortie est précieuse car elle transforme une promesse contractuelle en capacité observée. Un acheteur public peut tester une exportation, inspecter les champs, exécuter une charge de travail représentative dans une destination contrôlée et comparer les registres obtenus. Il peut consigner ce qui n’a pas été transféré et décider si l’écart est acceptable. L’exercice n’a pas besoin d’être spectaculaire. Une petite répétition effectuée avant le renouvellement vaut mieux qu’une migration héroïque réalisée après que le fournisseur est devenu la seule personne qui se souvient du système.

Quitter est une séquence d’autorité, d’exportation, de sens, de vérification, de continuité et de clôture. Un bouton intitulé exportation n’est pas la séquence.

Le coût dépasse la ligne du marché public

Le prix est facile à comparer lorsque l’objet acheté est stable. L’achat d’IA a un horizon de coût plus long. Il peut y avoir du travail d’intégration, de préparation des sources, du temps de revue, des contrôles de sécurité, du stockage, de l’évaluation, des mises à jour de modèles, du travail d’accessibilité, de la gestion d’incidents, du support, de l’exportation et du remplacement. Certains coûts sont supportés par l’autorité. D’autres sont transférés aux travailleurs ou au public lorsqu’un service devient plus difficile à contester. Un marché public qui ne compare que les frais initiaux n’est pas nécessairement économique. Il ne fait que compter une partie visible.

La directive 2014/24/UE prévoit le calcul du coût du cycle de vie lorsque l’autorité choisit cette approche. La directive décrit des coûts tels que l’acquisition, l’utilisation, la maintenance, la fin de vie et, le cas échéant et lorsqu’ils sont vérifiables, les externalités environnementales. Elle exige également que les documents de marché indiquent les données que les soumissionnaires doivent fournir et la méthode utilisée pour évaluer le coût du cycle de vie. C’est une discipline utile pour l’IA car elle oblige l’acheteur à préciser ce qui sera compté plutôt que d’inviter chaque fournisseur à apporter une définition différente de ce qui est bon marché.

Le même principe s’applique à l’attention humaine. Si un système produit des recommandations qui doivent être examinées, le travail d’examen fait partie du modèle d’exploitation. Si un service public a besoin d’une voie de recours, cette voie doit avoir un responsable et du temps. Si une mise à jour d’un fournisseur exige une nouvelle évaluation, l’autorité doit avoir la capacité de la réaliser. Ce ne sont pas des arguments contre l’automatisation. Ce sont des rappels que l’automatisation déplace le lieu où le travail s’effectue. Une économie sur la facture peut devenir une dépense dans la file d’attente si le marché ne nomme pas ce nouveau travail.

Le coût doit aussi inclure celui de ne pas pouvoir partir. Une dépendance peut sembler peu coûteuse lorsqu’elle est nouvelle, puis devenir chère lorsque des dossiers, des compétences, des intégrations et des attentes du public se sont accumulés autour d’elle. L’acheteur peut demander une estimation de migration, un inventaire des données et des artefacts, une obligation de support et un calendrier d’essais. Il peut comparer ces conditions dans le cadre de la valeur de l’offre. Le choix n’est pas entre optimisme et pessimisme. Il est entre une dépendance visible et une dépendance cachée dans le futur.

La pensée axée sur le cycle de vie aide une équipe de marchés publics à dire non sans prétendre que l’offre visible la moins chère est l’option neutre. L’équipe peut rejeter une proposition parce que ses preuves, sa charge d’examen, son chemin de changement ou son coût de sortie ne sont pas compatibles avec l’intérêt public. Elle peut expliquer sa décision selon des critères publiés. Ce n’est pas un geste contre le marché. C’est ce qu’un marché avec des exigences vérifiables est censé permettre.

Les acheteurs publics ont besoin du pouvoir de dire non

Une équipe de marchés publics ne peut pas exercer un pouvoir que l’organisation ne lui a pas donné. De nombreuses autorités disposent de personnes capables d’évaluer les questions juridiques, techniques, financières et de service, mais le pouvoir de combiner ces évaluations en une pause ou un refus n’est pas clair. Le résultat est connu : les préoccupations sont consignées dans un document, l’enthousiasme dans un autre, et l’attribution se poursuit parce que personne ne sait quel rôle peut fermer la porte.

L’autorité doit nommer les rôles qui peuvent accepter, rejeter, restreindre ou suspendre un achat à chaque étape. Ces rôles doivent avoir accès aux preuves pertinentes et un moyen d’enregistrer la raison. Un agent de marchés publics peut posséder le processus, un responsable de service l’intérêt public, un délégué à la protection des données une condition de confidentialité, un responsable de la sécurité un contrôle, un examinateur technique un test et un haut responsable la décision finale. La disposition exacte varie. L’absence de disposition est la partie dangereuse.

Une condition d’arrêt utile n’est pas un badge rouge indiquant un risque élevé. C’est un fait qui bloque la décision suivante. L’objectif visé n’est pas suffisamment défini. Le fournisseur ne peut pas fournir de preuve pour une exigence matérielle. La personne concernée n’a pas de voie de recours utilisable. L’autorité ne peut pas inspecter le changement pertinent. Les droits sur les données ou les artefacts ne sont pas clairs. Le système ne peut pas être exporté ou remplacé dans le cadre du plan de continuité. L’examinateur humain a une responsabilité mais aucune autorité. Chaque condition peut avoir un remède différent. Certaines exigent des clarifications, certaines une modification du contrat, certaines une portée plus restreinte et certaines un non.

Les conditions d’arrêt doivent être connues avant l’évaluation de l’appel d’offres. Elles doivent être liées aux critères d’attribution et au contrat afin que l’acheteur n’invente pas une nouvelle norme après avoir vu la réponse du fournisseur. Elles doivent aussi être réexaminées après l’attribution. Une exigence satisfaite au lancement peut cesser de l’être après un changement important ou une nouvelle utilisation. La capacité de dire non n’est pas une porte unique à la fin. C’est une autorité maintenue tout au long de la vie du service.

Considérons une équipe publique fictive qui achète un service d'acheminement de documents. Ses exigences publiées incluent la traçabilité des sources, un parcours de relecture humaine, un avis en cas de modification importante du modèle, une exportation des enregistrements et une procédure d'arrêt définie. Un soumissionnaire propose une démonstration convaincante, mais ne peut pas permettre à l'autorité d'inspecter la sélection des sources ni de conserver les preuves d'acheminement versionnées. Un autre soumissionnaire offre moins de fonctionnalités, mais satisfait aux exigences de preuve et de sortie. L'équipe n'est pas obligée de privilégier la démonstration la plus spectaculaire. Elle peut appliquer les critères énoncés, poser des questions proportionnées et refuser la première offre si une exigence matérielle reste non démontrée.

Cette décision ne doit pas être formulée comme un jugement moral sur le fournisseur ou la technologie. Elle doit énoncer l'objectif d'intérêt public, l'exigence, les preuves reçues, la condition non résolue et la décision autorisée par les documents d'appel d'offres. Un non clair est plus respectueux qu'un peut-être vague qui se transforme plus tard en renouvellement obligatoire. Cela donne également un signal utile au marché : les acheteurs publics paieront pour des preuves et du contrôle, et non seulement pour un spectacle de capacités.

L'autorité humaine d'arrêt doit pouvoir être exercée en cas d'incident. L'opérateur doit savoir qui appeler, quel état du système préserver, quelle route de service peut continuer et quelle communication est requise. Le compte rendu de décision doit distinguer le confinement immédiat d'une décision d'achat à plus long terme. Une administration publique n'a pas besoin d'attendre une enquête parfaite avant de prévenir d'autres préjudices, mais elle doit éviter de revendiquer plus de certitude qu'elle n'en a. L'arrêt est un contrôle. L'explication peut évoluer.

L'achat public façonne le marché

L'achat public est l'un des moyens par lesquels l'Europe décide quelles capacités méritent d'être développées. Le rapport du CCR sur l'avancement de l'adoption de l'IA dans les administrations publiques de l'UE décrit le secteur public comme une force majeure de structuration du marché. Il relie l'adoption réussie à la gouvernance, à la préparation des effectifs, à un achat responsable, à l'interopérabilité et à la confiance du public. Il indique également qu'un achat stratégique peut réduire la dépendance à l'égard des fournisseurs non européens et soutenir les startups européennes, les solutions open source et GovTech. Le propos n'est pas qu'une autorité publique devienne un fonds d'investissement. Le propos est que ses exigences peuvent soit récompenser une capacité responsable, soit récompenser une enveloppe persuasive autour d'une dépendance.

Le rapport spécial n° 28/2023 de la Cour des comptes européenne est intitulé Marchés publics dans l'UE : moins de concurrence pour les marchés de travaux, de fournitures et de services au cours des dix années précédant 2021. Son résumé public décrit la concurrence pour les appels d'offres publics en Europe comme étant en recul. Un marché avec moins de concurrents effectifs est un mauvais endroit pour cacher des exigences vagues. Si l'autorité ne peut pas comparer les preuves, elle peut choisir entre des styles de marketing plutôt qu'entre des services. Refuser une offre non vérifiable peut préserver les conditions d'une meilleure concurrence ultérieure.

Dans le même temps, un acheteur peut exclure accidentellement des fournisseurs utiles en exigeant des preuves sous une forme que seul le plus grand fournisseur peut produire. Des exigences proportionnées, des interfaces claires, des formats ouverts et des évaluations par étapes peuvent permettre à des organisations plus petites de démontrer une capacité limitée sans prétendre avoir les ressources d'une multinationale. L'acheteur doit être strict sur l'objectif d'intérêt public et flexible sur la mise en œuvre lorsque celle-ci n'affecte pas cet objectif. C'est ainsi qu'un non devient une meilleure question plutôt qu'une porte fermée.

La structuration du marché signifie également refuser de faire de l'architecture privée d'un fournisseur la définition du besoin public. Si une exigence nomme un modèle, un cloud ou un flux de travail propriétaire particulier sans lien justifié avec la tâche, la concurrence peut être restreinte avant même que les preuves ne soient examinées. Des exigences fonctionnelles et des résultats vérifiables donnent aux acheteurs publics plus de marge pour comparer les approches. Ils rendent également le contrat moins fragile lorsque le composant choisi change.

Une autorité publique peut être un client exigeant sans devenir un client difficile. Elle peut publier les éléments de preuve qu’elle attend, expliquer la raison d’une condition d’arrêt, offrir une voie de clarification et rémunérer un travail qui crée une capacité publique durable. Le marché dispose alors de quelque chose d’utile auquel répondre. Il n’a pas à deviner si le facteur décisif était une préférence cachée, une démonstration séduisante ou le prix d’un problème futur.

Un schéma de travail pour un marché public qui peut refuser

Le schéma suivant est une recommandation pratique, et non une nouvelle procédure juridique. C’est une manière de maintenir la décision publique visible pendant qu’un système passe de l’idée à l’exploitation. Une autorité doit l’adapter à son droit, à son secteur, à ses risques et à sa méthode de passation. L’essentiel est que chaque étape ait un responsable, des éléments de preuve et une issue autorisée qui inclut la pause ou le refus.

Premièrement, rédigez l’objectif public. Nommez le service, les personnes qui le fournissent, celles qui le reçoivent, la décision ou l’action qui peut changer et la raison pour laquelle un système est envisagé. Précisez ce qui est hors du périmètre. Si l’objectif ne peut être décrit sans le vocabulaire produit du fournisseur, l’autorité est encore en phase de découverte du marché. Le résultat de cette étape est un énoncé du problème et une décision sur la question de savoir si la passation de marché est la prochaine étape appropriée.

Deuxièmement, rédigez la limite des éléments de preuve. Pour chaque affirmation importante, indiquez ce qui démontrerait qu’elle est vraie dans la tâche visée. Nommez les conditions relatives aux données, la langue, les besoins d’accessibilité, les documents sources, la version, la référence et la voie de réexamen qui rendent le test pertinent. Précisez ce qui doit pouvoir être inspecté, ce qui peut rester confidentiel et ce qui doit être livré comme document contractuel. Le résultat de cette étape est un ensemble d’exigences compréhensibles pour les soumissionnaires et un plan d’évaluation qui peut modifier l’attribution.

Troisièmement, rédigez la limite de l’autorité. Nommez les actions que le système peut suggérer, celles qu’il peut entreprendre, celles qui nécessitent une approbation et celles qui sont interdites. Nommez qui peut corriger une source, rejeter un résultat, modifier une règle, suspendre un service et parler à une personne concernée. Définissez ce qui se passe lorsque le système est incertain ou que les éléments de preuve se contredisent. Le résultat de cette étape est une voie humaine plus précise qu’une simple case à cocher.

Quatrièmement, rédigez la limite du changement. Identifiez les changements qui exigent un préavis, une évaluation, une approbation ou une nouvelle décision de passation. Incluez le modèle, les données, le fournisseur, le sous-traitant, l’infrastructure, le lieu de traitement, l’interface, le seuil, la population, l’objectif et la voie humaine. Décidez quels éléments de preuve restent attachés au dossier de changement et lesquels peuvent être expurgés pour des raisons légitimes. Le résultat de cette étape est un dossier tenu à jour plutôt qu’une promesse que le système restera figé.

Cinquièmement, rédigez la limite de sortie. Listez les documents, les données, la configuration, les éléments de preuve, les autorisations, les intégrations et les connaissances opérationnelles qui doivent survivre. Définissez les formats, les délais, le support, la vérification, le service réduit, la bascule, la fermeture des accès et la suppression. Répétez une petite exportation avant un renouvellement ou une expansion importante. Le résultat de cette étape est une voie qui peut être testée pendant que le fournisseur est encore un partenaire, et non seulement après que la relation est devenue un litige.

Sixièmement, rédigez le dossier public. Décidez ce qui peut être publié concernant l’objectif, le rôle du système, les éléments de preuve, la voie humaine, les changements, les incidents et le contact pour contester. Protégez les informations confidentielles et personnelles sans transformer toute la décision en conversation privée. Un dossier public peut indiquer ce qui est connu, ce qui ne l’est pas et quand aura lieu le prochain examen. Son rôle n’est pas de donner une image parfaite du système. Il est de rendre le jugement de l’autorité inspectable.

Enfin, rédigez le refus. Le refus n'est pas un communiqué de presse dramatique. C'est un résultat normal dans le dossier de décision : l'exigence était substantielle, les éléments ne l'ont pas satisfaite, le recours a été examiné et l'autorité a choisi de refuser, de restreindre, de suspendre ou de chercher une autre voie. Un marché qui ne peut pas produire ce dossier a fait paraître l'achat inévitable avant qu'il ne le mérite.

Ces portes peuvent être représentées dans une réponse à un appel d'offres, une architecture de démarrage de projet, un calendrier contractuel, une réunion d'examen et un manuel d'incident. Elles ne doivent pas devenir un formulaire plus grand pour lui-même. Si une porte ne change pas ce que l'équipe peut décider, c'est probablement du théâtre documentaire. Si elle donne à une personne des éléments et l'autorité d'agir, elle fait partie du service.

Questions à poser dans un appel d'offres

Les meilleures questions ne sont pas celles qui font répéter au fournisseur son langage marketing. Ce sont celles qui rendent visibles l'objectif public et la limite des éléments. Un acheteur peut adapter les questions suivantes au système et à la procédure :

  • Quelle tâche publique précise la capacité proposée soutient-elle, et quelles tâches sont hors de son usage prévu ?
  • Quelles personnes, quels dossiers et quelles sources de données sont dans le périmètre, et lesquels doivent être exclus ?
  • Quelle sortie le système produit-il, et quelle décision ou action peut en découler ?
  • Quelle exigence peut être démontrée, laquelle peut être inspectée et laquelle sera maintenue contractuellement ?
  • Comment l'autorité reproduira-t-elle un résultat avec la version, les sources, la configuration et les conditions de tâche pertinentes ?
  • Que peut voir, modifier, rejeter, escalader ou arrêter un examinateur humain avant qu'une action importante ne se produise ?
  • Quels changements de modèle, de données, d'infrastructure, de sous-traitant ou de politique exigent un préavis et une réévaluation ?
  • Quels dossiers et artefacts l'autorité peut-elle exporter, dans quels formats, avec quelle signification, quels droits et quel statut de conservation ?
  • Que se passe-t-il lorsque le service est indisponible, que les éléments sont incomplets ou qu'une personne conteste le résultat ?
  • Quelles obligations de support, d'audit, d'incident, de formation et de sortie se poursuivent après la première version ?

Ces questions ne remplacent pas la directive sur les marchés publics, l'AI Act, le droit de la protection des données ou les règles sectorielles. Ce sont des incitations pour que l'autorité rende ses propres obligations opérationnelles. Un fournisseur qui peut y répondre clairement n'est peut-être pas le bon fournisseur. Un fournisseur qui ne peut pas y répondre peut tout de même avoir un composant utile, mais l'autorité ne doit pas confondre un composant utile avec une capacité publique complète.

Notre petite note

Chez Dweve, notre AI Compas comprend une voie d'approvisionnement et de gouvernance neutre vis-à-vis des fournisseurs pour les organisations européennes réglementées. Le matériel RFI et RFP demande aux équipes de classer le cas d'usage, d'appliquer des critères d'élimination, de comparer les fournisseurs, de mener une preuve de concept et de conserver les éléments tout au long du suivi. C'est notre contexte de mise en œuvre, pas une preuve indépendante sur les marchés publics et pas une affirmation qu'un cadre convient à chaque autorité. Nous le mentionnons parce que la discipline décrite ici est aussi celle que nous essayons d'utiliser dans notre propre travail : définir la limite, exiger des preuves, garder la décision humaine et rendre la sortie visible.

Notre Trust Centre fait la même distinction dans un registre différent. Un dossier public peut décrire ce qui est documenté, ce qui est préparé et ce qui reste un événement futur sans transformer une déclaration d'intention en preuve. Une équipe d'approvisionnement mérite la même honnêteté de la part de ses fournisseurs. L'acheteur doit pouvoir voir le statut d'une affirmation, les éléments qui la soutiennent et la voie pour la contester.

La leçon

Une autorité publique ne devient pas responsable lorsqu’elle signe pour un système d’IA. Elle le devient lorsque l’achat peut expliquer pourquoi le système a sa place dans le travail, quelles preuves étayent cette conclusion, qui peut intervenir, ce qui se passe lorsque le système change et comment la fonction publique peut se poursuivre si le fournisseur ne peut pas.

Les règles européennes en matière de marchés publics offrent déjà des habitudes importantes : les critères doivent être liés à l’objet du marché, les informations doivent être vérifiables, les pondérations doivent être indiquées et les conditions contractuelles doivent être claires. Les clauses types de la Commission européenne sur l’achat d’IA donnent aux acheteurs publics un moyen de discuter des systèmes à haut risque et des autres systèmes, et de répartir les responsabilités. L’Algoritmekader néerlandais transforme l’achat responsable en mesures concrètes concernant la finalité, les données, les preuves, l’audit, le contrôle humain, l’arrêt et la sortie. Le rapport du JRC inscrit l’achat public dans la réflexion européenne sur les capacités et la souveraineté. L’avertissement de la Cour des comptes européenne sur la réduction de la concurrence rappelle qu’un appel d’offres faible n’est pas réparé par une attribution confiante.

Le mot difficile reste non. Non, la finalité n’est pas définie. Non, les preuves ne peuvent pas être inspectées. Non, la voie humaine est décorative. Non, le parcours de changement est invisible. Non, le registre public ne peut pas être tenu. Non, le service ne peut pas partir sans perdre le travail qu’il était censé protéger. Chaque non peut être un refus, un resserrement, une pause ou une demande de meilleure réponse. L’autorité doit décider lequel, consigner pourquoi et laisser la décision ouverte à la contestation.

Un achat qui sait dire non n’est pas un achat qui craint la technologie. C’est un achat qui sait la différence entre une capacité et une promesse. Il paie pour un système qui peut être testé, supervisé, modifié et quitté. Il offre aux fournisseurs un appel d’offres plus équitable parce que la question est visible. Il donne aux agents publics un moyen d’intervenir avant qu’un problème ne devienne une politique. Il donne aux personnes concernées par le service quelque chose de plus utile qu’une déclaration selon laquelle un fournisseur a été approuvé.

Un achat public devrait se terminer par un service que l’autorité peut encore gouverner. Si les preuves sont solides, dire oui a du sens. Si les preuves sont faibles, dire non est le travail public. Le dossier d’achat devrait pouvoir contenir ces deux phrases.

Sources