Summary

  • On 2 June 2021, Orange was performing work intended to increase Voice over IP call-handling capacity. The official multi-agency investigation says a call-server route was reopened before a usable exit existed, calls accumulated in memory, a pre-existing software defect activated, and affected servers entered recurring restart loops that made them difficult to administer. [1][2]
  • The affected call servers formed an interconnection layer between mobile and VoIP voice services and the legacy public switched telephone network. Many emergency-answering centres still depended on that path, so a change in a carrier voice platform became a national public-safety continuity event rather than an ordinary application outage. [1][3]
  • Orange described the platform as distributed across six sites. Geographic distribution did not preserve service because the configuration sequence and software behaviour crossed the estate as a common mode. Running code and completed calls therefore provide stronger resilience evidence than a diagram showing six locations. [1][3][6]
  • Orange reported an 11 percent deterioration in emergency-call routing and estimated that about 11,800 emergency calls were not routed. The external mission recorded that estimate but said it could not independently verify it; the Senate later used a figure of roughly 10,000. The numbers must remain attributed and should not be harmonised into a false exact total. [1][3][4]
  • Official and parliamentary records discussed deaths that authorities examined in connection with unsuccessful access to emergency services. The available record does not establish individual medical causation or a final legal conclusion, so this article does not state that the network incident caused a particular death. [1][4][5]
  • Emergency services detected abnormal incoming-call volumes and published ten-digit alternatives. The external report found that some so-called black numbers were only translations of the same short emergency numbers and did not bypass the failed transport path. A different identifier is not an independent network fallback. [1][4][9]
  • Technical teams identified abnormal behaviour before the organisation fully recognised the emergency-service dimension. The oversight chronology records delays in identifying heavy complaints involving short emergency numbers, reporting the major incident to the interministerial crisis centre and convening Orange's first internal crisis cell. [1][4][7]
  • The official investigation identified the absence of emergency-number-specific national supervision and insufficiently tested operating procedures as material control gaps. Server health, overall call volume and emergency-call completion are different evidence channels; only the last directly answers whether the public service worked. [1][2]
  • Later French legislation, decrees, ministerial rules and Arcep opinions introduced or specified continuity measures, technical supervision, emergency-number volume and success indicators, alert thresholds and reporting. Those later controls show the direction of reform but are not retroactive proof of Orange's exact legal position or an enforcement sanction on 2 June 2021. [12][13][14][15][16][17][18]
  • Accountability should be tested by whether a future maintenance operation preserves at least one administratively and technically independent call path, whether emergency calls complete across fixed, mobile and other-operator origins, whether fallback numbers use independent transport, and whether technical, managerial and public-authority escalation can be reconstructed from timestamps. [1][4][19]

The failed service was a network transaction

An emergency number looks simple because the caller sees only two or three digits. The network transaction behind that number is not simple. The originating access network has to recognise the call, retain or derive location information where required, select an emergency-routing treatment, pass the session through the relevant voice and interconnection systems, identify the competent answering centre and deliver the call over a path that the centre can receive. If any required control point loses state or reachability, a handset with radio coverage and a functioning dialler can still fail to reach help.

That transaction is the proper unit of accountability for Orange's 2 June 2021 incident. The official investigation describes an interconnection layer in which call servers connected mobile and VoIP services to legacy public switched telephone network destinations. Many emergency centres remained reachable through that legacy side of the chain. When the call-server estate entered restart loops, the practical effect therefore extended beyond a generic voice-platform degradation. Calls whose paths depended on the affected interconnection could fail before reaching an emergency service. [1]

Some calls avoided the failed condition. The official record indicates that combinations involving fully legacy or fully VoIP paths could behave differently, depending on the caller's network and the answering centre's technology. That fact explains why the incident was severe without being universal. It also prevents an exaggerated claim that every call, every emergency number or every answering centre failed. The available evidence supports a path-dependent disruption, not total national silence. [1]

The path dependence matters because it reveals where nominal redundancy can mislead. A carrier can operate several sites and duplicate servers while preserving one logical control plane, one configuration procedure, one software failure mode or one necessary interconnection. An emergency service can publish another telephone number while routing that number through the same failed infrastructure. An operator can restore server availability while some call paths remain impaired. Each of those conditions creates apparent diversity without an independent service outcome.

