Un plan de continuité adapté aux pannes d'IA dans le recrutement permet de conserver les candidatures, les décisions, les entretiens et les échanges pris en charge par l'équipe dans votre ATS, même si les enrichissements dépendant des modèles échouent. Enregistrez d'abord la transaction de recrutement, placez le travail de l'IA dans une file avec la version des données sources, limitez les tentatives automatiques, prévoyez une voie manuelle et faites le tri dans les tâches devenues obsolètes avant la reprise.

L'IA ne se résume plus à un assistant de rédaction ouvert dans un autre onglet. Un modèle peut analyser un CV, résumer un entretien, suggérer une réponse, rechercher des informations dans les dossiers ou appeler des outils qui modifient le pipeline de recrutement. Si l'enregistrement du dossier dépend de la réponse du modèle, l'incident du fournisseur perturbe aussi votre propre service.

Impossible de garantir une automatisation ininterrompue. En revanche, le processus de recrutement peut rester compréhensible et utilisable lorsqu'elle s'arrête.

## Qu'a vraiment démontré le chevauchement des pannes d'IA pendant 93 minutes ?

Le 3 septembre 2026, les incidents confirmés chez Anthropic, xAI et OpenAI se sont chevauchés pendant **93 minutes**, de 14 h 43 à 16 h 16 UTC. Ils n'ont pas commencé en même temps et aucune preuve publique n'établit une cause commune.

