Haute disponibilité : guide pratique pour chatbots et

Un lundi matin, un callbot d'assurance reçoit soudainement plus de demandes que prévu. Le modèle LLM ralentit, la recherche documentaire renvoie des réponses incomplètes, puis l'API CRM devient inaccessible. L'agent vocal transfère alors les appels vers des conseillers humains, qui découvrent en quelques minutes que la file d'attente a saturé le centre de contacts.

Le serveur n'a pas forcément cessé de fonctionner. Pourtant, le service conversationnel est indisponible pour le client. Une haute disponibilité efficace doit donc couvrir le modèle, le RAG, les intégrations, la téléphonie, la supervision humaine et les règles de conformité. C'est cette continuité de bout en bout qui compte pour un agent IA conversationnel, pas le simple nombre de machines actives.

Quand un agent conversationnel tombe, ce n'est pas un serveur qui s'éteint

Dans ce scénario, chaque composant peut continuer à répondre isolément. Le fournisseur LLM accepte encore certaines requêtes, la base de connaissances reste joignable, le CRM fonctionne pour les utilisateurs internes. Mais la chaîne complète n'aboutit plus à une réponse utile. Le client entend un silence, reçoit une réponse hors contexte ou attend un transfert qui n'arrive jamais.

Cette distinction change la façon de concevoir la haute disponibilité. Pour un agent conversationnel, le parcours réel ressemble plutôt à ceci :

• Réception du canal : le chat, la voix ou l'email accepte la demande.
• Qualification : l'agent identifie l'intention et les informations nécessaires.
• Orchestration LLM : le modèle produit une réponse ou choisit une action.
• Récupération RAG : le système consulte les documents autorisés.
• Intégration métier : le CRM, la prise de rendez-vous ou le système de commande exécute l'action.
• Escalade humaine : un conseiller reprend la conversation avec son contexte.

Une panne d'un fournisseur LLM peut provoquer une latence qui déclenche des timeouts en cascade. Une base RAG corrompue peut laisser l'agent disponible tout en augmentant le risque d'hallucination. Une intégration CRM lente peut créer des doublons, tandis qu'un pic vocal peut saturer les licences, les trunks ou les files d'attente humaines.

Règle d'exploitation : mesurez la disponibilité d'un parcours client complet, pas uniquement celle de l'API qui semble la plus critique.

Pour un agent combinant LLM, RAG et intégrations, viser un SLO de 99,95 % peut constituer un objectif opérationnel cohérent lorsqu'il correspond au niveau de criticité et au budget d'exploitation. Cette valeur est affichée parmi les niveaux de service d'infrastructures françaises, qui distinguent aussi la disponibilité annoncée contractuellement de la disponibilité réellement mesurée sur l'ensemble du service dans les informations de sécurité et de disponibilité de TimeTonic.

La démarche doit ensuite relier métriques, architecture, supervision, tests de panne et conformité. Les dépendances fournisseurs, le plan de sortie, la localisation des données et le scénario de ransomware sont souvent traités comme des annexes. En production, ils déterminent pourtant si le service peut réellement continuer quand une brique externe échoue.

Comprendre les métriques qui mesurent vraiment la disponibilité

Un restaurant ouvert en continu ne mesure pas seulement si la porte est ouverte. Il vérifie aussi le temps nécessaire pour remplacer un équipement, la quantité de commandes perdues pendant une panne et la capacité à reprendre le service. Un agent IA doit être évalué avec la même logique opérationnelle.

Le MTBF, ou temps moyen entre défaillances, indique la fréquence moyenne des incidents. Le MTTR, ou temps moyen de résolution, mesure le délai nécessaire pour restaurer le service. Le RTO fixe le temps maximal acceptable pour reprendre l'activité, alors que le RPO définit la quantité de données que l'organisation accepte de perdre ou de devoir reconstituer.

Le SLA est une promesse contractuelle faite par un fournisseur. Le SLO est la cible interne que l'équipe se donne pour un parcours ou un composant. La disponibilité effective doit être mesurée dans les journaux, les traces et les parcours synthétiques, car un SLA d'hébergement ne garantit pas automatiquement que le LLM, le CRM et la téléphonie fonctionneront ensemble.

