Organiser un pilote d’IA qui permet une décision de déploiement

Définir le besoin avant de choisir le produit

Le besoin doit décrire une fonction et un résultat attendu. Demander un outil d’IA sans préciser les tâches, les utilisateurs et les contraintes revient à laisser le fournisseur définir une partie du projet. Pour un service documentaire, le besoin peut être de retrouver une règle dans un corpus identifié et de fournir un passage vérifiable. La capacité à rédiger un texte long est alors secondaire si le problème initial concerne la fiabilité de la recherche.

L’article L. 2111-1 du code de la commande publique exige que la nature et l’étendue des besoins soient déterminées avec précision avant le lancement de la consultation, en prenant en compte les objectifs de développement durable dans leurs dimensions économique, sociale et environnementale. Pour l’usage étudié, cette exigence conduit à préciser le corpus, le nombre d’utilisateurs, les accès, l’intégration et les prestations de contrôle attendues. La procédure de passation dépendra de la valeur estimée et des caractéristiques du marché réel. ^[4]

Le coût doit comprendre le service complet. L’abonnement ou la consommation technique ne représente qu’une partie de la dépense. Il faut ajouter la préparation des documents, leur mise à jour, la formation, les vérifications, le traitement des incidents et la sortie du contrat. Une offre moins chère à l’usage peut devenir plus coûteuse si les agents corrigent systématiquement des réponses non sourcées ou si l’export des données exige une prestation supplémentaire.

L’équipe définit également les exclusions. Le pilote peut interdire l’accès aux dossiers individuels et aux données confidentielles, tout en autorisant un corpus public contrôlé. Cette limite doit être traduite dans la configuration et dans les droits d’accès. L’article 5 du RGPD fournit les principes de finalité et de minimisation lorsque des données personnelles sont concernées ; le mot expérimentation ne dispense pas de les appliquer. ^[1]

Relier les responsabilités au contrat

Le chef de projet organise le travail, mais il ne doit pas absorber toutes les responsabilités. Le service métier définit les situations à résoudre ; l’acheteur prépare les engagements contractuels ; les responsables numériques examinent l’architecture ; le délégué à la protection des données conseille sur les opérations concernées. Une personne habilitée décide du passage à l’étape suivante. Cette répartition doit rester lisible lorsqu’un résultat technique et un risque juridique donnent des conclusions différentes.

Si le fournisseur traite des données personnelles pour le compte du responsable, l’article 28 du RGPD impose un cadre de sous-traitance correspondant aux opérations réelles. Le contrat doit notamment encadrer les instructions, les garanties, les autres sous-traitants et l’assistance. Un contrat commercial général ne suffit pas à prouver que les données du pilote ne seront pas conservées ou réutilisées pour une autre finalité. Les engagements doivent pouvoir être contrôlés. ^[3]

La réversibilité est préparée avant le début des essais. Le service décrit comment récupérer le corpus, les réglages et les traces nécessaires, comment supprimer les copies et comment continuer sans l’outil. Une sortie théorique qui nécessite plusieurs mois de reconstruction n’offre pas la même liberté qu’un export utilisable. Le pilote doit donc tester une opération de restitution limitée, et pas seulement lire une clause promettant la restitution.

Le règlement IA exige également une qualification du système et des rôles. Les articles 6, 26 et 27, lus avec le calendrier modifié de l’article 113, ne permettent pas de transformer tout pilote public en système haut risque immédiatement soumis aux mêmes obligations. Ils justifient toutefois d’identifier sa destination et les modifications susceptibles de changer cette qualification. Un outil documentaire qui évolue vers l’évaluation de l’éligibilité appelle une nouvelle analyse, même si le fournisseur reste identique. ^[5]

Un pilote documentaire avec des résultats travaillés

Le cas est entièrement fictif. Un service de vingt agents veut retrouver plus rapidement des réponses dans une documentation publique validée. Il prépare cent questions fabriquées : soixante questions ordinaires, vingt questions portant sur une règle récemment modifiée et vingt questions hors du périmètre documentaire. Les réponses attendues sont établies avant le test par des personnes compétentes. Les nombres servent à montrer le raisonnement et ne décrivent pas un résultat réel.

Le protocole exige une réponse accompagnée d’un passage exact du corpus ou un refus explicite lorsque la documentation ne permet pas de répondre. Sur les quatre-vingts questions relevant du corpus, soixante-huit réponses seraient correctement fondées dans le scénario. Huit utiliseraient un passage exact mais insuffisant pour la conclusion. Quatre citeraient une règle ancienne. Le taux apparent de réponses disponibles serait donc trompeur : produire une citation ne prouve pas que la réponse est juridiquement fondée.

