Introduction : l'objectif d'un RFP centré sur l'usage
Rédiger un appel d'offres pour un avatar IA d'accueil exige d'équilibrer exigences techniques, contraintes opérationnelles, obligations juridiques et critères objectifs d'évaluation. Le document doit permettre à des fournisseurs variés de répondre de manière comparable et au client de classer les réponses sans ambiguïté.
Ce guide propose une checklist structurée, des modèles de clauses contractuelles et de SLA, une grille d'évaluation pondérée et un mapping pour vérifier les différenciateurs techniques courants (RAG, multi‑LLM, intégrations, formats documentaires, compatibilité hardware, accessibilité, support 24/7).
Pourquoi structurer le RFP dès le départ
Un RFP structuré réduit le risque de comparaisons incomplètes, évite les oublis sur les sujets sensibles (protection des données, accessibilité, continuité) et clarifie les interfaces attendues avec les systèmes métiers. Il facilite aussi la phase de négociation contractuelle en ayant préalablement listé les obligations techniques et opérationnelles.
L'objectif opérationnel est simple : obtenir des réponses homogènes, mesurables et vérifiables afin de sélectionner, sur des critères documentés, le fournisseur le plus adapté au contexte de déploiement (sites, publics, contraintes réglementaires).
Checklist RFP structurée - rubriques obligatoires
Inclure les rubriques suivantes comme exigences minimales : objet du marché, périmètre des sites, description des usages prioritaires, contraintes d'accessibilité, attentes en matière de langues, formats d'interaction (vocal, tactile), et modes d'exploitation attendus.
Préciser les éléments techniques indispensables : compatibilité des écrans/borne avec les familles de systèmes (Tizen, Android, Windows) selon l'infrastructure existante, contraintes réseau et sécurité, capacités de déploiement en multi‑sites et modalités de mise à jour centralisée de la base de connaissances.
Objet et périmètre du projet
Cas d'usage prioritaires et exclusions
Contraintes d'accessibilité (modalités vocales, sous‑titres, LSF, tactile)
Langues prises en charge et capacité multilingue
Compatibilité matérielle et familles d'OS (Tizen, Android, Windows) - préciser l'existant
Architecture cible et exigences réseau/sécurité
Checklist RFP - rubriques opératoires et de gouvernance
Demander des précisions sur la gouvernance du contenu : qui édite la base de connaissances, processus de validation des réponses métier, outils de mise à jour et niveau de granularité des droits d'édition.
Préciser les attentes d'exploitation : procédures de maintenance, disponibilité attendue (service continu possible 24/7), modalités de support, formation des équipes et reprise en cas d'incident. Indiquer également les livrables attendus pour la phase pilote et le passage en production.
Modèle de gouvernance et rôles (éditeur, valideur, administrateur)
Processus de mise à jour des contenus métier
Plan de déploiement pilote et critères d'acceptation
Modalités de formation et documentation
Support opérationnel et modalités d'astreinte 24/7
Rubriques juridiques et sécurité des données à demander
Exiger une description claire des traitements de données, du périmètre des données collectées et des mesures de sécurité mises en place. Demander des éléments sur l'hébergement des données et la possibilité d'un déploiement sur une infrastructure dédiée si nécessaire.
Préciser les exigences juridiques à intégrer dans le contrat : responsabilité, propriété intellectuelle des prompts/persona, confidentialité, conditions de sauvegarde et de restauration, conditions de fin de contrat et reprise de données. Formuler ces clauses comme critères d'éligibilité plutôt que comme simples options.
Description des traitements et finalités
Localisation de l'hébergement et options d'infrastructure
Mesures de sécurité techniques et organisationnelles
Propriété des contenus et des adaptations de la persona
Modalités de restitution ou suppression des données à la fin du contrat
Modèles de clauses contractuelles et structure SLA (à personnaliser)
Fournir des modèles de clauses facilite la comparaison. Voici les éléments essentiels que le RFP doit proposer au fournisseur pour réponse : garantie de disponibilité, niveaux de support, maintenance programmée, reprise après incident, confidentialité et audits. Indiquer clairement que les éléments chiffrés seront négociés et insérés dans le contrat final.
Exemple de structure SLA à inclure dans le RFP : définition des niveaux de gravité, engagement de réponse initiale par gravité, engagement de résolution, modalités de notification et d'escalade, maintenance planifiée et reporting. Préciser aussi l'exigence d'une organisation de support pouvant fonctionner 24/7 si le service est exposé en continu.
Définitions : disponibilité, interruption planifiée, incident critique
Niveaux de gravité et réponses attendues (réponse initiale, résolution)
Modalités de notification et d'escalade
Maintenance planifiée et fenêtres de travail
Reporting périodique et revue de service
Grille d'évaluation pondérée et exemple de scoring (exemple hypothétique)
Une grille d'évaluation aide à comparer objectivement les offres. Présenter les critères principaux (technique, sécurité, accessibilité, intégrations, gouvernance, coût total) et expliquer la pondération retenue en interne. Il est important d'adapter la pondération au contexte métier et aux priorités du projet.
Exemple présenté à titre hypothétique : pondérer technique et intégrations plus fortement si le projet implique des connexions à des systèmes métiers, ou privilégier l'accessibilité si le public est prioritairement vulnérable. Ce qui suit est un exemple illustratif et doit être adapté au besoin.
Critères techniques : architecture, support multi‑LLM, RAG, formats documentaires
Sécurité et conformité : mesures techniques, hébergement, audits
Accessibilité : modes vocal/tactile, sous‑titres, support LSF
Opérationnel : gouvernance, formation, support 24/7
Coût et modèle économique : licences, coûts d'intégration, maintenance
Mapping pratique pour vérifier les différenciateurs techniques
Pour vérifier les affirmations techniques des fournisseurs, demander des preuves reproductibles : démonstration sur des cas réels, accès à un environnement de test pour valider la qualité des réponses RAG, tests multilingues et scénarios d'intégration avec des API factices ou sandbox.
Demander à chaque fournisseur de détailler le format et les volumes documentaires acceptés pour l'ingestion, la gestion des versions, et les moteurs LLM compatibles ou orchestrables. Vérifier la compatibilité prévue avec les familles d'écrans/borne (Tizen, Android, Windows) et la capacité à fonctionner en mode vocal, tactile ou hybride selon les configurations.
Preuves demandées : démonstration, environnement sandbox, cas de test métiers
Formats documentaires pris en charge pour RAG (PDF, DOCX, XLSX, TXT, CSV, NDJSON) - demander précisions
Support multi‑LLM et stratégie d'orchestration
Compatibilité matérielle et modalités de déploiement multi‑sites
Tests d'accessibilité et preuves de validation utilisateur
Points de vigilance opérationnels et erreurs fréquentes à éviter
Ne pas négliger la gouvernance des contenus : laisser la responsabilité des réponses uniquement au fournisseur sans définir de processus interne de validation conduit souvent à des dérives de qualité. Préciser qui est responsable de l'actualisation des informations métier.
Éviter d'oublier la phase pilote. Un pilote permet de valider les intégrations, la qualité des réponses, l'ergonomie d'interaction vocale et tactile, et l'acceptation par les utilisateurs. De même, clarifier dès le RFP le périmètre des tests acceptés pour l'acceptation finale.
Définir explicitement la gouvernance des contenus
Prévoir des scénarios de test représentatifs et un pilote formalisé
Vérifier la capacité du fournisseur à fournir un environnement de test
Ne pas confondre disponibilité promise et modalités d'astreinte opérationnelle
En pratique : questions à poser aux fournisseurs lors des entretiens
Pour compléter le dossier écrit, préparer un jeu de questions autour des points sensibles : comment le fournisseur gère la confidentialité des données, quelles garanties sur les sauvegardes et restaurations, comment sont conduits les tests multilingues, et quels outils de back‑office sont fournis pour éditer la base de connaissances.
Demander aussi des démonstrations ciblées sur la gestion des interruptions, la mise à jour des contenus en masse, et la capacité à personnaliser persona et voix selon les contraintes de droits et d'image. Ces éléments permettent de juger la maturité opérationnelle au-delà des réponses écrites.
Exemples de questions : gestion des incidents, reprise, localisation des données
Scénarios de démonstration à demander : import de documents, requête RAG, test vocal multilingue
Évaluer l'ergonomie du back‑office d'édition
Conclusion : formaliser pour réduire le risque et faciliter le choix
Un RFP complet et structuré permet de comparer les fournisseurs sur des bases objectives et réduit les risques liés à la sécurité, à l'accessibilité et à l'exploitation. En structurant les rubriques obligatoires, en proposant des modèles de clauses et une grille d'évaluation, vous facilitez une prise de décision documentée.
SANIA peut illustrer certains des différenciateurs opérationnels évoqués ici : avatar IA d'accueil conçu pour écran ou borne interactive, disponible 24/7 et capable de communiquer dans de nombreuses langues. Pour étudier l'adéquation de cette approche à votre contexte et recevoir un exemple de RFP personnalisable, vous pouvez demander une démonstration et un kit RFP adapté.