Comment acheter et tester un outil numérique sans rendre le pilote irréversible ?

Définir ce que le pilote doit apprendre

Le besoin du pilote se distingue du besoin final. Le service peut vouloir vérifier si un moteur retrouve les passages pertinents, si les agents peuvent contrôler les sources et si le temps total diminue. Il ne demande pas encore l’intégration générale de tous les dossiers. La commande décrit le périmètre, les utilisateurs, les documents et les résultats attendus du test, afin que la prestation et l’évaluation portent sur le même objet.

L’article L.2111-1 du code de la commande publique impose une définition précise du besoin avant consultation, avec prise en compte du développement durable. Cette exigence concerne aussi l’achat expérimental. Le pilote peut être limité, mais le mot expérimentation ne justifie pas une prestation indéfinie dont le contenu serait découvert au fil des échanges avec le fournisseur.^[1]

Les spécifications prévues par l’article L.2111-2, dans la version applicable aux consultations nouvelles depuis août 2026, prennent également en compte les dimensions du développement durable. Pour un outil numérique, l’équipe doit traduire les attentes pertinentes en caractéristiques vérifiables : capacité utile, limites de conservation, conditions d’usage et consommations lorsqu’elles sont pertinentes. Une promesse commerciale de solution durable ne remplace pas cette définition.^[1]

Le protocole indique enfin les décisions possibles après le test. Continuer à l’identique, réduire le périmètre, changer les réglages ou renoncer constituent des options distinctes. Le responsable identifie les critères qui peuvent déclencher chacune. Sans cette préparation, toute information défavorable peut être traitée comme un défaut provisoire à corriger par un investissement supplémentaire, et le pilote perd sa fonction de choix.

Conserver une commande et une concurrence cohérentes

L’article L.1111-1 définit le marché par la réponse aux besoins de l’acheteur en contrepartie d’un prix ou d’un équivalent. Une prestation de test peut donc relever d’une commande, même si son intitulé évoque une coopération ou une démonstration. Le dossier examine les obligations et contreparties réelles. Le caractère court du contrat ne suffit pas à l’exclure du cadre applicable.^[2]

Les principes de l’article L.3 imposent notamment égalité de traitement, liberté d’accès et transparence selon les conditions du code. Le service doit donc préparer le pilote sans construire artificiellement le besoin autour d’un opérateur pressenti. Les échanges préalables peuvent apporter une connaissance du marché ; leur résultat doit être utilisé de manière compatible avec la procédure retenue et l’information des candidats.^[3]

La prolongation et l’intégration doivent être envisagées dès la préparation du montage. Un petit test ne doit pas servir à créer une situation technique dans laquelle seul son fournisseur peut poursuivre, alors que cette dépendance était évitable. Le dossier décrit les interfaces et les éléments récupérables. Les conditions d’une éventuelle suite sont examinées juridiquement, sans promettre que la réussite du test attribuera automatiquement le déploiement au même opérateur.

Les droits sur les livrables doivent correspondre à l’usage. Le service distingue l’outil du fournisseur, les documents qu’il transmet, les configurations et les résultats du test. Il identifie les droits nécessaires à la vérification et à la sortie. Une clause générale disant que tout appartient au service peut être inadaptée ; une absence de clause peut rendre inutilisable un corpus de test qu’il a pourtant financé.

Encadrer les données et la fin du test

Le pilote peut commencer sur des documents publics ou des cas fabriqués lorsque cela permet de vérifier les fonctions recherchées. Cette limitation réduit certains risques, mais ne doit pas être présentée comme une preuve de validité pour les dossiers réels. Si le passage à ces dossiers est nécessaire, l’équipe examine les finalités, les données et les conditions de traitement avant d’élargir le test.

Lorsque le fournisseur agit comme sous-traitant, l’article 28 du RGPD exige un cadre adapté aux opérations. Le contrat doit traiter les instructions, les garanties, les intervenants ultérieurs et l’assistance nécessaire. La durée du pilote n’efface pas ces exigences. Le service doit savoir ce qui est conservé et ce qui sera restitué ou supprimé à la fin, ainsi que les conditions de vérification.^[4]

L’article 32 conduit à examiner les risques de sécurité ; l’article 35 appelle une analyse d’impact lorsque les conditions de risque élevé sont réunies. La qualification ne dépend pas du nom pilote. Une expérimentation sur des dossiers de personnes peut avoir des conséquences dès le premier jour, même si aucune décision finale de généralisation n’est encore prise. Le protocole prévoit donc les restrictions et les moyens d’interruption adaptés.^[4]

