Orange/Sosh en panne à Lyon: PCA « IA & automatisation » quand le réseau tombe

Une panne mobile, et vos automatismes sautent avec

Quand Orange/Sosh tombe, on pense d’abord aux appels qui n’aboutissent pas et aux SMS qui n’arrivent plus. À Lyon, ça suffit à paralyser une partie des équipes terrain, des astreintes, des points de vente, et parfois… le plan de secours lui-même.

Le déclencheur récent est clair: Orange a confirmé un incident technique majeur sur son réseau mobile en France le 21 octobre 2026, avec des perturbations sur appels, SMS et data mobile pour une “partie importante” des clients, y compris entreprises. Orange précise que les appels d’urgence ne sont pas impactés et recommande de basculer, quand c’est possible, sur un Wi‑Fi disponible et sécurisé pour conserver la plupart des usages. Source: newsroom.orange.com.

Et côté signal local, des pages de suivi de pannes ont remonté des signalements à Lyon et dans la métropole autour du 23-24 octobre 2026. C’est déclaratif, donc imparfait, mais utile pour sentir où ça chauffe. Source: degrouptest.com.

Le vrai sujet pour les boîtes lyonnaises qui automatisent, c’est que le réseau mobile n’est plus juste “un téléphone”. C’est un maillon critique de vos workflows d’IA & automatisation. Et quand il casse, ça casse en cascade.

Pourquoi une panne Orange à Lyon casse vos workflows IA

1) Le mobile est souvent votre plan B, pas votre plan A

Beaucoup d’entreprises à Lyon ont la fibre au siège. Mais leurs sites secondaires, chantiers, agences, véhicules, équipes nomades, et même certains routeurs sont en “secours 4G/5G”. Problème: si le secours est sur le même opérateur que celui en panne, vous venez de perdre votre redondance.

2) Les agents IA et les SaaS vivent sur des API, donc sur de la connectivité

Un agent IA de support, un bot interne, un copilote commercial: dans la vraie vie, ça parle à un CRM, un helpdesk, une base de connaissances, un outil de tickets, un outil d’identité. Souvent via Internet et des API externes. La panne mobile frappe fort quand:

• des collaborateurs sont en mobilité et n’ont plus de data,
• un site dépend du backup cellulaire,
• l’authentification exige un second facteur reçu… sur ce même réseau mobile.

3) RPA et orchestrateurs: un point de rupture, plusieurs processus bloqués

RPA, iPaaS, orchestrateurs (n8n, Make, etc.): un workflow “simple” peut dépendre de 6 à 10 briques. Si l’annuaire SSO est injoignable, si un webhook ne passe plus, si une file d’événements se remplit sans être consommée, vous ne perdez pas une automatisation. Vous perdez un pan entier (tri des demandes, qualification de leads, création de tickets, relances, extraction de données).

4) Téléphonie cloud et centre de contact: la voix est IP, donc réseau

Beaucoup d’équipes support à Lyon utilisent une téléphonie cloud, un softphone, un centre de contact web. Si la connectivité est dégradée (fixe ou mobile) ou si votre bascule Internet s’appuie sur le cellulaire en panne, vous perdez:

• la prise d’appels,
• l’accès aux consoles superviseurs,
• le couplage téléphonie-CRM,
• la traçabilité et les enregistrements.

5) MFA par SMS: le verrou qui vous empêche de réparer

Le scénario classique: incident réseau, et au même moment, impossible de se connecter aux consoles d’admin, au VPN, au helpdesk, ou au cloud, parce que le MFA dépend du SMS ou de la data mobile. Résultat: vous êtes bloqué dehors, et même votre équipe IT ne peut plus “entrer” pour corriger.

C’est exactement le genre de risque que doit couvrir un plan de continuité IT orienté “identité + communications”.

Mettre le risque à sa juste place: qualité globale bonne, incidents quand même

Oui, globalement, le mobile marche bien. L’Arcep rappelle que sa campagne 2024 s’appuie sur plus d’un million de mesures et conclut à une qualité Voix/SMS et internet mobile “élevée”, avec amélioration des débits, même s’il reste des écarts selon les zones. Source: arcep.fr.

Mais “ça marche bien” ne veut pas dire “ça ne tombe jamais”. Et la dépendance augmente: toujours selon l’Arcep, un client 4G consomme en moyenne 17 Go/mois (T3 2024). Source: arcep.fr.

Autre rappel utile: côté fixe, les pannes existent aussi. L’Arcep observe une amélioration du taux d’abonnés ayant eu au moins une panne (national) de 2,2% à 1,7% entre janvier 2024 et mars 2025. Source: arcep.fr.