This is why the incident belongs within risk and accountability on network infrastructure. Remove the VoIP-to-PSTN interconnection, call-server routing state, common configuration action, shared restart behaviour, emergency-call completion metrics and transport independence of fallback, and the thesis no longer holds. What remains would be a general software incident and a crisis-communications case. The public-safety consequence arose because a network control layer that carried essential voice transactions did not preserve an independent route.

A capacity operation activated a common-mode failure

The technical sequence should be stated narrowly. Orange was carrying out an operation intended to increase VoIP capacity. According to the official multi-agency report, the procedure changed call-server configuration so equipment could be updated and then reconnected. During restoration of the routes, an initial instruction reopened a route before a usable exit existed. Calls accumulated in server memory. That state activated a pre-existing software defect, and the affected servers entered recurring restart loops. The loops made the servers unadministrable, preventing the next corrective instruction from being accepted. [1][2]

The report characterises the order of instructions as an Orange error while also identifying software behaviour that amplified the initial mistake and made recovery harder. Both parts are necessary. Describing the event only as human error would hide the platform's inability to contain a foreseeable configuration mistake. Describing it only as a software bug would hide the operational sequence that placed the system in the triggering state. The accountability surface is the interaction between change design, route-state validation, software resilience, administrative recovery and service monitoring.

The sequence also distinguishes cause from consequence. Reopening a route without a usable exit did not simply produce a clean rejection. Calls accumulated. The accumulation triggered latent behaviour. The resulting restart loops then impaired administrative control. Each transition increased the blast radius and reduced the operator's ability to correct the previous state. A resilience assessment should therefore ask not only whether an invalid sequence can be prevented, but also whether the platform fails safely if prevention does not work.

A safe failure would preserve an independent control path, bound the queue or memory effect, isolate a subset of servers, reject the invalid route state before traffic is accepted or keep enough capacity available to carry emergency calls. The public record does not establish which of those mechanisms existed in Orange's platform or which specific controls were later implemented. They are not asserted as missing facts. They are testable questions derived from the documented sequence.

The same discipline applies to vendor responsibility. The official sources describe a pre-existing software defect, but the packet does not provide a complete defect history, affected version list, contractual allocation of duties or final legal finding against a supplier. Naming a vendor or allocating liability would exceed the evidence. A control-based analysis can still ask whether defect disclosure, patch qualification, fail-safe behaviour, support escalation and acceptance testing were sufficient without inventing an answer.

Six sites did not create six operational fates

Orange's internal account described the call-server platform as distributed across six sites. [3] That fact is important, but it is not a resilience verdict. Geographic distribution protects against some facility failures, power losses, local equipment incidents and physical hazards. It does not automatically protect against a common command, common software state, shared administrative authority or a routing dependency that crosses every site.

The June incident supplies a running-code test. Whatever separation existed in physical location, the deployed system responded to the configuration sequence and software condition in a way that impaired the estate. Calls did not receive six independent outcomes merely because servers occupied six places. The observed behaviour is stronger evidence about the relevant failure domain than the site count.

This does not mean the six-site architecture had no resilience value. It may have protected against other events, and the available sources do not disclose the complete topology. The narrower conclusion is that site diversity did not contain this particular common mode. A credible assurance statement must therefore identify which failure classes the architecture separates and which ones it does not.

Change segmentation is part of that assurance. If all sites can be placed into the same dangerous state by one procedure, the maintenance design has joined them operationally. Controls can separate that fate through canary execution, staged route activation, independent approval, per-site blast-radius limits, health and service checkpoints, immutable rollback access or an untouched reserve group. The exact control set should follow the architecture and threat model. The evidence needed is a change plan and test record showing that one known-good service path survives.

Administrative independence is equally important. A backup server is of limited value if the failure also removes the management path required to activate or repair it. The restart loops in the official sequence made servers unadministrable and prevented acceptance of the next corrective instruction. [1] A resilience test should therefore include the management plane, not only the traffic plane. Operators need to know whether they can observe, isolate and recover a platform while its ordinary control interface is degraded.

