API indisponible : ce que l’agent IA peut encore répondre

L’assistant peut encore produire une phrase lorsque l’ERP ne répond plus. Il peut aussi retrouver une ancienne disponibilité ou une procédure dans sa documentation. Le risque commence lorsqu’il présente ces éléments comme une preuve actuelle du stock, ou prépare une opération qui exige la donnée manquante. La fluidité de la réponse ne restaure pas la source dont dépend la décision.

En pratique, chaque question doit définir ses sources obligatoires, les réponses qui restent possibles et les gestes à suspendre. Une API indisponible ne signifie ni stock nul ni dossier absent. L’intégration d’une IA au système d’information doit conserver les états de source jusque dans la réponse et l’autorisation de préparer une action, avec un repli décidé avant la panne.

Vingt-deux scénarios à réponses fictives distinguent consultation du stock, lecture d’une procédure et préparation de réservation lorsque l’ERP ou le CRM manque. Le contrôleur local n’exécute aucun LLM, appel HTTP ou effet distant ; il ne mesure pas la disponibilité d’un service réel. L’accompagnement IA sur mesure de Dawap peut préciser pour chaque étape la source indispensable, la fraîcheur admissible et la réponse à conserver quand la préparation doit être suspendue.

Pour qui une source manquante change la décision

Identifier les réponses qui engagent un état vivant

Le sujet concerne un agent connecté à plusieurs logiciels, dont certaines données évoluent pendant le travail. Expliquer une procédure générale n’exige pas les mêmes preuves que confirmer la disponibilité d’une pièce ou préparer sa réservation. Le métier doit nommer la conséquence de chaque réponse. Une présentation uniforme peut sinon cacher que le système a cessé de consulter la référence nécessaire.

Le banc porte sur la pièce fictive P37 dans A. L’ERP fournit une disponibilité observée de 7 unités, le CRM apporte un contexte facultatif et une procédure indépendante soutient l’explication générale. La préparation demande 2 unités. Aucun stock réel ni réservation n’existe ; ces valeurs servent à vérifier les frontières entre information courante, historique et capacité de préparation.

Choisir la continuité qui reste utile au lecteur

Un arrêt total peut fermer une aide encore utile, tandis qu’un maintien sans restriction peut laisser croire que tout fonctionne. Le repli doit conserver une capacité définie : expliquer la procédure, afficher une observation passée datée ou signaler le report d’une décision. Il indique aussi ce qu’il ne permet plus de confirmer. L’utilisateur n’a pas à deviner cette différence depuis un message technique de connexion.

La référence AWS sur la stabilité statique face aux dépendances défaillantes souligne la préparation avant l’incident. Son contexte est l’infrastructure et les zones de disponibilité. La transposition proposée ici porte sur les capacités métier à conserver ; elle ne démontre aucune stabilité statique du laboratoire ou d’un assistant en production.

Classer les dépendances par question et par effet

Définir ce qui manque avant de choisir un repli

Le même logiciel peut être facultatif pour une question et obligatoire pour une autre. Un CRM absent ne bloque pas ici la lecture de stock ERP. Il pourrait devenir indispensable pour identifier le destinataire d’un message ou vérifier une condition commerciale. Le classement appartient donc à l’opération, et non à une hiérarchie permanente où l’ERP serait toujours critique et le CRM toujours accessoire.

Une dépendance facultative indisponible devient une limite explicite, sans enrichissement inventé. Une dépendance obligatoire absente ferme les affirmations qui en dépendent. Le contrat doit conserver cette liste en sortie, avec provenance des faits encore présentables. La quantité ne peut pas être complétée par une donnée plausible issue du contexte conversationnel lorsque la source choisie comme autorité manque.

Éviter qu’une deuxième source change silencieusement d’autorité

