← Retour au blog
Automatisation

Quand l’API IA tombe : continuer à travailler en mode dégradé

Le système de réservation ne répond plus, mais les clients continuent d’appeler. Le bon mode dégradé conserve la demande sans inventer une confirmation définitive au client.

Automation IA fonctionnant en mode dégradé pendant une panne d’API externe

Vendredi, 16 h 43. Un client téléphone pour obtenir un rendez-vous lundi. L’assistant comprend la demande, mais l’API de réservation renvoie un timeout. Deuxième tentative, même résultat. La pire réponse serait : « C’est confirmé » en espérant que l’écriture passe plus tard.

La deuxième pire réponse serait de perdre complètement la demande.

Le mode dégradé se place entre les deux. L’automation offre moins de fonctions, tout en restant utile et honnête. Elle enregistre le contact et le souhait de créneau, ne promet pas de disponibilité, crée une tâche visible et explique qu’une confirmation suivra.

Les architectures résilientes utilisent depuis longtemps des mécanismes comme le circuit breaker et le health monitoring. Une PME n’a pas besoin d’une plateforme complexe pour appliquer l’idée métier : qu’est-ce qui peut continuer sans danger quand une dépendance ne répond plus ?

Le mode dégradé d’une automation IA commence par les fonctions

Dire « l’API est down » est trop vague. Le modèle peut fonctionner alors que le CRM ne répond plus. Le calendrier peut être lisible mais refuser les écritures. Le paiement peut être indisponible alors que le support reste normal.

Définissez trois états : normal, dégradé, arrêté.

En normal, le workflow lit, décide et exécute dans son périmètre. En dégradé, il garde les tâches sûres : collecte de demande, informations stables, demande de rappel, création d’une queue. Les actions qui nécessitent un état en temps réel — confirmer un slot, débiter, finaliser une commande — s’arrêtent.

En mode arrêté, même la collecte n’est plus suffisamment fiable ; le canal humain prend le relais.

Fait confirmé : les patterns de résilience comme circuit breaker et health checks servent à détecter les dépendances défaillantes et à éviter la propagation des erreurs.

Recommandation : écrivez le comportement métier réduit avant la panne.

Le mot dangereux pendant une panne : « probablement »

L’IA conversationnelle cherche à aider. Si une source live ne répond plus, cette tendance peut produire des suppositions convaincantes.

Un calendrier inaccessible ne signifie pas qu’un horaire « semble libre ». Une écriture CRM échouée ne doit pas afficher « client créé ». Une absence de réponse du paiement ne vaut pas « payé ».

Le mode dégradé a donc besoin de règles négatives explicites : pas de promesse live sans source live ; pas de succès après un write non confirmé ; pas de retry aveugle lorsqu’on ignore si la transaction a quand même été exécutée.

Exemple hôtel : le PMS est indisponible. L’assistant peut recueillir dates, nombre de personnes, préférence de chambre et coordonnées. Il ne peut pas promettre une disponibilité et un prix actuels si ces informations viennent précisément du système en panne.

Une file visible plutôt qu’un oubli élégant

Une bonne queue transforme l’échec en travail gérable.

Chaque action différée reçoit un identifiant, une heure, l’action souhaitée, le client, la raison et un owner. Le client entend un statut honnête : demande reçue, confirmation en attente.

Au retour du service, ne rejouez pas tout automatiquement. L’équipe a peut-être traité des dossiers à la main. Des clients ont pu rappeler ou annuler.

La reprise peut suivre ce chemin :

  1. Vérifier la santé réelle de la dépendance, pas un seul appel réussi.
  2. Rouvrir progressivement les nouveaux flux.
  3. Trier la queue par âge et urgence.
  4. Comparer l’état cible avant replay, pour éviter les doublons.
  5. Marquer les tâches devenues obsolètes, qui nécessitent un nouveau contact.
  6. Attribuer les exceptions à une personne.

Le replay n’est pas seulement une opération technique ; il doit respecter ce qui s’est passé dans le monde réel pendant la panne.

La formulation au client fait partie du dispositif

Pour l’équipe technique, c’est un timeout. Pour le client, c’est la différence entre une demande et une promesse.

Une phrase correcte peut être : « Notre système de réservation est temporairement indisponible. Je peux enregistrer votre souhait et nous vous confirmerons le rendez-vous dès que l’accès sera rétabli. »

Il n’est pas nécessaire de parler de code 503. Il est nécessaire de dire si l’action est confirmée ou non.

Le transfert humain devient prioritaire lorsque le temps compte : urgence artisanale, arrivée d’hôtel le soir même, client déjà sur place ou dossier financier qui doit être traité avant une échéance. Ces cas ne doivent pas attendre simplement parce que la queue existe.

Le pilote minimum consiste à provoquer la panne

Dans l’environnement de test, coupez volontairement une dépendance. Observez les paroles de l’agent, ses tentatives d’écriture, la qualité de la queue et le redémarrage.

Mesurez le délai de détection, la part des demandes correctement capturées en mode dégradé, les faux états de succès, l’âge moyen des tâches en attente, les traitements après recovery sans doublon et le délai de handover pour les cas urgents.

Le succès n’est pas « l’automation fait tout quoi qu’il arrive ». Dans certains cas, réussir signifie refuser proprement une action que l’on ne peut plus vérifier.

Conclusion : un agent robuste sait fonctionner avec moins. Pour une PME, le bon mode dégradé protège trois choses : le contact client, la vérité sur le statut et la visibilité du travail encore à faire.

À la reprise, ne renvoyez pas toutes les tâches. Vérifiez si l'action cible a pu réussir malgré le timeout. C'est le lien entre protection contre les doublons et rapprochement.

Sources


FAQ

Le mode dégradé est-il simplement un retry ?

Non. Le retry est technique ; le mode dégradé redéfinit les fonctions métier autorisées.

Peut-on confirmer provisoirement un rendez-vous ?

Uniquement si vous disposez d’un vrai mécanisme évitant les conflits. Sinon, enregistrez la préférence sans promettre la disponibilité.

Faut-il rejouer automatiquement toute la queue ?

Non. Comparez d’abord l’état actuel, car une personne ou le client a pu intervenir.

Une petite PME doit-elle installer du health monitoring ?

Un contrôle simple des dépendances critiques est déjà utile. Il n’a pas besoin d’être lourd.

Quand transférer immédiatement à un humain ?

Lorsque l’urgence, la sécurité ou l’impact rendent l’attente de la recovery inacceptable.

Vérifier un vrai processus avant d'en faire un projet IA

Le business check examine un parcours client ou administratif concret. Vous repartez avec une prochaine étape claire, même si la bonne réponse consiste à moins automatiser.

Démarrer le business check gratuit →

Lire plus sur le blog AlpenAgent

D'autres articles sur la voice AI, les chatbots, l'automatisation et les leads.

Découvrir tous les articles →
AlpenAgent
Disponibilité

Voice AI Bot pour appels, rendez-vous et opportunités manquées.

Idéal lorsque des appels sont manqués, arrivent hors horaires ou doivent être préqualifiés proprement.

Questions recommandées
Chat IA · Aucune donnée confidentielle. Confidentialité
Powered by AlpenAgent