Demandez à un ingénieur de combien de services externes dépend son système et vous obtiendrez généralement un chiffre. Demandez-lui de tous les énumérer, et le chiffre grandit au fil de la conversation.
Un système d’entreprise moderne n’est pas un seul logiciel. C’est un prestataire de paiement, une API d’envoi d’e-mails, un service de validation d’adresses, un connecteur ERP, un fournisseur d’identité, un CDN, une région cloud, un résolveur DNS et une poignée d’API plus petites que quelqu’un a intégrées il y a des années pour un besoin précis. Chacune fonctionne presque tout le temps. Aucune ne vous appartient.
Voilà la réalité pour laquelle il faut concevoir, et la plupart des processus ne sont pas conçus pour elle du tout.
Le processus que tout le monde conçoit
Parcourez la spécification d’un processus type de commande, de sinistre ou d’inscription et vous trouverez une séquence impeccable : le client soumet, l’adresse est validée, le paiement est autorisé, l’enregistrement est créé dans l’ERP, l’e-mail de confirmation part, le document est archivé.
Chaque étape suppose que la précédente a réussi. Chaque appel externe suppose que le prestataire répond. La conception décrit ce qui se passe quand tout fonctionne, parce que c’est la version sur laquelle tout le monde peut s’accorder, et parce que l’alternative soulève des questions inconfortables sur les responsabilités quand ce n’est pas le cas.
L’hypothèse implicite est que ces prestataires font de fait partie de votre système : toujours disponibles, toujours identiques, jamais en erreur. Ils ne le sont pas. Ce sont des entreprises indépendantes avec leurs propres déploiements, leurs propres incidents et leurs propres mauvais mardis.
Ce qui se passe réellement
Les chiffres ne sont pas ambigus. Entre août 2024 et août 2025, AWS, Azure et Google Cloud ont cumulé plus de cent pannes de service. Environ 94 % des services d’entreprise dans le monde reposent sur au moins un grand fournisseur cloud, et les trois plus grands contrôlent à peu près 62 % du marché. La concentration est efficace, jusqu’à ce qu’elle ne le soit plus.
Les incidents pris un à un sont instructifs, car aucun n’était exotique :
- En octobre 2025, une défaillance de résolution DNS dans une seule région AWS a mis des services hors ligne pendant des heures, touchant plus de 3 500 entreprises dans 60 pays. Le déclencheur : un enregistrement DNS vide et une mise à jour d’automatisation.
- En novembre 2025, un fichier plus volumineux que prévu injecté dans le système Bot Management de Cloudflare s’est propagé mondialement en quelques minutes, dégradant le service pour une large part des 2,4 milliards d’utilisateurs dont le trafic passe par ce réseau. Coût estimé : plus de 250 millions de dollars.
- En juillet 2024, la mise à jour défectueuse d’un agent de sécurité a fait planter des hôtes Windows dans le monde entier. Ce n’était pas du tout une panne cloud, et les analystes ont chiffré les dégâts pour les seules entreprises du Fortune 500 à 5,4 milliards de dollars.
- En mai 2026, des signatures DNSSEC invalides publiées pour la zone .de ont rendu des domaines irrésolubles sur tout l’internet, y compris des domaines de second niveau qui n’utilisaient pas DNSSEC eux-mêmes.
Ce dernier mérite une seconde lecture. Des entreprises se sont retrouvées hors ligne à cause d’une dépendance qu’elles n’avaient jamais configurée, jamais choisie et probablement jamais recensée. Voilà la forme du problème : les dépendances qui font mal sont rarement celles que vous surveillez.
Un dernier détail mérite d’être connu. L’analyse d’incidents majeurs récents a montré qu’environ un quart du temps total d’impact client s’écoulait avant que le prestataire lui-même sache ce qui était cassé. Attendre que la page de statut vous dise ce qui se passe n’est pas une stratégie de reprise.
Quand le processus s’arrête, autre chose s’arrête aussi
C’est ici que le sujet devient une conversation métier plutôt que technique.
Si un appel externe échoue et que le processus s’arrête, la conséquence dépend entièrement de ce que fait ce processus. Une page marketing lente est un désagrément. Une chaîne de commandes incapable d’accepter des commandes, c’est du chiffre d’affaires perdu, et il ne revient pas plus tard. Un système logistique incapable de produire des étiquettes d’expédition immobilise des camions. Une facturation qui n’aboutit pas le dernier jour du mois devient un problème de trésorerie et de rapprochement. En contexte réglementé, un processus arrêté peut devenir une obligation de notification.
La question importante n’est pas « quelle est la fiabilité de ce prestataire ». Elle est : si ce prestataire est indisponible quatre heures, qu’est-ce qui s’arrête, et combien cela nous coûte-t-il ?
La plupart des entreprises ne se la sont jamais posée dépendance par dépendance. Elles ont le sentiment général qu’une panne serait fâcheuse, ce qui n’est pas assez précis pour concevoir en conséquence.
À quoi ressemble vraiment une conception résiliente
La résilience ne consiste pas à atteindre une disponibilité parfaite, que vous ne pouvez acheter à aucun prix quand la panne est en amont. Elle consiste à faire en sorte qu’une défaillance fournisseur dégrade votre processus au lieu de l’arrêter.
Quelques motifs font l’essentiel du travail.
Connaître la carte complète des dépendances
On ne conçoit pas autour de ce qu’on n’a pas recensé. Cela signifie chaque appel externe, y compris ceux enfouis dans une bibliothèque, hérités d’un module fournisseur ou ajoutés il y a des années par quelqu’un qui est parti depuis. Cela signifie aussi les dépendances sous vos dépendances : la région, le DNS, le CDN, le fournisseur d’identité.
Cette cartographie est la première étape peu spectaculaire, et c’est là que surgissent la plupart des surprises.
Décider, pour chaque dépendance, ce que doit produire une panne
Toutes les dépendances ne méritent pas le même traitement. Pour chacune, il n’y a que quelques réponses sensées :
- Faire échouer la transaction, quand poursuivre sans elle serait incorrect. Une autorisation de paiement ne se présume pas.
- Dégrader proprement, quand l’étape enrichit sans être essentielle. Si la validation d’adresse est indisponible, acceptez l’adresse et signalez-la pour contrôle plutôt que de bloquer la commande.
- Mettre en file et réessayer, quand l’étape peut se produire plus tard sans dommage. Les e-mails de confirmation et les synchronisations n’ont que rarement besoin d’être synchrones, et les traiter comme tels transforme un hoquet du prestataire en échec visible par le client.
- Basculer vers une alternative, quand la fonction est réellement critique et qu’un second prestataire existe. C’est l’option la plus coûteuse, donc un choix délibéré pour un petit nombre de dépendances plutôt qu’une ambition pour toutes.
Le point essentiel est que chacune de ces options est une décision métier exprimée en code. Quelqu’un doit décider si une commande doit être acceptée lorsqu’un contrôle non essentiel est indisponible. L’ingénierie peut implémenter l’une ou l’autre réponse, mais ne devrait pas être celle qui devine.
Contenir la panne
Les délais d’expiration, les disjoncteurs et les cloisonnements existent pour qu’un prestataire lent ne devienne pas un système arrêté. Sans délai d’expiration, un appel externe suspendu retient une connexion, puis un thread, puis le pool, et une seule intégration dégradée fait tomber une application qui avait bien d’autres choses à faire. Une part surprenante des pannes complètes commence par une dépendance lente.
Faire de la file d’attente la règle pour tout ce qui peut être asynchrone
Si une étape n’a pas besoin de s’achever avant que l’utilisateur obtienne une réponse, elle n’a rien à faire dans le chemin critique. La placer derrière une file durable signifie qu’une panne retarde le travail au lieu de le perdre, et le processus se rattrape tout seul au retour du prestataire.
Répéter l’exercice
Un chemin de secours jamais exécuté est une hypothèse. Le test utile le moins cher consiste à désactiver une dépendance dans un environnement de recette et à observer ce que fait le processus. Les réponses sont souvent inconfortables, et c’est précisément pourquoi l’exercice vaut la peine avant que le prestataire ne choisisse la date à votre place.
C’est une question de conception, pas d’achats
Il est tentant de vouloir régler le risque fournisseur dans les contrats. Les SLA et les avoirs comptent, mais ils vous indemnisent après coup. Ils ne maintiennent pas les commandes en mouvement le matin où un enregistrement DNS tourne mal quelque part hors de votre contrôle.
Ce qui maintient le processus en marche, c’est une conception qui a anticipé la panne. Et cette conception n’est possible que si quelqu’un comprend le processus de bout en bout : pas seulement le code, mais à quoi sert chaque étape, celles sans lesquelles l’activité ne peut réellement pas avancer, et à quoi ressemble un mode dégradé acceptable.
Cette vue d’ensemble est ce que nous produisons dans un technology assessment, et ce que nous entretenons dans la durée lorsque nous reprenons un système. C’est aussi pourquoi nous répétons que la documentation n’est pas une coquetterie administrative : on ne peut pas concevoir de la résilience dans un processus que personne ne sait décrire entièrement.
La disponibilité parfaite n’est pas disponible. Un processus qui survit à ses fournisseurs, si.
Questions fréquentes
Qu’est-ce que la résilience d’un système en contexte d’entreprise ?
La résilience est la capacité d’un processus métier à continuer de fonctionner quand certaines de ses parties défaillent, en particulier celles que vous ne contrôlez pas. Ce n’est pas la même chose que la disponibilité. Une conception résiliente accepte que les prestataires externes tomberont en panne et fait en sorte que le processus se dégrade, mette en file ou réachemine au lieu de s’arrêter.
Pourquoi les pannes de fournisseurs comme AWS ou Cloudflare nous touchent-elles si nous ne sommes pas leurs clients directs ?
Parce que les dépendances sont en couches. Votre prestataire tourne peut-être sur une région cloud, derrière un CDN, avec un résolveur DNS ou un service d’identité que vous n’avez jamais choisi. En mai 2026, des signatures DNSSEC invalides sur la zone .de ont rendu des domaines irrésolubles, même pour des organisations qui n’avaient pas activé DNSSEC. La carte des dépendances est généralement plus profonde que la liste des contrats.
Faut-il un second prestataire pour tout ?
Non, et essayer est généralement un mauvais investissement. La redondance coûte cher en temps de construction et en maintenance continue. L’approche utile consiste à décider dépendance par dépendance : échouer, dégrader, mettre en file et réessayer, ou basculer. La redondance complète ne vaut la peine que pour les rares dépendances où le processus ne peut vraiment pas s’arrêter.
Comment savoir où se situe notre vrai risque ?
Cartographiez chaque dépendance externe, y compris indirecte, puis posez une seule question pour chacune : si elle est indisponible quatre heures, qu’est-ce qui s’arrête et combien cela coûte. Cela transforme une crainte vague des pannes en une liste courte et priorisée de points autour desquels il vaut la peine de concevoir.
Est-ce qu’on règle cela une fois pour toutes ?
Non. Les dépendances changent à mesure que des intégrations sont ajoutées, que les fournisseurs modifient leurs conditions et que des services sont abandonnés. La résilience est une propriété d’un système entretenu, pas un projet qui se termine.
Vous ne savez pas de quoi dépendent réellement vos systèmes, ni ce qui s’arrêterait si un prestataire tombait demain ? Commencez par un technology assessment à périmètre fixe, ou contactez-nous.