Le CRM peut contenir un ancien commentaire sur le stock, mais il ne devient pas l’autorité de disponibilité pendant une panne ERP. Utiliser ce commentaire demande une politique distincte, avec son origine et sa limite. Le changement de source ne doit pas apparaître seulement dans une trace technique que le lecteur ne verra jamais. Il modifie le sens de l’information et les décisions que celle-ci peut soutenir.

Le banc ne fusionne aucune valeur de quantité CRM avec celle de l’ERP. Il ne teste pas une réconciliation de stocks contradictoires ni une base de remplacement complète. La capacité de continuité dépend de ce que l’équipe a préparé et vérifié. Ajouter un cache ou une réplication demande de tester portée, retard et permissions, plutôt que d’attribuer automatiquement à cette copie l’autorité de son logiciel d’origine.

Distinguer indisponibilité, absence et refus d’accès

Conserver le sens de l’erreur jusqu’à la décision

Une source qui ne répond pas ne prouve pas l’absence de la pièce. Un champ manquant ne vaut pas zéro. Un refus d’accès ne constitue pas une permission de chercher avec un compte plus puissant. Le contrôleur distingue unavailable, not_found_authoritative et forbidden. Le deuxième état est un contrat métier fictif de lecture d’absence, pas une conversion automatique de n’importe quel code HTTP.

La RFC 9110 définit 403 comme un refus de satisfaire la demande et permet à une origine de masquer une ressource interdite par 404. Elle décrit 503 comme une incapacité temporaire de traiter la requête. Le connecteur doit donc interpréter code, endpoint et contrat sans déduire automatiquement un fait métier de la seule présence d’une erreur.

Fermer les données dont le périmètre est incorrect

D37-07 refuse une lecture ERP interdite malgré une copie disponible. D37-08 refuse une réponse portant sur B au lieu de A. D37-12 reçoit une observation datée dans le futur par rapport à l’horloge du banc et la rejette. Ces sorties n’affichent aucune quantité. Une indisponibilité, une mauvaise identité de ressource et une incohérence de temps ne doivent pas être regroupées dans un simple état source lente.

Les droits et horodatages sont injectés dans les objets fictifs ; aucun système d’authentification ou horloge distribuée n’est éprouvé. Dans le SI, le service doit identifier l’autorité de chaque champ et les décalages acceptés. Une valeur reçue avec HTTP 200 peut encore être mal rattachée, inaccessible à la personne ou inutilisable pour l’opération. Le succès du transport ne clôt pas cette revue.

Garder une copie historique dans son propre périmètre

Présenter ce qui était observé sans promettre ce qui reste vrai

Cas concret : D37-04 perd l’ERP courant et retrouve 9 unités dans une copie observée à t=950, révision 3. L’horloge fixe vaut t=1000. La sortie historical_only conserve cette quantité avec quantityMeaning égal à historical_snapshot et une provenance ERP-cache. Elle ne confirme pas la disponibilité présente. Le résultat courant nominal était 7 en révision 4 ; ces deux observations ne sont pas interchangeables.

{"verdict":"historical_only","quantity":9,"quantityMeaning":"historical_snapshot","provenance":[{"source":"ERP-cache","revision":3,"observedAt":950}],"missing":["ERP:unavailable"],"prepared":false,"externalEffects":0}

La fenêtre historique du laboratoire vaut 300 secondes, choisies uniquement pour éprouver la décision. D37-17 porte une observation de 301 secondes et la ferme. D37-18 retire la permission sur la copie et la ferme aussi. Le programme teste âge et périmètre de l’objet ; il ne démontre pas une propagation de révocation ou une invalidation distribuée du cache.

Définir la valeur d’un historique pour le travail réel

Un historique daté peut aider une personne à expliquer un échange passé ou préparer une investigation. Il peut devenir trompeur s’il ressemble à la réponse ordinaire sur l’état présent. Le produit doit distinguer ces usages dans sa formulation et dans ses actions disponibles. Un avertissement discret ne suffit pas si le bouton suivant permet encore de promettre une quantité que le service n’a pas vérifiée.

