Un service public ne peut pas déléguer son jugement.

Un fournisseur peut fournir le logiciel, les preuves et un avis. Il ne peut pas devenir l'organisme public qui détient la finalité, l'autorité, les motifs,...

Un service public ne peut pas déléguer son jugement.

The contract is not the decision

A public body can buy software. It can buy hosting, analysis, a recommendation, a workflow, a translation, a ranking or a report. What it cannot buy is an escape from being the public body that acts. The contract may allocate work to a supplier, but it does not transfer the institution's public purpose, legal authority, duty to give reasons or obligation to provide a remedy. Those things follow the decision, not the invoice.

This sounds obvious until procurement language turns a judgement into a deliverable. A tender asks for a risk score. A supplier supplies a risk score. A contract calls the output advisory. A service quietly changes its queue, its attention or its threshold because the score is convenient. By the time a person is affected, everyone can point to a different document. The supplier points to the specification. The procurement team points to the award. The operator points to the screen. The institution points to the contract. The person who needs an answer is left with a circle of pointing fingers and no accountable hand.

Public work has always involved delegation. A council may commission an inspection, a ministry may buy a case-management system and a hospital may procure a scheduling service. Delegation is not the problem. The problem begins when the delegated component is allowed to carry a decision without the authority, evidence and review that make the decision legitimate. A tool may be excellent at one task and still be the wrong place to put a public judgement. Procurement has to preserve that distinction before a supplier's vocabulary becomes the organisation's operating model.

The European public procurement tradition already contains the right instinct. Contracting authorities must act transparently, proportionately, without discrimination and without artificially narrowing competition. That is not only a fair way to run a tender. It is a reminder that the authority remains visible inside the purchase. The public body chooses a purpose, defines a need, sets the conditions and accepts the consequences. A clever system does not make those choices disappear. It merely gives them a more expensive interface.

Judgement is not the same as output

Technical systems produce outputs. Public institutions make decisions. The two can sit next to one another, but they are not interchangeable. A classifier can assign a category. A search system can retrieve documents. A language model can draft a letter. An optimiser can find a route through constraints. None of those verbs, by themselves, contains the legal or civic question of what should happen to a person.

Judgement enters when an institution decides that an output is relevant, sufficient and authorised for a particular action. It enters when competing interests are balanced, when an exception is considered, when a rule is interpreted in context, when a person is heard, when a delay is accepted, when an error is repaired and when a reason is given. A model may contribute information to those moments. It does not acquire public authority by being accurate, fast or confidently presented.

The distinction matters because procurement often describes systems in capability language. The supplier will detect, assess, prioritise, recommend or automate. Capability language is useful for finding a market. It is not enough for assigning responsibility. The tender must say which human or institutional role turns the capability into an action, which evidence that role must inspect, which actions are prohibited and how the affected person can challenge the result.

Cette traduction, de la capacité à l'autorité, est le premier acte sérieux de l'achat public. Sans elle, l'acheteur n'acquiert pas un service délimité. Il acquiert une lacune dans sa propre description des responsabilités. Les lacunes sont faciles à ignorer tant qu'un projet est célébré. Elles deviennent étonnamment solides lorsque quelqu'un demande pourquoi une décision a été prise.

Commencer par la finalité publique

Un achat public responsable commence par la finalité publique, et non par une catégorie de modèle. La question n'est pas de savoir si une autorité peut acheter un système d'IA. La question est de savoir quelle tâche publique nécessite un soutien, quel résultat cette tâche est censée atteindre, qui est concerné et ce qui constituerait un échec. Une finalité étroite rend possibles les choix ultérieurs. Un slogan tel que améliorer l'efficacité laisse chaque décision importante pour plus tard, généralement à l'intérieur d'une démonstration du fournisseur.

La finalité doit être rédigée dans le langage du service. Une équipe peut avoir besoin de trouver des informations manquantes dans un dossier, d'orienter les demandes vers le bon spécialiste, de traduire un avis public, de rédiger un résumé interne ou d'identifier les cas nécessitant une attention particulière. Ce sont des tâches différentes aux conséquences différentes. Un projet peut être rejeté. Une orientation peut retarder une personne. Une traduction peut modifier l'accès. Une priorisation peut changer qui reçoit un temps rare. Un seul mot, automatisation, cache toute une géographie du pouvoir public.

La déclaration de finalité doit également préciser ce que le système n'est pas autorisé à faire. Il peut assister un agent mais ne peut pas déterminer l'éligibilité. Il peut suggérer un ordre de file d'attente mais ne peut pas retirer une personne du service. Il peut faire apparaître des documents mais ne peut pas décider quels éléments de preuve sont juridiquement pertinents. Il peut préparer une communication mais ne peut pas l'envoyer sans l'approbation nommée. L'espace négatif n'est pas un luxe rédactionnel. C'est ainsi qu'une limite survit à un mardi chargé.