Choisir un objectif par parcours

Un chat web peut parfois afficher une réponse de secours ou proposer un formulaire. La voix, elle, expose immédiatement la latence, les silences et la saturation de l'escalade. L'email supporte généralement une reprise différée, tandis qu'un back-office peut accepter une file d'attente tant que les opérations sont rejouées sans perte.

Ces seuils sont indicatifs, pas universels. Une banque, un service public et une boutique en ligne ne paient pas le même coût pour une interruption. Il faut donc relier chaque SLO à une conséquence observable, comme une transaction interrompue, un rendez-vous non enregistré ou un transfert humain sans contexte.

La base de connaissances participe directement à cette mesure. Une base de connaissance IA pour le service client doit être suivie sur sa fraîcheur, son accessibilité, la qualité de récupération et la capacité à fournir une réponse de repli. Une réponse générée sans preuve exploitable n'est pas un succès de disponibilité.

Architectures et patterns de redondance adaptés aux agents IA

La redondance active-active permet à plusieurs instances de traiter les requêtes en parallèle. Elle convient aux canaux soumis à des variations de charge, mais elle augmente les exigences de cohérence, de routage et de supervision. L'actif-passif est plus simple à exploiter, toutefois la capacité de secours doit rester prête et le basculement doit être testé.

Pour un pic vocal, le premier levier n'est pas forcément une seconde région. Un équilibrage de charge applicatif, un auto-scaling contrôlé et une file d'attente vocale peuvent absorber la pression plus simplement. Le routage doit tenir compte de la latence du modèle, du nombre de sessions actives et de la capacité réelle des intégrations.

Empiler les protections sans sur-architecturer

Un déploiement multi-AZ réduit l'exposition à la panne d'une zone d'infrastructure. Le multi-région ajoute une protection contre un incident géographique ou une dépendance régionale, mais il impose de traiter la résidence des données, les écritures concurrentes et les coûts de réplication.

Pour la base RAG, une réplique chaude permet une reprise rapide avec des données proches de l'état courant. Une réplique tiède réduit les coûts tout en demandant une phase de réactivation. Une réplique froide convient à une reprise plus lente, mais elle ne doit pas être présentée comme une solution de continuité immédiate.

Le choix dépend du risque :

• Panne LLM : prévoir plusieurs modèles compatibles, une politique de routage par capacité et un mode de réponse déterministe pour les demandes simples.
• Corruption RAG : isoler les index, versionner les documents et restaurer une collection connue comme saine.
• CRM indisponible : placer les actions dans une file durable, accuser réception au client et rejouer l'opération après rétablissement.
• Escalade saturée : limiter les transferts simultanés, enrichir le contexte et proposer une reprise différée lorsque le métier l'autorise.
• Panne de routage : redonder l'équilibreur et éviter qu'un mécanisme DNS soit l'unique voie de bascule.

Le failover DNS reste pratique pour une bascule géographique, mais ses délais dépendent des caches et des mécanismes de résolution. Un routage applicatif ou un gestionnaire de trafic réactif offre davantage de contrôle, au prix d'une exploitation plus complexe.

Compromis réel : active-active améliore la continuité et la capacité, mais il ne supprime ni les conflits de données ni les erreurs de configuration.

Un agent de back-office peut souvent accepter une reprise asynchrone, car les tâches sont enregistrées et rejouées. Les parcours qui automatisent des actions sensibles doivent en revanche utiliser des identifiants d'idempotence, des validations métier et des journaux complets, comme dans les agents IA pour le back-office.

Superviser, tester et anticiper les pannes avec le chaos engineering

Une haute disponibilité non observée est une hypothèse. L'équipe doit savoir si l'agent répond, s'il répond assez vite, s'il récupère la bonne information et s'il transfère correctement quand l'automatisation atteint sa limite.

Commencez par définir des SLO sur les parcours, pas seulement sur les composants. La qualification, la récupération RAG, l'exécution d'une action et l'escalade humaine doivent disposer de signaux propres. Un tableau de bord utile distingue la latence de bout en bout, la latence avant le premier token, les erreurs d'intégration, le taux d'escalade et les réponses sans source acceptable.