Le coût caché du repli comprend stockage des copies, contrôle des lecteurs et assistance aux utilisateurs qui doivent comparer les observations. L’équipe doit décider quelles valeurs historiques valent cette charge et lesquelles sont à retirer du parcours. Une durée courte ne prouve pas la justesse actuelle ; elle définit seulement une condition d’âge. La volatilité et la conséquence métier déterminent ce qui peut réellement être présenté.

Répondre partiellement sans inventer une vue complète

Limiter chaque affirmation à ses sources disponibles

D37-02 garde la quantité ERP de 7 lorsque le CRM devient indisponible. Le verdict partial_current porte CRM:unavailable dans missing et conserve seulement la provenance ERP. Il ne fournit ni nom de contact ni condition commerciale supposée. Le résultat utile est une lecture partielle de la source admissible, avec son observation, pas une vue client complète qui aurait miraculeusement survécu à la panne.

Current_source_snapshot signifie que cette observation répond aux conditions locales du banc. Il ne garantit pas que le stock est inchangé au moment où une personne agit. L’ERP nominal est observé à t=990 ; la règle fictive accepte jusqu’à 30 secondes à t=1000. La production doit choisir sa propre fenêtre et prévoir les validations de concurrence nécessaires au prochain effet métier.

Conserver un refus d’accès même sur une dépendance facultative

D37-13 reçoit un refus CRM et continue la lecture ERP, sans restituer de donnée CRM. Le caractère facultatif permet d’omettre cette source ; il ne permet pas de la lire malgré le refus. La sortie indique cette limite de façon structurée. Une interface réelle doit aussi décider comment présenter les raisons sans révéler l’existence de pièces ou de comptes que l’utilisateur ne peut pas connaître.

Un modèle chargé de verbaliser ces sorties doit garder cette portée. Il ne doit pas transformer source manquante en aucun incident connu, ni rattacher une quantité historique à une promesse présente. Le banc n’exécute pas cette verbalisation. Sa recette future doit vérifier compréhension des limites, couverture des affirmations et fidélité aux données, avec questions contradictoires et demandes d’action pendant le mode dégradé.

Fermer la préparation qui manque de preuve actuelle

Distinguer une proposition possible d’une réservation appliquée

Le banc marque prepared lorsque la source ERP satisfait sa politique, la quantité couvre les 2 unités demandées et le droit de préparation reste actif. D37-15 est prepared_only ; D37-16 ajoute prepared_with_limits lorsque le CRM manque. Le programme ne transmet pas un payload ni ne réserve de pièce. Ces verdicts autorisent seulement le stade fictif de préparation dans la recette.

D37-05 possède la même copie historique que D37-04, mais demande une préparation. Il reçoit defer_required_source sans quantité présentée ni préparation. D37-14 retire le droit et ferme aussi ce stade. Paradoxalement, conserver une aide de lecture et fermer son prolongement en action peut donner un service plus fiable qu’un mode dégradé unique appliqué à toutes les capacités.

Éprouver les limites sans leur attribuer une validité universelle

D37-21 porte exactement 30 secondes d’âge et peut préparer ; D37-10 porte 31 secondes et diffère. Cette paire vérifie la frontière du code, sans recommander ce seuil pour un ERP. D37-22 possède seulement 1 unité et ne prépare pas les 2 demandées. Le contrôleur conserve ce fait avec insufficient_quantity, distinct de insufficient_data quand le champ quantité manque dans D37-11.

Une réservation réelle exige une autorisation et un contrat d’écriture au moment de l’effet. La donnée lue peut changer après préparation ; les contrôles de version, de quantité et de cible doivent appartenir au système qui décide l’opération. Une réponse verbale positive ne devient pas son reçu. Le parcours garde proposition, validation et résultat dans des états séparés, avec les moyens de reprise que l’interface permet effectivement.

Différer avec une responsabilité et une condition de reprise

Donner au report un objet que les équipes peuvent traiter