Il y a une raison pratique d'être strict ici. L'utilisation d'un système s'étend par commodité. Une fois qu'un outil est disponible, l'équipe suivante demande s'il peut gérer une tâche voisine. La finalité initiale semble assez proche. Un nouveau champ est ajouté, une nouvelle source de données est connectée et un nouveau groupe de personnes est concerné. Si la finalité initiale était vague, personne ne peut dire s'il s'agit d'un petit changement ou d'un nouvel acte public. L'achat public devrait créer une question de changement à laquelle l'organisation peut répondre avant que la nouvelle utilisation ne devienne ordinaire.

Les règles européennes rendent la responsabilité plus difficile à dissimuler

La directive 2014/24/UE établit une base familière pour l'achat public : égalité de traitement, non-discrimination, transparence et proportionnalité. Ces principes ne prescrivent pas une technologie particulière. Ils exigent que le pouvoir adjudicateur conçoive un processus qui puisse être expliqué et défendu. Une exigence qu'un seul fournisseur peut satisfaire sans raison opérationnelle réelle est un problème de gouvernance, et non simplement un problème de marché. Une exigence qui ne peut pas être testée est une promesse portant un numéro d'achat public.

Les mêmes principes s'appliquent lorsque l'objet de l'achat est un modèle, un agent ou un service d'aide à la décision. L'autorité doit décrire son besoin d'une manière qui permette une concurrence loyale et une évaluation significative. Elle doit comparer les offres selon des critères qui importent pour le service, et non seulement selon un indice de référence préféré du fournisseur. Elle doit préserver les éléments de preuve derrière l'attribution et gérer le contrat lorsque la réalité diffère de l'appel d'offres. La transparence n'est pas terminée lorsque l'offre gagnante est annoncée. Elle se poursuit à travers la performance, le changement et la sortie.

The EU AI Act adds a second layer for certain high-risk systems. Article 14 requires human oversight that is effective, proportionate to risk, level of autonomy and context, and capable of detecting anomalies, interpreting outputs, disregarding or reversing them and interrupting the system safely. Article 27 requires relevant public bodies and providers of public services to assess fundamental-rights impacts before deploying specified high-risk systems, and to update the assessment when the context changes. These are operational obligations, not decorative language for a policy page.

The AI Act does not turn every public software purchase into the same legal category. It does something more useful: it makes the relationship between provider, deployer, system and affected person harder to blur. A provider must describe capabilities and limitations. A deployer must use the system appropriately and keep responsibility for its use. Public authorities have registration and information duties for specified high-risk systems. The exact legal application depends on the use and the relevant provisions. The governance lesson is stable: the party buying the capability still owns the context in which the capability acts.

The supplier's output needs a home

Every output used in a public workflow should have a named home. That home is not merely a database table. It is a role with authority to decide whether the output is fit for purpose, what evidence supports it, what happens when it is wrong and which version produced it. If an output has no owner, it will be treated as everybody's concern until the first dispute, when it becomes nobody's job.

Ownership should be split without being fragmented. A service owner knows the public purpose and acceptable risk. A data owner knows the source, quality, access and correction path. A technical owner knows the deployment, security, capacity and integration. A model or supplier owner knows the evaluation, limits and changes. An operational reviewer knows the work and can stop a case from travelling further. These roles can belong to one small team. They cannot be replaced by the phrase human in the loop.

The person who reviews an output needs time, information and authority. If the interface shows only a score, the reviewer cannot inspect its basis. If the queue makes review impossible, the reviewer cannot exercise meaningful oversight. If a policy says the output is advisory while the workflow treats it as the default answer, the reviewer is being asked to provide a signature rather than judgement. A button labelled approve is not a control point when the person behind it cannot safely choose anything else.

Procurement should therefore ask suppliers to describe the hand-off. What exactly enters the system. What comes out. Which uncertainty or limitation travels with the output. What can the operator see. What can the operator change. What does the system do when the input is outside its declared scope. How is a stop action exposed. Which records prove that a review happened. A supplier that can answer those questions is describing an operating service. A supplier that answers only with a performance score is describing a component.

The first visual: responsibility follows the chain

La responsabilité ne disparaît pas à la frontière du fournisseur. Elle traverse l’objet, la preuve, le contrôle, l’action et le recours.

Un score n’est pas une raison

Les scores séduisent dans les marchés publics parce qu’ils donnent l’impression de simplifier la comparaison. Un fournisseur peut communiquer une exactitude, une latence, une couverture ou une réduction du travail manuel. Un acheteur peut placer les valeurs dans un tableau et sentir la décision devenir objective. La mesure a de la valeur. Mais un score ne répond qu’à la question pour laquelle il a été conçu. Il ne devient pas une raison d’agir pour le public simplement parce qu’il gagne une décimale.