La sortie comprend aussi la continuité du service. Les agents conservent un circuit de recherche sans l’outil, les sources restent accessibles et les résultats nécessaires sont exportables dans des conditions utilisables. Une possibilité contractuelle de résiliation n’est pas une sortie praticable si les équipes ne peuvent plus travailler sans le système. Le test doit éprouver cette réversibilité, au moins sur les fonctions essentielles.

Tester une recherche documentaire fictive

Dans un exemple fictif, un service teste pendant huit semaines un outil qui retrouve des passages dans sa documentation. Le protocole utilise cinquante questions construites, avec des réponses de référence et des cas où aucun texte ne permet de répondre. Le besoin est la recherche fiable de sources, pas la production d’une réponse plausible à toute question. Les cas sans réponse font donc partie du test dès le début.

Les agents effectuent les mêmes catégories de tâches avec et sans outil, selon un dispositif permettant de limiter les différences de difficulté et les effets d’apprentissage. Le suivi mesure le temps jusqu’à une réponse vérifiée, les sources erronées et les recherches incomplètes. Le temps de génération seul n’est pas retenu comme gain de productivité : le service a besoin d’un résultat contrôlé, pas seulement d’un texte rapidement produit.

Sur les cinquante cas fictifs, l’outil fournit une source correcte dans quarante cas, une source insuffisante dans six et une réponse sans fondement dans quatre. La seule proportion de sources correctes ne suffit pas à décider. L’équipe examine si les quatre réponses sans fondement sont repérables et si elles concernent des situations particulièrement importantes. Un défaut rare peut avoir une conséquence élevée.

Le temps moyen sans outil est de vingt minutes ; avec outil, la recherche prend cinq minutes et la vérification douze. Le gain net apparent est donc de trois minutes, avant prise en compte des reprises exceptionnelles et de la maintenance documentaire. Si les cas difficiles exigent quinze minutes supplémentaires, leur fréquence doit être intégrée. Le protocole ne doit pas annoncer un gain de quinze minutes en omettant le travail déplacé vers le contrôle.

Le service prévoit trois options. Il peut poursuivre sur la recherche de passages publics, réduire les catégories de questions ou abandonner si les réponses non fondées restent difficiles à détecter. Le choix est rapproché du coût de licence, du temps de contrôle et des conditions de mise à jour. Une bonne démonstration commerciale ne remplace pas l’observation du service dans ses tâches.

Avant la fin, un exercice de sortie vérifie l’export du corpus de test, la récupération des résultats utiles et le travail sans outil. Les données du fournisseur sont traitées selon les stipulations ; les pièces du service sont conservées dans leur environnement propre. Ce test peut révéler une dépendance qui n’apparaissait pas dans les essais de qualité. La réversibilité devient alors un résultat vérifié, pas seulement une phrase du contrat.

Décider de la suite sur des conditions explicites

L’objection selon laquelle un test limité serait trop éloigné du fonctionnement réel est partiellement fondée. Une généralisation doit examiner les volumes, les utilisateurs et les dossiers supplémentaires. Le pilote apporte une preuve sur un périmètre déterminé, pas une garantie universelle. Le responsable prépare donc une étape suivante proportionnée et évite d’extrapoler les résultats aux fonctions qui n’ont pas été éprouvées.

Une seconde objection tient au coût de l’évaluation. Elle doit être adaptée à la décision et au risque. Quelques cas décisifs et un suivi du temps réel peuvent être plus utiles qu’une mesure massive sans critère de choix. Les exigences essentielles, telles que la protection des données et la qualification de la commande, ne deviennent toutefois pas facultatives parce que le budget du test est modeste.

La décision finale indique le périmètre autorisé, les défauts acceptés ou corrigés et les conditions de réexamen. Elle précise la procédure de poursuite et les engagements financiers permis. Si le pilote est arrêté, la sortie prévue est exécutée. Si le service est élargi, les qualifications et flux sont repris. Le résultat du test ne doit pas servir de dispense générale aux étapes juridiques de la nouvelle prestation.

Acheter et tester utilement suppose donc de préparer le choix autant que l’usage. Dans la recherche documentaire fictive, l’information décisive porte sur les sources, le temps de vérification et la capacité de sortie. Le pilote reste réversible parce que sa commande, ses données et ses options sont définies. Le déploiement peut alors être décidé sur une utilité constatée, avec des limites connues et des engagements compatibles avec le droit applicable.