Un cahier des charges commun pour comparer les offres de chatbot IA

01Un document très détaillé peut produire des offres incomparables

Un cahier des charges très détaillé peut encore rendre les offres incomparables. L’accumulation de fonctionnalités permet à chaque fournisseur de choisir ses termes, le niveau de preuve qu’il apporte et la manière dont il formule ses réserves. Deux réponses peuvent alors sembler couvrir le même besoin, alors qu’elles ne mobilisent pas les mêmes données et ne prévoient ni les mêmes responsabilités d’exploitation ni les mêmes conditions de sortie. L’entreprise doit donc rédiger son cahier des charges en fonction de la décision d’acceptation qu’elle devra prendre.

Pour chaque exigence, l’acheteur doit préciser le résultat observable, la preuve attendue et la personne habilitée à valider ce résultat. Les critères d’acceptation servent de liste de contrôle pour vérifier que le service répond au besoin de l’utilisateur ^[1]. Des critères de choix précis aident aussi à identifier un fournisseur capable de répondre au besoin ^[3]. La comparaison repose ainsi sur une base commune : périmètre des usages, données permises, intégrations, permissions, validations humaines, conservation, signalement des incidents, exploitation et réversibilité. Le standard GovS 005, destiné aux administrations britanniques, recommande de définir les responsabilités d’exploitation selon le mode d’acquisition ^[2]. Dans le CAF du NCSC, conçu pour des organisations britanniques assurant des fonctions essentielles, la répartition entre client et fournisseur doit être inscrite au contrat ^[7]. Ces deux repères servent ici à construire les questions du cahier des charges, sans transformer leur portée en obligation générale.

Cette hiérarchie évite de traiter toutes les demandes comme des fonctions équivalentes. Une suggestion de réponse, un accès à un dossier interne et une action dans un logiciel n’exposent ni les mêmes informations ni les mêmes responsabilités. Les preuves demandées doivent donc correspondre au niveau de capacité retenu. Une architecture différente reste recevable lorsque le résultat soumis à l’acceptation demeure inchangé et explicite.

02Chaque besoin doit aboutir à une décision d’acceptation

Le point de départ est une situation réelle : une personne formule une demande par un canal identifié, dispose d’un droit déterminé et attend un résultat exploitable. Le cahier des charges précise ce que le système peut répondre, ce qu’il doit refuser et quand une validation humaine devient obligatoire. Les acteurs concernés doivent participer à la formulation et comprendre les exigences qui les touchent ^[6].

Pour être applicable, un critère doit associer une entrée connue, un résultat observable et une règle de décision. « Répondre correctement » ne suffit pas : personne ne sait alors quel écart reste acceptable, quelle source fait foi ou quel comportement adopter en cas d’incertitude. Le document doit également nommer le responsable de l’acceptation. Sans cette attribution, une démonstration convaincante risque de tenir lieu de recette.

Le scénario doit aussi préciser ce qui entraîne un refus. Une réponse peut être exacte tout en provenant d’une source non autorisée ; une action peut réussir avec des droits excessifs ; un transfert peut être effectué sans responsable identifiable. Ces écarts ne peuvent pas être ramenés à une note moyenne. Le cahier des charges les rattache à l’exigence concernée, à la preuve consultable et à la personne qui décide de demander une correction, d’émettre une réserve ou de refuser la réception.

Avant la consultation, une dernière lecture doit repérer les exigences qui ne peuvent pas encore être validées. Si la preuve disponible ou l’autorité compétente reste inconnue, l’exigence demeure trop vague pour comparer les réponses.

03Les données autorisées fixent la limite technique

Le périmètre des données doit être défini avant le choix de la solution. Le document distingue les informations saisies par l’utilisateur, celles que le système peut rechercher, celles qu’il produit et celles qu’un service intermédiaire reçoit. Il indique aussi les catégories exclues. Cette cartographie permet d’interroger tous les fournisseurs sur le même circuit de données sans leur imposer prématurément une architecture.

Le flux complet doit apparaître dans la réponse : point d’entrée, traitements successifs, lieux de stockage déclarés, accès d’administration et mécanismes d’effacement. Toute information manquante doit être signalée par le fournisseur comme une réserve et ne peut valoir engagement implicite.