Construire des alertes qui déclenchent une action

Une alerte doit désigner un propriétaire et un runbook. Une hausse de latence LLM n'appelle pas la même réponse qu'une chute de qualité RAG. Dans le premier cas, l'orchestrateur peut réduire le contexte, choisir un modèle de secours ou basculer vers une réponse courte. Dans le second, il doit suspendre certaines réponses et orienter vers un contenu validé ou un humain.

Sur un callbot, surveillez en particulier :

• Silence et latence vocale : détecter les pauses qui font croire à l'appelant que la ligne est coupée.
• Taux de transfert : distinguer une escalade métier normale d'un transfert provoqué par une panne.
• Qualité de transcription : repérer les erreurs qui dégradent la qualification et les actions.
• Saturation humaine : suivre la file, les capacités de reprise et la transmission du contexte.
• Actions externes : contrôler les timeouts, les reprises et les doublons côté CRM.

Le chaos engineering rend ces contrôles crédibles. Injectez volontairement une indisponibilité du LLM, une latence de l'API partenaire, une réponse vide du moteur RAG ou une saturation du canal vocal. Observez ensuite si l'agent applique bien sa politique de secours, si l'utilisateur reçoit une information honnête et si l'équipe sait restaurer le service sans improviser.

Le test doit rester progressif. Commencez par un environnement contrôlé, définissez le signal d'arrêt, consignez les écarts et mettez à jour le runbook. La résilience progresse quand chaque incident simulé produit une modification vérifiable, pas quand l'équipe accumule des scénarios dans un document oublié.

Choisir entre LLM, RAG et NLP pour équilibrer disponibilité et coût

Le choix technologique influence directement la disponibilité. Un NLP classique répond bien à des intentions bornées et à des formulations prévisibles. Il demande moins de ressources et offre un comportement plus déterministe, ce qui en fait un bon filet de sécurité pour l'identification, les menus vocaux ou les demandes fréquentes.

Un LLM couvre des formulations variées et peut orchestrer plusieurs outils. En contrepartie, il dépend d'une capacité externe ou d'une infrastructure exigeante, avec des variations de latence, de quota et de comportement. Une architecture qui confie chaque étape au même modèle transforme une panne de fournisseur en panne globale.

Le RAG réduit le risque de réponse hors contexte en associant la génération à une base documentaire. Il ajoute toutefois des dépendances, index, embeddings, stockage, filtrage des droits et pipeline de mise à jour. La disponibilité n'est donc pas seulement celle du modèle, mais celle de la chaîne de récupération.

Un mix de modèles vaut souvent mieux qu'un modèle unique

Dans un parcours fiable, un NLU ou un classifieur route les demandes. Les intentions simples vont vers des réponses déterministes. Les demandes nécessitant une synthèse utilisent un LLM avec RAG. Les actions sensibles exigent une validation, une trace et parfois une reprise humaine.

Ce découpage permet de réserver les ressources coûteuses aux cas qui le justifient. Il permet aussi de maintenir un service dégradé quand le modèle principal est lent ou indisponible. Le client peut encore obtenir une information vérifiée, déposer une demande ou recevoir un délai de reprise clairement annoncé.

La capacité doit être exprimée dans des unités d'exploitation, comme les tokens par minute, les sessions vocales simultanées et les appels d'API autorisés. Le coût par requête ne suffit pas. Une solution peu chère devient inutilisable si elle ne dispose pas d'un mode de repli, d'une limite de capacité maîtrisée et d'un plan de migration vers un autre fournisseur.

Conformité RGPD, SecNumCloud et DORA comme leviers de résilience

La conformité ne devrait pas arriver après l'architecture. Elle oblige l'équipe à répondre à des questions qui améliorent directement la continuité, quelles données circulent, où elles sont stockées, qui peut les consulter, comment les restaurer et comment remplacer un fournisseur défaillant.

Avec le RGPD, un agent conversationnel doit limiter les données collectées, contrôler les accès, assurer la traçabilité et organiser la supervision humaine lorsque le parcours le requiert. La localisation des données dans l'Union européenne peut aussi peser dans le choix d'un hébergeur ou d'un fournisseur de modèle. Une gouvernance claire évite qu'un basculement d'urgence envoie des conversations vers un service non validé.