Running-code evidence gives this distinction a practical form. The legitimacy of a continuity claim rests on what the deployed network does when a real failure or maintenance action occurs. Policies, architecture diagrams and redundancy counts are inputs to assurance. Completed emergency calls, bounded failure domains, recoverable control paths and timestamped tests are the reality layer.

The impact numbers require attribution, not synthesis

Orange reported that the severe national disruption ran from approximately 16:45 until midnight. It described an 11 percent deterioration in emergency-call routing and estimated that around 11,800 calls were not routed. [3] The official external mission recorded the estimate but stated that it could not independently verify it. [1] The Senate later used a figure of roughly 10,000 unsuccessful emergency calls. [4]

Those figures point to a large service failure. They do not produce one independently verified exact count. The correct treatment is to preserve their provenance. Orange's 11,800 is an operator estimate. The external report's inability to verify it is a material qualification. The Senate's roughly 10,000 is an oversight figure from a later record. Rounding, time windows, call definitions, retries and source systems may explain differences, but the packet does not establish the reconciliation method.

An unsuccessful call is also not necessarily one unique person or one abandoned emergency. A caller may retry. Multiple people may call about the same incident. A failed attempt may later complete by another route. Conversely, one incomplete attempt can have serious consequences. Without call-level and incident-level data, the record supports neither minimisation nor multiplication.

The discussion of deaths demands an even stricter boundary. Government and parliamentary materials examined reports of deaths that may have been associated with difficulty reaching emergency services. [1][4][5] The supplied evidence does not establish that a particular unsuccessful call medically caused a death, that a completed call would have changed the outcome or that Orange received a final legal finding on causation. This article therefore does not convert institutional concern into a causal verdict.

The absence of a verified national count is itself an accountability lesson. An essential network service should produce reconcilable evidence of attempts, routing outcomes, delivery, answer seizure, retries and restoration, subject to privacy and lawful handling. If operators, emergency centres and authorities cannot reconcile those signals after a national event, they cannot confidently measure the failure or validate the recovery.

Later French supervision rules made service-specific measurement more concrete. The post-incident framework addressed emergency-call volume, success or answer-seizure indicators, thresholds and reporting. [14][15][16][17] Those measures do not retroactively establish the exact 2021 total. They demonstrate what more inspectable evidence can look like: defined metrics, alert conditions, responsible recipients and records that can be compared across the service chain.

An alternative number is not necessarily an alternative path

During the incident, emergency organisations and public authorities distributed ten-digit numbers so that callers could try to reach local services without relying on the familiar short codes. That response was understandable and may have helped where the numbers terminated over a usable route. The official investigation nevertheless identified a critical ambiguity: some so-called black numbers were only translations of the short emergency numbers and did not provide an independent bypass. [1][4]

This distinction separates numbering from transport. A short number such as 15, 17, 18 or 112 is an identifier that causes the network to apply emergency routing. A ten-digit number is another identifier. If both identifiers resolve into the same affected call-server path, changing what the caller dials does not change the decisive failure domain. The fallback is semantically different and operationally identical.

A genuine fallback must be defined end to end. It should terminate at the correct emergency centre, use a transport path that does not depend on the failed platform, carry adequate capacity, preserve location and routing procedures where necessary, remain current, and be distributed through channels available during the outage. It must also be tested from realistic fixed, mobile and other-operator origins. A spreadsheet of numbers cannot prove those properties.

The public-copy problem also matters. Authorities and operators need to know which alternatives are truly independent before they tell the public to use them. The official report says Orange did not promptly correct the ambiguity around some numbers. [1] In a crisis, an inaccurate fallback instruction can consume caller time and emergency-service capacity while creating false assurance.

An operational fallback registry should therefore record more than digits. It should identify the destination, responsible organisation, transport provider, primary and alternate route, last end-to-end test, capacity assumption, geographic scope, distribution owner and known limitations. Changes to emergency-centre connectivity should update that record. The registry is a ledger of operational facts, not a declaration that a route is sovereign or safe merely because it has been listed.

The later ANSC work on NexSIS 18-112 and the SECOURIR component provides relevant institutional context. ANSC materials discuss resilient IP transport, supervision and inter-service assistance. [10][11] Those programmes must not be projected backward as an available fallback on 2 June 2021. They show how public authorities later worked on continuity and interoperability, not what the incident network could do at the time.