Sur les vingt questions hors périmètre, l’outil refuserait de répondre à quinze et proposerait une réponse plausible aux cinq autres. Ces cinq sorties sont traitées comme des erreurs importantes, parce que l’agent pourrait les prendre pour une information issue du corpus. Le pilote examine alors l’affichage de l’absence de source et les conditions de refus. Il ne compense pas ces erreurs par la bonne rédaction des réponses ordinaires.

Le temps de travail est également comparé. Dans l’hypothèse pédagogique, une recherche habituelle exige six minutes par question, tandis que la génération exige une minute et la vérification trois minutes. Sur une réponse correcte, le gain serait de deux minutes. Mais une réponse erronée nécessitant six minutes supplémentaires de reprise peut annuler plusieurs gains. L’évaluation calcule donc le temps jusqu’à une réponse utilisable, et non le temps d’apparition du premier texte.

Le service teste ensuite une mise à jour du corpus. Une règle ancienne est retirée et remplacée par sa version actuelle. Les questions concernées sont rejouées, puis l’équipe vérifie si les références périmées demeurent dans les sorties ou les caches. Cette épreuve porte sur une capacité essentielle du service : maintenir une information exacte dans le temps. Une démonstration initiale sur un corpus figé ne permet pas de répondre à cette question.

Enfin, une indisponibilité est simulée. Les agents doivent pouvoir retrouver les mêmes documents sans assistance et poursuivre l’accueil. La procédure de secours indique où se trouve le corpus, qui signale l’incident et comment éviter l’utilisation d’une réponse non vérifiée. Le test révèle que certains utilisateurs ne connaissent plus le circuit documentaire habituel. Une formation complémentaire est donc intégrée avant toute extension du dispositif.

Décider sur des critères annoncés à l’avance

Les critères de sortie doivent être définis avant l’examen des résultats, afin de ne pas déplacer les exigences pour conserver un outil apprécié. Ils peuvent porter sur l’exactitude des références, la reconnaissance du hors périmètre, le temps total de contrôle et la capacité de secours. Les valeurs numériques choisies dans un projet ne sont pas des seuils légaux universels. Elles doivent être justifiées par les conséquences de l’erreur et les moyens du service.

La décision ne doit pas additionner indistinctement les résultats. Une absence de garantie sur la confidentialité ou une incapacité à arrêter un usage peut constituer un obstacle, même si les utilisateurs sont satisfaits. De même, une bonne moyenne peut masquer une faiblesse sur les questions récentes. Le rapport présente donc les résultats par catégorie et identifie les défauts qui conditionnent la poursuite. Une note globale unique peut dissimuler les problèmes les plus importants.

Les droits des personnes doivent rester opérationnels lorsque le pilote utilise des données personnelles. Les articles 12 à 22 du RGPD imposent des exigences de transparence et organisent les droits dans les conditions prévues par le règlement. Le service doit savoir rechercher les données concernées, répondre à une demande et expliquer les opérations. Un dispositif expérimental sans circuit de réponse aux personnes ne devient pas conforme parce que le nombre de dossiers serait limité. ^[2]

L’objection à cette préparation est son coût. Il peut sembler excessif de construire un protocole pour un outil facile à essayer. Mais l’essai peut engager des données, créer une dépendance et modifier les habitudes de travail avant qu’une décision formelle soit prise. La proportionnalité consiste à adapter les preuves au périmètre et aux conséquences, pas à supprimer les critères. Un usage documentaire limité permet un protocole plus simple qu’une aide à une décision individuelle.

Passer du pilote à un périmètre assumé

La décision finale distingue trois possibilités : poursuivre le périmètre testé, corriger puis rejouer certaines épreuves ou arrêter l’usage. Elle identifie les engagements du fournisseur, les moyens internes et les limites conservées. Dans le cas fictif, les difficultés sur les règles anciennes et le hors périmètre justifient une correction avant extension. La satisfaction des agents demeure une information utile, mais elle ne remplace pas ces constats.

La réponse à la question initiale est de construire un pilote qui autorise réellement un refus. L’achat définit la fonction, le contrat rend les responsabilités contrôlables et les tests mesurent une réponse utilisable avec ses coûts de vérification. La gouvernance décide sur ce périmètre précis. Si l’usage change, les données, les conséquences et les obligations doivent être réexaminées ; le succès d’une recherche documentaire ne vaut pas autorisation d’automatiser une décision publique.