Introduction
Lancer un appel d'offres pour une solution d'avatar IA sur borne interactive nécessite de traduire des attentes métier en exigences techniques, opérationnelles et contractuelles claires. Ce document propose un canevas prêt à l'emploi pour structurer la RFP, définir des critères de choix exploitables par un comité de sélection et construire un protocole de preuve de concept (POC) qui permette d'évaluer les candidats sur des scénarios réels.
Le guide couvre les sections obligatoires du cahier des charges, les rubriques de sécurité et gouvernance de la base de connaissances, un modèle de clauses à négocier (SLA, support, propriété des données) et un protocole POC opérationnel. Il s'adresse aux DSI, responsables expérience client, acheteurs IT et chefs de projet en charge du pilote et de la sélection fournisseur.
Structure recommandée du cahier des charges
Pour faciliter la comparaison des offres, la RFP doit suivre une structure homogène. Demandez aux candidats de remplir chaque section et de fournir des preuves documentées, démonstrations fonctionnelles, et références techniques.
Prévoyez un format de réponse standardisé avec annexes techniques et grille de scoring fournie aux soumissionnaires afin d'assurer une évaluation objective.
Résumé du projet et périmètre des sites pilotes
Exigences fonctionnelles détaillées
Spécifications techniques et compatibilité matérielle
Sécurité, confidentialité et gouvernance de la base de connaissances
Exploitation, maintenance et support opérationnel
Protocole POC et critères d'acceptation fonctionnels et techniques
Exigences fonctionnelles à formaliser
Listez précisément les usages attendus de l'avatar sur borne ou écran : accueil, information produit, orientation, FAQ métier, orientation vers un service humain. Pour chaque usage, précisez l'entrée utilisateur attendue (voix, tactile), les canaux de sortie (voix synthétique, texte à l'écran) et le niveau d'autonomie requis.
Documentez les exigences linguistiques et de persona. Par exemple, indiquez les langues prioritaires du périmètre et les attentes sur la cohérence de la persona. Rappelez que certaines capacités multilingues peuvent être fournies par la solution : SANIA peut communiquer dans plus de 100 langues, mais la RFP doit demander la qualité attendue pour les langues ciblées et les tests associés.
Modes d'interaction supportés : tactile uniquement, vocal uniquement, ou mixte
Cas d'usage prioritaires à lancer pendant le POC
Attentes en matière de personnalisation visuelle et vocale (persona)
Contraintes d'accessibilité à vérifier sur site
Spécifications techniques et compatibilité
Décrivez l'infrastructure cible : type d'écrans et bornes, système d'exploitation SoC/OS (par ex. Samsung Tizen, Android, Windows). Indiquez que la compatibilité effective doit être testée lors du POC, car la disponibilité d'un OS dépend du matériel déployé sur chaque site. Précisez également les contraintes réseau, proxy, et sécurité attendues.
Demandez des informations claires sur l'architecture logicielle : modes d'hébergement possibles (cloud, edge, hybride), possibilité d'utiliser plusieurs moteurs LLM selon la configuration, et les interfaces exposées (APIs, webhooks) pour intégrations POS, CRM ou inventaire. Précisez que chaque intégration tierce constitue une phase d'intégration spécifique à chiffrer.
Compatibilité avec les familles d'OS à préciser site par site et testée en POC
Options d'hébergement proposées et contraintes opérationnelles
Interfaces techniques disponibles pour intégration temps réel
Exigences audio : ASR, TTS et gestion de l'environnement bruyant
Sécurité, confidentialité et gouvernance de la base de connaissances RAG
La RFP doit détailler les exigences de sécurité applicables à la base documentaire et aux échanges API. Demandez des engagements sur le chiffrement en transit et au repos, la gestion des accès, la segmentation des données multitenant et la possibilité d'audits externes. Précisez aussi les responsabilités relatives à la détection, la suppression ou l'anonymisation des informations sensibles fournies en entrée.
Incluez une rubrique sur la gouvernance des contenus alimentant la RAG : flux d'ingestion des documents, process de validation humaine, périodicité des mises à jour et mécanismes de retrait d'information obsolète ou erronée. Évitez de préscrire une méthode technique spécifique ; exigez en revanche des preuves de processus et d'outils permettant d'assurer la qualité et la traçabilité des modifications.
Exploitation, SLA et clauses contractuelles clés
Précisez les attentes opérationnelles sans fixer de valeurs arbitraires : demandez aux fournisseurs d'indiquer leurs engagements en matière de disponibilité, de délai moyen de traitement des incidents critiques, de fenêtres de maintenance et d'accompagnement lors des mises à jour. Demandez aussi un plan de continuité et de restauration après incident.
Voici des clauses à intégrer ou à négocier dans le contrat : définition des niveaux de service attendus, procédures d'escalade et d'astreinte, modalités de support et d'accès aux correctifs, responsabilités concernant la sécurité des données, propriété intellectuelle des contenus métier et conditions de sortie en cas de résiliation. Prévoyez des modalités de validation des livrables en phase POC et un processus clair de recette opérationnelle.
Protocole POC et critères d'évaluation opérationnelle
Le POC doit être conçu comme une évaluation sur des scénarios représentatifs et reproductibles. Demandez une durée et un périmètre adaptés à la fréquentation et aux langues cibles, et exigez la mise en place d'un environnement de test isolé reproduisant la configuration réseau et matérielle d'au moins un site pilote.
Pendant le POC, évaluez la solution selon des axes concrets : adéquation fonctionnelle sur les cas métier, robustesse des intégrations API, comportement en multilingue, ergonomie vocale en conditions réelles, et capacité à utiliser la base de connaissances fournie. Établissez des critères d'acceptation qui s'appuient sur des tests pass/fail et sur des rapports d'anomalies documentés.
Jeux de tests fonctionnels pré-établis et répliqués sur le site pilote
Scénarios d'intégration avec systèmes métier simulés ou réels
Tests multilingues sur les langues prioritaires et observation utilisateur
Tests de robustesse en cas d'indisponibilité d'un service externe
Grille de scoring et méthode décisionnelle (orientation pratique)
Proposez une grille de critères regroupés en familles : pertinence fonctionnelle, qualité technique et intégrations, sécurité et gouvernance, exploitation et support, coût total de possession et maturité du fournisseur. Pour la gouvernance de la décision, affectez une importance plus élevée aux critères opérationnels et de sécurité si le projet implique des données sensibles ou des sites à forte affluence.
Pour assurer une décision rationnelle, demandez aux fournisseurs des preuves vérifiables : démonstrations en live, accès restreint au backoffice pour validation, et résultats détaillés du POC. Utilisez un comité multi‑disciplinaire rassemblant IT, exploitation et métier pour compulser les résultats et arbitrer les compromis entre exigence fonctionnelle et contraintes opérationnelles.
Checklist de préparation interne et critères d'acceptation concrets
Avant l'envoi de la RFP, préparez un jeu de contenus métier structuré à fournir au soumissionnaire pour le POC : documents produits, FAQ, et accès de lecture aux systèmes nécessaires (APIs, fiches produits). Identifiez clairement les sites pilotes et préparez la logistique (réseau, permissions du matériel, plan d'accès technique).
Définissez des critères d'acceptation clairs et traçables pour la recette finale : validation des cas d'usage définis, démonstration d'intégrations opérationnelles, preuve de capacité multilingue sur les langues cibles et conformité aux exigences de sécurité. Formalisez également le processus de correction des anomalies et la remise des livrables attendus à la fin du POC.
Préparer les contenus métier et jeux de données pour le POC
Garantir les accès réseau et API nécessaires au soumissionnaire
Sélectionner au moins un site pilote et définir les contacts locaux
Organiser les sessions d'observation utilisateur et de recette
Conclusion
Un appel d'offres clair et structuré permet de comparer objectivement les offres et de réduire les risques liés au déploiement d'un avatar IA sur borne ou écran. En exigeant un POC rigoureux, des preuves techniques et des engagements contractuels sur l'exploitation et la sécurité, vous réduisez l'incertitude opérationnelle lors du passage en production.
SANIA est une solution d'avatar IA conversationnel professionnel conçue pour l'accueil, l'information et l'orientation sur écran ou borne, avec une disponibilité 24/7 et des capacités multilingues reconnues. Pour tester concrètement l'adéquation d'une solution à vos sites pilotes, vous pouvez demander une démonstration et construire une RFP sur la base de ce modèle.