Anthropic a déclaré son incident principal à 13 h 26 UTC après une hausse du taux d'erreur sur plusieurs modèles Claude. Son [rapport d'incident](https://status.claude.com/incidents/461yvfrzpwtt) indique que Claude.ai, l'API Claude, Claude Code et Claude Cowork figuraient parmi les services concernés. Anthropic a déclaré avoir identifié une cause, sans la décrire publiquement autrement que comme un problème d'infrastructure. Les perturbations ont pris fin à 16 h 16 UTC, soit deux heures et 50 minutes après la première alerte. Un incident distinct touchant Sonnet 5 s'était terminé à 12 h 56 UTC : on ne peut donc pas regrouper les deux événements en une seule panne continue.

La perturbation de xAI a commencé à 13 h 30 UTC. Son [rapport d'état de l'API US East](https://status.x.ai/api-us-east-1/INC410324ed) fait état d'un rétablissement à 17 h 07 UTC. Les services web et mobiles, l'intégration à X et d'autres périmètres de l'API ont connu des plages comparables. SpaceXAI a ensuite évoqué une panne dans son centre de calcul de Memphis, sans préciser si elle relevait de l'alimentation électrique, du réseau, du matériel ou du logiciel.

OpenAI a signalé le début des perturbations à 14 h 43 UTC. Sa [page d'incident](https://status.openai.com/incidents/2rm6gqeh) cite des composants de ChatGPT et de Codex, pas l'API OpenAI. Un porte-parole a attribué les difficultés rencontrées par certains utilisateurs à une erreur de routage. Une solution a été mise en place à 15 h 17 UTC, mais la surveillance s'est poursuivie jusqu'à la clôture de l'incident à 16 h 55 UTC. Parler d'une panne de 34 minutes reviendrait à confondre le temps nécessaire pour atténuer l'incident avec son rétablissement définitif.

Ce chevauchement met à mal une idée reçue : choisir un fournisseur d'IA réputé ne supprime pas le risque opérationnel. Mais la proximité temporelle ne permet pas d'affirmer que les fournisseurs dépendaient du même service cloud, du même réseau ou du même centre de données, ni qu'ils avaient subi la même attaque ou le même pic de trafic. Les [informations publiées au moment des faits](https://www.wired.com/story/nobody-is-saying-why-openai-and-anthropic-had-outages-today/) ne mentionnent aucune déclaration d'un fournisseur établissant un tel lien. Sans rapport d'incident détaillé qui la confirme, toute explication par une cause commune reste spéculative.

Pour une équipe de recrutement, l'enjeu pratique n'est pas de savoir pourquoi trois pages d'état étaient au rouge, mais ce que les candidats et les recruteurs pouvaient encore faire pendant ce temps.

## Quels flux de recrutement doivent résister à une panne d'IA ?

Les actions qui font foi dans votre processus de recrutement doivent fonctionner sans modèle. La panne d'un fournisseur peut retarder un enrichissement, mais elle ne doit ni effacer une candidature, ni masquer une décision, ni empêcher un candidat de joindre quelqu'un.

Commencez par séparer les **transactions** de l'**assistance**. Les premières modifient durablement le processus de recrutement. La seconde se contente d'en déduire des informations ou de proposer la suite.

| Doit continuer | Peut passer en mode dégradé |
|---|---|
| Accepter et horodater une candidature | Extraire les champs structurés d'un CV |
| Conserver le consentement du candidat et les pièces jointes | Résumer un CV ou un entretien |
| Afficher l'étape actuelle du pipeline | Effectuer une recherche sémantique ou un classement |
| Consigner une décision humaine et son auteur | Suggérer des critères d'évaluation |
| Permettre aux recruteurs de changer manuellement l'étape d'un candidat | Rédiger un message destiné à un candidat |
| Conserver les messages écrits par une personne | Personnaliser automatiquement un message de prospection |
| Afficher les tâches en attente, en échec ou annulées | Recommander la prochaine action du flux de travail |

La limite porte sur le pouvoir décisionnel, pas sur l'importance perçue de la fonctionnalité. Un recruteur peut dépendre largement d'un résumé généré, mais les notes d'entretien d'origine doivent rester disponibles. Un assistant de rédaction peut faire gagner des heures, mais le recruteur doit pouvoir écrire lui-même un message. Un modèle de recherche peut faire remonter des correspondances pertinentes, mais une personne autorisée doit disposer d'un autre moyen d'ouvrir le dossier d'un candidat.

Le [manuel pratique de l'AI Risk Management Framework](https://airc.nist.gov/airmf-resources/playbook/) du NIST recommande de prévoir des solutions viables sans IA, des rôles humains, des mécanismes de reprise en main et des procédures de continuité en cas de défaillance d'un fournisseur. Dans le recrutement, le mode dégradé ne peut donc pas se résumer à un indicateur de chargement qui tourne sans fin. L'interface doit préciser ce qui a échoué, confirmer ce qui a été enregistré et proposer la marche à suivre sans risque.

Les candidats subissent eux aussi ce type de panne. Si la candidature a bien été reçue mais que son analyse tarde, dites au candidat que son dossier est enregistré. Ne lui demandez pas de le renvoyer parce qu'un appel d'enrichissement a dépassé son délai. Le principe est le même que pour un [portail candidat accessible](/blog/keyboard-accessible-candidate-portal-checklist) : le parcours essentiel doit rester praticable quand une couche facultative ne l'est plus.

Définissez cette limite avant l'incident. Pour chaque fonction qui dépend d'un modèle, posez deux questions : **quel dossier reste disponible si cet appel ne reçoit jamais de réponse ? Que peut ensuite faire une personne ?** Si aucune réponse n'est claire, le modèle détient probablement trop de pouvoir sur la transaction.

## Comment séparer la transaction de recrutement de l'enrichissement par l'IA ?

Enregistrez d'abord le dossier principal dans votre système, puis demandez l'enrichissement par l'IA comme une tâche distincte et observable. Une action destinée au candidat ne doit pas attendre la réponse d'un modèle, sauf si la fonctionnalité est explicitement facultative et permet clairement de continuer sans elle.

En pratique, le cheminement est le suivant :

`candidate or recruiter action → ATS transaction → durable AI task → bounded worker → provider → versioned result → human review`

Prenons l'envoi d'une candidature. Enregistrez le candidat, la candidature, le consentement, la référence de la pièce jointe et l'étape initiale dans une même transaction de base de données. L'extraction ou le résumé du CV ne doit être placé dans la file qu'après validation de cette transaction. Si le fournisseur est indisponible, la candidature continue d'exister. Le recruteur voit « résumé en attente » au lieu d'un dossier vide, et le candidat reçoit une confirmation fondée sur la candidature enregistrée, pas sur le résultat de l'enrichissement.

Une file d'attente persistante absorbe le travail pendant l'indisponibilité d'une dépendance, mais elle ne constitue pas à elle seule une stratégie de résilience. Les [recommandations de Microsoft sur la mise en file d'attente pour lisser la charge](https://learn.microsoft.com/en-us/azure/architecture/patterns/queue-based-load-leveling) soulignent la nécessité de surveiller la profondeur de la file, de limiter le débit du traitement, de rendre les consommateurs idempotents, de gérer une file de rebut et de définir l'ordre des tâches. Sans ces protections, la reprise peut transformer une panne du fournisseur en déferlement de tâches en attente.

Chaque tâche doit porter une **version immuable des données sources**. Cette version peut correspondre au CV, aux notes d'entretien, aux critères du poste ou au modèle de message. Avant d'enregistrer un résultat, le processus doit la comparer à l'état actuel. Si le candidat a remplacé son CV ou si sa candidature a progressé, l'ancienne tâche n'est plus simplement en retard : elle est obsolète.

Il est souvent plus sûr de remplacer une tâche obsolète que de la relancer. Conservez l'ancienne tâche à des fins d'audit, indiquez pourquoi elle a été ignorée et ne placez dans la file une tâche fondée sur la version actuelle que si le résultat reste utile. Les recruteurs ne risquent ainsi pas de lire un résumé bien tourné de données qui ne régissent plus la candidature.

L'interface doit être tout aussi précise. Utilisez des états distincts comme en attente, en cours, nouvelle tentative, en échec, remplacé, annulé et terminé. « IA indisponible » est plus utile qu'un chargement sans fin. « Candidature enregistrée ; résumé du CV retardé » est encore plus précis, car le message identifie à la fois la transaction réussie et l'enrichissement en échec.

## Comment sécuriser les nouvelles tentatives avant d'ajouter un fournisseur de secours ?

Une nouvelle tentative n'est sûre que si la répétition de la requête ne peut pas produire deux fois le même effet métier. Réglez ce point avant d'ajouter un autre fournisseur de modèles, car ce secours ouvre une voie supplémentaire par laquelle des actions dupliquées ou obsolètes peuvent être exécutées.

Les tâches d'IA se répartissent en deux catégories de risque. Générer deux fois un résumé interne gaspille de l'argent et peut produire des résultats contradictoires. Répéter une action qui touche le candidat ou modifie un état peut causer un préjudice direct : deux e-mails de refus, deux réservations d'entretien, deux changements d'étape ou une offre envoyée après le retrait de la candidature.

Attribuez à chaque opération une clé d'idempotence au niveau métier. Un format possible serait :

`account + application + capability + source_version + workflow_step`

Enregistrez cette clé avec la tâche, ainsi qu'avec tout résultat ou effet de bord produit. Avant tout envoi, réservation, refus ou changement d'étape, vérifiez à la fois la clé et l'état local actuel. Les recommandations d'AWS pour [sécuriser les nouvelles tentatives grâce à des API idempotentes](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/) expliquent pourquoi un identifiant fourni par l'appelant est plus fiable que de déduire, à partir de deux requêtes semblables, qu'elles expriment la même intention.

Confiez les nouvelles tentatives à une seule couche. Un SDK peut déjà relancer les appels. Le processus d'arrière-plan peut en faire autant. Un moteur de flux de travail peut ajouter une autre boucle. Si chaque couche effectue trois essais, une défaillance peut déclencher bien plus d'appels que votre règle ne semble l'autoriser. Utilisez des erreurs transitoires typées, un délai exponentiel assorti d'un aléa, une limite et une échéance. Une erreur d'authentification, une entrée incorrecte ou le rejet d'une requête pour des raisons de sécurité ne justifient pas de recommencer sans cesse.

Le basculement vers un autre fournisseur n'est pas le premier mécanisme de protection à ajouter. Deux modèles portant des noms différents peuvent tout de même dépendre des mêmes services d'identité, du même réseau, des mêmes capacités régionales ou d'un autre composant commun du plan de contrôle. Le [rapport d'incident d'OpenAI de juillet 2026](https://status.openai.com/incidents/01KXXDNEAKEPRGFM661SBJJAM6/write-up) décrit un problème régional de capacité du service d'identité, dans lequel le basculement automatique n'a redirigé qu'une part insuffisante du trafic. L'indépendance n'est réelle que si elle concerne le chemin effectivement touché.

Si vous ajoutez un fournisseur de secours, définissez les actions qu'il peut effectuer. Un second fournisseur peut convenir à un résumé interne à faible risque. Il peut être inadapté à un CV sensible si les contrats, le lieu ou la durée de conservation des données, ou encore le comportement du modèle diffèrent. Les résultats peuvent aussi varier au point d'invalider les hypothèses des traitements en aval. Consignez le fournisseur et le modèle dans le journal d'audit, validez le résultat de secours et préservez la voie sans IA.

## Comment tester un mode dégradé en cinq étapes ?

Une bonne procédure de secours doit être assez courte pour être suivie sous pression et assez explicite pour éviter toute improvisation. Testez ces cinq étapes en coupant la connexion au modèle, pas à partir d'une simple présentation.

### 1. Déclarer le mode dégradé et protéger le parcours principal

Vérifiez que le symptôme vient bien du fournisseur, puis désactivez ou contournez les appels synchrones non essentiels. Maintenez la réception des candidatures, l'accès aux dossiers, les changements manuels d'étape, l'administration des entretiens et les communications rédigées par votre équipe. Affichez un message d'état clair à l'endroit où les recruteurs le verront. Consignez le début de l'incident et le nom de la personne qui coordonne le rétablissement.

### 2. Contenir les nouvelles tentatives et préserver l'intention

Faites passer le coupe-circuit de la fonction concernée à l'état ouvert ou suspendez ses consommateurs. Ne supprimez pas les tâches de la file. Arrêtez les tentatives en cascade avant qu'elles n'amplifient la charge ou n'épuisent les limites de débit. Conservez la clé d'idempotence, la version des données sources, l'échéance, l'identifiant de requête du fournisseur et la dernière erreur typée de chaque tâche.

Le guide SRE de Google sur les [défaillances en cascade](https://sre.google/sre-book/addressing-cascading-failures/) recommande de renvoyer des résultats dégradés, d'imposer des échéances, de délester les traitements non essentiels et de gérer prudemment les nouvelles tentatives. Le trafic qu'elles produisent peut prolonger une surcharge. Réduisez la pression sans perdre l'intention associée à l'action de recrutement.

### 3. Orienter les personnes vers une voie manuelle

Donnez aux recruteurs des instructions propres à chaque fonction. Ouvrez le CV enregistré au lieu d'attendre son résumé. Utilisez une recherche par mots-clés ou en base de données plutôt que des représentations vectorielles. Écrivez directement au candidat. Consignez la décision d'étape dans l'ATS au lieu de demander à un agent de s'en charger. Attribuez un responsable aux candidatures et entretiens urgents pour éviter que « IA en attente » ne devienne « candidat oublié ».

Si votre équipe utilise un assistant pour piloter des outils de recrutement, revoyez les limites d'autorisation et de validation présentées dans [le déploiement d'agents de recrutement IA avec MCP](/blog/deploying-ai-recruiting-agents-mcp). Le contrat de l'outil peut rester disponible alors que le modèle qui le pilote ne l'est plus.

### 4. Sonder la reprise avec un budget limité

Ne libérez pas toutes les tâches accumulées dès qu'une page d'état repasse au vert. Envoyez un petit ensemble de tâches actuelles et à faible risque dans un circuit semi-ouvert. Surveillez la latence, le taux d'erreur, les réponses signalant une limitation du débit, l'ancienneté des tâches dans la file et la validation des résultats. Relancez progressivement les consommateurs et réservez de la capacité aux nouvelles candidatures.

### 5. Vérifier avant de relancer

La reprise consiste à comparer les données, pas à vider la file. Pour chaque tâche en attente ou en échec, vérifiez si la version de ses données sources est encore actuelle, si son échéance reste pertinente, si un résultat équivalent existe déjà ou si une personne a effectué l'action manuellement. Passez en revue les effets externes, comme les e-mails et les réservations dans les calendriers, avant toute nouvelle tentative.

Donnez la priorité aux échanges en cours avec les candidats et aux postes ouverts. Marquez le travail obsolète comme remplacé. Annulez les tâches qui n'ont plus d'utilité opérationnelle. Ne relancez que les tâches actuelles dotées de clés d'idempotence valides, puis comparez les données attendues et celles réellement enregistrées. Conservez dans la chronologie de l'incident le nombre de tâches terminées, ignorées, annulées et résolues manuellement.

Répétez cet exercice chaque trimestre et après toute modification importante du flux de travail. Mesurez si une candidature peut toujours être envoyée, si un recruteur peut repérer un enrichissement en échec et si la reprise ne produit aucune action en double auprès des candidats. Ces résultats comptent davantage qu'un pourcentage nominal de disponibilité.

## Qu'est-ce qui continue de fonctionner dans Kit, et où l'IA reste-t-elle nécessaire ?

Kit sépare les principaux dossiers de recrutement et de nombreux flux manuels des enrichissements par l'IA, mais ne promet ni un système de recrutement capable de fonctionner hors ligne ni un basculement entre fournisseurs fondé sur leur état opérationnel. La promesse réaliste de continuité est plus étroite : le dossier de recrutement reste disponible lorsque l'assistance qui dépend des modèles échoue de manière visible.

La réception publique des candidatures enregistre le candidat, la candidature, le consentement, le dépôt et l'étape initiale dans une transaction de base de données. Ce n'est qu'après la validation de cette transaction que l'extraction du CV commence. Si l'extraction échoue, la candidature ne disparaît pas avec elle. Les changements manuels d'étape conservent l'état de référence du pipeline, qu'ils proviennent de l'interface web ou d'un outil MCP. La décision du modèle d'appeler cet outil constitue une dépendance distincte.

Les recruteurs peuvent créer des invitations à un entretien, les candidats peuvent confirmer des rendez-vous pris directement dans Kit et les équipes peuvent conserver les messages écrits par des personnes ainsi que les modèles Liquid sans appel à un modèle. Ces parcours dépendent toujours de systèmes comme la disponibilité des calendriers, la création des réunions Google Meet ou Calendly, les tâches d'arrière-plan et l'envoi par SMTP. Les qualifier de totalement hors ligne serait faux.

Kit dispose aussi de mécanismes de repli limités à certains cas. Lorsque le fournisseur ou le transport échoue, la rédaction de réponses par l'IA peut préremplir l'éditeur avec un texte déterministe. Certaines recherches sémantiques basculent des représentations vectorielles de Gemini vers la recherche textuelle de PostgreSQL. Les outils de résumé des candidatures et des candidats sérialisent les dossiers stockés au lieu de générer eux-mêmes du texte. Un modèle connecté peut interpréter ces dossiers, mais il n'en est pas la source d'autorité. Notre présentation de [MCP pour le recrutement](/blog/mcp-for-hiring) explique cette séparation entre le modèle et les outils de recrutement qu'il peut demander à utiliser.

Les lacunes sont tout aussi importantes. Kit ne surveille pas l'état des fournisseurs pour basculer automatiquement entre Gemini, Anthropic et OpenRouter. Le repli vers un modèle de gamme inférieure s'effectue uniquement au sein du fournisseur configuré. Les erreurs générales du chat apparaissent comme telles au lieu d'entrer dans un système universel de relance. L'échec de l'extraction des CV et des champs personnalisés peut nécessiter une intervention manuelle, et les représentations vectorielles restent liées à Gemini même si les conversations utilisent un autre fournisseur. Kit ne relance pas chaque enrichissement en échec et ne supprime pas les dépendances aux calendriers, à SMTP ou aux modèles.

Voilà le critère à appliquer à tout ATS nativement IA : **quand la page d'état du modèle passe au rouge, le dossier de recrutement ne doit pas en faire autant.** Gardez les candidatures et les décisions comme données de référence, veillez à ce que le travail de l'IA reste dérivé et récupérable, et rendez la voie manuelle évidente avant d'en avoir besoin.

> [!CTA]
> **Vous voulez vérifier cette limite en pratique ?** Essayez Kit avec un vrai flux de recrutement, puis testez ce que votre équipe peut encore faire lorsque les fonctions d'IA sont indisponibles.
>
> [Démarrez votre essai gratuit](/users/sign_up)