Une réponse différée doit nommer la donnée nécessaire et la capacité suspendue, sans promettre une heure de retour inconnue. Le contrat précise entrée, sortie, responsabilité et condition de reprise. L’instrumentation conserve source, motif et demande concernée. Le repli peut expliquer la procédure ou orienter vers un traitement manuel autorisé ; il ne confirme pas le fait qu’il ne peut plus vérifier.

Exemple concret : une équipe peut poursuivre la préparation documentaire d’un dossier tout en suspendant sa décision de quantité. Le dossier conserve la référence de pièce et la question à reprendre lorsque la source sera admissible. Le propriétaire du processus choisit délai de revue, seuil d’escalade et responsable. Notre banc ne crée pas cette file de travail ; sa sortie fournit les états que ce parcours doit prendre en charge.

Séparer protection des appels et décision de réponse

Le pattern Circuit Breaker décrit par Microsoft limite les tentatives vers une dépendance qui échoue et organise la vérification de son rétablissement. Il protège le parcours technique, mais ne décide pas à lui seul si une quantité historique peut être montrée ou si une opération doit attendre. Ces règles doivent être présentes dans le service métier.

Un circuit ouvert peut faire échouer rapidement l’accès à la source, sans rendre le cache plus exact. Le budget d’appels doit inclure recherches, essais de retour et éventuels services de repli. Le laboratoire ne mesure ni délais, ni charge, ni retries ; il reçoit des états fixés à la main. La recette réelle doit vérifier que la dégradation ne déplace pas la saturation vers une autre dépendance ou le support.

Vingt-deux scénarios et leur décision observée

Comparer les décisions à contexte contrôlé

Les cas changent une condition à la fois autour d’un contexte nominal, avec une horloge fixe et des objets copiés. Les sorties portent verdict, quantité, sens de cette quantité, provenance, limites, préparation et effets externes. Cette comparaison permet de retrouver pourquoi une capacité reste ouverte ou se ferme. Elle ne fournit pas un taux de disponibilité, car les situations ne constituent pas un échantillon de production.

Toutes les sorties ont zéro effet externe. Les trois préparations favorables sont D37-15, D37-16 et D37-21. Le mot vide dans le tableau signifie que quantity vaut null, jamais une quantité égale à zéro. L’absence confirmée de D37-09 appartient au contrat fictif not_found_authoritative ; elle ne provient pas d’un essai HTTP 404 ni d’une recherche incomplète.

Conserver les contre-exemples qui éprouvent la frontière

La paire D37-04/D37-05 montre qu’une donnée admissible à l’historique ne soutient pas la préparation. D37-02/D37-03 oppose source facultative et obligatoire. D37-10/D37-21 vérifie la borne d’âge. Ces contrastes appartiennent au problème traité ; une liste de scénarios tous refusés ne suffirait pas à prouver qu’une aide utile reste disponible pendant une panne partielle.

Les données sont entièrement fictives et les réponses du contrôleur sont déterministes. Aucun agent ne choisit ses outils ni ne rédige une synthèse. Le résultat valide cette politique locale sur ces entrées. L’évaluation d’un modèle devra vérifier qu’il respecte les sorties, sans multiplier les appels jusqu’à obtenir une donnée ou transformer un refus en explication inventée.

Vérifier le retour avant de rouvrir les capacités

Exiger une donnée admissible pour la question reprise

Le retour d’une réponse réseau ne prouve pas que tous les objets attendus sont frais, bien rattachés et accessibles. La recette doit revalider la source obligatoire pour la question qui attend, puis reprendre son contexte. Les observations conservées pendant l’incident restent historiques. Un bouton de reprise ne doit pas porter une ancienne quantité simplement parce qu’une sonde générale annonce le service disponible.