Supposons qu’un système classe des dossiers par priorité. Le classement peut être utile, mais la raison publique n’est pas simplement qu’un nombre était élevé. L’institution doit savoir quelle finalité légale autorise le classement, quelles données ont été examinées, quels dossiers sont exclus, ce que le classement manque, comment un contrôleur peut le corriger et comment une personne peut contester le résultat. Le score est un signal parmi d’autres dans une décision. S’il est la seule phrase que l’institution peut produire, ce n’est pas une preuve de jugement. C’est la preuve que l’institution a délégué l’explication.

Les affirmations de référence exigent aussi un contrat. Quelle population a été testée. Quelles étiquettes ont été utilisées. Quelles langues et quels cas limites ont été inclus. Quelle référence a été comparée. Comment les erreurs ont-elles été pondérées. Qu’est-il advenu des entrées manquantes ou ambiguës. Un humain a-t-il corrigé le résultat pendant le test. L’évaluation a-t-elle été exécutée sur la même version qui fonctionnera en service. Sans ces détails, une référence peut rester intéressante, mais elle ne peut pas porter tout le poids d’une décision d’achat public.

Les acheteurs publics devraient demander des preuves sous la forme dont le service aura besoin plus tard. Un test technique peut montrer si un modèle accomplit une tâche. Un test de flux de travail peut montrer si les personnes peuvent détecter et corriger les erreurs. Un test de gouvernance peut montrer si une décision peut être reconstituée et contestée. Un test de continuité peut montrer si l’autorité peut fonctionner quand un fournisseur est indisponible. Ces tests répondent à des questions différentes. Les combiner en un seul score de fournisseur est pratique et généralement faux.

Le contrôle humain doit avoir des dents

Le contrôle humain est souvent présenté comme le dernier nom rassurant d’un schéma de système. Une case étiquetée humain apparaît après le modèle et avant la décision. Le schéma a l’air responsable. La vraie question est de savoir si l’humain peut comprendre, contester et modifier le résultat dans les conditions où le service fonctionne.

L'article 14 du règlement sur l'IA est inhabituellement concret à ce sujet. Les personnes chargées de la surveillance doivent comprendre les capacités et les limites pertinentes, surveiller le fonctionnement, reconnaître le biais d'automatisation, interpréter les résultats, décider de ne pas utiliser le système ou de le remplacer, et intervenir ou interrompre le processus selon une procédure sûre. Ce sont des pouvoirs. Ils exigent une interface, une formation, une charge de travail, des preuves, une autorité et du temps. Ils exigent aussi une organisation qui soutiendra un examinateur qui déclare que le système sort de son périmètre.

Un examinateur ne peut pas exercer une surveillance sur un résultat dépouillé de son contexte. Le résultat doit comporter les références sources pertinentes, les avertissements sur la qualité des données d'entrée, la version et l'objectif. L'examinateur doit pouvoir demander des preuves supplémentaires ou marquer le dossier comme non résolu. Si le système présente une seule réponse d'une manière qui rend les alternatives coûteuses, il conçoit le biais d'automatisation dans la salle. Si la seule façon d'arrêter un flux de travail est d'appeler un fournisseur, l'autorité a acheté un système qu'elle ne peut pas exploiter en toute sécurité.

La proportionnalité compte. Un outil d'aide à la rédaction à faible enjeu n'a pas besoin des mêmes contrôles qu'un système qui appuie une prestation, une inspection ou l'accès à des soins. Mais proportionné ne signifie pas symbolique. Plus le système peut affecter les droits, la sécurité ou les services essentiels, plus l'autorité doit pouvoir démontrer que la surveillance était possible, qu'elle a été exercée et qu'elle était capable de modifier le résultat. Un humain présent mais sans pouvoir n'est pas une surveillance. C'est une clause de non-responsabilité rembourrée.

La contestabilité fait partie du service

Une décision publique n'est pas complète lorsqu'un flux de travail interne indique « terminé ». Elle est suffisamment complète pour que la personne concernée comprenne ce qui s'est passé, corrige les faits pertinents et utilise la voie de révision ou de recours disponible. La contestabilité n'est pas une fonctionnalité optionnelle d'expérience client. Elle fait partie de la relation de l'institution avec le public.

L'explication de la Commission concernant les garanties relatives aux décisions automatisées du RGPD expose clairement le principe de base. Une personne ne devrait pas être soumise à une décision entièrement automatisée ayant des effets juridiques ou des effets significatifs similaires, sauf dans des conditions et avec des garanties définies. Lorsque les garanties s'appliquent, les personnes ont besoin d'informations, de la possibilité d'une intervention humaine et d'un moyen d'exprimer leur point de vue et de contester la décision. La voie juridique exacte dépend du traitement et du droit applicable. Le principe opérationnel est plus large : une personne concernée a besoin d'une prise réelle sur la décision, et non d'une promesse générique que quelqu'un, quelque part, pourra l'examiner.

