Pour comparer les offres de chatbot IA, le cahier des charges fixe une base commune

Un 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 laisse chaque fournisseur choisir son vocabulaire, son niveau de preuve et ses réserves. Deux réponses peuvent alors sembler couvrir le même besoin tout en engageant des données, des responsabilités d’exploitation ou des conditions de sortie différentes. L’entreprise doit donc construire le document d’achat à partir 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 à prononcer l’acceptation. Les critères d’acceptation constituent la liste de contrôle qui confirme que le service répond au besoin utilisateur ^[1]. Des critères de choix précis facilitent aussi l’identification d’un fournisseur capable d’y répondre ^[3]. La comparaison gagne ainsi 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. Le niveau retenu doit donc se lire dans les preuves demandées. Une architecture différente reste recevable lorsque le résultat soumis à l’acceptation demeure inchangé et explicite.

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

Le point de départ est une situation réelle : une personne formule une demande, depuis un canal identifié, avec 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].

Un critère exploitable associe une entrée connue, un résultat observable et une règle de décision. « Répondre correctement » ne suffit pas : personne ne sait quelle variation 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 peut remplacer la véritable recette.

Le scénario doit aussi préciser ce qui entraîne un refus. Une réponse peut être exacte mais provenir d’une source non autorisée ; une action peut aboutir tout en utilisant un droit excessif ; un transfert peut partir sans responsable identifiable. Ces écarts ne se résument pas dans une note moyenne. Le cahier des charges les rattache à l’exigence concernée, à la preuve consultable et à la personne qui décide d’une correction, d’une réserve ou d’un refus de réception.

Avant la consultation, une dernière lecture doit repérer les exigences dont l’acceptation ne peut pas encore être prononcée. Si la preuve disponible ou l’autorité compétente reste inconnue, l’attente demeure trop vague pour comparer les réponses.

Les données autorisées fixent la limite technique

La frontière des données précède 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 les fournisseurs sur un même trajet fonctionnel sans imposer prématurément leur 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 devient une réserve signalée par le fournisseur, jamais un engagement implicite.

La permission minimale se formule comme une capacité nécessaire à un 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 voisine qui doit être refusée. Le journal attendu établit 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. Chaque catégorie reçoit une règle proposée, un moyen de suppression, la liste des copies concernées et une 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 trajet représentatif permet de contrôler cette réponse. Le document suit une information depuis sa saisie, vérifie la source consultée, observe la donnée transmise au service intermédiaire, puis identifie la trace et la copie éventuellement conservées. Le fournisseur doit pouvoir indiquer à chaque étape le rôle autorisé, la nécessité de l’information et la manière de la retirer. Le test ne dicte pas où chaque composant doit fonctionner ; il impose que la proposition rende le trajet compréhensible et vérifiable.

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

Le nom du logiciel ne suffit pas à décrire une intégration. Elle engage un compte propriétaire, des identifiants, des permissions, un déclencheur, un format d’échange et une conduite 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.

Dans une démarche d’assurance, la source inclut les artefacts nécessaires à l’évaluation des exigences applicables aux fournisseurs ^[4]. L’article propose d’appliquer ce point aux intégrations en demandant, 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 sans correspondance avec les critères ne constitue pas une preuve plus forte.

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. Chacune conserve cependant les mêmes scénarios de recette. Cette règle autorise l’innovation architecturale tout en empêchant qu’une option séduisante réduise discrètement le périmètre accepté.

La comparaison peut alors se faire ligne par ligne. Sur un même scénario, la proposition détaille le compte mobilisé, le droit demandé, la sortie produite, 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.

La 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 qui lui sont adressées doivent rester justifiées, proportionnées et réalisables ^[5]. Chaque épreuve est donc reliée 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 du verdict. 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. Les exigences critiques doivent garder leur propre décision.

Cette préparation reste distincte d’un déroulement complet de 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 demeurent impossibles à stabiliser, une conception et un cadrage d’assistant conversationnel constituent une suite logique avant la consultation. Le livrable attendu demeure un périmètre testable, utilisable face à plusieurs réponses.

L’exploitation départage les promesses équivalentes

Deux propositions peuvent réussir la même démonstration tout en transférant des charges très différentes à l’entreprise. 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 construction 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, pour un achat commercial d’IA, de définir contractuellement les responsabilités détaillées et la responsabilité juridique ^[10].

Les indicateurs demandés servent une décision d’exploitation, pas l’apparence d’un tableau de suivi. Chacun doit déclencher une lecture 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 quelle limite empêche de la surinterpréter.

Aucun mode ne bénéficie d’une note 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.

La sortie contractuelle se prépare avant le choix

La réversibilité commence par l’inventaire de ce qui devra rester accessible. Données sources, conversations, configurations, consignes, comptes, connecteurs, journaux et 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 propositions doivent accepter dès maintenant.

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 devient une réserve explicite du contrat, plutôt qu’une difficulté découverte lorsque le service doit déjà être remplacé.

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