Detection, interpretation and escalation were separate controls

Technical teams noticed abnormal behaviour relatively quickly. Recognising that the behaviour was impairing emergency calls, activating managerial crisis processes, informing public authorities and coordinating with other operators took longer. The oversight record treats those as distinct stages, and an accountable timeline should do the same.

The Senate chronology, drawing on the external investigation, records approximately 45 minutes before heavy complaints involving short emergency numbers were recognised, 1 hour 41 minutes before the major incident was reported to the interministerial crisis centre, and 2 hours 40 minutes before Orange's first internal crisis-cell meeting. [4] Orange later acknowledged that managerial crisis activation and stakeholder communication had been too slow. [3][6][7]

These intervals should not be treated as precise evidence about every individual action or internal message. They are oversight milestones derived from the investigation. Their value is structural: a network can generate technical alarms without generating timely public-safety awareness.

Server-health monitoring answers whether software processes, interfaces or resources appear normal. Aggregate voice metrics answer whether overall call volumes and completion rates have changed. Emergency-service telemetry answers whether calls to specified numbers reach intended answering centres. Complaint channels answer whether users and centres are experiencing failures not yet visible in platform metrics. Government notification answers whether the authority responsible for a national response can coordinate alternatives. None of those signals substitutes for all the others.

The incident exposed the cost of weak correlation. Emergency services noticed abnormal incoming-call volumes and used their own escalation networks. [1][4][9] If a carrier's national operations centre cannot immediately connect that external evidence to internal route and server state, technical detection can precede service understanding by a dangerous interval.

Escalation design should therefore be explicit. Emergency-call success thresholds should trigger a named incident class. That class should identify technical, executive, regulatory and public-authority recipients. Cross-operator coordination should not depend on ad hoc personal contact. Alternative-number guidance should be validated before release. The service should remain in an emergency state until end-to-end completion evidence, not merely server recovery, meets the exit criteria.

The Ministry of the Interior's crisis update documents continued interministerial coordination, residual local problems and the decision to retain alternative numbers while service stabilised. [9] That record shows why restoration is not one timestamp. A central platform may improve while local paths remain impaired. Public instructions may need to persist until the service chain is demonstrated across regions and centres.

The later legal framework made observability concrete

French law and regulation changed after the incident. The later framework addressed continuity of emergency communications, technical supervision, measurement and notification. [12][13][14][15] Arcep's opinions in 2023 discussed proposed indicators, thresholds and reporting arrangements for emergency-call routing. [16][17] Current regulator guidance summarises operator duties relating to routing, caller location and significant incidents. [18]

These materials should be used carefully. A rule adopted or amended after June 2021 is not automatically the exact legal standard that applied during the incident. A regulator opinion about proposed supervision is not an enforcement decision against Orange. The existence of a later obligation does not prove that Orange lacked every comparable internal control before the outage. The sources support a policy response and a more measurable assurance model, not a retroactive verdict.

The later framework is nevertheless useful because it translates a broad continuity promise into observable conditions. Monitoring emergency numbers separately from ordinary voice traffic makes the service visible. Call-volume and answer-seizure indicators can reveal degradation that server metrics miss. Defined thresholds create an escalation boundary. Reporting duties ensure that operators do not keep a public-safety condition inside a technical team after its significance becomes clear.

Measurement design still requires care. A success rate can conceal geography, caller network, destination technology or repeated attempts. A national aggregate may look acceptable while one department or emergency centre is unreachable. A threshold may be too insensitive during low-volume periods. Answer seizure does not prove that the caller received the required assistance. Those limits do not make measurement useless; they require a layered set of indicators and test transactions.

The technical standard in the source packet provides additional context for emergency sessions in IMS environments. [19] It describes architecture and routing concepts that can help explain independent treatment and emergency-session handling. It does not prove that Orange implemented a particular option or that compliance with one standard would have prevented this incident. Standards define possible controls; deployed configuration and observed service prove whether they worked.

Control was divided, but responsibility was not absent