Cette prise doit être reliée aux preuves. Si une personne conteste une priorisation, l'autorité doit pouvoir récupérer le contexte décisionnel pertinent, et non seulement la version actuelle du modèle. Si un enregistrement source a été corrigé ultérieurement, l'organisation doit distinguer l'état d'origine de l'état corrigé et indiquer ce qui a changé. Si un examinateur humain a rejeté un résultat, le dossier doit montrer que le système n'a pas pris la décision finale. Une contestabilité sans dossier est une invitation polie à répéter la question.

Les fournisseurs peuvent contribuer à rendre la contestabilité possible. Ils peuvent exposer les entrées versionnées, les motifs, les liens vers les sources, les états d'examen, les événements de correction et les formats d'exportation. Ils peuvent faire en sorte que le service fasse une pause plutôt que de continuer silencieusement lorsque des preuves manquent. Ils ne peuvent pas décider de l'explication due en vertu du droit public, ni du recours qu'un organisme public doit offrir. Ce sont des choix institutionnels. Un fournisseur peut construire des prises. L'autorité doit décider où mènent ces prises.

Les frontières des données sont des frontières publiques

Les discussions sur les marchés publics traitent souvent les données comme une entrée à connecter après la sélection du fournisseur. Dans un service public, les frontières des données sont aussi des frontières d'autorité. La source détermine ce que le système est autorisé à savoir, ce qu'il peut déduire, ce qu'il peut conserver et quelles personnes peuvent être affectées par une erreur. Un fournisseur ne devrait pas définir ces frontières en rendant la connexion facile.

Les exigences doivent nommer les sources autorisées, la finalité, la fraîcheur, la conservation, l'accès, la correction et la suppression. Elles doivent distinguer les enregistrements primaires des éléments dérivés tels que les plongements, les résumés, les étiquettes, les caches et les scores. Elles doivent préciser quelles données quittent l'autorité, quels sous-traitants peuvent les traiter et comment l'accès du support est consigné. Elles doivent définir ce qui se produit lorsqu'une source est incomplète, obsolète, contestée ou hors de la finalité initialement déclarée.

Il ne s'agit pas uniquement d'une question de confidentialité. La discipline des sources affecte la qualité et la légitimité d'une décision. Une administration publique peut détenir de nombreux enregistrements et manquer néanmoins de base légale ou fiable pour les utiliser dans un flux de travail particulier. Un modèle peut trouver une corrélation techniquement utile et institutionnellement inacceptable. Un document récupéré peut être à jour mais non autorisé. L'exigence d'achat doit permettre à un opérateur de distinguer les informations disponibles des informations justifiées.

La même discipline aide le fournisseur. Des limites de sources claires réduisent la tentation de promettre qu'un modèle général peut traiter toutes les questions. Elles rendent les évaluations reproductibles. Elles définissent ce que le service doit faire lorsqu'une entrée sort de son contrat. Un système capable de dire que les preuves sont insuffisantes est souvent plus utile qu'un système qui peut toujours renvoyer une réponse. Les acheteurs publics devraient récompenser ce comportement plutôt que de traiter le refus comme un défaut de la démonstration.

Les exigences doivent décrire l'échec

La plupart des appels d'offres décrivent le chemin souhaité : recevoir des données, les traiter, renvoyer un résultat, mesurer la performance. Les services publics ont aussi besoin des chemins non souhaités. Un enregistrement manque. Une langue n'est pas prise en charge. Le modèle change. Une source entre en conflit avec une règle. Un fournisseur est indisponible. Un examinateur est en désaccord. Une personne fait appel. La sortie est utilisée hors de la finalité prévue. Une personne concernée demande une correction. Un incident est découvert des mois après la décision.

Les exigences d'échec doivent être testables. Le système doit s'arrêter lorsqu'un champ obligatoire manque. Il doit identifier la version et le périmètre de la source derrière une recommandation. Il doit fournir une procédure d'arrêt sécurisé. Il doit exporter les enregistrements dans un format documenté. Il doit notifier l'autorité des modifications importantes. Il doit prendre en charge un parcours de correction pour les artefacts dérivés. Il doit conserver suffisamment de contexte pour une enquête autorisée. Il ne doit pas substituer silencieusement un modèle ou une classe de source différent lorsque celui déclaré est indisponible.

Ces exigences ne sont pas des tentatives de prévoir chaque mauvaise journée. Elles sont des moyens de rendre visible la posture de sécurité du service. Un fournisseur peut proposer une mise en œuvre différente, mais l'autorité peut comparer les propositions sur la base d'un comportement observable. L'appel d'offres devient moins une liste de fonctionnalités et davantage une question de savoir si le service peut porter la responsabilité sous pression.