Le banc ne simule pas une séquence de rétablissement dans le temps. Il ne teste ni circuit breaker, ni reconnexion, ni cache distribué. Les âges sont calculés depuis une horloge fixe, sans preuve de leur attribution par un serveur réel. Une intégration doit observer la transition avec ses interfaces et vérifier la sortie donnée aux dossiers ouverts, y compris pendant un retour partiel.

Éviter une réouverture qui relance toutes les décisions passées

Une file différée peut contenir des demandes devenues inutiles, des sources modifiées et des droits retirés. La réouverture doit définir lesquelles restent pertinentes et qui peut les reprendre. L’instrumentation conserve motif de report, dépendance et dernière observation. Le repli manuel peut avoir déjà réglé un dossier ; le service doit rapprocher ce fait avant de préparer une opération que personne n’attend plus.

La recette de retour doit aussi mesurer les effets de charge de cette file sur le fournisseur et les équipes. Une API en voie de rétablissement peut redevenir indisponible sous un afflux de demandes. Ce problème technique ne change pas la politique d’accès ou de données. Le responsable choisit cadence de reprise et capacité ouverte, en gardant les preuves requises pour chaque effet.

Erreurs fréquentes dans une réponse en mode dégradé

Remplir les blancs pour préserver la conversation

Un champ absent peut devenir zéro, un timeout peut devenir aucun dossier trouvé, et un commentaire ancien peut devenir une disponibilité actuelle. Ces transformations donnent une réponse complète en apparence tout en changeant ses preuves. Le service doit garder les valeurs manquantes et les motifs structurés. Un prompt demandant de rester utile ne doit pas autoriser le modèle à compléter une information qui engage une décision métier.

Un signal faible apparaît lorsque la qualité perçue reste stable pendant une panne, mais que les utilisateurs découvrent davantage d’écarts avec le SI. Le produit peut avoir masqué le changement de source ou supprimé les limites de sortie. Il faut retrouver provenance et âge des affirmations, puis tester leur restitution. La disponibilité de l’écran et la validité des réponses se mesurent séparément.

Confondre dégradation technique et assouplissement des permissions

Un refus d’accès n’appelle pas le même repli qu’une panne. Le service ne doit pas basculer vers un compte d’administration, un export partagé ou une copie devenue inaccessible pour maintenir une réponse. La capacité de lecture reste décidée par les permissions courantes. L’abstention ou le report conserve le travail autorisé ; contourner une frontière change le périmètre du service.

Un autre signal est une augmentation des reprises manuelles sans propriétaire de la source manquante. Le mode dégradé peut déplacer silencieusement le coût vers le support. Une réponse limitée doit laisser un état de dossier attribué et une condition de résolution. Le nombre de conversations terminées ne suffit pas à mesurer si la décision attendue par le métier est encore possible.

Plan d’action pour définir un repli utile

Le contrat de mode dégradé précise les entrées admissibles, les sorties limitées et les effets fermés. La responsabilité du report est nommée avant l’ouverture. La journalisation relie question, source, observation et motif, avec les accès prévus pour la supervision. Le seuil de fraîcheur appartient à l’opération ; l’équipe conserve sa justification et ses cas limites plutôt que de réutiliser un nombre unique pour tous les logiciels.

1. Décomposer les questions et leurs conséquences. Séparez procédure, état courant et préparation d’action. Identifiez la source qui soutient chaque affirmation, puis classez les dépendances obligatoires ou facultatives pour cette opération. Vérifiez le raccordement, le périmètre des données et les droits avec les propriétaires du SI.
2. Définir les états de source interprétables. Distinguez panne, refus, absence confirmée, champ manquant, âge excessif et rattachement invalide. Appuyez les conversions sur le contrat de l’interface. Conservez une valeur absente sans la convertir en zéro ni faire d’une erreur de transport un fait métier.
3. Préparer les capacités de repli et leurs limites. Choisissez la procédure consultable, l’historique éventuellement présentable et les opérations fermées. Vérifiez lecteurs, provenance et durée de validité des copies. La sortie doit indiquer ce qui est observé et ce qui reste inconnu, avec un parcours manuel utile.
4. Éprouver des pannes croisées et des accès nominaux. Retirez chaque dépendance, puis testez copie obsolète, permission retirée, mauvaise société et borne temporelle. Gardez des cas favorables. Comparez réponse structurée et verbalisation réelle, en vérifiant que le modèle n’élargit ni ses affirmations ni ses outils.
5. Organiser report et retour du service. Attribuez les dossiers, fixez délais d’escalade et budget de reprise. Vérifiez source et autorisation au retour, avec les effets déjà traités manuellement. Ouvrez progressivement les capacités dont les preuves sont retrouvées et mesurez le travail effectivement terminé par les équipes.