The emergency-call chain crosses organisational boundaries. Orange controlled the relevant parts of its voice and interconnection platform, its maintenance process, much of its telemetry and its incident escalation. Other operators controlled originating networks and interconnections used by their customers. Emergency organisations controlled answering-centre connectivity and local continuity procedures. Public authorities coordinated crisis information and later policy. Technology suppliers may have controlled software fixes and defect information, although the public packet does not establish the contractual details.

Divided control can create gaps if each entity assumes that another party is measuring the complete transaction. It can also create resilience when independent networks and centres provide alternate paths and independent evidence. The difference depends on explicit interfaces, tested procedures and shared incident records.

For Orange, the public record supports questions about change approval, route-state validation, software resilience, management access, emergency-specific monitoring and escalation. For emergency centres, it supports questions about diverse access, independently transported numbers, local failure detection and public communication. For public authorities, it supports questions about a validated fallback registry, cross-operator exercises, notification thresholds and the ability to reconcile national impact.

These are questions of practical control, not an invitation to declare every entity equally liable. The sources do not disclose each contract, each statutory interpretation or each decision. Accountability remains bounded when it identifies the evidence each controller should possess and the uncertainty that remains when that evidence is not public.

The external multi-agency investigation is especially important for this reason. It gives a common technical chronology and separates findings from estimates. Orange's internal investigation and testimony supply operator representations. Senate and Assembly materials supply oversight and institutional response. Later legislation and regulator opinions supply the evolving control framework. Keeping those source roles distinct prevents one entity's account from becoming the entire record.

A service-specific change gate

The incident suggests a practical gate for maintenance on emergency-dependent voice infrastructure. The gate should be applied before, during and after a change.

Before the change

  1. Map the end-to-end service. Identify originating access types, emergency number treatment, voice and interconnection functions, destination routing, answering-centre connectivity, management paths and external operators. Mark dependencies that cross sites.
  2. Define the failure domain. State which sites, server groups, software versions, route tables, administrative credentials and transport paths the operation can affect. A geographic list is not enough.
  3. Preserve a known-good group. Keep a documented portion of capacity outside the change and outside the same administrative action. Prove that it can carry emergency traffic if the changed group fails.
  4. Validate route state. The procedure should prevent traffic from entering a route before a usable exit exists. Preconditions and automated checks should fail closed.
  5. Test failure behaviour. Exercise queue growth, restart loops, partial connectivity, management-plane degradation and rollback. Verify that one fault does not make every group unadministrable.
  6. Confirm fallback transport. Test short codes and each published alternative number from fixed, mobile and other-operator origins. Record whether the alternatives share the primary path.
  7. Set service stop conditions. Define emergency-call completion, destination reachability and regional thresholds that stop the change before aggregate platform alarms become severe.
  8. Name escalation owners. Identify the technical commander, executive crisis lead, public-authority contact, emergency-service liaison and cross-operator channel.

During the change

  1. Stage the operation. Change a bounded group, observe service outcomes and wait for a defined period before expanding.
  2. Measure completed emergency transactions. Synthetic probes and controlled test calls should reach representative centres. Server health alone is limited public evidence.
  3. Watch independent evidence. Correlate operator metrics with emergency-centre volumes, complaint channels and other-operator observations.
  4. Protect administrative access. Maintain an out-of-band or otherwise independent path for isolation and recovery.
  5. Stop on ambiguity. If route state, destination reachability or fallback independence cannot be confirmed, pause rather than treating missing telemetry as success.
  6. Timestamp decisions. Record detection, interpretation, escalation, notification, rollback and service verification so the sequence can later be audited.

After rollback or completion

  1. Verify service, not configuration. Show that emergency calls complete by origin, destination, number and region.
  2. Reconcile records. Compare carrier attempts and outcomes with answering-centre receipts, accounting for retries and duplicate reports.
  3. Retain alternative instructions while needed. Do not withdraw public fallback guidance until local and national evidence supports closure.
  4. Document residual risk. Record untested paths, exceptions, unresolved software behaviour and any temporary control.
  5. Repeat the test. A control that worked once can be invalidated by later software, routing, centre or interconnection changes.

This gate does not require publication of exploitable configuration. Public assurance can describe the tested failure classes, route independence, service metrics, exercise dates, exceptions and remediation status without exposing sensitive topology. Regulators and qualified auditors may need confidential access to the underlying evidence.