Le langage de l'échec améliore aussi la conversation commerciale. Un fournisseur qui ne peut pas offrir un arrêt sécurisé, une exportation fiable ou un avis de version peut encore convenir à une tâche à faible enjeu. L'autorité peut le décider ouvertement. Elle n'a pas à découvrir la limite après la signature. Personne n'a besoin d'un appel d'offres techniquement excitant et opérationnellement hanté.

Le contrat est une conception opérationnelle

Un contrat pour un service public doté d'IA devrait décrire plus que la disponibilité et les heures de support. Il devrait décrire les preuves, le changement, l'accès, l'examen, la réponse aux incidents et la sortie. Ces termes façonnent ce que l'autorité peut savoir et faire après le début du service. Ils font partie de l'architecture même lorsqu'ils apparaissent dans des annexes juridiques.

Le contrôle des modifications est essentiel. Ce qui compte comme une modification matérielle du modèle, des invites, des données, de la récupération ou des politiques. Le préavis requis. Les évaluations à relancer. Qui peut accepter la modification. Ce qui se passe si les performances changent pour un sous-groupe ou une langue. L'autorité peut-elle différer une mise à jour. Peut-elle revenir en arrière. Le fournisseur peut avoir besoin de flexibilité pour maintenir un service, mais une flexibilité sans trace écrite est un transfert de risque déguisé en agilité.

Les conditions d'accès devraient couvrir plus que les tableaux de bord. L'autorité peut avoir besoin de journaux, de configuration, d'artefacts de test, d'identifiants de source, de dossiers de support et d'un historique des modifications. L'accès doit être proportionné et sécurisé, avec protection des données personnelles et séparation des secrets. Il ne s'agit pas d'exiger chaque détail d'implémentation interne. Il s'agit de garantir que l'autorité peut vérifier ce que le service a fait dans le contexte où elle l'a utilisé.

Les conditions relatives aux incidents doivent prévoir des voies nommées et des délais adaptés aux conséquences du système. Elles doivent préciser qui peut déclarer un incident, qui peut suspendre le flux de travail, quelles preuves sont conservées, comment les personnes concernées sont prises en compte et comment la remédiation est vérifiée. Un service qui ne signale que les pannes d'infrastructure ne signale pas les incidents qu'un organisme public aura le plus probablement besoin d'expliquer.

La responsabilité du fournisseur est réelle, mais différente

Il est faux de dire que le fournisseur n'a aucune responsabilité. Les fournisseurs conçoivent des systèmes, formulent des affirmations, fixent des limites, gèrent les mises à jour, choisissent des sous-traitants et contrôlent une partie des preuves. Une autorité publique devrait les tenir à ces engagements. La responsabilité technique et contractuelle du fournisseur compte, surtout lorsque l'autorité ne peut pas reproduire indépendamment chaque composant.

Il est tout aussi faux de faire de la responsabilité du fournisseur un substitut à la responsabilité institutionnelle. Le fournisseur n'a pas choisi la finalité publique, défini le groupe concerné, décidé qu'un résultat était suffisant pour le service, établi la voie de recours ou déterminé quel risque le public devrait accepter. Ces décisions appartiennent à l'autorité et au cadre juridique qui l'entoure. Un organisme public qui affirme que le modèle a décidé décrit son propre échec à garder la décision entre des mains publiques.

La relation utile est une interdépendance explicite. Le fournisseur fournit un composant ou un service dans des conditions documentées. Le déployeur l'intègre dans une structure de finalité, de processus et de rôles. Les deux parties conservent les preuves de la partie qu'elles contrôlent. L'autorité reste en mesure de contester le fournisseur, de suspendre l'utilisation et d'expliquer l'action publique. Si la conception d'un fournisseur rend ces capacités impossibles, le choix d'approvisionnement lui-même devient partie du risque.

Les bons contrats n'exigent pas que le fournisseur accepte chaque responsabilité inconnue. Ils répartissent les obligations afin que chaque partie puisse les exécuter. L'autorité doit fournir un contexte licite et approprié. Le fournisseur doit divulguer les limites et les changements. L'opérateur doit utiliser le système dans le cadre défini. Le réviseur doit avoir un pouvoir réel. Les enregistrements doivent survivre au litige. La précision sur les rôles est plus aimable qu'une clause qui dit que les parties coopéreront et espère que tout le monde apporte le même dictionnaire.

La portabilité est une exigence de jugement

La sortie est souvent traitée comme une question commerciale. Pour les services publics, c'est aussi une question de jugement. Si l'autorité ne peut pas récupérer les preuves, la configuration, les enregistrements et les décisions nécessaires pour poursuivre un service ou enquêter sur son passé, elle ne peut pas pleinement posséder les décisions prises via le service. Un système qui ne peut pas partir emporte avec lui une partie de la mémoire de l'institution.