Donc, à Lyon comme ailleurs: la bonne approche, c’est d’accepter que l’incident rare mais massif arrive, et de préparer un MFA mode dégradé, une continuité support, et une priorisation des flux.

Le plan concret: PCA « IA & automatisation » quand le réseau tombe

Objectif: éviter le double échec. Le premier, c’est la panne. Le second, c’est l’absence de mode dégradé qui transforme une panne en crise métier.

Étape 1: cartographier vos dépendances réseau (celles que vous oubliez)

Vous n’avez pas besoin d’un audit de 6 mois. Vous avez besoin d’une carte simple, à jour, lisible.

• Identité: SSO, MFA, annuaires, procédures de break-glass.
• Accès: fibre siège, fibre agence, routeurs, SD-WAN, VPN, bastions.
• Comms: téléphonie cloud, numéros support, SMS transactionnels, WhatsApp/Teams/Slack.
• Automatisations: orchestrateur, RPA, webhooks, files, ETL, intégrations CRM/helpdesk.
• IA: API LLM, RAG, vector DB, outils de monitoring, logs, alerting.

Deux questions qui piquent, mais qui évitent de se mentir:

• Votre “backup Internet” dépend-il d’Orange uniquement?
• Votre accès admin dépend-il du SMS uniquement?

Étape 2: prioriser les flux et définir des RTO réalistes

Quand ça tombe, tout le monde veut être prioritaire. Donc vous tranchez avant.

• Flux vitaux: accès admin, support incident, téléphonie support, facturation, production.
• Flux importants: ventes entrantes, traitement commandes, logistique.
• Flux confort: reporting, enrichissement CRM, automatisations marketing non critiques.

Donnez un objectif de reprise, même simple:

• RTO (temps max d’interruption): par exemple 1 h pour accès admin et support.
• RPO (perte de données acceptable): par exemple 0 pour tickets support, 24 h pour reporting.

Étape 3: MFA mode dégradé, sinon vous êtes aveugle et sourd

Votre priorité numéro 1, c’est de pouvoir vous authentifier quand le SMS est HS. Options à combiner:

• App d’authentification TOTP (codes hors-ligne) au lieu du SMS quand c’est possible.
• Clés de sécurité (FIDO2/WebAuthn) pour les comptes admin et les accès critiques.
• Codes de secours imprimés, scellés, inventoriés, avec procédure d’ouverture.
• Comptes “break-glass” (accès d’urgence) stockés et protégés, testés, avec journalisation.
• Numéros alternatifs et diversité opérateur pour les rares cas où le SMS est imposé.

Point non négociable: documentez qui peut déclencher le mode dégradé, à quelles conditions, et comment vous revenez en mode normal. Sinon ça dérive, et ça devient un trou de sécu.

Sur la partie “accès et garde-fous” des agents, vous pouvez aussi recouper avec ce sujet Lyon IA, côté sécurité opérationnelle: https://lyon-ia.com/blog/agents-ia-10-garde-fous-avant-dautomatiser-en-entreprise-acces-donnees-actions.

Étape 4: support client en mode dégradé (sans perdre l’historique)

Quand la téléphonie ou le CRM est inaccessible, le risque n’est pas juste “on répond moins”. Le risque, c’est on répond sans traces. Et vous payez la dette plus tard (ressaisie, litiges, perte d’info).

Plan concret:

• Canaux de repli: un formulaire web léger, une adresse e-mail dédiée, un canal messagerie si possible.
• Script de tri: 5 questions fixes, toujours les mêmes, pour qualifier en 60 secondes.
• Identifiant incident: un numéro unique attribué à chaque demande, même sur papier.
• Saisie différée: procédure claire pour ressaisir dans le CRM/helpdesk dès retour réseau.
• Base de connaissances hors-ligne: export PDF des procédures critiques, à jour, accessible localement.

Si votre support est déjà “augmenté IA”, prévoyez le plan B: un agent IA peut être indisponible si vos API externes ou votre accès réseau sautent. Donc gardez une version humaine et simplifiée du processus. Sur le fond “support et connaissances”, ce repère peut aider: https://lyon-ia.com/blog/base-de-connaissances-support-ia.

Étape 5: files d’attente, reprise, et anti-effet domino

Une panne réseau, ce n’est pas juste “ça s’arrête”. C’est aussi “ça s’accumule”. Et quand ça revient, tout repart en même temps, et ça recasse.

• Mettre en file tout ce qui peut l’être (tickets, leads, demandes internes) plutôt que d’échouer en silence.
• Déduplication: éviter de créer 5 tickets pour la même demande lors des retries.
• Reprise contrôlée: redémarrage par vagues (priorité 1, puis 2, puis 3).
• Limites: caper le débit de reprise si vos API externes ont des quotas.
• Journalisation: un log exploitable, pas juste “ça a planté”.