Chaque permission doit être limitée à ce qui est nécessaire pour l’usage défini. Lire un dossier, créer une entrée ou déclencher une action sont des droits distincts. L’essai de recette porte donc sur l’opération autorisée, puis sur une opération proche mais interdite que le système doit refuser. Le journal attendu doit indiquer ce qui a été demandé, l’identité ou le rôle concerné, la décision du système et l’éventuelle validation humaine.

La conservation utile doit enfin être distinguée de la conservation par défaut. Pour chaque catégorie, la proposition précise la règle applicable, le moyen de suppression, les copies concernées et la preuve disponible. Cette demande ne présume ni une durée universelle ni une architecture unique ; elle rend les réponses comparables sur leurs engagements réels.

Un circuit de données représentatif permet de vérifier ces engagements. Le test consiste à suivre une information depuis sa saisie, à vérifier la source consultée, à observer la donnée transmise au service intermédiaire, puis à identifier la trace et la copie éventuellement conservées. Le fournisseur doit pouvoir indiquer à chaque étape le rôle autorisé, pourquoi l’information est nécessaire et comment la retirer. Le test n’impose pas le lieu d’exécution de chaque composant ; il exige que la proposition rende le circuit des données compréhensible et vérifiable.

04Les intégrations révèlent les responsabilités cachées

Le nom du logiciel ne suffit pas à décrire une intégration. Elle suppose d’identifier le propriétaire du compte, les identifiants utilisés, les permissions accordées, le déclencheur, le format d’échange et la conduite à tenir en cas d’échec. Avant la consultation, le cahier des charges réunit ces éléments afin que la proposition fasse apparaître ce qui relève du fournisseur, du client ou d’un service tiers.

D’après la source ^[4], les livrables d’une démarche d’assurance comprennent les éléments nécessaires à l’évaluation des exigences applicables aux fournisseurs. Pour les intégrations, cela conduit à demander, selon le résultat à vérifier, une représentation du flux, une configuration exportable, un journal d’essai ou une procédure d’exploitation. Un document volumineux qui ne correspond pas aux critères n’apporte pas une preuve plus solide.

Cette matrice rend visibles les dépendances qui resteraient autrement dispersées dans la proposition.

Lorsque ces informations dépendent encore d’un choix technique, la réponse peut présenter des variantes. Chaque variante doit cependant être évaluée selon les mêmes scénarios de recette. Cette règle laisse aux fournisseurs le choix de l’architecture, sans qu’une variante puisse réduire le périmètre soumis à l’acceptation.

La comparaison peut alors se faire ligne par ligne. Pour un même scénario, la proposition détaille le compte utilisé, la permission demandée, le résultat produit, la trace remise et la conduite prévue en cas d’échec. Une variante qui exige un accès supplémentaire doit l’expliquer ; une autre qui ne fournit pas la preuve attendue doit formuler sa réserve. L’acheteur compare ainsi des conséquences d’exploitation et non des listes de connecteurs dont les noms masquent des responsabilités différentes.

05La sécurité se juge sur des épreuves observables

Une déclaration de sécurité renseigne sur l’intention du fournisseur, tandis qu’un protocole permet d’observer le système proposé. Les exigences minimales imposées au fournisseur doivent rester justifiées, proportionnées et réalisables ^[5]. Chaque épreuve doit donc correspondre au risque créé par les usages, les données, les intégrations et les droits réellement demandés.

Chaque cas mentionne la configuration testée, l’entrée utilisée, le comportement attendu, la preuve conservée et le responsable de la décision. Il décrit aussi le traitement d’un échec : correction, nouvel essai, réserve acceptée ou refus de réception. Une moyenne globale masquerait une défaillance rédhibitoire. Chaque exigence critique doit faire l’objet d’une décision distincte.

Cette préparation ne constitue pas le déroulement complet du projet. Elle fixe l’épreuve nécessaire à la comparaison et à l’engagement contractuel. Si les trajets de données, les permissions ou les scénarios ne peuvent pas encore être stabilisés, il est logique de passer par une conception et un cadrage d’assistant conversationnel avant la consultation. Le livrable attendu reste un périmètre testable, utilisable pour comparer plusieurs réponses.