La portabilité doit couvrir l'état opérationnel, et pas seulement les lignes d'une base de données. L'autorité peut avoir besoin des enregistrements d'entrée et de sortie, des références aux sources, des versions des modèles et des invites, des paramètres de politique, des décisions d'examen, des événements d'audit, de l'historique des corrections, des métadonnées de conservation et des schémas qui les expliquent. L'ensemble exact dépend du service. Le principe est qu'un futur opérateur doit pouvoir comprendre ce qui s'est passé sans avoir à faire de rétro-ingénierie sur le tableau de bord privé d'un fournisseur.

La sortie doit être testée avant de devenir urgente. Une courte répétition peut révéler si une exportation est complète, si les identifiants restent stables, si les enregistrements peuvent être lus sans licence, si les données dérivées peuvent être rapprochées et si le service peut fonctionner pendant une transition. Le test expose également les parties du flux de travail qui n'ont jamais vraiment appartenu à l'autorité. Un test de sortie réussi n'est pas un vote de défiance envers le fournisseur. C'est la preuve que le service public a un interrupteur d'arrêt.

La continuité compte même lorsque le contrat se déroule bien. Les fournisseurs peuvent changer de propriétaire, de tarifs, de conditions, d'infrastructure ou d'orientation stratégique. Un organisme public ne devrait pas avoir besoin d'une crise pour découvrir que les seules personnes qui comprennent sa piste de décision travaillent pour quelqu'un d'autre. L'approvisionnement est le moment de rendre la continuité ordinaire plutôt qu'héroïque.

Le deuxième visuel : une porte de jugement, pas un tampon en caoutchouc

Un examinateur n'est un point de contrôle que lorsque le cas peut encore changer, que les preuves sont visibles et qu'un recours reste possible.

Acheter la capacité de dire non

L'exigence d'approvisionnement la plus forte est parfois un refus. L'autorité doit pouvoir dire non à une utilisation qui ne peut pas être prouvée, non à un changement qui n'a pas été évalué, non à un résultat hors périmètre et non à un fournisseur qui ne peut pas offrir une sortie viable. Ce n'est pas de l'hostilité envers la technologie. C'est l'indépendance minimale requise pour choisir une technologie à des fins publiques plutôt que de choisir un objectif qui correspond à la technologie déjà achetée.

Dire non nécessite une voie interne. Un examinateur doit savoir qui peut décider qu'un cas est trop risqué pour être automatisé. Un propriétaire de service doit pouvoir faire une pause sans attendre un comité de pilotage qui se réunit le mois prochain. L'approvisionnement doit reconnaître qu'une offre avec moins de fonctionnalités peut être plus sûre parce que ses limites sont plus claires. Les équipes juridiques, techniques et opérationnelles doivent pouvoir contester le fournisseur privilégié avant que la décision ne devienne socialement délicate.

Les fournisseurs profitent aussi de cette discipline. Un non clair leur donne un cadre défini dans lequel s'améliorer. Il évite qu'un prototype prometteur soit vendu comme une réponse universelle. Il rend les critères d'acceptation significatifs. Il empêche aussi l'interprétation la plus enthousiaste du prestataire de devenir la politique de fait. L'enthousiasme est un carburant utile pour l'exploration. Il ne remplace pas un frein.

La capacité de refuser fait partie de la souveraineté au niveau du service. Elle signifie que l'autorité peut garder une tâche humaine, restreindre les données, exiger davantage de preuves, choisir un autre fournisseur ou arrêter un déploiement sans perdre de vue l'intérêt public. C'est une meilleure définition de l'indépendance technologique que le nombre de produits dans un catalogue.

L'achat public devrait inclure ceux qui porteront le travail

Les équipes d'achat ont besoin de plus qu'une évaluation technique et d'une revue juridique. Les personnes qui exploiteront le service devraient aider à définir la tâche, les modes de défaillance et les preuves qu'elles peuvent raisonnablement inspecter. Les agents de traitement, les inspecteurs, les administrateurs, les traducteurs, les cliniciens, les enseignants ou les planificateurs savent où un résultat soigné devient un cas difficile. Ils savent aussi quelles solutions de contournement apparaîtront lorsqu'un système ne convient pas.

L'implication devrait être concrète. Demandez aux opérateurs de parcourir des cas représentatifs et difficiles. Demandez-leur ce qu'ils ont besoin de voir avant d'accepter une recommandation. Demandez où commence un recours, où une source est corrigée et quels délais rendent une pause dangereuse. Demandez à quoi ressemble un refus sûr. Ce ne sont pas des gestes de recherche utilisateur. C'est la découverte des exigences pour un service qui sera exploité par des humains plutôt que par le diaporama.