Le rollback d’une nouvelle politique doit restaurer les règles connues sans transformer les copies anciennes en références courantes. La traçabilité conserve les demandes qui ont reçu une réponse limitée et les capacités restées fermées. Le responsable peut alors réexaminer leur sortie ou leur report. Un changement de prompt seul ne corrige pas une mauvaise interprétation de source dans le connecteur.

Guides pour contexte SI, fraîcheur et frontières d’outil

Choisir l’autorité avant le raccordement

Le contexte d’un agent connecté à l’ERP et au CRM définit rattachement, lectures et actions contrôlées. Le mode dégradé applique cette matrice lorsque des sources manquent. Il ne crée pas une nouvelle autorité en faveur du logiciel qui répond encore le plus vite.

Le traitement du contexte ERP périmé avant une action distingue préparation et état vérifié au moment d’écrire. Une API disponible peut fournir une observation insuffisante ; une API absente peut laisser un historique utile à la lecture. Le contrat garde ces deux dimensions séparées pour décider le prochain geste.

Conserver les restrictions au niveau de l’interface

La frontière d’autorisation entre MCP et API précise que l’exposition d’un outil ne donne pas un droit métier. Le repli doit conserver cette frontière lorsque l’assistant cherche une autre capacité. Un canal alternatif ne rend pas admissible une lecture ou une préparation refusée dans le parcours initial.

Les traces de décision doivent permettre de retrouver source indisponible et capacité suspendue sans exposer tous les contenus. La revue peut ainsi corriger un raccordement ou une politique d’âge avec son propriétaire. La personne qui utilise le service reçoit les limites nécessaires à sa tâche, sans devoir interpréter une pile d’erreurs techniques ou reconstruire les permissions des logiciels connectés.

Conclusion : maintenir un service sans élargir ses affirmations

Une source indisponible ferme certaines preuves, pas nécessairement toutes les capacités. Le service peut conserver une procédure générale ou une observation historique lorsqu’elles restent admissibles. Il doit distinguer cette aide d’une confirmation actuelle et d’une préparation d’action. Les droits, le rattachement et le sens des données ne deviennent pas facultatifs pour préserver la conversation.

Les vingt-deux cas locaux rendent ces décisions explicites. La copie historique reste datée, le CRM absent limite la réponse ERP et les sources obligatoires manquantes ferment la préparation. Les bornes d’âge sont fictives et les identités injectées. Aucun LLM, transport HTTP, système fournisseur ou effet distant n’est exécuté ; leurs recettes doivent compléter la preuve du contrôleur.

L’intégration IA dans votre SI doit choisir les modes de réponse avec les propriétaires des sources et des opérations. Le report garde son responsable et ses conditions de retour. Le système peut ainsi maintenir une capacité utile sans promettre un état qu’il n’a pas observé ni autoriser une action dont le contexte manque.

Pour maintenir une assistance pendant une panne partielle, notre expertise IA sur mesure peut séparer les consultations encore utiles des préparations qui exigent un état actuel. La recette doit provoquer indisponibilité, accès interdit et retour de l’API, avec des données anciennes clairement identifiées. Le rétablissement ne relance la préparation qu’après vérification de la source et des conditions métier ; une ancienne disponibilité de stock ne suffit pas à réserver.