Transformer les exigences en protections concrètes

Le référentiel SecNumCloud intervient dans les environnements qui recherchent un cadre renforcé pour l'hébergement cloud. Les critères de localisation, de contrôle, d'audit et de gouvernance ne sont pas de simples éléments administratifs. Ils structurent la capacité à identifier les dépendances, vérifier les accès et maintenir un niveau de contrôle pendant une reprise.

Pour le secteur financier, DORA est applicable depuis le 17 janvier 2025 et encadre notamment la gestion des risques ICT, les tests de résilience, la notification des incidents majeurs et le contrôle des prestataires ICT, comme le rappelle l'analyse française consacrée à l'Indice de Résilience Numérique et à DORA. Un agent client doit donc être documenté comme une chaîne de dépendances, pas comme une simple interface de dialogue.

La cartographie doit inclure :

• Fournisseurs de modèles : contrats, quotas, délais de notification, compatibilité de remplacement.
• Données et index : localisation, sauvegardes, versions, restauration et suppression.
• Intégrations : CRM, téléphonie, paiement, identité et systèmes de rendez-vous.
• Gouvernance : responsables, validations, journaux, accès d'urgence et supervision humaine.
• Sortie fournisseur : formats exportables, alternatives testées et procédure de repli.

L'ANSSI a enregistré 1 366 incidents de sécurité et 3 586 événements de sécurité en 2025, selon son rapport d'activité 2025. Ces chiffres rappellent que la résilience doit aussi couvrir le ransomware, le déni de service et la compromission d'un prestataire. Une sauvegarde isolée, un accès administrateur contrôlé et un mode dégradé valent souvent davantage qu'une architecture sophistiquée impossible à restaurer.

Feuille de route 90 jours et pièges fréquents à éviter

Une démarche réaliste commence par l'inventaire. Pendant les premières semaines, cartographiez chaque dépendance, du canal jusqu'au CRM, puis classez les parcours selon leur impact métier. Documentez les données manipulées, les délais acceptables, les fournisseurs de secours et les actions qui peuvent être rejouées.

La phase suivante consiste à fixer les SLO et à mettre en place les contrôles essentiels. Déployez la redondance adaptée, comme le multi-AZ pour les composants critiques, une réplique RAG exploitable et une file durable pour les intégrations. L'administration française recommande un plan de continuité et un plan de reprise testés, des sauvegardes 3-2-1 et un support dédié, un socle détaillé dans les recommandations de résilience opérationnelle et de haute disponibilité.

Un calendrier de terrain

• Jours 1 à 30 : dépendances, criticité, SLO, RTO, RPO, données et responsabilités.
• Jours 31 à 60 : redondance des composants prioritaires, modes de secours LLM, versionnement RAG et runbooks.
• Jours 61 à 90 : tests de panne, chaos engineering, restauration, escalade humaine et dossier de conformité.

Trois erreurs reviennent régulièrement. La première consiste à viser 99,99 % sans mesurer le parcours réellement vécu par le client. La deuxième consiste à ignorer la panne du fournisseur LLM externe, alors que l'orchestration en dépend. La troisième consiste à confondre le SLA contractuel avec la disponibilité effective, qui inclut les intégrations, les données et la supervision.

Le bon ordre n'est pas celui qui ajoute le plus de composants. C'est celui qui supprime d'abord les points de rupture les plus probables, puis prouve la reprise par des tests reproductibles. Les solutions de Webotit.ai s'inscrivent dans cette logique avec des agents conversationnels, du monitoring temps réel, des intégrations et une supervision humaine, selon le mode d'hébergement et les contraintes du parcours.

---

Webotit.ai conçoit et déploie des chatbots, callbots, mailbots et agents IA combinant LLM, RAG, intégrations sécurisées et supervision humaine pour traiter les parcours critiques avec continuité de service. Pour cadrer vos dépendances, vos SLO et votre stratégie de secours, visitez Webotit.ai et demandez un diagnostic gratuit de 45 minutes.