06L’exploitation départage les promesses équivalentes

Deux fournisseurs peuvent réussir la même démonstration tout en transférant à l’entreprise des charges très différentes. La comparaison doit donc identifier qui surveille le service, traite les erreurs, gère les accès, met à jour les consignes, examine les journaux et décide d’une interruption. Dans GovS 005, pour les administrations britanniques visées, les rôles doivent refléter le choix entre développement en interne et achat ^[2].

Le NCSC propose de vérifier si le contrat précise les conditions de gestion et de signalement des incidents, notamment le destinataire et les actions attendues ^[8]. Le contrat consigne aussi les choix de répartition ainsi que les droits et obligations correspondants ^[9]. Dans l’AI Playbook destiné aux organismes publics britanniques, le guide recommande de définir contractuellement les responsabilités détaillées et la responsabilité juridique lorsqu’une solution d’IA est achetée auprès d’un fournisseur ^[10].

Les indicateurs demandés doivent éclairer une décision d’exploitation, et non simplement alimenter un tableau de suivi. Chaque indicateur doit conduire à un examen ou à une décision : qualité d’une réponse, usage d’une source non permise, action refusée, incident ouvert, intervention humaine ou modification en attente de validation. Le fournisseur précise comment l’information est obtenue, qui peut la consulter et quelles limites doivent être prises en compte pour ne pas la surinterpréter.

Aucun mode d’acquisition ne reçoit d’avantage implicite. La décision dépend de la capacité de l’entreprise à assumer les responsabilités qui lui reviennent et des preuves que le fournisseur accepte de remettre.

07La sortie contractuelle se prépare avant le choix

La réversibilité commence par l’inventaire de ce qui devra rester accessible. Les données sources, les conversations, les configurations, les consignes, les comptes, les connecteurs, les journaux et la documentation ne suivent pas nécessairement le même régime. Le cahier des charges demande pour chaque actif son propriétaire, son format de remise, ses droits d’accès et la procédure applicable à la fin du contrat.

La propriété doit être décrite sans formule globale. Le fournisseur distingue les éléments apportés par l’entreprise, ceux créés pour le dispositif, les composants qu’il concède et les services tiers qu’il ne peut transférer. Il indique également qui contrôle les comptes d’administration pendant le contrat et comment l’accès est récupéré. Dans le CAF du NCSC, pour les organisations britanniques assurant des fonctions essentielles, la répartition des responsabilités entre client et fournisseur doit figurer dans les engagements ^[7].

Obtenir un fichier ne suffit pas à établir la portabilité. L’entreprise doit pouvoir comprendre ce qui est exporté, rétablir les droits nécessaires et identifier ce qui ne pourra pas être repris tel quel. Une réserve technique peut être acceptable si elle est connue avant la décision. Une dépendance découverte à la sortie ne l’est pas.

Le document peut enfin prévoir les conditions d’arrêt : maintien transitoire, interlocuteur responsable, assistance à la remise, accès aux traces et preuve de suppression des copies concernées. Ces exigences ne décrivent pas toutes les opérations futures. Elles fixent les engagements que les fournisseurs doivent prendre dès leur réponse.

Une épreuve de sortie sur un échantillon rend ces engagements concrets avant le choix. Le fournisseur remet les éléments prévus dans le format annoncé, rétablit les accès concernés et explique les dépendances qui ne peuvent être transférées. L’entreprise vérifie que les données restent lisibles, que les configurations sont identifiables et que la documentation permet de reprendre les opérations attribuées au client. Tout écart doit être inscrit comme une réserve explicite dans le contrat, plutôt que d’être découvert lorsque le service doit déjà être remplacé.

La décision peut alors être prise sans avoir à interpréter les promesses du fournisseur : l’offre apporte-t-elle, pour chaque critère déterminant, les éléments nécessaires pour accepter le résultat, le refuser ou demander une correction ? Tant qu’une preuve ou un responsable manque sur l’un de ces critères, le choix reste ouvert.