Mise en place d’un chatbot client

Le marché porte sur la conception, la fourniture en mode SaaS, la configuration, l’intégration, la mise en service et l’exploitation d’un chatbot pour le site actionlogement.fr et les extranets concernés. Le périmètre initial vise l’entrée « Salarié » et certaines pages destinées aux clients personnes physiques ; il exclut les entrées « Propriétaire bailleur », « Bailleur social », « Partenaire » et « Collectivité ». Sur les pages authentifiées, le chatbot reste générique et n’accède pas aux données du compte ou du dossier de l’utilisateur.

Fonctions, connaissances et expérience utilisateur

Le chatbot échange en langage naturel en français et en anglais, traite les fautes, synonymes et acronymes, conserve le contexte pendant la session, demande des précisions en cas d’ambiguïté et affiche des liens vers les ressources pertinentes. L’utilisateur peut réinitialiser la conversation, ce qui supprime les données de la session. L’interface est personnalisable selon la charte graphique ; elle ne s’ouvre qu’à l’initiative de l’utilisateur et indique qu’il échange avec un assistant automatisé.

La base de connaissances exploite uniquement des sources validées. Elle permet notamment l’ajout, la modification et la suppression de contenus, la mise à jour de l’index, la réindexation à la demande, la traçabilité des versions, la détection d’incohérences et la gestion des droits d’administration. Les réponses doivent être fondées sur les sources autorisées, rester dans le périmètre défini, signaler l’insuffisance d’information et permettre de retrouver les sources utilisées. Les utilisateurs habilités peuvent examiner les conversations et repérer les demandes non couvertes ou les réponses potentiellement erronées.

L’escalade vers un interlocuteur humain est prévue lorsque la réponse ne peut être fiable, que l’utilisateur le demande, que plusieurs tentatives échouent ou que la demande nécessite l’examen d’un dossier individuel. Les demandes hors des activités d’Action Logement Services sont signalées puis clôturées, sans orientation vers un autre organisme.

Architecture, intégration et conformité

La solution SaaS comprend une interface web, un moteur conversationnel, la gestion et la recherche des connaissances, une console d’administration, l’historisation et la supervision des conversations, des tableaux de bord, des mécanismes d’intégration au Centre de Relation Client et un mode dégradé. Le périmètre initial n’inclut ni application mobile native ni plateforme de messagerie tierce. Le titulaire précise notamment les capacités d’API, d’import/export, de connecteurs CRM et de compatibilité Microsoft Dynamics.

L’intégration au site et aux extranets est réalisée par les équipes en charge de ces applications ; le titulaire fournit les composants, la documentation et l’accompagnement nécessaires. L’intégration doit éviter le recours à une iframe, préserver performances, référencement, accessibilité et sécurité, prendre en compte le consentement et la politique CSP, et permettre activation, désactivation et retour à une version opérationnelle.

Le dispositif doit respecter le RGAA applicable à la mise en service et maintenir sa conformité pendant le marché. Les exigences comprennent notamment la navigation clavier et lecteur d’écran, l’annonce des nouveaux messages, un contraste de niveau AA, l’absence de temporisation imposée, la lisibilité avec agrandissement du texte jusqu’à 200 % au moins et l’absence de soumission de formulaire sans validation explicite. Avant recette, le titulaire fournit un audit RGAA ou une déclaration de conformité ; les vérifications combinent tests automatisés et tests manuels avec NVDA, JAWS ou VoiceOver.

Les données fournies par Action Logement Services ne peuvent servir à entraîner un modèle généraliste. Le titulaire documente les modèles, fournisseurs, lieux d’hébergement — données dans l’UE, de préférence en France —, traitements et sous-traitants. Toute modification du modèle, du fournisseur, de l’hébergement ou des modalités de traitement requiert l’accord écrit préalable d’Action Logement Services. La solution doit aussi respecter le RGPD et la réglementation européenne applicable à l’intelligence artificielle.

Phases, livrables et vérifications

Le projet prévoit le cadrage (besoin, cas d’usage, sources, contraintes, architecture et planning), la conception et la configuration des parcours et des règles de réponse, puis l’intégration, les tests et la préparation de l’exploitation. Les livrables comprennent notamment la note de cadrage, l’architecture cible, le planning, le dossier de conception, la cartographie des intentions et parcours, les règles d’escalade, le dossier d’architecture technique et les procédures de déploiement et de retour arrière.

La recette couvre les fonctions conversationnelles, l’intégration, les connaissances, les performances, la sécurité, l’accessibilité, la continuité, l’escalade et la non-régression. Elle inclut des jeux d’essais et l’évaluation des réponses, de leurs sources et des demandes hors périmètre. La VABF ne peut être prononcée si une anomalie P1 ou P2 demeure ouverte ; les autres anomalies peuvent faire l’objet de réserves assorties d’un plan de correction. Après mise en production, la VSR dure quatre semaines et vérifie notamment stabilité, disponibilité, qualité des réponses, escalade, sécurité, continuité et suivi des consommations. Les livrables comprennent également le dossier d’exploitation, la documentation d’administration et d’utilisation, les tableaux de bord de VSR et le bilan de démarrage.

Exploitation, suivi et réversibilité

Le titulaire assure la maintenance corrective et préventive, les mises à jour de sécurité et techniques, l’assistance aux administrateurs, la supervision, le suivi des performances et la prise en charge des incidents selon les SLA du CCTP. Le mode dégradé permet de désactiver l’IA générative, de maintenir un socle de réponses de type FAQ et d’orienter vers le Centre de Relation Client ou les formulaires appropriés. L’amélioration continue porte notamment sur les connaissances, les parcours, les règles d’escalade et la qualité des réponses ; les évolutions nécessitant un développement spécifique suivent le processus contractuel prévu.

L’administration comprend la gestion des sources, règles, profils et habilitations, la revue des conversations, la traçabilité des changements et la restauration d’une configuration antérieure. Le reporting suit les usages, la qualité et la performance, notamment résolution automatique, escalades, échecs, abandons, réponses sourcées ou non fondées, temps de réponse et parcours. Les données sont exportables dans un format exploitable ; les indicateurs sont agrégés ou anonymisés lorsque l’identification n’est pas nécessaire.

Le dispositif FinOps suit consommations, coûts, prévisions et risques de dépassement ; des alertes configurables sont prévues aux seuils de 70 %, 85 % et 95 % du volume ou du budget alloué. La réversibilité couvre notamment connaissances, configurations, règles conversationnelles, jeux de tests, statistiques et documentation, dans des formats standards exploitables. Le plan initial est établi au cadrage ; sa version actualisée est transmise dans les dix jours ouvrés suivant son déclenchement et, sauf accord différent, les éléments sont restitués dans les vingt jours ouvrés suivant la demande. Un test d’export ou un exercice de réversibilité peut être demandé pendant le marché.

Le titulaire forme les équipes désignées à l’administration, à la gestion des connaissances, à l’analyse des conversations et au suivi des indicateurs, remet les supports correspondants et transfère les compétences nécessaires à leur autonomie.