Les personnes concernées devraient aussi être prises en compte. Leur perspective peut révéler qu'une distinction technique ne produit pas une explication compréhensible, qu'un parcours de correction est trop lent ou qu'un avis traduit change le sens pratique. L'achat public ne peut pas transformer chaque service en consultation, mais il peut tester si la frontière proposée est visible de l'extérieur de l'institution. Une personne ne devrait pas avoir à comprendre l'architecture pour comprendre comment contester un résultat.

Le résultat est généralement moins élégant qu'une démonstration et plus durable qu'elle. Le travail réel contient des interruptions, des exceptions, des différences linguistiques, de vieux dossiers, des besoins d'accessibilité et des personnes qui ne se comportent pas comme des données de test. Ce n'est pas un échec du service public. C'est le service public. L'achat public devrait acheter pour ce monde.

Le suivi est la façon dont la propriété se poursuit

La propriété ne s'arrête pas au lancement. Les modèles, les systèmes sources, les politiques, le comportement du personnel et les besoins du public changent. Un système peut continuer à produire des résultats pendant que son sens dérive. Le suivi devrait donc relier les signaux techniques à l'action publique qu'ils soutiennent. La disponibilité et la latence comptent, mais aussi les dérogations, les corrections, les recours, les effets de file d'attente, les preuves manquantes, les résultats par sous-groupe, la couverture linguistique et la gravité des erreurs.

Le plan de suivi devrait indiquer ce qui se passe lorsqu'un signal franchit un seuil. Qui enquête. Qui peut suspendre. Quels enregistrements sont conservés. Quelles personnes ont pu être touchées. Si le fournisseur est contacté. Quand l'autorité communique. Comment un correctif est vérifié. Un tableau de bord sans règle de réponse n'est pas de la gouvernance. C'est une suggestion très colorée.

L'évaluation devrait être répétée après des changements importants et à des intervalles adaptés à l'usage. Une mise à jour du modèle peut modifier les résultats même si le fournisseur affirme que l'interface est inchangée. Un changement de politique peut modifier ce qu'un résultat correct signifie. Une nouvelle source de données peut introduire un proxy ou un modèle d'erreur différent. Un organisme public a besoin d'assez d'historique de versions pour comparer les états et d'assez d'autorité pour décider qu'un changement apparemment mineur exige un examen plus large.

La surveillance protège également le relecteur. Si une personne est censée prendre le pas sur un système, l’organisation devrait vérifier si la charge de travail, l’interface ou les incitations rendent cela réellement possible. Des taux de dérogation élevés peuvent indiquer un modèle faible, une politique floue ou un relecteur qui fait le vrai travail autour d’un outil mal conçu. Traiter chaque dérogation comme un bruit humain est un moyen facile de passer à côté de la spécification réelle du système.

Un service hypothétique rend la frontière visible

Prenons un service public hypothétique qui reçoit des demandes et utilise le système d’un fournisseur pour identifier les informations manquantes et suggérer une voie de traitement. Le système n’est pas autorisé à décider de l’éligibilité. L’autorité a documenté l’objectif, les sources de données et les cas nécessitant une attention particulière. Un relecteur voit les références sources, l’explication des champs manquants, la version du système et une option claire pour ignorer la suggestion. L’enregistrement conserve l’action du relecteur et l’avis envoyé au demandeur.

Dans cet exemple, le fournisseur a un rôle significatif. Il peut améliorer l’extraction, exposer l’incertitude, prendre en charge des mises à jour sûres et remplir ses obligations en matière d’incidents et d’exportation. L’autorité conserve la propriété de l’objectif du service, de la norme juridique, du rôle de relecture et du recours. Si un champ est erroné, le demandeur peut le corriger. Si la suggestion sort du cadre, le relecteur peut la rejeter. Si le système échoue, l’autorité peut suspendre la voie et poursuivre avec une alternative documentée. L’utilité vient de la frontière, pas de la prétention que le fournisseur est devenu l’institution.

Changeons maintenant une condition. La voie suggérée par le système est traitée comme la valeur par défaut, les relecteurs ne voient qu’une couleur et un badge de confiance, et le fournisseur peut mettre à jour le modèle sans avis qui atteigne le propriétaire du service. Le contrat qualifie toujours la sortie de consultative. Le flux de travail en a fait une autorité. C’est pourquoi les étiquettes juridiques ne peuvent pas sauver une conception opérationnelle qui donne à la sortie le pouvoir de décider.

L’hypothèse est volontairement simple. Elle ne contient ni municipalité, ni incident, ni client inventés. Son but est de montrer les choix que l’approvisionnement doit rendre observables. Les services réels ajouteront de la complexité. Les questions restent : qui définit l’usage, qui voit les preuves, qui peut changer le résultat, qui enregistre la raison et qui peut réparer le préjudice.

Ce qu’un acheteur public devrait demander