What would prove the fallback is independent

The phrase "independent fallback" should have an evidence definition.

First, the fallback should have a distinct route graph. It should not traverse the call-server function whose failure is being mitigated. If it uses another operator, the test should show where the paths converge. A second provider can still share a facility, power system, cable, signalling gateway or answering-centre access.

Second, it should have distinct administrative control. The same change command, credential system or orchestration policy should not disable both primary and fallback paths. Recovery access should remain available when the ordinary platform is unstable.

Third, it should have sufficient capacity and prioritisation. A path that works for one test call but saturates during a national event is not an adequate fallback. Capacity assumptions should include simultaneous public retries and emergency-service outbound communications.

Fourth, it should preserve correct destination selection. Emergency calls may need geographic or service-based routing and caller-location handling. A fallback that reaches the wrong centre can create delay even when the call technically connects.

Fifth, it should be discoverable. Emergency organisations, public authorities, operators and communications staff should know which fallback is valid for which area. Public instructions should distinguish genuine alternate transport from a number alias.

Sixth, it should be exercised jointly. Carrier-only tests cannot prove that an answering centre receives, identifies and handles the call. Centre-only tests cannot prove that callers on other networks can reach the route. Exercises should include the whole chain and record the result.

Seventh, it should remain current. Connections, providers, centre locations, routing rules and software change over time. The fallback registry should record the last verified state, not simply the date on which a number was created.

These requirements are demanding because emergency continuity is demanding. They do not prescribe one architecture. They define the proof required before an organisation describes an alternative as independent.

Remediation claims need a measure-to-failure map

Orange announced corrective actions after the incident, and the government report set out recommendations. [1][2][3] The responsible way to evaluate those actions is not to count initiatives. Each measure should be linked to a documented failure mechanism.

A revised change procedure should address the order in which routes are opened and exits become usable. Staging should address the common blast radius. Software remediation should address the memory accumulation and restart-loop behaviour. Independent management access should address the loss of administrative control. Emergency-specific supervision should address the delay between technical detection and recognition of public-safety impact. Cross-operator exercises should address divided visibility. A validated fallback registry should address the confusion between another number and another route.

For each measure, evidence should identify an owner, implementation date, covered systems, validation method, observed result, exception and residual risk. A measure is not complete merely because a document was approved or software was deployed. It is complete enough for assurance when the relevant failure test produces the intended service outcome.

The public sources do not independently establish that every announced measure remained deployed and effective over time. Nor do they disclose all external or internal audit results. That is a limitation, not proof of failure. A proportionate public record could still state which failure classes were retested, whether an independent route carried calls, whether emergency-specific thresholds fired and what exceptions remain.

Later reforms also require this mapping. New monitoring can become a reporting burden without improving continuity if its thresholds do not detect the documented condition. A new IP transport can remain vulnerable if primary and fallback paths share control. A new crisis protocol can fail if entities do not exercise it. Controls earn confidence through use.

What the public record still cannot answer

The public packet does not expose Orange's complete change ticket, command transcript, internal approval chain, route tables, software versions or contemporaneous logs. It does not identify every person who designed, approved, executed or supervised the operation. Those omissions prevent individual attribution.

The full vendor defect history is not available. The evidence does not establish when the defect was discovered, what contractual notices existed, which patches were available or how responsibility was allocated between Orange and a supplier. A legal claim about a vendor would exceed the record.

The exact national impact remains uncertain. Orange's approximately 11,800 estimate was not independently verified by the external mission, and the Senate used roughly 10,000. The record does not provide a complete breakdown by region, originating network, answering-centre technology, number, retry or final outcome.

The evidence does not establish medical causation for a particular death. It does not show that every unsuccessful attempt represented an abandoned emergency, nor that every later successful call avoided harm. Institutional concern must remain distinct from a medical or judicial finding.

The packet does not provide a final Arcep enforcement result or sanction establishing an Orange legal violation. Later laws, decrees, orders and regulator opinions should not be converted into such a finding.

The available sources do not prove that every announced remediation remained in place, that every answering centre obtained diverse access, that every alternative number gained independent transport or that subsequent exercises covered every relevant path.