Si vous avez déjà des workflows, vous avez déjà des erreurs. La question, c’est si vous savez les reprendre proprement. Pour cadrer cette partie: https://lyon-ia.com/blog/gerer-les-erreurs-workflows-automatises.

Étape 6: procédure manuelle minimale (oui, du manuel, mais carré)

Le manuel improvisé, c’est le chaos. Le manuel prévu, c’est de la continuité.

• Modèles prêts: fiche de prise d’appel, fiche ticket, fiche intervention.
• Règles: ce qui est autorisé ou interdit en mode dégradé (ex: pas de changement de coordonnées bancaires sans contrôle renforcé).
• Traçabilité: qui a fait quoi, quand, sur quelle base.
• Rattrapage: check de fin d’incident pour ressaisir et clôturer proprement.

Checklist opérationnelle: panne Orange Lyon, quoi faire et quoi préparer

Checklist A: alternatives MFA (MFA mode dégradé)

• Remplacer le MFA SMS par TOTP quand possible pour les comptes sensibles.
• Déployer clés FIDO2 pour admins, IT, support, astreinte.
• Générer codes de récupération et les stocker hors dépendance réseau.
• Créer 1 à 2 comptes break-glass (procédure d’usage, journalisation, revue mensuelle).
• Tester la connexion aux outils critiques sans mobile (mode avion): vous saurez vite la vérité.

Checklist B: support en mode dégradé

• Définir un canal de repli (formulaire léger ou e-mail) connu des clients.
• Préparer un script de qualification en 5 questions max.
• Mettre en place un identifiant de demande même hors CRM.
• Prévoir la ressaisie et la réconciliation post-incident (éviter doublons).
• Avoir une base de connaissances exportée pour les procédures vitales.

Checklist C: files d’attente, priorisation, reprise

• Lister les workflows et taguer: critique, important, différable.
• Configurer des queues et des retries avec limites.
• Mettre une déduplication sur les événements et créations (tickets, leads).
• Documenter un plan de reprise par vagues (ordre et seuils).
• Prévoir un mode lecture seule pour certains outils plutôt qu’un arrêt total.

Checklist D: procédures manuelles

• Créer des fiches papier/PDF pour les 3 processus vitaux.
• Nommer un responsable de bascule (et un back-up) côté IT et côté métier.
• Définir les règles de sécurité renforcées pendant la panne (anti-fraude).
• Préparer un point de situation toutes les 60 minutes (même bref).

Checklist E: tests trimestriels (sinon ton PCA n’existe pas)

Un plan non testé est un document, pas une capacité. Cybermalveillance.gouv.fr insiste sur l’importance des processus dégradés et des tests réguliers. Source: cybermalveillance.gouv.fr.

• 1 test/trimestre: simulation panne SMS (MFA sans SMS).
• 1 test/trimestre: simulation perte 4G/5G sur un site pilote.
• 1 test/trimestre: support mode dégradé pendant 2 heures (formulaire, tri, ressaisie).
• Revue post-test: ce qui a bloqué, ce qui manque, et mise à jour des procédures.

Le point souvent raté à Lyon: diversité opérateur et diversité de chemins

Deux liens Internet ne veulent pas dire résilience. Si vous avez:

• fibre chez l’opérateur X,
• secours 4G/5G chez le même opérateur X,

vous avez surtout un SPOF déguisé. Même logique si votre MFA, votre SMS transactionnel, et vos numéros d’astreinte reposent tous sur le même acteur. La résilience, ce n’est pas “doublonner”. C’est diversifier.

Ce que tu peux faire dès cette semaine (sans budget délirant)

• Stopper le réflexe SMS pour les comptes critiques: bascule vers TOTP ou clé FIDO2 là où c’est possible.
• Écrire une page “mode dégradé support” avec 1 canal de repli, 1 script, 1 process de ressaisie.
• Taguer vos automatisations: critique, important, différable.
• Tester en conditions réelles: mode avion sur le téléphone, et tu vois qui reste bloqué.
• Programmer un test trimestriel dans l’agenda, avec un compte rendu. Sans ça, tu oublies.

Un PCA orienté IA, c’est surtout un PCA orienté identité et communications

La panne Orange à Lyon est un rappel utile: vos projets d’automatisation entreprise et d’IA dépendent de briques basiques, parfois invisibles. Voix, SMS, data, MFA, support. Quand l’une tombe, tout le reste peut suivre.

Si vous voulez un angle “pratico-pratique”: ne cherchez pas la perfection. Cherchez une continuité minimale, testée, avec un MFA mode dégradé solide et un support capable d’absorber le choc sans perdre la trace. C’est ça, un plan de continuité IT qui tient quand le réseau tombe.