Un dossier d’approvisionnement pratique peut transformer ces principes en questions auxquelles les soumissionnaires et les équipes internes doivent répondre. La liste n’est pas un modèle universel, et chaque secteur aura besoin de ses propres détails juridiques et opérationnels. C’est un moyen de faire entrer la frontière dans la salle dès le début.

  • Quelle tâche publique est soutenue, et quelles actions sont explicitement hors du cadre ?
  • Qui est concerné, qu’est-ce qu’une sortie erronée pourrait changer et dans quelle mesure ce changement est-il réversible ?
  • Quelles données, sources, versions et hypothèses sont utilisées, et qui peut les corriger ?
  • Quelles preuves accompagnent une sortie, et un relecteur autorisé peut-il les inspecter et les contester ?
  • Que se passe-t-il lorsque l’entrée est manquante, contradictoire, non prise en charge ou en dehors de la distribution déclarée ?
  • Quel rôle peut rejeter, déroger, suspendre, arrêter ou escalader, et ce rôle est-il doté en personnel et autorisé ?
  • Comment les changements de modèle, de prompt, de récupération, de politique et de données sont-ils identifiés, testés, approuvés et annulés ?
  • Comment une personne concernée reçoit-elle un avis, une correction, une explication et une voie de recours praticable ?
  • Quels journaux, enregistrements et exportations restent disponibles pour l’autorité pendant le contrat et après la sortie ?
  • Que signale le fournisseur comme incident, et comment la remédiation est-elle prouvée ?

Ces questions ne remplacent ni un appel d'offres, ni une étude d'impact, ni un avis juridique. Elles rendent plus difficile pour chaque document de supposer qu'un autre document assume la partie difficile. Elles permettent aussi à un acheteur de comparer les fournisseurs sur ce qui rend un service gouvernable, et non seulement sur ce qui rend une démonstration impressionnante.

Notre petite note, tardive et délibérée

Chez Dweve, nous travaillons sur des systèmes gouvernés, nous connaissons donc bien la tentation de faire du produit le héros. La discipline la plus utile est plus modeste : énoncer la finalité, lier l'autorité, conserver les preuves attachées, rendre les passations inspectables et laisser une voie de correction. Notre propre documentation sur les achats et la gouvernance part de ces limites, car un flux de travail responsable importe plus qu'une description convaincante d'un outil. C'est un exemple de position de conception, et non la preuve qu'un produit peut remplacer une institution publique.

Le propos n'est pas que chaque acheteur public devrait utiliser notre logiciel, ni qu'une seule architecture résout les achats publics. C'est que le même test s'applique à nous comme à n'importe qui d'autre. L'acheteur peut-il comprendre ce qui est acheté, ce qu'il est autorisé à faire, quelles preuves il laisse, comment il évolue et comment l'acheteur peut en sortir. Si la réponse est non, l'acheteur a une raison de continuer à poser des questions, quelle que soit la tonalité européenne, ouverte ou policée du fournisseur.

La décision reste à l'organisme public

Les achats publics sont souvent décrits comme une voie vers une bonne gestion des deniers publics. C'est vrai, mais la valeur ne se limite pas à un prix plus bas ou à un processus plus rapide. Un service public doit aussi pouvoir motiver ses décisions, corriger ses erreurs, résister à l'examen, protéger les droits et continuer à fonctionner lorsqu'un composant change. Un système qui fait gagner du temps tout en rendant ces obligations impossibles n'est pas une bonne gestion des deniers publics. C'est un futur litige acheté à prix réduit.

Un fournisseur peut apporter des capacités, des preuves, de la maintenance et une voie d'amélioration. L'autorité publique doit apporter la finalité, l'autorité, le jugement, le recours et la propriété. Le contrat doit rendre ces relations explicites. Le flux de travail doit les rendre visibles. L'enregistrement doit les rendre récupérables. La personne concernée doit pouvoir trouver la porte par laquelle une correction peut entrer.

C'est pourquoi un service public ne peut pas externaliser son jugement. L'institution peut déléguer une tâche, mais elle ne peut pas déléguer le sens public du résultat. Elle peut utiliser un modèle, mais elle ne peut pas utiliser la confiance du modèle comme raison de cesser de réfléchir. Elle peut acheter un assistant, mais elle ne peut pas acheter un assistant puis désigner cet assistant comme partie responsable. L'autorité publique ne se déplace pas simplement parce qu'un schéma logiciel comporte une flèche.

La question honnête en matière d'achats publics n'est donc pas de savoir si le fournisseur peut automatiser ceci. C'est de savoir si l'organisme public peut continuer à comprendre, contester, suspendre, corriger, expliquer et sortir pendant que le fournisseur aide. Si la réponse est oui, la technologie a sa place dans un service gouvernable. Si la réponse est non, la bonne décision peut être de restreindre l'usage, de modifier le contrat ou de refuser l'achat. Un organisme public qui sait dire non fait encore son travail.

Sources