The exact condition of NexSIS 18-112 and SECOURIR during June 2021 is also bounded. Later ANSC materials describe programme work, but they do not establish that those systems were available as incident fallbacks.

These unknowns define the limit of the conclusion. They do not erase the documented mechanism. The record is sufficient to test whether operational controls can contain a common configuration and software condition and whether emergency-call continuity is measured as an end-to-end network outcome.

Accountability begins with a completed call

Orange's six-site platform provided geographic distribution, but the 2 June 2021 incident demonstrated that geography was not the decisive failure boundary. A shared configuration sequence and shared software behaviour impaired the call-server estate, while loss of administrative control complicated recovery. The result was a path-dependent disruption of ordinary and emergency voice traffic.

The event also demonstrated that fallback has to exist in transport, not merely in numbering. A ten-digit alternative that resolves through the affected infrastructure does not bypass the failure. An independently routed number, a different provider, a separate management path and a tested answering-centre connection are different controls, and each needs evidence.

The official chronology showed a third boundary between detecting technical trouble and understanding public-safety impact. Emergency-specific completion telemetry, centre-side evidence, cross-operator coordination and public-authority notification need to be connected before a crisis, not assembled after callers report failure.

Later French measures moved toward that evidence model by specifying continuity, supervision, indicators, thresholds and reporting. They should be evaluated by whether they reveal and contain the same failure condition, not by their existence on paper.

The accountable claim is therefore conditional. Orange or any operator should describe emergency-call redundancy as effective only when a real or controlled failure leaves a known-good route carrying calls, the destination receives them, operators can still administer the system, and the result can be reconciled across the service chain. The 2021 outage made that completed transaction, rather than the number of sites or alternative numbers, the public-safety test.

Sources

  1. https://www.vie-publique.fr/files/rapport/pdf/280855.pdf
  2. https://presse.economie.gouv.fr/1252-panne-orange-du-2-juin-le-gouvernement-rend-public-le-rapport-de-lanssi-du-cced-et-des-trois-inspections-iga-igas-et-cge-et-annonce-des-premieres-mesures/
  3. https://www.orange.com/en/press-release/orange-presents-the-conclusions-of-the-internal-investigation-into-the-2-june-crisis-that-impacted-emergency-calls-in-france-234710
  4. https://www.senat.fr/rap/r21-297/r21-297_mono.html
  5. https://www.senat.fr/salle-de-presse/communiques-de-presse/presse/cp20211216.html
  6. https://www.senat.fr/compte-rendu-commissions/20211025/commissions.pdf
  7. https://www.assemblee-nationale.fr/dyn/actualites-accueil-hub/dysfonctionnements-ayant-affecte-l-appel-des-numeros-d-urgence-audition-de-s.richard
  8. https://www.assemblee-nationale.fr/dyn/opendata/RINFANR5L15B5119.html
  9. https://www.interieur.gouv.fr/archives/actualites/communiques-de-presse/communique-de-presse-de-cellule-interministerielle-de-crise
  10. https://ansc.interieur.gouv.fr/focus-sur-le-dysfonctionnement-des-numeros-durgence/
  11. https://ansc.interieur.gouv.fr/wp-content/uploads/2022/09/20220916_MI_ANSC_Newsletter-Flash-info-ANSC-NexSIS-18-112.pdf
  12. https://www.legifrance.gouv.fr/codes/section_lc/LEGITEXT000006070987/LEGISCTA000006165902/2023-12-25
  13. https://www.legifrance.gouv.fr/codes/article_lc/LEGIARTI000044164666
  14. https://www.legifrance.gouv.fr/jorf/id/JORFTEXT000048007084
  15. https://www.legifrance.gouv.fr/jorf/id/JORFTEXT000048007122
  16. https://www.arcep.fr/uploads/tx_gsavis/23-0146.pdf
  17. https://www.arcep.fr/uploads/tx_gsavis/23-1559.pdf
  18. https://extranet.arcep.fr/communications-electroniques/communications-d-urgence
  19. https://www.etsi.org/deliver/etsi_ts/123100_123199/123167/16.03.00_60/ts_123167v160300p.pdf